중간 산출물: 개발 프로세스
이 중간 산출물은 프로젝트에서 원하는 결과를 얻기 위해 따라야 하는 프로세스에 대해 설명합니다. 이 중간 산출물은 소프트웨어 개발 프로세스라고도 합니다.
목적
개발 프로세스의 목적은 프로젝트의 구성원에게 안내 및 지원을 제공하는 것입니다. "정통한 정보"는 이 중간 산출물의 목적에 따라 적절히 맞춘 구체적인 예입니다.
관계
기본 설명

모든 프로세스는 n 레벨 분해 구조로 구성되어 있습니다. 코어 메소드 컨텐츠는 단계별 설명을 제공하고, 개발 라이프사이클 내에서 해당 단계의 배치와 관계없이 매우 특정적인 개발 목적의 달성 방법을 설명합니다. 프로세스는 이 메소드 요소를 받아 특정 유형의 프로젝트에 사용자 정의되는 반 순서 지정된 시퀀스와 관련시킵니다. 따라서 프로세스는 상위 개발 목적에 도달하기 위해 의도된 부분적인 순서 지정 작업 설명 세트(예: 특정 소프트웨어 시스템 릴리스)입니다. 프로세스는 분해 구조의 작업 라이프사이클 및 시퀀스에 초점을 맞춥니다.

다양한 유형의 프로세스(예: 전달 프로세스기능 패턴)가 있습니다.

전달 프로세스

전달 프로세스는 특정 유형의 개발 프로젝트를 수행하기 위한 전체 및 통합 접근 방식을 설명합니다. 전달 프로세스는 처음부터 끝까지 전체 개발 라이프사이클을 포함하는 프로세스입니다. 전달 프로세스는 프로젝트 계획 및 실행을 위한 템플리트로 사용됩니다. 전체 라이프사이클 모델에는 사전 정의된 단계, 반복 및 작업분류체계로 메소드 컨텐츠의 시퀀스를 지정하여 세부화한 활동을 제공합니다. 과거 프로젝트나 계약에 대한 경험 및 개발 또는 전달 방식의 우수 사례 적용을 기반으로 하여 정의됩니다. 생산되는 항목, 해당 항목의 생산 방법 및 통합된 작업, 중간 산출물 및 팀 분해 구조의 양식에 필요한 인력 구성을 정의합니다. 예를 들어, 프로세스 엔지니어는 필요한 고용계약 및 인력 구성 기준, 개발해야 할 소프트웨어 응용프로그램 유형, 사용해야 할 개발 방법 및 기술에 따라 다른 소프트웨어 개발 프로젝트에 대한 대체 전달 프로세스를 정의할 수 있습니다. 전달 프로세스는 전체 프로젝트 보호를 목적으로 하지만 필요 이상의 프로젝트 특정 결정을 공개적으로 유지합니다. 예를 들어, 작업분류체계는 발생이 많거나 각각의 속성을 경유로 반복 가능한 분해 요소를 정의하고 발생 횟수 및 반복 횟수를 지정하지 않습니다. 이 결정은 구체적 프로젝트, 프로젝트 단계 또는 프로젝트 반복을 계획할 때 프로젝트 관리자에 의해 수행되어야 합니다.

기능 패턴

기능 패턴은 공통 프로세스 영역의 재사용가능한 활동 클러스터를 설명합니다. 기능 패턴은 중요한 기본 영역(예: 원칙)에 대한 프로세스 정보를 표시 및 커뮤니케이션하고 프로세스 종사자(practitioner)의 작업 안내에 직접 사용될 수 있습니다. 또한 더 큰 기능 패턴은 표시한 핵심 사례에 대해 최선의 재사용 및 응용을 보장하는 전달 프로세스나 더 큰 기능 패턴을 조합하는 빌딩 블록으로도 사용될 수 있습니다. 기능 패턴의 예로는 '유스 케이스 기반 요구사항 관리', '유스 케이스 분석' 또는 '유닛 테스트'가 있습니다. 반드시 그렇지는 않지만 일반적으로 기능 패턴은 재사용가능하고 복잡한 활동의 분해, 이 활동 내에서 타스크를 수행하는 역할과 사용 및 생산되는 중간 산출물과의 관계를 제공하는 일련의 원칙 범위를 나타냅니다. 기능 패턴은 개발 라이프사이클의 어떤 특정 단계나 반복과도 관계가 없고 어떠한 의미도 내포하지 않습니다. 다시 말해서, 패턴은 전달 프로세스의 어디든지 적용 가능한 방법으로 디자인해야 합니다. 따라서 활동은 적용되는 전달 프로세스에 존재하는 어떤 단계일지라도 유연하게 지정될 수 있습니다.

하나 이상의 일반 인도물을 생산하기 위해 기능 패턴을 디자인하는 것은 바람직한 사례입니다. 일반적인 구성은 기능 패턴의 각 활동이 하나의 인도물을 생산하고 활동의 마지막 타스크 설명자가 명시적으로 이 인도물만 출력하는 것입니다. 이 구성을 사용하여 프로세스 엔지니어는 필요한 인도물을 결정하여 패턴이나 적절한 활동을 선택할 수 있습니다. 또한 단순 통합 접근 방식도 제공하므로, 기능 패턴의 활동은 활동의 인도물을 생산하는 데 필요한 단계나 반복과 연결됩니다.

특성
선택사항
계획됨Yes
핵심 고려사항
개발 프로세스에서 전체 프로세스를 캡처하지 않도록 결정할 수 있습니다. 일부의 경우에는 특히 많은 책임, 프로세스에 대한 결정 및 중간 산출물이 소프트웨어 개발 프로젝트의 구성원에게 위임됩니다. 예를 들어, 경험있고 능력있는 프로젝트 관리자가 있으면 그 관리자가 생성 계획 및 생성 방법을 결정하게 할 수 있습니다. 동일한 방법으로, 각 팀 구성원이 적시에 적절한 품질 레벨로 기능을 전달하기만 하면 여러 프로젝트 관리자는 각 팀 구성원이 시스템을 구성하는 방법에 신경을 쓰지 않습니다.

프로세스 설명이 있어야 하는 한 가지 이유는 여러 사람들이 정보를 공유할 수 있기 때문입니다. 이렇게 하지 않으면 프로세스 정보를 유지보수하는 비용이 많이 들 수 있습니다. 따라서 하나 또는 여러 규칙에 대해 프로세스 설명이 없도록 하거나 유지보수하도록 결정할 수 있습니다. 이는 특정 원칙에 대해 노력을 기울이지 않는다거나 이를 중요하지 않게 생각하는 것은 아닙니다. 예를 들어, 유능한 테스트 관리자를 고용하거나 가능한 모든 지원을 제공하되 해당 테스트 관리자가 작업 방법 및 생성할 중간 산출물을 결정하게 할 수 있습니다.

자세한 정보