요구사항 3

요구사항 변경에 대처하는 개발자의 자세

프로그램 개발에서 요구사항 변경은 피할 수 없는 운명과도 같다. 피한다고 피할 수도 없고, 그렇다고 당당하게 마냥 즐길 수도 없는 그런 존재이다. 프로젝트는 요구사항, 일정 그리고 인력 자원으로 시작한다. 최종 산출물은 당연히 훌륭하게 작동하는 소프트웨어다. 보통 일정과 인력 자원은 변경이 없으니, 흔들리는 요구사항에 따라서 흔들리는 것은 소프트웨어다. 보통의 클라이언트들은 요구사항을 계속 추가하고, 기존 요구사항을 자꾸 변경한다. 변경된 사항에 따른 일정 조절이나 추가 인력 자원 투입은 불가한 경우가 많으니 결국엔 요구사항에 충실하지 못한 소프트웨어가 나오고 만다. 예전에는 어떻게 요구사항을 고정할지에 대한 이야기를 했고, 요즘에는 어떻게 변경되는 요구사항에 맞출까를 많이 이야기한다. 처음 막연한 구상..

MS의 응용 프로그램 라이프사이클 관리 솔루션

MS의 VS는 2005를 거치면서 단순 IDE에서 Team Foundation Server를 통해 Application Lifecycle Management 툴로 진화하기 시작했습니다. 당시만 해도, 역시나 1.0이어 그런지 여러 부분이 조잡한 천처럼 부드럽지 못 한 부분이 있었는데, 이제는 많은 부분에서 개선을 이뤄낸 것 같습니다. 이 자료는 MS가 준비한 ALM에 대한 설명입니다. http://www.microsoft.com/visualstudio/ko-kr/solutions/management 아래는 "04.ALM-Tool-Evolution-v2-Chappell.pdf"에 들어 있는 개발 과정의 구성입니다. 관리해야 할 것은 "요구사항", "디자인 문서", 그리고 "소스 코드"이고, 품질을 보증하는..

요구사항과 품질, 그리고 변화관리

시스템엔 2가지 종류가 있습니다. 사용할 수 있는 시스템과 사용할 수 없는 시스템이요. 간혹 비극적으로 시스템은 개발과 릴리즈 초기부터 사용할 수 없는 시스템이 되곤 합니다. 사용자의 요구사항을 반영하지 못 했거나, 품질이 너무 낮아서 그렇죠. 운영중인 시스템도 사용자와 업무의 변환에 대응해 가면서 품질이 낮아지거나 변화에 대응하지 못해 뒤쳐져 기능 제한으로 점점 사용할 수 없는 시스템이 되어 갑니다. 엔트로피 증가의 법칙이 시스템에도 그대로 적용되는 것이죠. 그래서 프로젝트는 요구사항과 품질, 그리고 변화관리에 집중해야 합니다. 요구사항에 부합해야 하고, 품질은 어느 수준 이상으로 보장되어야 합니다. 그리고 끝없는 변화를 따라가면서도 요구사항 만족과 품질 확보를 달성해야 합니다. 그래야 쓸 수 있는 "..

반응형