MODULE-3 AGILE DEVELOPMENT

3 MODELING PRINCIPLES
We create models to gain a better understanding of the actual
entity to be built.
In software engineering work, two classes of models can be
created: requirements models and design models.
Requirements models (also called analysis models) represent
customer requirements by depicting the software in three different
domains: the information domain, the functional domain, and the
behavioral domain.
Design models represent characteristics of the software that help
practitioners to construct it effectively: the architecture, the user
interface, and component-level detail.
Scott Ambler and Ron Jeffries define a set of modeling principles that
are intended for those who use the agile process model but are
appropriate for all software engineers who perform modeling actions
and tasks:
Principle 1. The primary goal of the software team is to build software,
not create models. Agility means getting software to the customer in
the fastest possible time. Models that make this happen are worth
creating, but models that slow the process down or provide little new
insight should be avoided.
Principle 2. Travel light—don’t create more models than you need.
Every model that is created must be kept up-to-date as changes
occur. Therefore, create only those models that make it easier and
faster to construct the software
Principle 3. Strive to produce the simplest model that will describe
the problem or the software. Don’t overbuild the software. By
keeping models simple, the resultant software will also be simple.
Principle 4. Build models in a way that makes them amenable to
change. Assume that your models will change, but in making this
assumption don’t get sloppy.
Principle 5. Be able to state an explicit purpose for each model that
is created. Every time you create a model, ask yourself why you’re
doing so. If you can’t provide solid justification for the existence of
the model, don’t spend time on it.
Principle 6. Adapt the models you develop to the system at hand. It
may be necessary to adapt model notation or rules to the
application; for example, a video game application might require a
different modeling technique than real-time, embedded software
that controls an automobile engine.
Principle 7. Try to build useful models, but forget about building
perfect models. When building requirements and design models, a
software engineer reaches a point of diminishing returns. That is,
the effort required to make the model absolutely complete and
internally consistent is not worth the benefits of these properties.
Principle 8. Don’t become dogmatic about the syntax of the model.
If it communicates content successfully, representation is
secondary. Although everyone on a software team should try to use
consistent notation during modeling, the most important
characteristic of the model is to communicate information that
enables the next software engineering task. If a model does this
successfully, incorrect syntax can be forgiven.
Principle 9. If your instincts tell you a model isn’t right even though
it seems okay on paper, you probably have reason to be concerned.
If you are an experienced software engineer, trust your instincts.
Software work teaches many lessons—some of them on a
subconscious level. If something tells you that a design model is
doomed to fail (even though you can’t prove it explicitly), you have
reason to spend additional time examining the model or developing
a different one
Principle 10. Get feedback as soon as you can. Every model should
be reviewed by members of the software team. The intent of these
reviews is to provide feedback that can be used to correct modeling
mistakes, change misinterpretations, and add features or functions
that were inadvertently omitted
REQUIREMENTS MODELING PRINCIPLES.

Analysis methods are related by a set of operational principles:

Principle 1. The information domain of a problem must be
represented and understood. The information domain encompasses
the data that flow into the system, the data that flow out of the
system , and the data stores that collect and organize persistent
data objects.
Principle 2. The functions that the software performs must be
defined. Software functions provide direct benefit to end users and
also provide internal support for those features that are user
visible. Some functions transform data that flow into the system.
Principle 3. The behavior of the software (as a consequence of
external events) must be represented. The behavior of computer
software is driven by its interaction with the external environment.
Input provided by end users, control data provided by an external
system, or monitoring data collected over a network all cause the
software to behave in a specific way.
Principle 4. The models that depict information, function, and
behavior must be partitioned in a manner that uncovers detail in a
layered (or hierarchical) fashion. Requirements modeling is the first
step in software engineering problem solving. It allows you to
better understand the problem and establishes a basis for the
solution (design). A large, complex problem is divided into
subproblems until each subproblem is relatively easy to
understand. This concept is called partitioning or separation of
concerns, and it is a key strategy in requirements modeling
Principle 5. The analysis task should move from essential
information toward implementation detail. Requirements modeling
begins by describing the problem from the end-user’s perspective.
The “essence” of the problem is described without any
consideration of how a solution will be implemented. For example,
a video game requires that the player “instruct” its protagonist on
what direction to proceed as she moves into a dangerous maze.
DESIGN MODELING PRINCIPLES.

The software design model is analogous to an architect’s plans for a house. It

begins by representing the totality of the thing to be built (e.g., a three-
dimensional rendering of the house) and slowly refines the thing to provide
guidance for constructing each detail (e.g., the plumbing layout). Similarly, the
design model that is created for software provides a variety of different views of
the system.
There is no shortage of methods for deriving the various elements of a software
design.
Some methods are data driven, allowing the data structure to dictate the
program architecture and the resultant processing components. Others are
pattern driven, using information about the problem domain (the requirements
model) to develop architectural styles and processing patterns. Still others are
object oriented, using problem domain objects as the driver for the creation of
data structures and the methods that manipulate them. Yet all embrace a set of
design principles that can be applied regardless of the method that is used
Principle 1. Design should be traceable to the requirements model.
The requirements model describes the information domain of the
problem, user-visible functions, system behavior, and a set of
requirements classes that package business objects with the
methods that service them. The design model translates this
information into an architecture, a set of subsystems that
implement major functions, and a set of components that are the
realization of requirements classes. The elements of the design
model should be traceable to the requirements model.
Principle 2. Always consider the architecture of the system to be
built. Software architecture (Chapter 9) is the skeleton of the
system to be built. It affects interfaces, data structures, program
control flow and behavior, the manner in which testing can be
conducted, the maintainability of the resultant system, and much
more. For all of these reasons, design should start with
architectural considerations. Only after the architecture has been
established should component-level issues be considered
Principle 3. Design of data is as important as design of processing
functions. Data design is an essential element of architectural
design. The manner in which data objects are realized within the
design cannot be left to chance. A well-structured data design helps
to simplify program flow, makes the design and implementation of
software components easier, and makes overall processing more
Principle 4. Interfaces (both internal and external) must be
designed with care. The manner in which data flows between the
components of a system has much to do with processing efficiency,
error propagation, and design simplicity. A well-designed interface
makes integration easier and assists the tester in validating
component functions
Principle 5. User interface design should be tuned to the needs of
the end user. However, in every case, it should stress ease of use.
The user interface is the visible manifestation of the software. No
matter how sophisticated its internal functions, no matter how
comprehensive its data structures, no matter how well designed its
architecture, a poor interface design often leads to the perception
that the software is “bad.”
Principle 6. Component-level design should be functionally
independent. Functional independence is a measure of the “single-
mindedness” of a software component. The functionality that is
delivered by a component should be cohesive—that is, it should
focus on one and only one function or subfunction.5
Principle 7. Components should be loosely coupled to one another
and to the external environment. Coupling is achieved in many
ways— via a component interface, by messaging, through global
data. As the level of coupling increases, the likelihood of error
propagation also increases and the overall maintainability of the
software decreases. Therefore, component coupling should be kept
as low as is reasonable
Principle 8. Design representations (models) should be easily
understandable. The purpose of design is to communicate
information to practitioners who will generate code, to those who
will test the software, and to others who may maintain the software
in the future. If the design is difficult to understand, it will not serve
as an effective communication medium
Principle 9. The design should be developed iteratively. With each
iteration, the designer should strive for greater simplicity. Like
almost all creative activities, design occurs iteratively. The first
iterations work to refine the design and correct errors, but later
iterations should strive to make the design as simple as is possible
When these design principles are properly applied, you create a
design that exhibits both external and internal quality factors .
External quality factors are those properties of the software that
can be readily observed by users (e.g., speed, reliability,
correctness, usability). Internal quality factors are of importance to
software engineers. They lead to a high-quality design from the
technical perspective. To achieve internal quality factors, the
designer must understand basic design concepts.
4 CONSTRUCTION
PRINCIPLES
The construction activity encompasses a set of coding and testing tasks that
lead to operational software that is ready for delivery to the customer or end
user. In modern software engineering work, coding may be (1) the direct
creation of programming language source code (e.g., Java), (2) the automatic
generation of source code using an intermediate design-like representation of
the component to be built, or (3) the automatic generation of executable
code using a “fourth-generation programming language” (e.g., Visual C)
The initial focus of testing is at the component level, often called unit testing.
Other levels of testing include (1) integration testing (conducted as the
system is constructed), validation testing that assesses whether
requirements have been met for the complete system (or software
increment), and (3) acceptance testing that is conducted by the customer in
an effort to exercise all required features and functions. The following set of
fundamental principles and concepts are applicable to coding and testing
Coding Principles. The principles that guide the coding task are
closely aligned with programming style, programming languages,
and programming methods. However, there are a number of
fundamental principles that can be stated:
Preparation principles: Before you write one line of code, be sure
you
• Understand of the problem you’re trying to solve. • Understand
basic design principles and concepts. • Pick a programming
language that meets the needs of the software to be built and the
environment in which it will operate. • Select a programming
environment that provides tools that will make your work easier. •
Create a set of unit tests that will be applied once the component
you code is completed
Programming principles: As you begin writing code, be sure you
• Constrain your algorithms by following structured programming
[Boh00] practice. • Consider the use of pair programming. • Select
data structures that will meet the needs of the design. •
Understand the software architecture and create interfaces that are
consistent with it. • Keep conditional logic as simple as possible. •
Create nested loops in a way that makes them easily testable. •
Select meaningful variable names and follow other local coding
standards.
• Write code that is self-documenting. • Create a visual layout (e.g.,
indentation and blank lines) that aids understanding
Validation Principles: After you’ve completed your first coding pass,
be sure you
• Conduct a code walkthrough when appropriate. • Perform unit
tests and correct errors you’ve uncovered. • Refactor the code
More books have been written about programming (coding) and the
principles and concepts that guide it than about any other topic in
the software process. Books on the subject include early works on
programming style [Ker78], practical software construction
[McC04], programming pearls [Ben99], the art of programming
[Knu98], pragmatic programming issues [Hun99], and many, many
other subjects. A comprehensive discussion of these principles and
concepts is beyond the scope of this book. If you have further
interest, examine one or more of the references noted.
Testing Principles. In a classic book on software testing, Glen Myers
[Mye79] states a number of rules that can serve well as testing
objectives
• Testing is a process of executing a program with the intent of
finding an error. • A good test case is one that has a high
probability of finding an as-yetundiscovered error. • A successful
test is one that uncovers an as-yet-undiscovered error
These objectives imply a dramatic change in viewpoint for some
software developers. They move counter to the commonly held
view that a successful test is one in which no errors are found. Your
objective is to design tests that systematically uncover different
classes of errors and to do so with a minimum amount of time and
effort.
If testing is conducted successfully (according to the objectives
stated previously), it will uncover errors in the software. As a
secondary benefit, testing demonstrates that software functions
appear to be working according to specification, and that
behavioral and performance requirements appear to have been
met. In addition, the data collected as testing is conducted provide
a good indication of software reliability and some indication of
software quality as a whole. But testing cannot show the absence
of errors and defects; it can show only that software errors and
defects are present. It is important to keep this (rather gloomy)
statement in mind as testing is being conducted.
Davis [Dav95b] suggests a set of testing principles6 that have been
adapted for use in this book:
Principle 1. All tests should be traceable to customer
requirements.7 The objective of software testing is to uncover
errors. It follows that the most severe defects (from the customer’s
point of view) are those that cause the program to fail to meet its
requirements
Principle 2. Tests should be planned long before testing begins. Test
planning (Chapter 17) can begin as soon as the requirements
model is complete. Detailed definition of test cases can begin as
soon as the design model has been solidified. Therefore, all tests
can be planned and designed before any code has been generated
Principle 3. The Pareto principle applies to software testing. In this context the
Pareto principle implies that 80 percent of all errors uncovered during testing
will likely be traceable to 20 percent of all program components. The problem, of
course, is to isolate these suspect components and to thoroughly test them.
Principle 4. Testing should begin “in the small” and progress toward testing “in
the large.” The first tests planned and executed generally focus on individual
components. As testing progresses, focus shifts in an attempt to find errors in
integrated clusters of components and ultimately in the entire system.
Principle 5. Exhaustive testing is not possible. The number of path permutations
for even a moderately sized program is exceptionally large. For this reason, it is
impossible to execute every combination of paths during testing. It is possible,
however, to adequately cover program logic and to ensure that all conditions in
the component-level design have been exercised.
5 DEPLOYMENT PRINCIPLES
As I noted earlier in Part 1 of this book, the deployment activity
encompasses three actions: delivery, support, and feedback. Because
modern software process models are evolutionary or incremental in
nature, deployment happens not once, but a number of times as software
moves toward completion. Each delivery cycle provides the customer and
end users with an operational software increment that provides usable
functions and features. Each support cycle provides documentation and
human assistance for all functions and features introduced during all
deployment cycles todate. Each feedback cycle provides the software
team with important guidance that results in modifications to the
functions, features, and approach taken for the next increment
The delivery of a software increment represents an important milestone
for any software project. A number of key principles should be followed as
the team prepares to deliver an increment:
Principle 1. Customer expectations for the software must be
managed. Too often, the customer expects more than the team has
promised to deliver, and disappointment occurs immediately. This
results in feedback that is not productive and ruins team morale. In
her book on managing expectations, Naomi Karten [Kar94] states:
“The starting point for managing expectations is to become more
conscientious about what you communicate and how.” She
suggests that a software engineer must be careful about sending
the customer conflicting messages (e.g., promising more than you
can reasonably deliver in the time frame provided or delivering
more than you promise for one software increment and then less
than promised for the next)
Principle 2. A complete delivery package should be assembled and
tested. A CD-ROM or other media (including Web-based downloads)
containing all executable software, support data files, support
documents, and other relevant information should be assembled
and thoroughly beta-tested with actual users. All installation scripts
and other operational features should be thoroughly exercised in as
many different computing configurations (i.e., hardware, operating
systems, peripheral devices, networking arrangements) as possible.
Principle 3. A support regime must be established before the
software is delivered. An end user expects responsiveness and
accurate information when a question or problem arises. If support
is ad hoc, or worse, nonexistent, the customer will become
dissatisfied immediately. Support should be planned, support
materials should be prepared, and appropriate recordkeeping
mechanisms should be established so that the software team can
conduct a categorical assessment of the kinds of support requested
Principle 4. Appropriate instructional materials must be provided to
end users. The software team delivers more than the software
itself. Appropriate training aids (if required) should be developed;
troubleshooting guidelines should be provided, and when
necessary, a “what’s different about this software increment”
description should be published
Principle 5. Buggy software should be fixed first, delivered later.
Under time pressure, some software organizations deliver low-
quality increments with a warning to the customer that bugs “will
be fixed in the next release.” This is a mistake. There’s a saying in
the software business: “Customers will forget you delivered a high-
quality product a few days late, but they will never forget the
problems that a low-quality product caused them. The software
reminds them every day.”
The delivered software provides benefit for the end user, but it also
provides useful feedback for the software team. As the increment is
put into use, end users should be encouraged to comment on
features and functions, ease of use, reliability, and any other
characteristics that are appropriate