[note -- the two figure images have been lost to the internet black hole, but they

were fairly simple diagrams that could be replaced with a quick google image
search... or intermediate-level mspaint skillz ;-)]

Robert Mathenia
SG150: Project 1
February 17, 2008

Software engineering is a discipline wherein certain techniques / methods are

employed to improve the quality of software development. As the field grew larger
and more complex, the use of a methodical approach became all but necessary in
order to consistently achieve fewer defects, shorter delivery times, and better
value in software products. Many software development methodologies now exist –
too many to count, and a big challenge facing software engineers is that of
selecting a proper methodology or combination of methodologies and using them
wisely (Chapman). Discussed herein are five of the most recognized software
development methodologies, their efficiencies/ inefficiencies, and their
relationships to one another. These methodologies are almost telescopic in nature,
as they are largely built on and derived from each other. In most real-life
software development projects, no single method is employed; rather, a combination
of methods usually serves development interests best, and some of these
combinations are explored within.

Object orientation is probably the single most pivotal advancement in software

development methodology. It allows software systems to more closely model the real
world by representing the world as a system of interacting objects. This
methodology was conceived relatively early on in the history of digital computers,
but has been only gradually adopted. The reason for this is that in order for the
methodology to work, modeled objects must encapsulate their data as well as the
operations that act on that data, which means more computing memory, storage, and
processing power is necessary. Computer hardware prices have steadily decreased
since the inception of object orientation, contributing to its widespread
adoption.

The main benefits of object orientation are threefold:

1) Maintainability – A system of interacting objects is less complex (to the

programmer) than a structural code collection (in which the acting pieces are more
closely tied to one another), therefore it takes less time and is generally easier
to modify code. Verification of correct coding procedure is also simplified for
the same reason.
2) Reusability – Unique objects that are encapsulated with their own data and
operations can be used with little or no modification in multiple applications
3) Productivity gains – The above principles can be directly mapped to a
contemporary object-oriented programming language, which makes transitioning from
modeling to inception nearly seamless. This saves time, and time is money (Bray).

Object orientation is based on (and often closely coupled to) Object-Oriented

Analysis (OOA). OOA provides the basis for Object-Oriented Design (OOD) via the
creation of classes, which are akin to templates that generate objects. In
OOA/OOD, classes are used to define particular objects, and protocols for
communication between these objects are provided in the form of methods. Methods
are also defined within classes and are thus part of the object. Since an object's
data and the operations that work on that data are encapsulated in a single
entity, the transition from model to programming code requires less effort. In
this way, analysis and design are more closely related in object orientation than
in structured programming. Two distinct phases comprise OOD: high-level, where
larger more basic objects are conceptualized and organized; and low-level, where
the particular objects' attributes, methods and specific composition are addressed
(Bray). This principle further illustrates the marriage of analysis and design
inherent in object-orientation.

Companies have notably reaped significant benefits from the integration of object
orientation in software design. In its large project known as the Call Attempt
Data Collection System (CADCS), AT&T Bell Labs saw a 30% decrease in development
time and a 20% decrease in development staff effort after adopting object
orientation. However, this increase in productivity only occurred after the
incorporation of three- to six-month long pilot projects for training (Bray).

The disadvantage to object orientation is that thoroughly trained developers are

necessary in order to fully reap productivity improvements. If training is not
sufficient, the learning curve involved in adopting object-orientation could be
costly and provide little value. Object orientation provides the best returns when
its goal is the design of reusable software systems. Without significant reuse
potential, object orientation ends up being more costly than more traditional
methodologies such as structural or procedural programming (Bray). The principle
of reuse potential becomes important in methodologies that are largely based on
object orientation, such as the Rapid Development methodologies. Most notably of
these (and which will be discussed later) is eXtreme Programming, wherein the core
practices are built on object-orientation (Zagarrio).

The inherently close relationship between analysis and design in object

orientation practically begs for a standardized way of modeling objects and their
interactions, and this standardization is embodied in the Unified Modeling
Language (or UML). UML is akin to blueprints used by architects in a construction
project – with UML, a model (or collection of different types of models) of a
software application can be generated to serve as a blueprint in software
development. Since the vast majority of software design processes begin with a
model, UML is closely tied to object-orientation ("Practical UML").

UML is not a methodology in itself, but rather a paradigm or framework designed

for compatibility with contemporary object orientation methodology. UML has
significantly affected the evolution of methods that are based on object-
orientation. This is made evident by various changes in the methodology that were
explicitly made to take advantage of updated notation in newer versions of UML.
UML has played a big role in advancing the progress of model-driven technologies,
with the Rational Unified Process (also known as RUP) being a prime example of
this ("Unified Modeling Language").

Modeling is facilitated in UML through the use of various types of diagrams. A

class (the framework or definition of an object), for example, is represented as a
rectangle divided into three parts: the topmost contains the name of the class,
the middle section contains the attributes, and the bottom section is comprised of
the class's methods (see Figure 1).

Figure 1: Diagram of a class

The class diagram is not the only diagram UML is capable of creating; in fact, in
the newest version of UML (UML 2.0) there are thirteen different types of diagrams
spread across three categories. The distribution of diagram types is as follows:
The first category, Structure Diagrams, consists of class, component, composite
structure, deployment, object, and package diagrams. The second category, Behavior
Diagrams, consists of activity, state machine, and use case diagrams. The final
category, Interaction Diagrams, consist of communication, interaction overview,
and UML timing diagrams. All these diagrams can be organized under a hierarchy, as
depicted in Figure 2: ("Unified Modeling Language")
..
Figure 2: Diagram hierarchy in UML ("Unified Modeling Language")

Despite UML's virtually unanimous industry acceptance, some criticisms of its

alleged deficiencies have surfaced:

1) UML is too large and/or complex, resulting in redundant or infrequently used

diagrams,
2) Difficult for newcomers to adopt due to complexity,
3) UML seems to represent some systems better than others. This implies that any
given programming language used to implement UML models would cap off at some
level of efficiency in those situations that UML does not accurately model.
4) UML is aesthetically inconsistent and displeasing. There seems to be no pattern
or practical reason behind the various shapes used to represent different
diagrams/models (boxes sometimes, clouds other times)
5) UML strives for total compatibility and generality in modeling, which can make
it feel weighed down and bloated ("Unified Modeling Language").

As we have seen, UML produces models wherever object orientation happens to be

practiced. The combination is prevalent because the software development
methodology feeds off of the modeling process, and vice versa. In practice, the
methodology and the modeling language are inextricably intertwined.

Rapid Application Development (or RAD) is essentially a sort of revved-up

occurrence of object orientation and UML in action. In traditional software
development, many requirements are documented along the way in a process, and the
quality of the resulting product is measured as "the degree to which the system
conforms to written specifications". Since most large software development
projects never satisfy every single written requirement, the quality of the
resulting product comes under scrutiny. RAD addresses this issue by redefining the
concept of quality to mean "the degree to which a system meets business
requirements" (Zagarrio).

RAD is an evolutionary, iterative approach to software development, with each

iteration in the process resembling an entire (yet smaller-scoped) development
project. Evolution of prototypes in RAD is directed by a set of guidelines:

- The customer specifies requests, the developer makes changes

- Designers review the prototype
- Customer determines whether the prototype follows requests and suggests new
requests
- Meetings are arranged between developers and designers to discuss secondary
requests, and which requests may be sacrificed

According to Giuseppe Zagarrio's "Rapid Software Development Methodologies", Rapid

Application Development embodies three basic principles:

"1) In certain situations, a usable 80% solution can be produced in 20% of the
time that would have been required to produce a total solution.
2) In some cases the customer's requirements can be completely satisfied even if
the functional requirements are not completely satisfied.
3) In some cases a system can work with a sufficient level of functionality even
if functions are not all required ones" (Zagarrio).
All of these seemingly stringent formalities are really not such – in practice,
the principles of RAD are a little more general and malleable: release only
documentation that is absolutely necessary, use models as much as possible, and
work closely with the customer (Zagarrio). Skipping publishing of unnecessary
documentation saves time and money, and keeping close communication with the
customer / client helps ensure a better understanding of requirements. This in
turn leads to the application being designed correctly early on, serving to
diffuse or eliminate problems, or at the very least preventing problems from
compounding beyond control.

The act of rapidly developing a software product often results in lack of

reusability. RAD facilitates reuse by building from the generic to the specific.
In other words, base classes are given priority in design. Modification and new
functionality is achieved through class inheritance (Zagarrio). So, if a "car"
object is needed, a base class of "vehicle" would probably be designed, and then
the class "car" would be based on the vehicle class. This way, if at a later time
trucks or boats are needed, they could be based on the already written vehicle
class.

Rapid Development often uses CASE (Computer Aided Software Engineering) tools to
expedite the design process. There are some problems with this:

- Programming code is not 100% testable because of lack of visibility of third-

party code,
- Costs can increase due to licensing constraints of CASE tools,
- Customer satisfaction can decrease if secondary requirements are set aside when
CASE cannot provide for them (Zagarrio).

If programmers depend too much on CASE tools, the resulting application might not
be as testable as desired because the implementation of the CASE tools themselves
are involved, but invisible (and therefore unable to be included in testing). CASE
also has its own limits, so some things may be overly difficult or near-impossible
to implement using a given CASE toolset. If the development team is forced to rely
on a CASE toolset, and that toolset does not provide for the specified
requirements, the customer could end up dissatisfied.

RAD should not be used for mission- or life-critical situations where the best
performance is required (eXtreme programming is preferred in these situations).
RAD is ideally employed in the case of a standalone application, or to get an
early compromise between customer and developer (Zagarrio).

Even though RAD is based on and operates in the larger framework of object
orientation and UML, RAD itself can be generalized into an entire group of
methodologies, and when this is the case, is often referred to as Rapid
Application Methodologies (or RAM). RAM consists of (but is apparently not limited
to): Rapid application development (as discussed above), Agile Modeling, and
eXtreme Programming (Zagarrio).

In eXtreme Programming, also known as xp, development time is reduced by employing

standardized programming practices which allow for constant testing. This is in
direct contrast to Rapid Development, which focuses on reduction of development
time through the use of third-party software (Zagarrio). It can be speculated that
xp's standardized programming practices are more controllable than RAD's third-
party software use, which may in turn lead to a tighter more satisfactory product.

Much as in RAD, in xp the customer is involved, but to an even greater degree. The
customer is considered part of the team so that necessary changes can be made
quickly and effectively (Zagarrio). This method has the advantage of instant
feedback, but the disadvantage of the responsibility of an in-house client. For
the benefits to be maximized with this setup, communication must be open, honest
and sincere.

The final constituent of RAM, Agile Software Development, is a sort of general

paradigm that encompasses many development methods. The main goal in these methods
is risk minimization through development iterations. Even though at the end of an
iteration the project may not be functional enough to justify release, release is
the goal of every iteration, and every iteration is in itself an entire project.
Agile employs a customer-centric approach, giving preference to face-to-face
communication over written documents, and the focus is on working software as the
main measure of progress ("Agile software development").

Agile Modeling is a support to design, not a formula or method in itself. It

employs a set of principles divided into two groups (core and other) in order to
reduce problems into models. For a model to be officially considered Agile, the
core principles must be adhered to. Agile Modeling's values include communication,
simplicity, feedback, courage, and humility (these are very similar to the values
of xp, probably due to Agile often being in support of xp). The core principles of
Agile modeling are:

1) Model with a purpose

2) Maximize stakeholder investments
3) Travel light
4) Multiple models
5) Rapid feedback
6) Assume simplicity
7) Embrace change
8) Incremental change
9) Quality work
10) Software is primary goal
11) Enabling next effort is secondary goal (Zagarrio)

The advantages of agile modeling are similar to those of RAD and xp, due mostly to
its heavy involvement with those disciplines. Due also to this relationship, the
main disadvantage of Agile speaks as well to xp and other RAMs: In the case of
inaccurate feedback, problems can be compounded quickly and lead to an unworkable
solution ("Agile software development"). This is why communication is so important
in these Rapid methodologies – it does not matter how close the customer / client
is kept to the development process: if the feedback from the customer to the
developer (or vice versa) is inaccurate but is mistaken as accurate and then acted
upon, the mistake could spiral into a large problem the likes of those that
sometimes occur with traditional methodologies (such as the waterfall method). And
in these problem scenarios where RAM is employed, there is not even documentation
with which to gain some footing.

Another area in which a developer may encounter problems with agile modeling is
that of working with and incorporating large data systems. Data system specialists
often require exacting, complete specifications. If these specs are not prepared
correctly, the development comes to a standstill until the data can be negotiated.
For this reason, agile modeling is not well-suited for systems that rely on large,
relational, legacy databases ("Agile software development").

Common to all software development projects, regardless of methodology employed,

is the fact that every application embodies one or more patterns. These pattern
may be similar to patterns found in other software development projects, and so
may be adopted from project to project. This is the central tenet to Design
Patterns. Design patterns address the problem of unique techniques for every
software design problem by providing general solutions that are documented in a
way that does not attach them to any particular problem. Design patterns are like
templates that are made to expedite solutions to common problems in software
design. The use of patterns in design allows developers to attach well-understood
names and terminology to software interactions. This way, design patterns lend
themselves to improvement over time, where ad-hoc designs do not ("Design pattern
(computer science)").

Design patterns can be categorized into three groups: creational, structural, and
behavioral ("Design patterns in C and VB.NET"). Each particular pattern is
composed of several sections: structure, participants and collaboration. These
combined sections describe a "micro-architecture" which includes classes, methods,
and their relationships. Micro-architectures are used by developers in design
patterns, facilitating uniform structure and organization ("Design pattern
(computer science)").

The main advantage to design patterns is that they speed up the development
process. They also serve to provide a tested and proven framework for development,
since the pattern has been previously used. Early issues that can cause big
problems later are often revealed through reuse of design patterns. Design
patterns are numerous, and exist for a variety of specific domains in software
design, such as user-interface design ("Design pattern (computer science)").

Two examples of design patterns are the Singleton and the Façade. The Singleton
applies in situations where only one object of a class is needed. A second client
class is used to interact with the singleton. The class has absolute control over
the number of instances that can be created, via a method that returns a reference
to the instantiated object. The Singleton design pattern keeps the responsibility
of keeping track of objects off the programmer, and can be extended (it is
refactorable in xp lingo) to keep track of a different number of objects.

The Façade pattern helps in situations where a collection of classes needs to be

grouped under a common interface class (rather than interfacing complexly among
themselves). An example of the Façade in action is in the case of modeling a room.
The room has several objects, such as chair, table, desk, bed, etc. Incorporating
a Façade pattern, an interface that allows all the objects in the room to interact
in room-like ways would be created. In this case, a room class would have methods
such as "organizeRoom()" wherein the objects in the room would be changed via one
interface call instead of many. Compilers often employ the Façade pattern in
design ("Design Patterns Tutorial").

A problem with design patterns is the tradeoff of performance for flexibility,

because design patterns introduce a greater number of possible outcomes which can
complicate designs. It is also argued (to a lesser degree) that design patterns do
not promote software reuse because they are not components in themselves.
Currently, patterns must be integrated into each application from scratch, and
some seek to address through "componentization" of the patterns ("Design pattern
(computer science)").

The very nature of software development involves problem solving, and an essential
component of problem solving is pattern recognition. Therefore, design patterns
(or some offshoot thereof) are destined to walk hand-in-hand with software
development. And like design patterns, we have seen that some software development
methodologies are inseparably bound to each other. A developer would not start a
large object-oriented project without first creating one or more UML diagrams,
most applications developed using a rapid methodology are immersed in object
orientation, and rapid-methodology designed applications probably would not have
been nearly as rapidly designed without an agile model. All this leads to the
conclusion that the methodologies explored herein overlap each other to the point
of all-inclusiveness and that in practice the best is borrowed from all
methodologies in all applicable areas.

WORKS CITED
"Agile software development." Wikipedia. 2008. Wikipedia.org. 16 Feb 2008 .

Bray, Mike. "Object-Oriented Design." Carnegie Mellon Software Engineering

Institute. 27 OCT 1997. Carnegie Mellon Software Engineering Institute. 16 Feb
2008 .

Chapman, James. "Software Development Methodology." Infinite Spiritual Discovery.

01 JAN 2007. 17 Feb 2008 .

"Design pattern (computer science)." Wikipedia. 2007-08. Wikipedia.org. 16 Feb

2008 .

"Design patterns in C and VB.NET." data & object factory. 16 Feb 2008 .

Kurotsuchi, Brian. "Design Patterns Tutorial." Cal Poly Computer Science

Department. 1996. Cal Poly State University. 16 Feb 2008 .

"Practical UML." CODE GEAR From Borland. 01 DEC 2003. Borland Software Corp. 17
Feb 2008 .

"Unified Modeling Language." Wikipedia. 2008. Wikipedia.org. 17 Feb 2008 .

Zagarrio, Giuseppe. "Rapid Software Development Methodologies." Norwegian
University of Science and Technology Department of Computer and Information
Science. NTNU. 16 Feb 2008