Basic OOAD Process

Created 8/24/00 - Go Back

The top goals for Mini Proces 3 (MP3) are extreme flexiblity, scalability, power, ease of getting started and ease of use, in that order. The first few are architectural and hard to change. The last few are lower level and much easier to improve with time.

We introduce one abstraction at a time until the entire approach to process has been painted. These abstractions allow process to be handled at the deeper level necessary for process componentization. Once you've grasped the essential components you can configure the process you need for each project, considering variables like team size, project size, project complexitity, timeline, skill levels, domain type, organizational maturity, etc.

The Basic OOAD Process is the foundational process for MP3, so we start there with this question:

"What is a good, lightweight, flexible, basic approach to creating a system using sound Object Oriented Analysis and Design principles?"

Core Steps

Engineers solve complex problems. To do this more effectively and efficiently they have adopted various tricks of the trade. The most powerful is a standard, structured approach to solving any problem. Here's our approach, boiled down to four core steps:

Note how the steps are abstracted at so high a level they apply to any domain, including software. The only hint we are accommodating software is Deliverables for Design and Implementation, which mention modeling, source code and such.

The Core Steps never change, regardless of problem domain. For example they can be used on fixing a lawn mower, fixing a bug, building a dog house and speeding up a slow sorting algorithm. Next, we look at an example of using the Core Steps.

Core Steps Example

1. Concept - Change the corporate logo on all company software products.

2. Analysis - The corporate logo is a penguin of standard shape and color. Different products need different size images and each product has many windows of various size, so each product has its own image files. There are 120 different image files altogether. The 120 master copies reside on 5 servers in two cities. A single design master is in marketing. Any image changes must be manually made to each file. A problem is all those manual changes are fraught with risk. (A potential improvement has been identified, part of any good analysis.)

3. Design - We choose to solve the manual change problem once and for all, by designing a program which, given the design master, updates all 120 other masters automatically. It uses reference data in a single text file to determine master copy location and image size. The program is so easy to write that's all the design we need, other than a sample of the text file format, which will be used to test a dummy product first.

4. Implementation - A dummy product is created and the text file is written for it. Using that for testing, the program is written and debugged. The complete text file is written. After a corporate wide weekend backup the program is run and all 120 images checked by hand for correctness. Two mis-sized ones are found, the text file is edited, the program is run again, the two images are okay, some of the other images are checked again, and we're done.

As you can see, this is a well done project. The core steps provided sufficient structure for an obviously sharp engineer to use. They even make it easier for us to understand what happened. Notice the substeps the engineer threw in, such as designing the test in the Design step. This is a good practice. The problem is, not all engineers do this. Most design the test after Implementation.

Now imagine what happens if you have a more complex project, especially one involving many customer requirements and classes. The four core steps provide insufficient guidance. There's simply too many good practices left out, and the average person cannot remember them all. We need more structured guidance.

Sidesteps

A repeatable, easy to understand process needs consistency at the lowest level, so the first thing we do for more structured guidance is go deeper into what a step is. Our goal is to make all steps as uniform but as flexible as possible. This can be done by adding a rather interesting abstraction, sidesteps. (We're open to better name suggestions :-)

The simple rule that all steps have these sidesteps gives our process tremendous foundational structure. Now, whenever you perform a step you do it the same way at the highest mental level. This greatly improves efficiency and effectiveness.

The key sidestep is Confirm Value. This allows eliminating the common separate testing step, integrating value with quality throughout the process. There can still be separate value confirmation steps, such as Final Testing or Customer Satisfaction Survey, but they are no longer as large, critical and unpredictable. (By the way, such steps are actually the four core steps bundled together. The process unbundles these and all such complicated looking steps.) Sidesteps implement the adage, "Test often and test early".

Examples of Confirm Value are requirements review, mapping of design to requirement elements, code inspection and testing.

Later as we get more detailed we can standardize on input and output per step. Standard input includes People, Skills, Previous Step, Standards and the cumulative product and artifacts. Standard output includes the Product, Artifacts, Metrics, Spot Improvements and Better Skills.

The Cycle Plan Step

The diagram on the right shows the flow from Customer to end Product. The minimum number of steps is just one, Implementation. However this fails to give enough structure to any but the most trivial tasks, so we have four minimum steps. These are performed in sequence to gradually move from customer needs to final product. The output of each step becomes the input to the next step.

This is the classic waterfall process, where one continues in a straight line as if falling from the start to the finish. The problem with the waterfall approach is each step has to be 100% complete before going to the next step, and each step has to remain stable until all are finished. This never happens in the real world on nontrivial projects, so we must introduce iterations.

Iterations allow steps to be cycled through again and again, adding more product mass each time, until complete.

The core steps are for single iteration work only. This occurs frequently in simple tasks, maintenance and bug fixes. The presence of a single interation process handles the very small work that otherwise would be done without structure, which is a no no. :-) Don't worry, the first two steps can be done in minutes with a worksheet or added as text to a model. The process strives to remain lightweight.

All but the simplest of tasks need multiple iterations. In defining our process, we use the word "cycle" instead of "iteration" to emphasize the cyclic nature, to use a more commonly known word, to use two less syllables and to avoid confusing the concepts of iteration and cycle as used in process definition. An iteration is a cycle type.

To define a standard cyclic process we need one more step type, which is Cycle Plan. This allows process flow to repeat planned cycles again and again until the Cycle Plan is done.

Five Step Types

Adding Cycle Plan gives the fifth and final step type. The key feature of the Cycle Plan step is it produces a list of Concepts organized along a timeline.

Cycle Block

Now let's discuss the powerful flowchart that's possible with these five step types.

A Cycle Block contains the standard process steps for a defined cyclic approach to development. The key step is the Cycle Plan, where given initial stage work, the remaining work is broken up into a sequential series of cycles. Each cycle is planned by creating its Concept, which is later the key input for that cycle.

The Initial Stage and Cycles both have all four core steps. All the Cycles are really doing is drilling down in the direction set by the Initial Stage steps. Since the same step types are used we have wonderful consistency, simplicity, power and scalability. Frequently scalable power is hard to achieve with simplicity, but careful selection and use of the five step types yields the emergent properties we seek.

A cycle block is commonly used for Release Cycles and Iteration Cycles. In an iteration the developers each use Personal Cycles to get a task done. My, my, such consistency. :-)

Cycle Block Example

Let's repeat our previous example except scale it up to require cycling.

1. Initial Concept - Redo all images, sound and multimedia on all products to reflect the new corporate merger.

2. Initial Analysis - This encompases 4,500 files on 40 products. Marketing for each product will have to redo each design master, of which there are only 8. These are then chopped up or resized, according to various rules, to create the 4,500 files. Many people have been gripping about how long this takes manually.

3. Initial Design - (architecture) - The architecture has paritions for Design Masters, Rulebase, Product Masters and Business Logic. A diagram shows these and their relationships. Using the Rulebase the Business Logic partition walks through the Design Masters one by one and translates them into the Product Masters. The test design is to do all this on 5 dummy products that are representative of all types of media and transformations.

4. Initial Implementation - (prototype) - A simple working version is created that handles one media type (the hardest one) and two transformations. It uncovers no surprises. Management approves the Initial Stage.

5. Cycle Plan - The project manager studies the analysis and design, and creates the Concept for each cycle. The Core Steps are used to analyze, design and implement the plan. Implementation consists of creating each Concept in extreme detail and confirming with various parties this is what's needed and is possible. The cycles are:

Add the Transform partition. This keeps Business Logic from getting too big.

Rollback feature.

Static images.

Sound.

Animations.

Flash.

6. Cycles - The cycles are performed one at a time until done. The project goes smoothly due to all risk being addressed in the Initial Stage and good cycles selected. Handoffs to developers are easy because the Concepts contain an extensive narrative about the cycle vision and objectives. No final testing step is deemed necessary because of continuous full regression testing during each cycle of Core Steps. The project is completed with no surprises. The process worked! :-)

Substeps

As soon as the going gets tough, we need to expand a step into a procedure. This is done with substeps. Substeps in turn can have their own substeps, allowing a process to become as detailed as necessary. In practice we usually refer to them all as steps. Unlike sidesteps, substeps can be anything needed. For example the Design step may have these substeps:

Review

Let's review what we've got here. We propose to achieve our goals with this handful of abstractions:

Step - All work is done in defined steps, aka activities.

Five Step Types - Concept, Requirements, Design, Implementation and Cycle Plan.

Substep - A step is composed of sequential or unordered substeps. A substep can contain substeps.

Sidestep - A step is also composed of sequential sidesteps. This makes steps "two dimensional", since a step can have substeps and sidesteps.

Four Standard Sidesteps - Get Input, Add Value, Confirm Value and Forward Output

These can be used to compose these semi-patterns so far, which are higher level abstractions. In fact, Cycle Block uses Core Steps, a case of a pattern using a subpattern. The ease with which these patterns emerge and the strength they give the process framework is remarkable. (Must be more of Steve Alexander's emergent properties ;-)

Core Steps - Concept, Requirements, Design and Implementation, in that order.

Cycle Block - Uses Core Steps plus Cycle Plan to structure Initial Stage and Cycles.

We will add something like the following as helper components. These are mostly descriptive. Some, such as how to construct a process, checklist, etc, are prescriptive.

Checklists - Used to precisely guide or evaluate a step or sidestep.

Guidelines - Descriptive material to define the more esoteric steps and sidesteps, and the process as a whole.

Examples - For training or reference.

Worksheets and Forms - For use in steps and workflow.

Here's the huge benefit of all the above work:

A particular process consists of concrete instances of the abstractions as defined by the patterns and helpers.

One benefit of identifying these abstractions and helpers is you can roll your own process versions faster and with a higher probability of success. Since that is not easy for some, we provide several "starter" processes, such as the Basic OOAD Process. These are expected to be customized and evolved as soon as understood deeply. So in the final analysis, Mini Process 3 is not a process but a framework (or metaprocess) for creating the process you need for your unique situation.

Next we present the various "process views" necessary to define our Basic OOAD process.

Core Steps Flowchart

We first compose a process for OOAD using just the Core Steps. This is used for "small work" where iterations are not formal. Typically the work can be done in a few hours or days.

Note how each step has its sidesteps defined, giving us a straightforward single iteration procedure. As mentioned earlier, the Confirm Value sidestep is the key one. You can see how it's used to draw out quality in each step.

Particularly interesting is the way the Design step designs the test before Implementation. By doing this in the Design step, a better Implementation will result. This is because of human nature. If one has a test design as well as a functional design as a spec, the functional implementation is bound to be better, and the test is so, so much easier to write. There's a strong tendency to just get the Implementation step done, and worry about the test later. Our approach minimized that tendency.

History has shown that the four Core Steps are not enough, so we add the Improvement Step. This encourages continuous improvement of the output of the other steps.

Summary Step

But wait. Improvement is not one of our five step types! Hmmmmm, let me delicately explain it's a "Summary Step" and has its own four Core Steps inside. These are not shown to keep the diagram simple. A Summary Step accomplishes a specific task using the four Core Steps, which may or may not be formalized. When a step's sidesteps can be done with ease intuitively, the formalization of defining the four Core Steps is not necessary, because we do them in our head. We avoid formalizing substeps whenever possible to keep the process lightweight. This gives another abstraction:

Summary Step - A step that accomplishes something using the four Core Steps.

Your first processes should not become rampantly sprinkled with Summary Steps. Keep them simple until you've mastered process. Then gently add more Summary Steps as necessary. Whenever possible, make them substeps of your five step types.

As an example, Cycle Plan is a Summary Step. The Concept is to create a cycle plan. The Analysis determines what must be accomplished. The Design step breaks that down into Concepts, but perhaps just the concept names. Implementation takes the time to create a full vision and objectives for each Concept. Dates, resources, predecessors, etc, is done in whatever step is appropriate. So for a fully defined process one would define the four Core Steps for Cycle Plan.

Cyclic Flowchart

This handles small to large cyclic development, which it typical of most projects. By use of Cycle Blocks we have simple, consistent, easy to understand process definitions for the Release Cycle and Iteration Cycle demanded by modern software engineering. This process scales to any number of developers, though as size grows specialized Summary Steps will be needed, such as Requirements Management and Predictive Acceptance. Many variations are possible starting with this foundation.

Most work is in Iteration Cycles, so their arrows are bolded. These are the steps that need the most attention in process definition and actual project planning. Fortunately this is easy, due to the consistent framework the process gives.

Note the pivotal role the Improvement step plays. It's the "hub" for the Iteration Cycle and is the interface between Release Cycle and Iteration Cycle when Final Testing finds an opportunity or problem. This is a clean design. The Improvement step encapsulates improvements, regardless of their source, causing smoother project execution.

Note the use of the Core Steps in many places - Initial Stage, Release Cycle and Iteration Plan and Iteration Cycle. This is reuse. :-)

Since this is a condensed diagram, lots is missing. The Release Cycle steps have their sidestep detail and Core Steps. All the initial steps have further detail.

One need not use the entire flowchart for a process. For example a project many not be large enough to justify release and iterations. It only needs releases. No problem. Instead of drawing another flowchart, just use one iteration per release and skip the Interation Plan.

Core Steps Grid

This is too large for this page, so see the image. Note how a Step, Objectives, Deliverables style grid can define process step detail extremely well, and is understood at a glance, once the grid concept is digested.

Cycle Steps Grid

(To be done later. Will include steps not shown on the other grid.)