Upload
favian
View
61
Download
3
Tags:
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
Two Case StudiesTwo Case Studies
• CCPDS-R, TRWCCPDS-R, TRW• How Microsoft Builds SoftwareHow Microsoft Builds Software• Different development environmentsDifferent development environments• Software development life cycleSoftware development life cycle• Software project management Software project management
techniquestechniques
CCPDS-R Case StudyCCPDS-R Case Study
• Command Center Processing and Command Center Processing and Display System – ReplacementDisplay System – Replacement
• TRW Space and Defense in Redondo TRW Space and Defense in Redondo Beach, CABeach, CA
• Customer : U.S. Air ForceCustomer : U.S. Air Force• Focus : Common SubsystemFocus : Common Subsystem• Mission critical softwareMission critical software
Common SubsystemCommon Subsystem
• Primary missile warning systemPrimary missile warning system• Main installation : Cheyenne MountainMain installation : Cheyenne Mountain• Backup system : Offutt Air Force Base, Backup system : Offutt Air Force Base,
NebraskaNebraska• 48-month software development schedule48-month software development schedule• 355,000 SLOC355,000 SLOC• Ada : design & implementation languageAda : design & implementation language• 6 builds were required6 builds were required• Completed successfully, on time within budget Completed successfully, on time within budget
to customer satisfactionto customer satisfaction
CCPDS-R AcquisitionCCPDS-R Acquisition
• Concept definition (CD), 12-month Concept definition (CD), 12-month scheduleschedule
• 5 major bidders, 2 contracts awarded5 major bidders, 2 contracts awarded• Full-scale development (FSD)Full-scale development (FSD)• 1 contract awarded to TRW1 contract awarded to TRW• Contract award based on performance in Contract award based on performance in
Software Engineering ExerciseSoftware Engineering Exercise
Concept Definition (CD)Concept Definition (CD)
• VisionVision• Analyze and specify the project requirementsAnalyze and specify the project requirements• Define and develop the top-level architectureDefine and develop the top-level architecture• Plan FSD phase software development activitiesPlan FSD phase software development activities• Configure the process and development Configure the process and development
environmentenvironment• Establish trust and win-win relationships among the Establish trust and win-win relationships among the
stakeholdersstakeholders• Software engineering exerciseSoftware engineering exercise
Process Overview for FSDProcess Overview for FSD
• Standard DOD life cycle after contract Standard DOD life cycle after contract awardaward
• Software requirements review (SRR)Software requirements review (SRR)• Interim preliminary design review (IPDR)Interim preliminary design review (IPDR)• Preliminary design review (PDR)Preliminary design review (PDR)• Critical design review (CDR)Critical design review (CDR)• Final qualification test (FQT)Final qualification test (FQT)
Incremental Design ProcessIncremental Design Process
• Individual milestones within a buildIndividual milestones within a build• Preliminary design walkthroughPreliminary design walkthrough• Critical design walkthroughCritical design walkthrough• Code walkthroughCode walkthrough• Turnover reviewTurnover review
Incremental Test ProcessIncremental Test Process
• Stand-alone testStand-alone test• Build integration test; establish a Build integration test; establish a
stable, reliable baselinestable, reliable baseline• Reliability testReliability test• Engineering string testEngineering string test• Final qualification testFinal qualification test
IPDR DemonstrationIPDR Demonstration
• Demonstrate defined capabilities at NORADDemonstrate defined capabilities at NORAD• Capabilities well understood by the customer Capabilities well understood by the customer
and TRWand TRW• 37 evaluation criteria37 evaluation criteria• Results were apt to change requirements, Results were apt to change requirements,
plans and designsplans and designs• 31 satisfactory, 6 were not met31 satisfactory, 6 were not met• Required redesign and re-demonstrationRequired redesign and re-demonstration
MetricsMetrics
• Build Progress (% coded) vs timeBuild Progress (% coded) vs time• Requirements verified vs timeRequirements verified vs time• Cumulative SLOC vs timeCumulative SLOC vs time• Average hours per software change Average hours per software change
order (SCO)order (SCO)• Mean time between failure (MTBF) vs Mean time between failure (MTBF) vs
total test hourstotal test hours• Cumulative SLOC vs budgetCumulative SLOC vs budget
People factorsPeople factors
• Core team conceptCore team concept• Leverage skills of a few experts across Leverage skills of a few experts across
the entire teamthe entire team• Avoid attritionAvoid attrition• Profit sharing of award feesProfit sharing of award fees
Microsoft Case StudyMicrosoft Case Study
• High volume, mass market softwareHigh volume, mass market software• Redmond, WashingtonRedmond, Washington• Excel, Word, Windows 95, Windows NT, Excel, Word, Windows 95, Windows NT,
etc.etc.• Respond to events in the marketplaceRespond to events in the marketplace• Highly flexible, entrepreneurial companyHighly flexible, entrepreneurial company
Microsoft Competitive StrategyMicrosoft Competitive Strategy
• Identify mass markets quicklyIdentify mass markets quickly• Introduce products that are “good Introduce products that are “good
enough”enough”• Improve products by incrementally Improve products by incrementally
evolving their featuresevolving their features• Sell multiple product versions and Sell multiple product versions and
upgradesupgrades• Sell globallySell globally
Product Development Product Development PhilosophyPhilosophy
• Utilize small parallel teams (3 to 8 developers)Utilize small parallel teams (3 to 8 developers)• Teams evolve features and products Teams evolve features and products
incrementallyincrementally• Occasionally introduce new concepts and Occasionally introduce new concepts and
technologiestechnologies• Synchronize changes frequently so product Synchronize changes frequently so product
components work togethercomponents work together• Structured hacker-like approachStructured hacker-like approach
Synch-and-StabilizeSynch-and-Stabilize
• Continually synchronize what developers are Continually synchronize what developers are doing as individuals and team membersdoing as individuals and team members
• Stabilize the product in incrementsStabilize the product in increments• Daily buildDaily build• Continual testingContinual testing• Testers work in parallel with developers (1 to 1)Testers work in parallel with developers (1 to 1)• Fix defect immediately if checked in code Fix defect immediately if checked in code
“breaks” the daily build“breaks” the daily build
Big Picture ProceduresBig Picture Procedures
• Teams work at single physical siteTeams work at single physical site• Common development languages (C and Common development languages (C and
C++)C++)• Common coding stylesCommon coding styles• Standardized development toolsStandardized development tools• Teams must communicate, debate Teams must communicate, debate
design ideas, and resolve problems face design ideas, and resolve problems face to faceto face
Synch-and-StabilizeSynch-and-StabilizeDevelopment ApproachDevelopment Approach
• Planning PhasePlanning Phase• Development PhaseDevelopment Phase• Stabilization PhaseStabilization Phase
Planning PhasePlanning Phase
• Vision statementVision statement• Product managers define goals for a new Product managers define goals for a new
product based on market researchproduct based on market research• Specification document written up by Program Specification document written up by Program
managermanager• During development, feature set in During development, feature set in
specification document may change by 30% or specification document may change by 30% or moremore
• Schedule and feature team formation Schedule and feature team formation
Development PhaseDevelopment Phase
• Developers design, code, and debugDevelopers design, code, and debug• Testers pair with developers for continuous Testers pair with developers for continuous
testingtesting• 3 major milestones3 major milestones• Milestone 1 : first 1/3 of features (most critical Milestone 1 : first 1/3 of features (most critical
and shared components)and shared components)• Milestone 2 : second third of featuresMilestone 2 : second third of features• Milestone 3 : final third of features (least Milestone 3 : final third of features (least
critical)critical)
Stabilization PhaseStabilization Phase
• Internal testingInternal testing• External testing (“beta” sites and External testing (“beta” sites and
users)users)• Release preparationRelease preparation
Principles – Developing and Principles – Developing and Shipping ProductsShipping Products
• Work in parallel teams but “synch up” and debug Work in parallel teams but “synch up” and debug dailydaily
• Always have a product you can ship, with versions Always have a product you can ship, with versions for different platforms and marketsfor different platforms and markets
• Speak a “common language” on a single Speak a “common language” on a single development sitedevelopment site
• Continuously test the product as you build itContinuously test the product as you build it• Use metric data to determine milestone completion Use metric data to determine milestone completion
and product releaseand product release
ConclusionsConclusions
• Stakeholders and type of software being Stakeholders and type of software being developed effect the software development life developed effect the software development life cyclecycle
• CCPDS-R - more externally controlled processCCPDS-R - more externally controlled process• Microsoft – market driven – internally controlled Microsoft – market driven – internally controlled
process geared towards customer satisfaction process geared towards customer satisfaction and market shareand market share
• Both cases illustrate extensive use of modern Both cases illustrate extensive use of modern software project management techniquessoftware project management techniques
• Both cases show level 3 (defined) of CMMBoth cases show level 3 (defined) of CMM