정보처리기사 3일차

1.소프트웨어 설계

 1.1 요구사항 확인

  1.1.4 분석모델 확인

 

---

- 분석모델 확인

 

1. 모델링 기법

 

1.1 모델링의 개념

모델링의 정의 : 실세계의 물리현상을 특정한 목적에 맞추어 이용하기 쉬운 형식으로 표현하는 일을 의미

개념모델링 의 역할

실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심이며, 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다.

따라서 개념모델은 문제 도메인의 엔티티들과 그들의 관계 및 종속성을 반영한다.

 

1.2 개념 모델의 종류와 표기법

유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터액션, 객체 모델, 데이터 모델 등 과 같은 다양한 모델을 작성할 수 있다. 

대부분의 모델린 표기법은 UML을 사용한다.

 

1.3 UML 다이어그램의 사용

사용 시나리오를 나타내기 위하여 유스케이스 다이어그램이 많이 사용되고 있다.

구조 다이어그램은 시스템의 정적구조와 다양한 추상화 및 구현 수준에서 시스템의 구성요소, 구성 요소들 같의 관계를 보여준다.

행위 다이어그램은 시스템 내의 객체들의 동적인 행위를 보여주며, 시간의 변화에 따른 시스템의 연속된 변경을 설명해준다.

 

2. 분석자동화 도구

 

2.1 유스케이스 모델 검증

한국정보화진흥원의 정보 시스템 감리지침에서는 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성에 대하여 다음과 같은 사항을 점검하도록 하고 있다고 한다.

 

 

2.2 개념 수준의 분석 클래스 검증

시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검해야한다.

주요 점검 항목

• 개별 유스케이스 단위로 작성하지 않고 시스템 전체를 대상으로 작성하였는가?
• 중요도가 높은 요구사항 도는 유스케이스에 필요한 엔티티 클래스가 도출 되었는가?
• 도출된 클래스 이름과 설명이 이해관계자 간에 이견이 발생하지 않도록 명확한가?
• 클래스의 속성은 도출하였는가? 도출된 속성의 이름과 설명이 명확한가?
• 클래스들 간에 순환적 관계과 불필요하게 정의되어 있는가?
• 클래스 간의 관계에서 다중성이 정의되었는가?

2.3 분석 클래스 검증

유스케이스마다 분석 클래스가 적절히 도출되었고, 제어 클래스의 도출 등이 충분하고 상세하게 도출되어 클래스의 역할, 클래스 간의 관계, 메시지 흐름 등을 확인할 수 있는지 검토한다.

1.유스케이스 실현에 필요한 분석 클래스 도출 확인

하나의 유스케이스를 실현하기 위하여 3개 이상의 클래스가 역할 기준으로 도출되어야 하며, 유스케이스 별로 실현에 필요한 클래스가 추적 가능해야 클래스 누락 여부를 확인할 수 있다.

유스케이스 별로 도출된 분석 클래스 들이 역할 기준으로 경계, 엔티티, 제어 클래스가 도출되어 스테레오 타입으로 표시되었는지 확인한다.

2.경계와 제어 클래스의 도출 여부 빛 상세화 정도 확인

유스케이스 실현에 필요한 분석 클래스들이 도출되었는지 확인하기 위하여, 유스케이스 단위로 분석 클래스를 확인한다.

3.클래스 간의 관계, 클래스 정보의 상세화 정도 확인

 

3.요구사항 관리 도구

 

3.1 요구사항 관리 도구의 개념

요구사항을 기반으로 프로젝트 관리, 설계, 개발, 테스트 등을 수행할 수 있는 역할을 지원하는 도구이다.

히스토리, 베이스라인, 교환과 같은 요구사항 관리 기능, 요구사항 간의 혹은 요구사항과 다른 산출물 간의 추적성, 다양한 CASE도구와의 통합, 자체 언어와 API를 통한 확장성을 지원한다.

 

3.2 요구공학의 요구사항 관리

요구공학에서는 요구사항 관리를 요구사항 협상, 요구사항 기준선, 요구사항 변경관리, 요구사항 확인 및 검증 등으로 정의하고 있다.

 

3.3 요구사항 관리 도구의 주요기능

요구사항 관리 도구는 제품에 따라 기능과 특성의 차이가 있을 수 있으나, 보편적인 요구사항 관리 도구의 기능 사례는 

아래와 같다.

 

1.프로젝트 생성

프로젝트 타입 및 기본 모듈 템플릿, 속성, 역할별 뷰를 설정하여 프로젝트 생성을 도와주며 이를 저장하여 재사용 할 수 있도록 할 수 있다.

2.요구사항 작성

모든 요구사항에 고유의 ID가 생성, 부여되고 이 ID는 사용자에 의한 임의 변경이 될 수 없도록 한다.

3.요구사항 Import/Export

요구사항의 일괄 등록 및 추출을 위해 Plain Text,Rich Text,Spread sheet, Word, Excel, Outlook, HTML 등 다양한 형식의 파일 Import 와 Export 기능을 제공한다.

4.요구사항 이력관리

요구사항 별로 히스토리 관리 기능을 제공하여 변경 이력을 관리할 수 있다.

5.요구사항 베이스라인

요구사항이 확정되고 관리의 시작점이 되는 요구사항 베이스라인 기능을 제공한다.

5.요구사항 추적성

어느 요구사항이 베이스인지를 구분하기 위한 기능으로 현재 요구사항을 기반으로 작성된 요구사항인지, 타 요구사항을 기반으로 하여 현재 요구사항이 작성되었는지를 알려준다.

7.협업 환경

하나의 요구사항 문서를 여러 명이 작성할 수 있도록 하는 협업 기능이다. 일반적으로 공유 모드를 제공하고 선점 사용자외에는 수정 및 삭제 권한이 제한된다.

8.외부 연동 환경

요구사항대로 설계되었는지를 파악하기 위해 설계도구와 연동을 지원하며, 요구사항대로 구현되었는지를 확인하기 위해 형상 관리도구와의 연동을 지원한다.

9.확장성

API 등을 통해 타 시스템과의 연동 기능을 제공한다.

 

---

오답풀이

 

시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 도형 또는 도면을 무엇이라 하는가?

1.Flow chart(나의 오답)

2.HIPO Chart(정답) 

3.Control Specification

4.Box Diagram

 

HIPO는 하향식 소프트웨어 개발을 위한 문서화 도구이다. 기능과 자료의 의존관계를 동시에 표현할 수 있어서 보기 쉽고 이해하기 쉽다.

 

3.Control Specification

4.Box Diagram 이것들은 뭘까..?

 

Control Specification

요구되는 완전성의 수준을 보증하기 위하여 데이터 처리 시스템 중에 적용되어야 할 규칙의 기술들.

Box diagram

NS(Nassi-Schneiderman) Chart

- 논리 기술에 중점을 둔 도형을 이용한 표현 방법(Box Diagram, Chapin Chart) 

- 순차, 반복, 선택, 다중 선택 구조등 표현 

- GOTO나 화살표 사용하지 않음, 선택과 반복 구조를 시각화 

- 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별 

출처: https://yeolco.tistory.com/6 [열코의 프로그래밍 일기]

 

소프트웨어 재사용에 가장 많이 이용되는 것은?

1.HIPO chart

2.Test Case

3.Source Code(정답) 이게 정답이었다니..

4.Project Plan

 

소스코드는 프로그래머가 작성한 프로그램이다. 소스코드를 통해 재사용, 수정, 세부처리 내용을 파악할 수 있다.