SDLC Models
SDLC Models
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
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
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