Systems Development Life

Cycle Models
 Requirements Analysis
Extracting the requirements of a desired software product is the first task in
creating it. While customers probably believe they know what the software is to
do, it may require skill and experience in software engineering to recognize
incomplete, ambiguous or contradictory requirements.

Specification
Specification is the task of precisely describing the software to be written, in a
mathematically rigorous way. In practice, most successful specifications are
written to understand and fine-tune applications that were already well-
developed, although safety-critical software systems are often carefully specified
prior to application development. Specifications are most important for external
interfaces that must remain stable.

Software architecture
The architecture of a software system refers to an abstract representation of that
system. Architecture is concerned with making sure the software system will
meet the requirements of the product, as well as ensuring that future
requirements can be addressed. The architecture step also addresses
interfaces between the software system and other software products, as well as
the underlying hardware or the host operating system.
Coding
Reducing a design to code may be the most obvious part of the software
engineering job, but it is not necessarily the largest portion.

Testing
Testing of parts of software, especially where code by two different engineers
must work together, falls to the software engineer.

Documentation
An important task is documenting the internal design of software for the
purpose of future maintenance and enhancement. Documentation is most
important for external interfaces.

Maintenance
Maintaining and enhancing software to cope with newly discovered problems or
new requirements can take far more time than the initial development of the
software. Not only may it be necessary to add code that does not fit the original
design but just determining how software works at some point after it is
completed may require significant effort by a software engineer. About 2/3 of all
software engineering work is maintenance, but this statistic can be misleading.
A small part of that is fixing bugs.
SDLC Models
System development approach, depending Upon the specific
requirement of the organization in the total system may follow
Any one of the following models :

 Waterfall model
 Prototyping model
 Spiral model

The combination of more than one of the Above model may be used
for system Development, depending upon the nature and size of
the project and the risk involved. This Is called hybrid approach
of system Development
Waterfall model
The best-known and oldest process is the waterfall model, where
developers follow these steps in order. They state requirements,
analyze them, design a solution approach, architect a software
framework for that solution, develop code, test (perhaps unit
tests then system tests), deploy, and maintain. After each step is
finished, the process proceeds to the next step, just as builders
don't revise the foundation of a house after the framing has been
erected. If iteration is not included in the planning, the process
has no provision for correcting errors in early steps , so the entire
(expensive) engineering process may be executed to the end,
resulting in unusable or unneeded software features.
PROPOSAL
DEFINATION

FEASIBILITY
STUDY
WATERFALL MODEL

REQUIREMENT
ANALYSIS

SYSTEM
DESIGN

CODINGAND
TESTING

IMPLEMENTATION

SYSTEM
MAINTENANCE
Waterfall Strengths
 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
Waterfall Deficiencies
 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)
When to use the Waterfall Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
PROTOTYPE MODEL
Prototyping is the process of quickly putting together a
working model in order to test various aspects of a
design, illustrate ideas or features and gather early
user feedback. Prototyping is often treated as an
integral part of the system design process, where it
is believed to reduce project risk and cost. Often
one or more prototypes are made in a process of
incremental development where each prototype is
influenced by the performance of previous designs,
in this way problems or deficiencies in design can
be corrected
 START PROTOTYPE MODEL

PROTOTYPE
REQUIREMENT QUICK
BUILDING
ANALYSIS DESIGN

ENGINEER THE REDEFINE USER

PRODUCT PROTOTYPE EVALUATION

STOP
Prototyping Model

 Developers build a prototype during the

requirements phase
 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.
Prototyping Model Steps
 A preliminary project plan is developed
 An partial high-level paper model is created
 The model is source for a partial requirements specification
 A prototype is built with basic and critical attributes
 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
Advantages :
 Can be used when customer is not sure about what
he wants
 Faster way of finalising the requirements
 Useful for new technologies and domains
Disadvantage :
 A prototype if used in a production environment, may
lack quality
 Overall maintainability may be overlooked
 The customer may want the prototype delivered.
 Process may continue forever (scope creep)
Spiral Model Steps
The spiral model is a Systems Development Life Cycle
methodology that combines features of prototyping
with the waterfall methodology. The spiral model is
often favored for large, complex projects.

Iterates cycles of these project phases:

1 Requirements definition
2 Risk analysis
3 Prototyping
4 Simulate, benchmark
5 Design, implement, test
6 Plan next cycle (if any)
 Steps in the spiral model include:
 The new system requirements are defined. This usually involves
interviewing a number of users representing all the end users of the
system.
 A preliminary system design is created.
 An initial prototype of the new system is constructed from the
preliminary design. This is usually a scaled-down system, and
represents an approximation of the final product’s characteristics.
 After evaluating the strengths, weaknesses and risks of the first
prototype, a second prototype is developed and tested.
 If the risk is considered to be too great, the client may choose to
terminate the project at this point. Risk factors to be considered include
development cost overruns, operating-cost miscalculation, etc.
 Subsequent prototypes are developed until the customer is satisfied
that the latest prototype represents the desired product.
 The system is constructed, based on the final prototype.
 The final system is evaluated and tested. Routine maintenance is
carried out continually to prevent large-scale failures and to minimize
downtime.
Advantages of Spiral Model
1. Avoidance of Risk is enhanced.
2. Strong approval and documentation control.
3. Implementation has priority over functionality.
4. Additional Functionality can be added at a later
date.

Disadvantages of Spiral Model

1. Highly customized limiting re-usability
2. Applied differently for each application
3. Risk of not meeting budget or schedule
4. Possibility to end up implemented as the Waterfall
framework
When to use Spiral Model
 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)
 Incremental SDLC Model
 Construct a partial implementation of a total system
 Then slowly add increased functionality
 The incremental model prioritizes requirements of the system and
then implements them in groups.
 Each subsequent release of the system adds function to the
previous release, until all designed functionality has been
implemented.
DESIGN1 DESIGN2 DESIGN3 DESIGNn

IMPLEMENT1 IMPLEMENT2 IMPLEMENTn

ANALYSIS1 ANALYSIS2 ANALYSISn

ITERATIVE ENHANCEMENT MODEL

Incremental Model Strengths
 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
Incremental Model Weaknesses
 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 High