소프트웨어 공학 정리
· 115 min read
- 하드웨어를 동작시켜 사용자가 작업을 편리하게 수행하도록하는 프로그램과 자료구조
- 프로그램 개발, 운용, 유지보수 관련된 모든 문서와 정보를 포함
- 상품성 : 개발된 소프트웨어는 상품화되어 판매된다.
- 견고성 : 일부 수정으로 소프트웨어 전체에 영향을 줄 수 있다.
- 복잡성 : 개발과정이 복잡, 비표준화
- 순응성 : 사용자의 요구나 환경 변화에 적절히 변경
- 비가시성 : 소프트웨어 구조는 외관으로 나타나지 않고 코드로 숨어 있다.
- 비마모성 : 마모되거나 소멸되지 않는다.
- 비제조성 : 하드웨어처럼 제작이 아니라 논리적인 절차에 맞게 개발
- 비과학성 : 과학적이 아니라 조직, 인력, 시간, 절차 등 중심
분류
- 기능에 의한 분류 : 시스템, 응용
- 사용 분야에 의한 분류 : 프로그래밍, 문서, 통신, 분산처리, 멀티미디어, 개발, 인공지능
- 개발 과정 성격에 따른 분류 : 프로토타입, 프로젝트 산출물, 패키지
- 정보처리 방법에 따른 분류 : 일괄처리, 온라인, 실시간
시스템 구성요소
- 입력 : 처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것
- 처리 : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것
- 출력 : 처리된 결과를 시스템에서 산출하는 것
- 제어 : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것
- 피드백 : 출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리 하는 것
위기
여러가지 원인해 의해 개발 속도가 하드웨어의 개발속도를 따라가지 못해 소프트웨어에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생함을 의미
- 소프트웨어의 특징에 대한 이해 부족 : 물리적이지 않고 논리적인 소프트웨어 특징을 이해하지 못함
- 소프트웨어의 관리 부재 : 소프트웨어에 대한 관리를 소홀히 하여 효율적인 자원 통제가 이루어지지 못했다.
- 프로그래밍에만 치중 : 소프트웨어 품질이나 유지보수는 고려하지 않고, 프로그래밍만 하려하므로 다양하고 복잡해지는 소프트웨어의 요구사항을 처리하지 못함
- 개발 인력 부족과 그로 인한 인건비 상승
- 성능 및 신뢰성 부족
- 개발 기간 지연 및 개발 비용 증가
- 유지보수가 어려워져 비용 증가
- 소프트웨어의 생산성 저하
- 소프트웨어의 품질 저하
소프트웨어 공학
- 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
- 소프트웨어의 품질과 생산성 향상을 목적
- IEEE 정의 : 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안
- Fairley 정의 : 지정된 비용과 기간 내의 소프트웨어를 체계적으로 생산하고 유지보수하는 데 관련된 기술적이고 관리적인 원리
- Boehm 정의 : 과학적인 지식을 소프트웨어 설계와 제작에 응용하는 것이며 이를 개발 운용, 유지보수하는 데 필요한 문서 작성 과정
- 제품을 단지 생산하는 것이 아니라 가장 경제적인 방법으로 양질의 제품을 생산하는 것
- 계층화 기술을 사용한다.
계층화 기술
도구, 방법, 절차가 있다.
- 도구 : Tool 절차와 방법을 자동 또는 반자동으로 처리하는 기능을 제공, 대표적으로 CASE를 사용
- 방법 : Method 소프트웨어를 구축하는 기술적인 방법을 제공
- 절차 : Process
- 소프트웨어 개발에 사용되는 개발 방법과 도구가 사용되는 순서
- 계층화 기술들을 결합시켜 합리적이고 적절한 방법으로 소프트웨어를 개발하고 유지
기본 원칙
- 현대적인 프로그래밍 기술을 계속적으로 적용해야한다.
- 개발된 소프트웨어 품질이 유지되도록 지속적으로 검증해야한다.
- 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야한다.
발전 과정
- 1960 : 소프트웨어 공학의 시작, 구조적 프로그래밍
- 1970 : 구조적 분석/설계 개념 도입, 상품화
- 1980 : 하드웨어 가격 하락
- 1985~ : 객체지향 기술 사용, CASE 등의 활용, 재공학
품질과 생산성
품질
- 사용자가 요구하는 대로 동작
- 하드웨어 자원을 효율적으로 이용
- 일정 시간 내에 주어진 조건하에서 원하는 기능을 실행
- 처리 절차에 맞게 수행되어 정확하게 결과가 산출
- 소프트웨어의 개발, 유지보수 등이 초기 예상 비용 이내에서 수행
- 적당한 사용자 인터페이스를 제공해 사용하기가 편리해야한다.
- 유지보수가 용이하고 신뢰성이 높아야한다.
- 에러가 최소화
- 소프트웨어 사용법, 구조의 설명, 성능, 기능이 이해하기 쉬어야한다.
- 실행 속도가 빠르고, 기억 용량을 적게 차지해야 한다.
생산성
투입된 비용, 노력에 대한 생산량을 의미
- 개발자의 능력
- 원활한 의사 전달
- 프로젝트의 복잡도와 성격
- 기술 수준
- 관리 기술
생명 주기
- 소프트웨어 수명 주기
- 소프트웨어 개발 방법론의 바탕
- 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 단계별로 나눈 것
- 프로젝트 비용 산정과 개발 계획을 수립할 수 있는 기본 골격
- 프롲게트 진행 방향을 명확하게 파악
- 용어 및 기술의 표준화를 가능하게 한다.
- 프로젝트 관리를 용이하게 한다.
- 여러 소프트웨어 간 상호 일관성을 유지하게 한다.
단계
정의 단계, 개발단계, 유지보수 단계로 나뉨
정의 단계
- 소프트웨어를 개발할 것인지 정의하는 단계
- 관리자와 사용자가 가장 많이 참여하는 단계
- 타당성 검토단계, 개발 계획단계, 요구사항 분석 단계로 나뉨
개발 단계
- 실제적으로 소프트웨어를 개발하는 단계
- 설계 단계 : 구조, 알고리즘, 자료구조를 작성하는 단계로 에러가 가장 많이 발생
- 구현 단계 : 설계 단계에서 작성된 문서를 기초로 하여 코딩하고 번역하는 단계
- 테스트 단계 : 구현된 소프트웨어에 내재되어 있는 오류를 찾아주는 단계
유지보수 단계
- 소프트웨어를 적응 및 유지시키는 단계
- 소프트웨어 생명 주기 단계 중에서 시간과 비용이 가장 많이 든다.
정의 : 개발 계획, 요구사항 분석 설계 : 구조, 알고리즘 구현 : 코딩 테스트 : 오류 검출
생명 주기 모형
폭포수 모형
- 소프트웨어 개발이 각 단계를 확실히 매듭짓고 그 결과를 철저히 검토하여 승인한 뒤 다음 단계로 진행
- 이전 단계로 넘어갈 수 없는 방식
- 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형
- 고전적 생명 주기 모형
- 앞 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
- 제품의 일부가 될 매뉴얼을 작성해야 한다.
- 타당성 검토 => 계획 => 요구 분석 => 설계 => 구현(코딩) => 테스트(검사) => 유지보수
- 모형 적용 경험과 성공 사례가 많다.
- 단계별 정의가 분명하고 전체 공조의 이해가 용이하다.
- 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시한다.
- 개발 중 발생하는 새로운 요구나 경험을 반영하기 어려워 처음부터 사용자가 모든 요구사항을 명확하게 제시해야한다.
- 오류 없이 다음 단계로 진행해야 하는데 현실적으로 힘들다.
- 업무에 운용할 때 검출되지 않은 오류가 발생할 수 있다.
프로토타입 모형
- 사용자의 요구사항을 정확하게 파악하기 위해 프로토타입(견본품)을 만들어 최종 결과물을 예측하는 모형
- 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.
- 폭포수 모형의 단점을 보완
- 프로토타입은 요구 분석 단계에서 사용한다.
- 소프트웨어 생명주기에서 유지보수가 없어지고, 개발 단계 안에서 유지 보수가 이뤄지는 것으로 볼 수 있다.
- 요구 수집 => 빠른 설계 => 프로토타입 구축 => 고객 평가 => 프로토타입 조정 => 구현
- 요구사항을 충실히 반영하며 요구사항의 변경이 용이
- 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있다.
- 프로토타입은 의뢰자나 개발자 모두에게 공동의 참조 모델을 제공한다.
- 미리 제작된 소프트웨어를 사용할 경우 실제 소프트웨어와의 차이가 발생할 수 있다.
- 단기간 제작해야되기 때문에 비효율적 언어나 알고리즘을 사용할 수 있다.
나선형 모형
- Boehm이 제안한 것으로 폭포수와 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
- 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
- 점진적 모형
- 소프트웨어를 개발하면서 발생하는 위험을 관리하고 최소화하는 것을 목적으로 한다.
- 계획 및 정의 => 위험 분석 => 공학적 개발 => 고객평가의 반복
- Planning => Risk Analysis => Engineering => Customer Evalutation
- 가장 현실적인 모형
- 대규모 프로젝트나 큰 시스템에 적합하다.
- 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 추가할 수 있고, 정 밀하며 유지보수가 필요 없다.
- 위험성 평가에 크게 의존하기 때문에 발견하지 못하면 문제가 발생한다.
- 비교적 최신 기법이라 널리 사용되지 않는다.
4GT 모형
- 사용자와 개발자가 쉽게 접근하고 사용할 수 있는 4세대 언어를 이용하여 개발자가 조사한 요구사항 명세서로부터 원시 코드를 자동으로 생성할 수 있게 해주는 모형
- 설계 단계를 축소하고 요구 분석단계에서 코딩단계로 전환할 수 있는 비절차적 모형
- 요구사항 수집 => 설계 전략 => 4세대 언어를 이용한 구현 => 제품화
- 중소형 소프트웨어 개발에는 시간이 감소하지만 대규모에서는 자동화로 인해 분석 설계 단계에서 더 많은 시간이 필요
프로젝트 관리
- 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 활동
- 소프트웨어 개발 계획을 세우고 분석, 설계, 구현 등 작업을 통제하는 것
- 소프트웨어 생명 주기의 전 과정에 걸쳐 진행된다.
관리 대상
- 계획관리 : 프로젝트 계획, 비용산정, 일정 계획, 조직 계획
- 품질관리
- 위험관리
3대 요소
- 사람 : People 프로젝트 관리에서 가장 기본이 되는 인적자원
- 문제 : Problem 사용자 입장에서 문제를 분석하여 인식
- 프로세스 : Process 소프트웨어 개발에 필요한 전체적인 작업 계획 및 구조
구성 단계
- 프로젝트 계획 수립
- 프로젝트 가동
- 프로젝트 통제
- 프로젝트 종료
프로젝트 계획 수립
- 프로젝트가 수행되기 전에 소프트웨어 개발 영역 결정, 필요한 자원, 비용, 일정 등을 예측하는 작업
- 관리자가 합리적으로 예측할 수 있도록 프레임워크 제공
- 소프트웨어 개발 과정에서 발생할 수 있는 위험성 최소화
- 계획 수립 후에는 시스템 정의서와 프로젝트 계획서가 산출
- 프로젝트 관리자의 임무
소프트웨어 개발 영역 결정
- 프로젝트 계획 수립의 첫 번째 업무
- 개발될 소프트웨어의 영역을 결정
- 주요 요소 : 처리될 데이터, 소프트웨어에 대한 기능, 성능, 제약 조건, 신뢰도, 인터페이스 등
- 인터페이스
- 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨러를 실행하는 프로세서나 하드웨어
- 운영체제, 서브루틴 패키지와 같이 새로운 소프트웨어에 연결되어야 하는 소프트웨어
- 키보드나 기타 I/O 장치를 통해 소프트웨어를 사용하는 사람
- 순서적인 연산에 의해 소프트웨어를 실행하는 절차
자원 추산
- 소프트웨어 개발에 필요한 자원을 예측하는 것
- 인적자원, 재사용 소프트웨어자원, 환경 자원
소프트웨어 프로젝트 추산
- 프로젝트 수행에 필요한 비용을 예측하는 것
프로젝트 계획 수립시 고려사항
- 프로젝트 복잡도
- 프로젝트 규모
- 구조적 불확실성의 정도
- 과거 정보의 가용성
- 위험성
소프트웨어 프로젝트 추산
- 비용을 예측하는 작업
- 가장 어렵고 오차 발생이 심한 작업
프로젝트 비용 결정 요소
프로젝트 요소
- 제품의 복잡도
- 시스템의 크기
- 요구되는 신뢰도 : 일정한 기간 내에 주어진 조건 하에서 필요한 기능을 수행하는 정도
자원 요소
- 인적 자원 : 관리자, 개발자의 자질
- 하드웨어 자원
- 소프트웨어 자원 : 개발 지원 도구
생산성 요소
- 개발자의 능력
- 개발 기간 : 개발 기간이 길어질수록 개발 비용이 적어짐
비용 산정 기법
하향식
전문가 감정 기법
- 경험이 많은 두 명 이상의 전문가에게 비용 산정 의뢰
- 개인적이고 주관적
- 편리하고 신속하게 비용 산정
- 의뢰자에게 신뢰를 얻을 수 있음
델파이 기법
- 전문가 감정 기법의 주관적 편견을 보완하기 위함
- 많은 전문가의 의견을 종합해 선정하는 방법
- 한 명의 조정자와 여러 명의 전문가
상향식
프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
LOC 기법
- 원시 코드 라인수 기법
- 소프트웨어 각 기능의 원시 코드 라인 수와 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
- 측정이 용이하고 이해하기 쉬워 가장 많이 사용된다.
- 예측치 = (낙관치 + (4 X 기대치) + 비관치) / 6 = (a + 4m + b) / 6
- ManMonth = 개발 기간 X 투입 인원 = LOC / 1인당 월평균 코딩량
- 개발 비용 = ManMonth X 1인 인건비
- 개발 기간 = ManMonth / 투입 인원
- 생산성 = LOC / ManMonth
개발 단계별 인원수 기법
- Effort Per Task
- 각 기능을 구현시키는데 필요한 ManMonth를 생명 주기의 각 단계별로 산정
- LOC보다 정확하다.
수학적 산정 기법
- 상향식 비용 산정 기법
- 경험적 추정 모형 = 실험적 추정 모형
- COCOMO, Putnam, FP 모형
COCOMO 모형
- COnstructive COst MOdel
- Boehm이 제안
- 원시 프로그램 규모인 LOC에 의한 비용 산정 기법
- 개발할 소프트웨어의 규모를 예측한 후 소프트웨어의 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 구한다.
- 비용 견적의 강도 분석 및 유연성이 높아 널리 사용된다.
- 같은 규모의 프로그램이라도 성격에 따라 비용이 다르게 산정된다.
- 비용 산정 결과는 ManMonth로 나타낸다.
조직형
- Organic Mode
- 중소규모, 5만 라인 이하의 소프트웨어 개발
- 사무처리, 업무, 과학용 응용 소프트웨어 개발에 적합
반분리형
- Semi-Detached Mode
- 30만 라인 이하의 소프트웨어 개발
- 트랜잭션 처리 시스템, 운영체제, DBMS, 컴파일러, 인터프리터 등 유틸리티 개발에 적합
내장형
- Embedded Mode
- 30만 라인 이상의 소프트웨어 개발
- 최대형 규모의 트랜잭션 처리 시스템, 운영체제, 신호기 제어, 미사일 유도, 실시간 처리 등 시스템 프로그램 개발에 적합
종류
- 기본형 : Basic 소프트웨어 크기와 개발 유형만을 이용
- 중간형 : Intermediate 기본 COCOMO를 사용하나 제품, 컴퓨터, 개발요원, 프로젝트 특성에 따라 비용을 산정한다.
- 발전형 : Detail 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형, 소프트웨어 환경과 구성요소가 사전에 정의되어 있어야하고 개발과정 후반부에 주로 적 용한다.
Putnam 모형
- Putnam이 제안
- 생명 주기 예측 모형
- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
- SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로하여 개발된 자동화 추정 도구
FP 모형
- 기능 점수 = Function Point
- Albrecht이 제안
- 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고 가중치와 영향도를 합하여 기능 점수를 구한 후 비용을 산정하는 기법
- 최근에 유용성과 간편성으로 비용 산정 기법 가운데 최선의 평가를 받고 있다.
- ESTIMACS : FP 모형을 기초로하여 개발된 자동화 추정 도구
프로젝트 일정 계획
- 프로젝트 프로세스를 이루는 소작업의 순서와 일정을 정하는 것
- 소프트웨어 개발 기간의 지연을 방지하고 프로젝트가 계획대로 진행되도록 일정을 계획
- 계획된 일정은 프로젝트의 진행을 관리하는데 기초 자료가 된다.
- 계획된 일정과 프로젝트의 진행도를 비교하여 차질이 있을 경우 조정할 수 있다.
- WBS, PERT/CPM, 간트 차트가 사용된다.
사람-노력 관계
- 소규모 개발 프로젝트에서는 한 사람이 요구사항을 분석하고 설계, 코딩, 테스트까지 수행할 수 있다.
- 프로젝트의 크기가 증가할수록 더 많은 사람들이 참여해야 한다.
- Brooks의 법칙 : 프로젝트 중 새로운 인력을 투입할 경우 작업 적응기간과 부작용으로 인해 일정이 더 지연된다.
노력 분배
- 노력을 개발과정에 분배할 때는 40-20-40 규칙을 권장한다.
- 분석 설계에 40, 코딩에 20, 테스트에 40
WBS
- Work Breakdown Structure = 업무 분류 구조
- 개발 프롲게트를 여러 개의 작은 관리 단위로 분할하여 계층적으로 기술한 업무 구조
PERT/CPM
- 프로젝트 지연을 방지하고 계획대로 진행되게 하기 위한 일정을 계획하는 것
- 초단시간 내 계획 완성을 위한 프로젝트 일정 방법
- 프로젝트 개발 기간을 결정하는 임계 경로를 제공한다.
- 통계적 모델을 적용해 개별 작업에 대한 가장 근접한 시간을 측정하는 기준이 된다.
- 각 작업에 대한 시작 시간을 정의하여 작업들 간의 경계 시간을 계산할 수 있게 한다.
- 가장 빠른 완료시간, 가장 늦은 완료시간, 총 자유시간을 구할 수 있다.
PERT
- Program Evaluation and Review Technique = 프로그램 평가 및 검토 기술
- 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크
- 낙관적인 경우, 가능성이 있는경우, 비관적인 경우로 나누어 각 단계별 종료 시기를 결정하는 방법
- 과거에 경험이 없어 소요 기간 예측이 어려운 소프트웨어에서 사용
- 노드와 간선으로 구성되며 원 노드에는 작업을 화살표 간선에는 낙관치, 기대치, 비관치를 표시한다.
- 결정 경로, 작업에 대한 경계시간, 작업 간의 상호관련성을 알 수 있다.
- 작업 예측치 = (비관치 + (4 X 기대치) + 낙관치) / 6
CPM
- Critical Path Method = 임계 경로 기법
- 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
- 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업사이의 전후 의존 관계를 나타낸다.
- 원형 노드는 작업과 소요기간을 표시하고, 박스 노드는 이정표를 의미하며 예상 완료 시간을 표시한다.
- 전 작업이 완료된 후 다음 작업을 진행할 수 있다.
- 각 작업의 순서와 의존관계, 작업의 동시성을 한 눈에 볼 수 있다.
- 프로젝트 규모 추정 => 단계별 필요작업 분할 => 작업의 상호 의존 관계를 CPM 네트워크로 나타냄 => 일정 계획을 간트 차트로 나타냄
Gantt Chart
- 간트 차트 = 시간선 = Time Line
- 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표
- 중간 목표 미달성시 그 이유와 기간을 예측 가능
- 사용자와의 문제점이나 예산의 초과 지출 등을 관리
- 자원 배치와 인원 계획에 사용 가능
- 다양한 형태로 변경 가능
- 작업 경로를 표시할 수 없다.
- 계획의 변화에 대한 적응성이 약하다.
- 계획 수립 또는 수정 때 주관적 수치에 기울어지기 쉽다.
- 이정표, 작업 일정, 작업 기간, 산출물로 구성
프로젝트 조직 구성 계획
분산형 팀 구성
- 팀원 모두가 의사 결정에 참여하는 비이기적인 구성 방식
- 민주주의식 팀 구성
- 팀 구성원의 참여도와 만족도를 높이고 이직률을 낮게 한다.
- 팀 구성원 각자가 서로의 일을 검토하고 다른 구성원이 일한 결과에 대해 같은 그룹의 일원으로 책임을 진다.
- 여러 사람의 의사를 교류하므로 복잡하고 이해되지 않는 문제가 많은 장기 프로젝트 개발에 적합
- 링 모양의 구조를 가진다.
- 팀 구성 방법 중 가장 많은 의사 소통 경로를 갖는다.
중앙 집중형 팀 구성
- 관리자가 의사 결정을 하고 그 결정에 따르는 구성 방식
- 책임 프로그래머 팀 구성
- 프로젝트 수행에 따른 모든 권한과 책임을 한 명의 관리자에게 위임하고 기술 및 관리 지원을 위해 인력을 투입하는 형태
- 소규모 프로젝트에 적합
- 프로젝트의 성공은 책임 프로그래머의 능력에 달렸다.
- 책임 프로그래머에 따라 의사 결정이 이뤄지기 때문에 의사 결정이 빠르고 의사 교환 경로를 줄일 수 있다.
- 책임 프로그래머 : 요구 분석 및 설계, 기술적 판단, 프로그래머 작업 지시 및 배분
- 프로그래머 : 책임 프로그래머 지시에 따른 코딩, 테스트, 디버깅, 문서 작성
- 프로그램 사서 : 프로그램 리스트, 설계 문서, 테스트 계획 관리
- 보조 프로그래머 : 책임 프로그래머의 업무 지원, 기술적 문제에 대한 자문, 사용자와 품질 보등 담당자 섭외, 책임 프로그래머 감독 하 분석, 설계 구현 담당
계층적 팀 구성
- 분산형과 중앙 집중형을 혼합한 형태로 혼합형 팀 구성
- 초급 프로그래머를 작은 그룹으로 만들어 각 그룹을 고급 프로그래머가 관리
- 경험자와 초보자를 구별
- 기술 인력이 관리를 담당하게 되어 좋은 기술력을 사장시킬 수 있고, 기술 인력이 업무 관리 능력을 갖춰야한다.
소프트웨어 품질 보증
품질 표준
소프트웨어의 운영적인 특성, 소프트웨어의 변경 수용능력, 새로운 환경에 대한 소프트웨어의 적응 능력에 따라 분류
운영특성
- 정확성 : Correctness 사용자의 요구 기능 충족
- 신뢰성 : Reliability 요구된 기능을 오류 없이 수행하는 정도
- 효율성 : Efficiency 소프트웨어가 자원을 쓸데없이 낭비하지 않아야한다.
- 무결성 : Integrity 허용되지 않는 사용이나 자료의 변경을 제어하는 정도
- 사용 용이성 : Usability 소프트웨어는 적절한 UI와 문서를 가지고 있어야한다.
변경 수용 능력
- 유지보수성 : Maintainability 변경 및 오류 사항 교정에 대한 노력을 최소화 하는 정도, 소프트웨어를 진화하는 것이 가능해야 한다.
- 유연성 : Flexibility 소프트웨어를 얼마만큼 쉽게 수정할 수 있는가의 정도
- 시험 역량 : Testability 프로그램을 시험할 수 있는 정도
적응 능력
- 이식성 : Portability 다양한 하드웨어 환경에 운용이 가능하도록 쉽게 수정될 수 있는 정도
- 재사용성 : Reusability 전체나 일부 소프트웨어를 다른 목적으로 사용할 수 있는가의 정도
- 상호 운용성 : Interoperability 다른 소프트웨어와 정보를 교환할 수 있는 정도
품질 보증
- SQA = Software Quality Assurance
- 어떠한 소프트웨어가 이미 설정된 요구사항과 일치하는가를 확인하는 데 필요한 개발 단계 전체에 걸친 계획적이고 체계적인 작업
- 소프트웨어 개발 초기에 소프트웨어 특성과 요구사항을 철저히 파악하여 품질 목표를 설정하고, 개발 단계에서는 정형 기술 검토를 통해 품질 목표의 충족 여부를 점검하며, 개발 후에는 디버깅과 시험 과정을 거친다.
정형 기술 검토
- FTR = Formal Technical Review
- 가장 일반적인 검토 방법으로 소프트웨어 기술자들에 의해 수행되는 소프트웨어 품질 보증 활동
- 검토회의, 검열 등이 있으며 회의 형태로 수행된다.
- 검토중인 소프트웨어가 해당 요구사항과 일치하는지를 검증
- 미리 정해진 표준에 따라 표현되는지를 확인
- 기능과 로직에 오류가 있는지 확인
- 소프트웨어가 균일한 방식으로 개발되도록 한다.
- 프로젝트를 용이하게 관리하도록 한다.
정형 기술 검토 지침사항
- 제품 검토에만 집중
- 의제를 제한하여 진행
- 논쟁과 반박을 제한
- 문제 영역을 명확히 표현
- 해결책이나 개선책에는 논하지 말라
- 참가자의 수를 제한하고 사전 준비를 강요
- 검토될 확률이 있는 각 제품에 대한 체크리스트 개발
- 자원과 시간 일정을 할당
- 모든 검토자들을 위해 훈련
- 사전에 작성한 메모를 공유
- 검토 과정과 결과를 재검토
정형 기술 검토 유형
Walkthrough
- 검토 회의 = 워크스루
- 소프트웨어 개발 각 단계에서 개최하는 기술 평가 회의
- 소프트웨어 구성요소와 같은 작은 단위를 검토하는 것
- 오류의 조기 검출을 목적으로 하며 발견된 오류는 문서화
- 검출된 오류는 회의 후에 해결
- 3~5명이 검토에 참여해야하며 두 시간 이내
- 검토를 위한 자료를 미리 배포하여 검토, 미리 검토하는 시간도 두 시간 이내
Inspections
- 검열 = 심사
- 검토 회의를 발전시킨 형태
- 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하며 이를 개선시키는데 사용
기타
- 검증 : Verification 설계의 각 과정이 올바른지, 프로그램이나 하드웨어에 오류가 있는지를 검사
- 확인 : Validation 올바른 제품을 생산할 수 있도록 정의, 분석이 잘 되었는지를 검사
- 인증 : Certification 사용자 또는 전문가가 소프트웨어 품질을 공식적으로 확인
- 소프트웨어 시험 : Test
- 오류 수정 : Debugging
소프트웨어 신뢰성과 가용성
- 신뢰성 : 프로그램이 주어진 환경에서 주어진 시간동안 오류 없이 작동할 확률로 측정과 예측이 가능하다.
- 가용성 : 한 프로그램이 주어진 시점에서 요구사항에 따라 운영되는 확률
측정
- 신뢰성 측정은 MTBF를 이용한다.
- MTBF
- Mean Time Between Failure
- 평균 고장 간격
- 수리가 가능한 시스템이 고장난 후부터 다음 고장이 날 때까지의 평균 시간
- MTBF = MTTF + MTTR
- MTTF
- Mean Time To Failure
- 평균 가동 시간 = 고장 평균 시간
- 수리 불가능한 시스템의 사용 시점부터 고장이 발생할 때까지의 가동 시간 평균
- MTTF = (가동중1 + 가동중2 + 가동중3 + ... + 가동중 n) / n
- MTTR
- Mean Time To Repair
- 평균 수리 시간
- 시스템 고장이 발생하여 가동하지 못한 시간들의 평균
- MTTR = (고장중1 + 고장중2 + 고장중3 + ... + 고장중 n) / n
- 가용성 측정
- 시스템의 총 운용 시간 중 정상적으로 가동된 시간의 비율
- 가용성 = 가동시간 / (가동시간 + 고장시간) = MTBF / (MTBF + MTTR)
위험 관리
- Risk Analysis
- 프로젝트 추진 과정에서 예상되는 각종 돌발 상황을 미리 예상하고 대책을 수립하는 활동
- 위험은 불확실 성과 손실을 가지고 있는데, 위험관리로 대비한다.
- 위험 식별 => 위험 분석 및 평가 => 위험 관리 계획 => 위험 감시 및 조치
범주
- 프로젝트 위험 : Project Risk
- 기술 위험 : Technical Risk
- 비즈니스 위험 : Business Risk
종류
- 인력 부족
- 예산 관리
- 일정 관리
- 사용자 요구사항 변경 : 대표적 위험 요소
Charette가 제안한 종류
- 알려진 위험 : 프로젝트 계획서, 기술적 환경, 정보 등에 의해 발견 될 수 있는 위험
- 예측 가능한 위험 : 과거의 경험으로 예측 가능한 위험
- 예측 불가능한 위험 : 사전 예측이 매우 어려운 위험
위험 분석 및 평가
- 프로젝트에 내재한 위험 요소를 인식하고 그 영향을 분석하는 활동
- 위험 추산(Risk Estimation) 작업을 통해 수행된다.
- 가능한 모든 위험 요소와 영향을 분석하여 의사결정에 반영
- 위험표(Risk Table)을 작성하여 활용한다.
위험표
- 위험 내용
- 위험 범주
- 발생 확률
- 영향력
- 위험 감시 및 조치
위험 감시 및 조치
- 위험 회피 : Risk Avoidance 예상하고 회피
- 위험 감시 : Risk Monitoring 위험 요소 징후에 대해 계속적으로 인지하는 것
- 위험 관리 : Risk Management
- 비상 계획 수립 : Contingency Plan 위험 회피 전략이 실패할 경우 위험에 대해 관리하고 대비책과 비상 계획을 수립한다.
소프트웨어 형상 관리
- SCM = Software Configuration Management
- 소프트웨어 변경 사항을 관리하기 위해 개발된 일련의 활동
- 소프트웨어 변경의 원인을 알아내고 제어하며 적절이 변경되고 있는지 확인하여 담당자에게 통보하는 작업
- 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동
- 유지보수 단계에서도 수행
- 형상 관리는 소프트웨어 개발의 전체 비용을 줄인다.
- 개발 과정의 여러 방해 요인을 최소화시킨다.
- 형상은 소프트웨어 각 개발 단계의 결과물
형상 항목
- SCI = Software Configuration Item
- 스시템 명세서
- 소프트웨어 프로젝트 계획서
- 소프트웨어 요구사항 명세와 실행가능한 프로토타입
- 예비 사용자 매뉴얼
- 설계 명세서
- 원시 코드 목록