UNIT- I

1.1 Conventional software management

 Conventional software management practices are sound in theory, but practice is still tied
to archaic (outdated) technology and techniques.
 Conventional software economics provides a benchmark of performance for conventional
software management principles.
 The best thing about software is its flexibility: It can be programmed to do almost
anything.
 The worst thing about software is also its flexibility: The "almost anything"
characteristic has made it difficult to plan, monitors, and control software development.
 Three important analyses of the state of the software engineering industry are
1. Software development is still highly unpredictable. Only about 10% of software
projects are delivered successfully within initial budget and schedule estimates.
2. Management discipline is more of a discriminator in success or failure than are
technology advances.
3. The level of software scrap and rework is indicative of an immature process.
 The Standish Group, Jones, Defense Science Board, analysis of all three papers says that,
the success rate for software projects is very low.

1.1.1 The WATERFALL MODEL

Most software engineering texts present the waterfall model as the source of the
"conventional" software process.

1.1.1.1 In Theory:

It provides an insightful and concise summary of conventional software management

Three main primary points are
1. There are two essential steps common to the development of computer programs:
analysis and coding.

Waterfall Model part 1: The two basic steps to building a program.

 Analysis and coding both involve creative work that directly contributes to the usefulness of
the end product.

2. In order to manage and control all of the intellectual freedom associated with software
development, one must introduce several other "overhead" steps, including system
requirements definition, software requirements definition, program design, and testing.
These steps supplement the analysis and coding steps. Below Figure illustrates the resulting
project profile and the basic steps in developing a large-scale program.

3. The basic framework described in the waterfall model is risky and invites failure. The
testing phase that occurs at the end of the development cycle is the first event for which
timing, storage, input/output transfers, etc., are experienced as distinguished from
analyzed. The resulting design changes are likely to be so disruptive that the software
requirements upon which the design is based are likely violated. Either the requirements
must be modified or a substantial design change is warranted.

Five necessary improvements for waterfall model are:-

1. Program design comes first. Insert a preliminary program design phase between the software
requirements generation phase and the analysis phase. By this technique, the program designer
assures that the software will not fail because of storage, timing, and data flux (continuous
change). As analysis proceeds in the succeeding phase, the program designer must impose on the
analyst the storage, timing, and operational constraints in such a way that he senses the
consequences. If the total resources to be applied are insufficient or if the embryonic(in an early
stage of development) operational design is wrong, it will be recognized at this early stage and
the iteration with requirements and preliminary design can be redone before final design, coding,
and test commences. How is this program design procedure implemented?

The following steps are required:

Begin the design process with program designers, not analysts or programmers.
Design, define, and allocate the data processing modes even at the risk of being wrong. Allocate
processing functions, design the database, allocate execution time, define interfaces and
processing modes with the operating system, describe input and output processing, and define
preliminary operating procedures.
Write an overview document that is understandable, informative, and current so that every
worker on the project can gain an elemental understanding of the system.

2. Document the design. The amount of documentation required on most software programs is
quite a lot, certainly much more than most programmers, analysts, or program designers are
willing to do if left to their own devices. Why do we need so much documentation? (1) Each
designer must communicate with interfacing designers, managers, and possibly customers. (2)
During early phases, the documentation is the design. (3) The real monetary value of
documentation is to support later modifications by a separate test team, a separate maintenance
team, and operations personnel who are not software literate.

3. Do it twice. If a computer program is being developed for the first time, arrange matters so
that the version finally delivered to the customer for operational deployment is actually the
second version insofar as critical design/operations are concerned. Note that this is simply the
entire process done in miniature, to a time scale that is relatively small with respect to the overall
effort. In the first version, the team must have a special broad competence where they can
quickly sense trouble spots in the design, model them, model alternatives, forget the
straightforward aspects of the design that aren't worth studying at this early point, and, finally,
arrive at an error-free program.

4. Plan, control, and monitor testing. Without question, the biggest user of project resources-
manpower, computer time, and/or management judgment-is the test phase. This is the phase of
greatest risk in terms of cost and schedule. It occurs at the latest point in the schedule, when
backup alternatives are least available, if at all. The previous three recommendations were all
aimed at uncovering and solving problems before entering the test phase. However, even after
doing these things, there is still a test phase and there are still important things to be done,
including: (1) employ a team of test specialists who were not responsible for the original design;
(2) employ visual inspections to spot the obvious errors like dropped minus signs, missing
factors of two, jumps to wrong addresses (do not use the computer to detect this kind of thing, it
is too expensive); (3) test every logic path; (4) employ the final checkout on the target computer.

5. Involve the customer. It is important to involve the customer in a formal way so that he has
committed himself at earlier points before final delivery. There are three points following
requirements definition where the insight, judgment, and commitment of the customer can
bolster the development effort. These include a "preliminary software review" following the
preliminary program design step, a sequence of "critical software design reviews" during
program design, and a "final software acceptance review".

1.1.1.2 In Practice:
Some software projects still practice the conventional software management approach.
It is useful to summarize the characteristics of the conventional process as it has typically been
applied, which is not necessarily as it was intended. Projects destined for trouble frequently
exhibit the following symptoms:
 Protracted integration and late design breakage.
 Late risk resolution.
 Requirements-driven functional decomposition.
 Adversarial (conflict or opposition) stakeholder relationships.
 Focus on documents and review meetings.

Protracted Integration and Late Design Breakage For a typical development project that used a
waterfall model management process, Figure 1-2 illustrates development progress versus time.
Progress is defined as percent coded, that is, demonstrable in its target form.
 The following sequence was common: Early success via paper designs and thorough (often
too thorough) briefings.
 Commitment to code late in the life cycle.
 Integration nightmares (unpleasant experience) due to unforeseen implementation issues and
interface ambiguities.
 Heavy budget and schedule pressure to get the system working.
 Late shoe-homing of no optimal fixes, with no time for redesign.
 A very fragile, unmentionable product delivered late.

Figure 1.2: Progress Profile of a conventional software project

In the conventional model, the entire system was designed on paper, then implemented all at
once, then integrated. Table 1-1 provides a typical profile of cost expenditures across the
spectrum of software activities.

Late risk resolution A serious issue associated with the waterfall lifecycle was the lack of
early risk resolution. Figure1.3 illustrates a typical risk profile for conventional waterfall
model projects. It includes four distinct periods of risk exposure, where risk is defined as the
probability of missing a cost, schedule, feature, or quality goal. Early in the life cycle, as the
requirements were being specified, the actual risk exposure was highly unpredictable.
Requirements-Driven Functional Decomposition: This approach depends on specifying
requirements completely and unambiguously before other development activities begin. It
naively treats all requirements as equally important, and depends on those requirements
remaining constant over the software development life cycle. These conditions rarely occur in
the real world. Specification of requirements is a difficult and important part of the software
development process.

Another property of the conventional approach is that the requirements were typically
specified in a functional manner. Built into the classic waterfall process was the fundamental
assumption that the software itself was decomposed into functions; requirements were then
allocated to the resulting components. This decomposition was often very different from a
decomposition based on object- oriented design and the use of existing components. Figure 1-
4 illustrates the result of requirements- driven approaches: a software structure that is
organized around the requirements specification structure.
Figure 1-4: Suboptimal software component organization resulting from a requirements driven
approach

Adversarial Stakeholder Relationships:

The conventional process tended to result in adversarial stakeholder relationships, in
large part because of the difficulties of requirements specification and the exchange of
information solely through paper documents that captured engineering information in ad hoc
formats.

The following sequence of events was typical for most contractual software efforts:
1. The contractor prepared a draft contract-deliverable document that captured an
intermediate artifact and delivered it to the customer for approval.
2. The customer was expected to provide comments (typically within 15 to 30days).
3. The contractor incorporated these comments and submitted (typically within 15 to 30
days) a final version for approval.
This one-shot review process encouraged high levels of sensitivity on the part of customers and
contractors.

Focus on Documents and Review Meetings:

Theconventionalprocessfocusedonproducingvariousdocumentsthatattemptedtodescribethesoft
ware product, with insufficient focus on producing tangible increments of the products
themselves. Contractors were driven to produce literally tons of paper to meet milestones and
demonstrate progress to stakeholders, rather than spend their energy on tasks that would
reduce risk and produce quality software. Typically, presenters and the audience reviewed the
simple things that they understood rather than the complex and important issues.
Mostdesignreviewsthereforeresultedinlowengineeringvalueandhighcostintermsof the effort
and schedule involved in their preparation and conduct. They presented merely a facade of
progress.
Table 1-2 summarizes the results of a typical design review.

1.1.2 CONVENTIONAL SOFTWARE MANAGEMENT PERFORMANCE

Barry Boehm's "Industrial Software Metrics Top 10 List” is a good, objective characterization
of the state of software development.

1. Finding and fixing a software problem after delivery costs 100 times more than finding
and fixing the problem in early design phases.

2. You can compress software development schedules 25% of nominal, but no more.
3. For every $1 you spend on development, you will spend $2 on maintenance.
4. Software development and maintenance costs are primarily a function of the number of
source lines of code.
5. Variations among people account for the biggest differences in software productivity.

6. The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in
1985,85:15.
7. Only about 15% of software development effort is devoted to programming.
8. Software systems and products typically cost 3 times as much per SLOC as individual
software programs. Software-system products (i.e., system of systems) cost 9 times as
much.

9. Walkthroughs catch 60% of the errors

 10. 80% of the contribution comes from 20% of the contributors.

1.2 EVOLUTION OF SOFTWARE ECONOMICS

1.2.1 SOFTWARE ECONOMICS:

Most software cost models can be abstracted into a function of five basic parameters: size,
process, personnel, environment, and required quality.
1. The size of the end product (in human-generated components), which is typically
quantified in terms of the number of source instructions or the number of function points
required to develop the required functionality
2. The process used to produce the end product, in particular the ability of the process to
avoid non-value- adding activities (rework, bureaucratic delays, communications
overhead)
3. The capabilities of software engineering personnel, and particularly their experience with
the computer science issues and the applications domain issues of the project.
4. The environment, which is made up of the tools and techniques available to support
efficient software development and to automate the process.
5. The required quality of the product, including its features, performance, reliability, and
adaptability.
The relationships among these parameters and the estimated cost can be written as follows:
Effort =(Personnel) (Environment) (Quality) ( Sizeprocess)
One important aspect of software economics (as represented with in today's software cost
models) is that the relationship between effort and size exhibits a diseconomy of scale. The
diseconomy of scale of software development is a result of the process exponent being greater
than 1.0.
Contrary to most manufacturing processes, the more software you build, the more
expensive it is per unit item.
Figure 1-5 shows three generations of basic technology advancement in tools,
components, and processes. The required levels of quality and personnel are assumed to be
constant. The ordinate of the graph refers to software unit costs (pick your favorite: per SLOC,
per function point, per component)realized by an organization. The three generations of
software development are defined as follows:
1. Conventional:1960s and1970s, craftsmanship. Organizations used custom tools, custom
processes, and virtually all custom components built in primitive languages. Project
performance was highly predictable in that cost, schedule, and quality objectives were almost
always under achieved.
2. Transition: 1980s and 1990s, software engineering. Organizations used more-repeatable
processes and off- the-shelf tools, and mostly (>70%) custom components built in higher
level languages. Some of the components (<30%) were available as commercial products,
 including the operating system, database management system, networking, and graphical
user interface.
3. Modern practices: 2000 and later, software production. This book's philosophy is rooted in
the use of managed and measured processes, integrated automation environments, and mostly
(70%) off-the-shelf components. Perhaps as few as 30% of the components need to be
custom built.
Technologies for environment automation, size reduction, and process improvement are
not independent of one another. In each new era, the key is complementary growth in all
technologies. For example, the process advances could not be used successfully without new
component technologies and increased tool automation.

Figure 1-5: Three generations of software economics leading to the target objective
Organizations are achieving better economies of scale in successive technology eras-with very
large projects (systems of systems), long-lived products, and lines of business comprising
multiple similar projects. Figure 1-6 provides an overview of how a return on investment (ROI)
profile can be achieved in subsequent efforts across life cycles of various domains.

Figure 1.6: Return on investment in different domains

1.2.2 PRAGMATIC SOFTWARE COST ESTIMATION
One critical problem in software cost estimation is a lack of well-documented case studies of
projects that used an iterative development approach. Software industry has inconsistently
defined metrics or atomic units of measure, the data from actual projects are highly suspect in
terms of consistency and comparability. It is hard enough to collect a homogeneous set of
project data within one organization; it is extremely difficult to homogenize data across
different organizations with different processes, languages, domains, and so on.

There have been many debates among developers and vendors of software cost estimation
models and tools. Three topics of these debates are of particular interest here:

1. Which cost estimation model to use?

2. Whether to measure software size in source lines of code or function points.
3. What constitutes a good estimate?

There are several popular cost estimation models (such as COCOMO, CHECKPOINT,
ESTIMACS, Knowledge Plan, Price-S, ProQMS, SEER, SLIM, SOFTCOST, and SPQR/20),
CO COMO is also one of the most open and well-documented cost estimation models. The
general accuracy of conventional cost models (such as COCOMO) has been described as "within
20% of actuals, 70% of the time."

Most real-world use of cost models is bottom-up (substantiating a target cost) rather than
top-down (estimating the "should" cost). Figure 2-3 illustrates the predominant practice: The
software project manager defines the target cost of the software, and then manipulates the
parameters and sizing until the target cost can be justified. The rationale for the target cost maybe
to win a proposal, to solicit customer funding, to attain internal corporate funding, or to achieve
some other goal.

The process described in Figure 1-7 is not all bad. In fact, it is absolutely necessary to analyze the
cost risks and understand the sensitivities and trade-offs objectively. It forces the software
project manager to examine the risks associated with achieving the target costs and to discuss
this information with other stakeholders.

A good software cost estimate has the following attributes:

 It is conceived and supported by the project manager, architecture team, development

team, and test team accountable for performing the work.

 It is accepted by all stakeholders as ambitious but realizable.

 It is based on a well-defined software cost model with a credible basis.

 It is based on a database of relevant project experience that includes similar processes,

 similar technologies, similar environments, similar quality requirements, and similar
people.

 It is defined in enough detail so that its key risk areas are understood and the probability
of success is objectively assessed.
Extrapolating from a good estimate, an ideal estimate would be derived from a mature cost
model with an experience base that reflects multiple similar projects done by the same team with
the same mature processes and tools.

Figure 1-7 : The Predominant cost estimation process

1.3 IMPROVING SOFTWARE ECONOMICS

Five basic parameters of the software cost model are
1. Reducing the size or complexity of what needs to be developed.
2. Improving the development process.
3. Using more-skilled personnel and better teams (not necessarily the same thing).
4. Using better environments (tools to automate the process).
5. Trading off or backing off on quality thresholds.
These parameters are given in priority order for most software domains. The following table
lists some of the technology developments, process improvement efforts, and management
approaches targeted at improving the economics of software development and integration.
 Table : The Important trends in improving software economics

1.3.1 REDUCING SOFTWARE PRODUCT SIZE

The most significant way to improve affordability and return on investment(ROI) is usually to
produce a product that achieves the design goals with the minimum amount of human-generated
source material. Component-based development is introduced as the general term for reducing
the "source" language size to achieve a software solution.
Reuse, object-oriented technology, automatic code production, and higher order programming
languages are all focused on achieving a given system with fewer lines of human-specified
source directives(statements). size reduction is the primary motivation behind improvements in
higher order languages (such as C++, Ada 95, Java, Visual Basic), automatic code generators
(CASE tools, visual modeling tools, GUI builders), reuse of commercial components (operating
systems, windowing environments, database management systems, middleware, networks), and
object-oriented technologies (Unified Modeling Language, visual modeling tools, architecture
frameworks).
The reduction is defined in terms of human-generated source material. In general, when size-
reducing technologies are used, they reduce the number of human-generated source lines.
1.3.1.1 Languages:
Universal function points (UFPs1) are useful estimators for language-independent, early life-cycle
estimates. The basic units of function points are external user inputs, external outputs, internal logical
data groups, external data interfaces, and external inquiries. SLOC metrics are useful estimators for
software after a candidate solution is formulated and an implementation language is known.
Substantial data have been documented relating SLOC to function points. Some of these results are
shown in Table.
Languages expressiveness of some of today’s popular languages

1.3.1.2 Object Oriented Methods and Visual Modeling:

Object-oriented programming languages appear to benefit both software productivity and
software quality.
The fundamental impact of object-oriented technology is in reducing the overall size of what
needs to be developed.
People like drawing pictures to explain something to others or to themselves. When they do it for
software system design, they call these pictures diagrams or diagrammatic models and the very
notation for them a modeling language.
These are interesting examples of the interrelationships among the dimensions of improving
software economics.
1. An object-oriented model of the problem and its solution encourages a common
vocabulary between the end users of a system and its developers, thus creating a shared
understanding of the problem being solved.
2. The use of continuous integration creates opportunities to recognize risk early and make
incremental corrections without destabilizing the entire development effort.
 3. An object-oriented architecture provides a clear separation of concerns among disparate
elements of a system, creating firewalls that prevent a change in one part of the system
from rending the fabric of the entire architecture.

Booch also summarized five characteristics of a successful object-oriented project.

1. A ruthless focus on the development of a system that provides a well understood
collection of essential minimal characteristics.
2. The existence of a culture that is centered on results, encourages communication, and yet
is not afraid to fail.
3. The effective use of object-oriented modeling.
4. The existence of a strong architectural vision.
5. The application of a well-managed iterative and incremental development life cycle.

1.3.1.3 Reuse:
Reusing existing components and building reusable components have been natural software
engineering activities since the earliest improvements in programming languages. With reuse in
order to minimize development costs while achieving all the other required attributes of
performance, feature set, and quality. Try to treat reuse as a mundane part of achieving a return
on investment.
Most truly reusable components of value are transitioned to commercial products supported by
organizations with the following characteristics:
 They have an economic motivation for continued support.
 They take ownership of improving product quality, adding new features, and
transitioning to new technologies.
 They have a sufficiently broad customer base to be profitable.

The cost of developing a reusable component is not trivial. Figure 1-8 examines the economic
trade-offs. The steep initial curve illustrates the economic obstacle to developing reusable
components.
Reuse is an important discipline that has an impact on the efficiency of all workflows and the
quality of most artifacts.
 Figure 1-8: Cost and Schedule investments necessary to achieve reusable components

1.3.1.4 Commercial Components

A common approach being pursued today in many domains is to maximize integration of commercial
components and off-the-shelf products. While the use of commercial components is certainly
desirable as a means of reducing custom development, it has not proven to be straightforward in
practice. The following Table identifies some of the advantages and disadvantages of using
commercial components.
1.3.2 Improving Software Processes:
Process is an overloaded term. Three distinct process perspectives are.
Metaprocess: an organization's policies, procedures, and practices for pursuing a software-
intensive line of business. The focus of this process is on organizational economics, long-term
strategies, and software ROI.
Macroprocess: a project's policies, procedures, and practices for producing a complete software
product within certain cost, schedule, and quality constraints. The focus of the macro process is
on creating an adequate instance of the Meta process for a specific set of constraints.
Microprocess: a project team's policies, procedures, and practices for achieving an artifact of the
software process. The focus of the micro process is on achieving an intermediate product
baseline with adequate quality and adequate functionality as economically and rapidly as
practical.
Although these three levels of process overlap somewhat, they have different objectives,
audiences, metrics, concerns, and time scales as shown in Table.

Table: The three level of process and their attribute

In a perfect software engineering world with an immaculate problem description, an obvious solution
space, a development team of experienced geniuses, adequate resources, and stakeholders with
common goals, we could execute a software development process in one iteration with almost no
scrap and rework. Because we work in an imperfect world, however, we need to manage engineering
activities so that scrap and rework profiles do not have an impact on the win conditions of any
stakeholder. This should be the underlying premise for most process improvements.

1.3.3 Improving Team Effectiveness:

Teamwork is much more important than the sum of the individuals. With software teams, a
project manager needs to configure a balance of solid talent with highly skilled people in the
leverage positions. Some maxims of team management include the following:
 A well-managed project can succeed with a nominal engineering team.
 A mismanaged project will almost never succeed, even with an expert team of engineers.
 A well-architected system can be built by a nominal team of software builders.
 A poorly architected system will flounder even with an expert team of builders.

Boehm five staffing principles are

1. The principle of top talent: Use better and fewer people
2. The principle of job matching: Fit the tasks to the skills and motivation of the people
available.
3. The principle of career progression: An organization does best in the long run by helping its
people to self-actualize.
4. The principle of team balance: Select people who will complement and harmonize with one
another
5. The principle of phase-out: Keeping a misfit on the team doesn't benefit anyone

Software project managers need many leadership qualities in order to enhance team effectiveness.
The following are some crucial attributes of successful software project managers that deserve much
more attention:
1. Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in
the right job seems obvious but is surprisingly hard to achieve.
2. Customer-interface skill. Avoiding adversarial relationships among stakeholders is a
prerequisite for success.
3. Decision-making skill. The jillion books written about management have failed to provide a
clear definition of this attribute. We all know a good leader when we run into one, and
decision-making skill seems obvious despite its intangible definition.
4. Team-building skill. Teamwork requires that a manager establish trust, motivate progress,
exploit eccentric prima donnas, transition average people into top performers, eliminate
misfits, and consolidate diverse opinions into a team direction.
5. Selling skill. Successful project managers must sell all stakeholders (including themselves)
on decisions and priorities, sell candidates on job positions, sell changes to the status quo in
the face of resistance, and sell achievements against objectives. In practice, selling requires
continuous negotiation, compromise, and empathy
1.3.4 Improving Automation:
The tools and environment used in the software process generally have a linear effect on the
productivity of the process. Planning tools, requirements management tools, visual modeling tools,
compilers, editors, debuggers, quality assurance analysis tools, test tools, and user interfaces provide
crucial automation support for evolving the software engineering artifacts.
Above all, configuration management environments provide the foundation for executing and
instrument the process. At first order, the isolated impact of tools and automation generally allows
improvements of 20% to 40% in effort.
However, tools and environments must be viewed as the primary delivery vehicle for process
automation and improvement, so their impact can be much higher.
Automation of the design process provides payback in quality, the ability to estimate costs and
schedules, and overall productivity using a smaller team.
Round-trip engineering describes the key capability of environments that support iterative
development. As we have moved into maintaining different information repositories for the
engineering artifacts, we need automation support to ensure efficient and error-free transition of data
from one artifact to another.
Forward engineering is the automation of one engineering artifact from another, more abstract
representation. For example, compilers and linkers have provided automated transition of source
code into executable code.
Reverse engineering is the generation or modification of a more abstract representation from an
existing artifact (for example, creating a visual design model from a source code representation).
Economic improvements associated with tools and environments. It is common for tool vendors to
make relatively accurate individual assessments of life-cycle activities to support claims about the
potential economic impact of their tools. For example, it is easy to find statements such as the
following from companies in a particular tool.
 Requirements analysis and evolution activities consume 40% of life-cycle costs.
 Software design activities have an impact on more than 50% of the resources.
 Coding and unit testing activities consume about 50% of software development effort and
schedule.
 Test activities can consume as much as 50% of a project's resources.
 Configuration control and change management are critical activities that can consume as
much as 25% of resources on a large-scale project.
 Documentation activities can consume more than 30% of project engineering resources.
 Project management, business administration, and progress assessment can consume as much
as 30% of project budgets.

1.3.5 Achieving Required Quality:

Software best practices are derived from the development process and technologies. Table 3-5
summarizes some dimensions of quality improvement.
 Table: General quality improvements with a modern process

Key practices that improve overall software quality include the following:
 Focusing on driving requirements and critical use cases early in the life cycle, focusing
on requirements completeness and traceability late in the life cycle, and focusing
throughout the life cycle on a balance between requirements evolution, design evolution,
and plan evolution
 Using metrics and indicators to measure the progress and quality of an architecture as it
evolves from a high-level prototype into a fully compliant product
 Providing integrated life-cycle environments that support early and continuous
configuration control, change management, rigorous design methods, document
automation, and regression test automation
 Using visual modeling and higher level languages that support architectural control,
abstraction, reliable programming, reuse, and self-documentation
 Early and continuous insight into performance issues through demonstration-based
evaluations
Conventional development processes stressed early sizing and timing estimates of computer
program resource utilization. However, the typical chronology of events in performance
assessment was as follows
 Project inception. The proposed design was asserted to be low risk with adequate
performance margin.
 Initial design review. Optimistic assessments of adequate design margin were based
mostly on paper analysis or rough simulation of the critical threads. In most cases, the
actual application algorithms and database sizes were fairly well understood.
 Mid-life-cycle design review. The assessments started whittling away at the margin, as
early benchmarks and initial tests began exposing the optimism inherent in earlier
estimates.
 Integration and test. Serious performance problems were uncovered, necessitating
fundamental changes in the architecture. The underlying infrastructure was usually the
scapegoat, but the real culprit was immature use of the infrastructure, immature
architectural solutions, or poorly understood early design trade-offs.

1.3.6 Peer Inspections.

Peer inspections are frequently over hyped as the key aspect of a quality system. In my experience,
peer reviews are valuable as secondary mechanisms, but they are rarely significant contributors to
quality compared with the following primary quality mechanisms and indicators, which should be
emphasized in the management process:
 Transitioning engineering information from one artifact set to another, thereby assessing the
consistency, feasibility, understand-ability, and technology constraints inherent in the
engineering artifacts
 Major milestone demonstrations that force the artifacts to be assessed against tangible criteria
in the context of relevant use cases
 Environment tools (compilers, debuggers, analyzers, automated test suites) that ensure
representation rigor, consistency, completeness, and change control
 Life-cycle testing for detailed insight into critical trade-offs, acceptance criteria, and
requirements compliance
 Change management metrics for objective insight into multiple-perspective change trends
and convergence or divergence from quality and progress goals

Inspections are also a good vehicle for holding authors accountable for quality products. All authors
of software and documentation should have their products scrutinized as a natural by-product of the
process. Therefore, the coverage of inspections should be across all authors rather than across all
components.