4.2 개발 프로세스 표준화 #1483
Description
4.2 개발 프로세스 표준화
4.2.1 문서 표준화
아키텍처 구현 작업은 시스템 구축 초기에 수행되므로, 일반적인 애플리 케이션 기능 개발보다 먼저 수행됩니다.
따라서 애플리케이션 기능의 설계 및 구현을 위한 입력 문서 또한 사전에 표준화해 둘 필요가 있습니다.
실제 개발 현장에서는 소프트웨어 엔지니어링에 정통한 아키텍트가 표준화를 지원하거나, 경우에 따라 이를 주도하는 사례도 적지 않습니다.
4.2.2 기능 명세서 표준화
유스케이스 다이어그램
이 다이어그램은 UML이라는 표준화 기법을 사용하므로, 기본적인 표기법은 이미 통일되어 있는 경우가 많습니다.
하지만 작성자에 따라 다이어그램의 단위, 유스케이스의 세분화 수준, 표현 방식이 달라질 수 있어 일정한 정책을 정해두는 것이 좋습니다.
유스케이스 다이어그램에서는 요소 간 의존 관계를 나타내기 위해 일반화 관계, 포함 관계, 확장 관계라는 개념을 사용합니다.
업무 담당자 입장에서는 이러한 흐름을 다이어그램으로 정확히 표현하는 데 어렵다는 점에서, 보통은 ‘경비 정산 신청하기’ 유스케이스 설명 안에 해당 조건과 처리 과정을 함께 기술하는 경우가 많습니다.
이처럼 설명이 명확히 정리되어 있다면, 굳이 해당 관계를 다이어그램으로 나타내지 않아도 충분합니다.
유스케이스 기술서
각 유스케이스의 동작 요구사항을 구체적으로 정리한 것입니다.
유스 케이스 기술서는 다양한 시나리오를 일정한 형식에 따라 정리한 문서입니다.
표 4.1 유스케이스 기술서 예시
| 유스케이스명 | 경비 정산 신청하기 |
|---|---|
| 사용자 | 주 사용자: 신청자, 부 사용자: 워크플로 서비스, 증빙 관리 서비스 |
| 요약 | 직원이 업무상 선결제한 경비를 회사에 청구하기 위해 신청한다. |
| 사전 조건 | 회계 기간이 열려 있다. |
| 사후 조건 | 워크플로가 시작되고 승인자가 지정되어 있다. 신청자가 업로드한 증빙자료에 타임스탬프가 부여되어 등록된다. |
| 주요 성공 시나리오 | 1. 사용자는 자신이 선결제한 비용의 금액, 용도 등의 정보를 입력한다. 2. 시스템은 입력 내용을 확인한다. 3. 사용자는 증빙자료를 업로드한다. 4. 시스템은 증빙자료가 유효한지 확인한다. 5. 사용자는 경비 정산을 신청한다. 6. 시스템은 신청번호를 부여하고, 워크플로 서비스를 호출하여 신청 처리를 진행 한다. 또한 증빙 관리 서비스를 호출하여 증빙을 등록한다. |
| 예외 시나리오 | 2a. 입력 내용이 충분하지 않은 경우, 시스템은 오류 메시지를 표시하고 사용자에게 수정을 촉구한다. 4a. 증빙자료가 전자문서 및 전자거래 기본법 요건을 충족하지 못하는 경우, 시스 템은 오류 메시지를 표시하고 사용자에게 수정을 촉구한다.[BR-010] 6a. 워크플로 설정이 잘못되어 승인자를 찾을 수 없는 경우, 시스템은 오류 메시지를 표시하고 유스케이스를 종료한다. |
| 대체 시나리오 | 사전 신청이 있는 경우 1a. 사용자는 경비 정보 외에 사전 신청 항목을 선택한다. 2b. 선택한 사전 신청 항목이 이미 개인 결제로 처리된 경우, 해당 금액은 정산할 비용에서 상계 처리한다.[BR-020] |
| 비즈니스 규칙 | [BR-010] 전자문서 및 전자거래 기본법의 보존 요건 점검 [BR-020] 개인이 선결제한 비용의 상계 처리 |
유스케이스 기술서 작성 시 핵심 고려 사항
유스케이스 기술서를 작성할 때 가장 중요한 것은 적절한 추상화 레벨에서 기술 하는 것입니다.
『앨리스터 코오번의 유스케이스』에 따르면 유스케이스에는 요약, 사용자 목표, 하위 기능의 세 가지 목표 레벨이 있는데, 이 중 사용자 목표가 가장 중요하다고 합니다.
추가적으로 고려해야 할 사항은 다음과 같습니다.
- 사전 조건과 사후 조건은 시스템 외부에 있는 사용자가 인식할 수 있는 상태만 기술하고, 시스템 내부 상태는 포함하지 않는다.
- 사용자 인터페이스에 의존하는 표현을 피한다.
- 화면이나 장부의 개별 항목을 나열하지 않고, 정보의 청크 형태로 기술한다.
- 비즈니스 규칙이나 비즈니스 로직의 세부 사항은 기술하지 않는다.
- 사용자가 직접 처리할 수 없는 시스템적 예외(예: DB 장애, 서버 오류)는 기술하지 않지만, 사용자가 개입할 수 있는 예외 상황이라면 포함한다.
기능 명세서
실제 사용자 인터페이스로 구현될 화면이나 각종 출력 서식(증빙 양식 등)의 구성은 기능 명세서를 통해 정의합니다.
기능 명세서에는 일반적으로 다음과 같은 항목을 기재합니다.
- 화면 전환도
- 화면 레이아웃 정의 (각종 문서 서식의 레이아웃 포함)
- 항목 정의
- 화면 이벤트 정의
- 로직 정의
기능 명세서는 ‘어떻게 실현할지(How)’가 아니라, ‘무엇을 할지(What)’를 설명하는 문서여야 합니다.
자신을 QA 엔지니어라고 가정하고 해당 명세서를 읽고 내용을 이해할 수 있는 지, 그리고 그 내용을 바탕으로 구체적인 테스트 케이스를 설계할 수 있는지 스스로 질문해 보는 것이 좋습니다.
COLUMN: 유저 스토리 user story
유저 스토리는 보통 한 장의 카드에 담을 수 있을 만큼 짧고 명확하게 작성되며, 다양한 형식이 존재합니다.
아래는 예제입니다.
부정한 경비 사용으로 인한 회사 손실을 방지하기 위해 감사 담당자로서 부정이 의심되는 경비 정산 신청을 감지하는 기능을 원한다.
4.2.3 설계서 표준화
클래스 다이어그램이나 협업 다이어그램을 상세하게 미리 작성하더라도, 실제로 소스 코드로 구현하는 과정에서 그대로 반영되지 않는 경우가 많아 설계서와 소스 코드가 항상 일치하도록 관리하는 것은 쉽지 않은 일입니다.
현실적인 문서화 방식은 최종 소스 코드에서 리버스 엔지니어링reverse engineering으로 소스 코드에서 역으로 설계 구조를 도출하여 다이어 그램을 생성하는 것입니다.
복잡한 처리 등에 대해서만 설계서를 작성하는 것도 합리적인 접근 방식입니다.
반드시 작성하는 것이 좋은 설계서도 있습니다.
대표적인 예가 데이터베이스 관련 설계 문서입니다.
여기에는 ER 다이어그램 entity-relationship diagram(엔티티 관계도), 테이블 목록, 테이블 정의서 등이 포함됩니다.