중간고사 05~08 (제품 백로그, SRS 소프트웨어 요구 명세, SoC 관심사 분리, 모듈성)

Mt.Hwang 2024. 4. 19. 00:42

* 제품 백로그    product back log item
로드맵 및 그 요구 사항에서 파생된
개발 팀에서 수행할 우선 순위가 지정된 작업 목록

제품이 요구하는 기능과 우선순위
1. 누가
2. 어떤 문제를 겪고 있는가
3. 문제를 어떻게 해결할 수 있는가
4. 얻게 되거나 기대하는 결과

제품 소유자의 속도에 맞춰 백로그 작업을 하지 않으며
제품 사유자도 개발 팀에게 작업을 푸쉬하지 않는다

작업 수용량이 있으므로
개발 팀은 지속적으로 or 반복적으로
제품 백로그에서 작업을 가져온다

팀의 로드맵과 요구 사항으로
제품 백로그의 토대를 마련한다

백로그 그루밍
백로그에 대한 정기적인 검토

백로그가 커지면
제품 소유자는 백로그를 단기 및 장기적 항목으로
그룹화해야 한다
단 대략적으로, 막연하게 해야 한다
1. 장기 마스터 백로그
2. 단기 실행 백로그 (스프린트 백로그)

제품 소유자와 개발 팀간의 연결고리 역할
1. 고객 피드백
2. 추정치 조정
3. 새로운 요구 사항

백로그 방법
1. MoSCoW 방법
2. RICE 방법

MoSCoW
백로그를 크게 4가지로 구분해서 우선순위를 정리
1. Must have
2. Should have
3. Could have
4. Won't have

Must have
서비스 운영에서
이 기능을 빼고는 온전한 서비스라고 생각하기 어려운 기준

Should have
당장 적용하지 않아도 서비스에 영향이 없는 기능 중
우선순위가 높은 기준

Could have
서비스 운영에 전혀 영향이 없는 기준 중
우선순위가 낮은 기준

Won't have
서비스를 운영하는 데 있어서 전혀 영향이 없고
우선순위가 가장 낮은 기준
중요도가 떨어지고
적용했을 때 효과도 아주 미미한 수준의 기능

RICE 방법
백로그에 RICE라는 4가지 항목을 적용해서
점수를 도출함으로써 우선 순위를 적용
1. Reach
2. Impact
3. Confidence
4. Effor

결과 = R * I * C/E
산출한 RICE 점수가 클수록 우선순위가 높다

Reach
개발된 기능이 특정 기간 동안에
얼마나 많은 사용자가 사용할 수 있는가
1. 일별 활성 사용자  DAU  Daily Active Users
2. 월별 활성 사용자  MAU  Monthly Active Users
같은 수치로 평가 가능

Impact
해당 기능을 사용할 때 얼마나 큰 영향을 받는가
명확한 기준을 수립할 수 없고
측정하기에 따라 다르다
5단계로 구분하여 상대적인 점수를 부여
1. 효과가 매우 큼
2. 효과가 큼
3. 효과가 중간
4. 효과가 낮음
5. 효과가 매우 낮음

Confidence
개발할 기능이 성공할지에 관해 가지는 확신의 정도
크게 3단계로 구분하여 점수를 적용한다
1. 높은 신뢰도  100%
2. 중간 신뢰도  80%
3. 낮은 신뢰도  50%

Effort
개발 과정에서 소요되는 시간 or 인력에 대한 기준
4단계 점수를 적용할 수 있다
1. 매우 큰 수준의 노력  4점
2. 큰 수준의 노력  3점
3. 중간 수준의 노력  2점
4. 적은 수준의 노력  1점

* 소프트웨어 요구 명세  SRS (System Requirements Specification)
시스템 요구 사항 문서
개발될 소프트웨어 시스템의 설명

소프트웨어의 종합 설계도
프로젝트의 전체적인 그림을 제공
기획, 분석, 설계, 구현, 시험에 도움

고객 or 개발자에게 중요한 모든 별도의 품질 특성을 설명
명확하고 확인 가능한 특성들

소프트웨어의 요구 사항을 분석하고 정의하는 단계에서
작성되는 최종 산출물

소프트웨어가 수행해야 할
모든 기능과 제약 조건 등이 기술돼어 있음

소프트웨어 개발과 테스트의
완료 승인에 대한 기준으로서 사용

절대적인 기준이 존재하지 않는다

SRS 구성 예
1. 목적
  (1) 정의
  (2) 배경
  (3) 시스템 개요
2. 전반적인 설명
  (1) 제품의 관점
   a. 시스템 인터페이스
   b. 사용자 인터페이스
   c. 하드웨어 인터페이스
   d. 소프트웨어 인터페이스
   e. 통신 인터페이스
   f. 메모리 제약
  (2) 디자인 제약
   a. 운영
   b. 사이트 적응 요구
  (3) 제품 기능
  (4) 사용자 특징
  (5) 제약, 추측, 의존성
3. 시스템 요구
  (1) 외부 인터페이스 요구
  (2) 기능 요구
  (3) 성능 요구
  (4) 논리 데이터베이스 요구
  (5) 소프트웨어 시스템 속성
   a. 신뢰성
   b. 가용성
   c. 보안
   d. 유지보수성
   e. 이식성
  (6) 기능 요구
   a. 기능 분리
   b. 기능 설명
   c. 제어 설명
  (7) 환경 특징
   a. 하드웨어
   b. 주변 기기
   c. 사람

SRS 구성
1. 소개
  (1) 목적
  (2) 문서 규칙
  (3) 대상 독자
  (4) 읽는 방법
  (5) 프로젝트 범위
2. 전체 설명
  (1) 제품 기능
  (2) 사용자 계층과 특징
  (3) 운영 환경
  (4) 설계 및 구현 제약사항
  (5) 사용자 문서
3. 시스템 특징
  (1) 시스템 특징
  (2) 기능 요구사항
4. 외부 인터페이스 요구사항
  (1) 사용자 인터페이스
  (2) 하드웨어 인터페이스
  (3) 소프트웨어 인터페이스
5. 기능 이외의 요구사항
  (1) 성능 요구사항
  (2) 보안 요구사항
  (3) 소프트웨어 품질 특성

* 관심사 분리   SoC   Separation of Concerns
컴퓨터 프로그램을 구별된 부분으로 분리시키는 디자인 원칙
추상화의 일종

소프트웨어의 구성 요소를
서로 다른 책임 영역으로 나누는 원칙

시스템 내부에서 질서를 달성하기 위해
소프트웨어 요소의 상관관계와 설계를 적용

관심사
컴퓨터 프로그램 코드에 영향을 미치는
정보의 집합

모듈러 프로그램
SoC를 구현하는 프로그램

자유도를 챙길 수 있다
1. 코드의 단순화
2. 유지보수
3. 독립적인 개발
4. 업그레이드
5. 모듈 재사용

SoC 법칙
시스템 요소가 단일 목적이고 배타성을 가져야 한다
시스템 요소는 다른 요소와 책임을 공유하면 안 된다

가능한 모든 것들을 단순하게 만들어라

불필요한 복제를 제거
복잡도를 관리

1. 수평적 분리
2. 수직적 분리

수평적 분리
동일한 역할을 수행하는 기능의 논리적 레이어 단위로
앱을 분리

수직적 분리
전체 관점에서 기능을 분리

비즈니스 로직이 섞이지 않게 할 수 있다

비즈니스 로직
인터페이스와 관련된
비즈니스 규칙 or 일련의 처리 과정
사용자의 입력에 따라
데이터를 처리, 조직, 작업 수행

* 모듈성   modularity
분할이라는 기법을 이용하여
모듈을 활용한 활동의 기반을 만드는 활동

함수처럼 코드를 묶어 놓은 덩어리

컴포넌트가 분리되고 재결합될 수 있는 정도

소프트웨어 패키지를
논리 단위로 분할하는 것

모듈
큰 체계의 구성 요소로
다른 구성 요소와 독립적으로 운영된다
본체에 대해 독립된 하위 단위
복잡한 구조를 만드는 데 쓰이는
각각의 표준화한 부품이나 독립적인 단위

컴포넌트   Component
여러 함수들을 모아
하나의 특정한 기능을 수행할 수 있도록 구성한
작은 기능적 단위

통합성과 상반되는 개념

모듈성이 높다는 것은
시스템의 기능과 구조요소가
최대한 1대1로 대응하고
요소 간의 의존성을 최소화시키는 것

모듈성이 높다는 것은
기능적 응집성을 높이고
모듈 간의 의존성을 낮추는 것