프로세스 필수사항

주제
  1. 비전 - 비전 개발
  2. 계획 - 계획 관리
  3. 위험 - 위험 완화 및 관련 문제 추적
  4. 비즈니스 케이스 - 비즈니스 케이스 검사
  5. 구조 - 컴포넌트 구조 설계
  6. 프로토타입 - 점진적으로 제품 빌드 및 테스트
  7. 평가 - 정기적으로 결과 평가
  8. 변경 요청 - 변경 관리 및 제어
  9. 사용자 지원 - 사용 가능한 제품 전개
  10. 프로세스 - 프로젝트에 적합한 프로세스 채택

추가 가이드:


소개페이지 맨 위

좋은 품질의 소프트웨어를 출시하는 것과 소프트웨어를 빠르게 출시하는 것 사이의 민감한 밸런스(소프트웨어 패러독스)를 이루는 데 있어서 중요한 것은 프로세스의 필수 요소를 이해하고 프로젝트의 특정 요구사항에 가장 잘 맞도록 일정한 가이드라인에 따라 프로세스를 조정하는 것입니다. 이것은 소프트웨어 개발 프로젝트를 성공할 수 있도록 산업 전반에서 걸쳐 증명된 베스트 프랙티스를 고수하는 동안 수행되어야 합니다.   

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

1. 비전 - 비전 개발페이지 맨 위

특히, 명확한 비전 개발은  스테이크홀더의 실제 요구사항을 충족시키는 제품을 개발하는 데 중요한 요소입니다.

RUP에서 비전 결과물은 상위 레벨의 요구사항 및 설계 제한조건을 캡처하여 독자에게 개발될 시스템에 대한 이해를 제공합니다. 이것은 프로젝트 승인 프로세스에 입력을 제공하므로 비즈니스 케이스와 밀접하게 관련되어 있습니다. 또한 이는 프로젝트에 관련된 기본적인 "이유 및 목적"을 전달하고 검증되어야 하는 향후 모든 의사결정에 대한 척도가 됩니다.

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

  • 주요 용어는 무엇입니까?(용어집)
  • 해결하려는 문제점은 무엇입니까?(문제점 진술)
  • 스테이크홀더는 누구입니까? 사용자는 누구입니까? 요구사항은 무엇입니까?
  • 제품 기능은 무엇입니까?
  • 기능적 요구사항은 무엇입니까?(유스 케이스)
  • 비기능적 요구사항은 무엇입니까?
  • 설계 제한조건은 무엇입니까?

명확한 비전 및 이해 가능한 요구사항 세트를 개발하는 것이 ../../process/workflow/ovu_req.htm -- This hyperlink in not present in this generated website요구사항 규칙베스트 프랙티스: 요구사항 관리의 핵심입니다. 여기에는 문제점 분석, 스테이크홀더 요구사항 이해, 시스템 정의 및 변경한 요구사항 관리가 포함됩니다.   

2. 계획 - 계획 관리

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

새 프로젝트 착상, 범위 및 위험 평가, 프로젝트 모니터링 및 제어, 각 반복 및 단계 평가 계획은 ../../process/workflow/ovu_mgm.htm -- This hyperlink in not present in this generated website프로젝트 관리 규칙의 "핵심"입니다.

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

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

결과물 계획의 형식은 결과물에 들어 가는 활동 및 생각의 계획만큼 중요하지 않습니다. 계획이 어떻게 보이는지 또는 계획을 빌드하는 데 어떤 툴을 사용할 것인지는 중요하지 않습니다.  Dwight D. Eisenhower는 "계획은 아무 것도 아닙니다. 계획 수립이 중요합니다."

3. 위험 - 위험 완화 및 관련 문제 추적

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

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

4. 비즈니스 케이스 - 비즈니스 케이스 조사

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

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

설명은 특정 문제점에 대해 깊이 파고들어서는 안되고 오히려 제품이 필요한 이유에 대한 설득력 있는 주장을 작성해야 합니다. 그러나 모든 프로젝트 팀 구성원이 이해하고 기억하기 쉽도록 간략해야 합니다. 결정적인 이정표에서 예상되는 수익 및 비용의 측정이 아직 정확한지, 프로젝트가 계속되어야 하는지 여부를 알아보기 위해 비즈니스 케이스가 재조사됩니다.

5. 구조 - 컴포넌트 구조 설계페이지 맨 위

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

소프트웨어 구조에 대해 설명하고 추론하려면 먼저 중요한 구조의 측면을 설명하는 방법인 구조적 표시를 정의해야 합니다. 이 설명은 소프트웨어 구조 문서에 캡처되며 다중 보기에 구조를 표시합니다.

각 구조적 보기는 개발 프로세스에서 스테이크홀더(일반 사용자, 설계자, 관리자, 시스템 엔지니어, 유지보수자 등)에 특정한 일부 특정 관심사 세트를 제시합니다. 이것은 소프트웨어 아키텍트와 다른 프로젝트 팀 구성원 간에 프로젝트에 대해 구조적으로 중요한 의사 결정시, 의사소통 매체로 사용됩니다.

후보 구조 정의, 구조 정제, 작동 분석 및 시스템 컴포넌트 설계는 분석 및 설계 규칙베스트 프랙티스: 컴포넌트 구조 사용의 "핵심"입니다.

6. 프로토타입 - 점진적으로 제품 빌드 및 테스트 페이지 맨 위

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

점진적으로 시스템 컴포넌트를 빌드하고 테스트하는 것은 구현 및 ../../process/workflow/ovu_test.htm -- This hyperlink in not present in this generated website 테스트 규칙, 베스트 프랙티스: 반복적으로 개발의 "핵심"입니다.

7. 평가 - 정기적으로 결과 평가

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

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

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

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

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

8. 변경 요청 - 변경 관리 및 제어페이지 맨 위

첫 번째 프로토타입이 사용자 앞에 놓이자 마자(종종 그 이전) 변경이 요청됩니다(라이프의 확실성 중의 하나). 변경을 제어하고 프로젝트의 범위 및 스테이크홀더의 기대치를 효율적으로 관리하려면, 개발 결과물에 대한 모든 변경사항이 변경 요청을 통해 제안되고 일관적인 프로세스로 관리되는 것이 중요합니다.

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

프로젝트 라이프사이클 전체에서 변경이 발생할 때 모든 스테이크홀더 요구사항을 고려하고 이를 충족시키면서 가능한 정도까지 프로젝트의 범위를 관리하고 제어합니다. 이것은 형상 및 변경 관리 규칙베스트 프랙티스: 변경 제어의 "핵심"입니다.

9. 사용자 지원 - 사용 가능한 제품 전개페이지 맨 위

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

10. 프로세스 - 프로젝트에 적합한 프로세스 채택페이지 맨 위

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

프로젝트에 적합한 프로세스를 채택하는 것은 ../../process/workflow/ovu_env.htm -- This hyperlink in not present in this generated website환경 규칙의 핵심 부분입니다.

프로젝트 및 조직에 맞는 RUP 채택에 대한 자세한 정보는 ../../process/workflow/environm/co_polpr.htm -- This hyperlink in not present in this generated website개념: RUP 조정을 참조하십시오.

결론페이지 맨 위

위의 "필수사항"은 빠르게 프로세스를 평가하고 개선이 가장 필요한 영역을 식별하는 수단을 제공합니다. 이런 필수사항 중 어느 것이라도 무시될 때 발생하는 상황을 조사하는 것이 중요합니다. 예를 들면, 다음과 같습니다.

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

이런 "필수사항"은 RUP의 각 규칙에 대한 소개 및 수 많은 베스트 프랙티스를 제공하기도 합니다. 



Rational Unified Process   2003.06.15