출처 : https://mini-noriter.tistory.com/31
포인트1. 유지보수 작업과 개발 작업의 차이는 무엇인가?
포인트2. 유지보수 작업 과정은 무엇인가?
포인트3. 형상관리 작업이란 무엇이며 그 절차와 방법은 무엇인가?
포인트4. 역공학과 리엔지니어링이란 무엇이며 어떻게 하는가?
포인트5. 유지보수 작업 방법과 지원 도구에는 어떤 것이 있는가?
유지보수 - 개발 후에 이루어지는 소프트웨어의 변경 작업
- 유지보수 단계는 소프트웨어가 가장 유용하게 활용되는 기간
- 소프트웨어는 환경과 비즈니스 요구에 따라 진화한다
11-1. 유지보수의 소개
- 레거시 시스템(Legacy System)
수십 년 전에 구축되었지만 지금까지 사용되고 있는 소프트웨어 시스템
- 레거시 시스템을 대체하지(=소멸하지) 못하는 이유
- 대체하기 위해서는 비용이 많이 들기 때문
- 전문가, 사용자들의 수십 년 동안의 경험, 지능이 녹아 있기 때문
- 새로운 시스템이 더 좋다는 보장이 없기 때문
11-1-1. 변경의 이유와 유지보수 유형
>> 시스템의 릴리스, 배포, 설치 후에는 여러가지 이유로 변경이 필요하게 됨
- 버그 제거
- 운용 단계에서 버그가 발생하면 제거해야 함
- 변경된 소프트웨어가 예전에 선택된 테스트에 대하여 통과 여부를 가리는 리그레션 테스트 필요
- 운영 환경의 변화
- 하드웨어, 플랫폼, 시스템 형상의 변화
- 정부 정책, 규례의 변화
- 정부 정책, 규례에 의한 소프트웨어 변화가 불가피
- 비즈니스 절차의 변화
- 예를 들어 보안이 중요해졌다면 웹 기반 시스템은 사용자 인증을 강화하기 위해 사용자에게 개인 인증의 질문을 추가한다
- 미래 문제를 배제하기 위하여
- 미래에 일어날 수 있는 문제를 피하기 위함
- 예를 들어 신뢰성을 개선하기 위하여 복잡한 컴포넌트(독립적 단위모듈)를 다시 설계하고 다시 구현한다
>> 유지보수 유형에는 어떤 것들이 존재하는가?
- 수정형 유지보수(Corrective Maintenance)
- 발견된 결함을 고치기 위하여 소프트웨어 제품을 수정
- 적응형 유지보수(Adaptive Maintenance)
- 변경된 환경에서도 계속 사용할 수 있도록 소프트웨어를 이식하거나 변경
- 완전형 유지보수(Perfective Maintenance)
- 소프트웨어 설치 후에 성능이나 유지보수성을 개선하기 위해 실시하는 유형
- 코드의 기능 및 효율성 향상과 사용자의 요구 변화에 따라 시스템의 기능을 변경
- 사용자에 의한 기능 보강 요청에 의해 발생하는 유지보수
- 예방형 유지보수(Preventive Maintenance)
- 오류 발생을 방지하기 위해 수행하는 유지보수
11-1-2. Lehman의 법칙
- 시스템의 타입
- E 타입 - 시스템이 계속 진화하는 타입, 확실하게 정의가 불가능한 시스템 ( Lehman의 법칙 적용 가능 )
- S 타입 - 완전히 확실하게 정의할 수 있는 타입 ( 예 - 체스 게임, 수학 S/W )
>> Lehman의 법칙
1. 지속적인 변경의 원칙 (Law of continuing change)
- 시스템이 릴리스 된 후 변경은 그 시스템이 대체될 때 까지 변경됨
- 시스템의 요구는 항상 변화하기 때문에 소프트웨어가 사용되려면 계속 좋은 방향으로 진화되어야 함
2. 엔트로피, 복잡도 증가의 법칙 (Law of increasing entropy or complexity)
- 시스템의 구조는 변경되면서 더 나빠진다 -> 변경이 오류를 유발, 더 많은 변경을 요구하기 때문
- 시스템이 변경될 수록 그 구조는 더 복잡해지고, 구조를 단순화 하기 위해 많은 노력이 필요함
- 유지보수 비용을 줄이기 위하여 시스템 구조를 개선하는 재구조화 또는 리엔지니어링이 필요함
3. 자기 통제의 법칙 (Law of self-regulation)
- 시스템이 계속 피드백 되기에 가능
- 안정성 유지의 법칙, 친근성 유지의 법칙, 지속성 성장의 규칙을 일반화 한 것
4. 안정성 유지의 법칙 (Law of organizational stability)
- 진화하는 시스템의 유지보수 프로세스는 시스템이 소멸할 때 까지 일정한 평균 작업량을 보임
5. 친근성 유지의 법칙 (Law of familiarity)
- 시스템의 평균 성장률은 소멸될 때 까지 일정함
- 시스템 개발 전 단계에 걸쳐 각 버전의 변화는 거의 일정
6. 지속적 성장의 법칙 (Law of continuing growth)
- E 타입의 시스템은 사용자를 만족시키기 위하여 기능적 성장을 계속하여야 함
7. 품질 저하의 법칙 (Law of declining quality)
- E 타입 시스템의 품질은 운영 환경의 변화에 완전히 적응하지 못하는 한 저하됨
8. 피드백 시스템의 법칙 (Law of feedback systems)
- 진화 프로세스는 여러 단계의 여러번 반복, 중요한 역할을 담당하는 여러 관련자들의 피드백으로 구성됨
11-2. 유지보수 작업 과정
소프트웨어 개발은 코딩 중심의 작업이며, 유지보수는 이해 중심의 작업이다
11-2-1. 유지보수 작업
>> 유지보수 작업에 포함되는 기본적 작업들
1. 현재 프로그램의 이해
- 소프트웨어 엔지니어는 변경 전에 소프트웨어를 알아야 함
- 프로그램 로직을 추적하거나 요구, 설계 등에 대한 이해가 필요함
2. 변경 파악과 분석
- 필요한 변경을 파악, 그 영향도와 소요 비용, 변경에 의한 리스크를 분석
3. 변경 영향 파악
- 시스템 컴포넌트에 가해진 변경은 다른 컴포넌트에 영향을 줄 수 있음
- 따라서 변경의 이해당사자들에게 알리고 피드백을 얻어야 함
4. 변경 구현, 테스트, 설치
- 구현으로부터 설계를 복구하거나 변경된 요구를 만족시키기 위하여 설계를 변경할 수도 있음
- 변경 반영을 위해 시스템을 수정
- 시스템이 올바로 고쳐졌는지 확인하기 위하여 통합, 승인, 시스템 테스트 실시
11-2-2. 유지보수 프로세스
소프트웨어에 유지보수성을 형성하기 위한 요구가 어떤 것인지 인식하기 위하여 모델이 필요함
- 즉시 수정 모델
- 문제가 발견, 확인되면 가능한 빨리 문제를 해결하는 방식
- 장기적인 효과를 자세히 분석하지 않고 바로 수정하며 문서 수정은 최소화
- 오늘날도 많이 사용
- 장점
- 한 두명의 유지보수 담당자가 시스템을 잘 알고 있고 상세한 문서 없이 관리할 수 있으면 적절한 모델
- 고객의 빠른 수정요구를 적용할 수 있음
- 단점
- 한 두명의 유지보수 담당자가 시스템을 잘 알고 있으며 문서 없이 관리할 수 있는 상황이 흔하지 않음
- 잘못하면 매우 어렵고 비용이 많이 드는 문제를 초래할 수 있음
- 변경 효과(ripple effect)를 간과할 수 있음 - 파급된 더 이상의 수정을 잘못된 것으로 몰아갈 수 있음
- 인력과 자원이 긴급 보수에 투입되어야 함 -> 문서 변경에 투자하는 시간 감소 -> 오류 탐색 기회 감소
- 반복적 개선 모델
- 소프트웨어에 대한 변경이 전체 생명주기 단계에 반복적으로 일어나 시스템이 계속된다는 전제
- 변경이 일어나게 되면 새 시스템의 개발이라는 반복 사이클이 시작되는 것
- 현재 시스템의 요구 명세와 설계는 변경을 구축하는 데 기초가 됨
- 즉시 수정 모델을 더 체계화된 형태로 만들어낸 것
- 문제점
- 완벽한 문서화, 유지보수 팀이 시스템을 완전히 분석할 능력이 있다는 것을 전제 - But, 흔하지 않음
- 재사용 중심 모델
- 유지보수 작업을 프로그램 컴포넌트의 재사용이라고 본다
>> 재사용 개념
- 재사용 후보가 될 만한 시스템의 부품을 파악
- 시스템의 부품을 이해
- 시스템 부품을 새로운 요구에 맞추어 변경
- 변경된 부품을 새 시스템으로 통합
재사용 모델은 컴포넌트 분류, 변경을 가능하게 하는 프레임워크가 필요
- 재사용 컴포넌트를 위한 저장소가 필요, 재사용 컴포넌트 선택, 맞춤화 작업을 지원해야 함
- 유지보수 프로세스 모델의 비교
11-2-3. 프로그램의 이해
프로그램 이해 - 원시코드로부터 설계나 명세를 추출하여 멘탈 모델로 표현하는 것
>> 개발 프로세스(문제의 정의 -> 프로그램 개발)와는 반대로 추상성을 추구
- 상향식(bottom-up) & 묶음화(chunking)의 원리 사용
- 원시코드에서 의미 있는 묶음과 표시를 발견/기억하여 더 큰 구조로 올라가 모든 시스템이 이해될 때 까지 반복
11-2-4. 변경 파악과 분석
유지 보수는 변경 요구를 기초로 어떤 부분을 변경할지 찾아내야 한다
- 변경 분석
- 여러가지 방안을 평가하고 추구하여야 할 방안을 선택하는 것
- 변경 효과 분석 - 지정된 컴포넌트가 변경되어 영향 받는 다른 컴포넌트는 어떤 것인가? (유지보수 비용 고려)
- 변경을 구현하고 결과를 테스트 하는데 드는 비용과 시간의 예측
- 리스크를 파악하고 해결책에 대한 측정 방법을 정의
- 객체지향 프로그램의 변경 효과 분석
변경 효과 - 클래스 사이의 의존관계로 파악한다 --> 의존관계가 있다면 변경시 영향이 가게 된다
>> 클래스 B가 A에 의존하는 경우
- 클래스 B가 A의 서브클래스인 경우
- 클래스 B가 클래스 A의 집합인 경우
- 클래스 B가 클래스 A를 사용한다 -> 다음 중 하나를 만족
- 클래스 A가 클래스 B에 있는 메서드의 파라미터 타입일 때
- 클래스 A가 클래스 B에 있는 메서드의 리턴 타입일 때
- 클래스 A가 클래스 B의 로컬 변수 타입일 때
- 클래스 B가 클래스 A의 객체를 생성할 때
- 클래스 B가 클래스 A의 메서드를 호출할 때
- 클래스 B가 클래스 A와 다른 클래스 사이의 연관을 위한 클래스인 경우
11-3. 소프트웨어 형상 관리(Software Configuration Management)
- 개발 주기동안 생성된 문서를 관리하고 소프트웨어 시스템과 컴포넌트의 상태를 추적하는 작업
- 문서와 결과물에 대한 변경이 잘 조절되지 않는다면 불일치가 발생함
- 클래스 변경 후 의존 클래스를 업데이트해야 함
- 하드웨어에 적용되었던 전통적 원리를 소프트웨어 개발에 적용
11-3-1. 베이스라인
소프트웨어 개발 주기의 각 단계에 결과물을 체크 -> 프로젝트의 진도를 측정하기 위함
>> 요구 단계 종료 후 문서를 체크하는 시점 = 마일스톤 (프로젝트의 진척 상태를 나타냄)
베이스라인 - 소프트웨어 결과물(소프트웨어 형상 항목)의 집합
- 목적
- 프로젝트 진행의 중요한 상태를 정의함
- 프로젝트나 프로덕트가 특정 상태에 이르렀는지 나타냄
- 계속되는 개발, 유지보수 작업의 기준 - 요구에 대한 베이스라인 설정 후 변경을 자유롭게 할 수 없음
- 형상 항목에 대한 변경을 제어하는 메커니즘
베이스 라인과 형상 항목 ( 출처 - 소프트웨어 공학의 모든 것 467 page )
11-3-2. 형상관리 절차
형상관리 절차는 네 가지 기능으로 구성
- 소프트웨어 형상 파악
- 형상 변경 제어
- 소프트웨어 형상 감사
- 소프트웨어 형상 상태 보관
형상 관리 절차 ( 출처 - 소프트웨어 공학의 모든 것 468 page )
- 소프트웨어 형상 파악
- 소프트웨어 개발 과정에서 여러 가지 문서가 생성, 사용됨
- 프로젝트 크기, 개발 프로세스, 가용 자원 등 여러 가지 요인을 고려하여 문서를 관리할 필요가 있음
- 베이스라인과 각 베이스라인의 형상 항목을 정의하는 것
- 형상항목 - 단순항목, 복합항목(다수의 다른 항목을 포함)으로 나눠짐
| 형상 항목 | 설명 |
| 고유 식별자 (ID number) |
소프트웨어 형상 항목을 구별하기 위한 고유번호이다. 형상 항목의 기능을 나타내기 위한 의미를 가져야 한다. 예를 들면 도서관 정보 시스템의 도메인 모델의 버전 1이라면 LIS-Inc1-DM과 같이 고유 식별자를 붙인다. |
| 이름 | 형상 항목의 이름, 예를 들면 문헌 대출 유스케이스, 문헌 대출 시퀀스 다이어그램과 같다 |
| 문서 종류 | 형상 항목의 문서 종류. 예를 들면 요구 분석 명세서, 설계 문서, 테스트 케이스 등 |
| 문서 파일 | 문서 파일 이름과 경로 |
| 저자 | 형상 항목을 만든 개발자 |
| 생성 날짜, 타겟 완성일 | 형상 항목의 상태를 파악하기 위한 정보 |
| 버전 번호 | 형상 항목의 버전을 추적하기 위한 정보 |
| 업데이트 이력 | 누가 언제 업데이트하였는지 간단히 요약한 리스트 |
| 설명 | 형상 항목에 대한 설명 |
| SQA 담당자 | 형상 항목의 품질 보증 책임자 |
| SCM 담당자 | 형상 항목을 체크할 책임자 |
- 형상 변경 제어 (Software Configuration Change Control)
- 변경의 이유를 파악 - 형상 항목을 변경하는 이유는 다음과 같음
- 소프트웨어의 결함 - 예 > 기능이 부정확, 적합하지 않음, 성능이 만족스럽지 않음
- 하드웨어 변경 - 예 > 하드웨어나 하드웨어 장치의 교체
- 운영 요구의 변경 - 예 > 새로운 보안 절차에서 PW는 더 복잡한 보안 규칙을 만족해야 하기 때문
- 고객이나 사용자로부터 개선 요구가 있을 경우 - 예 > 사용자 인터페이스 개선
- 예산, 프로젝트 일정, 기간의 변경 - 예 > 다가오는 비즈니스의 상황 등으로 일정 조정이 불가피한 경우
- 영향 분석 - 상황이 발생하면 팀은 형상 항목에 대한 변경 파악, 전문가가 변경에 대한 영향 분석
- 변경 계획 수립 - 변경 계획서는 다음과 같은 사항을 명시하기 위한 기술/행정 사항으로 구성됨
- 제안된 변경의 설명
- 조직과 개발자의 파악
- 변경의 이유
- 영향 받는 베이스라인과 형상 항목
- 제안된 변경을 구현하는 데 소요되는 노력, 시간, 비용, 제안된 변경의 우선순위
- 프로젝트 일정에 대한 영향
- 변경 계획의 평가 - 변경에 의하여 영향 받는 부서로 구성된 형상 관리 위원회에 의하여 검토됨
- 변경을 추가 - 승인된 변경을 시스템에 추가함
- 소프트웨어 형상 감사
>> 가지는 의무
- 베이스라인을 구축하기 위한 메커니즘 정의
- 향후 구축될 베이스라인 - 관련 문서 중 하나라도 생성되어 형상관리 시스템에 제출되었을 때 존재하는 상태
- 승인된 베이스라인 - 형상 항목 제작, 인스펙션 작업 완료 후 형상관리 시스템에 제출되었을 때 존재하는 상태
- 형상 항목 검토
- 형상 항목이 의도하는 것이 차이가 없음을 보장해야 함
- 예 > 요구 베이스라인에서 유스케이스가 변경 -> 설계 수준의 베이스라인에 확장된 유스케이스에서 시스템/액터가 변경된 대로 상호작용하도록 일치되어야 함
- 형상 항목 확인
- 형상 항목이 올바른 문제를 해결하였는지 확증하기 위하여 정확성을 체크
- 소프트웨어 형상 상태 보관
- 형상 항목에 대한 정보를 추적하고 보고하는 것
버전 관리 도구
11-4. 역공학
정의 - 대상 시스템을 분석하여 시스템의 컴포넌트와 관계를 찾아 내어 같은 수준의 다른 표현이나 더 높은 수준의 표현으로 만드는 작업
- 하드웨어 완제품으로부터 설계를 해독해 내는 작업
- 프로그램의 추상 수준을 점증적으로 복구해 나가는 과정
- 같은 수준의 추상 수준에서 다른 표현을 추출하는 것도 역공학이다
역공학 ( 출처 - 소프트웨어 공학의 모든 것 473 page )
11-4-1. 역공학 작업 순서
- 원시코드에서 소프트웨어 결과물을 추출후 데이터 베이스에 저장
- 파악된 각 요소를 다이어그램으로 그리기 위하여 레이아웃 계산
- 디스플레이 컴포넌트가 레이아웃에 따라 다이어그램으로 그려진다
역공학 도구의 구성 ( 출처 - 소프트웨어 공학의 모든 것 474 page )
11-4-2. 역공학의 용도
역공학에 의해 복원된 다이어그램은 여러 방면에 사용됨
- 프로그램 이해
- 역공학 도구에 의해 생성된 다이어그램은 유지보수하고 있는 SW의 구조, 기능, 동작의 이해를 용이하게 함
- 정형적 분석
- 역공학 도구에 의하여 생성된 다이어그램을 SW에 존재할 수 있는 문제를 감지하기 위하여 사용될 수 있음
- 테스트 케이스 생성
- 역공학 도구에 의하여 생성된 다이어그램은 테스트 케이스 생성을 용이하게 함
- 예 > 흐름도의 경로는 경로 테스트 케이스를 생성하는 것을 용이하게 함
- 리엔지니어링
- 역공학에 의해 생성된 다이어그램은 리엔지니어링을 위하여 사용됨
- 리엔지니어링 - SW의 특정 측면을 개선하기 위해 재구축하는 과정
11-4-3. 재문서화
의미적으로 같은 추상 수준을 가진 표현을 생성하는 작업
- 재문서화의 목적
- 소프트웨어의 이해를 증진시키기 위하여 시스템의 다른 관점을 가지려는 것
- 현재 보유한 문서를 개선하기 위함
- 새로 수정된 프로그램의 문서화를 하기 위함
11-4-4. 설계 복구
- 원시코드를 자세히 검토하여 의미 있는 추상성 높은 표현을 찾아내고 추출하는 작업
- 복구된 설계
- 원시코드 이해에 도움이 될 수 있음
- 향후 유지보수 또는 리엔지니어링을 위한 베이스라인으로 사용됨
- 유사한 다른 애플리케이션을 위하여 사용될 수도 있음
- 설계 복구 작업은 프로그래밍 언어 구조에 크게 좌우됨
- 객체지향 프로그램 - UML도구에 의하여 자동화되어 있음
- 객체지향이 아닌 경우 - 내재된 설계의 의미와 의사결정을 파악, 이해하며 설계로 표현하는 작업이 필요함
- 설계 복구에는 도메인 지식이 필요할 수도 있음
11-5. 리엔지니어링
소프트웨어의 어떤 측면을 개선하기 위하여 시스템 또는 컴포넌트를 재구조화 하는 과정
소프트웨어는 지속적으로 변경된다 -> 시스템의 구조가 나빠지고있다 -> 유지보수의 비용이 많이 들어간다
>> 유지보수 비용을 줄이기 위하여 재구조화가 필요함
11-5-1. 리엔지니어링 목적
- 소프트웨어 아키텍처 개선
- 소프트웨어의 복잡도 경감
- 변경에 대한 적응성 개선
- 성능, 효율성, 자원 유용성 개선
- 소프트웨어 시스템의 유지보수 개선
11-5-2. 리엔지니어링 과정
- 개선이 필요한 위치 파악
- 소프트웨어 분석을 통하여 개선이 필요한 위치를 파악
- 개선 전략을 선택
- 하나 이상의 전략이 존재할 수도 있음
- 변경 효과와 개선 전략을 구현하는 데 소요되는 시간과 비용을 분석
- 분석 결과를 기반으로 개선 전략을 선택
- 제안된 개선의 구현
- 리엔지니어링한 SW가 요구를 만족하는지 테스팅 및 리그레션 테스팅 실시
- 목표를 기준으로 시스템 평가
- 목표와 대비하여 평가함
- 추가 개선이 필요하면 프로세스를 반복함
리엔지니어링 과정 ( 출처 - 소프트웨어 공학의 모든 것 477 page )
'IT기술 > CS(ComputerScience)' 카테고리의 다른 글
| Stateful | Stateless 서비스 (0) | 2023.11.24 |
|---|---|
| 애자일 개발 프로세스 (0) | 2023.08.10 |
| [CS] OOM의 원인과 아주 간단하게 OOM 발생 시키기 (0) | 2023.08.03 |
| 개발에서 빌드도구(Build tool) maven, gradle 살펴보기 (0) | 2023.04.18 |
| 온디맨드(On-Demand) 서비스 (0) | 2023.04.17 |
