The Meaning of Process Process Characteristics: Source: Pfleeger Source: Pfleeger

Download as pdf or txt
Download as pdf or txt
You are on page 1of 10

The Meaning of Process

! 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

The Importance of Processes


! Impose consistency and structure on a set of activities ! Guide us to understand, control, examine, and improve the activities ! Enable us to capture our experiences and pass them along

source: pfleeger

source: pfleeger

Reasons for Modelling a Process


! To form a common understanding ! To find inconsistencies, redundancies, omissions ! To find and evaluate appropriate activities for reaching process goals ! To tailor a general process for a particular situation in which it will be used

Software Life Cycle


! When a process involves building a software system, the process may be referred to as the software life cycle
! Requirements analysis and definition ! System (architecture) design ! Program (detailed/procedural) design ! Writing programs (coding/implementation) ! Testing: unit, integration, system ! System delivery (deployment) ! Maintenance

source: pfleeger

source: pfleeger

Software Development Process Models


! Waterfall model ! V model ! Operational specification ! Transformational model ! Phased development: increments and iteration ! Spiral model ! Rational unified process ! Agile methods

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

! Each major phase is marked by milestones and deliverables (artefacts)

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

Drawbacks of the Waterfall Model


! Provides no guidance how to handle changes to products and activities during development (assumes requirements can be frozen) ! Views software development as manufacturing process rather than as creative process ! There is no iterative activities that lead to creating a final product ! Long wait before a final product

Waterfall Model with Prototype


! A prototype is a partially developed product ! Prototyping helps
! developers assess alternative design strategies (design prototype) ! users understand what the system will be like (user interface prototype)

! Prototyping is useful for verification and validation

source: pfleeger

source: pfleeger

Waterfall Model with Prototype

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

Operational Specification Model


! Requirements are executed (examined) and their implication evaluated early in the development process ! Functionality and the design are allowed to be merged

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

! Relies on formalism ! Requires formal specification (to allow transformations)

source: pfleeger

source: pfleeger

Transformational Model

Phased Development: Increment and Iterate


! Shorter cycle time ! 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

source: pfleeger

source: pfleeger

Phased Development: Increment and Iterate

Phased Development: Increment and Iterate


! Incremental development: starts with small functional subsystem and adds functionality with each new release

source: pfleeger

source: pfleeger

Phased Development: Increment and Iterate


! Iterative development: starts with full system, then changes functionality of each subsystem with each new release

Phased Development: Increment and Iterate


! Phased development is desirable for several reasons
! Training can begin early, even though some functions are missing ! Markets can be created early for functionality that has never before been offered ! Frequent releases allow developers to fix unanticipated problems globally and quickly ! The development team can focus on different areas of expertise with different releases

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

REVIEW Requirements plan Life-cycle plan

Simulations, models, benchmarks S/W requirements

Product design

Development plan Integration and test plan

Requirement validation Design V&V Acceptance test Service

Detailed design Code

Unit test Integration test Develop, verify next-level product

Plan next phase

source: pfleeger

source: sommerville

The Rational Unified Process


! A modern generic process derived from the work on the Unified Modeling Language (UML) and associated process ! Brings together aspects of the generic process models discussed previously ! Normally described from three perspectives
! A dynamic perspective that shows phases over time ! A static perspective that shows process activities ! A practice perspective that suggests good practice

Rational Unified Process Phases


Phase iteration

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

Rational Unified Process Phases


Phase iteration

Rational Unified Process Iteration


! In-phase iteration
! Each phase is iterative with results developed incrementally.
Transition

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

Rational Unified Process Good Practice


! Develop software iteratively
! Plan increments based on customer priorities and deliver highest priority increments first.

Rational Unified Process Good Practice


! Visually model software
! Use graphical UML models to present static and dynamic views of the software.

! Manage requirements
! Explicitly document customer requirements and keep track of changes to these requirements.

! Verify software quality


! Ensure that the software meets organizational quality standards.

! Use component-based architectures


! Organize the system architecture as a set of reusable components.

! Control changes to software


! Manage software changes using a change management system and configuration management tools.

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

Agile Methods: Examples of Agile Process


! Extreme programming (XP) ! Crystal: a collection of approaches based on the notion that every project needs a unique set of policies and conventions ! Scrum: 30-day iterations; multiple selforganizing teams; daily scrum coordination ! Adaptive software development (ASD)
! features are crux of customer values ! iteration is important ! change is embraced ! risk is embraced hardest features done first
source: pfleeger

Agile Methods: Extreme Programming


! Emphasis on four characteristics of agility
! Communication: continual interchange between customers and developers ! Simplicity: select the simplest design or implementation ! Courage: commitment to delivering functionality early and often ! Feedback: loops built into the various activities during the development process

Agile Methods: Twelve Facets of XP


! The planning game
(customer defines value)

! Small release ! Metaphor (common vision,


common names)

! Pair programming ! Collective ownership ! Continuous integration


(small increments)

! Simple design ! Writing tests first ! Refactoring

! Sustainable pace
hours/week)

(40

! On-site customer ! Coding standard

source: pfleeger

source: pfleeger

When Extreme is Too Extreme?


! Extreme programming's practices are interdependent
! A vulnerability if one of them is modified

! Requirements expressed as a set of test cases must be passed by the software


! System passes the tests but is not what the customer is paying for

! Refactoring issue
! Difficult to rework a system without degrading its architecture

source: pfleeger

You might also like