2 PROJECT MANAGEMENT

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

Development process - when to do what phase - document: SPMP Management structure - hierarchical, peer,... Risk identification & retirement Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 2 Focus Corporate practices Development phases Schedule Cost estimate SPMP 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” Learn different ways to 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 PM WANTED - Requirements: Technical Organizational People Management Skills

Management 101 The four fundamental activities of management: Planning Organizing Controlling Leading (influencing)

Variables for Project Management cost capabilityduration defect density (quality) Target : $70K Target : 30 wks Target : 4 defects/Kloc Target: 100% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Can somewhat vary each of these factors

Bullseye Figure for Project Variables cost capabilityduration defect density Target : $70K Actual: 100% Target : 30 wks Target : 4 defects/Kloc this project Actual: 1 defect/Kloc Actual: 20 wks Actual: $90K Target: 100% 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 6. Develop staffing plan -- see section 3.5 of case study 1 5. Develop schedule (times at which the work portions are to be performed) -- see section 6 7. Begin risk management -- see section 4 8. Identify documents to be produced -- see SQAP 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 “the principal ingredient is people”

Project Management Perspectives Enterprise (Business) Perspective –Effecting the “bottom line” Management Perspective –“there are no technical failures only management failures” –Get the job done  PM  Keep staff happy User Perspective –“we just want it to make our jobs better” Engineers’ Perspectives –Architecural and design level, implementation level –High quality workmanship, pride

Managing Expectations Managers must have a strong concern for the people they work for and with They must help people work together Must be familiar with team building concepts (covered next week) Must fit personal aspirations to team goals Communicate expectations affectively Measurement of project variables is key Note deviation from plan, take action

3. Options for organizing personnel

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

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

Hierarchical Project Management Organizations Larger Projects:Smaller Projects: No separate Marketing dept? No separate QA group? 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.

Networked Project Management Organizations Gil Warner Team leader Ian Corliss Team member Nel Tremont Team member Fran Smith Team member Team facilitator? Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. (A more Organic/Democratic Structure)

Peer Organizations for Larger Projects Team of leaders Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Roles versus People Project Manager Technical Architect Programmer Jim Nasium50%25% Bart Simpson100% Judy Jedi75%25%

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.

4. Identifying and retiring risks

What is a Risk? What is risk? Do all projects have risks? What about software projects?

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. Lack of sufficient knowledge/skills

What is a Risk? Two types of project risks –Direct Risk - Can be avoided / controlled eg. Project member likely to move Retirement via elimination –eg. job shadowing, replace when necessary –Indirect Risk - Cannot be avoided eg. Comm. time between NS and BC Retirement via mitigation (decrease risk as much as possible) –eg. Use client/server arch. to provide some local functionality

The Four Risk Activities 1.Identification – a continual activity 2.Analysis and Prioritization (see spreadsheet) – RBC = Probability * Impact; RAC = RBC * Costspreadsheet 3.Planning – create action plan - to retire or mitigate 4.Retirement or mitigation – includes tracking and control Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Project finish The Risk Management Mindset Project start IdentificationRetirement 2. “Java skills not high enough.” 1. “May not be possible to superimpose images adequately.” 1. Retirement by conquest: Demonstrate image super- imposition Risk 1 Risk 2 Risk 1 Project finish Risk 2 2. Retirement by avoidance: Use C++ Project start Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

*:in advance of first meeting M : at meeting **: between meetings Identify and Retire Risks 1.* Each team member spends 10 mins. exploring his or her greatest fears for the project’s success 2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & s 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-Class Exercise Each group member takes 5 minutes to identify risks to project success –fill in probability, impact, retirememt method and costs on spreadsheet providedspreadsheet One group member leads all to integrate and rationalize, and add any additional risks Calculate priority (RBC, RAC) of risks Rank priorities, determine most important Suggest methods of retirement or mitigation and assign person responsible for follow-up

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 costBuy cost Comments (in thousands) 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 Customize Ajax application ______ _________________ TOTALS$30$51 Build, do not buy Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Factor Weight (1-10) Benefit of Language 1 1 to 10=best Benefit of Language 2 1 to 10=best Internet-friendly 382 Familiarity to development team 839 Compilation speed 528 Runtime speed on processor p 173 Score 3*8 + 8*3 + 5*2 + 1*7 = 65 3*2 + 8*9 + 5*8 + 1*3 = 121 Table 2.4 Example of method for deciding language choice Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

6. Creating schedules: high level planning

Create an Initial Schedule 1. Indicate the deliverables your must observe –usually includes delivery date 2. Introduce the milestones you need to meet deliverables –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. 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, consider liberal estimates, add admin tasks/time 7. Complete the schedule 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 Month Month Month Month Milestones(1 * ) Delivery Begin system testing Iteration 1 Iteration 2 (6) (4) (3) Freeze requirements Risk identification & retirement (5) * Indicated the order in which the parts of this table were built SCMP complete SQAP complete SPMP rel. 1 complete (2) Prep. for maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Level Labor Allocation for Fixed Labor Total Month Month Month Month Month Milestones Release to production Complete testing Iteration 1 Iteration 2 Freeze requirements Risk ID & retire Given team size: To be assigned 4 Hal vacation Karen vacation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

11. The Software Project Management Plan

IEEE SPMP Table of Contents 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 3.2 Assumptions, dependencies & constraints 3.3 Risk management 3.4 Monitoring & controlling mechanisms (QA approach) 3.5 Staffing plan 4. Technical process 4.1 Methods, tools & techniques 4.2 Software documentation 4.3 Project support functions 5. Work packages, schedule & budget 5.1 Work packages 5.2 Dependencies 5.3 Resource requirements 5.4 Budget & resource allocation 5.5 Schedule (phases,milestones)

SPMP for the Encounter video game

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

Member Team leader CM Leader QA leader Require- ments manageme nt leader Design leader Implementati on Leader Liaison Respon- sibility VP Engineer ing Marketing Software engineerin g lab Docume nt Responsi -bility SPMPSCMP SQAP STP SRSSDDCode base Table 2.9 Encounter Project Responsibilties Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Program Monitoring & Control Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Name Team Leader CM Leader. QA Leader Requ. Mngmnt Leader Design Leader Implemen- tation Leader Ed BraunX X Al Pruitt X Fern Tryfill X Hal Furnass X Karen Peters X Liaison withVP Eng. Marketing Soft. Eng. Lab Table 2.11 Encounter Staffing Plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Month Month Month Month Month Milestones Delivery Complete testing Iteration 1 Iteration 2 Freeze requirements Risk I&R SCMP SQAP SPMP rel. 1 E. Braude J. Pruitt F. Tryfill H. Furnass K. Peters Tasks Work Breakdown Structure Excluding Secretarial TOTAL F. Smith (tech support) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Estimation Method Min (K lines Java) MaxComment (1) (2) (3) for two identified functions x 6-20 times as many in complete application Most conservative Maximum of minimums and maximum of maximums. Least conservative Minimum of minimums and minimum of maximums. Widest range Minimum of minimums and maximum of maximums. Narrowest range Maximum of minimums and minimum of maximums. 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 Month Month Month Month Milestones(1 * ) Delivery Begin system testing Iteration 1 Iteration 2 (6) (4) (3) Freeze requirements Risk identification & retirement (5) * Indicated the order in which the parts of this table were built SCMP complete SQAP complete SPMP rel. 1 complete (2) Prep. for maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Likelihood = least likely Impact = least impact Retire- ment cost = lowest retirement cost Priority computation Resulting priority Lowest number handled first The highest priority risk 10 (most likely) 10 (most impact) 1 (lowest retiremen t cost) (11-10) *(11-10) *1 1 The lowest priority risk 1 (least likely) 1 (least impact) 10 (highest retiremen t cost) (11-1) *(11-1) * Table 2.2 A way to compute risk priorities Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

# Risk title (details given above) Like- lihood =least likely Im- pact =least impact Retire- ment cost =lowest retirement cost Pri- ority lowest number handled first Retirement / mitigation plan Respon- sible engineer Target com- pletion date 1 Super- imposing images Experiment with Java images. P. R.2/1/99 2 Deficient Java skills 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 3 Alan Gray may be pulled off this project Susan Ferris to inspect all of Alan's work S.F. Contin- ual.... Table 2.3 Sample Risk Analysis for Encounter Case Study Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

BONUS MATERIAL FOR PROJECT MEETINGS

1.* Distribute start time, end time, and agenda with approximate times (important items first) 2.*Ensure “ strawman ” items prepared 3. Start on time 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.** action items & decision summary. * in advance of meeting ‡ actions members must perform ** after meeting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Plan and Execute Meetings

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 mins 4. Discuss strawman artifact(s) -- x mins 5. Discuss risk retirement 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.