Figure 1. Average Software Development Productivity Growth in the Aerospace Industry from 1960 to 1995.
By focusing on the people-management facet of software development, appreciable gains in quality and productivity can result. This article discusses how to enhance communication effectiveness through motivation, the physical software development environment, and the team concept.
Introduction
Software development contains three important elements: people, process, and product. The people element has largely been ignored in the quest for productivity and quality improvement. Process and product represent the technology elements of development.
The aerospace industry has searched for a software technology over the last 25 years that would dramatically improve productivity and reduce cost and schedule. Each new technology improved software quality and the development process. Major product cost improvements such as high-level languages and object-oriented methods resulted from technologies that produced program size reductions. None of these technologies have produced the anticipated efficiencies or productivity gains measured in source lines per person month.
Software development productivity, measured from start of development through software-system integration, has grown almost linearly from 1960 through the present. Figure 1 shows a simplified (smoothed) productivity growth curve for that period. The result, smoothed or not, illustrates the growth of software development productivity is less than one source line per person-month per year over the entire 30-year period. This growth is disappointing when the languages, systems, and development environments of 1995 are compared to those available in 1960.
Figure 1. Average Software Development Productivity Growth
in the Aerospace Industry from 1960 to 1995.
Technology penetration accounts for part of the poor productivity improvement. Recent Software Engineering Institute Capability Maturity Model (SEI CMM) rating information [1] shows 75 percent of the assessment sites are operating at maturity Level 1, 16 percent at Level 2, and only 8 percent at Level 3 or better. Other industry studies show the use of structured programming is less than 20 percent, structured analysis is less than 1 percent, and object-oriented methods are less than 0.1 percent of the software industry. These findings suggest a possible inherent organizational resistance to change.
Software development is the most communication intensive of all engineering processes. This unique software process characteristic suggests significant productivity gains are more likely to be realized through communication improvement rather than through technology. Communication effectiveness is a people issue controlled by organization structure, management approach, and the development environment.
Software Management
Project management is the American software industry's major challenge. This bold statement is based on over 20 years of software research, data collection, process modeling, analysis, and development estimation. Yet, in retrospect, the statement is not surprising.
Chuck Tonies defined an effectiveness formula [2] in Software
Engineering that describes the net effect of an individual's
effort in a software development environment. The effectiveness
expression
E = C[M(CS)] where
E = net individual effectiveness
C = communication skills (0-1)
M = management concept awareness (0-1)
CS = computer science technical ability (0-1)
By combining individual contributions, the effectiveness of a
software development organization is driven by three major skill
factors: communication, management, and technical. Management
theory suggests the parallel view of project management shown in
Figure 2. The Tonies factors and the project management model
facets cover the same skills sorted into a different grouping.
The product of the Tonies factors equals the management facet
total.
Figure 2. Three Major Facets of Project Management.
The product facet historically was the principal project management focus until the early 1960s. As products became larger, their sheer size forced the software industry to look for improved tools, methods, and processes to reduce development problems and development cost to acceptable levels. Third-generation programming languages were the first successful improvements. Structured techniques, such as structured programming and analysis, dominated improvement efforts from the mid-1960s through the mid-1980s.
Each new tool or method appeared with a claim that productivity would improve an order of magnitude, and errors would essentially disappear. Although structured techniques were valuable, their claims placed them among the first "silver bullets." Formal processes were introduced in the early 1970s to organize large projects and ease the accompanying management stress. New silver bullets were always available with similar expectations and generally similar results. The most recent improvements include Ada, "object-oriented methods," and the SEI CMM. Ada data over the last decade indicates the source code cost per line is essentially unchanged from historical FORTRAN and COBOL costs. A rocket scientist is not required to determine that productivity can increase no more than 20 percent if code production is eliminated from the development activity. SEI CMM rating data from the last decade matches improvements predicted by the Constructive Cost Model (COCOMO) and SAGE software estimation tools.
All software development improvements to date, e.g., languages, methods, tools, and process, are associated with the process and product facets of the project management model. No published improvements relate to the people facet.
The people facet is the most important of the three management facets in terms of productivity and quality gains and represents the bulk of the communications and management Tonies factors. There are no technology factors that can significantly impact the people facet. Barry W. Boehm suggested in his widely used text Software Engineering Economics that "Poor management can increase software costs more rapidly than any other factor. Each of the following mismanagement actions has often been responsible for doubling software development costs. ..." [3]
Boehm's list of management problems describes the common software management style for that time--a style that is prevalent today. Boehm continues, "Despite this cost variation, COCOMO does not include a factor for management quality, but instead provides estimates that assume the project will be well managed." [Emphasis is mine.]. Gerald M. Weinberg [4] extends this discussion by grouping Boehm's cost impacts to illustrate the relative importance of each group. Figure 3 presents Weinberg's results, emphasizing the importance of management in projecting software costs.
Figure 3. Relative impact of COCOMO Software Cost Driver
Groups.
Weinberg also compares the relative cost impacts with the SEI-sponsored research over the first five years of the institute's existence. Figure 4 relates the payoff percentage in the four categories to the percentage of papers published by SEI.
Figure 4. Software Engineering Institute-Sponsored Research
vs. Relative Payoff by Group.
Modern management concepts are the cornerstone for articulating management practice in both technology and manufacturing industry sectors. These concepts are consistent with good software development and with the communication-intensive software process. The high correlation between productivity and team performance in software development underscores the importance of management effectiveness.
Major software development activities are closely related to thinking and communicating, as suggested by Tonies. Software development is the most communication centered of all creative engineering activities. Quality and productivity gains cannot be achieved without focusing on improvements that enhance communication effectiveness and efficiency. These improvements fall into three overlapping but distinct areas:
Discussion of these areas is simpler if presented in reverse order.
Motivation
Motivation is one of the most effective and important tasks that face any manager. This task becomes critical in managing a creative, communication-centered activity such as software development. Management style must be considered before the other improvement areas since it is the basis for both team concepts and working environment. Management styles vary across the spectrum from the traditional Theory X to the modern Theory Y approach. Theory X assumes that most people prefer to be directed, are not interested in assuming responsibility, and want safety (job security) above all. This theory assumes people are motivated by money, fringe benefits, and most of all, the threat of punishment. Theory X managers manage by control (as directors), closely supervise their employees, and are devoted to structure in both organization and process. Those who search for tools and methods to solve the productivity and quality problems are inherently traditional Theory X personalities. Theory X also underlies the concept that people are interchangeable if the development process is defined and stable.
Human behavior according to Theory Y is quite unlike Theory X behavior. Theory Y assumes people are not, by nature, lazy and unreliable. It asserts people can be self-directing and creative if properly motivated. Thus, the task of management is to unleash this potential in workers. Properly motivated people can achieve their own goals best by directing their efforts toward organizational goals. Theory Y people are motivated at the self-actualization, social, and esteem levels rather than the physiological and safety levels as assumed in Theory X. Theory Y is the basis for continuous process improvement. If the workers have little process ownership, the process is unlikely to change. Theory Y managers tend to be supportive and facilitating (leaders).
The importance of motivation in the development organization is much greater than the space devoted to it here. It is a topic worth additional study by those searching for major gains in quality and productivity.
Environment
The physical software development environment has a great impact on both productivity and quality. Although space does not allow a thorough treatise on facilities planning, a few rules that cover the most important issues are outlined. One consistent observation gleaned from successful software projects is that of a "war room." The ideal physical development environment appears to be a dedicated open area that supports communication. On the surface, the area is similar to a bullpen with some subtle differences that become apparent when considering the following rules of software environments. The ideal physical software development environment requirements are summarized as follows:
Thou shalt dedicate the project area. Team members will essentially "live" in this area (war room) for the project duration. They have no need for other offices since they have no other duties or assignments. Commitment to the project increases in direct proportion to the isolation provided by the environment. The war room should be large enough to support the project but no larger. There is an unwritten law that states communication quality and quantity decrease rapidly when the distance between team members increases beyond 50 feet.
Thou shalt not construct communications barriers. Walls, partitions, or barriers of any kind are the nemesis of teamwork. Many studies describe the grave decrease in communications that occurs when walls of any kind are constructed within the work area. The walls can be plaster, cardboard, or even several feet of pure air. Team-member segregation in any form degrades communications and morale. The infamous cubicle that improves organization overhead cost in terms of programmers per square foot is one of the greatest detriments to communications, productivity, and quality in today's environments. In spite of this profound negative impact, cubicles are standard in the vast majority of traditional development facilities.
Thou shalt provide utensils for creative work. The war room must be supplied with the software development tools and systems required to develop the software product effectively and efficiently. These required tools also include whiteboards, corkboards, tables, and chairs for small group discussions that can be freely arranged by the team as their immediate needs dictate.
Thou shalt not share resources. The war room, or development area, and its resources must not be shared with other projects or activities. The sharing restriction doubly applies to development personnel. Part-time people equate to part-time commitment. Part-time commitment leads to team failure.
Thou shalt not interfere with the project's space. Facilities management is usually performed by an organization outside the project domain. The physical environment should be largely under project control--a tough hurdle to clear. The effort necessary to accomplish this culture shift is high, but the benefit of putting the project staff in this type of environment far outweighs the expense. At least, that is the result in every team-oriented project researched.
Teams
The software development scenario almost always includes the following three steps:
1. The development begins with great expectations. Extra analysts and programmers are added to the project early to reduce schedule risk.
2. The project falls behind schedule and misses major milestones. Organization and customer pressure the project manager to increase staff to regain lost schedule in spite of projected cost increases. The actual schedule continues to deteriorate at an accelerated rate. Repeat Step 2.
3. The project schedule is beyond hope. The project is in danger of being canceled. The development organization's reputation and future are at stake. The organization forms a "tiger team" to complete development and deliver the software product.
Why does the development organization ignore the tiger team at the start of the project? Why do organizations repeat this three-step process for each new project? Why do these organizations persist in using management approaches they have personally demonstrated to be ineffective? Culture is hard to change.
The development team is a critical ingredient in successful software development. The use of motivated teams accounts for almost all high-productivity gains observed over the past two decades. A manager simply cannot assign programmers to a project, give the group a unique name, i.e. "The Great Ones", and expect them to work miracles. Four major conditions must be met for a team to rise above mediocrity. First, the development team must contain working representatives from each area involved in the development and use of the product; for example, design, programming, test, integration, user, and quality assurance. Second, the team must be co-located. The ideal team environment is described in the preceding section. Third, the key team members including design, programming, and test must be full-time team members from the start of development until the project is complete. Part-time team members are not and will not become dedicated, committed team members.
The rewards must go to the team as a unit for "team performance." This fourth point is the hardest to implement because it appears to be un-American. We learn in school to be entrepreneurs, to succeed as individuals, or to be "Lone Rangers." However, team success depends on working together. Rewarding individual performance is the proverbial "kiss of death" in a team environment. Tom DeMarco [5] suggests the team should be replaced by a "choir" concept. DeMarco states, "An individual can only succeed to the extent that the whole prospers. And the whole can only prosper to the extent that everyone does well." The quality management writings of W. E. Deming [6] and Tom Peters [7] reinforce the team considerations listed here.
There are two basic team concepts that offer valuable insights into the software management problem. The first team concept is a simple two-person team functioning as a unit with one problem to solve and figuratively using only one pencil. The second concept, the cross-functional team, is synonymous with the generalized team we have discussed to this point.
Two-Person Team. The two-person (2P) team implements the adage "Two heads are better than one." When this concept was first implemented in 1975, there was great concern the productivity gain could never offset the additional resource expense. The two-person approach places two engineers or two programmers in the same location (office, cubicle, etc.) with one workstation and one problem to solve. The team is not allowed to divide the task but produces the design, code, and documentation as if the team was a single individual. The 1975 team's project was a real-time, multitasking system executive of approximately 30,000 FORTRAN source lines. The development team had five 2P teams and a progressive Theory Y type project leader. The traditional development environment, outside the 2P team organization, was typical of most environments. The architecture design was completed in a war room environment. The project architecture divided the development into six independent tasks, with the two smallest tasks assigned to one team. The 2P teams returned to the war room environment during system integration. The team concept appears to have been violated when the project was divided among five independent teams working in their own small war rooms (two-person offices). There were two organizational issues working here:
Final project results were astounding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm prior to the project. This result is especially striking when we consider two persons produced each line of source code. The error rate through software-system integration was three orders of magnitude lower than the organization's norm. Was the project a fluke? No. Why were the results so impressive? A brief list of observed phenomena includes focused energy, brainstorming, problem solving, continuous design and code walk-throughs, mentoring, and motivation.
The cross-functional team development approach corresponds to the dictionary's team definition. Almost every large-scale development reverts to a variation of this approach at some point in the project. The team approach described above is essentially the cross-functional team. Cross-functional teams are known by several names. Tiger teams and "skunk works" are only two examples of the team approach known as the cross-functional team. Rather than iterate the description to the extreme, results of a significant cross-functional team study completed in 1990 are shown. The software project was another real-time system consisting of approximately 57,000 Ada source lines. The system contained only one component. The development team was experienced in the application area and was composed of experienced JOVIAL programmers starting their first Ada project plus one Ada expert. The development environment was a textbook war room. The project manager, or team leader, was instrumental in creating the environment for this experimental project. The development team's productivity data was unavailable; however, the organization's historical productivity was near 80 lppm for both FORTRAN and JOVIAL projects.
The productivity improvement calculated at the end of the development was 218 lppm, or 172 percent better than the organization average. The most significant project feature was a basic technology constant [8] (Ctb) of 8,635 achieved during the development. This Ctb value is the current highest measured value.
Project Management Effects Model
It is difficult to create the identical project conditions required to demonstrate the relative productivity achievable through the use of modern management techniques. SAGE is the only validated software cost and schedule estimating model available today that incorporates management effects in its input parameters. This model can be used to realistically demonstrate the relative productivity gain under controlled development environment and management conditions.
The hypothetical project presented in this demonstration is a 50,000 source line mission planning system to be developed in a third-generation language. The development contractor is experienced in the application area, the programming language, and the development system and tools. The first analysis assumes a traditional management approach in a physical environment based on a standard cubicle configuration. The conditions described in the analysis input data are typical software development conditions. The traditional results presented in Figure 5 indicate a productivity value near average for 1995. The second analysis replaces that standard cubicle environment with a war room facility and a development team relatively new to modern team approaches. The manager is also new to team management. The modern results in Figure 5 show a 194.5 person month development cost that is only 37 percent of the traditional cost. The modern 257 lppm productivity figure represents a 171 percent gain over the traditional approach. Both calculations are consistent with historical project data.
| Mission Planning Management Impact | |||
|---|---|---|---|
| Management Style | Traditional | Modern | Units |
| Develop Effort | 527.0 | 194.5 | Person-Months |
| Develop Schedule | 25.2 | 18.1 | Months |
| Productivity | 94.9 | 257.0 | lppm |
Figure 5. SAGE Mission Planning Project Analysis Comparing
Traditional and Modern Management Methods.
Summary and Conclusions
The case studies described above are real projects developed in real environments under typical time and schedule constraints. Each study was the first application of modern management techniques to software development. The results indicate the modern management approach learning curve is small or negligible.
This presentation demonstrates a consistent characteristic productivity found in software projects developed with team organizations and nontraditional management styles. The presentation does not attempt to prove a relationship between people and productivity in a software development activity. A "proof," or validation in software estimation terms, can only be accomplished through repeated, successful correlation between predicted and actual software project data.
Some organizations transition from traditional to modern management without any serious problems; others fail miserably. The difference between success and failure appears to be commitment. Making the transition is similar to jumping the Grand Canyon. The transition is simple if the organization is committed to the transition and believes the change is possible. A lack of belief or commitment to the new approach will ensure the project will fail. Uncertainty can certainly be sensed by the development team. The team knows if the organization is dedicated to the change. If not, the team won't make the change either. The choice is yours. Culture is hard to change.
About the Author
Dr. Randall W. Jensen is an international authority and consultant in software engineering and project resource management. He is president of Software Engineering, Inc., a consulting firm that specializes in both training and application aspects of software project management and real-time system development. He developed the SAGE software schedule and cost estimation system and the model underlying the SEER-SEM (System Evaluation and Estimation of Resources Software - Software Estimation Model) system. He retired as chief scientist of the Software Engineering Division of Hughes Aircraft Company's Ground Systems Group where he implemented software management and cost and schedule prediction methods and developed real-time system analysis and design techniques for embedded software systems.
Jensen received the International Society of Parametric Analysts Freiman Award for Outstanding Contributions to Parametric Estimating in 1984. He has taught electrical engineering and computer science at Utah State University where he was awarded the Institute of Electrical and Electronics Engineers Outstanding Professor Award and the Sigma Tau Outstanding Professor Award for the College of Engineering.
Jensen has published several textbooks including Software Engineering and numerous software and hardware analysis papers. He is currently writing Quantitative Methods in Software Management. He is editor of the Prentice-Hall Software Engineering Series.
Jensen holds a bachelor's, a master's, and a doctorate in electrical engineering from Utah State University.
Randall W. Jensen, Ph.D., President
Software Engineering, Inc.
660 North Highland Blvd.
Brigham City, UT 84302-1631
Voice: 801-734-2585
Fax: 801-734-2586
E-mail:73157.2023@compuserve.com
References
1. Mattingly, J. Lewis and S. Boycan, " Air Force Software Process Improvement," Crosstalk, STSC, Hill Air Force Base, Utah, February 1995, pp. 6-9, 28.
2. Jensen, Randall W. and C. C. Tonies, Software Engineering, Englewood Cliffs, N.J., Prentice-Hall, Inc., 1979, pp. 8-9.
3. Boehm, Barry W., Software Engineering Economics, Englewood Cliffs, N.J., Prentice-Hall, Inc., 1981, pp. 486-87.
4. Weinberg, Gerald M., Quality Software Management, Vol. 3, Congruent Action, New York, N.Y., Dorset House Publishing, 1994, pp. 15-16.
5. DeMarco, Tom, "The Choir and the Team," The Dorset House Quarterly, Nov. 4, 1995, p. 4.
6. Walton, M., The Deming Management Method, New York, N.Y., Putnam Publishing Group, 1986.
7. Peters, Tom, Thriving on Chaos, New York, N.Y., Harper & Row, 1987.
8. Jensen, Randall W., "An Improved Macrolevel Software Development Resource Estimation Model," Proceedings of the Fifth International Society of Parametric Analysts Conference, St. Louis, Mo. April 26-28, 1983.
Quantitative Software Management -
Software Cost and Schedule Estimation
The Software Technology Support Center is offering a five-day workshop on software development cost and schedule estimation. The intensive workshop, provided on a fee-for-service basis to Department of Defense agencies and their supporting contractors, is designed to: Introduce and compare the major estimating tools and proven estimating techniques applicable in the DoD environment; provide practical software estimating experience through team participation in predicting cost and schedule; explain commercial-off-the-shelf and existing software impacts on modified system effective size, and provide realistic methods of determining effective modification size; provide workshop experience in software development schedule and cost prediction and control, including early recognition of potential problems and corrective measures; explain project management and development environment effects on software development productivity and product quality; and discuss estimating techniques for multiple concurrent development tasks that provide minimum schedule and resource requirements.
The workshop is built around practical, realistic case studies to provide maximum exposure to real-world estimating problems and scenarios. The workshop case studies provide participants with hands-on experience in all aspects of developing realistic software estimates. This approach also instills an excellent understanding of parametric estimating and the impact of management.
The training material is derived from contributions of leaders in the software economics and metrics field, including that of the workshop leader. The quantitative measures utilized in the workshop material have been validated through decades of practice. The workshop is performed at your location and can be scheduled as needed depending on instructor availability.
At the conclusion of the workshop, participants will be able to: perform realistic software development cost, schedule and resource estimates with a variety of estimating tools on multiple concurrent development tasks; understand the capabilities and limitations of the major estimating tools in the DoD environment; and understand the meanings of the major estimating tool parameters required for a realistic estimate.
Who is the audience? Acquisition and development managers, estimators, customers, and personnel who are ultimately involved in the software development activity will benefit by attending and participating. To schedule a workshop, or to receive more information, contact Alan Giles at 801-775-5555 ext. 3031.