Phases of SE: 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. There are four fundamental phases in most, if not all, software engineering methodologies. These phases are analysis, design, implementation, and testing. These phases address what is to be built, how it will be built, building it, and making it high quality.

The Analysis Phase

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. Traditionally, the requirement document is written in English or another written language. 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. There is a fuzzy line between high-level descriptions and low-level details. 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. An example of a low-level detail that might appear in the requirement document is the usage of a particular vendor's product line, or the usage of some accepted computer industry standard, or a constraint on the image size of the application. There is a fundamental conflict between high levels and low levels of detail. The requirement document states what the system should accomplish, independent of many of the details. The discovery process used in establishing the requirements during the analysis phase is best described as a refinement process than as a levels-of-detail process 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 a typical scenarios of usage

The Design Phase

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.

The Implementation Phase

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.

The Testing Phase

Simply stated, quality is very important. Many companies have not learned that quality is important and deliver more claimed functionality but at a lower quality level. It is much easier to explain to a customer why there is a missing feature than to explain to a customer why the product lacks quality. A customer satisfied with the quality of a product will remain loyal and wait for new functionality in the next version. Quality is a distinguishing attribute of a system indicating the degree of excellence In many software engineering methodologies, 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. Unfortunately, delegating testing to another team leads to a slack attitude regarding quality by the implementation team. Alternatively, another approach is to delegate testing to the whole organization. If the teams are to be known as craftsmen, then the teams should be responsible for establishing high quality across all phases. Sometimes, an attitude change must take place to guarantee quality. The testing technique is from the perspective of the system provider. Because it is nearly impossible to duplicate every possible customer's environment and because systems are released with yet-to-be-discovered errors, the customer plays an important, though reluctant, role in testing.