Two Case Studies

Download Report

Transcript Two Case Studies

Two Case Studies

• CCPDS-R, TRW • How Microsoft Builds Software • Different development environments • Software development life cycle • Software project management techniques

CCPDS-R Case Study

• Command Center Processing and Display System – Replacement • TRW Space and Defense in Redondo Beach, CA • Customer : U.S. Air Force • Focus : Common Subsystem • Mission critical software

Common Subsystem

• Primary missile warning system • Main installation : Cheyenne Mountain • Backup system : Offutt Air Force Base, Nebraska • 48-month software development schedule • 355,000 SLOC • Ada : design & implementation language • 6 builds were required • Completed successfully, on time within budget to customer satisfaction

CCPDS-R Acquisition

• Concept definition (CD), 12-month schedule • 5 major bidders, 2 contracts awarded • Full-scale development (FSD) • 1 contract awarded to TRW • Contract award based on performance in Software Engineering Exercise

Concept Definition (CD)

• Vision • Analyze and specify the project requirements • Define and develop the top-level architecture • Plan FSD phase software development activities • Configure the process and development environment • Establish trust and win-win relationships among the stakeholders • Software engineering exercise

Process Overview for FSD

• Standard DOD life cycle after contract award • Software requirements review (SRR) • Interim preliminary design review (IPDR) • Preliminary design review (PDR) • Critical design review (CDR) • Final qualification test (FQT)

Incremental Design Process

• Individual milestones within a build • Preliminary design walkthrough • Critical design walkthrough • Code walkthrough • Turnover review

Incremental Test Process

• Stand-alone test • Build integration test; establish a stable, reliable baseline • Reliability test • Engineering string test • Final qualification test

IPDR Demonstration

• Demonstrate defined capabilities at NORAD • Capabilities well understood by the customer and TRW • 37 evaluation criteria • Results were apt to change requirements, plans and designs • 31 satisfactory, 6 were not met • Required redesign and re-demonstration

Metrics

• Build Progress (% coded) vs time • Requirements verified vs time • Cumulative SLOC vs time • Average hours per software change order (SCO) • Mean time between failure (MTBF) vs total test hours • Cumulative SLOC vs budget

People factors

• Core team concept • Leverage skills of a few experts across the entire team • Avoid attrition • Profit sharing of award fees

Microsoft Case Study

• High volume, mass market software • Redmond, Washington • Excel, Word, Windows 95, Windows NT, etc.

• Respond to events in the marketplace • Highly flexible, entrepreneurial company

Microsoft Competitive Strategy

• Identify mass markets quickly • Introduce products that are “good enough” • Improve products by incrementally evolving their features • Sell multiple product versions and upgrades • Sell globally

Product Development Philosophy

• Utilize small parallel teams (3 to 8 developers) • Teams evolve features and products incrementally • Occasionally introduce new concepts and technologies • Synchronize changes frequently so product components work together • Structured hacker-like approach

Synch-and-Stabilize

• Continually synchronize what developers are doing as individuals and team members • Stabilize the product in increments • Daily build • Continual testing • Testers work in parallel with developers (1 to 1) • Fix defect immediately if checked in code “breaks” the daily build

Big Picture Procedures

• Teams work at single physical site • Common development languages (C and C++) • Common coding styles • Standardized development tools • Teams must communicate, debate design ideas, and resolve problems face to face

Synch-and-Stabilize Development Approach

• Planning Phase • Development Phase • Stabilization Phase

Planning Phase

• Vision statement • Product managers define goals for a new product based on market research • Specification document written up by Program manager • During development, feature set in specification document may change by 30% or more • Schedule and feature team formation

Development Phase

• Developers design, code, and debug • Testers pair with developers for continuous testing • 3 major milestones • Milestone 1 : first 1/3 of features (most critical and shared components) • Milestone 2 : second third of features • Milestone 3 : final third of features (least critical)

Stabilization Phase

• Internal testing • External testing (“beta” sites and users) • Release preparation

Principles – Developing and Shipping Products

• Work in parallel teams but “synch up” and debug daily • Always have a product you can ship, with versions for different platforms and markets • Speak a “common language” on a single development site • Continuously test the product as you build it • Use metric data to determine milestone completion and product release

Conclusions

• Stakeholders and type of software being developed effect the software development life cycle • CCPDS-R - more externally controlled process • Microsoft – market driven – internally controlled process geared towards customer satisfaction and market share • Both cases illustrate extensive use of modern software project management techniques • Both cases show level 3 (defined) of CMM