![\"GettyImages-1050482460.jpg\"](\"http:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/6\/2019\/09\/GettyImages-1050482460-2.jpg\" "\\"GettyImages-1050482460.jpg\\"")
<\/span>You have probably heard this analogy already. Let me explain for those who haven’t. The game Jenga involves removing one block at a time from a tower constructed of 54 blocks. Each block removed is then placed on top of the tower, creating a progressively taller and unstable structure until someone’s misstep (either on removing a block or on placing it unsteadily on top of the destabilizing structure) leads to it crashing down.<\/SPAN><\/P><\/p>\nThis to me is the perfect analogy for complex embedded software development projects. The interesting thing to notice is that many embedded software projects seem to go through the Jenga game lifecycle. Changes are easy at first in both cases but become increasingly difficult and risky as the game or project goes on and your structure (your Jenga tower or project code base) becomes cumbersome.<\/SPAN><\/P><\/p>\n Now for sure, both the Jenga and embedded software project cannot be compared one-on-one. One is just a game while the other finds its use in sophisticated electronics items, automobiles, and what not, where instability or crashing down can mean breaching a thin line between life-death, profit-loss and in effect survival of the company itself.<\/SPAN><\/P><\/p>\n So, how can you keep your software ecosystem healthy, without too many “uh-oh, I messed up!” moments before the whole software stack collapses like a game of Jenga? <\/SPAN><\/P><\/p>\n The answer to the above is to architect <\/STRONG>your software in order to visualize<\/STRONG>, frontload<\/STRONG> and analyze,<\/STRONG> before you start writing your first line of code.<\/P><\/p>\n Visualize<\/STRONG>.<\/P> Again visualize! requirements, specifications, compatibility lists, test requirements, advisories, etc. Do not just look for changes in the product itself, but also for changes to parameters, APIs or peripheral components (input\/output). A logical drawing (software architecture) of your software product helps: visualize which systems talk with other systems, both horizontally and vertically. Break-down your complexity and create nested hierarchy of software architecture. Frontload<\/STRONG>. <\/P> As soon as you find the ideal combination of software subsystems and systems, create an even enriched architecture out of it. Contracts <\/A>can help: it is a lightweight and adaptable framework for specifying requirements or specification on top of architecture elements in form of executable test cases. You can tailor it to your specific needs and capabilities. Analyze<\/STRONG>.<\/P> Once you have the enriched architecture, you will need to test the architecture for compatibility and completeness. Check proper decomposition of the embedded software system architecture at the design stage through assume-guarantee analysis.<\/P><\/p>\n The assume-guarantee analysis is a horizontal as-well-as vertical compatibility check among the data-flow blocks connected in an architecture. The analysis works totally on top of the enriched architecture, thus this analysis can be performed very early in the design and identify potential compatibility issues long before any implementation is started. <\/P> Now before you start your next game of Jenga (wait, I mean your software project), make use of the visualize, frontload and analyze<\/STRONG> principle<\/STRONG> in your software development approach. It helps make your design right the first time by meeting the timing and budget constraints. Architecture analysis with the help of contract helps detect design errors and to perform virtual integration scenario before the first line of code is written.<\/P><\/p>\n
\n![\"visualise.png\"](\"http:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/6\/2019\/09\/visualise-1.png\" "\\"visualise.png\\"")
<\/span><\/P><\/p>\n
\n![\"contract.png\"](\"http:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/6\/2019\/09\/contract-1.png\" "\\"contract.png\\"")
<\/span>You don’t need to enrich all of the architecture components before you can reap the benefits: you can pick the components you like. Some components in your architecture could need careful specification. For example, iEVtemperatureControl<\/EM> in the above example. Others can be more loosely specified.<\/P><\/p>\n
\n
\n![\"analyse.png\"](\"http:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/6\/2019\/09\/analyse-1.png\" "\\"analyse.png\\"")
<\/span><\/P><\/p>\n