Designing the Archive for SHRP 2 Reliability and Reliability-Related Data (2014)

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.

8C h a p t e r 2 2.1 General approach The Archive system has to address both long-term and short- term user needs. A system that meets short-term customer requirements but cannot adapt to future and long-term needs is doomed to a short life span. However, it is almost impossible to grasp all short-term and long-term user as well as system needs at the planning stage. The user requirements need to be identified gradually—through keeping the users in the loop— while the system is being developed incrementally. The development of system capabilities is an iterative, two- sided process. On one side, customers and users need to define the system’s capabilities that will provide value. On the other side, the project team has to incrementally develop the system and constantly ask questions about whether the system func- tionalities being developed are worth the value they deliver. To meet the characteristics critical to the success of the L13A project, the project team selected the agile software devel- opment approach to develop the Archive. The agile software development approach is an iterative, feature-based delivery process and is founded on continuous communication with users. This method is based on incremental development, in which needs and requirements evolve through collaboration between the developers and users/stakeholders. Agile develop- ment is a time-boxed approach that requires adaptive planning and provides evolutionary development and delivery. The plan was to develop the Archive system and transfer the final product to SHRP 2 through six phases. Figure 2.1 shows the proposed approach. The proposed phases were as follows. 2.1.1 Phase 1—Requirement Definition The focus of this phase was on understanding the system and user basic requirements. The collection of the requirements was conducted through two parallel tracks. On the first track, the project team performed literature studies on various archive systems and technologies to become familiar with the latest progress and findings in the data archiving and content management domain. On the second track, the team developed a stack of preliminary requirements in the form of user stories that were discussed and verified in a workshop consisting of a group of technical experts. The revised set of requirements was the basis for developing a prototype of the Archive. 2.1.2 Phase 2—Prototyping and Acceptance Testing The team developed an archive prototype in Phase 2 based on the user stories defined in Phase 1. This phase was crucial since it was an opportunity to appraise various approaches and to solicit potential users’ feedback on effectiveness and usefulness of archive features. The team closely collaborated with a group of subject matter experts, carefully put together by the project team, and the Technical Expert Task Group (TETG) to answer key questions regarding the operations and maintenance of the system. This collaborative effort was extremely helpful for the development team to make key decisions regarding the system’s features and specifications. At the end of Phase 2, the completed prototype was demonstrated to stakeholders (Decision Gate 1) to gain their approval for starting Phase 3 (Archive Development). 2.1.3 Phase 3—Archive Development Phase 3 focused on delivering an operating archive system and finalizing user interface and back-end coding. The system com- ponents were tested according to a test plan developed by the team to fix the bugs and errors that could not be identified dur- ing the prototyping phase. The team started loading the system with an initial set of SHRP 2 artifacts. At the end of this phase the project team held a user acceptance workshop to obtain TETG members’ approval to release the system for operation (Decision Gate 2). 2.1.4 Phase 4—Outreach and Training The objectives of this phase were to perform outreach and training activities after release of the Archive and to promote Approach

9 the site through social media, academic conferences, or any transportation-related venue that discusses highway systems management and operations. Because of the significant workload associated with the artifact upload task, this phase was scaled down to save budget for the upload activities. 2.1.5 Phase 5—Operation and User Engagement Phase 5 will deliver a fully functional data archive that is loaded with all SHRP 2 artifacts. This phase has not been started at the time of writing this report. 2.1.6 Phase 6—Transfer of Operations During this phase the ownership of the Archive system will be transferred to SHRP 2. Extensive documentation on all the systems and frameworks will be provided and, ultimately, the project will be closed. The Archive system was created through a collaborative effort between Iteris, Inc., and Kittelson & Associates, Inc. The Kittelson & Associates team assisted Iteris with the litera- ture review, outreach, and data upload tasks. 2.2 Software Development Methodology The L13A team used a hybrid method, which combined the prototyping and agile methodologies, to develop and deploy the Archive. The general development process was based on prototyping methodology in which the inception phase started with a prototype that was demonstrated to a group of users and subject matter experts to identify whether the design and features would address users’ needs. At the soft- ware coding and system design level, the development was based on the agile approach. 2.2.1 Agile Approach The team used agile schema to develop the software. The agile approach (see Figure 2.2) starts with creating a prod- uct backlog, a prioritized list of features that need to be developed for the product. The product backlog is a stack of stories that can be generated by the project team and other stakeholders. The project manager prioritizes the back- log and—with the help of the development team—breaks each story into smaller tasks. From that point on, each feature/story is coded iteratively—with the user/client in the loop—until it meets the desired outcomes. The agile process is iterative and relies on continuous feed- back from users/stakeholders during the course of develop- ment. To meet that requirement, the team met with a group of subject matter experts (SMEs) and users in various phases of the system development (i.e., requirement elicitation, pro- totype development, user acceptance) to make sure the final product met the needs of future users (see Figure 2.2). It should be noted that system and user requirements were not identified at the inception of the project, which made the communication task a crucial element to the success of the project. For more information on the user engagement strat- egy, see Section 2.3. Figure 2.1. Project general approach.

10 2.3 User engagement As part of Phase 1, Phase 2, and Phase 3, the L13A project team established a collaborative effort in which the SME group—consisting of the TETG members, future users, and experts—worked together to help the software design team identify practical user requirements and design a system that can be operational for more than 25 years. This section sets out the general strategy for establishing the group and engag- ing members of the L13A SME group. 2.3.1 Objective of the L13A Subject Matter Experts Group To develop an archive system for the SHRP 2 Reliability pro- gram, the L13A project team put together a core group of users and SMEs to get involved in identifying the system requirements and designing the Archive system. The goal was to make the Archive system more useful to the targeted audi- ence. The project team assembled these stakeholders into a group, with a clear mission to help guide the development of the project. Through effective stakeholder engagement, the team expected to • Understand user and system needs; • Use outside expertise and advice on system design and architecture; • Obtain user feedback on the system requirements and interface; and • Create awareness regarding the L13A project and the SHRP 2 Reliability Archive. 2.3.2 Mode of Engagement The team leveraged two types of engagement tools to interact with the stakeholders: (1) facilitated workshop; and (2) stake- holder website. 2.3.2.1 Facilitated Workshop The project team used the facilitated workshop approach to involve stakeholders. The Joint Application Design (JAD) method was used to elicit user and system requirements. JAD-like workshops provide various benefits for the users and developers. Some of the benefits are • Reducing risk of scope creep; • Accelerating delivery of product; • Providing savings in time and effort; and • Creating greater chance of consensus. The group provided feedback and insight for the following deliverables (see Figure 2.3): • User/system requirements and system design; • Acceptance testing criteria; Figure 2.2. Agile approach. • User and system requirements • System design Workshop 1 SME June 2012 • Acceptance Criteria Definition Workshop 2 SME June 2012 • Prototype Demonstration Workshop 3 SME January 2013 • Final System Demonstration and Acceptance Testing Workshop 4 T-ETG Only February 2014 Figure 2.3. Stakeholder engagement: Dates and objectives.

11 • Archive system design review; • Prototype; and • Final system acceptance test. 2.3.2.2 Stakeholder Website The stakeholder website is the SHRP 2 L13A project-restricted website that is available only to the SHRP 2 clients, the contrac- tor team, and the TETG. The website can be accessed by those with proper permissions at http://sites.kittelson.com/SHRP2_ ReliabilityDataArchive. Among other uses, the stakeholder website has been used to provide a link to a continuously updated spreadsheet with project progress. Figure 2.4 presents the home page of the stakeholder website for authorized users. 2.3.3 Group Structure As mentioned before, the major objective of engaging the L13A SME group was to capture stakeholders’ feedback on the Archive system design and features. The set of partici- pants consisted of a representative sample of stakeholders and users that could help the project team develop a user-centric system successfully. The L13A SME group (see Figure 2.5) comprised • The TETG group (see Table 2.1); • An external advisory panel made up of 44 Senior researchers from major academic transportation centers, Figure 2.4. Stakeholder website.

12 L13A SME Group T-ETG External Advisory Panel University researchers Practitioners Private sector researchers Iteris/Kittelson Team Figure 2.5. L13A subject matter expert group structure. Table 2.1. Technical Expert Task Group Members Name Organization Richard T. Goeltz Oak Ridge National Laboratory Michael L. Pack Center for Advanced Transportation Technology (CATT) Lab, University of Maryland William H. Schneider The University of Akron Dustin Sell Microsoft Theodore J. Trepanier INRIX Kristin A. Tufte Portland State University Marcus Ramsay Wigan Oxford Systematics Mike Bousliman Montana Department of Transportation Table 2.2. External Advisory Panel Members Name Organization Brian Hoeft Las Vegas Regional Transportation Commission of Southern Nevada’s (RTC) Freeway & Arterial System of Transportation (FAST) Dale Thompson Federal Highway Administration (FHWA) Daniela Bremmer Washington State DOT Gene McHale FHWA Heng Wei University of Cincinnati James Hall University of Illinois John Shaw Wisconsin DOT Ken Courage University of Florida Mark Hallenbeck University of Washington Mei Chen University of Kentucky Nazy Sobhi FHWA Paul Pisano FHWA Saman Moshafi IndraSoft Inc. Steven Beningo FHWA Steven Parker University of Wisconsin Walter During FHWA 44 Practitioners from state and federal departments of trans- portation (DOTs), and 44 Private-sector researchers; and • The Iteris and Kittelson project management team. Members of the external advisory panel are listed in Table 2.2. Various characteristics were considered to assemble the group. Some of these characteristics are as follows: • Being able to provide expertise in data archive systems, specifically those used for traffic data; • Working with the project from the beginning, and staying engaged throughout the life of the system; • Conducting research in topics related to SHRP 2 Reliability research fields; • Being neutral; and • Being potential users from different areas.