개요

이 글은 소프트웨어 회사의 유지보수 프로젝트를 위한 자동화 프로젝트를 다룹니다. 이 프로젝트는 이러한 목적으로 개발된 도구를 사용하여 분산되고 이질적인 프로세스를 중앙 집중식 모니터링 메커니즘으로 자동화하는 것을 포함합니다.

이 문서에서는 네트워크 다이어그램과 작업 분할 구조와 함께 리소스 및 일정 계획과 같은 범위와 다양한 측면을 나열합니다.

프로젝트 범위

본 프로젝트의 범위는 업무 흐름의 프로세스를 중앙 집중화하는 자동화 도구를 개발하는 것입니다. 여기에는 다음이 포함됩니다.

• 이러한 목적에 필요한 대시보드와 데이터베이스를 개발합니다.

• SLA 준수 및 처리량 정의를 위한 프로세스 모니터링을 포함한 기능적 요구 사항을 나열합니다.

• 다양한 관리 계층에 대해 다양한 수준의 제어를 통해 액세스 권한을 유지합니다.

시간 관리 및 기타 관리 기능은 도구의 일부가 아니므로 범위에 포함되지 않습니다. 범위는 위에서 설명한 프런트엔드 및 백엔드 구성 요소를 포함하는 결과물의 출력과 직접적으로 관련됩니다.

자원 및 일정 계획

이 프로젝트에는 개발팀을 감독하는 팀 리더를 포함하여 프로젝트에 전담된 6명의 리소스로 구성된 팀이 필요합니다.

자원은 두 팀으로 나뉩니다.

1. 한 팀은 설계와 개발을 담당하고, 다른 팀은 요구 사항과 테스트 측면을 담당합니다.

2. 두 번째 팀은 요구 사항을 매핑하고 이를 첫 번째 팀에서 사용 가능한 사양으로 변환하는 기능적 전문 지식을 보유하게 됩니다.

또한 이 팀의 전문지식은 테스트에도 활용되며, 이들은 테스트의 범위와 기능적 측면을 이해합니다.

프로젝트 일정은 두 달입니다. 처음 몇 주는 다양한 이해관계자들의 요구사항을 검토하는 데 소요되고, 그 다음 달은 실제 설계 및 코딩에 사용됩니다. 마지막 몇 주는 도구 테스트 및 구현에 사용됩니다.

네트워크 다이어그램

중요 경로는 위에 나열된 것과 같습니다. 이 프로젝트는 직접 개발(Straight Through Development)을 포함하므로 중요 경로는 SDLC 단계의 중요 경로와 동일합니다.

일정이 갑작스럽게 중단되는 효과

일정이 겹칠 경우, 요구 사항 단계를 병렬 활동을 통해 설계 단계와 통합할 수 있습니다. 이를 위해서는 SDLC의 일반적인 "폭포수" 모델을 벗어나 애자일 방법론을 도입해야 합니다.

리소스 로딩 레벨의 효과

두 팀의 리소스는 리소스의 기술 세트가 동일해야 한다는 요구 사항에 따라 상호 교환하여 사용할 수 있습니다.

위험 평가

이 프로젝트의 위험 관리 계획에는 다음 항목을 잠재적 위험으로 나열하고 이를 완화하는 계획이 포함됩니다.

• 자원 위험: 지식 습득 및 이탈 위험 측면에서 두 가지 요소로 구분됩니다. 첫 번째 요소는 교육 및 지식 공유를 통해 완화되고, 두 번째 요소는 프로세스 문서화 및 지식 관리를 통해 완화됩니다.

• 스코프 크리프: 범위에 대한 모든 변경 사항은 모든 이해 관계자의 승인을 받아야 하며 비용은 공유해야 합니다.

• 변화: 시간, 비용 또는 품질 제약("삼중 제약")으로 인한 예산 변동은 모든 이해관계자가 해결해야 합니다. 이는 정기적인 현황 보고와 다양한 이해관계자가 해결해야 할 잠재적 문제 파악을 통해 이루어져야 합니다.

• 기술: 기술의 변화는 프로젝트에 즉각적인 위험을 초래할 수 있으므로, 이에 적합한 기술을 선택해야 합니다.

맺음말

이 글에서는 소프트웨어 회사의 유지 관리 프로젝트에 자동화 도구를 활용한 사례를 통해 프로젝트 관리 프로세스의 몇 가지 측면을 살펴보았습니다. 이 글이 포괄적이지는 않지만, 과제에 제시된 몇 가지 질문에 대한 해답을 제시하고 있습니다.