[web agency] project process standard guide

㈜홍익인터넷 업무 프로세스 표준화 지침

㈜홍익인터넷 CDM 업무 프로세스 표준화 지침

(PPSG)

작성자 : CDM Staff

㈜홍익인터넷

시행일 : 2000년 6월 1일

2차 수정일 : 2000년 7월 25일

3차 수정일 : 2000년 10월 31일

대외비

외부 유출 엄금.

Copyright 2000 ㈜홍익인터넷 All rights reserved.

-1-


목차

1. 업무 프로세스의 정의와 분류

1.1 업무 영역의 정의 및 분류

1.2 업무 프로세스의 정의와 적용

2. 업무의 역할 분장

2.1 업무 관할의 정의

3. 업무 프로세스의 표준화 모델

3.1 업무 표준화의 목적

3.2 업무 프로세스 표준화 모델의 종류

3.3 표준 업무 프로세스 모델

4. 용어의 정의 및 표준화

4.1 회의와 회의 관련 용어

4.2 프로젝트 관련 용어

4.3 Job Description

5. 업무 진행을 위한 표준화 문서 (별지 참조) 표준화지침서 (PPSG) RRPB (Request Report for Project Beginning) 기획서

스토리보드 (S/B) 플로우차트 (F/C) 코드화 규칙 (GDP) 프로그램 설계서

일정서

백서

고객만족조사 (CSSS) QA Report Data CD Format TYL (Thank You Letter)

6. Quality 란?

-2-


1. 업무 프로세스의 정의와 분류

효과적인 업무 진행을 위해서는 먼저 명확한 업무 파악을 위한 기본 업무 분류 모델을 필요로 하며 각

업무마다 그 성향과 업무에 필요한 표준적인 업무 프로세스를 적용하여 효율적이고 성공적인 업무 진행을

수행해야 한다.

1.1 업무 영역의 정의 및 분류

다음은 ㈜홍익인터넷이 현재 수행하거나 향후 수행될 업무 전반의 분류이다.

가. ConsultingWeb Agency업무로서의 컨설팅 영역을 지칭하는 것으로 기업의 신규 인터넷 비즈니스 모델에 대한

제안에서 구현할 시스템의 테크니컬한 요소에 이르기까지 다양한 부분의 컨설팅을 수행할 수 있다.

신규 비즈니스 모델링과 컨설팅

사이트 디자인 컨설팅

인터넷 서비스 시스템 컨설팅

나. Development고객이 구축 의뢰한 인터넷 사이트의 구축 구현 작업에 해당하는 업무이거나 혹은 인터넷 관련 사업으로

필요하다고 판단되는 애플리케이션의 제작과 같은 실무 제작 차원에 해당하는 업무로 PM, Planner, Designer, Engineer등으로 이루어진 하나의 TF조직이 고객이 의뢰한 사이트의 설계에서부터 구축까지

일련의 작업 수행하게 된다.

신규 사이트 제작

사이트 Renewal인터넷 애플리케이션 시스템의 제작

기타

다. Management이는 주로 Development 업무에서 구현한 사이트나 기타 의뢰 받은 사이트의 서비스 대행이나 관리와

보수 업무에 해당하는 것으로 크게는 사이트 시스템의 유지/관리에 해당하는 다양한 고객 서비스의

개념으로 해석될 수 있는 부분과 사이트의 마케팅 전략과 전략적 비즈니스 모델 구현등과 같은 적극적인

개념으로 해석될 수 있는 부분을 지니고 있다.

신규 비즈니스 모델의 구현

사이트 시스템의 관리와 보수

-3-


사이트 서비스 대행

1.2 업무 프로세스의 정의와 적용

㈜홍익인터넷이 수행하는 다양한 사업분야(업무)는 각각의 업무마다 다른 업무 진행 환경과 조건을 가지고

있는 경우가 많으며 또한 이를 진행하기위한 방법적 절차과정이 서로 상당에 해당하는 차이를 가질 수

있다. 업무 프로세스(Work Process)라 함은 이와 같은 다양한 업무 진행 조건을 가진 업무들에

대응하기위한 표준적 방법론을 제시하여 보다 효율적인 업무진행을 보장하고 표준화된 업무 진행으로

유발되는 업무진행의 효과적인 커뮤니케이션의 보장 그리고 나아가 보다 효율적인 수익구조를 창출하기

위한 것이라고 할 수 있다. 업무 프로세스 표준화는 주로 다음과 같은 3관점에서 진행되어야 한다.

가. 프로젝트 프로시저(Project Procedure)의 표준화

이는 프로젝트(업무)의 진행 방법을 표준화하는 것으로 실제 업무 프로세스 표준화의 가장 핵심적인

사항이라고 할 수 있다. 프로젝트 프로시저는 각각의 업무 영역마다 그 특성에 맞는 모델링이 되어야 하며

작업자는 각 업무에 맞는 표준적인 프로시저를 선택하여 업무를 진행해야 한다. 나. 프로젝트 진행을 위한 업무 용어의 통일화와 표준화

업무 진행을 위한 용어의 통일화 및 표준화 작업은 주로 고객과 그리고 사내 관계자간의 명확하고 효율적인

커뮤니케이션을 보장하는 것을 그 목적으로 한다. 또한 업무가 종료된 후에도 일관성있는 업무 데이터를

저장하고 이를 자료화하는데도 필요한 요소이다.

다. 프로젝트 진행을 위한 문서의 표준화

업무 용어의 표준화 작업과 마찬가지로 업무 진행을 위한 문서의 표준화역시 명확한 그리고 효율적인

커뮤니케이션을 보장하는 것을 그 주요 목적으로 하며 일관적인 사내 자료화를 위해서도 필요 요소라고 할

수 있다.

2. 업무의 역할 분장

효율적이고 성공적인 업무의 진행을 위해서는 합리적인 업무 역할의 분장이 이루어져야 한다. 이 장에서는

㈜홍익인터넷 CDM사업부의 업무 프로세스 진행 시 필요한 업무 역할의 정의와 상호 협조, 보고와 결재

관계를 정의한다.

2.1 업무 관할의 정의

가. e-Brain Groupe-Brain 그룹은 CDM 사업부내 영업, 마케팅, 고객관리 업무를 주요 업무 내역으로 하며 최초의 고객 의뢰

내용에 대응부터 프로젝트를 수주하기까지의 관리를 수행한다. 다음은 e-Brain 그룹의 주요 업무 내역에

-4-


대한 정의이다.

프로젝트 영업과 마케팅

프로젝트 제안

신규 비즈니스 모델의 연구와 모델링

나. CDM StaffCDM Staff은 각 단위 Cell의 Development 작업의 품질관리를 수행하며 신규 기술의 도입, 사내 CDM부서의 교육 그리고 외부 Outsourcing의 관리 등을 수행한다. 다음은 CDM Staff의 주요 업무 내역에

대한 정의이다.

CDM 사업부 Development 작업의 총체적 관리

외부 아웃소스 인력과 작업의 관리

CDM 인원의 교육

프로젝트와 포트폴리오의 관리

고객 관리

시안작업 (디자인) QA (Quality Assurance)

다. CDM Team 각 Team 조직은 Project Manager, Planner, Designer, Engineer 등의 인원으로 구성되며 주로

실제적인 프로젝트의 Development 업무와 Management 업무를 수행하게 된다.

3. 업무 프로세스의 표준화 모델

이 장에서는 ㈜홍익인터넷의 각 업무마다 표준적인 업무 진행 프로세스를 정의하고 이를 준수하도록 하여

효율적인 프로젝트의 진행과 사내/외 업무 커뮤니케이션을 표준화하는 데 그 주요 목적을 가진다.

3.1 업무 표준화의 목적

업무 표준화는 사내 다양한 각 업무들을 정확히 분석하고 각각의 업무마다 정의되어있는 표준적인 업무

진행 방법을 따르게 하여 효율적인 업무 진행을 보장하고 바람직하지 않은 업무 진행으로 인한 시간, 인력, 비용 등의 자원 소비를 사전에 예방하며 차후 일관성 있는 업무 자료를 확보할 수 있도록 하며 업무

관계자와 비관계자 그리고 고객과의 효과적이고 분명한 커뮤니케이션 채널을 유지하도록 하는데 그 주요

목적이 있다.

3.2 업무 프로세스 표준화 모델의 종류

-5-


다양한 업무 성격에 맞추어 각각의 업무 분류에 맞는 표준 업무 프로세스들을 적용해야 한다. 다음은 ㈜

홍익인터넷 CDM 사업부 주요 사업분야에 대한 표준 업무 프로세스 구분이다.

가. Consulting 프로세스 모델

Consulting 프로세스 모델은 주로 전략적 비즈니스 모델 컨설팅, 사이트 디자인 컨설팅, 인터넷 서비스

시스템 컨설팅 등 별도의 제작업무가 진행되지 않으며 고객의 의뢰사항 및 시장 파악 -> 분석 및 연구 -> 신규 혹은 수정 모델 제안(과제 해결)의 메커니즘을 갖게 된다. 이 지면에서는 별도의 Consulting 업무

프로세스를 논하지는 않기로 한다.

나. Development 프로세스 모델

Development 프로세스는 실제 프로젝트의 개발 업무로 정의 될 수 있으며 대부분의 경우 웹사이트의

제작이나 웹 애플리케이션 등의 제작 업무로 표현될 수 있다.

다. Management 프로세스 모델

Management 프로세스는 대부분의 경우 기존의 고객을 관리하는 서비스 업무에 해당할 수 있는데

사이트의 유지/보수, 기존 고객에게 신규 비즈니스 모델의 제안과 구현, 고객의 요구 사항 대응 등의 업무로

이루어진다.

2.3 표준 업무 프로세스 모델

가. Development ProcessDevelopment Process 모델은 웹사이트 제작, 웹 애플리케이션의 제작 등과 같은 제작 전반에 걸쳐 적용

될 수 있는 표준 프로세스로 대부분의 경우 Planning, Application Programming, Site(or Interface) Design 등의 작업이 동시에 진행될 경우가 많다.

Development 업무는 ㈜홍익인터넷 CDM 사업부의 주요 사업 내용중 하나로 이는 크게 표() 와 같이 영업 단계 > 기획 단계 > 제작 단계 > 유지 및 관리 단계로 나누어진다고 볼 수 있다. 각각의 단위 단계마다 표

-6-

고객의 제안 요청Project Profiler (PP)과제분석과 전략 수립

제안 단계

수주/제작여부 결정

과제분석

일정계획IMP시나리오 구상

자료수집 및 코드화

플로우차트

스토리보드

컨텐츠맵

일정계획 및 기획서

영업 단계 기획 단계 제작 단계 유지/관리 단계

상세 제작 계획

자료 가공

Alpha 작업

Beta 작업

Gold 작업Quality Assurance (QA)사이트 런치

운영자 교육

사이트 홍보CSSS유지 및 갱신


준 프로세스로 지정되어 있는 모델에 따라 작업자는 업무를 수행하는 것을 기본으로 하며 업무의 성격에따

라 각 단계마다 요소의 생략이나 첨가를 유연하게 진행할 수 있도록 한다 . 단, 각 Development 과정엔 3 회에 걸쳐 각 프로젝트 팀과 QM 이 품질관리를 위한 리뷰 미팅을 가지며, 고객과 각 단계별로 필요한 리뷰

를 갖도록 한다.

가.1 영업 단계

Deveolpment 업무의 시작은 대부분의 경우 고객의 제안요청에 대응하는 영업단계를 거치게 된다 . 고객

이 특정 개발주제를 가지고 이를 요청할 경우 CDM 사업부는 해당 요청건에 대한 과제 분석과 영업 전략을 수립하고 실제 제안 단계를 위한 제안 준비작업을 수행하게 된다.

제안 단계에서는 프로젝트 수주를 위한 PT(Presentation) 등이 이루어지며 고객에의해 수주나 제작 여부

가 결정된다. ( 특정 프로젝트의 경우 경재업체와의 경쟁적인 PT 를 수행하거나 생략될 수있다)

경쟁적인 PT 를 거친 후 프로젝트를 수주했건 그렇지 않건간에 이 단계에서는 고객에게 제안요청하는 프로

젝트의 전반적인 고객 요구와 과제분석 상황을 묻는 PP(Project Profiler) 를 작성하도록 한다. PP (Project Profiler)

고객에게 계획하고 있는 프로젝트의 제반사항을 묻는 문답서로 회사 전반 사항 , 프로젝트의 목적, 구현 시

스템등을 물어 프로젝트 관련 기초 이해 도모하는 것을 그 목적으로 한다.

* Communication Channel Map ( 각 부서간 업무 공조 관련 커뮤니케이션 채널에 관한 조직도)

(①∼⑦ 은 CES 를 통해 이루어지는 항목)

-7-

제안요청& RFP

과제분석과 전략 수립

제안의 준비

PT

PP 제작 여부의 결정

e-Brain 중심

Client의 RFP와 PP클라이언트 관련

정보 수집

산업환경 분석

미팅 준비

e-Brain 중심

1차 미팅

제안여부 결정

2차 제안미팅

- 제안서

- 견적서

- 시안

구축 문의 단계 미팅 단계 PT 단계 계약 단계

e-Brain 중심

계약완료 후

계약서(경영지원)TYL(QA Group)발송

제작 단계

e-Brain 중심PT (Presentation)수주 후 RRPB 보고

Project Team 선정

Project Team (PM) 중심Kick Off Meeting기획

개발

완료


① 문의 보고 항목

1) 문의 일시 및 문의 방법 (전화, 메일, Fax 등)

-8-

Client e-BrainRFP

Project Profiler

① 문의 보고

DROP 미팅진행

③ 미팅, BS 참가요청

1차 미팅회사소개서

제안여부결정

DROP 제안 미팅

② 미팅 보고

제안서

④ PT 참가요청

PT 담당자 선임 및 진행PT

FAIL 수주

⑤ PT 보고

⑥ 수주 보고

※ 1차 참여 인력 요청 (RRPB)(

계약완료

Kick Off Meeting ⑦ 미팅 참여 요청

참여 인력 확정

백서

i-Media

e-Solution

e-Consulting

QA-Group

전략기획

Design Lab시안

견적서

산업환경분석자료

벤치마킹

경영지원팀Client계약서

TYL

기획

개발

완료

i-Design

i-Planning

구축 문의 단계

미팅 단계

PT 단계

계약 단계

제작 단계

Project Team


2) 프로젝트 및 클라이언트 회사, 담당자, 부서, 연락처3) e-Brain팀 책임 담당자 (정, 부)4) 문의 및 구축 내용

5) 문의에 따른 대처 방안 및 요청 사항

6) 미팅 예정일

7) 접촉계기 ( 홍익을 알게 된 경로)

② 미팅 보고 항목

1) 미팅 일시 및 장소

2) 미팅 참가자 (홍익 / 클라이언트)3) 구축 내용

4) 논의 내용 (Agenda 위주)5) 요청사항 : BS (일정), 시안 필요 여부

6) 이후 일정

7) 관련 자료 분석

8) 담당자 의견 : 프로젝트 진행에 대한 의견 (예산, 접근 방식에 대한 의견)

③, ④, ⑦ 미팅, BS, PT 참가 요청

프로젝트 성격에 따라 참여인원 선정, Agenda 정리

⑤ PT 보고 항목

1) PT일시 및 장소

2) 참석자 (홍익 / 클라이언트)3) PT 내용

4) 최종 결과 발표일

가.2 기획단계

-9-

기획준비단계 시나리오 기획단계 기획의 구현 단계

과 제 분 석 (AA)

일정계획

아이디어 회의

시나리오의 구상

자료수집 및 코드화

일정계획 및 기획서 작성플로우차트 작성

스토리보드 작성

고객과 일정계획 협의 고객과 기획내용 협의 완료


성공적인 웹사이트의 구축에 있어 가장 중요한 단계라고 할 수 있다. 프로젝트 기획 단계는 크게 사이트

제작팀을 구성하고 고객의 과제 분석하여 전체 구축 일정과 자원관리 계획을 수립하는 『기획 준비 단계』

와 브레인스토밍 등을 통하여 주어진 과제를 구체화하고 사전 인터페이스/ 프로그램 설계를 수행하는 『

시나리오 기획 단계』 그리고 자료의 수집과 이의 분류/코드화, 플로우차트/스토리보드를 작성하는 『

사이트 기획 구체화 단계』로 나누어 볼 수 있다.

특히 이 단계가 충분한 시간을 가지고 철저하게 정립되지 않으면 후에 사이트 제작단계에서 제작 방향성의

혼선, 사이트 제작 도중 일탈, 제작물의 Quality 저하, 사이트 제작 시한의 연기 등의 문제가 나타나곤

한다. (사이트 제작을 의뢰한 고객 측에서 구체적인 리뷰물을 확인할 수 없는 등의 이유로 충분한

사전협의없이 지나칠 수 있다. 일정계획과 기획서의 제작이 끝나면 각각 시점마다 그 결과물을 고객과

충분한 검토→협의→확인하는 과정을 반드시 거쳐야 한다)

[기획준비단계] 과제분석 (Analyzing Assignment)과제분석 과정은 영업단계에서 고객에게 요청한 PP를 바탕으로 고객의 Needs를 정확히 파악하고 시장

현황, 제반 사항과 요구되는 비즈니스 전략에 맞추어 주어진 과제를 포괄적으로 이해하여 향후 올바른

기획과정에 반영될 수 있도록 한다.

벤치마킹 (Benchmarking)벤치마킹 참고 요소 (체크리스트) - Core Value : Eyeball, contents, look&feel, technology, navigation- Homepage 에서 보여주고자 하는 제일 중요한 Theme은 무엇인가?- Homepage 의 메뉴들은 무엇이며 어떻게 구성되어 있으며 사용자 배려가 보이는 곳이 있는가?- Effect로 어떤 것이 쓰였는가?- 플러그인은 무엇을 사용했는가? - Page 구성 요소가 완벽한가? (헤드, 바디, 푸터)- Loading 속도가 어떤가? (기준 제시)- 업데이트 주기가 보이는가? 있다면 얼마간의 간격으로 업데이트 되는가?- Information Architecture? 정보들이 이해하기 쉽게 분류 되어 있으며 네비게이션 중 혼돈되는

Flow는 없는가?- Labling 은 이해하기 쉬운가?- 웹에 작성된 컨텐츠의 가독성은 상, 중, 하 로 나뉘었을 경우 어떠며, 가독성이 좋지 않은 경우의

예는 어떤 것이 있는가?- 어떤 부분이 개인적으로 제일 마음에 드는가?- 본 사이트에서 배울 점은?- 수익성 창출 가능한 사이트로 보이는가? 그렇다면 수익은 어떻게 이루어 지고 있는가? 수익성

-10-


창출이 어려워 보인다면 수익성 창출을 가능하게 하기 위한 방법이 제안 가능한가?

일정계획 (PSS : Project Schedule Sheet) 일정 계획에는 크게 작업 스케줄과 인력체제의 편성, 그리고 개발비등의 비용관리 계획등을 포함시킬 수

있다. 이 일정 계획 요소중 작업 스케줄의 작성과 자원관리(인력 체제의 편성)은 필수적으로 계획되어야

하는 요소이다. 정확한 예측에의 해 계획되어진 일정은 지정된 형식의 PSS를 통해 고객과 사내에

보고되어야 한다.

[시나리오 기획 단계] 아이디어 회의 (IMP : Idea Meeting for Production)기본적인 과제 분석이 끝나고 프로젝트 진행일정이 계획된 후에는 프로젝트를 보다 효과적으로 수행하고

창의적인 작업물을 얻기 위하여 구체적인 아이디어 회의에 들어가야 한다. 이단계에서는 프로젝트 TF로

구성된 인원전체가 충분한 시간을 들여 BS와 같은 형태의 아이디어 회의를 진행한다.

시나리오의 구상 (Sketch of Site Scenario)아이디어 회의가 어느 정도 수행한 후에는 차후 구체적인 기획서를 제작하기 위한 사이트 시나리오(혹은

프로그램 시나리오) 구상작업을 진행한다. 이 작업을 통해서는 전체 프로젝트의 뼈대라고 할 수 있는

개괄적인 내용들을 충분한 논의를 통해 TF 인원 모두에게 명확히 이해 시킬 수 있어야 한다.

[기획의 구현 단계]기획의 구현 단계에서는 기획서, 자료수집 및 코드화 분류표, 스토리 보드, 플로우차트를 준비한다.

기획서

고객 정보, 프로젝트 이름, 작성자, 날짜, 본 프로젝트의 목적, 프로젝트의 요약, 타겟 관중, 아이디어

요약을 담은 기획서를 준비하며 다음의 나열된 과정에서 도출된 결과물을 첨부한다.

자료수집 및 코드화 (GPD : Gathering Project Data)- Directory Map 제작

대략적인 프로젝트 구성 내용들을 도출해낸 후에는 프로젝트 진행을 위한 관련 자료 수집/수집한 자료를

일목요연하게 데이터베이스화하는 작업(원시자료의 코드화)과 향후 작업의 결과 생성되는 결과물을

코드화할 작업이 시작되어야 한다. 모든 메뉴명과 매체별 파일명을 일관된 체제와 기호로 정의하는 것을

자료의 코드화라고 하는데 이런 코드화 작업을 각 과정별 담당자들이 일관되게 수행함으로써 제작 단계별

자료관리와 의사전달에 큰 도움을 줄 수 있다. 이러한 코드는 일정한 룰과 형식을 갖추고 만들어지며

팀원들이 이해하기 좋고 혼란을 주지 않는 약칭으로 표현되어야 한다. 다음은 표(3.1)와 표(3.2)는 각각

코드화 작업을 위한 데이터 코드 정의 예와 실제 코드화된 데이터 예이다.

-11-


플로우 차트 (FC : Flow Chart)플로우 차트(Flow Chart)란 웹사이트의 전체적인 뼈대를 제공하는 흐름도로 웹사이트에 접속하여 어떠한

과정을 거쳐 사이트를 네비게이션하게 되는 것인가를 한눈에 알 수 있게 로직으로 표현한다. 플로우차트는 스토리보드가 제작 과정상의 분업을 관리하고 효율적으로 진행하기 위한 작업 지침서이며

스토리보드의 핵심 대화내용이라고 할 수 있다. 그러므로 개발에 참여하는 모든 제작진은 기본으로

플로우차트를 이해하고 작성하는 법을 알고 있어야 하며 작성자는 정해진 표준에 따라 작성하여 누구라도

이해할 수 있도록 해야 한다

아래의 표(3.3)는 일반적인 기능성 플로우차트의 표현 요소들을 나타낸다.

-12-

표(3.1) 데이터 코드의 정의 예

표(3.2) 코드화 데이터 예


위의 예는 하이퍼텍스트 구조외에 다른 시나리오 구조를 사용하는 일반적인 멀티미디어 제작등에서 주로

사용하는 플로우차트의 요소 표현법이어서 하이퍼텍스트 구조가 대부분을 이루고 있는 웹사이트

제작시에는 다소 어려움이 있다. 따라서 보통은 그냥 프레임을 표시하는 기본 요소와 외부 프로그램 (페이지 단위가 아닌 플러그인 요소와 같이 동작하는 외부 프로그램의 경우/ Ex: 플래시 플러그인, 자바

애플릿, 별도의 외부 호출 프로그램등) 표시요소만을 분리하여 표시해도 무방하다. 다음 표(3.4)는

웹사이트 제작시 사용할 수 있는 플로우차트의 실제 예이다.

-13-

표(3.3) 일반적인 플로우차트 표현 요소

표(3.4) 웹사이트 제작 플로우차트 예


위의 예처럼 웹사이트 제작을 위한 플로우차트는 가능한 상세하게 도식화시켜야 하며 각 주제마다 다른

컬러화 하는등으로 구분이 가도록 하는 것이 좋다. 각 프레임(페이지)마다 각각의 통일된 Scene 번호를

주어 스토리보드와 매칭할 수 있도록 한다. 플로우차트는 프로그램의 기능구현요소를 충분히 반영, 프로그램 계획서를 대신 할 수도 있다. 즉 사용자의 동선을 나타내는 기획자용의 플로우 차트와

Architecture Flow을 나타내는 Engineer용(프로그램 계획서)의 플로우 차트 두 가지로 나누어 작성한다. 작성된 플로우 차트의 개수와 다음의 스토리 보드 장수는 일치할 것을 권장하며 컨텐츠맵을 사용하여

나타내도록 한다.

스토리보드 (Storyboard : SB)스토리보드는 웹사이트 개발의 설계도이며 구체적인 작업 지침서이다. 즉 웹사이트 설계 단계의 최종

목표를 달성하기 위한 내용을 컴퓨터 화면상에 맞도록 종이 위에 구성화한 형태로서 디자이너의 화면

계획서를 대신 한다. 스토리보드 작성시, 기획자는 스토리보드에 필요한 화면 구성 및 화면구성안 설명을 1차 준비한 후

디자이너와 회의를 통해 그래픽과 로직을 완성한다.스토리보드가 완성된다는 것은 기획단계가 완료되었음을 의미하며, 디자이너는 스토리보드에 명시된

내용을 가지고 화면 디자인부터 시작하여 각각의 일러스트 데이터를 그려 알파 리뷰를 준비한다. 프로그래머는 스토리보드를 보고 프로그램을 설계하고 각 세부 로직을 코딩하게 된다.따라서 스토리보드가 완성되면 사이트 개발 기획이 완성되었다고 말할 수 있으며 다음작업은 구체적인

제작만이 남게 된다. 잘못된 설계도를 가지고 작업하면 잘못된 개념의 집을 짓게 되어 기초가 무너지게

되는 것처럼 스토리보드는 정확하고 치밀하게 작성되어야 한다.* 컨텐츠 맵

Mainpage와 각 Subpage의 스토리보드를 작성하고 고정된 화면구성요소를 정한 뒤, 포함되는 컨텐츠는

논리적인 각각의 컨텐츠 구성요소, 즉 단위 정보들로 나누거나 묶어서 컨텐츠 맵을 작성한다. 컨텐츠의

양을 고려하여 컨텐츠 맵 번호를 정의한 후 이를 FC의 ID와 연결시킨다. 컨텐츠 맵 번호가 부여된 각각의

컨텐츠는 워드로 작성하여 Power Point상에서 수정할 요소를 최소화시킨다. 다음 표(3.5)는 일반적으로 사용할 수 있는 스토리보드의 구성예이다.

-14-


(1) 프로젝트 명:프로젝트 명을 기입한다.

(2) 페이지 주제:해당 화면의 내용, 용도를 이해하기 쉽게 기획자가 명기한다.

(3) 페이지 ID:이 화면의 코드명이다. 플로우차트상의 프레임 Scene 번호와 일치해야 한다.

(4) Page:Page번호는 스토리보드의 단순한 일련번호이다.

-15-

표(3.5) 표준 스토리보드 제작 양식


(5) 화면구성 (Page Elements):각 작업자가 화면의 내용과 구성을 시각적으로 이해하기 쉽도록 스케치로 표현한다. 메뉴 네비게이션의

구성과 위치, 아이콘, 텍스트, 필요한 이미지 등의 화면 구성요소를 가능한 정확히 묘사해야 불필요한

작업상의 손실을 막을 수 있다. 일반적으로 화면 구성요소는 다음의 항목을 포함한다.

Header : <title> <meta …> Body : 본문의 내용과 기능을 구현하기에 필요한 요소

- 헤드라인, 각 항목의 제목, 소제목

- 컨텐츠 : 주요 문장, 키워드, 완성된 텍스트 컨텐츠

- 그래픽 : 아이콘, 머리글표, 도표, 테이블

- 네비게이션 : 각 컨텐츠 군의 기능적, 내용적 분류에 따른 네비게이션 배열

- 웹마스터에게 메일 보내기? (mailto:) - 라디오버튼, 체크박스, Submit 버튼의 표시

Footer : (예모음) Copyright 1998-2000 홍익인터넷㈜ All rights reserved. © 1998-2000 홍익인터넷㈜

Copyright 1998-2000 Hongik Internet, Inc. All rights reserved. © 1998-2000 Hongik Internet, Inc.

(6) 화면설명 (Page Description):그림이나 플로우차트로 표현하기 어려운 화면 분위기 및 요구사항을 글로 설명하는 부분이다. 특별히

강조되는 기획의도를 디자이너와 프로그래머에게 각인 시킬 필요에서 명기하는 것이다. 애니메이션의

순서나 화면이 뜨는 순서, 특성 화면 부분에 대해 설명한다.

(7-8) F/C 와 Logic: 화면내에 이루어지는 인터랙션을 표시하며, 화면의 시작에서 다음화면으로 연결되는 흐름을 로직적으로

정확하게 표현한다. 사용자가 요구하는 의도에 따라 제시되는 화면의 순서나 화면을 움직이는 조직, 연결되는 프레임을 명확히 기록한다.

(9) Text: 화면 나타나는 텍스트 내용을 적는 곳이다. 그래픽으로 처리된 제목이나 글씨는 제외하고 텍스트로 편집

가능한 데이터는 모두 적는다. 이 란에 다 들어갈 수 없으면 별도의 용지를 첨부한다. 텍스트는 짧고

간결하여 가독성이 높도록, 건조하지 않은 단어나 문장으로 적는다.

(10) Graphic/Video: 그래픽 요소는 실제로 작업에 들어가는 그래픽 데이터를 표현하는 곳이다. 지정된 기업의 로고, 캐릭터

-16-


등이 있다면 반드시 명시하고 기타 강조할 만한 그래픽요소와 비디오 요소가 들어간다면 이의 자세한

설명을 덧붙인다.

(11) Effect:자바스크립트등의 특정 화면 이벤트를 기록한다.

(12) Music/Sound:페이지에서 사용될 음악, 효과음, 나레이션 등을 상세하게 기록한다.

프로그램 아키텍쳐, 모듈 설계서

해당 프로젝트에 구현되는 아키텍쳐와 모듈에 대한 설계서.

가.3 제작단계

AlphaAlpha단계의 작업에는 기획단계에서 정의된 제작 계획을 보다 상세히 하고 고객에게 향후 진행될 작업의

초안작업을 수행한다. 이 Alpha단계의 작업물에 의해 고객과 제작인원은 전체 프로젝트의 향후

진행방향과 작업물의 스타일을 가늠할 수 있게 된다. 보통의 디자인 작업의 경우 Alpha Review시

방향성의 결정을 위해 몇 가지 안을 준비하게 된다. 작업의 범주는 FC를 기준으로 하여 한 Flow를

시연하는 것으로 하며 HTML 작업이 완성 될 것을 권장한다. 프로그램의 경우 설계안을 제시한다.

Review 준비 사항

1) View Room : Alpha 단계에서 시안 등을 FTP를 이용하여 별도로 보여주는 곳

2) Project용 사내 게시판 : 개발작업과정에서 팀원간의 커뮤니케이션을 위한 것 (내부용) 3) Client용 게시판 : 클라이언트가 제공하는 자료 및 홍익의 산출물 공유

4) 메일링 리스트 : 공지사항 등 커뮤니케이션을 위해 홍익이 제공

Alpha Review진행된 Alpha 작업물을 고객과 시연하고 검증하는 단계로 다음단계(Beta)의 작업은 Alpha Review에

의한 고객의 Confirm이 이루어져야 진행할 수 있게 된다. Alpha Review는 온라인으로 해당 프로젝트

Team과 QM간 약식으로 이루어 진 후 고객과의 리뷰를 가지는 것을 원칙으로 한다. QM과의 리뷰에선

-17-

Alpha단계 Beta 단계 Gold 단계

상세 제작 계획

Alpha Review(원시) 자료 가공

Alpha 작업 진행 Beta 작업 진행 Beta Review

Gold 작업 진행

Gold Review Site Launch

Quality Assurance


Alpha 까지의 작업량 확인에 그 초점을 맞춘다.

Beta앞서서 Alpha작업에 의해 결정된 작업물의 방향성을 기초로 본 작업에 들어가는 단계로 실제 제작 작업의

대부분은 이 단계에서 이루어지게 된다.

Beta ReviewBeta기간동안 제작된 작업물을 고객과 함께 시연하고 검증하는 단계로 이 단계에서는 실제 프로젝트에

있어 정의되어 있는 대부분의 작업을 완성한 후 그 작업물들을 고객에게 검증받는 단계라고 볼 수 있다.

GoldGold단계에서는 프로젝트 기간 동안 수행한 대부분의 작업을 마무리하는 단계에 해당하며 이 단계에는

최종 Gold Review와 Quality Assuarance 그리고 사이트 런치와 같은 작업들이 포함된다.

Gold Review해당 프로젝트의 100% 완성. 일반 공개용인 지정된 URL에 컨텐츠, 디자인, 프로그램이 100% 완성된

것을 해당 프로젝트 TF와 클라이언트에게 확인하는 단계로, 일반에게 공개되어도 아무런 지장 없을 정도의

완성도를 가져야 한다.

Quality Assurance (QA)해당 프로젝트에 대한 Quality 검증 단계. 다음의 영역에 맞추어 QA 테스트를 QA Group 또는 해당

프로젝트의 구성원이 담당한다. 각 QA에 대해선 QA Report를 PM과 QM에게 동시 보고, QA 리포트 제출

시 2일 이내로 모든 수정 사항을 완료한다. 적어도 2주간 정기적인 일정으로 QA 가 이루어 지길 권장한다.- 브라우져 (IE 4.0, IE 5.0, Netscape 4.x 버전)- 모니터 화면 resolution에 따른 사이트 뷰

- 각 홈페이지의 title 과 적절한 메타 태그 부여 여부

- 오탈자

- 깨진 링크, 이미지, Alt 삽입 여부

- 파일 용량에 따른 Connectivity Test - Java Script, Java Applet 의 정상적인 동작

- 회원등록, Login, 게시판 글쓰기, 지우기, 편집하기, 파일 업로드, 다운로드 기능들의 정상적인

구현

-18-


가.4 유지/관리단계

CSSS (Customer Satisfaction Survey Sheet)프로젝트의 완료후 고객이 해당 프로젝트와 그 결과물에대해 얼마나 만족하는가를 조사하는 문서. QM Group이 고객에게 발송, 접수 받는다. 사이트 런치 후 2주 이내로 접수 받는다.

4. 용어의 정의

PRE (Project Review & Evaluation)평가와 사후 점검을 위해 완료된 프로젝트를 사내 임의의 인원들과 함께 시연 및 검토하는 회의

IMP (Idea Meeting for Production)제작 아이디어 회의, 프로젝트의 질높은 수행을 위해 아이디어를 내는 프로젝트 관계자 회의, 주로

BS(Brain Storming)같은 방법에 의해 진행된다.

RFP (Request for Project) 구축 문의, 고객의 구축관련 문의 행위자체를 지칭하는 용어로 RFP는 웹사이트, 인터넷 기반 애플리케이션

제작등과같이 디자이너나 프로그래머 같은 전문 인력의 투입에 의해 이루어지는 구축 행위에 관련된 고객

문의 전반을 가리킨다.

RRPB (Request Report for Project Beginning)프로젝트 개발작업 시작 단계에서 클라이언트 정보, 프로젝트와 관련된 개발일정, 개발내용, 개발환경과

각 부서의 담당인원을 보고하는 양식

Interview고객 면담

Consulting비즈니스 전략 상담

-19-

관리단계

운영자 교육

사이트 홍보 수행

유지 및 갱신

CSSS


DROPProject 거절, 고객이 문의한 프로젝트 의뢰 건을 프로젝트 진행 조건이나 제반 사항 등의 이유로

미수주하는 행위

PP (Project Profiler)프로젝트 체크리스트, 프로젝트 수주이전 해당 프로젝트의 관련한 제반사항과 고객의 회사제반 사항등을

묻는 문답 문서 형식

PT & QNA (Presentation & Question and Answer)특정 연구물이나 제안 내용 등을 관계자에게 발표하고 관련 문답시간을 갖는 행위

IMP (Idea Meeting for Production)제작 아이디어 회의, 프로젝트의 질높은 수행을 위해 아이디어를 내는 프로젝트 관계자 회의, 주로


수주

프로젝트가 수주된 경우

FAIL특정 이유로 프로젝트 수주에 실패한 경우

견적서

수주이전의 가격 제안서로 프로젝트 견적서, 즉 프로젝트 계약 전 고객이 미리 대략의 프로젝트 진행

비용을 가늠할 수 있도록 하는 목적으로 발송된다.

계약서

수주이후 비용 청구서로 계약 시점이나 이후 정확한 프로젝트 비용을 산정하여 발송하는 것을 지칭한다.

Alpha웹사이트 제작 초기 단계나 그 결과물을 가리킨다. Alpha는 제작자와 고객이 함께 향후 진행될 작업의

진행방향을 가늠할 수 있도록 하는데 그 주목적이 있으며 제작된 Alpha 결과물에 따라 차후 본작업이

시작된다고 볼 수 있다.

Alpha Review Alpha 시연 (1차 시연), Alpha 작업 기간동안 진행한 결과물을 고객에게 시연, 검증하고 차후 개발/구축

방향을 논의하게 된다.

-20-


Beta웹사이트 제작 본 단계(제작 100%)나 그 작업물을 가리킨다.

Beta Review Beta 시연(2차 시연), Beta작업에 의해 진행된 작업물을 시연하고 작업 마무리 단계의 방향을 협의한다.

QA(Quality Assurance)웹사이트 검증

Gold웹사이트 제작 완료 단계로 최종 마무리 단계에 해당한다.

Gold ReviewGold 시연(최종 시연), 프로젝트 전체에 걸쳐 진행된 최종 작업물을 시연/검증하고 향후 서비스 개시를

위한 사전 논의를 수행한다.

Launch제작한 웹사이트의 서비스 개시

CSSS (Customer Satisfaction Survey Sheet)프로젝트의 완료 후 고객이 해당 프로젝트와 그 결과물에 대해 얼마나 만족하는가를 조사하는 문서

PSS (Project Schedule Sheet)프로젝트 일정 계획서

PRE (Project Review & Evaluation)평가와 사후 점검을 위해 완료된 프로젝트를 사내 임의의 인원들과 함께 시연 및 검토하는 회의

DPI (Delayed the Project by In-house)사내 내부적 문제로 인한 프로젝트 일정의 연기

DPC (Delayed the Project by Client)고객의 사정에 의해 프로젝트 프로젝트의 일정 연기

TF (Task Force)

-21-


특정 프로젝트를 진행하기위해 구성된 프로젝트 참여 인력, 보통의 경우 PM, Planner, Designer, Programmer등이 한 팀을 이루게 된다.

Analying Asignment과제분석, 고객의 요구를 파악하고 프로젝트 진행을 위한 기초 환경을 파악하는 등의 프로젝트의 본격

진행을 위해 사전에 주어진 프로젝트 과제 전반을 파악하고 이해하는 작업

IMP (Idea Meeting for Production)제작 아이디어 회의, 프로젝트의 질 높은 수행을 위해 아이디어를 내는 프로젝트 관계자 회의, 주로


CPM (Change Project Manager)PM 변경 요구

DCR (Draft Change Request / Design Change Request)

SSCR (Site Structure Change Request)사이트 구조 변경 요구

QCR (Quotation Change Request)견적 변경 요구

4.3 Job Description

PM (Project Manager) - 해당 프로젝트의 총 책임자. 목표와 기획에 따라 예산, 자원을 조절하여 프로젝트가 정상적으로

진행 하도록 담당한다. - 프로젝트 과정 및 결과에 책임을 진다.- 프로젝트 수행시 Creative를 담당한다.- 고객과의 커뮤니케이션 및 해당 프로젝트 팀원간의 커뮤니케이션의 조정을 이끈다.

DSN (Designer) : 해당 프로젝트의 그래픽, 유저인터페이스, 정보구조배열, Creative를 담당한다. : 구현된 그래픽이 HTML로 표현되는 웹 출판 부분도 담당한다. : 모든 개발과 관련된 내부 회의에 참석해야 한다.

-22-


PRG (Programmer): 해당 프로젝트의 네트워크, 보안, 프로그램의 설계 및 구현을 담당한다.: 구현된 프로그램이 HTML로 표현되는 웹 출판 부분도 담당한다. : 모든 개발과 관련된 내부 회의에 참석해야 한다.

PL (Planner): Creative 있는 컨텐츠 취합, 작성, 가공, 레이블링, 정보구조배열을 담당한다.: 해당 프로젝트의 컨텐츠 작성 및 발생되는 문서 관리 작업을 담당한다. : 모든 개발과 관련된 내부 회의에 참석해야 한다.

5. 업무 진행을 위한 표준화 문서

가. 표준화지침서 (PPSG)본 문서를 가리키며 프로젝트 진행의 표준화 지침 및 표준화 문서를 담고 있다.

나. RRPB (Request Report for Project Beginning)프로젝트 개발작업 시작 단계에서 클라이언트 정보, 프로젝트와 관련된 개발일정, 개발내용, 개발환경과

각 부서의 담당인원을 보고하는 양식. 수주 이전 단계에서는 e-Brain에서 담당하며, 수주 후 프로젝트 팀이

결성된 이후에는 PM이 작성, 관리하며 QM에게 보고한다. 각 단계에서 Update를 통해 내용을 수정, 보완하도록 한다.

-23-


프로젝트 명

발주업체 내용

담당자(이름/부서)연락처(E-mail/Phone/Mobile/Fax /URL /Address)

담당인원 조직

e-Brain(영업자) CDM팀 e-Solution팀 e-Consulting팀정:

부:

정:

부:

정:

부:

정:

부:

개발일정(계획)

전체 개발일정 기획 일정 디자인 일정 프로그래밍 일정 기타

Alpha :

Beta :

Gold :

Alpha : Alpha :

Beta :

Alpha :

Beta :

Gold

QA (Test) :

개발내용

(프로그램 개발내역은 모듈별로 상세하게 기록요)

- Information Architecture

- Graphic Design

- Programming

개발요구 환경

H/W OS Application DB Etc.

기타사항

-24-


다. 기획서

기획서는 스토리보드, 플로우 차트, 코드화 규칙, 일정서를 포함하며, 다음의 내용도 별도로 명시한다.

1) 프로젝트명

2) 프로젝트 설명

3) 해당 프로젝트의 목표

4) 프로젝트 진행 기간 (예상기간)5) 고객 정보 : 성명, 부서, 이메일, 사무실 전화, 이동전화, 우편주소, 사무실 주소, 본 프로젝트에서

역할,6) 프로젝트팀 구성원 : 이름, 이메일, 역할

7) 페이지 스타일 가이드 및 환경 정보: i. 기본사용 폰트

ii. 기본사용 색상

iii. 표준 화면 해상도

iv. 준수해야 하는 스타일 가이드 양식 (예 : 프레임 사용 금지, Popup 창 사용 금지, 양쪽

반드시 10 pixel의 여백 줄 것 등)v. CSS 규칙

vi. 필요한 Meta Tag 내용

vii. 대상 웹 브라우져 / OS viii. OS (예 : NT, Unix)ix. 서버(예 : Netscape, IIS, Linux)x. 특정 사용 언어 (예 : Java, PHP, ASP)xi. 기타 특이 사항 (예 : 암호화, 지불 솔루션 채택 등 외부 애플리케이션 적용 여부)

라. 스토리보드

스토리보드는 크게 기본형과 축약형, 컨텐츠맵이 있다. 프로젝트의 내용과 기능에 따라 해당 프로젝트

제작진이 취사선택하여 사용한다. 스토리보드의 각각의 구성요소는 필요에 따라 첨삭이 가능하나, 기본틀은 유지하도록 한다. 즉, 페이지 구성요소와 페이지 설명, 텍스트와 그래픽 란은 변경하지 않는다. 아래 예의 스토리보드 작성으로 마이크로소프트 오피스의 파워포인트를 이용하였다.

라1. 기본형

[작성법은 가2.의 스토리보드 참조]

* 예 1 1) Contents 군에 대한 내용성, 기능성 반영

2) 필요한 페이지 요소들을 모두 표현. 추후 디자인의 완성도 높일 수 있다.

-25-


3) 구체적이고 간결한 화면 설명으로 구현될 그래픽 및 기능에 대한 예를 준다.4) 해당 F/C의 삽입으로 어떤 로직에 의해 페이지 구현 되는 지 알기쉽게 설명한다.

-26-


예 2 :1) 화면상 부족한 컨텐츠는 별첨으로 첨부. 디자인을 하기 위해 필요한 공간을 가늠할 수 있도록

한다. 2) 화면상 부족한 컨텐츠군도 별첨으로 첨부하여 내용 표기한다. 개발 과정시 수정되지 않을 확정된

메뉴명을 사용한다.3) 페이지 구성 요소 중 반드시 사용될 그래픽 요소를 별도로 지정하였다.

-27-


예 3.- Page No.101에 대한 별첨 화면. No.101에 텍스트와 확정된 메뉴군의 리스트도 구체적으로 명히

하였다. - 반드시 별첨임을 표시하여 주며 관련 번호를 부여한다. (Page No. 101_1)

-28-


예 4 :한 페이지가 F/C 의 여러 영역을 포함하거나 페이지를 이해하기 위해 해당 Flow가 연속적으로 필요한

경우는 스토리 부분의 한 영역만 확장하여 사용한다.

-29-


라2. 축약형텍스트 및 디자인 구성이 많은 웹사이트의 스토리보드로 적용한다.

예 1 : 정보전달이 주목적인 홈페이지의 예. 가독성 있는 배열과 직관적인 정보 전달을 위해 완성된 텍스트를 삽입

하였다. 구체적인 텍스트 삽입을 위해 불필요한 스토리보드의 기능 및 요소란은 삭제 하였다.

-30-


예 2 :프로젝트 팀과의 회의를 통해 직접 손으로 스토리보드를 작성하였다. 회의시 순간 순간 발생하는 아이디어

등을 기록하기 좋다.

-31-


예 3 : 도식이 필요한 부분은 그림으로 표시하였다. 이는 페이지 구성을 효과적으로 표현하기 위함이지 반드시

그래픽으로 동일 양식으로 표현될 필요는 없다.

-32-


예 4 :- 해당 화면이 전체 웹사이트에서 어떤 부분에 해당하는 지 알 수 없다.- 각 웹사이트 기능의 플로우와 연계성이 없다. - 페이지 구성요소가 분명하지 않다.

-33-


라3. 컨텐츠맵페이지 구성요소가 정해져 있는 경우 컨텐츠만을 FC ID, Contents Map 번호와 함께 입력한다. * Contents_Map.ppt를 인트라넷에서 다운로드받아 사용한다.

-34-


마. 플로우차트

다음예의 플로우차트는 마이크로소프트 오피스의 파워포인트를 사용하였다.

예 1 : - 웹사이트의 플로우를 효과적으로 표시하기 위해, 이전에 정의한 기호들을 적절히 사용하여

구현한다. - 플로우가 A4 용지를 넘더라도 규격 용지 (A4, A3)등에서 내용이 출력될 수 있도록 여러 용지 및

화면을 활용하여 플로우 차트를 그린다.- (다음 페이지 참조)

-35-


-36-


예 2 :- 체계적으로 플로우차트가 작성 되었다. -

-37-


예 3 :- 각 기능별로 플로우차트가 구현되어 있어, 전체적인 플로우를 이해하기 어렵다. - 해당 기능이 속한 플로우를 파악하기 어렵다.- 통상적인 플로우차트의 예가 아닌 임의의 기호와 색상 구현으로 플로우 파악이 쉽지 않다.

-38-


바. 코드화규칙

1. 자료 수집 및 코드화 (GPD : Gathering Project Data)

대략적인 프로젝트 구성 내용물들을 도출한 후 프로젝트 진행을 위한 관련 자료 수집/수집한 자료를

일목요연하게 데이터베이스화 하는 작업과 향후 작업의 결과 생성되는 결과물을 코드화할 작업이

시작되어야 한다. 모든 메뉴명과 파일명을 일관된 체제와 기호로 정의하는 것을 자료의 코드화라고

하는데, 이런 코드화 작업을 각 과정별 담당자들이 정보를 체계화함으로써 제작 단계별 자료 관리와

의사 전달에 큰 도움을 줄 수 있다.

이러한 코드는 일정한 룰과 형식을 갖추고 만들어지며, Cell 구성원들이 이해하기 좋고 혼란을 주지 않는

약칭으로 표현되어야 한다.

데이터 코드화 문서는 스토리보드, 플로우차트와 상관 관계가 있다. 정리가 잘된 자료들이 있어야 프로젝트가 완벽해질 수 있는 요건이 되고, 데이터 코드화 문서는 이러한

것들 중의 중요 요소 중 하나이다.

데이터 코드화는 프로젝트 Alpha 단계가 진행되기 전에 모두 마무리 되는 것을 원칙으로 하고, 상황에

따라 Low Data가 Update가 될 경우는 Modify Update가 아닌 Date Update로 문서를 따로 생성해서

그 History를 남긴다.

클라이언트 쪽에서 미리 원시자료에 대한 코드가 있다면, 그 원칙을 따라야 클라이언트와의

커뮤니케이션이 자유롭게 이루어질 수 있고, 스토리보드나 플로우차트를 준비하면서 챙겨야 될 문서

등을 만들어진 코드화 문서를 클라이언트 쪽에 제시함으로써 명확한 원시 자료를 취득할 수 있고, 해야

한다.

2. 레이블링(Labeling)

레이블링은 표현의 한 형식이다. 레이블링의 가장 큰 목적은 “정보를 효율적으로 전달” 하는 수단이고, 프로젝트 진행시 커뮤니케이션의 한 방법이기도 하다. 따라서, 직관적인 레이블링이 바람직하다.이러한 레이블링 방식은 웹사이트 제작 시 생성되는 모든 자료 뿐만 아니라, 웹사이트 자체도 적용이

된다.

3. 데이터 코드화 문서의 필수 요소

-39-


데이터 코드화 문서에 포함되는 요소는 프로젝트가 진행되면서 클라이언트 측에서 제공되는 모든

자료를 포함해야 한다. 홍익에서 가공되는 모든 자료는 코드화 되어야 한다.

4. 데이터 코드화 문서 예제

데이터 코드화 문서는 프로젝트 업무 프로세스에 관련해서 만들어진 템플릿 문서는 없다.다만, 몇 개의 샘플로 설명을 대신한다.

-40-

표1. 데이터 코드의 정의 예

표2. 코드화 데이터 예

데이터 코드 정의 문서

작성일 코드 정의 작성자문서 코드

문서 코드 코드 / 번호 제목 디렉토리 비고

데이터 코드 문서


[표1]은 데이터 코드화 문서를 만들기 위한 전체 코드에 대한 설명이다.[표2]는 [표1]에서 정의한 분류를 통해서 만든 데이터 코드 문서이다.

데이터 코드는 해당 프로젝트에 따라서 구분이 될 수 있고, 클라이언트의 데이터에 대한 코드가

존재한다면, 그것을 기준으로 Low Data부터 홍익에서 생성하는 문서 등에 적용을 한다. 실제로 E-Commerce 사이트를 만드는데 있어서, 데이터는 엄청나게 많을 수 있을 것이다.

[표3] 양식은 ㈜하나로 통신 WSG의 자료 수집 목록이다. 작업자가 작업을 원활하게 하기 위해서 만든

문서이고, 분류는 Title, Filename, Directory, Update, Print, Notes 등으로 나누었다. 그러나, ㈜하나로

통신에서 제공한 문서와 자체 가공된 혹은 수집된 자료가 명시되어 있지만, 코드화 되어 있지 않다. 이미

만들어진 문서를 수정하는 것보다는 처음부터 정리하고 정의를 해 가는 것이 프로젝트 진행이 수월할

것이다.

-41-

표3. 하나로 WSG 자료 수집 목록


[표4]는 원시자료의 코드화가 끝난 후 작업의 결과 생성되는 결과물에 대한 코드화 예제이다. 결과물의

디렉토리 구조와 파일명을 일관된 체계와 기호로 정리한다.

마지막으로 데이터 코드화에 대해 정의 하자면,i. 프로젝트 진행시 모든 자료를 코드화 해서 관리를 한다.ii. 코드화 작업에는 원시자료 코드화와 최종 결과물에 대한 코드화의 두 가지로 분류한다. iii. 데이터 코드화에 따른 문서는 데이터 코드에 대한 정의 부분과 코드에 의한 리스트가 있다.iv. 데이터 코드화 문서는 스토리 보드, 플로우 차트와 연관성을 가진다.

-42-

표4. Joyhill 결과물 코드화 자료


사. 프로그램 아키텍처 & 모듈 설계서 (e-Solution 추가 요망)

-43-


아. 일정서

일정 계획에는 크게 작업 스케줄과 인력체제의 편성, 그리고 개발비등의 비용관리 계획 등을 포함시킬 수

있다. 이 일정 계획 요소 중 작업 스케줄의 작성과 자원관리(인력 체제의 편성)은 필수적으로 계획되어야

하는 요소이다.

일정과 자원계획의 효율화와 표준화를 위하여 전문적인 프로젝트 관리도구인 『Microsoft Project』을

이용한 일정 계획, 자원계획을 수립 할 것을 권장한다.

-44-


자. 백서

프로젝트 종료 후에는 다음의 내용을 포함하는 백서를 작성한다. * Project_Report.xls를 인트라넷에서 다운받아 사용

작성자, 작성일, 작성자 연락처 (이메일 또는 전화)[내부 목차]

1. 프로젝트명

2. Client 정보

- 회사명/URL- 담당자 부서/성명/직책- e-mail/Tel/Fax/Mobile/Address- 담당자 역할

(* 담당자는 의사결정자를 포함 본 프로젝트 진행 전반에 걸쳐 단 한 번이라도 커뮤니케이션

했던 고객들을 전부 기록한다.)3. 계약 기간

4. 수주 금액

5. 선금 입금일

6. 잔금 입금일

7. Project TeamPM :Planner:Designer :Programmer :(* 복수의 인원이 참석하였을 경우도 기입, 개발과정에서 맡았던 업무에 대해 상세히

기술한다.)8. 개발 일정

- Kick Off Meeting 날짜 :- Alpha 날짜 :- Beta 날짜 :- Gold 날짜 :- Launch 날짜 :

9. 프로젝트의 목적

(* 프로젝트 Kickoff 시 확정된 목적을 적는다.)10. 본 프로젝트의 대상

(* 해당 웹사이트의 컨텐츠나 서비스의 대상을 명시한다.)11. 프로젝트 개발 범위

-45-


(* 프로젝트의 개발 범위로 개발된 웹사이트의 메뉴명과 간략한 설명을 적는다.)12. 프로젝트 개발 산출물 : PPSG에 정의한 문서들 (O, X로 표시) : 기획서 ( ) RRPB ( ) F/C ( ) S/B ( ) GDP ( ) 서비스 URL : HTML (개수) Graphic (개수)

- Main Image- Button- Symbol- Animation- 동영상

Programming - Script- Module 단위에 따른 분류

개발에 쓰인 Tool/ Solution (*Graphic과 Program 에 쓰인 Tool과 Solution을 기술한다.)

13. Server 환경

- OS- Web Server- DB- 암호화, 보안/인증

14. 프로젝트 완료 후 평가

- 언론보도 (스크랩)- 방문자수/페이지 열람수

15. 총평

- 개발 시 유의사항

- 본 프로젝트를 통해 배운 점

- 개발자 후기 (* 각 기획, 디자인, 프로그래밍에 참여했던 팀의 후기를 적는다.)

-46-

(주)홍익인터넷서울특별시 중구 소공동 51번지 해운센터 빌딩 신관 16~17층

TEL : 02-753-2553 FAX : 02-753-1302http://www.hongik.com/


차. CSSS

Hongik Internet, Inc. Client Survey Sheet안녕하십니까? (주)홍익인터넷 입니다. 웹 사이트 및 웹 서비스에 대한 고객의 의견을 수렴하여 보다 나은 웹사이트 및 서비스를 제공하기 위한 고객 만족

조사입니다. 해당 내용을 빈 곳 없이 기재하여 주시기 바랍니다. 보내주신 의견은 추후 홍익과 재작업을 하실 때에

최대한 반영할 것을 약속드립니다.Company

To be filled by Hongik Internet.

Inc.

Name

Email

Phone

URL

Your Project Manager at Hongik Internet. Inc. : Communication

이해도 : Project Manager는 고객의 요구를 잘 이해하였습니까? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

친절도 : 전화, 메일 혹은 직접 면담 시 친절하게 상담해드렸습니까? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

신속성 : 고객의 요청에 대하여 신속하게 응답해드렸습니까? (제작 작업 제외) -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

웹사이트 제작

Design Quality : 제작된 웹사이트의 디자인에 만족하십니까 ? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

-47-

고객 만족 조사


Programming : 프로그래밍 부분에 만족하십니까 ? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Editorial Contents Quality : 작성된 내용에 대해서 만족하십니까 ? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

작업 완벽도 : 진행된 작업에 대한 완벽도는 만족하십니까 ? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

Creativity : 창의적인 작업에 대한 결과에 만족하십니까 ? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

웹사이트 기획

제작하는 웹사이트에 대하여 컨설팅한 부분은 적절했다고 생각하십니까 ? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

웹사이트 제작에 대한 일정관리는 잘 되었습니까 ? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

웹사이트 가격

웹사이트의 결과와 제작비용은 적절하다고 생각하십니까 ? -------( )① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.Comment :

차후에도 홍익과 함께 작업을 하실 용의가 있으십니까?① 그렇다. ② 별로였다. ③ 약간 부족했다. ④ 아주 부족했다. ⑤ 전혀 안되었다.혹시 원치 않으신다면 그 이유는 무엇입니까?

㈜홍익인터넷 고객 만족 조사에 응해주셔서 감사합니다. 응해주신 내용을 적극적으로 반영하여 보다 나은

웹사이트와 웹서비스 제공을 위해 최선을 다하겠습니다.㈜홍익인터넷 대표 노상범 드림

-48-


타. QA Report

QA 리포트는 각 프로젝트의 Gold 이후 QA Tester가 작성하며, 다음의 형식을 갖는다.

- 프로젝트명과 담당 PM 을 문서 상단에 적는다.

- 작성자는 QA Tester로서 성명, 전화, 이메일을 적는다. QA Report 완료 후 해당 Report를 PM과

QM에게 제출한다.

- 작성일은 테스트 후 QA Report 작성일로서, 해당 QA Report에 대해 수정여부가 완료 되었거나

할 경우, 이미 제출된 QA Report를 다시 작성 후 날짜도 수정 완료 된 날짜로 바꾸어 문서 자체를

업데이트 한다.

- 브라우져 버전은 각 해당 사이트의 특성에 따라 정하나, Internet Explore와 Netscape 간의

테스트는 반드시 수행되어야 한다.

- 위험 : 각 버그가 현 웹사이트 운영에 치명적인 오류를 발생시키는 정도를 표시

H : High – 서비스가 정상적으로 운영 되지 않을 정도의 높은 위험도

(예 : 404, 505, “서버를 찾을 수 없습니다.” “Assess denied” 등의 서버 출력 에러 메시지 및

깨진 링크, 한 페이지당 로딩 속도 10초 이상일 경우)

-49-

QA Report프로젝트명 : PM :

작성자 : XXX (전화, 이메일) 작성일 : yyyy/mm/dd브라우져 : NS 4.51

위험 URL 설명 수정여부 담당자H www.hongik.com/

test.htm404 not found Done PRG 똑똑

M www.hongik.com/gif.img 화면 좌측 상단 첫번째 메뉴의 “검색” 아이콘 이미지가 깨져서 보임

- DSN 만세

L www.hongik.com/2.htm 첫번째 줄 “맞춤 법” 띄어쓰기 틀림.

Done PL 야호

첨부 : Loading 속도 측정표 (56K, 256K, 512K)

http://www.hongik.com/gif.img


M : Medium – 서비스 운영에는 영향을 미치지 않으나 시각적으로 서비스 완성도를

저하시키는 경우

(예 : 텍스트나 이미지 파일의 링크가 잘못 되었을 경우, Title 태그가 잘못 되어 있는 경우, 글씨가 틀린 경우) L : Low – 서비스운영에는 영향을 미치지 않으나 곧 쉽게 수정 가능한 경우

(예 : 맞춤법)

- URL : 버그가 발생한 URL - 설명 : 감정이 삽입되지 않은 단어로 구체적으로 명시한다. 특히, 버그가 발생할 경우, 버그가

발생한 경우까지 접속 경로를 구체적으로 명시하여 제작진 중 각 담당자가 문제 해결을 신속히 할

수 있도록 한다. (좋은 예 : 회원 로그인을 하라는 메시지를 출력 받은 후 회원 로그인이 되어 있지 않아 회원

가입을 하 였다. 회원 가입 한 후 다시 로그인 하였으나 회원자격으로서 게시판의 글쓰기가 되지

않는다.) (나쁜 예 : 게시판에 글쓰기가 정말 안 되요!!!)

- 수정여부는 제작진의 각 담당자들에게 수정을 확인 받은 후 PM이 취합하여 Done 표시를 한다. 수정여부가 기재된 QA Report를 받은 Tester는 수정 사항들이 반영되었는지 다시 테스트한다. Launch 전 해당 프로젝트에서 모든 버그는 반드시 수정되어야 한다.

-50-


파. Data CD Format

1. 개요

프로젝트를 마무리 짓기 위한 마지막 작업으로 해당 프로젝트를 수행하던 기간 동안 제작되었던 각종

문서와 HTML 그리고 웹 프로그램, 혹은 클라이언트로부터 수집된 Low Data 등을 디지털화 해서 CD로

보관을 한다.

Project Final Data CD를 제작하는 이유는 ㈜홍익인터넷의 데이터베이스화, History 차후 진행되는

업무에 도움을 주기 위함이다.

Project Final Data CD는 3 Copy를 만들어야 한다.

Backup CD는 ㈜홍익인터넷 경영지원실이나 Backup CD 담당자를 통해서 받는다.

Project Final Data CD는 프로젝트가 마무리 되고, 고객에게 발송되는 CSSS(Customer Satisfaction Survey Sheet)을 보낼 때 같이 발송을 하고, 고객에게 따로 발송할 CD를 따로 제작해도 상관이 없지만, 필수적으로 포함 되어야 할 요소는 사이트 Launching에 필요한 HTML, IMAGES, PROGRAM 이다.

프로젝트 진행 시 미리 구조를 잡아서 작업을 하면, Project Final Data CD 작업하는 데, 불편함이 없다. 뿐만 아니라 구조화된 디렉토리를 사용함에 따라 어려 사람이 작업하는데 있어서 도움이 된다.

-51-


2. Project Final Data CD 디렉토리 구조

I. 디렉토리명은 가급적 영문으로 표기한다.괄호[ ]로 표시된 것은 디렉토리를 의미한다.

II. 1_DOC : 프로젝트과정에서 산출되는 문서들을 정리하며 가급적 영문으로 파일이름을

작성하도록 한다.

III. 2_DSN : 사이트 디자인 시 생성되는 PSD, JPG, GIF 파일이나 FLA, SWF 파일 등을 Alpha, Beta로 나누어서 디렉토리별로 정리 보관한다.

IV. 3_Web Site : Site of Compress – Beta : Beta 가 끝나는 시점에서 압축해서 보관 (HTML Coding이

끝난 후 프로그램 기능은 되지 않는 상태) Site of Compress – Gold : Gold 가 끝나는 시점에서 압축해서 보관

-52-

\ Project Final Data CD│├ [ 1_DOC ]│ ├ [From Client]│ └ [From Hongik]│├ [ 2_DSN (PSD, Media Original File) ]│ ├ [ Alpha]│ └ [ Beta]│ └ [ 3_Web Site ] └ [ Site of Compress - Beta, Gold]


3. CD Label 표준 안

* 위의 예는 실제로 출력하여 사용할 수 있는 크기임.

I. CD Case 의 정면부 하단에 CD 에 담겨질 내용을 위와 같은 형식으로 기록한다.II. 레이블에 대한 설명

- Project : 프로젝트명과 URL기입

- Client : 프로젝트를 발주한 발주처(회사명) - PM : 프로젝트를 수행한 PM

- Term : 프로젝트 수행 기간

- Burn Date : CD 를 제작한 날짜

- Vol. : 하나의 CD 로 제작이 가능할 때도 있으나, 여러장의 CD 가 만들어질 경우 Vol. 번 호로 몇장의 CD 가 있는지 알수 있다.

ex ) Vol.1 : 1 장의 CD , Vol.1/3 : 3 장의 CD 중 첫번째 측면은 CD ID, Project, Vol. 를 기입한다.

-53-

Project / Vol.

■ Project명 : ■ Client : ■ PM :■ Term : ■ Burn Date : ■ Vol. :


I. 대부분의 CD 에는 간단하게 설명을 기입할 수 있는 공란이 있다.II. Project, PM, Burn Date, Vol. 을 기입해서 어떤 내용이 있는 지 알 수 있게 한다.

하. TYL(Thank You Letter)계약 완료 또는 프로젝트 완료 후 고객에게 발송

-54-

■ Project :■ PM :■ Burn Date :■ Vol. :


감사의 말씀

안녕하십니까? 고객 여러분!저희 홍익인터넷을 선택해주셔서 감사합니다.

급변하는 Business환경 속에서 그 어느 때보다 빠른 대응이 필요한 e-business의 전문가 집단이라고

자신하는 저희 홍익인터넷은 고객 여러분의 성공과 비즈니스 도약을 위해 최선을 다하리라고 약속

드리겠습니다. 모쪼록 저희와 함께 하여 주신 점 깊이 감사드리며, 앞으로도 저희와 함께 e-business의

최강자로서 사업을 영위하실 수 있게 되시기를 기원합니다.

저희 홍익인터넷은 프로젝트의 보다 원활한 진행과 문제해결을 위해서 QA (Quality Assurance) 조직을 운영하고 있습니다. 작업 진행시 발생 할 수도 있는, 미처 예측하지 못했던 문의사항과 문제점들을

고객의 입장에서 겸허히 수용하고 처리하여 귀사에 최대한의 성과와 만족을 드리고자 합니다. 프로젝트

완료이후에도 언제 어디서나 고객의 의견을 경청할 준비가 되어 있사오니, 필요하시다면 허심탄회하게

애로사항을 말씀해 주시길 바라옵고, 최선을 다해서 처리해 드릴 것을 약속 드립니다. 많은 이용을 부탁

드립니다.

다시 한번 저희 홍익인터넷을 선택해 주신 점에 대해서 감사드리며, 고객 여러분의 무궁한 발전을

기원합니다.

감사합니다!

2000년 10월 19일

홍익인터넷 부사장(C.O.O) 홍기석 배상

QA 연락처

QA Manager : 홍기석

전화(직통): 02-3706-4201이동전화 : 011-797-1692

E-mail : [email protected] : 김희성

전화(직통) : 02-3706-4299이동전화 : 016-393-9998

E-mail : [email protected]

-55-


6. Quality란?

- 필독!!! http://old.hongik.com/main/service/m_web/index.html“엉망진창 홈페이지 만들기” (홍익인터넷 노상범 사장) http://computer.altavista.co.kr/webdesign/“잘못된 웹디자인”

http://korea.internet.com/web/column/content.asp?etcid=532“코리아인터넷닷컴, 최악의 웹 사이트 디자인 10가지”

- Station의 DSN 게시판의 Check List

[기획 & 컨셉]- 사이트의 목적과 필요성을 충분히 인식했나?- 예상되는 주요 방문객의 특성을 충분히 파악했나?- 클라이언트의 니드를 충분히 파악했나?- 유사, 경쟁사이트의 디자인 분석은 완료했나?- 컨셉에 대한 클라이언트와의 합의는 이루어졌는가? (문서로 합의했는가?)- 통일성확보를 위한 칼라, 톤, 폰트, 레이아웃의 원칙들은 수립되었는가?

- 표준 브라우저의 (3.0 or 4.0 이상)결정

- 이미지전달의 우선인가? 정보와 기술등의 텍스트 전달이 우선인가? - 프레임의 사용여부 결정

- 서브화면에 대한 top 화면의 제작여부 결정.- 신기술(다이나믹, 플래시 등)의 사용여부 결정

- 인트로 화면의 유무결정

- 클라이언트가 원하는 색상과 고유한 CI가 있는가?- 모든 홍보물 등에 적용되는 기업(혹은 단체) 지켜야 할 규칙등이 있는가?- 메인 화면과 서브 화면의 최대 용량은 어느 정도인가?

[자료확보]

- 디자인에 필요한 각종 자료는 확보했는가?- 확보된 자료들을 디지탈화하고 분류하였는가?- 확보된 자료의 원본은 잘 보관하고 있는가?- 자료확보로 인한 시간적 손실을 작업일정에 반영하였는가?

-56-

http://korea.internet.com/web/column/content.asp?etcid=532

http://computer.altavista.co.kr/webdesign/

http://old.hongik.com/main/service/m_web/index.html


- 최종 확정된 자료들만 확보받았는가?- 모든 자료와 클라이언트의 요구 및 결정 사항 등은 문서화 되어있는가?

[인터페이스 설계]

- 목적에 충실한 분류 및 그룹핑이 이루어졌는가?- 각 그룹들에 대한 우선순위는 결정되었는가?- 각 메뉴(섹션)의 이름은 클라이언트와 합의되었는가?- 각 섹션들에 대한 사이트맵을 작성하였는가?- 각 섹션들에 대한 네이게이션이 설정되었는가?- 예상 시나리오에 근거한 스토리보드가 작성되었는가?- 각 페이지에 대한 기능적인 정의가 완료되었는가?- 추후 확장성을 충분히 고려했는가?

[이미지 형상화&제작]

- 메타포는 디자인 컨셉에 충실한가?- 유사, 경쟁 사이트와 비교했을 때 비교우위가 있는가?- 사용된 색상에 대한 색상표는 작성했는가?- 디자인되어진 네이게이션바, 아이콘, 이미지, 폰트 등이 통일감이 있는가?- 모든 디자인에 대한 제작의도를 설명할 수 있는가?- 사용된 원본이미지에 대한 저작권은 해결했는가?- 웹 칼라 원칙에 충실했는가? - 최소한의 용량으로 작업했는가?- 최소이용자환경을 고려하였는가?- 모든 원본파일은 수정하기 쉽도록 PSD 화일로 보관하고 있는가?- 프로그램과 연동하는 페이지의 템플릿 화일을 제공했는가?- 모든 페이지에 대한 통일성을 확신하는가?

[HTML코딩]

- 주석은 확실하게 삽입하였는가?- title은 썼는가?- 이미지에 대한 alt태그 및 사이즈를 지정하였나?- 대/소문자 통일은 완료했나?

-57-


[완료&납품]

- 링크 오류, 맞춤법, 프로그램 버그는 체크해보았는가?- 클라이언트의 요구가 100% 반영되었는가?- 추후 유지보수를 위한 준비는 철저한가?- 클라이언트의 수정사항에 대한 대비가 되었는가?- 일련의 과정들에 대한 문서들의 보관 및 데이터 백업은 완료했나?

[유지 보수]

- 제작 후 유지보수는 어느 정도로 할 것인가?

[아웃소싱]

- 사이트 전체를 맡길 것인가? 내부에서 메인과 템플릿을 제작하고 넘길 것인가?- 정해진 체크리스트와 코딩 규칙을 준수했는가? [사후관리]

- 제작완료보고서는 제출하였는가?- 스스로 만족하는가? 무엇을 얻었고, 무엇을 후회하는가?- 클라이언트의 반응은 어떠한가?

-58-

[web agency] project process standard guide

Technology