http://blog.naver.com/prologue/PrologueList.nhn?blogId=weedboy
이제 분석단계를 마치고, 기획자는 수행기획안을 기반으로 구체적인 설계를 시작한다.
설계라 하면 일반적으로 화면설계 즉, 스토리보드를 만드는 업무가 되겠다.
자...각 페이지별로 화면설계서를 만들기 위해서는 어떠한 작업들이 필요할까?
먼저 화면설계서에 나와야 할 화면단위별 페이지가 얼마나 필요한지, 그 화면에 담겨야 할 요소는 무엇인지,
이 화면 다음에는 어떠한 화면이 나와야 하는지 크게 이러한 문제가 해결되어야 화면설계의 첫페이지를 적어나가기 시작할 수 있을것이다.
"뼈대를 올리기 위한 기반공사"
이러한 준비를 위하여 우리가 만들어야 할 문서가 바로 IA, 기능정의서, Flow Chart(업무흐름도)이다.
IA는 보통 프로젝트에서 기본적으로 개발을 하는 문서(물론, 양식은 제 각각이지만..)이지만, 기능정의서나 Flow Chart는 패스하거나 약식으로 공유하는 경우들이 많다. 작은 프로젝트의 프로세스를 가지고 있더라도 기본적으로 준비를 해보는것이 업무파악을 하고 업무에 대한 미스커뮤니케이션을 최소화 할 수 있다.
IA(Informaiton Architecture)
지난번에 IA에 관련하여 글을 하나 올린적이 있다. 그 글에는 전체메뉴구성에 있어 서비스별로 사용자의 접근성이나 정보전달을 위한
최적의 메뉴구성안에 중점을 두고 작성했다면 이번에는 IA를 작성하는 방법이나 IA를 통해서 어떠한 커뮤니케이션이 일어나는지에 대해서 알아보고자 한다.
IA에 명시되어야 할 필드를 살펴보면,
1) CODE : 해당 페이지에 대한 코드값으로 화면설계서나 검수과정에서의 오류체크리스트 등 모든 문서에서 앞으로 사용하게 될 고유번호이다.
2) Depth명 : 1Depth에서부터 최하Depth까지의 메뉴구조와 해당 메뉴에 대한 메뉴명으로 띄워쓰기,한/영표기 등 정확하게 기입한다.
3) 페이지수 : 해당 메뉴에 페이지수를 말하며, 예를들어 하나의 html 페이지라고 하더라도 내용이 많을 경우 기본 A4용지를 기준으로 페이지수를 산정한다.
4) 형식 : 해당 페이지의 타입을 정의하는 것으로 html, program, link로 크게 구분을 하며, link형식일 경우에는 페이지수를 카운팅 하지 않는다.
5) 구조 : 페이지의 표현구조를 정의하는 것으로 winpop, layerpop, iframe으로 구분하여 해당 페이지를 출력하는 방법에 대해서 명시한다.
6) 포함 : 해당 페이지에 포함된 별도의 확장자를 가진 경우 표기하며, movie(동영상), flash(플래시), doc(문서)로 구분하여 명시하고, 해당 자료는 반드시 요청하여 원본파일을 수령해야 한다.
7) 권한 : 해당 페이지의 접근 권한을 정의하며, 접근권한은 전체 회원의 등급 및 플로워차트를 설계하는데에도 아주 중요하므로 정확한 접근권한을 명시해야 한다.
8) 업데이트 : 해당 페이지 및 메뉴별 업데이트 주기를 표기하며, 업데이트 주기와 관련하여 페이지에 대해서 관리자기능 구현 여부를 판단하도록 한다.
9) 설명 : 해당 페이지에 대한 별도 설명을 기록하며, 대부분 개발이나 디자인에서 주의해야 할 사항이나 기획자가 화면설계시에 반드시 명시해야 하는 사항에 대해서 코멘트 한다.
위의 IA 문서 구성필드는 제가 만든 극히 개인적인 항목들이다.
이에 더 필요한 항목이 있다면 추가하면 될것이고 프로젝트의 성격에 따라서 필요없는 항목들은 삭제하여 IA를 구성하면 될것이다.
보통의 프로젝트에서 각 페이지별 위의 항목들은 명시가 되어야 업무파악이 가능할 것으로 판단하여 작성해 보았다.
IA에 정의된 모든 페이지는 페이지수가 존재하는 한 한페이지도 빠짐없이 화면설계서(SB : Story Board)로 만들어져야 한다.
IA는 만들어져서 배포되는 순간부터 전체 개발자와 클라이언트와의 의사소통에 주체가 되므로 작성법이나 활용법에 대한 사전 리뷰가 반드시 필요할것으로 판단된다.
기능정의서
기능정의서는 클라이언트의 기능요구사항과 개발자의 구현된 아웃풋과 미스커뮤니케이션에 의한 잘못된 아웃풋을 맞이하는 리스크를 방지하기 위한(?) 문서로 보인다.
기능정의서는 각 주요기능 또는 세부기능에 대한 모듈별/프로세스별/메뉴별 등의 단위로 묶어 해당 기능에 대한 구체적인 요구사항과 정책사항, 제약사항 등을 명시하고 공유하는 문서이다.
기능정의서에 명시되어야 할 필드를 살펴보면,
1) 분류 : 간략한 기능에 대한 분류를 명시한다. 예) 검색기능, 추천기능, 수정기능, 회원가입기능 등
2) 정의 : 현 프로젝트에 적용될 기능에 대해서 간단히 명시한다. 예) UCC게시판에서의 추천기능에 따른 처리사항
3) 상세설명 : 해당 기능에 대한 각 요소별 적용범위 및 개발에 대한 범위를 상세히 명시한다. 예) 검색범위,검색방법,검색가능컨텐츠, 검색결과에 출력할 항목 등
4) 적용메뉴 : 해당 기능이 적용될 모든 메뉴 예) 공지사항게시판, Q&A게시판, 통합검색, 이미지형게시판 등
5) 정책 : 해당 기능이 구현되어 서비스됨에 있어 제약사항이나 정책적으로 고려되어야 할 사항 예)DB검색을 기본으로 하며 최초 검색은 검색시점으로 부터 30일이전 컨텐츠를 검색 등
6) 기능설명 : 해당 기능이 구현될 페이지의 UI를 기준으로 한 요소별 액션에 대한 결과값을 명시한다. 예) 검색버튼 클릭 시 검색결과페이지로 이동
7) 요구사항 : 현업 담당자의 구체적인 요구사항을 여과없이 기록하여 공유하며, 내용에 대한 별도 기획자/개발자의 코멘트를 첨부한다.
8) 중요도 : 해당 기능 구현이 전체 프로젝트의 구축 비중에 기준한 중요도를 표기하며, 리스크 발생 시 중요도에 준하여 별도 협의를 진행한다. 예) 상/중/하
9) 담당자 : 기획/개발/현업 담당자를 명시한다.
현재 기능정의서가 웹에 공유되는 문서를 보면 매우 다양하게 만들어져서 사용되고 있다. 물론 다른 문서들도 마찬가지이지만...
본질적으로 기능정의서를 왜 만들고 공유함으로서 어떠한 목적으로 가지고 공유되는가에만 충족할 수 있는 항목들로 구성된 문서이면 충분하다고 생각한다. 모든 문서가..
Flow Chart(업무흐름도)
플로우차트는 대부분의 프로세스를 단계별로 USER와 DATA의 흐름을 명시하는 문서라고 보면 된다. 우리가 흔히 알고 있는 순서도(?)의 모습을 상상하면 쉽게 접근할 수 있다.
플로우차트를 처음부터 문서로 만들어서 담기는 사실상 어렵다고 본다. 누락되는 단계도 발생할 수 있으며, 잘못된 이해를 하기 쉽기 때문이다.
그래서 하나의 업무(서비스)에 대한 플로우차트를 그리기 전에 우리는 '목업테스트(Mock-Up Test)'라는 과정을 거치게 된다.
목업테스트는 하나의 프로세스를 서비스하는데 발생되는 요소나 객체단위를 모아서 서비스이용에서의 USER의 이동 및 액션에 대한 흐름과 그에 따른 DATA의 흐름을 하나하나 연결하여 실제 완성될 서비스의 아웃풋을 미리 그려보는 과정이다.
여러분야에서 이러한 목업테스트는 최적의 아웃풋을 만들기 위해서 다양한 방법으로 진행이 되고 있다.
목업테스트를 통해서 나온 하나하나의 요소(페이지단위)들을 중심으로 우리는 플로우차트를 완성하게 되며, 이 플로우차트를 기준으로 하여 화면설계서의 페이지를 구성한다.
플로우차트에 명시된 모든 페이지는 반드시 필요한 페이지이며, 해당 페이지의 누락은 서비스가 진행되지 않음을 명심해야 한다.
여기서 우리가 알고 넘어가야 할 것이 바로 UML과 ERD이다.
나도 아직 관심만 갖고 하나하나 책을 찾아가면서 읽어보고 공부를 하는 중이라서 깊게 설명은 못하지만,
UML을 통해서 프로젝트 내에 모든 서비스에 대한 전체적인 프로세스의 흐름을 파악하는데 굉장히 유용한 수단이라고 생각한다.
UML을 작성하는 방법이나 툴은 여러가지들이 있다. 아래 참고할만한 책을 추천한다.
UML - Unified Modeling Language(표준화된 모델링언어)
1) 유즈케이스 다이어그램
2) 클래스 다이어그램
3) 오브젝트 다이어그램
4) 시퀀스 다이어그램
5) 액티비티 다이어그램 : 웹기획자가 꼭 알아야 할 다이어그램
6) 스테이트 차트 다이어그램
7) 컴포넌트 다이어그램
8) 배치 다이어그램
9) 객체 다이어그램
10) 커뮤니케이션 다이어그램
ERD - Entity Relationship Diagram(개체관계도)
보통 프로그래머들이 DB 테이블 설계를 위하여 만드는 것으로 각 엔티티별 관계도를 그리는 과정이다.
UML과 달리 USER의 흐름과는 달리 DATA의 흐름에 있어 생성/변경/삭제되는 일련의 과정에 따른 DATA의 흐름을 고려하여 그리고 되며, 각 엔티티의 속성값과 속성값별 타입에 대한 정의를 구체화 하여 결국 DB 테이블명세서가 나오게 되는 것이다.
