Accumulative software development

In order to design and develop effective information systems, a number of software development methodologies have been proposed in the past and several attempts have been made to compare these methodologies to find out the best fit for a specific software development project so that improvements in software reliability could be achieved in view of the growing size and complexity and difficulties experienced in stringent requirements. However, in spite of the evolution of many software development life cycle models and the stated efforts to find the best fit, software projects failure rate is still looming large if compared to the software failure rate of over a decade ago. From the research studies of the Standish Group conducted during 1995, it showed that 31% of projects are cancelled before completion and that 53% incur cost exceeding 189% of their original estimates (Arthur and Nance, 2000) while according to the same Standish Group survey conducted during 2004 showed that only 29% of software projects produced acceptable results that were delivered close to on-time and on-budget, 53% were challenged (overbudget and schedule), and 18% failed to deliver any usable result (Masticola, 2007). According to Taylor & Hoek (2007), the challenges for software design toady, at a suitably abstract level, are still the same as they were forty years ago.
Nevertheless, with the advent of new methodologies, considerable progress has been made, yet there is a need to implement and integrate the existing life cycle models with such a process model that should render the software specifications 100% complete with inherent ambiguities and discrepancies successfully removed. The most common factors of software project failure are linked directly to the quality of the requirements (Mikulovic & Heiss, 2006). Effectively managing the requirements inconsistency is the key to the development of complex reliable software system. There has been lot of work on detection of requirements inconsistency treating it according to heuristic rules, and as such we still lack of promising method for managing requirements properly (Zhu & Jin, 2005). The inconsistencies may occur during any stage of the project which includes application and to software requirements specification, design to different kinds of code, software implementation, system integration and validation, test plans and test cases, analysis criteria and results, and documentation. Most of the time it is too late to resolve inconsistencies when the project is maturing that involves additional cost and time and still the certainty of successful resolution is not predictable.
Existing software process models do not provide enough insight into actual development process to guide research on software development technologies (Curtis, Klasner, & Iscoe, N., 1988). The real issue is that if a model does not represent the processes that control the largest share of the variability in software development, then it is not helpful in boosting productivity and quality. Different literatures have reveled that waterfall and related models of software process are inadequate for describing what really occurs in software development (Curtis et al., 1987).

Leave a Reply

Your email address will not be published. Required fields are marked *