Home
Content
I have heard that "software is easy to change" many times over the years. The fact is that making a change to a software component is as complicated as making a change to a hardware component, and there is a process for software development just as there is a process for hardware development.
The system development process continues with software engineering. The advantages of having a process are many, and include being able to map from one artifact to another, being able to explain why things are done, showing a level of competence, and giving customers confidence.
Once the documents defining "the what" have been produced by the system engineering team, it is up to software engineering to describe "the how", at least for the software that will drive the computer. During the requirements analysis phase, each requirement must be addressed and a system architecture derived that will meet the collection of requirements.
Software engineering consists of overlapping phases as follows:
As part of the software development process there are reviews before each phase of development. The reviews are as follows:
The physical topology from the system specification is helpful for defining the software architecture. I have seen some inexperienced programmers use the physical topology as the software architecture. My experience has proven to me that it is better to do a logical topology of the system as part a software architecture. When the software architecture is complete, there will be a mapping of the logical topology to the physical topology.
High level design begins with requirements analysis to produce a data definition document and a high level design document including the logical architecture for the software system.
Taken to an extreme, everything in computer memory or on a computer storage device is data. When designing a software system, it is extremely important that every important piece of data be described.
The data description document is the most important document during the software engineering stage where detailed design is translated into code. It contains the name of each data element, the mnemonic for the data, the type of the data, and a description of the data and its purpose. This format for this document is normally a table, and it may be included as a section in the high level design document.
The high level design document is a textual description of the logical topology of the system. It describes at a high level, the inputs, outputs, purpose, and description of each element identified in the logical topology. If special processing is required, it too is described in this document. Specific algorithms may be mentioned in the high level document, but it is better to save the algorithm descriptions for the detailed design document. Data alluded to in the high level design should make specific references to the data description.
So far, requirements and a high level design have provided the "whats and high level hows". No mention has been made as to whether a structured or object-oriented methodology will be implemented. In fact, if we have done our requirements correctly, the customer, the president of my company, my manager, the programmer, or anyone with an interest of the system should be able to pick up any of the documents produced thus far and understand them without a translator.
Although the decision as to platform, language, implementation paradigm, etc. are made by upper management before the project begins, I feel that this is the correct point to determine those choices. This is where we know what system we are going to be building and can make intelligent choices.
The current fad is to use tools that support the UML for detailed design, and implement using C++. This is fine as long as we have done our homework. My preference, whether using a tool or not is to continue with good old fashioned text. No, I don't create the text file manually, but use an interactive program to create it. Once the text file is created, I have another application that will do a consistancy check, and another application that will create a nicely formatted design description document.
I have seen worse cases where design is skipped, and a development environment is used to create random classes and methods, and then use a tool like Doxygen to generate pictures that are referred to as design. These systems usually end up with an extremely large number of classes, and are unmaintainable.
Documenting a design does more than produce paper. Documentation is a tool used to help organize our thinking process. Even if I am using one of the graphical tools, I write, and require those I am responsible for, write detailed design descriptions. It is simple, a reference to the high level design, inputs and outputs referencing the data description document, purpose of the class, method, function or procedure, and a description of the processing.
By documenting in this manner, we have a trail back to the requirement.
If a graphic tool alone is used to do the detailed design, then it is extremely important to use comments in the code to describe what the code is intended to do. Comments in code can be important to the maintenance programmer if the system is around for any length of time. Code should have references to the detailed design document that describes its purpose. Code is not self documenting. I can read code in many computer languages, however, reading code lets me know what the code is doing, not what its intent is.
Common sense is a key ingredient to the system software development process. Unfortunately, there is no tool or rule to enforce it.