U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
This step allows the system's owner to evolve the system to keep pace with changing needs, advancing and changing technology, and/or add system capabilities over time. These changes & upgrades will be performed in a systematic way to maintain or establish system integrity. Integrity in context of systems engineering means that the system's functional, performance, physical, and enabling products are accurately documented by its requirements, design, and support specifications. The system documentation is accurate and sufficient to the point where changes & upgrades can be performed by any competent development team. This gives the system's owner the freedom to have the widest possible selection of development teams for evolving the system.
The guidance in this step will address upgrades that are planned and ones that are based on new stakeholder needs. This step will also give guidance on implementing upgrades on a system that has not been well documented [see integrity as defined in the objective above ]. This step will also give guidance on handling COTS products and applications which may have:
CONTEXT OF PROCESS:
CHANGES & UPGRADES PROCESS
Legacy System is the existing system to which the upgrade or change will be applied.
Legacy System documentation includes the requirements, design, and support documentation.
Change Request identifies the new change, upgrade needs, or requirements for the system.
Systems Engineering Management Plan [SEMP] is used if the upgrade is a planned upgrade and part of the development strategy.
Configuration Management Plan describes how planned and unplanned upgrades & changes would be evaluated, coordinated, and inserted into the legacy system.
Stakeholder involvement is important when the system is being changed/upgraded, and is essential if the changes & upgrades will impact the stakeholders in some way.
Traceability ensures that the integrity is maintained through changes & upgrades as well as supports cost estimation for making changes & upgrades to system.
Documented legacy system products in the areas of change & upgrade. If the legacy system has not been well documented before the change & upgrade, documented legacy system products are employed.
Updated system products and documentation for the new capabilities, as well as the impacted areas of the legacy system.
Analyze needed changes & upgrades
Planned upgrades are executed IAW the systems engineering management plan [SEMP]. The SEMP may have a development strategy that lays out a plan for the evolution of the system over time. The plan may have several phases to the system evolution. For example, phase 1 may deploy the communications network. Phase 2 may deploy the CCTV [camera system]. Phase 3 may deploy the detection system and so on; until the system has been fully implemented. Each of these phases should be implemented using the forward engineering process.
Unplanned changes may be the result of a change in needs, technology obsolescence, requirements, or new stakeholder participation. If the system was well documented, the changes should be implemented using the forward engineering process. The system's owner's configuration management process will lay out how the changes will be evaluated, coordinated, and inserted into the system. If the system was not well documented, the reverse engineering process should be performed as described below. An analysis of the legacy system and its documentation is needed to assess to what extent, if any, a reverse engineering process is needed.
Reverse engineering is documenting the legacy system [the system being upgraded/changed]. This includes the interfaces [both internal and external to the system], hardware, software, and support products [original development tools, test plans, and traceability matrix]. This process requires one to
Forward engineering is the process of following the Vee Development Model as defined in chapters 3.3-3.7 of this guidebook. All changes & upgrades to the system start with the update of the systems engineering management plan, concept of operations. They are followed by the requirements, sub-systems, high-level design, and detailed design. When evolving, upgrading, or implementing changes to a legacy system, it should be in a forward engineering approach as suggested in this guidebook.
Where do the Changes & Upgrades take place in the project timeline?
Is there a policy or standard that talks about Changes & Upgrades?
This task would include all of the tasks from phase [-1] to 4 including all FHWA Final Rule requirements and standards.
Which activities are critical for the system's owner to do?
How do I fit these activities to my project? [Tailoring]
In the reverse engineering process, first identify the areas which are going to be impacted by the upgrades and changes. Those areas should be the focus of the reverse engineering activities. This will tailor the activity to only the affected areas of the legacy system. [See below – Are there any other recommendations that can help?]
In the forward engineering activities, apply the tailoring guides identified in Chapters 3.2-3.7.
What should I track in this process step to reduce project risks and get what is expected? [Metrics]
On the technical side:
On the project management side:
Checklist: Are all the bases covered?
|Is there a change management process in place?|
|Is the documentation for the legacy system available?|
|Have the upgrades and changes been clearly identified?|
|If this has been a planned upgrade have the systems engineering management plan, concept of operations, requirements, and test plans been reviewed and updated?|
|If this is a new capability that is added to the system, have the systems engineering plan, concept of operations, requirements, and test plans been developed for this new capability?|
|Does the upgrade/change impact the project architecture? If so, is the updated project architecture consistent with the regional architecture?|
|Prior to applying changes/upgrades, have the impacted areas of the legacy system been documented to a level that the changes/ upgrades can be applied using the forward engineering process? [as described in Chapters 3.2-3.7|
Are there any other recommendations that can help?
If reverse engineering on a legacy system is needed, it should be done only to the areas that will be affected by the changes/upgrades. On major systems it may be too costly to document the entire legacy system for minor upgrades and changes. The cost effective approach is to document as needed. Over time, as changes are made, more of the system will be documented. Those areas that never get changed will not be documented.
Continue the reverse engineering process through the implementation of the changes. The reverse engineering process will document the obvious impacted areas of the legacy system that changes/upgrades will be applied to. As the changes are applied to the affected areas, the implementer must check and continue the documentation effort. Changes to a system may impact areas not intended for change or affect these areas in a subtle, unanticipated way.
It will be the implementer and test support that will most likely uncover these types of issues. They must be ready to identify and document these areas.
A closer look at reverse engineering and COTS products and applications
Reverse Engineeringis documenting an existing Intelligent Transportation Systems functional requirements [what it does], physical characteristics or design [how it does it], and the way it was built and maintained [enabling products]. Legacy system documentation may not have been complete, lost or over time, or was not kept up to date. Traditionally, system's owners would use the system to the end of its life and start over. Today there is a regional focus on multiple agency involvement, fast-paced changes in technology, and constrained budgets. Systems owners are being driven to evolve their systems and to have greater latitude in development team choices [whether this is done in-house and/or contracted]. In such situations, reverse engineering may be a good alternative to starting over.
Reverse engineering for COTS products and applications focuses on interfaces and modularity. Examples of some common elements: workstations and operating systems, databases, changeable message signs, cameras, communications, and detection & traffic control systems. Custom developments focus on user interfaces, data structures, distribution, and applications that analyze, exchange, and translate information. Both the forward and reverse engineering activities should focus on allowing these COTS products to be updated/changed as they become obsolete, have changes to design, or reach the end of their service life. Database management system [DBMS] is a good example of this. When the DBMS reaches the end of life, the system's owner can choose to stay with the existing DBMS now unsupported, or move to the latest version of the DBMS. If the system's owner chooses to upgrade, the impact may affect the current operating system and computer hardware. This, then, would impact other applications like the user interface, drivers for the camera system, changeable message signs, and communications. By keeping the applications modular, and interfaces [both internal and external] well defined, the impacts of obsolescence can be minimized.