폭포수 모형을 기반으로 하는 구조적 개발 방법론에서는 요구 분석 단계에서 요구 사항들이 일단 명세화되고 나면, 이들은 단지 후속의 개발 단계를 위한 중간 산출물로만 사용되고 더 이상 요구 사항 자체를 관리 대상으로 취급하지 않기 때문에 설계 단계 이후에 발생하는 요구 사항의 변경을 관리할 수 있는 절차가 미흡하다. 그러나 현실적으로는 정보 기술의 발전, 시장 환경이나 적용 환경의 변화 등으로 인하여 개발 기간 중 요구 사항은 끊임없이 변화하게 된다. 따라서 이러한 요구 사항의 지속적인 변경을 지원하기 위해서는 전체 개발 생명 주기에 걸쳐 요구 사항을 관리하고 특히 설계 단계 이후의 요구 사항 변경을 지원할 수 있는 요구 사항 변경 관리 프로세스가 필요하다. 이 논문에서는 하향식(top-down)의 구조적 개발 방법론에 적용할 수 있는 요구 사항 변경 관리 프로세스 모델을 제안하여 설계 단계 이후에 발생하는 요구 사항의 변경을 체계적으로 관리하고 요구 사항 자체를 모든 개발 생명 주기에서 활용하기 위한 방안을 제시한다. 제안 프로세스는 마르미 방법론의 개발 프로세스와 산출물 측면의 적용 검토를 통하여 개발 방법론의 요구 사항 변경 및 관리에 대한 개선 효과를 평가한다.
폭포수 모형을 기반으로 하는 구조적 개발 방법론에서는 요구 분석 단계에서 요구 사항들이 일단 명세화되고 나면, 이들은 단지 후속의 개발 단계를 위한 중간 산출물로만 사용되고 더 이상 요구 사항 자체를 관리 대상으로 취급하지 않기 때문에 설계 단계 이후에 발생하는 요구 사항의 변경을 관리할 수 있는 절차가 미흡하다. 그러나 현실적으로는 정보 기술의 발전, 시장 환경이나 적용 환경의 변화 등으로 인하여 개발 기간 중 요구 사항은 끊임없이 변화하게 된다. 따라서 이러한 요구 사항의 지속적인 변경을 지원하기 위해서는 전체 개발 생명 주기에 걸쳐 요구 사항을 관리하고 특히 설계 단계 이후의 요구 사항 변경을 지원할 수 있는 요구 사항 변경 관리 프로세스가 필요하다. 이 논문에서는 하향식(top-down)의 구조적 개발 방법론에 적용할 수 있는 요구 사항 변경 관리 프로세스 모델을 제안하여 설계 단계 이후에 발생하는 요구 사항의 변경을 체계적으로 관리하고 요구 사항 자체를 모든 개발 생명 주기에서 활용하기 위한 방안을 제시한다. 제안 프로세스는 마르미 방법론의 개발 프로세스와 산출물 측면의 적용 검토를 통하여 개발 방법론의 요구 사항 변경 및 관리에 대한 개선 효과를 평가한다.
In conventional development methodologies, requirements are considered to be not changing after analysis phase, and requirements specifications are used for the next step system design purpose. But in the real world, requirements can be changed and modified throughout the development life cycle acco...
In conventional development methodologies, requirements are considered to be not changing after analysis phase, and requirements specifications are used for the next step system design purpose. But in the real world, requirements can be changed and modified throughout the development life cycle according to end-user's more understanding about the target system, new IT technologies, changes of customer environment and market situation, and so on. So there needs a requirements change management process that can extend requirements management over the entire development life cycle and can support managing changes to the requirements after design phase. In this paper, a requirements change management process that can be integrated into conventional development methodologies is proposed to support the extension of requirements life cycle and managing changes to the requirements after design phase. This process was evaluated through an verification test with a widely used development methodology‘MaRMI’.
In conventional development methodologies, requirements are considered to be not changing after analysis phase, and requirements specifications are used for the next step system design purpose. But in the real world, requirements can be changed and modified throughout the development life cycle according to end-user's more understanding about the target system, new IT technologies, changes of customer environment and market situation, and so on. So there needs a requirements change management process that can extend requirements management over the entire development life cycle and can support managing changes to the requirements after design phase. In this paper, a requirements change management process that can be integrated into conventional development methodologies is proposed to support the extension of requirements life cycle and managing changes to the requirements after design phase. This process was evaluated through an verification test with a widely used development methodology‘MaRMI’.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
그러나 현행 개발 방법론에 제안 프로세스와 비교 가능한 프로세스가 존재하지 않기 때문에, 여기서는 요구 사항 변경 관리 프로세스를 개발 방법론에 적용하기 위한 요건들을 조사하고 이에 대한 충족 여부의 확인을 통하여 제안 프로세스의 효율성을 평가한다.
따라서 이 논문에서는 요구 사항의 관리를 위한 요구 공학적 관점을 시스템 개발을 위한 개발 방법론에 통합 할 수 있는 요구 사항 변경 관리 프로세스 모델을 제안 하여, 하향식의 구조적 개발 방법론에 대한 요구 사항 변경 관리를 개선하는 방안을 제시하였다. 요구 사항 변 경 관리 프로세스는 먼저 요구 사항 관리를 위한 객체- 관계 모형과, 이 모형을 바탕으로 한 요구 사항 변경 관 리 절차와 활동, 그리고 산출물을 통하여 정의하였다.
제2장에서 살펴본 바와 같이, 개발 방법론에서는 요구 사항을 도출하고 분석하며 명세화하여 설계에 반영하는 절차와 방법을 제시하지만 설계 단계 이후의 요구 사항 변경은 지원하지 못하는 문제점이 있고, Volere 요구 사항 프로세스 모델을 비롯한 요구 사항 관리 모델과 요구 공학적 기법들은 요구 사항 자체에 대한 관리 방안만 제시하기 때문에 시스템 개발을 위한 기본 틀로 사용되는 개발 방법론에 적용하기 위해서는 별도의 절차와 노력이 필요하다. 따라서 이 논문에서는 폭포수 모형을 기반으로 하는 구조적 개발 방법론의 관점을 바탕으로 하는 요구 사항 변경 관리 프로세스 모델을 통하여 기존 개발 방법론에서 미흡한 요구 사항 변경 관리를 개선하는 방안을 제시한다.
이 논문에서는 요구 사항의 관리 범위를 확장하고 변경 관리를 개선할 수 있는 요구 사항 변경 관리 프로세스를 통하여 구조적 개발 방법론의 요구 사항 변경 관리를 개선하는 방안을 제시한다. 프로세스는 요구 사항 관리를 위한 객처)-관계 모형과 요구 사항 변경 관리 절차와 활동, 영향 범위 추적 모형, 그리고 산출물을 통하여 정의한다.
제안 방법
기본 설계 단계는 요구 분석 단계에서 파악된 요구 사항을 컴퓨터 시스템의 구현 관점에서 해결 방안을 결 정하는 단계로, 설계 작업의 진행 도중 발견되는 요구 사항의 문제점이나 사용자의 변경 요구 등을 지원하기 위하여 요구 사항 변경 관리를 실시하고 요구 사항을 보완한다.
더구나 이 논문에서 제안하는 요구 사항 관리 프로세 스는 개발 방법론적 관점을 바탕으로 하기 때문에, 제4.2 절에서 살펴 본 바와 같이 별도의 추가적인 절차나 적용 방안의 수립 없이도 폭포수 모형을 기반으로 하는 구조적 개발 방법론에 요구 사항 변경 관리를 직접 적 용할 수 있는 방안을 제공한다.
개발 계획 단계에는 사용(예정)자의 요구 사항을 수집 하여 상위 수준의 요구 사항 명세서를 작성한다. 따라서 요구 사항에 대한 변경 관리는 적용되지 않지만, 설계 단계 이후의 요구 사항 변경 관리에 필요한 산출물의 준비를 위하여 상위 수준의 요구 사항 명세서를 보완하여 요구 사항 기술서(개략)를 작성하고 요구 사항 관계 표를 추가한다.
간단한 프로세스의 경우에는 상세한 절차를 규정하기도 하지만, 좀 더 복잡한 프로세스의 경우에는 이를 적용하는 사람의 개인적 배경이나 기술 수준, 적용 환경에 따라 적용 방법이나 결과가 달라질 수 있으므로 상위 수준의 절차나 결과물만 규정한다. 따라서 이 논문에서는 요구 사항 변경 관리 프로세스를 설계하기 위하여 우선 요구 사항의 객체화와 관계 표시에 의한 관리 모형을 설정하고, 이를 바탕으로 요구 사항 변경 관리에 필요한 활동과 산출물을 정의한다.
설치 및 인도 단계는 단계 준비(D7100), 사용자 교육 실시(D7200), 시스템 설치(D7300), 설치 후 관리 (D7400), 단계 점검(D7500)의 5개 활동과 13개 작업으로 구성되어 있으나 마르미 방법론에는 요구 사항 관련 활동이나 작업이 정의되어 있지 않다. 따라서 전달물 검토 및 갱 신(D7404) 작업에서 향후 유지 보수를 위하여 지금까지 의 모든 요구 사항 변경을 정리하여 요구 사항 기술서 를 재 정립하고 요구 사항 기준선을 다시 설정하는 업 무를 추가하고, 산출물로 요구 사항 기술서(재정립)와 요구 사항 관계표(수정)를 추가한다.
요구 공학 분야와 개발 방법론 분야는 실제 시스템 개발 과정에서 발생하는 다양한 현상을 대상으로 하고, 특히 개발 방법론에서는 프로젝트의 규모와 성격, 특성에 따라 프로세스의 활동과 산출물의 조정을 전제로 한다. 따라서 제 3 장에서 설계한 요구 사항 변경 관리 프 로세스 모델에 대한 논리적 검증이나 계량화된 평가가 어렵기 때문에, 여기서는 현재 널리 사용되고 있는 개발 방법론에 대한 적용 검토를 통하여 프로세스 모델의 적 용성과 개선 효과를 평가한다.
일반적으로 요구 공학과 개발 방법론, 특히 프로세스 분야는 프로젝트의 규모와 특성에 따라 조정과 변형이 불가피하기 때문에 논리적 검증이나 계량화된 측정이 어렵고 실무적 경험과 지식을 필요로 한다. 따라서 제안 요구 사항 변경 관리 프로세스의 평가를 위하여, 대표적 개발 방법론의 하나인 마르미 방법론의 개발 프로세스와 산출물에 대한 적용 검토를 통하여 적용 효과를 분석한다.
요구 사항과 요구 사항 간의 관계는 요구 사항 추적 표를 사용하지 않고 개별 요구 사항에 하나의 속성으로 정의할 수도 있으나, 요구 사항의 변경 관리를 위해서는 추적 표 형식으로 기술하는 것이 바람직하다. 이 논문에서는 특히 요구 사항과 요구 사항 간의 관계를 정의한 요구 사항 추적표 를 요구 사항 관계 표라고 명명하여 다른 요구 사항 추 적표와 구분하기로 한다.
일반적으로 논리적 검증이 어렵고 실무적 경험과 지 식을 필요로 하는 개발 방법론과 요구 공학 분야의 특성을 감안하여, 제안 프로세스를 널리 사용되고 있는 개발 방법론의 하나인 마르미 방법론에 대한 적용 검토와 정보 시스템 개발 경험이 풍부한 정보처리 기술사 및 정보시스템 감리인에 대한 설문 조사를 통하여 평가하였다. 제안 요구 사항 변경 관리 프로세스는 설계 단계 이후의 요구 사항 변경 관리를 지원함으로서, 기존의 개발 방법론에서 미흡한 요구 사항의 변경 관리를 개선할 수 있다.
이론/모형
그런데 관리기법/1은 프로젝트 규모나 적용 대상 에 따라 다양한 개발 경로가 존재하기 때문에 어느 하나의 개발 경로에 대하여 대표성을 부여하기 어렵고, 정 보공학 방법론은 구조적 기법을 프로젝트 단위가 아닌 기업 전체에 대한 정보 전략의 관점으로 적용하고 데이 타 모델을 중심으로 분석과 설계를 진행하며 프로그램 의 자동 생성을 전제로 하여 프로세스 모델이 정교하지 않기 때문에 요구 사항 관리 프로세스의 적용 검토 대상으로 부적절하다. 반면, 마르미 방법론(마르미-D 기 준)은 전형적인 구조적 기법을 사용하고 ISO 12207을 기반으로 하며 각 단계별 활동과 산출물의 정의가 정형 화되어 있으므로 이 논문에서는 적용 검토의 대상으로 마르미 방법론을 선정한다.
요구 사항 기술서는 각각의 요구 사항에 대하여 작성하며, 비전문가인 사용자나 개발 참여자도 쉽게 이해할 수 있도록 가급적 자연어로 작성하고, 각각의 요구 사항을 하나의 관리 단위(객체)로 설정한다. 이 객체가 가지는 주요 속성은 Volere 요구 명세 템플리트나 관리기법/1의 '요구 사항 설명' 템플리트 등을 기준으로 프로젝트 의 성격이나 규모, 특성에 따라 조정할 수 있으며, 여기 에 변경에 따른 버전 부여와 버전별 간략한 변경 내용 기술 항목을 추가하여 향후 요구 사항 변경 관리, 특히 변경 이력 관리를 위하여 활용한다.
성능/효과
그리고 각 요구 사항별로 확인 및 검증 기준을 부여하여 개발 초기 단계부터 테스트를 시작할 수 있으며, 요구 사항으로부터 설계 및 구현으로의 추적 이 가능하고, 변경으로 인한 영향 범위 및 파급 효과를 분석하기 용이한 장점이 있다[18]. 각 요구 사항별로 변 경 이력을 유지하고 보안 수준을 설정하여 유지 보수와 보안성을 향상할 수 있으며, 객체의 속성으로 정의한 요 구 사항의 세부적 기술과 다른 객체와의 연결성 등을 통하여 요구 사항 자체의 완전성을 향상할 수 있다.
이러한 방법으로 제안 요구 사항 관리 프로세스를 마 르미 방법론에 적용하면, 기존의 각 단계별 활동이나 절 차를 변경하지 않고 단지 요구 사항 변경 관리 활동을 추가하거나 보완함으로써 쉽게 적용할 수 있고, 기본 설계 단계 이후에 대한 요구 사항 관리를 보완하며, 설치 및 인도 단계에서 요구 사항 기준선을 다시 설정할 수 있도록 요구 사항 관리의 개선이 가능하다.
일반적으로 논리적 검증이 어렵고 실무적 경험과 지 식을 필요로 하는 개발 방법론과 요구 공학 분야의 특성을 감안하여, 제안 프로세스를 널리 사용되고 있는 개발 방법론의 하나인 마르미 방법론에 대한 적용 검토와 정보 시스템 개발 경험이 풍부한 정보처리 기술사 및 정보시스템 감리인에 대한 설문 조사를 통하여 평가하였다. 제안 요구 사항 변경 관리 프로세스는 설계 단계 이후의 요구 사항 변경 관리를 지원함으로서, 기존의 개발 방법론에서 미흡한 요구 사항의 변경 관리를 개선할 수 있다.
하지만 대부분(86.4%)의 설문 응답자가 요구 사항 변 경 관리 모형이 개발 방법론 자체의 보완 및 적용 효과 제고에 도움이 될 것으로 예상하고, 90.9%의 설문 응답 자가 프로젝트 관리와 시스템 품질 향상에 도움이 될 것으로 예상하고 있기 때문에 전체적으로 이 논문에서 제안하는 요구 사항 변경 관리 프로세스가 개발 방법론 에서 미흡한 요구 사항의 관리를 개선하는데 효과가 있을 것으로 결론지을 수 있다.
후속연구
ISO 12207, 관리기법/1, 그리고 마르미 방법론과 같은 하향식의 구조적 개발 방법론에서는 공통적으로 파악된 요구 사항들을 각각의 관리 대상으로 설정하지 않고, 후속의 요구 사항 명세서나 설계서 작성을 위한 중 간 단계로 활용한다. 따라서 분석된 요구 사항 중에서 오류가 발생하거나 누락된 요구 사항이 발생할 경우, 후속의 개발 단계에서는 역으로 추적하거나 확인할 수 있는 원천 정보를 상실함으로써 검증 및 변경을 위한 근거를 잃어버리게 되는 문제점이 있다. 그리고 요구 분석이 완료된 다음에는 이후의 개발 기간 동안 요구 사항 자체를 관리 대상으로 취급하지 않기 때문에, 실제 프로젝트에 있어서 전체 개발 노력(비용)과 기간의 70 - 80% 이상[7, 9, 12]을 차지하는 나머지 개발 단계에서 발생할 수 있는 요구 사항의 변경을 체계적으로 수용할 수 있는 절차가 없다.
그러나 이 논문의 연구 범위에는 최근 프로젝트에 적 용이 확산되고 있는 객체 지향 개발 방법론과 관련된 연구가 포함되지 않고 제안 프로세스의 실증적 검증을 위한 실무 프로젝트 적용 시험이 미흡하였다. 따라서 향후 이 부분에 대한 추가적인 연구와, 실무 적용을 위하여 소요되는 노력과 비용 규모 평가, 그리고 요구 사항 자체의 품질 향상 방안에 대한 연구를 계속할 예정이다.
참고문헌 (23)
강기선, 김재선, 김종원, 홍태기, 박수용, '웹 기반 요구사항 관리도구의 구현', 정보과학회 가을 학술발표논문집, Vol. 26, No.2, pp. 531-533, 1999
이원우, 박수용, 류성열, '객체지향 어플리케이션 개발을 의한 UML 기반의 요구공학 프로세스', 제1회 한국소프트웨어공학 학술대회, pp. 165-172, 1999. 3.
교육용 교재 (컴포넌트기반 시스템 개발방법론 마르미-III 공개 발표 및 마르미 / 마르미-II 개발방법론 설명회), 한국소프트웨어산업협회, 2001. 8.
신종철, '요구 사항 변경을 지원하는 요구 공학 프로세스의 개선 모델', 충북대학교 대학원, 박사학위논문, 2002. 8.
NCA II-AUER-97095, 시스템 개발방법론 적용기준에 관한 연구, 한국전산원, 1997. 12.
TTA.KO-11.0002, 분석단계 소프트웨어 문서 작성지침, 한국정보통신기술협회, 1998. 12.
정통부 고시 2000-13호, 소프트웨어 사업 대가의 기준, 2000. 2. 8.
관리기법/1 오브젝트 샘플 (버전 9.5), 한국전산원
왕창종, 소프트웨어 공학, 정익사, 서울, 2000
James and Suzanne Robertson, 'Volere Requirements Specification Template', Edition 6.1, Atlantic Systems Guild, 2000
Arnold, Robert S., and Shawn A. Bohner, Software Change Impact Analysis, Reading, MA: Addison-Wesley, 1997
Ian Sommerville, Software Engineering, 6th Edition, Addison-Wesley, 2001
Suzanne and James Robertson, Mastering the Requirements Process, Addison-Wesley, 1999
Karl E. Wiegers, Software Requirements, Microsoft Press, 1999
Gerald Kotonya and Ian Sommerville, Requirements Engineering Process and Techniques, John Wiley & Sons, 1998
Michael Haug, Eric W. Olsen, and Gonzalo Cuevas, Managing the Change : Software Configuration and Change Management, Springer Verlag, 2001
Dean Leffingwell, 'Calculating Your Return on Investment from More Effective Requirements Management', Rational Software Corp. http://www.rational.com/products/reqpro/, 1997
Larry Boldt, 'Managing Requirements at the Object Level', Technology Builders Inc, http://www.tbi.com/products/asq/
Doc. #:01 WP0598, 'Requirements Management : The Foundation for Solving Common Development Challenges', Technology Builder Inc., http://www.tbi.com/products/asq/
Glenn Stout, 'Requirements Traceability and the Effect on the System Development Lifecycle (SDLC)', Nov. 29, 2001, http://www.stickyminds.com/
ANSI/IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, IEEE, NY, 1998. Reprinted in Software Requirements Engineering (2nd Edition), pp. 207-244, edited by Richard H. Thayer and Derlin Dorfman, IEEE Computer Society Press, Los Alamitos, CA, 2000
ANSI/IEEE Std 1233 (1998 Edition), IEEE Guide for System Requirements Specifications, IEEE, NY, 1998. Reprinted in Software Requirements Engineering (2nd Edition), pp. 245-280, edited by Richard H. Thayer and Derlin Dorfman, IEEE Computer Society Press, Los Alamitos, CA, 2000
※ AI-Helper는 부적절한 답변을 할 수 있습니다.