Introduction

A software engineering project involves people guided by common goals and strategies working with a collection of tools to produce documents and code. The tools include compilers, debuggers, environments, change management,   source control,   project management,   document processors, and domain modeling tools. The documents produced include requirements that define the problem, customer manuals, test plans,   scenarios,   a design that defines the architecture, and implementation plans. The code may deal with objects, data structures, algorithms, methods, modules, protocols, and interface definitions. The strategies are materialized through the collection of the architecture, methods, paradigms,   risk analyses,   conventions, and a mission statement. These steps together define the cradle-to-grave life cycle   of the software project.

Just how should a software engineering project be managed? The answer is not unique nor is it clearly defined. It is a combination of many ingredients. One of the key ingredients in the management of an engineering project is the methodology.  

      Two well-known categories of software engineering methodologies are the sequential and the cyclical, informally known as the waterfall and spiral methodologies. A third methodology is introduced here, called the WaterSluice methodology, which combines the best aspects of the previous two methodologies. It takes the iterative nature of the cyclical methodologies and the steady progression of the sequential methodologies and then adds priority and conflicting requirement management.

All three methodologies deal with four simple phases of software engineering, namely analysis, design, implementation, and testing. These concepts are first introduced before the detailed discussion of methodologies.

The following is the main theorem of the thesis.

Theorem 1   Different software engineering methodologies have significant performance variations depending on the given environment. A software engineering methodology that is goal focused, manages conflicts, and differentiates between different priorities is best suited for dynamic non-monotonic environments.

Though the statement of the theorem appears simple, the complexity is in the details of the formal definitions of software engineering methodologies, performance, and environment. The variations in performance of different software engineering methodologies are sufficiently great as to make the choice of which software engineering methodology to use dependent on the surrounding environment.

First the environment will be defined. As discussed later, the environment definition is built from the definitions of the analysis, design, implementation, and testing phases. Each phase defines a plane which is then defined in terms of atomic, compound, and complex steps. One step may have a sibling relationship with other steps. Together the four planes form a multi-layered space, either static or dynamic. In some cases, a dynamic space may exhibit the non-monotonic property. There are two special steps: the problem statement and the system acceptance test. The environment is the multi-layered space consisting of the analysis, design, implementation, and testing planes with two special steps: the initial problem statement and the system acceptance test.

Next we define the methodology, as discussed later, as an algorithm that finds a solution in the given environment of the multi-layered space consisting of the analysis, design, implementation, and testing plane starting with the root represented by the problem statement and ending with the goal represented by the system acceptance test. Three classes of methodologies are presented: sequential, cyclical, and the WaterSluice.

Finally, we define performance, as discussed later, as the number of steps needed by a methodology to find a solution. A family of theorems and corollaries are then proven. In summary, the proceeding theorems and corollaries generate several key results:

• All three categories of software engineering methodologies are complete for static environments. See Theorems 2, 3, and 4.
• Only cyclical and WaterSluice are complete for dynamic environments. See Corollaries 2.4, 3.4, and 4.1.
• Only WaterSluice is complete for non-monotonic environments. See Corollaries 2.5, 3.5, and 4.2.
• The best case performance of sequential software engineering methodology is O(N). See Corollaries 2.1.
• The best case performance of cyclical and WaterSluice software engineering methodologies is O(1). See Corollaries 3.1, and 4.3.
• The worst case performance of all three categories of methodologies are the same. See Corollaries 2.2, 3.2, and 4.4.
• On average, the sequential methodology will find a solution in O(N). See Corollary 2.3. On average, the cyclical methodology will find a solution in O(N). ^1.1 See Corollary 3.3. On average, the WaterSluice will find a solution an order-of-magnitude less than N. See Corollary 4.5.
• A software engineering methodology that is goal focused, manages conflicts, and differentiates between different priorities is best suited for dynamic non-monotonic environments.

As an analogy, the search section compares the three methodologies to algorithms in a search space. It will be shown that the sequential methodologies is analogous to a breadth-first search, the cyclical methodologies is analogous to a depth-first search, and the WaterSluice methodology is analogous to a best-first search.

Some established methodologies are reviewed in Chapter 4 including Boehm-Waterfall Methodology, Boehm-Spiral Methodology, Booch Methodology, Object Modeling Technique (OMT), Rational Objectory Methodology, and WinWin Spiral Methodology.

Chapter 7 reviews several large projects while future work is outlined in Chapter 8.