His research was a product of his times when programming/coding was considered a clerical job with the real brain work being done by System Analysts and System Designers who produced System Requirements Specification Documents and System Design Specification Documents. He was the first to show that software development costs would outstrip hardware development costs and the importance of its Risk Management through a Spiral Model. He brought "big picture" engineering process lens to the management of software development which became "Software Engineering" today.
All of these ideas are still valid though they would need to be modified for current times given the decades of experience we have had since then. Software development at the Individual level involves creativity/art/craft/individual flair and companies must acknowledge and provide means for expression of these psychological needs. OTOH, Software development at the Company level is all about Risk Management in the service of its Business Goals and hence needs a reproducible process and associated methodologies. We need to find a balance between the two.
I agree that risk management is important for software companies, in the same way it is for construction companies, and part of that involves software engineers.
But I think pretty much any business has risk management processes that involve domain knowledge, and a much larger and more distinctive part of any kind of engineering involves non-business considerations and tradeoffs that AFAIK Boehm didn’t really concern himself with. For example, a civil engineer designing a bridge is thinking about wind shear, traffic volume, vehicle weight allowances, and so on, just as a software engineer is thinking about latency, throughput, error propagation, and so on. To me, these sort of non-business-logic but very much domain-specific considerations are what comprise the core of software engineering (as compared to programming, which I would classify as just getting the business logic correct without any meta-considerations).
This comment is poorly edited, but essentially Boehm’s processes to me are better described as “software business management” than “software engineering”.
Agreed, though IMO "Software Engineering" subsumes everything. You are looking for a holistic and reproducible process which can be communicated using well defined methodologies.
One important point though; IMO Risk Management in the Software Industry is qualitatively different than that from other Industries. This is because of the greater play and importance of Human Factors involved and their cumulative non-linear effects. In very few other industries (eg. Finance) can you have a factor of 10x/100x productivity between the average and the best since it does not follow the normal distribution. If i have a Jeff Dean/John Carmack programming or a Steve Jobs salesmanship in my company i can break every engineering rule i want and still come out on top.
Nassim Taleb's ideas on Mediocristan/Extremistan, Power Laws/Fat Tails are all relevant here. Here is a great video explaining these concepts (though we have to adapt and apply it to Software Engineering) : Pareto, Power Laws, and Fat Tails - https://www.youtube.com/watch?v=Wcqt49dXtm8
His research was a product of his times when programming/coding was considered a clerical job with the real brain work being done by System Analysts and System Designers who produced System Requirements Specification Documents and System Design Specification Documents. He was the first to show that software development costs would outstrip hardware development costs and the importance of its Risk Management through a Spiral Model. He brought "big picture" engineering process lens to the management of software development which became "Software Engineering" today.
All of these ideas are still valid though they would need to be modified for current times given the decades of experience we have had since then. Software development at the Individual level involves creativity/art/craft/individual flair and companies must acknowledge and provide means for expression of these psychological needs. OTOH, Software development at the Company level is all about Risk Management in the service of its Business Goals and hence needs a reproducible process and associated methodologies. We need to find a balance between the two.