Software Process. Characteristics, Process Models

1. SOFTWARE PROCESS
MODELS
PROCESS
CHARACTERISTICS OF SOFTWARE PROCESS
PROCESS MODELS
PROTOTYPING

2. “You’ve got to be very careful if you don’t
know where you’re going, because you might
not get there.” - Berra

3. CMM (Capability Maturity Model)
 A bench-mark for measuring the maturity of an
organization’s software process
 CMM defines 5 levels of process maturity
based on certain Key Process Areas (KPA)
 Level 5 – Optimizing (< 1%)
◦ -- process change management
◦ -- technology change management
◦ -- defect prevention
 Level 4 – Managed (< 5%)
◦ -- software quality management
◦ -- quantitative process management

4. Level 3 – Defined (< 10%)
-- peer reviews
-- intergroup coordination
-- software product engineering
-- integrated software management
-- training program
-- organization process definition
-- organization process focus
Level 2 – Repeatable (~ 15%)
-- software configuration management
-- software quality assurance
-- software project tracking and oversight
-- software project planning
-- requirements management
Level 1 – Initial (~ 70%)

5. Sofware Process 5
The software Development
Problem

6. Sofware Process 6
Project and Process
 A software project is one instance of the
development problem
 Development process takes the project
from user and develops software needed by
user
 There are other goals: cost schedule and
quality, besides delivering software

7. Sofware Process 7
Software Process…
 Process: A sequence of steps performed to
achieve some goal
 Software Process: The sequence of steps
performed to produce software with high
quality, within budget and schedule
 Many types of activities performed by diff
people in a software project
 Better to view software process as comprising
of many component processes

8. Software Process
 A framework for the activities, actions, and tasks that
are required to build high-quality software.
 A process: a series of steps involving activities,
constraints, and resources that produce an intended
output of some kind
 Software process is a method of developing a software
 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 project
objectives of high QP

9. Sofware Process 9
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
software process; other processes revolve
around it
 These are executed by different people
◦ developers execute engg. Process
◦ project manager executes the mgmt proces

10. Sofware Process 10
Component Processes…
 Other processes
◦ Configuration management process:
manages the evolution of artifacts
◦ Change management process: how
changes are incorporated
◦ Process management process:
management of processes themselves
◦ Inspection process: How inspections are
conducted on artifacts

11. Sofware Process 11
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
 At top level, typically few phases in a
process
 How to perform a particular phase –

12. Sofware Process 12
ETVX Specification
 ETVX approach to specify a step
◦ Entry criteria: what conditions must be satisfied for 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 mgmt

13. Sofware Process 13
ETVX approach

14. Characteristics of Software
Process
 Predictability
 Support Testability & Maintainability
 Support Change
 Early defect removal
 Process improvement and feedback

15. 1) Predictability
 Fundamental property of any process
 Predictability determines how accurately the outcome of
process can be predicted before project is completed
 It is achieved from past experiences and failures from
the similar projects
 It increases Q & P. Decreases C & T
 Predictable process is under statistical control
 Predictable property is within the bound around the
expected value of property of interest

16. 2) Support Change
 Changes due to:
◦ Requirements change
◦ Organization and business change –
leads to software supports has to change
 Changes during development also
◦ Customer needs change
◦ Long duration projects needs to be
changed
 Process should support healthy
changes

17. 3) Support testability and Maintainability
 Maintenance cost > Development
 To reduce overall cost, development should reduce maintenance
cost
Process includes Effort
R 10%
D 10%
C 30%
T 50%
 How programmers spend their time?
Writing Programs 13%
Reading Programs and Manuals 16%
Job Communication 32%
Others 39%
 Testing takes more resources during development
 If testing as side activity or underestimating the testing efforts -
>unreliable software

18. 4) Early Defect Removal
 Errors occur during programming
 Correction & Detection -> Hardest activity
 Errors occurs at any stage during dev.
Error occurrence distributions:
R 20%
D 30%
C 50%
 Cost of correcting errors of different phases -> not the same, depends
on when the error is detected and corrected
 Greater the delay in error detection -> more expensive to correct
 Quality control in each phase -> identify, detect, prevent and remove
defects

19. 5) Process Improvement and Feedback
 Fundamental goal -> high Q product with low C
 Software process be a closed-loop process (feedback
control system)
 Process improvement based on previous experiences,
feedback from early parts(last iterations) used to
improve execution of rest of the part(later iterations)

20. Sofware Process 20
Development Process and Process
Models

21. Sofware Process 21
Development Process &
Process Model
 A set of phases and each phase being a sequence of steps
 Sequence of steps for a phase - methodologies for that phase
 Why have phases?
◦ To employ divide and conquer
◦ each phase handles a different part of the problem
◦ helps in continuous validation
 A process model provides generic structure of the process
that can be followed by some projects to achieve their goals

22. Process Models - SDLC
 Major activities in SDLC (Software
Development Life Cycle)
◦ Planning
◦ Requirements Analysis
◦ Design
◦ Coding
◦ Testing
◦ Implementation
◦ Maintenance

23. SDLC PHASE ACTIVITIES
1. Planning •Define the system to be developed
•Set the project scope
•Develop the project plan
2. Requirements
Analysis
•Gather business requirements and documented in SRS
3. Design •Design the technical architecture based on SRS
•Design overall system structure
4. Development •Build technical architecture, databases and programs
• Build programs in small units and integrated in next phase
5. Testing •Write test conditions
•Perform testing
6. Implementation/
Deployment
•Write user documentation
•Provide training
•Product is deployed in customer environment or released to
market
7. Maintenance •Build a help desk
• Support Corrections, improvements and adaptations
•Support system changes

24. Sofware Process 24
Waterfall Model
 One of the first process development models
proposed
 Linear sequence of stages/phases
 Requirements – HLD – DD – Code – Test – Deploy
 A phase starts only when the previous has
completed; no feedback
 Works for well understood problems with minimal
or no changes in the requirements
 Each major phase is marked by milestones and
deliverables (artifacts)

25. Sofware Process 25

27. Sofware Process 27
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

28. Sofware Process 28
Waterfall Advantages
 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

29. Sofware Process 29
Waterfall disadvantages
 All requirements must be known upfront
 Follows the “big bang” approach – all or nothing delivery; too
risky
 Very document oriented, requiring docs at the end of each
phase
 Views software development as manufacturing process rather
than as creative process
 No iterative activities and Change Management that lead to
creating a final product
 Long wait before a final product

30. Sofware Process 30
Waterfall Usage
 Has been used widely
 Well suited for projects where requirements
can be understood easily and technology
decisions are easy
 For familiar type of projects with well known
requirements

31. V Model
 A variation of the waterfall model
 Uses unit testing to verify procedural design
 Uses integration testing to verify architectural
(system) design
 Uses acceptance testing to validate the
requirements
 If problems are found during verification and
validation, the left side of the V can be re-executed
before testing on the right side is re-enacted

33. V-Shaped Strengths
 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

34. 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

35. When to use the V-Shaped
Model
 Excellent choice for systems requiring high
reliability – hospital patient control applications
 All requirements are known up-front
 When it can be modified to handle changing
requirements beyond analysis phase
 Solution and technology are known

36. Sofware Process 36
Prototyping
 Prototyping addresses the requirement
specification limitation of waterfall & V-model
 Instead of freezing requirements only by
discussions, a prototype is built to understand the
requirements
 Helps lessen the requirements risk
 Focus is on quickly developing the model not on
good programming practices
 After preliminary requirements gathering, it
visually show the users what their requirements may
look like when implemented

37. Sofware Process 37
Prototyping

38. Prototyping: Basic Steps
 Identify basic requirements
 Including input and output info
 Details (e.g., security) generally ignored
 Develop initial prototype
 UI first
 Review
 Customers/end –users review and give feedback
 Revise and enhance the prototype & specs

39. Prototyping
 Allows repeated investigation of the
requirements or design
 Reduces risk and uncertainty in the
development

40. Sofware Process 40
Prototyping
 Cost can be kept low
◦ Build only features needs clarification
◦ “quick and dirty” – quality not important
◦ Things like exception handling, recovery,
standards are omitted
◦ Cost can be a few % of the total
◦ Learning in prototype building will help in building,
the improved requirements

41. Sofware Process 41
Prototyping
 Advantages:
◦ Req. will be more stable,
◦ Req. frozen later,
◦ Experience helps in the main development
 Disadvantages:
◦ Potential hit on cost and schedule
 Applicability:
◦ When req. are hard to elicit and confidence in
reqs. is low;
◦ Reqs. are not well understood

42. Throwaway Prototyping
 Write preliminary requirements
 Design the prototype
 User experiences/uses the prototype,
 Specifies new requirements
 Repeat if necessary
 Write the final requirements
 Develop the real products

43. Evolutionary Prototyping
Model
 Goal is to build a very robust prototype in a
structured manner and constantly refine it
 Developers build a prototype during the
requirements phase
 Prototype is evaluated by end users
 Users give corrective feedback
 Developers further refine the prototype
 When the user is satisfied, the prototype code is
brought up to the standards needed for a final product.

44. Incremental prototyping
 Final product built as separate prototypes
 At the end, the prototypes are merged into a final design
 Often used for web applications
 Development broken down into 3 phases, each based on the
preceding 1
1. Static prototype consisting of HTML pages
2. Screen are programmed and fully functional using a
simulated services layer
3. Services are implemented

45. Phased Development: Increments and
Iterations
 Incremental development: starts with small functional
subsystem and adds functionality with each new
release
 Iterative development: starts with full system, then
changes functionality of each subsystem with each new
release

46. Increments and Iterations Model
 System delivered in pieces
◦ enables customers to have some functionality while the rest is being
developed
 Allows two systems functioning in parallel
◦ the production system (release n): currently being used
◦ the development system (release n+1): the next version

47. Sofware Process 47
Iterative Development
 Solves “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 waterfalls
 Feedback from one iteration is used in the future
iterations

48. Sofware Process 48
Iterative Enhancement

49. Sofware Process 49
Iterative Development
 Products almost always follow it
 Used commonly in customized
development:
◦ Businesses want quick response for s/w
◦ Cannot afford the risk of all-or-nothing
 Newer approaches like XP, Agile,… all rely
on iterative development

50. Sofware Process 50
Iterative Development
 Benefits: Get-as-you-pay, feedback for
improvement
 Drawbacks: Architecture/design may not
be optimal, rework may increase, total cost
may be more
 Applicability: where response time is
important, all req. not known

51. Sofware Process 51
Another form of Iteration…
•The first iteration
does the
requirements and
architecture in the
waterfall way
•The development
and delivery is done
incrementally in
iterations

52. Spiral Model
 Suggested by Boehm (1988)
 Combines development activities with risk management
to minimize and control risks
 The model is presented as a spiral in which each
iteration is represented by a circuit around four major
activities
◦ Plan
◦ Determine goals, alternatives and constraints
◦ Evaluate alternatives and risks
◦ Develop and test

54.  Spiral Quadrant: Determine objectives,
alternatives and constraints
◦ Objectives: functionality, performance,
hardware/software interface, critical success
factors, etc.
◦ Alternatives: build, reuse, buy, sub-contract, etc.
◦ Constraints: cost, schedule, interface, etc.
 Spiral Quadrant: Evaluate alternatives, identify
and resolve risks
◦ Study alternatives relative to objectives and
constraints
◦ Identify risks (lack of experience, new technology,
tight schedules, poor process, etc.)
◦ Resolve risks (evaluate if money could be lost by
continuing system development)

55.  Spiral Quadrant: Develop next-level product
◦ Create a design
◦ Review design
◦ Develop code
◦ Inspect code
◦ Test product
 Spiral Quadrant: Plan next phase
◦ Develop project plan
◦ Develop configuration management plan
◦ Develop a test plan
◦ Develop an installation plan

56. Spiral Model Strengths
 Changing requirements can be accommodated.
 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and
the risky parts can be developed earlier which helps
in better risk management.

57. Spiral Model Weaknesses
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-
development phase activities
 Management is more complex.
 End of the project may not be known early.
 Not suitable for small or low risk projects and could be
expensive for small projects.

58. When to use Spiral Model
 When creation of a prototype is appropriate
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment is risky because of
potential changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 Significant changes are expected (research and
exploration)