Project Management Flashcards Preview

PE > Project Management > Flashcards

Flashcards in Project Management Deck (93):
1

Project Management

⦿ 정의 : 프로젝트를 성공적으로 관리하는데 필수적인 일정, 조직, 인력, 지휘, 통제를 제공하는 절차와 실행기술, 지식 등의 체계
⦿ 특징 (유일목점)
- 유일성 : 똑같은 것 없음
- 일시성 : 시작과 끝 명확
- 목적성 : 목적 달성 행위
- 점진적 상세화 : 점차 구체화
⦿ 목적
- SW측면 : 품질고도화, 생산성
- 개발측면 : 표준화, 목표수립
⦿ 영역 (통범일원 품인의 위조이)
- 통합 관리
- 범위 관리
- 일정 관리
- 원가 관리
- 품질 관리
- 인력 관리
- 의사소통 관리
- 위험 관리
- 조달 관리
- 이해관계자 관리
⦿ 생명주기
- 착수
- 계획
- 실행
- 통제
- 종료

2

프로젝트 조직

⦿ 기능 조직
- 장점 : 단순함, 유연함, 전문성
- 단점 : 의사소통 부제, 편협성
⦿ 프로젝트 조직
- 장점 : 의사소통 용이, 신속함
- 단점 : 개인에 의존, 자원낭비
⦿ 매트릭스 조직
- 장점 : 자원활용 극대화
- 단점 : 조직 구성 복잡, 의사결정 지연

3

프로젝트

⦿ 범위 : 특정 인도물 중심
⦿ 변경관리 : 변경 최소화 노력
⦿ 관리방법 : 일정, 예산, 성과물
⦿ 포커스 : 리더십, 업무성취, 감독
⦿ 관리대상 : 기술자, 전문가
⦿ 관리자의 역할 : 동기부여, 팀플
⦿ 계획 수준 : 결과물 관리 계획
⦿ 관심 사항 : 생산작업 감시통제

4

프로그램

⦿ 범위 : 여러 프로젝트들의 집합
⦿ 변경관리 : 변경 예견 수용
⦿ 관리방법 : ROI, 능력기준
⦿ 포커스 : 갈등해소, 정치측면
⦿ 관리대상 : PM 관리
⦿ 관리자의 역할 : 비전, 리더십
⦿ 계획 수준 : 상위 수준 계획
⦿ 관심 사항 : 지배구조, 업무감시

5

포트폴리오

⦿ 범위 : 기업의 전략적 목표 Biz
⦿ 변경관리 : 광의의 환경 변화
⦿ 관리방법 : 총체적 성과
⦿ 포커스 : 가치부여
⦿ 관리대상 : 포트폴리오 스텝
⦿ 관리자의 역할 : 통찰력, 통합
⦿ 계획 수준 : 의사소통
⦿ 관심 사항 : 전체성과, 가치지표

6

포트폴리오 관리

⦿ 정의 : 기존 프로젝트들을 가속화 시키거나 Drop하기도 하는 의사결정 프로세스
⦿ 의사결정 방법 (전재포스)
1) 전략적 방법
- NPV, ROI, 투자회수기간
2) 재무적 방법
- 시장, 기술, 필요성
3) 포트폴리오 맵/프레임워크
- BGC, GE Matrix
4) 스코어링 모델
- 프로젝트 단위 점수 환산 평가
⦿ 관리 체계
- 조직체계
- 통합 프로세스
- 명확한 의사결정 기준
- 지원 시스템
- 의사결정 프로세스

7

WBS (Work Breakdown Structure)

⦿ 정의 : 프로젝트 팀이 실행할 작업을 산출물 중심으로 분할한 계층 구조 체계
⦿ 특징
- 산출물 중심 : 작업단위
- 의사소통도구 : 이해관계자
- R&R정의 : 각 단계 업무
- 진척관리 : 일정, 비용 예상
- 가시성 : 작업 명세화
⦿ 작성 절차
- Scope Planning : 범위계획
- Scope Definition : 범위정의
- Activity Definition : 행위정의
- Activity Sequencing : 행위순서
- Activity Duration Estimating : 행위일정추정
- Scope Development : 범위개발
⦿ 구성요소
- Work Package : 최하위 작업단위
- WBS Dictionary : WP상세 내용
- Code of Account : WBS 고유 식별 번호
- Duration & Relationship : WP 소요기간
- RAM : 각 담당 책임자
⦿ WBS 계층구조
1. Project : 전체 개요, 범위
2. Deliverable : 주요 산출물
3. Sub-deliverable : 부수 산출물
4. Lowest Sub-deliverable : 최종 상세 산출물
5. Cost Account : WP 그루핑
6. Work Package : 수행작업
⦿ 작업절차
1) WBS 요소나열
- WBS 요소나열
2) WBS 설계
- 개략 설계
- WBS 요소의 선택
- 상세 설계
- WBS Dictionary 구성
3) WBS 후속작업
- WBS 제안
- WBS 계약
- WBS 관리
⦿ WBS 분할조건
- 개별적 의미의 독립적 분할
- 수행 기간 및 예산 산출 가능
- 명확한 이해 가능 산출물 명시
- 수행하는 사람이 익숙하게
⦿ WBS 정의 원칙
- One Week : 하나의 Task 5일 이상
- Two Week : 최대 10일 이내
- Six Week : 범위 밖은 요약 수준으로 나타냄

8

EVM (Earned Value Management)
AC, PV, EV

⦿ 정의 : 프로젝트 비용, 일정, 수행 목표의 기준을 설정하고 실제 진도 측정 및 분석을 통해 문제점 분석, 만회 대책 수립, 향후 예측을 가능하게 하는 성과 위주의 관리 기법
⦿ 기성고 관리의 절차
1) 작업범위, 일정, 비용 Base Line 설정
2) 실적측정 (범위, 일정, 비용)
3) 계획대비 실적평가
4) 문제점 해결/예측
5) 계획수정/위험예방
⦿ EVM 측정지표
- PV : 계획 작업량
- EV : 수행 작업량
- AC : 실투입비용
- BAC : 예산
⦿ EVM 분석지표
- SV : 일정편차 (SV=EV-PV)
- CV : 비용편차 (CV=EV-AC)
- SPI : 일정지표 (SPI=EV/PV)
- CPI : 비용지표 (CPI=EV/AC)
⦿ EVM 예측지표
- ETC : 잔여분 산정치 (ETC=BAC-EV)
- EAC : 완료시점 산정치 (EAC=AC+(BAC-EV)/CPI
- BCWR : 실시기성 차감 금액 (BCWR=BAC-EV)
- VAC : 완료시점 비용편차 (VAC=BAC-EAC)

9

일정관리

⦿ 정의 : 프로젝트 품질을 확보하면서 제한된 납기 준수를 위해 일정을 체계적으로 계획, 관리, 통제하는 관리활동 (PMC : Plan, Monitor, Control)
⦿ 일정계획 수립시 고려사항
- 업무담당자, 전후관계, 업무규모, 생산성
⦿ 특징
- 납기준수, 자원 효율성 향상, 일정 산출
⦿ 절차 (정순자 기일통)
1) Activity 활동정의
- 입력 : WBS
- 도구 : 분해, 전문가판단
- 산출 : 목록/속성, 마일스톤
2) Activity 순서배열
- 입력 : 목록/속성, 마일스톤
- 도구 : PDM, ADM, 의존관계
- 산출 : 네트워크 다이어그램
3) Activity 자원산정
- 입력 : 목록/속성, 자원역일표
- 도구 : 전문가판단, 대안분석
- 산출 : RBS(Resource)
4) Activity 기간산정
- 입력 : 목록/속성, 범위기술서, 자산
- 도구 : 전문가판단, 모수/3점 산정
- 산출 : 기간 산정치, 문서 갱신
5) 프로젝트 일정개발
- 입력 : PND, 목록/속성, 환경요인
- 도구 : CPM, CCM, What-if, Crashing, Fast Tracking
- 산출 : 일정, 일정 기준선
6) 일정통제
- 입력 : 계획, 일정, 성과, 자산
- 도구 : 성과검토, 차이분석
- 산출 : 작업성과 산정치

10

선후행 도형법(PDM : Precedence Diagramming)

⦿ 정의 : 활동을 노드로 표시하고 그들의 연관관계를 화살표로 표시(AON:Activity on Node)
⦿ 특징
- FS, FF, SS, SF 표현
⦿ 종류
- SS (Start to Start)
- FS (Finish to Start)
- SF (Start to Finish)
- FF (Finish to Finish)

11

화살 도형법(ADM : Arrow Diagramming)

⦿ 정의 : 활동의 시작과 끝을 원 형태의 노드로 표시하고, 그 사이에 화살표로 활동을 표시하는 방식(AOA : Activity on Arrow)
⦿ 특징
- 선행작업 완료 후 후속작업 착수 (FS) 관계만 표현
- 모든 논리관계를 정확히 명시하기 위하여 모조(Dummy)활동을 사용

12

일정 추정 기법

- 전문가 판단 : 유사 프로젝트 근거
- Simulation : 가상 테스트
- CPM : 1점 추정
- PERT : 3점 추정
기대시간 = (a + 4m + b) /6
(a: 낙관, m: 정상, b: 비관)
분포 = ((b – a)/6)2
- Monte Carlo Simulation : 난수 생성 값 확률분포 근사치

13

일정 관리 기법

- Network Diagram (PERT/CPM)
- Gantt Chart
- Milestone

14

일정 단축 기법

- Crashing : 자원을 CP상의 Activity에 추가 투입, 비용초과로 고객승인 필요
- Fast Tracking : 병행 추진, 기간 장기화 위험 내포
- What-if 시나리오 : 영향 Factor기준 분석 및 대안 시뮬레이션
- Resource Leveling : 가용자원 한계 내에서 배정

15

신규 투입 인력에 따른 일정 단축 불가사유

⦿ 신규인력 추가 투입시 문제점
- Brooks 이론
- N의 제곱 복잡도
⦿ 일정단축 불가사유
- 추가 투입인력 교육
- 커뮤니케이션 비용 및 오류 증가
- 업무 오류 증가
- 추가 일정 지연 가능
⦿ 해결절차
- CP상의 일정인지 확인
- 해당업무의 지연 원인 확인
- 원인 분석 및 해결 방안 도출

16

PERT

⦿ 주목적 : 프로젝트 기간 단축
⦿ 일정계산 : 단계(Event) 중심
⦿ 시간추정
- 공정별 처리 순서로 정의
- 작업대기시간 추출
(낙관치 * 4평균 + 비관치)/6
- 가장 신뢰도가 높은 것을 주공정으로 선택
⦿ 장점
- 경험적 교훈이 없는 경우
- 불확실성이 높은 경우
⦿ 단점 : 확률론 이용에 한의 위험성
⦿ 활용사례 : 불확실한 대상인 우주산업

17

CPM (Crital Path Method)

⦿ 주목적 : 프로젝트 비용 절감
⦿ 일정계산 : 요소작업(Activity) 중심
⦿ 시간추정
- 단축 활동의 초과 직접비 산출
- 평균값 이용, 1점 추점방식)
⦿ 장점
- 경험적 교훈이 있는 경우
- 불확실성이 적은 경우
⦿ 단점 : 잘 알려진 자원과 기술에만 적용 가능

18

CCM (Crital Chain Method)

⦿ 개념 : 자원 제약 사항을 반영하여 프로젝트 일정을 계획하는 일정 네트워크 분석 기법
⦿ 납기가 지연되기 쉬운 이유
- 파킨슨의 법칙
- 자기방어
- 후행공정 작업준비 미흡
- 학생 중후군
⦿ 구성
- 프로젝트 버퍼 : Critical Chain 끝 (안전:사용가능, 모니터링:사용추이, 행동:버퍼통제)
- 피딩 버퍼 : non-critical chain 끝
- 자원 퍼버 : 경보장치

19

프로젝트 위험관리

⦿ 위험의 정의 : 프로젝트 전체 기간 중 발생하여 프로젝트의 정상적인 납기, 품질, 원가에 영향을 줄 수 있는 사건으로써, 프로젝트 수행 중에 반드시 식별되고 관리/해결해야 할 프로젝트 관리요소
⦿ 총 위험
- 위험 * 취약성 * 자산가치
⦿ 위험관리의 정의
- 기회는 극대화하고 위험은 최소화하여 프로젝트의 성공 가능성을 높이는 일련의 활동
⦿ 위험관리의 목적
- 성공 가능성 향상, 위험 요소 관리 및 제거, 위험 요소 사전 감지 제거
⦿ 원칙 (일개형)
- 일관성 : 관점 및 관리방법 일치
- 개별성 : 차별화된 접근법
- 형평성 : 감독 방법/비율 표준화

20

프로젝트 위험요소 (Bohem 분류)

(관설기환)
- 관리요인 : 일정부족, 비현실적 일정/예산, 과대포장, 지속적 요구사항 변경
- 설계오류 : 잘못된 SW 기능개발, 잘못된 사용자 I/F 개발
- 기술문제 : 실시간 성능문제, 기술취약
- 환경요인 : 외부작업의 부족, 외부기능의 부족

21

위험분할체계 (RBS : Risk Breakdown System)

- 기술 위험 : 신기술, 외부연계, 성능, 신뢰성
- 프로젝트 관리 위험 : 미숙한 계획, 통제 불가능, 의사소통 장애
- 조직 위험 : 의존도, 자원제약, 자금 지원, 우선순위
- 외부 위험 : 외주 계약, 관련법규, 시장상황, 고객 요구, 기후

22

위험관리 프로세스

1. 위험관리 계획 : 위험 관리 계획서
2. 위험 식별 : Risk Register
- 기법 : 델파이, 체크리스트
3. 정성적 위험 분석 : 영향도
- 기법 : 위험 영향도/발생가능성, 프로젝트 가정 테스트, 데이터 정확도 순위화
4. 정량적 위험 분석 : 관리계획서
- 민감도 분석, 의사결정 분석, 몬테카를로 시뮬레이션, EMV
5. 위험 대응 계획 : 관리계획서
- 기법 : 회피, 전가, 완화, 수용
6. 위험 감지 및 통제 : 조치문서

23

위험 대응 방법

(회전완 강공수)
1) 부정적 위험
- 회피
- 전가
- 완화
2) 긍정적 위험
- 공유
- 강화
3) 모든 유효 전략
- 수용

24

EMV (Expected Monetary Value)

⦿ 정의 : 위험이 발생할 수 있는 기능성에 대해서 확률과 영향도를 분석하여 가장 이득이 많이 나오는 가능성에 대하여 투자를 하도록 유도하는 기법
⦿ 계산식
- 위험 사건 현황(Risk Event Status)
= 위험확률 x 발생된 영향의 정도
- 금전전 기대값

25

동기부여이론

⦿ 정의 : 팀원들이 목표를 향한 자발적인 행동을 끌어내고 지속시키는 요인과 과정에 대한 이론
⦿ 종류
1) Content theory
- 매슬로 이론
- 엘더퍼의 ERG 이론
- 허츠버그 이론
- 맥클러랜드의 3욕구 이론
- 맥그리거의 X,Y이론
2) Process theory
- 기대 이론
- 공정성 이론

26

매슬로 이론

(자존사안생)
- 자아실현 : 재능, 잠재력 발현
- 자기존중 : 능력, 지위, 명성,
- 애정소속 : 집단의 일원
- 안전 : 개인환경의 확실성 보장
- 생리 : 의식주에서 보호

27

엘더퍼 ERG

(존관성)
- 존재(Existence)욕구 : 생리, 안정
- 관계(Relatedness)욕구
- 성장(Growth)욕구

28

허츠버그 이론

(위동)
⦿ 위생요인(불만을 발생시키는 요인, 만족을 유발시키지는 못함)
- 급여, 기술적 감독, 회사의 정책과 행정, 인간관계, 작업 조건, 개인생활 요소들, 직위, 직장의 안정성
⦿ 동기요인(만족을 유발시키는 요인, 불만을 유발시키지는 않음)
- 성취감, 칭찬이나 인정을 받을 수 있는 기회, 직무 자체가 주는 흥미, 성장 가능성, 책임감, 직무의 도전성, 발전성(승진)

29

맥클러랜드의 3욕구 이론

(성권친)
⦿ 성취욕구
⦿ 권력욕구
⦿ 친화욕구

30

맥그리거의 X이론 Y의론

⦿ X 이론 : 일 피함, 벌 주거나, 위협, 지시 받아야 일함, 책임 회피, 안위를 중요하게 생각
⦿ Y 이론 : 일 즐김, 자기 통제, 자기 방향성 수립, 책임감 추구

31

기대이론

⦿ 정의 : 노력을 해서 성과가 나올수록, 개인의 업무성과가 보상으로 이어질수록, 그리고 그 보상이 개인을 만족시킬때 동기부여가 된다는 이론
⦿ 구성요소 (노성기)
- 노력
- 성과
- 기대
⦿ F = E x V
- F = 동기부여의 강도
- E = 기대
- V = 결과의 유용성

32

공정성 이론

⦿ 개념 : 다른 사람의 input 대비 output, 그리고 본인의 input 대비 output을 비교해서 불공정을 느낀다면 공정한 상태로 만들기 위한 노력을 한다는 이론
⦿ 종류
- 배분의 공정성
- 과정적 공정성
- 관계적 공정성

33

팀발달 5단계

(형격규성해)
- 형성기 (Forming) : 업무소개, 할당
- 격동기 (Storming) : 동기부여, 독려, 업무조정
- 규범기 (Norming) : 팀 규범 확립, 적극적 지지
- 성과기 (Performing) : 과업 촉진, 자율 부여, 권한 위임
- 해산기 (Adjouring) : 행정적 마감, 사례 지식화

34

갈등관리 기법

(강문철회양수타)
⦿ 강요(Forcing)
- win-lose
- 불신조장 가능
⦿ 문제해결(Problem Solving)
- win-win
- 가장 모범적인 해결
⦿ 철수/회피(Withdrawal)
- lose-lose
- 일시적 진정 효과
- 재발 및 증폭 가능
⦿ 양보/수용(Smoothing)
- lose-win
- 더 큰 갈등유발 가능
⦿ 타협(Compromising)
- 일정 수준의 상호만족

35

이해관계자관리

⦿ 정의 : 프로젝트의 의사결정과 활동들에 효과적으로 참여시키기 위한 관리 전략을 개발하는 지식영역
⦿ 단계별 세부 내용
1) 이해관계자 식별
- 입력 : 차터, 프로세스, 자산
- 도구 : 전문가 판단, 프로파일분석
- 산출 : 이해관계자 등록부
2) 이해관계자 참여 계획 수립
- 입력 : 계획서, 등록지, 자산
- 도구 : 전문가판단, 회의
- 산출 : 관리계획서, 프로젝트문서
3) 이해관계자 참여 관리
- 입력 : 의사소통계획, 변경로그
- 도구 : 의사소통/대인관계 기술
- 산출 : 이슈로그, 변경요청
4) 이해관계자 참여 통제
- 입력 : 이슈로그, 작업성과
- 도구 : 시스템, 전문가, 회의
- 산출 : 작업성과보고, 변경요청, 업데이트된 프로젝트 문서

36

이해관계자 분석

1) 높은 권력, 높은 관심
- 프로젝트 성공에 큰 관련 있음
- 최대한 정보 공유, 의사결정 참여 시키는 전략
2) 높은 권력, 낮은 관심
- 이해관계 적으나, 영향력 행사
- 중요정보 중심 제공, 집중관리로 후원자로 만다는 전략
3) 낮은 권력, 높은 관심
- 영향력 적으나 이해관계가 큼
- 수시로 정보 제공, 프로젝트 참여 유도
4) 낮은 권력, 낮은 관심
- 프로젝트에서 역할을 수행하고 있다면 수시로 관찰

37

현저성 (Sailence Model)

⦿ 이해관계자 관리의 정의
- 프로젝트의 의사결정과 실행에 영향력 있는 이해관계자에 대한 적절한 관리를 포함한 프로세스
⦿ 이해관계자 관리를 위한 절차 (식계관통)
- 이해관계자 식별 : 관리대장
- 이해관계자 관리 계획 : 관리계획
- 이해관계자 참여 관리 : 이슈로그, 변경 요청
- 이해관계자 참여 통제 : 모니터링, 변경요청
⦿ 구성도 (권합긴)
- 권한 (Power)
- 합법 (Legitimate)
- 긴급 (Urgency)
⦿ 구성요소 (완우위 의휴자요)
7. 완전한
4. 우세한
5. 위험한
6. 의존적
1. 휴지의
2. 자유재량
3. 요구하는

38

PMO (Project Management Office)

⦿ 정의 : 프로젝트의 자원, 일정, 진도, 이슈관리 등을 효율적으로 수행하기 위해 만들어진 프로젝트 관리 전담조직
⦿ 등장배경
- 프로젝트 장기화
- 대규모 인력 및 예산
- 다양한 이해 관계자
- 업무 프로세스 변화 및 신기술
⦿ 목적
- 체계적인 관리
- 위험최소화 및 품질향상
- 중재
⦿ 주요 모델
1) PMO Type (조직위치)
- Internal : 내부 조직 구성
- External : 외부 조직 구성
- Combined : 혼합 구성
2) PMO Position (투여시간)
- Part-time
- Full-time
- Director
- President
3) PMO Skill
- 컨설팅, 프로젝트 평가/개선
- 개발방법론, 품질 프로세스
- 규정적용, 의사소통
- 보고, 조정자 역할
- PM, QM, Developer, Biz 관리
4) PMO R&R
- Weather Station
- Coach
- Control Tower
⦿ 도입절차
- 도입계획 수립
- PMO 가동 준비
- PMO 운영
- PMO 지속적 개선

39

조달관리

⦿ 정의 : 제품, 서비스등을 구매 계약 및 변경 통제, 계약 종료까지의 일련의 프로세스 관리
⦿ 단계 및 활동
- 제안 요청서 작성 : 주관기관
- 입찰 공고 : 전담기관, 주관기관
- 제안서 평가 : 주관기관
- 협상 : 주관기관
- 계약 : 전담, 주관, 사업자
- 사업수행 계획 수립 : 사업자
- 실행 및 통제 : 사업자
- 검토 및 평가 : 주관기관, 사업자
- 납품 및 평가 : 주관기관, 사업자
⦿ 구성요소
- Make or Buy Decision
- 계약 업무 범위서
- RFI
- RFP
- 계약관리
- 인수확인

40

계약유형

1) 고정가격 계약(FP, Fixed Price, Lumpsum)
- 업무범위 명확
- 공급자 측에서 계약관리 노력
- 유형 : FPIF
2) 비용보상 계약(CR, Cost Reimbursement)
- 실비정산, 보상계약, 범위불명확
- 수요자 측에서 계약관리 노력
- 유형 : CPFF, CPPC, CPIF

41

CPFF (Cost Plus Fixed Fee)

- Buyer가 모든 원가를 부담
- Fee는 고정 금액
- Seller의 원가를 적정한 선에서 유지시킴
- Cost + Fee($1000,000)

42

CPPC (Cost Plus Percentage of Costs)

- Buyer가 모든 원가와 일정 비율의 Fee를 부담
- Seller는 원가관리 필요성을 못느낌
- Cost + 10% of Cost

43

CPIF (Cost Plus Incentive Fee)

- 모든 Cost + 약정된 Fee + Bonus
- Cost + $100,000(Fee) + 조기완료시 $10,000 추가

44

FPIF (Fixed Price Incentive Fee

- 확정금액에 Incentive를 추가함
- $1,100,000(확정금액) + 조기 완료시 $10,000추가

45

T&M (Time and Material)

- 단가기준, 소규모 금액의 경우 사용
- 시간당 또는 품목별로 가격설정
- 시간단 $100 + 자재비

46

Purchase Order

- 쌍방계약이 아닌 일방계약
- 단순한 일용품 구매에 사용
- 미터당 $9로 30미터 목제를 구매하는 계약

47

공급자 성정 방법

(가사예공)
- 가중평가 시스템 : 사전에 정한 가중치
- 사전 필터링 시스템 : 공급자 최소 기준 제시
- 예정가격 선정 : 적정가격 도출 후 차이가 큰 업체 배제
- 공급자 평가 시스템 : 공급자 과거 수행 실적, 품질 평가

48

RFI (Request For Information) 작성사항

1. 사업개요
- 사업명, 추진 배경 및 목적, 사업범위, RFI 제출요령
2. 발주업체 정보
- 일반현황(사업목표/추진방향등)
- 정보시스템 현황, 개선사항 등
3. 주요 요구사항
- 세부 업무관련 요구사항
- 기술적 요구사항
- 관리능력

49

RFP (Request For Proposal) 작성사항

1. 사업개요
- 제안배경, 추진목적
2. 프로젝트 일정
- 제안서 제출 마감일정 및 발표일정, 업체선정 발표일, 개략적인 프로젝트 추진일정
3. 정보 요구내역
- 서비스 제공자명
- 조직 및 인력 구조
- 관련 분야 추진 내역
- 주요 보유 기술 내역
4. 기술적 환경 정의
- 현재 기술 현황(인프라)
- 시스템 아키텍처(현재 및 To-Be 모델)
5. 제안서관련 요구사항
- 제안 목차
- 공급업체의 핵심인력 및 참고자료
- 제안 형식 및 제출 부수
- 제안서 제출장소
- 질의 문의처 및 각종 기준 선정

50

제안서 작성내용

1. 요약
2. 제안의 목적과 내용
3. 회사 소개
4. 제안 시스템의 내용
5. 개발방법론과 관리 전략
6. 프로젝트 관리 방법론
7. 납품 후 추진전략
8. 프로젝트 조직에 대한 제안
9. 일정 계획
10. 가격 제안(밀봉)
11. 기타 제안 제반 요청 사항

51

기술제안서 평가항목 및 배점한도

⦿ 개발계획부문 (30)
- 유사분야에서의 개발경험, 전략
- 개발 대상 사업의 이해도
⦿ 개발부문 (30)
- 기능 및 성능, 개발환경, 개발 방법론
⦿ 관리부문 (20)
- 경영상태, 품질보증방안, 일정계획, 사업수행조직, 관리방법론
⦿ 지원부문 (5)
- 시험운영, 유지보수 방안, 비상대책, 교육훈련, 기밀보안
⦿ 전문업체 참여 및 상호협력 부문
- 전문업체 참여, 상호협력 (10)
- 중소기업 보호 육성 (5)

52

패키지 S/W 평가항목 및 배점한도

⦿ S/W 기능부문 (30)
- 기능성, 사용성
⦿ S/W 관리부문 (30)
- 이식성, 유지보수성
⦿ S/W 성능부문 (25)
- 효율성, 신뢰성
⦿ 공급자 지원부문 (15)
- 교육훈력, 업체 신뢰성, 운용지원

53

입찰가격의 평점 산식

⦿ 기술 능력 평가 (80)
- 기술/지식능력
- 인력 조직관리 기술
- 사업 수행 계획
- 지원 기술, 사후 관리
- 수행실적
- 재무구조, 경영상태
- 상호협력

54

제품품질 종합

⦿ 제품 품질 평가
- ISO 9126 (품질특성과 척도)
- ISO 14598 (소프트웨어 제품평가)
- ISO 12119 (SW패키지 품질요구/시험)
- ISO 25000 SQuaRE (품질측정과 평가)
⦿ 프로세스 품질 평가
- ISO 9000 시리즈
- ISO 12207 (SDLC)
- CMMI
- SPICE
⦿ 경영측면 품질 평가
- 6-Sigma
⦿ Peer Review
- Inspection
- Review
- Walkthrough
- Audit

55

ISO 9126

⦿ 정의 : 소프트웨어 제품 품질을 내/외부적, 사용관점에서 측정하기 위한 품질특성과 품질평가의 Metric을 정의한 국제표준
⦿ 구성요소
- 9126-1 : 품질특성 6개, 부특성 21개
- 9126-2 : 외부 Metric, 최종제품, 사용자 및 관리자
- 9126-3 : 내부 Metric, 개발단계, 개발자
- 9126-4 : 사용 중 품질, 효율성, 생산성, 안전성, 만족성

56

ISO 9126 품질 특성 및 부특성

⦿ 기능성 (적정상유보)
- 적합성
- 정확성
- 상호호환성
- 유연성
- 보안성
⦿ 신뢰성 (성오회)
- 성숙성
- 오류허용성
- 회복성
⦿ 사용성 (이습운)
- 이해성
- 습득성
- 운용성
⦿ 효율성 (실자)
- 실행효율성
- 자원효율성
⦿ 유지보수성 (해변안시)
- 해석성
- 변경성
- 안정성
- 시험성
⦿ 이식성 (환이일치)
- 환경적응성
- 이식성
- 일치성
- 치환성

57

ISO 14598

⦿ 정의 : 소프트웨어 제품평가에 대한 국제적인 표준으로 ISO 9126의 사용을 위한 절차와 기본 상황 및 소프트웨어 평가 프로세스에 대한 표준을 규정한 국제표준
⦿ 도입배경 : 신뢰성 확보, 동기부여, 제품 선택 기준
⦿ 특징 (반재공객)
- 반복성 : 동일 평가자/동일 사양
- 재생산성 : 다른 평가자/동일 사양
- 공평성 : 임의유도 금지, 편향금지
- 객관성 : 가정이나 사건에 독립
⦿ 구성 (개관구평모)
1) 14598-1 : 개요
- 14598 시리즈 전체와 9126 품질 모델과 관계 설명
2) 14598-2 : 계획 및 관리
- 제품 품질 측정 계획, 평가, 관리 계획 수립
3) 14598-3 : 개발자 프로세스
4) 14598-4 : 구매자 프로세스
5) 14598-5 : 평가자 프로세스
6) 14598-6 : 평가 모듈 및 문서화

58

ISO 14598-6 평가모듈

- EM0 개요 : 서론 및 소개
- EM1 범위 : 품질특성, 평가레벨, 기술, 적용성
- EM2 참조규격 : 관련규격
- EM3 용어 및 정의 : 용어정의
- EM4 입력요소와 메트릭스 : 입력요소정의, 데이터요소, 메트릭스 정의
- EM5 결과 해석 : 결과판정, 결과보고서
- EMA 적용절차 : 소요자원, 평가지침

59

ISO 12119

⦿ 정의 : SW 패키지에 대한 품질요구사항과 이를 시험하는 방법을 수립하고 있는 국제 표준
⦿ 평가대상
- 인도된 상태의 SW 패키지만 대상 (생산공정, 중간산출물, 공급사의 품질시스템은 규격범위에서 제외)
⦿ 구성
- 제품설명서 : 식별과 지시, 기능성, 신뢰성, 사용성, 효율성
- 사용자문서 : 완전성, 정확성, 일관성, 이해성, 개괄용이성
- 프로그램과 데이터 : ISO9126
⦿ 평가절차 (제사프기보추)
- 제품설명서 시험
- 사용자 문서 시험
- 프로그램과 데이터
- 테스트 기록
- 테스트 보고서
- 추후테스트(필요시)

60

기능안전성 표준화

▣ 개념
- 위험을 제거하기 위한 목적으로 시스템이나 장비가 적극적으로 동작하도록 하여 확보하는 안전성
▣ 동향
- IEC 61508 : 전기, 전자 및 프로그램 가능한 전자 안전 관련 시스템의 기능안전성 표준
- IEC 62304 : 의료 장비 소프트웨어와 생명주기 프로세스에 대한 표준
- DO-178B : 항공분야 SW 기능안전성 표준
- ISO 26262 : 자동차 분야 기능 안전성 표준

61

ISO 26262

▣ 정의
- 자동차의 안전을 확보하기 위한 전기전자부품 및 시스템 개발절차에 대한 국제 규격
▣ 등장배경
1) 기능안전의 등장
- 전자제어시스템(ECU) 역할 증대
- 네트워크로 연결/상호작용
- 첨단운전자시스템
2) ISO 61508 한계 보완
- 공급자 중심의 제품안전성
- 전기전자 장치 안전에 관한 포괄적 규격
▣ 주요내용
- 자동차에 특화된 Lifecycle 반영 (초기, 생산, 폐기에 걸친 안전 관련 요구사항)
- 소비자 관점의 안전성 중점
(재난노출가능성, 차량 통제 가능성 등 고려)
- 자동차에 적합한 위해도 평가지표 (SIL 보완 -> ASIL 등급)
▣ 구성요소
1) 용어
2) 기능 안전성 관리
- 개별활동 계획, 조정, 추적하는 요건 정의
- 전반적인 안전성 관리 요구사항 정의
3) 구상 단계
- 해저드 분석, 위험심사, ASIL 판정
- 안전 목표와 메커니즘 정의
4) 제품 개발 : 시스템 레벨
- 안전 메커니즘 확인, 사람의 통제성 및 작동작업에 대한 전체 검증
5) 제품 개발 : HW 레벨
- V모델 개념에 따른 HW의 개발, 통합, 검증 등에 대한 요구사항 정의
6) 제품 개발 : SW 레벨
- V모델 개념에 따른 SW의 개발, 통합, 검증 등에 대한 요구사항 정의
7) 생산 및 운용
- 계획, 샘플생산, 양산, 서비스 요구사항 정의
8) 지원 프로세스
- 안전 요구사항 관리, 명세 방법, 형상/변경관리, 검증, 문서화, 지원도구 자격 검증, 재사용 SW 자격검증, HW 자격검증, 실제 사용을 통해 입증된 안전성 등에 대한 요구사항 정의
9) ASIL 및 안전 중심의 분석
- 안전 관련 구성요소 사이 공존의 조건인 상호간섭의 정도, 위험분석 방법 기술
10) 가이드라인
- 주요 개념, 안전케이스, ASIL 분해 등 정보 기술
▣ ASIL 등급
- 4단계의 등급 결정, A 부터 가장 엄격한 D까지의 4단계 분류
▣ ASIL 결정 요소
- S(Severity) : 위험의 잠재적 심각도, S0 ~ S3
- E(Exposure) : 재난상황에 노출 가능성, E0 ~ E3
- C(Controllability) : 통제가능성, C0 ~ C3
▣ 재난 요인 별 심각도 분석
- S0 : 심각하지 않음
- S1 : 가벼운
- S2 : 위협적(생존 가능)
- S3 : 위협적(생존 불확실)
▣ 재난 요인 별 노출 가능성 분석
- E0 : 거의 없는
- E1 : 매우 낮은 확률
- E2 : 낮은 확률
- E3 : 중간 확률
- E4 : 높은 확률
▣ 재난 요인 별 통제 가능성 분석
- C0 : 일반적 통제
- C1 : 간단히 통제
- C2 : 정상적 통제
- C3 : 어려운 통제
▣ ISO 26262의 SW 정적분석의 내용
- Walk-through : ++, +
- Inspection : , +, ++, ++, ++
- SemiFormal Verification : +, +, ++, ++
- Formal Verification : +, +
- Control flow analysis : +, +, ++, ++
- Data flow analysis : +, +, ++, ++
- Static code analysis : +, ++, ++, ++
- Semantic code analysis : +, +, +, +
▣ 단위 테스팅 기법
1) SW Unit testing
- Requirements-based test
- Interface test
- Fault Injection test
- Resource usage test
- Back to back comparison test
2) For deriving test
- Analysis of requirements
- Generation and analysis of equivalence classes
- Analysis of boundary values
- Error guessing
3) Structural Coverage metrics
- Statement coverage
- Branch coverage
- MC/DC

62

ISO/IEC 25000 (SQuaRE)

▣ 정의
- 소프트웨어 개발공정 각 단계에서 산출되는 제품이 사용자 요구를 만족하는지를 검증하기 위해 품질 측정과 평가를 위한 모델 및 측정기법, 평가방안에 대한 국제 표준
▣ 특징
- SW 제품품질모델(ISO9126), SW 제품품질평가지침(ISO 14598), SW 패키지 제품품질 및 시험 (ISO12119)를 하나로 통합
▣ 구성
1) 품질 요구(Quality Requirement)
- ISO 15288 참조
- ISO 2503n
2) 품질 모형(Quality Model)
- ISO 9126-1에 해당
- ISO 2501n
3) 품질 관리(Quality Management)
- ISO 14598-2에 대응
- ISO 2500n
4) 품질 측정(Quality Measurement)
- ISO 9126-2,3,4에 대응
- ISO 2502n
5) 품질 평가(Quality Evaluation)
- ISO 14598 시리즈에 대응
- ISO 2054n

63

SW 품질평가의 3가지 영역

▣ 영역분류
- 제품품질 : SW 제품 자체
- 프로세스 : 개발관리, 프로세스
- 경영품질 : 경영시스템 평가
▣ 영역별 특징
1) 제품 품질
- SW자체, 패키지, SI, In-House
- 사용자 요구 충족
- 사용자, 개발자
- SDLC 중 개발공정
- ISO9126, ISO 14698, ISO12119, ISO25000, GS인증
2) 프로세스 품질
- SW SDLC
- SW 프로세스 개선
- 개발자, 운영자
- SDLC 전체
- ISO12207, ISO15504, CMMi
3) 경영시스템 품질
- 전사적 경영, 제품 ~ 고객
- 고객 만족
- 전 직원
- PDCA
- ISO9000시리즈, 6시그마

64

ISO 12207

▣ 정의
- 소프트웨어 생명주기 프로세스 표준
▣ 필요성
- 의사소통 : 방법론 남발 해소
- 기본요건 : What 정의
- 일반성 : 본질적 프로세스
▣ 구성요소
1) 기본 생명주기 프로세스
- 획득(=발주), 공급, 개발 V&V, 운영, 유지보수
2) 지원 생명주기 프로세스
- 문서화, 형상관리, 품질보증, 검증, 확인, 합동검토, 감사, 문제해결
3) 조직 생명주기 프로세스
- 관리, 기반구조, 개선, 훈련

65

SW 품질관리

▣ 정의
- 프로젝트에 주어진 요구사항을 충족시키는데 필요한 품질정책, 품질목표, 품질관련 책임사항들을 결정하는 회사 차원의 모든 활동
- 품질은 검사(Inspected) 되는 것이 아니라 계획(Planned)되고 설계(Designed)되며 내장(Built-in) 되는 것
▣ 이론
- 고객만족
- 실제 필요사항을 충족
- 사양에 맞는 제품을 생산
▣ 목적
- 기술지원 평가 : Baseline
- 자원 평가 : 비용
- 프로세스 평가 : SDLC
- 제품 평가 : 인수시험, 산출물
▣ 구성도
1) 품질 계획
- 프로젝트 요구사항이 무엇이고 무엇을 어떻게 달성할 것인가
- 품질 요구 사항 정의
- 품질 활동 프로세스 정의
2) 품질 보증
- 요구 사항 충족을 위해 필요한 프로세스 수행을 계획, 체계적 보증
- 프로세스 심사
- 프로세스 개선 활동
3) 품질 통제
- 요구사항 달성 여부 확인 및 조치
- 테스트 활동 수행 및 결함 수정
- 부적합 원인 분석

66

품질계획 프로세스

▣ 정의
- 프로젝트와 관련된 품질기준을 명시하고 이를 충족시키는 방법을 결정
▣ 입력물
- 범위 기준선
- 이해관계자 등록부
- 원가 성과 기준선
- 일정 기준선
- 리스크 등록부
- 기업 환경 요인
- 조직 프로세스 자산
▣ 도구/기법
- 원가-편익 분석
- 품질비용
- 관리도
- 벤치마킹
- 실험 설계법
- 통계적 표본 추출
- 흐름도
- 독점 품질 관리 및 방법론
- 추가 품질 기획 도구
- 브레인 스토밍
- 친화도
- 명목집단기법
- 흐름도
- 우선순위 매트릭스
▣ 산출물
- 품질 관리 계획서
- 품질 지표
- 품질 점검목록
- 프로세스 개선 계획서
- 프로젝트 문서 갱신
▣ 품질비용(Cost of Quality, COQ)
- 예방비용 : 교육훈련비용, 품질계획비용, 설계검토비용, 공정관리비용
- 평가비용 : 감리, 완제품 검사비용, ISO 획득비용
- 내부실패비용 : 폐기처분, 재작업, 재검사비용, 작업중단비용
- 외부실패비용 : 반품비용, 제품책임비용, 클레임처리비용, 보증수수료, 호감상실비용

67

품질보증 프로세스

▣ 정의
- 프로젝트가 관련 품질기준을 충족시킬 것 이라는 신뢰를 제공하기 위하여 정기적으로 프로젝트의 전반적 성과를 평가, 보증하는 활동
▣ 입력물
- 품질관리계획
- 품질 메트릭스
- 품질 체크리스트
- 프로세스 향상 계획
- 작업수행실적
- 수행된 변경요청/시정조치
- 결함수정/예방조치
- 승인된 변경요청
▣ 도구/기법
- 품질심사
- 프로세스분석
- 연관모델
- 품질계획수립
- 품질통제활동
▣ 산출물
- 변경요청
- 권고된 시정조치
- 변경된 프로젝트 관리 계획

68

품질통제 프로세스

▣ 정의
- 특정 프로젝트 결과가 관련 품질 기준을 준수하는지 감시하고 불만족스러운 성과의 원인을 제거하기 위한 방법 식별
▣ 입력물
- 품질관리계획
- 품질 메트릭스
- 품질 체크리스트
- 작업수행실적
- 승인된 변경요청
▣ 도구/기법
- 품질통제활동도구(QCT)
- 통계 샘플링
- 불량 검증
- 리뷰
▣ 산출물
- 품질통제측정치
- 변경된 품질 베이스라인
- 권고된 시정조치/Actions
- 예방조치/변경요청
- 조치된 불량검증
- 검증된 산출물

69

품질통제 도구

▣ 부적합 식별 및 수정
- 통제도(Control Chart)
- 검토(Inspection)
- 런차트(Run Chart)
- 결함수정검토(Defect Repair Review)
▣ 부적합 유형분류 및 우선순위 결정
- 히스토그램(Histogram)
- 파레토 차트(Pareto Chart)
- 특성요인도(Cause Effect Diagram)
▣ 원인분석
- 흐름도(Flowchart)
- 산점도(Scatter Diagram)
▣ 기타
- 통계적 표본 추출(Statistical Sampling)

70

통제도(Control Chart)

▣ 개념
- 프로세스의 안정성 여부 혹은 예측가능성을 판단하기 위한 도구
- Random cause와 Special cause의 개념을 활용하여 이상요인이 발생했는지 탐지하거나 제품에 대한 합격/불합격을 판정
▣ 구성
- Upper Spec Limit
- Upper Control Limit
- In-Control
- Lower Control Limit
- Lower Spec Limit
- Out of Control
▣ 구성요소
- In-Control : random variation은 발생하지만, 통제할 수 있는 special variation은 없는 상태 (special variation 은 원인을 규명해야 함)
- Out of Control : 결과가 상한선(UCL)이나 하한선(LCL)을 벗어나는 경우
- 7 Rule : 7개 이상의 연속되는 포인트가 특정패턴을 보이는 경우(한 방향 계속 증가/계속 감소, 평균을 중심으로 한 부분에만 위치)
- Hugging : 평균을 중심으로 어느 한 부분에 2/3 이상이 몰려있는 경우

71

인과관계도 (Cause-Effect Diagram, Ishikawa, Fishbone)

▣ 개념
- 핵심문제 또는 효과에 얼마나 다양한 원인들이 연관되어 있는지를 체계적으로 보여줌 (어떤 결과의 원인이 체계적으로 정리되어 현상에 대한 시각적인 이해를 도와줌)

72

파레토 차트(Pareto Chart)

▣ 개념
- 80:20 법칙
- 80%의 결함은 20%의 프로그램에서 발생 또는 80%의 기능은 20%의 프로그램이 담당
- 수정 작업시 가장 많은 결함을 일으키는 원인을 제일 먼저 수정
- 제한된 자원으로 최대의 효과를 얻으려고 할 때 활용

73

런 차트(Run Chart)

▣ 개념
- 변이의 기록과 패턴을 보여주는 도표
- 시간 경과에 따른 프로세스 추세 및 변이, 프로세스의 수준 하강 또는 상승을 보여줌
- 기술적 성과, 원가 및 일정성과의 감시에 이용

74

산점도(Scatter Diagram)

▣ 개념
- 두 변수(예 : 사람키와 몸무게)사이 관계 패턴을 가지고 존재할 수 있는 관계를 연구
- 종속변수와 독립변수 함수로 작도되며 점들이 대각선에 가까울수록 더 밀접하게 관련

75

히스토그램(Histogram)

▣ 개념
- 변수의 분포를 보여주는 막대 차트
- 각 막대가 문제/상황의 한 가지 속성이나 특성을 표시하고, 각 막대의 높이는 해당특성의 상대적 빈도를 나타냄
- 분포의 형태나 너비를 통해 프로세스의 문제 원인 식별 가능

76

통계적 표본추출(Statistical Sampling)

▣ 개념
- 적절한 표본추출로 품질관리 원가가 절감되는 경우가 있음
- 일부 응용분야에서는 프로젝트 관리팀이 다양한 표본추출 기법을 숙지해야 할 수 있음

77

검사, 검토, 워크스루, 동료검토

▣ 개념
- 작업제품을 점검하여 표준에 부합성 여부를 판별하는 활동

78

소프트웨어 안전성(Safety)확보를 위한 국제 표준 규격

▣ 개념
- ISO/IEC Guide51에서 제시하는 가이드라인에 따라 기본안전규격, 그룹안전규격, 제품안전규격으로 계층화 하여 구분
▣ 계층구분
1) 기본안전 규격(A규격)
- 광범위한 제품, 프로세스, 서비스 안전규격
- 안전 관련 제품규격 및 이를 준수하기 위한 규정에 대한 가이드라인 제공
- 일반설계 원칙 : ISO 12100
- 위험평가 원리 : ISO 14121
2) 그룹안전 규격(B규격)
- 유사 그룹군에 대한 제품, 프로세스, 서비스 안전규격으로 C규격에 비해 광범위
- 시스템 안전규격 : ISO 13849
- 기능 안전규격 : ISO 61508
3) 제품안전 규격(C규격)
- 특정 제품군에 대한 제품, 프로세스, 서비스의 안전 규격
- ISO 26262, IEC 62304, DO-178B
▣ 안전성 평가기법
1) 위험과 운영 가능성 분석
- 요구사항 명세 단계 안전성 분석
- R&R명확화 및 체계적 절차 제공
- 명세요원, 설계요원, 검증요원, 분석요원, 기록요원
2) FMEA
- SW제품이나 공정의 잠재적 오류를 발견하고 예방하기 위한 체계적 접근 기법
- 장애 발생확률, 심각도, 파급도에 따라 Risk Priority Number(RPN) 부여하고 장애 대응 방안을 수립하고 개선하는 사전적 예방조치 이자 소프트웨어 안전성 평가 기법
- 설계 FMEA, 공정 FMEA
3) 결함수 분석(Fault Tree Analysis)
- 시스템 오류 원인들 간의 관계를 논리게이트를 이용한 트리로 구성하여 확률적으로 분석하여 안전성을 진단하는 기법
- 정량적 결함분석 기법
4) V-모델 평가
- 기능안전 평가 대상에 따라 Type을 구분하고 공급망의 단계별 활동에 따라 평가를 수행하는 기법
- Type에 따라 조직의 기능안전 관리 능력, 안전 요구사항 수준, 운영, 유지보수 프로세스, 통합시스템 및 서브 컴포넌트, 독립 컴포넌트가 평가 대상

79

CMMI (Capability Maturity Model Integration)

▣ 정의
- 시스템과 소프트웨어 개발에 대한 능력 및 성숙도에 대한 평가와 프로세스 개선 활동에 광범위한 적용성을 제공하는 지속적인 품질 개선 모델
▣ 구성요소
1) 프로세스 영역(Process Area)
- 성숙단계 2~5 중 하나에 포함
2) 목적(Goal)
- 활동들의 특징
- 특정목적(Specific Goal)
- 일반목적(Generic Goal)
3) 활동(Practice)
- 구체적인 활동
- 특정활동(Specific Practice)
- 일반활동(Generic Practice)
4) 공동 수행항목(Common Feature) (서능구검)
- 실행서약(Commitment to Perform, CO)
- 실행능력(Ability to Perform, AB)
- 지정된 구현(Directing Implementation, DI)
- 구현검증(Verifying Implementation, VE)
▣ 단계별 표현(Staged Representation)
1) 개념
- 여러 프로세스 영역 중 조직의 필요성에 따라 특정영역을 선택하고 적용하여 평가 후 나머지 영역에 대하여 추가 적용하여 전체평가
2) 레벨
- Level 5 : Optimized, 최적화 (지속적인 프로세스 개선)
- Level 4 : Quantitatively Managed, 정량적 관리
- Level 3 : Defined, 정의 (프로세스 표준화)
- Level 2 : Managed, 관리 (기본적인 프로젝트 관리)
- Level 1 : Initial, 실행
▣ 연속적 표현 (Continuous Representation)
1) 개념
- 전체영역을 적용하여 평가 받으며 영역별 수준을 조직의 성숙수준으로 적용하여 프로세스 영역을 4개의 범주로 그룹화하여 사용
2) 레벨
- Level 0 : Incomplete, 불수행
- Level 1 : Performed, 수행
- Level 2 : Managed, 관리
- Level 3 : Defined, 정의
- Level 4 : Quatitatively Managed, 정량적 관리
- Level 5 : Optimized, 최적화

80

CMMI PA(Process Area)

▣ 구분
- Process Management
- Project Management
- Engineering
- Support
▣ Level5 (조문)
[Process]
- 조직 성과 관리
[Support]
- 문제 원인 분석 및 해결
▣ Level4 (프정)
[Process]
- 프로세스 능력 관리
[Project]
- 정량적 프로젝트 관리
▣ Level3 (개정훈 통위 요기제검확 대)
[Process]
- 조직 프로세스 개선
- 조직 프로세스 정의
- 전사 교육 훈련
[Project]
- 통합 프로젝트 관리
- 위험관리
[Engineering]
- 요구사항 개발
- 기술적 솔루션 개발
- 제품 통합 및 구현
- 검증
- 확인
[Support]
- 대안 분석 및 해결
▣ Level2 (요계모공 측제형)
[Project]
- 요구사항관리
- 프로젝트계획수립
- 프로젝트 모니터링 및 통제
- 공급업체 계약관리
[Support]
- 측정 및 분석
- 제품 및 프로세스 품질보증
- 형상관리

81

PSP/TSP(Personal Software Process/Team Software Process)

▣ PSP
- 개발자들이 자신의 개발능력을 파악하여 자신에게 맞는 개발방법을 찾을 수 있도록 지원하는 방법론
▣ TSP
- PSP로 훈련된 3-15명의 소프트웨어 공학팀을 위한 프로세스로서 소프트웨어 개발, 개선 및 수정을 위하여 독립적인 지휘능력을 갖춘 팀이 통계적 프로세스제어를 행하는 Level5프로세스
▣ PSP 학습절차
1) PSP 0 (기준프로세스)
- Exercise 1,2,3
- 자신의 개발능력, 결함 처리 능력 확인
- 프로그램 작성시간, 결함 수, 코드 량을 이용
2) PSP 1 (개인계획프로세스)
- Exercise 4,5,6
- 기준 프로세스를 이용한 개발 계획 수립
- 작업과 일정계획 수립
3) PSP 2 (개인품질관리)
- Exercise 7,8,9
- 코딩, 테스트 이전의 Review 수행
- 초기 단계에서 결함을 수정 할 수록 효율적
4) PSP 3 (반복프로세스)
- Exercise 10
- 큰 사이즈의 프로그램을 작은 사이즈로 분할하여 반복적으로 설계, 코딩, 테스트 수행
- 개인적으로 시스템을 만들어 가는 방법 이해
▣ TSP의 목표
- 소프트웨어 개발팀에 동기를 부여하여 효과적으로 소프트웨어 개발팀을 구성하고 유지하는 훈련방법 제공
▣ TSP 팀 구성원의 선결조건
- 구성원이 PSP를 통해 계획수립, 측정, 추적기술, 프로세스, 품질, 헌신의 중요성 획득
- 시간기록일지, 결함기록일지 등 로그기록

82

ISO 15504 (SPICE)

▣ 개념
- SW 프로세스에 대한 개선 및 능력 평가의 기준이 되는 SW 프로세스 모델
▣ 목적
- 프로세스 개선을 위해 개발기관 스스로 평가
- 기관의 요구조건 만족도를 개발조직 스스로 평가
- 계약을 맺기 위하여 수탁 기관의 프로세스 평가
▣ 특징
- 각 프로세스 영역별 능력 평가를 별도로 할 수 있는 2차원 모델
- CMM과 같이 프로세스 평가를 위한 참조 모형 제공 (개발 성숙도 판단)
- 무능력 상태부터 최적화 상태까지 6단계 능력 평가
▣ 수행단계
- 5 : 최적화 (지속적인 개선)
- 4 : 예측 (정량적 이해 및 통계)
- 3 : 확립 (표준 프로세스 사용)
- 2 : 관리 (수행 계획 및 관리)
- 1 : 수행 (수행 및 목적 달성)
- 0 : 불완전 (미구현, 미달성)
▣ 2차원 평가모델 차원
1) 프로세스 수행능력 차원
- ISO 12207(SDLC) 기반
2) 프로세스 차원
- 달성 목표
- 0 ~ 5 까지의 Capability Level
▣ 프로세스 차원의 5개 범주 (고공지관조)
1) 기본 프로세스
- 고객-공급자 : 인수, 공급, 요구도출, 운영
- 공학 : 시스템과 소프트웨어 개발, 유지보수
2) 지원 프로세스
- 지원 : 문서화, 형상, 품질보증, 검증/확인, 리뷰, 감사, 문제해결
3) 조직 프로세스
- 관리 : 프로젝트 관리, 품질관리, 위험관리
- 조직 : 조직배치, 개선활동, 인력관리, 측정도구, 재사용
▣ SPICE의 프로세스 Rating 방법
- N : Not Achieved (0~15%)
- P : Partially Achieved (16~50%)
- L : Largely Achieved (51~85%)
- F : Fully Achieved (86~100%)

83

Verification & Validation

▣ Verification (검증)
- 개발자 혹은 시험자의 시각으로 소프트웨어가 명시된 기능을 올바로 수행하는지 알아보는 과정
- 프로그램과 명세서의 일치정도 확인
- 개발자, 시험자 관점
- Review, Inspection
▣ Validation (확인)
- 사용자 시각으로 올바른 소프트웨어가 개발되었는지를 입증하는 과정
- 프로그램 명세서의 활용 가능성 판단
- 사용자 관점
- Unit Testing, Integration Testing, System Testing, Acceptance Testing

84

정형기법

▣ 정의
- 논리학이나 이산 수학을 이용하여 요구 사항 명세, 설계 및 구현 과정에서 사용하는 기법
▣ 구성
1) 정형명세
- 개발 대상 시스템에 대해 원하는 어떠한 수준의 레벨로도 명세 가능
- 시스템의 요구사항이 완전하게 정확하게 명시되었는지 검증
2) 정형개발
- 정형 명세를 통한 개발
3) 정형검증
- 만들어진 명세는 명세의 특성을 증명하는 기초가 됨
- 사람 주도적 증명 : 시스템의 정확성을 자연 언어로 수학적 증명을 함. 자연 언어의 태생적 모호함으로 인해 문제점을 검출하지 못할 수도 있으며, 좋은 증명은 높은 수학 지식과 전문 지식을 요함
- 자동화 증명 : 중요 State를 정의해 줄 수 있는 사람의 도움 필요. 검증한 것은 모두 수학적으로 증명된 것으로 정확도가 더 높다고 인지
▣ 정형명세 대수적 방법(Algebraic)
1) CSP (Communicating Sequential Process)
- 이벤트의 진행 순서와 상호작용에 초점을 맞추어 명세를 기록하는 방식
2) CCS (Calculus of Communication System)
- 특정 동기화 메카니즘을 통해 프로세스간 상호작용의 방법을 나타냄으로써 시스템을 명세하고 검증하는 프로세스 Algebra 언어
3) LOTOS (Language of Temporal Ordering Specification)
- CCS의 확장 개념
▣ 정형명세 모형기반 방법(Model Theoretic Structure)
1) Z
- 논리, 모델기반 명세 기법
- 모듈화와 재사용성은 우수하나 지식이 부족하면 이해하기 어려움
2) VDM(Vienna Development Mothod)
- 표현 의미론에 기초한 기법으로 명세이외에도 설계 구현에도 적용이 가능함
3) Petri-Net
- 시스템 내에서의 가능한 모든 상태와 한 상태에서 다른 상태를 이어주는 동작에 해당되는 전이를 통해 시스템을 표현
▣ 정형검증의 종류
1) Model Checking
- 자동 검증 기법
- 입력 : 모형, 속성 명세
- 방법 : 상태 공간의 철저한 탐색
- 출력 : 참 또는 반례
2) 정리증명(Theorem Proving)
- 수학적으로 참인 명제의 증명으로 검증하는 방법
- 논리 : 명제, 술어, 고차 논리
- 장점 : 일반화된 속성을 검증
- 단점 : 사용자 개입 요구
3) Equivalence checking
- FSM, BDD or SAT 중에 2가지를 선택하여 같은 행동의 결과를 비교하는 방법
4) SAT
- 불린 함수를 이용하여 기 정의한 함수의 결과가 성공이면 1 (satisfiable) 증명하지 못하면 unsatisfiable 상태를 유지하는 방법
▣ 모델 체킹 기법 적용 시 고려사항
- 상태폭발 : SW 상태 수가 HW 대비하여 매우 많음(지수적증가)
- 모델 구현의 어려움
- 요구 명세 적용의 어려움
- 검증 결과 해석의 모호성

85

정리증명(Theorem Proving)

▣ 사용기법
- 수학/논리학적 공리 (Axiom), 규칙을 활용하여 시스템명세/특성 도출
▣ 검증확인
- 시스템 명세와 특성의 논리학적 정합성
▣ 장점
- 무한상태기계도 명세 및 증명 가능
▣ 단점
- 시스템 명세 도출 및 증명이 매우 어려움
▣ 활용 예
- SPEAR II, PVS

86

모델 체킹(Model Checking)

▣ 사용기법
- 정형 명세 언어를 통한 시스템 명세(유한상태기계)
- 시스템 요구사항에 기반하여 시스템 특성 도출
▣ 검증확인
- 시스템 모델의 시스템 특성 만족 여부
▣ 장점
- 모델 증명 도구를 통한 자동화 가능
▣ 단점
- 유한상태기계만 명세 및 증명 가능
▣ 활용 예
- CMU's, SMV, Bell/s SPIN, Berkeley's VIS

87

SW 비용산정

▣ 측정기법에 따른 분류
- 유사산정 : 과거 유사 프로젝트
- 상향식 : 하위 Activity 노력 합산 (LOC)
- 하향식 : 전체 프로젝트 노력 추정 (델파이)
- 수학적 : 과거 실적/경험 (FP, COCOMO)
▣ 매트릭에 따른 분류
1) 양적 산정
- Doty : 인터뷰, 문헌바탕
- Putman : 프로젝트 생명주기 동안 노력 분포
- COCOMO : 63종류 프로젝트 기초 경험적 SW 비용 산출
2) 양적/질적
- FP (ISO 14143)
- Halstead의 SW과학
- McCabe의 회전복잡도
▣ SW 비용산정의 정의
- 소프트웨어 규모파악(양적인 크기, 질적인 수준)을 통한 소요공수와 투입자원 및 소요기간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정

88

Function Point

▣ 정의
- 정보처리규모의 기능적 복잡도에 의해 소프트웨어 규모를 사용자의 관점에서 측정하는 방식
▣ 등장배경
- 추정의 어려움 : LOC측정 어려움
- 환경의 영향 : 개발언어
- 파라미터의 영향 : CS, 웹 차이
- 사용자 관점 부재 : 기능과 양을 고려한 평가 과점 부재
- 개발환경의 변화 : 3GL -> 4GL, 자연어 처리, CBD, Package
▣ 특징
- 최종 사용자 입장에서 SW 규모를 견적
- 프로젝트 완료 후 생산성 평가를 위해 개발되었으나, 사전에 개발소요 공수를 예측하는 모델로 사용 가능
- 개발환경과 기술에 무관하게 측정가능하고, 사용자 요구에 따라 시스템 기능 설계 시 개발 중에도 측정 가능함
▣ 측정 절차
1. 측정 유형 결정
2. 측정 범위와 어플리케이션 경계 식별
3. 데이터 기능 측정
- DET, RET 식별 -> 복잡도 부여 -> 기능점수
4. 트랜잭션 기능 측정
- DET, FTR 식별 -> 복잡도 부여 -> 기능점수
5. 미조정 기능점수 결정
6. 조정 인자 결정
7. 조정 기능점수 결정
▣ 1. 측정 유형 결정
- 개발 프로젝트
- 개선 프로제트
- 어플리케이션
▣ 2. 측정범위와 어플리케이션 경계 식별
- 범위 결정 : 전체 범위
- 경계 분류 : ILF, ELF 구분
▣ 3. 데이터 기능 측정
1) 식별
- ILF(Internal Logical File) : 내부 DB
- EIF(External Interface File) : 외부 DB
2) 복잡도 계산
- DET(Data Element Type) : 필드, 속성
- RET(Record Element Type) : 엔티티 타입
▣ 4. 트랜잭션 기능 측정 (최소 업무 단위 프로세스)
1) 식별
- EI(External Input)
- EO(External Output)
- EQ(External Query)
▣ 5. 미조정 기능점수 결정
- 데이터기능점수와 트랜잭션 점수의 합
▣ 6. 조정인자 결정 (0~5 점 가중치 부여)
- 데이터 통신
- 분산 데이터 처리
- 성능
- 사용환경
- 처리율
- 온라인 데이터 입력
- 최종사용자 편리성
- 온라인 갱신
- 처리복잡성
- 재사용성
- 설치용이성
- 복수 사이트
- 변경 용이성
▣ 7. 조정 기능점수
- 조정인자 값이 결정되면 개발, 개선, 어플리케이션의 유형에 따라 조정인자를 반영하여 최종 FP 계산
- FP결과값 = 미조정기능점수 * 조정인자계산

89

COCOMO(Constructive Cost Model)

▣ 정의
- 소프트웨어 유형을 모듈별(Organic, Semi-Detached, Embedded)로 구분하고 각 유형에 대한 총 인월(man/month)수와 개발 기간을 계산하는 방식
▣ 특징
- 비용예측 : LOC
- 의존성 : Organic, Semi-Detached, Embedded
- 유연성 : 제품특성, 컴퓨터특성, 개발요원특성, 프로젝트성격 융통성
- 이용성 : 이해하기 쉬운 모델
▣ 모델의 유형
1) Basic
- LOC 추정, 고정 단일값 모형
2) Intermediate
- 제품속성, HW속성, 인적속성, 프로젝트 속성 고려
3) Detailed
- 모듈별, 서브시스템별로 비용 별도 산정하여 합산
▣ 프로젝트의 유형
1) Organic
- 50,000 소스라인 이하
- 비교적 소규모 개발팀
- 훌륭한 현장 경험 보유 개발팀
- 비교적 덜 업격한 명세
- 안정적인 개발환경
- 현존하며, 증명된 기술 사용
2) Semidetached
- 300,000 소스라인 이하
- 개발대상과 개발환경에 대하여 경험자와 비 경험자가 섞여있는 개발팀
- 업격한 명세와 덜 업격한 명세가 섞여 있음
- 중간 정도 수준의 일정에 대한 압박
3) Embedded
- 기능이나 성능등에 대한 업격한 명세
- 제품이 시간 제약사항내에서 수행되어야 함
- 정형적인 품질 표준 만족해야 함
- HW, SW, Managememt
- 선도적 기술 사용
- 강한 일정에 대한 제약

90

소프트웨어 매트릭스

▣ 정의
- 소프트웨어 측정 기술을 기반으로 SDLC 동안에 소프트웨어의 특성을 객관적인 수치로 정량화 할 수 있는 방법
▣ 개념 비교
- Measurement(측정) : 어떤현상, 특성, 결과를 숫자로 표현하는 활동 (검사하고 기록)
- Measure((중요성・가치・영향을) 판단[평가]하다) : 측정방법의 표준, 단위로 알고자 하는 개념을 대표하는 측정항목(FP, 본 수, 결함 수, 투입공수)
- Metrics : 두 개 이상의 측정항목(Measure)으로 계산된 복합적 지표
▣ 유형
1) Product metrics
- Size : LOC, FP
- Complexity : McCabe, Halsted
- Quality : 결함수, 신뢰성(MTBF), 가용성(MTTF/MTBF*100)
2) Process metrics
- Resource : Effort, People, Money
- Guidelines : Procedure, Goals, Rules, Constraints, Policies, Trainings
- Process : 요구분석, 설계, 코딩, 테스트, 변경관리, 인스팩션
- 사용율, 표준화 정도, 관리의 효율성, 개발시스템 성능
3) Resource metrics
- 컴퓨터자원, 훈련 및 교육, 인력
4) Project metrics
- 프로젝트 계획 수립
- 테스트 업무
- 형상관리 업무
- 개발방법론, SDLC, 산출물, 인력관리, 위험관리, 일정관리
▣ 단계별 활동 (공수분해피)
- 공식화 : Measure와 Metric 유도
- 수집 : 요구 데이터 수집
- 분석 : 척도 계산, 수학적 도구 적용
- 해석 : Metric 평가
- 피드백 : Metric 해석으로 부터 유도
▣ 품질관련 SW 매트릭스
1) 결함율
- 결함건수/프로그램규모
2) 품질목표
- 성능, 사용 편의성, 고객 요청 품질 목표
3) 프로세스 준수율
- 프로젝트 표준 및 프로세스 준수율
4) 고객만족도
- 프로젝트 진행 과정, 결과 만족도
- 각 항목별 평가 점수

91

McCabe 복잡도

▣ 테스트의 한계
- 프로그램의 입력 영역과 조건에 따른 경우의 수는 무한히 크기 때문에 현실적으로 모든 가능한 입력 값들을 테스트 할 수 없음
▣ 개념
- 제어 흐름에 의한 그래프를 통하여 사이클로매틱 회전 수를 구하여 복잡도를 계산하는 방법
▣ 프로그램 복잡도
- V(G) = e - n + 2
(e : edge의 수, n : node의 수)

92

Halstead

▣ 개념
- 연산자, 피연산자 종류 및 개수에 의해 프로그램 구현, 부피, Dificalty, Effort 등을 측정하는 소프트웨어 과학적 척도
▣ Primitive Measure Set
- n1 : 연산자의 종류
- n2 : 피 연산자의 종류
- N1 : 연산자의 총 발생 빈도수
- N2 : 피 연산사의 총 발생 민도수
▣ Measure 이용 공식
- Length : N = n1 log2 n1 + n2 log2 n2
- Volume : V = N log2(n1+n2)
- Level : L = 2/n1 * n2/N2
- Effort : E = V / L

93

신뢰성 및 가용성

▣ 개념
- MTBF(Mean Time Between Failure) : 장애 발생 후 수리되고 다시 장애가 발생할 때 까지의 시간
- MTTF(Mean Time To Failure) : 정상 운영 시간, 가동 시간
- MTTR(Mean Time to Repair) : 장애 난 후 정상 복구 하는데 소요되는 시간
▣ 공식
- 신뢰성 = MTTF + MTTR
- 가용성 = MTTF/(신뢰성) x 100