Project Management
To frame our discussion, consider:
How do we organize a project to manage the people, process, problem and product?
What are the strengths and weaknesses of the team organization methods?
What tasks define the skills needed by software developers?
| Factors to Consider |
|---|
| Product Factors | Expectations on the System |
| Problem Factors | Novelty and complexity of the Problem |
| Process Factors | Tools, Organization, Management |
| People Factors | People interacting successfully with the software we build.
People interacting successfully to build the software. |
"The central question in how to improve the software art
centers, as it always has, on people."
(Brooks, 1987)
"Personnel attributes and human resource activities provide by
far the largest source of opportunity for improving software
development productivity." (Boehm, 1981)
Knowledge is the raw material of software development. Software
engineers transform knowledge into software products. The level of talent on a software project is often the strongest predictor of its results, and personnel shortfalls are one of the
most severe project risks.
"However, there is much dissatisfaction with the preparation and viewpoints that graduates bring to industry. Employers indicate that new graduates do no lack technical skills and scientific preparation. Rather, they lack people and process skills. New hires do not know how to communicate effectively, they have insufficient experience and preparation for working as part of a team, they lack the ability to manage their individual work efficiently and productively, and they do not understand or appreciate organizational structures or business practices." (Hilburn, 1997)
What Developers Do
Bell Labs Distribution of Developer Time by Task
| Writing Programs | 13% |
| Reading Programs and Manuals | 16% |
| Job Communications | 32% |
| Personal | 13% |
| Misc. | 15% |
| Training | 6% |
| Mail | 5% |
Distribution of Developer Time by Task
IBM Distribution of Developer Effort by Type
Team Organization
- Democratic Decentralized
Consists of task coordinators appointed for short duration. Decisions on problems and approaches are made by group consensus.
| PROS: | 1) team members contribution to project decisions |
| 2) learning from each other |
| 3) increased job satisfaction |
| CONS: | 1) communication overhead to reach decisions |
| 2) requires team work well together |
| 3) weakening of individual responsibility and authority |
Useful in long-term research and development projects where a variety of opinions or views is preferred. Team structure encourages brainstorming and consideration of alternative solutions.
- Controlled Decentralized
Team has a defined leader who coordinates specific tasks and secondary leaders responsible for those tasks. Problem solving remains a group activity, but implementation is allocated to subgroups. Communication between subgroups and individuals is horizontal.
- Controlled Centralized
Top-level problem solving and team coordination are the responsibility of a team leader. Communication tends to be vertical. Chief Programmer Team (IBM mid-70s)
The nucleus of the team is a senior engineer, the chief programmer. The chief programmer plans, coordinates, and reviews all technical activities. The senior programmer has two to five staff for support. These staff would include other programmers, technical writers, and a software librarian. The librarian serves many teams and maintains the software configuration, assists in research and document preparation.
| PROS: | 1) centralized decision making |
| 2) reduced communication overhead |
|
| CONS: | 1) sensitive to the nature of the chief programmer |
| 2) low morale |
|
Useful in settings where training of lower level personal is needed, or for sensitive applications packages.
Comparison of Team Structures
| Factor | Chief Programmer | Egoless |
| Difficulty of Problem | simple | complex |
| Size of Program | large | small |
| Creativity Required | Low | High |
| Reliability Requirement | low | high |
| Modularity Requirements | high | low |
| Schedule | tight | relaxed |
| Duration of Project | Short | long |
| Team Morale | low | high |
| Risk Taking | low | high |
Principles for Team Organization
Use fewer, and better, people
Try to fit tasks to the capabilities and motivation of the people available
In the long run, an organization is better off if it helps people to get the most out of themselves
It is wise to select people such that a balanced and harmonious team results
Someone who does not fit the team, should be removed
Brooks' Law
Adding manpower to a late software project makes it later. (Brooks, 1995)
PCMM
Estimates of product size and cost are required early in the activity prior to the availability of sufficient information. The software scope is defined to establish the context of the problem, the information objectives, and a high level view of the functions and performance.
| Difficulty |
|---|
| Characteristic | Low | Moderate | High |
|---|
| Number of Functions Performed | Small | Medium | Large |
| Novelty of Function | Standard | Similar to existing | New theory or Approach |
| Number of users requiring access or concurrent access | 1 | several | many |
| Multi-tasking | no | some | yes |
| Interactive vs. batch | batch or minimal interaction | highly interactive | highly interactive |
| Response-time | Off-line; non-critical | Interactive; moderate response time | real-time |
| Need for distributed processing | none | 2 computers | 3 or more computers |
| Amount of Data Stored | will fit on single disk | requires 2 or more disks | requires system to manage disk access |
| Structure of data | Simple data relationships | Moderately complex relationships | Highly complex relationships |
| Accuracy of Data | Low | Moderate | High |
| Transaction Size | Small | Medium | Large |
| Remote vs. local | Local Only | Remote | Remote |
| Criticality | Can tolerate several hours downtime | Can tolerate short periods of downtime | Can tolerate no downtime |
| Security | none | moderate | high |
| Interaction with Other systems | None | Some, but well-defined | Much; possible parallel development |
| Number of Phases of Development | none | few | many |
| Need for Manual Override | no | no | yes |
| Dependence On Hardware | Independent | Some | Tied to specific Hardware constraints |
| Stability of Specification | Fixed | Some changes | Frequent changes |
| User Sophistication | Familiarity with systems | some familiarity | naive |
| Developer Sophistication | Has developed similar systems with similar tools | Experience with tools, none with application | no experience |
Pfleeger, p. 29.
Go To Lecture
[Outline] [Overview]
Go To
[Course Outline]
Boehm, B. (1981) Software Engineering Economics. Englewood
Cliffs, NJ: Prentice-Hall. 1981.
Brooks, F. P., Jr. (1987) No silver bullet; essence and accidents of
software engineering. IEEE Computer 20, 4 (April 1987):
10-19.
Brooks, F. P., Jr. (1995) The Mythical Man-Month. Reading, MA: Addison-Wesley.
Curtis, B., W. E. Hefley, & S. Miller (1995) People Capability Maturity Model. CMU/SEI-95-MM-02
Hilburn, T. (November/December 1997) Software Engineering Education: A Modest Proposal. IEEE Software 14(6), p. 44-48.
Pfleeger, S. (1987) Software Engineering. New York: Macmillan.