Software Engineering
The description below can be found on Wikipedia and stems from the Guide to the Software Engineering Body of Knowledge - 2004 Version.
We think this description is clear enough. However, there are some issues in software engineering that need some clarification.
Craftmanship versus Engineering
Is developing software craftmanship or engineering? The answer is in the description at the top of this page. Developing software by experience can lead us in the right direction. This is craftmanship. But experience can only take us to a certain point when we enter unknown territory. Then we have to go on making it better through a controlled process of refinement. This is engineering. Actually, software engineering is based on craftmanship. We need craftmanship to accomplish the smaller processes in developing software, as part of software engineering.
What is Software Design?
In our opinion the final document of the design phase in software engineering is the source code listing. This idea was coined by Jack W. Reeves in his articles What is Software Design? (1992) and What is Software Design: 13 Years Later.
We repeat here the summarization from the articles.
- Real software runs on computers. It is a sequence of ones and zeros that is stored on some magnetic media. It is not a program listing in C++ (or any other programming language).
- A program listing is a document that represents a software design. Compilers and linkers actually build software designs.
- Real software is incredibly cheap to build, and getting cheaper all the time as computers get faster.
- Real software is incredibly expensive to design. This is true because software is incredibly complex and because practically all the steps of a software project are part of the design process.
- Programming is a design activity -- a good software design process recognizes this and does not hesitate to code when coding makes sense.
- Coding actually makes sense more often than believed. Often the process of rendering the design in code will reveal oversights and the need for additional design effort. The earlier this occurs, the better the design will be.
- Since software is so cheap to build, formal engineering validation methods are not of much use in real world software development. It is easier and cheaper to just build the design and test it than to try to prove it.
- Testing and debugging are design activities -- they are the software equivalent of the design validation and refinement processes of other engineering disciplines. A good software design process recognizes this and does not try to short change the steps.
- There are other design activities -- call them top level design, module design, structural design, architectural design, or whatever. A good software design process recognizes this and deliberately includes the steps.
- All design activities interact. A good software design process recognizes this and allows the design to change, sometimes radically, as various design steps reveal the need.
- Many different software design notations are potentially useful -- as auxiliary documentation and as tools to help facilitate the design process. They are not a software design.
- Software development is still more a craft than an engineering discipline. This is primarily because of a lack of rigor in the critical processes of validating and improving a design.
- Ultimately, real advances in software development depend upon advances in programming techniques, which in turn mean advances in programming languages. C++ is such an advance. It has exploded in popularity because it is a mainstream programming language that directly supports better software design.
- C++ is a step in the right direction, but still more advances are needed.
What is Software Architecture?
There exist many definitions for software architecture, but none of them grasp the idea of abstraction in software design. In our opinion software architecture is the most abstract level of the software design, identifying components and their interactions without implementation details which can be decided upon on a lower (less abstract) level. Each component has its own architecture and each interaction can be refined into a component.
So, it is the structure that uphelds the system.