SE is not like other projects. l The project is intangible. l There is no standardized solution process. l New projects may have little or no relationship to completed projects. l Rapid changes in technology often makes the "experience" learned from other projects non-transferable.

Successful software requires that we understand: l the scope of the work to be done l the risks to be incurred l the resources to be required l the tasks to be accomplished l the milestones to be tracked l the effort (cost) to be expended l the schedule to be followed

In the Beginning Before a project can be planned: 1. Project objectives and project size (scope) must be established. 2. Alternative solutions should be considered. 3. Technical and managerial constraints must be identified.

Project Objectives - identify the overall goals of the project without considering how these goals will be achieved Project Size (Scope) - identifies the primary functions that software is to accomplish

Things that are quantified are more easily understood!

Project planning is essential to SE efforts.

Effort Estimates can include: l estimates of required human effort (person-months) l estimates of project duration (calendar time) l estimates of the cost of the project (in dollars)

TIME is the most valuable commodity available to a software engineer!

IF - enough TIME is available, A problem CAN be properly analyzed, a solution CAN be comprehensively designed, source code CAN be carefully implemented, and the program CAN be thoroughly tested BUT -- there never is enough

SE involves significant time pressure.

l Part of the pressure comes from arbitrary and sometimes unrealistic deadlines established by those who do not have to build the product! l But, Part of the pressure is created by the people involved!

WHY is there TIME pressure? In most cases: l projects are planned and scheduled in a haphazard fashion. l risks are considered only when they appear. l people aren't organized in effective ways.

Every software project has a schedule, BUT not all schedules are created equal--

Questions about the schedule? l Did the schedule evolve on its own or was it planned in advance? l Was the work done "by the seat of our pants?" or was a set of well-defined tasks identified? l Was the deadline imposed by upper management or was it designed by the SE staff?

Two views to scheduling a project: 1) An end date for release of a computer based system has already (and irrevocably) been established. 2) The software scheduling assumes that rough time bounds have been discussed but that the end date is set

Poor scheduling CAN-- l reduce market impact l create dissatisfied customers l raise internal costs by creating additional problems during system integration

Scheduling Issues l How do we balance chronological time with human effort? l What tasks and parallelisms are to be expected? l What milestones can be used to show progress?

"...if we fall behind schedule we can always add more programmers and catch up later in the project." Management often believes:

Adding people to a late project only makes it later!!! WHY???

If 1 cat can catch 1 mouse in 1 hour Then 2 cats might be able to catch 1 mouse in 30 minutes Then Can? 60 cats catch the mouse in 1 minute?

Most likely outcome dead cats 10 injured cats 1 escaped mouse

Why is this true?

Communication l New people have to learn the project form the existing team members. l The time lost in teaching the new people is time away from the project. l The more people in a group, the more complex the communication, the less that gets done in the same amount of time.

Benefits can be gained by: l Using fewer people over a longer period of time span l When more than one person is involved in a SE project try to complete tasks in parallel

Effort is divided as follows: l Project planning = 2-3% l Requirements analysis = 10-25% l Software design = 20-25% If the above time is spent then l Coding = 15-20% l Testing/debugging could = 30-40%

Project tracking-- How are we doing? "Software Projects fall behind schedule one day at a time."

How do we know if we're on track? l Conduct periodic project status meetings in which each team member reports on progress and problems. l Evaluate the results of all reviews conducted throughout the SE process.

How do we know if we're on track? l Determine whether formal project milestones have been accomplished by the scheduled date. l Compare the actual start date to the planned start date for each project task.

How do we know if we're on track? l Meet informally with each team member to obtain their "subjective" assessment of progress to date and problems they anticipate.