Ivan Marsic  Rutgers University 62

2.1 Software Development Methods

“Plan, v.t. To bother about the best method of accomplishing an accidental result.”
—Ambrose Bierce, The Devil’s Dictionary

The goal of software methodologists is to understand how high quality software can be developed
efficiently. The hope is that new insights will emerge about effective product development, so
both students and experts might benefit from learning and applying methodology. Ideally, the
developer would adhere to the prescribed steps and a successful project would result—regardless
of the developer’s knowledge and expertise. Methodology development often works by observing
how expert developers work and deriving an abstract model of the development process. In
reality, life cycle methods are often not followed; when they are, it is usually because of
employer’s policy in place. Why is it so, if following a method should be a recipe for success?
There are several reasons why methodologies are ignored or resisted in practice. One reason is
that methodology is usually derived from past experience. But, what worked for one person may
not work for another. Both developers and projects have different characteristics and it is difficult
to generalize across either one. Software development is so complex that it is impossible to create
precise instructions for every scenario. In addition, method development takes relatively long
time to recognize and extract “best practices.” By the time a method is mature, the technologies it
is based on may become outdated. The method may simply be inappropriate for the new and
emerging technologies and market conditions.
A development method usually lays out a prescriptive process by mandating a sequence of
development tasks. Some methods devise very elaborate processes with a rigid, documentation-
heavy methodology. The idea is that even if key people leave the project or organization, the
project should go on as scheduled because everything is properly documented. This approach is
known as “Big Design Up Front” (BDUF). However, experience teaches us that it is impossible
to consider all potential scenarios just by thinking. And, regardless of how well the system is
documented, if key people leave, the project suffers. It is much more sensible to develop initial
versions of the system-to-be from a partial understanding of the problem, let users play with such
a prototype, and then redesign and develop a new iteration based on the gained understanding.
One difficulty with product development is that when thinking about a development plan,
engineer usually thinks in terms of methodology: what to do first, what next, etc. Naturally, first
comes discovery (studying the problem domain and finding out how the problem is solved now
and proposing how it can be solved better with the to-be-developed technology); then comes
development (designing and implementing the system); lastly, the system is deployed and
evaluated. This sequential thinking naturally leads to the “waterfall model” (Section 1.2) and
heavy documentation.
The customer does not see it that way. The customer would rather see some rudimentary
functionality soon, and then refinement and extension.
Recent methods, known as agile, attempt to deemphasize process-driven documentation and
detailed specifications. They also consider the number and experience of the people on the
development team.
Four major software development methodologies can be classified as:
Chapter 2  Object-Oriented Software Engineering 63

 Structured analysis and design (SAD), developed in late 1960s and 1970s
 Object-oriented analysis and design (OOAD), developed in 1980s and 1990s
 Agile software development (ASD), developed in late 1990s and 2000s
 Aspect-oriented software development (AOSD), developed in 2000s
The structured analysis and design (SAD) methodology emerged in the 1970s and introduced
functional decomposition and data-flow analysis as key modeling tools.
The object-oriented analysis and design (OOAD) methodology emerged in the late 1980s and was
widely adopted by the mid 1990s. It introduced use cases and the Unified Modeling Language
(UML) as key modeling tools.
The ideas of agile software development (ASD) emerged at the end of 1990s and rapidly gained
popularity in the software industry as a “lightweight” way to develop software. Agile
development is reviewed in Section 2.1.1.
The aspect-oriented software development (AOSD) methodology emerged in the late 1990s. It is
not a replacement for any of the other methodologies. Rather, it helps deal with scattered
crosscutting concerns. Functional features of a software system could be divided into two
categories: (1) core features that provide basic functionality and allow the end-user to achieve
specific business goals; and, (2) supplementary features that provide support for entitlements,
connectivity, concurrency, system interface, etc. Many of the complementary features can be
scattered across the application and tangled with core features, which is why they are called
crosscutting concerns. By “tangled” I mean that these crosscutting concerns are invoked in the
context of core features and are part of the affected core functionality. Aspect-oriented software
development helps deal with crosscutting concerns in a systematic manner.

2.1.1 Agile Development

“People forget how fast you did a job—but they remember how well you did it.” —An advertising executive
“Why do we never have time to do it right, but always have time to do it over?” —Anonymous

Agility is both a development philosophy and a collection of concepts embedded into

development methodologies. An agile approach to development is essentially a results-focused
method that iteratively manages changes and risks. It also actively engages customers in
providing feedback on successive implementations, in effect making them part of the
development team. Unlike process-driven documentation, it promotes outcome-driven
documentation. The emphasis of agile practices is on traveling lightweight, producing only those
artifacts (documentation) that are absolutely necessary. The philosophy of the agile approach is
formulated by the Manifesto for Agile Software Development (http://agilemanifesto.org/).
Agile development evangelists recommend that the development should be incremental and
iterative, with quick turnover, and light on documentation. They are believers in perfection being
the enemy of innovation. Agile methods are not meant to entirely replace methodologies such as
structured analysis and design, or object-oriented analysis and design. Rather, agile methods are
often focused on how to run the development process (“project management”), perhaps using the
tools for software development inherited from other methods, but in a different way. A popular
Ivan Marsic  Rutgers University 64

agile-development tool is user stories, which are intended to represent the system requirements,
estimate effort and plan software releases (Section 2.2.3).
SIDEBAR 2.1: Agile vs. Sloppy
 I have had students complain that demanding readability, consistency, and completeness in
project reports runs against the spirit of agile development. Some software engineering
textbooks insist on showing snapshots of hand drawn UML diagrams, as opposed to neat
diagrams created electronically, to emphasize the evanescent nature of designs and the need for
dynamic and untidy artifacts. This may work for closely knit teams of professionals, working
in adjacent offices exclusively on their project. But, I found it not to be conducive for the
purpose of grading student reports: it is very difficult to discern sloppiness from agility and
assign grades fairly. Communication, after all, is the key ingredient of teamwork, and
communication is not improved if readability, consistency, and completeness of project reports
are compromised. I take it that agility means: reduce the amount of documentation but not at
the expense of the communicative value of project artifacts. Brevity is a virtue, but we also
know that redundancy is the most effective way to protect the message from noise effects. (Of
course, you need to know the right type of redundancy!)

Agile methodologists seem not to have much faith in visual representations, so one can find few
if any graphics and diagrams in agile software development books. Some authors take the agile
principles to the extreme and I would caution against this. I have seen claims that working code is
the best documentation of a software product. I can believe that there are people for whom
program code is the most comprehensible document, but I believe that most people would
disagree. Most people would find easiest to understand carefully designed diagrams with
accompanying narrative in a plain natural language. Of course, the tradeoff is that writing proper
documentation takes time, and it is difficult to maintain the documentation consistent with the
code as the project progresses.
Even greater problem is that the code documents only the result of developer’s design decisions,
but not the reasoning behind those decisions. Code is a solution to a problem. It is neither a
description of the problem, nor of the process by which the problem was solved. Much of the
rationale behind the solution is irretrievably lost or hidden in the heads of the people who chose
it, if they are still around. After a period of time, even the person who made a design decision
may have difficulty explaining it if the reasons for the choice are not explicitly documented.
However, although documentation is highly desirable it is also costly and difficult to maintain in
synchrony with the code as the lifecycle progresses. Outdated documentation may be source of
confusion. It is said that the code is the only unambiguous source of information. Such over-
generalizations are not helpful. It is like saying that the building itself is the only unambiguous
source of information and one need not be bothered with blueprints. You may not have blueprints
for your home or even not know where to find them, but blueprints for large public buildings are
carefully maintained as they better be. After all, it is unethical to leave a customer with working
code, but without any documentation. There is a spectrum of software projects, so there should be
a matching spectrum of documentation approaches, ranging from full documentation, through
partial and outdated one, to no documentation. I believe that even outdated documentation is
better than no documentation. Outdated documents may provide insight into the thinking and
evolution that went into the software development. On most projects, documentation should be
created with the understanding that it will not always be up to date with the code, resulting in
Chapter 2  Object-Oriented Software Engineering 65

“stale” parts. A discrepancy usually arises in subsequent iterations, so we may need to prioritize
and decide what to keep updated and what to mark as stale.
There are other issues with maintaining adequate documentation. The developer may even not be
aware of some choices that he made, because they appear to be “common sense.” Other decisions
may result from company’s policies that are documented separately and may be changed
independently of the program documentation. It is useful to consider again the exponential curve
in Figure 1-13, which can be modified for documentation instead of estimation. Again, a
relatively small effort yields significant gains in documentation accuracy. However, after a
certain point the law of diminishing returns triggers and any further improvement comes at a
great cost. It is practically impossible to achieve perfect documentation.
SIDEBAR 2.2: How Much Diagramming?
 I often hear inquiries and complaints that the amount of diagramming in this book is
excessive. This book is primarily intended for students learning software engineering and
therefore it insists on tidiness and comprehensiveness for instructive purposes. If I were doing
real projects, I would not diagram and document every detail, but only the most difficult and
important parts. Unfortunately, we often discover what is “difficult and important” only long
after the project is completed or after a problem arises. Experience teaches us that the more
effort you invest in advance, the more you will be thankful for it later. The developer will need
to use their experience and judgment as well as contextual constraints (budget, schedule, etc.)
to decide how much diagramming is appropriate.

Many books and software professionals place great emphasis on the management software
engineering projects. In other words, it is not about the engineering per se but it is more about
how you go about engineering software, in particular, knowing what are the appropriate steps to
take and how you put them together. Management is surely important, particularly because most
software projects are done by teams, but it should not be idolized at the detriment of product
quality. This book focuses on techniques for developing quality software.

2.1.2 Decisive Methodological Factors

Software quality can be greatly improved by paying attention to factors such as traceability,
testing, measurement, and security.

Traceability
Software development process starts with an initial artifact, such as customer statement of work,
and ends with source code. As the development progresses, being able to trace the links among
successive artifacts is key. If you do not make explicit how an entity in the current phase evolved
from a previous-phase entity, then it is unclear what was the purpose of doing all that previous
work. Lack of traceability renders the past creations irrelevant and we might as well have started
with this phase. It makes it difficult for testers to show that the system complies with its
requirements and maintainers to assess the impact of a change. Therefore, it is essential that a
precise link is made from use cases back to requirements, from design diagrams back to use
cases, and from source code back to design diagrams. Traceability refers to the property of a
software artifact, such as a use case or a class, of being traceable to the original requirement or
Ivan Marsic  Rutgers University 66

rationale that motivated its existence. Traceability must be maintained across the lifecycle.
Maintaining traceability involves recording, structuring, linking, grouping, and maintaining
dependencies between requirements and other software artifacts. We will see how traceability
works on examples in this chapter.
Requirements Use Cases Concepts/Objects Source Code

UC-1 CO-1 Code-1

Req-1
CO-2 Code-2
UC-2

CO-3 Code-3

UC-M CO-S Code-W

Req-K

UC-N CO-T Code-X

Requirements
Engineering Use Cases OOA/OOD Implementation
(Section 2.2) (Section 2.3) (Sections 2.4 & 2.5) (Section (2.7)

Testing
The key idea of Test-Driven Development (TDD) is that every step in the development process
must start with a plan of how to verify that the result meets some goal. The developer should not
create a software artifact (such as a system requirement, a UML diagram, or source code) unless
he has a plan of how it will be tested. For example, a requirement is not well-specified if an
automated computer program cannot be written to test it for compliance. Such a requirement is
vague, subjective, or contradictory and should be reworked.
The testing process is not simply confined to coding. Testing the system design with
walkthroughs and other design review techniques is very helpful. Agile TDD methodology
prescribes to make progress just enough to pass a test and avoid detailed analysis. When a
problem is discovered, fix it. This approach may not be universally appropriate, e.g., for mission
critical applications. Therein, when a problem is discovered, it might have led to a major human
or economic loss. Discovering that you missed something only when system failed in actual use
may prove very costly. Instead, a thorough analysis is needed in advance of implementation.
However, the philosophy of thinking while creating a software artifact about how it will be tested
and designing for testability applies more broadly than agile TDD.
Software defects (or, bugs) are typically not found by looking at source code. Rather, defects are
found by mistreating software and observing how it fails, by reverse engineering it (approach
used by people who want to exploit its security vulnerabilities), and by a user simply going about
his business until discovering that a program has done something like delete all of the previous
hour’s work. Test plans and test results are important software artifacts and should be preserved
along with the rest of software documentation. More about testing in Section 2.7.
Chapter 2  Object-Oriented Software Engineering 67

Agile TDD claims to improve the code, and detect design brittleness and lack of focus. It may
well do that, but that is not the main purpose of testing, which is to test the correctness, not
quality of software. Even a Rube-Goldberg design can pass tests under the right circumstances.
And we cannot ever check all circumstances for complex software systems. Therefore, it would
be helpful to know if our system works correctly (testing) and if it is of high quality, not a Rube-
Goldberg machine. This is why we need software measurement.

Measurement
While testing is universally practiced and TDD widely adopted, metrics and measurement are
relatively rarely used, particularly for assessing software product quality. Agile methods have
emphasized using metrics for project estimation, to track progress and plan the future iterations
and deliverables. Software product metrics are intended to assess program quality, not its
correctness (which is assessed by testing and verification). Metrics do not uncover errors; they
uncover poor design.
More about software measurement in Chapter 4.

Security
Most computers, telephones, and other computing devices are nowadays connected to the public
Internet. Publicly accessible Web applications and services can be abused and twisted to
nefarious ends. Even if the computer does not contain any “sensitive” information, its computing
and communication resources may be abused to send out spam and malware as part of a
distributed botnet. Such hijacked systems provide a “safe” means of distribution of illicit goods or
services on someone else’s server without that person’s knowledge. Because of ubiquitous
connectivity, anyone’s security problems impact everyone else, with only rare exceptions.
There are two kinds of technology-based security threats in software systems. One arises because
of bad software, where the attacker exploits software defects. The other arises because of network
interconnectedness, when the attacker exploits other infected systems to poison the traffic to or
from targeted computers. Hence, even if software is designed with security features to prevent
unauthorized use of system resources, it may be denied data or services from other computers.
Attackers rely on exploitable software defects as well as continuing to develop their own
infrastructure. An experienced developer must understand both the principles of software design
and the principles of network security. Otherwise, he will be prone to making naïve mistakes
when assessing the security benefits of a particular approach to software development. This book
focuses on better software design and does not cover network security.
The Security Development Lifecycle (SDL), promoted by Microsoft and other software
organizations, combines the existing approaches to software development with security-focused
activities throughout the development lifecycle. Security risk management focuses on minimizing
design flaws (architectural and design-level problems) and code bugs (simple implementation
errors in program code). Identifying security flaws is more difficult than looking for bugs,
because it requires deep understanding of the business context and software architecture and
design. We work to avoid design flaws while building secure software systems. Techniques
include risk analysis, abuse cases (trying to misuse the system while thinking like an attacker),
and code quality auditing.
Ivan Marsic  Rutgers University 68

Functional security features should not be confused with software security. Software security is
about developing high quality, problem-free software. Functional security features include
cryptography, key distribution, firewalls, default security configuration, privilege separation
architecture, and patch quality and response time. Poorly designed software is prone to security
threats regardless of built-in security functionality. Security functionality design is detailed in
Section 5.5.

2.2 Requirements Engineering

“The hardest single part of building a software system is deciding what to build. No part of the work so
cripples the resulting system if done wrong. No other part is more difficult to rectify later.”—Fred Brooks
“You start coding. I’ll go find out what they want.” —Computer analyst to programmer

Requirements engineering helps software engineers understand the problem they are to solve. It
involves activities that lead to understanding the business context, what the customer wants, how
end-users will interact with the software, and what the business impact will be. Requirements
engineering starts with the problem definition: customer statement of work (also known as
customer statement of requirements). This is an informal description of what the customers think
they need from a software system to do for them. The problem could be identified by
management personnel, through market research, by ingenious observation, or some other means.
The statement of work captures the perceived needs and, because it is opinion-based, it usually
evolves over time, with changing market conditions or better understanding of the problem.
Defining the requirements for the system-to-be includes both fact-finding about how the problem
is solved in the current practice as well as envisioning how the planned system might work. The
final outcome of requirements engineering is a requirements specification document.
The key task of requirements engineering is formulating a well-defined problem to solve. A well-
defined problem includes
 A set of criteria (“requirements”) according to which proposed solutions either definitely
solve the problem or fail to solve it
 The description of the resources and components at disposal to solve the problem.
Requirements engineering involves different stakeholders in defining the problem and specifying
the solution. A stakeholder is an individual, team, or organization with interests in, or concerns
related to, the system-to-be. Generally, the system-to-be has several types of stakeholders:
customers, end users, business analysts, systems architects and developers, testing and quality
assurance engineers, project managers, the future maintenance organization, owners of other
systems that will interact with the system-to-be, etc. The stakeholders all have a stake, but the
stakes may differ. End users will be interested in the requested functionality. Architects and
developers will be interested in how to effectively implement this functionality. Customers will
be interested in costs and timelines. Often compromises and tradeoffs need to be made to satisfy
different stakeholders.