정보처리기사 실기 요약[요구사항 확인 - Chapter1](정처기)

정보처리기사 실기 정리는 제가 직접 수기로 작성하여 요약한 내용이기 때문에 조금의 오타가 있을 수 있습니다.

Chapter10 - 프로그래밍 언어 활용

Chapter11 - 응용 SW 기초 기술 활용

Chapter2 - 데이터 입출력 구현

본 3파트는 학교 OS, DB 수업과 코딩 테스트를 준비하면서 다른 과목들의 암기 시간을 늘리기 위해 정리(암기)하지 않고 갔습니다.

하지만 양이 많고, 가장 중요하면서 최소 4문제 이상 나오는 파트이기 때문에 준비를 잘해야하는 파트입니다.

시간이 된다면 추후에 추가하겠습니다.

 

요구사항 확인

Chapter 1

HIPO
기본 모델로 입력, 처리, 출력으로 구성되는 시스템 분석 및 설계와 시스템 문서화용 기법
구성 : 가시적 도표, 총체적 다이어그램, 세부적 다이어그램

재공학
소프트웨어 위기를 개발 생산성이 아닌 유지보수의 생산성으로 해결하려는 방법
과정 : 분석, 구성, 역공학, 이식
목표 : 유지보수성 향상, 다른 뷰 생성, 소프트웨어 수명 연장, 재사용이 용이하기 위해

역공학
소프트웨어를 분석해 소프트웨어 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만들어 내는 작업

소프트웨어 생명주기(SWLC)
타당성 검토 - 개발 계획 - 요구사항 분석 - 설계 - 구현 - 테스트 - 운용 - 유지보수

폭포수 모형
Bohem이 제시한 고전적 생명주기 모형, 순차적으로 진행되는 모형

프로토타입 모형
실제 개발될 시스템의 견본을 미리 만들어 최종 결과물을 예측하는 모형

나선형 모형
Boehm이 제시, 반복적인 작업을 수행하는 점증적 생명주기 모형
목적 : 위험 관리,최소화 목적
계획수립 - 위험 분석 - 공학적 개발 - 고객 평가

애자일 방법론
'날렵한, 재빠른'이란 사전적 용어, 소프트웨어 개발을 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있음

XP
Ken Beck제안, 개발 단계 중 요구사항의 변동이 심한 경우 적합한 방법론
5가지 핵심 가치 : 소통, 단순성, 피드백, 용기, 존중
Release Planning : 몇 개 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것
User Story : 유저의 요구사항
Iteration : 하나의 릴리즈를 세분화한 단위 ,1~3주동안 진행 
Acceptance Test, Small Release로 구성

짝 프로그래밍
2사람이 짝이 되어 한사람 코딩, 한사람은 검사를 수행하는 방식

SCRUM
반복적이고 점진적인 소규모 팀 중심 소프트웨어 개발 방법론
구성 : 제품 책임자 , 스크럼 마스터 , 스크럼 팀
Product Backlog : 제품 개발에 필요한 모든 요구사항을 우선순위로 나열한 목록
Sprint : 전력질주, 2~4주 동안 폭발적 개발
Spring Planning Meeting : Backlog에서 진행할 목록 선택, 요구사항을 개발자들이 나눠 작업할 수 있도록 Task 단위로 나눔
Daily SCRUM Meeting : 매일 15분정도 뭐했나 검사 , 스크럼 마스터가 방해요소를 해결하기 위해서 소멸 차트 작성

현행 시스템 파악
정의 : 어떤 하위 시스템으로 구성 되어있는지 파악
목적 : 개발 시스템 개발범위 확인, 이행 방향성 설정 
절차
1. 시스템 구성, 기능 ,인터페이스 현황 파악 
2. 아키텍처 파악 , 소프트웨어 구성 파악
3. 시스템 하드웨어 현황 파악, 네트워크 구성 파악

플랫폼
다양한 애플리케이션이 작동하는데 기본이 되는 운영체제 소프트웨어를 의미
성능 분석 항목 : 가용성 , 응답시간, 사용률

TCO
기업에서 사용하는 정보화 비용에 투자 효과를 고려한 총 소유 비용

DBMS
DB의 종속성과 중복성의 문제를 해결하기 위해서 제안된 시스템
고려사항 : 성능, 가용성, 기술 지원, 상호 호환성, 구축 비용

미들웨어
운영체제와 소프트웨어 애플리케이션 사이에 위치
고려사항 : 성능 , 가용성, 기술 지원, 구축 비용

GNU
유닉스의 상업적 확산에 반발해 리처드 스톨먼과 그의 팀이 무료로 개발해 배포한 유닉스 호환 운영체제
GPLv1 : 1989.1, GPLv2 : 1991.6, GPLv3 : 2007.6 , AGPLv3.0 : 네트워크 서버용, LGPL : GPL보다 완화된 조건의 공개 소프트웨어 라이선스, BSD : 아무나 개작, 수정한 것 제한 없이 배포 할 수 있음.

하둡
다수의 저렴한 컴퓨터를 하나처럼 묶어 대량 데이터를 처리하는 기술

SWEBOK에 따른 요구사항 개발 프로세스
도출 - 분석 - 명세 - 확인

요구사항 분석
시스템 요구사항을 정제해 소프트웨어 요구사항 도출
기능적 요구사항, 비기능적 요구사항으로 구성

UML 다이어그램
시나리오를 표현할 때 사례 다이어그램을 주로 사용
구조 다이어그램 : 시스템의 정적 구조와 다양한 추상화 및 구현 수준에서 시스템의 구성요소, 구성요소간 관계를 보여줌 
행위 다이어그램 : 시스템 내의 객체들의 동적 행위를 보여줌, 시간의 변화에 따른 연속된 변경을 설명

요구사항 명세
시스템 정의서, 소프트웨어 요구사항 명세서, 시스템 요구사항 명세서

요구사항 타당성 검증 사항
무결성 및 완전성, 일관성, 명확성, 기능성, 검증 가능성, 추적 가능성(시스템 요구사항과 시스템 설계문서 추적할 수 있나)

SDLC
소프트웨어 생성부터 소멸까지 정의, 개발, 유지보수 단계로 구분한 것

CMMI
소프트웨어 성숙도 능력이 어느 정도인지 규정하는 지침
초기 - 관리 - 정의 - 정략적 관리 - 최적화

요구사항 관리 프로세스
요구사항 협상, 요구사항 베이스라인, 요구사항 변경관리, 요구사항 확인 및 검증

정형 분석
요구사항 분석의 마지막 단계에서 이루어짐

요구사항 베이스라인
이해 당사자 간에 명시적 합의한 내용이며 프로젝트 목표 달성 여부를 확인하는 기준
-요구사항 정의서 작성단계에서 정립

변경 통제
변경통제 위원회(CCB) 등 회의기구를 통해서 최초 요구사항의 확정 및 확정된 요구사항의 변경을 수행하도록 함.

인수 테스트
사용자 측 관점에서 소프트웨어가 요구사항을 충족시키는지 평가하는 절차
종류 : 베타, 알파 테스트

품질 검증
정적 분석 : 객체 모델에서 객체 사이에 존재하는 의사소통 경로를 검증하기 위해서 사용
동적 분석 : 직접 실행

요구사항 분석시 사용하는 인터뷰 질문 유형 3가지
폐쇄, 자유대답, 유도

Petri-Net
프로세스 마이닝의 가장 기본이 되는 프로세스 모델, 가장 간단한 형태로 프로세스 나타낼 수 있음

소단위 명세서
프로세스 명세서라고도 함. 자료 흐름도의 처리 공정의 절차 기술

개체 관계도(ERD)
1. 개체 2. 속성 3. 관계 로 구성

자료 흐름도 구성
1. 처리공정 2. 자료 흐름 3. 자료 저장소 4. 단말

구조적 분석 모델
사용자의 요구분석 사항을 파악하기 위해 자료의 흐름과 가공 절차를 그림 중심으로 표현하는 방법
절차: 배경도 작성 - 상위 자료 흐름도 작성 - 하위 자료 흐름도 작성 - 자료 사전 작성 - 소단위 명세서 작성

객체지향 분석 모델은 UML로 많이 기록함

분석 모델 검증 절차
사례 모델 검증 - 개념 수준 분석 클래스 검증 - 분석 클래스 검증

분석 클래스 스테레오 타입
1. 경계 2. 제어 3. 엔티티

CASE
소프트웨어 개발 자동화 도구, 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발한 도구
분류 : Upper(요구분석 및 설계), Lower(코드 작성, 테스트, 문서화), Integrate(개발 주기 전체 과정)

자동화 도구 선정시 평가 항목
비용, 업체 지명도, 시장점유율, 호환성, 통합성, 사용 용이성, 숙달 기간, 유지 보수성

럼버우 객체 지향 분석 방법
객체 모델링 : 객체를 다이어그램으로
동적 모델링 : 상태를 시간에 흐름에 따라 표시
기능 모델링 : 자료 흐름도를 이용해 여러 프로세스 간의 자료 흐름

UML 특성
비주얼화, 문서화, 명세화, 구축

UML 관점
기능적 관점(사용자 측면에서 본 소프트웨어 기능), 정적 관점(소프트웨어 내부 구성요소사이 구조적 관계), 동적 관점(내부 활동)

UML 구성
사물, 관계, 다이어그램

스테레오타입
<<>> : 길러멧

UML 접근 제어자
+(public), -(private), #(protected), ~(package)

구조적 다이어그램
정적이고, 구조적 표현을 위한 다이어그램
1. 클래스 : 시스템을 구성하는 클래스 사이 관계
2. 패키지 : 클래스나 유스 케이스 등 여러 요소를 그룹화하여 패키지를 구성해 관계 표현
3. 복합체 : 복합 구조, 컴포넌트 내부 구조 표현
4. 객체 : 객체 정보
5. 컴포넌트 : 컴포넌트 구조 사이 관계
6. 배치 : sw, hw, network 물리적 구조

행위 다이어그램 
동적이고, 순차적 표현을 위한 다이어그램
1. 유스 케이스 : 사용자 관점에서 시스템 행위 
2. 활동 : 업무 처리 과정, 연산이 수행되는 과정
3. 콜라보레이션 : 순차와 같음
4. 상태 머신 : 객체 생명주기
5. 순차 : 시간 흐름에 따른 객체 사이 상호작용(생명선, 통로, 상호작용, 발생, 실행, 상태불변, 상호작용, 메시지, 활성, 객체, 액터)
6. 통신 : 객체 사이 관계를 중심으로
7. 상호작용 개요 : 여러 상호작용 다이어그램 사이에 제어 흐름
8. 타이밍 : 객체 상태 변화와 시간 제약을 명시적

UML 관계
연관 관계, 의존 관계, 일반화 관계(is kind of)(세모), 집합 관계(빈 네모), 포함 관계(채워진 네모), 실체화 관계(점선 세모)

유즈케이스 다이어그램 구성요소
시스템 경계, 액터, 유스 케이스, 접속 관계, 사용 관계, 확장 관계

유즈케이스 다이어그램 작성 단계
1. 액터 식별 2. USE CASE 식별 3. 관계 정의 4. USE CASE 구조화

디자인 패턴 구성 요소
필수 : 패턴 이름, 문제 및 배경, 해법, 결과

생성 패턴
객체를 생성하는 것과 관련
1. Abstraction factory : 서로 연관 되거나 의존적 객체들의 조합을 만드는 인터페이스 제공
2. Builder : 조립하듯 조합
3. Factory Method : Virtual-Contributor
4. Prototype : 원본 객체를 복제하여
5. Singleton : 객체를 하나만 생성

구조 패턴
클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
1. Adpater : 함께 사용할 수 없는 것을 개조해 함께 작동하도록
2. Bridge : 기능 클래스 구현 클래스 연결
3. Composite : 복합 객체와 단일 객체를 클아이언트에서 구별 없이 다루게
4. Decorator : 동적으로 유연하게 확장할 수 있도록
5. Facade : '건물 정면'
6. Flyweight : 인스턴스를 매번 생성안하고 공유하면서
7. Proxy : 네트워크 연결에 사용

행위 패턴
반복적으로 사용되는 객체들의 사용되는 상호작용을 패턴화 한것
1. 책임 연쇄 : 객체 고리 따라 
2. Command : 서로 다른 요청으로 클라이언트 파라미터화
3. Interpreter :언어에 따라 문법에 대한 표현
4. Iterator : 복합 객체의 우너소를 순차적 접근 
5. Mediator : 객체 간의 상호작용을 객체로 캡슐화
6. Memento : 캡슐화 위배 X 객체 내부 상태 객체화 
7. Observer : 일대다의 종속성을 정의
8. State : 내부 상태에 따라 변화
9. Strategy :알고리즘군
10. Template Method : 오퍼레이션에는 알고리즘 처리만, 구체적인건 서브 클래스 정의
11. Visitor : 객체 구조의 요소들에 수행할 오퍼레이션을 표현

디자인 패턴 구조
1. 주제, 목표 2. 문제 3. 해결