Page 195 -

162 part 2 • inforMation requireMents analysis

The agile philosophy, however, allows an analyst to adjust the quality resource and per-
haps put less effort into maintaining quality than otherwise would be expected. Quality can be
adjusted both internally and externally. Internal quality involves testing software for factors such
as functionality (Does a program do what it is supposed to do?) and conformance (Does the
software meet certain conformance standards, and is it maintainable?). It usually doesn’t pay to
tinker with internal quality.
That leaves us with external quality, or how the customer perceives the system. The cus-
tomer is interested in performance. Some of the questions a customer may ask are: Does the pro-
gram act reliably (or do software bugs still exist)? Is the output effective? Does the output reach
me on time? Does the software run effortlessly? Is the user interface easy to understand and use?
The extreme philosophy of agile development allows some of the external quality issues to
be sacrificed. In order for a system to be released on time, the customer may have to contend with
some software bugs. If we want to meet our deadline, the user interface may not be perfect. We
can make it better in a follow-up version.
Commercial off-the-shelf software manufacturers do sacrifice quality, and it is debatable
whether this is a good approach. Developers may be using extreme programming as one of their
agile practices, so don’t be surprised when your PC software applications (not to mention your
operating system and Web browser) are updated often.
SCOPE. Finally, there is scope. In the agile approach, scope is determined by listening to
customers and getting them to write down their stories. Then the stories are examined to see
how much can be done in a given time to satisfy the customer. Stories should be brief and
easy to grasp. Stories will be described in more detail later in this chapter, but here is a brief
example showing four short stories from an online air travel system. Each story is shown in
bold type:
Display alternative flights.
Prepare a list of the five cheapest flights.
Offer cheaper alternatives.
Suggest to customers that they travel on other days, make weekend stays, take special pro-
motions, or use alternate airports.
Purchase a ticket.
Allow the customer to purchase a ticket directly using a credit card (check validity).
Allow the customer to choose his or her seat.
Direct the customer to a visual display of the airplane and ask the customer to select
a seat.

Ideally, the analyst would be able to determine how much time and money is needed to
complete each of these stories and would be able to set the level of quality for them as well. It
is obvious that this system must not sacrifice quality, or credit card purchases may be invalid or
customers may show up at the airport without reservations.
Once again, agile practices allow extreme measures, so in order to maintain quality, manage
cost, and complete a project on time, an agile analyst may want to adjust the scope of the project.
This can be accomplished by agreeing with the customer that one or more of the stories can be
delayed until the next version of the software. For example, maybe the functionality of allowing
customers to choose their own seats can be put off for another time.
In summary, an agile analyst can control any of the four resource variables of time, cost,
quality, and scope. Agility calls for extreme measures and places a great deal of importance on
completing a project on time. In doing so, sacrifices must be made and the agile analyst will find
out that the trade-offs available involve difficult decisions.
FOUR CORE AGILE PRACTICES. Four core practices markedly distinguish the agile approach from
other approaches: short releases, the 40-hour workweek, hosting an on-site customer, and using
pair programming:

1. Short releases means that the development team compresses the time between releases
of the product. Rather than release a full-blown version in a year, using the short release