Software Engineering Theory in Practice

Software Engineering Theory in Practice IEEE June 2005

모든 프로젝트의 원인은 만능이라고 생각하는 특정 소프트웨어 개발론의 신봉이다. 개발 방법론이 heavy할 경우에는 delay의 원인이 될 수도 있다.

Heavy Software 개발 방법론은 다음과 같은 프로젝트에서는 사용될 수 없다.
간단하고, 작은 프로젝트,
현존하는 제품의 새 버젼
legacy SW의 유지보수
비용이 적은 프로젝트
빠른 시간내에 나와야 하는 프로젝트
요구사항이 없는 프로젝트

요구사항이 없는 프로젝트의 경우는 고객으로부터, 또는 시장으로부터 요구사항을 꺼집어 내어야 한다.

이런 내용으로 구성되어 있다.

"은 총알은 없다"라는 말이 문득 떠올랐다. 하나의 총알으로 모든 것을 다 잡을 수는 없다라는 말이다.
나는 개인적으로 카메라를 좋아한다. 펜탁스의 istD라는 DSLR, 렌즈 교환식 카메라를 사용하고 있다. 모든 것을 렌즈 하나로 해결할 수 없다는 사실을 안다. 그리고, 광각이나 망원이냐에 따라서, 날씨가 좋냐, 나쁘냐, 실내에서 쓰냐 안쓰냐에 따라서, 쓰는 렌즈가 달라지고, 렌즈에 따라 달라지는 색감과 AF능력까닭에 상황에 따라서 사용하고 있다.

즉, 개발 환경은 상황에 맞춰 그에 맞는 프로젝트 개발 방법론을 사용하는 것이 좋다는 것이다. CMM 레벨의 내용을 따라하다가, 문서만 만들다가 시간이 촉박여서 밤을 새기 보다는 필요한 것만 정리하며 개발에 착수하여 기간내에 고품질의 제품을 만들어내는 것이 가장 우선순위가 높은 것이다.

또한 데모와 같은 작업을 하는 데에서 가장 문제가 되는 것은 요구사항이 없다는 것이다. 해당 당일날 그제서야 원하는 기능이 없다며 문제를 왜 얘기하지 않았냐는 것은 요구사항이 빨리 나오지 않았거나, 의사소통의 부재일 것이다.
요구사항이 가장 먼저 나오고, 의사소통을 통해서 확실히 하는 것이 가장 빠르고 안전한 길인데도, 왜 이렇게 제대로 하지 않는 것일까??

내가 관리자가 되면, 일처리 하나만큼은 잘 할 것이다!. 실력도 함께 말이다.