Appendix F. Introduction to the PBE Practice

This appendix provides an overview of the PBE Practice, highlighting the main roles, work products, and tasks involved in PBE. The goal of this appendix is to provide additional details regarding the practice to assist in further understanding the case study and PBE in general. This material also serves as an introduction to the full PBE Practice, which is available for download as both an EPF Composer plug-in and a published process configuration.

PBE Roles

A good place to start in following a development process is to figure out the roles that are involved in the effort. When looking at the roles, it is important to keep in mind that a role does not necessarily map to a single person. A person may end up filling multiple roles, or a role may end up being filled by multiple people. So there can be a many-to-many relationship between people and roles. In a larger organization we may find that each role maps directly to one or more individuals. In smaller organizations the roles may be less formally recognized and an individual may fill more than one role.

Figure F.1 shows all the roles involved in PBE and maps them to the areas in which they perform tasks. Only the main roles are described in the remainder of the section; the others are more standard and are self-explanatory. Beneath each role there is a listing of the case study chapters where the role participates in the effort.

Figure F.1. View of the PBE roles

Asset Librarian

The Asset Librarian is responsible for managing reusable assets. Typically the person in the role works with an asset repository, making sure that the reusable assets are managed properly. Asset Librarians set up communities of interest and users, review workflows, and facilitate the reuse program. As shown in Figure F.2, the Asset Librarian is the primary performer for the Deploy Pattern to Asset Repository task and is responsible for the reusable asset work product.

Figure F.2. Overview of Asset Librarian role and associated tasks and work products

Skills typically required to fill this role include

• Strong organizational skills

• Knowledge of the tools and practices related to managing reusable assets

Pattern Author/Subject Matter Expert (SME)

The Pattern Author/Subject Matter Expert (SME) is an expert within a business or technical domain. As shown in Figure F.3, Pattern Authors/SMEs are primary performers of a number of tasks, including Capture Reuse Metrics and Evaluate Candidate Patterns. They are experts in the domain associated with the pattern and partner with other roles in creating pattern specifications and implementations.

Figure F.3. Overview of Pattern Author/SME role and associated tasks

Skills typically required to fill this role include

• Expertise related to the targeted technology or business domain

• Intimate knowledge of the pattern and experience applying it successfully

Pattern Specification Author

The Pattern Specification Author is responsible for writing pattern specifications, that is, the formal written documentation that describes a pattern. This includes the description of the problem, solution, and consequences of use, as well as pointers to additional related patterns. The Pattern Specification Author does not necessarily need to be skilled in the domain related to the pattern and depends on the Pattern Author/SME to provide assistance and explanations as needed.

As shown in Figure F.4, the Pattern Specification Author participates in a number of tasks, including Create a Pattern Specification, Make Pattern Available for Reuse, and Review Feedback. The role is also responsible for the pattern specification work product.

Figure F.4. Overview of Pattern Specification Author role and associated tasks and work products

Skills typically required to fill this role include

• Knowledge of the templates and practices of pattern specification

• Strong technical writing skills

• Knowledge of the targeted technology or business area (desirable)

Pattern Implementation Author

The Pattern Implementation Author is an expert in creating pattern implementations. This includes, but is not limited to, the creation of one or more of model-to-model pattern implementations, model-to-text pattern implementations, UML patterns, and DSLs. Like the Pattern Specification Author, the Pattern Implementation Author is not an expert in the domain of a specific pattern.

As shown in Figure F.5, the Pattern Implementation Author participates in a number of tasks, including Build a Pattern Implementation, Design a Pattern, Increase Pattern Scope, Make Pattern Available for Reuse, and Review Feedback. In addition, this role has responsibility for the pattern implementation and pattern implementation documentation work products.

Figure F.5. Overview of Pattern Implementation Author role and associated tasks and work products

Skills typically required to fill this role include

• Knowledge of the tools and practices used for creating a pattern implementation

• Knowledge of the targeted technology or business areas (desirable)

Pattern Tester

The Pattern Tester role is responsible for testing pattern specifications and implementations. The role collaborates with the Pattern Author/SME, the Pattern Implementation Author, and the Pattern Specification Author in testing the pattern. This role is responsible for the Test a Pattern task and will work with the defect artifact.

Skills typically required to fill this role include

• Knowledge of testing approaches and techniques

• Diagnostic and problem-solving skills

• Knowledge of the targeted technology or business area (desirable)

Pattern User

Everyone within the development organization fills the Pattern User role, as everyone should be looking to use patterns. This role focuses on the use of patterns in helping to create and deliver software. Keep in mind that patterns can be used for many things, including the creation of other patterns. As shown in Figure F.6, the Pattern User role participates in the following tasks: Capture Reuse Metrics, Locate a Pattern, Model Pattern Use, Provide Feedback on a Pattern, and Use a Pattern. Pattern Users are responsible for the pattern feedback and pattern metric work products.

Figure F.6. Overview of the Pattern User role and associated tasks and work products

Skills typically required to fill this role include

• Ability to recognize opportunities where a pattern could be used

• Ability to work with an asset repository to find and reuse patterns

PBE Main Work Products

In this section we discuss the work products associated with the PBE Practice. As the different roles work through their tasks, they will consume and produce different artifacts, called work products.

Figure F.7 shows the PBE work products as well as their relationships. The arrows show the work product flow and how those work products, in turn, influence other work products. Beneath each work product there is a listing of the case study chapters where the work product is involved.

Figure F.7. Overview of PBE work products and their relationships

The rest of this section describes the main work products, skipping those that are self-explanatory.

Domain-Specific Language

A domain-specific language (DSL) is a language used to capture information for a specific domain. Such a language can be graphical or textual. It is targeted to a specific area and should not be used generally across a range of problem spaces.

DSLs are often used in conjunction with patterns. Thus, DSLs are a common deliverable when following PBE.

Exemplar

An exemplar represents the results (or output) associated with the application of a best practice. This is the best-practice-based solution that will serve as the target reference as we design and create a pattern. This is a key artifact that serves as input into the pattern creation effort.

List of Candidate Patterns

As we identify candidate patterns, we add them to a list, recognizing that not all of them will end up being built. We evaluate the candidate patterns in the list and determine which make the most sense to create.

Pattern Description

A pattern description is an artifact that provides a high-level description of a pattern. This description is much less detailed than a pattern specification and will later serve as the input into the creation of patterns (including both specifications and implementations). The pattern description provides a lightweight and easy method for capturing initial details about the pattern that can be fleshed out as we progress through evaluation and design efforts.

Pattern Implementation

A pattern implementation automates the application of a pattern in a particular environment. The patterns become tools themselves, concrete artifacts within the development environment.

Pattern Implementation Design

This artifact details the design for a pattern implementation. The artifact will contain details regarding

• The major components that constitute the pattern and how those components fit together

• The expected behavior of each of the components

• Input expectations for each of the components

• Expected output from each of the components

• Diagrams as necessary to help others understand the design

• Documentation as necessary to help others understand the design

Pattern Implementation Documentation

This documentation describes a pattern implementation, how to use it, and how to install it and provides guidance and pointers to other related patterns. When creating this artifact, we reference the pattern design, description, and specification.

Input Model

An input model is used to provide input into a pattern implementation. Its content maps to the roles and points of variability associated with the pattern, allowing us to make the pattern unique to our specific context. The input model may take a number of different forms, including XML, UML, EMF, or even a 3GL such as Java. The actual representation of the model may be hidden from the user via the use of a wizard, form, or other view.

Pattern Specification

A pattern specification is the formal written documentation that describes a pattern. This documentation details the problem, solution, and consequences of a pattern along with guidance on related patterns.

Reusable Asset

An asset is “. . . a collection of artifacts that provides a solution to a problem. The asset has instructions on how it should be used and is reusable in one or more contexts, such as a development or a runtime context. The asset may also be extended and customized through variability points.”¹

Task Order

At this point we have an understanding of the roles and work products associated with a PBE effort. The next step is to look at the tasks defined within the PBE Practice. As part of this discussion we will take a high-level look at each task, the participating roles, and the work products that are consumed and produced.

Recall that within PBE we have four major focus areas: pattern identification, pattern production, pattern consumption, and pattern management. Figure F.8 shows how these different focus areas interact.

Figure F.8. Overview of PBE focus areas and their relationships

With this view in mind, we can use Table F.1 to help us understand when each of the tasks from the PBE Practice should be considered for use. The chapter numbers shown in parenthesis following the task name are the case study chapters in which the tasks are used.

Table F.1. Mapping of Tasks to Phases of PBE

An additional aspect to consider in regard to the timing of the performance of the PBE tasks is the larger overall process and associated practices being used.

PBE Tasks

At this point we have an understanding of the roles and work products in the PBE Practice. However, what work must be done by these roles to create and consume these work products? In this section we work through the list of tasks associated with PBE. For each task a high-level overview is provided. More details about each task are available in the PBE Practice. The tasks are grouped and listed following the order in Table F.1.

Pattern Identification

Figure F.9 shows pattern identification tasks and workflows.

Figure F.9. Overview of the pattern identification tasks and workflow

Find Project Patterns

In this task we find the set of patterns that we want to consider using in our project(s). The patterns can be sourced via a number of different options and may also be at different levels of maturity or completeness.

In terms of sources, some of the options include

• Patterns from external sources such as vendors and the community

• Patterns from internal sources such as preexisting patterns and patterns that need to be created

Our focus is on figuring out the set of patterns that could have an impact on the project. We spend some time and effort in putting together a list of candidate patterns. We perform some analysis on the patterns and their possible impact. But our focus is on being thorough in terms of identifying and finding patterns, not the filtering. As a result of this task we produce a candidate pattern list.

Keep in mind that in an iterative and incremental approach to development we would revisit this task multiple times during the project. At the beginning of the project we are still learning about the requirements associated with the project. As time and the project progress, our understanding grows, and usually requirements and priorities change. Therefore, we do not want to overinvest time in this task at the beginning of the project or expect that all patterns will be identified up front.

As shown in Table F.2, this task is inclusive and meant to involve the entire team. Good ideas and input can come from any member of the team, and everyone should be encouraged to contribute to the effort. In terms of input to this task we need to look at the requirements related to the project. The functional and nonfunctional requirements will be used to help us determine when and where patterns may have an impact on the project.

Table F.2. Summary of Relationships to Find Project Patterns Task

Evaluate Candidate Patterns

In this task we determine which of the candidate patterns should be invested in and created. With PBE, we want to be systematic and disciplined in how we use patterns. We need to have some rigor in place, guiding us as we figure out what patterns we should use, why they should be used, and the expected impact. This is especially important when we create our own patterns. It is not acceptable to deliver a pattern that has no value to the project.

It makes sense that we would evaluate our candidate patterns in much the same way as we perform similar work with other architecturally significant aspects of building a solution. For instance, we would typically answer the following questions:

• What architecturally significant elements should we use?

• What is the benefit of using those elements?

• What are the associated constraints and challenges?

Although the primary performer of this task is only the Pattern Author/SME, Table F.3 shows that many others in the organization assist in performing the task. When reviewing the list of candidate patterns, we seek assistance from those who will help to create the pattern as well as those who will use the pattern.

Table F.3. Summary of Relationships to Evaluate Candidate Patterns Task

Increase Pattern Scope

In the Increase Pattern Scope task we grow the scope of a pattern to drive generation of additional related artifacts. After we release the pattern, we will start to receive feedback from users regarding the pattern. They will tell us what works well and what doesn’t work so well and will suggest areas for improvement. This becomes a source for determining how the pattern should evolve in future releases. However, this is not the only source of input on the future direction of the pattern. We also can work with the Pattern Author/SME to determine ways in which we can extend the scope of the pattern.

When looking at expanding the scope of the pattern, we want to find ways in which we can leverage as much of the existing infrastructure as possible and generate more value from the effort to date. For example, the pattern requires that users provide an input model with many details about their specific situations. We could use this information to generate code associated with a best practice. The information provided in the input model is valuable and is usually applicable to more than just code. We could start to think of all of the other things that are related: test cases, deployment scripts, database scripts, packaging, documentation, and so on. We could also look at other ways in which we can extend the usage scenario. Would the introduction of a graphical DSL help users more successfully use the pattern? Additional constraints? Additional assumptions? This is still adding scope, just in a different dimension.

When building out the scope of the pattern, we want to think about what extensions to the pattern will provide the most ROI. Much as we did when we evaluated which patterns we should build, we need to analyze which extensions should be made. Just because an extension can be made, doesn’t mean that it should be.

As shown in Table F.4, the primary performer for this task is the Pattern Implementation Author since this task is applicable to the creation of pattern implementations.

Table F.4. Summary of Relationships to Increase Pattern Scope Task

Pattern Production

Figure F.10 shows pattern production tasks and workflows.

Figure F.10. Overview of pattern production tasks and workflows

Design a Pattern

Once we have decided that a pattern is to be built, we have to come up with a design for it. We need to ensure that a pattern description has been created. As we design the pattern, we use the PBE Core Values and PBE Patterns and Guidelines to guide the effort.

Recall from the PBE Core Values that when we design a pattern, it is important to remember that we usually use a number of patterns in combination. So we need to understand how the new pattern will be used in relation to other patterns. In addition, we need to consider whether we are going to target the creation of a pattern specification or a pattern implementation. An exemplar, as listed in Table F.5, is a key input to the efforts associated with this task, ensuring that the pattern is grounded in a proven best practice.

Table F.5. Summary of Relationships to Design a Pattern Task

We also need to ensure that the exemplar that is used as the basis for the pattern is of high quality. We can start by using traditional testing approaches to ensure that the exemplar is indeed a representation of best practices and that it works. However, we also want to take things a step further and make sure that the exemplar is a good foundation for the patterns that will be built on top of it. For instance, does it exhibit the necessary variability to truly account for the flexibility that will be needed by the Pattern Users?

Create a Pattern Specification

Generally, patterns have been presented as formal written documentation that explains the pattern. We refer to these patterns as pattern specifications. In this task we build upon the effort from the Design a Pattern task. We want to embellish the design and capture the details in the pattern specification, using a pattern specification template. Usually, within an organization we try to use a standardized pattern specification template for capturing pattern specifications. This helps to ensure that the information that is most important to the organization is captured and that we can train people on a standard approach to creating pattern specifications, and it simplifies the effort needed to understand the pattern specification.

As shown in Table F.6, the primary performers of this task are the Pattern Author/SME and the Pattern Specification Author. In cases where a pattern implementation is also being created, they will interact with the Pattern Implementation Author. Inputs to this task include the exemplar and pattern description. We may also need to consider the related pattern implementation and associated DSL.

Table F.6. Summary of Relationships to Create a Pattern Specification Task

Build a Pattern Implementation

In this task we create a pattern implementation that leverages the design that was created in the Design a Pattern task. Recall that there are a number of types of pattern implementations that can be used independently or in combination, including UML pattern implementations, model-to-text pattern implementations, and model-to-model pattern implementations. For examples of pattern implementations please refer to Chapter 2.

To make the pattern implementation easier to use, we can also develop a domain-specific language (DSL). Other artifacts and deliverables related to this task include

• Pattern input model

• Pattern description

Table F.7 provides a summary of the relationships of other process elements of this task. As mentioned in the role descriptions, it is unlikely that Pattern Implementation Authors have the domain knowledge to build the pattern on their own; they will collaborate with a Pattern Author/SME. If it is decided that a pattern specification is also needed, the Pattern Specification Author role will also join in the effort of completing this task.

Table F.7. Summary of Relationships to Build a Pattern Implementation Task

Make Pattern Available for Reuse

In this task we take the patterns that we have created, along with associated artifacts, and package them for reuse. The focus here is on ensuring that the assets are as consumable as possible. Artifacts that usually get included within and alongside the patterns include the DSL, pattern implementation documentation (within the asset and alongside), sample models used for input/testing the pattern, and model templates to guide the user in creating an input model.

Here are some of the things that we need to consider in this task:

• How should the pattern be packaged?

• How are relationships between patterns handled?

• How are supporting artifacts made available?

• How can the user learn about and understand how to use the pattern?

As shown in Table F.8, the Pattern Implementation Author and Pattern Specification Author roles focus on making their respective assets available for reuse. They will look to the Asset Librarian role to provide assistance in regard to reusable assets in general.

Table F.8. Summary of Relationships to Make Pattern Available for Reuse Task

Test a Pattern

A product that lacks quality will not be used successfully. In the case of a pattern, this means that the investment in identifying, evaluating, designing, building, and deploying the pattern has been for naught.

As for any other development activity, testing is an important component of ensuring quality. In the context of patterns, they should be tested on multiple levels and in multiple ways. Developer testing is part of the pattern developer activities, whereas this task focuses more on the functional testing, also called “black-box” testing. The tester tests the reusable asset packaged by the pattern developer and validates that the pattern when applied produces the expected result.

As shown in Table F.9, we see that this kind of testing is mainly the responsibility of the Pattern Tester role, with other roles involved as necessary to support the effort.

Pattern implementation and pattern implementation documentation are mandatory only when testing a pattern implementation, while a pattern specification is mandatory when testing a pattern specification.

Table F.9. Summary of Relationships to Test a Pattern Task

Pattern Consumption

Figure F.11 shows pattern consumption tasks and workflows.

Figure F.11. Overview of pattern consumption tasks and workflows

Locate a Pattern

As Pattern Users, we want to locate a pattern that can help to solve a recurring problem. In the Locate a Pattern task we conduct a search of the pattern repository (or a set of pattern repositories) to find the available patterns that fit our needs.

If we are unable to find a pattern that suits our requirements, we need to escalate the issue to the leadership team for the project. It may turn out that the pattern was considered during the Find Project Patterns task but was found to provide insufficient value; it may turn out that it was not considered, or that the pattern does exist but the search was not conducted properly.

When searching through the repository, we may find a number of patterns that potentially suit our requirements. At this point we will need to further evaluate the patterns and perhaps enter the Use a Pattern task with a set of patterns.

As shown in Table F.10, the primary performer of this task is the Pattern User role. Upon completion of this task we should have found a set of patterns that can assist us in our efforts, or else we will have raised a flag indicating that we have a recurring problem and are unable to locate a pattern.

Table F.10. Summary of Relationships to Locate a Pattern Task

Use a Pattern

At this point the Pattern User has found a pattern that can be applied to help solve a particular problem. This task focuses on helping the Pattern User successfully consume the pattern.

As we look to use the pattern, we want to document where and how the pattern is used. If we are leveraging modeling as we create the solution, it makes sense to document that the pattern is being used, where and how it is being used, and how it connects to other patterns.

At this point the steps that we have taken will be the same whether we are dealing with a pattern specification or a pattern implementation. However, moving forward, we find that the steps will diverge, as we need to work to the specifics of each type of pattern.

Note that when using a pattern the output can vary widely, as patterns can be used for many things and many situations. As a result, the output from this task will be some set of artifacts that are based on the pattern that is used. This may be a model, a portion of a model, or some text-based artifact such as code, configuration scripts, XML files, and so on.

Use a Pattern Specification

In terms of working with just a pattern specification, the path forward is quite simple. There should be a minimal amount of documentation that ships with the specification. To move forward and use the pattern, we first need to read and then comprehend the pattern specification itself. When reading the specification, we need to consider the following:

• Does the pattern address the problem?

• Can we live with the constraints associated with applying the pattern?

• Does the pattern have relationships with other patterns? What type of relationship(s)? Can the pattern be used in conjunction with other patterns, or are the relationships mutually exclusive? If there are relationships, have we already used some of those patterns? Would it make sense to look at applying those other patterns if they have not already been used?

Once we have a firm understanding of the pattern, we can then apply the pattern.

Use a Pattern Implementation

In terms of working with a pattern implementation, our next step after finding the pattern is consulting the more detailed pattern implementation documentation that is provided along with the pattern. We use this documentation to further understand the pattern, how the pattern is used, how it can be applied, and how we connect the details that are specific to our situation with the points of variability that are provided by the pattern. We will also find out how many patterns are in the package, how they are related, and any supporting DSL and customizations to the modeling environment. Once we feel comfortable with our understanding of the pattern, we need to install it. The documentation that ships alongside the pattern helps us to gain this understanding.

Once we have installed the pattern, we should check to make sure that the pattern works with provided samples and that documentation for the pattern is available within our work environment. In addition, we should check for supporting artifacts that could help us comprehend and use the pattern(s).

Then we can start working on defining an input model matching our context and applying the pattern as described in the supporting documentation.

As shown in Table F.11, the primary performer for this task is the Pattern User role. Note that the table does not explicitly call out a list of outputs as the list is unbounded, limited only by the needs of the project and the creativity of the Pattern Authors.

Table F.11. Summary of Relationships to Use a Pattern Task

Model Pattern Use

In this task we focus on modeling the patterns that are used in a solution. Traditionally we have used modeling to capture details about the architecturally significant aspects of a solution; such thinking and effort also apply to the patterns used within a solution. Some of the reasons and benefits of modeling the patterns used include these:

• Improved design. It is clear and explicit where architecturally significant elements, such as patterns, have been used. Modeling also highlights where patterns have not been used, can alert us to areas where patterns are absent, and helps us as we review solutions.

• Improved communication. It becomes easier for others to understand the solution.

• Education. We can use such models to educate others on the design and the use of patterns.

Keep in mind that we are not looking at a one-size-fits-all approach to the use of modeling. We’ve seen that modeling can be used in many forms and at varying levels of detail and effort. We may use models to sketch out the design of the solution, or we may use models as a blueprint that details a majority of the aspects related to the solution. Regardless of the depth, we can stay consistent with our modeling preference and still include details about the patterns in use.

The Communicate Design with Patterns guideline provides examples of modeling pattern usage.

The primary performer for this task, as shown in Table F.12, is the Pattern User role.

Table F.12. Summary of Relationships to Model Pattern Use Task

Provide Feedback on a Pattern

When using a pattern, we should provide feedback to the pattern maintainers to improve the quality and increase the value of the pattern. This feedback can be used as input into the next iteration of pattern development as well as help to guide efforts in expanding the scope of the pattern. This feedback can also be used to help others determine if they should use the pattern.

The primary output of this task is pattern feedback, as shown in Table F.13, which is provided by the Pattern User.

Table F.13. Summary of Relationships to Provide Feedback on a Pattern Task

Pattern Management

Figure F.12 shows pattern management tasks and workflows.

Figure F.12. Overview of pattern management tasks and workflows

Deploy Pattern to Asset Repository

Once the pattern has been documented and packaged, we have to make it available for reuse. The key mechanism that we use here is the asset repository. Depending on the needs of our ABD program, we can select from a range of different approaches for our repository. We may use a tool that is specifically focused on assets, one that is more general but focused on versioning, or we may use something as simple as a network folder or wiki. The key idea is that we have a known location that allows us to make assets available for reuse while managing versions and feedback. In addition, we want to be sure to use the correct level of tooling and support to meet the needs of our effort. As the scope of the reuse effort grows, we will want to ensure that our repository approach meets our needs in regard to aspects such as governance, collaboration, security, versioning, and availability.

We store the artifacts related to the pattern in the repository, including the pattern itself (pattern specifications and pattern implementation), the associated pattern implementation documentation, and DSLs. When we submit the asset to the repository, we may have to participate in an approval process. During that process the appropriate parties review the asset before making it widely available. When we create the record for the asset in the repository, we provide details on the pattern: What type of asset is it? What can it be used for? To whom should it be made available?

The primary performer for this task, as shown in Table F.14, is the Asset Librarian. Again, it is important to keep in mind that a person can take on multiple roles. Many organizations do not have a single person who is 100% dedicated to the Asset Librarian role. However, this does not mean that the work done by the role is not performed. It may be that the role is shared by a number of people or that one person takes on this role as one of many.

Table F.14. Summary of Relationships to Deploy Pattern to Asset Repository Task

Review Feedback

From a pattern creation, maintenance, and support point of view, we need to have a mind-set that we don’t just create and release a single version of the pattern and never expect to see that asset again. Focusing on a big-bang approach that sees just one release that has everything the pattern could ever need is a path to failure. Focusing on the essence of the pattern and then augmenting future versions is the approach we need to adopt. Feedback from Pattern Users is an important input when determining how to prioritize enhancements to a pattern in future releases.

In this task we look at things from the point of view of the owner of the pattern, which is typically the Pattern Implementation Author or the Pattern Specification Author. We need to be diligent in ensuring that we are following up on feedback and improving the quality of our patterns. We cannot have a fire-and-forget mentality. The culture around the reuse program is very important, and having Pattern Users consume the pattern and then submit feedback is a key behavior that needs to be supported and reinforced. Ignoring the feedback, arguing with users, or not following through can have serious negative consequences on the reuse program.

We will review the feedback and discussions in the pattern repository to gain insights into how pattern users are faring in using patterns. How often are the patterns used? What positive suggestions are being made about improving them? What issues have users run into? What are the priorities associated with these issues? What is the value of the pattern that these feedback items are assigned to? How important is the underlying pattern to the organization?

When we originally created a pattern, we did not automatically build it just because potential had been identified. We performed an analysis and invested in only those patterns that were deemed to provide the appropriate ROI. As we anticipate releasing a new version of a pattern, one that incorporates user feedback, we will end up performing a similar analysis. It is therefore important that we have a good understanding of the outstanding issues, the impact that they would have on the pattern, the effort associated with implementing these changes, and the expected benefit from implementing them.

In addition to consulting the asset repository for user feedback, we should also take time to discuss and interact directly with those using the patterns. One approach is to follow up on comments and feedback that have been provided. Another option is to follow up based on those who have downloaded the artifact. In this case we leverage some of the capabilities of an asset repository, which tracks how many times each pattern is downloaded and who has obtained a copy of the pattern. Discussing the pattern with those who downloaded it but did not record feedback may provide some valuable insights. Perhaps they downloaded the pattern but found that it didn’t meet their needs. Did they misunderstand the pattern description and metadata? Or is that information misleading?

As shown in Table F.15, the primary performers of this task are the Pattern Implementation Author and Pattern Specification Author roles. The Asset Librarian and the Pattern Author/SME assist them in reviewing the feedback. The Asset Librarian provides assistance in working with and capturing information from the asset repository. The Pattern Author/SME provides insights into the domain and the pattern, helping to validate and ascertain the value of the feedback.

Table F.15. Summary of Relationships to Review Feedback Task

Capture Reuse Metrics

A key aspect of following a PBE approach is to be systematic and disciplined while also quantifying results. It is not sufficient to just use patterns because we expect it to be a good approach. We need numbers, metrics that detail the impact and support the decisions that are made. Anecdotal evidence can help but is not nearly as effective.

We attempt to capture metrics at a number of key points as we work through our PBE workflows; for instance, in the Evaluate Candidate Patterns task we can see that metrics play a key role in deciding which patterns we should initially invest in. However, a focus on metrics doesn’t occur only within this one task. We also need to capture and leverage metrics as we support the Provide Feedback on a Pattern, Increase Pattern Scope, and Review Feedback tasks. When using a pattern, we need to understand its ROI. What was the investment made in acquiring the pattern, and then what was the return on that investment?

In Table F.16 we see that a number of roles are involved in supporting this task. They require the support of several artifacts, including the list of candidate patterns, pattern description, pattern feedback, and ROI analysis. Being able to quantify the results is a shared responsibility, and a focus on results cuts across many tasks.

Table F.16. Summary of Relationships to Capture Reuse Metrics Task

Update Development Process

As we leverage other tasks such as Build a Pattern Implementation and Increase Pattern Scope, we find that the pattern implementations end up affecting aspects of the development process. For instance, a pattern implementation can automate the performance of many steps and generate many artifacts. Previously, these tasks would have been performed manually and would have required a number of roles to be involved and coordinated. If in our development efforts we adopt such a pattern implementation, we have to remove references to the performance of the manual steps and in their place discuss when, where, and how to use the automation as part of the process. Ideally, we end up simplifying the development process; a simpler process with fewer manual steps is easier to follow and leads to success.

A key idea to keep in mind in this task, as in most any software development process-related effort, is that the process being followed is not static. It does not occur in a vacuum, oblivious to any changes made in how we work and the tools that we use. Thus, we always need to keep an eye on how we’ve documented the process and be aware that it will need to be updated periodically to reflect the current practices of the team.

EPF Composer is an excellent tool to help in such efforts, as it allows for easy modification and publishing of process content. We do not need to manually update the files that detail the process. Rather we update the model that represents the process and then republish. Once it is republished, it’s an easy task to push the documentation out to the team.

Knowing that this is a task we are going to have to do, and understanding the tools that will help us accomplish the task, let’s take some time to discuss what needs to be considered.

A good place to start is to analyze the patterns that we are using. As there are a number of steps along the way where we have analyzed the patterns that we are going to acquire, build, and use, we know what patterns will be used before they are actually used.

In some cases, such as the use of a UML pattern, the impact is too narrow to be detailed in the development process. However, the guidance to use UML patterns, or even a set of patterns, would be a detail that is worth including.

As we get to patterns with a bigger scope, we need to start accounting for how these patterns will impact the development process. In addition, as we start to combine and encapsulate larger-scope patterns, we are able to compress the development process even more. The more we are able to compress and simplify the development process, the more pressing is the need to ensure that these changes are recorded and made available to the team.

In addition, we also need to account for how these larger-scope patterns impact additional ancillary tasks. For example, we would have tasks in the development process that relate to the deployment of the code, build, and testing efforts. Again, we have insight into the patterns in advance of them actually being used. In this case we are well aware of how far the scope of the pattern extends. We can ask ourselves, how does the scope of the pattern impact development tasks? Testing tasks? Deployment tasks? Requirements?

As shown in Table F.17, the primary performer for this task is the Development Process Author role. This role will consult with the Pattern Author/SME to provide guidance on the patterns that are used and their possible impact on the process.

Table F.17. Summary of Relationships to Update Development Process Task