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