2 PROJECT MANAGEMENT Software Engineering Roadmap: Chapter 2

2 PROJECT MANAGEMENT Software Engineering Roadmap: Chapter 2

2 PROJECT MANAGEMENT Software Engineering Roadmap: Chapter 2 Focus Corporate practices Plan project Analyze requirements Maintain Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Software Management Engineering

structure Roadmap: - hierarchical, peer,... Chapter 2 Focus Development process Corporate practices Risk identification & retirement SPMP - when to do what phase - document: SPMP Schedule Cost estimate Plan project Analyze requirements Development

phases Maintain Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Learning Goals of This Chapter Understand the term project management Organize teams Specify project management plans Define and retire risks Estimate costs very early in the life cycle Create high level projects schedules Write a Software Project Management Plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 1. Introduction to project management Can somewhat vary the following factors.

1. The total cost of the project, e.g., increase expenditures 2. The capabilities of the product, e.g., subtract from a list of features ..... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. The Variables of Project Management Can somewhat vary the following factors. 1. The total cost of the project, e.g., increase expenditures 2. The capabilities of the product, e.g., subtract from a list of features The Variables of Project Management 3. The quality of the product, e.g., increase the mean time between failure

4. The date on which the job is completed. e.g., reduce the schedule by 20% e.g., postpone project's completion date one month Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Bullseye Figure for Project Variables Target: 100% cost capability Target : 4 defects/Kloc Target : $70K duration defect density Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Target : 30 wks Bullseye Figure for Project Variables Target: 100% Actual: 100% capability cost this project Actual: $90K duration Target : 30 wks Target : 4 defects/Kloc

Actual: 1 defect/Kloc Target : $70K defect density Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Actual: 20 wks RoadMap for Project Management 1. Understand project content, scope, & time frame 2. Identify development process (methods, tools, languages, documentation and support) -- section 4 of chapter 1 3. Determine organizational structure (organizational elements involved) -- see section 3 4. Identify managerial process (responsibilities of the participants) -- see section 3 of case study 1 at end of chapter

..... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. RoadMap for Project Management 1. Understand project content, scope, & time frame 2. Identify development process (methods, tools, languages, documentation and support) -- section 4 of chapter 1 3. Determine organizational structure (organizational elements involved) -- see section 3 4. Identify managerial process (responsibilities of the participants) -- see section 3 of case study 1 at end of chapter 5. Develop schedule (times at which the work portions are to be performed) -- see section 6 6. Develop staffing plan -- see section 3.5 of case study 1 7. Begin risk management -- see section 4 8. Identify documents to be produced -- see SQAP 4.2 9. Begin process itself -- described in chapters 3-10 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

2. Managing people 1.* Distribute start time, end time, and agenda with approximate times (see figure tbd) list important items first 2.* Ensure strawman items prepared Plan and Execute 3. Start on time Meetings 4. Have someone record action items 5. Have someone track time & prompt members 6. Get agreement on the agenda and timing 7. Watch timing throughout, and end on time allow exceptions for important discussion stop excessive discussion; take off line 8. Keep discussion on the subject 9.** E-mail action items & decision summary. * in advance of meeting actions members must perform Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. ** after meeting

Specify Agendas 1. Get agreement on agenda & time allocation 2. Get volunteers to : record decisions taken and action items watch time and prompt members (see figure tbd) 3. Report progress on project schedule -- 10 mins 4. Discuss strawman artifact(s) -- x mins 5. Discuss risk retirement -- 10 mins metrics and process improvement? n. Review action items -- 5 mins Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 3. Options for organizing personnel Optimal Size for Interaction (Approximate) Effectiveness per developer Developer communicates

regularly with no one. No communication time lost, but developer is too isolated and has no help. 3 Number of people with whom developer must frequently interact Key: Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. = engineer Optimal Size for Interaction (Approximate) Effectiveness per developer Approximate optimal range Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help. 3

7 Number of people with whom developer must frequently interact Developer communicates regularly with eleven people. Communication time outweighs benefits of interaction Key: Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. = engineer Hierarchical Project Management Organizations Smaller Projects: No separate Marketing? No separate QA organization? Larger Projects: Subdivide QA into testing, ? Subdivide Engineering into

system engineering, ? Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Horizontal Project Management Organizations Ian Corliss Team member Gil Warner Team leader Nel Tremont Team member Team facilitator? Fran Smith Team member Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Organize a Team 1. Select team leader: responsibilities: ensure all project aspects active fill all gaps 3. Designate leader roles & document responsibilities team leader: proposes and maintains SPMP configuration management leader: ... SCMP

quality assurance leader: ... SQAP, STP requirements management leader: ... SRS design leader: ... SDD implementation leader: ... code base 2. Leaders responsibilities: propose a strawman artifact (e.g. SRS, design) seek team enhancement & acceptance ensure designated artifact maintained & observed maintain corresponding metrics if applicable 4. Designate a backup for each leader as per Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Peer Organizations for Larger Projects Team of leaders Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Table 2.1 Matrixed organization Airline reserv. project Bank accountg. project Molecular analysis project Fluid mechanics project Al Pruitt Full time Quinn Parker Half time

Ruth Pella Full time Fred Parsons Full time Marketing dpt Oscar Mart Full time Pete Merrill Full time Sue More Half time Elton Marston Full time Engineering dpt

Hal Egberts ...... Ben Ehrlich ...... Mary Ericson ..... Len Engels ..... Project management dpt Functional Unit Project 4. Identifying and retiring risks The Four Risk Activities

(1) Identification Mindset: try to continually identify risks (2) Retirement planning (3) Prioritization (4) Retirement or mitigation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Risk Sources Ordered by Importance (Keil, Cule, Lyytinen, Schmidt) 1. Lack of top management commitment 2. Failure to gain user commitment 3. Misunderstanding of requirements 4. Inadequate user involvement 5. Failure to manage end-user expectations 6. Changing scope and/or objectives 7. . The Risk Management Mindset Identification Retirement 2. Java skills not high enough.

Project finish Project finish Risk 2 Risk 1 1. May not be possible to superimpose images adequately. Project start 2. Retirement by avoidance: Use C++ Risk 2 Risk 1 1. Retirement

by conquest: Demonstrate image superimposition Project start Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel. Likelihood 1-10 Impact 1-10 Retirement cost 1-10 1 = least likely 1 = least impact 1 = lowest

retirement cost The highest priority risk 10 (most likely) 10 (most impact) 1 (lowest retiremen t cost) (11-10) *(11-10) *1 The lowest

priority risk 1 (least likely) 1 (least impact) 10 (highest retiremen t cost) (11-1) *(11-1) *10 Table 2.2 A way to compute risk priorities Priority

computation Resulting priority Lowest number handled first Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 1 1000 Table 2.3 Sample Risk Analysis for Encounter Case Study # 1 Risk title (details given above) Superimposing images

Likelihood 1-10 Impact 1-10 Retirement cost 1-10 1=least likely 1=least impact 1=lowest retirement cost 3 10 1 Priority

3 . . 9 6 8 Responsible engineer Target completion date lowest number handled first 8 Experiment with Java images.

P. R. 2/1/99 80 H.T., K.M., V.I. and L.D. to attend training course beginning 1/5/99 at Ultra Training Corp, obtain Java level 2 certification by 3/1/99 and level 3 certification by 4/15/99 H. L. 4/15/99 S.F. Continual ...

... 2 Deficient Java skills Retirement / mitigation plan Alan Gray may be pulled off this project 3 7 9 288 Susan Ferris to inspect all of Alan's work

... ... ... ... ... ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Identify and Retire Risks 1.* Each team member spends 10 mins. exploring his or her greatest fears for the projects success 2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader 3.* Team leader integrates and prioritizes results 4.M Group spends 10 mins. seeking additional risks 5.M Team spends 10 mins. finalizing the risk table Designates responsible risk retirement engineers 6.** Responsible engineers do risk retirement work 7.M Team reviews risks for 10 mins. at weekly meetings

responsible engineers report progress team discusses newly perceived risks and adds them *:in advance of first meeting M : at meeting **: between meetings 5. Choosing development tools and support Potential CASE Tool Components To support project management schedule work breakdown To support configuration management For managing requirements

For drawing designs functional object-oriented use-case-based Tracing tools requirements to designs designs to code To support testing To support maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel. Example of Build vs. Buy Decision-making: Game Graphics engine Build cost Buy cost (in thousands) Comments multi-year costs not accounted for

Supplies $ 0 $40 Purchase Ajax engine First-person perspective $ 5 $ 0 Ajax has this feature 3-D $10 $ 1 Customize Ajax application Light reflection $15

$10 ___ $51 Customize Ajax application ___ TOTALS $30 _________________ Build, do not buy Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Table 2.4 Example of method for deciding language choice Weight (1-10) Benefit of Language 1 1 to 10=best Benefit of Language 2

1 to 10=best Internet-friendly 3 8 2 Familiarity to development team 8 3 9 Compilation speed 5 2 8

Runtime speed on processor p 1 7 3 3*8 + 8*3 + 5*2 + 1*7 = 65 3*2 + 8*9 + 5*8 + 1*3 = 121 Factor Score Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 6. Creating schedules: high level planning High Level Task Chart with Fixed Delivery Date: Order of Completion

Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 SCMP complete Milestones Begin system testing (2) SQAP complete (1*) Delivery SPMP rel. 1 complete (3) Freeze requirements Iteration 1 (4) (6) Iteration 2 Risk identification & retirement (5) Prep. for maintenance * Indicated the order in which the parts of this table were built Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Create an Initial Schedule 1. Indicate the milestones your must observe usually includes delivery date 2. Back these up to introduce the milestones you need e.g., begin system testing well before delivery 3. Designate a time at which all requirements frozen The remaining steps depend on the process used. We will assume an iterative process. 4. Show first iteration: establishes minimal capability usually: keep it very modest, even trivial, in capability benefit: exercises the development process itself 5. Show task of identifying & retiring risks starting from project inception 6. Show unassigned time (e.g., week) near middle? 7. Complete the schedule Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Level Labor Allocation for Fixed Labor Total Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Milestones

Freeze requirements Karen vacation Iteration 1 Release to production 2 2 2 3 2 2 3 Hal vacation 4 4 4 3 3 4 4 4 4 4 4 4 Iteration 2 Risk ID & retire Given team size: Complete testing 2 2 2 1 1 1 4 To be assigned 4 4 4 4 4 3 3 4 4 4 4 3 3 4 4 4 4 4 4 4

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 7. Integrating legacy applications Add new features (typically using same language) or Change features (e.g., port to new environment) Resulting system Repairs Legacy system Legacy System Integration Build new application that uses legacy system (possibly using different language) Legacy system

New features Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. New application 8. Estimating costs: early calculations $4 Range of cost estimates after conceptualization phase, based on actual cost of $1 Conceptualization phase $1 25c Requirements analysis Range of Errors in Estimating Eventual Cost

Range of cost estimates after requirements analysis phase $1 Design $1 Implementation $1 Integration/Test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. $1 Typical Cost Estimation Roadmap 1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code. and / or 1B. Use function point method to estimate lines of code 1B.1 Compute un-adjusted function points. 1B.2 Apply adjustment process.

2. Use lines of code estimates to compute labor and duration using COCOMO formulas. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Function Point Computation for a Single Function (IFPUG) External Inquiries (EIN) External Inputs (EI) Function Logical Logical group ofof Logical group user data group of user data user data

External Logical Files (ELF) file file file Internal Logical Files (ILF)* External Outputs (EO) * Internal logical grouping of user data into files Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) PARAMETER simple

complex Ext. inputs EI 3 or 4 or ... 6 = ___ Ext. outputs EO 4 or 5 or ... 7 = ___ countTotal Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process) PARAMETER simple complex Ext. inputs EI

3 or 4 or ... 6 = ___ Ext. outputs EO 4 or 5 or ... 7 = ___ Ext. inquiries EIN 3 or 4 or ... 6 = ___ Int. logical files ILF ... 7 or 10 or ... 15 = ___ Ext. logical files ELF ... 5 or 7 or ... 10 = ___ countTotal Unadjusted Function Point Computation for First Encounter Functions:Set up Player Character

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Unadjusted Function Point Computation for Second Encounter Functions: Encounter Foreign Character Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. General Characteristics for FP Adjustment 1-7 incidental 0 none 1 average 2 moderate essential 3 4 significant

1. Requires backup/recovery? 2. Data communications required? 3. Distributed processing functions? ..... 5 Case study 0-2 0-1 0 General Characteristics for FP Adjustment 1-7 incidental 0 1 none 1. 2. 3.

4. 5. 6. 7. average 2 moderate 3 essential 4 5 significant Requires backup/recovery? Data communications required? Distributed processing functions? Performance critical? Run on existing heavily utilized environmt.? Requires on-line data entry? 5

Multiple screens for input? .... continued Case study 0-2 0-1 0 3-4 0-1 4-5 General Characteristics for FP Adjustment 8-14 incidental 0 none 1 average 2 moderate 3

essential 4 significant 8. Master fields updated on-line? 9. Inputs, outputs, inquiries of files complex? 10. Internal processing complex? .... 5 Case study 3-4 1-2 1-4 General Characteristics for FP Adjustment 8-14 incidental 0 none 1 average

2 moderate 3 essential 4 significant 8. Master fields updated on-line? 3-4 9. Inputs, outputs, inquiries of files complex? 10. Internal processing complex? 1-3 11. Code designed for re-use? 2-4 12. Conversion and installation included? 0-2 13. Multiple installation in different orgs.? 1-3 14. Must facilitate change & ease-of-use by user? 4-5 5 Case study 1-2

Computation of Adjusted Function Points (IFPUG) (Adjusted) Function points = [ Unadjusted function points ] [ 0.65 + 0.01 ( total general characteristics ) ] Unadjusted Function Point Scores for Video Store Example Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. FP Adjustment Factors for Video Example none incidental 0 1 1. 2. 3. 4. 5. 6.

moderate 2 average significant 3 4 Requires backup/recovery?. Data communications required ?.... Distributed processing functions ?. Performance critical ?.. Run on existing heavily utilized environment ?. Requires on-line data entry ?.. 5 .... essential 5 4 0 0

3 1 FP Adjustment Factors for Video Example none incidental 0 1 moderate 2 average significant 3 4 1. Requires backup/recovery?. 2. Data communications required ?.... 3. Distributed processing functions ?.

4. Performance critical ?.. 5. Run on existing heavily utilized environment ?. 6. Requires on-line data entry ?.. 7. Multiple screens for input ?. 8. Master fields updated on-line ?.. 9. Inputs, outputs, inquiries of files complex ?.. 10. Internal processing complex ?. 11. Code designed for re-use ?... 12. Conversion and installation included ?.. 13. Multiple installation in different orgs. ?. 14. Must facilitate change & ease-of-use by user ?.. essential 5 4 0 0 3 1 5 3 5 2 1 3

3 3 2 Total 35 9. Estimating effort and duration from lines of code Meaning of the COCOMO Formulas (Boehm) (2) Duration for increasing Effort* ( y 2.5x 0.35 ) (1) Effort* for increasing LOC ( y 3x 1.12 ) exponent: < 1 >1 Applies to design through integration & test. *Effort = total person-months required. Basic COCOMO Formulae (Boehm)

Effort in Person-months = aKLOC b Duration = cEffort d Software Project a b c d Organic 2.4 1.05 2.5 0.38 Semidetached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32

Due to Boehm [Bo] Computing COCOMO Case Study Models Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Computing COCOMO Case Study Models Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Estimate Cost and Duration Very Early in Project 1. Use the function point method to estimate lines of code 2. Use Boehms formulas to estimate labor required 3. Use the labor estimate and Boehms formula to estimate duration Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 10. The Team Software Process

TSP Launch Issues to Settle (Humphrey) Process to be used Quality goals Manner of tracking quality goals How team will make decisions What to do if quality goals not attained fallback positions What to do if plan not approved fallback positions Define team roles Assign team roles Graphics reproduced with permission from Corel. To Be Produced at Launches (Humphrey) 1. 2. 3. 4. 5.

Written team goals Defined team roles Process development plan Quality plan Projects support plan computers, software, personnel etc. 6. 7. 8. 9. Overall development plan and schedule Detailed plans for each engineer Project risk assessment Project status report TSPi Cycle Structure (Humphrey) Week Milestones Iteration 1 Iteration 2 1 1 1 1 1 1 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Cycle 1 launch Delivery Cycle 2 launch Cycle 3 launch 1. strategy 2. plan 3. requirements 4. design 5. implementation 6. test 7. postmortem 1. strat. Iteration 3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 1. strategy. 11. The Software Project Management Plan 1. Introduction 1.1 Project overview 1.2 Project deliverables 1.3 Evolution of the SPMP 1.4 Reference materials 1.5 Definitions and acronyms 2. Project organization

2.1 Process model 2.2 Organizational structure 2.3 Organizational boundaries and interfaces 2.4 Project responsibilities 3. Managerial process 3.1 Managerial objectives & priorities .... IEEE 1058.1-1987 SPMP Table of Contents IEEE 1058.1-1987 SPMP Table of Contents 3.2 Assumptions, dependencies & constraints 3.3 Risk management 1. Introduction 3.4 Monitoring & controlling 1.1 Project overview mechanisms 1.2 Project deliverables 3.5 Staffing plan 1.3 Evolution of the SPMP 4. Technical process

1.4 Reference materials 4.1 Methods, tools & techniques 1.5 Definitions and acronyms 4.2 Software documentation 2. Project organization 4.3 Project support functions 2.1 Process model 5. Work packages, schedule & 2.2 Organizational structure budget 2.3 Organizational boundaries 5.1 Work packages and interfaces 5.2 Dependencies 2.4 Project responsibilities 5.3 Resource requirements 3. Managerial process 5.4 Budget & resource allocation 3.1 Managerial objectives & 5.5 Schedule priorities 12. Quality in project management Table 2.5 Defects by Phase Defects detected per ... ... 100 requirements, or ... design

diagram, or ... KLOC This project / norm Detailed requirements Phase containing defects Design Phase in which defects detected Detailed requirements Design Implementation 2/5 0.5 / 1.5 0.1 / 0.3 3/1

1/3 Implementation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 2/2 Five Process Metric Examples Compare each of the following with company norms averaged over similar processes. 1.Number of defects per KLOC detected within x weeks of delivery 2.Variance in schedule on each phase actual duration - projected duration projected duration 3.Variance in cost actual cost - projected cost projected cost 4.Total design time / total programming time should be at least 50% (Humphry) 5.Defect injection and detection rates per phase e.g. 1 defect per class in detailed design phase Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

IEEE 739-1989 Software Quality Assurance Plans Table of Contents Part 2 of 2 7. Test -- can reference Software Test Documentation 8. Problem reporting & corrective action 9. Tools, techniques and methodologies -- can reference SPMP 10. Code control -- reference SCMP 11. Media control 12. Supplier control 13. Records collection, maintenance & retention 14. Training 15. Risk Management -- can reference SPMP Gather Process Metrics 1. Identify & define metrics team will use by phase; include ... time spent on 1. research, 2. execution, 3. review size (e.g. lines of code) # defects detected per unit (e.g., lines of code)

include source quality self-assessment of each on scale of 1-10 maintain bell-shaped distribution 2. Document these in the SQAP 3. Accumulate historical data by phase 4. Decide where the metric data will be placed as the project progresses SQAP? SPMP? Appendix? 5. Designate engineers to manage collection by phase QA leader or phase leaders (e.g., design leader) 6. Schedule reviews of data for lessons learned Specify when and how to feed back improvement Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Requirements Document: 200 detailed requirements Hours spent Meeting Research Execution

Personal Review Inspection 0.5 x 4 4 5 3 6 % of total time 10% 20% 25% 15% 30%

% of total time: norm for the organization 15% 15% 30% 15% 25% Self-assessed quality 1-10 2 8 5 4 6 Defects per 100

N/A N/A N/A 5 6 Defects per 100: organization norm N/A N/A N/A 3 4 Hours spent per detailed requirement

0.01 0.02 0.025 0.015 0.03 Hours spent per detailed requirement: organization norm 0.02 0.02 0.04 0.01 0.03 Process improvement Improve

strawman brought to meeting Spend 10% more time executing Table 2.6 Project Metric Collection for phases Productivity: 200/22 = 9.9 detailed requirements per hour Probable remaining defect rate: 6/4[organizational norm of 0.8 per hundred] = 1.2 per 100 Perspective by Eric J. Braude (Wiley 2001), with permission. Adapted from Software Engineering: An Object-Oriented Summary 13. Process improvement and the Capability Maturity Model Table 2.7 Example of Process Comparison Process Motor control applications Waterfall Spiral, 2-4 iterations

Spiral, 5-10 iterations ... requirements time 4.2 3.2 2.4 ... architecture time 3.1 2.5 3.7 ... detailed design time 1.1 1.1 2.2

... implementation time 1.0 2.1 3.5 TOTAL 9.4 8.9 11.8 Company average -- Defects per thousand source lines of code at delivery time injected at ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Feed Back Process/Project Improvement 1. Decompose the process or sub-process being measured into Preparation, Execution and Review include Research if learning about the procedure

2. Note time taken, assess degree of quality for each part on a 1-10 scale, count defects try to enforce a curve 3. Compute quality / (percent time taken) 4. Compare teams performance against existing data, if available 5. Use data to improve next sub-process note poorest values first e.g., low quality/(percent time) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Table 2.8 Measuring Team Phase Performance Preparation Execution Review % time 45

30 25 6 2 investigate 6 0.13 investigate 0.07 investigate 0.24 No Joe lost specs Yes Yes Quality (0 to

10)* If low, investigate Quality/(% time) If low, investigate Typical? Action For each part ... Schedule 20% more time for execution, taken equally from other phases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 14. Miscellaneous tools and techniques for project management Model Remote Team Options Same office area + ideal for group communication

- labor rates sub-optimal Same city, different offices communication fair Same country, different cities - communication difficult + common culture Multi-country - communication most difficult - culture issues problematical + labor rates optimal Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel. Non-Extreme vs Extreme Programming Limited customer contact Customer on team

Central up-front design Open evolving design Build for the future too Evolve; just in time Complex implementation Radical simplicity Tasks assigned Tasks self-chosen Developers in isolation Pair programming Infrequent integration Continuous integration Limited communication Continual

communication Adapted from Andserson, A., et al, "At Chrysler, Objects Pay", Distributed Computing, October 1998 Triage in Project Management Among top items in importance? if so, place it in do at once category otherwise Could we ignore without substantially affecting project? if so, place it in last to do category otherwise Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Triage in Project Management Among top items in importance? if so, place it in do at once category otherwise Could we ignore without substantially affecting project? if so, place it in last to do category otherwise (do not spend decision time

on this) place in middle category Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 16. Summary of the project management process Summary Project management: silver bullet? People aspects co-equal technical Specify SPMP Define and retire risks Estimate costs with several methods expect to revisit and refine use ranges at this stage Schedule project with appropriate detail Maintain a balance among cost, schedule, quality and functionality Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel. SPMP for the Encounter video game Gaming Industries Consolidated

President IV&V ... VP Marketing ... ... VP Engineering Software Engineering Labs Game Lab Game 123 Encounter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. SQA

Table 2.9 Encounter Project Responsibilties Member Team leader Liaison Responsibility VP Engineer ing Docume nt Responsi -bility SPMP CM Leader SCMP QA leader

SQAP STP Requirements manageme nt leader Design leader Marketing Software engineerin g lab SRS SDD Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Implementati on Leader Code base

Program Monitoring & Control Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Table 2.11 Encounter Staffing Plan Team Leader CM Leader. QA Leader Requ. Mngmnt Leader Design Leader Implementation

Leader Name Ed Braun X Al Pruitt X X Fern Tryfill X Hal Furnass X Karen Peters Liaison with X

VP Eng. Marketing Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Soft. Eng. Lab Work Breakdown Structure Excluding Secretarial Milestones Tasks Month 1 Month 2 Month 3 Month 4 Month 5

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 SCMP SQAP SPMP rel. 1 Complete testing Freeze requirements Delivery Iteration 1 Risk I&R Iteration 2 E. Braude 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 J. Pruitt 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 F. Tryfill 1 1 1 1 1 1 1 1 1 1 1 1 1

H. Furnass 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 K. Peters 1 1 1 1 1 1 1 1 1 1 1 1 1 1 F. Smith (tech support) TOTAL 1 1 1 1 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 3.5 3.5 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Method* Minimum

Maximum (1) 7.5** 170 (2) 4.2 300 (3) 11.4 46 1.9-2.3 for two identified functions 6-20 times as many in complete application Most conservative

11.4 300 Maximum of minimums and maximum of maximums. Least conservative 4.2 46 Minimum of minimums and minimum of maximums. Widest range 4.2 300 Minimum of minimums and maximum of maximums. Narrowest

range 11.4 46 Maximum of minimums and minimum of maximums. Comment Table 2.12 Very Rough Estimate of Application Size Prior to Requirements Analysis Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. High Level Task Chart with Fixed Delivery Date: Order of Completion Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 SCMP complete Milestones Begin system testing (2) SQAP complete (1*) Delivery

SPMP rel. 1 complete (3) Freeze requirements Iteration 1 (4) (6) Iteration 2 Risk identification & retirement (5) Prep. for maintenance * Indicated the order in which the parts of this table were built Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Software quality assurance plan Part 2 of 2 1. Defect Number: 2. Proposer: 3. Documents / sections affected:__________ Source code affected*: 4.

package(s)_______ 5. class(es) ____6.Problem Reporting method(s) ______ 7.Severity: ____8. Type: Form _____ 9. Phase injected**: Req Arch Dtld.Dsg Code Int 10. Detailed description: ___________________ 11. Resolution: ____ 12. Status closed / open:__ Sign-off: 13. Description and inspected: __ **earliest phase with the 14.defect *plan for source code defects Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Recently Viewed Presentations

  • From Raw Data to an Image Field Record

    From Raw Data to an Image Field Record

    L 5 - Seismic Method . Courtesy of ExxonMobil. Positioning Problems Energy. Source The seismic ray hits an inclined surface at 90. º and reflects back
  • Main Title 32pt - Sandia National Laboratories

    Main Title 32pt - Sandia National Laboratories

    y = observed variable (log 10 (ILINet)), x = log 10 (HM), e = noiseARX models need to . Search over (L, M) for a good fit AND . Use AIC to choose between models with different (L, M) AND....
  • Läxförhör 1 Medeltiden - WordPress.com

    Läxförhör 1 Medeltiden - WordPress.com

    Kristendomen förändrade människorna. Omkring år 1100 hade nästan alla i Sverige och Norden blivit kristna. Folk i Europa hade varit kristna i många hundra år.
  • Global Business Today 9e

    Global Business Today 9e

    A new round of talks Doha. Have been ongoing since 2001 concerned with cutting tariffs on industrial goods and services, phasing out subsidies to agricultural producers, reducing barriers to cross-border investment, limiting the use of antidumping laws.
  • Koalas! By: Monica G. Koala Facts Diet Description

    Koalas! By: Monica G. Koala Facts Diet Description

    Life Cycle. It takes 35 days for the koala to be born, Koalas are born by live birth. A baby koala does NOT look like an adult koala at all!! A baby koala looks like a little pink blob with...
  • Global Climate Change Action and the Transportation Sector:

    Global Climate Change Action and the Transportation Sector:

    Clean Power Plan - stayed by SCOTUS Feb. 2016. ... Source: LSE Grantham Research Institute on . Climate Change and the Environment and Columbia University. International Climate Change Action in the Transport Sector. ... Dundon, Leah Anne ...
  • What Is Seller Financing?

    What Is Seller Financing?

    That is a 6.25-7.25 minimum investment in down payment on an FHA loan. On top of that there's a 1.35% add to the rate over the life of the loan. So if interest rates are 4.5% the effective rate on...
  • Central Technical Publications Librarian

    Central Technical Publications Librarian

    Log the CECR part 2 date into our ELMS as the incorporated date once the part 2 is received. Type in the pub number into the ELMS search, select the copy number and location as applies, and fill in the...