Teaching material for a course in Software Project Management & Software E ngineering – Part I

1. Teaching material for a course in Software Project Management & Software Engineering – Part I

2. Part 1: Project Management Chapter 1 (Introduction) • Any set of activities can be considered to be a Project if they have a definite start time and end time and these set of activities achieve some pre defined goals. • A project needs resources for a definite period of time. These resources are released after project gets completed.

3. Part 1: Project Management Fundamentals Chapter 1 (Project Management Introduction) Project consumes resources, time and budget

4. Part 1: Project Management Chapter 1 (Introduction) • A project can be initiated to build a road, a building, a software product etc. Managing a project will need different kinds of metrics, tools, skills etc. • A project can be broken down into project phases. These project phases include project initiation, project planning, project monitoring & control and project closure. • For each kind of project, there could be sub processes within each of the project phases. These sub processes are not related to project processes but belong to industry specific processes. For example, software development lifecycle processes (requirement gathering, software design etc.) fall within various project processes but are not part of project processes. • Software project management is the management of any software project. Specialized skills are needed to manage these projects for example software engineering, software testing, software design etc.

5. Part 1: Project Management Fundamentals Chapter 1 (Project Management Introduction) Project phases

6. Part 1: Project Management Fundamentals Chapter 1 (Introduction) • A software project will have processes like software life cycle processes (requirement gathering, software design, software construction, software testing etc.), software project processes, software configuration management

7. Part 1: Project Management Fundamentals Chapter 1 (Project Management Introduction) Software tasks in software projects

8. Part 1: Project Management Fundamentals Chapter 1 (Project Management Introduction) project phases with software lifecycle tasks

9. Part 1: Project Management Chapter 2 (Project Initiation) • Software projects are initiated in the same manner as any other type of projects. • Project charter is made by the top management of the organization for starting a software project. Project charter basically defines the purpose for starting the project. • A detailed project scope is developed to define boundaries of the project. The scope will include what functionalities are needed in the software product to be developed. It will also define level of quality needed in the software product.

10. Part 1: Project Management Chapter 2 (Project Initiation) • An initial budget is estimated for the project. As per the estimate a budget is sanctioned for the project. • The budget includes costs to cover for salaries of people who will work on the software project, purchase of hardware, services, travel costs, management costs etc.

11. Part 1: Project Management Chapter 2 (Project Initiation) • Project costs are directly related to size of the project. How much effort is needed to build the software product is the most crucial aspect for the project costs. The effort estimate will determine labor cost for the project.

12. Part 1: Project Management Chapter 2 (Project Initiation) • An initial project schedule is prepared for the project. The entire project work is broken down into smaller tasks. Which tasks will start and end at what times determines the project schedule. Accurate estimation of duration of each task, dependencies of tasks on each other are the factors which help in making the project schedule accurately. After refinement, the initial project schedule later becomes the baseline schedule. • For better project effort & cost estimate, a technique known as project division can be used (popular in Australia & New Zealand). Here after preparing project charter and scope, an expert is hired who will make effort and cost estimate. Now bids are invited from software development companies for project planning & execution based on the effort & cost figured given by the expert.

13. Part 1: Project Management Fundamentals Chapter 2 (Project Initiation) Initial project cost & effort estimate

14. Part 1: Project Management Fundamentals Chapter 2 (Project Initiation) Tentative project plan and schedule

15. Part 1: Project Management Fundamentals Chapter 2 (Project Initiation) project division for better project size estimate

16. Part 1: Project Management Fundamentals Chapter 3 (Effort & Cost Estimation) • Software projects are inherently effort driven because most of work involves human effort to build the software product. • Estimating the effort required to build the software product is difficult as the result of effort is intangible and difficult to make effort estimation in building software artifacts.

17. Part 1: Project Management Fundamentals Chapter 3 (Effort & Cost Estimation) • There are many techniques like function point analysis, wide band delphi, COCOMO etc. for making effort estimation on software projects. • Depending on requirement, a suitable effort estimation technique is chosen for any software project. • Since effort estimation techniques are not foolproof, effort estimates need to be revised as the project progresses.

18. Part 1: Project Management Fundamentals Chapter 3 (Project Effort Estimation) Function point count for effort estimate (function point analysis technique)

19. Part 1: Project Management Fundamentals Chapter 3 (Project Effort Estimation) Function count type for effort estimate (function point analysis technique)

20. Part 1: Project Management Fundamentals Chapter 3 (Project Effort Estimation) Effort sizing for effort estimate (function point analysis technique)

21. Part 1: Project Management Fundamentals Chapter 3 (Project Effort Estimation) Effort estimate for iterative projects

22. Part 1: Project Management Fundamentals Chapter 3 (Effort & Cost Estimation) • Once effort estimates are made for the project, cost estimates are calculated based on the effort estimate and cost parameters like hourly salary of individual employees. • Cost estimates are done using techniques like activity based costing or cost factor analysis.

23. Part 1: Project Management Fundamentals Chapter 3 (Effort & Cost Estimation) • Software projects use different kinds of software development life cycle models like waterfall model, iterative model etc. Effort estimation for each type of software development lifecycle model requires understanding the difference in the way the software product is built. In iterative models, software products are built in small incremental cycles. On the contrary in the waterfall model, software products are built in one go and thus all product features are fully built in the same one cycle. This fundamental difference necessitates a different approach to effort estimation for each type of software development lifecycle model projects.

24. Part 1: Project Management Fundamentals Chapter 3 (Effort & Cost Estimation) • Software products are made manually by software engineers. How many of these people are needed on the project and for how long, is determined by the effort estimate and project duration. • Resource estimation also needs to take into consideration the skill set required on the project. Off course speed with which a software engineer can build a software product varies and thus this factor can affect resource estimation on the project.

25. Part 1: Project Management Fundamentals Chapter 3 (Project Effort Estimation) Comparison of effort estimate techniques

26. Part 1: Project Management Fundamentals Chapter 3 (Project Effort Estimation) Effort and cost for various project tasks

27. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) • Any project needs to start and end at the pre defined dates. There could be risks like resource unavailability, service breakdown problems, technology obsolescence, wrong selection of project tools etc. These risks can occur and can hamper project progress. Finding chances of occurrences of risks and finding ways to tackle them is important. So risk management is very important for any project.

28. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) • Risk can hamper a project either affecting product quality or rate of production. Product quality can go down if software engineers lack adequate skills or not enough time could be allotted for testing. Rate of production may go down if adequate resources are not allocated on the project.

29. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) Major risk types on projects

30. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) Major causes of risks on projects

31. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) Mitigating risks through schedule buffer on projects

32. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) Mitigating resource risks through knowledge management system

33. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) Mitigating quality risks through quality gates on projects

34. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) Risk management through risk prioritization

35. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) • Each kind of risk which can occur on a project should be identified and then evaluated for the kind of impact it can have on the project. Probability for the risk to occur should also be identified. Together with impact and probability, the risk factor can be devised for each risk on the project.

36. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) • The biggest benefit of iterative software development lifecycle model is that it minimizes risks. In the waterfall model, the software product is available for end user review only after the complete software product is built. If there were misunderstandings in getting end user requirements right then the software product built will not be suitable to the end users. In iterative models, this risk is minimized by building small set of features and getting them reviewed by end users. If any features are not correct then making the required changes at this stage is not costly.

37. Part 1: Project Management Fundamentals Chapter 4 (Risk Management) Risks of waterfall model

38. Part 1: Project Management Fundamentals Chapter 5 (Configuration Management) • Software product features need to be changed if end users make a request. This is not unusual and is a common practice on software projects. There could be many change requests during the entire project duration. Thus many different versions of the software product results. Managing change requests and different versions of the software product is done in configuration management.

39. Part 1: Project Management Fundamentals Chapter 5 (Configuration Management) Characteristics required for a good configuration management system

40. Part 1: Project Management Fundamentals Chapter 5 (Configuration Management) Document attributes needed to keep documents unique

41. Part 1: Project Management Fundamentals Chapter 5 (Configuration Management) Document version control in configuration management system

42. Part 1: Project Management Fundamentals Chapter 5 (Configuration Management) Characteristics of a good configuration management system

43. Part 1: Project Management Fundamentals Chapter 5 (Configuration Management) Characteristics go a good configuration management system

44. Part 1: Project Management Fundamentals Chapter 6 (Project Planning) • In project planning phase, elaborate planning for all project components are made. You create baseline structure here which is used to execute, monitor and control the project. • Project planning consists of project scheduling, project budgeting, manpower planning, communication planning, quality planning etc. • Project scheduling can be done in 2 ways. Top down planning and bottom up planning. But first of all you need to break the entire project work into manageable small tasks. In top down planning you first assign time duration for the entire project. Later you assign time duration for smaller tasks within the time periods of their respective container bigger tasks. In bottom up planning, time duration is assigned to small tasks first. Later, the time duration of all smaller tasks are added up to come up with time duration of their container larger task.

45. Part 1: Project Management Fundamentals Chapter 6 (Project Planning) Software Project planning components

46. Part 1: Project Management Fundamentals Chapter 6 (Project Planning) Software Project planning inputs for top down planning technique

47. Part 1: Project Management Fundamentals Chapter 6 (Project Planning) Software Project planning ouputs for top down planning technique

48. Part 1: Project Management Fundamentals Chapter 6 (Project Planning) Software Project planning inputs for bottom up planning technique

49. Part 1: Project Management Fundamentals Chapter 6 (Project Planning) Software Project planning outputs for bottom up planning technique

50. Part 1: Project Management Fundamentals Chapter 6 (Project Planning) • Work breakdown structure (WBS) is the systematic way of breaking down the complete project work into smaller tasks. WBS also maintains relationship among tasks so that it is possible to know which tasks precede another tasks, which tasks can not start before completion of some other task etc. • Once WBS structure for tasks is ready then you can allocate resources for each task. Resource allocation should be based on closely matching required skills with those available. How many resources should be allocated on a task will depend on the amount of effort required and for how long the task will run. For example, if a task requires 50 hours of work and should be completed in 2 days (16 hours) then you should assign 3 resources on this task. Still you will need to over burden any resource for 2 hours of overtime work.