정보처리기사 필기) 시나공 모의고사 정리 - 1과목 소프트웨어 설계
본문 바로가기
정보처리기사/정보처리기사 필기

정보처리기사 필기) 시나공 모의고사 정리 - 1과목 소프트웨어 설계

by 코딩하는 핑가 2020. 8. 18.
반응형

1회

2. 스크럼 개발 과정

- 스프린트 계획 회의 > 스프린트 > 일일 스크럼 회의 > 스프린트 검토 회의 > 스프린트 회고

- Sprint Planning Meeting > Sprint > Daily Scrum Meeting > Sprint Review > Sprint Retrospective

- 계획한 내용을 토대로 일정 기간동안 스프린트를 수행하면서 진행 상황을 매일 점검하고 하나의 스프린트가 끝나면 검토한 후 진행을 되돌아봄

 

4. 웹 애플리케이션 서버(WAS)에 대한 요구사항 식별 시 고려해야 할 사항

* 가용성, 성능, 기술지원, 구축비용

- 가용성 : 장시간 운영 시 발생할 수 있는 고유의 장애 발생 가능성

- 성능 : 대규모의 트랜잭션 처리 능력 및 다양한 옵션 지원

- 기술 지원 : 제조업체의 안정적인 기술 지원 및 여러 사용자들 간의 정보 공유

- 구축 비용 : 라이선스, 유지관리 등에 대한 비용

 

7. 요구사항 확인 기법

* 인수 테스트

- 사용자가 실제로 사용할 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 과정

- 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획이 필요

* 모델 검증(Model Verification)

- 요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것

* 프로토타이핑(Prototyping)

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

* 요구사항 검토(Requirement Reviews)

- 문서화된 요구사항을 훑어보면서 확인하는 것으로 가장 일반적인 요구사항 검증 방법

 

11. 웹의 3요소

* 웹 표준, 웹 접근성, 웹 호환성

- 웹 표준(Web Standards) : 웹에서 사용되는 규칙 또는 기술을 의미하는 것으로, 웹 사이트 작성 시 이용하는 HTML, JavaScript 등에 대한 규정, 웹 페이지가 다른 기종이나 플랫폼에서도 구현되도록 제작하는 기법 등을 포함함

- 웹 접근성(Web Accessibility) : 누구나, 어떠한 환경에서도 웹 사이트에서 제공하는 모든 정보를 접근하여 이용할 수 있도록 보장하는 것

- 웹 호환성(Cross Browsing) : 하드웨어나 소프트웨어 등이 다른 환경에서도 모든 이용자에게 동등한 서비스를 제공하는 것

 

20. 인터페이스 표준 항목

- 송수신 시스템을 연계하는데 표준적으로 필요한 데이터를 의미

- 시스템 공통부, 거래 공통부로 나뉨

* 시스템 공통부

- 시스템 간 연동 시 필요한 공통 정보

- 구성 정보 : 인터페이스 ID, 전송 시스템 정보, 서비스 코드 정보, 응답 결과 정보, 장애 정보

* 거래 공통부

- 시스템들이 연동된 후 송수신되는 데이터를 처리할 때 필요한 정보

- 구성 정보 : 직원 정보, 승인자 정보, 기기 정보, 매체 정보

 

2회

5. UML의 관계(Relationships)

* 연관(Association) 관계

- 2개 이상의 사물이 서로 관련되어 있음

* 집합(Aggregation) 관계

- 하나의 사물이 다른 사물에 포함되어 있는 관계

* 포함(Compsition) 관계

- 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

* 일반화(Generalization) 관계

- 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 포현하는 관계

* 의존(Depenency) 관계

- 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시 간 동안만 연관을 유지하는 관계

* 실체화(Realization) 관계

- 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계

 

6. UML의 구조적(Structural) 다이어그램

* 클래스 다이어그램(Class Diagram)

- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현

- 시스템의 구조를 파악하고 구조상의 문제점을 도출할 수 있음

* 객체 다이어그램(Object Diagram)

- 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현

* 배치 다이어그램(Deployment Diagram)

- 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현

- 노드와 의사소통(통신) 경로로 표현

- 구현 단계에서 사용되는 다이어그램

* 복합체 구조 다이어그램(Composite Structure Diagram)

- 클래스나 컴포넌트가 복합 구조를  갖는 경우 그 내부 구조를 표현함

* 패키지 다이어그램(Package Diagram)

- 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현함

 

9. 유스케이스(Use Case)

- 사용자의 요구사항을 정리하고 기록하기 위한 도구

- 완성된 유스케이스에 대해 유스케이스 명세서를 작성

- 일반적으로 다이어그램 형식으로 작성

* 와이어프레임 : 현재 진행 상태 등을 공유하는 데 적합한 도구

 

10. 추상화(Abstraction)

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

- 인간이 복잡한 문제를 다룰 때 가장 기본적으로 사용하는 방법

- 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테스트할 수 있음

- 최소의 비용으로 실제 상황에 대처할 수 있고, 시스템의 구조 및 구성을 대략적으로 파악할 수 있게 해줌

* 추상화의 유형

- 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법

- 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법

- 제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법

 

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

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

- 설계 목표 설정 : 시스템의 개발 방향을 명확히 하기 위해 설계에 영향을 주는 비즈니스 목표, 우선순위 등의 요구사항을 분석하여 전체 시스템의 설계 목표를 설정함

- 시스템 타입 결정 : 시스템과 서브시스템의 타입을 결정하고, 설계 목표와 함께 고려하여 아키텍처 패턴을 선택함

- 서브시스템 구체화 : 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스를 정의함

- 검토 : 아키텍처가 설계 목표에 부합하는지, 요구사항이 잘 반영되어 있는지, 설계의 기본 원리를 만족하는지 등을 검토

 

18. 인터페이스 처리 유형

* 실시간 방식

- 사용자가 요청한 내용은 바로 처리해야 할 때 사용하는 방식

* 지연 처리 방식

- 데이터를 매건 단위로 처리할 경우 비용이 많이 발생할 때 사용하는 방식

* 배치 방식

- 대량의 데이터를 처리할 때 사용하는 방식

3회

6. 비기능 요구사항(Non-functional Requirements)

- 시스템 장비 구성 요구사항

- 성능, 인터페이스, 데이터, 테스트, 보안, 품질 요구사항

- 제약사항

- 프로젝트 관리, 프로젝트 자원 요구사항

* 기능 요구사항(Functioanl Requirements)

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

- 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야하는지에 대한 사항

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

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

 

7. 요구공학(Requirements Engineering)

- 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문

- 점점 복잡하고 대형화되어가는 소프트웨어 개발 환경에 따라 사용자 요구사항도 더욱 복잡해지고 잦은 변경이 발생하는데, 이는 요구사항에 문제가 발생할 가능성을 높이며 요구사항 관리가 잘못될 수 있는 원인이 된다.

- 요구공학은 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것을 목표로 한다.

 

9. 요구사항 분석 기법

- 요구사항 분류(Requirement Classification)

- 개념 모델링(Conceptual Modeling)

- 요구사항 할당(Requirement Allocation)

- 요구사항 협상(Requirement Negotiation)

- 정형 분석(Formal Analysis)

반응형

댓글