Task V.32 Extract engineering information from existing system
V.32.1 Analyze existing documentation
Intent: The intent of this task is to perform a detailed evaluation of existing documentation to determine the extent to which it provides information that can be used during the reengineering activity.
Mechanics: Each document is reviewed for correctness, conformance to existing executable code, completeness, and lack of ambiguity. Areas of weakness are noted for potential document restructuring.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has each document been reviewed in detail?
2. Have deficiencies been noted in writing?
3. Have documents been cross-checked for conformance to executable code?
4. Are all documents available in electronic form?
5. Have all documents been placed under change control?
Do's & Don'ts
Do: Focus on content first, but don't forget to assess readability.
Do: Look for omissions and ambiguity.
Don't Expect that original analysis documentation will have been kept up to date. Be sure to check it.
Don't: Spend inordinate amounts of time reengineering requirements documents. Focus on design documentation instead.
Deliverables: notes on existing documentation
V.32.2 Extract design data and create appropriate models
Intent: The intent of this task is to examine the implemented data structures and extract design information. Data objects and their relationships are defined. The internal data structure of each data object is identified.
Mechanics: Data design information is extracted to the extent that it is not available in existing design documentation (see Task V.32.1.1). Objects, attributes, relationships and data structure are all modeled.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Will the data objects that have been identified meet the objectives for the reengineered system?
2. Has each data structure been documented?
3. Have data structures been evaluated in an attempt to simplify the data?
4. Have entity-relationship diagrams been created and reviewed with the customer?
5. Has the structure of any external databases been documented?
6. Have necessary changes to data structured been documented?
Do's & Don'ts
Do: Try to reduce reliance on global data structures for the reengineered application.
Do: Use the most simple data structure for the job.
Don't: Forget linked lists and other similar structures when data must be inserted randomly.
Don't Forget to examine the algorithms that manipulate data structures as part of your evaluation.
Deliverables: documented data structures
V.32.3 Model existing program architecture or class hierarchy
Intent: The intent of this task is to examine the implemented program architecture or class hierarchy (for object-oriented systems) and extract design information.
Mechanics: Architectural design information is extracted to the extent that it is not available in existing design documentation (see Task V.32.1.1). Module or class hierarchy is examined.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has an architectural model been created and reviewed?
2. Have processing narratives for each module in the architecture been created?
3. Is the current program architecture factored?
4. For OO applications: Does the class architecture remain amenable to new requirements for the reengineered system? How much of the class hierarchy can be reused in the reengineered system?
5. Have module or object interfaces been fully described and reviewed?
Do's & Don'ts
Do: Apply design principles to assess the current architecture and create a high quality reengineered architecture.
Do: Review the existing architecture using modern software engineering design criteria.
Don't: Allow the reengineering effort to proceed without a documented design.
Don't Reengineer the code without reengineering the design..
Deliverables: documented program architecture
V.32.4 Extract procedural design.
Intent: The intent of this task is to extract the procedural design from each program module (for OO systems: from each class method).
Mechanics: Procedural design information is extracted to the extent that it is not available in existing design documentation (see Task V.32.1.1). Module or class method algorithms are examined.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has the procedural design been reviewed for correctness and conformance to existing code?
2. Does the procedural design properly manipulate data structures defined in Task V.32.2?
3. Is the module interface consistent with the program architecture?
4. For OO applications: Do the class methods properly manipulate object attributes? Are the class methods consistent with the messaging model?
5. Have module or object interfaces been fully described and reviewed?
Do's & Don'ts
Do: Apply design principles to assess the current algorithm and create a high quality reengineered algorithm.
Do: Review the existing procedural design using modern software engineering design criteria.
Don't: Allow the reengineering effort to proceed without a documented design.
Don't Reengineer the code without reengineering the design..
Deliverables: documented procedural design for each program module
V.32.5 Extract technical infrastructure products
Intent: The intent of this task is to extract information on the operational environment (the technical infrastructure) in which the application to be reengineered resides. The technical infrastructure includes the hardware, operating system, network architecture, communication protocols, and existing utilities that form the environment for the application.
Mechanics: Information developed in Task V.29.2.3 is refined and a detailed schematic representation of the technical infrastructure is created. The schematic depicts the elements of the infrastructure and the manner in which the application to be reengineered interacts with these elements. In addition, detailed descriptions of the requisite interfaces between elements of the technical infrastructure is also created.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has an infrastructure schematic been created and does it identify all elements of the infrastructure?
2. Has coupling between the application and the infrastructure been fully described?
3. Has a detailed interface description been created and reviewed?
4. Have modules that are coupled to the technical infrastructure been identified within the application?
5. Have risks associated with the existing technical infrastructure been identified?
Deliverables: refined schematic of the technical infrastructure and related descriptive information
V.32.6 Integrate extracted products
Intent: The intent of this task is to integrate information developed as part of Tasks V.32.1 through V.32.5.
Mechanics: Design information is combined to create the basis for a design document that describes the application to be reengineered.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
Deliverables: integrated design information
V.32.7 Build reverse engineered documentation
Intent: The intent of this task is to create a Design Document that describes the application to be reengineered.
Mechanics: The design document is created following the outline or template adopted by the local organization. If a design document already exists, it is augmented with any information derived from earlier Tasks V.32.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has each section of the design document been reviewed for correctness, completeness and lack of ambiguity?
2. Does the Design Document provide an accurate picture of the environment in which the existing application operates?
Deliverables: Design Document
V.32.8 Review all reverse engineered products
The tasks associated with review of the reverse engineered products are described in the Formal Technical Reviews umbrella task.
Use Browser "back" arrow or return to APM Process Design Language Description
