Ask HN: What tools and work methodology for Systems Engineering (EE)
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/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/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/or tech they are not the owner of. Any suggestions on how to improve?
I'm also interested at which tools are used in the industry for Systems EE. We are mainly C/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/faster for some complex systems than having everyone code from scratch).
Thanks HN! 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. 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! Do you work as instrument engineer in power plant industry? I'm not quite sure what kind of project that you have to use IEEE SWEBOK?