자산 개발 및 라이프사이클

자산을 개발할 때 관리되는 변경사항은 계획에서 프로덕션으로 이동합니다. 이러한 단계는 모든 자산이 충족해야 하는 표준과 요구사항을 관리하기 위해 저장소 및 커뮤니티 관리자가 사전 정의합니다.

라이프사이클을 사용하는 자산 개발에 대해 학습하려면 다음 절을 참조하십시오.

라이프사이클 단계(Phase)와 반복

개발 사이클에는 단계(Phase)와 반복이 포함됩니다. 단계(Phase)와 반복을 통해 개발 아티팩트를 작성하고 재사용할 수 있습니다. 개발 아티팩트들 간에 관계가 존재할 수 있습니다. 다른 개발 사이클에서 작성된 개발 아티팩트를 참조하고 사용할 수도 있습니다. 이러한 개발 아티팩트는 웹 사이트에 있거나 사용자 정의 저장소에 있을 수 있습니다.

자산에는 개발 아티팩트 파일 또는 이들에 대한 참조가 포함될 수 있습니다. 예를 들어, 원격 아티팩트를 자산 저장소에 자산 아티팩트로 업로드할 수 있습니다. 또한 자산 아티팩트는 저장된 저장소에 있는 원격 아티팩트에 대한 참조가 될 수도 있습니다. 적절한 아티팩트와 관계 세트가 자산 저장소에 표시됩니다. 팀은 저장소에 액세스하여 자산에 대한 사용법 시나리오를 관리하고 검색하고 볼 수 있습니다.

자산 라이프사이클을 사용하여 할 수 있는 일

사용자 정의 라이프사이클은 유연하며 여러 용도로 사용될 수 있습니다.
  • 시간 경과에 따라 개발할 자산에 대한 워크플로우 제공: 모든 라이프사이클은 단일 워크플로우를 사용합니다. 저장소 관리자는 마스터 라이프사이클을 작성할 때 워크플로우를 정의합니다. 워크플로우는 상태와 상태 간의 상태 전이로 구성됩니다. 예를 들어, 표준 워크플로우에는 세 가지 상태가 있습니다. 자산은 초안 상태로 시작된 후 검토 상태로 이동할 수 있습니다. 자산을 검토하거나 승인한 후 승인됨 상태로 이동할 수 있습니다. 각 상태에 대해 자산을 보거나 검토하거나 투표할 수 있는 사람을 수정할 수 있으며 실행할 정책을 구성할 수 있습니다.

    제품에 포함된 워크플로우를 사용하거나 저장소에 대해 추가 워크플로우를 작성할 수 있습니다.

  • 라이프사이클을 시작할 수 있는 자산 지정: 특정 자산 유형 또는 카테고리화의 자산이 특정 마스터 또는 커뮤니티 라이프사이클을 시작하도록 지정하는 조건을 구성할 수 있습니다. 예를 들어, 문서 유형의 자산은 한 마스터 라이프사이클을 시작하도록 지정하고 프리젠테이션으로도 카테고리화된 문서 유형의 자산은 다른 마스터 라이프사이클을 시작하도록 지정할 수 있습니다. 프리젠테이션 마스터 라이프사이클을 사용하는 커뮤니티 레벨 라이프사이클에서 슬라이드로 카테고리화된 자산은 이 라이프사이클을 사용하도록 하는 조건을 추가할 수 있습니다.
  • 라이프사이클을 통해 자산을 안내하는 사용자 지정: 저장소, 커뮤니티, 자산 레벨의 각 라이프사이클에 대해 한 사용자를 라이프사이클 관리자로 지정할 수 있습니다. 라이프사이클 관리자는 라이프사이클을 조정하고 자산의 검토자를 관리하여 라이프사이클을 통해 자산을 안내합니다. 라이프사이클 관리자에 대한 자세한 정보는 자산에 대한 라이프사이클의 추가적인 역할을 참조하십시오. 단일 자산의 라이프사이클을 조정하는 방법에 대한 자세한 정보는 개별 자산의 라이프사이클 수정을 참조하십시오.
  • 자산에 주석을 추가하거나 자산을 수정하거나 승인할 사용자 지정: 라이프사이클의 워크플로우 내에 있는 모든 상태에 대해 해당 분야 전문가 또는 기타 흥미있는 부서가 검토자가 되도록 지정할 수 있습니다. 검토자는 자산을 보고 주석을 추가하고 선택적으로 수정하거나 투표할 수 있습니다. 검토자에 대한 자세한 정보는 자산에 대한 라이프사이클의 추가적인 역할을 참조하십시오.
  • 자산을 테스트하거나 수정하는 정책 구성: 자산의 모든 상태에서 정책을 구성할 수 있습니다. 정책은 자산을 테스트하거나 수정할 수 있는 스크립트 또는 매크로입니다. 예를 들어, 자산을 테스트하여 이름이 고유한지 확인할 수 있습니다. 정책을 실행할 시기와 빈도를 제어할 수 있습니다. 정책을 사용하여 제한사항을 강제 실행하고 프로그래밍 방식으로 자산을 통제할 수 있습니다. 사용 가능한 정책과 구성 방법에 대한 자세한 정보는 Rational Asset Manager에서 라이프사이클에 대한 정책을 참조하십시오.
  • 자산을 상태 간에 이동하기 위한 요구사항 구성: 모든 상태 전이에 대해 자산을 상태 간에 이동하기 위해 충족해야 하는 종료 조건을 구성해야 합니다. 예를 들어, 자산을 검토 상태에서 승인됨 상태로 이동하려면 최소한 세 명의 검토자가 자산을 승인해야 하고 모든 테스트 정책을 통과해야 하도록 요구할 수 있습니다.

자산 라이프사이클을 사용하는 경우

자산 라이프사이클은 다음과 같은 상황에서 유용합니다.
  • 자산이 필수 워크플로우에서 이점이 있는 경우: 필수 라이프사이클 워크플로우에서 이점이 있는 자산에는 비즈니스 케어 문서, 테스트 계획, 소프트웨어 컴포넌트와 서비스, 제품 빌드와 기준선, 회사 브랜딩 컴포넌트(예: 로고, 스타일시트, 템플리트)가 포함됩니다.
  • 자산을 검토하려는 경우: 라이프사이클 관리자는 임의 상태의 자산을 보거나 수정하거나 투표할 검토자를 초대할 수 있습니다.
  • 라이프사이클에 대해 정책을 사용하려는 경우: 라이프사이클에 대해 정책을 사용하여 커뮤니티의 자산을 효율적으로 관리할 수 있습니다. 라이프사이클의 정책은 자산 유형에 대해 구성할 수 있는 많은 제한조건과 유사합니다.
  • 서비스 지향 아키텍처(SOA)를 사용 중인 경우: Rational® Asset Manager에는 SOA 프로세스를 지원하는 라이프사이클 패키지가 포함되어 있습니다. 라이프사이클을 사용하여 해당 프로세스를 IBM® WebSphere® Service Registry and Repository와 통합할 수 있습니다.

자산 라이프사이클에 대한 추가 역할

사용자 정의 라이프사이클을 작성하는 경우, 추가 역할이 구성됩니다.
  • 라이프사이클 관리자: 커뮤니티에 대해 사용자 정의 라이프사이클을 구성하는 동안 사용자 또는 사용자 그룹에 라이프사이클 관리자 역할을 지정할 수 있습니다. 자산의 라이프사이클 관리자는 다음과 같은 추가적인 권한을 얻습니다.
    • 자산을 검색하고 보고 다운로드할 수 있습니다.
    • 자산을 수정할 수 있습니다.
    • 내 대시보드 페이지의 관리할 자산 섹션에서 자산을 볼 수 있습니다.
    • 자산의 검토 페이지에서 주석을 그대로 둘 수 있습니다.
    • 검토자를 추가 또는 제거하고 검토자의 권한을 변경하고 정책을 추가 또는 제거하고 라이프사이클 상태 간 상태 전이 조건을 변경하여 자산의 라이프사이클을 조정할 수 있습니다.
  • 검토자: 사용자 정의 자산 라이프사이클의 각 상태에 대해 사용자 또는 사용자 그룹을 검토자로 추가할 수 있습니다. 커뮤니티 관리자는 커뮤니티에 대해 사용자 정의 라이프사이클을 구성할 때 검토자를 추가하거나 제거할 수 있습니다. 라이프사이클 관리자는 개별 자산의 라이프사이클을 수정할 때 검토자를 추가하거나 제거할 수 있습니다. 자산의 검토자는 다음과 같은 추가적인 권한을 얻습니다.
    • 자산을 검색하고 보고 다운로드할 수 있습니다.
    • 자산의 검토 페이지에서 주석을 그대로 둘 수 있습니다.
    • 승인자 선택란이 선택된 경우 검토 페이지에서 투표하여 자산을 승인하거나 거부할 수 있습니다. 승인과 거부는 저장되며 상태 변경 조건으로 사용될 수 있습니다. 예를 들어, 자산은 세 명 이상의 검토자가 승인에 투표한 경우에만 검토에서 승인으로 변경될 수 있습니다.

라이프사이클 수정

자산 레벨에서, 마스터 및 커뮤니티 라이프사이클에 대한 요구사항은 자산 라이프사이클에서 상속됩니다. 라이프사이클 관리자는 자산에 대한 요구사항을 추가하여 저장소 및 커뮤니티 관리자가 지정한 요구사항을 보충할 수 있습니다.

이 트리 다이어그램은 마스터 라이프사이클 요구사항이
커뮤니티 라이프사이클에 의해 상속되는 방법을 보여줍니다. 그런 다음
커뮤니티 관리자는 요구사항을 커뮤니티 라이프사이클에 추가할 수 있습니다.
마스터 및 커뮤니티 라이프사이클 요구사항은 자산 라이프사이클에 의해
상속됩니다. 그런 다음 라이프사이클 관리자는 자산 라이프사이클에
요구사항을 추가할 수 있습니다.

예를 들어, 라이프사이클 관리자는 특정 자산에 대한 추가 검토자를 초대할 것을 결정할 수 있습니다. 특정 자산의 요구사항에 더 일치되도록 하기 위해 정책 구성 방법을 조정할 수도 있습니다.

자산의 라이프사이클 구성에 대한 변경사항은 해당 자산에만 적용됩니다. 변경사항은 동일한 마스터 또는 커뮤니티 라이프사이클을 사용 중인 커뮤니티의 다른 자산에 적용되지 않습니다. 자산에 대해 동일한 조정을 종종 수행하는 경우, 커뮤니티 관리자가 커뮤니티 레벨에서 라이프사이클을 조정하도록 할 수 있습니다.

다음과 같은 방식으로 라이프사이클 관리자는 개별 자산의 라이프사이클을 조정할 수 있습니다.
  • 자산의 라이프사이클 추가 또는 제거
  • 각 상태의 검토자 추가 또는 제거
  • 각 상태의 검토자 권한 변경
  • 각 상태의 정책 추가 또는 제거
  • 각 상태의 정책 재구성
  • 상태 간의 상태 전이 재구성
개인 자산 레벨에서, 다음의 라이프사이클 측면은 변경할 수 없습니다.
  • 라이프사이클의 워크플로우
  • 라이프사이클을 입력할 자산의 조건

내재된 자산 라이프사이클

커뮤니티에 제출된 자산이 라이프사이클 또는 다른 사용자 정의 검토 프로세스의 요구사항을 충족하지 않는 경우, 자산은 제출됨과 승인됨의 두 가지 상태만 있는 단순 라이프사이클을 시작합니다. 자산의 소유자와 모든 관리자는 자산의 라이프사이클 관리자입니다.

내재된 라이프사이클을 시작하는 자산의 라이프사이클은 수정할 수 있지만 커뮤니티 내의 모든 자산에 대해 이 라이프사이클을 수정할 수는 없습니다.

처분 라이프사이클

내재된 라이프사이클을 포함하여 라이프사이클에 있는 모든 자산에 대해 자산을 별도의 처분 라이프사이클인 내재된 자산 처분 라이프사이클로 보낼 수 있으며, 이 라이프사이클은 두 단계로 구성됩니다.
  • 처분 전: 처분 전 상태는 처분 전 상태를 시작하기 전에 자산이 있던 라이프사이클의 상태에서 권한, 라이프사이클 관리자, 검토자를 복사합니다. 모든 소유자, 라이프사이클 관리자, 검토자, 관련 자산의 소유자, 자산을 다운로드한 임의의 사용자가 자산이 사전 사용 중지됨 상태에 진입했다는 이메일을 수신합니다.
  • 처분됨: 자산이 처분됨 상태인 경우, 모든 관리자와 라이프사이클 관리자는 자산을 찾거나 다운로드할 수 있습니다.

모든 라이프사이클 상태에서 자산을 처분 라이프사이클로 보낼 수 있습니다. 자산이 처분 라이프사이클에 있는 동안 해당 라이프사이클 관리자는 해당 자산에 대해 처분 라이프사이클을 수정할 수 있습니다. 이 라이프사이클의 상태에서 자산을 복원할 수 있습니다. 자산을 복원하면 커뮤니티로 다시 제출됩니다. 자산 유형 또는 자산의 카테고리를 기반으로 적절한 라이프사이클의 첫 번째 상태가 시작됩니다.

라이프사이클 및 V7.2 전 검토 프로세스

7.2보다 이전의 제품 버전에서는 검토 프로세스를 사용하여 시간 경과에 따른 자산 개발을 관리할 수 있습니다. 버전 7.2 이후에서는 라이프사이클을 사용하여 시간 경과에 따라 자산을 개발할 수 있습니다.

기존 검토 프로세스에는 여전히 액세스할 수 있지만 새로 작성할 수는 없습니다. 대신 더 사용자 정의할 수 있고 유연한 라이프사이클을 사용하십시오. 다음 표는 라이프사이클과 검토 프로세스의 차이점을 나타냅니다.
표 1. V7.2 이후 라이프사이클과 V7.1.1.1 이전 검토 프로세스의 차이점
기능 검토 프로세스(V7.1.1.1 이전) 라이프사이클(V7.2 이후)
상태와 상태 전이의 수 단일 워크플로우가 포함됩니다. 포함된 상태와 상태 전이의 수가 다양한 기본 제공 워크플로우 중에서 선택할 수 있습니다. 또는 IBM Rational Team Concert™를 사용하여 더 많은 상태와 상태 전이를 작성할 수 있습니다.
상태의 유연성 각 상태에는 수정할 수 없는 권한에 대한 연관된 제한사항이 있습니다. 예를 들어, 자산의 소유자와 관리자만 초안 상태의 자산을 볼 수 있습니다. 모든 상태에 대해 권한, 검토자, 정책을 사용자 정의할 수 있습니다.
상태 전이 사용자는 자산의 상태를 변경하도록 수동으로 요청해야 합니다. 자산을 한 상태에서 다른 상태로 이동할 시기를 제어하는 복잡한 조건을 작성할 수 있습니다. 사용자가 지정하는 조건을 자산이 충족하는 경우 상태 전이가 자동으로 발생할 수도 있습니다.
라이프사이클을 통해 자산을 안내하는 사용자 검토 프로세스를 작성하는 경우 검토 위원회, 즉 자산의 검토에 대한 최종 승인이 있는 사용자 목록을 작성합니다. 사용자 커뮤니티의 기본 제공 검토 위원회 역할을 수정하여 검토 위원회의 권한을 수정할 수 있습니다. 라이프사이클을 작성하는 경우 개별 자산에 대한 라이프사이클을 조정하고 더 많은 검토자를 초대할 수 있는 라이프사이클 관리자를 지정하십시오. 라이프사이클 관리자는 사용자가 수정할 수 없는 사전 정의된 권한 세트가 있습니다.
자산을 검토하는 사용자 검토 상태에서 검토자는 자산을 보고 투표할 수 있으며 자산에 대한 포럼에 액세스할 수 있습니다. 검토 프로세스를 구성할 때 검토자를 선택할 수 있습니다. 자산에 대한 검토 위원회는 자산이 계획 검토 상태인 동안 검토자를 선택할 수 있습니다. 라이프사이클의 모든 상태에 대해 자산을 보고 주석을 추가하고 선택적으로 자산을 수정하거나 투표할 수 있는 검토자를 추가할 수 있습니다.
정책이 작동하는 방식 정책 프로세스는 검토 프로세스와 별도로 구성되어야 합니다. 일반적으로 자산에 대한 조치를 시도하기 직전에 정책을 실행하도록 구성합니다. 정책이 실패하는 경우에는 해당 조치를 수행할 수 없습니다. 예를 들어, 정책은 자산이 승인되거나 검토를 위해 제출되거나 삭제되거나 처분되거나 아카이브되기 전에 실행될 수 있습니다. 정책은 라이프사이클의 주요 컴포넌트입니다. 임의 상태에서 다양한 횟수로 실행되도록 정책을 구성할 수 있습니다. 예를 들어, 특정 상태의 자산이 수정될 때마다 실행되는 정책이 있습니다. 또는 자산이 특정 상태를 시작한 후 지정된 시간이 경과한 후에 실행되는 정책도 있습니다. 정책의 결과를 사용하여 자산이 한 상태에서 다른 상태로 변경될 수 있는 시기를 제어할 수 있습니다.
날짜가 지나거나 사용되지 않는 자산에 대한 액세스 제한 처분 및 아카이브됨 상태는 승인됨 및 현재 상태의 자산에서만 액세스 가능합니다. 모든 라이프사이클에서 모든 상태의 자산은 언제든지 처분 라이프사이클을 시작할 수 있습니다.

자산이 라이프사이클 또는 검토 프로세스를 시작할 수 있는 경우

하나의 자산은 단일 라이프사이클 또는 검토 프로세스에 의해서만 통제될 수 있습니다. 자산을 커뮤니티에 제출하면 자산은 다음과 같은 순서로 라이프사이클 또는 워크플로우를 시작합니다.
  1. 우선 자산을 검사하여 저장소에서 마스터 라이프사이클의 파트가 될 수 있는지 판별합니다.
  2. 그런 다음, 자산을 검사하여 커뮤니티 라이프사이클의 파트가 될 수 있는지 판별합니다.
  3. 자산에 적용되는 라이프사이클이 없는 경우, 자산을 검사하여 저장소 또는 커뮤니티에서 작성된 검토 프로세스의 파트가 될 수 있는지 판별합니다.
  4. 적용되는 검토 프로세스가 없는 경우, 자산은 내재된 단순 라이프사이클 프로세스를 시작합니다.

예: 표준 라이프사이클 워크플로우

다음 그림은 자산 라이프사이클에 대한 워크플로우의 예입니다. 워크플로우에는 자산 유형의 상태와 조치가 포함되며 관리를 위한 자산 라이프사이클의 파트로 구성될 수 있습니다. 사용자는 워크플로우의 특정 조치에 정책을 적용하고 각 조치를 완료하도록 권한 부여된 사용자를 지정하거나 검토 프로세스의 파트가 될 수 있습니다.

그림은 표준 워크플로우 유형을 표시합니다.

예: 자산 개발과 라이프사이클

자산 개발은 순환적입니다. 자산 워크플로우의 파트로서, 자산은 해당 라이프사이클에서 상태를 통해 이동할 수 있습니다. 주어진 자산 유형에 대해 관리 모델을 설정하여 자산을 제출, 승인 또는 거부, 공개할 수 있는 사용자와 그룹을 제어하십시오. 사람들이 자산을 변경하고 반복하는 경우 개발 주기는 다음 단계를 통해 이동합니다.

  1. 누군가가 현재 솔루션에서 차이 또는 문제점을 식별합니다.
  2. 설계자 또는 프로젝트 리더가 Rational Asset Manager 저장소에서 자산을 검색하여 문제점이 있는 솔루션을 찾습니다. 솔루션 또는 솔루션의 일부가 사용 가능한 경우에 이는 새로 제안된 솔루션의 아키텍처에 포함됩니다.
  3. 설계자 또는 프로젝트 리더가 솔루션에 대한 정규 요구사항을 작성합니다. 정규 요구사항에는 검색 중에 찾은 자산이나 이전 결함, 개선에 대한 요청 또는 지난 프로젝트의 태스크 목록이 포함될 수 있습니다.
  4. 설계자는 자산에 대한 스펙을 작성합니다.
  5. 설계자는 스펙을 자산 관리 보드에 제출합니다. 솔루션에 대한 모든 주요 이해 당사자가 정규 검토를 완료합니다. 이 검토에서 이해 당사자는 솔루션 디자인이 완전한지와 이전 솔루션의 차이 또는 문제점을 다루는지를 확인합니다.
  6. 개발 팀이 솔루션을 개발하고 해당 솔루션을 자산으로 제출합니다. 개발된 솔루션의 검토에서 검토자는 제출된 자산이 완전한 솔루션 또는 구현인지와 이전 솔루션의 차이 또는 문제점을 해결하는지를 확인합니다.
  7. 개발된 자산이 승인되면 해당 솔루션의 자산은 라이프사이클 워크플로우의 다음 단계로 이동합니다. 다음 단계에서 관리 보드는 자산을 검토하고 투표하여 자산을 사용 가능한 것으로 만들지 여부를 결정합니다. 모든 주요 이해 당사자가 자산을 검토하고 투표해야 합니다.
  8. 검토 위원회가 자산을 승인하도록 투표하면 회사 내의 다른 사람들이 자산을 사용하고 배치할 수 있도록 공개됩니다.

피드백