Category Archives: Stateflow Modeling

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

 

 

Advertisements

Tips of Requirements and design using statecharts formalism(Statecharts formalism를 이용한 요구사항 및 설계 작성 tip)


korean version is below. 한국어버전은 아래로

This was introduced at the DO-178C certification consulting meeting, and I hope that this will probably be helpful to others. In DO-178C, there is no clear separation criterion for the requirements and design description steps. Also, the human brain does not think separately of requirements and design explanations. Quite capable programmers often think about the logic of the code while writing requirements. I consider the possibility of verifying the test environment, test method, test case, etc. of this requirement while reviewing the requirements.

My client decided to express the requirements as statecharts in the project for DO-178C certification. The diagram that the customer expressed has various problems in my judgment. Although it was one of the main research fields at the graduate school, it described the specification method even though it was a long time.

Statecharts is a visual formalism devised by David Harel as an extended version of the FSM (Finite state machine). Statecharts has since been incorporated into UML, and has been transformed from Simulink in Mathworks into the notation Stateflow.

(For another moment, statecharts has a non-determinism attribute, a troublesome issue in AI, so to develop a fatalistic system, Mathworks invented a deterministic version of statecharts, Stateflow.)

(Of course, the diagram you are trying to express is meant to be deterministic.)

Components of Statecharts

Statecharts = {S, s0, I, O, T}.

S = set of states
S0 = initial state
I = set of input variables
O = set of output variables
T = S x Cond1 x Cond2 x S The set of state transitions,
Where Cond1 = state transition condition, Cond2 = state transition behavior
Although the mathematical definition of transition is a bit old, it is not perfect, but let’s skip this once.

With all the elements defined above, the above Statecharts can be implemented, executable, and can generate test cases.

For example, suppose you have the following Statecharts

S = {s0, S1, s2}
I = {i1, i2}
O = {o1, o2}
T = {t1, t2}
T1: = {s0, ‘i1 = 1’, ‘o1 = 1’, s1}

T2: = {s1, ‘i2 = 0’, ‘o1 = 0, o2 = 1’, s2}

For developers, this can be done directly in code. In the past, when I participated in the model review and refactoring of projects that automatically generated auto code in stateflow (remember that time). With a few frameworks, it is possible to generate code mechanically without using expensive tools . The following code can be different from the behavior of the actual statecharts when run instead of applying the framework. I just want to understand it as a concept.

State = s0;
While (1)
{
Switch (State)
S0:
If (i1 == 1) {o1 = 1; State = s1; Break;}
Break;
S1:

For tester making test procedure, you can make test procedure by making the following table.

Test prefix for state reachability

S0: null
S1: null. “I1 = 1”
S2: null. “I1 = 1”. “I2 = 0”
The meaning of the above notation means that it is necessary to keep it in the initial state to reach s0. In order to reach s1, 1 is inputted to i1 in the initial state. In case of s2, i1 = 1 is inputted in the initial state And then enter 0 in i2.

I think the test procedure for the transition in each state is understandable enough without saying a word.

So, let’s take the eternal questions of DO-178C beginners.

Drawing with Statecharts, I think I draw requirements and designs together, how do I separate them?

I do not know if it needs to be separated, but if you split it off and decide that you need to write some in the Software Requirement Data (SRD) and some in the DD (Design Description), you can hierarchically represent the statecharts, Slice. It is a purely personal judgment to which level to slice, and I do not think DER will blame it for being wrong.

Note that even if you do not express requirements and designs with statecharts, you can still use vertical logical slicing to represent your requirements in a hierarchical way, even if they are expressed in natural language. Therefore, the upper level can be classified into HLR (high level requirement) and the lower level can be divided into LLR (low level requirement).

If I explained this, I think I got enough sense. I hope to use it in practice now.

What if you still do not know? You need to get consulting services, so please contact me. In the meantime, there have been a lot of examples that have impressed customers with the high-quality expression of experts, so if you have difficulty in expressing it, you may be assisted by a consultant, like me.

DO-178C 인증 컨설팅 회의때 있었던 일인데, 다른 사람들에게 도움이 될 듯 하여 소개를 해볼까 한다. DO-178C에서 요구사항과 설계 설명 단계는 칼로 무 자르듯이 명쾌한 분리기준이 존재하지 않는다. 또한 인간의 뇌는 요구사항과 설계 설명 단계를 별도로 분리하여 생각하지 않는다. 꽤 유능한 개발자들은 대부분 요구사항을 작성하면서 코드의 로직까지 생각한다. 나같은 경우는 요구사항을 검토하면서 이 요구사항의 시험 환경, 시험 방법, 시험 케이스 등의 검증 가능성을 생각하지만..

고객은 요구사항을 statecharts로 표현하기로 했다. 고객이 표현한 diagram은 내가 볼때 여러가지 문제가 있었다. 대학원 박사과정때 주 연구분야중의 하나였기 때문에 오래되긴 했지만, specification방법에 대해서 기술했다.

Statecharts는 David Harel에 의해 고안된 visual formalism으로서 FSM(Finite state machine)의 extended version이라고 볼 수 있다. Statecharts는 이후 UML에도 통합되었고, Mathworks의 Simulink에서 Stateflow라는 표기법으로 변형되기도 했다.

(잠깐 다른 이야기를 하자면, statecharts가 최근 AI에서 핫한 non-determinism 속성을 갖고 있기 때문이다. 그래서 운명론적인 시스템을 개발하기 위해 Mathworks에서는 deterministic version의 statecharts를 창안하게 된 것이고, 그래서 탄생하게 된 것이 Stateflow이다.)

(물론 고객이 표현하려는 diagram에서는 deterministic한 행동을 하도록 표현되어 있다.)

Statecharts의 구성요소

Statecharts = {S , s0, I, O, T} 로 정의된다.

  • S = 상태의 집합
  • S0 = 초기 상태
  • I = 입력 변수의 집합
  • O = 출력 변수의 집합
  • T = S x Cond1 x Cond2 x S 상태 천이의 집합,
    여기서 Cond1 = 상태 전이 조건, Cond2 = 상태 전이 행동

Transition에 대한 수학적 정의가 오래되어서 살짝 완벽하지 않은 감이 있기는 하지만, 일단 이 정도로 하고 넘어가겠음.

위에서 정의한 모든 요소를 갖추면 위 Statecharts는 구현 가능하며, executable하며, test case를 생성할 수 있다.

예를 들어 다음과 같은 Statecharts가 있다고 가정해보자

S = {s0, S1, s2}
I = {i1, i2}
O = {o1, o2}
T = {t1, t2}

t1: = {s0 , ‘i1=1’ , ‘o1=1’, s1}

t2:={s1, ‘i2=0’, ‘o1=0, o2=1’,s2}

개발자 입장에서는 이 것만 보고 코드로 바로 구현이 가능하다. 예전에 stateflow에서 자동으로 auto code를 생성하는 프로젝트의 모델 검토 및 리팩토링에 참여했을 당시 (그 때 쯤이었던 것으로 기억한다.) 약간의 framework만 있으면 비싼 툴을 사용하지 않고도 기계적으로 code 생성하는 것이 가능하다. 아래의 코드에는 그런 framework가 적용된 것이 아니라 실행시켜보면 실제 statecharts의 behavior와 다를 수 있다. 그저 concept정도로만 이해했으면 한다.

State = s0;
while(1)
{
switch(State)
s0:
if (i1==1) {o1=1; State = s1; break;}
break;
s1:

시험 절차를 만드는 tester입장에서는 다음의 table을 만들어서 test procedure를 만들 수 있다.

state reachability를 위한 test prefix

s0: null
s1: null.”i1=1″
s2: null.”i1=1″.”i2=0″

위 표기방식의 의미는 s0에 도달하기 위해서는 초기상태에서 가만히 있으면 된다는 의미고, s1에 도달하기 위해서는 초기상태에서 i1에 1을 입력하면 도달하게 되며, s2의 경우는 초기상태에서 i1=1을 입력하고 그 이후 i2에 0을 입력하면 도달한다.

각 상태에서의 transition에 대한 test procedure는 굳이 말하지 않아도 충분히 이해할 수 있을 것이라고 생각한다.

자, 그렇다면 DO-178C 초심자들의 영원한 질문사항을 받아보도록 하겠다.

Statecharts로 그리면 요구사항 및 설계를 같이 그리는 거 같은데, 어떻게 분리해야 하는가?

딱히 분리를 해야 할 필요가 있을지는 모르겠으나, 굳이 분리를 해서 일부는 SRD(Software Requirement Data)에 기술하고 일부는 DD(Design Description)에 기술해야겠다고 판단한다면, statecharts를 hierarchical하게 표현하고, 그것을 vertical하게 slice한다. 어느 level을 slice하는지는 순수하게 개인적인 판단이며, 그거 잘못했다고 DER이 비난하지는 않을 것이라고 생각한다.

참고로 굳이 statecharts로 요구사항 및 설계를 표현하지 않는다고 하더라도, natural language로 표현한다고 하더라도 철처한 logical thinking process를 적용해서 요구사항을 hierarchical하게 표현하여 마찬가지로 vertical slice를 할 수도 있다. 그래서 상위 level을 HLR(high level requirement), 하위 level을 LLR(Low level requirement)로 구분지을 수도 있다.

이정도 설명했으면 충분히 감을 잡았으리라 생각한다. 이제 실전에서 활용해보기 바란다.

아직도 잘 모르겠다면? 컨설팅 서비스를 받아야 할 필요가 있으므로, 나에게 연락하기 바람. 그동안 전문가의 고급스러운 표현으로 고객을 감동시킨 사례가 많이 있었으므로, 표현하는데 어려움이 있다면 컨설턴트의 도움을 받아도 좋음.

Statecharts – 소프트웨어 구조 설계 작업


요즘은 Harel의 Statecharts라는 말보다는 Mathworks의 Stateflow라는 용어를 많이 쓰기는 하지만, 시조는 Statecharts이다. 대학원때 첨보고 클 놈이라고 확신을 했었고 난 그쪽에 대한 업무를 하면서 열혈 신자가 되었으며, 결국 Harel이 Statecharts를 세상에 내놓은지 30여년만에 Statecharts는 세계를 정복했다.

최근에 소스코드를 분석하여 소프트웨어의 구조를 재구성하는 과제를 진행하고 있었다. 설계 개념을 제대로 도입하지 않은터라 설계 저자의 직강을 듣지 않고는 이해하기 어려운 것들이 많았고, 전역변수의 사용으로 인해 데이터의 흐름은 이미 어지러웠으며, 심오한 코딩 기법을 몇 개 적용함으로 인해, 그 코드는 깊이를 알 수 없는 심오한 대상이 되었다.

지금까지 설계 저자와 3차 미팅을 했다. Statecharts 신봉자인 나는 Staetcharts의 교리를 전파하고 열심히 포교활동을 한 끝에 그들을 Statecharts 교도가 되도록 하고 그런 사상으로 시스템을 바라보도록 하는데 성공했다.

2시간 정도의 짧은 순간이었지만, 지금까지 이해한 시스템을 바탕으로 하이브리드 시스템의 뼈대를 세우는 작업을 실시했다. 두 명의 도메인 전문가와 한명의 독실한Statecharts 교도가 합작하여 드디어 과거와는 다른 이상적이고 깔끔하고 심지어 아름답기까지 한 하이브리드 시스템을 설계했다.

이상하게 Arts에 대해서는 문외한이지만, Statecharts의 그림은 아름답게 보이고 예술적으로 보이는 것은 나만 그런 것은 아닐 것이라 생각한다. 모두들 나의 그림 실력에 만족감을 보이고, 그 그림을 보니 모든 하이브리드 시스템의 체계가 정리되었다고 뿌듯해했다.

아침에 갑자기 이 일이 생각났다. 도대체 내가 한 이 그림 그리기는 소프트웨어 개발의 어떤 단계에 해당하느냐고… 곰곰히 생각해보니 요구사항 분석 및 설계 활동이다. 일반적인 ISO26262나 DO-178C/278A, IEC 6508에서 흔히 이야기 하는 development life cycle하고는 차이가 있긴 하다. 하지만 조금 넓게 시야를 가지면 그게 그거긴 한데, 좁은 시야에서는 완전 다르다고 볼 수도 있다.

어쨌거나 what을 알고 있는 domain expert입장에서 how를 정리하는 것은 어려운 수수께끼를 드디어 해결한 것과 같은 쾌감을 선사했고, what을 모르지만 how로 단번에 문제의 본질을 정리한 것은 statecharts 교도 입장에서 역시 statecharts에 대한 믿음을 더욱 강화하게 한 계기가 되었다.

Statecharts로 시스템을 모델링하는 것은 그런 의미에서 What과 How가 mix된 형태의 표현 방식이라고 생각된다. 그 그림에는 문제의 본질과 그 문제를 해결하기 위한 방법이 둘 다 들어가 있다. 그 그림을 보면 어떻게 문제를 표현했는지가 기술되어 있고 그 그림은 아름답기 까지 하다. (모든 게 아름답진 않겠으나)

예술작품을 공개하고 싶은 마음이 굴뚝같으나, 비 공개할 수밖에 없는 것이 안타깝긴 하다. 역시 난 그림 그리는 일에 소질이 있는 것 같다.