Chapter 10

Systems Management and Control

As mentioned many times in previous chapters, systems engineering is a well-defined, requirement-driven process that brings systems to life. With increasing levels of complexity, the system design life cycle could last for years, even decades, with hundreds or even thousands of people involved globally. There are many ways in which things could go wrong, as unexpected events occur almost all the time. Dealing with these uncertainties in a dynamic environment puts good planning and management efforts in demand. The systems engineering management plan (SEMP) is such a document that has been developed and widely adopted in complex systems design, to plan, schedule, and control system engineering design efforts and activities throughout the system life cycle, mainly focusing on the technical aspects. In this chapter, we will use SEMP as the basis and template to illustrate how system engineering design is planned and controlled; more specifically, we will

1. Describe the system design teams and responsibilities
2. Describe SEMP and its content, including major sections and information included in each of the sections
3. Describe system control concepts; introduce two commonly used project control models, the critical path method (CPM) and the program evaluation and review technique (PERT), providing examples of both models

The purpose of this chapter is to introduce the fundamental concepts of systems management and models that can be used to schedule and control the progress of systems engineering technical activities.

10.1 Systems Management Planning

10.1.1 Engineering Design Project Management and Design Teams

Systems engineering is a team effort, especially for large, complex systems; it is not uncommon to see a design project involving thousands of people from different countries. Managing these people and their daily activities is certainly a challenging task, not to mention the uncertainties and risks that occur all the time, which makes management even more difficult. It is no myth that a successful system development largely depends on a well-thought-out plan of the project, careful selection of the design teams, and efficient coordination of all the different players/stakeholders in the design life cycle. That is to say, systems engineering requires good project planning and management.

Project management plays a key role in the systems design life cycle; depending on the nature of the systems design project, different skills may be required for the different phases of the life cycle, but, generally speaking, the basic functions are similar; the ultimate goal is to manage the design personnel and efforts to be both technically and economically efficient. In a team-based approach for managing systems design projects, the key measures for success are time, cost, and technical performance metrics. The major administrative issues for project management include selecting the project team members and defining their responsibilities, choosing team leads, and managing/allocating resources.

As we mentioned earlier in Chapter 2, systems engineering is multidisciplinary in nature, which implies that the composition of the teams is also multidisciplinary; it is very common that a design team contains a variety of skills and expertise. It may include representatives from management (e.g., chief technical officer, human resources person, manager/directors, etc.), finance and accounting personnel, systems engineers (even in this field, there are different types of skills; e.g., industrial engineers, systems designers, modeling and simulation engineers, engineering psychologists, human factors engineers, etc.; it all depends on the nature of the systems being developed), engineers from related fields (e.g., aerospace engineers, civil engineers, electrical engineers, software engineers, mechanical engineers, etc.) and personnel with specialized skills such as graphical designers, architects, or computer programmers, plus facility and support personnel at various levels. As a project manager/team leader, one’s great responsibility is to control the team personnel’s efforts on a daily basis, to make sure the design efforts are on the right track in a timely and cost-efficient manner. The manager bears important responsibility for the success of the system design and implementation; he/she serves as the link in the chain of command, controlling work efforts and progress, managing human labor within the team, maintaining communication, promoting collaboration, safeguarding the work atmosphere and environment, monitoring work quality, and, most importantly, keep track of the time and costs spent on the design. A good manager is not only a good system engineer who understands the complexity of systems design and applies a systems engineering approach, but also possesses strong leadership and personal skills to bring all the team members together as a cohesive group. These skills cannot be learned solely in the classroom, but rather from personal experience and skills development. The team leaders’ job is both challenging and rewarding; certain management skills are required for effective management of the team, including communication, coordination, motivation, and flexibility. A good project manager shall have some understanding and training in operations management, not to mention that there are many ethical issues that exist in managing teams; together, these require the project manager to have well-rounded skills to perform the job satisfactorily. In this text, we will not cover the whole spectrum of system management responsibilities, but only focus on the technical aspects of systems design; for a more comprehensive review of project management, readers can refer to any operations management textbook such as Stevenson’s Operations Management (2009). In the next section, we will introduce a work tool that is commonly used in systems engineering to manage the technical efforts of systems design: the systems engineering management plan, or SEMP.

10.2 Systems Engineering Management Plan (SEMP)

The systems engineering management plan (SEMP) is an important tool for systems engineers to manage and control systems design projects. According to INCOSE (2004), SEMP is a top-level plan for managing systems engineering design efforts and activities. It defines how a systems design project will be “organized, structured and conducted and how the total engineering process will be controlled to provide a systems that meets the stakeholder requirement.” More specifically, the SEMP is a “document that identifies the plans and schedules that will be needed to perform the technical effort for the systems development. This document is used to tailor the various activities to the needs of the project/program and is used to control the systems development when completed and approved” (INCOSE).

Since systems engineering is a structured plan for systems design, SEMP can be considered as a “plan for the plan”; it defines and regulates design activities and efforts so the systems engineering process can be carried out in an efficient manner. In these sections, we will describe the general structure and functions of a typical SEMP document, based on INCOSE (2004). For any specific system, SEMP needs to be tailored to accommodate its special nature and needs.

The basic structure of a typical SEMP includes the following sections:

10.2.1 Cover Page

The cover page includes the title and contract information for the project; it should include “Systems Engineering Management Plan (SEMP)” as part of the title, and at a minimum, the cover page should also include a project number, the authors’ names and their contact information, customer name, date and location, funding agency, and contract information if applicable.

10.2.2 Table of Contents

As a standard, a table of contents should be included to facilitate easy access within the document. Ideally, this table should be generated automatically by word processing software and should also include the list of figures and list of tables.

10.2.3 Scope of Project

The scope of the project should state the purpose of the system to be designed with a brief summary and the content of the system. For some complex systems, the level of the complexities and challenges involved may also be briefly described. Some scope sections may also need to state the environmental conditions in which the system will operate, and the organizational structure involved in systems design, including the composition of the technical teams and their responsibilities. The purpose of this section is to give an overview of the system and make readers aware of the fundamental players involved in the efforts, including the various types of stakeholders.

10.2.4 Applicable Documents

Some prefer to put this section at the end as part of the references of the document. This section lists all the documents that have been used as input to the project. These could include government documents, standards, specifications and codes, or any other documents needed, even internal planning documents. Usually, government documents are listed first, followed by the rest in the following format:

Document Number Title

10.2.5 Systems Engineering Process

This section is the core component of the SEMP; it defines the major design processes that are needed to develop the system, serving as guidance for systems engineering teams. It should also cover the organization’s policies and procedures for systems engineering activities; the main subsection should include systems engineering process planning, requirement analysis, functional analysis and allocation, synthesis, system analysis, and control.

10.2.5.1 Systems Engineering Process Planning

In this section, the planning effort of the systems design process is defined; this should include (but not be limited to)

Design data and major deliverables: At each major design milestone, what is required to be delivered, such as design data, drawings, parts lists, specification documents, and baselines. For complex systems, software may be required to produce these documents, such as Vitech’s CORE. A particular format should be followed to develop these documents; this format needs to be specified in this section.

Design input: The source and rationale of the project is specified here; this might include the statement of work (SOW), request for proposal (RFP), documentation from the previous versions of the systems and major problems which need to be fixed, market surveys, and so on, to justify the need for the design of the system.

Technical objectives: The technical objectives specify the operational goals for the system to be designed; this serves as a high-level requirement source as well as supplementary material for design input.

Work breakdown structure: The work breakdown structure (WBS) is a hierarchical decomposition of the system design efforts into various levels of components in different phases. Usually constructed in a tree structure, WBS provides a framework to plan and control the work process needed for the design to complete the work in a timely and cost-efficient manner. It starts with the highest level of technical objectives, based on the outcomes of the design, rather than the work needed, to specify the outcomes in the sublevels, letting the outcomes drive the work. WBS is an important tool to map out the work efforts needed for the overall design of the project; it provides a basic structure for personnel and cost allocation, and has been a common practice technique for most complex projects. It has been adopted by government standards. For more details of WBS, readers can refer to INCOSE (2012) and MIL-STD-881C (DoD 2011).

Training: For complex systems, training may be an important issue; this section specifies planning for training, including training objectives, training performance measurement metrics, the proposed training facility, and support and major timelines/schedules for training.

Standards and procedures: In this section, all the standards and procedures that are related to the project should be listed. These standards and procedures are mainly internal and should be different from the applicable external documents. The standards and procedures of the organization should be followed, including those for human resources, accounting, quality control, and related policies.

Resource allocation: Resources include the personnel, capital, facilities, and time that are necessary for the successful completion of the project. According to the INCOSE SEMP template (INCOSE 2004), the resource application should include the resource requirements for the various phases of the design, and procedures for resource allocation.

The systems engineering process specifies the work authorization procedure and policies, and sometimes the verification planning, specifying the responsibilities of the verification personnel, and major verification plans and schedules, including the demonstrations and tests that may be required throughout the systems life cycle.

10.2.5.2 Requirement Analysis

This section defines the methods to be used for systems requirements analysis. This is the one of the most important design efforts in the conceptual design phases and even throughout the design life cycle. To obtain a good set of design requirements, these efforts need to be planned carefully, especially the methods and approaches that will be used to collect and analyze them. According to INCOSE (2004) at least 15 categories of requirements need to be covered in the requirements analysis section; they are: reliability and availability, maintainability, supportability and logistic control, sustainability, environmental compatibility, human engineering and human–system integration, safety and environmental impact, security, producibility, testing and evaluation, testability and diagnosis, computer resources, transportability, infrastructure support, and other engineering specialties required by the systems.

10.2.5.3 Functional Analysis/Functional Allocation

In this section, this refers to the scope and information needed in the functional analysis. Detailed information within the functional analysis, such as the level of function decomposition, functional requirements, risks, and function allocation to components, needs to be clearly defined in the SEMP for the consideration of the efforts required to complete the tasks.

10.2.5.4 Synthesis

In this section, the synthesis efforts are specified. Systems synthesis, as we have previously discussed, consists of a series of activities that brings the systems design concepts into actual systems. These activities translate the physical architecture of the systems, interfaces and prototyping, and proposed product and process solutions for the development. Possible topics include but are not limited to: trade studies, quality analysis, COTS items selection, simulation models (such as CAD, CATIA, Arena, etc.), performance prediction model, testing and evaluation model, and so on. The overall goal is to create a feasible plan to translate system requirements into detailed design parameters.

10.2.5.5 System Analysis and Control

This portion of the SEMP defines the tools and models to be used by designers to conduct system analysis and control the design process. Some of the tools include decision making using trade studies, cost-benefit analysis, risk assessment, configuration management, data and interface management, scheduling and planning, TPMs, technical reviews, supplier control, and selection and requirement management. Some of the topics have been covered in previous chapters; for a more detailed description of these items, please refer to INCOSE (2004, 2012). The purpose of this section is to define the criteria for each of the analyses, determine the methods and models for conducting the analysis, the basic procedures involved, and, most importantly, provide estimates of the resources required for completion of these analyses so that these efforts can be properly planned and controlled.

10.2.6 Transitioning Critical Technologies

According to INCOSE (2004), this section is described as the “key technologies for the program and their associated risks, including the activities and criteria for assessing and transitioning critical technologies form technology development and demonstration programs.” Most of the technologies are developed in the scientific laboratory environment. Using the technology in a real-world system requires collaboration and partnerships between the government, academia, and industries. When a technology is ready to be transitioned to industry, the operational environment changes may bring out additional issues or risks that are not present in the originating laboratory. Issues such as operational environment and capacities, cost, residual use, purchasing and acquisition policies, and legal/political issues will bring risks and challenges to technology transition. A comprehensive plan is required for a smooth transition to lay out the foreseeable risks and identify the critical elements and management strategies, so that if unexpected events occur in the future, a management plan will be in place to handle them. This section will give a description of the candidate technology for the systems, their acquisition/purchasing procedures, possible risks involved, and alternatives that will be considered should any changes occur within the development.

10.2.7 Systems Integration Efforts

According to INCOSE (2004), systems integration defines how “various inputs into the Systems Engineering efforts will be integrated and how interdisciplinary teaming will be implemented to involve appropriate disciplines in a coordinated Systems Engineering effort.” Systems integration is a process that brings together all components and subsystems into one system and ensures that they work and function as one. Nowadays, companies seldom produce everything within one organization, rather taking advantage of the global supply chain to find the most economical parts from various suppliers. To successfully integrate system components together, systems designers need to have a wide breadth of knowledge of systems components, such as hardware, software, and networks, as well as enterprise and government architecture and policies. General problem-solving skills are often required to handle the uncertain and challenging problems that may not be seen elsewhere, as every system is different. Common tasks in systems integration include (INCOSE 2004):

Team organization: Defines the multidisciplinary teams that will be formed for the project; key team players and their responsibilities shall be specified. A typical team composition should include management, engineers, accounting and finance, marketing, customers, suppliers, and subject matter experts. According to INCOSE (2004), these teams should have an organizational structure, and should be end-item oriented. The core controlling team is the “system team of teams,” which includes the lead systems engineer, the technical director, and a representative from each of the end-item teams. The composition and organization of the teams integrate all the necessary expertise together to meet the project requirements, in terms of cost, time schedule, and performance objectives.

Technology verification: In this section, the team verification plan is developed for the candidate technology considered. The objective is to have the appropriate team composition to ensure the necessary expertise is covered for these technologies.

Process proofing: This defines the measures and efforts planned to ensure an appropriate process for the proposed system. It also defines the necessary team credentials for such process proofing and synergy with other ongoing concurrent projects within the organization.

Manufacturing of engineering test articles: This defines the team composition for the manufacturing of engineering test articles. Details include the definitions of the manufacturability and technology, and the process and development teams’ relationships to ensure a suitable manufacturing process.

Development test and evaluation: This defines the teams that are responsible for development test and evaluation to achieve life cycle cost optimization. These tests and evaluations should cover the whole life cycle of system development and specify the levels and locations of the tests.

Implementation of software design for end items: This defines the teams who are responsible for developing the software end items. If any special software engineering efforts are needed, these should be defined clearly, regarding how to integrate them with the systems engineering efforts; if there are any foreseeable software development risks, they need to be described here, as well as the potential measures to minimize these risks.

Sustaining engineering and problem solution support: This defines the teams who are responsible for sustaining engineering efforts, including the levels of support and facility requirements, as well as the potential risks involved.

Other systems engineering implementation tasks: This defines the teams that are responsible for system implementation tasks, identifies the tasks that are related to system implementation and what efforts are needed to complete the tasks and coordinate them between different teams.

10.2.8 Additional Activities

This defines all other activities that are not included in the previous sections. These largely depend on the nature of the system, and describing these activities helps customers to understand the efforts planned. According to INCOSE (2004), these activities may include, but are not limited to: long lead items, engineering tools, design to cost, value engineering, system integration plans, compatibility with support, and other plans. For a more detailed description of these items, readers can refer to INCOSE (2004), section C-8.

10.2.9 Appendices

All the appendices are listed here, including support materials, background information, glossary, design documents (drawings, blueprints, checklists, etc.), and external links.

10.2.10 Systems Engineering Master Scheduling

A systems engineering master schedule (SEMS) is a top-level process control and measurement tool for systems engineers to plan, control, and monitor the progress of the systems design efforts and activities, to make sure these are carried out in a timely and efficient manner to ensure successful completion of the project. Using SEMS, the design efforts and processes, including the decision points and flow logic involved, are visible for in-process verification; the expected outcome, accomplishments, and factors are visible throughout the design process. Such visibility helps designers to control and monitor the progress and visualize the risk factors, which, in turn, helps to control these risks.

The SEMS is driven by technical events; there are four basic elements used to develop the SEMS:

Events: These include the major technical efforts, as well as the reviews and key demonstration points.

Required accomplishments for events: The final steps or outcomes for each of the technical events. Examples of such accomplishments are the completion of the physical design and the interface prototype, completed and documented reviews, and so on. These accomplishments are derived from the system specifications; they should be clearly defined yet allow flexibility in implementation.

Criteria for accomplishment: For each of the accomplishments defined above, criteria are specified that can be measured, such as “technical report completed,” “reliability test accepted,” and so on.

Timeline of events: For the sequence of events required, specify the time needed for each of them to plan the efforts to complete on time.

A typical SEMS development should start with identification of the major events, and then break these down into activities. Based on the process of these events, a sequence tree is developed to aggregate these events together; the input/output outcomes of these events are then specified, as well as the criteria for these outcomes. A decomposition of the SEMS to a detailed schedule is possible if multiple levels of activities are involved.

The SEMP is an essential part of the system design project; the sections listed here are quite general. Keep in mind that every design project is different, so the SEMP should be tailored to the needs and the nature of the system to be designed. As seen in the SEMP, system scheduling is one of the key components. In the next section, we will introduce the two most commonly used methods to control the system schedule: the critical path method (CPM) and the program evaluation review technique (PERT).

10.3 Systems Control Models

In this section, we introduce two of the most widely used techniques for planning, CPM and PERT. These methods are similar in nature but different in the types of data applied in planning. CPM is a deterministic approach with no randomness incorporated in its model, while PERT is considered a probabilistic model, as it includes random time data in the analysis.

10.3.1 Critical Path Method (CPM)

The critical path method, also sometimes called critical path planning, is commonly used in scheduling for systems planning. Based on the network structure of the work schedule, CPM can derive the minimum time needed for project completion by identifying the critical path of the project design activities, as well as the start and end times for all the activities involved in the project.

Before we get into the details of CPM models, let us define some of the elements that are essential for CPM modeling. First, CPM is a network model; the CPM network consists of a sequence of events and activities that are necessary for the completion of the project. An event is usually a milestone or certain phases in design process; for example, an event could be “requirement analysis completed,” “prototype completed,” or “functional model developed,” and so on. In CPM, an event is represented by a circle, as seen in Figure 10.1.

The second element for CPM is the activity, which is represented by an arrow link from the start event to the end event, usually with time information on the arrow, as shown in Figure 10.2.

CPM represents the sequential relationships (predecessors and successors) of the design process using events, event nodes, and the corresponding activities. Completing the project means that all the activities have to be carried out and completed. Many people might confuse CPM with finding a short path for a network, as they are similar, but when finding the shortest path we do not have to visit every path, as long as we can get to the end point from the start point. In CPM, an event is not considered complete until all the activities prior to that event are completed. This is important to keep in mind as we introduce the algorithm.

Of particular interest in CPM is to find the critical path. A path is a sequence of events and activities from the start event to the end event. A critical path is the longest path (in terms of time) among them; the sum of the times on the critical path represents the shortest time required to complete the project. Any delay on the critical path is going to delay the whole project. This implies that, for all the events on the critical path, their earliest start time (tES) equals their latest start time (tLS) or that there is no slack time for each critical event, that is to say, s = tLS − tES = 0.

This gives us the indication of how to find the critical path; first, we start from the start node and work toward the end event, working out the earliest start time for each of the events; then, we work backward from the end event back to the start event, to work out the latest start time for each of the events. By calculating the slack time for each event

$s=t_{LS}-t_{ES}$ (10.1)

We can then identify the critical path by finding the events with zero slack time. Let us use an example to illustrate the procedure to find the critical path.

Example 10.1

Critical Path Method. Figure 10.3 shows a network diagram for a project. Find the critical path for this project.

Solution:

Step 1. Find the earliest start time for each event.

Event A: Obviously the earliest start time is tES = 0.

Event B: In working out the earliest start time, we need to look at the immediate predecessors of that event; the earliest start time of the event is immediately after all the preceding events and activities complete. For event B, the immediate predecessor is event A. If we denote the earliest start time for B as tES(B) and the activity time from A to B as dAB, then for event B, tES(B) = tES(A) + dAB = 0 + 3 = 3.

Event C: Event C has more than one immediate predecessor; namely, A and B. The event has more than one immediate predecessor since it cannot start until all the previous events and activities are completed, so we take the maximum value of all the immediate predecessor events’ earliest start times plus their corresponding activity times, or

$t_{ES}\left(C\right)=\max \left\{\begin{array}{c}{t}_{ES}\left(A\right)+d_{AC}\\ t_{ES}\left(B\right)+d_{BC}\end{array}\right\}=\max \left\{\begin{array}{c}0+5=5\\ 3+4=7\ast \end{array}\right\}=7$

Event D: D has only one immediate predecessor, B, so

$t_{ES}\left(D\right)=t_{ES}\left(B\right)+d_{BD}=3+6=9$

Event E: E also has only one immediate predecessor, D, so

$t_{ES}\left(E\right)=t_{ES}\left(D\right)+d_{DE}=9+5=14$

Event F: F has three immediate predecessors, C, D, and E, so the earliest start time for F is

$t_{ES}\left(F\right)=\max \left\{\begin{array}{c}{t}_{ES}\left(C\right)+d_{CF}\\ t_{ES}\left(D\right)+d_{DF}\\ t_{ES}\left(E\right)+d_{EF}\end{array}\right\}=\max \left\{\begin{array}{c}7+9=16\\ 9+8=17\ast \\ 14+2=16\end{array}\right\}=7$

Event G: G has two immediate predecessors, E and F:

$t_{ES}\left(G\right)=\max \left\{\begin{array}{c}{t}_{ES}\left(E\right)+d_{EG}\\ t_{ES}\left(F\right)+d_{FG}\end{array}\right\}=\max \left\{\begin{array}{c}14+8=22\\ 17+7=24\ast \end{array}\right\}=24$

We mark the earliest start time on the network, as shown in Figure 10.4.

Step 2. Find the latest start time for each event.

In finding the latest start time, we start from the end event, G, and work backward to the start point, A.

Event G: For the end event, the latest start point equals its earliest start point, so

$t_{LS}\left(G\right)=24$

Event F: To work out the latest start time for an event, we need to look at its immediate successor in the network diagram. Event F has only successor, G, so its latest start time is

$t_{LS}\left(F\right)=t_{LS}\left(G\right)-d_{FG}=24-7=17$

Event E: E has two immediate successors; namely, F and G. To work out the latest start time, we need first to calculate the latest possible start time for each of the successors by subtracting the activity time from the latest start time for that successor, and then choosing the minimum value from the results of all the successors. The reason we choose the minimum value is to ensure all the latest start times of the successors will not be affected. We can obtain the latest start time for E as

$t_{LS}\left(E\right)=\min \left\{\begin{array}{c}{t}_{LS}\left(G\right)-d_{EG}\\ t_{LS}\left(F\right)-d_{EF}\end{array}\right\}=\min \left\{\begin{array}{c}24-8=16\\ 17-3=15*\end{array}\right\}=15$

Event D: D has two immediate successors, E and F, so the latest start time for D is

$t_{LS}\left(D\right)=\min \left\{\begin{array}{c}{t}_{LS}\left(E\right)-d_{DE}\\ t_{LS}\left(F\right)-d_{DF}\end{array}\right\}=\min \left\{\begin{array}{c}15-5=10\\ 17-8=9*\end{array}\right\}=9$

Event C: C has only one successor, F, so its latest start time is

$t_{LS}\left(C\right)=t_{LS}\left(F\right)-D_{CF}=17-9=8$

Event B: B has two immediate successors, C and D, so the latest start time is

$t_{LS}\left(B\right)=\min \left\{\begin{array}{c}{t}_{LS}\left(C\right)-d_{BC}\\ t_{LS}\left(D\right)-d_{BD}\end{array}\right\}=\min \left\{\begin{array}{c}8-4=\text{4 }\\ 9-6=3*\end{array}\right\}=3$

Event A: A is the start point, so its latest start time will be zero. But, to reveal the critical path, it is a good idea to complete the same procedure for A.

$t_{LS}\left(A\right)=\min \left\{\begin{array}{c}{t}_{LS}\left(B\right)-d_{AB}\\ t_{LS}\left(C\right)-d_{AC}\end{array}\right\}=\min \left\{\begin{array}{c}3-3=0*\\ 8-5=3\end{array}\right\}=0$

The earliest start (ES) and latest start (LS) results are shown in Figure 10.5. The 3-tuple in the parentheses associated with each event represents (ES, LS, slack). Slack is calculated by using Equation 10.1.

From the algorithm above, trace back from G to A, identifying the zero-slack events that are on the critical path (those with a * in the calculation), and mark them on the network diagram, as seen in Figure 10.6.

The critical path is identified as A → B → D → F → G. The total time required (or the minimum time needed) to complete the project is 24 time units.

We have described the CPM algorithm in detail. Table 10.1 and Table 10.2 show how to use a spreadsheet to carry out the above algorithm. The earliest start time is illustrated in Table 10.1, and the latest start time is illustrated in Table 10.2.

An algorithm for CPM is easy to implement using a computer program. In such a program, it is more convenient to use numbers (1, 2, 3, …) for the events rather than letters. The following shows a generic procedure for a CPM computer algorithm.

Step 1: Number all the events from start to end. Derive the matrix D to represent the CPM network diagram, with D = [dij], i = 1, 2, …, n; j = 1, 2, … n; dij > 0 if there is a link between i and j; for the above example, the matrix would be

$D=\left[\begin{array}{ccccccc}0& 3& 5& 0& 0& 0& 0\\ 0& 0& 4& 6& 0& 0& 0\\ 0& 0& 0& 0& 0& 9& 0\\ 0& 0& 0& 0& 5& 8& 0\\ 0& 0& 0& 0& 0& 2& 8\\ 0& 0& 0& 0& 0& 0& 7\\ 0& 0& 0& 0& 0& 0& 0\end{array}\right]$

Step 2: Calculate the earliest start time for each node, as follows:

1. Let E(1) = 0
2. For j = 2, 3, …, n, let

   $E\left(j\right)=\underset{i}{\max }\left(E\left(i\right)+ d_{ij}\right)$

   Step 3: Calculate the latest start time for each node:

3. Let L(n) = E(n)
4. For i = n − 1,n − 2, …, 1, let

$L\left(i\right)=\underset{j}{\min }\left(L\left(j\right)-d_{ij}\right)$

Step 4: Calculate the slack time for each node. The critical path is identified by finding the zero-slack time nodes.

10.3.2 Program Evaluation and Review Technique (PERT)

The program evaluation and review technique was first developed by the U.S. Navy’s Special Project Office in the 1950s to support its Polaris nuclear submarine project. Its intention was to have a statistical technique to consider the uncertainty within the project and to measure and predict the program’s progress. Its principle is very similar to that of the CPM method; they both use network models, and the algorithms are also similar. Unlike CPM, in which time is deterministic, PERT incorporates randomness into the time estimate of the activity; that is, for each of the activities between events, there are three pieces of time data being estimated:

1. Optimistic time (to): the time required to complete the activity under optimal conditions; this is the minimum time needed to complete the activity.
2. Most likely time (tm): the amount of time that is the most probable to be taken to complete the activity.
3. Pessimistic time (tp): the amount of time required to complete the activity under the worst-case scenario.

   In PERT analysis, we are interested in the expected (mean) time required to complete the activity te and its variance for the time (σ2). Most of the PERT model uses the beta distribution as an assumption of the time; although there is no real theoretical justification for using this distribution, it has been argued that it provides great generality for different shapes of time distribution, whether symmetric or skewed (Figure 10.7).

   Figure 10.7

   

   Illustration of beta distribution.

The expected value te is given by Equation 10.2:

$t_e=\frac{t_o+4t_m+t_p}{6}$ (10.2)

And the variance σ2 is given by Equation 10.3:

${\sigma }^2={\left[\frac{t_p-t_o}{6}\right]}^2$ (10.3)

The basic steps for conducting a PERT analysis include the following:

1. Develop the network diagram for the project and identify the tp, to, and tm estimates for the activities;
2. Compute the expected (mean) time te and variance σ2 for each of the activities, as shown in Equations 10.2 and 10.3.
3. Find the critical path using te.
4. Estimate the probability of project completion by a specified time or related estimate.

   We will illustrate the PERT algorithm using Example 10.2.

   Example 10.2

   Figure 10.8 presents the information for a project, with the 3-tuple showing the to, tm, and tp of the time estimate (in days). (a) Find the critical path for the project; (b) determine the expected length of the project; and (c) calculate the probability that the project will be completed within 22 days or less.

   Figure 10.8

   

   Network diagram for Example 10.2.

   Step 1: Based on the information given in Figure 10.8, compute the expected (mean) time te and variance σ2, as shown in Table 10.3.

   Table 10.3

   Expected (Mean) Time t e and Variance σ 2

   Event	Immediate Successor	$t_o$	$t_m$	$t_p$	$t_e$	σ 2
   A	B	1	3	4	2.83	0.25
   A	C	3	4	5	4.00	0.11
   B	D	2	3	4	3.00	0.11
   C	E	6	7	9	7.17	0.25
   D	E	1	2	3	2.00	0.11
   D	F	4	6	7	5.83	0.25
   E	F	6	8	10	8.00	0.44
   E	G	7	9	10	8.83	0.25
   F	G	3	4	6	4.17	0.25

   Step 2: Using CPM procedures, identify the critical path. The earliest start times are shown in Table 10.4 and the latest start times are shown in Table 10.5. Based on the above algorithm, the critical path can be easily obtained, as seen in Figure 10.9.

   Table 10.4

   Earliest Start Time

   Event	Immediate Predecessor	t ES + d ij for Each Predecessor	t ES
   A	–	–	0
   B	A	0 + 2.83 = 2.83	2.83
   C	A	0 + 4.00 = 4.00	4.00
   D	B	2.83 + 3.00 = 5.83	5.83
   E	C	4.00 + 7.17 = 11.17a	11.17
   	D	5.83 + 2.00 = 7.83
   F	D	5.83 + 5.83 = 11.66	19.17
   	E	11.17 + 8.00 = 19.17a
   G	E	11.17 + 8.83 = 20.00	23.34
   	F	19.17 + 4.17 = 23.34a

   a Indicates the smallest value for multiple successors.

   Table 10.5

   Latest Start Time

   Event	Immediate Successor	t LS − D ij for Each Successor	t LS
   G	–	–	23.34
   F	G	23.34 − 4.17 = 19.17	19.17
   E	F	19.17 − 8.00 = 11.17a	11.17
   	G	23.34 − 8.83 = 14.51
   D	E	11.17 − 2.00 = 9.17a	9.17
   	F	19.17 − 5.83 = 13.34
   C	E	11.17 − 7.17 = 4.00	4.00
   B	D	9.17 − 3.00 = 6.17	6.17
   A	B	6.17 − 2.83 = 3.34	0
   	C	4.00 − 4.00 = 0a

   a Indicates the smallest value for multiple successors.

   Figure 10.9

   

   Critical path based on the expected time, A → C → E → F → G, with the total expected time to complete of 23.34.

   The second part of the question asks what the probability is that the project is completed in 22 days or less, or, what is P(t ≤ 22)?

   In working out the probability, we assume that the overall completion time t follows the normal (Gaussian) distribution. One may ask why individual time follows the beta distribution while the overall time follows the Gaussian. According to the central limit theorem, the arithmetic sum of any sufficient large number of independent random variables will be approximately normally distributed, regardless of the distribution of those random variables. Recall that in previous chapters (such as in Section 5.3 on maintainability) we used the standard normal distribution to estimate the z-value. We use a similar procedure here.

   The mean time for completion is μ = 23.34 days and the standard deviation of the time equals the square root of the sum of activity variances on the critical path, or

   $\sigma =\sqrt{{\displaystyle \sum \text{variances of critical path activities}}}$ (10.4)

   So, according to Equation 10.4, we can obtain the standard deviation by

   $\sigma =\sqrt{{\displaystyle \sum \left(0.11+0.25+0.44+0.25\right)}}\cong 1.0247$

   So, the z-value for 22 days can be obtained as

   $z=\frac{20-\mu }{\sigma }=\frac{22-23.34}{1.0247}=-1.31$

   So, P(t ≤ 22) is converted to P(z ≤ −1.31)

   Using the normal distribution table in Appendix II, we find that the probability of P(z ≤ −1.31) = 0.0951, so the probability that the project is completed in 22 days or less is approximately 0.0951 or 9.51%.∎

   10.4 Summary

   For large, complex systems design, a well-planned design process is essential for the success of the system development. This characteristic requires a team effort and also demands much of project management. In this chapter, major methods for systems engineering management and control were reviewed, including SEMP, CPM, and PERT. The SEMP is an organized and structured document, and lists practices to define and control technical efforts for systems development. It is used to make sure the systems design efforts are on track and to meet the time and cost limits. The major sections in the SEMP include the cover page, table of contents, scope of the project, applicable documents, systems engineering processes, transitioning critical technologies, systems integration efforts, other additional activities, and master scheduling. CPM is a very commonly used deterministic scheduling tool. Based on the work structure, CPM uses the network diagram to identify the earliest and latest start times for each event. The critical path can then be identified by finding the activities with zero slack time. PERT is a more general approach than CPM; it incorporates randomness into activity time, by using the beta distribution, a critical path can be obtained using the mean activity time, and the probability of completing the project within a certain window of time can be estimated using the mean and variance of the times of activities on the critical path.

   Problems

5. Why are system management and control important in systems engineering processes?
6. What is SEMP? Describe the major sections included in SEMP.
7. Find out the critical path for the following project network.

   

8. Find out the critical path for the following project network.

   

9. In the following project, find the critical path and calculate the probability of completing the project in 25 days.