Pressman sofware engineering
Published on: Mar 4, 2016
Transcripts - Pressman sofware engineering
A Practitioner's Approach
Copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at
the university level
When used in conjunction with Software
Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly
CHAPTER OVERVIEW AND COMMENTS
The goal of this chapter is to introduce the notion of software as
a product designed and built by software engineers. Software is
important because it is used by a great many people in society.
Software engineers have a moral and ethical responsibility to
ensure that the software they design does no serious harm to
any people. Software engineers tend to be concerned with the
technical elegance of their software products. Customers tend to
be concerned only with whether or not a software product
meets their needs and is easy to use.
The Evolving Role of Software
The main point of this section is that the primary purpose of
software is that of information transformer. Software is used to
produce, manage, acquire, modify, display, and transmit
information anywhere in the world. The days of the lone
programmer are gone. Modern software is developed by teams
of software specialists. Yet, the software developer's concerns
have remained the same. Why does software take so long to
complete? Why does it cost so much to produce? Why can't all
errors be found and removed before software is delivered to the
Software is not like the artifacts produced in most other
engineering disciplines. Software is developed it is not
manufactured in the classical sense. Building a software product
is more like constructing a design prototype. Opportunities for
replication without customization are not very common.
Software may become deteriorate, but it does not wear out. The
chief reason for software deterioration is that many changes are
made to a software product over its lifetime. As changes are
made, defects may be inadvertently introduced to other
portions of the software that interact with the portion that was
Software: A Crisis on the Horizon
Many people have written about the "software development
crisis". There seems to be an inordinate fascination with the
spectacular software failures and a tendency to ignore the large
number of successes achieved by the software industry.
Software developers are capable of producing software the
functions properly most of the time. The biggest problem facing
modern software engineers is trying to figure out how to
produce software fast enough to meet the growing demand for
more products, while also having to maintain a growing
volume of existing software.
The myths presented in this section provide a good source of
material for class discussion. Managers need to understand that
buying hardware and adding people does not spontaneously
solve all software development problems. Customers need to
understand that computer software does not make all their
other problems go away. If the customer can not define his or
her needs clearly, it is not possible to build a software product
to meet these needs. If a customer does not have defined
business processes without computer support, building
computer software will not create these processes automatically.
Software engineers must be committed to the concept of doing
things right the first time. Software quality does not happen on
its own after a product is finished. Quality must be built into
every portion of the software development process.
PROBLEMS AND POINTS TO PONDER
1.1. Classic examples include the use of "digital
automobile dashboards" to impart a high tech, high
quality images. Appliances that "think;" the broad
array of consumer electronics; personal computers
(today, differentiated more by their software function
than the hardware), industrial instrumentation and
differentiated by software.
1.2. The apprentice/artist culture of the 1950s and
1960s worked fine for single person, well constrained
projects. Today, applications are more complex, teams
work on large projects, and software outlives
established in the early days dies hard, leading more
than a little resistance to more disciplined methods.
In addition (see Chapter 29), the new generation of
Web application developers is repeating many of the
same mistakes that programmer made during the circa
1.3. This is a good problem for classroom discussion
(time permitting). Rather than focusing on cliche'
ridden (albeit important) issues of privacy, quality
"technofright" and how software can help to exacerbate
or remedy it. Another interesting possibility is to
use Neumann's "Risks" column in SEN to key discussion.
You might also consider new attempts at software-based
entertainment, virtual reality, e-commerce, etc.
1.5. There are literally dozens of real life
circumstances to choose from. For example, software
errors that have caused major telephone networks to
fail, failures in avionics that have contributed to
plane crashes, computer viruses (e.g., Michaelangelo)
that have caused significant economic losses. Attacks
on major e-commerce sites.
1.6. The two broadest categories encompass risks
associated with economic loss and risks to the wellbeing of people. You might suggest that each student
select five risks (culled from the sources noted) and
present them to the class. Encourage them to look for
humorous as well as serious risks.
1.7. To be honest, most professors do not assign
papers as part of software engineering courses that
use SEPA. Instead, a term project (or a number of
somewhat smaller projects) are assigned. However, you
might consider discussing software engineering issues
as they relate to the topics noted in this problem.
Another way to characterize this problem is to
suggest that each student describe a software myth
that he or she believed that has subsequently been
dispelled. From the student's point of view, myths
will likely be driven by programming projects that
they've attempted earlier in their career. To give
this problem a contemporary feel, you might consider
the myths that have evolved around the development of
CHAPTER OVERVIEW AND COMMENTS
This chapter discusses several process models used by
professional software developers to manage large-scale
software projects. No software process works well for every
project. However, every project needs to conform to some
systematic process in order to manage software development
activities that can easily get out of control. Software processes
help to organize the work products that need to be produced
during a software development project. Ultimately the best
indicator of how well a software process has worked is the
quality of the deliverables produced. A well-managed process
will produce high quality products on time and under budget.
Software Engineering - A Layered Technology
Software engineering encompasses a process, the management
of activities, technical methods, and use of tools to develop
software products. Software is engineered by applying three
distinct phases (definition, development, and support).
Students need to understand that maintenance involves more
than fixing bugs.
The Software Process
This section discusses the concept of a software process
framework and provides a brief overview of the Software
Engineering Institute Capability Maturity Model. It is important
to emphasize that the Capability Maturity Model does not
specify what process model needs to be used for a given project
or organization. Rather, it provides a means of assessing how
well an organization's processes allow them to complete and
manage new software projects.
Software Process Models
The terms "software process model" and "software engineering
paradigm" are used interchangeably in the literature. This
chapter presents overviews of several software process models.
It is easy for students to become so lost in the details of the
various process models that they fail to see the features the
models have in common with each other. Another difficulty
students have is their belief that each phase of a process is
performed completely independently of the other phases. The
reality is that there tends to be lots overlap among the phases.
The Linear Sequential Model
The linear sequential model is also known as the "classic life
cycle" or "waterfall model". System development proceeds
though the phases (analysis, design, coding, testing, support) in
order. This is a good model to use when requirements are well
understood. If a phase must be revisited in this model, process
failure is indicated (more thorough requirements analysis is
The Prototyping Model
This model is good to use when the customer has legitimate
needs, but is not able to articulate the details at the start of the
project. A small mock-up of a working system is developed and
presented to the customer. Sometimes this first system is
discarded and sometimes it is extended based on the customer's
The RAD Model
The rapid application deployment model is a high-speed
adaptation of the linear sequential model. Project requirements
must be well understood and the project scope tightly
constrained. Developers are often able to use component-based
construction techniques to build a fully functional system in a
short time period.
The two most important models in this section are the
incremental model and the spiral model. The incremental model
combines elements of the linear sequential model applied
repetitively with the iterative philosophy of the prototyping
model. Each increment produces a working version of a
software product with increasing functionality. There is no
throwaway code. The spiral model also combines the iterative
nature of prototyping with the systematic control found in the
linear sequential model. An essential component of the spiral
model is that assessment of both management and technical
risks is performed as each incremental release is completed.
Object-based technologies provide the technical framework for
component-based software engineering. The component-based
development (CBD) model incorporates many of the iterative
characteristics of the spiral model. The main difference is that in
CBD the emphasis is on composing solutions from prepackaged
software components or classes. This CBD emphasizes software
reusability. The unified software development process is an
example of CBD that has been proposed for industrial use. The
unified modeling language (UML) is used to define the
components and interfaces used in the unified software
The Formal Methods Model
Formal methods in software development require the use of
rigorous mathematical notation to specify, design, and verify
computer-based systems. Mathematical proof is used to verify
the correctness of a system (not empirical testing). Cleanroom
software engineering is an example of this approach. While
formal methods have the potential to produce defect-free
software, the development of formal models is both timeconsuming and expensive.
2.10 Fourth Generation Techniques
This is a broad class of techniques. The general idea is that a
software tool is used to describe a system in manner understood
by the customer using a specialized design language or
graphical notation. In the ideal case, the tool then generates
source code from this system description that can be compiled
into a running system. The running system then needs to be
tested and refined using other software engineering processes.
There is some risk that the customer is not able to describe the
system in sufficient detail or that the initial system will be
deployed without sufficient testing.
Section 2.12 uses a short essay by Margaret Davis to
put process and product issues into perspective. If you’re
teaching a graduate course, I’d recommend Phillip
Howard’s The Death of Common Sense, as outside reading on
the failures of a wholly process-oriented mind set.
PROBLEMS AND POINTS TO PONDER
2.1. You might suggest that students use the Further
Readings and Information Sources section of Chapter 8
2.2. The support phase is applied differently for
embedded software. In most cases, embedded software is
defined and developed, but once it is placed in its
host environment, it is not likely to change until a
new release of the product occurs.
The latest SEI information can be obtained at:
2.4. In each case status quo, problem definition,
technical development, and solution integration are
applied at a different levels of abstraction. For
requirements level would entail many meetings with
marketing and even potential end-users;
development” at the product requirements level would
demand the creation of a product specification;
“solution integration” would require detailed review
against customer requirements and modifications. At a
lower level of abstraction (e.g., generate code ...)
the nature of these activities would change, moving
away from customer related information and toward
implementation specific information.
2.5. Assign this problem as is if the majority of
your class is composed of industry practitioners. If
your students are "green," suggest a project scenario
and ask the students to identify the appropriate
paradigm. The key here is to recognize that the "best"
paradigm is a function of the problem, the customer,
the environment, the people doing the work and many
other factors. My choice — all thing being equal — is
the evolutionary approach.
2.6. Software applications that are relatively easy
to prototype almost always involve human-machine
interaction and/or heavy computer graphics. Other
prototyping are certain classes of mathematical
algorithms, subset of command driven systems and other
applications where results can be easily examined
without real-time interaction. Applications that are
difficult to prototype include control and process
applications and embedded software.
2.7. Any software project that has significant
functionality that must be delivered in a very tight
(too tight) time frame is a candidate for the
functionality in increments. Example: a sophisticated
software product that can be released to the
marketplace with only partial functionality—new and
improved versions to follow!
Any project in which tight time-lines and
delivery dates preclude delivery of full functionality
is a candidate for the incremental model. Also any
software product in which partial functionality may
still be saleable is a candidate.
2.9. As work moves outward on the spiral, the product
moves toward a more complete state and the level of
abstraction at which work is performed is reduced
(i.e., implementation specific work accelerates as we
move further from the origin).
2.10. I would suggest postponing this problem until
Chapter 27 is assigned, unless you do not intend to
assign it. In that case, it can serve to introduce the
importance of reuse.
2.11. Stated simply, the concurrent process model
assumes that different parts of a project will be a
different stages of completeness, and therefore,
different software engineering activities are all
being performed concurrently. The challenge is to
manage the concurrency and be able to assess the
status of the project.
2.12. An SQL, a spreadsheet, a CASE code generator,
graphical tools like VisualBasic, Powerbuilder, Web
page construction tools
2.13. The product is more important! That’s what
people use and what provides benefit to end users.
Project Management Concepts
CHAPTER OVERVIEW AND COMMENTS
This chapter discusses project management at a fairly general
level. The important point to get across is that all software
engineers are responsible for managing some portion of the
projects they work on. Modern software development is a very
complex undertaking that involves many people working over
long periods of time. The key to successful project management
is to focus on the four P's (people, product, process, and
project). Effective communication among customers and
developers is essential. The process selected must be
appropriate for the people and the product. The project must be
planned if the goal is to deliver high quality software, on time
and under budget.
The Management Spectrum
This section provides an overview of the four P's of project
management. The point to emphasize is that each the P's is
important and it is the synergy of all four working together that
yields the successful management of software products. This
also the time to remind students that it is customer for whom
the product is being developed. Process framework activities
are populated with tasks, milestones, work products, and
quality assurance checkpoints regardless of the project size. To
avoid project failure developers need react to warning signs and
focus their attention on practices that are associated with good
Companies that manage their people wisely prosper in the long
run. To be effective the project team must be organized in a
way that maximizes each person's skills and abilities. Effective
managers focus on problem solving and insist on high product
quality. Software teams may be organized in many different
ways. Two keys factors in selecting a team organizational model
are desired level of communication among its members and
difficulty level of the problems to be solved. Hierarchically
organized teams can develop routine software applications
without much communication among the team members.
Teams having a more democratic style organization often
develop novel applications more efficiently. It is important for
students to understand that the larger the team, the greater the
effort required to ensure effective
coordination of team member efforts.
3.3 The Problem
The first project management activity is the determination of
software scope. This is essential to ensure the product
developed is the product requested by the customer. It is
sometimes helpful to remind students that unless developers
and customers agree on the scope of the project there is no way
to determine when it ends (or when they will get paid).
Regardless of the process model followed, a problem must be
decomposed along functional lines into smaller, more easily
Once a process model is chosen, it needs to be populated with
the minimum set of work tasks and work products. Avoid
process overkill. It is important to remind students that
framework activities are applied on every project, no matter
how small. Work tasks may vary, but not the common process
framework. Process decomposition can occur simultaneously
with product decomposition as the project plan evolves.
The text lists 10 warning signs that indicate when a software
project is failing. Software engineers need to be on the watch for
them and take corrective action before failure occurs. Most
failures can be avoided by doing things right the first time and
avoiding the temptation to cut corners to try to shorten the
development cycle. Skipping process steps often has the effect
of lengthening the development time since the amount of work
usually increases. Taking time to reflect on how things went
once a project is over, is a good habit to develop in students
(who should be striving to avoid repeating their past mistakes
on future projects).
The W5HH Principle
Boehm's W5HH principle is a simple organizing tool that can
help both novice and experienced software engineers focus on
what is really important to include in a project management
plan. Boehm's questions are applicable to all software projects,
regardless of their size or complexity.
The Airlie Council list of project integrity critical practices
provides a good baseline for assessing how well a project team
understands its practices. Most of the items in this list will be
discussed in later chapters of the text. It may be helpful to have
students begin thinking about this list in the context of
developing their own project management plans. While this is
difficult undertaking for students early in the course, it does get
them thinking about the big picture without worrying about the
details of software implementation.
PROBLEMS AND POINTS TO PONDER
Thou shalt get smarter (provide education).
Thou shalt focus on quality.
Thou shalt listen to the customer.
Thou shalt understand the problem.
Thou shalt work within a repeatable process.
Thou shalt not agree to ridiculous schedules.
Thou shalt measure the product, the process and
Thou shalt document the work in the most
Thou shalt remember that others will also work on
10. Thou shalt continually improve
The latest SEI information can be obtained at:
3.3. Same person: (1) an engineer who must develop a
program for personal use; (2) a business person
creating a spreadsheet model for personal use; (3) an
entrepreneur who has a new concept for a killer App.
Different person: (1) an IS department servicing some
business function; (2) a software development group
servicing marketing needs; (3) a contractor building
to customer specs.
outsourcing have the most immediate and significant
impact. In addition, "expense reduction measures" that
lead to lower product quality; unrealistic project
deadlines; failure to "listen" to the customer, or
conversely, to warnings
engineers doing the work.
3.6. A controlled decentralized team is one option.
Since requirements are well defined, it will be
possible to partition requirements and allocation to
subteams. The large size of the project also mitigates
in favor of a CD team. Since there is no discussion of
schedule, we assume that delivery date is reasonable.
Therefore, it might be possible to use a linear
sequential process model (work has been done before).
However, an iterative model (e.g., spiral) is also a
3.7. The DD team is probably the only viable option,
given hazy requirements and the experimental nature of
the work. A prototyping approach or an evolutionary
process model should be used.
3.8. A CC team is probably best, given time pressure
and familiarity with the work (however, a CD team
might also work well). An incremental process model is
indicated by the deadline driven nature of this work.
3.9. A CD team is probably best, given that the work
is experimental, but that there is a business
deadline. Another possibility is to use a DD team. An
incremental process model or an evolutionary process
model could be used, given the deadline driven nature
of this work.
3.10. Much of the problem has to do with the structure
of documents and when they are created. Documents
should be kept lean and should be generated as
software engineering work is being conducted, NOT
after the fact. If this is done, the perceived value
of documents will improve.
3.11. The GradeAnalyzer application will obtain grades
for all undergraduate and graduate for-credit courses
contained in the Registrar’s data base of courses for
a given semester. GradeAnalyzer will read all grades
for each course and compute the average grade using a
numerical scale in which an A = 4.0 and other grades
are assigned values as indicated in grade value
document UC29-1. GradeAnalyzer will print and/or
display a report that lists each course, the
instructor, the average grade. The report may be
sorted by department, by highest to lowest average
grade, by instructor or by any permutation of these
characteristics. GradeAnalyzer will be implemented to
run under Microsoft Windows 200x environment.
3.12. A simple decomposition:
define page parameters
allocate text regions
allocate graphical regions
define emphasis (lines, shading, etc.)
end page layout
Software Process and Project Metrics
CHAPTER OVERVIEW AND COMMENTS
This chapter provides an introduction to the use of metrics as a
mechanism for improving the software development process
and managing software projects. A more complete discussion of
software quality assurance appears later in the text. The
concepts discussed in this chapter will be difficult for the
students to relate to prior to working on a large software
project. It is important to expose them to the reasons for using
metrics and so that they can appreciate their potential in
monitoring development costs and schedules on future projects.
Measures, Metrics, and Indicators
The important point to get across in this section is that
measures, metrics, and indicators are distinct (though related)
entities. A measure is established when a single data point is
collected. A software metric relates individual measures in a
meaningful way. An indicator is a metric or combination of
metrics that provide insight into the software project, process,
Metrics in the Process and Project Domains
Measurement is not used in software engineering work as often
as it is in other branches of engineering. Software engineers
have trouble agreeing on what to measure and have trouble
evaluating the measures that are collected. The point to get
across to the students is that the only rational way to improve a
process is to make strategic decisions based on metrics and
indicators developed from measurements of process attributes.
Students also need to understand the differences between
process metrics and project metrics. Process metrics are used to
make strategic decisions about how to complete the common
process framework activities. Project metrics are used to
monitor progress during software development and to control
In this section the differences between direct measures (e.g.
LOC or defects over time) and indirect measures (e.g.
functionality or quality) in software engineering are discussed.
Size-oriented metrics are derived by normalizing quality or
productivity measures over the product size (typically LOC or
KLOC). Students need to appreciate some weaknesses of LOC
as a measure (like language dependency). Some discussion
about what to count in LOC (e.g. executable statements) and
what not to count (e.g. comments) might be wise here.
Function points are presented as an example of a method of
indirectly measuring functionality using other direct measures.
Function points can be used to normalize software. Function
point values (FP) are easier for students to compute (prior to
implementation) than LOC for their projects. Function points
were originally developed for information systems applications.
Feature points and 3D function points are extensions of the
function point measures to engineering applications involving
real-time programming or process control.
Reconciling Different Metrics Approaches
This table presented in this section provides a good resource for
students to use when estimating LOC for their projects from
function points prior to writing the source code. Students
should be cautioned against the practice of backtracking (using
the table to compute function point from the LOC measure for a
completed program). A key point: using LOC or FP in project
estimation (discussed in Chapter 5) requires the existence of
baseline historical data.
Metrics for Software Quality
A detailed discussion of software quality assurance appears
later in the text. This section is intended to get students thinking
about the role of measurement to assess product quality and
process effectiveness during project development. Students
should also be made aware of the fact that the factors that
defined software quality in the 1970's (correctness,
maintainability, integrity, usability) continue to define software
quality today. Defect removal efficiency is an important
software quality metric that can useful at both the process and
Integrating Metrics within the Software Engineering Process
The fact that many software developers resist the use of
measurement to guide their work will make it hard to convince
students of its importance. However, the fact remains if
developers do not measure they have no means of determining
whether they are improving or not. Students need to
understand that many current practitioners are still self-trained
and may not be following the best development practices.
Current thinking among experienced software developers is
that process improvement is essential to remain competitive
economically. This cannot happen without means of repeating
past successes and avoiding inefficient development practices.
Managing Variation—Statistical Quality Control
A complete discussion of statistical process control is beyond
the scope of this text. However, the idea of using a control chart
to identify out of control processes is understandable to
students. Implicit in using this technique is the necessity of
having access to baseline historic metric data to compute the
standard deviations and means required to apply the zone
Metrics for Small Organizations
The important point in this section is that small projects and
small organizations can also benefit economically from the
intelligent use of software metrics. The key is to select metrics to
compute carefully and to ensure that the data collection process
is not to burdensome for the software developers.
Establishing a Software Metrics Program
This section discusses the steps needed to establish a goaldriven software metrics program. The important points are to
choose your business goals and to determine what you expect to
learn from the metrics program. The measures and derived
indicators used will need to answer questions related to the
attainment of these goals. It is also important to keep in mind
that the modern view of software quality assurance includes
customer satisfaction goals as well as product quality and
process improvement goals.
PROBLEMS AND POINTS TO PONDER
For an automobile:
weight, wheelbase, horsepower
metrics: max speed per quarter mile; breaking distance
at 30 mph; miles between schedule engine maintenance
defects per vehicle at delivery; cost per
vehicle at manufacture; parts per vehicle at manufacture
For a dealership:
measures: square feet of showroom
service bays; number of sales people
units sold per month;
salesperson; cars serviced per month
indicators: $ profit per sale; $ profit per service call;
number of repeat customers/total number of customers
4.3. A process metric is used to assess the activities
that are used to engineer and build computer software
(with the intent of improving those activities on
subsequent projects). A project metric is used to assess
the status of a software project.
4.4. Metrics should NOT be used as rewards or punishments
at an individual level. Hence, any metric that measures
individual productivity or quality should be private.
Group and process metrics may be public, as long as they
are not used for reprisals.
4.6. Additional rules of etiquette: (1) don’t look for
the perfect metric ... it doesn’t exist; (2) be sure to
comparisons are not made; (3) focus on quality, it’s
For the “missing” rib:
customer forgot requirement
customer not properly queried
customer misunderstands requirements
requirement inadvertently omitted
improper review techniques
analyst error or sloppiness
For the “ambiguous” rib:
improper review techniques
lack on specification training
misunderstanding of requirements
misunderstood or unclear requirement
customer not properly queried
customer misunderstands requirements
analyst misunderstands requirements
For the “change” rib:
legitimate business modification
correcting error in specification
correcting ambiguity in specification
4.8. An indirect measure is used when the characteristic
to be assessed cannot be measured directly. For example,
“quality” cannot be measured directly, but only by
measuring other software characteristics. Some examples:
number of pages
number of figures
number of distinct documents
readability (use the FOG index)
2. completeness (count the number of "help desk"
questions that you receive)
3. maintainability (time to make a documentation
Many metrics in software work are indirect because
dimensional or physical measures (e.g., length or weight)
can be applied.
4.9. The “size” or “functionality” of the software
produced by both teams would have to be determined. For
example, errors/FP would provide a normalized measure. In
addition, a metric such as DRE would provide an
indication of the efficiency of SQA within both teams’
4.10. LOC is weak because it rewards “verbose” programs.
It is also difficult to use in a world where visual
programming, 4GLs, code generators and other 4GTs are
moving development away from 3GLs.
4.11. Using the table noted in Figure 4.5 with average
values for complexity and average values for each CAF,
FP = 661.
4.12. Using the table noted in Figure 4.5 with average
values for complexity, and assuming that the weight for
transitions is 1 across all complexity values, we compute
905 3-D function points.
4.13. The backfiring technique can be used here. From the
table in Section 4.4,
Therefore, 32,000/128 + 4,200/20 = 250 + 210
= 460 FP (approximate)
4.16. "Spoilage" is defined as the cost to correct
defects encountered after the software has been released
to its end-users. It is possible for spoilage to increase
even though defects/KLOC decreases. This occurs when SQA
techniques have not found the “difficult” defects. These
consume large amounts of maintenance/rework time and
hence cost significantly more on average that less
4.17. No. The level of abstraction of most 4GLs is too
You might suggest that students implement the
calculations required for this problem (see Section
4.7) using a spreadsheet model. Results for this
Data should be plotted using the approach outlined in the
Software Project Planning
CHAPTER OVERVIEW AND COMMENTS
This chapter provides students with basic information on
planning software projects. Software planning involves
estimating how much time, effort, and resources are required to
build a software product. In most cases, there is enough
information provided in the text to allow students to estimate
their own projects and write their own planning documents.
Students should be assigned the task of using the planning
document template on the SEPA web site to write a planning
document as part of their coursework early in the semester.
Observations on Estimating
The point to get across in this section is that project estimation is
a difficult task to do without both historical data and a fair
amount of experience with the proposed application to draw on.
None the less, it is an activity that needs to be done for all
projects in order to begin the process of quality management.
Project complexity, project size, and structural uncertainties
affect the reliabilities of the estimates. The topic of risk
management is discussed more fully in the next chapter.
Project Planning Objectives
The objective of software project planning is providing a
framework that allows managers to make reasonable estimates
of the resources and time required to build a software product.
It is important to point out to the students that the more
information an estimator has, the better his or her estimates will
be. This is an important reason to update all estimates, as the
actual project costs and schedule become known as the project
Determining the scope of a software project is the first project
planning activity. Students need to understand that until the
developer and customer agree on the scope of the project it is
impossible to determine what the project will cost and when the
project will end. The best software practices call for the
customer and developer to work together to identify the
problem areas to be addressed and to negotiate different
approaches to their solutions. Once the project scope is
established, feasibility is the next issue to address. It is
sometimes hard for young software developers to recognize
that having the resources and capabilities needed to build a
system, does not always justify building it. The best interests of
the customer must come first, even if it means advising against
the creation of a new software product.
For software project work the resources used involve people,
reusable software components, the development environment
(hardware and software). The number of people required for
software projects can only be determined after an estimate of
development (e.g. person months) effort is computed. Students
may have a tough time relating to software reuse. Student are
either anxious to build their own software or naively believe
that all they need to do is browse the Internet for some code to
download. A more detailed discussion of component-based
software design and software reengineering appears later in the
text. In modern software development, people and hardware
may be shared among several projects. Time windows for
resource availability must be prescribed and planned for.
Software Project Estimation
Software is now the most costly element of virtually every
computer system. Cost and effort estimates may determine
whether an organization can realistically undertake the
development of software product or not. Software estimating
can never be an exact science, but even students can be taught
the steps needed to make estimates having acceptable risks
associated with them. It is important to get students used to the
idea or using 2 or more methods for making an estimate and
then using the results to cross check one another. Students
should be encouraged to reconcile the differences between
multiple estimates to improve their confidence in the values
This section compares two methods of performing software
sizing (directly by estimating LOC or indirectly using FP). The
function point method seems to be a little easier for students to
work with during the planing phase of their projects. The text
suggests using the expected value (3 point) method of adjusting
their software size estimates (either LOC or FP). It will be easier
for students to develop meaningful LOC or FP estimates if they
attempt to decompose their projects along functional lines and
then estimate the size of each subfunction individually. This
approach is called problem-based estimation. Process-based
estimation is also discussed in this section. Students often prefer
process-based estimation since they are estimating the amount
of time they plan spend on the tasks that make up each phase of
their process model after they have determined the work
products for each phase (several low cost PC scheduling tools
support this method, like MS Project). It may be wise to have
the students reconcile the results obtained from a problembased method like FP with their process-based estimates. It is
important to point out that without some historical data to give
these estimates a context LOC and FP values may not be very
useful for estimating cost or effort.
Empirical Estimation Models
This section describes the general process of creating and using
empirical cost estimation models. It may be wise to work
through an example showing how a simple linear regression
model is created from raw data and used to predict the value of
dependent variables from new data points. Most students have
not seen linear regression prior to this course and may not
appreciate how these models are built. The equations in these
models still require inputs like LOC or FP but users do not need
local project data to compute their estimates. Model users only
need to be confident that their project is similar to those used to
create the model in the first place. The complete details of
COCOMO II are not given in text and will need to be found on
the COCOMO web site. Similarly, the details of the Software
Equation will need to be located on the web.
5.8 The Make-Buy Decision
The make-buy decision is an important concern these days.
Many customers will not have a good feel for when an
application may be bought off the shelf and when it needs to be
developed. The software engineer needs to perform a cost
benefit analysis in order to give the customer a realistic picture
of the true costs of the proposed development options. The use
of a decision tree is a reasonable to organize this information.
Outsourcing is a popular idea for many companies these days.
The decision is usually motivated by the promise of reducing
costs. This promise may or may not prove to be true, if the
outside contractor handles the project management.
Automated Estimation Tools
This section lists some areas where automated estimation tools
might be useful to project planners. It is unfortunate that the
results obtained from different estimation tools show a wide
variance for the same project data. It is also true that the
predicted values are often significantly different from the actual
PROBLEMS AND POINTS TO PONDER
5.1. This is the first appearance of the SafeHome system
that will recur throughout the book. Even if you normally
don't assign homework, you might try this one. What
you're looking for is a reasonable work breakdown
structure, but your students will struggle because they
don't have a bounded scope. You can help them by defining
the basic characteristics of SafeHome (see later
chapters, use the SEPA index for pointers to the
established interface between the customer and the
software developer. Discounting that, the following
technical characteristics should be considered:
nature of the algorithm
requirement for recursion
nature of input
determinacy of input
nature of output
. . . and knowledge/experience of staff on application.
real time application—raw processing
measured by CPU time and possibly
accuracy and for large systems, CPU time.
commercial applications—I/O efficiency
interactive applications—user "wait time"
5.4. The SafeHome system is analyzed in detail in
Chapter 12. For our purposes here, we do a simple
user interaction (2400)
sensor monitoring (1100)
message display (850)
system configuration (1200)
system control [activation/deactivation] (400)
password processing (500)
LOC estimates (in the C language) for each function are
noted in parentheses. A total of 6450 LOC are estimated.
Using the data noted in the problem:
6450 LOC / 450 LOC/pm = 14.3 pm
14.3 pm * $7,000/pm = $100,000 (approximate)
5.5. Assuming that the SafeHome system is implemented in
C, we can use backfiring for a quick FP estimate:
6450 LOC / 128 LOC/FP = 50 FP (approximate)
5.7. Using the relationship noted in equations 5.4 (note
that this project is a bit small for these equations) and
the discussion that follows, assuming B=0.16, PP = 3,000,
= 8.14 (6450/3000)^0.43
= 8.14 * 1.38 = 11.31 months
= 180 * 0.16 * (0.94)^3
5.8. The estimates are all within a reasonable range
with the software equation representing the most
conservative estimate. Note however, that the SafeHome
project is small for software equations 5.4, therefore
putting this result in doubt.
Given the values computed in the above problems, it
likely that an estimate in the range 15 - 18 personmonths would be appropriate for this project.
5.9. The software equation predicts “no” but we may be
outside its bounds. Using the original COCOMO model (not
= 2.5 E ^ 0.35
= 2.5 * 16.92 ^ 0.35
= 6.7 person-months
It appears that 6 months is aggressive, but probably
size/complexity of the SafeHome project.
5.12. Costs and schedule are estimated early because such
information is demanded (by upper management) as early as
possible. If a project is extremely complex with high
technological risk and a fixed price proposal is to be
submitted, costing of the project should (if possible) be
delayed until after requirements analysis. Note: the cost
of requirements analysis alone can be estimated early.
CHAPTER OVERVIEW AND COMMENTS
This chapter defines the process of risk management and
explains why it is an important part of the planning process for
any software project. The text contains practical advice on how
to perform risk analysis and how to build risk mitigation,
monitoring, and management plans (RMMM). Students will
have a hard time relating to this material without seeing lots of
examples of software risks and techniques for managing them.
Having students write RMMM plans or risk information (RSI)
sheets for projects of their own design is an important part of
their learning this material.
Reactive vs. Proactive Risk Strategies
This section distinguishes between reactive and proactive risk
strategies. It is important for students to understand that
reactive strategies are usually not successful as a means of crisis
management. A better strategy is to anticipate the occurrence of
potential risks and to prepare plans for managing them before
they become problems that cause a project to fail.
Risks involve areas of uncertainty in the software development
process that have the potential to result in nontrivial losses to
the project. Most computing students will need help in
recognizing that software risks go beyond technical concerns
and also include the economic uncertainties that come with
marketing a piece of software. Students also need to be aware
that while most software risks can be identified prior to
beginning a project, some cannot. The fact remains that even if it
is impossible to manage all risks any planning is better than no
This section discusses the differences between identifying
generic risks and product-specific risks. Generic risks can be
listed on a checklist to examine for every software product.
Examining the project plan and the software statement of scope
identifies product-specific risks. Students may need to be shown
examples of software project risk checklists. The risk assessment
table shown in this section provides students with a good to
begin quantifying the impact of many types of risk.
Risk projection (estimation) attempts to associate with each risk
the likelihood (probability) of its occurrence and the
consequences of the resulting problems if the risk should occur.
The students should go though the process of creating risk
tables for projects of their own. Determining the probabilities
and quantitative impact measures will be very hard for them. It
may be wise to give them some heuristics for converting
qualitative statements into measures. If it is easier for them to
estimate costs to fix problems, then Halstead's risk exposure
(RE) might be helpful to use.
Risk refinement is the process of decomposing risks into more
detailed risks that will be easier to manage. Using the CTC
(condition-transition-consequence) format may be helpful to
students as they refine their own risks.
Risk Mitigation, Monitoring and Management
When teaching this section, it will be helpful to give students
examples of several types of risks and have the class discuss
detailed strategies for mitigation and management.
Contingency plans often benefit from brain storming activities.
This section also provides a chance to pitch the importance of
metrics as a source of indicators that can assist managers in risk
Safety Risks and Hazards
This section provides an opportunity to introduce a computing
ethics topic. Engineers are often entrusted with ensuring the
safety of the public and software engineers are not exempted
from this obligation. There are lots of stories in the media that
provide examples of critical software systems that failed with
dire consequences to people or businesses.
The RMMM Plan
The template RMMM plan appears on the text web site.
Students should be encouraged to examine its headings. An
important new point in this section is that risk monitoring also
includes tracing problems back to their points of origin (to do a
better job of mitigating this risk in the future).
PROBLEMS AND POINTS TO PONDER
6.1. Reactive risk management occur ‘once the horse has
left the barn.’ A few examples: putting a stop sign at a
dangerous corner only after a fatal accident has
occurred; fixing a pothole only after the city has been
sued by an angry motorist. In essence, we react instead
6.2. Known risks are those that are determine through
careful evaluation of the project and technology.
Predictable risks are extrapolated from past experience.
rapid changes in digital format for video data
changing compression algorithms and format
rapid changes in processing power and bus
rapid changes in video input modes (e.g., via
internet, direct from camera, across LAN, from
analog tape, from DAT)
All of the
6.5. Business risks here are probably the most relevant,
although your students will likely select technical and
project risks. Be sure to indicate that business risks
significant penetration problems); industry standard WPs
(e.g., MSWord) will cause reticence to buy, etc. may be
significantly more important than technical or project
6.6. Risk components indicate the four areas of impact
that will be affected by risk. That is, risk can impact
performance, cost, support, or schedule. Risk drivers are
the risks that will have a focused
impact on the risk
components. For example, some risks will have an affect
on schedule; other risks might drive the performance
sufficient. See Karolak for more detailed risk model with
more sophisticated weighting.
6.8 through 6.10. A single example of RMMM is provided
to illustrate the approach:
from table — “Lack of training on tools”
(1) Develop a training schedule for all
software staff that is “just-in-time.” That is, training
will be provided just before the tool is required for
use. (2) Have one or two experts on staff for each tool.
These people will be available to mentor others in the
use of the tool and answer questions.
(1) Log number of hours tools are being
used. (2) debrief staff to determine how tools are
perceived; whether frustration is setting in; (3) examine
work products created using tools for quality; (4)
determine time required to create work products using
tools vs. manual approach—look for anomalies.
Assumes that tools are not working.
Determine reasons why. If staff are untrained, then
provide one-to-one mentoring/training using staff experts
and vendor trainers (budget for this contingency). If
training is OK but tools don’t work, then consider
alternative work product generation approaches using a
semi automated approach, e.g., word processors and
graphical tool and a stripped down version of required
6.13. If a risk is high probability, high impact, but the
project team cannot do anything to mitigate, monitor, or
manage it, it should not appear in the risk table. For
example, if the company goes out of business in the
middle of the project, the impact is catastrophic. Assume
the probability of this is high, given outside business
pressures. The software project team will likely have no
control over the outcome.
6.14. The referent curve can be skewed to emphasize the
impact of either schedule risks or costs risks. In
general, schedule risks are more important. For example,
if a risk would result in a schedule delay that causes a
market window to be missed, the project must be cancelled
(no market for the product).
6.15. An excellent source of information
Leveson's book (see SEPA Chapter 8).
6.16. Any application area in which human life can be
affected by defects is a candidate: medical equipment,
avionics, power plant control (especially nuclear),
automobile control systems, radar. In addition, systems
that are involved in national security and systems that
Project Scheduling and Tracking
CHAPTER OVERVIEW AND COMMENTS
This chapter describes many of the issues associated with
building and monitoring schedules for software projects.
Students will need to be shown the process of building a
schedule for a case study to really understand how it's done.
They should be required to build a schedule for one of their
own projects early in the semester.
This section is intended to motivate the student's interest in
project scheduling by describing several reasons why software
projects are not completed on time. There is also a description of
a proactive way to deal with unrealistic customer deadlines
(based on detailed estimates and use of incremental
development to deliver critical functionality on time).
Scheduling is not a seat of the pants activity any more. There are
many excellent tools that can be used to make the process
easier. The basic idea to get across to the students is to break the
software project into well-defined tasks, determine the
interdependencies among the tasks, determine the time
duration for each task, and assign the tasks to project team
members. Each task must have defined outcomes and be
associated a meaningful project milestone.
The Relationship Between People and Effort
The most important point to get across in this section is that
adding people to a project in an arbitrary manner does not
reduce the project completion time (and may in fact lengthen
the completion time). There are times when a project schedule
has slipped so badly that adding people can not save it and the
only option a manager has is to renegotiate the completion date
with the customer. The effort distribution model presented in
this section is a good guideline for students to follow when they
build their first project schedules.
Defining a Task Set for the Software Project
A "task set" is a collection of engineering tasks, milestones, and
deliverables. The software process model selected for project
provides much guidance in determining the task set. Task set is
also dependent on the project type and degree of rigor desired.
Students should be familiar with the five project types described
in this section. The method used for determining degree of rigor
should be demonstrated for case study.
Selecting Software Engineering Tasks
This section points out that scheduling involves taking the
software engineering task set and distributing it on the project
time line. The details of how to do this will depend on whether
the software process model is linear, iterative, or evolutionary.
The example discussed in this section describes the major tasks
for a concept development project. It may be worthwhile to
show students the task sets from the adaptable process model
on the text web site.
Refinement of Major Tasks
This section contains an example of refining a major scheduling
task (concept scoping) into the smaller activities needed to
create a detailed project schedule. Students may need to see
additional examples of task refinement.
Defining a Task Network
Building a task graph or activity network is the key to building
a feasible schedule. The task graph represents inter-task
dependencies very clearly. This allows managers to determine
which tasks may be done in parallel and which tasks need to be
This section recommends the use of project scheduling tools for
any non-trivial project. The PERT (program evaluation and
review technique) and CPM (critical path method) are
mentioned in the section, but no examples are given. It may be a
good to show students a simple project activity graph and then
show them how to use CPM to determine the critical path and
compute minimum project completion time. Timeline (Gantt)
charts are fairly easy for students to understand and are often
available as output from scheduling tools like MS Schedule. The
time-boxing procedure described at the end of this section is a
time management strategy that students should made aware of.
Earned Value Analysis
Earned value analysis is an example of a quantitative technique
for monitoring project completion to date. If students are able to
estimate total project completion time they should be able to
compute the percentage of the total project time associated with
each project task. The progress indicators discussed in this
section are fairly easy for students to compute and interpret.
The important point to get across regarding error tracking is
that metrics need to be defined so that the project manager has a
way to measure progress and proactively deal with problems
before they become serious. This also implies the need have
historical project data to determine whether the current metric
values are typical or atypical at a given point in the
7.10 The Project Plan
This section merely reviews the purposes of the software project
plan. Three of these purposes are the presentation of project
costs, resource needs, and schedule. Students need to be aware
that the project plan needs to be updated (e.g. risks, estimates,
schedule, etc.) as a project proceeds and the team learns more
about the project itself.
PROBLEMS AND POINTS TO PONDER
7.1. Document your reservations using quantitative
arguments derived from past project metrics. Then suggest
an incremental approach (see Chapter 2) that offers to
deliver partial functionality in the time allotted with
complete functionality following.
7.2. A macroscopic schedule defines major activities and
tasks. It is the table of contents for the project and
may be sufficient for small efforts. For larger projects,
a detailed schedule, defining all work tasks, work
products, and milestones should be developed.
7.3. In most cases, milestones are tied to the review of
integration testing complete) may be tied to successful
completion of an integration test plan, rather than a
7.4. The reduction of rework is the key to your
argument. If good reviews reduce rework significantly, it
can be argued that the time spent on communication
(during reviews) results in time savings (due to less
rework) overall. The crux of this argument is as follows:
Typically, it costs more than 10 times as much to find
and correct an error during testing as it does to find
and correct the same error during, say, design.
Therefore, if one hour of communication finds one error
during design, it saves 10 hours of work later on. Big
7.5. If a project is compartmentalized and well
organized; if good documentation has been done; if
interfaces are clearly defined; if parallel tasks are
possible; if the people who are added are generally
competent; if newcomers can pick up what they need form
the configuration, rather than the software engineers
currently working on the project, you can add people to a
project without negative impact.
7.6. The relationship can be developed by solving for td
and varying the number of person months and duration as
Problems 7.7 through 7.11. Be sure that your students
first establish the scope of the OLCRS project. Depending
on requirements, this can become quite complex. An
alternative is for you to provide a requirements handout
so that everyone is working from the same scope.
development project should be chosen.
The project team should have at least three people.
This will force students to consider parallel activities.
A tool such as Microsoft Project will be extremely
useful to illustrate important concepts.
Use the steps defined in Section 7.8 to computer
earned value. First sum all planned effort through
SV = BCWP - BCWS = 127.5 - 126.5 = 1.0 person-day
Other earned-value data are computed in the same
Software Quality Assurance
CHAPTER OVERVIEW AND COMMENTS
This chapter provides an introduction to software quality
assurance (SQA). It is important to have the students
understand that software quality work begins before the testing
phase and continues after the software is delivered. The role of
metrics in software management is reinforced in this chapter.
An important concept in this section is that controlling variation
among products is what quality assurance work is all about.
Software engineers are concerned with controlling the variation
in their processes, resource expenditures, and the quality
attributes of the end products. The definitions of many quality
concepts appear in this section. Students need to be familiar
with these definitions, since their use in software quality work
does not always match their use in casual conversation.
Students also need to be made aware that customer satisfaction
is every bit as important to modern quality work as is quality of
design and quality of conformance.
The Quality Movement
Total quality management (TQM) is described in this section.
TQM stresses continuous process improvement and can be
applied to software development. The most important point
made in the section is that until a visible, repeatable, and
measurable process is created not much can be done to improve
Software Quality Assurance
This section describes software quality as conformance to
explicitly stated requirements and standards, as well as implicit
characteristics that customers assume will be present in any
professionally developed software. The SQA group must look at
software from the customer's perspective, as well as assessing
its technical merits. The activities performed by the SQA group
involve quality planning, oversight, record keeping, analysis
and reporting. SQA plans are discussed in more detail later in
This section describes the purposes of conducting software
reviews. It is important to point out to students that any work
product (including documents) should be reviewed. Students
are usually impressed by the fact that conducting timely
reviews of all work products can often eliminate 80% of the
defects before any testing is conducted. This message often
needs to be carried to managers in the field, whose impatience
to generate code sometimes makes them reluctant to spend time
Formal Technical Reviews
The mechanics of conducting a formal technical review (FTR)
are described in this section. Students should pay particular
attention to the point that it is the work product that is being
reviewed not the producer. Encouraging the students to
conduct formal reviews of their development projects is a good
way to make this section more meaningful. Requiring students
to generate review summary reports and issues lists also helps
to reinforce the importance of the review activities.
8.6 Formal Approaches to SQA
This section merely introduces the concept of formal methods in
software engineering. More comprehensive discussions of
formal specification techniques and formal verification of
software appear Chapters 25 and 26.
Statistical Quality Assurance
Statistical quality assurance is beyond the scope of this text.
However, this section does contain a high level description of
the process and gives examples of metrics that might be used in
this type of work. The key points to emphasize to students are
that each defect needs to be traced to its cause and that defect
causes having the greatest impact on the success of the project
must be addressed first.
Software reliability is discussed in this section. It is important to
have the students distinguish between software consistency
(repeatability of results) and reliability (probability of failure
free operation for a specified time period). Students should be
made aware of the arguments for and against applying
hardware reliability theory to software (e.g. a key point is that,
unlike hardware, software does not wear out so that failures are
likely to be caused by design defects). It is also important for
students to be able to make a distinction between software
safety (identifying and assessing the impact of potential
hazards) and software reliability.
A Software Quality Assurance Approach
This section describes the use of poka-yoke devices as
mechanisms that lead to the prevention of potential quality
problems or the rapid detection of quality problems introduced
into a work product. Examples of poka-yoke devices are given,
but students will need to see others (a web reference is given in
8.10 The ISO 9000 Quality Standards
The ISO 9000 quality standard is discussed in this section as an
example of quality model that is based on the assessment of
quality of the individual processes used in the enterprise as a
whole. ISO 9001 is described as the quality assurance standard
that contains 20 requirements that must be present in any
software quality assurance system.
8.11 The SQA Plan
The major sections of a SQA plan are described in this section. It
would advisable to have students write a SQA plan for one of
their own projects sometime during the course. This will be a
difficult task for them. It may be advisable to have the students
look at the material in Chapters 17-19 (testing and technical
metrics) before beginning this assignment.
In addition to the review checklists contained within the SEPA
Web site, I have also included a small sampler in the special
section that follows.
Formal technical reviews can be conducted during each step in the software
engineering process. In this section, we present a brief checklist that can be
used to assess products that are derived as part of software development.
The checklists are not intended to be comprehensive, but rather to provide a
point of departure for each review.
System Engineering. The system specification allocates function and
performance to many system elements. Therefore, the system review
involves many constituencies that may each focus on their own area of
concern. Software engineering and hardware engineering groups focus on
software and hardware allocation, respectively. Quality assurance assesses
system level validation requirements and field service examines the
requirements for diagnostics. Once all reviews are conducted, a larger review
meeting, with representatives from each constituency, is conducted to ensure
early communication of concerns. The following checklist covers some of the
more important areas of concern.
Are major functions defined in a bounded and unambiguous fashion?
Are interfaces between system elements defined?
Have performance bounds been established for the system as a whole
and for each element?
Are design constraints established for each element?
Has the best alternative been selected?
Is the solution technologically feasible?
Has a mechanism for system validation and verification been
Is there consistency among all system elements?
Software Project Planning. Software project planning develops estimates
for resources, cost and schedule based on the software allocation established
as part of the system engineering activity. Like any estimation process,
software project planning is inherently risky. The review of the Software
Project Plan establishes the degree of risk. The following checklist is
Is software scope unambiguously defined and bounded?
Is terminology clear?
Are resources adequate for scope?
Are resources readily available?
Have risks in all important categories been defined.
Is a risk management plan in place?
Are tasks properly defined and sequenced? Is parallelism reasonable
given available resources?
Is the basis for cost estimation reasonable? Has the cost estimate been
developed using two independent methods?
Have historical productivity and quality data been used?
Have differences in estimates been reconciled?
Are pre-established budgets and deadlines realistic?
Is the schedule consistent?
Software Requirements Analysis. Reviews for software requirements
analysis focus on traceability to system requirements and consistency and
correctness of the analysis model. A number of FTRs are conducted for the
requirements of a large system and may be augmented by reviews and
evaluation of prototypes as well as customer meetings. The following topics
are considered during FTRs for analysis:
Is information domain analysis complete, consistent and accurate?
Is problem partitioning complete?
Are external and internal interfaces properly defined?
Does the data model properly reflect data objects, their attributes and
Are all requirements traceable to system level?
Has prototyping been conducted for the user/customer?
Is performance achievable within the constraints imposed by other
Are requirements consistent with schedule, resources and budget?
Are validation criteria complete?
Software Design. Reviews for software design focus on data design,
architectural design and procedural design. In general, two types of design
reviews are conducted. The preliminary design review assesses the translation
of requirements to the design of data and architecture. The second review,
often called a design walkthrough, concentrates on the procedural correctness
of algorithms as they are implemented within program modules. The
following checklists are useful for each review:
Preliminary design review
Are software requirements reflected in the software architecture?
Is effective modularity
Is the program architecture factored?
Are interfaces defined for modules and external system elements?
Is the data structure consistent with information domain?
Is data structure consistent with software requirements?
Has maintainability considered?
Have quality factors (section 17.1.1) been explicitly assessed?
Does the algorithm accomplishes desired function?
Is the algorithm logically correct?
Is the interface consistent with architectural design?
Is the logical complexity reasonable?
Have error handling and "anti-bugging" been specified?
Are local data structures properly defined?
Are structured programming constructs used throughout?
Is design detail amenable to implementation language?
Which are used: operating system or language dependent features?
Is compound or inverse logic used?
Has maintainability considered?
Coding. Although coding is a mechanistic outgrowth of procedural design,
errors can be introduced as the design is translated into a programming
language. This is particularly true if the programming language does not
directly support data and control structures represented in the design. A
code walkthrough can be an effective means for uncovering these translation
errors. The checklist that follows assumes that a design walkthrough has
been conducted and that algorithm correctness has been established as part
of the design FTR.
Has the design properly been translated into code? [The results of the
procedural design should be available during this review.]
Are there misspellings and typos?
Has proper use of language conventions been made?
Is there compliance with coding standards for language style,
comments, module prologue?
Are there incorrect or ambiguous comments?
Are data types and data declaration proper?
Are physical constants correct?
Have all items on the design walkthrough checklist been re-applied (as
Software Testing. Software testing is a quality assurance activity in it own
right. Therefore, it may seem odd to discuss reviews for testing. However,
the completeness and effectiveness of testing can be dramatically improved
by critically assessing any test plans and procedures that have been created.
In the next two Chapters, test case design techniques and testing strategies
are discussed in detail.
Have major test phases properly been identified and sequenced?
Has traceability to validation criteria/requirements been established as
part of software requirements analysis?
Are major functions demonstrated early?
Is the test plan consistent with overall project plan?
Has a test schedule been explicitly defined?
Are test resources and tools identified and available?
Has a test record keeping mechanism been established?
Have test drivers and stubs been identified and has work to develop
them been scheduled?
Has stress testing for software been specified?
Have both white and black box tests been specified?
Have all independent logic paths been tested?
Have test cases been identified and listed with expected results?
Is error-handling to be tested?
Are boundary values to be tested?
Are timing and performance to be tested?
Has acceptable variation from expected results been specified?
In addition to the formal technical reviews and review checklists noted
above, reviews (with corresponding checklists) can be conducted to assess
the readiness of field service mechanisms for product software; to evaluate
the completeness and effectiveness of training; to assess the quality of user
and technical documentation, and to investigate the applicability and
availability of software tools.
Maintenance. The review checklists for software development are equally
valid for the software maintenance phase. In addition to all of the questions
posed in the checklists, the following special considerations should be kept
Have side effects associated with change been considered?
Has the request for change been documented, evaluated and
Has the change, once made, been documented and reported to
Have appropriate FTRs been conducted?
Has a final acceptance review been conducted to ensure that all software
has been properly updated, tested and replaced?
PROBLEMS AND POINTS TO PONDER
8.1. We look for variation in the traceability from
requirements to design and design to code. We assess the
variation in the form and content of work products. We
look for variation in the process — repeatable process is
a goal. We look for variation in expected and actual
results derived from software testing.
8.2. In reality, if we define quality as "conformance to
changing), the definition of quality will be dynamic and
an assessment of quality will be difficult.
8.3. Quality focuses on the software's conformance to
explicit and implicit requirements. Reliability focuses
on the ability of software to function correctly as a
function of time or some other quantity. Safety considers
the risks associated with failure of a computer-based
system that is controlled by software. In most cases an
assessment of quality considers many factors that are
qualitative in nature. Assessment of reliability and to
some extent safety is more quantitative, relying on
statistical models of past events that are coupled with
software characteristics in an attempt to predict future
operation of a program.
8.4. Yes. It is possible for a program to conform to all
explicit functional and performance requirements at a
given instant, yet have errors that cause degradation
that ultimately causes the program to fail.
together or otherwise "kludged up" so that they work, yet
these program exhibit very low quality if measured by
most of the criteria described in Figure 17.1.
8.6. There is often a natural "tension" that exists
between these two groups. The reason is simple: if the
SQA group takes on the role of the "watch dog," flagging
quality problems and high-lighting shortcomings in the
developed software, it is only normal that this would not
be embraced with open arms by the software engineering
group. As long as the tension does not degenerate into
hostility, there is no problem. It is important to note,
however, that a software engineering organization should
work to eliminate this tension by encouraging a team
approach that has development and QA people working
together toward a common goal—high quality software.
8.7. Institute formal technical reviews. After these are
working smoothly, any of a number of SQA activities might
be implemented: change control and SCM (see Chapter 9);
comprehensive testing methodology (see Chapters 16 and
17); SQA audits of documentation and related software.
Also software metrics can help (Chapters 4, 18, and 23)
8.8. Any countable measure that indicates the factors
noted in Chapter 18 are candidates. For example,
maintainability as measured by mean-time-to-change;
portability as measured by an index that indicates
conformance to language standard; complexity as measured
by McCabe's metric, and so on.
8.9. Typically, an unprepared reviewer will be reading
the product materials while everyone else is conducting
the review; will be especially quiet throughout the
review; will have made no annotation on product
materials; will make only very general comments; will
focus solely on one part (the part he/she read) of the
product materials. As a review leader, you should ask if
the person has had time to prepare. If most reviewers
have not prepared, the review should be cancelled and
Assessing style is tricky and can lead to bad
feelings if a reviewer is not careful when he/she makes
comments concerning style. If the producer gets the
feeling that the reviewer is saying, "Do it like I do,"
it is likely that some resentment will arise. In general,
the review should focus on correctness.
spreadsheet model using a table like Table 8.2 and the
equations discussed in Section 8.7 to do the necessary
8.13 The May, 1995 and January, 1996 issues of IEEE
Software have useful articles.
For hardware the MTBF concept is based on
statistical error data that occurs due to physical wear
in a product. In general, when a failure does occur in
hardware, the failed part is replaced with a spare.
However, when an error occurs for software, a design
change is made to correct it. The change may create side
effects that generate other errors. Therefore, the
statistical validity of MTBF for software is suspect.
Classic examples include aircraft
systems, control systems for nuclear power
instrumentation (e.g., CAT scanners or MRI
control systems for trains or subway systems;
8.17 device: Develop a simple parsing algorithm that
will detect common errors in e-mail addresses (e.g., bad
detection device: recognize an e-mail message that has no
content (e.g., e-mail text is null)
See the SEPA Web site for links to ISO sites.
Software Configuration Management
CHAPTER OVERVIEW AND COMMENTS
This chapter presents a high level overview of the issues
associated with software configuration management, version
control, and change control. It will not be easy to convince
students of the importance of these topics, unless your course
happens to include a term long project that involves interaction
with a real customer. Most introductory software engineering
courses are not set up this way. One way to reinforce the
importance of configuration management (without a real
customer) would be to change the project requirements
sometime after students have begun its implementation.
Software Configuration Management
This section defines software configuration items as programs,
documentation, and data. Students need to be aware that
changes can occur to any of these items during the course of a
project. The impact of these changes can have a negative ripple
affect throughout a project, if they are not controlled properly.
The concept of a baseline configuration item as being something
that has very tightly defined change procedures is important for
students to understand.
The SCM Process
Software configuration management (SCM) is defined as having
change control as its primary responsibility. SCM is also
concerned with auditing the software configuration and
reporting all changes applied to the configuration. The next
sections cover the five SCM tasks in more detail.
Identification of Objects in the Software Configuration
This section advocates the use of an object-oriented approach to
managing the software configuration items once they are
identified. Students who are unfamiliar with the concepts of
object-oriented programming and/or the use of E-R diagrams
may struggle with the concepts introduced here. It may be
desirable to review some of the object-oriented programming
concepts from Chapter 20 while covering this chapter.
It is important for students to be able to distinguish between the
terms version and variant. It is also important for students to
get in the habit of incorporating the version number in the
naming scheme used for their SCI's.
This section discusses the details of processing and controlling a
change request for an SCI. Students need to be familiar with
each of the major steps. Having students write change requests
and engineering change orders (ECO) are worthwhile
assignments. The process of item check-in and check-out from
the project data base might be illustrated by having students use
a Unix tool like SCCS or an MS Windows tool like Visual
SourceSafe. It is important for students to understand the
distinction between informal change control and the formal
change control required for a baseline SCI.
This section contains a list of questions that need to be answered
during a configuration audit. Students might profit from the
experience of doing (or observing) a configuration audit using
these questions following an assignment involving a required
change to one of their projects.
This section suggests that software engineers develop a need to
know list for every SCI and keep them up to date. This is
probably the easiest and most reliable way to deal with the
configuration status reporting task.
9.8 SCM Standards
Several military and ANSI/IEEE software configuration
standards are listed in this section. It may be worthwhile to
have students do library or web research to locate the details for
one of them.
PROBLEMS AND POINTS TO PONDER
9.1. Because change is a fact of life, it is necessary
to recognize that iteration occurs in all paradigms for
software engineering. The biggest danger is to assume
sequentially from start to finish with no changes. This
just is not realistic!
9.2. We have to establish a point at which we "cut the
chord." That is, we must define a point beyond which we
will not change something without careful (even formal)
evaluation and approval.
9.3. A small project might combine analysis and design
modeling into a "Development Specification" that would
serve as the first SCI. The source would be the second.
It is unlikely that a formal Test Specification would be
created, but the suite of test cases would be the third
SCI. A User's manual would likely be the fourth SCI and
executable versions of the software would be the fifth.
Any change to these baseline SCIs might generate
the following questions:
What are the effort and cost required?
How complex is the
the software that is to be changed
to other components of the system?
Are the modules to be changed cohesive?
What is likely to happen
What is the relative importance of this change as
compared to other requested changes?
Who will make the change?
How can we be sure that the change is implemented
9.4. Any book on database design would provide pointers
9.8. Other relationships:
9.12. An SCM audit focuses on compliance with software
engineering standards while an FTR concentrates on
uncovering errors associated with function, performance
or constraints. The audit has a less technological feel.
CHAPTER OVERVIEW AND COMMENTS
This chapter provides an introduction to the process of system
engineering. The emphasis is on requirement analysis,
specification, and quality management. Simple examples of
system modeling are presented. More detailed discussion of
system representation (e.g. data flow diagrams) appears later in
10.1 Computer-Based Systems
This section introduces the systems view of engineering (all
complex systems can be viewed as being composed of
cooperating subsystems). The elements of computer-based
systems are defined as software, hardware, people, database,
documentation, and procedures. Software engineering students
find it difficult to think about system elements other than
software when they begin to develop their first projects. It is
important to get students in the habit of taking time to
understand the all the elements of the systems in which their
software products will reside.
10.2 The System Engineering Hierarchy
The key to system engineering is a clear understanding of
context. For software development this means creating a "world
view" and progressively narrowing its focus until all technical
detail is known. It is important to get students in the habit of
recognizing the importance of developing alternative solutions
to problems. In software engineering there is rarely one right
way of doing something. Instead designers must consider the
tradeoffs present in the feasible solutions and select one that
seems advantageous for the current problem. This section lists
several factors that need to be examined by software engineers
simplifications, limitations, constraints, and preferences). This
section also cautions students that developing reactive systems
without some simulation capability is a risky practice.
10.3 Business Process Engineering: An Overview
Software engineers usually do not participate in the upper
levels of business process engineering (information strategy
planning and business area analysis). Student projects usually
begin with the assumption that this work has been done and is
understood by the customer. Students need to believe that it is
important for software engineers to understand the results of
the system engineering that has taken place prior to beginning
the definition of the requirements for a specific information
system to support a particular business application.
10.4 Product Engineering: An Overview
Product engineering is described as the task of translating a
customer's desires for a set of capabilities into a working
product. Software engineers participate in all levels of the
product engineering process that begins with requirements
engineering. The analysis step maps requirements into
representations of data, function, and behavior. The design step
maps the analysis model into data, architectural, interface, and
software component designs. Detailed discussion of analysis
and design techniques appears in the next several chapters of
10.5 Requirements Engineering
This section describes the process of requirements engineering
detail, from requirement elicitation through requirement
management. Students need to experience the process of
working with a customer to develop the requirements for a
software product before they graduate. It is hard for students to
do this in a one-semester software engineering course, but they
should do this as part of a senior design project. Trying to
understand customers' needs and negotiating changing
requirements is part of every software development project.
Students also need to experience the opportunity to judge the
feasibility of solutions and steering the customer toward options
that can be completed with the resources available. This section
provides an opportunity to reinforce quality assurance and
configuration management concepts discussed previously.
Students should be encouraged to develop and use traceability
tables on their own projects.
10.6 System Modeling
This section describes a system modeling technique that is
based on developing a hierarchical system model that has a
system context diagram (SCD) as its root. This model is based
on the notion of an information transform using an inputprocessing-output template. The SDC provides a big picture of
the system, even when all details are not known. The process of
building a system flow diagram (SFD) is similar to building a
data flow diagram (DFD). Data flow diagrams are not discussed
in detail until Chapter 12, so it is probably better to hold off on a
discussion of DFD's until later in the course.
Chapter 10 begins with Machiavelli's quote on the
dangers associated with the introduction of a "new order". It
might be worthwhile to project how computer-based
systems will introduce a "new order" in the first decade of
the 21st century. You might use Toeffler, Naisbitt, or
Negroponte as guidelines for these discussions. Topics could
include: the Internet (personal privacy and e-commerce),
intelligent agents, artificial reality, artificial intelligence,
office automation, education, warfare, medicine, voice
recognition, robots, vision systems, personal digital
assistants, appliance computers, DVD/MP3, networks, and
data warehousing issues.
PROBLEMS AND POINTS TO PONDER
10.1. Use a large dictionary to present the many
definitions of the word. A thesaurus may help. Good
10.2. You might suggest the following systems for the
An on-line bank
A retail store
An e-commerce site
10.3. Suggest that the student draw a hierarchy
similar to those represented in Figures 10.1 through
10.5. The data architecture refers to corporate data,
its organization, and the relationships between
individual corporate data elements. For example, a
telephone billing system might draw on elements that
include customer information, rate tables, calling
logs and so forth. Application architecture defines
the functional hierarchy that is required to realize
the goals and objectives of a large information
10.6. A business objective for a software products
vendor might be to “get the customer written
information about our products within 4 hours of
receipt of inquiry.” The following goals would be
improve system that integrate telephone sales to
make better use of the internet/e-mail and web
make better use of automated instant response
10.7. There is less likelihood of miscommunication
when the developer is the system engineer, but there
is high likelihood of “creeping enhancements” and the
possibility of building a system that doesn’t meet
customer’s needs because perceptions of need are
incorrect. When the customer is the system engineer,
the is the likelihood that technical issues may be
omitted, but it is likely that customer need will be
more accurately reflected. When an outside third party
is the system engineering, communication bandwidth
between developer and customer must be very high. It’s
likely that things will fall into the cracks. However,
the third party may be an expert, hence better overall
quality of the system model. The ideal system engineer
is technically expert in system engineering, has full
understanding of the customer business/product domain,
and understands the development environment (and leaps
tall buildings in a single bound!).
10.8. Additional questions:
Couldn't sorting occur as the boxes were packed?
Is the number of different parts (and boxes)
likely to increase or decrease?
Are all boxes the same size and weight?
What is the environment in which this system
will sit (e.g., corrosive, high temperature, dusty,
Allocations: (4) Bar code reader and PC. PC prints
destination on screen and a human operator does the
placement into the bin; (5) Human reads box and speaks
controls and automated shunt.
The checklist should answer one global
"Can we do it?" An example checklist
relevant staff experience
projected degree of change
percent "new" technology
availability of resources
In addition to the above items, other
considered in the book should also be added.
A "feasibility number could be calculated
assigned a numeric grade (in the range 1 to 5, say)
each attribute and a weight (same range) to be used
a multiplier for the grade. The feasibility number
the sum of the products of grade x weight.
Suggest that your students obtain one or
more books on business and/or project management. The
following titles should be useful:
Degarmo, E.P, et al, Engineering Economy, 7th edition,
DeMarco, T., Controlling Software Projects, Yourdon
Management, Addison-Wesley, 1988.
Gunther, R.C., Management Methodology
Product Engineering, Wiley, 1978.
Londiex, B., Cost Estimation for Software Development,
Page-Jones, M., Practical Project Management, Dorset
House Publishing, New York, 1985.
Although the ACD is not used widely in
industry, it is a worthwhile mechanism for getting
student to understand the interaction between various
components of a computer based system, If time
permits, I would strongly recommend that you go
through this notation in class and have your student
try this problem.
You may, if you choose, allow students to
derive their own System Specification for any of the
systems shown without any handout. However, it is
relatively easy to acquire a general article or paper
that will serve as a consistent basis for student
work. Alternatively, require that students research
attributes of one of the systems, then develop the
specification is impossible early in a project. In
some of these, it is necessary to prototype before a
formal specification can be developed. Examples are:
sophisticated analytical models that must be
researched and developed—delay until requirements
specification or even design!
interfaces—delay until requirements, but no later!
requirements, but no later!
In many instances, a computer-based system is
actually a "software only" system. That is, an
existing standard computer, operating system and I/O
environment are to be used. In such cases, the System
Specification can be eliminated in lieu of a Software
There are also situations in which a system
prototype (either real or paper) is much more
effective than a specification.
Analysis Concepts and Principles
CHAPTER OVERVIEW AND COMMENTS
This chapter describes the process of software requirements
analysis as a refinement of the initial work products developed
during the systems engineering process. It is important that
students be encouraged to complete a system specification
document, before beginning to write a software specification
document for their own course projects. The focus of software
requirements analysis is on working with the customer to
identify and refine the information, functional, and behavioral
requirements for the proposed software solution to the
11.1 Requirements Analysis
Software requirements analysis is intended to bridge the gaps
between system requirements engineering and software design.
In this chapter the focus of software requirements analysis is on
the process of modeling the data, function, and performance of
the software to be developed. The process model used has five
areas of effort: problem recognition; evaluation and synthesis;
modeling; specification; and review. It is important to remind
students that requirements analysis is an important part of the
software configuration management plan and the software
quality assurance plan.
11.2 Requirements Elicitation for Software