[정보처리기사 실기 3편] 1장 요구사항 확인

1. 공부 권장 시간

30분 ~ 40분

 

 

---

2. 내용 요약

---

1. 요구사항 확인

1) 현행 시스템 파악

- 현재 개발하고자 하는 시스템의 개발 범위를 설정하기 위해 구성과 기능, 연계정보, 소프트웨어, 하드웨어, 네트워크의 구성을 파악하는 과정을 의미한다.

 

2) 현행 시스템 파악 절차

현행 시스템 구성 파악	현행 시스템 기능 파악	인터페이스 현황 평가
기간 업무, 지원 업무	제공하는 기능 파악, 계층형 표시	데이터 종류, 통신규약, 연계 유형

아키텍처 구성 파악	소프트웨어 구성 파악
업무 수행 기술 요소들이 사용되는지 최상위 수준에서 파악	소프트웨어 제품명, 용도, 라이선스 수, 적용 방식 명시

하드웨어 구성 파악	네트워크 구성 파악
서버의 주요 사양, 서버의 이중화, 수량	네트워크 구성 파악을 위해 네트워크 연결 방식을 구성도로 작성

 

3) 소프트웨어 아키텍처(서술형)

- 여러가지 소프트웨어 구성요소와 외부 특성, 구성요소 간의 관계를 표현하는 시스템 구조

- 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체

 

4) 소프트웨어 아키텍처 프레임워크(서술형)

소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 표준 기술을 의미한다.

- 기본 구조, 소프트웨어의 베이스(개발 기반), 역할 : 품질유지, 원칙, 지침

- 동일한 아키텍쳐 = 기본 구조가 같은 여러 형태의 결과물

 

* 소프트웨어 프레임워크의 특징

- 모듈화(Modularity)

: 프레임워크는 인터페이스에 의한 캡슐화를 통해서 모듈화를 강화하고 설계와 구현의 변경에 따르는 영향을 극소화하여 소프트웨어의 품질을 향상시킨다.

- 재사용성(Reusability)

: 프레임워크가 제공하는 인터페이스는 반복적으로 사용할 수 있는 컴포넌트를 정의할 수 있게 하여 재사용성을 높여준다. 또는 재사용성은 소프트웨어의 품질을 향상시킬 뿐만 아니라 개발자의 생산성도 높여준다.

- 확장성(Extensibility)

: 프레임워크는 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 넓게 사용할 수 있게 한다. 또한 애플리케이션 서비스와 특성을 변경하고 프레임워크를 애플리케이션의 가변성으로부터 분리함으로써 재사용성의 이점을 얻게 한다.

- 제어의 역흐름(Inversion of control)

: 프레임워크 코드가 전체 애플리케이션의 처리 흐름을 제어하여 특정한 이벤트가 발생할 때 다형성을 통해 애플리케이션이 확장한 메소드를 호출함으로써 제어가 프레임워크로부터 애플리케이션으로 반대로 흐르게 한다.

 

5) 소프트웨어 아키텍처 4+1 뷰

* 정의 : 고객의 요구사항을 정리해둔 시나리오 4개의 관점으로 바라보는 소프트웨어적인 접근 방법

* 4+1뷰의 종류

- 유스케이스 뷰 : 아키텍처를 도축하고 설계하는 작업을 주도하는 뷰

- 논리 뷰 : 설계 모델의 추상화, 클래스 식별 -> 클래스 다이어그램

- 프로세스 뷰 : 런타임 시 스레드와 프로세스 사이의 상호 작용

- 배포 뷰 : 물리적인 노드의 구성 -> 배포 아이어그램

- 구현 뷰 : 정적인 소프트웨어 구현 -> 컴포넌트 뷰, 컴포넌트 다이어그램

 

* 런타임 : 컴퓨터 프로그램이 실행되고 있는 동안의 동작 상태

* 스레드 : 프로세스의 실행을 담당하는 실행의 기본 단위

* 프로세스 : 운영체제가 관리하는 실행 단위며 PCB를 가진 시스템

* 프레임워크 : 소프트웨어의 특정 부분을 설계 및 구현 시 재사용이 가능하도록 클래스 제공

 

6) 개발 기술 환경 정의

* 운영체제(서술형) : 사용자와 하드웨어의 인터페이스 역할을 하며 컴퓨터 시스템의 자원을 관리하는 소프트웨어

- 키워드 : 신뢰성, 성능, 기술 지원, 주변 기기, 구축 비용

 

* DBMS(서술형) : 사용자와 Database 사이에서 사용자의 요구에 따라 정보를 생성해주고 Database를 관리해주는 소프트웨어

- 데이터의 중복성과 종속성을 해결

- 키워드 : 가용성, 성능, 기술 지원, 상호 호환성, 구축비용 

 

* JDBC : JAVA 언어를 이용하여 DB에 접근하여 관리할 수 있는 인터페이스

* ODBC : 응용프로그램에서 DB에 접근하여 데이터를 관리할 수 있는 표준 인터페이스

 

* 미들웨어 : 운영체제와 소프트웨어 Application 사이에서 원만한 통신이 이루어질 수 있도록 중개 및 제어 역할을 하는 소프트웨어

 

* 미들웨어의 종류

- DB(DataBase)

: 데이터베이스 벤더(Vendor)에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어

- RPC(Remote Procedure Call)

: 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어

- MOM(Message Oriented Middleware)

: ​메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어

- TP-Monitor(Transaction Processing Monitor)

: 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어

- ORB(Object Request Broker)

: 객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어

- WAS(Web Application Server)

: 사용자의 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

- 키워드 : 가용성, 성능, 기술 자원, 구축 비용

- WAS 종류 : Tomcat, JBoss, Jetty, JEUS

 

* 가비지 컬렉선 : 실제로 사용되지 않고 있지만 반환되지 않은 메모리 공간을 강제로 해제하여 사용할 수 있도록 하는 메모리 관리 기법

 

* 오픈소스 : 누구나 제한 없이 사용할 수 있는 소스코드를 공개한 라이선스를 만족하는 소프트웨어

- 키워드 : 라이선스 종류, 사용자의 수, 기술 지속 가능성 고려

 

* tpmC : 1분당 최대 처리 건수, 하드웨어 성능 지표로 사용

* OLTP/배치/데이터베이서 서버 -> tpmC

* WEB/WAS 서버 -> OPS(Operations per Second)

 

7) 요구사항

* 소프트웨어가 문제를 해결하기 위해 제공되는 서비스 설명과 제약조건을 나타낸다.

- 기능적 요구사항 : 시스템이 제공하는 기능, 서비스 (기능성, 완전성, 일관성)

- 비기능적 요구사항 : 기능외의 제약사항이나 보안적인 요소

- 사용자 요구사항 : 사용자 관점에서 시스템이 제공해야 할 기능 및 서비스

- 시스템 요구사항 : 개발자 관점

 

- 요구사항 개발 프로세스

도출	분석	명세	확인
- 요구사항 식별 - 인터뷰 - 브레인스토밍 - 리서치 - 워크숍	- 요구사항 분류 - 개념 모델링 - 요구사항 협상 - 요구사항 할당 - 정형 분석	- 문서화 - 시스템 요구사항 명세서 - 시스템 정의서	- 요구사항 검토 - 프로토타이핑 - 모델 검증 - 인수 테스트
* 개념 모델링 : 요구사항 분석의 핵심으로 요구사항을 단순화하여 개념적으로 표현한 것 * 유스케이스 다이어그램 : 액터(사용자)와 시스템의 관계를 표현하고 기능적인 요구사항을 유스케이스라는 단위로 표현 * UML : 개발자들이 효율적으로 의사소통을 하기 위해 만들어진 표준 통합 모델링 언어 * 요구사항 할당 : 아키텍처 구성요소 식별 * 정형 분석 : 구문과 의미를 갖는 정형화된 언어를 수학적 기호로 표현하여 분석 * 모델 검증 : 정적 분석 수행 * 인수테스트 : 사용자의 입장에서 테스트하는 방법으로 알파 테스트와 베타 테스트가 존재 * 프로토타이핑 : 새로운 요구사항을 도축하기 위한 수단 또는 요구사항에 대해 소프트웨어 엔지니어가 해석한 것으로 확인하기 위한 수단

 

 

8) 비용 산정 모델

- 하향식 선정 방법 : 전문가 판단, 델파이 기법

- 상향식 선정 방법 : LOC, M/M(Man/Month), Putnam, COCOMO

* Putnam : 개발 주기의 단계별 요구, 인원 분포도 가정

* COCOMO : 보헴이 정의 / 프로그램 규모에 따라 비용 산정

 

* 상호 운용성 : 서로 다른 시스템 간의 데이터를 주고 받아 효율적으로 운용될 수 있는 특성

 

9) 분석 모델 검증

 (1) 유스케이스 모델 검증 ( 액터, 유스케이스 )

 (2) 개념 수준의 분석 클래스 검증

 (3) 분석 클래스 검증

 

* 분석 클래스의 스테레오 타입(표현법) - 아이콘과 유형명 및 설명 중요

- 경계 : 외부 액터와 상호작용

- 제어 : 시스템이 제공하는 기능의 로직, 제어 담당

- 엔티티 : 시스템이 유지해야 하는 정보를 관리

 

* 기술적 타당성 검토

 (1) 성능 및 용량 산정의 적정성

 (2) 시스템 간 상호 운용성

 (3) IT 시장 성숙도 및 트렌드 부합성

 (4) 기술적 위험 분석

 

10) UML

* 정의 : 개발자들이 원활한 의사소통을 하기 위해 고안된 표준화 통합 모델링 언어

* 6개의 구조 다이어그램 + 7개의 행위 다이어그램

* 구성요소 : 사물, 관계, 다이어그램

 

- 사물 : 구조, 그룹, 행동, 주해

 

- 관계

  - 연관관계 : 2개 이상 사물이 서로 연관

  - 집합관계 : 하나의 사물이 다른 사물에 포함

  - 포함관계 : 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

  - 일반화 : 상속 관계

  - 의존 : 필요에 의해 짧은 기간 동안 관계 유지

  - 실체화 : 서로를 그룹화할 수 있는 인터페이스

	연관 Association	집합 Aggregation	포함 Composition	일반화 Generalization	의존 Dependency	실체화 Realization
정의	2개 이상 사물 서로 관련	하나의 사물, 다른 사물에 포함	포함되는 사물에게 영향 미침	사물끼리 일반적, 구체적 표현	연관은 있으나 영향줄 때만 연관을 유지	행위, 인터페이스로 서로 그룹화할 수 있는 관계
표기법	― * 다수, .. 또는	◇	◆	상위개념 실선	일시적, 점선	상위개념, 점선
예시	자동차-타이어	컴퓨터 ◇ 마우스	마우스 ◆ 마우스 리시버	토레타 포카리 - 이온음료	고객등급 --- 사은품	폰, 벽시계 --- 시간확인

 

- 다이어그램(6개의 구조 다이어그램 + 7개의 행위 다이어그램)

 

  - 6개 구조 다이어그램 : 클래스, 객체, 컴포넌트, 배치

   - 컴포넌트 다이어그램 : 컴포넌트와의 관계나 인터페이스를 표현

   - 배치 다이어그램 : 물리적인 요소들의 위치 표현

  - 7개 행위 다이어그램 : 유스케이스, 시퀀스, 커뮤니케이션, 상태

구조적 다이어그램		행위 다이어그램
종류	키워드	종류	키워드
클래스	구조	유스케이스	모델링
객체	관계	시퀀스	메시지
컴포넌트	구현, 인터페이스	커뮤니케이션	메시지 + 연관관계
배치	구현, 위치	상태	상태 변화
복합체 구조	내부 구조	활동	로직 흐름
패키지	그룹	상호작용 개요	제어 흐름
		타이밍	시간제약

 

* 유스케이스 다이어그램 구성요소 : 액터, 유스케이스, 시스템, 관계

* 유스케이스 : 액터에게 제공하는 서비스, 기능을 표현

 

---

3. 분석 모델 관련 어휘

 

1. 속도에 중점을 둔 분산형 버전 관리 시스템이며, 대형 프로젝트에서 효과적이고 유용한 형상 관리 도구이다.

Git

 

 

2. 소스 및 자료를 천재지변이나 해킹, 소프트웨어 버그 및 오동작 등으로 인한 각종 재해에 대비해 시스템을 회복 가능한상태로 만들기 위해 준비하는 작업이다.

백업

 

 

3. 버전 관리 도구를 활용, 제품 소프트웨어 백업은 내부의 정확한 ( ____ ) 을 먼저 세워야 하고, 상세 백업 방법을 공유해야한다.

백업 정책

 

 

4. 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 요구사항 분석을 위한 자동화 도구이다.

분석 자동화 도구

 

 

---

4. 변형 문제

1. 다음 내용에 해당하는 분석 모델 검증 방법은?

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

- 주요 클래스 도출 여부, 도출된 클래스 이름과 속성의 적절성, 올바른 클래스들 간의 관계 여부 점검

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

 

 

2. 분석 모델 검증 방법 中 유스케이스 모델 검증 방법은?

시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해서 액터, 유스케이스, 유스케이스 명세서 점검

 

3. 분석 모델 검증을 위한 프로세스이다. 순서로 알맞은 것은?

A - 검토의 견 컬럼 추가

B - 검토 의견 작성

C - 검토 의견 정제

A-B-C

 

4. 분석 클래스의 스테레오 타입에 대한 설명에서 '시스템과 외부 액터와의 상호 작용을 담당하는 클래스'는?

경계

 

5. 분석 모델의 기술적 타당성 검토 항목 2가지는?

1. 성능 및 용량 산정의 적정성

2. 시스템 간 상호 운용성

3. IT 시장 성숙도 및 트렌드 부합성

4. 기술적 위험 분석

 

 

6. 다음의 제시된 분석 모델의 시스템화 타당성 분석 프로세스를 순서대로 나열하시오.

A - 타당성 검토의견 작성

B - 타당성 검토의견 컬럼 추가

C - 타당성 검토 결과 확인 및 배포/공유

D - 타당성 분석 결과 검증

B-A-D-C