정보처리기사 실기 요약 - 1. 요구 사항 확인
정보처리기사 실기 정리 - 1. 요구사항 확인
챕터 01 소프트웨어 개발 방법론
1) 소프트웨어 생명주기(SDLC) : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화 한 절차
|
모델
|
폭포수 모델
|
프로토 타이핑 모델
|
나선형 모델
|
반복적 모델
|
|
설명
|
각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감
|
고객 요구 주요 기능을 프로토타입으로 구현
|
점진적으로 완벽한 시스템으로 개발
|
대상을 나누어 병렬 개발 후 통합하거나 반복 개발로 점증 완성(SDLC)
|
|
특징
|
선형 순차적,
가장 오래됨(고전적), 명확, 변경 어려움
|
피드백 반영, 프로토타입
|
위험 분석, 반복개발
|
병행 개발
|
|
절차
|
|
|
계획 및 정의 →
위험 분석 → 개발 → 고객평가
|
|
2) 소프트웨어 개발 방법론 : SW개발의 전 과정을 형상화한 방법론
소프트웨어 개발 방법론 종류
|
종류
|
설명
|
|
구조적 방법론
|
기능에 따라 나누어 개발한 후 통합(분할 정복)
프로세스 중심, 하향식 방법론, 나씨-슈나이더만 차트 사용
|
|
정보공학 방법론
|
정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
개발 주기 사용, 대형 프로젝트
|
|
객체지향 방법론
|
객체를 기본 단위로 시스템 분식 및 설계
객체, 클래스, 메시지 사용
|
|
컴포넌트 기반 방법론
|
컴포넌트를 조립해서 하나의 응용 프로그램 작성
개발 기간↓, 생산성↑, 확장성, 재사용
|
|
제품 계열 방법론
|
공통 기능을 정의하여 개발
임베디드 SW에 유용, 영역 공학과 응용공학으로 구분
|
|
애자일 방법론
|
절차보다 사람 중심, 유연하고 신속하게 효율적으로 개발
개발 시간↓, 폭포수에 대비, 즉시 피드백
|
3) 애자일 방법론의 유형
- XP(eXtreme Programming) : 의사소통 개선과 즉각적 피드백으로 SW 품질을 높이는 방법론
> 가치 : 용기, 단순성,의사소통,피드백,존중
> 원리 : 짝 프로그래밍, 공통 코드 소유, 지속적 통합, 계획 세우기, 작은 릴리즈, 메타포어, 간단한 디자인
- 스크럼 : 매일 정해진 시간, 장소에서 짧은 시간 개발하는 팀을 위한 프로젝트 관리 중심 방법론
> 백로그, 스프린트(짧은 개발 기간), 스크럼 미팅, 스크럼 마스터, 스프린트 회고, 번 다운 차트(남은 시간)
- 린(Lean) : 낭비요소를 제거하여 품질을 향상한 방법론 (도요타 관련)
> 가치 : 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화
4) 객체 지향 분석(OOA) : 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계 정의
5) 객체 지향 분석 방법론 종류
- OOSE(Object Oriented Software Engineering) : 유스케이스를 모든 모델의 근간으로 활용되는 방법론 (야콥슨)
- OMT(Object Modling Technoiogy): 그래픽 표기법을 이용하여 소프트웨어 구성요소 모델링 (럼바우)
> 분석 절차 : 객체 모델링 -> 동적 모델링 - 기능 모델링
> 객체 모델링 : 객체 간의 관계를 정의하여 ER 다이어그램을 만다는 과정까지의 모델링 (객체 다이어그램 활용)
> 동적 모델링 : 시간 흐름에 따라 객체들의 동적인 행위를 표현하는 모델링(상태 다이어그램 활용)
> 기능 모델링 : 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링(자료 흐름도(DFD 활용)
6) 비용 산정 모형 분류
|
분류
|
설명
|
종류
|
|
하향식
|
경험 많은 전문가에게 의뢰,
여러 전문가와 조정자를 통해 산정
|
전문가 판단, 델파이
|
|
상향식
|
세부 요구 사항과 기능에 따라 비용 계산
|
코드 라인 수(Loc),Man Month, COCOMO, 푸트남(putnam), 기능점수(FP)
|
- 델파이 기법 : 전문가의 경험적 지식을 통해 문제 해결 및 미래 예측을 위한 기법
- 코드 라인 수(LOC Lines Of Code) : 원시 코드 라인수의 낙관치, 중간치, 비 관치를 측정하여 비용 산정
- Man Month : 한 사람이 한 달 동안 할 수 있는 일의 양을 기준으로 비용 산정
> Man Month = Loc/프로그래머의 월간 생산성
> 프로젝트 기간 = Man Month/프로젝트 인력
- COCOMO모형 : 보헴이 제안한 비용 산정 방식으로 프로그램 규모에 따라 비용 산정
> 조직형(Oranic) 5만 라인 이하
> 반 분리형(Semi-Detached) 30만 라인 이하
> 임베디드형(Embedded) 30만 라인 이상
- 푸트남(Putnam) 모형 : 개발 주기의 단계별로 인력 분포를 가정하는 방
> 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
- 기능 점수(FP) 모형 : 소프트웨어 기능을 증대시키는 요인의 가중치 부여하여 비용 산정
> FP = 총 기능점수 * [0.65 + (0.1 * 총영향도)]
> 단순, 보통, 복잡 정도에 따라 가중치 부여
- 비용 산정 자동화 추정 도구
> SLIM : Rayleigh-Norden곡선과 푸트남 모델을 기초로 개발된 자동화 추정 도구
> ESTIMACS : FP모형을 기초로 개발된 자동화 추정 도구
7) 일정 관리 모델 : 프로젝트가 기한 내에 완료될 수 있도록 관리하는 모델
|
모델
|
설명
|
|
주 공정법(CPM)
|
프로젝트 일정 계산법, 노드와 노드 간 연결을 통해 공정 계산
프로젝트 시작에서 종료까지 가장 긴 시간이 걸리는 경로 계산
|
|
PERT
|
일의 순서를 계획적으로 정리하기 위한 수렴 기법(비관·중간·낙관치로 일정 관리)
|
|
중요 연쇄 프로젝트 관리
|
주 공정 연쇄법으로 자원 제약 고려, 일정 작성
|
챕터 02. 현행 시스템 분석
1) 현행 시스템 파악 개념 : 사용하고 있는 SW, HW, NW구성 등 어떻게 되어 있는지 파악하는 활동
2) 절차 : 구성/기능/인터페이스 파악 → 아키텍처/소프트웨어 구성 파악 → 하드웨어/네트워크 구성 파악
- 구성/기능/인터페이스 파악
|
절차
|
설명
|
|
구성
|
기간업무(주)와 지원업무(보조)로 구분하여 파악 / 정보시스템들의 명칭, 주요 기능 명시
|
|
기능
|
현재 제공하고 있는 기능 파악, 계층형 표시
|
|
인터페이스
|
다른 시스템과 주고 받는 데티어 종류, 프로토콜 등 파악
|
- 아키텍처/소프트웨어 구성 파악
|
절차
|
설명
|
|
아키텍처
|
계층별로 어떠한 기술 요소를 사용하고 있는지 파악(기간 업무부터)
|
|
SW
|
소프트웨어들의 제품명, 용도, 라이선스 파악
|
- 하드웨어/네트워크 구성 파악
|
절차
|
설명
|
|
하드웨어
|
서버 위치, 운용 서버의 주요 사양, 이중화 구현 여부 파악
|
|
네트워크
|
어떤 네트워크 장비를 사용하여 어떻게 구성되어 있는지 파악
|
3) SW 아키텍처 : SW구성과 그 요소의 외부 특성과 관계 표현하는 시스템 구조
- SW 아키텍처 프레임워크 : 아키텍처의 내용 및 관계를 제공하는 아키텍처 기술 표준
- SW아키텍처 프레임워크 구성요소
|
구성 요소
|
설명
|
|
아키텍처 명세서
|
아키텍처를 기록하기 위한 산출물, 뷰로 표현
|
|
이해관계자
|
개발과 관련된 모든 사람, 조직
|
|
관심사
|
이해관계자들(사용자, 유지보수자, 개발자)의 의견, 목표
|
|
관점
|
뷰의 토대가 되는 패턴이나 양식
|
|
뷰
|
전체 시스템 표현
|
|
근거
|
아키텍처 결정 근거, 화의 결과
|
|
목표
|
이해관계자들의 목적, 사용, 운영 방법
|
|
환경
|
시스템에 영향을 주는 요인
|
|
시스템
|
각 애플리케이션, 서브 시스템, 시스템 집합 등 구현체
|
- 소프트웨어 아키텍처 4+1 뷰 : 시나리오를 4개의 관점에서 바라보는 SW접근 방법, 유스 케이스 사용
|
뷰
|
설명
|
|
유스케이스
|
다른 뷰를 검증하는 데 사용되는 뷰
|
|
논리
|
기능 요구사항이 어떻게 제공되는지 설명
|
|
프로세스
|
비기능적 속성 표현 뷰
|
|
구현
|
정적인 소프트웨어 모듈 구성을 보여주는 뷰
|
|
배포
|
컴포넌트가 물리적인 아키텍처에 어떻게 배치되는 가를 보여주는 뷰
|
4) 아키텍처 패턴 : 소프트웨어 설계 시 참조할 수 있는 전형적인 해결 방식
|
유형
|
설명
|
|
계층화
|
시스템을 계층으로 구분하여 구성
각 하위 모듈은 추상화 제공, 서로 마주보는 계층끼리 상호작용
|
|
클라이언트-서버
|
하나의 서버와 다수의 클라이언트로 구성
사용자가 클라이언트에 서비스 요청,
서버가 클라이언트에 서비스 제공, 클라이언트가 사용자에게 전달
|
|
파이프-필터
|
서브 시스템이 입력 데이터 처리, 결과를 넘겨줌(반복)
데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능
|
|
브로커
|
서버의 기능을 브로커 컴포넌트가 가짐,
클라이언트가 브로커에 서비스 요청하면 적합한 것으로 연결해 줌
분산시스템에서 사용, 원격 서비스 실행 통해 상호작용 가능
|
|
모델-뷰-컨트롤러(MVC)
|
대화형 애플리케이션을 모델, 뷰, 컨트롤러로 구조화
모델 : 핵심 기능, 데이터 보관
뷰 : 사용자에게 정보 표시
컨트롤러 : 요청을 입력받아 처리아키텍처 비용 평가 모델 : 아키텍처 적합성 평가
|
5) SW 아키텍처 비용 평가 모델
|
종류
|
설명
|
|
SAAM
|
변경 용이, 기능성에 집중
|
|
ATAM
|
아키텍처 품질 속성을 만족시키는지 판단
|
|
CBAM
|
ATAM + 경제적 의사결정에 대한 요구 충족 판단
|
|
ADR
|
구성 요소 간 응집도 평가
|
|
ARID
|
전체가 아닌 특정 부분에 대한 품질 요소에 집중하여 평가
|
6) 디자인 패턴 : 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 것
- 구성 요소 : 이름, 문제 및 배경, 설루션, 적용 사례, 결과, 샘플 코드
- 유형 : 목적(생성, 구조, 행위) / 범위(클래스, 객체)
생성 패턴
|
패턴
|
설명
|
|
Builder
|
복잡한 인스턴스를 조립하여 만드는 구조,
객체 생성과 구현을 분리함으로써 동일한 절차에 다른 결과를 만드는 것이 가능
|
|
Prototype
|
일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요 부분만 수정하여 사용
|
|
Factory Method
|
상위 클래스에서 객체 생성 인터페이스 정의,
하위 클래스에서 인스턴스 생성
|
|
Abstract Factory
|
서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공
구체적인 구현은 Con-crete Product 클래스에서 이루어짐
|
|
Singleton
|
전역 변수 사용x, 객체 하나만 생성, 생성된 객체는 어디서든지 참조 가능
한 클래스에 한 객체만 존재
|
구조 패턴
|
패턴
|
설명
|
|
Bridge
|
기능 클래스 계층과 구현 클래스 계층 연결, 구현부에서 추상층 분리
실제 구현 부분을 독립적으로 확장할 수 있음
|
|
Decorator
|
기존에 구현되어 있는 클래스에 필요 기능을 추가해나감
|
|
Facade
|
단순 인터페이스 제공, 사용자와 시스템 간 결합도 낮춤
→ 쉬운 구조 파악 가능, 접근성 높일 수 있음
|
|
Flyweight
|
모두가 갖는 본질적 요소를 클래스 화하여 공유
→ 메모리 절약, 클래스의 경량화
|
|
Proxy
|
실제 객체에 대한 대리 객체를 사용
→ 메모리 용량↓, 정보은닉
|
|
Composite
|
객체들의 관계를 트리 구조로 구성, 부분-전체 계층을 표현하는 패턴
|
|
Adapter
|
기존에 생성된 클래스를 재사용할 수 있도록 맞춰주는 인터페이스 패턴
클래스 패턴, 인스턴스 패턴 두 가지 형태로 사용
|
행위 패턴
|
패턴
|
설명
|
|
Mediator
|
중재자를 만들어 중재자에게 모든 것을 요구하여 통신 빈도수를 낮추는 패턴
|
|
Interpreter
|
언어의 다양한 해석을 맞는 클래스를 각각 작성하여
여러 형태의 언어 구문을 해석할 수 있게 만드는 패턴
|
|
Iterator
|
컬렉션 구현 방법을 노출하지 않으면서
그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공
|
|
Template Method
|
작업 처리 일부분을 서브 클래스로 캡슐화해
전체 수행 구조는 바꾸지 않으면서 특정 단계 수행 내역을 바꾸는 패턴
(상위 작업 구조를 바꾸지 않으면서 서브 클래스로 작업 일부분 수행)
|
|
Observer
|
한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에 연락이 가고,
자동으로 내용이 갱신되는 방법(일대 다)
|
|
State
|
객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식
상태에 따라 다르게 처리할 수 있도록 행위 내용 변경 가능
|
|
Visitor
|
각 클래스에서 처리 기능을 분리, 별도 클래스 생성
클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하도록 만드는 패턴
|
|
Command
|
실행될 기능을 캡슐화, 여러 기능 실행 가능한 재사용성이 높은 클래스를 설계
추상 클래스에 메서드 생성,
명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행
|
|
Strategy
|
알고리즘 정의 후 각각 하나의 클래스로 캡슐화,
필요할 때 서로 교환해서 사용할 수 있게 하는 패턴
→ 행위 객체를 클래스로 캡슐화 해 동적으로 자유롭게 변환
|
|
Memento
|
클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용
|
|
Chain of Responsibility
|
정적으로 어떤 기능에 대한 처리의 연결이 하드코딩 되어 있을 때
이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 것
|
7) 현행 시스템 분석서 작성 및 검토
- 분석한 결과를 기반으로 산출물 작성
산출물(구성도) : 정보시스템 기능, 인터페이스 현황, 현행 시스템 아키텍처, 소프트웨어 구성도, 하드웨어 구성도, 네트워크 구성도
8) 개발기술 환경 정의 : 운영 처제(OS), 네트워크(NW), DBMS, 미들웨어, 오픈소스
순서 : 정의 → 자료 수집 → 분석 및 환경 설정 → 요구사항 정의서 및 목표 반영 및 검토
- OS : 컴퓨터와 하드웨어 간의 인터페이스를 담당하는 프로그램
- 분석 시 고려사항 : 신뢰도, 성능, 기술 지원, 주변 기기, 구축 비용
|
구분
|
종류
|
특징
|
|
PC
|
윈도즈(Window)
|
중소 규모의 서버, 일반 PC 등에서 주로 사용
|
|
유닉스(UNIX)
|
대용량 처리, 안정성 높음
|
|
|
리눅스(Linux)
|
중/대규모 서버 대상, 보안성 높음
|
|
|
모바일
|
Android
|
리눅스 기반 모바일 운영 체제, 자바와 코틀린 이용
|
|
iOS
|
스마트폰, 태블릿PC의 높은 보안성과 고성능
|
- 네트워크 : 컴퓨터의 노드 간 연결을 통해 서로에게 데이터를 교환할 수 있도록 하는 기술
- OSI 7 계층 : 네트워크 기본 모델
|
계층
|
설명
|
프로토콜
|
전송단위
|
|
응용
|
사용자와 네트워크간 응용 서비스 연결
|
HTTP, FTP
|
데이터
|
|
표현
|
데이터 형식 설정, 부효교환, 암호화 · 복호화
|
JPEG, MPEG
|
|
|
세션
|
연결 접속 및 동기 제어
|
SSH, TLS
|
|
|
전송
|
데이터 분할, 재조립, 흐름 · 오류 · 혼잡 제어
|
TCP, UDP
|
세그먼트
|
|
네트워크
|
단말 간 데이터 전송을 위한 최적화 경로 제공
|
IP, ICMP
|
패킷
|
|
데이터 링크
|
인접 시스템 간 데이터 전송, 오류 제어
|
이더넷
|
프레임
|
|
물리
|
0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환
|
RS-232C
|
비트
|
- DBMS : DB 생성, 저장 및 관리 제공 응용 프로그램
- 분석 시 고려사항 : 가용성, 성능, 상호 호환성, 기술지원, 구축비용
|
기능
|
설명
|
|
중복 제어
|
동일한 데이터가 여러 위치에 중복으로 저장되는 현상 방지
|
|
접근 통제
|
권한에 따라 데이터 접근 제어
|
|
인터페이스 제공
|
사용자에게 인터페이스 제공(CLI, GUI)
|
|
관계 표현
|
데이터간의 다양한 관계 표현
|
|
샤딩/파티셔닝
|
작은 단위로 나누는 기능
|
|
무결성 제약 조건
|
무결성에 관한 제약 조건을 정의/검사
|
|
백업 및 회복
|
DB 장애 시 데이터 보존 기능
|
- 미들웨어 : 응용 프로그램과 프로그램 운영 환경이 원만한 통신을 이루도록 제어해주는 소프트웨어
- 분석 시 고려사항 : 가용성, 성능, 기술지원, 구축 비용
- WAS(웹 애플리케이션 서버) : 서버 계층에서 앱이 동작할 수 있는 환경 제공
챕터 3 요구사항 확인
1) 요구 공학 : 사용자 요구 반영 시스템 개발을 위해 요구사항에 대한 도출-분석-명세-확인 및 검증하는 활동
- 요구 사항 분류 : 기능적 요구사항, 비기능적 요구사항
- 도출 : 수집 방법 결정, 요구 사항 구체적 표현
- 방법 : 인터뷰, 브레인스토밍, 델파이 기법, 롤플레잉(연기), 워크숍, 설문 조사
- 분석 : 도출된 요구 사항 분석, 완전성과 일관성 확보 / 우선순위 부여
- 단계 : 분류 → 개념 모델링 생성 및 분석 → 요구 사항 할당 → 협상 → 정형 분석
- 분석 기법 : 자료 흐름 지향 분석(데이터 흐름도, 자료 사전) / 객체지향 분석(UML)
- 분석 기술 : 청취, 인터뷰와 질문, 분석, 중재, 관찰, 작성, 조직, 모델 작성
- 명세 : 문서 작성
- 주요 기법 : 비정형(자연어, 이해, 명확) / 정형(수학적 원리, Z-스키마, 상태 차트)
- 검증 항목 : 명확, 완전, 검증 가능, 일관, 수정 용이, 추적 가능, 개발 후 이용성(유지 보수)
- 확인
- 절차 : 요구 사항 목록 확인 → 정의서 작성 여부 확인 → 비기능 요구 사항 확인 → 인터페이스 요구 사항 확인
|
기법
|
설명
|
|
|
검토
|
검토
|
|
|
정형 기술 검토
|
동료 검토
|
명세서 작성자가 설명, 동료들이 설명 들으며 결함 발견
|
|
워크 스루
|
오류 조기 검출 목적
자료를 회의 전 미리 배포, 검토 후 회의 때 오류 검출
|
|
|
인스펙션
|
다른 전문가가 검사하여 오류를 찾아내는 방법
|
|
|
관리 리뷰
|
통제 및 의사결정을 지원하는 리뷰
|
|
|
기술 리뷰
|
정의된 계획 및 명세를 준수하고 있는지 검토 수행
|
|
|
프로토 타이핑
|
주요 기능이나 일부분을 개발하여 사용자 대상으로 시연, 요구 사항 확인
|
|
|
모델 검증
|
개발된 모델의 품질 검증
|
|
|
테스트 케이스 및 테스트
|
테스트 케이스 작성 후 테스트
|
|
|
CASE 도구 활용 검증
|
자동화 분석 도구인 CASE도구 활용(대규모 프로젝트)
|
|
|
베이스 라인
|
요구 사항 변경 추적, 통제 시점인 베이스라인을 통한 검증
|
|
|
요구 사항 추적표
|
개발 단계별 최종 산출물이 어떻게 반영되고,
변경되었는지 확인 가능 문서를 통해 요구 사항 검증
|
|
챕터 04. 분석 모델 확인하기
1) 분석 모델 검증 : 요구 사항 도출을 활용해 분석 모델에 대해서 확인하는 활동
프로세스 : 추적 표 작성 후 검토 의견 칼럼 추가 → 검토의견 작성(요구 사항 작성) → 검토의견 정제(의견 추가)
|
검증 방법
|
설명
|
|
유스케이스 모델
|
액터, 유스케이스, 유스케이스 명세서 점검
|
|
개념 수준의 분석 클래스
|
개념 수준의 주요 분석 클래스를 적절히 도출했는지, 명확한지 점검
|
|
분석 클래스
|
유스케이스 실현에 필요한 분석 클래스 도출 확인
|