천객만래 [千客萬來] (It has an interminable succession of visitors)

프로젝트 조정자(Coordinator) vs 촉진자(Expeditor)

1 프로젝트 관리자의 역할 및 권한

 

* 프로젝트 조직구조에 따른 프로젝트 관리자(PM)의 역할 및 권한

  a 기능조직 : PM은 촉진자의 역할

  b 프로젝트 전담조직 : 가장 강력한 권한 위임

  c 약한 매트릭스 조직 : 기능조직+프로젝트 전담조직의 혼합형태. 기본적으로는 기능조직과 유사한 역할이지만 의사결정의 위임이 추가되면 조정자로 지칭

  d 강한 매트릭스 조직 : 프로젝트 조직과 유사한 PM 역할

 

2 구분

  a 프로젝트 촉진자(Project Expeditor) : 의사결정 권한이 없고 프로젝트 팀원들을 지원하며 팀원들의 의사소통을 조정하는 역할

  b 프로젝트 조정자(Project Coordinator) : 의사결정 권한이 있고 상위수준의 관리자에게 보고

 

 

 

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

  • 아래 내용들은 ISTQB FL 시험준비 & 테스팅공부를 위해 다음 출처의 자료들로 공부하며 정리한 것 입니다 *

  • 출처 : 개발자도 알아야할 소프트웨어 테스팅 실무 제3판

  • 출처 : 문제로 배우는 소프트웨어 테스팅 2

  • 출처 : Certified Tester Foundation Level Syllabus version 2011 Korean

[1] 소프트웨어 개발 모델

테스팅은 소프트웨어 개발활동과 독립적으로 존재하지않고 밀접하게 연계되어있으므로,

개발수명주기모델에 기반하여 테스트 접근법을 다르게 적용해야한다

  1. V-모델 (순차적 개발 모델)

※ 참고 : 폭포수모델

  • 폭포수 모델은 개발이 종료된 후 테스팅을 시작한다

  • 폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식(top-down)으로 진행되며, 병행되거나 거슬러 반복되지 않는다. 각 단계가 끝날 때마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 진행한다.

https://terms.naver.com/entry.nhn?docId=3532871&cid=58528&categoryId=58528&expCategoryId=58528

폭포수 모델의 개발 절차
폭포수 모델에서는 폭포의 물이 위에서 아래로 떨어지듯이 계획, 분석, 설계, 구현, 테스트, 유지보수의 각 단계가 하향식(top-down)으로 진행되며, 병행되거나 거슬러 반복되지 않는다. 각 단계가 끝날 때마다 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 진행한다. 폭포수 모델을 적용한 개발 절차에서는 요구 사항 분석 단계가 끝나면 '요구 분석 명세서'라는 문서가 산출된다. 이 명세서를 기준으로 사용자에게 이상 유무를 확인받고 다음 단계인 설계 절차로 넘어간다. 이렇게 각 단계에서 생성되는 산출물에 대해 확인 절차를 거...

terms.naver.com

https://terms.naver.com/entry.nhn?docId=3532872&cid=58528&categoryId=58528&expCategoryId=58528

폭포수 모델의 장점과 단점
폭포수 모델은 각 단계마다 요구 분석 명세서, 설계 사양서, 코드 문서, 데이터베이스 매뉴얼, 사용자 매뉴얼, 운영 매뉴얼 등의 상세한 문서가 생성되는 문서 중심의 모델이라 할 수 있다. 또 각 단계가 명확히 구분되어 있다. 각 단계에서는 산출물이 만들어지고 이 산출물은 다음 단계의 입력 자료로 사용된다. 따라서 해당 단계의 오류를 수정하지 않고 다음 단계로 넘어가면 그 오류가 끝까지 남을 수 있으므로 초기 단계에서 오류를 해결하는 것이 매우 중요하다. 소프트웨어 개발에서 폭포수 모델을 사용했을 때의 장점은 다음과 같다. ■ 관리가...

terms.naver.com

[출처 : 네이버 지식백과 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 한빛아카데미(주))]

<V-모델>

※V-모델 그림 참고 (p.49)

  • 폭포수 개발모델에 근간

  • 개발 단계에 대응하는 테스트레벨이 별도로 존재. 하지만, 일대일 대응은 아니다.

  • 각각의 개발단계에서 테스팅을 접근하는 방법을 간략히 모델화한 것

  • 개발단계와 테스팅활동이 어떻게 통합될수 있는지 설명한다.

  • 실제업무에 적용시에는 특성에 맞게 변형하여 사용한다.

  • 실업무에서 프로젝트,소프트웨어제품의 특성에 따라 v모델에서의 개발단계 및 테스트레벨을 더 많이 혹은 더 적게 구성할 수 있다.

(에) 컴포넌트 테스팅 이후에 컴포넌트통합테스팅이있을 수 있고, 시스템테스팅 이후에 시스템통합테스팅이 존재할 수 있다.

  • 소프트웨어 개발기간중의 '개발산출물(Work products)'은 하나이상의 테스트레벨에서 '테스트베이시스'가 된다.

(예) 일반적인 개발산출물 : CMMI, 소프트웨어 라이프 사이클 프로세스 참고. ??

  • 테스트분석가는 요구사항을 명세화하는 시점에 맞춰 테스트분석,설계를 시작한다

<V-모델을 통한 테스팅의 기본개념>

1) 테스트레벨 ​

  • V-모델에서 제시하는 테스트레벨

(1) 컴포넌트(단위) / 통합 - 하위레벨

(2) 시스템 / 인수 테스팅 - 상위레벨

  • 각 테스트레벨은 서로 독립적인 테스트 수명주기를 가진다. : 각각 다른 테스트전략,계획,기법,목적,수행주체,완료기준 등을 가진다.​

  • 각 테스트레벨은 서로 종속성을 지닌다. : 하나의 테스트레벨에서 다른 테스트레벨로 옮겨가기 위한 종료/시작조건을 갖춰야 한다.

2) 개발 초기 단계에서 테스팅을 수행

→ 정적 테스팅 (리뷰 등)

  • 개발 산출물을 리뷰(Review)형태로 검토하면서 결함을 발견

  • 개발이 시작됨과 동시에 진행한다

  • 테스터는 테스팅관점에서 테스트케이스를 만들면서 결함을 발견하여 리뷰에 기여한다.

  • 요구분석단계에서 테스트케이스를 작성해두면 인수테스팅시 많은 도움이 된다.

  • 정적테스팅 : 결정테이블테스팅, 상태전이 테스팅, 유즈케이스 테스팅 ※4장. 설계기법 참고

3) 결함 예방차원에서의 테스팅

  • 개발초기에 발견한 결함은 수정비용이 저렴

  • 개발초기에 테스트 베이시스가 되는 개발 산출물을 리뷰, 조기에 테스트를 설계하여, 결함을 사전에 예방

4) V&V (베리피케이션 & 벨리데이션)

  • 소프트웨어 개발 수명주기의 전(모든) 단계에서 수행가능

  • 정적테스팅(인스펙션과 같은 리뷰활동) 또는 동적테스팅 모두에서 검증가능

(1)베리피케이션(Verification)

: 개발 단계의 산출물이 그 단계의 '초기에 설정된 조건'을 만족하는지 여부를 검증하는 프로세스

  • 주어진 개발 단계의 제품이 그 단계에서 정의한 대로 조건을 만족하는지, 시스템이나 컴포넌트를 평가하는 프로세스.

  • ISO9000 : 명세된 요구사항이 충족됐는지를 조사에 의해서나 객관적증거제공으로 확인하는 것

  • 수명주기초기에 발생하는 중간산출물에 대해 베리피케이션을 실시하여, 처음에 정의한 대로 조건을 만족하는 시스템이나 컴포넌트가 구현됐는지 사전에 일부검토가 가능하다.

  • 이점 : 결함을 예방

(2)벨리데이션(Validation)

: 개발 중 또는 개발단계 말에 명시된 사용자의 관점에서의 '요구사항'이 만족하는 지를 평가하는 프로세스

  1. 반복적-점증적 개발모델 (Iterative-incremental)

※ 모델 그림 참고 (p.53)

  • 개발주기(요구사항분석-시스템설계-구현 및 테스팅)가 짧게 연속적으로 '반복'하는 활동으로 이루어진다

  • 초기반복단계에서 리스크가 높은 모듈이나 주요 아키텍처에 해당하는 시스템 일부를 우선적으로 개발, 테스팅한다

  • 단위 테스트 프레임 워크 도구를 이용해 개발자가 테스트 주도 개발을 하는 것이 매우 중요하다.

(ex) 테스트 자동화 도구 도입을 통한 테스팅

  • 하나의 반복단계에서 생성한 산출물(프로그램,시스템)은 일반적으로 테스트레벨을 거치면서 검증된다.

  • 이전 반복단계에서 개발한 결과물은 현재의 반복에서 추가개발한 증분(증가된 부분)에 의해 규모가 커져 부분시스템(Partial system)을 형성한다.

  • 이때, 현재반복단계의 증분도 테스팅해야하지만, 부분시스템역시 리그레션여부의 확인목적으로 테스팅해야한다.

  • 리그레션테스팅 : 반복단계가 거듭될수록 중요해진다.

  • 베리피케이션, 벨리데이션 : 각 증분산출물(부분시스템)을 대상으로 수행될 수 있다.

< 장점 >

(1) 조기에 결함과 장애를 발견하고 제거가능하다. (개발리스크를 조기에 감소)

(2) 요구사항이 변경되었을 때 빠르게 반영가능하다.

< 반복적 개발모델에서의 테스팅 이슈 >

: 초기개발단계에서의 테스팅 및 테스트환경과 개발이 반복진행되면서, 테스팅 및 테스트환경이 변경된다.

  • 제한된 세트의 집중된 테스트에서, 광범위한 세트의 분산된 테스트로 확장

  • 테스트 대상 컴포넌트가 점차 증가

  • 단순한 테스트환경에서, 복잡한 테스트환경으로 변화

  • 시간이 지남에 따라 개별 유즈케이스 테스팅에서, 유스케이스간의 통합 테스팅으로 변화

< 주요 모델 > : 반복적으로 개발하는 모델들

  • 애자일 개발 모델 (민첩) (Agile) : XP(eXtreme Programming) , SCRUM 등

  • 래셔널 통합 프로세스 : RUP (Rational Unified Process)

  • 래피드 애플리케이션 개발 : RAD (Rapid Application Development)

  • 이해 관계자 중심의 소프트웨어 개발 (Outside-in Software Development)

  • 프로토타이핑 (Prototyping)

<애자일 테스팅 특징>

  • 테스트를 미리 설계하지 않을 수 있으며, 누구나 테스트에 적극참여가능 (사용자,테스터,개발자)

  • 결함을 최대한 빨리 발견가능 (요구사항을 개발과 동시에 발견가능)

  • 문서를 최소화한다

  • 테스트는 개발과 같이시작되거나 먼저시작되므로, 개발완료 = 테스트완료 이다.

  1. 개발 수명주기 모델 (Life Cycle)에서의 테스팅
  • 테스트 레벨은 프로젝트, 시스템아키텍쳐의 성격에 따라 재조정, 합쳐질 수 있다

(예) 상용(COTS : Commercial Off The Shelf)소프트웨어 제품을 시스템에통합할때

  • 구매자는 시스템레벨에서 통합테스팅 / 인수테스팅을 수행할 수 있다

  • 통합테스팅 : 인프라나 다른 시스템에 통합, 배포된 시스템에 통합

  • 인수테스팅 : 기능적 테스팅, 비기능적 테스팅, 사용자 테스팅, 운영 테스팅 등 수행

<성공적인 테스팅 요건>

  • 모든 개발 활동은 이에 상응하는 테스팅활동을 동반한다

  • 각 테스트 레벨은 그 레벨에 맞는 특정한 목적을 가지고 있다

  • 주어진 테스트 레벨에 맞는 테스트의 분석과 설계는 대응되는 개발활동 동안에 시작​되어야 한다

  • 개발산출물 리뷰 : 개발 수명주기 동안에 개발 산출물의 초안이 작성되면, 테스터는 이러한 문서를 리뷰하는 활동에 참가해야 한다.

[2] 테스트 레벨(Test Levels)

< 각 테스트레벨 특징에 맞게 정의&식별되는 항목>

  • 일반적인 목표 : 목적

  • 테스트 케이스를 도출해내는데 참조되는 개발산출물 : 테스트베이시스

  • 테스트 대상 : 테스트할 그 무엇

  • 발견된 전형적 결함, 장애

  • 테스트 하네스 (드라이버,스텁), 툴 필요여부

  • 상세한 테스트 접근법

  • 테스트 수행주체, 조직

<화이트박스&블랙박스 테스팅>

  • 컴포넌트 테스팅 - 화이트박스

  • 시스템 테스팅 - 블랙박스

  1. 컴포넌트 테스팅(Component Testing) = 단위 테스팅(Unit Testing) = 모듈 테스팅 = 프로그램 테스팅

: 테스트가 가능한 최소단위로 나누어진 소프트웨어 (모듈,프로그램,객체,클래스 등) 내에서 결함을 찾고 그 기능을 검증하는 것

  • 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템의 다른부분에서 격리하여 독립적으로 수행할 수 있다.

이떄, 스텁, 드라이버, 시뮬레이터가 사용될 수 있다.

  • 테스트케이스는 개발산출물에서 도출된다 : 컴포넌트명세, 소프트웨어상세설계, 데이터모델과 같은 개발산출물

  • 일반적으로 코드를 중심으로 수행하며, 개발환경의 지원을 필요로 한다 : 단위테스트프레임웍, 디버깅 툴과 같은 개발환경

  • 실무에서 개발자가 직접 테스트에 참여하여 결함을 바로수정하며, 기록과정은 일반적으로 생략한다.

그러나 프로세스관리,개선을 위해 결함에 대한 통계적 데이터가 필요한 경우는 인시던트(결함) 기록과정이 필요하다

  • 테스트 중심의 개발방법론 (Test-first approach / test driven development) : 코딩전 테스트케이스를 준비하고 자동화하는 방법이다. 반복적성향이 매우 강한 접근법으로 테스트케이스를 개발한 후 작은 규모의 코드를 작성, 통합하고 테스트가 통과할 떄까지 반복수행한다.

  • V모델에서 하위레벨 테스트에 속한다.

  • 테스팅

  • 주된 테스팅 방식 : 구조기반테스팅(화이트박스)

  • 구조적 : 분기커버리지등

  • 기능성

  • 비기능성 : 리소스 메모리유출 관련, 강건성 테스팅 등..

  • 수행주체

: 주로 개발자가 직접, 타개발자, 제3자 테스터

<목적>

  • 기본경로(Path)확인

  • 모든 오류처리경로(Error handling path) 확인

  • 컴포넌트 내의 인터페이스 확인

  • 로컬 데이터 확인, 경계값 확인

<테스트 베이시스>

  • 컴포넌트 요구사항

  • 상세설계 / 프로그램 상세 설명서

  • 코드

<테스트 대상>

  • 컴포넌트

  • 프로그램

  • 데이터변환, 마이그레이션 프로그램

  • 데이터베이스 모듈

  1. 통합 테스팅 (Intergration Testing)

: 컴포넌트간의 인터페이스를 테스트하는 것

: 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트 하는 것 (OS,파일,시스템,하드웨어,시스템간 인터페이스)

  • 단위간의 결합과 인터페이스를 중점적으로 검증한다.

  • 개별모듈의 내부 기능성에는 관심을 두지 않는다.

  • 컴포넌트테스팅은 개별모듈의 기능에 관심을 두지만, 통합테스트는 두개 모듈사이의 커뮤니케이션에 관심을 둔다.

  • ??? 통합의 각 단계에서 테스터는 통합 그 자체에만 집중(실라버스) / 통합그자체에만 집중하는 오류를 범하지 말아야 한다(책)

  • 이상적으로는 테스터가 이키텍처에 대한 이해를 바탕으로 통합테스팅계획에 관여해야한다.

  • 컴포넌트 또는 시스템이 만들어지기 전에 통합테스트를 계획한다면, 테스팅을 가장 효율적으로 수행할 수 있도록 컴포넌트 개발순서를 계획할 수도 있다.

  • V모델에서 하위레벨 테스트에

  • 테스팅

  • 기능적 / 비기능적(성능,연결성) 특성을 테스팅해야한다

  • 테스팅설계 : 기능적 / 구조적 접근법 모두 사용하여, 통합 그 자체만 집중하는 오류를 범하지 말아야 한다.

  • 수행주체

: 테스터

  • 하나이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행될 수 있다.

1) 컴포넌트 통합 테스팅 : 소프트웨어 컴포넌트 사이의 상호작용을 테스트하며 컴포넌트 테스팅 이후에 수행된다

2) 시스템 통합 테스팅 : 서로 '다른 시스템간' 또는 하드웨어, 소프트웨어간 상호작용을 테스트하며, 시스템 테스팅 이후에 수행된다.

  • 타 시스템과의 연동 테스트

  • 개발조직은 한쪽 시스템에 국한되어 제어 권한을 갖고, 이는 리스크로 간주됨 : 변경발생시 시스템전체차원에서 불안정유발

  • 비즈니스 프로세스가 시스템간의 업무흐름을 가지고 있는 경우, 시스템간 교차점에서 중대한 문제를 야기가능

  • 통합하는 범위가 크면 클수록 장애,결함의 위치를 찾아 격리하기가 어렵다. → 개발리스크/문제해결(Troubleshooting)시간 증가

  • 통합하는 범위가 클수록, 특정 컴포넌트나 시스템에서기인하므로.

(ex) 빅뱅 접근법 : 점진적 통합방식에 비해 결함발견이 늦어져 리스크로 작용할 확률이 높다

  • 따라서, 결함을 쉽게 격리하고 조기발견하기위해서 순차적, 체계적인 통합전략(Incremental approach)을 사용해야 한다

  • 빅뱅전략 x / 상향식, 하향식, 백본 o

  • 시스템 통합 전략은 시스템아키텍처 (상향식/하향식), 기능적테스트, 트랜잭션 처리순서, 시스템 또는 컴포넌트의 다른 측면등에 기반을 둘 수 있다

< 통합 테스트 레벨의 통합 접근법>

※표 참고 (P.56)

1) 백본(Backbone) : 가장 중요,리스크가 높은 모듈로 초기통합형성

  • 장점 : 결함 격리 쉬움 / 리스크가 높은 결함을 초기에 발견

  • 단점 : 시간이 오래 걸림

  • 드라이버/스텁 : 필요에 따라 만들어 사용

2) 빅뱅(Big bang) : 모든 테스트 모듈을 동시에 통합

  • 장점 : 단시간 테스트

  • 단점 : 결함 격리 어려움

  • 드라이버/스텁 : 없다. 실제모듈로 테스트

3) 상향식(Bottom up) : 가장 하부모듈부터 통합해가면서

  • 장점 : 결함 격리 쉬움 / 하위모듈을 충분히 테스트

  • 단점 : 수정이 어려운 중요결함을 상부구조에서 발견가능 / 비즈니스 로직반영이 어려움

  • 드라이버/스텁 : 테스트 드라이버가 필요

4) 하향식(Top down) : 가장 상부모듈부터 통합해가면서

  • 장점 : 결함 격리 쉬움 / 설계쌍의 결함을 빨리 발견

  • 단점 : 수정이 어려운 중요결함을 하부에서 발견가능 (ex)디자인결함을 가진 db

  • 드라이버/스텁 : 테스트스텁이 필요

<테스트 베이시스>

  • 소프트웨어와 시스템 설계

  • 아키텍쳐

  • 워크플로우(Workflows)

  • 유즈케이스

<테스트대상>

  • 서브 시스템

  • 데이터베이스 구축

  • 기반환경

  • 인터페이스

  • 시스템 구성과 구성 데이터

  1. 시스템 테스팅 (System Testing)

: 개발 프로젝트 차원(범위)에서 정의된 '전체 시스템 또는 제품의 동작'(시스템 성능)에 대해 테스트 하는 것

  • 테스팅 범위 : 해당 테스트레벨의 마스터/레벨테스트 계획에 명확하게 정의되어 있어야 한다.

  • 단위 및 통합테스트가 완료돼 기능상 문제가 없는 상태에서 수행할 수 있다.

  • 실제 최종 사용환경 또는 이와 유사한 환경에서 수행해야한다. : 환경특성장애(Environment-specific failure)리스크를 최소화하기 위해서

  • 전체 기능상의 결함발견, 비기능적 품질 특성확인을 목적으로 한다

  • 테스트엔지니어는 불완전, 문서형태를 갖추지못한 요구사항을기반으로 테스트하는 경우도 고려해야한다.

  • 시스템 성능(시스템,제품의 동작)과 관련된 고객의 요구사항이 성공적으로 수행되었는지를 확인한다.

  • V모델에서 상위레벨 테스트에 속한다

  • 완료조건 : 오픈돼있는(처리되지않은) 심각한 결함이 없음 / 모든 기능,비기능테스트아이템을 테스트함

  • 테스팅

  • 기능 요구사항 / 비기능 요구사항 / 데이터 품질특성 등을 모두 검증해야한다

[ 기능적]

  • 주된 테스팅 방식 : 명세기반테스팅(블랙박스)

(예) 결정테이블 기법 : 비즈니스 룰에 표현된 결과들의 조합을 테스트하기 위해 사용

[비기능적(구조적)]

  • 구조기반기법 : 메뉴구조나 웹페이지 내비게이션같은 구조적(비기능적)요소에 결함문제가 없는지 평가

  • 기능적 품질특성 외 나머지부분 검증을 수행

(예) 성능테스트, 가용성테스트, 보안성 테스트

  • 수행주체

: 주로 독립적인 테스트 팀이 진행 (하지만 개발팀도 수행가능)

< 테스트 베이시스(개발산출물) >

  • 리스크 분석서(리포트)

  • 요구사항 명세 : 시스템 및 소프트웨어

  • 기능 명세

  • 비지니스 프로세스

  • 유즈 케이스

  • 기타 비지니스 레벨의 시스템 동작 명세

  • OS 및 시스템 리소스와의 상호작용 명세

<테스트대상>

  • 시스템, 사용자메뉴얼, 운영메뉴얼

  • 시스템구성, 구성데이터

  1. 인수 테스팅 (Acceptance Testing)

: 시스템이 인수조건을 만족시키는지, 사용자나 고객이 시스템을 인수할지 결정할 수 있도록

사용자의 필요, 요구, 비지니스 프로세스를 고려해 수행하는 테스팅이다.

  • 요구분석단계에서 테스트케이스를 작성해두면 인수테스팅시 많은 도움이 된다.

  • 테스트 베이시스가 확보되는 개발 초기단계(요구사항정의단계)에서 시작한다

  • 최종 단계의 테스팅이라고 보기 어렵다

(예) 대규모의 시스템 통합 테스트를 개별시스템에 대한 인수테스트 이후에 실행할 수도 있다.

  • V모델에서 상위레벨 테스트에 속한다

< 목적 >

: 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 '확신'을 얻는 것.

  • 결함을 찾는 것은 주된 관심사가 아니다.

  • 사업적 리스크(Business Risk)에 집중해 테스트한다

  • 프로젝트 전(모든) 개발 과정에서 수행할 수 있다.

  • 상용(COTS)소프트웨어 제품은 설치, 통합되면 - 인수테스팅을 수행할 수 있다

  • 프로그램 유지보수성에 대한 인수테스팅은 - 컴포넌트테스트 실행전에 수행할 수 있다

  • 컴포넌트의 사용성에 대한 인수테스팅은 - 컴포넌트테스팅 동안에 수행할 수 있다

  • 새로운 기능상의 개선에 대한 인수 테스팅은 - 시스템 테스팅전에 수행할 수 있다

  • 수행주체

: 시스템을 사용하는 고객이나 사용자가 전담하여 수행하는게 대부분 / 다른관련자도 참여가능

<인수 테스팅의 전형적인 형태>

1) 사용자 인수 테스팅

  • 일반적으로 비즈니스 사용자가 시스템 사용의 적절성을 확인한다

2) 운영상의 인수 테스팅

  • 시스템관리자에 의한 테스트활동이다.

  • 테스트항목

  • 백업/복원테스팅

  • 재난 복구

  • 사용자 관리

  • 유지보수 작업

  • 보안취약성에 대한 정기점검

  • 데이터로드, 마이그레이션 작업

3) 계약 / 규정 인수테스팅

  • 계약 인수테스팅 : 맞춤식개발(Custom-developed) 소프트웨어가 계약상의 인수통과조건을 준수하는지확인하는 테스팅으로, 인수자가 계약에 동의할 때 인수통과된다

  • 규정 인수테스팅 : 정부지침, 법률, 안정규정 등 준수해야 하는 규정에 맞게 개발되었는지 확인하는 테스팅

4) 알파 / 베타(필드) 테스팅

  • 상용소프트웨어개발자는 종종 소프트웨어가 상업적으로 판매되기 전에 목표시장의 기존 고객이나 잠재고객으로 피드백을 받고 싶어한다.

(1) 알파테스팅 = 공장 인수 테스팅(Factory acceptance testing)

  • 개발 조직 내에서 고객에 의해 수행된다

  • 고객사의 사이트로 이동하기 전에 개발완료후 테스팅

(2) 베타(필드)테스팅 = 사이트 인수 테스팅(Site acceptance testing)

  • 실제 환경에서 사용자, 잠재고객에 의해 수행된다

  • 고객사이트로 이동한 후에 테스팅

<테스트 베이시스>

  • 리스크 분석 리포트

  • 사용자 요구사항 : 테스트케이스구성을 위한 베이시스

  • 시스템 요구사항

  • 유즈케이스

  • 비지니스 프로세스

<테스트 대상>

  • 완전히 통합된 시스템의 비즈니스 프로세스

  • 운영 및 유지보수 프로세스

  • 사용자 절차

  • 양식

  • 보고서

  • 구성 데이터

<검수 테스팅>

  • 실무에서는 시스템테스팅 - 인수테스팅사이에 출시여부를 결정하기위한 검수테스팅이 존재하는 경우가 있다

  • 품질평가형태로 이루어진다

<개발과정 테스팅>

  • 소프트웨어의 결함을 찾고 수정하기 위해 가능한 많은 장애의 원인을 발생시킨다

<SW 품질평가 테스팅>

  • 신뢰성, 가용성 같은 시스템의 특성을 평가한다

[3] 테스트 유형 (Test types)

  • 테스팅하는 목적 및 품질특성을 염두에 두고, 소프트웨어 시스템(시스템일부)을 검증하는 일련의 테스트활동을 말한다.

  • 테스트의 구체적인 이유, 대상에 따라 특정테스트 활동 묶음을 소프트웨어 시스템(또는 시스템의일부)을 확인하기 위해 실행할 수 있다.

<테스트유형은 다음의 테스트목적에 중점을 둔다>

  • 소프트웨어가 수행하는 기능에 대한 테스팅

  • 비기능적인 품질 특성 테스팅 : 호환성, 신뢰성, 사용성과 같은

  • 소프트웨어나 시스템의 구조나 아키텍쳐에 대한 테스팅

  • 변경내용에 대한 테스팅 : 확인테스팅 / 리그레션 테스팅

<테스트 용이성 (Testability)>

  • 테스터는 품질속성 중 제품요구사항을 리뷰할 때(테스트 전에/개발(코딩) 전에), 제품에 대한 테스트용이성을 먼저 평가해야 한다.

  1. 기능 테스팅 (Functional Testing)

: 시스템이 수행하는 그 '무엇' = 기능

  • [블랙박스]테스팅

  • 모든 테스트 레벨에서 수행가능

  • 블랙박스 테스팅 : 명세기반기법을 이용해 소프트웨어, 시스템기능에서 테스트조건,테스트케이스를 도출하고 소프트웨어의 외부적인 행동을 고려한다.

  • 프로세스 흐름 모델, 상태 전이 모델, 평문 언어 명세 등을 이용가능

  • 실행되어야하는 (서브)시스템,컴포넌트의 기능은 개발산출물(요구사항명세, 유즈케이스, 기능적명세)에 기술되어 있거나, 문서화되지 않을 수 있다.

  • 기능테스팅은 문서화되어있거나 테스터가 알고 있는 기능과 특징, 그것들과 특별한 시스템과의 상호운용성을 고려하여 수행한다.

(예) 컴포넌트 테스트 레벨에서의 기능테스팅 - 컴포넌트 명세를 기반으로함

<품질특성 : 기능성>

  • 품질부특성 : 적합성,정확성, 준수성, 상호운용성, 보안성 [적.정.보.상.준]

1) 보안성 테스팅 (Security Testing)

: 악의적인 코드(바이러스등)와 같은 외부로부터의 위협을 감지해내는 것과 관련이 있는 기능(방화벽)을 확인하는 테스팅

  • 보안정책확인

  • 시스템으로 침투하는 보호되지 않는 진입점(트랩도어) 파악

  • 가용성, 무결성, 기밀성, 부인방지 등의 보안관련 평가

2) 상호운용성 테스팅(Interoperability)

: 하나 또는 여러개의 명시된 컴포넌트나 시스템이 서로 상호작용하는 소프트웨어 제품의 능력을 평가하는 테스팅

  1. 비기능 테스팅 (Non-Functional Testing) = 소프트웨어 제품 특성 테스팅(Testing of software product characteristics)

: 시스템이 '어떻게' 동작하는가를 테스팅

  • [블랙박스]테스팅

  • 성능, 부하, 스트레스, 사용성, 유지보수성, 신뢰성, 이동성 테스팅을 포함하는 개념이다.

  • 모든 테스트 레벨에서 수행가능

  • (성능테스팅에서의 응답시간과 같이) 다양한 척도,비율(Scale)로 정량화가능한 소프트웨어, 시스템의 특성을 측정하는 테스트이다.

  • 외부로 표출되는 소프트웨어의 습성을 확인할 목적으로 실행된다.

  • 블랙박스 테스트 설계기법을 활용한다

<부하 테스팅(Load Testing)>

실제 환경을 가정하고 일반적으로 요구사항에서 제시하는 부하의 최대치를 발생시켜 시스템이 안정적으로 작동하는 지를 확인하는 테스트.

<비기능성>

  • 품질특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성 [유.효.이.신.사]

  1. 구조적 테스팅 (Structural Testing)

: 특정 유형의 구조에 대한 커버리지를 평가하여 테스팅의 보장성, 충분함(Thoroughness)을 측정하는 테스팅

  • [화이트박스]테스팅

  • 제어 흐름 모델, 메뉴구조 모델 등을 이용가능

  • 구조기반(화이트 박스) 테스팅 : 코드커버리지 높임

  • 모든 테스트 레벨에서 수행가능 : 시스템, 시스템 통합, 인수 테스팅

(예) 비즈니스 모델이나 메뉴구조도 활용하여 구조적 테스트 설계를 통해 수행이 가능하다.

  • 명세기반기법을 적용한 다음에 사용할 떄 가장 좋은 결과를 보여준다.

  • 컴포넌트 테스팅/컴포넌트 통합 테스팅 레벨에서 프로그램 코드 커버리지를 높이는 용도로 사용한다.

((자동화)도구사용하여 선언,구문(Statements) 혹은 결정문(Decisions)과 같은 커버리지 요소를 측정)

  • 코드레벨뿐만아니라, 호출 체계/구조(Hierarchy)와 같은 시스템의 아키텍처에 기반을 두고 수행가능하다.

<커버리지>

: 시스템, 소프트웨어 구조가 테스트수트에 의해 테스트된 정도

  • 만일 커버리지가 100%가 아니라면, 누락된 아이템을 테스트하기위해 더많은 테스트를 설계하여 커버리지를 높일 수 있다

  1. 확인 테스팅 (Confirmation Testing) = 재 테스팅 (Re Testing)

: 결함이 발견되고 수정된 후에 소프트웨어는 원래의 결함이 성공적으로 제거되었는지 확인하기 위해 다시 테스트하는 것

  • 디버깅(결함의 원인을 찾거나 수정하는 활동)은 개발활동이며, 테스팅활동이 아니다.

  1. 리그레션 테스팅 (Regression Testing) = 회귀 테스팅

: 결합수정 이후 변경의 결과로 새롭게 만들어지거나, 이전 결함으로 인해 발견되지 않았던 또다른 결함을 발견하기 위해

  • 이미 테스트된 프로그램의 테스팅을 반복하는 것. 퇴행(Regression)여부를 확인하는 테스팅

  • 모든 테스트 레벨에서 수행가능

  • 기능, 비기능, 구조적 테스팅에 적용할 수 있다

  • 반복수행되므로 '자동화'대상으로 고려가능 : 리그레션 테스트 수트는 여러번 반복수행되며 대개는 서서히 변경되므로

  • 테스트 대상 : 변경된 소프트웨어뿐만아니라 환경이 변경되어도 수행되어야 한다.

  • 결함은 테스트중인 소프트웨어에 존재할 수 있고, 관련이 없는 다른 소프트웨어 컴포넌트에도 있을 수 있다.

  • 테스트 범위/정도 : 리스크에 바탕을 둔다

  • 위험성이 높으면 리그레션 테스팅을 넓은범위로, 보다 상세하고 철저하게 수행 (Intensive and higher-depth)

  • 테스트가 확인테스팅으로 쓰이거나, 리그레션 테스팅을 보조한다면 그 테스트는 반복적인 성향을 갖는다.

  • 결함 마스킹은 리그레션 테스팅으로 찾을 수 있다.

<결함 마스킹(Fault Masking)>

: 어떤 이유로 결함이 가려져서 해당 결함을 발견할 수 없는 상태

​- 결함이 있는 프로그램 부분이 실행되지 않았거나, 다른 결함이나 장애로 해당 결함이 드러나지 않는 등 여러 이유로 결함이 존재하지만 발견되지 않을 수 있다.

[4] 유지보수 테스팅 (Maintenance Testing)

: 소프트웨어 또는 시스템이 변경, 단종, 마이그레이션될 때, 이미 운영되고 있는 시스템에서 수행하는 테스팅

  • 개발과정에서 변경작업이 일어나는 경우, 새로운 결함이 유입됐는지 확인한다.

  • 모든 테스트 유형 / 모든 테스트 레벨에서 수행가능​

  • 명세(Specifications)가 매우 오래되었거나 없다면 명세서를 근간으로 수행하기는 어렵다

  • 사전에 출시계획을 세우는 것이 유지보수 테스팅의 성공여부에 중대한 영향을 미친다.

  • 테스트 대상 : 변경된 부분에 대한 테스팅 이외에도 변경되지 않은 시스템 요소에 대한 방대한 리그레션 테스팅도 고려해야한다​

  • 테스트 범위/정도 : 변경사항의 리스크 및 크기, 기존시스템의 크기

  • 영향도 분석(Impact analysis) : 변경으로 인해 기존시스템이 어떻게 영향을 받는지 결정하는 것

  • 얼마나 많은 리그레션 테스팅을 수행할지 결정하는 데 이용한다

1) 변경(Modification)

  • 출시(릴리즈)기반으로 계획된 개선활동에 의한 변경, 요구사항 변경에 의한 수정과 긴급변경, 환경의 변경 등

  • 계획된 OS 또는 DB 업그레이드 / 계획된 상용소프트웨어 업그레이드 / OS의 새로 드러난 취약점 패치

2) 마이그레이션 = 변환

  • 한 플랫폼에서 다른 플랫폼으로 옮기는 작업

  • 변경되는 소프트웨어에 대한 운영테스트 + 새로운 환경에서의 운영테스트 필요

  • 운영되고 있는 시스템에서 다른 응용프로그램의 데이터가 마이그레이션될때도 필요

3) 단종

  • 데이터를 마이그레이션하는 테스팅 포함

  • 데이터 저장관련 테스팅 : 데이터의 보유기간이 필요할경우

  • 유지보수테스팅 vs 유지보수성테스팅 비교하기! - 다른개념이다

< (비교) 유지보수성 테스팅(Maintainability Testing)>

: 소프트웨어 및 시스템이 변경을 고려해 얼마나 잘 개발했는지 밝히는 테스팅

  • 유지보수성이 낮은 시스템은 작은 변경에도 취약하다 ( 코드의 많은 부분을 수정하는 등 재작업,리소스 투입이 많음)
    [출처] Part2. 소프트웨어 수명주기와 테스팅|작성자 Eugene
Posted by 사용자 SB패밀리

댓글을 달아 주세요

소프트웨어 개발주기

확인(Verification) - 제품을 올바르게 개발하고 있는가? Need

소프트웨어 개발 주기에서 주어진 단계에서의 생산품이 이전 단계에서 수립된 요구들을 수행하는가를 결정하는 과정.

프로그램 정확도의 형식 증명.

항목들, 프로세스들, 서비스들, 또는 문서들이 명시된 요구들을 따르는지 재검토하고 조사하며 시험, 검사, 감사 및 문서화하는 행위.

검증에는 주기 검증과 형식 검증의 두 가지 형태가 있다. 주기 검증은 개발 주기의 특정 단계에서 제작된 생산 제품이 그 이전 단계에서 설정한 규격들을 어느 정도 충족시키는지를 결정하는 과정이다. 형식 검증은 원시 부호가 규격에 맞게 작성되었는지를 수학적으로 엄격하게 증명하는 것이다

보증,검증(Validation) - 올바른 제품을 개발하고 있는가? Procedure

소프트웨어에 대한 요구 조건에 응하고 있는 것을 확인하기 위해 소프트웨어 개발공정의 마지막에 소프트웨어를 평가하는 공정.

소프트웨어개발과정의 최종 단계로써, 소프트웨어가 요구된 바와 합치되는지를 평가하는 일.

소프트웨어 타당성 검사(Software Validation)

 

 

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

검증(Validation)

올바른 제품을 만들고 있는가? WHAT

QIP(Quality Inspection Plan)

품질시험계획서(제품명세서)

기자재 제작업체가 기기제작에 착수하기 전에 검사품명, 제작공정별 검사  항목,     적용규격, 검사예정일, 검사장소 등을 명시하여 검사를 효과적으로 수행하기 위하여 제작업체가 작성하여 발주자가의 승인을 받으며 시험 및 검사가 공장에서 이루어지는 공장 QIP와 발전소 또는 건설현장에서 이루어지는현장 QIP로 구분됩니다.

   - 검사방법은 “R, W, H” 가 있으며, 자세하게 설명하면 다음과 같습니다.

   R(Review Point) : 공정 중 시험환경, 절차 및 판정기준 등의 시험요건과 규격 및 성능이 계약규격에 만족되는지를 확인하기 위하여 점검하는 행위입니다.

   W(Witness Point) : 공정 중 검사자의 입회를 받도록 결정한 시점으로,입회검사가 불가능할 경우 다음 공정으로 진행시킬 수 있으나, 반드시 입회불가 통보를 받은 후에 진행하여야 합니다.

   H(Hold Point) : 공정 중 검사자에 의한 검사 또는 입회를 필요로 하는 중요단계로서 검사에 합격하지 않고는 다음 공정으로 진행하지 못하도록 결정한 검사점을 말합니다.

 

확인(Verification)

올바르게 제품을 만들고 있는가?  HOW

ITP(Inspection Test Plan)

검사및시험계획서(시험절차서)

공정 중 실시하는 검사항목에 대한 적용범위, 적용기준 및 표준, 시험 및 검사 항목, 항목별 시험검사 절차, 판정기준 등 시험 및 검사수행에 필요한 내용을 상세히 기술한 서류를 말합니다

 

 

품질관련 필수용어 필수용어 참조

Posted by 사용자 SB패밀리

댓글을 달아 주세요

RISK 관리란

프로젝트관리 2016. 6. 26. 23:26

RISK 관리란



RISK 

□ 개요

 
건설업은 초기 계획·설계단계에서부터 건설·준공·사용·유지관리의 전 과정에 이르기까지 다른 유형의 산업보다 더 심각하면서도 다양한 종류의 불확실성과 위험성에 직·간접적으로 노출된다. 이에 대한 효과적이며 능동적인 대처가 필요하며 건설업의 리스크 관리 이론 체계와 실무적용 방법론의 정립이 요구된다. 

○ RISK 관련 용어 

리스크 관리에 있어서 가장 중요한 용어로는 리스크, 불확실성, 확실성 등을 들 수 있다. 


1) 리스크: 부정적인 영향을 초래할 사건의 발생 가능성, 불확실한 위험을 내포하고 있는 요인·요소· 방향, 사건이 발생할 확률 및 그 심각성 등을 포괄적으로 나타낸다. 이는 발생할 사건 및 그로 인한결과가 일정 범위의 신뢰성 한계 내에서 확실하게 예측될 수 있는 상태로 미래 발생할 사건에 대한 확률분포를 정의할 수 있다. 


2) 불확실성: 의사결정에 필요한 정보가 전무한 상태이며, 미래 발생할 사건 및 그로 인한 결과에 대하여 전혀 알 수 없는 경우로서 미래 발생할 사건에 대한 확률분포를 정의할 수 없다. 


3) 확실성: 의사결정에 필요한 모든 정보가 확보되어 미래에 발생할 사건을 확신을 갖고 예측할 수 있는 상태이다. 
건설업의 리스크 관리의 대상으로는 손실·피해는 물론 획득·기회도 포함하는 포괄적 개념의 리스크를 대상으로 해야 한다. 

○ 리스크와 불확실성 

해당 결정이 영향을 미치는 기간 동안 무엇이 발생할 것이지, 발생 후 어떠한 결과를 유발 할 것인지 정확하게 구체화할 수 있을 때만 확실성이 존재한다. 물론 건설산업에서 흔하지 않은 일이다. 확률계산이 가능하며 정량적인 표현을 할 수 있는 경우, 불확실성은 리스크로 전환되며 이 때 리스크는 관리의 대상이 된다. 

○ 리스크 관리 

불확실한 상황에서의 문제해결과정을 개선하기 위해 다양한 유형의 리스크 관리 절차가 있다. 본질적인 측면은 대동소이하며 일반적으로 다음과 같은 절차로 정의된다. 


1) 리스크 식별: 리스크 발생의 근원을 인식하고 리스크 인자의 유형과 특성을 파악함으로써 발생 가능한 리스크 성격을 이해하는 과정. 식별과정의 합리화와 이후의 분석과정을 위해 리스크들에 대한분류체계가 요구되며 리스크의 성격, 시간적인 차원, 공간적인 차원 등이 분류기준으로 사용된다. 


2) 리스크 분석: 계량적 분석기법을 이용하여 식별된 리스크 인자의 결과적 중요도를 파악하여 리스크를 보다 명확하게 이해하고 이에 대응하기 위한 대안설정이나 전략수립 여부를 판단, 결정하는 과정이다. 분석과정에 활용될 수 있는 모델은 감도분석방법, 확률분석방법 등이 있다. 


3) 리스크 대응: 리스크의 부정적인 영향을 가능한 한 완벽히 제거하고, 리스크에 대한 통제력을 증가시키기 위한 것으로 리스크 대응전략은 다음 4가지로 구분된다. 


- 리스크 회피(Risk Avoidance): 리스크에 대한 노출 자체를 회피함으로써 발생될 수 있는 잠재적 손실을 모면하는 전략 
- 리스크 감소(Risk reduction): 가능한 모든 방법을 활용하여 리스크 발생 가능성을 저감시킴으로써 리스크에 대한 노출 정도를 감소시키는 전략 
- 리스크 전이(Risk Transfer): 계약과 보험 등을 통하여 리스크의 잠재적 결과를 다른 집단에 전가하거나 함께 공유하는 전략 
- 리스크 보유(Risk Retention): 회피되거나 전이될 수 없는 리스크를 감수하는 전략특정 리스크 인자에 대하여 어떠한 대응전략을 마련해야 하는가? 에 관련해서 의사결정자 및 대상 프로젝트의 유형 및 특성에 따라 다르다. 이때 의사결정자의 리스크 태도(attitude)가 신중히 검토되어야 한다. 





Posted by 사용자 SB패밀리

댓글을 달아 주세요



'SW 마에스트로' 연수생 구글 본사 방문… 선배들과 간담회

2011년 01월 07일

"좋은 소프트웨어(SW) 개발자의 조건은 명문대 졸업여부가 아니라 창의력과 문제에 접근하고 해결하는 능력이다.", "초가집을 수 백 채 지어봤다고 63빌딩을 건설할 수 없다. SW 개발도 우선 역량을 크게 키워야 한다."

실리콘밸리를 방문한 한국의 SW 꿈나무들에게 미국 구글 본사에서 근무하고 있는 한국인 SW 엔지니어들은 창의력을 바탕으로 더 높은 곳으로 비상해야한다고 조언했다.

5일(현지시간) 지식경제부, 정보통신산업진흥원, 한국정보산업연합회 등이 주관하는 SW 마에스트로 미국 연수의 일환으로 구글을 방문한 학생들은 직원들의 언제든 즐길 수 있는 게임기와 카페테리아 등 자유로운 업무환경을 돌아봤다. 이어진 구글 본사에서 근무하고 있는 한국인 SW엔지니어들과의 간담회에서는 선배들의 조언이 쏟아졌다.

SW엔지니어인 전지운 씨는 "코딩과 프로그래밍 능력은 물론 창의력과 문제에 접근하고 해결하는 능력이 중요하기 때문에 미국에서는 SW 개발자를 뽑는데 창의력과 문제 해결 능력 등에 중점을 두고 평가한다"며 "알고리즘과 자료구조 등이 중요한데 책만 본다고 이런 능력이 생기는 것이 아니므로 프로젝트를 하면서 문제 해결 능력을 배양해야 한다"고 말했다.

김용성씨는 "초가집을 수 백 채 지어봤다고 63빌딩을 지을 수 있는 것이 아닌 것처럼 SW 도 SW를 잘 개발하는 역량이 있는 기업에서 배워야 한다"며 "SW 마에스트로 과정을 통해 큰 프로젝트들을 진행해 보는 것도 도움이 될 것"이라고 조언했다.

SW 마에스트로 연수단 학생들은 구글의 SW 개발 여건에 많은 관심을 나타냈다.

이에 대해 김용성 구글 SW엔지니어는 "미국과 한국의 SW 개발 환경의 차이는 관리 대상이 다르다는 것"이라고 설명하고 "한국에서는 SW를 개발할 때 사람을 대상으로 관리하는데 구글 등 미국에서는 일의 성과를 중심으로 관리한다는 점이 다르다"고 말했다. 또 "구글 등 미국 기업들의 자율적인 SW 개발 환경에 대해 동경하는 이야기가 많은데 실제 일의 강도와 업무는 한국보다 더 높다"며 "이는 업무를 믿고 맡겨서 밀어주는 환경이 업무 집중도를 높여주기 때문"이라고 설명했다.

한국인 구글 SW엔지니어들은 후배 개발자들에게 문제 해결 능력을 배양하는 것이 중요하다고 입을 모아 말하고 시야를 넓게 갖고 큰 꿈을 가지라고 충고했다

출처 : http://www.dt.co.kr/contents.html?article_no=2011010702010660739004




실제로 사회에서 개발자로 직장을 다닌다는건 .. 학생 때와는 다르게 프로다운 마음가짐이 필요합니다.
신입일 때는 내가 못하면 위에서 봐주면서 대신 처리해주지만 갈수록 책임감이 늘어갑니다.
즉, 문제가 주어졌을 때 해결해야한다는 것이죠. 차선책이라도 꼭 만들어야 한다는 겁니다.
가정의 가장일 경우도... 책임감은 날로 늘어가면서 가정을 지키기 위해서는 문제가 있을 때마다 해결해야한다는
압박감이 큽니다. 개발자이건 아니건 문제해결능력이라는건 그사람의 역량과도 직결되는 문제이니 간과해서는 안됩니다.


Posted by 사용자 SB패밀리

댓글을 달아 주세요







.pmoffice.co.kr/data.html

1. 프로젝트 관리 소프트웨어의 필요성
Microsoft Project는 프로젝트 관리자의 업무를 지원하는 프로젝트 관리 도구입니다. 프로젝트 관리자는 Microsoft Project를 사용하여 프로젝트의 기간과 자원, 비용을 통합적으로 관리할 수 있습니다. 
프로젝트 관리자가 겪는 문제점은 계획을 체계적으로 세우지 않았기 때문에 발생하게 됩니다. 체계적인 계획은 프로젝트 관리의 기본 골격이라고 할 수 있습니다. 다음은 계획의 중요성을 나타내는 애로 체감 곡선입니다.

애로(고충) 체감 곡선 (Pain Curve)
훌륭한 기획(Good Planning)
프로젝트 관리 소프트웨어를 사용한 기획입니다. 관리 기준이 명확해지고 문제점을 분석할 수 있으므로 프로젝트가 진행되면서 팀원들의 애로 사항이 줄어 듭니다. 

잘못된 기획(Poor Planning)
프로젝트 관리 소프트웨어를 사용하지 않은 기획입니다. 명확한 관리 기준이 없으므로 프로젝트가 진행되면서 발생하는 복합적인 문제에 대처하기가 어렵습니다.

애로 체감 곡선이 시사하는 바는 바로 계획의 중요성입니다. 프로젝트 초기 단계에서 관리자가 관리 기준을 적용하기 위해서 약간의 애로 사항이 있겠지만, 초기 계획과 진행 상황의 차이를 맞추어 가면서 팀원들이 동기 부여를 받고 문제 대응 능력이 발전해 나가는 것입니다. 합리적인 계획 관리에 따른 유연한 대처는 결국 프로젝트 관리자의 애로 사항을 점차로 감소시키게 됩니다.

다시 말해서 초기 단계에 수립한 계획이 프로젝트 진행 중에도 효력을 발휘하려면, 각종 일정 및 자원 변동 사항과 문제점을 업데이트했을 때 전체 프로젝트에서 어떤 영향을 주는지 정확하게 분석할 수 있어야 합니다. 사실, 제약 조건이나 돌발 상황에 대한 분석 능력(What-if Analysis)은 프로젝트 관리자가 가지고 있는 나름대로의 판단력으로 처리할 수도 있습니다. 그러나, 모든 것이 특정 프로젝트 관리자의 머리 안에서만 처리된다면 조직 내의 다른 관리자나 팀원에게 제대로 전달되지 못할 수 있다는 것입니다. 만일 프로젝트 관리 소프트웨어를 사용한다면 이 모든 문제점을 한 번에 해결할 수 있습니다.

프로젝트 관리 소프트웨어는 프로젝트를 성공적으로 수행하기 위한 체계적인 기획과 분석 기능을 제공하는 도구입니다. 즉, 프로젝트 관리 소프트웨어를 사용할 수 있다는 것 자체가 훌륭한 프로젝트 기획자이면서 동시에 관리자가 된다는 것을 뜻합니다. 프로젝트 관리 소프트웨어를 이용하여 표준 서식 파일을 작성하면 프로젝트 관리자의 노하우를 체계화하고 이를 조직 전체에 적용하고 발전시켜 나갈 수 있습니다. 

Microsoft Project가 제공하는 쉽고 다양한 분석 기능과 공동 작업 기능을 이용한다면, 여러분들 누구나 관리 마인드를 가지고 프로젝트에 주도적으로 참여할 수 있게 될 것입니다. 이제는 더 이상 1차원적으로 입력한 고정 데이터(data)가 아니라 프로젝트의 일정, 자원, 비용을 관리 기준에 따라 입력한 전략 정보(intelligence)를 중심으로 프로젝트를 분석하고 조정하기 바랍니다. Microsoft Project는 여러분을 위한 훌륭한 솔루션이 될 것입니다.


2. Microsoft Project의 제품 구성


이전의 Microsoft Project 98과 Microsoft Project 2000은 프로젝트 관리 초보자에게는 너무 어렵고, 전문가에게는 너무 단순한 도구였습니다. 프로젝트의 규모도 중소형 프로젝트에만 적용할 수 있었으며, 관리 기법과 협업 기능에 있어서도 부족한 점이 많이 있었습니다. 

Microsoft Project 2002 버전 제품부터 사용자의 이러한 요구사항을 충분히 반영하여, 용도에 따라 제품을 선택할 수 있도록 하였습니다. 제품 특성을 이해하시고, 필요한 최적의 솔루션을 구성해 보시기 바랍니다.

Microsoft Project 제품군

1) Microsoft Project Standard 
2) Microsoft Project Professional 
3) Microsoft Project Server 
4) Microsoft Project Server Client Access License(CAL)

Microsoft Project 제품을 선택할 때 기준이 되는 사항은 다음과 같습니다. 사용자가 단독으로 프로젝트를 관리하는 프로젝트라면 프로젝트 서식을 중심으로 제품을 사용해야 합니다(Standard). 여러 관리자 또는 팀원이 공동으로 프로젝트를 관리하는 프로젝트라면 효과적으로 공동 작업 기능을 수행해야 합니다(Professional).

Microsoft Project의 유연성 있는 플랫폼을 활용하면 프로젝트 관리 정보를 조직의 모든 사람과 공유함으로써 보다 입체적이고 정확한 프로젝트 관리를 할 수 있을 것입니다(Server). 특히, 프로젝트 관리자는 조직 내에 진행되는 여러 프로젝트라도 다양하게 분석할 수 있으므로 보다 능률적이고 신속하게 업무를 수행할 수 있습니다.

각 Microsoft Project 제품은 특정 사용자 그룹의 요구 사항에 맞췄습니다. 어떤 Microsoft Project 제품이 해당 환경에 적합한지는 프로젝트 참여자들의 역할에 따라 결정됩니다.

① Microsoft Project Standard: 업무 관리자용 
Microsoft Project Standard는 Server와 연계 기능이 미약하므로 일반적으로 Word, Excel, PowerPoint처럼 사용자가 프로젝트 계획을 단독으로 계획하고 업데이트하고 분석, 보고하는 용도로 활용합니다. Microsoft Project Standard를 활용하면, 업무 관리자가 일정 및 자원을 관리하고, 프로젝트 정보를 공유하며, 결과를 분석하는 작업을 쉽고 간편하게 수행할 수 있게 해줍니다. 새로운 기능인 프로젝트 가이드는 보다 생산적이고 신속한 업무 수행을 위해 프로젝트 계획을 만들고 관리할 수 있는 마법사 유형의 과정을 제공합니다.

② Microsoft Project Professional
전사적 프로젝트 관리 환경의 프로젝트 관리자, 자원 관리자, 기획자 
Microsoft Project Professional은 Microsoft Project Standard의 프로젝트 관리 기능을 기본적으로 제공하며, 이 외에도 기업 프로젝트 관리를 표준화할 수 있는 기능을 제공합니다. Microsoft Project Professional은 Microsoft Project Server와 함께 강력한 포트폴리오 및 자원 관리 도구를 제공합니다. 
Microsoft Project Professional은 프로젝트 계획을 수립하는 핵심 도구이므로, 프로젝트 관리자와 핵심 기획 팀원들은 Microsoft Project Professional을 보유해야 합니다.

③ Microsoft Project Server: 시스템 관리자용 
Microsoft Project Server는 회사의 기존 업무 시스템과 통합하여 공동 작업 및 기업 프로젝트 관리를 수행할 수 있도록 확장성, 보안성, 유연성이 뛰어난 고급 플랫폼을 제공합니다. Microsoft Project Server는 중앙 집중화된 프로젝트 관리 사무실(PMO: project management office) 역할을 하기 때문에 기업에 하나만 있으면 됩니다. 시스템 관리자는 효과적인 프로젝트의 운영을 위해 Microsoft Project Server에 전사적 프로젝트 관리 환경을 구축합니다.

④ Microsoft Project Server CAL: 임원 및 팀 구성원용 
Microsoft Project Server CAL은 Microsoft Project Web Access를 통해 팀 구성원 및 프로젝트 관계자가 최신 프로젝트 정보에 액세스할 수 있도록 합니다. 액세스 권한이 있는 사용자는 누구든지 웹 기반 프로젝트 정보를 보고, 업데이트하고, 분석할 수 있습니다. 실시간 보고 및 시나리오 분석도구는 보다 나은 의사 결정을 위해 중요한 정보를 제공합니다.

Microsoft Project의 실시간 통합프로젝트관리 개념도

Microsoft Project가 제공하는 전사적인 프로젝트 관리 환경은 이해 관계자의 역할에 따라 프로젝트에 효과적으로 참여할 수 있는 최적의 솔루션을 제공합니다.

전사적 프로젝트 관리 체계의 구현

Microsoft Project는 1984년 DOS 버전으로 첫 선을 보인 이래 기업의 정보화 환경에 맞게 많은 진화를 하였습니다. 이전의 Microsoft Project 2000에서 선보인 Microsoft Project Central은 중앙 집중화된 데이터 베이스 환경 하에서 프로젝트 관리를 수행할 수 있도록 구현된 첫 제품이었습니다. Microsoft Project 2002 이후 버전부터는 전사적 프로젝트 관리 수행을 위해 기존의 Central이 Microsoft Server 제품으로 발전하였습니다. Microsoft Project Server는 Microsoft Project에 클라이언트-서버 작업 방식을 추가한 차세대 서버 제품입니다.

Microsoft Project Server 전사적 프로젝트 관리 체계


Microsoft Project Server 전사적 프로젝트 관리 체계

전사적 프로젝트 관리의 장점 
Microsoft Project Professional과 Microsoft Project Server를 활용한 전사적 프로젝트 관리는 기업에게 프로젝트 관리의 가시성, 자동 분석, 통제의 장정을 제공합니다.

① 가시성 (visibility) 
시각적으로 분석되지 않은 데이터는 정보로서의 가치가 적습니다. Microsoft Project를 활용하면 조직 내의 모든 프로젝트의 진행 상황과 자원별 수행도를 시각적으로 확인할 수 있습니다.

② 유연한 자동 분석 (insight) 
진행 상황 중의 작업별 또는 자원별 변동 사항이 전체 프로젝트에 미치는 영향을 실시간으로 자동 분석합니다. Microsoft Project가 제공하는 유연한 자동 분석 기능은 프로젝트 관리자가 프로젝트를 성공적으로 완수하는데 필요한 매우 객관적이고 합리적인 근거를 제공합니다.

③ 프로젝트의 통제 (control) 
Microsoft Project가 제공한 상황 예측 정보와 분석 정보를 기준으로 프로젝트를 입체적으로 통제할 수 있습니다. 프로젝트 관리자는 전략적 자원 배분으로 제한된 자원을 효과적으로 활용할 수 있습니다.

전사적 자원의 구분

전사적 프로젝트 관리를 효율적으로 수행하려면 프로젝트에 참여하는 자원들이 고유의 역할과 권한을 체계적으로 수행해야 합니다. Microsoft Project를 사용할 때의 자원 구분은 다음과 같습니다.

① 포트폴리오 관리자: 여러 프로젝트를 관리하는 관리자, 프로젝트 관리자의 상위 관리자 
② 프로젝트 관리자: 프로젝트의 계획, 실행, 통제를 책임지는 관리자 
③ 자원 관리자: 여러 프로젝트에 배정되는 자원 그룹을 관리하는 관리자 
④ 팀 리더: 프로젝트의 팀 또는 부서의 자원을 관리하는 관리자 
⑤ 자원(팀원): 프로젝트의 작업을 수행하고 보고하는 모든 인력 
⑥ 임원: 프로젝트를 관장하고 후원하는 관리자 
⑦ 고객: 프로젝트의 산출물을 받는 이해 관계자 
⑧ 계약자: 작업을 수행하는 자원 중 계약직 또는 외부 인력

전사적 프로젝트 관리를 위한 Project Professional과 Project Server의 업무 상호 관계

 

전사적인 프로젝트 관리를 효과적으로 수행하기 위해서는 Microsoft Project의 주요 기능을 자원의 역할 별로 구분하여 사용해야 합니다.


Microsoft Project 주요 특징


Microsoft Project는 기획을 담당하는 모든 사람들을 위한 도구입니다. 98, 2000을 거쳐 2003에 이르기까지 Microsoft Project는 기능적인 발전을 거듭해 오고 있지만, 변함없는 특징은 프로젝트 관리를 지원하는 도구라는 점입니다. 프로젝트 관리 전문 소프트웨어로서 Microsoft Project가 가지고 있는 특징은 무엇일까요?

1. 사용하기 쉬운 오피스 제품

기업 경쟁력 강화의 중요한 기준이 되는 프로젝트 관리의 도구는 누구나 쉽게 사용할 수 있고 기업 내외부적으로 표준이 되는 소프트웨어이어야 합니다. Microsoft Project는 Word, PowerPoint와 같은 Microsoft Office 제품군입니다. 따라서, 다른 Office 제품과 데이터 호환이 자유로우며, 사용법도 매우 유사합니다.

Microsoft Project는 Business Tool에 속하는 Office 제품이기 때문에 기업 프로젝트 실무자에게 꼭 필요한 기능들이 잘 갖추어져 있습니다. 

2. 프로젝트 다이어그램의 자동 작성

Microsoft Project에 데이터를 입력하면 Gantt 차트, 달력 및 다양한 그래프가 자동으로 작성됩니다. 사용자는 Project가 제공하는 시각적인 다이어그램을 봄으로써 프로젝트의 각 작업들의 의존 관계가 어떻게 되어 있으며 다른 요소와는 어떤 관련성이 있는지 분명하게 확인할 수 있습니다. 

3. 요주의 작업의 표시

Microsoft Project는 일정 지연에 영향을 주는 작업과 경로를 자동으로 찾아 냅니다. 이를 요주의 경로라고 합니다. 
요주의 경로 상의 작업은 항상 자동으로 차트에 붉은 색으로 나타납니다. 
프로젝트 관리자는 전체 프로젝트에서 가장 중요한 1/5 또는 1/3의 요주의 작업에 관리를 집중하여 일정을 단축시킬 수 있습니다.


Gantt 차트에 표시된 요주의 작업

진행상황 Gantt에 표시된 요주의 작업


4. 일정/비용/수행도의 자동 평가 


신호등 형식의 그래픽 표시기의 예 

Microsoft Project는 각 작업 별로 일정, 비용, 수행도 등의 진행 상황을 쉽고 정확하게 확인할 수 있는 다양한 그래픽 표시기 기능을 제공합니다.
중요한 사항을 그래픽 표시기로 나타낼 수도 있으며, 위험(risk)가 발생하면 자동으로 특정 그래픽 표시기가 나타나게 할 수도 있습니다.



일정 수행도를 자동평가하는 그래픽 표시기의 예

프로젝트 관리자는 각 팀원들이 입력한 여러 업데이트 정보를 관리자가 원하는 기준에 따라 다양한 그래픽 표시기로 실시간 확인할 수 있습니다. 팀원들이 Web Access를 통해 또는 하위 프로젝트 파일에서 입력한 업데이트 사항을 자동 반영합니다.


5. 역동적인 작업 일정 관리 (dynamic scheduling)

역동적인 작업 일정 관리 기능을 통해 관리자와 팀 구성원은 작업이나 자원의 변경 결과를 즉시 파악할 수 있습니다. 예를 들어, 작업이 일정보다 늦어진 경우, Microsoft Project는 다른 작업과 전체 프로젝트에 발생한 변경 사항의 영향을 확인합니다.


과도한 일정지연을 그래픽 표시기로 자동표시한 예


6. 프로젝트 관리의 시각적 표현 (visualization of project management)

Gantt 차트, 네트워크 다이어그램 및 기타 보기 도구와 같은 시각적 표시 도구를 사용하여 프로젝트 데이터를 표시함으로써 작업 의존 관계와 프로젝트 상태를 효과적으로 파악할 수 있습니다.

 



7. 단계별 지침 및 컨트롤

프로젝트 가이드의 제시: 언제든지 왼쪽 창에 있는 마법사 지침과 컨트롤을 사용하여 새 프로젝트를 만들고, 작업과 자원을 관리하고, 작업시간을 지정하거나 변경하고, 프로젝트 진행을 관리하고, 프로젝트 정보를 보고할 수 있습니다.




8. 다양한 보기의 지원

사용자가 입력한 일정이나 비용 정보는 편의에 맞게 여러 가지 형식의 보기로 나타납니다. 관리 기준이 적용된 다양한 보기를 사용하여 프로젝트를 여러 관점에서 입체적으로 분석할 수 있습니다.




9. 자원의 작업 시간 및 비용 관리

인적 자원 및 물적 자원을 작업에 배정하여 투입된 작업 시간과 수량을 확인할 수 있습니다. 프로젝트 관리자는 작업 시간을 투입하는 자원을 관리함으로써 일정 계획을 합리적으로 세우고 진행 상황을 통제할 수 있습니다. 수량을 투입하는 자원을 통제하면 투입 원가를 산정할 수 있습니다.




10. 필터

사용자가 원하는 정보만 편리하게 찾을 수 있습니다. 예를 들면, 마케팅 담당 부서가 자원으로 배정된 작업들만 모두 찾는다거나 특정 시기에 진행될 예정 작업들만 찾을 수 있습니다. Microsoft Project는 사용자가 실무에 활용할 수 있는 다양한 필터를 제공하며, 사용자의 필요에 따라 자주 사용하는 필터를 얼마든지 만들어 사용할 수 있습니다


특정 시기에 진행될 예정 작업들을 필터한 예


11. 그룹화

그룹화 기능을 이용하여 프로젝트 관리자는 업무나 자원들을 관리 기준에 따라 그룹 지어서 볼 수 있으며, 전체 상황을 일목요연하게 파악할 수 있습니다. 작업 또는 자원이 같은 값을 가지면 하나의 그룹에 포함되도록 지정할 수 있습니다. 그룹화 기능은 그룹 행에 하위 실행 작업들에 대한 자동 계산 또는 평가된 요약 값이 표시되므로 프로젝트 관리자가 프로젝트를 분석할 때 매우 편리한 기능입니다.


책임자별로 일정 상태를 그룹화한 서식 예

관리 분야별로 월별 예정 업무를 그룹화한 서식 예
자원 별 일정을 월 별로 그룹화한 예


12. 다양한 보고서 작성

프로젝트 관리자가 원하는 관리 기준으로 프로젝트를 가장 효율적으로 확인할 수 있는 다양한 보고서 기능을 제공합니다. 문제점을 확인할 수 있는 필터와 그룹화 기능을 적용하여 보고서를 간결하게 할 수 있습니다.


프로젝트 요약 보고서의 예

13. 프로젝트 히스토리 기록

프로젝트를 수행해 가는 과정에 입력되는 모든 정보를 히스토리로 기록하여 차기 프로젝트를 진행할 때 참조할 수 있습니다. 예를 들면, 특정 작업의 기간이나 수행도 또는 비용 등은 프로젝트 관리자가 차기 프로젝트 계획을 세우는데 중요한 근거 자료가 될 수 있습니다.

14. 이메일과 웹을 통한 의사 소통

프로젝트 진행 상황을 실시간으로 정확하게 분석하여 모든 프로젝트 이해 관계자가 공유할 수 있습니다. Microsoft Project 2002 버전에서 새롭게 출시된 Server 제품을 사용하면 프로젝트 관리자와 팀원 간에 작업 업데이트, 문서 관리, 문제점 분석, 메시징 기능을 쉽고 명료하게 수행할 수 있습니다.

15. 여러 프로젝트의 관리

여러 프로젝트 파일을 병합하면 하나의 파일로 관리할 수 있는 장점이 있습니다. 예를 들면, 규모가 큰 프로젝트는 부서별 또는 하위 프로젝트별로 일정 계획이나 비용 계획을 작성하여 상위 프로젝트에 통합할 수 있습니다. 
또는 현재 프로젝트와 신규 프로젝트를 통합하여 조직 내의 여러 일정들을 관리할 수 있습니다. 

Microsoft


Posted by 사용자 SB패밀리

댓글을 달아 주세요

MS Project : Man Month(M/M, 맨먼쓰), 작업 시간, 단위의 차이점







1. 맨먼쓰 이해하기

 

프로젝트 제안서를 작성할 때 투입 인원의 개념으로 맨맨쓰라는 표현을 많이 씁니다. 맨먼쓰를 이해하기 전에 [작업 시간]과 [단위]에 대해 알 필요가 있습니다.

 

[작업 시간]은 자원이 작업에 투입되는 예정 시간을 뜻합니다. 1일 4시간 일할 예정이면 작업 시간이 4시간이라는 뜻입니다. 달력에서 하루의[사용 가능한 작업 시간] 대비 [작업 시간]을 [단위]라고 합니다. 예를 들면 하루의 단위가 50%라면 달력 상에서 하루에 8시간 근무하기로 되어 있는데 4시간 업무가 배정되었다는 뜻입니다.

 

맨먼쓰(M/M, Man Month)는 엄밀히 men per month의 뜻입니다. 프로젝트에 투입되는 월 인원을 나타내는 숫자입니다. 프로젝트의 크기를 표현할때 주로 쓰입니다.

 

1 M/M 이면, 
1명이 한달간 하면 끝낼수 있다,
2명이면 보름이면 끝낸다는 뜻입니다.

5 M/M 이면, 
1명을 투입하면 5달 걸린다,
5명을 투입하면 한달걸린다는 뜻입니다.

각 사람의 능력은 동일하다는 전제하에 나오는 숫자입니다.

M/M는 투입되는 작업 시간의 양(How big)과 관련된 사항이며 [기간](How long)과는 다른 의미인 점을 이해할 필요가 있습니다.

 


2. MS Project에 표시하기

 

맨먼쓰는 Microsoft Project에서 [할당율]이라는 필드로 표시됩니다. Microsoft Project에서 맨먼쓰인 할당율은 [자원 배정 현황] 보기에 표시할 수 있습니다. [자원 배정 현황] 보기는 각 자원 별 작업 시간과 작업 배정 일정을 확인하고 업데이트하는 보기입니다.

 

[자원 배정 현황] 보기에서 M/M을 표시하는 방법은 다음과 같습니다.

 

1. 메뉴 모음에서 [서식 - 날짜 표시줄]을 클릭하여 날짜 표시줄의 단위를 [월]로 지정합니다.

 

2. 메뉴 모음에서 [서식 - 스타일 자세히 지정]을 클릭하여, [스타일 자세히 지정] 대화 상자를 엽니다.

 

3. 왼쪽의 [사용 가능한 필드]에서 [할당율] 필드를 선택한 후에 가운데에 위치한 [표시] 버튼을 클릭합니다. 그러면, 선택한 [할당율] 필드가 [표시할 필드] 위치로 이동합니다.

 

4. [확인] 버튼을 클릭하여 [스타일 자세히 지정] 대화 상자를 닫으면, M/M이 표시됩니다.

 

(그림 1을 클릭하면 확대된 이미지를 볼 수 있습니다.)

 

예를 들어, 한 달 22일 근무하여 [사용 가능한 작업 시간]이 176시간(22일*8시간) 근무 예정인데, 88시간 근무 예정이라면 [할당율]은 50%입니다. 박지성, 설기현처럼 개별 자원 이름을 사용한 경우, 할당율이 100%를 넘으면, 한 달내에 투입할 작업량을 조정해야 함을 의미합니다. 자원 이름이 웹디자이너, 프로그래머와 같이 일반 자원인 경우, [최대 단위]보다 [할당율]이 크면 자원의 작업량을 조정해야 함을 의미합니다.

 

맨먼쓰는 보통 프로젝트 원가 산정과 관련하여 고려되기도 합니다. 자원의 시간 당 비용을 설정해 놓으면, Microsoft Project에서는 맨먼쓰에 따른 각 자원의 비용이 자동으로 계산됩니다. 예를 들면, 개발자 사용 비용이 250만원인데, 200%의 할당율이 나오면 맨먼쓰 원가가 500만원이 나온다라고 표현합니다.

 

정리

[할당율] = ([작업 시간]/[사용 가능한 작업 시간])*100




Posted by 사용자 SB패밀리

댓글을 달아 주세요

코드 프로젝트에서 설문조사가 있었다.

개발자가 선호하는 소프트웨어 (프로젝트) 개발의 단계에 대하여 설문조사를 하였다. 

2013년 5월 13일부터 20일까지 8일간 하였는데 그 결과가 나의 어렴풋한 생각과 맞아 떨어졌다.


비단 소프트웨어 뿐만 아니라 대부분의 일에서.... 일을 벌리기는 쉬워도 일을 마무리하거나 책임지는 것 

어렵고 부담스러울 수 밖에 없다.

그러한 패러다임이 설문조사에도 고스란히 반영된 것이다.




자, 위의 설문조사 결과에서 상위 3가지와 하위 3가지를 살펴보자.

선호하는 절차는 

1. 프로젝트 설계와 아키텍처

2. 메인 개발: 정의된 프레임워크와 시동 코드

3. 프로젝트 스타트업: 첫 코드 작성


선호하지 않는 절차는

1. 유지보수

2. 배포와 설치

3. QA, 테스트와 오류 수정



뭐, 이런 생각을 안해 본 개발자는 없을 것 같다.

또, 선호하는 절차와 그렇지 않은 절차는 대체로 보수도 비례하는 것 같다.


그런데, 선호하는 절차를 이끌어 나갈려면 그만큼 노력도 많이 필요하다는 것도 알아야 한다.

요즘  스포츠에서 이슈가 되고 있는 류현진, 추신수, 이대호... 

이들 또한 조금 준비해서 지금까지 온 것은 아닌만큼

앞으로 더 나은 개발자가 되고자 한다면 자신이 선호하는 분야에 많은 준비와 끊임없는 노력이 필요할 것이라고 생각한다.





Posted by 사용자 SB패밀리

댓글을 달아 주세요

개발 프로젝트의 단계별로 나타날 수 있는 Risk
2004.01.27 16:47  

류(ryujt)   http://cafe.naver.com/codeway/15 


1. 입찰 혹은 영업 단계(Proposal Phase) 
   - 사업주 요구조건(Requirements) 이해 부족 
   - 자체 사업수행 능력의 과대평가 
   - 공기 예측의 실패 



2. 사업기획단계 (Planning Phase) 
   - 항목누락(Omissions) 
   - 업무분류체계(WBS:Work Breakdown Structure) 작성미숙 
   - 수집정보의 잘못 이해 및 적용 
   - 견적(Estimating) 기술의 선택 
   - 주요 비용요소(Major Cost Elements) 관리의 실패 
   - 사업위험(Risks) 평가 및 설정의 실패 



3. 계약 협상 단계 (Negotiation Phase) 
   - 성급한 협상 유도 
   - 협상팀의 「Win」전략에만 집중 



4. 계약단계 (Contractual Phase) 
   - 계약내용의 모순 발생(Discrepancies) 
   - RFP 요구조건과 다르게 계약추진 
   - 사업수행팀과 계약협상팀의 의사소통 부재 



5. 기획 단계 ( Phase) 
   - PM 승인 없이 사업주 요구조건 수락 
   - 사업주와의 의사소통 및 제공 자료에 문제발생 
   - 기획검토회의 미숙 
   - 기획 변경에 대한 웹사이트 개발비 영향 평가 생략 



6. 디자인/프로그래밍 단계(Design/Programing Phase) 
   - 솔루션 구매비의 상승 
   - 기획과 실제 구현 가능한 기술과의 차이 발생 
   - 노무관리의 실패 
   - 공기 지연 (단기 집중 작업, 비논리적 작업) 



7. 납품 및 검수 단계(Submission/Test Phase) 
   - 사업주/사업주측 담당자/개발자 간의 책임부재 혹은 전가 
   - Test 절차 및 Test 요원 경험 미숙

Posted by 사용자 SB패밀리

댓글을 달아 주세요

[IT/개발] 프로젝트 관련 용어 정리

두서없이 정리된 용어이다. 기본기가 있어야 더욱 더 커뮤니케이션과 실무가 쉽다.






beta version [베타 버전] 
소프트웨어를 정식으로 발표하기 전에 미처 발견하지 못한 오류를 찾아내기 위해, 회사가 특정 사용자들에게 배포하는 시험용 소프트웨어. 베타 버전은 시간이 경과하면 사용하지 못하도록 장치가 되어 있거나 정식 제품이 아님을 표시하는 문구가 표시되어 있는 경우가 많다.

Alpha Version [알파버전] 
개발 도중의 하드웨어/소프트웨어에 붙는 제품 버전. 개발 초기 단계에서 개발 기업 내 또는 일부의 사용자에게 배포하여 시험하는 초기 버전으로, 일반적으로 불안정한 상태에서 알파 시험(Alpha Test)을 거쳐 문제점을 보완 한 후 다음 단계인 베타 버전으로 진행한다.

시스템 담당자 구분
H/W담당자 : 네트워크, 컴퓨터 및 coat를 관리
Application 담당자 : 업무지원을 위해서 개발 혹은 도입된 소프트웨어 담당자
운영담당자 : 일반사용자에게 업무를 원활하게 지원할 수 있도로고 각종 주요 데이터를 관리

개발 방법론
패키지 솔루션을 적용하여 고객의 Needs에 맞도록 재구축하는 방법론.
어플리케이션 시스템을 구축하는 방법의 사례에서는 라이프사이클에 따른 업무 수행방법과 산출물을 표시하여 효율적인 개발과 유지보수가 되도록 지원하는 체계

산출물 관리방법
산출물에 대한 형상관리 대상인지 표시

reversion : 변경 전후 내용
final : 최종결과
history : 변경이력

제안서
제품설명과 고객의 현재와 미래를 기술한 문서

제품설명서
패키지 솔루션을 고객이 경영전략과 업무전략 차원에서 설명한 자료와 ITA(ISP)측면에서 설명한 자료

컨설팅
도메인 부분의 지식과 솔루션을 이용 고객의 업무효율을 증진시키는 일

형상관리
시간에 따라 문서나 소프트웨어 하드웨어의 변경을 추적하고 관리할 수 있도록 변경사유와 내용을 지속적으로 관리업무

BPR
Business Process Reengineering, 기업내 비효율적인 요소를 파악하여 업무를 재구성하여 업무효율을 높이는 경영전략

Package
비즈니스 도메인 영역의 내용을 미리 구축하여 적용시간을 단축한 소프트웨어 산출물

PI
Process Innovation, 업무 효율을 높이기 위한 업무의 간소화 재구성 추진 업무

PL
Project Leader, 프로젝트에서 PM의 영역을 지원

PM
Project Manager or Project Management, 프로젝트 관리인력 또는 방법

솔루션
고객의 니즈를 반영해 해결할 수 있는 업무 지원 방법이나 도구.
1)기대하는 기능을 구현할 수 있는 정보와 기술력
2)기대하는 기능을 수행할 수 있는 제품을 가진 경우

staff
프로젝트 지정된 담당자들

stakeholder
프로젝트에 관련된 이해 당사자들, 공급자와 고객에게 프로젝트나 결과에 관계되는 모든 사람으로 시스템 운영자도 포함

Posted by 사용자 SB패밀리

댓글을 달아 주세요


[개발/컬럼] 프로젝트관리의 현실

프로젝트 관리의 고객과 시행업체, 그리고 시행업체 내에서 부서간의 이견을 좁히지 못하고
이해관계가 얽히고 설켜서 나타나는 현실을 그림 하나로 잘 표현한 내용입니다.

Posted by 사용자 SB패밀리

댓글을 달아 주세요

두서없이 정리된 용어이다. 기본기가 있어야 더욱 더 커뮤니케이션과 실무가 쉽다.


beta version [베타 버전]
소프트웨어를 정식으로 발표하기 전에 미처 발견하지 못한 오류를 찾아내기 위해, 회사가 특정 사용자들에게 배포하는 시험용 소프트웨어. 베타 버전은 시간이 경과하면 사용하지 못하도록 장치가 되어 있거나 정식 제품이 아님을 표시하는 문구가 표시되어 있는 경우가 많다.

Alpha Version [알파버전]
개발 도중의 하드웨어/소프트웨어에 붙는 제품 버전. 개발 초기 단계에서 개발 기업 내 또는 일부의 사용자에게 배포하여 시험하는 초기 버전으로, 일반적으로 불안정한 상태에서 알파 시험(Alpha Test)을 거쳐 문제점을 보완 한 후 다음 단계인 베타 버전으로 진행한다.

시스템 담당자 구분
H/W담당자 : 네트워크, 컴퓨터 및 coat를 관리
Application 담당자 : 업무지원을 위해서 개발 혹은 도입된 소프트웨어 담당자
운영담당자 : 일반사용자에게 업무를 원활하게 지원할 수 있도로고 각종 주요 데이터를 관리

개발 방법론
패키지 솔루션을 적용하여 고객의 Needs에 맞도록 재구축하는 방법론.
어플리케이션 시스템을 구축하는 방법의 사례에서는 라이프사이클에 따른 업무 수행방법과 산출물을 표시하여 효율적인 개발과 유지보수가 되도록 지원하는 체계

산출물 관리방법
산출물에 대한 형상관리 대상인지 표시

reversion : 변경 전후 내용
final : 최종결과
history : 변경이력

제안서
제품설명과 고객의 현재와 미래를 기술한 문서

제품설명서
패키지 솔루션을 고객이 경영전략과 업무전략 차원에서 설명한 자료와 ITA(ISP)측면에서 설명한 자료

컨설팅
도메인 부분의 지식과 솔루션을 이용 고객의 업무효율을 증진시키는 일

형상관리
시간에 따라 문서나 소프트웨어 하드웨어의 변경을 추적하고 관리할 수 있도록 변경사유와 내용을 지속적으로 관리업무

BPR
Business Process Reengineering, 기업내 비효율적인 요소를 파악하여 업무를 재구성하여 업무효율을 높이는 경영전략

Package
비즈니스 도메인 영역의 내용을 미리 구축하여 적용시간을 단축한 소프트웨어 산출물

PI
Process Innovation, 업무 효율을 높이기 위한 업무의 간소화 재구성 추진 업무

PL
Project Leader, 프로젝트에서 PM의 영역을 지원

PM
Project Manager or Project Management, 프로젝트 관리인력 또는 방법

솔루션
고객의 니즈를 반영해 해결할 수 있는 업무 지원 방법이나 도구.
1)기대하는 기능을 구현할 수 있는 정보와 기술력
2)기대하는 기능을 수행할 수 있는 제품을 가진 경우

staff
프로젝트 지정된 담당자들

stakeholder
프로젝트에 관련된 이해 당사자들, 공급자와 고객에게 프로젝트나 결과에 관계되는 모든 사람으로 시스템 운영자도 포함

 

Posted by 사용자 SB패밀리

댓글을 달아 주세요

'SW 마에스트로' 연수생 구글 본사 방문… 선배들과 간담회

2011년 01월 07일

"좋은 소프트웨어(SW) 개발자의 조건은 명문대 졸업여부가 아니라 창의력과 문제에 접근하고 해결하는 능력이다.", "초가집을 수 백 채 지어봤다고 63빌딩을 건설할 수 없다. SW 개발도 우선 역량을 크게 키워야 한다."

실리콘밸리를 방문한 한국의 SW 꿈나무들에게 미국 구글 본사에서 근무하고 있는 한국인 SW 엔지니어들은 창의력을 바탕으로 더 높은 곳으로 비상해야한다고 조언했다.

5일(현지시간) 지식경제부, 정보통신산업진흥원, 한국정보산업연합회 등이 주관하는 SW 마에스트로 미국 연수의 일환으로 구글을 방문한 학생들은 직원들의 언제든 즐길 수 있는 게임기와 카페테리아 등 자유로운 업무환경을 돌아봤다. 이어진 구글 본사에서 근무하고 있는 한국인 SW엔지니어들과의 간담회에서는 선배들의 조언이 쏟아졌다.

SW엔지니어인 전지운 씨는 "코딩과 프로그래밍 능력은 물론 창의력과 문제에 접근하고 해결하는 능력이 중요하기 때문에 미국에서는 SW 개발자를 뽑는데 창의력과 문제 해결 능력 등에 중점을 두고 평가한다"며 "알고리즘과 자료구조 등이 중요한데 책만 본다고 이런 능력이 생기는 것이 아니므로 프로젝트를 하면서 문제 해결 능력을 배양해야 한다"고 말했다.

김용성씨는 "초가집을 수 백 채 지어봤다고 63빌딩을 지을 수 있는 것이 아닌 것처럼 SW 도 SW를 잘 개발하는 역량이 있는 기업에서 배워야 한다"며 "SW 마에스트로 과정을 통해 큰 프로젝트들을 진행해 보는 것도 도움이 될 것"이라고 조언했다.

SW 마에스트로 연수단 학생들은 구글의 SW 개발 여건에 많은 관심을 나타냈다.

이에 대해 김용성 구글 SW엔지니어는 "미국과 한국의 SW 개발 환경의 차이는 관리 대상이 다르다는 것"이라고 설명하고 "한국에서는 SW를 개발할 때 사람을 대상으로 관리하는데 구글 등 미국에서는 일의 성과를 중심으로 관리한다는 점이 다르다"고 말했다. 또 "구글 등 미국 기업들의 자율적인 SW 개발 환경에 대해 동경하는 이야기가 많은데 실제 일의 강도와 업무는 한국보다 더 높다"며 "이는 업무를 믿고 맡겨서 밀어주는 환경이 업무 집중도를 높여주기 때문"이라고 설명했다.
한국인 구글 SW엔지니어들은 후배 개발자들에게 문제 해결 능력을 배양하는 것이 중요하다고 입을 모아 말하고 시야를 넓게 갖고 큰 꿈을 가지라고 충고했다

출처 : http://www.dt.co.kr/contents.html?article_no=2011010702010660739004

실제로 사회에서 개발자로 직장을 다닌다는건 .. 학생 때와는 다르게 프로다운 마음가짐이 필요합니다.
신입일 때는 내가 못하면 위에서 봐주면서 대신 처리해주지만 갈수록 책임감이 늘어갑니다.
즉, 문제가 주어졌을 때 해결해야한다는 것이죠. 차선책이라도 꼭 만들어야 한다는 겁니다.
가정의 가장일 경우도... 책임감은 날로 늘어가면서 가정을 지키기 위해서는 문제가 있을 때마다 해결해야한다는
압박감이 큽니다. 개발자이건 아니건 문제해결능력이라는건 그사람의 역량과도 직결되는 문제이니 간과해서는 안됩니다.
Posted by 사용자 SB패밀리

댓글을 달아 주세요


프로젝트를 진행하기 위해서 기획단계에서부터 구현이전단계까지 스토리보드라는 것이 만들어집니다.

그러면, 이 스토리라는 것은 무엇이고 스토리보드에 필요한 것은 무엇인지 알아보자.

스토리보드란 프로젝트를 설계하는 디자인 설명서입니다. 개발 기획서가 프로젝트 개발의 청사진이라면 플로우차트는 타이틀의 인터랙션을 나타내는 것이고 스토리보드는 설계도이자 구체적인 작업지침서입니다.
스토리보드가 완성되면 디자이너는 스토리보드에 명시된 내용에 따라 화면 디자인을 하고 일러스트를 제작합니다.
프로그래머는 스토리보드를 보고 프로그램 설계를 하고 각 세부 로직을 프로그래밍하게 됩니다.
스토리보드는 프로젝트 기획이 완성되었다고 할 수 있는 산출물이며 설계 및 구현을 위한 리소스라고 할 수 있습니다.

스토리보드에 대한 더 자세한 설명이 아래 사이트에 있으니 참조하기 바랍니다.

링크 http://blog.naver.com/jooshe12/100051451581

아래 링크에는 스토리보드 작성법이 설명되어 있습니다.
링크 http://blog.naver.com/jooshe12/100051451534



쌈꼬쪼려 소백촌닭
Posted by 사용자 SB패밀리

댓글을 달아 주세요


웹사이트를 검색엔진에서 제대로 검색되게 끔 하기 위해 알아야 할 15가지 사이트맵(site map) 제작 규칙에 대하여 알아본다.

사이트맵은 사이트 전체의 메뉴구조나 페이지 분류를 설명할 수 있는 것으로 일종의 가이드라인, 지도, 안내표 라고 할 수 있습니다.
검색엔진에서 로봇이 웹사이트를 들러들러 방문해서 정보,키워드,를 가져갈 때 사이트맵이 있다면... 더 많은 정보를 로봇에게 전달할 수 있을 것입니다...

아래 링크에서 괜찮은 내용을 전달하는 것 같아서 링크를 걸어봅니다.


링크 : http://blog.naver.com/jooshe12/100051453726


쌈꼬쪼려 소백촌닭
Posted by 사용자 SB패밀리

댓글을 달아 주세요


PDF 화일입니다.


출처 : (주)네트로21 이해석님 글


좋은 정보 감사합니다.
쌈꼬쪼려 소백촌닭
Posted by 사용자 SB패밀리

댓글을 달아 주세요


스토리보드(Storyboard)란?

 

스토리보드는 멀티미디어 타이틀 개발의 설계도이며 구체적인 작업 지침서이다. 즉 멀티미디어 설계 단계의 최종 목표를 달성하기 위한 내용을 컴퓨터 화면상에 맞도록 종이 위에 구성화한 형태이다. 즉, 애니메이션과 비디오가 음악과 결합하여 어떻게 진행되는지를 명확하게 보여주기 위해 사용된다. 개발 기획서가 멀티미디어 타이틀 개발의 청사진이라면 플로우 차트는 타이틀의 인터랙션을 나타내는 것이고, 스토리보드는 멀티미디어 타이틀 개발의 설계도이며, 구체적인 작업 지침서이다.

스토리보드가 완성되면, 디자이너는 스토리보드에 명시된 내용을 가지고, 화면 디자인부터 시작하여 각각의 일러스트 데이터를 그린다. 프로그래머는 스토리보드를 보고 프로그램 설계를 하고 각 세부 로직을 프로그램 코딩하게 된다. 그러므로 스토리보드가 완성되면 타이틀 개발의 기획이 완성되었다고 말할 수 있으며 구체적인 데이터 제작만이 남게 된다. 만일 스토리보드가 잘못되어 있거나 불충분하여 중간에 개념과 로직이 바뀌면 어떤 일이 벌어질까? 그것은 말할 필요도 없이 프로그램과 그림 데이터가 그려진 것 만큼 손해를 입게 된다. 프로그램은 다시 작업을 하여야 하며, 그래픽 데이터는 사이즈와 내용이 맞지 않아 전혀 쓸모없는 것이 되어버리고 일정은 완전히 망가지게 된다.

잘못된 설계도를 가지고 작업하면 완전히 잘못된 개념의 집을 짓게 되어 기초가 무너지게 되는 것과 같다. 그러므로 스토리보드는 치밀하고 정확하게 작성되어야 한다.

 

스토리보드 작성시 체크 포인트

 

(1)    스토리보드는 누가 보아도 프로그램의 흐름과 내용을 쉽게 이해할 수 있도록 표현하는 것이 중요하다.

(2)    기술해야 할 내용은 많고 지면은 한정되어 있는 관계로 가능한 체계적이고 간략한 기호(영문 알파벳)를 써서 표현의 간결함을 꾀해야 한다.

(3)    프로젝트의 성격에 따라 효율적인 S/B 양식을 만들어 사용하는 것이 효과적이다. (예를들면 비디오가 없는 프로젝트의 경우 비디오난은 의미가 없으므로 당연히 삭제하는 것이 적당하다.또 애니메이션이 복잡한 프로젝트의 경우 칸을 넓혀 주는 것이 당연하다.)

(4)    화면 플로우차트는 화면의 전개 순서와 로직을 정확하게 이해할 수 있도록 표현하며 시작과 끝이 정확하게 표현되어야 한다.

(5)    S/B는 가능한 모듈별로 작성하여 이해의 간결성을 도모하는 것이 좋다.

(6)    각 요소는 파일의 종류에 따라 통일적이고 체계적으로 일련번호를 부여하여 전체작업의 효율성을 기하는 것이 좋다.

(7)    위치와 크기, 시간 등을 보여 주거나 실행 특성을 명기하는 것이 좋다.

(8)    스토리보드 양식자의 크기는여유있고 알기쉽게 표현하기 위해서는 A3용지가 좋으나 제작과 정상 프로그래머용, 디자이너용, 일러스트용, 원고 필자용 사운드 작업용 등이 필요하며 디버깅의 효율성을 취해서도 다량의 복사본이 필요하게 되므로 관리상 A4용지가 좋다.

(9)    계속되는 수정사항이 발견되면서, 항상 버전관리를 신속히 하기 위해서 컴퓨터상의 양식으로 만들어 관리하는 것이 편리하다.

스토리보드 작성법

 

Project:  (1)

화면주제

(3)

화면ID

(4)

화면경로

(5)

page

(2)

 

화면구성

 

(6)

화면설명

(7)

 

F/C & Logic

(8)

 

Graphic

Text

Anim./Video

Music

Effect

Narration

Function Key

 

(9)

 

 

(10)

 

(11)

 

(12)

 

(12)

 

(12)

 

(13)

 

 항목 설명 

(1)프로젝트 명

타이틀 또는 프로젝트 명(or 사이트 url)을 기입한다. 

(2)Page 번호

Page번호는 스토리보드의 단순한 일련 번호이다. 하지만 외형상 그리 중요한 의미를 갖지 않는 것처럼 보이는데 반해, 수많은 스토리보드 속에서 특정한 위치를 찾아가기 위해서나 분실시에 쉽게 번호를 체크할 수 있기 때문에 Page 번호는 빠질 수 없는 요소이다 또한, 화면 플로우차트에도 화면전환 표시로 이 Page번호를 사용한다. 이것은 흐름을 쉽게 이해하고 찾아가기 위해서다. 

(3)화면 주제

해당 화면의 내용, 용도를 이해하기 쉽게 기획자가 명기한다. 예를 들면 표지 타이틀, 메인 메뉴, 회사역사, 만든 사람들, 끝내기 등 개발 참여자 모두가 쉽게 이해할 수 있는 이름으로 짓는 것이 좋다. 

(4)화면 ID

이 화면에 해당하는 코드명이다. 플로우챠트의 프레임 명으로 표기되며, 해당 프레임의 배경 그래픽 파일명과도 동일하게 쓰인다. 예) about.html

(5)화면 경로

처음 시작되는 화면에서 현재 화면에 오기까지의 경로를 코드명으로 표시한다. 예를 들어 타이틀로그. 인트로 무비/ 메인 메뉴의 코드 순으로 표시하며, 구조가 복잡할 경우 KEY 프레임이나 현재화면이 분지되어 나온 주 메뉴화면부터 표기하여도 무방하다. 예) 홈/회사소개/회사연혁

(6)화면 구성

각 작업자가 화면의 내용과 구성을 시각적으로 쉽게 이해하도록 스케치로 표현한다. 선택 가능한 아이콘의 개수 구성물의 위치, 애니메이션이 이루어지는 지점 등을 가능한 한 정확히 묘사해야 디자이너와 일러스트레이터가 작업할 때 쉽게 이해하고 불필요한 작업상의 손실을 막을 수 있다. 

(7)화면 설명

그림이나 플로우차트로 표현하기 어려운 화면 분위기 ? 요구 사항을 글로 설명하는 부분이다. 특별히 강조되는 기획의도를 디자이너와 프로그래머에게 각인시킬 필요에서 명기하는 것이다. 애니메이션의 순서나 화면이 뜨는 순서, 특정한 부분에 대해 설명한다. 

(8)Flow Chart 와 Logic

화면 내에서 이루어지는 인터렉션을 표시한다. 화면의 시작에서 다음 화면으로 연결되는 흐름을 논리적으로 정확하게 표현한다. 사용자가 요구하는 의도에 따라 제시되는 화면의 순서나 강제적으로 표현되는 미디어들, 화면을 움직이는 조직, 연결되는 프레임을 명확히 기록한다. 

(9)그래픽

그래픽 요소는 실제로 작업에 들어가는 그래픽 데이터를 표현하는 곳이다. 배경그림, 캐릭터, 아이콘, 버튼 등 그래픽 요소를 디자이너가 작업할 수 있도록 명확히 설명하고 작업을 요구하는 곳이다. 요소의 이름은 이미 약속된 코드체제에 의해 표기되어지고, 코드명 중 중복되는 부분은 생략하여 표기하여도 좋다. 

(10)텍스트

화면에 나타나는 텍스트 내용을 적는 곳이다. 그래픽으로 처리된 제목이나 글씨는 제외하고 텍스트로서 편집 가능한 데이터는 모두 적는다 폰트의 사이즈와 내용의 길이를 고려하여 한 화면에 표현될 수 없다면 어떤 인터렉션에 의해 나타내 줄 것인지는 FlowChart에 표시되어져야 한다. 

(11)애니메이션/비디오

애니메이션과 비디오를 표시하는 곳이다. 보통 애니메이션과 비디오는 사운드와 텍스트를 포함하고 있다. 이 경우 제작하는 화면의 성격을 명확히 하고 하나의 파일로 묶어서 처리하는 것이 좋다. 비디오는 디스플레이되는 위치, 사이즈를 고려해야 한다. 애니메이션이 긴 경우 지면 관계상 다 설명할 수 없기 때문에 영역별 파일을 따로 만들기도 한다. 자세한 그래픽의 묘사는 애니메이션의 순서 등을 표기하는 경우가 있는데 될 수 있으면 최대한의 공간을 활용하여 한 페이지 안에 모든 화면 요소를 기입하는 것이 바람직하다. 

(12)사운드

사운드는 성격상 뮤직(Music), 효과음(Effect), 나레이션(Narration) 등으로 나눌 수 있다. 세가지 요소는 모두 소리라는 점에서는 동일 하지만 제작 공정에서 서로 다른 특징을 가지고 있기 때문에 서로 나누어서 표시하는 것이 좋다. 뮤직은 배경 음악과 실제 상황에서 나가는 주제곡이 있다. 음악은 작곡과 연주 과정을 거쳐 생성된다. 라이센스가 보장되면 분위기에 어울리는 음악을 선곡하여 사용하여도 된다. 효과음은 실제로 내용과 상황에 어울리는 자연음을 만들어 내는 것이 가장 좋은 방법이지만 많은 돈과 연출력이 요구되는 분야이다. 보통은 스튜디오에서 효과음 라이브러리를 활용하여 편집하거나 신디사이즈로 합성하여 만들어 사용한다. 나레이션은 대사 내용으로 스튜디오에서 성우의 목소리와 연출로 생성된다. 

(13)기능키 정의

기능키는 현재의 화면에 사용되는 특수한 목적에 쓰여지는 키를 정의하는 곳이다. 한 화면에서 특정한 키에 기능을 부여하려면 여기에 명시하면 된다. 

(14)로직(logic)

특히 게임류의 타이틀에 필요한 요소로서 게임 진행시 획득되는 점수나 보상 등의 인터렉션을 표시한다.

(15) 작성자 : 해당 페이지 스토리보드의 분식을 막고, 화면전환 표시로 사용한다.
 


. 스토리보드의

 

(1) 아동용 타이틀의

 

Project :

화면주제

메인메뉴

화면ID

MA

화면경로

LG/IN/MA

page

3

화면구성

화면 이미지

 

화면설명

기본 언어는 영어

처음 화면이 뜨면 캐릭터 해리가 나타나서 도움말을 주면서 손을 좌우로 흔들면서 선택을 대기한다.

FlowChart

 

플로우차트 그림

 

 

 

Graphic

Text

Anim/Video

Music

Effect

Narration

FunctionKey

MAG01 배경

펼친책 그림

아이콘 포함

English

Spanish

Japanese

MAC01

해리 캐릭터

MAA01

배경음악으로 앙증맞고 귀여운 춤곡

MAE01

마우스클릭시 효과음

MAN01

안녕 나는 해리야, 나하고 놀자

ESC: 프로그램 종료

F1: 도움말

 

 

(2) 어학용 타이틀 스토리보드

 

Project :

화면주제

UNIT 16 CG1 : 연주회

화면 ID

U16C1

화면경로

메인-D서브-unit16드라마-CG1

화면설명

 준식과 경미가 피아노 연주회에 가서 나란히 앉아 있는 모습. 준식과 경미만 밝게 처리되어 있고 다른 청중들은 선으로만 표현되어 있다. 대화가 시작되기 클래식 음악이 잠깐 나오는데, 준식은 졸고 있다. 준식의 콧방울이 터진다. 반면 경미는 초롱초롱 열심히 듣고 있다. 대사가 끝나고 나면 준식의 얼굴은 빨개진다.

배경id

ACGBAK.gif

화면구성

만화화면

TEXT

 

 

 

 

 

 

 

 

 

F/C

 

 

 

Video

Narration

#1 (피아노 연주회장이다. 준식과 경미는 피아노 연주를 들으며 객석에 앉아 있다 연주가 진행되는 동안 준식은 몹시 따분해한다. 주위를 둘러보다가 손을 만지작거리다가 연신 하품을 댄다. 그러다가 결국 눈을 감고 잔다. 경미는 음악에 심취해 있어서 준식이 자는 것도 모른다.)

 

경미: (상기된 얼굴로) 준식씨, 음악회 어땠어요?

준식: (당황하면서) , . 너무 감동적이었어요/

경미: (혼자 도취돼서) 전음반을 듣는 것보다 훨씬 좋아서 이런 자주 와요. 준식씨는

어떤 연주가 제일 마음에 들었어요?

준식: (팜플렛을 슬쩍 들여다보며) 라흐마니노프 3번이 제일 좋았어요. 제가 제일 좋아하는 작곡가가 라흐마니노프거든요. 아지 연주하기 어려운 곡인데 정말 잘하던데요.

경미: (의아해하며) 오늘 곡은 연주 했잖아요.

준식: (멋적어하며) 그랬나요? 사실 제가 어젯밤에 잠을 못자서……

 

Graphic

U16CG101.gif: 어두운 연주회장에 앉아 있는 경미와 준식, 준식은 반쯤 졸린표정

02:  콧방울이 올라간다.

03: 준식이 얼굴이 빨개지는 표정

 

Effect

  U16CG1E01.wav: 박수소리

 

Music

 U16CG1S01 : 피아노 연주곡 (바이올린 )

 

화면이동 기능

: 도움말            : 메인 메뉴로

: 드라마로          : 서브메뉴로

: 사전아: 종료      : 한국의 문화

CG1     CG2

A:  text보이기(한국)  B: 번역(일어)

 

 

 

 (3) 에듀테인먼트 타이틀의

 

Project :

화면주제

스테이지1(연료실기)

화면ID : ST1FO

   (스테이지1, 연료 실기를 의미)

화면경로

로고->Intro->메인메뉴->비쥬얼1->스테이지

화면내용

황량한 해왕성 지표면과 시커먼 하늘을 배경으로 아래쪽에 우주선이 있다. 앞쪽에 연료를 담은 드럼통이 늘어서있다 드럼통에는 각각의 숫자들이 찍혀있다. 마우스로 드럼퉁을 클릭하면 나레이션과 함께 드럼통이 확대되며 숫자에 대한 애니메이션이 나온다.

SCREEN

   화면의 비쥬얼적인 부분을 표시

Hypermedia

드럼통1 -1 관한 애니메이션

드럼통 2-2 관한 애니메이션

드럼통3에서 10까지 동일

Graphic/Video

G01 : 배경화면으로 해왕성 지표면에 10개의 드럼통이 나열되어 있다. 드럼통마다 1부터 10까지 숫자가 적혀 있다.

G02 : 연료 게이지

F/C

Effect

S01 : 슈퍼빽이 날아올 때의 웅장한 굉음

S02 : 연료통을 클릭한 연료가 들어가는 소리

S03 : 연료를 채운 슈퍼빽이 이륙하는 소리

Back Ground Sound(배경음악)

우주여행을 나타내는 배경음악

( : 스타워즈 배경음악)

TEXT

Hyperlink(화면이동)

  연료를 채우면 비주얼 2 진행<현재 화면에서 이용 가능한 메뉴를 의미>

  버튼 1 : 종료로

  버튼 2 : 메인 메뉴로

  버튼 3 : 도움말

  버튼 4 : 풍선도움말

로직 수치변화

 

   연료 게이지가 숫자를 클릭 때마다 10% 증가

 

 
 
출처 : 인터넷, 지식인
 
좋은 정보 감사합니다.
쌈꼬쪼려 소백촌닭
Posted by 사용자 SB패밀리

댓글을 달아 주세요


작성 : 데브뱅크 운영자 skyoh

 

먼저 스토리보드가 무엇이며, 왜 웹사이트 제작에 스토리보드를 사용하게 되었는지 부터 말씀드리려고 합니다.

 

원래 스토리보드는 영화나 TV CF, 만화, 그림등의 영상물이나 창작물을 제작할 때 사용되었던 방법으로 의뢰자와 제작자가 작품을 제작하기 전에 제작 전반에 걸친 내용을 간단하게 여러 개의 화면에 전달하고 싶은 영상을 시간적 흐름에 따라 그림으로 표현한 것이었습니다.

 

보다 구체적으로 설명하자면 제작자 또는 의뢰자가 생각하는 이미지를 시각화하는 작업으로 영화나 CF 제작에 들어가기 전에 각 장면에 대한 카메라와 피사체의 움직임을 설명, 어떤 내용을 어떻게 찍을 것인가를 그림으로 표현, 촬영에 필요한 모든 것을 미리 파악하게 해주는 일종의 설계도와 같은 것입니다.

 

의뢰자는 스토리 보드를 보고 실제 작품이 만들어 졌을 때 어떤 내용과 이미지를 갖는지 사전에 확인할수 있고, 현재 제작하려는 작품이 과연 효과적인 안인가 아닌가를 검증해 볼 수가 있습니다. 특히 영상매체 제작에는 필수적인 항목이지요.

 

그럼 웹사이트로 다시 돌아와서, 인터넷 사이트는 기존의 텍스트환경의 네트워크를 탈피하여, 웹을 기반으로 시각, 청각등의 모든 멀티미디어가 표현가능한 종합예술(?)로서의 기능을 가지고 있는 바, 일반적인 말로서의 설명과 구조적인 설명만을 가지고, 아직 제작이 되지 않은 사이트를 설명하기가 힘들어 졌습니다. 또한 어느정도의 규모만 되어도 적어도 기획자, 디자이너, 프로그래머 이 세그룹이 힘을 합해 한가지 작품을 만들어야 하며, 의뢰자의 기존 생각과도 일치 하도록 만들어야 합니다. 다시 말씀드리면 의뢰자, 기획자, 프로그래머, 디자이너, 이렇게 4가지 부류의 사람들이 아직 제작되지 않은 작품에 대해 동일한 컨셉과 이미지를 가지고 제작이 시작되어야 한다는 점입니다.

 

현재 웹기획자들은 여러분야에서 다른 전공을 가지고 일을 하다가 전업을 하게된 경우가 많습니다. 그중의 한분야가 CF나 기타 영상메체의 프로듀서를 하시던 분들입니다. 어찌되었던 만들어지는 표현의 차이일 뿐 전체를 프로듀싱한다는 점에서는 같으니 말이죠.. 이런분야에서 전업하신 기획자님들의 사이트는 그래픽이 섬세하고, 기능적인 부분에 치우치는 경우가 가끔 있다는 단점이 있기는 하지만 이분들이 스토리보드라는 개념들도 같이 가지고 들어오셔서 웹기획일에 또 한가지 중요한 툴을 갖추게 되었죠.

 

어찌되었건 웹사이트 제작에 있어서 스토리보드의 역할은 의뢰자, 기획자, 디자이너, 프로그래머가 사이트를 제작하기 전에 미리 웹사이트의 조금은 디테일한 내용을 머리속에 같은 그림으로 그릴 수 있다는 점과, 사이트의 설계도로서의 역할을 한다는 것입니다.

 

스토리 보드의 제작시점은 사이트의 초기 기획서와 견적서가 제출되고, 계약이 이루어지고, 본격적으로 일이 시작되는 시점에 가장 먼저 그리고 가장 중요한 작업이 됩니다.

 

스토리 보드가 제작되면 의뢰자에서 승인을 받아야 하는 경우도 있고, 스토리 보드 조차도 잘 이해 못하는 의뢰자라면 디자이너가 먼저 중요페이지를 보여주는 부분만 제작하여 승인을 받는 경우도 있습니다. 

 

그럼 이제 스토리보드 제작의 방법에 대해 설명드리도록 하겠습니다.

 

스토리보드의 제작은 사이트의 기획과 제작을 이끌어나가는 기획자의 성향에 따라 매우 다양한 방법으로 진행되고, 표현방법 도 아주 다양합니다. 아직 적립되지 않은 툴이라 모든 기획자가 나름대로 스토리 보드를 제작하고 있고, 모든 기획자가 다 다르다고 봐도 과언을 아닐 듯합니다. 이 이야기는 제가 지금부터 설명드릴 스토리보드 제작에 대한 방법 또한 일반적인 툴이 아니라는 말씀입니다. 사실은 저만의 방법이었으며, 저는 앞에서 말씀드린 것 처럼 방송쪽의 프로듀서나 CF계통 출신이 아닌 만큼 원래의 스토리보드는 본 적도 없습니다. 제 나름으로 사이트를 제작하기 전에 어떻게 하면 좀 더 모든 사람들이 제작완료 단계의 사이트를 상상할 수 있는 설계도를 작성할 수 있을까? 그리고, 어떻게 하면 이문서를 보고 OK한 사람이 다 만들어진 사이트를 보고 [아니 처음 말한것과 왜 다르냐]는 말을 안나오게 정확한 표현이 가능할 까를 연구한 끝에, 그리고 사이트 제작을 한건, 두건 진행하면서 쌓아온 나만의 방법입니다.

 

자꾸 이런 말씀을 드리는 것은 개인의 취향에 따라 사이트가 다르게 나오듯이 자신에게 맞는 스토리보드 제작방법이 있으니 사이트 제작 경험을 쌓으시면서 자신만의 방법을 찾으시기를 바라는 때문이며, 저의 방법이 아직은 완벽하지 않음이 많이 있기 때문입니다.

 

  

1단계. 사이트구조도 작성..

 

먼저 사이트의 구성에 대한 구조가 확립되어야 합니다. 저의 방법은 의뢰자로부터 요청된 내용, 그리고 기획자의 아이디어, 그리고 벤치마킹을 통해 추가되어야 할 부분이라고 생각되는 내용, 또한 최근 인터넷의 흐름 등등 모든 기획적인 요소가 복합적으로 작성되어 사이트의 뼈대가 만들어 집니다.

 

일단 사이트에 들어가야할 모든 내용을 나열합니다. 그리고는 내용적으로 또는 기능적으로 유사내용끼리 묶음을 만들어 갑니다. 이것이 추후 사이트 메뉴의 기본 틀로 구성됩니다. 내용과 카테고리가 많은 경우 트리구조로 엮어지기도 합니다.

 

저의 경우 트리구조로 작성된 이 사이트 구조도를 의뢰자와 작업에 참여할 프로그램머, 디자이너와의 각각 상담을 통해 완성 짓고 결정짓습니다. 첫 단추에 승인을 받지 않고 넘어가면 추후 모든 작업을 다시 하거나 곤란에 봉착하는 일들이 많아지더군요..

 

2단계. 사이트 맵 작성

 

사이트구조도가 완성되면 좀더 자세히 사이트맵을 작성합니다. 이 사이트 맵은 추후 스토리보드의 목차역할을 할 뿐 아니라 사이트 제작의 근간이 되기도 합니다. 이 사이트 맵에는 사이트에 들어가는 모든 페이지가 보여져야 합니다.

 

사이트 맵이 완성되면 그 사이트의 규모나 구조등이 완전히 결정이 되게 됩니다. 항상 반복해서 말씀드리지만 한단계 한단계를 의뢰자의 승인과 함께 같이 프로젝트에 참여하는 모든 사람들의 동의를 얻으십시오. 기획자가 프로그램, 디자인, 기획등 모든 일에 완벽하게 다 알고 있다면 몰라도, 기획자는 신이 아닙니다. 귀를 열고 많은 부분을 받아들이고, 그 다음에 주관을 가지고 결정하신 후 의뢰자의 승인을 받으세요.. 많은 부분들을 설득시키기도 하셔야 할 거고, 새로 추가되어야 하는 내용들도 많이 있을 겁니다. 처음에 완벽한 설계도 작성의 추후에 업무량을 많이 줄여 줍니다(경험).

 

많은 사이트들이 사이트 맵을 보여주고 있습니다. 이용자들의 편의를 고려하고, 이용자들이 이 사이트에서 제공하는 부분을 가장 쉽게 알 수 있는 페이지 이지요.. 여기서 만드는 사이트 맵은 일반 사이트에서 보여주는 사이트 맵과는 조금은 차이가 있습니다. 모든 페이지가 다 들어있어야 하고, 각 페이지 마다 넘버링을 하여야 합니다. 모든 페이지에 대한 넘버링은 추후 스토리보드의 목차역할을 하게 되는 것입니다. 넘버링 하는 방법은 기획자의 재량이지만 이왕이면 넘버만 보고도 어느 부분에 속하는 페이지인지 알 수 있도록 하는 것이 유리하겠지요. 알파벳약자와 숫자를 섞어 쓰는 것이 좋습니다.

 

자 사이트 맵이 완성되셨으면 이제 스토리보드를 만드실 모든 준비를 하신 겁니다. 이제는 스토리보드를 한장 한장 그려보도록 하겠습니다

 

저는 스토리보드를 만들기 전에 사이트맵을 가지고 브레인스토밍을 합니다.

브레인스토밍이란 회의 참가자들이 이견을 제시하지 않고 생각나는 모든 아이디어를 추출하는 회의를 말합니다. 이건 회의시간도 단축되고, 많은 아이디어를 끌어모을 수 있는 아이디어회의 방법중에 하나지요.

 

프로젝트에 참여하는 기획자, 디자이너, 프로그래머가 모여 브레인스토밍을 한 후 거기서 나온 것을 스토리보드를 만들 때 많이 반영도록 합니다.

 

그럼 스토리보드에는 어떤 요소들이 들어가야 하는 지를 살펴보시죠.

 

우선 그 페이지의 구성이 들어가야 합니다.

프레임을 사용하는 지 아닌지, 메뉴의 구성이 상단에 있는 지 좌측에 있는 지 어느 곳에 어떤 내용을 보여 줄 것인지 등 전체적인 화면구성을 보여 주어야 합니다. 메뉴구성을 포함한 페이지의 구성은 디자인 요소 중 아주 중요한 부분을 차지 하게 됩니다. 페이지 구성시 사용자 편의를 최우선으로 하시구요..

 

두번째로 그 페이지의 정보를 보여 줍니다.

지금 작성하고 있는 페이지의 정보를 간략하게 보여줍니다. 저장될 디렉토리, 화일이름, 페이지 title등을 기입하여 주는 것이 좋습니다. 사실 디자인을 하다보면 많은 페이지들을 카피해서 사용하게 되고 페이지의 제목(html코드상)에 소홀하게 되는 경우가 많이 있습니다. 하지만 검색엔진의 로보트가 들어온 경우 페이지의 제목이 아주 유용하게 사용됩니다. 메타네임등을 기입할 필요가 있으

면 이것도 적어 주시면 좋구요..

 

세번째로 링크정보를 보여줍니다.

페이지에 들어간 링크정보를 정리하여 적어 줍니다. 링크를 기입하는 방법은 각 페이지에 넘버를 설정하여 적어주는 경우도 있고 미리 화일네임과 디렉토리를 다 설정하여 적어주는 경우도 있습니다만 서로의 장단점이 있습니다. 물론 후자의 경우로 하는 것이 작업에 많은 도움을 줍니다만, 지면상 아주 협소해 지는 경우가 있으니 잘 생각하셔서 작업을 하세요..

 

네번째로 프로그램요소를 보여줍니다.

스크립트 기능을 사용하는 경우, ASP PHP등의 프로그램을 사용하는 경우 DB를 오픈하고 쿼리를 사용하는 경우등을 표시하고, 그 기능을 적어줍니다.

 

그리고 기타로 꼭 설명이 필요한 것을 적습니다. 어떤 부분을 작업할 때 유의해야 할 부분이나, 꼭 신경써서 만들어야 할 부분등 프로그래머나 디자이너에게 알려줘야 할 부분을 적어 줍니다.

 

이 정도면 어느정도 스토리 보드에 들어갈 부분이 정리가 되는 듯 하네요..

 

그럼 이런 많은 정보를 어떻게 하면 모든 사람이 쉽게 볼 수 있고, 스토리보드를 그리기 쉽게 할 수 있을 까요? 기획자마다 아직은 여러가지 스타일로 만들고 있습니다. 기획자 자신과 또 같이 일을 하는 팀원이 잘 이해할 수 있고, 사이트 제작을 의뢰한 의뢰자가 납득하기 쉬운 폼이라면 어떤 폼이라도 관계없겠지요? 그럼 그런 방법을 한번 알아보겠습니다. 물론 제방법이지만요.

  

 

이제 화면에다 스토리보드를 그려보도록 하겠습니다.

회원님들의 요청에 의해 지금 자료실에다 스토리보드 예제를 올려 놓았습니다.

필요하신분은 그 화일을 받아 프린트하신후 보시면서 글을 읽으시면 좀 더 쉽게 이해하실 수 있을 듯 하네요. 화일은 엑셀로 되어있는 데 이건 제가 엑셀을 잘 다루고 익숙해져서 그렇구요. 파워포인트나 다른 어떤 툴로 작업을 하셔도 아님 손으로 그리셔도 됩니다.

 

다들 잘 보이시나요? 잘 안보이신다구요.. 그럼 제가 대략적인 그림을 보여드릴께요.. 영차!!

 


 

그림이 좀 무겁네요.. 잘 보이시나요? 그래도 안보인다구요? 그럼 그림을 클릭하면 크게 보이실 거예요.. 전체창으로 보이니 불편하시죠? 그럼 그림을 오른쪽마우스로 클릭하시구요. 다른이름으로 대상저장을 누르셔서 화일을 저장하신 후보셔도 되구요.. 설명과 같이 보시려면 한장 프린트 하셔서 옆에 두고 보세요.

 

~ 자 그럼 이제 잘 보인다고 믿고 한가지씩 설명을 드리겠습니다.

 

1. 화면 제일 좌측상단에 Name란에는 화일이름을 표시하구요.. 사실 초기에 화일이름을 일일히 다 결정하지 않고 작업을 하는 경우에 페이지마다 넘버를 부여해서 사용하는 경우도 있습니다. 그런데 제가 작업을 해본 결과 화일네임을 앞장에서 말씀드렸던 사이트맵 작성하실 때 미리 다 만드시구요.. 화일네임으로 작업을 하시면 미리 링크를 걸수 있어서 좋습니다. 단지 제 방법이구요.. 편리하신 데로 하세요.

 

2. 고 바로옆에 Floder를 적는 란을 마련했습니다. 현재 작업하시는 파일의 디렉토리를 적어 주시면 됩니다. 링크를 걸 때 상대적인 주소를 사용하게 되는 경우는 이 화일이 있는 위치를 파악하고 있으 면 편리 하지요. 링크를 거는 사람에 대한 배려입니다요..

 

3. 우측상단에는 타이틀과 Meta라고 적혀있는 부분이 있지요?

Title에는 그 페이지의 제목을 적어 줍니다. html 페이지 상단에 title 코드를 넣게 되는 데 이곳에 제목을 넣게 되면 그 페이지를 열었을 때 모니터 하단에 창이 열렸다는 표시에도 표시가 되구요. 브라우저 제일위에도 보여주게 됩니다. 그리고 더 중요한 것은 메타정보들과 함께 타이틀을 가져가는 로보트들이 있습니다. 검색엔진에서 사용하는 로보트들이 사이트에 들어온 경우 모든 페이지를 읽어가서 자신의 검색사이트에 올리게 되는 데 이 때 타이틀에 제목을 안 적어 준 페이지는 제목없음으로 나오게 되지요.. 그리고 메타네임은 주로 메인페이지에 많이 적어주는 데 자세한 내용은 프로그래머나 디자이너에 맡기시구요. 메인페이지라면 적어도 메타 키워드하고 디스크립션 정도는 적어주십시오. 웹페이지들을 만들다보면 비슷한 페이지를 카피해서 사용하는 경우도 많구요. 제목에 소홀해 지는 경우가 많은 데 작은 곳에서 부터 마켓팅을 준비하시는 자세가 필요합니다.

 

아직 프린트 하신 거 가지고 계시죠? 무슨 프린트냐구요? 우쉬~

운영자(오종혁)가 스토리보드 예제 만들어 드린 거요.. 없으시면 스토리보드의 제작(5)에 가셔서 그림클릭하시고 한장 인쇄하세요. 그 거 보면서 설명 읽으시는 것이 훨씬 도움이 되실 거 같아요..

 

이 예제는 물론 눈치채셨겠지만 데브뱅크 사이트 입니다. 기존에 작업했던 거 가지고 사용할려고 했더니 보안이다 뭐다해서 공시할 수 있는 게 없네요. 사실 데브뱅크는 제가 기획, 프로그램, 디자인, 강좌 다 하거든요. 이럴때는 스토리 보드가 필요없답니다. 나 혼자하는 데 그게 왜 필요하겠어요? 머리속에 다 있고, 제 손발은 제 머리하고 연결되어 있거든요. 하지만 혼자 모든 일을 하게되는 일은 거의 없죠.. 의뢰자, 프로그래머, 디자이너와 공동컨셉을 가지고 작업을 해야되고, 사이트가 만들어지기 이전에 이미 모든 걸 공유하고, 승인이 나야 하니까요.. 그리고 만들면서도 설계도 역할을 하니 작업하면서 서로 군소리를 줄일 수 있고 작업효율도 향상되지요.

 

그래도 회원님들의 요청을 뿌리치지 못하고 운영자가 한장 그렸습니다. 그림솜씨는 없지만 예쁘게 봐 주세요..

어디까지 설명을 드렸더라? ! 메타네임.. 그럼 이번시간에는 아래부터 설명을 드리겠습니다. 페이지의 아래를 보세요.

 

4. 화면의 좌측하단에 보시면 Link정보라는 란을 마련해 두었습니다. 링크되는 곳과 링크페이지를 보여주어야 하는 데 화면에다가 다 적으면 여기저기 적다가 나중에 적을 곳이 없어서 선을 찍~빼서 적기도 하고 나중에 그것도 안되면, 문방구에 가게됩니다. 큰 종이사러~..

그래서 코드화 했습니다. 물론 제방법이지만 링크는 {}를 사용해서 Link에서 따온 약자 L을 넣고 일련번호를 넣었지요. {L01}, {L02}, {L03}이런 넘버들이 보이시죠.. 이 표시를 메인창 링크들어가는 곳에 넣으시고 그 정보는 하단에 적으시면 편리합니다. 중괄호 { 가 불편하시면 < # 등을 사용하시는 것도 좋구요. 링크정보를 적으실 때 디렉토리까지 적으시면 다른 페이지가 만들어지지 않

은 상황에서 미리 링크를 걸어 놓을 수 있지요. 하지만 미리 링크를 거신 경우에 끊어진 링크가 있는 지 수시로 확인하시고, 사이트가 다 만들어진 경우에 모두 클릭해 보시고 확인해 보셔야 합니다. 끊어진 링크는 사이트의 신뢰를 무지하게 떨어뜨리는 요인이 됩니다.

 

5. 다음은 페이지 우측하단인데요.. 요건 예전엔 안쓰다가 최근에 제가 좀 업데이트를 해서 사용하고 있는 부분입니다. Program란에는 이 페이지에 프로그램 요소가 들어있는 지 유무를 넣는 란이지요.. O, X로 넣기도 하구요. ASP, PHP로 넣기도 합니다.

그리고, DB Query란에는 이페이지에 DB에서 불러오거나 입력 또는 수정하거나 DB내용을 컨트롤 하는 쿼리를 사용하는 지 유무를 체크해 주는 란이구요..그리고 Script라고 써있는 부분은 자바스크립트나 VB스크립트가 이페이지에 사용되는지의 유무를 표시해 줍니다. 마지막으로 Image부분은 이페이지에 필요한 이미지 특히 새로 만들어야 하는 이미지의 숫자를 표시하고 있습니다.

요부분은 프로그래머나 디자이너가 스토리보드를 볼 때 이부분을 보면 대략적으로 이 페이지를 만들 때 어느 정도의 일을 해야하고 어떤 부분을 사용해야 하는지 보여주는 곳으로 일일히 내용을 읽지 않고도 어느 정도 알 수 있지요. 프로그래머나 디자이너들이 좋아하더라구요. 한번 사용해 보세요..

 

인쇄하신 스토리보드 종이 아직 버리지 마세요.. 만일 벌써 버리셨다면 스토리보드의 제작 (5)에 가셔서 또는 자료실에 가셔서 다시 한장 받아오시구요. 아참 아무리 운영자가 그림을 못그려도 그렇지 벌써 버리시다니..

 

6. 우측하단에 연결Table이란 곳이 보이시지요?

이부분은 Table기획이 끝나고 나서 스토리보드를 만드는 것이 좋다는 것을 미리 알려주고 있습니다. 프로그래머가 DB의 어떤 Table을 사용해야 하는 지를 보여주는 부분인 데, 어떤 분들은 이건 월권이다. DB설계는 프로그래머의 고유권한이다.. 라고 하시는 분들도 있을 지 모르겠습니다. 하지만 웹기획자는 사이트의 모든 부분을 기획하시는 것이 좋습니다. DB기획은 프로그램머와 같이 합니다. 사실 DB기획은 다른 강좌에서 자세하게 설명하겠지만 사이트가 성장(?)했을 때 엄청난 파급효과를 가져오는 부분으로 기획자가 미리 이 사이트가 테이블 별로 어느 시점에 어느 정도 성장할 지 각 테이블이 추후 어떻게 사용이 될지에 대한 정보를 프로그래머에게 주시고, 프로그래머와 잘 상의하셔서 Table에 대한 설계를 하셔야 합니다.

DB가 필요한 부분은 {D01}, {D02}, {D03}같은 코드를 저는 사용하고 있습니다. 메인창에 코드를 표시하고 이곳에다가 Table명을 기입하고 있지요. 프로그램작업하실 때 많이 편리하실 겁니다. 물론 사용하는 컬럼네임까지 적어주면 좋겠지만 지면 관계상 적지 않고 있습니다. DB가 중요한 사이트라면 항목을 한번 만들어 보시는 것도 좋겠네요..

 

7. 다음은 우측중간에 있는 내용입니다.

여기는 메모창입니다. 창에 각 요소마다 주석을 달아야하는 데 이곳에 적습니다. 저는 코드를 <A>, <B>, <C> 이런 형태로 사용하는 데 이건 좋으실 대로 하세요. 가나다를 쓰시던지 1234를 쓰시던지 말리지 않겠습니다. 주석을 적으실 때는 주석정보를 보실 분, 디자이너 또는 프로그래머에게 의사가 정확하게 전달될 수 있도록 하시고 간결하게 표현하시는 것이 좋습니다. 저의 경우 공간이 부족한 부분은 메인창 뿐아니라 어떤 곳이라도 테그를 달고 이곳에 적습니다. 사용하다보면 공간이 부족한 부분이 많이 생기실 겁니다. 지금 예제에도 메타 Description항목에 <J> 라는 코드가 붙어있고 그 내용이 내용의 <J>에 들어 있지요.. 이렇게 사용하시면 됩니다.

다시 한번 노파심에 말씀 드리지만 지금의 예제는 정형화 된 폼이 아닙니다. 이건 제가 사용하는 방법이구요. 이걸 힌트로 기획자님들 각자의 멋진 폼을 만드시고 같이 일하시는 프로그래머, 디자이너가 쉽게 모든 정보를 알 수 있도록 만드시면 됩니다. 그리고, 사이트의 문외한인 의뢰자가 보고도 그 페이지가 어떻게 구성될 지 알 수 있도록 하면서 빨리 작성할 수 있는 툴을 만드십시오.

 

프린트하신 페이지의 좌측 중앙부분의 넓은 창이 있지요

 

 이 곳에 이 페이지의 구성이 들어갑니다. 물론 제 방법이구요. 이곳에다가 상세한 디자인을 그리지는 않습니다. 다만 어떤 부분이 어느 곳에 들어갈지 전체 구성이 들어가지요. 디자인에 대한 컨셉을 설명하기는 하지만 실제 디자인 작업은 디자이너의 몫이라고 생각합니다.

자 그럼 하나씩 집어보면서 각 코드부분과 내용부분을 찾아 보시면 이해가 되실 듯 한데 먼저 메인창의 젤 위에 A라는 주석표시가 보이시죠. 이건 내용부분에 이에 대한 설명이 있다는 표시입니다. 내용에 보시면 A항목에 topmenu.asp삽입이라고 되어있지요.. 이 화일을 이곳에 삽입하라는 말이지요. 실제로 지금 데브뱅크 사이트의 상단 메뉴는 화일삽입으로 처리하고 있습니다. 제일 아래쪽에 주석I도 하단메뉴를 삽입하라는 내용임을 아시겠지요? 네 이렇게 표시하시는 겁니다. 쉽지요?

그리고 네모들이 보이시죠.. 작은 네모, 중간네모, 큰네모, 그건 내용을 구분해 주고 있구요. 페이지의 전반적인 구성도을 보여주고 있습니다. 이걸 토대로 디자이너는 html 테이블 설계를 하게되고 그안에 디자인들을 그리게 됩니다. 이 페이지에서는 작은 네모들은 제목들을 표시하고 있구요. 큰 네모들은 내용을 넣을 공간들을 표시해 주었습니다. 전 주로 이런 네모들을 사용하는 데 그림을 잘 그리시는 회원분들은 더 멋지게 그리시리라 생각되네요..

주석A 아래 작은 네모에 보면 주석B 표시가 있지요. ? 여기저기 많이 있네요. 주석B의 내용을 보니 배경에 이미지를 삽입하라는 내용입니다. 데브뱅크 메인페이지를 보면 제목을 보여주는 부분에 같은 이미지들이 여러개 보이죠? 바로 이것입니다. 배경으로 넣어주고 그위에 제목을 적고 있음을 알 수 있지요. 같은 내용의 주석은 이렇게 같은 주석으로 여러곳에 표시하시면 편리합니다.

지금처럼 데브뱅크 메인페이지를 보시면서, 스토리보드 예제를 보시면 좀 이해가 쉽지 않을까 하는 생각이 드네요. 이게 거기 거든요. 이 스토리보드가 실제로 어떻게 구현되는 지 한번 잘 살펴 보세요. 링크 주소들은 좀 달라지긴 했습니다만. 똑같습니다.

또 그림을 찬찬히 보시면 아까 설명드린 링크표시들 DB표시들도 보이시지요? 각 코드 번호에 해당되는 곳을 찾아가시면 사이트를 만드는 데 그 부분에서 참고해야할 내용들이 들어있지요. 함 잘 찾아 보시구요..

자 사이트에 대한 설계도 처럼 보이시나요? 이것만 보면 이 페이지가 어떻게 만들어 질 지가 보이시나요? 만일 그렇다면 전 성공한 거구요. 아니라면 이 페이지는 실패입니다.

아 그럼 간단하게(?) 스토리보드에 대한 장황한 설명을 일단 일단락 지을 시간이 된 것 같네요.. 더 발전되고 향상된 내용이 있으면 다시 올리도록 하겠습니다. 제가 스토리보드를 만드는 방법이 많이 미흡한 방법이지만 조금이나마 도움이 되셨으면 좋겠네요. 여러번 연습해 보시구요. 자신의 팀에 꼭 맞는 가장 좋은 툴을 찾아가시기를 바랍니다.


출처: 데브뱅크 대표이사 오종혁

좋은 정보 감사합니다.
쌈꼬쪼려 소백촌닭
Posted by 사용자 SB패밀리

댓글을 달아 주세요


손쉬운 소프트웨어 스케줄 관리법


글 : Joel Spolsky
번역 :

AhnLab


2000년 3월 29일 수요일

지난해 10, 미국의 북동부 지역은 어딜 가나 아셀라(Acela) 광고 천지였다. 아셀라란 암트랙(Amtrak) 워싱턴-보스턴간 노선에서 운행할 새로운 초고속열차의 이름. 끊임없이 쏟아지는 TV 광고와 전광판 광고, 도처에 나붙은 포스터들을 보면서, 누구라도 정도의 물량 공세라면 새로운 초고속열차 서비스에 대한 수요 창출에 상당히 기여했으리라 생각했을 것이다.

글쎄, 그랬는지도 모르지. 하지만, 정작 암트랙사는 이를 확인해 기회가 없었다. 아셀라 프로젝트가 계속 지연되는 바람에 상용서비스가 개시되지도 않은 상태에서 광고 캠페인만 진행되고 있었던 것이다. 어떤 회사의 신제품 시판을 한달 앞두고 제품이 우수한 평가 등급을 받자 마케팅 책임자가 했다는 말이 떠오른다. “대단한 홍보 효과야! 이럴 시장에 물건만 있었으면 얼마나 좋았을까!”

남성호르몬이 철철 넘치는 게임 업체들은 자사 웹사이트에 제품 개발이 완료되는 대로 새로운 게임이 출시될 것이라고 떠들어대기를 좋아한다. 스케줄? 스케줄 같은 필요하지 않다. 그들은 나는 게임 개발자들이니까! 하지만, 대부분의 평범한 소프트웨어 업체들에게는 스케줄이 필요하다. 로터스의 경우가 좋은 예로, 로터스사가 처음 123 버전 3.0 개발을 완료했을 소프트웨어는 당시만 해도 아직 보급 대수가 많지 않던 80286 기종의 컴퓨터를 필요로 했다. 로터스는 제품 출시를 16개월이나 미뤘고 기간 동안 8086 기종의 메모리 한계인 640K 맞춰 제품의 용량을 줄였다. 수정된 제품이 완성되었을 때엔 이미 엑셀을 시판중인 마이크로소프트사가 시장에서 16개월 정도 앞서나가고 있었으며, 무슨 가혹한 운명의 장난인지, 8086 기종은 이미 시장에서 폐물 취급을 받고 있었다!

글을 쓰고 있는 지금도 넷스케이프의 인터넷 브라우저 5.0 경쟁사에 비해 거의 2가까이뒤쳐져있다. 개발된 코드를 모두 폐기하고 처음부터 코딩을 다시 시작하는 치명적인 실수를 저질렀기 때문이다. 애시톤-테이트, 로터스, 애플사의 MacOS 등도 똑같은 실수를 저지르는 바람에 소프트웨어 역사의 휴지통(Recycle-bin) 속으로 내던져지는 신세가 되고 말았다. 사이 넷스케이프사의 브라우저의 시장점유율은 80%대에서 20%대로 곤두박질쳤지만 회사는 아무것도 없었다. 주력 소프트웨어 제품이 산산조각으로 분해되어 있는 상태에서는 달리 손을 있는 방도가 없었기 때문이다. 한번의 잘못된 결정이 넷스케이프를 자폭시킨 핵폭탄이 셈이었다. ( 자세한 내용은 Jamie Zawinski world-famous tantrum 참조한다).

그래서, 스케줄관리가필요한것이다. 거의 모든 프로그래머들이 하기 싫어하는 일이 바로 스케줄 관리다. 필자의 경험에 따르면, 대다수의 프로그래머들은 어떻게 해서든 스케줄 같은 아예 짜지 않고 버텨 보려고 든다. 스케줄을 짜는 극소수의 프로그래머들도 대부분 상사가 하라고 하니까 억지로 하고 있을 , 스케줄대로 프로젝트가 진행되리라고 믿는 사람은 상사 밖에 없다. 상사는 스케줄을 믿는 한편으로, “기한 내에 완료되는 소프트웨어 프로젝트는 없다고도 믿으며 , UFO 존재도 믿는 사람이다.

그렇다면, 아무도 스케줄을 만들려 하지 않을까? 주된 이유는 가지다. 첫째는 스케줄을 짜고 관리하는 것이 매우 골치 아픈 일이기 때문이고, 번째 이유는 아무도 그것이 그만한 수고의 가치가 있는 일이라고 믿지 않기 때문이다. 스케줄이 지켜지지도 않을 거라면 도대체 그런 수고를 해야 한단 말인가? 스케줄이란 애당초 지켜지는 법이 없고 시간이 지날수록 현실과의 괴리는 점점 커지기만 하는데, 하러 그런 헛수고를 한단 말인가?

여기, 정확하게지켜지는스케줄을만드는간단하고손쉬운방법이있다.

1) 엑셀프로그램을사용하라. MS Project 같은 거창한 프로그램을 사용하려 들지 말라. MS Project 사용자가 종속성의 문제를 해결하기 위해 많은 시간을 할애할 것이라는 가정하에 만들어진 프로그램이다. 종속성이란, 가지 작업을 진행해야 하는 상황에서 하나의 선행 작업이 먼저 완료된 후에만 다음 작업을 시작할 있는 경우를 말한다. 소프트웨어 프로젝트의 경우, 작업들간의 종속성은 너무나 당연한 것이기 때문에 굳이 수고스럽게 종속성을 추적할 필요가 없다.

MS Project 사용하는 경우에 생길 있는 다른 문제는 프로그램을 사용하다 보면 자꾸 스케줄 균형 조정 기능을 실행하고 싶어진다는 것이다. 스케줄 균형 조정에는 불가피하게 모든 작업을 재조정하여 다른 사람에게 재할당하는 과정이 포함되는데, 소프트웨어 프로젝트의 경우 이런 재조정은 말이 되지 않는다. 프로그래머들간의 호환이 불가능하기 때문이다. 가령, 리타가 작업한 코드의 버그를 존이 수정하려면 리타 자신이 수정할 때보다 시간이 일곱 배는 걸린다. , UI 담당 프로그래머에게 WinSock 관련된 문제를 해결하라고 시키면, WinSock 프로그래밍에 익숙해지는 데에만 일주일은 걸릴 것이다. 결론은 MS Project 소프트웨어 개발 프로젝트보다는 건축 공사 프로젝트에 적합한 프로그램이라는 것이다.

2) 단순하게만들라. 필자가 이용하는 스케줄 포맷은 너무나 단순해서 한번만 봐도 기억할 있을 정도다. (컬럼) 개수는 일곱 개면 된다.

개발자가 여러 명인 경우에는 개발자별로 시트를 각기 따로 만들 수도 있고, 아니면 작업을 담당하는 개발자의 이름으로 컬럼을 만들 수도 있다.

3) 하나의기능은여러개의작업으로분해하라. 여기서, 기능이란 프로그램에 추가되는 맞춤법 검사 기능 같은 것을 말한다. 실제로 맞춤법 검사 기능을 추가하려면, 프로그래머는 여러 단계의 작업을 수행하게 된다. 스케줄을 가장 중요한 부분은 바로 이와 같은 구체적인 작업들의 목록을 만드는 것이다. 따라서 다음 규칙을 명심해야 한다.

4) 코딩을직접담당할프로그래머만이스케줄을만들있다. 관리자가 임의로 만든 스케줄을 프로그래머에게 던져주고는 따르라고 말하는 프로젝트는 실패할 밖에 없다. 코딩을 직접 담당할 프로그래머만이 기능을 구현하기 위해 어떤 작업들이 필요한가를 구체적으로 예측할 있고 작업에 어느 정도의 시간이 소요될 것인가도 추정할 있다.

5) 작업단위를세분화하라. 실효성 있는 스케줄을 만들기 위해 반드시 유념해야 부분이다. 작업량은 날짜가 아니라 시간 단위로 계산해야 한다. ( , 또는 단위로 작업 기간이 계산되어 있는 스케줄은 처음부터 지킬 생각으로 만든 스케줄이 아니다). ‘작업 단위를 잘게 쪼개면 정밀한 스케줄이 나오겠지 정도로 생각하는 독자가 있을지도 모른다. 천만의 말씀! 대략적인 작업 개요를 바탕으로 스케줄을 세워보고, 다시 작업 단위를 보다 세분화하여 스케줄을 세워보면, 단순히 정밀한 스케줄이 얻어지는 것이 아니라 전혀다른결과 나온다. 완전히 다른 수치가 나오는 것이다. 어째서 이런 일이 생기는 걸까?

작업 단위를 세분화하기 위해서는 실제 코딩 과정에서 구체적으로 어떤 일들을 수행하게 것인가를 생각해보지 않으면 된다. 서브루틴을 저작하고, 이러저러한 대화상자들을 만들고, wawa 파일을 읽어내고 등등. 같은 각각의 단계에 소요되는 시간을 추정하는 것은 어렵지 않다. 프로그래머라면 서브루틴을 저작하고 대화상자를 만들고 wawa 파일을 읽어내는 작업들은 모두 해봤을 것이기 때문이다.

만일 어떤 스케줄이 적당히 얼버무린 덩어리 작업들로만 (가령, “문법 검사 기능 구현하기 ) 채워져 있다면, 이는 프로그래머가 구체적으로 어떤 일들을 하게 것인가에 대해 제대로 생각해보지 않았다는 증거다. 그리고, 어떤 일들을 하게 것인지 제대로 생각해보지 않았다면, 거기에 어느 정도의 시간이 소요될 것인지도 없다.

개별 작업에는 어림잡아 2시간에서 많게는 16시간 정도까지가 소요된다. 스케줄에 40시간(1주일)짜리 작업이 포함되어 있다면, 작업 단위를 충분히 세분화하지 않았다는 이야기다.

스케줄을 작업 단위를 세분화해야 하는 다른 이유는 그런 과정을 통해 해당 기능을 머리 속으로 설계해보게 된다는 것이다. 만일 인터넷 통합이라는 떨리는 기능에 대한 스케줄을 수립하면서 무턱대고 3주일을 배정했다면 프로젝트는 실패할 밖에 없다. 구체적으로 어떤서브루틴들을만들어내야것인가 생각해내다 보면, 기능을 명확하게규정하게 된다. 같은 단계에서 미리 계획을 세워봄으로써 소프트웨어 프로젝트와 관련된 불안정성을 크게 줄일 있다.

 

6) 최초추정시간과현재추정시간을지속적으로추적하라. 어떤 작업을 처음 스케줄에 추가할 때는 작업에 어느 정도의 시간이 소요될 것인가를 추산한 , 결과를 Orig Est (최초 추정시간) 컬럼과 Curr Est (현재 추정시간) 컬럼에 모두 입력한다. 시간이 흐름에 따라, 작업 진도가 당초의 예정보다 지연 (혹은 단축)되면, 현재 추정시간 컬럼을 필요에 따라 업데이트할 있다. 같은 방식으로 관리하다 보면, 특정 작업에 필요한 시간을 보다 정확하게 추정하는 방법을 스스로 터득할 있다. 대부분의 프로그래머들은 각각의 작업에 어느 정도의 시간이 소요되는지 모른다. 그래도 걱정할 필요는 없다. 스케줄을 지속적으로 관리하고 그에 따라 업데이트하는 , 결국 스케줄과 프로젝트 완료 시기는 일치하게 된다. (최종 납기를 맞추기 위해 일부 기능이나 항목을 잘라버려야만 하는 경우도 생길 있지만, 그와 같은 추려내기가 필요한 시점이 언제인가를 일관되게 보여준다는 점에서 스케줄의 정확성은 여전히 유지될 것이다). 필자의 경험으로 , 대부분의 프로그래머들은 일년 정도만 연습하면 스케줄 짜는 도사가 된다.

작업이 완료되면, 현재 추정시간 컬럼과 Elapsed (경과시간) 컬럼의 값이 똑같아지고 Remain (잔여시간) 컬럼의 값은 0 된다.

7) 경과시간을매일업데이트하라. 물론, 스톱워치를 들여다보며 코딩을 진행할 필요는 없다. 퇴근하기 직전에, 혹은 회사에서 밤을 새워가며 일하는 경우라면 책상 밑에 기어들어가 잠깐 눈을 붙이기 직전에, 하루에 한번만 경과시간을 업데이트하면 된다. 8시간 동안 근무했다고 가정하고 (하하!), 그날 진행한 작업들에 대한 경과시간 필드에 8시간을 쪼개서 입력한다. 잔여시간 컬럼의 값은 엑셀이 자동으로 계산해 것이다.

그와 동시에, 현재 추정시간 컬럼도 업데이트하여 변화된 현실을 반영한다. 스케줄을매일업데이트하는걸리는시간은고작2정도밖에되지않는다. 그래서 방법을 손쉬운 스케줄 관리법이라고 부르는 것이다. 빠르고 간편하기 때문에.

8) 휴가기간과휴일등도항목에포함시켜라. 1 정도 진행되는 스케줄이라면, 사이에 프로그래머들의 휴가일수가 대개 10일에서 15 정도 포함될 것이다. 스케줄의 기능 컬럼에는 휴가, 휴일 기타 시간을 잡아먹는 모든 것들에 대한 항목이 전부 포함되어야 한다. 잔여시간 컬럼의 값을 모두 더한 이를 40(1주일)으로 나누면, 휴가 모든 요소를 포함하여 작업 기간이 주일이나 남아있는지를 산출할 있고 제품 출시 일자도 계산할 있다.

9) 디버깅시간도고려하라! 디버깅은 소요시간을 추정하기가 가장 어려운 항목이다. 가장 최근에 작업했던 프로젝트를 떠올려보라. 아마도 코딩 단계에서 소요된 시간의 100% 내지 200% 해당하는 시간이 디버깅에 소요되었을 것이다. 스케줄의 기능 컬럼에는 반드시 디버깅 항목이 포함되어야 하며, 아마도 가장 값이 항목이 것이다.

스케줄 업데이트 방법은 다음과 같다. 가령, 어떤 개발자가 wawa 파일을 코딩한다고 하자. 처음 스케줄을 예상했던 최초 추정시간은 16시간이었지만, 현재까지 이미 20시간이 소요되었고 앞으로도 10시간 정도는 걸릴 것으로 예상된다. 경우, 개발자는 현재 추정시간 컬럼에 30 입력하고 경과시간 컬럼에 20 입력하면 된다.

주요 작업 단계가 완료된 , 모든 항목들의 값들을 더해보니 상당한 수치가 나왔다. 이론상으로 제품 납기를 맞추자면 몇몇 기능을 잘라내 버려야 한다. 이렇게 시간에 쫓길 프로그래머들이 가장 먼저 잘라낼 있는 기능이 바로 디버깅 항목이다. 다행히도, 처음 스케줄을 디버깅 항목에 많은 시간을 할당해 두었으니까.

원칙적으로, 개발자들은 코딩과 동시에 디버깅을 병행해야 한다. 절대로, 수정할 있는 버그를 뒤로 미뤄둔 새로운 코딩에 착수해서는 된다. 미해결 버그의 수는 가능한 최소한으로 유지해야 한다. 이유는 가지다.

1) 버그는 코딩 직후에 곧바로 수정하는 것이 가장 수월하다. 달쯤 지난 후에 버그를 수정하려고 하면, 정확한 코딩 방식을 기억하지 못하기 때문에 버그 수정도 어려워지고 시간도 많이 걸릴 있다.

2) 버그 수정은 과학적 연구와 비슷해서, 언제 새로운 과학적 사실을 발견할 있을지 정확히 예측하기 어려운 것처럼 언제 버그를 해결할 있을지 정확히 예측하는 것도 쉽지 않다. 수정해야 버그가 개나 개뿐이라면 제품 출시 시기를 예측하는 것은 어렵지 않겠지만, 미해결 버그가 수백 개나 수천 개쯤 되는 경우에는 이것들을 언제 전부 수정할 있을지 예측하기란 불가능하다.

그렇다면, 개발자가 코딩 과정에서 버그를 발견할 때마다 곧바로 버그를 수정하는데 디버깅 스케줄을 따로 만들어야 하는가? 프로그래머가 모든 버그를 그때그때 수정한다 하더라도, 작업 단계가 완료되면 불가피하게 버그 수정 과정이 필요하다. 테스트 (내부 테스트 베타 테스트) 단계에서 정말로 어려운 버그들이 발견되기 때문이다.

10) 통합시간도고려하라. 여러 명의 프로그래머가 함께 작업하는 경우, 프로그래머들 간에 서로 일치되지 않아 조정이 필요한 부분이 생기게 마련이다. 가령, 유사한 기능의 대화상자를 명의 프로그래머가 서로 다른 방식으로 구현할 수도 있다. , 여러 명의 프로그래머들이 각자 마음대로 추가한 메뉴 항목이나 키보드 단축키, 툴바 등을 누군가는 전체적으로 정리하고 통일시켜야만 한다. 사람이 코드에 체크인하는 순간 컴파일러 에러가 발생할 수도 있다. 모든 것들을 수정할 시간이 필요하며, 이는 별도의 기능 항목으로 스케줄에 포함시켜야 한다.

11) 여분의시간을포함시켜라. 시간은 모자라게 마련이다. 스케줄을 고려해야 여분의 시간(버퍼) 가지 종류가 있다. 첫째는 당초 추정했던 것보다 시간이 많이 걸리는 작업을 고려한 버퍼이고, 둘째는 관리자가 wawa 구현이 너무나도 중요해서 다음 버전으로 미룰 없다고 결정하는 경우 등과 같이, 계획에 없이 갑자기 추가된 작업을 고려한 버퍼다.

혹시라도 휴가, 휴일, 디버깅, 통합 시간 버퍼 항목 등을 모두 더한 값이 실제 작업 시간을 모두 더한 값보다 크다는 사실을 알고는 놀랄 수도 있다. 이런 사실에 놀라는 독자라면 아마 프로그래밍 경력이 아직 그리 길지 않은 개발자일 것이다. 책임질 자신이 있거든, 이런 항목들을 빼버려도 좋다.

12) 절대로관리자가프로그래머에게스케줄단축을요구해서는된다. 풋내기 소프트웨어 관리자 중에는 프로그래머들에게 빡빡한” (비현실적으로 짧은) 스케줄을 던져주는 방법으로 그들을 자극하여 작업을 보다 빨리 진행시킬 있다고 생각하는 사람들이 많다. 필자의 생각으로는 이런 식의 자극은 멍청한 짓일 뿐이다. 필자의 경우, 스케줄에 뒤쳐지면 오히려 좌절감이 생기고 의욕이 저하되며, 스케줄보다 진도가 빠를 활기도 생기고 생산성도 높아진다. 관리자는 스케줄을 심리전의 도구로 이용해서는 된다.

그럼에도 불구하고, 관리자가 스케줄 단축을 요구하는 경우에는 이렇게 대처하라. 릭의추정시간이라는 새로운 컬럼을 하나 추가한다 (물론, 프로그래머의 이름이 릭이라고 가정하고.) 프로그래머 자신이 예상하는 추정시간을 컬럼에 입력한