Evolving the Enterprise Software Configuration Management Model

(1)

Customer Success Is Our Mission is a registered trademark of Raytheon Company.

Evolving the Enterprise

Software Configuration

Management Model

Successfully implementing DoD CM processes and requirements in an Agile/Xtreme programming development environment

Jimmy Dyer/Stacy J. Speer [email protected] [email protected]

(2)

2

Overview

 Many facets of missile design include some form of software development, each with unique development needs for

architecture, design, control and deployment

 The Engineering Product Support Directorate (EPSD) has worked to implement processes and tools to support Agile development and continual integration efforts for embedded software, firmware, test equipment and the simulations

organizations

 This presentation will provide a high-level overview of what was required in order for software configuration management (SWCM) to support Agile development and continual

integration at RMS

(3)

Raytheon Missile Systems — Who We Are

 2012 sales: 5.2 billion  11,600 employees

 Headquartered in Tucson, Ariz.  Locations:

– Arizona, Alabama, Arkansas, California, Kentucky, Oklahoma and New Mexico

 RMS designs, develops and produces missile systems for critical

requirements, including air-to-air,

strike, surface navy air defense, land combat, guided projectiles,

exoatmospheric kill vehicles, missile defense and directed energy weapons

(4)

5

The Challenge

 Agile improves the waterfall process with frequent quality checks, iterative development and better speed/quality to cost ratios

Adapting software configuration management in a changing software environment

Cost 0 +1 -1 -1 0 +1 Spe e d -1 +1 0

Enhanced Delivery Time

Missing Market Opportunities Intermittent Quality Checks

Iterative Development Improves Quality

Post-Completion Quality Check Extended Failure Recovery

Missing Market Opportunities

Quality Decreases with Speed

Agile Project Results

(5)

Typical SW Development Model

 Waterfall method

– Disciplined approach to software development

– Each phase must be complete before moving to the next

 Structured  Rigid

 Cannot test a product until the end  Progresses linearly through phases

Development teams using the typical waterfall development cycle spend considerable time and effort defining (more

accurately attempting to define) requirements upfront

Requirements

Design

Implementation

Verification

(6)

7

Agile Software Development

 Agile methods break tasks into small increments with minimal planning

 Each iteration involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing and

acceptance testing

 At the end of the iteration a working product is

demonstrated to stakeholders

 Minimizes overall risk and allows the project to adapt to changes quickly

One single goal: Deliver high-quality software to customers faster and more efficiently

Cumulative Costs

Progress

Requirements Plan

Prototype 1 Prototype 2 Operational Prototype Concept of Operation Review Release Implementation Test Integration Code Detailed Design Drafts Test Plan Verification and Validation Development Plan Verification and Validation

1. Determine Objectives 2. Identify and _{Resolved Risks}

3. Development and Test 4. Plan the Next

(7)

A Little More About Agile/Scrum

Scrum is an agile framework for completing complex projects

Selection: Sprint Planning I Decomposition: Sprint Planning II Daily Scrum Demonstration: Sprint Review Discovery: Sprint Retrospective Product Backlog Product Owner Vision Sprint Backlog Creation  Decompose the product backlog  Collaboration Review  Task updates  Progress  Roadblocks  Demonstrate the work that is done  What worked

(8)

What does this mean for traditional SWCM?

Configuration Management

(9)

Balancing

 In a Waterfall model

– Conduct software configuration control board (SCCB) once a week

– Build only major releases – Structure and orderly

– Phases and defects are easy to track

– Major events and milestones are agreed by the customer and an event (PDR, CDR, etc.)

 In a Scrum/Agile model – Work is decided at Scrum

planning meeting

 Small chunk of the backlog – Complete the sprint in 2–4

weeks

– Conduct daily stand-ups to assess how things are going – Along the way, the Scrum

master keeps the team focused on its goal

– Assess and reflect – Start all over again

– Focus is on people and creating a product — not process

(10)

11

Adapting SWCM Tools

 Adapting to Agile without compromising product integrity and/or quality

 Integrate/utilize new and existing

– IBM Rational®_{change for supporting the change management process (core)}

– IBM Rational®_{synergy for supporting the software configuration management}

process (core)

– IBM Rational Team Concert™ (RTC) for supporting the Agile development process and the collaboration among team members

IBM Rational Team Concert™

Change Management:

IBM Rational®_Change

Version Control:

(11)

SWCM Tool Use/Integration

(12)

13

SWCM Tool Use/Integration (cont.)

(13)

SWCM Tool Use/Integration (cont.)

(14)

15

Automation and Continual Integration

 Automation and continual integration are an integral part of Agile development

 Again, we must ensure that product integrity and/or quality is not compromised with the implementation of Agile

development and/or continual integration process/practices

SWCM Build Unit Test AT/FQT Test Analysis Test Report

Build request Reconfigure Conflict detect Baseline VDD/drawing (Suite of 60 tests) 43 hr (43 person-hr) 3 hr Done at developer discretion

40 hr — Manual testing covered less than 2 percent of current automated test capability

1.5 hr (0.5 person-hr) Before Continual Integration

(15)

Where does SWCM fit in Agile/SCRUM

 Sprint planning — disposition SCRs for sprint and product backlog

 Daily scrum — participation, become key member(s) of the team

 Tool support — administer and manage SWCM and Agile development tool suite used by teams

 Automation/continual integration — support automation and continual integration efforts (provide SWCM and Agile tool knowledge/expertise often enabling automation to occur)

 Build/release management — build and release all products for formal testing and/or release outside of the program area (this includes internal customer deliveries)

(16)

17

Conclusion

 Inserting SWCM into Agile/Scrum solutions can be Implemented and successful

 Takes best practices and apply to multiple software work products  Engage stakeholders and partners for successful solutions

 Standardize for commonality between programs

 Establish the standard process — minimal customization  Automate, automate, automate

 Automation improves cycle time and productivity

(17)