This document provides a summary of a master's thesis on software development projects. It discusses several high-profile software project failures such as the FBI's Virtual Case File system and the Ariane 5 rocket to demonstrate what can go wrong when proper software engineering practices are not followed. The author aims to determine best practices for ensuring successful software project delivery and avoiding failure by examining literature on challenges, reasons for failure and success factors. The thesis will also explore software engineering knowledge areas, causes of failed projects, practices for success, and relevant tools and models.

1. Running head: SOFTWARE DEVELOPMENT PROJECTS SOFTWARE DEVELOPMENT PROJECTS: A CASE STUDY OF FAILURE AND SUCCESS Direct Research Project in Partial Fulfillment of the Requirements for the Degree of Master of ScienceInformation Systems – Software Engineering Management Submitted By Carol A. Harstad, BS (IS-Pr) 1240 Apopka Lane, Kissimmee, Florida 34759 (863) 427-0890 carol.harstad@mail.strayer.edu Under the direct supervision of Dr. Ward Ulmer Online Campus – Strayer University September 2009 ACCEPTANCE PAGE Strayer University Certificate of Approval Form A DRP Entitled SOFTWARE DEVELOPMENT PROJECTS: A CASE STUDY OF FAILURE AND SUCCESS By CAROL A. HARSTAD We hereby certify that this DRP submitted by CAROL A. HARSTAD conforms to acceptable standards, and as such is fully adequate in scope and quality. It is therefore approved as the fulfillment of the requirement of the degree of Master of Science in Information Systems – Software Engineering Management. Approved: ___________________________________________ Supervising Faculty: ___________________________________________ Peer Review/Technical Advisor: ___________________________________________ ABSTRACT To err is human, but to really foul things up you need a computer ~ Paul Ehrlich When proper software engineering techniques and processes are neglected or ignored, software development projects can suffer. They can cost more than estimated, take longer than anticipated, be low in quality, and maintenance can be difficult. At worst, the project could be completely abandoned. By using the proper processes and procedures, an organization has a better chance of completing a high quality, maintainable software project on time, and less expensive than one that is disorganized and in disarray. The purpose of this study was to determine processes we can implement to ensure the successful delivery of a development project. The main question that was answered by this research project was; what can we do within the development process to ensure a successful delivery of software projects and to avoid possible failure? To answer that question, the knowledge areas of software engineering were laid out, examples of failures were discussed, methods were outlined, and tools were identified. The results were obtained from websites, textbooks, newspaper articles, websites, and industry publications. TABLE OF CONTENTS TOC o "
1-3"
h z u ACCEPTANCE PAGE PAGEREF _Toc240635806 h iABSTRACT PAGEREF _Toc240635807 h iiLIST OF FIGURES PAGEREF _Toc240635808 h viCHAPTER 1 - INTRODUCTION PAGEREF _Toc240635809 h 1Context of the Problem PAGEREF _Toc240635810 h 1Statement of the Problem PAGEREF _Toc240635811 h 2FBI Virtual Case File. PAGEREF _Toc240635812 h 2The Ariane 5 rocket (Flight 501) PAGEREF _Toc240635813 h 5The Federal Aviation Administration Advanced Automation System PAGEREF _Toc240635814 h 5Other Software Development Failures PAGEREF _Toc240635815 h 5Research Question and Subquestions PAGEREF _Toc240635816 h 7Significance of the Study PAGEREF _Toc240635817 h 7Research Design and Methodology PAGEREF _Toc240635818 h 8Objectives of the Study PAGEREF _Toc240635819 h 8CHAPTER 2 – LITERATURE REVIEW PAGEREF _Toc240635820 h 9Software Project Challenges and Failure PAGEREF _Toc240635821 h 9Reasons of Software Project Challenge or Failure PAGEREF _Toc240635822 h 10Software Project Success PAGEREF _Toc240635823 h 10Conclusion PAGEREF _Toc240635824 h 11CHAPTER 3 – KNOWLEDGE AREAS OF SOFTWARE ENGINEERING PAGEREF _Toc240635825 h 12Software Requirements PAGEREF _Toc240635826 h 12Fundamentals. PAGEREF _Toc240635827 h 12Process. PAGEREF _Toc240635828 h 13Elicitation. PAGEREF _Toc240635829 h 14Analysis. PAGEREF _Toc240635830 h 14Specification. PAGEREF _Toc240635831 h 15Validation and verification. PAGEREF _Toc240635832 h 15Software Design PAGEREF _Toc240635833 h 16Software Construction PAGEREF _Toc240635834 h 17Software Testing PAGEREF _Toc240635835 h 17Fundamentals. PAGEREF _Toc240635836 h 17Levels. PAGEREF _Toc240635837 h 18Techniques. PAGEREF _Toc240635838 h 19Software Maintenance PAGEREF _Toc240635839 h 20Fundamentals. PAGEREF _Toc240635840 h 20Key issues. PAGEREF _Toc240635841 h 21Software Processes and Product Quality PAGEREF _Toc240635842 h 22Analysis and Findings PAGEREF _Toc240635843 h 23CHAPTER 4 – CAUSES OF CHALLENGED AND FAILED PROJECTS PAGEREF _Toc240635844 h 24Introduction to Challenged and Failed Projects PAGEREF _Toc240635845 h 24Causes of Challenged and Failed Projects PAGEREF _Toc240635846 h 24Bad project planning. PAGEREF _Toc240635847 h 24Vague objectives. PAGEREF _Toc240635848 h 26Inadequate project requirements. PAGEREF _Toc240635849 h 26Lack of risk management. PAGEREF _Toc240635850 h 27Lack of scope management. PAGEREF _Toc240635851 h 27Inadequate project management methodology. PAGEREF _Toc240635852 h 28Inadequate development management methodology. PAGEREF _Toc240635853 h 28Inadequate quality management. PAGEREF _Toc240635854 h 29Poor performance by suppliers of hardware/software. PAGEREF _Toc240635855 h 29Lack of resources. PAGEREF _Toc240635856 h 29Lack of user involvement. PAGEREF _Toc240635857 h 30Lack of executive support. PAGEREF _Toc240635858 h 30Unrealistic expectations. PAGEREF _Toc240635859 h 31Incorrect cost estimation. PAGEREF _Toc240635860 h 32Project restarts. PAGEREF _Toc240635861 h 32Technology incompetence. PAGEREF _Toc240635862 h 33Insufficient senior staff on the team. PAGEREF _Toc240635863 h 34Poor social skills. PAGEREF _Toc240635864 h 34Remedy Attempts of Challenged Projects. PAGEREF _Toc240635865 h 34Analysis and Findings PAGEREF _Toc240635866 h 35CHAPTER 5 – PRACTICES FOR PROJECT SUCCESS PAGEREF _Toc240635867 h 37Introduction to Best Practices PAGEREF _Toc240635868 h 37Best Practices PAGEREF _Toc240635869 h 37Stakeholder Management. PAGEREF _Toc240635870 h 37Proper project planning. PAGEREF _Toc240635871 h 38Clear objectives. PAGEREF _Toc240635872 h 41Clear project requirements and analysis. PAGEREF _Toc240635873 h 43Risk management. PAGEREF _Toc240635874 h 43Change control. PAGEREF _Toc240635875 h 45Project management methodology. PAGEREF _Toc240635876 h 45Development methodology. PAGEREF _Toc240635877 h 49Quality management. PAGEREF _Toc240635878 h 49Supplier management. PAGEREF _Toc240635879 h 50Resource management. PAGEREF _Toc240635880 h 51User involvement. PAGEREF _Toc240635881 h 51Executive management support. PAGEREF _Toc240635882 h 52Realistic expectations. PAGEREF _Toc240635883 h 52Communication management. PAGEREF _Toc240635884 h 53Competent staff. PAGEREF _Toc240635885 h 53Iteration deliveries. PAGEREF _Toc240635886 h 54CHAPTER 6 – TOOLS & MODELS PAGEREF _Toc240635887 h 55Introduction to Tools and Models PAGEREF _Toc240635888 h 55Project management software PAGEREF _Toc240635889 h 55CASE tools PAGEREF _Toc240635890 h 56Diagrams and other graphical representations PAGEREF _Toc240635891 h 57Testing Tools PAGEREF _Toc240635892 h 59CHAPTER 7 – SUMMARY AND CONCLUSION PAGEREF _Toc240635893 h 60Summary PAGEREF _Toc240635894 h 60Conclusion PAGEREF _Toc240635895 h 61REFERENCES PAGEREF _Toc240635896 h 63APPENDIX A. REQUIREMENTS DOCUMENT PAGEREF _Toc240635897 h 68APPENDIX B. CHANGE REQUEST LOG PAGEREF _Toc240635898 h 71APPENDIX C. POSSIBLE THREATS FOR RISK MANAGEMENT PAGEREF _Toc240635899 h 72 LIST OF FIGURES TOC h z c "
Figure"
Figure 1. September 11, 2001. (Photo obtained from http://delong.typepad.com/images/911.gif) PAGEREF _Toc240635900 h 4 Figure 2. Standish CHAOS Summary (by percent) (Galorath, 2008) PAGEREF _Toc240635901 h 9 Figure 3. Microsoft Project Sample View. PAGEREF _Toc240635902 h 40 Figure 4. Sample Gantt Chart (Stellman & Greene, 2009). PAGEREF _Toc240635903 h 40 Figure 5. Systems Development Life Cycle (SDLC) (U.S. Department of Justice, 2003) PAGEREF _Toc240635904 h 46 Figure 6. Success Potential Chart (The Standish Group, 1994). PAGEREF _Toc240635905 h 47 Figure 7. PERT Chart (Image released to public domain by: Jeremy Kemp, 2005) PAGEREF _Toc240635906 h 55 Figure 8. Sample Gantt Chart (Stellman & Greene, 2009). PAGEREF _Toc240635907 h 56 Figure 9. Class Diagram PAGEREF _Toc240635908 h 57 Figure 10. Data Modeling Process PAGEREF _Toc240635909 h 58 Figure 11. Entity Relationship Diagram PAGEREF _Toc240635910 h 58 SOFTWARE ENGINEERING METHODS CHAPTER 1 - INTRODUCTION Context of the Problem What issues can a company face if they perform a software development project inappropriately? If not done properly, developing a new software package can be lengthy, taking longer than expected to reach completion. Additionally, it can result in low quality, more expensive, and harder to maintain software. Improper design and planning could possibly lead to disastrous results. This paper shows that by applying the proper methods and procedures to the development process, and using the proper tools, an organization can avoid these issues and develop a high quality, less expensive, easier to maintain software in a timely manner CITATION Sof09 l 1033 (Software Engineering, 2009). The Institute of Electrical and Electronics Engineers (IEEE) defines software engineering as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software (The Joint Task Force on Computing Curricula, 2004).” A software engineer “focuses on the computer as a problem-solving tool (Pfleeger & Atlee, 1998).” In essence, developing a software application is similar in nature to building a puzzle. If some of the pieces are missing, you will end up with a puzzle that is incomplete and virtually useless. However, depending on which pieces are missing, the puzzle could provide some usefulness, and give part of the picture, but you may still be enticed to throw it away. This paper presents acceptable software engineering methods, tools, and procedures. It also presents the issues an organization could face if they are not used. Areas of concern included in the study are as follows: modeling, planning and managing, securing the requirements, design, programming, testing, delivering, maintaining, evaluating, and improvement. Statement of the Problem Proper software engineering methods are required for a high quality software solution. Not using the proper methods could result in software that is low in quality, expensive, hard to maintain, and take longer to build (Software Engineering, 2009). Most universities teach the proper methods to their students, however many organizations do not allow their consistent use due to time constraints and other reasons, and they pay the price for such practice. Sometimes, an organization will see the deadline, and decide that the proper planning and designing will take too much time they could be using for coding. Additionally, there are programmers who feel that proper planning is unnecessary and just busy work. This is often seen in Extreme Programming, where the programmers sometimes try to skip most processes and jump immediately into programming. In essence, they are skipping the essential pieces that would inevitably prevent them from back stepping and reworking. If the organization does not perform proper planning and design, they may miss essential pieces to the solution that could prevent disaster. If they miss enough of the solution, they may have to scrap the entire project and start over. The worst possible outcome could be catastrophic (Glass, 1997). Webster’s dictionary defines catastrophic as “utter failure.” While there are many projects that have ended in failure, the following cases show just how catastrophic a failure can be. FBI Virtual Case File. The Federal Bureau of Investigation needed to bring its software into the 21st century. They needed “a networked system for tracking criminal cases that was designed to replace the bureaus’ antiquated paper files (Eggen & Witte, 2006).” After several years of development, and $170 million, The Federal Bureau of Investigation’s Virtual Case File system was considered incomplete and unusable. It was deemed a failure and ultimately sent to the grand ole project graveyard. Attributed to its failure was “poor conception and muddled execution of the steps needed to make the system work (Eggen & Witte, 2006).” Another issue attributed to the demise of the Virtual Case File project was the open-ended contract with SAIC, with few safeguards. SAIC knew there were issues with the project, but failed to notify the client that the project would not work. They kept collecting payments and forging ahead with the project. After the terrorist attacks in September of 2001, the system became top priority. The FBI moved up deadlines, expanded requirements, and ultimately the costs ballooned (Eggen & Witte, 2006). SAIC should have been experts in the field of software engineering, yet failed in their responsibilities to ensure that the project was successful. The Office of the Inspector General attributed the following reasons to the delay and costs of the Virtual Case File system (Office of the Inspector General, 2007): poorly defined and evolving design requirements contracting weaknesses IT investment management weaknesses lack of an Enterprise Architecture lack of management continuity and oversight unrealistic scheduling of tasks lack of adequate project integration, and inadequate resolution of issues raised in reports Now that the system was scrapped after several years and $170 million, a new system needed to be completed. The new system, called Sentinel, was estimated to run $425 million. Add that to the amount previously spent on the Virtual Case File system, and ultimately, you have a system that cost the FBI nearly $600 million, not to mention delivery of a system that was needed many, many years earlier. If the system had been in place at the time, it is thought that the United States could have prevented the activities of September 11, 2001. Figure 1. September 11, 2001. (Photo obtained from http://delong.typepad.com/images/911.gif) The Ariane 5 rocket (Flight 501) “Ariane 5 ECA is [a] version of the Ariane 5 launcher. It is designed to place payloads weighing up to 9.6 [tons] into geostationary transfer orbit [(or low Earth orbit)] (European Space Agency, 2006).” “On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded (LIONS, 1996).” This disaster was due to an incorrect variable conversion in the software running the rocket. Considered one of the most expensive bugs in history, the Ariane 5 prototype cost US$1 billion to build. The Federal Aviation Administration Advanced Automation System Another huge failure in the history of software development was the Federal Aviation Administration (FAA) Advanced Automation System (AAS). This project was in development for thirteen years before it was realized to be a “train wreck.” It was a $2.6 billion disaster, of which $1.5 billion was considered unsalvageable for future development. “At its peak, the AAS program was costing the government $1 million a day, 2,000 IBM employees, and producing a hundred pages of documentation per line of code.” It was considered “the greatest debacle in the history of organized work (Rosenberg, 2008).” Other Software Development Failures In addition to the above-mentioned disasters, many more can be used to show how disastrous a project can be. For example: The California Department of Motor Vehicle system cost $45 million and was ultimately cancelled (McManus, 1994). The American Airlines CONFIRM Reservation System was cancelled after three and a half years, $125 million, and the use of 500 technical personnel (Confirm Project, 2009). Sydney Water Corp aborted a project midway through, after spending US$32 million due to inadequate planning and specifications, which led to numerous change requests (Charette, Why Software Fails, 2005). Allstate planned to automate all of its office operations in a project projected that was estimated to take five years and cost $8 million. Six years and $15 million later, they set a new deadline and a new budget of $100 million (Glass, 1997). Westpac Banking Corporation decided in 1988 to redefine its information systems. The plan estimated five years and $85 million to complete the project. After 3 years and $150 million, they cancelled the project because there was little to show for it, and eliminated 500 development jobs (Glass, 1997). In the mid-1990’s, Canada decided to create the Canadian Gun Registry to make owners register their guns. The system was estimated to cost $1 million. However, by 2004, it hovered more closely to $750 million and was not operational (Charette, Why Software Fails, 2005). Although not a huge disaster in terms of budget or scheduling time, there is a recent incident worth mentioning pertaining to the U.S Department of Veterans Affairs. Whether by human error, or coding error, (some believe it was a coding error) thousands of veterans were sent letters indicating they had a debilitating and fatal disease. While they did eventually send out letters apologizing for the error, many of the rightfully concerned patients had already gone out and racked up thousands of dollars of unnecessary medical bills to obtain second opinions (Charette, "
Coding"
Error Creates Anxiety Among US Veterans, 2009). Research Question and Subquestions The purpose of this research is to determine the following: 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, this paper addresses the following subquestions: 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? Significance of the Study This case is significant because it shows organizations and software engineers the importance and proper use of methods to develop software and what can happen if they do not make use of available tools. As discussed in the context of the problem, if an organization does not properly plan, design, and test an application, catastrophic disasters can occur. Research Design and Methodology This research is a qualitative in nature case study, using literature review and personal experience. In addition to textbooks, sources will also include newspaper articles, company websites, government papers, and industry publications. The author currently holds a Bachelors of Science degree in Computer Information Systems, and near completion of the Masters of Science degree in Information Systems with an emphasis on Software Engineering Management. Additionally, she has over eighteen years experience with software development in all phases of the process. She has realized that learning is a never-ending process and keeps an open mind to new technologies and methods. Objectives of the Study Based on the findings of this study, organizations are shown the importance of proper procedures to create high quality, inexpensive, maintainable software in a timely manner (Software Engineering, 2009). It also shows the consequences if proper methods are not used. This study covers the main knowledge areas of Software Engineering (SWEBOK, 2004), the software development process, methods and tools that can be used in the software development process, and the consequences of omittance. CHAPTER 2 – LITERATURE REVIEW The secondary research will consist of textbooks, newspaper articles, company websites, and government and industry publications. Most sources agree that software project failure is just a part of life in the development world and we learn from our mistakes. However, there is some disagreement among sources of the actual percentage of successes and failures. Some sources distinguish a difference between failure and challenged projects. Failure is complete failure and ultimate cancellation of the project. The projects that are challenged include projects that run over budget, over schedule, and offer less features than outlined in the requirements specification (The Standish Group, 1994). Software Project Challenges and Failure The Standish Group reports approximately a twenty-four percent failure rate and a forty-four percent challenged rate. Oxford University reports ten percent for failures and seventy-four percent for challenged projects. The article in the Communications of the ACM reported an abandoned rate of only nine percent (Sauer, Gemino, & Reich, 2007). Figure 2. Standish CHAOS Summary (by percent) (Galorath, 2008) In addition to failures, according to information gathered by Galorath (2008), projects averaged between forty-nine and fifty-seven percent of overrun budgets, and between thirty-three and sixty-two percent of projects failed to meet schedules. These projects are considered in the challenged category as set forth by The Standish Group (1994). According to the British Computer Society, failures cost tens of billions of British Pounds in the European Union, and according to the National Institute of Standards and Technology (NIST), software defects cost nearly $60 billion annually (Galorath, 2008). Reasons of Software Project Challenge or Failure Many sources agree that software project failures have a correlation to their size. Sauer, Gemino & Reich (2007) report that as the effort, duration, or team, increases in size, so does the risk of underperformance. The Standish Group agrees that the longer the duration in projects the higher the result in challenge rates (The Standish Group, 1994). While there many reasons for project failure, there is a consensus among the sources as to the basic reasons, which are inadequate requirement specifications, lack of communication, poor design, and unrealistic schedules and budgets. Software Project Success The Standish Group reported that approximately thirty-two percent of projects are considered successful (see Figure 1). Oxford University and the British Computer Society estimated a sixteen percent success rate. The Standish Group (1994) firmly believes that projects that are broken into smaller sub-projects with incremental implementations (otherwise known as iteration development) have a higher success rate. There was one source, Alleman (2009), that claimed he believed the Standish Report to be naïve and flawed, and possibly only used as a marketing ploy. However, of all the sources researched, The Standish Group appears to be the most forgiving in the calculated success rates, as the other sources reported success rates half that of which The Standish Group reported. Conclusion There is no question that all sources agree there are too many software project failures. What they differ in opinion on, is the causes of the failures and the actual percentage of failures and what exactly constitutes a failure. What we can learn from past software project failures are the issues that can be faced, and determine the proper strategies to ensure a better chance at success. CHAPTER 3 – KNOWLEDGE AREAS OF SOFTWARE ENGINEERING According to the IEEE Computer Society, software engineering is defined as “(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software and (2) The study of approaches as in (1) (IEEE Computer Society, 2009)."
In order to understand the processes needed to ensure a successful software development project, it is essential to know the ordinary and typical parts and processes that make up a development project. This chapter covers the processes, or knowledge areas, of a project from its inception to completion. It follows the general layout of the generally accepted knowledge areas required for most development projects as set forth by SWEBOK (2004) with additional information not provided by SWEBOK (2004). The information within this chapter is not all-inclusive. It is important to know that this information should be used in combination with information from all other chapters of this paper. Software Requirements Software requirements are properties that must be exhibited by developed software or adapted to solve a particular problem (SWEBOK, 2004). Software requirements should be written by all stakeholders in a project so that everyone has a clear understanding of what it needed, what is feasible, and what can be delivered within the constraints of the project. Fundamentals. Before specifying the requirements, we must be aware of, and identify, all stakeholders in a project via stakeholder analysis. A stakeholder can be anyone inside or outside an organization that can affect, or be affected, positively or negatively, by the project. For more information on stakeholder analysis, refer to Chapter 5. Requirements are either a product requirement or a process requirement. A product requirement is a requirement within the software application. A process requirement is a constraint on the development. The language needed to program the application is an example of a process requirement. In addition, a requirement may be functional or non-functional. Functional requirements are tasks (or capabilities) that the software must perform, such as calculating payroll or printing paychecks. Non-functional requirements are constraints or quality requirements that must be attached to the software, such as the look and feel of the application (SWEBOK, 2004). Requirements should be cohesive, complete, consistent, correct, current, externally observable, feasible, unambiguous, mandatory and most importantly, verifiable. If a requirement is not verifiable, it must be modified so that it can be verifiable. An example of an unverifiable requirement would be if it states the requirement must always, or never, exhibit a certain property. In this scenario, infinite testing would be required (Requirement, 2009) which is not feasible in any application. Process. While the requirements are initially defined at the beginning of the project, it is a continuous process throughout the lifecycle of the project. Once the initial requirements are created, requirements should go through a change control process known as requirements management or scope management to avoid a vast array of problems that may arise. For example, requirements may be added that were not initially identified. Therefore, scope management will allow for the analysis of such a requirement to determine its impact on the project. Elicitation. Elicitation is the process of obtaining requirements from all stakeholders and other sources in a project and requires good lines of communication. Other terms that may be used to describe this process are "
requirements capture,"
"
requirements discovery,"
and "
requirements acquisition (SWEBOK, 2004)."
Some people may refer to this process as “requirements gathering,” however, this term falsely suggests that the requirements are only collected from the customer. In fact, the requirements may come from sources such as goals (or software objectives), domain knowledge, stakeholders, operational environment, and organizational environment. Upon identification of all sources, elicitation may begin. Elicitation may take the forms of interviews, conceptual modeling, prototype creation, moderated brainstorm meetings, and observation (SWEBOK, 2004). Analysis. Once the requirements have been identified, requirements analysis must be performed. Requirements analysis is the process of detecting and resolving conflicts and ensuring that requirements are within the boundaries of the software application. Any conflicts brought to light by this process can be remedied prior to the start of design and development. Requirements will be classified and prioritized, and determination will be made if the requirement is volatile or stable and to what extent the requirement affects the scope of the project. The requirements will also be allocated to components, which will allow further analysis to take place (SWEBOK, 2004). Additionally, conceptual modeling will aid in the discovery of unforeseen requirements and possible conflicts in the analysis process. Conflicts may arise not only between requirements, but between stakeholders as well. Conflict resolution can analyze the situation and discussions can be made to determine which requirement should take priority. It is possible that there is another way to incorporate certain conflicting requirements so that they do not conflict with each other. Specification. Depending on the size of a given project, it may require one or all of a system definition document, a system requirements specification, a software definition document, and a software requirements specification. Projects that have a scope beyond the software may require all documents, whereas a simple software application may only require the software requirements specification (SWEBOK, 2004). The software requirements specification is usually all that is needed on projects that only require the development of a software package and not additional system requirements like you would find for an airliner. This document will outline all the requirements and their analyses and “provide a realistic basis for estimating product costs, risks and schedules.” It will include a set of use cases, or functional requirements, and non-functional requirements, otherwise known as constraints. This document will also allow an organization to “develop validation and verification plans more productively (SWEBOK, 2004).” Validation and verification. The process of validating ensures that the software engineer understands the requirements for the project and that they describe the software to be developed. Additionally, the requirements must be verified so that they are understandable, consistent, and complete (SWEBOK, 2004). Validation can be performed by reviews and prototyping. Prototyping can be used to validate the developers understanding of the requirements. If the developer is incorrect in any assumptions, the prototype validation will provide a means of feedback to correct his understanding. Software Design “If I can’t picture it, I can’t understand it.” ~ Albert Einstein The software design process consists of the architectural and detailed designs and allows software engineers to provide models that create a roadmap to the application development. Models should depict structural as well as behavioral descriptions and can be function-oriented or object-oriented in nature. Structural descriptions can be accomplished by using such tools as class and object diagrams, component diagrams, deployment diagrams, entity-relationship diagrams, and structure charts. Behavioral descriptions can be depicted via activity diagrams, data flow diagrams, decision tables, flowcharts, sequence diagrams, state-chart diagrams, and pseudocode (SWEBOK, 2004). Architectural designs describe how software is organized into components. Detailed designs describe the specific behavior of the components. In addition to behavior, issues that software design must address are concurrency, event control and handling, component distribution, error and exception handling, fault tolerance, interaction, presentation, and data persistence. In order to maintain a good quality software design, it is important for it to be maintainable, portable, testable, traceable, correct, and robust (SWEBOK, 2004). Software Construction Software construction is accomplished through a “combination of coding, verification, unit testing, integration testing, and debugging.” The main concepts that apply to software construction are to minimize complexity, anticipate change, construct for verification, and maintain standards (SWEBOK, 2004). When maintaining standards, it is important to pick a set of standards and stick to them. Do not use one set of standards for one area of the construction and another set of standards for another area. Typical standards used are those that are put out by IEEE, the ISO, or the Object Management Group. Software Testing Fundamentals. Failures can occur because of many reasons. Requirements may have been unintentionally omitted in the requirements document, there may be requirements that are impossible to implement, the design could be faulty, or the coding could be wrong. The testing process allows the team to locate faults in the system by fault identification, classify them, and correct or remove them (Pfleeger & Atlee, 1998). Many types of faults can occur in a software application. Possible faults that may occur and should be tested for are: algorithmic faults, syntax faults, computation and precision faults, documentation faults, stress or overload faults, capacity or boundary faults, timing or coordination faults, throughput or performance faults, recover faults, hardware and software faults, and standards and procedure faults (Pfleeger & Atlee, 1998). When faults are found, they should be classified. Classification allows the team to identify areas in the design or development processes that may need to be modified to prevent or reduce faults in the future. IBM developed a classification system called orthogonal defect classification. Within this classification process, they identify a fault as either a fault of omission or a fault commission, and place it under the following classifications: function, interface, checking, assignment, timing/serialization, build/package/merge, documentation, or algorithm (Pfleeger & Atlee, 1998). Levels. There are typically three levels of testing, which are unit, integration, and system testing. During unit testing, tests are done on individual software pieces, or components. Integration testing is the tests run to verify the interaction between components. System testing is the tests run on the system as a whole. The following are the objectives of the testing knowledge area as per SWEBOK (2004): Acceptance/qualification testing Installation testing Alpha and beta testing Conformance/Functional/Correctness testing Reliability achievement and evaluation Regression testing Performance testing Stress testing Back-to-back testing Recovery testing Configuration testing Usability testing Techniques. Several testing techniques can be used to test the application. Some are based on the software engineer’s intuition and experience such as ad-hoc and exploratory testing, and some others are specification-based techniques such as equivalence testing, boundary-value analysis, decision tables, finite-state machine-based testing, testing from formal specifications and random testing (SWEBOK, 2004). In addition, there are tools available for the testing process, which are covered in Chapter 6. The control-based technique is another technique that includes control-flow-based criteria, data flow-based criteria, and reference models for code-based testing. Fault-based techniques include error guessing and mutation testing. Usage-based techniques include operational profile and software reliability engineered testing (SWEBOK, 2004). Finally, there are techniques based on the nature of the application such as object-oriented testing, component-based testing, web based testing, GUI testing, testing of concurrent programs, protocol conformance testing, testing of real-time systems, and testing of safety-critical systems (SWEBOK, 2004). In addition to the testing techniques, various test-related measures can be used. Program measurements can be used to determine how many lines of code exist, and if the number of lines coincides with, or exceeds, any code restraints placed on the application. It may be necessary to double check the written code and see if anything can be reduced to simpler terms. Fault types, classification and statistics can be used to determine the frequency of faults occurring in the system and allow strategies to be designed to avoid these faults in the future. Sometimes, based on project limitations, a client may allow a certain percentage of faults to occur, as no software is 100% perfect. Fault density measures allow the team to count the faults in the system so they can attempt to bring the faults below a certain level as indicated by the client. Software Maintenance Upon completion of the software development project, new user requirements will surface, operating environments will change, and defects will be discovered (SWEBOK, 2004), all of which will require maintenance. Maintenance related activities are not unlike development activities. The activities involved in maintenance are analyzing requirements, evaluating design, writing and reviewing code, testing changes, and updating documentation (Pfleeger & Atlee, 1998). Fundamentals. The four types of maintenance are corrective maintenance, adaptive maintenance, perfective maintenance and preventive maintenance. They can be reactive or proactive, and geared toward corrections or enhancements (SWEBOK, 2004). Corrective maintenance is maintenance geared toward fixing bugs and correcting defects. It is a reactive type of maintenance meant for corrections (SWEBOK, 2004) and does not provide new capabilities. Sometimes, the corrective maintenance may just be user interaction, such as manually adjusting the layout for a report. The developer can then later alter the code to print the report properly without user interaction (Pfleeger & Atlee, 1998). Adaptive maintenance is the process of assessing environmental changes and adapting the software with secondary changes (Pfleeger & Atlee, 1998). It is a reactive type of maintenance geared toward making enhancements to the new environment (SWEBOK, 2004) however, it does not incorporate new capabilities. An environmental change can be a change in the operating system or a change in other parts of the system, such as an upgraded payroll system that is tied into the application. Perfective maintenance evaluates and updates the software to improve performance, make enhancements, or provide maintainability. It is a proactive type of maintenance geared toward making enhancements (SWEBOK, 2004) and is not a result of defects. For example, if the code for an application is confusing, it may be rewritten so that it is easier to maintain in the future. Preventive maintenance is the process of detecting and correcting hidden errors before they become operational errors, improving reliability, and providing a gateway for future development and maintainability. It is a proactive type of maintenance meant for corrective measures (SWEBOK, 2004) before they become active defects. Key issues. While maintenance is a necessary process in software development, issues do arise such as technical issues, management issues and maintenance costs. Technical issues consist of limited understanding, testing time and cost, impact analysis, risk assessment, and maintainability (SWEBOK, 2004). Limited understanding is a big issue if the developer was not part of the original development process. He must first familiarize himself with the system before attempting to make any modifications. If the modifications that are needed are code changes, the better the code was documented, the easier it will be for him to understand. In addition to limited understanding, testing can be another big issue. There is a calculation based on the number of changes that need to be made that indicates the number of interfaces that need to be tested. “If a system has m components and we need to change k of them, there are k * (m – k) + k * (k – 1)/2 interfaces to be evaluated for impact and correctness (Gerlich & Denskat, 1994).” Management issues that can be faced are resource use versus benefit achieved, maintaining staffing requirements, process challenges, priorities of management personnel, and low morale. If management feels other projects are higher priority, it will be difficult to get the resources to perform the needed maintenance. Maintenance cost estimations include the money spent during maintenance and lost opportunities for new development. Many organizations use a popular cost estimation method called COCOMO II to calculate the estimated maintenance costs. Software Processes and Product Quality Striving for quality is a number one skill a software engineer must possess. If any process or product is low in quality, the entire development effort, not to mention future efforts, could be in jeopardy. Repeat business will most likely not occur if a client receives a product that is not of high quality within their definition. The client’s expectations of quality should be determined at the same time the requirements are defined. This is important, as quality to a client may depend on trade-offs that are required during the development process, and other reasons. IEEE12207.0-96 defines some quality management processes that not only encourage quality, but aid in finding potential problems. The processes included in this standard are as follows: quality assurance, verification, validation, review, and audit processes (SWEBOK, 2004). When these processes are used, quality is not guaranteed, but a better quality product is more likely. Analysis and Findings While it may seem that there many areas covered within each process, they are essential to the creation of a successful development project. As discussed earlier, if any pieces to the processes are omitted, you may end up with a development project that is riddled with defects, and possibly lead to abandonment. CHAPTER 4 – CAUSES OF CHALLENGED AND FAILED PROJECTS Introduction to Challenged and Failed Projects The term challenged can mean any number of issues, or combination of issues that indicate a project is not a success. Issues that can classify a project as challenged can include going over budget, exceeding the set time schedule, missing functionality or features, missing requirements, bug filled releases, and more. A project failure is one in which aborting the project is the only feasible option. Causes of Challenged and Failed Projects While there are many causes for challenged or failed software development projects, the actual challenge or failure can be attributed to one, or many, of those causes. As you will see, many times, one cause leads to another. Many of the causes covered in this section are widely used in publications pertaining to project failure. Other causes that are covered here are not as widely covered, but are important nonetheless. The following sub-sections detail each cause. Bad project planning. “Because if you have a strong foundation like we have, then you can build or rebuild anything on it. But if you've got a weak foundation you can't build anything”~ Jack Scalia As the quote describes, you must have a good foundation for any project. You cannot build a bridge without a solid foundation, or it will most definitely fall to pieces. Building a software application follows the same theory. The project plan is the foundation from which the development team will build. If the foundation is bad, so will be the project, and it could very well collapse. Bad project planning means the planning and scheduling of the project are not accurate, therefore resulting in incorrect timetables, resource allotments and cost allocations. Bad planning includes everything from not planning at all, to not planning enough, to not updating the plan once it is in place. Many times, bad planning is a result of inexperienced personnel creating the plans, such as customers, marketing personnel, or sales people. Issues typically overlooked are activities that may seem insignificant, such as file setups, test data setups, and more, but when you accumulate enough of those “insignificant” issues, you end up spending valuable time on issues you thought you would be using on another task. Not planning for possible risks can be another issue related to bad planning. Planners do not always plan for possible risks that may be associated to the project or the personnel developing the project. For example, if an employee suddenly fell ill or quit, and that issue is not accounted for during risk management, and hence the planning, you could find yourself behind schedule (McConnell, 2001). In addition to inadequate planning, a plan may not be accurate due to inadequate requirement specifications. If the requirement specifications are missing key pieces to the project, it will not be accounted for in the project plan or the design, and hence the development. Another issue that an organization can face when planning is reusing previous plans or using prepackaged plans. The current project can easily have issues that are not covered in the reused or prepackaged plan (McConnell, 2001). Project managers must also keep the plans up to date. If a plan is not updated frequently, activities can be omitted and milestones missed. If the project is going over budget or getting behind, you may not find out until it is too late to compensate and remedy the situation. Vague objectives. Objectives state what is needed, what the ultimate goal of the project will be, and why it is needed. If the objectives are vague, requirements will not be properly defined, and the system may end up inadequate. With vague objectives, the development team will not know why the project is being done, or what it is meant to do. Because of this, many assumptions may be made during the requirement specification stage, and they might not match what the client initially wanted done, or there will be constant discussions for clarifications. Lack of clear objectives will usually result in development rework, low morale, schedule extensions and additional costs. Inadequate project requirements. Inadequate, ambiguous, and constantly changing project requirements can severely derail a software development project (The Standish Group, 1994). Inadequate requirements can result from confusion over what constitutes a requirement, poor customer involvement, and inexperience. Once the requirements specification has been completed, more requirements can be added, causing what is known as scope creep. If the additional requirements are allowed to be added without scope management process in place, scope creep can occur and cause a project to get uncontrollable and lead to possible disaster (Satzinger, Jackson, & Burd, 2007). Lack of risk management. Risk management is the process of identifying risks, assessing them, and taking steps to reduce them to an acceptable level (Stoneburner, Goguen, & Feringa, 2002). Risk management is an essential part of the software development project. It allows the team to determine the probability and impact of any risks that could affect the project. If risk management is not incorporated into the project, problems can occur and cause severe setbacks to the project and substantial unforeseen costs could be added to the project. The risks that can affect the project are not only risks that can occur during the project such as the illness of a developer, but also the risks that can occur after delivery, such as software hackers and data loss. The former risks can add time and cost to the project, whereas the latter risks can cause damage to the delivered product, damage to the organization using the application, and additional costs to repair. Lack of scope management. Just as the lack of risk management can affect a project, so can the lack of scope management. Scope management is similar in nature to risk management, but deals directly with issues that occur during a software development project as opposed to actual risks. If issues are not managed, the potential could be unexpected extended schedule time and increased costs. Scope management is put into place to reduce scope creep as discussed earlier. Issues that may arise during a project, typically originate from the customer. “A simple attribute addition can affect the database, input forms, output forms, control algorithms, update algorithms, system testing plans and tests, data conversions, system interfaces, and system and user documentation (Satzinger, Jackson, & Burd, 2007).” In addition, without scope management, additions to the project may occur as requests from end-users that are not approved by the sponsor. This may lead to trouble, as the sponsor may not have included the addition in the project requirements for a specific reason. Inadequate project management methodology. Project management methodology is the process, or framework, put into place to guide the project in an organized manner. It is a set of guidelines or principles to keep the project on track. It can consist of an approach, forms, templates, and checklists among other things (Charvat, 2003). A project without a project management methodology, or an inadequate one, put into place will ultimately result in an unorganized development project. Projects need structure and guidance, and without that structure and guidance, milestones can be missed, costs can become unmanageable, and the project can fail. Additionally, there can be inadequate communications between team members, and the wasting of time on purposeless tasks. The project management methodology must also be good for the project. It is possible to choose the wrong methodology for the project, hence resulting in possible disaster. Inadequate development management methodology. Not having an adequate development management methodology is nearly as bad as not having a project management methodology. Typically, in large companies, a project manager may manage several projects at once. To help in this endeavor, there should be in a development management methodology as well. Without a development management methodology, there could be “serious shortfalls in the overall management, administration, execution, standardization, and reporting of projects (Rittinghouse, 2004).” Inadequate quality management. Quality can have different meanings to different people. A development team might qualify quality as having no bugs, whereas a client might qualify quality as having an application that meets their needs. The client may accept a few bugs here and there and still consider it high quality, but if it does not meet their needs, then to them, it is not of high quality. The project manager must be able to communicate with the client to find out exactly how they define quality. If they do not, the quality assurance team may pass an application as bug-free, but of low quality to the client. Poor performance by suppliers of hardware/software. In order to get a project delivered on time, any hardware or software that is purchased from another vendor must be delivered on time, and work as expected. If it is not delivered on time, obviously, delays to the project may occur. If the product does not perform as expected, scheduling extensions may be made to make the products work together. If scheduling delays occur, there could be added costs to the project, not to mention the additional unexpected work that is needed to be done to get the products to work together. Lack of resources. A project must have all the available resources at the proper times. If a resource is not available or assigned to another task, not only will the scheduling be in jeopardy (The Standish Group, 1994), but customer confidence can also be lost. You should never have to explain to a customer that a task is not completed at the proper time because you did not have the resource to do it. Resource allocation should be addressed by making use of resource management and should be addressed at the beginning of the project to allow time to make sure that the resources are available when needed. Lack of user involvement. User involvement is essential to the success of a project. Without user involvement, or insufficient user involvement, the development team is left to do the users responsibilities themselves. Users typically give input on the requirements they need, input on the functions required, and input on the design, design test cases, provide test data, and analyze test results (Hoffman, 2002). If the development team is required to complete the user's portion of the project, not only is it possible that the system will not be delivered as the users expect, but may not function as they expect as well. Another possibility is that the schedule could be extended since the development team is typically resourced to do other tasks while the users perform these tasks. If the schedule is extended, the costs are increased. If the development team is creating the test data, the results could be completely opposite from what the users would expect because the development team does not know, first hand, how the business is run (Hoffman, 2002). Lack of executive support. Executive support is an essential part of developing a new software project. Without executive support, it gets extremely difficult to get the resources the team needs to complete a project. Additionally, resources that the project already has, could possibly be taken away periodically to work on other things that the executives believe are more important. These issues can cause delays to the project, and possibly additional costs due to the delays. Unrealistic expectations. Many times, clients do not have the technological competence to know how long it will take to develop a project. They may have a preconceived idea of how long they believe the project, or certain parts of the project should take. It is up to the project manager and development team to make sure the client completely understands the scope of the project and what is involved to make the project come to life. If the team does not convey this information to the client and make them understand, the client may be disappointed. The client may push to have certain milestones completed by certain dates. If those dates are unreasonable, the development team will be stressed to meet deadlines, and that could be disastrous to the project. When a team is pushed to unreasonable deadlines, they may drop features, skip steps, and ultimately deliver a project that is unsatisfactory, if even usable, to the client. Another example of unrealistic expectations can come into play if the sales person sells features that are obviously not included in the software. The client may be expecting to see a feature in the application that was never meant to be there. The developers are then scrambling to implement features they had no idea they were to be developing. Unrealistic expectations also come into play when the development team tries to please all the users, all the time. The following quote sums it up: “You can please some of the people all the time, and all the people some of the time, but you can’t please all the people all the time”~ John Lydgate Incorrect cost estimation. When estimating costs, it is necessary to account for as much of the expenses associated with the project as possible. Many times, organizations fail to incorporate costs such as software licenses, equipment and other purchases needed for development of the application. Additional unforeseen costs can be incurred due to other issues if not accounted for during risk management such as, extending the schedule, hiring additional personnel, and more. This is also "
one of the major factors in the breakdown of relationships between IT people and their clients (DeWeaver & Gillespie, 1997)."
Project restarts. According to a study done by The Standish Group (2004), restarting a project is one of the major causes of both scheduling and cost extensions. “For every 100 projects that start, there are 94 restarts. This does not mean that 94 of 100 will have one restart, some projects can have several restarts (The Standish Group, 1994).” Restarting a software development project is sometimes the best solution to a project that has gone off-track. If a project has gone off-track, development could continue, but result in a project that fails to meet the requirements of the client. Another option would be to cancel the project. The obvious result of restarting a project is the extension in the schedule, and ultimately additional costs. The later the restart is done, the longer the extension, and the higher the costs. Another type of restart can occur when a project is stopped for some reason, and restarted in the future from the stopping point. Some reasons for this type of restart may be lack of funding, change in leadership at the client location, or any of a number of other reasons. The problem with this type of restart is that the personnel working on the project must re-familiarize themselves with the project and try to get back on track. Technology incompetence. Technology incompetence can cause problems when developing a software application. Sometimes, this means the developers are using a new technology that they have not had much experience using. It could also mean that a developer is inexperienced and somewhat new to developing applications. This results in a learning curve being added to the project, hence extending schedule time. If a developer is technologically inexperienced, it means that he has not learned what works, what does not work, and how to deal with issues that occur in a timely manner. An inexperienced developer may write too much code, hence increasing time needed to accomplish that task. They may not account for potential errors, therefore causing more bugs and errors in the product than would have been there if an experienced programmer had done the coding. If these issues are caught by the quality assurance team, the application goes back to the developer to be fixed. If the quality assurance team does not catch the issues, the application could be delivered with bugs and errors. Either way, the application must be corrected, hence adding time to the schedule. Technology incompetence is not limited to the developers of a software project. If the project manager is not familiar with the technology being used, they may not properly schedule the time needed to develop the project. If the sales person is not familiar with the technology, they may promise a product that cannot be delivered, or a product that will essentially not meet the needs of the client. Insufficient senior staff on the team. Having insufficient, or inexperienced, senior staff on the team can cause turmoil in the development process. With little or no prior experience, it is difficult to know what can go wrong during a project, and may not have the social skills needed to manage a project. The result could be changes in project leadership, possible project staff turnover, scheduling extensions, and increased costs. Poor social skills. Social skills are a necessity to work in teams. Rarely is a software development project initiated, designed, planned, developed and used by only one person. Typically, there are many people involved including executives, users, project management, developers, testers, quality assurance personnel, and more. When working with this many people, social skills are a necessity. Without good social skills, disagreements ensue, arguments flourish, teamwork falls apart, communication is difficult, and the project could possibly suffer a fatality. Remedy Attempts of Challenged Projects. Now that you have a clear understanding of the issues that can be faced when creating a software development project, let us look at the remedies often used when those issues arise (Glass, 1997). Schedule extensions Reduction in scope of project Work overtime Add development staff Reduce quality (less testing, etc) Implementation of better management procedures Change in project manager or team More funds Pressure on suppliers by withholding payment Better development methodologies Pressure on suppliers by threat of litigation Change of technology used on the project Restarting the project Abandoning the project Analysis and Findings When creating a software development project, causality plays a huge role throughout the project. Causality is the relation between a cause and its effect. In the case of creating a software development project, the effect of one cause is typically another cause that will have its own effect that will be the cause to yet another effect. For example, if the requirements specification is supposed to have fifteen functions, but only accounts for ten, the plan will only allot time and resource allocation for the ten functions. When the design is completed for the ten specified functions, the development and testing will include those ten functions. If, at that point, it is discovered that five functions were inadvertently left out, they will need to be added to the requirements specification, the plan and the design. The developers will then need to not only add in the new functions, but also ensure that they work with the functions already created and retest the entire system. As you can see, by omitting a few functions at the beginning of the project, a substantial amount of time has been added since someone will be required to take the time to add the functions to the documentation, the plan and the design. Once those are complete, the developers have to stop what they are doing and go back and add the functions to the application. Then, they need to retest the entire system to make sure the new additions work as intended. CHAPTER 5 – PRACTICES FOR PROJECT SUCCESS Introduction to Best Practices Having a successful project can be a pipe dream. In order to ensure a successful project, there are practices that should be consistently maintained. If done properly, successful project completion is no longer a dream, but a reality. Best Practices Stakeholder Management. Indentifying the stakeholders of a project should be the first task completed. “A stakeholder is anyone who has a vested interest in the project, can be affected by the change initiative that the project represents, or has the power to influence the project.” Chellar (2009) explains, “Failure to understand the stakeholders can kill a project.” Possible stakeholders for a project may include organization owners or partners, department heads, managers, staff, regulatory bodies, suppliers, customers, or competitors (Chellar, 2009). Stakeholder analysis identifies the stakeholders of the project, the importance of each, and what possible role they may play in the project. Since stakeholders can have a negative as well as a positive effect on the project, the analysis can be used to develop strategies to get effective support and reduce obstacles (Management Sciences for Health and the United Nations Children's Fund). It is important to realize the negative stakeholders as well as the positive, because they can create obstacles to the project. For example, the project could possibly create an automated way of doing something that will inevitably lead to corporate downsizing. Those individuals that would be losing their jobs will surely cause obstacles to prevent the application from being successful. The analysis will allow you to identify those obstacles ahead of time, and prepare a strategy in which to deal with them. Proper project planning. Planning the project can make or break the whole project. According to Brown’s (2008) first law of IT physics, “planning is a continuous process, not a one-time event.” A manager cannot simply create the plan and walk away expecting it to go as planned without changes. If the plan is not consistently maintained, milestones will be missed, deliveries will be delayed, and costs could escalate out of control. Project planning encompasses almost all other practices that should ensure a successful project. In addition to the scheduling, planning includes resource planning, communication planning, and risk management. In order to start a plan, objectives, stakeholders (defined earlier), and deliverables must be identified. This portion can be completed via the objectives and requirements documents. Once these items have been identified and analyzed, the project schedule can be initiated. The requirements document will allow the manager to see what tasks need to be done, and schedule them. Project scheduling not only gives the team a roadmap in which to follow, but it should also provide a layout of the tasks that need to be completed, the resources required to complete the tasks, the amount of effort to complete the tasks, and costs associated with each task. For the purpose of this document, we will focus on the scheduling in this section, as other information is covered under the appropriate area elsewhere in this chapter. In the beginning, the schedule will be a high-level overview of the project tasks to be completed. Without detailed requirements, it is difficult, if not impossible, to create a detailed schedule. Once the requirements have been defined and analyzed, a work breakdown structure (WBS) must be completed. The planner will use the tasks from the WBS, assign resources (which may be people, items, tools or services), define critical paths, and more, to create the detailed schedule. In order to create the schedule, dependencies must also be taken into consideration. A dependency occurs when one task is dependent on another task before it can start or finish. There can be four types of dependencies including finish to start, start-to-start, start to finish, and finish-to-finish CITATION Ste09 l 1033 (Stellman & Greene, 2009). Finish to start is a type of dependency where the finish of one task is required before the next task can begin. An example of finish to start is the start of application development is dependent on the finish of the design. The development cannot be started until there is a design in place from which to work. Start to start is a type of dependency where the start of one task is required before the start of another task can occur. Start to finish requires a task to start before another task can finish. Finally, finish to finish is a dependency where the completion of one task is required to complete another task. Once the WBS has been completed, resources assigned and dependencies accounted for, the schedule can be created and costs assigned. There are many popular applications that can be used for project scheduling, which are covered more in detail in Chapter 6. Popular applications will allow outputs such as task lists, cost reports, budget reports, resource reports, Gantt charts and more. The following illustration shows what Microsoft Project 2007 looks like in the typical task view. This illustration shows a Work Breakdown Structure (WBS) on the left and a Gantt chart on the right. Figure 3. Microsoft Project Sample View. The following illustration shows a sample Gantt chart. Figure 4. Sample Gantt Chart (Stellman & Greene, 2009). “Each task is represented by a bar, and the dependencies between tasks are represented by arrows. Each arrow points to either the start or the end of the task, depending on the type of predecessor. The black diamond between tasks D and E is a milestone, or a task with no duration. Milestones are used to show important events in the schedule. The black bar above tasks D and E is a summary task, which shows that these tasks are two subtasks of the same parent task. Summary tasks can contain other summary tasks as subtasks CITATION Ste09 l 1033 (Stellman & Greene, 2009).” In addition to scheduling, project-planning software can also assist in completing cost estimations. Applications such as Microsoft Project allow you to assign salary information to people resources and per task costs to tasks. The application will then allow you to generate cost and budget related reports. Clear objectives. Objectives are part of Scope Management and clear objectives are important to a project. They are brief statements, written in business terms to describe what the project will accomplish. A good way to set objectives is by using the SMART principle, which states that objectives should be Specific, Measurable, Achievable, Realistic, and Time-bound. Webster (1999) gives the following outline as a guide to the questions that should be answered: Why? (Background) Why does the organization need this project? What is the business case? What is the background and history that got you where you are now? What triggered the project at this time? What is the problem/opportunity being addressed? Are there any other related projects running? What? (Scope) How does the organization want to go about it? What is this project to do, and what are the options? What is it not to do? What changes are expected as a result of this project? What return on investment is the organization looking for and how will it be measured? What will the success of this project look like? What other options were considered? What factors of prime importance in reaching this plan of action? What are the deliverables and expectations? How (Project Objectives) How should it be approached? What objectives should be set? What measurable outcomes are foreseen? What will the tangible results be? When is it wanted by? What resources are there? What is the budget? What authority do you have? What are the boundaries and priorities? Who? (The People) Who are the stakeholders and how do you keep them happy? What would those involved like to see happen? What are the political dimensions? Who is in support? Is there anyone against this project succeeding? Where do you need to tread carefully? Has this project been tried before and if so, what was the outcome? Are there any no-go areas? Clear project requirements and analysis. In addition to objectives (defined above), requirements are also a part of Scope Management. Where objectives are brief statement of overall project needs, the requirements are detailed specifications that tell what the new software application will contain. The requirements must be clear and complete. Please refer to APPENDIX A for a sample template of a requirements document. Take note that the requirements document (or software requirement specification) may take many formats, and the attached appendix is only an example. Once the requirements document has been completed, a requirement analysis should be done to ensure that the requirements stated are clear, complete, explicit, and non-conflicting. If this step is not done, there could be conflict and confusion later in the project. Risk management. Risk management is of utmost importance to any project. In risk management, all possible risks are identified and documented prior to the start of the project, but should be done during every phase of the project. Risks can be anything that could cause a negative impact to a project. The process of risk management is to identify the possible risks, analyze them, plan a strategy to take, and track, control, and communicate them to the proper personnel (Higuera, 1996). The main concept behind risk management is prevention and correction. Risks can originate from many sources. They may originate within the application itself, the development team, the customer or their business practices, and even from outside sources such as the government. If, for example, you are developing an accounting module for an application, one of the possible risks that could affect the application would be if the government is planning to increase taxes. Another possible risk that a project could face would be if one of the developers suddenly fell ill and was unavailable as a resource. The first step in identifying possible risks is to identify possible sources of risks. Common sources can be natural threats such as floods, earthquakes and hurricanes. A second common type of threat can be human threats such as unintentional data entry, network attacks, malicious software upload and unauthorized access to confidential information. The third common type of threat could be environmental such as electrical outages or pollution (Stoneburner, Goguen, & Feringa, 2002). Refer to Appendix C for a table of possible types of threats. Once possible threats have been indentified, they should be analyzed not only for possibility (high/medium/low), but also for impact. Impact could be as simple as bad data, or as important as lost revenue, system repair, human injury or damage to an organization’s credibility (Stoneburner, Goguen, & Feringa, 2002). As in an earlier example, if a developer should fall ill, the impact on the project will be loss of a resource and possible schedule extension. Another issue may allow outsiders to access confidential information. Yet another issue may be as simple as an end user entering incorrect data such as a wrong state abbreviation like XX. After the possible threats have been analyzed, strategies must be put into place to ensure the threats are avoided or corrected. Strategies must take into consideration cost to benefit. If the cost outweighs the benefit, the strategy may be to allow the possible risk. In the event of incorrect data entry, validation may be put into place that will only allow correct entry, within reason. For example, while entering a state abbreviation, the application can be set up to allow the user only to select from a list of acceptable states. In the event a developer should fall ill, there can be a backup plan to replace the developer with other personnel if he will be unavailable to the point where the schedule is severely affected. Change control. Just as objectives and requirements are part of Scope Management, so is change control. Change control is extremely important. If it is not implemented, scope creep may occur and the project could get uncontrollable. Any time a change is requested, no matter how small, it should be logged. A decision then needs to be made on the priority of the change (high/medium/low) and what impact the change will have on the project. Is the change something that can easily be added to a section that has not yet been developed? What impact will the change have on other parts of the application? How will the change affect the workload, schedule, resources or budget (Satzinger, Jackson, & Burd, 2007)? Is it possible that the change could be saved and added after delivery as part of a value added upgrade? Please refer to Appendix B for a sample of a Change Request Log. This is only a sample, and may take many forms. Project management methodology. "
A methodology is a set of guidelines or principles that can be tailored and applied to a specific situation (Charvat, 2003)."
The methodology, or framework, is everything that should be done over the lifespan of the project, including steps, procedures, templates, documents, checklists, and more. Some types of formal methodologies that can be adopted are the traditional approach, Critical Chain Project Management (CCPM), Rational Unified Process (RUP), Extreme Project Management, Event Chain Methodology, Agile Project Management, System Development Life Cycle (SDLC), and PRINCE2. The following figure shows a typical SDLC life cycle, however remember that planning should be revisited often and updated, not just once as it appears in the life cycle. Figure 5. Systems Development Life Cycle (SDLC) (U.S. Department of Justice, 2003) As part of project management, the manager can assess the potential success of the project, and implement strategies to ensure a successful project. The Standish Group (1994) created a weighted “success potential” chart that can be used to predict the potential for success of a project. What they have done is taken criteria that have shown success in projects and assigned point values based on importance. If a project has the criteria, the points are assigned. If the project does not have the criteria, it gets zero points for that category. There is the potential of 100 points total and the higher the points a project has, the more the success rate. Areas within the success criteria are covered in other sections of this chapter. Figure 6. Success Potential Chart (The Standish Group, 1994). As you can see, the more points assigned to a project, the better the potential. The California DMV project that was identified in Chapter 1 as a disaster that was cancelled only had 10 points. The Hyatt project (The Standish Group, 1994) was considered a success, and as you can see, had 100 points. The American Airlines CONFIRM project (another covered in Chapter 1 as a failure) with only 29 points, was also cancelled. Banco Itamarati, with a point value of 85, was a successful project and along with other strategic maneuvers allowed them to move from 47th to 15th place in the Brazilian banking industry (The Standish Group, 1994). In addition to predicting success in a project, the project manager can also estimate project performance. Earned Value Analysis (EVA) measures the project performance in terms of scope, time and cost. Before you can make this measurement, Makar (2009) shows there three questions to be answered: How much work did you plan to complete to this point in time (Planned Value or PV)? How much work was actually completed to date (Earned Value or EV)? How much did it cost to complete the work so far (Actual Cost or AC)? For this sample, we will assume the project being worked on is as follows: One year project budgeted at $120,000 Reporting period at 9 months Team has completed 50% of the project (should have completed 75%) Spent $108,000 to date PV = (Planned % Complete) * (Project Budget) = .75 * $120,000 = $90,000 EV = (Actual % Complete) * (Project Budget) = .50 * $120,000 = $60,000 AC = $108,000 The cost and schedule variances are now calculated using the above calculations: Cost Variance (CV) = EV – AC = $60,000 - $108,000 = -$48,000 Schedule Variance (SV) = EV – PV = $60,000 - $90,000 = -$30,000 Since both of these numbers are negative, we can know that we are currently running over budget and behind schedule. Now, we can use these calculations to find the cost performance index (CPI) and the schedule performance index (SPI). If those calculations are less than one, the project is behind schedule, equal to or more than one, the project is on or ahead of schedule. CPI = EV / AC = $60,000 / $108,000 = .56 SPI = EV / PV = $60,000 / $90,000 = .67 Now that we have these numbers, and we know that the project is behind schedule, we can find out approximately how much it will cost to complete the project with a schedule extension by dividing the original budgeted amount by the cost performance index (CPI): EAC = BAC / CPI = $120,000 / .56 = $214,285.71 As you can see from these calculations, at the current rate, we are completing the project, and the current costs, we will end up going over our $120,000 budget by approximately $94,285. With this in mind, we can then make a decision how to proceed. We can either cut back on scope or extend the schedule and accept the budget overrun. Development methodology. A software development methodology is a framework that is used to structure, plan, and control the process of developing an information system (Centers for Medicare and Medicaid Services, 2008). There are several types of development methodologies, many of which crossover and combine with each other. A few can also be considered both development and project management methodologies, such as System Development Life Cycle (SDLC). Examples of development methodologies include Waterfall, Incremental, Spiral, Rapid Application Development (RAD), Agile Software Development, Dynamic Systems Development Model (DSDM), Extreme Programming (XP), Feature Driven Development (FDD), Joint Application Development (JAD), and Lean Development (LD). Quality management. “The main objective of Quality Management is to produce a system that is easy to use, fit for its intended purpose, robust, reliable, and maintainable (Satzinger, Jackson, & Burd, 2007).” Quality control should be performed during all milestones and delivery points of the project. The system must be developed to the purpose as set forth by the client. It should also be easy to understand and learn. Strong help systems should be available within the application and documentation should be available to the end user. Tasks should be easy and efficient to perform, so the least amount of steps needed to perform a certain task should be taken into consideration. A user should not have to click through fifteen totally unrelated screens to perform a typical everyday task (Satzinger, Jackson, & Burd, 2007). Quality management is made of three components, which are control, assurance and improvement. Control ensures products meet the customer’s requirements. Assurance ensures that standards of quality are met by monitoring and evaluation. Improvement is the processes put into place in order to strive to improve from lessons learned. One way improvement can be achieved is by monitoring via assurance. Logs are made and when low quality issues begin to repeat themselves, a strategy is put into place to avoid those issues in the future. For example, if a problem in the Graphical User Interface (GUI) layout is repetitive, the designer can be approached and steps taken to ensure that problem stops appearing. It could be as simple as the designer is unaware of the problem, or that he is aware but does not bother to fix it for whatever reason. Then the problem will be monitored in the future, and if it is found that the designer continues to ignore the problem, he can be dealt with by management. If the problems are severe enough, it may even be time to replace that designer. Quality up front is better than quality after rework, because it simply saves time. Supplier management. Supplier management is important because suppliers must supply their product on time. If suppliers deliver beyond the intended delivery date, it can extend the project scheduling efforts. While there are times when this can be accepted as an exception to the rule, it cannot be a continuous occurrence. One remedy for consistently late deliveries is to change suppliers. Depending on the item being purchased, this may not be an option. There are times when other remedies such as litigation may be the only option. Resource management. Managing resources is an important activity during a project. If a resource is not going to be available during a project or any portion thereof, alternate strategies must be made to ensure the project does not run over schedule. If the manager is using an application such as Microsoft Project, resources can be managed and tracked within the software. Risk management is also related to resource management. Back to our example of a developer falling ill, risk management would have identified that as a possible risk, and the manager should have a backup plan in place. The backup plan could be that the project proceeds in other areas awaiting the developers return, or maybe another resource is used in his place. User involvement. Projects require user involvement. There is really no way around this. Users must be able to lead in the requirements specifications. They are the ones who know what they need and how the business runs. The project team can guide the users, but they do not know the details of the clients business. Users must also lead in the functional requirements of the system. Again, the project team can guide them, but the project team does not know details about the clients business. Partial user involvement is necessary in the technical design of the system as well. What the project team believes to be a nice design may not be appealing to the user at all. Finally, the users must design the test cases to be used to test the system. While the project team can easily come up with their test cases, they do not know the clients business, and therefore may miss something of great importance to the client (Hoffman, 2002). Executive management support. Support from executive management is a necessity. Without it, many times, a project will fail. Say, for example, you need to requisition a new resource because one of your developers was just called to active duty in the military. Without executive support, you may not get the new person for months, and the schedule could suffer terribly because of it. Maybe you need to purchase something for the project and executive management needs to approve it. If you cannot make the purchase, will the project continue? Will it need to be stopped and sent to the great project graveyard in the sky? Realistic expectations. Many users are not technologically competent enough to know what can and cannot be achieved with an application, or the extent of the costs for some wanted features. It is the project team’s responsibility to keep the users informed of the limitations considering the available time, technology, and budget. They may not ask for something that they believe is too difficult to accomplish, but in reality is quite simple. On the other hand, they may ask for something that they believe is easy, but in reality is very difficult and may extend the schedule another year which they have no intention of doing. The project team can explain the difficulty involved if the users ask for something that is not covered in the current state of time and budget criteria. Communication management. Everyone knows, or should know, that communication is the key to success. Whether it is personal, business, or other relationships, without communication, systems can break down. Consider a project as a relationship with your clients, coworkers, and managers. Everyone must be able to communicate to get the job done. If there is a communications process in use, everyone will be familiar with it, and communication will be made much easier. Maybe the organization requires the channel of communication to go through certain people and managers in a certain order. Maybe one person on the team is expecting another person to make a communication that is not in his duties and therefore the issue is never communicated to anyone. Perhaps part of the communications management process is to have a fifteen-minute daily meeting for quick status updates, or an end of the week meeting to see what was accomplished that week, and what will be accomplished the next week. However the project team deals with communication, it should be consistent, and it should work. If it does not work, the team needs to figure out why and made adjustments so that it does work. Competent staff. Without competent staff, a project can easily fail. If the manager does not manage the project, how will anyone know where he or she is in the project, if it is on schedule, if it is meeting requirements, and if it is within budget? Likewise, without a competent developer, how do we know the development process is being done properly before the quality control people check the work? A project simply needs competent personnel in order to attain success. Everyone needs to do their job to the best of their ability, and corrected if it is found they are not. Iteration deliveries. Delivering a project in iterations is good practice. If the project has one huge delivery at the end, possible problems may surface that can cause a lot of rework to be done. It is possible that the project does not meet the user’s needs as they expected. If the project is delivered in iterations, the users can be checking a small portion of the application while developers are still working on another section. If issues arise, corrections can be made much sooner, and possibly avoid a severe extension to the schedule and increased costs. CHAPTER 6 – TOOLS & MODELS Introduction to Tools and Models Many tools can be used to manage, design, and test a project. Some tools go so far as automatically generating code for the application. Many organizations find that by using available tools, development time can be cut down dramatically. Project management software Project management software can not only allow a project manager to set up a project schedule, but also assign resources, predecessors, constraints, percent complete, start and end dates, and more. The output can be very helpful when communicating to the client, other team members or upper management. Output from project management software can typically include PERT charts, Gantt charts, resource charts, baseline reports, budget reports, resource reports, cash flow reports, and more. Project Evaluation and Review Technique (PERT) is a project management model. The lines are typically activities to be performed, and the nodes are milestones (Internet Center for Management and Business Administration, Inc., 2007). The following illustration shows a PERT chart: Figure 7. PERT Chart (Image released to public domain by: Jeremy Kemp, 2005) Gantt charts are visual representations of a project schedule and its work breakdown structure. The following illustration shows the Gantt chart that was introduced in the proper project planning section of Chapter 5: Figure 8. Sample Gantt Chart (Stellman & Greene, 2009). CASE tools A CASE tool is “a computer-aided system engineering tool designed to help a systems analyst complete development tasks (Satzinger, Jackson, & Burd, 2007).” There are several types of CASE tools available such as UML Modeling, Microsoft Visio (not technically a CASE tool, but can be used as one), Visible Analyst, Embarcadero Describe, and a line of Rational software. CASE tools can be considered upper CASE or lower CASE, and are used to support design, debugging, development, testing, maintenance, and implementation activities, among others. Diagrams and other graphical representations There are other common graphical representations used to show how a system should operate. These other representations are flowcharts, data flow diagrams, entity-relationship diagrams, structure charts, use case diagrams, class diagrams, and sequence diagrams. Figure 9. Class Diagram Figure 10. Data Modeling Process Figure 11. Entity Relationship Diagram Testing Tools When the testing process is being performed on the application, there are tools that can be used to aid in the process. Static and dynamic code analysis tools are tools available to report information pertaining to the written code. When the programming is executing, dynamic analysis is done, and static analysis is done when it is not executing. Examples of tools available for static analysis include code analyzers, structure testers, data analyzers, and sequence checkers. An example of a dynamic tool is a program monitor that reports the applications behavior (Pfleeger & Atlee, 1998). In addition to the tools available for testing the actual written code, tools are available for the planning and running of the tests such as capture and replay (or capture and playback) tools, stubs and drivers, automated testing environments, and structured test case generators (Pfleeger & Atlee, 1998). CHAPTER 7 – SUMMARY AND CONCLUSION Summary Surveys show that software development failures occur too often. Based on findings of the surveys, we can see the issues that can ultimately cause such failures. Most of these causes can be directly attributed to certain knowledge areas of software engineering. If we make ourselves experts in those knowledge areas, we can better manage, plan, design, develop, test and maintain our projects. We can also see, from the evidence given, that by not using methods and processes for one knowledge area carries defects or issues into other knowledge areas. Once initiation of the project begins, a plan is created for the project. The requirements are then completed, which leads into the design. Upon completion of the design, the development begins. After the application has been developed, it is then tested, implemented and maintained. At each stage of this process, the plan is consistently updated and maintained in order to keep the development effort on track. If planning is not done, or done inadequately, the whole project could be inaccurately estimated in terms of time, cost, and resource allocation and the team will be unable to detect late or missed milestones. Other issues that can be attributed to challenged and failed projects include: vague objectives, inadequate requirements, lack of risk and scope management, inadequate project or development management, inadequate quality management, poor performance by suppliers, lack of resources or user involvement, lack of executive support, unrealistic expectations, incorrect cost estimation, technology incompetence, insufficient staff, and poor social skills. On the other hand, if the opposite of the above is present in the development process, there is a better chance at success. Better planning leads to better time and cost estimation. Better requirement specifications lead to more complete and correct design and development. Better development leads to a better overall project. If the client is happy with the delivered product, they will return for future efforts. Conclusion “Mistakes are a part of being human. Appreciate your mistakes for what they are: precious life lessons that can only be learned the hard way. Unless it's a fatal mistake, which, at least, others can learn from.” ~ Al Franken Regardless of which studies you look at, the percentage of software development failures and challenges are too high. The purpose of this research project was to determine the activities we can do to ensure a successful delivery of software development projects and avoid failure. To be successful, we must know the knowledge areas of software engineering. We must know the causes of past failures to avoid future failures. We must be familiar with the proper processes, methods, and tools of the various knowledge areas. We can learn from the mistakes we have made, or the mistakes of others. Too many organizations bypass important processes and procedures because they think they will save time. In the end, they do not save time. They do however, go over budget, over time, and end up with a low quality product, if the project even makes it to completion. They can end up reworking parts of the application because they did not take the time up front to ensure the requirements are as complete and correct as possible. They may not have taken the time to design the system properly. Any time a developer needs to go back and rewrite code, it must be retested and documented, and needs to go back through quality control. Additionally, if the developer does not properly document the code as he is writing it, it will be nearly impossible to maintain in the future. If we are to raise the success rate of software projects, we must be sure that all curriculums teach the necessary fundamentals of the knowledge areas. Additionally, organizations must be more proactive and ensure their teams are knowledgeable in software engineering and proven methods. If they are not adequately knowledgeable, it is worth the expense to ensure they are properly taught. The time added to a project by following all proper processes may be irritating or cumbersome to some, but is a necessity in order to complete a successful software development project. REFERENCES BIBLIOGRAPHY Alleman, G. B. (2009, April 29). Standish Report and Naive Statistics. Retrieved July 25, 2009, from Herding Cats: http://herdingcats.typepad.com/my_weblog/2009/04/standish-report-and-poor-statistics.htmlBaltzan, P., & Phillips, A. (2009). Business Driven Information Systems (2nd ed.). The McGraw-Hill Companies, Inc.Brenner, R. (2001, April 25). Restarting Projects. Point Lookout , 1 (17) . Chaco Canyon Consulting.Brown, N. V. (2008). 11 "
Laws of IT Physics"
. Off-Line and Off-Budget: The Dismal State of Federal Information Technology Planning (pp. 8-9). http://hsgac.senate.gov/public/_files/BrownTestimony.pdf.Burd, S. D. (2006). Systems Architecture. Boston, Massachusetts: Thomson.Carnegie Mellon. (2009). Software Engineering Institute. Retrieved July 11, 2009, from Software Engineering Institute: http://www.sei.cmu.edu/CBC News. (2004, February 13). Gun registry cost soars to $2 billion. Retrieved July 30, 2009, from CBC News Canada: http://www.cbc.ca/canada/story/2004/02/13/gunregistry_rdi040213.htmlCenters for Medicare and Medicaid Services. (2008, March 27). Selecting a Development Approach. Retrieved August 10, 2009, from U.S. Department of Health and Human Services: http://www.cms.hhs.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentApproach.pdfCharette, R. (2009, August 26). "
Coding"
Error Creates Anxiety Among US Veterans. Retrieved August 26, 2009, from IEEE Spectrum: Risk Factor: http://spectrum.ieee.org/blog/computing/it/riskfactor/coding-error-creates-anxiety-among-us-veteransCharette, R. (2005, September). Why Software Fails. Retrieved July 30, 2009, from IEEE: Spectrum: http://www.spectrum.ieee.org/computing/software/why-software-failsCharvat, J. (2003). Project Management Methodologies. Hoboken, NJ: John Wiley & Sons, Inc.Chellar, D. (2009, June 25). Who Are Your Stakeholders? Retrieved September 4, 2009, from The Project Management Hut: http://www.pmhut.com/who-are-your-stakeholdersConfirm Project. (2009, July 12). Retrieved July 12, 2009, from Wikipedia, The Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Confirm_Project&oldid=301706064DeWeaver, M. F., & Gillespie, L. C. (1997). Real-world Project Management: New Approaches for Adapting to Change and Uncertainty. New York, NY: Quality Resources.Eggen, D., & Witte, G. (2006, August 18). The FBI's Upgrade That Wasn't: $170 Million Bought an Unusable Computer System. The Washington Post , p. A01.Erdil, K., Finn, E., Keating, K., Meattle, J., Park, S., & Yoon, D. (2003). Software Maintenance As Part of The Software Life Cycle. Tufts University. Department of Computer Science.European Space Agency. (2006, March 12). First Ariane launch of 2006. Retrieved August 10, 2009, from ESA News: http://www.esa.int/esaCP/SEMAJ8MVGJE_index_0.htmlGalorath, D. (2008, June 7). Software Project Failure Costs Billions. Retrieved July 25, 2009, from SEER: http://www.galorath.com/wp/software-project-failure-costs-billions-better-estimation-planning-can-help.phpGerlich, R., & Denskat, U. (1994). A Cost Estimation Model for Maintenance and High Reuse. Proceedings, ESCOM 1994. Ivrea, Italy.Glass, R. L. (1997). Software Runaways: Monumental Software Disasters. Prentice Hall.Haughey, D. (2008). Project Planning: A Step by Step Guide. Retrieved August 10, 2009, from Project Smart: http://www.projectsmart.co.uk/project-planning-step-by-step.htmlHiguera, R. P. (1996). Software Risk Management. Pittsburgh, PA: Carnegie Mellon University.Hoffman, G. (2002, August 8). Why IT Projects Fail: Lack of User Involvement. Retrieved August 10, 2009, from Montana Associated Technology Roundtables: http://www.matr.net/article-4206.htmlIEEE Computer Society. (2009, July 11). IEEE: The world's leading professional association. Retrieved July 11, 2009, from IEEE: The world's leading professional association: http://www.ieee.org/portal/siteIEEE-CS/ACM Joint Task Force. (1999, October). Engineering Code of Ethics. Computer Society Connection , 84-88.Internet Center for Management and Business Administration, Inc. (2007). PERT. Retrieved August 15, 2009, from NetMBA: http://www.netmba.com/operations/project/pert/Johnson, J., Boucher, K. D., Connors, K., & Robinson, J. (2001, February). Collaboration: Development & Management (Collaborating on Project Success). Retrieved July 20, 2009, from SoftwareMAG.com - The IT Software Journal: http://www.softwaremag.com/archive/2001feb/collaborativemgt.htmlLeveson, N. G. (2004). Role of Software in Spacecraft Accidents. Journal of Spacecraft and Rockets 4 .LIONS, P. J. (1996, July 19). ARIANE