Agile Software Development
Автор: Alistair Cockburn /
CHAPTER 4. Methodologies Methodology Concepts
-
Часть 5
-
A medium-high level is the class diagram, showing classes, attributes, and relationships with cardinality.
A high level of precision is the list of classes, attributes, relations with cardinality constraints, and functions with function signatures. These often are listed on the class diagram.
The final, highest level of precision is the source code.
Figure 4-7. A Responsibility-Collaboration diagram: the low-precision view of an object-oriented design.
These levels for design show the natural progression from Responsibility-Driven Design (Beck 1987, Cunningham URL-CRC) through object modeling with UML, to final source code. The three are not in opposition, as some imagine, but rather occur along very natural progression of precision.
As we get better at generating final code from diagrams, the designers will add precision and code-generation annotations to the diagrams. As a consequence, the diagrams plus annotations become the "source code. " The C++ or Java stops being source code and becomes generated code.
The User Interface Design
The low-precision description of the user interface is the screen flow diagram, which states only the purpose and linkage of each screen.
The medium level of precision description consists of the screen definitions with field lengths and the various field or button activation rules.
The highest precision definition of the user interface design is the program's source code.
Figure 4-8. Using low levels of precision to trigger other activities.
Working with "Precision"
People do a lot with these low-precision views. During the early stages of the project, they plan and evaluate. At later stages, they use the low-precision views for training.
I currently think of a level of precision as being reached when there is enough information to allow another team to start work. Figure 4-8 shows the evolution of six types of work products on a project: the project plan, the use cases, the user interface design, the domain design, the external interfaces, and the infrastructure design.
In looking at Figure 4-8, we see that having the actor-goal list in place permits a preliminary project plan to be drawn up. This may consist of the project map along with time and staffing assignments and estimates. Having those, the teams can split up and capture the use-case briefs in parallel. As soon as the use-case briefs—or a significant subset of them—are in place, all the specialist teams can start working in parallel, evolving their own work products.
One thing to note about precision is that the work involved expands rapidly as precision increases. Figure 4-9 shows the work increasing as the use cases grow from actors, to actors and goals, to main success scenarios, to the various failure and other extension conditions, and finally to the recovery actions. A similar diagram could be drawn for each of the other types of work products.
Because higher-precision work products require more energy and also change more often than their low-precision counterparts, a general project strategy is to defer, or at least carefully manage, their construction and evolution.
Figure 4-9. Work expands with increasing precision level (shown for use cases).
Stability and Concurrent Development
Stability, the "likelihood of change, " varies over the course of the project (Figure 4-10).
A team starts in a situation of instability. Over time, team members reduce the fluctuations and reach a varying state as the design progresses. They finally get their work relatively stable just prior to a design review or publication. At that point, the reviewers and users provide new information to the development team, which makes the work less stable again for a period.
On many projects, instability jumps unexpectedly on occasions, such as when a supplier suddenly announces that he will not deliver on time, a product does not perform as predicted, or an algorithm does not scale as expected.
You might think that you should strive for maximum stability on a project.
However, the appropriate amount of stability to target varies by topic, by project priorities, and by stage in the project. Different experts have different recommendations about how to deal with the varying rates of changes across the work products and the project stages.
Figure 4-10. Reducing fluctuations over the course of a project.
Figure 4-11. Successful serial development takes longer (but fewer workdays) compared to successful concurrent development.
The simplest approach is to say, "Don't start designing until the requirements are Stable (with a capital 'S'); don't start programming until the design is Stable, ” and so on. This is serial development. Its two advantages make it attractive to many people. It is, however, fraught with problems.
The first advantage is its simplicity. The person doing the scheduling simply sequences the activities one after the other, scheduling a downstream activity to start when an upstream one gets finished.
The second advantage is that, if there are no major surprises that force a change to the requirements or the design, a manager can minimize the number of work-hours spent on the project, by carefully scheduling when people arrive to work on their particular tasks.
There are three problems, though.
The first problem is that the elapsed time needed for the project is the straight sum of the times needed for requirements, design, programming, test, and so on. This is the longest time that can be needed for the project. With the most careful management, the project manager will get the longest elapsed time at the minimum labor cost. For projects on which reducing elapsed time is a top priority; this is a bad tradeoff.
The second problem is that surprises usually do crop up during the project. When one does, it causes unexpectedly revision of the requirements or design, raising the development cost. In the end, the project manager minimizes neither the labor cost nor the development time.
-
Закладки
Games are not just for children, although children also…
It follows that on the Theory Building View, for the primary…
Crystal Clear is the most tolerant, low-ceremony small-team…
Using the planning game in this way, the sponsors can properly…
The chart shows the state of the user stories being worked on…
Figure 4-1. Elements of a methodology. Roles. Who you…
After much coaching for six months, his programs still…
Accepting program modifications demanded by changing external…
For us as designers, it was possible to express both propositional…
Types of Methodologies Rechtin (1997) categorizes methodologies…
Agility implies maneuverability, a characteristic that…
In arguing for the Theory Building View, the basic issue is…
We see an example of needing these normalizing rituals in the…
On a new project, I would use Crystal Orange as a base methodology…
The group of 17 quickly agreed on those value choices. Developing…
The industry is littered with projects whose sponsors…
The main question is, if you were funding this project, which…
Walk around your place of work. Notice · The convection currents…