2020 정보처리기사 실기 요약 - 요구사항 설계 및 개발 프로세스

요구사항 설계 및 개발 프로세스

1. 모듈
공통 모듈 : 기능을 분할하고 추상화하여 성능 향상 및 유지보수를 효과적으로 하기 위한 공통 컴포넌트 구현 기법
모듈 : 하나의 소프트웨어 또는 하드웨워 단위, 소프트웨어 설계에서 기능 단위로 분해해 추상화되어 재사용 및 공유가 가능한 단위
모듈화 : 모듈을 통해 소프트웨어의 성능을 향상 시키고 디버깅, 수정, 통합을 용이하게 하는 설계 기법

2. 공통 모듈 명세 기법
정확성 : 시스템 구현 시 해당기능이 필요하다는 것을 알 수 있도록 정확히 작성
명확성 : 해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확히 작성
완전성 : 시스템 구현을 위해 필요한 모든 것을 기술
일관성 : 공통 기능들 간 상호 충돌이 발생하지 않도록 작성
추적성 : 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성

3. 결함관리 측정지표
결함 분포 : 모듈 또는 컴포넌트의 특정 속성에 해당하는 결함 수 측정
결함 추세 : 테스트 진행 시간에 따른 결함 수의 추이 분석
결함 에이징 : 특정 결함 상태로 지속되는 시간 측정

4. XP(eXtreme Programming) 기법
핵심 가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)
Pair Programming(짝 프로그래밍) : 다른 사람과 함께 프로그래밍을 수행함으로 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성
Test-Driven Development(테스트 주도 개발) : 테스트 케이스를 먼저 작성해 자신이 무엇을 해야할지 정확히 파악. 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구 사용
Whole Team(전체 팀) : 개발에 참여하는 모든 구성원은 각자의 역할에 따른 책임을 가져야함
Continuous Integration(계속적인 통합) : 모듈 단위로 나눠서 개발된 코드는 작업이 마무리 될 때마다 지속적으로 통합됨
Design Improvement(디자인 개선 또는 리팩토링) : 프로그램 기능의 변경 없이 단순화, 유연성 강화 등을 통해 시스템 재구성
Small Releases(소규모 릴리즈) : 릴리즈 기간을 짧게 반복해 고객의 요구 변화에 신속히 대응

5. XP 개발 프로세스
사용자 스토리 : 요구사항 간단한 시나리오로 표현. 기능 단위 구성.
릴리즈 계획 수립 : 부분적으로 기능이 완료된 제품 제공
스파이크 : 요구사항 신뢰도를 높이고, 기술 문제의 위험 감소를 위해 별도로 만드는 프로그램
이터레이션 : 하나의 릴리즈를 더 세분화한 단위
승인 검사(인수 테스트) : 계획된 릴리즈 단위가 부분 완료가 구현되면 고객이 직접 수행해서 테스트함.
소규모 릴리즈

6. 스크럼 개발 프로세스
제품 백로그 : 제품 개발에 필요한 요구사항을 우선순위에 따라 나열한 로그 리스트. 지속적으로 업데이트되며, 사용자 스토리 기반의 릴리즈 계획 수립
스프린트 계획 회의 : 수행할 작업에 대한 단기적 일정. 태스크(Task) 작업 단위로 분할. 개발자별로 수행할 작업 목록인 스프린트 백로그 작성
스프린트 : 실제 개발 작업 과정. 개발자가 원하는 태스크를 담당할 수 있도록 함. 할 일(Todo), 진행 중(In Progress), 완료(Done)의 상태로 태스크 관리
일일 스크럼 회의 : 15분 정도의 짧은 시간으로 진행상황을 점검하고 남은 작업 시간을 소멸 차트에 표시한다.
스프린트 검토 회의 : 제품 책임자(PO)는 개선할 사항에 대한 피드백을 정리 후 다음 스프린트에 반영할 수 있도록 제품 백로그를 업데이트함
스프린트 회고

7. 소프트웨어 생명 주기
폭포수 모형 : 가장 오래되고 가장 폭넓게 사용된 전통적 모형으로 고전적 생명 주기 모형이라고 함. 두 개 이상의 과정 병행 수행 할 수 없음.
- 순서 : 타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현 -> 시험 -> 유지보수.
프로토타입 모형 : 사용자와 시스템 사이의 인터페이스에 초점.  시스템 모형의 골격 코드. 폭포수 모형의 단점 보안.
- 순서 : 요구 수집 -> 설계 -> 구축 -> 평가 -> 조정 -> 구현 -> 요구수집
나선형 모형 : 보헴(Boehm) 제안. 여러 번의 개발 과정과 검토 과정을 거치는 점진적 모형. 별도의 유지보수 과정 필요 없음
애자일 모형 :  고객과의 소통에 초점을 맞춘 방법론. 스프린트 또는 이터레이션 개발 주기 반복. 고객이 요구사항에 우선순위를 부여함.
- 종류 :  스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM, DAD


8. 스크럼
제품 책임자(PO) : 이해관계자들의 의견을 종합해 제품에 대한 요구사항 작성. PO는 요구 사항이 담긴 백로그를 작성하고 백로그 우선 순위를 지정
스크럼 마스터(SM) : 일일 스크럼 회의 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화해서 처리
개발팀(DT) : 개발자, 디자이너, 테스터 등

9. UI 요구사항 작성
요구사항 요소 확인 -> 정황 시나리오 작성 -> 요구사항 작성

10. 요구사항 요소 확인
데이터 요구 : 사용자가 요구하는 모델과 객체들의 주요 특성을 기반으로 하여 데이터 객체들을 정리(이메일의 메시지 속성 -> 제목, 발신인, 답변 등)
기능 요구 : 사용자의 목적 달성을 위해 무엇을 실행해야 하는지를 동사형으로 설명. 기능 요구 리스트는 최대한 철저하게 정리(읽거나 삭제, 다른 메시지와 함께 보관)
제품/서비스의 품질 : 데이터 및 기능 요구 외에 제품의 품질, 서비스, 여기에 감성적인 품질 등을 고려하여 작성.(얼마나 빠르게 처리할 수 있는지의 여부 등 정량화가 가능한 요구사항)
제약 사항 : 제품 완료 데드라인, 전체 개발 및 제작에 필요한 비용, 시스템 준수에 필요한 규제가 포함.(제약사항의 변경 가능 여부 확인)

11. 정황 시나리오 : 사용자의 요구사항을 도출하기 위해 작성하는 것. 사용자가 목표를 달성하기 위해 수행하는 방법을 순차적으로 묘사

12. 요구사항 개발 프로세스[도분명확]
도출 : 시스템, 사용자, 개발자가 의견을 교환하여 요구사항을 식별하고 이해하는 과정. 소프트웨어 개발 생명주기(SDLC) 반복
- 요구사항 도출 방법 : 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스(사용사례)
분석 : 요구사항 중 명확하지 않거나 모호한 부분을 걸러내는 과정. 타당성을 조사. 비용과 일정에 대한 제약 설정
- 요구사항 분석 기법 : 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석
명세 : 요구사항을 체계적으로 분석 한 후 승인될 수 있도록 문서화.
확인 : 개발 자원을 요구사항에 할당하기 전에 명세서가 정확하고 완전하게 작성되었는지를 검토. 요구사항 관리 도구를 이용하여 요구사항 정의 문서를 형상 관리 해야 함.
- 요구사항 확인 기법 : 요구사항 검토, 프로토타이핑, 모델 검증(정적 분석), 인수 테스트

[연계 요구사항]
체크리스트 : 시스템 운영환경, 성능, 보안, 데이터발생주기 등의 기준에 대한 점검을 통한 연계 요구사항 기법
브레인스토밍 : 소속된 인원들이 자발적으로 자연스럽게 제시된 아이디어 목록을 통한 연계 요구사항 기법


13. 요구사항 검토 상세 항목
동료 검토 : 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 형태의 검토 방법
워크 스루 : 검토 회의 전에 사전 검토를 한 후에 짧은 검토 회의를 통해 결함을 발견하는 검토 방법
인스펙션 : 작성자를 제외한 다른 검토 전문가들이 검토하는 방법


14. 요구 사항 분석의 도구와 기법
사용자 인터뷰, 핵심 사용자 그룹 면담(FGI: Focus Group Interview): 사용자 면담 또는 시스템 관리자 및 서비스 활용자와 같은 핵심 그룹 면담 연계 데이터 정의, 연계 데이터의 활용 목적, 필요성 등을 식별하기 위함으로 사용자 인터뷰 전 연계 대상 시스템의 응용 애플리케이션 기능, 서비스의 확인이 필요함
체크리스트(Checklist) : 연계 데이터와 연계 시스템 아키텍처 정의를 위해 시스템 운영 환경, 성능, 보안, 데이터 발생 등 다각도의 관점에서 고려 사항 점검 및 확인
설문지 및 설문 조사 : 서비스 활용 목적에 따라 연계가 필요한 데이터를 식별하고, 연계 주기 등을 분석하기 위해 설문 조사 항목을 통해 자료를 수집. 객관식 문항으로 예상 답변을 일정 범위 이내로 한정할 수도 있음
델파이 기법 : 통합 구현 및 연계 전문가, 시스템 아키텍처, 업무 전문가 등 각 분야 전문가로부터 연계 데이터 및 사용자 요구 사항 식별
연계 솔루션 비교 분석: EAI, ESB, Open API 등 다양한 연계 방식과 연계 솔루션 별 연계 시의 성능, 보안, 데이터 처리, 모니터링 등의 장단점을 비교함


15. EAI(Enterprise Application Integration)
EAI는 기업 내 각종 애플리케이션 및 플롯폼 간의 정보 전달, 연계 통합 등 상호 연동이 가능하게 해주는 솔루션이다. EAI는 비즈니스 간 통합 및 연계성을 증대시켜 효율성 및 각 시스템 간의 확정성을 높여준다.
Point-to-Point : 가장 기본적인 애플리케이션 통합 방식으로, 1대1로 연결한다. 변경 및 재사용이 어렵다는 단점.
Hub & Spoke : 단일 접점인 허브 시스템을 통해 데이터를 전송하는 중앙 집중형 방식. 확장, 유지 보수가 유리하다. 허브 장애 발생시 시스템 전체에 영향이 있다는 단점.
Message Bus : 애플리케이션 사이에 미들웨어를 두어 처리하는 방식이다. 확장성이 뛰어나며 대용량 처리가 가능하다.
Hybrid : Hub & Spoke와 Message Bus의 혼합 방식이다. 데이터 병목 현상을 최소화 할 수 있다. 


16. ESB(Enterprise Service Bus)
ESB는 애플리케이션 간 연계, 데이터 변환, 웹 서비스 지원 등 표준 기반의 인터페이스를 제공하는 솔루션이다. ESB는 애플리케이션 통합 측면에서 EAI와 유사하지만 애플리케이션 보다는 서비스 중심의 통합을 지향한다. ESB는 특정 서비스에 국한 되지 않고 범용적으로 사용하기 위해 애플리케이션과의 결합도(Coupling)를 약하게 유지한다. 관리 및 보안 유지가 쉽고, 높은 수준의 품질 지원이 가능하다.
* 느슨한 결합 : 클래스 간의 의존성을 최소화 하는 것으로, 각 모듈간 통합시 특정 서비스를 변경하더라도 연결된 다른 서비스에는 영향을 주지 않는 유연한 구조


17. 소프트웨어 패키징 작업 순서[기모빌환적변배]
기능 식별 : 코드의 기능 확인
모듈화 : 기능 단위로 코드 분류
빌드 진행 : 모듈 별로 실행 파일
사용자 환경 분석 : 사용 환경(웹/모바일/PC 등), 운영체제(인도우/유닉스/안드로이드 등), CPU, RAM
패키징 및 적용 시험 : 빌드한 파일을 배포용 파일 형식으로 패키징하고 테스팅
패키지 변경 개선 : 적용 시험 후 확인된 불편 사항 반영
배포 : 오류 발생 시 개발자에게 전달 및 수정 요청

18. 릴리즈 노트 작성 순서[모정개영정추]
모듈 식별 -> 릴리즈 정보 확인 -> 릴리즈 노트 개요 작성 -> 영향도 체크 -> 정식 릴리즈 노트 작성 -> 추가 개선 항목 식별


19. cocomo 소프트웨어 개발 모형
조직형 : 5만 라인(50KDSI)이하의 소프트웨어를 개발하는 유형. 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합
반분리형 : 조직형과 내장형의 중간형으로 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형. 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합
내장형 : 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형. 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합


20. 수학적 산정 기법
COCOMO : 보헴이 제안한 것으로 LOC(원시 코드 라인 수)에 의한 비용 산정 기법
Putnam : 소프트웨어 생명주기의 전 과정 동안에 사용될 노력의 분포를 가정해주는 모형. 생명 주기 예측 모형이며, Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
기능 점수 : 알브레히트(Albrecht)가 제안한 것으로, 소프트웨어의 기능을 증대시키는 요인 별로 가중치를 부여하고, 요인별 가중치를 합산해 총 기능 점수를 산출해 기능 점수를 구한다.

[비용 산정 자동화 추정 도구]
SLIM : Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 한 자동화 추정 도구
ESTIMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로해 개발된 자동화 추정 도구

21. 테일러링(Tailoring)
프로젝트의 특성과 필요에 따라 소프트웨어 개발 프로세스, 기법, 산출물 등을 비즈니스 적으로 또는 기술적인 요구에 맞도록 최적화 하는 과정 및 방법론

22. 객체지향 분석 방법론
Rumbaugh(럼바우) 방법 : 가장 일반적으로 사용되는 방법으로 분석 활동을 객체모델, 동적모델, 기능 모델로 나누어 수행하는 방법
Booch(부치) 방법 : 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석방법
Jacobson 방법 : Use Case를 강조하여 사용하는 분석방법
Coad와 Yourdon 방법 : E-R다이어그램을 사용하여 개체의 활동들을 데이터 모델링하는데 초점을 둔 기법
Wirfs-Brock 방법 : 분석과 설계간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

23. 브룩스의 법칙
소프트웨어 개발 일정이 지연된다고 해서 새로운 개발 인력을 진행 중인 프로젝트에 투입할 경우 작업 적응 기간과 부작용으로 인해 일정이 더욱 지연된다는 법칙

24. LOC 기법
- 노력(인월) = 개발 기간 x 투입 인원
          = LOC / 1인당 월평균 생산 코드 라인수
- 개발 비용 = 노력(인월) X 단위 비용(1인당 월 평균 인건비)
- 개발 기간 = 노력(인월) / 투입 인원
- 생산성 = LOC / 노력(인월)

25. SPICE((Software Process Improvement and Capability dEtermination)
소프트웨어 개발 표준 중 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준으로, 공식 명칭은 ISO/IEC 15504

26. CMMI(능력성숙도통합모델) : ISO15504(SPICE)를 준수하는 소프트웨어 개발 능력/성숙도 평가 및 프로세스 개선 활동의 지속적인 품질 개선 모델