0% found this document useful (0 votes)
18 views25 pages

02-Sdlc Models (i)

Uploaded by

akrajput1504
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views25 pages

02-Sdlc Models (i)

Uploaded by

akrajput1504
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 25

SOFTWARE CONSTRUCTION

AND DEVELOPMENT
SE-351
Muhammad Waheed Khan
Software Development Lifecycle

Models Overview
Software Process Models
Software Development Life Cycle

• When a process involves building a software, the process may be referred to as


software life cycle
• Requirements analysis and definition

• System (architecture) design

• Program (detailed/procedural) design

• Writing programs (coding/implementation)

• Testing: unit, integration, system

• System delivery (deployment)

• Maintenance
Software Process Models
Software Development Process Models

• Waterfall model
• V model
• Prototyping model
• Operational specification
• Transformational model
• Phased development: increments and iterations
• Spiral model
• Agile methods
Software Process Models
Waterfall Model
• One of the first process development models proposed

• Works for well understood problems with minimal or no changes in the requirements

• In it, one development stage should be completed before the next begins, thus when all the requirements are elicited from the
customer, analyzed for completeness and consistency and documented in a requirement document, then the development team
can go on to system design activities.

• Simple and easy to explain to customers

• It presents
• a very high-level view of what goes on during development
• sequence of process activities

• Each major phase is marked by milestones and deliverables (artifacts)

- Milestones are the end-point of a process activity

- Deliverables are project results delivered to customers


Software Process Models
Waterfall Model (cont.)
Software Process Models
Waterfall Model (cont.)
• There is no iteration in waterfall model

• Most software developments apply a great many iterations

The software development process in reality


Software Process Models
Drawbacks of The Waterfall Model
• Provides no guidance how to handle changes to products and
activities during development (assumes requirements can be
frozen)

• Views software development as manufacturing process rather than


as creative process

• There is no iterative activities that lead to creating a final product

• Long wait before a final product is delivered.


Software Process Models
Waterfall Model with Prototype

• A prototype is a partially developed product that enables customers and developers to


examine some aspect of the proposed system and decide if it is suitable or appropriate
for the finished product.

• For example: parts of the design may be prototyped,


which helps developers assess alternative design
strategies and decide which is best for a particular project.
Software Process Models
Waterfall Model with Prototype (cont.)

• Prototyping helps
• developers assess alternative design strategies (design prototype)
• users understand what the system will be like (user interface prototype)

• Prototyping is useful for verification and validation


- Validation: ensures that the system has implemented all the requirements, so that each
system function can be traced back to a particular requirement in the specification. It
ensures that developer is building the right product (according to specifications).

- Verification : ensures that each function works correctly. It checks quality of the
implementation.
Software Process Models
Waterfall Model with Prototype (cont.)

• Waterfall model with prototyping


Software Process Models
V Model

• V model is a variation of the waterfall model

• Uses unit testing to verify program design i.e., during unit and
integration testing, the coders and test team members should
ensure that all aspects of the program design have been
implemented correctly in the code.

• Uses integration testing to verify architectural (system) design


Software Process Models
V Model
• Uses acceptance testing to validate the requirements

• If problems are found during verification and validation, the left


side of the V can be re-executed to fix and improve the
requirements, design and code before testing step on the right
side are re-enacted.
Software Process Models
V Model (cont.)
Software Process Models
Prototyping Model
• Prototyping model allows all or part of the system to be constructed
quickly to understand or clarify issues.
• Allows repeated investigation of the requirements or design to ensure that
the developer, user and customer have a common understanding both of
what is needed and what is required.
• It allows all or part of the system to be constructed quickly to understand
or clarify issues.
• Reduces risk and uncertainty in the development
Software Process Models
Prototyping Model
• For example: the system development may begin with a small set of
requirements supplied by the customers and users.
• Then alternatives are explored by having interested parties look at possible
screens, tables, reports and other system output that are used directly by
the customers and users.
• As the customers and users decide on what they want, the requirements
are revised.
Software Process Models
Prototyping Model
• Once there is a common agreement on what the requirements should be,
the developers move on to the design.
• Again, alternative designs are explored, often with consultation with
customers and users.
• The initial design is revised until the developers, users and customers are
happy with the result.
• During design revision, requirements might get change which are
accommodated.
Software Process Models
Prototyping Model
Software Process Models
Prototyping Model

• Prototype Model places more effort in creating the actual software instead of
concentrating on documentation. This way, the actual software could be released in
advance.
• Prototyping requires more user involvement and allows them to see and interact with a
prototype allowing them to provide better and more complete feedback and
specifications.
• The presence of the prototype being examined by the user prevents many
misunderstandings that occur when each side believe the other understands what they
said. The final product is more likely to satisfy the user’s desire for look, feel, and
performance
Software Process Models
Phased Development: Increments and Iterations
• One way to reduce cycle time is to use phased
development.
• System delivered in pieces
• enables customers to have some functionality while the rest is
being developed
Software Process Models
Phased Development: Increments and Iterations

• Allows two systems functioning in parallel


• the production system (release n): currently being used
• the development system (release n+1): the next version that is being
prepared to replace the current production system.
Software Process Models
Phased Development: Increments and Iterations (cont.)

• The developers build Release1, test it and turn it over to the users as the
first operational release.
• As the users use Release1, the developers are building Release2.
• Thus, the developers are always working on Release n+1 while Release n is
operational.
Software Process Models
Phased Development: Increments and Iterations (cont.)
Approaches of development in releases:
• Incremental development:
- The system as specified in requirement document is partitioned into
subsystems by functionality.
- The releases are defined by beginning with one small functional
subsystem and adds functionality with each new release.
• Iterative development:
- Delivers a full system in the beginning and then changes functionality
of each subsystem with each new release
Software Process Models
Phased Development: Increments and Iterations (cont.)
Software Process Models
Phased Development: Increments and Iterations (cont.)

• Phased development is desirable for several reasons


• Training can begin early, even though some functions are missing. The
training process allows developers to observe how certain functions are
executed, suggesting enhancements for later releases. In this way, the
developers can be very responsive to the users.
• Markets can be created early for functionality that has never been
offered.
• Frequent releases allow developers to fix unanticipated problems
globally and quickly as they are reported from the operational system.
• The development team can focus on different areas of expertise with
different releases.

You might also like