Determine the Kind of Software

You’re Working On
Capers Jones, Chief Scientist at Software Productivity
Research, summarized 20 years of software research
by pointing out that he and his colleagues have seen
❖ 40 different methods for gathering requirements,
❖ 50 variations in working on software designs,
❖ 30 kinds of testing applied to projects in more
than 700 different programming languages
❖ On real projects, you’ll find infinite variations on
the three themes presented

❖ Business systems projects tend to benefit from

highly iterative approaches, in which planning,
requirements.
❖ Life-critical systems tend to require more
sequential approaches—

❖ Requirements stability is part of what’s needed

to ensure ultrahigh levels of reliability
Iterative Approaches’ Effect on
Prerequisites
⚫ Consider the examples shown in Table of
projects that don’t focus on prerequisites.

⚫ One project is conducted sequentially and

relies solely on testing to discover
defects; the other is conducted iteratively
and discovers defects as it progresses.
⚫ The first approach delays most defect
correction work to the end of the
project, making
⚫ the costs higher, as noted in Table 3-1.
Choosing Between Iterative and
Sequential Approaches
⚫ You might choose a more sequential
approach when
⚫ ■ The requirements are fairly stable.
⚫ ■ The design is straightforward and fairly
well understood.
⚫ ■ The development team is familiar with
the applications area.
Problem-Definition Prerequisite
⚫ The first prerequisite you need to fulfill
before beginning construction is a clear
statement of the problem that the system
is supposed to solve. This is sometimes
called

⚫ “product vision,” “vision statement,”

“mission statement,” or “product
definition.”

⚫ Here it’s called “problem definition.”

❖ A problem definition defines what the
problem is without any reference to
possible solutions.

❖ It’s a simple statement, maybe one or two

pages, and it should sound like a problem.
⚫ The problem definition should be in user
language.
⚫ And the problem should be described
from a user’s point of view.
⚫ It usually should not be stated in technical
computer terms.
⚫ The best solution might not be a
computer program. Suppose you need
a report that shows your annual profit.
Requirements Prerequisite
Requirements describe in detail what a
software system is supposed to do, and
they are the first step toward a solution.
The requirements activity is also known as
“requirements development,”
“requirements analysis,” “analysis,”
“requirements definition,” “software
requirements,” “specification,” “functional
spec,” and “spec.
Why Have Official
Requirements?
⚫ Explicit requirements help to ensure that the
user rather than the programmer drives
⚫ The system’s functionality. If the requirements
are explicit, the user can review them and
agree to them.
⚫ If they’re not, the programmer usually ends up
making requirements decisions during
programming.
⚫ Explicit requirements keep you from guessing
what the user wants.
⚫ Paying attention to requirements helps to
minimize changes to a system after
development begins.

⚫ If you find a coding error during coding,

you change a few lines of code and work
goes on
⚫ If you find a requirements error during
coding, you have to alter the design to
meet the changed requirement.
⚫ You might have to throw away part of the
old design,
⚫ And because it has to accommodate
code that’s already written, the new
design will take longer than it would have
in the first place
❖ Explicit requirements also help to
avoid arguments. You decide on
the scope of the system before
you begin programming.

❖ If you have a disagreement with

another programmer about what
the program is supposed to do,
you can resolve it by looking at
the written requirements.
❖ Paying attention to requirements helps to
minimize changes to a system after
development begins.
❖ If you find a coding error during coding,
you change a few lines of code and work
goes on.
❖ If you find a requirements error during
coding, you have to alter the design to
meet the changed requirement.
The Myth of Stable Requirements
❖ Stable requirements are the holy grail of
software development.

❖ With stable requirements, a project can

proceed from architecture to design to
coding to testing in a way that’s orderly,
predictable, and calm.
⚫ It’s fine to hope that once your customer has
accepted a requirements document, no
changes will be needed.

⚫ On a typical project, however, the customer

can’t reliably describe what is needed before
the code is written.

⚫ The problem isn’t that the customers are a

lower life form. Just as the more you work
with the project, the better you

⚫ Understand it, the more they work with it, the

better they understand it
Handling Requirements Changes During Construction

Use the requirements checklist at the end of

the section to assess the quality of your
requirements

Make sure everyone knows the cost of

requirements changes

Set up a change-control procedure

Use development approaches that

accommodate changes

Dump the project

Keep your eye on the business case for the

project
Checklist: Requirements
The requirements checklist contains a list
of questions to ask yourself about
your project’s requirements.

❖ Functional Require requirements

❖ Non-functional Requirements
Specific Functional Requirements
⚫ ❑ Are all the inputs to the system specified, including their source, accuracy,
range of values, and frequency?
⚫ ❑ Are all the outputs from the system specified, including their destination,
accuracy, range of values, frequency, and format?
⚫ ❑ Are all output formats specified for Web pages, reports, and so on?
⚫ ❑ Are all the external hardware and software interfaces specified?
⚫ ❑ Are all the external communication interfaces specified, including handshaking,
error-checking, and communication protocols?
⚫ ❑ Are all the tasks the user wants to perform specified?
⚫ ❑ Is the data used in each task and the data resulting from each task specified?
Specific Nonfunctional (Quality) Requirements
⚫ ❑ Is the expected response time, from the user’s point of view,
specified for all necessary operations?
⚫ ❑ Are other timing considerations specified, such as processing time,
data transfer rate, and system throughput?
⚫ ❑ Is the level of security specified?
⚫ ❑ Is the reliability specified, including the consequences of software
failure,
⚫ the vital information that needs to be protected from failure, and the
strategy for error detection and recovery?
⚫ ❑ Are minimum machine memory and free disk space specified?
⚫ ❑ Is the maintainability of the system specified, including its ability to
adapt to changes in specific functionality, changes in the operating
environment, and changes in its interfaces with other software?
⚫ ❑ Is the definition of success included? Of failure?
Architecture Prerequisite

⚫ Architecture is also known as “system

architecture,” “high-level design,” and
“top-level design.” Typically, the
architecture is
⚫ Described in a single document referred
to as the “architecture specification” or
“top level design.”
Why have architecture as a
prerequisite?
⚫ Because the quality of the architecture determines the
conceptual integrity of the system. That in turn determines
the ultimatequality of the system.
⚫ A well-thought-out architecture provides the structure
needed to maintain a system’s conceptual integrity from the
top levels down to the bottom.
⚫ It provides guidance to programmers at a level of detail
appropriate to the skills of the programmers and to the job
at hand.
⚫ It partitions the work so that multiple developers or
multiple development teams can work independently.
❖ Architectural changes are expensive to
make during construction or later.

❖ The time needed to fix an error in a

software architecture is on the same
order as that needed to fix a
requirements error—that is, more than
that needed to fix a coding error .
Typical Architectural Components

❖ Many components are common to good

system architectures.
❖ If you’re building the whole system
yourself, your work on the architecture
will overlap your work on the more
detailed design.
Here are some Architecture
components.
Program Organization
❖ A system architecture first needs an overview
that describes the system in broad terms.
❖ The architecture should define the major
building blocks in a program.
❖ Depending on the size of the program, each
building block might be a single class or it
might be a subsystem consisting of many
classes
Major Classes
❖ The architecture should specify the major
classes to be used.
❖ It should identify the responsibilities of
each major class and how the class will
interact with other classes.
❖ It should include descriptions of the class
hierarchies, of state transitions, and of
object persistence.
❖ If the system is large enough, it should
describe how classes are
❖ organized into subsystems
Data Design
⚫ The architecture should describe the major
files and table designs to be used.
⚫ It should describe alternatives that were
considered and justify the choices that were
made.
⚫ The architecture should specify the high-level
organization and contents of any databases
used.
⚫ The architecture should explain why a single
database is preferable to multiple databases
(or vice versa)
Business Rules
❖ If the architecture depends on specific business rules, it
should identify them and describe the impact the rules have
on the system’s design.
User Interface Design
❖ The user interface is often specified at requirements time. If
it isn’t, it should be specified in the software architecture.
The architecture should specify major elements .

❖ Web page formats, GUIs, command line interfaces, and so

on. Careful architecture of the user interface makes the
difference between a well-liked program and one that’s
never used.
Resource Management
⚫ The architecture should describe a plan for
managing scarce resources such as database
connections, threads, and handles.
• Memory management is another important
Area for the architecture to treat in
memory-constrained applications areas such as
⚫ driver development and embedded systems.
.
Security

⚫ The architecture should describe the approach

to design-level and code-level security.
If a threat model has not previously been built, it
should be built at architecture time.
Coding
⚫ Guidelines should be developed with security
implications in mind, including approaches to
handling buffers,
Performance
❖ If performance is a concern, performance
goals should be specified in the
requirements.

❖ Performance goals can include resource

use, in which case the goals should also
specify priorities among resources,
including speed vs. memory vs. cost.
Scalability

⚫ Scalability is the ability of a system to

grow to meet future demands. The
architecture
⚫ should describe how the system will
address growth in number of users,
number of
⚫ servers, number of network nodes,
number of database records, size of
database
⚫ records, transaction volume, and so on.
Interoperability
❖ If the system is expected to share data or
resources with other software or hardware,
the architecture should describe how that will
be accomplished.
Internationalization/Localization
❖ “Internationalization” is the technical activity
of preparing a program to support multiple
locales.
❖ “Localization” is the activity of translating a
program to support a specific local language.
Input/Output
⚫ Input/output (I/O) is another area that
deserves attention in the architecture.

⚫ Architecture should specify a look-ahead,

look-behind, or just-in-time reading
scheme.

⚫ And it should describe the level at which

I/O errors are detected: at the field,
record, stream, or file level.
⚫ Error handling is often treated as a
coding-convention-level issue,
⚫ But because it has systemwide
implications, it is best treated at the
architectural level.
⚫ Here are some questions to consider:
Here are some questions to consider:

⚫ Is error processing corrective or merely

detective?
⚫ Is error detection active or passive?
⚫ How does the program propagate errors?
⚫ How will exceptions be handled?
⚫ Inside the program, at what level are
errors handled?
Fault Tolerance
⚫ The architecture should also indicate the
kind of fault tolerance expected.
⚫ Fault tolerance is a collection of
techniques that increase a system’s
reliability by detecting errors,
⚫ Recovering from them if possible, and
containing their bad effects if not.
For example, a system could make the computation of
the square root of a number
fault tolerant in any of several ways:
⚫ ■ The system might back up and try again when
it detects a fault.
⚫ If the first Answer is wrong, it would back up to a
point at which it knew everything was all right
and continue from there.
⚫ ■ The system might have auxiliary code to use if
it detects a fault in the primary code.
⚫ In the example, if the first answer appears to be
wrong, the system switches over to an
alternative square-root routine and uses it
instead.
⚫ ■ The system might use a voting algorithm. It might
have three square-root classes
⚫ That each use a different method. Each class
computes the square root, and then
⚫ The system compares the results. Depending on the
kind of fault tolerance built into the system, it then
uses the mean, the median, or the mode of the three
results.
⚫ ■ The system might replace the erroneous value
with a phony value that it knows
⚫ to have a benign effect on the rest of the system.
Architectural Feasibility
⚫ The designers might have concerns about
a system’s ability to meet its performance
targets, work within resource limitations, or
be adequately supported by the
implementation environments.
Overengineering
⚫ Robustness is the ability of a system to
continue to run after it detects an error.
Often an architecture specifies a more
robust system than that specified by the
requirements.
Checklist: Architecture
⚫ Is the overall organization of the program clear, including a good
architectural overview and justification?
⚫ ❑ Are major building blocks well defined, including their areas of
responsibility and their interfaces to other building blocks?
⚫ ❑ Are all the functions listed in the requirements covered sensibly, by
neither
⚫ too many nor too few building blocks?
⚫ ❑ Are the most critical classes described and justified?
⚫ ❑ Is the data design described and justified?
⚫ ❑ Is the database organization and content specified?
⚫ ❑ Are all key business rules identified and their impact
 Amount of Time to Spend on Upstream Prerequisites
The amount of time to spend on problem definition,
requirements, and software architec_x0002_ture varies
according to the needs of your project.
Generally, a well-run project devotes
About 10 to 20 percent of its effort and about 20 to 30
percent of its schedule to requirements, architecture, and
up-front planning
If requirements are unstable and you’re working on a large,
formal project, you’ll probably have to work with a
requirements analyst to resolve requirements problems that
are identified early in construction.
⚫ If requirements are unstable and you’re
working on a small, informal project, you’ll
probably need to resolve requirements
issues yourself. Allow time for defining the
requirements well enough that their
volatility will have a minimal impact on
construction.
⚫ Checklist: Upstream Prerequisites
⚫ ❑ Have you identified the kind of software project
you’re working on and tailored your approach
appropriately?
⚫ ❑ Are the requirements sufficiently well defined and
stable enough to begin
⚫ ❑ Is the architecture sufficiently well defined to
begin construction?
⚫ ❑ Have other risks unique to your particular
project been addressed, such
⚫ that construction is not exposed to more risk than
necessary?
Key Construction Decisions
⚫ Choice of Programming Language
⚫ The programming language in which the
system will be implemented should be of
⚫ great interest to you since you will be
immersed in it from the beginning of
construc_x0002_tion to the end.
⚫ Studies have shown that the
programming-language choice affects
productivity and
⚫ code quality in several ways.
⚫ Programmers are more productive using a
familiar language than an unfamiliar one.
⚫ Data from the Cocomo II estimation
model shows that programmers working
in a lan_x0002_guage they’ve used for
three years or more are about 30 percent
more productive than
⚫ programmers with equivalent experience
who are new to a language
⚫ Programmers working with high-level
languages achieve better productivity and
quality
⚫ than those working with lower-level
languages. Languages such as C++, Java,
Smalltalk,
⚫ and Visual Basic have been credited with
improving productivity, reliability,
simplicity
Language Descriptions
⚫ Ada
⚫ Ada is a general-purpose, high-level
programming language based on Pascal. It
was developed under the aegis of the
Department of Defense and is especially
well suited to real-time and embedded
systems.
⚫ Assembly Language
⚫ Assembly language, or “assembler,” is a
kind of low-level language in which each
state_x0002_ment corresponds to a
single machine instruction.
Programming Conventions
⚫ In high-quality software, you can see a
relationship between the conceptual
integrity of the architecture and its
low-level implementation.
⚫ The implementation must be consistent
with the architecture that guides it and
consistent internally.
⚫ In a complex program, architectural
guidelines give the program structural
balance and construction guidelines
provide low-level harmony, articulating
each class as a faithful part of a
comprehensive design.
⚫ Any large program requires a controlling
structure that unifies its
programming-language details.
Selection of Major Construction
Practices
⚫ Part of preparing for construction is
deciding which of the many available good
practices you’ll emphasize.
⚫ Some projects use pair programming and
test-first development, while others use
solo development and formal inspections.