case study how eliminate flaws waterfall
애자일 폭포 하이브리드 모델
C ++의 이중 연결 목록
Waterfall Model은 소프트웨어 개발을위한 이상적인 선택이었습니다. 이 모델에서 아이디어는 시작, 분석, 구현, 테스트 및 유지 관리 단계를 통해 연속적인 프로세스에서 사용 가능한 소프트웨어가됩니다.
그러나 Waterfall 모델에는 몇 가지 단점이 있습니다.
민첩한 소프트웨어 개발은 Waterfall 모델의 문제를 제거하기 위해 발전했습니다. 완전히 새로운 프레임 워크가 있습니다. Waterfall 모델에는 순차 설계가 있지만 Agile 모델은 점진적 접근 방식을 따랐습니다.
Waterfall 모델을 따르던 클라이언트가 Agile로 전환했을 때 전환으로 인해 많은 문제가 발생했습니다. 그 이유는 소프트웨어 개발에 대한 다른 접근 방식에 적응할 수 없기 때문입니다. 최종 제품은 재앙으로 판명되었습니다.
따라서 Agile 및 Waterfall 모델의 전문가를 선택하여 강력한 최종 제품을 보장하기 위해 '하이브리드'라고 할 수있는 새로운 방법론이 발전했습니다.
먼저 Waterfall 및 Agile 개발 모델에 대해 알아 본 다음 각각의 장단점이있는 'Agile Waterfall Hybrid 모델'로 이동하겠습니다.
학습 내용 :
- 폭포 모델
- 애자일 모델
- 협업 (하이브리드) 모델
- 민첩한 폭포 하이브리드 모델 – 사례 학습 – 사례 연구
- 하이브리드 모델을 사용하여 워터 폴 및 애자일 개발 프로세스의 결함을 제거하는 방법 :
- 결론:
- 추천 도서
폭포 모델
Waterfall 모델은 프로젝트를 유한 단계로 나누는 소프트웨어를 개발하기위한 접근 방식입니다. 이전 단계를 검토하고 확인한 경우에만 다음 단계로 이동해야합니다.
폭포수 모델에서는 단계가 겹치지 않습니다.
그림 1은 Waterfall 모델을 보여줍니다.
폭포 모델의 장점 :
- 간단하고 이해하기 쉽고 사용하기 쉽습니다.
- 엄격한 모델 – 각 단계에는 특정 결과물과 검토 프로세스가 있습니다.
- 문서와 인공물이 꼼꼼하게 유지됩니다.
- 요구 사항이 잘 이해되는 프로젝트에 적합합니다.
Waterfall 모델의 단점 :
- 요구 사항이 변경 될 위험이있는 프로젝트에는 적합하지 않습니다.
- 결함을 수정하는 비용은 나중 단계에서 발견 될 때 매우 높습니다.
- 복잡하고 긴 프로젝트에는 적합하지 않습니다.
- 수명주기 동안 늦게까지 작동하는 소프트웨어가 생성되지 않습니다.
애자일 모델
Wikipedia는 애자일 모델을 '반복적이고 점진적인 개발을 기반으로하는 소프트웨어 개발 방법 그룹'으로 정의합니다. 여기서 요구 사항과 솔루션은자가 구성, 교차 기능 팀 간의 협업을 통해 발전합니다.
이 모델에는 프로세스를 뒷좌석으로 가져 오는 경향이있는 자체 원칙이 있습니다.
=> 여기에서 애자일 방법론에 대한 더 많은 기사를 읽어보십시오.
(확대하려면 이미지를 클릭하십시오)
Agile 모델의 장점 :
- 프로세스에 대한 고객 참여.
- 작업 소프트웨어가 자주 제공되므로 높은 ROI.
- 요구 사항의 늦은 변경도 쉽게 수용 할 수 있습니다.
- 제품과 프로세스 모두에 대한 지속적인 개선.
애자일 모델의 단점 :
- 설계 및 문서화에 대한 강조 부족.
- 팀은 안정적이고 숙련되어야합니다.
협업 (하이브리드) 모델
Collaborative Model은 Waterfall과 Agile의 두 모델을 결합하는 것을 목표로합니다. Waterfall 및 Agile 접근 방식을 모두 활용하면 프로젝트의 성공을 보장합니다. 두 모델의 단점을 제거합니다. 두 가지의 장점을 함께 모으고 있습니다.
협업 모델은 다음을 실행하여 프로젝트에서 구현할 수 있습니다.
따라서 협업 모델은 다음과 같이 다이어그램으로 표현할 수 있습니다.
하이브리드 모델의 장점
- Agile 및 Waterfall 프로세스의 이점을 결합합니다.
- 폭포수 원칙을 적용하기 위해 고급 디자인이 준비되어 있습니다.
- 코딩 및 테스트는 애자일 방법론을 사용하여 수행됩니다.
민첩한 폭포 하이브리드 모델 – 사례로 배우기 –사례 연구
소프트웨어 회사 인‘ABC Software Service’는 클라이언트 인‘XYZ University’라는 대학에 소프트웨어를 개발, 테스트 및 유지 관리하는 서비스를 제공합니다 (실시간 프로덕션 지원).
계정의 주요 기능은 다음과 같습니다.
xml 파일을 여는 가장 좋은 방법
- ABC Software Services는 XYZ University의 응용 프로그램을 업그레이드해야합니다. 데이터베이스를 업그레이드하고 모든 애플리케이션을 시장에서 사용할 수있는 최신 기술로 재개발해야합니다.
- 지금까지 ABC Software가 처리하는 모든 프로젝트는 Waterfall 모델로 실행되었습니다.
- 트래픽이 많고 우선 순위가 높은 애플리케이션 중 두 개가 이제 재개발 될 예정입니다. 첫 번째는 '온라인 등록'이고 두 번째는 '온라인 시험'입니다.
- Client XYZ University는 이제 이러한 애플리케이션이 소프트웨어 개발의 Agile 모델을 사용하여 작업되기를 원했습니다.
ABC 소프트웨어 용 애자일 모델의 첫 번째 프로젝트는 온라인 등록이었습니다. 이 프로젝트를 실행 한 후 일련의 회고를 통해 후속 프로세스에 많은 결함이 있음을 알았습니다.
이러한 결함은 두 번째 프로젝트 인 '온라인 시험'을 실행하는 동안 해결되어 하이브리드 모델에서 실행되었습니다.
하이브리드 모델을 사용하여 워터 폴 및 애자일 개발 프로세스의 결함을 제거하는 방법 :
이에 대해 하나씩 자세히 논의하겠습니다.
#1. 문서 없음 :
애자일 선언문의 애자일 원칙 중 하나는 다음과 같습니다. 애자일은 '포괄적 인 문서를 통해 작동하는 소프트웨어'에 더 많은 가치를 부여합니다. 애자일 방법론은 문서화가 '간신히 충분'해야한다고 믿으며 작동하는 소프트웨어를 출시하는 데 더 중점을 둡니다. 문서화에 많은 노력을 기울이지 않지만 라이브 프로젝트에서 발견 된 결함에 대해 작업하는 전담 지원 팀이있는 XYZ University와 같은 계정의 경우 이러한 습관을 장기적으로 분석하면 장애가 될 수 있습니다.
수년에 걸쳐 프로젝트가 Waterfall 모델에서 실행되었을 때 지원 팀이 그에 따라 이해하고 작업 할 수 있도록 문서가 유지 관리되고 업데이트되었습니다. 솔루션 설계, 기술 설계, 연습 문서 등이 준비된 문서 중 일부였습니다. 프로젝트가 종료 된 후 지원 팀으로 전환되었습니다.
그러나 '온라인 등록'프로젝트의 경우 그러한 문서가 준비되지 않았으며 비용이 많이 듭니다. 프로젝트가 시작되었을 때 최종 사용자가 많은 티켓을 제기했으며 지원 팀은 작업 방법에 대한 단서가 없었습니다. 팀은 참조 할 문서가 없었습니다.
이것은 중요한 교훈이었으며 다음 프로젝트를 위해 '온라인 시험'문서가 작성되고 효과적으로 전환되었습니다.
=> 문서가 중요한 이유는 여기에서 자세히 읽어보십시오.
#두. UAT / End-to-end 테스트 없음 :
소프트웨어 개발의 애자일 모드에서 테스터는 테스트 할 빌드를 점진적으로 가져옵니다. 이러한 빌드는 최종 빌드가 완전히 빌드 될 때까지 계속 통합됩니다. 테스터는 각 스프린트에서 다루는 요구 사항을 테스트하고 계속 합산되는 빌드의 회귀 테스트를 계속 수행합니다.
그러나 모든 스프린트가 완료되고 최종 빌드가 준비되고 모두 통합 된 후에 테스터는 전체 시스템을 테스트하고 엔드 투 엔드 테스트를 수행해야합니다. 이것은 완전히 새로운 환경에서 수행되어야합니다.
다음과 같은 이점이 있습니다.
- 전체 시스템이 새 환경에 배포되고 테스터가 전체 흐름을 테스트합니다.
- 궁극적으로 빌드가 라이브 환경에서 전체적으로 배포되어야하기 때문에 자신감이 생깁니다.
온라인 등록 프로젝트가 테스트되었을 때 테스트 환경에서 수행되었습니다. 시스템 테스트와 모든 결함을 다시 테스트 한 후 승인을 위해 선언되었습니다. 이상적으로는 시스템 테스트의 다른주기를 위해 다른 환경으로 승격되지 않았습니다. (이상적으로, UAT는 시스템 테스트 후 발생합니다. , 그러나이 경우 UAT 팀 구성원이 첫 번째 테스트주기에 참여 했으므로 두 번째주기가 예약되지 않았습니다.)
온라인 시험 프로젝트가 시작되었을 때 SIT (시스템 통합 테스트)가 완료되고 코드가 두 번째 테스트주기가 완료된 UAT 환경으로 승격되었습니다. 결과 : 우선 순위가 높은 모든 결함이 포착되고 해결되었습니다. 라이브 출시 전에 빌드가 안정적이었습니다.
#삼. 스크럼 마스터 없음 :
그만큼 스크럼 마스터 팀이 스크럼의 가치와 관행에 따라 생활하도록 할 책임이 있습니다. 스크럼 마스터는 팀이 가능한 최선의 작업을 수행하도록 도와줌으로써 팀의 코치로 간주됩니다. 스크럼 마스터는 또한 프로세스 소유자 팀을 위해서.
온라인 등록 팀은 스크럼 마스터없이 구성되었습니다. 전담 스크럼 마스터를 갖는 것의 중요성은 중요하지 않았습니다. 그 결과 많은 문제가 제 시간에 해결되지 않았고 프로젝트를 완료하는 데 걸리는 시간이 기한을 넘었습니다.
그러나 전담 스크럼 마스터가 온라인 시험 프로젝트에 참여했습니다. 프로젝트 문제와 과제는 스크럼 마스터가 처리했습니다. 프로젝트 / 스프린트 보고서가 준비되었고 팀은 진행 상황을 볼 수있었습니다.
또한 적절한 스프린트 계획 회의와 스프린트 회고 회의가 각 스프린트에 대해 개최되어 팀의 성과를 향상 시켰습니다. 팀은 작업에만 집중하고 해당 스프린트에 할당 된 작업을 완료했습니다. 모든 추가 하우스 키핑은 스크럼 마스터가 처리했습니다.
# 4. 프로젝트 문서를 제품 백 로그로 변환 :
폭포수 모델로 준비된 초기 프로젝트 문서는 비즈니스 요구 사항 사양 (BRS), 고급 디자인, 기능 디자인 등입니다. 이러한 문서는 코딩, 테스트 및 구현 단계를 실행하기 위해 제품 백 로그로 변환되어야합니다. 애자일 모드에서. 이것은 매우 중요한 단계입니다.
제품 백로 그는 애자일 프로젝트의 시작점입니다. 제품 백로 그는 제품에 대해 유지되는 우선 순위가 지정된 요구 사항 목록입니다. 기능, 버그 수정, 비 기능적 요구 사항 등으로 구성되어 있습니다. 고객 피드백, 변화하는 요구 사항 등에 따라 점점 더 커지는 문서입니다.
모든 프로젝트의 첫 번째 아티팩트이기 때문에 요구 사항을 나열하고 우선 순위를 지정하는 것이 가장 중요합니다. 폭포수 프로젝트 문서를 제품 백 로그로 변환하는 것은 그 자체로 큰 작업이며 고객 / 이해 관계자와 함께 전체 팀에 대한 브레인 스토밍이 필요합니다.
모든 요구 사항이 나열되고 고객이 동의하면 다음 작업은 스프린트에서이를 선택하기 위해 우선 순위를 지정하는 것입니다.
# 5. 추적 성 매트릭스 :
일반적으로 폭포 모델에서 유지되는 또 다른 중요한 아티팩트는 추적 성 매트릭스입니다. 따라서 누락 된 요구 사항이 없는지 확인하기 위해; 추적 성 매트릭스도 설계 및 유지되어야합니다. . 일반적으로 애자일에서는 그러한 매트릭스가 설계되지 않습니다.
이것은 모든 프로젝트에서 모범 사례입니다. 추적 성 매트릭스는 제품 백 로그와 병행하여 준비해야합니다. 그리고 사용자 승인 테스트 / 엔드 투 엔드 테스트 중에 실행 된 테스트 케이스와 비교하여 확인해야합니다 (이 단계는 다음 부분에서 설명합니다). 요구 사항이 누락 된 경우에도 애자일이 추가적인 유연성과 적응성을 제공하므로 개발 후반 단계에서도 쉽게 통합 할 수 있습니다.
온라인 등록 프로젝트가 실행 된 후 최종 사용자 (등록하려는 학생)가 애플리케이션에 액세스했습니다. 그들은 응용 프로그램에서 많은 문제에 직면했습니다. 이로 인해 프로덕션 지원 팀에 많은 티켓이 제기되었습니다. 제기 된 티켓은 사고, 문제 또는 변경으로 분류 될 수 있습니다. 응용 프로그램이 안정 될 것으로 예상하면서 많은 문제가 해결되었습니다. 그러나 그 후에도 12 개 이상의 변경 요청 / 개선이 후속 릴리스에서 계획되었습니다. 이러한 향상된 기능은 응용 프로그램을 안정화하고 최종 사용자 환경을 개선하기위한 것입니다.
테스트 케이스와 테스트 시나리오의 차이
따라서 궁극적으로 프로젝트 비용은 크게 증가했습니다. 따라서 프로젝트가 애자일로 제대로 전환되지 않으면 예산이 초과 될 수 있습니다. 이는 프로젝트를 Agile로 완전히 전환하는 데 매우 필요합니다. 또한 프로젝트를 애자일 모드에서 실행하기 위해 필요한만큼 계획을 수행해야합니다. 특정 프로젝트에 적합한 하이브리드 모델을 설계해야합니다.
시험 응시 프로젝트가 시작되기 전에이 측면은 잘 관리되었습니다. 하이브리드 모델을 생각하고 요구 사항 분석 단계와 고급 설계 단계를 폭포 모델과 애자일 모델의 나머지 단계에서 실행하기로 결정했습니다.
채택 된 하이브리드 모델은 아래와 같이 그림으로 표현할 수 있습니다.
결론:
Waterfall 모델과 Agile 모델 모두 고유 한 단점이 있음이 분명합니다. 따라서 하이브리드 모델을 선택하는 것은 매우 현실적입니다. 두 세계의 장점을 활용합니다.
프로젝트 시작의 가장 중요한 측면은 팀이 채택 할 모델을 결정하는 것입니다. 이를 위해서는 광범위한 계획이 필요합니다. 소프트웨어 모델을 채택 할 때 예산, 시간, 자원 활용, 요구 사항의 복잡성 등과 같은 요소를 고려해야합니다.
하이브리드 모델은 아직 초기 단계에 있습니다. 점점 더 많은 회사가이를 채택할수록이 개념에 대해 더 많이 배울 것입니다.
애자일 선언문은 다음과 같은 가치를 요구합니다.
- 개인과 상호 작용 프로세스 및 도구
- 작업 소프트웨어 포괄적 인 문서
- 고객 협력 계약 협상에
- 변화에 대응 계획을 따르는 것보다
반면 하이브리드 모델은이 100 %를 고수하지 않습니다. 그것은 모든 측면이 동등하게 중요하다는 것을 암시합니다. 어떤 측면을 더 중요하게 생각하고 어떤 측면을 무가치하게 할 것인지 결정하는 것은 클라이언트 / 프로젝트 관리자에게 달려 있습니다.
저자 정보 : 이것은 Harshpal Singh의 게스트 기사입니다. 그는 7 년 이상의 수동, 데이터베이스, 자동화 및 성능 테스트 경험을 보유하고 있으며 현재 선도적 인 MNC에서 팀 리더로 일하고 있습니다. 그는 Waterfall, Agile 및 하이브리드 개발 모델을 따르는 많은 QA 프로젝트에서 작업했습니다.
이 하이브리드 개발 및 테스트 모델에서 작업 한 경험이 있습니까? 댓글로 토론합시다.
추천 도서
- Agile Vs Waterfall : 프로젝트에 가장 적합한 방법은 무엇입니까?
- SDLC 폭포 모델이란 무엇입니까?
- Zephyr 엔터프라이즈 테스트 관리 도구 검토-Agile 도구에서 폭포 모델 자산을 사용하는 방법
- 나선형 모델-SDLC 나선형 모델이란?
- 애자일 프로세스로의 성공적인 전환을위한 애자일 테스트 마인드를 개발하기위한 4 단계
- JIRA Agile Tutorial : Agile 프로젝트 관리를 위해 JIRA를 효과적으로 사용하는 방법
- SDLC (소프트웨어 개발 수명주기) 단계, 방법론, 프로세스 및 모델
- 애자일 선언 : 애자일 가치 및 원칙 이해