카테고리 없음

시스템 설계의 흐름, 설계서의 구성

개발자 두더지 2023. 6. 18. 20:02
728x90

일본의 한 블로그 글을 번역한 포스트입니다. 오역 및 의역, 직역이 있을 수 있으며 틀린 내용은 지적해주시면 감사하겠습니다.

 

 상류 공정은 "요건 정의" → " 외부 설계" → "내부 설계"의 흐름에 따른다.

 

요건 정의


 개발하는 시스템에서 원해지는 기능등의 요건을 정리하는 것. 예를 들어, 다음과 같은 것들이 있다.

  • "패스워드 인증", "데이터 베이스 내의 검색"등의 기능 요건
  • "입력 데이터", "출력 데이터"의 사양
  • "보수성", "조작성" 등의 비기능 요건
  • 작업 플로우

 RFP(제안의뢰서) 작성이나 사전 조사등을 하여 정말 필요한 요건을 제대로 정밀하게 조사해간다. 여기서 정리한 내용을 바탕으로 개발을 진행하기 위해 모든 케이스를 생각하여 간과한 사양에 의한 변경 횟수를 줄일 수 있다.

 요건정의 시에 다루는 것은 반드시 보증해야만 하는 항목이 중심이며 UI 디자인 등의 개발자쪽이 결정해도 무방한 부분은 외부정의에서 실시한다.

 

 

요건정의서


 요건 정의의 결과를 문서화한 것을 요건 정의서라고 부른다. 적어도 아래의 다섯 개는 항목에 있어야한다고 생각한다.

  • 시스템의 개요
    • 어떠한 시스템인가
    • 왜 이 시스템이 필요한가
    • 이 시스템의 목표는 무엇인가
  • 시스템의 구성도
    • 시스셈의 개념도
    • 시스템의 업무 플로우
    • 유스케이스도
  • 기능 요건
    • 시스템의 기능 목록
    • 각 기능의 상세내용
  • 입출력 요건
    • 입력 데이터 목록
    • 각 입력 데이터의 상세(데이터 항목, 파일 형식등)
    • 출력 데이터 목록
    • 각 출력 데이터의 상세(입력 데이터와 동일)
  • 비기능 요건
    • 요구되는 보안
    • 요구되는 품질, 성능
  • 그 외
    • 대략적인 스케줄
    • 스테이크 홀더(이해 관계자) 관계도

 

 

외부 설계


요건 정의서에 따른 시스템의 구성을 구체화하여 설계해간다. 클라이언트쪽에서도 공유하는 요건 정의서와 달리 "기본 설계서" (=외부 설계서)는 개발자 시점에서 기재해나간다. 그러나 기본 사양서를 리뷰할 때는 클라이언트도 참가할 때도 있는 듯 하다.

 "외부 설계"는 주로 아래의 세 가지로 분류된다.

 

방식 설계(=아키텍처 설계)

 무엇을 사용하여, 얼마나 걸려서, 어떤 시스템을 제작할 것인가를 순서대로 설계해나가는 이미지이다. 

  • 무엇을 사용하여
    • 개발 방침을 결정해나간다. 구체적으로는 하드웨어, 소프트웨어 구성등
    • 대규모 개발의 경우, 사용 언어나 플랫폼은 지정한다.
  • 얼마나 걸려서
    • 개발 체제
    • 개발 스케줄
    • 프로젝트 관리 툴
  • 어떤 시스템을
    • 시스템 구성도

 

기능 설계

 시스템을 모듈 단위로 분할해 각 모듈의 외부 사양을 설계한다. UML도를 활용하는 경우가 많은 단계이다. 각 모듈의 상세 설계는 뒤에서 설명할 "내부 설계"에서 한다.

  • 화면 이동도
  • 화면 레이아웃(UI) 설계도
  • 시나리오
  • 비즈니스/로직
  • 기능 목록표
  • 데이터베이스 설계
    • ER도
    • 테이블 정의서

 

기타 설계

 그 외에도 보안 설계, 운용 설계, 테스트 설계등을 한다.

 

 

기본 설계도


외부 설계에서 결정한 것을 정리하여 문장화한 것이 기본 설계서이다.

  • 시스템 개요
    • 시나리오
    • 비즈니스 로직
  • 시스템의 구성
    • 시스템 구성도
    • 작업의 흐름, 액티비티도
    • 하드웨어, 소프트웨어 구성도
    • 네트워크 구성도
  • 기능 목록
  • 데이터 베이스 사양
    • ER도
    • 테이블 정의서
  • UI설계
    • 화면 이동도
    • 화면 레이아웃 설계도
  • 그 외
    • 개발 체제
    • 개발 스케줄
    • 프로젝트 관리 툴

 

 

내부 설계


 외부 설계에서는 "시스템 전체의 구성", "개발 방침의 결정"을 메인으로 설계했지만, 내부 설계에서는 "어떤 모듈을 구현하여 시스템을 구성하는가"에 주목하여 설계한다. 각 모듈의 구성, 데이터 플로우를 주로 기재한다.

 외부 설계에서는 리뷰어에 클라이언트가 포함되어 있었지만, 내부 설계에서는 SE, PG만 관련되어 있다. PG만을 대상으로한 자료라고 생각해도 문제없다.

 실제로는 내부 설계없이 코딩을 하는 것이 효율적이다라고 생각하는 사람이 많다.

 

내부 설계서

 "상세 설계서"라고 불린다. 내부 설계서는 1장의 자료로 정리하는 것이 아닌, 각 모듈의 사양서를 한 장씩 작성하는 경우가 많은듯하다.

  • 기능 분할 설명
    • 클래스도
  • 데이터 플로우
    • DFD도
  • 모듈 상세
    • 모듈명
    • 역할
    • 인수, 반환값
    • 처리 개요
    • 참고

 

 

구현 시작


 내부 설계가 끝나면 드디어 PG에 의한 프로그래밍이 시작된다. 구현이 끝나면 외부 설계에서 작성했던 "테스트 사양서"에 따라 단체 테스트 > 종합 테스트를 실시한다.


참고자료

https://qiita.com/chocode/items/fd51dd8f561e2a0fbd70

728x90