
Ask HN: What tools and work methodology for Systems Engineering (EE) - hclalpha
As a Systems Engineer in the very narrow field of Avionics, I always ask myself how we can improve our practice, be more efficient at problem solving and be more organized in the long term as teams, as we end up supporting our products for decades. The methodology we use, Agile w&#x2F;daily Scrum, Sprints and Kanbans, are very quick at dispatching resources onto problems, which is great for quickly fixing problems that are under our code base and our ownership. However, I find it real bad at minimizing disruptions and generating the heightened levels of concentration required for big reworks. We also often have to stimulate very complex A&#x2F;C parts, black boxes if you will, with partial or delayed support from vendors. Due to this, often our work is paused for days on issues due to missing data. This disrupts the flow of our work severely and forces our company to operate in an extremely dynamic matrix-based system, which in turn drives the resources away even more when there is no urgency on an issue. Thus, we end-up shipping with very little documentation, and accumulating huge amounts of technical debts on our products. While the work can be exhilarating, all of this is very hard on personnel, not only because of the constant interruptions, but also because because they often end up having to work on very old, complex tech and&#x2F;or tech they are not the owner of. 
Any suggestions on how to improve?<p>I&#x27;m also interested at which tools are used in the industry for Systems EE. We are mainly C&#x2F;C++ based, freshly moved to git, for long term sustainability and as it seems likely to pass the test of time, with a lot of internal tools and automation strategies which are internally supported, mainly using XMLs and CSVs (Lower learning curve&#x2F;faster for some complex systems than having everyone code from scratch).<p>Thanks HN!
======
CyberFonic
Are you working in an aeronautical engineering area? From my limited knowledge
of practices at Boeing and Airbus industries, your post suggests are lack of
compliant design and documentation in terms of the many international
standards for avionics and related equipment.

My experience is in fields of instrumentation and control for electrical power
generation and transmission, and steelworks automation. The projects I have
worked on use IEEE SWEBOK and OMG SYSML as a minimum. The management have
traditional engineering background (mechanical, electrical, civil and
chemical) so design documentation is extensive and then updated to "as built"
status when commissioned. Generally we create models and perform extensive
validation and scenario testing before committing to production code.

~~~
hclalpha
We're in the very particular business of Aircraft Simulation, specifically
integrating real parts in a custom made simulation environment for pilots to
train in. The products get certified based on functionality/realism level
(Level D which requires motion/feel/view), thus we have very few low-level
documentation requirements as compared to typical Aircraft design. We do test
the platforms internally pretty correctly as they get audited by FAA/EASA
autorities before certification. In the end, however, we end-up maintaining,
updating and re-certifying the many-years-old platforms with the authorities
for pretty much the full flying life of the fleet of planes we simulate, and
for each of the updates delivered, often struggling to figure out the
architecture of our old platforms (or our competitors even, as we provide
updates for theses too).

Thanks for your input!

