Project Management - Lecture Slides | CMSC 435, Study Guides, Projects, Research of Software Engineering

Download Project Management - Lecture Slides | CMSC 435 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity! P j t tro ec managemen cmsc435 - 1 Objectives To explain the main tasks undertaken by project managers T i t d ft j t t d t o n ro uce so ware pro ec managemen an o describe its distinctive characteristics To discuss project planning and the planning process To show how graphical schedule representations are used by project management To discuss the notion of risks and the risk cmsc435 - 2 management process Tracking project progress Do you understand customer problem and needs? Can you design a system to solve customer problem or satisfy customer needs? How long will it take you to develop the system? How much will it cost to develop the system? cmsc435 - 3 Topics covered Management activities Project planning Project scheduling Risk management In many ways these are the activities that make software engineering different from cmsc435 - 4 programming Milestones and activities Activity: takes place over a period of time Milestone: completion of an activity -- a particular point in time Precursor: event or set of events that must occur in order for an activity to start Duration: length of time needed to complete an activity cmsc435 - 9 Due date: date by which an activity must be completed Managing groups Most software engineering is a group activity The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone. Group interaction is a key determinant of group performance. Flexibility in group composition is limited Managers must do the best they can with il bl l cmsc435 - 10 ava a e peop e. Project staffing May not be possible to appoint the ideal people to work on a project P j t b d t m t ll f th s f hi hlro ec u ge ay no a ow or e u e o g y- paid staff; Staff with the appropriate experience may not be available; An organization may wish to develop employee skills on a software project. Managers have to work within these constraints cmsc435 - 11 especially when there are shortages of trained staff. Factors influencing groups Group composition. Group cohesiveness. Group communications. Group organization. cmsc435 - 12 Group composition Group composed of members who share the same motivation can be problematic Task oriented everyone wants to do their own thing;- - Self-oriented - everyone wants to be the boss; Interaction-oriented - too much chatting, not enough work. An effective group has a balance of all types. This can be difficult to achieve software engineers are cmsc435 - 13 often task-oriented. Interaction-oriented people are very important as they can detect and defuse tensions that arise. Leadership depends on respect not titular status. Group leadership There may be both a technical and an administrative leader. Democratic leadership is more effective that autocratic leadership. cmsc435 - 14 Group organization Small software engineering groups are usually organized informally without a rigid structure. For large projects, there may be a hierarchical structure where different groups are responsible for different sub-projects. cmsc435 - 19 Informal groups The group acts as a whole and comes to a consensus on decisions affecting the system. The group leader serves as the external interface of the group but does not allocate specific work items. Rather, work is discussed by the group as a whole and tasks are allocated according to b l d cmsc435 - 20 a i ity an experience. This approach is successful for groups where all members are experienced and competent. Extreme programming groups Extreme programming groups are variants of an informal, democratic organisation. In extreme programming groups, some ‘management’ decisions are devolved to group members. Programmers work in pairs and take a collective responsibility for code that is d l d cmsc435 - 21 eve ope . More later with discussion of agile methods Chief programmer teams Consist of a kernel of specialists helped by others added to the project as required. The motivation behind their development is the wide difference in ability in different programmers. Chief programmer teams provide a supporting environment for very able programmers to be responsible for most of the system development. cmsc435 - 22 Project planning Probably the most time-consuming project management activity. Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available. Various different types of plan may be d l d h f cmsc435 - 23 eve ope to support t e main so tware project plan that is concerned with schedule and budget. Types of project plan Plan Description Quality plan Describes the quality procedures and standards that will be used in a project. See Chapter 27. Validation plan Describes the approach, resources and schedule used for system validation. See Chapter 22. Configuration management plan Describes the configuration management procedures and structures to be used. See Chapter 29. Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required See Chapter 21 cmsc435 - 24 . . Staff development plan. Describes how the skills and experience of the project team members will be developed. See Chapter 25. Project scheduling Expert judgment analogy proportion Delphi technique Wolverton model Algorithmic methods: E = (a + bSc) m(X) Walston and Felix model: E = 5 25S 0.91 cmsc435 - 29 . Bailey and Basili model: E = 5.5 + 0.73S1.16 Project scheduling Split project into tasks and estimate time and resources required to complete each task. Organize tasks concurrently to make optimal use of workforce. Minimize task dependencies to avoid delays caused by one task waiting for another to complete. (Pert or Gantt chart) Dependent on project managers intuition and cmsc435 - 30 experience. WBS (Work Breakdown Structure). Make parts small enough so that effort is known Tools – COCOMO, SLIM, Price S, Function Points The project scheduling process Estimate resources for activities Identify activity dependencies Identify activities Allocate people to activities Software requirements Activity charts and bar charts Create project charts cmsc435 - 31 Software Cost Estimation Basic method: 1. break system down into recognizable pieces 2 h . estimate eac piece 3. sum pieces together This works when we understand each decomposition and can estimate the pieces. For other engineering fields (e.g., bridge and tunnel building), thousands are built each year so the basic cmsc435 - 32 understanding is there. Not so with software. We don’t fully understand the decomposition principle to make well understood pieces. Software Cost Estimation However, even in other fields, estimation is not good if the product is new (e.g., although the McHenry tunnel in Baltimore was built well under budget there , were billions in overruns on the English-French “Chunnel”; also NASA and space station). There is still some belief in the “exchanging” of staff and time (e.g., Brook’s “Mythical Man Month”). R h i 1970 b d h d cmsc435 - 33 esearc n s, ase upon ar ware reliability theory, indicates that the “natural” growth of staff follows the Rayleigh curve. Rayleigh estimator Effort = 2 k a t e-at2 However, there is some empirical evidence that this schedule cannot be compressed more than about 25% ith ut dir c ns qu nc s cmsc435 - 34 w o e o e e e . Task durations and dependencies Activity Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) cmsc435 - 39 T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) Activity network cmsc435 - 40 Activity timeline cmsc435 - 41 Gantt chart cmsc435 - 42 Staff allocation 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 T8 T11 T12 T1 T3 T9 T2 T6 T10 Fred Jane Anne cmsc435 - 43 T7 T5Mary Jim Reallocation saves staff 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 T8 T11 T12 T1 T3 T9 T2 T6 Fred Jane Anne cmsc435 - 44 T7 T5Mary Jim T5 T10 One measure of risk – Utility functions Which of the following would you choose: 1. You can win between $0 and $1000 d l h h h Spin a ia containing t e numbers 1 t roug 10. If 1—9 show up, you get nothing; if 10 shows up you get $1000. Win $100 for doing nothing 2. You can lose between $0 and $1000 cmsc435 - 49 Spin a dial containing the numbers 1 through 10. If 1—9 show up, you pay nothing; if 10 shows up you pay $1000. Pay $100 for doing nothing Utility function experiment For 1, most people choose the $100 as “found money.” (E.g., in one class, 31 out of 46 chose this option.) It didn’t matter that they had the potential for winnin $1000g . But for 2, most people chose spinning the dial, even though they risked losing $1000 (e.g., 16 out of 46 chose paying $100). But both experiments were the same (minimal gain of +/- $100 and average gain or loss of $100), yet on the chances f l i l illi bl h if cmsc435 - 50 o os ng money, peop e were more w ng to gam e t an they were guaranteed a win. Understanding risk tolerance important for any project manager. 10 most important risk factors: From Capers Jones: From Barry Boehm: 1. Inaccurate metrics Personnel shortfalls 2. Inadequate measurement Unrealistic schedules and budgets 3. Excessive schedule pressure Wrong functionality 4. Inaccurate cost estimating Gold plating 5. Management malpractice (e.g., knowledge) Wrong user interface 6. Silver bullet syndrome (will save the project) Continuous requirements changes 7. Creeping user requirements Shortfalls in externally supplied components cmsc435 - 51 8. Low quality Shortfalls in externally provided tasks 9. Low productivity Real time performance constraints 10. Cancelled projects Straining computer science technology Note: Boehm’s experiences working for a DoD contractor (TRW) show up in his list – depending upon subcontracts (#7 #8) – and 1970s computer technology – performance (#9) Risk Factors (Reifer) Risk item Risk reduction Cost impact Late delivery of hardware Acquire time on another system Computer time costs N p tin s st m B n hm k l nd St ffin t p p ew o era g y e e c ar ear y a perform acceptance test before use a g o re are benchmark Feasibility of requirements Feasibility analysis and simulation Staffing to conduct analysis Staffing up Start recruiting and training early Recruiting and training costs Feasibility of design Peer reviews Added effort for review preparation Lack of management Use detailed work packaging Added effort to prepare cmsc435 - 52 visibility and weekly reporting inputs for reports Configuration integrity of software products Use formal change control system Purchase price of library plus administrative costs Lack of a test discipline Use independent test group and get them involved early Cost of using test group Software risks (Sommerville) Risk Affects Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with different priorities. Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Project and product There will be a larger number of changes to the requirements than anticipated. Specification delays Project and product Specifications of essential interfaces are not available on schedule Size underestimate Project and product The size of the system has been underestimated. cmsc435 - 53 CASE tool under- performance Product CASE tools which support the project do not perform as anticipated Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed. MANAGING RISK- Risk Assessment Risk identification – What can go wrong? Which of 10 Jones or Boehm risk factors are possible to occur? Technology risks. People risks. Organizational risks. Requirements risks. Estimation risks. Risk analysis – For each risk, what is the cost cmsc435 - 54 if it occurs? Risk prioritization – What is the probability that the risk may occur? What is the expected value of the loss (cost of risk times its probability of occurrence)? Risk analysis -2 Risk Probability Effects Organizational financial problems force reductions in the project budget. Low Catastrophic It is impossible to recruit staff with the skills required for the project. High Catastrophic Key staff are ill at critical times in the project. Moderate Serious Software components that should be reused contain defects which limit their functionality. Moderate Serious cmsc435 - 59 Changes to requirements that require major design rework are proposed. Moderate Serious The organisation is restructured so that different management are responsible for the project. High Serious Risk analysis -3 Risk Probability Effects The database used in the system cannot process as many transactions per second as expec ted. Moderate Serious The time required to develop the software is underestimated. High Serious CASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of requirements changes. Moderate Tolerable Required training for staff is not available. Moderate Tolerable cmsc435 - 60 The rate of defect repair is underestimated. Moderate Tolerable The size of the software is underestimated. High Tolerable The code generated by CASE tools is inefficient. Moderate Insignificant Risk planning Consider each risk and develop a strategy to manage that risk. Avoidance strategies The probability that the risk will arise is reduced; Minimization strategies The impact of the risk on the project or product will be reduced; cmsc435 - 61 Contingency plans If the risk arises, contingency plans are plans to deal with that risk; Risk management strategies Risk Strategy Organizational financial problems Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business. Recruitment problems Alert customer of potential difficulties and the possibility of delays, investigate buying-in components. cmsc435 - 62 Staff illness Reorganize team so that there is more overlap of work and people therefore understand each other’s jobs. Defective components Replace potentially defective components with bought- in components of known reliability. Risk management strategies -2 Risk Strategy Requirements changes Derive traceability information to assess requirements change impact, maximize information hiding in the design. Organizational restructuring Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business. Database performance Investigate the possibility of buying a higher- performance database cmsc435 - 63 . Underestimated development time Investigate buying in components, investigate use of a program generator Risk monitoring Assess each identified risks regularly to decide whether or not it is becoming less or b blmore pro a e. Also assess whether the effects of the risk have changed. Each key risk should be discussed at management progress meetings. cmsc435 - 64