The Systems (or Software) Development Life Cycle (SDLC) is a domain of competency used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system. In this article, we would review the various paradigms of SDLC based development approaches which has emerged in the discipline of Systems Analysis and Design.

There are basically three paradigms of Software Development Approaches

The linear approaches

• This takes specific activities and represents them as separate phases such as requirements specification, software, design, implementation, testing and so on.
• After each stage is defined it is `signed-off’., and development goes on to the following stage

Iterative approaches

• This approach interleaves the activities of specification, development & validation
• An initial system is rapidly developed from very abstract specifications.
• This is then refined with specific inputs from the stakeholders to produce a system that satisfies the needs of the stake-holders.

Component-based software development

• This technique assumes that parts of the system already exists and the rest needs to be planned for and designed.
• The system development process focuses on integrating these parts rather than developing them from scratch.
• Components based approaches break down the scope of the large system into modules which are generic and can be reused into other sections of the developed information system.

The Waterfall Model

The Waterefall model is a classic SDLC model, which was first proposed by H.D. Benington at a symposium on advanced programming methods for digital computers in 1956. The original waterfall model has 5 stages: requirements analysis, design, implementation, verification, maintenance.

Strengths of the waterfall model

• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost or schedule

Weaknesses of the waterfall model

• All requirements must be known upfront
• Deliverables created for each phase are considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system (until it may be too late)

V-Shaped SDLC Model

The V-Shaped SDLC Model is an extension of the waterfall model that introduces the added responsibility of defining the criteria for system testing / evaluation during each stage of the system design.

Verification Phases

• Business Requirement Analysis: The product requirements are understood from the customer perspective. The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing.
• System Design: System design would comprise of understanding and detailing the complete hardware and communication setup for the product under development. System test plan is developed based on the system design.
• Architectural Design: Usually more than one technical approach is proposed and based on the technical and financial feasibility the final decision is taken. System design is broken down further into modules taking up different functionality. The data transfer and communication between the internal modules and with other systems is clearly understood and defined in this stage. With this information, integration tests can be designed.
• Module Design: It is important that the design is compatible with the other modules in the system architecture and the other external systems. Unit tests are an essential part of any development process and helps eliminate the maximum faults and errors at a very early stage.

Coding Phase

• The actual coding of the system modules designed in the design phase is taken up in the Coding phase.
• The best suitable programming language is decided based on the system and architectural requirements.
• The coding is performed based on the coding guidelines and standards.
• The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.

Validation Phases

• Unit Testing: Unit tests designed in the module design phase are executed on the code during this validation phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing.
• Integration Testing: Integration testing is associated with the architectural design phase. Integration tests are performed to test the coexistence and communication of the internal modules within the system.
• System Testing: System testing is directly associated with the System design phase. System tests check the entire system functionality and the communication of the system under development with external systems. Most of the compatibility issues can be uncovered here.
• Acceptance Testing: Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. Acceptance tests uncover the compatibility issues with the other systems. It also discovers the non functional issues such as load and performance defects.

Prototyping Approach

Software prototype based approaches fall into the scope of iterative software development paradigms. It focuses on iteratively improving a software prototype with inputs from the stake-holders while fine tuning it.

Strengths of the prototyping approach

• Customers can “see” the requirements as they are being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates awareness of additional needed functionality

Weaknesses of the prototyping approach

• Tendency to abandon structured program development for “code-and-fix” development
• Bad reputation for “quick-and-dirty” methods
• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)

Rapid Application Development

Rapid application development (RAD) was proposed by James Martin’s for rapid development of information systems. In general, the RAD approaches to software development put less emphasis on planning tasks and more emphasis on development. Further, they are somewhat iterative in nature, in how they develop the final system.

Strengths of Rapid Application Development based Approaches

• Reduced cycle time and improved productivity with fewer people means lower costs
• Time-box approach mitigates cost and schedule risk
• Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs
• Focus moves from documentation to code.
• Uses modeling concepts to capture information about business, data, and processes.

Weaknesses of Rapid Application Development based approaches

• Accelerated development process must give quick responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

Evolutionary (Spiral) Model

The Evolutionary (Spiral) Model emphasizes risk analysis, and thus requires customers to accept this analysis and act on it. This requires both trust in the developer as well as the willingness to spend more to fix the issues. If the implementation of risk analysis will greatly affect the profits of the project, the spiral model should not be used. Software developers have to actively look for possible risks, and analyse it accurately for the spiral model to work.

Strengths of the Spiral Model

• Provides early indication of insurmountable risks, without much cost
• Users see the system early because of rapid prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently

Weaknesses of the Spiral Model

• Time spent for evaluating risks too large for small or low-risk projects
• Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development phase activities
• May be hard to define objective, verifiable milestones that indicate readiness to move to the next iteration

The Incremental Model

The incremental model is an approach of systems development where the product is designed, implemented and tested incrementally until the product is finished as per the desired specifications. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the principles of the waterfall model with the iterative philosophy of prototyping.

Strengths of incremental approaches to system development

• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced

Weaknesses of incremental approaches to system development

• Requires good planning and design
• Requires early definition of a complete and fully functional system to allow for the definition of increments
• Well-defined module interfaces are required (some will be developed long before others)
• Total cost of the complete system is not lowered
• Requires high coordination cost during integration

Component Based Software Development

Component based software development emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems.  It also aims to bring about an equally wide-ranging degree of benefits in both the short-term scenario and the long-term scenario for the software itself and for the organization.

Practitioners regard components as part of the starting platform for service-orientation. Components play this role, for example, in web services, and more recently, in service-oriented architectures (SOA). In this approach, component is converted by the web service into a service and subsequently inherits further characteristics beyond that of an ordinary component.

These are the major approaches for system development based on the variants of Software Development Life Cycle. Each of these approaches have their own suitability to problem specific system development, based on its strengths and weaknesses.

• Research