Chapter1.프로젝트 기획과 분석
-1. 프로젝트 개요
-2. 사용자 요구사항 정의서
Chapter2.프로젝트 설계
-1. 화면 정의서
-2. 테이블 명세서
-3. API 명세서
Chapter3.프로젝트 시험
-1. 진행 절차
-2. 개발자 테스트
<Chapter1.프로젝트 기획과 분석(분석 단계)>
1. 프로젝트 개요
1) 비즈니스 관점에서의 개발 프로젝트 이해
① 과업 발생
② 사업자 선정 및 계약: RFP(Request For Proposal, 제안 요청서)로 작성. 개요와 구축 컨셉, 제안요청사항 정의, 제안서 작성가이드 정의의 내용을 포함.
③ 기획/분석: SRS(Software requirements specification, 사용자 요구 정의서) 작성
④ 설계: 설계 문서(화면 정의서, 아키텍처 설계서, 클래스 정의서 등) 작성
⑤ 구현: 단위 테스트 진행
⑥ 시험: 통합 시험 진행, 사용자나 운영자 관점에서의 지침서(매뉴얼) 등을 작성
⑦ 서비스 오픈
⑧ 유지보수
2) 소프트웨어 개발 단계
① 분석 단계: 사용자 요구사항 정의서, 유스 케이스 명세서, 요구사항 추적표와 같은 문서를 작성
② 설계 단계: SRS를 기반으로 하여 범주에 벗어나지 않는 설계. 클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 단위시험 케이스, 데이터 전환 및 초기데이터 설계서와 같은 문서를 작성.
③ 구현 단계: 프로그램 코드, 단위시험 결과서, DB 생성 스크립트 등을 문서화 하여 개발의 진행 정도를 알 수 있게 가시화
④ 시험 단계: 통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서, 사용자, 운영자를 위한 지침서(매뉴얼)와 같은 문서를 작성
분석 단계 -> SRS
설계 단계 -> 화면 정의서, 테이블 명세서, API 명세서
구현 단계 -> 유닛 테스트
시험 단계 -> 개발자 테스트, Alpha 테스트, Beta 테스트, Acceptance 테스트2.SRS(Software Requirements Specification, 사용자 요구 정의서)
1) 정의
소프트웨어가 무엇을 할 것이며 어떻게 작동할 것으로 예상되는지를 설명하는 문서. 또한 제품이 모든 이해 관계자(비즈니스, 사용자)의 요구를 충족시키는데 필요한 기능을 설명.
2) 작성 목적
시스템의 요구사항을 도출하여 발주자와 내용을 합의하고, 하나의 업무 단위로서 가치를 가지고 수행될 수 있는 업무를 도출하여 업무 내용을 기술
3) 프로젝트에서 SRS가 중요한 이유
프로젝트의 전체적인 그림을 제공
소프트웨어(제품) 개발에 관련된 모든 팀이 따라야 하는 것의 집합이며 그 원천을 제공하기 때문
4) 작성 방법
산출물 양식의 표를 이용하여 해당 항목에 기술하며 이해하기 쉽고 구체적인 언어표현을 사용. 기능적 요구사항과 비기능 요구사항을 그룹핑하여 별도의 표로 작성.
-요구사항 ID: 요구사항별로 유일한 ID를 부여하여 기입
-요구사항명: 도출된 요구사항을 요약할 수 있는 명칭을 기입
-구분: 도출된 요구사항을 기능/성능/품질/인터페이스/데이터/운영/제약사항 중에서 선택하여 기재
-요구사항 설명: 사용자 요구사항을 구체적이고 상세하게 기술
-중요도: 해당 요구사항의 전체 시스템 구현 측면에서의 중요도를 기술(상, 중, 하)
-비고: 항목에 포함되지 않으나, 고려해야 할 사항이 있으면 기술
5) SRS 구성
1. 소개
1.1 목적 (Purpose)
이 문서에 요구사항이 명시되어 있는 제품 또는 애플리케이션을 설명한다. 이 SRS가 전체 시스템 중 일부에만 관련된 것이라면 그 부분 또는 하위시스템을 설명한다.
1.2 문서 규칙 (Document Convention)
텍스트 스타일, 하이라이트 또는 주석과 같은 모든 표준 또는 표기규칙을 설명한다.
1.3 독자대상과 읽는 방법 (Intend Audience and Reading Suggestion)
SRS가 대상으로 하고있는 다양한 독자계층을 나열한다. SRS의 나머지 부분과, SRS가 조직되어 있는 방법을 설명하고, 각각의 독자 계층에 대해 가장 적합한 읽기 순서를 설명한다.
1.4 프로젝트 범위 (Project Scope)
설명되고 있는 소프트웨어와 그 목적에 대해 간단하게 설명한다.
1.5 참조 (Reference)
이 SRS가 참조하고 있는 모든 문서 또는 다른 리소스를 나열하며, 가능한 경우에는 하이퍼링크도 포함시킨다.
2. 전체 설명 (Overall Description)
2.1 제품조망 (Product Perspective)
제품의 구성과 유래를 설명한다. 제품이 확장되는 제품군의 다음 구성제품인지, 완성된 시스템의 다음 버전인지, 기존 애플리케이션을 대체하는 것인지, 완전히 새로운 제품인지를 설명한다.
2.2 제품 기능 (Project Feature)
제품이 가지고있는 주요기능 또는 제품이 수행하는 중요한 기능을 나열한다. 요구사항의 주요 그룹과 그 그룹이 연결되어 있는 방법을 설명하는 최상위 데이터 플로우 다이어그램, 유스케이스 다이어그램, 클래스 다이어그램 등이 도움이 된다.
2.3 사용자 계층과 특징 (User Classes and Characteristic)
이 제품을 사용할 것으로 예상되는 사용자계층을 파악하고 그들의 특징을 설명한다.
2.4 운영 환경 (Operation Environment)
하드웨어 플랫폼, 운영체계와 버전, 사용자, 서버와 데이터베이스의 지리적 위치 등과 같은 소프트웨어가 동작되는 환경을 설명한다. 시스템이 아무런 문제없이 연동해야 하는 다른 소프트웨어 컴포넌트 또는 애플리케이션을 나열한다.
2.5 설계 및 구현 제약사항 (Design and Implementation constraint)
개발자가 선택할 수 있는 사항을 제약하는 모든 요소와 각 제약조건의 이유를 설명한다. 제약 조건은 다음과 같다.
반드시 사용하거나 피해야 하는 기술, 툴, 프로그래밍 언어와 인터페이스.
사용될 웹 브라우저의 유형과 버전과 같이 제품의 운영환경으로 인한 제약.
필요한 개발 규칙 또는 표준(예를 들면 고객의 조직이 소프트웨어를 유지보수 할 예정이라면, 그 조직은 하청업체가 따라야 하는 설계 표기법과 코딩 표준을 명시 할 수 있다.)
이전 제품과의 호환성.
비즈니스 규칙에 따른 제약.
메모리 또는 프로세스의 제약, 크기, 무게, 비용과 같은 하드웨어의 제약.
기존 제품을 개선하는 경우에 따라야 하는 기존 사용자 인터페이스 규칙.
XML과 같은 표준 데이터 교환 형식.
2.6 사용자 문서 (User Documentation)
소프트웨어와 함께 제공할 사용자 문서를 나열한다. 사용자 문서로는 사용자 메뉴얼, 온라인 도움말, 교재 등이 있으며 따라야 하는 문서 전달 형식, 표준 또는 툴이 있다면 그것들을 설명한다.
2.7 가정과 종속관계 (Assumptions and Dependencies)
가정이 잘못되거나 이것을 공유하지 않는다면 문제가 발생될 수 있기 때문에 어떤 가정은 프로젝트 위험으로 간주된다. 프로젝트가 통제할 수 없는 외부 요소에 어느정도 종속되는지 또한 설명해야 한다.
3. 시스템 특징 (System Feature)
3.1 시스템 특징
가. 설명과 우선순위 (Description and Priority)
기능에 대해 간단하게 설명하고 그것이 높은 우선순위인지 낮은 우선순위인지를 나타낸다. 우선순위는 프로젝트 중에 변할 수 있는 동적인 것으로, 요구사항관리 툴을 사용한다면 요구사항 특성의 우선순위를 정의한다.
나. 자극/응답 순서 (Stimulus / Response Sequence)
입력 자극(사용자 행동, 외부 장비의 신호 또는 다른 자극)의 순서와 이 기능에 대한 동작을 정의하는 시스템 반응을 나열한다.
다. 기능 요구사항 (Functional Requirement)
이 기능과 관련된 상세한 기능 요구사항을 항목으로 나열한다. 이것들은 사용자가 기능의 서비스를 수행하기 위해 또는 유스케이스를 수행하기 위해 사용하는 소프트웨어의 기능들이다.
4. 외부 인터페이스 요구사항 (External Interface Requirement)
4.1 사용자 인터페이스 (User Interface)
시스템이 요구하는 각각의 사용자 인터페이스와 논리적인 특징을 설명한다. 따라야 할 GUI 표준 또는 제품 스타일 가이드에 대한 참조.
폰트, 아이콘, 버튼 레이블, 이미지, 색상 체계, 필드탭 순서, 공통으로 사용되는 컨트롤 등에 대한 표준.
화면 레이아웃 또는 해상도 제약 조건.
도움말 버튼과 같이 모든 화면에 나타나는 표준 버튼, 기능 또는 탐색 링크.
단축키.
메시지 표시 규칙.
소프트웨어 번역을 원활하게 하는 레이아웃 표준.
시각장애자를 위한 기능.
사용자 인터페이스 설계 상세 내용은 SRS가 아닌 별도의 사용자 인터페이스 명세에 문서로 정리한다.
4.2 하드웨어 인터페이스 (Hardware Interface)
시스템의 소프트웨어와 하드웨어 컴포넌트간의 모든 인터페이스의 특징을 설명한다. 설명에는 지원되는 장비 유형, 소프트웨어와 하드웨어간의 데이터와 컨트롤 연동, 사용될 통신 프로토콜 등이 포함된다.
4.3 소프트웨어 인터페이스 (Software Interface)
이 제품과 다른 소프트웨어 컴포넌트(데이터베이스, 운영체제, 툴, 라이브러리, 통합 상업용 컴포넌트)간의 연결을 설명한다. 소프트웨어 컴포넌트 간에 교환되는 메시지, 데이터와 컨트롤 항목을 설명한다.
4.4 통신 인터페이스 (Communication Interface)
이메일, 웹 브라우저, 네트워크 통신 프로토콜, 전자 문서와 같이 제품이 사용할 모든 통신 기능에 대한 요구사항을 설명한다. 관련된 모든 메시지 형태를 정의하고 통신 보안 또는 암호화 문제, 데이터전송률과 동기화 메커니즘을 명시한다.
5. 기능 이외의 다른 요구사항 (Other Nonfunctional Requirements)
5.1 성능 요구사항 (Performance Requirement)
다양한 시스템 운영에 대한 특정 성능 요구사항을 설명한다. 개발자들이 적합한 설계를 선택할 수 있게 만든 논리를 설명한다.
5.2 안전 요구사항 (Safety Requirement)
반드시 방지해야 하는 잠재적으로 위험한 행동 뿐만 아니라 반드시 취해야 할 모든 안전장치 또는 행동을 정의한다. 제품이 따라야 하는 보안인증, 정책 또는 규제를 정의한다.
5.3 보안 요구사항 (Security Requirement)
제품에 대한 접속과 제품사용에 영향을 미치는 보안, 무결성 또는 사생활 문제, 제품이 사용하거나 만드는 데이터 보호를 모두 명시한다.
5.4 소프트웨어 품질 특성 (Software Quality Attribute)
고객 또는 개발자에게 중요한 모든 별도의 품질 특성을 설명한다. 이런 특성들은 명확하고 계량적이며 확인이 가능해야 한다.
6. 다른 요구사항 (Other Requirement)
SRS의 다른 부분에서는 다루지 않는 모든 요구사항을 정의한다.<Chapter2.프로젝트 설계(설계 단계)>
1.화면 정의서
1) 작성 목적
시스템이 제공하는 사용자 인터페이스의 전체 구조와 메뉴 형식, 화면 목록과 화면의 상세 설계 내역을 기술
2) 작성 방법
전체 시스템에 대한 사용자 인터페이스의 구조를 사용자에게 제공하는 메뉴 형식으로 기술하고, 화면 및 출력으로 구분하여 목록을 작성하며, 화면의 상세 설계 내용을 화면별로 기술
3) 항목 설명
-화면 ID: 설계된 화면에 고유값을 부여
-화면명: 알아볼 수 있는 화면에 대한 제목을 부여
-화면 유형: 입력/출력 중 알맞은 유형을 선택. 기타 유형이 존재한다면 알맞게 작성.
-메뉴 경로: 해당 화면이 서비스의 어디에 위치하는지 설명
-화면 개요: 화면의 간단한 설명을 추가
-화면 미리보기: 와이어 프레임과 같은 화면 설계 툴을 사용하여 작성된 화면 미리보기 이미지를 삽입하고 해당 화면에서 기능을 수행하는 항목을 번호를 매겨 표시
-기능 번호: 화면 미리보기에서 표시된 기능의 번호를 기입
-요구사항 ID: 해당 기능이 사용자 요구사항 정의서에 기술된 어떤 항목인지를 아이디로 표시
-API 활용 여부: 이 기능이 API를 활용하는 기능인지를 구분
-API 주소: API 활용 여부가 YES라면 어떤 API를 호출하는지 기입
-유효성 체크: 기능이 동작하는 동안 화면 내에서 필수적으로 사용되어야 할 데이터에 대한 유효성 체크
ex) 회원 가입을 할 때 아이디와 비밀번호는 필수로 작성되어야 함 → 아이디, 비밀번호
2.테이블 명세서
1) 작성 목적
최종적으로 설계된 테이블과 인덱스를 데이터베이스 공간에 맵핑시키고 저장공간 등의 물리 모델을 기술
2) 작성 방법
부서에서 운영하는 데이터베이스 목록을 작성하고, 데이터베이스의 물리적 상세내용을 기술
3) 항목 설명
-데이터베이스 명: 데이터베이스 명칭을 기입
-테이블 명: 테이블 명칭을 기입
-요구사항 ID: 테이블이 사용되는 사용자 요구사항 정의서의 ID를 맵핑
-테이블 설명: 테이블의 목적 및 역할을 간략하게 기술
-컬럼명: 테이블 컬럼의 내용과 특성을 인식할 수 있는 명칭을 기술
-컬럼 ID: 테이블 컬럼 ID를 기술
-타입 및 길이: 컬럼의 타입과 최대 허용 길이를 기술
-NOT NULL: 필수항목 여부
-PK(Primary Key): 주키 여부를 의미
-FK(Foreign Key): 외래키를 의미
-INX(Index): 인덱스를 의미
-기본값: 속성의 기본값이 있는 경우에 그 값을 기술
-제약조건: 속성의 특이한 제약조건이 있는 경우 기술
3.API 명세서
1) REST API(Representational State Transfer Application Programming Interface)
(1) 관련 용어
① 리소스: 미디어, DB 데이터 등 모든 자원. 즉, RESTful한 API로써 통신할 때 기대하는 결과값에 해당하는 자원들의 일체
② URI(Uniform Resource Identifier): 특정 리소스르 식별하는 '통합 자원 식별자'
scheme:[//[user[:password]@host[:port]][/path][?query][#fragment]-scheme: http 또는 https를 사용
-user, password: 데이터가 있는 서버에 접근하기 위해 필요한 ID와 PASSWORD
-host, port: 서버의 호스트와 포트 번호
-path: 서버의 상세 경로
-query: path에 접근하기 위한 추가 정보(파라미터)
-fragment: 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 식별하기 위한 정보
(2) RESTful한 API의 정의
모든 리소스에 대해 고유한 URI를 부여하고 HTTP Method를 적절히 사용하여 리소스를 제어할 수 있는 수단
(3) REST의 특징
서버-클라이언트 구조(Server-Client Architecture)
무상태성(Stateless)
캐시 가능(Cacheable)
일관된 인터페이스(Uniform Interface)
자체적인 표현 구조(Self-Descriptiveness)
계층 구조(Layered System)
2) REST API 규칙
3) 관계 나타내기
http://test.com/groups/1/users-groups, users: 이와 같이 복수로 표현되는 것들은 보통 여러개의 리소스를 갖을 수 있으므로 복수형으로 표시하고 Collection 이라고 부름
-1: Collection에 포함된 대상 리소스는 단수형으로 표시하고 Document라고 부름
-/groups/1/users: Collection과 Document의 관계를 /를 통해 나타낼 수 있음. groups이라는 Collection 안에 ‘1’ Document를 나타내고, 해당 Document가 갖고 있는 users를 나타냄.
4) HTTP Method
-GET : Query의 ‘SELECT’에 해당
-POST : Query의 ‘INSERT’에 해당
-PUT : Query의 ‘UPDATE’에 해당
-DELETE : Query의 ‘DELETE’에 해당
<Chapter3.프로젝트 시험(시험 단계)>
1.진행 절차
1) 관련 용어
① 블랙박스 테스트 vs 화이트박스 테스트
-블랙박스 테스트: 테스트를 진행 하는 사람이 시스템 내부 설계를 모르는 상태에서 기능만 사용함으로써 정상 동작 여부를 판단하는 방식(대부분 시험 단계에서 진행)
-화이트박스 테스트: 내부 구조와 코드를 알고 있는 상태에서 진행되는 테스트(대부분 구현 단계에서 진행)
ex. 유닛 테스트
② TC(Test Case), 체크리스트
TC가 조금 더 설계적 관점이 포함되어 있다고는 되어 있지만 실제로는 두개의 용어가 구별없이 혼용되어 사용
-체크리스트: 테스트 할 항목이 모여 있는 문서
-체크 항목: 테스트 할 항목
③ QA(Quality Assurance) 팀
시험단계에 필요한 체크리스트 작성 및 테스트를 실시 하고 배포된 서비스의 사후 품질을 관리
2) 사전 준비
① 통합 테스트 환경 구축
시험 단계의 테스트: 실제 배포 환경과 동등한 환경에서 실시
테스트가 진행되는 환경: 서비스의 목적과 난이도에 따라 각각의 구성 방식과 수가 결정
ex) 아직 배포를 한번도 하지 않는 서비스의 경우 -> 배포 전까지 배포 환경을 통합 테스트 환경으로 사용
② 개발자 테스트
시험 단계 진입을 판단하기 위해 실시하는 테스트. 개발자가 구현 단계에서 개발한 기능이 통합 테스트 환경에서 정상 동작 하는 지를 직접 확인.
3) 진행 절차
(1) Alpha 테스트
기본 적인 기능 테스트를 실시하는 단계(예외 상황까지 포함)
기대 동작에 대한 자세한 정의는 보통 사용자 요구사항 정의서나 다른 정책 문서에 기입되어 있음
ex) 회원가입 Alpha 테스트
에러 토스트의 위치나 글자 색 등 -> 사용자 요구사항 정의서/정책 문서에 기입
(2) Beta 테스트
① 정의
Alpha 때 보다 복잡한 상황을 만들어서 테스트 하는 단계
② 진입 조건
Alpha 테스트 패스율 100%
③ 특징
-회귀 테스트로 진행
- 회귀 테스트: 이전에 테스트한 항목을 다시 테스트 하는 행위(Alpha 테스트 항목을 포함)
- 회귀 테스트를 진행하는 이유: 개발자의 코드 수정으로 인해 예상지 못한 사이드 이펙트가 발생했는지를 확인하기 위해
- Beta 테스트 중 회귀 테스트 항목에서 에러가 일정 수치 이상으로 발생하면 Beta는 중단되고 다시 Alpha로 돌아감.
-Beta 테스트 기간에는 체크리스트 기반의 기능 테스트와는 별개로 성능 테스트를 실시
(3) Acceptance 테스트
① 정의
상용 배포 결정 후 마지막 테스트 단계
② 진입 조건
Beta 테스트를 일정 수준 이상으로 통과
③ 특징
보통 Alpha 체크리스트의 내용을 일부를 그대로 사용하는 경우가 많음(100% 회귀 테스트)
2.개발자 테스트
1) 개발자 테스트 체크리스트
(1) 수준
기본 기능의 검증을 주요 목적으로 함(예외 상황 포함하지 않음, 예외 상황은 구현 단계에서 유닛 테스트를 통해 검증)
(2) 작성 방법
만약 Alpha 테스트였다면 등록 시 작성자의 누락, 제목의 누락, 내용의 누락 등등의 예외 처리 테스트 항목이 체크리스트에 포함. 하지만 개발자 테스트이므로 포함하지 예외 상황은 포함하지 않음.
(3) 실시 방식
① 개발자 테스트를 실시하는 경우
-기능 개발 완료 후 해당 코드가 통합 테스트 환경에 최초 배포 될 때(관련된 체크 항목만 테스트)
-관련된 코드가 수정 되었을 때(관련된 체크 항목만 테스트)
-마지막 안정화 버전이 통합 테스트 환경에 배포 될 때(모든 체크 항목 테스트)
② 안정화 버전 배포 시 개발자 테스트 진행 순서
-배포 환경에 제출일 기준 최신 안정화 버전 배포
-개발자 테스트 실시 후 체크리스트에 결과 업데이트
-배포 환경 링크와 개발 테스트 체크리스트 제출
