Software Engineering Roadmap: Project Management Strategies
This content delves into project management strategies in software engineering, covering topics such as team organization, risk management, cost estimation, and high-level project scheduling. It explores key aspects of project management and provides insights into creating effective software project management plans.
Uploaded on Feb 27, 2025 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
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 Engineering Roadmap: Chapter 2 Focus Management structure - hierarchical, peer,... Risk identification & retirement SPMP Schedule Development process - when to do what phase - document: SPMP Corporate practices Cost estimate Plan project Development phases 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.
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 Target: 100% Target : $70K Can somewhat vary each of these factors capability duration Target : 30 wks Target : 4 defects/Kloc defect density(quality) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Bullseye Figure for Project Variables cost Target: 100% Target : $70K Actual: 100% Actual: $90K this project capability duration Target : 30 wks Target : 4 defects/Kloc Actual: 1 defect/Kloc Actual: 20 wks defect density 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 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
Optimal Size for Interaction (Approximate) Effectiveness per developer What is the best range of people In a workgroup? 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: = engineer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Optimal Size for Interaction (Approximate) Effectiveness per developer Developer communicates regularly with eleven people. Communication time outweighs benefits of interaction 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 Key: = engineer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Hierarchical Project Management Organizations Smaller Projects: Larger 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 (A more Organic/Democratic Structure) 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.
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 Nasium 50% 25% Bart Simpson 100% Judy Jedi 75% 25%
One way to ... 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: requirements management leader: ... SRS design leader: implementation leader: 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 ... SQAP, STP ... SDD ... code base One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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 * Cost 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.
The Risk Management Mindset Identification Retirement 2. Java skills not high enough. 2. Retirement by avoidance: Use C++ Project finish Project finish Risk 2 Risk 2 Risk 1 Risk 1 1. Retirement by conquest: Demonstrate image super- imposition 1. May not be possible to superimpose images adequately. Project start Project start Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.
One way to ... 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) & 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
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 provided 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 For drawing designs functional object-oriented use-case-based Tracing tools requirements to designs designs to code To support testing To support maintenance To support project management schedule work breakdown To support configuration management For managing requirements 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 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 TOTALS $15 $10 Customize Ajax application ___ ___ _________________ $30 $51 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 Benefit of Language 1 1 to 10=best Benefit of Language 2 1 to 10=best Weight (1-10) Factor Internet-friendly 8 2 3 Familiarity to development team 3 9 8 Compilation speed 2 8 5 Runtime speed on processor p 7 3 1 3*8 + 8*3 + 5*2 + 1*7 = 65 3*2 + 8*9 + 5*8 + 1*3 = 121 Score Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
One way to ... 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 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 SCMP complete Begin system testing (2) SQAP complete Milestones (1*) Delivery SPMP rel. 1 complete (3) Freeze requirements (4) Iteration 1 (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.
Level Labor Allocation for Fixed Labor Total 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 Milestones Freeze requirements Karen vacation Complete testing Release to production 2 2 2 3 2 2 3 Iteration 1 Hal vacation 4 4 4 3 3 4 4 4 4 4 4 4 Iteration 2 2 2 2 1 1 1 4 To be assigned Risk ID & retire Given team size: 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.
IEEE 1058.1-1987 SPMP Table of Contents 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) 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
Gaming Industries Consolidated President IV&V . . . VP Marketing VP Engineering Software Engineering Labs . . . Game Lab . . . Game 123 Encounter SQA Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Table 2.9 Encounter Project Responsibilties Require- ments manageme nt leader Team leader CM Leader QA leader Design leader Implementati on Leader Member VP Software engineerin g lab Liaison Respon- sibility Engineer ing Marketing Docume nt Responsi -bility SQAP STP SPMP SCMP SRS SDD Code base Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Program Monitoring & Control Leader Facilitator Marketing liaison QA Game lab liaison Risk Responsibilty liaison retirement Report at weekly meeting Circulate weekly report Circulate biweekly report Circulate monthly report X X X 3* X 4* 1* 2* *Report formats 1 2 3 4 see CI 34: "monthly project status form" see CI 87: "monthly marketing status form" see CI 344: "weekly QA status form" see CI 48: "biweekly game lab result form" Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Team Leader CM QA Requ. Mngmnt Leader Design Leader Implemen- tation Leader Table 2.11 Encounter Staffing Plan Leader. Leader Name Ed Braun X X Al Pruitt X Fern Tryfill X Hal Furnass X Karen Peters X Soft. Eng. Lab Liaison with VP Eng. Marketing Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Work Breakdown Structure Excluding Secretarial Month 1 1 2 3 4 SCMP Month 2 1 2 3 4 Month 3 1 2 3 4 Month 4 1 2 3 4 Month 5 1 2 3 4 Complete testing SQAP Milestones Freeze requirements Delivery SPMP rel. 1 Iteration 1 Tasks Iteration 2 Risk I&R 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 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 1 F. Smith (tech support) .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 TOTAL 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.
Estimation Method Min Max Comment (K lines Java) Table 2.12 Very Rough Estimate of Application Size Prior to Requirements Analysis (1) 7.5 170 (2) 4.2 300 1.9-2.3 for two identified functions x 6-20 times as many in complete application (3) 11.4 46 Most Maximum of minimums and maximum of maximums. 11.4 300 conservative Least Minimum of minimums and minimum of maximums. 4.2 46 conservative Minimum of minimums and maximum of maximums. Widest range 4.2 300 Narrowest range Maximum of minimums and minimum of maximums. 11.4 46 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 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 SCMP complete Begin system testing (2) SQAP complete Milestones (1*) Delivery SPMP rel. 1 complete (3) Freeze requirements (4) Iteration 1 (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.
Likelihood 1-10 Impact 1-10 Retire- ment cost 1-10 1 = lowest retirement cost Priority computation Resulting priority Table 2.2 A way to compute risk priorities 1 = least likely 1 = least impact Lowest number handled first The 1 (11-10) *(11-10) *1 10 10 (most impact) highest priority risk (lowest retiremen t cost) (most likely) 1 The 10 (11-1) *(11-1) *10 1 1 lowest priority risk (highest retiremen t cost) (least likely) 1000 (least impact) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Table 2.3 Sample Risk Analysis for Encounter Case Study Risk title (details given above) Like- lihood 1-10 Im- pact 1-10 Retire- ment cost 1-10 1=lowest retirement cost Pri- ority Retirement / mitigation plan Respon- sible engineer Target com- pletion date # lowest number handled first 1=least likely 1=least impact Super- imposing images Experiment with Java images. 1 3 10 1 P. R. 2/1/99 8 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 2 Deficient Java skills 9 6 8 H. L. 4/15/99 80 Alan Gray may be pulled off this project Susan Ferris to inspect all of Alan's work Contin- ual 3 3 7 9 288 S.F. ... ... ... ... ... ... . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. ... ...
BONUS MATERIAL FOR PROJECT MEETINGS
Plan and Execute Meetings One way to ... 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.** E-mail 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.
