Вы находитесь на странице: 1из 65

INTRODUCTION TO

SOFTWARE
ENGINEERING
Week 3(Lecture
5,6)
Maha Butt
Chapter 2: Process Models

Linear ,iterative ,evolutionary ,parallel

Linear process flow executes each of the five


activities in sequence.(start from communication
and ended at deployment)
An iterative process flow repeats one or more of the
activities before proceeding to the next.
An evolutionary process flow executes the activities
in a circular manner. Each circuit leads to a more
complete version of the software.
A parallel process flow executes one or more
activities in parallel with other activities ( modeling
for one aspect of the software in parallel with
construction of another aspect of the software ).

SDLC

SDLC is a process followed for a software


project, within a software organization.
Software life cycle models describe
phases of the software cycle and the
order in which those phases are
executed

Planning & Requirement


Analysis

Take input from the customer


Identify the problem to be solved
Focus on what not how
End Result: Functional specification.
Reviewed by customer and designer.

Defining requirement

define and document the product


requirements
get them approved from the customer.
This is done through SRS Software
Requirement Specification (A document
which consists of all the product
requirements to be designed and
developed during the project life cycle.)

Designing Product
Architecture

Focus on how
SRS is reference for product architecture
Based on SRS more than one
architecture is defined in DDS(design
document specification) view by
stakeholders & implementers
the best design approach is selected for
the product based on risk assessment,
product robustness (strength), design
modularity & time.

Developing the product

The programming code is generated as


per DDS during this stage.
Often the shortest phase if design is
performed in detailed & organized way.
Reviewed by designers coders and
tester.

Testing product

Verifying the code works according to


the functional specifications
In this stage products defects are
reported, tracked, fixed and retested,
until the product reaches the quality
standards defined in the SRS

Deployment & maintenance

Sometime product deployment happens


in stages as per the organizations
business strategy.
The product may first be released in a
limited segment and tested in the real
business environment (UAT- User
acceptance testing)
Get feedback for next version.

Waterfall model(classic life


cycle)

The Waterfall Model was first Process Model to


be introduced. It is also referred to as alinearsequential life cycle model. (work flows from
communication through deployment in a
reasonably linear fashion)
each phase must be completed fully before the
next phase can begin.
Simple to understand and use.
Used when project is small and requirements are
clear
Technology is understood

When to use Waterfall

The project is short


Requirements are very well documented,
clear and fixed
Product definition is stable
There are no ambiguous requirements
Technology is not dynamic

Advantages of Waterfall

This model is simple and easy to


understand and use.
Clearly defined stages
Process and results are well documented
It is easy to manage due to the rigidity
of the model
Waterfall model works well for smaller
projects where requirements are very
well understood.

Disadvantages of Waterfall

High amounts of risk and uncertainty.


Poor model for long and ongoing projects.
Not a good model for complex and objectoriented projects.
Cannot accommodate changing requirements.

Example

Software for medical store


Software for library management

V Model

The V model is SDLC model where


execution of the process happens in
sequential manner in V-shape.
Also known as verification and validation
model.

V Model

Model is an extension of the waterfall


model
based on association of a testing phase
for each corresponding development
stage.
Verification phases on one side of the V
Validation phases on the other side.
Coding phase joins the two sides of the
V-Model.

Verification VS Validation
21

Verification: Are we building the product


right?

check whether the software conforms to


specifications.

Validation: Are we building the right


product?

check whether software meets the customer


expectations and requirements.

Verification VS Validation
22

Verification

Validation

Verification is a static practice of


verifying documents, design,
code and program.
It does not involve executing the
code.
It is human based checking of
documents and files.
Verification uses methods like
inspections, reviews,
walkthroughs, and Desk-checking
etc.
It can catch errors that validation
cannot catch.
Target is requirements
specification, application and
software architecture, high level,
complete design, and database
design etc.
Verification is done by QA team

Validation is a dynamic
mechanism of validating and
testing the actual product.
It always involves executing the
code.
It is computer based execution of
program.
Validation uses methods like
black box (functional) testing,
and white box (structural) testing
etc.
It can catch errors that
verification cannot catch.
Target is actual product-a unit, a
module, a bent of integrated
modules, and effective final
product.
Validation is carried out with the

The V-Model
23

The V-Model
24

Verification phases

Requirements

modeling
Architecture design
Module design
Code generation

Validation phases

Unit

testing
Integration testing
System testing
User acceptance testing

When to use V-Model

The V-shaped model should be used for


small to medium sized projects where
requirements are clearly defined and
fixed.
The V-Shaped model should be chosen
when sufficient technical resources are
available with needed technical
expertise.

Advantages of V-Model
26

Simple and easy to use.


Proactive defect tracking that is defects are
found at early stage.
Avoids the downward flow of the defects.
Works well for small projects where requirements
are easily understood.
Easy to manage due to the rigidity of model
Testing activities like planning,test designing
happens well before coding. This saves a lot of
time. Hence higher chance of success over the
waterfall model.

Disadvantages of V-Model
27

Very rigid and least flexible.


Software is developed during the implementation
phase, so no early prototypes of the software are
produced.
Does not easily handle dynamic changes in
requirements
Poor model for long and ongoing projects.
If any changes happen in midway, then the test
documents along with requirement documents
has to be updated.
Does not handle iterations or phases

Example

Software for Admission management


system

Incremental Model
In
incremental
model
the
whole
requirement is divided into various
builds(chunks).
Multiple
development
cycles take place here, making the life
cycle amulti-waterfall cycle.

Cycles are divided up into smaller, more


easily managed modules.
A working version of software is produced
during the first module
So, Working software early on during
thesoftware life cycle.

Incremental Model

When to use the Incremental Model

This model can be used when the requirements of


the complete system are clearly defined and
understood.
When user want some portion of the software as
early as possible.
There is a need to get a product to the market
early.
Resources with needed skill set are not available
There are some high risk features and goals.
Major requirements must be defined; however,
some details can evolve with time.

Advantages of Incremental
Model

Generates working software quickly and early


during the software life cycle.
This model is more flexible less costly to change
scope and requirements.
Time effective
Lowers initial delivery cost.
It is easier to test and debug during a smaller
iteration.
In this model customer can respond to each built.
Easier to manage risk because risky pieces are
identified and handled during itd iteration.

Disadvantage of Incremental Model

Total cost is higher thanwaterfall.


Needs good planning and design.
Needs a clear and complete definition of
the whole system before it can be
broken down and built incrementally.
Integration overhead

Example

MS word
Photoshop
CorelDraw

Evolutionary Models

Software system evolves(to change) over time


as requirements often change as development
proceeds. Thus, a straight line to a complete
end product is not possible. However, a
limited version must be delivered to meet
competitive pressure.

Usually a set of core product or system


requirements is well understood, but the
details and extension have yet to be defined.

Cont
You need a process model that has been
explicitly designed to accommodate a
product that evolved over time.
It is iterative that enables you to develop
increasingly more complete version of
the software.
Two types are introduced, namely

Prototype Process Model


Spiral Process Models.

Evolutionary Models:
Prototyping

The basic idea here is that instead of freezing


the requirements before a design or coding
can proceed, a throwaway prototype is built to
understand the requirements. This prototype
is developed based on the currently known
requirements.
By using this prototype, the client can get an
actual feel of the system, since the
interactions with prototype can enable the
client to better understand the requirements
of the desired system.

Prototype

The prototype are usually not complete


systems and many of the details are not
built in the prototype. The goal is to
provide
a
system
with
overall
functionality.
It is just the Dummy product, or a
sample product just to show the
customer that how actual product will
look like.
Customer evaluate prototype to refine
requirements

Prototype Model

When to use Prototype


Model

Prototype model should be used when the desired


system needs to have a lot of interaction with the end
users.
Typically, online systems, web interfaces have a very
high amount of interaction with end users, are best
suited for Prototype model. It might take a while for a
system to be built that allows ease of use and needs
minimal training for the end user.
Prototyping ensures that the end users constantly work
with the system and provide a feedback which is
incorporated in the prototype to result in a useable
system. They are excellent for designing good human
computer interface systems.

Advantages

Since a working model of the system is displayed, the


users get better understanding of the system being
develop
Errors can be detected much earlier.
Reduces time and cost as the defects can be detected
much earlier.
Quicker user feedback is available leading to better
solutions.
Missing functionality can be identified easily
Since in this methodology a working model of the system
is provided, the users get a better understanding of the
system being developed.
Confusing or difficult functions can be identified
Requirements validation, Quick implementation of,
incomplete, but functional, application.

Disadvantages

Leads to implementing and then repairing way


of building systems.
Users may get confused in the prototypes and
actual systems.
Practically, this methodology may increase the
complexity of the system as scope of the
system may expand beyond original plans.
Incomplete application may cause application
not to be used as the full system was designed
Incomplete or inadequate problem analysis.

Example

Web Apps
online systems

Rapid Application Development Model


In RAD model the functional modules are
developed in parallel as prototypes and
are integrated to make the complete
product for faster product delivery.

RAD Model

When to use RAD Model

RAD should be used when there is a need to develop fully


functional system within very short time(60 to 90 days)
Whole System can be divided in to small modules
User want complete working software as soon as possible
User is willing to pay more
It should be used if theres high availability of designers
for modeling
RADSDLC modelshould be chosen only if resources with
high business knowledge are available and there is a
need to produce the system in a short span of time (2-3
months).

Advantages

Changing requirements can be accommodated.


Progress can be measured.
Reduced development time.
Increases reusability of components
Encourages customer feedback
Quick initial reviews occur
Iteration time can be short with use of powerful RAD
tools.
Productivity with fewer people in short time.
Integration from very beginning solves a lot
ofintegration issues.

Disadvantages

Only system that can be modularized can be built


using RAD.
Requires highly skilled developers/designers.
High dependency on modeling skills.
Inapplicable to cheaper projects as cost of
modeling and automated code generation is very
high.
Management complexity is more.
Dependency on technically strong team members
for identifying business requirements.
Suitable for systems that are component based
and scalable.

Spiral Model

A heavy-weight, plan-driven, highlystructured approach for large projects.


Especially designed for those with higher
chances of failure.
Combines iterative model and waterfall,
emphasizes risk assessment(tashkhees),
customer participation, prototyping, and
more.
Definitely an iterative process.

Spiral Model
Spiral model has different phases
depending upon the choice that team
make.
Communication
Planning
Modeling
Construction
Deployment

Spiral Model

Spiral Model

Planning Phase:Requirements are gathered


during the planning phase. Requirements like
BRS that is Business Requirement
Specifications and SRS that is System
Requirement specifications.
Risk Analysis:In this phase, a process is
undertaken to identify risk and alternate
solutions. A prototype is produced at the end
of the risk analysis phase. If any risk is found
during the risk analysis then alternate
solutions are suggested and implemented.

Spiral Model

Construction Phase:In this phase


software isdeveloped, along
withtestingat the end of the phase.
Hence in this phase the development
and testing is done.
Deployment phase:This phase allows
the customer to evaluate the output of
the project to date before the project
continues to the next spiral.

When to use Spiral Model

When the project is large


For medium to high-risk projects
When costs and risk evaluation is important
Users are unsure of their needs
Requirements are complex
New product line
Long-term project commitment unwise because
of potential changes to economic priorities
Significant changes are expected (research and
exploration)

Advantages of Spiral Model

High amount of risk analysis hence,


avoidance of Risk is enhanced.
Good for large and mission-critical
projects.
Strong approval and documentation
control.
Additional Functionality can be added at
a later date.
Software is produced early in
thesoftware life cycle.

Disadvantages Spiral Model

Can be a costly model to use.


Risk analysis requires highly specific
expertise.
Projects success is highly dependent on
the risk analysis phase.
Doesnt work well for smaller projects.

Example

Robotic software

Win-Win Model

The Win-Win spiral approach is an


extension of the spiral approach. The
phase in this approach is same as the
phase in the spiral approach. The only
difference is that at the time of the
identifying the requirements, the
development team and the customer
hold discussion and negotiate on the
requirements that need to be included in
the current iteration of the software.

Win-Win Model
Addresses more on customer
communication, the following activities
are defined:
1.
Identification of the system or
subsystems key stakeholder.
2.
Determination of the stakeholders
win conditions.
3.
Negotiation of the stakeholders win
conditions to reconcile them into a set
of win-win conditions for all concerned.

Win-Win Model

Win-Win Model
The approach is called Win-Win because it
is a winning situation for the development
team and also for the customer. The
customer wins by getting the product that
fulfills most of the requirements while the
development team wins by delivering
software which is developed with all the
requirements
established
after
negotiations with the customer. The WinWin approach is generally used when you
have time-bound releases.

Example

Complex web app

Component Based
Development

Component based developmentthe


process to apply when reuse is a
development objective (COTS)

Component based
development

Available component-based products are


researched and evaluated for the application
domain in question.
Component integration issues are considered.
A software architecture is designed to
accommodate the components.
Components are integrated into the
architecture.
Comprehensive testing is conducted to
ensure proper functionality.

Advantages

The component-based development


model leads to software reuse, and
reusability provides software engineers
with a number of measurable benefits.
Your software engineering team can
achieve a reduction in development
cycle time
as well as reduction in project cost if
component reuse becomes part of your
culture.

Вам также может понравиться