소프트웨어 개발 일정 결정하기
소트웨어 생명 주기 모형과 현실의 차이
이론
"소프트웨어 공학"을 보면 소프트웨어 생명 주기 모형에 대해 나열되어 있다.
개발자가 선택할 수 있는 대표적인 개발 방법이나 유형을 몇 가지 모형으로 정리되어있다.
제일 전통적이고 보편화된 폭포수 모형(Waterfall Model)
폭포물이 흐르듯 순차적으로 한 단계씩 완벽하게 수행하고 다음 단계로 넘어가는 개발모형이다. 전통적인 방법으로 많이 쓰이고 이미 지나간 단계를 역행해서 넘어갈 수는 없다.
개발 순서
타당성 검토-계획-요구분석-설계-구현(코딩)-시험(검사)-유지보수
프로토타입 모형(Prototype Model)
고객 요구사항에 따라서 시제품을 만들고 지속적으로 개발 방향을 확인하는 개발 방법.
시간은 오래 걸리지만 고객의 요구사항을 정확하게 구현할 수 있고 동일한 거 같으면서도 유사한 작업을 개발자는 계속 수행한다.
개발 순서
타당성 검토-계획-요구분석*-설계-구현(코딩)-시험(검사)-유지보수
요구분석* 에서 프로토타입이 적용되며 아래의 단계가 반복된다. "요구 수집-설계-프로토타입 구현-고객 평가-프로토타입 조정 -구현 (-필요시 다시 요구 수집부터)
나선형 모델 (Spiral Model)
Boeham 이 제안, 폭포수와 프로토 타입의 장점과 위험 분석 기능을 추가한 모형
개발 순서
계획 및 정의-위험 분석- 공학적 개발-고객 평가 (*필요한 만큼 반복)
가장 현실적이지만 유지보수가 없다. 최신 기법이라 예시(레퍼런스)가 드물다.
등등이 있다는데... 현실은 다르다.
현실
현실은 고객이 마감일을 알려 주면 마감일까지 끝내야 한다. 생각보다 그 마감일이 실제 업무 완료일보다 촉박하다. 예를 들어 프로젝트 C를 개발해 달라고 의뢰가 들어왔는데 사전에 A랑 B 프로젝트 개발 일정이 확정되어 있고 그 사이에 약간의 공백이 있어서 C 프로젝트를 진행하려고 한다. 개발에 필요한 시간을 일차적으로 분석해보니 약 30일인데 업체에서는 급하다고 20일 만에 완료해 달라고 요청한다. 이러한 가상의 상황이 발생되기도 한다.
개발 방식을 골라서 개발하기보다는 보통은 폭포수 모형의 일부분인 "요구사항 분석 - 개발"로 진행된다. 최악의 경우에는 기계에서 프로그램 디버깅을 못하고 물건이 먼저 현장(최종 사용자)에 설치된 이후에 디버깅하는 경우도 있다. 실제 최종 사용자에게 납기 하는 일정보다 부품 납기나 조립 일정이 딜레이 되어 일정이 촉박해지는 경우도 비일비재하다. 또는 프로그램을 버전별로 관리하여 초반에는 기본 기능만 되도록 설치하고 추후에 추가 기능(옵션)을 넣은 프로그램을 설치하여 원하는 요구사항으로 개발한다.
열악한 환경에서, 효율적으로 개발하려면 어떻게 해야 할까.
