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

2020 시나공 정보처리기사 필기책 참고

주의! 중요도가 낮은 항목(C)은 제외

1. 소프트웨어 생명 주기(Software Life Cycle) – A

소프트웨어 개발 방법론의 바탕

- 폭포수 모형(Waterfall Model)

• 고전적 생명 주기 모형
• 개발의 한 단계가 끝나야 다음 단계로 넘어가는 선형 순차적 모형
• 메뉴얼 작성
• 단계가 끝나면 다음 단계 _결과물 명확히 산출_되어야 함
• 두 개 이상의 과정이 병행 수행 X
• 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현(코딩) -> 시험(검사) -> 유지보수

- 프로토타입 모형(Prototype Model)

• 인터페이스에 중점을 두어 개발
• 시스템의 일부를 만드는 과정으로 추후 구현 단계에서 사용될 골격 코드
• 폭포수 모형의 단점 보완
• 요구 수집 -> 빠른 설계 -> 프로토타입 구축 -> 고객 평가 -> 포로토타입 조정 -> 구현

- 나선형 모형(Spiral Model)

• 프로토타입 + 위험 분석 기능
• 여러번의 개발 과정을 거쳐 완벽한 소프트웨어 개발. 점진적 모형
• 위험의 관리와 최소화 목적
• 누락되거나 추가된 요구사항 첨가 가능, 정밀
• 유지보수 과정 필요 없음
• 계획 및 정의 -> 위험 분석 -> 공학적 개발 -> 고객 평가

- 애자일 모형(Agile Model)

• 일정 주기 반복 하며 개발
• 고객과의 소통에 초점
• 스프린트, 이터레이션의 짧은 개발 주기 반복
• 결과물에 대한 고객의 평가와 요구를 적극 수용
• 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈, ASD, FDD 등

@ 애자일 선언

애자일 개발 4대 핵심 가치

• 개인과 상호작용에 더 가치를 둠
• 실행되는 SW에 더 가치를 둠
• 고객과 협업에 더 가치를 둠
• 변화에 반응하는 것에 더 가치를 둠

- 폭포수 모형과 애자일의 비교

구분	폭포수	애자일
요구사항 반영	어려움	지속적으로 반영
고객과의 의사소통	적음	지속적
테스트	마지막에 테스트	반복되는 주기마다 테스트
개발 중심	계획, 문서(메뉴얼)	고객

2. 스크럼(Scrum) 기법 – A

팀 중심으로 개발 효율성 높임

- 개요

• 스스로 팀을 구성, 스스로 해결
• 제품 책임자(PO; Product Owner)
  • 개발 의뢰자나 사용자가 담당
  • 제품 요구사항 작성의 주체
  • 요구사항 백로그 작성, 우선순위 지정
• 스크럼 마스터(SM; Scrum Master)
  • 객관적인 시각에서 조언
  • 통제가 목표 아님
  • 진행사항 점검, 장애요소 공론화
• 개발팀(DT; Development Team)
  • PO, SM을 제외한 개발에 참여하는 모든 사람

- 스크럼 개발 프로세스

• 제품 백로그 -> 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

3. XP(eXtreme Programming) 기법 – A

고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상

- XP

• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적 참여로 S/W를 빠르게 개발
• 릴리즈 기간을 짧게 반복
• 릴리즈 테스트마다 고객을 직접 참여시킴
• 소규모 인원 개발 프로젝트에 효과적
• XP의 5대 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백

- XP 개발 프로세스

• 사용자 스토리 -> 릴리즈 계획 수립 -> 스파이크 -> 이터레이션 -> 승인검사 -> 소규모 릴리즈

- XP 주요 실천 방법

• 짝 프로그래밍(Pair Programming)
  • 다른 사람과 함께 스행하여 책임을 공동으로 나눔
• 테스트 주도 개발(Test-Driven Development)
  • 테스트 케이스 먼저 작성
  • 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구 사용
• 전체 팀(Whole Team)
  • 모든 구성원들을 각자 자신의 역할이 있고 거기에 책임을 가져야 함
• 계속적인 통합(Continuous Integration)
  • 모듈 단위로 개발된 코드가 지속적으로 통합
• 디자인 개선(Design Improvement) 또는 리팩토링(Refactoring)
  • 기능 변경 없이, 단순화, 유연성 강화 등을 통해 시스템 재구성
• 소규모 릴리즈(Small Releases)
  • 릴리즈 기간을 짧게 반복하여 고객 요구 변화에 신속히 대응

4. 요구사항 정의 – B

- 요구사항 개념 및 특징

• 요구사항은 소프트웨어가 제공하는 서비스에 대한 설명과 운영되는데 필요한 제약 조건
• 개발이나 유지 보수 과정에서 필요한 기준과 근거를 제공
• 개발에 참여하는 이해관계자들 간의 의사소통을 원활하게 도움
• 요구사항이 잘 정의 되어야 이후 과정의 목표와 계획을 수립할 수 있음

- 요구사항의 유형

• 기능 요구사항
  • 무엇을 하는지, 어떤 기능을 하는지
  • 입출력에 무엇이 포함되어야 하는지, 어떤 데이터를 저장하거나 연산을 수행해야 하는지
  • 반드시 수행해야 하는 기능
  • 사용자가 제공받기 원하는 기능
• 비기능 요구사항
  • 시스템 장비 구성
  • 성능
  • 인터페이스
  • 데이터
  • 테스트
  • 보안
  • 품질
  • 제약사항
  • 프로젝트 관리 요구사항
  • 프로젝트 지원 요구사항
• 사용자 요구사항
  • 사용자 관점에서 본 시스템이 제공해야 할 요구사항
  • 친숙한 표현으로 이해하기 쉽게 작성
• 시스템 요구사항
  • 개발자 관점에서 본 시스템이 사용자와 다른 시스템에 제공해야 할 요구사항
  • 전문적이고 기술적인 용어로 표현
  • 소프트웨어 요구사항이라고도 함

- 요구사항 개발 프로세스

요구 사항 도출(Elicitation) -> 분석(Analysis) -> 명세(Specification) -> 확인(Validation)

5. UML(Unified Modeling Language) – A

- UML 개요

• 객체 지향 모델링 언어
• Rumbaugh, Booch, Jacobson 등 객체지향 방법론의 장접 통합. OMG에서 표준으로 지정
• 구조 다이어그램 6개, 행위 다이어그램 7개
• 사물과 사물 간의 관계를 용도에 맞게 표현
• 구성요소는 사물, 관계, 다이어그램

- 사물(Things)

• 관계가 형성될 수 있는 대상
• 구조 사물(Structural Things)
  • 시스템의 개념적, 물리적 요소
  • Class, Use Case, Component, Node 등
• 행동 사물(Behavioral Things)
  • 시간과 공간에 따른 요소들의 행위
  • Interaction, State Machine
• 그룹 사물(Grouping Things)
  • 요소들을 그룹으로 묶어서 표현
  • Package
• 주해 사물(Annotation Things)
  • 부가적인 설명이나 제약조건
  • Note

- 관계(Relationships)

• 사물과 사물 사이의 연관성 표현
• 연관(Association) 관계
  • 2개 이상의 사물이 서로 관련되어 있음
  • 사물 사이 실선 연결, 방향성은 화살표로
  • 양방향 관계의 경우 화살표 생략하고 실선으로만 연결
  • 다중도를 선 위에 표기
• 집합(Aggregation) 관계
  • 하나의 사물이 다른 사물에 포함되어 있음
  • 서로 독립적
  • 포함하는 쪽으로 속이 빈 마름모 연결하여 표현
• 포함(Composition) 관계
  • 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
  • 독립될 수 없고 생명주기를 함께 함
  • 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현
• 일반화(Generalization) 관계
  • 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현
  • 일반적인 개념을 상위(부모), 구체적인 개념을 하위(자식)
  • 상위 사물 쪽으로 속이 빈 화살표 연결하여 표현
• 의존(Dependency) 관계
  • 연관은 있으나 짧은 시간 동안만 연관을 유지하는 관계
  • 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
  • 영향 받는 쪽으로 점선 화살표 연결하여 표현
• 실체화(Realization) 관계
  • 할 수 있거나 해야 하는 기능으로 서로를 그룹화 할 수 있는 관계
  • 기능 쪽으로 속이 빈 점선 화살표 연결

- 다이어그램(Diagram)

• 사물과 관계를 도형으로 표현
• 가시화한 View를 제공하여 의사소통에 도움
• 정적 모델링에서는 구조적 다이어그램, 동적 모델링에서는 행위 다이어그램 사용

@ 구조적 다이어그램

• 클래스(Class) 다이어그램
• 객체(Object) 다이어그램
• 컴포넌트(Component) 다이어그램
• 배치(Deployment) 다이어그램
• 복합체 구조(Composite Structure) 다이어그램
• 패키지(Package) 다이어그램

@ 행위 다이어그램

• 유스케이스(Use Case) 다이어그램
• 시퀀스(Sequence) 다이어그램
• 커뮤니케이션(Communication) 다이어그램
• 상태(State) 다이어그램
• 활동(Activity) 다이어그램
• 상호작용 개요(Interaction Overview) 다이어그램
• 타이밍(Timing) 다이어그램