Process Model

1
Process Model

• N.L. Hsueh

2
Why process model is important?

• Software development projects need to be
  controlled
• Progress, people, resource, time
• To control progress, we use a phased development
  in which a number of clearly identifiable
  milestones are established between the start and
  finish of the project

3
Software is engineered by applying three distinct
phases that focus on definition, development and
support R. Pressman
What How Change
4
Process Model

• The waterfall model
• Separate and distinct phases of specification and
  development
• Evolutionary development
• Specification and development are interleaved
• Formal transformation
• A mathematical system model is formally
  transformed to an implementation
• Reuse-based development
• The system is assembled from existing components
• Hybrid process models Spiral Model
• Prototyping for high-risk specifications
• Waterfall model for well-understood developments

5
Without a repeatable process, the only repeatable
result you are likely to produce are
errors Macala etc.
6
!
7
Waterfall

• Waterfall model is proposed by Royce in 1970
• In each phase of software development process, we
  have to compare the results obtained against
  those that are required
• In all phases, quality has to be assessed and
  controlled
• Verification
• If the system meets its requirements
• Are we building the system right
• Validation
• If the system meets the users requirements
• Are we building the right system
• We want to prevent putting much energy into
  constructing a system which later turns out not
  to satisfy the users requirements

8
Figure 3.1 The Waterfall Model
9
Problems with Waterfall Model

• Why does waterfall model sometimes fail?
• Document-driven
• It is often difficult for the customer to state
  all requirements explicitly
• Compare to buying clothes
• The customer must have patience
• Blocking state some team members must wait for
  other members of the teams to complete dependent
  tasks

10
(No Transcript)
11
Evolutionary development

• Prototyping
• Incremental Development
• Rapid Application Development

12
Prototyping

• It is often difficult to get and maintain a
  sufficiently accurate perception of the
  requirements of the prospective user
• Customers does not know the full possibilities of
  automation
• Quick design
• throwaway implement only aspects poorly
  understood.
• evolutionary more likely to implement best
  understood benefits
• improve communication
• reduce risk
• most feasible way to validate specification
• for maintenance as well

13
(No Transcript)
14
Advantages of evolutionary process

• Is easier to use
• Users are involved in the development
• Problem are detected earlier
• The development incurs less effort
• The product is early-visible
• Avoid the un-necessary re-work

15
Problems with evolutionary process

• The resulting system has more features
• Users may think it is easy to realize new
  features
• Worse performance
• Only focus on functionality
• An inefficient algorithm may be implemented
  simply to demonstrate capability
• Less-than-idea choice has become an integral part
  of the system
• Harder to maintain
• Customers unaware that the prototype is
  throw-able
• Documentation is sacrificed for speed
• Require experienced team
• The process is not visible
• System is often poorly structured

16
When your customer has a legitimate need but is
clueless about the details, develop a prototype
as a first step R. Pressman
17
Incremental Development

• The functionality of the system is produced and
  delivered to the customer in small increments
• Avoid the big bang effect
• Instead of building software, the software grows
• The user is closely involved in planning the
  development
• Avoid the over-functionality
• When you encounter a difficult deadline that
  cannot be changed, the incremental development is
  a good paradigm to consider

18
File management, editing
More sophisticated editing
Spelling checking
Advanced page layout
19
Rapid Application Development

• Four phases
• Requirements planning
• User design
• Construction
• Cutover
• Time box
• JRP (Joint Requirement Planning)
• Get the requirement right at the first time
• Triage
• Requirements are prioritized
• JAP (Joint Application Design)
• Two JAP workshop to determine the design
  architecture

20
Team

• SWAT team
• Skilled With Advanced Tool
• ownership of the problem to be address
• SWAT itself estimates the time and time boxes
• Four main ingredient
• Prototyping
• Considerable user involvement
• SWAT teams
• Time box

21
Determined by SWAT
Time box
Reqt. planning
User design
Construction
Cutover
22
Spiral Model

• A model which explicitly recognized risk may form
  the basis of a generic process model
• Each loop in the spiral represents a phase
  (defined by management) of the software process
• Loop evolution
• Feasibility analysis ? requirement analysis ? ?
  system integration
• A loop may involve more than one process model
• E.g., prototyping for requirement risk, followed
  by a waterfall model

23

• Phases of the spiral model
• Objective setting
• 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
  of development.
• Planning
• The project is reviewed and plans drawn up for
  the next round of the spiral

24

• Template for a spiral round
• Objectives
• Constraints
• Alternatives
• Risks
• Risk resolution
• Results
• Plans
• Commitment

25
Spiral model of the software process
26
Objective Significantly improve software quality
Risk No cost-effective quality improvement
possible Quality improvements may increase cost
excessively New methods migh cause existing staff
to leave
Constraint Within a three-year
timescale Without large-scale capital
investment Without radical change to company
standards
Risk resolution Literature survey Pilot
project Survey of potential reusable
components Assessment of available tool
support Staff training and motivation seminars
Alternative Reuse existing certified
software Introduce formal specification and
verification Invest in testing and validation
tools
Result Experience of formal methods is
limited Hard to quantify improvements Limited
tool support available for company standard
development Reusable components available but
little reuse tool support
Plan Explore reuse option in more detail Develop
prototype reuse support tool Explore component
certification scheme
Commitment Need further 12 month development
27

• 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 parts
  of the project

28

• Spiral model advantages
• Focuses attention on reuse options
• Focuses attention on early error elimination
• Puts quality objectives up front
• Integrates development and maintenance
• Provides a framework for hardware/software
  development

29
Problems with spiral model

• Spiral model problems
• Contractual development often specifies process
  model and deliverables in advance
• Requires risk assessment expertise
• Needs refinement for general use

30
Process Model for Component-Based Software
Engineering

• The software factory paradigm emphasizes the
  development of reusable elements, ranging from
  individual routines (domain-specific) to software
  architectures and frameworks that serve as
  fill-in-the-blacks skeleton systems

31
(No Transcript)
32
Process Modeling Language

• Process language
• State transition diagram
• Petri-net

33
Any activity becomes creative when the doer cares
about it right, or doing it better John Updike
34
Rational Unified Process

• Use case driven
• employ use cases for determining the requirements
• Architecture and component-centered
• determine which artifacts need to be developed
• describe how the entire system is divided into
  parts and how these interact
• decide which parts need to
• Iterative
• the decomposition of the development into similar
  steps, each iteration produces a partial result
• Incremental
• the total functionality of the system under
  development grows with each step.

35

• Why use case
• To capture the value adding requirement
• To drive the process
• To device the architecture
• Why architecture
• To understand the system
• To organize development
• To foster reuse
• To evolve the system

36

• Why iterative and incremental
• Mitigate risk
• Get a robust architecture
• Handle changing requirements
• Allow for tactical changes
• Achieve continuous integration

37
Requirements
Analysis
Use Case
Increment
Architecture
Design
Test
Implementation
38
(No Transcript)