* 초반에 프로세스를 수립해야 하는 이유.
(출처:소트트웨어 프로젝트 생존전략 - 개인적으로 필요한 내용을 정리하는 곳입니다. 문제 발생시 해당 글은 삭제 조치하도록 하겠습니다.)
- 변경 통제(Change control):
프로젝트 수행도중, 고객, 매니져가 다향한 변경을 요청하는 경우가 많음.
팀원들은 이행에 동의하지만 프로젝트 후반까지 이러한 변경을 체계적으로 통제하지 않는다면 업무 범위는
늘어날것이고, 그에 따른 예산과 일정도 늘어난다.
- 품질 보증(Quality assurance):
프로젝트 초반에 결함 제거 프로세스를 확립하지 못하면, "Test - debugging- 재작업- 재시험" 을 계속 반혹하는
악순환에 빠진다.
프로젝트 종반에 많은 결함이 보고 되기 때문에 결함 정정 우선순위를 정하느라 정신이 없고, 알려진 결함도
우선순위에 따라 해결하지 않은채 릴리즈가 된다.
최악으로는 릴리즈 할만한 수준도 안되는 case 발생
- 무분별 개정(Unconrolled revisions):
프로젝트 후반에 발견된 중대한 결함으로 테스트중에 소프트웨어 재설계 및 재 코딩할 수 있는데 이는
전혀 계획되지 않았기 때문에 원래 계획과 동떨어지게 되서 계획을 재 수립하거나 통제가 할 수 없는 지경에 이를 수
있다.
- 결함추적(Defect tracking):
결함추적에 대한 계획 미수립시 후반까지도 결함추적으로 수행하지 못할 가능성이 크다. 그리고 그러한 사실을
놓치고 결함이 있는 상태로 릴리즈되어 불안정한 SW가 나가게 된다.
- 시스템 통합(System Intergration):
각기 다른 개발자가 개발한 컴포넌트들에 대한 Merge에 대한 계획이 수립되지
못했다면 후분에 이를 통합시 많은 시간과 노력이 들어가게 되어 계획이 차질이 생긴다.
- 자동화된 소스코드 통제(Automated source code control):
소스코드에 대한 통제등이 잘 이뤄지지 않는다면 나중에 원본을 오버라이트 한다던가 삭제하는등, 시간과 노력이
많이 들어가는 불필요한 일들이 생기게 된다.
- 일정 관리(Scheduling):
일정이 지연되면 개발자들은 할일이 많아지고, 일주일에 한번이상 가증하면 자주 남은 작업이 얼마나 남았는지
재추정해야 한다. 이는 개발 시간도 없는데 불필요한곳에 시간을 또 소요한다.
. 형상관리툴, Bug Tracking, 일정관리, 개발 설계등 우리가 뻔히 알고 있는 내용이다..
하지만 알고 있는것 조차 잘 진행되지 않는 경우가 다반사....
정보는 공유되어야 한다 쭈욱~
댓글