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)으로, 프로그램 구조 향상을 위한 역공학의 한 형태임. 데이터 역공학은 요 몇 년간 주목을 받아왔는데, 이는 물리 데이터베이스에서 논리 스키마를 복구하는 활동임.