The Meaning of Process Process Characteristics: Source: Pfleeger Source: Pfleeger
The Meaning of Process Process Characteristics: Source: Pfleeger Source: Pfleeger
The Meaning of Process Process Characteristics: Source: Pfleeger Source: Pfleeger
! A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind ! A process involves a set of tools and techniques
Process Characteristics
! Prescribes all major process activities ! Uses resources, subject to set of constraints (such as schedule) ! Produces intermediate and final products ! May be composed of subprocesses with hierarchy or links ! Each process activity has entry and exit criteria ! Activities are organized in sequence, so timing is clear
source: pfleeger
source: pfleeger
Process Characteristics
! Each process has guiding principles, including goals of each activity ! Constraints may apply to an activity, resource or product
source: pfleeger
source: pfleeger
source: pfleeger
source: pfleeger
Waterfall Model
! One of the first process development models proposed ! Works for well understood problems with minimal or no changes in the requirements ! Simple and easy to explain to customers ! It presents
! a very high-level view of the development process ! sequence of process activities
source: pfleeger
source: pfleeger
Waterfall Model
Waterfall Model
! There is no iteration in waterfall model ! Most software developments apply a great many iterations
source: pfleeger
source: pfleeger
source: pfleeger
source: pfleeger
V Model
! A variation of the waterfall model
source: pfleeger
source: pfleeger
V 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 reexecuted before testing on the right side is reenacted
Prototyping Model
! Allows repeated investigation of the requirements or design ! Reduces risk and uncertainty in the development
source: pfleeger
source: pfleeger
Transformational Model
! Fewer major development steps ! Applies a series of transformations to change a specification into a deliverable system
! Change data representation ! Select algorithms ! Optimize ! Compile
source: pfleeger
source: pfleeger
Transformational Model
source: pfleeger
source: pfleeger
source: pfleeger
source: pfleeger
source: pfleeger
source: pfleeger
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
Spiral Model
Determine objectives, alternatives and constraints Risk analysis Risk analysis Risk analysis Risk analysis Prototype 1 Concept of Operation Prototype 2 Operational protoype Evaluate alternatives, identify, resolve risks
Prototype 3
Product design
source: pfleeger
source: sommerville
Inception
Elaboration
Construction
Transition
! Inception
! Establish the business case for the system.
! Elaboration
! Develop an understanding of the problem domain and the system architecture.
! Construction
! System design, programming and testing.
source: sommerville source: sommerville
Inception
Elaboration
Construction
! Cross-phase iteration
! As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally.
! Transition
! Deploy the system in its operating environment.
source: sommerville
source: sommerville
! Manage requirements
! Explicitly document customer requirements and keep track of changes to these requirements.
source: sommerville
source: sommerville
Agile Methods
! Emphasis on flexibility in producing software quickly and capably ! Agile manifesto
! Value individuals and interactions over process and tools ! Prefer to invest time in producing working software rather than in producing comprehensive documentation ! Focus on customer collaboration rather than contract negotiation ! Concentrate on responding to change rather than on creating a plan and then following it
source: pfleeger
! Sustainable pace
hours/week)
(40
source: pfleeger
source: pfleeger
! Refactoring issue
! Difficult to rework a system without degrading its architecture
source: pfleeger