Index: arms/docs/aRMs-Document.html =================================================================== diff -u -rde070d6b74a1e97b6a67f16e7d76fc32b893f7ef -rb7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63 --- arms/docs/aRMs-Document.html (.../aRMs-Document.html) (revision de070d6b74a1e97b6a67f16e7d76fc32b893f7ef) +++ arms/docs/aRMs-Document.html (.../aRMs-Document.html) (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -104,28 +104,47 @@ ============================ -->
@@ -156,1000 +174,38 @@
- -
-

A-RMS Document

- - - - - - - - - - - - - - - - - - -
-
+

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문서 관리 - 프로젝트 문서를 온라인 화 및 관리 - 지식 저장소의 역할 -
5CI/CD 관리 - 코드를빌드하고(자동화된UnitTest, 정적분석및자동화된프로젝트문서산출) 아티팩트 생성 -
6릴리즈 관리 - 아티팩트 공유 및 배포 레파지토리 관리※ ARMS 적용 후 ALM (ROSE) 프로토타입 -
-
-

1. 제품 이해 관계자들이 요구사항( Issue)을 쉽고, 단순하게 올릴 수 있습니다. (누가, 언제, 어떤 변화 이력이 있는지에 관한 시스템을 지원)

-

2. WORKS(jira)에 특정 label을 달고 자동으로 요구사항( Issue) 이슈가 등록되며, 선정된 요구사항( Issue)을 토대로 DOCS(confluence)에 - SRS가 기재되어야 합니다.

-

3. ARMS가 이를 수집하여 현재 상태를 표시합니다

-
-
-

2.3 기술의 구성A-RMS 시스템 구성도

- 시스템구성도 +

SRS Document

+
-

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
-
-
-
+

SDS Document

+ +
+ +
+ +
-
-
-

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가상 Docker1 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으로 활용하여 시스템간 인터페이스 내용을 표기하기 때문입니다.

- -
-
-
-

4. 제품(서비스) 기능 요구사항

-

4.1 A-RMS → Auth 기능 요구사항

-

* 본 프로젝트 범주는 A-RMS의 인증과 인가에 대한 내용을 다룹니다

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RequirementSummarize FunctionMiddle FunctionDetail function
인증 시스템 REQ ID : AUTH통합 계정 관리 시스템 REQ ID : SUMACCOUNT통합 로그인 사용자 검색 시스템 REQ ID : TOTAL - User Account Search Service - - 사용자 계정 정보를 검색하고 - - 사용자 세부정보를 확인할 수 있다. -
계정 그룹 관리 시스템 ( CRUD ) - REQ ID : ACCOUNT GROUPGroup Manager - - 사용자 계정을 그룹화 하기 위하여, - - 그룹을 정의 설정, 관리 할 수 있다. Group - User Mapper - - 사용자 계정을 그룹화 하고, - - 그룹을 대상으로 권한을 관리 할 수 있다.
통합 권한 관리 시스템 - REQ ID : SUMPERMISSON권한 관리 시스템 ( CRUD ) - REQ ID : GRANTGlobal - Permission Mapper - - 그룹을 대상으로 권한을 관리한다. - - 권한은 admin, user, anonymous 로 구분 Permission Manager - - 권한을 정의하고 관리한다. - - 권한관리는 admin user 만이 가능하다. Group - Permission Mapper - - 그룹을 대상으로 권한을 관리한다. - User - Permission Mapper - - 계정을 대상으로 권한을 관리한다.
로컬 계정 관리 시스템 - REQ ID : LOCALACCOUNT로컬 로그인 계정 관리 ( CRUD ) - REQ ID : LOCAL - Local Account Manager - - 로컬 계정을 관리한다. ( CRUD ) - - Global 권한과 Permission 권한을 관리
연동 계정 관리 시스템 - REQ ID : INTEGACCOUNTUser Directories 시스템 REQ ID : DIRECTORY - OAuth Manager - - OAuth를 지원하는 시스템과 연결 - - JIRA, Crowd, etc - LDAP Join Manager - - LDAP을 연결하고 계정 정보를 연결 -
사용자별 맞춤형 REQ ID : FORUSER개발자 및 프로젝트 진행 담당자 - REQ ID : DEV - - Project Collected Data Viewer - - 프로젝트 진행 담당자 관련 데이터 뷰어 - DashBoard Viewer -
기획자 및 프로젝트 이해 관계자 - REQ ID : PLAN - Project Requirement Progress Viewer - 요구사항 반영 진척도 뷰어 - - DashBoard Viewer -
고위관리자 REQ ID : BOSS - Product ( Service ) Progress Viewer - 제품 ( 서비스 ) 기반 진척도 뷰어 - - DashBoard Viewer -
Atlassian Tool Chain 담당자 - REQ ID : DEVOPS - Atlassian Tool Monitoring Viewer - 아틀라시안 제품 모니터링 뷰어 - - DashBoard Viewer -
- -
-

4.2 A-RMS → Product & Service 기능 요구사항(수정중)

-

* 본 프로젝트 범주는 aRMS Product(Service) 내부의 데이터를 분류하는 시스템을 jsTree framework를 활용하여 관리하는 범위에 대해 기술합니다 -

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RequirementSummarize FunctionMiddle FunctionDetail function
분류 시스템 - REQ ID : CLASSFI제품(서비스) 와 - ALM Tool Chain Mapping 시스템 - REQ ID : PROSERVICE제품 (서비스) 관리 시스템 - - Product (Service) Manager - - 제품 ( 서비스 ) 등록 및 관리 ( CRUD ) -
계정 그룹 관리 시스템 ( CRUD ) - REQ ID : ACCOUNT GROUPGroup Manager - - 사용자 계정을 그룹화 하기 위하여, - - 그룹을 정의 설정, 관리 할 수 있다. Group - User Mapper - - 사용자 계정을 그룹화 하고, - - 그룹을 대상으로 권한을 관리 할 수 있다.
통합 권한 관리 시스템 - REQ ID : SUMPERMISSON권한 관리 시스템 ( CRUD ) - REQ ID : GRANT
로컬 계정 관리 시스템 - REQ ID : LOCALACCOUNT로컬 로그인 계정 관리 ( CRUD ) - REQ ID : LOCAL -
연동 계정 관리 시스템 - REQ ID : INTEGACCOUNTUser Directories 시스템 REQ ID : DIRECTORY -
사용자별 맞춤형 REQ ID : FORUSER개발자 및 프로젝트 진행 담당자 - REQ ID : DEV -
기획자 및 프로젝트 이해 관계자 - REQ ID : PLAN - Project Requirement Progress Viewer - 요구사항 반영 진척도 뷰어 - - DashBoard Viewer -
고위관리자 REQ ID : BOSS - Product ( Service ) Progress Viewer - 제품 ( 서비스 ) 기반 진척도 뷰어 - - DashBoard Viewer -
Atlassian Tool Chain 담당자 - REQ ID : DEVOPS - Atlassian Tool Monitoring Viewer - 아틀라시안 제품 모니터링 뷰어 - - DashBoard Viewer -
- -
-
@@ -1169,22 +225,31 @@ +
- + @@ -1201,5 +266,8 @@ + + + Index: arms/docs/assets/images/document/requirementInfo.png =================================================================== diff -u Binary files differ Index: arms/docs/assets/images/document/sds_01.png =================================================================== diff -u Binary files differ Index: arms/docs/assets/images/document/srs_01.png =================================================================== diff -u Binary files differ Index: arms/docs/assets/images/document/srs_02.png =================================================================== diff -u Binary files differ Index: arms/docs/assets/images/document/systemConfigurationDiagram.png =================================================================== diff -u Binary files differ Index: arms/docs/html/design-considerations.html =================================================================== diff -u --- arms/docs/html/design-considerations.html (revision 0) +++ arms/docs/html/design-considerations.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,57 @@ +

2.설계고려사항

+

2.1 소프트웨어 설계 목표

+

jsTree Service Framework를 활용하여 Tree 알고리즘 기준의 Requirement Management System 을 설계합니다.

+ +

aRMS는 프로젝트 요구사항을 효과적으로 관리하기 위한 시스템으로, 다양한 기능과 모듈을 포함합니다. - 설계 목표

+ +

Frontend 및 Backend 분리: aRMS의 주요 설계 목표 중 하나는 Frontend 개발과 Backend 개발을 명확하게 분리하는 것입니다. + 이를 통해 각 영역의 독립성을 확보하고 개발 프로세스를 효율적으로 관리할 수 있습니다.
+ 비지니스 로직과 설정의 분리: 두 번째 목표는 비지니스 로직을 Backend에 집중시키고, Java 개발의 engine 및 framework 설정은 Core-Module로 분리하여 실제 비지니스 로직과 구성 요소를 분리합니다. 이를 통해 복잡성을 감소시키고 유지보수성을 향상시킵니다.
+ 패키지 및 라이브러리 관리 툴 활용: aRMS의 세 번째 목표는 패키지 및 라이브러리 관리를 효율적으로 수행하는 것입니다. Maven과 같은 관리 툴을 활용하여 라이브러리의 업데이트와 관리를 용이하게 하고, 관련한 라이브러리를 Lib-Module로 분리하여 패키지 업데이트를 간편하게 지원합니다. +

+ +

aRMS와 관련한 설계목표는 개발 후 → 자동으로 빌드하며 → Core-Module은 Nexus에 Upload되고, Docker는 Docker Hub에 Upload되도록 Source Write after Deploy 까지 One Shot Flow CI/CD를 제공하고
+ Source 설계 목표는 비지니스 코드인 제품 코드는 Web-Module 에서만 사용하도록 구성했습니다.

+
+

2.2 제약사항

+

2.2.1 H/W 제약사항

+

하드웨어는 Monitoring Server 시스템으로 인하여 많은 자원이 필요합니다. 따라서, 다음의 하드웨어 최소 스펙과 권장 스펙을 지정하도록 하겠습니다.

+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
spec설명cpumemdisk
최소 스펙1 Server All in one12 core32 gb500 gb
권장 스펙4 + 1 Server Clusterper 12 coreper 16 gbNFS Server 2TB~
+
+
+

2.2.2 S/W 제약사항

+

aRMS는 S/W 제약사항이 존재하지 않고, 100% OpenSource를 활용하여 개발하도록 합니다.

+

2.2.3 N/W 제약사항

+

aRMS는 Atlassian ALM 제품군과 통신이 필요합니다.

+

2.3 기타

+

PLE ( Product Line Engineering ) 기법을 활용하여, 재사용을 극대화한 프로젝트 구조를 적용합니다. + - aRMS는 자체적인 Static Code Analysis ( SonarQube )를 적용하여 코드 품질을 유지하도록 합니다. - aRMS는 BitBucket (혹은 Github)을 활용하여 Git으로 형상관리를 적용하도록 합니다.

Index: arms/docs/html/design.html =================================================================== diff -u --- arms/docs/html/design.html (revision 0) +++ arms/docs/html/design.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,507 @@ +

3. 설계

+

  3.1 구성

+

3.1.1 소프투웨어 배치

+
+
+
+

소프트웨어 배치는 SRS ( Software Requirement Specification ) 에서 산출된 비지니스 아키텍쳐 → 시스템 구성도 → 시스템 아키텍쳐로 점차 구체화 되기때문에, 시스템 아키텍쳐로 소프트웨어 배치도를 갈음하도록 합니다.

+
+
+
+

+

+

3.1.2 소프트웨어 아키텍쳐

+
+
+
+

소프트웨어 아키텍쳐는 다음과 같이 구성합니다.

+

시스템 아키텍쳐를 기반으로 구체화된 어플리케이션 아키텍쳐로 본 장을 갈음하도록 합니다.
어플리케이션 아키텍쳐로 각 시스템의 세부 컴포넌트와 모듈을 표시하고 상호 작용하는 목적이 기술되어 있기 때문입니다.

+

 

+
+
+
+

3.1.3 Component Design

+
+
+
+

소프트웨어 구성요소인 각 Component와 그 하위 module을 정의하고, 각각의 기능 및 의존관계 등을 기술합니다. ( input 값인 소프트웨어 아키텍쳐를 기반으로 컴포넌트의 역할과 주요 호출 등을 서술합니다. )

+
+
+
+

3.1.3.1 통합 계정 관리 Manager(Component)

+
+
+
+

로컬 + 연동 계정의 풀에서 사용자 계정을 관리 할 수 있도록 지원하는 메니저

+
+
+
+

3.1.3.2 통합 권한 관리 Manager(Component)

+
+
+
+

로컬 + 연동 계정의 풀에서 사용자 계정에 대한 권한을 관리 할 수 있도록 지원하는 메니저 또한 전체 계정을 대상으로 권한을 정의하고 할당 할 수 있도록 지원하는 메니저

+
+
+
+

3.1.3.3 로컬 계정 관리 Manager(Component)

+
+
+
+

로컬 내부에서 계정을 관리 할 수 있도록 하는 메니저

+
+
+
+

3.1.3.4 연동 계정 관리 Manager ( Component )

+
+
+
+

연동하는 계정 툴. 예를 들어 LDAP, CROWD 등의 계정을 로드하도록 지원하는 메니저 연동하는 계정을 연결 할 수 있도록 설정을 지원하는 메니저

+
+
+
+

3.1.3.5 사용자별 맞춤 Manager ( Component )

+
+
+
+

전체 사용자를 일정한 권한을 기준으로 맞춤형 서비스를 제공하고, 제품(서비스) 별 대시보드를 제공하는 메니저

+
+
+
+

3.1.3.6 수집 호스트 분류 Manager ( Component )

+
+
+
+

모니터링 시스템에 적재되는, 데이터를 기준으로 호스트를 분류하여 리스트를 제공하도록 하는 메니저

+
+
+
+

3.1.3.7 자동 설정 등록 Manager ( Component )

+
+
+
+

모니터링 시스템의 데이터 통합 컨트롤러를 InfluxDB로 수집하기 때문에,
InfluxDB에 자동으로 등록할 수 있는 DataSource와 DashBoard를, 미리 등록된 template 를 import 할 수 있도록 지원하는 메니저

+
+
+
+

3.1.3.8 요구사항 등록 Manager ( Component )

+
+
+
+

요구사항을 등록 할 수 있도록 제품(서비스) 를 표시하고 사용자로 하여금 요구사항을 등록 할 수 있도록 지원하는 메니저

+
+
+
+

3.1.3.9 요구사항 리뷰 Manager ( Component )

+
+
+
+

등록된 요구사항은 제품(서비스)에 의해 구조화 되고, 해당 제품(서비스)의 요구사항은 관리되어야 할 대상으로 각 요구사항은, 미리 정의된 프로세스인 ( 등록->리뷰→승인 ) 일련의 과정을 거칩니다.
또한, 제픔(서비스)의 일련의 과정을 관리 및 권한을 권한자로 하여금 처리할 수 있도록 한정합니다.

+
+
+
+

3.1.3.10 요구사항 권한 Manager ( Component )

+
+
+
+

요구사항 권한 메니저는 요구사항 리뷰 메니저에 제공할, 제품(서비스)의 일련의 과정 프로세스를 관리하고, 각 프로세스를 처리할 수 있는 권한자를 관리하는 메니저

+
+
+
+

3.1.3.11 요구사항 버전 Manager ( Component )

+
+
+
+

요구사항 버전 관리 메니저는 제품(서비스)의 출시와 관련되며, 이슈 트래커에 등록할 버전을 지정하여 관리되고, 연동할 수 있는 컴포넌트입니다.

+
+
+
+

3.1.3.12 요구사항 승인, 연동 Manager ( Component )

+
+
+
+

요구사항은 최종 과정인 승인과, 더불어서 제품(서비스)에 연동된 Issue tracker 및 wiki 등에 후속 조치를 담당하는 메니저 입니다.

+
+
+
+

3.1.3.13 요구사항 이력 Manager ( Component )

+
+
+
+

요구사항의 모든 기록을 담당하는 이력 메니저이며, 변동사항 발생시 등록된 일련의 프로세스를 재시작하는 메니저입니다. 또한 변경 또는 프로세스가 진행된 내역을 조회할 수 있으며, 연동된 시스템 역시 확인 할 수 있도록 기능을 제공합니다.

+
+
+
+

3.1.3.14 요구사항 진척 Manager ( Component )

+
+
+
+

요구사항 진척 메니저는 제품(서비스)에 등록된 요구사항의 연결된 이슈와 버전정보를 바탕으로 진척도를 관리하는 메니저 입니다.

+
+
+
+

3.1.3.15 요구사항 알람 Manager ( Component )

+
+
+
+

요구사항 일련의 프로세스에 따라서, 제품(서비스) 의 이해관계자 * 연동된 시스템의 사용자까지 * 에게 알람을 발송합니다. 알람 발송 시, mail 을 default로 하고 추가 알람 방식은 추후 제공하도록 합니다.

+
+
+
+

3.1.3.16 제품(서비스) 등록 Manager ( Component )

+
+
+
+

aRMS의 기준 데이터 중에 하나인 제품(서비스)를 등록하고 관리하도록 합니다.

+
+
+
+

3.1.3.17 제품(서비스) ALM Mapping Manager ( Component )

+
+
+
+

제품(서비스)에서 연동할 툴의 게이트를 제공하는 메니저입니다.
실제 연동 설정 데이터를 관리하지 않습니다. ( 이유는 1:N 의 관계를 가질 수도 있기 떄문입니다 )

+
+
+
+

3.1.3.18 제품(서비스) - 요구사항 - Issue Tracker Mapping Manager ( Component )

+
+
+
+

제품(서비스)의 Issue Tracker 연동 설정을 제공하는 맵핑 메니저 입니다.

+
+
+
+

3.1.3.19 제품(서비스) - 요구사항 - WIKI Mapping Manager ( Component )

+
+
+
+

제품(서비스)의 Wiki 연동 설정을 제공하는 맵핑 메니저입니다.
위키를 등록하는 이유는 향 후 요구사항을 자동으로 위키에 문서로 저장 관리 해 주기 때문입니다. ( not write , only read )

+
+
+
+

3.1.3.20 제품(서비스) - 요구사항 - VCS Mapping Manager ( Component )

+
+
+
+

제품(서비스)의 VCS 연동 설정을 제공하는 맵핑 메니저입니다.
VCS를 통해 관련 요구사항의 하위 이슈와 연관된 브랜치와 소스의 상태를 추적하여 수치화 하는데 집중되 있습니다.

+
+
+
+

3.1.3.21 제품(서비스) - 요구사항 - Code Quality Mapping Manager ( Component )

+
+
+
+

제품(서비스)의 CodeQuality 툴 연동 설정을 제공하는 맵핑 메니저 입니다.
이 경우, Issue tracker 나 VCS에서 제공되는 api 가 있다면 자동 수집하도록 하며,
연관 이슈에서 파생된 코드의 변경은 추적하여 수집하고, 이외에도 추가적으로 마스터 브랜치에 대한 코드 퀄리티를 추적합니다.

+
+
+
+

3.1.3.22 제품(서비스) - 요구사항 - CICD Mapping Manager ( Component )

+
+
+
+

제품(서비스)의 연관된 이슈에서 커밋, 푸쉬된 VCS정보로 부터 확인 할 수 있는 CICD 빌드 결과나, 배포 현황을 볼 수 있도록 비주얼한 서비스를 제공합니다.

+
+
+
+

3.1.4 Data Design

+
데이터 디자인은 다음과 같이 구성합니다.
+
+

어플리케이션 아키텍쳐를 기반으로 구체화된 컴포넌트와 모듈이 사용하는 데이터를 설계하는 데이터 아키텍쳐로 갈음합니다. ( 소프트웨어 Component 간에 전달되는 자료구조를 설명합니다. )

+
+
+

3.1.5 Interface Design

+
+
+
+

인터페이스 디자인의 전제는 시스템 정의에서 상세화된 컴포넌트의 데이터 아키텍쳐가 Input 값이며, ( 어떤 데이터를 input하고 어떤 데이터를 return 할 것인지 정의되어야 한다 )

+

컴포넌트 기준으로 사용되는 인터페이스가 상세화되는것이 인터페이스 디자인 Output이다.

+
+
+
+

3.1.5.1 Module Interface 

+

+

+ + + + + + + + + +
+
+
모듈은 가장 상위에 위치하는 구현의 단위, 컴포넌트는 런타임 엔티티를 참조하는 단위라고 생각하면 됩니다. 따라서, 모듈과 컴포넌트는 상위와 하위관계를 명확히 구분짓기 어렵고 서로 다른 개념으로 바라보아야 합니다. 쉽게 설명해서, 모듈이란 실질적으로 구현이 된 단위를 의미한다.
반면, 컴포넌트는 실제적으로 동작하고있는 엔티티로써 활동중인 독립적인 단위를 중점적으로 보고 있다.
+
+
+
+
객체지향 프로그래밍 언어를 사용하는 프로젝트에서는, 컴포넌트란, 잘 동작하는 기능 단위를 말하는 것이며, 컴포넌트에서 사용하는 데이터의 단위는 VO ( Value Object ) 또는 DTO ( Data Transfer Object ) 를 의미하게 됩니다. 이 데이터 단위 표시는 데이터베이스 ERD 와 연관관계를 가지게 되며,
ERD 와 Mapping 관계를 가지지 않는 VO 혹은 DTO 는 Class 명세에 표시됩니다.
+
+
+ + + + + + + + + + + + + + + +
+
+
+
core - module source code
+
+
+ 		+ +
+
+
+
backend - module source code
+
+
+ 		+ +
+
+
+
frontend - module sorce code
+
+
+ 		+ +
+

A-RMS 시스템은 총 4개의 모듈로 이루어져 있습니다  (Frontend, Middle-Proxy, Core,   )

+

이 시스템은 전통적인 방식으로 구성되어 있으며, 각 모듈은 아래와 같은 역할을 수행합니다.

+


Core 모듈: Core 모듈은 의존성 라이브러리 관리와 함께 Struts부터 Spring까지 다양한 설정을 제공합니다. 또한 iBatis에서 Hibernate까지 다양한 설정을 포함하고 있습니다. 이 모듈은 다른 모듈 간의 관계를 설명하는데 중점을 두며, 시스템의 핵심 설정과 의존성 관리를 수행합니다.

+ +

Backend 모듈: Backend 모듈은 비즈니스 로직에서 사용되는 최소한의 속성, 설정 및 코드를 포함하고 있는 구조입니다. 이 모듈은 핵심 비즈니스 로직을 처리합니다. Java Service Tree Framework를 기반으로 동작하고 있습니다. Java Service Tree Framework 는  MVC패턴을 구현한 다양한 프레임워크를 대상으로 ( EgovFramework 기반한 ) 서비스레이어의 도메인 객체를 Tree Base Object로 간주하여 서비스 - DAO - DTO - DB를 정형화한 기반 구현체를 제공하는 프레임워크 입니다.

+


Frontend 모듈: Frontend 모듈은 웹 서버에서 정적 파일을 전송하는 역할을 담당합니다. 주로 사용자 인터페이스와 관련된 기능을 처리하며, 사용자가 시스템과 상호작용할 수 있도록 합니다.


+

3.1.5.2 Component Interface Design

+

3.1.5.2.1 통합 계정 관리 Manager ( Component )

+
+
+
    3.1.5.2.1.1 getUserFromAllDirectory
+
+
+

    3.1.5.2.1.2 getUsersFromAllDirectory

+

3.1.5.2.2 통합 권한 관리 Manager ( Component )

+

    3.1.5.2.2.1 getPermissionFromUser

+

    3.1.5.2.2.2 getPermission

+

    3.1.5.2.2.3 putPermission

+

    3.1.5.2.2.4 updatePermission

+

    3.1.5.2.2.5 deletePermission

+

    3.1.5.2.2.6 getAllPermissionList

+

3.1.5.2.3 로컬 계정 관리 Manager ( Component )

+

    3.1.5.2.3.1 getLocalUser

+

    3.1.5.2.3.1 putLocalUser

+

    3.1.5.2.3.1 updateLocalUser

+

    3.1.5.2.3.1 deleteLocalUser

+

    3.1.5.2.3.1 getAllLocalUser

+

3.1.5.2.4 연동 계정 관리 Manager ( Component )

+

    3.1.5.2.4.1 getRelatedAccoutTool

+

    3.1.5.2.4.2 putRelatedAccoutTool

+

    3.1.5.2.4.3 updateRelatedAccoutTool

+

    3.1.5.2.4.4 deleteRelatedAccoutTool

+

    3.1.5.2.4.5 getAllRelatedAccoutTool

+

    3.1.5.2.4.6 connectRelatedAccoutTool

+

3.1.5.2.5 사용자별 맞춤 Manager ( Component )

+

    3.1.5.2.5.1 getDeveloperViewTemplate

+

    3.1.5.2.5.2 setPerDeveloperView

+

    3.1.5.2.5.3 getPerDeveloperView

+

    3.1.5.2.5.4 updatePerDeveloperView

+

    3.1.5.2.5.5 deletePerDeveloperView

+

3.1.5.2.6 수집 호스트 분류 Manager ( Component )

+

    3.1.5.2.6.1 Anonymous - getDeviceList

+

    3.1.5.2.6.2 Anonymous - searchNode

+

    3.1.5.2.6.3 Anonymous - getPaginatedChildNode

+

    3.1.5.2.6.4 Anonymous - getNode

+

    3.1.5.2.6.5 Anonymous - getChildNode

+

    3.1.5.2.6.6 Anonymous - getMonitor

+

    3.1.5.2.6.7 Anonymous - updateList

+

    3.1.5.2.6.8 Admin - addNode

+

    3.1.5.2.6.9 Admin - removeNode

+

    3.1.5.2.6.10 Admin - alterNode

+

    3.1.5.2.6.11 Admin - alterNodeType

+

    3.1.5.2.6.12 Admin - moveNode

+

    3.1.5.2.6.13 Admin - getChildNode

+

3.1.5.2.7 자동 설정 등록 Manager ( Component )

+

    3.1.5.2.7.1 updateDashBoard

+

    3.1.5.2.7.2 updateDataSource

+

    3.1.5.2.7.3 updateDeviceHost

+

3.1.5.2.8 요구사항 등록 Manager ( Component )

+

    3.1.5.2.8.1 Admin - Requirement addNode

+

    3.1.5.2.8.2 Admin - Requirement alterNode

+

    3.1.5.2.8.3 Admin - Requirement alterTypeNode

+

    3.1.5.2.8.4 Admin - Requirement removeNode

+

    3.1.5.2.8.5 Admin - Requirement moveNode

+

    3.1.5.2.8.6 Admin - Requirement getNode

+

3.1.5.2.9 요구사항 리뷰 Manager ( Component )

+

    3.1.5.2.9.1 Admin - Requirement Review addNode

+

    3.1.5.2.9.2 Admin - Requirement Review alterNode

+

    3.1.5.2.9.3 Admin - Requirement Review alterTypeNode

+

    3.1.5.2.9.4 Admin - Requirement Review removeNode

+

    3.1.5.2.9.5 Admin - Requirement Review moveNode

+

    3.1.5.2.9.6 Admin - Requirement Review getNode

+

3.1.5.2.10 요구사항 권한 Manager ( Component )

+

3.1.5.2.10.1 Admin - Requirement Permission addNode

+

    3.1.5.2.10.2 Admin - Requirement Permission alterNode

+

    3.1.5.2.10.3 Admin - Requirement Permission alter type Node

+

    3.1.5.2.10.4 Admin - Requirement Permission removeNode

+

    3.1.5.2.10.5 Admin - Requirement Permission moveNode

+

    3.1.5.2.10.6 Admin - Requirement Permission getNode

+

3.1.5.2.11 요구사항 버전 Manager ( Component )

+

    3.1.5.2.11.1 Admin - Requirement Version addNode

+

    3.1.5.2.11.2 Admin - Requirement Version alterNode

+

    3.1.5.2.11.3 Admin - Requirement Version alterTypeNode

+

    3.1.5.2.11.4 Admin - Requirement Version removeNode

+

    3.1.5.2.11.5 Admin - Requirement Version moveNode

+

    3.1.5.2.11.6 Admin - Requirement Version getNode

+

3.1.5.2.12 요구사항 승인, 연동 Manager ( Component )

+

    3.1.5.2.12.1 Admin - Requirement Transaction addNode

+

    3.1.5.2.12.2 Admin - Requirement Transaction alterNode

+

    3.1.5.2.12.3 Admin - Requirement Transaction alterTypeNode

+

    3.1.5.2.12.4 Admin - Requirement Transaction removeNode

+

    3.1.5.2.12.5 Admin - Requirement Transaction moveNode

+

    3.1.5.2.12.6 Admin - Requirement Transaction getNode

+

3.1.5.2.13 요구사항 이력 Manager ( Component )

+

    3.1.5.2.13.1 Admin - Requirement History addNode

+

    3.1.5.2.13.2 Admin - Requirement History alterNode

+

    3.1.5.2.13.3 Admin - Requirement History alterTypeNode

+

    3.1.5.2.13.4 Admin - Requirement History removeNode

+

    3.1.5.2.13.5 Admin - Requirement History moveNode

+

    3.1.5.2.13.6 Admin - Requirement History getNode

+

3.1.5.2.14 요구사항 진척 Manager ( Component )

+

    3.1.5.2.14.1 Admin - Requirement Info 프로덕트(서비스)

+

    3.1.5.2.14.2 Admin - Requirement Info 프로덕트(서비스)

+

    3.1.5.2.14.3 Admin - Requirement Info 프로덕트(서비스)

+

    3.1.5.2.14.4 Admin - Requirement Info 프로덕트(서비스)

+

    3.1.5.2.14.5 Admin - Requirement Info 프로덕트(서비스)

+

    3.1.5.2.14.6 Admin - Requirement Info 프로덕트(서비스)

+

3.1.5.2.15 요구사항 알람 Manager ( Component )

+

    3.1.5.2.15.1 Admin - Requirement Alarm - configuration

+

3.1.5.2.16 제품(서비스) 등록 Manager ( Component )

+

    3.1.5.2.16.1 Product(Service) Manager - addNode

+

    3.1.5.2.16.2 Product(Service) Manager - alterNode

+

    3.1.5.2.16.3 Product(Service) Manager - alterTypeNode

+

    3.1.5.2.16.4 Product(Service) Manager - removeNode

+

    3.1.5.2.16.5 Product(Service) Manager - moveNode

+

    3.1.5.2.16.6 Product(Service) Manager - getNode

+

3.1.5.2.17 제품(서비스) ALM Mapping Manager ( Component )

+

    3.1.5.2.17.1 Product(Service) - ALM Mapping Manager - addNode

+

    3.1.5.2.17.2 Product(Service) - ALM Mapping Manager - alterNode

+

    3.1.5.2.17.3 Product(Service) - ALM Mapping Manager - alterTypeNode

+

    3.1.5.2.17.4 Product(Service) - ALM Mapping Manager - removeNode

+

    3.1.5.2.17.5 Product(Service) - ALM Mapping Manager - moveNode

+

    3.1.5.2.17.6 Product(Service) - ALM Mapping Manager - getNode

+

3.1.5.2.18 제품(서비스) - 요구사항 - Issue Tracker Mapping Manager ( Component )

+

     3.1.5.2.18.1 Product(Service) - Issue Tracker Mapping Manager - addNode

+

     3.1.5.2.18.2 Product(Service) - Issue Tracker Mapping Manager - alterNode

+

    3.1.5.2.18.3 Product(Service) - Issue Tracker Mapping Manager - alterTypeNode

+

    3.1.5.2.18.4 Product(Service) - Issue Tracker Mapping Manager - removeNode

+

    3.1.5.2.18.5 Product(Service) - Issue Tracker Mapping Manager - moveNode

+

    3.1.5.2.18.6 Product(Service) - Issue Tracker Mapping Manager - getNode

+

3.1.5.2.19 제품(서비스) - 요구사항 - WIKI Mapping Manager ( Component )

+

    3.1.5.2.19.1 Product(Service) - Issue Wiki Mapping Manager - addNode

+

    3.1.5.2.19.2 Product(Service) - Issue Wiki Mapping Manager - alterNode

+

    3.1.5.2.19.3 Product(Service) - Issue Wiki Mapping Manager - alterTypeNode

+

    3.1.5.2.19.4 Product(Service) - Issue Wiki Mapping Manager - removeNode

+

    3.1.5.2.19.5 Product(Service) - Issue Wiki Mapping Manager - moveNode

+

    3.1.5.2.19.6 Product(Service) - Issue Wiki Mapping Manager - getNode

+

3.1.5.2.20 제품(서비스) - 요구사항 - VCS Mapping Manager ( Component )

+

    3.1.5.2.20.1 Product(Service) - Issue VCS Mapping Manager - addNode

+

    3.1.5.2.20.2 Product(Service) - Issue VCS Mapping Manager - alterNode

+

    3.1.5.2.20.3 Product(Service) - Issue VCS Mapping Manager - alterTypeNode

+

    3.1.5.2.20.4 Product(Service) - Issue VCS Mapping Manager - removeNode

+

    3.1.5.2.20.5 Product(Service) - Issue VCS Mapping Manager - moveNode

+

    3.1.5.2.20.6 Product(Service) - Issue VCS Mapping Manager - getNode

+

3.1.5.2.21 제품(서비스) - 요구사항 - Code Qaulity Mapping Manager ( Component )

+

    3.1.5.2.21.1 Product(Service) - Issue CodeQulity Mapping Manager - addNode

+

    3.1.5.2.21.2 Product(Service) - Issue CodeQulity Mapping Manager - alterNode

+

    3.1.5.2.21.3 Product(Service) - Issue CodeQulity Mapping Manager - alterTypeNode

+

    3.1.5.2.21.4 Product(Service) - Issue CodeQulity Mapping Manager - removeNode

+

    3.1.5.2.21.5 Product(Service) - Issue CodeQulity Mapping Manager - moveNode

+

    3.1.5.2.21.6 Product(Service) - Issue CodeQulity Mapping Manager - getNode

+

3.1.5.2.22 제품(서비스) - 요구사항 - CICD Mapping Manager ( Component )

+

    3.1.5.2.22.1 Product(Service) - Issue CICD Mapping Manager - addNode

+

    3.1.5.2.22.2 Product(Service) - Issue CICD Mapping Manager - alterNode

+

    3.1.5.2.22.3 Product(Service) - Issue CICD Mapping Manager - alterTypeNode

+

    3.1.5.2.22.4 Product(Service) - Issue CICD Mapping Manager - removeNode

+

    3.1.5.2.22.5 Product(Service) - Issue CICD Mapping Manager - moveNode

+

    3.1.5.2.22.6 Product(Service) - Issue CICD Mapping Manager - getNode

+
+

3.1.6 Database Description

+
+
+
+

영구적으로 사용되는 데이터는 데이터를 관리하는 시스템인 Database System에 해당합니다.

+

또한 데이터베이스 스키마의 데이터를 Mapping 하는 VO, DTO로 보통 표기되기에 ERD와 VO관계를 파악하는 것으로 갈읍합니다.

+

따라서, ERD - 데이터딕셔너리와 Class 다이어그램으로 갈음합니다.

+

 

+
+
+
+

3.1.6.1 ERD (Entity Relationship Diagram)

+
+
+
+
+

ERD는 클래스 상세화를 통하여 어떤 데이터를 데이터베이스에 적제해야 할지 결정 한 후 작성될 수 있습니다.

+

데이터 설계단계는 각 컴포넌트의 메소드 인터페이스에서 활용할 데이터객체 ( VO, DTO )가 정의된 후 상세화 및 명세가 가능합니다.

+

따라서, 클래스 다이어그램이 작성된 후 프로젝트 종료시점에 적시하도록 합니다. ( DDL, DML : script )

+
+
+
+
+
+
+
+
+
+
+
+

 

+
+
+
+

3.1.6.2 Class Diagram

+
+
+
+

프로젝트 진행 중 빌드 시 자동으로 클래스 다이어그램을 export 하여 제공할 수 있도록 합니다. 관련 링크는 다음과 같습니다 → http://www.313.co.kr/DeveloperPortal/analysis/

+
+
+
+
+
+
+

 

+

 

Index: arms/docs/html/footer.html =================================================================== diff -u --- arms/docs/html/footer.html (revision 0) +++ arms/docs/html/footer.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,8 @@ +
+

Copyright © 2023 A-arms. All Rights + Reserved.

+

Design & Develop by 313DEVGRP +

+
Index: arms/docs/html/interface-requirements.html =================================================================== diff -u --- arms/docs/html/interface-requirements.html (revision 0) +++ arms/docs/html/interface-requirements.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,65 @@ +

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으로 활용하여 시스템간 인터페이스 내용을 표기하기 때문입니다. +

+
Index: arms/docs/html/non-functional-requirements.html =================================================================== diff -u --- arms/docs/html/non-functional-requirements.html (revision 0) +++ arms/docs/html/non-functional-requirements.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,49 @@ +

5. 비-기능 요구사항

+

5.1 제품(서비스) 성능

+

쿠버네티스(K8s) 와 Docker Swarm 클러스터링을 통한 자원 활용을 통해 요구사항들을 다룹니다.

+

- 쿠버네티스(K8s) + Scale Out 및 Clustering 지원: 쿠버네티스는 애플리케이션을 여러개의 파드(pod)로 분산하고, 필요에 따라 자동으로 확장하거나 축소할 수 있도록 지원합니다. 파드는 동일한 애플리케이션 컨테이너들을 묶어놓은 단위이며, 이를 통해 애플리케이션을 쉽게 스케일 아웃할 수 있습니다. + 캐시 메모리 및 분산 컴퓨팅: 쿠버네티스는 다양한 종류의 볼륨을 지원하므로, Redis와 같은 캐시 메모리 서비스를 파드로 실행하고 데이터를 관리하는 것이 가능합니다. 분산 컴퓨팅은 여러 파드들을 이용하여 병렬 작업을 수행하거나, 데이터를 처리할 수 있도록 합니다. + Database Clustering 지원: 쿠버네티스는 StatefulSet이라는 리소스를 통해 상태를 가지는 애플리케이션을 관리할 수 있습니다.

+

이를 이용하여 데이터베이스 클러스터를 구성하고 관리할 수 있습니다 + Health Check 및 장애 극복: 쿠버네티스는 파드의 상태를 지속적으로 모니터링하고, 불필요한 상태의 파드를 제거하고 새로운 파드를 생성하는 등의 작업을 수행하여 애플리케이션의 가용성을 높일 수 있습니다. Liveness Probe와 Readiness Probe를 통해 파드의 상태를 모니터링하며 필요에 따라 조치를 취할 수 있습니다.

+

- Docker Swarm + Scale Out 및 Clustering 지원: Docker Swarm은 애플리케이션을 서비스(Service) 단위로 관리합니다. 서비스는 여러 개의 태스크(Task)로 구성되며, 각 태스크는 동일한 컨테이너 이미지를 실행하는 인스턴스입니다. 서비스의 스케일을 조절하여 필요에 따라 컨테이너 인스턴스를 추가하거나 제거하여 애플리케이션을 확장하거나 축소할 수 있습니다. + 캐시 메모리 및 분산 컴퓨팅: Docker Swarm은 다양한 네트워크 모드를 지원하여, 서비스 간 통신을 구성할 수 있습니다.

+

따라서 캐시 메모리와 같은 데이터 스토어 서비스를 컨테이너로 실행하고 다른 서비스들과 연결하여 분산 컴퓨팅 환경을 구성할 수 있습니다. + Database Clustering 지원: Docker Swarm은 데이터베이스 클러스터를 구성하기 위해 볼륨을 관리할 수 있는 기능을 제공합니다. 볼륨을 사용하여 데이터의 지속성을 보장하고, 여러 컨테이너가 동일한 데이터에 접근할 수 있도록 할 수 있습니다. + + Health Check 및 장애 극복: Docker Swarm은 서비스의 상태를 모니터링하고 필요한 경우 서비스를 다시 시작하거나 불필요한 컨테이너를 제거하여 가용성을 유지합니다. Health Check 설정을 통해 서비스의 상태를 감시하고 필요한 조치를 취할 수 있습니다.

+
+

5.2 보안

+

Keycloak은 동적 싱글 사인온 솔루션을 제공하기 위해 표준 보안 프로토콜에 따라 설계된 신뢰할 수 있는 오픈소스입니다.

+ +

Keycloak을 통해 관리할 수 있는 정보, 즉 다음을 볼 수 있습니다.

+ +

Keycloak은 다음 표준 프로토콜을 지원합니다.

+ +
Index: arms/docs/html/project-background.html =================================================================== diff -u --- arms/docs/html/project-background.html (revision 0) +++ arms/docs/html/project-background.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,44 @@ +
+

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) 관리 시스템의 필요성과 중요성을 높이고자 합니다. +

+
+ Index: arms/docs/html/project-content.html =================================================================== diff -u --- arms/docs/html/project-content.html (revision 0) +++ arms/docs/html/project-content.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,179 @@ +

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 +
+
+ +
+
+

2.2 추진과제

+

ARMS 도식화 모형

+

※ ARMS 적용 후 ALM단계별 설명

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
구분단계설명
1요구 사항 관리 + 요구사항( Issue)을 수집하고 정립 + 프로젝트 별 이슈 기반 추적 메트릭스를 통한 제품의 가시성 ( Dashboard ) 관리 +
2이슈 관리 + 프로젝트 별 이슈 기반 추적 메트릭스를 통한 제품의 가시성 ( Dashboard ) 관리 +
3문서 관리 + 요구사항( Issue) 기반 이슈 생성 및 관리(ex : 요구사항( Issue) 정립부터 코드 개발에 이르기까지의 전 과정 이슈 추적 관리) +
4문서 관리 + 프로젝트 문서를 온라인 화 및 관리 + 지식 저장소의 역할 +
5CI/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 분류 체계 시스템 - 객체의 구조적 활용 중심의 시스템

+ + +

A-RMS(atlassian Requirements Managment System) 는 제품(서비스)관점의 JIRA 전용 RMS입니다. 제품(서비스) 중심으로 Jira + Project를 분석하고, 제품(서비스)중심으로 요구사항을 Jira Project에 전파합니다.

+
+요구사항 정보 + +
Index: arms/docs/html/sds-overview.html =================================================================== diff -u --- arms/docs/html/sds-overview.html (revision 0) +++ arms/docs/html/sds-overview.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,121 @@ +

1. 프로젝트 개요

+

1. 개요

+

1.1 목적

+

이슈 기반 요구사항 관리 시스템을 개발하여, 제품별 요구사항의 생명주기(추가-채택-변경-삭제 ) 및 이력을 관리하고, 이와 함께 Atlassian ALM Tool Chain과 통합하여 Business Intelligence와 Atlassian 제품군에 없는 Requirement Management System 을 제공하는 RMS (for atlassian)시스템을 개발하는 것을 목표로 aRMS를 설계합니다.

+

1.2 범위

+

본 설계의 범위는 아래 시스템의 기능에 대한 설계입니다.

+ + + + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
구분기능
Auth System인증 시스템으로써, 권한 관리와 계정 관리 및 사용자 맞춤형 서비스를 제공합니다.
Product(Service) System제품(서비스)를 관리하며, 연관하는 ALM Toolchain 과 Mapping 하여 데이터 싱크를 제공한다.
Requirement System요구사항을 관리하며, 연관하는 제품(서비스)와 Mapping 하여, 제품 (서비스) - 요구사항 - ALM 을 연결한다.
Monitoring System다양한 어플리케이션의 조합으로 인하여, 각 시스템간의 성능 및 안정성을 보장하기 위하여 JAVA 기반 모니터링 을 지원한다.
+
+
+

1.3 관련 문서

+
+ + + + + + + + + + + + + + + + + + + + + +
구분기능
Project CharterProject Charter
SRSSRS
SDSSDS
+
+

1.4 개발자 스펙

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
구분필요 Skill
View Parthtml+css, Bootstrap, RequireJS, Bower, Grunt, AngularJS, jQuery, Qunit, Flex, Json, xml, BlazeDS
Server PartApache(modjk), Nginx, Tomcat, Resin, Jetty, SiteMash, Tiles, FreeMarker, Velocity
Framework PartStruts, Spring, iBatis, Hibernate, Spring-integration, Spring-security, Spring-Boot, Spring-DW, Spring-WebFlow, Spring-Data(JPA), Spring-Batch, Spring-WebServices, Spring-Mobile, Spring-MVC
Tool PartQuartz, Ehcache, MemCache, Redis, Apache-Commons, EgovFramework(Component)
CI Part Junit, Maven, Hudson, Jenkins, Bamboo, Nexus, Jira, Fisheye, Crucible, Confluence, Sonar
Database PartMySql, Oracle, MS-sql, postgres, Hadoop, Storm, Spark, Cassandra, MongoDB
Search Engine PartElastic Search, Kibana, Logstash, Beats, Grafana
Management PartPMBOK, MicroService, CBD, PLE, Prototype, PMS, ALM
Virtual Image PartDocker, Kubernetes(K8s), Docker Swarm
Microservice PartNetty - Zookeeper - Finagle - Kafka
+
+
+ Index: arms/docs/html/srs-functional-requirements.html =================================================================== diff -u --- arms/docs/html/srs-functional-requirements.html (revision 0) +++ arms/docs/html/srs-functional-requirements.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,427 @@ +

4. 제품(서비스) 기능 요구사항

+

4.1 A-RMS → Auth 기능 요구사항

+

* 본 프로젝트 범주는 A-RMS의 인증과 인가에 대한 내용을 다룹니다

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RequirementSummarize FunctionMiddle FunctionDetail function
인증 시스템 REQ ID : AUTH통합 계정 관리 시스템 REQ ID : SUMACCOUNT통합 로그인 사용자 검색 시스템 REQ ID : TOTAL + User Account Search Service + - 사용자 계정 정보를 검색하고 + - 사용자 세부정보를 확인할 수 있다. +
계정 그룹 관리 시스템 ( CRUD ) + REQ ID : ACCOUNT GROUPGroup Manager + - 사용자 계정을 그룹화 하기 위하여, + - 그룹을 정의 설정, 관리 할 수 있다. Group - User Mapper + - 사용자 계정을 그룹화 하고, + - 그룹을 대상으로 권한을 관리 할 수 있다.
통합 권한 관리 시스템 + REQ ID : SUMPERMISSON권한 관리 시스템 ( CRUD ) + REQ ID : GRANTGlobal - Permission Mapper + - 그룹을 대상으로 권한을 관리한다. + - 권한은 admin, user, anonymous 로 구분 Permission Manager + - 권한을 정의하고 관리한다. + - 권한관리는 admin user 만이 가능하다. Group - Permission Mapper + - 그룹을 대상으로 권한을 관리한다. + User - Permission Mapper + - 계정을 대상으로 권한을 관리한다.
로컬 계정 관리 시스템 + REQ ID : LOCALACCOUNT로컬 로그인 계정 관리 ( CRUD ) + REQ ID : LOCAL + Local Account Manager + - 로컬 계정을 관리한다. ( CRUD ) + - Global 권한과 Permission 권한을 관리
연동 계정 관리 시스템 + REQ ID : INTEGACCOUNTUser Directories 시스템 REQ ID : DIRECTORY + OAuth Manager + - OAuth를 지원하는 시스템과 연결 + - JIRA, Crowd, etc + LDAP Join Manager + - LDAP을 연결하고 계정 정보를 연결 +
사용자별 맞춤형 REQ ID : FORUSER개발자 및 프로젝트 진행 담당자 + REQ ID : DEV + + Project Collected Data Viewer + - 프로젝트 진행 담당자 관련 데이터 뷰어 - DashBoard Viewer +
기획자 및 프로젝트 이해 관계자 + REQ ID : PLAN + Project Requirement Progress Viewer - 요구사항 반영 진척도 뷰어 + - DashBoard Viewer +
고위관리자 REQ ID : BOSS + Product ( Service ) Progress Viewer - 제품 ( 서비스 ) 기반 진척도 뷰어 + - DashBoard Viewer +
Atlassian Tool Chain 담당자 + REQ ID : DEVOPS + Atlassian Tool Monitoring Viewer - 아틀라시안 제품 모니터링 뷰어 + - DashBoard Viewer +
+ +
+

4.2 A-RMS → Product & Service 기능 요구사항

+

* 본 프로젝트 범주는 aRMS Product(Service) 내부의 데이터를 분류하는 시스템을 jsTree framework를 활용하여 관리하는 범위에 대해 기술합니다 +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RequirementSummarize FunctionMiddle FunctionDetail function
분류 시스템 + REQ ID : CLASSFI제품(서비스) 와 + ALM Tool Chain Mapping 시스템 + REQ ID : PROSERVICE제품 (서비스) 관리 시스템 + + Product (Service) Manager + - 제품 ( 서비스 ) 등록 및 관리 ( CRUD ) +
제품 (서비스) - Issue Track 등록, 수정, 삭제, 조회 및 Mapping 시스템Product (Service) - Issue Track Mapper - 제품 ( 서비스 ) 와 이슈 프로젝트 연동
제품 (서비스) - Wiki 등록, 수정, 삭제, 조회 및 Mapping 시스템Product (Service) - Wiki Mapper - 제품 ( 서비스 ) 와 Wiki 공간 연동
제품 (서비스) - VCS 등록, 수정, 삭제, 조회 및 Mapping 시스템Product (Service) - VCS Mapper + - 제품 ( 서비스 ) 와 레파지토리 연동 +
제품 (서비스) - Code Review 등록, 수정, 삭제, 조회 및 Mapping 시스템Product (Service) - Review Mapper + - 제품 ( 서비스 ) 와 Review Project 연동 +
제품 (서비스) - CI/CD Tool 등록, 수정, 삭제, 조회 및 Mapping 시스템Product (Service) - CICD Mapper - 제품 ( 서비스 ) 와 Job 연동 +
제품(서비스) 와 ALM Tool Chain Data 수집 시스템 REQ ID : CRAWL + 제품 (서비스) - Issue Track 데이터 수집 Batch 시스템 + Product (Service) - Issue Track Mapper + - 등록된 배치 스케쥴러에 따라 Jira 에서 데이터를 수집
제품 (서비스) - Wiki 데이터 수집 Batch 시스템 + Product (Service) - Wiki Mapper + - 등록된 배치 스케쥴러에 따라 Confluence 에서 데이터를 수집 +
제품 (서비스) - VCS 데이터 수집 Batch 시스템 + Product (Service) - VCS Mapper + - 등록된 배치 스케쥴러에 따라 BitBucket ( Git ) 에서 데이터를 수집 +
제품 (서비스) - Code Review 데이터 수집 Batch 시스템 + Product (Service) - Review Mapper + - 등록된 배치 스케쥴러에 따라 Sonar Qube 에서 데이터를 수집 +
제품 (서비스) - CI/CD Tool 데이터 수집 Batch 시스템 + Product (Service) - CICD Mapper + - 등록된 배치 스케쥴러에 따라 Spinnaker, Jenkins 에서 데이터를 수집 +
+
+

4.3 A-RMS → Requirement 기능 요구사항

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RequirementSummarize FunctionMiddle FunctionDetail function
요구사항 관리 시스템 + 요구사항 등록 시스템 + 요구사항 등록 관리 + + + Requirement Registe Manager + - 요구사항 등록 관리자 + - Rich Edito, File Convertor, File Uploader +
요구사항 리뷰 시스템 + 요구사항 리뷰 관리 + Requirement Review Manager + - 요구사항 리뷰 관리자 ( with History ) + - Review 승인, 거절, 변경요청, Need Task +
요구사항 권한 관리 시스템 + 요구사항 권한 관리 + Requirement Permission Manager + - 요구사항 권한 관리자 + - 각 사용자별 등록, 리뷰, 승인, 변경 권한 +
요구사항 버전 관리 시스템요구사항 버전 관리 + Requirement Version Manager - 요구사항 버전 관리자 + - 요구사항 별 버전 등록
요구사항 승인 + 및 연동 시스템 처리요구사항 승인 후처리 관리 + Requirement Integration Manager + - 요구사항 승인 후처리 관리자 + - 요구사항 이슈등록, wiki 등록 (with format)
요구사항 맵핑 시스템요구사항 + - Jira Issue 맵핑 관리 시스템 + 요구사항 - 이슈트래커 연동Requirement Join IssueTrack Manager - 이슈트래커와 연동하여 요구사항을 등록 - Version 필수조건과 Date 관련 필수조건
요구사항 + - Confluence 맵핑 관리 시스템 + 요구사항 - WIKI 연동 + Requirement Join Wiki Manager + - 위키와 연동하여 요구사항 문서를 등록 - Restriction 관련 옵션 ( en or disable )
요구사항 + - BitBucket 맵핑 관리 시스템 + 요구사항 - VCS 연동 + Requirement Join VCS Manager + - 버전 관리 시스템과 연동하여 설정을 등록 - 요구사항 이슈 연동 추적 ( 참여인원 확인 )
요구사항 + - Sonarqube 맵핑 관리 시스템 + 요구사항 - Code Qaulity 연동 + Requirement Join CQ Manager + - 코드 퀄리티 시스템과 연동하여 설정을 등록 - 요구사항과 연동 이슈의 코드 퀄리티 추적 +
요구사항 + - CI/CD맵핑 관리 시스템 + 요구사항 - CI/CD 연동 + Requirement Join CICD Manager + - 빌드 배포 시스템과 연동하여 설정을 등록 - 요구사항과 배포 관계 연동 추적 +
요구사항 + - History 관리 시스템 + 요구사항 이력 관리 + Requirement History Manager + - 요구사항 이력 검색 + - Git Server 활용 요구사항 버전 관리 +
프로젝트 분석 시스템 + 요구사항 기반 진척 관리 시스템 + 제품(서비스) 진척 관리 + Product(Service) Progress Manager + - 제품(서비스) 의 수집 데이터를 활용 + - 요구사항 기반 진척도 DashBoard 관리 +
프로젝트 진척 알람 시스템 + 제품(서비스)진척 알람 관리 ( Mail, Messenger, etc ) + Product(Service) Alarm Manager - 제품(서비스) 의 수집 데이터를 활용 - Date 기반 진척도 관리 알람
+
+

4.4 A-RMS → Monitoring 기능 요구사항

+

* 본 프로젝트 범주는 aRMS가 Atlassian 제품군 및 Java Application을 대상으로, 인스턴스 모니터링을 관리하는 내용을 다룹니다.

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RequirementSummarize FunctionMiddle FunctionDetail function
모니터링 시스템 + Server 모니터링 + Metric Beat 활용 및 + Embed Elastic Search 연동 + + Metric Beat Manager + - cpu, mem, disk 등의 일반적인 서버 상태 체크 +
Application 성능 모니터링 + APM Server, Scouter 활용 및 Embed Elastic Search 연동 + APM, Scouter Manager + - JVM 의 상태 체크 +
Database Query 모니터링 + Packet Beat 활용 및 + Embed Elastic Search 연동 + Packet Beat Manager + - 네트워크 패킷 및 SQL Query 상태 체크 +
연동 시스템 모니터링 + + Heart Beat 활용 및 + Embed Elastic Search 연동 + Heart Beat Manager + - 연동된 시스템의 response 상태 체크 +
클라이언트 모니터링 + File Beat 활용 및 + Embed Elastic Search 연동 + File Beat Manager + - 각종 Log 시스템의 row를 활용한 상태 체크 +
문제 탐지 알람 시스템 + Monitoring Alarm Manager - 각 모니터링 데이터 기준 + - 임계점 설정 이후 알람 + Alarm Manager + - 임계점을 설정하여 알람 시스템을 연동 후 상태값 데이터를 Notification + +
+
Index: arms/docs/html/srs-overview.html =================================================================== diff -u --- arms/docs/html/srs-overview.html (revision 0) +++ arms/docs/html/srs-overview.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,186 @@ +
+

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가상 Docker1 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

+ +
Index: arms/docs/html/srs-serviceview.html =================================================================== diff -u --- arms/docs/html/srs-serviceview.html (revision 0) +++ arms/docs/html/srs-serviceview.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,215 @@ +

2. 제품(서비스) 조망

+

2.1 제품(서비스) 구성도

+

제품(서비스) 조망 구성의 시작은 Business Architecture 입니다.

+

input은 project charter를 활용하면서, 기본적인 요구사항을 구체화합니다.

+

구체화된 요구사항에 맞춰서 비지니스 아키텍쳐가 이 요구사항을 대응할 수 있어야 하고, 추상화 단계는 최상위 레벨인 시스템 수준의 대단위 모듈로 대응 할 수 있어야 + 합니다.

+제품(서비스) 구성도 +

input인 비지니스 아키텍쳐로 부터, 세부적인 요구사항의 기능을 대응할 시스템 하위 컴포넌트 레벨의 모듈을 구성하고, 해당 모듈의 핵심적인 기능을 기록하도록 합니다.

+ +

2.2 제품(서비스) 동작 방식

+

2.2.1 인증 시스템 모듈 동작 방식

+

2.2.1.1 통합 계정 관리 시스템

+ + +

2.2.1.2 통합 권한 관리 시스템

+ +
+

2.2.1.3 로컬 계정 관리 시스템

+ +
+

2.2.1.4 연동 계정 관리 시스템

+ +
+

2.2.1.5 사용자별 맞춤 시스템

+ + +

2.2.2 제품(서비스) 관리 시스템 모듈 동작 방식

+

2.2.2.1 제품(서비스) 관리 시스템

+ + +

2.2.2.2 제품(서비스) ALM 간 Mapping 시스템

+ +

2.2.2.3 제품(서비스) - 요구사항 - Jira Issue 맵핑 관리 시스템

+ +

2.2.2.4 제품(서비스) - 요구사항 - Confluence 맵핑 관리 시스템

+ +

2.2.2.5 제품(서비스) - 요구사항 - Bitbucket 맵핑 관리 시스템

+ +

2.2.2.6 제품(서비스) - 요구사항 - Sonarqube 맵핑 관리 시스템

+ +

2.2.2.7 제품(서비스) - 요구사항 - CI/CD 맵핑 관리 시스템

+ +

2.2.3 요구사항 관리 시스템

+ +

2.2.3.1 요구사항 등록 시스템

+ +

2.2.3.2 요구사항 리뷰 시스템

+ +

2.2.3.3 요구사항 권한 관리 시스템

+ +

2.2.3.4 요구사항 버전 관리 시스템

+ +

2.2.3.5 요구사항 승인 및 연동 시스템 처리

+ +

2.2.3.6 모니터링 시스템

+ +

2.2.6.1 Server 모니터링 시스템

+ +

2.2.6.2 Application 성능 모니터링 시스템

+ +

2.2.6.3 Database 모니터링 시스템

+ +

2.2.6.4 연동 시스템 모니터링

+ +

2.2.6.5 클라이언트 모니터링 시스템 +

+ +

2.2.6.6 장애 탐지 알람 시스템 +

+ +
Index: arms/docs/html/utilization-plan.html =================================================================== diff -u --- arms/docs/html/utilization-plan.html (revision 0) +++ arms/docs/html/utilization-plan.html (revision b7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63) @@ -0,0 +1,53 @@ +

3. 활용 방안

+

3.1 기대 효과

+

ARMS 적용 후 순기능

+ + +

ARMS 적용 후 역할 별 효과

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

+ + Checkboxes and Radio +

+
+
+
+
+
+ +
+ + + +
+
+
+ +
+ + + +
+
+
+ +
+
+ + +
+
+
+
+ + + +
+
+
+
+ +
+ + + +
+
+
+ +
+ + + +
+
+
+ +
+
+ + +
+
+
+
+ + + +
+
+
+
+ +
+ + +
+
+
+
+
+
Index: arms/img/Document/requirementInfo.png =================================================================== diff -u -r7307f90f91cf368f8085403e0f0646ae05bda84d -rb7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63 Binary files differ Index: arms/img/Document/srs_01.png =================================================================== diff -u -rde070d6b74a1e97b6a67f16e7d76fc32b893f7ef -rb7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63 Binary files differ Index: arms/img/Document/srs_02.png =================================================================== diff -u -rde070d6b74a1e97b6a67f16e7d76fc32b893f7ef -rb7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63 Binary files differ Index: arms/img/Document/systemConfigurationDiagram.png =================================================================== diff -u -r7307f90f91cf368f8085403e0f0646ae05bda84d -rb7f2d2eb2902d9d98144a5c5c3100a1fd0c18b63 Binary files differ