1. Project management

2. Software project management ■It is the discipline of planning, organizing and managing resources to bring about the successful completion of specific project goals and objectives. ■Requires professional skills. ■Includes 2 very crucial aspects: Planning and Control. ■The goal is to ensure prompt completion times, minimum costs, and required functionality.

3. Management activities ■Proposal writing. ■Project planning and scheduling. ■Project costing. ■Project monitoring and reviews. ■Personnel selection and evaluation. ■Report writing and presentations.

4. Project planning  Planning is the most important project management activity.  It has two basic objectives:  Establish reasonable cost, schedule, and quality goals for the project.  Draw out a plan to deliver the project goals.  The inputs to the planning activity are :  The requirements specification.  The architecture description.  A very detailed requirements document is not essential for planning, but for a good plan all the important requirements must be known, and it is highly desirable that key architecture decisions have been taken.

5. Project planning There are generally two main outputs of the planning activity:  Project Management Plan document :  That establishes the project goals on the cost, schedule, and quality fronts, and defines the plans for managing risk, monitoring the project, etc.;  Detailed Project Schedule (detailed plan):  Specifying the tasks that need to be performed to meet the goals, the resources who will perform them, and their schedule. o Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget.

6. Types of project plan

7. The project plan ■The project plan sets out: –The resources available to the project; –The work breakdown; –A schedule for the work.

8. Project plan structure ■Introduction. ■Project organisation. ■Risk analysis. ■Hardware and software resource requirements. ■Work breakdown. ■Project schedule. ■Monitoring and reporting mechanisms.

9. Effort Estimation  For a software development project, overall effort and schedule estimates are essential prerequisites for planning the project.  These estimates are needed before development is initiated, as they establish the cost and schedule goals of the project(Why?).  Without these, even simple questions like “is the project late?” “are there cost overruns?” and “when is the project likely to complete?” cannot be answered.

10. Effort Estimation  Size of the software is a major factor in determining how much effort is needed to build it. That is, the larger the project, the greater is the effort requirement. lines of code )  Software Size can counted in terms of LOC, KLOC ( lines of code ).  Work effort (man-months) is the labor required to complete an activity.  Work effort is typically the amount of focused and uninterrupted labor time required to complete an activity. (P/H), (P/M), (S/M), (M/H).(person/month).

11. Effort Estimation There are two commonly used approaches in estimating effort:  Top-Down Estimating Approach : analogy, group consensus, or mathematical relationships  Bottom-Up Estimating Approach: estimates of elements of the work breakdown structure.

12. Top-Down Estimating Approach ■The top-down approach considers effort as a function of project size. ■This approach can work only if the size and type of the project are similar to the set of projects from which the productivity P was obtained (and that in the new project a similar productivity can be obtained by following a process similar to what was used in earlier projects). ■In Top-Down approach for estimation of effort, some equation is used to estimate the total effort required for entire project.

13. Top-Down Estimating Approach A more general function for determining effort from size that is commonly used is of the form: EFFORT = a * SIZE b ■project size is generally in KLOC based on project type/complexity: ■where a and b are constants its change based on project type/complexity:

14. Example The lead developer is consulted to give estimate of the expected size of the new project. The opinion is that this project will be about 50,000 lines of C++. Calculate the effort (man/hour). Note : The project type is Organic.

15. Bottom-Up Estimating Approach:  In this approach, the estimate is first obtained for every parts of the project, then the overall estimate is obtained.  This type of approach is also called activity-based estimation.  This approach does not require size to be estimated.  This approach is also used when a project involves mix of different software language & technologies, making size estimation difficult.

16. Bottom-Up Estimating Approach: The risk involved in bottom-up approach are:  Miss some important activity  Difficult to estimate task overhead (project management which can span the entire project)

17. Conclusion..  Both top-down & bottom-up approach require information about the project to estimate –Size for Top-Down approach –List of task for Bottom-Top approach  Both types of estimates become more accurate if more information is available about the project or as the projects proceeds.

18. Project staffing ■May not be possible to appoint the ideal people to work on a project –Project budget may not allow for the use of highly- paid staff; –Staff with the appropriate experience may not be available; –An organisation may wish to develop employee skills on a software project. ■Managers have to work within these constraints especially when there are shortages of trained staff.

19. Project scheduling. ■person and months are not fully interchangeable in a software project. ■Person and months can be interchanged only if all the tasks in the project done in parallel, and no communication is needed between people performing the tasks. ■This is not true for software projects—there are dependencies between tasks, and a person performing some task in a project needs to communicate with others performing other tasks.

20. Project scheduling.  once the effort is fixed, there is some flexibility in setting the schedule by appropriately staffing the project, but this flexibility is not unlimited.

21. 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. ■Dependent on project managers intuition and experience.

22. The project scheduling process

23. Bar charts and activity networks ■Graphical notations used to illustrate the project schedule. ■Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two. ■Activity charts show task dependencies and the critical path. ■Bar charts show schedule against calendar time.

24. Task durations and dependencies

25. Activity network

26. Staff allocation

27. Risk management.. ■Risk is defined as an exposure to the chance of injury or loss. ■A risk is a probabilistic event—it may or may not occur. ■A risk is a probability that some adverse circumstance will occur –Project risks affect schedule or resources; –Product risks affect the quality or performance of the software being developed; –Business risks affect the organisation developing or procuring the software.

28. Risk management ■The aim of risk management is not to avoid getting into projects that have risks but to minimize the impact of risks in the projects that are undertaken. ■Risk management has to deal with identifying the undesirable events that can occur, the probability of their occurring, and the loss if an undesirable event does occur. ■Risk management revolves around risk assessment and risk control.

29. Software risks

30. The risk management process ■Risk identification –Identify project, product and business risks; ■Risk analysis –Assess the likelihood and consequences of these risks; ■Risk planning –Draw up plans to avoid or minimise the effects of the risk; ■Risk monitoring –Monitor the risks throughout the project;

31. The risk management process

32. Risk identification ■Risk identification is the first step in risk assessment, which identifies all the different risks for a particular project. ■Checklists of frequently occurring risks are probably the most common tool for risk identification. Risk type : ■Technology risks. ■People risks. ■Organisational risks. ■Requirements risks. ■Estimation risks.

33. Risks and risk types

34. Risk analysis ■In risk analysis, the probability of occurrence of a risk has to be estimated, along with the loss that will occur if the risk does materialize. ■Probability may be very low, low, moderate, high or very high. ■Risk effects might be catastrophic, serious, tolerable or insignificant. ■Once the probabilities of risks materializing and losses due to materialization of different risks have been analyzed, they can be prioritized. ■One approach for prioritization is through the concept of risk exposure (RE).

35. Risk analysis (i)

36. Risk planning ■Consider each risk and develop a strategy to manage that risk. ■Avoidance strategies –The probability that the risk will arise is reduced; ■Minimisation strategies –The impact of the risk on the project or product will be reduced; ■Contingency plans –If the risk arises, contingency plans are plans to deal with that risk;

37. Risk monitoring ■Assess each identified risks regularly to decide whether or not it is becoming less or more probable. ■Also assess whether the effects of the risk have changed. ■Each key risk should be discussed at management progress meetings.

38. Risk indicators