Software Development Projects


Published on

Software Development Projects Presentation.

Published in: Education, Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Welcome to my presentation. It was developed in conjunction with my research paper on Software Development Projects: A Case Study of Failure and Success. Please go to slide #2
  • My name is Carol Harstad and I have done this research project in fulfillment of my masters degree in Information Systems. My concentration is on software engineering management, so I believed it to be highly important to not only pool all my course learning and experience together, but to go further and gather information that was not available in the curriculum. There is a vast amount of information available on software engineering and developing software projects. The problem was that I could not find any one source that puts it all together in terms of success and failure, which I intend to here.Please go to slide #3
  • After reviewing the literature, I felt in order to determine the requirements for success, it was necessary to lay out the knowledge areas of software engineering and show causes of previous failures. Only then was it possible to outline successful practices to be used for a software development project and determine the tools that could be used in conjunction with those practices.Please go to slide #4
  • While researching software engineering methods, I found studies pertaining to software failures and successes. If a software development project is done improperly, which is a majority of the time, it may take longer to complete than anticipated, be low in quality, cost more than estimated, be hard to maintain, have missing features, or there could be an unacceptable level of bugs.Other projects may end in total failure and require the project be abandoned, or worse, cause a catastrophic disaster that could possibly lead to the loss of life.Please go to slide #5.
  • I have discussed project challenges and failures, however projects can end in one of three ways. They can end in success, which is on time, within budget, and of high quality. They can end in what is known as challenged, which means it was completed, however it went over budget, beyond the estimated time period, and offers less features than was listed in the requirements document. Last but not least, they could end in complete failure, in which there is no other option than to abandon the project.Please go to slide #6
  • The Standish Group periodically publishes their research on project successes, challenges, and failures as derived from surveys. Recent studies show there is only a 32% success rate, and a 24% failure rate. Challenged projects are at a rate of 44%.This chart shows the percentage of each from 1994 to 2009. As you can see, successful projects have basically increased since 1994. While failures were showing a decline, there was a slight increase in the latest survey. Challenged projects have not changed a whole lot, but have shown a decrease in the most recent survey. It is assumed that the reason success rates have increased over the past 15 years, is due to education in software engineering and project management. At the same time, the failure rate shows there are still many organizations that do not properly use software engineering methods and tools to their advantage.Please go to slide #7
  • Bynow you may be asking, “What is the research?”The question answered by the research project is: What can we do within the software development process to ensure a successful delivery of software projects and to avoid possible failure? To answer this question, it was necessary to also answer the following questions:What are the knowledge areas of software engineering?What are causes of failures in software development projects?What methods can we implement to ensure successful completion of a software project?What tools are available that will allow a project a better possibility of success?Please go to slide #8
  • What are the knowledge areas of software engineering?To answer the first sub-question, the paper outlines and defines each of the knowledge areas as set forth by Software Engineering Body of Knowledge put out by the IEEE Computer Society. There are actually 10 knowledge areas, however this paper focuses on the six shown, and separately covers the tools available.The three remaining knowledge areas are covered in the paper, however not directly as their own individual pieces, as they encumber the other covered knowledge areas.Please go to slide #9
  • Why do projects fail?There are many reasons that can lead to project failure including: Bad planning, vague objectives, inadequate requirements, inadequate risk, scope or quality management, inadequate project or development methodologies, lack of resources, unrealistic expectations, and more.Please go to slide #10
  • The best way to think about software engineering is by comparing it to a puzzle. Each piece of the puzzle (or process) that is left out leaves less of a complete picture. The more pieces (or processes) you leave out, the more inclined you are to throw out the puzzle (or project), and abandon it completely. This is very important in a software development project because if you leave out, say the software design process, the development portion will be very difficult, if not impossible, to complete. If you leave out the project management process, you will have a project that is in complete disarray.Please go to slide #11
  • This slide represents the possible impact of adding an attribute that was left out of the requirements specification document. Depending on the attribute and at what stage the attribute is added, changes might be made to the database, input forms (such as screens), output forms (such as reports), control algorithms, update algorithms, tests, system testing plans, data conversions, system interfaces, system documentation, and user documentation. You can see that this will take a considerable amount of time, depending on how much of the project has been completed.Please go to slide #12
  • When it comes to failures, one particular project specifically comes to mind. The Ariane 5 Rocket (otherwise known as Flight 501), was considered to have had the most expensive bug in history. After spending one billion dollars on the prototype, it exploded after only 40 seconds into take-off. The reason for the failure? An incorrect variable in the on-board software.Please go to slide #13
  • Another project that failed considerably, was the FBI’s Virtual Case File (VCF) system. Originally announced in 2000, it was anticipated to take 3 years to complete and the software portion was estimated at $120,000,000. In April 2005, the FBI officially abandoned the project after spending $170,000,000. There were many reasons for the failure, including poorly defined and ever evolving requirements, contract weaknesses, IT investment management weaknesses,lack of management continuity and oversight, unrealistic scheduling of tasks, lack of adequate project integration, and inadequate resolution of issues.Please go to slide #14
  • I am sure most, if not all, of you remember what you were doing and where you were on the morning of September 11, 2001. Some people believe that had the FBI had an up-to-date, operational system in place at the time, those events might have been avoided. The reason for this belief is that information could have been transmitted in real time, allowing for mass communication and warnings that could have stopped this horrible event.Please go to slide #15
  • Another famous project failure is the Federal Aviation Administration’s Advanced Automation System. It was considered a 13 year “train wreck” and cost $2.6 Billion. At its peak, the project was costing $1 million/day, used 2,000 IBM employee’s, and generated hundreds of pages of documentation per line of code. Rosenberg referred to this project as the “greatest debacle in the history of organized work.”Please go to slide #16Rosenberg, S. (2008). Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. New York: Three Rivers Press.
  • Other failures include projects by the California Department of Motor Vehicles, American Airlines, Sydney Water Corp, Allstate, Westpac Banking Corporation, Canada, and most recently the U.S. Department of Veterans Affairs, who by coding error, sent out letters to thousands of veterans indicating they had a debilitating and fatal disease. While they did eventually send out letters of apology, many patients had already spent thousands of dollars seeking second opinions.Please go to slide #17
  • Now that you have seen reasons that projects fail and a few samples, you can see why it is so important to adhere to a set of best practices, as indicated here, to avoid failure.Please go to slide #18
  • Alongside the Best Practices, many tools can be used to simplify and clarify many processes. These include using project management software, CASE tools, diagrams & other graphical representations, and testing tools.Please go to slide #19
  • You have been shown the definition and trends in success, challenges, and failures and some samples of catastrophic and costly failures. You have been shown the reasons behind these failures, and a recipe for success.By knowing where others have failed and succeeded, we can better understand the need to consistently adhere to proper software engineering methods, processes, and standards in order to complete a software development project successfully.Thank you for your time. This concludes this presentation on Software Development Projects: A Case Study of Failure and Success.{End of slide show}
  • Software Development Projects

    1. 1. Software Development Projects:<br />CIS590 – Directed Research Project<br />Carol A. Harstad<br />A Case Study of Failure and Success<br />
    2. 2. Who am I?<br />Carol A. Harstad<br />Completing Master of Science in Information Systems<br />Software Engineering Management<br />18 years experience in Software Development<br />
    3. 3. Chapters of the paper<br /><ul><li>Introduction
    4. 4. Literature Review
    5. 5. Knowledge Area’s of Software Engineering
    6. 6. Causes of Challenged and Failed Projects
    7. 7. Practices for Project Success
    8. 8. Tools & Models
    9. 9. Summary & Conclusion
    10. 10. Appendices: Requirements Document, Change Request Log, & Possible Threat List.</li></li></ul><li>Context of the Problem?<br />Majority of Software Development Projects:<br />Longer to complete<br />Low quality<br />More expensive<br />Hard to maintain<br />Missing features<br />Unacceptable level of bugs<br />Other projects:<br />Abandon the project<br />Catastrophic disasters<br />
    11. 11. Projects can end in 1 of 3 ways<br />Success<br />Challenged<br />Failure<br />On Time<br />Within Budget<br />High Quality<br />Over Budget<br />Extended Time<br />Less Features<br />Abandon<br />
    12. 12. Standish Group – CHAOS Summary<br />
    13. 13. What is the Research?<br />What can we do within the software development process to ensure a successful delivery of software projects and to avoid possible failure?<br />What are the knowledge areas of software engineering?<br />What are causes of failures in software development projects?<br />What methods can we implement to ensure successful completion of a software project?<br />What tools are available that will allow a project a better possibility of success?<br />
    14. 14. Software Engineering<br />Knowledge Areas:<br />Requirements<br />Design<br />Construction<br />Testing<br />Maintenance<br />Processes and Product Quality<br />Not included:<br />Configuration Management<br />Engineering Management<br />Engineering Processes<br />Separately:<br />Engineering Tools<br />
    15. 15. Why do projects fail?<br />Bad Project Planning<br />Vague Objectives<br />Inadequate/Incomplete Requirements<br />Inadequate Management in areas such as:<br />Risk<br />Scope<br />Quality<br />Inadequate Methodologies<br />Lack of Resources<br />Unrealistic Expectations<br />More<br />
    16. 16. Software Engineering is like a puzzle<br />
    17. 17. Attribute addition after project completion can affect:<br />Attribute<br />Database<br />User Documentation<br />Input Forms<br />System Documentation<br />Output Forms<br />System Interfaces<br />Control Algorithms<br />Data Conversions<br />Update Algorithms<br />System Testing Plans<br />Tests<br />
    18. 18. Ariane 5 Rocket (Flight 501)<br />Most expensive bug in history<br />$1 Billion prototype<br />40 Seconds<br />Incorrect variable in the software<br />End result?<br />FAILURE!!!<br />
    19. 19. FBI Virtual Case File<br />Announced the project in September 2000<br />Estimated $120,000,000 for software portion of project and 3 years to complete<br />April, 2005 – FBI Officially cancelled the project after spending $170,000,000<br />It’s incomplete!?!<br />It’s unusable!!!<br />How did that happen????<br />Both FBI and SAIC at fault.<br />Reasons for Failure<br /><ul><li>poorly defined and evolving requirements
    20. 20. contracting weaknesses
    21. 21. IT investment management weaknesses
    22. 22. lack of management continuity and oversight
    23. 23. unrealistic scheduling of tasks
    24. 24. lack of adequate project integration; and
    25. 25. inadequate resolution of issues</li></li></ul><li>September 11, 2001<br />Although only a theory, some believe that if the FBI had an up to date, operational system in place at the time, the events of September 11, 2001 might have been avoided.<br />
    26. 26. Another Project Failure<br />FAA – Advanced Automation System<br />13-year “train wreck”<br />$2.6 Billion disaster<br />$1 million/day, 2,000 IBM employees, hundreds of pages of documentation per line of code<br />Greatest debacle in the history of organized work (Rosenberg, 2008)<br />
    27. 27. More Famous Failures<br />California Department of Motor Vehicles<br />American Airlines<br />Sydney Water Corp<br />Allstate<br />Westpac Banking Corporation<br />Canadian Gun Registry<br />U.S. Department of Veterans Affairs<br />
    28. 28. Recipe for Success<br />Stakeholder Management<br />Project Planning<br />Clear Objectives<br />Clear requirements and analysis<br />Risk Management<br />Scope Management<br />Project Management Methodology<br />Quality Management<br />Supplier Management<br />Resource Management<br />User Involvement<br />Executive Support<br />Realistic Expectations<br />Communication Management<br />Competent Staff<br />Iteration Deliveries<br />
    29. 29. Tools for Success<br />Project Management Software<br />CASE Tools<br />Diagrams/Graphical Representations<br />Testing Tools<br />
    30. 30. Conclusion<br />Trends and Definitions of success, challenges, and failures<br />Samples of catastrophic and costly failures<br />Reasons leading to failure<br />Recipe for Success<br />YAY!!!<br />