Question? Leave a message!




Project Management

Project Management 36
Project Management Massimo Felici Room 1402, JCMB, KB 0131 650 5899 mfeliciinf.ed.ac.ukƒƒ Project Management Software project management is an essential part of software engineering •Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organizations developing and procuring the software • Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software The Good, the Bad and the Ugly • Good management cannot guarantee project success • Bad Management usually results in project failures • Software is delivered late, costs more than originally estimated and fails to meet its requirements …The Ugly © 20042006 SEOC Lecture Note 07 2ƒƒƒ Software Management Distinctions The product is intangible and uniquely flexible The software development process is not standardised Large software projects are often 'oneoff' projects © 20042006 SEOC Lecture Note 07 3ƒƒƒƒƒ The Role of the Project Manager Software managers are responsible for planning and managing project development Estimation of the project effort, time and cost Planning. Scheduling deliverables, review points and allocation of staff to activities Replanning. Reestimating and rescheduling in the light of unfolding circumstances, e.g., risks and quality assurance results Organization. Establishing a division of labor which is able to make the most effective use of available skills and maximizes productivity potential in the context of characteristics (e.g., risk factors) of the particular project Quality assurance. Planning and carrying out actions to ensure that the software product meets required quality targets © 20042006 SEOC Lecture Note 07 4ƒƒƒƒƒ ƒƒƒƒ Project Planning Types of project plan Probably the most time Quality plan: describes the consuming project management quality procedures and standards that will be used in activity the project Validation plan: describes the Continuous activity from initial approach, resources and concept through to system schedule used for system validation delivery Configuration Management plan: Plans must be regularly revised describes the configuration management procedures and as new information becomes structures to be used available Maintenance plan: predicts the maintenance requirements of Various different types of plan the system, maintenance costs and effort required may be developed to support the Staff Development plan: main software project plan that describes how the skills and experience of the project team is concerned with schedule and members will be developed budget © 20042006 SEOC Lecture Note 07 5ƒƒƒ Scoping the Problem Objectives expressed in general terms and in the language application domain Scope defines the system boundary, explaining what will be included in the system and what will not be included Identify: the Customer, the system environment, necessary tools, potential reuse, etc. • Ask the Customer: Who is the end user (often not the customer) Who has the authority to accept the finished product What problem are we addressing What documentation will be required When do they believe they need the product Where is the work to be dune Why do they need the product How will the product be developed/acquired © 20042006 SEOC Lecture Note 07 6ƒƒƒ Other Management Activities… Measurement Framework allows the quantitative analysis of project (e.g., productivity, progress, etc.) and product features (e.g., quality, size, etc.) • Software Metrics. Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real word in such a way as to describe them according to clearly defined rules. • Quality Assurance plan describes how reviews, inspections, testing, and other techniques will help to evaluate quality and ensure that it meets the customer’s needs. Resource management identifies (and quantifies) the (needed) resources and describes how resources are allocated throughout the project • Resources include infrastructure, staff and time. Feasibility study also explores alternative solutions © 20042006 SEOC Lecture Note 07 7ƒƒƒƒ Activity Organization and Milestones Activities in a project should be organised to produce tangible outputs for management to judge progress Milestones are the endpoint of a process activity Deliverables are project results delivered to customers The waterfall process allows for the straightforward definition of progress milestones Milestones in the Requirements Engineering Process Sommerville, 2004 © 20042006 SEOC Lecture Note 07 8ƒƒƒ Project Personnel Determine the project schedule and estimate the associated effort and costs • How many people will be involved in the project • What tasks they will perform • What abilities and experience they must have so that they can do their job effectively The assignment of staff to tasks depends on project size, staff expertise and staff experience People have different work styles (e.g., preferred styles for interacting with others) © 20042006 SEOC Lecture Note 07 9ƒƒƒƒ ƒƒƒƒ Project Scheduling Split project into tasks and Problems estimate time and resources Estimating the difficulty of required to complete each task problems and hence the cost of Organize tasks concurrently to developing a solution is hard make optimal use of workforce Productivity is not proportional to Minimize task dependencies to the number of people working on a avoid delays caused by one task task waiting for another to complete Adding people to a late project Dependent on project managers makes it later because of intuition and experience communication overheads The unexpected always happens. Always allow contingency in planning Sommerville, 2004 © 20042006 SEOC Lecture Note 07 10ƒƒƒ Tracking Progress and Control Scheduling explores possible ways of allocating (limited) resources across tasks Project scheduling involves separating the total work involved in a project into separate activities and judging the time required to complete these activities. Project can be late with respect to the initial plan. It is important to track the progress of the project and compare it to the plan. If significant divergences arise it is necessary to replan to take account of the changed circumstances. © 20042006 SEOC Lecture Note 07 11(Graphical) Notations Sommerville, 2004 Task Durations and Dependencies Activity Network ActivityDuration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) Activity Timeline Staff Allocation © 20042006 SEOC Lecture Note 07 12ƒƒƒƒ ƒƒƒ Risk Management Project managers must engage in Risk Identification concerns risk management to understand with discovering possible risks and control the risks on their to the project projects Risk Analysis considers each A Risk is an unwanted event that identified risk and makes a has negative consequences judgment about the probability • Risk impact: the loss and seriousness of it associated with the event Risk Planning considers each •Risk probability: the identified risk and identifies likelihood of the risk, strategies to manage the risk measured from 0 Risk Monitoring involves (impossible) to 1 (certainty) regularly assessing each • Risk control: the degree to identified risk to decide which we can change the whether that risk is becoming outcome more or less probable and Risk Management involves: Risk whether the effect of the risk Identification, Risk Analysis, Risk have changed Planning and Risk Monitoring © 20042006 SEOC Lecture Note 07 13Software Risks Boehm’s Top Ten Risk Items (1991) Somerville (2004) 1. Personnel shortfalls 1. Staff turnover 2. Unrealistic schedules and budgets 2. Management change 3. Developing the wrong software 3. Hardware unavailability functions 4. Requirements change 4. Developing the wrong user 5. Specification delays interface 6. Size underestimate 5. Gold plating 7. CASE tool underperformance 6. Continuing stream of requirements 8. Technology change changes 9. Product competition 7. Shortfalls in externally performed tasks 8. Shortfalls in externally furnished components 9. Realtime performance shortfalls 10. Straining computer science capabilities © 20042006 SEOC Lecture Note 07 14ƒƒƒƒ Risk Management Process Sommerville, 2004 Risk identification: identifies project, product and business risks Risk analysis: assesses the likelihood and consequences of these risks Risk planning: draws up plans to avoid or minimise the effects of the risk Risk monitoring: monitors the risks throughout the project © 20042006 SEOC Lecture Note 07 15ƒƒ ƒƒ Project Organization Team members are organized Comparison of Organizational in ways that enhance the Structures: • Highly or Loosely Structured completion of quality • High Certainty of products Uncertainty The choice of an appropriate • Repetition or New structure for your project techniques (or Technology) depends on several things • Large or Small Projects • The backgrounds and work Examples of Organizations styles of the team members • Functional • The number of people on the • Matrix team • Integrated Product • The management styles of Development Teams the customers and (IPDTs) developers © 20042006 SEOC Lecture Note 07 16ƒƒƒƒ Project Organization: Functional Basic hierarchical organization Project organized by disciplines and functions Characteristics: Narrow set of work methods, deep technical expertise, Develops skills and morale; Serviceoriented, Communication responsibility on group manager Problems: Elitism within expertise areas, Communication difficult, no project “ownership” Project Organization Requirements Software Testing Customer Specification Design Quality Assurance Support © 20042006 SEOC Lecture Note 07 17ƒ ƒƒƒƒ Project Organization: Matrix Problems: Staff attention Based on a specific project; fractured Conflicting obligations Experts are borrowed, but not Large amount of communication removed Strong top management Strong Matrix: team leader is involvement; Reporting to home the principal authority, Control “base” is difficult of schedule and budget, Acquire personnel, Perform reviews Weak Matrix: team leader is Project only a coordinator, Spokesperson Organization to higher management, Steering committee has ultimate Dept. A Dept. B Dept. C authority Requirements Software Coding Testing Characteristics: Specialists work Specification Design on parttime basis for several Project projects, Top management selects Manager project manager and staff Good for shortlived projects “Task force” Mentality © 20042006 SEOC Lecture Note 07 18ƒƒ ƒƒ Project Organization: IPDT Single, longterm Characteristics: Tightly project; Organized by controlled effort, component Complex or large project, Independent Combining individuals authority for sub from different managers, Direct functional groups into an contact with customer, interdisciplinary work Reporting is easy unit Problems: Loss of System Architecture project – what to do Project Manager with staff, Difficult to enforce standards, Subsystem A Subsystem B Overspecialization Project Manager Project Manager © 20042006 SEOC Lecture Note 07 19ƒƒ Reading/Activity Chapter 8 (Software Engineering Management) and 9 (Software Engineering Process) of the SWEBOK References on Project Management © 20042006 SEOC Lecture Note 07 20