IT项目管理英文版课件：Process case1

1、CCPDS-R A Case StudyAn objective case study is a true indicator of a mature organization and a mature project process. The software industry needs more case studies like CCPDS-RThe metrics histories were all derived directly from the artifacts of the projects process. These data were used to manage

2、the project and were embraced by practitioners, managers, and stakeholdersCCPDS-R was one of the pioneering projects that practiced many modern management approachesCCPDS-R A Case StudyA detailed case study of a successful software projectSuccessful means on budget, on schedule, and satisfactory to

3、the customerCommand Center Processing and Display System-Replacement projectFor the U.S. Air Force, from 1987 to 1994, by TRW, Ca.Including system engineering, hardware procurement, and software development, each consuming about 1/3 of the total costThe software effort included the development of th

4、ree distinct software systems totaling more than one million source lines of code, and each consuming about 1/3The case focusing on the initial software developmentCommon Subsystem, about 355,000 source lines, producing a reusable architecture, a mature process, and an integrated environment for oth

5、er two subsystemsCCPDS-R A Case StudyCD: Concept Definition FSD: Full-Scale Development like inception phaseCCPDS-R A Case StudyA very large software development activityUsing Ada languageThe purpose of the SE exercise be to demonstrate that the contractors proposed software process, Ada environment

6、, and software team were in place, were mature, and were demonstrableConduct a mock design review with the customer 23 days after receipt of a simple twospecification of a “missile warning simulator” TRWs CCPDS-R team won (12 people for 23 days)CCPDS-R A Case StudyThe following results were produced

7、 with the proposed software development plan:CCPDS-R A Case StudyTRW proposing an architecture-first, demonstration-based approachMore than 20% bid higher than that of their competitorThe best value and lowest riskSuccessful performance on the SE exerciseAbility to demonstrate their process under re

8、alistic conditionsCCPDS-R A Case StudyThe primary responsibilities of the CD phase team:CCPDS-R A Case StudyThe six computer software configuration items(CSCIs) of the Common Subsystem softwareCCPDS-R A Case StudyCCPDS-R A Case StudyCCPDS-R A Case StudyIn the CCPDS-R definition of an architecture, t

9、he view of the Software Architecture Skeleton(SAS) included the followingCCPDS-R A Case StudyTwo important aspects of SAS verification and assessment: compilation and executionThe SAS provides the forum for integration and architecture evolution. It is important to construct the SAS early and to evo

10、lve it into a stable baselineCCPDS-R installed its first SAS baseline (after three informal iterations) around month 13,just before the PDR milestoneAll subsequent change was performed via rigorous configuration controlThe SAS was useful in assessing the volatility in the overall software interfaces

11、 and captured the conceptual architecture of the Common SubsystemCCPDS-R A Case StudyCCPDS-R A Case StudyThe software architecture stability with Common Subsystem SAS evolution From a macroprocess view, the initial milestones focused on achieving a baseline architecture. The PDR baseline required th

12、ree major architecture iterations, the conclusions of which coincided with the milestones for the software requirements review (SRR), interim PDR (IPDR), and PDR:The SRR demonstration: initial feasibility of the foundation components, and basic use cases of initialization and interprocess communicat

13、ionsThe IPDR demonstration: the feasibility of the architectural infrastructure under the riskiest use cases, including the following:The PDR demonstration: adequate achievement of the peak load scenarios and the other primary use cases within a full-scale architectural infrastructure, including the

14、 other critical-thread componentsThe CDR demonstration updated the architecture baseline to represent the equivalent of an alpha test capability for the complete architectural infrastructure and the critical-thread scenarios. This was a usable system in that it provided a set of complete use cases s

15、ufficient for the user to perform a subset of the mission.A peak data load missile warning scenario of a mass raid from the Soviet UnionA peak control load scenario of a system failover and recovery from the primary thread of processing to a backup thread of processing with no loss of dataCCPDS-R A

16、Case Study Process OverviewBuild 0. This build comprised the foundation components necessary to build a software architecture skeleton. The intertask/interprocess communications, generic task and process executives, and common error reporting components were included. This build was also the conclus

17、ion of the research and development project executed in parallel with the CD (inception) phase. These NAS components were the cornerstone of the architectural framework and were built to be reusable across all three CCPDS-R sub-systems. They represented very complex, high-risk components with string

18、ent performance, reliability, and reusability demands. The Details of the Build ContentBuild 1. This build was essentially the architecture. It included a complete set of instantiated tasks (300), processes (70), interconnections (1,000), states, and state transitions for the structural solution of

19、the CCPDS-R software architecture. To achieve a cycling architecture, this build also added all the NAS components for initialization, state management (reconfiguration), and instrumentation. A trivial user interface and the capability to inject test scenarios into the architecture were added to sup

20、port the initial demonstration. Upon completion of build 1, only a few critical use cases were demonstrable: initializing the architecture, injecting a scenario to drive the data flow through the system, and orchestrating reconfigurations such as primary thread switchover to backup thread.The Detail

21、s of the Build ContentBuild 2. This was the first build of mission-critical components and achieved the initial capability to execute real mission scenarios. The three primary risks inherent in the mission scenarios were the timeliness of the display database distribution, the performance (resource

22、consumption and accuracy) of the missile warning radar algorithms, and the performance of the user interface for several complex displays. Upon completion of build 2, several mission-oriented use cases could be executed, including the worst-case data processing thread and the worst-case control proc

23、essing thread (primary-to-backup switchover).The Details of the Build ContentBuild 3. This build contained the largest volume of code, including display format definitions, global type definitions, and representation specifications needed for validation of external interface transactions. Although t

24、he code was voluminous, much of it was produced automatically in a cook-book manner by constructing code generation tools. The remaining components allocated to build 3 included the external communications interface protocol handling, the completed user-system interface for the mission operators, th

25、e user-system interface for the computer support positions, the system services for mission reconfigurations, database resets, off-line data reduction, and the nuclear detonation algorithms. Although initially planned as one large build, this increment was later split into two more manageable releas

26、es, builds 3-1 and 3-2.The Details of the Build ContentBuild 4. This build provided the final installment of missile warning algorithms for satellite early warning systems, the final installment of mission management and mission status displays, and the final installment of external communications i

27、nterface processing.Build 5. In the middle of the Common Subsystem schedule, build 5 was added to coincide with a particular external interface (being built on a separate contract), the schedule for which had slipped so that it was not going to be available during its originally planned build (build

28、 4). Consequently, the external interface was scheduled into an entirely new build.The Details of the Build ContentThe individual milestones within a build : preliminary design walkthrough(PDW) critical design walkthrough (CDW) turnover review (TOR) CCPDS-R A Case Study Process OverviewCCPDS-R A Cas

29、e Study Process OverviewPreliminary Design Walkthroughs Initial prototyping and design work was concluded with a PDW and a basic capability demonstration. The walkthrough focused on the structural attributes of the components within the build. The basic agenda was tailored for each build, but it gen

30、erally included the following topics for each CSCI:Overview: CSCI overview, interfaces, components, and metricsComponents: walkthrough of each major component, showing its source code interface, allocated system requirements specification (SRS) requirements, current metrics, operational concept for

31、key usage scenarios, standalone test plan, and erroneous conditions and responsesDemonstration: focused on exercising the control interfaces across the components within the integrated architectureCCPDS-R A Case Study Process OverviewCritical Design Walkthroughs A builds design work was concluded wi

32、th a CDW and a capability demonstration that exposed the key performance parameters of components within the build. While the PDW focused on the declarative view of the design, the CDW focused on the completeness of the components and the behavioral perspective of operating within the allocated perf

33、ormance requirements. The basic agenda was tailored for each build, but it generally included the following topics for each CSCI:CSCI overview: interfaces, components, and metrics; summary of changes since PDW; disposition of all PDW action items; build integration test scenariosComponents: walkthro

34、ugh of each major component, showing its source code interface, allocated SRS requirements, current metrics, operational concept for key usage scenarios, stand-alone test plan, and erroneous conditions and responsesDemonstration: focused on exercising the critical performance threadsCCPDS-R A Case S

35、tudy Process OverviewCode WalkthroughsDetailed code walkthroughs were also used to disseminate projectwide expertise and ensure the development of self-documenting source code. Some authors generated source code that demonstrated excellent levels of readability worthy of being assessed as self-docum

36、enting. The CSCI managers and the software chief engineer coordinated the need for code walkthroughs and their allocation among various authors to meet the following objectives: Better dissemination of self-documenting source code style Identification of coding issues not easily caught by compilers

37、and source code analysis tools: Object naming, coding style, and commenting style: Does it promote readability? Unnecessarily complex objects or methods: Are there simpler approaches. Reuse: Is custom software being built where reusable components exist? Potential performance issues: Are there poten

38、tially inefficient implementations? Reduction of the amount of source code needed for review in the larger design walkthroughs Exposure of inexperienced personnel to the products of experts and vice versaCCPDS-R A Case Study Process OverviewTurnover ReviewsTurnover reviews were not really reviews; t

39、hey were typically a one-month activity during which components were completed with stand-alone testing and turned over for configuration control, build integration testing, and engineering string testing.COMPONENT EVOLUTION CCPDS-R used Ada as a uniform life-cycle format for design evolution. This uniformity allowed for software development progress metrics to be extracted directly from the evolving sou