U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000


Skip to content U.S. Department of Transportation/Federal Highway AdministrationU.S. Department of Transportation/Federal Highway Administration

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

3.6.1 Hardware/Software Development and Unit Test

 

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

 

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.

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:

  • perform unit test
  • document the development environment
  • Perform their own developmental configuration management to the level needed to transfer the complete design package to the agency [if contracted for].

Illustrates where the Hardware/Software Development occurs in the Vee Development Model. The Hardware/Software Development occurs in the Software Coding Hardware Fabrication section.

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?

  • Participate in the technical reviews
  • Participate in risk identification and assessment
  • Participate in any project coordination meeting
  • Manage the contracting process for COTS commercial-off-the-shelf products and applications

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:

  • During the technical reviews, a clear link must be made between the developing product and the requirement it is intended to meet
  • During the technical reviews, the development team must show how the developing product will meet the required performance for functionality
  • Documentation of the developed products is completed and synchronized with the detailed design documentation. Examples are code comments and artwork notes

On the project management side:

The progress in the development of hardware and software should match the planned development progress.

  • This can be milestone-based for hardware development projects [e.g., milestones for printed circuit boards completion of layout, artwork, fabrication, and checkout].
  • For software, this is more difficult and ambiguous. Completion of software modules can be based on estimated lines of code [LOC] developed, compiled, and checked out as a way to measure software progress. Another estimating method is called function point analysis [FPA]. In this approach, small program functions such as database accesses, input/output calls, and the number of memory accesses are individually estimated. These estimates also include other factors, such as the history of the development team's productivity and the amount of software reuse
  • Risks, monitoring, and corrective actions should be performed. At least once a week project risks should be assessed per the risk management plan

Checklist: Are all the bases covered?

check Is the technical review and coordination meeting schedule established and documented?
check Has the development team established a schedule and method for measuring software and hardware progress?
check Have the significant risks been identified and is a schedule in place to monitor these risks?
check Does the development team have documented process for developing hardware, software, database, and communications?

Are there any other recommendations that can help?

Recommendation.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.

  • Function points
  • Number of classes and objects
  • Source lines of code

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:

Graph shows the software effort estimates are more accurate as the project lifecycle progresses.

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.

Tip.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.

Checklist  

 

Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000