[ 1과목:소프트웨어 설계 ]
1. User Interface 설계 시 오류 메시지나 경고에 관한 지침으로 가장 거리가 먼 것은?
① 메시지는 이해하기 쉬워야 한다.
② 오류로부터 회복을 위한 구체적인 설명이 제공되어야 한다.
③ 오류로 인해 발생 될 수 있는 부정적인 내용을 적극적으로 사용자들에게 알려야 한다.
④ 소리나 색의 사용을 줄이고 텍스트로만 전달하도록 한다.
User Interface의 설계 지침은 다음과 같습니다.
1) 사용자 중심 (쉽게 사용 가능한가?)
2) 일관성 (빠른 습득이 가능한가?)
3) 단순성 (조작 방법이 간단한가?)
4) 가시성 (주요 기능이 메인화면에 있는가?)
5) 표준화 (디자인이 표준화되어 쉽게 사용 가능한가?)
6) 접근성 (다양한 계층을 수용 가능한가?)
7) 결과 예측 가능 (기능만으로 결과 예측이 가능한가?)
8) 명확성 (사용자 관점에서 개념적으로 쉽게 인지 가능한가?)
9) 오류 발생 해결 (오류 발생 시 사용자가 상황을 정확히 인지 가능한가?)
User Interface의 설계 원칙은 다음과 같습니다.
1) 직관성 (누구나 쉽게 이해하고 사용 가능한가?)
2) 유효성 (사용자의 목적달성을 위해 유용하고 효과적인가?)
3) 학습성 (사용자가 쉽게 배우고 익힐 수 있는가?)
4) 유연성 (사용자의 요구를 최대한 수용하며 오류를 최소화하는가?)
1번 보기는 설계원칙의 직관성, 설계지침의 사용자 중심과 관련,
2번, 3번 보기는 설계원칙의 유연성, 설계 지침의 오류 발생 해결과 관련이 있습니다.
2. 다음 중 애자일(Agile) 소프트웨어 개발에 대한 설명으로 틀린 것은?
① 공정과 도구보다 개인과의 상호작용을 더 가치 있게 여긴다.
② 동작하는 소프트웨어보다는 포괄적인 문서를 가치 있게 여긴다.
③ 계약 협상보다는 고객과의 협력을 가치 있게 여긴다.
④ 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.
애자일 방법론은 고객과의 협업에 초점을 두어 빠르게 개발하기 위한 방법입니다.
또한 설계 변경에 신속히 대응하기 위한 방법이며, 문서 중심이 아니라 실행 가능한 S/W를 중시합니다.
3. 소프트웨어 설계에서 요구사항 분석에 대한 설명으로 틀린 것은?
① 소프트웨어가 무엇을 해야하는가를 추적하여 요구사항 명세를 작성하는 작업이다.
② 사용자의 요구를 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정하는 단계이다.
③ 소프트웨어 시스템이 사용되는 동안 발견되는 오류를 정리하는 단계이다.
④ 소프트웨어 개발의 출발점이면서 실질적인 첫 번째 단계 이다.
SWEBOK에 따른 요구사항 개발 프로세스는 다음과 같습니다.
1) 도출 (Elicitation)
2) 분석 (Analysis)
3) 명세 (Specification)
4) 확인 (Vaildation)
요구사항 분석은 요구사항 개발 프로세스의 두 번째 단계(분석, Analysis)로 볼 수 있습니다.
요구사항 분석(Requirement Analysis)은 S/W가 환경과 어떻게 상호작용하는지 이해하고,
사용자의 요구사항을 걸러내기 위한 과정을 통하여 요구사항을 도출하고, 요구사항 정의를 문서화하는 과정입니다.
소프트웨어 시스템이 사용되는 동안 발견되는 오류를 정리하는 단계는 소프트웨어 유지보수 프로세스에 해당하므로,
SWEBOK에 따른 요구사항 개발 프로세스에 해당되지 않습니다.
4. 객체지향 기법에서 상위 클래스의 메소드와 속성을 하위 클래스가 물려받는 것을 의미하는 것은?
① Abstraction
② Polymorphism
③ Encapsulation
④ Inheritance
상위 클래스의 메소드와 속성을 하위 클래스가 물려받는 것을 의미하는 것은
객체지향의 5가지 특징 중 "상속성(Inheritance)"입니다.
객체지향의 5가지 특징은 아래와 같습니다.
1) 캡슐화 (Encapsulation)
: 서로 관련성이 높은 데이터(속성)와 그와 관련된 기능(메소드/함수)을 묶는 것
2) 정보은닉 (Information Hiding)
: 객체 내부의 속성과 메소드를 숨기고, 공개된 인터페이스를 통해서만 메시지를 주고받을 수 있게 하는 것
3) 추상화 (Abstraction)
: 시스템 내의 공통 성질을 추출하여 추상 클래스를 설정하는 것
4) 상속성 (Inheritance)
: 상위 클래스의 메소드와 속성을 하위 클래스가 물려받는 것
5) 다형성 (Polymorphism)
: 객체가 다양한 모양을 가지는 성질 (현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가하고 싶을 때 사용)
5. 설계 기법 중 하향식 설계 방법과 상향식 설계 방법에 대한 비교 설명으로 가장 옳지 않은 것은?
① 하향식 설계에서는 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다.
② 하향식 설계에서 레벨이 낮은 데이터 구조의 세부 사항은 설계초기 단계에서 필요하다.
③ 상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.
④ 상향식 설계에서는 인터페이스가 이미 성립되어 있지 않더라도 기능 추가가 쉽다.
상향식 설계와 하향식 설계는 소프트웨어 개발 방법론에서 언급되는 내용입니다.
상향식/하향식 설계에 대한 내용은 아래와 같습니다.
상향식 설계 : 가장 기본적인 컴포넌트를 먼저 설계 => 이를 사용하는 상위 수준의 컴포넌트 설계
하향식 설계 : 최상위의 Main User Function 먼저 설계 => 하위 기능으로 나누어가며 설계
6. 자료흐름도(DFD)의 각 요소별 표기 형태의 연결이 옳지 않은 것은?
① Process : 원
② Data Flow : 화살표
③ Data Store : 삼각형
④ Terminator : 사각형
자료흐름도 (Data Flow Diagram; DFD)의 4가지 구성 요소는 아래와 같습니다.
1) [ 처리 (Process) ] : 원
2) [ 자료 흐름 (Data Flow) ] : 화살표
3) [ 자료 저장소 (Data Store) ] : 직선 (단선 / 이중선)
4) [ 단말 (Terminator) ] : 사각형
Data Store(자료 저장소)는 삼각형이 아닌 직선(단선 / 이중선)으로 표기됩니다.
7. 소프트웨어 개발에 이용되는 모델(Model)에 대한 설명 중 거리가 먼 것은?
① 모델은 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현한다.
② 모델을 통해 소프트웨어에 대한 이해도를 향상시킬 수 있다.
③ 모델을 통해 이해 당사자 간의 의사소통이 향상된다.
④ 모델을 통해 향후 개발될 시스템의 유추는 불가능하다.
소프트웨어 개발 프로세스는 소프트웨어를 개발할 때 필요한 절차와 과정을 말합니다.
소프트웨어를 개발할 때 필요한 절차와 과정을 체계화하여 정의한 것이 소프트웨어 개발 프로세스 모델입니다.
소프트웨어 개발 프로세스 모델에서 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현할 수 있으며,
소프트웨어에 대한 이해도를 향상시킬 수 있습니다. 모델을 통해 당사자 간 의사소통이 향상되며,
향후 개발될 시스템을 유추할 수 있습니다.
8. 다음의 설명에 해당하는 언어는?
| 객체 지향 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화하는데 사용된다. 즉, 개발하는 시스템을 이해하기 쉬운 형태로 표현하여 분석가, 의뢰인, 설계자가 효율적인 의사소통을 할 수 있게 해준다. 따라서, 개발 방법론이나 개발 프로세스가 아니라 표준화된 모델링 언어이다. |
① JAVA
② C
③ UML
④ Python
해당 설명은 UML에 대한 설명입니다.
Unified Modeling Language (통합 모델링 언어)는 말 그대로 모델링 언어로, *모델링을 하기 위한 언어입니다.
*모델링? : 데이터를 추상화하여 컴퓨터로 옮기는 변환 과정.
9. 다음 내용이 설명하는 UI설계 도구는?
| - 디자인, 사용방법설명, 평가 등을 위해 실제 화면과 유사하게 만든 정적인 형태의 모형 - 시각적으로만 구성 요소를 배치하는 것으로 일반적으로 실제로 구현되지는 않음 |
① 스토리보드(Storyboard)
② 목업(Mockup)
③ 프로토타입(Prototype)
④ 유스케이스(Usecase)
해당 설명은 목업(Mockup)에 대한 설명입니다.
UI 설계 도구들에 대한 설명은 다음과 같습니다.
Wire Frame (와이어 프레임) : UI 중심의 화면 레이아웃을 선(Wire)을 이용하여 개략적으로 작성
Mockup (목업) : 시각적으로 구성요소를 배치하는 것으로 일반적으로 실제 구현은 X / "유사하게 만든 모형"
Prototype(프로토타입) : 상호작용(Interaction)이 결합하여 "실제 작동하는 모형"
Storyboard(스토리보드) : 정책, 프로세스, 와이어프레임, 설명이 모두 포함된 "설계 문서"
10. 애자일(Agile) 기법 중 스크럼(Scrum)과 관련된 용어에 대한 설명이 틀린 것은?
① 스크럼 마스터(Scrum Master)는 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할 등을 맡는다.
② 제품 백로그(Product Backlog)는 스크럼 팀이 해결해야 하는 목록으로 소프트웨어 요구사항, 아키텍처 정의 등이 포함될 수 있다.
③ 스프린트(Sprint)는 하나의 완성된 최종 결과물을 만들기 위한 주기로 3달 이상의 장기간으로 결정된다.
④ 속도(Velocity)는 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치로 볼 수 있다.
애자일(Agile) 개발 방법론에는 스크럼(Scrum), 익스트림 프로그래밍(XP; eXtreme Programming),
기능 주도 개발(FDD; Feature Driven Development), 린(Lean) 등이 있습니다.
이 중 스크럼(Scrum)방식은 요구사항 변경에 신속하게 대처할 수 있도록 "반복적"이고 "점진적"인 소규모 팀원 간
활발한 소통과 협동심이 필요한 팀 중심의 소프트웨어 개발 방법론입니다.
스크럼 팀의 역할은 아래와 같습니다.
제품 책임자(Product Owner)
: 개발 목표에 이해도가 높은 의뢰자,사용자가 담당
: 제품 요구사항 파악 => 기능 목록(Product Backlog) 작성
: 업무 관점에서 우선순위, 중요도 표시, 신규항목 추가
: 스프린트가 시작되면 팀 운영에 관여 X
스크럼 마스터
: 업무 배분 및 지원(일 강요 X) / 개발 과정 장애 요소 제거 등
스크럼 팀
: 제품 책임자, 스크럼 마스터를 제외한 팀원 (5~9명 내외)
: 기능을 작업 단위로 분류, 요구사항을 사용자 스토리로 도출 및 구현
: 일정, 속도를 추정 => 제품 책임자에게 전달
: 스프린트 결과물을 제품 책임자에게 시연
: 매일 스크럼 회의에 참여 => 진행 상황 점검
스프린트(Sprint)는 작은 단위의 개발 업무를 단기간에 전력 질주하여 개발한다는 의미로, 반복 주기는 2~4주입니다.
11. UML 다이어그램 중 정적 다이어그램이 아닌 것은?
① 컴포넌트 다이어그램
② 배치 다이어그램
③ 순차 다이어그램
④ 패키지 다이어그램
UML 다이어그램 종류
UML 다이어그램은 크게 [ 구조 / 행위 ] 다이어그램으로 나뉩니다.
위 구조/행위 다이어그램은 각각 [ 정적 / 동적 ] 모델링 방식입니다.
순차 다이어그램(Sequence Diagram)은 행위 Diagram에 속하는 동적 다이어그램입니다.
12. LOC기법에 의하여 예측된 총 라인수가 36000라인, 개발에 참여할 프로그래머가 6명, 프로그래머들의 평균 생산성이 월간 300라인일 때 개발에 소요되는 기간을 계산한 결과로 가장 옳은 것은?
① 5개월
② 10개월
③ 15개월
④ 20개월
LOC(Line Of Code; 원시 코드 라인 수) 기법(방법)은 프로그램의 라인 수를 평가하여 비용을 산정하는 방법입니다.
LOC 계산 방법은 아래와 같습니다.
예측치 = { 낙관치 + ( 4 × 기대치 ) + 비관치 } ÷ 6
개발 기간 = 인월 ÷ 투입 인원
개발 비용 = 인월 × 단위 비용
인월 = 개발 기간 × 투입 인원
생산성 = LOC ÷ 인월
(인월 : man per month / man-month , 개발자 1인이 1개월동안 개발하는 양)
[ LOC = 36000 , 투입 인원 = 6 , 인월 = 6a ] 로 계산하겠습니다.
즉, a가 개발 기간이 되는 것입니다.
생산성이 월간 300라인이므로
36000 / 6a = 300이 됩니다.
따라서 a(개발 기간) = 20(개월)이 됩니다.
13. 클래스 설계원칙에 대한 바른 설명은?
① 단일 책임원칙 : 하나의 클래스만 변경 가능 해야한다.
② 개방-폐쇄의 원칙 : 클래스는 확장에 대해 열려 있어야 하며 변경에 대해 닫혀 있어야 한다.
③ 리스코프 교체의 원칙 : 여러 개의 책임을 가진 클래스는 하나의 책임을 가진 클래스로 대체되어야 한다.
④ 의존관계 역전의 원칙 : 클라이언트는 자신이 사용하는 메소드와 의존관계를 갖지 않도록 해야 한다.
객체지향 프로그래밍의 5가지 설계 원칙 SOLID는 아래와 같습니다.
S : SRP (단일 책임 원칙) - 모듈이 변경되는 이유는 한가지여야 한다.
O : OCP (개방-폐쇄 원칙) - 확장에 대해 열려있으나 수정에 대해 닫혀있어야 한다.
L : LSP (리스코프 교체 원칙) - 하위 타입은 상위 타입을 대체할 수 있어야 한다.
I : ISP (인터페이스 분리 원칙) - 클라이언트의 목적과 용도에 적합한 인터페이스만을 제공한다.
D : DIP (의존 역전 원칙) - 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다. (반대여야 함)
14. GoF(Gangs of Four) 디자인 패턴에서 생성(Creational) 패턴에 해당하는 것은?
① 컴퍼지트(Composite)
② 어댑터(Adapter)
③ 추상 팩토리(Abstract Factory)
④ 옵서버(Observer)
GoF(Gangs of Four) 디자인 패턴은 [ 생성 / 구조 / 행위 ] 패턴으로 분류됩니다.
생성 패턴의 구성 : Abstraction Factory, Singleton, Prototype, Builder
구조 패턴의 구성 : Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
행위 패턴의 구성 : Chain of Responsibility, Iterator, Command, Interpreter, Memento, Observer, State, Strategy, Visitor, Template Method, Mediator
추상 팩토리 (Abstract Factory)는 생성(Creational) 패턴에 해당합니다.
컴퍼지트 (Composite)와 어댑터 (Adapter)는 구조 패턴, 옵서버 (Observer)는 행위 패턴에 해당합니다.
15. 아키텍처 설계과정이 올바른 순서로 나열된 것은?
| ㉮ 설계 목표 설정 ㉯ 시스템 타입 결정 ㉰ 스타일 적용 및 커스터마이즈 ㉱ 서브시스템의 기능, 인터페이스 동작 작성 ㉲ 아키텍처 설계 검토 |
① ㉮ → ㉯ → ㉰ → ㉱ → ㉲
② ㉲ → ㉮ → ㉯ → ㉱ → ㉰
③ ㉮ → ㉲ → ㉯ → ㉱ → ㉰
④ ㉮ → ㉯ → ㉰ → ㉲ → ㉱
아키텍처 설계 과정은 아래와 같습니다.
1) 목표 설정
2) 시스템 타입 결정
3) 스타일 적용 및 커스터마이즈
4) 서브시스템 기능, 인터페이스 동작 생성
5) 아키텍처 설계 검토
16. 사용자 인터페이스를 설계할 경우 고려해야 할 가이드라인과 가장 거리가 먼 것은?
① 심미성을 사용성보다 우선하여 설계해야 한다.
② 효율성을 높이게 설계해야 한다.
③ 발생하는 오류를 쉽게 수정할 수 있어야 한다.
④ 사용자에게 피드백을 제공해야 한다.
UI 설계 지침은 아래와 같습니다.
1) 사용자 중심 (쉽게 사용 가능한가?)
2) 일관성 (빠른 습득이 가능한가?)
3) 단순성 (조작 방법이 간단한가?)
4) 가시성 (주요 기능이 메인화면에 있는가?)
5) 표준화 (디자인이 표준화되어 쉽게 사용 가능한가?)
6) 접근성 (다양한 계층을 수용 가능한가?)
7) 결과 예측 가능 (기능만으로 결과 예측이 가능한가?)
8) 명확성 (사용자 관점에서 개념적으로 쉽게 인지 가능한가?)
9) 오류 발생 해결 (오류 발생 시 사용자가 상황을 정확히 인지 가능한가?)
보기 1번의 "심미성을 사용성보다 우선하여 설계해야 한다"는 UI 설계 지침사항 중 사용자 중심에 반하는 내용입니다.
17. 소프트웨어 설계에서 자주 발생하는 문제에 대한 일반적이고 반복적인 해결 방법을 무엇이라고 하는가?
① 모듈 분해
② 디자인 패턴
③ 연관 관계
④ 클래스 도출
기존 환경 내에서 반복적으로 발생하는 문제들에 일반적이고 반복적인 해결 방법은 "디자인 패턴(Design Pattern)"입니다.
대표적인 디자인 패턴은 GoF(Gangs of Four) 디자인 패턴이며, [ 생성 / 구조 / 행위 ] 패턴으로 분류됩니다.
18. 객체지향 분석기법의 하나로 객체 모형, 동적 모형, 기능 모형의 3개 모형을 생성하는 방법은?
① Wirfs-Block Method
② Rumbaugh Method
③ Booch Method
④ Jacobson Method
객체지향 분석(OOA; Object Oriented Analysis) 방법론 종류는 아래와 같습니다.
1) Rumbaugh
: 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 객체지향 분석 (가장 일반적)
: 분석 절차는 [ 객체 모델링 - 동적 모델링 - 기능 모델링 ] (즉, 객체/동적/기능 모형을 생성하는 방법)
2) Booch
: 미시적(Micro) 개발 프로세스, 거시적(Macro) 개발 프로세스 모두 사용
: 클래스와 객체들을 분석 및 식별, 클래스의 속성과 연산을 정의
3) Jacobson
: Use Case를 사용하여 분석
4) Coad와 Yourdon
: E-R Diagram을 사용 => 객체의 행위 모델링
: 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의
: 연산과 메시지 연결 정의 등의 과정으로 주로 관계를 분석하는 기법
5) Wirfs-Brock
: 분석과 설계간 구분이 없음
: 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법
19. 입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어를 말하는 것은?
① EAI
② FEP
③ GPL
④ Duplexing
입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는
시간을 줄여주는 프로그램이나 하드웨어는 FEP (Front-End Processer)입니다.
일반적으로 대형 컴퓨터 시스템에서 시간을 절약하기 위해 입력되는 데이터를
"미리 가공/처리 후 주 컴퓨터로 전송"하는 역할을 하는 소형 처리 장치입니다.
20. 객체 지향 개념 중 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화를 의미하는 것은?
① Method
② Class
③ Field
④ Message
객체지향 구성 요소는 아래와 같습니다.
1) Class : 유사한 객체를 정의한 집합
2) Object : Class에 속한 Instance (데이터와 함수를 묶어 캡슐화하는 대상이 됨)
2-1) Attribute : Object가 가진 데이터 값
2-2) Method : Object의 행위인 함수
3) Message : Object 간 주고받는 통신
하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화를 의미하는 것(또는 단위)은 Class입니다.
'정보처리기사 필기' 카테고리의 다른 글
| 정보처리기사 22_04_24 필기 [4과목] (1) | 2023.05.16 |
|---|---|
| 정보처리기사 22_04_24 필기 [3과목] (1) | 2023.05.15 |
| 정보처리기사 22_03_05 필기 [2과목] (0) | 2023.05.04 |
| 정보처리기사 22_04_24 필기 [2과목] (0) | 2023.05.03 |
| 정보처리기사 22_04_24 필기 [1과목] (0) | 2023.05.01 |