There are four fundamental phases of Software Engineering. 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.
First Phase: The Analysis/ Study 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.
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.
Second Phase: 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.
Third Phase: 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.
Fourth Phase: The Testing Phase
As we know, 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.
Software Engineering Cem Kaner