프로젝트관리 감리사 기출문제[4/4]

 

8회 13번) 서면 질문과 무기명 응답, 그리고 응답 결과분석 및 배포 과정을 반복함으로써 주어진 문제에 대한 전문가의 합의를 이끌어내는 위험 식별 기법은?

 

① 인터뷰                                       ② 델파이 기법

③ 브레인스토밍                             ④ SWOT 분석

 

해설:  ②번

 

리스크 관리 – 리스크 식별 프로세스

  • 프로젝트에 영향을 미칠 수 있는 리스크를 결정하고, 리스크별 특성을 문서화하는 프로세스
  • 프로젝트가 진행됨에 따라 생애 주기 전반에서 새로운 리스크가 발생되거나 확인될 수 있기 때문에 리스크 식별은 반복적인 프로세스

 

1) 도구 및 기법

1-1) 문서 검토

1-2) 정보 수집 기법

도구 및 기법

설명

브레인스토밍

  • 종합적인 프로젝트 리스크 목록을 작성하는 것
  • 프로젝트팀 및 일반적으로 팀에 포함되지 않은 다양한 분야의 전문가와 함께 브레인스토밍을 수행한다.
  • 진행자의 안내에 따라 프로젝트 리스크에 대한 아이디어를 얻을 수 있다.
  • 브레인스토밍을 수행하고 나면 리스크를 식별하여 유형에 따라 분류하고 명확하게 정의할 수 있게 된다.

델파이기법

  • 전문가 의견의 합의점을 찾아내는 방법이다.
  • 프로젝트 리스크 전문가는 이 기법에 익명으로 참여한다.
  • 진행자는 설문을 이용하여 중요 프로젝트 리스크에 대한 아이디어를 얻는다. 설문에 대한 응답을 요약한 후 전문가들에게 다시 회람하여 추가적인 견해를 구한다. 이 프로세스를 몇 번 거치고 나면 합의점에 도달할 수 있다.
  • 델파이 기법을 사용하면 자료 편중 현상을 줄이고 결과에 대한 특정 개인의 과도한 영향력을 막을 수 있다.

인터뷰

  • 경험이 있는 프로젝트 참여자, 이해관계자 및 해당 분야의 전문가와의 인터뷰를 통해 리스크를 식별할 수 있다.
  • 인터뷰는 리스크 식별 자료 수집에 있어서 주요 출처 중 하나이다

근본 원인 식별

  • 프로젝트 리스크의 근본 원인을 조사하는 방법이다.
  • 이 기법을 사용하면 리스크를 보다 명확하게 정의할 수 있고 원인별로 분류할 수 있다. 리스크의 근본 원인이 밝혀지면 효과적인 리스크 대응책을 개발할 수 있다

1-3) 점검목록 분석

1-4) 가정사항 분석

1-5) 도식화 기법

1-6) SWOT 분석

1-7) 전문가 판단

 

5회 24번) 컴포넌트 기반 시스템 개발을 위해 마르미Ⅲ 방법론을 적용하기로 하였다. 그런데 프로젝트의 위험을 식별한 결과, 프로젝트 참여자들이 마르미Ⅲ에 대한 지식과 경험이 없다는 것이 문제가 되었다. 이때 위험을 완화하기 위한 계획에 해당하는 것은?

 

① 마르미에 경험이 있는 외부 전문가에게 방법론 Ⅲ 적용 방안을 모색하도록 위임한다.

② 프로젝트 참여자들에게 마르미Ⅲ를 교육한다.

③ 개발 방법론을 변경한다.

④ 시간을 지체할 수 없으므로 프로젝트 관리자의 주도로 프로젝트를 진행시킨다.

 

해설:  ②번

프로젝트 참여자에게 교육을 통해 리스크의 확률/영향력을 허용한계선까지 낮춤 → 완화

① 외부 전문가에게 위임 → 전가

③ 개발 방법론 변경 → 회피

④ 프로젝트 진행 → 수용

 

 

리스크 관리 – 리스크 대응 계획수립 프로세스

  • 프로젝트 목표에 대한 기회는 증대시키고 위협은 줄이기 위한 대안과 조치를 개발하는 프로세스
  • 각 리스크 대응책에 대해 책임을 지는 한 사람을 선정하는 작업 포함
  • 우선순위에 따라 리스크를 처리하며, 필요하면 예산, 일정 및 프로젝트 관리 계획서에 자원 및 활동을 추가함

 

6회 8번) 다음 중 위험 대응전략에 관한 설명으로 적절한 것은?

 

① 회피 : 특정 위험요소에 대한 적절한 대응 방법을 식별하는 것이 불가능함을 의미한다.

② 완화 : 이행보증(Performance Bonds), 보험 등을 통하여 위험을 소멸시키는 것이다.

③ 수용 : 위험에 대처하기 위하여 프로젝트의 계획을 변경하는 것이다.

④ 전가 : 위험에 대한 영향과 책임을 제3자에게 이양하는 것이다.

 

해설:  ④번

① 특정 위험요소에 대한 적절한 대응 방법을 식별하는 것이 불가능함을 의미한다. → 수용

② 이행보증(Performance Bonds), 보험 등을 통하여 위험을 소멸시키는 것이다. → 전가

③ 위험에 대처하기 위하여 프로젝트의 계획을 변경하는 것이다. → 회피

 

 

8회 22번) 보험에 가입하는 것은 어떤 위험 대응 방안인가?

 

① 완화(Mitigate)              ② 전가(Transfer)

③ 수용(Accept)                            ④ 회피(Avoid)

 

해설:  ②번

 

9회 6번) 개발 위험요인의 위험 값(Risk Value)을 계산하기 위하여 고려해야 할 요인은? (2개 선택)

 

① 위험 가능성(Likelihood)            ② 위험 평가(Evaluation)

③ 위험 개수(Number)                   ④ 위험 충격(Impact)

 

해설:  ①, ④번

 

10회 15번) 위험분석기법의 하나인 위험노출도(Risk Exposure)에서 정의하는 위험 중 ’예상 못한 손실’이 있다. 프로젝트 승인에 6주 이상 걸릴 ‘예상 못한 손실’이 발생할 확률이 15%일 대 위험노출도를 구하라.

 

① 0.15주            ② 0.9주              ③ 5.1주              ④ 6.9주

 

해설:  ②번

위험노출도 = 발생가능성 * 영향력 = 15% * 6주 = 0.9주

 

11회 10번) 다음 중 리스크 관리 계획에 포함되어야 할 내용을 모두 고르시오.

가. 리스크 관리를 위한 방법론

나. 리스크 관리에 대한 역할과 책임

다. 리스크 관리에 소요되는 예산 산정

라. 리스크 범주

마. 리스크 발생 확률과 그에 미치는 영향

 

① 가, 나, 다, 마

② 가, 나, 라, 마

③ 가, 나, 다, 라

④ 가, 나, 다, 라, 마

 

해설:  ④번

 

해설:  ④번

 

리스크 관리 – 리스크 관리 계획수립 프로세스

  • 프로젝트에 대한 리스크 관리 활동의 수행방법을 정의하는 프로세스

 

리스크 관리 계획서

  • 프로젝트 리스크 관리의 구조와 수행방법을 기술하며, 프로젝트 관리계획서에 포함됨
    • 방법론: 리스크 관리를 수행하는 데 사용할 수 있는 접근방법, 도구/자료출처 정의
    • 역할 및 책임사항: 각 활동 유형별 리더, 자원 및 리스크 관리 팀원을 정의하고 그들의 책임사항을 명시
    • 예산 책정: 리스크 관리에 필요하며 원가 성과 기준선에 포함시킬 자원, 산정치 자금을 할당하고, 우발사태 예비의 적용 규약을 제정함
    • 시기: 프로젝트 생애 주기에 걸쳐 리스크 관리 프로세스의 수행 시기와 빈도를 정의하고 일정 우발사태 예비의 적용 규약을 제정하며, 프로젝트 일정에 포함시킬 리스크 관리 활동을 설정함
    • 리스크 범주: 리스크를 체계적으로 식별하는 종합적인 프로세스가 될 수 있는 구조를 제공함. 간단한 범주 목록 형태 또는 리스크 분류 체계(RBS) 형태
    • 리스크의 확률 및 영향 정의: 리스크의 발생 확률과 영향의 다양한 수준을 정의
    • 확률-영향 매트릭스
    • 수정된 이해관계자 허용한도
    • 보고 형식
    • 추적

 

 

5회 4번) 프로젝트관리에서 팀원의 Commitment를 확보하는 것은 매우 중요하다.

이와 같이 목표달성에 대한 자발적인 동의를 얻기 위해 사용하는 방법과 거리가 먼 것은?

 

① 계획수립에 팀원을 참여시킨다.

② 모두에게 균등한 성과보상체계를 구축한다.

③ 주요 이슈에 대해 그룹 의사결정을 장려한다.

④ 프로젝트 관리자가 스스로 헌신하는 모습을 보인다.

 

해설:  ②번

인정과 보상은 반드시 모범적 행위만을 보상한다.

사람들은 조직에서 가치를 인정 받는다고 느끼고 보상을 통해 확인될 때 자극을 받는다.

따라서 뛰어난 성과를 공개적 인정하는 것은 확실한 동기 부여가 되므로 프로젝트 관리자는 프로젝트 완료 이후보다는 프로젝트 생애 주기 동안 팀의 가능한 모든 성과를 인정해주는 것이 좋다

 

 

11회 13번) 팀 구축 활동은 프로젝트의 성공에 결정적으로 작용한다. 팀이 거쳐갈 수 있는 5단계 개발 이론의 순서를 올바르게 나열한 것은?

 

① 스토밍-형성-표준화-수행-해산

② 형성-스토밍-표준화-수행-해산

③ 수행-스토밍-형성-표준화-해산

④ 형성-표준화-스토밍-수행-해산

 

해설:  ②번

집단발달단계는 둘 이상의 어떤 형태의 모임에도 적용할 수 있는 이론이며, 형성/forming → 스토밍/storming → 표준화/Norming → 수행/Peforming → 해산/Adjourning의 단계로 진행됨

 

 

1) 팀 구축 활동 – 프로젝트 팀 개발의 도구 및 기법 中

  • 팀 구축 활동의 목표는 팀원 개개인이 효과적으로 협력하도록 지원하는 것이며, 팀원이 서로 대면하지 않고 원격지에서 작업할 때 특히 가치를 발휘함
  • 효과적인 팀을 구축하려면 프로젝트 관리자가 최고 경영진의 후원을 받고 팀원의 헌신적 참여와 적절한 보상/인정 체계 도입, 팀 정체성 수립, 갈등의 효과적인 관리, 팀원 간에 신뢰와 개발적인 대화 촉진이 필요하며 무엇보다도 훌륭한 팀 리더십을 발휘해야 함
  • 팀 구축은 프로젝트 성공에 결정적인 작용, 프로젝트 초기에 필수적이고 지속적인 프로세스임

 

2) 집단발달 5단계 모형(표준화 단계)

  • 보통 5단계는 차례로 일어나지만 특정 단계에 머무르거나 이전 단계로 밀리는 상황이 발생하기도 함
  • 특정 단계의 기간은 팀의 역학, 크기, 팀 리더십에 따라 달라짐

단계

설명

1

형성

(forming)

  • 팀이 모여서 프로젝트 자체, 각자의 공식적인 역할, 책임사항을 파악하는 단계
  • 팀원들이 독자적이며 개방적이지 않은 경향이 있음

2

스토밍

(storming)

  • 팀이 프로젝트 작업, 기술적 의사결정, 프로젝트 관리방식을 다루기 시작
  • 팀원들이 다른 사고와 관점에 협조적, 개방적이지 않으면 파괴적인 환경이 조성될 수 있음

3

표준화

(Norming)

  • 팀원들이 협력하고 팀을 지원하는 행동과 작업 습관을 조율하기 시작함
  • 팀원들이 서로 신뢰하기 시작함

4

수행

(Peforming)

  • 잘 구성된 단위로 운영됨
  • 팀원들이 상호 의존적이며 원활하고 효과적으로 문제를 해결함

5

해산

(Adjourning)

  • 팀이 작업을 완료하고 프로젝트에서 이동함

 

 

 

5회 23번) 팀 조직도에 포함되는 내용이 아닌 것은?

 

① 조직의 계층 구조

② 조직의 담당 업무

③ 의사소통 경로

④ 구성원의 역할과 책임

 

해설:  ③번

 

 

6회 11번) 갈등 해결전략 중 자기 의견 관철 정도와 타그룹에 대한 협조 정도가 동시에 낮은 방법은?

 

① 절충(Compromising)                 ② 회피(Avoiding)

③ 조화(Accommodating)              ④ 경쟁(Competing)

 

해설:  ②번

갈등관리는 인적자원관리 è 프로젝트팀관리의 도구 및 기법에 속함

갈등 해결전략을 작업내용에 관심과 관계의 관심 관점으로 살펴보았을 때 동시에 낮은 방안은 철회/회피(withdrawing/avoiding) 방안임

 

9회 8번) 다음 중 각각의 상황에 따른 갈등해결 전략이 올바르게 짝지어진 것은? (2개 선택)

 

① 자기의견 관철(Forcing) - 매우 중요한 통합된 의견을 도출할 때

② 상대의견 수용(Smoothing) - 상대로 하여금 실패를 통하여 배우도록 할 때

③ 양쪽의견 절충(Compromising) - 복잡한 문제의 잠정적인 해결책을 도출할 때

④ 회피(Withdrawing) - 나중을 위해서 신용을 얻고자 할 때

 

해설:  ②, ③번

  • 매우 중요한 통합된 의견을 도출할 때 -> 직면/문제해결(confronting/problem solving)
  • 나중을 위해서 신용을 얻고자 할 때 -> 수용(Smoothing)

 

 

9회 11번) 프로젝트가 진행됨에 따라 갈등이 나타날 수 있다. 다음 중 프로젝트 시기와 주요 갈등요인이 가장 올바르게 짝지어진 것은?

 

① 전반기 - 원가, 후반기 - 프로젝트 우선순위

② 전반기 - 기술적 옵션, 후반기 - 일정

③ 전반기 - 프로젝트 우선순위, 후반기 - 일정

④ 전반기 - 일정, 후반기 – 원가

 

해설:  ③번

1) 갈등의 원인

- 일정, 프로젝트 우선순위, 자원, 기술적 견해, 관리적 절차, 비용, 개인성향

 

2) 프로젝트 시기별 주요 갈등 원인

- 프로젝트 단계에 따라 갈등을 일으키는 원인들의 순서가 달라지게 됨

- 계획수립단계에서는 프로젝트 우선순위가 갈등의 가장 큰 원인

- 구현단계에서는 일정이 가장 큰 갈등의 원인

 

 

11회 24번) 해결이 가장 어렵다고 할 수 있는 갈등 유형은?

 

① 단순한 의견 차이에 의한 갈등

② 장기적 관계를 유지해야 하는 관계에서 파생된 갈등

③ 원칙의 문제가 걸려 있는 갈등

④ 강력한 리더쉽이 존재하는 조직에서의 갈등

 

해설:  ③번

갈등을 일으키는 당사자간의 원칙이 서로 상이한 경우 해결방법을 찾기가 어려움

 

4회 17번) 화폐 가치의 불안정, 정치적 불안, 국가간 및 지방정부간의 경쟁, 특정의 이익 집단 등의 요소들이 국제 프로젝트에 관한 프로젝트 관리에 영향을 준다.

국제 프로젝트의 PM은 문화적으로 해결해야 할 국가간의 다른 주요 요소가 무엇인지를 인식하여야 하는데, 다음 중 특히 염두에 두어야 하는 요소는?

 

① 수행보고시스템의 확립

② 의사소통 관리 시스템의 개발

③ 공식적이고 문서화된 프로젝트 보고를 위한 번역 서비스

④ 계획된 의사소통간의 정보요구에 대한 응답을 피하기 위한 정보 분배 일정계획의 수립 및 실행

 

해설:  ②번

다국적 프로젝트를 수행하는 경우 프로젝트 관리자는 특히 효과적으로 의사소통하기 위한 방안 마련에 힘써야 하며, 인적 자원 관리 측면에서 문화적 차이를 고려하여 한다.

 

의사소통 관리

  • 프로젝트 정보의 생성, 수집, 배포, 저장, 검색 그리고 최종 처리가 적시에 적절히 수행되도록 하기 위해 필요한 프로세스를 포함함
  • 프로젝트 관리자는 대부분의 시간을 팀원, 조직 내부(조직의 모든 계층) 또는 외부의 기타 프로젝트 이해관계자들과 의사소통하는 데 소요함
  • 효과적인 의사소통은 프로젝트와 관련된 다양한 이해관계자들 사이에 연계를 형성하고, 다양한 문화적, 조직적 배경, 여러 수준의 전문성, 프로젝트 실행 또는 결과물에 대한 다양한 관점 및 이해사항들을 연결할 수 있음

 

순서

프로세스

설명

1

이해관계자 식별

프로젝트의 영향을 받는 모든 사람 혹은 조직을 식별하여 각각의 이해사항, 관여도, 프로젝트의 성공에 미치는 영향력에 관한 정보를 문서화하는 프로세스

2

의사소통 계획수립

프로젝트 이해관계자의 정보 요구사항을 식별하고 의사소통 방식을 정의하는 프로세스

3

정보 배포

프로젝트 이해관계자에게 계획된 대로 관련 정보를 제공하는 프로세스

4

이해관계자 기대사항 관리

이해관계자들과 의사소통 및 협력을 통해 이해관계자의 요구사항을 충족시키고 발생하는 이슈를 처리하는 프로세스

5

성과 보고

현황 보고서, 진척 측정치, 예측치 등의 성과 정보를 수집하고 배포하는 프로세스

 

 

 

5회 18번) 다음 중 팀의 원활한 의사소통을 위해 프로젝트 관리자가 취한 행동 중 적절하지 않은 것은?

 

① 자유로운 의사소통 분위기를 조성하기 위해 되도록 팀원끼리 대화를 통해 문제를 해결하도록 하였다.

② 객체지향 시스템을 설계하기 위해 UML을 이용하여 모델을 작성하도록 규정하였다.

③ 팀의 기본 규칙으로 회의를 통해 문제를 해결하고 회의에 반드시 참여할 것을 규정하였다.

④ 팀 구성원 모두가 공통의 어휘와 개념을 숙지하도록 HTML 용어집을 작성 하여 누구나 열람할 수 있게 하였다.

 

해설:  ①번

팀의 기본 규칙은 프로젝트 팀원들이 수용할 수 있는 행동과 관련하여 명확한 기대사항을 설정한다. 초기부터 명확한 지침을 준수함으로써 오해를 줄이고 생산성을 높일 수 있다.

원활한 의사소통을 위해 프로젝트 관리자는 다양한 계층과 다양한 방법으로 의사소통이 이루어지도록 해야 함

 

 

8회 18번) “홍길동”씨는 진행 중인 프로젝트의 새로운 관리자로 임명되었다. 정기적으로 프로젝트 현황회의를 개최하고, 또한 각종 현황 보고서를 작성하여 배포하려 한다. 이러한 활동을 수행하기 위해서는 어떤 문서를 참고하여야 하는가?

 

① 성과 보고 절차서

② 기록 관리 시스템

③ 의사소통관리 계획

④ 프로젝트 charter

 

해설:  ③번

 

의사소통 관리 - 의사소통 계획 수립 프로세스

  • 프로젝트 관리 계획서에 포함되거나 별도의 보조 계획서로 존재함
  • 이해관계자들의 정보 및 의사소통 필요를 식별한다
  • 이해관계자의 정보 필요성을 식별하고, 필요성에 부합하는 적합한 방법을 결정하는 것이 프로젝트 성공의 중요한 요소임

 

의사소통 관리 계획서

  • 프로젝트 관리 계획서에 포함되거나 별도의 보조 계획서로 존재함
  • 이해관계자 의사소통 요구사항
  • 언어, 형상, 내용, 상세 수준을 포함하여 전달할 정보
  • 정보의 배포 사유
  • 필요한 정보의 배포 시간대 및 주기
  • 정보 전달을 책임지는 담당자
  • 기밀 정보 공개의 승인을 담당하는 책임자
  • 정보를 수신할 개인 또는 그룹
  • 하부 직급에서는 해결할 수 없는 이슈의 상부 보고에 관한 시간대 및 관리진을 식별할 수 있는 상부 보고 프로세스

 

 

4회 5번) 늦어지고 있는 소프트웨어 개발 프로젝트에 더 많은 인원을 투입하면 일반적으로 프로젝트가 더 지체되는 경향의 주된 원인은?

 

① 일정 마감 일에 대한 중압감 때문에

② 기존 인원과 신규 투입 인원의 갈등 때문에

③ 원래 프로젝트의 구현 가능성이 희박하기 때문에

④ 투입된 인원의 업무에 대한 커뮤니케이션이 필요하기 때문에

 

해설:  ④번

개발자를 추가할수록 의사소통 비용이 증가하며 의사소통 오류로 인한 재작업 등으로 프로젝트가 더 지연되는 현상을 겪게 됨 → 브룩스의 법칙

 

브룩스의 법칙(Brook’s Law)

  • 지연되는 프로젝트에 인력을 더 투입하면 오히려 더 늦어진다.”
  • “1 개발자 * 12 개월 == 12 개발자 * 1 개월” 이 아니다
  • 개발자를 추가하면 할수록 그들 사이에 미팅, 인터페이스 합의, 이메일 송수신 등과 같은 커뮤니케이션 비용이 월등히 증가하며, 커뮤니케이션 오류로 일이 잘못 진행되는 경우도 빈번히 생기며 그럴 때마다 원상태로 수정하는 추가 작업들이 발생함
  • 이런 요인으로 추가 인력이 투입될수록 프로젝트가 지연되는 현상을 겪게 됨
  • 전문적으로 말하면, 개발자가 N명이라면 N만큼 개발자가 일하는 양이 늘어나지만 N의 제곱만큼 프로젝트가 복잡해지기 때문에 결국 시간 내에 일을 끝낼 수 없다
  • 따라서 지연되는 프로젝트를 원래 스케줄대로 진행하려면 인력을 더 추가하는 것이 아니라 “개발하기로 약속했지만 아직 완성되지 못한 기능”을 없애는 것이 합리적인 방법이며 프로젝트의 범위(scope)를 조절함으로써 스케줄을 제어해야 한다고 주장함

 

 

 

5회 9번) 프로젝트에서 현재 5명인 팀원이 10명으로 증가하는 경우 증가되는 의사소통 라인 수는 몇 개인가?

 

① 30 개             ②35개                ③40개                ④45개

 

해설:  ②번

현재 의사소통 라인 수 = 5 * (5 - 1) / 2 = 10개

향후 의사소통 라인 수 = 10 * (10 - 1) / 2 = 45개

증가되는 의사소통 라인 수 = 45 – 10 = 35개

 

의사소통 라인 수 = N (N - 1) / 2

N명의 사람이 의사소통을 한다고 가정할 때, 나를 제외한 모든 사람과 의사소통 라인수가 만들어 질 수 있으므로 최대 N * (N-1)개의 의사소통 라인이 만들어 진다.

중복된 라인을 제거하면 N명의 의사소통 라인 수는 N * (N-1) /2 의 공식이 성립한다.

 

 

6회 21번) 회사의 관광길라잡이 홈페이지 구축 프로젝트는 A 초기에3명이 투입되어 작업을 하였으나, 중간 감리결과, 사업관리 및 품질보증활동 부문에 일정 지연 등으로 "우선개선" 판정을 받아서 3명을 추가 투입하여 6명이 일하기로 했다. 이 경우 초기에 비하여 의사소통라인은 몇 배 증가했는가?

 

① 2배                                          ② 3배

③ 4배                                           ④ 5배

 

해설:  ④번

초기 의사소통 라인 수 = 3 * (3 - 1) / 2 = 3개

현재 의사소통 라인 수 = 6 * (6 - 1) / 2 = 15개

의사소통 라인 수는 초기 대비 5배 증가됨

 

 

9회 9번) 프로젝트 팀 내의 공식적인 계통과 수직적인 경로를 통해서 의사전달이 이루어지므로 명령과 권한의 체계가 명확한 공식적인 조직에서 주로 사용 되는 의사소통 네트워크는?

 

① Y자형 네트워크(Y-Network)                  ② 바퀴형 네트워크(Wheel Network)

③ 연쇄형 네트워크(Chain Network)            ④ 원형 네트워크(Circle Network)

 

해설:  ③번

쇠사슬형은 공식적인 명령계통에 따라 의사소통이 상위계층에서 하위계층으로만 흐르는 경우이며, 구성원들 간에 엄격한 권한의 계층관계가 존재하며 의사결정의 속도는 빠르나 구성원들의 만족도가 낮은 의사소통 네트워크임

 

1) 의사소통망 형태

구분

개념

그림

쇠사슬형

(직선형)

  • 공식적인 명령계통에 따라 의사소통이 상위계층에서 하위계층으로만 흐르는 경우이다
  • 구성원들 간에 엄격한 권한의 계층관계가 존재하며 의사결정의 속도는 빠르나 구성원들의 만족도가 낮다
  • 정보가 계층의 단계를 따라 아래로 전달되는 과정에서 왜곡될 소지를 내포하고 있다.

 

UNI00000af81615

원형

  • 권한의 계층관계가 형성되어 있지 않고 중심인물도 없는 상황에서 나타날 수 있는 형태이다 예: 위원회의 의사소통
  • 권한이 어느 한 쪽에 집중되어 있지 않아서 문제해결이 느린 편이지만 구성원의 민족도는 일반적으로 높다

 

UNI00000af8161d

수레바퀴형

  • 구성원들 간에 중심인물이 있어 그에게 모든 정보가 집중되는 형태임
  • 정보를 신속하게 획득, 정학하게 문제해결에 대응 가능함
  • 단순업무의 경우 의사소통의 속도와 정확성을 기할 수 있으나 복잡한 업무의 경우 효과를 기대하기 어렵고 구성원들의 만족도 낮음

 

UNI00000af81619

별형

(상호연결형)

(전체경로형)

  • 비공식적 의사소통의 형태이다.
  • 특정 중심인물이 없고 구성원 개개인이 서로 의사소통을 주도한다.
  • 상황 파악과 문제해결에 시간이 많이 소요되나 구성원들의 참여로 창의적으로 문제를 해결하고자 할 때 효과적

 

UNI00000af81621

Y

  • 1인의 전달자가 2인에게, 혹은 2인의 전달자가 1인에게 의사소통을 하는 경우

 

2) 의사소통망 형태별 의사소통의 효율성

기준

의사소통망

쇠사슬형

수레바퀴형

원형

상호연결형

의사소통의 속도

중간

빠름

빠름

빠름

의사소통의 정확도

높음

높음

중간

중간

리더에의 권한집중

보통

높음

낮음

극히 낮음

구성원 만족도

보통

낮음

높음

높음

 

 

4회 7번) 사용자나 업무 요구사항의 변화에 대비하여 프로토타이핑 등을 이용하면서 시스템 개발 일정을 단축하며 점진적으로 개발 및 확장하는 방법은?

 

① 프로세스 중심의 개발 ② 객체지향 개발

③ 업무프로세스 재공학(BPR)        ④ 고속응용개발(RAD)

 

해설:  ④번

RAD는 GUI 중심의 개발 툴을 이용해서 반복적으로 최종 시스템을 확장시켜 나감

 

6회 4번) 컴포넌트기반(Component Based) 방법에 의한 소프트웨어 프로젝트에서 품질측정을 위한 측정지표로 바람직하지 않은 것은?

 

① 컴포넌트들 간의 응집도(Cohesion)

② 컴포넌트들 간의 결합도(Coupling)

③ 컴포넌트의 기능(Function)에 대한 이해용이성(Understandability)

④ 컴포넌트 변경에 대한 용이성 정도(Adaptability)

 

해설:  ①번

CBD 방법론은 소프트웨어를 느슨한 결합도를 갖는 조립 가능한 컴포넌트 단위로 만들어 재사용성을 높이는 목적을 갖고 있다. 기 개발된 컴포넌트의 재사용에 대한 품질 측정지표로 컴포넌트의 이해용이성(component’s understandability), 적응성(adaptability), 이식성(and portability)를 적용할 수 있다.

 

 

5회 3번) 소프트웨어 제품품질에 대한 대표적인 모델인 ISO/IEC 9126에서 정의하고 있는 6가지 품질특성에 속하지 않는 것은?

 

① 기능성            ② 신뢰성            ③ 재사용성        ④ 유지보수성

 

해설:  ③번

ISO/IEC 9126 품질특성 기신사효유이(기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성)

 

9회 14번) "ISO/IEC 9126 소프트웨어 품질체계"의 품질특성인 신뢰성(Reliability)의 품질 부특성에 속하지 않는 것은?

 

① 성숙성(Maturity)                        ② 결함 허용성(Fault Tolerance)

③ 회복성(Recoverability)              ④ 정확성(Accuracy)

 

해설:  ④            번

정확성은 ISP 9126 소프트웨어 품질체계의 품질특성인 기능성의 품질 부특성에 속함

 

10회 17번) XP(eXtreme Programming)에서 프로젝트의 규모를 파악하고 프로젝트 범위를 추정하기 위해 사용하는 기본 자료는 무엇인가?

 

① 반복 횟수

② 작은 배포의 개수

③ 소스 코드의 크기

④ 스토리 카드

 

해설:  ④번

XP는 스토리를 바탕으로 개발 계획을 수립한다.

스토리 카드는 2주 동안 구현할 정도의 크기의 시스템 기능 단위이다.

 

 

4회 11번) 통계적 품질보증의 방법으로 소프트웨어의 신뢰성을 추정하고자 한다.

MTBF(Mean Time Between Failure)를 신뢰성이라고 할 때, 다음 보기에 대한 MTBF는 얼마인가?

ATP(Average Time Process) = 30분

MTTF(Mean Time To Failure) = 60분

MTTR(Mean Time To Recovery) = 3분

 

① 33분

② 63분

③ 87분

④ 93분

 

해설:  ②번

MTBF = MTTF + MTTR = 60 + 3 = 63분

 

소프트웨어 신뢰도 측정은 평균 고장 간격(Mean Time Between Failure: MTBF)으로 표시함

MTBF = MTTF + MTTR

Availability = MTTF / (MTTF + MTTR)

 

평균 고장 간격(Mean Time Between Failure: MTBF)

  • 수리할 수 있는 설비의 고장에서부터 다음 고장까지의 동작 시간의 평균치

 

평균 고장 수명(Mean Time to Failure: MTTF)

  • 수리하지 않는 부품 등의 사용 시작으로부터 고장 날 때까지의 동작 시간의 평균치
  • 한번 고장 난 후 다음 고장이 날 떄까지 평균적으로 얼마나 걸리는지를 나타냄
  • MTTF(Mean Time to Failure)는 고장까지의 평균시간으로 이는 수리 불가능한 경우에 해당되며, 수리가능한 경우에는 MTBF(Mean Time Between Failure)의 평균 고장 간격시간으로 표현됨. 수리 가능과 불가능의 경우를 나누어 표현은 하되 같은 개념으로 사용되므로 주의 필요함

 

평균 수리 시간(Mean Time to Repair: MTTR)

  • 수리 시간의 평균치
  • MTBF와 MTTF와 함께 고장을 분석하고 그 원인을 찾아내며, 신뢰성을 추정하는데 아주 중요하고 많이 활동되어지는 개념으로 MTBF, MTTF는 길수록 MTTR은 짧을수록 우수한 장비의 척도가 된다

 

 

4회 19번) 개발기간 동안에 생성되는 문서들에 적용되는 문서표준과 가장 거리가 먼 것은?

 

① 문서 식별표준                           ② 문서 구조표준

③ 문서 교환표준                           ④ 문서 갱신표준

해설:  ③번

문서 표준에는 문서 식별 표준, 문서 구조 표준, 문서 표현 표준, 문서 수정 표준이 있다

 

1) 문서화 프로세스 표준

  • 어떻게 문서가 개발되고, 검증되고, 유지되는 지에 관한 사항

구분

설명

문서 표준

문서의 내용, 구조, 외형에 대한 사항

문서 교환 표준

전자 문서의 이식성에 대한 사항

 

2) 문서 표준

  • 문서 식별 표준: 문서를 어떻게 식별하는가?
  • 문서 구조 표준: 프로젝트 문서에 대한 표준 구조
  • 문서 표현 표준: 폰트, 스타일, 로고등에 대한 정의
  • 문서 수정 표준: 앞 버전으로부터의 수정을 어떻게 문서에 반영할 것인가를 정의

 

3) 문서 교환 표준

  • 교환 표준은 전자 문서나 우편으로 교환하는 것을 가능하게 한다.
  • 문서는 다른 시스템과 컴퓨터에서 생산된다. 표준화 도구가 사용된다고 하더라도, 스타일 종이와 매크로에 대한 방법을 정의하는 것이 필요하다.
  • 저장에 대한 필요. 문서편집기 시스템의 수명이 문서화하려고 하는 소프트웨어보다 짧기 때문에 미래에 다시 사용할 수 있도록 기록/보관을 위한 표준이 필요하다.

 

※ 문서화 프로세스

  • ISO/IEC 12207 또는 공공부문 SW사업 발주Ÿ관리 표준 프로세스 중 지원 수명주기 프로세스에 속함
  • 다른 수명주기 프로세스나 활동에 의하여 생산되는 정보를 기록하는 프로세스이다.
  • 시스템 혹은 소프트웨어 산출물과 관련한 모든 관련자가 필요로 하는 문서에 대한 계획, 설계, 개발, 생산, 편집, 배포, 유지하는 활동을 포함한다.
  • 활동: 문서화 준비 → 문서화 표준 개발 → 문서 생산 및 배포 → 문서 유지보수

 

 

5회 16번) 소프트웨어 측정(Measurement)에 사용하는 척도(Metrics)에 대한 설명으로 틀린 것은?

 

① Line of Code(LOC)는 프로그래밍 언어에 따라 크기가 가변적이다.

② Function Point는 사용자 입력, 사용자 출력, 사용자 질의, 파일, 외부 인터페이스 개수를 활용한다.

③ Feature Point는 Function Point의 측정항목 외에 데이터베이스 항목을 추가하여 측정한다.

④ Function Point는 프로그래밍 언어에 독립적으로 측정할 수 있다.

 

해설:  ③번

 

소프트웨어 규모 측정방식

구분

LOC (Line of Code)

FP(Function Point)

특징

  • 크기 중심 매트릭스
  • 소스코드 라인수를 중심으로 측정
  • 소스코드 라인수가 클수록 복잡도, 개발기간, 개발비용이 증가함
  • 기능 중심 매트릭스
  • 프로그램의 기능 수와 복잡도에 따른 점수를 계산
  • FP값이 클수록 복잡도, 개발기간, 개발비용도 비례하여 증가함

장점

  • 쉽게 측정할 수 있다
  • 많은 측정 모델이 LOC를 중요한 입력 값으로 사용함
  • 프로그래밍 언어에 독립적

단점

  • 프로그래밍 언어에 따라 크기가 가변적이다
  • 계산이 주관적인 자료를 바탕으로 함
  • 물리적인 의미가 없음

 

※ Feature Point

  • Function Point는 일반적인 정보시스템을 다루는 데에는 문제가 없으나, input, output의 개수는 적으나 복잡도가 매우 높은 알고리즘을 사용하기 시스템에 대하여는 잘못된 결과를 도출할 확률이 높다

ex) real-time systems, operating systems, process control systems 등

  • 이러한 한계를 극복하기 위하여 feature point가 제안됨
  • 기본적으로 function point와 같은 방식이지만, 5가지 측정항목 외에 algorithms을 추가하고 복잡도 값을 평균값(weighting factor)으로 3을 부여하였음
  • 기존의 측정항목에 대한 복잡도 값을 조정하였음

 

 

5회 25번) 컴포넌트 기반 시스템 개발을 계획하면서 재사용 컴포넌트의 획득을 검토할 때 올바른 판단이 아닌 것은?

 

① 범위정의 프로세스에서 재사용 컴포넌트를 제작할지 혹은 구매할지 결정한다.

② 조직의 능력을 고려하여 제작-구매를 결정한 후 조달 계획을 세운다.

③ 제작-구매는 제작 비용과 구매 비용을 비교하여 적게 드는 것으로 결정한다.

④ 수행조직 내의 전문가 그룹이나 컨설턴트의 판단을 기반으로 제작-구매를 결정한다.

 

해설:  ③번

컴포넌트 기반 시스템 개발을 계획하면서 기업들은 컴포넌트를 나름대로 제작하거나 이미 잘 개발되어진 컴포넌트를 재사용하여 자체 프로젝트에 재활용함으로써 최대의 기능과 신속한 개발로 소프트웨어의 품질과 생산성 향상을 높이고 시스템 유지보수 비용 최소화함

재사용 컴포넌트 획득을 검토할 때는 조직, 기능, 비용 등 다각적으로 고려하여 결정함

 

 

조달관리

  • 작업 수행에 필요한 제품, 서비스 또는 결과물을 프로젝트 팀 외부로부터 구매하거나 획득하기 위해 필요한 프로세스들을 포함함
  • 권한을 승인받은 프로젝트 팀원이 발행하는 계약서 또는 구매 주문서를 작성하고 관리하기 위해 필요한 계약관리 및 변경 통제 프로세스가 포함됨

 

순서

프로세스

설명

1

조달 계획수립

  • 프로젝트 구매 결정사항을 문서화하고, 조달 방식을 규정하며, 잠재적인 판매자를 식별하는 프로세스
  • 프로젝트 조직 외부에서 제품, 서비스 또는 결과를 구매하거나 획득함으로써 최대로 충족될 수 있는 프로젝트 요구와, 프로젝트 실행 중에 프로젝트팀에서 성취할 수 있는 프로젝트 요구를 식별
  • 획득 여부, 획득 방법, 획득 대상, 획득량 및 획득 시기를 고려

2

조달 수행

대상 판매자를 모집하고, 판매자를 선정하며, 계약을 체결하는 프로세스

3

조달 관리

조달 관계를 관리하고, 계약의 이행을 감시하며, 필요한 변경 및 수정을 수행하는 프로세스

4

조달 종료

각 프로젝트 조달을 완료하는 프로세스

 

 

 

9회 18번) 개발자가 사용자와 협력하여 요구사항을 구체화하기 위하여 사용되는 기법 중에 아이디어 축약(Idea Reduction) 기법을 활용할 수 있다. 아이디어 축약의 진행순서는?

 

① 우선순서 정하기 → 가지치기 → 아이디어 묶기 → 특징정의

② 아이디어 묶기 → 특징정의 → 우선순서 정하기 → 가지치기

③ 우선순서 정하기 → 아이디어 묶기 → 가지치기 → 특징정의

④ 가지치기 → 아이디어 묶기 → 특징정의 → 우선순서 정하기

 

해설:  ④번

아이디어 축약은 Pruning Ideas → Grouping Ideas → Defining Features → Prioritizing Ideas 과정을 통해 이루어짐

 

아이디어 축약(Idea Reduction)

  • 브레인스토밍 등을 통해 아이디어 생성이 끝난 후에는 아이디어 축약이 시작된다.

 

1) Pruning Ideas

  • 더 이상 논의할 가치가 없는 아이디어를 제거함
  • 촉진자는 참석자에게 각 아이디어가 더 논의할 가치가 있는지를 물어보고 유효하지 않은 아이디어를 제거한다

2) Grouping Ideas

  • 유사한 아이디어를 그룹핑하고, 관련된 아이디어 그룹에 이름을 붙임

ex) 새로운 기술, 성능이슈, 현재 기능 강화, 사용자 인터페이스 등

3) Defining Features

  • 촉진자는 각 아이디어를 검토하고 아이디어 제공자에게 한 문장 설명을 요청함
  • 이 과정을 통해 아이디어 특징을 상세화하고 참석자들이 해당 아이디어에 대해 공통의 이해를 갖게 된다

4) Prioritizing Ideas

  • 우선순위를 정한다.
  • 우선순위는 투표와 Critical/Important/Useful 등 분류를 통해 수행될 수 있음

댓글