Ebor Computing Presentation

nationmattedΛογισμικό & κατασκευή λογ/κού

10 Νοε 2012 (πριν από 4 χρόνια και 7 μήνες)

350 εμφανίσεις

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 Issues

Surviving 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 doctors

Product

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 World

Feeding 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 4
FRT
System Review and
Stage 3 Review
Australia
Day
Easter
System at 203L
Internal Design Review #2
Sep
Oct
Feb
Nov
Dec
Jan
Mar
May
Apr
Jun
Jul
Aug
2005
2006
Detailed Design Review
Christmas
Break
Anzac Day
Acceptance
Testing
Early
Hardware
Long Lead
Hardware
Main
Hardware
Stage 4 Changes ?
Stage 3 Schedule Summary
Build 1
Build 2
Build 3
FRT Dry Runs
Build 4
FRT
System Review and
Stage 3 Review
Australia
Day
Easter
System at 203L
Internal Design Review #2
Sep
Oct
Feb
Nov
Dec
Jan
Mar
May
Apr
Jun
Jul
Aug
2005
2006
Sep
Oct
Feb
Nov
Dec
Jan
Mar
May
Apr
Jun
Jul
Aug
2005
2006
Detailed Design Review
Christmas
Break
Anzac Day
Acceptance
Testing
Early
Hardware
Long Lead
Hardware
Main
Hardware
Stage 4 Changes ?
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 World

You 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 development

You 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