For more than ten years, the IBM Rational Unified Process®, or RUP®, team has been developing method frameworks by "drinking its own champagne;" that is, by applying principles, processes, and techniques that RUP itself advocates for software development. However, developing a method framework like RUP is not quite the same as developing a software application.1 Over the years, the RUP team has adapted its own processes and techniques to the specific needs of method development.2 With the availability of IBM Rational Method Composer3 (RMC), an increasing number of IBM internal teams and customers are defining or customizing methods. Therefore, there is a growing need for guidance on method development.
This article proposes an approach to method development based on my experience in developing methods on the RUP team. This approach is presented via a roadmap that guides you through the lifecycle of a typical method development project. Following a discussion of the key differences and similarities between method and software development, and a presentation and definition of the essential work products produced during a method development project, I will walk through each phase (Inception, Elaboration, Construction, and Transition) of a typical method development project.
The approach to method development I present in this article is iterative and risk-driven. It focuses on developing the actual method incrementally in each iteration, as opposed to simply producing project-related documentation. This facilitates feedback and mid-course corrections to the project's plan or direction; i.e., agility. This approach concentrates on leveraging existing assets, and on stabilizing the Method Architecture and any high-risk method 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 method through reviews and testing.
I've defined this proposed approach with RMC in mind, both to ensure consistent terminology between the method and the tool, and to guarantee that the approach can be easily implemented using RMC. However, this approach is widely applicable outside of the context of RMC: You could use it to write a method book, for instance.
The scope of the approach supports defining new methods from scratch, as well as making significant customizations of existing methods; for example, extending RUP to Service Oriented Architecture (RUP for SOA), or extending RUP for SOA to the System z (RUP for z). However, the approach does not address the complex problem of integrating several existing methods into a unified one. Also, this approach is not targeted toward straightforward customizations,4 like the modification of an existing method for a given project based on the tailoring of a work breakdown structure or project plan.
Method versus software development
The key principles of business-driven development, as defined by Per Kroll and Walker Royce5 for software-intensive systems, remain generally applicable in the context of methods. Therefore, they serve well as guides to improved method project results. These principles are:
- Adapt the process. It is critical to right-size the development process to the needs of the project. More is not better, less is not better. Instead, the amount of formal procedure, precision, and control applied to a project must be tailored according to a variety of factors including the size and distribution of teams, the amount of externally imposed constraints, and the phase the project is in.
- Balance competing stakeholder priorities. It is important to balance often conflicting business and stakeholder needs, as well as balancing custom development versus asset reuse in the satisfaction of these needs.
- Collaborate across teams. It is important to foster optimal project-wide communication. This is achieved through proper team organization and by setting up effective collaborative environments.
- Demonstrate value iteratively. An iterative process allows the development team to better accommodate change, to obtain feedback and factor it into the project, to reduce risk early, and to adjust the process dynamically.
- Elevate level of abstraction: Elevating the level of abstraction helps reduce complexity as well as the amount of documentation required by the project. This can be achieved through reuse, the use of high-level modeling tools, and stabilizing the architecture early.
- Focus continuously on quality: Quality must be addressed throughout the project lifecycle. An iterative process is particularly adapted to achieving quality since it offers many measurement and correction opportunities.
While applying these principles to method development, it is important to keep in mind its differences and similarities compared with software development. The most important difference is probably the fact that method development focuses on producing textual and graphical content, all connected by a network of links and usage threads and supported by a presentation scheme; while software development focuses on producing code. There is no need to write and test code during a method development project, but there is still a need for testing all links and usage threads.
Many software requirements techniques are applicable to methods. Use cases, for instance, can be applied to define the scope of the method, identify the different types of practitioners (i.e., typical users) that will be using the method and the goals they want to reach by using the method, and to define how the practitioners will interact with the method to reach their goals. Usability requirements can then be based on the use-case scenarios and some usability factors (ease of learning, retention of learning over time, speed of scenario completion, or subjective satisfaction). Other non-functional requirements are also important, like complexity (modulating the complexity level of the method so it will be accepted by its audience), composability (the ability to compose the method from existing method plug-ins), or localizability (the ability to make adaptations to the method due to regional differences).
Because of the fairly static nature of a method, static analysis techniques -- especially method review -- play an essential role in method quality. Static analysis consists in analyzing the method elements to verify that they satisfy some explicit or implicit properties, such as content correctness, good content presentation, or compliance with authoring guidelines. Static analysis can be either manual, like reviews, or automated like spelling and grammar checking. In addition, the application of dynamic verification techniques such as testing remains applicable. For instance, if the method is presented to the practitioners through a website, testing may include some functional testing (e.g. the method is tested against use-case scenarios) and usability testing (e.g. use-case scenarios are tested by different user groups against usability factors).
At the architecture and design level, there are a lot of similarities between method development and software development. For instance, architecting a method library, like the RMC library including RUP and its extensions, is comparable to architecting a software library of reusable components. The same care should be given to the organization of the architecture into loosely coupled and highly cohesive components, in order to improve comprehension and to increase flexibility and opportunities for re-use. A very significant aspect of Method Architecture is its resilience to change and ease of evolution. Methods are expected to need corrections and additions over time, especially in today's world with its ever-changing processes. You might, for instance, need to change an existing method in order to incorporate compliance and governance at some point.
Finally, managing a method development project is not fundamentally different from managing a software development project. The same principles of iterative and risk-driven development can be successfully applied to help the team focus on delivering incremental value. The particularity of a method development project, however, is that it deals with at least two distinct lifecycles: the project lifecycle followed by the method development team, as well as the lifecycle of the method under Construction. The project manager needs to be intimately familiar with both lifecycles, which could be achieved by having the project manager and method designer roles performed by the same person.
Method development work products
This section presents the essential work products produced during a method development project. I distinguish the work products that are specific to method development from the ones that are relevant to most types of development effort (in order to define the project vision and schedule, for instance).
Method-specific work products
A method is primarily defined in terms of Method Elements. A Method Element could be a Content Element (Role, Task, Work Product, or Content Guidance), or a Process Element (Activity, Capability Pattern, Delivery Process, or Process Guidance). Refer to Table 1 for definitions of the different types of Method Elements.
|Content Element||Process Element|
A Method Element can be seen from two different and equally important perspectives: from the perspective of the Method Designer, who defines the method structure and hence identifies Method Elements and their relationships; or from the perspective of the Method Author, who writes the description (i.e., textual and graphical content) of the Method Elements. This second perspective is particularly significant since a large proportion of the method development effort is spent authoring Method Elements. For this reason, a separate work product called Method Element Description is used to refer to the content of a Method Element (even though the Method Element Description work product is included in the Method Element work product).
The other essential work products specific to method development are summarized in Table 2, together with the role responsible for each work product. Additional information on these work products follows Table 2.
Outline of the method, identifying candidate method elements, and possibly including some of their relationships and early description.
|Method Designer |
Oversees the definition of the overall method. Synonyms: Method Architect, Method Engineer, Process Engineer.
Well-formed definition of a method in terms of its Method Elements (including their description) and their relationships, and characterization of one or more Method Configurations. In RMC, a Method Definition is a composite work product encompassing all Method Plug-ins and Method Configurations relevant to the method under construction.
Method Web Site
In RMC, a Method Web Site is automatically generated from a Method Definition (one Method Web Site could be generated per Method Configuration).
Note that this work product depends on the presentation scheme. If you are writing a method book, for instance, the Method Web Site is replaced by a Method Book.
|Method Element Description|
Description (i.e., textual and graphical content) of a Content Element.
Writes the content of a method element.
Early in the project, it is recommended to outline the method using a Method Sketch. The goal of the Method Sketch is to help the team identity candidate Method Elements and some of their relationships, and to propose an early description for some of the key elements. To do so, and depending on the project type (creation of a new method from scratch, extension of an existing method with content elements only, extension of an existing method with content and process elements, etc.), the Method Sketch may take various forms. For instance, it may include one or more of the following elements: a walkthrough of the lifecycle; a brief description of candidate roles, tasks, and work products, and their relationships; a list of candidate method guidance (templates, examples, whitepapers, etc.); an early Work Breakdown Structure (WBS); or a mockup of the Method Web Site. The Method Sketch could be documented on a white board; in a word processor document, spreadsheet, or visual model; or using any other support. This free framework is meant to encourage creative thinking and allow the team to define and review some first sketches of the method using the content, format, notation, and support that best fit their needs and skills. Once the new method, or part of the method, starts to emerge from the Method Sketch, it is time to launch Rational Method Composer, in which the method is more formally and completely defined. The Method Sketch could be abandoned at this point, kept to explore other ideas, evolve into a method roadmap (process guidance), or simply evolve into the list of all the Method Elements to be authored, for instance. In that latter case, it could be used to assign responsibility and track progress.
A Method Definition is a well-formed definition of a method in terms of its Method Elements (including their description) and their relationships. A Method Definition also characterizes one or more configurations or versions of the method by identifying, for each configuration, which elements are presented to the practitioners and how. In RMC, as illustrated in Figure 1, a Method Definition is a composite work product encompassing all Method Plug-ins and Method Configurations relevant to the method under Construction. In other words, a Method Definition corresponds to the subset of the RMC Library relevant to the method under Construction.
A Method Plug-in is a well-formed definition of a component of a method (or of the entire method if the method is defined using only one component) in terms of its Method Elements (including their description) and their relationships. In RMC, a Method Plug-in is a container for Method Packages which, in turn, contains Method Elements and possibly other packages. Method Plug-ins and Method Packages allow organizing the Method Elements at the appropriate level of granularity. This level of granularity needs to be carefully thought through with reuse in mind. Indeed, Method Plug-ins and Method Packages are the reusable components of a Method Configuration.
A Method Configuration is a characterization of a version of the method (like RUP for Small Projects and RUP for Large Projects). In RMC, a Method Configuration defines how to compose a Method Web Site based on the Method Elements included in a selection of Method Plug-ins and Method Packages (since you may not want to publish all the Method Elements defined in the method in the context of a given configuration). The Method Configuration also defines the views that will be presented in the Method Web Site tree browser.
The Method Web Site is the main outcome of a method development project. It makes the newly defined method, or method framework, available to the practitioners through a set of interconnected webpages. In RMC, a Method Web Site is automatically generated from the Method Definition (one Method Web Site could be generated per Method Configuration). Figure 2 provides an example of a Method Web Site. Note that the form this work product takes depends on the presentation scheme. If you are writing a method book, for instance, the Method Web Site is replaced by a Method Book.
To summarize the role of the different constituents of a Method Definition, I'll use the analogy of a bookstore specialized in selling book sets at a discounted price: A Method Plug-in could be compared to a bookstore department (travel, comics, kids, etc.), a Method Package to a set of books packaged to be sold together, the Method Element to an individual book, the Method Configuration to your shopping list, and the Method Web Site to the shopping bag full of books that you take home after shopping.
Figure 1: Example of Method Definition for RUP for z in RMC, including selection of elements to be published in the RUP for z Method Web Site
Figure 1 provides an example of RMC Method Definition for RUP for z, including three Method Plug-ins (rup, rup_for_soa, and rup_for_z, because the rup_for_z plug-in is defined by extending both rup and rup_for_soa) and one Method Configuration (RUP for z Configuration). Even though the Method Definition includes three Method Plug-ins, only the rup_for_z plug-in is in the scope of the RUP for z method development effort. (The rup and rup_for_soa plug-ins are out of scope because they will not be modified during the project). The RUP for z Configuration determines the content of the RUP for z published website. In this simplified example, the website will include the content elements of the Method Content package of rup (the Processes package of rup having been filtered out), the content elements of the Method Content package of rup_for_soa (the Processes package of rup_for_soa having been filtered out), as well as all the method elements (from both Method Content and Processes packages) of rup_for_z. The practitioners will be able to navigate the website through the navigation tree shown in the View column in Figure 1.
Figure 2 shows an example Method Web Site for RUP for z, which has been generated from the Method Definition presented in Figure 1.
Figure 2: Example of Method Web Site for RUP for z
In the case of a new method built from scratch, the Method Definition is empty at the beginning of the project. In the case of a method customization, the Method Definition already contains the plug-ins relevant to the existing method -- but not the existing configurations, however, since a configuration is specific to a given method and consequently is not a reusable asset. For instance, in order to create a customized version of RUP for z, you would start with a Method Definition, including the plug-ins shown in Figure 1. Then you would add, at a minimum: one new Method Plug-in (referencing the existing plug-ins: rup, rup_for_soa, and rup_for_z), in order to define the Method Elements specific to your new method; and one new Method Configuration, in order to configure your new Method Web Site. Your new Method Elements could be built from scratch or by leveraging some elements of the existing method using variability relationships6 (e.g. contribute, extend, or replace).
Now is a good time to explicitly define a couple of terms that I've alluded to above:
- Method Architecture refers to the structure of the method in terms of the significant structural elements and the relationships among them.
- Method Design refers to the structure of the method, including all the structural elements and the relationships among them.
In RMC, the structural elements are the Method Plug-ins, Method Packages, Method Elements, and Method Configurations.
Note that no new work products are needed for Method Architecture and Method Design since they are directly defined in RMC within the Method Definition work product. That is, unless the team sees a need for capturing them in separate work products, like an architecture document and a visual model, for instance -- which could very well be the case when defining complex methods.
Supporting work products
In addition to the essential work products specific to method development that I just described, and notwithstanding the fact that the approach described in this article focuses on developing the actual method rather than producing project-related documentation, it may at times be useful to produce some additional work products to support the development effort. In this section I present some work products that, while not specific to method development, have proven useful in supporting many method development efforts of various magnitudes. Similar work products can be found in other methods, like OpenUP/Basic7 or RUP itself. The degree to which you would formalize these supporting work products depends on many factors, including project complexity, the culture of the development organization, and project governance dynamics.
Since every project needs a source for capturing all stakeholders' expectations, the project scope, and requirements and constraints, I recommend documenting this information within a Vision document. The Vision can serve as the contract between the customer and the development organization.
Since I strongly believe in the benefits of an iterative and risk-driven approach to method development, I recommend using a Project Plan to implement this approach effectively. The Project Plan defines the project phases and milestones. It may include an Iteration Plan to define the details of each iteration (in term of tasks with assigned resources, for instance); an Iteration Assessment to assess the results of an iteration and perform the necessary mid-course corrections; as well as a Risk List to identify and prioritize risks, and define the necessary mitigation or contingency actions.
Table 3 summarizes the recommended work products to support the method development effort.
Captures stakeholders' views of the method to be developed, as well as the project scope, requirements, and constraints.
Represents stakeholder concerns by gathering their input to understand the problem to be solved and by capturing and setting priorities for requirements.
Gathers all information required to manage the project. Its main part consists of a coarse-grained plan, containing project phases and milestones. Includes the following:
Leads the planning of the project, coordinates interactions with the stakeholders, and keeps the project team focused on meeting the project objectives. On most method development projects (except for exceptionally complex ones), the Project Manager and Method Designer roles are performed by the same person.
Method development roadmap
The approach to method development proposed in this article is based on the four RUP phases: Inception, Elaboration, Construction and Transition. This section walks you through each phase of a typical project.
This section describes the Inception phase of a method development project in terms of its primary objectives, evaluation criteria, state of the essential work products at the end of the phase, and essential tasks.
The primary objectives of the Inception phase are to achieve concurrence among all stakeholders on the project objectives, and to establish that the project is worth doing.
Inception evaluation criteria
At the end of the Inception phase, the project is evaluated against the following criteria:
- Stakeholder concurrence on scope, requirements, constraints, and schedule estimates.
- All risks have been identified and a mitigation or contingency strategy exists for each.
- The method development environment is in place to support the Elaboration phase. In particular, the configuration management environment (e.g. IBM Rational ClearCase®) and method development environment (e.g. RMC) should be set up.
- The team has been trained as appropriate, so it is ready to start the Elaboration phase.
The project may be aborted or considerably re-thought if it fails to satisfy these criteria.
State of essential work products at the end of the Inception phase
- Vision. The stakeholders' expectations, project scope, requirements, and constraints are documented.
- Project Plan. The phases, their durations, and objectives are identified. The iteration plan for the first Elaboration iteration is completed and reviewed. The initial project risks are identified.
- Method Sketch (optional). An early Method Sketch may be available to address very specific risks.
Essential tasks performed during a typical iteration in Inception
The Inception phase work products are produced by performing the tasks shown in Figure 3. Note that other tasks and work products may be applicable (to set up the method development environment and train the team, for instance), but this is a minimum recommended set. The Stakeholder role in Figure 3 illustrates that inputs from stakeholders, such as customers, practitioners, and Subject Matter Experts (SMEs), drive all the tasks of the Inception phase, in order to ensure that the team builds the right method, on-time and on-budget.
Figure 3: Essential tasks in the Inception phase, together with their associated role and input/output work products
Table 4 provides the description of the Sketch Method task. The task is independent of the actual strategy adopted by the project team to define the method; i.e., top-down (the definition of the overall lifecycle in terms of phases and their objectives drives the identification of the content elements) or bottom-up (the identification of the content elements drives the definition of the lifecycle). In practice, project teams generally use a combination of these two strategies. However, whenever applicable, I recommend favoring a top-down strategy, which tends to produce more cohesive methods, in the sense that each content element is more clearly tied to one or more phase objectives.
The core of the RUP for System z8 method, for instance, has been defined mostly using a top-down strategy, in the context of a series of brainstorming sessions running full-time over a period of two weeks. Results from these brainstorming sessions were documented in a Method Sketch. First, z practitioners were asked to examine each RUP phase and identify any necessary changes to its main objectives and deliverables, in order to accommodate the specific needs of the z environment. This allowed the team to identify a first set of work products (such as Module and Installation Verification Procedures) that needed to be added to RUP to satisfy the needs of the z community, and to agree on the fact that objectives of the original RUP phases were applicable to z. Second, z practitioners were asked to describe typical high-level activities that they perform today, which would permit them to reach the goal of each phase. This allowed the team to define, for each phase, a typical iteration in terms of a sequence or combination of high-level activities. Third, z practitioners were asked to detail each activity in term of a grouping of tasks (and potentially sub-activities) performed by roles and producing work products; this was done by leveraging as much as possible existing RUP elements. This allowed the team to identify a set of tasks (such as Module Design and Define Installation Verification Procedures) and related roles and work products, which needed to be added to RUP for z. This strategy led to the definition of an end-to-end process depicting software development practices currently in use in the z environment and leveraging some of the tasks, roles, work products, activities, and modern best practices encompassed in RUP. This strategy also ensured that each method element was clearly tied to one or more phase objectives.
|Task: Sketch Method||This task outlines the method within a Method Sketch. It identities candidate method elements and some of their relationships, and proposes an early description for some of the key elements. Some potentially relevant steps in the performance of this task are proposed below (no specific order):|
This section describes the Elaboration phase of a method development project in terms of its primary objectives, evaluation criteria, state of the essential work products at the end of the phase, and essential tasks.
The primary objective of the Elaboration phase is to baseline the Method Architecture in order to provide a stable basis for the bulk of the authoring effort in the Construction phase. The stability of the architecture is evaluated through one or more Method Web Sites.
Elaboration evaluation criteria
At the end of the Elaboration phase, the project is evaluated against the following criteria:
- The requirements are stable.
- The Method Architecture is stable.
- The description of the most significant method elements is stable.
- The evaluation of one or more Method Web Sites has demonstrated that the major risk elements have been addressed.
- The iteration plans for the Construction phase are of sufficient detail to allow the work to proceed.
- All stakeholders agree that the current vision can be met if the current plan is executed to develop the complete method, in the context of the current architecture.
The project may be aborted or considerably re-thought if it fails to satisfy these criteria.
State of essential work products at the end of the Elaboration phase
- Method Sketch. All significant candidate method elements are identified as well as some of their relationships. The sketch may also include an early description for some of the key elements. The sketch has been reviewed and agreed upon; i.e., each candidate method element will become a Method Element of the Method Definition.
- Method Definition. The Method Architecture is baselined. It includes all significant structural elements (Method Plug-ins including Method Packages and Method Elements, and Method Configurations) and the relationships among them. It leverages existing assets whenever applicable. The Method Design may be partially defined. The Method Design includes non-significant structural elements and the relationships among them.
- Method Element Descriptions. Most method element descriptions are drafted, either directly in RMC or using any other editor. Significant method element descriptions are completely authored and reviewed.
- Method Web Site. One or more websites have been generated to explore significant aspects of the method and evaluate usability.
- Vision. The vision is refined based on new information obtained during the phase, thus establishing a solid understanding of the most critical requirements driving the architectural and planning decisions.
- Project Plan. The project plan is updated and expanded to cover the Construction and Transition phases. The iteration plan for the first Construction iteration is completed and reviewed. Iteration plans for the subsequent iterations in Construction are drafted. The risks are updated and reviewed.
Essential tasks performed during a typical iteration in Elaboration
The Elaboration phase work products that are specific to method development are produced by performing the tasks shown in Figure 4. Note that other tasks and work products may be applicable (in order to test the website, for instance), but this is the minimum recommended set. The execution of the tasks in Figure 4 should be driven by a clear Vision and Project Plan, whatever their level of formality. The Method Reviewers include primarily peers and other Subject Matter Experts (SMEs). However, it is recommended to involve other stakeholders in the evaluation of the method, like practitioners and customers, to make sure that the method is consumable and meets the stakeholders' expectations.
Figure 4: Essential method-specific tasks in the Elaboration phase, together with their associated role and input/output work products
Table 5 provides the description of the Structure Method task.
|This task structures the method, in terms of Method Plug-ins, Method Packages, Method Elements, Method Configurations, and the relationships among them. Some potentially relevant steps in the performance of this task are proposed below (no specific order):|
This section describes the Construction phase of a method development project in terms of its primary objectives, evaluation criteria, state of the essential work products at the end of the phase, and essential tasks.
The primary objectives of the Construction phase are to complete the development of the method based upon the baselined architecture, and to achieve a production-quality method ready for the practitioner community.
Construction evaluation criteria
At the end of the Construction phase, the project is evaluated against the following criterion: the method is stable and mature enough to be deployed in the practitioner community.
The Transition phase may have to be postponed by one release if the project fails to satisfy this criterion.
State of essential work products at the end of the Construction phase
- Method Definition. The Method Design is completely defined. It includes all structural elements (Method Plug-ins including Method Packages and Method Elements, and Method Configurations) and the relationships among them.
- Method Element Descriptions. Method element descriptions are completed and reviewed; i.e., they all reside in RMC.
- Method Web Site. A website covering the complete method has been generated. It has been tested to identify defects, like broken links, or usability issues.
- Project Plan. The iteration plan for the first Transition iteration is completed and reviewed. Iteration plans for the subsequent iterations are drafted. The risks are updated and reviewed.
Essential tasks performed during a typical iteration in Construction
The Construction phase work products that are specific to method development are produced by performing the tasks shown in Figure 5. Note that other tasks and work products may be applicable (in order to test the website, for instance), but this is the minimum recommended set. The execution of the tasks in Figure 5 should be driven by a Project Plan, whatever its level of formality, making crystal clear what needs to be accomplished during each iteration of the Construction phase so the team can focus on delivering results as rapidly as practical now that the creative stage is behind them. The Method Reviewers include primarily peers and other Subject Matter Experts (SMEs). However, it is recommended to involve other stakeholders in the evaluation of the method, like practitioners and customers, to make sure that the method is consumable and meets the stakeholders' expectations.
Figure 5: Essential method-specific tasks in the Construction phase, together with their associated role and input/output work products
This section describes the Transition phase of a method development project in terms of its primary objectives, evaluation criteria, state of the essential work products at the end of the phase, and essential tasks.
The primary objective of the Transition phase is to ensure that a good quality method is available for the practitioners.
Transition evaluation criteria
At the end of the Transition phase, the project is evaluated against the following criterion: the method has been distributed to the practitioner community, and the practitioners are satisfied.
The project closure may have to be postponed by one release if it fails to satisfy this criterion.
At the end of the Transition phase, the post-release maintenance cycle begins. This may involve starting a new cycle, or some additional maintenance releases.
State of essential work products at the end of the Transition phase
- Method Definition. The Method Plug-ins (including Method Element Descriptions) and Method Configurations are complete in accordance with the requirements. Feedback from reviewers has been taken into account.
- Method Web Site. A website covering the complete method has been generated (problems identified during testing have been fixed).
Essential tasks performed during a typical iteration in Transition
The Transition phase work products that are specific to method development are produced by performing the tasks shown in Figure 6. Note that other tasks and work products may be applicable (in order to test the website or package and distribute the method, for instance), but this is the minimum recommended set. The execution of the tasks in Figure 6 should be driven by a Project Plan, whatever its level of formality, making clear what needs to be accomplished during each iteration of the Transition phase. The Method Reviewers include primarily practitioners at this point, since the method is under "beta" evaluation. However, it is recommended to involve other stakeholders, such as customers, in the evaluation of the method to make sure that the method meets their expectations before project close-out.
Figure 6: Essential method-specific tasks in the Transition phase, together with their associated role and input/output work products
This article illustrates an iterative, risk-driven, architecture-centric, and quality-driven approach to method development. The approach has been presented via a roadmap walking through each phase of a method development project, in terms of its primary objectives, evaluation criteria, state of the essential work products at the end of the phase, and essential tasks performed during the phase.
This approach has been implemented and refined over the years -- and will continue to be refined -- in the context of a number of projects of various magnitudes: from fairly simple extensions to RUP addressing a specific technology through tool mentors (like RUP for IBM Rational Software Architect), to fairly complex extensions addressing specific domains through various guidance, additional content elements, and a modified lifecycle (like RUP for COTS9, 10). This approach was documented while being implemented in RUP for System z, which corresponds to a typical method development effort of medium to high complexity (five people on the project team, a fourteen-week project timeline, one plug-in deliverable, one configuration deliverable, and about eighty new content and process elements).
The presented approach is currently being documented as an RMC method called Method Authoring Method Basic (MAM Basic). This article is only a first attempt to formalize the method development process that the RUP team follows. Since method development is an area of growing interest, expect to see more guidance coming from the method development community, related to various topics like Method Architecture, method integration, or method configuration management.
I 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 Carlos Goti for his detailed reviews and always excellent suggestions, and to the RUP for System z team for implementing the method so thoroughly and providing constructive feedback. Finally, the method presented in this article has emerged from the work of the RUP and IRUP teams over the years, so I extend an individual thanks to each of my colleagues on these two remarkable teams.
1 Per Kroll and Philippe Kruchten. The Rational Unified Process Made Easy: A Practitioners Guide to the RUP. Addison-Wesley, 2003.
2 In this article I address the development of both methods, which are meant to be directly implemented on a project without customization; and method frameworks, which are meant to be further customized to address the specific needs of a project or organization. For the sake of simplicity I use the word method throughout this article to refer to both methods and method frameworks.
3 For more on RMC, see the following resources:
- RMC Resource Center on IBM developerWorks: http://www.ibm.com/developerworks/rational/products/rup/
- RMC 7.1 Plug-Ins on IBM developerWorks: http://www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/
- Per Kroll, "Introducing IBM Rational Method Composer," The Rational Edge, November 2005: http://www.ibm.com/developerworks/rational/library/nov05/kroll/index.html
- Peter Haumer, "IBM Rational Method Composer: Part 1: Key Concepts," December 2005: http://www.ibm.com/developerworks/rational/library/dec05/haumer/
- Peter Haumer, "IBM Rational Method Composer: Part 2: Authoring method content and processes," January 2006: http://www.ibm.com/developerworks/rational/library/jan06/haumer/
4 One good source of information on simple method customizations using RMC, is the IBM Global Services training course PRJ350v2: Essentials of tailoring methods with IBM Rational Method Composer v7.0.1: http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&courseCode=RP522#4.
5 Per Kroll and Walker Royce, "Key principles for business-driven development," The Rational Edge, October 2005: http://www.ibm.com/developerworks/rational/library/oct05/kroll/index.html.
6 For more information on variability, refer to the IBM Global Services course PRJ350v2, per above.
7 For more information visit: http://www.eclipse.org/epf/.
8 For more on RUP for System z, the following resources should be available in late February, 2007:
- RMC plug-in downloadable at http://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.
9 For more information visit: http://www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/.
10 Cécile Péraire and Russell Pannone, "The IBM Rational Unified Process for COTS-based projects: An introduction." The Rational Edge, August 2005, http://www.ibm.com/developerworks/rational/library/aug05/peraire-pannone/index.html.