[정보처리산업기사] 오답노트 2

 

 

 

5. 폭포수 모델 단계

• 타당성 조사 : 시스템의 정의와 가능성 조사 및 다른 방법과 비교 조사하는 단계
• 계획 : 문제 정의, 목표와 요구사항 결정, 개발 비용 및 소요 기간, 인력 등의 개발 계획 수립 단계
• 분석 : 요구사항을 구체적으로 이해하고 소프트웨어가 담당해야 하는 정보 영역을 정의하여 요구 분석 명세서로 문서화하는 단계
• 기본 설계 : 전체적인 하드웨어 및 소프트웨어의 구조, 제어 구조, 자료 구조의 개략적인 설계를 작성하는 단계
• 상세 설계 : 각 단위 프로그램에 대한 사항을 상세히 기술하는 단계

 

 

 

 

10. 스크럼

• 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 제품 백로그를 사용
• 소멸(Burn-down) 차트를 통해 작업의 진행 사항 확인
• 스프린트 검토 회의 후 개선 사항에 대한 피드백을 정리하여 제품 책임자(스크럼 마스터 X)는 제품 백로그를 업데이트
• 작업 할당 시 개발자들이 자신에게 맞느 작업을 스스로 선별하여 담당할 수 있도록 하는 것이 좋음

 

 

 

 

 

 

11. 사용자 요구사항 추출 기법

• 인터뷰 : 상대를 직접 만나서 이야기하면서 의견을 나누는 방법
• 설문 : 어떤 주제에 대하여 미리 준비한 질문을 내어 물어보는 방법
• 브레인스토밍 : 3인 이상이 자유롭게 의견을 교환하면서  독창적인 아이디어를 산출해 내는 방법
• 프로토타이핑 : 시스템 수행 결과를 설명하기 위해 종이에 화면 순서를 기술하여 고객과 사용자에게 보여주는 것

 

 

 

 

13. 비기능 요구사항

• 시스템 장비 구성, 성능, 인터페이스, 데이터, 테스트, 품질, 제약사항, 프로젝트 관리, 프로젝트 지원에 대한 내용
• ex) 1년 365일, 하루 24시간 운용이 가능해야 한다 => 품질과 제약사항에 관한 요구사항임

 

 

 

 

17. 자료 흐름도 작성 효과

• 사용자의 업무 및 요구 사항을 정확하게 파악 가능
• 사용자와 분석가 사이의 의사소통읠 위한 공용어 역할
• 사용자의 업무 및 요구사항을 쉽게 문서화
• 자료 흐름에 중점을 두는 분석용 도구

 

 

 

 

20. 자료 사전(DD, Data Dictionary)

• 자료 흐름도의 대상이 되는 모든 자료에 대한 기본 사항들을 구체적으로 정의
• ( ) 안의 자료 항목은 생략할 수 있음
• 자료 요소는 더 이상 분할되지 않는 자료 항목을 의미
• 모호성 제거하며, 세부 구성 내력을 명세하는 역할

 

 

 

 

24. 소단위 명세서

• 단계화된 DFD에서 최하위 처리의 입력 자료 흐름을 출력 자료 흐름으로 변환하는 과정을 명세화해 놓은 문서
• 작성 도구 : 구조적 언어, 의사 결정표, 의사 결정도 => 의사코드는 해당하지 않음

 

 

 

 

29. 요구사항 협상

• 요구사항이 서로 충돌하는 경우 적절히 해결하는 과정
• ex) 두 명의 이해 관계자가 요구하는 요구사항이 서로 충돌되는 경우, 요구사항과 자원이 서로 충돌되는 경우, 기능 요구사항과 비기능 요구사항이 서로 충돌되는 경우

 

 

 

 

31. HIPO(Hierarchy Input Process Output)

• 기능 중심의 도형 표현에 편리
• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법
• 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타냄

 

 

 

 

34. HIPO Chart

• 가시적 도표(도식 목차) : 시스템의 전체적인 기능과 흐름을 보여주는 계층 구조도
• 총체적 도표(총괄도표, 개요 도표) : 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표
• 세부적 도표(상세 도표) : 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

 

 

 

 

35, 36. UML의 관계(Relationships) 화살표 모양

• 연관(Association) 관계 : →
• 집합(Aggregation) 관계 : ―◇
• 포함(Composition) 관계 : ―◆
• 일반화(Generalization) 관계 : ―▷
• 의존(Dependency) 관계 : ·····>
• 실체화(Realization) 관계 : ·····▷

 

 

 

 

37. 추상화(Abstraction) => 소프트웨어 아키텍처

• 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시켜 나가는 것
• 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법
• 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 데체하는 방법
• 제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법

 

 

 

 

40. 소프트웨어 아키텍처의 설계 과정

• 설계 목표 설정 → 시스템 타입 결정 → 아키텍처 패턴 적용 → 서브시스템 구체화 → 검토

 

 

 

 

41. 소프트웨어 설계 방식

• 객체 지향 설계 : 객체지향 설계 원칙을 기반으로 하여 소프트웨어를 설계하는 방식
• 데이터 흐름 설계 : 프로세스와 프로세스 간의 데이터 흐름에 중점을 두고 소프트웨어를 설계하는 방식
• 상향식 설계 : 최하위 수준에서 각각의 모듈을 설계하고, 완성된 모듈을 결합해 가면서 설계하는 방식
• 하향식 설계 : 제일 상위에 있는 main user function에서 시작하여 기능을 하위 기능들로 분할해 가면서 설계하는 방식

 

 

 

 

47. 아키텍처 패턴

• MVC Pattern : 서브시스템을 3개의 부분으로 구조화한 패턴
• Pipe-Filter Pattern : 한 모듈이 데이터 스트림을 입력받아 처리하면, 다음 모듈이 결과를 이어받아 처리하는 형식;
• Peer-To-Peer Pattern : 피어를 하나의 컴포넌트로 간주하며, 각 피어는 서비스를 호출하는 클라이언트가 될 수도, 서비스를 제공하는 서버가 될 수도 있는 패턴
• Broker Pattern : 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결해줌

 

 

 

 

50, 51, 54, 55. 객체지향의 주요 구성요소

• Class : 하나 이상의 유사한 객체를 묶어 하나의 공통된 특성을 표현하는 요소 (같은 특성을 갖는 객체를 표현한 것)
• Inheritance : 이미 정의된 상위 클래스의 메소드를 비롯한 모든 속성을 하위 클래스에게 재정의하지 않고서도 항상 이용 가능하도록 허용하는 성질
• Instance : 클래스에 속한 각각의 객체
• Method : 객체에 정의된 연산을 의미. 객체의 상태를 참조하거나 변경하는 수단이 됨
• Message : 외부로부터 하나의 객체에 전달되는 메소드(행위)의 요구를 의미. 객체가 목적지, 연산할 내용, 인자를 함께 표시하여 다른 객체로 전송되는 메커니즘
• Polymorphism : 하나의 메시지에 대해 각 클래스가 가지고 있는 고유한 방법으로 응답할 수 있는 능력을 나타내는 것

 

 

 

 

58. 객체지향 방법론

• Coad와 Yourdon 기법 : E-R 다이어그램을 사용하여 객체의 행위를 모델링이라 하며, 객체 식별, 구조 식별, 주제 저으이, 속성과 인스턴스 연결 정의, 연산과 메세지 연결 정의 등의 과정으로 구성하는 기법
• Rumbaugh 기법 : 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행하는 방법
• Booch 기법 : 데이터 흐름도(DFD)를 사용해서 객체를 분해하고, 객체들 간의 인터페이스를 찾아 Ada 프로그램으로 변환시키는 기법

 

 

 

 

63. GoF의 디자인 패턴

• 생성 패턴 : Abstract Factory, Builder, Factory Method, Prototype, Singleton
• 구조 패턴 : Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
• 행위 패턴 : Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor