경험으로 배운 프로젝트관리에 붙여

지금까지는 프로토타입을 적용했던 프로젝트가 C/S환경에서였다. 그러나 필자가 프로토타입을 웹 개발 프로젝트에 적용하면서 많은 변화가 있었다. 프로토타입의 정의부터가 C/S에서와 다르게 나타났다. 프로토타입은 HTML로 제작된 페이지를 의미한다. 즉 기능적으로 많은 로직이 구현될 웹 어플리케이션에서 프로그램은 하지 않고 단지 HTML로 만 페이지를 제작하여 전체적으로 흐름을 보여주고 필요한 플로우를 미리 검증을 받는 기능을 가진다. 디자인 부분은 완전히 배제하고 메뉴와 화면의 필요한 구성요소에 치중하였다.

문제는 웹 디자이너와 함께 프로토타입을 제작하자고 하면 대부분이 어려워서 하지 못하겠다고 하는 것과 스토리보드를 먼저 제작하지 않고 페이지를 만들어야 하는 부분을 개발자나 디자이너 모두 하기 싫어 한다는 것이다. 이러한 문제는 새로운 변화를 시도하면 항상 발생하는 문제로 몇 번 하다고면 친숙해 질 것이라고 하면서 일을 하게 되었다.

하여튼 모든 페이지 구조를 HTML로 제작하고 나서 화면을 캡쳐 받아 'UI정의서'에 넣는 방식으로 진행을 하였으며, HTML을 통해 고객에게 전체적인 흐름과 상세 화면에 나타날 항목에 대해서 확인을 받았다. 문서보다 친숙한 화면을 통해 보면서 고객의 이해도가 빨랐으며, 프로젝트 진행 도중에 들어오는 팀원들의 프로젝트 이해도 또한 아주 빠르다는 것을 확인했다.

프로토타입을 확인받은 후 스켈레톤으로 확장하였다. Skeleton 즉 '뼈'의 의미와 같이 프로그램의 뼈대를 세우는 것을 의미한다. 프로젝트에서는 MVC를 이용한 프레임웍을 사용하였으며, 1차 Skeleton은 JSP에서 Class를 부르는 부분까지 제작하였고, class는 JSP가 call하는 클래스만 제작하여 클래스 내부에는 아무것도 없이 필요한 값을 가지고 있다가 리턴하여 JSP에서 뿌려줄 수 있게 제작하였다. 2차 Skeleton에서는 JSP --> business class --> DB DAO 클래스까지 연결하는 전체 클래스를 작성하였으나 DAO에서 직접 DB에 연결하지 않고 DAO가 가짜 값을 가지고 있다가 Return하는 방식으로 처리하였다.

위의 방식을 통해 배운 것은 DB의 변경이 잦은 어플리케이션의 특성상 DB변경이 일어나면 소스코드의 수정이 많아 지는 것을 미연에 방지할 수 있었다 는 것과 게시판과 같이 DB연결에 전적으로 의존하는 프로그램은 Skeleton 1차가 필요없이 2차로 가는 것이 더 편리하고 빨랐다는 것이다.. DB는 2차 스켈레톤이 완성된 후 물리적으로 구현하여 나머지 개발을 수행하였다.

먼저 위의 방법을 통해 나타난 장점은 다음과 같다.
- 모든 클래스의 모습이 나타난 후 DB를 확정함으로써 문서를 통한 설계에서 발견하기 어려웠던 관계 테이블까지 DB확정시에 나타나 그 후 별 다른 수정이 없었다는 것이다.
- 고객의 이해도와 프로젝트 도중에 들어온 개발자들의 이해도가 문서를 통할 때 보다 엄청나게 빠랐다는 것이다.
- 문서보다 필요한 개발을 먼저함으로써 문서를 어려워하는 개발자들도 쉽게 문서화에 참여를 했다
- 처음에 Skeleton을 위해 투입되었던 중, 고급 개발자가 Skeleton 2차 이후에는 별 다른 참여가 없어서 초급으로도 충분히 프로그램 완료가 가능했으며, 중급 1명이 남아 초급이 제작한 나머지 부분을 검토하는 방식으로 진행해도 별 다른 문제가 없었다
- 처음에 많은 부분이 완성됨으로써 나중에 지연되는 현상이 완전히는 아니지만 많은 부분 사라졌다.

다음은 단계별로 적용방식을 정리 한 것이다.

- 요구분석 단계: 프로토타입의 완료
- 기본설계서 단계: Skeleton Version 1완료, 인터페이스 확정
- 상세설계서 단계: Skeleton Version 2완료, Public 메소드 확정 및 DB확정
- 개발 단계: Skeleton Version 2의 실제 메소드 구현, 주로 Private 메소드 확정 및 완성