Traditionally, application development in the System z environment has followed a waterfall lifecycle. Today, most software practitioners still believe that modern software development practices, like iterative development and Agile development practices, are not applicable to the System z1 environment. To support the System z development community and to make better use of up-to-date techniques, IBM® assigned a team of experts, representing both traditional System z and modern development practice communities, the task of defining a method that employs software development practices currently in use in the System z environment, while embracing modern development principles and tools. This article presents the culmination of that effort: the IBM Rational® Unified Process® for System z (RUP® for System z)2.
RUP for System z provides practitioners with specific software development guidance and a succinct, end-to-end process specifically geared to the System z environment. RUP for System z includes a large set of work product examples -- mostly produced using IBM tools -- taken from an application created in CICS3 COBOL and exposed as Web services, using both the CICS Web Services Assistant and the Enterprise Generation Language (EGL)4.
RUP for System z addresses "green field" development, as well as system evolution that involves architectural changes (including turning an existing capability into a Web service, for instance) or significant impact on existing business processes. However, pure maintenance activities are outside the scope of RUP for System z. For more information on using RUP on maintenance projects, refer to the IBM Rational Unified Process for Maintenance Projects5.
RUP for System z is intended for the whole of the System z application development community, from project managers, architects, and designers to programmers and testers. It covers the full, end-to-end development lifecycle for the System z environment.
RUP for System z is iterative and risk-driven. It focuses on developing the actual software system incrementally in each iteration, as opposed to producing project-related documentation. This facilitates feedback and mid-course corrections, and supports collaboration among the entire development team. This approach concentrates on leveraging existing assets, and on stabilizing the architecture and any high-risk elements early in the project, to avoid late discovery of problems that could potentially lead to project failure. It also emphasizes quality by recommending early and frequent evaluation of the running system. Users, customers, and other stakeholders are involved in the evaluation process to make sure that the project outcome will be consumable and will meet the stakeholders' expectations. In other words, RUP for System z embraces most of the values and practices associated with the Agile development community.
Following a discussion of the reasons why IBM created RUP for System z, this article introduces the method via a roadmap that guides you through the lifecycle of a typical System z development project. An introduction to the RUP for System z Website is also included to familiarize you with everything you need to start applying the method on your own projects.
Why IBM created RUP for System z
System z has been around for more years than just about any computing environment still widely in use. Its development community has been a pioneer in creating and following application development methodologies, long recognizing that process is a prerequisite for producing quality software on a consistent basis. However, although there have been several changes in methodologies used in the System z application development environment since the 1990s, these shifts have largely been related to the traditional waterfall development lifecycle model. So far, it has been a common belief that modern development methodologies, such as RUP, are applicable only to the object-oriented programming world.
In recent years, there have been significant changes in the scope and speed of software development, as well as in related tools and languages. In the current, on-demand business environment, IT organizations are under intense pressure to respond to business demands in as agile a manner as possible, so as to satisfy user needs with speed, precision, and quality products. Consequently, organizations running System z face the problem of integrating traditional and on-demand needs, as summarized in Table 1 below.
Table 1: Problem statement
|The problem of integrating||Traditional needs: Support high-volume, transaction processing
environments with a large number of mission critical applications.
On-demand needs: Maintain flexibility, responsiveness, consistently high quality, ability to leverage existing assets, ability to meet business and user needs.
|Affects||Organizations that run System z across their IT environments.|
|The impact of which is||The development of flawed applications and an inability to deliver on key business priorities and objectives.|
|A successful solution would||Improve flexibility, responsiveness, quality, user satisfaction, competitiveness and ROI.|
To solve the problem defined in Table 1, IBM recently formed a team of experts to:
- Develop a method that makes use of software development practices currently in use in the z environment combined with modern development principles
- Base the new method on RUP6 and its service oriented extension (the IBM Rational Unified Process for Service Oriented Modeling and Architecture, or RUP for SOMA7)
- Address green field development, as well as system evolution with architectural changes or with significant impacts on existing business processes
- Prove the method using a case study taken from a CICS COBOL application
- Show how EGL can be used to create a Web interface
- Show how IBM tools can help implement the new method
- Provide information on how to customize the method if necessary
- Deliver the new method as both an IBM Rational Method Composer7 plug-in and an IBM Redbook
The result is RUP for System z as presented in this article. RUP for System z is based on RUP, an all-encompassing modern process framework applicable to any software development environment. RUP for System z leverages a subset of RUP that is applicable to System z, while adding method elements specific to the System z development environment.
RUP for System z roadmap
The RUP for System z roadmap walks through each phase (Inception, Elaboration, Construction, and Transition) of a typical System z development project. The RUP for System z lifecycle is illustrated in Figure 1. The roadmap provides an overview for each of the elements in the figure.
Figure 1: RUP for System z lifecycle
The activities within each iteration in Figure 1 can be executed in sequence or in any order. Indeed, in RUP, an iteration is not necessarily a sequence of activities; it can be a multifaceted combination of activities, including some that may be done in parallel.
The main goal of the Inception phase is to achieve concurrence among all stakeholders on the project scope and to ensure that the project is both worth doing and possible to do. The Inception phase consists of a number of iterations culminating in the Lifecycle Objectives Milestone.
A typical iteration in Inception includes the following activities, as illustrated in Figure 1:
- Conceive New Project. This activity brings a project from the initial germ of an idea to a point at which a reasoned decision can be made to continue or abandon the project.
- Prepare Project Environment. This activity prepares the development environment for a project, where the development environment includes both process and tools.
- Define Requirements. This activity covers the definition of the project Vision. It drives agreement on the scope of the system and outlines the key requirements. The requirements could be described in term of use cases. In Inception, the main use cases are identified and briefly described. The requirements (functional and non-functional) that do not fit appropriately within the use cases should be documented in the Supplementary Specifications. Once some use cases and supplementary requirements are identified, they are prioritized, so that their order of development can be decided. For instance, use cases that represent some significant functionality, that have substantial architectural coverage (i.e., they exercise many architectural elements), or that illustrate or emphasize a specific and critical point of the architecture, will be developed first.
- Perform Architectural Proof-of-Concept. This optional activity aims at demonstrating the solution's feasibility by building an Architectural Proof-of-Concept and assessing its viability against the architecturally significant requirements.
- Plan the Project. This activity starts with an assessment of the current iteration and a re-evaluation of the risks. It refines the Software Development Plan (covering all project phases and iterations), and creates a fine-grained Iteration Plan for the next iteration or iterations. This activity also drives acquisition of the necessary resources (including staff) to perform the coming iteration or iterations.
At the end of the Inception phase, the Lifecycle Objectives Milestone evaluates the project against the following criteria:
- Stakeholder concurrence on scope definition
- Agreement that the right set of requirements has been captured
- Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate
- Agreement that all risks have been identified and that a mitigation strategy exists for each
The state of some essential work products at the Inception phase milestone are:
- Business Case (100% complete)
- Vision (almost 100% complete)
- Glossary (about 40% complete)
- Software Development Plan (about 80% complete)
- Iteration Plan for the first Elaboration iteration (almost 100% complete)
- Risk List (about 25% complete)
- Use Case Model (about 20% complete)
- Supplementary Specifications (about 20% complete)
- Test Plan (about 10% complete)
- Software Architecture Document (about 10% complete)
- Architectural Proof-of-Concept (one or more proof-of-concept prototypes may be available to address very specific risks)
The main goal of the Elaboration phase is to baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the Construction phase. The stability of the architecture is evaluated through one or more architectural prototypes. The Elaboration phase consists of a number of iterations culminating in the Lifecycle Architecture Milestone.
A typical iteration in Elaboration includes the following activities, as illustrated in Figure 1:
- Refine Requirements. This activity details the requirements of the system in terms of its use cases. Only the use cases that are in the scope of the current iteration are detailed, in order to reach the goal of the iteration. The remaining use cases will be detailed in later iterations. The requirements (functional and non-functional) that do not fit appropriately within the use cases should be detailed in the Supplementary Specifications.
- Define Architecture. This activity starts by defining a candidate architecture (initial system organization), identifying reusable assets, defining the architectural patterns, identifying the architecturally significant use cases, and performing a use-case analysis (also called use-case realization) on each one. This includes identifying conceptual Analysis Elements necessary to express the behavior of each use case. Once a candidate architecture has been defined, the architecture is refined by transitioning from analysis to design activities. The conceptual Analysis Elements are refined into concrete design elements like Modules and Classes (refer to Figure 4 for examples of modules). The goal is also to describe the organization of the system's run-time and deployment architecture, and to maintain the consistency and integrity of the architecture. The activity ends with a review of the resulting architecture, as documented in the Software Architecture Document. Note that architecture and design are documented using the Unified Modeling Language (UML)9. UML diagrams allow you to model both object-oriented and non object-oriented elements such as modules.
- Design Components. This activity addresses the detailed design of one or more components within the scope identified in the Iteration Plan. When services are involved, this activity refines the design with service elements. When databases are involved, this activity identifies the design elements to be saved in a database and designs the corresponding database. When a user interface is involved, this activity models and prototypes the user interface. This activity ends with a review of the resulting design, as documented in the Design Model, and optionally other supporting models like the Service Model.
- Code and Unit Test Components. This activity completes a part of the implementation so that it can be delivered for integration. It implements the elements in the design model by writing source code, adapting existing source code, compiling, linking, and performing unit tests. If defects in the design are discovered, rework feedback on the design is submitted. The activity also involves fixing code defects and performing unit tests to verify the changes. The code is reviewed to evaluate quality and compliance with the programming guidelines.
- Integrate and Test. This activity covers the integration and test of the product. The Integrate sub-activity integrates changes from multiple implementers to create a new and consistent version of an Implementation Subsystem. This is done for any implementation subsystem within the scope of the iteration. When appropriate, this activity also integrates implementation subsystems to create a new and consistent version of the overall system. The Test sub-activity includes the tasks required for testing within a particular scope. The scope could be a given level or type of test, such as Functional Verification Test (FVT) or System Verification Test (SVT). It may also be limited to the components, or portions thereof, that have been implemented or are planned to be implemented during the iteration. It includes the refinement of the Test Plan, definition of test cases and their implementation into test scripts (a test script is a step-by-step instruction enabling the execution of a test case), the execution and evaluation of the tests, and the corresponding reporting of incidents that are encountered. It also includes the definition and implementation of the Installation Verification Procedures (IVPs).
- Plan the Project. See Iteration phase above.
At the end of the Elaboration phase, the Lifecycle Architecture Milestone evaluates the project against the following criteria:
- The product requirements and architecture are stable.
- The key approaches to be used in test and evaluation are proven.
- Test and evaluation of executable prototypes have demonstrated that the major risk elements have been addressed and have been credibly resolved.
- The iteration plans for the Construction phase are of sufficient detail to allow the work to proceed, and are supported by credible estimates.
- All stakeholders agree that the Vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture.
- Actual resource expenditure versus planned expenditure is acceptable.
The state of some essential work products at the Elaboration phase milestone are:
- Glossary (about 80% complete)
- Software Development Plan (about 95% complete)
- Iteration Plans for the Construction iterations (almost 100% complete, at least for the first iteration)
- Risk List (about 50% complete)
- Use-Case Model (about 80% complete, depending on iteration goals)
- Supplementary Specifications (about 80% complete, depending on iteration goals)
- Software Architecture Document (almost 100% complete)
- Design Model (about 60% complete)
- Service Model (about 60% complete)
- Test Plan (about 30% complete)
- Test Cases (about 40% complete)
- Test Scripts (about 40% complete)
- Implementation Elements, including source code (about 40% complete)
- Builds are available (one or more per iteration, for instance).
- One or more executable architectural prototypes are available (to explore critical functionality and architecturally significant scenarios).
- Installation Verification Procedures (IVPs) (about 80% complete)
The main goal of the Construction phase is to complete the development of the system based upon the baselined architecture. The Construction phase consists of a number of iterations culminating in the Initial Operational Capability Milestone.
A typical iteration in Construction includes the following activities, as illustrated in Figure 1:
- Design Component. This activity completes the detailed design of the components, within the scope identified in the Iteration Plan.
- Code and Unit Test Components. This activity completes most parts of the implementation so that they can be delivered for integration.
- Integrate and Test. This activity covers the integration and test of the product, as described in the Elaboration phase.
- Prepare Deployment. This activity defines the Deployment Plan. Its purpose is to ensure that the system successfully reaches its users. The Deployment Plan provides a detailed schedule of events, persons responsible, and event dependencies required to ensure successful cutover to the new system. The activity also includes the definition of a first draft of user support materials and other collateral materials covering the full range of information required by users to learn, install, operate, use, and maintain the system.
- Plan the Project. See Iteration phase above.
At the end of the Construction phase, the Initial Operational Capability Milestone evaluates the project against the following criteria:
- Is this product release stable and mature enough to be deployed in the user community?
- Are all the stakeholders ready for the transition into the user community?
- Are actual resource expenditures versus planned expenditures still acceptable?
The state of some essential work products at the Construction phase milestone include:
- Glossary (almost 100% complete)
- Software Development Plan (almost 100% complete)
- Iteration Plans for the Transition iterations (almost 100% complete, at least for first iteration)
- Risk List (about 75% complete)
- Use-Case Model (almost 100% complete)
- Supplementary Specifications (almost 100% complete)
- Design Model (almost 100% complete)
- Service Model (almost 100% complete)
- Test Plan (about 90% complete)
- Test Cases (about 80% complete)
- Test Scripts (about 80% complete)
- Implementation Elements, including source code (about 95% complete)
- Builds are available (one or more per iteration, for instance).
- The executable system is available.
- Installation Verification Procedures (IVPs) (about 90% complete)
- User Support Material (about 40% complete)
The main goal of the Transition phase is to ensure that software is available for its users. It includes testing the product in preparation for release, and making minor adjustments based on user feedback. This phase focuses mainly on fine-tuning the product, configuration, installation, and usability issues. The Transition phase consists of a number of iterations culminating in the Product Release Milestone.
A typical iteration in Transition includes the following activities, as illustrated in Figure 1:
- Code and Unit Test Components. This activity completes all remaining parts of the system implementation so that they can be delivered for integration.
- Integrate and Test. This activity completes the integration and test of the product.
- Perform Beta and Acceptance Test. This activity covers beta and acceptance testing of the product. Beta Test solicits feedback on the product from a subset of the intended users while it is still under active development. A beta test gives the product a controlled, real-world test, so that feedback from potential users can be used to shape the final product. It also provides a preview of the next release to interested customers. Acceptance Test ensures that the product is deemed acceptable to the customer prior to its general release.
- Package Product. This activity builds and packages the product for release. It produces any artifact needed to effectively learn, install, operate, use, and maintain the product.
- Plan the Project. During the last project iteration, a final Status Assessment is prepared for the Project Acceptance Review, which, if successful, marks the point at which the customer formally accepts ownership of the software product. The project manager then completes the close-out of the project by disposing of the remaining assets and reassigning the remaining staff.
In some cases, it may be necessary to update the system requirements and design. Any significant changes, however, should be deferred to a future generation of the solution to maintain its stability. Refer to the discussion of the Elaboration phase above for information on the Refine Requirements and Design Components activities.
At the end of the Transition phase, the Product Release Milestone evaluates the project against the following criteria:
- Is the user satisfied?
- Are actual resources expenditures versus planned expenditures acceptable?
At the Product Release Milestone, the product is in production, and the post-release maintenance cycle begins.
Some of the essential work products completed at the Transition phase milestone include:
- Risk List
- Test Plan
- Test Cases
- Test Scripts
- Implementation Elements, including source code
- Deployment Unit
- User Support Material
- Installation Verification Procedures (IVPs)
RUP for System z Website
This section introduces the RUP for System z Website, which describes the development process from beginning to end, at different levels of detail. The Website can be generated out of the Rational Method Composer plug-in for RUP for System z.8
The welcome page of the RUP for System z Website (see Figure 2) is structured around the three following sections:
- Learn about RUP for System z. This section includes learning and introductory material related to RUP for System z. It is targeted toward beginners.
- Implement RUP for System z. This section includes materials to help you implement RUP for System z on your project. It is targeted toward advanced practitioners.
- Customize RUP for System z. This section includes materials to help you customize RUP for System z to better address your project needs, if necessary. It is targeted toward project managers and method designers.
Figure 2: Welcome page of the RUP for System z Website
In addition to the three sections -- Learn, Implement, Customize -- and to best satisfy the needs of its different audiences, the Website illustrates the RUP for System z end-to-end lifecycle. It describes a development process from beginning to end, at different levels of detail, as illustrated in Figure 3. At the highest level, an overview diagram presents the big picture. The lowest level shows the complete delivery process, including a detailed Work Breakdown Structure (WBS). In between is a roadmap -- providing a textual description of the process for beginners, as well as a Process Essentials page -- including mostly tables, which is designed to provide advanced practitioners with all the links they need to achieve a specific goal by performing a precise activity or task.
Figure 3: The lifecycle is presented at different levels of detail for different audiences
The three sections -- Learn, Implement, Customize -- of the Website are described below.
Learn about RUP for System z
This section includes the following topics:
- Introduction to RUP and its SOA Extension. This section introduces RUP, including some key modern principles for software development10, and its service-oriented architecture (SOA) extension (RUP for SOMA).
- Why RUP for System z. This section explains the rationale behind the creation of RUP for System z. It also describes the main differences between the traditional waterfall development model and the RUP iterative development model.
- Terminology Mapping between RUP and z. This section maps RUP terminology to equivalent terms used in System z software development process, to simplify the learning process when transitioning to RUP.
- RUP for System z Roadmap. Similar to the approach taken in this article, the roadmap walks through each phase (Inception, Elaboration, Construction, and Transition) of a typical System z development project.
Implement RUP for System z
This section includes the following topics:
- Process Essentials. This page provides advanced z practitioners with all the links necessary to perform specific activities or tasks. This is your process cheat sheet!
- RUP for System z End-to-end Lifecycle. This delivery process is an example of the RUP for System z end-to-end lifecycle. It includes a Work Breakdown Structure illustrated with activity diagrams. It can be used as-is or copied and modified to suit your project's needs.
- Catalog Manager Case Study. This case study provides a simulation of the development of a CICS COBOL Catalog Manager application using RUP for System z. This working application is shipped with CICS Transaction Server3 and is designed to illustrate best practices for exposing CICS applications as Web services. To prove the method, we added one use case (Replenish Inventory) to the existing application, for which we created working COBOL code, and that we exposed as a Web service.
The case study includes numerous work product examples, from business case to source code, shown at different completion states over the project lifecycle, as illustrated in Table 2.
Table 2: Work product examples available in RUP for System z at different completion states
|Software Development Plan||80%||95%||100%|
|Iteration Plans||E1 100%|
|Use Case Model||20%||80%||100%|
|Software Architecture Document||10%||100%|
|Test Cases & Test Scripts||40%||80%||100%|
|Installation Verification Procedures||80%|
Most work products of the Catalog Manager case study have been produced using IBM tools. The following tools are utilized during the project:
- IBM Rational Software Architect is used to create the UML models: use case, analysis, design, and service models. IBM Rational Software Modeler could have been used as well. Figure 4 shows an example of a Class/Module diagram created using Rational Software Architect. Note that modules are modeled using the stereotype <<Module>>.
Figure 4. Catalog Manager Replenish Inventory Class/Module diagram
- IBM Rational SoDA® is used to generate a use-case model survey report in Rational Software Architect or Rational Software Modeler.
- IBM Rational RequisitePro® is used to document and manage requirements.
- IBM WebSphere® Developer for zSeries (WDz) is used to test the Catalog Manager Web services client, as illustrated in Figure 5.
Figure 5: Invoking the Catalog Manager Replenish Inventory Web service
- IBM Rational Manual Tester is used to exercise the test cases.
- IBM Rational Functional Tester is used to automate the test suites.
- Rational Method Composer is used to export the RUP for System z Work Breakdown Structure into an IBM Rational Portfolio Manager Software Development Plan.
- IBM Rational Portfolio Manager is used to tailor the Software Development Plan for the Catalog Manger Project and to detail the Iteration Plans.
- IBM Rational ClearCase® and IBM Software Configuration and Library Manager are used for configuration management.
Finally, the case study illustrates how quickly and simply the EGL4 can be used to develop the Web interface of the Catalog Manager case study application.
Customize RUP for System z
This section includes the following topics:
- Why Customize RUP for System z. This guidance discusses the rationale for customizing RUP for System z.
- How to Create a Project Plan Specific to Your Project. This guidance provides information on how to create a project plan for your very own project, by modifying a project plan exported from Rational Method Composer.
- How to Customize a Process using RMC. This tool mentor provides information on how to customize a process, using Rational Method Composer, to better address your project or organizational needs.
RUP for System z provides practitioners with an end-to-end lifecycle that is easy to implement on z, because it is succinct and is illustrated with numerous examples. Indeed, it includes a complete case study taken from a CICS COBOL application exposed as Web services. The case study includes numerous work products shown at different completion states over the project lifecycle, and demonstrates how IBM tools are used to create these work products.
The RUP for System z lifecycle embodies modern software development principles, while working with practices currently in use in the z environment. In other words, RUP for System z enables customers to leverage Rational's twenty-five years of experience in software engineering and modern software development practices, along with IBM's long-time experience in developing applications in the z environment.
Finally, it is worth mentioning that the RUP for System z lifecycle is applicable outside of the scope of System z, to any development using procedural programming languages.
We would like to acknowledge the contributions of all the reviewers, and thank them for their insightful comments on early drafts of this article. A special thanks to Joe DeCarlo, who led the RUP for System z residency project at IBM in San Jose, California.
1 IBM System z Website: www.ibm.com/systems/z/
2 For more on RUP for System z: - RUP for System z Plug-in: www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/
- Cécile Péraire, Mike Edwards, Angelo Fernandes, Enrico Mancin and Kathy Carroll. The IBM Rational Unified Process for System z. IBM Redbook SG24-7362-00, 2007: www.redbooks.ibm.com/
3 CICS Transaction Server: www.ibm.com/software/htp/cics/tserver/
4 Enterprise Generation Language resources: www.ibm.com/developerworks/rational/products/egl/egldoc.html
5 RUP for Maintenance Projects Plug-in: www.ibm.com/developerworks/rational/downloads/06/plugins/rmc_prj_mnt/
6 Per Kroll and Philippe Kruchten. The Rational Unified Process Made Easy: A Practitioners Guide to the RUP. Addison-Wesley, 2003.
7 RUP for Service Oriented Modeling and Architecture V2.4: www.ibm.com/developerworks/rational/downloads/06/rmc_soma/
8 For more on Rational Method Composer, see the following
- Rational Method Composer Resource Center on IBM developerWorks: www.ibm.com/developerworks/rational/products/rup/
- Rational Method Composer 7.1 Plug-Ins on IBM developerWorks: www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/
- Per Kroll, "Introducing IBM Rational Method Composer," The Rational Edge, November 2005: www.ibm.com/developerworks/rational/library/nov05/kroll/index.html
- Peter Haumer, "IBM Rational Method Composer: Part 1: Key Concepts," December 2005: www.ibm.com/developerworks/rational/library/dec05/haumer/
- Peter Haumer, "IBM Rational Method Composer: Part 2: Authoring method content and processes," January 2006: www.ibm.com/developerworks/rational/library/jan06/haumer/
- The IBM Rational training course PRJ350v2: Essentials of tailoring methods with IBM Rational Method Composer v7.0.1: 9 http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&courseCode=RP522.
9 Unified Modeling Language: www.ibm.com/software/rational/uml/
10 Per Kroll and Walker Royce, "Key principles for business-driven development," The Rational Edge, October 2005: www.ibm.com/developerworks/rational/library/oct05/kroll/index.html
11 Cécile Péraire, "A Roadmap to Method Development," The Rational Edge, February 2007: www.ibm.com/developerworks/rational/library/feb07/peraire/index.html
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
- Global Rational User Group Community