Can you learn SysML or any other language in 3 Days?
The answer to this is probably no. However, most people can at least learn the grammatical structure and how to form sentences.
Off To A Good Start
Many system engineering customers are sold on a particular tool, and are convinced a 3-day training course in SysML will do the job. You will know how to use it, and your project will proceed without a hitch, right?
On the contrary, you will probably have an idea of what you’re trying to accomplish. But when you actually try to apply it, you will most likely need a tool expert. In fact, unless the customer is one hundred percent focused on continually trying to learn and understand the tool, this type of rollout plan is guaranteed to fail. If your organization has a dedicated person in-house who can champion SysML, and who can encourage global use within the company, chances are that person has already mastered the language by reading other books and attending training courses to really learn and apply the tools.
Know Where You Want to Go
The most effective adoption method, is when a company hires an outside consultant. After taking the training course, the mentor can look at their system and help them build their material in the language. He can show them only the pieces of the language they need in order to just get their jobs done. This also includes helping them to automate any steps they do repetitively, or to generate the right reports.
At least by starting to show the minimum sets, then yes you can learn the basics of the language in 3 days. This would be akin to learning French where, in a short period of time, you could probably figure out how to order from a menu, how to get to the bank or pharmacy, and ask where the bathroom is. But you wouldn’t be able to have a conversation with someone. This takes experience, dedication, and time working and living in the culture for months or even years.
Without the help of an expert to get teams started on the right path, most companies will do a little bit on their project. But then they will go away for three months, come back and forget what they did. This results in the tool becoming more and more convoluted and complex.
Even worse, the outcome might be going the wrong direction in the tool. In this case you might not be able to get the data or the result you are looking for out of the model because if you don’t know where you are putting the information, and later you want a report that does for example cost over time. If you didn’t put any of those figures into the model, you’re out of luck. Some people believe they could simulate the model, and I have to tell them “no you can’t because you didn’t assemble the simulation parts.”
Make It Relevant
Picking and choosing segments of the language you are going to use is similar to forming a sentence structure that you need for your project from a set of encyclopedias. In SysML you don’t use all diagrams, or all constructs. You pick the ones that best fit your needs and that’s it. Most companies come up with their own Domain Specific Language to apply to their models to help this along. This is because there are elements built into the diagrams. Practically speaking, unless you are doing embedded systems, interrupt level, task-driven, or any such specific thing, these elements are useless. They are not going to help in your definition, or in talking to the rest of your team.
One Size Doesn’t Fit All
The best technique for SysML training is to approach it from different levels. Architects who design the system should be trained more in-depth than say the consumer, who only has need for the bear minimum. There ought to be instruction on how to use the tooling on both ends of the complexity scale. Then there could also be an intermediate level for those who don’t want to learn the entire language, but can benefit from knowing a subset. Three levels of training would be ideal for SysML:
- Architect Level — There will always be a need for someone who understands inside and out, the full language of SysML. These are the people who figure out for the company how they want to use the modeling. The architect will get a picture of how to apply what they need, so they can then put data into the model. This is the standard 3-day course of a firehose of information. The architect should take this information and their knowledge of the overall company use to determine what is necessary. For example, some companies communicate primarily in sequence diagram form. These organizations discuss steps and interfaces of information in that flow, whereas others primarily use activity diagrams to show similar information, but in a different consumable way.
- User/Intermediary Level – The focus here is on those who have a good understanding of SysML. Using the architect’s knowledge of the system and what he wants to model, the user will narrow down the information. Then the system engineers can perform their jobs.
- Consumer Level — This level of training is for those who only require the basics on how to do their jobs. After we know what we’ve modeled, then we create appropriate reports and views of the data for the consumers.
Next Steps
MBSE Solutions can work with your group in all three levels, and create libraries of reusable components so you can see how the structure should be formed. We can also help generate all of the general basic diagrams. After working with several teams in a mentoring environment, almost invariably I hear the sentiment “Oh, I see! Here is an example in of what we are building in our environment. Now we can generate more!” As your guide, we can at least help you get started, making any necessary corrections along the way. You’ll be off the ground running with a conceptual knowledge of how to build just the models you need.
