Category Archives: Book review

내가 읽었던 책 리뷰

Practical Guide to SysML

Recently I had a chance to use SysML to design a system. My role is more close to make a rule for modeling and guide a drafted design to be a more structured design and to refine preliminary design which to be a simple and straightforward design in a manageable way.

Enterprise Architecture gives me very useful examples and I chose some sample diagrams to apply to my project. This book also gives me real examples how modeling using SysML can be specified.

First impression for SysML modeling examples is that a system in the real world can be modeled using SysML. It seems to be more realistic. It does not just a concept in mind. It exists in a semi-formal specification way

The book have many example sysML models in a real world, and they are useful to understand how SysML model  can be formalized and which modeling notations are useful to specify.

Obviously, Model based System Engineering approach really helps requirement management to be manageable, because design engineers can specify their system more structured way, which help stakeholders to understand system better.

If a SysML model is imported to Medini, then systematic safety analysis can be performed. so I recommend to apply MBSE approach, and SysML is a very good tool to model a system design.




Certification Liaison Process

This process is specified in DO-178C. It is a kind of communication process with Certification Authority. It is very important for suppliers to get a good results. I’ve never  experienced about type certification or airworthiness certification, but I think that I can imagine the procedure because there are published document.

Though it is natural to think, applicant has to submit safety plan to certification body and it can be proceed if the plan is approved by certification authority.

It would be ridiculous if applicant submit safety plan in the middle of the project. What if the plan is rejected? Everything they have done so far must be dumped.

Unfortunately this process is not defined in the automotive, but it also essential for supplier. Competent OEM may have a detailed process for audit and assessment.

You can also refer a book, “Developing Safety-Critical Software(DO-178C)” in chapter 12

Developing Safety-Critical Software(DO-178C)에 대한 이미지 검색결과


Section 6. 상세 설계 단계



SECTION 6 상세 설계 단계






상세 설계 단계의 목적은 시스템을 위한 모든 요구사항을 만족시키는 설계 사양을 생성하고 코드로 직접 구현 가능할 수 있도록 하기 위함이다.


The purpose of the detailed design phase is to produce a completed design specification that will satisfy all requirements for the system and that can be directly implemented in code.


PDR에서 표시된 comment가 예비 설계에서 심각한 문제나 약점을 표시하지 않는다면, 상세 설계는 PDR을 따름으로 시작된다. 상세 설계 프로세스는 예비 설계 동안에 수행한 활동의 확장이다. 개발 팀은 예비 설계에서 정의된 시스템 구조를 elaborate하여 단위 수준까지 하여 코드로 생성할 수 있는 사양을 생성한다. 이 단계의 일차적 산출물은 상세 설계 문서이며, 소프트웨어 시스템을 위한 설계 다이어그램, 프롤로그, PDL를 포함한다.


Unless comments expressed at the PDR indicate serious problems or deficiencies with the preliminary design, detailed design begins following the PDR. The detailed design process is an extension of the activities begun during preliminary design. The development team elaborates the system architecture defined in the preliminary design to the unit level, producing a complete set of code-to specifications. The primary product of the phase is the detailed design document, which contains the design diagrams, prologs, and PDL for the software system.


이 단계 동안 개발 팀은 요구사항 팀을 위해 설계에 대한 워크스루를 수행하고 동료 검토를 통해 설계 사양 각각을 검토한다. 이 단계의 마지막으로 CDR에서 완성된 설계가 형식적으로 검토된다.


During this phase, the development team conducts walk-throughs of the design for the requirements definition team and subjects each design specification to peer inspection. At the conclusion of the phase, the completed design is formally reviewed at the CDR.


그림 6-1은 상세 설계 단계의 주요 프로세스를 나타낸다.

Figure 6-1 shows the major processes of the detailed design phase.



개발 팀은 세부 설계를 생성하는 동안, 요구사항 정의의 팀은 나머지 요구사항의 문제와 TBDs를 해결하기 위해 계속한다. 즉시 요구사항 질문 및 변경 수준을 교체 하자마자, 인수 시험을 위한 추가 팀이 구성된다. 이 승인 테스트 팀은 일반적으로 요구사항 및 사양 문서를 준비하는 직원의 일부와 함께, 시스템을 사용할 분석가들로 구성되어 있다.

While the development team is generating the detailed design, the requirements definition team continues to resolve the remaining requirements issues and TBDs. As soon as requirements questions and changes level off, an additional team is formed to prepare for acceptance testing. This acceptance test team usually consists of the analysts who will use the system, along with some of the staff who prepared the requirements and specifications document.


개발 팀, 관리팀, 요구사항 정의의 팀 및 인수 시험 팀의 활동은 아래의 항목을 구별된다. 이러한 활동의 성과에 대해 제안된 타임 라인은 그림 6-2에 제시되어있다.

The activities of the development team, the management team, the requirements definition team, and the acceptance test team are itemized below. A suggested timeline for the performance of these activities is given in Figure 6-2.



개발팀의 활동들(Activities of the Development Team)


  • 최하위 수준, 즉, 서브 루틴/서브 수준으로 상세 설계 도면을 준비한다. 모든 컴포넌트가 하나의 기능을 수행하고 단일 유닛으로 구현될 수 있을 때까지 계속해서 각각의 서브시스템을 refine한다.
  • Prepare detailed design diagrams to the lowest level of detail, e., the subroutine/subprogram level. Successively refine each subsystem until every component performs a single function and can be coded as a single unit.


  • 설계 워크스루를 수행한다. 각 주요 기능 혹은 객체에 대해서 다른 개발자 및 요구사항 정의팀과 함께 워크스루를 실시한다. 작은 프로젝트에서는 서브시스템당 한번의 워크스루를 수행한다. 150KSLOC 혹은 그 이상인 경우 하나의 서브시스템당 두 번의 워크스루를 개최하여 한번은 상세 설계의 초기 단계에 그리고 한번은 최종 단계에 한다.
  • Conduct design walk-throughs. Walk through each major function or object with other developers and the requirements definition team. On small projects (e.g., simulators), conduct one walk-through per On systems of 150 KSLOC or more (e.g., AGSSs), hold two walk-throughs per subsystem — one in the early stages of detailed design and one later in the phase.


  • 프로토타이핑, 성능 모델링 설계 활동의 결과의 관점에서 운영 시나리오를 refine한다. 디스플레이, 프린터와 플로터 출력, 데이터 저장 등을 포함한 각각의 서브 시스템에 대한 자세한 입출력 포맷을 명세한다. 
  • Refine the operations scenarios for the system in light of the results of prototyping, performance modeling, and design activities. Finish specifying detailed input and output formats for each subsystem, including displays, printer and plotter output, and data stores.


모든 프로토타이핑 노력을 완성한다. 프로토타이핑을 통해 불확실한 것들이 모두 해소되어 CDR에서는 불확실한 것이 없어야 한다.

Complete all prototyping efforts. The detailed design presented at CDR should contain no uncertainties that could have been resolved through prototyping.


Figure 6-1.   Generating the Detailed Design



  • 모든 유닛에 대한 완벽한 프롤로그와 PDL을 완성한다. 설계 도면에 명세된 새로운 유닛에 대해 프롤로그와 PDL을 생성한다. 에이다 프로젝트에서 패키지 사양 및 PDL은 컴파일 되어야 한다.그대로 사용 혹은 수정하는 등의 재사용 할 모든 유닛을 식별한다.모든 단위 설계가 형식적으로 검토되고 인증됨을 확인하라(방법과 도구 참조). 단위에 대한 SEN의 완성된 체크리스트를 보관한다.



  • Complete prologs and PDL for all units. Generate prologs and PDL for the new units specified in the design diagrams. On Ada projects, package specifications and PDL should also be compiled.  This means that package bodies are compiled, and that, at a minimum, subprogram bodies each contain a nullIdentify all units (from the RSL or other sources) that will be reused, either verbatim or with modifications. Transfer existing units that require modification into online libraries, and revise the prologs and PDL of these units as necessary.Ensure that all unit designs are formally inspected and certified (see Methods and Tools below). File the completed checklist in the SEN for the unit.


  • 빌드 계획에 대한 입력을 제공하고 빌드 테스트 계획을 시작한다. 관리 팀에게 빌드 계획에 필요한 기술 정보를 제공한다; 구현되어야 하고 통합 되어야 하는 단위의 순서를 포함한다. 첫 번째 빌드에 대한 테스트 계획을 준비하고 CDR에서 그것을 검토한다. (계획의 형식과 내용은 제 7 장을 참조한다.)


  • Provide input to the build plan and begin the build test plan.

Provide the technical information needed for the build plan to the management team; include the order in which units should be implemented and integrated. Prepare the test plan for the first build and review it at CDR. (See Section 7 for the plan’s format and contents.)


  • CDR의 기초로서 상세화된 설계 문서를 준비한다. 팀 사서가 그 단계 동안 프로젝트 라이브러리에 모든 문서를 추가함을 확인한다. (유일한 예외는 SEN자료인데, 이 자료는 단위가 코딩 되고 시험 될 때까지 개별 개발자에 의해 유지 관리된다.)


  • Prepare the detailed design document as a basis for the Ensure that the team librarian adds all documentation produced during the phase to the project library. (The only exceptions are SEN materials, which are maintained by individual developers until the unit has been coded and tested.)


  • CDR을 수행하고 모든 CDR RID에 응답한다.


  • Conduct the CDR and respond to all CDR



Figure 6-2. Timeline of Key Activities in the Detailed Design Phase




관리팀의 활동들(Activities of the Management Team)


일부 예외를 제외하고 관리팀의 상세 설계 단계 동안의 활동들은 이전 단계의 활동들과 병렬적으로 수행된다.

With a few exceptions, the activities of the management team during the detailed design phase parallel those of the previous phase.


  • 일정 데이터 및 프로젝트 통계를 포함한 소프트웨어 개발 이력에 대해 예비 설계 단계로부터 얻은 교훈을 평가하고 정보를 기록한다. 이들 데이터의 관점에서 일정, 인적 자원 및 자원들을 다시 평가한다.
  • Assess lessons learned from the preliminary design phase and record information for the software development history, including schedule data and project statistics. Reassess schedule, staffing, and resources in view of these data.


  • 요구사항 변경을 제어한다. 요구사항 질문 및 응답의 숫자와 범위를 모니터링하는 것을 계속한다.분석가와 고객이 각각의 요구사항 TBD의 잠재적 인 영향 및 제안 된 사양 변경을 이해했는지 확인한다.


  • Control requirements changes. Continue to monitor the number and scope of requirements questions andEnsure that analysts and the customer understand the potential impact of each requirement TBD and proposed specification modification.


  • 상세 설계 프로세스의 품질과 제품을 제어한다. 설계 표준, 형상 관리 절차(특히 변경 제어), 보고 절차, 데이터 수집 절차, 품질 보증 절차 등에 대해 준수하는지를 확인한다. 생성된 설계를 검토하고 설계 워크스루에 참여한다.프로젝트의 모든 측면이 완전히 가시적이며 개발 팀 및 개발팀과 상호작용해야 하는 다른 그룹들 사이에 밀접한 협력이 있는지를 확인한다.


  • Control the quality of the detailed design process and its Ensure adherence to design standards, configuration management procedures (especially change control), reporting procedures, data collection procedures, and quality assurance procedures. Review the design produced and participate in design walk-throughs.Ensure that all facets of the project are completely visible and that there is close cooperation between the development team and the other groups with which they must interact.


  • 빌드 계획을 준비한다. 구현 단계의 각 단계에서 개발되어야 할 시스템의 부분을 명세하기 위해 개발 팀의 기술 리더와 어플리케이션 전문가가 제공하는 단위 종속성 정보를 사용한다. 각각의 빌드에 포함되어야 하는 기능을 문서화하고 상세 일정, 외부 제약사항에 대한 양산, 사용자 요구를 준비한다.


  • Prepare the build plan. Use unit dependency information provided by the technical leads and application specialists of the development team to specify the portions of the system that will be developed in each stage of the implementation phase. Document the capabilities to be included in each build and prepare a detailed milestone schedule, factoring in external constraints and user needs.


  • 구현 단계로의 전환을 조정한다. 대개 빌드 내의 여러 개의 서브시스템을 동시에 구현하기 위해 개발 팀의 규모를 키우는 것이 필요하다. 개발팀에게 구현 동안 사용되는 소프트웨어 공학 접근법을 공지하고 필요한 훈련을 제공한다. 개발 팀의 각각의 멤버들이 코드 및 시험 표준을 이해하고 준수해야 하는 품질 보증 및 형상관리 절차를 이해하고 있는지를 확인한다.


  • Coordinate the transition to the implementation phase. It is usually necessary to increase the size of the development team to simultaneously implement multiple subsystems within a Inform the development team of the software engineering approaches to be used during implementation and provide the necessary training. Ensure that members of the development team understand the code and testing standards, and the quality assurance and configuration management procedures to be followed.

온라인 프로젝트 라이브러리가 수립되었는지를 확인하며 라이브러리와 관련된 엄격한 변경 제어 절차를 따르는지, 필요한 시스템 빌드 및 시험에 필요한 소프트웨어가 사용 가능하여 개발자가 CDR이후 즉시 구현을 시작할 수 있는지를 확인한다.

Ensure that online project libraries are established, that strict change-control procedures concerning these libraries are followed, and that the necessary software for building and testing the system is made available so that developers can begin implementation immediately after the CDR.


  • CDR을 지시한다. 일정을 세우고 검토에 참여하며 모든 관련 단체가 참여 하는지를 확인한다.
  • Direct the CDR. Schedule and participate in the review, and ensure that all pertinent groups take



요구사항 정의팀의 활동들(Activities of the Requirements Definition Team)


  • 필요에 따라 사양 변경을 준비하면서 해결되지 않은 요구사항 이슈와 TBD들을 해결한다. 요구사항에 대한 임박한 변경의 개발을 경고하여 개발자들이 설계 활동을 계획할 수 있도록 한다. 개발자들의 질문에 응답한다.
  • Resolve any outstanding requirements issues and TBDs, preparing specification modifications as necessary. Warn developers of any impending changes to requirements so that they can plan design activities accordingly. Respond to developers’


  • 설계 워크스루와 CDR에 참여한다. CDR전에 상세 설계를 검토한다. 검토하는 동안 설계에 대한 비평을 한다. 이슈 사항과 불일치를 문서화하기 위해 RID를 사용한다. 
  • Participate in design walk-throughs and the CDR. Review the detailed design document before CDR. During the review, provide a critique of the Use RIDs to document issues and discrepancies.



인수 시험팀의 활동들(Activities of the Acceptance Test Team)


  • 요구사항이 안정화 되자마자 인수 시험 계획의 작업을 시작한다. 요구사항은 개발자들이 새로운 요구사항 질문을 하지 않고 TBD의 개수가 낮은 수준으로 감소하게 되면 안정화 된 것으로 간주할 수 있다.
  • Begin work on the acceptance test plan (Section 8) as soon as requirements have Requirements can be considered as stable when developers are no longer submitting new requirements questions and the number of TBDs has declined to a low level.


  • 빌드 1에서 필요로 하는 분석적 시험 계획의 일부를 준비한다 (section 7을 참조하라). 구현 단계의 첫 번째 빌드 동안 어떠한 분석 시험이 필요한지를 결정하기 위해 개발팀과 만나고 분석적 시험 계획의 일부분들 완성하라. 
  • Prepare the portions of the analytical test plan that are needed for Build 1 (see Section 7). Meet with the development team to determine which analytical tests will be needed during the first build of the implementation phase, and complete those portions of the analytical test




상세 설계 동안 예비 설계 단계에서 사용되는 같은 방법과 도구가 사용된다:

The same methods and tools used during the preliminary design phase continue in use during detailed design:


  • 기능적 분해와 객체 지향 설계(OOD)
  • 재사용 검증
  • 분석 방법들: 프로토타이핑, 성능 모델링, 코드 분석
  • 설계 워크스루
  • 설계 검사
  • 프롤로그와 PDL
  • SENs


  • Functional decomposition and object-oriented design (OOD)
  • Reuse verification
  • Analysis methods:  prototyping, performance modeling, and code analysis
  • Design walk-throughs
  • Design inspections
  • Prologs and PDL
  • SENs


상세 설계 단계 동안, 개발 팀은 기능 분해 혹은 OOD기법을 사용하여 설계 다이어그램을 상세화의 가장 낮은 수준까지 기술한다 (그림 5-3, 5-4). 설계 이슈를 해결하기 위해 수행된 프로토타이핑과 성능 모델링 노력이 완성된다. 팀은 또한 각각의 유닛이 계획대로 시스템에 통합될 수 있는지의 여부를 판단하기 위해 코드의 점검을 완료하며 재사용 할 수 있는 컴포넌트의 문서화를 완료한다.

During the detailed design phase, the development team uses functional decomposition or OOD techniques to take the design diagrams down to the lowest level of detail (see Figures 5-3 and 5-4). Prototyping and performance modeling efforts that were undertaken to address design issues are completed. The team also completes its examination of the code and documentation of reusable components to determine whether each unit can be incorporated into the system as planned.


예비 설계 단계로부터 계속 사용되는 다른 방법과 도구(설계 워크스루, 설계 검사, 프롤로그, PDL, SENs)는 상세 설계 동안 도출되는 새로운 측면이나 어플리케이션을 가진다. 이들은 다음 단락에서 논의된다.

The other methods and tools that continue in use from the preliminary design phase — design walk-throughs, design inspections, prologs and PDL, and SENs — have new aspects or applications that are introduced during detailed design. These are discussed in the paragraphs that follow.



설계 워크스루(Design Walk-throughs)


상세 설계 동안 한 혹은 두 개의 설계 워크스루는 각각의 서브시스템에 대해 개최된다. 참가자들은 개발팀, 요구사항 정의팀, 개발 소프트웨어와 인터페이스 하는 시스템 대표, 관리자 등을 포함한다. 이런 워크스루에서 개발 팀의 멤버들은 서브시스템의 설계를 하나하나 진행하며, 그것의 알고리즘, 인터페이스, 운영 개념을 설명한다. 참가자들은 매치되지 않은 인터페이스나 알고리즘 사이의 모순, 잠재적 성능 문제등과 같은 이슈들을 해결하기 위해 검사하고 설계 질문을 상세화된 수준에서 한다.

During the detailed design phase, one or two design walk-throughs are held for each subsystem. Participants include members of the development team, the requirements definition team, representatives of systems that will interface with the software under development, and managers. At these walk-throughs, members of the development team step through the subsystem’s design, explaining its algorithms, interfaces, and operational aspects. Participants examine and question the design at a detailed level to uncover such issues as mismatched interfaces, contradictions between algorithms, or potential performance problems.


사용자 인터페이스의 설계는 특별히 하나 혹은 그 이상의 워크스루를 한다. 이 세션은 시스템의 미래 사용자를 참가시키며 사용자의 관점에 집중한다. 사용자들은 어떻게 시스템이 운영 시나리오상에서 시스템을 바라로며 개발자들에게 피드백을 제공하며 갱신된 요구사항 및 사양에 대한 “실제적인 체크”를 한다. 사양에 대한 문제들은 질의 응답 형식으로 문서화하고 이행을 위해 요구사항 정의 팀에 제출한다.

The design of the user interface is specifically addressed in one or more additional walk-throughs. These sessions are attended by the future users of the system and concentrate on the users’ point of view. The users learn how the system will look to them under representative operational scenarios, give feedback to developers, and provide a “reality check” on the updated requirements and specifications. Problems encountered with the specifications are documented on question-and-answer forms and submitted to the requirements definition team for action.


디자인 워크스루와 검사는 예비 설계 단계 동안 시작된다. section 5는 검사와 워크스루에 대해 정의하며 두 방법의 차이점에 대해 설명한다.

Design walk-throughs and inspections are initiated during the preliminary design phase. Section 5 defines both inspections and walk-throughs and explains the differences between the two methods.




별도의 정형화된 디자인 워크스루는 항상 작은 도구 개발 노력으로 유지되는 것은 아니다. 이런 프로젝트에서 워크스루는 설계 검토와 결합될 수 있다. 검토는 일반적으로 비형식적인데, 점검되는 제품은 CCB제어하에 있지 않으며 시스템 운영 및 사용자 인터페이스에 집중하기 때문이다.

Separate, formalized design walk-throughs are not always held on small tool development efforts. On these projects, walk-throughs may be combined with design reviews.  The reviews are generally informal, since the products being examined will not be put under CCB control, and focus on system operability and the user interface.


설계 검사(Design Inspections)


설계 검사는 상세 설계 단계의 핵심 방법이다. CDR은 관리 및 사용자의 이익을 위해 주로 실시되고 있기 때문에, 설계의 상세한 구성 요소 별 리뷰는 단지 디자인 검사 동안에 일어난다. 각 개별 디자인 제품의 정확성, 완전성 및 이해 능력을 검사하는 것은 이들을 검사하는 기간에 수행한다.

Design inspections are the key methodology of the detailed design phase. Because the CDR is conducted primarily for the benefit of management and users, a detailed, component-by-component review of the design takes place only during design inspections. It is during these inspections that each separate design product is examined for correctness, completeness, and comprehensibility.


설계 검사는 프로젝트의 규모나 타입에 상관없이 언제나 수행된다.

Design inspections are always conducted, regardless of the size or type of the project.


최소한, 검사팀은 moderator, 설계 작성자, 개발팀의 다른 멤버로 구성된다. 어플리케이션의 상세 지식(항공 역학의 물리학과 같은)을 요구하는 단위는 개발 팀의 어플리케이션 전문가에 의해 검사된다.

At a minimum, the inspection team consists of the moderator, the design’s author, and another member of the development team. Units that require detailed knowledge of the application (such as the physics of flight dynamics) are inspected by the development team’s application specialist.


대형 프로젝트에서는 둘 혹은 그 이상의 작성자의 동료들이 설계를 검사하고 품질 보증부의 대표자들이 포함될 수 있다. 검사 받는 컴포넌트와 인터페이스를 하는 서브시스템을 개발하는 팀의 리더들도 역시 참석해야 한다.

On large projects, two or more of the author’s peers will inspect the design and a representative from the quality assurance office may be included. Leaders of teams that are developing subsystems that interface with the components being inspected should also attend.


각각의 검사 세션은 논리적으로 연관된 단위(평균적으로 5~10)을 커버하며, 각각의 설계 그림과 단위 수준의 PDL과 프롤로그들은 완성된다. 세션이 개최되기 수일 전에 검사 받을 자료의 복사본이 검사 팀의 멤버들에게 배포된다.

Each inspection session covers a set of logically related units (5 to 10 on average), for which design diagrams and unit-level PDL and prologs have been completed. Copies of the materials to be inspected are distributed to members of the inspection team several days before the session.


각각의 멤버는 개별적으로 기술적 내용에 대해 검토하고 설계 표준의 부합성에 대해 검토하며 작성자가 발견하지 못한 어떤 문제점들에 대해 comment하기 위해 준비한다. moderator는 에러, 불일치 해결, re-inspection이 필요한지에 대한 판단 등을 기록한다. 작성자는 질문에 대답하고 식별된 문제점들을 해결하기 위한 행동을 취한다. 모든 참가자들은 에러를 찾는 것과 설계가 요구사항에 부합함을 확인하는 데에 책임이 있다.

Each member individually reviews the materials for technical content and adherence to design standards, and comes to the inspection session prepared to comment on any flaws he or she has uncovered. The moderator records the errors, resolves disagreement, and determines whether re-inspection is necessary. The author answers questions and takes action items to resolve the flaws that are identified. All participants are responsible both for finding errors and for ensuring that designs are traceable to requirements.


핵심 검토 기준으로 검사자 들에게 알리기 위해 그림 6-3과 같은 설계 검토 체크리스트는 검사 자료와 함께 배포된다. 마스터 체크리스트는 moderator에 의해 합쳐지고 검사가 완료되었을 때 해당 단위를 인증하기 위해 사용된다.

Design inspection checklists, such as the one shown in Figure 6-3, are distributed to reviewers with the inspection materials to remind them of key review criteria. A master checklist is compiled by the moderator and is used to certify the unit when inspection is complete.



각각의 단위는 시스템을 개발하기 위해 필요하며 각각의 신규 혹은 수정된 단위는 동등한 강도로 검토되어야 한다. 그것이 재사용되는 “중요한” 부분이 아니고 “시시한” 기능의 소프트웨어라는 이유로 해당 단위를 무시하는 것은 재앙이 될 수 있다.

Every unit is important to the developing system and each new or modified unit must be reviewed with equal thoroughness.  Neglecting a unit because it is reused software, it is not part of a “critical” thread, or its functions are “trivial” can be disastrous.


Compiled Prologs and PDL


Ada프로젝트의 상세 설계 단계 동안, 개발 팀은 시스템을 위한 PDL을 생성하고 컴파일 한다. 이 작업을 위해 및 이후 단계의 코드 및 테스트 작업을 위해 STL개발자들은 Ada 소프트웨어 개발 환경의 일부인 도구 세트 및 유틸리티를 사용한다.

During the detailed design phase of an Ada project, the development team generates and compiles all PDL for the system. For this work, and for the code and test activities of subsequent phases, developers in the STL use sets of tools and utilities that are part of an Ada software development environment.





Unit Name                System    Build/Release            

Task Number                            Initial      Inspection      Date     

Inspection  Moderator                                             


KEY INSPECTION QUESTIONS Yes No Corrected Yes No Corrected
1 Does the design present a technically valid way of achieving the unit’s assigned function? [ ] [ ] [ ]
2 Is all data required by the unit available and defined? [ ] [ ] [ ]
3 Is the dependency between each input and output argument and the processing apparent in the design? [ ] [ ] [ ]
4 Is it clear from the design where the outputs from the unit are generated? [ ] [ ] [ ]
5 Is the dependency between each external reference (e.g., unit file, record) and the processing apparent in the design? [ ] [ ] [ ]
6 Does the design include the necessary error detection and recovery logic? [ ] [ ] [ ]
7 Is the design, as written, sufficient to handle the upper and lower bounds associated with unit inputs (especially arguments)? [ ] [ ] [ ]
8 Are the prolog and PDL consistent with the unit’s design diagram? [ ] [ ] [ ]
9 Does the PDL define logic as opposed to code? [ ] [ ] [ ]
10 Does the prolog contain enough information to describe the unit clearly to the unfamiliar reader? [ ] [ ] [ ]
11 Do both the prolog and PDL conform to applicable standards? [ ] [ ] [ ]



(List on a separate sheet.  Refer to questions above by number.)



1.       If all answers to 1-11 were “Yes, ” the unit’s design passes.  Check

here and sign below.                                                                                           [ ]

2.       If there are serious deficiencies in the design (e.g., if more than one

key question was answered “No”) the author must correct the unit design and the moderator must schedule a reinspection.

Scheduled date for reinspection:                                                                                                 

3.       If there are minor deficiencies in the design, the author must correct the unit design and hold a followup meeting with the moderator.

Scheduled date for followup meeting:                                                                                             


Moderator’s signature certifies that this unit meets all applicable standards and satisfies its requirements, and that any identified deficiencies have been resolved (applicable at initial inspection, followup meeting, or reinspection).


Moderator signature:                  Date      



The Ada development environment provides a program library manager that functions as the user interface to the Ada compiler and the linker. The program library manager keeps track of which compilation units are in the library, when they were compiled, which ones have been made obsolete by more recent compilations, and the dependencies among units.


The development environment also includes a language-sensitive editor (LSE). The LSE provides a template for the Ada language that allows developers to enter and edit prologs and PDL interactively.


Ada developers use an additional tool to expedite the generation of package bodies. This utility reads a “bare-bones” package specification, enhances it to conform to local Ada styles (see Reference 22), and uses the specification to build templates for the package body and subprograms.


The other components of the Ada development environment are used primarily during the implementation phase of the life cycle and are described in Section7.




In Ada, the term program library refers not to a library of programs, but to a library of compilation units that comprise one or more programs.  To detect consistency errors before an entire program is constructed, the Ada compiler cross-checks information from separately compiled units. The program library is the mechanism by which the compiler retains the information needed to perform these checks efficiently.



Software Engineering Notebooks (SENs)


상세 설계 단계의 마지막으로, 개발팀의 사서는 시스템의 각각의 단위에 대한 SEN을 생성한다. 개발자는 장치의 프롤로그와 PDL, 단위 디자인 검사 체크리스트, 설계 도면, 설계 의사 결정을 문서화 노트의 현재 목록을 포함하는 장치에 관한 모든 문서를 저장하는 SEN를 사용한다. 유닛 코드, 테스트, 통합을 통해 각 개발자는 자신이 담당하는 유닛에 대한 SENS을 유지한다. 모듈 단위, 코딩, 테스트 및 인증을 받을 때, 형상 관리 아래에 배치 할 준비가 된 것이다; 이 시점에서, 개발자는 프로젝트 라이브러리를 파일 사서에게 SENS를 제공한다.


By the end of the detailed design phase, the development team’s librarian will have created a SEN for each unit and/or module in the system. The developer uses the SEN to store all documentation that pertains to a unit, including the current listing of the unit’s prolog and PDL, the unit design inspection checklist, design diagrams, and notes documenting design decisions. Through unit code, test, and integration, each developer retains the SENs for the units for which he or she is responsible. When the units in a module have been coded, tested, and certified, they are ready to be placed under configuration management; at this point, the developer gives the SENs to the librarian who files them in the project library.


이 문서에서, 용어 “모듈”은 논리적으로 관련된 유닛들의 컬렉션을 나타내는 데 사용된다. 비행 역학 환경에서, 모듈은 일반적으로 5 ~ 10 단위로 구성되어 있다.


Throughout this document, the term “module” is used to denote a collection of logically related units.  In the flight dynamics environment, a module usually consists of 5 to 10 units.





Ada 프로젝트에서 하나 SEN은 각 패키지의 저장 문서에 사용된다. 즉, 현재의 명부, 검사 체크리스트, 패키지의 사양, 몸에 관련 설계 도면이며, 서브 프로그램은 하나의 노트북에서 함께 유지된다.


On Ada projects, one SEN is used to store documentation for each package.  That is, the current listings, inspection checklists, and relevant design diagrams for the package’s specification, body, and subprograms are maintained together in a single notebook.




주요 측정지표들(Objective Measures)


CPU 시간 – 예비 설계 단계에서 사용되는 객관적인 측정은 하나의 추가와 세부 설계에 사용되는 척도이다. 다음과 같이 수집 할 조치는 다음과 같다:


  • 식별 번호 대 인증 된 기기 디자인의 수이다.
  • 요구사항 질문 및 답변, TBDs, 변경사항들.
  • 직원의 시간
  • 시스템의 크기, 노력, 일정 및 재사용 추정
  • 날짜에 사용 된 총 CPU 시간


이러한 데이터의 소스와 데이터 수집 및 평가 주기를 표 6-1에 나타낸다. 다음 단락은 상세 설계 시 이러한 조치를 평가하기 위한 구체적인 권장 사항을 제공하고, 5 절에 나와있는 지침을 보완한다.


The objective measures used during the preliminary design phase are also the yardsticks used for detailed design, with one addition — CPU hours. The measures to be collected are as follows:


  • The number of unit designs that have been certified versus the number identified
  • Requirements questions and answers, TBDs, and changes
  • Staff hours
  • Estimates of system size, effort, schedule, and reuse
  • Total CPU hours used to date


The source of these data and the frequency of data collection and evaluation are shown in Table 6-1. The paragraphs that follow provide specific recommendations for evaluating these measures during detailed design, and supplement the guidance given in Section 5.



평가 범주(Evaluation Criteria)


TBD 요구사항의 개수는 이 단계에서 중요한 메트릭이다. 이상적으로, 모든 TBD 요구사항들은 이 단계의 마지막에 해결된다. 만약 이 목표가 달성하기 불가능한 경우, 관리 팀은 나머지 TBDs 시스템 크기, 시스템 설계, 직원 시간, 비용 및 일정에 미치는 영향을 평가 한 다음 계속의 타당성을 평가해야 한다. 비행 역학 환경에서 요구사항의 총 수의 10 % 이상이 TBD인 경우 또는 “미션 크리티컬” 요구사항이 해결되지 않은 남아있는 경우에 구현은 연기되어야 한다.


The number of TBD requirements is a vital metric in this phase. Ideally, all TBD requirements are resolved by the end of the phase. If this goal is impossible to achieve, the management team must assess how the remaining TBDs will affect system size, system design, staff hours, costs, and schedule, and then evaluate the feasibility of continuing. In the flight dynamics environment, implementation should be postponed if “mission critical” requirements remain unresolved or if more than 10 percent of the total number of requirements are still TBD.


상세 설계 단계에서의 사양 변경의 많은 수는 일반적으로 요구사항 및 사양이 불안정하거나 잘못된 것을 나타낸다. 관리 팀은 사양 변경의 수준이 구현 및 시스템 테스트 단계에 걸쳐 높은 수준으로 유지된다고 가정한다. (그림 6-4) 그에 따라 시스템의 크기는 예상과 계획을 재평가 해야 한다.


A large number of specification modifications in the detailed design phase is usually an indication that requirements and specifications are unstable or erroneous. The management team must assume that the level of specification modifications will remain high throughout the implementation and system test phases, and should reevaluate system size estimates and schedules accordingly (Figure 6-4).


예비 설계의 마지막에서 관리자는 시스템에서 단위의 예상 개수를 안다. 상세 설계 단계의 마지막에서 새로운 시스템에 그들을 통합하는데 필요한 변경의 정도와 함께 재사용되어야 하는 모든 단위는 식별된다. 관리자는 개발을 완료하는 데 필요한 노력의 시간 및 인력 수준을 다시 추정하기 위해 과거 프로젝트에서 생산성의 속도로 새로운 그림을 결합 할 수 있다. (이러한 추정치를 계산하는 지침 참조 (12)의 표 3-2를 참조하십시오.)


12. Software Engineering Laboratory, SEL-84-101, Manager’s Handbook for Software Development (Revision 1), L. Landis, F. McGarry, S. Waligora, et al., November 1990


By the end of preliminary design, managers know the projected number of units in the system. By the end of the detailed design phase, all units to be reused will have been identified, along with the degree of modification needed to incorporate them into the new system. Managers can combine these new figures with productivity rates from past projects to re-estimate the effort hours and staffing levels necessary to complete development. (See Table 3-2 of Reference 12 for guidance in computing these estimates.)


해당 단계의 거의 마지막에서 많은 유닛이 “재사용” 카테고리에서 “신규” 카테고리로 이동하는 경우 크기 추정은 예기치 않게 부풀어 오를 수 있다. 관리자들은 기존 단위보다는 신규 유닛을 결정하기 위한 결정이 정당화 되고 단지 NIH(“여기에 개발되지 않음”) 증후군의 표현이 아님을 확실하게 해야 할 필요가 있다.


Near the end of the phase, size estimates can balloon unexpectedly if many units are moved from the “reused” to the “new” category. Managers need to ensure that decisions to create new units rather than reuse existing ones are justified and not merely a manifestation of the NIH (“not invented here”) syndrome.


CPU시간 혹은 세션/작업 실행의 개수로 표현되는 컴퓨터 사용은 설계 및 구현 단계에서 진행의 주요 지표이다. 일반적인 항공 역학 프로젝트에서, 작은 정도의 CPU시간은 설계 단계에서 기록되어야 하는데, 이는 개발 팀이 프로토타이핑 노력과 PDL을 진입하기 때문이다. Ada PDL은 컴파일되기 때문에 보다 많은 CPU시간이 Ada프로젝트에서 기록되어야 한다.


Computer use, as expressed in CPU hours or the number of sessions/job runs, is a key indicator of progress during design and implementation. On a typical flight dynamics project, a small amount of CPU time should be recorded during the design phases as the development team conducts prototyping efforts and enters PDL. Because Ada PDL is compiled, more CPU time should be logged on Ada projects.


Recent SEL studies have shown that the relative cost of reusing existing units, as a percentage of the cost to develop the unit newly, is 20 percent for FORTRAN projects and 30 percent for Ada projects. The higher percentage for Ada is correlated to a significantly greater proportion of reused to new units on these projects as compared with FORTRAN efforts.


Table 6-1.  Objective Measures Collected During the Detailed Design Phase




Figure 6-4.  Example of the Impact of Requirements Changes on Size Estimates — the UARS Attitude Ground Support System




A lack of CPU hours on a project that is three-quarters of the way through the detailed design phase should raise a red flag. The management team should investigate to determine whether the team is avoiding using the computer because of inadequate training or is mired in redesign as a result of specification modifications




The development team’s primary product for this phase is the completed design for the system, including unit prologs and PDL, as recorded in the detailed design document. In addition, the management team produces a build plan for implementing the design, and the development team begins to develop build test plans. These products are described in the paragraphs that follow


상세 설계 문서(Detailed Design Document)


상세 설계 단계에서 예비 설계 보고서가 확장 및 상세 설계 활동의 결과를 반영하기 위해 정제된다. CDR 전에 이 상세 설계 문서가 완료되고 검토를 위해 배포. 문서의 형식과 내용은 그림 6-5에 나와 있다.

During the detailed design phase, the preliminary design report is expanded and refined to reflect the results of detailed design activities. Before CDR, this detailed design document is completed and distributed for review. The format and contents of the document are shown in Figure 6-5.


빌드 계획(The Build Plan)


빌드 계획 구현 단계 시스템 구축에 적용 할 전략을 설명한다. 계획은 소프트웨어 구성 요소는 실행 가능한 코드와 서브 시스템이 서브 시스템은 시스템에 결합되는 순서에 통합되는 순서를 정의한다.

The build plan describes the strategy that will be applied in constructing the system during the implementation phase. The plan defines the sequence in which software components are coded and integrated into executable subsystems and the order in which these subsystems are combined into systems.


이 계획은 일반적으로 세 부분이 포함되어 있다

  • 각 빌드 또는 릴리스에서 제공 될 기능의 나열
  • 특정 빌드에 지정된 기능을 제공하기 위해 관련 제약 조건을 포함한 이론적 근거
  • 구현 일정


The plan usually contains three parts:

  • An itemization of the capabilities that will be provided in each build or release
  • The rationale, including relevant constraints, for providing specified capabilities in a particular build
  • The implementation schedule


예비 빌드 계획은 일반적으로 예비 설계 단계에서 생성된다. 상세 설계시, 빌드 전략 단계의 결론에서, 업데이트 된 전략이 SDMP에 포함되어 있으며 CDR에서 평가를 제시 할 때까지 확장하고 refine한다.

A preliminary build plan is usually generated during the preliminary design phase. During detailed design, the build strategy is expanded and refined until, at the conclusion of the phase, the updated strategy is included in the SDMP and presented for evaluation at the CDR.


빌드는 운영 능력 또는 중간 제품에 대한 사용자의 요구를 수용 할 수 있도록 계획해야 한다. 계획은 또한 변동과 TBD 요구사항을 허용해야 한다. 초기 개발 팀 기술적 관점에서 시스템을 구현하기 위한 최적 계획을 결정한다. 관리 팀은 계획을 분석하고 사용자, 외부 (예를 들어, 임무) 일정, 사양 변경, 알려지지 않은 것을 조정하기 위해 어떻게 해야 할지 결정한다. 최적의 및 조정 계획은 모두 CDR에 표시된다.

Builds must be planned to accommodate user needs for operational capabilities or intermediate products. Plans must also allow for fluctuating and TBD requirements. Initially, the development team determines the optimum plan for implementing the system from a technical viewpoint. The management team then analyzes the plan and decides how it must be perturbed to accommodate the user, external (e.g., mission) schedules, specification modifications, and unknowns. Both the optimum and adjusted plans are presented at CDR.


프로젝트 기능으로 필요한 빌드 및 릴리즈의 수를 결정하기 위한 가이드로 빌드와 릴리즈에 대한 용어는 Section 2를 참조한다.


See SECTION 2 for definitions of the terms build and release and for guidance in determining the number of builds and releases that are needed as a function of project size.


추가적인 빌드는 클린 룸의 방법론을 사용하는 프로젝트에 필요하다. 클린 룸 프로젝트에서, 빌드는 쉽게 테스트되고 통합될 수 있는 소프트웨어의 일부들로 구성되어야 하며 2~3달 이 지속되지 않아야 한다.


Additional builds are required on projects using Cleanroom methodology.  On Cleanroom projects, a build should consist of portions of the software that can be readily tested and integrated together and should last no more than 2 or 3 months.





This document is the primary product of the detailed design phase. To complete the document, the development team updates similar material from the preliminary design report and adds greater detail. The suggested contents are as follows:


  1. Introduction — purpose and background of the project, overall system concepts, and document overview


  1. Design overview
    1. Design drivers and their order of importance
    2. Reuse strategy
    3. Discussion and high-Ievel diagrams of the selected system design, showing hardware interfaces, external data interfaces, interconnections among subsystems, and data flow
    4. Traceability matrix of major components against requirements and functional specifications
    5. Design status
      • List of constraints, concerns, and problem areas and their effects on the design
      • List of assumptions and possible effects on design if they are wrong
      • List of TBD requirements and an assessment of their effect on system size, required effort, cost, and schedule
      • ICD status
      • Results of prototyping efforts
    6. Development environment


  1. Operations overview
    1. Operations scenarios/scripts
    2. System performance considerations


  1. Design description for each subsystem or major functional breakdown:
    1. Overall subsystem  capability
    2. Assumptions about and restrictions to processing in each mode
    3. Discussion and high-Ievel diagrams of subsystem, including interfaces, data flow, and communications for each processing mode
    4. High-Ievel description of input and output
    5. Detailed description of processing keyed to operator-specified input and actions in terms of points of control, functions performed, and results obtained (both normal and abnormal, e., error processing and recovery)
    6. Structure charts or object-oriented diagrams expanded to the unit level, showing interfaces, data flow, interactive control, interactive input and output, and hardcopy output
    7. Internal storage requirements, e., description of arrays, their size, their data capacity in all processing modes, and implied limitations of processing
    8. Detailed input and output specifications
      • Processing control parameters, g., NAMELISTs
      • Facsimiles of graphic displays for interactive graphic systems
      • Facsimiles of hardcopy output
    9. List of numbered error messages with description of system’s and user’s actions
    10. Description of COMMON areas or other global data structures
    11. Prologs and PDL for each unit (normally kept in a separate volume because of size)


  1. Data interfaces—updated from description in preliminary design report (see Figure 5-5)

Figure 6-5. Detailed Design Document Contents


각 빌드는 요구사항 및 사양의 일관성 있는 집합을 해결하고 구현하는 3 ~ 5 개월이 걸린다. 각 빌드가 완료 단위의 집합을 포함해야 한다; 즉, 빌드 계획은 이후 빌드 동안의 개별 단위에 대한 수정이나 개선을 요구하지 않아야 한다.

Each build should address a coherent subset of the requirements and specifications and take three to five months to implement. Each build should cover a set of completed units; that is, the build plan should not require modifications or enhancements to individual units during later builds.


첫 번째 빌드는 개발 팀이 개발 환경 또는 사용되는 프로그래밍 언어에 익숙하지 않은 경우 특히, 간단하게 유지해야 한다. 이후의 빌드는 성능 요구사항, 주요 제어 기능, 시스템 및 유저 인터페이스와 같은 높은 위험 사양, 중요한 소프트웨어 기능을 다루어야 한다. 빌드 전략은 소프트웨어 설계의 주요 영향을 가질 수 있는 기능들이 조기에 완료될 수 있도록 하여 발견된 문제를 처리할 수 있는 시간이 충분해야 한다.

The first build must be kept simple, particularly if the development team is unfamiliar with the development environment or programming language being used. The next builds should address high-risk specifications and critical software capabilities, such as performance requirements,        major   control functions, and system and user interfaces.  The build strategy must ensure that capabilities that can have a major impact on the software design are completed early, so that any problems can be handled while there is still time to recover.


마지막 빌드는 사양 변경의 구현과 이전 빌드의 남아있는 문제의 해결을 포함하도록 성장할 것이기 때문에, 초기 계획에 작게 유지되어야 한다. 그러므로 끝에서 두 번째(next-to-last)빌드는 모든 중요한 시스템 기능을 제공해야 한다. 시스템에 새로운 기능을 추가 사양 변경을 구현 단계 동안 수신하는 경우, 그 단계를 확장하는 추가적인 빌드는 기존 빌드가 일정대로 진행될 수 있는지를 확인해야 할 필요가 있다.

Since the last build will grow to include the implementation of specification modifications and the resolution of problems remaining from earlier builds, it should be kept small in initial planning. The next-to-last build, therefore, must supply all crucial system capabilities. If specification modifications that add new features to the system are received during the implementation phase, additional builds that extend the phase may be needed to ensure that existing builds can proceed on schedule.


In the flight dynamics environment, the initial build (B1) usually provides the core capabilities needed in a functioning system. Middle builds (B2 to Bn-1) supply all critical capabilities. The last build (Bn) is restricted to “bells and whistles” and problem fixes.



The build plans for flight dynamics projects also include the dates by which developers need to receive unit-level, analytic test plans from the acceptance test team. See SECTION 7 for detailed information about the purpose and content of these plans.


빌드 시험 계획(Build Test Plans)


빌드가 정의된 후, 개발 팀은 소프트웨어가 설계한대로 동작하는지의 검증을 하기 위해 수행할 시험을 명세하기 시작할 수 있으며 빌드나 릴리즈에 할당된 기능을 제공한다. 개발 팀은 빌드의 통합 이후 즉시 빌드 시험 계획을 수행한다.

As soon as a build has been defined, the development team can begin to specify the tests that will be conducted to verify that the software works as designed and provides the capabilities allocated to the build or release. The development team executes the build test plan immediately following integration of the build.


첫 번째 빌드에 대한 테스트 계획은 상세 설계 단계에서 정의된다. 첫 번째 테스트 계획을 정의하는 결과로 만들어지는 전체 테스트 전략에 대한 수정은 CDR에 표시된다.

The test plan for the first build is defined during the detailed design phase. Any modifications to the overall testing strategy that are made as a result of defining this first test plan are presented at the CDR.


나머지 빌드에 대한 테스트 계획은 구현 단계에서 생성된다.

빌드 테스트 계획의 형식과 내용은 7 절에 설명되어 있다.


Test plans for the remaining builds are generated during the implementation phase.

The format and content of build test plans are described in Section 7.






상세 설계 단계는 CDR에서 절정이 된다. 이 리뷰는 개발 팀과 관리자, 요구사항 정의팀과 관리자, 품질 보증 대표, 사용자 대표, CCB, 시스템과 관련된 사람이 참여한다. 참가자는 디자인 구현을 시작하기에 충분히 정확하고 완전한 있는지 여부를 확인하기 위해 시스템의 상세 설계를 평가한다. 그들은 또한 구현 일정과 기능이 가능한 수 있는 빌드에 할당하도록 빌드 계획을 검토한다.


The detailed design phase culminates in the CDR. This review is attended by the development team and its managers, the requirements definition team and its managers, quality assurance representatives, user representatives, the CCB, and others involved with the system. Participants evaluate the detailed design of the system to determine whether the design is sufficiently correct and complete for implementation to begin. They also review the build plan to ensure that the implementation schedule and the capabilities allocated to the builds are feasible.


CDR의 중점은 요구사항, 높은 수준의 디자인, 시스템 운영 및 PDR 이후의 개발 계획에 대한 수정에 있다. 그들이 검토의 초점이 될 수 있도록 스피커, 슬라이드 및 프레젠테이션 하는 동안이 두 가지 변화를 강조한다. CDR은 관리, 미션 프로젝트 사무실, 품질 보증 직원 및 CCB에 대한 관심은 항공 문제에 대한 개발 팀을 위한 기회를 제공한다.


The emphasis at CDR is on modifications to requirements, high-level designs, system operations, and development plans made since the PDR. Speakers should highlight these changes both on the slides and during their presentations, so that they become the focus of the review. The CDR also provides an opportunity for the development team to air issues that are of concern to management, the mission project office, quality assurance personnel, and the CCB.


그림 6-6은 권장 CDR의 형식을 보여준다. CDR의 하드 카피 재료의 개요 및 제안 내용은 그림 6-7에 제시되어있다. PDR에 덮여 그 자료를 참고 변경 내용을 대조하기 위해 필요한 경우를 제외하고, 다시 제공되지 않는다. 이 간결한 형식을 적용하려면, 참가자들은 프로젝트의 배경, 요구사항 및 디자인에 대해 잘 알고 있어야 한다. 그들은 PDR에 참석하고 회의 전에 상세 설계 문서를 공부해야 한다.


Figure 6-6 shows the recommended CDR format. An outline and suggested contents of the CDR hardcopy material are presented in Figure 6-7. Note that material that was covered at PDR is not presented again, except as needed to contrast changes. For this concise format to be effective, participants must be familiar with the project background, requirements, and design. They should have attended the PDR and studied the detailed design document before the meeting.


대규모 프로젝트의 경우, CDR 시스템의 모든 측면을 커버하기 위해 변화하는 요구사항을 수용하기 위해 각각의 주요 서브 시스템 및 / 또는 릴리스 개최한다. 이러한 프로젝트에, 그것은 하나의 검토, 즉, 높은 수준에서 전체 시스템을 포함하는 시스템 설계 검토를 하는 것이 중요하다.


For very large projects, a CDR should be held for each major subsystem and/or release in order to cover all aspects of the system and to accommodate changing requirements. On such projects, it is vital to have one review, i.e., a System Design Review that covers the entire system at a high level.


CDR에서 구성 요소의 수와 비율이 다시, 이 중 어느 될 보여주는 개발자 본 통계는 RSL에서 그려집니다. 또한 자세한 재사용 전략의 현재 키 포인트는 PDR 이후 되었다. 재사용 제안에 변경 사항을 확인하고, 새로운 / 수정 재사용 트레이드 오프 분석에 대해 설명한다.


At the CDR, developers present statistics showing the number and percentage of components to be reused, and which of these are drawn from the RSL. They also present key points of the detailed reuse strategy, identify any changes to the reuse proposal that have been made since PDR, and describe new/revised reuse tradeoff analyses.


Reviewers should address the following questions:

  • 설계는 모든 요구사항과 명세를 만족하는가?
  • 운영상의 시나리오는 수용할 만한가?
  • 설계는 정확한가? 명세된 변환이 입력으로부터 정확한 출력을 생성하는가?
  • 설계는 강건한가? 잠재적 오류에 대한 사용자 입력을 처리하기 전에 점검하는가?
  • 모든 설계 가이드라인과 표준들을 따랐는가? 어떻게 데이터 사용 및 접근이 지역화되었는가? 단위들간의 커플링(유닛간 의존성)이 최소화되었는가? 각각의 유닛은 내부적으로 응집력이 있는가? (유닛은 단일 목적으로 사용하는가?)
  • 설계는 시험 가능한가?


  • Does the design satisfy all requirements and specifications?
  • Are the operational scenarios acceptable?
  • Is the design correct? Will the transformations specified produce the correct output from the input?
  • Is the design robust? Is user input examined for potential errors before processing continues?
  • Have all design guidelines and standards been followed? How well have data usage and access been localized? Has coupling between units (i.e., inter unit dependency) been minimized? Is each unit internally cohesive (i.e., does it serve a single purpose)?
  • Is the design testable?
  • Is the build schedule structured to provide early testing of end- to-end system capabilities? Is the schedule reasonable and feasible for implementing the design?



Presenters — software development team



•    Requirements definition team

•    Quality assurance representatives from  both teams

•    Customer interfaces for both teams

•    User representatives

•    Representatives of interfacing systems

•    System capacity/performance analysts

•    CCB


Attendees should be familiar with the project background, requirements, and design.


Schedule — after the detailed design is completed and before implementation is begun


Agenda — selective presentation of the detailed design of the system. Emphasis should be given to changes to the high-level design, system operations, development plan, etc. since PDR.


Materials Distribution

• The detailed design report is distributed at least 10 days before the CDR.

• Hardcopy material is distributed a minimum of 3 days before the review.


Figure 6-6.  CDR Format




1.         Agenda — outline of review material


2.         Introduction — background of the project, purpose of the system, and an agenda outlining review materials to be presented


3.         Design overview — major design changes since PDR (with justifications)

a.   Design diagrams, showing products generated, interconnections among subsystems, external  interfaces

b.   Mapping of external interfaces to ICDs and ICD status


4.         Results of prototyping efforts


5.         Changes to system operation since PDR

a.   Updated operations scenarios/scripts

b.   System  performance  considerations


6.         Changes to major software components since PDR (with justifications)


7.         Requirements traceability matrix mapping requirements to major components


8.         Software reuse strategy

a.   Changes to the reuse proposal since PDR

b.   New/revised reuse tradeoff analyses

c.   Key points of the detailed reuse strategy, including software components to be reused in future projects

d.   Summary of RSL contributions — what is used, what is not, reasons, statistics


9.         Changes to testing strategy

a.   How test data are to be obtained

b.   Drivers/simulators to be built

c.   Special considerations for Ada testing


10.         Required resources — hardware required, internal storage requirements, disk space, impact on current computer usage, impacts of compiler


11.         Changes to the SDMP since PDR


12.         Implementation dependencies (Ada projects) — the order in which components should be implemented to optimize unit/package testing


13.         Updated software size estimates


14.         Milestones and schedules including a well-thought-out build plan


15.         Issues, risks, problems, TBD items

a.   Review of TBDs from PDR

b.   Dates by which TBDs and other issues must be resolved



Figure 6-7. CDR Hardcopy Material





To determine whether the development team is ready to proceed with implementation, the management team should consider the following questions:


  • 모든 설계 다이어그램이 단위 수준까지 완성되었는가? 모든 외부 및 내부 인터페이스가 완벽하게 명세 되었는가?
  • Are all design diagrams complete to the unit level? Have all interfaces — external and internal — been completely specified?


  • PDL과 프롤로그는 모든 유닛에 대해 존재하는가? 모든 단위 설계가 검사되었는가?
  • Do PDL and prologs exist for all units? Have all unit designs been inspected and certified?


  • 모든 TBD 요구사항들이 해결되었는가? 만약 아니라면 어떻게 남은 TBD들이 현재 시스템 설계에 영향을 끼치는가? 구현 전에 결정되어야 하는 중요 요구사항들이 진행될 수 있는가?
  • Have all TBD requirements been resolved? If not, how will the remaining TBDs impact the current system design? Are there critical requirements that must be determined before implementation can proceed?


  • 상세 설계 단계에 대한 주요 종료 기준이 만족되었는가? 상세 설계 문서가 완성되고, CDR이 성공적으로 수행되고 모든 응답들이 모든 CDR RID로 제공되는가?
  • Have the key exit criteria for the phase been met? That is, has the detailed design document been completed, has the CDR been successfully concluded, and have responses been provided to all CDR RIDs?


모든 설계 산출물이 생성되고 중요하지 않은 요구사항이 TBD로 남아 있다면 구현 단계는 시작할 수 있다.

When all design products have been generated and no critical requirements remain as TBDs, the implementation phase can begin.