Cyclical Software Engineering Methodology

In this section, a family of theorems are presented that pertain to the cyclical software engineering methodology.
The cyclical software engineering methodology will find solutions in both static and dynamic environments
but not in dynamic environments that have the non-monotonic property.
If a solution exists, and the
cyclical software engineering methodology finds the solution, the best case performance is *O*(1), the
worst case performance is *O*(*N*), while the
average case performance is *O*(*N*)
^{5.4}
where N is the total number of steps in the environment.

Let
be the *n*_{a} steps
leading to the possible analysis *A* with *a*_{1} being the
initial problem statement.
Let
be the *n*_{d} steps
leading to the possible design *D*.
Let
be the *n*_{i} steps leading
to the possible implementation *I*.
Let
be the *n*_{t} steps leading
to the possible testing *T*
with *t*_{nt} being the final system acceptance test.
Though this static environment includes the same steps as in the other sections, these steps are not necessarily taken in the same sequence as those established in the other sections but are the sequence taken by a cyclical methodology. A cyclical methodology has a simple selection process which defines this order.
Define a static environment that consists of the four planes of analysis, design, implementation, and testing with each lower plane being a refinement of the higher planes.
Define the solution as the tree, or in a more general sense,
the directed acyclic graph, of all steps from all four planes
used in the final system. This solution can be represented as a sequence of steps.
See Figure 5.5 on page for a visual representation of the environment.
See Figure 5.12 on page for a visual guide of the reasoning.
The numbers associated with the steps represent the order
visited by the methodology.

A cyclic methodology leads to this sequence of
steps.

The last step is the system acceptance test.
Thus a cyclical methodology is static complete.

These steps are generated in an iterative fashion and eventually exhaust the static environment.

If the environment is static, then all steps in the environment are known before the cyclical methodology begins. The cyclical methodology discovers steps in an iterative fashion in the analysis plane, the design plane, the implementation plane, and the testing plane. This iterative discovery of steps from all four planes continues until the environment was exhausted.

Let the environment consist of
*n*_{a} analysis steps, *n*_{d} design steps, *n*_{i} implementation steps, and *n*_{t} testing steps.
Let the correct analysis step be the very first step
*a*_{1}.
Let the correct design step be the very first step
*d*_{1}.
Let the correct implementation step be the very first step
*i*_{1}.
Let the system acceptance test be the very first step *t*_{1}.
To satisfy the problem statement would
require one analysis, one design, one implementation, and one testing step. In this environment, the cyclical software engineering methodology will require only four steps.
Thus the performance is O(1).

The cyclical software engineering methodology has no mechanism to manage a non-monotonic step. Consider a dynamic environment with two highly conflicting requirements and their associated design, implementation, and testing steps. The cyclical software engineering methodology would pick one requirement and build the associated system. The cyclical software engineering methodology, because there is no mechanism to manage a non-monotonic step, then picks the second conflicting requirement. The first solution is negated in order to build a second system. The cyclical software engineering methodology oscillates between these two systems with no convergence to a common solution. The final system acceptance test fails because one of the conflicting requirements can never be accomplished. Thus, the cyclical software engineering methodology is incomplete for a non-monotonic environment.