목적
|
프로젝트에 필요한 인력의 수, 유형(스킬, 도메인), 경험 및 재능을 정의
|
프로젝트에 대한 노력 예상, 원하는 스케줄, 선택한 조직 구조 및 역할 맵핑을 기반으로 프로젝트 관리자는 프로젝트에 필요한 인력 구성 프로파일(시간 외 근무 인력 수 및 스킬 세트)을 결정합니다. 프로젝트에 대한
노력 예상은 물론 팀 규모, 경험, 스킬 및 재능과 관계가 있습니다. 일반적으로 프로젝트 관리자는 노력 예상 시 인력의 가능성 등에 대한 가정을 하게 됩니다. COCOMO 예상 모델 (타스크: 단계 및 반복 계획 참조)에서 인력의 능력과 경험은 주요 노력 구동 요소입니다. 따라서 다양한 COCOMO 노력
구동 요소를 조정하여 허용 가능한 총 노력을 선택하고 실현 가능한 스케줄을 선택하면 인력 프로파일을 판별하게 됩니다.
일부 경우, 프로젝트 관리자는 사용 가능한 인력의 수와 스킬을 사전에 알고 있을 수 있습니다. 이런 경우, 프로젝트 범위가 변하지 않는다고 가정하고 인력 규모와 스킬 세트를 그대로 사용하여 스케줄만 변경할
수 있습니다.
또한 프로젝트 관리자는 너무 급속히 인력 레벨을 강화할 경우 야기될 수 있는 혼란과, 인력 수를 대폭 늘려 스케줄을 급격히 줄이는 경우 생산성에 미치는 잠재적 파국 효과를 알고 있어야 합니다.
도입/인식 단계에서는 범위를 정의하고 한정하며 프로젝트의 비즈니스 사례를 개발하는 데 초점을 맞춥니다. 따라서 팀 규모가 아주 작습니다. 프로젝트 관리자, 소프트웨어 설계자, 하나 또는 두 명의 개발자가 필요하며,
특히 요구사항을 명확히 하거나 제품 지원을 빌드하기 위해 개념 검증 프로토타입이 필요합니다.
정제(Elaboration) 단계에서는 아키텍처와 아키텍처 프로토타입에 주로 초점을 맞춥니다. 따라서 초기 정제 단계에서 디자인 타스크는 아키텍처 측면에 초점을 맞춥니다. 클래스 및 클래스 속성 세부사항에 대해서는
주의를 기울이지 않으며, 이는 식별되었다고 해도 구조적으로 중요하진 않습니다. 이런 반복 중에는 아키텍처 팀 및 배정된 프로토타입 팀이 대부분의 노력을 기울입니다. 대개 프로토타입 생성 팀은 보다 숙련된
프로그래머와 함께 배치됩니다. 현 시점에서는 일반 메커니즘과 기술에 초점을 맞추는 아주 작은 디자인 팀을 갖게 됩니다. 테스트 그룹은 테스트 환경을 빌드하고 조치 유스 케이스를 테스트하는 데 초점을 맞춥니다.
아키텍처 팀 구성원 선택은 신중해야 합니다. 아키텍처 팀 구성원은 우수한 분석 및 디자인 스킬은 물론 지도자의 자질도 갖추고 있어야 합니다. 구현/구축(Construction) 단계 중 보다 대규모의 팀과
아키텍처에 관한 커뮤니케이션을 하려면 구현/구축 팀에 아키텍처 팀 구성원을 분배하는 것이 좋습니다. 또한 아키텍처 팀 구성원은 광범위한 소프트웨어 엔지니어링 경험이 있어야 합니다. 소프트웨어 디자인 및 구현, 성능
조정, 데이터베이스 관리, 네트워크 관리 및 형상 관리는 아키텍처 팀에 표시되어야 하는 주요 스킬 세트를 포함해야 합니다.
구현/구축 단계에서는 시스템에 더 많은 기능을 빌드하면서 시스템의 아키텍처 무결성을 유지보수하는 데 초점을 맞춥니다. 이렇게 하려면 아키텍처 정제(따라서 정제 단계를 따라 아키텍처 "기준선 작성" 및 "동결"
방지)와 디자이너와 디자인을 주시하는 아키텍처 팀이 필요합니다.
아키텍처 팀은 개발 팀에 분배되는 경향이 있으며, 기술적 리드의 역할을 하고 다른 기술적 리드와 그룹 간 문제를 조정합니다. 구현/구축 팀은 자신들이 지정한 기능의 구현 및 디자인에 대한 책임을 모두 지고 있으므로
디자인과 개발 전문 지식을 둘 다 보유한 다기능 팀이어야 합니다. 일반적으로 구현/구축 팀은 잘 정의된 하나 이상의 서브시스템을 책임지고 있습니다. 이 인터페이스가 변경되거나 새로운 서브시스템이 추가되면 아키텍처가
변경되므로 주의깊게 고려해야 합니다. 서브시스템 내에서 팀은 적합하다고 생각되면 비교적 자유롭게 디자인하고 구현할 수 있지만 팀이 동일한 구현 메커니즘을 병렬로 구축하지 않도록 팀 간 커뮤니케이션이 필요합니다.
일반적으로 구현/구축 팀은 대개 계층화 라인을 따라 수평으로 구성됩니다. 한 팀은 데이터베이스 인터페이스 또는 통신 하부 구조에 대한 책임을 지는 반면에 다른 팀은 응용프로그램 기능 자체에 초점을 맞출 수
있습니다. 따라서 "상위" 계층 팀의 경우 문제점 도메인, 사용자 인터페이스 디자인 또는 외부 시스템과의 상호작용에 대한 전문 지식이 더 많이 필요합니다. "하위" 계층 팀은 구현 기술에 보다 정통합니다. 이런 팀
구성은 여러 스킬 요구를 반영해야 합니다.
테스트에서 첫 번째 질문은 정규 테스트를 어느 정도 수행해야 하는가 입니다. 그 다음에는 비용 및 스케줄 측면에서 합당한 한계 내에서 품질 목표를 충족하기 위해 어느 정도의 테스트를 수행할 수 있느냐 입니다. 모든
종류의 테스트를 수행할 수 있을 만큼 프로젝트 예산이 풍족한 경우는 드뭅니다. 일반적으로 프로젝트는 제공할 수 있는 테스트 레벨을 선택해야 합니다. 각 테스트 스펙을 검사하고 유지보수해야 함을 기억하십시오. 테스트
스펙을 많이 작성하도록 계획을 수립해 놓고 시간이 부족하여 해당 계획을 구현할 수 없는 경우에는 프로젝트 팀의 사기가 극도로 저하됩니다.
특정 테스트 팀을 구성하십시오. 테스트 팀에서 적어도 한 사람은 요구사항 캡처 팀이어야 합니다. 테스트 팀은 다음을 책임집니다.
-
블랙 박스 테스트. 유스 케이스의 이벤트 플로우를 기반으로 시스템 외부에서 유스 케이스를 테스트(중간 산출물: 유스
케이스 참조).
-
화이트 박스 테스트. 시나리오에 대한 시퀀스 보기를 기반으로 유스 케이스에서 실제 메시지 전송을 테스트.
-
시스템 테스트. 시스템이 본래의 특성을 나타내도록 압박.
테스트는 단지 테스트를 실행하는 것이 아닙니다. 테스트 환경을 준비하고 테스트 스펙을 작성하고 검사하는 것이기도 합니다.
독립 그룹은 유스 케이스와 전체 시스템을 테스트해야 합니다. 테스트를 수행하고 테스트 보고서도 작성해야 합니다. 한 사람이 각 유스 케이스 테스트 책임을 지도록 유스 케이스 테스트를 구성해야 합니다.
소규모 프로젝트에서 처럼 독립 그룹이 유스 케이스를 테스트하는 것이 불가능할 경우, 적어도 디자인 시 유스 케이스를 책임지는 사람이 유스 케이스를 테스트하지 않도록 해야 합니다.
중대규모 프로젝트에서는 자동 회귀 테스트를 사용해야 합니다. 이 기능을 지원하려면 테스트 팀에 일부 프로그래머가 필요합니다. 이는 반복 개발 중에 동일한 테스트 스위트를 계속해서 재실행하느라 많은 노력을 소비하지
않으려는 경우 훨씬 더 중요합니다.
전이 단계에서는 개발 작업이 완료됩니다. 베타 테스트를 수행하고 최종 릴리스를 준비합니다. 구현/구축(Construction) 단계에서 작업을 훌륭히 수행한 경우, 프로젝트 팀은 다시 크기를 조정하여 개발자와
테스터 수를 줄일 수 있습니다. 제품을 사용자 커뮤니티에 배치하는 책임을 지고 있는 하부 구조 물류 전문가와 트레이너를 위해 팀 혼합이 변경됩니다.
소프트웨어 설계자 또는 아키텍처 팀은 "사후 관리 모드"로 작업합니다. 문제점 보고서를 분류하고 변경 제안서의 우선순위를 결정하며, 편의를 위해 아키텍처를 손상시키는 식으로 문제점이 수정되지 않도록 순서를
변경하도록 돕습니다. 전이 단계 중 디자인 타스크는 줄어들며, 문제점을 정정하거나 최종 개선사항을 도입하는 것으로 제한됩니다.
|