연관관계, 의존관계, 일반화(Generalization), 실체화(Realization)

중 UML의 관계(Relationship) 의존관계, 연관관계, 일반화(Generalization), 실체화(Realization)
연의GR
토픽 이름(상) 관계(Relationship)
분류 소프트웨어 >UML> Usecase diagram
키워드(암기) 연관관계, 의존관계, 일반화(Generalization), 실체화(Realization)
암기법(해당경우) 연의 GR

 

기출문제

번호 문제 회차
1 6.아래 시나리오를 기반으로 고객과 점주가 사용하는 주문 시스템에 대한 Use Case Diagram을 작성하시오 가. 고객은 주문 시스템을 통해 가격을 조회하고 주문할 수 있다. 나. 고객은 주문 시스템을 통해 주문 상태를 확인하고 주문을 취소할 수 있다. 다. 점주는 주문 시스템을 통해 주문 활동을 모니터링하고 창고를 관리할 수 있다. 라. 회계 시스템은 주문 시스템과 연동하여 주문이나 취소 처리할 수 있다. 122관3
2 6. UML(Unified Modeling Language)에서 사용하는 행위 다이어그램(behavior diagram) 인 액티비티 다이어그램(activity diagram), 스테이트 다이어그램(state diagram), 그리고 유스케이스 다이어그램(use-case diagram)에 대하여 설명한 후, 레스토랑에서 일어나는 상황을 고객, 웨이터, 요리사, 그리고 계산대 직원을 고려하여 유스케이스 다이어그램으로 표현하시오. 93회_관리_3교시
4 3. 객체지향 모델의 표현 방법인 UML(Unified Modeling Language)을 사용하여 "수강신청 처리"에 대한 시스템을 설계하시오.
반드시 유스케이스 다이어그램(use-case diagram), 시퀀스 다이어그램(sequence diagram), 클래스 다이어그램(class diagram),
액티비티 다이어그램(activity diagram)을 작성하고, 필요시 다른 diagram을 추가 작성하시오.		 86_관리_3
5 1. 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 유스케이스 다이어그램에 대하여 아래의 물음에 답하시오.
가. 유스케이스 다이어그램에 대한 설명
나. 예제의 요구사항에 대하여 유스케이스 다이어그램으로 작성		 모의_2018.12_관리_3
6 1. 유스케이스 다이어그램(usecase diagram)에 대하여 설명하시오 모의_2018.07_관리_1

 

 

I. UML의 관계(Relationship) – ‘연의 GR’ 이라고 암기한다. ★

- UML에는 4개의 관계가 있다. 연관관계, 의존관계, 일반화(Generalization), 실체화(Realization) 이다.

 

 

 

 

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

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

Usecase diagram  (0) 2024.04.06
Class diagram  (0) 2024.04.05
UML / Diagram 전체  (0) 2024.04.03
MSA  (0) 2024.04.02
SW Architecture 평가  (0) 2024.04.01
상 UML / Diagram 전체 전체 다이어그램 구분 정리
[구조 기반] 클래스(Class) Diagram, 컴포넌트(Component) Diagram, 객체(Object) Diagram, 배치(Deployment) Diagram, Composite Structure  Diagram, Package
Diagram, Profile Diagram
[ 행위 기반 다이어 그램] 활동(Activity), 유즈케이스(Use Case), 상태(State) 상호작용 다이어그램(Interaction Diagram), 순차(Sequence)다이어그램, Communication
Diagram, 상호작용 개요다이어그램(Interaction Overview Diagram), Timing Diagram		 itpe 특강 볼것  
토픽 이름(상) UML / Diagram
분류 소프트웨어 >UML> Diagram
키워드(암기) [구조 기반] 클래스(Class) Diagram, 컴포넌트(Component) Diagram, 객체(Object) Diagram, 배치(Deployment) Diagram, Composite Structure  Diagram, Package
Diagram, Profile Diagram
[ 행위 기반 다이어 그램] 활동(Activity), 유즈케이스(Use Case), 상태(State) 상호작용 다이어그램(Interaction Diagram), 순차(Sequence)다이어그램, Communication
Diagram, 상호작용 개요다이어그램(Interaction Overview Diagram), Timing Diagram
암기법(해당경우)  

기출문제

번호 문제 회차
1 6.아래 시나리오를 기반으로 고객과 점주가 사용하는 주문 시스템에 대한 Use Case Diagram을 작성하시오 가. 고객은 주문 시스템을 통해 가격을 조회하고 주문할 수 있다. 나. 고객은 주문 시스템을 통해 주문 상태를 확인하고 주문을 취소할 수 있다. 다. 점주는 주문 시스템을 통해 주문 활동을 모니터링하고 창고를 관리할 수 있다. 라. 회계 시스템은 주문 시스템과 연동하여 주문이나 취소 처리할 수 있다. 122관3
2 6. UML(Unified Modeling Language)에서 사용하는 행위 다이어그램(behavior diagram) 인 액티비티 다이어그램(activity diagram), 스테이트 다이어그램(state diagram), 그리고 유스케이스 다이어그램(use-case diagram)에 대하여 설명한 후, 레스토랑에서 일어나는 상황을 고객, 웨이터, 요리사, 그리고 계산대 직원을 고려하여 유스케이스 다이어그램으로 표현하시오. 93회_관리_3교시
4 3. 객체지향 모델의 표현 방법인 UML(Unified Modeling Language)을 사용하여 "수강신청 처리"에 대한 시스템을 설계하시오.
반드시 유스케이스 다이어그램(use-case diagram), 시퀀스 다이어그램(sequence diagram), 클래스 다이어그램(class diagram),
액티비티 다이어그램(activity diagram)을 작성하고, 필요시 다른 diagram을 추가 작성하시오.		 86_관리_3
5 1. 시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 유스케이스 다이어그램에 대하여 아래의 물음에 답하시오.
가. 유스케이스 다이어그램에 대한 설명
나. 예제의 요구사항에 대하여 유스케이스 다이어그램으로 작성		 모의_2018.12_관리_3
6 1. 유스케이스 다이어그램(usecase diagram)에 대하여 설명하시오 모의_2018.07_관리_1

 

 

I. 객체지향 모델링 기술과 방법론의 표준, UML의 개요 – 그래픽 형태를 통한 객체지향 설계 설명 도구

   가. UML(Unified Modeling Language)의 정의

      - 객체 지향 분석/설계가 S/W공학의 새로운 추세로 자리매김함에 따라 관련된 방법론을 표준화할

         필요성을 느끼고 OMG(Object Management Group – UML, MDA를 제정한 협회)에서 객체

        모델링 기술과 방법론을 표준화 한 것으로 단어자체가 의미하는 언어가 아니고 모델링을

        위한 Notation을 말함 

 

   나. UML의 등장 배경 및 필요성

      - 객체지향 모델링을 위해 학자들 마다 중복되고 일부 다른 방식으로 표현,

      - 보다 체계적인 모델링 방법을 표준화하기 위해 3명의 학자가 주장하는 표기법의 통일이 필요하게 됨

      - 객체지향 시스템 개발 전 과정(Life Cycle)에서 개발자와 사용자간에 표준화된 의사소통 방식 필요

      - 자기 자신, 팀 동료, 고객들과의 의사소통 – 자신의 이해가 다른 사람과 일치하는지 확인하기 위한

        방법(1994년, 부치, 럼바, 야콥슨 연구시작 -> 1997년 발표)

 

가. 정적 다이어그램

구분 분  류 내  용
정적
모델링
(정적인부분/
구조모델링)		 클래스(Class) Diagram - 시스템 내 클래스들의 정적 구조를 표현
- 클래스는 객체들의 집합으로 속성(Attribute)과 동작(Behavior)으로 구성됨.

컴포넌트(Component)
Diagram		 - 코드 컴포넌트(Code component)에 바탕을 둔 코드의 물리적 구조를 표현
- 컴포넌트(component)는 논리적 클래스 혹은 클래스 자신의 구현에 대한 정보를 포함함.
- 실질적인 프로그래밍 작업에 사용함.

객체(Object) Diagram - 클래스의 여러 Object 인스턴스(Instance)를 나타내는 대신에 실제 클래스를 사용함.
- 클래스 다이어그램에서 2가지 예외를 제외하고 동일 표기법을 사용함.
- Object 이름에 밑줄 표시를 하며, 관계 있는 모든 인스턴스를 표현함.

배치
(Deployment)
Diagram		 - 시스템 하드웨어와 소프트웨어간의 물리적 구조를 표현하며, 실질적인 컴퓨터와
  Device간의 관계를 표현하는데 이용함.
  컴포넌트(Component) 사이의 종속성을 표현함.

Composite
Structure
Diagram		 - 분류자의 복합 구조를 표현하는 다이어그램
- port, part, connector, Collaboration으로 분류자 내부 구조 표현

Package
Diagram		 - 패키지들과 패키지 내부의 요소를 표현
- 클래스, 인터페이스 등 분류자 등을 그룹화하여 보여 주기 위함

Profile
Diagram		 profile diagrams are: profile, metaclass, stereotype, extension, reference, profile application.(우리가 프로파일을 말할 때와 같은 의미로 사용)

 

나. 동적다이어그램

구분 분  류 내  용
동적
모델링
(행위 다이어그램)		 활동
(Activity)		 - 행위(Activity)의 순서적 흐름을 표시함.
- 연산자로 수행된 활동 상황(Activity)을 설명키 위해 사용함.

유즈케이스
(Use Case)		 - 외부 행위자(Actor)와 시스템이 제공하는 여러 개의 Use Case(시스템을 사용
하는 다양한 경우에 연결하여, Use Case 다이어그램은 유즈케이스 뷰를 다룬다.

상태(State) - 클래스의 객체가 가질 수 있는 모든 가능한 상태를 나타냄.

상호작용 다이어그램(Interaction Diagram) 4개의 다이어그램을 통합한 그룹 /*시퀀스, 커, 인, 타 */
- 행동 다이어그램의 서브(하위) 집합인 상호 작용 다이어그램은 모델링되는 시스템에서 사물 간의 제어 및 데이터의 흐름을 강조함.

순차
(Sequence)
다이어그램		 - 여러 객체 사이에 동적인 협력 사항을 표현함.
- 오브젝트(Object) 사이에 메시지를 보내는 순서를 보여주기 위해 사용함.
- 수직선상의 여러 object로 구성되어 시간 혹은 순서가 강조되어야 할     경우 이용함.

Communication
Diagram		 - UML1.x의 Collaboration Diagram에서 변경됨
- A communication diagram is an extension of object diagram that shows the objects along with the messages that travel from one to another.
(Example – Hotel Reservation)

상호작용 개요
다이어그램(Interaction Overview Diagram) 		액티비티 다이어그램과 시퀀스 다이어그램의 혼합된 다이어그램 ★★★
1) 활동 다이어그램과 유사 -> 차이점: 상호작용 개요 다이어그램의 경우는 각 개별 활동이 중첩된 상호 작용 다이어그램으로 포함할 수 있는 특징이 있다.
   -> 복잡한 시나리오를 분해하는데에 유리함

Timing Diagram - 시간의 흐름에 따른 상태를 표현
- 가로 축 시간 표현, 세로 축에 상태로 하여 상태 변화를 나타냄
반응형
저작자표시 비영리 변경금지

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

Class diagram  (0) 2024.04.05
UML의 관계(Relationship)  (0) 2024.04.04
MSA  (0) 2024.04.02
SW Architecture 평가  (0) 2024.04.01
ISO/IEC/IEEE 42010  (1) 2024.03.31
MSA 상 MSA [정의] 대규모 분산 웹 환경에서 응용 소프트웨어를 독립적으로 배치 가능한 서비스 조합으로
설계하는 아키텍쳐
[특징] 사상: 리액티브 시스템 [디자인패턴] observer패턴, circuit breaker 패턴
[구조] 서비스 컴포넌트화(fine grained, loosely coupled), 분산거버넌스(polyglot),
분산데이터(vertical slicing), End point 통합(API GW, Orchestraion),
비즈니스 연계(Cross functional Team)		 SPOF 방지 구현을 위해 다수의 API GW 구성가능
API GW, LB, Conway's Law, SOA, DevOps, Docker,
DDD, EDA, Agile
마이크로서비스/모노리틱
토픽 이름 MSA(Micro Service Architecture)
분류 SW > SW Architecture > MSA(Micro Service Architecture)
키워드(암기) API Gateway, Orchestration REST API, Persistent, DevOps,
DDD(Domain Driven Design; 도메인 주도 설계),
Polyglot(폴리글랏): 크로스 플랫폼 적인 데이터 교환를 의미함.
콘웨이의 법칙(Conway’s Law)
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 마이크로 서비스 아키텍처(Micro Service Architecture) 관리 117회 1교시 6번

 

I.  MSA(Micro Service Architecture)개요.

 - 하나의 큰 애플리케이션을 여러 개의 작은 마이크로 서비스 단위로 나누어 변경과 조합이 가능하도록 만든 아키텍처

 

II. 개념도 및 기술요소

 가. 개념도(둘 중 하나 취사선택)

 

 

OR

 

 

나. 구성요소

 

- 대용량 웹 서비스 개발에 적합하게 작은 서비스의 결합을 통해 하나의 응용프로그램을 개발하는 SOA를 근간으로 한 서비스 아키텍처

 

III. 마이크로 서비스 아키텍처와 모놀리식 아키텍처 비교

[추가자료] 마이크로 서비스 아키텍처와 SOA(Service Oriented Architecture) 비교

 

 

[참고] 콘웨이(Conway)의 법칙

•1967년 프로그래머 멜빈 콘웨이가 제안한 법칙

•시스템 구조는 설계하는 조직의 커뮤니케이션 구조를 닮게 된다.

•모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다(닮는다는 의미임).

•조직의 구조가 시스템 아키텍처 설계에 영향을 줌

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

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

UML의 관계(Relationship)  (0) 2024.04.04
UML / Diagram 전체  (0) 2024.04.03
SW Architecture 평가  (0) 2024.04.01
ISO/IEC/IEEE 42010  (1) 2024.03.31
명세기반 테스팅 기법  (0) 2024.03.30
상 SW Architecture 평가 [정의] 아키텍처 접근법이 품질속성에 미치는 영향을 판단하고, 아키텍처 적합성을 평가하는 모델
[유형] 시나리오기반, 시뮬레이션기반, 수학적기반, 경험기반
[모델]
시나리오기반(SAAM, ATAM, CBAM, EATAM)
설계혼합기반(ADR, ARID)
 
토픽 이름 (중) SW Architecture 평가
분류 SW > SW Architecture > SW Architecture 평가
키워드(암기) 소프트웨어 아키텍처의 정방향 분석, 소프트웨어 아키텍처의 역방향 분석,
SAAM, CBAM, ATAM, EATAM, ADR, ARID
암기법(해당경우)  

기출문제

번호 문제 회차
1 최근 정부 및 공공기관 소프트웨어 개발 프로젝트에서는 전자정부 표준 공통서비스 및 개발 프레임워크의 적용이 확대되고 있다. 아키텍처 중심의 소프트웨어 개발을 위한 프레임워크 개념과 프레임워크 컴포넌트 구성을 위한 오픈소스 소프트웨어 선정 평가 프로세스에 대하여 설명하시오. 93회_관리_3교시
2 3. 공공부문 EA(Enterprise Architecture) 성과를 평가하는 요소에 대하여 설명하시오. 92회_조직응용_3
3 4. 소프트웨어 아키텍처 평가모델인 ATAM(Architecture Tradeoff Analysis method) 과 CBAM(Cost Benefit Analysis Method)에 대해 프로세스를 중심으로 논하시오. 80회_응용_4
4 6. 소프트웨어 아키텍처 평가모델에 대해 설명하시오. 모의_2019.07_관리_1
5 3. SW 아키텍쳐 분석에 대해 다음 물음에 답하시오.
가. SW 아키텍쳐 분석의 개요
나. SW 아키텍쳐 정방향 분석 및 정방향 분석의 주요 기법인 ATAM
다. SW 아키텍쳐 역방향 분석		 모의_2016.10_관리_2교시
6 SA(Software Architecture) 평가 모델을 분류하고 그 중 ATAM (Architecture Tradeoff Analysis Method), CBAM(Cost Benefit Analysis Method)을 비교하여 설명하시오. 모의_2016.05_관리_2교시
7 SW 아키텍처 평가방법인 ATAM과 CBAM의 평가절차에 대하여 설명하고, CBAM을 기반으로 아래의 사례에 대하여 아키텍처 전략을 선정하시오. 모의_2014.07_공통_2교시
8 소프트웨어 아키텍처 평가방법의 하나인 CBAM(Cost Benefit Analysis Method)의 특징을 설명하고, 평가절차를 상세히 기술하시오. 모의_2013.06_관리_3교시
9 아키텍처 평가방법인 ATAM의 수행단계를 설명하시오. 모의_2012.11_관리_1교시
10 3. SW 아키텍처 평가의 개요, 주요종류 및 수행절차, 기업에 적용 시 문제점과 해결 방안에 대해 기술하시오 모의_2011.12_관리_4교시
11 12. SW 아키텍처 평가의 개념 및 평가 유형을 설명하시오. 합숙_2016.07_관리_1일차
12 CBAM(Cost–Benefit Analysis) 아키텍처 평가방법론을 기반으로 다음의 사례 시나리오를 읽고, 아키텍처 전략을 선정하시오. (가중치와 주어진 업무조건 이외의 내용은 가정하여 제안할 수 있음)
<사례 시나리오>
① POS(Point of Sale) 시스템은 상품에 부착되어있는 바코드를 읽어 들이는 즉시, 재고량이 조정될 수 있고, 소매점 뿐 아니라 대규모 슈퍼마켓으로 확장이 가능
② HA(High Availability)구성을 위해 Heartbeat and cache, Virtual machine, Concurrency 아키텍처 전략 중 하나를 선택하고자 함		 합숙_2012.02_공통_2일차
13 CBAM(Cost–Benefit Analysis) 아키텍처 평가방법론을 기반으로 다음의 사례 시나리오를 읽고, 아키텍처 전략을 선정하시오. (가중치와 주어진 업무조건 이외의 내용은 가정하여 제안할 수 있음)
<사례 시나리오>
① POS(Point of Sale) 시스템은 상품에 부착되어있는 바코드를 읽어 들이는 즉시, 재고량이 조정될 수 있고, 소매점 뿐 아니라 대규모 슈퍼마켓으로 확장이 가능
② HA(High Availability)구성을 위해 Heartbeat and cache, Virtual machine, Concurrency 아키텍처 전략 중 하나를 선택하고자 함		 합숙_2012.02_공통_2일차
14 EATAM(Extending Architecture Tradeoff Analysis Method)을 설명하시오. 합숙_2011.08_공통_2일차
15 SW 아키텍쳐는 설계원칙을 나타내는 상위 수준의 추상화를 의미한다. 이에 따른 요구품질기반 아키텍쳐 수준의 평가방법과 방법론에 대해 논하고, ATAM, CBAM에 대해 설명하시오. 그리고 현재 업무환경에 맞추어 SW 아키텍쳐의 품질평가방법을 제안하고 적용방안을 제시하시오 합숙_2011.02_공통_1일차

 

I. 아키텍처 설계의 검증 방법론, 소프트웨어 아키텍처 평가 개요

가. 소프트웨어 아키텍처 평가의 정의

- 제시된 소프트웨어 아키텍처가 개발될 소프트웨어에 대해서 요구되는 품질 특성을 충족시킬 수 있는지 아키텍처 수준에서 평가하는 절차

 

나. 소프트웨어 아키텍처 평가 방법론 유형

평가유형 내용
Scenario Based
(시나리오 기반)		 - 직접적으로 품질 요소를 위해 미리 정의된 Profile에 의존하여 평가
- 시나리오에 기반하므로 평가 결과도 정밀
- ATAM, SAAM, CBAM 등
Simulation Based
(시뮬레이션 기반)		 - BMT와 같은 시뮬레이션 기반 평가
Mathematical Based
(수학적 기반)		 - 기준 모델을 수치화하고 이를 기초로 평가하는 수학적 기반 모델
Experience Based
(경험 기반)		 - 정량적인 분석이 어려운 경우 적용하는 경험 기반의 평가
- 품질 평가를 위한 정형화된 평가 모델을 갖지 않고 경험을 평가 수단으로 활용

II. 소프트웨어 아키텍처 평가 모델의 관계도 및 상세설명

가. SW아키텍처 평가 모델의 관계도

 

- 일반적으로 ARID와 ADR라는 모듈이나 컴포넌트의 상세 설계 적합성을 검토하는 기법과 함께 사용

 

 

III. 소프트웨어 아키텍처 평가의 기대효과 및 적합성 판단 시 고려사항

가. 소프트웨어 아키텍처 평가의 기대효과

  • 금전적 이익제공, 요구사항의 검증
  • 현재 아키텍처의 문제 조기발견
  • 검토준비의 강제화: 아키텍처의 문서화를 통해 평가 대상자가 적절한 수준의 문서를 획득
  • 논리적 근거 파악: 변경 시 발생할 수 있는 영향 평가
  • 아키텍처 개선: 아키텍처 품질개선

 

나. 소프트웨어 아키텍처 적합성 판단 시 고려사항

  •  아키텍처 평가의 원칙은 아키텍처가 달성해야 하는 목표 식별해 우선순위를 매기는 것.

 -> 이러한 목표들이 아키텍처 적합성을 판단할 수 있는 기준

  •  아키텍처는 한 목표에 대해서는 적합하지만 다른 목표에 대해 적합하지 않을 수 있고 서로 상충 가능
  •  아키텍처 평가는 적합성 판단할 수 있도록 아키텍처 달성 목표에 대해 우선순위 부여하는 과정
반응형
저작자표시 비영리 변경금지

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

UML / Diagram 전체  (0) 2024.04.03
MSA  (0) 2024.04.02
ISO/IEC/IEEE 42010  (1) 2024.03.31
명세기반 테스팅 기법  (0) 2024.03.30
SW Architecture  (0) 2024.03.30
상 ISO/IEC/IEEE 42010
(구 버전 IEEE1471)		 [정의] 시스템, 소프트웨어 및 엔터프라이즈 아키텍처 설명에 대한 요구 사항/표준 용어 정의
[구성요소]
System of Interest,
Architecture,
Stakeholder,
Architecture Description,
Concern,
Architecture Viewpoint(where),
Architecture View(what),
model Kind,
Architecture model,
Architecture Rationale,
Correspondence,
Correspondence Rule
 
토픽 이름 (중) ISO/IEC/IEEE 42010(구 IEEE 1471)
분류 SW > SW Architecture > ISO/IEC/IEEE 42010(구 IEEE 1471)
키워드(암기) System of Interest, Stakeholder, Concerns, Architectural ViewPoint, Model Kind,
Architecture, Architecture description, Architecture View, Architecture Model, Architecture Rationale, Correspondence Rule, Correspondence
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 3. IEEE 1471에 대하여 설명하시오. 98_시스템응용_1
2 아키텍처 표준인 IEEE1471에 대해서 설명하시오 합숙_2012.02_공통_2일차
3 1. IEEE1471 에 대해 설명하시오. 모의_2015.12_응용_1교시
4 아키텍처 표준인 IEEE1471을 설명하고, 소프트웨어 아키텍처의 단계별 산출물과 아키텍처 스타일을 설명하시오. 모의_2009.01_관리_3교시

 

I. SA가 표현해야 하는 내용, 관계정의 표준 프레임워크 ISO/IEC/IEEE 42010(IEEE 1471)의 개요

가. ISO/IEC/IEEE 42010(IEEE 1471)

- 시스템, 소프트웨어 및 엔터프라이즈 아키텍처 설명에 대한 요구 사항/표준 용어 정의

- (목적) 아키텍처를 표현, 전달, 검토하기 위한 개념 제시하고, 아키텍처 설명, 아키텍처 프레임워크 및 아키텍처 설명 언어에 적용되는 요구 사항 지정함으로써 아키텍처 설명의 실무를 표준화

 

나. ISO/IEC/IEEE 42010(IEEE 1471)의 중요성

중요성 설명
표준화 - 아키텍처와 관련된 용어 및 개념의 통일
중립성 - 모델링언어, 방법론 제시 않음, 개발 상위 레벨에서의 SA의 표현
유연성 - 다양한 규모의 시스템 구축 시 적용 가능
의사소통 - 요구사항/설계의 차이를 개선, 이해관계자 관점에서의 표현

 

II. . SW 아키텍처 프레임워크 모델 및 구성요소

가. SW 아키텍처 프레임워크 (ISO/IEC/IEEE 42010가 최종, IEEE 1471 개념적) 모델

프레임워크 내용
IEEE 42010 - 시스템 및 SW엔지니어링 아키텍처기술(Description) 관련된 용어와 개념을 정의한 국제표준, IEEE 1471이 IEEE 42010으로 통합
IEEE 1471 - SW 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처를 기술하기 위한 표준

나. SW 아키텍처 프레임워크(ISO/IEC/IEEE 42010) 구성요소

분류 구성요소 설명
식별 System of Interest
(대상 시스템)		 - 각 어플리케이션들, 서브 시스템들, 시스템의 집합, 제품라인, 제품 군 등의 구현체

Stakeholder
(이해관계자)		 - <system> individual, team, organization, or classes thereof, having an interest in a system
- 한 명 이상의 System에 대한 이해 당사자로 각자 다른 System에 대한 Concern을 가지고 있는 개인, 기관 등

Concerns
(관심사)		 - <system> interest in a system relevant to one or more of its stakeholders
- 하나 또는 다수의 이해관계자들과 관련 있는 시스템에서의 관심사항
- System의 성능, 유연성, 보안, 분배, 진화 등을 포함한 한 명 이상의 Stakeholder들에게 중요한 System의 개발이나 운영 등 측면
표현 Model Kind
(모델형)		 - conventions for a type of modeling
- 모델링 하는 타입에 대한 방식
- system의 특성 속성에 대한 concern에 대해 기술하기 위한 방식

Architecture
(아키텍처)		 - <system> fundamental cencepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
- <시스템> 환경에서 시스템의 기본 개념 또는 속성

Architecture description
(아키텍처 기술)		 - work product used to express an architecture
- architecture 표현에 사용되는 방법
- architecture가 기록되는 방법
AD의
파트		 Architectural ViewPoint
(아키텍처 View 관점)		 - work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system
- 특정 시스템의 관심사항을 만들기 위해 아키텍처 뷰의 구성, 해석, 사용에 대한 규칙을 정립한 work product
- Architecture View를 구성하기 위한 규칙을 정의하는 패턴이나 템플릿

Architecture View
(뷰)		 - work product expressing the architecture of a system from the perspective of specific system concerns
- 특정 System의 관심 있는 부분(concerns, interest)의 관점에서 system의 architecture를 표현한 work product

Architecture Model
(모델)		 - 특정 시스템의 관심사항 작성을 위한 이해관계자들이 가지는 생각이나 견해로부터 시스템을 표현

Architecture Rationale
(결정 근거)		 - 선택되어 설계된 아키텍처에 대한 논리적 근거

Correspondence Rule
(대응 관계의 규제)		 - architecture view들간의 대응 규칙

Correspondence
(대응관계)		 - stakeholder의 관심에 따른 대응 관계
반응형
저작자표시 비영리 변경금지

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

MSA  (0) 2024.04.02
SW Architecture 평가  (0) 2024.04.01
명세기반 테스팅 기법  (0) 2024.03.30
SW Architecture  (0) 2024.03.30
(외부)EPMO  (0) 2024.03.11
상 명세기반 테스팅 기법 블랙박스 테스트 = 명세기반 테스트
 
토픽 이름(상) 명세기반 테스트(Specification-based Technique)
분류 SW > Test > 명세기반 테스트
키워드(암기) - 요구명세서, 기능중심, Data Driven, I/O Driven
- 동등분할, 경계값분석, 의사결정 테이블, 상태전이, 유즈케이스, 분류트리, 페어와이즈 테스트, 원인-결과 그래프 기법, 오류예측기법
암기법(해당경우) 불동경의상-유분페원오 (불교, 동경에 의상대사 가셨다)

 

기출문제

번호 문제 회차
1 테스트 설계 기법 중 명세기반 기법(Specification-based Technique)에 대하여 설명하시오. 111.응용.3.3
2 소프트웨어의 명세기반기법(Specification-Based Technique)테스트와 구조기반기법 (Structure-Based Technique)테스트 방법을 나열하고 설명하시오. 83.관리.2.4
3 5. 명세기반테스트에 대해 설명하시오. 모의_2018.07.응용.3

 

I. 명세기반 테스트 개요

    1. 명세기반 테스트 정의
      1. S/W의 내부 동작을 알 수 없는 상태에서 시스템 명세서를 기반으로 테스트케이스를 설계하여 S/W가 목적하는 동작만을 인지하여 테스트하는 방식
  1. 명세 기반 기법의 특징
특징 설명
블랙박스테스트 시스템 내부를 참조하지 않고 테스트 수행
데이터 중심 입출력 데이터에 초점
테스트 케이스 도출 초기 테스트 설계 적용으로 테스트 케이스 도출 가능

 

II. 명세기반 테스트의 기법

 -- 블랙박스 테스트 기법과 동일

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

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

SW Architecture 평가  (0) 2024.04.01
ISO/IEC/IEEE 42010  (1) 2024.03.31
SW Architecture  (0) 2024.03.30
(외부)EPMO  (0) 2024.03.11
객체지향 설계의 원리  (0) 2024.03.10
상 SW Architecture [정의] 프로그램/시스템 컴포넌트, 컴포넌트 간의 상호관계 구조이며 이들을 설계하기 위한 지침과 원리
[중요성] SW 프레임워크에 설계기반제공, SW 스타일을 제공
[구성요소] Architecture Description, 이해관계자, 관심사, 관점, View
[아키텍처 설계절차] 요참모프배
아키텍처 요구파악
참조 아키텍처 준비
아키텍처 모델링
아키텍처 프로토타이핑
아키텍처 배포
[설계 원리]
분할과 정복 - 세분화된 작은 시스템부터 개발(상향식)
추상화 - 과정 추상화, 데이터 추상화, 제어 추상화
단계적 분해 - 기능 세분화 후 점진적 구체화(하향식)
모듈화 - 작업 단위화, 응집도 및 결합도
정보은닉 - 모듈간 독립화, 인터페이스 통해 필요정보만 송수신
[소프트웨어 아키텍처 설계 시 고려사항]
기능 요구사항 - 시스템이 구현해야 하는 기능 요구사항에 대해 설계 단계에서 책임 할당
품질 속성 - 시스템 품질속성, 비즈니스 품질속성, 아키텍처 품질속성
제약사항 - 프로그래밍 언어, Legacy 재사용, H/W, COTS
요참모프배
분추단모정
토픽 이름 (상) SW Architecture
분류 SW > SW Architecture > SW Architecture
키워드(암기) IEEE 42010으로 통합구성요소, Mission, Stakeholder, Concerns, View, Viewpoint
암기법(해당경우)  

 

기출문제

번호 문제 회차
1 6. 아래와 같은 간단한 응용에 대한 소프트웨어 아키텍처를 작성하고자 한다. 다음 질문에 답하시오.
(1) C&C 뷰(Component & Connector, 프로세스 뷰)를 작성할 때 가장 적당한 아키텍처 스타일을 제시하고 필요한 컴포넌트와 커넥터를 제시하시오.
(2) 위에서 제시한 아키텍처 스타일에 따라 아키텍처를 작성하시오.
(3) 위 응용에 대한 모듈 뷰(논리 뷰) 작성을 위한 컴포넌트를 제시하고 아키텍처를 작성하시오.		 92회_관리_3
2 4. 소프트웨어 아키텍처의 중요성 및 품질속성을 시스템, 비즈니스, 아키텍처 관점으로 구분하여 설명하시오. 87_조직_3
3 6. 소프트웨어 아키텍처의 정의, 역할, 아키텍처 모델의 중요성을 설명하고, 여러 가지 아키텍처 스타일을 설명하시오. 86_관리_3
4 6. A기관 차세대통합정보시스템 구축 사업에서는 웹서비스 방식으로 모든 서비스를 제공할 계획이다. 고객 제안요청서에서는 CBD (Component Based Development)방법론으로 구축을 요구하고 있으나, 현재 개발업체 입장은 과제해결에 요구되는 몇 가지 기존 소프트웨어 컴포넌트 구매가 필요하고, 나머지는 EJB(Enterprise Java Beans)환경으로 개발을 고려하고 있다. 고객과의 이견차이를 좁히기 위한 적합한 응용소프트웨어 아키텍처 구현방안을 다음사항을 기준으로 설명하시오.
1) 개발 방법론(팩키지+CBD) 적용방안을 제시하시오.
2) 응용 소프트웨어 아키텍처 구성방안을 기술하시오.
3) 기성 소프트웨어 컴포넌트와 신규개발 컴포넌트간 인터페이스 방안 설명.		 83_관리_4
5 소프트웨어 아키텍처(Software Architecture)를 정의 하시오. 세가지 주요요소를 중심으로 기술하시오. UML의 4+1View, 프레임워크(FW 모델들), 스타일 81_관리_1
6 1. 소프트웨어 아키텍처(Software Architecture)를 정의 하시오. 세가지 주요요소를 중심으로 기술하시오. 81_응용_2
7 2.  CBD 방법론을 적용하여 프로젝트를 수행하려고 한다. 컴포넌트 정의에 앞서 소프트웨어 아키텍처에 대해 정의하고자 한다.
   가. 소프트웨어 아키텍처 단계의 목적(작업완료기준)을 기술하시오.
   나. 수행내용을 기술하시오.
   다. 고려할 사항 등에 대하여 기술하시오. 		80_관리_4
8 1. 소프트웨어 아키텍처 품질 속성 시나리오의 개념 및 구성요소를 설명하고 소프트웨어 아키텍처 품질 속성 시나리오 중에서 신뢰성, 보안성, 유지보수성에 대한 시나리오를 설명하시오. 모의_2019.07_응용_3
9 5. 소프트웨어 아키텍처 패턴의 개념과 종류를 설명하고, layer, Broker, MVC 패턴의 장/단점에 대해 설명하시오. 모의_2018.01_응용_2
10 5. 아키텍처를 이해관계자들이 원하는 수준으로 품질 속성을 달성하기 위해서 소프트웨어 아키텍처 품질 속성 시나리오를 작성하고자 한다. 아키텍처 품질 속성 시나리오의 개념 및 구성요소를 설명하고 소프트웨어 아키텍처 품질 속성 시나리오 중에서 가용성, 변경 용이성, 수행 성능에 대한 시나리오를 설명하시오. 모의_2017.12_관리_3
11 4. 소프트웨어 아키텍처란 소프트웨어 시스템의 구성을 위한 중대한 결정사항들이라 할 수 있다. 소프트웨어 아키텍처에 대한 다음 질문에 답하시오.
가. 품질속성 시나리오
나. 아키텍처 설계 전술
다. 아키텍처 스타일		 모의_2017.04_관리_3

 

I. 소프트웨어 컴포넌트와 인터페이스 간의 상호관계 및 구조, 소프트웨어 아키텍처의 개요

가. 소프트웨어 아키텍처(Software Architecture)의 정의

- 프로그램/시스템 컴포넌트, 컴포넌트 간의 상호관계 구조이며 이들을 설계하기 위한 지침과 원리

- 소프트웨어 컴포넌트들과 외부적으로 보여지는 특성, 그들의 상호 관계들로 구성되는 해당 시스템의 구조

 

나. 소프트웨어 아키텍처의 등장배경

SW 목적, 기능의 다양성 증가 ▷ Software Architecture 활용 ▷ 품질 및
생산성
향상
분할과 통합 과정 복잡도 증가



품질 고려한 체계적 설계 필요



 - 이해관계자(Stakeholder)간에 관점 조율, 우선순위 결정과 요구 사항들 간 Trade off 분석 통한 시스템 최적화

 - 요구사항 간 조화 및 충돌 조정 (성능: 정보보호, 유지보수성: 안정성, 개발단가:투자단가 등)

 

다. 소프트웨어 아키텍처의 특징

구분 특징 내용
비즈니스
측면		 변화 민첩성 - Agility(민첩성) 통한 RTE 구현, 적시성.
- 다양한 비즈니스 요구사항의 민첩한 대응 및 처리

비용 절감 - 소프트웨어 재사용, 자산화 통한 개발비 절감

표준화 - 재사용 가능한 산업별 표준화 지원
기술적
측면		 의사소통 수단 - 이해관계자들 간 원활한 의사소통 수단

간략성 - 소프트웨어 복잡성 증가에 따른 해결 대안

관점(Aspect)모형 - 이해관계자들 간 관심사에 대한 모형 제시

 

II. SW 아키텍처 프레임워크 및 구성요소

가. SW 아키텍처 프레임워크의 주요 구성요소

요소 내용
Architecture
Description
(AD)		 - 아키텍처를 기록하기 위한 산출물들
- 하나의 AD는 System에 대한 관심사를 나타내는 관심사(Concern)와 관련, 이에 대응하는 하나 이상의 Stakeholder와 연관됨
이해관계자
(Stakeholder)		 - 소프트웨어 시스템 개발에 관련된 모든 사람과 조직을 의미
- 고객, 최종 사용자, 개발자, 프로젝트관리자, 유지보수자, 마케팅담당자 등을 포함.
관심사
(Concerns)		 - 동일한 시스템에 대해 각 이해관계자들이 가지는 서로 다른 의견과 목표.
(예) 사용자 입장: 기본적인 기능 + 신뢰성/보안/사용성 요구//유지보수자 입장: 유지보수 용이성//개발자 입장: 적은 비용과 인력으로 개발 가능해야 함
관점
(Viewpoint)		 - 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대한 이해관계자들의 관점.
- Viewpoint는 View 구성하기 위한 규칙 정의하는 패턴. 각각의 View에 1:1로 대응.
View - 이해관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현.

 

나. SW 아키텍처 프레임워크 (ISO/IEC/IEEE 42010가 최종, IEEE 1471 개념적)

à SW 토픽 044_ISO_IEC_IEEE42010(IEEE1471) 참고

 

III. SW 소프트웨어 아키텍처 프로세스(절차도)

 

 

IV. 소프트웨어 아키텍처 정방향 분석과 역방향 분석

가. 소프트웨어 아키텍처 정방향 분석

구분 세부항목 설명
개념 의사 결정
상세 설계		 - 프로젝트 초반에 요구사항 명세서 활용해 분석하고 의사 결정
- 위험요소, 품질, 비기능 요구사항 등을 분석해 시스템 설계
특징 일관성 유지 위험 예방 - SW 외적(요구사항) 완결성, 내적(개발방향) 완결성 추구
- 적합성 여부 분석하고 수정/보완해 위험 최소화 목적
기법 ATAM
CBAM
ADR
ARID		 - 아키텍처가 특정 품질 목표 충족 여부, 목표 간 충돌(Trade-off) 분석
- ATAM 기법의 부족한 경제성 평가해 보완한 방법
- 아키텍처 구성 요소 간 응집도 평가하는 방법
- ATAM 기법과 ADR 기법 혼합하여 특정 부분에 대한 품질 요소 평가

- 산출물 없이 요구사항 기반으로 프로젝트 초반에 아키텍처 분석 실시할 때 정방향 분석 수행

 

나. 소프트웨어 아키텍처 역방향 분석

구분 세부 항목 설명
개념 역공학 시스템 통합 - 기존 산출물(코드, 설계서)에서 정보 추출해 아키텍처 분석
- 기존 시스템(Legacy) 분석, 도축하여 기본 아키텍처 분석 수행
특징 품질 관리 이해도 향상 - 구성 요소 간 복잡도 최소화하여 유지 보수 용이하도록 지원
- 소프트웨어 시스템 구성에 대한 이해도 증대
기법 지표 분석
관계 분석
시각화 분석		 - 산출물(코드 등)에서 추출한 정보 기반으로 정량적 수치 평가
- 컴포넌트 간 관계 추출해 관계적 문제점(영향력, 상호참조) 평가
- 지표/관계 기법 결과를 시각화하여 다각도로 분석하는 방법

- 기존 시스템(Legacy)이 있는 경우 역방향 분석 이용해 기본 아키텍처 분석, 도출한 후 수행

- 아키텍처 분석 활동은 비용 절감, 사전 문제 발견, 요구사항 검증, 설계 품질을 향상시킬 수 있는 활동

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

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

ISO/IEC/IEEE 42010  (1) 2024.03.31
명세기반 테스팅 기법  (0) 2024.03.30
(외부)EPMO  (0) 2024.03.11
객체지향 설계의 원리  (0) 2024.03.10
객체지향 프로그래밍 특징  (0) 2024.03.09
중 (외부)EPMO [정의] - 다수의 IT 프로젝트를 기업 비즈니스전략과 정렬하고 프로젝트 별 기업 자원 투입, PMO 간 의견 조율 등을 수행하는 최상위 PMO
도입절차] 도입계획수립-PMO가동준비-PMO운영-PMO지속적개선
[PMO제도의 한계점] 예산부족, 예산편성기준 부재, 명확한 도입대상 기준부재,
PMO 도입 부정적인식, PMO 권한과 책임 애매함, 감리업체와 충돌
[PMO 선정기준] 수행인력, 업무계획, 수행실적, 품질 및 성과관리
​
[PMO유형] 기상대, 코치, 컨트롤타워
[PMO단계]
PMO사업추진(도입검토,발주및계약,착수)
PMO사업수행(본사업기획단계, 본사업집행단계, 본사업 사후관리단계)
PMO사업종료(PMO사업검사,PMO사업 산출물인수, PMO사업 추진실적제출)
토픽 이름(중) (외부)EPMO, 공공 PMO
분류 PM > (외부)EPMO, 공공 PMO
키워드(암기) PMO(Project Management Office)의 유형, 공공 PMO, EPMO
암기법(해당경우) [기집사] 기획, 집행, 사후관리

 

기출문제

번호 문제 회차
1 최근 정부에서는 공공기관의 전문성을 보완하고, 중소 소프트웨어 기업의 성공적인 사업 추진 및 품질확보를 위해 PMO(Project Management Officier) 제도를 추진하고 있다. 공공 정보화 사업에서의 PMO 제도 적용과 관련하여 다음에 대해 설명하시오.
가. 프로젝트 단계별 PMO 도입시기에 따른 장,단점
나. CDB 방법론을 활용한 정보화 사업에서 프로젝트 단계별 PMO 역할
다. PMO의 도입효과 및 기술사적 입장에서 PMO제도의 성공적인 도입 방안		 관리 98회

 

기업 전략에 기반을 둔 상시적, 포괄적 조직, EPMO 개념

    1. EPMO(Enterprise PMO) 정의
    2. EPMO의 등장배경
  1. EPMO의 개념 및 역할

  • 데이터를 저장함과 동시에 일정한 규칙에 의해 사용자 어플리케이션에 의해 처리될 수 있도록 함
  1. 기업 조직 내 EPMO 위치 및 역할

  1. EPMO와 PMO의 비교

  1. 공공정보화 사업에서의 PMO 제도, 공공 PMO 개요

가. 공공 PMO 정의

- 전자정부사업의 사업의 위험을 방지하고 품질을 향상시키기 위해 전자정부사업의 관리 감독 업무 일부 또는 전체를 전문가에게 위탁하는 제도

- 전자정부사업관리 위탁(PMO) 제도 도입(전자 정부법 제64조의2)

 

나. 공공정보화 사업에서의PMO 제도 등장배경

발주기관 측면 중소기업 측면
-정보화 사업 전문관리 인력공급 및 전문성 부족 보완
-PMO의 도움을 받아 사업기획부터 사후관리까지 사업전반에 대한 품질향상		 -체계적인 사업관리 방법론 및 경험, 노하우 부족을 보완
-사업관리 전문역량이 강화되며, PMO 관련 업체는 공공정보화 시장이 사업영역으로 확장

 

  1. 공공정보화 사업 PMO 제도 도입의 범위

법적 근거

구분 규정 및 대상

전자정부법
제64조의2		 - (전자정부사업관리의 위탁) ① 행정기관등의 장은 전자정부사업을 효율적으로
수행하기 위하여 다음 각 호의 어느 하나에 해당하는 사업에 대하여 관리ㆍ감독하는
 업무(이하 "전자정부사업관리"라 한다)의 전부 또는 일부를 전문지식과 기술능력을 갖춘 자에게 위탁할 수 있으며, 대상이 되는 전자정부사업의 구체적인 범위 및 전자정부사업관리를 수탁할 수 있는 자의 자격요건은 대통령령으로 정한다.

전자정부법
제64조의3		 - (전자정부사업관리자의 책무 등) 전자정부사업관리자가 전자정부사업관리업무를
수행할 때 계약을 위반하거나 고의나 과실로 발주자에게 손해를 발생시킨경우에는
 그 손해를 배상하여야 한다.

전자정부법
시행령
제78조의2		 - (관리ㆍ감독업무를 위탁할 수 있는 전자정부사업의 범위 등)
① 법 제64조의2제1항에 따른 관리ㆍ감독 업무(이하 "전자정부사업관리"라 한
다)를 위탁할 수 있는 전자정부사업의 구체적인 범위는 다음 각 호와 같다.

전자정부법
시행령
제78조의3		 - (전자정부사업관리자의 자격요건) 법 제64조의2제1항에 따라 전자정부사업관리를
 수탁할 수 있는 자의 자격요건은 다음 각 호와 같다.

전자정부법
시행령
제78조의4		 - (전자정부사업관리자의 선정기준) ① 중앙행정기관등의 장은 법 제64조의2제2항에
 따른 전자정부사업관리를 위탁받아 수행하는 자(이하 "전자정부사업관리자"라 한다)를 다음 각 호의 기준을 고려하여 평가한 후 선정하여야 한다.

전자정부법
시행령
제78조의5		 - (표준계약서) 행정자치부장관은 중앙행정기관등이 전자정부사업관리에 대한 위탁업무를 효율적으로 처리하기 위하여 필요하다고 인정하는 경우에는 표준계약서를 정하여 고시할 수 있다.

위탁규정 - (전자정부사업관리 위탁에 관한 규정) 위탁대상사업, 용역 대가 산정, 전자정부사업관리 수행 등 규정
- 「전자정부법」 제64조의2, 같은 법 시행령 제78조의2부터 제78조의4까지의
규정에서 위임한 사항과 전자정부사업관리의 위탁에 필요한 사항을 정함을 목적

위탁계약
특수조건		 - (전자정부사업관리 위탁용역계약 특수조건) 전자정부사업관리 위탁용역계약 특수조건(이하 "위탁계약특수조건"이라 한다)은 「전자정부법」제64조의2에 따른 전자정부사업관리 위탁용역(이하 "위탁용역"이라 한다)을 수행함에 있어 발주 기관과 위탁용역 수행자간에 이행해야 할 계약조건을 정함을 목적
도입 대상 대국민서비스 - 국민생활의 편의와 안전을 위해 필요한 정보시스템을 구축, 고도화하는 사업

공통행정
서비스		 - 여러 행정기관 등이 공통적으로 사용하여 행정의 효율성에 큰 영향을 미치는 정보시스템을 구축하거나 고도화하는 사업

통합·연계
사업		 - 행정정보의 공동이용시스템 등 둘 이상의 정보시스템이 통합·연계되어 고도의
사업관리 역량이 요구되는 사업

행정기관 등
의 장이 인정
하는 사업		 - 해당 행정기관 등이 전자정부사업관리에 대한 경험 및 전문성 등이 부족하거나
필요 인력등이 충분하지 아니하여 위탁관리가 필요한 사업
- 그 밖에 전자정부사업의 중요도, 난이도 등이 대국민·공통행정서비스 및 통합·연계
 사업에 준하는 것으로서 전문적인 관리·감독이 필요하다고 인정되는 사업

- 전자정부사업에 대한 관리·감독 업무의 전부 또는 일부를 전문지식과 기술능력을 갖춘 자에게 위탁할 수 있도록 하는 PMO제도 도입

 

  1. 공공 정보화 사업 PMO 사업자 선정 기준 및 수행단계별 세부 업무

  가. 공공 정보화 사업 PMO 선정기준

구분 선정기준 평가항목
수행인력 전자정부사업 또는 전자정부사업관리 수행경력 등 수행인력의 전문성
업무계획 사업의 이해도, 위탁용역 추진내용의 적절성, 사업관리・기술지원・인력투입 계획의 적절성등 사업계획의 구체성 및 실현가능성
수행실적 참여업체의 전자정부사업 또는 전자정부사업관리 수행실적 전자정부사업 등의 수행실적
품질 및 성과관리 위탁용역사업의 품질관리, 성과관리 지원 등 품질관리 지원체계
  • 발주기관은 사업의 특성을 고려하여 평가항목 등 선정기준을 조정하여 사용가능

 

  나. 공공사업 PMO의 수행단계별 세부 업무

수행단계 관리항목 세부업무
기획 단계 통합관리 1. 사업계획 수립 지원.
2. 사업대가 산정 지원
3. 제안요청서 작성 지원
4. 사업자 선정 및 기술협상 지원

성과관리 1. 사업목표 수립 지원
2. 세부 성과지표 및 목표치 수립 지원
집행 단계 통합관리 1. 사업착수 관련 계획의 검토, 조정
2. 사업 진행상황 모니터링,검토, 조정
3. 과업 변경영향 분석, 대안 제시
4. 설계·종료 단계 기능점수 적정성 검토
5. 사업의 검사·인수 지원
6. 단계별 교훈수집, 하자보수 계획 및 절차 검토·조정
7. 적용된 사업관리 절차 및 방법론의 지식화
8. 위험 및 쟁점 사항에 대한 지식화

이해 관계자
관리		 1. 이해관계자 식별 및 영향도 분석
2. 이해관계자 의견 반영여부 점검 및 조치사항 지시

범위관리 1. 사업범위 검토 및 조정
2. 요구사항 분석내용의 점검 및 추적관리
3. 사업범위 변경통제

자원관리 1. 투입인력 계획의 적정성 검토 및 조정
2. 투입인력 계획의 준수여부 점검 및 조치사항 지시
3. 인력변경 적정성 점검 및 조치사항 지시

일정관리 1. 일정계획 검토 및 조정
2. 진척상황 점검 및 지연시 조치사항 지시
3. 일정변경 요청의 타당성 검토 및 대안제시

위험관리 1. 위험 관리계획 검토 및 조정
2. 위험사항 식별 및 분석
3. 위험 대응계획 검토 및 조정
4. 위험 대응상황 점검 및 조치사항 지시

품질관리 1. 품질 및 시험 관리계획 검토 및 조정
2. 방법론 검토 및 조정
3. 품질·시험 활동 점검 및 조치사항 지시

성과관리 1. 성과 관리계획 수립
2. 단계별 성과지표 평가

조달관리 1. 하도급 및 조달 계획 점검·조정
2. 하도급 및 조달 계획의 이행상황 점검,조치사항 지시

의사소통
관리		 1. 의사소통 계획 검토 및 조정
2. 사업추진 상황 및 쟁점사항의 정기·비정기 보고
3. 발주기관의 의사결정 지원

변화관리 1. 변화관리 계획 검토 및 조정
2. 변화관리 계획의 이행여부 점검 및 조치사항 지시

보안관리 1. 보안 및 개인정보보호 관리계획 검토·조정
2. 보안 및 개인정보보호 관리계획 이행여부 점검, 조치사항 지시
사후관리
단계		 통합관리 1. 정보시스템 안정화 지원
2. 위탁대상사업 및 위탁용역 산출물의 활용·관리 지원
3. 하자여부의 검토
4. 하자보수 이행 관리 지원

변화관리 1. 정보시스템 변화관리 지원
2. 교육 및 홍보 지원

성과관리 1. 성과지표 달성여부 평가
  1. 도입된 PMO 제도의 한계점 및 보완 방안

[참고] 공공 정보화 사업에서 프로젝트 단계별 PMO의 역할 (CBO방법론 도입 시)

단계 주요 활동 PMO의 역할
요구정의 단계 - 고객의 요구사항 도출 및 정의
- 개발할 시스템의 비즈니스 도메인에 대한 이해
- 이터레이션 계획 수립		 - 프로젝트 관리원칙 제공
- 체계적 보고체계 구축
분석단계 - 해당이터레이션에 대한 상세 계획 수립
- 개발할 시스템에서 제공해야 할 기능을 고객 관점에서 정의
- 핵심 기능에 대한 UI 프로토타이핑을 통해 고객에게서 검증
- 시스템의 기능을 구현할 내부 객체 식별 및 정의
- 시스템 내부 객체와 사용자와 시스템 간의 상호작용 체계를 정의하고 이들의 일관성 검증		 - 요구 수집을 위한 의사소통 체계 구축 및 지원
- 산출물 표준 검토
- 요구사항 추적성 확보 방안 마련
설계단계 - 시스템에 구현될 화면 레이아웃 및 화면 간의 네비게이션(Navigation) 정의
- 데이터 모델링을 통한 DB 설계
- 컴포넌트 식별 기법을 사용한 컴포넌트 식별, 컴포넌트 간 상호작용 관계 정의
- 컴포넌트 내부 클래스 및 시퀀스 다이어그램 작성을 통해 객체의 속성 및 오퍼레이션과 객체 간 메시지 전달 흐름을 설계		 - 산출물 검토를 통한 산출물 품질 확보
- 테스트 계획 검토 및 테스트 조직 구성 확인
구현단계 - 컴포넌트 프로그래밍
- 컴포넌트 테스트
- 컴포넌트 배포 및 운영		 - 테스트 결과 확인
- 배포 전 품질수준 확보

 

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

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

명세기반 테스팅 기법  (0) 2024.03.30
SW Architecture  (0) 2024.03.30
객체지향 설계의 원리  (0) 2024.03.10
객체지향 프로그래밍 특징  (0) 2024.03.09
Architecture  (0) 2024.03.08

+ Recent posts

티스토리툴바