• 한국정보과학회논문지:소프트웨어및응용
• /
• 제32권12호
• /
• pp.1164-1177
• /
• 2005

현재 소프트웨어 개발 공정이 복잡해짐에 따라 개발하는 소프트웨어의 요구사항 역시 복잡해지고 있으며 요구사항 관리에 많은 노력이 소요되고 있다. 그러나 소프트웨어의 요구사항을 처음부터 모두 정의하는 것은 사실상 불가능하며, 개발이 진행되면서 환경은 변하기 마련이다. 또한 요구사항 변경은 개발보다 많은 비용이 소요되므로 체계적인 변경 관리를 통해 변경에 민첩하게 대응하고 관리되어야 한다. 본 논문에서는 소프트웨어 프로덕트 라인에서 요구사항 변경 관리 프로세스를 기반으로 체계적인 요구사항 변경 관리 방법을 제시한다. 소프트웨어 프로덕트 라인(software product lines)에서 어플리케이션의 요구사항은 도메인 요구사항과 밀접하게 관련되어 있으므로 어플리케이션 공학(application engineering) 단계에서 요구사항 변경이 발생했을 경우 도메인 공학(domain engineering) 단계를 이용하여 변경을 분석하고 관리하는 방법을 제시한다. 이러한 일관된 변경 관리를 통해 변경 범위를 분석하고, 변경 대처방안을 제시함으로써 변경 처리 결정을 내리는데 도움을 주며 한번 요청된 변경이 완벽하게 처리되도록 도와주어 같은 변경의 반복 요청을 막을 수 있기 때문에 잠재된 변경 비용을 절약할 수 있다.

• 한국전자거래학회지
• /
• 제12권3호
• /
• pp.33-47
• /
• 2007

소프트웨어 개발 초기에 모든 요구사항을 정의하는 것은 불가능하기 때문에 요구사항은 소프트웨어 개발이 진행되는 동안에 지속적으로 변경된다. 이러한 요구사항 변경은 개발자가 소프트웨어 구조나 행위를 완벽하게 이해하지 못하거나 변경에 따라 영향을 받는 모든 부분을 식별할 수 없을 경우 많은 오류를 야기 시킨다. 그러므로, 조직의 비즈니스에 공헌하면서 비용 효과적으로 적절히 처리되기 위하여 요구사항은 관리되고 평가되어야한다. 본 논문은 가치분석을 통하여 생성된 휘처 기반의 요구사항추적 링크를 근간으로 하는 요구사항변경 관리 기법을 제안한다. 이는 사용자 요구사항과 산출물간의 연결을 분석하기 위하여 휘처를 중간 매개체로 활용한 추적 링크를 이용한다. 그리고, 요구사항 변경 요청을 휘처 단위로 상세화하기 위한 변경 트리 모델을 정의하고 변경 관리가 수행되는 전체적인 프로세스를 제시한다. 또한, 요구사항 변경 관리 기법을 자산관리포탈시스템에 적용한 사례의 결과를 기술한다.

• 한국정보과학회논문지:소프트웨어및응용
• /
• 제30권5_6호
• /
• pp.503-514
• /
• 2003

폭포수 모형을 기반으로 하는 구조적 개발 방법론에서는 요구 분석 단계에서 요구 사항들이 일단 명세화되고 나면, 이들은 단지 후속의 개발 단계를 위한 중간 산출물로만 사용되고 더 이상 요구 사항 자체를 관리 대상으로 취급하지 않기 때문에 설계 단계 이후에 발생하는 요구 사항의 변경을 관리할 수 있는 절차가 미흡하다. 그러나 현실적으로는 정보 기술의 발전, 시장 환경이나 적용 환경의 변화 등으로 인하여 개발 기간 중 요구 사항은 끊임없이 변화하게 된다. 따라서 이러한 요구 사항의 지속적인 변경을 지원하기 위해서는 전체 개발 생명 주기에 걸쳐 요구 사항을 관리하고 특히 설계 단계 이후의 요구 사항 변경을 지원할 수 있는 요구 사항 변경 관리 프로세스가 필요하다. 이 논문에서는 하향식(top-down)의 구조적 개발 방법론에 적용할 수 있는 요구 사항 변경 관리 프로세스 모델을 제안하여 설계 단계 이후에 발생하는 요구 사항의 변경을 체계적으로 관리하고 요구 사항 자체를 모든 개발 생명 주기에서 활용하기 위한 방안을 제시한다. 제안 프로세스는 마르미 방법론의 개발 프로세스와 산출물 측면의 적용 검토를 통하여 개발 방법론의 요구 사항 변경 및 관리에 대한 개선 효과를 평가한다.

• 한국정보과학회:학술대회논문집
• /
• 한국정보과학회 1998년도 가을 학술발표논문집 Vol.25 No.2 (1)
• /
• pp.623-625
• /
• 1998

시스템의 변경은 개발 주기의 전 과정 가운데 지속적으로 발생하게 되고, 변경이 발생하면 연관된 다른 요소에 영향을 미칠 뿐 아니라 다음 주기에까지 그 영향이 전달되기 때문에, 개발 초기의 요구공학 주기의 산출물인 요구사항명세서로부터 추적과 관리가 시작되어야 한다. 본 논문에서는 요구사항의 관리를 위해 요구사항 관리 모델을 제안하고, 요구사항 관리 계층을 중심으로 요구사항의 저장, 변경사항의 관리 및 추적을 처리하며, 이를 기반으로 이후 프로젝트 관리와 관련된 작업들을 어플리케이션 계층에서 처리하도록 지원하였다. 또한 이 모델이 효율적으로 컴퓨터를 이용한 공동작업(Computer Supported Cooperative Work: CSW)에 활용 가능하도록 웹을 통해 구현한다.

• 한국재난정보학회:학술대회논문집
• /
• 한국재난정보학회 2023년 정기학술대회 논문집
• /
• pp.165-166
• /
• 2023

BCMS의 변경관리에 대한 요구사항은 ISO 22301 구성체계의 기획단계인 6.3 변경의 기획에서 수행하고, 기업재난관리표준 구성체계에서 기획단계인 3.5.5 문서화된 정보에서 수행하도록 규정하였으며, 이는 모두가 P-D-C-A 운용 모델의 Plan 단계에 해당된다. 이러한 구성체계는 BCP를 최초에 수립하는 단계에서는 적합하지만, BCP가 수립(제정)되어 운용단계에서 발생되는 변경사항을 처리하는데는 많은 문제점이 도출된다. 따라서 재난 및 안전관리 분야에 해당하는 유사제도의 요구사항을 대상으로 비교분석을 통하여 도출된 개선방안을 연구결과로 제시하고자 한다. BCP를 수립하는 과정에서 발생하는 보완사항은 변경관리 절차에 포함하지 않고, BCP가 수립되어 운용단계에서 발생되는 변경사항만 변경관리 절차에 포함하여 관리하며, P-D-C-A 운용 모델의 Act 단계에서 수행하는 것이 적합하다.

• 정보처리학회논문지D
• /
• 제17D권4호
• /
• pp.271-282
• /
• 2010

소프트웨어 프로젝트의 실패요인 중 54%가 요구사항관리 미흡에서 발생하며, 이중 22%는 요구사항 변경관리에서 기인한다. 따라서 실패요인을 줄이기 위해 요구사항 관리활동이 중요하며 이중 요구사항 변경을 위한 핵심활동으로 추적기법을 활용한다. 추적기법에 사용되는 방법인 추적테이블은 단순링크 방식으로 사용이 간편하고 가독성이 있으며 추적의 정확성이 높은 장점이 있다. 그러나 기존 추적테이블 연구는 변경관리 방법 및 추적의 효과를 구체적으로 제시하고 있지 않으며, 또한 변경영향 추정연구는 추정방법이 복잡하여 실용성에 한계가 있다. 이에 본 연구는 기존에 연구된 추적테이블을 이용하여 변경요구사항을 관리하는 방법을 제시하고 이로 인해 변경율 및 변경영향도를 기존 연구에 비해 용이하게 추정할 수 있는 기법을 제안한다. 또한 15개 프로젝트를 대상으로 추적테이블의 효과를 가설 검정하여 추적테이블이 프로젝트 성공에 영향을 미치며, 요구사항 관리미흡으로 인한 실패요인을 감소시킴을 확인한다.

• 한국정보과학회:학술대회논문집
• /
• 한국정보과학회 2002년도 봄 학술발표논문집 Vol.29 No.1 (B)
• /
• pp.445-447
• /
• 2002

최근 국내 기업들은 S/W Process심사를 통하여 기업의 Process수준 향상과 개발 제품의 품질을 향상시키고자 하는 관점에서 CMM, SPICE와 같은 표준에 많은 관심을 보이고 있다 이러한 표준들에서는 소프트웨어 품질 향상을 위만 기반으로 요구사항 관리를 중요시하고 있다. 많은 기업들이 요구사항을 추출하여 분석하고, 관리하는 방안에 대해 관심을 가지고 적용하고 있다. 요구사항 관리는 요구사항 개발, 변경 및 연계성과 관련된 모든 활동을 포함한다. 즉, 상호적이고 협력적인 공정을 통해서 요구사장을 추출, 분석하고 분석된 결과를 문서화하고, 요구 사항들 간의 연계성을 설정 관리하고, 변경 사장을 관리해야 한다. 본 논문에서는 요구사항추출 단계에서부터 개발 완료 시점가지 요구사항을 관리하는 소프트웨어 요구사장 프로세스를 제안하고, 이를 적용한 사례를 제시한다.

• 인터넷정보학회논문지
• /
• 제22권3호
• /
• pp.59-66
• /
• 2021

이 연구에서는 소프트웨어 개발 과정에서 소프트웨어 시스템의 품질을 높이기 위해 요구사항에 대한 추적성 관리 및 변경 관리를 체계적으로 수행하는 요구사항 모니터링 방법을 제안한다. 이를 위해 산출물 간 연관 관계를 정의하기 위한 추적 매트릭스와 개별산출물들에 대한 변경 관리를 체계적으로 수행하기 위한 산출물 변경 이력 관리 모델을 제시한다. 또한 특정 산출물이 변경될 때 연관된 산출물에 변경이 파급되는 상황을 쉽게 파악할 수 있도록 하는 시각적 대시보드도 제안한다.

• 한국정보과학회:학술대회논문집
• /
• 한국정보과학회 2004년도 가을 학술발표논문집 Vol.31 No.2 (2)
• /
• pp.484-486
• /
• 2004

CMMI는 조직의 역량 성숙도를 향상시키기 위한 소프트웨어 프로세스 개선(SPI) 모델이다 CMMI의 단계적 형태(Staged Representation)의 2레벨을 획득하기 위해서 요구되는 요구사항 관리 프로세스 영역은 요구사항에 대한 협의 확정(Commitment) 활동을 포항하고 있다. 요구사항 관리 프로세스 영역은 이전에 협의 확정된 요구사항이 필요한 경우 변경이 가능하도록 허용하고 있는데, CMMI와 같이 프로세스 중심적인 모델에서 이러한 변경 가능성은 협의 확정 사항의 무한정 확대(Escalation of Commitment)와 같은 문제점을 야기할 수 있다. 본 논문에서는 SPI학계에서 사용되는 협의 확정에 대한 정의를 살펴보고, 이 정의를 CMMI에 적용함으로써 요구사항 관리 프로세스 영역의 협의 확정을 수행하는 활동에서 발생할 수 있는 문제점을 해결하기 위한 방안을 제시한다. 협의 확정의 개념은 Brown에 의해서 정의된 속성(1)과 Meyer에 의해서 제안된 형태(2)를 적용하여 정성적이고 정량적인 관리가 가능할 수 있다. 이를 통하여, 요구사항의 협의 확정에 대한 체계적인 관리가 가능해질 수 있다.

• 정보처리학회논문지D
• /
• 제14D권6호
• /
• pp.641-648
• /
• 2007

요구사항이 빈번히 변경되는 동적 비즈니스 시스템 프로젝트를 확정가로 개발할 경우, 개발과정에서 발생하는 요구사항의 변경에 따른 추가 소요 비용으로 인해 확정가 범위 이내로 개발을 완료하는 것은 거의 불가능하다. 확정가 범위 이내에서 성공적으로 프로젝트를 완료하기 위해서는 요구사항 변경 규모와 이에 기반하여 개발이 되지 않아도 되는 옵션 요구사항의 비율을 관리하여야 한다. 이에 대해 Bhagwat는 요구사항 변경이 구축단계에서만 발생한다고 한정하였다. 또한, 소프트웨어 개발비용, 구축단계 소요 비용과 요구사항 변경에 소요되는 추가 비용이 동일하다고 가정함으로써 요구사항 변경 비율과 옵션 요구사항의 비율 유도의 모순을 보였다. 본 논문은 요구사항 변경은 정련단계와 구축단계에서 발생한다고 가정하였다. 또한, 소프트웨어 개발비용, 구축단계 소요 비용과 요구사항 변경 비용간에는 차이가 발생한다고 가정하였다. 그 결과 확정가 대비 요구사항 변경에 따른 추가 소요 비용과 개발이 되지 않아도 되는 옵션 요구사항의 비율도 보다 현실성을 반영하는 결과를 얻을 수 있었다.