Escolar Documentos
Profissional Documentos
Cultura Documentos
Process Models
In addition to project members, the following may need access to parts of the project plan:
Management,
Customers
Subcontractors
Suppliers
Investors
1
Unit_I_T2_W14-15
Process Models
Banks
Project Visibility
Unlike other engineers (e.g. civil, electronic, chemical etc.) software engineers do not
produce anything physical.
It is inherently difficult to monitor an SE project due to lack of visibility.
SE projects must produce additional deliverables (artifacts) which are visible, such as:
A Lifecycle Model?
Definition.
A (software/system) lifecycle model is a description of the sequence of activities
carried out in an SE project, and the relative order of these activities.
It provides a fixed generic framework that can be tailored to a specific project.
Project specific parameters will include:
Size, (person-years)
Budget,
Duration.
project plan = lifecycle model + project parameters
2
Unit_I_T2_W14-15
Process Models
Project visibility
Administrative overhead
Risk exposure
Customer relations, etc, etc.
Waterfall Model
The waterfall model is the classic lifecycle model it is widely known, understood
and (commonly?) used.
In some respect, waterfall is the common sense approach.
Introduced by Royce 1970.
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)
3
Unit_I_T2_W14-15
Process Models
Technology is understood
New version of an existing product
Porting an existing product to a new platform.
A variant of the Waterfall that emphasizes the verification and validation of the product.
Testing of the product is planned in parallel with a corresponding phase of development
V-Shaped Steps
Project and Requirements Planning allocate resources
Product Requirements and Specification Analysis complete specification of the
software system
Architecture or High-Level Design defines how software functions fulfill the design
Detailed Design develop algorithms for each architectural component
Production, operation and maintenance provide for enhancement and corrections
System and acceptance testing check the entire software system in its environment
Integration and Testing check that modules interconnect correctly
Unit testing check that each module acts as expected
Coding transform algorithms into software
V-Shaped Strengths
4
Unit_I_T2_W14-15
Process Models
Emphasize planning for verification and validation of the product in early stages of
product development
Each deliverable must be testable
Project management can track progress by milestones
Easy to use
V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in requirements
Does not contain risk analysis activities
Code-and-Fix
This model starts with an informal general product idea and just develops code until a
product is ready (or money or time runs out).
Work is in random order.
Advantages
No administrative overhead
Signs of progress (code) early.
Low expertise, anyone can use it!
Useful for small proof of concept projects, e.g. as part of risk reduction.
Disadvantages
Dangerous!
o No visibility/control
o No resource planning
o No deadlines
o Mistakes hard to detect/correct
Impossible for large projects,
o communication breakdown, chaos.
5
Unit_I_T2_W14-15
Process Models
The incremental model prioritizes requirements of the system and then implements them in
groups.
Each subsequent release of the system adds function to the previous release, until all
designed functionality has been implemented.
6
Unit_I_T2_W14-15
Process Models
Risk, funding, schedule, program complexity, or need for early realization of benefits.
Most of the requirements are known up-front but are expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development schedules
On a project with new technology
C o n s t r u c t io n
c o m p on e n t re u s e
T e am # 2 a u t o m a t ic c o d e
C o m m u n ic a t io n g e n e r a t io n
t e s t in g
M o d e ling
b u si n e s s m o d e l i n g
d a t a m o d e lin g
p ro c e s s m o d e l i n g
P la n n in g
C o ns t r uc t io n D e p lo y m e n t
T e am # 1 co m p o n e n t re u se i n t e g r at io n
a u t o m a t i c co d e
g e n e ra t i o n
d e liv e r y
M o d e li n g t e st i n g f e e d b ack
b u s in e s s m o d e lin g
d a t a m o d e lin g
p r o c e s s m o d e lin g
C o n s t r u c t io n
c o m p o n e n t re u s e
a u t o m at i c c o d e
g e n e r at i o n
t e s t in g
6 0 - 9 0 days
7
Unit_I_T2_W14-15
Process Models
RAD Strengths
Reduced cycle time and improved productivity with fewer people means lower costs
Time-box approach mitigates cost and schedule risk
Customer involved throughout the complete cycle minimizes risk of not achieving customer
satisfaction and business needs
Focus moves from documentation to code (WYSIWYG).
Uses modeling concepts to capture information about business, data, and processes.
RAD Weaknesses
Accelerated development process must give quick responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed to rapid-fire activities in an abbreviated
time frame.
Spiral Model
8
Unit_I_T2_W14-15
Process Models
iterative lifecycle models.
In 1988 Boehm developed the spiral model as an iterative model which includes risk
analysis and risk management.
Key idea: on each iteration identify and solve the sub-problems with the highest risk.
Advantages
Realism: the model accurately reflects the iterative nature of software development on
projects with unclear requirements
Flexible: incoporates the advantages of the waterfal and rapid prototyping methods
Comprehensive model decreases risk
Good project visibility.
Disadvantages
Needs technical expertise in risk analysis to really work
Model is poorly understood by non-technical management, hence not so widely used
9
Unit_I_T2_W14-15
Process Models
Complicated model, needs competent professional management. High administrative
overhead.
Rapid Prototyping
Idea: Customers are non-technical and usually dont know what they want/can have.
Prototypes are built when goals are general and not specific.
Prototyping can be used as a standalone process or by one of the processes presented.
The prototype serves as the first system. Users get a feel for the actual system and
developers get something built quickly.
A prototype is intended for short term use but too often they are used much longer.
Rapid prototyping emphasises requirements analysis and validation, also called:
o Customer Oriented development,
o Evolutionary prototyping
Advantages
Reduces risk of incorrect user requirements
Good where requirements are changing/uncommitted
Regular visible progress aids management
Supports early product marketing
Disadvantages
An unstable/badly implemented prototype often becomes the final product.
Requires extensive customer collaboration
Costs customers money
Needs committed customers
Difficult to finish if customer withdraws
May be too customer specific, no broad market
10
Unit_I_T2_W14-15
Process Models
When to use
Structured Evolutionary Prototyping
Requirements are unstable or have to be clarified
As the requirements clarification stage of a waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
With the analysis and design portions of object-oriented development.
Agile Principles
Continuous delivery of software
Continuous collaboration with customer
Continuous update according to changes
Value participants and their interaction
Simplicity in code, satisfy the spec.
An Agile method?
11
Unit_I_T2_W14-15
Process Models
XP Practices
Programming in pairs
Test driven development
Continuous planning, change , delivery
Shared project metaphors, coding standards and ownership of code
Advantages
Lightweight methods suit small-medium size projects
Produces good team cohesion
Emphasises final product
Iterative
Test based approach to requirements and quality assurance
Disadvantages
Difficult to scale up to large projects where documentation is essential
Needs experience and skill if not to degenerate into code-and-fix
Programming pairs is costly
Test case construction is a difficult and specialised skill.
12
Unit_I_T2_W14-15
Process Models
Each cycle has phases, culiminating in a new release (c.f. Spiral model)
Inception identify core use cases, and use to make architecture and design tradeoffs.
Estimate and schedule project from derived knowledge.
Elaboration capture detailed user requirements. Make detailed design, decide on build vs.
buy.
Construction components are bought or built, and integrated.
Transition release a mature version that satisfies acceptance criteria.
Reuse-oriented development
Based on systematic reuse where systems are integrated from existing components or
COTS (Commercial-off-the-shelf) systems
Process stages
o Component analysis
o Requirements modification
o System design with reuse
o Development and integration
This approach is becoming more important but still limited experience with it
COTS
COTS = Commercial Off-The-Shelf software
Engineer together a solution from existing commercial software packages using minimal
software glue.
E.g. using databases, spread sheets, word proccessors, graphics software, web browsers, etc.
Advantages
Fast, cheap solution
May give all the basic functionality
Well defined project, easy to run
Disadvantages
Limited functionality
Licensing problems, freeware, shareware, etc.
License fees, maintainance fees, upgrade compatibility problems
13
Unit_I_T2_W14-15
Process Models
14
Unit_I_T2_W14-15
Process Models
Team Waterfall Prototype Iterative Evolutionary Spiral RAD
15
Unit_I_T2_W14-15
Process Models
16