A brief comparison of SDLC Models

INTRODUCTION

Since five decades, software has gradually evolved from a tool used for evaluating data on or unraveling a problem to a product in itself.  Software development life cycle provides a framework, recognizing the necessary terminology, activities and procedures for an effective software development in a cost-efficient way to all stakeholders. SDLC provides disciplined methodology for project planning, analysis, design, implementation, scheduling, maintenance and control. SDLC focus on integrating all these activities and reducing risk by coordination and management in appropriate decision making. Each model follows a different approach with unique focus and is not suitable for all kinds of projects (Beynon et al, 2004). Models may be required to provide a standardized tested approach throughout an organization, with a better end product of the development process along with better management and control of development process (Avison et al., 1990).  In general, all SDLC models have the common focus of identifying the steps and procedures since the inception of software project till its completion. Keeping in view this trend, a number of life cycle models/methodologies for developing software are available. Evolving as new technology, SDLC models have been researched widely and new models generated considering the weaknesses of older models.

LIFE CYCLE MODEL COMPARISON

SDLC models are generally classified as heavyweight and lightweight methodologies adopting sequential, iterative and agile approach respectively. Classical software development with focus on detailed planning, documentation and design comes under heavyweight. Waterfall, Iterative and spiral are few examples. Newly developed lightweight models focus on short iterative cycles with minimum documentation to give better end product in shortest time. According to Sommerville (1999), Waterfall, Iterative Development and Spiral are the backbone of most of software lifecycle models. Though a number of hybrids of the basic models exist, presently six of them are predominant in practice.

WATERFALL MODEL

This classical software engineering model is regarded as basic foundation for all models for controlling process of software development. Defined by Royce (1970), it was later refined by Boehm (1976). This linear structure model provides highly structured formal analysis and design and developmental process.

  

Fig. 1 Waterfall model

Figure 1 shows the distinct and cascading nature of waterfall model. Each phase is dependent on previous phase. In modified waterfall model, end phase may overlap with beginning of other phase giving parallel operations. Waterfall model works well for problems when requirements are stable and methodology is well understood.

ADVANTAGES

·         Well documented making it imperative for quality conscious projects.

·         With highly documented and structured system, it is easy to understand requiring no special skills.

·         Phases with well defined goals easily correspond with project management phases.

·         Details can be addressed with more engineering effort if software is large or complex.

DISADVANTAGES

·         Being non iterative is its biggest disadvantage. With fixed requirements which are gathered at initial stage, final product is obsolete as it normally don’t cater to the changing requirements.

·         Being rigid, implementing changes is very difficult in development process. All risks must be dealt with in a single software development effort.

·         Because the model is sequential, late delivery delays serious error discovery as feedback is provided only at the transition between phases.

·         Progress and success are not observable until the later stages. If a mistake or deficiency exists in the documentation of earlier phases, it may not be discovered until the product is delivered.

·         Corrections must often wait for the maintenance phase.

·         High administrative overhead cost and high documentation makes it difficult and expensive to repeat phases.

·         User’s feedback is not considered during development. Late availability of final product leads to late user review.

APPLICATION

·         This model is successful in case of well defined, well understood and non changing requirements over the project life.

·         Project risks could be high for complex and long duration projects.

·         Being bureaucratic in strategy, it is best suited for companies and government projects which are supported with high duration, budget and manpower.

ITERATIVE

This Evolutionary model also focuses on distinct and cascading software development phases. Iteration in increments is basic rule of thumb. Each iteration of this model is actually a mini waterfall model where feedback of one phase helps in developing next phase adding new functionality. This iterative process starts with requirement stage, then design followed by implementation. Iterative development of each phase is undertaken in distinct increments on the basis of requirements, user feedback and other analysis tools. Several iterations might be required before the project is complete. Larmen and Rational Unified process (RUP) are two sample models.

Fig. 2: Iterative Model

ADVANTAGES

·         Suitable for large project which support incremental development and delivery in modules.

·         Risk involved in project reduces due to greater customer feedback which keeps developers focused.

·         High involvement of all team members helps in planning better quality control and assessment.

·         Incorporates stable and better understood requirements in each increment.

·         Requirements modification and addition is allowed.

·         More responsive and consumer oriented than the waterfall model.

·         A working product is available with the first phase and improvements and more functionality can be added in later stages, though project can be stopped at any stage with usable product as end product.

·         Multiple cycles reduces project risk.

·         Requires less manpower than the waterfall model.

·         Project management, testing is easier for these small incremental projects giving high investment return.

·         Gives time to customer to adapt to the final product.

DISADVANTAGES

·         Knowledge of most of the requirements is imperative in the beginning.

·         Requires well defined module interfaces during project start to cover the whole development.

·         Each product deployment needs specific user training.

APPLICATION

·         It is good for projects with known requirements at the inception and which requires functional output early in the project.

·         Beneficial for projects with no fixed funding as each cycle provides a working system.

·          Advantageous for projects involving low to medium-risk. Spreading the development over many cycles reduces the potential risks to a more manageable level.

SPIRAL

Proposed in 1987 by Barry Boehm, spiral model is popular evolutionary model for large projects. Being risk driven (Boehm, 1987; Boehm et al., 1998) it applies prototyping to software process analysis for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer, 1983). It is also represents waterfall model where each of its phases precedes a risk analysis phase. A software project undergoes repeated iterations in spiral model consisting of four phases: Planning, Risk Analysis, Engineering and Evaluation. Expanding spirals denotes iterative development cycles, inner cycles denote early system analysis and prototyping and outer cycles denoting the classic software life cycle Project progress is represented by the angular component while the radius of the spiral represents cost.

Fig. 3: Spiral Model

ADVANTAGES

·         Project risks are progressively resolved in this model starting with the highest risk.

·         A version of end product is available early to consumers in life cycle.

·         Regular consumer feedback results in a good quality product.

·         Implements techniques like prototyping, component based design and reuse along with high risk analysis.

·         Beneficial for big & complex projects.

DISADVANTAGES

·         Requires excellent risk and project management skills.

·         Not beneficial for small projects with low cost which may be less than cost of risk analysis.

·         Considered a complex model involving different specific expertise and high cost.

·         Risk analysis determines the successful completion of project.

APPLICATION

Normally applicable for large scale projects involving risks ranging from medium to high. It is beneficial in case of complex and new startup projects.

RAD (RAPID APPLICATIONS DEVELOPMENT)

Proposed by IBM in 1980 and later by James Martin, RAD models are time driven unlike other requirement driven models. Failure of well documented traditional models along with need for faster and low cost model has led to its evolution. Implementing prototypes along with time boxing, they produces better end product incorporating better user feedback.

Fig. 4: RAD Model

ADVANTAGES

·         Being people oriented and involving regular feedback from initial phases, end products reflect consumer satisfaction.

·         Reduced development cycle time due to application and involvement of various powerful development tools.

·         Decreased cycle time due to reusable components.

·         Less manpower results in less cost.

DISADVANTAGES

·         Requires skilled and expert manpower involving various tools and development techniques like prototypes.

·         Developers must work closely with users in order to produce output in specific time period.

·         Requires extensive committed customer collaboration.

·         Prone to fall back in absence of proper requirements analysis, design, customer evaluation and feedback.

APPLICATION

It is beneficial for project with known requirements and involving short & fixed development time. Normally appropriate for development projects which can divided into modules involving reusable components with minimum changes.

AGILE/EXTREME

Developed in 1990, agile models represent family of various lightweight models. Adaptive Software Development (ASD), Agile Modeling, Crystal Methods, Dynamic System Development, Scrum and XP are some examples. Instead of focusing on heavy documentation, these models being people oriented focus on customer satisfaction and communications at all levels during project development. It is also time driven model rather than requirement driven. These models work with the common goal of providing software as output at end of each timebox. Each iterative timebox acts as a mini project incorporating planning, requirements, design, coding, testing, and documentation in sequential or parallel processing. Agile models conform to business values rather than project plans, working as empirical process providing better flexibility and planning. The extreme programming (XP) process can be distinguished by small development teams working in incremental cycles with regular feedback and knowledge sharing. In order to produce high quality software products based on customer requirements, team members are prescribed practices on daily basis under extreme programming model. XP assumes that there is always a chance to improve. Welcoming variation in requirements with increase in understanding makes them an adaptive model. Success of any project development depends on five extreme values: communication, simplicity, feedback, courage, and respect. All agile/extreme models are characterized by incremental development with frequent system release incorporating regular customer feedback.

Fig. 5: Agile/Extreme Model

ADVANTAGES

·         Better applicable to small-medium size projects.

·         Involves better team involvements.

·         It introduces techniques such as Iterative, incremental development, Prototyping, Requirements prioritization which result in parallel development and less chances of failures.

·         Provides fast delivery under fixed budget.

·         Active involvement of users makes the final output fit for purpose.

DISADVANTAGES

·         Since more emphasis is given to speedy development, a considerable amount of the new system’s potential functionality is at risk of sacrifice.

·         Agile models emphasis on measuring project success in terms of business values may sometimes neglect technical aspects. Loopholes in iterative development give scope to hackers.

·         Management of total project may pose a problem involvement of large number of stakeholders. Changing requirements throughout the project may give rise to poor documentation.

·         Improper incorporation of prototype technique can induce delays in project and unwanted expectations from final delivery leading to decommissioning or restart of project.

APPLICATION

·         Not suitable for computationally complex system with fixed specified requirements.

·         A lot of importance is given to active user involvement in a restricted time frame; it is best suited for development of new products.

·         It is an iterative method working in incremental steps which may be the reason for not having detailed structured plan at start of project lifecycle.

SUMMARY

Today, vast number of models exists, differing in terms of their inputs, outputs, requirements as well as in their respective approaches, processes, tools and techniques. After the initial decision to software development, the right selection of model determines the nature of the systems development process. Heavyweight models consisting of waterfall, iterative and spiral models are process and tool oriented models following predictive approach involving comprehensive documentation. Lightweight agile model are people oriented models following decentralized approach making them adaptive to changes thus conforming to actual results.

Features		Lightweight Models	Heavyweight Models
Approach	Adaptive		Predictive
Success Measurement	Business Value		Conformation to plan
Project size	Small		Large
Management Style	Decentralized		Autocratic
Perspective to Change	Change Adaptability		Change Sustainability
Culture	Leadership-Collaboration		Command-Control
Documentation	Low		Heavy
Emphasis	People-Oriented		Process-Oriented
Cycles	Numerous		Limited
Domain	Unpredictable/Exploratory		Predictable
Upfront Planning	Minimal		Comprehensive
Return on Investment	Early in Project		End of Project
Team Size	Small/Creative		Large

REFRENCES

·         Beynon, P., Owens, D. & Williams, M. (2004). “Information systems evaluation and the

information systems development process”. Journal of Enterprise Information Management, 17 (4), 276-282.

·         Avison, D.E. (1990) ‘An Overview of Information Systems Development Methodologies’, in R.L. Flood, M.C. Jackson, & P. Keys (Eds.) Systems Prospects: The Next Ten Years of Systems Research, Plenum Press, New York.

·         Somerville, I. Software Engineering (7th. Edition), Addison-Wesley, Menlo Park, CA, 1999.

·         Royce, W. W., Managing the Development of Large Software Systems, Proc. 9th. Intern. Conf. Software Engineering, IEEE Computer Society, 1987, 328-338 Originally published in Proc. WESCON, 1970.

·         Boehm, B, W, ‘A spiral model of software development and enhancement’, IEEE Computer, Vol.1, Issue 5, pp. 61-72. 1988

·         Balzer, R., T. Cheatham, and C. Green, Software Technology in the 1990's: Using a New

            Paradigm, Computer, 16, 11, 39-46, 1983.

•   J. A. Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Addison Wesley 2000.