연구 개발 모델에서 폭포 모델 및 반복 모델의 장점과 단점

폭포수형 모델은 소프트웨어 수명 주기의 활동을 폭포처럼 일정한 순서로 연결된 여러 세션으로 정의하여 결국 소프트웨어 제품을 얻는 것입니다.

폭포수 모델의 핵심 사상은 프로세스에 따라 문제를 단순화하고, 기능의 실현과 설계를 분리하고, 분업 협력을 용이하게 하며, 구조화된 분석과 설계 방법을 채택하는 것이다

논리적 구현을 물리적 구현과 분리합니다. 소프트웨어 수명 주기는 계획, 요구 사항 분석, 소프트웨어 설계, 프로그래밍, 소프트웨어 테스트 및 운영 차원의 6 가지 기본 활동으로 나뉩니다.

폭포처럼 한 걸음 한 걸음 한 걸음 한 걸음 한 걸음 떨어지는 고정 순서를 제공한다. (윌리엄 셰익스피어, 폭포, 폭포, 폭포, 폭포, 폭포, 폭포, 폭포, 폭포, 폭포, 폭포)

폭포 모델에는 다음과 같은 장점이 있습니다.

1) 은 프로젝트에 대한 단계별 검사점을 제공합니다.

2) 현재 단계가 완료되면 다음 단계에만 집중하면 됩니다.

3) 반복 모델에서 각 반복은 작은 폭포 모델과 매우 유사합니다.

폭포 모델은 증분 반복을 사용합니다. 각 반복은 실행 가능한 버전을 생성하고 함수를 더 추가합니다. 각 반복은 품질 및 통합 테스트를 수행해야 합니다.

4) 분석, 설계, 코딩 및 테스트에 동일한 지침을 제공할 수 있는 템플릿을 제공합니다.

폭포 모형에는 다음과 같은 단점이 있다.

1) 각 단계의 분할은 완전히 고정되어 있으며 단계 간에 대량의 문서가 생성되어 작업량이 크게 증가합니다.

2) 개발 모델이 선형이기 때문에 사용자는 전체 프로세스가 끝날 때까지 개발 결과를 볼 수 없으며 개발 위험을 증가시킵니다.

3) 너무 많은 필수 완료 날짜 및 이정표를 통해 각 프로젝트 단계를 추적합니다.

4) 폭포 모델의 두드러진 단점은 사용자 수요의 변화에 적응할 수 없다는 것이다.

반복에는 제품 출시 (안정적이고 사용 가능한 제품 버전) 를 생성하는 모든 개발 활동과 해당 릴리스를 사용하는 데 필요한 기타 모든 주변 요소가 포함됩니다.

어느 정도 한 번의 반복은 계획, 수요 분석, 설계, 코딩 및 테스트와 같은 모든 워크플로우를 거치는 완전한 프로세스입니다.

게시 프로세스. 본질적으로 작은 폭포 프로젝트와 비슷하다. 각 반복은 최종 제품의 하위 세트인 게시할 수 있는 제품을 생성합니다.

우세

기존 폭포 모델에 비해 반복 프로세스는 다음과 같은 장점이 있습니다.

1) 개발 위험을 점진적으로 줄입니다. 반복 후 소프트웨어가 고객의 요구 사항을 충족하지 못하면 개발이 저조한 반복 비용만 손실됩니다.

2) 제품이 정해진 진도에 따라 시장에 진입하지 못할 위험을 줄였다. 개발 초기에 위험을 식별하면 개발 후기에 성급하게 행동하는 대신 가능한 한 빨리 해결할 수 있습니다.

3) 전체 개발 작업의 진행을 가속화했다. 개발자가 문제의 요점을 알고 있기 때문에, 그들의 생산성은 더욱 높아질 것이다.

4) 사용자 요구 사항은 처음에 완전히 정의할 수 없기 때문에 일반적으로 다음 단계에서 세분화됩니다. 따라서 이러한 반복 프로세스의 모델은 수요 변화에 더 쉽게 적응할 수 있습니다.

열세

제품 인력의 리듬 제어 능력 (주간 목표 설정, 수요 우선 순위 분석, 임시 수요 처리) 에 대한 요구가 높습니다. 그렇지 않으면 주 발표일에 야근과 사망의 리듬에 빠지기 쉽습니다.

나는 몇몇 인터넷 창업 회사들과 접촉한 적이 있는데, 빠른 반복에 뚜렷한 오해가 있다는 것을 발견했다. 즉, 제품 기능 수준의 빠른 반복에만 집중하고 시스템 아키텍처 수준의 빠른 반복은 무시한다는 것이다.

그 결과 시스템 백엔드 아키텍처가 여전히 혼란스러울 때, 심지어 백엔드 아키텍처가 없을 때도 제품에 이미 많은 기능이 쌓여 있었다.

이것은 바닥에 경사진 기초를 쌓는 것과 같다. 더 많이 지어질수록 더 위험하다. 백엔드 시스템이 불치병에 걸려 개조가 필요하다는 것을 알게 되면, 그것은 이미 여러 가지 기능을 실행했으며 회복하기 어렵다는 것을 알게 된다. (존 F. 케네디, 건강명언)

백엔드 아키텍처의 반복에 신경 쓰지 않는 것은 일반적인 문제이며, 그 이유는 다음과 같습니다.

1) 초기 제품 사용자가 적고 성능이 주요 병목 현상이 아닙니다.

2) 팀에는 우수한 건축가가 없어 최적화가 부족하다.

3) 백엔드 아키텍처 최적화는 느린 작업이며, 제품 기능 수준의 반복만큼 빠르게 감지할 수 없으며, 기술 기반이 아닌 강력한 제품 구동을 위한 회사에도 충분하지 않습니다.

4) 백엔드 아키텍처 최적화는 정교한 작업이며 제품 기능만큼 뚜렷한 "출력" 을 갖고 있지 않습니다. 기술을 모르고, KPI 중심의 기업 문화를 이해하지 못하는 리더십에 대해 직원들이 백엔드를 최적화하려는 의지는 그리 강하지 않다.

5) 제품 제공 진도 압력이 비교적 커서 아키텍처 최적화를 고려할 시간이 없고, 기능 달성 방법에 집중할 수 있습니다.

다음 그림은 각 반복에 대한 제품 모양을 보여줍니다. 반복 횟수가 증가함에 따라 제품의 기능이 점점 더 풍부해지고 있다. 각 반복은 사용자 피드백을 기준으로 수요를 조정하기 때문에 최종 제품도 사용자 요구에 대한 책임을 져야 합니다.