폭포 모델은 시스템 개발에 자주 사용되는 개발 방법입니다사소한 차이는 있지만 일반적인 흐름은 요구사항 정의 → 기본 설계 → 상세 설계 → 제조
폭포 모델에서 품질 측면에서 중요한 부분은 요구사항 정의와 기본 설계를 다루는 '젠 토토 프로세스'입니다"품질 향상"은 젠 토토 프로세스에서 이루어져야 한다고 합니다
젠 토토 프로세스가 왜 중요합니까?
상류 공정에서 제거할 수 없었던 잠재 결함이 중류 또는 하류 공정에서 발견되면 이를 처리하는 데 많은 노력이 필요하기 때문입니다
다음은 요구사항 정의에서 하나의 결함이 제거될 때 노력이 1로 설정되는 예입니다요구사항 정의 프로세스에서 동일한 결함을 제거할 수 없고 이후 프로세스에서 발견되는 경우 시스템 테스트 중에 비용이 수십 배 더 비싸고 릴리스 후에는 가능성이 100배 이상 더 높다고 합니다
왜 그렇게 시간이 많이 걸리나요?
요구사항 정의 프로세스에서는 요구사항 정의 문서 등 관련 문서를 수정하고 확인하기만 하면 됩니다
시스템 테스트 중에 결함이 발견되고 결함이 요구 사항과 관련된 경우 문서 수정과 같은 관련 작업은 요구 사항을 정의할 때보다 더 광범위해집니다
- 문서(요구사항 정의 문서, 기본 설계 문서, 상세 설계 문서, 각 테스트 사양) 수정
- 소스 코드 수정
- 각 문서 및 소스 코드 검토
- 단위 테스트, 통합 테스트 및 시스템 테스트 재실행
작업 후 시장에서 결함이 지적되면 더 많은 작업이 필요합니다
- 콜센터 카운터 운영
- 시스템 운영 직원이 첫 번째 응답을 받아 개발 직원과 연결합니다
- 문서(요구사항 정의 문서, 기본 설계 문서, 상세 설계 문서, 각 테스트 사양) 수정
- 소스 코드 수정
- 각 문서 및 소스코드 검토
- 단위 테스트, 통합 테스트, 시스템 테스트 재실행
- 수정 후 보고서 작성
- 출고 승인 회의 개최 중
또한 콘텐츠가 시장에 큰 영향을 미치고 시스템 장애로 이어질 수 있는 경우 관련 정부 기관에 신고가 필요할 수 있습니다
위 사항을 고려하면 프로세스가 늦어질수록 더 많은 시간과 노력이 소요됩니다응답에 필요한 노력이 증가하면 일정에 더 큰 영향을 미치며 사용 가능한 시간도 줄어듭니다
젠 토토 프로세스에서만 100% 품질을 보장할 수 있습니까?
이것은 아니오입니다실제 객체가 없는 요구사항 정의 과정과 기본 설계 과정에서 고려할 수 없는 측면도 있고, 외부 시스템에 연결해야만 볼 수 있는 문제점도 있습니다또한 중간 공정 이후에 혼입되는 문제가 있습니다
이러한 이유로 우리는 여러 테스트 프로세스를 통해 문제가 없음을 확인하기 위해 노력하고 있으며 품질을 더욱 보장하기 위해 제3자 관점의 테스트 팀도 포함시킵니다궁극적으로 우리는 젠 토토에서 다운스트림까지 품질을 보장하기 위해 노력할 것이지만, 그럼에도 불구하고 필수적인 전제는 ``젠 토토 프로세스에서 품질을 구축하는 것''입니다
