Archive for the ‘추정’ tag
소프트웨어 공학의 사실과 오해 2 – 추정
http://www.yes24.com/24/goods/1418676
추정
프로젝트가 폭주하는 가장 흔한 원인 두 가지 중 하나가 형편없는 추정이라고 한다. (다른 하나는 불안정한 요구사항)
소프트웨어 공학 분야에서는 이런 폭주의 원인이 무엇일까에 대한 질문이 자주 있었다. 이 질문에 대한 대답은, 답하는 사람의 개인적인 주관에 기초하는 경우가 많았다. 어떤 사람들은 적절한 방법론의 부재가 폭주를 야기한다고 말한다. 이런 사람들은 보통 방법론을 파는 사람들이다. 어떤 사람들은 좋은 도구가 없기 때문이라고 말한다(이런 사람들은 무엇으로 먹고 사는 사람들일까?). 어떤 사람들은 프로그래머에게 훈련과 주의가 부족하기 때문이라고 말한다(보통 이런 사람들이 옹호하고, 판매하는 방법론들을 사용하기 위해서는 많은 훈련이 필요하다). 각자 그들이 지지하는 개념을 제시하며 그 개념의 부족이 프로젝트 폭주의 원인이라 주장한다.
p.60
많은 주장들이 결국은 자기들 돈벌려고 하는 얘기라는 것. 그나마 아무에게도 이익을 줄 것 같지 않은 객관적인 대답이 “형편없는 추정”과 “불안정한 요구사항”이란다.
마지막으로 다시 한번 상식적으로 생각해보자. 우리가 앞에서 논한 것처럼 부적절한 시점에 부적절한 사람에 의해 만들어지고 잘 변경되지 않는, 정말 그렇게도 부적절한 소프트웨어 추정이라면, 상대적으로 덜 중요하게 다뤄질 것이라 생각되지 않는가? 틀렸다! 사실 소프트웨어 프로젝트는 거의 항상 일정에 의해 관리된다. 그 때문에 적어도 고위 경영진은 소프트웨어(개발)에서 일정을 가장 중요한 요소로 생각한다.
p.76
두번째 문장에 엄청난 함축이 있다. 우선 추정은 부적절한 시점에 수행되고 있다. 보통 프로젝트를 시작할때 소프트웨어 추정을 하는데, 이 때는 풀고자 하는 문제가 무엇인지도 명확하지 않은 단계이다! 무엇을 만들지도 모르면서 비용과 시간을 추정하는 셈이다.(p.66)
다음으로 추정은 부적절한 사람에 의해 수행되고 있다. 대부분의 경우 소프트웨어 추정은 소프트웨어 제품을 원하는 사람들, 즉 경영진이나 마케팅, 고객, 사용자들에 의해 이루어진다(p.69)
마지막으로 이렇게 잘못된 추정은 프로젝트가 진행되면서 거의 조정되지 않는다.(p.73)
일정에 의한 관리대신에 사용할 수 있는 방법이 몇 가지 제시되고 있다.(p.77)
- 제품에 의한 관리 : 사용 가능한 정도, 어느 정도 작동하는가에 의해 프로젝트의 성공/실패 판단
- 이슈에 의한 관리 : 프로젝트 도중에 발생하는 이슈를 얼마나 잘 해결하는 가에 의해 프로젝트의 성공/실패 판단
- 위험요소에 의한 관리 : 위험요소가 적절히 해결되었는지를 통해 프로젝트의 성공/실패 판단
- 비즈니스 목표에 의한 관리 : 비지니스 능률을 얼마나 향상시켰는가에 따라 프로젝트의 성공/실패 판단
- 품질에 의한 관리 : 제품의 품질 속성을 얼마나 많이 달성했는가에 따라 프로젝트의 성공/실패 판단
솔직히 일정에 의한 관리 방식을 버린다는 게 막막하기만 하지만, 저번 글에서 얘기한 것처럼, 단순히 가로등 밑이 밝다는 이유로 가로등 밑에서 열쇠를 찾고 있었던 것은 아닌지 생각해 봐야겠다.