소프트웨어 프로젝트 관리

소프트웨어 개발에 종사하는 IT 회사의 업무 패턴은 두 부분으로 나뉩니다.

소프트웨어 생성
소프트웨어 프로젝트 관리

프로젝트는 목표를 달성하기 위해 수행되는 여러 작업 (예 : 소프트웨어 개발 및 제공)의 모음 인 잘 정의 된 작업입니다. 프로젝트의 특징은 다음과 같습니다.

모든 프로젝트에는 고유하고 뚜렷한 목표가있을 수 있습니다.
프로젝트는 일상적인 활동이나 일상적인 작업이 아닙니다.
프로젝트에는 시작 시간과 종료 시간이 있습니다.
프로젝트는 목표가 달성되면 종료되므로 조직 수명의 일시적인 단계입니다.
프로젝트에는 시간, 인력, 재무, 재료 및 지식 은행 측면에서 적절한 자원이 필요합니다.

소프트웨어 프로젝트

소프트웨어 프로젝트는 요구 사항 수집에서 테스트 및 유지 관리에 이르기까지 소프트웨어 개발의 전체 절차로, 의도 된 소프트웨어 제품을 달성하기 위해 지정된 기간 동안 실행 방법론에 따라 수행됩니다.

소프트웨어 프로젝트 관리의 필요성

소프트웨어는 무형의 제품이라고합니다. 소프트웨어 개발은 세계 비즈니스에서 일종의 완전히 새로운 흐름이며 소프트웨어 제품을 구축하는 데 경험이 거의 없습니다. 대부분의 소프트웨어 제품은 고객의 요구 사항에 맞게 맞춤 제작됩니다. 가장 중요한 것은 기본 기술이 너무 자주 빠르게 변화하고 발전하여 한 제품의 경험이 다른 제품에 적용되지 않을 수 있다는 것입니다. 이러한 모든 비즈니스 및 환경 적 제약은 소프트웨어 개발에 위험을 초래하므로 소프트웨어 프로젝트를 효율적으로 관리하는 것이 필수적입니다.

위 이미지는 소프트웨어 프로젝트에 대한 삼중 제약을 보여줍니다. 양질의 제품을 제공하고 비용을 고객의 예산 내에서 유지하고 일정에 따라 프로젝트를 제공하는 것은 소프트웨어 조직의 필수 부분입니다. 이 삼중 제약 삼각형에 영향을 줄 수있는 내부 및 외부 요인이 여러 개 있습니다. 세 가지 요소 중 하나가 다른 두 요소에 심각한 영향을 미칠 수 있습니다.

따라서 소프트웨어 프로젝트 관리는 예산 및 시간 제약과 함께 사용자 요구 사항을 통합하는 데 필수적입니다.

소프트웨어 프로젝트 관리자

소프트웨어 프로젝트 관리자는 소프트웨어 프로젝트를 실행하는 책임을 맡은 사람입니다. 소프트웨어 프로젝트 관리자는 소프트웨어가 거치는 SDLC의 모든 단계를 철저히 알고 있습니다. 프로젝트 관리자는 최종 제품 생산에 직접 관여 할 수 없지만 생산과 관련된 활동을 제어하고 관리합니다.

프로젝트 관리자는 비용, 예산, 자원, 시간, 품질 및 고객 만족 문제를 해결하기 위해 개발 프로세스를 면밀히 모니터링하고, 다양한 계획을 준비 및 실행하고, 필요하고 적절한 리소스를 준비하고, 모든 팀 구성원 간의 의사 소통을 유지합니다.

프로젝트 관리자가 담당하는 책임을 몇 가지 살펴 보겠습니다.

사람 관리

프로젝트 리더 역할
이해 관계자와의 연락
인적 자원 관리
보고 계층 등 설정

프로젝트 관리

프로젝트 범위 정의 및 설정
프로젝트 관리 활동 관리
진행 상황 및 성과 모니터링
모든 단계에서 위험 분석
문제를 피하거나 해결하기 위해 필요한 조치를 취하십시오.
프로젝트 대변인 역할

소프트웨어 관리 활동

소프트웨어 프로젝트 관리는 프로젝트 계획, 소프트웨어 제품 범위 결정, 다양한 용어의 비용 추정, 작업 및 이벤트 일정 수립, 자원 관리를 포함하는 여러 활동으로 구성됩니다. 프로젝트 관리 활동에는 다음이 포함될 수 있습니다.

Project Planning
Scope Management
Project Estimation

프로젝트 기획

소프트웨어 프로젝트 계획은 소프트웨어 생산이 실제로 시작되기 전에 수행되는 작업입니다. 그것은 소프트웨어 생산을위한 것이지만 소프트웨어 생산과 어떤 방향 으로든 연결되는 구체적인 활동은 포함하지 않습니다. 오히려 소프트웨어 생산을 용이하게하는 여러 프로세스의 집합입니다. 프로젝트 계획에는 다음이 포함될 수 있습니다.

범위 관리

프로젝트의 범위를 정의합니다. 여기에는 제공 가능한 소프트웨어 제품을 만들기 위해 수행해야하는 모든 활동, 프로세스가 포함됩니다. 범위 관리는 프로젝트에서 수행 할 작업과 수행하지 않을 작업을 명확하게 정의하여 프로젝트의 경계를 만들기 때문에 필수적입니다. 따라서 프로젝트에 제한적이고 정량화 가능한 작업이 포함되어 쉽게 문서화 할 수 있으며 비용과 시간 초과를 방지 할 수 있습니다.

프로젝트 범위 관리 중에 다음을 수행해야합니다.

범위 정의
확인 및 제어 결정
관리의 용이성을 위해 프로젝트를 여러 작은 부분으로 나눕니다.
범위 확인
범위 변경 사항을 통합하여 범위 제어

프로젝트 추정

효과적인 관리를 위해서는 다양한 조치의 정확한 추정이 필수입니다. 정확한 견적을 통해 관리자는 프로젝트를보다 효율적이고 효과적으로 관리하고 제어 할 수 있습니다.

프로젝트 추정에는 다음이 포함될 수 있습니다.

Software size estimation
소프트웨어 크기는 KLOC (Kilo Line of Code) 또는 소프트웨어의 기능 포인트 수를 계산하여 추정 할 수 있습니다. 코드 줄은 코딩 관행에 따라 다르며 기능 포인트는 사용자 또는 소프트웨어 요구 사항에 따라 다릅니다.
Effort estimation
관리자는 소프트웨어를 생산하는 데 필요한 인력 요구 사항과 인건비 측면에서 노력을 추정합니다. 노력 추정 소프트웨어 크기를 알고 있어야합니다. 이것은 관리자의 경험, 조직의 과거 데이터 또는 소프트웨어 크기에 의해 파생 될 수 있으며 일부 표준 공식을 사용하여 노력으로 변환 될 수 있습니다.
Time estimation
크기와 노력이 추정되면 소프트웨어를 생산하는 데 필요한 시간을 추정 할 수 있습니다. 필요한 노력은 요구 사항 사양 및 소프트웨어의 다양한 구성 요소의 상호 의존성에 따라 하위 범주로 구분됩니다. 소프트웨어 작업은 WBS (Work Breakthrough Structure)에 따라 작은 작업, 활동 또는 이벤트로 나뉩니다. 작업은 매일 또는 달력 달로 예약됩니다.

모든 작업을 몇 시간 또는 며칠 내에 완료하는 데 필요한 시간의 합계는 프로젝트를 완료하는 데 투자 된 총 시간입니다.
Cost estimation
이것은 이전 요소보다 더 많은 요소에 의존하기 때문에 가장 어려운 것으로 간주 될 수 있습니다. 프로젝트 비용을 추정하려면 다음 사항을 고려해야합니다.

소프트웨어 크기
소프트웨어 품질
Hardware
추가 소프트웨어 또는 도구, 라이선스 등
작업 별 기술을 갖춘 숙련 된 인력
관련된 여행
Communication
교육 및 지원

프로젝트 추정 기법

규모, 노력, 시간 및 비용과 같은 프로젝트 추정과 관련된 다양한 매개 변수에 대해 논의했습니다.

프로젝트 관리자는 널리 알려진 두 가지 기술을 사용하여 나열된 요소를 추정 할 수 있습니다.

분해 기법

이 기술은 소프트웨어를 다양한 구성의 제품으로 가정합니다.

두 가지 주요 모델이 있습니다.

Line of Code 추정은 소프트웨어 제품의 코드 줄 수를 대신하여 수행됩니다.
Function Points 추정은 소프트웨어 제품의 기능 포인트 수를 대신하여 수행됩니다.

경험적 추정 기법

이 기법은 경험적으로 도출 된 공식을 사용하여 추정하며, 이러한 공식은 LOC 또는 FP를 기반으로합니다.

Putnam Model
이 모델은 Norden의 주파수 분포 (Rayleigh 곡선)를 기반으로하는 Lawrence H. Putnam에 의해 만들어졌습니다. Putnam 모델은 소프트웨어 크기에 필요한 시간과 노력을 매핑합니다.
COCOMO
COCOMO는 Barry W. Boehm이 개발 한 COnstructive COst MOdel의 약자입니다. 소프트웨어 제품을 유기적, 반 분리형 및 내장형의 세 가지 범주로 나눕니다.

프로젝트 일정

프로젝트의 프로젝트 스케줄링은 지정된 순서로 각 활동에 할당 된 시간 슬롯 내에서 수행 할 모든 활동의 로드맵을 나타냅니다. 프로젝트 관리자는 다양한 작업과 프로젝트 이정표를 정의하고 다양한 요소를 염두에두고 정렬하는 경향이 있습니다. 그들은 일정에서 중요한 경로에있는 작업을 찾습니다.이 작업은 특정 방식으로 (작업 상호 의존성 때문에) 완료해야하며 엄격하게 할당 된 시간 내에 완료해야합니다. 중요한 경로를 벗어난 작업의 배열은 프로젝트의 모든 일정에 영향을 줄 가능성이 적습니다.

프로젝트를 예약하려면 다음을 수행해야합니다.

프로젝트 작업을 더 작고 관리하기 쉬운 형식으로 분류
다양한 작업을 찾아 상호 연결
각 작업에 필요한 시간 프레임 추정
시간을 작업 단위로 나누십시오.
각 작업에 적절한 수의 작업 단위 할당
프로젝트 시작부터 완료까지 필요한 총 시간 계산

자원 관리

소프트웨어 제품을 개발하는 데 사용되는 모든 요소는 해당 프로젝트의 자원으로 간주 될 수 있습니다. 여기에는 인적 자원, 생산 도구 및 소프트웨어 라이브러리가 포함될 수 있습니다.

자원은 제한된 수량으로 제공되며 자산 풀로 조직에 머물러 있습니다. 자원 부족은 프로젝트 개발을 방해하고 일정보다 지연 될 수 있습니다. 추가 리소스를 할당하면 결국 개발 비용이 증가합니다. 따라서 프로젝트를위한 적절한 자원을 추정하고 할당하는 것이 필요합니다.

자원 관리에는 다음이 포함됩니다.

프로젝트 팀을 구성하고 각 팀원에게 책임을 할당하여 적절한 조직 프로젝트 정의
특정 단계에 필요한 리소스 및 가용성 결정
리소스가 필요할 때 리소스 요청을 생성하고 더 이상 필요하지 않을 때는 할당을 해제하여 리소스를 관리합니다.

프로젝트 위험 관리

위험 관리에는 프로젝트에서 예측 가능하고 예측 불가능한 위험을 식별, 분석 및 제공하는 것과 관련된 모든 활동이 포함됩니다. 위험에는 다음이 포함될 수 있습니다.

경험 많은 직원이 프로젝트를 떠나고 새로운 직원이 들어옵니다.
조직 관리의 변화.
요구 사항 변경 또는 요구 사항 잘못 해석.
필요한 시간과 자원의 과소 평가.
기술 변화, 환경 변화, 비즈니스 경쟁.

리스크 관리 프로세스

위험 관리 프로세스에는 다음과 같은 활동이 있습니다.

Identification - 프로젝트에서 발생할 수있는 모든 가능한 위험을 기록하십시오.
Categorize - 프로젝트에 미칠 수있는 영향에 따라 알려진 위험을 높음, 중간 및 낮음 강도로 분류합니다.
Manage - 다양한 단계에서 위험 발생 확률을 분석합니다. 위험을 피하거나 직면 할 계획을 세우십시오. 부작용을 최소화하십시오.
Monitor - 잠재적 위험과 초기 증상을 면밀히 모니터링하십시오. 또한이를 완화하거나 피하기 위해 취한 조치의 효과를 모니터링하십시오.

프로젝트 실행 및 모니터링

이 단계에서는 프로젝트 계획에 설명 된 작업이 일정에 따라 실행됩니다.

모든 것이 계획대로 진행되고 있는지 확인하려면 실행을 모니터링해야합니다. 모니터링은 위험 가능성을 확인하기 위해 관찰하고 위험을 해결하거나 다양한 작업의 상태를보고하기위한 조치를 취하는 것입니다.

이러한 조치에는 다음이 포함됩니다.

Activity Monitoring - 일부 작업 내에서 예약 된 모든 활동은 매일 모니터링 할 수 있습니다. 작업의 모든 활동이 완료되면 완료된 것으로 간주됩니다.
Status Reports - 보고서에는 주어진 시간 프레임 (일반적으로 1 주일) 내에 완료된 활동 및 작업의 상태가 포함됩니다. 상태는 완료, 보류 또는 진행 중 등으로 표시 될 수 있습니다.
Milestones Checklist - 모든 프로젝트는 SDLC의 단계에 따라 주요 작업이 수행되는 여러 단계 (이정표)로 나뉩니다. 이 마일스톤 체크리스트는 몇 주에 한 번씩 준비되며 마일스톤 상태를보고합니다.

프로젝트 커뮤니케이션 관리

효과적인 의사 소통은 프로젝트의 성공에 중요한 역할을합니다. 하드웨어 공급 업체와 같은 프로젝트의 다른 이해 관계자뿐만 아니라 팀 구성원 간의 클라이언트와 조직 간의 격차를 해소합니다.

의사 소통은 구두 또는 서면으로 할 수 있습니다. 통신 관리 프로세스에는 다음 단계가있을 수 있습니다.

Planning -이 단계에는 프로젝트의 모든 이해 관계자의 식별과 이들 간의 의사 소통 방식이 포함됩니다. 추가 통신 시설이 필요한지 여부도 고려합니다.
Sharing -기획의 다양한 측면을 결정한 후 관리자는 정확한 시간에 정확한 사람과 정확한 정보를 공유하는 데 집중합니다. 이를 통해 프로젝트에 참여한 모든 사람이 프로젝트 진행 상황과 상태를 최신 상태로 유지할 수 있습니다.
Feedback -프로젝트 관리자는 다양한 측정 및 피드백 메커니즘을 사용하고 상태 및 성과 보고서를 작성합니다. 이 메커니즘은 다양한 이해 관계자의 의견이 프로젝트 관리자에게 피드백으로 전달되도록합니다.
Closure -각 주요 이벤트가 끝날 때, SDLC 단계가 끝날 때 또는 프로젝트 자체가 끝날 때, 이메일을 보내거나 문서의 하드 카피를 배포하거나 기타 효과적인 커뮤니케이션 수단을 통해 모든 이해 관계자를 업데이트하기 위해 행정적 폐쇄가 공식적으로 발표됩니다.

종료 후 팀은 다음 단계 또는 프로젝트로 이동합니다.

구성 관리

구성 관리는 제품의 요구 사항, 디자인, 기능 및 개발 측면에서 소프트웨어의 변경 사항을 추적하고 제어하는 프로세스입니다.

IEEE는이를 "시스템에서 항목을 식별 및 정의하고, 수명주기 동안 이러한 항목의 변경을 제어하고, 항목 및 변경 요청의 상태를 기록 및보고하고, 항목의 완전성과 정확성을 확인하는 프로세스"로 정의합니다.

일반적으로 SRS가 완료되면 사용자의 변경 요구 사항이 적습니다. 변경 사항이 발생하면 비용 및 시간 초과 가능성이 있으므로 상위 경영진의 사전 승인을 통해서만 변경 사항을 처리합니다.

기준

기준선이있는 경우 SDLC의 단계가 가정됩니다. 즉 기준선은 단계의 완전성을 정의하는 측정입니다. 단계는 관련된 모든 활동이 완료되고 잘 문서화 될 때 기준이됩니다. 최종 단계가 아니라면 출력은 다음 단계에서 사용됩니다.

구성 관리는 한 단계가 기준이 된 후 모든 변경 (프로세스, 요구 사항, 기술, 전략적 등)의 발생을 처리하는 조직 관리 분야입니다. CM은 소프트웨어의 변경 사항을 계속 확인합니다.

변경 제어

변경 제어는 구성 관리의 기능으로, 소프트웨어 시스템에 대한 모든 변경 사항이 일관되고 조직 규칙 및 규정에 따라 이루어 지도록합니다.

제품 구성 변경은 다음 단계를 거칩니다.

Identification-내부 또는 외부 소스에서 변경 요청이 도착합니다. 변경 요청이 공식적으로 식별되면 적절하게 문서화됩니다.
Validation -변경 요청의 유효성을 확인하고 처리 절차를 확인합니다.
Analysis-일정, 비용 및 필요한 노력 측면에서 변경 요청의 영향을 분석합니다. 시스템에 대한 예상 변경의 전반적인 영향이 분석됩니다.
Control-예상 변경이 시스템의 너무 많은 주체에 영향을 미치거나 불가피한 경우 변경이 시스템에 통합되기 전에 고위 당국의 승인을 받아야합니다. 그 변화가 합병의 가치가 있는지 아닌지 결정됩니다. 그렇지 않은 경우 변경 요청이 공식적으로 거부됩니다.
Execution -이전 단계에서 변경 요청을 실행하기로 결정한 경우이 단계는 변경을 실행하기 위해 적절한 조치를 취하고 필요한 경우 철저한 수정을 수행합니다.
Close request-변경 사항이 올바른 구현을 위해 확인되고 나머지 시스템과 병합됩니다. 소프트웨어에 새로 통합 된이 변경 사항은 적절하게 문서화되고 요청은 공식적으로 종료됩니다.

프로젝트 관리 도구

프로젝트가 정해진 방법론에 따라 개발 되더라도 프로젝트 규모에 따라 위험과 불확실성이 여러 배로 증가합니다.

효과적인 프로젝트 관리에 도움이되는 도구가 있습니다. 몇 가지가 설명되어 있습니다.

간트 차트

Gantt 차트는 Henry Gantt (1917)에 의해 고안되었습니다. 기간에 대한 프로젝트 일정을 나타냅니다. 프로젝트 활동에 대해 예약 된 활동 및 시간을 나타내는 막대가있는 가로 막대 차트입니다.

PERT 차트

PERT (Program Evaluation & Review Technique) 차트는 프로젝트를 네트워크 다이어그램으로 묘사하는 도구입니다. 프로젝트의 주요 이벤트를 병렬 및 연속 방식으로 그래픽으로 표현할 수 있습니다. 차례로 발생하는 이벤트는 이전 이벤트에 대한 이후 이벤트의 종속성을 보여줍니다.

이벤트는 번호가 매겨진 노드로 표시됩니다. 프로젝트의 작업 순서를 나타내는 레이블이 지정된 화살표로 연결됩니다.

리소스 히스토그램

이는 프로젝트 이벤트 (또는 단계)에 대해 시간이 지남에 따라 필요한 리소스 (일반적으로 숙련 된 직원) 수를 나타내는 막대 또는 차트가 포함 된 그래픽 도구입니다. 리소스 히스토그램은 직원 계획 및 조정을위한 효과적인 도구입니다.

중요 경로 분석

이 도구는 프로젝트에서 상호 의존적 인 작업을 인식하는 데 유용합니다. 또한 프로젝트를 성공적으로 완료하기위한 최단 경로 또는 중요 경로를 찾는 데 도움이됩니다. PERT 다이어그램과 마찬가지로 각 이벤트에는 특정 시간 프레임이 할당됩니다. 이 도구는 이전 이벤트가 완료된 경우에만 이벤트가 다음으로 진행될 수 있다고 가정하여 이벤트의 종속성을 표시합니다.

이벤트는 가능한 가장 빠른 시작 시간에 따라 정렬됩니다. 시작 노드와 끝 노드 사이의 경로는 더 이상 줄일 수없는 중요한 경로이며 모든 이벤트는 동일한 순서로 실행되어야합니다.