In Software Development, design is a phase of software life cycle. It is based on the requirements specification produced by the analysis of the requirements (analysis phase), the design defines how these requirements will be met, the structure that must be given to the software system to become a reality.
The design remains a separate phase of programming or coding, the latter corresponds to the translation in a given programming language of the premises adopted in the design.
The distinctions between the activities mentioned so far are not always clear as one wished in classical theories of software engineering. The design, in particular, can describe the internal workings of a system at different levels of detail, each of which is placed in an intermediate position between analysis and coding.
Typically, "architecture design" is understood as the "very high level" design, which only defines the structure of the system in terms of the software modules of which it is composed and the macroscopic relationships between them. At this level of design belong formulas such as client-server or "three levels", or, more generally, the decisions about the use of the special hardware architecture that is used, the operating system, DBMS, Network protocols, etc.
An intermediate level of detail can define the decomposition of the system into modules, but this time with a more or less explicit reference to the decomposition mode offered by the particular programming language with which the development is to be implemented, for example, in a design made with object technology, the project could describe the system in terms of classes and their interrelationships.
The detailed design, finally, is a description of the system very close to coding (for example, describing not only abstract classes, but also their attributes and methods with their types).
Due to the "intangible" nature of the software, and depending on the tools used in the process, the boundary between design and coding can also be virtually impossible to identify. For example, some CASE tools are able to generate code from UML diagrams, which graphically describe the structure of a software system.
During this stage the tasks that are commonly known as programming are performed; which essentially consists in bringing to the source code, in the chosen programming language, everything designed in the previous phase. This task is performed by the programmer, completely following the guidelines imposed in the design and always considering the functional and non-functional requirements (ERS) specified in the first stage.
It is common to think that the stage of programming or coding (some call it implementation) is the one that consumes most of the software development work; however, this may be relative (and generally applicable to small systems) since the previous stages are crucial, critical, and may take considerably longer. Estimates are usually made of 30% of the total time spent in programming, but this figure is not consistent since it depends to a large extent on the characteristics of the system, its criticality and the chosen programming language.
The lower the language level, the longer the programming time will be, so it would take longer to encode an assembly language algorithm than the one programmed in C language. While programming the application, system, or software in general , there are also debugging tasks, this is the task of releasing the code from the feasible errors of being found in this phase (semantic, syntactic and logical).
There is a sort of overlap with the next phase, since to debug the logic it is necessary to perform unit tests, normally
with test data; Of course not all errors will be found only in the programming stage, there will be others that will be encountered during subsequent stages. The occurrence of some functional error (poor response to requirements) may eventually lead to a return to the design phase before further coding.
During the programming phase, the code can take several states, depending on the form of work and language chosen, namely:
- Source code: is written directly by programmers in text editors, which generates the program. It contains the set of instructions encoded in some high level language. It can be distributed in packages, procedures, source libraries, etc.
- Object code: is the binary or intermediate code resulting from processing the source code with a compiler. It consists of a complete and one-time translation of the latter.
The object code is not intelligible by the human being (usually it is binary format) but it is not directly executable by the computer. This is an intermediate representation between the source code and the executable code, for the purposes of a final link to the library routines and between procedures, or for use with a small intermediate interpreter [for example, see EUPHORIA, ( interpreter), FORTRAN (pure compiler) MSIL (interpreter) and BASIC (pure interpreter, intermediate interpreter, intermediate compiler or pure compiler, depending on the version used)].
The object code does not exist if the programmer works with a language as a pure interpreter, in this case the interpreter is responsible for translating and executing line by line the source code (according to the program flow), at runtime. In this case, there is no executable file (s) either. A disadvantage of this modality is that the execution of the program or system is a little slower than if it were done with an intermediate interpreter, and rather slower than if the executable file (s) existed.
In other words, it does not favor performance in execution speed. But a great advantage of the pure interpreter mode is that this form of work greatly facilitates the task of debugging the source code (versus the alternative of doing it with a pure compiler). Often a mixed form of work is used (if the chosen programming language allows it), that is to say initially to work as a pure interpreter, and once the source code has been debugged (freed of errors) a compiler of the same language is used to get the complete executable code, which facilitates debugging and execution speed is optimized.
- Executable code: The binary code is the result of linking one or more object code fragments with the necessary routines and libraries. It consists of one or more binary files with a format such that the operating system is able to load it into the RAM (possibly also part of a virtual memory), and proceed to its direct execution. By the above it is said that the executable code is directly "intelligible by the computer". The executable code, also known as machine code, does not exist if it is programmed with "pure interpreter" mode.
Software Testing (Unity and Integration)
Among the various tests carried out on the software, the following can be distinguished:
- Unit tests: These consist of testing or testing small pieces of software; at the level of sections, procedures, functions and modules; those that have specific functionalities. Such tests are used to ensure the correct functioning of code sections, much smaller than the set, and which have specific functions with some degree of independence.
- Integration tests: They are performed once the unit tests were successfully completed; with these attempts are made to ensure that the complete system, including the subsystems that make up the large individual pieces of software, operate correctly when operating and interacting together. Tests are usually performed with so-called test data, which is a selected set of typical data that can be subjected to the system, modules or code blocks.
Also chosen are: Data that leads to software boundary conditions in order to test its tolerance and robustness; utility data for performance measurements; data that cause unusual or unusual conditions to which the software will not normally be subject but may occur; etc
The "test data" are not necessarily fictitious or "created", but normally they are those of little probability of occurrence. Generally, there is a final and complete test phase of the software, called Beta Test, during which the system installed under normal operating and working conditions is thoroughly tested to find errors, instabilities, erroneous responses, etc. that have passed the previous controls.
These are usually carried out by suitable personnel hired or specifically affected. The possible errors are transmitted to the developers for debugging. In the case of development software "on demand", the end user (client) is the one who performs the Beta Test, having for this purpose a trial period agreed with the developer.
Installing and Moving to Software Production
Software installation is the process by which the developed programs are properly transferred to the target computer, initialized, and eventually configured; all for the purpose of being used by the end user. It constitutes the final stage in the development of software itself. After this, the product will enter into the operation and production phase, for which it was designed. The installation, depending on the developed system, can consist of a simple copy to the destination hard disk (rare cases at the moment); or, more commonly, with an intermediate complexity in which the various software components (executables, libraries, own data, etc.) are decompressed and copied to specific pre-set locations on the disk; even creating links with other products, in addition to the operating system itself.
The latter case is commonly a fairly automatic process that is created and guided with specific software tools (packaging and distribution, installers). In products of greater complexity, the second alternative is the one used, but it is carried out or guided by specialists; it may even require installation on several different computers (distributed installation).
Also, in medium and high complexity software, a configuration and check process is usually required, whereby adequate operating parameters are assigned and the functional operation of the product is tested. In mass-selling products, complete installations, if relatively simple, are usually performed by the end users themselves (such as operating systems, office packages, utilities, etc.) with their own guided installation tools; even the configuration is usually automatic.
In products of specific design or "to measure" the installation is usually restricted to specialists involved in the development of the software in question. Once the software has been successfully installed, it goes into the production phase (operativity), during which it fulfills the functions for which it was developed, that is, it is finally used by the end user (s), producing the expected results.
Software maintenance is the process of control, improvement and optimization of software already developed and installed, which also includes debugging of errors and defects that may have been leaked from the test phase of control and beta test. This phase is the last (before iterating, depending on the model used) that applies to the software development lifecycle.
The maintenance phase is the one that comes after the software is operational and in production.
A good design and development documentation will depend on how the maintenance phase will be, in both temporary and monetary costs. Modifications made to software that was drawn up with improper or poor documentation and bad design can become as much or more expensive than developing the software from the start. For this reason, it is fundamentally important to respect all the tasks of the development phases and to maintain adequate and complete documentation.
The period of the maintenance phase is usually the highest throughout the life cycle. This phase also involves updates and evolutions of the software; does not necessarily imply that the system had errors. One or more changes in software, for example adaptation or evolutionary, may even lead to review and adaptation from the early stages of initial development, altering all others; depending on how deep the changes are.
The common cascade model is particularly costly in maintenance, since its rigidity implies that any change causes a return to the initial phase and strong alterations in the other phases of the life cycle. During the maintenance period, new revisions and versions of the product are common; which frees it more purified, with greater and better functionality, better performance, etc.
There are several facets that can be altered to bring about desirable, evolutionary changes, adaptations or extensions and improvements. Basically you have the following types of changes:
- Perfective: Those that lead to an improvement of the internal quality of the software in any aspect: Restructuring of the code, clearer definition of the system and its documentation; performance optimization and efficiency.
- Evolutionary: Aggregates, modifications, even eliminations, necessary in the software to cover their expansion or change, according to the needs of the user.
- Adaptive: Modifications that affect the environments in which the system operates, such as: Changes in hardware configuration (by upgrading or upgrading electronic components), changes in base software, in database managers, in communications , etc.
- Corrective: Alterations necessary to correct errors of any type in the developed software product.
You May Also Like