See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/224587194

Using the Agile Unified Process in Banking

Article in IEEE Software · July 2010

DOI: 10.1109/MS.2009.156 · Source: IEEE Xplore

CITATIONS READS

22 7,457

3 authors, including:

Ioannis T. Christou Stavros T. Ponis

Athens Information Technology National Technical University of Athens
86 PUBLICATIONS 1,172 CITATIONS 121 PUBLICATIONS 1,557 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Ioannis T. Christou on 21 May 2014.

The user has requested enhancement of the downloaded file.

feature
agile methods

Using the Agile Unified

Process in Banking
Ioannis T. Christou, Athens Information Technology

Stavros T. Ponis, National Technical University of Athens

Eleni Palaiologou, Athens Information Technology

T
he banking sector is well known for using large, sometimes monolithic, leg-
A banking-sector
acy systems. Now, banks find themselves having to catch up with rapid ad-
project combined
vancements in software development that call for new service-oriented com-
agile methods puting paradigms. Unfortunately, this task is nontrivial and often requires
with the Rational huge projects that are costly, time consuming, and risky. The safe choice for a develop-
Unified Process ment methodology is a process framework such as the Rational Unified Process (RUP),
to exploit service- which is customizable enough to fit any project. However, customizing RUP isn’t trivial,
oriented architecture so it’s often used in its full-blown out-of-the-box project, regardless of its size. Still, customizing RUP
functionality and form, which entails significant sacrifices of time, demands both experienced staff and preparation
cost, and flexibility.1–3 But what if the organiza- time, otherwise it could result in an oversimplified
user interface tion is unwilling to make these sacrifices? What project or, worse, a failure to meet essential require-
integration of legacy happens when time, cost, and flexibility aren’t ne- ments. To avoid the effort and risk, organizations
applications. gotiable issues but hard management constraints? often implement RUP with little or no customiza-
We recently applied the Agile Unified Process tion, resulting in a complex process requiring nu-
(AUP)4 —a hybrid approach designed by Scott Am- merous documentation artifacts. On the other
bler combining RUP with agile methods5–7 —to a hand, agile methods are considered more light-
successful project in the banking sector. The proj- weight, emphasizing people and shifting authority
ect achieved on-time delivery within budget, inte- to the developers at the heart of the project. Never-
grating heavy legacy back-end application systems theless, the two methods aren’t incompatible.
with newly reengineered client user-interface appli- AUP is an agile public-domain instantiation
cations on a modern service-oriented architecture of RUP.9–11 It’s a simple, easy-to-understand ap-
(SOA) platform.8 proach to developing business-related software us-
ing agile techniques and concepts while remaining
The Agile Unified Process true to RUP. It applies agile techniques including
Agile methods and RUP are among the most widely agile modeling (AM), test-driven design (TDD), ag-
used software development methods. Although ile change management, and database refactoring
both are iterative, they seem to have significant to improve productivity. AM is the basis for agile
differences. model-driven development and is a key concept in-
For starters, RUP is a process framework of- troduced in AUP to effectively model and document
fering adaptability to every software development software systems. Simply put, AM is a collection of

72 IEEE SOFT WARE Published by the IEEE Computer Society 0 74 0 -74 5 9 / 10 / $ 2 6 . 0 0 © 2 0 10 I E E E

values, principles, and practices for modeling soft- project’s scope to ensure that it’s delivered on
ware in a lightweight manner.9–10 It values commu- time and within budget.
nication, simplicity, courage, feedback, and humil- ■■ Environment. Support the rest of the effort by
ity. Its principles include ensuring that the team has the proper process,
guidance (standards and guidelines), and tools
■■ assuming simplicity, which is the equivalent of (hardware, software, and so on).
Occam’s razor in software engineering;
■■ embracing change, in that requirements will in- Ambler designed AUP around a few basic con-
evitably change during the project lifecycle; cepts. First, people won’t read detailed process doc-
■■ incremental change of a system over time to ac- umentation, but they will want high-level guidance
commodate requirement changes; and and training from time to time. Second, describe
■■ rapid feedback from project stakeholders after things concisely in a few pages, not thousands.
every software release. Third, focus on the important activities and risks,
not every minute detail. Fourth, teams should use
AM practices are a set of best practices that include any tools they prefer for a given job, not have tools
creating several models in parallel, modeling in imposed on them by the process. And finally, the
small increments, iterating to another artifact, and process should be highly customizable so that you
updating models only when it hurts. can tailor it to a specific project’s needs.
As in RUP, AUP has four major phases:
The Integrated Desktop
1. Inception. The team identifies the project’s ini- Using AUP, one of the largest banks in Greece im-
tial scope, a potential architecture, and obtains plemented a small to medium-scale project called
initial funding and stakeholder acceptance. the Integrated Desktop (ID). It was an important
2. Elaboration. The team establishes the system’s part of a large company-wide project that aimed
feasibility and proposed architecture. to transition the company’s IT architecture from
3. Construction. The team builds working soft- the aged client-server model to one using SOA
ware on a regular, incremental basis that meets concepts. The parent project was based on an en-
the project stakeholders’ highest-priority needs. terprise service bus framework—a standard archi-
4. Transition. The team validates and deploys the tectural framework in the world of SOAs—devel-
system in the production environment. oped for the company’s particular needs.
The project’s main objective was to host private-
Unlike RUP however, AUP is guided by seven banking applications with single sign-on capabil-
principles: ity, thus automating daily tasks via global customer
handling, exploiting the enterprise service bus
■■ Understanding. Understand the business of the framework architecture, and managing multiple
organization and the problem domain the proj- and concurrent customer sessions. Modifying ex-
ect addresses, and identify a viable solution. isting functionality or creating new functionality in
■■ Implementation. Transform models into ex- the existing back-end systems was beyond the proj-
ecutable code, and perform a basic level of test- ect’s scope.
ing, particularly unit testing. In the context of the parent project, the bank
■■ Testing. Find defects, validate that the system adopted RUP as its development methodology. ID
works as designed, and verify that it meets the was the first to adopt AUP to produce quick-win
requirements. user results. The bank’s IT strategy unit and IT de-
■■ Deployment. Plan for the system’s delivery, velopment units authorized AUP’s adoption.
and execute the plan to make it available to end Figure 1 summarizes the project’s main char­-
users. acteristics.
■■ Configuration management. Manage access
to project artifacts. This includes tracking arti- Project Life Cycle Based on AUP
fact versions over time and then controlling and The team followed the SOA-phased deployment
managing changes to them. approach based on AUP and Microsoft’s Smart
■■ Project management. Direct the activities that Client and Customer Care Framework (CCF).9
take place within the project. This includes The ID phased deployment stopped at CCF step
managing risks, directing people (assigning 2. The project included an integrated user interface
tasks, tracking progress, and so on), and coor- that combined existing user interfaces and new ap-
dinating with people and systems outside the plications based on a small set of enterprise service

May/June 2010 I E E E S O F T W A R E 73
Figure 1. Project information summary. The
Project name Integrated Desktop project involved 23 people spanning a large
portion of the organizational hierarchy. In
Project owner Private banking unit
addition to the purely technical core, the
Bank units IT development and operations, organization and plan- people involved included five users and
involved in the ning, private banking (top management, relationship
four top managers who formed the project
project managers, middle office, customer documentation,
and MIS) steering committee. The project lasted six
months, during which the team implemented
Team size Nine developers, three technicians (operational and
a total of 13 use cases.
administrative support), two test managers, five users,
and four top managers (see steering committee)
The team followed AUP’s four phases through-
Steering Project manager, IT development manager, and top
committee management review (private-banking operations unit out the project life cycle. Figure 3 shows the project
manager, brands unit manager, area manager, and time line.
private-banking general manager)
Project An author of this article who has much experience in Inception
manager successfully managing large-scale IT projects During inception, the team defined the project
Project duration Six months scope as follows:

Project size 13 use cases

■■ A role-based integrated user desktop hosts pri-
vate-banking applications.
■■ The ID system automates daily tasks via global
customer handling, exploiting the SOA-based
parent project architecture and managing mul-
Host native user interface
tiple and concurrent customer sessions.
Start now ■■ The ID system prefetches customer information
Quick benefits and shares it intelligently among different appli-
cations to eliminate redundancy and radically
reduce the time users must spend to complete
Step 1 tasks.

Expose some applications Using AUP, the team identified more than 10 use
as services cases and key requirements in this phase. The proj-
ect manager made cost and schedule estimates used
for iterations in later phases (mostly during elabora-
tion). This doesn’t mean that she planned out the
Step 2 Create full data abstraction entire project at this point. As with all planning,
and layer those tasks scheduled for completion in the near fu-
Full SOA architecture ture were detailed more accurately and with greater
confidence, whereas tasks further down the line
were understood to be estimates with larger mar-
gins of error.
The team also defined the project’s risks dur-
Virtual ing inception. The list of risks was a living compi-
record lation that changed over time. Risks drive project
Step 3
management, just as the highest-priority risks drive
iteration scheduling. Earlier iterations addressed
higher-priority risks. Difficulties the team initially
Figure 2. Development steps of the Integrated Desktop (ID) project. ID identified included
was based on the Microsoft Customer Care Framework offering Single
Sign-On functionality for all applications it hosted using the Citrix ■■ communicating the new architecture’s benefits
Password Manager. to the users and producing really useful results;
■■ meeting scheduling requirements due to the
bus services. The idea was to deliver a pilot project project’s innovative approach;
and proceed with a new multiphased project based ■■ maintaining management and user commit-
on the user response and acceptance (see Figure 2). ment throughout all phases; and

74 IEEE SOFT WARE w w w. c o m p u t e r. o rg /s o f t w a re

Track name Duration May ‘07 Jun ‘07 Jul ‘07 Aug ‘07 Sep ‘07 Oct ‘07 Nov ‘07 Dec ‘07
(days) 30 7 14 21 28 4 11 18 25 2 9 16 23 30 6 13 20 27 3 10 17 24 1 8 15 22 29 5 12 19 27 3 10 17
PB SSO & application front-end integration 132
Project manager 132
Inception 19 Inception
Elaboration 23 Elaboration
Prototype–key users training 2
Prototype 5
Prototype–UAT completion 0 Prototype–UAT completion
Construction 75 Construction
Executable A–Implementation 24
Executable A–UAT 5
Executable A–UAT completion 0 Executable A–UAT completion
Deliverable B–implementation 46
Executable B–UAT 5 Executable B–UAT
Executable B–UAT completion 0 completion
Transition 23 Transition
PB users training 10
Rollout at (PB key users’ PC) 5
Beta testing by PB key users 15
Fine-tuning & defect resolution 15
Performance testing (network included) 12
Final rollout 3 Final rollout

Figure 3. Project time

■■ potential incompatibility between proj- sults to the users for confirmation, which in turn line. The inception
ect requirements and the bank’s culture and produced the necessary results for iteration 2. phase took 19 days,
infrastructure. The team made the changes and top management the elaboration phase
signed off. The team also held a user-acceptance- lasted 23 days, the
Finally, the project needed to make sense from testing workshop during which they received a construction phase
a technical, operational, and business perspective. second round of minor correction requests. took 75 days, and the
The project manager collaborated with the devel- The requirements weren’t completely speci- transition phase lasted
opment, architectural, and operations teams to cre- fied at this point. They were detailed only so as another 23 days. PB
ate time and cost estimates and the steering com- to ensure an understanding of the architectural stands for private
mittee approved the proposal. In general, internal risks of each requirement’s scope for subsequent banking. SSO stands
banking project management allows a 20 percent planning. The team identified and prioritized for single sign-on.
margin for time and cost estimates. Projects that the risks, addressing significant ones during UAT stands for user
stay within this limit are deemed successful. elaboration. Addressing architectural risks can acceptance test.
take several forms: research into similar sys-
Elaboration tems, a stand-alone test suite, a working proto-
This phase aims to prove the system’s architecture type, and so on.
by elaborating a well-accepted working skeleton In our case, a working prototype showcasing
called an architectural prototype. The point was the architecture and user interface functionality
to ensure that the team could actually develop a was developed that enabled project management
system that satisfied the requirements. The team’s to mitigate architectural and usability risks. The
business analyst gathered requirements. (Still, the ID hosted core banking, portfolio management,
users themselves prepared the current system’s customer relationship management, fraud de-
“as-is” documentation, proving in some sense tection, suspicious activity reporting, document
their commitment to the project.) Then, the de- management, and a management information
velopment team prepared a mock-up demo with system for private banking. The team captured
screenshots for each software function in a se- most of the system requirements. Common pro-
quence following the business workflow and pre- cesses undertaken in this phase included creating
sented the ID user interface. The team then held process-flow, use-case, and sequence diagrams.
user workshops—one with each user representa- The team wrote use cases during the elabora-
tive per unit and one global workshop with all tion phase; each one would become the start of
units, gathering their comments, remarks, and a new construction iteration. The user members
suggestions on the user interface and business of the team described in detail all the daily tasks
workflow and system functionality. The project performed until then, and the technical members
manager sent debriefings of the workshops’ re- of the team documented them. The document

May/June 2010 I E E E S O F T W A R E 75
describing the “as-is” situation was a main deliv- though users and test managers tested integration
erable. After detailed study and architectural de- early enough, during the elaboration (hosting of
The team sign finalization, the project manager produced a applications) and construction (UAT in the test-

needed to similar document with the “to-be” situation. She

extensively conferred with the users in developing
ing environment) phases, differences in set-up
between preproduction or production and UAT
start thinking the final version of this document. environment couldn’t be predicted. Most of the
outside of the Construction
issues resulted from special settings of the hosted
applications in the preproduction or production
current UML- This phase develops the system so that it’s ready environment. The time and effort spent in the
centric nature for preproduction testing. Previous phases identi- transition phase was significant owing to the fine-
fied most requirements and created a baseline for tuning required for the entire infrastructure to
of RUP. the system’s architecture. Emphasis then shifted improve performance and assure smooth, stable
to prioritizing and understanding the require- operation.
ments, brainstorming a solution, and coding and The phased-rollout approach that came next
testing the software. Construction was the proj- included extensive beta testing by small groups
ect’s largest phase. In this phase, the team built before the company released the system to the
the remainder of the system on the foundation whole end-user population, including the final
laid during elaboration. The team implemented technical documentation with detailed physical-
system features in two time-boxed iterations last- architecture and technical-user manuals. The
ing 24 and 46 working days. company conducted exhaustive training pro-
Each iteration resulted in an executable release grams, addressing both operation and support.
of the software. The team deployed an early re- To exit the transition phase, the project team
lease of the system to obtain user feedback. The had to pass the product release milestone, which
team implemented 30 percent of the process flow included the following items. Business stakeholder
automations (the most complicated ones) during acceptance: the business stakeholders were sat-
the first iteration and included them in executable isfied with and accepted the system. Operations
A. They included corrections to Executable A and acceptance: the people responsible for operating
all remaining process flow automation in execut- the system in production were satisfied with the
able B. The successful completion of each of the relevant procedures and documentation. Support
two iterations (not including automated unit and acceptance: the people responsible for support-
integration testing) ended with a user acceptance ing the system once in production were satisfied
test (UAT). This ensured that progress was always with the relevant procedures and documentation.
based on mutual agreement with the users. Cost and estimate acceptance: the current expen-
To exit the construction phase, the project had ditures were acceptable, and reasonable estimates
to pass the initial operational-capability mile- had been made for future production costs.
stone. The primary issue was whether the current
version was ready to move into the preproduction Project Development Issues
test environment for system and acceptance test- As the project progressed, the team ran into sev-
ing. The team achieved that milestone with a pre- eral issues, most of which are common in similar
sentation demo during a workshop with the mem- projects.
bers of the steering committee.
Personnel
Transition The developers adopted the process pretty quickly
This phase lasted 23 days. Transition includes because many of the object-oriented development
system and acceptance testing and focuses on practices were familiar to them already and they
delivering the system into production. In this preferred an iterative and incremental develop-
phase, the team gradually deployed the system to ment approach. However, the development team
the target users. Feedback from an initial release leader and the database administrator (DBA) had
resulted in further refinements that they incor- a “big design up front” (BDUF)—also known as
porated over the course of two transition phase “big modeling up front” (BMUF)11 —mindset that
iterations. they started to overcome only after seeing that
Extensive testing occurred, including beta the emergent-design approach actually worked in
testing. Fine-tuning of the existing hosted ap- practice. The business analyst tried hard to learn
plications and integrated desktop took place as how to apply use cases effectively in combination
well as rework to address significant defects. Al- with other requirements artifacts. One tester was

76 IEEE SOFT WARE w w w. c o m p u t e r. o rg /s o f t w a re

initially concerned that there weren’t enough de- the team’s decisions, and the whiteboard diagrams
tailed models to inspect and review. However, he were quite agile. The testers carried out the testing
soon realized that the closer collaboration among with the Mercury testing and analysis tool. They
the team and the combination of significant de- inserted all the test cases (scenarios) and moni-
veloper testing using the bank’s testing tool and tored testing progress using the tool. The testers
testing in the large activities such as system testing also maintained the test model—the definition of
and UAT were sufficient. the test cases—but invested too much effort in its
development.
Management
Senior management supported the project team Lessons Learned
throughout the effort because they could clearly see For a RUP project team to adopt AUP and AM
that the team was delivering. The project manager techniques,10–11 it must overcome common devel-
could therefore focus on issues such as scheduling oper misconceptions about RUP as well as several
and estimating and softer issues such as ensuring cultural barriers common in organizations that in-
that the team had the resources they needed, includ- stantiate RUP. The team needed to start thinking
ing training, and that they weren’t being delayed by outside of the current UML-centric nature of RUP.
politics. To do this, the team tried and mostly succeeded
in the following eight goals.
Tools First, they detached from the phrase “use-case
The team could have been more agile regarding driven.” Use cases, elaborated by developers (play-
tool usage. It didn’t fully accept the practice of ing also the business analyst role) weren’t sufficient
“use the simplest tools”: whiteboards made sense, to drive the team to the final product. Use cases
but index cards and essential user interface proto- are good for documenting behavioral require-
types using Post-it notes and flip chart paper were ments, but that was only a part of the functional-
too foreign. requirements picture and a smaller part of the total
requirements picture. Use cases aren’t the best for
The Culture documenting business rules, user interface require-
The hardest thing to overcome was the serial/wa- ments, constraints, or nonfunctional requirements.
terfall mindset of some participants. The develop- This is why RUP includes a supplementary specifi-
ment team leader and the tester from the responsi- cation to contain all these other things.
ble test center wanted more formal documentation. Second, they acknowledged that there are more
The DBA’s data-driven mentality was typical but modeling artifacts than those that UML offers.
we eventually confronted it successfully, mostly AM’s multiple-models principle reminds develop-
because of the type of the project that focused on ers that we have many modeling artifacts at our
UI integration and legacy data presentation that disposal, such as change cases, user stories, busi-
necessarily had to go over multiple iterations. Se- ness rules, UML activity diagrams, UML class dia-
nior management was already committed to the grams, data models, and external interface specifi-
project because it had already participated in the cations. Many people perceive that RUP is simply a
project’s definition and pushed for it. process for using UML. However, RUP recognizes
that a wide range of models is needed to explore
Documentation the complexities of modern software, and recent
The team wrote too much documentation, but this versions include data modeling and user interface
increased its comfort level with the new approach, design activities that are currently outside UML’s
so it wasn’t too bad. The team produced only the scope.
required AUP artifacts. The requirements model Third, they recognized that RUP isn’t inher-
focused on use cases, business rules, sequence dia- ently documentation-centric. RUP clarifies that
grams, UI specifications, technical requirements, only the required artifacts must be developed;
and a glossary. The business analyst wrote and however, many software professionals often ne-
maintained these documents, keeping them up- glect this. The team had to question every model
to-date as the requirements evolved. The project that RUP suggests to determine the ones it needed
manager maintained the software architecture for the project. It found AM’s “travel light” and
document, which included formally transferring “model with a purpose” principles beneficial, as
point form notes, whiteboard sketches, and argu- well as the “update only when it hurts” and “dis-
ably, models, in the computer-aided software en- card temporary models” practices.
gineering tool. The notes, basically an overview of Fourth, they created an agreed-upon process-

May/June 2010 I E E E S O F T W A R E 77
About the Authors cases, class responsibility collaborator cards, busi-
ness rules, and user interface prototypes simul-
Ioannis T. Christou is an associate professor at Athens Information Technology and taneously. Similarly, they held analysis sessions
an adjunct professor at Carnegie-Mellon University’s Information Networking Institute. His
where use-case modeling, sequence diagramming,
research interests include business intelligence and optimization algorithms and systems,
enterprise software, and data mining. Christou has a PhD in computer sciences from the UI prototyping, and class modeling made sense.
University of Wisconsin at Madison. He’s a member of IEEE, the ACM, and the Technical They also held design sessions on class modeling,
Chamber of Greece. Contact him at [email protected].
state modeling, data modeling, component model-
ing, UI prototyping, and even developing business
code.
Sixth, they complied with the rule of simplicity.
Stavros T. Ponis is a lecturer in supply chain management at the National Techni-
cal University of Athens. He teaches a series of courses on supply chain management, Simplicity is a fundamental value of AUP and AM
operations research, e-commerce, and management of production information systems, in particular, promoting several critical principles
enterprise-resource-planning systems, and operations research laboratories. Ponis has a that dramatically improved the effectiveness of our
PhD in Mechanical Engineering from the National Technical University of Athens. Contact
him at [email protected]. modeling efforts. Instead of specifying everything
possible, we created sequence diagrams that were
just good enough to depict the likely functional-
ity of the automation of the daily tasks, and be-
gan coding from there. Agile modelers assume that
Eleni Palaiologou is a senior project manager of major IT projects at one of the
largest banks in Greece. Her research interests include information systems modeling, programmers can figure out the details during de-
systems analysis, and process modeling and evaluation.. Palaiologou has an MBA from the velopment and therefore focus on issues that might
Athens University of Economics and Business in collaboration with the National Technical not be so obvious. By keeping the models simple,
University of Athens. Contact her at [email protected].
the team worked faster while creating something
of actual value to the programmers—models that
focused on critical issues.
Seventh, they staffed the project with personnel
based perspective for both developers and proj- who can contribute in both modeling and devel-
ect stakeholders. Managers often tend toward opment. Many organizations have separate posi-
prescriptive software processes such as RUP. De- tions for modelers, motivating their staff to focus
velopers, on the other hand, tend toward agile on specialties—a practice that in our experience
techniques such as Extreme Programming and reduces agility. Although RUP states clearly that
AM on the basis of the techniques’ perceived individual developers can and should take multiple
focus on building software. Because manage- roles on a project, in general, most organizations
ment is the decision-making authority, many adopting RUP don’t follow this advice. They tend
developers find themselves in a situation where to introduce positions along the lines of the pro-
management has chosen RUP and forces them to cess’s modeling roles—for example, requirements
follow it. Fortunately, RUP is flexible and can be analyst, system analyst, UI designer, database de-
tailored to be reasonably agile. Still, developers signer—and therefore label people with unique
and project stakeholders must agree on the extent roles, going against the advice of both RUP and
of the tailoring. AUP. People whose only job on a software proj-
Fifth, they successfully implemented the core ect is to produce models tend to overmodel things
disciplines of iterative and incremental develop- for two reasons. First, they naturally want to do a
ment. Experienced modelers might have difficulty good job. Second, there’s a hand-off and therefore
modeling AM practices such as “model in small greater motivation to add more detail to the model,
increments,” “iterate to another artifact,” and detail that likely wouldn’t be needed if the people
“create several models in parallel.” Traditional developing models also wrote the code.
modeling techniques often promote a single- Finally, they adapted AM’s principle of honest,
artifact approach, such as use-case modeling or open communication. Development teams are usu-
user-interface prototyping sessions, and a BDUF/ ally reluctant to follow the “display models pub-
BMUF approach in which you model everything licly” practice with people external to the team,
in detail before coding. Although in theory, fo- often because they’re afraid of what another politi-
cusing on one artifact at a time should have en- cal faction in the organization would do with that
abled the modelers to get it right quickly, practice information. They initially hesitated to communi-
shows this isn’t the case. Instead of use-case mod- cate the models to stakeholders outside the devel-
eling sessions, the team tried to run requirements- opment team owing to anticipated criticism. For-
modeling sessions in which they worked on use tunately, this criticism never materialized. As soon

78 IEEE SOFT WARE w w w. c o m p u t e r. o rg /s o f t w a re

as the team displayed its models publicly, people Unified Process: Success with the RUP, Addison-
realized there wasn’t much to criticize, so the team Wesley, 2004.
4. S. Ambler, “The Agile Unified Process (AUP),”
greatly benefited from publicizing its models. Ambysoft, 2005; www.ambysoft.com/unifiedprocess/
agileUP.html.

O
5. M. Sliger and S. Broderick, The Software Project Man-
ager’s Bridge to Agility, Addison-Wesley Professional,
verall, we found that to succeed in apply- 2008.
ing AUP, the organization’s culture and 6. J. Shore and S. Warden, The Art of Agile Development,
management must be receptive to both O’Reilly Media, 2007.
7. M. Fowler and J. Highsmith, “The Agile Mani-
RUP and to agile methods, and there lies a con- festo,” Software Development, 2001; www.drdobbs.
tradiction; that while most organizations adopting com/184414755.
RUP target a fairly rigid and prescriptive process, 8. C. Jefferies, P. Brereton, and M. Turner, “A Systematic
Literature Review of Approaches to Reengineering for
organizations that adopt agile methods typically Multi-channel Access,” Proc. 12th European Conf.
work in a much more flexible manner. Fortunately, Software Maintenance and Reengineering, IEEE CS
Press, 2008, pp. 258–262.
we found that RUP is flexible enough that it can be
9. S. Ambler, “An Introduction to Agile Modeling,”
customized to be reasonably agile. One immediate Ambysoft, 2005; www.agilemodeling.com/essays/
and direct implication this project had on the or- introductionToAM.htm.
10. S. Ambler, Agile Modeling: Effective Practices for
ganization was the decision of the IT strategy de-
Extreme Programming and the Unified Process, John
partment to include a customized version of AUP Wiley & Sons, 2002.
as the proposed methodology for all small-scale IT 11. S. Ambler, “Big Modeling Up-Front Anti-pattern,”
Ambysoft, 2005; www.agilemodeling.com/essays/
projects in the bank. bmuf.htm.
12. “Microsoft Customer Care Framework, the Fast
Path to Reduced Costs and Increased Productivity,”
References rev. 2.0, Accenture, 2008; http://origin.www.
1. P. Kroll and P. Kruchten, The Rational Unified Process accenture.com/NR/rdonlyres/53058BEA-88B5-425C-
Made Easy: A Practitioner’s Guide to the RUP, 8DE0-91DD70AFF2D3/0/Accenture_CCF.pdf
Addison-Wesley, 2003.
2. R.D. Gibbs, Project Management with the IBM Ratio-
nal Unified Process: Lessons from the Trenches, IBM
Press, 2006. Selected CS articles and columns are also available
3. S. Bergström and L. Råberg, Adopting the Rational for free at http://ComputingNow.computer.org.

ADVERTISER INFORMATION MAY/JUNE 2010 • IEEE SOFTWARE

Advertiser Page Advertising Sales Midwest/Southwest Product:
Better Software 2010 Cover 3 Representatives Darcy Giovingo
Seapine Software Inc. Cover 4 Phone: +1 847 498 4520 US East
Recruitment: Fax: +1 847 498 5911 Dawn Becker
Email: [email protected] Phone: +1 732 772 0160
Mid Atlantic Fax: +1 732 772 0164
Advertising Personnel
Lisa Rinaldo Northwest/Southern CA Email: [email protected]
Marion Delaney
Phone: +1 732 772 0160 Tim Matteson
IEEE Media, Advertising Dir.
Fax: +1 732 772 0164 Phone: +1 310 836 4064 US Central
Phone: +1 415 863 4717
Email: lr.ieeemedia@ Fax: +1 310 836 4067 Darcy Giovingo
Email: [email protected]
ieee.org Email: tm.ieeemedia@ Phone: +1 847 498 4520
Marian Anderson ieee.org Fax: +1 847 498 5911
New England
Sr. Advertising Coordinator Email: [email protected]
John Restchack Japan
Phone: +1 714 821 8380 Phone: +1 212 419 7578 Tim Matteson US West
Fax: +1 714 821 4010 Fax: +1 212 419 7589 Phone: +1 310 836 4064 Lynne Stickrod
Email: [email protected] Email: j.restchack@ Fax: +1 310 836 4067 Phone: +1 415 931 9782
ieee.org Email: tm.ieeemedia@ Fax: +1 415 931 9782
Sandy Brown ieee.org Email: [email protected]
Sr. Business Development Mgr. Southeast
Phone: +1 714 821 8380 Thomas M. Flynn Europe Europe
Fax: +1 714 821 4010 Phone: +1 770 645 2944 Heleen Vodegel Sven Anacker
Email: [email protected] Fax: +1 770 993 4423 Phone: +44 1875 825700 Phone: +49 202 27169 11
Email: flynntom@ Fax: +44 1875 825701 Fax: +49 202 27169 20
mindspring.com Email: impress@ Email: sanacker@
impressmedia.com intermediapartners.de

May/June 2010 I E E E S O F T W A R E 79

View publication stats