1. CS 360 Lecture 4

2.  The operating system for the IBM 360 was two years late!  Question:  How does a project get two years behind schedule?  Answer:  One day at a time! Fred Brooks Jr., The Mythical Man Month, 1972 2

3.  Project management is concerned with activities that ensure that software is delivered on time and in accordance with the requirements.  Systematic, organized approach to software development.  Project management is needed:  Software development is always subject to budget and schedule constraints. 3

4.  To complete a project:  On time  On budget  With required functionality  To the satisfaction of the client  Without exhausting the team  To provide visibility about the progress of the project. 4

5.  The product is intangible  Software can’t be seen or touched.  Progress is difficult to express by simply looking at the software.  Many software projects are “one-off” projects  New projects usually differ in some way than previous projects.  Even experienced personnel may find it difficult to anticipate problems.  Software processes are variable  Industry leaders still can’t reliably predict when a particular software process is likely to lead to development problems. 5

6.  Clients wish to know:  Will the system do what was promised?  When will it be delivered? If late, how late?  How does the cost compare to the budget?  Often the project is part of a larger activity or system.  If the project is to be deployed as a product, marketing and development must be combined.  If the project has to work with other systems, developments must be coordinated. 6

7.  But:  Every software project is different.  Most systems are not well specified, or the requirements change during development.  Estimating time and effort is full of errors, even when the system is well understood.  Implementing risk management techniques is crucial to increasing project success rate. 7

8.  Staff turnover  Affects project  Management change  Affects project  Hardware unavailability  Affects project  Requirements change  Affects project and product  Task-time underestimate  Project and product  Technology change  Affects business  Product competition  Affects business 8

9.  Should be a team activity  Risk identification  Identify project, product, and business risks  Risk analysis  Assess the likelihood and consequences of these risks  Risk planning  Define plans to avoid or minimise the effects of the risks  Risk monitoring  Define ways to monitor and log risks throughout the project 9

10.  Checklist of common risks:  Technology risks  Database is too slow, software components contain defects  People risks  Difficult to recruit skilled personnel, key staff unavailable at times  Organizational risks  Management personnel change, reduction in project budget  Requirements risks  Changes require major redesign  Estimation risks  Time requirements, defect repair rate underestimated, project size 10

11.  Assess probability and seriousness of each risk  Examples:  Financial problems force reductions in the project budget.  Probability: Low, Effects: Catastrophic  Difficult or impossible to recruit competent personnel.  Probability: High, Effects: Catastrophic  Key staff are unavailable at times.  Probability: Moderate, Effect: Serious  Changes are made to requirements that include major redesign.  Probability: Moderate, Effect: Serious  Software tools can’t be integrated.  Probability: High, Effect: Tolerable  The rate of defect repair is underestimated  Probability: Moderate, Effect: Tolerable 11

12.  Consider each risk and develop a strategy to manage that risk  Organizational financial problems:  Prepare briefing document to show how the project is making very important contributions to the organization and why budget cuts would not be cost-effective.  Staff unavailability:  Reorganize the project team so there is more task overlap.  Component performance:  Research alternative hardware/software components that may increase performance while remaining in the budget. 12

13.  Planning:  Outline schedule during feasibility study (Needed for CS 360).  Fuller schedule for each part of a project.  Each process step, iterations, sprint  Contingency planning:  Anticipation of possible problems.  Risk management  Progress tracking:  Regular comparison of progress against plan.  Regular modification of the plan.  Changes of scope, etc. made jointly by client and developers.  Final analysis  Analysis of project for improvements during next project. 13

14.  Deliverable:  Work product that is provided to the client  Mock-up, demonstration, prototype, report, presentation, documentation, code, etc.  Release of a system or subsystem to client or users  Milestone:  Completion of a specified set of activities  Delivering specified deliverables  Completion of a process step 14

15.  Activity:  Part of a project that takes place over time (also known as a task).  Event:  The end of a group of activities, such as the agreement by all parties on the budget and plan.  Dependency:  An activity that can’t begin until some event is reached.  Resource:  Staff time, equipment, or other limited item required by an activity 15

16.  The scope of the project is defined early in the process.  The development is divided into tasks and milestones.  Estimates are made of the time and resources needed for each task.  The estimates are combined to create a schedule and a plan.  Progress is continually reviewed against the plan, perhaps weekly.  The plan is modified by changes to scope, time, resources, etc. 16

17.  Planning is divided into high level release forecasting and low level detailed planning.  Release planning is a best guess, high level view of what can be achieved during a specific time span.  Release plans are continually modified  Almost daily  Clients and developers take join control of the release plans and choice of sprints.  For each time span, the development team plans on what it can achieve.  The development team may use Gantt charts 17

18.  With experienced staff, estimating the actual time to carry out a single task is usually fairly accurate, but..  The smaller details are underestimated.  The time from “almost done” to “completely done” is much longer than anticipated.  “There’s just one thing that needs finishing..”  “Comments and documentation need refining..”  “I just need to integrate this last feature..”  The distractions are not planned for.  I have a test/homework in another class.  I decided to upgrade the operating system, now nothing works.  I forgot to create system backups  Total hardware/software failure  Some things will have to be done twice, or three times.. 18

19.  The team often has the best understanding of what it can achieve in a single time span, or sprint.  The team commits to the outcome of the sprint.  The team must have an internal schedule to allocate tasks within a sprint. The CS 360 project can be thought of as a single sprint. 19

20.  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.  In CS 360, the start-up time is three to four weeks.  Essentially the same start-up tasks, but applied to a smaller project.  Teams need to learn organizational, communication, and domain related skills.  Teams also need to learn how to apply software engineering concepts to completing the project. 20

21.  Gantt charts, Activity bar charts, etc.  The group should build a work-plan from activity data.  Display the work-plan in graphical or tabular form. 21

22.  A chart that illustrates the start and finish dates of essential tasks needed in a project.  Steps to creating your team’s Gantt chart: 1. List your activities  Make a list of everything you plan to do in the project. This includes all code development and documentation. 2. Estimate the time required  For each item on your list, estimate how long it will take the group to finish that task.  Make realistic assumptions on what the group can accomplish during a given time span. 3. Put activities in order  What will the group do first? Second? …  Activities order may be based on deadlines, outside dependencies, progression of the project, etc. 4. Create task chunks  Chunks, for this project, should be defined in weeks. Chunks can overlap, if the development team is working on tasks in parallel. 5. Draw the chart  Group activities into major headings and sub headings.  Set the time intervals to weeks. 22

23.  Activities/Chunk ordering will be determined by the software process model your development team decides to use.  Microsoft Excel can be used to easily create your group’s Gantt Chart.  As the semester progresses, the Gantt chart may need modifying.  The group should keep all revisions of the Gantt chart in the project documentation. The charts can be named or versioned, v1, v2, etc. 23

24.  A group of scheduling techniques that emphasizes dependencies.  An activity (task)  A dummy activity (dependency)  An event  A milestone 24

25. 25

26. 26

27.  The project group can use an Activity Graph to estimate when tasks can begin, and when tasks should be completed.  The Activity Graph gives the group insight on which tasks can be completed in parallel, and which tasks must be completed sequentially.  The Activity Graph may need updating as the group progresses on the project.  Accommodate for tasks finishing early  Tasks taking longer than expected  New and deleted tasks, etc. 27

28.  Each activity can include resources:  Number of people (2 system architects)  Key personnel (chief designer)  Equipment (3 servers with specified hardware)  facilities (research lab)  Each resource is then labelled with availability:  Training of developers  Equipment availability 28

29.  In CS/SwE, not all people are equal  The best are at least five times more productive.  Some tasks are too difficult for everybody.  Adding more people adds complexity  Some activities need a single mind.  Sometimes, the time needed for an activity can’t be shortened by increasing personnel.  Adding more people may sometimes increase the time to complete a project.  What happens to the project if a key person is sick or quits? 29

30.  Creates and maintains the schedule  Tracks progress against the schedule  Keeps some contingency time in the schedule (to reduce risk)  Assigns himself/herself tasks in other key areas of the project team  Continually makes adjustments:  Start activities before previous activities are complete (parallel tasks if possible)  Sub-contract activities to project group members based on background, skills, etc.  Negotiating deliverables  Keeps client(s) informed of key aspects of the project and project group.  The project manager needs the support of the entire team.  Each project group in CS 360 should designate a project manager.  Any correspondence outside of the weekly meeting times between the client and development team will be through the project manager. 30

31.  Remember, the feasibility report is due on Friday.  The report should be as detailed as possible for how your group plans on developing the project.  Feasibility presentation schedule is posted on the class website.  The presentation should be 10 minutes long.  Make sure to cover relevant material about your group’s project, software process, etc.  Each person should participate in the presentation. 31