the software production process - mcmaster university

Ch. 7 1

The software production process

Ch. 7 2

Questions

• What is the life cycle of a software product?

• Why do we need software process models?

• What are the goals of a software process and what makes it different from other industrial processes?

Ch. 7 3

Outline• Traditional answer: "waterfall" lifecycles• Flexible, incremental processes• Case studies

– "synchronize-and-stabilize" (Microsoft)– the "open source" development model

• Organizing the process– software methodologies– the "Unified Process"

• Organizing artifacts: configuration management

• Standards

Ch. 7 4

Life cycle

• The life cycle of a software product– from inception of an idea for a product

through• requirements gathering and analysis• architecture design and specification• coding and testing• delivery and deployment• maintenance and evolution• retirement

Ch. 7 5

Software process model

• Attempt to organize the software life cycle by

• defining activities involved in software production

• order of activities and their relationships

• Goals of a software process– standardization, predictability, productivity,

high product quality, ability to plan time and budget requirements

Ch. 7 6

Code&Fix

The earliest approach• Write code• Fix it to eliminate any errors that have

been detected, to enhance existing functionality, or to add new features

• Source of difficulties and deficiencies– impossible to predict– impossible to manage

Ch. 7 7

Models are needed

• Symptoms of inadequacy: the software crisis– scheduled time and cost exceeded– user expectations not met– poor quality

• The size and economic value of software applications required appropriate "process models"

Ch. 7 8

Process model goals (B. Boehm 1988)

"determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions:

What shall we do next?How long shall we continue to do it?"

Ch. 7 9

Process as a "black box"

Product

Process

Informal Requirements

Ch. 7 10

Problems

• The assumption is that requirements can be fully understood prior to development

• Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)

• Unfortunately the assumption almost never holds

Ch. 7 11

Process as a "white box"

Product

Process

Informal Requirements

feedback

Ch. 7 12

Advantages

• Reduce risks by improving visibility• Allow project changes as the project

progresses– based on feedback from the customer

Ch. 7 13

The main activities

• They must be performed independently of the model

• The model simply affects the flow among activities

Ch. 7 14

Feasibility study

• Why a new project?– cost/benefits tradeoffs– buy vs make

• Requires to perform preliminary requirements analysis

• Produces a Feasibility Study Document1. Definition of the problem2. Alternative solutions and their expected benefits3. Required resources, costs, and delivery dates in

each proposed alternative solution

Ch. 7 15

Requirements engineering activities

Ch. 7 16

Requirements engineering

• Involves – eliciting– understanding– analyzing– specifying

• Focus on– what qualities are needed, NOT on– how to achieve them

Ch. 7 17

What is needed

• Understand interface between the application and the external world

• Understand the application domain• Identify the main stakeholders and

understand expectations– different stakeholders have different

viewpoints– software engineer must integrate and

reconcile them

Ch. 7 18

The requirements specification document (1)

• Provides a specification for the interface between the application and the external world– defines the qualities to be met

• Has its own qualities– understandable, precise, complete,

consistent, unambiguous, easily modifiable

Ch. 7 19

The requirements specification document (2)

• Must be analyzed and confirmed by the stakeholders– may even include version 0 of user manual

• May be accompanied by the system test plan document

Ch. 7 20

The requirements specification document (3)

• As any large document, it must be modular– "vertical" modularity

• the usual decomposition, which may be hierarchical

– "horizontal" modularity• different viewpoints

• Defines both functional and non functional requirements

Ch. 7 21

A case studyrailway automation

• Who are the stakeholders?– management of the train company– train drivers and their unions– passengers (customers)– contractors

• Each has different goals

Ch. 7 22

Case studyhow to classify requirements

• Safety requirements– the probability of accidents should be less

than 10-9 per year

• Utility requirements– level of usefulness of the system as

perceived by the various stakeholders

Ch. 7 23

Case studythe produced document

• Introduction: the “mission” of the system• Architecture: the main structure of the

system• Specific requirements associated with each

subsystem– discussion of how the subsystems’ requirements

guarantee that the overall goals are indeed achieved

Ch. 7 24

Software architecture and detailed design activity

• The result of this activity is a Design Specification Document

• Usually follows a company standard, which may include a standard notation, such as UML

Ch. 7 25

Coding and module testing activity

• Company wide standards often followed for coding style

• Module testing– based on black box/white box criteria

Ch. 7 26

Integration and system test activity

• These activities may be integrated with coding and module testing

• Integration may be done incrementally through subsystems– top down vs. bottom up

• The last step is system test– may be followed by alpha testing

Ch. 7 27

Delivery, deployment, and maintenance activities

• Delivery– real delivery may be preceded by beta

testing• Deployment

– components allocated on physical architecture

• Maintenance– corrective, adaptive, perfective

Ch. 7 28

Maintenance

• Requirements errors are main cause of maintenance activities

• Late discovery of requirements errors causes increased costs

Ch. 7 29

Other software activities

• Documentation• Verification• Management

They can be considered as parts of any kind of software related activity

Ch. 7 30

Overview of software process models

Ch. 7 31

Waterfall models (1)

• Invented in the late 1950s for large air defense systems, popularized in the 1970s

• They organize activities in a sequential flow

• Exist in many variants, all sharing sequential flow style

Ch. 7 32

Feasibility study

Requirements

Design

Coding and module testing

Integration and system testing

Delivery, deployment, maintenance

A waterfall model

Ch. 7 33

Waterfall models (2)• Organizations adopting them

standardize the outputs of the various phases (deliverables)

• May also prescribe methods to follow in each phase– organization of methods in frameworks

often called methodology• Example: Military Standard (MIL-STD-

2167)

Ch. 7 34

Critical evaluation of the waterfall model

+sw process subject to discipline, planning, and management

+postpone implementation to after understanding objectives

– linear, rigid, monolithicno feedbackno parallelisma single delivery date

Ch. 7 35

Feasibility study

Requirements

Design

Coding and module testing

Integration and system testing

Delivery, deployment, and maintenance

Waterfall with feedback

Ch. 7 36

Problems with waterfall

• Estimates made when limited knowledge available

• Difficult to gather all requirements once and for all– users may not know what they want– requirements cannot be frozen

Ch. 7 37

Evolutionary models• Many variants available• Product development evolves through

increments– "do it twice" (F. Brooks, 1995)– evolutionary prototype

• Evolutionary process model (B. Boehm, 1988)"model whose stages consist of expanding

increments of an operational software product, with the direction of evolution being determined by operational experience"

Ch. 7 38

Incremental delivery

• Identify self-contained functional units that may be delivered to customers

• To get early feedback– According to T. Gilb, 1988:

• Deliver something to the real user• Measure the added value to the user in all

critical dimensions• Adjust design and objectives

Ch. 7 39

Transformation model

• Guided by formal methods• Specifications transformed into

implementations via transformations• Still a theoretical reference model

Ch. 7 40

Requirements analysis and specification

OptimizationRequirementsFormal specifications

Verification Tuning

Lower level specifications

Recording of developmental history

Reusable components

Decisions & rationale

Transformation model

Ch. 7 41

Spiral modelB. Boehm, 1989

Ch. 7 42

A final model assessment(1)

• Waterfall– document driven

• Transformational– specification driven

• Spiral– risk driven

Ch. 7 43

A final model assessment(2)

• Flexibility needed to reduce risks– misunderstandings in requirements– unacceptable time to market

• Waterfall may be useful as a reference structure for documentation– describes the "rationale" a posteriori

(Parnas and Clements, 1989)

Ch. 7 44

Legacy software

Ch. 7 45

Software evolution• Existing software must evolve because

requirements change• Re-engineering

– process through which an existing system undergoes an alteration, to be reconstituted in a new form

• Reverse engineering– from an existing system to its documentation,

which may not exist, or may be incomplete– includes program understanding– preventive maintenance

Ch. 7 46

Case study

Synchronize&Stabilize(The Microsoft Software Process)

Ch. 7 47

The process

• Planning phase– vision of the product, specification, schedule

• Development – team composed of 2 groups

• developers and testers (continuous testing)

– process prescribes• daily synchronization• product stabilization

Ch. 7 48

Case study

The Open Source Approach

Ch. 7 49

Open source

• Regulates licensed software, specifying its use, copy, modification, and distribution rights

• Business does not derive from selling software, but rather from other, indirect activities (services, accessories, advertisement, etc.)

Ch. 7 50

The process• Highly distributed process characterized

by frequent iterations– wide availability of source code– openness to contributions from a large

community of developers

• Enabling technology– Internet (large scale and fast collaborations)– repositories with version control and

configuration management

Ch. 7 51

Methodologies to organize the process

Ch. 7 52

SA/SD

• Structured Analysis/Structured Design• 3 major conceptual tools for modeling

– data flow diagrams• functional specifications

– data dictionaries• centralized definitions

– Structured English• to describe transformation of terminal bubbles

Ch. 7 53

DFDs: a reminderA file

Adata

transformer

An output deviceAn input

device

Ch. 7 54

Employee_1

Registration

Employee_2

Authorization

Employee_3

Response

Request

Request

Result

Authorized_requests

Employee_4Employee_6Employee_5

Process ProcessProcess

Order_request

Complete_order

Analysis ofoffice work

Ch. 7 55

Extract order data

Get letter form

Order request

Letter form

Letter forms

Quantity to order

Type of letter

Compose order

Get address

Addresses

Address

Addressee

AddressComplete order

Authorized requests

Automatedportion

Ch. 7 56

From analysis to design

• Use of Structured Diagrams (SDs)• A "method" is provided to transform

DFDs into SDs; tries to– minimize coupling– maximize cohesion

Ch. 7 57

SD• A DAG of functional modules (direction of arrow is implicitly downward)

M

MMM 1 32

Ch. 7 58

Decorated SDs

M

MM 1 2

B

C

selection loopdata flow X

A

Ch. 7 59

Decorated SDsM

MMM 1 32

M 1,1 M 1,2

XX Y

Y

X XX

11

M1 abstract inputM2 transformationM3 abstract output

Ch. 7 60

SD for the "order" DFD

Order main

Get data

Produce data for order form

Print order form

T

Q

AE

AE

T

A

L

A

L

Q

Ch. 7 61

JSD and JSP

• Jackson's System Development– modeling stage

• analysis and modeling of the external world– entities– actions (described by process structure diagram)

– network stage• system modeled as a network of

interconnected and communicating processes—system specification network (SSN)

– implementation stage

Ch. 7 62

A

DCB

(a)

PSD(a) sequence(b) selection(c) iteration

X

Y*

(c)

H

L Mo o

(b)

Ch. 7 63

Network stage (SSNs)

P QA

(a) Processes connected by data structure

P' Q'A'

(b) Connection by state vector

Ch. 7 64

Implementation stage (JSP)Transfer order file

Item group

Transfer record

Receipt Delivery

*

*

o o

Output report

Header Body

Net item transfer

*

Input and output data structuresCorrespondence between nodes

Program structure

Ch. 7 65

Program

Generate header

Generate body

Generate * line byitem group

Processitemgroup

Output net movementline

Processrecord

*

Processreceipt

oProcessdelivery

o

1. open files

2. close files

3. read (item_id, movement)

4. net_item_movement := 0

5. net_movement_item := net_movement_item + movement

6. net_movement_item := net_movement_item - movemen

7. write (header)

8. write (net_item_movement_line)

t

The resulting programstructure

Ch. 7 66

Program

Generate header

Generate body

Generate * line by item group

Process item group

Process record

*

Process receipt

oProcess delivery

o

1, 3, 7 2

4 8

3

5 6

Output net transfer line

(c)

Annotated programstructureTrivially translatableinto a program

Ch. 7 67

Unified Software Development Process

(UP)

Ch. 7 68

Principles

• Development of an OO system• Uses the UML notation throughout the

process• Supports an iterative and incremental

process• Decomposes a large process into

controlled iterations (mini projects)

Ch. 7 69

Cycles and phases of a cycle

time

death

cycle1 ... cycle2 cycle n

productreleases

Inception Elaboration Construction Transitionproductrelease

milestone

Ch. 7 70

Distribution of workflows over phases

inception elaboration construction transition

Iter1 Iter2 ... ... ... ... ... ... ... ... Iter n

Requirements

Analysis

Design

Implementation

Testing

Ch. 7 71

Organizing artifactsConfiguration management

Ch. 7 72

CM concepts

• Configuration– identifies components and their versions

• Configuration management– discipline of coordinating software

development and controlling the change and evolution of software products and components

Ch. 7 73

Key CM issues

• Multiple access to shared repository• Handling product families

– different members of the family comprise components which may have different versions

Ch. 7 74

Member 1

A

B

C1

Member 2

A

B

C2

Member 3

A

D

1

2

3

A

A

B

D

E

A

C C

1

1

2

2

3

Component database

Ch. 7 75

Baseline and private workspaces

• Project baseline– central repository of reviewed and

approved artifacts that represent a given stable point in system development

• Private workspaces– private and intermediate versions of

components

Ch. 7 76

Versions

• Can be refined into– revisions

• new version supersedes the previous• define a linear order

– variants• e.g., alternative implementations of the same

specification for different machines, or access to different I/O devices

Ch. 7 77

Derived versions

• Further logical relations may exist among versions of components

• A component may be derived from another– object code component is a derived version

of a source code component

Ch. 7 78

Software standards

Ch. 7 79

Why standards?

• They are needed to achieve quality in both software products and processes

• They may be imposed internally or externally– e.g., MIL-STD 2167A imposed to

contractors for military applications

• Other examples: ISO series, IEEE

Ch. 7 80

Main benefits• From the developers' viewpoint

– standards enforce a uniform behavior within an organization

– they facilitate communication among people, stabilizes the production process, and makes it easier to add new people to ongoing projects

• From the customers' viewpoint– they make it easier to assess the progress and

quality of results– they reduce the strict dependency of customers on

specific contractors

Ch. 7 81

Issues with standards

• Freezing premature standards– can inhibit acceptance of new ideas

• Standards proliferation• De-facto standards vs. official standards