This was the prompt of a small assignment in my software engineering course. At first, I was skeptical of such a trivial assignment, but it actually captivated my attention and helped me reflect on an important work experience. What this question is really about is understanding the responsibilities and expectations of the professionals and their work in this industry. And that, is no trivial matter.
Though I’m not able to fully answer this question yet, what I have thus far lies in an experience I had in my short time at Northrop Grumman and in a textbook.
I had the opportunity to get to know about other projects at the Northrop facility. One of them was digitalization of the cockpit for the UH-60L Black Hawk helicopter (UH-60V).[2] Developing software that controls the flight of military aircraft requires adherence to strict guidelines and regulations, namely DO-178B. For this reason, the software developers on the UH-60V team don’t do any programming, at least not in the way computer science students instinctively think about programming. They use Model-Based (or Model-Driven) Development and the SCADE software suite. For users of SCADE, their models are their documentation (at least one form of it) and their code. SCADE generates code using the developed models and the code it generates is certified to be DO-178B Level A.[3] “The levels are defined in term of the potential consequence of an undetected error in the software certified at this level.” [4] And Level A means, if there is an error in the code, there is more than likely a “catastrophic” outcome.[4]
There are many industries that software is developed for, each with its own set of regulations that need to be followed, some more strict than others. Developing software to keep aircraft in the sky has some of the strictest regulations. “Software Engineering” in this sub-industry means almost zero hand-written code. I don’t think projects are prohibited from coding, but the hoops that must be jumped through to prove that the code is error free and meets DO-178B Level A standards makes it financially impractical to introduce coding. With SCADE and Model-Based Development, they can provide the level of quality that is expected by the customer and do so on budget.
As a kid straight out of school, this was foreign to me. It didn’t look anything like the software engineering I’d seen. But I got to know people on that team and they shipped great software.
In his book, Software Engineering: A Practitioner’s Approach, Roger Pressman describes the realities and challenges of software in the twenty-first century before defining software engineering. Below are the summaries of those challenges and their takeaways [1]:
- Software is now in such high demand that there are many forces pushing and pulling the direction of a project. “We need to understand the problem before building a solution”.
- The requirements demanded by customers becomes more and more complex each year. “Design is a pivotal activity”.
- More people and organizations are relying on software and to a higher degree than ever before. “Software should exhibit high quality”.
- Software projects can see long term growth in their user base and increased demands in their capabilities. “Software should be maintainable”.
Pressman began with the challenges we will face developing software to prevail upon us that software projects won’t succeed on accident. Software will need to be ENGINEERED.[1] He puts an emphasis on the verb engineering. Pressman uses the diagram below to highlight the importance of various aspects of software engineering.[1]
The foundation of software engineering, Pressman teaches, is a focus on quality. A focus on quality, dictates the processes, methods, and tools that we’ll use to reach that standard of quality. And what’s better, if our focus is building quality software, then over time we’ll iterate and develop better processes, methods, and tools than what we already have.
So why did the Black Hawk team’s version of software engineering look so different from my preconceived notions? Because all I saw were their processes, methods, and tools. And if I’m being totally honest, all I really saw were their tools. What I didn’t see was the massive part of the iceberg hidden underneath the surface of the water: their processes and definition of quality. If you start with a focus on quality, then everything else can be great software engineering.
References:
- “Software and Software Engineering.” Software Engineering: A Practitioner’s Approach, by Roger S. Pressman, 7th ed., McGraw Hill, 2010, pp. 12–16.
- “UH-60V Black Hawk Integrated Mission Equipment Package.” Northrop Grumman, www.northropgrumman.com/what-we-do/air/uh-60v-black-hawk-integrated-mission-equipment-package/.
- “SCADE Suite: Integrated Model-Based Design & Development Environment.” Ansys, www.ansys.com/products/embedded-software/ansys-scade-suite.
- “Airborne Software Certification Explained.” Open, www.open-do.org/about/software-certification-101/.