ASPICE 기본 이론

MAN.3 관리 영역 파헤치기 1 (feat - Best Practice)

아즈마민초 2023. 12. 26. 17:55

이번 글은 MAN.3의 Base Practices를 가지고 실무에 적용한다는 느낌을 첨가하여 글을 쓸 것이다

 

BP1 업무 범위를 정의한다.

-  지난 번 https://undefined7.tistory.com/24 글에서도 작성하였지만 좀 더 구체적인 예시를 들어서 범위를 정한다는

것이 무엇을 정하는 것인지 예를 들어보겠다.

○ 개발될 제품의 정의 및 구현되어야 하는 기능을 정의 하는 것이다. (프로덕트 측면)

○ 고객에게 전달해야 하는 모든 산출물(deliverables)을 주요한 것 위주로 정리(프로덕트 측면)

○ 프로젝트의 성격(양산 목적인지, 선행 개발 목적인지) (프로젝트 측면)

○ 표준 준수(ISO26262, 사이버 보안(ISO21434), ASPICE) (프로젝트 측면)

○ Q,C,D(품질, 비용, 납기) 측면에서 성공적인 목표를 측정할 수 있는 지표(프로젝트 측면)

    예를 들어 ASPICE CL2, 월마다 최대 예산 사용, sample delivery deadline

 

좀 더 부가적인 설명을 하자면

프로덕트 측면인 것은 예를 들어 제품을 개발 할 때 기능의 구현 순서도 

주된 기능을 먼저 구현하고 부가적인 기능은 나중에 구현하는 것으로 개략적인 일정을 잡는다.

여기서 주된 기능과 부가적인 기능은 어떻게 나누냐? 주된 기능은 사용자가 직접 이용하는 기능 부가적 기능은 기능안전의 안전 메커니즘처럼 사용자가 직접적으로 사용하지는 않는 기능처럼 분류할 수도 있고

제품에 주된 기능 중에서도 고객이 뭐부터 구현해달라 하는 그런 요구사항이 있다면 그 기능을 먼저 구현해야 하고 혹은

개발 순서상 합리적으로 먼저 구현해야 하는 것을 정해야 할 수도 있다. 결국 핵심은 개발을 할 때도 우선순위를 먼저

정하고나서 개발을 하라는 것

프로젝트 측면의 것은 예를 들어 프로젝트 시작 시점에 개략적인 WBS를 짜는 것이 있을 수 있다. 물론 개발 일정이 지나면서 WBS는 점점 상세해지고 확고해지는 방향으로 업데이트가 되어야 한다.

 

BP2 프로젝트 수명주기 정의

- 에이스파이스를 접해보지 않은 사람들이 이 내용을 듣고선 뭔 수명주기 정의야? 폭포수 모델, 나선형 모델, 이런거 중에

우리가 무엇을 채택했냐? 이런 거를 쓰라는 건가? 이렇게 받아들이는 경우가 많다. 하지만 사실 이것을 뜻하는 것이 아니다. ASPICE는 형식적인 갖추라고 추구하는 표준이 아니다 실질적으로 표준에서 설명하는 하나 하나의 활동이 의미있는 행동이어야 한다. 그래서 BP2에서 말하는 프로젝트 수명주기를 정의하라는 것은 무슨 뜻이냐? 내부 외부 고객 모두에게 

회사의 프로세스가 어떻게 돌아가는지 알아야 그 프로세스를 따라서 일을 진행할 수도 있고 어느 시기에 어떤 행동을 해야 하는 지도 짐작할 수 있다. 그렇기 때문에 일반화된 프로젝트 수명주기 모델(폭포수, 나선형, V사이클, 애자일 등)을 대부분의 기업들이 자신들만의 프로세스로 채택하고 있다. 그렇다면 실무를 하고 있는 내부 및 외부고객의 입장에서 회사가 채택한 프로젝트 수명주기 모델을 봤을 때 어떤 생각이 들 것 같은가? → 이런 반응이 나올 것이다. "음 대충 프로젝트를 시작하면 프로세스가 어떻게 돌아가는지는 알겠어 근데 이 해당 모델에서 지금 우리가 하는 프로젝트의 업무들이 박혀있는게 보이면 업무를 하는데 훨씬 도움이 될 거 같은데?" 바로 이거다! 아주 좋은 반응이다. 무슨 모델을 채택했냐만 보여주는 것이 아니라 모델에 실제 임하고 있는 프로젝트의 이정표를 쭉 매칭하는 것이다 (물론 주요한 것들 위주로만 샘플 납기, 베이스라인, 마일 스톤 등)

 

 

BP3 프로젝트의 실현 가능성을 평가한다.

- 사실 이 작업은 수주를 하고 개발을 착수하기 전에 이루어져야 하는 활동이지만 현실적으로 무조건 수주를 해야

 기업이 사니 잘 이루어지지 않는 부분이다. 아무튼 이상적인 것은 그렇다는 것이고

여기서 실현 가능성을 평가해야 한다는 것은  비용 대비 수익, 기술적 구현 가능성에 대한 나름의 기준을 갖고 평가를 하라는 것이다. 즉 수주를 하는 회사 자체에도 이 프로젝트가 이윤이 남는지 여러 측면에서 고려를 하라는 것이고 고객을 위해 정말 기술적 측면에서도 이상 없이 구현을 할 수 있는지 프로젝트 초기에 평가를 하라는 것이다.

 

이번 글은 여기서 마치고 BP4 부터는 다음 글에서 연재하겠다.