[313DevGrp] A-RMS

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) 변경에 대한 이력은 SRS에 기록됨에도 불구하고, 변경 사항의 추적성이 부족합니다. 변경 사항의 최종 형상만 확인되며, 중간 과정의 변경 및 이력이 적절히 관리되지 않습니다.

요구사항( Issue) 충족 여부 확인의 어려움: 요구사항( Issue)을 발의한 사람들이 제시한 대로 제품(Service) 개발되고 있는지 확인하는 것이 어렵습니다. 개발 팀장을 통해 요구사항( Issue)의 해석과 개발 진행 상황을 전달받기 때문에, 요구사항( Issue)의 충족 여부를 정확하게 확인하기 어려운 상황이 발생합니다.

이러한 문제점들은 요구사항( Issue) 관리 및 프로젝트 진행 상황 파악에 대한 투명성과 효율성을 제한하는 요인으로 작용하고 있습니다. 이러한 배경을 통해 새로운 요구사항( Issue) 관리 시스템의 필요성과 중요성을 높이고자 합니다. 

 

 

2. 내용

 

   2.1 경쟁 제품 조사 및 비교
 

      Atlassian 제품군 요구사항 관리 툴 조사

 Atlassain 제품과 connector 를 제공하는 솔루션으로 아래의 링크는 요구사항에 관련한 Atlassian 의 자라 사용방법에 관련된 내용입니다.

Using Jira for Requirements Management | Jira | Atlassian Documentation

 

솔루션 명	WEB 링크
Modern Requirements	https://www.modernrequirements.com/modern-requirements4devops/
Visure	https://visuresolutions.com/free-trial
reqtest	https://reqtest.com/en/
doors	https://jazz.net/previews/#dng
jama	https://www.jamasoftware.com/platform/jama-connect/features/

• 현재 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에 전파합니다. 

제품(Service)별로 다음과 같이 A-RMS를 통하여 요구사항( Issue)을 등록 할 수 있습니다.

 

제품(Service)별로 버전을 관리할 수 있습니다. 

등록된 지라 서버를 조회하고 추가하며 변경할 수 있습니다.

연결된 jira 서비스를 조회하고 버전을 선택 & 등록하여 제품(Service) jira 연결을 등록합니다.

 

3. 활용 방안

   3.1 기대 효과

      ARMS 적용 후 순기능

• 프로젝트 버전관리에 중요성 대해 인식이 높아질 것이며 릴리즈 날짜를 선정하고, 어떠한 요구사항( Issue)을 적용했는지에 관리를 할 수 있습니다.
• 제품(Service)의 모든 관련자가 요구사항( Issue)을 기반으로 소통할 수 있습니다.
• 상위 관리자는 현재 진행되는 모든 프로젝트의 진행 척도와 개발 진척사항을 확인합니다. 

 

 

      ARMS 적용 후 역할 별 효과 

   

구분	효과 설명
고객 면대면	고객의 요구사항( Issue) 실시간 채택여부, 개발 진척상황, 제품(Service) 적용 시점 확인 가능
기획 담당자	요구사항( Issue)의 이력 관리 및 분류, 구분, 변경에 대한 개발팀과의 소통 창구 개설
상위 관리자	전체 제품(Service) 개발 진척 상황 모니터링
개발팀	1. 명시된 요구사항( Issue) 을 근거로 이슈 생성  2. 문서 작성 3. 개발 4. 리뷰 5. 코드 분석 6. 빌드  7. 배포 FM Flos

   

 

* A-RMS 목차

[313DevGRP] A-RMS INDEX PAGE