Creative Commons License

MyLog

Personal Log
IT Log
Book Log
마음의양식
Note

제 삶의 자취를 남깁니다.

.

IT Log

개발자의 삶을 살아가면서 느끼는 지극히 개인적인 느낌이나 이슈를 남깁니다.

완벽하지 않은 요구사항

작성자 : 박종명
최초 작성일 : 2008-07-23 (수요일)
최종 수정일 : 2008-07-23 (수요일)
조회 수 : 2243

소프트웨어 개발에 대한 요구사항 이슈는 개발 초창기 부터 지금까지 쭈~~욱 , 사람들 입에 오르 내리는 것 같다.

그 유명한(?) '폭포수 개발 방법론'에서도 요구사항의 변화를 시스템에 반영하기 힘들다는 전제로 출발하고 있으며
요구사항 변화에 유연하기 위한 '반복 개발 방법론'인 'RUP 개발방법론','XP개발방법론' 및 '객체지향 개발' 등이
요구사항과 밀접한 관계가 있는 것만 봐도 '요구사항' 이라는 넘은 '기획-설계-개발-테스트-안정화-유지보수-확장'의
프로세스 전반에 걸쳐 아주 중요한 이슈꺼리가 된다.

흔히 개발자들은 요구사항의 변화를 무척(?) 싫어 한다.
기획,설계 단계에 요구사항이 여차여차 해서 승인이 나서 개발을 진행 중인데,
중간에 이러저러한 항목들이 '추가 요구사항' 이라는 얼굴로 쓸~적 들이밀려 올때면 개발자의 '짜증'도
같이 밀려온다. 

그러나 사실 이 요구사항이 것이 매번 정확히 모든 것을 예상하고 초기에 고정시키기 힘든 점이 많다.
중간에 새로운 아이디어가 나올 수 도 있으며 미처 생각하지 못한 중요한 결점이 있거나 비지니스의 성격이
중간에 변화된다던지 개발에 영향을 주는 기반 시스템의 변화가 있다던지... 등등 중간 요구사항의 변경은
어찌 보면 '귀엽게(?) 봐 줄수 밖에 없는 것' 으로 인정해야 할 필요도 있는 것 같다.

물론 '요구사항을 언제든 변경 할 수 있습니다' 라는 접근은 절대,Never .. 안 될 일이다.

아래는 스티브 맥코넬의 'RAPID Development' 라는 책에서 언급된 요구사항과 관련된 내용이다.

=====================================================================

개발자들은 사용자가 원하는 바를 모른다고 불평한다.
그러나 입장을 바꿔놓고 생각 해보자.
자동차 기술자에게 원하는 차를 자세하게 설명한다고 상상해보라.
엔진,몸체,창문,운전대,가속기 페달,브레이크 페달,비상 브레이크,좌석 등을 원한다고 기술자에게 전한다.
그렇지만 자동차 기술자가 차를 만드는데 필요한 모든 항목을 빠뜨리지 않고 말해줄 수 있을까?

차가 후진할 때 켜지는 후진등을 잊었다고 치자. 6개월 후, 기술자는 후진등이 없는 차를 완성해 보여준다.
"이런, 기어를 후진으로 바꾸면 후진등이 자동으로 켜져야 한다는 사항을 잊었습니다"

기술자는 버럭 화를 낸다.
"변속기에서 차 뒷부분까지 전선을 연결하는 데 얼마나 일이 많은지 아십니까? 차 뒷부분 패널을 다시 설계해야 하고 브레이크 등에 전선을 연결해야 하고, 변속기에 감지기를 더 달아야 합니다. 몇 달까지는 아니라도 몇 주는 더 걸립니다. 왜 처음부터 말하지 않았죠?"

간단한 요구 같은데, 할 말이 없다.

이해할 수 있는 실수다. 그렇지 않은가? 자동차는 비전문가가 명시하기에는 너무 복잡한 물건이다.
소프트웨어 제품 역시 복잡하다. 소프트웨ㅔ어를 명시하는 책임을 맡은 사람들이 전문가가 아닌 경우도 흔하다.
실제로 돌아가는 제품을 보고 나서야 자신들이 느끼기에는 간단한 사항을 생각해낸다.

- RAPID Development (스티브 맥코넬) 책 생명주기 계획 글 중에서...-

이름
비밀번호
홈페이지
QP <- 왼쪽의 문자를 오른쪽 박스에 똑같이 입력해 주세요