이 게시물에서는 장점과 단점, 각 모델을 사용하는시기와 함께 다양한 소프트웨어 개발 방법론을 살펴 봅니다.
반복적 라이프 사이클 모델은 전체 요구 사항 사양으로 시작하지 않습니다. 대신 개발은 소프트웨어의 일부만 지정하고 구현하는 것으로 시작되며 추가 요구 사항을 식별하기 위해 검토 할 수 있습니다. 그런 다음이 프로세스를 반복하여 모델의 각주기에 대해 새 버전의 소프트웨어를 생성합니다.
다음 네 단계를 순서대로 반복하는 반복적 인 라이프 사이클 모델을 고려하십시오.
요구 사항 단계, 소프트웨어에 대한 요구 사항이 수집되고 분석됩니다. 반복은 결국 요구 사항의 완전하고 최종 사양을 생성하는 요구 사항 단계로 이어져야합니다.
디자인 단계, 요구 사항을 충족하는 소프트웨어 솔루션이 설계되었습니다. 이것은 새로운 디자인이거나 이전 디자인의 확장 일 수 있습니다.
구현 및 테스트 단계, 소프트웨어가 코딩, 통합 및 테스트 될 때.
검토 단계, 소프트웨어 평가, 현재 요구 사항 검토, 제안 된 요구 사항 변경 및 추가.
모델의 각주기에 대해주기에 의해 생성 된 소프트웨어를 버릴지 아니면 다음주기의 시작점으로 유지할지 결정해야합니다 (증분 프로토 타이핑이라고도 함).
결국 요구 사항이 완료되고 소프트웨어를 제공 할 수있는 지점에 도달하거나 필요에 따라 소프트웨어를 향상시키는 것이 불가능 해져 새로운 시작을해야합니다.
반복적 인 라이프 사이클 모델은 연속적인 근사를 통해 소프트웨어를 생산하는 것과 비슷할 수 있습니다. 연속 근사를 사용하여 최종 솔루션에 도달하는 수학적 방법으로 유추하면 이러한 방법의 이점은 솔루션에 얼마나 빠르게 수렴하는지에 따라 달라집니다.
반복적 인 소프트웨어 개발 라이프 사이클을 성공적으로 사용하기위한 핵심은 요구 사항의 엄격한 유효성 검사와 모델의 각주기 내에서 해당 요구 사항에 대한 각 소프트웨어 버전의 검증 (테스트 포함)입니다.
증분 빌드 모델은 제품이 완성 될 때까지 모델을 점진적으로 설계, 구현 및 테스트하는 소프트웨어 개발 방법입니다 (매번 조금 더 추가됨). 개발과 유지 보수가 모두 포함됩니다. 제품은 모든 요구 사항을 충족 할 때 완제품으로 정의됩니다. 이 모델은 워터 폴 모델의 요소와 프로토 타이핑의 반복적 인 철학을 결합합니다.
제품은 여러 구성 요소로 분해되며, 각 구성 요소는 개별적으로 설계되고 구축됩니다 (빌드라고 함). 완료되면 각 구성 요소가 클라이언트에 전달됩니다. 이를 통해 제품을 부분적으로 활용할 수 있고 개발 시간이 길어지지 않습니다. 또한 이후의 긴 대기를 피하면서 초기 자본 지출이 크게 발생합니다. 이 개발 모델은 완전히 새로운 시스템을 한꺼번에 도입하는 데 따른 충격적인 영향을 완화하는데도 도움이됩니다.
이 모델에는 몇 가지 문제가 있습니다. 하나는 각각의 새로운 빌드가 이전 빌드 및 기존 시스템과 통합되어야한다는 것입니다. 제품을 분해하여 빌드하는 작업도 사소하지 않습니다. 빌드가 너무 적고 각 빌드가 퇴화되면 빌드 및 수정 모델로 바뀝니다. 그러나 빌드가 너무 많으면 각 빌드에서 추가 된 유틸리티가 거의 없습니다.
애자일 모델은 각주기 또는 반복에서 구성 요소의 작동 모델이 제공되는 구성 요소로 제품을 분할하여 반복 및 증분 모델의 조합입니다.
이 모델은 이전 릴리스 (반복)에 작은 변경 사항을 추가 할 때마다 지속적인 릴리스 (반복)를 생성합니다. 각 반복 중에 제품을 빌드 할 때 반복이 끝날 때 제품을 배송 할 수 있는지 확인하기 위해 테스트를 거칩니다.
애자일 모델은 고객, 개발자, 테스터가 프로젝트 전체에서 함께 작업하므로 공동 작업을 강조합니다.
Agile 모델의 장점은 작동하는 제품을 신속하게 제공하고 매우 현실적인 개발 접근 방식으로 간주된다는 것입니다.
이 모델의 한 가지 단점은 고객 상호 작용에 크게 의존하기 때문에 고객이 요구 사항이나 원하는 방향에 대해 명확하지 않으면 프로젝트가 잘못된 방향으로 향할 수 있다는 것입니다.
V 모델은 다음 레벨로 이동하기 전에 개발 라이프 사이클의 각 레벨을 확인하는 클래식 워터 폴 모델의 향상된 버전입니다. 이 모델을 사용하면 소프트웨어 테스트는 요구 사항이 작성되는 즉시 처음에 명시 적으로 시작됩니다.
여기서 테스트 란 검토 및 검사를 통한 검증, 즉 정적 테스트를 의미합니다. 이렇게하면 수명주기 초반에 오류를 식별하는 데 도움이되고 수명주기 후반에 코드에 나타나는 잠재적 인 향후 결함을 최소화 할 수 있습니다.
개발 수명주기의 각 수준에는 해당하는 테스트 계획이 있습니다. 즉, 각 단계가 진행됨에 따라 해당 단계의 제품 테스트를 준비하기위한 테스트 계획이 개발됩니다. 테스트 계획을 개발함으로써 해당 레벨의 제품 테스트에 대한 예상 결과를 정의하고 각 레벨의 진입 및 종료 기준을 정의 할 수도 있습니다.
폭포와 마찬가지로 각 단계는 이전 단계가 끝난 후에 만 시작됩니다. 이 모델은 여전히 돌아가서 변경하기가 어렵 기 때문에 알 수없는 요구 사항이 없을 때 유용합니다.
폭포수 모델은 구조화 된 SDLC 방법론 중 가장 오래되고 직관적입니다. 엄격한 단계가 있으며 다음 단계로 이동하기 전에 각 단계를 먼저 완료해야합니다. 돌아갈 수 없습니다.
각 단계는 이전 단계의 정보에 의존하며 자체 프로젝트 계획이 있습니다.
Waterfall은 이해하기 쉽고 관리하기 쉽습니다. 그러나 다음 단계가 시작되기 전에 각 단계를 검토하고 완전히 승인해야하므로 일반적으로 지연되는 경향이 있습니다.
또한 단계가 완료되면 수정할 여지가 거의 없기 때문에 유지 관리 단계에 도달 할 때까지 문제를 해결할 수 없습니다.
이 모델은 모든 요구 사항이 알려져 있고 유연성이 필요하지 않고 프로젝트에 고정 된 일정이있을 때 가장 잘 작동합니다.