SOFTWARE PROJECT PLANNING

1. SOFTWARE PROJECT PLANNING Submitted to:- Submitted by:- Er. Anshu Parashar Ankita(1706210) Karan(1706208)

2. CONTENTS • Who needs software? • Introduction to project planning • Activities included in project planning • Statement of work • Resource list • Estimation • Scheduling • Risk management

3. Who needs software? • Most software is built in organizations for people with specific needs. • A stakeholder is anyone who has an interest (or stake) in the software being completed • A user is someone who will need to use the software to perform tasks. • Sometimes stakeholders will be users; but often the stakeholder will not use the software.

4. Role of Project Manager The project manager plans and guides the software project: • The project manager is responsible for identifying the users and stakeholders and determining their needs • The project manager coordinates the team • To do this well, the project manager must be familiar with every aspect of software engineering

5. Project Planning • When: need for software has already been established; stakeholders are on-board; coding is ready to begin • What: project planning spans five major activities— • preparing a Statement of work (SOW) • preparing a Resource List • Estimation • Scheduling • Risk analysis

6. Statement of Work The statement of work (SOW) is a detailed description of all of the work products which will be created over the course of the project It includes: • A list of features that will be developed • A description of each intermediate deliverable or work product that will be built.

7. Resource List The project plan should contain a list of all resources that will be used on the project. • A resource is a person, hardware, room or anything else that is necessary for the project but limited in its availability • The resource list should give each resource a name, a brief one-line description, and list the availability and cost (if applicable) of the resource

8. Estimation • Planning requires estimation early-on, even though it is likely this “commitment” will be proven wrong • Some degree of uncertainty is unavoidable when predicting into the future • Solid techniques and concrete procedures help reduce the inaccuracy of estimates

9. Process-based estimation • Most commonly-used technique for project estimation • Project is broken down into a relatively small set of tasks and the effort required to accomplish each task is estimated • Begins with a delineation of software functions obtained from the project scope

10. Process-based estimation • A series of framework activities must be performed for each function • Representative framework activities: • Customer communication • Planning / risk analysis • Engineering • Construction / release

11. Process-based estimation • Once functions and activities are melded, the planner estimates the effort (person-months) required to accomplish each activity per function • Average labor rates are then applied to the estimated efforts (may vary per task) • Cost and effort for each function and activity (row and column totals) are computed as the last step

12. Estimation with use-cases • Use-cases provide insight into software scope and requirements • However, developing an estimation approach with use-cases is problematic: • There is no standard form for use-cases • They represent an external view (the user’s view) of the software, and vary in levels of abstraction • Use-cases do not address the complexity of a feature • Use-cases do not describe complex interactions between many functions and features

13. Use-case estimation • A structural hierarchy is described for the project • Any level of the hierarchy can be described by no more than 10 use-cases • Each of the use-cases would encompass no more than 30 distinct scenarios

14. Use-case estimation • Use-cases for a large system are described at a much higher level of abstraction then use-cases for individual sub-systems • Before use-cases can be used: • The level within the structural hierarchy is established • Average length (in pages) of each use-case is determined • The type of software (business, scientific, etc) is defined • Rough architecture for the system is considered

15. Use-case estimation • Once those characteristics are established, empirical data can be used to determine estimated LOC or FP per each use-case for each level of the hierarchy • Historical data are then used to calculate the effort required to develop the system

16. Sample use-case estimation LOC = N × LOCavg + [(Sa/Sh - 1) + (Pa/Ph - 1)] × LOCadjust N = actual number of use-cases LOCavg= historical average LOC per use-case for this type of system Sa = actual scenarios per use-case Sh= average scenarios per use-case for this type of system Pa = actual pages per use-case Ph = average pages per use-case for this type of system LOCadjust= represents an adjustment based on n percent of LOC where n is defined locally and represents the difference between this project and “average” projects

17. Reconciling estimates • The various estimation methods encountered result in multiple estimates which must be reconciled • Widely divergent estimates can often be traced • The planner must determine the cause of the divergence to reconcile the estimates • The goal of a reconciliation process is to produce a single estimate of effort, project duration, or cost

18. .Project Scheduling….. The scheduling process 18

19. Project Schedule • A project Schedule is at two levels – • Overall schedule • Detailed schedule • Overall schedule comprises of major milestones and final date • Detailed schedule is the assignment of lowest level tasks to resources

20. Overall Schedule • Depends heavily on the effort estimate • For an effort estimate, some flexibility exists depending on resources assigned • One method is to estimate schedule S (in months) as a function of effort in PMs • Can determine the function through analysis of past data; the function is non linear • COCOMO: S = 2.5 E 3.8

21. An Example Schedule

22. Detailed Scheduling • To reach a milestone, many tasks have to be performed • Lowest level tasks - those that can be done by a person (in less than 2-3 days) • Scheduling - decide the tasks, assign them while preserving high-level schedule • Any activity to be done must get reflected in the detailed schedule

23. An example task in detail schedule 23

24. ..Project Scheduling…. Graphical notations used in software project scheduling: Tables: summary description of tasks Bar charts: show schedule against the time Activity charts: graphs that depict dependencies between tasks and indicate the critical path (the longest path in the activity graph) 24

25. ….Project Scheduling.. Example of activity chart 25

26. …..Project Scheduling. Example of bar chart 26

27. Risk Management • A risk plan is a list of all risks that threaten the project, along with a plan to mitigate some or all of those risks. • Risk: any condition or event whose occurrence is not certain but which can cause the project to fail • Aim of risk management: minimize the effect of risks on a project

28. Risk Management Tasks

29. THANK YOU