California Division | Federal Highway Administration

4.11.2 Example Project 2 – Example Project 2 – Adding New Functionality to an Existing System

[Please note that the solution given here is for this example only. Other viable solutions may be possible. Each must be evaluated for a given project.]

Building on Example 1, a new requirement was added. The changeable message signs were to have shared control with a partner agency [Agency B]. Primary agency A owns and operates the signs and the host system that controls them. This new requirement was driven by the development of a regional architecture. The existing CMS host system was deployed prior to the regional architecture. The requirement reads, "The changeable message sign system shall share control with agency B". For this example, the smaller agency B manages events at two centers. As part of the installation, the primary agency will be installing six signs that would assist agency B for their event management. Agency B would use the CMS in coordination with their local control of traffic signals to divert traffic to appropriately get the attendees in and out of the event faster and more safely.

New software may need to be developed and integrated into the existing system. The project had an initial cost estimated at $10.5 million for the signs, new software, workstations, and communications for the participating agencies and systems engineering activities. With this new requirement, new risks and complexity are introduced relative to example 1. It is recommended that, for this example, the following systems engineering processes be used to clearly define and develop the shared control of the CMS. [In this example some of the steps needed for example project 1 [section 4.11.1] may be incorporated, e.g., Technical Reviews, others, e.g., Unit Verification by the vendor still needs to be performed ]

Process Step	Estimated Level of Effort	Check list of supporting activities	Check list of issues	Check list of risks	Examples
Feasibility	Medium 2-5 pages	Procurement Trade study Stakeholder involvement Elicitation Risk mgt	Procure the services of systems engineering services Address all user needs Definition of the problem Scope of the problem Possible solution concepts Estimated cost and benefit Identification of the portion of the regional architecture that this will fulfill Institutional issues Feasibility with existing system[s] Feasibility with partner agencies Identify project risks Technical metrics and performance Document the feasibility analysis	Picking a point solution without considering the business case or cost benefit of alternatives Selecting a solution that is not appropriate among participating agencies Proposing a solution that is too costly Incomplete solutions	Definition of the problem and need: "Sharing of CMS by Agency B for event management, and to provide alternate routing at the beginning and ending of the event". Scope: Agency B needs shared control of 6 CMS that are in the event areas Feasibility: Can the existing software be modified to include this new requirement? How much reverse engineering is needed to integrate the new requirement into the existing system? Trade study and cost benefit: Evaluate stand-alone systems controlling the signs or integrate software functionality into legacy system at the primary agency. Institutional issues: Equipment standards different between the agencies. Limited support staff and maintenance at agency B. Cost Estimate: Reverse engineering effort increased the cost of the project to $10.7 million from the original $10.5 million Identified Risks: Interagency MOUs cannot be signed or delayed Reverse engineering will be more costly than expected Standards and license agreements Security Maintenance Limited solution [not general enough for region]
Planning	Low* to Medium SEMP framework developed 2-3 pages	Stakeholder involvement Risk mgt Config. mgt Project planning Technical reviews	Identification of expected plans for the project Expected content and quality of the plans Expectations on the effort needed for the development Schedule & budget Monitoring and controlling of effort	Loss of control of the project deliverable, schedule & budget Missing critical activities Lack of long term maintenance & operations Not meeting expectations	The identified technical plans include: Development Plan [Software, Hardware] Integration Plan Deployment Plan Verification and Validation Plans Development team CM Plan Project Plan Operations & Maintenance Plan Configuration Management Plan Risk Management Plan * Note: This effort will be low if plan frameworks have already been done, medium effort if they need to be developed.
Concept of Operations & Validation Plan	Medium 5-10 pages	Elicitation Stakeholder involvement Risk mgmt Trade studies Technical reviews	Definition of the way the system will operate and be maintained Identification of the project level stakeholders e.g. Maintenance Supervisors Operators IT department Agencies' risk managers Validation of the system Limitations of shared control Alternative operational concepts Definition of user needs at the project level Identification of risks Target performance of the shared control Revised cost estimate Agency's normal Operations & Maintenance Standards	Lack of understanding on: How shared control will operate with limitations How the system will be maintained Scope of the project Who will be impacted by the control How the system will be validated What is needed for shared control Project risks Project needs Operational & Maintenance Standards and agency limitations City's policies and risks regarding control of the CMS Missing alternative operational strategies	How shared control will operate with limitations: Agency B staff needs to monitor the status of the 6 CMS and post messages on alternate routes for local events and emergency traffic conditions Be able to remotely control the signs from the supervisor's home. Limited to the use of pre-developed canned messages by agency B How the system will be Maintained: Agency B maintenance is limited and lacks the skills to maintain the communications link The standard for Agency B is a Windows-based workstation or PC. Staff can install software if installation instructions are provided or there is a standard installation wizard. The primary agency will maintain the host and communications system and provide installation support to agency B. Operational Standards and Norms Agency B is a 5-day operation that is supported on weekends for events and emergencies from the supervisor's home. The primary agency is a 7-day 24-hour operation. On weekends, if agency B cannot be reached, the primary agency has the authority to post messages on behalf of agency B [MOUs] as agreed. If any system fault occurs, the primary agency would need to identify and resolve the problem. Additional risks identified: Security of the remote link into the system; a security plan will be needed. [Update SEMP with a framework of a Security Plan.] Validation of the shared control The transfer of control between agencies will be in accordance with the scenario developed in the conops.
Development of System Level Requirements and Verification Plans	Medium 5-7 pages of Requirements and a 5-7 page Verification Plan	Stakeholder involvement Elicitation Technical reviews Trade studies Risk mgmt Config mgmt Traceability	Definition of what the system is to do to support the identified needs What will be used as the basis for accepting the completed system? New risks that may be uncovered New requirements may be needed Are all the needs addressed? Is each need addressed completely? What will be needed to support the development, operations & maintenance? Project cost The important things are implemented Establish a baseline of Requirements that will be used to build the system Validation of Requirements	Not having a basis to accept the system when completed Not completely defining what the system is to do Scope creep Expectations not met Project cost Losing control and visibility of the development Requirements not validated by stakeholders	Definition of what the system is to do to support the identified needs "The changeable message sign system shall share control with agency B." "Agency B shall have remote access to the CMS system." "Remote access to the CMS host shall be secure." "Remote access shall be limited to a pre-defined set of messages." What will be used for the basis of verification and acceptance of the system? Verification Plan would contain: Demonstrate that only a pre-defined set of messages can be displayed. Analysis that the system is secure. What will be needed to support the development, operations & maintenance? Users and maintenance documentation shall be provided Installation documentation shall be developed for the host and remote users. Project Costs With the additional support documentation and security aspects the project costs have been revised to 10.8 million If only the high priority requirements are implemented, the estimated cost is 10.6 million. Establish a baseline of requirements that will be used to build the system Requirements walk-through and a review with the stakeholders is performed for acceptance of the requirements document to establish a system baseline
High Level Design Sub-system Requirements and Verification Plans	Medium 3-5 pages for each of the sub-systems	Stakeholder involvement Trade studies Risk mgmt Config mgmt Technical reviews Procurement	What Project Architectures will be viable Sub-system Requirements Identification of candidate commercial off the shelf products Establish a sub-system baseline for each sub-system - performance Establish interface standards Sub-system verification Add content to the plans as appropriate Selection of a systems integrator Project costs and risks	Not deployable Not maintainable Inflexible Agency B staff cannot access internet from home or remotely Lack of Standards That the sub-systems are not verified Project costs Lack of facilities and services for new functionality Decomposed incorrectly	What project architectures are viable: Centralized control with direct dial-in remote links Centralized control with access via internet Centralized control call in/email via operator [man in-the-loop] Distributed workstations direct to field controllers Recommended Architecture Centralized control with access via internet [Rational] Remote workstations are platform independent Flexible in a multi-agency environment Maintenance for remotes are minimized VPN technology offers fairly good security Remote software maintained at host [thin client] Project Costs Revised cost estimate based on responses from system integrator proposals
Development of Component Level Design	Defined by the SEMP – Development Plan	Stakeholder involvement Trade studies Risk mgmt Config mgmt Technical reviews Procurement	Provide content to SEMP Reverse engineer the legacy system software and restructure for remote application [As-builds] Recommendations from the system integrator on alternatives Definition on how to implement the recommended architecture Develop the software architecture for the system Develop build-to specifications Establish a detailed design baseline Verification of the units Identification of configuration items Critical design review prior to implementation Define and document the development environment Prototype user interface Traceability between detailed design and requirements	Lack of a specification to build the system Are there alternatives that were missed? Lack of a modular design Lack of unit verification Lack of documentation for legacy system to make the needed changes to the affected areas of the system Not all requirements are addressed Losing configuration control	Provide Content to SEMP Development Plan and schedules Configuration Management Plan Risk Plan Integration Plan Deployment Plan Security Plan Definition on how to implement the recommended architecture: Detailed design of software architecture Specify the internal interfaces between the central system software for new functionality Specify Java applets developed at the host for remote access Detailed design specifications [code-to] for the Java applets and user interface Specify VPN strategy Detailed design of Oracle application Specify an internet server using Apache technology and Oracle server Specify a T1 communications link with ISP Design data tables and schemas
Hardware and software development	Defined by the SEMP – Development Plan	Technical reviews Config mgmt Risk mgmt	Development of software Purchase of commercial off-the-shelf products Development of COTS application software Configuration management of software at the developmental level Code walk-through Start development of user documentation Develop Unit Verification Procedures Developmental engineering reviews Identify project risks	Lack of traceability between the coding and the detailed design documentation Not implementing all functionality requirements Not meeting performance requirements Losing configuration control	Development of Software Coding of individual units of software Coding libraries Checking in and checking out of software for CM Code data tables Purchase of COTS products Software license Maintenance contracts Communications links
Unit verification	Defined by the SEMP Development Plan	Technical Reviews Config mgmt Risk mgmt	Check out of the units of software and hardware Communications COTS products and applications Traceability to detailed design Complete unit functionality	Propagating defects to a higher level Inability to verify units and to complete development at the unit level	Check out the units of software and hardware Check out purchased servers Integrate basic COTS applications with server and verify operations Check units of software that it can perform as specified Installed communications check End-to-end test [Pinging messages] Evaluate data rates and delays
Unit integration	Defined by the SEMP Integration Plan	Technical review – verification readiness review Config mgmt Risk mgmt	Integrate units of software into sub-systems Develop Sub-system Verification Procedures	Interfaces are not compatible Propagating defects to a higher level	Integrate units of software into sub-systems Application software for Oracle into the server Integrate Apache application with internet server
Sub-system verification	Defined by the SEMP Verification Master Plan and Verification Procedures	Technical review – verification readiness review Config mgmt Risk mgmt	Verification of sub-systems for functionality Make ready for the next level of integration Update user documentation Complete sub-system functionality	Interfaces are not compatible Sub-system functions not complete Not meeting performance Propagating defects to a higher level	Verification of sub-systems for functionality Verify that the database management system is functional and that the data tables are populated and can be accessed within the performance requirements The Apache application is functional and accessibility of the server to the internet is functional
Sub-system integration	Defined by the SEMP Integration Plan	Technical review Verification readiness review Config mgmt Risk mgmt	Integrate sub-systems together into the final system configuration Update user documentation Update Operations & Maintenance Plans Initial deployment and transition into Operations Plan update System Verification Procedures	Operating agency staff not ready for operations & maintenance Final configuration is not appropriate Documentation for users is not ready Propagating defects to a higher level	Integrate sub-systems into the final systems configuration Integrate the Apache server and internet communications with the Java applet exercise system, end-to-end check for memory leaks, fault conditions, browser compatibility, security, sign filtering [be able to access only the signs required for agency B]. Check Oracle database for agency profiles and login authority.
System verification	Defined by the SEMP Verification Plan	Stakeholder involvement Technical reviews Verification readiness reviews Config/ Risk mgmt	Verify that the system meets all requirements All documentation is updated and ready for users Complete system functionality	System not fully implemented System does not meet requirements System does not meet the needs of the user	All documentation is updated and ready for users All user training, maintenance, user manuals are completed
Deployment	Defined by the SEMP Deployment Plan	Technical review Deployment readiness review	Determine if system is ready to be deployed Evaluation period Training updates	System is not ready to be deployed Latent defects that did not surface during verification	Determine if system is ready to be deployed Staff is trained, Internet access is available, VPN is configured, agency profiles are fully populated, access to the correct signs has been verified, remote users can read the 6 CMS status and post appropriate messages
Validation	Defined by the SEMP Validation	Stakeholder involvement Risk mgmt Config mgmt	Pre-system studies vs. post-system evaluation, effects on event management	Not meeting the expectations of the stakeholders Not meeting the needs as specified in Concept of Operations	Pre-system studies vs. post-system evaluation, effects on event management In the pre-system evaluation it took 7 staff members 2 hours to set up the event management process. The effects on the event - it took 30 minutes from the end of the event to move traffic out of the area. It took 45 minutes prior to the event to park the event attendees. In the post-system evaluation it took 1 staff member 10 minutes to set up the event management process. The effectiveness of dynamically changing the signs shows when it took only 15 minutes to clear the event and 30 minutes to park the event attendees.
Operations & maintenance	Defined by the Operations & Maintenance Plan	Stakeholder involvement Config mgmt	On-going maintenance costs On-call services contracts with COTS vendors IT support for VPN and internet access	Lack of maintenance Lack of vendor support	On-call services contracts with COTS vendors Updates to Oracle, notice of obsolescence, design changes
Changes & upgrades	Defined by the new project SEMP	Stakeholder involvement Config mgmt	Other agencies want access to signs in their jurisdictions	Need for new development Locked into a specific development team	Other agencies want access to signs in their jurisdictions Since the sharing control sub-system was designed for flexibility, it was found that no new development was needed, that adding new profiles and VPNs for the participating agencies would allow the system to accommodate new users without further design Since the new functionality was well documented, the agency has a choice of future development teams and additional functionality, if needed. Or, they can do it themselves.

Previous Document section | Next Document section

Return to top

Page last modified on September 20, 2016