활동:
|
목적
|
|
역할: 프로젝트 관리자 | |
빈도: 반복당 한 번 | |
단계 | |
입력물: | 결과물: |
툴 강좌: |
워크플로우 세부사항: |
목적 | 지위, 팀, 책임 및 계층 구조에 따라 프로젝트의 조직 구조 정의 |
프로젝트 조직 구조는 프로젝트의 특성 및 외부 제한조건(기존 조직 정책 등)을 기준으로 선택합니다. 따라서 효율적인(또는 실행 가능한) 조직 구조는 환경에 따라 매우 다르므로 해당 구조를 규정하는 일은 어렵습니다. 프로젝트 조직의 형태와 규모는 단계별로 다양하며 활성 문서인 소프트웨어 개발 계획이 이러한 변경사항을 반영하여 갱신됩니다.
목적 | 프로젝트에 필요한 인력의 수, 유형(기술, 도메인), 경력 및 가치 정의 |
프로젝트의 예상 업무량, 스케줄, 선택된 조직 구조 및 역할 맵핑을 기반으로 프로젝트 관리자는 프로젝트에 필요한 인력 프로파일(시간 경과 시 인력 수 및 기술 세트)을 판별합니다. 프로젝트의 예상 업무량은 팀 규모, 경력, 기술 및 가치에 따라 달라지며 관리자는 직원 능력 등에 대한 가정을 정하고 업무량을 예상합니다. COCOMO 평가 모델(활동: 단계 및 반복 계획 참조)의 경우 업무 수행의 주요 조정자는 직원의 능력 및 경력입니다. 따라서 승인 가능한 총 작업량(다양한 COCOMO 작업 조정자를 튜닝하여)과 실행 가능한 스케줄을 선택하여 인력 프로파일을 결정합니다.
일부 경우에 프로젝트 관리자는 사용 가능한 인력의 수 및 기술력을 미리 알 수 있습니다. 이런 경우에는 프로젝트 범위가 일정하게 유지된다고 가정하여 인력 크기 및 기술 세트를 통해 스케줄만 변동됩니다.
프로젝트 관리자는 인력 레벨을 갑자기 올려 초래할 수 있는 혼란과 인력 수를 늘려 스케줄을 급격하게 줄임으로써 생산력에 미칠 수 있는 잠재적인 영향에 대해서도 알고 있어야 합니다.
초기화 단계의 요점은 범위를 정의하고 제한하며 프로젝트의 비즈니스 케이스를 개발하는 것입니다. 따라서 팀 규모가 매우 작습니다. 한 명의 프로젝트 관리자, 한 명의 소프트웨어 아키텍트 및 한 명이나 두 명의 개발자로 이루어지며 특히 제품 요구사항을 명확히 하거나 제품 지원을 빌드하기 위해 개념 프로토타입의 입증이 요구됩니다.
구현화 단계의 요점은 주로 구조 및 구조적 프로토타입입니다. 따라서 초기 구현화 단계의 설계 활동은 구조적 측면에 중점을 두며 식별되더라도 구조적으로 중요하지 않은 세부적인 클래스 및 속성에는 거의 주의를 기울이지 않습니다. 이 반복 동안에 대부분의 작업은 구조 팀 및 지정된 프로토타입 팀에서 수행합니다. 보통 프로토타입 팀은 경력이 풍부한 프로그래머로 이루어집니다. 이 때 일반 메커니즘 및 기술에 중점을 두는 소규모의 설계 팀과도 작업하게 됩니다. 테스트 그룹은 테스트 환경을 빌드하고 초기 유스 케이스를 테스트하는 데 중점을 둡니다.
구조 팀 구성원은 주의 깊게 선택해야 합니다. 우수한 분석 및 설계 기술이 필요할 뿐만 아니라 리더쉽도 있어야 합니다. 형상 단계 동안 규모가 큰 팀과 구조에 대해 의사 교환하려면 구조 팀의 구성원을 구성 팀 내에서 배분시키는 것이 좋습니다. 또한 구조 팀의 구성원은 광범위한 소프트웨어 엔지니어링 경력을 가지고 있어야 합니다. 소프트웨어 설계 및 구현, 성능 튜닝, 데이터베이스 관리, 네트워크 관리 및 형상 관리자는 구조 팀에 필요한 주요 기술 세트를 포함합니다.
구성 단계는 증가된 기능성을 시스템에 빌드하면서 시스템의 구조적 무결성을 유지하는 데 중점을 둡니다. 이를 위해 구조적 정제(구현화 단계 다음에 오는 구조의 "동결"이 아닌 "기준선 작성")와, 설계자 및 설계자의 설계를 감시하는 구조 팀이 필요합니다.
구조 팀은 기술 리더 역할을 하고 그룹 내부 사안을 다른 기술 리더와 함께 조정하면서 개발 팀들 내에서 작업합니다. 구성 팀은 지정된 기능을 설계하고 구현하는 것 모두에 대해 책임이 있기 때문에 구성 팀 자체는 설계 및 개발 전문가가 모두 포함된 상호 기능적인 팀입니다. 일반적으로, 구성 팀은 잘 정의된 인터페이스를 가진 하나 이상의 서브시스템을 담당합니다. 이런 인터페이스를 변경하거나 새로운 서브시스템을 추가하면 구조적인 변경이 이루어지므로 이와 같은 변경이나 추가는 주의 깊게 고려해야 합니다. 서브시스템 내에서는 적절하다고 판단되는 범위에서 팀이 상대적으로 자유롭게 설계하고 구현하지만, 여러 팀이 동일한 구현 메커니즘을 동시에 빌드하지 않도록 팀 간 의사소통이 필요합니다.
일반적으로 구성 팀은 계층화된 라인에 따라 수평적으로 조직됩니다. 한 팀은 데이터베이스 인터페이스 또는 의사소통 인프라스트럭처를 담당하고 다른 팀은 어플리케이션 기능성 자체에 집중할 수 있습니다. 결과적으로 "상위" 계층 팀에는 사용자 인터페이스 설계 또는 외부 시스템과의 인터페이스와 함께 문제점 도메인 분야의 전문가가 많이 필요합니다. "하위" 계층 팀은 구현 기술에 익숙합니다. 이와 같이 이들 팀 구성에는 서로 다른 기술 요구사항이 반영되어야 합니다.
첫번째 테스트 질문은 수행해야 하는 공식 테스트의 횟수에 관한 것입니다. 그런 다음, 공식 테스트 중 비용 및 스케줄 측면에서 적당하면서도 품질 목표을 충족시키기 위해 수행할 수 있는 테스트 수를 묻습니다. 모든 테스트를 수행할 수 있도록 프로젝트 예산을 세우는 경우는 거의 없습니다. 일반적으로 프로젝트는 수행 가능한 테스트 레벨을 선택해야 합니다. 각 테스트 스펙을 조사하고 유지해야 한다는 점에 주의하십시오. 수많은 테스트 스펙을 작성하도록 계획을 세워 놓고 시간 부족으로 계획을 구현하지 못하는 경우 프로젝트 팀의 의욕이 저하될 수 있습니다.
특정 테스트 팀을 구성하십시오. 테스트 팀의 최소한 한 명은 요구사항 캡처 팀에서 나와야 합니다. 테스트 팀은 다음을 담당합니다.
테스트 작업은 단지 테스트를 수행하는 것만이 아니라 테스트 환경을 준비하고 테스트 스펙을 조사하여 기록하는 작업도 포함하는 것임을 기억하십시오.
별도의 그룹이 유스 케이스 및 전체 시스템을 테스트해야 합니다. 이러한 그룹은 테스트를 수행하고 테스트 보고서도 작성해야 합니다. 한 개인이 각 유스 케이스의 테스트를 담당하도록 유스 케이스 테스트 작업을 구조화해야 합니다.
소규모 프로젝트와 같이 별도의 그룹이 유스 케이스를 테스트할 수 없는 경우 최소한 유스 케이스의 설계 담당자가 유스 케이스를 테스트하는 일은 없도록 해야 합니다.
자동화된 회귀 테스트는 중간 규모 및 대규모 프로젝트에서 사용됩니다. 테스트 팀에는 이 기능을 지원하는 약간 명의 프로그래머가 필요합니다. 동일한 테스트 도구를 여러 번이고 다시 실행하지 않으려면 반복 개발 중에 이 기능이 더욱 중요합니다.
전이 단계에서 개발 작업이 완료됩니다. 베타 테스트가 수행되고 최종 릴리즈가 준비됩니다. 구성 단계의 작업이 제대로 수행된 경우 프로젝트 팀은 규모를 줄이고 개발자 및 테스터 수를 감소시키기 시작할 수 있습니다. 팀의 혼합은 사용자 커뮤니티에 제품을 전개할 책임이 있는 인프라스트럭처 세부 계획 전문가 및 트레이너를 위해 전환됩니다.
소프트웨어 아키텍트 또는 구조 팀은 "사후 관리 모드"로 작업합니다. 이들은 편의 위주로 문제점을 수정하여 구조를 손상시키는 일이 없도록, 문제점 보고서를 분류하고 변경 제안서의 우선순위를 정하며 순서를 변경합니다. 설계 활동은 전이 단계 동안 감소되어 문제점의 정정이나 최종 단계에서 개선점을 도입하는 것으로 제한됩니다.
Rational Unified Process
|