What is our primary use case?
It's now called Cameo Enterprise Architect 19. It is my system engineering tool.
I do systems engineering. If you go to my website, www.simtrs.com, there are simulation and training for this solution. You will see the benefits of MagicDraw and how I use it.
I use it for systems engineering and life cycle systems engineering, and even for deployment. The beauty of MagicDraw is that it has a simulation part, so you can simulate your model to validate it. The simulation allows you to bring in code off of an external code that you can write to set up the simulation and execute the code.
What is most valuable?
We are getting away from the old ways of writing a lot of papers and requirements documents, architecture documents, technical solution documents, interface documents - those days are gone. MagicDraw allows you to model the requirements and by doing so, you've got a good chance of not missing any requirements. The old way of doing things was to decompose the requirements into shell statements.
But when you model it, you will be able to practically make sure you don't miss anything. MagicDraw has a good modeling tool you use for case diagrams. Its use case diagram is part of the UML and SysML that you can use to model requirements to create an architecture. I've created a lot of architectures for the Army and also mapped those components of the architecture as the test procedures.
What needs improvement?
I wouldn't say anything negative about No Magic MagicDraw. But there is a steep learning curve. The steep learning curve applies to two things - system engineering and INCOSE. INCOSE, I-N-C-O-S-E international systems engineering. INCOSE is what most people use today for system engineering, for building systems, and deploying and maintaining them in a full life cycle. For MagicDraw there is a steep learning curve if you don't have the system engineering domain experience because a lot of folks go in there and say, "Okay, I'm going to do model-based system engineering." MagicDraw has a model-based system engineering tool but it only allows you to draw the diagram or the model. Then you need to understand the relationships between the processes and activities.
So some people can pick it up, but it's a steep learning curve. You have to do the correct keystrokes to portray what it is you're really trying to do. You take a picture, an ER diagram, Entity Relationship diagram, which is a diagram that shows all the components and how they relate to each other, not just an arrow. You can say this component influences another component or another component enables integration, etc... Things like that. You have to know what your relationships are and MagicDraw allows you to do that really well.
But they do provide manuals. They have a lot of manuals that you can go through for each plug-in they have. You have the system engineering piece, and then you have the DoDAAC, which is the DOD architecture. They use what they call a UPDM, that's a DoDAAC standard. You also have the UAF. System Ellis is the base for everything, but you've got other pieces for the government first. When working for the government, they require that you do your architecture using the DoDAAC. So it has the DoDAAC too, because the government likes certain things. It depends on who your customer is and what they want.
For the next releases, I would like to have them import requirements from other sources. They could make it very easy to do that because there are a lot requirements management tools like DOORS, D-O-O-R-S, Dynamic Object Oriented Management. A lot of folks use DOORS to create a requirement. For those requirements you allocate them to a component in the architecture and a verification method for that requirement. It would be good if we could import those into MagicDraw as components so you don't have to manually do these things.
For how long have I used the solution?
I have been using No Magic MagicDraw for about 10 years.
What do I think about the scalability of the solution?
The way MagicDraw scales is very good. You have the team server which allows a lot of people to use the product for a specific path. I can create different pieces because you don't want to have hundreds of sheets of the same model. Imagine you're flying a plane and you come over a city and see the view from 10,000 feet. But then as you come down you come into more details. When you're on the ground you'll be going to a bathroom, for example. If you want a model of the bathroom you've got to be able to set it up.
MagicDraw will scale that way, but someone has to be able to set it up to give you that granularity. You can get the bird's eye view or you can get the pie in the sky. It's like you are in an aircraft. You can see the city, but as you come down lower, you see the cars start running on the freeways. And as you get lower, you can see the toll booths and the gas stations. That is how it scales, but you have to have the ingenuity to be able to model it so that you can flip from model to model, which it allows. But it would be nice if I could have hyperlinks in there, where I could take the big model, click and see, just like you see Google Earth.
As you click it further up and down, it gets bigger and smaller and smaller and smaller until you get down to the very house that you live in. It'd be nice if they add hyperlinks or something like that so your customer wouldn't have to be an expert in MagicDraw. Because the way it is now, I have to import it to JPEG's or to files and organize it in such a way that it would take me a lot of time to describe what an architecture is. This is especially true for large systems. For small systems it's not a problem but for large systems it can be. For example, if you want to draw an architectural automobile, you start with the basics. But then when you start drilling down into the engine and the carburetor and all those different things, it can get very hairy. So you've got to be able to organize it in such a way and that capability isn't there. You have to do that manually.
What other advice do I have?
On a scale of one to ten, I would give No Magic MagicDraw a nine.
Overall I find it very effective and the customers are happy with it.
Which deployment model are you using for this solution?