2009년 11월 30일 월요일

프로젝트 일정에 반영되어야 하는 하는 요소들

며칠간 글을 올리지 못하였군요.

오늘은 프로젝트 일정 수립에 직접적 영향을 미치는 요소들을 정리해 보고자 합니다.

"조엘따라하기" 란 글에서 일정은 아래와 같은 형식이라고 말씀을 드렸습니다.
 Y(일정) = F( 분석, 설계, 구현, 테스트 , 범위, 리소스, 품질 ... ) + e ( 공휴일, 휴가, ... )

위의 식에서 보면 "e ( 공휴일, 휴가, ... )" 부분이 오늘의 주제 입니다.

1. 공휴일 확인하기

프로젝트 일정중에 공휴일이 얼마나 있는 지 챙기는 것은 관리자로서는 당연히 , 기본적인 것이겠지요.

2. 경조일

프로젝트 팀원의 입장에서는 중요하므로 이 부분을 사전에 확인 해 두는 것이 좋습니다.
대체로 일정에 영향을 미치는 행사들은 다음과 같다.

 - 팀원 생일 : 조기 퇴근등이 있을 수 있으므로 당일 -1시간정도 예상하는 것이 좋다.
 - 결혼기념일 : 위와 같이 -1 시간정도 예상
 - 돌잔치 : 저녁에 하는 경우도 있고 휴일에 하는 경우도 있는데 , 평일인지 챙겨둬야 한다.
 - 결혼 : 경우에 따라서 다르지만 결혼에 따르는 휴가 기간을 일정에 반영해야 한다.
 - 제사 : 보통 저녁에 진행이되지만 지방인 경우는 반차를 내는 경우도 있으므로 확인해 두어야 합니다.
 - 출산 : 출산에 따르는 휴가기간이 길기 때문에 기간을 확인해 두어야 합니다.

3. 교육일/행사일

프로젝트 기간중에 필요한 툴이나 기타 팀원 양성 교육계획에 따른 교육일정을 확인해야 합니다.
교육일정은 변동이 많으므로 일자가 정해지지 않은 경우라 할 지라도 몇주 , 몇일 인지 확인해야 한다.

 - 팀원 개인 교육일자 확인
 - 전사, 팀단위 교육
 - 자격증 취득에 필요한 시험 : 시험은 휴일에 진행이 되는데 직전 며칠간은 영향을 미친다.
 - 프로젝트 진행에 필요한 각종 교육 : 프레임워크 , 샘플코딩 , UI툴 사용법 , 코딩가이드 기타 표준 규약 교육

4. 휴가

팀원의 휴가 계획을 사전에 수립해야 합니다.
년차가 오래된 팀원인 경우 사용 할 수 있는 휴가 기간이 상당히 깁니다.

5. 기타

 - 건강 검진일 : 반나절 내지는 하루가 걸리는 일
 - 연말정산 서류준비 : 프로젝트가 해가 바뀌는 기간에 걸리는 경우 연말정산에 필요한 서류 준비에 시간이 들어갑니다.
 - 워크샵 : 프로젝트 자체 또는 전사적인 워크샵이 진행되는 경우 불참하기 어렵습니다.
 - 유지보수 : 팀원이 책임지고 있는 시스템의 유지보수 업무, 이 부분은 언제 어떻게 발생 할 지 알기가 어렵습니다 만,과거의 자료를 기초로 대체적인 소요를 산정해두고 일정에 반영해야 합니다.
 - 면담일 : 팀원 개개인별 대상의 연봉협상 , 평가면담 등의 진행에 필요한 일정
 - 이사 : 휴가에 포함이 되지만 이사에 따르는 부대 일정이 필요함으로 챙겨 두어야 합니다.
 - 회식 : 사전 회식장소 물색과 일정잡기 , 장소예약 , 팀원 연락등의 일이 있습니다.
 - 업무 위치이동 : 프로젝트 장소를 이동해야 할 경우 상당한 시간이 소요됩니다.
 - 질병치료 : 감기등의 질환으로 통원치료가 필요한 경우의 일정


일정 산출의 실무적인 방법으로는 전에도 말씀드린 적이 있는 것 같은데, 각각의 요소를 일일 8시간으로 산정하여 전체 합계를 구한다음 며칠이 걸리는 지를 계산하는 방식으로 하시는 것이 편할 것 같습니다.

이상으로 프로젝트 일정 산출에 필요한 요소를 적어 보았습니다. 나열해보니 언제일하냐 하는 생각이 들 정도로 참 많지요.
프로젝트의 성격이 워낙 다양해서 맞지 않는 부분도 있고 , 빠진 것도 많을 것 같습니다. 다만, 위와 같은 형태로 정리를 해두고 체크리스트와 같이 확인을 하는 습관을 들인다면 , 빠뜨리는 부분이 없이 좀 더 정확한 일정 산정이 가능 할것 같습니다.

2009년 11월 24일 화요일

SW 개발일정 만들기

SW 개발일정 만들기

"개발일정 산정은 어떻게 하시나요?"  
개발 프로젝트 PM에게 이런 질문을 하면 대답이 보통 다음과 같은 대답이 돌아 옵니다.
"네, 그건 제가 개발 내용을 선임 개발자에게 전달해 주면 그 개발자가 산정해서 저에게 주게 됩니다."

선임 개발자가 일정 산정을 한다고 하니 다시 그 질문을 선임 개발자에게 물어보면 ,
"네 그건 전체 개발 내용을 기능별로 나눠서 개발자들에게 할당을 하고 그 개발자들이 일정을 산정하면 저는 그 내용을 취합해서 PM에게 알려 줍니다."

아직까지 질문에 대한 "어떻게" 라는 부분에 대한 대답은 못들은 상태입니다. 다시 한번 개발자들에게 그 질문을 하면 "네 전체 프로젝트 예상 일정이 이미 정해져 있기 때문에 저는 배당 받은 기능 리스트를 더 잘개 쪼개서 일정표에 집어 넣기만 합니다." @.@

개발일정 산정이 되려면 먼저 개발소요 산정이 되어야 합니다, 그렇지만 소프트웨어 공학이 정립된 60년대 이래 40년이 넘게 흐르는 동안 수도 없이 많은 SW개발 프로젝트가 있었지만 , 아직까지도 업계 전반적으로 개발 소요를 산정하는 표준적인 기준은 없다고 보여 집니다. 하지만 최근에는 이러한 소요산정의 기준으로 소프트웨진흥원의 FP(Function Point) 나오기도 하고 업계에서도 소요산정에 대한 고민이 있어 많은 방법들이 제시되고 있습니다.
물론 FP같은 경우는 발주자의 입장에서 초기 프로젝트 규모를 잡아보는 단계에서 사용하는 것이기 때문에 개발 일정 산정에 직접적으로 쓸 수는 없을 것입니다. 하지만 위의 문답에서와 같이 방법에 대한 아무런 근거없이 일정을 잡는 방법보다는 좀 더 과학적인 것 같습니다.
제가 늘 말씀드리고자 하는 것은 관리의 기본은 기준을 정하는 데서 시작한다는 것입니다.
개개인의 주관적인 요소가 배제된 상태에서 특정 기준에 의해서 소요를 산정한다는 것은 그렇지 않은 경우와 비교 하였을 때 관리상 전혀 다른 의미를 가질 수 있습니다.

예를들어 보겠습니다.
첫번째 , 어떤 개발자가 3개월이 걸린다고 판단한 일을 그 개발자가 3개월동안 진행하는 경우와 두번째는 어떤기준(FP)에 의해 3개월이 예상되는 일을 진행하는 경우입니다.
만일 첫번째에서 프로젝트가 4개월이 걸렸다면 "이 프로젝트는 소요산정이 잘못된 것 같아" 라는 분석이 나옵니다. 그러나 두번째의 경우는 "개발자가 일에 적응을 잘 못하거나 문제가 있는 것 같아" 라는 분석이 나올 수 있습니다. 동일한 현상에 대한 전혀 다른 원인 분석이 나오게 됩니다. 물론 이에 따른 관리 방법도 달라 질 것입니다.

제가 말씀드릴려고 하는 것의 요지도 여기에 있습니다.
프로젝트 관리자라면 일정 수립에 대한 방법을 만들어 두어야 한다는 것입니다. 그것이 FP가 되었든 아니면 자신만의 방식이 되었든 상관은 없습니다. 다만 중요한 것은 주관적인 요소를 제거하고 명확한 산출 방법을 제시할 수 있는 방법이면 됩니다.

다시 질문을 드려 볼까요.

"개발일정 산정은 어떻게 하시나요?"  

프레임워크 적용시 고려사항

프레임워크 적용시 고려사항

직전글 "프로젝트전에 개발 프레임워크는 꼭 준비해 두십시요" 에 이어지는 글입니다.

프레임워크는 애플리케이션 구축의 기본설계를 구성하여 제어 흐름을 통제하는 모듈이 그 실체가 될 것입니다.
자바같은 경우는 스트러츠, 스프링 등이 이에 해당한다고 말씀 드렸습니다.

그러면 사용자의 입력으로 부터 시작하여 출력을 얻게 되는 과정을 통하여 프레임워크의 기본 제어 제어 흐름을 살펴보고 장단점에 대하여 말씀드리도록 하겠습니다.

1. 어플리케이션의 동작순서는 먼저 사용자의 입력이 이루어지고 ( JSP1 )
2. 이 입력을 컨트롤부에 처리를 넘깁니다. ( Controller )
3. 컨트롤부는 설정파일 또는 데이터에 정의된 입력데이터 처리 클래스를 호출하게 되고. ( Class1 )
   즉 사용자의 입력에 따라서 처리하는 클래스가 결정이 된다는 것입니다.
4. 처리 클래스의 기본 메소트가 실행이 됩니다. ( perform 또는 execute 등의 이름 )
5. 처리클래스는 다시 데이터베이스 또는 파일 IO 등을 수행하고 결과값을 컨트롤부에 넘기고, ( Controller )
6. 다시 컨트롤부가 제어를 받아서 결과를 처리할 UI프로그램을 호출합니다. ( JSP2 )

위의 처리흐름에 관여하는 프로그램을 나타내 보면 다음과 같습니다.

   JSP1 -> Controller -> Class -> Controller -> JSP2

사용자 입력으로부터 최종처리까지 최소 4개의 프로그램이 관여하고 6단계의 과정을 거치게 됩니다.
위와같이 복잡한 처리 과정의 이유로 일부 개발자들이 프레임워크의 적용을 꺼리게 됩니다.
복잡해서 이해하기 어렵고 장애 발생시 디버깅이 까다롭다 등의 이유인 것이지요. 이것외에도 프레임워크 적용에는 몇가지 단점들이 있습니다.
하지만 적용에 따라 얻게 되는 장점 또한 많기 때문에 이러한 장단점을 알고 적용을 고려해 보셔야 할 것 입니다.

프레임워크 적용의 단점으로는 ,

1. 처리과정상에 반드시 프레임워크가 개입되므로 성능의 일부를 차지하게 된다.
2. 프레임워크의 개발 및 유지보수에 필요한 개발 리소스가 필요할 수 있다.
3. 개발자들이 프레임워크에 적응하는 시간이 필요하다.
4. 프레임워크 개발은 난이도가 높은 스킬을 필요로 한다.
5. 디버깅이 까다롭다.

이러한 단점을 극복하는 방법은 사전에 준비된 완성도 높은 프레임워크가 해답이라고 할 수 있다.

장점으로 본다면

1. 개발의 각 단계를 세분화하여 숙련도를 높일 수 있다.
    eg) 설계자 : 비지니스 처리에 필요한 테이블 설계와 , sql 문장 작업에 집중
         UI개발자 : 사용자 이벤트 처리 및 화면 작업에 집중
         클래스개발자 : 비지니스 로직 구현
         프레임워크개발 : 프래임워크의 성능개선 및 장애처리등의 시스템적인 유지보수

2. 일정의 예측이 가능
    개발의 가장 큰 부분이 UI개발에 있으므로 일정의 critical path는 UI에서 발생한다.
    UI 개발의 일정은 Class와의 간섭이 없음으로 개발해야 할 UI 화면의 갯수에 비례한는 특성을 가지게 된다. 따라서 UI화면 갯수를 변수로 하는 일정 예측 모델이 가능하다.
    --> 이런 일정 예측의 장점 하나만으로도 도입을 하려는 PM 또는 관리자가 있을 것이다.

3. 개발자간의 성과 측정가능
    2.에서의 이유로 개발 성과 관리가 세부적으로 가능해진다.

물론 저는 프레임워크 적용을 주장하는 쪽이기 때문에 장점에 대한 설명에 좀 더 치중을 했습니다만 , 프레임워크 적용을 꼭 해야 한다는  생각은 아닙니다. 상황에 따라서는 적용을 안하는 것이 나을 수도 있다는 것이지요.
그러나 위와 같이 모듈 형태는 아니더라도 개발 표준 규약과 같은 형태의 원시적인 프레임워크라도 꼭 사용하시기를 바랍니다.

2009년 11월 23일 월요일

프로젝트전에 개발 프레임워크는 꼭 준비해 두십시요.

프로젝트전에 개발 프레임워크는 꼭 준비해 두십시요.

프레임워크가 웹개발 프로젝트에서는 빠지지 않는 중요 요소이기는 하지만 "프레임워크가 무엇?"
이런 질문을 받게 되면 정의를 해주기 좀 어려운 부분이 있습니다. 왜냐하면 사용해 보기 전에는 그 존재와 가치를 알 수 없는 프레임워크의 특징이 있어서 그렇기도 하지만 프레임워크를 개발 소프트웨어의 일부분으로서 별도 모듈로 분리하기 어려운 점도 있어서 일 것입니다. 그러다 보니 프레임워크가 일종의 어려운 개념 설명으로 흘러 버리는 경향도 있는데 오늘은 이 프레임워크에 대한 정의와 필요성에 대하여 설명을 해볼까 합니다.

개발기술을 보게 되면 CGI , ASP , JSP 정도의 개발 방식이 주를 이루다가 PHP , COM+ , JAVA가 실무에 적용되었고 J2EE, .Net 등으로 진화, 최근에는 WEB2.0 의 하부 기술을 이루는 AJAX, RIA , XML 확장 등의 기술들이 있습니다. 그러다보니 개발 기술들이 많이 나와 선택의 폭이 넓어진 점이 있습니다.
 
다음과 같은 경우를 한 번 생각해 봅시다.
http 프로토콜을 따르는 웹개발이면 어떠한 개발 기술을 적용하든 동작이 가능하기 때문에 한편에서는 JSP만으로 프로그램 코드를 구성하고 다른 한편에서는 C# 으로 개발 또 다른 쪽에서는 JSP+Java 조합으로 개발을 하는 것이 가능합니다.  이렇게 해도 전체 시스템을 구성하는 데는 큰 문제가 없습니다. 이유는 기본 인터페이스가 http 이기 때문입니다.
하지만 이렇게 시스템을 설계, 개발하게 되면 어떤 문제가 있는지는 잘 알고 계실 것입니다.
*이러한 문제들에 대해서는 여기서 자세히 설명드리지 않겠습니다.

이러한 문제들에 대한 해결책으로, 아래와 같이 몇가지를 정해두고 개발 프로젝트를 진행하게 되는데,
개발 진행에 있어서의 규약을 정해 , 프로그램 코드에 대한 표준화를 이루는 것이 해결책이라는 것이지요.
이렇게 함으로써 개발자간의 협업이 가능하게 하고 유지보수단계에서의 비용을 낮출 수 있다고 보는 것입니다.

- UI 와 서버 프로그램은 분리 하도록 합시다.
- UI, 서버 개발 언어는 각각 하나로 합시다.
- 각 언어는 코딩가이드를 정해서 따르도록 합시다.
- 데이터베이스는 한군데서 처리 하도록 합시다.
- 로그는 특정 모듈에서만 출력합니다.

이렇게 규약을 정하는 것이 중요한 것이기는 하지만 규약의 형태로만 존재하게 되면 사실상 지키기가 무척 어렵습니다. 일정에 쫒기는 현실을 생각해 보면 이런저런 규약을 뒤져가며 개발을 하기보다는 자기가 잘하는 방법으로 그냥 하기 마련이기 때문입니다.

그래서 위의 예에서처럼 규약으로만 존재하지 않고 , 데이터베이스 모듈, 로그 모듈등을 만들고 인터페이스를 정해 프로그램 코드에서 이 인터페이스만을 사용하도록 한다면 규약을 따르는 좀 더 강력한 방법이 될 것입니다.
그래서 실무적으로는 이러한 규약들이 구현된 모듈들과 인터페이스를 프레임워크로 정의하는 것이 맞을 것 같습니다.

하지만 이런 프레임워크를 프로젝트 중에 개발 진행하기는 대단히 어렵습니다. 최근에는 스트러츠, 스프링등과 같이 잘 알려진 기본 프레임워크들이 나오고 있습니다. 개발관리 또는 프로젝트 관리를 해야 한다면 반드시 이러한 프레임워크의 중요성에 대하여 인식을 하시고 , 준비를 해 두시는 것이 좋을 것 같습니다.

향후로도 프레임워크는 애플리케이션 개발에서 매우 중요한 위치를 차지하게 될 것인데 이에 대하여는 Software House 란에 설명을 해보도록 하겠습니다.

2009년 11월 20일 금요일

한번 만들어 두면 두고두고 써먹는 아키텍처 설계서

한번 만들어 두면 두고두고 써먹는 아키텍처 설계서

1. 아키텍처 개요
1.1 시스템 범위
1.2 미들웨어
1.3 J2EE
1.4 스트러츠
1.5 EJB

2. 서브시스템 분할 방침

3. 클래스 분할 방침
3.1 시스템 내 공통 모듈 추출
3.2 배포 단위
3.1 서브시스템내 공통 모듈 추출

4. 패키징 규칙
4.1 시스템 공통
4.2 서브시스템
4.3 배포

5. 코딩규칙
5.1 기본 규칙
5.2 들여쓰기 규칙
5.3 명명규칙
5.4 범위
5.5 주석 처리

6. 예외사항
6.1 예외사항분류
6.2 예외사항을 THROW 한 경우
6.3 예외사항을 CATCH한 경우

7. 로그
7.1 로그출력형식
7.2 로그 출력 수준

8. DB 프래임워크
8.1 주요 컴포넌트
8.2 애플이케이션 이용
8.3 예외사항 처리

목차를 정리해 보았습니다.
이 내용은 두고두고 써 먹을 수 있기 때문에 Full-Set은 한 번 작성해 두시는 것이 좋습니다.

프로젝트 적합성 테스트

프로젝트 적합성 테스트


다음의 항목들은 프로젝트에 적합한 인물인지를 판단해 보는 항목들이 되겠습니다.
가벼운 마음으로 봐 주시기 바랍니다.


1. 개발에 필요한 툴에 관한 내용을 90% 이상 이해하지 못한다.

2. 묵묵히 일만하는 본인과 커뮤니케이션이 잘 안되는 개발자가 다수 있다.

3. 목적하는 시스템의 최종적인 모습이 직관적으로 떠오르지 않는다.

4. 현업(고객)과의 대화에 필요한 도메인 지식이 부족하다. ( 건설 , 금융, 증권 , ... )

5. 개발에 필요한 프래임워크가 준비되어 있지 않고, 이를 개발할 시간도 없다.

6. SRS 가 완료 되기전에 이미 개발 일정이 정해진 프로젝트이다.


상기 항목에서 두가지 이상에 해당하는 분들은 해당 프로젝트에 적합하지 않다고 판단되는 경우이므로 개인적으로나 회사로 봐서나 과감하게 프로젝트에서 빠지는 것이 낫겠습니다.
이럴 경우 병원을 이용하는 통상적인 방법에서부터 외국으로의 망명까지 다양한 방법이 있습니다. ^^;

PS) 세가지 이상인 경우는 심각히 고려해 보시기 바랍니다.

효율을 최대화 할 수 있는 SW 개발 조직이 되려면 #1

효율을 최대화 할 수 있는 SW 개발 조직이 되려면 #1

SW Lifecycle 단계별로 어떤 개발이 되어야 하는 지 정의가 잘 되어야 겠지요. 아래 처럼요.

   Waterfall Model

   분석
      - 시스템 환경분석
      - 연동분석
      - Technical Issue 도출
      - 업무 프로세스 분석
      - 사용자 정의
      - 요구사항 명세서 ( SRS ) 작성
      - 데이터 모델링

   설계
      - 테이블설계, 데이타 표준 정의
      - UI 설계
      - UI Control 동작 정의
      - SQL 작성
      - DataSet 명칭 정의
      - 파라미터 , Action 설계
      - 공통 요소 정의 ( .js , .java )
      - 코딩 표준 정의
      - Chart 요소 정의
      - Technical Issue 정리
      - Error 처리 정의
      - e-Mail 처리 정의
      - Business Logic 처리 정의 , Class 구조 정의
      - HTML 구조정의 ( 메뉴 , Footer , js 파일 처리 등 )

   디자인
      - 스타일 가이드 정의
      - HTML 코딩 가이드
      - HTML 파일명, 폴더구조 정의
      - Flash 요소 정의
      - Chart  요소 정의
      - CSS 적용 정의

   구현
      - JSP , Java 프레임워크 코딩
      - HTML 수정
      - 개발테스트

   테스트

   유지보수

SQL where절 처리법

SQL where절 처리법

이 번에는 이러한 SQL을 사용함에 있어 프로그램 코드와 SQL을 좀 더 효율적으로 만드는 방법을 설명해 보겠습니다.

최근의 여러 애플리케이션 프레임워크들에서 SQL은 프로그램과 분리가 되어 있습니다.
SQL 코드를 프로그램 코드 밖으로 분리시키는 이유는 먼저 프로그램 개발자와 초기 SQL 작성자가 다른 경우가 대부분이고 두번째는 SQL은 프로그램보다 잦은 변경이 예상되기 때문에 이를 프로그램 코드와 분리하면 SQL변경에 따른 프로그램 재컴파일등의 번거러운 작업을 줄일 수 있기 때문에 장점이 많다고 할 수 있습니다.

이렇게 SQL을 프로그램 코드와 분리하는 경우에도 where 절 처리 부분은 여전히 까다로운 점으로 남게 됩니다.
예를들어 보면,
먼저 검색조건이 있다고 가정하고 이 검색조건에는 날짜 필드 (date) 와 아이디 (id) 필드 두가지 조건이 있습니다. 이러한 검색 조건에 따른 SQL where 문 작성은 아마 다음과 같을 것입니다.

select * from table_name where date = ? and id = ?

문제는 date 또는 id에 아무런 값이 없을 경우가 있기 때문에 SQL을 수행하기 전에 프로그램에서는 date 또는 id 가 null 값인지를 확인해야 된다는 것입니다. 왜냐하면 where 문에 null 이 들어가게 되면 결과가 제대로 나오지 않기 때문입니다.

where date = null and id = 'aaa'  이렇게 될 경우 데이터베이스의 null 지원 여부에 따라 결과가 달라집니다.

이런 경우를 막아야 되기 때문에 SQL 문장을 수행하기 전에는 프로그램 코드에서 반드시 if date == null 등으로 확인을 해야 하고,  만약 date가 null 인 경우에는 where 문은 다음과 같이 바꿔서 수행 해 주어야 합니다.

where id = 'aaa'  

마찬가지로 id가 null 인 경우도 처리해 줘야 합니다.

where date='20091108'

그래서 2가지 검색조건을 처리해 주기 위해서는 결국 3가지 종류의 where 문이 필요하게 됩니다.

where date=? and id=?
where date=?
where id=?

각각의 상황에 맞게 where 문을 조립해줘야 되는 번거러운 코딩작업이 들어가야 된다는 것입니다.
문제는 검색조건이 좀 더 복잡한 경우 대단이 성가신 코딩 작업이 되지 않을 수 없다는 것입니다.

극단적인 예로 20개의 검색조건이 들어가는 경우를 한 번 생각해 보시면 가능한 조합이 얼마나 많겠습니까.
또한 위에서 언급한 SQL 코드가 프로그램 코드와 분리가 된 상황에서는 프로그래머가 느끼는 SQL 난이도는 엄청날 것입니다.

프로그램 코딩의 대부분의 시간이 이런 작업에 소요되는 현실이 많기 때문에 이에 대한 개선은 실무적으로도
대단히 중요한 의미가 있을 것입니다.
그래서 이러한 문제를 파악하고 개선의 방법을 생각해 보았는데 , 아래는 그에 대한 설명입니다.

기본적인 아이디어는 위의 예에서와 같은 검색의 경우라도 SQL 문은 하나만을 사용할 수 있는 방법은 없는가 하는 것입니다.

대부분의 데이터베이스에서는 ANSI SQL 외에도 Null Value 관련 내장 함수들을 가지고 있습니다.
데이터베이스에서 null 값을 체크하는 것이지요.

위의 두가지를 조합해 보니 아래와 같은 SQL 문장으로 해결이 될 것 같습니다.

select * from table_name where date = ifnull ( ? , date ) and id = ifnull ( ? , id )

위의 SQL에서 만약에 date 값에 null 이 오게 되면 "ifnull ( ? , date )" 부분이 date 가 됩니다.
그래서 SQL 수행시에는 아래와 같이 됩니다.

select * from table_name where date = date and id = '20091108'

여기서 date = date 부분이 항상 참이 되기 때문에 위의 문장은 아래의 문장과 동일한 결과가 나오게 됩니다.

select * from table_name where id = '20091108'

where 절에 들어가는 여러가지 경우를 생각해 보니 아래의 다섯가지 정도로 요약이 되는데 각각에 대한 설명을 해보겠습니다.

1. 지정문( = )

    WHERE a = ifnull( ? , a ) and b = ifnull( ? , b ) and c = ifnull( ? , c )
   a 에 null 이 들어오는 경우 where 문은 다음과 같다.
    WHERE a = a and b = 'b' and c = 'c'
   여기서 a = a 라는 부분은 항진으로 처리되므로
    WHERE b = 'b' and c = 'c' 과 동일한 결과를 가져온다. b , c 가 null 인 경우대해서도 결과는 동일하다.

2. BETWEEN a AND b

    WHERE sql_name between ifnull( ? , sql_name ) and ifnull( ? , sql_name )

    a = null 이 된다면
    where a between a and 'b' 이 된다.
 
3. 부등호 ( < , > )

    WHERE sql_name < ifnull( ? , 'field_max' )
    WHERE sql_name > ifnull( ? , 'field_min' )

4. LIKE
    WHERE sql_name like '%' || ifnull( ? , '' ) || '%'

5. IN
    WHERE sql_name IN ( ifnull( ? , 'sql_name' ) , .... )

where 문을 구성하는 요소는 위의 다섯가지 경우가 아마 대부분 일 것입니다.
그리고 이를 이용한다면 위에서 잠깐 나왔던 20개의 검색조건 SQL은 다음과 같이 where 문이 구성 될 수 있을 것이다.

where a1=ifnull(?,a1)
   and a2=ifnull(?,a2)
          .......
   and a20=ifnull(?,a20)

이젠 더이상 SQL where 문을 이리저리 조합하는 머리 아픈 코드는 없애도록 해봅시다.

조엘따라하기 #3

조엘따라하기 #3

이 번글이 조엘따라하기의 마지막이 될 것 같습니다.

지난 #1번 글에서는 일정관리의 필요성에 대해서 설명을 드렸고, 2번 글에서는 일정관리의 방법에 대하여 말씀을 드렸고 , 오늘은 마지막으로 지난글에서 설명드린 Time_Table을 사용하게 되면 어떤 장점들이 있는 지 설명을 해보겠습니다.

관리라는 것은 아주 일반적으로 말씀드려서 안정된 상태에 대하여 어떤 변화를 주기 위한 또는 그러한 변화에 대한 대응 방안을 마련하는 것이라고 할 수 있습니다.
전략 경영에서는 이렇게 정의 하더군요. Operation 을 Strategy 에 맞추는 모든 활동이 Management.
관리자는 지각 체크하는 사람이 아니란 것이죠. ^^;

Time_Table은 프로젝트 일정에는 많은 변수가 있으므로 이러한 변수들을 한번에 모아서 총량 개념으로 관리하는 것이라고 할 수 있는데 Time_Table을 이용하면 프로젝트 일정은 최초 예측치로부터 정해집니다.
처음에는 이 최초 예측치는 현재 예측치와 동일하지만 몇가지 단계를 진행하게 되면 이 최초 예측치와는 다른 현재 예측치가 나타나게 됩니다. 즉 변화가 발생하는 것이지요. 이럴 때 Time_Table을 이용하면 첫번째 장점인 "정확한" 관리가 가능합니다.

예를 들겠습니다.
분석 단계가 완료되었는데 몇가지 이유로 3주의 기간이 더 들어간 상태로 완료가 되었습니다. 즉 SRS ( Software Requirement Spec. ) 작성이 최초 예측 일정보다 현재 예측 일정이 3주가 많아 졌다는 것입니다. PM은 어떻게 해야 될까요.
대부분의 PM이라면 분석 단계에서 3주가 지연된 상태라면 직감적으로 일정에 대한 어떤 변화가 올 지는 알게 될 것입니다.
하지만 이 단계에서는 직감의 수준이지 대안을 마련할 수 있는 정량화가 어렵습니다. 그래서 그냥 다음 단계로 넘어가서 보자는 경우도 생기게 됩니다. 하지만 이렇게 되면 초기에 간단히 해결 할 수 있는 문제를 발견하지 못하고 일을 크게 키우는 경우가 발생 할 수 있습니다. 역설적으로 PM이
리스크를 키우게 되는 셈입니다.

Time_Table의 경우는 어떻게 하나요,
먼저 분석 단계에 대한 결과가 다음 단계들에 어떠한 영향을 미치는 지 Table을 이용하여 파악합니다.
분석 이후의 설계 단계가 늘어날 수 도 있고 , 구현 단계가 줄어들 수도 있습니다. 개발자, PM이 모여 현재 시점에서 향후의 예측치를 모두 업데이트 해야 합니다. 그리고 다시 현재 예측치에 기반한 일정을 산출합니다. 이 일정이 프로젝트 일정과 어떻게 되는 지 비교를 합니다.
결과에 따라서 3주의 지연이 발생 할 수 도 있고, 아니면 더 길어 질 수 도 있습니다. 그렇지 않으면 분석기간은 늘었지만 다른 기간이 줄어들어 일정이 줄어 들 수도 있습니다.
만일 이번 경우의 예에서처럼 3주의 분석기간 지연 후에 다시 예측을 해보니 설계에서 4주, 구현에서 2주의 추가적인 지연이 예상되었습니다. 다른 조치가 없다면 전체 일정이 3 + 4 + 2 = 11 주의 전체 일정 지연이 예상된다는 것입니다. 프로젝트 관계자들이 모여 대책을 위한 협의를 진행해야 합니다.
설계 이후의 단계에서 개발자를 늘리는 방법등이 고려 될 것입니다. ( 이 부분은 "설계를 고정하여 변수를 줄여라" 편을 참조해 주시기 바랍니다. )
여기서 보시면 "현재 상태로는 11주 지연예상 , 일정 준수를 위해서는 개발자 00명이 어떻게 지원 되어야 한다"는 내용이 있습니다.
이러한 내용을 가지고 대책을 세우는 것과 직감적으로 대처하는 것은 시간이 지날 수록 비교 할 수 없는 차이가 나게 됩니다.

두번째 장점으로는 개발의 효율성을 높일 수 있습니다. 어찌 보면 이 장점이 가장 중요한 점일 수도 있겠습니다.
개발자간의 업무처리 속도 차이는 분명히 있는 것 같습니다. 어떤 자료를 보면 20배 까지도 된다 라고도 하는데 무슨 기준인지는 잘 알 지 못하겠습니다. 다만 이런 속도의 차이는 무시하고 최초 업무 배분을 고집하게 되면 전체적인 효율이 떨어지게 됩니다.
프로젝트 진행중에 Time_Table 상에서 속도가 나는 개발자를 확인해 볼 수 있는데 , 이런 경우 현재의 속도를 기준으로 현재 예측치를 다시 업데이트 해 줍니다. 그리고 남은 시간을 이용하여 Critical Patrh 상의 다른 업무을 지정하여 맡길 수가 있을 것입니다.
단, 이런 것이 가능하기 위해서는 반드시 개발자간의 업무 연관성이 없도록 업무를 배분 할 필요가 있고 이를 위해서는 프래임워크 적용과 같은 SW 개발상의 테크닉을 적용 할 필요가 있습니다.

세번째는 프로젝트 진행중과 후에 개발자의 평가에 활용 할 수 있다는 점입니다.
프로젝트가 잘못 되어도 원인을 제대로 찾지 못하거나 엉뚱한 이유를 찾으려는 경우가 허다한데 , 인사관리의 관점에서 보면 실무적으로 중요한 점이 아닐 수 없습니다.
Time_Table을 이용하면 프로젝트 중간에 개발자간의 업무처리 상태를 확인 할 수 있습니다. 지속적으로 잘해내는 사람이 있는가 하면 들쭉날쭉하는 경우도 있고 기대에 미치지 못하는 경우도 있습니다.
이러한 개발자 평가는 프로젝트 종료 후에 최종적으로 산출하여 다음 프로젝트에 반영 할 수도 있고 개인 평가에 활용할 수 도 있을 것입니다.
관리측면에서 본다면 이러한 객관적인 사실 기준의 평가가 개발자들이 느끼기에도 공정하다고 생각 할 것입니다. 평가가 주관적이라면 이에 불만을 가지게 될 것이고 향후 프로젝트에 마이너스 요인이 될 가능성이 많기 때문입니다.
평가에 활용 될 수 있는 지표는 조직에 맞게 개발이 필요한데 , 예를들면 Time_Table상의 마일스톤 준수율과 일정 준수율 될 수 있을 것이고 , 계획대비 ( 최초예측치 ) 수행업무의 양도 성과 평가의 좋은 지표가 될 것으로 보입니다.

이상으로 "조엘따라하기" 편을 모두 마치도록 하겠습니다.

SW 개발 프로젝트 관리자는 프로젝트 변화 요인들에 대한 향후 대책을 세울 수 있어야 한다.

조엘따라하기 #2

조엘따라하기 #2

지난글 "조엘따라하기 #1" 에 이어지는 내용입니다.

지난글에 설명드린 내용 일정의 예측 방법들에 대한 것들을 가지고,
실무에 어떻게 적용하여 프로젝트 일정을 관리 할 것인가 ?
실무에 적용을 하기위해서는 적당한 관리 툴이 있으면 좋을 것인데 많이들 사용하는 MS-Project 는 여기에 맞지 않았고,
여기저기 찾던 중 조엘의 Time Table 이 눈에 들어왔습니다.

여기서는 먼저 일정을 크게 4가지로 나누는데 다음과 같습니다.

최초 예측치 / 현재 예측치 / 현재 진행치 / 잔여치

이 내용을 보면서 들었던 생각은 프로젝트의 진행에 따른 변화를 2번을 통해서 계속 업데이트 한다면 정확한
일정관리가 가능하지 않을까 하는 점이다. 다만 매일 또는 주기적으로 업데이트를 해줘야 한다는 번거러운
점이 있는데 그 정도는 감수 할 수 있지 않을까 하는 생각에 팀원들의 동의를 얻어 실제 프로젝트에 적용을 하기로 하였다.
* 팀원들 동의를 얻는 부분이 좀 어려웠습니다. 조그마한 변화에도 민감한 개발자들이 많은 지라....

적용을 위해서는 먼저 항목들에 대한 이해가 필요합니다.

1. 최초 예측치 : 프로젝트 진입 시점의 일정 예측치
2. 현재 예측치 : 현재 시점의 일정 예측치
3. 현재 진행 : 현재 시점까지의 일정 진행 ( 확정치 )
4. 잔여 일정 : 현재 예측치 - 현재소요

1,2 번 항목은 프로젝트 초기와 비교하여 현재 시점까지 일정에 어떠한 변화가 있었는 지 알 수 있도록 해줍니다.
2,3 번의 차이가 4번 항목이 되는데 현재 날짜에서 잔여 일정을 합치게 되면 현재 시점의 예상 일정이 됩니다.

다음으로 엑셀을 이용하여 이 항목을 열로 구성을 합니다. 물론 4번 항목은 2 -3 의 수식으로 됩니다.
그리고 각 행은 WBS 항목들로 채워 넣고 최초 예측치 부분에 WBS 항목별 예상 소요일수를 입력합니다.
그렇게 되면 아래와 같이 될 것입니다. ( 2009년 수행 프로젝트 예 입니다. )


개발자들이 매일 업데이트 해야 하는 부분은 Elapsed ( 현재 진행) 입니다.
물론 어떤 변화에 의해서 현재 예측치 (Curr Est) 를 변경해야 하는 경우에는 PM, 개발간의 협의를 거쳐서 이 부분을 변경하게
됩니다. 우측의 완료일자는 그 단계가 완성된 날짜를 의미합니다. 프로젝트가 설계 단계인 경우 분석 단계의 항목들은
완료일자가 입력이 되어 있게 됩니다. 그리고 항목에 들어가는 숫자는 시간입니다.
앞에서 팀원들 동의를 얻기에 어렵다고 했던 부분이 있었는데 바로 이 항목의 값이 시간으로 되어 있다는 점이 가장
이해 시키기 어려운 부분이었습니다.

개발자들은 매일 퇴근전에 이 표를 업데이트 합니다. 이 후 PM이 확인을 하게 되는데 , 이 때 스프레드시트의 히스토리 기능을
이용하면 어떤 변화가 있었는 지 쉽게 알게 됩니다.

이 표를 사용하는 주요 이유는 다음의 그림 , 표의 마지막 부분을 살펴 보시면 알게 됩니다.



최초 예상은 1,432 시간이 들어간다고 예측 했습니다. 종료 시점에서의 실제 소요 시간은 1,544 시간이 소요되었음을 알 수 있습니다.
( 각 개발자의 소요시간을 합산한 수치이므로 이 시간이 소요 일정이 아닙니다. )
그리고 아래 부분의 경과시간 항목은 각 개발자별로 목표, 현재, 잔여 시간을 나타내어 어느 개발자가 지연, 단축되는 지
알 수 있습니다.

자! 그러면 일정은 어떻게 산출하는지 설명을 드리겠습니다.
제가 앞서의 글에서 일정은 여러 변수의 조합으로 된 수식으로 표현이 가능하다고 한 적이 있습니다.
이 표의 각 행이 하나의 변수라고 생각하시면 됩니다.
그리고
1. WBS를 입력한 후에 항목의 담당자를 입력합니다.
   한명의 담당자를 입력 할 수 없는 경우는 다시 분리합니다.
2. Excel 같은 경우는 SUMIF 등의 함수를 사용하여 담당자별로 잔여 일정의 합을 구합니다.
3. 그 중에서 제일 큰 사람의 값(시간)을 날짜로 바꾸어서 현재일과 합치면 완료 예상 일정이 됩니다.
   개발자별로 차이가 많이 나지 않도록 업무를 분배하는 것이 전체 일정 단축의 팁이 됩니다.

이 표를 사용하면서 얻게 되는 장점들에 대해서는 다음에 설명을 드리겠습니다.


2009년 11월 11일 수요일

조엘따라하기 #1

조엘따라하기 #1

이 번에는 프로젝트 일정 관리에 대한 이야기를 해 보고자 합니다.

이전글에서 프로젝트 일정은 여러가지 변수가 있어서 정확히 구할 수는 없다고 했습니다.
때문에 프로젝트가 진행 되면서 일정에 영향을 미치는 변수들이 하나씩 없어지게 되면
점점 더 정확한 일정을 알수가 있게 되는 것이지요.
만약 진행이되면서 일정을 더 알 수 없게 되는 상황이라면 정말 심각한 상황이라고 판단하시면 됩니다. ^^;

그러면 프로젝트가 진행중에는 어떤 식으로 일정을 관리해야 될까요.

이전글에서 일정은 아래와 같은 방식으로 구해질 수 있다고 했습니다. 예)

 Y(일정) = F( 분석, 설계, 구현, 테스트 , 범위, 리소스, 품질 ... ) + e ( 공휴일, 휴가, ... )

일정에 영향을 미치는 변수들 간에는 서로 영향을 미치는 경우도 있습니다.
예를들어 분석단계에서의 결과가 이후의 단계들에 영향을 미치게 되고 , 품질의 제약조건이 강화가 되면
반대로 구현 테스트 단계의 일정에 영향을 미치게 됩니다. 또한 분석, 설계, 구현, 테스트등의 각 단계의
내부도 자세히 보면 간단한 구조가 아님을 알게 됩니다.

일정이 이렇게 복잡한 구조로 되어 있는데 그러면 어떻게 관리하시나요.
혹시 아래와 같이 하시거나 해보지 않으셨나요 ?

- 세부적인 업무는 신경쓰지 않고 일정을 줄일 수 있는 일이라면 뭐든지 한다.
- 최선을 다하면 일정을 맞출 수 있다는 각오로 팀원을 독려하고 열심히 야근한다.
- 그래도 안되면 예정 일자가 다되기 전에 고객, 영업들과 일정변경 회의를 한다.  

물론 극단적인 예입니다만, 위와 같은 경우는 다음과 같은 것들이 문제들로 나타납니다.

  --> 스펙변경, 추가가 불가하고 무조건 줄이려는 성격이 까칠한 PM이 완성된다.
  --> 프로젝트가 끝나면 팀원들이 이직을 심각히 고려한다.
  --> 개발팀의 신뢰가 떨어지고 프로젝트 관계자들의 비용이 상승한다.

사업을 계속 할려고 한다면 위와 같은 상황이 발생해서는 안되겠지요.
일정관리에 좀 더 과학적인 방법이 없을까 하여 궁리해 봅니다.
먼저 일정을 구하는 방식이 아래와 같습니다.

Y(일정) = F( 분석, 설계, 구현, 테스트 , 범위, 리소스, 품질 ... ) + e ( 공휴일, 휴가, ... )

기본 원리만 빼서 보면 다음과 같이 바꿀 수 있습니다.
일정 예측치 = 분석단계 예측치 + 설계단계 예측치 + 구현단계 예측치 + ....

수식으로 써볼까요.

E(S) = E(A) + E(D) + E(C) + ...
S : Schedule , D : Design , C : Construction ( Coding )

어디서 많이 보던 수식이 나오네요. ^^
A, D, C 가 정규분포를 따른다면 t-분포와 유사하게 되는군요.

복잡하게 통계 모형을 이용하여 설명드리지 않겠습니다. 직관적으로 설명드리겠습니다.
분석단계의 기간이 10일이 걸린다고 예측했다면 그렇다면 실제로 이 기간이 8일에서 12일 사이에 있을
확율은 99%라고 할 수 있습니다. 그리고 계속해서 설계기간이 20일 이라면 99% 확율로 16일에서 24일
사이에 있을 것입니다. 물론 예상 확율을 낮춘다면 일정변동의 폭은 좀 더 줄어 들 것입니다.

이 두가지만 가지고 일정을 예측해보면 예상 일정 E(S) 는 24일에서 36일 사이에 있을 확율이 9X% 입니다.
즉, 분석 , 설계의 기간은 9X% 확율로 24일에서 36일 정도 걸립니다. 이렇게 말 할 수 있는 것입니다.
변동폭이 너무 큰가요 그러면 확율을 90% 로 낮춰 계산해 봅니다.
9.5 <= E(A) <= 10.5
19 <= E(D) <= 21
그러면 "분석 설계의 기간은 28.5 일에서 31.5 일 사이에 끝나고 예측의 정확도는 90%입니다."
라고 말 할 수도 있겠지요.

오늘은 여기까지만 말씀드리고 최초 예상치 , 현재 예상치 , 진행율 등에 대해서는 다음으로 미루겠습니다.

2009년 11월 10일 화요일

설계를 고정하여 변수를 줄여라

프로젝트 관리 #1 설계를 고정하여 변수를 줄여라

일상에서 매일 또는 정기적으로 반복되는 작업 ( Operation ) 과는 달리 , 다양하고 많은
변수를 가진 것이 프로젝트의 특징이기는 하다.

이러한 프로젝트의 주요 성공 목표라고 할 수 있는 일정은 어떻게 구할 수 있나요?
일정이라는 값을 구해내는 공식을 만들어 보면 다음과 같을 수 있지 않을까 합니다.

 Y(일정) = F( 분석, 설계, 구현, 테스트 , 범위, 리소스, 품질 ... ) + e ( 공휴일, 휴가, ... )

이 식의 문제점은 뭐라고 생각하시는가 ?
Y(일정) 을 구하기 위해 필요한 식이 너무 적다는 것이겠지요.
방정식은 하나인데 변수가 너무 많다는 것인데 이렇게 되면 정확한 Y(일정) 을 구하는 것은
어렵다는 아니 안된다는 것입니다.

프로젝트 관리자는 Y(일정)에 영향을 미치는 변수를 줄여주는 것이 필요합니다.
여러가지 방법이 있겠지만 그중에서 오늘은 "#1 설계를 고정하여 변수를 줄여라" 것을 말해 보고자 합니다.

규모가 제법되는 SW 개발 프로젝트의 경우 (, 대체로 동시 3-4 명 이상의 개발자가 개발하는 )
프로젝트는 초기에 개발 시스템의 기본 설계를 정해두고 구현 단계로 진입하는 것이 필요합니다.
기본 설계를 정한다는 것이 개발자들의 반발을 불러 올 수도 있고 별도의 설계 교육이 필요한
다소 번거로운 일이 될 수도 있으나 프로젝트 관리적인 측면에서 본다면 몇가지 장점이 있다.

첫번째는 개발자들의 결원, 또는 교체라든지 등의 상황이 발생한 경우에 발생하는 비용을 사전
예상하여 관리를 할 수 있다는 점이다.

예를들어 개발자의 교체가 발생하는 경우 교체 멤버가 제대로 개발을 하기 위해서는 비지니스
로직에 대한 이해외에도 SW 설계에 대한 이해가 필요한데. 전체 시스템의 기본 설계를 동일하게
가져간다면 어느 개발자가 교체 되더라도 , 기본 설계가 같기 때문에 , 이를 이해하는 시간이 대체로
일정하게 된다는 것이다.

이는 다시 말해서 개발자 전환 비용이 줄어드는 것은 아니지만 전환에 따른 비용을 사전에 예상할
수 있어 관리에 활용 할 수 있다는 것이다.

두번째는 프로젝트를 진행하다보면 업무의 진행속도에 차이가 나게 마련이다. 이런 경우 해당 단계의
개발이 완료된 개발자를 미완료 업무에 전환 배치하는 경우 전환 비용이 거의 없어 전체적인
효율을 높일 수 있는 기회를 가진다는 것이다.

이러한 이유로
SW 개발 프로젝트 관리자는 SW 설계에 대한 의견을 내고 , 토론을 하고 , 평가를 할 수 있어야 한다.

마무리하면 ,
"#1 설계를 고정하여 변수를 줄여라" 에서는 개발자 교체에 따른 비용을 고정하고 전화에 따른 비용을
줄이기 위해서는 개발 초기에 시스템 전체에 필요한 설계를 확정하는 것이 필요하다는 것입니다.


프로젝트관리(Project Management) 용어 몇가지

IT 산업에서의 대규모 아웃소싱이 진행되기 전 , 기업들이 자체 IT 조직을 구성하여 개발을 진행하던 시절에는
SW개발이 프로젝트 형태를 이루기 보다는 개발 업무의 일환으로 진행되었던 적이 있었습니다 만,
최근에는 SW 개발이 프로젝트 형태를 띄지 않는 경우가 거의 없습니다.

개발 프로젝트를 진행하다보면 , 여러가지 커뮤니케이션 문제를 만나게 되는데 원인을 생각해 보면
용어에 대한 이해가 잘못되어 발생한 경우가 적지 않았다고 생각이 되는군요.
예를들면, "이 프로젝트는 일정이 어떻게 됩니까 ?"  이런 질문이 나오면 여러가지 답이 나옵니다.
그러면 다시 알고 싶은 것을 다른말로 물어보고 이렇게 몇번 반복을 해야 커뮤니케이션이 완성 되는데
위 상황이 이메일로 이루어지는 경우를 생각해보면 엄청난 시간이 드는 문제가 아닐 수 없더군요.

프로젝트에 관계된 용어를 정리 해 둘 필요가 있겠다 싶어 관련 자료를 찾아 보았는데 게을러서 그런지
검색실력이 꽝인지 좋은 자료가 잘 안나오네요.

- Project Management
Working in the field of project management requires a number of distinct skills.
A project manager needs to be able to define the scope of a project clearly,
estimate the cost and time required to complete it, set deliverables and specifications
for every stage from start to finish, and allocate the needed resources as efficiently
as possible.
The ability to manage people is also a critical skill. A good project manager can deal
productively with a broad range of stakeholders, including employees, clients,
subcontractors and others affected by the project. He or she will need to sign off on
major decisions, such as change orders, while choosing the best possible team to make
day-to-day decision.

- Project Manager (PM)
The person with overall responsibility for planning and managing a project.
This title is used in the construction industry, information technology and many other
industries that are based on the production of product or service.

"A project manager needs to begin by setting clear objectives."

- Sponsor
The person who has authority over a project, provides funding, approves scope changes
and champions the project within an organization. The project sponsor is usually
a representative of the client, since the client has commissioned and funded the project.

"The sponsor should provide high-level guidence while letting the project manager
handle day-to-day isues."

- Stakeholder
Anyone who has an interest in a project or will be affected by it. Stakeholders can be
people inside or outside the organization carrying out the project.

"We need to remember that the homeowners near our new factory are also stakeholder
in the expansion project."

- Subcontractor
A business or person who is paid to do part of the work assigned to another person or company."

"We can't permit our IT provider to subcontract any work on our database, since this
would put the security of our customer records at risk."

- Scope
Including the project's goal, the resources to be used to carry it out, and a specific
description of the expected end result.

- Deliverables
A deliverable may be either a physical object, such as a newly designed product, or
an outcome, such as the completion of a business plan.

- Specifications
Specifications is often abbreviated to : specs.
Specifications are detailed descriptions of the deliverables for a project and include all
the technical, time and cost requirements of a project.

"This customer management software doesn't meet our original specifications."

- Baseline
A set of standards for a project, usually based on previous experience, that can
be used to evaluate its progress. The baseline will include the project's expected costs,
schedule and any technical requrements.

"Our baseline expectation is to complete the project by December at a cost of no
more than $4 million."

- Resources
All items needed to complete a project, such as a tool, supply item, facility or person.
People (human resources) and money (financial resources) are often the most important
elements of a project.

"The scope of a project needs to match the resources available to carry it out."

- To estimate
To calculate or guess the value, size or amount of something.

"The value of the deal is estimated at $12 million."

- Top-down estimate
'from the top down', or in great detail, and comparing it to similar projects in the past.

"Richard has worked on several similar projects before, so he can give us
a top-down estimate of how much this one should cost."

- To allocate
To decide that an amount of money, time or other resources should be used
for a certain purpose.

"Du Pont has allocated funds t build two new factories in Asia."

- Margin
A spare amount of money, time or other resources that is set aside in case of
unforseen problems, costs or delays.

"This construction project has two-week margin to allow for delays due to bad weather."

- Contingency
A planned allocation of resources that are to be used in the event that something
unforeseen, ... such as a bad weather, affects the completion of a project according
to the schedule.

"We need to develop plans to deal with any contingencies before starting the project."

- Change order
A request for a change in a project's scope, deliverables or cost. Most large projects will
require change orders, either because the project manager sees the need for changes
or because the client's needs have changed.

"It's important to get the client to approve any change orders before allocating more resources."

- To sign off
To give approval for someone else's decision.

"The finance director needs to sign off on any change in our approved vendors."

- Schedule
A set of target dates for completing elements of a project.

"The schedule requires us to complete the first phase by January 1."
"Richard has scheduled a meeting for all department heads on Wednesday morning at 10:00."

- Timeframe
Time frame is usually written as one word, but can be written as two: time frame.

"The timeframe for this project is quite tight as we only have two month to complete the design phase."

- To kick off
An idiomatic expression meaning 'to start'. Can also be used as a noun: kickoff.

"We kicked off the new project with a meeting for all stakeholders."

- To give the green light
To give permission for a project to begin.

"The commission has given the green light for a wind farm development."

- Lead time
The time between making a request and receiving the results.
Often used to refer to the time between placing an order and receiving delivery.

"We have a large backlog of order, so our lead time has risen from 15 days to nearly 30 days."

- To execute
To perform or accomplish a specific task.

"We need to execute each phase of this project according to schedule or we'll be facing series delays."

- Stage / phase
A specific time period assigned for one element (part) of a project.
In most cases, each stage will end with the completion of a deliverable.

"In the second phase, marketing will work with our research team to build new feature
based on customer feedback."

- Milestone
A critical event during the life of a project, usually the accomplishment of a project deliverable.

"Completing all documentation is a key milestone for most software development projects."

- Constraint
A restriction of limitation that influences the project plan. For example, a target date may be a
constraint on the scheduling of a project.

"There are two key constraints on the scope of this project: it needs to be completed in less
than six months and within budget."

- Critical path
The sequence of activities that must be completed on time for the entire project to finsh on schedule.

"The critical path for this product launch involves market research, followed by product development and testing."

- Deadline
The latest time or date by which something should be completed.

"The deadline to apply for these new positions is next Friday."

- Dependency relationship
A relationship between two elements of a projects..  requiring one to be started or finished before
another can begin.

"There's a clear dependency relationship between planning and budgeting, since the plans have
to e finished before we can calculate our materials costs."

- PERT chart
A tool used to schedule, organize and coordinate tasks within a project.

"A PERT chart specifies the sequence of tasks in a project, and the time required t execute each one."

- Gannt chart
A bar chart that shows the overlapping timing of activities involved in a project, and sometimes
also shows the relationship betwen them.

"According to the project's Gannt chart, we should complete our fundraising on or before 15 June."

- Work breakdown structure (WBS)
A tree-like structure of tasks that need to be performed to complete a project.
The WBS is often used as a project management tool.

"Creating a WBS might help us identify the major cost items for this project."

출처 : http://www.businessenglishpod.com/

텍스트큐브닷컴 블로그 개설을 축하합니다.

텍스트큐브닷컴 서비스에 가입하신 것을 환영합니다.
회원님은 현재 텍스트큐브닷컴 오픈 베타 서비스 사용자입니다.

이 포스트는 텍스트큐브닷컴 서비스에서 블로그를 만든 이후 처음 보여지는 안내 포스트입니다. 내용을 다 읽으신 이후에는 삭제하셔도 됩니다.
텍스트큐브의 멋진 기능들을 살짝 소개해 드립니다.


보다 쉽고 편리하게 글을 작성할 수 있습니다.


1. 글쓰기 메뉴가 깔끔하게 정리 되었습니다.
2. 멀티미디어 첨부위자드를 도입했습니다.
3. 글쓰기 도중에 자료를 검색하여 본문에 삽입할 수 있게 되었습니다.*
(* 외부자료 검색하여 붙여넣기는 추후지원)


블로그끼리 서로 연결됩니다.

관심있는 텍스트큐브닷컴 블로그를 "관심블로그"로 등록하세요.
내가 어떤 블로그에 관심 있는지를 나타낼 수 있으며, 관심 블로그의 새 글을 알리미로 구독 할 수 있습니다.


개인화된 정보가 추천됩니다.

1. 회원님의 글을 바탕으로, 회원님을 잘 나타낼 수 있는 태그(ExperTag)가 추천 됩니다.
2. 글쓰기의 재료를 위한 포스트가 추천됩니다.


블로그에 첫 글을 남겨 보세요.

어느페이지에 있더라도 블로그 오른쪽 상단의 "글쓰기" 버튼을 클릭하면 바로 글쓰기가 가능합니다.
지금 바로 글을 하나 써보시는 건 어떨까요?



텍스트큐브닷컴은 현재 비공개 베타서비스중입니다.
사용중 발견하신 버그나 개선점은 관리자 페이지 상단에 위치한 의견제안 링크를 통해서 언제든지 가능합니다.

텍스트큐브를 통해 멋진 블로그를 만들어 보세요.