Page 46 -

ChaPter 1 • SyStemS, roleS, and develoPment methodologieS 13

always easy because the agile process is an unusually demanding role for the customer to play.
Customers decide what the development team should tackle first. Their decisions will set priori-
ties and check functionalities throughout the process.

itErations to thE First rElEasE. The third stage in the agile development process is composed
of iterations to the first release. Typically these are iterations (cycles of testing, feedback, and
change) of about three weeks in duration. You will be pushing yourself to sketch out the entire
architecture of the system, even though it is just in outline or skeletal form. One goal is to run
customer-written functional tests at the end of each iteration. During the iterations stage you
should also question whether the schedule needs to be altered or whether you are tackling too
many stories. Make small rituals out of each successful iteration, involving customers as well as
developers. Always celebrate your progress, even if it is small, because this is part of the culture
of motivating everyone to work extremely hard on the project.
productionizing. Several activities occur during the productionizing phase. In this phase the
feedback cycle speeds up so that rather than receiving feedback for an iteration every three
weeks, software revisions are being turned around in one week. You may institute daily briefings
so everyone knows what everyone else is doing. The product is released in this phase, but it may
be improved by adding other features. Getting a system into production is an exciting event.
Make time to celebrate with your teammates and mark the occasion. One of the keys to the agile
approach, which we heartily embrace, is that it is supposed to be fun to develop systems!
MaintEnancE. Once a system has been released, it needs to be kept running smoothly. New
features may be added, riskier customer suggestions may be considered, and team members may
be rotated on or off the team. The attitude you take at this point in the developmental process is
more conservative than at any other time. You are now in a “keeper of the flame” mode rather
than the playful one you experienced during exploration.

Object-Oriented Systems Analysis and Design

Object-oriented (O-O) analysis and design is an approach that is intended to facilitate the devel-
opment of systems that must change rapidly in response to dynamic business environments.
Chapter 10 helps you understand what object-oriented systems analysis and design is, how it
differs from the structured approach of the SDLC, and when it may be appropriate to use an
object-oriented approach.
Object-oriented techniques often work well in situations in which complicated informa-
tion systems are undergoing continuous maintenance, adaptation, and redesign. Object-oriented
approaches use the industry standard for modeling object-oriented systems, called Unified
Modeling Language (UML), to break down a system into a use case model.
Object-oriented programming differs from traditional procedural programming in that it
examines objects that are part of a system. Each object is a computer representation of some
actual thing or event. Objects may be customers, items, orders, and so on. Objects are repre-
sented by and grouped into classes that are optimal for reuse and maintainability. A class defines
the set of shared attributes and behaviors found in each object in the class.
The phases in UML are similar to those in the SDLC. Since those two methods share rigid
and exacting modeling, they happen in a slower, more deliberate pace than the phases of agile
modeling. An analyst goes through problem and identification phases, an analysis phase, and a
design phase, as shown in Figure 1.6.
Although much of the specifics are discussed in Chapters 2 and 10, the following steps give
a brief description of the UML process:
1. Define the use case model.
In this phase the analyst identifies the actors and the major events initiated by the
actors. Often the analyst will start by drawing a diagram with stick figures representing
the actors and arrows showing how the actors relate. This is called a use case diagram
(Chapter 2), and it represents the standard flow of events in the system. Then an analyst
typically writes up a use case scenario (Chapter 2), which describes in words the steps that
are normally performed.