Warehouse Management System Project

Running head: MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 1

Research Project: Model-Based Systems Engineering Implementation

(Name and date withheld)

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 2

Model-Based Systems Engineering (MBSE) Implementation

Section 1: Requirements Analysis

Section 1 tasks for the MBSE project will identify issues and requirements for

implementing an MBSE system for our Engineering and Systems Integration work.

Problem Definition

Our Engineering department focuses on a niche market of systems engineering, design,

integration, and ongoing maintenance and support of emergency communication and power

systems, predominantly housed in High-Altitude Electromagnetic Pulse (HEMP) protected

mobile environments. The complexity of the integrated voice, data, network, and audio/video

systems we work with, the specialized nature of the work, and the demanding project timelines

have put a strain on our resources and existing processes. We need to leverage common

requirements and design elements across projects and customers while remaining adaptive to

unique and changing customer needs. With people spread across multiple projects, it is harder to

capture changes on one system that should be implemented on others – especially since

requirements and design files are all in separate Word, Excel, Visio and other documents. We

would also like to expand our business to new customers with complex Systems-of-Systems

(SoS) environments that may require protections from HEMP events. To do that, we need to

streamline our processes and reduce redundant work to allow people to reasonably take on

additional projects and make new hires productive on project work more quickly – while

maintaining critical quality factors.

Issues requiring solution. The following list describes the primary issues requiring the

development of an MBSE system for Engineering.

1. Business growth is placing a strain on senior employees with specialized skills

and knowledge.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 3

2. System information is contained in a large, diverse set of files (Excel files, Word

documents, Visio diagrams, and CAD files) with no easy way to share technical information.

3. We can’t easily reuse or modify applicable requirements and design elements

between projects. This increases cost and effort of new work.

4. It 's hard to perform change management and assess impacts on a short timeline

across the systems’ lifecycle, again increasing workloads and quality risks.

5. We’re not able to quickly evaluate new customer requirements and designs against

existing systems efficiently, increasing the effort and response time on customer proposals.

6. There is an increasing demand from customers to see architectural views and

interconnecting systems that help them understand the proposed designs.

7. Consistently high workloads cause bottlenecks that slow communications with the

other functional areas who are dependent on information from the engineering group.

High level project and system objectives.

1. Develop a full-lifecycle MBSE proof-of-concept.

2. Create a central repository that links system information on across the lifecycle–

research, concept, requirements, design, integration, test, support and maintenance, and disposal.

3. Focus on a Commercial-off-the-Shelf (COTS) solution that provides ongoing

product support and maintenance while reducing development and implementation time.

Requirements for the MBSE implementation. Requirements may be prioritized and

implemented in phases, but the fully developed MBSE system shall:

1. Support ‘modules’ of reusable requirements and design components.

2. Capture configuration management and analyze impacts of systems changes.

3. Incorporate a bill of materials for reusable design components.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 4

4. Enable creation of relationships and functional and physical visualization model

5. Allow import from Word and Excel-compatible formats.

6. Enable capture of system-related information, including materials.

7. Include a straightforward user interface with online help and training aids.

8. Support systems engineering across the system and product lifecycle.

9. Improve collaboration and information-sharing between functional groups.

10. Enable architecture views and data exchange standards required by DoDAF.

11. Map to standard modeling languages, including Lifecycle Modeling Language (LML)

and Systems Engineering Modeling Language (SysML).

Constraints on the system. The two constraints on development of the MBSE system

are : (1) the system must be installed in virtualized network, and (2) system must support

existing business security guidelines and user access based on Active Directory schemes.

Description of Proposed System

The MBSE System will be designed and implemented using a web-based interface in a

virtual network environment. The MBSE Implementation project would develop a process

approach and install the necessary software on the network; we have selected LML and Innoslate

software as the primary tools for this effort. LML is an open-standard modeling language that

supports systems engineering across the full life cycle of system development and acquisition

stages. Innoslate is COTS software that fully supports the LML standard and can map that

standard construct to other common modeling languages and architecture frameworks.

System Context Diagram

The context diagram for the MBSE system can be seen on Figure 1. This diagram shows

a generalized view of the MBSE system using LML and Innoslate software. The MBSE system

receives input from the Engineering, Project Management, and Verification/Validation System

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 5

entities. Also, it sends information to the Engineering, Project Management (PM),

Verification/Validation (V/V) testing, Information Assurance (IA), and Customer entities.

Figure 1. MBSE Context Diagram

Engineering enters requirements, materials lists, and other artifacts related to a project.

After processing the information, the MBSE system generates architecture models, reports, and

specifications based on the needs of different functional entities. Engineers receive as output a

graphical models generated from the system, the specifications necessary to define the

manufacture and implementation of the project, and specialized reports as required.

The Customer can view the specifications, reports, and model views to understand and

clarify whether the proposed system will meet the requirements of their project. PM receives

Engineering

Customers

Project

Management MBSE

System

Requirements/

Artifacts

Model Views

Reports

Model Views

Information

Assurance

Verification/

Validation

Specifications and

Reports

Material

Tracking

Material/Components

Test Documents

Model

Views

Model

Views

Specifications and

Reports

Specifications and

Reports

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 6

material lists related to a project and can update with material purchased. PM can also view

status reports on project activities. V/V receives input on the system functionality to allow them

to develop test documents; V/V can then attach test plans, procedures, and reports as artifacts to

the project. IA receives model views, specifications, and reports designed to assist them in

developing appropriate accreditation documentation and determine necessary security testing.

Logical Model Data Flow Diagram

The logical data flow diagram for the MBSE System (Figure 2) shows the five major

processes and a concept for the major system inputs and outputs. The processes interact with

four data stores, all of which are internal to the Innoslate program.

Description of processes. The processes shown in the logical model are described below.

1.0 Import/Enter Requirements: An engineer logs in to Innoslate to establish a

project and enter requirements using the Project entry screen and Requirements entities.

Requirements either be imported from a Word or Excel file or entered directly into the software.

2.0 Input/Update Materials List: Many of the same systems are integrated into

different customer projects. Using the Resource entity, this allows a centralized materials list to

be built, maintained, and reused across multiple projects and systems.

3.0 Build/Update Database: This process is the heart of defining the entities,

attributes, and relationships that LML and Innoslate use to create the architectural views and

centralized management of engineering data we need. Future phases will decompose this into

more detailed processes necessary to produce the required architectural views and other artifacts.

4.0 Select Model Views: This process will uses the Diagram view within Innoslate to

produce the architectural, functional, or traceability diagrams inherent in the product.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 7

Figure 2. Logical Data Flow Diagram

Engineering

Customers

Project Management

Establish Project

Model

Views

Model Views

Information Assurance

Verification/ Validation

Material

Tracking

Material/

Components

Model

Views

Specifications

and

Reports

1.0

Import/Enter Requirements

2.0

Input/Update Materials List

3.0

Build/Update Database

4.0

Select Model Views

5.0 Create Reports

and Specifications

D4 System

Descriptions

D3 Material

Components

D1 Customer /

Project Information

D2 Requirements

System Requirements

Requirements

Statements

Customer/

Project Information

System

Descriptions

Project

BOM

Customer/Project

Equipment List

Equipment Requirements

Material by System

Systems and Relationships

Information Sets

Systems Information for

Testing

Specifications and

Reports

Requirements/Artifacts

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 8

5.0 Create Reports and Specifications: In addition to graphical views, Innoslate

enables creation of several standard and custom report formats.

Data Dictionary. The Data Dictionary defines the five data stores internal to the

Innoslate software, and the fields found in them. Every entity in Innoslate is comprised of a

name, number, and description fields; individual entities have additional standard attributes and

relationships. Attributes names are unique for each entity, but may be used in other entities.

The data dictionary for Data stores 1, 2 and 3 of the MBSE project describes the fields on

the main input page for that function. Data store 4 can be associated with any one or more of the

20 entities that LML and Innoslate allow. Screenshots of primary input and output screens and

artifacts will found in the User Interface section in Section 2 of the paper will describe the data

fields anticipated used for the MBSE project.

D1: Customer/Project Information. An engineer goes to the Innoslate login page to

establish a new project, which will include customer information.

Name: Project Name - obtained from project work statement or statement of

work for external customers. A work order number, innovation project number, or other

descriptive text for internal customers.

Description: Customer name, point or contact and contract number for external

customers. The functional group and POC for internal projects. Brief descriptive text can be of

the project goal can be included.

D2: Requirements. An engineer enters project requirements which may either be

imported into the system using the Import Analyzer or entered directly into the system using the

Requirements View. Whether imported or direct-entry, the Requirements data store includes the

following fields

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 9

Name: Brief text for requirement objective.

Number: A unique number that notes the requirements place in the project

hierarchy; can be any alpha-numeric numbering scheme.

Description: The text needed to describe the requirement.

Rationale: Text capturing the reason behind the requirement.

Quality Score: Optional, generated by the system based on the selections

assessing various quality attributes shown.

Clear: Yes/No, is the requirement clear and unambiguous

Complete: Yes/No, is the requirement in conflict with other requirements

Correct: Yes/No, does the requirement describe the users true intent

Design: Yes/No, does the requirement impose a specific solution

Feasible: Yes/No, can the requirement be implemented using existing technology

and within cost and schedule

Modular: Yes/No; can the requirement be changed without excessive impact on

other requirements

Traceable: Yes/No, is the requirement uniquely identified and able to be tracked

to predecessor and successor lifecycle items

Verifiable: Yes/No, is the requirement provable

D3: Material Components. Engineers enter the project bill of materials into the system

as a Resource or by importing an existing list in .CSV format

Name: Name of resource.

Number: A unique alpha-numeric number designating the specific resource.

Description: The text needed to describe the resource.

Minimum Amount: Minimum quantity of the resource required.

Maximum Amount: Maximum quantity of the resource required.

Units: Text that defines the measure values, such as 'each' or 'hours'.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 10

D4: System Descriptions. This data store captures information and connections made

within Innoslate for any of the 20 Innoslate parent and child entities called out by the LML

Specification.

Descriptions of inputs/outputs. The basic inputs and outputs of the MBSE system are

shown in the logical data flow diagram and summarized in Table 1.

Table 1. MBSE Process Inputs and Outputs

Process Inputs Outputs

1.0 Import/Enter Requirements Requirements/Artifacts Requirement/Statements

Project Set Up

Equipment Requirements

2.0 Input/Update Materials List Equipment Requirements

Material Components

Material Changes

Materials by System

Project Bill of Material

Project Bill of Materials with

Costs

Material Tracking

Materials by System

3.0 Build/Update Database Material by System

Equipment List

System Requirements

System Descriptions

Material by System

System Descriptions

Systems and Relationships

4.0 Select Model Views System and Relationships Project Information Sets

Systems Information for Testing

Model Views

5.0 Create Reports and

Specifications

Project Information Sets

Customer/Project data

Specifications and Reports

Summary of Cost/Benefit Analysis

The implementation of MBSE would provide both tangible and intangible benefits. The

specific initial tangible benefits are reflected in the anticipated reduction in labor hours for

requirements and design support of projects. We anticipate an average cost reduction of 15% in

labor hours. Over the past two years, we have spent more than 8300 hours on requirements and

design activities. A reduction of 15% would realize approximately 1250 hours saved over two

years. At an average rate of $91.00 per hour, the savings per year would be almost $57,000.

Total Return on Investment would take approximately 2.7 years. This does not account for

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 11

potential savings realized by a reduction in rework and improved change management, or by

improved collaboration and process improvement for other groups.

Intangible benefits include reduced stress on senior staff, increased customer satisfaction,

and improved support for marketing to new customers.

Section 2: System and Database Design

Entity-Relationship diagram (ERD).

The ERD (Figure 3) shows how the different major MBSE entities are related. A

Customer can have one or more active Projects. On the other hand, a Project can belong to only

one Customer. A Project will have many Requirements. Requirements can describe many

Systems, and some individual Requirements may relate to several Systems. Each System has

many specific Requirements. A system-requirement relationship table joins those two entities.

Finally, a System will contain many types of Material, and any piece of Material may be

part of several different Systems. A material-system relationship table joins the System and

Requirements entities. The two relationship tables will serve to reduce the many-to-many

relationship and provide individual linkages as necessary.

Figure 3. MBSE Entity-Relationship Diagram

CUSTOMER PROJECT

MATERIAL

A customer has 1toM

projects

generates lists

SYSTEM

REQUIREMENTS SYSTEM-

REQUIREMENT

MATERIAL-

SYSTEM

generated

by describe

Identifies

Has

Has Define

Built from

Builds

Belongs to

Has

A project has many

requirements

Requirements describe

many systems

Systems have many

parts/material

Material can be part

of many systems

Systems have many

requirements

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 12

Database design. The LML specification calls out 20 parent and child entities,

descriptions, and examples of their usage (LML Spec, 2015). . The Innoslate software used to

implement the MBSE system provides full support to the LML specification. The System entity

shown in the MBSE is comprised of these individually defined entities and relationships.

Database file storage and access. In Innoslate, information is stored within projects

using a Relational Database structure. Each project has its individual database with physical

separation from other projects. A project can contain any number of requirements documents,

system models, simulation results, reports, etc. Innoslate projects are made up of entities,

attributes, and relationships. Each entity in Innoslate has a name, number and description

attribute no matter which entity class.

Innoslate relationships are bi-directional, where the relation and inverse relation comprise

one relationship. The Innoslate schema for Innoslate includes a "verified by" relationship

between the Requirement and any other type of entity. The base schema also has the "satisfied

by" relationship to track who or what fulfills the requirement. The schema requires bi-

directionality and automatically generates an inverse relationship (Innoslate, 2015). Innoslate

provides labels to support classification/ categorization of requirements at any time.

Users will have sign-in access to Innoslate based on Active Directory permissions.

Innoslate also provides three project-level permissions (Table 2) for user-access controls on a

specific project (Innoslate, 2015).

Table 2. Innoslate Project-Level Permission Levels (Innoslate, 2015)

Project-Level Permissions Description

Read Only View project contents only, add and remove your own

comments, unable to share project.

Read/Write View, modify, and delete project contents, add and remove

comments, unable to share project.

Owner View, modify, and delete project contents, add and remove

comments, share a project with other users.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 13

System Architecture

The Innoslate software will be installed on a separate partition in our virtualized network

environment using VMware and vSphere, as depicted in Figure 4.

Figure 4. Virtual Network Architecture (VMWare, 2006)

Technical requirements for software installation include (these can all be supported by

our network infrastructure) include: 1) SQL Database, 2) 1GB available disk space, 3) 4GB

RAM, 4) Modern browser (Chrome, Safari, Edge, Firefox), and 5) Internet connection to server.

User Interface

Since our MBSE solution will make use of the LML and Innoslate, this section will

provide a selection of Innoslate screenshots most commonly used for MBSE efforts. The menu

and top navigation bar at the top of every Innoslate screen gives users consistent access to links

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 14

necessary to navigate around Innoslate (Figure 5). Also, all entity ‘view' screens have a common

layout this is described further in the Input Screen section of the document.

Figure 5. Innoslate Menu and Navigation Bar

Project Set-up and Dashboard. After logging in to Innoslate, a user can establish a new

project. Figure 6 shows the screen for setting up a new project. This is the entity that captures the

Project and Customer reference for Data store 1. When several projects reside in Innoslate,

Dashboard screen appears (Figure 7) after login. To create a new project from the dashboard,

select the drop down on the project name (red arrow) in the menu bar and select Manage Projects.

Figure 6. New Project Screen

Figure 7. Innoslate Project Dashboard

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 15

Importing and entering requirements. Requirements for a project can be imported from

various formats, or entered individually into the system. Figure 8 shows the Import Analyzer

screen. As shown in the figure, requirements can be imported from Word, Excel or DOORS (CSV

format), PDF files, or plain text. Innoslate can also export data into an XML format.

Figure 8. Import Analyzer Screen Used to Import Artifacts.

Input screen: Requirement entity. All entity screens in Innoslate share a common layout.

As shown in Figure 9 for the Requirement entity, the entity type is shown in a black box on the

upper left part of the screen. A list of labels is underneath the box; labels are used to categorize

further the instance of each entity. Attributes are displayed in the center of the screen. The

‘name, number, and description' fields common to every Innoslate entity are listed first.

Additional attributes follow the three mandatory fields. Unique to the Requirement

entity, Rationale is an additional attribute. Some yes/no type fields follow the Rationale field to

enable a self-assessment as to the quality of the specific requirement. The last area common to

all entities is the Relationships section. Selections made here are one method used to build the

architectural models based on and traced to individual requirements.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 16

Figure 9. Innoslate Requirement Entity Screen

Input screen: Action entity. The layout of the Action entity is consistent with the

Requirement entity screens; however, the standard labels, attributes, and relationship choices

change. The Action entity attributes now include Duration, Start Date and Time, Percent

Complete, and Comment Fields (Figure 10). The Action entity is required for building a

functional or behavioral diagram for a system.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 17

Figure 10. Innoslate Action Entity Screen.

Input screen: Asset (Parent) and Resource (child) entities. The Asset and Resource

entities are used to define specific physical components of a system. The Resource entity is used

to capture consumable or producible assets of the system; this can be used to define a bill or

materials that will be used on a project. Additional attributes for the Resource entity include the

Initial, Minimum and Maximum Amount fields, and the unit types for the resource (Figure 11).

Examples could include ‘each' to for a quantity of servers, or ‘feet' to define a cable length.

Figure 11. Innoslate Resource Entity Screen.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 18

Input screen: Building the model. Users can also access a drag and drop interface from

the Diagrams drop down menu shown at the top of each entity screen (red arrow). Figure 12

shows the drop-down list from the Asset entity screen. Figure 13 shows an example for building

an Action diagram. Once the basic Action entity is on the screen, actions can be dragged from

the left-hand panel to develop the full sequence. This layout is common throughout Innoslate.

Figure 12. Creating a Diagram from an Entity Screen.

Figure 13. Innoslate Drag-and-Drop Interface Screen Example (Innoslate, 2015).

Outputs from the MBSE System

An essential output from the MBSE system is the graphical model. Selecting the Diagrams

from the top navigation bar will present the user with all the diagrams that have been created for a

project (Figure 14).

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 19

Figure 14 Innoslate Diagram View Screen (Innoslate, 2015).

There are three mandatory ‘visualizations’, or graphical models associated with LML:

Requirements traceability related to the requirements database, Physical models associated with

Asset entities, and Functional or Action diagrams related to the Action entity. Diagrams can also

be created by clicking the New Diagram button on the Diagrams screen shown in Figure 14, or

from within any entity (Figure 12).

Output: Action Diagram. Figure 15 shows a completed action diagram example.

Figure 15. Action Diagram Example (Innoslate, 2015)

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 20

Output: Spider Diagram. A Spider diagram can display up to nine (9) levels of

decomposition of entities used to visualize requirements traceability. The Spider Diagram is

generated based on the current project's requirements database. The entities display as rounded

blocks showing number and name of the entity; relationships create the structure displayed as

arrow lines. Figure 16 shows an example of requirements decomposition of LML entities using

the decomposed by relationship (LML Relationship Spec, 2015).

Figure 16. Spider Diagram Showing LML Traceability between Entities (LML Spec, 2015).

Output type: Documents. As shown in the logical model (Figure 2) for the MBSE

system, a variety of reports need to be created. The Menu button on the navigation screen will

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 21

display a selection of report types built into to Innoslate (Figure 17). Figure 18 shows an

example Concept of Operations (CONOPS) document generated by the system.

Figure 17. Standard Innoslate Document Formats.

Figure 18. Sample CONOPS Document Format (Innoslate, 2015).

Section 3: Project Plan

The plan for the MBSE project will fall under follow a Process-based Data Architecture

(Crain, 2015) framework to determine what information is needed to effectively execute our

business processes and map our MBSE information environment related (Figure 19).

Figure 19. Ten-step MBSE System Development Process (Crain, 2014)

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 22

Task List

A list of tasks, durations, and personnel resources needed are related to the overarching

PDA process methodology for implementing the proposed MBSE are captured in the MS Project

file for the MBSE Implementation Project. Figure 20 capture the Task Sheet from the project file.

Figure 20. MBSE Project Tasks, Duration, and Resources

Task descriptions and process map. The following sections describe how the specific

tasks map to our Process-based Data Architecture approach for developing the MBSE system.

Innoslate installation and set up and Innoslate on-site vendor training. Use of the COTS

software and LML specification provide the Application Architecture Selection, Application

Schema Development, and Application Methodology Definition solutions. Installation of the

software onto our virtual network and training on the software and systems engineering approach

are the foundation of the Shared Integration Service segment of the process.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 23

Planning. The Planning tasks, lines 4-11, support the Data Object Application

Assignment and Disparate Data Object Identification functions. During Planning, data inputs,

and their authoritative repositories will be identified, as well as necessary system outputs.

Individual systems of our SoS will be prioritized for development. The Implementation Plan

will determine what and how information needs to be captured and entered into the system, and

the Test Plan will describe how to verify the required capabilities of the MBSE system.

Input data/build prioritized database, Build required models, and Create and

download/export reports. These project tasks (lines 12-20) will Define the System of Interest

Architecture necessary to the last step of the PDA process, System Definition. These tasks

encompass all the inputs and outputs necessary to realize the MBSE project objectives.

Testing, training, demonstration, and ongoing maintenance and support. The next

project tasks (lines 21 through 28) will wrap up the project, providing the testing, training, and

management reviews necessary to fully launch the MBSE project into the mainstream business

activities of the organization and manage ongoing licensing agreements.

Additional iterative development. Once the initial MBSE development has been successfully

completed, there will begin an ongoing cycle of system definition based on the prioritized list of

systems; subsequent phases will focus on expanding the database, models, and reports (Lines 12-20).

These activities will be fall under ongoing project support for customers. Lessons learned will be

reviewed and become part of a project backlog for the ongoing development.

Cost Estimates

Table 4 shows the costs for labor resources according to the time allocated in the project

task table (Figure 20) and material needed to complete the MBSE project. The initial MBSE

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 24

phase will capture the Non-Recurring costs; additional work related to system definitions and

model building will transition into normal support activities on new and existing projects.

Table 4. Resource Allocation and Costs

Resource Name Cost

System Architect (SA) $9,047.00

Systems Engineer 1 (SE1) $19,804.74

Systems Engineer 2 (SE2) $27,260.10

Systems Engineer (SE) $1,216.00

Network Engineer 1 (NE1) $18,717.48

Project Manager $647.29

Communication Systems Engineer $15,735.60

Audio/Visual Engineer (A/V) $13,258.74

Mechanical Engineer 2 (ME2) $4,391.00

Electrical Engineer 2 (EE2) $6,359.64

Engineering Manager $3,467.10

Systems Engineering Lead $3,189.76

Information Assurance Analyst (IA) $175.84

Test $523.04

Labor Costs $123,793.33

Innoslate software 4 seats, 2 floating/2

fixed-1 year license $9,799.00

Innoslate 5-day onsite training, includes

instructor travel $19,500.00

Network Servers and Storage Upgrades $1,000.00

Material Costs $30,299.00

Projected Cost Phase 1 $ 154,092.33

Project Summary

The MBSE Project Gantt chart (Figure 21) shows the proposed timeline and assigned

resources for the project. The project has an estimated duration of 21 weeks at a labor and

material cost of $154,092. This cost includes all non-recurring activities and definition of the

system prioritized first during the planning stage. Subsequent iterations will complete the full

SoS definition under standard project support costs.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 25

Figure 21. MBSE Implementation Project Phase 1 Schedule.

MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION 26

References

Crain, R. (2014.). MBSE without a process-based data architecture is just a random set of

characters. Aerospace Conference, IEEE. Pages 1-10. doi:

10.1109/AERO.2014.6836221

Innoslate v3.4 [Computer software]. (2015). User's Guide. Retrieved from

https://docs.innoslate.com/latest/users-guide/

Lifecycle Modeling Language (LML) Specifications. (2015). Retrieved from

http://www.lifecyclemodeling.org/specification/ and

http://www.lifecyclemodeling.org/spec/LML_Relationships_Specification_1_1.pdf

VMWare, Inc. (2006). VMWare Infrastructure Architecture Overview White Paper. Retrieved

from https://www.vmware.com/pdf/vi_architecture_wp.pdf