도성룡 강사님의 ASPICE 기본 교육 내용을 인용해서 글을 작성하는 것을 말씀 드립니다.
제 처음 전공은 "품질경영, 품질공학" 입니다.
신뢰성 공학과 관리도 설계를 세부 전공하였고 현장 품질을 알아야 한다는 혼자만의 생각을 가지고서 매몰차게 호되게 부딪힌 경험이 있습니다.
현재는 자동차 부품 연구소에서 일하면서 그 때의 호되게 경험했던 기억이 간혹 떠오를 때가 있는데요.
품질과 관련된 일이 생길 때라고 말씀 드릴 수 있겠네요.
ISO 26262, ASPICE, CMMI 등을 하면서 현업 개발자분들 중에는 이런 말씀을 하시는 분들이 간혹 있습니다.
"이거 해야돼?"
"이게 뭐라고.. 바빠 죽겠는데.."
"고객이 시켜서 하는 거잖아"
"사람 붙여줘, 구해줘, 우린 바빠서 못해"
좋습니다. 아무리 설득해도 안되는 경우도 있으니까요..
그런데 그 중에서도 제가 참기 힘든 말이 "이거 한다고 좋아져? 이럴 시간에 코드 더 보는게 맞지!" ..
제 대답은 네! 좋아집니다. 였습니다.
직접 경험한 사례들을 말씀 드리고, Best practice를 보여주어도 잘 안 바뀌시더라고요. ㅠ
사내 강의 중에서 일목요연하게 사례들도 잘 섞어서 설명해주는 ASPICE 교육을 들었습니다.
제게는 BMW와 폭스바겐에서 이와 관련하여 오래전 발표한 내용을 언급해주었던게 머리 속에서 떠나지가 않네요 :)
그리고 약 20년 전에 들었던 Demming, Juran, Crosby 이름도 듣고요
BMW, VOLKSWAGEN 사례를 통해서 프로세스 품질이 제품 품질에도 영향을 준다는 객관적인 자료를 아래와 같이 발표하였습니다. 참고하시기 바랍니다.
1. BMW에서 프로세스 품질이 좋은 조직 과 프로세스 품질이 조지 않은 조직 간의 비교를 발표 했었네요.
출처: Volker Lehmann, Practical Experience form Assessment, Automotive SPICE Conference Shanghai, 2018
프로세스 품질이 좋은 조직에서는 SOP 기준으로 16개월 전에 총 결함의 50%를 발견했다고 합니다.
그리고 SOP 11개월 전 총 결함의 90%까지 발견하고 개선하였네요.
반면에 프로세스 품질이 좋지 않은 조직에서는 SOP 8개월 전에 50% 결함 발견, SOP 2개월 전에 90% 발견이라고 합니다.
저는 여기서 2가지 생각이 번쩍 들었습니다.
첫 번째는 아... SOP 2개월 전에 결함이 발견되다니.. 야근과 철야를 계속 하셨겠구나... ㅠ
두 번째는 아... 프로젝트 처음에는 편하셨겠구나..
백분율로 50%, 90%까지 도달하는데 걸리는 시간이 약 8~9개월이 차이가 납니다.
프로세스 품질이 좋은 조직 (당연히 현업에 적용하는 케이스)은 사전에 결함을 발견하고 조치할 시간이 충분하구나,
1:10:100 법칙처럼 앞에서 미리 개선하니까 양산 품질도 시간을 가지고 대응이 가능하겠구나 싶었습니다.
(역쉬!!)
2. 폭스바겐 (VOLKSWAGEN) 사례는 BMW보다 더 구체적, 상세화된 비교를 발표햇었습니다.
출처: Martin Becker, Process are good for you - beliefs and Facts, VDA. Automotive SYS Conference, 2014
동일한 ECU, 동일한 차량 프로그램을 사용해서 개발, 동일한 고객 요구사항 그리고 동시 개발이라는 같은 시작 선에서
위와 같이 프로세스 능력, 프로세스가 좋은 조직과 프로세스가 좋지 않은 조직을 비교하였습니다.
위에서는 총 결함 발견율을 척도로 하였지만, 폭스바겐의 사례에서는 아래의 6가지를 두고 비교 분석하였습니다.
(1) 복잡도, Complexity
(2) 식별된 결함 수와 복잡도, Defects Found vs. Complexity
(3) 문제의 심각도, Problem Severity
(4) 식별된 결함 수, Defects Found
(5) 결함 밀도, Defect Rate
(6) 릴리즈 횟수, Number of Release
프로세스가 좋지 않은 조직에서 복잡도 수치가 더 낮게 나온 경우를 제외하고, 프로세스가 좋은 조직에서 다른 평가 척도에서 우월하게 만족하는 결과가 나왔습니다.
프로세스가 좋지 않은 조직에서는 복잡도는 상대적으로 낮았지만, 식별된 결함 수는 더 많고 이를 해결하기 위한 추가 공수가 많이 들었습니다. 또한 1000 라인 당 결함 수가 훨씬 많았고 (결함 밀도가 높음), 심각한 결함도 많았습니다.
잦은 릴리즈도 추가 공수가 많이 들게 되었었고요.
글로벌 자동차 회사에서 확인한 사례라서 더 신뢰성 높은 결과 자료이기도 하고, 프로세스가 소프트웨어 품질을 높이는데 충분하게 기여한다는 점이 저는 참 마음에 들었습니다.
앞으로는 이러한 내용까지 포함해서 현업에서 프로세스 품질이 중요함을 알리도록 하겠습니다. (기쁜 마음으로요 ^^)
이상 읽어주셔서 감사합니다.
'소프트웨어공학 (Software Engineering)' 카테고리의 다른 글
| [ASPICE 핵심 컨셉#7] The relation between "Strategy" and "Plan" (0) | 2022.10.09 |
|---|---|
| [ASPICE 핵심 컨셉#6] "Evaluate", "Verification Criteria" and "Ensuring compliance" (0) | 2022.10.09 |
| [ASPICE 핵심 컨셉#5] "Agree" and "Summarize and Communicate" (0) | 2022.10.09 |
| [ASPICE 핵심 컨셉#4] Traceability (추적성) and Consistency (일관성) (0) | 2022.10.09 |
| [ASPICE 핵심 컨셉#3] 용어 "Element", "Component", "Unit", and "Item" (0) | 2022.10.09 |