프로젝트 변경 비용에 대해 알아봅시다.
프로젝트 변경 비용 이해
프로젝트 변경 비용은 시스템 결함이 발견되었을 때 이를 해결하는 데 드는 비용을 의미합니다. 프로젝트 진행 중 또는 개시 이후 결함이 발견되어 조치가 필요한 상황이 발생한 경우, 조치를 취하는 과정에서 비용이 발생하게 됩니다. 프로젝트 변경 비용(Cost of Changes)은 시스템 결함이 늦게 발견될수록 이를 해결하는 데 더 많은 비용이 든다는 것입니다. 점점 커지는 구조를 가지고 있습니다. 원칙적으로는 시스템의 결함이 나중에 발견될수록 이를 해결하는 데 드는 비용이 더 커진다는 것입니다. 프로젝트 변경 비용과 관련하여 주장한 학자들 중 대표적인 것이 Barry Boehm의 이론이다. Boehm의 변경 비용 곡선을 통해 프로젝트 변경 비용은 요구사항 분석 단계, 설계 단계, 개발 단계, 테스트 단계, 운영 단계에서 결정됩니다. 발견 시점에 따라 비용이 어떻게 달라지는지 그래프로 보여줍니다. 그래프는 나중에 발견될수록 비용이 최대 150배까지 증가한다는 것을 보여줍니다. 이는 가능한 한 빨리 결함을 찾아 해결해야 함을 의미합니다. 운영 수준에서 시스템 결함을 찾으려는 시도는 절대 수행되어서는 안 됩니다. 프로젝트 수명주기가 진행됨에 따라 수정 비용은 더욱 증가합니다. 프로젝트 수정 비용이 발생하는 이유는 결함이 있는 부품을 기반으로 이미 설계 및 개발 작업이 완료되었기 때문입니다. 왜냐하면. 그리고 이를 수정하면 더 많은 프로젝트 이해관계자가 변경의 영향을 받게 됩니다. QA(Quality Assurance)의 역할과 활동은 프로젝트 품질에 매우 중요합니다. QA(품질 보증)는 프로젝트 수명 주기의 각 단계에서 품질을 모니터링합니다. 검증이 수행되어야 합니다. QA에서는 프로젝트의 분석, 설계, 개발, 테스트 단계 전반에 걸쳐 각 단계에 맞는 품질 검증 활동을 수행하는 것이 중요합니다. 프로젝트에서 시스템을 오픈한 후 고객에게 영향을 미치는 문제를 해결하는 것보다, 프로젝트에서 시스템을 오픈하기 전에 프로젝트 과정에서 설계 문제를 해결하는 것이 더 좋습니다. 결함을 해결하기 위한 노력은 프런트엔드에서 훨씬 빠르고 비용 효율적인 활동입니다. 프로젝트 변경 비용과 관련된 기술 부채라는 개념이 있습니다. 기술부채란 제대로 개발되지 않을 경우 손실되는 금액을 말합니다. 빚이 되어 나중에 이자가 생기고, 빚을 갚을 때가 되면 더 많은 재작업과 노력이 필요하다는 뜻을 비유적으로 표현한 것입니다. 기술 부채는 잘못된 설계 작업, 각 단계의 결과물 누락, 충분하지 않은 부적절한 테스트를 의미합니다. 리팩토링미루면 이런 일이 발생합니다.
프로젝트 변경 비용에 대한 설명
프로젝트 작업을 진행하는 동안 프로젝트 프로세스 중 언제든지 변경 사항이 발생할 수 있습니다. 프로젝트 변경에는 두 가지 유형이 있습니다. 첫째, 가장 일반적인 변화 유형인 시스템 결함의 발견이다. 둘째, 요구사항 변경이 있습니다. 프로젝트 변경에는 결함을 수정하기 위한 변경과 결함이 아닌 비즈니스 요구 사항에 대한 변경이라는 두 가지 유형이 있습니다.[프로젝트 변경의 종류]
프로젝트 변경의 경우 두 가지 유형의 변경 사항을 모두 빨리 발견하고 조치를 취할수록 변경 비용이 저렴해집니다. 프로젝트 변경 비용은 조기에 발견하고 조기에 조치를 취하는 경우 가장 낮습니다. 프로젝트 변경 비용을 나타내는 가장 대표적인 그래프는 Boehm의 변경 비용입니다. Boehm의 변경 비용 곡선은 Barry Boehm이 제안한 이론으로, 요구사항 분석 단계에서 변경 비용이 1이면 설계 단계에서는 5배, 개발 단계에서는 20배, 테스트에서는 50배 증가한다는 것입니다. 단계에서는 최대 150회까지 가능합니다. 을 나타내는 그래프입니다. 프로젝트 후반부에 비용이 크게 증가하는 이유는 이미 잘못된 오류나 잘못된 요구 사항을 바탕으로 많은 작업을 진행했기 때문에 다시 변경하면 수정 범위가 넓어지고 수정이 더 어려워지기 때문입니다. 실제로 고쳐보세요. 왜냐하면.[보엠의 프로젝트 단계별 비용 증가율]
Boehm의 변화 비용 곡선은 가능한 한 빨리 결함을 찾는 것의 중요성을 강조합니다. 보헴의 변화비용곡선에 대응하기 위해서는 궁극적으로 품질향상을 위한 프로세스 설계가 정말 중요합니다. 프로젝트 수명주기 전반에 걸쳐 각 단계에서 품질을 달성하기 위한 방법을 결정하고 적용해야 합니다. 즉, 나중에 테스트 단계에서 단순히 검증하는 것만으로는 충분하지 않습니다. 분석, 설계, 구현, 테스트 등 프로젝트의 모든 단계에서 품질을 검증하기 위한 활동을 수행해야 합니다. 이는 프로젝트에서 QA(품질 보증) 활동의 중요성을 강조합니다. QA(Quality Assurance)는 프로젝트에서 역할을 담당하며 프로젝트 품질을 보장하기 위한 다양한 활동을 수행합니다.[QA의 단계별 활동들]
QA(Quality Assurance)는 요구사항 분석 단계에서 요구사항이 상세하게 작성되었는지 확인하고, 설계 단계에서는 설계 문서가 표준에 부합하는지, 설계 문서 간의 일관성이 유지되는지 확인하고, 개발 단계에서는 코드를 리팩터링하는 작업입니다. 깨끗한 코드를 작성하고, 최종 테스트 단계에서는 QC(Quality Control) 활동이 완료되었는지 확인하는 활동을 진행합니다. QA(Quality Assurance)는 전체 프로젝트 프로세스의 각 단계에서 수행됩니다. 매번 검증을 수행해야 합니다. 프로젝트 품질 측면에서 프로젝트 수명주기 동안 사전 조치를 취하면 수명주기 후반에 발견된 품질 문제를 해결하는 데 발생하는 비용을 절약하고 예방할 수 있습니다. . 그리고 다수의 고객에게 영향을 미치는 문제를 해결하는 것보다 설계 문제를 해결하는 것이 더 빠르고 비용 효율적입니다. 프로젝트에 대한 개발 변경 비용을 줄이는 방법도 고민할 필요가 있다. 프로젝트 개발 변경 비용을 줄이는 방법에는 세 가지가 있습니다. 첫째, 개발과 테스트 사이의 간격을 짧게 유지하는 것이 가장 좋습니다. 소스 코드의 결함을 빨리 발견하고 조치를 취할수록 결함이 다른 코드 영역으로 더 빨리 확산되지 않습니다. 테스트되지 않은 코드를 통합하고 테스트하면 오류를 찾고 결함을 수정하는 데 더 많은 비용과 노력이 필요합니다. 따라서 코드 검토와 테스트 주도 개발(TDD)이 대안이 될 수 있습니다. 둘째, 먼저 핵심기능에 중점을 두고 개발하세요. 프로젝트의 개발 규모가 커질수록 변경 비용도 증가합니다. 개발 규모가 커질수록 시스템의 구조와 아키텍처가 복잡해지고, 개발에 참여하는 개발팀원의 수가 늘어나 의사소통의 어려움이 발생할 수 있습니다. 기능 수가 적을수록 변경 가능성이 낮아집니다. 셋째, 작은 조각으로 나누어 빠르게 발전시키는 것도 하나의 방법이다. 핵심 기능 개발에도 기민한 반복적인 사이클 개발을 적용함으로써 결함을 신속하게 발견하고 조기에 조치를 취할 수 있습니다. 애자일 프로젝트반복 주기의 검토 단계를 거치면 프로젝트 이해관계자가 서로의 요구 사항을 초기에 명확히 하고 이해하는 데 도움이 됩니다. 애자일 프로젝트에는 기술 부채(Technical Debt)라는 개념이 있습니다. 기술 부채는 제대로 개발하지 않으면 그 부분이 부채가 되고, 그 부채는 나중에 이자가 발생하고, 이를 위해서는 엄청난 노력이 필요하다는 것을 비유한 것입니다. 나중에 해결하세요. 기술 부채란 개발 프로젝트의 결함을 제대로 해결하지 못한 것을 의미하는 용어입니다. 그렇지 않으면 작동 중에 처리하기가 어렵습니다. 기술부채를 발생시키는 요인으로는 첫째, 설계작업이 제대로 이루어지지 않은 경우, 둘째, 필수적인 핵심 결과물이 누락되어 검증이 불가능한 경우; 셋째, 일정에 쫓겨 테스트를 건너뛰는 경우 테스트 부족 현상이 발생한다. 진행하다 보면 4차 코드 리팩토링 등의 활동이 제대로 이루어지지 않는 경우가 있습니다. 기술 부채는 금융 부채와 유사하며, 미래에 갚을 목적으로 돈을 빌리는 것을 말합니다. 그것은 말한다. 당장 결함이 발생하지는 않더라도 소스 코드가 복잡하고, 로직이 복잡하거나, 표준에 맞지 않는 코드를 작성하여 향후 유지 관리가 어려운 경우가 발생할 수 있습니다. 기술 부채는 나중에 관리자가 부담하게 되는 부채이자 이자입니다.