2022. 6. 4. 18:19ㆍ소프트웨어 공학
유지보수란
- 개발 후에 이루어지는 소프트웨어의 변경 작업
- SW가 유용하게 활용되는 기간
- SW는환경과 비즈니스 요구에 따라 진화함
- 유치보수에 드는 노력은 전체 비용의 60~80%
레거시 시스템
- 대체하려면 많은 비용이 발생
- 지식, 경험, 지능이 녹아있음
# 여러 가지 이유로 수정 후 배포하는 작업
- 버그 제거
- 운영 환경의 변화
- 비즈니스 절차의 변화
- 미래 문제를 배제하기 위하여 변경
유지보수 유형
- 수정형 유지보수 : 발견된 결함을 고치기 위해 SW제품을 수정
- 적응형 유지보수 : 변경된 환경에서도 계속 사용할 수 있도록 SW를 이식하거나 변경
- 완전형 유지보수 : 성능이나 유지보수성을 개선하기 위해 실히
사용자의 요청되는 기능 보강 때문에 발생
- 예방형 유지보수 : 오류 발생을 방지하기 위해 수행
코드의 구조를 조정, 복잡성을 줄여 이해하기 쉽게 변경
Lehman의 법칙 - 소프트웨어 진화의 법칙
- E타입 : 계속 진화하는 타입
- S타입 : 완벽히 정의할 수 있는 타입(수학 소프트웨어 또는 체스 게임)
1) 지속적인 변경 원칙 : 시스템이 변경될 때까지 변경
2) 엔트로피, 복잡도 증가의 법칙 : 시스템이 변경될수록 구조는 복잡해지고 결합도는 증가함
3) 자기 통제의 법칙 : 시스템 진화 과정은 자기 통제의 과정(안정성 유지, 친근성 유지, 지속적 성장 규칙을 일반화)
4) 안정성 유지의 법칙 : 일정한 평균 작업략을 보임
5) 친근성 유지의 법칙 : 버전의 변화는 일정함
6) 지속적 성장의 법칙 : 사용자 만족을 위해 기능적 성장을 계속해야
7) 품질 저하의 법칙 : 운영 환경의 변화에 적응하지 못하는 한 저하됨
8) 피드백 시스템의 법칙 : 진화 프로세스는 중요한 역할의 관련자들의 피드백으로 구성
유지보수 기본 작업 과정
1. 현재 프로그램의 이해 : 프로그램 로직을 추적하거나 요구 및 설계 등에 대항 이해가 필요
2. 변경 파악과 분석 : 필요한 변경을 파악하고 그 영향도와 소요 비용, 변경에 의한 리스크 분석
3. 변경 영향 파악 : 이해당사자들에게 알리고 피드백 얻음
4. 변경 구현, 테스트, 설치 : 시스템을 수정하고 확인 후 설치
유지 보수 작업 분포
- SW 개발은 코딩 중십 작업이나, 유지보수는 이해 중심의 작업, 통합된 작업
- 유지보수는 처음 이해 단계에 많은 비용이 들고 코드를 수정하는 단계는 적게 든다.
유지보수 프로세스 모델
- 즉시 수정 모델
- 문제가 확인되면 빨리 문제 해결
- 고객 요구로 많이 사용되는 모델
-반복적 개선 모델
- 생명주기 단계를 반복하여 개선
- 즉시 수정 모델의 체계화된 형태
- 재사용 중심 모델
- 유지보수 작업을 컴포넌트 재사용으로 봄
- 컴포넌트 분류/재사용을 위한 프레임워크 필요
유지보수 프로세스 모델의 비교
작업과정1 - 프로그램 이해
- 프로그램 소스를 변경하려면 프로그램을 이해할 필요
- 원시코드로부터 설계나 명세를 추출 -> 멘탈 모델로 표현
- 개발 프로세스와 반대로 추상성을 추구
- 상향식 이해 모델
- 상향식(bottom-up)
- 묶음화(chunking)
작업과정2 - 변경파악과 분석
- 변경 요구를 기초로 어떤 부분을 변경할지 찾아냄
- 다른 변경 방법인 상용 컴포넌트 Commercial Off-The-Shelf(COTS)도 찾아냄
- 컴포넌트 변경에 시간이 많이 걸릴 경우 COTS를 차선책으로 검토
- 변경 분석
- 변경 효과 분석
- 변경을 구현하고 테스트하는 데 드는 비용, 시간 예측
- 리스크 파악
- 객체지향 SW
- 클래스 사이의 의존 관계로 파악
- 클래스 B가 A의 서브클래스이면 B는 A에 의존
- 클래스 B가 A의 집합이면 B는 A에 의존관계
- 클래스 B가 A를 사용하면 B는 A의 의존관계
- 클래스 B가 A와 다른 클래스 사이의 연관을 위한 클래스이면 B는 A에 의존관계
형상 관리
- 개발 주기 동안 생성된 문서를 관리하고 SW 시스템과 컴포넌트의 상태를 추적하는 작업
- 문서와 결과물에 대한변경이 잘 조정되지 않는다면 불일치 발생
- 클래스 변경 후 의존 클래스를 업데이트 해야 함
- 하드웨어에 적용되었던 전통적 원리를 SW개발에 적용
- 베이스 라인
- 마일 스톤은 SW 개발 단계에서 프로젝트 진척 상태를 측정하려는 의미
- 즉 마일스톤은 요구 단계 종료 후 또는 설계 단계 종료 후 문서 체크 시점
- SW 형상관리에서는 마일스톤을 베이스라인이라 부름
- SW 결과물인 형상 항목의 집합
- 베이스 라인 목적
- 프로젝트의 중요한 상태 정의
- 프로덕트가 특정 상태에 이르렀는지를 나타냄
- 계속되는 개발, 유지보수 작업의 기준
- 형상 항목에 대한 변경을 제어하는 메커니증
- 베이스 라인과 형상 항목
- 형상 관리는 한마디로 베이스라인, 즉 형상 항목을 관리하는 것
- 형상 항목 관리는 베이스 라인에 대한 업데이트
형상관리의 필요성
- 소수의 개발자가 한 장소에서 일한다면 형상 관리는 불필요
- 시스템을 개발하는 많은 팀과 개발자들이 협력하고 동기화 할 필요
- 여러 버전을 유지하여야 할 경우
- 다양한 고객을 만족시키이 위한 제품을 유지
형상 관리 절차
- 소프트웨어 형상 파악 : 베이스라인과 형상 항목을 구별하기 위한 명명 체계 정의
- 새 프로젝트가 시작될 때 베이스라인과 각 베이스라인의 형상 항목을 정의
- 형상 변경 제어 : 변경 관리
- 변경 이유를 파악
- SW의 결함
- 하드웨어 변경
- 고객이나 사용자로부터 개선 요구
- 예산 프로젝트 일정, 기간의 변경
- 영향 분석 : 형상 항목에 대한 변경을 파악 후 변경에 대한 영향 분석
- 변경 제안 준비 : 변경의 설명, 조직 및 개발자 파악, 변경의 이유, 영향 받는 항목, 소요 노력, 프로젝트 일정에 대한 영향
- 변경 제안의 평가 (승인, 거부)
- 변경을 시스템에 추가
- 소프트웨어 형상 검사 : 변경 여부를 확인하고 검증
- 베이스라인을 구축하기 위한 메커니즘 정의
- 향후 구축될 베이스라인과 승인된 베이스라인
- 승인된 베이스라인은 모든 형상 항목이 만들어지고 인스펙션을 마치고 형상 관리 시스템에 제출된 상태
- 형상 항목 검토
- 베이스라인 명시된 대로 업데이트되어도 차이가 없음을 보장
- 형상 항목 확인
- 올바른 문제를 해결하였는지 확증하기 위해 정확성 체크
- 소프트웨어 형상 상태 보관
역공학
- 대상 시스템을 분석하여 시스템의 컴포넌트와 관계를 찾아내 같은 수준의 다른 표현이나 더 높은 수준의 표현으로 만드는 작업
- 설계, 요구명세, 문제 정의를 회복하기 위해 코드로 변환하는 과정
- 프로그램의 추상 수준을 점증적으로 복구해 나가는 과정
역공학 작업 순서
역공학 용도
- 영공학에 의해 복원된 다이어그램은 다음 여러 방면에 사용
- 프로그램 이해
- SW의 구조, 기능, 동작 이해 용이
- 정형적 분석
- SW에 존재할 수 있는 문제를 감지
- 테스트 케이스 생성
- 흐름도의 경로 - 경로 테스트 케이스에 도움
- 리엔지니어링
- SW의 특정 측면을 개선하기 위해 재구축하는 과정
- 역공학에 의해 생성된 다이어그램을 리엔지니어링에 사용
역공학 - 재문서화
- 같은 수준의 추상 수준에서 다른 표현을 추출하는 작업
# 재문서화의 목적
- SW의 이해를 증진시키기 위한 시스템의 다른 관점
- 원시 코드로부터 자료 흐름도 또는 데이터 흐름도 생성
- 현재 보유한 문서를 개선
- 기존 문서에 반영되지 않아 시스템 변경되어 추가 변경
- 새로 수정된 프로그램의 문서화
- 미래 유지보수 작업을 쉽게 하기 위함
역공학 - 설계 복구
- 원시 코드를 자세히 검토하여 더 높은 수준의 추상성 높은 표현을 찾아내고 추출하는 작업
- 복구된 설계
- 원시 코드 이해에 도움됨
- 향후 유지보수 또는 리엔지니어링을 위한 베이스라인으로 사용
- 유사한 다른 에플리케이션을 위해 사용됨
- 프로그래밍 언어 구조에 크게 좌우
- 객체지향 프로그램 - UML 도구에 의하여 자동화
- 비객체지향 - 원시 코드에 내재된 설계의 의미, 의사결정을 파악 설계로 표현하는 작업
- 도메인 지식이 필요할 수도 있음
리엔지니어링
- SW의 특정 측면을 개선하기 위해 시스템 또는 컴포넌트를 재구조화 하는 과정
리엔지니어링 목적
- 소프트웨어 아키텍처 개선
예) MVC 패턴 적용으로 GUI 개선
- 소프트웨어의 복잡도 경감
예)싸이클로매틱 방법으로 복잡도 측정 - 옵서버, 상대 디자인 패턴 등으로 복잡도 개선
- 변경에 대한 적응성 개선
예) 프레임워크 설계를 통한 DB 적용성 높임
- 성능, 효율성, 자원 유용성 개선
예) 프록시, 프로토타입 디자인 패턴, 활성다중화 전술 등 적용
- 소프트웨어 시스템의 유지보수 개선
예)추상 팩토리, 데코레이터, 반복자 디자인 패턴 등 적용
리엔지니어링 과정
1. 개선이 필요한 위치 파악
2. 개선 전략을 선택
3. 제안된 개선의 구현
4. 목표를 기준으로 시스템 평가
