[정보처리기사 실기] 1. 요구사항 확인

 

이번 시간은 정보처리기사 실기에서 다루는 1장 요구사항 확인에 대해서 정리를 해보았습니다.

 

* 이 글은 정보처리기사 공부 목적으로 쓴 글입니다. 그러다 보니 혹시 제가 잘못 작성한 부분이 있거나 수정이 필요하다면 댓글로 알려주시면 감사하겠습니다. 

 

 

 

 

 

SDLC (소프트웨어 생명주기)	시스템의 요구분석 ~ 유지보수까지 전 과정을 모델링한 것
SDLC 모델 프로세스	요설구태유 1. 요구사항 분석 : 요구사항을 분석하고, 제약조건∙목표 등을 정의 2. 설계 : 수행 방법을 논리적으로 결정 ex. 시스템 구조 설계, 사용자 인터페이스 설계 3. 구현 : 프로그래밍 언어를 사용해 실제로 코드를 작성 ex. 인터페이스 개발, 자료 구조 개발, 오류 처리 4. 테스트 ex. 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 5. 유지보수
SDLC 모델 종류	폭프나반 1. 폭포수 모델 2. 프로토타이핑 모델 3. 나선형 모델 4. 반복적 모델
폭포수 모델 (Waterfall Model)	- =선형 순차적 모델, =고전적 생명주기 모델 - 각 개발 단계를 마무리 지은 후 넘어가는 모델 - 가장 오래됐고, 성공사례가 많으며, 단계별 산출물이 명확하고, 요구사항 변경이 어려움
프로토타이핑 모델 (Prototyping Model)	- 주요 기능을 프로토타입으로 구현하고, 피드백을 반영해 만들어나가는 모델
나선형 모델 (Spiral Model)	위험을 최소화하기 위해, 점진적으로 개발해나가는 모델 계위개고   - 절차: 계획 및 정의 → 위험 분석 → 개발 → 고객 평가
반복적 모델 (Iteration Model)	병렬적으로 개발 후 통합하거나, 반복적으로 개발해 점차 완성시켜나가는 모델
소프트웨어 개발방법론	소프트웨어의 개발 시작부터 전 개발 과정을 형상화한 방법론 종류: 구정 객컴 애제
구조적 방법론	- 전체 시스템을 나눠 개발하고 통합하는 분할-정복 방식의 방법론 - 나씨-슈나이더만 차트 사용
정보공학 방법론	정보 시스템 개발에 필요한 절차를 체계화한 방법론 (대형 프로젝트)
객체지향 방법론	객체라는 단위로 시스템을 설계하는 방법론
컴포넌트 기반 방법론	컴포넌트를 조립해 작성하는 방법론
애자일 방법론	절차보다 사람이 우선되는, 변화에 유연한 경량 개발 방법론
제품 계열 방법론	제품에 적용할 공통 기능을 정의하여 개발하는 방법론 (임베디드 소프트웨어 작성에 유용)
XP	1~3주의 반복(Iteration) 주기를 갖는 애자일 방법론
XP의 5가지 가치	용단의피존 1. 용기 (용기를 갖고 빠르게 개발!) 2. 단순성 (필요한 것만 하자!) 3. 의사소통 (개발자-관리자-고객 간 원활하게 소통!) 4. 피드백 (의사소통에 대한 빠른 피드백!) 5. 존중 (팀원간 상호 존중!)
XP의 12가지 기본 원리	1. 짝 프로그래밍 (Pair Programming) : 다른 사람과 페어로 개발하여 공동 책임을 지님 2. 공동 코드 소유 (Collective Ownership) : 시스템에 있는 코드는 누구나 언제든 수정 가능 3. 지속적인 통합 (CI; Continuos Integration) : 여러 번 소프트웨어를 통합하고 빌드해야 함 4. 계획 세우기 (Planning Process) : 고객이 원하는 가치를 정의하고, 개발에 필요한 건 무엇이며, 어떤 곳에서 지연이 될 수 있는지 알려줘야 함 5. 작은 릴리즈 (Small Release) : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 6. 메타포어 (Metaphor) : 공통 이름 체계를 통해 의사소통을 원활히 7. 간단한 디자인 (Simple Design) : 요구사항에 적합한 단순한 시스템을 설계 8. 테스트 기반 개발 (TDD; Test Drive Develop) : 테스트를 먼저 수행하고, 통과할 수 있는 코드를 작성 9. 리팩토링 (Refactoring) : 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 코드를 재구성 10. 40시간 작업 (40-Hour Work) : 피곤으로 인한 실수가 없도록 주 40시간만 일합시다 11. 고객 상주 (On Site Customer) : 개발자들의 질문에 즉각 대답해줄 수 있는 고객이 풀타임 상주해야 함 12. 코드 표준 (Coding Standard) : 코딩 표준을 두고 효과적으로 개발
스크럼	매일 정해진 시간/장소에서 짧은 시간의 개발을 위한 애자일 방법론
스크럼 용어	- 백로그 : 제품에 대한 요구사항 - 스프린트 : 짧은 기간 내 반복적으로 으쌰으쌰 - 데일리(스크럼) 미팅 : 매일 To-Do List 계획수립. 번다운 차트 작성 📉 - 스크럼 마스터 : 프로젝트 리더 - 스프린트 회고 : 각자 반성하고 개선점 확인 🙀 - 번 다운 차트 : 남아있는 백로그 대비 시간을 시각적으로 표현 (백로그를 수직, 시간을 수평)
린	낭비 요소를 제거해 품질을 향상시키는 애자일 방법론
린의 7가지 원칙	낭품지확인사전 1. 낭비제거 2. 품질 내재화 3. 지식 창출 4. 늦은 확정 5. 빠른 인도 6. 사람 존중 7. 전체 최적화
비용산정 모델	소프트웨어 개발 계획을 수립하기 위해, 투입될 자원이나 시간을 산정하는 방식 - 하향식 : 전문가가 산정 ex. 델파이 기법 - 상향식 : 요구사항과 기능에 따라 산정 ex. LoC, Man Month, COCOMO, 푸트남, FP
LoC (Lines of Codes) 모형	코드 라인 수의 예측치를 구하여 비용 산정 - 산정방법 낙중비46 (낙관치 + 중관치*4 + 비관치 ) / 6   ex. (낙관100+중관150*4+비관200) / 6 = 150
Man Month 모형	한 사람이 1개월 간 할 수 있는 일의 양을 기준으로 비용 산정 (Man Month) = (LoC) / 개발자의 월간 생산성 (프로젝트 기간) = (Man Month) / 프로젝트 인력
COCOMO 모형	프로그램 규모에 따라 비용을 산정 조반임 1) 조직형/단순형 (Organic) : 소규모. 5만 라인(50KSDI) 이하 2) 반 분리형 (Semi-Detached) : 중간형. 30만 라인(30KSDI) 이하 3) 임베디드형 (Embedded) : 초대형.
푸트남 (Putnam) 모형	생명주기 단계별 인력분포를 예측하는 방식 (시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선 분포도 기초)
FP (기능점수) 모형	요구 기능별로 가중치를 부여해 총 점수를 계산해 비용 산정
일정 관리 모델	씨씨펕 1. CPM 2. CCPM 3. PERT
CPM (주 공정법)	여러 작업의 수행 순서가 얽힌 프로젝트에서 일정을 계산하는 기법 - 임계 경로(Critical Path) 계산법 ⇒ 가장 긴 경로 계산!
CCPM (중요 연쇄 공정법)	주 공정법의 연쇄법으로, 자원 제약사항을 고려해 게산
PERT	낙관치∙중관치∙비관치의 3점 추정방식으로 일정 관리
현행 시스템 파악	구기인 아소 하네 1) 구성 현황 / 기능 현황 / 인터페이스 파악 2) 아키텍처, 소프트웨어 구성 파악 3) 하드웨어, 네트워크 구성 파악
소프트웨어 아키텍처	소프트웨어의 구성요소와, 구성요소의 특성, 구성요소 간 관계를 표현하는 구조
소프트웨어 4+1 뷰	요구사항을 4개의 관점에서 바라보는 방법. 4개 구조가 충돌되지 않는지, 요구사항을 충족하는지 증명하기 위해 유스케이스 사용
유스케이스 뷰	유스케이스를 도출하고 다른 뷰를 검증하는 뷰
프로세스 뷰	비기능적인 속성으로 자원 사용 등을 표현한 뷰
배치 뷰	컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 보여주는 뷰
논리 뷰	기능적인 요구사항이 어떻게 제공되는지 표현한 뷰
구조 뷰	소프트웨어 모듈의 구성을 보여주는 뷰
소프트웨어 아키텍처 패턴	소프트웨어 설계 시 참조 가능한 솔루션 (일반적으로 발생하는 문제점들에 대해 일반화되고 재사용 가능한 솔루션)
소프트웨어 아키텍처 패턴 종류	계클서 파필 브모 1. 계층화 패턴 2. 클라이언트-서버 패턴 3. 파이프-필터 패턴 4. 브로커 패턴 5. 모델-뷰-컨트롤러 패턴
계층화 패턴	- 시스템을 계층으로 구분  ex) OSI 7계층 - 서로 마주보는 계층에서만 상호작용 발생
클라이언트-서버 패턴	- 하나의 서버 + 다수의 클라이언트 - 사용자는 클라이언트와만 상호작용
파이프-필터 패턴	- 데이터 스트림을 처리하는 시스템에서 사용   ex) Unix의 Shell - 하나의 서브시스템이 데이터를 받아 처리하고, 결과를 다음 서브 시스템에게 넘겨줌
브로커 패턴	- 사용자가 요청하면, 브로커가 적합한 컴포넌트를 연결하는 방식 - 원격 서비스 호출에 응답하는 컴포넌트가 여럿일 때 적합
모델-뷰-컨트롤러 (MVC) 패턴	- 3개의 서브시스템으로 구조화한 패턴 1) 모델(Model) : 핵심 기능과 데이터 보관 2) 뷰(View) : 사용자에게 정보 표시 3) 컨트롤러(Controller) : 사용자의 입력 처리 - 하나의 모델에 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합
소프트웨어 아키텍처 비용 평가 모델	싸카 (SACAA) 1. SAAM : 변경 용이성과 기능성에 집중. 경험없어도 쉽게 사용 가능 2. ATAM : SAAM을 계승. 아키텍처 품질 속성을 만족하는지도 평가 2. CBAM : ATAM에 경제성 평가 보장 3. ADR : 아키텍처 구성요소 간 응집도 평가 4. ARID : ATAM+ADR. 전체가 아닌 특정 부분에 대한 비용 평가
디자인 패턴	소프트웨어 설계 시 자주 쓰이는 방법을 정리한 패턴으로 참고 시 개발 효율성이 높아진다
디자인 패턴 구성요소	패문솔 사결샘 1. 패턴 이름 2. 문제 및 배경 3. 솔루션 4. 사례 5. 결과 6. 샘플코드 cf. 라이브러리의 구성은 도설셈 (도움말, 설치파일, 샘플코드)
디자인 패턴 유형	생구행 1. 생성 (5) 2. 구조 (7) 3. 행위 (11)
디자인 패턴 - 생성 패턴	팩프빌싱추 1. 팩토리 메소드 2. 프로토타입 3. 빌더 4. 싱글톤 5. 추상 팩토리
팩토리 메소드 (Factory Method)	상위 클래스에서 인터페이스 정의, 서브 클래스가 실제 생성
프로토타입 (Prototype)	원형 객체를 복사하여 생성 (객체 생성 시 갖춰야할 기본 형태가 있을 때 사용)
빌더 (Builder)	객체를 조립하여 생성. 생성 방법과 구현 방법을 구분하여, 동일한 객체 생성이여도 다른 결과가 나올 수 있음
싱글톤 (Singletone)	클래스 내 객체가 하나 뿐임을 보장. 하나의 객체를 생성해 어디든 참조할 수 있으나 동시 참조 불가
추상 팩토리 (Abstract Factory)	구체적인 클래스에 의존하지 않고, 연관된 객체들의 그룹으로 생성 (객체 간 결합이 느슨해짐)
디자인 패턴 - 구조 패턴	퍼플컴프브어데 1. 퍼싸드 2. 플라이웨이트 3. 컴포지트 4. 프록시 5. 브리지 6. 어댑터 7. 데코레이터
퍼싸드 (Facade)	복잡한 시스템에 단순한 인터페이스를 제공해 접근성을 높인 패턴
플라이웨이트 (Flyweight)	객체가 필요할 때 생성하는 대신 공유하여 메모리 절약
컴포지트 (Composite)	객체 관계를 파일 트리 구조로 구성하여, 복합 객체와 단일 객체를 동일하게 취급
브리지 (Bridge)	구현부에서 추상층을 분리하여 결합도를 낮춘 패턴
어댑터 (Adapter)	호환성 없는 클래스의 인터페이스를 이용할 수 있게 변환
데코레이터 (Decorator)	객체 결합을 통해 기능을 확장
디자인 패턴 - 행위 패턴	미인템옵비커이체스스메 1. 미디에이터 2. 인터프리터 3. 템플릿 메소드 4. 옵서버 5. 비지터 6. 커맨드 7. 이터레이터 8. 체인 오브 리스폰서빌리티 9. 스테이트 10. 스트레이트지 11. 메멘토
중재자 (Mediator)	객체 사이에 중재자를 두어 의존성을 줄이는 패턴
인터프리터 (Interpreter)	여러 언어 구문을 해석할 수 있게 해주는 패턴
템플릿 메소드 (Template Method)	상위 클래스에서 기능을 정의하고, 하위 클래스에서 세부 처리 방법을 구체화하는 패턴 cf. 팩토리 메소드 - 상위 클래스에서 인터페이스 정의 후 하위 클래스에서 실제 생성
옵서버 (Obesrver)	객체를 지켜보고 있다가, 객체의 상태가 변화면 그 객체에 의존하는 다른 객체들에게 변화된 상태를 전달
비지터 (Visitor)	처리 기능을 별도로 분리한 패턴 (분리된 처리 기능은 클래스를 방문하여 수행)
커맨드 (Command)	요청을 객체로 캡슐화하여, 각 요청(명령)이 들어오면 그에 맞는 서브 클래스 실행
반복자 (Iterator)	접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴 (내부 노출 없이 순차적 접근 가능)
책임 연쇄 (Chain of Responsibility)	한 객체가 요청을 처리하지 못하면, 연결된 객체로 넘어가 처리
상태 (State)	객체의 상태를 캡슐화하고, 이를 참조해 동작을 다르게 처리
전략 (Strategy)	동일한 계열의 알고리즘을 캡슐화하고, 전략을 선택해 사용
메멘토 (Memento)	특정 시점의 객체 내부 상태를 객체화하여, 해당 시점으로 되돌리는 기능을 제공
OS	컴퓨터의 하드웨어를 사용자가 쉽게 사용할 수 있도록 인터페이스를 담당하는 소프트웨어
OS 현행 시스템 분석	신성기주구 1. 품질 측면 (신뢰도, 성능) 2. 지원 측면 (기술 지원, 주변 기기, 구축 비용)
네트워크	원하는 정보를 수신자에게 정확하게 전달하기 위한 인프라
OSI 7계층	네트워크 통신에서 충돌 문제를 최소화하고자, 국제표준화기구(ISO)에서 제시한 네트워크 통신 규약
DBMS	데이터베이스를 관리할 수 있는 응용 프로그램
DBMS 분석 시 고려사항	가성호기구 1. 성능 측면 (가용성, 성능, 상호 호환성) 2. 지원 측면 (기술 지원, 구축 비용)
미들웨어	컴퓨터와 컴퓨터 간 연결 및 연결 관리를 돕는 소프트웨어
요구공학	요구사항을 도출, 분석, 명세, 확인하는 구조화된 활동
요구공학 프로세스	1. 개발 단계 (CMM Level 3) : 도분명확 요구사항을 분석하자!! 2. 관리 단계 (CMM Level 2) : 협기변확 설계-개발-테스트를 거치는 동안 요구사항 잘 만족하고 있는지 볼까~
요구공학 개발 단계 구성 (CMM Level 3)	도분명확 1. 도출 : 이해관계자 식별, 고객 분석 2. 분석 : 분개할협분 분류→개념 모델링 생성→할당→협상→분석 3. 명세 : 정형화된 형태로 명세 작성 4. 확인 : 요구사항 이해를 확인하고 문서가 완전한지 검증
요구사항 도출 기법	- 인터뷰 : 직접 대화 - 브레인스토밍 : 말하기 쉬운 분위기 속에서 비판없이 의견을 수용 - 델파이 기법: 전문가 경험 활용 - 롤 플레잉: 각자 맡은 역을 연기 - 워크숍 : 단기간 집중하여 정보 획득 후 공유 (사전 준비 필요) - 설문 조사
요구사항 분석 단계	분개할협분 1. 요구사항 분류 : 기능적 요구사항(시스템이 제공해야 할 기능) vs. 비기능적 요구사항(시스템이 준수해야 할 제약사항) 2. 개념 모델링 생성 : 주로 UML 사용. 요구사항을 쉽게 이해할 수 있도록 개념적 표현 3. 요구사항 할당: 요구사항 만족을 위한 아키텍처 구성요소 식별 4. 요구사항 협상: 충돌되는 경우 합의, 우선순위 부여 5. 정형 분석: 정형화된 언어를 통해 수학적 기호로 표현
요구사항 분석 기법	- 자료 흐름 지향 분석 : 데이터 흐름도(DFD)와 자료 사전(DD)을 통해 분석 - 객체지향 분석 : 시스템 기능과 데이터를 함께 분석해 UML로 표준화
요구사항 명세 기법	1. 비정형 명세 기법 : 자연어 기반 서술 2. 정형 명세 기법 : 수학적 표기법으로 서술
요구사항 명세 원리 및 검증 항목	명완검 일수 개추 1. 명확성 : 각 명세 내용은 하나의 의미만 부여 2. 완전성 : 모든 요구사항이 포함되어야 함 3. 검증 가능성 : 달성 정도를 확인할 수 있어야 함 4. 일관성 : 모순이 없어야 함 5. 수정 용이성 : 쉽게 수정할 수 있어야 함 6. 개발 후 이용성 : 운영 및 유지보수에 이용이 가능해야 함 7. 추적 가능성 : 추적이 가능해야 함
요구사항 확인 기법	1. 정형 기술 검토(TCR)   - 동료 검토 (Peer Review) : 작성자가 설명하고, 이해관계자들이 설명읃 들으며 결함 발견   - 워크 스루 (Walk Through) : 검토 자료 사전 배포 후, 짧은 회의 진행   - 인스펙션 (Inspection) : 저작자가 아닌 다른 전문가가 검토 2. 프로토타이핑 활용 3. 테스트 케이스를 통한 확인 4. CASE 도구 활용 5. 베이스라인 검증 6. 요구사항 추적표 (RTM; Requirement Traceability Matirx) 통해 검증 : 요구사항 정의서 기준으로 개발단계별 최종 산출물이 어떻게 변경되었는지 확인 가능한 문서
정형 기술 검토(TCR) 기법	- 관리 리뷰 (Management Review): 프로젝트 진행 상황을 전반적으로 검토 - 기술 리뷰 (Technical Review) : 명세를 준수하고 있는지 검토 - 인스펙션 (Inspection) : 저작자가 아닌 다른 전문가가 검토.   ⇒ 참가자 구성: 주재자(Moderator, 참가자를 선정하고 계획 및 주재) & 작성자, 낭독자, 기록자, 검토자 - 워크스루 (Walk Throughs) : 회의 전 검토자료 배포하여 사전 검토 후, 짧은 시간 동안 회의 진행 - 감사 (Audit) : 제품이 표준이나 가이드라인을 준수하는지 검토. 제품 제공자, 소비자, 제3기관이 수행
요구공학 관리 단계 구성 (CMM Level 2)	협기변확 1. 협상 : 구현 가능한 기능 협상 2. 기준선 설정 : 기준선(베이스라인) 설정 3. 변경관리 : 형상통제 위원회를 운영하여 변경 관리   *CCB: 형상 관리의 방침을 정하고 산출물을 검토하는 조직   *베이스라인: 개발 과정의 산출물의 변화를 통제하는 시점 4. 확인 및 검증 : 요구사항에 부합하는지 확인

 

출처: https://cloudjini.tistory.com/820 [개발자 지니의 Blog:티스토리]