Scott Briggs

E mbedded systems are by far the most prevalent of all computer systems used in the world today. More than 99% of all microprocessors sold in 1998 were used in embedded systems. Advances in processor and memory technology and their associated low cost allow them to be considered for an enormous number of applications. This, coupled with the expectations of customers, has led to tremendous growth in the size and sophistication of embedded applications.

Embedded systems share the following characteristics. They generally are developed around custom hardware, require high quality and reliability, and frequently deal with real-time issues. The applications running on these systems are usually very large and complex. Examples of these systems include telecommunication switching systems, aircraft, spacecraft, weapons systems, and the multitude of applications in the car and home.

Several trends are causing the driving factors in embedded systems development to shift from hardware to software. First, processors continue to push the performance envelope, allowing more flexibility in the applications which run on them. Second, functions are being increasingly integrated on the silicon. Functions which in the past required several devices can now be found on a single device. Many development organizations have found that they can simply purchase whole boards from manufacturers, thereby eliminating expensive and very long hardware design cycles. On some projects, software development costs comprise about 90% of the total development costs.

Most software projects fail to meet their schedules. A 1998 survey indicates that only about 24% of all software projects succeeded, up from 9% in 1994. ¹ A 1997 survey indicated that 80% of all embedded software projects fail to come in on time. ²

In this article, I will present a number of techniques designed to improve the success rate of embedded projects. Three primary factors determine the success of a project: schedule, cost, and the quality of the delivered features. The ability of a company to optimize its project's schedule, cost, and quality objectives will give it a significant competitive advantage within its industry.

The development of software is one of the most complex activities ever undertaken. Despite significant advances in the methods and technologies for software development, it remains a people-oriented activity. As such, techniques that leverage the people and the way they develop software are the main factor in determining the success of a project.

I will focus on four areas of impact: people, process, product, and technology. ³ There are leverage points associated with each of these factors that are used to manage the risks to the success of a project.

People
People represent the single largest factor in improving software productivity and quality. Issues include motivation, staffing, and teamwork. Steve McConnell summarizes the research concerning variations in productivity of individuals and teams: ⁴

• Greater than 10-to-1 differences in productivity among individuals with different depths and breadths of experience
• 10-to-1 differences in productivity among individuals with the same levels of experience
• 5-to-1 differences in productivity among groups with different levels of experience
• 2.5-to-1 differences in productivity among groups with similar levels of experience

We must now distinguish between motivation and movement as defined by Herzberg. ⁶ Motivation is a function of growth from getting intrinsic rewards out of interesting work. Movement is a function of fear of punishment or failure to get intrinsic rewards. Movement is the typical procedure used in animal training and its counterpart, behavioral modification techniques for humans. Examples of this abound in software companies as they strive to bring products to market in a competitive environment as quickly as possible. The behaviors that result from motivation and movement appear the same but have different long-term differences. Movement requires constant reinforcement and is focused on short-term results. Once the extrinsic reward disappears, so will the movement. Motivation, on the other hand, is based around personal growth being the ultimate reward. The benefit is long-term with no need of incremental extrinsic rewards.

Herzberg goes on to define the differences in motivating factors and hygiene factors. ⁷ Motivating factors stimulate growth and performance. Examples of these include achievement, recognition, the work itself, responsibility, advancement, and growth. Hygiene factors represent the basic conditions a person needs to do his or her job. These include company policy and administration, supervision, interpersonal relationships, working conditions, salary, and security. The conclusion to draw here is that the motivating factors are primary causes of satisfaction, and hygiene factors, at best, create no dissatisfaction. At worst, hygiene factors can create extreme dissatisfaction.

We can look at the motivating factors for software developers and their managers and come to some conclusions. While the data in Table 1 is a bit dated, it still offers significant insights. It should be clear that developers are motivated by a desire to be challenged and prefer an environment where they can grow in their positions. This represents an opportunity for the organization to allow the developers to stay current with trends in technology and methods. Note that developers are motivated by the work itself. An environment that allows them to focus on the work free of interruption is critical. This also suggests that a constant redirection of work will eventually cause problems between developers and managers. Developers are also motivated by their personal lives. Don't expect them to live their lives at work. Last, the data clearly shows that developers are usually not motivated to move into a management position. More often than not, promoting a developer to manager is a mistake and the organization will suffer.

Staffing
Since software is developed by people, their selection for projects is of the utmost importance. Boehm presents five basic principles of software staffing. ⁸ There is the principle of top talent. The idea here is to use better and fewer people. Given the productivity implications above, significant differences exist between good, average, and mediocre people. The best people will be much more productive. Therefore, fewer people will be needed. However, the most productive people will also cost more. It seems that management will consistently pick the person who costs less, but this ignores the data concerning productivity.

The second principle deals with job matching. The idea is to fit the tasks to the skills and motivation of the people. In terms of technical skills, larger projects have many areas of specialization. It's important to select people to fill these positions based on their areas of expertise. For instance, it would not be appropriate to place a person skilled in developing higher level application software in a position which would require the development of embedded real-time firmware. The interpersonal skills of the people are also very important. Clearly, a person who is in a lead or managerial position needs to have effective communication and conflict resolution skills.

The third principle deals with career progression. An organization will benefit itself in the long run by helping its people to progress in their careers and keep current with the latest trends and technologies. It is also important not to force people to consistently work in areas where they are needed the most or have the most experience, but to let them explore other areas of interest. Of course, current business conditions will influence this activity significantly.

The fourth principle deals with team balance. The idea is to select people who will complement and harmonize with each other. The balance and coverage of a team are important considerations. Balance means that the team has a sufficiently diverse set of skills to achieve objectives. Coverage means that all critical skills needed are represented on the team. It is far better to have a team of average but solid performers dedicated to achieving results than it is to have one staffed with superstar developers engaged in adversarial relationships. The first team will easily outperform the second.

The fifth principle deals with members will be affected, resulting in more problems than before.

Teamwork
As software continues to become more complex, teams are increasingly the mechanism that determines the success of a project. Only teams can deliver the productivity enhancements needed to create complex software in a timely and cost-effective fashion. While much work has been accomplished in enhancing individual productivity over the last two decades, it is the productivity of teams that will be the deciding factor in the future.

Katzenbach and Smith define a team as "a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable." ⁹

Most teams usually consist of a small number of people, often between five and seven. ¹⁰ Teams with less than five members risk not having the creativity needed, while those with more than seven can cause subgroups to form which increases the likelihood of conflict. Larger groups of people can form teams, provided each individual makes a significant commitment.

An effective team must have the right mix of skills. The first of these is technical or functional expertise. It is important that the team not be staffed by people of only one particular skill set. Problem solving and decision skills are also important so that team members can readily evaluate opportunities and problems and come to conclusions on how to proceed. Last, interpersonal skills are essential to group communication and resolving conflicts in constructive manners. A surprising conclusion here is that the team members do not need to have all of these skills at the beginning. The most effective teams quickly identify the gaps in skills and the specific training members need to acquire them. Individual accountability will promote the necessary learning.

A team's purpose and performance goals cannot be separated. A demanding performance challenge is an essential factor in team formation and must relate to the team's purpose or there will be confusion. Most teams get their mandate from management and it belongs to them both individually and collectively. An effective team is constantly shaping their purpose as this clarifies the implications to members. The purpose is translated into specific objectives, which keeps the focus on achieving results. The focus on results helps to push member status and personality issues away as well. Objectives also help the team to win the small battles that are essential to building commitment.

All team members must be committed to a common approach, a shared way of working together to accomplish their purpose. In order for this to happen, every team member must do equal amounts of real work and make substantial contributions. Members should agree on how this takes place; this helps to advance the team's performance objectives. There is also a need for social roles on a team, roles that provide support for members and keep everyone honest and headed in the right direction. These roles usually evolve of their own accord on effective teams.

For a team to exist, there must be mutual accountability. This means both individual and team accountability. Commitment and trust among team members helps accountability to flourish. Accountability tends to grow as the team's purpose, goals, and approach are developed. In many ways, the quality of the team's results are highly dependent on this joint accountability.

In discussing teams, it is important to look at various groups of people to determine how they fit into the team model. These small groups include working groups, pseudo-teams, potential teams, real teams, and high-performance teams: ¹¹

• The working group is a group of people who are simply sharing information among themselves. There is no significant incremental performance need or opportunity that requires it to become a team
• The pseudo-team is a group for which a significant incremental performance need or opportunity could exist. However, the group has not focused on collective performance and is not trying to achieve it. Pseudo-teams have a smaller performance impact than working groups because their interactions detract from each member's individual performance without the corresponding joint benefits
• The potential team is a group for which there is a significant incremental performance need. The group is also making a substantial effort to improve its performance impact. Usually, the purpose, goals, and approach need more clarity. Mutual accountability does not exist yet
• The team is a group of people who satisfy all the basic characteristics described above. A significant performance impact occurs during the movement from a potential team to a team
• The high-performance team is a group which satisfies all the basic team characteristics with members who are also deeply committed to one another's personal growth and success. The high-performance team outperforms all other teams

Katzenbach and Smith also identify a number of common approaches to enhance the performance impact of teams: ¹²

• Establish urgency and direction
• Select members based on skills and skill potential, not personalities
• Pay particular attention to first meetings and actions
• Set some clear rules of behavior
• Set and seize upon a few immediate performance-oriented tasks and goals
• Challenge the group regularly with fresh facts and information
• Spend lots of time together
• Exploit the power of positive feedback, recognition, and reward

Process
Process is defined as a systematic series of actions for doing software development. The purpose of a process is to maximize the allocation of resources to productive activities and minimize the impact of overhead activities. ¹³ The following benefits are obtained by having a well-defined and flexible process in place. First, rework is avoided completely or minimized where possible. Second, there is a focus on the activities that constitute software development: requirements management, analysis, design, implementation, and test. Third, the quality of the delivered product is enhanced since errors are detected at the stage where they occur, where they are the least costly to fix. Last, there is an emphasis placed on risk management early in the lifecycle.

The waterfall model is the most common life cycle model found in software development. This model describes the sequential steps necessary to develop a successful software product. The model also shows that defects are much less costly to correct the earlier they are identified. The waterfall model works well with small projects and projects where the problem domain is well understood. However, several assumptions in the model cause significant problems when the model is used to develop software on large projects. The model assumes that the problem space is completely understood and that all requirements have been identified. However, the requirements can never be nailed down completely since customer expectations, markets, and the software and hardware technologies constantly change. Second, the model assumes that a design can be developed which captures all requirements and constraints. Obviously, any unresolved problems in the requirements phase will be pushed forward into subsequent phases. Last, the model pushes risks forward, effectively masking them until it is too late to deal with them in any meaningful fashion. These risks usually manifest themselves at integration time.

Figure 1: Waterfall and iterative models

Since the waterfall model works well on small projects, we can take a large project and divide the development activities into a series of small waterfall projects as Figure 1 shows. The figure compares the waterfall model with an iterative process showing three iterations. Notice that there are three distinct and smaller integration phases instead of a "big bang" integration. Each iteration resolves risks and brings us closer to a successful product.

The iterative process described here will follow the work now known as the Rational Unified Process (RUP). ¹⁴ This process identifies two distinct sets of activities in software development: research and development activities and production activities. It is from the separation of these two sets of activities that the phases of the iterative process are defined. The first stage is defined as the engineering stage and consists of the inception and elaboration phases. Team sizes during the engineering stage will be smaller due to the unprecedentedness of the work involved. The second stage is defined as the production phase and consists of the construction and transition phases. Team sizes during the production stage will be larger since construction and transition activities are well defined and much work can take place in parallel. Keep in mind that each phase may consist of several iterations. During the inception phase, the business case and scope of the project are defined. This is where the initial ideas are investigated and the functionality in the final product is identified. An initial architecture is defined based on the required functionality. The milestone associated with this phase is called the life cycle objective milestone.

During the elaboration phase, the goal is to refine the requirements and architecture to a stable point where the architecture can be baselined. A plan is also developed that identifies the iterations and evaluation criteria for each iteration during the construction phase. Since this is the phase in which risks are sufficiently mitigated, the plan should enable you to predict the schedule and cost of the remaining development. An executable prototype is also generated in this phase. At the end of this phase, the engineering activities are considered complete. The milestone associated with this phase is the life cycle architecture milestone.

The construction phase begins the activities associated with production. During this phase, all remaining components and features are developed and integrated into the product and then tested. The emphasis here is on managing resources and optimizing schedule, cost, and quality. If a project is big enough, the activities in this phase are executed in parallel. The goal of this phase is to have a beta release of the software to users to evaluate provided this does not expose the project to high risks. The milestone associated with this phase is the initial operational capability milestone.

Figure 2: Iterative process life cycle

The transition phase is where the software product is mature enough to be deployed to end users. This means that the product has met its quality objectives and user documentation exists. As end users exercise the software, issues will arise that require corrections or new releases. The goal of this phase is to have the end users self-supportive in their use of the product. The milestone associated with this phase is the product release milestone. Figure 2 shows an example of an iterative process life cycle with 10 iterations. ¹⁵ The number of iterations can vary. The major and minor milestones are shown.

Notice how the iterative process addresses the problems of the waterfall model. The more difficult features are developed first in the earlier iterations and refined in later iterations. Risks are effectively mitigated since there are now several integration periods to identify and resolve problems. Requirement and feature changes and additions can now be handled as the project proceeds through subsequent iterations. The iterations allow the developers to learn as they go and build up their expertise as they proceed. This will be especially effective with newer tools and development environments. As the iterations proceed, opportunities to identify commonality across the project will arise, an activity that should facilitate the reuse of components. Since the project will have been tested and integrated several times, the probability of significant errors remaining is low. This means that the overall quality of the product should be enhanced.

Architecture plays a critical and central role within RUP. The following are some of the definitions given to architecture: ¹⁶

• The architecture is the organization of a software system
• The architecture consists of structural elements and their behaviors and interfaces
• Architecture consists of the composition of these elements into progressively larger subsystems
• Architecture also considers performance, reliability, reuse, and economic and technological constraints and trade-offs

In short, architecture covers nearly every aspect of software system design including hardware constraints. In the past, architecture has not been given its proper place as the foundation on which a software product is based. Many of the problems commonly attributed to the waterfall model are in reality problems with the architecture not being defined appropriately. For example, many system-level issues such as performance requirements do not surface as problems until the integration phase of a project. At this point, it is too late to do a reasonable job of satisfying these requirements within any reasonable timeframe. A sound architecture and an iterative process that continually mitigates risks are two techniques that decrease the probability of problems like this. One of the big problems with architecture has been representing multiple views or dimensions. To accurately represent an architecture, multiple views covering different aspects of the system are needed. The concept of multiple architecture views is part of RUP and was first elaborated by Philippe Kruchten. ¹⁷ The five views are now summarized:

• The logical view addresses the functional requirements of the system, the feature content that the end user manipulates. It represents an abstraction of the design model and identifies major subsystems and classes
• The development view describes the organization and management of source code, data, components, and executables in the development environment. It seeks to address the issues of ease of development, reuse, and build-or-buy decisions
• The process view addresses the runtime behavior of the system in terms of its tasks, threads, and processes. It deals with issues such as performance, scaleability, throughput, and fault tolerance
• The physical view addresses how the executables and other runtime components map to the underlying computing platforms. This view deals with the systems engineering aspect of architecture
• The last is the use-case view. This view contains several key use-cases which are used to drive the discovery process with regard to the other views. As such, it integrates the other views into a coherent architecture which drives the remaining work. The use-cases also serve to validate the other views later

Product
The most significant point to understand about software development is this: the complexity of software does not scale linearly with size. Complexity is defined as product size. The effort required to build a software product increases faster than the size of the product. This means that we can decrease the time it takes to develop the product by reducing its size. We can quantify these relationships by considering the Constructive Cost Model (COCOMO). ¹⁸ COCOMO is a model that estimates the effort and duration of a software project based on its estimated size in thousands of lines of code (KLOC). Table 2 shows data derived from the COCOMO embedded mode equations. Notice how the effort increases much faster than the product size.

We can also look at the impact of product size on such aspects as schedules, productivity, and delivered defects. Table 3 shows that as product size increases, an increasing number of projects fail to meet their schedule commitments or are simply cancelled. Note especially the significant jump in late and cancelled projects as the product size increases from 100 to 1,000 function points. Our ability to manage the complexity of the product begins to fail within this range.

Figure 3: Relationship between productivity and product size

Figure 3 shows how productivity and product size relate within the U.S. ²⁰ In general, as product size increases, productivity drops. This is due to the additional overhead that larger projects have and is primarily due to the growth of interpersonal communications and system integration. ²¹ Note that the productivity of embedded systems is lower than the U.S. average.

Figure 4: Relationship between product size and delivered defects

Figure 4 shows the relationship between product size and delivered defects. ²² Notice how the number of defects increase with product size. Notice also how the number of defects is lower for embedded systems, reflecting the increased focus on quality.

We see that productivity decreases and defects increase as product size increases. Notice that the effects are nonlinear. The conclusion to draw from this is that smaller, less complex projects deliver higher quality software and do it more quickly.

Given the above implications about product size, an obvious way to simplify the product is to write less software. This can be accomplished in several ways. First, object-oriented techniques and higher order languages like C++ can be used to write less code via abstraction and inheritance. Second, commercial components and libraries can be used instead of developing the same functionality in-house. Of course, maintaining and upgrading commercial components and libraries involves work.

A significant decision for embedded systems is whether you need a real-time operating system (RTOS). The first decision is to determine if your application needs the services an RTOS can provide. If it does, the next decision is whether you buy a commercial RTOS or write your own. A proprietary RTOS can better address the specific needs of an application but requires significant cost to develop and maintain. A commercial RTOS will usually be cheaper, more thoroughly tested, and include customer support. It will also likely provide an integrated set of tools for development.

Another way to simplify the product is to develop only the most essential features. A rule of thumb such as the 80/20 rule can be followed. An example of this is to develop the 80% of the features that take 20% of the time. ²³ An even better way is to develop the feature set in iterations. The more difficult features are developed first and given more iterations to be refined. This process allows the risk inherent in the more difficult features to be mitigated across the iterations.

Technology
A variety of technologies is available to enhance software development. Object-oriented techniques and higher order languages such as C++ first come to mind. There has not been much use of either one within the embedded world due to performance and memory constraints. However, as the cost of processor cycles and memory continue to decrease, they should be looked at in detail. The long-term benefits of abstraction and reuse of designs and code are simply too great to ignore. It must also be noted that significant learning curves must be overcome in the use of both. It is also worthwhile to note that C++ takes many fewer lines of code to express equivalent functionality in C or assembly.

The concept of modeling is becoming more important in software development. Models are used because they help us to understand the problem domain we have to deal with. Once we have a good understanding of the problem domain, we can make trade-offs and come up with an optimized solution to the problem. These models are maintained by the organization and represent its intellectual property.

Modeling has been given a significant push forward with the introduction of the Unified Modeling Language (UML). UML is a rigorous graphical language that allows the user to visualize, specify, and document the artifacts of a software system. It stands a very good chance of becoming the communication medium of choice for architects, designers, and programmers. UML allows one to effectively specify the architecture views in the 4+1 view model discussed earlier.

It is important to note that none of the tools and techniques described above offer productivity enhancements that would cause them to be viewed as a silver bullet. However, their use in a consistent and disciplined manner will go far in allowing organizations to enhance their productivity and competitiveness.

COCOMO 2.0 software cost model
The COCOMO 2.0 software cost estimation model is an update to the earlier COCOMO model and takes into account modern software practices. ²⁴ It will be useful to look at the factors that this model takes into account. COCOMO 2.0 consists of three different cost estimation models that can be mapped to an iterative life cycle. The applications composition model corresponds to prototyping efforts to resolve high-risk issues. This model would be used to estimate work that involved exploratory analyses typical at the beginning of new and complex projects. This model maps to the engineering stage (inception phase) of RUP.

The early design model corresponds to the exploration of alternative software and system architectures. This model would fit within the engineering stage of RUP (elaboration stage) where there would be a good understanding of the requirements and architecture. The post-architecture model corresponds to the actual development and maintenance of a software product. This model would fit into the production stage of RUP (construction and transition phases). At this point, the requirements and architecture should be stable. The overall cost estimate equations for the early design and post-architecture phases follow. ²⁵ For the early design model:

Effort = 2.45 E(ARCH)(Size)P


For the post-architecture model:


Effort = 2.45 E(APP)(Size)P


where


P = 1.01 + 0.01 Wi

Effort is given in staff months and Size in function points for the first equation and in thousands of source lines of code in the second equation. The exponent P is the scaling factor applied to both equations and is a weighted sum of five factors as given by Table 4.

E(APP) is the product of the seven early design effort adjustment factors (cost drivers) shown in the left column of Table 5. Note that the early design factors are derived from the composite post-architecture cost drivers as shown in the right column of Table 5.

E(ARCH) is the product of the 17 post-architecture effort adjustment factors (cost drivers) shown in the right column of Table 5. The effects of the five scale factors are exponential in nature. As such, they represent your greatest leverage points on the road to a successful software project. They are also consistent with the themes discussed in this article.

Technology impacts
I have discussed a number of techniques designed to increase the probability of success of software projects. Table 6 lists some recent data that can be used to judge the impact of these techniques. ²⁶ The data come from the knowledge base of Software Productivity Research. The margin of error in the data in Table 5 is high, but we can learn some things from the general trends present.

Notice how the vast majority of technologies listed require significant learning curves and productivity results that are initially negative. This is important information not usually taken into account by the vendors or users of the technologies. Many examples exist of where technologies are abandoned when faced with this initial up-front cost. However, the data clearly show the long-term benefits of these technologies.

We see that reusable designs and code have significant up-front costs replicating the research to date in this area. However, the end productivity results and ROI clearly justify the effort here as do the positive schedule impacts.

Formal inspections represent one of the best ways to enhance the quality of software products. There is little upfront cost with tremendous ROI and final productivity and schedule reduction results. Notice how formal inspections can remove 35% of the defects at a particular stage. This means that a combination of design and code inspections can immediately give you a defect removal rate of 70%. Measurements are also a good way to enhance quality but only if the measurements are used to tune the existing processes.

The data on prototypes show why this activity is an important part of any process. An early prototype gives leverage with both the schedule and the quality of the product as well as being a highly productive activity. Notice how there is little up-front cost here since this work will have to be done regardless of when it is accomplished.

The data on object-oriented (OO) techniques are interesting. Both OO and ROI have extremely high up-front costs but longer-term OO programming shows much better productivity and ROI. It seems that the learning curve for OO design is prohibitive, causing many projects to either abandon it or go back to other better-known techniques. ²⁷

Last, we see the increasing productivity, quality enhancements, and ROI that adherence to the Software Engineering Institute's Capability Maturity Model (CMM) brings.

Scott Briggs is currently a manager of software development in the switching systems group at Alcatel USA. He holds a BSEE from Washington University and an MBA. He has 10 years experience in the development of hardware and software for embedded systems in the defense and telcommunications industries.

Resources
Boehm, Barry W., "An Overview of the COCOMO 2.0 Software Cost Model," Software Technology Conference, April 1995. This paper can be found at sunset.usc.edu/COCOMOII/cocomo.html. Boehm, Barry W., Bradford Clark, Ellis Horowitz, Ray Madachay, Richard Shelby, and Chris Westland, "Cost Models for Future Software Life Cycle Processes: COCOMO 2.0," Annals of Software Engineering, 1995. This paper can be found at sunset.usc.edu/COCOMOII/cocomo.html .

Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981.

Herzberg, Frederick, "One more time: How do you motivate employees?" Harvard Business Review, September-October 1987, pp. 109-120. Jones, Capers. Applied Software Measurement. New York: McGraw-Hill, 1996.

Katzenbach, Jon R. and Douglas K. Smith. The Wisdom of Teams. New York: HarperCollins, 1993.

Kruchten, Philippe, "The 4+1 View Model of Architecture," IEEE Software, November 1995, pp. 42-50.

Kruchten, Philippe. The Rational Unified Process: An Introduction. Reading, MA: Addison-Wesley, 1999.

McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996.

Royce, Walker. Software Project Management: A Unified Framework. Reading, MA: Addison-Wesley, 1998.

References

1. From "Optimizing Software Teamwork" by John R. Rymer.
Back

2. From "Embedded Y2K" by Jack G. Ganssle (Embedded Systems Programming, February 1999, p. 97) Back

3. I first read about this way of breaking up the areas of impact into the four dimensions of people, process, product, and technology in Steve McConnell's book Rapid Development.
Back

4. McConnell, p. 14.
Back

5. Boehm, Software Engineering Economics, p. 672.
Back

6. Herzberg, "One more time: How do you motivate employees?" p. 118.
Back

7. Herzberg, pp. 111-113.
Back

8. Boehm, pp. 667-672.
Back

9. Katzenbach and Smith, The Wisdom of Team, p. 45.
Back

10. I first heard of this range for team size in an introductory management class in 1999.
Back

11. Katzenbach and Smith, pp. 90-92.
Back

12. Katzenbach and Smith, pp. 19-127.
Back

14. Kruchten, The Rational Unified Process: An Introduction.
Back

15. Adapted from Kruchten, Figures 4 through 6.
Back

16. Kruchten, pp. 80-81.
Back

17. Kruchten, "The 4+1 View Model Architecture."
Back

18. See Boehm's Software Engineering Economics.
Back

19. From private communication with Capers Jones.
Back

20. Data adapted from Jones' Applied Software Measurement, p. 213.
Back

21. Boehm, "An Overview of the COCO- MO 2.0 Software Cost Model."
Back

22. Data adapted from Jones' Applied Software Measurement, p. 232.
Back

23. McConnell, p. 17.
Back

24. Boehm et al., "Cost Models for Future Software Life Cycle Processes: COCO- MO 2.0."
Back

25. Royce, pp. 274-281
Back

26. Adapted from Jones' Applied Software Measurement, pp. 240-241.
Back

27. Jones, p. 237.
Back