 |
 |
 |
|
 |
|||
| RE 1.4: Investigation of Technical Feasibility |
RE1.4 - Technische Durchführbarkeit untersuchen
 Contents
|
|
|---|
Product Flow
| From | Product | to | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Activity | State | Chapter | Title | Activity | State | ||||||||||||||||||||||||||||||
| External (1) | - | All | Existing source code | - | -
| External (1) |
- |
All |
Further information (2) |
- |
-
| RE1.1 |
being proc. |
2 |
User Demand.Actual Status |
- |
-
| RE1.2 |
being proc. |
3 |
User Demand.Current Analysis |
- |
-
| RE1.3 |
being proc. |
4 |
User Demand.Possible Solutions |
- |
-
| - |
- |
5 |
User Demand.Technical Feasibility |
RE1.5 |
being proc.
| |
Handling
In this activity it is checked if the basic Technical Requirements (Reverse Engineering) for the realization of the planned reverse engineering measure have been met. The following questions have to be clarified:
- Is the source code completely available?
The demand for completeness of the source code is based on the fact that it must be possible to generate loadable software from the collected source code, this software must match the behavior of the loadable software originally available. If the software to be processed consists of Assembler programs, then the completeness of the source code is best verified when the loadable software is restored by disassembly of the source code.
If the source code is written in a higher programming language, the completeness and the updated status of the source code can be confirmed by evaluating the configuration documents or by generating loadable software from the collected source code, and by comparing the contents of the generated executable files byte by byte with the content of the executable files that were originally available. If the compared data deviate from each other it is not true in every case, however, that the source code had not been completely collected, since such differences do not necessarily lead to a different behavior of the loadable software.
Other possibilities to check the source code may result in references to its incompleteness, but not to the confirmation of its completeness. By this way, it is possible, for example, to come to the conclusion that the source code is incomplete because of the error messages received during compilation and linking. In complex applications, it is also possible to find out, by observation, differences in the behavior of the generated and the original software that allow the conclusion that the source code is not complete. References to the incompleteness can also be discovered statically by investigating the invocation relationships in the source code as well as the data objects used. If a procedure is invoked that is not part of the set of the collected source code, then the source code is probably incomplete. The same is true when a reference is made to data objects that were not declared in the collected source code. During the course of such investigations it must be taken into consideration that identifiers in different parts of the source code have been used several times, that calling procedures are stored in program paths that cannot be reached and that the explicit declaration of data objects is not possible in all programming languages.
- Can loadable software be generated from the source code?
The demand to generate loadable software from the available existing source code is based on the fact that it is possible to come up with essential conclusions with regard to the relationship between the user-level tasks realized by that software, and by the technical structure of the software after observing (together with experts) the behavior of the source code. In order to check the processed software it is also required to be able to generate loadable software from the modified/changed source code.
The generation of loadable software from the source code is based on the requirement that the original environment, or another suitable, compatible development environment is available (compiler, linker, loader, library software, etc.). Furthermore, the statements for the compilation, binding, loading, and installing must be known.
- Is sufficient user-level information available?
The demand for the availability of sufficient user-level information is based on the fact that user-level information is an indispensable requirement for restoring the User Demand that are realized by the processed software. Without user-level information, reverse engineering can only restore the technical aspects for the software to be processed.
Since it is not possible to get any feedback about the quality of the available user-level information at this stage of reverse engineering, its quantity must be taken as an indicator for the technical feasibility.
- Reformatting, restructuring, remodularization:
The complete source code and the development environment must be available since no modification/change must be made to the source code with out subsequent checks. User-Level information is not required since this task only refers to the technical aspects of the software.
If the software to be modified realizes processes then the remodularization should not be made during reverse engineering but in connection with the realization of forward engineering measures.
- Recommenting:
The complete source code, the development environment, and the user-level information must be available because comments of the source code cannot be changed without subsequent checks, and since the source code cannot be commented in a user-level way without user-level information.
- Restoring the technical aspects of the software:
The availability of the source code is sufficient for restoring the technical aspects of the software, since the documentation of the technical aspects can be extracted directly from the source code.
- Restoring the user-level aspects of the software:
In order to restore the User Demand, the availability of the source code is only sufficient if, based on very good comments, all required user-level information can be obtained from the source code or when the original developer of the software is available as a source of information and can give all information about User Demand based on the source code. In general, however, the restoring of the user-level software aspects depends on the availability of external or user-level source code information.
Notes (1) Customer
(2) Other system and software documentation and all other available information.
|
|
|
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
|