Introduction to Software Engineering
Software Process Model
Muhammad Nasir
[email protected] Outline
Build and Fix Model
Why Models are needed?
Process as a "black box“ & Problem
Process as a “white box“ & Advantage
Prescriptive Model
Waterfall Model or Linear Sequential
Incremental Process Models
Build and Fix Model
Build and Fix Model
The earlier approach
Product is constructed without specification or any attempt
at design.
Developers simply build a product that is reworked as many
times as necessary to satisfy the client.
Model may work for small projects but is totally
unsatisfactory for products of any reasonable size.
Maintenance is high.
Source of difficulties and deficiencies
impossible to Predict
impossible to Manage
Why Models are needed?
Symptoms of inadequacy: The
Software Crisis
Scheduled Time and Cost
Exceeded
User Expectations Not Met
Poor Quality
Process as a "black box"
Informal
Requirements
Process
Product
Quality?
Uncertain /
Incomplete requirement
In the beginning
Problems
The assumption is that requirements can
be fully understood prior to development
Interaction with the customer occurs only at
the beginning (requirements) and end (after
delivery)
Unfortunately the assumption almost never
holds true
Process as a "white box"
Informal
Requirements
Process
Product
feedback
Advantages
Reduce risks by improving visibility
Allow project changes as the project progresses
based on feedback from the customer
Prescriptive Model
Prescriptive process models advocate an
orderly approach to software engineering
Organize framework activities in a certain
order
Process framework activities with set of
software engineering actions.
Each Task identifies the work to be
accomplished to meet the goals.
Prescriptive Model
Software engineer choose process
framework that includes activities like;
Communication
Planning
Modeling
Construction
Deployment
Prescriptive Model
Calling this model as “Prescribe”
because it recommend a set of
process elements, activities, action
task, work product & quality.
Each element is inter-related to one
another (called workflow).
Waterfall Model or Classic Life Cycle
Limitations of the waterfall model
The model implies that you should attempt to
complete a given stage before moving on to
the next stage
Does not account for the fact that
requirements constantly change.
It also means that customers can not use
anything until the entire system is complete.
14
Limitations of the Waterfall Model
Some teams sit ideal for other teams
to finish
Therefore, this model is only
appropriate when the requirements
are well understood, and changes will
be fairly limited during the design
process.
Waterfall Model - Problems
Problems:
1. Real projects rarely follow the
sequential model.
2. Difficult for the customer to state all the
requirement explicitly.
3. Assumes patience from customer -
working version of program will not
available until product is complete.
V-Model
V-Model
V-model depicts the relationship of quality
assurance actions to the Frame Work Activities.
In reality, there is no fundamental difference
between the classic life cycle and the V-model.
The V-model provides a way of visualizing how
verification and validation actions are applied to
earlier engineering work.
Incremental Process Model
Delivers software in small but usable pieces, each piece builds
on pieces already delivered
The Incremental Model
Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments
with each increment delivering part of the required
functionality.
First Increment is often core product
For Example: Word Processor System
1st increment: Basic File Management, Editing, Production
2nd increment: Spell-Checker & Grammar
3rd increment: Advance Page Layout Properties
4th increment: Document Printing
The Incremental Model
It is particularly useful when enough
staffing is not available for the whole
project
Increment can be planned to manage
technical risks.
Incremental model focus more on
delivery of operational product with
each increment.
The Incremental Model
User requirements are prioritised and the highest
priority requirements are included in early
increments.
Once the development of an increment is started,
the requirements are frozen though requirements
for later increments can continue to evolve.
Customer value can be delivered with each
increment so system functionality is available
earlier.
The Incremental Model
Early increments act as a prototype
to help elicit requirements for later
increments.
Lower risk of overall project failure.
For example, a major system might
require the availability of new hardware
that is under development and whose
delivery date is uncertain.
The End
Thanks for Listening
Questions would be appriciated
