[소프트웨어공학] 형상관리

[소프트웨어공학] 형상관리

형상 관리

다음이 변경 될 때 소프트웨어 시스템의 새 버전이 생성된다.

다른 운영체제/기계

다른 기능성 제공

특정 사용자 요구 사항에 맞게 조정

진화하는 소프트웨어 시스템 관리와 관련 있다.

시스템 변경과 관련된 비용과 노력을 컨트롤하는 것을 목표로 한다.

진화하는 소프트웨어 제품을 관리하기 위한 절차 및 표준의 개발 및 적용을 포함합니다.

보다 일반적인 품질 관리 프로세스의 일부로 볼 수 있음

릴리스될 때 소프트웨어 시스템은 추가 개발의 시작점이므로 기준선이라고도 한다.

형상관리란?

다음을 하는 것을 목적으로 한다.

항목 식별, 정의 및 기준선

해당 항목의 수정 및 릴리스를 제어

항목 및 수정 요청의 상태를 보고하고 기록

항목의 완전성, 일관성 및 정확성을 보장

물품의 보관, 취급 및 배송을 제어

형상 관리의 장점

결정적이고 최신 정보 기업이 무엇을 개발/구축/테스트/제공하는지 언제든지 알 수 있다.

제품 일관성 보장 역설계 없이 동일한 품목을 배송/수정할 수 있다.

비용 통제 변경 제어를 통해 프로젝트가 승인된 예산 범위 내에서 유지되도록 돕는다.

계획의 가시성 제안된 변경의 스케줄 영향 검토

요구사항 준수 기술검토/구성현황 회계/구성 감사를 통해 의도한 구성을 보장한다.

생산성 관리 개발 생산성 및 재사용성 향상

형상 식별(CI) -> 형상 통제(CC) -> 상태 보고(CA) -> 형상 점검(CA)

형상 식별(CI)

형상관리 대상 품목 선정 기준 정의 CI 선택 및 CI 간의 관계 정의 소프트웨어 컴포넌트 계층 구조 개발 및 CI 간 상관 관계 정의 특정 CI 식별을 위한 명명 규칙 정의 모든 CI를 커버해야한다.

유일한 이름

표준 형식

프로젝트와 버전에 연결되어야 한다. 릴리스/버전 관리 시스템 개발 CI 인터페이스 정의 및 문서화 Baseline 설정 절차 정의 CI에 식별자 할당

Baseline란?

: 합의된 출발지점으로, 이후 모든 관련 당사자에게 변경 사항을 전달해야 한다.

CM 역할과 책임

SCM팀

Kick-off 미팅 참석, SCM 시스템 설계, SCM 기획

프로젝트 구성 관리자

프로젝트 CM 업무 관리

기술 리드

변경 사항 처리

형상 제어 보드

결정

모든 프로젝트 구성원은 구성 관리 프로세스를 수행할 책임이 있다.

형상 통제(CC)

형상 관리를 위한 중요한 활동이다.

변경 사항에 대해,

평가

조정

승인/거절

구현

SCM 조직

형상 관리자(CM) 프로젝트 팀의 특정 구성원에게 할당됨 TL(팀리더)은 소규모 프로젝트의 CM이 될 수 있다. CM과 PM의 역할을 중복하지 않는 것이 좋다. 수행할 작업 프로젝트에 대한 SCM 계획 및 실행 SCM 데이터베이스 생성 및 유지 SCM 프로세스 정의, 문서화 및 전달 baseline 설정 baseline 변경 관리

형상 제어 보드(CCB) 변경 관련 문제를 해결하기 위한 위원회(이사회) 수행할 작업 baseline 변경 승인 변경 요청(CR) 평가 변경 요청 승인/거부 변경 요청 닫기 CR 평가를 위해 고려해야 할 문제 운영 영향 고객 동의서 개발 노력 인터페이스 효과 일정 변경 비용 품질 효과 타당성

형상 데이터베이스

모든 CM 정보는 형상 데이터베이스에 유지되어야 한다.

일반적인 변경 관리 프로세스

변경 개시 분류 변경 변경 평가 또는 변경 분석 변경 처분 변경 구현 변경 확인 Baseline 변경 관리

형상 상태 보고(CSA)

CI 상태 기록 및 보고(CSAR 사용)

CI 상태 데이터베이스 유지

확립된 Baseline 식별

설정된 Baseline의 내용 식별

문제 보고 현황

변경 요청 상태

모든 제공 문서의 상태 식별

형상 상태 보고의 중요성 프로젝트 관리의 문제를 쉽게 식별 계획 대비 실제 성과 파악 용이 문제 원인 파악 용이 상황이 악화되기 전에 시정 조치를 취할 수 있다. 프로젝트 성과를 쉽게 결정 CI 히스토리에 대한 쉬운 이해로 문제 해결 속도 향상

형상 감사(CA)

개발된 제품이 승인된 제품 사양과 정확히 일치하는지 검증

제품 baseline CI 릴리스 이전 및 후속 업데이트된 제품 릴리스에서 완료

제안된 CI가 생성된 것인지 확인

FCA & PCA(중요)

FCA(기능 형상 감사)

모든 기능적 요구 사항이 충족되는지 확인(SRS/RDD).

QE(품질 공학자)에 책임있음

소프트웨어에 대한 독립적인 평가

PCA(물리적인 형상 감사)

CSA 보고서를 사용하여 제품 베이스라인 CI의 버전이 올바른지 확인 (변경의 과정이 제대로 반영 되었는지 감사)

코드에 대한 설계를 검증 (코드에 집중)

CM에 대한 주요 책임 있음

유지보수

프로그램을 사용한 후 수정하는 것

유지 보수는 일반적으로 시스템 아키텍처의 주요 변경 사항이 포함되지 않는다.

변경 사항은 기존 컴포넌트를 수정하고 시스템에 새 컴포넌트를 추가함으로써 구현된다.

유지가 불가피하다. 환경이 변화하기 때문에 시스템이 개발되는 동안 요구 사항이 변경될 수 있다. 따라서 전달된 시스템은 요구 사항을 충족하지 않는다! 시스템은 환경과 밀접하게 연결되어 있다. 시스템이 환경에 설치되면 환경이 변경되므로 시스템 요구 사항이 변경된다. 따라서 시스템이 환경에서 유용하게 유지되려면 시스템을 유지 관리해야 한다.

유지보수의 유형

소프트웨어 결함을 복구하기 위한 유지보수 수정 유지보수 : 시스템의 요구사항에 맞게 결함을 수정하는 방식으로 변경

소프트웨어를 다른 운영 환경에 적응시키기 위한 유지보수 적응형 유지보수 : 초기 구현과 다른 환경(컴퓨터, OS 등)에서 동작하도록 시스템을 변경하는 것

시스템 기능 개편을 위한 유지보수 완벽한 유지보수 : 새로운 기술 및 환경 요구 사항을 충족하도록 시스템 수정

작동 중 오작동 방지를 위한 유지보수 예방형 유지보수 : 시스템을 실제로 사용하기 전에 시스템 기능이 정상인지 확인

유지보수 노력의 분산

기능 추가 및 수정(65%), SW적응(18%), 결함 고치기(17%)

유지보수 프로세스

-> Impact analysis

일정, 노력, 예산의 타당성

변경 효과

CCB(Configuration Control Board)에서 수행

유지 관리를 위한 지표

McCabe의 순환 복잡도 (중요)

제어 흐름 그래프 기준

C = E – N + P(또는 C = E – N + 2P) E : 에지 개수 N : 노드 수 P : 연결된 컴포넌트의 개수

C = 10 – 7 + 1 = 4

Halstead의 코드 복잡성 (중요)

소스 코드가 가지고 있는 연산자, 피연산자의 종류와 개수를 가지고 측정

연산자 및 피연산자 수 기준

프로그램 볼륨, V = N log2(n1+n2) n1 : 연산자 종류의 수 n2 : 피연산자의 종류 수 N = n1log2n1 + n2log2n2 N1 : 연산자 개수 N2 : 피연산자의 개수

소프트웨어 재공학

기존 소프트웨어 시스템을 보다 쉽게 유지 관리할 수 있도록 재구성 및 수정

기능을 변경하지 않고 legacy 시스템의 일부 또는 전체를 재구성하거나 재작성

더 큰 시스템의 모든 하위 시스템이 아닌 일부 하위 시스템이 자주 유지 관리해야 하는 경우에 적용 가능

재설계에는 유지보수를 더 쉽게 하기 위한 노력이 추가된다. 시스템을 재구성하고 다시 문서화할 수 있다.

CASE Tools

소프트웨어 수명 주기의 모든 단계/활동 지원

CASE 툴의 종류 PMO 툴 : 조직별 프로젝트 모니터링 및 감독. 수준 프로젝트 계획 도구 일정, 노력, 예산 등을 계획하고 / 계획과의 편차 관리 : ITScopeTM 비용추정 도구 : FPA 도구, COCOMO 도구, PRICE 도구 개발 엔지니어링 도구 : StarUML, Topcased UML, Raphsody 요구사항 관리 툴, 모델링 툴, 코드 생성 툴, 테스트 툴, 문서 생성 툴 형상 관리 툴 : Clear Case, Synergy, Harvest 시뮬레이션 툴 기타

from http://juyami.tistory.com/45 by ccl(A) rewrite - 2021-12-12 22:01:48