object-oriented software engineering lecture 03 process dr. ir. riri fitri sari mm msc 28 september...
TRANSCRIPT
Object-OrientedObject-OrientedSoftware EngineeringSoftware Engineering
Lecture 03Lecture 03
ProcessProcess
Dr. Ir. Riri Fitri Sari MM MScDr. Ir. Riri Fitri Sari MM MSc28 September 201128 September 2011
Multimedia Network Postgraduate ProgrammeMultimedia Network Postgraduate ProgrammeFaculty of EngineeringFaculty of EngineeringUniversity of IndonesiaUniversity of Indonesia
ELH7141ELH71413 3
2
Plan project
Integrate & test system
Analyze requirements
Design
Maintain
Test unitsImplement
Software Engineering Roadmap: Chapter 1 Software Engineering Roadmap: Chapter 1 FocusFocus
Identify corpo-rate practices- assess capability- specify standards- e.g. CMM level
Development phases
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
3
next chapter: Plan development process
Plan configuration management- how to manage documents & code- document: SCMP
Plan quality assurance - how to ensure quality- document: SQAP
Integrate & test system
Analyze requirements
Design
Maintain
Test unitsImplement
Software Software Engineering Engineering Roadmap: Roadmap: Chapter 1 Chapter 1
FocusFocus
Identify corpor-ate practices- assess capability- specify standards- e.g. CMM level
Development phases
Plan verification & validation - verify the product satisfies requirements- validate each phase by showing it succeeded document: SVVP
Plan project
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
4
Chapter Learning GoalsChapter Learning Goals Distinguish among development processes Distinguish among development processes
– Indicate benefits and disadvantagesIndicate benefits and disadvantages
Define software “quality” quantitativelyDefine software “quality” quantitatively
– Institute collectionInstitute collection
Understand documentation neededUnderstand documentation needed
– Approximately one for each waterfall phaseApproximately one for each waterfall phase
– Plan for configuration managementPlan for configuration management
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Introduction to the software 1. Introduction to the software engineering processengineering process
ELH7141ELH71413 3
6
Stand-aloneStand-alone– residing on a single computer residing on a single computer – not connected to other software or hardwarenot connected to other software or hardware– e.g., word processore.g., word processor
EmbeddedEmbedded– part of unique application involving hardwarepart of unique application involving hardware– e.g., automobile controllere.g., automobile controller
RealtimeRealtime– functions must execute within small time limitfunctions must execute within small time limit
typically microsecondstypically microseconds– e.g., radar softwaree.g., radar software
NetworkNetwork– consist of parts interacting across a network consist of parts interacting across a network – e.g., Web-based video gamee.g., Web-based video game
Some Application TypesSome Application Types
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
7
Typical Project RoadmapTypical Project Roadmap
1. Understand nature & scope of proposed product
2. Select the development process, and create a plan-- section 4 and chapter 2
4. Design and build the product -- chapters 5, 6, and 7
6. Deliver and maintain the product -- chapter 10
3. Gather requirements -- chapters 3 and 4
5. Test the product -- chapters 8 and 9
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
2. Historical and contemporary 2. Historical and contemporary perspectives on software perspectives on software
engineeringengineeringprocessprocess
ELH7141ELH71413 3
9
Structured ProgrammingStructured Programming
Function definition handleAccount(…)getDetailsFromUser(…)getAccount(…)doTransaction(…)……
Function definition getDetailsFromUser (…)getName(…)…...
Function definition getAccount(…)getFirstName(…)…...
…...
TOP
DOWNAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
10
Object OrientationObject Orientation
Real world concepts
Software design entities
SkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjkSkljkvjkvjfkavjafkksaovjsdvjfvkfjvkfjk
AccountgetDetails()
Transactionexecute()
CustomergetFirstName()
Direct correspondence
Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
11
The COM IdeaThe COM IdeaComponent Object Component Object Model (Microsoft)Model (Microsoft)
Identification interface
getName()
setName()
getSSN()
setSSN()
Computation interface
Asset interface
account
COM object
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
enable enable interprocess communication and dynamic object creation and dynamic object creation in any in any programming language
3. Expectations for process, 3. Expectations for process, project, product and peopleproject, product and people
ELH7141ELH71413 3
13
Five Key Five Key Expectations Expectations (Humphrey)(Humphrey)
Influencedby people
Used forprocess development
Part oftheproject
Aspectof the product
3. Keep all work visible
5. Measure quality
4. A. Design onlyagainst requirements
B. Programonly against designsC. Test only against
requirements and designs
1. Predetermine quantitative quality goals
2. Accumulate data for subsequent use
ELH7141ELH71413 3
14
Unified Software Development Process (USDP)Unified Software Development Process (USDP) Artifacts and RolesArtifacts and Roles
Artifacts: the entities that software engineering deals with.
Document Model-- a viewof the
application(design etc.)
Component-- physical
(source code etc.)
Workers: responsibilities allocated to people (roles).
USDP termUSDP term Symbol & examplesSymbol & examples
Worker Worker instance(e.g., Joe Smith)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
4.4. Process alternativesProcess alternatives
ELH7141ELH71413 3
16
The Waterfall ModelThe Waterfall ModelRequirements
analysis
Design
Implementation
Integration
Produces … specification (text)
... diagrams & text
... code & comments
... entire code
Test... test report, including defect descriptions
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
17
More Detailed More Detailed Waterfall VersionWaterfall Version
Design
Implementation& unit testing
Integration
System testing
Conceptanalysis
Analysis
MaintenanceAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
18
completetargeted
requirements
Step n:Analyzerequirements
Step n+3: Test
Step n+2: Implement
Step n+1: Design
Product:classmodels +
Product: requirementsspecifications
Product: code + Product: test results +
Spiral DevelopmentSpiral Development
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
19
Iteration No.Incremental DevelopmentIncremental Development
Analyzerequirements
Test whole
Implement
Design
Test units
Integrate
1 2 3 867 868
Update SRS3
Update SDD2
Update source code
Update Test documentation
Update SPMP1
1 Software Project Mangement Plan (chapter 2); 2 Software Design Document (chapter 5); 3 Software Requirements Specification (chapter 3);
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
20
The Unified Software Development Process: The Unified Software Development Process: Classification of IterationsClassification of Iterations
Inception iterationsInception iterations: preliminary interaction with : preliminary interaction with stakeholdersstakeholders– primarily customerprimarily customer– usersusers– financial backers etc.financial backers etc.
Elaboration iterations Elaboration iterations : finalization of what’s wanted and : finalization of what’s wanted and needed; set architecture baselineneeded; set architecture baseline
Construction iterations Construction iterations : results in initial operational : results in initial operational capabilitycapability
Transition iterations Transition iterations : completes product release : completes product release Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
21
ElaborationInception Construction Transition
Requirements
Analysis
Iter.#1
Iter.#n
Iter.#n+1
Iter.#m
Iter.#m+1
Iter.#k
….. …..Prelim.iterations
USDP vs. Standard Terminology ½ (Booch, Jacobson & USDP vs. Standard Terminology ½ (Booch, Jacobson & Rumbaugh)Rumbaugh)
Design
Implemen-tation
Test
USDP calls these “core workflows”
(Classically called “phases”)
Classification of iterations
Individual iteration
ELH7141ELH71413 3
22
Requirements
Analysis
USDP vs. Standard Terminology USDP vs. Standard Terminology 2 of 22 of 2
Design
Implementation
Test
Requirements analysis
Implementation
USDP USDP TerminologyTerminology
Classical Classical TerminologyTerminology
Integration
Design
Test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
23
Elaboration
Unified Process MatrixUnified Process Matrix
Inception Construction Transition
Requirements
Analysis
Jacobson et al: USDP
Prelim.iterations
Iter.#1
Iter.#n
Iter.#n+1
Iter.#m
Iter.#m+1
Iter.#k
….. …..
Design
Implemen-tation
Test
..
Amount of effort expendedon the requirements phaseduring the first Constructioniteration
ELH7141ELH71413 3
24
The Six USDP Models (Views of the The Six USDP Models (Views of the Application)Application)
Use-casemodel
Analysismodel
Designmodel
Deploymentmodel
Implementationmodel
Testmodel
Graphics reproduced with permission from Corel.
ELH7141ELH71413 3
25
Identify the Process You Identify the Process You Will UseWill Use
1. Decide which of 1. Decide which of waterfallwaterfall, , spiralspiral, and , and incrementalincremental processes processes is appropriate.is appropriate.Usually a spiral for a semester project. Usually a spiral for a semester project. Combining parts is OK e.g. start with spiral, end with Combining parts is OK e.g. start with spiral, end with incrementalincremental
2. Decide how many iterations.2. Decide how many iterations.Usually two for a semester project (there are many artifacts to Usually two for a semester project (there are many artifacts to
coordinate at the end of each iteration).coordinate at the end of each iteration).Three provides lots of practice -- but this is a challenge; make the first Three provides lots of practice -- but this is a challenge; make the first
increment as minor as possibleincrement as minor as possibleThree promotes the collection and use of metric data -- use metric Three promotes the collection and use of metric data -- use metric
data collected from each iteration on next.data collected from each iteration on next.3. Rough out a weekly schedule. 3. Rough out a weekly schedule.
Coordinate with course assignments. Coordinate with course assignments. (The next chapter discusses scheduling.) (The next chapter discusses scheduling.)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
5. Documentation5. Documentation
ELH7141ELH71413 3
27
Undocumented CodeUndocumented Codeint a( int i, char c ){
if( c== “m” )if( i< 1000 )
return 0;else
if( i< 10000 ) return 500;
elsereturn 1200;
elsereturn 1300;
}
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
28
Somewhat Somewhat Documented Documented
CodeCode
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
int tax( int anEarning, char aStatus )
{
if( aStatus == ‘m’ )
if( anEarning < 1000 )
return 0; // no tax for married, < $1000
else
if( anEarning < 10000 )
return 500; // married, $1000-$10000
else
return 1200; // married, >=$10000
// If not “married”, apply single tax rate of $1300 regardless
else
return 1300;
}
ELH7141ELH71413 3
29
Documented CodeDocumented Code/**
* This method implements requirement 4.3:
* “State tax effective 9/1/98 -12/31/99”
* @author Eric J. Braude
* @version 2.3.4 (8/6/98)
* @param anEarning: earnings 9/1/98 thru 12/31/99
* @param aStatus: ‘m’ signifies “married” (anything
* else designates unmarried)
*/
int tax( int anEarning, char aStatus )
{Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
30
Project DocumentationProject Documentation
SCMPsoftware configuration management plan
SPMPsoftware project management planProject status
Configuration
SQAPsoftware quality assurance plan Quality assurance
SVVPsoftware validation & verification plan Verification & validation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
31
ProjectProject
DocumentatiDocumentationon
SRSsoftware requirements specifications
STDsoftware test documention
SCMPsoftware configuration management plan
SDDsoftware design document
SPMPsoftware project management plan
Source Code
Project status
Configuration
Testing
Requirements
Design
Code
User’s manualOperation
SQAPsoftware quality assurance planQuality assurance
SVVPsoftware validation & verification planVerification & validation
Customer-orientedDeveloper-orientedArchitectureDetailed design
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
32
1. Document the way documents & code are accessed1. Document the way documents & code are accessed– otherwise, chaos results otherwise, chaos results – ““Software Configuration Management Plan*” -- section tbdSoftware Configuration Management Plan*” -- section tbd
2. Specify who will do what, and when they will do it2. Specify who will do what, and when they will do it– ““Software Project Management Plan*” -- chapter 2Software Project Management Plan*” -- chapter 2
3. Document what is to be implemented 3. Document what is to be implemented – for yourself, your customer, and your team for yourself, your customer, and your team – ““Software Requirements Specification*” -- chapters 3 and 4Software Requirements Specification*” -- chapters 3 and 4
4. Document the design of the application4. Document the design of the application– i.e., prior to programmingi.e., prior to programming– ““Software Design Document*” -- chapters 5 and 6Software Design Document*” -- chapters 5 and 6
5. Write and document code5. Write and document code– the “code base” -- chapter 7 the “code base” -- chapter 7
6. Document the tests you perform6. Document the tests you perform– so that they can be re-run, extended etc.so that they can be re-run, extended etc.– ““Software Test Documentation*” -- chapters 8 and 9Software Test Documentation*” -- chapters 8 and 9
Identify Your Documentation Identify Your Documentation NeedsNeeds
* the IEEE standard,which can be used toorganize this documentation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
6. Quality6. Quality
ELH7141ELH71413 3
34
QAQAInvolvementInvolvement
3. Plan4. Design and build5. Deliver & main-tain the product
1. Specify how to manageproject documents 2. Identify process
QA
1. QA Developsand/or reviews configurationmanagementplans, standards ...
3. QA developsand/or reviews provision for QA activities
2. QA reviews process forconformance toorganizational policy
5. QA reviews,inspects & tests
4. QA reviews,inspects & tests
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
35
Principle of InspectionPrinciple of Inspection
AUTHORS CAN USUALLY
REPAIR DEFECTS
THAT THEY RECOGNIZE
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
36
Principle of InspectionPrinciple of Inspection
AUTHORS CAN USUALLY
REPAIR DEFECTS
THAT THEY RECOGNIZE
COROLLARY:Have their peers seek defects.
COROLLARY:Help authors to recognize defects
before they deliver their work.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
37
OVERVIEW
CAUSAL
ANALYSIS
4. REWORK
5. FOLLOW-UP
Inspection Inspection Process & Process & Example TimesExample Times
Non-nominalprocess
6. IMPROVE PROCESS
2. PREPARATION
3. INSPECTION
Nominal process 1. PLANNING
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
38
Time/Costs per 100 LoC*Time/Costs per 100 LoC*-- one company’s estimates-- one company’s estimates
PlanningPlanning 1 hr 1 hr (1 person) (1 person)
[ Overview [ Overview 1 hr 1 hr (3-5) ] (3-5) ]
PreparationPreparation 1 hr 1 hr (2-4 people) (2-4 people)
Inspection meetingInspection meeting 1 hr 1 hr (3-5 people) (3-5 people)
ReworkRework 1 hr 1 hr (1 person) (1 person)
[ Analysis [ Analysis 1 hr 1 hr (3-5) ] (3-5) ]
TotalTotal: approx. : approx. 7 - 21 person-hours7 - 21 person-hours* lines of non-commented code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
39
Hours Per DefectHours Per Defect: One estimate: One estimate
… … at inspection … at integration at inspection … at integration timetime timetime
Hours to ..Hours to .... detect.. detect 0.7 to 2 0.7 to 2 0.2 to 10 0.2 to 10
.. repair.. repair 0.3 to 1.2 0.3 to 1.2 9+ 9+
TotalTotal 1.0 to 3.21.0 to 3.2 9.2 to 19+9.2 to 19+
If defect found ...
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
40
Prepare For & Conduct Prepare For & Conduct InspectionsInspections
1. Build inspections into the project schedule1. Build inspections into the project schedule– plan to inspect all phases, starting with requirementsplan to inspect all phases, starting with requirements– allow for preparation (time consuming!) & meeting timeallow for preparation (time consuming!) & meeting time
2. Prepare for collection of inspection data2. Prepare for collection of inspection data– include # defects per work unit (e.g., KLOC), time spentinclude # defects per work unit (e.g., KLOC), time spent– develop forms: include develop forms: include descriptiondescription, , severityseverity and and typetype– decide who, where, how to store and use the metric datadecide who, where, how to store and use the metric data
default: appoint a single person to be default: appoint a single person to be responsibleresponsible
failure to decide usually results in discarding the failure to decide usually results in discarding the datadata
3. Assign roles to participants3. Assign roles to participants– Three adequate (Three adequate (authorauthor; ; moderator/recordermoderator/recorder; ; readerreader))– Two far better than none (Two far better than none (authorauthor; ; inspectorinspector))
4. Ensure every participant prepares 4. Ensure every participant prepares – bring defects pre-entered on forms to inspection meeting bring defects pre-entered on forms to inspection meeting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
41
IEEE 730-1989 IEEE 730-1989 Software Quality Software Quality Assurance Plans Assurance Plans
Table of Contents Table of Contents
1. Purpose2. Referenced documents3. Management 3.1 Organization 3.2 Tasks 3.3 Responsibilities4. Documentation 4.1 Purpose 4.2 Minimum documen- tation requirements 4.3 Other5. Standards, practices, conventions and metrics 5.1 Purpose 5.2 Content
ELH7141ELH71413 3
42
IEEE 730-1989 Software Quality Assurance Plans Table of ContentsIEEE 730-1989 Software Quality Assurance Plans Table of Contents 1. Purpose2. Referenced documents3. Management 3.1 Organization 3.2 Tasks 3.3 Responsibilities4. Documentation 4.1 Purpose 4.2 Minimum documen- tation requirements 4.3 Other5. Standards, practices, conventions and metrics 5.1 Purpose 5.2 Content
6. Reviews and audits 6.1 Purpose 6.2 Minimum requirements 6.2.1 Software requirements review 6.2.2 Preliminary design review 6.2.3 Critical design review 6.2.4 SVVP review 6.2.5 Functional audit 6.2.6 Physical audit 6.2.7 In-process audits 6.2.8 Managerial review 6.2.9 SCMP review 6.2.10 Post mortem review 6.3 Other7. - 15. -- see next chapter
ELH7141ELH71413 3
43
VerificationVerification::are we buildingare we building the thing rightthe thing right??
ValidationValidation::are we buildingare we building the right thingthe right thing??
Meaning of “V&V” Meaning of “V&V” (Boehm)(Boehm)
Graphics reproduced with permission from Corel.
ELH7141ELH71413 3
44
IEEE 1012-1986 Software Verification & validation Plans IEEE 1012-1986 Software Verification & validation Plans Table of Contents Table of Contents (Reaffirmed 1992)(Reaffirmed 1992)
1. Purpose2. Referenced documents3. Definitions4. V&V overview 4.1 Organization 4.2 Master schedule 4.3 Resource summary 4.4 Responsibilities 4.5 Tools, techniques & methodologies5. Lifecycle V&V 5.1 Management of V&V 5.2 Concept phase V&V 5.3 Requirements phase V&V 5.4 Design phase V&V 5.5 Implementation phase V&V
ELH7141ELH71413 3
45
IEEE 1012-1986 Software Verification & validation Plans Table of IEEE 1012-1986 Software Verification & validation Plans Table of Contents Contents (Reaffirmed 1992)(Reaffirmed 1992)
1. Purpose2. Referenced documents3. Definitions4. V&V overview 4.1 Organization 4.2 Master schedule 4.3 Resource summary 4.4 Responsibilities 4.5 Tools, techniques & methodologies5. Lifecycle V&V 5.1 Management of V&V 5.2 Concept phase V&V 5.3 Requirements phase V&V 5.4 Design phase V&V 5.5 Implementation phase V&V
5.3 Test phase V&V 5.4 Installation & checkout phase V&V 5.5 Operation & maintenance phase V&V6. Software V&V reporting 6.1 Required reports 6.2 Optional reports 7. V&V administrative procedures 7.1 Anomaly reporting & resolution 7.2 Task iteration policy 7.3 Deviation policy 7.4 Standards, practices & conventions
ELH7141ELH71413 3
46
Produce a Quality Produce a Quality ProductProduct
1. Quantify your quality goals1. Quantify your quality goalsminimum: minimum: number of defects per KLOCnumber of defects per KLOC
teamteam: : # defective requirements# defective requirements; ; # classes# classes missing missing from design;from design;
# defects# defects in testing; in testing; # defects# defects foundfound in operation. in operation.
personalpersonal: apply : apply # defects# defects to code, compile, unit test separately to code, compile, unit test separately
2. Build inspections and reviews into the schedule2. Build inspections and reviews into the schedule(see scheduling, next chapter)(see scheduling, next chapter)
follow the inspection procedure (see figure 1.27 on page ??)follow the inspection procedure (see figure 1.27 on page ??)
3. Document your quality goals and procedures3. Document your quality goals and proceduresuse a documentation standard to avoid missing issuesuse a documentation standard to avoid missing issues
SQAP (see case study for example); If time allows: SVVPSQAP (see case study for example); If time allows: SVVP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
7. Documentation management7. Documentation management
ELH7141ELH71413 3
48
Example of Hyperlinked Documentation Set Example of Hyperlinked Documentation Set (with Dynamic Content shown)(with Dynamic Content shown)
SRSsoftware requirements specifications
STPsoftware test plan
SCMPsoftware configuration management plan
SDDsoftware design document
SPMPsoftware project management plan
Source Code
References to all other documents
Projectstatus*
Configuration*
Testresults*
Direction of hyperlink
*Dynamic component
Updates*
Updates*Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
49
Configuration Items (Configuration Items (CI’sCI’s))
Units tracked officiallyUnits tracked officially– down to the smallest unit worth trackingdown to the smallest unit worth tracking– includes most official documentsincludes most official documents
A1S6
E3
C4
D5
Payroll v. 0.3.4.2
Payrollv. 0.4.1
Payroll v. 0.3.4.3
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
50
Configuration Items (Configuration Items (CI’sCI’s))
Units tracked officiallyUnits tracked officially– down to the smallest unit worth trackingdown to the smallest unit worth tracking– includes most official documentsincludes most official documents
A1S6
E3
C4
D5
A1S7
E3
C4
D5
Payroll v. 0.3.4.2
A1
D5
Payrollv. 0.4.1
S7C4
E3F1
Payroll v. 0.3.4.3
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
51
Configuration Management RequirementsConfiguration Management Requirements Procedure to identify CI'sProcedure to identify CI's Locking Locking
– to prevent more than one person working on a CI at to prevent more than one person working on a CI at one timeone time
Authorization to check out Authorization to check out – optionaloptional
Check-in procedureCheck-in procedure– authorization processauthorization process– involves testing etc.involves testing etc.
Historical record of prior groupings of consistent Historical record of prior groupings of consistent CI’sCI’s
Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
52
IEEE 828-1990 SCMP IEEE 828-1990 SCMP Table of ContentsTable of Contents 3.2 Configuration control
3.2.1 Requesting changes 3.2.2 Evaluating changes 3.2.3 Approving or dis-
approving changes 3.2.4 Implementing
changes 3.3 Configuration status accounting 3.4 Configuration audits & reviews 3.5 Interface control 3.6 Subcontractor / vendor control4. SCM schedules5. SCM resources6. SCM plan maintenance
1. Introduction2. SCM management 2.1 Organization 2.2 SCM responsibilities 2.3 Applicable policies, directives & procedures3. SCM activities 3.1 Configuration identification 3.1.1 Identifying configu- ration items 3.1.2 Naming configu- ration items 3.1.3 Acquiring configu- ration itemsAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
53
Plan Configuration Plan Configuration ManagementManagement
1. Roughly sketch out your SCMP1. Roughly sketch out your SCMPDetermine procedures for making changesDetermine procedures for making changesOmit tool references unless already identified oneOmit tool references unless already identified oneSee the case study for an example See the case study for an example
2. Specify what you need from a CM tool2. Specify what you need from a CM toolFor class use, maybe only For class use, maybe only lockinglocking and and backupbackup
3. Evaluate affordable tools against your needs and 3. Evaluate affordable tools against your needs and budgetbudgetCommercial tools are in wide useCommercial tools are in wide useFor class use, try free document storage web sites; try For class use, try free document storage web sites; try
simple method of checking out e.g. renamingsimple method of checking out e.g. renaming
5. Finalize your SCMP5. Finalize your SCMPAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
8. Introduction to capability 8. Introduction to capability assessmentassessment
ELH7141ELH71413 3
55
The PSP Evolution (Humphrey):The PSP Evolution (Humphrey):Personal Software ProcessPersonal Software Process
(Adapted from [Hu1] )
PSP0Current personal process
Basic measurements
PSP0.1Coding standards
Process improvement proposalSize measurement
PSP1Size estimation
Test report
PSP1.1Task planning
Schedule planning
PSP2Code reviews
Design reviews
PSP2.1Design templates
PSP3Cyclic development
Additionalcapability at the same level
Skills addedto prior stage
100’s of lines
1000’s of lines
ELH7141ELH71413 3
56
Team Software Process (TSP) Team Software Process (TSP) Objectives 1 (Humphrey)Objectives 1 (Humphrey)
Build self-directed teamsBuild self-directed teams– 3-20 engineers3-20 engineers– establish establish ownown goals goals – establish establish ownown process and plans process and plans– track worktrack work
Show managers how to manage teamsShow managers how to manage teams– coachcoach– motivatemotivate– sustain peak performancesustain peak performance
Graphics reproduced with permission from Corel.
ELH7141ELH71413 3
57
TSP Objectives 2 (Humphrey)TSP Objectives 2 (Humphrey) Accelerate CMM improvementAccelerate CMM improvement
– make CMM 5 “normal”make CMM 5 “normal”
““Provide improvement guidelines to high-Provide improvement guidelines to high-
maturity organizations”maturity organizations”
““Facilitate university teaching of industrial-grade Facilitate university teaching of industrial-grade
teams”teams”
The Capability Maturity ModelThe Capability Maturity Model(CMM)(CMM)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
ELH7141ELH71413 3
59
1. Initial (Software Engineering 1. Initial (Software Engineering Institute)Institute)
Process: undefined, ad hoc
Result: outcome depends on individuals
Lacking: any reasonable process
ELH7141ELH71413 3
60
2. Repeatable (Software Engineering Institute)2. Repeatable (Software Engineering Institute)
1. INITIAL Process undefined, ad hoc, depends on individuals
Processtracks documents, cost, schedule, functionality (after fact)
Resultrepeatable only on similar projects
Lacking: complete process
ELH7141ELH71413 3
61
3. Defined (Software Engineering Institute)3. Defined (Software Engineering Institute)
2. REPEATABLE Basic project management totrack cost & schedule, repeatable on similar projects
Processdocumented, standardized, tailorable
Resultconsistency
Lacking: predictable outcomes
ELH7141ELH71413 3
62
4. Managed (Software Engineering Institute)4. Managed (Software Engineering Institute)
3. DEFINED Consistent: Documented, standardized, tailorable
Processdetailed measurement; control
Resultprocess and products with quantified quality predictability
Lacking mechanism for process improvement
ELH7141ELH71413 3
63
5. Optimized (Software 5. Optimized (Software Engineering Institute)Engineering Institute)
4. MANAGED Predictable: process & products measured
ProcessContinual process improvement
through quantitative feedback; Extensible scopeInnovative ideas and technologies
Graphics reproduced with permission from Corel.
ELH7141ELH71413 3
64
Level Focus Key Process Area PSP TSP
Requirements management X
Software project planning X X
Software project tracking X X
Software quality assurance X
Software configurationmanagement
X2. Repeatable
Projectmanagement
Software subcontract managementGet permission
Relating PSP, TSP & CMM Relating PSP, TSP & CMM (Humphrey)(Humphrey)
ELH7141ELH71413 3
65
CMM Level Focus Key Process Area PSP TSPDefect prevention X X
Technology change management X X5. OptimizingContinuousprocessimprovement Process change management X X
Quantitative process management X X
4. ManagedProduct &processquality Software quality management X X
Organization process focus X X
Organization process definition X X
Training programIntegrated software management X X
Software product engineering X X
Inter-group coordination X
3. Defined
Engineeringprocess
Peer reviews X X
Requirements management X
Software project planning X X
Software project tracking X X
Software quality assurance X
Software configurationmanagement
X2. Repeatable
Projectmanagement
Software subcontract managementGet permission
Relating Relating PSP, TSP PSP, TSP & CMM & CMM
(Humphrey(Humphrey))
9. Summary9. Summary
ELH7141ELH71413 3
67
Software engineering an extensive challengeSoftware engineering an extensive challenge Major process models: Major process models:
waterfallwaterfall; ; spiralspiral; ; incrementalincremental Capability frameworks: Capability frameworks: CMMCMM; ; TSPTSP; ; PSPPSP Quality is the professional differenceQuality is the professional difference
– metrics to definemetrics to define– inspection throughoutinspection throughout– rigorous testing rigorous testing – include continuous self-improvement processinclude continuous self-improvement process
Documentation: Documentation: SCMPSCMP, SVVP, SQAP, , SVVP, SQAP, SPMPSPMP, , SRSSRS, , SDDSDD, , STPSTP, , CodeCode, , User’s manualUser’s manual
SummarySummary
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Case Study: SCMPCase Study: SCMP
ELH7141ELH71413 3
69
Configuration Management ScheduleConfiguration Management Schedule
Month 1
1 2 3 4
Month 2
1 2 3 4
Month 3
1 2 3 4
Month 4
1 2 3 4
Month 5
1 2 3 4
Stable CM
CM reviews
CM process improvement session
Vendor backup plan due
Random IV&V audits
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.