9 august 2007
DESCRIPTION
Ebor Computing. 9 August 2007. Program. Bill CumpstonCommercial Issues Andrew RobbWorking with Defence. Tour. David BryceWorking in the commercial world Nick van HeeswykSoftware Development. Commercial Issues. Surviving despite government support. Legal Structure. People. - PowerPoint PPT PresentationTRANSCRIPT
9 August 2007
Ebor Computing
Program
David Bryce Working in the commercial world
Nick van Heeswyk Software Development
Bill Cumpston Commercial Issues
Andrew Robb Working with Defence
Tour
Commercial IssuesSurviving despite government support
Legal Structure
People
For Defence clearance
Must be an Australian citizen
Must have a background checkable for the past 10 years
Graduates — computer science, mathematics, science …
Don’t expect graduates to be ‘work ready’
Generally look for
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
Service v Product
+
_
Service
SmartMove taxi dispatching system
MedFePS fee-for-service payments to doctorsProduct
Where does the work come from?
Defence Materiel Organisation (DMO)
Defence Science and Technology Organisation (DSTO)
Research and development support
Typical contract is 3 to 9 months for 1 to 2 people
Product
Typical contract is 1 to 3 years for 5 to 10 people.
Royal College of Pathologists Quality Assurance Programme
Requirements
Requirements
Cashflow
Reliability
Fault diagnosis
Evolution
Driven by sales
Conclusions
Big bang solutions don’t work
Reliability, but people will tolerate faults
No single answer
Can’t survive on handouts
The Defence WorldFeeding hungry Software Engineers with
crumbs from Dr Nelson’s table
Large
Reasonably homogeneous
Very process driven
Currently REALLY BIG on schedule: ‘Schedule is King’
Defence Materiel 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
Defence Science & Technology Organisation
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!
Getting work
Getting the client’s attention
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 into contract
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
Requirements, requirements, requirements!
Developed in reviews/Captured in documents
ISO/IEC12207
MIL-STD-498 (obsolete)
Standards for Development of Software-Based Systems
Requirements Traceability Matrix
Verification Cross Reference Matrix
Functional and Physical Configuration Audits
Functional Performance (Test & Evaluation outcomes)
Management
Negotiating a contract
Typically they will want to own it all, but it is negotiable
Intellectual property
This is their main exposure to excusable delay
GFE (Government Furnished Equipment)
CCPs, follow-on support
Emergent work rates
30 days minimum, look out for review process delays
Deliverables and payment schedules
‘Prime Contractors’, sub-contractors, DSTO (in DMO contracts)
Third parties
Concept Demonstrator, FSED, production
Multiple Stages vs Multiple Tenders
Schedule is king
System Requirements Review
Preliminary Design Review
Detailed Design Review
System Engineering progression
Configuration Audits
Factory Release Testing
Acceptance Testing
T&E progression
Audit schedule & execution
Q&A progression
Effective Date
Routine Progress Reviews
Project Completion
Project management progression
Schedule is king
Stage 3 Schedule Summary
Build 1 Build 2 Build 3 FRT Dry Runs
Build 4FRT
System Review and Stage 3 Review
AustraliaDay
Easter
System at 203L
Internal Design Review #2
Sep Oct FebNov Dec Jan Mar MayApr Jun Jul Aug
2005 2006
Detailed Design Review
Christmas Break
Anzac Day
Acceptance Testing
Early Hardware
Long Lead Hardware
Main Hardware
Stage 4 C
han
ges ?
Stage 3 Schedule Summary
Build 1 Build 2 Build 3 FRT Dry Runs
Build 4FRT
System Review and Stage 3 Review
AustraliaDay
Easter
System at 203L
Internal Design Review #2
Sep Oct FebNov Dec Jan Mar MayApr Jun Jul Aug
2005 2006Sep Oct FebNov Dec Jan Mar MayApr Jun Jul Aug
2005 2006
Detailed Design Review
Christmas Break
Anzac Day
Acceptance Testing
Early Hardware
Long Lead Hardware
Main Hardware
Stage 4 C
han
ges ?
Business operating processes
ISO 9000 series. Quality Management Systems
Capability Maturity Model Integration (CMMI)
Quality assurance
Scheduling and Effort Tracking
Microsoft Project, worker time sheets etc
Documentation & Drawings
Microsoft Office, AutoCAD compatible vs esoteric (eg. *tex)
Data Item Descriptions (DIDs )
Project management & paperwork
Company baseline
Contract by contract: be adaptable
Requirement for processes and standards
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’
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
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
The Commercial WorldYou want it when?
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
RCPA
RCPA — Project overview
Web based reporting and data entry
RCPA — Project overview
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
RCPA — Statement of work
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!
RCPA — Client expectations
Automated Regression Testing
RCPA — Quality and peace of mind
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
RCPA — Design methodology
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
RCPA — Secrets of success
Software developmentYou want process? We got process!
Autonomous
User driven
Interactive
Interface with other systems (including hardware).
Part of larger system working interacting with other software components
All of the above
What kind of software systems might you develop?
Software development
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
Software development — coding standards
Software development — development model
Preferred method by defence.
Simple
Requires less knowledge from customer.
Easier to track.
Changes are slow.
Process orientated.
Waterfall
Used in concept demonstrators.
Fast feedback.
Requires more discipline.
Harder to track time.
People and communication over process.
Iterative & Agile (XP, Scrum)
Software development — development model
Software development — requirements and design
Obtain customer requirements
Derive into software requirements
Traceability to design and test
Requirements
Interface (eg. User, Network)
Data stores (eg. Files, Database, Memory)
Communication Protocols
Structure
Dependencies
UML and NetBeans GUI Designer
Design
Checked into Revision Control.
Baselined at milestones.
Must compile before committed.
Expected that people thoroughly test
Code
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.
Software development — training and deployment
Installation
Usage (may need full working system)
Maintenance
Troubleshooting
Training
Manual install
Install wizard
Pre-installed on supplied hardware
Ghost
Automatic updates
Upgrade (backwards compatibility)
Deployment
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
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
Questions