International Journal of Scientific & Engineering Research Volume 2, Issue 2, February-2011 1
ISSN 2229-5518
Software Process Models and Analysis on
Failure of Software Development Projects
Rupinder Kaur, Dr. Jyotsna Sengupta
Abstract— The software process model consists of a set of activities undertaken to design, develop and maintain software systems. A variety of software process models have been designed to structure, describe and prescribe the software development process. The software process models play a very important role in software development, so it forms the core of the software product. Software project failure is often devastating to an organization. Schedule slips, buggy releases and missing features can mean the end of the project or even financial ruin for a company. Oddly, there is disagreement over what it means for a project to fail. In this paper, discussion is done on current process models and analysis on failure of software development, which shows the need of new research.
Index Terms— process model, software failure rate, project failure, software development.
—————————— • ——————————
any software development models are described in the software engineering, which describes the states through which software evolves. The life-
cycle focuses on the product, defining the state through which a product passes from when it starts to be built to when software enters into operations and finally retired [14]. A software process model is an abstract representa- tion of the architecture, design or definition of the soft- ware process [15].
In software development, process models are imple- mented to manage various concerns associated with cost, time, and quality and changing requirements of client’s etc. The particular life cycle model can significantly affect various concerns associated with a software product. If the process is weak, the end product certainly will suffer. Enough effort has been done in this field; still ever chang- ing requirement during the development process for large software development is still not managed by soft- ware process models, which results in software projects not meeting their expectation in terms of functionality, cost and delivery schedule.
The reason of failure can be project team, suppliers, cus- tomers and other stakeholders, but the most common reasons for project failure are rooted in the project man- agement process itself and the aligning of IT with organi- zational cultures [7].
The identified estimation mistakes, unclear project goals and objectives, and project requirement changing during the project are some key factors in project failures.
The remainder of the paper is organized as follows: Sec- tion 2 discuss existing models and techniques, Section 3 presents the analysis on failure of software developments, which shows that new research is required in this field. In Section 4 the conclusion is done.
Developing and maintaining software systems involves a variety of highly interrelated activities. In order to man- age these structured set of activities various models have been developed over the years with varying degree of success. These include Waterfall model, Iterative devel- opment, Prototyping, Spiral model, RAD. Each product can pass through different states, depending on the spe- cific circumstances of each project and hence, there are different development models. For example, if the prob- lem is well defined and well understood and user need is practically invariable, a short waterfall-like life cycle is likely to be sufficient. The Waterfall Model was widely used because it formalized certain elementary process control requirements. However, when we come up against a poorly defined and understood problem and a highly volatile user need, we can hardly expect to output a full requirements specification at the start. In this case, we have to opt for longer and more complex life cycles, like the Spiral Model [2].
Each cycle in Spiral Model addresses the development of the software product at a further level of detail. In the course of several papers, Boehm and his colleagues ex- tended the spiral model to a variant called the Win–Win Spiral Model [2], [3], [4]. The win–win stakeholder ap- proach is used to determine three critical project miles- tones that together anchor the development of the project: namely, life-cycle objectives, life-cycle architectures, and initial operational capability [1]. Prototyping Model helps to understand uncertain requirements but leads to false expectations and poorly designed system. A popular var- iation of the Prototyping Model is called Rapid Applica- tion Development (RAD). This model introduces firm time limits on each development phase and relies heavily on rapid application tools which allow for quick devel-
IJSER © 2011 http://www.ijser.org
International Journal of Scientific & Engineering Research Volume 2, Issue 2, February-2011 2
ISSN 2229-5518
opment [9]. Exploratory model use the prototyping as a technique for gathering requirements and was very sim- ple in its construction but is limited with high level lan- guage for rapid development. This model works best in situations where few, or none, of the system or product requirements are known in detail ahead of time. This model is largely based on educated guesswork. This scheme is not particularly cost-effective and sometimes results in less-than-optimal systems, so it should be used only when no viable alternative seems to exist.
Agile process model give less stress on analysis and de- sign. Implementation begins much early in the life cycle of the software development. This process model de- mands fixed time. Extreme Programming (XP) was created by Kent Beck during software development, and is based on iterative enhancement model. Like other agile software development, XP attempts to reduce the cost of change by having multiple short development cycles, rather than one long one. It only works on teams of twelve or fewer people [11]. Industrial Extreme Pro- gramming (IXP) was introduced as an evolution of XP. It is intended to bring the ability to work in large and dis- tributed teams. It then supported flexible values [10]. There is not enough data to prove its usability.
These days, majority of the software development project involve some level of reuse of existing artifact like design or code modules. The component-based development (CBD) model incorporates many of the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software [12]. The component-based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits. The unified software de- velopment process is representative of a number of com- ponent-based development models that have been pro- posed. Using a combination of iterative and incremental development, the unified process defines the function of the system by applying a scenario-based approach [8].The concentration is on object oriented development.
The evolution of software development Process Models
has reflected the changing needs of software customers.
As customers demanded faster results, more involvement
in the development process and the inclusion of measures
to determine risk and effectiveness and the methods for
developing systems changed. Before requirements can be finalized we must understand the domain. According to Dines Bjorner, it is not possible to develop software with- out understanding its domain [6]. These rapid and nu- merous changes in the system development environment simultaneously spawned the development of more prac- tical new Process Models and the demise of older models that were no longer useful [13].
Software projects fail when they do not meet the criteria for success. Most of the IT projects run over budget or are terminated prematurely and those that reach completion often fall far short of meeting user expectations and busi- ness performance goals.
Here we discuss various reports on failure of software product, projected by Dan Galorath [5].There is several updates to the Standish “Chaos” reports. The 2004 report shows:
• Successful Projects: 29%
• Challenged Projects: 53%
• Failed Projects: 18%
Standish Findings By
Year Updated for 2009:
1994 1996 1998 2000 2002 2004 2009
Succeeded 16% 27% 26% 28% 34% 29% 32% Failed 31% 40% 28% 23% 15% 18% 24% Challenged53% 33% 46% 49% 51% 53% 44%
• 62% of organizations experienced IT projects that failed to meet their schedules.
• 49% suffered from budget overruns.
• 47% had higher-than-expected maintenance costs.
• 41% failed to deliver the expected business value and ROI.
• 33% file to perform against expectations.
• 66% of failure due to system specification.
• 51% due requirement understanding.
• 49% due to technology selection.
• 57% of contracts experienced cost overruns.
• 33% of contracts suffered major delays.
• 30% of contracts were terminated.
• 12.5% of Strategic Service Delivery Partnerships
have failed.
IJSER © 2011 http://www.ijser.org
International Journal of Scientific & Engineering Research Volume 2, Issue 2, February-2011 3
ISSN 2229-5518
On average, about 70 % of all IT-related projects fail to meet their objectives.
From Bob Lawhorn presentation on software failure
(March 2010)
• Poorly defined applications (miscommunication between business and IT) contribute to a 66% project failure rate, costing U.S. businesses at least
$30 billion every year (Forrester Research)
• 60% – 80% of project failures can be attributed di- rectly to poor requirements gathering, analysis,
and management (Meta Group)
• 50% are rolled back out of production (Gartner)
• 40% of problems are found by end users (Gartner)
• 25% – 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
• Up to 80% of budgets are consumed fixing self- inflicted problems (Dynamic Markets Limited 2007
Study)
The three major key factor of project success are delivered on time, on or under budget, the system works as needed. Few projects achieve all three. Many more are delivered which fail on one or more of these criteria, and a substan- tial number are cancelled having failed badly. They are number of software projects that succeeded or failed. So are the key factors for success of a project is based on only these three criteria? They is no one factor that cause the failure of project, a number of factors are involved. Some of the most vital reasons for failure are as follows:
Extracting requirements of a desired software product is the first task in creating it. Sometimes the goal of a project may be only partially clear due to a poor requirement gathering in the definition stage of a project. Many pro- jects have high level, vague and generally unhelpful re- quirements. This leads the developers having no input from the user and build what they believe is required, without having any real knowledge of the business for which the project is being developed. Inevitably when the system is delivered, user declares, it does not do what they needed it to. Defining clear requirements for a pro- ject can take time and lots of communication, but some- times goals and objectives might be unclear because pro- ject sponsors lack the experience to describe what they really require. User should know what they require from the project and be able to specify it clearly. However as user is non-IT specialist, developer must extracting re-
quirements from the user through his/her skills and ex- perience in software engineering.
The research companies and academic institution has fo- cused on the lack of executive support and user involve- ment as two main difficulties in managing IT projects. Lack of user involvement has proved fatal for many projects. Without user involvement nobody in the busi- ness feels committed to a system and can even be hostile to it. One of the criteria, of the software project success depends on user involved from the start of the project and continuously throughout the development. This re- quires time and effort from user end, which is often not done as finding time for a new project is not high on their priorities. User needs to continuously support the project. The developer must involve the user, as it helps in re- quirements elicitation and delivering all functionality of the project.
Proper team size is essential in software development project. Basically there are three different project team sizes: small team of 10 or fewer people for small project, medium size team of 11 to 25 people for medium project and large team of 26 or more for large project. Small group of team results in good communication and tends to be very flexible over large group of teams. It is easy to call meetings and get instant feedback. Projects some- times fail due to improper communication.
Time dimension is important in software development, it is beneficial to deliver project on given time schedule. So given time should be appropriately well thought-out. The time on task is the time the task will take to complete without interruptions, whereas duration is the time the task actually take to complete including interruptions. Using the time on task to estimate schedule is one of the common mistakes made by project managers. Long time- scales for a project, led the project to fail and no longer is required by an organisation. The key recommendation is that project time dimension should be short.
It is not realistic to expect no change in requirements while a system is being built. As an environment con- straints and client requirement keep on changing, devel- oper must follow component driven approach while building the system. The new requirements or modifica- tions can be taken care separately till these components match with the current development process. However
IJSER © 2011 http://www.ijser.org
International Journal of Scientific & Engineering Research Volume 2, Issue 2, February-2011 4
ISSN 2229-5518
uncontrolled changes play havoc with the system under development and have cause many project failures.
3.6 Testing
A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Devel- oper do testing of software product during development but eventually the user must run the acceptance testing to see if the system meets the business requirement. Often acceptance testing fails to catch many faults before system goes live, as it may be due to unplanned testing, inade- quately trained user who do not known the purpose of testing and inadequate time to perform testing as the project is late.
Periodic quality evaluation and appropriate prevention & removal measures are mandatory if the quality of the de- liverable needs to be as desired. Examples of defect re- moval activities include requirements review, design re- view, code review and different kinds of testing.
This paper makes an attempt to study variety of software process models and analysis various issues in software development projects. Discussion is done on various re- ports, which exhibit the failure of software product. Projects run over budget or are terminated prematurely and those that reach completion often fall far short of meeting user expectations and business functionalities. Few vital factors are discussed that cause the failure of projects. These factors are not the only one that affect the success or failure of a project, but they are among the near or the top of the list. This study shows the need to devel- op a new approach, model or techniques to resolve the major issues of software development.
project can”, Baseline, Volume 1, Issue 26, pp 28, 2004.
[8] I. Jacobson, G. Booch, and J. Rumbaugh, “The Unified Software Devel- opment Process”, Addison-Wesley, 1999.
[9] J. Martin, “Rapid Application Development”, Prentice-Hall Publication,
1991.
[10] Joshua Kerievsky, “Industrial XP: Making XP Work in Large Organiza- tions”, vol. 6, issue 2, Cutter Consortium Agile Product and Project Management.
[11] Kent Beck, “Extreme Programming Explain: Embrace Change”, Addi- son-Wesley, First Edition-1999, Second Edition- 2004.
[12] O.Nierstrasz, S. Gibbs, and D. Tsichritzis, “Component-Oriented Soft- ware Development,” CACM, vol. 35, no. 9, pp. 160–165, September
1992.
[13] Survey of System Development Process Models CTG.MFA -003, Center for Technology in Government 1998, University at Albany.
[14] Walt Scacchi, “Process Models in Software Engineering”, Institute for
Software Research, University of California, Irvine, October, 2001.
[15] Watts S. Humphrey and Marc I. Kellner, “Software Process Modeling: Principles of Entity Process Models”, Technical Report, New York: ACM Press, pp. 331-342, February 1989.
[1] Barry Boehm, “Anchoring the Software Process”, IEEE Transaction on
Software Engineering, pp. 79-82, July 1996.
[2] B.Boehm, “A Sprial Model of Software Development and Enhance- ment”, IEEE Computer, Volume 21, Issue 5, pp. 61-72, 1988.
[3] B.Boehm and D.Port, “Escaping the software tar pit: model clashes and
how to avoid them”, Software Engineering Note, Volume 24, Issue 1, pp. 36-48, 1999.
[4] B.Boehm and P.Bose, “A Collaborative Spiral Software Process Model
Based on Theory W.Processing of ICSP”, 3, New York: IEEE Press,
1994.
[5] Dan Galorath, “Software Project Failure Costs Billions-Better Estimation
& Planning Can Help”, June 7, 2008.
[6] Dines Bjørner, “Role of Software Engineering in Software Develop- ment: Why Current Requirements Engineering is Flawed”, Springer, Scotland, October 2009.
[7] George Tilmann and Joshua Weinberger, “Technology never fails, but
IJSER © 2011 http://www.ijser.org