• 목록
• 답변
• 글쓰기

공통

1. ARMS 요구사항 생성 시 에는 열림을 default로 생성, ALM 이슈의 초기 상태가 기본으로 설정되도록 반영 처리
2. 고객사별 상태 생성할 수 있도록 동적 상태 설정
   1. 현재 고정된 상태 사용에 대한 코드 변경
   2. 기존 아이콘, 버튼 색상 등 반영 안 됨

상태 매핑 ALM 상태 업데이트 지원

1. 생성한 ARMS 요구사항 상태와 ALM 상태의 매핑 설정을 하도록 지원을 해야한다.
2. 매핑시키도록 유도가 필요하다
   1. 매핑 설정 - ARMS 요구사항 상태 카테고리 - ARMS 상태 - ALM 상태 매핑 순서로 유도

   2. 매핑이 되어있지 않은 ARMS 상태일 시에는 ALM 이슈 상태 변화가 없다.

3. ARMS 상태를 ALM 이슈 상태의 매핑 후 단방향 업데이트 시

   1. ARMS의 상태의 변화가 있을 때 매핑된 상태에 의해서 ALM 이슈의 상태 변화가 일어난다.

      1. ALM 이슈가 완료로 되어있는데 ARMS 상태 변경에 의해서 매핑된 상태로 변경된 경우 개발자는 모르고 진행할 수 있다. 이럴 경우에 대한 고민
         1. 이미 해결되었는데 진행중으로 ARMS의 상태를 바뀔 경우 ALM 이슈의 데이터에도 반영이 일어난다. 괜찮은지?
4. ARMS 상태와 ALM 이슈 상태의 매핑 후 양방향 업데이트 시
   1. ALM의 이슈의 상태를 가져와서 ARMS의 상태로 반영되면 요구사항의 상태가 ALM 이슈의 상태로 반영된다는 건 ALM 이슈의 상태에 의해서 요구사항의 상태가 바뀔 수 있다. → 관리자 입장에서 변경이 된 상태가 아닐 수 있다.
   2. 스케줄러를 통해서 ALM 이슈의 상태를 ARMS의 상태에 업데이트 시킨다.

      1. 현재는 N개의 이슈 중 마지막 이슈의 상태와 매핑된 ARMS의 상태로 업데이트가 된다.

         어떻게 바꿔야할지? N개의 ALM 이슈들의 상태들 데이터 기반

      2.  통계로 ARMS의 상태를 업데이트 시키도록 변경?
         

      3. 1:1의 경우에는 문제가 되지 않음

5. 상태 매핑이 되어있을 지라도 업무 흐름에 의해서 ALM의 이슈 상태가 바뀌지 않을 수도 있다.
   1. 실패에 대한 알림 처리
   2. 레드마인은 업무 흐름을 조회하는 API가 없다.
   3. 업무 흐름에 맞게 매핑을 유도 해야 한다.

클라우드 지라 이슈 상태 매핑 설계

1. 프로젝트 - 이슈 유형 - 이슈 상태
2. 이슈상태와 이슈유형 매핑
3. 선택된 이슈 유형의 상태만 보여준다. / 이슈유형이 선택되지 않은 경우에는 해당 이슈 상태의 데이터는 없는 걸로 표시 혹은 알림 창
4. 프로젝트의 이슈 상태의 경우(이슈 유형별로 가지지만 그 중 공통으로 사용중인 상태의 경우 고려가 필요 - 데이터 확인)
   1. 매핑을 여러 이슈 유형 아이디와 할 수 있도록 반영
   2. [”10000”, “10001”, “10002”] - c_pdservice_versions_link와 같은 형태
   3. 해당 프로젝트의 이슈의 상태를 수정 시

      1. 프로젝트의 선택된 이슈 유형(c_check가 true)의 이슈 유형 ID를 조회

      2. 프로젝트의 이슈 상태 목록을 가져온 후 1에서 가져온 이슈 유형 ID를 포함하는 경우의 상태를 모두 가져와 화면에 출력 - 선택된 이슈 유형의 이슈 상태목록을 가져올 수 있다.

         

         c_issue_type_mapping_id 추가 후 클라우드 이슈 상태 쪽 적용 후 확인

         

         1. 선택된 이슈 유형 arms-requirement 에 사용 가능한 이슈 상태만 보여주고 매핑