이 게시글은 정보처리기사 실기 준비를 위해 수제비책과 ToDev님 블로그를 참조했으며
N번째 시험을 겪으며 중요하다고 느껴지는 개념을 위주로 담았고
이번 시험이 마지막이길 기원하며 정리한 글입니다.
개념의 설명을 보고 어떤 개념인지 유추하고 맞춰보며 학습하도록 빈칸을 쳐 놓았습니다.
드래그를 통해 답을 맞춰보실 수 있습니다.
01 소프트웨어 개발 방법론
▶ 소프트웨어 생명주기(SDLC)
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
▶ 소프트웨어 생명 주기 모델 종류
⦁ 폭포수 모델 : 각 단계를 확실히 마무리 지은 후에 다음단계로 넘어간다.
⦁ 프로토타이핑 모델 : 프로토타입을 구현해, 고객의 피드백을 반영하며 만들어 간다.
⦁ 나선형 모델 : 위험을 최소화하기 위해 점진적으로 개발한다.
⦁ 반복적 모델 : 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발한다.
▶ 소프트웨어 개발방법론 종류
⦁ 구조적 방법론 : 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합한다. 나씨-슈나이더만 차트 사용
⦁ 정보공학 방법론 : 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화
⦁ 객체지향 방법론 : ‘객체’라는 기본 단위로 시스템 분석 및 설계
⦁ 컴포넌트 기반 방법론(CBD) : 컴포넌트를 조립해 하나의 새로운 운용 프로그램 작성
⦁ 애자일 방법론 : 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템 개발
⦁ 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발, 임베디드
▶ 애자일 방법론의 유형
⦁ XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질 높이기 위한 방법론
⦁ SCRUM : 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 방법론
⦁ LEAN : 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해 낭비 요소를 제거하는 방법론
▶ XP의 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존중
▶ XP의 12가지 기본원리
⦁ 짝 프로그래밍 : 개발자 둘이서 짝으로 코딩하는 원리
⦁ 지속적인 통합(CI) : 매일 여러 번씩 소프트웨어를 통합하고 빌드
⦁ 메타포어(Metaphor) : 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다.
⦁ 테스트 기반 개발(TDD) : 만들 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다.
⦁ 리팩토링(Refactoring) : 프로그램의 기능은 바꾸지 않고 중복제거, 단순화 등을 위해 시스템 재구성을 한다.
▶ 델파이 기법
전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법
▶ 비용 산정 모형 종류
⦁ LoC(Line of Code) 모형 : 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정해 예측치를 구해 비용을 산정하는 방식
⦁ Man Month 모형 : 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용 산정하는 방식
⦁ COCOMO 모형 : 보헴이 제한, 프로그램 규모에 따른 비용 산정
- 조직형(Organic Mode) : 5만 라인 이하
- 반 분리형(Semi-Detached Mode) : 30만 라인 이하
- 임베디드형(Embedded Mode) : 30만 라인 이상
⦁ 푸트남 모형 : 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식, 생명주기 예측 모형, Rayleigh-Norden 곡선
⦁ 기능점수(FP; Fuction Point) 모형 : 요구 기능에 따른 가중치 부여
▶ 일정관리 모델 : 일정 기한 내에 적절하게 완료될 수 있도록 관리
⦁ 주 공정법(CPM) : 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정 계산
* 주 공정(Critical Path) : 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로
⦁ PERT : 일의 순서를 계획적으로 정리하기 위한 수렴 기법, 비관치, 중간치, 낙관치를 이용
⦁ 주 공정 연쇄법(CCPM) : 자원제약사항을 고려해 일정 작성
02 현행 시스템 분석
▶ 현행 시스템 파악
구성/기능/인터페이스 파악 -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악
▶ 소프트웨어 아키텍처
여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체이다.
▶ 소프트웨어 아키텍처 4+1 뷰
고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
⦁ 유스케이스 뷰 : 다른 뷰를 검증하는데 사용
⦁ 논리 뷰 : 시스템의 기능적 요구사항 설명
⦁ 프로세스 뷰 : 시스템의 비기능적 요구사항 설명
⦁ 구현 뷰 : 모듈의 구성, 컴포넌트 구조, 의존성
⦁ 배포 뷰 : 어떻게 배치되는가.
▶ 유스케이스(Usecase)
시스템 요구사항이자, 사용자의 입장에서 바라본 시스템의 기능
▶ 소프트웨어 아키텍처 패턴
소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식
▶ 소프트웨어 아키텍처 패턴 유형
⦁ 계층화(Layered) 패턴 : 시스템을 계층으로 구분해 구성하는 패턴
⦁ 클라이언트-서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴
⦁ 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용
⦁ 브로커(Broker) 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌트들 원격 서비스 실행을 통해 상호작용 가능
⦁ 모델-뷰-컨트롤러 패턴(MVC)
- 모델 : 핵심 기능과 데이터 보관
- 뷰 : 사용자에게 정보 표시
- 컨트롤러 : 사용자로부터 요청 입력 받아 처리
▶ 소프트웨어 아키텍처 비용 평가 모델 종류
⦁ SAAM : 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능
⦁ ATAM : 아키텍처 품질 속성을 만족시키는지 판단
⦁ CBAM : ATAM 바탕의 시스템, 경제적 의사결정에 대한 요구 총족
⦁ ADR : 소프트웨어 아키텍처 구성요소 간 응집도 평가
⦁ ARID : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중
▶ 디자인 패턴
소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
▶ 디자인 패턴의 유형
⦁ 목적
- 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식 구조화, 캡슐화 수행
- 구조 : 클래스나 객체의 조합을 다루는 패턴
- 행위 : 클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패턴
⦁ 범위 : 클래스, 객체
▶ 디자인 패턴 종류
◇ 생성 패턴
⦁ Builder : 복잡한 인스턴스를 조립해 만드는 구조, 복합 객체 생성 시 방법 분리, 서로 다른 표현 결과 만들 수 있음
⦁ Prototype : 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정해 사용하는 패턴
⦁ Factory Method : 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식
⦁ Abstract Factory : 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공하는 패턴
⦁ Singleton : 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴
◇ 구조 패턴
⦁ Bridge : 기능의 클래스 계층과 구현의 클래스 계층을 연결, 구현부에서 추상 계층 분리
⦁ Decorator : 기존에 구현되어 있는 클래스에 필요한 기능 추가해 나감
⦁ Facade : 복잡한 시스템에 대해 단순한 인터페이스 제공, 시스템 구조에 대한 파악 쉽게
⦁ Flyweight : 메모리 절약, ‘클래스의 경량화’ 목적
⦁ Proxy : 실체 객체에 대한 대리 객체, 실체 객체를 드러나지 않게 해 정보은닉
⦁ Composite : 객체들의 관계를 트리 구조로 구성, 부분-전체 계층 표현
⦁ Adapter : 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
◇ 행위 패턴
⦁ Mediator : 중간에 통제, 중재자
⦁ Interpreter : 언어의 다양한 해석, 구문의 해석을 맡는 클래스 가각 작성
⦁ Iterator : 컬렉션 구현 방법 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 방법을 제공
⦁ Template Method : 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화, 상위 클래스-추상, 하위 클래스-구체
⦁ Observer : 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락
⦁ State : 상태에 따라 다르게 처리할 수 있도록 행위 내용 변경
⦁ Visitor : 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업 수행
⦁ Command : 명령이 들어오면 그에 맞는 서브 클래스 선택되어 실행
⦁ Strategy : 알고리즘 군 정의, 행위를 클래스로 캡슐화해 동적으로 행위 자유롭게 변환
⦁ Memento : Undo 기능 개발
⦁ Chain of Responsibility : 정적으로 어떤 기능에 대한 처리의 연결이 하드 코딩 되어 있을 때, 이를 동적으로 연결되어 있는 경우에 따라 다르게 처리될 수 있도록 연결한 디자인
▶ 운영체제
컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스 담당
▶ 운영체제 종류
윈도즈, 유닉스, 리눅스, 안드로이드, iOS
▶ 미들웨어
분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어
03 요구사항 확인
▶ 요구공학(Requirements Engineering)
사용자의 요구가 반영된 시스템을 개발하기 위해서 사용자의 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동
▶ 기능적 요구사항 : 시스템이 제공하는 기능, 서비스에 대한 요구사항(기능성, 완전성, 일관성)
▶ 비기능적 요구사항 : 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항, 품질, 시스템 환경, 프로젝트 계획에 관한 요구사항
▶ 요구사항 도출 단계 주요 기법
⦁ 인터뷰, 워크숍, 브레인스토밍, 설문 조사
⦁ 델파이 기법 : 전문가의 경험지식을 통한 문제 해결 및 미래예측을 위한 방법
⦁ 롤 플레잉 : 현실에서 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함
▶ 정형 기술 검토(요구사항 확인 및 검증 단계의 주요 기법)
⦁ 동료 검토(Peer Review) : 2~3명이 진행, 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견
⦁ 워크 스루(Walk Through) : 회의 전에 검토 자료를 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태
⦁ 인스펙션(Inspection) : 원시 코드 등을 저작자 외의 다른 전문가 또는 팀이 검사해 오류를 찾아내는 공식적 검토 방법
'자격증 > 정보처리기사' 카테고리의 다른 글
| [정보처리기사 실기] 05. 인터페이스 구현 (빈칸버전) (0) | 2022.07.13 |
|---|---|
| [정보처리기사 실기] 04. 통합 구현 (빈칸버전) (0) | 2022.07.13 |
| [정보처리기사 실기] 03. 데이터 입출력 구현 (빈칸버전) ★ (0) | 2022.07.13 |
| [정보처리기사 실기] 02. 화면 설계 (빈칸버전) (0) | 2022.07.13 |
| [정보처리기사 실기] 영역별 출제 문항수, 요약집 + 팁 (0) | 2022.07.13 |
