[solution] »

I need to create a warehouse management system.

There are three parts to the project: Requi

Brief item decscription

Answer Download

Item details:

I need to create a warehouse management system.

There are three parts to the project: Requirements Analysis, System and Database Design, and Project Plan. The complete instructions are attached along with an example.

Please do not take this on if you cannot complete it. I don?t want to waste your time or mine.

Thanks

Running head: MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION Research Project: Model-Based Systems Engineering Implementation

 

(Name and date withheld) 1 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

 

2. 3 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. Specifications and

 

Reports Information

 

Assurance Model

 

Views Customers

 

Specifications and

 

Reports Model Views Requirements/

 

Artifacts

 

Material/Components Reports Model Views Material

 

Tracking Engineering

 

Specifications and

 

Reports MBSE

 

System Project

 

Management Test Documents Model

 

Views Verification/

 

Validation 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 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 Engineering Establish Project 1.0 Requirements/Artifacts Import/Enter

 

Requirements 7 D2

 

Requirements Requirements

 

Statements Customer/

 

Project Information Equipment Requirements Project

 

Management

 

D1

 

Customer /

 

Project

 

Information Material

 

Tracking 2.0

 

Input/Update

 

Materials List Project

 

BOM D3

 

Material

 

Components Material/

 

Components Material by System 3.0 System Requirements Equipment List Build/Update

 

Database

 

D4

 

System

 

Descriptions System

 

Descriptions Model

 

Views Systems and Relationships 4.0

 

Customer/Project Specifications

 

and

 

Reports Systems Information for

 

Testing Select Model

 

Views

 

Model

 

Views Information Sets Model Views Verification/

 

Validation

 

5.0

 

Create Reports

 

and

 

Specifications

 

Specifications and

 

Reports Information

 

Assurance Customers Figure 2. Logical Data Flow Diagram MODEL-BASED SYSTEMS ENGINEERING IMPLEMENTATION

 

5.0 8 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

 

Project Bill of Materials with

 

Material Components

 

Costs

 

Material Changes

 

Material Tracking

 

Materials by System

 

Materials by System

 

Project Bill of Material

 

3.0 Build/Update Database

 

Material by System

 

Material by System

 

Equipment List

 

System Descriptions

 

System Requirements

 

Systems and Relationships

 

System Descriptions

 

4.0 Select Model Views

 

System and Relationships

 

Project Information Sets

 

Systems Information for Testing

 

Model Views

 

5.0 Create Reports and

 

Project Information Sets

 

Specifications and Reports

 

Specifications

 

Customer/Project data

 

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.

 

A customer has 1toM

 

projects A project has many

 

requirements generates CUSTOMER Requirements describe

 

many systems lists PROJECT

 

generated

 

by Identifies REQUIREMENTS

 

describe Has Systems have many

 

requirements MATERIAL Belongs to

 

Has Material can be part

 

of many systems MATERIALSYSTEM SYSTEMREQUIREMENT Has Define Built from SYSTEM

 

Builds Systems have many

 

parts/material Figure 3. MBSE Entity-Relationship Diagram 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 bidirectionality 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

 

Read Only

 

Read/Write

 

Owner Description

 

View project contents only, add and remove your own

 

comments, unable to share project.

 

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

 

comments, unable to share project.

 

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 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. 16 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 D...

 

Notice: Undefined index: payment_status in /home/aceyourh/studycourse.fun/wp-content/themes/premier/page-templates/paper-detail.php on line 248





About this question: