발의된 시스템 개발 프로젝트에서 이러한 RV 위험 요소들을 인지하는 것은 그 결과로 파생되는 프로젝트 관리 위험들을 관리하는데 도움이 될 수 있다. 특히, 이러한 위험을 인지하는 것은 COBIT의 계획 및 조직 도메인(PO: Plan and Organize) 내의 PO9 프로세스인 ‘IT 위험 진단 및 관리’에서와 같이 IT 위험을 진단하는데 도움이 될 것이다. 다음 장에서는 RV 위험에 대한 대응과 그의 관리를 논할 것이다.
RV 위험 관리 메소드
RV는 통제할 수 없으며 프로젝트 매니저의 영향을 벗어난 것으로 여겨지는 위험이다. 6 비록 모든 RV를 통제할 수 없을지라도, 모두를 관리할 수는 있다. 프로젝트 매니저는 시스템 목적을 달성하는데 중요치 않은 요구사항 변경을 거절할 수 있고, 막을 수 있는 RV에 대한 원인을 없애는 개발 환경을 조성할 수 있고, 그리고 즉흥적 요구사항을 안고 일을 하는 개발 메소드를 활용할 수 있다. 끝으로, 그러한 메소드들이 실행 가능하지 않는 프로젝트일지라도, 설계, 개발 그리고 구현 과정에서 RV와 필연적인 변경을 관리하는 메소드만은 필수적이다. 다음 장에서는 RV 위험을 관리하는 메소드를 논하고자 한다.
RV 거절
RV를 관리하기 위한 가장 간단한 제안은 요구사항을 동결시키고 변경 요구를 거절하는 것이다. 그렇지만, 그러한 변경이 이루어지지 않으면 사용자가 시스템을 거절할 수도 있기 때문에, 아마 그 방법은 많은 상황에서 비현실적이다. 부연하면, 요구사항을 변경하지 않을 경우에는 예상 시스템 개발 이익을 달성하지 못할 수 있다. 자신보다 높은 지위의 프로젝트 이해관계자들에 의해 통제되는 시스템에서는 프로젝트 매니저가 RV를 예방할 수 없을 것이다. 그럼에도 불구하고, 프로젝트 매니저는 필수 요구사항과 그냥 유용하여 있으면 좋은 요구사항을 분리할 수 있고 그리고 비필수적인 요구사항을 동결할 수 있다. 그렇지만, 시스템 목적 달성에 중요치 않은 경우라면, 프로젝트 매니저가 요구사항 변경에 대한 거절과 비필수적인 요구사항의 즉흥성을 예방하기 위한 권한을 가져야 한다.
즉흥성을 피할 수 있는 원인 제거
앞 장에서 초기에는 요구사항들이 불분명하였다가 개발 과정에서나 표출되는 정보시스템 안에서 독특하고 차별화된 비즈니스 프로세스들 같은 위험 요소들이 논의되었다. 그런 즉흥성을 다루는 해결 방안은 커다란 이익을 주지 못하는 독특하고 차별화된 비즈니스 프로세스들을 비전략 시스템 안에서 배제시키는 것이다. 그러한 경우는 비즈니스 프로세스를 표준화해서 수용하는 것이 (위험을) 완화시키는데 더 좋다. 그러한 독창적인 프로세스를 피하는 것이 불가능하다면, 요구사항을 정확하고 완전하게 확인하기 위하여 프로세스 전문가를 동참시켜야 한다.
신기술 및 현행 기술의 무경험에 따른 즉흥성은 요구사항 정의 프로세스에 기술 컨설턴트를 참여시킴으로써 감소시키거나 회피할 수 있다. 추후 변경될 소지가 있는 부정확하고 불완전한 요구사항을 피하기 위하여서는 개발팀 내에 애플리케이션 영역에 지식을 갖춘 사용자 및 개발자를 포함시켜야 한다. 애플리케이션에 대한 사용자의 불충분한 지식으로 인한 즉흥성은 개발팀에 프로세스 전문가를 둠으로써 균형을 맞출 수 있다.
다양한 기능에 대한 사용자의 부적절한 표현에 기인한 RV는 각 기능을 대표하는 적당한 사용자들을 참여시킴으로써 최소화할 수 있다. 개발팀 안에 안정적인 개발자 및 사용자를 참여시키는 것은 지속성을 확보할 수 있으며 새로운 팀원이 들어와 생기는 요구사항 변경을 회피할 수 있다.
구조적 요구사항 정의 메소드는 요구사항을 문서화하고 관리할 때에 유용하다. 또한 이런 메소드는 앞으로 있을 요구사항 즉흥성을 피하기 위하여 요구사항을 정확하고 완전하게 수정하는 경우에도 효과적이다. 검사, 검토 그리고 워크스루 작업을 이용한 요구사항의 확인 및 검증은 요구사항을 올바르고, 일관성있고 그리고 완전하게 보증할 수 있으며, 그러한 작업들은 후속 개발 공정에서 요구사항에 대한 변경을 회피하는데도 도움을 줄 수 있다.
즉흥성을 갖고서 작업하는 메소드를 이용
전략적 시스템이나 신기술과 연관된 RV는 거부하거나 회피할 수 없다. 그러한 시스템에 알맞는 적당한 요구사항 수집 및 개발 메소드들을 이용하는 것이 보다 현명하다. 신속 애플리케이션 개발(RAD: rapid application development) 및 민첩 개발(agile development) 같은 반복적 메소드들은 RV를 갖고 하는 시스템 개발에 유용한 것으로 밝혀졌으나, 이러한 메소드도 대형 시스템 개발에 대해서는 아직 검증되지 않았다. 이러한 경우에, 프로토타입으로 반복 개발될 수 있고, 그리고 요구사항 정의 과정에서 명확한 요구사항을 이끌어내는데 사용될 수도 있다. 프로토타입과 파일럿 프로젝트는 전략 시스템이나 신기술 적용 시스템의 요구사항 즉흥성을 해소하는데 유용하다. 개발자들이 신기술에 대한 경험이 많지 않다면, 요구사항을 확인하는데 컨설턴트나 프로세스 전문가들을 동참시켜야 한다.
앞선 3개 섹션에서 토론한 메소드들은—RV 위험을 거부하거나, 제거하거나 혹은 받아들이고 일하는 메소드들— COBIT 도메인 PO 안에 통제목적 PO 10.9 ‘프로젝트 위험관리’와 일치한다.
즉흥성과 그 영향을 관리
RV는 개발 비용 및 시간을 늘이게 됨으로써 요구사항의 구현은 신중하게 관리되어야 할 필요가 있다. 요구사항 변경의 부정확한 구현은 보다 많은 즉흥성과 비용을 초래할 것이다. 변경 관리 시스템은 다른 요구사항 및 시스템 목적뿐만 아니라 비용 및 일정에 관한 변경 요구에 대한 영향도 인식하는 것이 필수적이다. 커다란 영향을 미치는 변경은 사용자 부서의 상위 책임자 및 프로젝트 스폰서가 소속된 위원회에 의해 승인을 받을 필요가 있다. 현재의 변경 관리 메소드들은 주로 설계 및 코드 작성에 초점을 맞추고 있지 요구사항에 대하여는 거의 그렇지 못하다. 구조적 요구사항 정의 메소드들은 하나하나의 요구사항을 시스템 (개발) 목적을 거슬러서 추적하고, 그리고 요구사항 변경의 영향을 시스템 목적 위에서 결정하는데도 도움이 될 수 있다.
최고 경영자의 참여(commitment)가 프로젝트 성공의 가장 중요한 요건이다. 최고 경영자의 지원은 사용자들간에 그리고 관련 즉흥성을 관리하는데 있어서 발생하는 논쟁을 해결하는데 필수적이다. 프로젝트 자체와 프로젝트 매니저 모두는 요구사항 변경을 다루고 그리고 RV 관리 메소드를 이용하는데 있어서 최고경영자의 지원 및 참여를 확보해야 한다. 요구 변경사항의 구현을 관리하기 위한 이러한 메소드들은 COBIT의 구매 및 구현(AI: Acquire and Implement) 도메인에 속한 AI6 ‘변경 관리’ 프로세스에 잘 묘사되어 있다.
그림 2는 RV 위험을 관리하는데 사용될 수 있는 메소드들을 요약한 것이다.
|
그림 2 – 요구사항 즉흥성 위험을 관리하기 위한 메소드 |
|
일반 메소드 |
# |
요구사항 즉흥성 위험 관리 메소드 |
|
요구사항 즉흥성을 거절 |
1 |
요구사항을 동결하고 즉흥성을 거절 |
|
피할 수 있는 원인을 제거 |
2 |
비전략적 시스템 내에서 유일한 프로세스들을 회피 |
|
3 |
기술 컨설턴트를 활용 |
|
4 |
프로세스 전문가를 활용 |
|
5 |
모든 기능에 적당한 설명을 달도록 보증 |
|
6 |
구조적 요구 정의 메소드를 활용 |
|
7 |
낮은 교체를 가진 안정적 개발팀을 보유 |
|
즉흥성을 안고 작업하는 메소드 이용 |
8 |
요구사항 분석으로 파일럿 프로젝트와 프로토타입을 활용 |
|
9 |
반복적 개발 메소드를 활용 |
|
즉흥성과 그 영향을 관리 |
10 |
변경관리시스템을 활용 |
|
11 |
논쟁 해결 메소드를 활용 |
|
모든 시스템 개발 프로젝트의 성공에 필수적인 요소들 |
최고 경영자 참여
충분한 권위를 가진 프로젝트 매니저
요구사항에 대한 확인 및 검증
애플리케이션 영역에 대한 지식을 갖춘 사용자/개발자 |
시스템 개발 프로젝트를 이행하기 전에, 프로젝트 매니저는 앞장에서 논의되고 그림 1에 요약되어 있는 다양한 RV 위험을 확인해야 한다. 프로젝트에 대한 RV 위험 요소에 따른, 그림 3에 나타나 있는 적당한 위험 관리 메소드를 채택하여야 한다. 최고경영자의 참여를 확보하는 것, 프로젝트 매니저가 충분한 권한을 갖는 것, 요구사항을 확인하고 검증하는 것, 그리고 프로젝트에 해당 애플리케이션 분야에 대해서 박식한 사용자 및 개발자들을 참여시키는 것과 같은 관리 메소드는 모든 형태의 시스템 개발에 필수적인 우수 실무라는 것을 제발 깨닫기 바랍니다.
|
그림 3 – 요구사항 변덕성 위험을 관리하는 가이드라인 |
|
만약 제안된 정보시스템 프로젝트가 … 이라면 |
그러면 이러한 메소드들을 채택하라 (숫자는 그림 2에 표시된 번호임) |
|
요구사항 변덕성을 거절 |
회피가능한 원인을 제거 |
변덕성을 지닌 작업을 하기 위한 메소드를 활용 |
변덕성과 그 결과를 관리 |
|
본래 전략적인 것이라면 |
|
3,4,5,6,7 |
8,9 |
10,11 |
|
신규 기술을 채택하는 것이라면 |
|
3 |
8,9 |
10 |
|
개발자들이 충분한 기술 경험을 갖고 있지 않다면 |
|
3 |
8 |
|
|
사용자들이 기술 지식이 부족하다면 |
|
|
8,9 |
|
|
대형 프로젝트라면 |
|
7 |
|
10 |
|
복잡한 프로젝트라면 |
|
6 |
9 |
10 |
|
유일하고 차별화된 비즈니스 프로세스를 보유하고 있다면 |
|
2,4,6 |
|
10 |
|
사용자들이 애플리케이션에 대한 부적절한 지식을 가지고 있다면 |
|
2,4 |
|
|
|
개발자들이 애플리케이션에 대한 부적절한 지식을 가지고 있다면 |
|
|
8,9 |
|
|
많은 부서/기능을 포함하고 있다면 |
|
5,7 |
|
10,11 |
|
불안정한 팀에 의해 수행되면 |
|
7 |
|
|
|
빡빡한 프로젝트 스케줄이라면 |
1 |
|
9 |
10 |
|
중요치 않은 요구사항에 대한 변경 요청을 받는다면 |
1 |
|
|
|
프로젝트 매니저와 정보시스템 개발자들은 일반적으로 RV로 인한 위험을 인식하고 있지만, 다른 프로젝트 이해관계자들은 다양한 RV 위험과 이러한 위험들이 갖는 함의를 인식하지 못할 것이다. 7 프로젝트 매니저는 위험 관리 차원에서 RV 위험을 프로젝트 이해관계자들에게 전달하고 교육시킬 책임이 있다. 프로젝트 매니저와 정보시스템 개발 부서장은 비즈니스 프로세스 오너, 시스템 설계자, IT 운영자 그리고 정보시스템 감사 및 통제 그룹과 협력하여 RV 위험을 확인하고 평가할 책임을 공유한다. 또한 PM과 개발 부서장은 이러한 위험을 관리하기 위한 메소드를 확인하고 구현할 수행책임과 총괄책임이 있다. 역시, 프로젝트 프로세스로써, 프로젝트 매니저는 CIO 및 CFO 에게 RV 위험 관리와 위험의 영향을 프로젝트 산출물로 계속해서 알려줄 책임이 있다.
결론
이 글에서 논의된 가이드라인은 자체 인력에 의한 시스템 개발 프로젝트의 RV 위험뿐만 아니라 그 밖의 다른 위험들을 관리하는데도 도움이 된다. 예를 들어, 새롭고 유일한 비즈니스 프로세스들은 비전략적 시스템들에서 빠져야 한다. 왜냐하면, 그러한 프로세스들은 RV를 발생시킬 뿐만 아니라 수반되는 이익은 없으면서 더 많은 개발 비용을 초래할 것이기 때문이다.
외주 프로젝트는 요구사항 즉흥성에 대하여 추가적인 위험 요소를 갖고 있다. 예를 들면, 시간 및 인력 계약으로 맺은 외주 프로젝트는 고정 가격 계약과 비교해서 더 높은 즉흥성 위험을 지닌다. 이것은 벤더들이 수입을 늘이기 위하여 프로젝트의 범위를 확장시키려 하는데 기인할 것이다. 세계적인 외주 프로젝트들은 거리 및 시간에 따른 사용자와 개발자들이 떨어져 있음 그리고 언어 및 문화의 차이로 인한 의사소통의 장벽으로 인해서 더 많은 RV위험을 갖게 된다. 이런 유형의 프로젝트들은 추가적인 RV 위험 관리 메소드를 필요로 한다.
Endnotes
1 Lamswede, A.; “Requirements Engineering in the Year 00: A Research Perspective,” Proceedings of the 22nd International Conference on Software Engineering (ICSE 2000), ACM Press, Ireland, 2000
2 The Standish Group, “Extreme CHAOS,” USA, 2001
3 Molokken, K.; M. Jorgensen; “A Review of Surveys on Software Effort Estimation,” IEEE International Symposium on Empirical Software Engineering (ISESE 2003), Italy, 2003
4 Thakurta, R.; F. Ahlemann; “Understanding Requirements Volatility in Software Projects—An Empirical Investigation of Volatility Awareness, Management Approaches and Their Applicability,” 43rd Hawaii International Conference on System Sciences (HICSS 2010), USA, 2010
5 IT Governance Institute, COBIT 4.1, 2007, www.isaca.org/cobit
6 Tiwana, A.; M. Keil; “The One-Minute Risk Assessment Tool,” Communications of the ACM, vol. 47, issue 11, 2004
7 Op cit, Thakurta
Sachidanandam Sakthivel, Ph.D.
is a consultant in IT outsourcing and information systems development methods. Sakthivel has published numerous articles in leading international journals. He has also presented numerous articles at international conferences and is a member of the Association for Computing Machinery (ACM) and the Institute of Electrical and Electronic Engineers (IEEE).
HOME > 커뮤니티 > 서평 & 번역물
