소프트웨어 프로젝트 관리

이 문서에는 여러 가지 문제가 있습니다.개선을 돕거나 토크 페이지에서 이러한 문제에 대해 논의해 주십시오.(이러한 템플릿메시지를 삭제하는 방법과 타이밍에 대해 설명합니다) 이 글은 검증을 위해 추가 인용문이 필요합니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 : '소프트웨어 프로젝트 관리'– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2010년 8월) (이 템플릿 메시지 삭제 방법 및 삭제 시기 확인) 이 기사에는 편파적이거나 검증 불가능한 정보를 수반하는 애매한 표현이 포함되어 있다. 이러한 진술은 명확해지거나 삭제되어야 한다.(2018년 11월) 이 기사에는 독창적인 연구가 포함되어 있을 가능성이 있다. 클레임을 확인하고 인라인 인용을 추가하여 개선해 주십시오. 독창적인 연구로만 구성된 진술은 삭제되어야 한다.(2018년 11월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인) (이 템플릿메시지를 삭제하는 방법과 타이밍을 확인합니다)

IEEE 소프트웨어의 라이프 사이클
SQA – 소프트웨어 품질 보증 • IEEE 730 SCM – 소프트웨어 구성 관리 • IEEE 828 STD – 소프트웨어 테스트 매뉴얼 • IEEE 29119 SRS – 소프트웨어 요건 사양 • IEEE 29148 V&V – 소프트웨어 검증 및 검증 • IEEE 1012 SDD – 소프트웨어 설계 설명 • IEEE 1016 SPM – 소프트웨어 프로젝트 관리 • IEEE 16326 SUD – 소프트웨어 사용자 매뉴얼 • IEEE 24748 SRA – 소프트웨어 리뷰 및 감사 • IEEE 1028
v t

소프트웨어 프로젝트 관리는 소프트웨어 ^[1]프로젝트를 계획하고 주도하는 기술 및 과학입니다.소프트웨어 프로젝트를 계획, 구현, 감시 및 제어하는 프로젝트 관리의 하위 분야입니다.

역사

1970년대와 1980년대에, 컴퓨터 회사들은 하드웨어 생산과 회로에 비해 상대적으로 낮은 소프트웨어 생산 비용을 빠르게 인식하면서 소프트웨어 산업은 매우 빠르게 성장했습니다.새로운 개발 노력을 관리하기 위해 기업은 확립된 프로젝트 관리 방식을 적용하였으나, 테스트 실행 중에 프로젝트 일정이 미끄러졌으며, 특히 사용자 사양과 배포된 소프트웨어 사이에 회색 영역에 혼선이 발생하였습니다.이러한 문제를 피하기 위해 소프트웨어 프로젝트 관리 방법에서는 현재 워터폴 모델이라고 불리는 방법으로 납품된 제품에 사용자 요건을 일치시키는 데 초점을 맞췄습니다.

업계가 성숙함에 따라 소프트웨어 프로젝트 관리 실패에 대한 분석 결과 다음과 같은 원인이 ^[2][3][4]가장 일반적인 것으로 나타났습니다.

1. 최종 사용자의 관여가 불충분하다
2. 고객, 개발자, 사용자 및 프로젝트 매니저 간의 커뮤니케이션 부족
3. 비현실적이거나 구체화되지 않은 프로젝트 목표
4. 필요한 자원의 부정확한 견적
5. 잘못 정의되었거나 불완전한 시스템 요건 및 사양
6. 프로젝트 상태 보고가 불충분
7. 리스크 관리가 불충분하다
8. 미숙한 테크놀로지의 사용
9. 프로젝트의 복잡성을 처리할 수 없음
10. 허술한 개발 관행
11. 이해관계자 정치(이그제큐티브 서포트의 부재, 고객과 최종 사용자 간의 정치 등)
12. 상업상의 압력

위 목록의 첫 번째 5개 항목은 적절한 리소스가 적절한 프로젝트 목표를 달성할 수 있도록 고객의 요구를 명확하게 표현하는 데 어려움을 보여줍니다.특정 소프트웨어 프로젝트 관리 도구는 유용하고 많은 경우 필요하지만 소프트웨어 프로젝트 관리의 진정한 기술은 올바른 방법을 적용하고 그 방법을 지원하는 도구를 사용하는 것입니다.방법이 없으면 공구는 가치가 없다.1960년대 이후 소프트웨어 제조업체가 자체 사용을 위해 여러 가지 소프트웨어 프로젝트 관리 방법을 개발했으며, 컴퓨터 컨설팅 회사도 고객을 위해 유사한 방법을 개발했습니다.오늘날 소프트웨어 프로젝트 관리 방법은 여전히 발전하고 있지만, 현재의 추세는 폭포형 모델에서 소프트웨어 개발 프로세스를 모방한 보다 주기적인 프로젝트 제공 모델로 이어지고 있습니다.

소프트웨어 개발 프로세스

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

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

프로젝트 계획, 실행, 감시 및 제어

프로젝트 계획의 목적은 프로젝트의 범위를 특정하고 관련된 작업을 견적하며 프로젝트 일정을 작성하는 것입니다.프로젝트 계획은 개발할 소프트웨어를 정의하는 요건부터 시작합니다.그 후 프로젝트 계획은 완료로 이어지는 작업을 기술하기 위해 작성됩니다.프로젝트 실행은 프로젝트 계획에 정의된 작업을 완료하는 프로세스입니다.

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

쟁점.

이 섹션에는 독창적인 연구가 포함되어 있을 수 있습니다. 클레임을 확인하고 인라인 인용을 추가하여 개선해 주십시오. 독창적인 연구로만 구성된 진술은 삭제되어야 한다.(2018년 11월) (이 템플릿메시지 삭제 방법 및 삭제 시기 확인)

이 섹션은 어떠한 출처도 인용하지 않습니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 섹션의 개선에 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.(2020년 12월) (이 템플릿메시지 삭제 방법 및 삭제 타이밍에 대해 알아보기)

컴퓨팅에서 "문제"라는 용어는 시스템 ^{[citation needed]}개선을 달성하기 위한 작업 단위입니다.버그, 요청된 기능, 작업, 문서 누락 등이 문제일 수 있습니다.

예를 들어, OpenOffice.org에서는 Bugzilla IssueZilla의 수정된 버전을 호출했습니다.2010년 9월^[update] 현재, 동사는 시스템을 ^{[needs update]}이슈 트래커라고 부르고 있습니다.

중요도 수준

문제는 종종 심각도 수준에 따라 분류됩니다.기업마다 중대도에 대한 정의는 다르지만, 가장 일반적인 것은 다음과 같습니다.

높은

이 버그 또는 문제는 시스템의 중요한 부분에 영향을 미치므로 정상 동작을 재개하려면 수정해야 합니다.

중간의

이 버그 또는 문제는 시스템의 작은 부분에 영향을 미치지만 동작에는 어느 정도 영향을 미칩니다.이 중대도는 시스템의 중앙 이외의 요건이 영향을 받을 때 할당됩니다.

낮음/고정

이 오류 또는 문제는 시스템의 일부에 영향을 미치며 작동에는 거의 영향을 미치지 않습니다.이 중대도는 시스템의 중앙 이외의 요건(중요도가 낮은 것)이 영향을 받는 경우에 할당됩니다.

사소한(외관, 미관)

시스템은 정상적으로 동작하지만 외관이 예상과 다르다.예를 들어, 잘못된 색상, 내용 간 간격이 너무 많거나 너무 작음, 잘못된 글꼴 크기, 오타 등입니다.이것은 가장 중대도가 낮은 문제입니다.

이슈 관리

많은 소프트웨어 ^[which?]회사에서는 시스템의 정확성을 검증할 때 품질보증 분석가가 문제를 조사하여 문제를 해결할 책임이 있는 개발자에게 할당하는 경우가 많습니다.또한 사용자 수용 테스트(UAT) 단계에서 시스템 사용자에 의해 할당될 수도 있습니다.

문제 또는 결함 추적 시스템을 사용하여 문제를 전달합니다.어떤 ^{[example needed]}경우에는 이메일이나 인스턴트 메신저가 사용된다.

철학

프로젝트 관리의 하위 분야로서 소프트웨어 개발 관리를 제조 관리와 같이 취급하는 사람도 있습니다.관리 능력은 있지만 프로그래밍 능력은 없는 사람이 할 수 있습니다.존 C. 레이놀즈는 이 견해를 반박하고 소프트웨어 개발은 전적으로 디자인 작업이라고 주장하며, 프로그래밍을 할 수 없는 매니저를 ^[6]글을 쓸 수 없는 신문의 편집장과 비교합니다.

레퍼런스

일반

• 16326:2019(E) - ISO/IEC/IEEE International Standard - Systems and software engineering - Life cycle processes - Project management. 2019. doi:10.1109/IEEESTD.2019.8932690. ISBN 978-1-5044-6299-0.
• 1058-1998 - IEEE Standard for Software Project Management Plans. 1998. doi:10.1109/IEEESTD.1998.88822. ISBN 978-0-7381-1448-4.
• Jalote, Pankaj (2002). Software project management in practice. Addison-Wesley. ISBN 0-201-73721-3.
• Murali Chemuturi, Thomas M. Cagley Jr. & (2010). Software Project Management: Best Practices, Tools and Techniques. J.Ross Publishing. ISBN 978-1-60427-034-1.

외부 링크

• Dan Galorath의 소프트웨어 프로젝트 관리 리소스

프로젝트 실패

• Robert Frese (2003-12-16). "PROJECT SUCCESS AND FAILURE: WHAT IS SUCCESS, WHAT IS FAILURE, AND HOW CAN YOU IMPROVE YOUR ODDS FOR SUCCESS?". University of Missouri-St. Louis. Retrieved 2015-05-13.