SE is not like other projects'

1
SE is not like other projects.

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

2
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

3
Effort Estimates can include

• estimates of required human effort
• (person-months)
• estimates of project duration
• (calendar time)
•  estimates of the cost of the project
• (in dollars)

4
Estimate pieces of the project and add the
parts together!
5
Project Estimation
Actual Time Required
Project Time In Work Hours
Estimate 1
Estimate 2
Estimate 4
Estimate 3
Estimate 6
Estimate 5
Estimate 7
1 2 3
4 5 6
7
Project Progress in Milestones
Adapted from Code Complete
6
TIME

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

7
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 TIME

8
SE involves significant time pressure.
9
SE involves significant time pressure.

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

10
WHY is there TIME pressure?

• In most cases
• Projects are planned and scheduled in a
  haphazardly.
• Risks, if they are considered at all, are
  considered as they happen! Crisis Management
• People aren't organized effectively!

11
Every software project has a schedule,

• BUT not all schedules are
• created equal--

12
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

13
Problems Poor scheduling Create --

• reduce market impact
• create dissatisfied customers
• raise internal costs by creating additional
  problems during system integration

14
Scheduling Issues What questions should be asked?

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

15
"...if we fall behind schedule we can always add
more programmers and catch up later in the
project."

• Management often believes

16
Adding people to a late project only makes it
later!!!

• WHY???

17
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?

18
Most likely outcome --

• 10 dead cats
• 10 injured cats
• 1 escaped mouse

19
Why is this true?
20
Communication

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

21
Benefits can be gained by

• Using fewer people over a longer period of time
  span
• When more than one person is involved in a SE
  project try to complete tasks in parallel

22
Why does a project fall behind?What kinds of
things influence a projects schedule?
23
Influences on Schedule

• Team motivation
• Management quality
• Amount of code reuse
• Personnel Turnover
• Requirements volatility and evolution
• Adapted from Code Complete

24
Additional Influences on Schedule

• Quality of relationship with customer
• User participation in requirements
• Classified security environment
• Amount of documentation
• Experiences-level of Team
• Adapted from Code Complete

25
Factors that Influence Software Project Effort

• What do we mean by Software Project
  Effort?
• It means how hard is the code to write? the
  softwares complexity

26
Factors that Influence Software Project Effort

• Reliability required
• Database size
• Project complexity
• Execution time required
• Volatility of Operating System
• Turnaround time on development computer
• Analyst team capability
• Teams experience in application area
• Adapted from Code Complete

27
Factors that Influence Software Project Effort

• Programmer team capability
• Programmers experience with underlying hardware
  and software
• Teams programming language experience
• Use of modern programming practices
• Use of software tools
• Required development schedule
• Adapted from Code Complete

28
Effort should be divided as follows

• Project planning 2-3
• Requirements analysis 10-25
• Software design 20-25
• If the above time is spent then
• Coding 15-20
• Testing/debugging could 30-40

29
Project tracking-- How are we doing?

• "Software Projects fall behind schedule one day
  at a time."

30
How do we know if we're on track?

• Conduct periodic project status meetings in which
  each team member reports on progress and
  problems.
• Evaluate the results of all reviews conducted
  throughout the SE process.

31
How do we know if we're on track?

• Determine whether formal project milestones have
  been accomplished by the scheduled date.
• Compare the actual start date to the planned
  start date for each project task.

32
How do we know if we're on track?

• Managers need to meet informally with each team
  member to obtain their "subjective" assessment of
  progress to date and problems they anticipate.