A-RMS Document
1. 배경
A-RMS는 ALM 시스템(Atlassian Jira, Redmine 등)과 연계하여 제품(Service)(기반의 요구사항( Issue)을 공유할 수 있는 RMS (Requirement Management System)입니다.
현존하는 이슈 기반 요구사항( Issue) 관리 시스템은 없으므로, A-RMS를 만들어서 제품(Service)별 요구사항( Issue)을 관리 및 전파하여 추적성을 확보하고 ALM 시스템과 통합하여 제품(Service)기반 프로젝트 진척도를 파악 할 수 있는 가시성을 제공하는 시스템 입니다.
제품(Service)별 요구사항( Issue ) 기반 진척상황 파악 : 제품(Service) 진척 상황을 쉽게 파악할 수 있는 시스템이 부재하여, 프로젝트 참여자들은 실시간으로 제품의 진행 상황을 파악하기 어려운 점이 있습니다.
요구사항( Issue) 이력 관리 부재: 요구사항( Issue)의 등록, 채택, 거절 및 변경 이력을 관리하지 않음으로써, 프로젝트의 진행 과정에서 어떤 변화가 있었는지 추적하기 어려운 상황이 발생합니다.
제품(Service)별 요구사항과 ALM Project Issue간 매핑 어려움: 제품(Service) 와 요구사항( Issue) 간의 매핑이 복잡하여, 프로젝트 기반의 작업 플로우를 제품(Service) 기반으로 확장하기 어렵습니다. 이로 인해 요구사항과 실제 제품(Service) 간의 일치 여부 파악이 어려워지는 점이 있습니다. 이를 파악하기 쉽게 해결하고자 합니다.
요구사항( Issue) 변경 권한 관리 필요성: 요구사항( Issue) 변경에 대한 권한 관리가 필요하며, 이를 통해 요구사항( Issue)의 변경이 비효율적으로 이루어지거나 예기치 못한 변경이 발생하는 상황을 방지하고자 합니다.
개발 진척 상황 보고의 어려움: 개발 진척 상황을 문서화하여 개발 팀장에게 보고하는 과정이 복잡하고 시간 소모적으로 진행되며, 보고 자료의 작성에 상당한 시간과 노력이 소요됩니다.
SRS에 적시되는 요구사항( Issue)의 작성자: 현재 SRS에 기재되는 요구사항( Issue)은 주로 개발자가 작성하고 있습니다. 이는 개발자의 기술적인 시각으로부터의 관점이 강조될 수 있으며, 고객이나 업무 담당자의 요구와 일치하지 않을 수 있습니다
요구사항( Issue)의 발의자: 요구사항( Issue)의 발의는 고객 또는 업무 담당자와 직접적으로 상호작용하는 사람들이 주로 수행하고 있습니다. 또한 기획자나 내부 개발자 역시 요구사항( Issue)을 발의하는데 관여하고 있습니다. 이로 인해 다양한 역할들 간의 의사소통 부재와 일관성의 결여가 문제로 작용할 수 있습니다.
요구사항( Issue)의 발의자: 요구사항( Issue)의 발의는 고객 또는 업무 담당자와 직접적으로 상호작용하는 사람들이 주로 수행하고 있습니다. 또한 기획자나 내부 개발자 역시 요구사항( Issue)을 발의하는데 관여하고 있습니다. 이로 인해 다양한 역할들 간의 의사소통 부재와 일관성의 결여가 문제로 작용할 수 있습니다.
요구사항( Issue)에 대한 이력 미관리: 현재 요구사항( Issue) 변경에 대한 이력은 SRS에 기록됨에도 불구하고, 변경 사항의 추적성이 부족합니다. 변경 사항의 최종 형상만 확인되며, 중간 과정의 변경 및 이력이 적절히 관리되지 않습니다.
요구사항( Issue) 충족 여부 확인의 어려움: 요구사항( Issue)을 발의한 사람들이 제시한 대로 제품(Service) 개발되고 있는지 확인하는 것이 어렵습니다. 개발 팀장을 통해 요구사항( Issue)의 해석과 개발 진행 상황을 전달받기 때문에, 요구사항( Issue)의 충족 여부를 정확하게 확인하기 어려운 상황이 발생합니다.
이러한 문제점들은 요구사항( Issue) 관리 및 프로젝트 진행 상황 파악에 대한 투명성과 효율성을 제한하는 요인으로 작용하고 있습니다. 이러한 배경을 통해 새로운 요구사항( Issue) 관리 시스템의 필요성과 중요성을 높이고자 합니다.
2. 내용
2.1 경쟁 제품 조사 및 비교
Atlassian 제품군 요구사항 관리 툴 조사
Atlassain 제품과 connector 를 제공하는 솔루션으로 아래의 링크는 요구사항에 관련한 Atlassian 의 자라 사용방법에 관련된 내용입니다.
경쟁 제품 : Jira Software Support
| 솔루션 명 | WEB 링크 |
|---|---|
| Modern Requirements | Azure Requirements Management Tools |
| Visure | visuresolution |
| reqtest | Reqtest |
| doors | jazz |
| jama | jamasoftware |
- 현재 5가지 종류의 RMS는 Atlassain과 분리된 채 독자적 제품을 구성하는 경우입니다.
- 위의 제품들은 ALM의 라이프 사이클에 녹아들지 못하는 형태로 구성되어, 연관성 및 관리성, 일관성에 문제점이 있습니다.
- 유료로 사용을 하며 가격이 비싸다는 점이 있습니다
- 아틀라시안 제품군과는 전혀 다른 UI 및 구성을 가지고 있으며 활용성 측면에서 낮은 상태입니다.
- 솔루션에서는 제품 기준 (이슈 기반) 진척사항을 확인하는 DashBoard는 제공하지 않습니다.
2.2 추진과제
ARMS 도식화 모형
※ ARMS 적용 후 ALM단계별 설명
| 구분 | 단계 | 설명 |
|---|---|---|
| 1 | 요구 사항 관리 | 요구사항( Issue)을 수집하고 정립 프로젝트 별 이슈 기반 추적 메트릭스를 통한 제품의 가시성 ( Dashboard ) 관리 |
| 2 | 이슈 관리 | 프로젝트 별 이슈 기반 추적 메트릭스를 통한 제품의 가시성 ( Dashboard ) 관리 |
| 3 | 문서 관리 | 요구사항( Issue) 기반 이슈 생성 및 관리(ex : 요구사항( Issue) 정립부터 코드 개발에 이르기까지의 전 과정 이슈 추적 관리) |
| 4 | 문서 관리 | 프로젝트 문서를 온라인 화 및 관리 지식 저장소의 역할 |
| 5 | CI/CD 관리 | 코드를빌드하고(자동화된UnitTest, 정적분석및자동화된프로젝트문서산출) 아티팩트 생성 |
| 6 | 릴리즈 관리 | 아티팩트 공유 및 배포 레파지토리 관리※ ARMS 적용 후 ALM (ROSE) 프로토타입 |
1. 제품 이해 관계자들이 요구사항( Issue)을 쉽고, 단순하게 올릴 수 있습니다. (누가, 언제, 어떤 변화 이력이 있는지에 관한 시스템을 지원)
2. WORKS(jira)에 특정 label을 달고 자동으로 요구사항( Issue) 이슈가 등록되며, 선정된 요구사항( Issue)을 토대로 DOCS(confluence)에 SRS가 기재되어야 합니다.
3. ARMS가 이를 수집하여 현재 상태를 표시합니다
2.3 기술의 구성A-RMS 시스템 구성도
A-RMS 시스템 설명
1. 사내, 사외에서 요구사항( Issue)을 손쉽게 등록할 수 있도록 Device 의 다양성을 대응할 Frontend Application
2. 다양한 Frontend Application 에 대응하기 위한 표준화된 Backend Application과 표준 통신 프로토콜 ( JSON ) API 처리 시스템
3. 요구사항( Issue)이 등록되는 대상은 제품, Jira 는 제품을 구성하는 프로젝트 ( 1:1 ~ 1:N ) 이므로 두 시스템을 맵핑 할 수 있는 유연한 분류체계 시스템
4. 진척상황(Dashboard)은 실시간 요소가 아니며, Jira 에 추가 부하가 없도록 함
5. Jira 에 등록된 정보(API)를 배치처리하여 데이터를 누적하기 위한 정보 저장 및 검색을 지원하는 색인, 검색엔진 시스템
6. 각역할별권한처리시스템(Rolebase)-LDAP,AD,CROWD 인증 연동
7. 요구사항( Issue) 이력관리시스템(분류체계시스템의서브기능)
8. JIRA 등록 처리 시스템
9. Private Cloud Service 를 위한 Docker 지원 서비스 솔루션 : Kubernetes
A-RMS 기술 요소 특징
추가적인 기술적용의 특징요소는 다음과 같습니다.
1. A-RMS 는 대한민국정부가 인증한 전자정부표준프레임워크 3.6 을 기준한 Framework 를 Backend 로 사용합니다.
2. 누구나 재사용 할 수 있는 아키텍쳐를 적용하고, 확장할 수 있도록 PLE(Product Line Engineering) 기법을 적용
3. Atlassian UI 구성인 Bootstrap + jQuery 및 CSS 를 채택하여 개발 진행 ( Design 요소가 필요 없습니다 )
4. Frontend 어플리케이션과 Backend 어플리케이션을 분리 개발 및 통신 프로토콜을 JSON 표준으로 채택하여 Frontend 개발이 Backend 영향없이 100% 분리하여 병렬 개발 가능합니다.
5. SonarQube 를 활용한 ( CPD, PMD, Checkstyle 등의 코드 퀄리티 측정 ) Sacle A 등급 코드 유지합니다
6. UnitTest Ccoverage 를 핵심인 분류체계 시스템에 한정하여 100%를 달성합니다.
7. 최종 산출 아티팩트를 Docker 로 구성( build automatioin)하고, Kubernetes 를 활용하여 배포 및 서비스 운영을 목표로 합니다.
A-RMS 분류 체계 시스템 제품(Service) – Project mapping
A-RMS 의 특징적 기술요소는 유연한 분류체계가 탑재된 서버사이드 시스템입니다
A-RMS 분류 체계 시스템 - 객체의 구조적 활용 중심의 시스템
- 입력된 요구사항( Issue)이 어느 제품(Service)에 요구하는 것인지. 해당 요구사항( Issue)과 JIRA mapping 정보 분류
- 요구사항( Issue) 의시스템이력관리 (기능확장의유연성)
- 요구사항( Issue) 자체의 구조관리 ( PM 과 기획자의 역할, 채택과 변경등 )
A-RMS(atlassian Requirements Managment System) 는 제품(서비스)관점의 JIRA 전용 RMS입니다. 제품(서비스) 중심으로 Jira Project를 분석하고, 제품(서비스)중심으로 요구사항을 Jira Project에 전파합니다.
3. 활용 방안
3.1 기대 효과
ARMS 적용 후 순기능
- 프로젝트 버전관리에 중요성 대해 인식이 높아질 것이며 릴리즈 날짜를 선정하고, 어떠한 요구사항( Issue)을 적용했는지에 관리를 할 수 있습니다.
- 제품(Service)의 모든 관련자가 요구사항( Issue)을 기반으로 소통할 수 있습니다.
- 상위 관리자는 현재 진행되는 모든 프로젝트의 진행 척도와 개발 진척사항을 확인합니다.
ARMS 적용 후 역할 별 효과
| 구분 | 효과 설명 |
|---|---|
| 고객 면대면 | 고객의 요구사항( Issue) 실시간 채택여부, 개발 진척상황, 제품(Service) 적용 시점 확인 가능 |
| 기획 담당자 | 요구사항( Issue)의 이력 관리 및 분류, 구분, 변경에 대한 개발팀과의 소통 창구 개설 |
| 상위 관리자 | 전체 제품(Service) 개발 진척 상황 모니터링 |
| 개발팀 |
1. 명시된 요구사항( Issue) 을 근거로 이슈 생성 2. 문서 작성 3. 개발 4. 리뷰 5. 코드 분석 6. 빌드 7. 배포 FM Flos |
SRS Document
1. 프로젝트 개요
1.1 목표
이슈 기반 요구사항 관리 시스템을 개발하여, 제품별 요구사항의 생명주기(추가-채택-변경-삭제 ) 및 이력을 관리하며, 이와 함께 ALM 시스템과 통합하여 Business Intelligence를 제공하는, Atlassian 제품군 기반의 Requirement Management System - RMS (for atlassian)시스템을 개발하는 것을 목표로 합니다.
1.2 범위
본 프로젝트 범주는 aRMS 의 인증 및 인가 시스템을 제공합니다.
1.2.1 aRMS → Auth Scope
본 프로젝트 범주는 aRMS 내부의 데이터를 분류하는 시스템을 jsTree framework를 활용하여 관리하는 시스템을 제공합니다.
1.2.2 aRMS → Product and Service Scope
본 프로젝트 범주는 aRMS가 Atlassian 제품군을 대상으로, 요구사항(Requirement)을 기준하여 관리하는 시스템을 제공합니다.
1.2.3 aRMS → Requirement Scope
본 프로젝트 범주는 aRMS가 Atlassian 제품군 및 Java Application을 대상으로, 인스턴스 모니터링을 관리하는 시스템을 제공합니다.
1.2.4 aRMS → Monitoring Scope
1.3 관련 문서
| 구분 | URL |
|---|---|
| Project Charter | ARMS ( Atlassian RMS ) Project Charter |
| SRS ( Software Requirement Specification ) → Business Architecture → 시스템 구성도 → System Architectur | ARMS ( Atlassian RMS ) SRS - Software Requirement Specification |
| SDS ( Software Design Specification ) → Application Architecture → Data Architecture | ARMS ( Atlassian RMS ) SDS - Software Design Specification |
1.4 결과물
| 구분 | 서버타입 | 대수 |
|---|---|---|
| Docker Swarm Base 물리 머신 클러스터링 | 물리 서버 - Docker instance 용 | instance replica 총량에 비례한 서버대수 필요 (cpu, mem) |
| Kubernetes Base 물리 머신 클러스터링 | 물리 서버 - Docker instance 용 | - |
| Docker Swarm Persistence Storage | 물리 서버 - Docker Data 용 | NFS 서버 ( 데이터 서버 분리 ) 1-1 미러링 |
| Web Server - Apache | 가상 Docker | 1 ea ( 웹서버 캐시용도 ) |
| WAS Server - Tomcat | 가상 | 1 ea ( 와스 서버 - java application - ARMS ) 클러스터링 기능 제공 시 ( Enterprise mode 제공 ) |
| Cache Server - Redis Sentinel | 가상 | 3 ea ( 세션 클러스터링 및 큐 용도 ) |
| ElasticSearch | 가상 | 4 ea 클러스터링 ( 검색엔진 : 1 Master - 3 Slave ) |
| ElasticSearch HQ | 가상 | 1 ea ( 검색엔진 관리 툴 ) |
| Kibana | 가상 | 1 ea ( 검색엔진 리포팅 툴 ) |
| Logstash | 가상 | 1 ea ( 클라이언트 데이터 수집기 - 검색엔진 데이터 마이닝 ) |
| ZooKeeper | 가상 | 3 ea ( 서비스 디스커버리 클러스터 ) |
| Kafka | 가상 | 3 ea ( 메세지 큐 클러스터 ) |
| Kafka Manager | 가상 | 1 ea ( 메세지 큐 클러스터 관리 툴 ) |
| APM Server | 가상 | 1 ea ( 클라이언트 성능 데이터 수집기 ) |
| influxDB | 가상 | 1 ea ( 시계열 데이터베이스 ) |
| chronograf | 가상 | 1 ea ( 시계열 데이터베이스 관리 툴 ) |
| grafana | 가상 | 1 ea ( 시계열 데이터베이스 리포트 툴 ) |
| scouter | 가상 | 1 ea ( 클라이언트 성능 데이터 수집기 ) |
| mysql | 가상 | 1 ea ( 데이터베이스 ) 클러스터링 기능 제공시 ( Enterprise mode 제공 ) |
Docker Swarm Infra 설치 스크립트 1종 - Linux base All-in-one Monitoring System 설치 스크립트 1종 - Docker Swarm Infra 기준 yml 파일 1종 aRMS 설치 스크립트 1종 - Docker Swarm Infra 기준 yml 파일 1종 - App server, DB Server, Cache Server 등. aRMS 프로그램 소스 코드 1종 - jsTree Base Java Application
2. 제품(서비스) 조망
2.1 제품(서비스) 구성도
제품(서비스) 조망 구성의 시작은 Business Architecture 입니다.
input은 project charter를 활용하면서, 기본적인 요구사항을 구체화합니다.
구체화된 요구사항에 맞춰서 비지니스 아키텍쳐가 이 요구사항을 대응할 수 있어야 하고, 추상화 단계는 최상위 레벨인 시스템 수준의 대단위 모듈로 대응 할 수 있어야 합니다.
input인 비지니스 아키텍쳐로 부터, 세부적인 요구사항의 기능을 대응할 시스템 하위 컴포넌트 레벨의 모듈을 구성하고, 해당 모듈의 핵심적인 기능을 기록하도록 합니다.
2.2 제품(서비스) 동작 방식
2.2.1 인증 시스템 모듈 동작 방식
2.2.1.1 통합 계정 관리 시스템
- 통합 계정 관리 시스템은 계정 관리를 목적으로 하는 시스템 입니다.
- 통합 계정 관리 시스템은 로컬 계정 관리 시스템과 연동 계정 관리 시스템을 연동합니다.
- 통합 계정 관리 시스템은 2개의 각 시스템으로부터 계정을 취합하는 기능을 가지게 됩니다. 통합 계정 관리 시스템은 주기적으로 2개의 연동 시스템으로부터 계정을 취합합니다.
- 통합 계정 관리 시스템은 취합된 계정의 CRUD 기능을 제공합니다.
- 통합 계정 관리 시스템은 권한을 부여할 수 있습니다.
- 통합 계정 관리 시스템은 통합 권한 관리 시스템으로부터 권한을 확인하고 추가, 갱신, 삭제, 조회를 할 수 있습니다.
2.2.1.2 통합 권한 관리 시스템
- 통합 권한 관리 시스템은 Tree 형식의 권한 체계를 구성 할 수 있습니다.
- 통합 권한 관리 시스템은 미리 anonymous, user, admin 으로 구분되 있습니다.
- 통합 권한 관리 시스템은 미리 정의된 권한 체계의 하위로 세부 권한을 추가할 수 있습니다.
- 통합 권한 관리 시스템은 미리 정의된 3개의 권한과 동일한 레벨로 권한을 생성할 수는 없습니다.
- 통합 권한 관리 시스템은 미리 정의된 3개의 권한에 대해 URL 패턴이 지정되 있습니다. 통합 권한 관리 시스템은 추가된 세부 권한은 3개의 권한 체계 내부 로직에서 처리합니다.
- 통합 권한 관리 시스템은 통합 계정 관리 시스템과 연동됩니다.
2.2.1.3 로컬 계정 관리 시스템
- 로컬 계정 관리 시스템은 aRMS 내부의 미리 정의된 admin 계정을 관리합니다.
- 로컬 계정 관리 시스템은 admin 이외 자체 계정을 관리합니다. ( 장애 상황 대비 )
- 로컬 계정 관리 시스템은 연동 계정 이외 서비스 계정을 관리하기 위한 목적이 있습니다.
2.2.1.4 연동 계정 관리 시스템
- 연동 계정 관리 시스템은 LDAP, Crowd, 등 계정 통합 관리 시스템과 연동하여 데이터를 로드합니다.
- 연동 계정 관리 시스템은 로드된 데이터를 기계적으로 저장하거나 갱신할 뿐, 사용자에 의한 변경은 처리하지 않습니다.
2.2.1.5 사용자별 맞춤 시스템
- 사용자별 맞춤 시스템은 사용자 권한별 대시보드 시스템을 제공합니다.
- 사용자별 맞춤 시스템은 미리정의된 anonymous, user, admin을 구분하여 대시보드를 제공합니다.
- 사용자별 맞춤 시스템은 anonymous 의 경우 동일한 하나의 대시보드를 통해 정보를 제공합니다.
- 사용자별 맞춤 시스템은 user의 경우 사용자가 정의한 하위 권한 체계 만큼 대시보드를 생성하여 구성할 수 있습니다.
- 사용자별 맞춤 시스템은 admin 을 위한 시스템 관리 대시보드를 제공합니다.
2.2.2 제품(서비스) 관리 시스템 모듈 동작 방식
2.2.2.1 제품(서비스) 관리 시스템
- 제품(서비스) 관리 시스템은 제품(서비스)를 등록하고 관리 할 수 있는 시스템을 제공합니다.
- 제품(서비스) 관리 시스템은 사용자에 의해 Tree 로 관리됩니다 ( CRUD ) 및 복사 기능 제공을 합니다.
2.2.2.2 제품(서비스) ALM 간 Mapping 시스템
- 제품(서비스) ALM Mapping 시스템은 제품(서비스)에서 사용할 Jira 의 정보를 관리 할 수 있습니다.
- 제품(서비스) ALM Mapping 시스템은 제품(서비스)와 Jira 간 Project mapping 을 관리 할 수 있습니다.
- 제품(서비스) ALM Mapping 시스템은 Jira 정보 적용시 사용할 계정 정보를 관리 할 수 있습니다.
- 제품(서비스) ALM Mapping 시스템은 연동된 Jira 정보로부터 연계된 VCS, Build 등의 시스템 정보를 관리 할 수 있습니다.
- 제품(서비스) ALM Mapping 시스템은 Issue track, wiki, vsc, analysis, build, deploy 의 연계 시스템을 관리 할 수 있습니다. 그러므로 제품(서비스) 별로 연관된 시스템의 정보를 수집하여 통계-수치화 할 수 있습니다.
- 제품(서비스) 별로 등록된 요구사항에 대한 필터를 적용하여 정보를 수집- 통계 및 수치화가 가능합니다.
2.2.2.3 제품(서비스) - 요구사항 - Jira Issue 맵핑 관리 시스템
- 요구사항 Jira Isuue 맵핑 관리 시스템은 요구사항 이슈를 연계된 Jira project 에 등록하고 관리하는 시스템입니다.
- 요구사항 Jira Isuue 맵핑 관리 시스템은 연계된 Jira project 에 요구사항 타입의 이슈를 추가합니다.
- 요구사항 Jira Isuue 맵핑 관리 시스템은 이후 요구사항 승인 및 연동 시스템에 의하여 처리 액션을 실행합니다.
2.2.2.4 제품(서비스) - 요구사항 - Confluence 맵핑 관리 시스템
- 요구사항 Confluence 맵핑 관리 시스템은 요구사항 이슈가 관리될 때, 등록된 confluence 의 space에 template 문서를 등록하고 연계합니다.
- 요구사항 Confluence 맵핑 관리 시스템은 template 문서를 등록하고 연계시 요구사항 승인 및 연동 시스템의해 처리됩니다.
2.2.2.5 제품(서비스) - 요구사항 - Bitbucket 맵핑 관리 시스템
- 요구사항 BitBucket 맵핑 관리 시스템은 Jira 에 등록된 VCS의 정보를 로드하여 표시합니다.
- 요구사항 BitBucket 맵핑 관리 시스템은 VCS 정보를 로드할 때 요구사항 승인 및 연동 시스템처리기를 통해 로드합니다.
2.2.2.6 제품(서비스) - 요구사항 - Sonarqube 맵핑 관리 시스템
- 요구사항 Sonarqube 맵핑 관리 시스템은 Jira 에 등록된 CodeQulity System의 정보를 로드하여 표시합니다.
- 요구사항 Sonarqube 맵핑 관리 시스템은 CodeQulity 정보를 로드할 때 요구사항 승인 및 연동 시스템처리기를 통해 로드 합니다.
2.2.2.7 제품(서비스) - 요구사항 - CI/CD 맵핑 관리 시스템
- 요구사항 Sonarqube 맵핑 관리 시스템은 Jira 에 등록된 CICD System의 정보를 로드하여 표시합니다.
- 요구사항 Sonarqube 맵핑 관리 시스템은 CICD정보를 로드할 때 요구사항 승인 및 연동 시스템처리기를 통해 로드합니다.
2.2.3 요구사항 관리 시스템
2.2.3.1 요구사항 등록 시스템
- 요구사항 등록 시스템은 제품(서비스) 하위에서 관리할 요구사항 타입의 이슈를 동록 할 수 있도록 지원합니다.
- 요구사항 등록 시스템은 제품(서비스) 와 연계된 Jira Project에 등록한 요구사항이 자동으로 등록됩니다.
2.2.3.2 요구사항 리뷰 시스템
- 요구사항 리뷰 시스템은 제품(서비스)에 등록된 요구사항에 대하여 리뷰어를 등록할 수 있도록 합니다.
- 요구사항 리뷰 시스템은 등록된 리뷰어의 리뷰가 완료됬을 때, 연계된 Jira Project 에 요구사항이 등록, 갱신, 삭제 처리 됩니다.
2.2.3.3 요구사항 권한 관리 시스템
- 요구사항 권한 관리 시스템은 조회의 경우 제품(서비스)에 등록된 사용자는 모두 가능합니다.
- 요구사항 권한 관리 시스템은 등록의 경우 제품(서비스)에 등록 권한을 가진 사용자만이 새로운 요구사항을 등록할 수 있습니다.
- 요구사항 권한 관리 시스템은 갱신의 경우 등록 권한을 가진 사용자는 갱신의 권한을 가집니다. ( 등록 = 갱신 )
- 요구사항 권한 관리 시스템은 갱신의 경우 등록된 리뷰어의 일정수준 ( 80% ) 이상의 승인을 받을 경우 가능합니다.
- 요구사항 권한 관리 시스템은 삭제의 경우 삭제 권한을 가진 사용자만 이 요구사항을 삭제 처리 할 수 있습니다.
- 요구사항 권한 관리 시스템은 삭제 처리의 경우 등록된 리뷰어의 과반 (50%)의 승인을 얻을 경우 가능합니다.
2.2.3.4 요구사항 버전 관리 시스템
- 요구사항 버전 관리 시스템은 제품(서비스) 관리 시스템의 하위에 요구사항의 집합을 적용할 버전을 관리하는 시스템입니다.
- 요구사항 버전 관리 시스템은 제품(서비스) 관리 시스템에 연계된 Jira Project 에 의하여 버전을 등록할 수 있습니다.
- 요구사항 버전 관리 시스템은 요구사항 관리 시스템에 의해 승인된 요구사항을 Version 에 맵핑 할 수 있습니다.
2.2.3.5 요구사항 승인 및 연동 시스템 처리
- 요구사항 승인 및 연동 시스템은 요구사항 권한 관리 시스템의 변동이 생겼을 경우 처리 하는 시스템입니다.
- 요구사항 승인 및 연동 시스템은 변동된 요구사항의 이슈 처리를 연계된 Jira Project 에 반영하고 반영된 결과를 리뷰어를 포함하여 알립 니다.
2.2.3.6 모니터링 시스템
2.2.6.1 Server 모니터링 시스템
- MetricBeat 를 활용한 데이터 수집 및 모니터링
2.2.6.2 Application 성능 모니터링 시스템
- Elastic APM 과 Scouter를 활용한 성능 데이터 수집 및 모니터링
2.2.6.3 Database 모니터링 시스템
- Packetbeat 를 활용한 SQL 데이터 수집 및 모니터링
2.2.6.4 연동 시스템 모니터링
- Heartbeat 를 활용한 연동시스템 상태 데이터 수집 및 모니터링
2.2.6.5 클라이언트 모니터링 시스템
- Filebeat 를 활용한 Log 분석 시스템을 통하여 클라이언트 데이터 수집 및 모니터링
2.2.6.6 장애 탐지 알람 시스템
- 상기 데이터 수집의 결과 데이터를 InfluxDB ( 시계열 데이터베이스 )에 누적하여, 임계 수치를 적용, 알람 시스템을 통한 상황 전파를 담당하는 시스템 입니다
3. 인터페이스 요구사항
3.1 사용자 인터페이스
모듈별 사용자 UI 및 스토리보드 형식의 와이어프레임 기제
| 모듈 명 | 와이어 프레임 링크 ( 현재 링크 없음) |
|---|---|
| 인증 시스템 | 인증 시스템 - UI/UX Page 정의 리스트 |
| 분류 시스템 | 분류 시스템 - UI/UX Page 정의 리스트 |
| 요구사항 관리 시스템 | 요구사항 관리 시스템 - UI/UX Page 정의 리스트 |
| 요구사항 맵핑 시스템 ( 연동 시스템 포함 ) | 요구사항 지원 시스템 - UI/UX Page 정의 리스트 |
| 프로젝트 분석 시스템 ( 알람 시스템 포함 ) | 프로젝트 분석 시스템 - UI/UX Page 정의 리스트 |
| 모니터링 시스템 | 모니터링 시스템 - UI/UX Page 정의 리스트 |
3.2 시스템 인터페이스
시스템 인터페이스는 시스템 아키텍쳐로 갈음하도록 합니다. 비지니스 아키텍쳐로 목적 시스템을 구성한 후 → 시스템 구성도로 목적 시스템 세부 컴포넌트를 구성할 수 있다. 이 세부 컴포넌트를 기준으로 시스템 아키텍쳐를 표기하는 input으로 활용하여 시스템간 인터페이스 내용을 표기하기 때문입니다.