For enterprise-component modeling to be successful, it must live and breathe within a larger context, a software development process. We’ve developed such a process in practice, and we detail it in this chapter. We present Feature-Driven Development (FDD) in these sections:
Despite the many advances in software development, it is not uncommon for projects lasting two or more years to use a function-driven process: from functional specs (in traditional paragraph format or in use-case for- mat) to design to code to test to deployment. Along the way, some have made minor modifications to the theme, allowing some influence from iterations. Nevertheless, many software projects exceed budget, blow schedule, and deliver something less than desired (something appropri- ate two years earlier, yet no longer). As if that weren’t enough pressure, the ever-increasing pace of tech- nological advances makes it less and less likely that a project lasting more than two years will ever succeed. In fact, more and more, we are mentoring projects with total schedules of 90, 120, or 180 days—or perhaps 9, 12, or 18 months. One market-leader we work with considers any project longer than 180 days as high-risk. Why? Their business changes so rapidly and the support- ing technology changes so rapidly that planning nine months out adds risk to the project. That’s quite a change in perspective. The authors of BLUR: The Speed of Change in the Connected Economy put it this way:
Speed is the foreshortening of product life cycles from years to months or even weeks.... Accelerated product life cycles and time- based competition have become part of the business lingo.... The faster things move, the less time you have to plan for them. You’re much better off iterating and reiterating, adjusting as you go. STAN DAVIS AND CHRISTOPHER MEYER [D AVIS98]
The norm for fast-cycle-time projects is a feature-driven iterative process, beginning with features and modeling, followed by design-and- build increments. In this chapter, we formalize the process we call “Feature-Driven Development” (FDD). We’ve developed FDD in practice. Project teams apply it with sig- nificant success. Developers like it. With FDD, they get something new to work on every two weeks. (Developers love new things.) With FDD, they get closure every two weeks. Closure is an important must-have element for job satis- faction. Getting to declare “I’m done” every two weeks is such a good thing. Managers like it too. With FDD, they know what to plan and how to establish meaningful milestones. They get the risk-reduction that
focuses developers on producing working results every two weeks, facilitates inspections (making inspections, a best practice, easier to accept and simpler to apply), provides detailed planning and measurement guidance, promotes concurrent development within each “design by feature, build by feature” increment, tracks and reports progress with surprising accuracy, and supports both detailed tracking within a project and higher-level summaries for higher-level clients and management, in business terms.
where an object is a person, place, or thing (including roles, moments in time or intervals of time, or catalog-entry-like descriptions) For example,
Calculate the total of a sale. Assess the fulfillment timeliness of a sale. Calculate the total purchases by a customer.
management An example is “product-sales management.” We start an informal features list while developing the overall model. We write down features we hear from domain members and glean con- tent from documents we are working with. We build a detailed features list after developing an overall model. Some features come by transforming methods in the model to features. Most features come from considering each pink moment-interval (busi- ness areas) and writing down the features. For example, see the model snippet in Figure 6-1.
Feature-Driven Development 185 We could transform its methods into:
Feature set Making a product sale to a customer Features Calculate the total of a sale. Assess fulfillment timeliness for a sale. Calculate the total purchases by a customer.
Yet we can do even more, considering additional features that will better satisfy client wants and needs. Here’s an example:
Major feature set Product-sale management Feature set Making a product sale to a customer Features Calculate the total of a sale. Assess the fulfillment timeliness for a sale. Calculate the total purchases by a customer. Calculate the tax for a sale. Assess the current preferences of a customer.
For each additional feature, we add corresponding methods to the model. Normally we don’t do this right away, but rather during the “design by feature, build by feature” iterations. In practice, we’ve seen again and again that building an overall model and an informal features list before developing a detailed features list:
brings domain members together to talk with each other, listen to each other, and develop a common model of the business—before developing a fully detailed features list, increases developer members’ understanding about the domain and how things interrelate within it (even if they have built sys- tems in the domain before),
186 Java Modeling in Color with UML 11 0..0..
<<moment-interval>> ProductSale
calcTotal assessTimelinessOfDelivery
<> Customer
calcTotal
FIGURE 6-1. A model snippet.
In this light then, let’s take a look at the top reasons for developing and using a process:
1. Move to larger projects and repeatable success. 2. Bring new staff in with a shorter ramp-up time. 3. Focus on high-payoff results.
6.4.1.1 Move to larger projects and repeatable success. To move to larger projects and repeatable success, you need a good process, a system for building systems. Simple, well-defined processes work best. Team members apply them several times, make refinements, and commit the process to memory. It becomes second nature to them. It becomes a good habit. Good habits are a wonderful thing. They allow the team to carry out the basic steps, focusing on content and results, rather than process steps. This is best achieved when the process steps are logical and their worth immediately obvious to each team member. With complex processes, about all you can hope for is “process pride,” since learning and applying the process can keep you away from getting the real work accomplished. With good habits in using simple, well-defined processes, the process itself moves from foreground to background. Team members focus on results rather than process micro-steps. Progress accelerates. The team reaches a new stride. The team performs!
6.4.1.2 Bring new staff in with a shorter ramp-up time. Well bounded, simple processes allow the easy introduction of new staff: it dramatically shortens their learning curves and reduces the time it takes to become effective and efficient. When there is a practiced and simple sys- tem in place, it takes far less time for someone new to understand how things are done and to become effective. Standardization benefits also come into play here if processes are subject to them (standard language, process templates, naming conventions, where to find things, and the like). It is far more effective to be able to spend a little time on process training and a lot of time on problem-domain training. The ramp-up to being productive will be shorter and much more efficient.
6.4.1.3 Focus on high-payoff results. We’ve seen far too many technologists going beyond what is needed, and in extreme cases striving for (unattainable) perfection on one part of a pro- ject, without considering the other parts they compromise by doing so. It’s absolutely essential that your team focuses and stays focused on producing high-payoff results. Here are some suggestions for doing just that. Help the team come to grips with this proverb:
Every time you choose to do, you choose to leave something else undone. Choose wisely. PETER COAD SR.
188 Java Modeling in Color with UML That means (in this context) setting and keeping priorities, building the must-have features, getting to “good enough,” and not going beyond till other features get their due. Make weekly progress reports visible to everyone on the team. And make individual progress visible at each desk. Here’s how: Use your own form of “features completed on time” scorecards. Some organizations use colorful stickers for this, indicating “feature kills” (features completed on time) and “feature misses” (features that are late). The politically correct prefer “feature wins” rather than “feature kills.”
6.4.2 Who Selects Tools for a Process?
Across-the-team-uniformity of tools in dealing with the various process artifacts streamlines what you do. So project tool selection is another important area to have well bounded. Yet who selects tools? And who builds them? We find that it’s a good idea to designate a Tools Board, one or more people with the charter of defining tools to support the process, selecting most tools from vendors, and building smaller in-house tools as needed. Use the Tools Board to drive all tooling decisions. And use its exis- tence to thwart side-tracks by your best and brightest (who might occa- sionally fall in love with a custom tool and spend valuable time designing and building that tool, rather than designing and building client-valued project results). But beware: Tools for the sake of tools is just as bad as process for the sake of process. Tools support the process. The Tool Board should strive to ensure that the tools work well together in a team environ- ment. If a tool gets in the way, get rid of it. Tools are a means to an end.
6.4.3 How Might One Describe a Process?
The best processes we’ve applied were expressed in one or two pages. Surprised? It takes extra effort to write a process with simplicity, clarity, and brevity. As Pascal once put it:
I have made this letter longer than usual, because I lack the time to make it short. 1 BLAISE PASCAL
Feature-Driven Development 189 (^1) “Je n’ai fait cette lettre plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.” Blaise Pascal, Lettres Provinciales (1656–1657), no. 4.
FDD Process #1: Develop an Overall Model Domain and development members, under the guidance of an experienced component/object modeler (chief architect), work together in this process. Domain members present an initial high-level, highlights-only walk-through of the scope of the system and its context. The domain and development members produce a skeletal model, the very beginnings of that which is to follow. Then the domain members present more detailed walkthroughs. Each time, the domain and development members work in small sub-teams (with guidance from the chief architect); present sub-team results; merge the results into a common model (again with guidance from the chief architect), adjusting model shape along the way.
In subsequent iterations of this process, smaller teams tackle specialized domain topics. Domain members participate in many yet not all of those follow-up sessions.
Entry Criteria The client is ready to proceed with the building of a system. He might have a list of requirements in some form. Yet he is not likely to have come to grips with what he really needs and what things are truly “must have” vs. “nice to have.” And that’s okay.
Tasks Form the Modeling Team Project Management Required The modeling team consists of permanent members from both domain and development areas. Rotate other project staff through the modeling sessions so that everyone gets a chance to observe and participate.
Domain Walkthrough Modeling Team Required A domain member gives a short tutorial on the area to be modeled (from 20 minutes to several hours, depending upon the topic). The tutorial includes domain content that is relevant to the topic yet a bit broader than the likely system scope.
Study Documents Modeling Team Optional The team scours available documents, including (if present): component models, functional requirements (traditional or use-case format), data models, and user guides.
Build an Informal Features List Chief Architect, Chief Programmers Required The team builds an informal features list, early work leading up to FDD Process #2. The team notes specific references (document and page number) from available documents, as needed.
Develop Sub-team Models Modeling Team in Small Groups Required The Chief Architect may propose a component or suggest a starting point. Using archetypes (in color) and components, each sub-team builds a class diagram for the domain under consideration, focusing on classes and links, then methods, and finally attributes. The sub-teams add methods from domain understanding, the initial features list, and methods suggested by the archetypes. The sub-teams sketch one or more informal sequence diagrams, too.
Develop a Team Model Chief Architect, Modeling Team Required Each sub-team presents its proposed model for the domain area. The chief architect may also propose an additional alternative. The modeling team selects one of the proposed models as a baseline, merges in content from the other models, and keeps an informal sequence diagram. The team updates its overall model. The team annotates the model with notes, clarifying terminology and explaining key model-shape issues.
Log Alternatives Chief Architect, Chief Programmers Required A team scribe (a role assigned on a rotating basis) logs notes on significant modeling alternatives that the team evaluated, for future reference on the project.
Verification Internal and External Assessment Modeling Team Required Domain members, active in the process, provide internal self-assessment. External assessment is made on an as-needed basis, to clarify domain understanding, functionality needs, and scope.
Exit Criteria To exit this process, the team must deliver the following results, subject to review and approval by the development manager and the chief architect: Class diagrams with (in order of descending importance) classes, links, methods, and attributes. Classes and links establish model shape. Methods (along with the initial features list and informal sequence diagrams) express functionality and are the raw materials for building a features list. Plus informal sequence diagrams. Informal features list Notes on significant modeling alternatives
Feature-Driven Development 191 FDD Process #2: Build a Features List The team identifies the features, groups them hierarchically, prioritizes them, and weights them. In subsequent iterations of this process, smaller teams tackle specialized feature areas. Domain members participate in many yet not all of those follow-up sessions.
Entry Criteria The modeling team has successfully completed FDD Process #1, Develop an Overall Model.
Tasks Form the Features-List Team Project Manager, Development Manager Required The features-list team consists of permanent members from the domain and development areas.
Identify Features, Form Feature Sets Features-List Team Required The team begins with the informal features list from FDD Process #1. It then: transforms methods in the model into features, transforms moment-intervals in the model into feature sets (and groupings of moment-intervals into major feature sets), (and mainly it) Brainstorms, selects, and adds features that will better satisfy client wants and needs. It uses these formats: For features: the <by|for|of|to> a(n) For feature sets: <-ing> a(n) For major feature sets: management where an object is a person, place, or thing (including roles, moments in time or intervals of time, or catalog-entry-like descriptions)
Prioritize the Feature Sets and Features Features-List Team Required A subset of the team, the Features Board establishes priorities for feature sets and features. Priorities are A (must have), B (nice to have), C (add it if we can), or D (future). In setting priorities, the team considers each feature in terms of client satisfaction (if we include the feature) and client dissatisfaction (if we don’t).
Divide Complex Features Features-List Team Required The development members, led by the chief architect, look for features that are likely to take more than two weeks to complete. The team divides those features into smaller features (steps).
Verification Internal and External Assessment Features-List Team Required Domain members, active in the process, provide internal self-assessment. External assessment is made on an as-needed basis, to clarify domain understanding, functionality needs, and scope.
Exit Criteria To exit this process, the features-list team must deliver a detailed features list, grouped into major feature sets and feature sets, subject to review and approval by the development manager and the chief architect.
192 Java Modeling in Color with UML FDD Process #4: Design by Feature (DBF) A chief programmer takes the next feature, identifies the classes likely to be involved, and contacts the corresponding class owners. This feature team works out a detailed sequence diagram. The class owners write class and method prologs. The team conducts a design inspection.
Entry Criteria The planning team has successfully completed FDD Process #3, Plan by Feature.
Tasks Form a DBF Team Chief Programmer Required The chief programmer identifies the classes likely to be involved in the design of this feature. From the class ownership list, the chief programmer identifies the developers needed to form the feature team. He contacts those class owners, initiating the design of this feature. He contacts a domain member too, if he needs one to help design this feature.
Domain Walkthrough Feature Team, Domain Optional (This task is optional, depending upon feature complexity.) The domain member gives an overview of the domain area for the feature under consideration. He includes domain information that is related to the feature but not necessarily a part of its imple- mentation to help set context.
Study the Referenced Documents Feature Team Optional (This task is optional, depending upon feature complexity.) Using referenced documents from the features list and any other pertinent documents they can get their hands on, the feature team studies the documents, extracting detailed supporting information about and for the feature.
Build a Sequence Diagram Feature Team Required Applying their understanding of the feature, plus components and informal sequence diagrams, the feature team builds a formal, detailed sequence diagram for the feature. The team logs design alternatives, decisions, assumptions, and notes. The chief programmer adds the sequence diagram (and corresponding class-diagram updates, as is nearly always the case) to the project model.
Write Class and Method Prologs Feature Team Required Each class owner updates his class and method prologs for his methods in the sequence diagram. He includes parameter types, return types, exceptions, and message sends.
Design Inspection Feature Team Required The feature team conducts a design inspection. The chief programmer invites several people from outside the team to participate, when he feels the complexity of the feature warrants it.
Log Design-Inspection Action Items Scribe Required A team scribe logs design-inspection action items for each class owner, for follow-up by that class owner.
Verification Design Inspection Feature Team Required The feature team walks through its sequence diagram(s) to provide an internal self-assessment. External assessment is made on an as-needed basis, to clarify functionality needs and scope.
Exit Criteria To exit this process, the feature team must deliver the following results, subject to review and approval by the chief programmer (with oversight from the chief architect): The feature and its referenced documents (if any) The detailed sequence diagram Class-diagram updates Class and method prolog updates Notes on the team’s consideration of significant design alternatives
194 Java Modeling in Color with UML FDD Process #5: Build By Feature (BBF) Starting with a DBF package, each class owner builds his methods for the feature. He extends his class-based test cases and performs class-level (unit) testing. The feature team inspects the code, perhaps before unit test, as determined by the chief pro- grammer. Once the code is successfully implemented and inspected, the class owner checks in his class(es) to the configuration management system. When all classes for this feature are checked in, the chief programmer promotes the code to the build process.
Entry Criteria The feature team has successfully completed FDD Process #4, Design by Feature, for the features to be built during this DBF/BBF iteration.
Tasks Implement Classes and Methods Feature Team Required Each class owner implements the methods in support of this feature as specified in the detailed sequence diagram developed during DBF. He also adds test methods. The chief programmer adds end-to-end feature test methods.
Code Inspection Feature Team Required The chief programmer schedules a BBF code inspection. (He might choose to do this before unit testing or after unit testing.) The feature team conducts a code inspection (with outside participants when the chief programmer sees the need for such participation).
Log Code-Inspection Action Items Scribe Required A team scribe logs code-inspection action items for each class owner, for follow-up by that class owner.
Unit Test Feature Team Required Each class owner tests his code and its support of the feature. The chief programmer, acting as the integration point for the entire feature, conducts end-to-end feature testing.
Check in and Promote to the Build Process Feature Team Required Once the code is successfully implemented, inspected and tested, each class owner checks in his classes to the configuration management system. When all classes for the feature are checked in and shown to be working end-to-end, the chief programmer promotes the classes to the build process. The chief programmer updates the feature’s status in the features list.
Verification Code Inspection and Unit Test Feature Team Required The features team conducts a code inspection. A team scribe logs action items for each class owner.
Exit Criteria To exit this process, the feature team must deliver the following results, subject to review and approval by its chief programmer: Implemented and inspected methods and test methods Unit test results, for each method and for the overall sequence Classes checked in by owners, features promoted to the build process and updated by the chief programmer
Feature-Driven Development 195 The chief programmer is just that, the chief! The interactions within the team are primarily between the chief programmer and the other team members (Figure 6-4). Why? We encourage this approach to accelerate progress, ensure on-going mentoring of the team members by the chief programmer, and promote uniformity of design and implementation. Overall, the chief architect mentors the chief programmers, who in turn mentor the class owners within a feature team.
6.7 TRACKING PROGRESS WITH PRECISION
How much time do teams spend within each of the five processes of FDD? Here are some useful guidelines (Figure 6-5):
Develop an overall model. 10% initial, 4% ongoing Build a features list. 4% initial, 1% ongoing Plan by feature. 2% initial, 2% ongoing Design by feature, build by feature. 77% (cycle time: every 2 weeks)
Feature-Driven Development 197 FIGURE 6-3. Feature-team membership may change with each DBF/BBF iteration.
Chief Programmer Class Owners FIGURE 6-4. Interactions within a feature team.
Again, the percentages are useful guidelines (not absolutes). The initial “develop an overall model, build a features list, and plan by feature” sequence consumes 16% of project schedule. The ongoing iter- ations of those front-end activities grab another 7%. It’s the other 77% we’re concerned about in this section, the time spent in the many “design by feature, build by feature” iterations. DBF/BBF consists of six little processes and corresponding schedule- percentage guidelines (Figure 6-6):
DBF Walk through the domain. 1% Design. 40% Inspect the design. 3% BBF Code/test. 45% Inspect the code. 10% Promote to build. 1%
198 Java Modeling in Color with UML Develop an Overall Model Build a Features List Plan by Feature Design by Feature Build by Feature components components shape sequences 10% initial 4% ongoing 4% initial 1% ongoing 2% initial 2% ongoing cycle time: every two weeks FIGURE 6-5. FDD processes with schedule percentages.
Walk Through the Domain Design Inspect the Design Code Inspect the Code Promote to Build DBF BBF FIGURE 6-6. DBF/BBF milestone with schedule percentages.
Id
Description
Chief
Class
Walk-through
Design
Design Inspection
Development
Code Inspection
Promote to Build
Programmer
Owners
Planned
Actual
Planned
Actual
Planned
Actual
Planned
Actual
Planned
Actual
Planned
Actual
.<Feature-Set Name> (<# of features>)Completion percentage for this feature set: __%Expected completion month for this feature set: . FIGURE 6-7.
Feature tracking during DBF/BBF.
Feature Set (<# of features>)
Total
Not
In
Behind
Completion
Features
Started
Progress
Schedule
Completed
Inactive
% Completed
Date
(<# of features>)^ FIGURE 6-8.
Major feature set and feature set tracking during DBF/BBF (includes project-wide totals, too)
Feature-Driven Development 201 Work in progress
Completed Not yet started
Targeted Completion Month
Attention (i.e., Behind Schedule)
Overall Status:
Progress bar
Completion Percentage:
Completed
Completion Status:
MY
Making Product Assessments (14)
Dec 2001
CP- Example: Feature Set: Making Product Assessments– Work in Progress CP-1 is the Chief Programmer's Initials (14) there are fourteen features that make up this feature set Feature Set is 75% complete Target is to complete in Dec 2001
FIGURE 6-9. Reporting progress to upper management and clients.
Making Product Assessments (14)
Dec 2001
75%
CP- Invoicing Sales (33)
Dec 2001
3%
CP- Delivering Products (10)
Dec 2001
30%
CP- Shipping Products (19)
Dec 2001
10%
CP- Selling Products (22)
Nov 2001
99%
CP- Setting up Product Agreements (13)
Dec 2001
CP-
Product Sale Management (PS)
Logging Account Transactions (30)
Nov 2001
82%
CP- Opening New Accounts (11)
Oct 2001
100%
CP- Evaluating Account Applications (23)
Oct 2001
95%
CP-
Customer A/C Mgmt (CA)
Moving Content (19)
Nov 2001
82%
CP- Accepting Movement Requests (18)
Nov 2001
97%
CP- Establishing Storage Units (26)
Nov 2001
100%
CP-
Inventory Mgmt (IM)
KEY: Work in progress Attention Completed Progress Bar Not Started
FIGURE 6-10. Reporting project-wide progress to upper management and clients.
