요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지 보수 단계로 이루어 지는 개방 방법론이며
선행된 단계가 완료 되어야 다음단계로 넘어가는 순차적 개발 방법론을 말함.
각 단계는 윗단계로 거슬러 올라 갈 수 없으므로 각 단계는 명확히 한 후 다음단계로 넘어야가 함( 실제 업무에서는 거슬러올라 가는 경우도 있음 )
또한 각 단계에서 나와야 할 산출물 들이 있지만 필요에 따라 생략 될 수도 있다,
이하 빨간색으로 작성된 부분은 개인적인 생각이 들어간 부분이라 아니라고 생각 되는 부분이 있으시면 감사하겠습니다.
1. 요구사항 분석 (Requirement Analysis)
클라이언트와 협의를 통해 시스템에 필요한 기능들을 문서화 하는것을 말함
해당 단계에서 나오는 산출물은 아래와 같음.
* 요구사항 명세서(Software Requirement Spectification , SRS )
- 시스템의 구현시에 필요한 기능적/비기능적 요구사항을 명시한 문서
- * 기능적 요구사항 이란 요구사항에 따라서 실제 시스템에서 구현 해야하는 요구 사항을 정의한것을 말함
- * 비 기능적 요구사항 이란 말 그대로 기능에 포함되지 않는 요구사항 등을 말함 ex) 하드웨어 스펙 , 서버 이중화 처리시간 데이터 보관 주기 등
( 생략되면 안되는 문서라고 생각이 되고 , 실제로 클라이언트의 요구가 추상적인 경우가 많기 때문에 구체적인 정리가 필요한 문서라고 생각한다. )
* 요구사항 추적 매트릭스 (Requrement Traceablity Matrix, RTM)
- 각 요구사항의 출처와 시스템의 어느 부분에 반영 되었는지, 개발 사이클 전반에 걸처 얼마나 이행이 되었는지 추적
개발보단 프로젝트 관리측면에서 필요한 문서였던것 같다.
2. 시스템 설계 단계 (System Design)
전체 시스템의 구조를 정의하고, 구현을 위한 설계도를 작성하는 단계를 말함.
해당 단계에서 나와야 할 산출물을 아래와 같음.
* 시스템 설계서(System Design Document , SDD)
- 시스템의 전체적인 구조와 아키텍쳐를 정의한 문서,
UML를 통한 다이어그램 형태로 그려지며, 크게 구조 다이어그램 , 행위 다이어그램 으로 나뉜다.
- 구조 다이어그램 ( Structural Diagrams ) : 시스템의 정적인 구조를 시각적으로 표현한 다이어 그램을 말함 , 이하 설명할 다이어그램들은 구조적인 관점에서 대상만 다를뿐 관계나 의존성을 표현 한다는 목적은 같다고 볼 수 있다.
1. 패키지 다이어그램 ( Package Diagram ) :
- 시스템의 패키지 간의 관계를 표현, 패키지 내의 구성요소( 클래스나 인터페이스)등도 간접적으로 이해 할 수 있도록 도움을 준다.
- 관련된 클래스, 인터페이스 들을 그룹화 하여 논리적인 단위로 묶은 패키지(package) 와 패키지간의 관계를 나타내는 의존 성 (Dependency) 으로 구성된다
2. 컴포넌트 다이어그램 ( Component Diagram) :
- 시스템의 컴포넌트 간의 관계를 표현
- 시스템의 모듈화 된 부분으로, 실행 가능한 코드의 단위를 나타내는 컴포넌트( Coponent ), 컴포넌트가 제공하거나 사용하는 기능의 집합의 의미 하는 인터페이스(Interface), 컴포넌트 간의 통신 경로를 나타내는 연결( Connector ),컴포넌트와 외부 시스템 간의 입출력 지점을 나타내는 포트( Port ), 컴포넌트가 배치될 물리적 환경이나 실행 플랫폼을 나타내는 노드(Node)로 구성이 된다.
3. 클래스 다이어그램( Class Diagram) :
- 시스템의 클래스와 클래스 간의 관계를 표현
4. 객체 다이어그램 ( Object Diagram) :
- 클래스 다이어그램의 인스턴스를 나타내며, 특정 시점의 객체들의 관계를 표현.
5. 배치 다이어그램 ( Deployment Diagram ) :
- 소프트웨어 시스템의 물리적 배치와 각 구성요소간에 관계를 시각적으로 표현
- 하드웨어 장치나 가상 머신을 나타내는 노드( node ) 노드에서 싱행되는 소프트웨어 구성요소를 나타내는 배치 아티팩트(
Deployment Artifact) , 노드간의 통신을 나타내는 연결 ( Connection ), 노드와 아티팩트 간의 상호작용을 나타내는
인터페이스 ( interface )로 구성된다.
1,2,3,4 다이어그램은 서로 낮은 숫자로 갈수록 좀더 높은 추상화를 제공하는 다이어그램이지만
5번에서 설명한 배치 다이어그램은 물리적 구현과 관련된 구조를 나타내므로 조금 다른 관점에서 보는게 좋을것 같다.
- 행위 다이어그램 ( Behavioral Diagrams ) : 시스템의 동적인 측면, 행위 및 상호 작용을 시각적으로 표현한 다이어그램
1. 유스케이스 다이어그램 ( Usecase Diagram ) :
- 시스템의 기능 및 사용자의 상호작용( 즉 현실의 동작을 의미 )을 시각적으로 표현
- 시스템 외부에서 시스템과 상호작용하는 주체( 사람 및 조직 또는 외부 시스템 )를 나타내는 액터(Actor), 시스템이 액터에게 제공해야 하는 특정 기능이나 서비스를 나타내는 유스케이스( Use Case), 유스케이스와 액터간의 상호작용이 이루어지는 시스템 경계를 나타내는 ( 즉 시스템이 제공하는 기능의 범위를 나타내는 기능의 범위) 시스템 경계( System Boundary ), 액터와 유스케이스 또는 유스케이스 간의 관계를 나타내는 관계( Relationship )으로 구성된다.
* 액터는 시스템의 주요 기능을 이용하거나 직접적인 상호작용을 하는 주요 액터( Primary Actor )와 시스템의 기능을 지원하는 역할을 하는 보조 액터( Secondary Actor) 로 나뉜다.
* 관계에서 여러가지 유형이 있는데 액터가 특정 유스케이스의 사용을 나타내는 연관 관계( Association ), 하나의 유스케이스가 다른 유스케이스를 반드시 포함하는 포함 관계( Include ), 특정 조건이 만족되었을때 유스케이스의 기능이 확장되는 확장 관계( Extend), 부모 자식 관계로 , 하위 유스케이스가 상위 유스케이스를 상속하거나, 확장하는 일반화( Generalization ) 관계가 있다.
개발이 완료 된 후에 작성하는 케이스가 있었었는데. 산출물을 작성해야 했기 때문에 그런것 같다.
2. 시퀀스 다이어그램 ( Sequence Diagram ) :
- 객체간의 상호작용을 시간의 순서에 따라 표현한다. ex) 예를들어 노드와 노드간의 통신흐름을 시간적 순서에 따라 어떤 메시지를 주
고 받을지를 표현
- 액터( Actor ), 시스템 내부에서 메시지를 주고받는 주체인 객체( Object ), 객체나 액터의 수명을 나타내는 생명선( Lifeline ), 특정 객체가 활성화된 상태를 나타내는 활성( Activation ), 객체간의 상호작용을 나타내는 메시지 (Message), 시퀀스 다이어그램의 특정 영역을 묶어서 그룹화 화거나 조건문 반복문, 선택사항들을 나타내가 위한 프레임( Frame ), 조건문을 나타내는 연산자인 조건/제어 연산자(Guard), 경계선 및 기타 구성요소로 시스템 내부와 외부를 구분하거나 경계선( Boundary ), 주석이나 설명을 추가하기 위해 사용되는 노트( Note )가 있다.
메시지 송수신 흐름을 작성한다.
3. 커뮤니케이션 다이어그램 ( Communication Diagram ) :
- 객체지향 모델링에서 객체 간의 상호작용을 시각적으로 표현, 주로 유스케이스 다이어그램, 시퀀스 다이어그램 과 같이 사용 된다고 한다.
- 시스템의 특정 역할을 수행하는 객체( Object )와 객체간의 상호작용을 나타내는 링크( Link ), 링크와 같이 상호 작용을 나타내지만 행동과 번호로써 순서를 나타내는 메시지( Message ) , 객체와 객체간의 관계를 나타내는 연관 관계( Association ) , 객체간에 메시지가 언제 어떻게 전달되는지 명확히 하여 동작방식을 이해 할 수 있게 해주는 상호작용( Interaction )로 구성된다.
4. 활동 다이어그램 ( Activity Diagram ) :
- 시스템의 특정 프로세스나 작업 흐름을 시각적으로 표현
5. 상태 다이어그램 (State Diagram ):
6. 상호작용 다이어그램 ( Interaction Diagram ) :
7. 타이밍 다이어그램 ( Timming Diagram )
예전에 Netty 서버를 개발 할때 프로토콜 명세서와 함께 시퀀스 다이어 그램을 받은적이 있었는데,
이 부분은 동작 흐름을 파악 할 수 있어다는 관점에서 꽤나 유용 했다..
다이어그램을 그린것은 전체적인 시스템 구조나 흐름을 파악하기위해서 괜찮은 방법이라고 생각이 든다.
하지만 아직까지 실제로 접해본 시퀀스 ,유스케이스 다이어그램 외에 다른 종류의 다이어그램들은 접해본적이 없어 개발하는데 있어서
어느 부분에서 얼마나 유효한지는 모르겠다.
아마 크게 필요가 없다고 판단되어 작성되지 않았거나 내 포지션 상 알 필요가 없다고 생각해서 받아보지 못한것 일지도 모르겠다.
* 데이터베이스 설계서 ( Database Disign Document )
- 데이터베이스의 구조를 정의하는 단계를 말함 , ERD( Entity-Relationship Diagram)를 포함 (dbeaver나 pgmodeler 또는 sql workbench등으로 그려진다.)
* UI/UX 설계서
- 사용자가 이용하게 될 소프트웨어의 화면을 정의하는 문서를 말함,
화면 설계와 디자인 관련해서 Figma로 많이 작성됨 .
현재 진행하고 있는 프로젝트와 같은 프로젝트 경험이 많고 비즈니스에 대한 이해도가 높다면 화면설계 없이도 큰 요구사항의 변화 없는 개발이 가능 하겠지만 .. 그게 아니라면 목적을 달성 할때까지 ( 개발 -> 검토 -> 요구사항 변화 )를 거친다.. 개발하고 해당 검토 및 협의를 거치고 나온 내용 다시 적용하여 개발하고.. 개발자가 만능은 아니기에 비 효율적인 방법이라고 생각이 든다..
* 모듈 설계 명세서
- 각 모듈의 역할과 책임을 정의한 문서
3. 구현
4. 검증 및 테스트( QA )
5. 유지 보수