변경관리(엔지니어링)
Change management (engineering)시스템 엔지니어링에서 변경 요구 관리 프로세스는 시스템 변경 요구, 달성 가능성 판단, 계획, 구현 및 평가 프로세스입니다.주요 목표는 상호 연결된 [1]일련의 요소에 대한 변경의 처리 및 추적성을 지원하는 것입니다.
서론
변경 요구 관리, 변경 제어 및 구성 관리 사이에는 상당한 중복과 혼란이 있습니다.다음 정의는 아직 이러한 영역을 통합하지 않았습니다.
변경 요청 관리는 영향을 받는 시스템을 개선하고 이에 따라 "고객의 요구"를 충족함으로써 이점을 제공할 수 있다는 점에서 받아들여져 왔지만, 변경 관리를 혼란스럽게 하고 불필요하게 복잡하게 만들 수 있다는 비판도 받고 있습니다.경우에 따라서는, 특히 정보기술(IT) 분야에서는,[2] 시스템의 초기 작성보다 시스템 유지보수(및 변경 요구 관리)에 더 많은 자금과 작업이 투입되고 있습니다.대규모 ERP 시스템을 처음 도입할 때 조직의 일반적인 투자는 전체 예산의 15~20%입니다.
같은 맥락에서 Hinley는 리먼의 소프트웨어 진화 법칙 중 두 가지를 설명합니다.
- 지속적인 변화의 법칙:사용되는 시스템은 변경해야 합니다.그렇지 않으면 자동으로 유용성이 떨어집니다.
- 복잡성 증가의 법칙:변경을 통해 시스템 구조가 더욱 복잡해지고 이를 단순화하기 위해 더 많은 리소스가 필요합니다.
또, 세계적인 경쟁의 격화, 테크놀로지의 진보, 고객의 [4]요구가 높아짐에 따라, 많은 변화에 직면하고 있는 제조 분야에서도, 변경 요구 관리는 매우 중요합니다.많은 시스템이 사용되면서 변화하고 발전하는 경향이 있기 때문에, 이러한 산업의 문제는 다른 많은 시스템에서 어느 정도 경험되고 있습니다.
주의: 다음 프로세스에서는 변경위원회가 승인/거부 결정뿐만 아니라 변경요구의 처리방법에 영향을 미치는 우선순위 부여에 대해서도 책임을 져야 합니다.
프로세스와 그 성과물
변경요구 관리 프로세스의 기술에는 메타모델링 기법을 이용한다.그림 1은 이 섹션에서 설명하는 프로세스 데이터 다이어그램을 나타내고 있습니다.
활동.
변경 요청 관리 프로세스를 공동으로 구성하는 6가지 주요 활동이 있습니다.다음과 같은 것이 있습니다.잠재적인 변경, 변경 요청 분석, 변경 평가, 변경 계획, 변경 구현 및 확인 후 변경 종료이러한 액티비티는 표 1에 설명되어 있는4개의 다른 역할에 의해 실행됩니다.활동 자체(또는 해당되는 경우 하위 활동)는 표 2에 설명되어 있습니다.
| 역할. | 묘사 |
|---|---|
| 고객. | 고객은 문제가 발생하거나 새로운 기능의 요건으로 인해 변경을 요구하는 역할입니다.이 역할은 개인 또는 조직 실체가 될 수 있으며 변경의 실장을 요구하는 기업 내부 또는 외부에 있을 수 있습니다. |
| 프로젝트 매니저 | 프로젝트 매니저는 CHANGE REQUEST와 관련된 프로젝트의 오너입니다.경우에 따라서는 이 역할을 담당하는 개별 변경 관리자가 있을 수 있습니다. |
| 변경 위원회 | 변경 위원회는 CHANGE REQUEST의 실행 여부를 결정합니다.프로젝트 매니저도 이 작업을 수행할 수 있습니다. |
| 변경 작성기 | 변경 작성자는 변경을 계획하고 실행하는 사람입니다.계획 컴포넌트는 프로젝트 매니저가 (부분적으로) 담당하고 있다고 주장할 수 있습니다. |
| 활동 | 서브 액티비티 | 묘사 |
|---|---|---|
| 잠재적인 변화를 특정하다 | 새로운[5] 기능 필요 | 고객이 새로운 기능을 원하고 요구 사항을 작성합니다. |
| 문제[5] 발생 | 고객이 시스템에서 문제(예: 버그)를 일으켜 문제 보고서를 작성합니다. | |
| 변경 요청 | 고객이 변경 요청 작성을 통해 변경을 제안합니다. | |
| 변경 요청 분석 | 기술적 타당성 판단 | 프로젝트 매니저는 제안된 CHANGE REQUES의 기술적 타당성을 판단하여 CHANGE TECHNICAL PABILITY로 이어집니다. |
| 비용과 편익을 결정하다 | 프로젝트 매니저는 제안된 변경 요청의 비용과 편익을 결정하여 변경 비용과 편익을 산출합니다.이 서브 액티비티와 위의 서브 액티비티는 임의의 순서로 실행할 수 있으며 서로 독립적이기 때문에 순서 없는 액티비티로서의 모델링이 이루어집니다. | |
| 변경 평가 | 변경 요청, 변경 기술적 타당성, 변경 비용 및 편익에 따라 변경 위원회는 승인 여부를 결정합니다.이는 중요한 프로세스 단계이며 이를 수행하는 다른 역할이 있기 때문에 별도의 활동으로 모델링됩니다.이는 렘코 헬름스(개인 커뮤니케이션)가 권장하는 하위 활동(이를 포함하는 활동이 없음)으로 모델링된다. | |
| 계획 변경 | 변경에 대한 영향 분석 | 변경의 정도(즉, 변경 효과가 미치는 다른 항목)는 CHANGE IMPACT 분석에서 결정된다.이 액티비티가 또 다른 승인/불합격 결정으로 이어지거나 변경 요청 분석 액티비티의 일부라고 주장할 수 있습니다.변경사항 전파 활동과의 관계 때문에 변경사항 작성기의 계획 태스크로 모델링됩니다. |
| 계획을 작성하다 | 변경 실행 시 변경 계획이 작성 시 변경계획이 작성됩니다.일부 프로세스 설명(Mékäraeinen, 2000 등)은 변경을 '저장'하여 나중에 일괄적으로 처리할 수도 있음을 보여줍니다.이 액티비티는, 이것을 실시하기 위한 좋은 포인트로 간주할 수 있습니다. | |
| 변경 실시 | 변경 실행 | 변경은 '프로그래밍'되어 있습니다.이 활동은 변경 전파와 밀접한 관계가 있습니다.이는 때때로 변경을 시스템의 다른 부분(또는 다른 시스템)에도 적용해야 하기 때문입니다. |
| 변경 전파 | Execute 변경으로 인한 변경은 변경의 영향을 받는 다른 시스템 부품으로 전파되어야 합니다.이 액티비티와 위의 서브 액티비티는 서로 의존도가 높기 때문에 동시 액티비티로 모델링되어 있습니다. | |
| 테스트 변경 | 변경 작성기는 자신이 구축한 것이 실제로 기능하고 CHANGE REQUEST를 충족하는지 여부를 테스트합니다.그림에서 보듯이, 이것은 위의 두 가지 하위 활동과 함께 반복적인 프로세스를 초래할 수 있습니다. | |
| 매뉴얼 갱신 | 적용된 변경 사항을 반영하도록 문서가 업데이트됩니다. | |
| 릴리스 변경 | 적용된 변경을 반영한 새로운 SYSTEM RELEASE가 공개됩니다. | |
| 변경 내용 확인 및 닫기 | 변경 확인 | 새로운 SYSTEM RELEASE의 변경 실장은 프로젝트 매니저에 의해 마지막으로 검증됩니다.이 문제는 출시 전에 발생해야 할 수도 있지만, 문헌 출처와 다이어그램의 복잡성 고려 사항의 상충으로 인해 이러한 방식으로 모델링하고 이 문제를 포함하도록 선택되었습니다. |
| 변경 닫기 | 이 변경 주기는 완료됩니다. 즉, CHANGE LOG ENTRI가 마무리됩니다. |
성과물
활동 외에도 프로세스 데이터 다이어그램(그림 1)은 각 활동의 성과물, 즉 데이터도 보여줍니다.이러한 성과물 또는 개념은 표 3에 설명되어 있습니다.이 문맥에서 가장 중요한 개념은 CHANGE REQUEST와 CHANGE LOG ENTRI입니다.
몇몇 개념은 (좋은) 정의를 찾을 수 없거나 활동의 명백한 결과이기 때문에 저자에 의해 정의된다(즉, 참조가 부족하다).이러한 개념에는 아스타리스크('*')가 붙어 있습니다.개념의 속성은 대부분 사소한 것이고 그렇지 않으면 다이어그램이 너무 복잡해질 수 있기 때문에 모형에서 제외되었습니다.또한 일부 개념(예: CHANGE REQUEST, SYSTEM RELEASE)은 Werd가 제안한 [6]대로 버전화 접근법에 적합하지만, 이 역시 다이어그램 복잡성 제약으로 인해 누락되었다.
| 개념. | 묘사 |
|---|---|
| 필요 | 컴포넌트(또는 아이템; NASA, 2005)에 필요한 기능. |
| 문제 리포트 | 레벨 1 헬프 데스크 직원이 해결할 수 없는 문제를 기술하는 문서.날짜, 문제를 보고하는 담당자의 연락처, 문제의 원인, 장소 및 설명, 조치 및 처분 등의 항목이 포함되어 있습니다(Dennis, 등, 2002). |
| 변경 요구 | 요청된 변경사항과 변경사항이 중요한 이유를 설명하는 문서. 문제 보고서, 시스템 개선사항, 기타 프로젝트, 기본 시스템 변경사항 및 고위 경영진에서 비롯될 수 있습니다(여기에는 REQUERATIONS(Dennis, et al., 2002).중요 속성: '동의/동의 안 함' 즉, 변경 실행 여부 |
| 로그 엔트리 변경* | 모든 변경사항 컬렉션(프로젝트 등)에 대한 개별 엔트리.변경요구, 변경기술적 타당성, 변경비용 및 이점, 변경영향분석, 변경계획, 테스트보고서 및 변경검증으로 구성됩니다.프로세스가 조기에 종료된 경우(즉, 변경이 구현되지 않은 경우) 이러한 모든 것을 포함할 필요는 없습니다. |
| 기술적 타당성 변경 | 「신뢰성이 높은 하드웨어와 소프트웨어, 제안된 시스템의 요구를 만족시킬 수 있는 기술 자원(즉, 변경 요구)을 조직이 필요한 시간에 취득 또는 개발할 수 있는지 여부를 나타내는 개념」(Vogl, 2004). |
| 비용 및 이점 변경 | 도입에 필요한 기대 노력과 변경을 도입함으로써 얻을 수 있는 이점(예: 비용 절감, 수익 증가)경제성이라는 이름도 붙었다(Vogl, 2004). |
| 변경 영향 분석 | 변화의 정도에 대한 평가(Rajlich, 1999). |
| 변경 계획 | "어떤 목표를 달성하거나 무언가를 달성하기 위한 계획, 방법 또는 설계(즉, 변경)"(Georgetown University, n.d.) 이 경우 변경. |
| 아이템 | "시스템, 서브시스템, 어셈블리, 서브어셈블리, 유닛, 세트, 액세서리, 컴퓨터 프로그램, 컴퓨터 소프트웨어 또는 부품을 포함한 모든 제품을 나타내기 위해 사용되는 비특정 용어"(Rigby, 2003)는 서브타입 항목과 변경된 항목을 추가(중복)했습니다. |
| 아이템 추가* | 자체 설명: 새로 생성된 ITEM. ITEM의 하위 유형. |
| 아이템 변경* | 자체 설명: 이미 존재했지만 변경된 항목. ITEM의 하위 유형입니다. |
| 테스트 리포트 | "[변경의 영향을 받는] 시스템 또는 컴포넌트에 대해 수행된 테스트 수행 및 결과를 설명하는 문서" (IEE, 1991년) |
| 문서 | 펜실베니아 주립 대학 도서관(2004)의 정의에 따르면, DOCUATION은 다른 자료(일반적으로 비도서)와 함께 제공되는 "p"-rinted 자료로, 주요 자료에 대한 설명, 사용 지침 또는 기타 지침으로 기능합니다.이러한 맥락에서, 시스템의 일부와 관련된 한, 디지털 자료나 훈련일 수도 있습니다. |
| 시스템 릴리스 | "M]erchandise는 판매 또는 공개용으로 발행되었습니다." (프린스턴 대학교, 2003).하나 이상의 항목과 함께 제공되는 설명서로 구성됩니다. |
| 변경 확인 | 변경 실시의 결과가 이전에 확립된 요건을 충족하는지 여부를 판단한다(Rigby, 2003). |
단순히 '변화'뿐만 아니라 편차와 [7]이탈도 구별할 수 있다.편차는 항목을 생성하기 전에 해당 항목의 요구 사항을 벗어나는 권한(또는 요청)입니다.포기는 기본적으로 동일하지만 아이템 작성 중이나 작성 후와는 다릅니다.이러한 두 가지 접근법은 최소한의 변경 요청 관리(즉, 당면한 문제에 대한 실질적인 해결책이 없음)로 볼 수 있습니다.
예
실행 중인 변경 요청 관리 프로세스의 좋은 예는 소프트웨어 개발에서 찾을 수 있습니다.사용자가 버그를 보고하거나 소프트웨어 프로그램에 새로운 기능을 요구하면 변경 요청이 발생하는 경우가 많습니다.다음으로 제품 소프트웨어 회사는 이 변경의 기술적, 경제적 타당성을 조사하고 그 결과 변경이 실제로 실현될지 여부를 결정합니다.실제로 그러한 경우, 예를 들어 기능점의 사용을 통해 변경을 계획해야 합니다.실제 변경 실행은 소프트웨어 코드의 작성 및/또는 변경으로 이어지며, 이 변경이 전파되면 다른 코드 조각도 변경될 수 있습니다.초기 테스트 결과가 만족스러운 것으로 판단되면 문서를 최신 상태로 만들어 소프트웨어와 함께 공개할 수 있습니다.마지막으로 프로젝트 관리자가 변경을 확인하고 변경 로그에서 이 항목을 닫습니다.
여기서의 변경 요구 관리의 또 다른 일반적인 영역은 제조 도메인입니다.자동차의 설계와 생산을 예로 들어보자.예를 들어 장거리 주행 후 차량의 에어백에 공기가 자동으로 채워지는 것으로 확인되면 고객 불만 사항(또는 테스트 단계 중 문제 보고)으로 이어질 것이 확실합니다.그 결과 변경 요청이 생성되고(오른쪽 그림 2 참조), 변경이 정당화될 수 있습니다.단, 가장 단순한 비용 및 편익 분석을 실시해야 변경 요청을 승인할 수 있습니다.자동차 설계 및 생산 일정에 미치는 영향을 분석한 후, 변경사항 시행 계획을 수립할 수 있습니다.이 계획에 따르면, 이 변화는 실제로 실현될 수 있으며, 그 후 새로운 버전의 차가 대중에게 공개되기 전에 철저한 테스트를 거치기를 바란다.
산업용 플랜트
복잡한 공정은 작은 변화에도 매우 민감할 수 있기 때문에 산업 시설 및 공정의 적절한 변경 관리는 안전에 매우 중요한 것으로 인식된다.미국에서는 OSHA에 변경이 이루어지고 문서화되는 방법을 규정하는 규정이 있다.주요 요건은 위험의 누락 가능성을 최소화하기 위해 가능한 많은 관점을 사용할 수 있도록 여러 학제 팀이 제안된 변경 사항을 철저히 검토해야 한다는 것이다.이 문맥에서 변경요구 관리는 Management of Change(MOC)라고 불립니다.1910.119(l) 섹션의 프로세스 안전 관리의 많은 구성 요소 중 하나일 뿐입니다.
「 」를 참조해 주세요.
- 변경 관리
- 변경요청관리
- 엔지니어링 변경 순서, 변경 요청
- 프린스2
- IT
- 버전 관리
- 릴리스 관리
- 소프트웨어 릴리스 라이프 사이클
- 응용 프로그램 라이프 사이클 관리
- 시스템 엔지니어링
- 이슈 추적 시스템
레퍼런스
- ^ Crnkovic, Asklund & Persson-Dahlqvist, 2003
- ^ Dennis, Wixom & Tegarden, 2002.
- ^ 힌리 1996년
- ^ Huang & Mak, 1999년
- ^ a b 실제로 변경 요청을 받기 위해 Require new function과 Outcounter 문제가 모두 발생할 필요는 없습니다.보통 두 가지 중 하나만 발생합니다.순서를 정하지 않은 활동으로 모델링하는 것은 대략 이 의미에 근접합니다.대안은 두 개의 개별적인 '시작점'(즉, 초기 상태)을 만드는 것이며, 둘 다 변경 요청을 가리킵니다.
- ^ 웨어드 2006
- ^ Scott & Nisse, 2001.
추가 정보
- Crnkovich I., Asklund, U. & Persson-Dahlqvist, A. (2003)제품 데이터 관리 및 소프트웨어 구성 관리 구현 및 통합런던:아르텍 하우스.
- Dennis, A., Wixom, B.H. & Tegarden, D. (2002)시스템 분석 및 설계: UML. Hoboken(뉴욕): John Wiley & Sons, Inc.의 객체 지향 접근법
- 조지타운 대학교 (신규)데이터 웨어하우스: 용어집2006년 4월 13일, https://web.archive.org/web/20060423164505/http 에서 취득.
- 힌리, D.S. (1996년)소프트웨어 진화 관리: 프로세스 지향적인 관점.Information and Software Technology, 38, 723-730.
- Huang, G.H. & Mak, K.L.(1999년)영국 제조업에서의 엔지니어링 변경 관리의 현행 관행.International Journal of Operations & Production Management, 19(1), 21-37.
- IEEE(1991)소프트웨어 엔지니어링 용어집(ANSI)전기 전자 기술자 협회2006년 4월 13일 취득:http://www.ee.oulu.fi/research/ouspg/sage/glossary/ #reference_6 Archived 2009-10-21 at the Wayback Machine.
- 매캐래이넨, M. (2000)임베디드 소프트웨어 개발에서의 소프트웨어 변경 관리 프로세스.박사 학위 논문Espoo: VTT 출판물.온라인으로 입수 가능:http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf
- NASA(2005년).NASA IV&V 설비 메트릭스 데이터 프로그램 - 용어집 및 정의2006년 3월 4일, https://web.archive.org/web/20060307232014/http 에서 취득.
- 펜실베이니아 주립대학 도서관(2004년).CCL 매뉴얼: 용어집 및 약어.2006년 4월 13일 취득:https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/ cataloging/ccl/contractary.htm
- 프린스턴 대학교(2003년).WordNet 2.0.2006년 4월 13일, http://dictionary.reference.com/search?q=release 에서 취득.
- 라즐리히, V. (1999년)소프트웨어의 변경과 진화Pavelka, J., Tel, G. & Bartoshek, M. (Eds.), SOFSEM'99, 컴퓨터 사이언스 강의 노트 1725, 189-202.
- Rigby, K. (2003)표준 관리: 용어집.2006년 4월 1일, https://web.archive.org/web/20060412081603/http 에서 취득.
- 스콧, J.A. & Nisse, D. (2001)소프트웨어 구성 관리, 소프트웨어 엔지니어링 지식 기관 가이드, 7장, IEEE Computer Society Press.
- Vogl, G. (2004)관리 정보 시스템: 용어집.2006년 4월 13일 우간다 순교자 대학 웹사이트 https://web.archive.org/web/20060411160145/http 에서 취득.
- Weerd, I. van de (2006)메타모델링 기술: 2006년 5월 5일 메서드 엔지니어링 과정 초안.2006년 3월 1일, https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions[permanent dead link] 에서 프로세스 데이터 다이어그램.pdf [접근 제한]를 취득했습니다.
