 |
  |
Systems Engineering for Intelligent Transportation Systems
|
|
Systems Engineering for Intelligent Transportation Systems
In addition to the process steps identified in the "V", there are several project management and control activities that are essential in order for a project to be successful. The project planning, project monitoring and control, risk management, and configuration management processes shown in Figure 35 all support systems engineering. These activities are discussed briefly in this chapter; a list of additional resources may be found in Chapter 7.
Figure 35: Project Management Activities Cut Across All Steps of the "V"
Project planning lays out the activities, resources, budget, and timeline for the project. This effort, which begins early in the project life cycle, results in the creation of two major plans, the Project Plan (PP) and the Systems Engineering Management Plan (SEMP). Both of these documents should be written in such a way that a newcomer to the project team can understand the type and scope of the project, the responsibilities of the major players, the staffing, the schedule and budget, and the processes that will govern the project. There are typically several additional plans (e.g., Risk Management Plan and Configuration Management Plan) that will either become appendices to the PP or SEMP or will stand on their own, depending on the size and complexity of the project.
The Project Plan (PP) documents how the project will be managed and controlled from a programmatic standpoint. It identifies the detailed work plans for both administrative and technical tasks. For each project task, the PP documents what is to be done, by whom, with what funds, when, how (processes to be used), and dependencies.
When contracting is involved, the PP will either be created by the agency prior to contracting for the project or will become the first output of the effort, created by the contractor immediately after beginning the project.
The Project Plan should include the purpose and overview of the project, task descriptions, resources and budget allocated to each task, deliverables, and project schedule. It should also include a budget plan that estimates annual/monthly costs and identifies where funds will come from, a project organization, as well as roles and responsibilities relative to project execution. If there are any Integrated Product Teams (IPTs) that will be utilized on the project, their mission and membership should be described. The PP should include a list of all documents to be generated, key milestones, and formal meetings. Process descriptions or flowcharts that will govern how the project is controlled should be appended. It's helpful to create a table that identifies the owner or lead for each process and document as well as those organizations that provide a supporting role. All tools to be used to manage the project should be listed, along with key project performance measures that will be tracked to monitor schedule and budget performance. In general, the PP is the "how to" manual for managing the project's implementation, and as such it should be formally reviewed and approved by all major stakeholders prior to the start of the project.
The Systems Engineering Management Plan (SEMP) is the top-level plan for managing the systems engineering effort to produce a final operational system from initial requirements. Just as the PP defines how the overall project will be executed, the SEMP defines how the engineering portion of the project will be executed and controlled. It describes how the efforts of system designers, test engineers, and other engineering and technical disciplines will be integrated, monitored, and controlled during the complete life cycle. For a small project, the SEMP might be included as part of the PP document, but for any project of greater size or complexity a separate document is recommended.
The information contained within a SEMP can be organized in different ways, but in general it should include an introductory section (including system description, top-level schedule, and relevant documents), technical planning and control, systems engineering processes tailored specifically for the project, and plans for coordinating the efforts of multiple engineering disciplines to accomplish the project tasks. Make sure that the SEMP and the PP are consistent – it's fine to reference the PP in the SEMP and vice versa.
Technical Planning and Control – This section describes how the project will be controlled from a systems engineering point of view. It includes the engineering organization and responsibilities, identification of technical and performance monitoring reviews to be held during the project life cycle, the system test strategy, technical performance measurements to be monitored, the configuration and data management strategy (see Section 5.4 for further details), the risk management strategy (see Section 5.3 for further details), and identification of any critical items that may require special risk management.
In addition, there are a host of other plans that should be created near the beginning of the project life cycle. Depending on the size and complexity of the project, plans may be small and included as part of the SEMP or they may be referenced by the SEMP as standalone documents. Minimally, the SEMP should identify all of the relevant project documents. Plans to be described or referenced in the SEMP include:
Systems Engineering Processes – This section of the SEMP describes the processes to be used for execution of the various systems engineering steps covered in Chapter 4, as tailored for your project. This is a good place to include a discussion of the project's approach to meeting the requirements of FHWA Rule 940.11/FTA Policy Section VI.
This section should include a definition of all high-risk areas, including critical technologies that might pose some challenge for your system. The SEMP will include a list of the tools that will be employed during the development (e.g., a requirements traceability tool).
Coordination of Engineering Disciplines – This section describes how the various inputs into the systems engineering effort will be integrated and how appropriate disciplines will be coordinated with that effort. In a complex project, there will be multiple engineering disciplines contributing to the success of the project. For example, for projects that have a user interface, operability/human engineering will provide input during the development cycle to ensure that the design is user-friendly and intuitive. If system reliability is a major issue, specialists should assess the design to make sure that it will meet performance requirements. In the SEMP, the dependencies between these various engineering disciplines and the project life cycle will be documented. This will help the systems engineer to make sure that input is solicited from each engineering discipline at the appropriate time and that the right people are at the various technical reviews.
The plans discussed in the PP and in the SEMP include the steps that will be taken to monitor and control the project from a systems engineering standpoint. Two aspects of this monitoring and control, project tracking and project technical reviews, are discussed next.
The PP and the SEMP define the tasks and schedule for the project and the processes that will be followed to produce the deliverables. Once the project is underway, how can you track progress against the plan? When should you start to worry that the project is veering off track? Is the project on track as long as cost and schedule are meeting the plan?
It's tough to answer
any of these questions without creating some means of measuring progress.
Metrics can help you to track progress and more importantly track problems on
the project. Performance measures, which are formed by combining metrics, may
be used to indicate progress or achievement and may be programmatic or
technical. A few examples of performance measures are shown in Table 18.
Table 18: Example Performance Measures
| Performance Measures | ||
| Technical | Programmatic | |
| Development Progress | System Performance | |
|
# of requirements defined
# of requirements predicted
# of SW modules completed
total # of planned installations
# of field sites installed
Total # of planned installations
# of acceptance tests passed
Total # of acceptance tests
|
Transit vehicle maintenance
database usage
# disk space allocated
# of times traffic signal
equipment reports faults
Total # traffic signal equipment faults
Failure rate of DMS equipment
Predicted failure rate
|
# of tasks performed
# of planned tasks scheduled
Cost as of today
Budget as of today
|
Programmatic performance measures are primarily concerned with spending and schedule progress and are documented in the PP. Earned value measures are one of the best ways to accurately measure cost and schedule performance. Earned value provides a measurement of work accomplishment compared with resource expenditure (cost or effort). A detailed discussion of this technique can be found in many project management resources, including the Project Management Book of Knowledge (PMBOK) and the NHI Project Management Course. (Consult Chapter 7 for resources.)
Technical performance measures are documented in the SEMP and fall into two general categories:
Metrics and measures should be defined early in the project and tracked either periodically (e.g., monthly) or at defined milestones. Monitoring the performance measures on a regular basis will help you to notice trends and to predict and head off potential issues before they grow into large problems. By using programmatic measures, you will be better able to adjust the task schedule and move resources as needed to minimize the impact to other tasks. By monitoring technical measures, you will notice trends that will help point to inefficiencies in the system design. Both programmatic and technical measures are also useful in identifying points in your processes that could be improved.
Project reviews provide a structured and organized approach to reviewing project products to determine if they are fit for their intended use. These reviews are a primary method of communicating progress, monitoring risk, and transferring products and knowledge between project team members. The reviews often occur at the completion of a "V" process step and represent decision points that must be passed successfully before moving to the next step in the process.
Note that there are programmatic project reviews that are focused on budget, schedule, resourcing, and other program control topics. Technical reviews center more on the project development aspects of the program, and these are the focus of the following discussion.
Project reviews should be done in partnership with the system developer and should not be treated as an audit to discover contract noncompliance. The reviews should be collaborative with no fingerpointing. Discuss ahead of time what should be done if an impasse is reached during a project review. "What if" planning in a risk management plan or a review-specific plan before an impasse is reached can help to keep the project moving forward productively.
Sometimes
it seems that the focus at major project reviews is on impressive presentations
that put the best face on the project. Remember that the review is not
convened to assess the quality of the presentations. The real intent is to
evaluate objectively the output of the current step and to assess honestly
whether the team is ready to progress to the next step.
Make sure that
the right people are in the room when you hold the project review. For
example, if requirements are being reviewed, the systems engineers, design
engineers, test engineers, O&M team, and other relevant parties should all
carefully review the material and provide constructive feedback. A list
containing the names of key reviewers should be made prior to the review.
Unless these reviewers provide written comments in advance or are present at
the project review meeting, the item under review should not be signed off as
complete.
You should
go into a major project review with the perspective that delaying the
transition to the next step can be the best choice depending on project status.
Too often, ITS projects are allowed to progress to the next step even if the
previous step has not been completed. The common sentiment is that the project
should maintain its schedule and catch up technically in the next process step,
but this rarely works. For example, a project that progresses to high-level
design before requirements are baselined is at risk of misunderstandings
concerning what is to be designed, developed, tested, operated, and
maintained.
Every major product (e.g., specifications and test results) created in the life cycle should be reviewed. In Chapter 4, we identified the various decision-point reviews that occur to assess readiness for progressing to the next step in the "V". Each of these reviews could be as simple as two or three team members walking through the product, or it could involve the whole team and, in many cases, the contracting agency.
Some of the formal technical reviews that may be planned for an ITS project include:
In addition to the formal decision-point reviews that are shown in the "V", many less formal reviews may be conducted; these include walkthroughs, interim progress reviews, and other ad hoc reviews that may be scheduled to address a particular risk or development challenge.
Risk management is the identification and control of risks during all phases of the project life cycle. Murphy's Law is alive and well during most projects, so it's essential that you anticipate the risks and put plans in place for addressing them. The goal of risk management is to identify potential problems before they occur, plan for their occurrence, and monitor the system development so that early action can be taken if the risk occurs.
Risk management is composed of the following general steps:
Risk
analysis and prioritizationThe objective of the risk identification step is to identify the key risks to project success at the beginning of the project. This will require that project managers, stakeholders, and possibly outside experts brainstorm about where the risks may lie. They should take a look at all potential risks, from initial development all the way out through operations and maintenance and eventual retirement of the system.
There are many areas of risk that might affect your project:
Risks should be expressed as "If <situation>, then <consequence>" statements. For example: "If an agreement cannot be made with Agency ABC to obtain incident information, then the dispatching software will not be able to take incident information into account when calculating the best route."
During
this first step, it is important to obtain a broad sample of potential risks.
However, try to keep reality in check. You're not trying to capture highly
improbable events but rather those that may well occur and are likely to impact
the project the most from a schedule, cost, or technical standpoint.
It is also
important to recognize the opportunities that go along with the project risks.
There is a risk that you will fall behind an aggressive schedule, but the shorter
schedule may provide some additional benefit or opportunity. It is common to
brainstorm project opportunities along with project risks, since risks are
almost always incurred when attempting to capitalize on some opportunity. As
you identify the risks, consider the aspects of the program that, if performed
a certain way, might lead to potential cost savings, schedule improvements, or
improved quality in the technical approach. The following steps in the risk
management process are equally relevant to opportunity capture.
Once risks have been identified, the next step in the process is to analyze and prioritize them. In order to do this, we need to determine the impact should the risk occur, and the probability of its occurrence.
How severe will the impact be if the risk occurs?
For each risk identified, you should make an assessment of what will be impacted if the risk occurs. Risks typically fall into one or more of the following areas:
Depending on the nature of the project and the nature of the risks, this assessment of severity can be qualitative (e.g., high, medium, or low) or quantitative (e.g., weeks of schedule slippage or amount of cost overrun).
When
determining risk severity, start with the qualitative approach (i.e., high,
medium, low), but create some quantifiable criteria for each level. For example,
a high-severity risk might cause a schedule slippage of more than six months.
Such criteria will give you a way to measure the impact you expect from any
particular risk.
What is the probability that the risk will occur?
For each risk identified, assign a probability that the risk will occur (e.g., high, medium, or low). It's a good idea to define each of these probabilities quantitatively to make sure that everyone is analyzing the risks the same way (e.g., high = greater than 30% probability that the risk will occur).
Once each risk has been analyzed, the next step is to prioritize the risks according to the severity of the impact and the probability of its occurrence, as shown in Table 19. Any risk that falls into the upper left-hand corner group lettered A, B, and D is important. These risks have a higher probability of occurrence and a greater impact. Mitigating these likely risks will give you the best cost, schedule, and/or technical savings. Depending on available resources, try also to consider the risks that fall into cells E, C, and F, in that order.
Table 19: Risk Prioritization Matrix
| Probability of Occurrence | ||||
| High | Medium | Low | ||
| Severity of Impact | High | A | B | C |
| Medium | D | E | F | |
| Low | G | H | I | |
The objective of risk mitigation is to identify and evaluate alternatives for handling the risks identified above. From a project management standpoint, there are several ways to address risks:
A risk mitigation strategy describing the steps to be taken to lessen the severity of the risk and the probability of its occurrence should be created for each risk. The strategy should identify the risk, an assigned owner, and the schedule and budget for implementation of the mitigation steps. The contingency schedule and budget should be allocated up front in order to have the time and funds to address each risk adequately. It's not enough just to create mitigation plans – you should begin to execute them according to the schedule and documented approach. The goal is to reach an acceptable risk mitigation solution between the customer and the contractor so that the project remains technically viable, on schedule, and on budget to the extent possible.
The risk mitigation strategy can take the form of a standalone risk management plan or it can be a section in the SEMP, depending on the size and complexity of the project.
As we
discussed earlier, opportunities for potential cost savings, schedule
improvements, or improved quality should be considered along with risks.
During this step, you should put a plan in place to exploit each opportunity
you've identified and implement the plan.
Risks should be monitored throughout the life cycle to determine whether the mitigation steps are actually lessening the severity or probability of each risk. It's also possible that the nature of the risk has changed (e.g., the due date for delivery of the software code was extended because another project was delayed).
One way to monitor risks is to develop metrics that will give an indication that a risk is occurring. These metrics (e.g., cost versus schedule to identify if cost overruns are beginning to occur) should be easy to track and should provide some signal of a potential problem. Risk status should be reviewed periodically during progress meetings and other reviews.
Configuration
management (CM) can be defined as "A management process for establishing and
maintaining consistency of a product's performance, functional, and physical
attributes with its requirements, design and operational information throughout
its life." (From ANSI/EIA 649-1998)
Establishing the system baseline, or configuration, and managing change to that baseline, are key processes for ensuring that system integrity is maintained throughout the life of the system. Consider it this way – if you had to recreate the system at a certain state in its life cycle or duplicate the deployed system in the test lab to check out a fault, would you have all of the configuration data and documentation version information you would need to do so? Following a strict configuration management process will ensure that you do.
The configuration management process consists of five major activities:
This
discussion of configuration management provides just a basic overview of what
is a major discipline within systems engineering. There are resources that
provide more detail and specific tools and techniques for the implementation of
configuration management. These resources may provide additional information
for adapting the information presented here to address specific project needs.
Such resources include:
The processes and procedures to be used to manage the configuration of the system and changes to that system are documented in a Configuration Management (CM) Plan. The CM Plan may be a separate document (if the project is of sufficient size or complexity) or it may be part of another project planning document (e.g., PP or SEMP). The CM Plan is created at the beginning of the project life cycle. Once approved, the CM processes and procedures described in the plan are used throughout the remainder of the life cycle through retirement or replacement of the ITS system.
During the CM planning phase, you should select your CM tool. This tool will capture the configuration definition and will be used to establish and maintain the system baselines (e.g., hardware or software). It could be as modest as a spreadsheet if your project is small or an industry-standard CM tool if the project is more complex.
It is also during this early planning phase that the configuration control board (CCB) is established. The purpose of the CCB is to control the baseline of the system and all changes that are proposed and implemented on it. Its membership and process should be documented in the SEMP or the CM Plan. Membership includes representation from both engineering and program management and from both the contractor and the contracting agency. For small projects, this may be only two or three people. The CCB reviews every change, including its technical and programmatic justification, implementation schedule, potential effects on other parts of the system and project cost/schedule, and the risks involved with deploying the change.
Configuration identification is the selection of the software, hardware, and documentation that will be tracked. These configuration items collectively represent the system baseline and typically include:
Each
configuration item must have a unique identifier, clearly marked on it in some
fashion, so that the item can be identified and tracked. For continuity, many
projects use identifiers that are consistent with the nomenclature used to
identify items in the project contract.
Once the configuration items have been identified, any changes to them must be handled in a controlled fashion. All changes must be clearly described and presented to the CCB to assess the technical, cost, and schedule impacts. Only after the CCB has approved the change should it be implemented and the baseline changed. Once the change has been approved and implemented, it is formally documented, the baseline is updated, and the control number is updated. You should define the format of the control number – a revision number or version number – in the CM Plan.
Your
Traceability Matrix can be a useful tool to help assess the impact of a
proposed change since user needs are traced to requirements, which in turn are
traced to system components and verification tests.
At any time during the system life cycle, you should always know the configuration of every item. From the time that a change is proposed and all the way through its approval cycle and final implementation in the deployed system, the change should be tracked. When it has been superseded by another change, the initial change should be archived. A complete history of all changes to all configuration items should be maintained throughout the life of the system and eventually archived.
It's a good idea to follow the same process for any test equipment used to debug the system. For example, if there are multiple dynamic message signs that will be tested, it's important to make sure that all tests were run using test equipment configured the same way.
How do you know that your project team members are following the documented CM processes to establish the baseline and control changes to it? You should periodically audit the processes and procedures that they're using against those in your CM Plan and also assess whether or not the CM processes are working effectively.
An auditing exercise should also verify that the state of each configuration item and its associated specifications, interface control documents, and other data are indeed as recorded in the CM tool. Check that a rabbit trail that tracks the history of changes to each item is complete.
TOC Previous Page Next Page
