안녕하십니까.
12월들어 눈. 비가 오는 날이 많았는데 오늘도 여전히 날씨가 안 좋군요.
오늘은 계속 미루던 제품 개발의 절차와 각 단계에서 고려되야 할 사항들에 대하여 간단히 말씀을 드려 보고자 합니다. 먼저 제품개발의 순서는 개발하는 곳 마다 세부적으로 다를 수 있고 , 또한 어떻게 해야 된다는 정형화 된 절차도 없기 때문에 아래의 내용은 참고로만 하시기 바랍니다.
제품개발은 SW 개발이라는 부분과 제품의 기획 그리고 마케팅 등과 같은 회사의 부서들과 연결해 보면 대체로 아래와 같은 절차를 밟게 될 것 같습니다.
1. 제품 기획
2. 요구사항분석
3. 설계
4. 구현
5. 테스트
6. 출시
*7. 유지보수
8. 업그레이드 기획 --> 다시 1. 번으로 또는 단종처리
아래는 각 단계별 대략적인 설명입니다.
1. 제품기획
이 단계에서는 최종 산출물은 제품 기획서입니다. 기획서의 주요 내용은 다음과 같습니다.
Market : 기획의 대상이 되는 제품이 속해 있는 시장 및 규모
Customer : 대상 고객의 분석
Feature : 제품의 주요 기능
Cost : 개발비용과 제반 경비
Price : 가격 정책
Launching Plan : 제품 런칭 계획
*RoadMap : *필요시 제품 로드맵
위의 사항들외에도 상황에 따라 4P, STP 등의 마케팅 전략들이 들어갈 수 있겠습니다.
이 단계에서 제품 개발에 필요한 일정과 리소스가 대략적으로 정해 집니다. 문제는 제품 RoadMap 상의 일정과 개발팀의 운용 일정이 맞지 않을 수 있고 , 제품의 기능에 대한 상호간의 충분한 이해가 안 될 수 있습니다. 그렇게되면 원하는 일정에 제품이 안 나오거나 기능이 다른 원치 않는 제품이 될 수도 있습니다.
또 개발을 하다보면 검토되지 않았던 부분에서 기술적인 문제가 발생 할 수도 있습니다.
이런 문제점들에 대하여 제품과 연관된 각 팀은 기획이 완료되기 이전에 충분한 커뮤니케이션이 이루어 져야 합니다. 특히 이러한 커뮤니케이션상의 문제 해결과 여러 기술적인 문제들에 사전 검토를 위하여 CTO를 중심으로한 기술위원회를 운용할 수도 있을 것입니다.
제품 기획과 연관되는 팀으로는 영업, 제품기획, 마케팅, 개발, 디자인, QA, PM, CTO, CEO, 기술지원, 고객지원 등 회사의 거의 전 부서가 다 해당이 되기 때문에 부서간의 이해관계가 얽히는 이슈가 발생하는 경우에는 이러한 커뮤니케이션에도 시간이 많이 걸릴 수 있습니다. 빠른 진행을 위해서는 사내에 커뮤니케이션을 위한 별도의 인프라를 구현해 두는 것이 좋을 것입니다.
제품기획 단계를 거치게 되면 프로젝트 관리자가 정해지게 됩니다.
2. 요구사항 분석
이 단계의 최종 산출물은 SRS 와 개발계획표가 될 것입니다.
개발계획표는 저번 글에서 알려드린데로 WBS 기반으로 또는 별도의 방법으로 Time Table 형식으로 작성을 하게 됩니다. SRS에는 너무 많은 부분이 언급이 되기 때문에 전체를 열거하기는 어렵습니다만 대체로 다음과 같습니다.
- 개요
프로젝트 목표/프로젝트 범위/개발의 범위/수행의 범위/문서규칙/정의 및 약어/관련문서
대상 및 읽는 방법/프로젝트 산출물/산출물 형태 및 명칭/특허 출원 유무 및 내용
- 제품
전체 설명/제품 조망/전체 시스템 구성/전체 동작방식
제품 주요 기능 ( 제품의 기능리스트 )/가정과 종속 관계/하위 호환성(BACKWARD COMPATIBILITY)
- 환경
운영(설치) 환경/Hardware, Software 환경/제품 설치 및 설정/배포 환경/마스터 구성/배포 방법/
업그레이드 방법/형상관리/산출물 위치/소스 위치/문서 위치/빌드 환경/버그트래킹/기타 환경
- 인터페이스
외부 인터페이스 요구사항/사용자 인터페이스/하드웨어 인터페이스/소프트웨어 인터페이스/
통신 인터페이스/기타 인터페이스
- 성능
THROUGHPUT/CONCURRENT SESSION/RESPONSE TIME/성능 종속 관계/기타 성능 요구사항
- 기능 이외의 다른 요구사항
안정성 요구사항/보안 요구사항/소프트웨어 품질 특성/다국어 지원/유니코드 지원/64BIT 지원/
제품 인증/FIELD TEST/기타 요구 사항
- 제품 기능 상세
대분류 기능/ 중분류 기능/소분류 기능
몇가지만 설명드리겠습니다.
요구분석 단계에서 가장 중요한 부분은 기능에 대한 명세를 작성하는 것일 것입니다.
위에 보시면 기능에 대하여 두군데에서 언급을 하고 있는데 첫번째는 비개발자들이 기능에 대하여 이해할 수 있는 영역입니다. "제품" 항목에 들어 있는 기능이지요. 평이한 언어로 이해하기 쉽도록 사용자(고객)의 관점에서 기능의 목적과 이용방법 실행결과등을 기술합니다. 두번째는 아래의 "제품 기능 상세" 입니다. 여기서는 입력되는 값의 범위와 오류처리 방법등의 방식으로 명세 형태로 기능을 나타냅니다.
다음으로 개요에 보시면 특허 출원 유무가 있습니다.
제품의 기능중에서 별도의 시스템 또는 기술로 분류하여 특허로 만들어 두게 되면 향후 이 기술에 대한 적극적 권리 보호가 됩니다. 이것이 왜 SRS에 들어가야 하는지에 대한 의문이 생기실 것인데 제품으로 출시가가 되고 난 뒤에 기술특허 출원을 하게 되면 종래의 기술로 분류되어 특허가 등록이 안 될 가능성이 많기 때문입니다.
그리고 출원 및 등록에 비용이 발생하게 되며 , 해외 출원을 고려한다면 상당한 금액이 되기 때문에 개발계획에 이 부분이 반드시 포함됩니다. 특허 진행 여부를 사전에 밝히는 것이지요.
다국어지원 같은 경우 우리나라에서 제작이 되는 SW이므로 기본적으로 한국어를 지원하겠지만 영업상황에 따라서는 해외 전용 SW를 제작하는 경우도 있고 , 전세계 대상 제품을 만들 수도 있습니다. 지원이 되어야 할 언어의 종류에 따라서 번역, 감수 등의 비용이 발생하고 일정에 영향을 미치기 때문에 개발 계획전에 확정을 해야 합니다.
업그레이드방법이란 이 제품이 기존 제품의 업그레이드인 경우 또는 대체 제품인 경우 어떻게 할 것인가를 정해야 합니다. 예를들어 버전이 3.0 신제품이라면 기존 1.0 부터 3.0 이전의 버전 제품들을 어떻게 할 것인가 이지요. 1.0 제품은 2.0으로 업그레이드 한 후에 3.0으로 업그레이드 한다. 등과 같은 업그레이드 방법입니다. 그리고 한가지더는 제품의 온라인 업그레이드를 지원하는 지 여부를 밝혀 둡니다. 이런 지원이 되려면 다시 업그레이드 서버의 구성등이 추가되게 됩니다.
요구분석 단계에서는 매우 중요한 이슈를 다루기 때문에 각 부서의 담당자들이 매우 민감해 질 수 있습니다. 특히 이 단계에서 PM은 커뮤니케이션에 주의해야 합니다.
SRS에 한 줄이 추가되면 엄청난 일들이 벌어지기도 하기 때문입니다. ( EAL4 CC인증 같은 것. )
요구분석이 끝나게 되면 각 부서는 개발에 필요한 일정을 산출하여 개발 계획을 작성하게 됩니다.
보통 연관 부서가 많기 때문에 일정 조절에 많은 노력이 들어가게 됩니다.
설계, 구현 , 테스트는 다음으로 미루겠습니다.
댓글 없음:
댓글 쓰기