Software Project Management-Software Engineering-Lecture 05 Slides-Computer Science, Slides of Software Engineering

Download Software Project Management-Software Engineering-Lecture 05 Slides-Computer Science and more Slides Software Engineering in PDF only on Docsity! LECTURE 5: SOFTWARE PROJECT MANAGEMENT Software Engineering Mike Wooldridge Lecture 5 Software Engineering 1 Introduction • The “software crisis” of the 1960s and 1970s was so called because of a string of high profile software project failures: over budget, overdue, etc. • The crisis arose in part because the greater power available in computers meant that larger software projects were tackled with techniques developed on much smaller projects. • Techniques were needed for software project management. Good project management cannot guarantee success, but poor management on significant projects always leads to failure. Mike Wooldridge 1 Lecture 5 Software Engineering 2 Project Planning • The biggest single problem that afflicts software developing is that of underestimating resources required for a project. • Developing a realistic project plan is essential to gain an understanding of the resources required, and how these should be applied. • Types of plan: – Software development plan. The central plan, which describes how the system will be developed. – Quality assurance plan. Specifies the quality procedures & standards to be used. – Validation plan. Defines how a client will validate the system that has been developed. Mike Wooldridge 4 Lecture 5 Software Engineering – Configuration management plan. Defines how the system will be configured and installed. – Maintenance plan. Defines how the system will be maintained. – Staff development plan. Describes how the skills of the participants will be developed. •We will focus on software development & quality assurance plan. Mike Wooldridge 5 Lecture 5 Software Engineering 2.1 The Software Development Plan • This is usually what is meant by a project plan. • Specifies the order of work to be carried out, resources, responsibilities, and so on. • Varies from small and relatively informal to large and very formal. • Developing a project plan is as important as properly designing code: On the basis of a project plan, contracts will be signed and careers made or broken. . . • Important not to: – overestimate your team’s ability; – simply tell clients what they want to hear; – be pressured by developers (“we can do that in an afternoon!”) Mike Wooldridge 6 Lecture 5 Software Engineering • A workpackage is a large, logically distinct section of work: – typically at least 12 months duration; – may include multiple concurrent activities; – independent of other activities; – but may depend on, or feed into other activities; – typically allocated to a single team. • A task is typically a much smaller piece of work: A part of a workpackage. – typically 3–6 person months effort; – may be dependent on other concurrent activities; – typically allocated to a single person. Mike Wooldridge 9 Lecture 5 Software Engineering • A deliverable is an output of the project that can meaningfully be assessed. Examples: – a report (e.g., requirements spec); – code (e.g., alpha tested product). Deliverables are indicators (but only indicators) of progress. • A milestone is a point at which progress on the project may be assessed. Typically a major turning point in the project. EXAMPLES: – delivery of requirements spec; – delivery of alpha tested code. Mike Wooldridge 10 Lecture 5 Software Engineering • Usually. . . – work packages are numbered WP1, WP2, . . . ; – tasks are numbered T1.1, T1.2, etc, the first number is the number of the workpackage; the second is a sequence number. – deliverables are numbered D1.1, D1.2, etc – milestones are numbered M1, M2 etc. Mike Wooldridge 11 Lecture 5 Software Engineering 3 Gantt Charts & Activity Networks • Gantt charts are a kind of bar chart: – time plotted on x axis – bars on y axis for each activity. Mike Wooldridge 14 Lecture 5 Software Engineering • An activity network is a labelled graph, with: – nodes corresponding to activities, – arcs labelled with estimated times; – activities are linked if there is a dependency between them. Mike Wooldridge 15 Lecture 5 Software Engineering 4 Risks When planning a project, it is critically important to know what the key risks are, and is possible plan for them: • staff turnover; • management change; • hardware unavailability; • requirements change; • specification delays; • size underestimate; • technology change; • product competition. Mike Wooldridge 16