Do you think that implementing IBM Rational Unified Process,® or RUP,® within an IT organization is a simple, straightforward project? Or do you think of it as a deeply complex, confusing, and frustrating one? You've probably heard both reports. But for those who've called it "complex" and "frustrating," I suggest that the problem lies not with RUP itself, but in the ways the new process is implemented.
Having seen all kinds of development process implementations during seventeen years of IT experience and several RUP adoption projects, I can describe patterns and styles of process implementation that work best as well as the reasons those patterns and styles occasionally fail. Most commonly, failure of process implementations result from a lack of clear guidance and structure, and a misunderstanding regarding "how much" new content can be inserted into the existing process and still achieve the ongoing operational goals for the development project. Add to that the tendency to underestimate the difficulty of adopting new activities and artifacts into the existing development environment. And finally, it can be quite difficult for management and individual contributors to remain persistent and dedicated as they "turn the Titanic" toward a more refined and improved development process.
I believe there is at least one successful way to go about a RUP implementation. This article outlines a repeatable, two-step process for adopting RUP generally in an organization and implementing RUP specifically on a pilot project. The two steps involve two separate project efforts with two distinct primary goals: 1) the adoption of process and creation of a project infrastructure, and 2) the implementation or "instantiation" of the process activities, artifacts, and roles on a pilot project.
This two-step approach is useful in the following ways:
- It is well-suited for an organization that wants to begin following a standard process for its application development activities, whether that is for a new design or for maintaining an existing one.
- It works well for a project team that needs to adopt a new process without overloading itself with too much change and is willing to utilize team members in dual roles for general process adoption and a pilot project implementation.
- It also works well for a project or organization that does not have access to an internal process organization and must rely on itself for development process improvement.
If your goal is to successfully adopt RUP and continue your ongoing project development cycle, then this guide should be of interest.
The process I describe in this paper allows for a slow, incremental, and managed process change effort for a small project team normally assigned to application maintenance. My explanation of this RUP adoption method presents two different perspectives. The first describes an adoption approach to using the Rational Unified Process (RUP) within a maintenance development cycle for an existing application. The second perspective describes the implementation of RUP on an individual project (pilot project) following that maintenance team's development cycle. The goal of this incremental approach to RUP is to move toward adoption within the larger organization that the maintenance development team is part of. I assume that a mentor will be engaged in both of these steps; I include references to resources such as a RUP project mentor brought in via outside consultants from IBM Rational or an IBM partner consulting firm.
If you already believe that RUP can improve your software development process, and thus positively affect the business's bottom line, then you should get comfortable with the idea that RUP can be incorporated into any software development project, no matter whether the project is a green field or maintenance effort.
Based on my experiences with various customer's maintenance development processes, I believe that the current state of any IT organization involved in software development will affect the decisions about the overall approach to RUP adoption. This approach uses a RUP iterative and incremental structure, using the standard four phases -- Inception, Elaboration, Construction, and Transition -- each with its own iteration cycles.
The goals of the new process adoption in the maintenance development process include:
- Stabilize the configuration management environment
- Create regular release cycles for improved planning
- Identify architecture issues earlier
- Institute industry best practices
- Map existing documents to RUP-equivalent artifacts
In working with various projects over the past several years, my group consistently presented a number of RUP concepts that were met with varying degrees of acceptance by the project teams. Here is a list of the basic concept areas, described in terms of the challenges that the development organization typically faces as it adopts RUP into a current project. (Further details and the resulting decisions typically made to maximize project success are included in Appendix A.)
- Embrace change. The organization must be committed to change from the beginning, willing to align its corporate activities -- so that change can occur with minimal resistance -- by sponsoring meetings for updates and discussions and allowing for flexible scheduling to accommodate the changes expected.
- Demonstrate results early in the lifecycle. The organization realizes that its current application development (CAD) workflow is not iterative and incremental, and thus is not meeting the needs of the organization satisfactorily. The organization believes that RUP will allow demonstration of development team results more quickly.
- Scope content/work orders. The iteration scope content is based on grouping the work orders into levels of risk, architectural significance, customer priority, and providing core functionality. Teams need to begin development by following these guidelines and demonstrating the scope content results at the end of each iteration.
- Named project manager. Typically, the CAD workflow is not driven by active project management and therefore cannot be "guided" during the maintenance cycle. One of RUP's main focuses is the role of the Project Manager, who uses iterative project management techniques to guide the project during the development cycle, adjusting for changes in the requirement's/work order's content. The role of Project Manager is vital for this approach.
- Team consensus and management support. Teams typically do not use a common set of best practices for guidance during the maintenance development cycle. The management team must actively support the new process and allow for flexibility to accommodate the behavior change and learning curve, both in project activities and roles that the development team will assume.
- RUP supporting discipline focus. Teams must adopt the Project Management (PM) and Environment (EN) disciplines at the same time as the Configuration and Change Management (CM) discipline.
- Supporting tools. RUP, Rational ClearCase® LT, Microsoft® Project, Microsoft® Word, Microsoft® Excel®, and Microsoft® Visio® can be used successfully to help teams follow and apply this approach.
- Role focus and new behavior flexibility. All individuals on the maintenance development team must be committed to implementing a new process and embracing the change as a team. The project team must be prepared to allocate some percentage of time to act in the role defined in the new maintenance development project team and for the process adoption team.
Preparing for the adoption
We start the effort with a focus on the adoption of process and then continue with preparing for the implementation by creating the process infrastructure for the pilot project. The primary adoption effort occurs in the first phase, Inception. The goals for achieving the Inception milestone are:
- Business problem identification
- Perform assessment
- Plan for process configuration
Process adoption structure
As noted earlier, this approach begins with adoption, followed by implementation. These phases are named accordingly:
- RAP - RUP Adoption Project
- RIP - RUP Implementation Project
Typically, "RAP1" is the first RUP Adoption Project and "RIP1" is the first RUP Implementation Project, or pilot project. We continue naming each new effort with this numbering scheme (see Figure 1).
Figure 1: RAP / RIP project plan
The clear separation of the adoption and implementation is critical for an organization that is not using a process-centric approach and desires to build a reusable "framework" and proper infrastructure for future maintenance development cycles. This is the final outcome of the RAP1 project.
The final outcome of the maintenance development pilot project (RIP1) must be the completion of the requested changes to the system. The goal of process adoption on the development project is secondary to the creation of the revised system changes. The process adoption must be flexible to accommodate the successful delivery of the maintenance changes required to satisfy the stakeholders for each maintenance cycle.
The pilot project is not started until the Construction phase begins (see Figure 2). Both projects (RAP1 and RIP1) run at the same time starting in Construction of RAP1 with the focus on the successful process adoption and delivery of the required changes for the RIP1. Based on the resource availability, you could pursue multiple RIP efforts during the Construction phase. See Appendix E for further details on performing parallel project activities.
Figure 2: RAP / RIP timelines
The Transition phase is focused on harvesting the best practices from the RIP1 effort and modifying the process that will be followed the second time for the maintenance development project named RIP2. The activities for Transition include identifying the process areas that can be classed as "reusable" at a project or enterprise level. It also involves analyzing the process for modifications based on the project team feedback and from the actual results of the activities performed.
Assess the organization
The assessment is to define the disciplines to adopt and lead you to the analysis of each proposed discipline's activities and artifacts. Assessing the organization helps define the problem areas, which are then mapped to a specific discipline(s). The selection is based on the disciplines that will provide the greatest value in the development process improvements. In fact, most organizations today need to start with adoption of the three RUP Supporting disciplines -- Environment (EN), Project Management (PM), and Configuration and Change Management (CM) -- in order for RUP Core disciplines to be adopted successfully.
In the future, as the new corporate organization adoption begins, a Development-Organization (Dev-Org) Assessment will need to be done for the larger application development group. We performed a Dev-Org Assessment as described in RUP, with our "organization" actually being the maintenance development team and some extended members.
The RAP effort begins with the Dev-Org Assessment to determine which problem areas the organization wants to improve or what parts of the current application development (CAD) workflow are not working well. The effort produces an initial version of the Dev-Org Assessment artifact and the initial Business Vision artifact. The Business Vision contains the identified business problems that we want to solve. We use the six best practices of RUP to guide us to the discipline that should be adopted, although the level of content detail we pursue will vary from project to project.
Here is the typical relationship of the six best practices to the maintenance development team:
- Develop iteratively. This is one of the goals of the maintenance development team. They know the benefits and want to adopt this as part of the maintenance cycle.
- Manage requirements. The maintenance development team does not own or update the original requirements for the software.
- Use component architectures. The software is not designed using a component architecture and the existing design is not in a model abstraction.
- Model visually. As stated above, the software is not driven from a model abstraction; rather, design changes are made directly to the application code. The proposed design changes cannot be estimated accurately without some ability to trace to the design elements that will be affected by the changes.
- Continuously verify quality. By demonstrating the executable product at the end of each iteration, we improve the odds for meeting the stakeholders' criteria. In addition, we create test plans early in each iteration and execute those plans at the end of each iteration, improving the quality as we go, rather than waiting until the end to perform all testing activities.
- Manage change. The software is being stored in a version control system that is not reliable. The maintenance development team has experienced several storage failures, causing many hours of lost work. We typically capture some simple metrics from IBM Rational ClearCase LT and suggest a simple change management process for the maintenance development team to follow for the RIP1. We plan to analyze the change management activity during the RIP1 and make recommendations about how and when it would add the most value to the development process.
Core Inception artifacts
The artifacts -- Business Vision, Risk List, Glossary, and Dev-Org Assessment -- will be the primary output artifacts from the Inception phase. They are vital for establishing the initial objectives for process adoption and to assist with planning for the future activities. See Appendix B for detailed artifact descriptions.
The project efforts follow guidelines from RUP and produce various artifacts to support the process adoption. Each has a significant purpose to support the adoption effort. These artifacts include:
- Iteration plans and assessments for the RAP1
- Development infrastructure for the RAP1
- Workstation setup for the RAP1
- Microsoft Project Plan for the RAP1
- Action items list for the RAP1
- Configuration management plan for the RAP1 artifacts
- Initial development case for pilot project, RIP1
- Maintenance development team concepts training
The maintenance development team should be trained together as a group, immediately following the assessment activities. This early training helps ensure a common knowledge base for the team to start from.
- Project environment preparation
The project environment has to be set up for the adoption. This includes hosting RUP on a Web server that the team can access and placing the adoption artifacts under ClearCase control. A RAP workstation setup includes the ClearCase LT client, the ability to access RUP via a Web browser, and the ability to view MS Project Plans via HTML copy.
Closing the Inception phase
The Inception phase closes with an assessment of the iteration and phase goals and objectives. The goals and results achieved for the Inception milestone are:
- Identified business problems
- Results of assessment
- Plan for process configuration
Let's consider what is involved in each of these:
Identified business problems:
- Unstable configuration environment
- Irregular release schedules
- Identify architecture issues earlier
- Lack of industry standards use or best practices
- Lack of risk mitigation approach for application development and maintenance
- Lack of controlled change management during the build cycle
Results of assessment:
If you'd like to see the Dev-Org Assessment artifact, Assessment Conclusions, for details on problems and recommended solutions, feel free to contact me at email@example.com.
- Environment (3 issues)
- Project management (4 issues)
- Change and configuration management (3 issues)
Plan for process configuration:
This objective includes the proposed plan for the process to follow for the first adoption project. This is the identification of the activities and artifacts that will help solve the business problems we have found:
- Business Vision. Justifies process adoption activities for the project
- Risk List. Helps to address risk earlier and used to guide the process
- Glossary. Assists in sharing common language for everyone, external or internal
- Development Infrastructure. Used to describe the environment that the team uses for the process adoption project, focusing on:
- Workstation setup
- Operational requirements
- Configuration Management Plan. Used to describe how we will version control and manage changes to our RAP1 artifacts
- Iterative Project Plan for RAP1
Prepare for implementation
We start preparing for the implementation by creating the process infrastructure for the pilot project. This is the Elaboration phase for the RAP effort, which focuses on creating the process infrastructure, or "architecture," and it includes the creation of pilot project artifacts.
The goals for achieving the Elaboration milestone are:
- Determine exactly what activities need to be performed and which artifacts need to be produced to follow the new PAD workflow.
- Develop the artifacts that will be used on the RIP1
- Identify necessary roles required for the RIP1
- Define resource allocations for the RIP1
- Create MS Project Plan for implementation on RIP1
- Review updated RAP1 artifacts
Process implementation structure
The Elaboration phase of the RAP is focused on the creation of the process artifacts for the pilot project and the completion of the process infrastructure. Using the information from our analysis and assessment during Inception, we begin to identify and align RUP activities and artifacts we proposed in Inception, as defined in the Development Case, with the Current Application Development (CAD) workflow activities and documents. The maintenance development team will use an existing Visio diagram that was previously produced and update it to reflect their actual, current flow of activities and the documents that they have to perform and create during the maintenance development cycle. This will become their CAD workflow (see Appendix C). If no previous documented development process workflows exist, the project team must be able to visually describe the process in order to determine how best to merge the new RUP activities and artifacts.
Workflows in the projects I've studied followed a waterfall approach, which is something that the maintenance development teams knew had to change. The mapping between the activities and artifacts must occur at a phase level. We created new workflow diagrams in relation to RUP phases. This will allow us to build a project plan unique to each phase and will help the maintenance development team focus on shorter time periods of a phase and iteration versus the longer two or three months for their normal lifecycle. It will also provide a means for the development team to learn the new process by visually following the flow for guidance when performing activities and managing artifacts.
As part of RUP adoption, the goal of this architecture activity is to produce a final combined workflow that the pilot project will follow for the new development process. The "architecture perspective" is attached to the concept of a framework that is being built for the process implementation pilot project (RIP). Another goal is to produce the necessary templates and examples that the team will need to produce and modify as part of the new development process.
Building the process infrastructure
Building the process infrastructure has one purpose: to help ensure the success of the pilot project, the RIP. If the RIP effort fails then the likely success of future adoption efforts is lessened. The RIP effort is driven by the mandated delivery of a new set of changes to the application. These changes will impact many stakeholders and may impact other critical areas of a company. The only required goal for the maintenance development effort is delivery of those changes, not the success of the process implementation. The process implementation must happen successfully in parallel with the delivery of the required application changes.
The RIP effort is meant to be repeated for each ongoing maintenance development cycle. Each project cycle will involve improving the newly adopted or existing process, by adding more disciplines or modifying the current process disciplines. However, the primary success criterion is delivery of the required changes for the application with additional focus on the process improvement area.
Core Elaboration artifacts and activities
Core Elaboration phase artifacts primarily include three RIP artifacts, but also include plans, guidelines, and additional activities.
There are three Core RIP artifacts that need to align for the pilot project to be successful. These artifacts provide us the correct information to lead the development team through the new process, in an iterative manner. The artifacts for the RIP effort include the Development Case, the MS Project Plan, and the Proposed AD Workflow, as shown in Figure 3. See Appendix D for detailed artifact descriptions.
Figure 3: Three core artifacts for RIP
During Elaboration we will also produce other artifacts to support the adoption and implementation efforts. These include:
- Communication Plan for RAP1
- Software Development Plan for RIP1
- Guidelines for RIP1
- Iteration Scope Content criteria for RIP1
- Status Assessment template for reuse
- Risk List template for reuse
- Iteration Plan and Assessment templates for reuse
- Action Items template for reuse
- Development Infrastructure template for reuse
- Introduce simple change management process
The maintenance development teams from the case study projects discussed and developed a simple change management technique to handle change requests during the build cycle not related to an assigned work order. The new process technique simply directs the developers to send an email to the Project Manager (PM) describing the change identified and the level of effort/complexity. The action is either correct at the same time as the existing work order or the PM will enter a new change request for the work to be performed at a later time.
- Iteration scope content
An activity not directly related to any of the adopted disciplines is to define the iteration scope content criteria. This activity is focused on defining the attributes of the work orders that will help to scope them into iterative "chunks" of work. These will be ranked as high risk, high customer priority, provide core functionality and high architectural significance to the software design, and will be the work performed during the Elaboration iteration(s).
Close out the Elaboration phase
The Elaboration phase closes with an assessment of the iteration and phase goals and objectives.
Goals achieved for Elaboration
The goals and results for achieving the Elaboration milestone are:
- Determine exactly what activities need to be performed and which artifacts need to be produced to follow the new PAD workflow:
- Use CAD Workflow document and new RUP Development Case to produce an aligned RUP Development Case for the new process description.
- Produce the PAD workflow that visually represents the combined artifacts and activities in relation to the phase workflow.
- Develop the artifacts that will be used on the RIP1:
- Includes guidelines, templates, examples, checkpoints, tool mentors, whitepapers, concepts, activities.
- Initial Software Development Plan.
- Identify necessary roles required for the RIP1:
- Map maintenance development team members into the corresponding RUP roles.
- Define resource allocations for the RIP1.
- Create MS Project Plan for implementation on RIP1:
- This plan reflects the scheduling of activities for the new PAD workflow with the assigned roles.
- Review updated RAP1 artifacts:
- This includes the Business Vision, Glossary, Risk List, Dev-Org Assessment, Capability Matrix and Development Infrastructure/Workstation Setup.
Prepare for the RAP1 Construction phase
At this point you have all of the elements in place for your process infrastructure and the pilot project artifacts. The Elaboration phase is completed with an Iteration Assessment of E2 and then an Elaboration phase assessment.
The next steps will be a kickoff meeting for the Construction phase for the RAP1 and an Inception kickoff meeting and Iteration 1 planning meeting for the RIP1. The focus becomes narrowed on the application change delivery process and results. The process adoption team, mainly the process engineers, must spend most of their time helping the development team follow the new guidance and remove obstacles for the successful delivery of the design changes. Their goal is to ensure that the process is implemented and the team achieves their primary goal: delivery of a new version of the application. The development team must also work to implement process with the guidance of the process engineers, seeking to achieve the same goal of process implementation and successful delivery of design changes. Together they will reach the first step towards an improved development process.
If you need further assistance or possible reusable project artifacts other than the ones attached to this paper, please feel free to contact me at firstname.lastname@example.org.
Appendix A: Details and the resulting decisions typically made to maximize project success
- Embrace change
An organization is an abstract representation of a group within a company. In the case study projects, the organization typically consists of the development project team and some extended members, roughly twelve people. They are solely responsible for the maintenance development of each set of changes to the Web-based application. The development project team includes the core developers, around eight people. This development project team is made up of senior analysts and developers, and they belong to an application development group within a larger corporate organization. Once the maintenance development team achieves success, the corporate application development group will begin adoption at a broader level, using RUP for other maintenance efforts and new development.
- Demonstrate results early in the lifecycle
One of the benefits of RUP is the iterative and incremental structure which produces immediate results in satisfying stakeholder needs -- i.e., work orders and change requests. For a maintenance development cycle following a waterfall approach, it does provide the ability to produce immediate results.
- Scope content/work orders
The maintenance development team uses a set of work orders as the "requirements." The work orders are not grouped or categorized in any particular order other than by submitting organization. The work orders almost equate to a change request as defined by the Rational ClearQuest tool.
- Named project manager
There must be one primary Project Manager (another to act as backup) that will use at least 50% of his time for mentoring on the role of Project Manager and performing the tasks to "guide" the development project. An additional role of RUP project mentor must exist in order to ensure success. This role is held by someone with prior successful RUP adoption experience, possibly an internal person with the development group or an outside resource from a RUP mentoring organization. The remaining project management effort is the responsibility of the RUP Project Mentor, who guides the primary Project Manager during the adoption and implementation projects as well as mentors the development group's Process Engineers.
- Team consensus and management support
The development project team and the management team should be in agreement about following a common set of best practices to support the new project development process. This is the foundation for RUP in the ongoing adoption and implementation at a corporate organizational level.
- RUP supporting discipline focus
The maintenance development team is using a version control tool that is not reliable. As Configuration and Change Management (CM) is one of the supporting disciplines in RUP, it is assumed that it will need to be adopted prior to the Core RUP disciplines. We will only adopt parts of the Configuration Management aspect of the discipline and address a simple change management process to capture changes made during the maintenance development cycle for activity not related to a work order item.
- Supporting tools
The Rational tools defined were already purchased by the case study customers and they were familiar with the use of the Microsoft tools. The artifacts produced by Microsoft Visio could be created by using Rational Rose or XDE. Migration of the models will be a future project when more RUP disciplines are adopted. Rational ClearCase LT is implemented to support the CM discipline adoption and RUP is being implemented to support the EN discipline. Microsoft Project will serve to create project plans to support the PM discipline adoption. Microsoft Word and Excel will support all disciplines for creation of various artifacts.
- Role focus and new behavior flexibility
Since the focus is on roles in RUP, identifying roles early is a key to changing the team's "behavior" towards following a new process. The process adoption project team consists minimally of one Project Manager, one Process Engineer, and one Configuration Manager. The case study projects allocated one person at 50% for the Project Manager role, two people each for the Process Engineer role (25% and 50%), and two people for the Configuration Manager role (25% and 75%). We added two people for the RUP Adoption Project Elaboration phase to act as the Designer role (25% for each). The same people will continue at these rates through the first pilot project and will perform development duties for the remainder of their time.
Appendix B: Core Inception artifact descriptions
The purpose of this paper is to identify the objectives of the organization in the adoption of RUP. It communicates the fundamental "whys and whats" related to the project and is a gauge against which all future decisions should be validated. It discusses the adoption of process, standardization of documents, and the use of iterative development. It describes the goals to achieve and the customer/stakeholder needs. It also describes, by RUP discipline, each of the decisions that will guide the adoption project. The Business Problems defined here describe the areas that the assessment will validate as possible improvements to achieve.
This artifact is used to describe both Direct and Indirect Risks, with mitigation strategies for each. This is reviewed and updated at the end of each iteration. This artifact is very critical for raising awareness of the impending process changes. The project team will begin to view the adoption effort just as they would a development effort: address high risks first. High risks that you are likely to encounter include: lack of RUP understanding in general, fear of change, organizational changes, poor management sponsorship, lack of ownership at project level, poor project management techniques, lack of "teaming" attitude, and lack of desire for best practice use or standards definition. This central artifact is owned by the RAP project manager and continuously communicated to the team and upper management.
This artifact should be started during the first assessment meeting, if not beforehand during informal planning meetings. This is how you begin to get the team focused on sharing a common language. This provides a common knowledge base of terms and definitions that support the development environment communication channel. RUP will introduce new terms as well and we always refer back to RUP during discussions of what something means. If not in RUP, it is best defined in the Glossary for future reference.
The Dev-Org Assessment describes the current status of the software organization in terms of current process, tools, peoples' competencies, peoples' attitudes, customers, competitors, technical trends, problems, and improvement areas. This list is all inclusive and may not necessarily be needed by every project/organization. It is best to define and to rank the importance of each improvement area and only focus on those that will help to add value for solving the problems. This assessment, for the case study projects, was only performed for the maintenance development environment, not the larger corporate application development organization. An assessment would be performed later at a corporate level that would include all projects in the development organization.
As part of the assessment, we perform an initial capability assessment and plan for improvement. This is captured in the Capability Plan matrix (see Figure 4).
Figure 4: Capability Plan matrix
This artifact is produced to support the future training and mentoring activities by reflecting an ongoing improvement in the skill set of the process adoption project team members. It is not meant to be a tool to measure each team member against the others but as a way to help the team member plan for improving their skill set to support the larger effort of process adoption. Many of the original process adoption project team members should assist in "seeding" the other adoption efforts at the corporate organizational level as mentors.
Appendix C: The Current Application Development (CAD) workflow
Appendix D: Three core RIP artifact descriptions
Development Case (Dev-Case)
The purpose of this artifact is to provide a description of the new process in terms of activities, artifacts, and roles. The artifact contains the activities from the new RUP disciplines and from the CAD workflow. This artifact does not tell us when each activity is performed, but does describe the combined activities that the adoption team has agreed to implement on the pilot project. We will describe the artifacts to be managed by discipline and the roles responsible for ownership of each artifact. We added a section for the activities to be performed and the artifacts that would have to be created from the CAD workflow. The Dev-Case helps to ensure that you describe all of the activities, artifacts, and roles for the entire process. Much of the input will come from the CAD workflow artifact and from the original analysis of the disciplines during Inception.
MS Project Plan
This artifact shows the calendar schedule for workflows/activities/tasks and dependencies. It is used to make role assignments to tasks in the activities. The Project Plan gives us a sense of where in time the activities need to occur, such as which phase to perform or not perform certain activities in. It describes the various dependencies between the tasks, activities, and workflows that constrain the scheduling of resources.
Proposed AD workflow
This artifact shows the visual representation of the workflows and artifacts in relation to the timing and order of their performance. It provides a way to visually identify the various parts of the process in relation to the phase they are performed in. The Proposed Application Development (PAD) workflow is described in four separate diagrams. Each diagram is for one specific RUP phase: Inception, Elaboration, Construction, or Transition. They display the workflows and artifacts that support the new development process. The artifacts are related to the Workflows that they are created or modified in. The activities that are performed within each workflow are described in the Dev-Case. The roles, as defined by RUP, are shown in relation to the general parts of the workflow that they are involved in. All of this information is captured in the Dev-Case and translated into the PAD workflow (see Figure 5).
Figure 5: Proposed Application Development (PAD) workflow
Appendix E. Parallel project profile
For the most efficiency, you would run a parallel track of adopting more of RUP disciplines and implementing on more projects. This is dependent on resources. If you want to continue the adoption efforts, you will have to run a RAP and RIP effort at the same time.
There are several different paths to follow, based on your resource availability. This path describes the approach as follows:
We start with RAP1 for the EN, CM, and PM disciplines of RUP. When complete, we proceed with the RIP1 effort, with the EN, CM, and PM disciplines.
When RIP1 completes, we will start another RAP effort, for another desired discipline, such as Requirements Mgmt (RM). While this is proceeding, we would perform another RIP2 effort, where we would improve the process we just followed for the same disciplines, EN, CM, and PM. The next round would be implementing the new discipline adopted from the RAP2 on the maintenance project, along with the previously adopted disciplines. This means RIP3 would implement the same disciplines, EN, CM, and PM, and add the new one, RM. We would repeat this pattern and RIP4 would be implementing the same four disciplines as RIP3. We would run RIP4 during RAP3.
This option is slightly different. We start with RAP1 for the EN, CM, and PM disciplines of RUP. When completed, we proceed with the RIP1 effort, with the EN, CM, and PM disciplines. We also proceed with another RAP effort (RAP2) for the next discipline.
When RIP1 completes, we will proceed with another RAP effort (RAP3), for another desired discipline, such as Test. While this is proceeding, we would also start another RIP effort (RIP2), where we would improve the process we just followed for the same disciplines, EN, CM, and PM, and add the RM discipline from the RAP2 effort.
The next round would be implementing the new discipline adopted from the RAP3 (Test) on the maintenance development project (RIP3), along with the previously adopted disciplines. We would also run another RAP effort (RAP4) for the next discipline(s) to adopt.
We start with RAP1 for the EN, CM, and PM disciplines of RUP. When complete, we proceed with the RIP1 effort, for the EN, CM, and PM disciplines. We also proceed with another RAP effort (RAP2) for the next discipline.
When RIP1 completes, we will proceed with another RAP effort (RAP3), for another desired discipline, such as Test. While this is proceeding, we would start another RIP effort (RIP2), where we would improve the process we just followed for the same disciplines, EN, CM, and PM, and add the RM discipline from the RAP2 effort. We would also start a new RIP effort (RIP 3) for the original disciplines. This assumes that we determine and agree that the new project (not the maintenance development project) will adopt the original disciplines we defined for the maintenance project process. The basic disciplines of EN, PM, and CM are always a good foundation to adopt first for the remaining disciplines to be grounded on.
The next round would be implementing the new discipline adopted from the RAP3 (Test) on the maintenance development project (RIP4), along with the previously adopted disciplines. We would also run another RAP effort (RAP4) for the next disciplines to adopt and we would start the next RIP effort (RIP5) round for the new project, and also add the discipline adopted in RAP2 (RM). Not shown here would be the next steps of starting another RIP effort (RIP6) for the maintenance development project for the remaining disciplines (A&D, Impl, Deploy). We would also start another RIP effort (RIP7) for the new project for the previously implemented disciplines (CM/EN/PM/RM) and add the next discipline (Test). The final effort would be implementing the previous disciplines with improvements and adding the remaining three disciplines (RIP8 - A&D, Impl, Deploy).
This is the scenario that would require the largest resource need and would need a firm commitment by management to support ongoing process improvement activities.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.