1

CSE

2102

CSE

2102

Chapter 7: The Software ProcessChapter 7: The Software Process

Prof. Steven A. DemurjianComputer Science & Engineering Department

The University of Connecticut371 Fairfield Road, Box U-2155

Storrs, CT 06269-2155

steve@engr.uconn.eduhttp://www.engr.uconn.edu/

~steve(860) 486 – 4818

(860) 486 – 3719 (office)

2

CSE

2102

CSE

2102

Overview of Chapter 7 Software Production Process Models

Focus on the “How” of Software Development Stages, Phases, Steps: Methodology

Consider Six Process Models Waterfall Model Evolutionary Model Transformation Model Spiral Model UML Unified Process (Slide 85ff – UML Slides) Agile Software Development

Other Process Issues Configuration Management Standards

3

CSE

2102

CSE

2102

Software Production Process Phases and Actions to Build, Deliver, Evolve Product Objectives

Construct Programs from Idea to Completion Produce Reliable, Predictable, and Efficient SW

Difficult to Automate Software Production is a Highly Intellectual

Activity Software is Highly Instable Interactions of Individuals from Various

Backgrounds Interface to OS, Hardware, Databases, etc.

Production Models Focus on the Software Lifecycle Emphasizing the Process from Start to Finish

4

CSE

2102

CSE

2102

Motivation Increase in Application Complexity and Requirements

has Led to Separation Between Developers and Users Software Now Targets Users without “Computer

Expertise” Higher Level of Quality and Reliability Needed Software Development as Group Activity

Software Development Needs to: Manage Complexity in Modern Applications Provide Detailed Careful Analysis of User

Requirements Boehm States that Goals of a Process Model are:

Determine Appropriate Stages Establish Transition Criteria for Progressing from

One Stage to Another

5

CSE

2102

CSE

2102

Design andSpecification

Waterfall Model – Classic Approach

Completion of All Phases (thru Delivery) Implies a Valid, Verified Product

Intended for Traditional Procedural PLs (C, Pascal, Fortran, PL/I, etc.)

Multiple Phases for Development

Complete One Phase before Next Begins

Requirements Analysis andSpecification

Coding andModule Testing

Integration andSystem Testing

Delivery

Maintenance

FeasibilityStudy

6

CSE

2102

CSE

2102

Waterfall Model First Appeared in late 1950s - Popularized in 1970s Describes a Sequential Linear Flow Among Phases Output of one Phase is Input to Next Many Variants of Waterfall Model Software Categories Influence Variants of Model

Customized Software for Particular Customer Customized Software for Company Generalized Application for Commercial Market

Software Production Companies Define Outputs for Each Phase Define Methods to be used to Produce Outputs Organize Methods into SW Development

Methodology Briefly – Let’s Review Each Phase

7

CSE

2102

CSE

2102

Feasibility Study Purpose: Produce a Feasibility Study Document that

Evaluates Cost and Benefits of Application People: Customer, End User, SW Engineers Contents Highly Dependent on Application Domain Feasibility Study Should Contain:

Definition of the Problem Alternative Solutions and Expected Benefits Required Resources, Costs, and Delivery Dates Global Problem Analysis Decide Future Worth of Software

How Complete can this Document be early in the Development Process?

8

CSE

2102

CSE

2102

Requirements Analysis/Specification Purpose: Identify Required Qualities of Application People: Interactions Between Users & SW Engineers States the Required Qualities not How Attained Produces a Requirements Specification Document

Formal Methods Translated into Natural Language for End Users

Includes User Manual with Screen Mockups System Test Plan and Strategies/Scenarios Critical Issues of

Separation of Concerns Abstraction Modularity

9

CSE

2102

CSE

2102

Requirements Analysis/Specification Vertical Modularity: Each Module Hides Lower Level

Design Decisions Horizontal Modularity: System is Collection of Views

of Some Level of Abstraction – Provide View of Model of Data (ER or other Diagram) Model of Functions (DFD, SC, AD, etc.) Model of Control (Petri Nets, FSM, etc.)

Requirements Specification Document Contains Functional Requirements – what Product Does Non-Functional Requirements

Reliability (Available, Secure, Integrity, Safety, …) Accuracy of Results, Performance, HCI Operating/Physical Constraints, Portability, …

10

CSE

2102

CSE

2102

Design and Specification Purpose: Decompose System into Modules People: SW Engineers and Managers Produces a Design Specification Document

Containing a Description of Software Architecture Decomposition usually has Two Phases:

Preliminary Design Detailed Design

Design Specifications Document Must Follow a Company’s Standard

Design Alternatives Proposed and Evaluated Multiple Ways to Solve Problem Paper Methods (Simulation, Queueing, etc.) Evaluate w.r.t. Requirements Analysis/Spec

11

CSE

2102

CSE

2102

Coding and Module Testing Purpose: Actually Code and Test Software People: SW Engineers and Managers, End Users (test) Programming-in-the Small Alternatives Implemented and Evaluated

List vs. Array vs. API (Set, Collection, …) Different Algorithms w.r.t. Space and/or Time

Usage of Company Wide Standards Program Layout, Comments and Headers, Naming

Conventions Module Testing (WBT, BBT) also via Standards Other Activities Include

Code Inspection for Adherence to Standards Check for Software Qualities (Performance)

12

CSE

2102

CSE

2102

Integration and System Testing Purpose: Assemble Application from Individual

Components and Test People: SW Engineers, Teams, Managers, Users Programming-in-the Large Collections of Modules and Entire System Tested

Incremental Testing Big-Bang Testing

Alpha Testing – Test Under Realistic Conditions with “Understanding” or “Forgiving” Users

Usage of Company Wide Standards Method of Integration Test Data Design Documentation of Tests and Results

13

CSE

2102

CSE

2102

Delivery and Maintenance Purpose: Application Distributed to Users and

Supported via Maintenance/Evolution (A, C, and P) People: Shipping Personnel, SWE, End Users Two Stage Deliver

Beta Testing – Selective Group of Expected Users to Shake out all Bugs

Product Delivered to Customers Leintz and Swanson’s Study Found:

Changes to User Requirements 42% Changes in Data Format 17% Emergency Fixes 12% Routine Debugging 9% Hardware Changes 6% Documentation Improvements 5% Efficiency Improvements 4%

14

CSE

2102

CSE

2102

Other Activities in Waterfall Model Documentation

Waterfall Model is Document Driven Output of Phases is Documented Company Standards Dictate Document Format

Verification Emphasized During Module and System Testing Appropriate Verification Occurs via Reviews,

Walk-Throughs, Code Inspection Goal – Monitor Application Quality Throughout

Development Process – Discover/Remove Errors Management

Tailor the Process to Fit the Product Configuration and Version Management Human Resources (Personnel and Organization)

15

CSE

2102

CSE

2102

Waterfall Model - Evaluation Contributions to Understanding Software Processes

Software Development Must be Disciplined, Planned, and Managed

Implementation Delayed Until Objectives Clearly Understood

Characteristics of Waterfall Model Linear: From Beginning to End w/o Backtracking Rigidity:

Results of Each Phase Completed Before Proceeding to Next Phase

Assumes Requirements and Specs Finalized Monolithic: All Planning is Oriented to Single

Delivery Date What are the Problems with this Process?

16

CSE

2102

CSE

2102

Waterfall Model - Evaluation Problems with Waterfall Model

Forces Cost Estimation and Project Planning to Occur After Limited Analysis Performed

Verification of Requirements Spec Document Performed by Customer Not Very Effective

Unrealistic to Assume all Requirements Frozen before Development Starts User’s Often Don’t Know Exact Requirements Particularly Early in the Process

Does not Stress Anticipating Changes Enforces Standards Based on Producing Particular

Documents at Specific Times

17

CSE

2102

CSE

2102

Waterfall Process Model with FeedbackWaterfall Process Model with Feedback

Requirements Analysis andSpecification

Design andSpecification

Coding andModule Testing

Integration andSystem Testing

Delivery and Maintenance

50 %50 %

50 %50 %

18

CSE

2102

CSE

2102

Evolutionary Model F. Brooks Advocates Producing a Product Twice

First Version is Throwaway to Provide Means for Users to Offer Feedback on Exact Requirements

Second Version Developed using Waterfall Evolutionary or Incremental Approach

Emphasizes Stepwise Development Flexible and Non-Monolithic Postpones Parts of Some Stages

Several Different Variants of Evolutionary Model

19

CSE

2102

CSE

2102

Evolutionary Process Model Variant Boehm: “Model Whose stages Consist of Expanding

Increments of an Operational Software product, with the Direction of Evolution being Determined by Operational Experience”

Delivered Increment: Self-Contained Functional Unit that is Useful to the Customer Includes Supporting Material (Doc, Test Plans,

Training Materials, etc.) Development Strategy

Deliver Something to the Real User Measure Added Value to user Adjust Design and Objectives Accordingly

Must Use Waterfall Process Discipline Use Increments to Evolve toward Desired Product

20

CSE

2102

CSE

2102

Incremental Implementation Model Variant Waterfall Model Used until Implementation Phase

Implementation Done Incrementally Requires Analysis and Design Emphasis on Useful,

Deliverable Subsets/Flexible Interfaces Different Plans are Implemented, Tested, and

Delivered at Different Times Incremental Implementation is only a Partial

Solution May be Missing Functional (Buttons Don’t Work) May Simulate Portions (Canned Info instead of DB)

What are Advantages? Disadvantages?

21

CSE

2102

CSE

2102

Incremental Development & Delivery Model Incremental Approach Applied to All Waterfall Phases

Achieves Finer Granularity in the Process Waterfall Model Followed for Different Portions Increments Developed After user Feedback Users can Understand What they Actually Need

All Evolutionary Approaches Incorporate Maintenance into Every Stage of the

Model Employ Evolutionary Prototype that is

Progressively transformed into Final Application Prototyping Helps SWEs Understand User Needs Requires Tools such as Visio, Rapid GUI tools, etc.

22

CSE

2102

CSE

2102

Assessing Evolutionary Models Problems:

Large Time Gap Between Requirements Specification and Delivery

Emphasis on User Interface and Not Product May Miss Functional Requirement May Underestimate DB Complexity/Interactions

Requires Tools to Manage Process (Doable Today) Advantages:

Product May Closely Follow User Requirements Supports Anticipation of Change More Flexible Than Just Waterfall Approach

23

CSE

2102

CSE

2102

Transformation Model Roots in Formal Specification that Views SW D & D

as Steps to Transform Spec to Implementation1. Internal Requirements are Analyzed and Formally

Specified2. Formal Specification Transformed into Detailed,

Less Abstract Formal Description3. Repeat Step 2 Until Description is Executable by

Some Abstract Processor4. Further Transformations may be Needed to

Increase Efficiency Transformations may be Performed manually by SWE

or by Automated Support System

24

CSE

2102

CSE

2102

Requirements analysis and specification

OptimizationRequirements

Formal specifications

Verification Tuning

Lower level specifications

Recording of developmental history

Reusable components

Decisions & rationale

Transformation ModelTransformation Model

25

CSE

2102

CSE

2102

Transformation Model Two Main Stages

Requirements Analysis for Formal Requirements Optimization for Performance Tuning

Transformation Controlled by Software Engineering Take Advantage of Reusable Components Verify Against user Expectations Supported by Software D&D Environment

Tools for Requirements Verification, Managing Reusable Components, Optimizing, Config. Mgmt.

Transformation Model Studied for Small Programs to Mathematically Prove Correctness

Idea of an Automated Assistant to Watch Over the Shoulder of Software Engineers Isn’t this What Today’s SDEs/IDEs Provide?

26

CSE

2102

CSE

2102

Spiral Model Purpose: Provide a Framework for Design Production

Process Guided by Risk Levels Guiding Principles: Level of Risk (Potential Adverse

Circumstance) Risk Management (Boehm): “Discipline whose

objectives are to identify, address, and eliminate software risk items before they become either threats to successful software operation or a major source of expensive software rework.”

Focus on Identifying and Eliminating High Risk Problems by Careful Process Design/Assessment

27

CSE

2102

CSE

2102

Spiral Model Cyclical Model is Four Stages:

1. Identify Objectives and Design Alternatives2. Evaluate Alternatives and Identify/Deal with

Potential Risks3. Develop and Verify Next Level Product4. Review Results and Plan for Next Iteration

Allows Unstated Requirements to Become Part of Specification of Next Cycle Robustness Approximates Correctness More

Closely

28

CSE

2102

CSE

2102

The Spiral ModelThe Spiral Model

29

CSE

2102

CSE

2102

The Spiral ModelThe Spiral Model

30

CSE

2102

CSE

2102

The Spiral ModelThe Spiral Model

31

CSE

2102

CSE

2102

UML Unified Process UML as a Model Can’t Work in Isolation Large Scale System Design/Development Involves

Team-Oriented Efforts Software Architectural Design System Design, Implementation, Integration

The Unified Process by Rational is Iterative and Incremental Use Case Driven Architecture-Centric

32

CSE

2102

CSE

2102

Creating the Unified ProcessCreating the Unified Process

Functional testingPerformance testingRequirements mgmt

Conf. and change mgmtBusiness engineering

Data engineeringUI design

Rational Unified Process 5.01998

Rational Objectory Process 4.11996-1997

Objectory Process 1.0-3.81987-1995

Ericsson Approach

Rational Approach UML

33

CSE

2102

CSE

2102

New or changed

requirements

New or changed

system

Software EngineeringProcess

What Is a Process?

Defines Who is doing What, When to do it, and How to reach a certain goal.

34

CSE

2102

CSE

2102

Lifecycle Phases

time

Inception Elaboration Construction Transition

Inception Define the scope of the project /develop business case

Elaboration Plan project, specify features, and baseline the architecture

Construction Build the productTransition Transition the product to its

users

35

CSE

2102

CSE

2102

ManagementEnvironment

Business Modeling

Implementation

Test

Analysis & Design

Preliminary Iteration(s)

Iter.#1

PhasesProcess Workflows

Iterations

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration Mgmt

Requirements

Elaboration TransitionInception Construction

Unified Process Iterations and WorkflowUnified Process Iterations and Workflow

36

CSE

2102

CSE

2102

Workflows and ModelsWorkflows and Models

Requirements

Design

Implementation

Test

Analysis

Use CaseModel

DesignModel

Deploym.Model

Impl.Model

AnalysisModel

TestModel

UML diagrams provide views into each model

Each workflow is associated with one or

more models.

37

CSE

2102

CSE

2102

Use Case ModelUse Case Model

Use CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

38

CSE

2102

CSE

2102

Analysis & Design ModelAnalysis & Design Model

Use CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

Incl. subsystems and packages

39

CSE

2102

CSE

2102

Deployment and Implementation ModelDeployment and Implementation Model

Use CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

Incl. active classes and components

40

CSE

2102

CSE

2102

Test ModelTest Model

Use CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

Test model refers to all other models and uses

corresponding diagrams

41

CSE

2102

CSE

2102

Use Case Driven

Reqmt.’s Impl. Test

Use Cases (scenarios) bind these workflows together

Analysis Design

42

CSE

2102

CSE

2102

Use Cases Drive Iterations Drive a Number of Development Activities

Creation and Validation of the System’s Architecture

Definition of Test Cases and Procedures Planning of Iterations Creation of User Documentation Deployment of System

Synchronize the Content of Different Models

43

CSE

2102

CSE

2102

Architecture-Centric

Models Are Vehicles for Visualizing, Specifying, Constructing, and Documenting Architecture

The Unified Process Prescribes the Successive Refinement of an Executable Architecture

timeArchitecture

Inception Elaboration Construction Transition

44

CSE

2102

CSE

2102

Architecture and ModelsArchitecture and Models

Architecture embodies a collection of views of the models

Views

Models

Use CaseModel

DesignModel

Deploym.Model

Impl.Model

TestModel

AnalysisModel

45

CSE

2102

CSE

2102

Logical Application ArchitectureLogical Application Architecture

RelationalDatabase

GraphicalUser

Interface

RelationalDatabase

GraphicalUser

Interface

BusinessObjectModel

GraphicalUser

Interface

BusinessObjectModel

RelationalDatabase

46

CSE

2102

CSE

2102

Physical Application ArchitecturePhysical Application Architecture

Relational Database Server(s)

Client CWWW Browser

WebServer

HTMLCGI ASP Java

Business ObjectServices

Business ObjectEngine

Application

Business ObjectServices

Client A

Business ObjectEngine

Thinner client, thicker server

Client B

Application

Business ObjectServices

Business ObjectEngine

Business Object Server

DCOMADO/R

CORBA Beans

COMMTS

BeansETS

47

CSE

2102

CSE

2102

Complex Internet System

Client

Server

ApplicationServer

FulfillmentSystem

FinancialSystem

InventorySystem

RDBMSServer

Dynamic HTML, JavaScript, Javaplug-ins, source code enhancements

Java, C, C++, JavaScript, CGI

Java, C, C++, JavaBeans, CORBA, DCOM

Native languages

48

CSE

2102

CSE

2102

Use cases Architecture

Function versus Form

Use Case Specify Function; Architecture Specifies Form

Use Cases and Architecture Must Be Balanced

49

CSE

2102

CSE

2102

The Unified Process is EngineeredThe Unified Process is Engineered

Describe a Use Case

Use case package

Use case

responsible for

Analyst

Artifact

A piece of information that is produced, modified, or used

by a process

Worker

A role played by an individual or a team

Activity

A unit of work

50

CSE

2102

CSE

2102

Agile DevelopmentAgile Development

Jump to Other Presentation

51

CSE

2102

CSE

2102

Configuration Management Configuration

Identifies Components and Their Versions Configuration Management

Discipline of Coordinating Software Development And Controlling the Change and Evolution of Software Products and Components

Multiple Access to Shared Repository Handling Product Families

Different Members of the Family Comprise Components Which May have Different Versions

52

CSE

2102

CSE

2102

Versions Version Management Differentiates Between

Revisions New Version Supersedes the Previous Define a Linear Order

Variants Alternative Implementations of the Same Specification

for Different Machines, or Access to Different I/O Devices

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

53

CSE

2102

CSE

2102

Software Standards Standards are Needed to Achieve Quality In Both

Software Products and Processes Standards May Be Imposed Internally or Externally

E.G., MIL-STD 2167A Imposed To Contractors For Military Applications

Other Examples: ISO Series, IEEE DOIT Standards for All Types of

Methodologies Tools Documentation Web Development etc. etc. etc.

54

CSE

2102

CSE

2102

Main Benefits of Standards From Developers' Viewpoint

Standards Enforce a Uniform Behavior Within an Organization Facilitate Communication Among People Stabilizes Production Process Makes It Easier to Add New People to Ongoing

Projects From Customers' Viewpoint

Make It Easier to Assess the Progress And Quality Of Results

Reduce the Strict Dependency of Customers on Specific Contractors

55

CSE

2102

CSE

2102

Chapter 7 Summary Software Process Methodologies are Crucial to

Control the Process from Idea to Maintenance Many Different Approaches Waterfall, Evolutionary, Transformation, Spiral Unified Process of UML Agile Process All Share Similar Terminology Influenced by

Original Waterfall Model Phases Relevant – Today Incremental Focus

What’s Coming Up… Project Management and Planning Tools and Environments Underlying Infrastructure that Supports Process