Top Banner
Aditya P. Mathur Department of Computer Sciences Purdue University Monday April 1, 2002 4:30-5:20pm PHY 112 Last update: April 1, 2002 The Software Development Process: Getting it Right!
35
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Software Testing

Aditya P. MathurDepartment of Computer Sciences

Purdue University

Monday April 1, 2002

4:30-5:20pm

PHY 112

Last update: April 1, 2002

The Software Development Process: Getting it Right!

Page 2: Software Testing

April 1, 2002 Software Process 2

Learning Objective

To understand the importance and basics of Software Process.

Page 3: Software Testing

April 1, 2002 Software Process 3

What is Software Process?

Organized collection of methods used in the development of a software product.

Requirements Analysis

Design

Coding

Testing

Maintenance

Deployment

Retirement

Page 4: Software Testing

April 1, 2002 Software Process 4

Why is Software Process important?

Over the years hardware:software cost ratio has changed dramatically.

Companies that sell hardware, e.g. Intel and Tektronix, appear to be hardware companies but a significant portion of their expense is towards the development and maintenance of software.

A well defined and implemented process has generally led to improved quality of the product at a lower cost.

Soon we shall examine supporting evidence.

Page 5: Software Testing

April 1, 2002 Software Process 5

What does software process aims to achieve?

High quality: measured in terms of Faults per delivered KLOC.

Lower cost of development.

Lower cost of maintenance.

Page 6: Software Testing

April 1, 2002 Software Process 6

How does it achieve ?

Discipline, planning, training.

Finding errors as soon as possible: An error made in the requirements phase, and not fixed in this phase, may cost 50-350 times when fixed during the maintenance phase.

Control: Collect data, look for problems, find ways to resolve them.

Continuous involvement of the customer.

Page 7: Software Testing

April 1, 2002 Software Process 7

Supporting Evidence: First…What is “Process Maturity ?”

Defined by the Software Engineering Institute at CMU [1986].

Measured in terms of 5 levels.

Level 1: Initial [Least mature]

Level 2: Repeatable

Level 3: Defined

Level 4: Managed

Level 5: Optimized [Highly mature]

Page 8: Software Testing

April 1, 2002 Software Process 8

Are there benefits of a mature process?

Hughes Aircraft: Software Division:

1987-1990: ~$500K spent in process improvement

Moved up from Level 2 to Level 3

Annual savings: ~$2 million

Page 9: Software Testing

April 1, 2002 Software Process 9

And…more good experience…

Comparable results at the Equipment Division of Raytheon

Moved up from Level 1 to Level 3

Two fold increase in productivity

Annual savings: $7.70 for every dollar invested in process improvement

Page 10: Software Testing

April 1, 2002 Software Process 10

A summary of benefits [Motorola, 1997]

Level Faults/MEASL Decrease in durationduring development

1 - 1.0

3 411 2.7

2 890 3.2

4 205 5.0

5 126 7.8

MEASL: Million equivalent assembler code lines

Page 11: Software Testing

April 1, 2002 Software Process 11

Where does the cost of production lie?

Phase Cost (HP)

Requirements 18%

Implementation 34%

Design 19%

Integration 29%

Page 12: Software Testing

April 1, 2002 Software Process 12

Another view of cost…

Phase Cost (HP)

Requirements 2%

Design 6%

Analysis 5%

Module coding 5%

Unit testing 7%

Integration 8%

Maintenance 67%

Ye great coders! Notice the relative importance of coding!

Page 13: Software Testing

April 1, 2002 Software Process 13

Software Life Cycle

Steps used in the development, maintenance, and retirement of a software product.

Page 14: Software Testing

April 1, 2002 Software Process 14

Models of Software Life Cycle

Unified Development Process (UDP)

Build and fix

Waterfall

Rapid prototyping

Incremental model

Spiral model

Page 15: Software Testing

April 1, 2002 Software Process 15

The Incremental Model

A build consists of code from various modules to provide desired functionality.

Product is designed, implemented, integrated, and tested as a series of incremental builds.

Note that architecture of the product is designed prior to the first build.

Page 16: Software Testing

April 1, 2002 Software Process 16

The Incremental Model: Advantages

Early adoption by the client eases the use of the application into the client environment. Often, introduction of new tools is a traumatic task for users. Incremental approach could ease the introduction.

At each stage, a new build is coded and integrated into existing code to provide added functionality. Each build is a working application though it might not have all the desired features.

The current build could be delivered to the customer for use. Thus, the client is able to do useful work at an early stage of the complete project.

Page 17: Software Testing

April 1, 2002 Software Process 17

Let us go over a sample process…

Code, test, deliver

Analysis

Design

Page 18: Software Testing

April 1, 2002 Software Process 18

Requirements Analysis

C- and D-Requirements

C-: Customer wants and needs; expressed in language understood by the customer.

D-: For the developers; may be more formal.

Page 19: Software Testing

April 1, 2002 Software Process 19

C-Requirements Use cases expressed individually and

with a use case diagram. A use case specifies a collection of scenarios.

Sample use case: Process sale as in a Point of Sale Terminal.

Page 20: Software Testing

April 1, 2002 Software Process 20

Requirements: A bird’s eye-view

A GUI front-end to multiple version control systems

Provide support on multiple platforms

Extends to incorporate additional functionality of an SCM or a new SCM entirely

Initially support Perforce, CVS, and ClearCase plug-ins

The Chameleon Project: CS 406/490: Sponsored by Peregrine Systems [2001-2002]

Page 21: Software Testing

April 1, 2002 Software Process 21

Conceptual Model

SoftwareEngineer

Workstation

Uses

1

1

WorkstationProject

1

1..*

Stores

WorkstationFiles

1

1..*

Contains

1..* SCM Client1

UsesSCM Server11

Connects To

MasterProject

1..*

1

Manages

Master Files1..*

1

Contains

1..*

Creates

/Updates

1

SCM: Source Code Management

Page 22: Software Testing

April 1, 2002 Software Process 22

Use Cases

Software Engineer

Load Plug-in

Change Plug-inConfiguration

Issue Command

Register New Plug-in

<<actor>>SCM Client

Use System Sequence diagrams to show how a userinteracts with the Application.

Page 23: Software Testing

April 1, 2002 Software Process 23

Load Plug-in Sequence Diagram

System

loadNewPlug-in()

registered plug-ins

selectPlugin(plug-in)

configurePlugin(configuration)

setPluginName(name)

Page 24: Software Testing

April 1, 2002 Software Process 24

What is Design?

As a process: The process by which the architecture of a software system is established.

As an artifact:The architecture of a software system describing system components and their interactions.

Page 25: Software Testing

April 1, 2002 Software Process 25

Design Principles [1]

Design for change

Change of algorithms

Change of data representation

Change of the underlying abstract machine

Change of peripheral devices

Change of social environment

Page 26: Software Testing

April 1, 2002 Software Process 26

Design Principles [2]

Separation of concerns

Separation over time.

Separation of quality attributes: e.g. performance and correctness

Separation by parts of the system.

Separation by views: e.g. data and control flows.

Page 27: Software Testing

April 1, 2002 Software Process 27

Sample: Basic Design Layout

GUI

UtilCore

SCM Clients

Page 28: Software Testing

April 1, 2002 Software Process 28

The Core PackageCore package

EngineissueCommand(command):Response

PluginManagergetPlugin (instanceName):IPlugin

IPlugin

CVSPlugin P4Plugin

1..*

CommandExecutor

doCommand(string)

Page 29: Software Testing

April 1, 2002 Software Process 29

Sequence diagram: Command Processing

GUI Engine PluginManager <<thread>>

Thread is now running;processing the command

issueCommand(command)

create()

start()

doCommand(command)

getPlugin(name):IPlugin

issueCommand()returns a flag for thread success or failure to the GUI

Page 30: Software Testing

April 1, 2002 Software Process 30

Command Process Threadplugin:IPlugin

CommandExecutor

<<thread>>: Engine

GUI

A: doCommand(command)

A: doCommand(args, …)

Thread A finished

A:commandFinished(res)

commandFinished(response)commandFinished(response)

Page 31: Software Testing

April 1, 2002 Software Process 31

Two Key Design Principles [1]

First: Design for changeChange of algorithms

Change of data representation

Change of underlying abstract machine

Change of peripheral devices

Change of social environment

Page 32: Software Testing

April 1, 2002 Software Process 32

Key Design Principles [2]

Second: Separation of concerns

Separation over time.

Separation of quality attributes: e.g. performance and correctness

Separation by parts of the system.

Separation by views: e.g. data and control flows.

Page 33: Software Testing

April 1, 2002 Software Process 33

Advancements in Software Process Control:Feedback Control

Specifications

ProgramEffort +

f(e)Additionaleffort What is f ?

-

RequiredQuality

rQ

ObservedQuality

oQ

oQr

Qe

Page 34: Software Testing

April 1, 2002 Software Process 34

Summary

3. Design principles, design notation (UML)

1. Software Process and its importance

2. Requirements analysis, domain model, use cases.

4. Design principles, design notation (UML)

5. Feedback control in software process

Page 35: Software Testing

April 1, 2002 Software Process 35

References

Software Process, Software Testing:

Object Oriented and Classical Software Engineering, Stephen Schach, McGraw Hill, 2002, Fifth Edition, Chapters 2, 3, 6.

Reference for Design Patterns:

Design patterns by Gamma et al., 1995, Chapter 5,

Or read pp. 372-380 from Larman’s book or section 3.2.2.1 of Braude’s book.

OO Analysis and Design:

Applying UML and Patterns, Craig Larman, PH-PTR, Second Edition, 2001, Chapters 9, 10, 15.