제목: 구조적 워크쓰루 프로세스 가이드(Structured Walkthrough Process Guide)
저자: COMMONWEALTH OF PENNSYLVANIA, DEPARTMENT OF HUMAN SERVICES
문서유형: 기술 문서(총 31페이지), 1999년
미 펜실베니아주 복지부의 정보 시스템 부서에 발행한 IT 가이드라인 문서. 소프트웨어 개발 프로젝트의 생명 주기 단계 동안 어떻게 워크쓰루를 수행하는지에 대해 기술함
구조적 워크쓰루(Structured walkthroughs)란
- 구조적 워크쓰루는 한 무리의 동료 작업자가 소프트웨어 개발 및 유지보수 산출물의 기술적 측면(정확성, 완전성)을 검토하고 논의하는 체계적인 절차이다.
- 구조적 워크쓰루의 주 목표는 에러를 발견하고 제품 품질을 향상시키는 것이다. 통상적인 에러 타입으로 누락, 모순, 로직 결함, 비일관성 등이 있다.
- 워크쓰루의 기본 목적은 에러 발견이지 에러 수정이 아니다(구조적 워크쓰루가 발견된 에러의 해결책을 논의하기 위해 사용되지 않음).
- 워크쓰루가 완료되었을 때 해당 산출물의 작성자는 에러를 수정하는데 필요한 조치를 취할 책임이 있다(검토자들과 사적으로 대화하거나 해결책을 논의하기 위한 후속 미팅을 잡음).
- 구조적 워크쓰루는 소프트웨어 생명 주기의 모든 단계 동안에 수행된다. 또한 다양한 형식과 정형화 수준에서 수행될 수 있고, 다양한 타입의 참가자가 참여할 수 있다.
참가자(Participants)
구조적 워크쓰루의 각 참가자가 특정 역할을 하게 되며, 작은 규모 프로젝트에서는 한 사람이 여러 역할을 하기도 한다.
- 작성자(Author): 적당한 크기와 완성도의 산출물 일부가 개발되면 그 작성자가 워크쓰루를 요청한다. 작성자는 관찰자(observer)로써 워크쓰루에 참여하고 검토자들의 질문에 답한다(작성자는 검토자가 아님). 워크쓰루 세션 후에는 워크쓰루 회의록을 체크리스트 삼아 식별된 모든 에러를 수정하고, 검토자 코멘트도 반영한다.
- 발표자(Presenter): 대개 워크쓰루를 위한 아젠다를 개발하고 검토될 산출물의 발표를 책임진다. 발표자가 해당 산출물과 친숙해야 하며, 프로젝트 관리 팀의 일원이 이 역할을 할 수도 있다. 워크쓰루에 참여할 검토자, 중재자, 서기를 선정하고, 시간과 장소도 계획한다. 적어도 워크쓰루 2일 전에 산출물을 검토자에게 배포한다. 워크쓰루 완료 후 평가 결과에 대한 의견 일치가 안되는 경우 발표자가 최종 결정을 내린다.
- 중재자(Moderator): 워크쓰루 아젠다가 준수되도록 보장하고, 모든 검토자들의 참여를 독려하는 등의 원할한 워크쓰루 세션 진행을 책임진다. 중재자가 서기 역할을 담당할 수도 있다. 워크쓰루 세션이 2시간이 넘어가면 적절선에서 중단하고 추가 세션을 잡는다.
- 검토자(Reviewers): 기술적으로 정확한지 결정하기 위해 산출물을 평가한다. 프로젝트 가이드라인/표준이 준수되었는지, 프로젝트 요구사항이 충족되었는지, 작성된 출력물이 적절한지 등도 평가한다. 워크쓰루 세션 사전에 자료를 검토하고 에러, 코멘트, 질문 등을 기록하며, 여기에 투자한 시간량을 실제 세션 진행 시 서기에게 알려준다.
- 서기(Scribe): 워크쓰루 동안에 식별된 에러와 기타 기술적 코멘트, 제안, 미해결 질문 등을 기록한다(서기는 검토자가 아님). 워크쓰루 세션에 대한 관리 정보(시작 시간, 참석자, 종료 시간 등등)도 기록한다. 워크쓰루 세션 후에는 작성된 회의록 사본을 참석자들에게 배포하여 내용이 정확한지 체크한다(필요 시 업데이트).
워크쓰루 회의록 템플리트
검토자들은 워크쓰루 세션 사전에 산출물을 검토하고 발견한 에러를 아래와 같은 ‘구조적 워크쓰루 회의록 워크시트’에 기록한다. 서기가 워크쓰루 동안에 논의된 정보를 기록하는데도 이 워크시트를 사용한다. 워크시트는 두 개 파트로 구성되어 있으며, 파트1은 관리용 회의 정보를 파트2는 검토자 코멘트, 질문, 후속 조치 항목(action items) 등을 기록하는데 사용된다.
개발 단계별 구조적 워크쓰루
구조적 워크쓰루는 개발 또는 유지보수에 있는 시스템을 생명 주기의 여러 단계 동안 검토하는데 사용되며, 생명 주기 각 단계에서 검토되는 산출물 목록이 아래와 같다(미 펜실베니아주 복지부가 채택한 ‘소프트웨어 개발 방법론’에 기술된 산출물에 상응하는 산출물 목록임).
계획 단계(Planning Phase)
계획 단계는 개발 또는 유지보수 작업을 위해 수행해야 할 일들을 정의하고, 요구되는 리소스를 추정한다. 계획 단계 동안 각 프로젝트 관리 도구에 대한 구조적 워크쓰루가 수행된다.
|
목적 |
참가자 |
|
아래를 포함한 이 단계의 산출물을 검토한다.
|
프로젝트 관리 팀 프로그램 관리 사무소 적어도 1명의 프로젝트 관리자(가능하면 프로젝트 외부 사람) |
요구사항 정의 단계(Requirements Definition Phase)
요구사항 정의 단계는 개발 또는 유지보수 프로젝트의 범위와 요구사항을 결정한다. 요구사항 정의 단계 동안 요구사항 명세에 있는 문제점, 부정확한 사항, 모호한 사항, 누락 사항 등을 식별하기 위해 구조적 워크쓰루가 사용된다.
|
목적 |
참가자 |
|
아래를 포함한 이 단계의 산출물을 검토한다.
|
프로젝트 관리 팀 프로그램 관리 사무소 적어도 1명의 프로젝트 관리자(가능하면 프로젝트 외부 사람) |
개괄적 시스템 설계 단계(General System Design Phase)
개괄적 시스템 설계 단계는 기능 요구사항을 충족시키기 위해 어떻게 소프트웨어가 구축되어야 할지를 결정하는 설계 요소(design elements)를 선정한다. 개괄적 시스템 설계 단계 동안 설계 아키텍쳐에 있는 결점, 약점, 에러, 누락을 식별하기 위해 구조적 워크쓰루가 사용된다.
|
목적 |
참가자 |
|
아래를 포함한 이 단계의 산출물을 검토한다.
|
프로젝트 관리 팀 프로그램 관리 사무소 적어도 1명의 프로젝트 관리자(가능하면 프로젝트 외부 사람) |
상세 시스템 설계 단계(Detailed System Design Phase)
상세 시스템 설계 단계는 시스템 컴포넌트를 자세하게 기술하기 위해 개념적 설계와 시스템 아키텍쳐를 사용한다. 상세 시스템 설계 단계 동안 상세 명세서를 검토하고, 테스팅 및 구현 이슈 해결을 계획하는데 구조적 워크쓰루가 사용된다.
|
목적 |
참가자 |
|
아래를 포함한 이 단계의 산출물을 검토한다.
|
프로젝트 관리 팀 프로그램 관리 사무소 적어도 1명의 프로젝트 관리자(가능하면 프로젝트 외부 사람) |
개발 단계(Development Phase)
개발 단계에서는 소프트웨어 구축과 이 구축 프로세스의 통합된 한 부분인 테스팅이 수행된다. 개발 단계 동안 클린 컴파일, 테스트 데이터 베이스, 운영 문서에 대한 워크쓰루가 수행된다.
|
목적 |
참가자 |
|
대략 80 시간의 코딩 결과물(클린 컴파일) 또는 완성된 하나의 논리적 작업 단위를 검토한다.
|
적절한 전문 지식을 갖춘 기술 담당자와 적어도 2명의 추가 검토자 접근 방법에 따라 개발 팀 전체가 워크쓰루에 참여할 수도 있음 |
|
통합 및 시스템 테스트 데이터 베이스와 테스트 계획의 적정성을 판단한다. |
소프트웨어 통합 및 테스팅 단계(Software Integration and Testing Phase)
소프트웨어 통합 및 테스팅 단계는 개별적인 소프트웨어 컴포넌트들이 하나의 통합된 소프트웨어 제품으로 전이되는 단계이다. 이 단계 동안 통합된 제품을 테스트하고, 사용자와 유지보수 프로그래머에게 제공될 운영 문서의 정확성을 체크하고, 승인 활동을 계획하는데 구조적 워크쓰루가 사용된다.
|
목적 |
참가자 |
|
아래를 포함한 이 단계의 산출물을 검토한다.
|
적절한 전문 지식을 갖춘 기술 담당자 기술 작가(technical writer) 적어도 2명의 추가 검토자 접근 방법에 따라 테스팅 팀 전체가 워크쓰루에 참여할 수도 있음 소프트웨어가 메인프레임 플랫폼상의 애플리케이션이라면 ‘인프라구조 운영 부서’의 담당자도 포함시킴 |
|
아래 생산 활동을 검토한다.
|
승인 및 설치 단계(Acceptance and Installation Phase)
승인 및 설치 단계는 개발에 있는 소프트웨어가 완전 생산 상태의 제품(시스템)으로 전이되는 단계이다. 승인 및 설치 단계 동안 승인 테스트 보고서를 체크하고, 완전 규모 생산을 준비하기 위한 활동 계획을 점검하는데 구조적 워크쓰루가 사용된다.
|
목적 |
참가자 |
|
아래를 포함한 이 단계의 산출물을 검토한다.
|
적절한 전문 지식을 갖춘 기술 담당자 기술 작가(technical writer) 적어도 2명의 추가 검토자 접근 방법에 따라 사용자 교육 팀 전체가 워크쓰루에 참가할 수도 있음 소프트웨어가 메인프레임 플랫폼상의 애플리케이션이라면 ‘인프라구조 운영 부서’의 담당자도 포함시킴 |
|
아래 생산 활동을 검토한다.
|
'개발생명주기단계별 > 설계_설계 V&V' 카테고리의 다른 글
| 영상자료 - 상태 기반 테스팅 기법 (0) | 2021.11.01 |
|---|---|
| 문서요약 - UML 테스팅 프레임워크 by Pudipeddi (0) | 2019.10.03 |
| 문서요약 - 객체 지향 설계 인스펙션을 위한 리딩 기법 by Travassos (0) | 2019.05.20 |
| 설계 인스펙션 체크리스트 by Software Quality Consulting (0) | 2019.05.16 |