프로세스 필수사항
이 페이지는 프로젝트의 특정 요구에 가장 잘 맞도록 프로세스를 사용자 조정하는 RUP의 필수 요소와 특정 가이드라인을 소개합니다. 고품질의 소프트웨어의 인도와 소프트웨어의 신속한 인도(소프트웨어 모순) 간의 미묘한 밸런스를 조절하는 핵심은 프로세스의 기본 요소를 이해하고 특정 가이드라인에 따라 프로젝트의 특정 필요에 가장 적합하게 프로세스를 조정하는 것입니다. .
기본 설명

소개

고품질의 소프트웨어의 인도와 소프트웨어의 신속한 인도(소프트웨어 모순) 간의 미묘한 밸런스를 조절하는 핵심은 프로세스의 기본 요소를 이해하고 특정 가이드라인에 따라 프로젝트의 특정 필요에 가장 적합하게 프로세스를 조정하는 것입니다. 이 작업은 업계에서 소프트웨어 개발 프로젝트의 성공에 도움이 된다고 입증된 우수 사례에 따라 수행되어야 합니다.   

다음은 효율적인 소프트웨어 프로세스의 필수 원칙을 설명하고 있습니다.

1. 비전: 비전 개발

특히, 명확한 비전 개발은 이해 당사자(stakeholder)의 실제 요구사항을 충족시키는 제품을 개발하는 데 중요한 요소입니다.

RUP에서 비전 아티팩트는 상위 레벨의 요구사항 및 디자인 제한조건을 캡처하여 독자에게 개발될 시스템에 대한 이해를 제공합니다. 이것은 프로젝트 승인 프로세스에 입력을 제공하므로 비즈니스 사례와 밀접하게 관련되어 있습니다. 비전은 프로젝트의 기본 "이유 및 대상"을 전달하며 향후 모든 결정의 유효성을 검증하는 기준이 됩니다.

필요할 경우, 비전의 컨텐츠(기타 관련 요구사항 아티팩트 포함)는 개별적이고 더 세부적인 아티팩트로 나뉠 수 있는 다음 질문에 응답해야 합니다.

  • 주요 용어는 무엇입니까? (용어집)
  • 해결하려는 문제점은 무엇입니까?(문제점 설명)
  • 이해 당사자(stakeholder)는 누구입니까? 사용자는 누구입니까? 요구사항은 무엇입니까?
  • 제품 기능은 무엇입니까?
  • 기능적 요구사항은 무엇입니까?(유스 케이스)
  • 비기능적 요구사항은 무엇입니까?
  • 디자인 제한조건은 무엇입니까?

명확한 비전 및 이해 가능한 요구사항 세트를 개발하는 것이 요구사항 원칙이해 당사자 우선순위 경합 밸런스 원칙의 핵심입니다. 여기에는 문제점 분석, 이해 당사자(stakeholder)의 요구 이해, 시스템 정의 및 변경한 요구사항 관리가 포함됩니다.   

2. 계획: 계획 관리

"제품은 제품에 대한 계획만큼만 좋아집니다." ( FIS96 ).

새 프로젝트 착상, 범위 및 위험성 평가, 프로젝트 모니터링 및 제어, 각 반복 및 단계 평가 계획은 프로젝트 관리 원칙의 "핵심"입니다.

소프트웨어 개발 계획은 프로젝트 관리에 필요한 정보를 수집합니다. 이 정보는 프로젝트 스케줄 및 자원 요구를 계획하고 스케줄에 따라 진행을 추적하는 데 사용됩니다.  프로젝트 조직, 스케줄, 예산 및 자원과 같은 영역을 처리에도 사용됩니다. 또한 요구사항 관리, 형상 관리, 문제점 해결책, 품질 보증, 평가 및 테스트, 제품 적합성에 대한 계획도 포함합니다.

단순 프로젝트에서, 이런 주제 대부분은 각각이 한 문장 또는 두 문장으로 다루어질 수 있습니다. 예를 들어, 형상 관리 계획은 단순히 다음과 같이 설명될 수 있습니다. "하루의 마지막에 프로젝트 디렉토리 구조의 컨텐츠가 압축되어 날짜와 레이블이 적힌 압축 디스크에 복사되고 버전 번호가 표시되어 중앙 서류 캐비넷에 놓입니다."

아티팩트 계획의 형식은 아티팩트에 들어 가는 활동 및 생각의 계획만큼 중요하지 않습니다. 계획이 어떻게 보이는지 또는 계획을 빌드하는 데 어떤 도구를 사용할 것인지는 중요하지 않습니다. Dwight D. Eisenhower가 말한 대로 "계획보다는 계획 수립이 더 중요합니다."

3. 위험성: 위험성 완화 및 연관된 문제 추적

프로젝트 초기에 가장 높은 위험성 항목을 식별하고 공격하며 다른 관련 문제와 함께 이를 추적하는 것이 필요합니다.위험성 목록은 프로젝트 성공에 위험이 되는 인지된 위험성을 캡처하기 위한 것입니다. 위험성 목록은 상당히 부정적인 결과물을 낼 수 있는 이벤트를 우선순위의 내림차순으로 식별합니다.

각 위험성과 함께 해당 위험성을 완화하는 계획이 있어야 합니다.  이것은 프로젝트 계획 활동의 중심점 역할을 하고 반복이 구성되는 기반입니다.

4. 비즈니스 사례: 비즈니스 사례 점검

비즈니스 사례는 비즈니스 관점에서 이 프로젝트에 투자할 가치가 있는지 여부를 판별하는 데 필요한 정보를 제공합니다.

비즈니스 사례의 기본 목적은 프로젝트 비전을 실현하기 위해 경제적 계획을 개발하는 것입니다. 일단 개발한 비즈니스 사례는 프로젝트에 의해 제공된 투자 수익률(ROI)을 정확히 평가하는 데 사용됩니다. 이를 통해 프로젝트에 대한 정당한 이유를 제공하고 경제적 제한조건을 설정합니다. 이것은 프로젝트의 가치에 대해 경제적 의사 결정자에게 정보를 제공하고, 프로젝트가 진행되어야 하는지 여부를 판별하는 데 사용됩니다.

설명은 특정 문제점에 대해 깊이 파고드는 대신 제품이 필요한 이유에 대해 설득력 있는 주장을 제공해야 합니다. 그러나 모든 프로젝트 팀 구성원이 이해하고 기억하기 쉬울만큼 간결해야 합니다. 주요 이정표에서 예상되는 수익 및 비용의 측정이 아직 정확한지, 프로젝트가 계속되어야 하는지 여부를 알아보기 위해 비즈니스 사례가 다시 점검됩니다.

5. 아키텍처: 컴포넌트 아키텍처 디자인

RUP에서 소프트웨어 시스템의 아키텍처(해당 위치)는 연속해서 더 작은 컴포넌트 및 인터페이스로 구성되는 컴포넌트와 함께 인터페이스를 통해 상호작용하는 시스템의 중요한 컴포넌트의 구성 또는 구조입니다. 중요한 부분은 무엇입니까? 각 컴포넌트를 일치시키는 방법은 무엇입니까? 나머지 소프트웨어가 추가될 수 있는 프레임워크가 있습니까?

소프트웨어 아키텍처에 대해 논의하려면 우선 아키텍처 표시, 즉 아키텍처의 주요 측면을 설명하는 방법을 정의해야 합니다. 이 설명은 소프트웨어 아키텍처 문서에 캡처되며 다중 보기에 아키텍처를 표시합니다.

각 아키텍처 보기에는 개발 프로세스의 이해 당사자(stakeholder)인 사용자, 디자이너, 관리자, 시스템 엔지니어, 유지보수자 등에 특정한 일부 관심사항 세트가 표시됩니다. 이것은 소프트웨어 설계자와 다른 프로젝트 팀 구성원 간에 프로젝트에 대해 구조적으로 중요한 의사 결정 시, 커뮤니케이션 매체로 사용됩니다.

후보 아키텍처 정의, 아키텍처 정제, 동작 분석 및 시스템 컴포넌트 디자인은 분석 및 디자인 원칙, 높은 추상 레벨 원칙의 "핵심"입니다.

6. 프로토타입: 점진적으로 제품 빌드 및 테스트

RUP는 가능한 한 초기에 문제점을 없애고 위험성 및 문제를 해결하기 위해 실행 가능한 제품 버전을 빌드, 테스트 및 평가하는 반복 방법입니다.

점진적으로 시스템 컴포넌트를 빌드하고 테스트하는 것은 구현 및 테스트 원칙 및 반복적으로 값 시연의 핵심입니다.

7. 평가: 정기적인 평가 결과

계속적 활동에서 직접적으로 파생되는 객관적인 데이터와 계속 개방적으로 통신하고 제품 구성을 전개하는 것은 모든 프로젝트에서 중요합니다.  정기적 상태 평가는 관리 문제, 기술 문제 및 프로젝트 위험성을 제시하고 커뮤니케이션하며 해결하는 메커니즘을 제공합니다. 문제 식별과 더불어, 각각에는 해결책을 담당하는 책임자와 함께 만기일이 지정되어야 합니다. 이는 정기적으로 추적되어야 하며 필요한 경우 갱신됩니다.

이런 프로젝트 스냅샷은 관리 주의에 대한 핵심을 제공합니다. 기간이 변경되는 동안, 프로젝트 히스토리를 캡처하고 진행을 방해하는 장애 또는 병목 현상을 제거하기 위해 강제 실행 기능이 필요합니다.

반복 평가는 반복의 결과, 평가 기준을 충족시키는 정도, 교훈 및 구현될 프로세스 변경사항을 캡처합니다.

반복 평가는 반복 방법의 필수 아티팩트입니다. 프로젝트의 범위 및 위험성, 반복적 특징에 따라 단순한 예시 및 결과물 레코드에서 완전한 형식의 테스트 검토 레코드까지 될 수 있습니다.

여기서, 핵심은 제품 문제점뿐 아니라 프로세스 문제점에 초점을 맞춥니다. "빨리 뒤쳐질수록 따라잡는 데 더 오래 걸립니다."

8. 변경 요청: 변경 관리 및 제어

첫 번째 프로토타입이 사용자 앞에 놓이자 마자(떼로는 그 이전에) 변경이 요청됩니다. (라이프의 확실성 중의 하나). 변경을 제어하고 프로젝트의 범위 및 이해 당사자(stakeholder)의 기대를 효율적으로 관리하려면, 개발 아티팩트에 대한 모든 변경사항이 변경 요청을 통해 제안되고 일관된 프로세스로 관리되어야 합니다.

변경 요청은 결함, 개선사항 요청 및 기타 유형의 제품 변경 요청을 문서화하고 추적하는 데 사용됩니다. 변경 요청의 장점은 결정 레코드를 제공하고, 평가 프로세스를 통해 모든 프로젝트 팀 구성원이 잠재적 변경의 영향을 파악했는지 확인한다는 것입니다. 변경 요청은 제안된 변경의 영향 평가와 프로젝트 범위 관리에 필수적입니다.

프로젝트 라이프사이클 전체에서 변경이 발생할 때 모든 이해 당사자(stakeholder) 요구를 고려하고 이를 충족시키면서 가능한 정도까지 프로젝트의 범위를 관리하고 제어합니다. 이것은 형상 및 변경 관리 원칙지원 자료: 변경 제어의 "핵심"입니다.

9. 사용자 지원: 유용한 제품 배치

프로세스의 목적은 유용한 제품을 생산하는 것입니다. 프로세스의 모든 측면은 염두에 둔 목적에 맞게 조정되어야 합니다. 제품은 일반적으로 소프트웨어 이상의 것입니다. 최소한 온라인 도움말을 통해 구현되는 사용자 안내서가 있어야 합니다. 설치 안내서 및 릴리스 정보를 포함할 수도 있습니다. 제품의 복잡도에 따라, 제품 패키지와 함께 전달되는 명세서뿐만 아니라 훈련 자료도 필요할 수 있습니다. 관련 활동은  배치 원칙을 형성합니다. 

10. 프로세스: 프로젝트에 적합한 프로세스 채택

개발 중인 제품의 유형에 맞는 프로세스를 선택해야 합니다. 프로세스가 선택된 후에도 맹목적으로 따라서는 안됩니다. 프로세스 및 도구를 구성하고 조직 및 프로젝트의 요구사항을 충족시키는 데 상식과 경험이 적용되어야 합니다.

프로젝트에 적합한 프로세스를 채택하는 것은 환경 원칙의 핵심 부분입니다.

프로젝트 및 조직에 맞는 RUP 채택에 대한 자세한 정보는 개념: RUP 사용자 조정을 참조하십시오.

결론

위의 "필수사항"은 빠르게 프로세스를 평가하고 가장 먼저 개선되어야 하는 영역을 식별하는 수단을 제공합니다. 이런 필수사항 중 어느 것이라도 무시될 때 발생하는 상황을 탐색해야 합니다. 예를 들어,

  • 비전이 없습니까? 현재 추구하는 방향을 쉽게 잃을 수 있습니다.
  • 프로세스가 없습니까? 공통 프로세스가 없으면 팀이 수행할 주체, 대상 및 시기에 대해 잘못된 커뮤니케이션과 오해가 있을 수 있습니다.
  • 계획이 없습니까? 진행을 추적할 수 없을 것입니다.
  • 위험성 목록이 없습니까? 현재 잘못된 문제에 중점을 두며 앞으로 5개월 후에 예상치 못했던 문제가 발생할 수 있습니다.
  • 비즈니스 사례가 없습니까? 프로젝트에서 시간과 돈을 잃을 위험이 있습니다. 프로젝트가 취소되거나 파산할 수 있습니다.
  • 아키텍처가 없습니까? 발생하는 통신, 동기화 및 데이터 액세스 문제를 처리하지 못할 수 있습니다. 크기 조정 및 성능에 문제점이 발생할 수 있습니다.
  • 제품(프로토타입)이 없습니까? 가능한 빠르게 고객에게 제품을 구해 주십시오. 단순히 문서 작업을 축적하는 것으로 제품이 성공적이라는 것을 보증할 수는 없습니다. 그리고 이것은 예산 및 스케줄 초과 및/또는 완전한 실패에 대한 위험성을 최대화합니다.
  • 평가는 없습니까? 현실을 회피하지 마십시오. 사실을 인식해야 합니다. 최종 기한에 얼마나 근접해 있습니까? 품질 또는 예산이 목적에 얼마나 근접해 있습니까? 모든 문제가 적절하게 추적되고 있습니까?
  • 변경 요청은 없습니까? 이해 당사자(stakeholder)의 요구를 어떻게 계속 추적할 것입니까? 이들의 우선순위를 어떻게 지정할 것입니까? 낮은 우선순위의 요구를 어떻게 유지할 것입니까?
  • 사용자 지원은 없습니까? 사용자가 질문이 있거나 제품 사용 방법을 알지 못할 때 어떤 일이 발생합니까? 쉽게 도움을 얻는 방법은 무엇입니까?

이런 "필수사항"은 또한 RUP의 각 원칙 그룹: RUP 원칙에 대한 소개 및 주요 원칙 지원을 제공합니다.