Software Development Phases: Traditional Phases Make No Sense

1. Rethinking the Concept of Modeling Phases

Many people, particularly generalizing specialists with a wide understanding of development will hear a requirement, ask a few questions to analyze what is actually needed, and then proceed to designing it in their heads. This typically occurs within a matter of minutes if not seconds. Clearly the concept of modeling phases is questionable, but I’m also beginning to wonder if the idea of focusing on requirements, analysis, and even design makes much sense these days. Perhaps we should just talk about modeling in general, or perhaps we should focus on other types of modeling instead.

Assume that we decide to focus on modeling, or better yet agile modeling, in general. I think that it is still valuable to consider requirements, which to me should identify what our stakeholders want; analysis, which investigates the details pertaining to the requirements; and design, which focuses on identifying how we intend to fulfill those requirements. Very useful concepts, but not very useful phases.

Now let’s take a different tack and try to identify what concepts should replace the activities of requirements, analysis, and design. One way that we could do this is to take a bottom up approach by considering potential modeling artifacts and identifying categories which they belong to. Or we could take a top-down approach and consider existing categories of modeling prevalent within software development. Or we could combine the two approaches, which is what I’ve done, to identify the following categories of modeling activities:

1. Usage modeling. The focus of usage modeling is to identify how people work with your system. Potential artifacts include business use cases, system use cases, UML use case diagrams and user stories. Usage modeling crosses the boundary of traditional requirements and analysis, and arguably even design, because when you model usage you explore what users will do with the system as well as how the system will support that usage (e.g. by considering user interface and deployment decisions). Personas and scenarios should also be considered.
2. Process modeling. The goal of process modeling is very similar to usage modeling in that it is to explore how people work with the system, taking into account the flow of the activities being performed. The main difference is that usage modeling techniques don’t fully address the flow of artifacts, including but not limited to information, within a system whereas process models do. Potential process models include data flow diagrams (DFDs), flow charts, and UML activity diagrams.
3. User interface (UI) modeling. UI modeling can include UI requirement identification via paper UI prototypes, traditional prototyping, and/or user interface flow modeling (storyboarding). Usability issues are clearly an important concern when developing the UI.
4. Supplementary requirements modeling. There is more to identifying what stakeholders need than usage or UI modeling, hence the need for supplementary artifacts which address these critical details. For example many systems have complex business rules, constraints, glossaries, or technical requirements and sometimes a requirement is best identified via a simple feature definition.
5. Conceptual domain modeling. The goal of conceptual domain modeling, sometimes simply called either conceptual modeling or domain modeling, is to identify the entities, their responsibilities, and their relationships within your problem domain. Potential models which you may want to consider include class responsibility collaborator (CRC) models, logical data models (LDMs), object role model (ORM) diagrams, robustness diagrams, or UML class models.
6. Architectural modeling. Architectural modeling should focus on the high-level design of a system or that of an enterprise as the case may be. Although virtually any model can be used for architectural modeling, I prefer models which can be used to explore the general landscape of your efforts. This includes free-form diagrams, UML component diagrams, UML package diagrams, UML deployment diagrams, and network diagrams. A supporting model are change cases, a form of architectural requirement which enables you to explore potential requirements.
7. Dynamic design modeling. The goal of dynamic design modeling is to explore the behavioral aspects of an object system. UML interaction diagrams — including UML communication/collaboration diagrams, UML composite structure diagrams, UML interaction overview diagrams, and UML sequence diagrams — can be used as can UML state machine diagrams and UML timing diagrams.
8. Structural design modeling. Structural design modeling, using UML class diagrams, UML object diagrams, and/or physical data models (PDMs).

My experience is that it is better to consider modeling categories instead of modeling phases/disciplines. Figure 1 depicts this idea, showing the eight different modeling categories described above and listing potential models within each category.

Figure 1. Iterative modeling.

It’s interesting to observe that this is very similar conceptually to Phillipe Kruchten’s 4+1 View of Modeling, albeit one with eight views instead of five. These categories are also similar to the six columns of the Zachman Framework (ZF), arguably a different take on the same basic idea. Although I would like to say that you should simply pick one model per category it’s not that simple. Here’s my advice:

1. You need one or more models from the usage and process modeling categories. This choice will often be driven by your chosen software process, following either the Rational Unified Process (RUP) you will need use case artifacts, with Extreme Programming (XP) user stories, and with a structured analysis and design approach data flow diagrams (DFDs). It is also quite common to use process models to analyze the information contained in usage models.
2. Create user interface models as needed. Some systems are UI intense whereas others are not, some developers prefer to start with essential models whereas others prefer to go straight to prototyping or even development of the actual source code itself. As always, Apply The Right Artifact(s).
3. Model supplementary requirements as appropriate. I’m a firm believer in using each type of model for what it’s good at and for recording information in one place only. Supplemental requirements such as business rules and technical requirements can and should be referred to within other development artifacts such as use cases, class models, and source code.
4. Create one type of conceptual domain model. You need to understand the business domain, and conceptual domain models are very good at that. Pick one model that best meets your needs.
5. Create architectural, dynamic design, and structural design models as needed. You often need several views of your architecture, so create the model(s) that reflect your situation. Similarly you are likely to discover that you need one or more dynamic design models from time to time, sequence diagrams are a popular choice as are state machine diagrams. Structural design diagrams are often the mainstay of modeling as they are very close to object code as well as data schemas.

2. Towards Inclusive Modeling

So how do these categories change the development landscape? First, I believe that they make the complexity of modern software development more explicit. These categories focus on the high-level issues that you should consider modeling, instead of modeling phases, and as a result provide better guidance to developers. Second, they provide insight into the types of models that you should create.

Figure 2 maps the modeling categories to individual modeling techniques, indicating which techniques are inclusive and which are complex. Inclusive techniques use simple tools (paper, whiteboards,…) and are simple in and of themselves (and are therefore easy to learn). I call these techniques inclusive because they are simple enough that stakeholders can use them, thus enabling the practice Active Stakeholder Participation.

Figure 2. Inclusive to complex techniques.

3. The Modeling Lifecycle

Figure 3 depicts the lifecycle of Agile Model Driven Development (AMDD), which is much different from the waterfall lifecycle of yesteryear. High level modeling, also called envisioning, is first done during “Iteration 0” and the details are gathered on a just-in-time (JIT) basis during development iterations. The goal of initial requirements envisioning and initial architecture envisioning is to understand at a high level what the scope and technical strategy of your initiative is. The other activities – iteration modeling, model storming, reviews, and implementation via TDD – potentially occur during any iteration, including iteration 0. It is during these activities that detailed modeling occurs, not during phases. Requirements analysis, architecture, and design are so important to agilists that we do these things every day, not just during specific phases.

Figure 3. The Agile Model Driven Development (AMDD) lifecycle for software teams (click to enlarge).

4. Adopting this Approach

It’s fair to ask what impediments exist to implementing this vision. The first impediment is the prevailing culture within the IT industry. For years we’ve been told that the modeling phases reflect how development occurs but it never really seemed to ring true with many developers, people who often threw out the “modeling baby” with the “phases bath water” when they abandoned the idea of serial development. The second impediment is existing IT specialists. There are many people who identify themselves as requirements analysts, architects, object designers, or database designers, all jobs which reflect “phasist thinking”. It would be far more effective if people could identify themselves as the more general concept of modelers or better yet simply as developers who happen to have solid modeling skills.

In short, I’m simply not convinced that the modeling phases of requirements, analysis, and design make sense any more. Nor, in the case of the various flavors of the Unified Process, do they make sense as disciplines. We need to rethink our approach to modeling within the IT industry, and my experience is that the categories which I have described above are far more realistic of an approach. Think about it.

Source

Parts of this article have been excerpted from The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2.