CSE403 Software Engineering Autumn 2000 Project Management - PowerPoint PPT Presentation

About This Presentation

CSE403 Software Engineering Autumn 2000 Project Management


CSE403 Software Engineering Autumn 2000 Project Management Gary Kimura Lecture #10 October 16, 2000 – PowerPoint PPT presentation

Number of Views:77
Avg rating:3.0/5.0
Slides: 23
Provided by: coursesCs71


Transcript and Presenter's Notes

Title: CSE403 Software Engineering Autumn 2000 Project Management

CSE403 Software Engineering Autumn 2000Project
  • Gary Kimura
  • Lecture 10
  • October 16, 2000

  • Understand that there are different approaches to
    project management for software
  • And what several of those are
  • Offer alternative and guidelines for your class
  • Youve seem to be doing pretty good for the first
    three weeks
  • Is this because I pre-suggested a team
    organization or because youre all great
    organizers by nature?
  • Managing schedules

Project management
  • What percentage of the effort to date has been
    spent writing code?
  • What percentage has been spend working through
    requirements and design?
  • What percentage has been spend in meetings?
  • When does the real coding start?

Problems with managing projects include
  • Figuring out and coordinating schedules
  • Handling communication among the team
  • The figure shows a rough notion of the cost of
    team communication
  • The theory is that about 25 of each group's
    effort is spent in communication, with this cost
    applying recursively
  • As Brooks observes, the worst case of this is
    adding people to a late project, which tends to
    make it even later
  • Making decisions
  • Recording decisions
  • Managing egos
  • What else?

Team structure
  • Brooks talks about the desire everyone has for a
    small, sharp team
  • 10 or fewer people
  • All of them brilliant
  • All of them focused on the task at hand
  • But he observes that this is too slow a way to
    build a really big system
  • And rightly so

Why? Time
  • Brooks take a 10 person team composed of people
    all 7x better than the worst
  • 5x to 25x are within known ranges
  • Assume OS/360 was built by the worst
  • Assume a small team has a 7x communication
  • Assume no turnover of the team
  • Assume 5000 person-years for OS/360
  • ? 10 actual years for the task
  • Now, do the same estimates for NT 5.0 with
    60,000,000 lines of code!

Chief Programmer Team
  • An alternative idea is to restructure a classic
    big team to get the benefits of the small, sharp
    team (ability and focus) with the benefits of a
    bigger team (overall speed)
  • The key is to design the positions on the team
    very carefully

  • Most of these specific (lower-level) job
    descriptions are clearly out of date
  • a team will rarely need its own machine and
    operating system crew
  • All computer input goes to the clerk, who logs
    and keys it
  • But the idea of focusing on how to break up the
    team into well-defined jobs is, of course, still
    extremely pertinent

Chief Programmer Team
  • An underlying theme of this approach is that a
    smart person understands the domain and defines
    an appropriate architecture
  • Then the subpieces are spawned off to people who
    are talented programmers but who have little (or
    less) knowledge about the project
  • In practice I wonder if this works very well at
  • Need commitment and buy-in from all parties
  • Need to build team synergy

Aside outsourcing
  • Over the past years, there has been an increased
    interested in outsourcing significant pieces of
    software projects
  • In particular, the interest has been to use
    cheaper labor in places like India, China,
    Ireland, etc.
  • There is a big political issue related to this,
    which is the question of granting H1-B visas to
    people from other countries to work in high-tech
    in the U.S.
  • This in many ways resembles aspects of the chief
    programmer team Give them the spec and let
    them code!

More on outsourcing
  • A serious problem with the outsourcing version of
    coding is the increased distance between the
    programmers and the people who own the
  • Communication is almost entirely by email, travel
    is costly and time consuming, etc.
  • I believe this leads to less and less effective
    communication, significantly increasing risks

Team structures Ive been involved in
  • DECwest Compiler team
  • About 6 people
  • One language architect and manager
  • Two senior developers
  • Three junior developers
  • Documentation and testing?
  • Overall NT team at Microsoft
  • When it began in 1988
  • When NT first shipped in 1993
  • When I left in 2000
  • The NT file system team
  • In its most productive phase there were 4
    developers, twice as many testers, and everyone
    eating dogfood.
  • Later it had over 20 developers (not by choice)

Some Microsoft job titles
  • Program Manager
  • Maintaining the big picture. Weighing risks
    against costs. Understanding many disciplines.
    Keeping a variety of specialists on the same
    page. Sewing all the components of a project
    together to make world-class software projects
    happen on time, on budget.
  • Software Design Engineer
  • Working with other product team members from the
    beginning of the product cycle through release,
    our SDEs design and implement sophisticated
    products ...
  • SDE in Test
  • Deeply involved in every phase of the product
    cycle, our SDEs in Test devise and implement test
    plans and strategies. It's a specialized skill
    that requires the ability to effectively
    second-guess our other developers.
  • Software Test Engineer
  • As the strongest advocate our end-users have,
    Microsoft Test Engineers develop and execute test
    plans and scripts designed to detect problems and
    ensure the quality ...

Last years team structure
  • Fairly non-hierarchical team structure
  • Small teams (5 students)
  • Nobody was really the boss
  • Everyone can communicate with each other
  • Would not scale well to larger teams (even at 10
    people it falls apart)

This years team structure
  • Hierarchical divided up into specific areas
  • One assigned manager (coordinator) for the whole
  • Each sub-team works quasi independently of the
    other teams
  • But communication and buy-in by everyone is still
    a must
  • A way to make decisions needs to be agreed upon
  • A very common problem is to fight for a long time
    over decisions for which either alternative is
    adequate often, making a decision is more
    important than which decision is chosen.
  • Most often a good manager is the decision maker
    if consensus cannot be reached in sufficient time

Decision making
  • Making decisions is something we do all the time
    in a project
  • The biggest risk, in general, is not that we make
    a bad decision
  • It is that we delay making any decision past a
    point of no return
  • You should probably spent relatively little time
    deciding between two pretty strong alternatives
  • This is perhaps especially true in your project,
    given the incredibly compressed schedule

Recording decisions
  • In your meetings you will be making a lot of
  • Some youve probably already made are who will do
    what, what will the requirements be, who will
    write up what, what coding standards (if any)
    will we use, how will we name our variables, etc.
  • You might even still have some major design
    decisions to work through.
  • You cannot record all your decisions in
    writingbut youd better record the key ones!
    Decide where these are recorded and how.
  • How have you been recording and keeping records?

Running meetings
  • Youve already had a few meeting, let me just
    offer a few tips if I can
  • Have an agenda
  • Have a person responsible for keeping the meeting
    on the agenda
  • Have a person record key decisions
  • This person can rotate or can be assigned to
    someone who is good at this by nature
  • Show up to the meetings (uh, and classes)
  • Start them and end them on time
  • It may be that your teams ability to succeed is
    driven as much by things like how your meetings
    run as by how well you cut code

  • The following are two documented/analyzed ways to
    aid in managing projects
  • You may find these artifacts helpful for your
    project management task
  • Some, of course, may appear in your actual
    project, as well
  • As always, (a) use what you want and (b) don't
    over do anything!

The primary example is a Gantt chart to show the
link between tasks and time
  • A Gantt Chart maps tasks to dates
  • There is a row for each task the columns
    represent dates
  • This makes it easy to see the schedule
  • So its often a good way to build an initial
    plan, to view the schedule, and to make
  • Task linking is a constraint that says, Task x
    cannot start until Task y completes
  • I use to use a white board with yellow sticky
    notes for this purpose but also with developers

PERT charts
  • Displays tasks and task dependencies as a network
    diagram or flowchart
  • A node represents each task and a line connecting
    two boxes represents the dependency
  • There are some nice software packages that help
    with, but personally, I cant stand them

Software engineering is not a mere matter of
  • Coming up next
  • Individual project reviews
  • Testing, testing, and more testing
Write a Comment
User Comments (0)
About PowerShow.com