소프트웨어공학 (Software Engineering)

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

깡또아빠 2022. 10. 9. 23:10

해당 글은 ASPICE Annex D. Key concepts를 참고하여 작성되었습니다.


개발하면서 다양한 리스크가 존재합니다. 여러 프로젝트에서 공통적으로 나타나는 리스크에서 없어지지 않는 하나가 의사소통, 공유인 것 같습니다.

 

만들어진 작업 산출물에 대한 REVIEW가 완료되면 관련 이해관계자가 해당 내용을 인지하고 있어야 합니다. 이 부분을 위에서 말씀 드린 의사소통, 공유라고 말씀 드리는 것입니다. 

 

ASPICE에서도 이러한 부분이 현실적으로 나타나는 공통의 리스크인 점을 알고서 핵심 컨셉 5번째로 활동을 요구하고 있습니다. 

 

V 모델 왼쪽 편 (Left side)에서는 "Communicate agreed", "합의한다"라고 말하고,

V 모델 오른쪽 편 (Right side)에서는 "Summarized communicate", "요약하고 의사소통한다"라고 말합니다. 

 

한 단계 더 붙여서 말씀 드리면

"Communicate agreed"는 "합의된 프로세스 별 작업 산출물을 의사소통한다" 입니다. 

"Summarized communicate"는 "결과를 요약해서 의사소통한다" 입니다.

* 테스트 케이스 별 수행 결과를 의사소통하기 보다는 요약한 결과를 공유하라고 하는 구나! 이해하시면 됩니다.

 

프로젝트에서는 여러 정기 미팅 Regular meeting, 이벤트 미팅이 있습니다. 

정기 미팅에서 내부적으로는 주간 Weekly meeting을 많이 이용해서 의사소통, 공유를 할 것입니다. 

 

Capability level 1 (Performed)에서는 의사소통을 했다는 성과가 있으면 됩니다. 

 

Capability level 2 (Managed)에서는 Project management plan에서 의사소통 계획이 포함되어 있어야 합니다. 

예를 들면 내부(Internal), 외부(External) 미팅이 어떻게 있고, 어떤 주기 (예: weekly, on the event 등)에 따라 의사소통하며, 참석자는 어떤 담당자들이 포함되어야 하며 조치사항들이 계획되어 있어야 합니다. 

* ASPICE 셀프 스터디 하면서 느끼는 부분은 제가 속했던 조직에서는 기본적으로 Managed, 즉 레벨 2의 프로세스를 가지고 있는 것 같습니다. (그 이상은 얘기하지 않겠습니다)

 

Capability level 3 (Established)에스는 의사소통 전략과 방법이 조직 차원에서 프로세스로 정의되어 있어야 합니다. 

* 이래서 한 단계, 단계를 밟아야 하겠구나 싶네요.

 

 

의사소통 한다. 공유한다. 라는

간단할 수도 있지만 잘 지키지 못하는 부분들을

표준적으로 프로세스에서 이렇게 해석하고 정리하고 요구하는 것이 참으로 재밌네요. 

 

또 한번 참 할일이 많구나 / 재밌겠다 싶었습니다. :)

 

이상 읽어주셔서 감사합니다.