SENG 380:Software Process and Management. Software Project planning

Size: px

Start display at page:

Download "SENG 380:Software Process and Management. Software Project planning"

Rolf Foster
6 years ago
Views:

1 SENG 380:Software Process and Management Software Project planning 1

2 Step Wise Planning Activities Step 0: Select project Step 1: Identify project scope and objectives Step 2: Identify project infrastructure Step 3: Analyze project characteristics Step 4: Identify project products and activities Step 5: Estimate effort for each activity Step 6: Identify activity risks 2

3 Step Wise Planning Activities Step 7: Allocate resources Step 8: Review/publicize plan Step 9: Execute plan Step 10: Execute lower levels of planning 3

4 Step Wise Framework 4

5 Step 1: Identify Project Scope and Objectives Step 1.1 Identify objectives and practical measures of the effectiveness in meeting those objectives. Correct definition of objectives. Identify measures of effectiveness for your objectives. Measures of effectiveness provides practical methods of checking that an objective has been met. Ex: measuring reliability: Mean time between failures. (Performance measure) Number of errors found during code inspections. (Predictive measure) 5

6 Step 1 (cont d) Step 1.2 Establish a project authority. To ensure the unity of purpose among all persons concerned. The project authority is usually: A project steering committee, A project board or project management board. The project authority have overall responsibility for setting, monitoring and modifying objectives. The project manager runs the project but reports regularly to the steering committee. 6

7 Step 1 (cont d) Step 1.3 Identify all stakeholders in the project and their interests. Step 1.4 Modify objectives in the light of stakeholder analysis. Based on the stakeholders requirements, it might be necessary to modify the project objectives. E.g. Adding new features to the system. This has to be done in a controlled manner. 7

8 Step 1 (cont d) Step 1.5 Establish methods of communication between all parties. Communication between stakeholders is important in all kinds of projects. It is more important to arrange for in a dispersed project. the way stakeholders will communicate is part of the project planning. 8

9 Step 1 (cont d) There has to be a communication plan: List the main stakeholders. With special attention to those involved in the development and implementation. List their concerns. Identify suitable methods for effective communications. consulting stakeholder s representatives would be a help 9

10 Step 1 (cont d) The communication plan could be documented in a table with the following headings: What? Name of the meeting. Who? Target audience. Purpose. When/frequency? Type/method? E.g. Meeting or a document distribution. Responsibility. the person initiating the meeting. 10

11 Step 2: Identify Project Infrastructure Step 2.1 Identify relationship between the project and strategic planning Select the projects to be carried out by an organization. Project portfolio. Programme management. managing a group of projects together in a coordinated way. It can ensure that a group of projects contribute to a common organizational strategy. 11

12 - Establish a framework within which the system fits. hardware and software standards should be followed. The software or components to be created should be compatible with those created by previous projects and with the existing HW and SW platforms.

13 Step 2 (cont d) Step 2.2 Identify installation standards and procedures. Identify standards and procedures related to the software project. E.g. specifying quality checks needed at each point of the project life cycle. The project manager should be aware of the Project planning and control standards. E.g how are hours spent by team members on tasks recorded on timesheets. 13

14 Step 2 (cont d) Step 2.3 Identify project team organization. e.g. a high level manager could decide that: software developers and business analysts could be in different groups. 14

15 Step 3: Analyse Project Characteristics Step 3.1 Distinguish the project as either objective-driven or product-driven. Step 3.2 Analyse other project characteristics (including quality-based ones). Step 3.3 Identify high level project risks. Step 3.4 Take into account user requirements concerning implementation. E.g. an organization might mandate the use of a particular development method. 15

16 Step 3 (cont d) Step 3.5 Select general life-cycle approach in the light of the above. Step 3.6 Review overall resource estimates. Up to this stage, the major risks of the project are identified the overall approach of the project is decided So, it is a good place to re-estimate the required effort and other resources for the project. 16

17 Step 4 (cont d) Step 4.1 Identify and describe project products. Identify all the products related to the project Account for the required activities. Products can be: Deliverables. Intermediate products. Technical products (e.g. training material, operating instructions). Products for management and quality (e.g. planning documents). 17

18 Step 4 (cont d) Products can be: Created from scratch. Modified version of something. Document. Person. Not an activity. Activity training Testing Designing Documenting. 18

19 Step 4: Identify Project Products and Activities Products will perform a hierarchy: Main products will have a set of components which in turn will have sub-components and so on. These relationships can be documented in a PBS product breakdown structure. 19

20 Product Breakdown Structure PBS for a software development task. 20

21 Product Breakdown Structure PBS for the products needed to produce an invitation to tender. 21

22 Product Breakdown Structure The tangible products are those at the bottom of the PBS that are not further subdivided. The boxes that are higher up are names of group of items. The products at the bottom of the PBS should be documented by Product Descriptions. The name, the purpose, the derivation of the product. The composition, the form the standards and quality criteria of the product. 22

23 Step 4 (cont d) Step 4.2 Document generic product flows. To document the relative order of the products. Some products will need other products to exist first before they can be created. E.g. the program code to be written need the program design, the program design needs the program specification. This can be portrayed in a PFD Product Flow Diagram. 23

24 Product Flow Diagram PFD for a software development task. 24

25 Product Flow Diagram PFD for the products needed to produce an invitation to tender. 25

26 Step 4 (cont d) Step 4.3 Recognize product instances. Some fragments in the PFD relates to more than one instance of a particular type of product. We should try to identify each of those instances. e.g. there could be only two modules related to the module product. 26

27 Step 4 (cont d) Step 4.4 Produce an ideal activity network Activity network shows : the tasks that have to be carried out and, their order of execution for the creation of a product. Activity networks don t take account of resource constraints. 27

28 Activity Network Diagram Test integrated software AND for a software development task. 28

29 Activity Network Diagram AND for the products needed to produce an invitation to tender. 29

30 Step 4 (cont d) Step 4.5 Modify the ideal to take into account need for stages and checkpoints. checkpoints To check compatibility of products of previous activities Milestones or key activities: Which represent the completion of important stages of the project. 30

31 Step 5: Estimate Effort for Each Activity Step 5.1 Carry out bottom-up estimates. need to estimate staff effort, time for each activity, and other resources. Step 5.2 Revise plan to create controllable activities. Long activity: break it down. Short activity: combine multiple small activities into one. Ideal activity: make the activity about the length of the reporting period. 31

32 Step 6: Identify Activity Risks Step 6.1 Identify and quantify the risks of each activity. Any plan is based on an assumption if the assumption is not correct this creates a risk to the plan. For each risk identify: Importance, Likelihood and Damage. 32

33 Step 6: Identify Activity Risks Step 6.2 Plan risk reduction and contingency measures where appropriate. For the identified risks: If (they didn t happen) yet then try to: Avoid risks. Reduce some of them. If a risk materializes (happens) then Use a contingency plan. Step 6.3 Adjust overall plans and estimates to take account of risks. e.g. add new activities that will reduce risks. 33

34 Step 7: Allocate Resources (Staffing) Step 7.1 Identify and allocate resources. type of staff needed for each activity. staff availabilities are identified. staff are provisionally allocated to task. 34

35 Step 7: Allocate Resources (Staffing) Step 7.2 Revise plans and estimates to take into account resource constraints. staffing constraints. Gantt charts: unlike the activity network they give a clear picture of when activities will take place and highlights which ones will be executed at the same time. 35

36 Gantt Chart 36

37 Step 8: Review/publicize Plan Step 8.1 Review quality aspects of the project plan. Each activity should have exit requirements or sign off requirements. Each activity should have quality criteria. Quality criteria : are quality checks that have to be passed before the product can be signed off as completed. 37

38 Step 8 (cont d) Step 8.2 Document plans and obtain agreement. all parties understand and agree to the commitments in the plan 38

39 Step 9/10: Execute plan/lower-level planning Plans will need to be more detailed for each activity as it becomes due. Detailed planning of later stages needs to be delayed because more information will be available nearer their start. But it is necessary to make provisional plans for more distant tasks. Why? 39

Lecture 04. Section - A

Lecture 04. Section - A Lecture 04 Section - A 1 Software Project Management 4th Edition Chapter 2 Step Wise: An approach to planning software projects 2 Introduction Products Steps continued.. Products The result of an activity