어쨌건간에 흘러가는 者

6시 공연 시작 예정이 7시로 늦춰지더니만, 오프닝 시작은 8시. 울나라 두 팀이 총 3곡을 부른 20분이 지난 이후, 무려 한시간 10분여를 가득 매운 스탠딩 석에서 마냥 기다리려니 허리가 쑤시지 않을려야 않을 수가 없었다는. 나도 이제 나이가 있는데 말야. 뭐 나 뿐인가? 본 공연의 관중 나이를 따지자면 난 중간 즈음에 속한다. 개중 머리가 벗겨진 아저씨도 보이더만.
근데 왠걸, 9시 반 경부터의 두 시간 여 공연을 위해 똑같은 자리에서 똑같이 서있었는데, 끝난 이후에는 언제 아팠냐는 듯이 다시금 멀쩡해지는 건 역시 액슬의 힘이던가? 그 만큼 만족했다는 뜻이다.
공연 타이틀이 Appetite for destruction도 아니고 Use your illusion도 아닌 Chinese Democracy임을 감안한다면, 본 신보의 곡을 적지 않게 배치했다는 것은 놀랄 일도, 그들을 탓할 일도 아니다. 본 신보 곡이 나올 때의 반응이 뜨겁지 않으리란 것은 예상했던 바이지만 '썰렁'까지 해질 줄이야. 곡을 따라부르고 있는 나를 신기한, 아니 얼마간은 이상한 듯이 쳐다보는 주위의 시선은 상당히 당황스러웠던 부분 중 하나. 아쉬웠던 건 본 앨범 중 가장 좋아하던 Prostitute가 빠졌다는 건데, 꽤나 긴 러닝 타임이나 얼마간 단조 냄새를 풍기는 곡 성격을 감안하자면 예상되기도 했던 부분이다.

한명이 더 늘어난 3명의 기타리스트 중 DJ Ashba가 상당히나 인상적이었는데 포스트 슬래시라고 불러도 그다지 이상하지 않을 듯한... 아우라, 실력(?), 외모. 액슬의 소개에 이어 진행된 그의 정면 스피커 위 기타 쏠로가 Sweet Child O'Mine으로 바뀌던 그 순간의 그 짜릿함은!

액슬의 목소린 최고 수준. 그 찢어지는 목소리 자체가 맘에 안든다면 할 말 없고, 첫 곡부터 목청껏 불러 제끼길래 이거 얼마나 갈까 싶었는데, 그 고주파 목소릴 마지막 곡까지의 계속된 고음 영역에서도 꾸준하게 유지했다는 데 상당히 놀라웠다. 이에 비교되는 한 옥타브 내려간 김빠진 액슬의 모습은 타 공연 실황에서 어렵지 않게 찾아 볼 수 있다.
왕년 꽃미남의 아우라가 아닌 Meat Loaf를 연상시키는 돼지 모습에 실망했다면, 이를 기대한 그 마음의 철부지스러움을 탓해야 한다. 액슬의 나이 이제 쉰을 바라본다. 고음역을 한청 부르짖은 후 잠시 허릴 잡고 힘들어하는 그의 '퍼포먼스'는 그간의 고압적 카리스마가 아닌 인간적 유머를 보이고자 하는 그의 마음을 다분히 보이는데, 난 당시 이 모습을 보고 '이제야 철들었군'하고 '잘못' 생각했다(공연 지연의 원인이 전날 도착이란 약속을 펑크내고 당일 그 시간에야 대만에서 도착했기 때문이었다는 이야길 나중에 접하고는, 그 생각을 바로 접었다~ ㅋ)

예상외로 빠진 곡으로 Don't Cry, Civil War, Catcher In the Rye 및 Use Your Illusion의 상당수 곡들.
예상 밖으로 들어간 곡은 상당 수의 Appetite for Destruction의 것들,
가장 아쉬웠던 곡으로는 Estranged, Prostitute, Don't Cry.


한줄 결론. 액슬이 있기에 Guns N' Roses다.


p.s.
1. 대중음악 평론가란 명함을 앞에 걸고 글빨 속에 본 공연에 대한 악감정을 표출한 글이 보이는데, 딱 한 마디 해주고 싶다. 그 따위로 글을 쓰니 평론가란 직업이 욕을 먹는 거라고. 강산도 두 번이나 변해가려는 십 수년전의 GNR 모습이란 자신의 잣대에 공연이 들어맞지 않았다고 힘껏 내려깐 그 글은 사실 '악플'에 다름 아니다. 개인적으로 꽤나 즐겨 찾던 신문 사이트에 이 어이없는 욕이 포스트되는 꼴을 보자니,,, 후훔.

2. 위의 사진은 iphone으로 찍은 건데, 줌이 안되니 액슬이 코딱지 만하게 나왔다. 똥돼지가 열심히 뛰어다니는 모습이 꽤나 귀여워 보였다는... ㅋ

 

[주의 사항]
IEEE에서 제작한 본 SWEBOK에는 무시하기 어려운 비판론이 제기된 상황입니다. 주된 비판 주체로 초기에 본 문서 제작에 참여했다 철수한 ACM이 있으며, Grady Booch, Cen Kaner가 보입니다. 비판의 핵심은 본 문서가 주장하는 바인 'Generally accepted'가 사실이 아니라는 점과 본 문서와 밀접히 연계된 licensing(CSDP)의 무효성입니다.

상기 비판론을 염두하여 문서에 대한 내용을 받아들이길 권장합니다.

Introduction 
시스템은 특정 기능 또는 기능 집합을 완수하기 위해 조직된 컴포넌트의 모음으로 정의됨(IEEE 610.12-90). 시스템의 형상 은 H/W, 펌웨어, S/W 또는 이들 간 조합을 기술 문서화하고 제품으로 드러나게 하는 기능적 그리고/또는 물리적 특성임. 또한 시스템의 형상 은 특정 목적을 수행하기 위해, 지정된 빌드 절차에 따라 조합된 H/W, 펌웨어, S/W의 특정 버전 모음으로 생각할 수도. 이제, 형상 관리(CM)란, 특정 시점의 시스템 형상 식별을 위한 규칙(discipline)으로, 그 목적은 형상의 변경을 시스템적으로 통제하고 시스템 생명주기 전체에 걸쳐 형상의 완전성(integrity)과 추적성을 유지하는 데 있음. 정형적으로 형상 관리를 정의하자면, "다음과 같은 사항에 대한 기술적, 관리적 지시(direction) 및 감독(surveillance) : 형상 항목의 기능적/물리적 특성의 식별 및 문서화, 변경 과정 및 상태 구현에 대한 기록 및 보고, 지정된 요구사항에 대한 준수 여부 확인".
S/W 형상 관리(SCM; Software Configuration Management)는 S/W 생명 주기를 지원하여, 프로젝트 관리, 개발 및 유지보수 활동, 보증 활동, 최종 제품의 고객 및 사용자에 이익을 줌. 형상 관리의 개념은 통제 대상의 모든 항목에 적용되지만 H/W CM과 S/W CM 간에 구현 상 상이점이 얼마간 존재.
SCM은 S/W 품질 보증(SQA)와 밀접히 관계하여, S/W 품질 KA에서 정의된 바에 따르면 SQA 공정은 프로젝트 생명주기에서의 제품 및 공정을 보증하는데, 이들 제품 및 공정은 S/W 품질 신뢰성을 부여하기 위한 일련의 활동을 계획, 강제, 수행을 통해 이루어야. SCM 활동은 이러한 SQA 목표의 달성에 도움을 주며 몇몇 프로젝트 컨텍스트에서는 SQA 요구사항에서 특정 SCM 활동을 기술하기도.
SCM 활동으로는 SCM 공정 관리 및 계획, S/W 형상 식별, 통제, 상태 기록, 감사 및 S/W 릴리즈(release) 관리 및 인도(delivery)가 있음. Figuire 1은 이들 활동을 나타내고 있음.

SCM은 타 모든 KA와 연계되는데, 이는 형상 관리의 항목(object)이 SWE 공정 전체에 걸쳐 생산 및 사용되기 때문.

Breakdown of Topic

1. S/W 형상 공정 관리(Management of the SCM Process)
SCM은 제품의 진화와 완전성을 다음을 통해서 통제함: 요소 식별, 변화 관리 및 통제, 검증(verify), 기록 및 형상 정보의 보고. S/W 기술자의 입장에서 보자면 SCM은 개발과 변경 구현 활동을 촉진함. 성공적 SCM 구현은 주의 깊은 계획과 관리를 요하는데, 이는 결국 조직 컨텍스트, 제한조건, SCM 공정의 설계 및 구현이 필요함을 뜻함.
1.2. SCM 공정의 제한조건 및 안내(Constraint and Guidance for SCM Process)
SCM 공정에 영향을 미치는 제한조건 및 안내는 다양한 소스로부터 출발함. 기업 또는 조직 수준에 선행하는 정책 및 절차가 해당 프로젝트에 대한 SCM 공정에 영향을 미칠 수 있으며, 획득자와 공급자간 계약 또한 그러함. 예를 들어, 특정 형상 감사가 필요하다거나 특정 항목을 CM 대상으로 지정할 수도. S/W가 공공 안전에 영향을 미칠 경우 외부 규제가 제한사항으로 포함되기도 하며, S/W 생명 주기 역시 그러함.
SCM 공정 설계 및 구현에 대한 안내는 'best practice'를 통해 얻을 수도.
1.3. SCM 계획(Planning for SCM)
SCM 공정 계획은 조직 컨텍스트, 제한조건, 일반적으로 수용되는 안내, 프로젝트의 본성(ex. 크기 및 중요도)과 일관되어야. 주로 다뤄지는 활동으로, S/W 형상 식별, 통제, 상태 기록, 감사 및 S/W 릴리즈 관리 및 인도(delivery)임. 이와 함께 고려될 사항으로, 조직 및 책임, 자원과 일정, 도구 선택과 구현, 벤더와 하청업체 통제, interface 통제가 있음. 계획 활동의 결과는 SCM 계획(SCMP; SQL 검토 및 감사의 주제)에 기록됨.
1. SCM 조직 및 책임
SCM 활동 및 작업 수행 주체를 명확하게 하기 위해 조직이 명확히 식별되어야. 주어진 SCM 활동 또는 작업에 대한 책임은 조직 엔티티 각각에 할당되어야. SCM에 대한 전체 감사 및 보고 경로(channel) 역시 식별되어야 하는데, 이는 프로젝트 관리 또는 품질 보증 계획 단계에서 이루기도.
2. SCM 자원 및 일정
스태프와 도구 식별 역시 SCM 계획 활동 중 하나. 본 활동은 SCM 작업 순서(sequence)의 수립 및 프로젝트 관리 계획 단계에서 수립된 일정/마일스톤과의 관계 식별을 부각시킴. 계획 구현 및 새로운 스태프 훈련을 위한 훈련 요구사항 역시 지정됨.
3. 도구 선택 및 구현
SCM 활동을 위한 도구, 절차는 다양함. 상황을 따른다면, 이들 도구 기능(capability)은 다음과 같은 도구의 조합을 통해 만들어짐: 여러 매뉴얼 도구(manual tools), 단일 SCM 기능을 위한 자동화 도구, 일정 범위의 SCM 기능을 통합하는 자동화 도구, 여러 SWE 공정(ex. SCM, 개발, V&V 등)의 요구를 충족시키는 통합 도구 환경(Integrated tool environment). 자동화 도구 지원은 프로젝트 크기가 커지고 복잡해짐에 따라 점점 중요해짐과 동시에 점점 수립이 어려워지는데, 이들 도구가 지원하는 기능은 다음과 같음.
 ○ SCM 라이브러리
 ○ S/W 변경 요구(SCR; Software change request) 및 승인 절차
 ○ 코드(및 관계 작업 도구) 및 변경 관리 작업
 ○ S/W 문서화 관리 및 추적
 ○ S/W 빌드 수행
 ○ S/W 릴리즈 및 인도 관리 및 추적
이들 도구는 프로세스 향상을 위한 측정요소 역시 제공하는데, 이에 관계된 측정기준, 즉 프로젝트 관리 지표 및 품질 지표 7가지로는 변경 트래픽(traffic) 및 안정성(stability), 파손(Breakage) 및 모듈화(modularity), 재작업(rework) 및 적응성(adaptability), 그리고 MTBF(mean time between failures)와 성숙도(Maturity)가 있음. Figure 3은 SCM 활동에 대한 도구 기능 및 절차의 매핑 관계를 보여줌.

위 예제에서 코드 관리 시스템은 S/W 라이브러리 운영에 대해 라이브러리 요소에 대한 접근 통제를 통해 지원하고, 여러 사용자의 활동을 조정(coordinate)하고, 운영 절차 강제를 돕고 있음. 또한, S/W 생성 및 릴리즈 해당 라이브러리에 담긴 S/W 요소에 대한 문서화 생성 공정을 지원하는 도구가 있고, SCR 관리 도구는 통제 대상  S/W 항목에 대한 변경 통제 절차를 지원하며, 어떤 도구는 DB 관리, 관리/개발/품질 보증 활동 관리에 대한 보고 기능을 갖추기도 함. 위에서 언급한 것처럼 이들 도구는 SCM 시스템으로 통합되어 결국 타 S/W 활동과 긴밀한 관계를 이룸.
계획에서 S/W 기술자는 해당 프로젝트에 맞는 SCM 도구를 선택하게 되는데, 이에 대한 고려 사항으로 이들 도구의 구현 시 문화 변경(culture change) 등이 요구될 경우 이슈가 발생할 수도. SCM 도구에 관한 자세한 설명은 SWE 도구 및 방법 KA를 잠조.
4. 벤더/하위 계약자 통제(Vendor/Subcontractor control)
SCM 계획에는 컴파일러 등의 외부에서 획득한 도구에 대해서도 어떻게 형상항목으로 다룰지, 변경에 대한 평가, 관리 방법을 고려해야. 
하위 계약자에 대해서도 유사한 고려가 필요. 이 경우 SCM 요구사항이 하위 계약자의 SCM 공정에 하위 계약의 일부로 부여되고 준수성 감독(monitoring compliance) 역시 수립되어야. 효과적인 준수성 감독을 위해 어떤 SCM 정보가 가능한지에 대해서도 고려가 필요.
5. 상호작용 통제(interface control)
S/W가 타 S/W 또는 H/W와 상호작용(interface)을 이룰 경우, 이들 중 하나가 변경을 이루더라도 다른 하나에 영향을 미치게 됨. SCM 공정 계획에서는 상호작용을 이루는 항목에 대한 식별 방법과 이들 항목에 대한 변경에 대해 어떻게 관리 및 소통을 이룰지를 고려하여야. SCM의 역할은 상호작용 명세 및 통제 계획, 통제 문서에 대한 더 큰, 시스템 수준 공정의 일부가 될 수 있으며, 이 경우 SCM 계획은 시스템 수준 공정의 배경 내에서 이루어짐.
1.4. S/W 형상 관리 계획(SCMP; Software Configuration Management Plan)
SCM 계획에 대한 결과는 SCMP, 즉 SCM 공정 참조 역할을 이루는 유효 문서(living document)에 기록됨. 본 문서는 S/W 생명 주기 내내 관리되며, SCMP의 작성에는 보통 어떻게 특정 요구사항을 정의하고 일일 활동 기반으로 어떻게 수행할지 등의 하위 세부 절차가 개발됨.
계획 활동에서 만들어진 정보를 기반으로 한 SCMP의 생성/유지보수 안내는 다양한 소스에서 얻을 수 있는데, IEEE828-98은 한 예. 본 참조 문서는 SCMP에 부과되는 제한 사항을 논하며, SCMP에 포함될 6개 카테고리로 이루어진 SCM 정보를 정의, 기술함.
 ○ 소개(Introduction; 목적, 범위, 사용 용어)
 ○ SCM 관리(조직, 책임, 권한, 적용 정책, 지시(directive), 절차
 ○ SCM 활동(형상 식별, 통제 등)
 ○ SCM 자원(도구, 물리적 자원, 인적 자원)
 ○ SCMP 유지보수
1.5. SCM 감독(Surveillance of SCM)
SCM 절차가 구현되고 나면, 일정 수준의 감독(surveillance)를 통해 해당 SCM이 목표하는 바를 적절히 수행하는지를 확인해야. SQA 요구사항에는 지정된 SCM 프로세스 및 절차의 준수 여부 확인이 있을 수도 있는데, 이는 SCM 권한(authority)과 연계되어, 준수성 감사 활동의 일부인 SQA 권한이 본 감독을 수행할 수도 있음.
프로세스 제어 기능(capability)을 갖춘 통합 SCM 도구는 본 감독을 더욱 쉽게 하는데, 감독 요구사항과 SCM 프로세스 적응 지원에 관한 부분은 도구 선정의 중요 기준임.
1. SCM 측정기준과 측정(SCM measures and measurement)
SCM 측정기준은 진화하는 제품에 대한 특정 정보 또는 SCM 프로세스의 기능에 대한 통찰의 제공을 목적으로 설계되기도. SCM 프로세스를 감시(monitor)하는 목적 중 하나는 프로세스 향상의 기회를 발견하는 데 있음. 측정은 현 프로세스를 특징지을 수 있으며, SCM 활동 효과성 감시를 위한 수단이 되기도. 측정결과 분석은 프로세스 변화 및 해당 SCMP 갱신을 이끄는 통찰을 제공하기도.
S/W 라이브러리와 다양한 SCM 도구는 SCM 프로세스의 특징을 추출하기 위한 소스 및 프로젝트/관리 정보를 제공함. 
감독 시 초점은 측정 자체가 아닌 측정을 통해 얻는 통찰에 있어야. 프로세스와 제품 측정은 SWE 프로세스 KA에서 , S/W 측정 프로그램은 SWE 관리 KA에서 다룸.
2. 프로세스 내 SCM 감사(In-process audits of SCM)
SWE 프로세스 동안 감사는 특정 형상 항목에 대한 현 상태의 파악 또는 SCM 프로세스 구현 평가를 위해 수행되기도. SCM의 프로세스 내(In-process) 감사를 통해 선택한 프로세스를 감시하기 위한 좀더 정형적인(formal) 메커니즘을 제공함과 동시에 SQA 기능(function)과 조합을 이룰 수도.

2. S/W 형상 식별(S/W Configuration Identification)
S/W 형상 식별은 통제할 항목을 식별하고, 이들 항목과 해당 항목의 버전을 위한 스키마를 수립하며, 통제 대상 항목의 수집과 관리에 사용할 도구와 기술을 수립하는 활동임. 본 활동은 타 SCM 활동의 기초가 됨.
2.1. 제어 대상 항목 식별(Identifying Items to be Controlled)
변경 통제의 첫 단계는 통제 대상 항목의 식별임. 본 활동은 시스템 형상의 컨텍스트 내에서 S/W 형상을 이해하고, S.W 형상 항목을 선택하며, S/W 항목 명명(labeling) 전략 수립 및 이들 간 관계, 기준선(baseline) 식별임.
1. S/W 형상(Software configuration)
S/W 형상은 기술 문서 및 제품 내에 내재할 S/W의 기능적, 물리적 특성임(IEEE 610.12-90). 이는 S/W 형상의 일부로 바라볼 수도
2. S/W 형상 항목(Software configuration item)
S/W 형상 항목(SCI; Software configuration item)은 형상 관리를 위해 지정된 S/W의 총체이며 SCM 프로세스 내에서 단일 엔티티로 다뤄짐(IEEE610.12-90). 코드 자체를 포함한 다양한 항목이 SCM을 통해 통제되어, 계획, 명세 및 설계 문서, 시험 관련물(matrial), S/W 도구, 소스 및 실행 코드, 코드 라이브러리, 데이터 및 데이터 딕셔너리, 설치/유지보수/운영/사용 문서화가 여기에 포함됨.
SCI의 선택은 프로젝트 통제를 위한 적절한 가시성과 관리 가능한 수준의 통제 항목 개수 간 균형을 이루기 위한 중요한 프로세스임.
3. S/W 형상 항목 관계(Software configuration item relationships)
선택된 SCI 간의 구조적 관계와 이에 연속된 부분은 타 SCM 활동 또는 작업, 즉 S/W 빌드, 변경 영향 분석 등에 영향을 미치며, 추적성 지원을 위해서도 중요. SCI 스키마 식별 설계 시에는 S/W 구조에 대한 식별 항목의 매핑 뿐 아니라, S/W 항목과 이들간 관계 진화의 지원에 대해서도 고려해야.
4. S/W 버전(Software version)
S/W 항목은 S/W 프로젝트가 진행됨에 따라 진화함. S/W 항목의 버전은 특별히 식별/지정된 항목으로, 진화한 항목의 상태로 생각할 수도. 리비전(revision)은 항목의 새 버전으로 이전 버전을 교체하는 의도가 포함되며, 배리언트(variant)는 이전 버전의 교체 없이 형상에 포함되는 새 버전임.
5. 기준선(Baseline)
S/W 기준선이란 S/W 생명주기 내의 특정 시간에 정식으로(formally) 지정되고 고정된 S/W 형상 항목의 모음으로, 본 용어는 합의하에 구성된 S/W 형상 항목의 특정 버전을 지칭할 때에도 사용함. 두 경우 모드에서 기준선은 정식 변경 통제 절차를 통해서만 변경 가능하며, 기준선과 기준선에 대해 승인된 모든 변경은 현재 승인된 형상을 나타냄.
일반적으로 사용되는 기준선에는 기능(functional), 할당(allocated), 개발(developmental), 제품(product) 기준선이 있어. 기능 기준선은 검토된 시스템 요구사항에 대응하고, 할당 기준선은 검토된 S/W 요구사항 명세 및 S/W 인터페이스 요구사항 명세에 대응. 또한 개발 기준선은 S/W 생명 주기 내 특정 시간의 진화 중인 S/W 형상을 표현함. 본 기준선의 변경 권한은 기본적으로 개발 조직에 부여되나, 타 조직(ex. SCM 또는 시험 팀)과 공유될 수도. 제품 기준선은 시스템 통합을 위해 인수된 S/W 완성품에 대응하며 일반적으로 SCMP에서 식별됨.
6. S/W 형상 항목 획득(Acquiring software configuration items)
SCM 통제 하의 S/W 형상 항목은 각기 다른 시간에 위치함, 이는 이들 항목과 특정 기준선의 연계가 S/W 생명 주기 내 특정 시점에 이루어짐을 의미함. 사건 트리거(triggring event)란 정형 검토(formal review)와 같은 정식 수용 작업(acceptance task) 형태(form)의 완료를 뜻함. Figure 4는 생명주기가 진행됨에 따라 기준선 기반 항목의 발전을 보여주는데, 본 그림은 폭포수 모형에서만 통용됨에 유의할 것. S/W 변경 요구(SCR)는 3.1 S/W 변경 요구, 평가, 승인 절에서 기술됨.

SCI 획득 이후, 항목의 변경은 해당 SCI와 관련 기준선에 대한 적합성을 나타내도록, 또한 SCMP에 계획된 대로 정식 승인 절차를 거쳐야. 승인 이후 해당 항목은 적절한 절차를 거쳐 S/W 기준선에 통합됨.
2.2. S/W 라이브러리(Software Library)
S/W 라이브러리란 S/W 개발, 사용, 유지보수를 돕기 위해 설계된 통제 하의 S/W 모음 및 관련 문서임(IEEE610.12-90). 이는 또한 S/W 배포 관리 및 인도 활동에도 이용되는 등, 여러 형태의 라이브러리가 사용될 수 있는데, 이들 각각은 S/W 항목의 특정 성숙도 수준에 대응함. 예를 들어, 워킹 라이브러리(working library)는 코딩을 지원하고, 프로젝트 지원 라이브러리(project support library)는 시험을 지원하며, 마스터 라이브러리(master library)는 완료 제품 지원에 사용됨. 적절한 SCM 통제 수준은 각각의 라이브러리와 연계됨. 접근 제어(Access control)과 백업 장비로 대표되는 보안은 라이브러리 관리의 핵심 측면임.
각 라이브러리에 사용되는 도구는 SCI 통제와 라이브러리 접근 통제 등의 SCM 통제를 지원해야 하는데, 예컨데 워킹 라이브러리 수준에서 도구는 개발자, 유지보수자 및 SCM을 위한 코드 관리 기능을 지원하여야. 통제 수준이 높아질 수록 접근은 더욱 제한적이어, SCM이 주요 사용자가 됨.
또한 이들 라이브러리는 작업과 프로세스 측정을 위한 중요 정보원이 되기도

3. S/W 형상 통제(S/W Configuration Control)
S/W 형상 통제는 S/W 생명 주기 내에서의 변경 관리에 관계됨. 본 활동은 변경 대상 결정 프로세스, 특정 변경 승인 권한, 변경 사항의 구현, 프로젝트 요구사항에 대한 정형 편차(formal deviation) 개념 및 요구 사항의 포기(waiver)를 다룸. 본 활동 중 추출된 정보는 변경 트래픽, 파손, 재작업 측면에 대한 측정에 도움이 됨.
3.1. S/W 변경의 요구, 평가, 승인(Requesting, Evaluating and Approving Software Changes)
통제 항목에 대한 변경 관리의 첫 단계는 변경 대상의 결정임. S/W 변경 요구 프로세스(Figure 5 참조)는 다음과 같은 사항에 대해 정형적 절차를 제공함; 변경 요구의 제출/기록, 잠재적 비용 및 제안된 변경 영향도의 평가, 제안된 변경의 승인, 수정, 반려.

S/W 형상 항목 변경 요구는 S/W 생명 주기 내 모든 시점/주체에 의해 나타나며, 해결책과 변경 우선순위가 함께 하기도. 변경 요구 소스 중 한 예는 문제 보고서(Problem Report)임. 또한 소스의 종류에 상관 없이 변경 유형(ex, 결함 또는 향상)은 SCR에 기록되곤 하며, 이를 통해 변경 유형에 따라 결함을 추적하고 변경 사항을 취합할 기회를 갖게 됨. 
SCR을 얻게 되면, (영향 분석으로 알려진) 기술 평가를 통해 해당 변경 요구를 수용할 만한지 여부를 판단케 하는 수정 범위를 결정하게 되는데, 이때 S/W(또는 H/W까지) 간 관계에 대한 이해도가 중요한 역할을 담당함. 마지막으로, 해당 기준선 및 관련 SCI, 해당 변경의 본성에 관계하는 기 수립된 권위 조직이, 변경 요구의 기술적/관리적 측면을 평가하고 제안된 변경을 수용, 수정, 거절, 연기함.
1. S/W 형상통제위원회(CCB; Software Configuration Control Board)
제안된 변경에 대한 수용 또는 거절 권한은 보통 형상통제위원회(CCB)라 일컫는 엔티티에 부여되며, 작은 프로젝트에서의 본 권한은 다수의 인원으로 구성된 위원회보다는 리더 또는 특정 인원에 부여됨. 변경 권한은 여러 수준으로 나뉠 수 있어 이는 여러 기준, 즉 해당 항목의 중요도, 변경의 성격(ex. 예산 및 일정에 대한 영향), 생명 주기 내의 현재 위치에 따라 달라짐. 여러 CCB의 구성 방법 역시 이들 기준에 따라 다양함(그 중에도 단일 SCM 대표는 항상 존재). CCB의 권한이 엄격히 S/W로 제한될 경우 이를 가리켜 S/W 형상통제위원회(SCCB)라 하며, 본 CCB의 활동은 S/W 감사 또는 검토에 치중됨.
2. S/W 변경 요구 프로세스(Software change request process)
효과적으로 S/W 변경 요구(SCR; Software Change Request) 프로세스를 이루기 위해서는 변경 요구 생성, 변경 프로세스 흐름의 강제, CCB 결정의 획득 및 변경 프로세스 정보의 보고를 위한 지원도구 및 절차를 사용해야. 또한 본 도구의 기능(capability)과 문제 보고 시스템의 연계는 보고된 문제의 해결책을 추적하는 데 많은 도움이 됨.
3.2. S/W 변경 구현(Implementing Software Changes)
승인된 SCR은 기 정의된 S/W 절차 및 일정에 따라 구현되는데, 많은 SCR이 동시에 구현될 수 있기 때문에 SCR과 연계된 S/W 버전과 기준선의 추적을 위한 수단이 요구됨. 변경 프로세스 종료 부에서는 완료된 변경에 대한 형상 감사와 S/W 품질 검증(verification)이 수행되는데, 본 활동에는 승인된 변경만이 적용되었는지 여부에 대한 검증도 포함됨. 변경 요구 프로세스는 보통 변경에 대한 SCM 승인 정보의 문서화 역시 함께 이룸.
변경의 실제 구현은 라이브러리 도구에 의해 지원되는데, 본 도구의 기능으로 버전 관리 및 코드 저장소 지원이 있음. 최소한 이들 도구는 체크 인/아웃과 관련 버전 제어 기능을 지원함. 좀더 강력한 도구는 병렬적 개발 및 지리적으로 분산 환경을 지원하기도. 또한 이들 도구는 독립적 SCM 그룹의 통제 아래 특화 응용프로그램으로 지정되기도 하며, SWE 환경의 핵심부가 되기도.
3.3. 편차와 포기(Deviations and Waivers)
SWE 노력에 부가된 제한조건 또는 개발 활동 중 만들어진 명세에는 생명 주기 중 지정된 시점에 충족될 수 없는 조항(provision)이 있을 수 있음. 편차(deviation)란 특정 조항에 대한 개발에 앞서 해당 조항에서 벋어나도 괜찮음을 나타내는 권한임. 포기(waiver)란…(deviation is an authorization to depart from a provision prior to the development of the item. A waiver is an authorization to use an item, following its development, that departs from the provision in some way) 두 경우 모두에서 정형 프로세스는 조항에 대한 편차 및 포기(waiver)의 승인 취득을 위해 사용됨.

4. S/W 형상상태기록(SCSA; Software Configuration Status Accounting)
S/W 형상상태기록이란 효과적인 S/W 형상 관리를 위한 기록(recording) 및 보고임.
4.1. S/W 형상 상태 정보(Software Configuration Status Information)
S/W 형상상태기록(SCSA) 활동에는 생명주기 진행 중 필요 정보의 획득 및 보고를 위한 시스템의 설계 및 운용이 있음. 여느 정보 시스템에서와 마찬가지로, 형상의 진화를 위한 관리 대상인 형상 상태 정보는 반드시 식별, 수집 및 유지보수가 이루어져야 하는데, 다양한 이들 정보 및 측정은 SCM 프로세스 지원과 관리/SWE/타 관련 활동의 형상 상태 보고 등 다양한 용도로 사용됨. 정보의 유형에는 승인된 형상 식별 요소 뿐 아니라 식별 요소, 변경에 대한 현 구현 상태, 편차, 포기(waiver) 등이 포함됨.
SCSA 데이터 컬렉션 및 작업 보고를 수립하기 위해서는 자동화 도구의 지원이 필요함. 본 도구로서 데이터베이스라던가 독립적(standalone) 도구 또는 통합 도구 환경 등이 있음.
4.2. S/W 형상 상태 보고(Software Configuration Status Reporting)
보고된 정보는 다양한 조직적/프로젝트 요소, 즉 개발팀, 유지보수 팀, 프로젝트 관리, S/W 품질 활동 등에 사용될 수 있음. 보고는 특정 질문에 대한 답을 산출하는 질의(query) 또는 기 설계된 보고서의 주기적 산출물(production) 형식이 될 수도. 생명주기 중 상태기록에 의해 만들어진 정보는 품질 보증 기록이 될 수도 있음.
본 정보는 현 형상 상태에 대한 보고 뿐 아니라 SCSA를 통해 얻은 정보는 관리 이윤/개발/SCM에 대한 기조 자료가 됨. SCI에 대한 변경 요구 횟수 및 변경 요구 구현에 요구되는 평균 시간 등은 이에 대한 좋은 예임.

5. S/W 형상 감사(Software Configuration Auditing)
S/W 감사란 S/W 제품과 프로세스가 규제(regulation), 표준, 안내선(guideline), 계획, 절차에 대한 준수성(conformance) 평가하는 활동임(IEEE1208-97). 감사는 다양한 감사자의 역할 및 책임으로 구성된 프로세스에 따라 수행되기에, 각각의 감사 활동은 주의 깊게 계획되어야. 감사에는 짧은 기간 내 다양한 작업을 수행하기 위해 다수의 인원이 결부되기도 하며, 계획과 수행에 대한 지원 도구는 해당 프로세스 수행에 많은 도움이 됨.
S/W 형상 감사 활동에는 요청된 기능적/물리적 특성을 만족시키기 위한 항목의 범위 결정이 포함되기도 하는데, 본 비공식적 감사는 생명 주기에서의 주안점이 되기도. 주요 계약(governing contract)에는 기능적 형상 감사(FCA; Functional Configuration Audit)과 물리적 형상 감사(PCA; Physical Configuration Audit)란 두 개의 공식 감사가 요구되기도. 위 세 가지 감사는 제품 기준선 수립을 위한 사전 조건을 이룸.
5.1. S/W 기능 형상 감사(S/W FCA; Software Functional Configuration Audit)
S/W FCA의 목적은 S/W 항목이 주요 명세와 일관되는지의 여부 확인에 있음. S/W V&V(Verification and Validation) 활동 산출물은 본 감사를 위한 핵심 입력 값이 됨.
5.2. S/W 물리적 형상 감사(S/W PCA; Software Physical Configuration Audit)
S/W PCA의 목적은 설계 및 참조 문서가 만들어진 S/W 제품과 일관되는지 여부 확인에 있음.
5.3. S/W 기준선의 내부 공정 감사(In-Process Audits of a Software Baseline)
위에서도 언급했듯이, 감사는 특정 형상 항목의 현 상태를 조사하기 위해 개발 프로세스 중에 수행될 수 있어. 이 경우 감사는 예제 기준선 항목에 적용되는데, 본 목적은 성능의 명세 준수성의 확인 또는 개발 기준선에 맞도록 문서가 지속적으로 진화해가는지 여부의 확인에 있음.

6. S/W 릴리즈 관리 및 인도(Software Release Management and Delivery)
본 컨텍스트에서 '릴리즈(release)' 란 용어는 S/W 형상 항목에 대한 개발 활동 외부로의 분배(distribute)를 뜻하며, 여기에는 고객으로의 릴리즈 뿐 아니라 내부 릴리즈 역시 포함됨. S/W 항목의 각기 다른 버전이 인도(delivery) 가능할 경우(즉 각기 다른 플랫폼의 버전이라던가 각기 다른 기능성(capability)를 지닌 버전 등), 종종 특정 버전 및 패키지의 재생성이 이루어지곤 함. S/W 라이브러리는 릴리즈와 인도 작업의 핵심 요소임.
6.1. S/W 빌드(Software Building)
S/W 빌드란 적절한 형상 데이터를 통해, S/W 형상 항목의 바른(correct) 버전을 결합(combine)하여, 고객 또는 시험 팀 등의 타 수취자에게 인도(delivery)하기 위해 실행(executable) 프로그램으로 만드는 것을 뜻함. H/W나 펌웨어가 결부된 시스템의 경우, 실행 프로그램은 시스템 빌드 팀으로 인도됨. 빌드 명령(instruction)은 적합한 빌드 단계가 올바른 순서로 수행될 수 있도록 함. 또한 새로운 릴리즈를 위해 S/W 빌드가 이루어질 경우, SCM에 요구되는 사항으로 이전 릴리즈의 재생성 기능이 있는데, 이는 복구(recovery), 시험, 유지보수 또는 추가적 릴리즈를 위한 것임.
S/W는 컴파일러와 같은 지원 도구를 통해 빌드 되는데, 이때 해당 도구는 이전 빌드 S/W 형상 항목의 복사본을 재생성할 수 있어야. 이를 위해 지원 도구 및 관련 빌드 명령  버전 역시 SCM 통제 하에 있어야.
이들 도구는 S/W 항목의 정확한 버전 선택에 유용한데, 이를 통해 주어진 대상 환경에 맞는 버전 선택 및 적절한 형상 데이터를 통한 선택된 버전의 S/W 빌드 프로세스 자동화가 편리함. 특히 대규모의 병렬적/분산 개발 환경에서는 본 도구가 필수적임. 대부분의 SWE 환경은 본 기능을 갖추고 있으며, 스크립트 언어 또는 그래픽 기반의 등의 다양한 종류가 있음.
제품의 빌드 및 빌드 프로세스는 S/W 품질 검증 대상이 되기도. 빌드 프로세스에서 추출된 산출물은 이후를 위한 참조 데이터로 필요로 하게 되며, 때로는 품질 보증을 위한 기록이 되기도 함.
6.2. S/W 릴리즈 관리(Software Release Management)
S/W 릴리즈 관리 활동에는 제품 요소, 즉 실행 프로그램, 문서, 릴리즈 노트, 형상 데이터의 식별, 패키징, 인도가 포함됨. 제품 변경이 지속적으로 이루어질 경우, 고려해야 할 사항 중 하나는 릴리즈의 발행(issue) 시점의 결정이며, 문제의 심각성과 이전 릴리즈의 결함 밀도 측정 결과가 본 결정에 미치는 주요 인자임. 패키징 작업에서는 어떤 제품 항목을 인도할 것인지를 식별한 후, 이들 항목에 대한 올바른 배리언트의 선택이 이루어짐. 릴리즈의 물리적 내용이 담긴 정보는 버전 기술 문서(version description document)라 하는 한편, 릴리즈 노트는 보통 새 기능, 알려진 문제, 적절한 제품 운용을 위한 플랫폼 요구사항을 기술함. 또한 패키지에는 설치 및 업그레이드 안내서가 담김. 마지막으로, 릴리즈 관리 활동에는 여러 고객 및 대상 시스템에 배포된 제품의 추적이 있음.
상기 릴리즈 관리는 관련 지원 도구를 통해 효과적으로 이룰 수 있으며, 본 도구의 주요 기능 중 하나는 각 릴리즈와 SCR에 대한 매핑 및 다양한 대상 플랫폼 및 고객 환경의 정보 유지임.

 

[주의 사항]
IEEE에서 제작한 본 SWEBOK에는 무시하기 어려운 비판론이 제기된 상황입니다. 주된 비판 주체로 초기에 본 문서 제작에 참여했다 철수한 ACM이 있으며, Grady Booch, Cen Kaner가 보입니다. 비판의 핵심은 본 문서가 주장하는 바인 'Generally accepted'가 사실이 아니라는 점과 본 문서와 밀접히 연계된 licensing(CSDP)의 무효성입니다.

상기 비판론을 염두하여 문서에 대한 내용을 받아들이길 권장합니다.

Introduction
생명주기의 유지보수 단계(phase)는 보증(warranty) 기간 또는 인수의 후-구현(post-implementation) 단계를 따라 시작되지만, 유지보수 활동은 좀더 일찍 시작됨.
그간 유지보수는 S/W 생명 주기의 주요 활동임에도 불구하고 대부분의 조직에서 타 활동에 비해 덜 중요시 되었지만, 이제는 S/W 개발에 투자하기 보다는 기 운용되는 S/W를 최대한 유지하려고 하기에 주목 받고 있음. Y2K 문제는 S/W 유지보수에 좀더 관심을 갖게 하였고, Open Source 패러다임은 타인에 의해 개발된 개발물에 대한 유지보수의 필요성을 더욱 부각시켜.
본 안내서는 S/W 유지보수를 비용-효과적인 S/W 지원에 요구되는 활동의 총체로 정의함. 본 활동은 인수 후(post delivery) 활동 뿐 아니라 인수 이전 단계에서도 수행됨. 인수 이전 단계의 활동은 유지보수를 위한 인수 후 운영 계획 및 이전(transition) 활동을 위한 세부계획 결정(logistics determination)을 포함함. 인수 후 활동에는 S/W 수정, 훈련, 운영 및 help desk와의 연계(interface)가 포함됨. S/W 유지보수 KA는 모든 타 SWE 측면과 연계됨.

Breakdown of topic

1. S/W 유지보수 기본(Software Maintenance Fundamentals)
본 섹션은 S/W 유지보수의 역할과 범위를 이해하는 데 요구되는 하부 기반 형성을 이루는 개념과 용어를 소개함. 본 섹션은 또한 유지보수의 필요성에 대한 정의와 강조를 이룸. S/W 유지보수의 카테고리는 기반 의미의 이해를 위해 중요.
1.1. 정의 및 용어(Definitions and Terminology)
IEEE1219 S/W 유지보수 표준에서 S/W 유지보수는, 인수 후 S/W 제품 수정을 통한 결함 교정, 성능 또는 타 속성의 향상 또는 변경된 환경에 대한 제품의 적응으로 정의되며, 인수 이전의 유지보수 활동에 대해서도 다룸.
S/W 생명주기에 관한 IEEE 12207 표준은 유지보수를 주요 생명주기 공정의 하나로 다루며, "문제 또는 향상 요구에 대한 코드 및 관련 문서의 변경. 기존 S/W 제품의 완전성(integrity) 유지를 위한 수정"의 프로세스로 기술함.
ISO/IEC 14764, S/W 유지보수의 국제표준에서는 IEEE12207과 동일한 정의를 따르며 계획과 같은 인수 이전의 유지보수 활동을 강조함.
1.2. 유지보수의 본성(Nature of Maintenance)
S/W 유지보수는 운영 생명주기를 통해 S/W 제품을 다룸(sustain). 수정 요구는 로그로 남겨지고 추적되며, 제안된 변경의 영향 결정, 코드 및 타 S/W 인공물(artifact)의 수정, 시험 수행 및 새 버전이 인도됨. 또한 사용자에 대한 훈련과 일일 지원이 이루어짐. 유지보수는 개발보다 더 넓은 영역을 다룸.
IEEE 12207에서 S/W 유지보수의 주요 활동을 다음과 같이 식별함; 프로세스 구현, 문제 및 수정 분석, 수정 구현, 수정 검토/승인, 이전(migration), 폐기. 이들 활동은 3.2 유지보수 활동에서 다룸.
유지보수자(maintainer)는 개발자의 S/W에 대한 지식을 배우며, 개발자와의 계약이나 유지보수자의 조기 개입은 유지보수 노력을 줄이는 데 도움이 됨.
1.3. 유지보수의 필요성(Need for Maintenance)
유지보수는 사용자 요구사항을 지속적으로 만족시키기 위해 필요하며, 어떤 S/W 생명 주기 모형을 사용한 S/W 개발에도 적용됨. 시스템은 수정적(corrective) 및 비 수정적 S/W 행동으로 인해 변경됨. 유지보수의 목적으로,
 ○ 결함 교정(correct)
 ○ 설계 향상
 ○ 구현 향상
 ○ 타 시스템과의 연동(interface)
 ○ 타 H/W, S/W, 시스템의 기능 사용을 위한 프로그램 적용
 ○ 기존(legacy) S/W 이전(migrate)
 ○ S/W 폐기가 있음.
유지보수자의 활동은 네 개의 주요 활동으로 요약됨.
 ○ S/W의 일일 기능에 대한 제어 유지보수
 ○ S/W 수정에 대한 제어 유지보수
 ○ 기존 기능의 완전화(perfecting)
 ○ S/W 성능의 수용 불가한 수준으로 낮아짐에 대한 방지
1.4. 유지보수 비용의 주요 용처(Majority of Maintenance Costs)
S/W 유지보수는 S/W 생명주기를 위한 재정적 자원 주된 부분을 소비함. 유지보수에 대한 일반적 인식은 단순히 결함 수정에 불과하지만, 각종 연구와 조사에 따르면, S/W 유지보수 노력의 80% 이상이 비수정적 활동에 사용됨.
S/W 유지보수는 교정(correction) 뿐 아니라 그룹의 향상에도 결부되는데, 이 점 역시 높은 교정 비용의 한 원인임. S/W 유지보수 카테고리의 이해 및 시스템의 유지보수성에 미치는 인자에 대한 이해 역시 S/W 유지보수 비용 구조의 이해에 도움이 됨. 본 인자의 기술/비기술적 내용은 다음과 같음
 ○ 응용프로그램의 유형
 ○ S/W의 새로움 정도(novelty)
 ○ S/W 유지보수 스태프의 능력
 ○ S/W 생명 기간
 ○ H/W 특성
 ○ S/W 설계, 작성, 문서화, 시험 품질
1.5. S/W의 진화(Evolution of Software)
유지보수는 진화적 개발로서, 유지보수 결정은 시간이 지나면서 시스템(및 S/W)에 어떤 일이 벌어졌는지를 이해하는 데서 출발함. 유지보수는 결코 끝나지 않고 지속된다는 점을 제외하면 개발의 연장으로 바라볼 수도. 진화에 따라 복잡도는 증대됨(따로 복잡도 감소를 위한 활동을 이루지 않는 이상.)
S/W 는 정규적 행동과 경향을 보이기에 측정이 가능함. 유지보수 노력을 추정하기 위한 예측 모형이 개발되어, 유용한 관리 도구가 존재함.
1.6. 유지보수 카테고리(Categories of Maintenance)
ISO/IEC 14764는 S/W 유지보수를 네 개의 카테고리로 나눔.
- 교정적 유지보수 : S/W 제품에 대한 반응적 수정으로, 인수 이후에 발견된 문제를 교정하기 위함.
- 적응적 유지보수 : 인수 이후의 S/W 제품에 대한 수정으로, S/W 제품이 변화된/변화 진행중인 환경에서 사용 가능하도록 하는 데 목적이 있음.
- 완전적 유지보수 : 성능 및 유지보수성 향상을 위한 인수 이후의 S/W에 대한 수정.
- 예방적 유지보수 : S/W 제품에서 결함이 드러나기 전에 사전에 탐지 및 교정하는 데 목적을 둠.
IEEE 14764는 Table 1에서처럼, 적응적/완전적 유지보수를 향상 카테고리로, 교정적/예방적 유지보수를 교정 카테고리로 묶음. 가장 나중에 나타난 예방적 유지보수는 안전성이 중요(critical)할 경우에 종종 수행됨.

2. S/W 유지보수의 주요 이슈(Key Issues in Software Maintenance)
유지보수는 그 자체를 위한 기술 및 관리 이슈를 낳는데, 500K 줄의 코드에서 결함을 찾는 것은 한가지 예. 또한 제한된 자원의 효율적 운용, 다음 배포를 위한 코딩 중의 미래를 위한 배포 계획, 현 배포에 대한 응급 패치 역시 여기에 속함. 이들 사항은 아래 네 개의 토픽으로 정리됨
 ○ 기술적 이슈
 ○ 관리적 이슈
 ○ 비용 추정
 ○ 측정
2.1. 기술적 이슈(Technical Issues)
1. 제한된 이해(Limited understanding)
제한된 이해란 S/W 기술자가 변화 또는 교정이 요구되는 S/W의 위치를 얼마나 빨리 이해할 수 있는지를 뜻함. 약 40 ~ 60%의 유지보수 노력이 이해에 사용된다는 연구가 있어, S/W 이해는 매우 중요.
텍스트 기반의 표현, 즉 소스코드의 이해는 더 어려운데, S/W 개발자의 설명 및 관련 문서가 없는 상황에서의 S/W의 변화 추적은 이의 한 예. 따라서 S/W 기술자는 초기에 S/W에 대한 이해도가 낮을 가능성이 크며 이를 해결하는 데 많은 노력이 요구됨.
2. 시험(Testing)
재귀 시험은 중요한 유지보수 활동이지만 이를 위한 시간을 얻기란 어려움. 또한 유지보수 팀 멤버 각각이 동시에 각기 다른 문제를 다룰 경우에 대한 조정(coordinating) 시험 역시 문제. 또한 S/W가 중요 기능을 수행할 경우에는 이를 offline으로 만들어 시험하는 것도 불가능. S/W 시험 KA의 2.2.6. 회귀 시험에서 이에 대한 문제를 다룸.
3. 영향 분석(Impact analysis)
영향 분석은 기 S/W의 변화에 따른 영향 분석을 어떻게, 비용 효과적으로 이룰지에 대해 다룸. 유지보수자는 S/W의 구조와 내용에 대해 사전 파악하여, 영향 분석, 즉 변화 요구가 미치는 시스템 및 S/W 및 이를 위한 자원을 추정해야 하며, 이에 따른 위험도 역시 결정해야 함.
수정 요구(MR; modification request) 또는 문제 보고(PR; Problem Report)라고 불리는 변화 요구는 먼저 S/W 용어로 분석 및 번역되어야 하며, 이는 S/W 형상 관리 공정에 변화 요구가 입력된 후에 수행됨. 영향 분석의 목적으로는,
 ○ 작업의 계획 및 구현(implement)을 위한 변화 범위 결정
 ○ 해당 작업 수행에 필요한 자원에 대한 정확한 추정 개발
 ○ 요구된 변화의 비용/이익 분석
 ○ 타인과의 변화로 인한 복잡도에 대한 논의
문제의 중요도(severity)는 문제 해결 방법 및 시점 결정에 종종 사용되며, 이후에 S/W 기술자는 영향을 받는 컴포넌트를 식별함. 여러 잠재적 해결책이 제시되며, 최선의 방법으로 권고안이 만들어짐.
유지보수를 감안한 S/W 설계는 영향 분석에 많은 도움이 됨. S/W 형상 관리 KA 참조.
4. 유지보수성(Maintainability)
IEEE610.12-90에서 정의하는 유지보수성이란 특정 요구사항을 만족시키기 위한 유지보수, 향상, 적응, 교정의 쉬운 정도이며, ISO/IEC는 이를 품질 특정의 하나로 정의함(ISO9126-1).
유지보수성의 하위 특성은 S/W 개발 활동 중에 지정,검토, 제어되어야 하며, 이는 유지보수 비용을 줄이기 위함임. 하지만 이는 달성되기 어려운 사항인데, S/W 개발자는 유지보수 요구사항보다는 타 요소에 더 많은 집중하기 마련이기 때문. 이는 시스템 문서의 빈약함으로 나타나 프로그램 이해와 영향 분석의 난해성의 가장 큰 원인으로 작용. 
시스템적, 성숙된 프로세스, 기법 및 도구는 시스템의 유지보수성에 많은 기여를 함.
2.2. 관리 이슈(Management Issues)
1. 조직 목표로의 정렬(Alignment with organizational objectives)
조직 목표는 S/W 유지보수 활동에 대한 투자의 성과를 어떻게 이끌어내는지에 대해 기술. 
S/W 개발은 주안점은 시간과 예산에 맞춰 사용자의 요구를 달성 및 인수에 있는 반면(프로젝트 기반), S/W 유지보수는 S/W 생명의 연장에 있으며,  S/W 갱신과 향상이 필요한 사용자의 요구에 의해 주도됨. 이들 두 가지 목적 모두에서 ROI는 명확하지 않음.
2. 유지보수자 형성(staffing)
스태핑은 S/W 유지보수를 위한 인력을 어떻게 끌어들이고 유지하느냐를 뜻함. 유지보수는 그다지 매력적인 작업으로 비춰지지 않음. S/W 유지보수 인원은 "2등 시민(second-class citizens)"으로 비춰져 사기(morale)에 안좋은 영향을 미친다는 연구 결과가 있음.
3. 프로세스(Process)
S/W 프로세스 수준에서 유지보수 활동은 S/W 개발과 많은 부분에서 공유되는 동시에(ex. S/W 형상 관리), S/W 개발에는 없는 다양한 활동이 있으며, 이들 활동이 바로 관리를 요구함.
4. 유지보수의 조직적 측면(Organizational aspects of maintenance)
조직적 측면이란 S/W 유지보수에서의 조직 및 기능의 책임에 대한 식별 방법을 뜻함. 유지보수는 해당 S/W 개발자 또는 타 인원으로 수행될 수도 있는데, 이들 두 선택지에 대한 결정은 상황에 따라 달라짐. 핵심은 조직의 구조에 상관없이 유지보수 책임을 부여하는 것임.
5. 외주(Outsourcing)
유지보수의 외주는 주요 산업으로 발전했지만, 보통 본 선택지는 비즈니스 상 덜 중요한 부문에서 사용되거나(해당 회사 그들의 핵심 사업에서 제어권을 상실하지 않기 위해.), 유지보수 전략 통제 방법을 찾았을 때만 유지보수 보수를 수행함. 
유지보수의 주요 부각 점 중 하나는 유지보수 서빙의 범위 및 계약 상세 사항을 결정하는 것임. 자료에 의하면 50%의 외주 업체가 명확한 SLA 없이 서비스를 제공하며, 이들 업체는 보통 계약 관계에 이르기까지 S/W를 평가하는 데 수 개월이 걸림.
2.3. 유지보수 비용 추정(Maintenance Cost Estimation)
계획에 있어 비용 추정은 S/W 유지보수의 중요한 측면임.
1. 비용 추정(Cost estimation)
2.1.3 영향 분석에서 비용 추정을 이룸. 유지보수 비용 추정은 많은 기술/비기술 인자에 의해 영향을 받아. ISO/IEC 14764에서는 "S/W 유지보수를 위한 자원 추정의 가장 인기있는 접근법은 parametric 모형과 경험의 사용이다"라고 하며, 종종 이들 둘은 조합되어 사용됨.
2. Parametric 모형(Parametric models)
본 모형은 이전 프로젝트의 데이터를 사용함. 기능 점수(Function Points)는 한 예.
3. 경험 기반 모형(Experience)
전문가 판단(ex. 델파이 기법의 사용을 통해)의 형태인 경험, 유추, WBS(Work Breakdown Structure)는 parametric 모형에서 데이터를 늘리기 위해 사용됨.  유지보수 추정에 대한 최고의 접근법은 경험적 데이터와 실험의 조합으로, 이들 데이터는 프로그램 측정의 결과로 제공되어야.
2.4. S/W 유지보수 측정(Software Maintenance Measurement)
네 개의 카테고리로 SEI가 식별한 S/W 측정기준, 즉 크기, 노력, 일정, 품질은 보편적으로 받아들여짐. 이들 측정기준은 유지보수자의 좋은 시작점임. 공정 및 제품 측정은 SWE 공정 KA에서 논하며, S/W 측정 프로그램은 SWE 관리 KA에서 논함.
1. 특정 측정(Specific Measures)
유지보수자는 어떤 측정기준이 해당 조직에 알맞은지를 결정해야. IEEE1219-98, ISO9126-1은 S/W 유지보수 측정 프로그램에 좀더 특화된 측정기준을 제시하는데, 이들은 유지보수성의 네 가지 부특성 각각에 대한 측정기준을 포함함.
 분석가능성(Analyzability) : 실패의 원인 또는 결핍, 수정 부분 식별에 필요한 유지보수자의 노력을 측정
 변경가능성(Changeability) : 특정 수정을 수행하는 데 연계된 유지보수자의 노력을 측정
 시험가능성(Testability) : 수정된 S/W를 시험하는데 요구되는 노력을 측정
S/W 유지보수성에 대한 몇몇 측정기준은 상용 도구를 통해 얻기도 함.

3. 유지보수 공정(Maintenance Process)
3.1. 유지보수 공정(Maintenance Processes)
유지보수 공정은 필요한 활동 및 이들 활동에 필요한 세부 입/출력을 제공하며, 이들은 IEEE 1219 및 ISO/IEC 14764에 기술됨.
IEEE1219에 기술된 유지보수 공정 모형은 인수-후 단계에서 시작되며, 유지보수를 위한 계획 등에 대해 논의함. Figure 2는 본 공정을 나타냄.

Figure 2. The IEEE1219-98 유지보수 공정 활동

ISO/IEC 14764 [ISO14764-99]는 IEEE 12207.0-96 유지보수 공정을 다듬은 것으로, ISO/IEC 유지보수 공정은 약간 다르게 취합되었다는 점을 제외하고는 IEEE의 것과 유사함. Figuire 3은 ISO/IEC의 유지보수 공정 활동임 

Figure 3. ISO/IEC 14764-00 S/W 유지보수 공정

ISO/IEC 14764의 주요 S/W 유지보수 활동은 다음과 같이 세부적으로 나뉨.
 ○ 공정 구현(process Implementation)
 ○ 문제 및 수정 분석(Problem and Modification Analysis)
 ○ 수정 구현(Modification Implementation)
 ○ 유지보수 검토/승인(Maintenance Review/Acceptance
 ○ 이전(Migration)
 ○ S/W 폐기(Software Retirement)
이들 이외에 타 모형도 존재하며 이 중 agile 방법론은 가벼운 공정을 추구하는데, 이는 빠른 유지보수 서비스의 순환(turn-around)의 지속적으로 증가하는 요구에 따라 부각된 것임.
3.2. 유지보수 활동(Maintenance Activities)
이미 논의되었던 바와 같이 유지보수 활동은 S/W 개발과 유사하여, 유지보수자는 분석, 설계, 코딩, 시험 및 문서화를 수행해야 하며, 개발 활동에서처럼 요구사항을 추적하여 기준선 변경에 따라 문서를 갱신해야. ISO/IEC 14764 표준은 유지보수자가 유사한 개발 공정을 참조할 때 반드시 그의 지정된 요구에 맞게 적용해야 한다고 권고함. 하지만 S/W 유지보수의 경우 몇몇 활동은 S/W 유지보수에 고유한 활동임.
1. 고유 활동(Unique activities)
S/W 유지보수에만 존재하는 공정, 활동 및 프랙티스가 많아. 다음은 그 예임.
 ○ 전이(Transition) : S/W가 점진적으로 개발자에서 유지보수자로 넘어가는 동안에 벌어지는 일련의 활동 절차.
 ○ 수정 요구 수락/거부(Modification Request acceptance/rejection) : 크기/노력/복잡도가 결부된 몇몇 수정 요구는 유지보수자에게 거부되고 개발자에게 넘겨지기도.
 ○ 영향 분석(Impact Analysis) : 2.1.3 섹션 참고
 ○ S/W 지원(Software Support) : 정보 요구에 관계된 사용자로의 도움(ex. 비즈니스 규칙, 검증, 데이터 의미, 임의 요구/보고)
 ○ 서비스 수준 합의(SLAs; Service Level Agreements) : SLAs와 특화된(도메인 지정적) 유지보수자에게 책임이 부가되는 유지보수 계약
2. 지원 활동(Supporting activities)
유지보수자는 S/W 유지보수 계획, S/W 형상 관리, V&V, S/W 품질 보증(SQA), 검토, 감사, 사용자 훈련 등의 지원 활동을 수행함. 유지보수자 훈련 또한 필요로 함.
3. 유지보수 계획 활동(Maintenance planning activity)
S/W 유지보수의 중요 활동은 계획이며 유지보수자는 여러 계획 측면에 관련한 이슈를 염두해야.
 ○ 업무 계획(조직 수준)
 ○ 유지보수 계획(전이 수준)
 ○ 배포/버전 계획(S/W 수준)
 ○ 개별 S/W 변경 요구 계획(요구 수준)
개별 요구 수준에서의 계획은 영향 분석 기간에 이루어지고, 배포/버전 계획 활동에서 유지보수자는 다음과 같은 활동이 요구됨.
 ○ 각 요구에 대한 가능 일자 산정
 ○ 뒤따르는 배포/버전의 내용에 대한 사용자와의 합의
 ○ 잠재적 충돌 식별 및 대안 마련
 ○ 해당 배포의 위험 평가 및 문제 발생 상황에 대한 대비책 마련
 ○ 모든 이해당사자로의 알림(inform)
S/W 개발은 몇 달에서 몇 년의 한정된 기간 내 이루어지는 반면, 유지보수는 보통 여러 해에 걸쳐 지속되므로, 자원의 산정은 유지보수 계획의 핵심 요소임. 자원은 반드시 개발자의 프로젝트 계획 예산에 포함되어야. 
S/W 유지보수 계획은 새 시스템의 개발 결정으로 시작해야 하고 품질 목표를 고려해야 함. 또한, 유지보수 개념 문서(concept document)가 유지보수 계획에 따라 마련되어야 하는데, 여기에는,
 ○ S/W 유지보수 범위
 ○ S/W 유지보수 공정의 적용
 ○ S/W 유지보수 조직의 식별
 ○ S/W 유지보수 비용의 추정이 포함됨.
다음 단계는 해당 S/W의 유지보수 계획의 마련임. 본 계획은 S/W 개발 중에 준비되어야 하고 사용자가 어떻게 S/W 수정을 요구할지 및 어떻게 문제를 알릴지를 적시하여야. S/W 유지보수 계획은 IEEE 1219 및 ISO/IEC 14764에서 다루며, ISO/IEC 14764는 본 계획에 대한 안내를 제공함.
마지막으로 최고 수준의 단계에서, 유지보수 조직은 업무 계획 활동(경비, 예산, 인적 자원)을 타 조직의 모든 부서에서와 마찬가지로 수행하여야.
4. S/W 형상 관리(Software configuration management)
IEEE 1219에서는 S/W 형상 관리를 유지보수 공정의 핵심 요소로 기술함. S/W 형상 관리 절차는 검증, 확인 및 식별, 권한 설정(authorize), 구현에 요구되는 각 단계에 대한 감사, 그리고 S/W 제품 배포를 규정함.
단순히 수정 요구 또는 문제 보고 추적으로는 충분하지 않아, S/W 제품과 발생된 변경은 반드시 통제되어야 함. 본 통제는 승인된 S/W 형상 관리(SCM; Software Configuration Management) 공정의 구현 및 강제를 통해 이루어짐. SCM의 세부 사항은 S/W 형상 관리 KA에서 다루며, 여기서는 S/W 변경 사항이 제출, 평가, 승인되는 프로세스에 대해 논함. S/W 유지보수에 대한 SCM은 S/W 개발에 대한 SCM과는 달라, 운영 S/W의 작은 변화라도 반드시 통제되어야 함. SCM 공정은 기 마련된 형상 관리 계획 및 운영 절차에 따라 구현되고, 유지보수자는 형상 통제 위원회(CCB; Configuration Control Boards)에 참여하여 다음 배포/버전의 내용을 결정함.
5. S/W 품질(Software Quality)
S/W 유지보수를 통해 품질이 향상될 것이라는 단순한 희망으로는 충분치 않아, 유지보수 공정 지원을 위한 계획이 마련되고 공정이 구현되어야 함. S/W 품질 보증(SQA; Software Quality Assurance), V&V, 검토 및 감사를 위한 활동 및 기법은 원하는 수준의 품질을 달성하기 위한 타 공정과 조화를 이룰 수 있게 선택되어야. 유지보수자가 일시적(instance) 시험 문서 및 시험 결과를 위해 S/W 개발의 공정, 기법 및 인도물을 적용하는 것 역시 추천됨(IEEE14764).
세부 사항은 S/W 품질 KA 참조.

4. 유지보수 기법(Techniques for Maintenance)
4.1. 프로그램 이해(Program Comprehension)
프로그래머는 변경 사항을 구현하기 위해 프로그램 읽기 및 이해에 적지 않은 시간을 보내는데, 코드 브라우저(browsers)는 프로그램 이해를 위한 핵심 도구임. 명료하고 간결한 문서 역시 프로그램 이해에 많은 도움이 됨.
4.2. 재공학(Re-engineering)
재공학은 S/W를 새 형태(form)으로 재구성하기 위한 S/W의 시험(examination) 및 변경(alteration)으로 정의되며, 뒤로 이어지는 새 형태의 구현 역시 포함함. 재공학은 가장 급진적(그리고 비싼)인 변경이지만, 소규모 변경에도 수행되기도. 재공학은 유지보수성 향상이 아니라 노후된 기존(legacy) S/W를 교체하기 위해 종종 사용됨.
4.3. 역공학(Reverse Engineering)
역공학은 S/W의 컴포넌트와 이들간 상호관계 식별 및 또 다른 형태 또는 더 높은 추상 수준에 대한 표현물에 대한 생산을 위한 S/W 분석 공정임. 역공학은 수동적 속성을 지녀, S/W를 변경하거나 새로운 S/W를 만드는 활동이 아님. 역공학은 제품 소스코드의 호출 그래프와 제어 흐름도의 생산에 초점이 맞춰짐. 
역공학의 종류로, 재문서화(redocumentation) 및 설계 복구가 있으며, 리팩토링(refactoring)은 S/W 행동 변경을 배재한 상태에서 프로그램에 대한 재조직화를 통한 변형(transformation)으로, 프로그램 구조 향상을 위한 역공학의 한 형태임. 데이터 역공학은 요 몇 년간 주목을 받아왔는데, 이는 물리 데이터베이스에서 논리 스키마를 복구하는 활동임.