문서요약 - 군사 소프트웨어 개발 표준 MIL-STD-498 by 미국방부

제목: 군사 소프트웨어 개발 표준 MIL-STD-498(Military Standard: Software Development and Documentation)

저자: 미국방부(DoD)

문서유형: 개발 표준(총 76페이지), 1994년

 

미국방부의 군사 소프트웨어 개발 표준인 MIL-STD-498에 기술된 요구사항을 간략히 정리

---

MIL-STD-498

• 무기 시스템 및 자동화된 정보 시스템 개발에 적합한 일련의 활동과 문서화를 정의한 표준
• 기존 표준인 DOD-STD-2167A와 DOD-STD-7935A를 통합 반영한 표준
• 본 표준에서 용어 “소프트웨어 개발”은 신규 개발, 변경, 재사용, 리엔지니어링, 유지보수, 소프트웨어 제품이 결과물이 되는 기타 모든 활동을 포함하는 포괄적인 의미로 사용됨

주요 용어 정리

• 계약 데이터 요구사항 목록(Contract Data Requirements List, CDRL): 고객에게 인도하기로 한 소프트웨어 제품의 목록(산출물 포함)
• 컴퓨터 소프트웨어 형상 항목(Computer Software Configuration Item, CSCI): 하나의 특정한 최종 사용자 기능을 충족시키는 소프트웨어의 묶음(집합). 형상 관리에서 개별로 관리되는 단위
• 인수(Acceptance): 구매자(the acquirer)의 권한을 가진 대표자가 계약의 부분 완성 또는 전체 완성에 따라 소프트웨어 제품의 소유권을 받아들이는 행위
• 승인(Approval): 개발자의 계획, 설계, 기타 프로젝트 측면이 견고하며 앞으로 수행할 작업의 기반으로 사용 가능하다고 구매자의 권한을 가진 대표자가 문서화된 통지(공지)를 하는 행위
• 관련 개발자(Associate developer): 주사업자(prime contractor)도 아니고 하청업자(subcontractor)도 아니지만 해당 프로젝트 또는 관련 프로젝트에 개발 역할을 하고 있는 사람 또는 조직
• 합동 검토(Joint review): 구매자와 개발자 양쪽 모두의 대표자가 관여한 프로세스 또는 회의로 프로젝트 상태, 소프트웨어 제품, 프로젝트 이슈 등을 검토하고 의견을 나눈다.
• 적격성 증명 테스팅(Qualification testing): 특정 CSCI 또는 전체 시스템이 명세된 요구사항을 충족한다는 것을 구매자에게 증명하기 위해 수행되는 테스팅

4장 일반 요구사항(GENERAL REQUIREMENTS)

4.1 소프트웨어 개발 프로세스(Software development process)

개발자는 계약 요구사항에 부합되도록 소프트웨어 개발 프로세스를 확립한다(5장 참고).

4.2 소프트웨어 개발의 일반 요구사항(General requirements for software development)

개발자는 5장의 상세 요구사항을 수행하는데 있어 다음과 같은 일반 요구사항을 만족시킨다.

4.2.1 소프트웨어 개발 방법(Software development methods)

개발자는 모든 소프트웨어 개발 활동에 체계적이고 문서화된 방법을 적용하며, 이 방법은 소프트웨어 개발 계획서에 기술되거나 참조된다.

4.2.2 소프트웨어 제품의 표준(Standards for software products)

개발자는 요구사항, 설계, 코드, 테스트 케이스, 테스트 절차, 테스트 결과를 나타내기 위한 표준을 개발 및 적용해야 하며, 이 표준은 소프트웨어 개발 계획서에 기술되거나 참조된다.

4.2.3 재사용 가능한 소프트웨어 제품(Reusable software products)

개발자는 아래의 요구사항을 충족해야 한다.

4.2.3.1 재사용 가능한 소프트웨어 제품 포함(Incorporating reusable software products)

개발자는 계약 요구사항을 충족하는데 사용 할 수 있는 재사용 가능한 소프트웨어 제품을 식별 및 평가하고, 실용적인 것으로 평가된 제품을 사용한다.

4.2.3.2 재사용 가능한 소프트웨어 제품 개발(Developing reusable software products)

계약 과정에서 개발자는 재사용을 위한 소프트웨어 제품을 개발할 수 있는 기회를 식별하고, 이러한 기회의 장점과 비용을 평가한다. 비용 효과적이고 프로그램의 목표에도 부합하는 기회가 있으면 구매자에게 알린다.

4.2.4 핵심 요구사항 처리(Handling of critical requirements)

개발자는 아래의 요구사항을 충족해야 한다.

4.2.4.1 안전성 보장(Safety assurance)

개발자는 오작동/고장의 경우 위험(예, 인명 피해, 상해, 자산 피해, 환경 문제)을 초래할 수 있는 고안전 컴퓨터 소프트웨어 형상 항목(safety-critical CSCIs)을 식별하고, 잠재 위험을 최소화 내지는 제거하기 위한 테스트와 분석을 포함하는 안전성 보장 전략(a safety assurance strategy)을 개발한다.

4.2.4.2 보안성 보장(Security assurance)

개발자는 오작동/고장의 경우 시스템 보안에 틈이 생기는 고보안 컴퓨터 소프트웨어 형상 항목(security-critical CSCIs)을 식별하고, 잠재적인 시스템 보안 위협을 최소화 내지는 제거할 수 있는 보안성 보장 전략(a security assurance strategy)을 개발하고 실현한다.

4.2.4.3 프라이버시 보장(Privacy assurance)

개발자는 오작동/고장의 경우 시스템 프라이버시 침해를 초래할 수 있는 컴퓨터 소프트웨어 형상 항목(privacy-critical CSCIs)을 식별하고, 식별된 위협을 최소화 내지는 제거하기 위한 프라이버시 보장 전략(a privacy assurance strategy)을 개발하고 실현한다.

4.2.4.4 기타 핵심 요구사항 보장(Assurance of other critical requirements)

계약서나 시스템 명세서에서 중요하게 여기는 다른 요구사항에 대해서도 개발자는 오작동/고장 시 해당 요구사항을 침해할 수 있는 CSCI를 식별하고, 이런 잠재 위험을 최소화하거나 제거하기 위한 보장 전략을 개발하고 실현한다.

4.2.5 컴퓨터 하드웨어 자원 활용(Computer hardware resource utilization)

개발자는 컴퓨터 하드웨어 자원 활용과 관련하여 계약 요구사항을 분석하고(예, 프로세서, 메모리, IO 디바이스, 보조기억장치, 통신장비의 최대 사용량), 컴퓨터 하드웨어 자원을 CSCI에 적절히 배분한다. 계약 기간 동안 하드웨어 자원 활용을 모니터하고 계약 요구사항을 충족하기 위해 자원 재분배 또는 추가가 필요한지 식별한다.

4.2.6 근거 정보 기록(Recording rationale)

개발자는 소프트웨어를 명세, 설계, 구현, 테스팅 하는데 있어 발생되는 주요 의사 결정의 근거 정보(예, 장단점을 가진 여러 옵션, 분석 방법, 의사 결정 기준)를 기록한다.

4.2.7 구매자의 검토 허용(Access for acquirer review)

개발자는 구매자(the acquirer) 또는 구매자의 권한을 가진 대표자가 개발자와 하청업자의 시설(소프트웨어 엔지니어링 환경과 테스트 환경)에 접근하여 계약에 요구된 소프트웨어 제품과 활동을 검토할 수 있도록 한다.

5장 상세 요구사항(DETAILED REQUIREMENTS)

5.1 프로젝트 계획과 감독(Project planning and oversight)

개발자는 아래 요구사항에 부합하도록 프로젝트 계획과 감독을 수행한다.

5.1.1 소프트웨어 개발 계획(Software development planning)

개발자는 본 표준이 요구하는 활동과 계약에 명시된 소프트웨어 요구사항의 활동을 수행하기 위한 계획을 개발하고 기록한다.

5.1.2 CSCI 테스트 계획(CSCI test planning)

개발자는 컴퓨터 소프트웨어 형상 항목의 적격성 증명 테스팅(CSCI qualification testing)을 수행하기 위한 계획을 개발하고 기록한다.

5.1.3 시스템 테스트 계획(System test planning)

개발자는 시스템 적격성 증명 테스팅(system qualification testing) 수행을 위한 계획을 개발하고 기록하는데 참여한다.

5.1.4 소프트웨어 설치 계획(Software installation planning)

개발자는 소프트웨어 설치 및 계약에 명시된 사용자 사이트 교육/훈련을 수행하기 위한 계획을 개발하고 기록한다.

5.1.5 소프트웨어 이전 계획(Software transition planning)

개발자는 지원 조직(the support agency)이 계약에 명시된 지원 개념을 충족시키는데 필요한 모든 소프트웨어 개발 자원을 식별한다. 개발자는 이러한 자원을 식별하기 위한 계획 및 지원 조직에 인도 항목(deliverable items) 이전을 위한 계획을 개발하고 기록한다.

5.1.6 계획 준수 및 업데이트(Following and updating plans)

수립된 모든 계획에 대해 구매자 승인을 얻은 후 개발 조직의 관리자는 소프트웨어 개발 프로세스를 주기적으로 검토하여 계약서 및 소프트웨어 개발 계획서에 부합하는지 확인한다. 계획서의 업데이트는 구매자의 승인을 받아야 한다.

5.2 소프트웨어 개발 환경 확립(Establishing a software development environment)

개발자는 아래 요구사항에 부합하도록 소프트웨어 개발 환경을 확립한다.

5.2.1 소프트웨어 엔지니어링 환경(Software engineering environment)

개발자는 소프트웨어 엔지니어링 작업을 수행하기 위한 환경을 확립하고, 통제하고, 유지한다.

5.2.2 소프트웨어 테스트 환경(Software test environment)

개발자는 소프트웨어의 적격성 증명 테스팅과 기타 다른 테스팅을 수행하기 위한 소프트웨어 테스트 환경을 확립하고, 통제하고, 유지한다.

5.2.3 소프트웨어 개발 라이브러리(Software development library)

개발자는 소프트웨어의 질서정연한 개발과 후속 지원을 용이하게 해주는 소프트웨어 개발 라이브러리(a software development library, SDL)를 확립하고, 통제하고, 유지한다. SDL은 소프트웨어 엔지니어링 환경과 소프트웨어 테스트 환경의 한 부분으로 통합되기도 한다.

5.2.4 소프트웨어 개발 파일(Software development files)

개발자는 소프트웨어 단위, 논리적으로 연관된 소프트웨어 단위 그룹, 컴퓨터 소프트웨어 형상 항목(CSCI), 논리적으로 연관된 CSCI 그룹, 서브 시스템, 전체 시스템 등의 각각에 대한 소프트웨어 개발 파일(a software development file, SDF)을 확립하고, 통제하고, 유지한다. 개발자는 소프트웨어 개발에 대한 정보를 상응하는 SDF에 기록하고 계약 기간 동안 SDF를 유지한다.

5.2.5 비인도 소프트웨어(Non-deliverable software)

개발자는 고객 인도 소프트웨어(deliverable software)의 개발에 비인도 소프트웨어(non-deliverable software)를 사용할 수 있다. 다만 구매자에게 인도된 소프트웨어의 운영과 지원이 비인도 소프트웨어에 의존하지 않거나 또는 구매자도 이런 비인도 소프트웨어를 쉽게 획득할 수 있어야 한다.

5.3 시스템 요구사항 분석(System requirements analysis)

개발자는 아래 요구사항에 부합하도록 시스템 요구사항 분석에 참여한다.

5.3.1 사용자 입력 분석(Analysis of user input)

개발자는 사용자 요구(user needs)에 대한 이해를 얻기 위해 구매자가 제공한 사용자 입력을 분석하는데 참여한다. 사용자 입력은 요구 진술서(need statements), 조사서, 문제/변경 보고서, 프로토타입에 대한 피드백, 인터뷰 형태이거나 또는 기타 다른 사용자 입력/피드백 형태가 될 수 있다.

5.3.2 운영 개념(Operational concept)

개발자는 시스템의 운영 개념을 정의하고 기록하는데 참여한다.

5.3.3 시스템 요구사항(System requirements)

개발자는 시스템이 충족시켜야 할 요구사항 정의 및 각각의 요구사항이 충족되었는지 보장하는 방법을 정의하고 기록하는데 참여한다.

5.4 시스템 설계(System design)

개발자는 아래 요구사항에 부합하도록 시스템 설계에 참여한다.

5.4.1 전체 시스템 설계 의사결정(System-wide design decisions)

개발자는 전체 시스템 레벨 설계 의사결정(즉, 시스템의 동작 설계에 대한 의사결정과 시스템 컴포넌트 선택 및 설계에 영향을 주는 기타 다른 의사결정)의 수행 및 기록에 참여한다.

5.4.2 시스템 아키텍쳐 설계(System architectural design)

개발자는 시스템의 아키텍쳐 설계(시스템 컴포넌트, 컴포넌트 인터페이스, 컴포넌트 실행 개념을 식별)를 정의하고 기록하는데 참여한다. 또한 시스템 컴포넌트와 시스템 요구사항간의 추적성(traceability)을 정의하고 기록하는데 참여한다.

5.5 소프트웨어 요구사항 분석(Software requirements analysis)

개발자는 각 CSCI가 충족시켜야 할 소프트웨어 요구사항, 각 요구사항이 충족되었는지 확인하는 방법, CSCI 요구사항과 시스템 요구사항 간의 추적성을 정의하고 기록한다.

5.6 소프트웨어 설계(Software design)

개발자는 아래 요구사항에 부합하도록 소프트웨어 설계를 수행한다.

5.6.1 컴퓨터 소프트웨어 형상 항목 레벨의 설계 의사결정(CSCI-wide design decisions)

개발자는 CSCI 레벨 설계 의사결정(즉, CSCI의 동작 설계에 대한 의사결정과 CSCI를 구성하는 소프트웨어 단위의 선택 및 설계에 영향을 주는 기타 다른 의사 결정)을 정의하고 기록한다.

5.6.2 컴퓨터 소프트웨어 형상 항목 아키텍쳐 설계(CSCI architectural design)

개발자는 각 CSCI의 아키텍쳐 설계(CSCI를 구성하는 소프트웨어 단위, 해당 소프트웨어 단위의 인터페이스, 해당 소프트웨어 단위의 실행 개념을 식별)를 정의하고 기록한다. 또한 이 소프트웨어 단위와 CSCI 요구사항 간의 추적성을 정의하고 기록한다.

5.6.3 컴퓨터 소프트웨어 형상 항목 상세 설계(CSCI detailed design)

개발자는 각 소프트웨어 단위에 대한 기술서(a description of each software unit)를 개발하고 기록한다.

5.7 소프트웨어 구현과 단위 테스팅(Software implementation and unit testing)

개발자는 아래 요구사항에 부합하도록 소프트웨어 구현(소프트웨어 설계를 컴퓨터 프로그램과 컴퓨터 데이터베이스로 전환하는 작업)과 단위 테스팅을 수행한다

5.7.1 소프트웨어 구현(Software implementation)

개발자는 CSCI 설계의 각 소프트웨어 단위에 상응하는 소프트웨어를 개발하고 기록한다. 이 활동에는 컴퓨터 구문 코딩, 데이터 정의, 데이터베이스 구축, 실제 데이터 값들을 데이터베이스와 데이터 파일에 채워 넣는 작업, 기타 설계를 실현하는데 필요한 활동들이 포함된다.

5.7.2 단위 테스팅 준비(Preparing for unit testing)

개발자는 각 소프트웨어 단위에 상응하는 소프트웨어를 테스트 하기 위한 테스트 케이스(입력, 예상 결과, 평가 기준), 테스트 절차, 테스트 데이터를 확립하고, 이 정보를 해당 소프트웨어 개발 파일(SDF)에 기록한다. 테스트 케이스는 해당 소프트웨어 단위의 상세 설계의 모든 측면을 커버해야 한다.

5.7.3 단위 테스팅 수행(Performing unit testing)

개발자는 각 소프트웨어 단위에 상응하는 소프트웨어를 단위 테스트 케이스와 절차에 따라 테스트한다.

5.7.4 교정과 재테스팅(Revision and retesting)

개발자는 단위 테스팅 결과에 따라 소프트웨어 필요한 수정을 가하고, 재테스트를 수행하고, SDF와 다른 관련 소프트웨어 제품을 업데이트 한다.

5.7.5 단위 테스트 결과 분석 및 기록(Analyzing and recording unit test results)

개발자는 단위 테스팅 결과를 분석하고, 해당 SDF에 수행된 테스트와 분석 결과를 기록한다.

5.8 단위 통합 및 테스팅(Unit integration and testing)

개발자는 아래 요구사항에 따라 단위 통합 및 테스팅을 수행한다. 단위 통합 및 테스팅은 두 개의 또는 그 이상의 소프트웨어 단위를 통합하고 이 통합된 소프트웨어가 함께 의도한대로 동작하는지를 테스팅 하는 것을 의미한다. 각 CSCI의 모든 소프트웨어가 통합되고 테스트 될 때까지 이 프로세스가 계속되며, 최종 단계로 개발자-내부 CSCI 테스팅(developer-internal CSCI testing)이 수행된다.

5.8.1 단위 통합 및 테스팅 준비(Preparing for unit integration and testing)

개발자는 단위 통합 및 테스팅을 수행하기 위한 테스트 케이스(입력, 예상 결과, 평가 기준), 테스트 절차, 테스트 데이터를 확립하고, 이 정보를 적절한 SDF에 기록한다. 테스트 케이스는 CSCI 전체 아키텍쳐 설계의 모든 측면을 커버해야 한다.

5.8.2 단위 통합 및 테스팅 수행(Performing unit integration and testing)

개발자는 단위 통합 테스트 케이스와 절차에 따라 단위 통합 및 테스팅을 수행한다.

5.8.3 교정과 재테스팅(Revision and retesting)

개발자는 단위 통합 및 테스팅 결과에 따라 필요한 모든 소프트웨어 수정을 가하고, 재테스팅을 수행하고, SDF와 다른 관련 소프트웨어 제품을 업데이트 한다.

5.8.4 단위 통합 및 테스팅 결과 분석과 기록(Analyzing and recording unit integration and test results)

개발자는 단위 통합 및 테스팅 결과를 분석하고, 적절한 SDF에 수행된 테스트와 분석 결과를 기록한다.

5.9 컴퓨터 소프트웨어 형상 항목 적격성 증명 테스팅(CSCI qualification testing)

개발자는 아래 요구사항에 부합하도록 CSCI 적격성 증명 테스팅(CSCI qualification testing)을 수행한다. CSCI 적격성 증명 테스팅은 CSCI 요구사항이 충족되었음을 구매자(the acquirer)에게 증명하기 위해 수행되는 테스팅으로 단위 통합 및 테스팅의 최종 단계에 수행되는 개발자-내부 CSCI 테스팅(developer-internal CSCI testing)과는 다르다.

5.9.1 CSCI 적격성 증명 테스팅의 독립성(Independence in CSCI qualification testing)

특정 CSCI의 적격성 증명 테스팅을 책임지는 사람은 해당 CSCI의 상세 설계나 구현을 수행한 사람과 동일하지 않다.

5.9.2 타겟 컴퓨터 시스템에서 테스팅(Testing on the target computer system)

CSCI 적격성 증명 테스팅은 타겟 컴퓨터 시스템(또는 구매자가 승인한 대체 시스템) 상에서의 테스팅을 포함한다.

5.9.3 CSCI 적격성 증명 테스팅 준비(Preparing for CSCI qualification testing)

개발자는 CSCI 적격성 증명 테스팅을 위한 테스트 사전 준비 사항, 테스트 케이스, 테스트 절차, 테스트 케이스와 CSCI 요구사항 간의 추적성을 정의하고 기록한다. 개발자는 테스트 케이스를 실행하는데 필요한 테스트 데이터를 준비하고 구매자(고객)에게 CSCI 적격성 증명 테스팅의 시간과 장소를 사전 공지한다.

5.9.4 CSCI 적격성 증명 테스팅 예행 연습(Dry run of CSCI qualification testing)

구매자가 CSCI 적격성 증명 테스팅에 참관하는 경우 개발자는 CSCI 테스트 케이스와 절차를 사전에 실행하여 이것들이 완전하고 정확하며 참관자가 있는 테스팅(witnessed testing)을 수행할 준비가 되었음을 확인한다. 개발자는 이 활동의 결과를 적절한 SDF에 기록하고 필요에 따라 CSCI 테스트 케이스와 절차를 업데이트 한다.

5.9.5 CSCI 적격성 증명 테스팅 수행(Performing CSCI qualification testing)

개발자는 CSCI 테스트 케이스와 절차에 따라 각 CSCI의 CSCI 적격성 증명 테스팅을 수행한다.

5.9.6 교정과 재테스팅(Revision and retesting)

개발자는 CSCI 적격성 증명 테스팅 결과에 따라 필요한 모든 소프트웨어 수정을 가하고, 재테스팅을 구매자에게 사전 공지하고, 재테스팅을 수행하고, SDF와 다른 소프트웨어 제품을 적절히 업데이트한다.

5.9.7 CSCI 적격성 증명 테스트 결과 분석 및 기록(Analyzing and recording CSCI qualification test results)

개발자는 CSCI 적격성 증명 테스팅의 결과를 분석하고 기록한다.

5.10 컴퓨터 소프트웨어 형상 항목/하드웨어 형상 항목의 통합 및 테스팅(CSCI/HWCI integration and testing)

개발자는 아래 요구사항에 부합하도록 CSCI/HWCI 통합 및 테스팅 활동에 참여한다. CSCI/HWCI 통합 및 테스팅은 CSCI를 인터페이스 되는 HWCI 및 CSCI와 통합하고 이 통합된 그룹이 함께 의도한대로 동작하는지를 테스트하는 것을 의미한다. 시스템의 모든 CSCI와 HWCI가 통합되고 테스트 될 때까지 이 프로세스는 계속되며, 최종 단계로 개발자-내부 시스템 테스팅(developer-internal system testing)이 수행된다.

5.10.1 CSCI/HWCI 통합 및 테스팅 준비(Preparing for CSCI/HWCI integration and testing)

개발자는 CSCI/HWCI 통합 및 테스팅을 수행하기 위한 테스트 케이스(입력, 예상 결과, 평가 기준), 테스트 절차, 테스트 데이터를 개발하고 기록하는데 참여한다. 테스트 케이스는 시스템 전반 아키텍쳐 설계의 모든 측면을 커버해야 한다. 개발자는 소프트웨어 관련 정보를 적절한 SDF에 기록한다.

5.10.2 CSCI/HWCI 통합 및 테스팅 수행(Performing CSCI/HWCI integration and testing)

개발자는 CSCI/HWCI 통합 테스트 케이스와 절차에 따른 CSCI/HWCI 통합 및 테스팅에 참여한다.

5.10.3 교정과 재테스팅(Revision and retesting)

개발자는 CSCI/HWCI 통합 및 테스팅 결과에 기반하여 필요한 모든 소프트웨어 수정을 가하고, 재테스팅에 참여하고, 관련 SDF와 다른 소프트웨어 제품을 업데이트한다.

5.10.4 CSCI/HWCI 통합 및 테스트 결과 분석과 기록(Analyzing and recording CSCI/HWCI integration and test results)

개발자는 CSCI/HWCI 통합 및 테스팅 결과를 분석하는데 참여하고, 소프트웨어에 관련된 분석 및 테스트 결과는 해당 SDF에 기록한다.

5.11 시스템 적격성 증명 테스팅(System qualification testing)

개발자는 아래 요구사항에 부합하도록 시스템 적격성 증명 테스팅(system qualification testing)에 참여한다. 시스템 적격성 증명 테스팅은 시스템 요구사항이 충족되었음을 구매자에게 증명하기 위해 수행되며, CSCI/HWCI 통합 및 테스팅의 최종 단계로 수행되는 개발자-내부 시스템 테스팅(developer-internal system testing)과는 다르다.

5.11.1 시스템 적격성 증명 테스팅의 독립성(Independence in system qualification testing)

시스템 적격성 증명 테스팅을 책임진 사람은 시스템의 소프트웨어 상세 설계나 구현을 수행한 사람과 동일하지 않다.

5.11.2 타겟 컴퓨터 시스템에서 테스팅(Testing on the target computer system)

개발자의 시스템 적격성 증명 테스팅은 타겟 컴퓨터 시스템 또는 구매자가 승인한 대체 시스템 상에서의 테스팅을 포함한다.

5.11.3 시스템 적격성 증명 테스팅 준비(Preparing for system qualification testing)

개발자는 시스템 적격성 증명 테스팅을 위한 테스트 사전 준비 사항, 테스트 케이스, 테스트 절차, 테스트 케이스와 시스템 요구사항 간의 추적성을 개발하고 기록하는데 참여한다. 개발자는 테스트 케이스 실행에 필요한 테스트 데이터 준비에 참여하고, 구매자에게 시스템 적격성 증명 테스팅의 시간과 장소를 사전 공지한다.

5.11.4 시스템 적격성 증명 테스팅 예행 연습(Dry run of system qualification testing)

구매자가 시스템 적격성 증명 테스팅에 참관하는 경우 개발자는 시스템 테스트 케이스와 절차를 사전에 실행하여 이것들이 완전하고 정확하며 참관자가 있는 테스팅을 수행할 준비가 되었음을 확인하는데 참여한다. 개발자는 이 활동의 소프트웨어 관련 결과를 적절한 SDF에 기록하고, 필요 시 시스템 테스트 케이스와 절차를 업데이트 하는데 참여한다.

5.11.5 시스템 적격성 증명 테스팅 수행(Performing system qualification testing)

개발자는 시스템 테스트 케이스와 절차에 따른 시스템 적격성 증명 테스팅에 참여한다.

5.11.6 교정과 재테스팅(Revision and retesting)

개발자는 시스템 적격성 증명 테스팅의 결과에 기반하여 필요한 모든 소프트웨어 수정을 가하고, 구매자에게 재테스팅을 사전 공지하고, 재테스팅에 참여하고, 필요에 따라 SDF와 다른 소프트웨어 제품을 업데이트한다.

5.11.7 시스템 적격성 증명 테스트 결과 분석과 기록(Analyzing and recording system qualification test results)

개발자는 시스템 적격성 증명 테스팅의 결과를 분석하고 기록하는데 참여한다.

5.12 소프트웨어 사용 준비(Preparing for software use)

개발자는 아래 요구사항에 부합하도록 소프트웨어 사용 준비를 한다.

5.12.1 실행 소프트웨어 준비(Preparing the executable software)

개발자는 각 사용자 사이트의 실행 소프트웨어(소프트웨어를 타겟 컴퓨터에 설치하고 운영하는데 필요한 모든 배치 파일, 커맨드 파일, 데이터 파일, 기타 소프트웨어 파일 포함)를 준비한다.

5.12.2 사용자 사이트의 버전 기술서 준비(Preparing version descriptions for user sites)

개발자는 각 사용자 사이트를 위한 정확한 소프트웨어 버전을 식별하고 기록한다.

5.12.3 사용자 매뉴얼 준비(Preparing user manuals)

개발자는 아래 요구사항에 부합하도록 사용자 매뉴얼을 준비한다(아래의 모든 매뉴얼을 필요로 하는 시스템은 드물며, 구매자가 개발자의 도움에 기반하여 자신들에게 필요한 매뉴얼 타입을 결정하도록 한다). 이 장에 기술된 매뉴얼들은 대개 소프트웨어 개발과 병행하여 개발되어 CSCI 테스팅에서 사용될 수 있도록 준비된다.

5.12.3.1 소프트웨어 사용자 매뉴얼(Software user manuals)

개발자는 소프트웨어의 실 사용자(소프트웨어를 작동시키고 그 결과를 사용하는 사람)에게 필요한 정보를 식별하고 기록한다.  

5.12.3.2 소프트웨어 입/출력 매뉴얼(Software input/output manuals)

개발자는 소프트웨어에 입력을 주고 출력을 받는 사람(소프트웨어를 작동하는 일은 컴퓨터 센터나 다른 소프트웨어 설치 장소의 작업자에게 의존)에게 필요한 정보를 식별하고 기록한다.

5.12.3.3 소프트웨어 센터 운영자 매뉴얼(Software center operator manuals)

개발자는 컴퓨터 센터나 중앙집중식/네트워크식 소프트웨어 설치 장소에서 소프트웨어를 작동하여 다른 이들이 사용할 수 있게 만들어 주는 사람에게 필요한 정보를 식별하고 기록한다.

5.12.3.4 컴퓨터 운영 매뉴얼(Computer operation manuals)

개발자는 소프트웨어가 탑재되어 실행될 컴퓨터를 운영하는데 필요한 정보를 식별하고 기록한다.

5.12.4 사용자 사이트에 설치(Installation at user sites)

개발자는 계약서에 명시된 대로 1) 사용자 사이트에 실행 소프트웨어를 설치 및 체크하고, 2) 사용자에게 교육/훈련을 제공하고, 3) 사용자 사이트에 기타 다른 지원을 제공한다.

5.13 소프트웨어 이전 준비(Preparing for software transition)

개발자는 아래 요구사항에 부합하도록 소프트웨어 이전을 위한 준비를 한다.

5.13.1 실행 소프트웨어 준비(Preparing the executable software)

개발자는 지원 사이트로 이전할 실행 소프트웨어(소프트웨어를 타겟 컴퓨터에 설치하고 운영하는데 필요한 모든 배치 파일, 커맨드 파일, 데이터 파일, 기타 소프트웨어 파일 포함)를 준비한다.

5.13.2 소스 파일 준비(Preparing source files)

개발자는 지원 사이트로 이전 할 소스 파일(실행 소프트웨어를 재생성하는데 필요한 모든 배치 파일, 커맨드 파일, 데이터 파일, 기타 소프트웨어 파일 포함)을 준비한다.

5.13.3 지원 사이트의 버전 기술서 준비(Preparing version descriptions for the support site)

개발자는 지원 사이트의 정확한 소프트웨어 버전을 식별하고 기록한다.

5.13.4 현 구축 빌드의 CSCI 설계 및 관련 정보 준비(Preparing the "as built" CSCI design and related information)

개발자는 각 CSCI의 설계 기술서를 현재 구축된 소프트웨어(the "as built" software)에 맞도록 업데이트 한다. 개발자는 소프트웨어 카피를 검증할 방법, CSCI의 컴퓨터 하드웨어 자원 사용 측정치, 소프트웨어를 지원하는데 필요한 기타 정보, CSCI 소스 파일과 소프트웨어 단위 간의 추적성, 컴퓨터 하드웨어 자원 사용 측정치와 CSCI 요구사항(HW 자원 사용 관련 요구사항) 간의 추적성을 정의하고 기록한다.

5.13.5 시스템 설계 기술서 업데이트(Updating the system design description)

개발자는 현재 구축된 시스템(the "as built" system)에 맞도록 시스템 설계 기술서를 업데이트 하는데 참여한다.

5.13.6 지원 매뉴얼 준비(Preparing support manuals)

개발자는 아래 요구사항에 부합하도록 지원 매뉴얼을 준비한다.

5.13.6.1 컴퓨터 프로그래밍 매뉴얼(Computer programming manuals)

개발자는 소프트웨어가 개발되거나 실행되는 컴퓨터를 프로그램 하는데 필요한 정보를 식별하고 기록한다.

5.13.6.2 펌웨어 지원 매뉴얼(Firmware support manuals)

개발자는 소프트웨어가 설치될 펌웨어 디바이스를 프로그램하고 재프로그램 하는데 필요한 정보를 식별하고 기록한다.

5.13.7 지정된 지원 사이트로 이전(Transition to the designated support site)

개발자는 1)계약서에 지정된 지원 환경에 소프트웨어를 설치 및 체크하고, 2)인도된 소프트웨어의 재생성 및 유지보수가 가능한 것을 구매자에게 증명하고(즉, 실행 소프트웨어로 컴파일, 링크, 로드 가능), 3) 지원 에이전시에 계약서에 명시된 교육/훈련을 제공하고, 4) 계약에 따른 기타 다른 지원을 지원 에이전시에 제공한다.

5.14 소프트웨어 형상 관리(Software configuration management)

개발자는 아래 요구사항에 부합하도록 소프트웨어 형상 관리를 수행한다.

5.14.1 형상 식별(Configuration identification)

개발자는 5.4.2 섹션의 시스템 아키텍쳐 설계에서 수행되는 CSCI 선정에 참여하고, 형상 통제 하에 놓일 엔터티를 식별하고, 형상 통제 하의 CSCI와 추가적인 엔터티 각각에 프로젝트 고유의 식별자를 부여한다. 형상 통제 하의 엔터티는 계약에 따라 개발될(또는 사용될) 소프트웨어 제품과 소프트웨어 개발 환경 요소(elements)를 포함한다. 형상 식별은 엔터티가 실제 통제되는 레벨이어야 한다(예, 컴퓨터 파일, 전자 미디어, 문서, 소프트웨어 단위, 형상 항목). 형상 식별은 각 엔터티의 버전/리비전/릴리즈 상태를 포함한다.

5.14.2 형상 통제(Configuration control)

개발자는 1)식별된 각 엔터티의 통제 수준(예, 작성자 통제, 프로젝트 단위 통제, 구매자 통제)을 지정하는 절차, 2)각 통제 수준에서 변경을 가하거나 변경을 승인하는 권한을 가진 사람/그룹, 3)변경 승인을 요청하고, 변경 요청을 처리하고, 변경을 추적하고, 변경을 배포하고, 과거 버전을 유지하는 절차 등을 확립하고 구현한다.

5.14.3 형상 상태 기록(Configuration status accounting)

개발자는 프로젝트 수준(또는 그보다 상위 수준)의 형상 통제 하에 놓인 모든 엔터티의 형상 상태 기록을 준비하고 유지한다. 형상 상태 기록은 각 엔터티의 현재 버전/리비전/릴리즈, 형상 통제 하에 놓인 이래로 변경 내역, 엔터티에 영향을 미치는 문제/변경 보고의 상태 등을 포함한다.

5.14.4 형상 감사(Configuration audits)

개발자는 계약에 명시된 구매자가 수행하는(주도하는) 형상 감사를 지원한다.

5.14.5 포장, 보관, 처리, 배달(Packaging, storage, handling, and delivery)

개발자는 구매자에게 인도할 소프트웨어 제품의 포장, 보관, 처리, 배달 절차를 확립하고 구현한다. 개발자는 인도된 소프트웨어 제품의 원본(master copies)을 계약 기간 동안 유지한다.

5.15 소프트웨어 제품 평가(Software product evaluation)

개발자는 아래 요구사항에 부합하도록 소프트웨어 제품 평가를 수행한다.

5.15.1 작업 중인 소프트웨어 제품과 최종 소프트웨어 제품 평가(In-process and final software product evaluations)

개발자는 본 표준의 요구사항을 수행하는 중에 생성되는 소프트웨어 제품의 평가(in-process evaluations)를 수행한다. 또한 구매자에게 인도될 소프트웨어의 최종 평가를 전달 전에 수행한다(평가할 소프트웨어 제품과 평가 기준은 부록 D 참고).

5.15.2 소프트웨어 제품 평가 기록(Software product evaluation records)

개발자는 각 소프트웨어 제품 평가의 기록을 준비하고 유지한다. 형상 통제 하에 있는 소프트웨어 제품에 발생된 문제는 ‘섹션 5.17 시정조치’에 기술된 대로 처리한다.

5.15.3 소프트웨어 제품 평가의 독립성(Independence in software product evaluation)

소프트웨어 제품 평가를 책임진 사람은 해당 제품을 개발한 사람과 동일하지 않다.

5.16 소프트웨어 품질 보증(Software quality assurance)

개발자는 아래 요구사항에 부합하도록 소프트웨어 품질 보증을 수행한다.

5.16.1 소프트웨어 품질 보증 평가(Software quality assurance evaluations)

개발자는 아래의 이유로 소프트웨어 개발 활동과 그 결과물인 소프트웨어 제품의 지속적인 평가를 수행한다.

a. 계약에서 요구한 또는 소프트웨어 개발 계획에 명시된 모든 활동이 제대로(해당 문서에 명시된 대로) 수행되고 있음을 보장하기 위하여

b. 본 표준 또는 계약에서 요구하는 각 소프트웨어 제품이 존재하며 의도된(해당 문서에 명시된) 평가, 테스팅, 시정 활동을 거쳤음을 보장하기 위하여

5.16.2 소프트웨어 품질 보증 기록(Software quality assurance records)

개발자는 각 소프트웨어 품질 보증 활동의 기록을 준비하고 유지한다. 형상 통제 하의 소프트웨어 제품에 있는 문제와 계약에서 요구한(또는 소프트웨어 개발 계획서에 명시된) 활동에 있는 문제는 ‘섹션 5.17 시정 조치’에 기술된 대로 처리한다.

5.16.3 소프트웨어 품질 보증의 독립성(Independence in software quality assurance)

소프트웨어 품질 보증 평가를 책임진 사람은 해당 소프트웨어 제품을 개발한 사람 또는 소프트웨어 제품/활동을 책임진 사람과 동일하지 않다(이 사람들이 품질 보증 평가에 참여하는 자체를 금지하는 것은 아님). 계약 준수 여부를 보장하는 일을 책임진 사람은 해당 작업에 요구되는 자원, 책임감, 권한을 가지며, 객관적인 소프트웨어 품질 보증 평가와 시정 조치 활동의 개시 및 검증이 가능하도록 조직적인 구속으로부터 자유롭다.

5.17 시정 조치(Corrective action)

개발자는 아래 요구사항에 부합하도록 시정 조치를 수행한다.

5.17.1 문제 변경 보고(Problem/change reports)

개발자는 형상 통제 하의 소프트웨어 제품이나 계약서에서 요구하는 활동(또는 소프트웨어 개발 계획서에 기술된 활동)에서 발견된 각 문제를 기술하는 문제/변경 보고서를 준비한다. 문제/변경 보고서는 식별된 문제, 필요한 시정 조치 활동, 현 시점까지 진행된 활동 등을 기술한다. 이 보고서는 시정 조치 시스템의 입력 데이터가 된다.

5.17.2 시정 조치 시스템(Corrective action system)

개발자는 형상 통제 하의 소프트웨어 제품과 계약에 요구된 활동(또는 소프트웨어 개발 계획서에 기술된 활동)에서 발견된 각 문제를 처리하기 위한 시정 조치 시스템(a corrective action system)을 구현한다.

5.18 합동 기술 및 관리 검토(Joint technical and management reviews)

개발자는 아래 요구사항에 부합하도록 합동(구매자/개발자) 기술 및 관리 검토를 계획하고 이에 참여한다.

5.18.1 합동 기술 검토(Joint technical reviews)

개발자는 개발자가 제안하고 구매자가 수락한 장소와 날짜에 합동 기술 검토를 계획하고 이에 참여한다. 이러한 검토에는 검토할 소프트웨어 제품에 대한 기술적 지식을 가진 사람이 참여한다. 검토를 위해 생성된 자료 보다는 작업 중인 또는 최종 완성된 실제 소프트웨어 제품에 검토의 중점을 둔다.

5.18.2 합동 관리 검토(Joint management reviews)

개발자는 개발자가 제안하고 구매자가 수락한 장소와 날짜에 합동 관리 검토를 계획하고 이에 참여한다. 이러한 검토에는 비용과 일정 의사결정 권한을 가진 사람이 참여한다.

5.19 기타 활동(Other activities)

5.19.1 위험 관리(Risk management)

개발자는 소프트웨어 개발 프로세스 전반에서 위험 관리를 수행한다. 개발자는 1) 잠재적인 위험(기술/비용/일정 측면) 및 이와 관련된 소프트웨어 개발 프로젝트 영역을 식별하고, 분석하고, 우선순위를 정하며 2) 이러한 위험을 관리하기 위한 전략을 개발하고 3) 소프트웨어 개발 계획에 이러한 위험과 전략을 기록하고 4) 계획에 따라 이 전략을 구현한다.

5.19.2 소프트웨어 관리 지표(Software management indicators)

개발자는 소프트웨어 개발 프로세스를 관리하고 그 상태를 구매자와 의사소통 하는 것을 돕기 위해 소프트웨어 관리 지표를 사용한다. 개발자는 수집할 데이터, 데이터를 해석하고 적용하는 방법, 이를 보고하는 방식을 포함하는 소프트웨어 관리 지표를 식별하고 정의한다. 개발자는 이러한 정보를 소프트웨어 개발 계획에 기록하고, 계획서에 기술된 대로 관리 지표를 수집하고, 해석하고, 적용하고, 보고한다.

5.19.3 보안과 프라이버시(Security and privacy)

개발자는 계약서에 기술된 보안과 프라이버시 요구사항을 충족시킨다. 이 요구사항들은 소프트웨어 개발 노력 또는 그 결과물인 소프트웨어 제품에 영향을 미칠 수 있다.

5.19.4 하청 업체 관리(Subcontractor management)

하청 업체를 이용하는 경우 개발자는 주 계약 요구사항에 부합하도록 소프트웨어 제품을 개발하는데 필요한 모든 계약 요구사항을 하청 계약에 포함시킨다.

5.19.5 독립적인 V&V 기관과의 인터페이스(Interface with software IV&V agents)

개발자는 계약에 명시된 대로 독립적인 소프트웨어 V&V 조직(the software Independent Verification and Validation agent)과 인터페이스 한다.

5.19.6 유관 개발자와의 협업(Coordination with associate developers)

개발자는 계약에 명시된 대로 유관 개발자/워킹그룹/인터페이스그룹과 협업한다.

5.19.7 프로젝트 프로세스 개선(Improvement of project processes)

개발자는 프로젝트에 사용된 프로세스를 주기적으로 평가하여 그 적절성(suitability)과 효과성을 판단한다. 이 평가에 기반하여 개발자는 필요한(또는 유익한) 프로세스 개선사항을 식별하고, 구매자에게 이러한 개선 관련 소프트웨어 개발 계획 업데이트를 제안하고, 구매자가 승낙하면 이를 프로젝트에 구현한다.