Our Development Approach

Initiation/Planning

This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, target dates etc.... The planning process is intensified and focused specifically on software. To understand the nature of the program(s) to be built, the system engineer or "Analyst" must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved

Analysis

The analysis phase defines the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the "what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details. The requirement document may be expressed in a formal language based on mathematical logic.

The requirement document does not specify the architectural or implementation details, but specifies information at the higher level of description. The problem statement, the customer's expectations, and the criteria for success are examples of high-level descriptions. Sometimes, if an exact engineering detail needs to be specified, this detail will also appear in the requirement document. This is the exception and should not be the rule. These exceptions occur for many reasons including maintaining the consistency with other established systems, availability of particular options, customer's demands, and to establish, at the requirement level, a particular architecture vision.

Traditionally, the requirement document describes the things in the system and the actions that can be done on these things. Things might be expressed as objects in an object-based technology where data and algorithms are hidden behind hierarchical-polymorphic methods. Alternatively, things might be expressed as services accessing databases in a functional approach where data is a fundamentally different concept than functions. In general, the description of things in the system can be much more general and not confined to a particular technology. In a more general sense, this document describes the ontology that is the noun phrases and the verb phrases that will become the guidelines for defining the application specific protocol.

The requirement descriptions of the things in the system and their actions does not imply an architecture design rather a description of the artifacts of the system and how they behave, from the customer's perspective. Later, in the design phase, these requirement descriptions are mapped into computer science based primitives, such as lists, stacks, trees, graphs, algorithms, and data structures.

The description of the abstraction of the noun phrases and the verb phrases are not bound to the use of a written human language. Most written human languages are too vague to capture the precision necessary to build a system. Alternative descriptive mechanisms based on mathematical logic are sometimes more suitable but much more difficult to accomplish. Mathematical logic provides a scientific foundation for precisely expressing information. However, frequently in the real world, a precise description is not attainable.

Again the requirement document should state in a clear and precise fashion what is to be built. The definitive mechanism to author such a document, either formally or informally, has yet to be developed, although reasonable success has been achieved with existing methods including CASE tools and tools based on mathematical logic

Later, in the design phase, the very important decomposition of the problem leads to the development of data structures and algorithms. A functional decomposition for a distributed environment leads to a natural split of the data structures and algorithms. Examples include distributed client-server systems, where a database holds the data in a server while the algorithms manipulating the data reside on the client. An object-based decomposition leads to a natural joining of data structures and algorithms forming objects with methods. The requirement documents should be independent of the decomposition technique.

The analysis team develops the requirement document, which talks about things and actions on things. This document should also include states, events, typical scenarios of usage, and typical scenarios of usage.

Design

In the design phase the architecture is established. This phase starts with the requirement document delivered by the requirement phase and maps the requirements into architecture. The architecture defines the components, their interfaces and behaviors. The deliverable design document is the architecture. The design document describes a plan to implement the requirements. This phase represents the "how'' phase. Details on computer programming languages and environments, machines, packages, application architecture, distributed architecture layering, memory size, platform, algorithms, data structures, global type definitions, interfaces, and many other engineering details are established. The design may include the usage of existing components. The architectural team can now expand upon the information established in the requirement document. Using the typical and a typical scenarios provided from the requirement document, performance trade-offs can be accomplished as well as complexity of implementation trade-offs.

Obviously, if an action is done many times, it needs to be done correctly and efficiently. A seldom used action needs to be implemented correctly, but it is not obvious what level of performance is required. The requirement document must guide this decision process. An example of a seldom used action which must be done with high performance is the emergency shutdown of a nuclear reactor.

Analyzing the trade-offs of necessary complexity allows for many things to remain simple which, in turn, will eventually lead to a higher quality product. The architecture team also converts the typical scenarios into a test plan.

In our approach, the team, given a complete requirement document, must also indicate critical priorities for the implementation team. A critical implementation priority leads to a task that has to be done right. If it fails, the product fails. If it succeeds, the product might succeed. At the very least, the confidence level of the team producing a successful product will increase. This will keep the implementation team focused. Exactly how this information is conveyed is a skill based on experience more than a science based on fundamental foundations.

Implementation

This phase is where "the rubber meets the road". In the implementation phase, the team builds the components either from scratch or by composition. Given the architecture document from the design phase and the requirement document from the analysis phase, the team should build exactly what has been requested, though there is still room for innovation and flexibility. For example, a component may be narrowly designed for this particular system, or the component may be made more general to satisfy a reusability guideline. The architecture document should give guidance. Sometimes, this guidance is found in the requirement document. The implementation phase deals with issues of quality, performance, baselines, libraries, and debugging. The end deliverable is the product itself.

Testing

The testing phase is a separate phase which is performed by a different team after the implementation is completed. There is merit in this approach; it is hard to see one's own mistakes, and a fresh eye can discover obvious errors much faster than the person who has read and re-read the material many times. The illustration below reflects the phases taken during the testing process:

: