-
8/6/2019 51155102-SE-RESORCE-MNGT
1/77
Sofware Process 1
Software Process
Integrated Approach to SE
-
8/6/2019 51155102-SE-RESORCE-MNGT
2/77
Sofware Process 2
Software Process Process is distinct from product products
are
outcomes of executing a process on a project
Software Engineering focuses on process
Premise: Proper processes will help achieve projectobjectives of
high QP
-
8/6/2019 51155102-SE-RESORCE-MNGT
3/77
Sofware Process 3
Software Process Process: A particular method, generally
involving a
number of steps
Software Process: A set of steps, along withordering constraints
on execution, to producesoftware with desired outcome
Many types of activities performed by different
people in a software project Better to view software process as
comprising of
many component processes
-
8/6/2019 51155102-SE-RESORCE-MNGT
4/77
Sofware Process 4
Software ProcessesSoftware Process
ProductEngineering
Process
ProcessManagement
Process
DevelopmentProcess
ProjectManagement
Process
ConfigurationManagement
Process
-
8/6/2019 51155102-SE-RESORCE-MNGT
5/77
Sofware Process 5
Component Software Processes Two major processes
Development focuses on development and quality steps
needed to engineer the software Project management focuses on
planning and
controlling the development process
Development process is the heart of softwareprocess; other
processes revolve around it
These are executed by different people Programmers, testers
execute development process
Project manager executes the management process
-
8/6/2019 51155102-SE-RESORCE-MNGT
6/77
Sofware Process 6
Component Processes Other processes
Configuration management process: manages the
evolution of artifacts Requirements management process: how
changes in
requirements are incorporated
Review process: How inspections are conducted on
artifacts Process management process: management of
processes
themselves
-
8/6/2019 51155102-SE-RESORCE-MNGT
7/77
Sofware Process 7
Process Specification Process is generally a set of phases
Each phase performs a well defined task and
generally produces an output
Intermediate outputs work products / artifacts
At top level, typically few phases in a process
How to perform a particular phase methodologieshave been
proposed
-
8/6/2019 51155102-SE-RESORCE-MNGT
8/77
Sofware Process 8
ETVX Specification ETVX approach to specify a step
Entry criteria: what conditions must be satisfied before
initiating this phase Task: what is to be done in this phase
Verification: the checks done on the outputs of this phase
eXit criteria: when can this phase be considered done
successfully
A phase also produces info for management
-
8/6/2019 51155102-SE-RESORCE-MNGT
9/77
Sofware Process 9
ETVX approach
-
8/6/2019 51155102-SE-RESORCE-MNGT
10/77
Sofware Process 10
Desired Process Properties Provide high Q&P
Support testability as testing is the most expensive task;
testing can consume 30 to 50% of total developmenteffort
Support maintainability as maintenance can be moreexpensive than
development; over life up to 80% of total
cost Remove defects early, as cost of removing defects
increases with latency
-
8/6/2019 51155102-SE-RESORCE-MNGT
11/77
Sofware Process 11
High Q&P: Early Defect
Removal Cost of a defect increases with latency
Hence, for high Q&P, the process must support
early defect removal
That is why there is a V in ETVX, and quality controltasks in
the software process
-
8/6/2019 51155102-SE-RESORCE-MNGT
12/77
Sofware Process 12
Early Defect Removal
-
8/6/2019 51155102-SE-RESORCE-MNGT
13/77
Sofware Process 13
Desired Properties Predictability and repeatability
Process should repeat its performance when used on
different projects i.e. outcome of using a process should be
predictable
Without predictability, one cannot estimate, or sayanything
about quality or productivity
With predictability, past performance can be used topredict
future performance
-
8/6/2019 51155102-SE-RESORCE-MNGT
14/77
Sofware Process 14
Predictability Predictable process is said to be under
statistical
control
Repeatedly using the process produces similar results
Results properties of interest like quality, productivity,
To consistently develop software with high Q&P,process must
be in control
-
8/6/2019 51155102-SE-RESORCE-MNGT
15/77
Sofware Process 15
Predictability
-
8/6/2019 51155102-SE-RESORCE-MNGT
16/77
-
8/6/2019 51155102-SE-RESORCE-MNGT
17/77
Sofware Process 17
Summary Process method for doing something
Process typically has stages, each stage focusing on
an identifiable task Stages have methodologies
Software process can be viewed as comprising ofmultiple
processes
Goal is to produce software with high quality
andproductivity
Process is the means
-
8/6/2019 51155102-SE-RESORCE-MNGT
18/77
Sofware Process 18
Development Process andProcess Models
Integrated Approach to SE
-
8/6/2019 51155102-SE-RESORCE-MNGT
19/77
Sofware Process 19
Software Project Project Temporary endeavor undertaken to
accomplish a unique purpose
Software Project to build a software system withincost and
schedule with high quality which satisfiesthe customer
Project goals high Q and high P
Suitable process needed to reach goals For a project, the
process to be followed is specified
during planning
-
8/6/2019 51155102-SE-RESORCE-MNGT
20/77
Sofware Process 20
Development Process A set of phases and each phase being a
sequence of
steps
Sequence of steps for a phase - methodologies forthat phase.
Why have phases
To employ divide and conquer (manage complexity)
Each phase handles a different part of the problem
Helps in continuous verification
-
8/6/2019 51155102-SE-RESORCE-MNGT
21/77
Sofware Process 21
Development Process Commonly has these activities:
Requirements
analysis, architecture, design, coding, testing,
delivery Different models perform them in different manner
-
8/6/2019 51155102-SE-RESORCE-MNGT
22/77
Sofware Process 22
Requirement Analysis To understand and state the problem
precisely
Forms the basis of agreement between user and
developer Specifies what , not how
Not an easy task, as needs are often misunderstood
Requirement specifications of even medium systems
can be many hundreds of pages Output is the software requirement
specifications
(SRS) document
-
8/6/2019 51155102-SE-RESORCE-MNGT
23/77
Sofware Process 23
Design A major step in moving from problem domain to
solution domain; three main tasks
Architecture design components and connectors thatshould be
there in the system
High level design modules and data structures neededto implement
the architecture
Detailed design logic of modules
Most methodologies focus on architecture or highlevel design
Outputs are architectural/high/logic design docs
-
8/6/2019 51155102-SE-RESORCE-MNGT
24/77
Sofware Process 24
Coding Converts design into code in specific language
Goal: Implement the design with simple and easy to
understand code. Code should be simple and readable.
The coding phase affects both testing andmaintenance. Well
written code can reduce thetesting and maintenance effort.
Output is code
-
8/6/2019 51155102-SE-RESORCE-MNGT
25/77
-
8/6/2019 51155102-SE-RESORCE-MNGT
26/77
Sofware Process 26
Effort Distribution Distribution of effort :
Req. - 10-20%
Design - 10-20% Coding - 20-30%
Testing - 30-50%
Coding is not the most expensive.
-
8/6/2019 51155102-SE-RESORCE-MNGT
27/77
Sofware Process 27
Distribution of effort How programmers spend their time
Writing programs - 13%
Reading programs and manuals - 16% Job communication - 32%
Others - 39%
Programmers spend more time in reading programsthan in writing
them
Writing programs is a small part of their lives
-
8/6/2019 51155102-SE-RESORCE-MNGT
28/77
Sofware Process 28
Defects Distribution of error occurrences by phase is
Req. - 20%
Design - 30% Coding - 50%
Defects can be injected at any of the major phases
Cheapest way to detect and remove defects close towhere it is
injected.
Hence must check for defects after every phase
-
8/6/2019 51155102-SE-RESORCE-MNGT
29/77
Sofware Process 29
Process Models A process model specifies a general process,
usually
as a set of stages
This model will be suitable for a class of projects
i.e. a model provides generic structure of theprocess that can
be followed by some projects toachieve their goals
-
8/6/2019 51155102-SE-RESORCE-MNGT
30/77
Sofware Process 30
Projects Process If a project chooses a model, it will generally
tailor it
to suit the project
This produces the spec for the projects process This process can
then be followed in the project
i.e. process is what is actually executed; processspec is plan
about what should be executed;
process model is a generic process spec Many models have been
proposed for the
development process
-
8/6/2019 51155102-SE-RESORCE-MNGT
31/77
Sofware Process 31
SDLC Models Waterfall Model
Prototyping / RAD
Iterative / Incremental Model
Spiral Model / Evolutionary Model
-
8/6/2019 51155102-SE-RESORCE-MNGT
32/77
Sofware Process 32
Classical Waterfall model
-
8/6/2019 51155102-SE-RESORCE-MNGT
33/77
Sofware Process 33
Waterfall model with iterationRequirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
-
8/6/2019 51155102-SE-RESORCE-MNGT
34/77
Sofware Process 34
Waterfall Model Linear sequence of stages/phases
Requirements HLD DD Code Test Deploy
A phase starts only when the previous hascompleted
The phases partition the project, each addressing a
separate concern
-
8/6/2019 51155102-SE-RESORCE-MNGT
35/77
Sofware Process 35
Waterfall Linear ordering implies each phase should have
some output
The output must be validated/certified Outputs of earlier
phases: work products
Common outputs of a waterfall: SRS, project plan,
design docs, test plan and reports, final code,supporting
docs
-
8/6/2019 51155102-SE-RESORCE-MNGT
36/77
Sofware Process 36
Waterfall Advantages Conceptually simple, cleanly divides the
problem
into distinct phases that can be performed
independently Natural approach for problem solving
Easy to administer in a contractual setup eachphase is a
milestone
-
8/6/2019 51155102-SE-RESORCE-MNGT
37/77
Sofware Process 37
Waterfall disadvantages Assumes that requirements can be
specified and
frozen early
May fix hardware and other technologies too early Follows the
big bang approach all or nothing
delivery; too risky
Very document oriented, requiring docs at the endof each
phase
-
8/6/2019 51155102-SE-RESORCE-MNGT
38/77
Sofware Process 38
Waterfall Usage Has been used widely
Well suited for projects where requirements can be
understood easily and technology decisions are easy i.e. for
familiar type of projects it still may be the
most optimum
-
8/6/2019 51155102-SE-RESORCE-MNGT
39/77
Sofware Process 39
V-Model It is a variation of Waterfall model with strong
emphasis on Testability
Model encourages test activities beginning inparallel with
corresponding development activities
Early verification & validation helps in mitigating risk
Excellent for system requiring high reliability Works well when
requirements are well understood
Suffers from problems similar to waterfall model
-
8/6/2019 51155102-SE-RESORCE-MNGT
40/77
Sofware Process 40
V-Model
User requirementsand acceptance
test planning
Functionalrequirements and
system test planning
Architectureand integration
test planning
Detailed design
and unittest planning
Unit
testing
Integrationtesting
Systemtesting
Acceptancetesting
Coding
Time
Verification Validation
-
8/6/2019 51155102-SE-RESORCE-MNGT
41/77
Sofware Process 41
Prototyping Prototyping addresses the requirement
specification
limitation of waterfall
Instead of freezing requirements only bydiscussions, a prototype
is built to understand therequirements
Helps alleviate the requirements risk
A small waterfall model replaces the requirementsstage
-
8/6/2019 51155102-SE-RESORCE-MNGT
42/77
Sofware Process 42
Throwaway - Prototype Development of prototype
Starts with initial requirements
Only key features which need better understanding areincluded in
prototype
No point in including those features that are wellunderstood
Feedback from users taken to improve the understanding
of the requirements Once the requirements are understood,
throwaway the
prototype and start all over again
-
8/6/2019 51155102-SE-RESORCE-MNGT
43/77
Sofware Process 43
Prototyping Cost can be kept low
Build only features needing clarification
quick and dirty quality not important, scripting etc canbe
used
Things like exception handling, recovery, standards
areomitted
Cost can be a few % of the total Learning in prototype building
will help in building,
besides improved requirements
-
8/6/2019 51155102-SE-RESORCE-MNGT
44/77
Sofware Process 44
Prototyping- pros & cons Pros
generally, reduces cost of development
reduces risks associated with projects
Cons
customer wants the prototype as final system
implementation level compromises are made
-
8/6/2019 51155102-SE-RESORCE-MNGT
45/77
Sofware Process 45
Prototyping Problems
Lack of process visibility
Systems are often poorly structured Special skills (e.g. in
languages for rapid prototyping) may
be required
Applicability
For small or medium-size interactive systems
For parts of large systems (e.g. the user interface)
For short-lifetime systems
-
8/6/2019 51155102-SE-RESORCE-MNGT
46/77
Sofware Process 46
Iterative Development Counters the all or nothing drawback of
the
waterfall model
Combines benefit of prototyping and waterfall Develop and
deliver software in increments
Each increment is complete in itself
Can be viewed as a sequence of mini waterfalls Feedback from one
iteration is used in the future
iterations
-
8/6/2019 51155102-SE-RESORCE-MNGT
47/77
Sofware Process 47
Iterative Enhancement
-
8/6/2019 51155102-SE-RESORCE-MNGT
48/77
Sofware Process 48
Iterative Development Products almost always follow it
Used commonly in customized development also
Businesses want quick response for sw
Cannot afford the risk of all-or-nothing
Newer approaches like XP, Agile, all rely oniterative
development
-
8/6/2019 51155102-SE-RESORCE-MNGT
49/77
-
8/6/2019 51155102-SE-RESORCE-MNGT
50/77
Sofware Process 50
Timeboxing Iterative is linear sequence of iterations
Each iteration is a mini waterfall decide the specs,
then plan the iteration Time boxing fix an iteration duration,
then
determine the specs
Divide iteration in a few equal stages Use pipelining concepts
to execute iterations in
parallel
-
8/6/2019 51155102-SE-RESORCE-MNGT
51/77
Sofware Process 51
Time Boxed Iterations General iterative development fix the
functionality
for each iteration, then plan and execute it
In time boxed iterations fix the duration ofiteration and adjust
the functionality to fit it
Completion time is fixed, the functionality to bedelivered is
flexible
-
8/6/2019 51155102-SE-RESORCE-MNGT
52/77
Sofware Process 52
UP-Time Boxed IterationsIteration
1
De-
signCode+Design+Test+Integrate
Ana-
lyze
...Iteration
2
De-
signCode+Design+Test+Integrate
Ana-
lyze
2 or 4 weeks 2 or 4 weeks
-
8/6/2019 51155102-SE-RESORCE-MNGT
53/77
Sofware Process 53
Time boxed Iteration This itself very useful in many
situations
Has predictable delivery times
Overall product release and marketing can be betterplanned
Makes time a non-negotiable parameter and helps
focus attention on schedule Prevents requirements bloating
Overall development time is still unchanged
-
8/6/2019 51155102-SE-RESORCE-MNGT
54/77
Sofware Process 54
Timeboxing Taking Time Boxed
Iterations Further What if we have multiple iterations executing
in
parallel
Can reduce the average completion time byexploiting
parallelism
For parallel execution, can borrow pipeliningconcepts from
hardware
This leads to Timeboxing Process Model
-
8/6/2019 51155102-SE-RESORCE-MNGT
55/77
Sofware Process 55
Timeboxing Model Basics Development is done iteratively in fixed
duration
time boxes
Each time box divided in fixed stages Each stage performs a
clearly defined task that can
be done independently
Each stage approximately equal in duration
There is a dedicated team for each stage When one stage team
finishes, it hands over the
project to the next team
-
8/6/2019 51155102-SE-RESORCE-MNGT
56/77
Sofware Process 56
Timeboxing With this type of time boxes, can use pipelining
to
reduce cycle time
Like hardware pipelining view each iteration as
aninstruction
As stages have dedicated teams, simultaneousexecution of
different iterations is possible
-
8/6/2019 51155102-SE-RESORCE-MNGT
57/77
Sofware Process 57
Timeboxing Execution Software
Requirements Build
eploy B1
B2Requirements Build
eploy B2
Requirements Build
eploy B3
Requirements Build
eploy B4
-
8/6/2019 51155102-SE-RESORCE-MNGT
58/77
Sofware Process 58
Timeboxing execution First iteration finishes at time T
Second finishes at T+T/3; third at T+2 T/3, and so
on In steady state, delivery every T/3 time
If T is 3 weeks, first delivery after 3 wks, 2nd after 4wks, 3rd
after 5 wks,
In linear execution, delivery times will be 3 wks, 6wks, 9
wks,
-
8/6/2019 51155102-SE-RESORCE-MNGT
59/77
-
8/6/2019 51155102-SE-RESORCE-MNGT
60/77
Sofware Process 60
Team Size In linear execution of iterations, the same team
performs all stages
If each stage has a team of S, in linear executionthe team size
is S
In pipelined execution, the team size is three times(one for
each stage)
i.e. the total team size in timeboxing is larger; andthis
reduces cycle time
-
8/6/2019 51155102-SE-RESORCE-MNGT
61/77
Sofware Process 61
Team Size Merely by increasing the team size we cannot
reduce cycle time - Brooks law
Timeboxing allows structured way to add manpowerto reduce cycle
time
Note that we cannot change the time of an iteration Brooks law
still holds
Work allocation different to allow larger team tofunction
properly
-
8/6/2019 51155102-SE-RESORCE-MNGT
62/77
Sofware Process 62
Timeboxing Pros and Cons Pros: Shortened delivery times,
iterative, distributed
execution
Cons: Larger teams, project management is harder,high
synchronization needed, CM is harder
-
8/6/2019 51155102-SE-RESORCE-MNGT
63/77
Sofware Process 63
Spiral model of the software processRisk
analys is
Riskanalys is
Riskanalys is
Riskanalysis Proto-
ty pe 1
Prototype 2
Prototype 3Opera-tional
protoyp e
Concept o fOperation
S imul ations, models, b en chmarks
S/Wrequi rements
Requi rementvalid ation
De si gnV& V
Prod uct
design Detail eddesign
Code
Un i t tes t
Integr ationtest
AcceptancetestServ ice Develop, ve rify
next-leve l prod uct
Evaluate alterna tivesidentify, resolve risk s
Determine objectiv esalternatives and
constraint s
Plan next p hase
Integra tionand test plan
Developmentplan
Requi rements planLi fe-c ycle pl an
REVIEW
-
8/6/2019 51155102-SE-RESORCE-MNGT
64/77
Sofware Process 64
Spiral Model by Boehm Activities are organized in a spiral with
many cycles
Radial dimension represents cumulative cost in
accomplishing the tasks done so far Angular dimension represents
the progress made in
completing each cycle.
Development step depends on risk and allows anymixture of
approaches
Each cycle completed by review for planning thenext cycle.
-
8/6/2019 51155102-SE-RESORCE-MNGT
65/77
Sofware Process 65
Phases of the spiral model Objective setting, alternatives and
constraints
Specific objectives for the project phase are identified
Risk assessment and reduction Key risks are identified, analyzed
and information is
sought to reduce these risks
Development and validation
An appropriate model is chosen for the next phase
ofdevelopment.
Planning
The project is reviewed and plans drawn up for the nextround of
the s iral
-
8/6/2019 51155102-SE-RESORCE-MNGT
66/77
Sofware Process 66
Spiral model flexibility Well-understood systems (low technical
risk) -
Waterfall model. Risk analysis phase is
relatively cheap Stable requirements and formal
specification.
Safety criticality - Formal transformation model
High UI risk, incomplete specification -
prototyping model
Hybrid models accommodated for different partsof the project
-
8/6/2019 51155102-SE-RESORCE-MNGT
67/77
Sofware Process 67
Spiral model Pros and Cons Pros
Focuses attention on early error elimination
Puts quality objectives up front Integrates development and
maintenance
Cons
Contractual development often specifies process model
and deliverables in advance Requires risk assessment
expertise
-
8/6/2019 51155102-SE-RESORCE-MNGT
68/77
Sofware Process 68
Component Based Development OO technologies provides framework
for CBSE
Reusability across applications
Encourages use of third party components
Framework exists for building / sharing components
Incorporates spiral model characteristics
Evolutionary, Iterative Ex. Unified software development
process
-
8/6/2019 51155102-SE-RESORCE-MNGT
69/77
Sofware Process 69
The Formal Methods Model Formal mathematical specification of
computer
system
Specify, develop, verify computer system byrigorous,
mathematical notations
Eliminate many of the problems of conventionalsoftware
engineering
ambiguity, incompleteness, inconsistency
Leads to defect free software ex. Cleanroomsoftware
engineering
-
8/6/2019 51155102-SE-RESORCE-MNGT
70/77
Sofware Process 70
Formal Methods concerns Time consuming and expensive
Extensive training is required
Difficult to use for communicating with the customer
Useful for safety critical software
-
8/6/2019 51155102-SE-RESORCE-MNGT
71/77
-
8/6/2019 51155102-SE-RESORCE-MNGT
72/77
Sofware Process 72
Agile Methodologies Extreme Programming (XP)
Scrum Development
Crystal Methodologies
Feature Driven Development (FDD)
Dynamic Systems Development Method (DSDM)
-
8/6/2019 51155102-SE-RESORCE-MNGT
73/77
Sofware Process 73
Agile Manifesto Individuals and interactions over
processes and tools
Working software over comprehensivedocumentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
-
8/6/2019 51155102-SE-RESORCE-MNGT
74/77
Sofware Process 74
Agile Method Best Practices Backlog Management Team Planning
Test Driven Development Continuous Integration SCRUM meetings Agile
Modeling Caves & Common Refactoring Pair Programming
-
8/6/2019 51155102-SE-RESORCE-MNGT
75/77
Sofware Process 75
Summary Process models define generic process, which can
form basis of project process
Process typically has phases, each phase focusingon an
identifiable task
Many models for development process have beenproposed
-
8/6/2019 51155102-SE-RESORCE-MNGT
76/77
Project management plan IT IS A DOCUMENT THAT IS PREPARED
BEFORE
THE PROJECT STARTS AND NECESSARY APPROVAL
IS TAKEN IT CONTAINS
PROJECT INITIATION
SCOPE OF THE PROJECT
USER REQUIREMENTS BASELINED
PHASES OF THE PROJECT/ MODEL USED/DELIVERABLES
HARDWARE / SOFTWARE TO BE USED
-
8/6/2019 51155102-SE-RESORCE-MNGT
77/77
PMP TEM AND RESPONSIBILTIES / MEETINGS
GUIDELINES/ STANDARDS TO BE USED
METRICATION PLAN CONFIGUARATION PLAN
RISK MANAGEMENT
GOALS
AUDITS TRAINING PALN
PROJECT CLOSURE
