Implement a Strategy for Transforming from Office Products to Model-Based Systems Engineering (MBSE)

Often people will ask me: “Who is your major competitor?” My usual response is “Microsoft Office.” I don’t say this because MS Office is a bad tool … it is not. It is a very good tool for publishing information. I use it often and have become quite the expert in using it to write books, papers, accounting, and presentations. But for systems engineering, it’s not the right toolset. Unfortunately, most people trying to perform SE tasks use MS Office because that’s the only tool they have. It’s cheap and already approved for use by management, but it does not provide all the capabilities SEs need. You can’t easily perform the kinds of analyses we need, such as functional analysis, simulation, requirements analysis, and risk analysis. That’s not to say that you can’t perform these kinds of analyses in the same way as your parents (or grandparents). They did it, but usually it was with armies of people. They did it with relatively simpler systems. They did it using libraries with librarians to help them find the things they needed. If you think I am exaggerating, I actually saw this in effect as late as 1986, before we had extensive implementation of personal computers.

But with the widespread availability of networked, high performance computer systems providing ready access to amazing processing capabilities, and the breadth of the worldwide web, we also have new tools that can do much more. And it’s a good thing, because at the same time this technology has caused system complexity to grow exponentially. We no longer have the “armies of people” and “librarians” available to help us do the work. So we have to do more with less.

So, let’s say your management has finally realized that you need better tools, or they just want to be “fully buzzword compliant” by jumping on the MBSE train. Now how are you going to come up to speed on a new toolset, while still continuing to meet cost and schedule?

The purpose of this paper is to help you make the shift from products like MS Office to a true MBSE tool: Innoslate®. Some of these strategies may be useful in migrating from Office to other tools, but other tools really don’t have all the features you need and when you put together the set you will have to spend a lot more on those other tools. Money being spent isn’t just the cost of the tools, but the people costs of operating them. Much like Office, even the toolsets being offered by others are really just a set of individual tools that were loosely “integrated” to provide a package. That’s why they have so many “plug-ins.”

So on with the strategies.

Strategy 1: Start Slow

Just like you can’t eat an elephant all at once (and I don’t recommend eating elephants at all!), you should migrate your information a piece at a time. For example, perhaps you have a big library of Visio diagrams and you want to reuse in Innoslate®. You might say, “well does Innoslate® have a way to import diagrams from Visio?” The answer is no. The reason we don’t is that tools like Visio are just drawing tools that don’t provide “semantic” meaning. One definition of this term is: “of, relating to, or arising from the different meanings of words or other symbols.” In other words, drawings require a significant set of rules to enable them to represent the information. An example of this from flowcharting is the use of a diamond to represent a decision or a rectangle to represent a process. Both the writer and reader of these diagrams must fully understand those representations for the chart to have any meaning. Unfortunately, with a pure drawing tool like Visio, people will use these symbols incorrectly or in different ways, which makes it difficult for the reader to really know what the writer meant. We have the same problem with unstructured words as well. Writers will use obscure words or use the words incorrectly, which interferes with the communication.

This problem is why MBSE has taken off as a concept to enhance the communications. The tools can help enforce the rules for diagrams. The diagrams can even be analyzed automatically by the computer algorithms to suggest improvements to the diagrams to make them more compliant to the rules.

So, what does this mean? It means that the diagrams as drawn in Visio are likely in error. Just moving the boxes and lines over to another tool will also bring all the errors with them. What should you do?

We recommend taking a few of the diagrams you are using right now, put them on one side of your desk (or in your second monitor, if you have one), and start a new diagram in Innoslate®. We recommend starting with the Action Diagram for a flow or process chart. You will need to interpret the information that’s on the current diagram to create the new one. You will want to take advantage of the capability in Innoslate® to decompose Actions, thus simplifying large diagrams. That allows you to identify subprocesses, which may be repeated in various parts of the diagram. In this way, you will gain a better understanding of the tool and the limitations (rules) that govern the diagrams.

 

Strategy 2: Only Start on a New Task

In this approach you keep legacy information separate or use the Innoslate® Artifact class entities to store the files from previous work, so you can find them if you need them. If you don’t have a strong requirements document from your customer (and you usually don’t), we recommend again starting with the Action Diagram and capture the current operational or business processes using that approach. The purpose of these models is to identify where the problem areas exist and then you can postulate solutions to those problems.

 

Strategy 3: Start with an Innoslate® Workshop

An Innoslate® Workshop provides a means to make learning Innoslate® easier by having our trainers work directly with your problem as the basis for the training. The training is tailored to your processes, situation (such as the phase of development), and problem so that enables the training to have greater relevance to your people. It has the added benefit of helping you get started with solving your particular problem. Don’t worry about us knowing too much about your business. We are happy to sign any appropriate non-disclosure agreements (NDAs) and our personnel have the necessary clearances to help you with your problem at any level of classification. SPEC Innovations is a woman-owned small business, so the chances of a conflict of interest is negligible.

 

Start Any Time

This in a sense is not a strategy, because it applies regardless of the situation. Timing is never perfect for moving from one way of doing things to another. The sooner you get started the sooner you can reap the benefits of MBSE. Just get in there and apply any or all of the strategies above to get started. Let us help you today. We will help you make it as painless as possible. Ben Franklin said: “There are no gains without pains.” It applies here as well. Just like starting your exercise program in the new year, the sooner you start, the sooner you feel better.

Innoslate Cloud vs. Innoslate Enterprise

This article is meant to help you determine which of these solutions is best for you and your team.

 

Innoslate is offered as a cloud or on premise solution, Innoslate Cloud and Innoslate Enterprise, respectively. It can be difficult to decide which one is right for you. We’ll take you through the pros and cons of each one to help you make this decision.

 

Innoslate Cloud

Innoslate Cloud is flexible and affordable. You can get started quickly, since there’s no download required. It’s easy to share projects with reviewers that are not Innoslate users yet. The pricing plans can be monthly or yearly, so you only have to pay for what you need. Innoslate Cloud is hosted in data centers audited for ISO 27001 and SAS70, so security isn’t a problem.

 

Pros:

Scalability through the cloud

High availability

Flexible pricing plans

Affordable pricing

No download required

 

Cons:

No floating licenses offered

Less administration controls

Less options

 

Innoslate Enterprise

Innoslate Enterprise offers scalability and collaboration beyond the cloud and behind your firewall, with the heightened security of your own server. Innoslate Enterprise is available on unclassified (U/FOUO) and classified (SECRET) level government networks through NSERC.  Innoslate Enterprise is also available on Amazon AWS Marketplace. You can choose between floating and named licensing options. You can get started within seconds on a modern server hardware. The high performance and close proximity of Innoslate Enterprise removes latencies. The server, RedHat Wildfly, implements the latest enterprise JAVA standards with full JAVA EE7 support. Wildfly runs on Windows, Mac, and Linux servers.

 

Pros:

Massive scalability (10 million entities)

Increased administration control

More availability through NSERC and AWS

Floating licensing options available

Fewer latencies

 

Cons:

Less flexibility through pricing

More expensive than Innoslate Cloud

Download required

 

Innoslate Enterprise is perfect if you need your SaaS on your organization’s server or want more administration controls through LDAP. Some organization will have to choose Innoslate Enterprise due to strict security requirements. Check with your IT department to see if you are required to use an on-premise solutions.

 

Still not sure, which solution is right for you? Give us a call at 571.485.7800.

Why We Built Innoslate – About Us

As systems engineers who had been using modeling and requirements tools for decades, we kept running into the same problem: we needed a solution that spans the entire system lifecycle. Effective requirements analysis and management requires not only capturing and managing the requirements provided by the customer, but also the analysis and decomposition of those requirements into specifications for the buying and building of the system components.

Requirement Analysis includes modeling the processes and procedures related to the requirements and simulating those processes with realistic constraints in resources, bandwidth, latencies, and many other factors. And once we have a baselined set of requirements, we have to not only “maintain” them (as they constantly change over the lifecycle), but we also have to verify that the resulting components and systems meet the requirements at every level of composition (component, subsystem, system, system of systems, etc.).

We realized what most systems engineers needed was a requirements tool, a modeling tool, a simulation tool, a verification tool, a risk tool, a program management tool, and a document management tool. None of the existing software solutions had native integration for all these different tools. The International Council on Systems Engineering (INCOSE) provides a tools interoperability working group, which includes representatives from all the major tool vendors. Unfortunately, without native integration, users experience missing data points and a drain on time and resources to integrate. It also became unreasonably expensive to purchase so many different tools and to manually integrate and manage each one.  

SPEC Innovations built Innoslate to be the all-in-one solution for systems engineer and program managers. We also wanted engineers to start analyzing overall quality of the entire project early in the lifecycle. That’s why Innoslate provides analytical capabilities like Innoslate’s Requirements Quality Checker and Intelligence View. These two internal features identify problems with the requirements and the overall model, quickly, so they can be fixed early in the process, thus saving time and money. Not only that, you get the scalability and collaboration features you need to work not only small projects, but also very large ones.

How to Make Requirements Approvals Using Innoslate

One question we often get is: does Innoslate do workflow? What people mostly mean by this question is how can they approve documents and requirements and be notified that that approval has occurred? How can we be sure the right person approved the item? Innoslate provides this capability using what we call “lightweight workflow.”

Lightweight work flow follows a simple process using the notifications, labels, history, and baselining features of Innoslate. The steps of that process are provided below.

Step 1: Setting up a signature block.

Most requirements approval occur at a document level. An example would be a standard operating procedure (SOP) for a project. The set of requirements are embedded in the SOP document. Innoslate provides templates for SOPs that can be used to develop them. You only need to access the SOP document (Menu/SOPs as seen below).

 

You can then select a blank document or the Standard Operating Procedure (With Guidelines) and the template will be produced.

In this template, there is a signature block. These can easily be separated in to separate blocks or you can break them out individually.

The screen shot below shows an example of breaking out the signature blocks. We have already added the information about the signatories of the SOP (Project Manager, Program Manager, and Division Manager).

Each manager may want to subscribe to one or more of these block for notification when it has been changed. Subscribing to an entity is easy and available from Entity View. Just select the entity and open the Entity View, as shown below.

In the Entity View of the signature of interest, select the “More” button and “Follow” the entity. The “Follow” tells Innoslate that you want to receive a notification anytime this entity is changed. When a change is made an e-mail will be sent to your e-mail address.

So, once the Project Manager approves of this entity, by adding the “Approved” label (note you may have to add this label as its not part of the standard label set), and the initials or a picture of the person’s signature can also be added at the same time, then an e-mail will be sent out to anyone subscribed to the entity. The e-mail below shows the notification I received from Innoslate.

Going back to the SOP and selecting the Project Manager entity, we see that the approved was made (see below).

The time and date of this approval and who approved it is recorded in the history of that entity, which is accessed from the Entity View using the “History” button (see below).

If you want to ensure that no changes occur elsewhere in the document after each approval, you can use the baselining feature (see the “Baseline” button at the top of the Document’s View).

This action will freeze the changes and only allow changes to the next version.

So using these techniques, Innoslate provides all you need to ensure that the requirements documents you produce follow your workflow.