SDLC Models | Software Development Life Cycle Models by Learntek

SDLC MODELS

About SDLC Models Software Development Life Cycle ( also called SDLC Models ) is a workflow process which defines the core stages and activities of development cycles or A framework that describes the operations performed at each phase of a software development project.

SDLC Models The SDLC aims to produce high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

1) Waterfall Model •It is one of the oldest and most well-known SDLC models •It follows a sequential step-by-step process from requirements analysis to maintenance. •Systems that have well-defined and understood requirements are a good fit for the Waterfall Model

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

Limitation of the Waterfall Model •Not suitable for the project where requirements are changing. •The high amount of risk and uncertainty •Not good for the object-oriented project •Poor model for long and ongoing project •Can give a false impression of progress •Integration is one big bang at the end •Little opportunity for the customer to preview the system Copyright @ 2019 Learntek. All Rights Reserved.

Suitable Situation to use Waterfall Model •Work well for a small project •When Requirements are very well known •When Product definition is stable •When Technology is understood •When New version of an existing product •When Porting a current product to a new platform.

2) Incremental SDLC Model •In this model, it constructs a partial implementation of a total system that is divide project into builds then slowly add functionality in each build. •The incremental model prioritizes the requirements of the system and then implements them in groups. •Each subsequent release of the system adds function to the previous version until all designed functionality has been implemented.

Incremental Model Strong Points •Develop high-risk or major functions first •Each release delivers an operational product •The 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 Copyright @ 2019 Learntek. All Rights Reserved.

Incremental Model Limitations •Requires good planning and design •Needs an 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) •The total cost of the complete system is higher than the waterfall model

Suitable Situation to use Incremental Model •Risk, funding, schedule, program complexity, or need for early realization of benefits. •Most of the requirements are known up-front but are expected to evolve over time •A need to get basic functionality to the market early •On projects which have lengthy development schedules •On a project with new technology

3) Spiral SDLC Model •It is a “risk-driven” iterative model •It divides a project into iterations •Each iteration deals with 1 or more risks •Each iteration starts with a small set of requirements and goes through the development phase (except Installation and Maintenance) for those set of requirements.

Spiral Model Strong Points •It provides an early indication of insurmountable risks, without much cost •Development phases can be determined by the project manager, according to the complexity of the project. •Users can be closely tied to all lifecycle steps and can see the system early because of rapid prototyping tools •Project monitoring is very efective. Each phase requires a review from concerned people (Early and frequent feedback from users). This makes the model more transparent. The design does not have to be perfect

•Estimates such as budget and schedule become more realistic as work progressed because important issues are discovered earlier. •Manages risks and develops the system into phases. •Changes can be introduced later in the life cycle as well.

Spiral Model Limitations •Time spent on evaluating risks too substantial 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 •Maybe hard to define the objective, verifiable milestones that indicate readiness to proceed through the next iteration Copyright @ 2019 Learntek. All Rights Reserved.

•High cost and time to reach the final product. •Needs special skills to evaluate the risks and assumptions.

Suitable Situation to use Spiral Model •When the creation of a prototype is appropriate •When costs and risk evaluation is important •For medium to high-risk projects •For Long-term project commitment unwise because of potential changes to economic priorities Copyright @ 2019 Learntek. All Rights Reserved.

•When users are unsure of their needs •When requirements are complex •For New product line •When Significant changes are expected (research and exploration)

4)Evolutionary Prototyping Model •Developers build a prototype during the requirements phase •The prototype is evaluated by end users •Users give corrective feedback •Developers further refine the prototype •When the user is satisfied, the prototype code is brought up to the standards needed for a final product.

Steps in Prototyping SDLC Models •A preliminary project plan is developed •A partial high-level paper model is created •The model is a source for a partial requirements specification •A prototype is built with basic and critical attributes •The designer builds the database, user interfaces, and algorithmic functions •The designer demonstrates the prototype, the user evaluates for problems and suggests improvements. •This loop continues until the user is satisfied Copyright @ 2019 Learntek. All Rights Reserved.

Evolutionary Prototyping SDLC Models Strong Points •Requires user involvement •Customers can “see” the system requirements as they are being gathered. •Developers learn from customers •Reduce the development time •Reduce the development cost •Unexpected requirements accommodated •Allows for flexible design and development Copyright @ 2019 Learntek. All Rights Reserved.

•Missing functionalities can be easily added •Result in higher user satisfaction

Evolutionary Prototyping SDLC Models Limitations •Too much involvement of the customer •Insufficient analysis •The design is of less quality

•The resulting system is harder to maintain. Overall maintainability may be overlooked •A prototype is a quick-and-dirty” solution •The customer may want the prototype delivered. •The process may continue forever

Suitable Situation to use Evolutionary Prototyping SDLC Models •When requirements are unstable or must be clarified •For developing user interfaces •For Short-lived demonstrations •For the new, original development •With the analysis and design portions of object-oriented development.

5)Agile Model •The biggest problem with software development is changing requirements •Agile processes accept the reality of change versus the hunt for complete, rigid specifications •Speed up or bypass one or more life cycle phases •Usually less formal and reduced scope •Used for time-critical applications •Used in organizations that employ disciplined methods Copyright @ 2015 Learntek. All Rights Reserved.

Agile Model Strong Points •It can adapt well with changing requirement •Deliver a working product faster than a conventional linear development model •Customer feedback at every stage ensures that the end deliverable satisfies their expectations •No guesswork between the development team and the customer, as there is face to face communication and continuous inputs from the client

•Decrease the time required to avail some system features. •A test can be conducted during the design cycle •Fewer risks and has more flexibilities •Modification in the system needs less time •The result is high-quality software in the least possible time duration and satisfied customer.

Agile Model Limitations •More Programmer centric than user-centric •For larger projects, it is difficult to judge the eforts and the time required for the project in the SDLC. •Since the requirements are ever-changing, there is hardly any emphasis, which is laid on designing and documentation. Therefore, chances of the project going of the track easily are much more

•Scalability •The ability and collaboration of the customer to express user needs. •Documentation is done at later stages. •Reduce the usability of components. •Needs special skills for the team.

Rapid Application Development Model (RAD)

Phases in the RAD model are as follows, •Requirements planning phase – a workshop utilizing structured discussion of business problems •User description phase – automated tools capture information from users •Construction phase – productivity tools, such as code generators and screen generators •Cutover phase – installation of the system, user acceptance testing and user training Copyright @ 2019 Learntek. All Rights Reserved.

RAD Model Strong Points •Reduced cycle time and improved productivity with fewer people means lower costs •Time-box approach mitigates cost and schedule risk •It increases the reusability components •Greater customer satisfaction •Fast delivery time •Reduce the development time •The focus moves from documentation to code (WYSIWYG). Copyright @ 2019 Learntek. All Rights Reserved.

•Uses modeling concepts to capture information about business, data, and processes.

RAD Model Limitations •Large manpower is required to create the number of RD teams. •Risk of never achieving closure •Hard to use with legacy systems •Requires a system that can be modularized •Require highly skilled developer and designer. Copyright @ 2019 Learntek. All Rights Reserved.

•Not useful when technical risks are high •Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

Suitable Situation to use RAD Model •Reasonably well-known requirements •The user involved throughout the life cycle •The project can be time-boxed •Functionality delivered in increments Copyright @ 2019 Learntek. All Rights Reserved.

•High performance not required •Low technical risks •The system can be modularised