Lectures Software Engineering - Chapter 4: Project management

36 trang hoanguyen 4110

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 4: Project management", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_4.ppt

Nội dung text: Lectures Software Engineering - Chapter 4: Project management

Project management l Organising, planning and scheduling software projects ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 1
Objectives l To introduce software project management and to describe its distinctive characteristics l To discuss project planning and the planning process l To show how graphical schedule representations are used by project management l To discuss the notion of risks and the risk management process ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 2
Topics covered l Management activities l Project planning l Project scheduling l Risk management ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 3
Software project management l Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software l Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 4
Software management distinctions l The product is intangible l The product is uniquely flexible l Software engineering is not recognized as an engineering discipline with the sane status as mechanical, electrical engineering, etc. l The software development process is not standardised l Many software projects are 'one-off' projects ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 5
Management activities l Proposal writing l Project planning and scheduling l Project costing l Project monitoring and reviews l Personnel selection and evaluation l Report writing and presentations ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 6
Management commonalities l These activities are not peculiar to software management l Many techniques of engineering project management are equally applicable to software project management l Technically complex engineering systems tend to suffer from the same problems as software systems ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 7
Project staffing l May not be possible to appoint the ideal people to work on a project • Project budget may not allow for the use of highly-paid staff • Staff with the appropriate experience may not be available • An organisation may wish to develop employee skills on a software project l Managers have to work within these constraints especially when (as is currently the case) there is an international shortage of skilled IT staff ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 8
Project planning l Probably the most time-consuming project management activity l Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available l Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 9
Project plan structure l Introduction l Project organisation l Risk analysis l Hardware and software resource requirements l Work breakdown l Project schedule l Monitoring and reporting mechanisms ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 12
Activity organization l Activities in a project should be organised to produce tangible outputs for management to judge progress l Milestones are the end-point of a process activity l Deliverables are project results delivered to customers l The waterfall process allows for the straightforward definition of progress milestones ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 13
Project scheduling l Split project into tasks and estimate time and resources required to complete each task l Organize tasks concurrently to make optimal use of workforce l Minimize task dependencies to avoid delays caused by one task waiting for another to complete l Dependent on project managers intuition and experience ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 15
Scheduling problems l Estimating the difficulty of problems and hence the cost of developing a solution is hard l Productivity is not proportional to the number of people working on a task l Adding people to a late project makes it later because of communication overheads l The unexpected always happens. Always allow contingency in planning ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 17
Bar charts and activity networks l Graphical notations used to illustrate the project schedule l Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two l Activity charts show task dependencies and the the critical path l Bar charts show schedule against calendar time ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 18
Risk management l Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. l A risk is a probability that some adverse circumstance will occur. • Project risks affect schedule or resources • Product risks affect the quality or performance of the software being developed • Business risks affect the organisation developing or procuring the software ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 23
The risk management process l Risk identification • Identify project, product and business risks l Risk analysis • Assess the likelihood and consequences of these risks l Risk planning • Draw up plans to avoid or minimise the effects of the risk l Risk monitoring • Monitor the risks throughout the project ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 25
Risk identification l Technology risks l People risks l Organisational risks l Requirements risks l Estimation risks ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 27
Risk analysis l Assess probability and seriousness of each risk l Probability may be very low, low, moderate, high or very high l Risk effects might be catastrophic, serious, tolerable or insignificant ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 29
Risk planning l Consider each risk and develop a strategy to manage that risk l Avoidance strategies • The probability that the risk will arise is reduced l Minimisation strategies • The impact of the risk on the project or product will be reduced l Contingency plans • If the risk arises, contingency plans are plans to deal with that risk ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 31
Risk monitoring l Assess each identified risks regularly to decide whether or not it is becoming less or more probable l Also assess whether the effects of the risk have changed l Each key risk should be discussed at management progress meetings ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 33
Key points l Good project management is essential for project success l The intangible nature of software causes problems for management l Managers have diverse roles but their most significant activities are planning, estimating and scheduling l Planning and estimating are iterative processes which continue throughout the course of a project ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 35
Key points l A project milestone is a predictable state where some formal report of progress is presented to management. l Risks may be project risks, product risks or business risks l Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 4 Slide 36