1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Chapter 3 Project Management

2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener The Aim of Project Management To complete a project: On time On budget With required functionality To the satisfaction of the client Without exhausting the team

3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener The 4 P’s  People — the most important element of a successful project  Product — the software to be built  Process — the set of framework activities and software engineering tasks to get the job done  Project — all work required to make the product a reality

4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Software Projects size delivery deadline budgets and costs application domain technology to be implemented system constraints user requirements available resources Factors that influence the end result...

5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Project Management Concerns

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener The Project Manager Create and maintain the schedule. Track progress against schedule. Keep some slack in the schedule (minimize risk). Continually make adjustments: Start activities before previous activity complete Sub-contract activities Renegotiate deliverables Keep senior management informed (visibility).

7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Why Projects Fail? an unrealistic deadline is established an unrealistic deadline is established changing customer requirements changing customer requirements an honest underestimate of effort an honest underestimate of effort predictable and/or unpredictable risks predictable and/or unpredictable risks technical difficulties technical difficulties miscommunication among project staff miscommunication among project staff failure in project management failure in project management

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Software Teams  the difficulty of the problem to be solved  the size of the resultant program(s) in lines of code or function points  the time that the team will stay together (team lifetime)  the degree to which the problem can be modularized  the required quality and reliability of the system to be built  the rigidity of the delivery date  the degree of sociability (communication) required for the project The following factors must be considered when selecting a software project team structure...

9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener  closed paradigm—structures a team along a traditional hierarchy of authority (similar to a CC team)  random paradigm—structures a team loosely and depends on individual initiative of the team members  open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm  synchronous paradigm—relies on the natural compartment- alization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves Organizational Paradigms

10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Defining the Problem  establish scope—a narrative that bounds the problem  decomposition—establishes functional partitioning

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Melding Problem and Process

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener To Get to the Essence of a Project  Why is the system being developed?  What will be done? By when?  Who is responsible for a function?  Where are they organizationally located?  How will the job be done technically and managerially?  How much of each resource (e.g., people, software, tools, database) will be needed?

13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Critical Practices  Formal risk analysis  Empirical cost and schedule estimation  Metrics-based project management  Earned value tracking  Defect tracking against quality targets  People aware project management

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Project Planning Methods Critical Path Method, Gantt charts, Activity bar charts, etc. are roughly equivalent. These methods are best when: 1. Model is updated regularly (e.g., monthly) 2. The structure of the project is well understood 3. The time estimates are reliable 4. Activities do not share resources Unfortunately, #2, #3, #4 rarely apply to software development

15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Terminology Deliverable Work product that is provided to the customer (report, presentation, documentation, code, etc.) Activity Part of a project that takes place over time. Event The beginning or end of an activity. Milestone Completion of a specified set of activities (e.g., delivery of a deliverable)

16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Activity Graph An activity A dummy activity An event A milestone

17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Scheduling: Background PERT Program Evaluation and Review Technique introduced by the U.S. Navy in 1957 to support the development of its Polaris submarine missile program. PERT/Time Activity graph with three time estimates (shortest, most probable, longest) on each activity to compute schedules. PERT/Cost Added scheduling of resources (e.g., facilities, skilled people, etc.)

18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Critical Path Method Uses Activity Graph with single time estimate for each activity to estimate, for each event: earliest start date latest start data and for each activity: slack A standard method for managing large construction projects. On big projects, activity graphs with more than 10,000 activities are common.

19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Estimating the Time for an Activity With experienced staff, estimating the actual time to carry out a task is usually fairly accurate, but... The little bits and pieces are underestimated The time from almost "done" to completely "done" is much longer than anticipated. (There's just one thing to tidy up. I need to put the comments into better shape. I really should get rid of that patch.) The distractions are not planned for. (My system crashed and I decided to upgrade the software. My child's school was closed because of snow. I spent the day showing visitors around.) Some things have to be done twice.

20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Start-up Time On a big project, the start-up time is typically three to six months: Personnel have to complete previous projects (fatigue) or be recruited. Hardware and software has to be acquired and installed. Staff have to learn new domain areas and software (slow while learning). Clients may not be ready.

21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Adding Resources to Activity Graph Each activity is labeled with resources, e.g., Number of people (e.g., 2 Java programmers) Key personnel (e.g., chief system architect) Equipment (e.g., 3 servers with specified software) Facilities (e.g., video conference center) Each resource is labeled with availability, e.g., Hiring and training Vacations Equipment availability

22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Using Critical Path Method for Resources Assume every activity begins at earliest start date: In each time period, calculate: resources required resources available Identify shortage / surplus resources Adjust schedule acquire extra staff (e.g., consultants) rearrange schedule (e.g., change vacations) change order of carrying out activities The earlier that a problem is known, the easier it is to fix.

23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Key Personnel In computing, not all people are equal The best are at least 5 times more productive. Some tasks are too difficult for everybody. Adding more people adds communications complexity Some activities need a single mind. Sometimes, the elapsed time for an activity can not be shortened. What happens to the project if a key person is sick or quits?

24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 and revised by Ayse Bener Value of Scheduling Tools Planning discipline Identify all activities and inter-relationship Provide schedule for each resource (identify clashes) Early warning of difficulties (e.g., timing of equipment purchase) Routine updating of schedule Focus on key milestones Visibility for management Weekly staff meeting -- What did we expect to accomplish? What did we accomplish? What is expected for next week?