html5-img
1 / 41

9 August 2007

Ebor Computing. 9 August 2007. Program. Bill Cumpston Commercial Issues Andrew Robb Working with Defence. Tour. David Bryce Working in the commercial world Nick van Heeswyk Software Development. Commercial Issues. Surviving despite government support. Legal Structure. People.

lida
Télécharger la présentation

9 August 2007

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

More Related