프로젝트 품질관리에 대해 알아봅시다.
프로젝트 품질 관리 이해
프로젝트에 있어서 프로젝트 품질관리는 프로젝트를 통해 구현된 시스템 성과를 전달하기 위해 필요한 중요한 기준이다. 프로젝트를 통해 구현된 시스템을 제공할 때 범위와 요구 사항이 충족되어야 하지만 품질에도 초점을 맞춰야 합니다. 사업 발주사(수행사)는 해당 사업을 통해 구현된 시스템의 결과를 사업 발주사(발주자)에게 전달한다. 시스템 결과를 제공할 수 있으려면 약속된 모든 프로젝트 범위와 요구 사항이 제공되어야 하며 동시에 성능 수준에 중점을 두어 품질을 충족해야 합니다. 프로젝트 품질에 대한 요구사항을 설명할 수 있습니다. 여러 가지 출력이 있습니다. 프로젝트 품질에 대한 요구사항은 요구사항 문서, 작업 명세서(SOW), 승인 기준 및 완료 정의(DoD)에 반영될 수 있습니다. 프로젝트 품질은 단위로 측정됩니다. 단위 테스트, 통합 테스트, UAT(사용자 승인 테스트) 등 테스트 및 품질 보증(QA) 활동을 통해 이를 높일 수 있습니다. 프로젝트 품질과 관련된 대부분의 비용은 후원 조직에서 발생합니다. 이는 정책, 절차 및 프로세스에 의해 부담되고 반영됩니다.
프로젝트 품질 관리 설명
프로젝트 품질은 프로젝트를 통해 구현된 시스템 결과의 기본 특성이 요구 사항을 충족하는 정도입니다. 프로젝트 품질은 프로젝트 이해관계자가 프로젝트를 통해 구현된 시스템 결과물을 수락하는 데 필요한 기능적 요구 사항과 함께 충족되어야 하는 것입니다. 프로젝트에서 높은 수준의 품질에 대한 요구 사항은 요구 사항입니다. 개별 결과물에 대한 품질 요구 사항은 문서에 정의 및 설명되어 있으며, 개별 결과물에 대한 품질 요구 사항은 각 결과물에 대한 승인 기준 또는 완료 정의(DoD)에 정의 및 설명되어 있습니다. UserStory에 승인 기준이나 완료 정의를 포함할 수도 있습니다. 프로젝트 품질에 대한 요구사항은 프로젝트 인도물에 정의되고 설명되어야 합니다. 프로젝트 품질에 대한 요구 사항은 사용자 스토리나 화면 디자인과 같은 요구 사항 문서와 제품의 사용 및 품질에 대해 설명하는 작업 명세서(SOW)에서 정의하고 설명할 수 있습니다. 이는 수행될 수 있으며 승인 기준에 지정될 수 있습니다. 만약에 애자일 프로젝트그렇다면 DoD(Definition of Done)에 반영할 수 있습니다.[프로젝트 품질 요구사항이 포함되는 문서]
품질과 관련된 대부분의 비용은 후원기관이 부담합니다. 그리고 품질과 관련된 사항은 회사의 정책, 절차, 프로세스에 반영됩니다. 품질과 관련된 모든 정책은 회사 및 조직의 정책에 따라 결정됩니다. 대부분의 기업이나 조직에서 프로젝트를 수행할 때 프로젝트 품질을 높이기 위해서는 개발 후 테스트 단계가 매우 중요합니다. 테스트를 통해 프로젝트에서 구현하려는 시스템 결과의 품질을 직접적으로 높일 수 있기 때문입니다. 테스트에는 단위 테스트, 통합 테스트 및 사용자 승인 테스트가 포함됩니다.[프로젝트 테스트의 유형]
유닛 테스트(Unit Test)는 각 기능의 개발이 진행됨에 따라 각 유닛별로 테스트하여 기능이 제대로 작동하는지 확인하는 것을 말합니다. 통합 테스트란 각 유닛을 테스트하여 기능이 제대로 작동하는지 확인하는 것을 말합니다. 단위 테스트 후, 모든 기능이 통합되었을 때 통합적 관점에서 각 기능이 잘 연결되어 있고 잘 작동하는지 확인하는 종합적인 테스트를 말합니다. 단위 테스트 및 통합 테스트(통합 테스트)는 IT 측면에서 수행되는 가장 대표적인 정식 테스트 단계입니다. 사용자 승인 테스트 단계를 진행하려면 먼저 단위 테스트 및 통합 테스트를 완료하고 통과하고 통과 승인을 받아야 합니다. UAT(사용자 승인 테스트)는 비즈니스 및 현장 측면에서 수행되는 대표적인 공식 테스트 단계입니다. 사용자 수용 테스트는 비즈니스 및 사용자 관점에서 개발된 시스템을 오픈하더라도 비즈니스 관점에서 문제가 있는지 확인하는 단계이다. 금융 분야에서 사용되는 복잡한 수학적 계산 등 비즈니스 영역에서만 할 수 있는 테스트도 일반적으로 사용자 수용 테스트입니다. 단계별로 진행하세요. 프로젝트에서 프로젝트의 품질은 사용자 수용 테스트가 얼마나 체계적이고 효율적이며 효과적으로 수행되는지에 따라 달라집니다. 기업이나 조직에 따라서는 통합 테스트 단계에 더 중점을 두고 간단한 사용자 수용성 테스트를 진행하는 경우도 있습니다. 개발된 시스템을 테스트 단계에서 대략적으로 테스트하고 시스템을 오픈하면 시스템에 내재된 오류가 그대로 남아있습니다. 사용자에게 노출되어 사용자에게 오류가 발생합니다. 이는 시스템에 대한 신뢰를 감소시키고 프로젝트 실패로 이어질 수 있습니다. 따라서 프로젝트에서는 오류 없는 성능과 높은 품질을 갖춘 시스템이 완성될 수 있도록 충분한 수의 테스트를 수행해야 합니다. 프로젝트 품질을 향상시키기 위해 테스트를 전문으로 하는 조직이나 회사가 있습니다. 예산이 충분한 특정 조직이 있습니다. 어떤 경우에는 회사나 조직이 품질 활동을 전문 테스트 기관에 의뢰하는 경우도 있습니다. 이러한 테스트를 전문으로 하는 품질활동 조직을 QA(Quality Assurance)라고 합니다. 어떤 경우에는 QA를 통해 전문적으로 테스트를 진행하기도 합니다. 하지만 기업이나 조직에서 QA를 활용하더라도 비즈니스와 IT 콘텐츠에 익숙한 프로젝트팀이 테스트와 품질 활동도 함께 수행해야 한다. 품질은 등급에 따라 구별됩니다. 품질은 프로젝트를 통해 구현된 시스템이 제공하는 기능이 오류 없이 정확하고 일관되게 작동하는 특성입니다. 반면, 등급이란 시스템의 사양이 높거나 다양하고 복잡한 기능을 갖추고 있음을 의미합니다.[품질과 등급의 차이]
일반적으로 고객에게 낮은 품질의 시스템을 제공하면 문제가 되지만, 낮은 품질의 시스템을 제공하는 것은 문제가 되지 않는 경우가 많습니다. 그리고 고객이 요구하는 것보다 더 많은 기능을 제공할 필요도 없습니다. 고객이 요구하지 않는 기능을 제공하는 것을 금도금이라 하며, 이는 도장, 금도금과 유사합니다. 프로젝트를 통해 구현된 시스템 결과(인도물)의 품질 수준에 대한 허용 범위는 프로젝트에 따라 결정됩니다. 이해관계자가 어떤 관점에 더 높은 가치를 부여하는지에 따라 달라질 수 있습니다. 즉, 결과물의 품질 수준과 프로젝트 이해관계자의 동의는 서로 연관될 수도 있고 그렇지 않을 수도 있습니다. 일반적으로 회사 및 조직 정책에서는 품질 문제 또는 오류에 대한 조치를 완료한 다음 프로젝트 이해관계자에게 알리도록 규정합니다. 납품물품을 제공하고 있습니다. 그러나 프로젝트 이해관계자는 품질 문제 없이 결과물을 수락하지 않을 수도 있고, 반대로 품질 문제가 있어도 결과물을 수락하는 경우도 있습니다. 이는 프로젝트를 통해 구현된 시스템 결과물이 비즈니스 관점에서 필요할 때가 있고 품질 문제가 있다는 것을 의미합니다. 내용에 따라 이해관계자의 인수기준이 다르기 때문이다. 결과물이 다소 부정확하고 오류가 해결되지 않은 채로 남아 있더라도, 납품 날짜가 매우 중요하거나 사소한 세부 사항이 부정확한 경우 프로젝트 이해관계자의 의사 결정에 의해 넘겨질 수 있습니다. 그러나 이러한 경우에는 운영 단계에서 시스템 오류에 대한 대책을 강구해야 하며, 잘못된 판단으로 인해 더 큰 문제가 발생할 수 있는 경우도 있습니다.