소프트웨어 프로젝트 관리

소프트웨어 프로젝트 관리(software project management)는 소프트웨어 프로젝트를 계획하고 이끄는 과정이다.^[1] 이는 소프트웨어 프로젝트가 계획, 구현, 모니터링 및 제어되는 프로젝트 관리의 하위 분야이다.

역사

1970년대와 1980년대에 소프트웨어 산업은 매우 빠르게 성장했다. 컴퓨터 회사들은 하드웨어 생산 및 회로에 비해 소프트웨어 생산 비용이 상대적으로 낮다는 것을 빠르게 인식했기 때문이다. 새로운 개발 노력을 관리하기 위해 회사들은 기존의 프로젝트 관리 방법을 적용했지만, 특히 사용자 사양과 납품된 소프트웨어 사이의 회색 지대에서 혼란이 발생했을 때 테스트 실행 중에 프로젝트 일정이 지연되었다. 이러한 문제를 피하기 위해 소프트웨어 프로젝트 관리 방법은 현재 폭포수 모델로 알려진 방식으로 사용자 요구 사항을 납품된 제품에 맞추는 데 중점을 두었다.

산업이 성숙함에 따라 소프트웨어 프로젝트 관리 실패 분석은 다음과 같은 가장 흔한 원인을 보여주었다:^[2][3][4]

1. 불충분한 최종 사용자 참여
2. 고객, 개발자, 사용자 및 프로젝트 매니저 간의 의사소통 불량
3. 비현실적이거나 명확하지 않은 프로젝트 목표
4. 필요한 자원에 대한 추정 부정확
5. 불분명하거나 불완전한 시스템 요구 사항 및 사양
6. 프로젝트 상태 보고 불량
7. 잘못 관리된 위험
8. 미성숙한 기술 사용
9. 프로젝트 복잡성 처리 능력 부족
10. 허술한 개발 관행
11. 이해관계자 정치 (예: 경영진 지원 부재 또는 고객과 최종 사용자 간의 정치)
12. 상업적 압력

위 목록의 첫 다섯 항목은 적절한 자원이 적절한 프로젝트 목표를 달성할 수 있도록 클라이언트의 요구 사항을 명확하게 표현하는 데 어려움이 있음을 보여준다. 특정 소프트웨어 프로젝트 관리 도구는 유용하고 종종 필요하지만, 소프트웨어 프로젝트 관리의 진정한 예술은 올바른 방법을 적용하고 그 방법을 지원하기 위해 도구를 사용하는 것이다. 방법 없이는 도구는 가치가 없다. 1960년대 이래로 여러 독점 소프트웨어 프로젝트 관리 방법이 소프트웨어 제조업체에 의해 자체적으로 개발되었으며, 컴퓨터 컨설팅 회사도 고객을 위해 유사한 방법을 개발했다. 오늘날 소프트웨어 프로젝트 관리 방법은 여전히 발전하고 있지만, 현재 추세는 폭포수 모델에서 벗어나 소프트웨어 개발 프로세스를 모방한 보다 주기적인 프로젝트 납품 모델로 향하고 있다.

소프트웨어 개발 프로세스

소프트웨어 개발 프로세스는 소프트웨어 도구와 같은 기술적 측면과 달리 주로 소프트웨어 개발의 생산 측면과 관련이 있다. 이러한 프로세스는 주로 소프트웨어 개발 관리를 지원하기 위해 존재하며, 일반적으로 비즈니스 문제 해결에 중점을 둔다. 많은 소프트웨어 개발 프로세스는 일반적인 프로젝트 관리 프로세스와 유사한 방식으로 실행될 수 있다. 예시는 다음과 같다.

• 대인 커뮤니케이션과 갈등 관리 및 해결. 적극적이고 빈번하며 솔직한 커뮤니케이션은 프로젝트 성공 가능성을 높이고 문제가 있는 프로젝트를 완화하는 데 가장 중요한 요소이다. 개발팀은 최종 사용자 참여를 유도하고 개발 프로세스에 사용자 의견을 장려해야 한다. 사용자 참여가 없으면 요구 사항 오해, 변화하는 고객 요구에 대한 둔감함, 클라이언트 측의 비현실적인 기대로 이어질 수 있다. 소프트웨어 개발자, 사용자, 프로젝트 관리자, 고객 및 프로젝트 스폰서는 정기적으로 자주 소통해야 한다. 이러한 논의에서 얻은 정보는 프로젝트 팀이 강점, 약점, 기회 및 위협(SWOT)을 분석하고 그 정보를 바탕으로 기회를 활용하고 위협을 최소화하도록 행동할 수 있게 한다. 심지어 나쁜 소식이라도 비교적 일찍 전달된다면 좋을 수 있는데, 너무 늦게 발견되지 않으면 문제가 완화될 수 있기 때문이다. 예를 들어, 사용자, 팀 구성원 및 기타 이해 관계자와의 비공식적인 대화는 공식 회의보다 잠재적인 문제를 더 빨리 드러내는 경우가 많다. 모든 커뮤니케이션은 지적으로 정직하고 진정성 있어야 하며, 차분하고 존중하며 건설적이고 비난하지 않으며 화내지 않는 방식으로 제공되는 한, 개발 작업에 대한 정기적이고 빈번하며 고품질 비판이 필요하다. 개발자와 최종 사용자 간, 프로젝트 관리자와 클라이언트 간의 빈번한 비공식 커뮤니케이션은 프로젝트가 최종 사용자에게 관련성 있고 유용하며 효과적으로 유지되도록 하고, 완료 가능한 범위 내에 있도록 하는 데 필요하다. 효과적인 대인 커뮤니케이션과 갈등 관리 및 해결은 소프트웨어 프로젝트 관리의 핵심이다. 어떤 방법론이나 프로세스 개선 전략도 커뮤니케이션 또는 대인 갈등의 심각한 문제를 극복할 수 없다. 또한, 그러한 방법론 및 프로세스 개선 전략과 관련된 결과는 더 나은 커뮤니케이션으로 향상된다. 커뮤니케이션은 팀이 프로젝트 헌장을 이해하고 있는지, 그리고 팀이 그 목표를 향해 나아가고 있는지에 초점을 맞춰야 한다. 최종 사용자, 소프트웨어 개발자 및 프로젝트 관리자는 문제가 재앙 수준으로 악화되기 전에 문제를 식별하는 데 도움이 되는 기본적이고 간단한 질문을 자주 해야 한다. 최종 사용자 참여, 효과적인 커뮤니케이션 및 협동이 충분하지는 않지만, 좋은 결과를 보장하기 위해서는 필수적이며, 이들이 없으면 거의 확실히 나쁜 결과로 이어진다.^[3][4][5]
• 위험관리는 위험을 측정하거나 평가한 다음 위험을 관리하기 위한 전략을 개발하는 과정이다. 일반적으로 사용되는 전략에는 위험을 다른 당사자에게 이전하거나, 위험을 피하거나, 위험의 부정적인 영향을 줄이거나, 특정 위험의 결과 중 일부 또는 전부를 수용하는 것이 포함된다. 소프트웨어 프로젝트 관리에서 위험 관리는 프로젝트 시작을 위한 사업 계획으로 시작하며, 여기에는 비용-편익 분석과 비상 계획이라고 불리는 프로젝트 실패 시의 대안 목록이 포함된다.
  • 위험 관리의 하위 집합은 기회 관리인데, 이는 잠재적 위험 결과가 부정적인 영향 대신 긍정적인 영향을 미친다는 점을 제외하고는 동일한 의미이다. 이론적으로는 동일한 방식으로 처리되지만, 다소 부정적인 용어인 "위험" 대신 "기회"라는 용어를 사용하면 팀이 파생 프로젝트, 횡재, 무료 추가 자원 등 프로젝트의 특정 위험 등록부에서 가능한 긍정적인 결과에 집중할 수 있도록 돕는다.
• 요구사항 관리는 요구사항을 식별하고, 도출하고, 문서화하고, 분석하고, 추적하고, 우선순위를 지정하고, 합의한 다음 변경 사항을 제어하고 관련 이해관계자에게 전달하는 과정이다. 새로운 또는 변경된 컴퓨터 시스템^[1] 요구사항 관리( 요구사항 분석 포함)는 소프트웨어 공학 프로세스의 중요한 부분으로, 비즈니스 분석가 또는 소프트웨어 개발자가 클라이언트의 필요 또는 요구사항을 식별하고, 이러한 요구사항을 식별한 후 솔루션을 설계할 수 있게 된다.
• 변화관리는 범위 (프로젝트 관리)에 대한 변경 사항을 식별, 문서화, 분석, 우선순위 지정 및 합의한 다음 변경 사항을 제어하고 관련 이해관계자에게 전달하는 과정이다. 변경 수준에서 요구사항 분석을 포함하는 새로운 또는 변경된 범위에 대한 변경 영향 분석은 소프트웨어 공학 프로세스의 중요한 부분으로, 비즈니스 분석가 또는 소프트웨어 개발자가 클라이언트의 변경된 필요 또는 요구사항을 식별하고, 이러한 요구사항을 식별한 후 솔루션을 재설계하거나 수정할 수 있게 된다. 이론적으로 각 변경 사항은 소프트웨어 프로젝트의 타임라인과 예산에 영향을 미칠 수 있으므로, 승인 전에 위험-편익 분석을 포함해야 한다.
• 소프트웨어 구성 관리는 진행 중인 소프트웨어 제품 자체인 범위를 식별하고 문서화하는 과정으로, 모든 하위 제품 및 변경 사항을 포함하고 이를 관련 이해관계자에게 전달할 수 있도록 한다. 일반적으로 사용되는 프로세스에는 버전 관리, 명명 규칙 (프로그래밍) 및 소프트웨어 아카이브 계약이 포함된다.
• 릴리스 관리는 소프트웨어 릴리스를 식별, 문서화, 우선순위 지정 및 합의한 다음 릴리스 일정을 제어하고 관련 이해관계자에게 전달하는 과정이다. 대부분의 소프트웨어 프로젝트는 소프트웨어를 릴리스할 수 있는 세 가지 소프트웨어 환경(개발, 테스트, 프로덕션)에 접근할 수 있다. 분산된 팀이 사용자에게 릴리스하기 전에 작업을 통합해야 하는 매우 큰 프로젝트에서는 사용자 승인 테스트 (UAT)로 릴리스하기 전에 유닛 테스트, 시스템 테스트 또는 통합 시험이라고 불리는 더 많은 테스트 환경이 있는 경우가 많다.
  • 릴리스 관리의 하위 집합 중 하나로 데이터 관리가 주목을 받고 있다. 사용자는 자신이 아는 데이터에만 기반하여 테스트할 수 있으며, "실제" 데이터는 "프로덕션"이라는 소프트웨어 환경에만 존재하기 때문이다. 따라서 프로그래머는 작업을 테스트하기 위해 종종 "더미 데이터" 또는 "데이터 스텁"을 생성해야 한다. 전통적으로는 이전 버전의 프로덕션 시스템이 이 목적으로 사용되었지만, 기업이 소프트웨어 개발을 외부 기여자에게 점점 더 의존함에 따라 회사 데이터가 개발 팀에 공개되지 않을 수 있다. 복잡한 환경에서는 전체 소프트웨어 릴리스 일정과 마찬가지로 테스트 릴리스 일정에 따라 테스트 환경 전반으로 마이그레이션되는 데이터 세트가 생성될 수 있다.
• 유지보수 및 업데이트는 요구사항과 고객의 요구가 항상 진화하는 과정이다. 그들은 의심할 여지 없이 버그를 발견하고, 새로운 기능을 요청하며, 다른 기능과 더 많은 업데이트를 요구할 것이다. 따라서 이러한 모든 요청은 고객의 요구사항과 만족도를 확인하고 충족해야 한다.

프로젝트 계획, 실행, 모니터링 및 제어

프로젝트 계획의 목적은 프로젝트 범위를 식별하고, 수행할 작업을 추정하고, 프로젝트 일정을 만드는 것이다. 프로젝트 계획은 개발할 소프트웨어를 정의하는 요구사항으로 시작된다. 그런 다음 프로젝트 계획이 개발되어 완료로 이어질 작업을 설명한다. 프로젝트 실행은 프로젝트 계획에 정의된 작업을 완료하는 과정이다.

프로젝트 모니터링 및 제어의 목적은 팀과 관리자가 프로젝트 진행 상황을 최신 상태로 유지하는 것이다. 프로젝트가 계획에서 벗어나면 프로젝트 관리자는 문제를 해결하기 위한 조치를 취할 수 있다. 프로젝트 모니터링 및 제어에는 팀으로부터 상태를 수집하기 위한 상태 회의가 포함된다. 변경이 필요한 경우, 변경 관리를 사용하여 제품을 최신 상태로 유지한다.

문제

컴퓨팅에서 "문제"라는 용어는 시스템 개선을 달성하기 위한 작업 단위를 의미한다.^[6] 문제는 버그, 요청된 기능, 작업, 누락된 문서화 등일 수 있다.

예를 들어, 오픈오피스는 이전에 버그질라의 수정된 버전을 IssueZilla라고 불렀다. 틀:2010년 9월 기준, 그들은 시스템을 Issue Tracker라고 부른다.^[7]

심각도 수준

문제는 종종 심각도 수준으로 분류된다. 회사마다 심각도에 대한 정의가 다르지만, 가장 일반적인 몇 가지는 다음과 같다.

높음

버그 또는 문제가 시스템의 중요한 부분에 영향을 미치며, 정상적인 작동을 재개하려면 수정되어야 한다.^[8]

중간

버그 또는 문제가 시스템의 사소한 부분에 영향을 미치지만, 작동에 약간의 영향을 미친다. 이 심각도 수준은 시스템의 비중심적 요구 사항이 영향을 받을 때 할당된다.^[9]

낮음 / 해결됨

버그 또는 문제가 시스템의 사소한 부분에 영향을 미치며, 작동에 거의 영향을 미치지 않는다. 이 심각도 수준은 시스템의 비중심적 요구 사항(및 중요도가 낮은)이 영향을 받을 때 할당된다.^[10]

사소함 (외관, 미학)

시스템은 올바르게 작동하지만, 외관이 예상과 일치하지 않는다. 예를 들어, 잘못된 색상, 내용물 사이의 너무 많거나 적은 간격, 잘못된 글꼴 크기, 오타 등이 있다. 이것은 가장 낮은 심각도 문제이다.^[11]

이슈 관리

소프트웨어 개발 프로세스의 일부 구현에서는 품질 보증 분석가가 시스템의 정확성을 검증하기 위해 이슈를 조사한 다음, 식별된 이슈를 해결하기 위해 개발 팀 구성원에게 다시 할당한다. 이슈는 사용자 인수 테스트(UAT) 단계에서 시스템 사용자에게서 식별될 수도 있다.

이슈는 이슈 또는 결함 추적 시스템을 사용하여 기록하고 전달할 수 있다. 공식적인 이슈 또는 결함 추적 시스템이 없는 경우, 발견된 이슈의 존재를 전달하기 위해 이메일이나 인스턴트 메시지와 같은 모든 형태의 서면 통신을 사용하는 것이 일반적이다.

철학

프로젝트 관리의 하위 분야로서, 일부는 소프트웨어 개발 관리를 프로그래밍 기술이 없는 관리 기술을 가진 사람이 수행할 수 있는 제조업 관리와 유사하게 본다. 존 C. 레이놀즈는 이 견해를 반박하며, 소프트웨어 개발은 전적으로 디자인 작업이며, 프로그래밍을 할 수 없는 관리자를 글을 쓸 수 없는 신문의 주필에 비유한다.^[12]