In my 25 years of engineering, I could have used different aspects of it in any program. It is a large tool, and it is pretty versatile, but it can be overly complicated at times. So, having a good frame of reference and a direction is helpful. The tool itself isn't going to guide you on the best practices and best decisions, but there are many different best practices out there.

It is a good tool. I would rate it a solid seven out of ten.

I'd rate the solution nine out of ten. I know there are some little nuisances here and there. Still, it works. I've had good success with it. It's got a lot of capability. It's just a little pricey. On the market right now, there is a lot of software out there that's pretty pricey, and many out there that are a lot more expensive. Like ARIS, for example.

I would definitely recommend using the solution. Overall, I would rate it a nine out of ten. 

I would tell potential users to do extensive research on model-based system engineering and its related aspects. They should probably get some training because that's the only way to understand the product's potential fully.

On a scale from one to ten, I would give No Magic MagicDraw a nine.

Magic Draw has capabilities that I'm sure I haven't even touched on, but at least for what I'm attempting to achieve, it provides the most capability to meet my needs at this point in time.

I rate No Magic MagicDraw a nine out of ten.

Before you start implementing No Magic MagicDraw, I would definitely recommend that you look at other solutions. You could take a look at Sparks and compare both Sparks and MagicDraw before you proceed with MagicDraw.

I recommend this solution to others.

I rate No Magic MagicDraw an eight out of ten.

The most important factors of success when introducing the tool into your project organization:

1. Get someone who really knows it, can teach it, can configure it to your needs (method & tool expert)!

2. Get someone who really knows your model(s) and amends it frequently by refactoring the contents (librarian, may be the same person(s) as above)!

3. Do not wait half a year or even longer until your method is finished, it never will! Start the very first day, reserve 20-40% of 1. and 2. to iterate your method in an agile way. Start with the concepts you need first.

And don't forget to publish your content to your most frequently used channels like your project file share, Sharepoint, web server so that all project team members can consume your knowledge even if they cannot or do not want to use the tool.

Produce tables with elements from your models (diagrams) as input for project management, test management, migration management, whatever management!

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.

My advice to anybody who is designing complex projects, like defense projects or space projects, is that they have to use this program or one like it. All of the stakeholders have to understand that they need to review the product using models, in addition to the documents. Following this will ensure that it is very easy to understand the product that is being designed. 

I would rate this solution a nine out of ten.

I am a sole proprietor consultant and I work within teams that are a mix of contractors and government employees. Also, I am an adjunct professor.

My advice goes back to the 80/20 rule. There is 20% of the basic fundamental capabilities that you will get you 80% of what you need or more.

My advice is to have a standard framework for a model within the enterprise. In terms of a standard hierarchy structure, know where you put the requirements or the logical architecture. Also, know how it changes depending on whether you are dealing with a system or with a system's assistance. The system's assistance depends on whether you have a directed governance environment or a federal, or coalition of the willing.

Because of the issues, I am experiencing with the OMG, I would rate this solution a five out of ten.

I would rate this solution a seven out of ten.

I would rate MagicDraw a nine out of ten because of the price. Enterprise Architect has a lot of bugs and MagicDraw is a lot more accurate and flexible. It's a level better. 

I would advise someone considering this solution to do a proof of concept. Ensure that your engineers have the training, not just in the tool, but also in the languages they're going to use.

I would rate it an eight out of ten.