CS 5150 Software Engineering

1
CS 5150 Software Engineering
Lecture 7 Managing Large Projects Guest Lecturer
Stephen Purpura
2
Administration

• Quiz 1
• Quiz 1 has been graded
• Project Announcements
• iPhone Apps for CIT Team please have someone
  from the team see Stephen Purpura after the
  lecture.

3
Why a T-shirt?
Why do software companies make project t-shirts?
4
The T-shirt, Explained
Benefits Short elevator description. Easy
to memorize. Provides a reference point to
resolve disputes. Visibility. Engineers
advertise the goals daily. Rallying point for
all project teams to plug into. Project vision
statements are cliché but important. The t-shirt
is the humanization of a bureaucratic function.
5
A Windows XP Desktop T-Shirt
Windows Focus Group Results7 out of 7 Apple
engineers dont want Windows to Prevent Internet
hackers from stealing my data Support the latest
cool hardware and games Auto-configure network
settingsRun every application Boot faster Or
Ship on Time
6
The Project Manager
Focuses the team. Recommends adjustments
to the interpretations of the vision the
schedule the team composition Facilitates
and communicates to provide visibility. The
project manager needs support from the client,
executive management, the heads of all of the
development teams and the confidence of everyone.
7
Project Manager vs. Program Manager
Project Manager single version focus
Program Manager multiple version focus Program
Managers are frequently leveled by the number
of versions ahead they can visualize. Most
program managers have project management
responsibility.
8
The Schedule

• Now we have a t-shirt. Whats next?
• The schedule is built using milestones, each with
  its own vision statement.
• The beginning is about exploration.
• The middle is about determining scope
  limitations.
• The end is about grinding it out.

9
Milestones
Milestones are in approximately 3 month
increments. Why? Because no one can reliably
estimate the future.
10
Common Mistakes

• Common failures
• Missing tasks (especially cleanup)
• Forgetting to include communication costs
• Missing/unknown customer requirements
• Understanding the release process
• Underestimating testing requirements
• You know youre in trouble when a software
  engineer says The customer wants it this way.

11
Interaction Costs Greater in Large Projects
When the of people on a project is 7, the
number of possible interactions is 21. At 1,000
people, the possibleinterpersonal interactions
increases to 499,500.
n(n-1)
of Possible Personal Interactions
2
12
When do you begin work on the following?

• Legal review
• Documentation
• Support training
• Supply chain training
• Good project/program managers are constantly
  talking to stakeholders and looking to prevent
  schedule holes.

13
Project Teams

• Most schedules are built bottom-up to enable buy
  in. Even with experienced staff, basic mistakes
  are made every day.
• To hedge this eventuality, two strategies are
  employed
• Use a daily routine that encourages catching
  mistakes
• Use a project team with diverse membership and
  focus
• Software engineers, Project Mgrs, Program Mgrs
• Architects, Ux, HCIEs, Testers (SDETs, STEs)
• Docs, Support, Sales, PR

14
Diversity on Project Teams
If youre selling software to Iraqis, it helps to
have an Iraqi on the project team. Diversity
isnt affirmative action or leveling the playing
field. Diversity helps generate better ideas and
perspectives which lead to better results.
15
Finally Estimating the Schedule
Now that weve discussed all of the ways that we
cant estimate the future, why do we build a
schedule? Answer Its a forcing function.
16
Example What does it mean to boot faster?
In the beginning we do a feasibility study The
goal is determine what needs to be done and the
dependencies. We want to boot faster, but we
dont know how. We profile the boot times for
each of the components and build a report. We
experiment and see where we might get traction.
The goal is to produce a report with options for
realizing faster boot and the costs of the
functionality gains.
17
Beginning Schedule Time Constrained
Phase I (Feasibility) May through
December Make a list of the potential
improvements Phase II (Proving) January through
May Phase III (Release Beta 1) May through
December Beta 1 doesnt hit customers for a
year Phase IV (Release Beta 2) January through
March Phase V (Release Candidate 1) March
through June Phase VI (Release Candidate 2)
August Phase VII (Release to Manufacturing) Aug
- Nov
18
Beginning Schedule Risk Constrained
Phase I (Feasibility) May through
December Make a list of the potential
improvements Slipstream a release to
customers Phase II (Proving) January through
May Slipstream a release to customers Phase III
(Release Beta 1) May through December Phase IV
(Release Beta 2) January through March . . . . .
.
19
Getting Traction on booting faster?
In the middle options identified during the
previous phase are built to 80
functionality. They are shipped to customers for
evaluation. The goal is to determine distance
from finished. Example PCI bus scanning and
known unknowns vs. unknown unknowns
20
Updating the Schedule Risk Constrained
Phase II (Proving) January through May This
phase now becomes half about responding to the
release feedback and half about the original
engineering goals. Engineers are segmented
appropriately Features are tossed out if a
viable plan cant be developed to resolve
customer problems. . . .
21
Tying a Team into the Larger Group

• More teams means more communication and
  coordination cost.
• Boot faster conflicts with Auto-configure
  network settings
• Auto-configure network settings conflicts
  with Prevent Internet Hackers from Stealing my
  Data
• Kernel changes and user-mode changes are
  required by all of the project teams. How do you
  handle source code changes?

22
Risk Management

• Practice releasing a quality product every day.
• Build the software
• Test it
• Report the results
• Read the reports
• Act like youre working with a purpose

23
The daily build

• Build the source code from source control every
  day. Then test it. Hold people accountable.
• How?
• Call out people for build failures.
• Call them at home at 3 am.
• Bring them into the office.
• Use a senior engineer as an example to set the
  tone. ?

24
Does the build live up to the t-shirt?
On large projects, there are typically more
testers than developers. Why? Well discuss
this more in my next lecture
25
Dont Underestimate the Value of Fun

• Brian Valentine read the News of the World
• Some managers pull stunts
• The trebuchet battle

26
Putting it All Together
Running a large project is about Focus
Fun Visibility Communication Risk
management
27
A Day in the Life of a Team Project Manager
700 Email/daily prep 800 Review the Daily
Build Report 810 Install the build and
exercise it 830 File bugs 900 Morning
status report 1000 Cross-team coordination
meeting 1 1100 Bug triage 1200 Lunch with
the team 100 Cross-team coordination meeting
2 200 Work (schedule development/spec
writing) 330 Team member visits 500 Update
manager w/visibility
Risk Mgmt
Coordination
Morale
28
The Project Manager

• Is not the Decider.
• A PM on a power trip generates bad results.
• But good PMs make problems disappear
• Persuade management to make critical decisions
• Convince software engineers to avoid escalating