Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 14: Project Management Outline Work breakdown structure What is it? Building a work breakdown structure Project scheduling Dependency diagrams Estimating task durations Project organization Types of organizations Communications infrastructure Software Project Management Plan (SPMP) Overview of project control activities Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 Work Breakdown Structure The hierarchical representation of all the tasks in a project is called the work breakdown structure (WBS). First Version of a UML Model Wo rk B reak down Str uctu re Ta sk * But Tasks are Parts of Activities. What would be a better model? Wo rk B reak down Str uctu re * Wo rk Ta sk Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java * Ac tivi ty 8 Tasks Smallest unit of management accountability Atomic unit of planning and tracking Tasks have finite duration, need resources, produce tangible result (documents, code) Specification of a task: Work package Name, description of work to be done Preconditions for starting, duration, required resources Work product to be produced, acceptance criteria for it Risk involved Completion criteria Includes the acceptance criteria for the work products (deliverables) produced by the task. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Activities Major unit of work Culminates in major project milestone: Internal checkpoint should not be externally visible Scheduled event used to measure progress Milestone often produces project baselines: Activitites may be grouped into larger activities: Establishes hierarchical structure for project (phase, step, ...) Allows separation of concerns Precedence relations often exist among activities formally reviewed work product under change control (change requires formal procedures) Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Creating Work Breakdown Structures Two major philosophies Activity-oriented decomposition (“Functional decomposition”) Write the book Get it reviewed Do the suggested changes Get it published Result-oriented (“Object-oriented decomposition”) Chapter 1 Chapter 2 Chapter 3 Which one is best for managing? Depends on project type: Development of a prototype Development of a product Project team consist of many unexperienced beginners Project team has many experienced developers Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Developing Work Breakdown Structures There are several different approaches to develop and display a work breakdown structure. Each is effective under different circumstances Approaches to break activities into detail by Product component approach Examples: Design documents, manuals, the running system Functional approach Analysis, design, implementation, integration, testing, delivery, reviews Geographical area Examples: USA team, China team, India team, ... Organizational approach Research, product development, marketing, sales Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 When to use what approach Distributed teams: Geographical area approach Experienced teams: Product component approach Project has mostly beginners or project manager is inexperienced: Functional approach Project is a continuation of previously successful projects, no change in requirements, no new technology Organizational approach When you choose an approach, stick with it to prevent possible overlap in categories Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 How do you develop a good WBS? Top down approach: Start at the highest, top level activities and systematically develop increasing levels of detail for all activities. Brainstorming: Generate all activities you can think of that will have to be done and then group them into categories. Which one you use depends on how familiar you and your team are with the project, whether similar projects have successfully been performed in the past, and how many new methods and technologies will be used. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 The Top Down WBS approach Specify all activities required for the entire project to be finished Determine all task required to complete each activity If necessary specify subactivities required to complete each task Continue in this way until you have adequately detailed your project. Approach is good if You are or your team is familiar with the problem. You have successfully managed a similar project in the past You are not introducing new methodologies, methods or tools Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 Top-down example: Architecture-centric approach Work with architect to come up with a tentative top-level design (software architecture) at the beginning of the project and use this decomposition to determine the work breakdown structure. Top-level decomposition can be functional or object-oriented. This approach is a deviation from traditional practices and may be feasible in certain domains with emerging standard architectures. This architecture is used strictly for decomposing the project tasks. Architecture must be revisited during system design after requirements analysis. Project tasks may also be reorganized to reflect the changed architecture. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 The Brainstorming WBS approach On a single list, write any activities you think will have to be performed for your project. Brainstorming means you Don’t worry about overlap or level of detail Don’t discuss activity wordings or other details Don’t make any judgements Write everything down Then study the list and group activities into a few major categories with common characteristics. If appropriate group activities under a smaller number of tasks Consider each category you have created and use the top-down WBS approach to determine any additional activities you may have overlooked. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 Displaying Work Breakdown Structures Three different formats are usually used Organization-chart format: Effectively portrays an overview of your project and the hierarchical relationships of different activities and tasks. Outline format Subactivities and tasks are indented Bubble format The bubble in the center represents your project Lines from the center bubble lead to activities Lines from activities lead to tasks Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 19 Prepare Report Prepare Report Prepare Draft Report Review Draft Report Org-Chart Format Write Final Report Prepare Final Report Print Final Report 1.0 Prepare draft report 2.0 Review draft report 3.0 Prepare final report 3.1 Write final report 3.2 Print final report Outline Format Review Final Report Review Draft Report Prepare Report Bubble Format Review Draft Report Modified from Bruegge & Dutoit’s originals Write Final Report Object-Oriented Software Engineering: Using UML, Patterns, and Java Print Final Report 20 Best format for displaying WBS? Org-chart format: Often good for a “bird view” of the project (executive summaries,...) Less effective for displaying large numbers of activities Outline format: Easier to read and understand if WBS contains many activities Bubble format: Effective for supporting the brainstorming process Not so good for displaying work breakdown structures to audiences who are not familiar with the project. Use bubble format to develop the WBS, then turn it into Org-Chart or outline format. In large projects: Use a combination of org-chart and outline formats: Display activities in org-chart format, Display subactivities and tasks in outline format. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 21 Heuristics for developing high quality WBS Involve the people who will be doing the work in the development of the WBS In particular involve the developers Review and include information from work breakdown structures that were developed for similar projects Use a project template if possible Use more than one WBS approach Do project component and functional approach simultaneously This allows you often to identify overlooked activities Make assumptions regarding uncertain activities Identify risky activities These are often the activities that whose times are hard to estimate Keep your current work breakdown structure current Update your WBS regularly Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 22 Heuristic: Use Templates Try to derive the WBS from a template, either an existing one or one that you start developing with this project. A template reflects the cumulative experience gained from doing numerous projects of a particular type. Using templates can save you time and improve your accuracy When developing templates, develop them for frequently performed tasks (reviews, meetings, …). “Checklists” Develop and modify your WBS templates from previous projects that worked, not from plans that looked good. Use templates as starting points, not as ending points Continually update your templates to reflect the experience gained from performing different projects. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 23 Heuristic: Develop always more than one WBS Consider to create more several different hierarchies with different categories for your work breakdown structure. Having two or more different perspectives helps you identify activities you may overlook. Good starting point are the following hierarchies: Entity-oriented decomposition Activity-oriented decomposition Example: You are running your first object-oriented project. Develop a WBS based on the project documents Develop a WBS based on the software process activities Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 24 WBS Based on Project Documents (Entity-oriented) <<Name>> Project Problem Statement - Write Introduction - Write Requirements - Write Constraints - ... Modified from Bruegge & Dutoit’s originals Project Agreement - Write Requirements - Write Constraints - Write Acceptance Criteria - Promise delivery date RAD - Write Introduction - Describe Functional Model - Describe Object Model - Describe Dynamic Model ... Object-Oriented Software Engineering: Using UML, Patterns, and Java SDD - Write Design Goals - Write Hardware Software mapping -Write boundary conditions - Write Data Manageme - Write Open Issues ... 25 WBS Based on Software Process (Activity-oriented) <<Name>> Project Project Initiation - Establish guidelines - Formulate requirements with client - Establish scenarios - Write project agreement Planning - Determine WBS - Determine dependencies between tasks - Write SPMP - Assign teams to subsystems - Establish project calendar Analysis - Brainstorm on application domain objects - Develop class diagram - Partition objects into boundary, entity and control objects - Develop use cases Design - Develop Models - Write code - Present problems to coach - Give status reports - Write RAD - Write SDD - Write ODD Question: Which activities mentioned in the WBS based on Project documents is left out in the WBS based on Software Process? Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 26 Heuristic: Identifying Risky activities When you identify activities for a work breakdown structure, you can also identify the risks in your project. Risks are usually associated with “unknown information”. Unknown information comes in two flavors A known unknown: Information that you don’t have but someone else does. Find out who has the information and determine what the information is. (Interviews, Phone calls, tasks analysis) An unknown unknown: Information that you don’t have because it does not yet exist. Develop contingency plans for each of these risks. These contingency plans need be followed when you find out the information does not exist. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 27 Choose a single WBS format Writing the WBS in different formats is good, because it allows you to identify activities that you may have overlooked However, after you identify these activities add them to either WBS Choose a single WBS format to be used in the SPMP and for your project: Nothing confuses people fast than trying to use two different work breakdown structures to describe the same project. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 30 How Detailed should the WBS be? Sometimes the activities are not clear at all, especially in software projects: Unclear requirements and/or changing requirements Dependency on technology enablers that appear or are promised to appear after project kickoff Simultaneous development of hardware and software (“concurrent engineering”) A project plan, especially for an innovative software project, should not address details beyond 3 months. Even for the first 3 months project activities might not all be detailable, for example when the requirements are unclear or change or introduction of technology enablers is expected. How should we describe a WBS for a longer project? Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 31 Doing a WBS for Long-Term Projects When developing a work breakdown structure for a long-term project (longer than 3 months), introduce at least two phases Phase 1 (3 months): Plan your WBS in detail Here list all activities that take two weeks or less to complete Phase 2, Phase 3, … (n-months) Plan the WBS for these phases in less and less detail Here list activities that you estimate will take between one and two months At the end of phase 1, revise the phase 2 activities to the two week level for the next 3 months. Modify any future activities as necessary based on the results of your first three months work. Continue to revise the SPMP this way throughout the project. (SPMP as an “evolving” document) Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 32 Outline Work breakdown structure What is it? Building a work breakdown structure Project scheduling Dependency diagrams Estimating task durations Project organization Types of organizations Communications infrastructure Software Project Management Plan (SPMP) Overview of project control activities Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 33 From the WBS to the Dependency Diagram The work breakdown structure does not show any temporal dependence among the activities/tasks Can we excavate before getting the permit? How much time does the whole project need if I know the individual times? What can be done in parallel? Are there any critical actitivites, that can slow down the project significantly? Temporal dependencies are shown in the dependency diagram Nodes are activities Lines represent temporal dependencies Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 34 Dependency Diagrams (Overview) Dependency diagrams consist of 3 elements Event (also called milestone): A significant occurrence in the life of a project. Activity: Work required to move from one event to the next. Span time ( also called duration or elapsed time): The actual calendar time required to complete an activity. Span time parameters: people’s availability, parallelizability of the activity, availability of nonpersonnel resources, …. Dependency Diagram are drawn as a connected graph of nodes and arrows. 2 commonly used diagram notations to display dependency diagrams: 1) Activity-on-the-arrow (Mealy automaton) 2) Activity-in-the-node (Moore automaton) Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 35 Why Dependency Diagrams? Example: You are assigned a project consisting of 10 activities which take one week each to be completed. How long does the project take? When projects have more than 15-20 activities, one cannot to compute the schedule in the head any more. Dependency Diagrams are a formal notation to help in the construction and analysis of complex schedules Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 36 1) Activity-on-the-arrow Diagram Notation Activity A Event (Milestone or Deliverable) RAD B t Event (Milestone or Deliverable) Span Time System Design SDD T1 = 4 weeks Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 37 PERT PERT is an activity-on-the-arrow notation PERT = Program Evaluation and Review Technique Developed in the 50s to plan the Polaris weapon system in the USA. PERT allows to assign optimistic, pessimistic and most likely estimates for the span times of each activity. You can then compute the probability to determine the likelihood that overall project duration will fall within specified limits. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 38 2) Activity-in-the-node Diagram Notation Activity A Node is either an event or an activity. Distinction: Events have span time 0 A tA = 0 B tB = 0 C tC = 0 Event (Milestone or Deliverable) Event (Milestone or Deliverable) Milestone boxes are often highlighted by double-lines RAD available t=0 Modified from Bruegge & Dutoit’s originals System Design t = 2 weeks Object-Oriented Software Engineering: Using UML, Patterns, and Java SDD available t=0 39 Example of an Activity-in -the -Node Diagram Activity 1 Activity 2 t1 = 5 t2 = 1 Start t=0 End t=0 Activity 3 t3 = 1 Modified from Bruegge & Dutoit’s originals Activity 4 Activity5 t4 = 3 5= 2 Object-Oriented Software Engineering: Using UML, Patterns, and Java 40 What do we do with these diagrams? Compute the project duration Determine activities that are critical to ensure a timely delivery Analyse the diagrams to find ways to shorten the project duration To find ways to do activities in parallel 2 techniques are used Forward pass (determine critical paths) Backward pass (determine slack time) Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 41 Definitions: Critical Path and Slack Time Critical path: A sequence of activities that take the longest time to complete The length of the critical path(s) defines how long your project will take to complete. Noncritical path: A sequence of activities that you can delay and still finish the project in the shortest time possible. Slack time: The maximum amount of time that you can delay an activity and still finish your project in the shortest time possible. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 42 Example of a critical path Activity 1 Activity 2 t1 = 5 t2 = 1 Start t=0 End t=0 Activity 3 t3 = 1 Activity 4 Activity5 t4 = 3 t55 = 2 Critical path in bold face Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 43 Definitions: Start and Finish Dates Earliest start date: The earliest date you can start an activity Earliest finish date: The earliest date you can finish an activity Latest start date: The latest date you can start an activity and still finish the project in the shortest time. Latest finish date: The latest date you can finish an activity and still finish the project in the shortest time. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 44 2 Ways to Analyze Dependency Diagrams Forward pass: Goal is the determination of critical paths Compute earliest start and finish dates for each activity Start at the beginning of the project and determine how fast you can complete the activites along each path until you reach the final project milestone. Backward pass: Goal the determination of slack times Compute latest start and finish dates activity Start at the end of your project, figure out for each activity how late it can be started so that you still finish the project at the earliest possible date. To compute start and finish times, we apply 2 rules Rule 1: After a node is finished, we can proceed to the next node(s) that is reachable via a transition from the current node. Rule 2: To start a node all nodes must be complete from which transitions to that node are possible. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 45 Forward Path Example Activity 1 Activity 2 t1 = 5 t2 = 1 Start t=0 End t=0 Project Duration = 7 Activity 3 tA3 = 1 Activity A1 A2 A3 A4 A5 Earliest Start(ES) Start of week 1 Start of week 6 Start of week 1 Start of week 2 Start of week 6 Modified from Bruegge & Dutoit’s originals Activity 4 Activity5 tA4 = 3 t5 = 2 Earliest Finish(EF) End of week 5 End of week 6 End of week 1 End of week 4 End of week 7 Object-Oriented Software Engineering: Using UML, Patterns, and Java 46 Backward Path Example Activity 1 Activity 2 t1 = 5 t2 = 1 Start t=0 End t=0 Project Duration = 7 Activity 3 tA3 = 1 Activity A1 A2 A3 A4 A5 Latest Start(LS) Start of week 1 Start of week 7 Start of week 2 Start of week 3 Start of week 6 Modified from Bruegge & Dutoit’s originals Activity 4 Activity5 tA4 = 3 t5 = 2 Latest Finish(LF) End of week 5 End of week 7 End of week 2 End of week 5 End of week 7 Object-Oriented Software Engineering: Using UML, Patterns, and Java 47 Computation of slack times Slack time ST of an activity A: STA = LSA - ESA Subtract the earliest start date from the latest start date for each activity Example: STA4 = 3 - 2 = 1 Slack times on the same path influence each other. Example: When Activity 3 is delayed by one week, activity 4 slack time becomes zero weeks. Activity 1 Activity A1 A2 A3 A4 A5 Slack time 0 1 1 1 0 Modified from Bruegge & Dutoit’s originals Activity 2 Activity 2 tt2 = 1 2= 1 t1 = 5 Start t=0 End t=0 Activity 3 Activity 4 Activity5 tA = 1 tA4 = 3 t5 = 2 Object-Oriented Software Engineering: Using UML, Patterns, and Java 48 Path types in dependency graphs Critical path: Any path in a dependency diagram, in which all activities have zero slack time. Noncritical path: Any path with at least one activity that has a nonzero slack time. Overcritical path: A path with at least one activity that has a negative slack time. Overcritical paths should be considered as serious warnings: Your plan contains unreal time estimates Any dependency diagram with no fixed intermediate milestones has at least one critical path. A project schedule with fixed intermediate milestones might have no critical path Example: The analysis review must be done 1 month after project start, the estimated time for all activities before the review is 3 weeks. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 49 Frequently used formats for dependency graphs Milestone View (“Key-Events report”): A table that lists milestones and the dates on which you plan to reach them. Activities View: A table that lists the activities and the dates on which you plan to start and end them Gantt chart View: A graphical illustrating on a timeline when each activity will start, be performed and end. Combined Gantt Chart and Milestone View: The Gantt Chart contains activities as well as milestones. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 50 Key-Events Report (example) Date August 26 October 16 October 26 November 7 November 20 Nov 26 Dec 11 Milestone Project Kickoff (with Client) Analysis Review System Design Review Internal Object Design Review Project Review (with Client) Internal Project Review Acceptance Test (with Client) Good for introduction of SPMP and high executive briefings Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 51 Activities View Date Jul 17-Aug 23 Aug 26 - Sep 24 Sep 11-Oct 8 Oct 9 - Oct 26 Oct 28-Nov 7 Nov 8 - Nov 20 Nov 22 - Dec 4 Dec 4 - Dec 10 Dec 11- Dec 18 Project Phases Preplanning Phase Project Planning Requirements Analysis System Design Object Design Implementation & Unit Testing System Integration Testing System Testing Post-Mortem Phase Good during developer meetings Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 52 Gantt Chart Activity 1 Activity 2 Activity 3 Activity 4 Activity 5 0 Easy to read Modified from Bruegge & Dutoit’s originals 1 2 3 4 5 6 7 Time (in weeks after start) Object-Oriented Software Engineering: Using UML, Patterns, and Java 53 Gantt Chart with milestones Project Start Activity 1 Activity 2 Activity 3 Design Review Activity 4 Activity 5 Project Finish 0 1 Good for reviews. Modified from Bruegge & Dutoit’s originals 2 3 4 5 6 7 Time (in weeks after start) Object-Oriented Software Engineering: Using UML, Patterns, and Java 54 Two Types of Gantt Charts Person-Centered View To determine people‘s load Joe A1 A2 Activity-Centered View To identify teams working together on the same tasks A3 A1 Joe, Toby Mary Toby A1 Clara A3 A3 A2 Joe A3 Clara, Toby, Joe Time Time Choose one view, stay with it. Usually base the view on the WBS structure Managing Experienced Teams: Person-centered view Managing Beginners: Activity oriented view Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 55 Tools support for Establishing Schedules Tool support for Graphical user interface for entering activity data Automatic computation of critical paths Multiple views (PERT, Gantt, table views) and switching between these views Many products available. Examples Fast Track (http://www.aecsoft.com) Main view: Gantt Charts Microsoft Project PERT Charts, Gantt Charts, combined Milestone/Gantt Charts Tool use and training beyond the scope of this class Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 56 How to develop an Initial Project Schedule Identify all your activities (reuse a template if possible) Identify intermediate and final dates that must be met Assign milestones to these dates Identify all activities and milestones outside your project that may affect your project’s schedule Identify “depends on” relationships between all these identified activities Draw a dependency diagram for all identified activities and relationships Analyze the diagram to determine critical paths and slack times of noncritical paths. Example: Establish a schedule for system integration testing Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 58 Determining Task Sizes Finding the appropriate task size is problematic Todo lists from previous projects During initial planning a task is necessarily large You may not know how to decompose the problem into tasks at first Each software development activitity identifies more tasks and modifies existing ones Modified from Bruegge & Dutoit’s originals Tasks must be decomposed into sizes that allow monitoring Work package usually corresponds to well defined work assignment for one worker for a week or a month. Depends on nature of work and how well task is understood. Object-Oriented Software Engineering: Using UML, Patterns, and Java 68 How to reduce the planned project time Recheck the original span time estimates Ask other experts to check the estimates Has the development environment changed? (batch vs interactive systems, desktop vs laptop development) Hire more experienced personnel to perform the activities Trade-off: Experts work fast, but cost more Consider different strategies to perform the activities Consider to Buy a work product instead of building it (Trade-off: Buy-vs-build) Consider extern subcontractor instead of performing the work work internally Try to find parallelizable activites on the critical path Continue coding while waiting for the results of a review Risky activity, portions of the work may have to be redone. Develop an entirely new strategy to solve the problem Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 69 Typical Mistakes when Developing Schedules The “Backing in” Mistake Using Fudge Factors Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 70 The “Backing in” Mistake Definition “Backing In”: You start at the last milestone of the project and work your way back toward the starting milestone, while estimating durations that will add up to the amount of the available time Problems with Backing in: You probably miss activities because your focus is on meeting the time constraints rather than identifying the required work Your span time estimates are based on what you allow activites to take, not what they actually require The order in which you propose activities may not be the most effective one. Instead, start with computing all the required times and then try to shorten the project duration Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 71 Using Fudge Factors Parkinson formulated this law for project completion: Work tends to expand to fill the time allotted for it. Fudge factor: A fudge factor is the extra amount of time you add to your best estimate of span time “just to be safe”. Example: Many software companies double their span time estimates. Don’t use fudge factors because of Parkinson’s law. If an activity takes 2 weeks, but you add a 50% fudge factor, chances are almost zero that it will be done in less then 3 weeks. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 72 Heuristics for dealing with time 1. First Set the Project Start Time => Determines the planned project time Determine the critical path(s) 2. Then try to reduce the planned project time If you want to get your project done in less time, you need to consider ways to shorten the aggregate time it takes to complete the critical path. Avoid fudge factors Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 73 Outline Work breakdown structure What is it? Building a work breakdown structure Project scheduling Dependency diagrams Estimating task durations Project organization Types of organizations Communications infrastructure Software Project Management Plan (SPMP) Overview of project control activities Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 75 Organization Definition Organization: A set of organizational units and their different relationships with each other. Organizational units can be organized according to many different categories, for example by function or by project type. Typical examples of organizational units: Functional organization: Research, Development, Marketing, Sales Project organization: Project 1, Project 2, …. A organization usually has 3 different types of relationships between organizational units. Reporting structure: To report status information Decision structure: To propagating decisions Communication structure: To exchange of information Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 76 Functional Organization Definition: In a functional organization participants are grouped into so-called departments, each of which addresses a function. Examples of departments: Traditional businesses: Research, development, production, sales, finance. In software companies the departments correspond to the activities in the software process: Analysis, design, integration, testing departments. Key properties: Projects are usually pipelined through the departments of a functional organization. The project starts in research, then it moves to development, then it moves to production, …. Only a few participants are involved in the complete project. Separate departments often address the same cross-functional needs (Examples: configuration management, IT infrastructure) Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 78 Properties of Functional Organizations Advantages: Members of a department have a good understanding of the functional area they support. Departments don‘t compete with another to get the support of their support teams Disadvantages: Because each department has its own support team, different work procedures and reporting systems are the rule. It is difficult to make major investments in equipment and facilities. Example: Two departments with a budget of 50,000 Euro each need a printer that costs 100,000 Euro. Both need only 50% of the maximum capacity. Neither department can buy it, because they don‘t have sufficient funds. High chance for overlap or duplication of work among departments Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 80 Project Organization In a project organization participants are grouped into projects, each of which has a problem to be solved within time and budget. Key properties: Teams are assembled for a project as it is created. Each project has a project leader. All participants are involved in the complete project. Teams are disassembled when the project terminates Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 81 Properties of Project Organizations Advantages Very responsive to new project requests (because the project is newly established and can be tailored around the problem) New people can be hired/selected who are very familiar with the problem or who have special capabilities. There is no waste of staff workload Disadvantages: Teams cannot be assembled rapidly. Often it is difficult to manage the staffing/hiring process. Because there are “no predefined lines”, roles and responsibilities need to be defined at the beginning of the project Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 82 Matrix Organization In a matrix organization, participants from different departments of the functional organizastion are assigned to work on projects as they are created. The project manager and team members may be assigned to the project for <= 100 % of their time Executive Office Finance Project A Production Sales Marketing Participants of Project A Project B Project C Modified from Bruegge & Dutoit’s originals Participants of Project B Object-Oriented Software Engineering: Using UML, Patterns, and Java 83 Properties of Matrix Organizations Advantages: Teams for projects can be assembled rapidly Scarce expertise can be applied to different projects as needed Consistent work and reporting procedures can be used for projects of the same type. Disadvantages: Team members usually are not familiar with each Team member have different working styles Team members must get used to each other Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 84 New Challenges in Matrix Organizations Team members must respond to two different bosses with different focus: Focus of the functional manager: Assignments to different projects, performance appraisal Focus of the project manager: Work assignments, project team support Team members working on multiple projects have competing demands for their time Team members working on more than one project have even more project members to report to Some people who have claim on the team member’s time may be at similar levels in the organization’s hierarchy Multiple work procedures and reporting systems are used by different team members Development of common procedures needs to be addressed at project kickoff time Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 85 When to use a Functional Organization Projects with high degree of certainty, stability, uniformity and repetition. Requires little communication Role definitions are clear When? The more people on the project, the more need for a formal structure Customer might insist that the test team be independent from the design team Project manager insists on a previously successful structure Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 86 When to Use a Project or Matrix Organization Project with degree of uncertainty Open communication needed among members Roles are defined on project basis When? Requirements change during development New technology develops during project Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 87 Metamodel for Organizations Functional Organization Project Organization Matrix Organization Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 88 Key Roles in Organizations Project Manager: The person ultimately responsible for the successful completion of the project Project Team Member: Participants who are responsible for performing individual activities and tasks (in a project or matrix organization) Functional Manager: The team member‘s supervisor in the department (in a functional organization) Upper management: People in charge of the departments or projects In the following we focus only on roles in project and matrix organizations Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 89 Relationships between Roles Organizations can have many different types of associations between roles The three most important associations for project organizations are: Reporting, decision making and communicating Reporting association: Used for reporting status information Decision association Used for propagating decisions Communication association Used for exchanging information needed for decisions (e.g., requirements, design models, issues). Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 90 Hierarchical Organization Often also called centralized organization. Examples: Military, church, traditional businesses. Key property: The organization has a tree structure. Decisions are made at the root and communicated to the leaf nodes. The decision association is also used for reporting and communication. Advantages: Centralized control over project selection One set of management and reporting procedures for all project participants across all projects Established working relationships among people Clearly established lines of authority to set priorities and resolved conflicts Authority to pressure people to honor their action items Clearly defined career path Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 93 Hierarchical Project Organization Information Flow Chief Executive Control Flow First Level Manager (“Front-Line Manager”) A B Project Members A wants to talk to B: Complicated Information Flow B wants to make sure A does a certain change: Complicated Controlflow Basis of organization: Complicated information and control flow across hierarchical boundaries Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 94 Disadvantages of Hierarchical Organizations Slow response time The process of evaluating and approving change requests often takes too long because of long reporting/decision lines. Difficult to manage the workload of the people: People are assigned fulltime to the organization, but projects don’t’ come in a smooth stream. Project request might not require the people who are available or their expertise. Unfamiliarity with application or solution domain area People are usually hired for their technical proficiency in a specialty that the organization normally performs. They often have only limited experience, if the problem to be solved is outside of their field of expertise. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 96 Nonhierarchical Organizations Key property: The organization has a general graph structure with different edges for the decision, reporting and communication flows. Decisions can be made at various nodes in the graph. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 97 Nonhierarchical Project Organization Project Leader Coaches Subsystem Team A Subsystem Team Subsystem Team B Team Members A wants to talk to B: Communication Flow B wants to make sure A does a certain change: Decision Flow Basis of organization: Nonlinear information flow across dynamically formed units Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 98 Observations on Organizational Structures Hierarchical structure “Reports”, “Decides” and “Communicates-With” all mapped on the same association Does not work well with iterative and incremental software development process Manager is not necessarily always right Project-based structures “Reports”, “Decides” and “Communicates-With”are different associations Cuts down on bureaucracy Reduces development time Decisions are expected to be made at each level Hard to manage Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 100 Heuristics for Project Managers 1. Create team identity Clarify team vision and working relationships Define team procedures (meeting management, configuration management, system integration strategy) Clarify each participant‘s authority Make sure your team is functioning Be sure only one person is assigned as project manager 2. Create team member buy-in Get commitment to the project goals (tough in matrix environment) Get to know other people‘s style 3. Get support from the environment Get a project champion (for example a power promoter) 4. Develop general procedures for Conflict resolution Communication between teams and project leaders, communication with upper management and for communication with the client Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 101 Outline Work breakdown structure What is it? Building a work breakdown structure Project scheduling Dependency diagrams Estimating task durations Project organization Types of organizations Communications infrastructure Software Project Management Plan (SPMP) Overview of project control activities Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 102 IEEE Std 1058: Standard for Software Project Management Plans (SPMP) What it does: Specifies the format and contents of software project management plans. It provides a standard set of abstractions for a project manager or a whole organization to build its set of practices and procedures for developing software project management plans Abstractions: Project, Function, Activities, Tasks What it does not do: It does not specify the procedures or techniques to be used in the development of the plan It does not provide examples . Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 103 Software Project Management Plan Template 0. Front Matter 1. Introduction 2. Project Organization 3. Managerial Process 4. Technical Process 5. Work Elements, Schedule, Budget Optional Inclusions Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 104 Outline Work breakdown structure What is it? Building a work breakdown structure Project scheduling Dependency diagrams Estimating task durations Project organization Types of organizations Communications infrastructure Software Project Management Plan (SPMP) Overview of project control activities Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 105 Project Control Project management does not end with the creation of the project plan. Project management is responsible for project control during the steady state phase of the project. Project control activities Project tracking Development teams are kept accountable for executing their assigned tasks according to plan. The plan must be evolved as new tasks are uncovered or estimated tasks durations are corrected. Risk monitoring Contingency plans are drawn up as risks become serious threats to the successful completion of the project. Examples include: shifting priorities, reorganizing teams, redefining the problem statement, modifying the project schedule, etc. Quality control Software quality metrics are tracked to ensure that defects are being found. Configuration management Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 106 Identifying When a Project Goes Off-Track Determine what went wrong: Why is your project got off track? Behind schedule Overspending of resource budgets Not producing the desired deliverables Identify the Reason(s): You are new on the job, this is your first project, and you made mistakes Key people left the teams or new ones are joining it Key people lost interest or new ones entered the picture The requirements have changed New technology has emerged The business objectives have changed Organizational priorities have shifted (for example after a merger) Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 107 Heuristics to get a project back on track Reaffirm your plan Refocus team direction and commitment Reaffirm your key people Reaffirm your project objectives Reaffirm the activities remaining to be done Reaffirm roles and responsibilities Revise estimates, develop a viable schedule Modify your personnel assignments Hold a midproject kickoff session Closely monitor and control performance for the remainder of the project Get practical experience Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 108 Summary Software engineering is a problem solving activity Must develop quality software for a complex problem within a limited time while things are changing We need system models (object models, dynamic models, etc.) and management models (WBS, dependency diagrams, issue models, etc.) WBS: Set of activities to do (“use cases”) Dependency diagram: identify dependency relationships between activities Schedule: Dependency diagram with estimates of task durations Development teams may be organized by function or by project Communication infrastructure is also needed for reporting, decision propagation, and exchanging information Project control is the project management role during the steady state portion of the software project. Modified from Bruegge & Dutoit’s originals Object-Oriented Software Engineering: Using UML, Patterns, and Java 109