Baseline, Release

오늘은 위와 관련하여 간단하게 일부분 내용을 기록해봅니다.

 

System A를 X, Y, Z라는 컴포넌트로 구성되어 있다고 가정하면,

X, Y, Z를 구현하고, 인테그레이션, 검증 및 확인을 통해서 System A를 납품하게 되겠죠.

 

최종 납품 또는 정해진 마일스톤(Milestone)까지 Baseline 3번으로 가정하겠습니다.

해당 Baseline은 릴리즈를 위한 시점으로 생각해주세요. 위 예시는 그러한 의미로 작성하였음을 말씀 드립니다.

 

X, Y, Z를 한번에 탁 하고 내놓으면 좋겠지만, 현실은 그렇지가 않죠. 

UDS (Unified Diagnosis Specification) 진단 통신 하나 개발하려고 해도, 주고 받는 Request ID, Response ID 정의하고, Session 별로 어떤 SID (Service ID)를 고려해야 할지, 어떤 DID (Data ID)를 정의하고 읽을지, 어떤 Flow로 서비스를 수행할 지 등.. 등.. 여러 상황별 요구사항을 정의해야 합니다.

 

그런 과정을 한번에 구현해 낼 수 없으니 저희는 계획(Plan)을 짜서 프로젝트를 수행해야 합니다.

 

Baseline1까지 개발해야 하는 목표와 범위가 있을 거에요. 그러한 부분을 고려해서 정의를 해야 합니다.

반면에 Z의 컴포넌트는 의존성(Dependency)를 가지고 있다고 한다면 Baseline1에서는 구현을 하기 어려울 것입니다.

 

그러면 위 설명한 내용으로 그림을 업데이트 해보면 (Y 컴포넌트를 X와 동일하다고 가정)

 

Baseline 1까지 목표로 한 X, Y 컴포넌트가 V1로 설정되었습니다. 

버전을 표기하는 방법은 다양합니다. 각 조직에서 프로젝트에서 정의한 방법대로 수행하시면 됩니다.

(예를 들면 X.xx --> X은 Major 버전, 중요 마일스톤을 의미, xx은 마이너 버전 업데이트 순서를 의미)

 

Baseline 2, 또는 Release 2 시점에 가서 계획과 달리 X 컴포넌트는 추가된 부분이 없고, Y 컴포넌트만 업데이트가 되는 경우, 그리고 아직 Z 컴포넌트는 시작하지 못한다고 한다면 아래 그림과 같이 될 거에요.

 

제가 말씀 드리고 싶었던 부분은 계획을 정의할 때 세분화 해야 한다는 것입니다.

프로젝트 상위레벨 (예: 고객 마일스톤, 내부 마일스톤)에서 정의된 일정을 내부적으로 개발(요구사항, 구현, 검증)하기 위해서는 세부 계획으로 쪼개야 합니다. 

 

Z 컴포넌트를 위에서 보게 되면 Baseline 2까지는 개발을 할 수 없었던 부분인데, 이를 고려하지 않고 Baseline1부터 포함시켜서 진행한다고 하면, 정작 필요로 우선적으로 작업해야 하는 컴포넌트 또는 Task를 놓치고 갈 수 있고, 관리의 목적이 무의미할 수 있을 것입니다.

 

각 Release 또는 Baseline 별로 개발해야 하는 범위와 Maturity 를 고려하여 개발을 하셔야 합니다.

(그래도 삐걱삐걱 하는게 프로젝트이니까 말이죠)

 

개인적인 얘기지만, 저는 어제보다 오늘을, 오늘보다는 내일이 궁금하고 재밌는 하루와 내일이기를 바랍니다.

이론적이다. 현실적이지 못하다 라고 생각하시기 보다는 조금씩이라도 오늘을 바꿔보시기를 그래서 조금이라도 달라진 내일이기를 희망합니다.

 

읽어주셔서 감사합니다.