1 / 37

Concentrate on the Big Things

Concentrate on the Big Things. Geoff Patch Software Engineering Manager - CEA Technologies. CEA History and Capability. My History and Capability. Missiles - Bigger, Badder , Faster. The CEA Solution - Software Defined Active Electronically Scanned Phased Array Radar. Software Defined -

zea
Télécharger la présentation

Concentrate on the Big Things

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Concentrate on the Big Things Geoff Patch Software Engineering Manager - CEA Technologies

  2. CEA History and Capability

  3. My History and Capability

  4. Missiles - Bigger, Badder, Faster

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

  6. Software Defined - • 44 PowerPC based embedded Controllers • 500,000+ lines of C++ • 300+ 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.

  7. How Does it Work

  8. 6 Radars Operating Simultaneously!

  9. 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

  10. Numerous Awards • 2011 Engineers Australia Engineering Excellence Award • 2011 ADM Essington Lewis Trophy for large defence project management • 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.”

  11. I have considerable experience in the development of very large software intensive distributed systems

  12. Things that have worked for me

  13. 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.

  14. 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.

  15. 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

  16. Be careful about the application of Agile development methodologies. 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

  17. Have Processes.

  18. 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

  19. 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. Maintaining correct process weight is critical. Too little process results in chaos. Too much process hinders development velocity.

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

  21. 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.

  22. Adopt or Develop Standards

  23. 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.

  24. 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.

  25. External Standards • ISO 15288 System Engineering – System Life Cycle Processes • Shares the ISO 12207 philosophy and terminology • Read it in conjunction with ISO/IEC TR 19760 Systems Engineering – A guide for the application of ISO/IEC 15288

  26. 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

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

  28. 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

More Related