What do you like best about Innoslate?
Innoslate is a tool like Cameo or DOORS that can be applied to all system development life cycle steps, including documentation, testing, and project management. One improvement that Innoslate incorporated in their software, which I have found beneficial, is the ability to quickly change system views to meet the immediate needs of a project best. The user can change from a function block diagram in a hierarchy of system decomposition to an action diagram that can demonstrate the actual functional process to help determine if the current concept is sound or if further development is required to satisfy functional or performance-based requirements. Innoslate takes full advantage of being built with application programming interfaces (API) that make use of both a native test environment with the tool that allows for constant testing and verification of existing process models. The tool also allows users to integrate other validation tools/models like MATLAB and Systems Tool Kit external to the tool.
Innoslate offers several models to represent functional flow block diagrams, such as Activity,
IDEF(0), and Action diagrams. The FFBDs below followed the Action diagram model. One useful tool
that can be performed with the Action diagram to help identify issues in functional flow is that time,
date and units can be added to each block (action), then any part of the model can be run through
either as a discrete or Monte Carlo simulation, considering any added variables. Review collected by and hosted on G2.com.
What do you dislike about Innoslate?
Some aspects of Innoslate that cause frustration and wasted time stem from the lack of detailed
formattings, such as the inability to increase text font sizes in a diagram, which is not a significant issue for
small diagrams but makes producing more extensive system and subsystem-level views nearly pointless.
The tool also fails to export otherwise standard and uniform table data, such as traceability matrices and risks.
This is due to how Innoslate treats associations amongst objects, which for any data table or diagram
uses a strict hierarchical relationship and does not permit mixing different classes.
For example, exporting physical elements cannot be set up to have element A connected by interface B which connects
to element C because A & C belong to the Asset class and B belongs to the Conduit class. Edge cases like
this becomes commonplace and adds a lot of post-export manual effort, which increases exponentially
as projects proceed to more granular levels and cross reference matrices became multiple pages in
length.
Available instruction is also lacking. I've attended numerous live sessions that SPEC hosts. I find that they never really dive into actual use cases and do not address the problems or shortcomings experienced by actual users, using arbitrary and very high-level examples. I've been requesting improvements on the font sizes available for years, and it's always the same excuse that it's a complex issue. Something written in HTML, JavaScript, and CSS should not be that challenging to address, given that I can do so on my own in a web browser's console on their website.
Lastly, the customer I work for isn't going to log into Innoslate to inspect diagrams or reports. They want them in MS Word, PowerPoint, or an online Wiki like Confluence. In Innoslate, they use a single formatting template when exporting documents of models that take a lot of time to fix on the exporting backend.
Innoslate would be a better product if they incorporated React and Redux into the online tool Review collected by and hosted on G2.com.
