Software Processes

Outline:
1. What is a software process?
A. Four primary software engineering activities
Software Processes 2. Traditional software process models
A. Waterfall
B. Incremental development
!
! C. Spiral model
Chapter 2 D. Reuse-oriented software engineering
3. Coping with change
4. Example process: Rational Unified Process

!1 !2

1. What is a software process? A simple process

• Software Process: A structured set of activities used
Unit
to develop a software system. Problem
Statement
Coding Compiling Testing
Release

• It is a description of Error
problem Error
problem

- what tasks need to be performed in

What important Debugging
- what sequence under step is missing?
- what conditions by
- whom to • Suitable for student projects
achieve the “desired results.” • Students encounter problems when
- some steps are skipped
- problem statement is not well stated or understood
• Desired results: high quality software product.
!3 !4
 As projects get larger and more 1A. Four primary software engineering
complex . . . activities
• There are many different software processes but all
involve these activities:
• We need more people and more coordination
- Specification – defining what the system should do (stating
- Problem statement needs to be expanded and clarified
the requirements)
(requirements/specifications)
- Development – defining the organization of the system (aka
- Need a good, well-documented design
the design) and implementing the system
- Need to make sure various developers can work together
- Validation – checking that the system does what the
(tools, documentation)
customer wants
- Need to ensure adequate testing is done
- Evolution – changing the system in response to customer
! needs.
• We need a more detailed process • Different software processes do the activities in
different ways.

!5 !6

Software specification Software development:

design and implementation

• The process of establishing the requirements: !

- the features/functions that are required by the users • Converting the requirements into an executable
- the constraints on the system’s operation and development. system.
• Requirements engineering process • Software design
- Requirements elicitation and analysis - Description of the structure of the software using various
❖ What do the customers/users require or expect from the system? models (describing the subcomponents, how they interact, etc)
❖ May observe existing systems, develop models or prototype
- Requirements specification • Implementation
❖ Defining the requirements in detail and documenting them. - Translate the design into an executable program
- Requirements validation
❖ Checking them for clarity, consistency, completeness, etc.
• Design and implementation are closely related and
often interleaved.
!7 !8
 Software validation Software evolution
• Verification and validation (V & V) is intended to • After the software has been released, it must be
- show that a system conforms to its specification and kept up to date.
- meets the needs of the system customer. - Customers require new functions
! - Defects must be repaired
- Must adapt to new platforms and machines
• Program testing: !
- executing the system over simulated data, ensuring the results
are correct. • Activities include:
- Modifying requirements/specifications (as needed)
• Inspections and reviews:
- Modifying design (as needed)
- humans analyze models and source code looking for errors or
- Modifying the implementation
problems
- Retesting, adding new test cases.

!9 !10

2. Traditional Software process models 2A. Waterfall model

(or frameworks, or paradigms)

• A software process model: • The waterfall model

- is a simplified (or abstract) representation of a set of specific - One of the first published models
software processes. - Separate and distinct phases are performed in sequence.
- must be “extended” with more detail to become an actual - Planning occurs up front: “Plan-driven”
software process.
• The separate phases:
• Traditional software process models: -
-
Requirements definition
Software design
A. Waterfall model
- Implementation
B. Incremental development
- Testing
C. Spiral model - Maintenance
D. Reuse-oriented software engineering
• The output of one stage is input to the next.
• Tends to require/generate much documentation.
!11 !12
 Waterfall model Waterfall model issues

Requirements
definition
• Good features:
- Simple and easy to implement (better than no process)
- Easy for managers to track the progress of the project
System and
software design
• Can be used for large projects when a system is developed
at several sites.
Implementation
and unit testing - Plan-driven nature of the this model helps coordinate the work.

Integration and • Main drawback: The difficulty of accommodating changes

system testing after the process is underway.
- Change requires “backtracking”: revising previous step(s), re-work (costly)
Operation and - This model is appropriate only when
maintenance
a) the requirements are well-understood upfront and
b) changes will be fairly limited during the design process.
What makes it go backwards?
• Customers often need to change the requirements
!13 !14

2B. Incremental development Incremental development

(a.k.a Iterative development)

• Several development iterations are performed in sequence.

• Each iteration is a self-contained mini-project composed of
activities such as requirements analysis, design,
programming, and test
From: Craig Larman,
! Agile and Iterative Development - A Manager's Guide

• Each iteration produces a new version (called an increment).

- Each version adds functionality to the previous version.
- Only the final version is a complete system.

• Each version is exposed to the user for feedback

- The customer may come to the developers’ site for demos/testing.
- If the intermediate versions are given to the customer, it is called
Each time around the loop produces
Incremental Delivery. a new version of the software.

!15 !16
 Incremental development benefits Incremental development problems

• The process is not visible

• Reduces cost of accommodating changing customer - there’s less process documentation, so it’s difficult to measure progress.
requirements. - may not know how many more increments are required.
- Early versions are incomplete, so less re-work to do.
- May require no changes to current version (add to future version).
• Difficult to design and implement common facilities needed by
all versions
• It is easier to get customer feedback.
• System structure tends to degrade as new increments are
- Users understand a working incremental release better than added.
documents from the specification or design phase. - this makes the code more difficult to modify each time.
• Does not need to be planned entirely up front. - UNLESS time and money are spent on refactoring to improve the
software.

• Early versions can implement the most important, - Refactoring: disciplined technique for restructuring an existing body of
code, altering its internal structure without changing its external behavior.
urgent, or risky features - Modifying a program to improve its structure, reduce its complexity, or
make it easier to understand.

!17 !18

2C. Spiral model

• Proposed by Barry Boehm in 1988.

• Process represented as a spiral
- Each loop represents a phase in the process.
- Content of each phase is not predetermined, plan as you go.

• Risks are explicitly assessed and resolved.

- Assumes need for change are a result of project risks.

• Sectors of the model:

- Identify objectives, alternatives and constraints.
- Evaluate and reduce risk (may develop prototype).
- Development and validation
- Plan next phase (after review of current phase).
!19 !20
 2D. Reuse-oriented software
Spiral model issues
engineering

• Good for high-risk projects. • The system is assembled from existing components.
- Often used in combination with other process models. • Components may be in the form of
• In practice, the model is rarely used as published. - source code that must be compiled into the final product OR
- already compiled code that can be accessed from other programs.
!
• Somewhat similar to incremental development, but • Process stages:
- Risk assessment is incorporated into the process - Requirements specification (similar to other process models)
- Component analysis: search for close matches to requirements
- Development is not required to be incremental:
- Requirements modification: to reflect available components
✦ prototypes and results of previous loops can be discarded.
- System design with reuse: organize framework around acceptable
✦ production development could be postponed until the last loop.
components (may require designing new code).
- Development and integration: components are integrated along with
new code
- System validation (similar to other process models)
!21 !22

Types of software components for Advantages and Disadvantages of

reuse Reuse-oriented Software Engineering
• Web services (or “API”) • Benefits
- Various “functions” available for remote invocation from apps - Reduces costs and risks (less code to write, already tested)
- Examples: Weather API from Weather Channel, Endicia Label - Usually leads to faster delivery.
Server API (labels with USPS postage)
• Disadvantages
• Library of Classes: framework - Requirements may have to be compromised (no good
- Developed as a package to be integrated (compiled) with a matches found)
component framework such as .NET or J2EE. - Control over evolution of system is lost (dependent on
- Example: parsekit for Mac OS X apps (scanners/parsers) developers of the components).

• Stand-alone software systems that are configured

for use in a particular environment.
- often called COTS: “Commercial off the Shelf” systems
- Example: PeopleSoft, HR management for companies
!23 !24
 Reducing the costs of rework:
3. Coping with change
two approaches
• Change is inevitable in all large software projects.
- Changing business environments lead to changing requirements • Change avoidance: include process activities that
❖ New opportunities and technologies anticipate possible changes before significant
❖ Changing markets, new competitors rework is required.
- New technologies open up new possibilities for improving - i.e. develop a prototype to show some key features of the
implementations system to users, let them refine requirements before
- New platforms require application changes committing to them.

• Change leads to rework: • Change tolerance: design the process to

- new requirements lead to more requirements analysis accommodate change at low cost
- this may lead to redesign of the system or components - Use incremental development, get feedback from users.
- this may lead to changes to the implementation - Changes likely apply to most recent increment only, OR
- this may lead to new tests, and re-testing the system - Can be incorporated into later increments.

!25 !26

Software prototyping Prototype process

• Prototype: an initial, incomplete, version of a system • Objectives for prototype should be made in advance
used to demonstrate concepts and try out options. - Decide what to put in, what to leave out.

• Allows users to see how well system could support • Must be developed quickly!
their work
• Users test the prototype and evaluate it with respect
• May lead to new ideas for requirements to the objectives
• As prototype is developed, may reveal errors and • Prototypes should be discarded after use!
omissions in the requirements - It may be impossible to tune the prototype to meet performance
and reliability requirements
• Can check feasibility of design - Prototypes are normally undocumented
- For a database, make sure it efficient for most common queries - The structure is usually degraded through quick and dirty design
- For a user interface, user understands a prototype much better - The prototype probably will not meet normal organizational
than a text description (get better feedback). quality standards.
!27 !28
 Incremental delivery Incremental delivery problems
• Special case of Incremental Development where • Generally same problems as Incremental
each version is delivered to users. Development
- Difficult to design and implement common facilities needed by
• Generally same advantages as Incremental all versions
Development - Constant upgrading can degrade structure of code
- Good response to changing requirements

• Major system functionality is available to users earlier. • Contract negotiations are more difficult
- The specification is developed in stages
• Early increments act as a prototype to help elicit - Unable to use it as part of the development contract.
requirements for later increments.
• Difficult to get feedback when replacing an existing
• Highest priority requirements are included in early system:
increments, so they receive the most testing. - Users won’t be motivated to use the less functional new
system.
!29 !30

4. The (Rational) Unified Process Four phases of UP

• INCEPTION
• Unified Process: A popular software process - High level requirements established
- a hybrid process: iterative/incremental AND staged. - Key risks identified

• Has 4 main phases or stages. • ELABORATION

- correspond to business concerns, not technical - Significant elements (core architecture) are
activities programmed and tested

• Each phase may contain several iterations. • CONSTRUCTION

- Remainder of system is built and tested
• Has 6 disciplines (= activities) performed
• TRANSITION
across the 4 phases. - The system is fully deployed to the customer
• Each phase involves all the disciplines, in Certain milestones must be completed in each phase,
varying amounts. before moving on to the next one.
!31 !32
 Disciplines of UP Phases of UP

• Business Modeling • Disciplines over the phases

- business processes are modeled using use cases - each column is an iteration.
• Requirements
• Design
• Implementation
• Testing
• Deployment
- product is released, distributed, and installed

• Project Management
- scheduling, managing resources

!33 !34

The Rational Unified Process

• Rational Unified Process (RUP) is a

refinement or specialization of UP
- A product from IBM
- Hyperlinked knowledge base with sample artifacts
- Enables developer organization to tailor UP to its
needs:
❖ allows developer to select appropriate elements

of the process
❖ manages documentation

❖ provides tools for applying the process

!35