Software Project Management 4 th Edition Chapter 2

Software Project Management 4 th Edition Chapter 2 Step Wise: An approach to planning software projects 1 ©The Mc. Graw-Hill Companies, 2005

‘Step Wise’ - aspirations • Practicality – tries to answer the question ‘what do I do now? ’ • Scalability – useful for small project as well as large • Range of application • Accepted techniques – e. g. borrowed from PRINCE etc 2 ©The Mc. Graw-Hill Companies, 2005

‘Step Wise’ - an overview 1. Identify project objectives 0. Select project 2. Identify project infrastructure 3. Analyse project characteristics Review 4. Identify products and activities Lower level detail 10. Lower level planning 9. Execute plan 5. Estimate effort for activity 6. Identify activity risks For each activity 7. Allocate resources 8. Review/ publicize plan 3 ©The Mc. Graw-Hill Companies, 2005

4 ©The Mc. Graw-Hill Companies, 2005

5 ©The Mc. Graw-Hill Companies, 2005

3. 2 Step 0: Select Project • This is called Step 0 because in a way it is outside the main project planning process. 6 ©The Mc. Graw-Hill Companies, 2005

A project scenario • Hardware/software engineering company (C++ language of choice) • teams are selected for individual projects - some friction has been found between team members • HR manager suggests psychometric testing to select team 7 ©The Mc. Graw-Hill Companies, 2005

Project scenario - continued • Software package to be used to test staff • Visual basic suggested as a vehicle for implementation • usability is important - decision to carry out usability tests 8 ©The Mc. Graw-Hill Companies, 2005

Step 1 establish project scope and objectives The activities in this step ensure that all the parties to the project agree on the objectives and are committed to the success of the project. • 1. 1 Identify objectives and measures of effectiveness in meeting those objectives – ‘how do we know if we have succeeded? ’ – Ex of project objectives: to implement the new application on time and within budget; • 1. 2 Establish a project authority – ‘who is the boss? ’ 9 ©The Mc. Graw-Hill Companies, 2005

Step 1 continued • 1. 3 Identify all stakeholders in the project and their interests – ‘who will be affected/involved in the project? ’ – Ex of college payroll system stakeholders: • The finance department • The human resource department: supply most of employees details. • Heads of departments: submit part time staff hours work loads • 1. 4 Modify objectives in the light of stakeholder analysis • In order to gain the full cooperation of all concerned, it might be necessary to modify the project objectives. This could mean adding new features to the system which give a benefit to some stakeholders as a means of assuring their commitment to the project. 10 ©The Mc. Graw-Hill Companies, 2005

Step 1 continued – Example on Modify objectives in the light of stakeholder analysis: • in collage payroll system the human resources department has a lot of work preparing payroll details for finance. It would be tactful to agree to produce some management information reports for human resources from the payroll details held on the computer. • 1. 5 Establish methods of communication with all parties – ‘how do we keep in contact? ’ 11 ©The Mc. Graw-Hill Companies, 2005

Step 2 Establish project infrastructure • 2. 1 Establish link between project and any strategic plan – ‘why did they want the project? ’ • 2. 2 Identify installation standards and procedures – ‘what standards do we have to follow? ’ • 2. 3. Identify project team organization – ‘where do I fit in? ’ 12 ©The Mc. Graw-Hill Companies, 2005

Step 3 Analysis of project characteristics • 3. 1 Distinguish the project as either objective or product-based. • 3. 2 Analyse other project characteristics (including quality based ones) – what is different about this project? 13 ©The Mc. Graw-Hill Companies, 2005

Step 3 continued • Identify high level project risks – ‘what could go wrong? ’ – ‘what can we do to stop it? ’ • Take into account user requirements concerning implementation • Select general life cycle approach – waterfall? Increments? Prototypes? • Review overall resource estimates – ‘does all this increase the cost? ’ 14 ©The Mc. Graw-Hill Companies, 2005

Back to the scenario • Objectives vs. products • Some risks – team members worried about implications and do no co-operate – project managers unwilling to try out application – Developer not familiar with features of VB • Answer? - evolutionary prototype? 15 ©The Mc. Graw-Hill Companies, 2005

Step 4 Identify project products and activities • The more detailed planning of the individual activities now takes place. 4. 1 Identify and describe project products - ‘what do we A product breakdown structure have to produce? ’ (PBS) 16 ©The Mc. Graw-Hill Companies, 2005

• The products will form a hierarchy. • The main products will have sets of component products which in turn may have sub-component products, and so on. • These relationships can be documented in a Product Breakdown Structure (PBS) - see Figure 3. 2. • The only boxes that represent tangible products are those at the bottom of the hierarchy 17 ©The Mc. Graw-Hill Companies, 2005

Products • The result of an activity • Could be (among other things) – physical thing (‘installed pc’), – a document (‘logical data structure’) – a person (‘trained user’) – a new version of an old product (‘updated software’) 18 ©The Mc. Graw-Hill Companies, 2005

Products • The following are NOT normally products: – activities (e. g. ‘training’ , 'design' and 'testing'. ) – events (e. g. ‘interviews completed’) – resources and actors (e. g. ‘software developer’) - may be exceptions to this • Products CAN BE deliverable or intermediate 19 ©The Mc. Graw-Hill Companies, 2005

Product description (PD) contains: • the name/identity of the product; • the purpose of the product; • the derivation of the product (that is, the other products from which it is derived); • the composition of the product; • the form of the product; • the relevant standards; • the quality criteria that define whether the product is acceptable. 20 ©The Mc. Graw-Hill Companies, 2005

EXERCIS • It has been decided that the finance department at the college should carry out Acceptance testing of the new payroll system. • draws up a product description of a test case. Write the content for this product description. 21 ©The Mc. Graw-Hill Companies, 2005

22 ©The Mc. Graw-Hill Companies, 2005

Step 4 continued Testing plan 4. 2 document Generic product flows Selected subjects Questionnaire design Completed questionnaire Booked machine Test results Analysis report Change requests 23 ©The Mc. Graw-Hill Companies, 2005

Step 4. 3 Recognize product instances • The PBS and PFD will probably have identified generic products e. g. ‘software modules’ • It might be possible to identify specific instances e. g. ‘module A’, ‘module B’ … • But in many cases this will have to be left to later, more detailed, planning 24 ©The Mc. Graw-Hill Companies, 2005

4. 4. Produce ideal activity network • Identify the activities needed to create each product in the PFD • More than one activity might be needed to create a single product • Hint: Identify activities by verb + noun but avoid ‘produce…’ (too vague) • Draw up activity network 25 ©The Mc. Graw-Hill Companies, 2005

An ‘ideal’ activity Select subjects Plan testing Design questionnaire Conduct tests Analyse results Draft change requests Book machine 26 ©The Mc. Graw-Hill Companies, 2005

Step 4. 5 Add check-points if needed Design system Design module A Code module A Design module B Code module B Design module C Code module C Design module A Design system Design module B Design module C Test system put in a check point Code module A Code module B Check-point 27 Test system Code module C ©The Mc. Graw-Hill Companies, 2005

Step 5: Estimate effort for each activity • 5. 1 Carry out bottom-up estimates – distinguish carefully between effort and elapsed time • 5. 2. Revise plan to create controllable activities – break up very long activities into a series of smaller ones – bundle up very short activities (create check lists? ) 28 ©The Mc. Graw-Hill Companies, 2005

Step 6: Identify activity risks • 6. 1. Identify and quantify risks for activities – damage if risk occurs (measure in time lost or money) – likelihood if risk occurring • 6. 2. Plan risk reduction and contingency measures – risk reduction: activity to stop risk occurring – contingency: action if risk does occur 29 ©The Mc. Graw-Hill Companies, 2005

• 6. 3 Adjust overall plans and estimates to take account of risks – e. g. add new activities which reduce risks associated with other activities e. g. training, pilot trials, information gathering 30 ©The Mc. Graw-Hill Companies, 2005

Step 7: Allocate resources • 7. 1 Identify and allocate resources to activities • 7. 2 Revise plans and estimates to take into account resource constraints – e. g. staff not being available until a later date – non-project activities 31 ©The Mc. Graw-Hill Companies, 2005

Week commencing Plan testing Select subjects Design questionnaire Book machine Gantt charts MARCH 5 12 19 26 LT = lead tester TA = testing assistant APRIL 2 9 16 LT TA Conduct tests TA Analyse results LT Draft changes LT 32 ©The Mc. Graw-Hill Companies, 2005

Step 8: Review/publicise plan • 8. 1 Review quality aspects of project plan • 8. 2 Document plan and obtain agreement Step 9 and 10: Execute plan and create lower level plans 33 ©The Mc. Graw-Hill Companies, 2005