Using the Agile Unified Process in Banking Agile Methods

featureagile 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

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 Thuge 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 1–3 user interface cost, and flexibility. But what if the organiza- time, otherwise it could result in an oversimplified 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 using 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 SOFTWARE Published by the IEEE Computer Society 0740-7459/10/$26.00 © 2010 IEEE 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 IEEE SOFTWARE 73 Figure 1. Project information summary. The Project name Integrated Desktop project involved 23 people spanning a large Project owner Private banking unit portion of the organizational hierarchy. In 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 administrative support), two test managers, five users, a total of 13 use cases. 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 private-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 bene ts and shares it intelligently among different applications 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 project manager made cost and schedule estimates used for iterations in later phases (mostly during elaboration). 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 SOFTWARE www.computer.org/software 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 IEEE SOFTWARE 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- similar document with the “to-be” situation. She ing environment) phases, differences in set-up needed to extensively conferred with the users in developing 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 issues resulted from special settings of the hosted Construction 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 SOFTWARE www.computer.org/software 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 IEEE SOFTWARE 77 About the Authors cases, class responsibility collaborator cards, business 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 modeling, 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 functionality 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 SOFTWARE www.computer.org/software 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. 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. ORUP and to agile methods, and there lies a con- 7. M. Fowler and J. Highsmith, “The Agile Mani- 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 we found that RUP is flexible enough that it can be Press, 2008, pp. 258–262. 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. ganization was the decision of the IT strategy de- 10. S. Ambler, Agile Modeling: Effective Practices for 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,” projects in the bank. Ambysoft, 2005; www.agilemodeling.com/essays/ 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 Advertising Personnel Fax: +1 732 772 0164 Lisa Rinaldo Marion Delaney Northwest/Southern CA Email: [email protected] Phone: +1 732 772 0160 IEEE Media, Advertising Dir. Tim Matteson Fax: +1 732 772 0164 Phone: +1 415 863 4717 Phone: +1 310 836 4064 US Central Email: lr.ieeemedia@ Email: [email protected] Fax: +1 310 836 4067 Darcy Giovingo ieee.org Email: tm.ieeemedia@ Phone: +1 847 498 4520 ieee.org Fax: +1 847 498 5911 Marian Anderson New England Email: [email protected] Sr. Advertising Coordinator 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 IEEE SOFTWARE 79