ASPICE 4.0 PAM 전체 프로세스 빠르게 훑기

참고로 MAN.3 프로세스만  이전 글에서 따로 잘 정리한 것이 있어서 MAN.3만 생략했다.

 

업무하는 도중에 시간이 남을 때 짬짬히 써서 어느 부분은 정성스럽게 작성했고 어떤 부분은 대충 작성했을 수 있다는 점

참고 바람.

 

SUP.1
품질보증의 목적 고객의 요구사항이 온전히 구현됨을 보장하고 
이 요구사항을 구현하기 위한 모든 조직의 모든 계획들이 프로세스적 측면에서
제대로 준수가 되었는지 그리고 그 정의된 프로세스가 정말로 요구사항을 구현하는데
문제가 없음을 보장하는지 그리고 프로세스를 통해 만들어진 산출물이 산출물간에
정보를 전달하는데 완전함을 보장하는지 점검 그리고 프로젝트와 독립적인 관계로
객관적인 평가를 해주고 MAN.3의 관리의 목표가 정해진 기간 안에 제품 납기라면
SUP.1의 목적은 납기 기간이 늘어날 지라도 품질을 완전하게 하겠다는 견제 그러므로
따로 에스컬레이션 절차를 가져 모든 프로젝트 구성원을 견제할 수 있는 힘이 있어야
함. 


SUP.8
형상관리의 목적은 
형상이 잘 관리가 되어 있다면:
조직은 기술적 자산이 어떻게 형성되어 있는지 알 수 있고
각각의 아이템이 다른 것과 어떻게 연관되는지 알 수 있음

CM은 형상 항목에 대한 추적을 해야함- 즉 형상의 핵심은
형상 항목에 대한 모든 변경에 대하여 끊임없이 추적이 
되어야 하는 것인데 그러다가 베이스라인으로 확정이 나면
그것을 기반으로 통제를 해야 하는 것인데 이건 인간이
다 할 수 있다는 것은 거의 불가능 그렇기 때문에 모든 팀의
구성원들이 형상 관리 툴을 사용해야 함(언제 구성원이 형상
아이템을 변경할 지 모르는데 또 변경했을 떄 변경 했다는 것을
모든 팀의 구성원에게 알리지 않는다면 나중에 각 형상이
결합이 안되는 일이 벌어질 것임 그래서 아주 사소한 변경이
있더라도 그 변경에 대한 알림이 공유되어지고 형상은 항상
통제되어 지는 것이 안전함)



SUP.9
문제 해결관리를 한다고 할 때
→ 제 때 공유가 적절히 되야 하고, 신속히 해결, 관리가 되고, 마무리

시뮬레이션: 예상치 못한 문제가 터지겠지 그 다음 발견자가 있는데 누가 문제를
해결해야 할 지 고민해야 함 그리고 문제해결자 선정하고 선정된 담당자는 
문제 원인 파악하겠지? 그리고 해결할 거임 문제 원인 파악하고 해결하려는 시나리오를
짜려는 순간에서 뭔가 다른 것에 영향을 줄 것이 생길거임. 그것을 파악하는 활동을 하고
그 영향을 받을 사람에게 또 알리는 통보를 해야 됨. 조직에서 해결할 수 없는 일이
있을 것인데 어떻게 이루어지는가? (여기서 예산을 초과할 경우는 어떻게 처리가 되는지)
등록되었던 문제들을 기록하여 고객에게 전달하고 이 전달 문서에는 트렌드 분석까지 있음 좋다.
문제 건에 대한 식별자를 부여해야지 문제가 변경 요청사항으로 넘어갈 때 추적 가능



문제의 기록시에 중요도도 구분해야 함. 또한 문제의 상태, 문제 제기자, 문제 해결자, 문제
해결 검토자, 문제 해결 완료 예상 날짜도 정해야 함




긴급 사항에 대한 문제해결 처리를 위해(물론 이를 위한 기준이 세워져 있어야 함) 신속한
대응이 되는 절차가 마련되어 있어야 함

문제가 심각한 영향을 발생할 것으로 예상될 경우엔 이를 경보하는 메커니즘이 있어야함
변경요청 관리와 이어지는 내용이 있어야 할 듯? →두 프로세스에 필요한 기록 사이에 추적성이
링크로 연결되어 있어야 함.

만약 처음에 문제 이슈가 등록되어 문제 해결 조치 절차를 타고 있다가 변경 요청관리 프로세스
로 넘어가서 변경에 거기서 문제가 해결이 되면 그 사실을 문제 해결 관리절차 프로세스에 
알려서 문제해결 관리 절차 프로세스에서도 그 문제에 대한 이슈를 closed시켜야 함

                                 


SUP.10
변경 요청이 들어오는데 그 문제를 변경할 지 말아야 할지에 대한 특정 기준을 토대로
판단하여 정하여야 됨, (예를 들어 내부 요청 인지 외부 고객 요청인지에 따라서도 달라질 거임)
변경을 결정할 경우 그 변경이 미치는 영향을 분석하고(이 분석은 영향 받는 이해 관계자 모두가
참여해야 함) 이를 대처할 수 있어야 함. 또한 변경의 평가도 해야 함 그렇게 모든 부분에서 
변경이 이루어지는데 아무런 문제가 없도록 해야 함. 변경되는 것의 상태가 종료될 
때까지 모니터링 되어야 함.

영향 분석을 할 때 기준의 예시: 자원의 요구, 스케쥴링, 위험, 이익 등

변경은 변경 이전에 반드시 승인을 받아야 하며 승인을 한다는 것은 이전의 변경의 영향에
대한 분석과 이용가능한 자원을 고려하여 승인하겠다는 거임, 아무튼 이런 승인의 과정이
필요하기 때문에 change control board가 만드는 것이 하나의 정형적인 메커니즘임

변경이 이루어진 것은 반드시 고객에게 의해 closure되기 전에 그것이 정상적으로 구현이 
되는 지 반드시 확인하는 과정이 필요함


SYS.2
이름이 요구사항 분석인데 요구사항 분석이 이루어진다고 할 때,
요구사항 분석은 시스템 아키텍처를 설계하기 이전의 작업 활동으로 아키텍처 설계에 도움이 되어야 한다.
여러분이 레고 설계를 한다고 생각을 해보자 무조건적으로 보이는데로 조립하는 것보다 구상을 하여 어느
부분을 먼저 조립하는 것이 좋을지 생각을 하는게 훨씬 효율적일것이다.
  
먼저 요구사항을 명세할 때에 필요한 속성을 표준(ISO 26262)같은 것을 참고하여 요구사항을 위한 특성
표를 구성한다.


요구사항에 대하여 구조화하고 우선순위화 해야함.
구조화라는 것은 그룹핑같은 것이라 볼 수 있는데, 보통 기능이냐 비기능이냐로 분류하거나 혹은 
product variant로 분류하기도 함 (이렇게 분류하는 이유는 하위 단계로 요구사항을 할당시에 
서로 간에 전혀 섞일 일이 없는 요구사항을 애초에 잘 분류하기 위해서라고 생각된다.)

운선순위화라는 것은 보통 고개이나 프로젝트 릴리즈 범위에 따라 정해진다.
(우선순위를 정하는 이유는 예를 들어 자신들이 확인하고 싶은 기능 중 가장 주요화 된 무엇이 얼마나 진척이
되었고 잘되고 있는지 중간 중간에 확인을 하고 싶을 것이다. 그렇기 때문에 그들의 릴리즈 범위를 참고하여 
우선순위화하는 것이 일반적인 것 그 외에 우선순위하는 방법은 기능도 기능마다 좀 더 상위 개념 그니까 
선행적으로 개발이 되어야 프로젝트 진행이 편하게 되는 그런게 있다. 그런거를 먼저 순서에 두는
우선순위화 기법이 있다)

요구사항의 분석은 기술적 실현가능성, 정확성에 대한 보장 같은 것을 말함

시스템 요구사항이 운영 환경에 미치는 영향에 대하여 분석

산출물이 프로젝트 계획서에 정의된 담당자에 의해 개발 되었는가?


SYS.3
시스템 아키텍처 설계는 매우 추상적인 단계이다. 소프트웨어 하드웨어 아키텍처 설계와는 다르게
단순히 추상적 개념으로 어떤 요소들이 어떻게 배치되어 있고 그들간의 흐름이 어떻게 이루어지고
를 언어적으로만 설명하는 수준이기 때문이다. 이 흐름이 구현이 될지 안될지는 아직 검증이 된 
것이 아닌채로 얘기를 하는 것이다. 비유적으로 보자면 조직에 비유할 수 있는데 적어도 고객에게
어떤 프로젝트를 받았다고 치자 그럼 그 프로젝트의 요구사항이 있을 것이고 적어도 우리는 추상적
으로 요구사항의 어떤 부분은 어떤 부서에서 처리하고 저 부분은 이 부서에서 처리하고 이렇게 할당
을 하고 그들이 각자 어떻게 처리를 하면 그 정보를 어떤 부서에서 어떤 부서로 전달을 하고 등등의
대략적인 구상을 할 수가 있다는 것이다. 바로 이것이 시스템 아키텍처에서 하는 일이다. 근데 당신도
알겠지만 일단 각 부서에게 할당을 하고 어떻게 흐름이 이어질 지 구상은 했지만 실제 각 부서에서
처리해 주길 바라는 일을 예상한 것처럼 처리해 줄 수 있는지는 미지수이다. 그렇기 때문에 그 하위
단계인 소프트웨어 하드웨어 수준에서 실질적 구현 수준에서 아키텍처를 또 설계하게 된다. 이 
설명만 해줘도 대충 시스템 아키텍처에서 해야만 하는 일이 무엇일지 예상이 갈 것이다. 그리고 아래
에 쓰게 되는 글은 ASPICE에서 시스템 아키텍처에서 하라고 시킨 절차들이다. 한 번 납득이 가는 
절차들인지 고민해봐라.

시스템 요구사항을 각각 기능 비기능으로 구분하여 시스템 아키텍처의 정적인 측면에 대하여 명세를 
하는가? 그리고 시스템의 외부 인터페이스와 내부 인터페이스와의 관계에 대하여 정적인 측면으로 
명세를 하였는가?

시스템 요구사항을 각각 기능 비기능으로 구분하여 시스템 아키텍처의 동적인 측면에 대하여 명세를
하였는가? 그리고 시스템 엘리먼트의 각 다른 시스템 모드에 따른 상호작용 및 행동에 대하여 명세
하였는가?

시스템 아키텍처를 분석하는데 아키텍처 디자인을 선택한 합리적 근거를 대야하고 

시스템 아키텍처를 분석할 때는 생명주기(개발, 생산, 유지 보수, 폐기)의 단계에 대하여 기술적
측면(즉, 재사용될 기존 시스템 엘리먼트의 적절성, 생산 라인의 제조성에 대한 분석을 한다.

기술적 측면의 분석에 적절한 기법은 다음과 같다.(프로토타입, 시뮬레이션, 정성적 분석(FMEA))


SYS.4 
시스템 통합과 통합 검증
이 프로세스의 진짜 목표는 SYS.3에서 진행했던 시스템 아키텍처 설계(이론)가 제품에 그대로 구현이
되었는지 검증 하는 것이라고 볼 수 있다. 이전에 SYS.3에서 일어나는 일을 프로젝트를 수행하는 
조직으로 비유했던 것으로 다시 바라보자면 하위 단계단인 소프트웨어 하드웨어가 구현을하고 검증까
지 마쳤으니 각 부서에게 할당했던 요구사항 즉 추상적인 요구사항: 어떤 부서에서 어떤 요구사항을 
맡고 타 부서와 각 처리한 정보를 교환시 예상된 흐름대로 움직여지도록 했는지 물으면서 검증을 하는
것 그렇게 최초 요구사항을 추상적으로 구상화 했던 모든 것이 다 검증이 되었다면 SYS.4의 활동은 
끝이다.

물론 검증은 구상하는 것 이외의 모든 예상치 못했던 허점을 파악하기 위해서 많은 테스트 케이스를
만들어야 한다

아무튼 ASPICE에서 가이드하는 절차는 
시스템 통합에 대한 검증방안(검증 방법 테크닉, pass/fail 기준, 검증 방법에 대한
진입 조건과 탈출 조건 정의, 요구되는 검증 인프라와 환경)을 명세하는 것

시스템 통합 테스트 케이스 생성시 집중해야 할 컨텐츠는 다음과 같다.
○올바른 신호가 시스템 아이템 간에 흐르고 있는지
○시스템 아이템 간에 신호 흐름에 있어 적절한 시기와 시간적 의존관계
○모든 시스템 아이템의 인터페이스의 신호가 정확하게 통역이 되는지
○시스템 아이템간에 동적 상호작용

또한 회귀 검증 기준을 포함한 선택 기준을 고려해서 각 통합 단계에 맞는 검증 수단을 선택해야 
하는데 선택되는 검증 수단은 납기 범위를 충분히 커버할 수 있어야 함
여기서 말하는 선택 기준은 다음과 같은 것이 될 수 있음
○고객의 요구사항의 우선순위
○회귀 검증의 요구

통합 전략을 가지고 시스템이 완전히 통합이 될 때까지 통합을 진행한다. 그리고 검증 시 pass/fail를
포함해서 데이터를 기록한다. 


SYS.5
시스템 검증
이 프로세스의 목표는 고객의 요구사항 즉 SYS.2 시스템 요구사항을 잘 준수하고 있는지 검증하는
것이다. 그런데 요구되는 절차는 모두 SYS.4랑 같다. 그 대상이 SYS.4 에서는 SYS.3를 향해있고
SYS.5에서는 SYS.2를 향해 있다는 차이 밖에는 없다.


SWE.1 - SYS.2과정과 거의 비슷

시스템 요구사양과 시스템 아키텍처에서 분석되고 구조화된 소프트웨어 관련 요구사항을 수립하는 
것
먼저 요구사항을 명세할 때에 필요한 속성을 표준(ISO 26262)같은 것을 참고하여 요구사항을 위한 특성
표를 구성한다.


소프트웨어 요구사항에 대하여 구조화하고 우선순위화 해야함.
구조화라는 것은 그룹핑같은 것이라 볼 수 있는데, 보통 기능이냐 비기능이냐로 분류하거나 혹은 
product variant로 분류하기도 함 (이렇게 분류하는 이유는 하위 단계로 요구사항을 할당시에 
서로 간에 전혀 섞일 일이 없는 요구사항을 애초에 잘 분류하기 위해서라고 생각된다.)

운선순위화라는 것은 보통 고개이나 프로젝트 릴리즈 범위에 따라 정해진다.
(우선순위를 정하는 이유는 예를 들어 고객들이 확인하고 싶은 기능 중 가장 주요화 된 무엇이 얼마나 진척이
되었고 잘되고 있는지 중간 중간에 확인을 하고 싶을 것이다. 그렇기 때문에 그들의 릴리즈 범위를 참고하여 
우선순위화하는 것이 일반적인 것 그 외에 우선순위하는 방법은 기능도 기능마다 좀 더 상위 개념 그니까 
선행적으로 개발이 되어야 프로젝트 진행이 편하게 되는 그런것이 해당 된다

요구사항의 분석은 기술적 실현가능성, 정확성에 대한 보장 같은 것을 말함

소프트웨어 요구사항이 운영 환경에 미치는 영향에 대하여 분석

소프트웨어 요구사항과 시스템 아키텍처 사이의 양방향 추적성, 소프트웨어 요구사항과 시스템
요구사항간의 추적성을 보장한다.

※소프트웨어 요구 사항이 추적하지 않는 비기능적 시스템 요구 사항이 있을 수 있습니다. 예를 들어 
프로세스 요구 사항 또는 인시던트 처리와 같은 이후 소프트웨어 제품 수명 주기 단계와 관련된 요구 
사항이 있습니다. 이러한 요구 사항은 여전히 검증의 대상이 됩니다.


SWE.2 소프트웨어 아키텍처 디자인
전반적으로 소프트웨어 수준의 시스템이 어떻게 구성되고 작동이 되는지를 보여줘야하기 때문에
논리적이어야 하고 이를 위한 상세한 설명들이 필요하다. 시스템이라는 것 자체가 복잡한 관계가 얽혀 있다는
뜻이기 때문에 이것이 실제적으로 구현되기 위해선 철저한 논리가 필요하고 그 논리는 상세한 설명들이
있어야 모순점이 없음을 알 수 있다. 그리고 특히 동적인 측면은 더욱 논리적이어야 하므로 이를 잘 표현할
수 있는 설명이 될 수 있도록 해야 한다.

내부 및 외부 인터페이스를 포함해서 소프트웨어 요구사항을 정적인 측면에 대하여 명세화 하기

내부 각 시스템 모드와, 동시성 측면에 따른 컴포넌트와와 그들의 상호관계의 행동에 대해 기능 
비기능으로 구분하여 동적인 측면에 대한 명세를 해야 함.
ex)여기서 동시성 측면이라는 것은 application-relevant interrupt handling, preemptive processing, 
multi-threading. 이러한 것들이다.
※동적 행태를 표현하는 일반적인 방법은 자연어나 semi formal notation(SysML, UML)것이 될 수 있음

소프트웨어 아키텍처와 관련된 기술적 설계 측면을 분석, 프로젝트 관리를 지원하기 위한 프로젝트 측면에
대한 평가를 해야 함. 그리고 선정한 소프트웨어 아키텍처 결정의 합리적인 이유를 대야 함.
현재 어플리케이션에 적용할 재사용하는 컴포넌트가 적절한지 분석을 해야 함.
※기술적 측면의 분석에 적절한 기법은 다음과 같다.(프로토타입, 시뮬레이션, 정성적 분석)
Examples of technical aspects are functionality, timings, and resource consumption 
(e.g. (ROM, RAM, external / internal EEPROM or Data Flash or CPU load).


SWE.3 소프트웨어 상세설계와 유닛 구축
소프트웨어 상세설계 및 유닛 수준에서는 이미 매우 작은 단위까지 분해한 수준이기 때문에 그만큼 
단순화 되어 있는 상태이다. 그래서 뭐 복잡한 관계에서 나오는 것을 따지기 보다는 얼마나 일관성이 있고
의도하는 것을 구현이 될 수 있도록 것이 중요하다. 그래서 추적성 같은 것을 주효하게 볼 수 있을 것이다.

이 프로세스의 목표는 소프트웨어 아키텍처의 상세 디자인을 수립하고 그 상세 설계와 일관성있는
소프트웨어 유닛을 구축하는 것임.

유닛 수준에서 정적인 구조와 관계를 명세해야 함
어플리케이션 도메인 관점에서 인풋과 아웃풋의 유효값의 범위를 정해야 함

동적 측면(동적 행태는 자연어나 semiformal notation으로 표현 가능)에서 상세설계를 하였는가?
소프트웨어 상세 설계와 소프트웨어 아키텍처의 일관성 및 양방향 추적성이 보장 되는가?
소프트웨어 유닛과 소프트웨어 상세설계의 일관성 및 양방향 추적성이 보장 되는가?
소프트웨어 상세설계와 소프트웨어 요구사항의 일관성 및 양방향 추적성이 보장 되는가?
와 같은 질문에 대한 답이 될 수 있도록 보장이 되어야 함.

SWE.4 목적은 소프트웨어 유닛이 소프트웨어 상세 설계에 일관성이 있는지 검증
소프트웨어 상세설계에 있는 정의된 소프트웨어 각 유닛에 대한 검증 수단을 명세 해야 함.
검증 수단에 대한 진입 및 탈출 기준을 포함해서 적합한 검증 환경과 검증의 pass/fail 기준을 정의
해야 함.

검증 수단은 정적 분석(MISRA같은), 코드 리뷰, 유닛 테스팅이 될 수 있음, 
검증 수단을 선택해야 하는데 반드시 회귀 검증의 기준을 포함하여 선택해야 함.
그리고 릴리즈 범위를 고려하여 이를 충분히 커버할 수 있는 만큼 검증 수단을 선택해야 함.
선택된 검증 수단을 가지고 검증을 수행하는데 pass/fail상태와 이에 대응되는 측정 데이터를 포함한 결과를
기록해야 함.
검증 수단과 소프트웨어 유닛간의 양방향 추적성 및 일관성 확보
검증 기록과 검증 수단(테스트 케이스 등)간의 양방향 추적성 확보


SWE.5 소프트웨어 컴포넌트 검증과 통합 검증
목적은 소프트웨어의 컴포넌트 수준이 아키텍처에서 의도한 그대로 잘 작동하는지 보는 것.
그니까 순차적으로 통합하는 과정에서 형성되는 컴포넌트 모든 것 하나 하나의 검증을 하는 것인데
정확히 설명하자면 통합을 하면서 점점 그 컴포넌트의 크기는 커질 것이다. 그런데 이 때마다 형성된
컴포넌트와 그 주변의 인터페이스의 동작이 잘되고 또 그 컴포넌트 안에서의 작동 자체가 잘 되는지
이를 매번 통합하면서 같은 메커니즘으로 검증하는 것.
 
소프트웨어 통합 부분에 대한 검증 수단 명세 (통합하는 엘리먼트 끼리의 상호작용)
진입 및 탈출 기준을 포함해서 적합한 검증 환경과 검증의 pass/fail 기준을 정의해야 함.

통합 할 떄마다 형성되는 컴포넌트에 대한 검증 수단을 명세
진입 및 탈출 기준을 포함해서 적합한 검증 환경과 검증의 pass/fail 기준을 정의해야 함.

검증 수단을 선택해야 하는데 반드시 회귀 검증의 기준을 포함하여 선택해야 함.
그리고 릴리즈 범위를 고려하여 이를 충분히 커버할 수 있는 만큼 검증 수단을 선택해야 함.


SWE.6 소프트웨어 검증
통합된 소프트웨어가 소프트웨어 요구사항을 온전히 반영하고 있는지 검증하는 것
검증 수단의 기술과 검증 수단의 필수적인 절차도 고려함.※참고로 검증 수단의 기술은 상황에 따라
고를 수 있다. 그 예로는(boundary values, equivalence classes, data range oriented requirement
fault injection 등이 있다.)
진입 및 탈출 기준을 포함해서 적합한 검증 환경과 검증의 pass/fail 기준을 정의해야 함. 사실 
검증하는 대상만 달라졌지 SWE.4, SWE.5에서 하는 활동을 거의 비슷하게 다 해야 한다고 보면 됨.