2021년 8월 7일 - 정보처리기사 실기 1장 요구사항 확인

● 본 기록은 '코딩하는 핑가님'의 허락을 받고 블로그에 정리된 글을 그대로 필사했음을 밝힙니다.

→ https://ss-o.tistory.com/110?category=1013699 

정보처리기사 실기 목차 - 정리, 예상문제, 문제 복원 수록

 

 

---

 

1. 요구사항 확인

1) 현행 시스템 파악

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

 

2) 현행 시스템 파악 절차

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

 

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

 

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

 

 

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

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

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

 

 

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

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

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

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

 

 

* 소프트웨어 프레임워크의 특징 모제확역

- 모듈화(Modularity)

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

 

- 재사용성(Reusability)

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

 

- 확장성(Extensibility)

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

 

- 제어의 흐름(Inversion of control)

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

 

 

5) 소프트웨어 아키텍처 4+1뷰 프배구논유 

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

* 4+1뷰의 종류

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

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

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

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

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

 

 

5) 개발기술 환경 정의

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

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

 

 

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

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

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

 

 

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

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

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

 

 

* 미들웨어의 종류 DTOMoRroW

- DB(Data Base)

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

 

- RPC(Remote Procedure Call)

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

 

- MOM(Message Oriented Middleware)

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

 

- TP-Monitor(Transaction Processing Monitor)

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

 

- ORB(Object Request Broker)

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

 

- WAS(Web Application Server)

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

: Tomcat, JBoss, Jetty, JEUS

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

 

 

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

 

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

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

 

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

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

* WEB/WAS - OPS(Operaions per Second)

 

 

7) 요구사항

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

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

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

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

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

 

 

- 요구사항 개발 프로세스 도분명확

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

 

 

8) 비용 산정 모델

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

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

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

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

 

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

 

 

9) 분석 모델 검증

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

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

(3) 분석 클래스 검증

 

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

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

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

 

- 기술적 타당성 검토

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

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

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

(4) 기술적 위험 분석

 

 

10) UML

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

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

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

 

- 사물 : 구조, 그룹, 행동, 주행(?)

 

- 관계  연집포일의실

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

 

 

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

 

 

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

 

 

* 일반화 : 상속 관계/ 사물끼리 일반적, 구체적 표현

 

 

* 의존 : 필요에 의해 짧은 기간동안 관계 유지/ 연관은 있으나, 영향을 줄때만 연관을 유지

 

 

* 실체화 : 서로를 그룹화할 수 있는 인터페이스/ 행위, 인터페이스로 서로 그룹화할 수 있는 관계

 

 

 

- 다이어그램

- 6개의 구조(정적) 다이어그램 [클객컴배복패]

* 클래스 - 구조

* 객체 - 관계

* 컴포넌트 - 구현, 인터페이스

* 배치 - 구현, 위치

* 복합체 구조 - 내부 구조

* 패키지 - 그룹

 

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

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

 

- 7개의 행위(동적) 다이어그램 [유시커상활타 + 상]

* 유스케이스 - 모델링

* 시퀸스 - 메시지

* 커뮤니케이션 - 메시지 + 연관관계

* 상태 - 상태 변화

* 활동 - 로직 흐름

* 타이밍 - 시간 제약

* 상호작용 개요 - 제어 흐름