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

소프트웨어 생명 주기(Software Life Cycle): 소프트웨어를 개발하기 위해 정의, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
- 폭포수 모형(Waterfall Model): 각 단계를 확실히 매듭짓고, 그 결과를 철저하게 검토하여 승인 후 다음 단계를 진행. 선형 순차적
- 프로토타입 모형(Prototype Model, 원형 모형): 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물을 예측. 사용자와 시스템 사이의 인터페이스에 중점을 두고 개발
- 나선형 모형(Spiral Model, 점진적 모형): 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 최종 소프트웨어를 개발. 계획 수집 -> 위험 분석 -> 개발 및 검증 -> 고객 평가
- 반복적 모델: 구축단계를 나누어 반복적으로 개발하여 완성시키는 모델

소프트웨어 개발방법론 종류
- 구조적 방법론: 전체 시스템을 기능에 따라 나누고 분할과 정복 접근 방식의 방법론. 하향식 방법론. 나씨-슈나이더만 차트 사용
- 정보공학 방법론: 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
- 객체지향 방법론: 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론
- 컴포넌트 기반 방법론: 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론. 개발 기간 단축으로 인한 생산성 향상. 새로운 기능 추가가 쉬움(확장성). 소프트웨어 재사용 가능
- 애자일 방법론: 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하며 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론. 개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발 가능

애자일 방법론의 유형
- XP: 5가지의 가치와 12개의 실천항목이 존재. 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존중
- 린: 도요타의 린 시스템을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
- 스크럼: 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
  - 백로그 : 제품과 프로젝트에 대한 요구사항
  - 스프린트 : 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상
  - 스크럼 미팅 : 매일 15분 정도 미팅으로 데일리 미팅이라고도 함
  - 스크럼 마스터 : 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
  - 스프린트 회고 : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록

비용산정 모형
- 하향식 산정 방법: 전문가 판단, 델파이 기법
- 상향식 산정 방법: 코드 라인 수(Loc), Man Month, COCOMO 모형, 푸트남 모형, 기능점수(FP) 모형

비용산정 모형 종류
- 코드 라인 수(Loc): 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식
- Man Month 모형: 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식
- COCOMO 모형: 보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식. 비용산정 결과는 Man Month로 산정 ex)  조직형과 반 분리형, 임베디드형
- 푸트남(Putnam) 모형: 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식. 생명주기 예측 모형.  시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초
기능점수(FP) 모형
: 인자별로 가중치를 부여하고, 가중치를 합산하여 총 기능의 점수를 계산하는 방식

COCOMO(COnstructive COst MOdel): LOC에 의한 비용 산정 기법 
- 조직형(organic Mode): 소규모의 소프트웨어 5만라인 이하 
- 반 분리형(Semi-Detached Mode): 중간형 소프트웨어 30만 라인 이하의 소프트웨어 
- 내장형(Embedded Mode): 초대형 규모의 소프트웨어 30만 라인 이상

일정관리 모델 종류
- 주 공정법: 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
- PERT: 일의 순서를 계획적으로 처리하기 위해 비관치, 중간치, 낙관치를 통해 일정을 관리하는 기법
- CCPM: 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법

소프트웨어 공학(SE. Software Engineering): 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문

요구사항 개발 단계 구성
도출 > 분석 > 명세 > 확인

요구사항 도출 주요 기법
- 인터뷰 : 이해관계자와 대화를 통해 도출하는 공식적, 비공식적 정보 수집 방법
- 브레인스토밍 : 말하기 편한 분위기를 만들어서 비판없이 수용할 수 있도록 하는 회의
- 델파이 기법: 전문가의 경험적 지식을 이용하여 문제 해결 및 미래 예측을 하는 방법
- 롤 플레잉 : 현실에서 일어나는 장면을 각자 맡은 역할로 수행하여 요구사항을 분석하고 수집
- 워크숍 : 단기간의 프로젝트를 진행하여 전문적인 정보를 획득하는 방법
- 설문 조사 : 설문지 또는 여론조사를 통해 간접적으로 정보를 수집하는 방법

요구사항 분석: 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동

요구사항 명세 단계 주요 기법
- 비정형 명세 기법: 사용자 요구를 표현할 때 자연어 기반으로 서술. 사용자와 개발자 이해 용이
- 정형 명세 기법: 사용자 요구를 표현할 때 수학적 원리와 표기법으로 서술, 표현이 간결하고 명확성 및 검증 용이

UML(Unified Modeling Language): 시스템 개발 과정에서 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 객체지향 모델링 언어. 사물(Things), 관계(Relationship), 다이어그램(Diagram)

구조적 다이어그램 / 정적 다이어그램
- Class Diagram (클래스 다이어그램) : 클래스 사이의 관계를 표현하는 UML을 이용한 정적 모델링의 대표 다이어그램
- Object Diagram (객체 다이어그램) : 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현
- Component Diagram (컴포넌트 다이어그램) : 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
- Deployment Diagram (배치 다이어그램) : 컴포넌트 사이의 종속성을 표현하고, 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
- Composite Structure Diagram (복합체 구조 다이어그램) : 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
- Pakage Diagram (패키지 다이어그램) : 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

행위적 다이어그램 / 동적 다이어그램
- Use Case Diagram (유스케이스 다이어그램) : 시스템이 제공하고 있는 기능과 그와 관련된 외부 요소들을 사용자의 입장에서 표현하는 다이어그램
- Sequence Diagram (시퀀스 다이어그램) : 객체 간 동적 상호작용을 시간적 개념으로 메세지 흐름을 이용해서 표현하는 다이어그램
- Communication Diagram (커뮤니케이션 다이어그램) : 객체들이 주고받는 메세지와 객체 간의 연관을 표현하는 다이어그램
- State Diagram (상태 다이어그램) : 하나의 객체가 자신이 속한 클래스의 상태변화 혹은 다른 객체간의 상호작용에 따라 상태가 변하는 것을 표현하는 다이어그램
- Activity Diagram (활동 다이어그램) : 시스템이 어떤 기능을 수행하는지 처리의 흐름을 순서로 표현한 다이어그램
- Timing Diagram (타이밍 다이어그램) : 객체 상태 변화와 시간 제약을 명시적으로 표현하는 다이어그램

Case(Computer Aided Software Engineering): 소프트웨어 개발 과정에서 사용되는 요구분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
- 소프트웨어 생명 주기 전 단계의 연결
- 다양한 소프트웨어 개발 모형 지원
- 그래픽 지원

소프트웨어 개발 프레임워크의 특성
- 모듈화(Modularity): 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상. 개발 표준에 의한 모듈화로 인해 유지 보수가 용이
- 재사용성(Reusability): 프레임워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증 가능
- 확장성(Extensibility): 프레임워크는 다형성을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능
- 제어의 역흐름(Inversion of Control): 개발자가 관리하고 통제해야 하는 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상시킴