ASPICE 20

Process quality가 제품 품질에 영향을 주는가?

도성룡 강사님의 ASPICE 기본 교육 내용을 인용해서 글을 작성하는 것을 말씀 드립니다. 제 처음 전공은 "품질경영, 품질공학" 입니다. 신뢰성 공학과 관리도 설계를 세부 전공하였고 현장 품질을 알아야 한다는 혼자만의 생각을 가지고서 매몰차게 호되게 부딪힌 경험이 있습니다. 현재는 자동차 부품 연구소에서 일하면서 그 때의 호되게 경험했던 기억이 간혹 떠오를 때가 있는데요. 품질과 관련된 일이 생길 때라고 말씀 드릴 수 있겠네요. ISO 26262, ASPICE, CMMI 등을 하면서 현업 개발자분들 중에는 이런 말씀을 하시는 분들이 간혹 있습니다. "이거 해야돼?" "이게 뭐라고.. 바빠 죽겠는데.." "고객이 시켜서 하는 거잖아" "사람 붙여줘, 구해줘, 우린 바빠서 못해" 좋습니다. 아무리 설득해도..

[ASPICE 핵심 컨셉#7] The relation between "Strategy" and "Plan"

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 개인적으로는 전략 (Strategy)이란 말을 많이 사용합니다. 같은 프로젝트라도 가용 가능한 자원 (시간 포함)과 상황에 따라서 다른 부분들을 고려해봐야 하고, 그럴 때마다 저는 '그래서 우리의 전략은 어떻게/얼만큼/언제.. 등을 고민해봅니다' ASPICE에서도 전략 (Strategy)는 프로젝트 목표 달성을 위해 수행가능한 부분들을 고려합니다. 이러한 전략들은 구체화 하고 어떻게 수행할지, 결국은 이해관계자들과 합의하여 계획 (Plan) 형태로 작성됩니다. 예를 들면, Carry over 되는 프로젝트라도 변경될 부분들, 이전 차종에서 발견된/확인된 부분들을 통해서 System Requirements를 어떻게 관..

[ASPICE 핵심 컨셉#6] "Evaluate", "Verification Criteria" and "Ensuring compliance"

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 평가한다 (Evaluate): 시스템 아키텍처 (SYS.3), 소프트웨어 아키텍처 (SWE.2)의 상세 설계의 여러 대안을 평가한다. 먼저 아키텍처에 대해서 간단하게 얘기해보면, 아키텍처는 구현을 위한, 문제 해결을 위한 접근이 필요합니다. 즉 What 보다는 How에서 논의가 필요합니다. 구성요소는 어떻게 이뤄지고, 구성 요소들간에 관계, 그리고 이 구성요소들의 외부로 보여지는 속성들은 어떤지를 고민해야 합니다. 아키텍처가 필요한 이유는 이해관계자와 의사소통할 산출물이며, 비 기능 요구사항의 실현 가능성을 분석할 수 있게 합니다. 또한 이전 개발로부터 재 사용할 수 있게끔 활용될 수 있습니다. 아키텍처를 평가한다 ..

[ASPICE 핵심 컨셉#5] "Agree" and "Summarize and Communicate"

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 개발하면서 다양한 리스크가 존재합니다. 여러 프로젝트에서 공통적으로 나타나는 리스크에서 없어지지 않는 하나가 의사소통, 공유인 것 같습니다. 만들어진 작업 산출물에 대한 REVIEW가 완료되면 관련 이해관계자가 해당 내용을 인지하고 있어야 합니다. 이 부분을 위에서 말씀 드린 의사소통, 공유라고 말씀 드리는 것입니다. ASPICE에서도 이러한 부분이 현실적으로 나타나는 공통의 리스크인 점을 알고서 핵심 컨셉 5번째로 활동을 요구하고 있습니다. V 모델 왼쪽 편 (Left side)에서는 "Communicate agreed", "합의한다"라고 말하고, V 모델 오른쪽 편 (Right side)에서는 "Summarize..

[ASPICE 핵심 컨셉#4] Traceability (추적성) and Consistency (일관성)

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 위 그림에서 각 프로세스 간에 연결되어 있는 선(Line)이 많이 보입니다. 선의 색에 따라서 추적성 (Traceability), 일관성 (Consistency)를 나타냅니다. 선이 많다는 것은 그만큼 추적성과 일관성이 많이 필요하다고 생각하시면 됩니다. 여기서, 추적성과 일관성은 다음을 의미합니다. 추적성 (Traceability): 작업 산출물 내 관련 요소들 간에 연결되어 추적 가능한지를 의미 일관성 (Consistency): 작업 산출물 내 관련 요소들 간에 내용과 의미가 일관되게 반영되어 있는지를 의미 추적성부터 간략하게 살펴보면 아래 그림과 같이 Requirements가 구현 그리고 Test case까지 ..

[ASPICE 핵심 컨셉#2] V-model 컨셉이란?

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 아래 그림과 같이 Requirements 가 왼쪽에 있다면, Qualification Test가 오른쪽에 있습니다. 아키텍처가 왼쪽에 있는 경우 통합 테스트가 오른쪽에 있듯이요. 이러한 V자는 시스템에서 도메인 Software level로 이어지더라도 동일하게 적용됩니다. 구현(코딩) 시 Unit Verification 이 맵핑되듯이요. 그럼 왜 V model을 기반으로 프로세스를 구성하였을까요? / 고려해서 생각해야 할까요? 일반적으로 소프트웨어 프로세스는 아래와 같은 단계를 거치게 됩니다. 이러한 단계를 한번 씩 수행하면서 요구사항 부터, 테스트 단계까지 쭈욱 이어가는 것을 Waterfall (폭포수) 모델이라고..

[ASPICE 핵심 컨셉#1] Plug-in이란?

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다. 시스템이란 의미부터 생각해 봅니다. 시스템은 하나의/또는 작은 소프트웨어만으로도 구성될 수 있으며, 또는 간단한 하드웨어 또는 IC를 포함하는 복잡해진 PCB로 구성되어 센서, 제어, 액추에이션을 수행할 수도 있습니다. 그리고 외부 환경의 영향으로부터 안전성, 힘, 역학 등을 고려한 메카닉까지 포함할 수도 있죠. (아래 그림에서는 SWE를 포함해서 이러한 영역을 Domain level로 표현하고 있습니다.) ASPICE PAM (Process Assessment Model), PRM (Process Reference Model) 에서는 기본적으로 SYS (System Engineering), SWE (Software..

Automotive SPICE Level

SPICE 모델을 기반으로 자동차 산업에서는 기본 전장프로세스로 ASPICE, Automotive SPICE 를 많이들 고려해서 진행하고 있습니다. 아래 그림처럼 레벨은 0단계에서 5단계로 프로세스 성숙도를 평가하고 있습니다. 레벨 0은 프로세스 기반으로 일하지 않는다 이며, 레벨 5는 가장 높은 수준으로 프로세스 기반의 개발을 하고 있다. 라고 이해하시면 됩니다. 레벨0. Incomplete 불완전한 프로세스 프로세스가 이행되지 않거나 프로세스 목적을 달성하지 못함 요구사항 작성하지 않고 개발 요구사항 작성하였으나 내용 부족하고, 요구사항 기반으로 개발을 전개하기 어려운 경우 레벨1. Performed 프로세스를 수행하면 레벨 1, 수행되었다라는 의미가 관리되고 있다는 의미가 아님 (결과물은 작성하지만..

Need, Wants, Requirements

요구사항(Requirements)을 알기 위해서 아래를 먼저 얘기해본다. Want는 구체적으로 원하는 것, 필요(Need)를 만족시킬 수 있는 어떤 제품이나 서비스 Need는 기본적으로, 근본적으로 어떤 결핍을 느끼는 것, 그리고 사람에게서 공통적으로 나타나는 현상 출처: https://keydifferences.com/difference-between-needs-and-wants.html 수많은 문제를 해결하는 과정으로 생각하면, 문제는 Wants, Needs를 말하는 것이고 문제를 해결하는 해결책 Solution은 Requirements 인 것이다. Wants --> Needs --> Requirements 출처: https://blogs.managementconcepts.com/2020/09/16/..

Why difficult to perform the Verification(Test)?

※ 해당 글은 "SW 요구사항 개발" 강의를 들으면서 메모하고 싶은 내용을 기록하고 공유하기 위함입니다. 저작권 및 위배가 되는 경우 해당 글은 별도의 공지 없이 삭제될 수 있습니다. 가급적 위배가 되지 않는 내용에서 글을 작성합니다. 검증(테스트)이 어려운 이유는? 이유는 요구사항을 기반으로 해야 하기 때문이다. 즉, 요구사항이 불명확거나, 요구사항이 모호하거나, 요구사항이 일치하지 않거나 충돌이 발생하는 등 모두를 포함해서 검증(테스트)가 어려운 이유이다. 위 ASPICE PAM3.1 그림에서의 V 사이클 그림을 보면 요구사항을 분석하면서 System Qualification Test 단계가 수행된다. 즉 검증(테스트)의 수행이 개발 초기에도 이뤄져야 하고 할 수 있다는 것이다. 그런데 요구사항이 실..