Pen Settings

HTML

CSS

CSS Base

Vendor Prefixing

Add External Stylesheets/Pens

Any URL's added here will be added as <link>s in order, and before the CSS in the editor. You can use the CSS from another Pen by using it's URL and the proper URL extention.

+ add another resource

JavaScript

Babel includes JSX processing.

Add External Scripts/Pens

Any URL's added here will be added as <script>s in order, and run before the JavaScript in the editor. You can use the URL of any other Pen and it will include the JavaScript from that Pen.

+ add another resource

Packages

Add Packages

Search for and use JavaScript packages from npm here. By selecting a package, an import statement will be added to the top of the JavaScript editor for this package.

Behavior

Save Automatically?

If active, Pens will autosave every 30 seconds after being saved once.

Auto-Updating Preview

If enabled, the preview panel updates automatically as you code. If disabled, use the "Run" button to update.

Format on Save

If enabled, your code will be formatted when you actively save your Pen. Note: your code becomes un-folded during formatting.

Editor Settings

Code Indentation

Want to change your Syntax Highlighting theme, Fonts and more?

Visit your global Editor Settings.

HTML

              
                <!DOCTYPE html>
<html lang="en">
<head>
	<title> System Design Documentation</title>
	<meta charset= "utf-8">
	<link rel="stylesheet" type="text/css" href="css/mystyles.css">
</head>
<body>
<nav id="navbar">
  <h1>System Design Documentation</h1>
  <ul> 
	<li><a class="nav-link" href="#Introduction">Introduction</a></li>
    <li><a class="nav-link" href="#Purpose">Purpose</a></li>
    <li><a class="nav-link" href="#System_Overview">System Overview</a></li>
    <li><a class="nav-link" href="#Design_Constraints">Design Constraints</a></li>
    <li><a class="nav-link" href="#Roles_and_Responsibilities">Roles and Responsibilities</a></li>
    <li><a class="nav-link" href="#Project_Referencess">Project References</a></li>
    <li><a class="nav-link" href="#System_Architecture">System Architecture</a></li>
    <li><a class="nav-link" href="#Database_Design">Database Design</a></li>
    <li><a class="nav-link" href="#Hardware_and_Software_Detailed_Design">Hardware and Software Detailed Design</a></li> 
	<li><a class="nav-link" href="#System_Security_and_Integrity_Controls">System Security and Integrity Controls</a></li> 
  </ul>
</nav>
<main id="main-doc">
  <section class="main-section" id="Introduction">
    <h2>Introduction</h2>
      <p>This System Design Document has been created to outline the proposed system design for new MOSHE38 Corporation Maintenance Management System (MMS). The MMS is intended to replace the legacy maintenance tracking system currently used by MOSHE38 Corp. By designing, testing, and deploying the MMS, MOSHE38 Corp. will improve its capabilities in maintenance management, tracking, and reporting. This document and the technical specifications listed herein comply with all  Corp. technical standards and infrastructure.      </p>
  </section>
	
  <section class="main-section" id="Purpose">
    <h2>Purpose</h2>

      <p>The purpose of this System Design Document is to provide a description for how the new MMS will be constructed. The Systems Design Document was created to ensure that the MMS design meets the requirements specified in the MMS project requirements documentation as well as the MOSHE38 Corporation's Executive Bulletin referencing improvements to existing maintenance management practices and tools. The System Design Document provides a description of the system architecture, software, hardware, database design, and security.</p>
   
    </section>
  <section class="main-section" id="System_Overview">
    <h2>System Overview</h2>
   
    <p>MOSHE38 Corporation has historically faced many challenges and shortcomings in managing fleet maintenance metrics, tracking, and reporting. The proposed MMS tool will utilize existing MOSHE38 infrastructure and hardware to provide an enterprise tool which will standardize and improve the efficiency of MOSHE38's maintenance management capabilities.</p>

<p>The MMS is designed as an enterprise software tool which is compatible with and leverages existing MOSHE38 hardware and infrastructure. Additionally, MMS is compliant with all internal MOSHE38 Corporation network security protocols and policies as well as industry regulatory policies.</p>

<p>The MMS tool is also compatible with existing MOSHE38 software suites to include MS Office applications and SharePoint, as well as SAP. The MMS tool will provide various user interfaces which will allow data entry, updates, tracking, and report generation. It will also allow users to export data to various existing software tools like MS Excel and SharePoint for various uses.</p>

<p>One of the primary benefits of the MMS tool over the legacy system is its ability to consolidate all maintenance data and generate real-time reports and analysis of fleet status, problem areas, chronic maintenance problems, and various other metrics. Until now MOSHE38 Corp. has relied upon legacy software with various reporting and data constraints and limited user interfaces which has resulted in poor reporting, tracking, and management as well as a general lack of continuity among the users.
</p>

<p>The new MMS tool will provide the following capabilities:</P>
	<ul>
		<li>Pre-designed automated reporting at various time intervals as well as manually generated reports</li>
		<li>Integration of all maintenance data which allows for real-time report generation and simplifies management of all maintenance activities</li>
		<li>Enhanced and additional user interfaces which provide users with much simpler data entry, updates, queries, and other capabilities</li>
		<li>Data export capabilities which allow users to export data to various software tools for simplified reporting and presentation capability</li>
	</ul>

    </section>
  <section class="main-section" id="Design_Constraints">
    <h2>Design Constraints</h2>

<P>
	The MMS Project Team identified several constraints which will impact and limit the design of the tool. These constraints are beyond the scope of the MMS Project but must be carefully factored into the system design. To date, the following constraints have been identified:
</P>	
<ol>
	<li> MMS must be compatible with existing MOSHE38 Corp. infrastructure to include network tools and applications, security requirements, server capabilities, and network management hardware. This constraints will impact the design because the team must ensure the MMS coding and formats meet the capabilities of the infrastructure will limit the MMS in certain areas—although the capabilities will still far exceed those of the legacy maintenance management system.</li>
	<li> MMS must comply with all MOSHE38 Corp. and industry regulatory policies and guidelines. These policies and guidelines will impact the tool by requiring certain standards of coding, user interfaces, security, and management of the tool.</li>
	<li> The MMS tool must be compatible with existing user software suites. This will require the team to design and code the MMS in a manner in which data can be seamlessly imported and exported between the MMS and existing software tools.</li>
</ol>
    
    </section>
  <section class="main-section" id="Roles_and_Responsibilities">
    <h2>Roles and Responsibilities</h2>
	
    <p>
		You use variables as symbolic names for values in your application. The names of variables, called identifiers, conform to certain rules.
    </p>
	
	<p>
		A JavaScript identifier must start with a letter, underscore (_), or dollar sign ($); subsequent characters can also be digits (0-9). Because JavaScript is case sensitive, letters include the characters "A" through "Z" (uppercase) and the characters "a" through "z" (lowercase).
    </p>
  
  </section>
  <section class="main-section" id="Project_References">
    <h2>Project References</h2>
    
      <p>
      The MMS tool is designed in accordance with several organizational guidelines, standards, analyses, and findings. These references serve as the basis for the requirement of a new maintenance management system. The following is a list of references. It should be noted that some of these documents are periodically updated and if more detailed information is needed, they should be referred to individually.
      </p>
			<ul>
				<li> MOSHE38 Corp. IT Security Policies and Guidelines, October 10, 2015</li>
				<li> MOSHE38 Corp. Hardware and Software Catalog, June 2, 2015</li>
				<li> MOSHE38 Corp. Program Management Office (PMO) Policies and Guidelines February 7, 2015</li>
				<li> MOSHE38 Corp. Legacy Maintenance Management White Paper July 8, 2015</li>
				<li> MOSHE38 Corp. 2015 Strategic Goals and Objectives December 27, 2015</li>
				<li> MOSHE38 Corp. 2015 Network Architecture Guidelines January 3, 20xx</li>
				<li> MOSHE38 Corp. 2015 Network Architecture Design Document, January 2, 2015</li>
			</ul>
    
    </section>
  <section class="main-section" id="System_Architecture">
    <h2>System Architecture</h2>

	<h3>Hardware:</h3>
     <p>The MMS design is based on existing hardware architecture already deployed across the MOSHE38 Corp. enterprise. This hardware consists of the following components:</p>
	<ul>
		<li> ABC Quadrant Server Array consisting of <br/>
			- 8GHz Server Suite <br/>
			- RAM: 16 GB Fully Buffered <br/>
			- Array Controller <br/>
			- 4x 80GB 15,000 RPM Hard Drive <br/>
			- 4x Giga Network Adapters</li>
		<li> Cisco CSS 11500 Content Services Switch series</li>
		<li>4 TB SAN Storage Devices</li>
		<li> Dell P3000 Workstations</li>
	</ul>
	
		<h3>Software:</h3>
		<p>The MMS design is based on the individual design of various components in which users will enter and query data. The software architecture is designed to incorporate all data entries and modifications into an integrated database which tracks maintenance data in real-time as it’s manipulated. The components which comprise the software architecture include:</p>
	<ul>
		<li> User Data Entry Module: This component provides the user interfaces for all maintenance data entry. This component consists of several sub-components to include: <br/>
		- New System Data  <br/>
		- Existing System Maintenance Updates  <br/>
		- System Location Updates  <br/>
		- System History</li>
		<li> Automated Reporting Module: This component provides all of the pre-built automated reporting capabilities. These are reports that are generated regularly and repetitively at known intervals.</li>
		<li> Manual Reporting Module: This component provides a list of all searchable fields in which the user can create a report as the need arises</li>
	</ul>		

    </section>
  <section class="main-section" id="Database_Design">
    <h2> Database Design</h2>
    
<p>The MMS tool will incorporate existing maintenance data in the legacy database into a new enhanced database with additional capabilities such as searchable and sortable fields and various enhanced reporting functions. The MMS database will also have the capability of importing and exporting data from/to MS Office applications.</p>

<p>Structured data stored in the database will be searchable and sortable in order to meet both automated and manual reporting requirements. As such, the database field names are consistent with all fields built into the User Data Entry Module, Automated Reporting Module, and Manual Reporting Module.</p>

<p>Additional fields have also been added to the MMS database to include:</p>
<ul>
	<li>Coordinates (lat./long.) of assets in the fleet</li>
	<li>Property management fields to capture and update personnel responsible for various assets</li>
	<li>Fault category identification to provide greater visibility into maintenance failures</li>
</ul>	
<p>Additional technical specifications of the database design can be found in the MSS database management system (DBMS) addendum to the Project Plan.</p>
   </section>
  <section class="main-section" id="Hardware_and_Software_Detailed_Design">
    <h2>Hardware and Software Detailed Design</h2>
    
	<h3>Hardware:</h3>
<p>The MMS solution leverages existing MOSHE38 Corp. hardware architecture and design. No additional hardware design is required for the MMS. Existing hardware detailed design can be found in the MOSHE38 Corp. 2015 Network Architecture Design Document, dated January 2, 2015.</p>

    <h3>Software:</h3>
<p>The MMS software design is coded by MOSHE38 Corp. IT Engineers to provide customized functionality specific to the operations of MOSHE38 Corp. It was determined through various analyses and studies that there is not an existing commercial-off-the-shelf (COTS) product with the ability to capture specific business operations unique to MOSHE38 Corp. As such, detailed requirements were gathered from the legacy maintenance system’s user population and these requirements were used to develop the concept for the MMS design. The concept was then broken down into modules in order to segregate and compartmentalize various functionality.</p>

<p>User Data Entry Module: Several partitions are coded into the User Data Entry Module depending on the type of maintenance transaction the user seeks to perform. These partitions help ensure users enter the appropriate sub-module (listed below) for their data entry activities.</p>

<ul>
	<li>New System Data – This sub-module is coded to contain specific fields required for entering new assets/equipment into the database for the first time.</li>
	<li>Existing System Maintenance Updates – This sub-module is coded to contain specific fields required for adding, removing, or editing data which already exists in the maintenance database</li>
	<li>System Location Updates – This sub-module is coded to contain fields specific to geographic locations to include site, city, state, zip code, latitude, and longitude. As assets/equipment are relocated, this sub-module allows users to update locations accordingly</li>
	<li>System History – This sub-module is coded to contain fields specific for reference past maintenance activities. Coding includes various search fields by location, serial number, part number, or asset/equipment type</li>
</ul>

<p>
	Automated Reporting Module: This module includes coding which provides users with a selection of pre-built automated reports. The coding allows the user to select a report and uses this input to initiate a pre-built database query to pull the appropriate data from the data base in response to the user’s selection.
</p>
<p>
	Manual Reporting Module: This module includes coding which provides users the ability to modify various reporting criteria such as search dates, locations, sites, systems, and serial numbers. These user inputs then initiate the database query to execute the desired search algorithm.
</p>
    </section>
  <section class="main-section" id="System_Security_and_Integrity_Controls">
    <h2>System Security and Integrity Controls</h2>
      <p>The MMS tool design incorporates several security and integrity controls to ensure that the system and its data are continually protected. This is done through a multi-tiered approach to ensuring data integrity is achieved through only authorized user functions and assignments.</p>
	  
	  <p>The first design consideration is user authorization or permissions. All MMS users will be assigned an authorization level and permissions within which they will operate. These users will be unable to perform any MMS transactions outside of their assigned areas. Managers will provide authorization levels and operating boundaries for each of their assigned users.</p>
	  
	  <p>The next design consideration is to establish control points. As the MMS is a network tool, firewalls will be placed to partition the functions each group within MOSHE38 Corp. is able to perform within the MMS. The purpose of this is to reinforce assigned work areas, permissions, and access with physical barriers to prevent any duplication, unintentional changes, or malicious changes of maintenance data.</p>
	  
	  <p>The next design consideration is to establish control points. As the MMS is a network tool, firewalls will be placed to partition the functions each group within MOSHE38 Corp. is able to perform within the MMS. The purpose of this is to reinforce assigned work areas, permissions, and access with physical barriers to prevent any duplication, unintentional changes, or malicious changes of maintenance data.</p>
	  
	  <p>The MMS design also incorporates an audit trail capability not available in the legacy maintenance system. This capability will allow MOSHE38 Corp. IT personnel to track the history of all MMS users in order to provide history, error identification, and accountability for system users.</p>
	  
	  <p>The next design consideration is data backup. The MMS database will be backed up in accordance with MOSHE38 Corp. IT Security Policies and Guidelines dated Oct. 10, 20xx. This will provide a fail-over capability to revert to in the event of a database corruption or system failure. The MMS was also designed to perform in degraded modes of operation should maintenance need to be performed on a particular module.</p>
	  
	  <p>MOSHE38 Corp.’s IT group will also have the capability, in the event of a catastrophic system failure, to revert back to the legacy system until such time that the MMS system can be restored.</p>
    </section>
    <footer>
		<small> Copyright 2019 || DESIGNED BY     MOSHE</small>
	</footer>
</main>
</body>
</html>
              
            
!

CSS

              
                html,body{
  min-width:290px;
    color: #4d4e53;
    background-color: #0b0c10;
    font-family: 'Open Sans',Arial,sans-serif;
    line-height: 1.5;
}
#navbar{
  position:fixed;
  min-width:290px;
  top:0px;
  left:0px;
  width:300px;
  height:100%;
  border-right:solid;
  border-color:#45a29e;
  background-color: #1f2833;
}
header{
  color:#45a29e;
  font-size: 30px;
  margin:10px;
  text-align:center;
  font-size:1.8em;
  font-weight:thin;
}

h1{
  color:#45a29e;
  font-size: 30px;
  margin:10px;
  text-align:center;
  font-size:1.8em;
  font-weight:thin;
}

h3{
	color:#45a29e;
}

#main-doc h2{
  color:#45a29e;
  font-size: 30px;
  text-align:left;
  margin:0px;
  font-size: 30px;
}
#navbar ul{
  height:88%;
  overflow-y:auto;
  overflow-x:hidden;
}
#navbar li{
  color: #66fcf1;
  border:1px solid;
  border-bottom-width:0px;
  padding:8px;
  padding-left:45px;
  list-style: none;
  position:relative;
  left:-50px;
  width:100%;
}

#navbar li:hover{
		left: 2%;
		transform: scale(1);
		transition: all .2s ease-in-out;
		color: orangered;
}

#navbar a{
	color: #66fcf1;
    text-decoration:none;
    cursor:pointer;
} 

#navbar a:hover{
	color: orangered;
} 

#main-doc{
  position: absolute;
  margin-left:310px;
  padding:20px;
  margin-bottom:110px;
}
section {
  color: #c5c6c7;
  margin:15px;
  font-size:0.96em;
}
section li {
  margin:15px 0px 0px 20px;
}

footer{
	color: #45a29e;
	text-align: center;
	padding-top: 20px;
}

@media only screen and (max-width: 815px) {
    /* For mobile phones: */
  #navbar ul{
	border:1px solid;
    height:207px;
  }
    #navbar{
      background-color:black;
      position:absolute;
      top:0;
      padding:0;
      margin: 0;
      width:100%;
      max-height:275px;
      border:none;
      z-index:1;
      border-bottom:2px solid;
    }
  #main-doc{
    position: relative;
    margin-left:0px;
    margin-top:270px;
  }
  
  #main-doc header{
	 padding-top: 60px;
}
  
  #main-doc section {
/*     padding-top: 240px; */
  }
}
@media only screen and (max-width: 400px) {
  #main-doc{
    margin-left:-10px;
  }
  #main-doc h2{
	 padding-top: 60px;
}
 
}
              
            
!

JS

              
                
              
            
!
999px

Console