SDLC Models | Software Development Life Cycle Models

1

SDLC MODELS
2
(No Transcript)
3
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.
4

• Some of the SDLC Models are as follows
• Waterfall Model
• Incremental SDLC Model
• Spiral Model
• Evolutionary Prototyping Model
• Agile Model
• RAD Model

5

• 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

6

• Waterfall Model Strong Points
• 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

7

• 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 

8

• 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. 

9
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.

10
(No Transcript)
11

• 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

12

• 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

13

• 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

14

• 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.

15
(No Transcript)
16

• 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 effective. 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

17

• 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.

18

• 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

19

• 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

20

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

21
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.

22
(No Transcript)
23

• 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

24

• 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

25

• 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

26

• 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

Learn Business Analyst Training
27

• 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.

28
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

29
(No Transcript)
30

• 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

31

• 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.

32

• Agile Model Limitations
• More Programmer centric than user-centric
• For larger projects, it is difficult to judge the
  efforts 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 off the track easily are
  much more

33

• 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.

34
Rapid Application Development Model (RAD)
35

• 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 

36

• 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).

37

• 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.

38

• 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

39

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

40
For more Training Information , Contact
Us Email info_at_learntek.org USA 1734 418
2465 INDIA 40 4018 1306
7799713624