Transcript Presentation - University of Adelaide

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
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
Service v Product
Paid by the hour
‘time and materials’ or ‘cost plus’
Service
_
Paid to produce something
No continuity
Own the product
Product
Need to persuade people to buy it
+
More profitable if successful
Where does the work come from?
Defence Science and Technology Organisation (DSTO)
Research and development support
Service
Typical contract is 3 to 9 months for 1 to 2 people
Defence Materiel Organisation (DMO)
Product
Typical contract is 1 to 3 years for 5 to 10 people.
Royal College of Pathologists Quality Assurance Programme
Product
SmartMove taxi dispatching system
MedFePS fee-for-service payments to doctors
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 World
Feeding hungry Software Engineers with
crumbs from Dr Nelson’s table
Defence Materiel Organisation
Large
Reasonably homogeneous
Very process driven
Currently REALLY BIG on schedule: ‘Schedule is King’
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
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!
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
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)
Negotiating a contract
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
Schedule is king
System Engineering progression
System Requirements Review
Preliminary Design Review
Detailed Design Review
T&E progression
Configuration Audits
Factory Release Testing
Acceptance Testing
Q&A progression
Audit schedule & execution
Project management progression
Effective Date
Routine Progress Reviews
Project Completion
Schedule is king
Stage 3 Schedule Summary
2005
Sep
Oct
2006
Nov
Dec
Christmas
Break
Jan
Feb
Mar
Australia
Day
Apr
Easter
May
Jun
Jul
Aug
Anzac Day
Acceptance
Testing
Build 1
Build 2
Build 4
FRT
System at 203L
Early
Hardware
Long Lead
Hardware
Internal Design Review #2
Main
Hardware
Detailed Design Review
System Review and
Stage 3 Review
Stage 4 Changes ?
Build 3
FRT Dry Runs
Business operating processes
Quality assurance
ISO 9000 series. Quality Management Systems
Capability Maturity Model Integration (CMMI)
Project management & paperwork
Scheduling and Effort Tracking
Microsoft Project, worker time sheets etc
Documentation & Drawings
Microsoft Office, AutoCAD compatible vs esoteric (eg. *tex)
Data Item Descriptions (DIDs )
Requirement for processes and standards
Company baseline
Contract by contract: be adaptable
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 World
You want it when?
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
RCPA — Project overview
RCPA — Project overview
Web based reporting and data entry
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
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!
RCPA — Quality and peace of mind
Automated Regression Testing
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
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
Software development
You want process? We got process!
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
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
Software development — development model
Waterfall
Preferred method by defence.
Simple
Requires less knowledge from customer.
Easier to track.
Changes are slow.
Process orientated.
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
Software development — requirements and design
Requirements
Obtain customer requirements
Derive into software requirements
Traceability to design and test
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 — 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
Training
Installation
Usage (may need full working system)
Maintenance
Troubleshooting
Deployment
Manual install
Install wizard
Pre-installed on supplied hardware
Ghost
Automatic updates
Upgrade (backwards compatibility)
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