codestates/preproject

Unit3 - 프로젝트 관리하기

나아눙 2023. 4. 12. 23:16

스택오버플로우를 제작한다.

SRS(=종합 설계도): 우리가 개발하고자 하는 소프트웨어(제품)가 무엇을 하는 것이고 어떻게 작동할지를 예상하는 문서의 집합

 

비즈니스 관점에서의 개발 프로젝트 이해

과업 발생 :즉 니즈가 발생하는 발주처에서 진행되어야 할 과업(프로젝트)이 그 집단의 니즈에 맞게 발생

 

사업자 선정 및 계약 : 발주처는 선정된 사업장에 명확한 요구사항과 일정, 사업 비용 등을 명시할 필요가 있다.

RFP(Request For Proposal, 제안 요청서)로 작성하여 문서화

 

기획/분석:진행할 프로젝트의 계약을 포함한 모든 사전 처리가 완료되었다면 프로젝트를 총괄하는 PM (Project Manager)은 프로젝트를 성공적으로 수행하기 위해서 일해야한다.

 

설계:기획된 SRS의 목표에 따라 그에 맞는 구체적인 설계가 고려되는 과정이다.

화면 정의서, 아키텍처 설계서, 클래스 정의서 등이 설계 문서의 일부

 

구현:실제로 기획/분석 → 설계 과정을 거친 후 그 가이드에 맞게 개발 업무를 수행하는 과정

목적에 맞게 개발업무 진행

 

시험:올바르게 구현이 되었는지, 구현의 결과가 올바른 설계에 의한 것인지 등을 면밀하게 검토할 필요가 있다.

유닛 테스트'를 통해 올바른 개발이 지속될 수 있는지를 판단했다면

시험 단계에서는 ‘통합 시험'을 통해 완성된 온전한 하나의 서비스가 그 역할을 잘 수행할 수 있는지를 검사한다.

 

서비스오픈

 

유지보수

 

개발 프로젝트 구분

솔루션 : 솔루션이라고 함은 기업에서 개발한 제품이다.

ex) 카카오톡, 배달의 민족 애플리케이션

 

SI (System Integration) : 시스템 구축을 의미

시간이 지나면서 시스템이 복잡해지고 더 높은 전문성이 요구됨에 따라 특화된 기업과 계약을 맺고 진행하는 형태로 발전

 

SM (System Management) : 시스템 운영 및 유지보수를 의미

 

SRS의 구성

SRS 문서는 아래 소개된 목차로 구성하는 템플릿 가지고 있다.

1. 소개

1 목적 (Purpose)

2 문서 규칙 (Document Convention)

3 독자대상과 읽는 방법 (Intend Audience and Reading Suggestion)

4. 프로젝트 범위

5 참조 (Reference)

 

2.전체 설명 (Overall Description)

1.제품조망 (Product Perspective

2 제품 기능 (Project Feature)

3 사용자 계층과 특징 (User Classes and Characteristic)

4 운영 환경 (Operation Environment)

5 설계 및 구현 제약사항 (Design and Implementation constrain

6 사용자 문서 (User Documentation)

7 가정과 종속관계 (Assumptions and Dependencies)

 

3.시스템 특징 (System Feature)

가. 설명과 우선순위 (Description and Priority)

기능에 대해 간단하게 설명하고 그것이 높은 우선순위인지 낮은 우선순위인지를 나타낸다.

 

나. 자극/응답 순서 (Stimulus / Response Sequence)

입력 자극의 순서와 이 기능에 대한 동작을 정의하는 시스템 반응을 나열한다.

다. 기능 요구사항 (Functional Requirement)

이 기능과 관련된 상세한 기능 요구사항을 항목으로 나열

 

4.외부 인터페이스 요구사항 (External Interface Requirement)

1. 사용자 인터페이스

2. 하드웨어 인터페이스

3. 소프트웨어 인터페이스

4. 통신 인터페이스

 

5.기능 이외의 다른 요구사항 (Other Nonfunctional Requirements)

1 성능 요구사항 (Performance Requirement)

2 안전 요구사항 (Safety Requirement)

3 보안 요구사항 (Security Requirement)

4 소프트웨어 품질 특성 (Software Quality Attribute)

사용자 요구 사항 정의서

소프트웨어 개발 단계

RFP(Request For Proposal)를 통해 제안요청을 하고 프로젝트 계약이 완료되면 SRS(Software requirements specification)를 통해 프로젝트의 큰 그림을 설계

분석 단계

사용자 요구사항 정의서, 유스 케이스 명세서, 요구사항 추적표와 같은 문서를 작성함으로써 보다 구체적으로 분석

설계 단계

클래스 설계서, 사용자 인터페이스 설계서, 컴포넌트 설계서, 인터페이스 설계서, 아키텍처 설계서, 총괄시험 계획서, 시스템시험 시나리오, 엔티티 관계 모형 기술서, 데이터베이스 설계서, 통합시험 시나리오, 유닛 테스트 케이스, 데이터 전환 및 초기데이터 설계서와 같은 문서를 작성함으로써 보다 구체적으로 설계

구현 단계

 프로그램 코드, 유닛 테스트 결과서, DB 생성 스크립트 등을 문서화 하여 개발의 진행 정도를 알 수 있게 가시화

시험 단계

통합시험 결과서, 시스템시험 결과서, 사용자 지침서, 운영자 지침서, 시스템 설치 결과서, 인수시험 시나리오, 인수시험 결과서와 같은 문서를 작성함으로써 보다 구체적으로 시험을 진행

지침서도 작성

 

작성 목적

시스템의 요구사항을 도출하여 발주자와 내용을 합의하고, 하나의 업무 단위로서 가치를 가지고 수행될 수 있는 업무를 도출하여 업무 내용을 기술한다.

 

작성 방법

산출물 양식의 표를 이용하여 해당 항목에 기술하며 이해하기 쉽고 구체적인 언어표현을 사용한다. 기능적 요구사항과 비기능 요구사항을 그룹핑하여 별도의 표로 작성한다.

 

항목 설명

요구사항 ID : 요구사항별로 유일한 ID를 부여하여 기입

요구사항명 : 도출된 요구사항을 요약할 수 있는 명칭을 기입

구분 : 도출된 요구사항을 기능 / 성능 / 품질 / 인터페이스 / 데이터 / 운영 / 제약사항 중에서 선택하여 기재

요구사항 설명 : 사용자 요구사항을 구체적이고 상세하게 기술

중요도 : 해당 요구사항의 전체 시스템 구현 측면에서의 중요도를 기술(상 , 중 ,하)

비고 : 항목에 포함되지 않으나, 고려해야 할 사항이 있으면 기술

화면 정의서

작성 목적

시스템이 제공하는 사용자 인터페이스의 전체 구조와 메뉴 형식, 화면 목록과 화면의 상세 설계 내역을 기술한다.

작성 방법

전체 시스템에 대한 사용자 인터페이스의 구조를 사용자에게 제공하는 메뉴 형식으로 기술하고, 화면 및 출력으로 구분하여 목록을 작성하며, 화면의 상세 설계 내용을 화면별로 기술한다.

 

  • 화면 ID : 설계된 화면에 고유값을 부여.
  • 화면명 : 알아볼 수 있는 화면에 대한 제목을 부여
  • 화면 유형 : 입력 / 출력 중 알맞은 유형을 선택, 기타 유형이 존재한다면 알맞게 작성
  • 메뉴 경로 : 해당 화면이 서비스의 어디에 위치하는지 설명
  • 화면 개요 : 화면의 간단한 설명을 추가
  • 화면 미리보기 : 와이어 프레임과 같은 화면 설계 툴을 사용하여 작성된 화면 미리보기 이미지를 삽입하고 해당 화면에서 기능을 수행하는 항목을 번호를 매겨 표시
  • 기능 번호 : 화면 미리보기에서 표시된 기능의 번호를 기입
  • 요구사항 아이디 : 해당 기능이 사용자 요구사항 명세서에 기술된 어떤 항목인지를 아이디로 표시
  • API 활용 여부 : 이 기능이 API를 활용하는 기능인지를 구분
  • API 주소 : API 활용 여부가 YES라면 어떤 API를 호출하는지 기입
  • 유효성 체크 : 기능이 동작하는 동안 화면 내에서 필수적으로 사용되어야 할 데이터에 대한 유효성 체크
  • 예) 회원 가입을 할 때 아이디와 비밀번호는 필수로 작성되어야 한다. → 아이디, 비밀번호
 

테이블 정의서

작성 목적

최종적으로 설계된 테이블과 인덱스를 데이터베이스 공간에 맵핑시키고 저장공간 등의 물리 모델을 기술한다.

 

작성 방법

부서에서 운영하는 데이터베이스 목록을 작성하고, 데이터베이스의 물리적 상세내용을 기술한다.

  • 데이터베이스 명 : 데이터베이스 명칭을 기입
  • 테이블 명 : 테이블 명칭을 기입
  • 요구사항 ID : 테이블이 사용되는 요구사항 정의서의 ID를 맵
  • 테이블 설명 : 테이블의 목적 및 역할을 간략하게 기술
  • 컬럼명 : 테이블 컬럼의 내용과 특성을 인식할 수 있는 명칭을 기술
  • 컬럼 ID : 테이블 컬럼 ID를 기술
  • 타입 및 길이 : 컬럼의 타입과 최대 허용 길이를 기술
  • NOT NULL : 필수항목 여부를 나타낸다.
  • PK (Primary Key) : 주키 여부를 나타낸다.
  • FK (Foreign Key) : 외래키를 의미한다.
  • INX (Index) : 인덱스를 의미한다.
  • 기본값 : 속성의 기본값이 있는 경우에 그 값을 기술한다.
  • 제약조건 : 속성의 특이한 제약조건이 있는 경우 기술합니다

 

API 명세서

REST(Representational State Transfer) API(Application Programming Interface)

API를 정의할 때 웹 애플리케이션은 보통 RESTful한 API를 정의하고 구현

RESTful ? 

리소스 : 미디어 ,DB데이터등 모든 자원 의미

RESTful한 API로써 통신을 할 때 기대하는 결과값에 해당하는 자원들의 일체를 의미

 

URI(Uniform Resource Identifier)란 특정 리소스를 식별하는 ‘통합 자원 식별자'를 의미

URI는 식별하고 URL은 위치를 알려준다

 

scheme:[//[user[:password]@host[:port]][/path][?query][#fragment]
  • scheme : http 또는 https를 사용
  • user, password : 데이터가 있는 서버에 접근하기 위해 필요한 ID와 PASSWORD
  • host, port : 서버의 호스트와 포트 번호
  • path : 서버의 상세 경로
  • query : path에 접근하기 위한 추가 정보 (파라미터)
  • fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 식별하기 위한 정보

REST API 규칙

/로 끝나지 않는다.

_ 말고 -

소문자를 사용

동사 사용 X

ex) add x

파일 확장자 X 

ex) http://test.com/grops/2/face Accept:image/png

 

http://test.com/groups/1/users

groups,users : 여러개 리소스를 갖을수 있으므로 복수형으로 표시

Collection으로 부른다.

/groups/1/users : 그룹이라는 Collection안에 1 Document를 나타낸다.

1Document가 갖고 있는 사용자들

 

HTTP Method

예시        
/users 사용자 전체 조회 신규 사용자 등록 실행 불가 사용자 전체 삭제
/users/1 1 사용자 조회 실행 불가 1 사용자 수정 1 사용자 삭제
  • GET : Query의 ‘SELECT’에 해당
  • POST : Query의 ‘INSERT’에 해당
  • PUT : Query의 ‘UPDATE’에 해당
  • DELETE : Query의 ‘DELETE’에 해당

블랙박스 vs 화이트박스 테스트

블랙박스 :테스트를 진행 하는 사람이 시스템 내부 설계를 모르는 상태에서 기능만 사용함으로써 정상 동작 여부를 판단하는 방식

(블랙박스 - 시험 단계)

 

화이트박스: 내부 구조와 코드를 알고 있는 상태에서 진행되는 테스트로 개발자 유닛 테스트

(유닛테스트-구현 단계에서 실시)

 

TC(Test Case) vs 체크리스트

TC:테스트하는 항목

체크리스트:테스트하는 항목 또는 항목의 집합

 

  • 체크 항목 테스트 할 항목
  • 체크리스트 테스트 할 항목이 모여 있는 문서

QA팀

QA(Quality Assurance) 팀은 시험단계에 필요한 체크리스트 작성 및 테스트를 실시 하고 배포된 서비스의 사후 품질을 관리

 

사전 준비

통합 테스트 환경 구축

시험 단계의 테스트는 실제 배포 환경과 동등한 환경에서 실시 되어야 하며 테스트가 진행되는 환경은 서비스의 목적과 난이도에 따라 각각의 구성 방식과 수가 결정한다.

배포를 한번도 하지 않는 서비스의 경우에는 배포 전까지 배포 환경을 통합 테스트 환경으로 사용한다.

 

개발자 테스트

시험 단계 진입을 판단하기 위해 실시하는 테스트

개발자가 구현 단계에서 개발한 기능이 통합 테스트 환경에서 정상 동작 하는 지를 직접 확인한다.

진행 절차

Alpha 테스트

기본 적인 기능 테스트를 실시하는 단계 입니다. 여기서 이야기하는 기본 기능은 기본 예외적인 상황까지 전부 포함한다.

 

Beta 테스트

Alpha 때 보다 복잡한 상황을 만들어서 테스트 하는 단계

Beta 체크리스트는 Alpha 테스트 항목을 포함한다.

이전에 테스트한 항목을 다시 테스트 하는 행위를 회귀(Regression) 테스트이다.

회귀 테스트 한못에서 에러가 일정 수치 이상 발생 -> Beta중단 ->Alpha로 돌아감

성능 테스트를 실시

 

Acceptance 테스트

Beta 테스트를 일정 수준 이상으로 통과를 하게 되면, 상용 배포 여부가 결정한다.

상용 배포가 결정되게 되면 마지막으로 Acceptance 테스트를 진행한다.

Acceptance 테스트 대신 회귀 테스트라고 부른다.

유닛 테스트 만으로는 해당 기능이 100% 정상적으로 동작 X

 

환경이슈 

로컬에서 동작하던 코드가 배포 환경에서 동작하지 않을 수 있

 

머지 이슈

코드 머지 중에 내가 반영한 코드나 내가 사용하는 코드가 정상적으로 포함되지 않을 수 있다.

 

협업 이슈 프론트엔드, 백엔드 두 파트가 서로 검증을 완료 했다 하더라도 막상 두개의 소스를 머지 후 확인 시 예상치 못한 문제가 있을 수 있다.

 

개발자 테스트 체크리스트

1. 수준

개발자 테스트는 기본 기능의 검증을 주요 목적으로 한다.

유닛테스트(구현단계)에서 예외적인 상황에 대한 확인을 한다.

2. 작성 방법

개발자 테스트 체크리스트는 그렇게 복잡하게 작성할 필요가 없다.

No 카테고리 설명 결과 비고
1 QnA QnA게시판에 질문등록 O  
2 QnA QnA게시판에 질문삭제 X  

패스율은 전체 테스트 항목 중에 테스트에 통과한 항목의 비율을 뜻한다.

3. 실시 방식

개발자 테스트의 경우 하기의 상황 발생시 항상 해준다.

  • 기능 개발 완료 후 해당 코드가 통합 테스트 환경에 최초 배포 될 때
  • 관련된 코드가 수정 되었을 때
  • 마지막 안정화 버전이 통합 테스트 환경에 배포 될 때

진행과정

  1. 배포 환경에 제출일 기준 최신 안정화 버전 배포
  2. 개발자 테스트 실시 후 체크리스트에 결과 업데이트
  3. 배포 환경 링크와 개발 테스트 체크리스트 제출
  4.  

Pre-Project 사전 준비

개발 역량 파악

타겟 서비스 분석 및 정리

스택오버플로우의 기능과 특징을 잘 이해하고 활용함으로써 개발 프로젝트를 성공적으로 수행

 

Pre-Project 목표 설정

일정과 역량이 부족한 상황에서는 타겟 서비스의 일부 기능을 목표로 삼아야 하며

사용자 요구사항 정의서에 해당 내용이 반영

목표 수준 정의

개발 결과물의 수준을 결정할 때 가장 우선적으로 고려해야 할 것은 기능들 간의 연관성입니다. 다른 기능의 선행 조건이 되는 기능의 경우, 우선순위를 높게 설정해야 한다.

Pre-Project 수준 정의 활용법

스택오버플로우의 기능들을 Level 별로 분류하고 각 단계별로 필요한 개발 내용을 제시한다.

 

Level 0~1 단계는 Pre-Project 단계에서 달성 가능한 수준으로 구성

완료 후 , 다음 단계의 개발 아이템 중 가능한 부분을 선택하여 진행

Level 2~3 단계는 일정 안에 달성하기 어려운 도전적인 기능들로 구성

Agile 방식의 특징

짧은 개발 주기

반복적인 개발

고객과의 적극적인 소통

 

Agile vs Waterfall

Agile 방식

  • 장점
    • 빠른 피드백을 받아 기능을 수정하고 보완할 수 있기 때문에 고객 요구사항을 빠르게 반영할 수 있다.
    • 개발 중인 제품을 빠르게 출시할 수 있다.
    • 작은 단위로 진행되기 때문에 프로젝트의 방향성을 바꾸기 쉽다.
  • 단점
    • 프로젝트의 방향성이 계속 바뀌기 때문에 프로젝트의 예산, 일정, 범위 등을 제대로 관리하기 어렵다.
    • 일정이 불안정하다.
    • 각각의 스프린트에서 개발된 기능들을 하나로 통합하는 과정에서 문제가 발생할 수 있다.

Waterfall 방식

  • 장점
    • 각 단계가 명확하게 구분되어 있기 때문에 프로젝트 일정과 예산을 관리하기 쉽다.
    • 한 단계가 완료되어야 다음 단계로 넘어갈 수 있기 때문에 개발 과정을 제어하기 쉽다.
    • 개발 과정이 선형적으로 진행되기 때문에 개발자들의 역할과 책임이 명확하다.
  • 단점
    • 개발이 완료된 후에야 고객의 피드백을 받아 수정할 수 있기 때문에 고객 요구사항을 반영하는 데에 어려움이 있을 수 있다.
    • 변경 요청이 발생할 경우, 이를 반영하기 위해서는 모든 단계를 다시 진행해야 할 수 있다.
    • 프로젝트의 방향성을 변경하기 어렵다.

 

사전 준비 단계

사용자 요구사항 정의서가 가장 먼저 작성

석, 설계, 구현, 시험 단계는 스프린트 실행 단계로 분류

요구사항 정의서가 작성되면 해당 문서를 기준으로 개발자 테스트 체크리스트를 작성하고,

각 항목을 Github Project Kanban의 이슈로 등록한다.

이때 등록된 이슈들은 모두 백로그에 위치한다.

요구사항 정의서에 명시된 항목 이외에도 배포 환경 구성 등 기능 외의 작업도 이슈로 생성해 추가 해야 한다.

 

백로그(Backlog)? 소프트웨어 개발 프로세스에서 사용되는 용어로, 아직 완료되지 않은 작업들의 목록을 말합니다. 소프트웨어 개발에서는 개발할 기능, 작업, 수정사항 또는 개선사항 등을 명시하고, 이를 우선순위에 따라 나열하여 백로그로 관리

GitHub Milestone 활용

마일스톤은 일정 기간 동안의 목표이다.

GitHub에서 마일스톤을 스프린트의 주기 단위로 설정 한다면 스프린트와 동등한 역할 할수 있다.

 

이슈 등록

등록된 이슈는 해당 프로젝트의 백로그에 위치

  1. 프로젝트 화면에서 ‘+’ 를 누른다.
  2. 백로그 상태 추가 후 드래그 앤 드랍으로 맨 왼쪽으로 이동 후 사전에 등록된 모든 이슈를 추가한다.

스프린트 실행 단계

프로젝트 개발 단계 중 분석, 설계, 구현, 시험 단계를 스프린트 단위로 실시

시험 단계는 개발자 테스트까지만 진행하며 테스트 한 결과는 개발자 테스트 체크리스트에 기록한다.

 

이슈 선정

선순위가 높은 이슈들 부터 백로그에서 선택하여 할 일 탭으로 이동한다.

마일스톤과 담당자를 각 이슈에 지정

 

종료

스프린트가 종료 되면 해결된 이슈와 남은 이슈를 파악 합니다. 만일, 해당 스프린트 기간에 완료 되지 못한 이슈가 있다면 해당 이슈는 자연 스럽게 다음 스프린트로 이관

 

제출물

스프린트가 종료되기 전에 개발 완료된 각 이슈의 테스트가 이루어져야 한다.

테스트를 수행한 결과를 개발자 테스트 체크리스트에 정리하여 제출한다.

이렇게 제출된 개발자 테스트 체크리스트를 통해 스프린트의 진척 상황을 확인 할수있다.

 

회고

스프린트 회고에서는 팀원들이 스프린트 동안 경험한 문제점과 개선점, 다음 스프린트에서 반영해야 할 내용을 함께 논의한다.

해당 스프린트가 프로젝트의 마지막 스프린트라면 개선할 부분 도출은 생략하고 대신 프로젝트 전반에 대한 경험을 공유

한다.

 

타임라인

Agile 방식으로 프로젝트 진행 시 단계 별 해야 할 일을 정리