프로세스 필수사항주제
소개
좋은 품질의 소프트웨어를 출시하는 것과 소프트웨어를 빠르게 출시하는 것 사이의 민감한 밸런스(소프트웨어 패러독스)를 이루는 데 있어서 중요한 것은 프로세스의 필수 요소를 이해하고 프로젝트의 특정 요구사항에 가장 잘 맞도록 일정한 가이드라인에 따라 프로세스를 조정하는 것입니다. 이것은 소프트웨어 개발 프로젝트를 성공할 수 있도록 산업 전반에서 걸쳐 증명된 베스트 프랙티스를 고수하는 동안 수행되어야 합니다. 다음은 효율적인 소프트웨어 프로세스의 필수 원칙을 설명하고 있습니다. 1. 비전 - 비전 개발
특히, 명확한 비전 개발은 스테이크홀더의 실제 요구사항을 충족시키는 제품을 개발하는 데 중요한 요소입니다. RUP에서 비전 결과물은 상위 레벨의 요구사항 및 설계 제한조건을 캡처하여 독자에게 개발될 시스템에 대한 이해를 제공합니다. 이것은 프로젝트 승인 프로세스에 입력을 제공하므로 비즈니스 케이스와 밀접하게 관련되어 있습니다. 또한 이는 프로젝트에 관련된 기본적인 "이유 및 목적"을 전달하고 검증되어야 하는 향후 모든 의사결정에 대한 척도가 됩니다. 필요할 경우, 비전의 컨텐츠(기타 관련 요구사항 결과물 포함)는 개별적이고 더 세부적인 결과물로 나뉠 수 있는 다음 질문에 응답해야 합니다.
명확한 비전 및 이해 가능한 요구사항 세트를 개발하는 것이
2. 계획 - 계획 관리"제품은 제품에 대한 계획만큼만 좋아집니다." (FIS96). 새 프로젝트 착상, 범위 및 위험 평가,
프로젝트 모니터링 및 제어, 각 반복 및 단계 평가 계획은
소프트웨어 개발 계획은 프로젝트 관리에 필요한 정보를 수집합니다. 이 정보는 프로젝트 스케줄 및 자원 요구를 계획하고 스케줄에 따라 진행을 추적하는 데 사용됩니다. 이것은 프로젝트 조직, 스케줄, 예산 및 자원과 같은 영역을 처리합니다. 또한 요구사항 관리, 형상 관리, 문제점 해결책, 품질 보증, 평가 및 테스트, 제품 인수에 대한 계획도 포함합니다. 단순 프로젝트에서, 이런 주제 대부분은 각각이 한 문장 또는 두 문장으로 다루어질 수 있습니다. 예를 들어, 형상 관리 계획은 단순히 다음과 같이 설명될 수 있습니다. "하루의 마지막에 프로젝트 디렉토리 구조의 컨텐츠가 압축되어 날짜와 레이블이 적힌 압축 디스크에 복사되고 버전 번호가 표시되어 중앙 서류 캐비넷에 놓입니다." 결과물 계획의 형식은 결과물에 들어 가는 활동 및 생각의 계획만큼 중요하지 않습니다. 계획이 어떻게 보이는지 또는 계획을 빌드하는 데 어떤 툴을 사용할 것인지는 중요하지 않습니다. Dwight D. Eisenhower는 "계획은 아무 것도 아닙니다. 계획 수립이 중요합니다." 3. 위험 - 위험 완화 및 관련 문제 추적프로젝트 초기에 가장 높은 위험 항목을 식별하고 공격하며 다른 관련 문제와 함께 이를 추적하는 것이 필요합니다. 위험 목록은 프로젝트 성공에 대해 인지된 위험을 캡처하기 위한 것입니다. 위험 목록은 상당히 부정적인 결과를 낼 수 있는 이벤트를 우선순위의 내림차순으로 식별합니다. 각 위험과 함께 해당 위험을 완화하는 계획이 있어야 합니다. 이것은 프로젝트 계획 활동의 중심점 역할을 하고 반복이 구성되는 기초입니다. 4. 비즈니스 케이스 - 비즈니스 케이스 조사비즈니스 케이스는 비즈니스 관점에서 이 프로젝트에 투자할 가치가 있는지 여부를 판별하는 데 필요한 정보를 제공합니다. 비즈니스 케이스의 주요 목적은 프로젝트 비전을 실현하기 위해 경제적 계획을 개발하는 것입니다. 일단 개발되면, 비즈니스 케이스는 프로젝트에서 제공되는 투자 수익률(ROI)을 정확하게 평가하는 데 사용됩니다. 이것은 프로젝트에 대한 정당성을 제공하고 경제적 제한조건을 수립합니다. 이것은 프로젝트의 가치에 대해 경제적 의사결정자에게 정보를 제공하고, 프로젝트가 진행되어야 하는지 여부를 판별하는 데 사용됩니다. 설명은 특정 문제점에 대해 깊이 파고들어서는 안되고 오히려 제품이 필요한 이유에 대한 설득력 있는 주장을 작성해야 합니다. 그러나 모든 프로젝트 팀 구성원이 이해하고 기억하기 쉽도록 간략해야 합니다. 결정적인 이정표에서 예상되는 수익 및 비용의 측정이 아직 정확한지, 프로젝트가 계속되어야 하는지 여부를 알아보기 위해 비즈니스 케이스가 재조사됩니다. 5. 구조 - 컴포넌트 구조 설계
RUP에서 소프트웨어 시스템의 구조(해당 위치)는 연속해서 더 작은 컴포넌트 및 인터페이스로 구성되는 컴포넌트와 함께 인터페이스를 통해 상호작용하는 시스템의 중요한 컴포넌트의 구성 또는 구조입니다. 중요한 부분은 무엇입니까? 각 컴포넌트를 일치시키는 방법은 무엇입니까? 나머지 소프트웨어가 추가될 수 있는 프레임워크가 있습니까? 소프트웨어 구조에 대해 설명하고 추론하려면 먼저 중요한 구조의 측면을 설명하는 방법인 구조적 표시를 정의해야 합니다. 이 설명은 소프트웨어 구조 문서에 캡처되며 다중 보기에 구조를 표시합니다. 각 구조적 보기는 개발 프로세스에서 스테이크홀더(일반 사용자, 설계자, 관리자, 시스템 엔지니어, 유지보수자 등)에 특정한 일부 특정 관심사 세트를 제시합니다. 이것은 소프트웨어 아키텍트와 다른 프로젝트 팀 구성원 간에 프로젝트에 대해 구조적으로 중요한 의사 결정시, 의사소통 매체로 사용됩니다. 후보 구조 정의, 구조 정제, 작동 분석 및 시스템 컴포넌트 설계는 분석 및 설계 규칙 및 베스트 프랙티스: 컴포넌트 구조 사용의 "핵심"입니다. 6. 프로토타입 - 점진적으로 제품 빌드 및 테스트
RUP는 가능한 한 초기에 문제점을 없애고 위험 및 문제를 해결하기 위해 실행 가능한 제품 버전을 빌드, 테스트 및 평가하는 반복 방법입니다. 점진적으로 시스템 컴포넌트를 빌드하고 테스트하는 것은
구현 및
7. 평가 - 정기적으로 결과 평가진행 중인 활동에서 직접적으로 파생되는 객관적인 데이터와 끊임없이 개방적인 통신을 하고, 제품 형상을 전개하는 것은 모든 프로젝트에서 중요합니다. 정기적 상태 평가는 관리 문제, 기술 문제 및 프로젝트 위험을 제시하고 전달하며 해결하는 메커니즘을 제공합니다. 문제 식별과 더불어, 각각에는 해결책을 담당하는 책임자와 함께 만기일이 지정되어야 합니다. 이는 정기적으로 추적되어야 하며 필요한 경우 갱신됩니다. 이런 프로젝트 스냅샷은 관리 주의에 대한 핵심을 제공합니다. 기간이 변경되는 동안, 프로젝트 이력을 캡처하고 진행을 방해하는 장애 또는 병목현상을 제거하기 위해 강제 실행 기능이 필요합니다. 반복 평가는 반복의 결과, 평가 기준을 충족시키는 정도, 학습 내용 및 구현될 프로세스 변경사항을 캡처합니다. 반복 평가는 반복 방법의 필수 결과물입니다. 프로젝트의 범위 및 위험, 반복적 특징에 따라 단순한 시연 및 성과 기록에서 완전한 형식의 테스트 검토 기록까지 될 수 있습니다. 여기서, 핵심은 제품 문제점뿐 아니라 프로세스 문제점에 중점을 둡니다. "빨리 뒤쳐질수록 따라잡는 데 더 오래 걸립니다." 8. 변경 요청 - 변경 관리 및 제어
첫 번째 프로토타입이 사용자 앞에 놓이자 마자(종종 그 이전) 변경이 요청됩니다(라이프의 확실성 중의 하나). 변경을 제어하고 프로젝트의 범위 및 스테이크홀더의 기대치를 효율적으로 관리하려면, 개발 결과물에 대한 모든 변경사항이 변경 요청을 통해 제안되고 일관적인 프로세스로 관리되는 것이 중요합니다. 변경 요청은 결함, 개선사항 요청 및 기타 유형의 제품 변경 요청을 문서화하고 추적하는 데 사용됩니다. 변경 요청의 장점은 의사결정 기록을 제공하고, 평가 프로세스를 통해 모든 프로젝트 팀 구성원이 잠재적 변경의 영향을 파악했는지 확인한다는 것입니다. 변경 요청은 제안된 변경의 영향 평가와 프로젝트 범위 관리에 필수적입니다. 프로젝트 라이프사이클 전체에서 변경이 발생할 때 모든 스테이크홀더 요구사항을 고려하고 이를 충족시키면서 가능한 정도까지 프로젝트의 범위를 관리하고 제어합니다. 이것은 형상 및 변경 관리 규칙 및 베스트 프랙티스: 변경 제어의 "핵심"입니다. 9. 사용자 지원 - 사용 가능한 제품 전개
프로세스의 목적은 사용 가능한 제품을 생산하는 것입니다. 프로세스의 모든 측면은 염두에 둔 목표에 맞게 조정되어야 합니다. 제품은 일반적으로 소프트웨어 이상의 것입니다. 최소한, 온라인 도움말을 통해 구현되는 사용자 안내서가 있어야 합니다. 설치 안내서 및 릴리즈 정보를 포함할 수도 있습니다. 제품의 복잡도에 따라, 제품 패키지와 함께 전달되는 명세서뿐만 아니라 교육 자료도 필요할 수 있습니다. 10. 프로세스 - 프로젝트에 적합한 프로세스 채택
개발 중인 제품의 유형에 맞는 프로세스를 선택하는 것이 중요합니다. 프로세스가 선택된 후에도 맹목적으로 따라서는 안됩니다. 프로세스 및 툴을 구성하고 조직 및 프로젝트의 요구사항을 충족시키는 데 상식과 경험이 적용되어야 합니다. 프로젝트에 적합한 프로세스를 채택하는 것은
프로젝트 및 조직에 맞는 RUP 채택에 대한 자세한 정보는
결론
위의 "필수사항"은 빠르게 프로세스를 평가하고 개선이 가장 필요한 영역을 식별하는 수단을 제공합니다. 이런 필수사항 중 어느 것이라도 무시될 때 발생하는 상황을 조사하는 것이 중요합니다. 예를 들면, 다음과 같습니다.
이런 "필수사항"은 RUP의 각 규칙에 대한 소개 및 수 많은 베스트 프랙티스를 제공하기도 합니다. |
Rational Unified Process
|