Post on 28-Nov-2014
description
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!
April 1, 2002 Software Process 2
Learning Objective
To understand the importance and basics of Software Process.
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
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.
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.
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.
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]
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
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
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
April 1, 2002 Software Process 11
Where does the cost of production lie?
Phase Cost (HP)
Requirements 18%
Implementation 34%
Design 19%
Integration 29%
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!
April 1, 2002 Software Process 13
Software Life Cycle
Steps used in the development, maintenance, and retirement of a software product.
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
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.
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.
April 1, 2002 Software Process 17
Let us go over a sample process…
Code, test, deliver
Analysis
Design
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.
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.
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]
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
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.
April 1, 2002 Software Process 23
Load Plug-in Sequence Diagram
System
loadNewPlug-in()
registered plug-ins
selectPlugin(plug-in)
configurePlugin(configuration)
setPluginName(name)
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.
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
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.
April 1, 2002 Software Process 27
Sample: Basic Design Layout
GUI
UtilCore
SCM Clients
April 1, 2002 Software Process 28
The Core PackageCore package
EngineissueCommand(command):Response
PluginManagergetPlugin (instanceName):IPlugin
IPlugin
CVSPlugin P4Plugin
1..*
CommandExecutor
doCommand(string)
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
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)
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
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.
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
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
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.