82
출제예상 번다운차트 [정의] Agile 프로젝트기반 조직에서 점수(Story Point)를 산정하여 Sprint 계획대비 현재진행을 파악할 수 있는 차트
스토리포인트(Story Point) 산정, Sprint 진척률 가시화
-----
Burn down(소멸차트) 상세설명
기울기를 통하여 작업수행 속도 판단
Story Point 산정 및 담당 업무할당에 너무 많은 시간이 소요되면 진척에 역효과 발생. 적절한 이해관계자 들간의 범위 및 일정조율 중요.		 Burn-dwon Chart, Burn-up Chart, 기능 차트
토픽 이름 번다운차트(Burn down)
분류 PM > Agile > 번다운차트
키워드(암기) 번업차트, 스토리포인트(Story Point), Sprint 진척률 가시화
암기법(해당경우) 번쓰 (번다운/스토리포인트/스프린트)

 

기출문제

번호 문제 회차
1 Burn-down chart와 EVM를 비교하시오. 합숙.2014.7.26.1교시.3
2 11. Burn down chart에 대하여 설명하시오. 모의.2011.01.1교시.11
3 Agile 프로세스가 국내에 많이 도입이 되고 있다. 프로젝트 관리자로서, 프로젝트마다 개별 개발방법론과 프로세스의 테일러링이 필요하다. 다음 질문에 대해 설명하시오.
가. SW의 획득가치기법인 EVM과 Burn Down Chart를 비교하시오.
나. 린 프로세스를 정의하고 7개 원칙에 대해 5가지 이상 설명하시오. 다. Kanban과 린 프로세스를 비교하시오.		 2016.01.27(수) 5일차
2교시 7번. 108회 대비
4 Burn-down chart와 EVM를 비교하시오. 2014.07.28(월) 3일차 1교시 3번. 104회 대비

 

I. Scrum의 Sprint 일정관리 도구, 번다운차트 개요.(서론)

- Agile 프로젝트기반 조직에서 점수(Story Point)를 산정하여 Sprint 계획대비 현재진행을 파악할 수 있는 차트

- 스토리포인트(Story Point) 산정, Sprint 진척률 가시화

 

II. 개념도(구성도) 및 기술요소

가. Burn down(소멸차트) 개념도

- 점수(User Point)를 지정하여 Sprint 기간에 계획대비 완료한 현재의 진행을 가시화

나. Burn down(소멸차트) 상세설명

구분 설명
가로축 시간 축으로 스프린트 반복 주기 날짜수
세로축 완료된 작업의 추정 일수(스토리 포인트로 표현)
계획 그래프 처음 계획을 세웠을 때 날짜로 남은 작업량 표현
실제 그래프 작업을 수행하면서 실제로 남은 작업량

- 기울기를 통하여 작업수행 속도 판단

- Story Point 산정 및 담당 업무할당에 너무 많은 시간이 소요되면 진척에 역효과 발생. 적절한 이해관계자들간의 범위 및 일정조율 중요.

 

III. Burn-Down Chart와 EVM의 비교

[참고] EVM과 Burn Down Chart 프로젝트 적용 방안

반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

객체지향 프로그래밍 특징  (0) 2024.03.09
Architecture  (0) 2024.03.08
CI, CD  (0) 2024.03.06
Lean(린)  (1) 2024.03.05
Kanban  (4) 2024.03.04
78
출제예상 CI, CD [CI의 정의]
- 개발자 별로 소스코드를 지속적/연속적 통합하여 자동화된 빌드, 테스트 및 배포 기능을 통하여 단기간에 고품질의 SW를 획득하는 기술 (형상관리 필수적용)
[CD의 정의]
변경된 요구사항에 대한 개발/통합/배포/테스트/릴리즈를 자동화함으로써 SW의 개발과 운영을 통합하여 DevOps를 지원하는 소프트웨어 연속적인 배포 출시 전략		 CI, 자동화, 통합, 빌드, 배포, Jenkins 연속적 소스 머지, 연속 배포 CI : 소스파일을 실행파일(바이너리파일)로 컴파일, 테스트, 테스트서버에 배포까지 프로 세스(Build Tool)
토픽 이름 CI (Continuous Integration), CD (Continuous Delivery)
분류 PM > Agile > CI, CD
키워드(암기) 소스파일의 연속적인 통합(CI) 및 연속적 배포(CD)
CI : 소스코드의 통합/테스트/배포 자동화를 통한 고품질 SW 획득
CD : S/W 개발 및 운영 통합을 통한 DevOps를 지원하는 연속적인 배포
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 12. CI(Continuous Integration)에 대해 설명하시오. 합숙_2019.04.관리.Day-5
2 4. CI(Continuous Integration)와 CD(Continuous Delivery)를 설명하고, 이를 통한 SW 생산성 향상방안에 대해 제시하시오. 합숙_2018.08.공통.Day-5
3 1. 클라우드 환경 확산 따라 DevOps의 중요성이 증가하고 있다. DevOps 의 구성요소에 대해서 설명하고, CD(Continuous Delivery)의 개념과 절차에 대해서 설명하시오. 모의_2017.04.관리.4
4 다양한 요구 변화에 대한 품질을 확보하며 안정적인 시스템 운영을 위해 스타트업 기업 위주로 DevOps 사상을 도입하는 경우가 증가하고 있다. DevOps 의 부각 배경과 CI(Continuous Integration) 도구, 그리고 DevOps 적용 시 고려사항에 대해서 설명하시오. 모의_2016.04.관리.4
5 1. CI(Continuous Integration), CD(Continuous Delivery)에 대해 설명하시오. 합숙_2014.07.공통.Day-3

 

I. SW의 품질개선과 위험 완화를 위한 Agile Practice, CI (Continuous Integration)) 개요

가. CI의 정의

- 개발자 별로 소스코드를 지속적/연속적 통합하여 자동화된 빌드, 테스트 및 배포 기능을 통하여 단기간에

고품질의 SW를 획득하는 기술 (형상관리 필수적용)

나. CI 목적/필요성

필요성 내용
에러의 조기 발견 - 에러를 초기에 발견할 수 있어, 흔히 발생하는 일반적인 위험을 줄여줌
- 자주 통합할수록 에러가 발생하는 반경(소스Gap)이 좁아짐
배포 용이성 확보 - 언제 어느 때라도 배포할 수 있는 소프트웨어를 생성
가시적 관리 및 자동화 - 프로젝트 가시성 향상, 반복적인 수작업 최소화

 

II. CI 개념도 및 기술요소

가. CI 개념도

 

나. CI 기술요소

구성요소 설명 CI 도구
버전관리 저장소 모든 프로젝트 파일의 중앙 저장소가 있어 팀원들의 작업을 전부 동기화 공간을 제공 - CVS
- Subversion
- GIT
지속적인 통합서버(CI시스템) 컴파일, 테스트, 릴리즈, 디플로이, 결과보고등의 작업을 통합적 자동화 SW - Hudson
- Jenkins
빌드스크립트 자동화된 절차를 위한 셀 스크립트(또는 배치파일)를 작성(소트 코드 컴파일, 테스트 수행 등) - 스크립트
- 배치파일
Project Management Tool 빌드 결과를 모니터링하거나 자동적으로 피드백을 받을 수 있는 관리도구 - 이메일, UC
- 문자메시지
자동화된 테스트 결과를 스스로 확인하는 자동화된 테스트 - SonarQube

 

III. CI의 위험요소와 프렉티스를 성공적 수행하기 위한 자동화 프로세스 Tools

소프트웨어 위험요소 CI 자동화 프로세스 CI 자동화 Tools
배포 가능한 SW 부재
빌드 실패
DB 동기화 실패
배포 실패		 소스 컴파일 자동화
DB Script 테스트
릴리즈 자동화		 Ant, Maven
뒤늦은 결함 발견
회귀테스트 부재
테스트 적용범위 부재		 테스트 자동화 JUnit, TestNG, Selenium
프로젝트 가시성 부재 통합 결과 피드백 Hudson, CruiseControl
저품질 SW
코딩표준, 설계지침 위반
중복/복잡한 코드		 코딩 표준, 설계 지침, 중복코드, 코드복잡도 검사 자동화 Checkstyle, PMD, JDepent, Findbugs

 

[CD(Continuous Delivery)]

I. SW 개발/운영 통합관리, DevOps를 위한 CD(Continuous Delivery)의 개요

 

 

- 변경된 요구사항에 대한 개발/통합/배포/테스트/릴리즈를 자동화함으로써 SW의 개발과 운영을 통합하여 DevOps를 지원하는 소프트웨어 연속적인 배포 출시 전략

II. CI와 CD 관계도

 

- Commit 한 코드를 CI를 수행하고 CD를 수행하여 지속적인 Deploy를 수행

 

[추가_2018.08.합숙풀이]

- 발전된 오픈소스를 통해 CI/CD를 넘어서 DevOps 환경 구성가능

반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

Architecture  (0) 2024.03.08
번다운차트  (0) 2024.03.07
Lean(린)  (1) 2024.03.05
Kanban  (4) 2024.03.04
XP  (0) 2024.03.03
74
상 Lean(린) / 린 경영 /
린(Lean software development)		 [정의] TPS(Toyota Production System)을 재정립한 경영방법론인 린시스템의 품질기법을
소프트웨어 개발에 적용한 개발방법론
[7대원칙]
낭비제거, 배음증폭, 늦은결정, 팀에 권한위임, 빠른 배포, 통합성 구축, 전체를 볼것
​
[7대낭비]
미완성 작업, 가외기능, 재학습, 이관, 작업전환, 지연 결함
낭배늦팀빠통전
미가재이작지결
토픽 이름(중) Lean(린) / 린 경영 / 린(Lean software development)
분류 프로젝트 관리 > Agile 프로세스 > Lean(린) / 린 경영 / 린(Lean software development)
키워드(암기) 린 프로세스, Lean manufacturing or lean production, Toyota Production System, 방법론보단 사상과 프로세스임.
낭비 제거
1.Partially done work
2.Extra processes
3.Extra features
4.Task switching
5.Waiting
6.Motion
7.Defects
8.Management activities
 
7대 원칙 Practice
2.1 Eliminate waste
2.2 Amplify learning
2.3 Decide as late as possible
2.4 Deliver as fast as possible(빠른 인도)
2.5 Empower the team
2.6 Build integrity in
2.7 See the whole
암기법(해당경우) 원칙 : [낭배결빠위통씨] 낭비제거, 배움증폭, 늦은 결정, 빠른 인도, 권한위임, 통합성 구축, 전체를 볼것
낭비 : [재미가결이작지] 재학습, 미완성작업, 가외기능, 결함, 이관, 작업전환, 지연

기출문제

번호 문제 회차
1 Lean SW 개발 방법론에 대하여 설명하시오. 합숙_2019.08 1일차
2 소프트웨어 Agile개발방법론에 대해 다음 질문을 설명하시오.
가. XP, SCRUM, KANBAN에 대해 비교 설명
나. LEAN개발방법론에 대해 설명		 모의_2016.10 4교시
3 린(Lean) 개발방법론을 정의하고, 7 가지 개발원칙 중 5 가지 이상을 제시하시오. 모의_2015.01 1교시
4 린(Lean) 소프트웨어 개발 방법에 대해 설명하시오. 모의_2014.07 1교시
5 소프트웨어 공학에 린 제조업의 원리를 적용시킨 린(Lean) 소프트웨어 개발기법에 대해 설명하고, 칸반(Kanban)과 스크럼(SCRUM)을 비교하시오. 모의_2014.06 3교시
6 Lean 개발방법론에 대하여 설명하시오. 모의_2014.01 1교시

 

I. Just in Time 달성 및 낭비제거, Lean의 개요

가. Lean의 정의

 - 빠른 프로토타입과 신속한 고객 피드백을 통해 JIT(Just in Time) 달성과 함께 낭비를 제거하는 개발 방법론

 

나. Lean의 특징

린 공학 품질기법 도요타의 린 공학 품질기법을 SW개발 프로세스에 적용
낭비요소 제거 낭비요소를 제거하고 7가지 원칙을 준수

 

II. Lean의 7대 원칙과 7대 낭비

  1. Lean의 7대 원칙
원칙 설명
Eliminate Waste (낭비 제거) - 불필요한 코드나 기능, 불분명한 요구사항 등의 낭비요소 제거
Amplify Learning (배움증폭) - 프로젝트 진행 간 학습의 필요성 존재, 고객의 학습도 필요
Decide as Late as Possible
(늦은 결정)		 - 중요한 문제에 대한 의사결정을 최대한 미룸
- 요구사항 변경에 적극적으로 대응할 수 있게 함
Deliver as Fast as Possible
(빠른 인도)		 - 결과물을 최대한 빨리 제공할 것
- 고객이 요구사항을 변경할 시간을 주지 않음
Empower the Team
(팀에 권한 위임)		 - 직원들의 동기부여 및 자기의사결정권으로 잠재력 극대화
Build Integrity In
(통합성 구축)		 - 개발 초기부터 품질을 향상시키도록 하는 것
- 작은 개발 단계마다 오류를 발견하고 수정하는 작업
See the Whole
(전체를 볼 것)		 - 요구사항 수집부터 제품 릴리즈 하는 시점까지 모든 프로세스를 최적화해야 함

 

나. Lean의 7대 낭비

낭비 설명
미완성 작업
(Partial Done Work)		 - 코드로 옮기지 않은 문서, 동기화되지 않은 코드 등 빠지지 않게 흐름을 진행해야 재고를 줄일 수 있음
가외기능
(Extra Feature)		 - 필요하지 않는 기능을 추가하는 것으로 업무에 집중하고 되도록 기능을 추가하지 않는 방향으로 생각
재학습
(Relearning)		 - 지식을 가진 사람들을 개발 과정에 끌어들이지 못해 작업 공간에 제공할 수 있는 지식을 놓여 재 학습하는 활동
결함 - 테스트에 결함 유입을 걸러주는 실수 방지 테스트가 반드시 포함하고 자주 테스트
이관
(Handoff)		 - 업무의 이관은 상당량의 암묵지가 전수되지 못하고 암묵지를 문서로 전달하기 어렵기 때문에 이관할 때 항상 정보가 손실됨
작업전환
(Task Switching)		 - 작업 중 다른 작업으로 전환하는 것은 집중이 분산되고 시간을 소모시키므로 전환 시간 낭비 최소화
지연
(Delay)		 - 필요한 인원이 정기적인 피드백이 있는 Iteration은 지연을 극적으로 줄일 수 있음

III. Kanban과 Lean의 비교

구분 Kanban Lean
개념 Workflow를 표현하는 Kanban보드를 통해, 개발공정을 시각화하고 작업제한, 소요시간 최적화 기법을 통해 적시개발을 지원하는 Agile방법론 적시개발(Just in time development)을 달성하고 낭비제거를 목표로 하는 Agile방법론
수행원리 Workflow 시각화, WIP(work-in-process) 제한 낭비 제거
원칙 Workflow 시각화를 통한 일의 진척도 관리 늦은 결정, 빠른 인도 등의 7대 원칙
사상 여부 개발 방법론 중의 하나 사상 및 아이디어를 총칭

 

반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

번다운차트  (0) 2024.03.07
CI, CD  (0) 2024.03.06
Kanban  (4) 2024.03.04
XP  (0) 2024.03.03
SCRUM  (0) 2024.03.02
72
상 Kanban (development)
프로세스		 [정의] workflow를 표현하는 칸반보드를 통해 공정을 시각화하고 WIP제한, 흐름관리를 통해
적시개발을 지원하는 Agile방법론
[실천방법]1)가시화2)WIP제한3)흐름관리4)정책명시화5)피드백루프 6)개선/발전
[원칙] 현재상태 그대로 시작, 변화 점진적 추구 합의, 기존역할/책임/직함존중, 리더쉽 행동장려
[작업조정] workflow 최적화를 통해 조정가능		 적시개발, 공정시각화, 생산성향상
overload/overproduction관리 - task간균형		 가워흐정프개현변기리
토픽 이름 (상) KANBAN
분류 SW공학 > Agile > kanban
키워드(암기) workflow시각화, WIP(Work in Process)제한, 소요시간 측정 및 최적화, 제조 & 여러팀
칸반 프로세스, 대기행렬(Work Queue)
암기법(해당경우) [위작워크] WIP제한, 작업시간 측정/최적화, Workflow 시각화

 

기출문제

번호 문제 회차
1 Agile의 Scrum과 kanban방법의 차이점과 보완점을 설명하시오 105.정보관리.1.13
2 칸반(Kanban)에 대하여 설명하시오. 합숙_2016.01 1일차
3 Agile 프로세스가 국내에 많이 도입이 되고 있다. 프로젝트 관리자로서, 프로젝트마다 개별 개발방법론과 프로세스의 테일러링이 필요하다. 다음 질문에 대해 설명하시오.
가. SW의 획득가치기법인 EVM과 Burn Down Chart를 비교하시오.
나. 린 프로세스를 정의하고 7개 원칙에 대해 5가지 이상 설명하시오.
다. Kanban과 린 프로세스를 비교하시오.		 합숙_2016.01 5일차
4 Agile 개발 방법론중 하나인 Kanban에 대하여 설명하시오. 합숙_2014.01 5일차
5 애자일의 개발방법론이 많은 장점을 가졌음에도 불구하고 국내 SW개발 사업에서 널리 사용되지 못하고 있다. 다음을 설명하시오
가. Scrum중심으로 Agile을 설명하시오
나. Kanban을 설명하시오		 모의_2019.07 2교시
6 소프트웨어 Agile개발방법론에 대해 다음 질문을 설명하시오.
가. XP, SCRUM, KANBAN에 대해 비교 설명
나. LEAN개발방법론에 대해 설명		 모의_2016.10 4교시
7 최근 다양한 Agile 개발방법론이 대두되고 있는데, 다음 세가지 Agile 개발 방법론에 대해 비교 설명하고, 향후 Agile 개발 방법론 발전 방향에 대해 기술하시오.
가. XP
나. SCRUM
다. KANBAN		 모의_2015.11 4교시
8 소프트웨어 공학에 린 제조업의 원리를 적용시킨 린(Lean) 소프트웨어 개발기법에 대해 설명하고, 칸반(Kanban)과 스크럼(SCRUM)을 비교하시오. 모의_2014.06 3교시
9 Agile 방법론인 Kanban에 대해 SCRUM과 비교하여 설명하시오. 모의_2013.12 1교시

 

 

 

 

 

 

I. Lean thinking 기반의 적시개발을 위한 Agile 개발 방법론, Kanban의 개요

가. KANBAN 개발 방법론의 정의

- 칸반보드를 통해 개발공정을 시각화 하고 WIP 제한을 이용해 workflow 상의 공정을 관리하고 최적화하여 적시개발(just in time Development) 를 지원하는 Agile 방법론

나. KANBAN 개발방법론의 특징

특징 상세내용 사례
Workflow 시각화 - 담당자에게 분할된 수행업무를 카드에
기록 및 Kanban보드 게시		 - To do, Dev, Test, Release, Done
WIP 제한
(Work in Process)		 - Workflow 상에 동시에 진행될 수 있는
 항목을 제한		 - 동시진행 항목 제한
- Workflow 제어 및 업무 재분배
소요시간 측정
및 최적화		 - 한 항목을 완료하는데 걸리는 평균시간인 사이클 타임(Cycle time)을 산정 - 소요시간 최소화를 위한 프로세스 최적화

II. Kanban 개념도(구성도) 및 기술요소

가. Kanban의 개념도

 

 

- TO-DO 리스트를 보고 작업자가 해당 작업을 선택하고 개발 진행, 배포, 서비스 등 순차적으로 Workflow를 가시화

나. Kanban의 구성요소

구성요소 상세내용
Kanban Board 프로세스를 기재한 Board와 스토리카드를 이용해 업무흐름제어
Process 실제 업무가 이루어지는 단계 및 업무 수행을 통한 산출물 작성
Work Queue
(대기행렬)		 대기행렬, 개발 대기, 테스트 대기, 배포/릴리즈 대기과정
총 주기 시간
(total cycle time)		 총 작업의 수행시간. 개별업무의 Cycle Time의 합으로 구성

 

III. KANBAN과 SCRUM 적용 프로세스 측면 비교

구분 KANBAN SCRUM
진척 관리 하나의 스토리가 한번의 반복 과정에서 완성(WIP) time-box 구간 내에서 반복 수행(sprint)

total cycle time을 활용하여 성과 측정 bun down chart 사용 팀 성과 측정
역할과
업무 협의		 별도로 정의된 역할과 미팅이 없음 특정 역할과 업무 협의(meeting)

조직 내에서 익숙한 방법을 사용 정의(스크럼마스터, 제품책임자)

기존 SCRUM사용 조직은 그대로 사용 스프린트 계획미팅(스토리 내 스프린트 결정)
기존 방법론에서 이행 기존 프로세스와 함께 시작하면서 지속적 개선 SCRUM자체의 체계와 기 사용 중인 방법론에서 전환 어려움
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

CI, CD  (0) 2024.03.06
Lean(린)  (1) 2024.03.05
XP  (0) 2024.03.03
SCRUM  (0) 2024.03.02
Agile 선언문 4-12  (0) 2024.03.01
71
상 XP [정의] 의사소통 개선, 즉각적인 피드백에 의해 단순하게 코딩하여 SW품질을 높이기 위한 방법론
[5가치] 용기, 피드백, 의사소통, 단순함, 존중
[12Practice] 개발 - 페어프로그래밍,공동소유/공동책임,CI
관리 - Planning Process, Small Release, Metaphor
구현 - Simple Design, TDD, 리팩토링
환경 - 40-hour work, 고객의 상주 / 기타 - 코드표준준수
[구성] User story -> 구조적Spike-배포 계획-추가(반복)-인수테스트-작은릴리즈 ->Spike
용단커피존
유구배반인작
토픽 이름(중) XP
분류 프로젝트 관리 > Agile 프로세스 > XP
키워드(암기) 용단커피존, 12개 프랙티스
전체팀(Whole Team)
암기법(해당경우) 가치 : [용단커피존] 용기, 단순함, 커뮤니케이션, 피드백, 존중
12가지 실천항목
[개관구환] 개발, 관리, 구현, 환경
개 - [공지페] 공동책임, 지속적 통합, 페어프로그래밍
관 - [메게작(PMS)] -> 메타포, 게임계획, 작은릴리즈 / Planning Game, Metaphor, Small
Release
구 - [리테디] 리펙토링, 테스트주도개발, 단순한 디자인
환 - [4상표] 40시간 작업, 고객상주, 코드표준화

 

기출문제

번호 문제 회차
1 2. XP(eXtreme Programming)의 특징 및 실천 방법(practice)들을 설명하시오. 123.컴시응.3교시.2
2 XP의 12가지 Practice중의 하나인 Continuous Integration을 설명하시오 합숙_2012.08 4일차
3 eXtreme Programming에 대해 설명하시오. 합숙_2013.01 1일차
4 많은 기업에서 애자일 방법론을 도입하려 고민하거나, 현재 적용하고 있습니다. 그 이유나 목적은 다양하지만 ‘신뢰성 높은 소프트웨어를 빨리 개발하자’는 가치를 공유하고 있습니다.
가. 애자일 방법론 중 대표적인 방법론인 XP, 스크럼, 린에 대해서 설명하시오.
나. 애자일 방법론의 대표적 실천사항(Practice) 중 사용자 스토리(User Story), 플래닝 포커(Planning Poker), 속도(Velocity)에 대해서 설명하시오.		 모의_2014.12 2교시
5 최근 다양한 Agile 개발방법론이 대두되고 있는데, 다음 세가지 Agile 개발 방법론에 대해 비교 설명하고, 향후 Agile 개발 방법론 발전 방향에 대해 기술하시오.      가. XP      나. SCRUM     다. KANBAN 모의_2015.11 4교시
6 소프트웨어 Agile개발방법론에 대해 다음 질문을 설명하시오.
가. XP, SCRUM, KANBAN에 대해 비교 설명
나. LEAN개발방법론에 대해 설명		 모의_2016.10 4교시
7 소프트웨어 제품에 대한 가시성을 제공하는 애자일(Agile) 헌장을 기술하시고 애자일 개발방법론인 스크럼(SCRUM)과 XP 대하여 아래 항목을 설명하시오
가. 스크럼(SCRUM)의 개념 및 프로세스
나. XP(eXtreme Programming) 프로세스 및 12 가지 실천사항(7 개이상)
다. 사용자스토리(User Story), 스토리포인트(Story Point)		 모의_2016.11 4교시
8 애자일(Agile)방법론인 XP의 12가지 Practice중 하나인 TDD(Test Driven Development)의 프로세스 및 장단점을 설명하고 BDD(Behavior Driven Development)를 설명하시오. 모의_2013.07 3교시
9 XP의 User Story에 대해 설명하시오. 모의_2012.05 2교시
10 XP의 핵심가치를 실현하기 위한 12가지 프렉티스 중 CI(Continuous Integration)에 대하여 설명하시오 모의_2011.04
 3교시
11 XP의 핵심가치를 실현하기 위한 12가지 프렉티스를 6가지 이상 설명하시오. 모의_2010.01 1교시

 

I. 유연하고 신속한 개발 방법론, XP의 개요

가. XP(eXtreme Programming)의 정의

  • 의사소통과 TDD(Test driven development)를 기반으로 짧은 개발 주기를 통해 소프트웨어를 생산하는 애자일 개발 프로세스의 대표적 개발 방법론

나. XP의 핵심가치

핵심가치 설명
용기 고객의 요구사항 변화에 능동적인 대처
단순성 부가적 기능, 사용되지 않는 구조와 알고리즘 배제
의사소통(커) 공통의 메타포 사용, 페어 프로그래밍 등 관리자, 개발자, 고객 간의 의사 소통
피드백 빠른 피드백을 원칙으로 해결 할 수 있는 일 먼저 처리
존중 구성원 상호간의 존중, 프로젝트에 대한 존중

 

II. 개념도(구성도) 및 기술요소

  1. XP의 프로세스

 

  1. XP 개발 프로세스 단계별 내역
단계 설명
유저스토리
User Story		 - 고객이 필요한 것이 무엇인지를 기술(요구사항 수집, 의사소통 도구)
- 릴리즈 계획을 작성하기 위한 단위
스파이크
Spike		 - 잠재적 솔루션들을 고려하기 위해 작성하는 간단한 프로그램(핵심 기능 프로토타입)
- 사용자 스토리의 신뢰성을 증대 시키거나 기술적 문제의 위험성을 줄일 목적으로 작성
배포계획
Release Planning		 - 전체 프로젝트에 대한 배포 계획을 생성
- 의사결정 등 모든 규칙을 포함, 그 규칙에 의한 프로젝트 수행 방법 정의
반복
Iteration		 - 반복적 개발에서는 민첩함이 중요, 1-3주 정도로 나누어 반복을 균형적으로 유지
- 프포세스의 평가와 계획을 단순하고 신뢰성 있게 만드는 핵심 항목
인수 테스트
Acceptance Test		 - 고객은 작동하는 시스템을 보면서 진척 사항 확인
- 고객이 직접 명세한 테스트 통과 파악
소규모 배포
Small Release		 - 짧은 사이클, 소규모의 빈번한 배포를 통해 고객에게 이득을 조기 제공
- 프로그램은 빠른 피드백을 제공 받음

 

III. XP의 12가지 실천항목

구분 실천항목 내용
개발 페어 프로그래밍
(Pair Programming)		 두명이 한대 컴퓨터에서 개발(오류 감소, 생산성 향상)

공동 책임
(Collective Ownership)		 시스템에 있는 코드는 누구든지 언제라도 수정 가능

지속적 통합
(Continuous Integration)		 하루에 몇 번이라도 시스템 통합하여 빌드 가능
관리 게임 계획
(Planning Game)		 User Story 이용하여 next Release 범위 빠르게 결정

작은 릴리즈
(Small Release)		 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈 (2주단위)

메타포(Metaphor) 문장형태로 시스템 아키텍처 기술, 고객과 개발자간 의사소통 언어
구현 단순한 디자인
(Simple Design)		 요구사항을 만족시키도록 가능한 단순하게 설계함

테스트 주도 개발
(Test Driven Develop)		 테스트 주도(TDD), 테스트를 통한 고객 검증, 승인

리펙토링 (Refactoring) 기능에 변화 없이 코드 수정을 통해 디자인 개선
환경 40시간 작업
(40-hour per week)		 주 40시간 이상 일하지 말도록 규칙, 2주 연속으로 오버타임 금지

고객 상주
(On-Site Customer)		 고객이 프로젝트에 풀타임 상주, 의사 결정 지원
기타 코딩 표준화
(Coding standards)		 커뮤니케이션 향상을 위해 코드가 표준화된 관례에 따라 작성
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

Lean(린)  (1) 2024.03.05
Kanban  (4) 2024.03.04
SCRUM  (0) 2024.03.02
Agile 선언문 4-12  (0) 2024.03.01
정량적 위험 분석  (4) 2024.02.29
70
상 SCRUM [정의] product backlog를 sprint단위로 분할하여 반복적으로 개발하며 daily
meeting, review통해 개선활동을 수행하는 Agile개발방법론
[3역할자] product owner, scrum master, team
[공정관리] burn down chart(계획과 실제번다운 표현)와 velocity측정
[작업조정] sprint진행중 작업추가 불가능
[절차] Product Backlog 미팅 -> Story Point 산정 -> Spring backlog 작성 -> sprint -> daily standup metting -> sprint review -> retrospective review		 daily meeting, sprint backlog, product
backlog, master, 그루밍(PO리딩)
번다운차트(가로:스프린트,세로:남은업무)
time boxing, 피어리뷰
회고(Restrospective)		  
토픽 이름(상) SCRUM
분류 프로젝트 관리 > Agile 프로세스 > SCRUM
키워드(암기) XP, SCRUM, 번다운차트, PO, SM 등 조직 구조 이해, 사례
Working Group(SCRUM team), Daily SCRUM Meeting
Sprint Review Meeting , Sprint Retrospective
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 1. SCRUM의 팀구성 및 개발프로세스 123.정보관리.1.1
1 13. Agile의 scrum과 Kahban 방법의 차이점과 보안점을 설명하시오 105.정보관리.1.13
2 SCRUM의 특성과 프로세스를 설명하시오 93.정보관리.1
3 1. 다음 기업에서 워킹그룹(Working Group)으로 애자일 팀을 구축하고, 애자일 프로세스를 도입해서 적용하시오.
(단, 답안은 SCRUM 기반으로 용어를 표기하여 설명하시오.)
가. 위 사례에서 워킹 그룹을 구축한 사례를 도식화 하시오.
나. 워킹 그룹의 작업 현황판 목록을 도출하고, 설명하시오.
다. 애자일 선언문 4개 내용과 실행 원칙을 5개 이상 기술하시오.
라. 애자일 팀에서 진행하는 회고 미팅에 대해 설명하시오.
    (단, 3가지 회고 미팅 주제로 설명할 것)		 합숙_2019.04_정보관리_DAY3
4 10. 스크럼마스터(Scrum Master)의 주요 역할에 대해 설명하시오. 합숙_2019.01_DAY1
5 13. 프로젝트관리자(Project Manager)와 스크럼 마스터(Scrum Master)의 차이를 설명하시오. 합숙_2018.01_DAY1

 

I. 실용주의 개발 방법론 SCRUM의 개요

가. SCRUM의 정의

- 팀의 개선과 프로젝트 관리를 위한 개발 방법론으로, 작은 개발팀과 짧은 개발기간 동안 점진적

(incremental), 반복적(Iterative)으로 소프트웨어를 개발하는 애자일 개발방법론

나. SCRUM의 특징

특징 설명
협업중심 항상 팀 단위로 생각하며, 팀 단위 협업을 통해 고품질 제품을 효율적 생산하기 위한 환경을 제공함
사회공학기법 프로젝트 이해관계자들의 적극적인 협력과 참여 촉진하여, 관련자의 성취감 충족을 목적으로 함
Sprint 수행 스프린트(Sprint)라는 약 4~6주 정도의 개발 주기를 가지며, 이를 반복 수행함
Daily scrum meeting 8~10명 정도의 scrum팀은 매일 15분 정도의 회의를 통해 진척관리와 이슈 중심 계획 리뷰 실시
독립적 방법론 특정 언어나 방법론에 의존하지 않으며, 개발 언어와 상관없이 적용 가능 개발 기법

 

II. SCRUM의 프로세스 및 프로세스 설명

  1. SCRUM의 프로세스

 

 

단계 수행 목록 내용
1 Product Backlog 작성 요구 사항 목록에 우선순위를 매겨 제품 기능 목록(product backlog) 작성
2 스프린트 계획 회의
(Spring Planning Meeting)		 스프린트 구현 목록(sprint backlog) 작성하고 스프린트 개발 시간 추정
3 스프린트 수행
(Burn down Chart
Daily Scrum Meeting)		 스프린트 개발을 진행하며 일일 스크럼 회의를 통해 진척사항을 확인하고 진행률을 소멸 차트에 표시
4 스프린트 개발 완료
(Spring Review)		 잠재적으로 출시 가능한 제품 증분
5 스프린트 완료 후
(Spring Retrospective)		 스프린트 검토 회의를 하며 스프린트 회고 후 두 번째 스프린트 계획 회의

나. SCRUM 구성요소 설명

구분 구성요소 설명
요구사항

 Product backlog - PO(Product Owner)에 의해 우선순위가 정해진 사용자가 요구하는 제품의 기능 목록
Sprint backlog - 각각의 sprint 주기에서 개발할 작업 목록
- Sprint 기간 동안 개발 가능한 기능의 목록을 product backlog에서 선택
주기 Sprint - 보통 2~4주 정도로 짧은 기간을 가지는 반복 개발 주기
- 각 sprint 단계 종료 시 새로운 기능이 추가되어 실행 가능 제품이 인도되어야 함
회의







 Product Backlog Meeting - Product Owner 가 이해관계자들과 미팅후 우선순위 선별. Product backlog 작성
Spring Planning Meeting - 스프린트 계획 회의, 스프린트 백로그 산정
Daily scrum meeting - 일일 15분 정도의 짧은 회의이며 어제 한 일, 오늘 할 일, 이슈사항 발표
- SCRUM master는 진척사항 검토 및 이슈사항 확인
Sprint review - 하나의 스프린트 반복 주기가 끝났을 때 실행 가능한 제품에 대해 검토
- 스프린트 목표달성 여부, 작업 진행과 결과물 확인
Sprint Retrospective - 스프린트 종료 후 수행활동과 개발한 것을 되돌아보고 개선점이나 규칙 및 표준을 잘 준수했는지 검토
관리 Burn-down chart - 하나의 스프린트에서 작업에 대한 완료 추이를 나타낸 차트

III. PO, Scrum Master, Scrum Team의 설명

담당자 항복 역할
제품 책임자
(product owner)

 제품 기능 목록 작성 - 제품 기능 목록을 만들고 비즈니스 관점에서 우선순위와 중요도를 매기고 새로운 항목을 추가
스프린트 운영 관여 안함 - 스프린트 계획 수립 시 까지만 역할을 수행하고, 스프린트가 시작되면 팀 운영에 관여하지 않음
스크럼 마스터
(scrum master)

 조력자 역할
애자일 촉진자		 - SCRUM에서 PM(Project Manager)
- 업무를 배분만 하고, 일은 강요하지는 않음
- Scrum 팀이 스스로 조직하고 관리하도록 지원
개발 방해 요소 제거 - 개발 과정에 방해될 만한 요소를 찾아 제거
스크럼 팀
(scrum team)



 요구사항 구현 - 팀원은 보통 5~9명으로 구성되며, 사용자 요구 사항을 사용자 스토리로 도출하고 이를 구현
제품 시연 - 하나의 스프린트에서 생산된 결과물을 제품 책임자에게 시연
스크럼 회의 진행 - 매일 스크럼 회의에 참여하여 진척 상황을 점검

IV. Scrum 미팅 유형 비교

[참고] 회고 미팅 3가지 분류

- Working Group 전체가 참석하여, 편하게 대화할 수 있는 장소로 이동, ‘한 명씩 돌아가며, 이야기 하는’ 형태의

개선의 장이 될 수 있는 미팅. (1H 내외)

반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

Kanban  (4) 2024.03.04
XP  (0) 2024.03.03
Agile 선언문 4-12  (0) 2024.03.01
정량적 위험 분석  (4) 2024.02.29
획득가치관리(EVM)  (1) 2024.02.28
5 Agile 프로세스 출제예상 선언문 4개 문장 [정의] 절차보다 사람이 중심 되어 변화에 유연하고 신속하게 적응해 효율적으로 개발 할 수 있는 방법론
[특징] 1)고객만족 2)짧은 반복주기 3)암묵적 지식의존 4)PM역할변화 5)개발자 동기부여 6)의사소통 활성화
[장점] 1)ROI증대 2)TimeToMarket/Delivery Time감소 3)창의성/생산성 향상 4)품질향상(잦은 테스트)
[단점] 1)문서화부족 2))사업관리 미흡 3)감리대응 문제 4)변경 오버헤드
[선언문]
공정,도구 > 개인과 상호작용
계획 추구 > 변화에 대응
포괄적 문서 > 작동하는 소프트웨어
계약 협상 > 고객과의 협력
개변동고
공계문계
68
출제예상 12개 원칙 고객만족 추구, 요구변경 수용, 짧은 배포주기, 일일의사소통, 동기부여,
면대면대화, 작동하는 SW가 척도, 지속 가능개발, 좋은 설계 관심,
단순성 추구, 자기조직적팀, 효율성 제고
고요배의동
대SW지좋단자효
토픽 이름(출제예상) 선언문 4개 문장_12개 원칙
분류 프로젝트 관리 > Agile 프로세스 > 선언문 4개 문장_12개 원칙
키워드(암기) Manifesto, Principles, 개변동고, 고요배의 동대소지 좋단자효
암기법(해당경우) 개변동고 공계문계, 고요배의 동대소지 좋단자효

기출문제

번호 문제 회차
1 1. 다음 기업에서 워킹그룹(Working Group)으로 애자일 팀을 구축하고, 애자일 프로세스를 도입해서 적용하시오.
(단, 답안은 SCRUM 기반으로 용어를 표기하여 설명하시오.)
가. 위 사례에서 워킹 그룹을 구축한 사례를 도식화 하시오.
나. 워킹 그룹의 작업 현황판 목록을 도출하고, 설명하시오.
다. 애자일 선언문 4개 내용과 실행 원칙을 5개 이상 기술하시오.
라. 애자일 팀에서 진행하는 회고 미팅에 대해 설명하시오.
    (단, 3가지 회고 미팅 주제로 설명할 것)		 합숙_2019.04_관리_Day-3
2 1. 애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development)에서 발표한 4가지 가치, 12가지 원칙에 대하여 설명하고 애자일 개발 문화를 확산시키기 위한 CSF(Critical Success Factor)를 제시하시오. 합숙_2020.01_공통_Day-1
3 최근 기민한 개발 방법론과 Enterprise 개발 방법론의 결합을 위한 다양한 시도가 증가하고 있다.
  가. Agile Manifesto 4가지에 대해 설명하시오.
  나. Agile 방법론 중 가장 대표적인 방법론인 XP에 대해 설명하시오.
  다. 전통적인 방법론과 Agile방법론을 비교하고 기존 방법론과 결합하기 위한 방안을 제시하시오.		 합숙_2011.02_공통_Day-1

 

I. 사람중심의 유연한 개발방법론, Agile 방법론의 개요

가. Agile 방법론의 정의

- 효율적인 제품, SW 개발을 위해 절차보다는 사람과 제품에 집중하여 낭비를 제거하고 고객의 요구사항을

보다 유연하고 신속하게 반영하기 위한 방법론

  나. Agile 방법론의 등장배경

 

SW 개발 환경
변화		 - 정보시스템에 대한 사용자 요구 다양해지고, 정보시스템 수명주기 짧아짐
- 정보시스템의 적시성(time-to-market)과 Product의 적시 배포(Release)가 중요해짐
개발 방법론
한계		 - 문서위주, 절차중심의 방법론은 변화에의 신속한 적응이 어려움
- 변화에 빠르게 적용하고 효율적으로 개발할 수 있는 방법론이 필요
- 소규모 및 중간규모 시스템에 무거운 계획 기반 기법 적용 시 오버헤드가 너무 커짐

II. Agile 4가지 가치(Value) 및 12가지 원칙(Principle)

  가. Agile 4가지 가치(Value)

가치 설명
개인과 상호작용 공정과 도구보다 개인과 상호작용을 강조
변화에 대응 포괄적인 문서보다 작동하는 소프트웨어에 가치를 둠
작동하는 소프트웨어 계약 협상보다 고객과의 협력에 가치를 둠
고객과의 협력 계획을 따르기보다 변화에 대응하는 것에 가치를 둠

나. Agile 12가지 원칙(Principle)

12가지 원칙 핵심 설명
고객만족 추구 고객 최우선 중시 - 빠른 배포와 피드백 반영, 고객의 만족도 향상
요구사항 변경 수용 요구 변경 상황 인정 - 고객 요구 변경 인정 및 대응을 위한 유연성
짧은 배포 간격 CI/CD 활용 - 도구 등을 통해 빠른 배포, 고객 피드백 반영
현업-개발자간 일일 의사소통 소통 중시 - 담당자와 개발자 간의 소통을 통한 업무 효율화
동기부여된 사람들 중용/지원 상호 존중 문화 - 동기 부여된 팀원을 중용 및 환경 지원
면대면 대화 의사소통의 효율화 - Daily Meeting등을 통한 면대면 대화
지속 가능한 개발 장려 일정한 속도 유지 - 지속 가능한 개발 및 프로젝트 진행 장려
작동하는 소프트웨어 진척도로 SW중시 - 직접 SW의 기능/비기능적 요소 및 진행관리
좋은 기술, 설계 관심 복잡성 줄이기 위한 기술 우수성 중시 - 우수한 기술, 아키텍처 중시 및 공유
단순성 추구 일정/진행사항 단순화 및 시간 절약 - 목표 업무와 연관 없는 일들을 최소화
자기 조직적 팀 조직 생산성 증대 - 책임감 부여,생산성 증대위한 자기조직적 팀
정기적 효율성 제고 업무 효율성 증대 - 스프린트 리뷰를 통해 다음 스프린트에 반영 할 수 있는 요소 적용

 

III. Agile Methodology의 장단점

가. Agile Methodology의 장점

장점 설명
ROI 증대 - 고객들에게 가치 있는 기능들을 빠르고 안정적으로 전달
Delivery Time 감소 - 요구사항의 변화를 유연하게 수용함으로써 Time to Market 실현
창의성 향상 - 팀 자율성 강화를 통한 업무만족도와 창의성 향상
생산성 향상 - 불필요한 산출물 제거 및 팀 협업 강화
제품 품질 향상 - 고객의 주기적 피드백 및 빈번한 테스트

 

나. Agile Methodology의 단점

단점 내용
체계적인 문서화
및 지침 부족		 - Agile 프로세스 적용을 지원하는 문서화나 구체적인 지침 부족
- 전체 제품에 대한 통합과 테스팅에 대한 가이드가 부족
요구사항 변경에
의한 오버헤드		 - 비기능적인 요구사항에 대한 고려가 부족
- 요구사항의 잦은 변경에 따른 테스트 수행노력 증가
사업 관리 부분
미흡		 - 측정지표가 개발자 위주로 상위관리자의 요구를 충족하기 충족하기 어려움
- 프로젝트 리스크 관리 (Risk management)에 대한 고려 부족
감리 대응 문제 - 기존 방법론에 비해 적은 문서량, 감리 기준에 부합되지 않는 산출물로 이슈 발생
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

XP  (0) 2024.03.03
SCRUM  (0) 2024.03.02
정량적 위험 분석  (4) 2024.02.29
획득가치관리(EVM)  (1) 2024.02.28
자원 최적화  (0) 2024.02.28
상 정량적 위험 분석 [정의] 프로젝트 위험을 수치화 하여 프로젝트에 미치는 영향 분석하는 프로세스
[기법]
영향관계도
민감도 분석(토네이도 다이어그램, 일원분산분석, 시나리오 분석)
의사결정 분석(EMV)
모의실험(몬테카를로 시뮬레이션)		 영민의모
토픽 이름(상) 정량적 위험 분석
분류 프로젝트관리 > 위험관리 > 정량적 위험 분석
키워드(암기) 시뮬레이션, 민감도 분석, 의사결정 트리(Decision Tree)
금전적 기대값 분석(EMV),
정량적 위험 분석 기법을 통한 위험을 수치화 함
암기법(해당경우) [수분대기] 수집, 분석, 대인관계 및 팀 스킬, 기타
수-[인] 인터뷰
부-[영민의모] 영향도, 민감도 분석, 의사결정, 모의실험
대-[촉] 촉진
기-[불전] 불활실성 표현, 전문가 판단

기출문제

번호 문제 회차
1 5. 정량적 위협분석의 정의와 필요성을 설명하고, 아래의 4가지 위험분석 기법에 대하여 예시를 들어 설명하시오.
가. 의사결정나무 분석(Decision Tree Analysis)
나. 금전적 기대값 분석(Expected Monetary Value Analysis)
다. 몬테카를로 시뮬레이션(Monte Carlo Simulation)
라. 민감도 분석(Sensitivity Analysis)		 123.관리.4.5
2 1. 정량적 위험분석 4가지 방법에 대하여 예시를 들어 설명하시오.
가. 민감도 분석(Sensitivity Analysis)
나. 금전적 기대값 분석(Expected Monetrary Value Analysis)
다. 의사결정나무 분석(Decision Tree Analysis)
라. 몬테카를로 시뮬레이션(Monte Carlo Simulation)		 117.관리.2.1
3 2. 위험관리 프로세스, 위험분석의 정성적 위험 분석, 정량적 위험 분석을 서술하시오 모의_2019.07.관리.3

 

I. 개별 프로젝트 위험의 우선 순위를 결정하는 분석절차, 정량적 위험 분석의 개요

- 식별된 개별 프로젝트 위험과 기타 불확실한 원인이 전체 프로젝트 목표에 미치는 영향을 수치적 분석하는 프로세스

II. 정량적 위험 분석 기법 설명

번호 문제 회차
데이터 수집 인터뷰 위험의 확률 및 영향을 수치로 환산하기 위해 선례 정보나 경험을 참고하는 방법으로 필요한 정보는 사용될 확률 분포에 따라 달라짐.
데이터 분석 영향도 다양한 위험요인, 원인들이 결과에 미치는 관계를 도표로 표현한 분석기법

민감도 분석 - 불활실한 요소를 걸정하여 목표에 영향을 미치는 정도를 분석 다른 위험 수치는 고정시킨 상태에서 임의의 한 위험을 변동 했을 때 전체 프로젝트에 미치는 영향력이 변동하는지 분석
- 토네이도 다이어그램, 일원분산분석, 시나리오 분석

의사결정 분석 각 의사결정에 따른 기대값을 계산하여 최적의 의사결정 선택
EMV (Expected Monetary Value)
- 예상되는 금전적인 가치로 위험의 크기를 측정하여 의사결정

모의실험 - 모수, 변수에 대하여 다양한 수치를 대입하여 확률변수의 분포 산정하는 기법
- 몬테카를로 분석법
특정 변수를 예측하기 위해 확률모형의 모수나 변수에 대해 반복적으로 여러 수치를 대입하여 확률 변수의 분포를 산정한다
데이터 표현 위험 확률 및 영향력 매트릭스 평가된 리스크 확률-영향을 P-I Matrix를 사용하여 등급화

계층적인 차트 3개 모수를 표현하는 버블차트
버블의 크기가 클수록 허용할 수 없는 큰 위험 요소이다.
버블의 크기는 영향 값(Impact value)이다.
대인관계 및 팀 기술 촉진 워크샵을 통해, 협의 도출 및 창의적으로 접근
기타 기법 불활실성 표현 기간, 원가, 일정, 자원의 요구사항에 대한 불확실성을 확률분포(Probability distributions)로 표현하는 것을 말함.

전문가 판단 유사 프로젝트나 도메인 및 비즈니스 관련 분야에 경험을 가진 전문가가 직접 위험을 수치화 및 모델링 적용

“끝”

[참고] 정량적 위험 분석 수행 (Plan Scope Management) ITO

입력물(Input) 도구 및 기법(Tool & Technique) 산출물(Output)
1. 프로젝트 관리 계획서
- 위험 관리 계획서
 (Risk Management Plan)
- 범위/일정/원가 기준선
2. 프로젝트 문서
가정사항 로그, 산정 근거
 원가 산정, 원가 예측치
 일정 예측치, 기간 산정,
마일스톤 목록
 자원 요구사항
 위험 관리대장(Risk Register)
 위험 보고서
3. 기업환경요인(EEF)
4. 조직 프로세스 자산(OPA)		 1. 전문가 판단(Expert Judgment)
2. 데이터 수집((Data Gathering)
- 인터뷰
3. 대인관계 및 팀 기술  (Interpersonal and team skills)
- 촉진
4. 불확실성 표현 (Representation of Uncertainty)
5. 데이터 분석
- 모의실험(Simulation)
- 민감도 분석(Sensitivity Analysis) - 의사결정 분석(Decision Analysis)
- 영향도(Influence Diagram)		 1. 프로젝트 문서 갱신 (Project Document Updates)
 - 위험 보고서

 

 

[몬테카를로(Monte Carlo) 시뮬레이션]

 

구분 설명
정의 - 특정 변수 예측 위해 투입 데이터의 확률분포에 따른 난수 반복적 생성하여 누적 분포 만들고, 누적결과 분석해 확률적 모형 제공하는 통계적 분석 방법
예시
- 이 누적 분포는 프로젝트가 $41M의 산정치 충족할 확률이 12%
- 보수적 조직에서 75%의 성공 확률을 원하는 경우, $50M의 예산(약 22% ($50M - $41M)의 우발사태 예비비)이 필요.

 

[민감도 분석 (Sensitivity Analysis)]

구분 설명
정의 - 선택된 방법과 데이터가 결과에 미치는 영향을 평가하기 위한 분석 절차
프로젝트의 목표에 잠재적 영향력이 큰 위험을 분석하고 결정하는데 유용한 방법으로 불확실한 요소를 기준 값으로 설정하고 대상이 목표에 영향을 미치는 정도를 분석하는 방법
종류



 토네이도 다이어그램
(Tornado Diagram)		 - 입력데이터에 같은 비율 적용하여 산출물 변화량 설명
일원 분산 분석
(one-way ANOVA)		 - 셋 이상의 집단간 통계적으로 유의미한 차이가 있는지 검증하는 방법
시나리오 분석
(Scenario Analysis)		 - 가정을 토대로 미래 상황 기술하는 것으로 시스템 경계, 할당 방법, 기술, 시간, 공간 및 가중치 방법등 사용
예시

- 토네이도 다이어그램		 - 민감도가 큰 순서대로 막대그래프로 표시
- 위험의 긍정적/부정적 영향의 정도와 민감도를 표시



 

 

 

[의사결정 나무 분석 (Decision Tree Analysis)]

구분 설명
정의 - 각 시나리오의 예상되는 금전적 가치를 산정(=금전적 기대값 분석(Expected Monetary Value analysis))해 평가하여, 최적 의사결정 경로 결정하는 방법
- 여러 대안 조치 과정 중 가장 효과적인 대안 선택하는데 사용
예시
- 금전적 기대값 (EMV) = 발생확률 * 기대금액
- 발생확률이 65%이고 영향도가 80억이면, EMV = 0.65 * 80억 = 52억 이 된다.

 

[영향 관계도 (Influence Diagrams)]

분석기법 설명
영향 관계도
(Influence diagrams)		 위험의 원인과 결과를 순서대로 정의한 도표로, 다양한 변수와 결과 사이의 영향 분석하고자 작성한다. 이때도, 범위 및 확률 분포를 통해, 영향 관계도에 나타낼 수 있음
반응형
저작자표시 비영리 변경금지

'정보관리기술사 > 소프트웨어공학' 카테고리의 다른 글

SCRUM  (0) 2024.03.02
Agile 선언문 4-12  (0) 2024.03.01
획득가치관리(EVM)  (1) 2024.02.28
자원 최적화  (0) 2024.02.28
프로젝트 일정 단축기법  (0) 2024.02.27

+ Recent posts

티스토리툴바