카테고리 보관물: software architecture

상태 분석을 활용한 복잡한 임베디드 시스템에 대한 요구사항 생성하기


Motivation

시스템 엔지니어가 작성한 소프트웨어 요구사항과 소프트웨어 엔지니어가 작성한 코드상의 차이가 크다.

소프트웨어 엔지니어는 요구사항을 코드로 번역하여 시스템 엔지니어가 의도한 시스템의 행동에 부합하다는 기대를 해야만 한다.

해결 방법: State analysis방법을 사용하여 명시적으로 표현한다.

원문 – Generating requirements for complex embedded systems using state analysis

Introduction

State analysis방법론은 다음의 3가지 기본적 원칙을 주장(assert)한다.

  • control은 system operation의 모든 측면을 포함한다. system under control의 모델을 통해 이해될 수 있음
  • system under control의 모델은 명시적으로 식별되고 시스템 엔지니어들 사이의 합의된 것들을 보장하는 방식이어야 함
  • 소프트웨어 설계 및 운영에 영향을 미치는 모델링 방식은 직접적이고 최소한의 번역(translation)을 해야 한다.

State based control architecture

시스템 model을 구현한 소프트웨어는 크게 4가지의 block으로 이루어져 있다.

  • State estimation – System under control에 대해 관찰하고 계측을 통해 시스템의 상태를 예측하는 모듈
  • Hardware Adapter – System under control을 관찰하거나 자극을 주거나 하는 모듈
  • State control – State knowledge를 토대로 시스템의 goal을 달성하기 위해 system under control을 제어하기 위한 방법을 결정하는 모듈
  • State knowledge – State estimation정보로부터 state transition을 시키고 시스템의 상태값을 변경시키는 모듈

 

state based control architecture

State의 정의

시스템의 상태와 그 상태에 대한 우리의 지식이 같은 것이 아니다. 실제로의 상태는 매우 복잡하지만 우리의 인식상에서는 유용한 것들만 추려서 의도에 맞도록 추상화를 시킬 수 있는데, 우리는 이러한 추상화를 “상태 변수”라고 부른다. 시스템의 알려진 상태는 관심 시점(time)에서의 그것의 상태변수의 값이다.

The state of a system and our knowledge of that state are not the same thing. The real state may be arbitrarily complex, but our knowledge of it is generally captured in simpler abstractions that we find useful and sufficient to characterize the system state for our purposes. We call these abstractions “state variables”.
The known state of a system is the value of its state variables at the time of interest.

상태 변수의 사례로는 다음과 같은 것들이 있을 수 있다.

• device operating modes and health;
• resource levels (e.g., propellant; volatile and nonvolatile memory);
• temperatures and pressures;
• environmental states (e.g., motions of celestial bodies and solar flux);
• static states about which we may want to refine our knowledge (e.g., dry mass of a spacecraft);
• parameters (e.g., instrument scale factors and biases, structural alignments, and sensor noise levels); and
• states of data collections, including the conditions under which the data was collected, the subject of the data, or any other information pertinent to decisions about its treatment.

 

Modeling process

  1. Identify needs—define the high-level objectives for controlling the system.
  2. Identify state variables that capture what needs to be controlled to meet the objectives, and define their representation.
  3. Define state models for the identified state variables—these may uncover additional state variables that affect the identified state variables.
  4. Identify measurements needed to estimate the state variables, and define their representation.
  5. Define measurement models for the identified measurements—these may uncover additional state variables.
  6. Identify commands needed to control the state variables, and define their representation.
  7. Define command models for the identified commands—these may uncover additional state variables.
  8. Repeat steps 2–7 on all newly discovered state variables, until every state variable and effect we care about is accounted for.
  9. Return to step 1, this time to identify supporting objectives suggested by affecting states (a process called ‘goal elaboration’, described later), and proceed with additional iterations of the process until the scope of the mission has been covered.

 

Example

논문 참조, skip

 

Control system을 설계하기 위해 모델을 활용하기

Goals

State analysis에서 goal은 time interval에 대한 상태 변수의 값의 기록에 대한 제약사항이다. 좀 쉽게 표현한다면 시스템이 수행되는 동안 반드시 만족되어야 하는 속성 정도로 표현할 수 있겠다. 예를 들면 카메라의 온도가 x와 y온도 사이에 반드시 있어야 한다는 것이 있을 수 있겠다.

Goal은 상태 변수의 값에 대한 이력에 대해 성공/실패를 판정할 수 있는 기준이 될 수 있다. (위의 사례에서 예를 들면 만약 카메라의 온도가 x-10일 경우 (해당 속성이 만족되어야 하는 시점에서) 위의 속성은 시스템에 부합하지 못함을 의미한다.

결국, 이 Goal이라고 하는 것은 model checking에서 검증되어야 하는 시스템에 대한 검증 속성으로도 볼 수 있다. Formal verification이 이렇게 연결이 될 수 있는 것이다. 결국 Goal을 식별한다는 말의 의미는 검증할 시스템이 만족되어야 하는 시스템의 속성을 추출하는 과정이라고 볼 수 있다. 

goal의 사례들

  1. Camera temperature is between 10 and 20 ◦C from 2:00 pm to 3:00 pm (control goal that specifies a constraint on state value, to be maintained by controller).
  2. Camera temperature is transitioning to be between 10 and 20 ◦C by 2:00 pm (transitional control goal that achieves the appropriate precondition for goal #1).
  3. Camera temperature standard deviation is less than 0.5 ◦C from 1:00 pm until 5:00 pm (knowledge goal that specifies a constraint on quality of state knowledge, to be maintained by estimator).
  4. Camera temperature mean value, plus or minus 3-sigma, is in the range 10–20 ◦C [10<= mean −3 sigma <= mean + 3 sigma <=20], from 2:00 pm to 3:00 pm (inseparably-combined control and knowledge goal, specifying constraints on both state value and quality of knowledge).
  5. Camera temperature measurement data collection state contains at least one measurement less than 10s old, from 1:00 pm until 5:00 pm (data goal, specifying a constraint on the state of a data collection).

 

goal의 정교화

시스템의 모델로부터 goal을 100% 추출하는 것은 한계가 있다. 그래서 goal을 정교화하는 작업이 별도로 필요한데, 본 논문에서는 정교화작업을 위한 4개의 규칙을 정의하였다.

  1. A goal on a state variable may elaborate into concurrent control goals on directly affecting state variables.
  2. A control goal on a state variable elaborates to a concurrent knowledge goal on the same state variable (or they may be specified jointly in a single control and knowledge goal).
  3. A knowledge goal on a state variable may elaborate to concurrent knowledge goals on its affecting and affected state variables.
  4. Any goal can elaborate into preceding goals (typically on the same state variable). For example, a “maintenance” goal on a state variable may elaborate to a preceding transitional goal on the same state variable.

 

Goal을 정교화하는 방법의 사례

아래의 예는 1개의 goal로 부터 5개의 추가적인 goal을 식별하는 사례를 나타내주고 있다.

goal elaboration example

결론

  • 시스템 모델을 소프트웨어로 구현하기 위한 architecture framework을 제시함
  • State variable을 활용하여 시스템의 상태를 식별하고, 시스템이 만족해야 하는 속성을 식별함
  • model checking의 본질적인 문제점인 completeness를 보완함
  • Stateflow modeling시에 Modeling 및 model check를 사용하고자 할 때 도움이 될 것으로 기대함
  • 향후 작업으로 Stateflow modeling을 위한 framework를 개발할 때 참조될 수 있을 것으로 기대함

Section 6. 상세 설계 단계


목차

 

SECTION 6 상세 설계 단계

THE DETAILED DESIGN PHASE

6.0

개요

OVERVIEW

 

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

 

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.

 

활동들(KEY ACTIVITIES)

개발 팀은 세부 설계를 생성하는 동안, 요구사항 정의의 팀은 나머지 요구사항의 문제와 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.

6.1

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

 

6.2

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

 

방법과 도구들(METHODS AND TOOLS)

 

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

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.

 

TAILORING NOTE

 

별도의 정형화된 디자인 워크스루는 항상 작은 도구 개발 노력으로 유지되는 것은 아니다. 이런 프로젝트에서 워크스루는 설계 검토와 결합될 수 있다. 검토는 일반적으로 비형식적인데, 점검되는 제품은 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 DESIGN INSPECTION CHECKLIST

 

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)? [ ] [ ] [ ]
ADDITIONAL INSPECTION QUESTIONS
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? [ ] [ ] [ ]

 

ACTION ITEMS AND COMMENTS

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

 

INSPECTION RESULTS

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.

 

DEFINITION

 

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.

 

 

TAILORING NOTE

 

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.

 

측정(MEASURES)

 

주요 측정지표들(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

6.3

 

6.4

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

 

산출물(PRODUCTS)

 

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.

 

 

DETAILED DESIGN DOCUMENT

 

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.

bn

 

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.

 

 

 

중요 설계 검토(CRITICAL DESIGN REVIEW)

 

상세 설계 단계는 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?

 

CDR 형식(CDR FORMAT)

Presenters — software development team

 

Participants

•    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

 

HARDCOPY  MATERIAL  FOR  THE  CDR

 

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

 

종료 기준(EXIT CRITERIA)

 

 

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.

Section 5. 예비 설계 단계


목차

 

 

SECTION 5 예비 설계 단계

5.0

개요

예비 설계 단계의 목적은 유용한 시스템의 요구 사양을 만족시키고 상위 수준 소프트웨어 아키텍처를 정의하는 것이다.

예비 설계하는 동안 개발 팀은 다른 디자인(alternative design)을 개발하고 최적의 방법을 선택하기 위해 업데이트 된 요구사항 및 사양 문서를 사용한다. 팀은 주요 서브 시스템으로 시스템을 분할할 모든 시스템 및 서브 시스템 인터페이스를 지정하고, 구조적 차트 나 주석 디자인 다이어그램을 사용하여 디자인을 설명한다. 개발자는 기능적 분해 또는 객체 지향 설계 방법이 선택되었는지 여부에 따라 다소 다르게 반복적 설계 프로세스를 사용하여 진행한다.

The purpose of the preliminary design phase is to define the high- level software architecture that will best satisfy the requirements and specifications for the system.

During preliminary design, the development team uses the updated requirements and specifications document to develop alternative designs and to select an optimum approach. The team partitions the system into major subsystems, specifies all system and subsystem interfaces, and documents the design using structure charts or annotated design diagrams. Developers use an iterative design process that proceeds somewhat differently, depending on whether a functional decomposition or object-oriented design approach is chosen.

 

초기에 이 단계에서, 개발자는 재사용을 위해 후보자 및 전반적인 시스템 요구사항과의 호환성과 새로운 디자인을 확인 소프트웨어 구성 요소를 검사한다. 요구사항 분석 단계 동안의 시작된 프로토타이핑 활동을 계속하고 새로운 프로토타이핑 노력이 개시 될 수 있다. 개발자는 또한, 오류 처리 및 복구 전략을 정의하는 사용자 입력 및 표시를 결정하고 운영 시나리오를 업데이트한다.

Early in this phase, developers examine the software components that are candidates for reuse and verify their compatibility with overall system requirements and the emerging design. Prototyping activities begun during the requirements analysis phase may continue and new prototyping efforts may be initiated. Developers also define error-handling and recovery strategies, determine user inputs and displays, and update operational scenarios.

 

이 단계에서, 개발 팀은 요구사항의 모호성과 TBDs를 해결하기 위해 요구사항 정의 팀의 분석과 긴밀하게 협력한다. 새로운 디자인은 시스템의 요구사항을 충족하는지 확인하기 위해 개발자가 피어 리뷰 혹은 워크스루를 수행한다. 그리고 분석가에게 주제에 대한 공식 요구사항의 질문을 보낼 수 있다.

During this phase, the development team continues to work closely with analysts of the requirements definition team to resolve requirements ambiguities and TBDs. To ensure that the emerging design meets the system’s requirements, developers send formal requirements questions to analysts for clarification, conduct walk-throughs, and subject all design products to peer inspection.

 

예비 설계 단계는 개발자가 높은 수준의 시스템 설계를 선택하기 위한 이론적 근거를 제시하는 동안 예비 설계 검토 (PDR)에 절정에 이른다. 예비 설계 보고서는 초기 시스템 디자인을 문서화 전에 PDR에 대한 검토를 위해 배포된다.

The preliminary design phase culminates in the preliminary design review (PDR), during which developers present the rationale for selecting the high-level system design. The preliminary design report documents the initial system design and is distributed for review prior to the PDR.

 

Tailoring Note

재활용도가 높은 프로젝트에서 예비 및 상세 설계 단계는 결합될 수 있다. 이 경우, 예비 및 상세 설계 활동을 실시하지만, 개발자들은 CDR을 보유하며 상세 설계 보고서만 생성한다.

On projects with a high degree of reuse, the preliminary and detailed design phases may be combined. In that case, both preliminary and detailed design activities are conducted, but developers hold only a CDR and produce only the detailed design report.

Figure 5-1 presents a high-level data flow diagram of the preliminary design process.

5.1

Figure 5-1. Developing the Preliminary Design

 

핵심 활동들

다음은 개발 팀, 관리 팀 및 예비 설계 단계에서 요구 정의 팀의 주요 작업이다. 개발 팀은 위상의 주요 활동을 수행한다. 요구사항 정의의 팀은 뛰어난 TBD 요구사항을 해결하고 개발 팀에 지원을 제공에 집중하고 있다. 이러한 그룹의 주요 활동들 사이의 관계는 그림 5-2에 나타낸다.

The following are the key activities of the development team, the management team, and the requirements definition team during the preliminary design phase. The development team performs the principal activities of the phase. The requirements definition team concentrates on resolving outstanding TBD requirements and providing support to the development team. The relationships among the major activities of these groups are shown in Figure 5-2.

 

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

  • 예비 설계 도면 준비한다. 기능적 분해 또는 객체 지향 기술을 사용하여 이전 단계에서 제안된 예비 소프트웨어 아키텍처를 확장한다. 소프트웨어의 구현, 시험, 유지관리, 재사용하기 어려운 특징을 최소화시키는 확장된 아키텍처를 설계한다.설계 옵션을 평가한다. 시스템 우선 순위 (예를 들어, 최적화 된 성능, 사용의 용이성, 재사용을 고려, 신뢰성, 또는 유지 관리)에 따라 우선순위를 둔다. 특히 위험 지역에서 테스트 대안에 프로토타이핑 및 성능 모델링을 사용한다.

    재사용을 위한 후보 소프트웨어 컴포넌트를 검사한다. 시스템 응답 요구가 특히 엄격한 경우, 재사용 가능한 컴포넌트의 성능을 모델링 한다. 이러한 재사용 검증 활동의 결과를 반영하여 재사용 계획을 업데이트 한다.

    선택한 시스템 디자인의 높은 수준의 다이어그램을 생성하고 이를 통해 요구사항 정의 팀의 분석을 수행한다. 분석의 관점에서 시스템 처리 흐름을 설명하기 위해 기본 설계 다이어그램을 사용한다. 시스템 및 서브 시스템의 인터페이스에 초점을 맞춘다. 분석 활동에서 발생하는 작업 시나리오로 분류 설명하고 워크스루를 통해 재료의 사용자 화면과 보고서 형식의 예비 버전을 포함한다.

 

  • Prepare preliminary design diagrams. Using functional decomposition or object-oriented techniques, expand the preliminary software architecture that was proposed in earlier Idealize the expanded architecture to minimize features that could make the software difficult to implement, test, maintain, or reuse.Evaluate design options. Weigh choices according to system priorities (e.g., optimized performance, ease of use, reuse considerations, reliability, or maintainability). Use prototyping and performance modeling to test alternatives, especially in risk areas.

    Examine the software components that are candidates for reuse. If system response requirements are especially stringent, model the performance of the reusable components. Update the reuse plan to reflect the results of these reuse verification activities.

    Generate high-level diagrams of the selected system design and walk the analysts of the requirements definition team through them. Use the high-level design diagrams to explain the system process flow from the analyst’s perspective. Focus on system and subsystem interfaces. Explain refinements to the operations scenarios arising from analysis activities and include preliminary versions of user screen and report formats in the walk- through materials.

 

Tailoring Note

디자인 다이어그램, 프롤로그, 그리고 PDL은 적용되는 디자인 방법론에 관계 없이 모든 시스템에 필요한다. 방법과 도구는 이러한 항목이 표시되는 방법에 대해 설명한다.

Design diagrams, prologs, and PDL are required for all systems, regardless of the design methodology applied. METHODS AND TOOLS discusses ways these items are represented.

 

5.2
Figur
e 5-2. Preliminary Design Phase Timeline

 

  • 고 수준 함수/객체를 위해 프롤로그, PDL을 준비한다. FORTRAN 시스템에서 prolog와 PDL을 서브시스템 드라이버의 아래 한 단계를 준비한다. Ada시스템에서는 시스템에서 중요한 객체를 위한 사양을 준비하고 컴파일하고 충분한 PDL을 구축하여 패키지와 서브시스템간의 의존관계를 보일 수 있도록 한다. (그림 5-4)완성된 설계 다이어그램, 단위 프롤로그/패키지 사양, PDL을 독립적 검사 및 인증을 위한 개발팀의 다른 멤버에게 제공한다.
  • Prepare prologs and PDL for the high-level functions/objects. For FORTRAN systems, prepare prologs and PDL to one level below the subsystem drivers. For Ada systems, prepare and compile specifications for the principal objects in the system and construct sufficient PDL to show the dependencies among packages and subprograms. (See Figure 5-4.)Provide completed design diagrams, unit prologs/package specifications, and PDL to other members of the development team for independent inspection and certification.
  • 예비 설계 보고서의 선택된 설계를 문서화한다. 재사용 계획, 대안 설계 결정, 외부 인터페이스를 포함한다.
  • Document the selected design in the preliminary design report. Include the reuse plan, alternative design decisions, and external interfaces.
  • PDR을 수행하고 RID를 해결한다. 상세 설계 단계에서의 사용을 위한 설계 변경을 기록하고 예비 설계 보고서를 업데이트하지 마라

 

  • Conduct the PDR and resolve RIDs. Record design changes for use in the detailed design phase, but do not update the preliminary design report.

 

 

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

 

예비 설계 시 계획에서 관리자의 초점 변화가 제어 할 수 있다. 다음은 이 단계의 주요 관리 활동이다:

During preliminary design, the manager’s focus changes from planning to control. The following are the major management activities of this phase:

 

  • 일정, 인력, 교육 기타 리소스를 다시 평가한다. 요구사항 분석 단계에서 교훈(lessons learned)와 프로젝트 통계를 기록함으로 소프트웨어 개발의 역사를 시작한다. 활동중인 프로젝트의 노력과 일정 비율, 시스템 사이즈 예측의 성장(growth of system size estimates), 팀 구성을 포함한다.개발 팀은 어플리케이션 분야에 경험 있는 소프트웨어 엔지니어와 직원의 조합이 있는지 확인한다. 프로젝트가 큰 경우, 일반적으로 서브 시스템 그룹으로 개발 팀을 분할하고, 그룹 지도자를 임명한다. 요구사항 변경 및 직원 이탈의 변화를 보상하기 위해 인력 수준을 조정하고 팀이 특정 프로젝트의 요구사항을 충족하는 데 필요한 교육을 취득하는 것을 보장한다.

 

  • Reassess schedules, staffing, training, and other resources. Begin the software development history by recording lessons learned and project statistics from the requirements analysis phase. Include percentages of project effort and schedule consumed, growth of system size estimates, and team composition.Ensure that the development team contains a mix of software engineers and personnel experienced in the application area. If the project is large, partition the development team into groups, usually by subsystem, and appoint group leaders. Adjust staffing levels to compensate for changes in requirements and staff attrition, and ensure the team obtains the training it needs to meet specific project demands.

 

예비 설계 보고서와 PDR 자료의 내용은 이 섹션에서, 각각의 제품과 검토의 제목 아래에 제공된다. 검사 및 인증 절차는 방법과 도구에 적용된다

Contents of the preliminary design report and PDR materials are provided under the PRODUCTS and REVIEW headings, respectively, in this section.  Inspection and certification procedures are covered under METHODS AND TOOLS.

 

소프트웨어 개발의 역사 (software development history, SDH)에 대한 자료는 프로젝트의 전 생애에 걸쳐 관리 팀에 의해 수집된다. SDH 내용의 개요에 대해서는 제 9 절을 참조하십시오.

 

Material for the software development history (SDH) is collected by the management team throughout the life of the project.  See Section 9 for an outline of SDH contents.

 

  • 계획하고, 조정하며 요구사항의 변경을 제어하라. 요구사항 이슈와 TBDs의 해결을 용이하게 하기 위해 분석가 및 고객과 인터페이스 하라. 분석가에게 제출된 요구사항 질문의 개수와 중요도 및 응답의 적시성을 모니터링 하라. 분석가와 고객은 어떤 TBD가 언제 해결될지에 대해서 알고 변경 및 판단하지 않은 요구사항 아이템의 영향을 이해하고 있다는 것을 보장하라.

 

각각의 명세 변경의 기술 영향 및 비용을 평가하라. 광범위한 재 작업과 중요하지 않은 기능 향상을 필요로 하는 수정은 제한한다

 

  • Plan, coordinate, and control requirements changes. Interface with analysts and the customer to facilitate resolution of requirements issues and TBDs. Monitor the number and severity of requirements questions submitted to analysts and the timeliness of responses. Ensure that analysts and the customer know the dates by which TBDs need to be resolved and understand the impact of changing or undetermined requirements items.

 

Assess the technical impact and cost of each specification modification. Constrain modifications that necessitate extensive rework and non-critical enhancements.

 

  • 일상적인 관리활동을 하는 동안 예비 설계 프로세스의 품질과 제품을 제어할 수 있다. 그 디자인 워크스루, 검사 및 리뷰를 확인, 예약하고 실시하고있다. 워크스루에 참석하고, 선택적으로 검사 및 보고, 추적 및 발생하는 설계 문제의 해결을감독. 모든 필수 소프트웨어의 문서가 생성되는 것을 확신하고 예비 설계 문서를 검토한다.팀은 표준 및 형상 관리 절차가 프로젝트에 부합 하는지 확인한다.

 

  • Control the quality of the preliminary design process and its products during day-to-day management activities. Ensure that design walk-throughs, inspections, and reviews are scheduled and conducted. Attend walk-throughs and, optionally, inspections and oversee the reporting, tracking, and resolution of the design issues that arise. Make certain that all requisite software documentation is generated and review the preliminary design document. Ensure that the team adheres to project standards and configuration management procedures.

 

  • 상세 설계 단계로의 순차적으로 전환을 계획한다. TBDs, 사양 변경, 일정 또는 팀 조정의 영향을 고려한다. 노력, 기간, 크기의 프로젝트 추정을 개정하고 그에 상응하는 SDMP의 부분을 업데이트 한다. 프로젝트 빌드 전략을 개발하고 프로토타이핑 결과, 프로젝트 위험 및 남은 TBDs를 반영하는 사전 구축 계획을 준비한다.필요한 경우 세부 설계를 시작하기 위해 팀 크기를 증가시키고 추가 인력의 훈련 요구를 기술한다. 단위 프롤로그, PDL, 재사용 코드를 저장하기 위한 온라인 도서관의 설립을 감독한다. 프로젝트 및 그룹 리더가 PDR을 준비하는 동안, 팀의 나머지는 상세 설계 활동을 시작한다.

    PDR을 제어하고 모두 종료 기준이 현재 단계의 완료를 선언하기 전에 충족되었는지 확인한다.

 

  • Plan an orderly transition to the detailed design phase. Consider the impacts of TBDs, specification modifications, and schedule or team adjustments. Revise project estimates of effort, duration, and size and update corresponding sections of the SDMP. Develop the project build strategy and prepare a preliminary build plan reflecting prototyping results, project risks, and remaining TBDs.Increase team size if necessary to begin detailed design and address the training needs of additional personnel. Oversee the establishment of online libraries to store unit prologs, PDL, and reused code. While project and group leaders prepare for PDR, start the rest of the team on detailed design activities.

    Control the PDR and ensure that all exit criteria have been met before declaring the phase complete.

 

 

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

 

예비 설계 단계에서 요구사항 정의의 팀은 다음과 같은 활동을 통해 소프트웨어 개발자들을 지원한다.

During the preliminary design phase, the requirements definition team provides support to software developers through the following activities:

 

  • 요구사항 문제와 TBDs 해결하는 것을 계속한다. 모호함, 충돌, 불완전한 요구사항을 명확히 한다. 개발자의 요구사항을 질문에 대한 신속한 서면 응답을 제공하고 서면 응답에 대해 개발자와 토의한다. 높은 수준의 시스템 요구사항의 변화에 ​​대응하고, 각각의 변경에 대한 영향을 평가하며 그에 따라 사양 변경을 준비한다.• 디자인 워크스루 PDR 참여한다. 철저하게 제안된 디자인을 분석한다. 운영 시나리오 및 예비 사용자 인터페이스를 구체화하는 개발자들과 작업한다. 워크스루 동안 제기된 문제를 해결하기 위해 개발자와 함께 작업한다.

    PDR전에 예비 설계 보고서와 모든 제공되는 하드 카피 자료를 검토한다. 검토 회의에서 질문을 제기하고 초기, 고 수준의 시스템 설계의 비평을 하고, 심각한 불일치를 문서화하기 위해 RIDs를 사용한다.

 

  • Continue to resolve requirements issues and TBDs. Clarify ambiguous, conflicting, or incomplete requirements. Provide prompt, written replies to developers’ requirements questions and discuss these responses with developers. Respond to changes in high-level system requirements, evaluate the impact of each change, and prepare specification modifications accordingly.

 

  • Participate in design walk-throughs and the PDR. Thoroughly analyze the proposed design. Work with developers to refine the operational scenarios and preliminary user interface. Follow up with developers to address issues raised during the walk-throughs.Review the preliminary design report and all supporting hardcopy materials before PDR. Pose questions and provide critiques of the initial, high-level system design during the review meeting, and use RIDs to document serious discrepancies.

 

방법과 도구

METHODS AND TOOLS

 

설계 및 구현 단계에서, 소프트웨어 개발 및 요구사항 정의의 팀은 요구사항 문제를 기록하고 해결하는 질의 응답 형태와 규격의 수정을 계속 사용한다. 방법과 도구, 자세한 내용은 4 절을 참조하라.

 

During the design and implementation phases, the software development and requirements definition teams continue to use question-and-answer forms and specification modifications to record and resolve requirements issues. See METHODS AND TOOLS, Section 4, for more details

 

예비 설계 단계에서 사용되는 기본 방법과 도구는

• 기능적 분해 및 객체 지향 설계
• 프롤로그와 PDL
• 소프트웨어 엔지니어링 노트북 (SENS)
• 디자인 워크스루
• 설계 검사
• 재사용 검증
• 분석 방법: 프로토타이핑, 성능 모델링 및 코드 분석

 

The primary methods and tools used during the preliminary design phase are

 

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

 

 

기능적 분해 및 객체 지향적 설계(Functional Decomposition and Object-Oriented Design)

 

설계 기술은 소프트웨어 개발자, 소프트웨어 시스템의 주요 구성 요소를 정의하는 구성 요소들 사이의 상호 관계를 설명하며 구현을 위한 기반을 생성하는 방법이다. 디자인 다이어그램, 구조 차트 및 문서는 이러한 방법을 지원한다. 이러한 도구를 통해 개발자는 선택된 디자인 접근 방식은 요구사항 및 사양 문서에 지정된 각 기능 및 인터페이스를 포함하고 있음을 보여줍니다. SEL-모니터링 프로젝트에 사용되는 두 가지 주요 설계 기술은 기능적 분해 및 객체 지향 설계 (OOD)이다.

Design technologies are methods by which software developers define the major components of a software system, describe the interrelationships among components, and create a foundation for implementation. Design diagrams, structure charts, and documentation support these methods. Through these tools, developers demonstrate that a chosen design approach incorporates each capability and interface specified in the requirements and specifications document. The two principal design technologies used on SEL-monitored projects are functional decomposition and object-oriented design (OOD).

 

객체 지향 분석 및 설계에 대한 철저한 논의는 참고 문헌 11, 16, 17에 제공된다.

11. G. Booch, Object-Oriented Design (with Applications), Benjamin/Cummings: Redwood

City, CA, 1991

16. P. Coad and E. Yourdon, Object-Oriented Analysis, Yourdon Press: NY, 1991

17. Software Engineering Laboratory, SEL-86-002, General Object-Oriented Software

Development, E. Seidewitz and M. Stark, August 1986

 

A thorough discussion of object-oriented analysis and design is provided in References 11, 16, and 17.

 

구조적 디자인 원리 (참조 번호 13)에 사용 SEL 기능적 분석법의 기초를 형성한다.

13. E. Yourdon and L. L. Constantine, Structured Design, Yourdon Press: NY, 1978

Structured design principles (Reference 13) form the basis of the functional decomposition method used in the SEL.

 

기능적 분해 설계 방법을 사용하는 경우, 개발자는 시스템의 주요 기능을 식별하고 연속적으로 기능들을 작은 기능 지향적 컴포넌트로 쪼갠다. 설계에서 높은 수준은 알고리즘적 추상화를 정의한다(절차상의 “무엇”) 그리고 낮은 수준은 높은 수준의 행동을 구현하기 위한 기본 동작을 제공한다.

When using a functional decomposition design method, developers identify the major functions of a system and successively refine them into smaller and smaller functionally oriented components. High levels in the design define the algorithmic abstraction (the “what” of the process), and the lower levels provide primitive operations that implement the higher level actions.

 

항공 역학 환경에서 기능적인 분해는 일반적 FORTRAN 시스템의 개발에 사용된다. 이 설계 방식을 사용하는 경우, 기능 기본 다이어그램 (챠트)을 (그림 5-3 참조) 서브 시스템 드라이버를 아래의 두 가지 수준의 모든 구성 요소에 대한 예비 설계 과정에서 생성된다. 나머지 디자인 다이어그램 (N에 레벨 3) 세부 설계 중에 완료된다. 별도의 구조 차트 다이어그램을 보강 할 수 있다; 대안적으로, 인터페이스 정보 차트에 직접 첨가 될 수 있다.

In the flight dynamics environment, functional decomposition is normally used for the development of FORTRAN systems. When using this design approach, functional baseline diagrams (tree charts) are generated during preliminary design for all components to two levels below the subsystem drivers (as shown in Figure 5-3). The remaining design diagrams (levels 3 to N) are completed during detailed design. Separate structure charts may augment the diagrams; alternatively, interface information may be added directly to the tree charts.

 

SEL은 다음의 사항들에 대해서 권장한다. – 기능 중심의 설계는 정보 숨기기, 데이터 추상화, 느슨한 결합 및 응집력의 원칙을 사용해야 한다. 그림 5-3의 기능 분해 계층의 굵은 선 아래 구성 요소는 낮은 수준의 루틴 ​​또는 그 정보의 상세 설계 단계로 연기하는 유틸리티를 나타낸다. 그러나, 개발자는 여전히 정확한 ​​예비 설계를 생성하는 전체 시스템 구조를 이해해야 한다.

The SEL also recommends that functionally oriented designs employ the principles of information hiding, data abstraction, loose coupling, and cohesion. Components below the heavy line in the functional decomposition hierarchy of Figure 5-3 denote low-level routines or utilities whose details are deferred to the detailed design phase. However, developers must still understand the total system architecture to produce a correct preliminary design.

 

객체 지향 접근 방식을 사용하는 경우, 설계자는 실재 환경을 모델링 하는 추상화된 객체와 속성을 식별하고 그 객체들의 작업을 정의하고 그들 사이의 인터페이스를 확립해야 한다. 객체에게 영향을 끼치는 액션보다 객체(시스템의 “일(things)”) 주로 집중함으로써 객체 지향 기술은 설계자가 그들의 솔루션을 문제에 더욱 직접적으로 매핑할 수 있도록 한다.

When using an object-oriented approach, designers identify the abstract objects and their attributes that model the real-world system, define operations on those objects, and establish the interfaces between them. By focusing primarily on the objects (the “things” of the system) rather than on the actions that affect those objects, object-oriented techniques allow designers to map their solutions more directly to the problem

 

응집 및 커플링, 소프트웨어 시스템 강도, 안정성, 유지 관리의 지표는, 참조 13에 설명되어 있다.

 

Cohesion and coupling, indicators of software system strength, reliability, and maintainability, are discussed in Reference 13.

 

5.3

Figure 5-3.  Extent of the Design Produced for FORTRAN Systems During the Preliminary and Detailed Design Phases

 

 

비행 역학 환경에서 Ada는 일반적으로 OOD 기술이 선택될 때 포함된 언어이다. Ada 시스템 예비 설계에서 문제 도메인의 요소를 언급하는 모든 패키지 및 서브 프로그램 식별된다. 이것은 시스템 기능, 이런 객체를 영향을 끼치는 기능 및 절차, 외부적으로 볼 수 있는 데이터, 모든 인터페이스와 의존관계를 구현하는데 필요한 고 수준의 객체를 모두 포함한다.

In the flight dynamics environment, Ada is typically the language involved when OOD techniques are chosen. In the preliminary design of Ada systems, all packages and subprograms that address elements of the problem domain are identified. This includes all high-level objects necessary to implement the system capabilities, the functions and procedures affecting these objects, externally visible data, and all interfaces and dependencies.

 

개발자는 식별 된 모든 서브 시스템의 모든 패키지 및 해당 패키지 내의 모든 서브 볼 때까지 객체 지향, 단계적 정제를 사용한다. 패키지 본문의 디자인은 (숨겨진 요소는 그림 5-4에서 음영) 상세 설계 단계까지 예약되어 있다. 에이다 시스템의 일반화 된 적절한 예비 설계 도면은 그림 5-4에 나와 있다.

Developers use object-oriented, stepwise refinement until all subsystems, all packages, and all visible subprograms within those packages have been identified. Design of package bodies (the hidden elements shaded in Figure 5-4) is reserved until the detailed design phase. A generalized preliminary design diagram appropriate for an Ada system is shown in Figure 5-4.

 

5.4

Figure 5-4. Level of Detail Produced for Ada Systems During Preliminary Design

 

Prologs and PDL

 

하드웨어 시스템, 프롤로그와 PDL의 청사진에 비해 구현에 필요한 세부 사항 레벨에 디자인의 개념을 전달한다. 프롤로그는 장치의 목적과 변수의 텍스트 설명을 제공한다; PDL은 장치에 대한 형식적인, 알고리즘 사양을 제공한다. 프롤로그 및 PDL를 사용함으로써, 개발자는 검토 및 코더에 디자인의 정확한 ​​의도를 의사소통 할 수 있다.

Comparable to the blueprint in hardware systems, prologs and PDL communicate the concept of the design to the level of detail necessary for implementation. The prolog provides a textual explanation of the unit’s purpose and variables; PDL provides a formal, algorithmic specification for the unit. By using prologs and PDL, the developer is able to communicate the exact intent of the design to reviewers and coders.

 

SEL은 유익하고 비용대비 효율적으로 디자인하는 동안 프롤로그와 PDL의 사용을 본다. 선택한 설계에 관계없이 개발자는 예비 설계를 완료하기 위해 단위 프롤로그와 높은 수준의 PDL(호출 종속성, 주요 논리 분기 및 오류 처리 전략 등의 항목으로 구성된)을 생성해야 할 것을 요청 받는다.

The SEL views the use of prologs and PDL during design as beneficial and cost-effective. Regardless of the design methodology chosen, developers are required to generate unit prologs and high-level PDL (consisting of such items as call dependencies, major logic branches, and error-handling strategies) to complete the preliminary design.

 

SEL conventions for prologs and PDL are found in References 22 (Ada conventions) and 23 (FORTRAN conventions).

 

For large Ada systems with broad, flat designs, creating PDL for externally visible elements of all packages and all visible subprograms entails extensive effort.  When this situation exists, software managers should adjust effort and schedule allocations to allow sufficient time to complete this work in preliminary design.

 

FORTRAN 시스템의 경우, 프롤로그와 PDL은 서브 시스템 드라이버보다 한 레벨 아래에 생성된다. 객체 지향 시스템 (ADA 시스템의 프롤로그 역할) 패키지 사양과 높은 수준의 PDL를 들어 (그림 5-4 참조) 디자인 다이어그램에 묘사 된 모든 프로그램 구성 요소에 대해 생성된다. 인터페이스 오류를 식별하기 위해, 에이다 PDL은 항상 컴파일; 개발자는 PDL 구조를 표준화하는 템플릿과 언어에 민감한 편집기 (LSE)를 사용한다.

For FORTRAN systems, prologs and PDL are produced to one level below the subsystem drivers. For object-oriented systems, package specifications (which serve as prologs in Ada systems) and high-level PDL are generated for all program elements depicted in the design diagrams (see Figure 5-4). To identify interface errors, Ada PDL is always compiled; developers use templates and a language-sensitive editor (LSE) to standardize PDL structure.

 

 

Software Engineering Notebooks

 

A software engineering notebook (SEN) is a workbook (i.e., a file folder or special notebook) that facilitates quality assurance and configuration management by consolidating printed information pertinent to a software component. This information becomes more detailed as the life cycle progresses. When printed documentation is combined with online source files in later phases, the SEN provides a baseline history of an element’s evolution through the development process.

 

During preliminary design, developers initiate SENs at a subsystem or logical function level. Into these SENs they collect notes documenting design decisions, design diagrams, structure charts, and signed design inspection checklists for the subsystem or function. SENs are usually maintained by developers until after unit testing, when they are turned over to the project librarian.

 

 

Design Walk-Throughs

 

개발자는 이 모습을 드러내고 요구사항 정의 및 개발 두 팀이 시스템 설계를 이해할 수 있도록 디자인 워크스루를 실시하고 있다. 개발자는 이전에 다른 개발자, 분석가, 사용자 대표, 개발중인 소프트웨어와 대면 시스템의 대표 및 관리자를 포함 참가자에 대한 단계별 안내에 자료를 배포 할 수 있다. 회의에서, 개발자는 주의 깊게 시스템 (처리 순서와 인터페이스, 화면 형식 및 사용자 입력)의 운영 측면을 새로운 디자인에 반영하는 방법을 설명한다. 참가자는 개발자가 시스템 요구사항을 얼마나 완전하게 해석하고 정확하게 해설하는지 comment한다. 기록 담당자는 불일치, 에러를 기록하고 action item을 기록한다. 중요한 문제가 워크스루 마지막에 남겨져 있는 경우, 후속 세션을 예약 할 수 있다.

Developers conduct design walk-throughs to ensure that both the requirements definition and development teams understand the system design as it takes shape. Developers distribute materials prior to the walk-through to participants, who include other developers, analysts, user representatives, representatives of systems that will interface with the software under development, and managers. During the meeting, developers carefully explain how operational aspects of the system (processing sequences and interfaces, screen formats, and user inputs) are reflected in the emerging design. Participants comment on how completely and accurately developers have interpreted the system requirements. A recording secretary notes discrepancies, errors, and inconsistencies and records action items. If significant issues remain at the end of the walk-through, a follow-up session may be scheduled.

 

초기 워크를 통해 일반적으로 전체적이고 시스템 수준의 접근 방식을 제시하고 나중에 서브 시스템의 워크스루와 그 주요 부품에 대해서 수행한다. 프로젝트가 크고 개발팀 그룹으로 분할되어 있다면 워크스루 중인 서브 시스템과 인터페이스의 그룹 리더가 세션에 참여하는 것이 중요하다.

The initial walk-through typically presents the overall, system level approach and is later followed by walk-throughs of subsystems and their major parts. When a project is large and the development team has been partitioned into groups, it is important that the group leader of any subsystem that interfaces with the subsystem being presented attend the session.

 

Design Inspection

 

디자인 워크스루는 시스템 설계의 운영 측면을 설명에 집중하는 반면, 디자인 검사는 소프트웨어 팀 동료에 의해 수행되는 독립적이고, 깊이가 있다. 설계 다이어그램의 기술 리뷰, 프롤로그, PDL는 디자인 검사를 한다. 검사는 명확하고 완벽하게 시스템 설계의 논리적으로 관련 부품으로 수행된다. 단위 프롤로그와 PDL이 필요한 수준으로 생성되었을 때 검사가 스케줄 된다. 개발자는 작업 회의를 개최하기에 앞서서 검사 팀이 학습할 수 있도록 이러한 자료를 배포 할 수 있다.

Whereas design walk-throughs focus on explaining operational aspects of the system design, design inspections are independent, in- depth, technical reviews of the design diagrams, prologs, and PDL that are performed by software team peers. Inspections are held as logically related parts of the system design become clear and complete; they are scheduled when unit prologs and PDL have been generated to the required level. Developers distribute these materials for study by the inspection team prior to holding a working meeting.

 

검사 팀은 세 개 이상의 프로젝트의 기준에 정통한 개발 팀의 구성원, 개발 언어 및 시스템 요구사항으로 구성되어 있다. 팀의 한 구성원은 회의의 의장 역할을 한다.

An inspection team consists of three or more members of the development team who are versed in the project’s standards, development language, and system requirements. One member of the team acts as the moderator for the meeting.

 

다른 단위가 각 단계에서 설계 되었기 때문에 설계 검사는 모두 예비 및 상세 설계 단계에서 실시하고 있다. 단위 디자인은 예비 설계 단계에서 검사 및 인증 된 경우 이 개정되지 않는 한, 이 세부 설계 단계에서 다시 검사되지 않습니다. 디자인 검사 절차에 대한 자세한 설명은 제 6 방법 및 도구를 참조하십시오.

Design inspections are conducted during both the preliminary and detailed design phases because different units are designed in each phase. If a unit design was inspected and certified during the preliminary design phase, it is not re- inspected during the detailed design phase unless it has been revised. See METHODS AND TOOLS in Section 6 for a detailed description of design inspection procedures.

 

검사 팀 참가자는 단위 논리와 인터페이스가 정확하게 시스템 요구사항을 나타냈는지 인증하고 개발자가 올바른 설계 원리를 적용했는지의 여부를 인증한다. 검토는 평가 및 주 약점 또는 디자인 검사 체크리스트 (그림 6-3)에 인터페이스의 충돌을 문서화 한다. 서명된 체크리스트는 또한 단위가 규정된 프로젝트 표준과 규칙을 따르는 것을 인증한다.

Inspection team participants certify that unit logic and interfaces accurately represent the system requirements and that developers have applied correct design principles. Reviewers document their assessment and note weaknesses or interface conflicts on design inspection checklists (Figure 6-3). The signed checklist also certifies that the unit follows prescribed project standards and conventions.

 

 

Reuse Verification

 

재사용 검증은 새로운 시스템 설계에 통합되어야 재사용 계획안에 지정된 기존 소프트웨어 컴포넌트를 결정하는 과정이다. 재사용을 검증하는 동안, 개발자는 FDF의 재사용 소프트웨어 라이브러리 (RSL)와 같은 소스에서 코드와 문서를 검사한다. 개발자는 전체 시스템 아키텍처 설계의 명확성 및 시스템 성능의 완전성을 고려하여 자신의 경험을 그린다.

Reuse verification is the process of determining which of the existing software components specified in the reuse proposal should be integrated into the new system design. During reuse verification, developers examine code and documentation from sources such as the FDF’s Reusable Software Library (RSL). Developers draw on their experience in considering the integrity of the overall system architecture, the clarity of the design, and system performance.

 

재사용 계획이 기존 시스템의 많은 부분을 사용하는 것을 권장할 때, 개발자들은 기존의 소프트웨어와 호환 되도록 하기 위해 최적의 시스템 디자인을 손상시킬 때의 장단점을 평가해야 한다. 그들은 설계 옵션을 비중을 둘 때, 전체 소프트웨어 개발 비용, 디자인, 선명도, 성능 요구사항, 시스템 크기, 유지 보수 및 신뢰성에 대한 장기적인 영향을 고려해야 한다.

When the reuse plan recommends using large portions of existing systems, developers must assess the trade-offs of compromising an optimum system design to make it compatible with existing software. They must consider long-term impacts on total software development costs, design clarity, performance requirements, system size, maintainability, and reliability when weighing design options.

 

(예: 호환되지 않는 언어 버전이나 운영 체제 별 통화의 높은 발생률 등) 요인이 재사용되는 기존 구성 요소를 금지하는 경우, 개발자는 구성 요소 호환을 디자인하기 전에 그 기능, 조직 및 데이터 구조를 이해하기 위해 소프트웨어 및 설명서의 내용을 공부할 수 있다 새로운 시스템. 따라서, 다시 경험은 명시 적 디자인과 코드가 될 수 없어도 프로젝트에서 공유된다.

When factors (such as incompatible language versions or a high incidence of operating system-specific calls) prohibit an existing component from being reused, developers can study the software and its documentation to understand its function, organization, and data structures before designing a component compatible with the new system. Thus, reused experience is shared across projects even when explicit design and code cannot be.

 

 

Analysis Methods: Prototyping, Performance Modeling, and Code Analysis

 

예비 설계하는 동안 개발 팀은 설계 개념을 확인하고 설계 옵션의 장단점을 테스트하기 위해 프로토타이핑을 사용한다. 개발자는 새로운 시스템에 재사용 할 계획 구성 요소를 행사하는 프로토타이핑 드라이버 (또는 비계 코드)를 구성한다. 또한 사용자 화면 프로토타이핑과 형식을 보고 한다. 아래에 설명 된 대로 기존의 구성 요소, 새로운 시스템의 성능 요구사항, 성능 및 소스 코드 분석 개발자 커플 프로토타이핑을 충족하는지 확인하는 방법을 설명한다.

During preliminary design, the development team uses prototyping to validate design concepts and to test the trade-offs of design options. Developers compose prototype drivers (or scaffolding code) to exercise components planned for reuse in the new system. They also prototype user screens and report formats. To confirm that existing components will meet the new system’s performance requirements, developers couple prototyping with performance and source code analysis, as described below.

 

성능 모델링 프로그램이 지정된 컴퓨터의 리소스를 사용하는 방법을 효율적으로 예측하는 수단이다. 이러한 예측을 생성하기 위해, 개발자는 예상되는 유닛 수 등의 파라미터를 사용하여, 데이터 플로우, 메모리 사용량 추정하고, 프로그램의 양 I / O의 양 및 빈도 기존의 유사한 시스템과 유사하게 사용될 수도 있다. 성능 모델링의 결과는 설계 옵션 사이에서 결정하는 개발자를 지원한다.

Performance modeling is a means of predicting how efficiently a program will use resources on a given computer. To generate these predictions, developers use such parameters as the number of units anticipated, the volume and frequency of the data flow, memory usage estimates, and the amount of program I/O. Analogy with existing, similar systems may also be used. Results of performance modeling assist developers in deciding among design options.

 

실행 코드 (예, 비계 코드 또는 재사용 단위)이 있는 경우, 개발자는 동시에 코드와 같은 문제 프로그램 평가자 (PPE) 또는 VAX 성능 및 적용 범위 분석기와 같은 성능 분석기를 실행할 수 있다. 이러한 동적 분석기는 CPU 시간 등의 정보를 생성하고, 이 I / O 개발자가 코드 재 설계 될 필요 (예를 들면, 비효율적 루프 구조 또는 계산)의 영역을 식별 할 수, 페이지 결함 데이터.

If executable code exists (e.g., scaffolding code or reused units), developers can run performance analyzers, such as Problem Program Evaluator (PPE) or the VAX Performance and Coverage Analyzer, concurrently with the code. These dynamic analyzers generate information such as CPU time, I/O counts, and page fault data that help developers identify areas of the code (e.g., inefficient loop structures or calculations) that need to be redesigned.

 

정적 코드 분석기 (예 VAX 소스 코드 분석기)는 기존 구성 요소의 소스 코드를 읽고 자신의 제어 구조, 심볼 정의하고, 변수 발생을 설명하는 정보를 생성하는 도구이다. 개발자는 재사용 가능한 구성 요소의 인터페이스에 대한 제안 된 변경의 범위를 평가하는 정적 코드 분석기에 의해 생성 된 호출 트리를 검사 할 수 있다. 디자이너는 더 나은 다음하는 방법을 결정할 수 있다 – 수정하고 테스트 영향을 받는 모든 단위 또는 새 구성 요소를 디자인 할 수 있다.

Static code analyzers (e.g., VAX Source Code Analyzer) are tools that read the source code of existing components and generate information describing their control structure, symbol definitions, and variable occurrences. A developer can examine the call trees produced by a static code analyzer to assess the scope of a proposed change to a reusable component’s interfaces. The designer can then decide which approach is better — to modify and test all affected units or to design a new component.

 

 

측정(MEASURES)

 

예비 설계 시, 관리자는 요구 분석 단계의 목적은 측정을 사용하는 것을 계속한다. 또한 추가 진도 데이터를 감시하기 시작한다. 다음과 같은 조치를 수집하고 있다:

• 식별 번호 대 디자인 단위의 수
• 요구사항 질문 및 답변, TBDs, 변경
• 직원의 시간
• 시스템의 크기, 노력, 일정 및 재사용 추정

이러한 데이터의 소스와 데이터 수집 및 평가 빈도를 표 5-1에 나타낸다.

 

During preliminary design, managers continue to use the objective measures of the requirements analysis phase. They also begin to monitor additional progress data. The following measures are collected:

 

  • The number of units designed versus the number identified
  • Requirements questions and answers, TBDs, and changes
  • Staff hours
  • Estimates of system size, effort, schedule, and reuse

 

The source of these data and the frequency of data collection and evaluation are shown in Table 5-1.

 

t5.1

Table 5-1.  Objective Measures Collected During the Preliminary Design Phase

 

평가 범주(Evaluation Criteria)

 

프로젝트 리더는 예비 시스템 디자인을 나타내는데 필요한 단위의 수를 추정한다. 이 추정에 대해, 생성된 단위 설계의 수와 인증 받은 단위의 수를 추적한다. 관리 플롯은 임박한 어려움을 신호를 발생시키는 진행 데이터의 추세 또는 고원을 발견하는 것을 도와준다. 인증 단위의 그래프는 상당히 부드러운 곡선으로 설계 단위의 그래프를 평행해야 한다. 급격하게 일정을 만족시키기 위한 노력을 하기 위해 많은 단위가 급하게 인증될 때 급격한 증가(계단형 그래프)가 나타납니다.

Project leaders estimate the number of units that will be needed to represent the preliminary system design. Against this estimate, they track the number of unit designs (prolog and PDL) that have been generated and the number certified. Management plots assist in discovering trends or plateaus in this progress data that signal impending difficulties. The graph of units certified should closely follow and parallel the graph for units designed in a fairly smooth curve. Sharp increases (a “stair- step” graph) will appear when many units are hurriedly certified together in an effort to meet schedules.

 

예비 설계 시 제출 요청한 질문의 수와 수신한 응답의 수 사이의 격차가 넓어지는 것은 재 작업 및 최종 일정 지연의 조기 경고 신호가 될 수 있다. 질문과 유사한 크기와 복잡성의 시스템과 비교하여 응답의 높은 숫자는 동일한 방식으로 해석된다.

During preliminary design, a widening gap between the number of requirements questions submitted and the number of answers received can be an early warning signal of impending rework and eventual schedule slippage. A high number of questions and answers when compared with systems of similar size and complexity is interpreted the same way.

 

설계 단위의 수는 단위 완료의 척도로서 사용되어서는 안 된다. 올바른 완료 측정은 인증 받은 단위 설계의 수이다.

The number of units designed should not be used as a measure of unit completion. The correct completion measure is the number of certified unit designs.

 

예비 설계 단계에도 지속되는 TBDs요구사항의 개수를 추적하는 것, 특히 외부 인터페이스와 하드웨어 변경 같은 경우는 매우 중요한데 그 이유는 TBD가 설계에서 완전하지 않음을 나타내며 재 작업에 대한 잠재적 증가를 의미하기 때문이다. TBDs는 초기 라이프 사이클 단계에서 신속하게 감소시켜야 한다.

Tracking the number of TBD requirements that persist into the preliminary design phase, especially those concerning external interfaces and hardware changes, is crucial because TBDs represent incompleteness in the design and increase the potential for rework. TBDs should diminish quickly in the early life cycle phases.

 

사양 변경은 개발 팀 질문의 응답 혹은 하드웨어 변경 등과 같은 외부 프로젝트의 영향에 대한 응답으로 발생될 수 있다. 개발자의 질문으로 인해 사양 변경의 수와 심각성은 품질 요구사항 및 사양 문서를 반영한다. 이러한 변경 사항은 일반적으로 개발 및 요구사항 정의의 팀에 의해 해결된다. 외부 원인에 의한 사양 변경의 수와 심각성은 더 광범위한 의미를 가지기 때문에 일정과 노력 추정 장기 교란을 예측하는 일을 하는 관리자에게 경고해야 한다.

Specification modifications may be issued in response to development team questions or external project influences such as hardware changes. The number and severity of specification modifications resulting from developers’ questions reflect the quality of the requirements and specifications document. These changes are normally addressed by the development and requirements definition teams. The number and severity of specification modifications from external causes have more far-reaching implications and should alert managers to anticipate long-term perturbations in schedule and effort estimates.

 

계획과 실제 직원의 노력의 시간 사이의 큰 편차는 정밀 검사를 타당하게 한다. 높은 수준의 노력으로 일정을 충족하도록 요구하는 경우, 개발 팀의 생산성이 낮을 수도 있고 문제는 원래보다 복잡할 수 있다. 낮은 직원 시간은 프로젝트 또는 불충분 한 요구사항 분석에 지연 인력을 나타낼 수 있다. 이 마지막 조건의 효과는 예비 설계에 항상 분명한 것은 아니지만, 이후의 단계에서 설계 결함으로 극적으로 표면화 한다.

Significant deviations between planned and actual staff effort hours warrant close examination. When a high level of effort is required to meet schedules, the development team’s productivity may be low or the problem may be more complex than originally realized. Low staff hours may indicate delayed staffing on the project or insufficient requirements analysis. The effects of these last conditions are not always immediately obvious in preliminary design, but will surface dramatically as design deficiencies during subsequent phases.

 

관리자는 시스템 사이즈를 예측하는 것을 refine하기 위해 계획된 단위의 수치 및 평균 단위 사이즈를 사용할 수 있다. 시스템에서 재 사용된 단위의 숫자는 또한 더욱 견고해진다. 관리자는 변경 없이 재사용되어야 하는 단위 대비 수정이 필요한 단위의 숫자를 식별하며 그에 따라 노력을 개정하고 일정 예측을 조정한다.

Managers can now use the number of units planned and average unit size to refine estimates of system size. The number of reused units in the system also becomes firmer; managers identify units to be reused without change versus those to be modified and revise effort and schedule projections accordingly.

 

SEL 관리자 업데이트 노력, 일정 및 크기의 추정치는 약 한 달에 한 번 프로젝트에서 이러한 추정치를 구성 양식 (PEF)를 추정한다. 이러한 형태의 데이터는 시스템의 성장과 발전의 플롯을 생성하는 데 사용된다.

 

SEL managers update effort, schedule, and size estimates approximately once a month and organize these estimates on the Project Estimates Form (PEF). Data from these forms are used to generate system growth and progress plots.

 

설계 품질 (강도 등)의 측정 값의 개수가 제안되었지만, SEL 아직 설계의 품질에 상당한 통찰력을 제공 대물 대책을 발견하지 않았다.

 

Although a number of measures of design quality (strength, etc.) have been proposed, the SEL has not yet found objective measures that provide significant insight into the quality of a design.

 

견적은 핵심적인 관리 측정이다; 광범위하게 추정치가 변경하거나 급격한 증가(변동폭이 매우 큰 경우)는 항상 조사를 해야 한다. 예비 설계 단계에서 시스템 사이즈 예측의 과도한 성장은 일반적으로 요구사항이 불안정하거나 변경 제어 메커니즘이 효과가 없는 것으로 볼 수 있다.

Estimates are a key management measure; widely varying estimates or sharp increases always warrant investigation. In the preliminary design phase, excessive growth in system size estimates is generally seen when requirements are unstable or change control mechanisms are ineffective.

 

산출물(PRODUCTS)

 

예비 설계 보고서에 설명 된 대로 예비 설계 단계의 주요 제품은 시스템의 높은 수준의 디자인이다. 보고서는 재사용 검증 및 프로토타이핑의 결과를 통합하고 상세한 설계 문서에 대한 기초를 형성한다. 그들의 크기 때문에, 단위 프롤로그와 PDL은 일반적으로 보고서에 대한 추가 사항으로 식별 된 별도의 볼륨에 게시된다.

 

형식과 내용을 보여주는 예비 설계 보고서의 개요는 그림 5-5로 제공된다.

The primary product of the preliminary design phase is the high- level design of the system, as documented in the preliminary design report. The report incorporates the results of reuse verification and prototyping and forms the basis for the detailed design document. Because of their size, unit prologs and PDL are normally published in a separate volume that is identified as an addendum to the report.

An outline of the preliminary design report, showing format and content, is provided as Figure 5-5.

 

예비 설계 검토(PRELIMINARY DESIGN REVIEW)

 

단계는 개발 팀이 대안을 통해 그 디자인을 선택하는 높은 수준의 시스템 설계 및 이론적 근거를 제시하는 동안 예비 설계 검토 (PDR)로 마친다. 또한 작업 시나리오, 해결을위한 주요 TBDs, 프로젝트 품질과 일정에 영향을 미치는 문제에 대한 외부 시스템 인터페이스, 개정의 설명은 PDR에 강조했다.

The phase concludes with the preliminary design review (PDR), during which the development team presents the high-level system design and the rationale for choosing that design over alternatives. Also highlighted in the PDR are explanations of external system interfaces, revisions to operations scenarios, major TBDs for resolution, and issues affecting project quality and schedule.

 

PDR에 제출 된 자료가 반드시 예비 설계 단계 동안에 달성된 개발팀의 기술적 깊이를 전달하는 것은 아니다. 이 기술적인 노력의 세부 사항은 예비 설계 보고서에 설명되어 있다. 개발자는 일반 작동 시나리오와 중요한 우발 사건으로 PDR의 프리젠테이션을 제한할 수 있다.

Materials presented at PDR do not necessarily convey the technical depth that the development team has achieved during preliminary design; details of this technical effort are documented in the preliminary design report. Developers limit the PDR presentation to the nominal operating scenarios and significant contingency cases.

 

프레젠테이션 관리자, 사용자 요구사항 정의의 팀과 CCB를 투사하는 것이다. 응용 프로그램 전문가, 분석가, 품질 보증 담당자 및 관리자는 이전에 공식적인 검토 참석에 예비 설계 자료의 상세한 기술 검토를 수행한다. 그들은 시스템 설계를 평가하고 프레젠테이션 중에 한 후, 곧바로 개발 팀에 의견과 비판을 제공한다. RID를 여전히 해결해야 할 문제를 기록하는 참가자에 의해 사용된다. PDR 형식과 일정은 PDR 하드 카피 자료 (그림 5-7)의 개요 다음에, 그림 5-6에 나와 있다.

The presentation is directed to project managers, users, the requirements definition team, and the CCB. Applications specialists, analysts, quality assurance personnel, and managers perform a detailed technical review of the preliminary design material prior to attending the formal review. They evaluate the system design and provide comments and critiques to the development team during and immediately after the presentation. RIDs are used by participants to record any issues that still need to be resolved. The PDR format and schedule are shown in Figure 5-6, followed by an outline of the PDR hardcopy materials (Figure 5-7).

 

PRELIMINARY DESIGN REPORT

This report is prepared by the development team as the primary product of the preliminary design phase. It presents the high-level design of the system and forms the basis for the detailed design document. The suggested contents are as follows:

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

2.    Design  overview

a.   Design drivers and their order of importance (e.g., performance, reliability, hardware, memory considerations, operating system limitations, language considerations, etc.)

b.   Results of reuse tradeoff analyses; the reuse strategy

c.   Critique of alternative designs

d.   Discussion and high-Ievel diagrams of the selected system design, showing hardware interfaces, external data interfaces, interconnections among subsystems, and data flow

e.   A traceability matrix of the subsystems against the requirements

f.   Design status

(1)    List of constraints, concerns, and problem areas and their effects on the design

(2)    List of assumptions and possible effects on design if they are wrong

(3)    List of TBD requirements and an assessment of their effect on system size, required effort, cost, and schedule

(4)    ICD status

(5)    Status of prototyping efforts

g.   Development environment (i.e., hardware, peripheral devices, etc.)

 

3.    Operations  overview

a.   Operations scenarios/scripts (one for each major product that is generated).  Includes the form and volume of the product and the frequency of generation. Panels and displays should be annotated to show what various selections will do and should be traced to a subsystem

b.   System performance considerations

c.   Error recovery strategies (automatic fail-over, user intervention, etc.)

 

4.    Design description for each subsystem or major functional breakdown:

a.   Discussion and high-level diagrams of subsystem, including interfaces, data flow, and communications for each processing mode

b.   High-Level description of input and output

c.   High-level 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, i.e., error processing and recovery)

d.   Structure charts or object-oriented diagrams expanded to two levels below the subsystem driver

e.   Prologs (specifying the unit’s purpose, operation, calling sequence arguments, external references, etc.) and program design language (PDL) for each identified unit (Prologs and PDL are normally published in a separate volume.)

 

5.    Data interfaces for each internal and external interface:

a.   Description, including name, function, frequency, coordinates, units, and computer type, length, and representation

b.   Format

(1)    Organization, access method, and description of files (i.e., data files, tape, etc.)

(2)    Layout of frames, samples, records, and/or message blocks

(3)    Storage  requirements

Figure 5-5. Preliminary Design Report Contents

 

PDR FORMAT

Presenters — software development team

Participants

•      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

Schedule — after the preliminary design is complete and before the detailed design phase begins

Agenda — selective presentation of the preliminary design of the system

Materials Distribution

•      The preliminary design report is distributed at least 1 week before PDR.

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

Figure 5-6. PDR Format

 

EXIT CRITERIA

 

개발 팀은 세부 설계를 진행 할 준비가 되어 있는지 여부를 확인하려면 관리자는 다음과 같은 질문을 한다:

  • 재사용후보인모든컴포넌트들이분석되었는가? 재사용과신규개발사이의트레이드오프가 신중하게 조사되었는가?
  • 개발자는 대안 설계방식을 평가하고최적의디자인을 선택했는가?
  • 모든설계도면, 프롤로그와 PDL(또는패키지사양을 적용할경우)규정수준으로생성되었는가? 그들은검사및인증을받은적이있는가?
  • 핵심종료기준이 충족 되었는가?즉,예비설계보고서제작및배포되고, PDR이성공적으로완료되었으며, 모든PDR RID들이답을얻었는가?

이러한 질문에 관리자가 “예”라고 답변을 할 때, 예비 설계 단계가 완료된다.

 

To determine whether the development team is ready to proceed with detailed design, managers should ask the following questions:

 

  • Have all components that are candidates for reuse been analyzed? Have the trade-offs between reuse and new development been carefully investigated?
  • Have developers evaluated alternate design approaches and chosen the optimum design?
  • Have all design diagrams, prologs and PDL (or package specifications, if applicable) been generated to the prescribed level? Have they been inspected and certified?
  • Have the key exit criteria been met? That is, has the preliminary design report been produced and distributed, has the PDR been successfully completed, and have all PDR RIDs been answered?

 

When the manager can answer “yes” to each of these questions, the preliminary design phase is complete.

 

HARDCOPY  MATERIAL  FOR  THE  PDR

 

1.       Agenda — outline of review material

2.       Introduction — background of the project and system objectives

3.       Design  overview

a.  Design drivers and their order of importance (e.g., performance, reliability, hardware, memory considerations, programming language, etc.)

b.  Results of reuse tradeoff analyses (at the level of subsystems and major components)

c.  Changes to the reuse proposal since the SSR

d.  Critique of design alternatives

e.  Diagram of selected system design.   Shows products generated, interconnections among subsystems, external interfaces.  Differences between the system to be developed and existing, similar systems should be emphasized

f.   Mapping of external interfaces to ICDs and ICD status

 

4.       System  operation

a.  Operations scenarios/scripts — one for each major product that is generated.  Includes the form of the product and the frequency of generation.  Panels and displays should be annotated to show what various selections will do and should be traced to a subsystem

b.  System  performance  considerations

c.  Error recovery strategies

 

5.       Major software components — one diagram per subsystem

6.       Requirements traceability matrix mapping requirements to subsystems

7.       Testing strategy

a.  How test data are to be obtained

b.  Drivers/simulators to be built

c.  Special considerations for Ada testing

8.       Design  team  assessment   — technical risks and issues/problems internal to the software development effort; areas remaining to be prototyped

9.       Software development/management plan — brief overview of how the development effort is conducted and managed

10.    Software size estimates — one slide

11.       Milestones  and  schedules — one slide

12.       Issues, problems, TBD items beyond the control of the development team

a.  Review of TBDs from SSR

b.  Other issues

c.  Dates by which TBDs/issues must be resolved

Figure 5-7. PDR Hardcopy Material