pdService 로 이름을 고정합니다.
reqAdd 는 동적 테이블로 운용됩니다.

패키지명은 무조건 소문자 통일
클래스명은 카멜 케이스 통일

sqlmapper 셀렉터의 sqlmap 네임스페이스는 무조건 소문자 ( 패키지 명에 해당 )

기업의 부채율은 부담을 가중 시킬 것이고,
효율 경영을 위한 활동을 할 것이다. ( 컨설팅 등 )
암암리에 진행하는 구조조정이 있을 것이고,
표면적인 정량적 평가에 의한 구분이 병행하고 싶을 것이다.
그 데이터 확보에 어려움을 겪을 것이고
여기에 a-RMS는 그 답을 제시해 줄 것이다.
기회다. 왜냐하면 a-RMS는 프로세스를 변화시키는 욕구를 충족시킬 것이고,
정량적 평가와 함께 회사에 유리한 지표를 제공할 테니까.

a-RMS 의 JIRA Issue Type 에 관하여
1.  지라 이슈 타입 ( 요구사항 이슈 타입이 없으니까 )
    만들어야 할 경우 지라 버전이 Major 7 이상이어야 한다.
    
2.  지라 5,6 버전은 메뉴얼 문서를 주고 admin 이 직접 요구사항 이슈 타입을
    만들게 유도하고, a-RMS에서 이슈타입을 써치하는 ( 조회하는 ) 방식으로 구현
    
3.  이것도 싫은 경우가 발생할 수 있는데,
    5,6 버전이라면 아마 내부적으로도 오래동안 쓴 케이스 일 것이므로,
    보수적일 가능성이 있다. 공식 a-RMS 플러그인을 만들어서 
    이슈 타입을 생성해 주는 방식을 고려 해야 할 것이다 ( 우선순위 낮음 )
    
[ 레퍼런스 문서 ]
https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-types/#api-rest-api-3-issuetype-id-get
https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-types/#api-rest-api-2-issuetype-post
https://docs.atlassian.com/software/jira/docs/api/REST/8.1.0/#api/2/issuetype-createIssueType
https://docs.atlassian.com/software/jira/docs/api/REST/5.2.11/#api/2/issuetype-createIssueType
[ a-RMS의 JIRA 전체 흐름 ]
1. 사용자가 a-RMS에 제품(서비스)를 만들고
2. 해당 제품의 버전을 구성하면 -> JIRA에 반영을 해야 한다.
3. 아직은 JIRA 연결이 되어 있지 않기 때문에 대기 상태일거고
4. 제품(서비스) - 버전 - JIRA 연결을 생성하면,
5. 해당 JIRA 프로젝트에 Version 을 생성해 준다. ( 예 : 제품(서비스)-Version ) 
6. 5번 과정이 끝나면 바로 요구사항 이슈 타입이 존재하는지 확인하고
7. 사용자에게 지라 버전이 5,6 이라면 admin 에게 요구 사항 이슈 타입을 생성해 달라고 요청을 유도한다.
8. 요구사항이 구성되기 시작하면, 요구사항 이슈 타입으로 설정된 프로젝트에 이슈를 생성한다.
9. 생성 후 이슈 링크를 확인하고 스크랩을 해 온다.
10. 지라 프로젝트 생성은 지원하지 않는다.
11. 이미 있는 프로젝트에 연결을 지원한다. ( a-RMS 백오피스에서 지원을 하는건 고려 중 )

12. 이후 주기적인 요구사항 이슈를 수집하여 ELK 에 적재한다. 

따라서 다음과 같은 테스트 케이스가 선행되어야 한다.

[ 테스트 케이스 ]
1. Jira Project 를 로드하여 a-RMS에 적재 할 수 있어야 한다.
2. 적재된 a-RMS Jira Project는 a-RMS Jira 연결 관리에서 볼 수 있어야 한다.
3. a-RMS 의 제품(서비스) - 버전 - JIra 연결 구성이 이루어 지면
4. 해당하는 Jira Project 에 "aRMS-제품(서비스)-Version" 이 존재하는지 확인한다.
5. 없으면 생성한다.
6. 해당 Jira Project 에 요구사항 이슈 타입을 쓸 수 있는 버전인지 확인한다.
7. 7 이상의 버전이면, 요구사항 이슈 타입이 없으면 생성해 준다.
8. 5,6 버전이면, 알림 창을 띄워서 admin 이 요구사항 이슈 타입을 생성하도록 유도
9. a-RMS에 요구사항이 등록되고 , 리뷰어가 리뷰를 완료하면,
10. 주기적으로 요구사항을 확인하여, Jira 에 이슈를 생성한다. ( 요구사항 타입 )
11. 이후 스케쥴러를 동작해서 요구사항 이슈를 수집하여 ELK 에 적재한다. ( 릴레이션, Sub-TASK 포함 )
히스토리와 기타 등등 모든 수집 대상을 ELK 에 비정형으로 적재한다.

[ 이슈 타입에 대한 로직 ]
1. 지라 글로벌 이슈 타입을 써치 할 수 있다.
2. 지라 글로벌 요구사항 타입을 생성할 수 있다.
3. 이슈 스키마에 요구사항 타입을 맵핑 할 수 있다.

[ 이슈 발생 ]
1.  제품(서비스) - 버전은 단일 연결 관계이지만, 
    버전 - 지라 연결은 1:N의 관계이다.
    따라서 지라 프로젝트에는 동일한 버전이 등록될 수 있고 이걸 관리해야 한다.
    
    따라서 버전에 추가로 컬럼을 넣어서
    지라 프로젝트에 등록된 버전을 관리 할 수 있어야 한다.
    
    단순 처리 보다는
    지라 프로젝트 - 버전 정보 - 이슈 생성 정보를 묶어서 관리하는건?