1과목 - 소프트웨어 설계
1장. 요구사항 확인
1. 소프트웨어 생명 주기
소프트웨어 생명 주기 (Software Life Cycle)
- 소프트웨어 개발 방법론의 바탕이 되는 것으로 소프트웨어를 개발하기 위한 과정을 각 단계별로 나눈 것
- 소프트웨어 개발 단계와 각 단계별 주요 활동 및 결과에 대한 산출물로 표현
- 소프트웨어 생명 주기 모형
- 폭포수 모형
- 프로토타입 모형
- 나선형 모형
- 애자일 모형
폭포수 모형 (Waterfall Model)
- 전통적인 소프트웨어 생명 주기 모형
- 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형
- 각 단계가 끝난 후 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함
프로토타입 모형 (Prototype Model, 원형 모형)
- 사용자의 요구사항을 정확히 파악하기 위해 시제품을 만들어 최종 결과물을 예측하는 모형
- 시제품(prototype)은 사용자와 시스템 사이 인터페이스에 중점을 두어 개발
- 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형
나선형 모형 (Spiral Model, 점진적 모형)
- 폭포수 모형과 프로토타입 모형의 장점 + 위험 분석 기능
- 위험을 관리하고 최소화하는 것이 목적
애자일 모형 (Agile Model)
- 고객 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발
- 고객과의 소통에 초점을 맞춘 방법론
- 스프린트(spring)라고 불리는 짧은 개발 주기를 반복하며, 주기마다 고객의 평가를 적극 수용
- 애자일 모형을 기반으로 하는 소프트웨어 개발 모형
- 스크럼
- XP
- 칸반
- ASD / FDD 등
2. 스크럼 (Scrum) 기법
스크럼의 개요
- 스크럼은 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어
- 럭비에서 양 팀 선수들이 럭비공을 가운데 두고 서로 대치해 있는 대형
- 스크럼 팀
- 제품 책임자 (PO, Product Owner)
- 요구사항을 작성하는 주체로 주로 개발 의뢰자나 사용자
- 요구사항이 담긴 백로그를 작성하고 백로그에 대한 우선순위 지정
- 스크럼 마스터 (SM, Scrum Master)
- 스크럼을 잘 수행할 수 있도록 조언해주는 가이드 역할
- 개발팀 (DT, Development Team)
- PO와 SM을 제외한 모든 팀원
- 제품 책임자 (PO, Product Owner)
스크럼 개발 프로세스
- 제품 백로그 (Product Backlog)
- 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
- 제품 백로그에 작성된 스토리를 기반으로 릴리즈 계획 수립
- 스프린트 계획 회의 (Sprint Planning Meeting)
- 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립
- 태스크 단위로 분할한 수 스프린트 백로그 작성
- 스프린트 (Sprint)
- 실제 개발 작업을 진행하는 과정 (보통 2~4주)
- 개발 담당자에게 태스크 할당 (To Do / In Progress / Done)
- 일일 스크럼 회의 (Daily Scrum Meeting)
- 모든 팀원이 매일 약속된 시간에 15분 정도 진행 상황 점검
- 스프린트 검토 회의 (Sprint Review)
- 사용자가 포함된 참석자 앞에서 테스팅 수행
- 스프린트 한 주당 한 시간 내에서 진행
- 스프린트 회고 (Sprint Retrospective)
- 스프린트 주기를 되돌아보며 규칙은 잘 준수했는지, 개선 사항은 없는지 확인하고 기록
- 해당 스프린트가 끝난 시점 혹은 일정 주기로 수행
3. XP (eXtreme Programming) 기법
XP (eXtreme Programming)
- XP는 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
- 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적은 참여를 통해 빠르게 개발하는 것이 목적
- 릴리즈 테스트마다 고객을 직접 참여시킴으로써 요구한 기능이 제대로 작동하는지 고객이 직접 확인 가능
- XP의 5가지 핵심 가치
- 의사소통 (Communication)
- 단순성 (Simplicity)
- 용기 (Courage)
- 존중 (Respect)
- 피드백 (Feedback)
XP 개발 프로세스
- 사용자 스토리 (User Story)
- 고객의 요구사항을 간단한 시나리오로 표현한 것
- 릴리즈 계획 수립 (Release Planning)
- 릴리즈는 몇 개의 요구사항이 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것
- 부분 혹은 전체 개발 완료 시점에 대한 일정 수립
- 스파이크 (Spike)
- 요구사항의 신뢰성을 높이고 위험을 감소시키기 위해 별도로 만드는 프로그램
- 이터레이션 (Iteration)
- 하나의 릴리즈를 더 세분화 한 단위
- 처리할 문제 외 다른 조건은 모두 무시하고 작성
- 승인 검사 (Acceptance Test)
- 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트
- 고객이 직접 수행
- 테스트 과정에서 발견한 오류 사항은 다음 이터레이션에 포함
- 소규모 릴리즈 (Small Release)
- 릴리즈를 소규모로 하면 고객의 요구사항에 좀 더 유연하게 대응 가능
4. 현행 시스템 파악
현행 시스템 파악 절차
- 1단계
- 시스템 구성 파악
- 시스템 기능 파악
- 시스템 인터페이스 파악
- 2단계
- 아키텍처 구성 파악
- 소프트웨어 구성 파악
- 3단계
- 하드웨어 구성 파악
- 네트워크 구성 파악
5. 개발 기술 환경 파악
운영체제 (OS, Operating System)
- 운영체제는 시스템 자원들을 효율적으로 관리하고, 사용자가 컴퓨터를 효율적으로 사용할 수 있는 환경을 제공하는 소프트웨어
- 사용자와 하드웨어 간의 인터페이스로서 동작하는 시스템 소프트웨어의 일종
- Windows / UNIX / Linux / MacOS 등
데이터베이스 관리 시스템 (DBMS)
- DBMS는 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해주는 소프트웨어
- 기존의 파일 시스템이 갖는 데이터 종속성과 중복성 문제를 해결하기 위해 제안된 시스템
- Oracle / MySQL / SQLite / MongoDB 등
웹 애플리케이션 서버 (WAS, Web Application Server)
- 사용자 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
- 주로 데이터베이스 서버와 연동해서 사용
- Tomcat, GlassFish, Jetty 등
6. 요구사항 정의
요구사항의 개념 및 특징
- 요구사항은 소프트웨어 개발이나 유지 보수 과정에서 필요한 기준과 근거 제공
- 개발하려는 소프트웨어 전반적인 내용을 확인할 수 있게 하므로 이해관계자들 간의 의사소통을 원활하게 해줌
요구사항의 유형
- 기능 요구사항 (Functional Requirements)
- 시스템이 반드시 수행해야 하는 기능
- ex) 사용자는 회원 ID와 비밀번호를 입력하여 로그인할 수 있다.
- 비기능 요구사항 (Non-functional Requirements)
- 품질이나 제약사항과 관련 있는 요구사항
- ex) 시스템은 365일, 하루 24시간 운용 가능해야 한다.
- 사용자 요구사항 (User Requirements)
- 사용자 관점에서 본 시스템이 제공해야 할 요구사항
- 사용자를 위한 친숙한 표현으로 작성
- 시스템 요구사항 (System Requirements)
- 개발자 관점에서 본 요구사항
= 전문적이고 기술적인 용어로 표현
- 개발자 관점에서 본 요구사항
요구사항 개발 프로세스
- 요구사항 도출 (Elicitation)
- 요구사항이 어디에 있는지, 어떻게 수집할 것인지를 식별하고 이해하는 과정
- 소프트웨어 개발 생명 주기동안 지속적으로 반복
- 요구사항 분석 (Analysis)
- 요구사항 중 명확하지 않거나 모호한 부분을 발견하고 걸러내기 위한 과정
- 요구사항 명세 (Specification)
- 요구사항을 체계적으로 분석한 후 승인될 수 있도록 문서화하는 것
- 기능 요구사항은 빠짐없이 기술하고, 비기능 요구사항은 필요한 것만 명확하게 기술
- 요구사항 확인 (Validation)
- 이해관계자들이 요구사항 명세서가 정확하게 작성되었는지 검토
9. UML (Unified Modeling Language)
UML 개요
- 대표적인 객체지향 모델링 언어
- 구성 요소
- 사물
- 관계
- 다이어그램
사물 (Things)
- 모델을 구성하는 가장 중요한 기본 요소
관계 (Relationships)
- 사물과 사물 사이 연관성 표현
- 연관 관계 (Association)
- 2개 이상의 사물이 서로 관련되어 있음을 표현
- 사물 사이를 실선으료 연결하고, 방향성은 화살표로 표현 (양방향은 화살표 생략)
- 집합 관계 (Aggregation)
- 하나의 사물이 다른 사물에 포함되어 있는 관계를 표현
- 전체와 부분은 서로 독립적
- 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 연결하여 표현
- 포함 관계 (Composition)
- 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현
- 전체와 부분은 서로 독립될 수 없고 생명주기를 함께함
- 포함되는 쪽에서 포함하는 쪽으로 속이 채워진 마름모를 연결하여 표현
- 일반화 관계 (Generalization)
- 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
- 일반적인 개념을 부모, 구체적인 개념을 자식
- 의존 관계 (Dependency)
- 사물 사이에 연관은 있으나 짧은 시간 동안만 연관을 유지하는 관계
- 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현
