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