Chapter 8. PBE and the Software Development Process
This chapter introduces the process aspect of PBE. Typically, a software development process provides guidance on the roles, tasks, work products, and workflow needed to develop software. This chapter examines the roles, tasks, work products, and workflows associated with PBE.
We can view the software development process as a set of components—some on testing, others on writing code, and others on source code management; each of these process components is known as a practice. This chapter provides an overview of the PBE Practice and guidance on how we can leverage the practice in our development efforts. The discussion will also include guidance on how to integrate PBE with some popular processes: Scrum, OpenUP, and Extreme Programming.
To gain a deeper understanding of the elements of the PBE Practice, the follow-on steps are to review Appendix F and then the PBE Practice itself.
Introduction to the PBE Practice
The PBE Practice is authored as a plug-in that can be used with Eclipse Process Framework Composer or Rational Method Composer.1 The PBE Practice is customizable and configurable, and it can be combined with other practices to create a software development process tailored to the needs of an organization. At a minimum, a default configuration of the content can be published as a set of HTML pages that can be viewed in a standard web browser, as shown in Figure 8.1.2
Figure 8.1. View of the published configuration of the PBE Practice
With the PBE Practice in hand, we can answer these questions:
• Who is involved in the PBE effort?
• What should each of these roles be doing?
• When should tasks be performed?
• How should tasks be performed?
The rest of the chapter will provide a high-level overview of the practice, focusing on building the base necessary to get started with using PBE without being overwhelmed by too many new concepts and ideas. With this foundation in place, we can gain additional insights about the practice through
• Oslec case study. Chapters 3 through 7 illustrate many of the tasks used in the creation of the LogoAuction application. Practice elements introduced in this chapter include references to the case study chapters where the elements are discussed.
• Appendix F. Appendix F provides a more detailed look at the roles, work products, and tasks associated with the PBE Practice.
• Patterns and guidelines. To successfully complete the PBE tasks, we use one or more of the PBE Patterns and Guidelines. The overview includes references to the chapters where the supporting patterns and guidelines are detailed.
• PBE Practice. The PBE Practice is available for download as both an Eclipse Process Framework Composer plug-in and a published configuration. We can review these downloadable elements to gain further insights into the elements within the PBE Practice.
PBE Roles and Tasks in Context
Recall from Chapter 1 that we introduced PBE as a specialized implementation of asset-based development (ABD). Within ABD, there are four key areas that we focus on as we work with assets, as shown in Figure 8.2.3
Figure 8.2. High-level overview of asset-based development efforts
Credit: Grant J. Larsen, IBM.
Figure 8.3 shows an instantiation of Figure 8.2 that focuses on patterns as assets.
Figure 8.3. High-level overview of PBE efforts
And we can take things a step further, as shown in Figure 8.4, and look at the flow between these phases.
Figure 8.4. PBE efforts activity diagram
We can use Figures 8.3 and 8.4 to help us put the elements within the PBE Practice in context. This is particularly useful as we consider the PBE tasks and roles. We can see the details regarding who is doing what, when, and for what purpose. We are also then able to map that understanding into the bigger picture. The roles, tasks, and work products within the PBE Practice support these four major focus areas. It is therefore important that we understand what we are trying to accomplish within each of the areas:
• Pattern identification. In this phase we are focused on identifying the patterns that can add value and assist us in successfully completing our projects. These patterns may already exist or may need to be created. We can reuse, as is, those patterns that exist (either from external sources or previously built within our organization) or enhance them. Typically we end up identifying more patterns that are possible to build, enhance, or use; we need to ensure that we are systematic in our efforts and quantify the value of a pattern before we make any investments.
• Pattern production. In pattern production our focus is on creating or updating the patterns that have been identified and vetted during pattern identification. In these efforts we look to design, implement, and test the new or extended patterns and their associated artifacts.
• Pattern management. In this phase we are focused on managing the patterns that we are making available within the organization. These may be patterns that we have created or patterns that we have acquired. Our focus is on ensuring that we are making it possible for Pattern Users to easily find and then use the patterns that meet the specific needs of their situation.
• Pattern consumption. In pattern consumption we are focused on successfully using patterns that have been made available within the organization. Surprisingly, this is often an area of weakness. Typically we find that we are much better at producing patterns than we are at consuming them.
Getting Started with the PBE Practice
To get started with the PBE Practice, there are a number of steps that we can follow to ensure success:
• Start small. We are doomed to fail if we attempt to learn, adopt, and integrate all of the content from the PBE Practice at once. To succeed as a team, we need to ensure that we are picking those core elements of the practice and integrating them, and then add further refinements and enhancements in future iterations.
• Leverage current strengths. We need to look at our current strengths, while also acknowledging our weaknesses, to help us decide how we will integrate new process elements.
• Quick wins. As we adopt and integrate new process elements, we want to ensure that we are setting ourselves up for quick wins. And as these wins occur, we want to ensure that we are communicating these successes to the team at large.
With these steps in mind we can consider Figure 8.5 and Table 8.1, which, respectively, list the roles and tasks within the PBE Practice and map them to the PBE phases. In reviewing these lists and keeping in mind that the roles and tasks continue to fan out to supporting steps, work products, guidelines, and patterns, it is clear that this is beyond starting small. As a matter of fact, we are likely to be overwhelmed if we try to absorb all of this material at once.
Figure 8.5. View of the PBE roles and how they map to phases of PBE
Table 8.1. Mapping of Tasks to Phases of PBE
Sticking with the idea of starting small and providing a solid foundation for successfully adopting PBE, let’s focus on a subset of tasks, including Find Project Patterns, Design a Pattern, Build a Pattern Implementation, Use a Pattern, and Capture Reuse Metrics.
Create a Pattern Specification is not part of this list because there are so many available pattern specifications that as we start introducing PBE into our organization, we are better off reusing existing pattern specifications rather than creating new ones. Capture Reuse Metrics is part of the list as we are trying to capture the benefits of using patterns; however, as we get started, we don’t necessarily need to record this information formally.
Summaries of these tasks are provided in Tables 8.2 through 8.6. More details on these tasks as well as the others are provided in Appendix F.
Table 8.2. Summary of Find Project Patterns Task
Table 8.3. Summary of Design a Pattern Task
Table 8.4. Summary of Build a Pattern Implementation Task
Table 8.5. Summary of Use a Pattern Task
Table 8.6. Summary of Capture Reuse Metrics Task
With this subset of the tasks, we will be well on our way to starting with PBE. Note that there are many other tasks, some of which we will find and perform by default as we follow and complete these key tasks.
The keys to focus on when getting started with these tasks are as follows:
• We are on the lookout for when and where we can use patterns. We adopt a mind-set of using patterns.
• In cases where a pattern does not yet exist, we look to create the pattern—where it makes sense. In particular, the use of model-to-text pattern implementations has proven to be quick and easy to learn while delivering substantial results.
• We need to measure and quantify our efforts. We cannot build or use patterns just for the sake of it. There must be a business result that we can identify, record, and use to justify the investment in our pattern efforts.
In other words, we should find guidance and support in the PBE Core Values.
Appendix F provides additional details on these tasks, along with pointers to the associated roles, work products, patterns, and guidelines needed to successfully complete them.
Leveraging the PBE Practice within Your Own Process
As mentioned earlier, PBE is a practice, not a full-fledged process. A practice can be thought of as a process component. A collection of such components is brought together to create a process specific to the needs of an organization.
To author a process via a set of practices, we use Eclipse Process Framework and Eclipse Process Framework Composer. In doing so, we need to keep in mind that we are working with a process framework, not a one-size-fits-all approach to processes. The goal is to use content building blocks and tools to build a process that works for our situation.
We have a number of practices that we can leverage, including OpenUP, Extreme Programming, and Scrum. Some organizations may prefer not to start with any of these sources, instead sampling from others. The choices depend on the work that needs to be accomplished and the skills and preferences of the team.
PBE is compatible with many other practices. In this section we will take a quick look at how we can integrate with some of them: Scrum, Extreme Programming, and OpenUP.
Building upon our earlier discussion about how to get started with the PBE Practice, here are some additional thoughts to keep in mind as we integrate with other practices:
• An iterative and incremental approach is a key aspect of how we create and work with patterns. We do not expect to find and create all patterns at the beginning of the project, falling into a waterfall approach. Nor do we want to wait until the end of the project to harvest patterns that can then be used on the next project.
• We always aim to be value-driven in deciding which patterns to create and use. We are focused on producing deliverables that meet the needs of our organization. We are not looking to create or use patterns just for the sake of doing so.
Scrum
Scrum is a project management framework that helps manage iterative projects centered on Sprints that are between two and four weeks long. Figure 8.6 provides an overview of a standard Scrum iteration. An iteration has three main elements:
• Pre-Sprint. This is when the content planning for the Sprint is done. A Sprint goal is defined, helping the team to understand the objective of the Sprint and to prioritize work. A product backlog tracks all requirements for the project. A Sprint backlog is a subset of the product backlog and is created for each Sprint. This planning is a joint activity between the product owner, who defines the priorities, and the project team, who define and estimate the associated tasks.
• Sprint. This is the heart of the Scrum iteration, where the team members sign up for tasks and perform them, providing feedback during a daily Scrum meeting. One of the characteristics of a Sprint is that the content of the Sprint backlog cannot be changed during the Sprint, ensuring that the team can focus on the agreed-upon set of requirements.
• Post-Sprint. A Sprint is concluded with a potentially shippable increment, a demo to the product owner, as well as a project review. Unimplemented requirements in the Sprint backlog are moved back to the product backlog, ready to be discussed with other requirements in the next pre-Sprint phase.
Figure 8.6. Overview of Scrum
Copyright 2005, Mountain Goat Software. Reused under the Creative Commons license.
Integrating PBE with Scrum
Integration between PBE and Scrum starts with the product backlog. The product backlog contains a list of functional and nonfunctional requirements. It is this latter category where we list the patterns that need to be built. In early Sprints we find that we are focused on identifying the patterns that may need to be built. As we progress through our Sprints, we find that we are able to select not only features, but also patterns that need to be built, adding these to the Sprint backlog. We may want to pre-allocate some of each Sprint to working on the patterns that have been identified (for example, within each Sprint, 10% of the effort will go toward building a pattern).
We can also integrate with the planning efforts associated with creating the Sprint backlog. As part of the analysis done for the Sprint, team members will consider how patterns can help them to deliver the elements in the Sprint backlog.
Another integration opportunity is the daily Scrum meeting. We can discuss any patterns that have been identified, those that are in use, and those that are in the process of being built. In this way we can ensure that the entire team is aware of possible patterns, assisting with the evaluation, and contributing to the overall pattern effort.
OpenUP
OpenUP is an iterative, incremental, Agile, and open-source development process that is minimal, complete, and extensible. The OpenUP project lifecycle is split into four phases, each one having its own focus and goal:
• Inception focuses on the definition of the high-level scope of the project.
• Elaboration focuses on defining and validating the architecture of the project.
• Construction focuses on implementing the remaining features, using and enhancing the architecture created during elaboration.
• Transition focuses on transitioning the developed product to the users, including deployment, training, and any other activity needed to make the transition as successful as possible.
Figure 8.7 provides an overview of OpenUP. The OpenUP phases drive the project lifecycle, which in turn drives the iteration lifecycle and micro-increments. Corresponding to this flow we see that the high-level project plan is used to coordinate the overall project. Each phase is subdivided into one or more time-boxed iterations that target the creation of an executable product increment. The scope and content of an iteration are detailed in an iteration plan. Work is assigned to each team member using work items.
Figure 8.7. OpenUP project management overview
Reprinted under the Eclipse Public License. Please visit http://www.eclipse.org/epf/downloads/openup/openup_downloads.php to access this material online.
Integrating PBE and OpenUP
There are a number of places where we can integrate PBE with OpenUP. We need to ensure that we map the PBE tasks to the right phases and the right level.
Initial pattern identification tasks are performed during the inception and elaboration phases. However, as new pattern sources or opportunities arise, we can come back to these tasks, regardless of the phase.
Pattern production and consumption tasks are started during elaboration and carried through to the transition phase. Recall that we use patterns across the SDLC, so we may end up building and using patterns targeted specifically at transition activities.
Pattern management tasks occur across all phases and all projects. Funding and staffing models for these efforts determine how these tasks will impact our project plans.
Extreme Programming (XP)
Extreme Programming is an Agile process that is iterative and encourages interaction and communication. As shown in Figure 8.8, it is based on a set of practices that reinforce and counterbalance each other.
Figure 8.8. Overview of Extreme Programming practices
Credit: Ronald E. Jeffries, www.Xprogramming.com.
The outer circle contains the practices that focus on the overall project and producing incrementally, iteration after iteration:
• Whole team. The whole team, usually no more than ten people, sits together in a room. The team includes a customer representative.
• Planning game. This is used to plan the content of the release as well as to split the content into two- to three-week iterations. Features to implement are expressed via user stories.
• Small release. New versions of the application are released frequently, typically every two or three months.
• Customer tests. The customer representative prioritizes the user stories and tests the resulting implementation.
The middle circle contains a set of supporting practices:
• Collective ownership. Source code is modifiable by every team member; code must be well documented and have supporting tests.
• Coding standard. The use of standards is encouraged to ensure that code is developed following best practices and supports collective ownership.
• Continuous integration. The application is built and tested frequently (at least daily) to avoid late integration and divergence issues.
• Metaphor. This is used to help the team stay in unison with one another and the overall project architecture.
• Sustainable pace. A sustainable pace discourages team exhaustion by having developers work no more than 40 hours a week.
The inner circle contains the practices that are performed by the developers on a day-to-day basis:
• Test-driven development. In this technique development starts with writing tests. The objective of the developers is to write just enough code to successfully pass the tests.
• Refactoring. The focus is on improving the quality of existing code without changing its functionality.
• Simple design. Design should focus only on current needs. If new needs arise in the future, we can use refactoring to adapt.
• Pair programming. Team members are encouraged to work in pairs; one writes the code while the other observes. The observer is tasked with spotting bugs and considering possible tests.
Integrating PBE with XP
PBE is compatible with many of the XP practices. Let’s take a look at a few of the possibilities:
• Planning game. As part of the planning game we can identify pattern opportunities, determine which patterns to build, and leverage Piecemeal Pattern Creation (Chapter 10).
• Coding standard. Model-to-text pattern implementations can be used to ensure that code that is created adheres to the project and organizational standards. As standards evolve, it is easy to reapply them and update the code.
• Continuous integration. Pattern implementations can be run in a headless fashion and integrated with an automated build system. User regions in the generated solution ensure that code added by the Pattern User is not overwritten. Tests generated by the pattern can be included in the automated build process and used to report on the quality of the solution.
• Test-driven development. Pattern implementations can be set up to generate the test cases that will need to be passed by the solution. Typically the Pattern User will have to add content to the output that is generated by the pattern implementation. Thus, the tests will exist before the solution is created.
• Pair programming. PBE uses pair programming in the creation of the patterns themselves. Typically a pairing of a Pattern Implementation Author and a Pattern Author/SME occurs as a pattern is created.
• Simple design. Having an approach whereby we create and use patterns within the same project drives us to support our current needs. In addition, patterns such as Exemplar Analysis (Chapter 12) and Pattern Selection Driven by Requirements (Chapter 16) keep us focused on current needs and best practices.
Summary
In this chapter we looked at the process implications associated with PBE. With PBE our focus is on using pattern specifications and pattern implementations, but doing so in a systematic and disciplined manner while quantifying results, impact, and decisions.
The team needs to understand the roles involved in the effort, the tasks that need to be performed, what artifacts are produced and consumed, and how PBE connects with the process that they follow in the larger software delivery effort. There is no single PBE path that all organizations can follow; we need to come up with the approach that works for our team and our situation.