Category Archives: Recommended Approach to SW Dev

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.

Advertisements

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

 

 

Section 4. 요구사항 분석 단계


목차

 

SECTION 4 요구사항 분석 단계

THE REQUIREMENTS ANALYSIS PHASE

4.0

 

 

개요

OVERVIEW

 

요구사항 분석 단계의 목적은 요구사항 및 사양이 가능하고 완전하며 일관성이 있는지 확인하고 그들이 개발 팀에 의해 이해되는 것이다.

 

The purpose of the requirements analysis phase is to ensure that the requirements and specifications are feasible, complete, and consistent, and that they are understood by the development team.

 

TAILORING NOTE

대형 프로젝트에서 요구사항 분석은 PSRR에서 시작된다. 개발 팀의 주요 구성원은 검토 자료를 조사 검토 자체에 참여하고, 잠시 후 요구사항을 분류하기 시작한다.

On large projects, requirements analysis begins at the PSRR. Key members of the development team examine the review materials, participate in the review itself, and begin classifying requirements shortly thereafter.

 

일반적인 개발 팀은 다음과 같이 구성된다.

  • 프로젝트 리소스를 관리하고, 진행 상황을 모니터링하며, 기술 컨설턴트 역할을 하는 하는 프로젝트 관리자
  • 기술 방향 및 일일 감독을 제공하는 프로젝트 (또는 작업) 지도자,
  • 기술적인 작업을 수행하는 프로그래머와 어플리케이션 전문가
  • 품질 보증 담당자
  • 프로젝트 사서 (방법 및 도구를 참조)

A typical development team comprises

  • the project manager, who manages project resources, monitors progress, and serves as a technical consultant
  • the project (or task) leader, who provides technical direction and daily supervision
  • the programmers and application specialists who perform the technical work
  • a quality assurance representative
  • a project librarian (see METHODS & TOOLS)

 

요구사항 정의 팀은 요구사항 및 사양을 완료하고 SRR을 보유하고 후에 요구사항 분석이 시작된다. 요구사항 분석 시, 개발 팀의 구성원은 주의 깊게 요구사항 및 사양 문서를 연구한다. 그들은 누락, 모순, TBDs 및 설명 또는 증폭을 필요 사양을 밝히기 위해서 문서의 각 문을 항목별로 정리하고 분류한다. 개발 팀은 (예를 들어, 구조화 된 또는 분석 객체 지향) 프로젝트에 적합한 분석 방법론을 사용하여, 내용의 다음 단계로 요구사항 정의 단계에서 수행 된 분석을 한다. 분석이 완료되면, 팀은 SSR에 그 결과(findings)를 제시한다.

 

Requirements analysis begins after the requirements definition team completes the requirements and specifications and holds the SRR. During requirements analysis, members of the development team carefully study the requirements and specifications document. They itemize and categorize each statement in the document to uncover omissions, contradictions, TBDs, and specifications that need clarification or amplification. The development team takes the analysis that was performed in the requirements definition phase to the next level of detail, using the appropriate analysis methodology for the project (e.g., structured or object-oriented analysis). When analysis is complete, the team presents its findings at an SSR.

 

개발 팀은 전체 단계에서 요구사항 정의 팀과 긴밀하게 작업한다. 요구사항 정의 팀은 워크스루에 참여하는 질문에 대한 답변, 요구사항의 문제를 해결하고, SSR에 참석한다. 한편, 프로젝트 관리자는 소프트웨어 시스템을 개발할 때 및 개발 노력을 관리할 때에 사용되는 접근 방법을 계획하고, 현 단계 동안 생성된 산출물을 검토한다.

 

The development team works closely with the requirements definition team during the entire phase. The requirements     definition team participates in walk-throughs, answers questions, resolves requirements issues, and attends the SSR. Meanwhile, the project manager plans the approaches to be used in developing the software system and in managing the development effort, obtains and trains the necessary staff, and reviews the products produced during the phase.

 

그림 4-1은 요구 분석 프로세스의 상위 레벨의 데이터 흐름도이다.

 

Figure 4-1 is a high-level data flow diagram of the requirements analysis process.

4.1

Figure   4-1.      Analyzing Requirements

 

핵심 활동들

KEY ACTIVITIES

 

요구사항 분석 단계에서, 활동들은 주로 요구사항 정의팀, 개발 팀, 소프트웨어 개발 관리자 사이에 주로 나누어진다. 각각의 요구사항 분석 단계에서 수행하는 주요 활동은 다음 절에서 세분화된다. 그림 4-2은 이러한 활동은 일반적으로 계획되는 방법을 보여주는 샘플 타임 라인이다.

 

In the requirements analysis phase, activities are divided primarily among the requirements definition team, the development team, and software development managers. The key activities that each performs during the requirements analysis phase are itemized in the following subsections. Figure 4-2 is a sample timeline showing how these activities are typically scheduled.

 

 

요구사항 정의 팀의 활동들

Activities of the Requirements Definition Team

 

  • 사양에 있어서의 모호함, 불일치, TBDs를 해결한다. 개발 팀을 위한 요구사항 및 사양의 초기 워크스루를 실시하고 나중에 워크스루에 참여한다. 개발자의 모든 질문들에 응답한다.개발 팀에 의해 제기된 요구사항 문제를 해결한다. 요구사항 및 사양 문서에 승인된 수정 사항을 통합한다.

 

  • SSR에 참여 한다.

 

  • Resolve ambiguities, discrepancies, and TBDs in the specifications. Conduct the initial walk-throughs of the requirements and specifications for the development team and participate in later walk-throughs. Respond to all developer questions.Resolve the requirements issues raised by the development team. Incorporate approved modifications into the requirements and specifications document.

 

  • Participate in the SSR.

 

 

개발 팀의 활동들

Activities of the Development Team

 

  • 요구사항을 분석하고 분류한다. 각각의 요구사항 및 사양을 워크스루하고 명확화하기 위해 요구사항 정의 팀과 만난다.요구사항 및 명세 문서에서의 과 누락 사양, 충돌 모호하거나, 불가능을 확인한다. 필수의 분류를 명세하기 위한 검토가 필요하며, 요구사항 문서의 각 항목에 분류, 단순 정보(information only) 또는 TBD를 필요로 한다.

 

  • Analyze and classify requirements. Meet with the requirements definition team to walk through and clarify each requirement and specification. Identify requirements and specifications that are missing, conflicting, ambiguous, or infeasible. Assign a classification of mandatory, requires review, and needs clarification, information only, or TBD to each item in the requirements and specifications document.

 

사양을 검증하기 위해 구조적 분석 또는 객체 지향 분석을 사용한다. 요구사항 및 사양의 고 수준의 다이어그램을 확장하여 낮은 수준의 상세하게 확장하고 누락된 부분을 채워 넣어서 모든 명세가 같은 수준에서 표현되도록 한다. 사용자의 상호 작용 및 주요 데이터를 저장 (예를 들어, 고도의 기록 파일)이 완벽하게 명세되어 있는지 확인한다.

 

Use structured or object-oriented analysis to verify the specifications. Expand the high-level diagrams in the requirements and specifications document to a lower level of detail, and supply missing diagrams so that all specifications are represented at the same level. Ensure that user interactions and major data stores (e.g., attitude history files) are completely specified.

 

이용 가능한 자원의 관점에서 컴퓨터 용량 및 성능 요구사항의 타당성을 확인한다. 기존 시스템들에 지정된 기능 / 알고리즘을 비교하여 초기 성능 예측을 설정한다. SOC에 설명된 운영 시나리오에 대한 전반적인 성능 (CPU, I / O 등)을 모델로 추정치를 사용한다. 이런 결과에 고려하도록 하기 위해 SOC 시나리오를 조정한다.

 

Determine the feasibility of computer capacity and performance requirements in view of available resources. Establish initial performance estimates by comparing specified functions/algorithms with those of existing systems. Use the estimates to model overall performance (CPU,         I/O, etc.) for the operational scenarios described in the SOC. Adjust the SOC scenarios to take these results into account.

 

요구사항 정의 팀과 워크스루를 통해 요구사항의 분류 및 분석을 수행한다.

Walk through the results of classification and analysis with the requirements definition team.

 

  • 현실적인 계획으로 재사용 제안을 개정(refine)한다. 기존 소프트웨어의 현재 작동 기능과 요구사항 기준선에 대한 변경의 관점에서 SOC의 소프트웨어 재사용 제안을 분석한다.
  • 기술적 위험 영역을 식별한다. 이러한 위험을 최소화하기 위해 프로토타이핑을 하거나 다른 적절한 기술을 계획하고 수행한다.
  • SSR전에 요구사항 분석 보고서를 준비하고 배포한다.
  • SSR을 실시하고 모든 RID를 해결한다.

 

  • Refine the reuse proposal into a realistic plan. Analyze the software reuse proposal in the SOC in light of the existing software’s current operational capabilities and any changes to the requirements baseline.
  • Identify areas of technical risk. Plan and conduct prototyping efforts or other appropriate techniques to minimize these risks.
  • Prepare the requirements analysis report and distribute it before the SSR.
  • Conduct the SSR and resolve all RIDs.

 

워크스루, 요구사항 분류, 분석 방법에 대한 자세한 정보는 아래 방법 및 도구를 참조한다.

See METHODS AND TOOLS below for more information about walk-throughs, requirements classifications, and analysis methodologies.

 

The contents of the requirements analysis report and the software development/ management plan are covered under PRODUCTS below. The SSR is discussed separately at the end of this section.

 

프로젝트의 크기, 비용 및 일정을 추정 지침에 대한 관리자의 소프트웨어 개발을 위한 핸드북 및 소프트웨어 비용 추정에 대한 접근을 (참고 자료 각각 12, 18)를 참조하십시오.

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

18. —,SEL-83-001, An Approach to Software Cost Estimation, F. E. McGarry, G. Page,

D. N. Card, et al., February 1984

See the Manager’s Handbook for Software Development and the Approach to Software Cost Estimation (References 12 and 18, respectively) for guidance in estimating project size, costs, and schedule.

 

 

관리팀의 활동들

Activities of the Management Team

 

  • 소프트웨어 개발 / 관리 계획 (SDMP)을 준비한다. 적절한 크기, 비용 및 일정 데이터뿐만 아니라 지난 프로젝트로부터 얻은 교훈(lesson-learned)에 대한 과거 프로젝트 및 관련 기록을 검토한다. 어떤 리소스가 필요한지를 결정하고, 인력 프로파일을 개발하고, 프로젝트 비용을 추정한다. 프로젝트 위험을 식별하고 이를 최소화 할 계획을 세운다. 프로젝트에 사용되는 기술과 관리 방법을 문서화한다.

 

  • Prepare the software development/management plan (SDMP). Review the histories of related, past projects for applicable size, cost, and schedule data as well as lessons learned. Determine what resources are needed, develop a staffing profile, and estimate project costs. Identify project risks and plan to minimize them. Document the technical and management approaches that will be used on the project.

 

  • 직원 및 개발 팀을 훈련한다. 가능한 한 빨리 다음의 SRR (또는 대형 프로젝트에, PSRR)와 같은 프로젝트에 직원을 데려온다. 개발 팀 구성원, 관리자 및 요구사항 정의팀 사이의 의사소통을 확인한다.또한, 요구사항 정의팀이 SRR을 대응하기에 충분한 직원을 보유하여 TBD 및 변화하는 요구사항이 즉시 주어지고 철저한 분석을 할 수 있도록 한다.

 

  • Staff and train the development team. Bring staff onto the project as soon as possible following SRR (or, on large projects, PSRR). Ensure communications among development team members, managers, and the requirements definition team.Also make certain that the requirements definition team is adequately staffed following SRR, so that TBD and changing requirements can be given prompt and thorough analysis.

 

  • 요구사항의 문제 해결을 용이하게 하기 위해 분석가 및 고객과 상호 작용한다. 제안된 요구사항 변경의 타당성을 평가하기 위해 비용과 일정에 미치는 영향을 추정하기 위해 팀 리더와 함께 작업한다.

 

  • Interact with analysts and customers to facilitate resolution of requirements issues. Work with team leaders to assess the feasibility of proposed requirements changes and to estimate their impact on costs and schedules.

 

  • 요구사항 분석 과정의 산출물을 검토한다. 요구사항 분류, 데이터 흐름 또는 객체 지향 다이어그램, 데이터 사전(data dictionary), 요구사항 분석 보고서 및 SSR 하드 카피 자료를 검토한다. SSR을 위한 일정을 예약하고 해당 그룹의 참여를 보장한다.

 

  • Review the products of the requirements analysis process. Look at requirements classifications, data-flow or object-oriented diagrams, the data dictionary, the requirements analysis report, and the SSR hardcopy materials. Schedule the SSR and ensure participation from the appropriate groups.

 

  • 예비 설계 단계로의 순차적인 전환을 계획한다. 개발 팀 멤버에게 예비 설계에 적용할 수 있는 소프트웨어 개발 계획의 일부를 전달한다. (예를 들어, 설계 기준 및 형상 관리 절차) 그리고 설계 동안 사용할 특별한 소프트웨어 엔지니어링 접근법들을 엔지니어들에게 교육시킨다. 핵심 멤버가 SSR을 위해 준비하는 동안 개발 팀의 나머지는 사전 예비 활동을 시작한다.

 

  • Plan an orderly transition to the preliminary design phase. Convey to the development team members the parts of the software development plan that apply to preliminary design (e.g., design standards and configuration management procedures) and instruct them in the specific software engineering approach to use during design. While the key team members are preparing for SSR, have the remainder of the development team begin preliminary design activities.

4.2

Figure 4-2:     Timeline of Key Activities in the Requirements Analysis Phase

 

방법 및 도구들

METHODS AND TOOLS

 

다음과 같은 방법, 기술 및 도구는 요구사항 분석 단계의 활동을 지원하는 데 사용된다:

 

The following methods, techniques, and tools are used to support the activities of the requirements analysis phase:

 

  • 요구사항 워크스루
  • 요구사항 분류
  • 요구사항 양식
  • 구조화 되고 객체 지향 요구사항 분석
  • CASE 도구
  • 프로토타이핑
  • 프로젝트 라이브러리

 

  • Requirements walk-throughs
  • Requirements classifications
  • Requirements forms
  • Structured and object-oriented requirements analysis
  • CASE tools
  • Prototyping
  • The project library

 

각각은 아래에서 논의된다.

Each is discussed below.

 

 

요구사항 워크스루

Requirements Walk-Throughs

 

요구사항 분석 단계의 시작 부분에서, 개발자는 요구사항 및 사양을 충족하는 요구사항 정의 팀의 분석자와 비공식적으로 만난다. 이러한 초기 워크스루 동안, 분석자는 각각의 사양을 논의하고 왜 어떤 알고리즘이 다른 것들을 제외하고 선택하였는지에 대해서 설명하며 개발자에게 질문하고 문제를 제기할 수 있는 기회를 제공한다.

 

At the beginning of the requirements analysis phase, developers meet informally with analysts of the requirements definition team to go through the requirements and specifications.  During these initial walk-throughs, analysts discuss each of the specifications, explain why certain algorithms were selected over others, and give developers the opportunity to raise questions and issues.

 

개발자가 요구사항 및 명세를 분석하고 분류한 후, 그들은 요구사항 정의팀에 대한 자신의 결과의 워크스루를 수행한다. 하나의 워크스루는 시스템에서 각각의 주요 기능 혹은 목적에 대해서 개최되어야 한다. 향후 이러한 워크스루 동안 양쪽의 팀은 문제가 있는 명세 목록을 검토하고 요구사항 문서에서 변경되어야 할 필요가 있는 부분을 논의한다.

 

After developers have analyzed and classified the requirements and specifications, they conduct walk-throughs of their results for the requirements definition team. One walk-through should be held for each major function or object in the system. During these later walk-throughs, both teams review all problematic specification items and discuss any needed changes to the requirements and specifications document.

 

모든 문제 영역과 결정이 문서화되어 있는지를 확인하기 위해, 개발 팀의 한 멤버는 워크스루 회의의 상세한 내용을 기록해야 한다. 개발자는 요구사항 정의팀에 의한 요청 확인, 추가 분석, 또는 다른 작업을 위해 질의 응답 양식을 작성할 필요가 있다.

 

To ensure that all problem areas and decisions are documented, one member of the development team should record the minutes of the walk-through meeting. Developers will need the minutes to fill out requirements question-and-answer forms for any issues that require confirmation, further analysis, or other action by the requirements definition team.

 

 

요구사항 분류

Requirements Classification

 

개발 팀은 요구사항 및 사양 문서를 잘 알고 있을 때, 그들은 요구사항 및 사양 문서의 각 통로 (문장이나 단락을) 가지고 필수 중 하나로 분류한다: 필수사항, 검토가 필요함, 분류가 필요함, 정보 전달 목적(information only), 또는 TBD

 

When the development team is thoroughly familiar with the requirements and specifications document, they take each passage (sentence or paragraph) in the requirements and specifications document and classify it as either mandatory, requires review, needs clarification, information only, or TBD.

 

  • 항목이 SIRD 또는 SORD와 같이 프로젝트 수준의 요구사항 문서로 정의되어 있거나 항목이 프로젝트 수준의 요구사항 분석에서 파생된 경우 해당 아이템은 필수이다. 필수 항목이 사양에서 제거되는 경우, 시스템은 프로젝트 레벨 요건을 충족하지 못할 것이다.

 

  • An item is mandatory if it is explicitly defined in project-level requirements documents such as the SIRD or SORD, or if it has been derived from analysis of the project-level requirements. If mandatory items are removed from the specifications, the system will fail to meet project-level requirements.

 

  • (프로젝트 수준의 요구사항 및 운영 개념을 기반으로 한) 특정 ​​요구사항 또는 사양에 대한 명백한 요구가 없다면, 아이템은 검토를 요구한다. (요구사항 정의팀에 의해 추가 분석되어야 함)가 필요하다. 해당 항목은 CDR전에 (사양 변경에 의해) 사양에서 제거되거나 필수 카테고리로 이동해야 한다.

 

  • If (on the basis of project-level requirements and the system and operations concept) there is no apparent need for a particular requirement or specification, then that item requires review (i.e., further analysis by the requirements definition team). The item must be deleted from the specification (by means of a specification modification) or moved into the mandatory category before CDR.

 

  • 아이템이 모호하고타당하지않은것으로보이거나요구사항의하나이상과충돌할때, 해당아이템은분류가필요하다.

 

  • An item needs clarification when it is ambiguous, appears infeasible, or contradicts one or more of the other requirements or specifications.

 

항목이 요구사항이나 사양이 없는 경우 아이템은 information only로 표기된다. 이러한 항목은 배경 정보, 소프트웨어 개발자를 위한 도움이 되는 힌트 등을 제공할 수 있다.

 

An item is labelled as information only if it contains no requirement or specification per se. Such an item may provide background information, helpful hints for the software developer, etc

 

  • 만약 (1) 이거나 (2)인 경우, 요구사항이나 사양 항목은 TBD이다.

(1): 항목이 “프로세스가 현재 시점에서 TBD와 같은 문장을 포함한다.”

(2): 항목과 관련된 정보가 없거나 정의되지 않았다.

 

  • A requirement or specification item is TBD if (1) the item contains a statement such as “the process is TBD at this time,” or (2) information associated with the item is missing or undefined.

 

요구사항 및 사양은 데이터베이스에 사용할 수 있는 경우, 분류를 입력하고 온라인 데이터베이스에 논평을 지원. 그렇지 않으면, 각각의 요구사항이나 사양 항목을 요약 요약 목록을 작성하고, 분류를 할당할 목록을 사용한다.

 

If the requirements and specifications are available in a database, enter the classifications and supporting commentary into the database online.  Otherwise, summarize each requirement or specification item, create a list of the summaries, and use the lists to assign classifications.

 

요구사항 양식

Requirements Forms

 

요구사항 분석 및 후속 단계에서, 질의 응답 형태의 통신에 사용 기록 요구사항의 문제 사항에 있다. 사양 변경은 요구사항의 변경을 문서화하는 데 사용된다.

 

During the requirements analysis and subsequent phases, question- and-answer forms are used to communicate and record requirements issues and clarifications. Specification modifications are used to document requirements changes.

 

개발 팀은 요구사항 정의의 팀에 제출 질문을 추적하고 요구사항에 대한 자신의 가정을 확인하기 위해 질의 응답 형태를 ​​사용한다. 요구사항 정의 팀의 관리자는 개발자가 자신의 팀의 응답 인원 및 기한을 지정 양식을 사용한다. 양식에 제출된 질문에 대한 답변은 서면으로 해야 한다.

 

The development team uses question-and-answer forms to track questions submitted to the requirements definition team and to verify their assumptions about requirements. Managers of the requirements definition team use the forms to assign personnel and due dates for their team’s response to developers. Responses to questions submitted on the forms must be in writing.

 

질문과 대답의 형태는 요구사항 또는 사양을 변경할 권한을 부여하는 데 사용할 수 없다. 제출된 질문이나 문제의 분석은 요구사항의 변경이 필요하다는 것을 알 수 있는 경우, 요구사항 정의 팀의 구성원은 사양 변경 초안을 작성한다. 제안된 사양 변경은 요구사항 정의 및 개발 팀 모두의 관리자에 의해 CCB의 승인을 받아야 한다. 요구사항 정의의 팀은 요구사항 및 사양 문서에 승인 된 모든 규격의 수정을 포함한다.

 

The question-and-answer form cannot be used to authorize changes to requirements or specifications. If analysis of the submitted question or issue reveals that a requirements change is needed, members of the requirements definition team draft a specification modification. Proposed specification modifications must be approved by the managers of both the requirements definition and the development teams and by the CCB. The requirements definition team incorporates all approved specification modifications into the requirements and specifications document.

 

 

분석 방법 및 CASE 도구들

Analysis Methods and CASE Tools

 

요구사항 분석에 적용 할 수 있는 방법과 도구는 섹션 3의 요구사항 정의 단계에서 정의된 것과 동일하다. 개발 팀은 일반적으로 요구사항 정의 팀에 의해 사용된 방법과 동일한 방법을 사용하는데 이는 명세에서 제공되는 상세한 수준으로 분석을 수행하기 위해서이다. 이것은 개발 팀이 이전 분석을 검증하고 문서에 존재할 수 있는 갭을 채울 수 있도록 한다. 만약 CASE 도구가 요구사항 정의단계에서 데이터 플로우나 객체 지향 다이어그램을 생성하기 위해서 사용된다면, 그것은 요구사항 분석 단계에서 동일한 도구의 사용을 하는 것이 중요하다. 개발자가 다시 입력하거나 다른 도구에 대한 다이어그램으로 다시 작성해야 하는 경우 생산성 및 통신 지원 등의 CASE 도구의 가치는 크게 감소한다.

 

The methods and tools applicable for requirements analysis are the same as those recommended for the requirements definition phase in Section 3. The development team will generally use the same method as was used by the requirements definition team to take the analysis down to a level of detail below that provided in the specifications. This allows the development team to verify the previous analysis and to fill in any gaps that may exist in the document. If CASE tools were used in the requirements definition phase to generate data flow or object diagrams, it is important to use the same tools in the requirements analysis phase. The value of a CASE tool as a productivity and communication aid is greatly reduced if developers must re-enter or reformat the diagrams for a different tool.

 

요구사항 정의팀이 분석을 위해 기능 분해를 사용하고 개발 팀이 객체 지향 설계를 생성할 필요가 있는 경우라면, 부가적인 분석 단계가 필요하다. 개발 팀은 낮은 수준으로 명세의 상세화된 다이어그램을 그려야 하고, 그 다음 그 다이어그램이 상위 수준의 요구사항을 백업할 수 있도록 사용한다. 이것은 개발 팀이 새롭고, 객체지향적인 관점으로 시스템을 바라보고 시스템을 필요에 따라 재구성할 수 있도록 한다.

 

If the requirements definition team has used functional decomposition for their analysis and the development team needs to generate an object-oriented design, then extra analysis steps are required. The development team must diagram the details of the specification at a low level, then use the diagrams to abstract back up to higher-level requirements. This allows the team to take a fresh, object-oriented look at the system architecture and to restructure it as needed.

 

 

프로토타이핑

Prototyping

 

요구사항 분석 단계에서 프로토타이핑의 활동은 일반적으로 위험을 줄이기 위해 실시하고 있다. 익숙하지 않은 기술 (예를 들어, 하드웨어 또는 새로운 개발 언어 기능) 프로젝트에 사용될 경우, 프로토타이핑은 변경 사항에 적은 비용으로 할 때 개발 팀은 초기 수명주기 기술의 가능성을 평가할 수 있다. 시스템의 성능이나 신뢰성이 주요, 해결되지 않은 문제의 경우, 팀은 중요한 작업이나 알고리즘을 프로토타이핑 할 수 있다.

 

During the requirements analysis phase, prototyping activities are usually conducted to reduce risk. If unfamiliar technology (e.g., hardware or new development language features) will be employed on the project, prototyping allows the development team to assess the feasibility of the technology early in the life cycle when changes are less costly to effect. If system performance or reliability is a major, unresolved issue, the team can prototype critical operations or algorithms.

 

사용자인터페이스에 대한 요구사항이 프로토타이핑 되어야 하는 프로젝트에서 인터페이스는 시스템 성공에 중요하며 사용자들은 그들의 필요를 잘 모르기 때문에 도구는 개발자들로 하여금 스크린과 윈도우를 빨리 셋업할 수 있도록 한다. 그와 같은 도구로 개발자들은 사용자들로 하여금 과도한 프로그래밍 없이 시스템을 보고 느낄 수 있도록 하여 조기에 피드백을 제공할 수 있도록 한다. 도구는 메뉴를 생성할 수 있어야 하고 여러 개의 스크린을 생성할 수 있어야 하며 입력에 따른 반응을 해야 한다. 성공적으로 SEL에서 사용 된 하나의 도구는 댄 브리 클린의 데모 프로그램이다.

 

On projects where the requirements for the user interface must be prototyped — either because the interface is critical to system success or because users are uncertain of their needs — a tool that allows the developer to set up screens and windows rapidly is often essential. With such a tool, the developer can give the user the “look and feel” of a system without extensive programming and can obtain early feedback. The tool should be able to generate menus, multiple screens, and windows and respond to input. One such tool that has been successfully used in the SEL is Dan Bricklin’s Demo Program.

 

어떤 프로토타이핑 활동이 수행되는 것이 필요하다는 것을 보장하기 위해서 주의 깊게 실시되어야 하고 명확한 목표를 가지고 있어야 하며 표준 개발 절차를 우회하는 수단으로 사용되지 않아야 한다. 프로토타이핑 노력을 계획하는 방법에 대한 자세한 지침은 4 장에서 제품을 참조하라.

 

Caution must be exercised to ensure that any prototyping activity that is conducted is necessary, has a defined goal, and is not being used as a means to circumvent standard development procedures. See PRODUCTS in Section 4 for additional guidance on how to plan a prototyping effort.

 

 

프로젝트 라이브러리

Project Library

 

각각의 소프트웨어 개발 프로젝트에서, 하나의 팀 구성원은 사서의 역할이 할당된다. 프로젝트 기간 동안, (때로는 소프트웨어 형상 관리자라고도 함) 사서는 모든 프로젝트 정보의 저장소인 프로젝트 라이브러리를 유지한다. 사서도 구성 소프트웨어 라이브러리를 관리하고 프로젝트 활동을 지원하는 다양한 소프트웨어 도구를 운영하고 있다.

 

In each software development project, one team member is assigned the role of librarian. During a project, the librarian (sometimes called the software configuration manager) maintains the project library, which is a repository of all project information. The librarian also maintains configured software libraries and operates various software tools in support of project activities.

 

사서는 요구사항 분석 단계에서 프로젝트 라이브러리를 설정한다. 일반적으로, 프로젝트 라이브러리는 결정의 기록 또는 정보를 통신하기 위한 목적으로 개발 팀에 의해 사용되거나 생산 서면 자료를 포함한다. 그것은 요구사항 및 사양 문서, 요구사항을 질문과 대답 양식, 승인된 사양 수정, 요구사항 분석 요약 보고서 등을 포함한다. 이러한 소프트웨어 개발 / 관리 계획 등 필요한 관리 정보도 포함되어 있다.

 

The librarian establishes the project library during the requirements analysis phase. In general, the project library contains any written material used or produced by the development team for the purpose of recording decisions or communicating information. It includes such items as the requirements and specifications document, requirements question-and-answer forms, approved specification modifications, and the requirements analysis summary report. Necessary management information, such as the software development/management plan, is also included.

 

측정

MEASURES

 

다음 단락에서는 매니저가 요구 분석 단계 중에 개발 프로세스를 평가하는 데 사용할 수 있는 방법 및 평가 기준을 설명한다.

 

The following paragraphs describe the measures and evaluation criteria that managers can use to assess the development process during the requirements analysis phase.

 

목표 지표들

Objective Measures

 

요구사항 분석의 진행과 품질은 여러 가지 객관적인 측정을 검사하여 모니터링 한다:

 

  • 직원 시간 – 직원의 실제 노력, 혹은 총 합으로서의 누적 시간, 혹은 활동당 직원의 노력
  • 요구사항 질문 및 답변 – 제출한 질문지, 답변지의 개수 대비 답변된 수
  • TBD 요구사항 – 요구사항의 총 개수 대비 TBD로 분류 요구사항의 개수
  • 요구사항 변경 – 사양 변경이 승인 된 것에 대한 요구사항의 총 누적 수
  • 시스템 크기, 재사용, 노력, 일정의 추정 – 시스템에서 코드 라인의 총 예상 시간; 새 코드의 예측되는 길이, 재사용된 코드의 길이, 시스템을 개발하기 위해 필요한 예상되는 직원의 시간, 라이프사이클의 각 단계와 끝에서 예상되는 기간

 

The progress and quality of requirements analysis are monitored by examining several objective measures:

 

  • Staff hours — actual, cumulative hours of staff effort, as a total and per activity
  • Requirements questions and answers — the number of question- and-answer forms submitted versus the number answered
  • TBD requirements — the number of requirements classified as TBD versus the total number of requirements
  • Requirements changes — the total cumulative number of requirements for which specification modifications have been approved
  • Estimates of system size, reuse, effort, and schedule — the total estimated number of lines of code in the system; the estimated number of new, modified, and reused (verbatim) lines of code; the total estimated staff hours needed to develop the system; and estimated dates for the start and end of each phase of the life cycle.

 

이러한 방법 각각에 대해, 표 4-1는 누가 데이터를 제공하고 어떤 데이터가 수집되고 분석되는지에 대한 빈도, 그리고 데이터 수집이 요구사항 정의 단계 혹은 초기단계에서 계속되는지의 여부를 나타낸다.

 

For each of these measures, Table 4-1 shows who provides the data, the frequency with which the data are collected and analyzed, and whether data collection is continued from the requirements definition phase or newly initiated.

 

SEL은 요구사항의 분석 단계에서 통계를 수집하기 위해 3개의 하드 카피 형태를 사용한다. 인사 자료 양식은 매주 노력의 시간을 기록하는 개발 팀에 의해 사용된다. 이 프로젝트는 형태가 매달 크기와 노력이 개발 상태 양식이 요구사항 변경의 수를 기록하는 데 사용된다 추정 기록하고, 요구사항의 질문에 대 답의 수에 관리자에 의해 사용되는 추정하고 있다. SEL 데이터 수집 양식 및 절차에 대한 자세한 내용은 참조 19를 참조하십시오.

 

19. —,SEL-92-002, Data Collection Procedures for the Software Engineering Laboratory

(SEL) Database, G. Heller, J. Valett, M.Wild, March 1992

 

The SEL uses 3 hardcopy forms to collect metrics during the requirement s analysis phase. The Personnel Resources Form is used by the development team to record weekly effort hours. The Project Estimates Form is used by managers to record their monthly size and effort estimates The Development Status Form is used to record the number of requirements changes, and number of requirements questions vs. answers. See Reference 19 for detailed information about SEL data collection forms and procedures.

 

Table    4-1.       Objective Measures Collected   During the Requirements

4.1t

평가 범주

Evaluation Criteria

 

직원 시간은 보통 SDMP (그림 4-5)에 대한 소프트웨어 개발 관리자에 의해 생성된다 추정 직원의 노력의 프로필에 대해 그래프로 그려진다. 실제 인력 대비 계획의 초기 비교는 계획의 실행 가능성을 평가하는 데 사용된다.

 

Staff hours are usually graphed against a profile of estimated staff effort that is generated by the software development manager for the SDMP (Figure 4-5). This early comparison of planned versus actual staffing is used to evaluate the viability of the plan.

 

비행 역학 환경에서 예상보다 낮은 시간은 심각한 위험 신호이다 – 일정이 충족되는 경우에도 – 그들이 개발 팀이 일손 표시하기 때문이다. 너무 적은 수의 개발자가 요구사항 분석을 수행 할 경우, 팀은 요구사항 문제를 표면에 필요한 이해의 깊이를 얻을 수 없습니다. 그들은 훨씬 더 비용이 많이 드는 조정하는 경우 이러한 문제는 나중에 라이프 사이클에 표시된다.

 

In the flight dynamics environment, hours that are lower than expected are a serious danger signal — even if schedules are being met — because they indicate the development team is understaffed. If too few developers perform requirements analysis, the team will not gain the depth of understanding necessary to surface requirements problems. These problems will show up later in the life cycle when they are far more costly to rectify.

 

제출된 질문의 수와 수신된 응답 또는 요구사항의 변화에 많은 수의 수 사이의 성장 격차는 명확성, 정확성, 또는 요구사항 및 사양 문서에 제시된 요구사항의 완전성에 문제가 있을 수 있다. 유사한 과거의 프로젝트에서의 데이터는 이러한 숫자의 상대적인 크기의 의미를 평가하기 위해 사용되어야 한다.

 

A growing gap between the number of questions submitted and the number of responses received or a large number of requirements changes may indicate problems with the clarity, correctness, or completeness of the requirements as presented in the requirements and specifications document. Data from similar past projects should be used to assess the meaning of the relative sizes of these numbers.

 

미해결 TBD 요구 프로젝트 뒷부분 심각한 설계 변경을 필요로 할 수 있기 때문에, TBD 요구의 수는 이 단계에서 검사 될 수 있는 가장 중요한 척도이다. 분류 및 심각도에 따라 TBD 요구사항을 추적할 수 있다. 외부 인터페이스에 관한 TBD 요건들은 시스템 입력을 포함할 경우 특히 제일 중요하다. 내부 알고리즘에 영향을 미치는 TBDs은 일반적으로 그렇게 심각하지 않습니다.

 

Because unresolved TBD requirements can necessitate severe design changes later in the project, the number of TBD requirements is the most important measure to be examined during this phase. Categorize and track TBD requirements according to their severity. TBD requirements concerning external interfaces are the most critical, especially if they involve system input. TBDs affecting internal algorithms are generally not so serious.

 

하나 이상의 서브 시스템 또는 데이터 처리 알고리즘을 지원하기 위해 필요한 높은 수준의 데이터 구조의 기능 설계에 영향을 미칠 수 있다면 TBD 요구는 심각한 것으로 간주된다. 모든 심각한 TBD 요구사항이 해결 될 때까지 예비 디자인은 더 이상 진행하지 않는 것이 좋습니다. 그것은 하나 이상의 구성 요소를 포함하는 서브 시스템의 부분에 영향을 미치는 경우 TBD 요건은 명목상이라고(nominal) 여겨진다. 명목상의 TBD 요구사항의 많은 하나의 기능 영역에 존재하지 않는 예비 설계를 진행할 수 있다. 부수적 TBD 요구사항은 하나의 단위만 내부에 영향을 미치는 하나이다. 부수적인 TBD 요구사항은 상세 설계의 마지막에서 해결되어야 한다.

 

A TBD requirement is considered severe if it could affect the functional design of one or more subsystems or of the high-level data structures needed to support the data processing algorithms. Preliminary design should not proceed until all severe TBD requirements have been resolved. A TBD requirement is considered nominal if it affects a portion of a subsystem involving more than one component. Preliminary design can proceed unless large numbers of nominal TBD requirements exist in one functional area. An incidental TBD requirement is one that affects only the internals of one unit. Incidental TBD requirements should be resolved by the end of detailed design.

 

각 TBD 요구사항은 시스템 크기, 필요한 노력, 비용 및 일정에 미치는 영향을 추정한다. 종종 TBD 요구사항을 해결하는 데 필요한 정보는 나중에까지 사용할 수 있으며, 디자인은 고정 기한을 충족하기 위해 시작해야 한다. 이러한 추정치는 개발 일정의 불확실성을 결정하는 데 도움이 된다.

 

For each TBD requirement, estimate the effect on system size, required effort, cost, and schedule. Often the information necessary to resolve a TBD requirement is not available until later, and design must begin to meet fixed deadlines. These estimates will help determine the uncertainty of the development schedule.

 

MORE MEASURES

요구사항 분석 단계 중에 진행 과정상의 이러한 추가 조치를 추적을 고려한다.

• 총 요구사항에 대 분류 요구사항의 수

• 총 예상 다이어그램 대 완료 요구사항 다이어그램의 수

 

Consider tracking these additional measures of progress during the requirements analysis phase:

• number of requirements classified vs. total requirements

• number of requirements diagrams completed vs. estimated total diagrams

4.3

Figure 4-3.           Effort Data Example — ERBS AGSS

 

시스템의 크기의 성장에 대한 예측은 프로젝트의 안정성의 또 다른 중요한 지표이다. 시스템의 최종 크기를 추정하는 것은 비용, 일정 및 인력 수준 (참조 12, 제 3 항)를 결정하기 위한 절차의 첫 번째 단계이다. 응용 프로그램 환경 내에서 지난 프로젝트의 정보로 현재의 요구사항을 비교하여 초기 견적을 확인한다. 수명주기 전반에 걸쳐 매달 예상치를 그래프를 그려서 업데이트 한다.

 

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

 

The growth of system size estimates is another key indicator of project stability. Estimating the final size of the system is the first step in the procedure for determining costs, schedules, and staffing levels (Section 3 of Reference 12). Make the initial estimate by comparing current requirements with information from past projects within the application environment. Update and plot the estimate each month throughout the life cycle.

 

프로젝트가 성숙하면, 추정의 변화의 정도가 안정된다. 요구사항의 성장이 예상 범위를 넘어서 시스템의 크기 추정치를 밀어 경우, 엄격한 변경 관리 절차를 구현하거나 추가 자금 및 개정된 프로젝트 계획을 얻을 필요가 있다. 크기 추정치를 평가하는 추가적인 지침은 참조 (12)의 제 6 절을 참고하라.

 

As the project matures, the degree of change in the estimates should stabilize. If requirements growth pushes the system size estimate beyond expected limits, it may be necessary to implement stricter change control procedures or to obtain additional funding and revise project plans. See Section 6 of Reference 12 for additional guidance in evaluating size estimates.

 

 

제품

PRODUCTS

 

다음과 같은 주요 제품은 이 단계에서 생성된다:

• 요구사항 분석 보고서
• 소프트웨어 개발 / 관리 계획
• 업데이트 요구사항 및 사양 문서
• 프로토타이핑 계획 (필요에 따라)

이 제품은 다음 단락에서 언급된다.

 

The following key products are produced during this phase:

 

  • The requirements analysis report
  • The software development/management plan
  • Updated requirements and specifications document
  • Prototyping plans (as needed)

 

These products are addressed in the paragraphs that follow.

 

 

요구사항 분석 보고서

The Requirements Analysis Report

 

요구사항 분석 보고서는 예비 설계를 시작하기 위한 기반을 구축하고, 따라서, 요구사항 분석 단계의 핵심 제품이다. 이 보고서는 다음을 포함한다:

 

The requirements analysis report establishes a basis for beginning preliminary design and is, therefore, a key product of the requirements analysis phase. This report includes the following:

 

  • 업데이트 된 재사용 플랜 (본래의 재사용 제안은 요구사항 정의 단계에 개발되었으며 시스템 및 운영 개념 문서에 기록된다. 그 문서는 승인된 요구사항 변경 및 재사용할 수 있는 소프트웨어의 현재 능력의 분석 결과를 반영하기 위해 조정된다.)
  • 운영시나리오에 대한 업데이트 (프로토타이핑 결과, 성능분석, 요구사항 변경및기능적재할당의관점에서)
  • 사양을 분석하고 완성하기 위해 생성되는 DFD나 객체 지향 다이어그램
  • 요구사항분석결과, 강조및문제점들, TBD요구사항들, 시스템제약, 개발가정들의요약
  • TBD요구사항이나 다른 요인들로부터 발생하는 비용 및 스케줄 위험뿐만 아니라 프로젝트의 기술적 위험의 분석

 

  • The updated reuse plan (The original reuse proposal was developed during the requirements definition phase and recorded in the systems and operations concept document. It is adjusted to reflect approved requirements changes and the results of analysis of the reusable software’s current capabilities.)
  • Updates to operational scenarios (in view of prototyping results, performance analyses, requirements changes, and functional reallocations)
  • The DFDs or object-oriented diagrams generated to analyze and complete the specifications
  • A summary of the results of requirements analysis, highlighting problematic and TBD requirements, system constraints, and development assumptions
  • An analysis of the technical risks of the project, as well as cost and schedule risks resulting from TBD requirements or other factors

 

그림 4-4은 요구사항 분석 보고서의 형식과 내용을 제시한다.

Figure 4-4 presents the format and contents of the requirements analysis report.

 

소프트웨어 개발/관리 계획

The Software Development/Management Plan

 

소프트웨어 개발 관리 계획(SDMP)은 프로젝트에 사용되는 특정 기술 및 관리 방법의 상세한 해설을 제공한다. SDMP에서 개발 팀 매니저는 현재 프로젝트에 맞게 권장되는 방법을 조정하는 지에 대해서 논의하고 실제 진행 데이터와 비교를 위한 기준으로 자원 및 일정 견적을 제공한다.

 

The SDMP provides a detailed exposition of the specific technical and management approaches to be used on the project. In the SDMP, the development team manager discusses how the recommended approach will be tailored for the current project and provides the resource and schedule estimates that will serve as a baseline for comparisons with actual progress data.

 

REQUIREMENTS ANALYSIS REPORT

This report is prepared by the development team at the conclusion of the requirements analysis phase. It summarizes the results of requirements analysis and establishes a basis for beginning preliminary design. The suggested contents are as follows:

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

2.        Reuse proposal — key reuse candidates and overall architectural concept for the system

3.        Operations overview — updates to system and operations concepts resulting from work performed during the requirements analysis phase

a.    Updated operations scenarios

b.    Operational modes, including volume and frequency of data to be processed in each mode, order, and type of operations, etc.

c.    Updated descriptions of input, output, and messages

4.        Specification analysis

a.    Summary of classifications (mandatory, requires review, information only, needs clarification, or TBD) assigned to requirements and specifications

b.    Problematic specifications — identification and discussion of conflicting, ambiguous, infeasible, untestable, and TBD requirements and specifications

c.    Unresolved requirements/operations issues, including the dates by which resolutions are needed

d.    Analysis of mathematical algorithms

5.        System constraints

a.    Hardware availability — execution, storage, peripherals

b.    Operating system limitations

c.    Support software limitations

6.        Performance estimates and models

7.        Development assumptions

8.        Risks, to both costs and schedules.  (These should include risks related to TBD or changing requirements, as well as technical risks.)

9.        Prototyping efforts needed to resolve technical risks, including the goals and completion criteria for each prototyping effort

10.     Data flow or object-oriented diagrams — results of all structured or object-oriented analysis of the requirements performed during the requirements analysis phase

11.     Data dictionary — for the updated processes, data flows, and objects shown in the diagrams

Figure 4-4. Requirements Analysis Report Contents

 

관리자는 요구사항 분석 단계에서 SDMP을 준비하고 개발 라이프 사이클 전반에 걸쳐 최신으로 유지한다. 이 계획은 중요하기 때문에 소프트웨어 개발에 대한 관리자의 수첩 (참고 12)에 자세히 설명되어 있다.

 

The manager prepares the SDMP during the requirements analysis phase and keeps it up to date throughout the development life cycle. Because of the primary importance of this plan, it is described in detail in the Manager’s Handbook for Software Development (Reference 12).

 

SDMP은 소프트웨어 개발 접근법을 포함한다; 위험과 위험 완화에 대한 설명; 시스템의 크기의 초기 추정; 및 일정, 인력, 자원, 프로젝트의 비용을 추정하고 있다. 그림 4-5은 SDMP의 내용을 간략하게 설명한다.

 

The SDMP includes a software development approach; a description of risks and risk mitigation; an initial estimate of the system’s size; and estimates of the schedule, staffing, resources, and cost of the project. Figure 4-5 outlines the contents of the SDMP.

 

SOFTWARE DEVELOPMENT/MANAGEMENT PLAN

In some sections of the plan, material (shown in italics) is to be regularly added during the life of the project. Other sections should be revised and reissued if circumstances require significant changes in approach.

1.      INTRODUCTION

1.1          Purpose — brief statement of the project’s purpose.

1.2          Background — brief description that shows where the software products produced by the project fit into the overall system.

1.3          Organization and Responsibilities

1.3.1   Project Personnel — explanation and diagram of how the development team will organize activities and personnel to carry out the project: types and numbers of personnel assigned, reporting relationships, and team members’ authorities and responsibilities (see Reference 12 for guidelines on team composition).

1.3.2   Interfacing Groups — list of interfacing groups, points of contact, and group responsibilities.

2.      STATEMENT OF PROBLEM — brief elaboration of the key requirements, the steps numbered) to be taken to accomplish the project, and the relation (if any) to other projects.

3.      TECHNICAL APPROACH

3.1               Reuse Strategy — high-level description of the current plan for reusing software from existing systems.

3.2               Assumptions and Constraints — that govern the manner in which the work will be performed.

3.3               Anticipated and Unresolved Problems — that may affect the work and the expected effect on each phase.

3.4               Development Environment — development computer and programming languages.

3.5               Activities, Tools, and Products — for each phase, a matrix showing (a) the major activities to be performed, (b) the development methodologies and tools to be applied, and (c) the products of the phase. Includes discussion of any unique approaches or activities.

3.6               Build Strategy — which portions of the system will be implemented in which builds and the rationale for this. Determined during the preliminary design phase. Updated at the end of detailed design and after each build.

4.        MANAGEMENT APPROACH

4.1          Assumptions and Constraints — that affect the management approach, including project priorities.

4.2          Resource Requirements — tabular lists of estimated levels of resources required, including estimates of system size (new and reused SLOC), staff effort (managerial, programmer, and support) by phase, training requirements, and computer resources. Includes estimation methods or rationale used. Updated estimates are added at the end of each phase.

4.3          Milestones and Schedules — list of work to be done, who will do it, and when it will be completed. Includes development life cycle (phase start and finish dates); build/release dates; delivery dates of required external interfaces; schedule for integration of externally developed software and hardware; list of data, information, documents, software, hardware, and support to be supplied by external sources and delivery dates; list of data, information, documents, software, and support to be delivered to the customer and delivery dates; and schedule for reviews (internal and external).  Updated schedules are added at the end of each phase.

4.4          Measures — a table showing, by phase, which measures will be collected to capture project data for historical analysis and which will be used by management to monitor progress and product quality (see Reference 12). If standard measures will be collected, references to the relevant standards and procedures will suffice. Describes any measures or data collection methods unique to the project.

4.5          Risk Management — statements of each technical and managerial risk or concern and how it is to be mitigated. Updated at the end of each phase to incorporate any new concerns.

5.       PRODUCT ASSURANCE

5.1          Assumptions and Constraints — that affect the type and degree of quality control and configuration management to be used.

5.2          Quality Assurance — table of the methods and standards that will be used to ensure the quality of the development process and products (by phase). Where these do not deviate from published methods and standards, the table should reference the appropriate documentation.  Methods of ensuring or promoting quality that are innovative or unique to the project are described explicitly. Identifies the person(s) responsible for quality assurance on the project, and defines his/her functions and products by phase.

5.3          Configuration Management — table showing products controlled, as well as tools and procedures used to ensure the integrity of the system configuration   (when is the system under control, how are changes requested, who makes the changes, etc.). Unique procedures are discussed in detail. If standard configuration management practices are to be applied, references to the appropriate documents are sufficient. Identifies the person responsible for configuration management and describes this role. Updated before the beginning of each new phase with detailed configuration management procedures for the phase, including naming conventions, directory designations, reuse libraries, etc.

6.       APPENDIX:  PROTOTYPING PLANS — collected plans for each prototyping effort to be conducted on the project.

7.       PLAN UPDATE HISTORY — lead sheets from each update of the SDMP, indicating which sections were updated and when the update was made.

Figure 4-5. SDMP Contents

 

업데이트 된 요구사항 및 명세

Updated Requirements and Specifications

 

이 단계에서, 요구사항 정의 팀 승인 사양 변경에 기초하여 요구 사양 문서에 업데이트를 준비한다. 추가 사양 변경은 SSR 또는 RID 프로세스에서 논의의 결과로 승인될 수 있다. 그들은 소프트웨어 디자인을 생성하는 대로 개발자가 사용할 수 있도록 요구사항 정의의 팀은 업데이트 된 요구사항 및 사양 문서가 곧 SSR 후 게시되어 있는지 확인해야 한다.

 

During this phase, the requirements definition team prepares updates to the requirements and specifications document on the basis of approved specification modifications. Additional specification modifications may be approved as a result of discussion at the SSR or the RID process. The requirements definition team must ensure that the updated requirements and specifications document is republished shortly after the SSR, so that it will be available to the developers as they generate the software design.

 

 

프로토타이핑 계획

Prototyping Plans

 

프로토타이핑 노력을 관리하는 특별한 경계가 필요하다. 진행을 예측하고 측정하는 것이 어렵다. 기준이 프로토타이핑을 평가하고 완료를 판단하기 위한 설정되지 않은 경우 프로토타이핑의 노력은 무한정 계속될 수 있다. 각 프로토타이핑의 활동에 대한 계획을 작성하는 것은, 아무리 간단해도 제어를 구축하는 데에 매우 중요하다.

 

Managing a prototype effort requires special vigilance. Progress is often difficult to predict and measure. A prototyping effort may continue indefinitely if no criteria are established for evaluating the prototype and judging completion. Writing a plan for each prototyping activity, no matter how brief, is vital to establishing control.

 

계획의 길이 및 준비 시간은 프로토타이핑 노력의 크기 및 범위에 비례한다. 한 페이지의 계획은 작은 프로토타이핑 노력에 필요한 모든 것을 할 수 있다. 간단한 계획은 별도로 게시 할 수 있지만, 대신 SDMP (그림 4-5)에 통합할 필요는 없다.

 

The length of the plan and the time to prepare it should be proportional to the size and scope of the prototyping effort. A one- page plan may be all that is required for small prototyping efforts. A brief plan need not be published separately but may, instead, be incorporated into the SDMP (Figure 4-5).

 

다음 항목은 계획에 포함되어야 한다:

  • 프로토타이핑의목표-목적과 사용
  • 행해질일과생성되는 제품의정책
  • 완료기준
  • 평가방법– 누가 프로토타이핑을평가하고 어떻게 그것을 평가할것인가
  • 기술방식
  • 필요한자원 -노력과크기추정, 가능직원의통역서비스,하드웨어, 소프트웨어등
  • 일정

 

The following items should be included in the plan:

  • Objective of the prototype — its purpose and use
  • Statement of the work to be done and the products to be generated
  • Completion criteria
  • Assessment methods — who will evaluate the prototype and how it will be evaluated
  • Technical approach
  • Resources required — effort and size estimates, staff, hardware, software,
  • Schedule

 

SDMP는 자세한 프로토타이핑 계획의 요약을 포함해야 한다. 각각의 요약은, 일반적인 방법을 설명하는 프로토타이핑 할 항목을 논의하고, 노력의 추정을 포함하며, 일정을 제공하고, 일정에 대한 이론적 근거를 설명해야 한다.

 

The SDMP should contain summaries of the detailed prototyping plans. Each summary should describe the general approach, discuss the items to be prototyped, include effort estimates, provide a schedule, and discuss the rationale for the schedule.

 

소프트웨어 사양 검토

SOFTWARE SPECIFICATION REVIEW

 

요구사항 분석의 결론에서, 개발 팀은 SSR을 보유하고 있다. 이 프로젝트 관리 및 시스템의 최종 사용자에 대해 실시하는 고수준의 리뷰이다. SSR 형식, 일정, 참가자는 그림 4-6에서 세분화 된다.

 

At the conclusion of requirements analysis, the development team holds an SSR. This is a high-level review conducted for project management and the end users of the system. The SSR format, schedule, and participants are itemized in Figure 4-6.

 

SSR FORMAT

Presenters — software development team

Participants

•       Requirements definition team

•       Customer interfaces for both the requirements definition and software development teams

•       User representatives

•       Representatives of interfacing systems

•       Quality assurance representatives for both teams

•       System capacity/performance analysts

•       CCB

Schedule — after requirements analysis is complete and before the preliminary design phase is begun

Agenda — selective presentation of the results of requirements analysis, directed primarily toward project management and the users of the system

Materials Distribution

•       The requirements analysis report and software development/ management plan are distributed 1 to 2 weeks before SSR.

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

Figure 4-6.  SSR Format

 

SSR 하드카피 자료

SSR Hardcopy Material

 

검토를 위해 하드 카피 자료는 요구사항 분석 보고서에 있는 동일한 정보의 일부가 포함된다. 프레젠테이션에 포함 할 가장 적절한 정보를 선택하는 유연성이 있음을 유의하십시오. 그림 4-7에서 제안된 내용은 가이드라인으로 구성되어있다.

The hardcopy materials for the review will contain some of the same information found in the requirements analysis report. Keep in mind that there is some flexibility in selecting the most appropriate information to include in the presentation. The contents suggested in Figure 4-7 are intended as a guideline.

 

HARDCOPY  MATERIAL  FOR  THE  SSR

1.      Agenda — outline of review material

2.      Introduction — background of the project and purpose of system

3.      Analysis overview — analysis approach, degree of innovation required in analysis, special studies, and results

4.      Revisions since SRR — changes to system and operations concepts, requirements, and specifications effected following the SRR

5.      Reusable software summary

a.   Key reuse candidates — identification of existing software components that satisfy specific system specifications exactly or that will satisfy the specifications after modification

b.   Overall architectural concept for the system

c.   Matrix of requirements to be fulfilled by reused components

6.      Requirements classification summary

a.   List of requirements and specifications with their assigned classifications (mandatory, requires review, needs clarification, information only, or TBD)

b.   Problematic specifications — identification and discussion of conflicting, ambiguous, infeasible, and untestable requirements and specifications

c.   Unresolved requirements/operations issues, including the dates by which resolutions to TBDs are needed (NOTE:  This is a key element of the SSR.)

7.      Functional or object-oriented specifications

a.   Object diagrams or high-level data flow diagrams showing input, transforming processes, and output

b.   Data set definitions for external interfaces to the system

8.      Performance model — key estimates and results of modeling system performance

9.      Development  considerations

a.   System constraints — hardware availability, operating system limitations, and support software limitations

b.   Utility, support, and test programs — Iist of auxiliary software required to support development (e.g., data simulators, special test programs, software tools, etc.)

c.   Testing  requirements

d.   Development  assumptions

10.       Risks, both to costs and schedules — includes how risks are identified, their potential impact, and how they will be managed. Covers risks related to TBD or changing requirements as well as technical risks

11.       Summary of planned prototyping efforts needed to resolve technical risks, including the goals and schedule for each effort and a summary of any prototyping conducted to date

12.       Key contacts — leaders of technical teams, application specialists, and other key project members

13.       Milestones and schedules — includes size estimates, development life cycle (phase start and finish dates), schedule for reviews (internal and external), build/release requirements, delivery dates of required external interfaces, schedule for integration of externally developed software and hardware

Figure 4-7.  SSR Hardcopy Material

 

IEEE 830-1998 Recommended Practice for Software Requirement Specification

좋은 요구사항의 특성

요구사항.. 어떻게 작성해야 좋을까?

SECTION 4. 요구사항 분석 단계

작성된 요구사항 명세서가 적절한 요구사항인지를 확인하는 방법?