[정보처리기사 필기] 1과목 키워드 정리

1과목 소프트웨어 설계

1.1 요구사항 확인

 

폭포수 모형

- 소프트웨어 개발도 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론.

- 고전적 생명주기 모형 / 선형 순차적 모형

- 제품의 일부가 될 메뉴얼을 작성해야 함.

- 각 단계가 끝난 후에 다음 단계를 수행하기 위한 결과물이 명확하게 산출 되어야 함.

- 타당성 검토 > 계획 > 요구 분석 > 설계 > 구현 > 시험 > 유지보수

 

나선형 모형

- 점진적 모형: 보헴이 제안.

- 나선을 따라 돌 듯이 여러 번의 소프트웨어 개발 과정을 거처 점진적으로 완벽한 소프트웨어를 개발하는 것.

- 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것으 목적으로 함.

- 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 유지보수 과정이 필요 없음.

- 계획 및 정의 > 위험 분석 > 공학적 개발 > 고객 평가

 

에자일

- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행.

- 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭.

- 스프린트 또는 이터레이션이라고 불리는 짧은 개발 주기를 반복하고 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용.

- 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합.

- 개발 모형: 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM, DAD

 

스크럼

- 팀이 중심이 되어 개발의 효율성을 높임. 팀원 스스로가 스크럼 팀을 구성해야 하며 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 함.

- 구성

s 제품 책임자: 요구사항을 책임지고 의사 결정할 사람으로 요구사항이 담긴 백로그를 작성하고 우선순위 지정. 주기적으로 요구사항의 우선순위 갱신.

s 스크럼 마스터: 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할. 일일 스크럼 회의를 주관하여 진행사항을 점검. 개발 과정에서 발생된 장애 요소를 공론화하여 처리.

s 개발팀

- 스크럼 개발 프로세스

s 제품 백로그: 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록. 지속적으로 업데이트.

s 스트린트 계획 회의: 단기 일정을 수립. 개발자 별로 테스크를 분할 한 후, 스프린트 백로그 작성.

s 스프린트: 실제 개발 작업을 진행하는 과정.

s 일일 스크럼 회의: 매일 약속된 시간에 15분 정도로 진행 사항 점검. 남은 작업시간 소멸 차트에 표시.

s 스프린트 검토 회의: 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 사용자가 포함된 참석자 앞에서 테스팅 수행. 한 주당 한시간 내에 진행 .제품 책임자는 개선할 사항에 대한 피드백 정리 후 제품 백로그 업데이트.

s 스프린트 회고: 개선점, 규칙 준수 여부 확인 및 기록.

 

XP (eXtreme Programming)

- 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화 하여 개발 생산성을 향상시키는 방법.

- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함.

- 비교적 소규모 인원의 개발 프로젝트에 효과적.

- 5가지 핵심 가치: 의사소통, 단순성, 용기, 존중, 피드백

- XP 개발 프로세스

s 사용자 스토리: 요구사항을 시나리오로 표현. 기능 단위로 구성.

s 릴리즈 계획 수립: 릴리즈(몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것) 일정 수립.

s 스파이크: 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램.

s 이터레이션: 하나의 릴리즈를 더 세분화 한 단위.

s 승인 검사: 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트.

s 소규모 릴리즈: 고객의 반응을 기능별로 확인할 수 있음.

 

기능 요구 사항

- 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항.

- 시스템이 반드시 수행해야 하는 기능

- 사용자가 시스템을 통해 제공받기를 원하는 기능

 

비기능 요구 사항

- 시스템 장비 요구사항, 성능 요구사항(처리 속도 및 시간, 가용성), 인터페이스 요구사항, 데이터 요구사항, 보안 요구사항, 품질 요구사항, 테스트 요구사항, 제약 사항, 프로젝트 관리 요구사항, 프로젝트 지원 요구사항

 

요구사항 개발 프로세스

- 요구사항 도출: 요구 사항 수집

- 요구사항 분석: 타당성 조사, 비용과 일정에 대한 제약 설정

- 요구사항 명세: 요구사항 체계적으로 분석 문서화

- 요구사항 확인: 요구 사항 검증

 

프로토타이핑

- 초기 도출된 요구사항을 토대로 프로토타입을 만든 후 대상 시스템의 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정

 

UML

- UML의 구성요소: 사물, 관계, 다이어그램

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

- 관계

존재하지 않는 이미지입니다.

 

 

UML 다이어그램

- 구조적 다이어그램(정적 모델링)

s 클래스 다이어그램: 클래스 사이의 관계 표현. 시스템 구조를 파악하고 구조상의 문제점 도출할 수 있음.

s 객체 다이어그램: 클래스에 속한 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현.

s 컴포넌트 다이어그램: 실제 구현 모듈은 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스 구현. 구현 단계에서 사용.

s 배치 다이어그램: 결과물, 프로세스, 컴포넌트 등 물리적 요소의 위치를 표현. 구현 단계에서 사용.

s 복합체 구조 다이어그램: 클래스나 컴포넌트가 복합 구조를 가질 때 내부 구조를 표현.

s 패키지 다이어그램: 모델 요소들을 그룹화.

- 행위 다이어그램(동적 모델링)

s 유스케이스 다이어그램: 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용. 사용자와 사용 사례로 구성.

s 시퀀스 다이어그램: 상호 작용하는 시스템이나 객체들이 주고받는 메시지 표현한다.

s 커뮤니케이션 다이어그램: 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고받는 메세지와 연관까지 표현.

s 상태 다이어그램: 자신의 속한 클레스의 상태 변화를 표현.

s 활동 다이어그램: 어떤 기능을 수행하는지 흐름을 순서에 따라 표현.

s 상호작용 개요 다이어그램: 상호작용 제어 흐름 표현

s 타이밍 다이어그램: 객체 상태 변화와 시간 제약을 명시적으로 표현.

 

 

 

 

 

 

1.2 화면 설계

사용자 인터페이스(UI)

- 구분: CLI, GUI, NUI

- 사용자 인터페이스 기본 원칙: 직관성, 유효성, 학습성, 유연성

- 설계 지침: 사용자 중심, 일관성, 단순성, 결과 예측 가능, 가시성, 표준화, 접근성, 명확성, 오류 발생 해결

 

내비게이션

- 사용자가 사이트에서 원하는 정보를 빠르게 찾을 수 있도록 안내하는 것.

- 원하는 정보를 쉽고 빠르게 찾을 수 있도록 다양한 경로나 방법을 제공해야 함.

 

와이어프레임

- 기획 단계의 초기에 제작하는 것으로 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는 단계. 각 페이지 구분을 화면 단위로 설계.

- 대발자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 사용.

 

스토리보드

- 와이어 프레임에 콘텐츠에 개한 설명, 페이지 간 이동 흐름 등을 추가하는 문서.

- 디자이너와 개발자가 최종적으로 참고하는 작업 지침서.

 

 

UI 요구사항

- UI 요구사항 확인 순서: 목표 정의 > 활동 사항 정의 > UI 요구사항 작성

- 요구사항 요소: 데이터 요구, 기능 요구, 제품 서비스의 품질, 제약 사항

 

품질 요구사항

- 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는 가를 나타내는 소프트웨어 특성.

- 기능성(Functionality)

s 적절성/적합성: 목적 달성을 위해 적절한 기능 제공하는지.

s 정밀성/정확성: 요구하는 결과를 정확하게 산출하는지.

s 상호 운용성: 다른 시스템과 어울려 작업.

s 보안성: 정보에 대한 접근 허용/차단

s 호환성: 기능에 관련된 표준을 준수했는지.

- 신뢰성(Reliability)

s 성숙성: 결함으로 인한 고장을 피해갈 수 있는 능력

s 고장 허용성: 결함 시에도 규정된 성능 수준을 유지할 수 있는 능력

s 회복성: 고장 시 규정된 성능 수준까지 회복하고 복수할 수 있는 능력

- 사용성(Usability): 이해성, 학습성, 운용성, 친밀성

- 효율성(Efficiency)

s 시간 효율성: 특정 기능을 수행할 때 적절한 반응 시간 및 처리 시간을 제공할 수 있는 능력.

s 자원 효율성: 특정 기능을 수행할 때 적절한 자원의 양과 종류를 제공할 수 있는 능력.

- 유지 보수성(Maintainability)

s 환경의 변화 또는 새로운 요구사항이 발생할 때 개선하거나 확장할 수 있는 정도.

s 분석성: 결함이나 고장의 원인, 수정될 부분들의 식별을 가능하게 하는 능력.

s 변경성: 결함 제거 또는 환경 변화로 인한 수정 등을 쉽게 구현할 수 있는 능력

s 안정성: 변경으로 인한 예상치 못한 결과를 최소화할 수 있는 능력.

s 시험성: 변경이 검증될 수 있는 능략

- 이식성(Portability): 적용성, 설치성, 대체성, 공존성

 

프로토타입

- 사용자 요구 사항을 기반으로 실제 동작하는 것처럼 만든 동적인 형태의 모형.

- 종류: 페이퍼 프로토타입, 디지털 프로토타입

- 계획 시 고려 사항

s 프로토타이핑 일정은 일반적으로 아키텍처가 확정된 이후 프로젝트의 실제 분석 작업이 완료되기 전에 진행해야 함.

s 가장 많이 시간이 소요된 구간을 찾고 원인 분석하여 해결 방법 제기.

- 작성 시 고려 사항

s 작성 계획을 세움. 목표를 확인함.

s 프로토타입으로 감증할 범위가 너무 넓거나 기간이 길면 목표가 커져서 문제가 될 수 있음.

s 실제 개발에 참조 될 수 있는지 확인.

 

UI 설계서

- 사용자의 요구사항을 바탕으로 UI 설계를 구체화하여 작성하는 문서. 상세 설계 이전 대표적인 화면 설계.

- 순서: UI 설계서 표지 작성 > UI 설계서 개정 이력 작성 > UI 요구사항 정의서 작성 > 시스템 구조 작성 > 사이트 맵 작성 > 프로세스 정의서 작성 > 화면 설계

 

유용성 평가

- 사용자가 시스템을 통해 원하는 목표를 얼마나 효과적으로 달성할 수 있는 가에 대한 척도.

 

UI 시나리오

- UI 설계자 또는 인터렉션 디자이너가 UI 시나리오 문서를 작성하면 그래픽 디자이너가 시나리오를 바탕으로 디자인하고 개발자가 UI 구현

- 사용자가 최종 목표를 달성하기 위한 방법이 순차적으로 묘사되어 있음.

- 다양한 상황에서의 예외처리 방식, 대표 화면간 인터렉션 흐름, 기능 구조, 대표 화면 등을 문서로 정리.

- UI 시나리오 문서의 일반 규칙

s 주요 키의 위치와 기능: 일관성 보장

s 공통 UI 요소

s 기본 스크린 레이아웃

s 기본 인터렉션 규칙: 공통적으로 사용되는 조작 방법과 효과등 기술

s 공통 단위 태스크 흐름

s 케이스 문서: 다양한 상황에서 공통적으로 적용되는 시스템의 동작을 정의한 문서

- 시나리오 문서의 요건

s 완전성: 최대한 상세하고 사용자 테스크에 초점 맞춰서 기술

s 일관성: 사비스 목표, 시스템 요구사항 등이 일관성을 유지.

s 이해성: 누구나 쉽게 이해할 수 있도록.

s 가독성: 표준화된 템플릿(화면 기본 레이아웃) 등을 활용하여 쉽게 읽을 수 있도록.

s 수정 용이성

s 추적 용이성: 변경 사항은 왜 발생했는지 쉽게 추적 할 수 있어야 함.

 

 

1.3 애플리케이션 설계

소프트웨어 아키텍처

- 소프트웨어의 골격이 되는 기본 구조이자 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템 구조 또는 구조체.

- 사용자의 비기능적 요구사항으로 나타난 제약을 반영, 기능적 요구사항을 구현하는 방법을 찾는 해결 과정

- 기본 원리: 모듈화, 추상화, 단계적 분해, 정보 은닉

 

모듈화

- 소프트웨어의 성능을 향상시키거나, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능을 모듈 단위로 나누는 것을 의미.

- 재사용성 향상 시킴.

- 모듈의 크기를 너무 작게 나누면 개수가 많아져 모듈간의 통합 비용이 많이 들고, 너무 크게 나누면 통합 비용은 적게 들지만 하나의 개발 비용이 많이 듦.

 

추상화

- 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화 하여 구체화시켜 나가는 것.

- 유형: 과정 추상화(전반적인 흐름), 데이터 추상화(데이터 구조를 대표할 수 있는 표현), 제어 추상화(이벤트의 발생을 표현으로 대체)

 

정보은닉

- 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법.

- 다른 모듈과 커뮤니케이션 할 때는 필요한 정보만 인터페이스를 통해 주고 받음.

 

아키텍처 패턴

- 아키텍쳐를 설계할 때 소프트웨어 시스템 구조의 기본적인 윤곽을 제시.

- 아키텍처 스타일, 표준 아키텍쳐.

- 종류: 레이어 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 모델-뷰 컨트롤러 패턴.

- 설계 과정: 요구사항 분석, 설계목표 설정 > 시스템과 서브 시스템 타입 결정 > 표준 아키텍처 설계 > 서브 시스템의 기능과 인터페이스 정의

 

레이어 패턴

- 시스템을 계층으로 구분하여 구성하는 고전적인 방법.

- 각각의 서브 시스템들이 계층 구조를 이루고, 상위 계층이 서비스 제공자가 되고, 하위 계층이 클라이언트가 됨.

- 레이어 패턴은 서로 마주보는 두 개의 계층 사이에서만 상호 작용이 이루어짐. 특정 계층만 교체해 시스템을 개선하는 것이 가능.

- 대표적으로 OSI 참조 모델.

 

클라이언트-서버 패턴

- 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴.

- 사용자는 클라이언트와만 의사소통을 한다. 서버는 클라이언트의 요청에 대비해 항상 대기 상태를 유지.

- 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고는 서로 독립적.

 

모델-뷰-컨트롤러(MVC) 패턴

- 서브 시스템을 3개의 부분으로 구조화 하는 패턴.

- 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업 수행가능.

- 여러 개의 뷰를 만들 수 있으므로 한 개의 모델에 대해 여러 개의 뷰를 필요로 하는 대화형 어플리케이션에 적합.

- 모델: 서브 시스템의 핵심 기능과 데이터를 보관.

- 뷰: 사용자에게 정보를 표시. (Output)

- 컨트롤러: 사용자로부터 받은 입력 처리 (Input)

 

클래스

- 공통된 속성과 연산을 갖는 객체의 집합.

- 클래스에 속한 각각의 객체를 인스턴스라고 하며, 새로운 객체를 생성하는 것을 인스턴스화라고 함.

- 동일 클레스에 속한 각각의 객체들을 공통된 속성을 가지고 있으면서, 그 속성에 대한 정보가 서로 달라서 동일 기능을 하는 여러 가지 객체를 나타내게 된다.

 

캡슐화

- 데이터와 데이터를 처리하는 함수를 하나로 묶는 것을 의미 .

- 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐 되어 외부의 접근이 제한적이기 때문에 외부 모듈의 변경으로 인한 파급 효과가 적다.

- 재사용이 용의하고 객체간의 결합도가 낮아진다.

 

결합도(Coupling)

- 모듈간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계.

- 결합도가 약할 수록 품질이 높고, 낮을 수록 품질이 낮음.

- 결합도 약>강 순의 종류

s 자료 결함도: 모듈간의 인터페이스가 자료 요소로만 구성될 때. 매개변수로 데이터를 넘겨주고 처리 결과를 다시 돌려주는 방식.

s 스탬프 결합도: 배열이나 레코드 등의 자료 구조가 전달 될때의 결합도.

s 제어 결합도: 제어 신호를 이용하여 통신하거나 제어요소를 전달. 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제.

s 외부 결합도: 데이터 변수를 다른 모듈에서 참조할 때.

s 공통 결합도: 공용 데이터 영역을 여러 모듈이 사용.

s 내용 결합도: 내부 기능 및 내부 자료를 직접 참조

 

응집도(Cohesion)

- 정보 은닉 개념을 확장한 것으로 모듈이 독립적인 기능으로 정의되어 있는 정도. 강할 수록 좋음

- 응집도가 강한 순의 종류

s 기능적 응집도: 모듈의 모든 기능 요소들이 단일 문제에 연관되어 수행.

s 순차적 응집도: 모듈 내 하나의 활동으로부터 나온 출력 데이터를 다음 활동의 입력 데이터로 사용.

s 교환(통신)적 응집도: 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행.

s 절차적 응집도: 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 기능을 순차적으로 수행할 경우.

s 시간적 응집도: 특정 시간에 처리되는 몇개의 기능을 모아 하나의 모듈로 작성할 경우.

s 논리적 응집도: 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소.

 

1.4 인터페이스 설계

요구사항 명세서

- 프로젝트 개발 시 기업이나 업체가 요구하는 사항들을 구체화하여 명세한 문서.

- 시스템 기능, 데이터, 인터페이스, 품질 등의 요구사항 단위별로 작성.

 

시스템 인터페이스 요구사항 분석

- 기능적 요구사항과 비기능적 요구사항으로 분류하고 조직화.

- 소프트웨어 요구사항 분석 기법을 적절히 이용.

- 누락된 요구사항이 제한 조건 추가.

- 상대적 중요도를 평가하여 우선순위 부여

 

요구사항 검토

- 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 검토 담당자들이 수작업으로 분석하는 방법.

- 동료 검토: 명세서 작성자가 직접 설명하고 동료들이 검토.

- 워크 스루: 요구사항 명세서를 사전 검토 한 후 검토 회의.

- 인스팩션: 작성자를 제외한 다른 검토 전문가들이 검토.

 

인터페이스 요구사항 검증 항목

- 완전성: 사용자의 모든 요구사항 완벽 반영 되었는가?

- 일관성: 요구사항이 일관성을 유지하는가?

- 명확성: 모든 참여자가 요구사항을 명확히 이해할 수 있는가?

- 기능성: ‘어떻게’보다 ‘무엇을’에 중점을 두고 있는가?

- 검증 가능성: 요구사항이 사용자의 요구를 만족하는지를 검증할 수 있는가?

- 추적 가능성: 요구사항 명세서와 설계서를 추적할 수 있는가?

- 변경 용이성: 변경이 쉽도록 작성 되었는가?

 

API/Open API

- 송신 시스템의 데이터베이스에서 데이터를 읽어와 제공하는 애플리케이션 프로그래밍 인터페이스 프로그램.

- 운영체제나 프로그래밍 언어 등에 있는 라이브러리를 응용 프로그램 개발 시 이용할 수 있도록 규칙 등에 대해 정의해 놓은 인터페이스.

 

Socket

- 서버는 통신을 위한 소캣을 생성하여 포트를 할당하고, 클라이언트의 통신 요청 시 클라이언트와 연결하여 통신하는 네트워크 기술.

 

Web Service

- 웹 서비스에서 WSDL(표준 언어), UDDI(XML의 규격), SOAP(객체 간의 통신 규약) 프로토콜을 이용하여 연계하는 서비스.

 

MOM(Message Oriented Middleware)

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

- 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용됨.

- 대표적 종료: IBM의 MQ, 오라클의 MessageQ, JCP의 JMS

 

TP-Monitor(Transaction Processing)

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

- 사용자 수가 증가해도 빠른 응답 속도를 유지해야 하는 업무에 주로 사용.

 

WAS

- 웹 어플리케이션 서버는 사용자의 요구에 따라 변하는 동적인 컨텐츠 처리하기 위해 사용되는 미들웨어.

- 웹 환경을 구현하기 위한 미들웨어

- HTTP 세션 처리를 위한 웹 서버 기능 뿐만 아니라 미션-크리티컬한 업무까지 구현 가능.

- 오라클의 WebLogic, IBM의 WebSphere