[SW프로세스 I] 폭포수 모델에 기반한 프로세스
소프트웨어 프로세스는 프로젝트를 구성하는 상호 관련된 조직별 작업들이 모여 일련의 과정을 통해 약속된 시간안에 요구되는 품질 수준으로 결과물을 생산하기 위한 모든 활동의 집합을 의미합니다. 이 활동의 집합에는 기획, 개발, 테스트, 데이터, 디자인 등 개별 작업이 포함되어 있고 소프트웨어를 생산하고 유지보수 하는 작업의 과정을 ‘소프트웨어 개발 프로세스’라고 부릅니다.
소프트웨어 개발 프로세스는 소프트웨어를 개발할 때 필요한 절차를 체계화한 것으로 요구사항을 구현하기 위한 활동입니다. 여기에는 작업을 수행하는 데 필요한 방법, 도구, 일정, 계획, 비용 산정, 작업자 간의 의사소통 기준, 작업 진행 상황 파악, 품질 목표 기준 등을 포함합니다. 효과적이고 효율성 있는 소프트웨어 개발을 위해 축적된 경험과 지식을 바탕으로 시행착오를 줄이고 일을 원활히 진행할 수 있도록 안내하는 역할이 프로세스의 목적입니다.
소프트웨어 개발 프로세스는 폭포수 모델과 애자일 모델로 크게 두가지 모델로 나뉩니다. 이 중 폭포수 모델에 기반한 프로세스를 먼저 살펴보겠습니다.
폭포수 모델은, 소프트웨어를 개발하는 가장 기본적인 과정으로 그 구조는 요구사항 분석, 설계, 구현, 테스트, 유지보수 단계가 순차적으로 진행되는 형태를 가지고 있습니다.
폭포수모델의 특징은 다른 공학 모델과 다르게 이전 단계를 거슬러 올라갈 수 없다는 특징을 가지고 있습니다. 이것은 프로젝트에 참여하는 각 작업 담당자들이 각각의 단계에서 자신의 작업에 대한 계획을 검토해서 승인해야 일을 시작할 수 있고, 각 담당자들이 할당된 일을 완성한 후에야 다음 작업자에게 인수 할 수 있습니다. 즉, 기획자가 기획문서를 완성해야 개발자에게 인수 할 수 있고 개발자는 제품에 대한 구현을 완성해야 테스팅을 요청할 수 있다는 것을 의미합니다.
폭포수 모델의 장점은 전체 프로세스에 걸쳐서 초기에 설계했던 대로 제품이 개발되도록 철저한 통제가 이루어지기 때문에 계획이 어긋나지 않습니다. 또 각 단계별로 정형화된 방법으로 작업을 수행할 수 있고 모든 단계를 문서화하기 때문에 프로젝트 진행을 명확하게 할 수 있다는 장점을 가지고 있습니다.
하지만 이전의 단계가 완료될 때까지 다음 단계는 작업을 진행할 수 없다는 단점이 있어서 이전 단계에서 지연이 발생되면 전체 일정에 영향을 주게되고, 또 요구사항에 의존적이여서 변경사항이나 문제가 발생이 되면 즉각적인 대응이 불가해 프로젝트 전반에 치명적인 결과를 가져올 수 있습니다.
이 중에서,
제품 개발의 기본적인 과정인 폭포수 모델에 기반한 협업 개발 프로세스와 프로세스에서 수행되는 테스트 활동 그리고 QA의 역할을 살펴보도록 하겠습니다.
폭포수 모델에 기반한 협업 프로세스와 테스트 프로세스
폭포수 모델에 기반한 프로젝트의 프로세스 흐름과 프로세스에서 수행되는 테스트 프로세스를 시각화하면 화면과 같이 그려볼 수 있습니다. 이 프로세스 flow는 일반적이지 않지만 업계에서 비슷한 형태와 절차로 사용되고 있습니다.
협업 프로세스 절차는 제품을 고객에게 제공하기 위해 기획, 개발, 테스트, 디자인 등 각 직무별로 제품을 생산하는 활동에 대한 절차를 정의한 것입니다. 이런 활동들은 각 직무별로 독립적이나 상호 연결되어 있고 각각의 활동들이 모여 프로젝트라는 집합을 이루게 됩니다. 협업 프로세스 절차는 프로젝트에 주어진 기간안에 각자의 작업 시간과 활동을 구성하고 일이 처리되는 과정의 조정을 통해 목표 된 일정 내 결과를 산출하기 위한 목적을 가집니다.
원활한 업무 흐름과 직무별 작업 시간 확보를 위해 각각의 담당자는 약속된 시간과 요구되는 품질 수준의 작업물을 산출하기 위해 노력해야 합니다. 업무 과정상 진행을 방해하는 요인을 사전에 방지하기 위해 협업 프로세스를 도입하지만 담당자 각자의 노력이 동반되지 않는다면 아무리 강력한 프로세스도 무의미해질 수 있습니다.
협업 프로세스가 필요한 이유
업무 진행 상황과 흐름을 쉽게 파악할 수 있고 각 직무 활동을 효율적으로 통솔할 수 있다.
프로세스 진행 중 발생할 수 있는 delay spot과 업무 누락을 빠르게 확인하고 개선할 수 있다.
실무자가 프로젝트에서 ‘해야 할 일'과 ‘업무 우선순위’를 쉽게 파악할 수 있다.
업무 관리에 소요되는 시간을 단축하고 해야 할 일에만 집중할 수 있어 생산성을 높일 수 있다.
프로젝트에 투입된 각 담당자와 담당자별 역할을 쉽게 파악할 수 있어 커뮤니케이션 비용을 줄일 수 있다.
효과적인 협업으로 프로젝트 성공 경험이 높아짐에 따라 각 개인의 업무 성취감과 경력 개발에 도움이 될 수 있다.
협업 프로세스에서의 테스트 활동
협업 프로세스에서 테스트 프로세스는 파란색 테두리로 강조된 범위에 해당되며, 테스트 프로세스 절차를 분리해서 좀 더 구체적으로 살펴보면 화면과 같은 단계로 수행됩니다.
테스트 프로세스의 절차를 간략히 살펴보면,
1) 테스트할 대상이 선정되면 QA는 테스트 일정과 투입인원, 테스트 범위, 품질 목표 기준, 리스크 요소를 분석하여 테스트 수행을 위한 계획과 전략을 마련한다.
2) 요구사항 분석단계에서 QA는 기획서나 개발설계서, 고객 요구사항 문서와 정의된 품질 요소 그리고 리스크를 기반으로 정적 테스트 활동인 리뷰와 분석을 진행하고 분석된 내용을 기반으로 테스트를 설계한다.
3) 개발 설계와 구현이 진행되는 동안 QA는 테스트 케이스, 테스트 플랜, 테스트 데이터, 테스트 환경, 테스트 스크립트 작성 등 테스트 수행을 위한 준비와 구현 작업을 진행한다.
4) 개발 작업과 개발 테스트가 완료가 되고 결과물이 전달되면 이후에 정식절차를 거쳐서 준비된 테스트 산출물로 테스트를 수행하고 결함을 보고하는 과정을 반복적으로 수행한다.
5) 준비된 테스트 활동이 완료되면 테스트 종료 조건을 평가하여 출시를 선언하고 이후에 테스트 활동과 프로세스에 대한 준수 감사와 회고 활동을 수행함으로써 과정을 마무리한다.
개발 초기 품질 향상을 위해 공동으로 참여하는 활동
협업 프로세스 flow에서 분홍색 테두리로 강조된 부분인 ‘기획리뷰', ’서비스 아키텍쳐 리뷰’, ‘개발 코드리뷰와 테스트’, 그리고 ‘코드프리징’ 은 제품의 초기 품질을 향상하고 제품에 대한 이해수준을 맞추는데 도움이 되는 활동에 해당합니다.
정적테스트 활동인 기획리뷰와 서비스 아키텍쳐 리뷰, 코드리뷰를 통해 제품이 구현되기 전에 소스 코드, 기획서, 고객 요구사항 명세서, 개발 설계서, 테스트 계획서, 테스트 케이스 등과 같은 산출물을 리뷰하고 분석을 통해서 명세상의 오류를 발견합니다.
정적 테스트를 수행하면 개발 초기에 요구사항 분석 단계에서부터 결함을 발견할 수 있고 이것을 통해서 일정 수준의 품질을 확보 할 수 있어서 전체 개발 과정의 효율을 높일 수 있습니다. 또 기간을 단축하거나 개발과 테스팅 비용을 줄일 수 있다는 장점도 있습니다. 이런 이유로 정적 테스트를 얼마나 잘 수행하느냐에 따라서 다른 테스팅 기법보다 더 효과를 볼 수 있습니다.
개발 테스트는 테스트 조직에서 수행하는 정식 테스트가 시작되기 전 테스트 조직에 개발 구현 작업물을 전달하기 앞서 작업물이 테스트 가능한 상태인지 확인하고자 개발 팀 또는 담당 개발자가 테스트 주체가 되어 개발 마무리 단계에서 실행하는 테스트이고,
코드 프리징은 개발 작업이 완료되고 개발자 테스트까지 수행되고 난 후 QA 조직으로 작업물을 인수하기 전 개발 팀 내부에서 작성된 코드에 대한 리뷰 활동을 진행하고 추가 수정·개발 작업이 없다면Code Frezze 상태로 테스트 조직에 결과물을 전달하는 것입니다. 여기서 말하는 코드 프리즈 된 상태는 테스트 환경에 배포된 코드, 즉 코드를 더이상 수정하지 않는 상황을 말합니다. 개발이 완료되고 테스트 조직으로 결과물이 인수된 이후 중간에 어떠한 추가 개발이나 수정 작업을 하지 않는 것입니다.
코드 프리즈가 필요한 이유는, 테스트를 요청하는 단계가 계획한 개발 작업이 모두 완료된 상태로 테스트 중 발견되는 문제가 없다면 라이브로 배포가 가능한 상태입니다. 그런데 코드가 프리즈되지 않은 상태에서 테스트 기간 중 코드를 추가하거나 수정 작업을 계속해서 진행된다면 테스트 기간동안 발견한 오류의 원인을 규명하는 것이 매우 어려워질 수 있고 테스트 조직에서 진행한 품질 검증 활동과 테스트 결과에 대한 신뢰가 떨어지고 제품의 안정성도 보증할 수 없기에 코드 프리징이 필요합니다.
프로세스에서의 QA 역할
프로세스에서의 QA 역할은 소프트웨어 프로덕트의 품질을 위해 테스트를 수행하고, 테스팅 활동에 대한 관리에만 역할이 한정되어있지 않습니다.
품질에 영향을 주는 모든 요소가 QA가 관리하고 감시하고 통제해야 할 범위에 해당됩니다. 이 요소에는 품질을 예방하는 차원의 브랜드나 지표 조사도 포함될 수 있고, 프로세스를 만들고 적용하고 준수여부를 심사하고 개선하는 것도 포함될 수 있습니다.
또 기획과 개발의 산출물인 문서와 코드를 작업 담당자들이 직접 리뷰하고 테스트해서 품질을 향상하는 방법을 찾을 수 있도록 권고하거나 지원할 수 있고, 품질 목표와 테스트 활동에 대한 가이드와 교육도 포함될 수 있습니다.
그 밖의 요소로 프로젝트를 잘 운영하기 위한 커뮤니케이션 관리, 산출물 관리, 리스크 관리, 형상 관리, 장애 관리 등도 QA의 역할에 포함될 수 있습니다.
이처럼, QA의 역할은 설계 단계에서부터 활동이 시작되고, 제품이 개발되는 전체 과정을 품질적 관점에서 관리하고 통제합니다.
QA가 이렇게 광범위하게 활동하는 이유는,
제품의 품질은 프로세스 모든 단계와 작업에서 빠질 수 없는 활동이고 구성원 모두의 책임이기 때문입니다. 제품 개발에 참여한 구성원이 각자의 작업에서 목적과 방법이 다를 뿐 품질에 대한 책임과 완성도를 고려해서 작업할 수 있도록 QA는 품질을 코칭하고 지원해주어야 합니다.
