National Academies Press: OpenBook

Integrated Delivery of SHRP 2 Renewal Research Projects (2014)

Chapter: APPENDIX B: Integration Tool Development Plan

« Previous: APPENDIX A: Renewal Project Expanded Summaries
Page 218
Suggested Citation:"APPENDIX B: Integration Tool Development Plan." National Academies of Sciences, Engineering, and Medicine. 2014. Integrated Delivery of SHRP 2 Renewal Research Projects. Washington, DC: The National Academies Press. doi: 10.17226/22249.
×
Page 218
Page 219
Suggested Citation:"APPENDIX B: Integration Tool Development Plan." National Academies of Sciences, Engineering, and Medicine. 2014. Integrated Delivery of SHRP 2 Renewal Research Projects. Washington, DC: The National Academies Press. doi: 10.17226/22249.
×
Page 219
Page 220
Suggested Citation:"APPENDIX B: Integration Tool Development Plan." National Academies of Sciences, Engineering, and Medicine. 2014. Integrated Delivery of SHRP 2 Renewal Research Projects. Washington, DC: The National Academies Press. doi: 10.17226/22249.
×
Page 220
Page 221
Suggested Citation:"APPENDIX B: Integration Tool Development Plan." National Academies of Sciences, Engineering, and Medicine. 2014. Integrated Delivery of SHRP 2 Renewal Research Projects. Washington, DC: The National Academies Press. doi: 10.17226/22249.
×
Page 221

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

B-1 APPENDIX B Integration Tool Development Plan Introduction The development of the Project Builder Application (PBA), the integration tool discussed in Chapter 4, needs to follow a well-designed plan in order to implement the framework and deliver a successful product. Since the framework calls for the tool to run as a web-based application, the development approach should follow established methods for designing and building robust software tools. This section outlines a plan for how the actual tool could be developed in collaboration with highway agencies and other stakeholders. The development scenario could involve an agency developing the software internally or working with an outside software developer. In addition, a software developer could work with a consortium of agencies, for example if multiple agencies wanted to share the development costs. Software Development Process The existing PBA framework is effectively ready for implementation using standard software development processes. Some of the key steps included in this process are  Validating requirements  Specification  Architecture and design  Implementation  Software testing  Deployment  Maintenance The steps of the development process are sequential in nature, in the sense that each activity builds on the work of the previous step. However, there is likely to be some overlap in activities during the transition from one step to the next. Validating Requirements The step of validating requirements involves determining the comprehensive list of requirements for the software. These will include user requirements (agency needs for the software to address), functional requirements (methods for the software to collect input and interact with users), and technical requirements (capabilities for storing, retrieving, and computing information). The completed list of requirements will drive the design parameters of the software system. In traditional software development, the initial phase would more likely be described as requirements gathering, since it is assumed that little effort has previously gone into identifying the requirements for the software. Development of the PBA can build on the existing framework developed in Phase I and outlined in Chapter 4, which has already identified and incorporated

B-2 many of these requirements. In this context, the first step of the development process works a bit differently. The PBA developer can appropriately work from the existing requirements rather than reinventing the wheel. However, the requirements should be reviewed by the agencies supporting the development before further steps are undertaken. This allows stakeholders to validate that the requirements defined are sufficiently comprehensive and still applicable to their needs. To the extent that additions or modifications are necessary, the requirements can be adjusted accordingly. Specification The specification process involves creating a document that describes the requested behavior of the software. It will outline the core functionality of the software, list required features, and provide a high-level overview of the anticipated software architecture. This document should be agreed upon by the PBA developer and the agency or consortium. It will serve as the reference point when decisions about software design need to be made during subsequent steps. Architecture and Design In order to create the architecture and design of the system, the developer will need to plan a software solution that meets the criteria described in the specification. This includes defining the structure of the product and the underlying technical design of the system. Related activities include planning the design of interfaces, which should incorporate user experience design concepts to ensure the usability of the resulting tool. Some key results of the architecture and design step will involve committing to particular options and configurations, such as deciding which programming languages to use, or selecting the software solution stack on which to build the application. It should also include analysis and evaluation of how the design will satisfy the requirements as originally defined. The architecture will need to be thoroughly documented in order to support potential future development and expansion of the software. Implementation The implementation step refers to the activity of programming the software tool based on the prescribed architecture and design. It may include selecting appropriate libraries and toolkits for integration into the program, in addition to creating the actual source code of the software. Initial debugging will be performed to ensure that the software is functional and contains the appropriate features. Verification and documentation activities should be included to track that the software fully implements specification requirements and to document the software codebase. Software Testing Software testing is the process of comprehensively checking that the software program behaves as intended, including all components and interfaces along with system performance. This step employs a combination of white-box testing (applying test cases to evaluate the internal functioning of individual units of code) and black-box testing (verifying the external

B-3 functionality of the overall program based on possible inputs and outputs). As part of the testing phase, a trial group of agency end users should be included to verify that the software meets stakeholder needs and collect feedback. As errors and other defects are identified during the testing process, it will need to be accompanied by software modifications to remedy these problems. Testing and debugging activity continues in an iterative fashion until the program is ready for deployment. Deployment Deployment is the step in which the software is released for general use, at which point the agency or consortium can make it available to internal users, or to the wider public as appropriate. It involves deploying the complete software system for use, either on agency servers or in a hosted environment. Since the PBA tool framework is conceptualized as a secure web- based application, it has the flexibility to accommodate a full range of deployment options; it can be delivered to any user with Internet access, while also allowing the possibility of restricting access to the application, or certain parts of it, based on security principles and defined user roles. Maintenance Ongoing maintenance is required to keep the software fully operational. This includes maintenance of both the software program itself along with the deployment environment. The level of effort and responsibility for various maintenance activities should be agreed between the PBA developer and the agency or consortium. In addition to maintaining operations and correcting any new defects, the maintenance step may encompass further modifications after the software has been released. This could include feature updates, performance improvements, or changes to adapt the product to a modified environment. For example, this phase might involve ongoing development to make the PBA tool available on mobile devices, as discussed in Chapter 4. Development Timeline The PBA developer and the agency or consortium will want to determine a suitable time frame in which to complete the development process. The length of the process will depend on the resources committed to the project, as well as the number and complexity of features the agency or consortium elects to include. The timing of the individual steps in the process should be included as part of the plan (see Figure B.1 for an example).

B-4 Figure B.1. Illustration of a representative work plan timeline for software tool development. J F M A M J J A S O N D J F M A M J 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Overall Software Development Timeframe Software Requirements Validation Software Specification Software Architecture and Design Software Implementation Software Testing Software Deployment Software Maintenance Project Work Task 2014 2015 Month

Integrated Delivery of SHRP 2 Renewal Research Projects Get This Book
×
 Integrated Delivery of SHRP 2 Renewal Research Projects
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s second Strategic Highway Research Program (SHRP 2) Renewal Project R31 has released a prepublication, non-edited version of a report titled Integrated Delivery of SHRP 2 Renewal Research Projects. This report documented the research performed under SHRP 2 Project R31, which originally had a goal to develop a tool to promote and support systematic and integrated application of the products developed in the Renewal research program. The development of the tool was not pursued, but this report details a tool development plan and visualized model of the tool for developing the tool in the future.

READ FREE ONLINE

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!