U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
California Division
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
OBJECTIVE This step in the process develops [builds or constructs] the hardware and software for the system that matches the requirements and component level detailed design documentation. This step is primarily the responsibility of the development team, who fabricates the hardware and writes the software programs. The systems engineering activities includes the support and review of the development effort on behalf of the system's owner. If multiple developments for the same system are underway, the systems engineering activity includes the monitoring and coordination of these developments to ensure these projects integrate together with a minimum of effort. |
DESCRIPTION: The systems engineering activities include the monitoring and coordination of the hardware & software development activities. The implementation is primarily the responsibility of the implementation team, whether it is in-house or by a contracted development firm. Monitoring is accomplished by a preplanned series of reviews coordinated with the development team. This is performed by the systems engineering staff of the agency or a contracted system manager. It is essential to review the technical progress and provide technical guidance on the implementation of requirements. These reviews provide early warning that requirements are deficient, or they are not being met by the implementation. In such cases deviations or waivers may be needed or the re-evaluation of the requirement may be necessary. Also, these reviews will be needed when coordinating among concurrent developments for the same project, depending on the development strategy. |
CONTEXT OF PROCESS
HARDWARE/SOFTWARE DEVELOPMENT PROCESS |
Inputs Component Level Detailed Designis the “build-to” documentation. The coding and fabrication team develop their products based on this documentation. Commercial-off-the-shelf [COTS] products are procured for the project. The intent is to wait until the last possible opportunity to procure technology to get the latest and most cost effective products. System and Sub-system Verification Plans are used to assist the development team to fully understand the design and requirements they are building to. |
Control Project Plan/Systems Engineering Management Plan [SEMP] will have the software/hardware development plan used as a roadmap to carry out the software and hardware development. Configuration Management Plan identifies the needed products from the development and manages changes during this step. Risk management identifies, monitors, and controls hardware/software development risks. |
Enablers: Technical reviews are used for monitoring the project management and technical progress of the development. When multiple concurrent developments are being performed, the technical reviews can be used as coordination meetings to keep projects synchronized with each other. Traceability of implementation elements to the detailed design ensures completeness |
Outputs: Developed hardware and software are the units or products that have been developed for the intended system. These are units of software and hardware that are ready for integration into larger more complex functions of the target system. Support products, such as user training materials, maintenance manuals plus development and other support tools. Unit Verification Procedures are the step-by-step instructions used to verify that the units match the design. |
Process Activities: Support, monitor, and review development During the development phase, technical reviews should be held according to the technical review plan developed by the development team. These reviews assess the progress and technical correctness of the implementation of the design. Develop system product This is where the actual software code is developed and the hardware is fabricated for the system. In addition to these, support products are developed, such as users manuals, training products, and maintenance manuals initially developed. As integration and verification proceeds, these products are updated as needed. Final delivery should follow the delivery of sub-systems and the final system. Coordinate concurrent development activities When multiple developments are being performed concurrently, based on the selected development strategy, these meetings should be coordination meetings between the developments to reduce the risk due to any integration between them. This should include schedule, functional, and interface risks. Procure COTS products COTS products should be procured at this time but only if needed in this phase. If the implementation phase is planned to last several months or years, procure only those items which e needed immediately, and push the procurement of this technology to the last possible minute. When doing so, account for lead times of the procurements. The specific domain discipline e.g., software, hardware, database engineering, is expected to:
|
Where does the Hardware/Software Development take place in the project timeline? |
Is there a policy or standard that talks about Hardware/Software Development?
FHWA Final Rule does not specifically mention general hardware/software practices to be followed. ISO/IEEE 12207 Software development life cycle processes.
Which activities are critical for the system's owner to do?
How do I fit these activities to my project? [Tailoring]
Depending on the budget, staff resources, size, and complexity of the project or program, the number and formality of the reviews should be tailored to fit the project.
Small projects, e.g. signal system upgrades, may require only 1-2 technical reviews and the coordination meetings with communications and/or IT services only.
Large complex projects may require bi-weekly or monthly technical reviews [at a minimum], and an equal amount of coordination meetings.
The technical reviews should go in accordance with the planned reviews in the Systems Engineering Management Plan.
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:
The progress in the development of hardware and software should match the planned development progress.
Checklist: Are all the bases covered?
 |
Is the technical review and coordination meeting schedule established and documented? |
|
Has the development team established a schedule and method for measuring software and hardware progress? |
|
Have the significant risks been identified and is a schedule in place to monitor these risks? |
|
Does the development team have documented process for developing hardware, software, database, and communications? |
Are there any other recommendations that can help?
Use an independent reviewer to assist the system's owner. This independent reviewer should be technically versed and work on behalf of the system's owner. This step involves a lot of technical knowledge in the specific development discipline of software, hardware, communications, and databases. An independent reviewer can help the owner of the system identify risks, completeness of design, and development performance.
It is recommended before starting implementation, the previous steps of the systems engineering process be completed. Make sure that the previous steps have been reviewed and approved by the system's owner and stakeholders. This includes, in particular, that the documentation is complete.
What are the ways to estimate software development efforts?
Keep refining the software development estimates at each step of the process. Be aware of the uncertainty in software estimates. There is a lot of work being done in the software community to estimate how much effort it takes to develop major software programs. Estimating the size of a software program is done by the development team.
Each development team will have its own method of estimating code. The following are examples of methods for estimating the size of software.
The following graph, adapted from Barry W. Boehm's classic Software Engineering Economics textbook, shows the estimation accuracy of software efforts at different steps in the project life cycle:
Figure 3‑12 Software Estimates over the project life cycle
As illustrated, estimates at the concept exploration phase may be off by a factor of four.
Estimating the software effort at the component level detailed design end will be much more accurate than the estimates at the concept exploration. The recommendation is to wait until the system definition is complete [end of phase 2] before trying to estimate the software effort.
The systems engineering mindset is to push the estimation of software to the component level detailed design step of the project timeline.
In estimating software development efforts, two primary methods exist today: source lines of code and Function Point Analysis [FPA]. Counting the lines of source code is the oldest method. A tool that is often used in this method is the COCOMO model developed by Barry W. Boehm in the late 1970's. Another method is Function Point Analysis. It dates back to the late 1970's but has gained popularity in recent years. Simply put, FPA estimates the number of each of five common types of program transactions that the software program will carry out. Then, using other factors, such as history of function point production, estimates the software effort. Once the estimates are made, the tasks are laid out per the development plan and then monitored as part of the review process.
 |
![Shows the flow for Phase [3] Task 1, Hardware/Software Development Process. Summaries are described for inputs, constraints, and enablers into the task; activities of the task; and outputs from the task. The flow is described in detail in the accompanying text.](/cadiv/segb/views/document/sections/Section3/29_files/image001.gif)
