9 August 2007

1. Ebor Computing 9 August 2007

2. Program • Bill Cumpston Commercial Issues • Andrew Robb Working with Defence Tour • David Bryce Working in the commercial world • Nick van Heeswyk Software Development

3. Commercial Issues Surviving despite government support

4. Legal Structure

5. People Generally look for • Graduates — computer science, mathematics, science … • Don’t expect graduates to be ‘work ready’ For Defence clearance • Must be an Australian citizen • Must have a background checkable for the past 10 years

6. Service v Product • Paid by the hour‘time and materials’ or ‘cost plus’ • Paid to produce something • No continuity Service _ • Own the product • Need to persuade people to buy it • More profitable if successful Product +

7. Where does the work come from? Defence Science and Technology Organisation (DSTO) • Research and development support • Typical contract is 3 to 9 months for 1 to 2 people Service Defence Materiel Organisation (DMO) • Product • Typical contract is 1 to 3 years for 5 to 10 people. Royal College of Pathologists Quality Assurance Programme • SmartMove taxi dispatching system • MedFePS fee-for-service payments to doctors Product

8. Requirements • Requirements • Cashflow • Reliability • Fault diagnosis • Evolution • Driven by sales

9. Conclusions • Big bang solutions don’t work • Reliability, but people will tolerate faults • No single answer • Can’t survive on handouts

10. The Defence World Feeding hungry Software Engineers with crumbs from Dr Nelson’s table

11. Defence Materiel Organisation • Large • Reasonably homogeneous • Very process driven • Currently REALLY BIG on schedule: ‘Schedule is King’

12. Defence Science & Technology Organisation • Moderately large • Non-homogeneous • Less process driven than DMO • Jobs range from “bodies” to finished applications, but all there as tools for their research

13. Getting into contract • ASDEFCON (RFTs etc.) • Strategic Material, Complex Material (High/Low Risk), Support, Services, Standing Offers for Goods/Services • Preferred tender >> contract negotiation • Be vigilant for scope creep and risk-shifting Getting work Getting the client’s attention • Informal discussions through personal contact • Unsolicited proposals • ROI, RFT/RFQ (Open, Confined, Sole Source) • Gazette (AusTender “Approach To Market”) • Conferences, Tradeshows & general marketing • (Contract Change Proposals) • RETURN BUSINESS!

14. Requirements, requirements, requirements! Standards for Development of Software-Based Systems • ISO/IEC12207 • MIL-STD-498 (obsolete) Developed in reviews/Captured in documents • System Requirements Review, Preliminary Design Review, Detailed Design Review • Concept of Operations, Functional Outline (tender), Functional Requirements Document, System/Subsystem Specifications, Module and Interface Specifications Management • Requirements Traceability Matrix • Verification Cross Reference Matrix • Functional and Physical Configuration Audits • Functional Performance (Test & Evaluation outcomes)

15. Intellectual property • Typically they will want to own it all, but it is negotiable GFE (Government Furnished Equipment) • This is their main exposure to excusable delay Emergent work rates • CCPs, follow-on support Deliverables and payment schedules • 30 days minimum, look out for review process delays Third parties • ‘Prime Contractors’, sub-contractors, DSTO (in DMO contracts) Multiple Stages vs Multiple Tenders • Concept Demonstrator, FSED, production Negotiating a contract

16. System Engineering progression T&E progression Q&A progression Project management progression • System Requirements Review • Preliminary Design Review • Detailed Design Review • Configuration Audits • Factory Release Testing • Acceptance Testing • Audit schedule & execution • Effective Date • Routine Progress Reviews • Project Completion Schedule is king

17. Schedule is king

18. Quality assurance Project management & paperwork Requirement for processes and standards • ISO 9000 series. Quality Management Systems • Capability Maturity Model Integration (CMMI) • Scheduling and Effort Tracking • Microsoft Project, worker time sheets etc • Documentation & Drawings • Microsoft Office, AutoCAD compatible vs esoteric (eg. *tex) • Data Item Descriptions (DIDs ) • Company baseline • Contract by contract: be adaptable Business operating processes

19. Military software-based systems evolution • Specialised Military Hardware >> COTS • Windows vs Non Windows (e.g. Linux), Linux vs Unix • General Purpose vs Specialised & Embedded Processing e.g. ASIC, DSP, FPGA, custom processing boards • Analog to Digital • ‘Tech Refresh’ vs software upgrades • Physical & IT security issues • ‘System Integrators’

20. Feast and famine • Extended periods of waiting, with occasional development of “proposals” and “outlines”, usually at no cost to the client • Tender process and subsequent contract will want to be started “yesterday, if possible” • Follow on work is never guaranteed • Defence requirements change, even in a defined project • People move on, and their position gapped for extended periods • So: • Pay attention to getting the next job(s) • If possible, have some diversity and manage the overlaps

21. Ebor and Defence • ‘Meet their expectations’ • Listen a lot, be up front (esp. with problems) & never bullshit • Mutual trust • Expectations are not necessarily what is in the contract! • Customer satisfaction (client happy) >> return business (Ebor happy) • DSTO substantially different to DMO • ‘flexibility’ of task scope • Levels of documentation

22. The Commercial World You want it when?

23. RCPA • Royal College of Pathologists Australia Quality Assurance Programs • Provides external quality assurance programs for laboratories across all 10 disciplines of pathology. • Clients include over 1000 laboratories • 30% of clients are international

24. RCPA — Project overview

25. RCPA — Project overview • Web based reporting and data entry

26. RCPA — Statement of work • Gather requirements from the relevant stakeholders • Provide a statement of work and corresponding estimate for that work • The scope and requirements are going to change • Phased feedback and demos

27. RCPA — Client expectations • Quality and reliability • Ability to interpret their needs • Cost effectiveness • Deliver projects on budget and on time • Quick delivery on important requirements • Some of these are mutually exclusive!

28. RCPA — Quality and peace of mind • Automated Regression Testing

29. RCPA — Design methodology • Iterative Design – The clients are often still experimenting with their needs • Balance between the need for an up front estimate and evolving requirements • Regular feedback as progress is made • Ensure that new features can be used by other disciplines as needed

30. RCPA — Secrets of success • Good relationship with the clients – knowing how to interpret their needs • Responding quickly to problems or requirements when needed • Delivering quality and reliability to give them a world class system

31. Software development You want process? We got process!

32. Software development What kind of software systems might you develop? • Autonomous • User driven • Interactive • Interface with other systems (including hardware). • Part of larger system working interacting with other software components • All of the above

33. Software development — coding standards • Can be a source of great debate • Typically follow the convention with modern languages (Java/C#) • Strive for clarity (optimise when necessary) • Well commented • Debug logging (Log4j) • Error handling (catch {}!) • Use known design patterns where possible

34. Iterative & Agile (XP, Scrum) • Used in concept demonstrators. • Fast feedback. • Requires more discipline. • Harder to track time. • People and communication over process. Software development — development model Waterfall • Preferred method by defence. • Simple • Requires less knowledge from customer. • Easier to track. • Changes are slow. • Process orientated.

35. Software development — development model

36. Design • Interface (eg. User, Network) • Data stores (eg. Files, Database, Memory) • Communication Protocols • Structure • Dependencies • UML and NetBeans GUI Designer Code • Checked into Revision Control. • Baselined at milestones. • Must compile before committed. • Expected that people thoroughly test Software development — requirements and design Requirements • Obtain customer requirements • Derive into software requirements • Traceability to design and test

37. Software development — testing • Unit Testing (JUnit). • Code Review. • Static and Run-time analysis. • Play Testing • Stress Testing and TPMs • Simulators • Performance (Memory, CPU, Disk) • Formal Testing • Every requirement must be tested at least once. • Formal procedure. • Formal test report. • Results submitted to customer. • Often forms part of formal milestone ($$). • Real and virtual test beds.

38. Deployment • Manual install • Install wizard • Pre-installed on supplied hardware • Ghost • Automatic updates • Upgrade (backwards compatibility) Software development — training and deployment Training • Installation • Usage (may need full working system) • Maintenance • Troubleshooting

39. Software development — task allocation • Team Leader identifies a parcel of work (design, code, review, investigate, test) • Add task to the tracking system • Description • Component • References to Requirements and Design • Priority • Time Code • Engineer receives email with task • Engineer implements with communication with TL and other Team Members as necessary • Task is resolved • Team Leader or another Engineer reviews changes made and accepts or rejects task • Executing test case • Code review • Inspection • If rejected task bounces back to the Engineer, otherwise it is closed

40. Software development — tools • NetBeans, Eclipse, Visual Studio Pro • Revision Control (Subversion) • Text Editor (UltraEdit) • DOORs • VMWare • Ant • Task and Bug Tracking Software • Microsoft Office • Microsoft Visio

41. Questions