1 / 22

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

favian
Télécharger la présentation

Two Case Studies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Two Case Studies • CCPDS-R, TRW • How Microsoft Builds Software • Different development environments • Software development life cycle • Software project management techniques

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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)

  7. Incremental Design Process • Individual milestones within a build • Preliminary design walkthrough • Critical design walkthrough • Code walkthrough • Turnover review

  8. Incremental Test Process • Stand-alone test • Build integration test; establish a stable, reliable baseline • Reliability test • Engineering string test • Final qualification test

  9. 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

  10. 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

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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. Synch-and-StabilizeDevelopment Approach • Planning Phase • Development Phase • Stabilization Phase

  18. 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

  19. 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)

  20. Stabilization Phase • Internal testing • External testing (“beta” sites and users) • Release preparation

  21. 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

  22. 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

More Related