David L. DrakeSAIC

drakedavid@saic.com858-826-2278

Agile Programming Experience at SAIC:Implementing Open Standards for Distributed

Simulations

Panel Presentation for Agile Programming Techniques

2

Background on SAIC

• Science Applications International Corporation (SAIC)• $6B revenue• 40,000 employees (offices in >150 cities worldwide) • Largest employee-owned high-tech company• Business areas• Criminal justice• Energy: oil, gas & utilities• Environment• Financial services• Healthcare• National security• Space• Telecommunications (including Telcordia technologies)• Transportation & logistics

3

SAIC and Process Improvement

• CMMI• SAIC is an SEI CMMI Transition Partner

– 8 engineers authorized to teach the SEI course and to provide SCAMPI appraisal services

• SAIC has organizations currently at CMMI Maturity Levels 5 and 3

• Software CMM• SAIC has organizations at SW CMM Maturity Levels 5, 4 and 3 at

more than 20 locations including the UK• My Operations Center is operating at SW CMM Maturity Level 4

• ISO 9001:2001• SAIC has more than 20 organizations operating at ISO 9001:2000• My Operations Center is one of those organizations

4

My Background and Projects

• 26 years of Software Development and 20 years of Program Management

• Largest project: Developing commercial Intrusion Detection System• $5M yearly budget• 45 engineering staff, plus marketing, sales, and product packaging

support

• Current Projects• Developing network infrastructure, particularly web services for

distributed simulations– See <www.xmsf.org> for more details

• Integrating distributed simulations into DoD web-based distance learning systems

5

Philosophy

• Sour dough starter• Organic culture has its own natural process of survival and success• My external influence: carefully measure what is added and removed• I am not fooled into believing that I can enhance the internal process• As management, know when to be “internal” or “external” to process

• Heisenberg Uncertainty Principle• The ongoing act of measuring some processes modifies them• This is true of cognizant beings that know that they are being

monitored

• Pirate ship approach• Engineers respond well to knowing:

– The goals external to projects (management strategy)– The real project goals (funding plans and management tactics)

• Engineers are then willing to do a wider range of activities

• Dr. “Patch” Adams• Better doctors are more concerned with what they give, not take• Engineers can emulate the same philosophy

6

Philosophy

• Sour dough starter• Organic culture has its own natural process of survival and success• My external influence: carefully measure what is added and removed• I am not fooled into believing that I can enhance the internal process• As management, know when to be “internal” or “external” to process

• Heisenberg Uncertainty Principle (sort of)• The ongoing act of measuring some processes modifies them• This is true of cognizant beings that know that they are being

monitored

• Pirate ship approach• Engineers respond well to knowing:

– The goals external to projects (management strategy)– The real project goals (funding plans and management tactics)

• Engineers are then willing to do a wider range of activities

• Dr. Hunter “Patch” Adams• Better doctors are more concerned with what they give, not take• Engineers can emulate the same philosophy

7

Tools Used for Extreme Programming

• Strategy: employ open source tools utilizing open standards for platform-independent software solutions

• Maintain a very low tool cost, and meet our customers’ requirements• Tools:

• Eclipse IDEs• Open source UML tool (Umbrello)• CVS for source and document control• ANT for build-per-check-in and automated metrics analysis• JUnit for test-per-build• Automated system backups for disaster recovery

• Server in the SAIC DMZ that is:• Secure distributed development environment• Project management system (utilizing TUTOS)• Public access point for the XMSF web site for keeping the distributed

simulation community at large informed

8

Extreme Programming at SAIC

XP Practice Area Used? Comments

Planning Game Partially We use formal SOWs and deliverable lists, but we involve key technical engineers in the process.

Small Releases Yes Frequent releases allow frequent customer feedback, an extremely critical feature for success.

Simple Design Yes Simple Design has allowed rapid development, but we still require good object oriented design that takes time.

Testing Yes We use automated unit testing per build, combined with automated metrics tracking.

Continuous Integration Yes We perform a complete integration build per check in for our smaller projects.

Refactoring Yes Refactoring is critical to the success of rapid prototyping. This runs counter to our standard iterative/ waterfall processes.

Pair Programming PartiallyMost of my programmers are more comfortable programming solo. Most debugging and refactoring is done as a pair process. Test code is peer reviewed using pairs.

Collective Ownership Yes Code is initially assigned to a team lead. All code can be reviewed by anyone, but modification is always advertised.

40-hour week No We believe that programming effort is sinusoidal over time. The time expended should match the creative level.

On Site Customer No Our customers rarely have the time to interact on a daily basis. We use frequent design and release meetings.

Metaphor Yes Use of a common language between customers and developers is critical.

Coding Standards Yes This is a requirement of our CMM level. Coding Standards are written and distributed.

9

Metrics Kept for Extreme Programming

• Measurable but not linked to customers’ desires/needs• Source lines of code

– Suggests that more code is better & doesn’t translate well to integration tasks• Defect count

– Assumes coders add defects rather than measuring how the code is improving– Measures what wrong with software, not what’s right with it

• Function points– Assumes a complete design up front– The truth is that the number varies throughout the development

• What we measure• Weighted software capability percentage based on customer requirements

– Weighting is based on the value to the customer, not necessarily on the complexity of the capability

• Quality of software capability as requested by customer– Customers that request rapid development often do not have quality as their highest

priority, although XP is geared to deliver it