Mini Process Elements

October 25, 1998 - Jack Harich

Here we explain the elements used in the Mini Process. This is actually hard to do without lots of hand waving, direct training and practice, so this document is a supplement for learning the Mini Process from someone who knows how to apply it well.

Note - This is in progress and incomplete - JH

Purpose

The purpose of the Mini Process is to serve as the easiest, quickest possible starting point for a formal process in software development. This is a high hurdle that about 75% of all software organizations have not yet jumped, and it's hard. Most stumble when they try, denounce the methods they tried, and return to their informal, haphazard techniques that depend on individual smarts and heroics for success. The core problem is this is absolutely non-scalable. A side issue is it is difficult to improve the efficiency of an informal process without formalizing it.

Element Strategy

We keep the number of elements small. There are 6 required and 5 optional elements.

Each element is as simple as possible. For example 3 of the elements (Nutshell Vision, Use Case List and Trait List) can be as short as a paragraph. For Use Case elaboration we advocate a text list of steps, not an Interaction Diagram. For modeling we advocate only Class Models at first. For GUI mockups we lean towards paper sketches, because they are faster and less constricting. There is a constant emphasis on simplicity.

The elements are grouped into Goal (1), Problem Definition (2 to 5), Design (6 to 7) and Implementation (8 to 11). This grouping is not emphasized at first in order to avoid introducing one more source of confusion. Instead we paint a picture of the Mini Process as being a smooth, easy continuum.

We gain a multi-dimensional view of the problem space in 3 ways: Use Cases, Traits and Risk. Since problem definition is far and away the crucial step in problem solving, and building systems is really just solving customer's problems, we are putting extreme emphasis on a clear, concise, deep definition of the problem. This is what gifted analysts do in their heads.

The Mini Process Steps

First, of course, you name the product, system or subsystem. This is not a step, since it is usually done before embarking on development.

We find it most productive to use visual tools to perform the first 8 steps. It helps greatly if you can put the system name, Nutshell Vision, Use Case List, Trait List, Risk List, high level Class Model and Implementation Plan on one page. This is easy for small systems. *** PUT EXAMPLE HERE ***

1. Nutshell Vision

This should be expressed in a single, crystal clear sentence. For larger systems 2 or 3 sentences, or even paragraphs, may be used. Keep it concise. It should state what the system does for its users in their language. Compressing this into a small, perfect Nutshell Vision statement is a wonderfully clarifying experience. Expect to fine tune the statement during the first few steps. After that it should be stable. Examples are:

A large, reusable subsystem that handles all visual behavior.
The client portion of the management utility for a (flagship product name) derivative product.
Reusable infrastructure for drillable data models supporting tree, list, row set and field data structures. The purpose is to decouple the GUI and Business Logic layers.

2. Use Case List

Modern software development is Use Case centric. This is because Use Cases have turned out to be the best way of capturing what the customer wants to do and how they prefer to do it. Use Cases are a mix of what and how, analysis and design, without getting very deep into design. Thus the transition from analysis to design is smoother and more likely to satisfy the user. The main advantage of Use Cases is system requirements are much easier to collect and validate, since they are in the user's language and expressed in how the user thinks. Users typically help collect and validate the Use Cases.

Most systems have a "Start Up" use case, so put that first on your list. Then brainstorm for the most important use cases. Then drill down. If the list gets long, use an outline format.

A Use Case consists of a goal, name, one or more actors, and one or more steps to achieve the goal. Often the goal and name are the same. In this step we are listing just names. You may optionally include the different types of actors. An example is:

Use Case List

  • System Startup (Admin)
  • Logon (User)
  • Device Tab (User)
    • Device Type 1
      • Add a device
      • Remove a device
      • Edit a device
    • Additional device types...
  • Additional Tabs....
  • Logoff (User)
  • System Shutdown (Admin)

3. Major Use Cases Stepped Out

(to be continued)