UNIT- II PROJECT LIFE CYCLE AND EFFORT ESTIMATION
Software process and Process Models – Choice of Process models - Rapid Application
development – Agile methods – Dynamic System Development Method – Extreme
Programming– Managing interactive processes – Basics of Software estimation – Effort and Cost
estimation techniques – COSMIC Full function points - COCOMO II - a Parametric Productivity
Model.
2.1 Software Process and Process Models
A Software product development process usually starts when a request for the product is
received from the customer.
• Starting from the inception stage:
- A product undergoes a series of transformations through a few identifiable stages
- Until it is fully developed and released to the customer.
• After release:
- the product is used by the customer and during this time the product needs to be
maintained for fixing bugs and enhancing functionalities. This stage is called
Maintenance stage.
• This set of identifiable stages through which a product transits from inception to retirement
form the life cycle of the product.
• Life cycle model (also called a process model) is a graphical or textual representation of its life
cycle.
2.2 Choice of Process Models
• The no. of inter related activities to create a final product can be organized in different ways
and we can call these Process Models.
• A software process model is a simplified representation of a software process. Each model
represents a process from a specific perspective. These generic models are abstractions of the
process that can be used to explain different approaches to the software development.
Any software process must include the following four activities:
1. Software specification (or requirements engineering): Define the main functionalities of the
software and the constraints around them.
2. Software design and implementation: The software is to be designed and programmed.
3. Software verification and validation: The software must conform to its specification and
meets the customer needs.
4. Software evolution (software maintenance): The software is being modified to meet customer
and market requirements changes.
The various Process Models are
• Water Fall Model
• Spiral Model
• Prototype Model
• Incremental Delivery
Water fall model
• The waterfall model is a sequential approach, where each fundamental activity of a
process represented as a separate phase, arranged in linear order.
• In the waterfall model, you must plan and schedule all of the activities before starting
working on them (plan-driven process).
• Plan-driven process is a process where all the activities are planned first, and the progress
is measured against the plan.
• While the agile process, planning is incremental and it’s easier to change the process to
reflect requirement changes.
• The phases of the waterfall model are:
• Requirements
• Design
• Implementation
• Testing
• Maintenance
V-process model
• Another way of looking at waterfall model
Evolutionary delivery: prototyping
An iterative process of creating quickly and inexpensively live and working models to test out
requirements and assumptions.
Sprague and McNurlin main types
• ‘throw away’ prototypes
• Evolutionary prototypes what is being prototyped?
• human-computer interface
• functionality
Reasons for prototyping
• learning by doing
• improved communication
• improved user involvement
• a feedback loop is established
• reduces the need for documentation
• reduces maintenance costs i.e. changes after the application goes live
• prototype can be used for producing expected results
Prototyping: some dangers
• users may misunderstand the role of the prototype
• lack of project control and standards possible
• additional expense of building prototype
• focus on user-friendly interface could be at expense of machine efficiency
Other ways of categorizing prototyping
• what is being learnt?
– organizational prototype
– hardware/software prototype (‘experimental’)
– application prototype (‘exploratory’)
• to what extent
– mock-ups
– simulated interaction
– partial working models: vertical versus horizontal
Incremental delivery
The incremental process
Intentional
incremental
delivery
Incremental approach: Benefits
• feedback from early stages used in developing latter stages
• shorter development thresholds
• user gets some benefits earlier
• project may be put aside temporarily
• reduces ‘gold-plating’
BUT there are some possible disadvantages
• loss of economy of scale
• ‘software breakage’
The outline incremental plan
• steps ideally 1% to 5% of the total project
• non-computer steps should be included
• ideal if a step takes one month or less:
– Not more than three months
• each step should deliver some benefit to the user
• some steps will be physically dependent on others
Which step first?
• some steps will be pre-requisite because of physical dependencies
• others may be in any order
• value to cost ratios may be used
– V/C where
– V is a score 1-10 representing value to customer
– C is a score 0-10 representing value to developers
V/C ratios: an example
Rapid Application Development
Rapid Application Development (RAD) model is also sometimes referred to as the rapid
prototyping model.
This model has the features of both the prototyping and the incremental delivery models.
The major aims of the RAD model are as follows:
● to decrease the time taken and the cost incurred to develop software systems; and
● To limit the costs of accommodating change requests by incorporating them as early as
possible before large investments have been made on development and testing.
‘Agile’ methods
Structured development methods have some perceived advantages
– produce large amounts of documentation which can be largely unread
– documentation has to be kept up to date
– division into specialist groups and need to follow procedures stifles communication
– users can be excluded from decision process
– long lead times to deliver anything etc. etc
Dynamic system development method
• UK-based consortium
• arguably DSDM can be seen as replacement for SSADM
• DSDM is more a project management approach than a development approach
• Can still use DFDs, LDSs etc!
Nine core DSDM principles
1. Active user involvement
2. Teams empowered to make decisions
3. Frequent delivery of products
4. Fitness for business purpose
5. Iterative and incremental delivery
6. Changes are reversible
7. Requirements base-lined at a high level
8. Testing integrated with development
9. Collaborative and co-operative approach
DSDM framework
DSDM process model
DSDM: time-boxing
• time-box fixed deadline by which something has to be delivered
• typically two to six weeks
• MOSCOW priorities
– Must have - essential
– Should have - very important, but system could operate without
– Could have
– Want- but probably won’t get!
Extreme programming
