The System Development
1 3
Life Cycle
What are the phases of the system development cycle?
Phase 2. Analysis
Conduct preliminary investigation
Phase 1. Planning Perform detailed analysis activities:
Phase 3. Design
Review project requests Study current system Acquire hardware
Prioritize project Determine user requirements
Unit 2 - Software
and software, if
requests Recommend solution necessary
Allocate resources Develop details of
Requirements Analysis
Identify project system
development team
and Modeling
Phase 5. Support Phase 4. Implementation
Conduct post-implementation Develop programs, if necessary
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) system review Install and test new system
Identify errors and enhancements Train users
Monitor system performance Convert to new system
The System Development
Introduction 2
Life Cycle
4
What are guidelines for system development?
Software development life cycle (SDLC) is a structured
process that is used to design, develop, and test good-quality
software. SDLC, or software development life cycle, is a Arrange tasks into phases
methodology that defines the entire procedure of software
development step-by-step.
Involve(groups of activities)
users (anyone for whom
system is being built)
The goal of the SDLC life cycle model is to deliver high-
quality, maintainable software that meets the user’s
requirements.
The SDLC is important because it helps ensure that the right Develop clearly defined standards (procedures
people are involved in the right activities at the right times. company expects employees to follow)
1
The System Development 5 SDLC Model 7
Life Cycle
Who participates in
the system A framework that describes the
development life
cycle?
activities performed at each
stage of a software
development project.
The System Development 6 SDLC Model 8
Life Cycle
What is a systems analyst?
Waterfall
Responsible for designing and V-shaped SDLC
developing information system
Structured Evolutionary Prototyping
RAD (Rapid Application Dev)
Liaison between users and IT Incremental Model
professionals
Spiral
2
Waterfall Model Waterfall Deficiencies 11
Requirements – defines All requirements must be known upfront
needed information,
function, behavior, Deliverables created for each phase are
performance and interfaces. considered frozen – inhibits flexibility
Design – data structures, Can give a false impression of progress
software architecture, Does not reflect problem-solving nature of
interface representations, software development – iterations of phases
algorithmic details.
Integration is one big bang at the end
Implementation – source
code, database, user Little opportunity for customer to preview
documentation, testing. the system (until it may be too late)
Waterfall Strengths 10 When to use the Waterfall 12
Model
Easy to understand, easy to use Requirements are very well known
Provides structure to inexperienced Product definition is stable
staff Technology is understood
Milestones are well understood New version of an existing product
Sets requirements stability Porting an existing product to a
Good for management control new platform.
(plan, staff, track)
Works well when quality is more
important than cost or schedule
3
V-Shaped SDLC Model V-Shaped Strengths 15
A variant of the
Waterfall that Emphasize planning for verification and validation
emphasizes the of the product in early stages of product
verification and development
validation of the Each deliverable must be testable
product. Project management can track progress by
Testing of the product is milestones
planned in parallel with Easy to use
a corresponding phase
of development
13
V-Shaped Steps 14 V-Shaped Weaknesses 16
Project and Requirements Production, operation and
Planning – allocate resources maintenance – provide for
enhancement and corrections
System and acceptance testing
Product Requirements and – check the entire software
Specification Analysis – complete system in its environment Does not easily handle concurrent events
specification of the software
system Does not handle iterations or phases
Does not easily handle dynamic changes in
Architecture or High-Level Design Integration and Testing – check
– defines how software functions that modules interconnect requirements
fulfill the design correctly
Does not contain risk analysis activities
Detailed Design – develop Unit testing – check that each
algorithms for each architectural module acts as expected
component
Coding – transform algorithms
into software
4
When to use the V-Shaped 17 Structured Evolutionary 19
Model Prototyping Steps
Excellent choice for systems requiring high A preliminary project plan is developed
reliability – hospital patient control applications An partial high-level paper model is created
All requirements are known up-front The model is source for a partial requirements
specification
When it can be modified to handle changing A prototype is built with basic and critical
requirements beyond analysis phase attributes
Solution and technology are known The designer builds
the database
user interface
algorithmic functions
The designer demonstrates the prototype,
the user evaluates for problems and suggests
improvements.
This loop continues until the user is satisfied
Structured Evolutionary 18 Structured Evolutionary 20
Prototyping Model Prototyping Strengths
Developers build a prototype during the Customers can “see” the system
requirements phase requirements as they are being gathered
Developers learn from customers
Prototype is evaluated by end users
A more accurate end product
Users give corrective feedback
Unexpected requirements
Developers further refine the prototype accommodated
When the user is satisfied, the prototype code is Allows for flexible design and
brought up to the standards needed for a final development
product. Steady, visible signs of progress produced
Interaction with the prototype stimulates
awareness of additional needed
functionality
5
Structured Evolutionary 21 Rapid Application Model 23
Prototyping Weaknesses (RAD)
Tendency to abandon structured Requirements planning phase (a
program development for “code-and- workshop utilizing structured discussion
fix” development of business problems)
Bad reputation for “quick-and-dirty” User description phase – automated
tools capture information from users
methods
Construction phase – productivity
Overall maintainability may be tools, such as code generators, screen
overlooked generators, etc. inside a time-box.
The customer may want the prototype (“Do until done”)
delivered. Cutover phase -- installation of the
system, user acceptance testing and
Process may continue forever (scope user training
creep)
When to use 22 RAD Strengths 24
Structured Evolutionary
Prototyping Reduced cycle time and improved
Requirements are unstable or have to productivity with fewer people means
lower costs
be clarified Time-box approach mitigates cost
As the requirements clarification stage and schedule risk
of a waterfall model Customer involved throughout the
complete cycle minimizes risk of not
Develop user interfaces achieving customer satisfaction and
business needs
Short-lived demonstrations Focus moves from documentation to
code.
New, original development Uses modeling concepts to capture
With the analysis and design portions information about business, data, and
processes.
of object-oriented development.
6
RAD Weaknesses 25 Incremental SDLC Model
Construct a partial
implementation of a total
system
Accelerated development process Then slowly add increased
must give quick responses to the functionality
user The incremental model
Risk of never achieving closure prioritizes requirements of
the system and then
Hard to use with legacy systems implements them in groups.
Requires a system that can be Each subsequent release of
modularized the system adds function to
the previous release, until all
Developers and customers must be designed functionality has
committed to rapid-fire activities in been implemented.
an abbreviated time frame.
27
When to use RAD 26 Incremental Model 28
Strengths
Reasonably well-known requirements Develop high-risk or major functions first
User involved throughout the life cycle Each release delivers an operational product
Project can be time-boxed Customer can respond to each build
Uses “divide and conquer” breakdown of
Functionality delivered in increments tasks
High performance not required Lowers initial delivery cost
Low technical risks Initial product delivery is faster
System can be modularized Customers get important functionality early
Risk of changing requirements is reduced
7
Incremental Model 29 Spiral SDLC Model
Weaknesses Adds risk analysis,
and 4gl RAD
Requires good planning and design
Requires early definition of a complete and fully
prototyping to the
functional system to allow for the definition of waterfall model
increments
Well-defined module interfaces are required
Each cycle involves
(some will be developed long before others) the same sequence
Total cost of the complete system is not lower of steps as the
waterfall process
model
31
When to use the 30 Spiral Quadrant 32
Determine objectives, alternatives and
Incremental Model constraints
Objectives: functionality, performance,
Risk, funding, schedule, program complexity, hardware/software interface, critical success
or need for early realization of benefits. factors, etc.
Most of the requirements are known up-front Alternatives: build, reuse, buy, sub-contract, etc.
but are expected to evolve over time Constraints: cost, schedule, interface, etc.
A need to get basic functionality to the
market early
On projects which have lengthy
development schedules
On a project with new technology
8
Spiral Quadrant 33 Spiral Quadrant 35
Evaluate alternatives, identify and Plan next phase
resolve risks
Study alternatives relative to objectives Typical activities
and constraints Develop project plan
Identify risks (lack of experience, new Develop configuration management
technology, tight schedules, poor plan
process, etc.
Develop a test plan
Resolve risks (evaluate if money could be
lost by continuing system development Develop an installation plan
Spiral Quadrant 34 Spiral Model Strengths 36
Develop next-level product
Typical activites: Provides early indication of
insurmountable risks, without much cost
Create a design Users see the system early because of
Review design rapid prototyping tools
Develop code Critical high-risk functions are developed
first
Inspect code The design does not have to be perfect
Test product Users can be closely tied to all lifecycle
steps
Early and frequent feedback from users
Cumulative costs assessed frequently
9
Spiral Model Weaknesses 37
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 proceed
through the next iteration
When to use Spiral Model 38
When creation of a prototype is
appropriate
When costs and risk evaluation is
important
For medium to high-risk projects
Long-term project commitment
unwise because of potential changes
to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected
(research and exploration)
10