프로젝트 관리자는 프로젝트 관리의 4가지 주요 모델을 알아야 합니다
폭포식 모델
폭포식 개발 모델은 일회성 전달 프로세스입니다. 프로젝트 통과 '소프트웨어 기획 → 수요분석 → 소프트웨어 설계 → 프로그램 코딩 → 소프트웨어 테스팅 → 운영 및 유지보수'의 6가지 개발 단계를 거쳐야 전체 프로젝트가 완료된다.
적용 범위
▲고객의 요구 사항이 매우 명확하고 개발 프로세스 중에 변경 사항이 없거나 거의 없거나 이미 시장에 안정적인 개발 프로세스가 있으며 프로젝트 중에 변경 사항이 거의 없습니다.
▲고객은 실시간으로 보는 효과에 대해 요구 사항이 없습니다.
폭포수 모델 - 6개의 특정 단계
1) 소프트웨어 계획
시장 조사 및 수요자와의 커뮤니케이션을 통해 프로젝트 목표를 결정하고 타당성 조사를 수행하여 프로젝트가 실현 가능하고 이점이 무엇인지, 그리고 기업이 프로젝트를 수락하는지 여부를 결정합니다.
2) 수요 분석
수요측의 모든 요구를 심층적으로 파악하고 분석을 수행하여 수요측이 달성하고자 하는 최종 효과를 파악함으로써 고객이 원하는 제품을 보장합니다. 원하다. 일반적으로 이 단계는 고객과 반복적으로 확인해야 하며, 최종적으로 개발의 기반이 되는 요구사항 문서가 형성됩니다.
3) 소프트웨어 설계
요구사항을 이해한 후에는 시스템 아키텍처를 설계하는 등 요구사항을 체계화하고, 요구사항의 내용을 바탕으로 어떻게 제시할지 고민해야 한다. , 시스템 인터페이스 설계, 데이터베이스 설계, 인터페이스 설계 및 개발 등이 결국 아키텍처 설계 문서를 형성하게 됩니다.
4) 프로그램 코딩
시스템 프레임워크가 명확해졌습니다. 다음 단계는 프로그래머와 소통하고 설계 결과를 프로그램 코드를 통해 고객이 사용할 수 있는 운영 플랫폼으로 바꾸는 것입니다.
5) 소프트웨어 테스팅
코딩이 완료되고 해당 플랫폼에서 작동 가능한 후에 테스터는 고객의 관점에서 요구사항 질문에 따라 세부적인 테스트를 수행해야 합니다. 불합리하거나 비정상적으로 작동하는 부분에 대한 문제가 제기되면 프로그래머가 이를 수정하고 모든 문제를 해결한 후 최종적으로 테스트 보고서를 작성합니다.
6) 운영 및 유지 관리
소프트웨어는 개발 완료 후 사용할 수 있습니다. 그러나 고객이 사용하는 동안 문제가 발생할지 여부는 보장되지 않으므로 프로젝트 팀에서 지속적인 유지 관리, 오류 수정 및 기능 추가가 필요할 수 있습니다.
증분 모델
증분 모델은 "요구사항 분석 → 소프트웨어 설계 → 프로그램 코딩 → 소프트웨어 테스트"의 4단계를 추출하여 여러 번 실행한 모듈 전달 프로세스입니다. 그런 다음 전체 프로젝트를 완료했습니다.
자동차를 예로 들면, 타이어를 먼저 만들고, 핸들, 자동차 쉘 등을 만듭니다. 또한 타이어를 만들 때 '수요 분석 → 소프트웨어 설계 → 프로그램 코딩 → 소프트웨어 테스트'의 4단계도 거쳐야 하며, 모듈에 종속성이 없으면 병렬로 개발할 수도 있습니다.
반복 모델
시장의 급격한 변화로 인해 현재 많은 프로젝트 고객은 자신의 요구 사항이 무엇인지 알지 못합니다. 따라서 이러한 상황에 대처하기 위해 반복 개발이 필요합니다. 모델이 등장할 때마다 제품의 일부만 디자인하고 구현한 다음 점차적으로 더 많은 기능을 완성합니다.
각 설계 및 구현 단계를 반복이라고 합니다. 소프트웨어 계획, 요구 사항 분석, 설계, 구현, 테스트 및 승인 등을 포함하는 전체 프로세스는 In과 동일합니다. 작은 폭포형 반복의 경우 반복이 끝나면 실행 가능한 전달 버전이 완료되어야 합니다.
Rapid Prototyping Model
여러 가지 이유로 인해 요구사항 분석 단계에서는 완전히 일관되고 정확하며 합리적인 요구사항 설명을 얻는 것이 매우 어렵습니다. 따라서 이를 해결하려면 문제, 양측이 이해하도록 합의에 도달한 후 프로토타입 모델이라고도 불리는 신속한 프로토타이핑 모델 방법이 등장했습니다. 이는 요구 사항을 받은 후 작동하는 소프트웨어 프로토타입을 신속하게 구축하고 고객과 테스트하고 피드백 정보를 수집한 다음 개발된 소프트웨어가 실제로 고객의 요구 사항을 충족할 수 있을 때까지 반복적으로 수정하고 확인하는 것을 의미합니다.
그러나 프로토타입 개발 과정에서 엄격한 시스템 설계와 기획이 이뤄지지 않아 신뢰성과 성능을 보장하기 어려웠다.
따라서 실제 소프트웨어 프로젝트에서는 프로토타입 모델의 빠르고 품질이 낮은 특성에 대해 일반적으로 두 가지 처리 전략이 있습니다. 하나는 포기 전략이고 다른 하나는 추가 전략입니다.
포기 전략은 요구사항이 확정된 후 프로토타입을 폐기하고 실제 개발 과정에서 모든 기능을 재개발한다는 의미다. 추가적인 전략은 프로토타입을 개발 과정 전체에 적용하고, 고객의 모든 요구가 충족될 때까지 지속적으로 새로운 기능과 새로운 요구사항을 추가해 최종적으로 프로토타입을 소프트웨어로 만들어 고객에게 전달하는 것입니다. 이 전략은 반복 모델과 유사한 장점을 가지고 있습니다.