The Engineering Context

1. The Engineering Context Advanced Maritime Anti-Missile Radar Technology Geoff Patch Software Engineering Manager - CEA Technologies

2. Or rather, My Engineering Context, and how it compares to others.

8. The CEA Solution - Software Defined Active Electronically Scanned Phased Array Radar

11. Software Defined - • 44 PowerPC based embedded Controllers • 500,000+ lines of C++ • 400+ person years of effort expended over multiple technology generations since 1996 • Over 2000 large Altera Field Programmable Gate Arrays • If you’re standing still, you’re dying. The next generation technology is under development today.

12. How Does it Work?

15. 6 Radars Operating Simultaneously!

16. System Configuration • Communications • Built-in Test, Status Aggregation and Reporting • Advanced Doppler Signal Processing • Target Detection, Tracking and Illumination • Post Fire Evaluation • Data Logging and Retrieval

17. Numerous Awards • 2011 Engineers Australia Engineering Excellence Award • 2011 ADM Essington-Lewis Trophy for large defence project management…and again in 2014! • Head of DMO reported to the Senate on 19-Oct-11 “…this system is a world beating system developed here in Australia. This is the best military system we have designed and built in Australia since a system we called Ikara, which was in the 1960s and 1970s.”

18. So what does it all look like in practice?

19. The High Reliability, High Performance, Realtime, Deeply Embedded Software Context.

20. Our success is absolutely dependent on developing and maintaining a system level perspective

21. For example…the ship system consists of subsystems: • Hull • Machinery • Combat Management • Sensors • Weapons • Communications

22. In developing our software we must consider many other aspects of the system: • Compensation for ownship motion • Weapon characteristics • EMI/EMC • RADHAZ • Combat Management System comms bandwidth • Etc…

23. Advice from a Grumpy Old Man

24. Only work with the best. Engineering is a human activity. It is much more about people than technology. Your success or failure will be determined by the quality of your people, not the speed of your compiler or the features provided by your debugger.

25. Good staff are necessary, but not sufficient. People require management. They need to be happy. They need to be motivated, led in the right direction and rewarded for their efforts. The best people, provided with the best tools and the best working environment will fail (guaranteed) if they are poorly managed and poorly led.

26. Get your requirements right. If you don’t know what you want to build, then what you build will not be what you want. Requirement errors are the most expensive to fix after delivery

27. Choose your development methodology carefully. For example, Agile techniques are a perfect fit for certain classes of problem. They are a terrible fit for other classes of problems. One size does not fit all. Choose a methodology appropriate to the nature of your problem

28. Have Processes.

29. Good processes are the key to good Software Engineering. Process won’t guarantee success, but lack of process will vastly increase your chances of failure

30. Without a disciplined, process driven approach to your engineering you will not be able to produce high quality products in a reliable, consistent and repeatable manner, and you shouldn’t be calling yourself an engineer. Maintaining correct process weight is critical. Too little process results in chaos. Too much process hinders development velocity.

31. Continuously review and improve your processes in order to adapt to changing circumstances and maintain correct process weight.

32. Perform peer and management reviews at all stages of the development process. You can’t find your own defects. Up front design reviews, and regular code inspections provide great ROI, and are a key driver of product quality.

33. Adopt or Develop Standards

34. Internal Standards • Code Formatting • Code Commenting • Standard coding techniques • Forbidden coding techniques – “GOTO Considered Harmful” • If you do something frequently then develop a Standard Operating Procedure for doing it. • Don’t waste intellectual effort on deciding where to put your curly brackets. Standardise such issues, and concentrate on algorithms and data structures.

35. External Standards • ISO 12207 Software Life Cycle Processes is the baseline software development standard called out in the DMO ASDEFCON contracting templates. • It provides detailed advice about what is involved in engineering software. Note…what, not how. • If you want to work in the Defence software space, or a lot of other places, then you should be familiar with this standard. • If you apply for an engineering position at CEA we will ask you about this standard.

36. External Standards • ISO 9001 Quality Management Systems • A standard about implementing processes • The process bible for most high quality business. Over a million ISO 9001 certified organisations worldwide. • Mandatory for doing business with the Department of Defence, and many other government organisations

37. The only thing we learn from history is that we don’t learn from history.

38. Learn from the experience of others. I recommend: • Fred Brooks • The Mythical Man Month • No Silver Bullet – Incidents and Accidents of Software Engineering • Robert L. Glass • Facts and Fallacies of Software Engineering