1과목 1장 요구사항 확인.md

정보처리기사 핵심 개념 정리

1과목 소프트웨어 설계

1장 요구사항 확인

SECTION1 소프트웨어 생명 주기

• 소프트웨어 생명 주기
  • 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
  • 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형.
  • 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등이 있음
• 폭포수 모형
  • 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론
  • 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
  • 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함
• 프로토타입 모형
  • 프로토타입 모형은 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 시제품을 만들어 최종 결과물을 예측하는 모형
  • 소프트웨어의 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완
• 나선형 모형
  • 보헴이 제안
  • 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
  • = 점진적 모형
  • 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없음
• 애자일 모형
  • 애자일 = 민첩한, 기민한 이라는 의미. 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행
  • 고객과의 소통에 초점을 맞춤
  • 스프린트 또는 이터레이션이라고 불리는 짧은 개발 주기를 반복, 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용
  • 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM, DAD등이 있음

SECTION2 스크럼 기법

• 스크럼의 개요
  • 스크럼은 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어
  • 팀원 스스로가 스크럼 팀을 구성, 개발 작업에 관한 모든 것을 스스로 해결
  • 제품 책임자, 스크럼 마스터, 개발팀으로 구성
  • 제품 책임자
    • 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정, 주로 개발 의뢰자나 사용자
    • 제품에 대한 요구사항을 작성하는 주체
    • 백로그(요구사항 우선순위를 부여해 놓은 목록)를 작성
    • 다른 팀원들이 우선순위를 지정할 순 없음
    • 제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위를 갱신
  • 스크럼 마스터
    • 객관적인 시각에서 조언을 해주는 가이드 역할. 팀원 통제 x
    • 일일 스크럼 회의를 주관
  • 개발팀
    • 제품 책임자와 스크럼 마스터를 제외한 모든 팀원.
    • 7~8명
• 스크럼 개발 프로세스
  • 제품 백로그
    • 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
    • 지속적 업데이트
  • 스프린트 계획 회의
    • 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 것
    • 태스크라는 작업 단위로 분할한 후 개발자별로 수행할 작업 목록인 스프린트 백로그를 작성
  • 스프린트
    • 실제 개발 작업을 진행하는 과정(2~4주)
    • 태스크를 할당할 때는 개발자가 원하는 태스크를 직접 선별하여 담당할 수 있도록 하는 것이 좋음
  • 일일 스크럼 회의
    • 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행 상황을 점검
    • 남은 작업 시간은 소멸 차트에 표시
  • 스프린트 검토 회의
    • 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅을 수행
    • 제품 책임자는 개선할 사항에 대한 피드백을 정리한 후 다음 스프린트에 반영할 수 있도록 제품 백로그를 업데이트
  • 스프린트 회고
    • 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록

SECTION3 XP(eXtreme Programming)

• XP
  • 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
  • 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것이 목적
  • 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높임
  • 릴리즈 테스트마다 고객이 직접 확인
  • XP의 5가지 핵심 가치: 의사소통, 단순성, 용기, 존중, 피드백
• XP 개발 프로세스
  • 사용자 스토리
    • 고객의 요구사항을 간단한 시나리오로 표현
    • 기능 단위로 구성
  • 릴리즈 계획 수립
    • 릴리즈: 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것
    • 일정을 수립
  • 스파이크
    • 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 프로그램
  • 이터레이션
    • 하나의 릴리즈를 더 세분화 한 단위
    • 1~3주
  • 승인 검사
    • 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트
    • 발견한 오류 사항은 다음 이터레이션에 포함함
    • 요구사항의 상대적 우선순위가 변결될 수 있음
  • 소규모 릴리즈
    • 고객의 반응을 기능별로 확인할 수 있어, 고객의 요구사항에 좀 더 유연하게 대응할 수 있음
    • 최종 결과물을 고객에게 전달하는것

SECTION6 요구사항 정의

• 요구사항의 개념 및 특징
  • 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건을 나타냄
  • 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거 제공
  • 개발에 참여하는 이해관계자들 간의 의사소통을 원할하게 하는데 도움을 줌
• 요구사항의 유형
  • 기술하는 내용에 따라 기능 요구사항, 비기능 요구사항
  • 기술 관점과 대상의 범위에 따라 시스템 요구사항, 사용자 요구사항
  • 기능 요구사항
    • 시스템이 무엇을 하는지
    • 어떤 기능을 하는지
    • 입출력으로 무엇이 포함되어야 하는지
    • 어떤 데이터를 저장하거나 연산을 수행해야 하는지
    • 사용자가 시스템을 통해 제공받기를 원하는 기능
  • 비기능 요구사항
    • 시스템, 성능, 인터페이스, 데이터(변환, 보안), 테스트, 보안, 품질, 제약(서비스나 기능에 대한), 프로젝트 관리 방법&지원 요구사항
  • 사용자 요구사항
    • 사용자 관점에서 본 시스템이 제공해야 할 요구사항
    • 친숙한 표현과 이해하기 쉽게 작성
  • 시스템 요구사항
    • 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
    • 전문적이고 기술적인 용어 사용
    • = 소프트웨어 요구사항
• 요구사항 개발 프로세스
  • 개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서에 정리한 다음 마지막으로 이를 확인 및 검증하는 일련의 구조화된 활동
  • 타당성조사가 선행되어야 함
  • 도출 -> 분석 -> 명세 -> 확인
• 요구사항 도출
  • 시스템, 사용자, 그리고 시스템 개발에 관련된 사람들이 서로 의견을 교환하여 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정
  • 소프트웨어 개발 생명 주기 동안 지속적으로 반복
  • 주요 기법에는 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스
• 요구사항 분석
  • 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
  • 비용과 일정에 대한 제약을 설정
  • 상충되는 요구사항 해결
  • 소프트웨어의 범위를 파악
  • 소프트웨어와 주변 환경이 상호 작용하는 방법을 이해
• 요구사항 명세
  • 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것을 의미
  • 기능 요구사항은 빠짐없이 완전하고 명확하게 기술해야 하며, 비기능 요구사항은 필요한 것만 명확하게 기술
  • 설계 과정에서 잘못된 부분이 확인될 경우 그 내용을 요구사항 정의서에서 추적할 수 있어야 함
• 요구사항 확인
  • 개발 자원을 요구사항에 할당하기 전에 요구사항 명세서가 정확하고 안전하게 작성되었는지를 검토하는 활동
  • 확인과 검증
  • 이해 관계자들이 검토
  • 요구사항 관리 도구를 이용하여 요구사항 정의 문서들에 대해 형상 관리를 수행

SECTION9 UML(Unified Modeling Language)

• UML의 개요
  • 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
  • 객체지향 방법론의 장점을 통합
  • 객체 기술에 관한 국제표준화기구 OMG에서 표준으로 지정
  • 시스템의 구조를 표현하는 6개의 구조 다이어그램과 시스템의 동작을 표현하는 7개의 행위 다이어그램이 있음
  • 사물과 사물간의 관계를 용도에 맞게 표현
  • 요소: 사물, 관계, 다이어그램
• 사물
  • 다이어그램 안에서 관계가 형성될 수 있는 대상
  • 구조사물
    • 시스템의 개념적, 물리적 요소
    • ex) 클래스, 유스케이스, 컴포넌트, 노드
  • 행동 사물
    • 시간과 공간에 따른 요소들의 행위를 표현
    • ex) 상호작용, 상태 머신 등
  • 그룹 사물
    • 요소들을 그룹으로 묶어서 표현
    • ex) 패키지
  • 주해 사물
    • 부가적인 설명이나 제약조건 등을 표현
    • ex) 노트
• 관계
  • 사물과 사물 사이의 연관성을 표현한 것
  • 연관 관계
    • 2개 이상의 사물이 서로 관련되어 있음을 표현
    • 사물 사이를 실선으로 연결하여 표현, 방향성은 화살표로 표현
    • 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결
    • 연관에 참여하는 객체의 개수를 의미하는 다중도를 선 위에 표기
    • ex) 사람 ㅡ> 집, 선생님 ㅡ 학생
  • 집합 관계
    • 하나의 사물이 다른 사물에 포함되어 있는 관계
    • 포함하는 쪽과 포함되는 쪽은 서로 독립적
    • 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 연결하여 표현
    • ex) 컴퓨터 ◇ㅡ 프린터
  • 포함 관계
    • 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현
    • 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고 생명주기를 함꼐함
    • 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현
    • ex) 문 ◆ㅡ 키
  • 일반화 관계
    • 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
    • 상위(부모), 하위(자식)이라고 부름
    • 구체적(하위)인 사물에서 일반적(상위)인 사물쪽으로 속이 빈 화살표를 연결하여 표현
    • ex) 사람 ◁ ㅡ 남자와 여자, 커피 ◁ ㅡ 아메리카노와 에스프레소
  • 의존 관계
    • 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
    • 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계를 표현
    • 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현
    • ex) 등급 ------------> 할인율
  • 실체화 관계
    • 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현
    • 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현
    • ex) 비행기, 새 -----------▷ 날수있는
• 다이어그램
  • 사물과 관계를 도형으로 표현한 것
  • 여러 관점에서 시스템을 가시화한 뷰를 제공함으로써 의사소통에 도움을 줌
  • 정적 모델링에서는 주로 구조적 다이어그램을 사용하고 동적 모델링에서는 주로 행위 다이어그램을 사용
  • 구조적 다이어그램의 종류
    • 클래스 다이어그램
      • 속성, 관계를 표현
      • 시스템 구조 파악, 문제점 도출 할 수 있음
    • 객체 다이어그램
      • 인스턴스를 특정 시점의 객체와 객체 사이의 관게로 표현
    • 컴포넌트 다이어그램
      • 실제 구현 모듈인 컴포넌트 간의 관계나 인터페이스를 표현
      • 구현 단계에서 사용
    • 배치 다이어그램
      • 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
      • 노드와 통신 경로 표현
      • 구현 단계에서 사용
    • 복합체 구조 다이어그램
      • 내부 구조 표현
    • 패키지 다이어그램
      • 그룸화한 패키지들의 관계를 표현
  • 행위 다이어그램의 종류
    • 유스케이스 다이어그램
      • 사용자의 요구를 분석하는 것으로 기능 모델링 작업에 사용
      • 사용자와 사용 사례로 구성되며, 사용 사례 간에는 여러 형태의 관계로 이루어짐
    • 시퀸스 다이어그램
      • 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현
    • 커뮤니케이션 다이어그램
      • 시퀸스 + 객체들간의 연관까지 표현
    • 상태 다이어그램
      • 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현
    • 활동 다이어그램
      • 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
    • 상호작용 개요 다이어그램
      • 상호작용 다이어그램 간의 제어 흐름을 표현
    • 타이밍 다이어그램
      • 객체 상태 변화와 시간 제약을 명시적으로 표현