The document provides an overview of software project management concepts including what constitutes a project and program, factors that determine project success or failure, differences between software and other projects, types of software, common problems with software projects, and why projects need management. It also outlines the key activities in software project management including preplanning, planning, scheduling and control, and implementation/termination. Finally, it presents a 10 step process for project planning.
13. 1.10 Step Wise Project planning 1. Identify project objectives 2. Identify project infrastructure 3. Analyse project characteristics 4. Identify products and activities 5. Estimate effort for activity 8. Review/ publicize plan 6. Identify activity risks 7. Allocate resources 9. Execute plan 10. Lower level planning Review Lower level detail For each activity 0.Select project
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25. An ‘ideal’ activity Specify overall system Design Module A Design Integration Test case Design Module B Code module A Test Integration software Code module B
26. Step 4.5 Add check-points if needed Design module A Design module B Design system Design module C Code module A Code module B Code module C Test system Design module A Design module B Design system Design module C Code module A Code module B Code module C Test system Check-point put in a check point
27.
28.
29.
30.
31. Gantt charts Select subjects Design questionnaire Book machine Conduct tests Analyse results Week commencing 5 12 19 26 MARCH APRIL 9 16 Plan testing 2 Draft changes LT TA LT TA LT LT TA LT = lead tester TA = testing assistant
32.
33.
34. Step Wise Project planning 1. Identify project objectives 2. Identify project infrastructure 3. Analyse project characteristics 4. Identify products and activities 5. Estimate effort for activity 8. Review/ publicize plan 6. Identify activity risks 7. Allocate resources 9. Execute plan 10. Lower level planning Review Lower level detail For each activity 0.Select project
Here we follow the PRINCE approach of firstly identifying the products to be created. These products could be deliverables that will eventually be handed over to the customer, or intermediate products such as specifications and design documents, that are produced along the way. The PBS is a way of listing these products. In the scenario, the need for usability testing was identified, and the example of planning a usability test is used here. In order to do the testing, we need a set of selected subjects , a group of people who have similar characteristics to those who will finally use the system and who have agreed to try out the application. We need to have a booked PC that is available for testing when we need it. We are going to give each subject a questionnaire to complete when they have tried out the application ( completed questionnaire ), but we will need to have a questionnaire design first. We are also to observe the subjects using the application and collect details of things like the time taken to complete standard tasks and the errors they make ( test results ). These will then be analysed and the results put in an analysis report which will then be used to suggest changes to the application ( change requests ). All the boxes in the diagram which are not sub-divided at a lower level represent products. Boxes that are sub-divided (i.e. usability testing and testing arrangements ) are names given to the group of activities that are connected to them lower in the hierarchy.
The names of products on the PBS can be rather vague. If you were to ask someone to produce, for example, the ‘analysis report’ in the usability testing scenario, then you would need to explain exactly what you mean by that. This is done via a Product Description. PDs can usually be re-used from one project to another. Note that they are different from specifications – the explain in general terms what a product is and the description is relevant to all instances of that product. A specification describes a particular instance within the class of products.
The product flow diagram shows the order in which the products have to be completed. Effectively it defines a method of working. Note that as we drew up the PFD for the usability testing scenario, we identified an additional product called ‘testing plan’. The flow of the PFD is generally from top to bottom and left to right. We do no put in lines which loop back. This is not because iterative and back-tracking is not accepted. Rather it is that you can in theory jump back to any preceding product. For example, when producing the analysis report we might realise that there is a particular type of user that we have not included in our tests. We could go back and find some more selected subjects . However this would potentially mean that all the products that follow the one we have jumped back to would have to be reworked.
You now need to allocate resources (in particular, staff) to the activities in the plan. Where there is a resource constraint, that is there are not enough staff (or other resource) of the right type to start all the activities that run in parallel at the planned time, then the start of some activities may need to be delayed until the appropriate resources are available.
We now have the basic information needed to produce a plan. One way of presenting the plan is by means of a Gantt chart (named after Henry Gantt).
We have noted already that it is not feasible to produce a detailed plan for all stages of the project right at the beginning of the project planning process and not all the information needed for the detailed planning of the later stages is available at the outset. Initially an outline plan for the whole project would be produced, plus a detailed plan for the first stage.
![Till far we have studied ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)