8. 유지보수

소프트웨어 개발에서 유지보수는 67%나 차지함

 

유지보수 타입

- Corrective 20%: 오류 수정

- Adaptive 20%: 환경변화 반영

- Perfective 60%: 새 기능 추가, 성능 개선을 위한 확장 활동

- Preventive: 미래의 유지보수를 용이하게 함

 

유지보수라고 하면 defect fix를 생각하지만 Corrective는 고작 20%에 불과함

 

 

Lehman의 원리

- SW는 계속 변경됨

- SW 복잡도도 계속 증가함

- 대규모 SW 유지보수에는 일정한 방향이 있음

- 대규모 SW는 안정화 상태인 경우가 많음

- 유지보수 수행시 기존 SW에 대한 친근성을 유지하려고 함

 

유지보수에 영향을 주는 요소

- 사용자: 불편, 오류의 개선을 위한 변경 요청

- 환경: 운용환경,조직환경 변화 등

- 유지보수 프로세스: 변경요청, 이해, 변경 효과 분석

- 소프트웨어 제품: 지속적인 사용과 변경

- 유지보수 인력

 

유지보수 작업의 문제점과 한계

- SW에 대한 변경이 수시로 일어남: 문서에 반영하지 않는 경우 추적이 불가능

- 다른사람이 작성한 코드를 이해하기 쉽지 않음: 문서화, 주석이 달려있지 않으면 매우 심각

- 변경을 가정하여 설계되는 경우는 드물다

- 관리적인 측면에서 유지보수를 담당하는 프로그래머에게 동기부여를 하지 못함

- Alien Code의 발생: 아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수가 어려운 프로그램

 

유지보수 작업 도구

- 시스템을 운영하고 지원하는 단계에 도움을 제공하는 자동화 도구

- 성능 모니터링 도구

- 프로그램 분석

- 디버깅 분석

- 자동 문서화 도구

 

SW 형상관리 (SCM: Software Configuration Management)

- 소프트웨어를 이루는 부품의 baseline(변경통제시점)을 정하고 변경을 철저히 통제하는 것

- 개발 중 발생하는 모든 산출물들이 변경됨으로써 점차 변해가는 소프트웨어 형상을 체계적으로 관리하고 유지하는 기법

- 소프투어ㅔ어 개발 생명주기 전바에 걸쳐 생성되는 모든 산출물들의 종합 및 변경 과정을 체계적으로 관리하고 유지하는 일련의 개발 관리 활동

 

예시) -시스템 버전을 추적, 유지보수 작업 후 업데이트 설치, 시스템의 모든 버전이 제대로 작동하는지 확인

 

형상관리 항목의 예

- 요구 분석서

- 설계 문서

- 원시/목적/실행 코드

- 매뉴얼

 

형상관리의 주 역할

- 변경되는 부분이 SW 전체에 어떤 영향을 미치는지 확인해줌

- 개발자가 해야할 일의 방향을 알려줌

 

형상관리가 제 역할을 하기 위해서는 프로젝트이 특성을 고려하여 관리하고자 하는 형상 항목과 시점을 명확하고 효율적으로 계획해야 함

 

버전 관리(version control)

개발 단계 또는 순서를 번호로 표시한 것

 

버전 관리의 필요성

각 버전의 정보를 데이터베이스화 하여 언제라도 과거의 release된 파일을 가지고 작업할 수 있도록 관리함

파일의 이력이나 차이점을 관리해 애플리케이션의 버전과 각 원시 파일이나 문서를 유용하게 활용하기 위함

 

1. 형상 식별

- 형상 관리의 가장 밑바탕이 되는 활동

형상 항목 선정, 식별자 규칙 선정, 베이스라인 기준 선정

 

2. 형상 통제

-형상 목록의 변경 요구를 검토 및 승인하여 현재 SW기준선에 반영될 수 있도록 통제하는 일련의 과정

- 변경 요청, 변경 심사, 변경 확인

 

3. 형상 상태 보고

- 프로젝트에서의 변경 횟수, 최근 SW항목의 버전, 릴리즈 식별자, 횟수, 비교 내용, 베이스라인의 상태, 변경 제어 상태, 형상통제위원회 활동 내역

 

4. 형상 감사

- 승인된 변경 요청이 제대로 반영되었는지 검증, 승인되지 않은 내용이 혹시 반영되었는지 검증, 승인된 변경과 관련된 항목들이 갱신되었는지 검증

 

 

형상관리의 목표 및 필요성

- SW의 라이프사이클 동안 제품의 무결성을 유지하고, 개발 프로젝트를 통제하여 생산성을 극대화하는 것

 

형상관리 SCM의 효과

- 언제라도 특정 시간대에 가장 안정적인 버전의 소프트웨어를 유지할 수 있도록 SW제품이 변경되어가는 상태에 대한 가시성을 확보

- 누가 변경, 뭐가 변경, 언제, 왜 변경했는지 알기쉬움

- 궁극적으로 생산성과 안전성을 높여 좋은품질의 SW생산하고 유지보수도 용이하게함

 

리팩터링

- 코드를 겉으로 보이는 동작의 변화 없이 내부구조를 변경하는 작업

- SW를 이해하기 쉽고 수정하기 쉽게 만드는것

- 기능을 변경하지 않음

 

리팩터링 하는 이유

- SW디자인을 개선: 중복된, 적절하지 않은 코드 제거.

- SW를 더 이해하기 쉽게 만듦

- 버그를 발견할 수 있게 도움

- 개발의 작업시간을 줄여준다: 설계된 SW디자인에 맞추면 쉽게 개발

=> SW개발 속도를 어느정도 유지하기 위해서는 좋은 디자인이 필수이며 이를 위해서는 리팩터링이 선행되어야함

 

리팩터링을 수행할 수 없을 때

- 현재 설계된 구조가 보안,성능등 문제가 있을때

- 코드를 첨부터 짜는게 낫다 싶을때

- 코드가 현재 작동하지 않을 때

- 마감일이 가까울 때