Agapang

: 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템을 개발하기 위한 전반적인 활동

: 소프트웨어 개발 계획을 세우고 분석, 설계 구현 등 작업을 통제

- 프로젝트 관리 대상

1. 계획 관리

: 프로젝트 계획, 비용 산정, 일정 계획, 조직 계획

2. 품질 관리

: 품질 통제, 품질 보증

3. 위험 관리

: 위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치

- 효과적인 프로젝트 관리를 위한 3P
: 사람(Person), 문제(Problem), 프로세스(Process)

- 프로젝트 관리의 구성 단계



2. 프로젝트 계획 수립
: 프로젝트 계획은 프로젝트가 수행되기 전에
: 소프트웨어의 개발 영역 결정, 필요한 자원, 비용, 일정 등을 예측하는 작업
: 관리자가 자원, 비용, 일정 등을 합리적으로 예측할 수 있도록 프로젝트 틀을 제공
: 소프트웨어 개발 과정에서 발생할 수 있는 여러 가지 위험성을 최소화 할 수 있음
: 프로젝트 계획 수립 후에는 시스템 정의서 와 프로젝트 계획서 가 산출됨

- 소프트웨어 개발 영역(Scope,범위) 결정
: 프로젝트 계획 수립의 첫 번째 업무로, 개발될 소프트웨어 영역을 결정하는 것
: 소프트웨어 개발 영역을 결정하는 주요 요소에는 처리될 데이터와 소프트웨어에 대한 기능, 성능, 제약조건, 인터페이스 및 신뢰도 등이 있다

- 자원 추산
: 개발에 필요한 자원을 예측
: 인적 자원, 재사용 소프트웨어 자원, 환경 자원 등이 있음

- 소프트웨어 프로젝트 추산
: 비용 예측

- 프로젝트 계획 수립 시 고려사항
: 프로젝트 복잡도, 규모, 구조적 불확실성 정도, 과거 정보의 가용성, 위험성


3. 소프트웨어 프로젝트 추산
: 소프트웨어 프로젝트 추산은 프로젝트를 수행하는 데 필요한 소프트웨어의 직, 간접적인 비용을 예측하는 작업

- 프로젝트 비용 결정 요소
1. 프로젝트 요소
: 어떤 소프트웨어를 개발할 것인가에 따라 비용이 달라질 수 있다
: 제품의 복잡도, 시스템의 크기, 요구되는 신뢰도 등

2. 자원 요소
: 개발에 필요한 각종 자원들의 투자 정도에 따라 비용이 달라질 수 있다
: 인적 자원, 하드웨어 자원, 소프트웨어 자원 등

3. 생산성 요소
: 개발자의 능력, 경험 및 주어진 개발 기간 등

- 개발 비용과 시스템 크기, 신뢰도, 개발 기간의 관계





4. 비용 산정 기법

1. 하향식 산정 기법
: 과거 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법
: 프로젝트의 전체 비용을 산정한 후 각 작업별로 비용을 세분화
: 전문가 감정 기법, 델파이 기법 등이 있음

2. 상향식 산정 기법
: 프로젝트의 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정방법
: LOC(원시 코드 라인 수) 기법, 개발 단계별 인월수 기법, 수학적 산정기법


* 노력/기간 = 필요 인원수

5. 수학적 산정 기법

1. COCOMO모형
: 보헴이 제안, 원시 프로그램의 규모인 LOC(원시 코드 라인 수)에 의한 비용산정기법
: 개발할 소프트웨어의 규모(LOC)를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정공식에 대입하여 비용을 산정
: 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리통용
: 같은 규모의 프로그램이라도 그 성격에 따라 비용이 다르게 산정
: 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 나타남

- 소프트웨어 개발 유형
1. 조직형(Organic Mode) - 5만라인 이하
: 중, 소규모의 소프트웨어로 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료처리용으로
5만 라인 이하의 소프트웨어를 개발하는 유형

2. 반분리형(Semi-Detached Mode) - 30만 라인 이하
: 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 라인이하의 소프트웨어를 개발하는 유형

3. 내장형(Embedded Mode) - 30만 라인 이상
: 최대형 규모의 트랜잭션 처리 시스템이나 운영체제 등 30만 라인 이상의 소프트웨어를 개발하는 유형

- COCOMO 모형의 종류

1. 기본형(Basic)
: 소프트웨어의 크기와 개발 유형만을 이용하여 비용을 산정하는 모형

2. 중간형(Intermediate)
: 기본형의 공식을 토대로 사용하나, 제품의 특성, 컴퓨터의 특성, 개발요원의 특성, 프로젝트의 특성의 15가지 요인에 의해 비용을 산정하는 모형

- 제품의 특성
: 요구되는 신뢰도, 데이터베이스 크기, 프로그램 복잡도

- 컴퓨터의 특성
: 수행 시간의 제한, 기억장소의 제한 가상 기계의 안전성, Turn Around Time

- 개발요원의 특성
: 분석가의 능력, 개발 분야의 경험, 가상 기계의 경험, 프로그래머의 능력, 언어의 경험

- 프로젝트 특성
: 소프트웨어 도구의 이용, 프로젝트 개발 일정, 최신 프로그래밍 기법의 이용

3. 발전형(Detailed)
: 중간형을 보완하여 만들어진 방법
: 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형



2. Putnam 모형 - 생명 주기 예측 모형: 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 가정해주는 모형
: 푸트남이 제안한 것으로 생명 주기 예측 모형이라고 함
: 시간에 따른 함수로 표현되는 Rayleigh-Norden곡선의 노력 분포도를 기초
: 대형 프로젝트의 노력 분포 산정에 이용되는 기법

3. 기능 점수 모형(FP; Function Point) 모형
: 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며 총 기능 점수와 영향도를 이용하여 기능 점수를 구한 후 이를 이용하여 비용을 산정하는 기법

- 자동화 추정 도구
: 비용 산정의 자동화를 위해 개발된 도구

1. SLIM
: Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 도구

2. ESTOMACS
: 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정도구


6. 프로젝트 일정 계획
: 프로젝트 일정 계획은 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여, 소작업의 순서와 일정을 정하는 것
: 프로젝트 일정 계획을 위해서는 WBS, PERT/CPM, 간트 차트등이 사용된다

- 기본원칙
: 분할, 상호 의존성, 시간 할당, 노력 확인, 책임성, 정의된 산출물, 이정표

- 사람-노력 관계와 노력 분배
1. 사람-노력
: 소규모의 개발 프로젝트에서는 한 사람이 요구사항을 분석하고, 설계, 코딩, 테스트까지 수행할 수 있다

2. Brooks의 법칙
: 프로젝트 진행중에 새로운 인력을 투입할 경우 작업 적응 기간과 부작용으로 인해 일정을 더욱 지연시키고, 프로젝트에 혼란을 가져오게 된다

3. 노력 분배
: 예측된 노력을 각 개발 과정에 분배할 때는 40-20-40규칙을 권장
: 분석과 설계 40%, 코딩 20%, 테스트 40%를 분배한다는 의미

- WBS(Work Breakdown Structure, 업무 분류 구조)
: 개발 프로젝트를 여러 개의 작은 관리 단위(소작업)로 분할하여 계층적으로 기술한 업무 구조
: 일정 계획의 첫 단계에서 작업을 분할할 때 사용되는 방법

- PERT/CPM - *
: 프로젝트의 지연을 방지하고 계획대로 진행하게 하기위한 일정을 계획하는 것으로, 대단위 계획의 조직적인 추진을 위해 자원의 제약하에 비용을 적게 사용하면서 초단시간 내 계획 완성을 위한 프로젝트 일정 방법

- PERT/CPM 네트워크를 통해 계산될 수 있는 경계 시간들
: 모든 선행 작업들이 가능한 최단시간 내에 완성될 때 한 작업이 시작될 수 있는 가장 빠른시간
: 최소의 프로젝트 완료 시간이 지연되기 전에 작업 개시를 위한 가장 늦은 시간
- 가장 빠른 완료 시간 : 가장 빠른 개시 시각과 작업 기간의 합
- 가장 늦은 완료 시간 : 가장 늦은 개시 시각과 작업 기간의 합
- 총 자유 시간 : 네트워크 임계 경로를 일정대로 유지하기 위해 작업이 허용된 이영어 시간의 양인 전체 여유 시간

-PERT(Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술)
: 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크로 각 작업별로 낙관적인 경우, 가능성이 있는 경우, 비관적인 경우로 나눠 각 단계별 종료 시기를 결정하는 방법
: 과거의 경험이 없어서 소요 시간 예측이 어려운 소프트웨어에서 사용
: 노드와 간선으로 구성되며 원 노드에는 작업을, 간선에는 낙관치, 기대치, 비관치 표시
: 결정경로, 작업에 대한 경계시간, 작업 간의 상호 관련성 등을 알 수 있음

- CPM(Critical Path Method, 임계 경로 기법)
: 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
: CPM은 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타냄
: 각 작업의 순서와 의존 관계, 어느 작업이 동시에 수행될 수 있는지를 한눈에 볼 수 있다
: 경영층의 과학적인 의사 결정을 지원하며, 효과적인 프로젝트의 통제를 가능하게 해줌

- 간트 차트(Gantt Chart) - 시간선(Time-Line)차트
: 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표.
: 중간 목표 미달성 시 그 이유와 기간을 예측할 수 있게 한다
: 사용자와의 문제점이나 예산의 초과 지출 등도 관리할 수 있게함
: 자원 배치와 인원 계획에 유용하게 사용된다
: 다양한 형태로 변경하여 사용할 수 있다
: 이정표, 작업 일정, 작업 기간, 산출물로 구성


7. 프로젝트 조직 구성 계획
- 프로젝트 팀 구성
: 의사 결정권이 누구에게 있느냐에 따라 팀 구성이 달라진다

1. 분산형 팀 구성 - 민주주의식 팀 구성
: 팀원 모두가 의사 결정에 참여하는 비이기적인 구성방식
: 여러 사람의 의사를 교류하므로 복잡하고 이해되지 않는 문제가 많은 장기 프로젝트 적합

2. 중앙 집중형 팀 구성 - 책임 프로그래머 팀 구성
: 한 관리자가 의사 결정을 하고 팀 구성원들은 그 결정에 따르는 구성방식
: 의사결정이 빠르고 의사 교환 경로를 줄일 수 있다
: 소규모 프로젝트에 적합
: 구성원 - 책임프로그래머, 프로그래머, 프로그램 사서, 보조 프로그래머

3. 계층적 팀 구성
: 분산형과 중앙 집중형 팀 구성을 혼합한 형태
: 5~7명의 초급 프로그래머를 작은 그룹으로 만들어 각 그룹을 고급 프로그래머가 관리
: 기술 인력이 관리를 담당하게 되며 좋은 기술력을 사장시킬 수 있으며,
: 기술 인력이 업무 관리 능력을 갖춰야 한다는 단점이 있음


8. 소프트웨어 품질 보증
- 소프트웨어 품질(Quality)
: 주어진 요구사항을 만족시키는 능력을 갖추고 있는 소프트웨어의 측정 가능한 기능 및 특성을 의미
- 설계 품질: 설계자가 한 품목을 위해 규정한 특성
- 일치 품질: 설계 내용들이 개발 과정에서 지켜지는 정도

- 품질 표준(목표)
: 명확하게 정의된 소프트웨어의 특성을 의미하며, 소프트웨어의 품질을 평가하는 기준 항목으로 사용

- 소프트웨어 운영 특성
: 정확성(Correctness), 신뢰성(Reliability), 효율성(Efficiency), 무결성(Integrity),
사용 용이성(Usability)

- 소프트웨어 변경 수용 능력
: 유지보수성(Maintainability), 유연성(Flexibility), 시험 역량(Testability)

- 소프트웨어 적용 능력
: 이식성(Portability), 재사용성(Reusability), 상호운용성(Interoperability)

- 소프트웨어 품질보증(SQA: Software Quality Assurance)
: 어떠한 소프트웨어가 이미 설정된 요구사항과 일치하는가를 확인하는 데 필요한 개발 단계 전체에 걸친 계획적이고 체계적인 작업

- 정형 기술 검토(FTR: Formal Technical Review)
: 가장 일반적인 검토 방법으로 소프트웨어 기술자들에 의해 수행되는 소프트웨어 품질 보증 활동
: 유형 - 검토 회의(Walkthrough), 검열(Inspections) 등
- 검토 지침 사항
1. 논쟁과 반박을 제한한다
2. 해결책이나 개선책에 대해서 논하지 말라
3. 참가자의 수를 제한하고 사전 준비를 강요하라
4. 검토될 확율이 있는 가 제품에 대한 체크 리스트를 개발하라
5. 자원과 시간 일정을 할당하라
6. 검토의 과정과 결과를 재검토하라

1)  검토 회의(Walkthrough)
: 소프트웨어 개발의 각 단계에서 개최하는 기술평가 회의로, 소프트웨어 구성 요소와 같은 작은 단위를 검토하는 것
: 오류의 조기 검출을 목적으로 하여 발견된 오류는 문서화한다
: 검출된 오류는 검토 회의 기간 동안에 해결하지 않고 미뤄 뒀다가 검토 회의 후에 해결
: 3~5명이 검토에 참여해야 하며 검토 회의 시간은 두 시간 이내로 해야한다

2) 검열(Inspections, 심사)
: 검토 회의를 발전시킨 형태로, 소프트웨어 개발 단계에서 산출된 결과물의 품질을 평가하며 이를 개선시키는 데 사용
: 검열 팀은 관련 분야에 대해 훈련을 받은 1~4명의 요원으로 구성되며, 검열자는 검열 항목에 대한 체크리스트를 이용하여 작업을 수행

- 기타 품질 보증 활동
: 검증(Verification), 확인(Validation), 인증(Certification), 소프트웨어 시험(Test),
오류 수정(Debugging)


9. 소프트웨어의 신뢰성과 가용성
- 소프트웨어의 신뢰성
: 프로그램이 주어진 환경에서 주어진 시간 동안 오류 없이 작동할 확률을 의미

- 소프트웨어 가용성
: 한 프로그램이 주어진 시점에서 요구사항에 따라 운영되는 확률을 의미

- 신뢰성과 가용성 측정
1. MTBF(Mean Time Between Failure)
: 평균 고장 간격, 수리가 가능한 시스템이 고장난 후부터 다음 고장 날 때까지 평균시간
: MTBF = MTTF + MTTR

2. MTTF(Mean Time To Failure)
: 평균 가동 시간, 수리가 불가능한 시스템의 사용 시점 부터 고장이 발생할 때까지의 가동 시간 평균, 고장 평균 시간이라고도 함
: 가동중인 시간들의 합 / 가동 횟수

3. MTTR(Mean Time To Repair)
: 평균 수리 시간, 시스템에 고장이 발생하여 가동하지 못한 시간들의 평균
: 고장중인 시간들의 합 / 고장 횟수

- 가용성 측정: 시스템의 총 운용 시간 중 정상적으로 가동된 시간의 비율


10. 위험 관리(Risk Analysis)
: 프로젝트 추진 과정에서 예상되는 각종 돌발 상황(위험)을 미리 예상하고 이에 대한 적정한 대책을 수립하는 일련의 활동을 의미

- 위험의 범주
: 프로젝트 위험(Project Risk), 기술 위험(Technical Risk), 비지니스 위험(Business Risk)

- 위험의 종류
: 인력 부족, 예산 관리, 일정 관리, 사용자 요구 사항 변경 등
: 알려진 위험(Known Risk), 예측 가능한 위험(Predictable Risk), 예측 불가능한 위험
: 예측 가능한 위험 항목 - 제품 크기, 고객 특성, 개발환경, 비지니스 영향, 프로세스 정의, 구축할 기술, 기술진의 규모와 경험

- 위험 관리 절차
: 위험 식별 -> 위험 분석 및 평가 -> 위험 관리 계획 -> 위험 감시 및 조치

1. 위험 식별
: 알려지거나 예측 가능한 위험 요소를 파악하는 작업

2. 위험 분석 및 평가
: 프로젝트에 내재한 위험 요소를 인식하고 그 영향을 분석하는 활동,
: 위험 추산 작업을 통해 수행, 위험 추산을 위해 위험표 작성
: 위험 내용 -> 위험 범주 -> 발생확률 -> 영향력 -> 위험 감시 및 조치

3. 위험 관리 계획

4. 위험 감시 및 조치
: 위험 회피, 위험 감시, 위험 관리 및 비상 계획 수립

* 위험표(risk table)의 사항: 위험 발생 확률, 위험의 내용 및 종류, 위험에 따르는 영향력
* 위험 모니터링: 위험 요소 징후들에 대하여 계속적으로 인지하는 것

11. 소프트웨어 형상 관리
1. 형상 관리(SCM: Software Configuration Management)
: 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리 위해 개발된 일련의 활동
: 소프트웨어의 변경 원인을 알아내고 제어하며 적절히 변경, 확인하여 해당 담장자에게 통보하는 작업
: 형성관리 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 한다

2. 소프트웨어 형상 항목(SCI: Software Configuration Item)
: 시스템 명세서, 프로젝트 계획서, 소프트웨어 요구사항 명세와 실행 가능한 프로토 타입
: 예비 사용자 메뉴얼, 설계 명세서, 원시 코드 목록, 테스트 계획, 절차, 시험사례, 결과
: 운영과 설치에 필요한 메뉴얼
: 실행 프로그램, 데이터베이스 기술서 - 스키마, 파일구조, 초기내용
: 구축된 사용자 메뉴얼, 유지보수 문서 - 변경 요청서, 변경 처리 보고서
: 소프트웨어 공학을 위한 표준과 절차