| Related: |  |
|
OBJECTIVES |
· Develop and/or purchase hardware and software that meet the design specifications with minimum defects. Identify any exceptions to the requirements or design specifications that are required. · 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 |
|
|
INPUT Sources of Information |
· Component Level Detailed Design is the “build-to” documentation. The coding and fabrication team develop their products based on this documentation. · Commercial 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.
|
|
PROCESS Key Activities |
· Plan software/hardware development · Establish development environment · Develop detailed design for each component · Develop custom hardware/software · Perform unit/device testing · Develop support products (manuals, training, on-line help) |
|
OUTPUT Process Results |
· Developed hardware and software · Support products · Unit Verification Procedures |
In the Implementation step, hardware and software solutions are created for the components identified in the high-level design. Part of the solution may require custom development of hardware or software, and part of the solution may be implemented with off-the-shelf items, modified as needed to meet the design specifications. The components are tested and delivered ready for integration and installation.
Having invested the effort in developing a clear set of requirements and a good high-level design, the systems engineering process now provides technical oversight as an implementation team of hardware and software specialists create the detailed component-level design, fabricate the hardware, and write the software programs. This is a highly iterative process, particularly for software, where key features may be incrementally designed, built, tested, and incorporated into the baseline over time. Progress is monitored through a planned series of walkthroughs, inspections, and reviews.
Although the systems engineering approach does not specify the mechanics of hardware and software development (this is left to the implementation team), the software/hardware development effort is obviously critical to project success. This is the time to build quality into the hardware/software and minimize defects. A common refrain in the software industry is that you can’t test quality into the software, you must build in quality from the beginning. The systems engineering activities that are suggested in this section are intended to ensure that the implementation team builds quality into their products.
In practice, most of the hardware that is
used for ITS projects is commercially available. Software development is more
prevalent, but there are many ITS projects that include little or no software
development. ITS projects that do not include custom hardware or software
development acquire the necessary off the shelf hardware and software
components at this step and configure and customize the components for the
particular application. Good performance-based specifications are developed to
support the acquisition, the system components are acquired, and bench testing
is performed on the received components to verify that they meet their specifications.
The detailed modeling and design development, hardware/software development,
and unit testing described in this section are not required.
Although it isn’t included in every ITS project, at least some custom software development is fairly common for ITS projects and custom software development has proven to be a relatively risky endeavor. This is why software development receives more attention than hardware development in this section. It is beyond the scope of this document to discuss specific software development techniques, but there are several clear factors that contribute to software development success:
No matter how
clear and unambiguous the requirements appear, it is almost certain that the
software customer and the software implementation team will interpret some of
the requirements differently. Requirements walkthroughs in the previous steps
help to mitigate this risk, but ultimately, the customer/stakeholders will have
to monitor the software as it is being developed to ensure that the development
is proceeding in the right direction. Also remember and try to compensate for
the natural tendency of the software developer to interpret the specification
narrowly and the customer to interpret it more broadly. Expect and plan for
course corrections and requirements changes along the way, at least until we
discover the way to build the “perfect specification”. Ensure that the contract
is flexible enough to have a couple of reviews but also to allow some visits or
informal reviews with the developers to see how they are doing.
Perhaps the best way
to reduce software development risk is to proceed in small steps and build
incremental software releases in short time periods. Software cycle times that
used to be measured in years are now measured in months or even weeks between
incremental software releases. Incremental, iterative development with frequent
coordination and feedback is the best way to keep the software development on
track, particularly for projects where the requirements are not well understood
at the outset.
Rapid prototyping
should be used to help the user and developer visualize the user interface
before significant resources are invested in software development. This is one
area in particular where you can expect multiple iterations as the developers
incrementally create and refine the user interface design based on user
feedback. Prototyping is one of the best ways to design software that will be
highly satisfactory to users, rather than software that merely meets the requirements.
Rapid prototyping must be planned for and bounded like any other task.
Hardware or Software doesn’t satisfy design specs: The risk, which is primarily technical, in the implementation of the hardware and/or software is that they don’t satisfy the design specifications allocated to them. The way this risk is managed is by testing the hardware components and software modules against the specifications allocated to the hardware components and/or software modules.
This step includes activities that the hardware and software specialists lead, beginning with the detailed design of each system component and ending with testing of each completed component. Systems engineering plays a supporting role in each of these steps, providing technical oversight on an on-going basis to identify minor issues early, before they grow into large problems. Some of the activities below will be performed only if there is new hardware or software development. Each of the activity descriptions is followed by a discussion of the technical review and monitoring of that activity.
Plan software/hardware development
This activity will be relevant if considerable hardware or software development is required. The implementation team documents their development process, best practices, and conventions that will be used. The plan should address development methods, documentation requirements, delivery stages, configuration control procedures, and technical tracking and control processes for the implementation effort, including reviews. This is one of the key documents that should be reviewed by the customer and the broader project team.
The implementation plan should be reviewed and
approved before hardware/software development begins. Well qualified
implementation teams will already have proven processes in place that can be
tailored for the specific project, so this shouldn’t be viewed as a burdensome
activity. The intent is not to mandate a particular implementation process, but
to ensure the implementation team has an established process that they will
follow. Even teams that use “lightweight” processes such as agile software
development or extreme programming should have documented processes.
Lightweight, flexible processes can be very effective, but no documented
process is definitely a red flag.
Establish development environment
This activity is applicable when new development, particularly software development is required. The development environment is assembled and integrated, including design and development tools, source control tools, third party application libraries, test simulators, etc. Every tool that is used should be documented specifically enough so that the development environment can be replicated if necessary.
Although it is sometimes overlooked, the
development environment is just as critical to future software maintenance as
the actual detailed design documentation and source code. Every tool that is
used should be documented, including version information and complete
documentation of any customization or extensions. If this is a custom
development and you have paid for the tools, include the development
environment as a project deliverable.
A peer review or inspection can be used to verify that the development environment is adequate and accurately documented. Once established, the development environment should be placed under configuration control so changes to the environment are tracked. Seemingly minor changes like application library upgrades or operating system service pack upgrades can cause problems later if the changes are not controlled and tracked.
Develop detailed hardware and software design specifications
Detailed “build to” design specifications are created for each hardware and software component to be developed. This step applies when there is significant hardware or software development as part of the project. A simple user interface prototype is developed as a quick way to help users visualize the software and several iterations are created based on user feedback. Any necessary requirements and high-level design changes are identified, evaluated, and incorporated as appropriate.
The detailed design of each component should be reviewed to verify that it meets the allocated requirements and is fit for the intended purpose. Periodic or as-needed reviews can be held to monitor progress and resolve any design issues. For larger projects, coordination meetings should be held to ensure concurrent design activities are coordinated to mitigate future integration risks. At the completion of the detailed design step, a broader stakeholder review is held to review and approve the detailed design before the implementation team begins to build the solution.
Procure commercial products
Off-the-shelf (OTS) products are compared and OTS solutions are selected, tailored as necessary, and procured. An alternatives analysis documents the alternatives that were considered and how the superior alternative was selected.
The evaluation of OTS products should be reviewed to verify that the evaluation criteria were properly defined, an appropriate range of products was considered, and the evaluation criteria were applied fairly.
Delay procurement of the OTS products until the products are actually required to support the implementation. Too much lead time can result in OTS that becomes outdated before it can be integrated into the project. Too little lead time could cause procurement delays that impact the project schedule.
Develop software and hardware
The software is written and the hardware is built based on the detailed design. On most projects, there is an easy transition from detailed design to software/hardware construction because the same person that does the detailed design for a specific part of the project also writes the software for that part. The current state of the practice is to develop the software incrementally and release the software in stages. The initial releases implement a few core features and subsequent releases add more features until all requirements are satisfied. This incremental approach enables early and on-going feedback between the customer and the implementation team. If this approach is used, then a staged delivery plan should define the order in which the software will be developed and the staged release process.
Releases will be developed, tested, and made available to selected users for feedback. Providing feedback on interim releases is only part of the technical oversight that should be performed. Code inspections and code walkthroughs should also be used to check the software quality – inspections and walkthroughs are the only way to check that the software is well structured, well documented, and consistently follows the coding standards and conventions identified in the implementation plan. Also verify that source control procedures and tools are in place to manage the evolving software and hardware components until they are delivered. Independent reviewers can help verify software quality on the customer’s behalf if the customer agency does not have the right expertise.
Most project managers who have managed
software development efforts are familiar with the “90% complete” syndrome in
which software developers quickly reach “90% complete” status, but then the development
effort languishes as the final 10% takes much more work than anticipated.
Project tracking should be based on discrete measurable milestones. To minimize
overly optimistic reporting of software completion status, credit for completed
software should not be taken until the piece of code has been successfully
tested and integrated into the next release.
Develop Supporting Products
Enabling products such as training materials, user manuals and on-line help, installation and conversion software, and maintenance manuals are also developed. It is natural to focus on the hardware and software in the “end product”, but you also need to develop and account for all the ancillary products that are needed in a working system.
Like the end-product hardware and software components, the supporting products can also be developed in stages and released incrementally to encourage early customer feedback.
Perform Unit/Device Testing
The software and hardware components are thoroughly tested to identify as many defects as possible. The first line of defense is the software developer, who should step through and test every line of code, including all exception and error paths. As the software/hardware is developed, a series of test cases are developed that will exercise the hardware/software component; these test cases are documented in a unit verification plan. After the software is complete and thoroughly debugged by the developer, the test cases are used to test the hardware/software and the test results are documented. Identified defects are analyzed and corrected and testing is repeated until all known defects are either fixed or otherwise resolved. Defect correction may be relatively simple or may include redesign of sections of code that are determined to be error-prone.
While the developer will conduct their own tests
to identify and fix as many defects as possible, experience shows that the test
cases and formal tests should be conducted by an independent party, either
within the implementation team or an independent party from another
organization. The reason for this independence is obvious if you look at the
objectives of the software developer and the software tester. The primary
objective for the tester is to break the software while the primary objective
of the developer is the exact opposite – to make the software work. Few
individuals can effectively wear both of these hats. The degree of independence
between the developer and the tester and the level of formality in unit testing
should be commensurate with the criticality of the software and the size of the
project.
The unit verification plan should be reviewed to verify that it will thoroughly test the component. Track testing as it progresses to verify that defects are being identified and addressed properly. A testing process that identifies few defects could indicate excellent software or an incomplete or faulty testing process. Use scheduled technical reviews to understand the real project status. Various techniques can be used to estimate the number and severity of remaining defects and make an educated decision about when the software will be ready for release.
This step results in hardware and software components that are tested and ready for integration and verification. Artifacts of the development process, including the implementation plans, development environment documentation, component-level detailed design, unit verification plans and procedures and verification results, change control records, and supporting products and documentation are also delivered. A record of the technical reviews that were performed should also be included in the project documentation.
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.
The FHWA Regulation does not specifically mention general hardware/software practices to be followed. ISO/IEEE 12207 Software development life cycle processes.
Table 8 illustrates that the test results of implementation should support the detailed design specifications for the project.
Table 8: Implementation Process traceability
|
Traceable Artifacts |
Backward Traceability To: |
Forward Traceability To: |
|
|---|---|---|---|
|
Implementation Test Results |
High Level and Detail Design Specifications |
N/A |
|
The following checklist can help answer the question “Are all the bases covered?” once the activities above have been planned or performed. The checklist is not sufficient by itself.
R Is the technical review and coordination meeting schedule established and documented?
R Has the development team established a schedule and method for measuring software and hardware progress?
R Have the significant risks been identified and is a schedule in place to monitor these risks?
R Does the development team have documented process for developing hardware, software, database, and communications?
| Related: | |
