1. 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.

2. 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 needed 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

3. 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 needed 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

4. 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

5. Project planning is essential to SE efforts.

6. Formalize Software Requirements It is unreasonable to expect a Software Engineer to estimate the amount of work required to build “something” before that “something” has been defined. Adapted from Code Complete

7. How can the size of a project be estimated? l Use scheduling software l Use an algorithmic approach such as COCOMO l Hire an expert to do the estimation l Use previous project experience as a guideline Adapted from Code Complete

8. How can the size of a project be estimated? l Have team members carefully discuss the schedule l Estimate project pieces and add the parts together l Estimate the time available for the entire project and divide it among the parts l Estimate, see what actually happens and adjust Adapted from Code Complete

9. 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)

10. Estimate pieces of the project and add the parts together!

11. Project Time In Work Hours Actual Time Required Project Estimation Project Progress in Milestones 1 2 3 4 5 6 7 Adapted from Code Complete

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

13. 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

14. SE involves significant time pressure.

15. 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!

16. WHY is there TIME pressure? In most cases: l Projects are planned and scheduled in a haphazardly. l Risks, if at all, are considered as they happen ! – Crisis Management l People aren't organized effectively!

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

18. Two views to scheduling a project: 1) An end date is set in advance and cannot be changed (Management decision) 2) Schedule is roughly set by the primary players

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

20. 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?

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

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

23. 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?

24. Most likely outcome -- 10 dead cats 10 injured cats 1 escaped mouse

25. Why is this true?

26. 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.

27. 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

28. Why does a project fall behind? What kinds of things influence a project’s schedule?

29. Influences on Schedule l Team motivation l Management quality l Amount of code reuse l Personnel Turnover l Requirements volatility Adapted from Code Complete

30. Influences on Schedule l Quality of relationship with customer l User participation in requirements l Classified security environment l Amount of documentation l Experiences-level of Team Adapted from Code Complete

31. Factors that Influence Software Project Effort l Reliability required l Database size l Project complexity l Execution time required l Volatility of Operating System l Turnaround time on development computer l Analyst team capability l Team’s experience in application area Adapted from Code Complete

32. Factors that Influence Software Project Effort l Programmer team capability l Programmers’ experience with underlying hardware and software l Team’s programming language experience l Use of modern programming practices l Use of software tools l Required development schedule Adapted from Code Complete

33. Effort should be 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%

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

35. 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.

36. 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.

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