프로젝트 일정관리 개선점 찾기...

안녕하세요. 기온이 많이 내려갔네요, 감기 조심하시기 바랍니다.

프로젝트 관리 , 제품 개발 프로세스 등에 관해서 일반적이고 실무적인 수준의 내용으로 진행을 해오고 있습니다.

글을 쓰면서 계속 느끼게되는 것이 아무래도 제가 좀 급한 성격이기도 하고 시간 압박을 느끼면서 작성을 하다보니 설명이 많이 부족했던 것 같고 논리의 흐름도 일정하지 않아 이해하기도 힘들었던 것 같습니다.

오늘 부터는 "일정관리 개선방법", "릴리스 이후 품질관리" 등으로 좀 더 주제를 세분화하여 범위를 좁히고

촉박하지 않은 시간대를 골라서 차분히 해 보도록 하겠습니다. 이러면 조금씩 글쓰는 게 나아지지 않을까 합니다.

오늘은 일정관리의 개선방법에 대해 어떤 방법들이 있는지 살펴 보겠습니다.

지난번 글들 "조엘 따라하기 #1" , 2, 3 에서 언급이 되었던 Time-Table 은 Work-List 를 일일 단위로 세분화하고 , 진행되는 내용을 시간 단위로 매일 업데이트 하면서 진행 내용을 관리한다고 했었습니다.

Time-Table 은 그 활용에 따라서 여러가지 용도로 쓰일 수 있는데 , 오늘의 주제인 일정관리 개선방법에

활용해 보도록 하겠습니다.

Time-Table은 시간 단위의 관리이기 때문에 최초 도입에 담당자들의 거부감이 매우 큽니다. 도입 단계에서

그 목적과 효과에 이해가 충분히 설명되지 않으면 시행을 한다고 하여도 제대로 그 효과를 보기 어렵다는

말씀을 다시 드리고 싶습니다.

Time-Table 도입에 있어 초기 관리자에게 또 하나 어려운 점이라면 일일 단위의 Work-List 를 작성하는 것이 쉽지 않다는 것일 것 같습니다. 프로젝트의 규모가 작고 Work-List 가 될 내용을 대부분 경험해 본 관리자라면 혼자서 작성해도 문제가 없겠지만 , 웹개발과 같이 기술적 폭이 넓은 경우에는 관리자의 경력이 아무리 오래 되었다고 하여도 한계가 있기 마련입니다. 예를들어 웹 디자인 경험을 해보고 각 단계을 알고 있으면 이를 일일 단위로 나눌 수 있는 관리자는 거의 없지 않겠습니까 ?

어쨌던 , 그래서 규모가 크던 작던 프로젝트의 Work-List 를 만드는 과정에는 프로젝트 팀원이 모두 참여해서 진행을 하도록 해야 합니다. 웹디자인 , 데이터베이스 설계 , UI 설계 , 웹코딩 , 비지니스 프로세스 설계 , 외부 연동 설계 , 라이브러리 사용, 테스트 등등 시간이 소요되는 모든 일들은 Work-List 의 대상이 된다고 생각하시고 프로젝트 관리자로서 모두 꼼꼼히 챙겨 보시기 바랍니다.

이런 과정을 거쳐서 Work-List 가 완성이 되면, 각 Work-List 에 예상 작업 소요량을 시간단위로 추가하고 , 담당자를 확정하고 우선순위를 매겨서 Time-Table 작성을 완성하게 됩니다. 이제 남은 일은 Time-Table에 따라서 실행을 하면 됩니다.

실행 과정에 대해서는 제가 따로 정리할 기회가 있으면 하겠지만 제 글 여기 저기 흩어져 있습니다. 블로그 글들을 간단히 한 번 둘러 보시기면 도움이 되실 수 있을 것입니다.

이제 이렇게 계획을 수행을 했을 때 ,  어떤 개선 방안을 찾는 어떤 방법이 있는 지 살펴 보겠습니다.

첫번째는 프로젝트의 종료 시점이 되면  Time-Table 이 초기의 것과 많이 달라져 있을 것입니다. 어떤 Work-List 는 초기 예상에서는 포함이 되었다가 없어졌을 수도 있고 어떤 Work-List 는 새로이 추가가 되어 있을 것입니다.

또 어떤 경우는 나누어 지거나 합쳐진 Work-List 도 있을 것입니다.

이렇게 변화무쌍한 것이 프로젝트의 특성이 아니겠느냐 하실 분도 있을 수 있는데 , 이러한 의견은 어떤 측면에서는 옳습니다. 초기의 요구사항 부터 기술적인 대처 방안들이 변화하지 않을 수가 없기 때문일 것입니다.

문제는 이러한 프로젝트의 특성을 그대로 인정하고 별다른 대책을 세우지 않는다면 발전을 기대하기는 어렵다는 것이겠지요.

과거로부터 배워 , 현실을 개선 , 발전 시켜야 하지 않겠습니까 ?

현재의 상태에 대하여 기본 가정에서 부터 문제 의식을 가지고 바라보며 , 개선을 하겠다는 의지를 가지지 않으면 발전이라는 것은 없다는 것이지요. CMM 의 최고 단계 수준이 계속 발전하는 모델이 잖습니까.

아무튼 조금 옆길로 새버렸습니다.

초기 Work-List 와 최종 Work-List가 변경이 되는데 그 변화의 폭에 주목해보면 , 예를들어 변경이 아주 많았던

프로젝트 일수록 잦은 일정 변경이 있었을 것이고 계획에 없었던 인력 이동도 많이 발생했을 것입니다.

달리 말하면 관리적으로 좀 어렵게 진행이 되었을 것이라는 것입니다. 일정 변경에 따른 계획 수정이 자주 발생하면서 이에 따른 조직의 부담이 늘어나게 되는데 이의 결과로 개발 효율이 올라가지 못하고 떨어지게 됩니다.

그러면 이러한 Work-List 변화의 폭은 어떻게 측정하고 어떻게 줄일 수 있을까요.

측정에 관해서는 아래의 수식을 살펴봐 주시기 바랍니다.

전체 Work-List 의 시간이란 최초 계획된 시간입니다.

위 수식의 Work-List 변화도는 그 값이 커질수록 예측대비 실행 단계에서의 변화가 많았다는 것을 의미하게 됩니다.

사실 변화도가 높다는 것은 최초 계획 단계에서의 예측력이 낮았다는 것을 의미하는 것이기 때문에 이에 대한 분석을 하는 것으로 개선점 발견의 시작으로 잡으시면 될 것 같습니다.

Work-List가 변한 이유는 한 두가지 이유가 아니기 때문에 이에 대한 분석이 필요합니다. 분석 결과에 가지고 그에 맞는 대책들을 마련하는 과정을 거쳐야 합니다. 이 대책들은 다음 프로젝트 진행시에 Time-Table에 반영을 하도록 하는 방식으로 프로젝트 개선 프로세스를 만들어 운용하는 방안이 있을 수 있습니다.

또한 Work-List 변화치를 관리자 또는 담당자자의 평가 지표로도 사용하는 방안이 있을 수 있습니다.

평가 지표의 명칭은 , 예를들어 , "일정 예측도" 같은 지표가 될 것입니다.

이 지표를 운영하시면서 매년 그 기준치를 조금씩 올려가는 관리 전략이 경영적으로는 중요한 의미를 가질 것입니다.

다음으로 일정 개선의 방안 두번째

프로젝트가 종료된 후에 Time-Table 상에는 예상 일정을 초과하여 , 또는 빨리 진행되는 Work-List 들이 있습니다. 초기에 너무 넉넉하게? 또는 빡빡하게 설정한 경우로 판단 되는 것 들인데요.

예를들어 8 시간을 잡은 일이 16 시간으로 종료될 수 있고 또는 4 시간만에 종료되는 것이 표에 쭉 나타나게 됩니다.

이러한 항목내에서의 예측치와 실측치의 차이를 보시면 담당자별로 다음의 세가지 패턴 중 하나를 발견하시게 될 것입니다.  

1. 대부분의 Work-List 가 계획된 시간에 완료됨.

2. 각 Work-List 의 소요 시간이 계획 대비 (+) , (-) 차이가 많이남.

3. 대부분의 Work-List 가 계획된 시간에 비하여 초과하여 완료됨.

각각의 경우에 대한 문제점과 개선 방안들에 대해 논해 보겠습니다.

1.번의 경우는 대부분의 Work-List 가 계획대로 완료가 되었기 때문에 겉으로 보기에는 전혀 문제가 없어 보입니다 만 내면적인 면을 생각해 보면 그렇지가 않습니다.

이 내용만으로 가능한 또 다른 해석은 "일정 소용 산정이 과장되어 있을 수 있다" 는 것입니다. 이런 담당자는 자신의 능력을 너무 과소평가 하거나 일에 대한 과대 평가가 원인일 것인데 주로 소극적인 업무 자세를 가지는 경우에 발생 한다고 할 수 도 있습니다. 뭔가 개선책이 필요하다고 할 수 있을 것입니다.

이런 사항이 발생하는 경우에는 점차적으로 실제 수행 시간이 예상된 시간을 초과하는 일이 발생하는 지점까지 할당된 일에 대한 소요시간을 줄여 주는 것이 좋을 것입니다. 이 방법은 프로젝트 기간이 길다면 수행중에도 가능한 운영 방안이 될 것이고 만약 기간이 짧은 프로젝트의 경우라면 다음 프로젝트에 반영이 될 수 있도록 관리를 해야 할 것입니다.

2.번의 경우는 소요시간이 계획대비 차이가 많이 나는 경우인데 , 최초 계획이 어설프게 되었거나 담당자가 자기 통제가 안되는 경우입니다. 이런 담당자의 경우는 해당 Work-List 에 대한 소요산정 내용을 다시 Review 해 보는 것이 좋을 것입니다. 아무래도 지난 경과를 가지고 팀에서 논의를 하게 되면 좀 더 나은 예측치가 되지 않을까 합니다.

물론 진행중에 별도의 시간을 내서 Review 해 보기는 어려울 수 있지만 말입니다.

3.번의 경우는 담당자 본인이 자신의 능력을 과대 평가하는 경우인데 1.번의 경우와는 반대로 예측치의 시간을 조금씩 올려서 운용하는 것이 합리적일 것입니다. 일에 대한 자세가 너무 적극적이거나 소극적인 것이 전체적으로 도움이 안되는 경우가 많기 때문입니다.

이상으로 일정 관리에 대하여 몇가지 말씀을 드렸습니다.

여기까지 읽으시다보면 "이거 너무 통제가 강한 것 같은데" 또는 "가능하지 않을 것 같은데" 같은 여러가지 의견이 있을 것 같습니다.

오늘은 이만 줄이겠습니다.

제품 개발 프로세스 #4

이번엔 아마 제품개발 프로세스 끝낼 수 있을 듯..

지난번에 설계 단계까지 했었군요.

구현 단계에 대해서는 구현의 방법등과 같은 내용 보다는 관리적인 면을 말씀드리겠습니다.

일전의 글에서 개발자들에게 코드 리뷰 시간을 할당하라고 하였었는데 , 바로 이 단계에서 필요한 것입니다.

코드리뷰 일정은 이미 개발계획서에 반영이 되어 있을 것입니다. 보통 주1회 2시간 정도가 적당합니다.

그리고 구현단계 초기에는 코딩가이드에 대한 교육도 진행이 되어야 합니다.

코드리뷰에 대해서는 Fagan Inspection 과 같은 관리적, 절차적 지침도 있는 것 같고 , 코드리뷰 관리 시스템도

일부 제작이 되어 있는 것 같기도 합니다. ( 이 시스템으로 논문을 진행하시는 분이 있어서 ...^^ )

어떤 방법을 사용하든 코드리뷰의 목적을 정하고 시작하면 그 방법에 대하여는 크게 고민하지 않아도 될 것 같습니다. 다만 너무 무거운 프로세스나 시스템을 사용하게 되면 본래의 목적을 잃게 되는 경우가 있어 되도록이면

큰 제약 사항없이 진행하는 것이 좋을 것 같습니다.

코드리뷰의 목적은 크게 아래의 두가지 일 것입니다.

첫째는 코드의 품질 향상이고 두번째는 개발자간의 기술공유가 될 것입니다.

방법적으로 코드리뷰는 일주일 단위로 주기적으로 진행을 하게 되는데 , 지난 시간에 지적이 나왔거나 논의가 된 부분에 대한 결과를 먼저 공유하고 , 지난 주간에 제작된 코드를 전체 리뷰를 하는 식으로 하면 무리가 없을 듯합니다.

시간은 진행을 해보니 전체 두시간 정도가 적당하고 가능하면 개발자 전원이 모일 수 있도록 해야 효과가 커집니다. 여기서 주의하실 점은 관리자의 입장에서 코드리뷰 도중에 나오는 개발자간 커뮤니케이션을 관여하게 되면 , 구현상의 솔직한 의견들이 나오기 어렵다는 것입니다. 그래서 코드리뷰의 원활한 진행을 위해서는 관리자 참여에 제한을 두는 것도 하나의 방법이 될 것입니다. 이 리뷰의 내용은 인사에 반영하지 말란 것이지요.

코드리뷰 외에도 Pair Programming 등의 진행 기법이 있는데, 전체적으로 적용하기에는 어려운 점이 있습니다. 신규 개발자 라든지 외주 개발자가 섞인 경우 시행 해 볼 수도 있을 것입니다. ( 저는 해본 적 없습니다만 )

구현이 진행되기 전에 도움말 제작 등의 작업은 없어도 되지만 , 스타일 가이드와 그래픽등의 UI 작업은 완료가 되어 있어야 합니다. 프로젝트 관리자는 설계기간 조정과 투입인력의 배분을 통해서 이러한 팀간의 일정 연결이 잘 되도록 특별히 신경을 써야 합니다.

그리고 빌드관리 시스템을 가동하게 됩니다. 빌드관리 시스템은 일일빌드 체계로 운영하는 것이 좋으며 , 개발팀

전체가 항상 최신의 버전으로 개발에 임할 수 있도록 해야 합니다. 되도록이면 오후4시경에 빌드를 하는 것이 무리가 없을 것입니다. 오후 4시에 하는 이유는 당일 빌드는 당일에 완료해야 하기 때문이죠. 실패했더라도 수정에  필요한 시간을 주어야 하기 때문입니다. 만약 빌드가 계속 안되게 되면 그 담당자는 문제가 해결 될 때까지 퇴근 할 수 없다는 원칙은 세워 두시기 바랍니다.

이렇게 일일빌드를 체크하시며 구현을 진행하시면 됩니다. 그래서 구현단계의 마지막에 다다르게 되면 개발자 테스트 단계가 됩니다. 개발자 테스트 단계에서는 아래의 사항을 만족 할 때까지 계속 코드를 고치거나 수정을 해야 합니다.

첫째 요구사항에 나온 모든 기능이 구현 완료된 상태가 되어야 하고 ,

둘째 시스템이 죽는 Crash 레벨 버그가 없어야 하며

셋째 프로세스 진행이 중단되는 Block 상황이 발생하면 안됩니다

그리고 마지막으로 도움말 등의 텍스트 작업까지 모두 완료되어 있어야 합니다.

이 모든 조건을 만족하게 되면 개발자 테스트의 다음 단계인 QA - 알파테스트 과정으로 진입을 선언하게 됩니다. 알파테스트 단계가 되면 형상관리를 본격적으로 진행하게 되는데 , 프로젝트 관리자는 개발자에게 알파테스트의 각 단계마다 알파1, 알파2, 등과 같이 반드시 Tagging 을 하도록 지시해야 하고 이 Tagging 버전을 기준으로 테스트를 진행 하도록 합니다.

테스트 도중에 발견되는 버그는 버그트래킹 시스템을 이용하여 테스터가 등록하고 관리자가 판단하여 개발자 할당을 하고 수정이 이루어진 버그들의 숫자가 일정 수준에 이르게 되면 다시 Tagging을 하여 다음 단계 알파테스트를 진행 합니다. 이렇게 계속적인 테스트를 거치면서 구현 제품의 완성도를 높여 가는데 특정 조건이 만족되면 베타 테스트 선언을 하게 됩니다.

사업적인 면에서 보면 , 이 알파테스트 단계로 진입을 하게되면 개발팀 외에도 바빠지는 팀들이 많습니다.

기획,마케팅 부서는 런칭 준비를 해야 하고 , 영업팀은 필드테스트 대상 물색? 에 들어갑니다. 그리고 홍보팀은

언론 대응 준비에 들어가겠지요.

이 알파테스트 단계에서는 프로젝트의 일정이 오로지 개발팀의 책임이 되는데 , 이 알파테스트 또한 다음 단계인 베타테스트 진행을 위한 조건을 만족하지 못하게 되면 계속 반복을 해야 하기 때문에 개발자들이 특히 어려운 기간임에는 분명합니다.

이러한 과정을 거치게 되면 베타 테스트를 진입하게 되는데 , 베타테스트 진입에 필요한 조건은 제품마다 회사마다 다를 것 입니다. 여하튼 이 단계에서는 베타 테스트의 대상을 최종사용자까지 할 것인가 또는 QA ,테스트로만 할 것인가를 정해야 합니다. 대개의 경우 B2C 제품인 경우는 오픈베타, 또는 크로즈베타 등으로 진행을 하고 B2B 제품인 경우는 필드테스트를 진행하게 됩니다. 이 모든게 여의치 않으면 QA 테스트로 대체하기도 합니다.

마찬가지로 베타테스트에도 Tagging 이 적용됩니다. 베타1, 베타2 와 같이 말이지요.

다음으로 베타테스트가 완료되면 RC를 정하게 됩니다.

RC1 , RC2 이렇게 말이죠. ( RC : Release Candidate )

원칙적으로는 RC는 여러개가 존재할 수 있으며 , 대체로 그 중에 제일 안정된 버전을 출시합니다.

프로젝트 관리자는 최종적으로 RTM ( Release To Manufacture , Market ) 회의를 소집하게 되는데 , 이 회의에는 프로젝트 관련 모든 사람들이 모이게 됩니다. ( CEO가 참석하기도 합니다. )

RTM 회의에서는 RC에서 처리가 안 된 잔여 버그들에 대한 보고를 하고 , 프로젝트 경과 보고등을 하게되고 출시 결정이 나게되면 프로젝트를 종료하게 됩니다. 이렇게 되면 이날이 회식하는 날입니다. ^^;

출시되기 전에 제품은 정식 버전을 정하게 되는데 1.0 과 같이 두자리 부터 1.0.3.1 과 같이 네자리 또는 기타 빌드 버전을 붙여서 길게 정하는 경우도 있습니다.

이상으로 제품 개발 프로세스에 대한 소개를 모두 마칩니다.

*쓰고 나서 보니까 뒷 부분으로 가면서 속도 조절이 안되어 빠진 부분이 많이 눈에 띄이는 데 이는 틈틈히 수정해 보도록 하겠습니다.

제품 개발 프로세스 #3

오늘도 어제 못다한 개발프로세스를 계속 진행해 볼까 합니다.

어제까지의 과정을 정리해보면 먼저 제품기획이 완료되고 SRS가 작성이 되면 개발계획서를 작성한다고 했습니다. 이 단계 이후에는 각 개발 관련 팀들이 맡은 일을 진행하게 됩니다.

영업팀 : 사전 영업

마케팅팀 : 제품 마케팅 계획 수립 및 진행

디자인팀 : 제품의 UI 설계와 그래픽 작업에 착수 ( SRS에 화면 요구사항이 있습니다. )

QA팀 : 테스트 계획 및 설계 / 버그관리 계획

형상관리팀 : 프로젝트 형상관리에 필요한 소스트리를 생성할 것입니다.

빌드팀 : 통합빌드 시스템에 빌드 스크립트 작성

TW ( Technical Writer ) : 사용자 설명서 , 도움말 제작 ,  번역

고객 지원팀 : 제품 지원에 대한 가이드 작성

기술 지원팀 : 제품의 설치 사양 및 운용방법 확인 및 설치 테스트

개발팀 : 시스템 설계 - 구현 - 테스트

*상기의 제품팀명은 제가 역할에 맞도록 가상으로 만든 것입니다.

굉장히 많은 팀들이 개발에 관여하기 때문에 지난번에도 말씀드렸지만 개발계획서는 매우 중요합니다.

그래서 각 팀의 일정 준수 자체가 완벽하게 이루어지지 않으면 계획된 기간내에 출시가 안되는 심각한

상황이 발생 할 수 있습니다. 또한 프로젝트 관리자의 소속이 별도의 PMO 조직인 경우도 있지만 그렇지

않은 경우도 있어 팀간의 갈등이 생겼을 경우 이를 해결하는데 많은 시간이 소모되기도 합니다.

위와 같은 이유로 개발계획을 산정할 때 별도의 여유 일정을 잡게 되는데 , 이렇게 잡게된 여유 일정이 나중에는 출시를 기다리는 영업/기획팀과 개발팀들간에 심각한 갈등을 일으키도 하고 , 연구소(개발조직)에 대한

경영진의 불신을 불러오는 계기가 되기도 합니다. 여하튼 그런 내부적인 문제들이 발생 할 가능성이 있기

때문에 팀간의 협업, 관리자의 사내 커뮤니케이션이 매우 중요하다고 할 수 있습니다.

다시 개발팀만을 중심으로 설명을 드리면 , 이어지는 단계는 제품 설계입니다.

제품 설계 즉 시스템 설계는 정형화된 방법이 없다고 말씀 드리는 것이 옳을 것 같습니다. 다만 이러이러한

형태로 , 방향으로 가야 하다는 정도는 말씀을 드릴 수가 있겠습니다.

시스템이라는 것은 , 지난번 글 제안서쓰기에서 언급했듯이 , 더 작은 서브시스템으로 나뉘어 질 것입니다.

이렇게 나뉘어 지게 되면 각 서브시스템을 연결해 주는 인터페이스가 생기게 되는데 , 설계는 이러한 서브 시스템의 명세와 인터페이스의 규약의 합으로 정의 할 수 있습니다. 여기서 다시 서브시스템은 더 작은 서브시스템으로 나뉘게되고 계속해서 이러한 방법으로 전체 시스템을 클래스 수준 또는 모듈의 수준까지 나누는 것이 좋을 것 같습니다.

설계를 어떠한 수준까지 명세를 남겨야 되는 것에 대해서는 이견이 있을 것 같습니다. 또한 프레임워크 같은 사전 설계된 시스템을 재사용하게 될 경우에는 극단적으로 시스템 설계를 건너 뛸 수도 있을 것 같습니다.

또다른 관점으로 설계서의 작성 수준을 이야기 하는 경우도 있습니다. 구현 단계에서 외주를 이용하는 경우에 해당 할 수 있는데 이런 가정이라면 설계서의 수준은 개발계획서에 명시된 조건을 갖춘 개발자가 별도의 설명 없이도 구현을 할 수 있는 수준까지 일 것입니다.

설계에 관해서는 이것으로 줄이도록 하겠습니다.

다음 단계로는 구현의 단계입니다.

이 부분은 다음글에서 계속 하도록 하겠습니다.

제품 개발 프로세스 #2

안녕하세요. 주말 잘 보내셨는지요 ?

찬바람이 부는 게 제법 겨울같은 날씨이군요.

오늘은 지난글에 이어서 개발 프로세스에 대한 내용을 적어보려고 합니다.

요구 사항 분석 단계가 완료되고 나면 산출물이 SRS와 개발계획서라고 말씀을 드렸습니다.

SRS에 대해서는 이미 말씀드렸으니 , 오늘은 개발계획서에 대한 내용으로 시작을 하겠습니다.

기획서를 만들 때 개발비용 및 출시일 향후 제품의 로드맵등을 나타냅니다.

개발계획서는 SRS 가 완료되고 난 이후에 작성이 되는 것이기 때문에 기획서의 여러 수치들에 비해서 구체적으로 나타나게 되는데 대표적인 수치가 일정과 비용 항목입니다.

개발계획서에는 이러한 수치를 포함하여 많은 항목들이 들어가게 되지만 필수적으로 포함이 되어야 할 내용들이 있는데 아래의 사항들입니다.

1. 비용

   프로젝트에 참여하게 되는 인적요소에 대한내용

   예를들면 개발자 (외주), 디자이너 , 테스터 , QA , 형상관리 , 관리자 등이 필수로 포함이 되고 필요에 따라서 특허, 인증등에 필요한 인력도 포함됩니다.

   인적요소 이외에도 외부모듈 구매 , 테스트/개발 용 장비 구매 , 공간 확보 등의 비 인적 요소도 있습니다.

2. 일정

   프로젝트 관리자는 각 담당팀의 일정을 취합하여 조정하는 역할을 해서 전체 일정을 작성하게 됩니다.

   CPM( Critical Path Management ) 이 필요한 시점입니다. 다만 , 이 시점의 개발팀 일정은 요구분석 단계이므로 기획 단계보다는 구체적이고 상세하겠지만 , 아직 설계 단계를 거치지 않은 상태이기 때문에 정확하지 않습니다. 대체로 일정 정도의 예비일정을 가지고 있는 단계라고 보시면 됩니다. 회사의 개발 프로세스가 고도화 되어 있다면 일정 예측이 이 단계에서도 매우 정확하게 될 수 있으나 아직 국내에는 이 단계에서 정확하게 할 수 있는 곳이 없는 것으로 알고 있습니다.

   추가적으로 개발 일정에는 해당 프로젝트와 연관이 있는 프로젝트의 일정을 명기해 둡니다.

( 사전 또는 사후 연관이 있는 프로젝트 )

3. 조직

    프로젝트 수행관련 조직 체계를 지정하는 것입니다.

    일상적 보고라인 , 커뮤니케이션 라인을 표시하고 부서의 담당자들을 명기하여 프로젝트를 진행하는 팀원들이 누구인지를 한눈에 알 수 있도록 해야 합니다.

4. 유지보수 계획

    빠뜨리기 쉬운 것이 유지보수 계획입니다.

    제품은 출시 이후에 단종처리가 되기까지는 유지보수를 해야합니다. 이에 대한 담당자와 필요한 계획을 미리 세워 두어야 합니다.

5. 개발계획 변경관리 방안

    개발계획은 내.외부 요인으로 변경이 될 가능성이 많습니다.

    이렇게 계획이 변경 될 경우의 변경관리 방안을 세워 두도록 합니다.

    계획이 대폭 변경되어야 하는 상황에서는 중요한 의사결정이 이루어져야 함으로 이 부분은 신경을

    써 주셔야 됩니다.

6. 프로젝트 평가방안

    프로젝트 수행 중 또는 종료 후의 평가 방법에 대한 기준을 설정해 둡니다.

    보통의 경우 일정 준수율과 비용 집행율 등이 평가의 기준이 되고 추가적으로 고객만족도, 특허 출원 건수 등이 있을 수 있습니다.

오늘은 시간 관계로 줄이고 , 다음번에는 이어서 설계단계에 대한 설명을 드리도록 하겠습니다.

제품 개발 프로세스 #1

안녕하십니까.

12월들어 눈. 비가 오는 날이 많았는데 오늘도 여전히 날씨가 안 좋군요.

오늘은 계속 미루던 제품 개발의 절차와 각 단계에서 고려되야 할 사항들에 대하여 간단히 말씀을 드려 보고자 합니다. 먼저 제품개발의 순서는 개발하는 곳 마다 세부적으로 다를 수 있고 , 또한 어떻게 해야 된다는 정형화 된 절차도 없기 때문에 아래의 내용은 참고로만 하시기 바랍니다.

제품개발은 SW 개발이라는 부분과 제품의 기획 그리고 마케팅 등과 같은 회사의 부서들과 연결해 보면 대체로 아래와 같은 절차를 밟게 될 것 같습니다.

1. 제품 기획

2. 요구사항분석

3. 설계

4. 구현

5. 테스트

6. 출시

*7. 유지보수

8. 업그레이드 기획 --> 다시 1. 번으로 또는 단종처리

아래는 각 단계별 대략적인 설명입니다.

1. 제품기획

   이 단계에서는 최종 산출물은 제품 기획서입니다. 기획서의 주요 내용은 다음과 같습니다.

   Market : 기획의 대상이 되는 제품이 속해 있는 시장 및 규모

   Customer : 대상 고객의 분석

   Feature : 제품의 주요 기능

   Cost : 개발비용과 제반 경비

   Price : 가격 정책

   Launching Plan : 제품 런칭 계획

   *RoadMap : *필요시 제품 로드맵

   위의 사항들외에도 상황에 따라 4P, STP 등의 마케팅 전략들이 들어갈 수 있겠습니다.

   이 단계에서 제품 개발에 필요한 일정과 리소스가 대략적으로 정해 집니다. 문제는 제품 RoadMap 상의 일정과 개발팀의 운용 일정이 맞지 않을 수 있고 , 제품의 기능에 대한 상호간의 충분한 이해가 안 될 수 있습니다. 그렇게되면 원하는 일정에 제품이 안 나오거나 기능이 다른 원치 않는 제품이 될 수도 있습니다.

또 개발을 하다보면 검토되지 않았던 부분에서 기술적인 문제가 발생 할 수도 있습니다.

   이런 문제점들에 대하여 제품과 연관된 각 팀은 기획이 완료되기 이전에 충분한 커뮤니케이션이 이루어 져야 합니다. 특히 이러한 커뮤니케이션상의 문제 해결과 여러 기술적인 문제들에 사전 검토를 위하여 CTO를 중심으로한 기술위원회를 운용할 수도 있을 것입니다.

   제품 기획과 연관되는 팀으로는 영업, 제품기획, 마케팅, 개발, 디자인, QA, PM, CTO, CEO, 기술지원, 고객지원 등 회사의 거의 전 부서가 다 해당이 되기 때문에 부서간의 이해관계가 얽히는 이슈가 발생하는 경우에는 이러한 커뮤니케이션에도 시간이 많이 걸릴 수 있습니다. 빠른 진행을 위해서는 사내에 커뮤니케이션을 위한 별도의 인프라를 구현해 두는 것이 좋을 것입니다.

제품기획 단계를 거치게 되면 프로젝트 관리자가 정해지게 됩니다.

2. 요구사항 분석

   이 단계의 최종 산출물은 SRS 와 개발계획표가 될 것입니다.

   개발계획표는 저번 글에서 알려드린데로 WBS 기반으로 또는 별도의 방법으로 Time Table 형식으로 작성을 하게 됩니다. SRS에는 너무 많은 부분이 언급이 되기 때문에 전체를 열거하기는 어렵습니다만 대체로 다음과 같습니다.

   - 개요

      프로젝트 목표/프로젝트 범위/개발의 범위/수행의 범위/문서규칙/정의 및 약어/관련문서

      대상 및 읽는 방법/프로젝트 산출물/산출물 형태 및 명칭/특허 출원 유무 및 내용

   - 제품

      전체 설명/제품 조망/전체 시스템 구성/전체 동작방식

      제품 주요 기능 ( 제품의 기능리스트 )/가정과 종속 관계/하위 호환성(BACKWARD COMPATIBILITY)

   - 환경

      운영(설치) 환경/Hardware, Software 환경/제품 설치 및 설정/배포 환경/마스터 구성/배포 방법/

      업그레이드 방법/형상관리/산출물 위치/소스 위치/문서 위치/빌드 환경/버그트래킹/기타 환경

   - 인터페이스

      외부 인터페이스 요구사항/사용자 인터페이스/하드웨어 인터페이스/소프트웨어 인터페이스/

      통신 인터페이스/기타 인터페이스

   - 성능

      THROUGHPUT/CONCURRENT SESSION/RESPONSE TIME/성능 종속 관계/기타 성능 요구사항

    - 기능 이외의 다른 요구사항

       안정성 요구사항/보안 요구사항/소프트웨어 품질 특성/다국어 지원/유니코드 지원/64BIT 지원/

       제품 인증/FIELD TEST/기타 요구 사항

    - 제품 기능 상세

       대분류 기능/ 중분류 기능/소분류 기능

 몇가지만 설명드리겠습니다.

 요구분석 단계에서 가장 중요한 부분은 기능에 대한 명세를 작성하는 것일 것입니다.

위에 보시면 기능에 대하여 두군데에서 언급을 하고 있는데 첫번째는 비개발자들이 기능에 대하여 이해할 수 있는 영역입니다. "제품" 항목에 들어 있는 기능이지요. 평이한 언어로 이해하기 쉽도록 사용자(고객)의 관점에서 기능의 목적과 이용방법 실행결과등을 기술합니다. 두번째는 아래의 "제품 기능 상세" 입니다. 여기서는 입력되는 값의 범위와 오류처리 방법등의 방식으로 명세 형태로 기능을 나타냅니다.

다음으로 개요에 보시면 특허 출원 유무가 있습니다.

 제품의 기능중에서 별도의 시스템 또는 기술로 분류하여 특허로 만들어 두게 되면 향후 이 기술에 대한 적극적 권리 보호가 됩니다. 이것이 왜 SRS에 들어가야 하는지에 대한 의문이 생기실 것인데 제품으로 출시가가 되고 난 뒤에 기술특허 출원을 하게 되면 종래의 기술로 분류되어 특허가 등록이 안 될 가능성이 많기 때문입니다.

    그리고 출원 및 등록에 비용이 발생하게 되며 , 해외 출원을 고려한다면 상당한 금액이 되기 때문에 개발계획에 이 부분이 반드시 포함됩니다. 특허 진행 여부를 사전에 밝히는 것이지요.

    다국어지원 같은 경우 우리나라에서 제작이 되는 SW이므로 기본적으로 한국어를 지원하겠지만 영업상황에 따라서는 해외 전용 SW를 제작하는 경우도 있고 , 전세계 대상 제품을 만들 수도 있습니다. 지원이 되어야 할 언어의 종류에 따라서 번역, 감수 등의 비용이 발생하고 일정에 영향을 미치기 때문에 개발 계획전에 확정을 해야 합니다.

    업그레이드방법이란 이 제품이 기존 제품의 업그레이드인 경우 또는 대체 제품인 경우 어떻게 할 것인가를 정해야 합니다. 예를들어 버전이 3.0 신제품이라면 기존 1.0 부터 3.0 이전의 버전 제품들을 어떻게 할 것인가 이지요. 1.0 제품은 2.0으로 업그레이드 한 후에 3.0으로 업그레이드 한다. 등과 같은 업그레이드 방법입니다. 그리고 한가지더는 제품의 온라인 업그레이드를 지원하는 지 여부를 밝혀 둡니다. 이런 지원이 되려면 다시 업그레이드 서버의 구성등이 추가되게 됩니다.

    요구분석 단계에서는 매우 중요한 이슈를 다루기 때문에 각 부서의 담당자들이 매우 민감해 질 수 있습니다. 특히 이 단계에서 PM은 커뮤니케이션에 주의해야 합니다.

SRS에 한 줄이 추가되면 엄청난 일들이 벌어지기도 하기 때문입니다. ( EAL4 CC인증 같은 것. )

요구분석이 끝나게 되면 각 부서는 개발에 필요한 일정을 산출하여 개발 계획을 작성하게 됩니다.

보통 연관 부서가 많기 때문에 일정 조절에 많은 노력이 들어가게 됩니다.

설계, 구현 , 테스트는 다음으로 미루겠습니다.

코딩가이드 작성하고 그리고 ...

오늘은 코딩가이드 작성에 대하여 말씀 드리겠습니다.

개발 프로젝트는 코딩이 필요한 부분이 매우 많지요.

HTML , CSS , JSP , Java , C++ , SQL , Procedure , XML 등일 것입니다. 이 중에서도 JSP와 Java프로그램은 여러명이서 나누어 개발하게 되는데 , 개발자간의 코딩 스타일에 다소의 차이가 있고 개발자 자신의 스타일도 조금씩 바뀌기 때문에 유사한 형태의 코드를 만들어 내기란 여간 어려운 것이 아닙니다.

그래서 제품개발이나 서비스 개발을 진행함에 있어서 일정한 기간마다 개발자들이 모여서 그 동안 작성된 코드의 리뷰를 하는 경우도 자주 봅니다. 물론 코드리뷰의 주목적이 개발자들간의 코딩 스타일을 맞추려는 것이 아니기 때문에 그 부분에 대하여 시간을 많이 할애하지는 않습니다만 누군가 리뷰를 하게 되는 진행이라면 개발자들이 "코딩 가이드"를 한 번이라도 더 보게 될 것입니다.

사족이지만 프로젝트 관리하시는 분들은 개발자들에게 일주에 1-2시간 정도라도 코드리뷰를 할 수 있는 시간을 꼭 주시기 바랍니다. 코드리뷰를 하는 과정이 개발자들 간에 맡은 업무에 대한 비지니스 로직과 개발 테크닉등의 정보교환에  사용되는 중요한 시간이 되기 때문입니다.

코딩가이드는 코드가 필요한 모든 부문에 다 만들어 두는 것이 좋습니다. HTML 같은 경우도 별도 코딩가이드를 정해 두어야 합니다. 화면상의 특정 콘트롤의 이름이 데이터베이스의 필드명과 일치시키는 것이 디버깅 과정에서 얼마나 많은 시간을 아껴주는지 모릅니다.

여기서 주의 하셔야 할 점은 이렇게 문서로 코딩가이드를 만들어 두기만 하면 제대로 지켜지기 어렵습니다. 코딩가이드를 제대로 적용시키려면 반드시 그 가이드를 100% 적용한 샘플 프로그램을 준비하셔야 됩니다. 이 샘플 프로그램을 탬플릿으로 활용하기 때문에 프로젝트 최초의 프로그램이 될 가능성이 높습니다.

첨부의 문서는 코딩가이드의 예입니다. ( 2004년도 자료일 겁니다. )

그리고 하나는 JSP 프로그램입니다. ( 다른 가이드가 적용된 것입니다. )

Coding_Guide_C++_2.txt

index_2.jsp

사업계획서 쓰기

안녕하세요. 이번에는 연간사업계획서 쓰기에 대한 내용으로 말씀드리겠습니다.

매년 다가오는 연말에는 다들 사업계획서 쓰시는 일로 바쁘시죠.

한해의 성과를 평가 해보고 다음해 해야 할 사업들에 대한 계획을 세우는 일이라 무척 중요한 일이긴 한데 막상 시작을 할려면 어디서 부터 해야 할 지 막막한 경우가 많습니다. 특히 R&D 분야에서는 느끼는 정도가 더 심할 것 같구요.

여기서는 사업계획서의 목차나 양식을 가지고 설명을 드릴려고 하는 것은 아니고 어떠한 내용이 들어가야 한다는 기본적인 것들을 가지고 이야기를 해 볼려고 합니다. 뭐든지 기본에 충실하면 아무리 어렵게 꼬아 놓더라도 쉽게 풀수 있지 않겠습니까.

사업계획의 내용은 크게 두가지로 나눌 수 있는데 , Operation 과 Strategy 입니다.

Operation 은 매일 주별 월별 분기별 반기별 등과 같이 주기적인 일들과 프로젝트 수행 등과 같이 기간의 주기성은 없지만 계속적으로 일어나는 일들에 대한 관리에 대한 것입니다.

그렇기 때문에 그 내용은 기간별 성과를 도출하고 그 원인을 분석해 보는 것입니다. 예를들면 분기 매출 목표가 얼마였는데 실제 그 분기의 자료를 취합하여 분석을 해보니 이런 이유로 초과 달성하게 되었고 저런 이유로 미달이 되었다 하는 것을 밝히는 것입니다.

조직별로는 적게는 3-4 개에서 많게는 20개 정도의 Operation 목표치들이 KPI ( Key Performance Index ) 형태로 존재하게 되는데 개발부문에서도 이러한 KPI들이 존재합니다. 주로 효율과 관련된 것들입니다. 예를들어 품질부분에서 제품 릴리스 이후 발견되는 치명적 버그의 수 같은 것 들입니다.

두번째 Strategy 부분은 앞서의 Operation 을 어떤 이유로 바꿀 필요가 있게 되는데 이를 위한 활동이 Strategy 입니다.

위에서 예로 들었던 치명적 버그 발생율을 당해 년도에 절반으로 줄이려는 Operation 목표를 세우게 되었는데 이를 달성기 위해서는 통상의 방법으로는 안되고 기간시스템의 개선이나 업무지원 소프트웨어의 개발이 필요하게 됩니다. 이에 따르는 프로젝트가 발생할 수 있고 제품 도입이 될 수 있는 일들이 Strategy 입니다.

두개의 구분은 다음과 같은 문장을 보면 명확해 집니다.

"Strategy 는 Operation 을 변경하는 일" - 어떤 분야에서는 Strategy 대신에 Management 를 넣기도 합니다.

이 두가지를 가지고

"계획이 어떠했는데 실행이 어떻게 되었고 분석해보니 이런 저런점들이 나왔다. 그래서 내년에는 어떻게 해야 되겠다."

의 단계로 작성을 하시면 무리가 없습니다.

사업계획은 크게 위의 두가지 항목에 대한 PLAN-DO-SEE 로 구성이 되고 이런 일들을 하기 위한 인력, 비용 등이 부가적으로 포함되어 년간 사업계획이 완성되게 됩니다.

요즈음 직장인들의 근무 기간이 벤처 같은 경우는 2-3년 정도이고 대기업이라고 하더라도 5-6년이기 때문에 장기적인 계획을 세우기는 좀 부담이 되는 부분이 있습니다. 그래도 년간 사업계획은 어느 직장을 가더라도 해야 되는 것이기에 기본을 알아두면 좋을 것 같은 생각에 몇자 적어 봅니다.

웹개발로 제품 만들다 늙어 죽을수도 있어요.#2

이번에는 지난회 "웹개발로 제품 만들려면 늙어 죽을수도 있어요." 에 이어지는 내용입니다.

지난번에는 계속되는 소스코드의 브랜치가 어떤 문제가 있는 지를 알려드렸습니다.

오늘은 그 해결책들에 대해서 설명을 해보고자 합니다.

사업하는 입장에서는 참으로 이상한 것이 , 비슷한 일인데 하면 할 수록 더 잘해야 될 것인데 비용이 점점 더 들어가는 상황이라니 말입니다. 제품의 문제점 파악 및 대안을 위한 워크숍같은 것 한 번 해야겠습니다.

여기서 나올 수 있는 대안은 대체로 다음의 두가지 정도입니다.

첫번째는 이리저리 고쳐 주는 것이 문제이니까. 아얘 패키지 제품으로 재개발을 한다는 것이고 두번째는 고비용 문제는 유지보수 업무에 해당하는 것이므로 이 업무를 외부업체에 아웃소싱한다 정도입니다.

문제는 첫번째나 두번째를 어느것을 선택하더라도 더 풀기 어려운 또다른 문제가 발생하기 때문에 실제로는 좋은 안이 될 수 없다는 점입니다.

커스트마이징은 고객의 요구사항이라서 뿌리치기 어렵습니다. 그렇다고 예상되는 요구사항을 모두 반영한 패키지화 된 제품을 만들려면 엄청난 비용이 들어가고 굉장히 어렵습니다.

두번째는 회사의 기술유출과 기존 고객관리가 안되는 점이 있어 영업리스크가 너무 높기 때문에 채택하기 어려운 결정입니다.

이 문제는 처음부터 다시 살펴보면 해결의 실마리가 보이지 않을까요.

처음에 어떤 프로젝트를 수행하고 나서 나오게 되는 산출물 , 이 산출물이 어떤 것이냐에 대한 정의를 내리면서 문제를 풀어보고자 합니다.

이 산출물이 재활용이 가능한 제품일까요 ?

웹시스템을 예로 들어 보겠습니다.

웹시스템을 구성하는 주요 요소는 웹서버/애플리케이션서버/데이타베이스서버 입니다.

다시 웹서버는 아파치, IIS , 제우스 등등 많은 벤더별로 나뉩니다. 그리고 그 벤더별 웹서버 제품의 버전이 나뉩니다. 설명을 간단히 하기위해서 3가지 벤더에 버전이 5개 라고 가정하면 전부 15개의 조합이 됩니다. ( 3 * 5 입니다. ) 그리고 웹서버에서 지원이 되어야 하는 여러 라이브러리들이 있습니다. SSL , SOAP 등 각 모듈마다 버전이 있을 것입니다. 이 두가지 모듈만 있다고 하고 버전이 5개씩이록 하면 전체 150 개 (3 * 5 * 2 * 5) 개의 조합이 가능합니다.

여기에 애플리케이션서버 환경으로 넘어가게 되면 좀 더 복잡합니다. 먼저 애플리케이션서버가 동작하기 위한 OS 환경이 조합되어야 하고 거기에 이 서버가 동작하는 데 필요한 외부 모듈이 최소 10여가지가 됩니다.

( 로그처리 , 데이터베이스 연결 , XML처리 , 파일업로드 , 각종문서파싱모듈 , 각종차트 , 리포트지원툴 , ... ) OS를 제외하고 10가지의 조합이 가능하다고 가정하고 , 지금까지의 환경 조합을 계산해 보면 벌써 1,500 개 ( 150 * 10+ ) 가 됩니다.

여기까지만 놓고 계산 해보면 웹서버/애플리케이션서버/데이타베이스서버의 기본구성의 환경에서 프로젝트 결과물이 문제없이 동작하기 위해서는 1/1,500 의 확율입니다. ( 데이터베이스 변수는 제외 )

즉 1,500 분의 1의 확율로 수정없이 재활용이 가능합니다. 제품의 기본 특징이 수정없이 수백 수천을 팔 수 있는 것 이라고 한다면 1/1,500 의상황은 이를 제대로 만족하지 못하게 됩니다. 결국 시스템 전체로는 재활용이 안되는 제품입니다.

이런 모든 환경에서 동작하는 시스템을 만들려면 지난글에서 말씀드린 것처럼 늙어 죽어도 안될 시간이 걸릴 것입니다. 될 수 있으면 웹개발로 제품 만들지 마시기 바랍니다.

그러면 반제품인가요?

반제품이라는 것이 일정 수준까지는 커스트마이징과 포팅을 고려한 설계를 하고 나머지는 라이브러리 형태로 제작을 하면 반제품이라고 할 수 있지 않을까 합니다.

제가 보는 문제 해결의 실마리도 여기에 있습니다.

제품과 같이 시스템 전체를 소스관리를 해야하는 방식에서 벗어나서 특정 부분만 소스 관리를 하고 나머지 커스트마이징, 포팅 부분은 별도의 레이어를 두고 관리해야 하는 것이 좋을 것입니다. 이렇게 함으로써 소스코드의 브랜치를 피할 수 있고 그에 따르는 비용을 줄일 수 있습니다. 이렇게되면 관리가 되지 않는 부분 즉 커스트마이징, 포팅 부분은 고객 또는 건별로 라이프싸이클 기간만 관리를 하고 이후 개별 종료 처리하는 것으로 하면 될 것입니다.

그러면 소스코드가 관리가 되어야 하는 부분과 그렇지 않은 부분을 나누는 것이 중요해 지는데 , 이부분에서 특정 레이어의 수준을 어느 정도로 할 지는 조직내의 CTO , 기술위원회 등의 도움을 받아서 정하는 것이 좋을 것입니다.

이렇게 나눌 때의 방식은 경험상으로 보면 외부연동부와 UI 는 커스트마이징 레이어에 놓이고 프레임워크 등은 관리부분에 놓이게 됩니다.

이번글은 구체적인 내용이 별로 없었 던 것 같습니다. 전달하고자 하는 내용의 요지는 웹시스템 같은 경우는 시스템 전체를 제품화 하려고 하면 너무 어려운 일이 될 수 있으므로 일부 또는 프레임워크 정도만 제품화 하시라는 말씀입니다.

*제품개발에 대한 말씀을 드릴려고 하는데 계속 밀리네요...

웹으로 제품 만들다 늙어 죽을수도 있어요.

주말 잘 보내셨나요?

저는 가족들과 김장했습니다. 집안에 냄새도 나고 몸은 힘들었지만 , 온 식구가 하나로 어울렸던 시간이었던 것 같습니다.잊지 못 할 추억이 될 듯합니다.

오늘은 웹개발에서의 소스관리의 어려움에 대하여 말씀드려 보도록 하겠습니다.

개발 프로젝트가 끝나면 산출물들을 정리하게 되는데 이 단계가 되면 다음 프로젝트가 정해지는 경우가 많습니다.

대개는 비슷한 업종의 비슷한 애플리케이션 개발인 경우가 많은데 , 회사의 사업전략은 기술전략과는 달리 대상 고객군과 분야를 정해서 짜여져서 진행되기 때문이지요.

이런 이유로 영업 , 기획하시는 분들이 개발관리자들에게 이런 질문들을 많이 하게 됩니다.

"이번 프로젝트 결과에서 조금만 바꿔서 다른데서 쓸려고 한답니다 , 어느 정도 개발이 필요합니까?"

"글쎄요 조금만 바꾼다는게..그냥 똑같이 한다고 해도 꽤 들어갈 텐데요"

"예? 어찌 그런일이...이해하기 힘든데요"

상황이 이렇게 되게 되면 이슈 회의가 소집되게 되고 원인파악부터 해서 어떻게 할 것인가에 대한 논의가 진행이 됩니다.

이런 회의의 결과는 대체로 "지난번 수행 경험을 살려 이 번 프로젝트는 낮춰서 진행하자" 가 될 것이고 결국 프로젝트를 좀 낮춰서 진행하게 됩니다. 그러고 나면 또 비슷한 개발 프로젝트를 계속하게 되는데 더 낮춰잡게 됩니다. 일정이나 금액 같은 것 말이지요. 결국 경영진이나 비개발 관리자들은 이런 생각을 하게 되는데 "우리회사의 제품은 완성이 되었고 개발 효율은 점점 좋아지고 있구나. 이일을 좀 더 확대 해봐야겠는데..."

계속 사업이 이렇게 진행이되어도 문제가 없다면 제가 오늘 이런 글을 쓰지는 않았을 것입니다.

위의 상황에서 제일 먼저 발생하는 문제는 담당 관리자 또는 개발자가 퇴사하고 나서 입니다. 기존 인력들에 비해서 교체된 인력들은 거의 절대 기존의 효율만큼 일하지 못합니다. 수행의 효율이 인력에 숙련도에 의해서 결정났기 때문입니다. 물론 이 것은 심각한 문제가 아닐 수 있습니다. 비용은 좀 들지만 다시 시작하면 되니깐요. 하지만 해결하기 힘든 큰 문제가 서서히 발생합니다. 바로 이리저리 변경 해준 기능들입니다.

솔루션이나 제품은 제작이 되고나서 부터는 유지보수의 단계로 들어갑니다. 유지보수에는 여러가지 일들이 포함되지만 크게 보면 두가지 인데 버그처리와 기능개선입니다. 이러한 수정들이 가해질 때마다 버전을 바꿔가며 관리를 하게 되는데 , 이 일이 만만치 않습니다. 예를들어 5.1 에서 발견된 버그는 그 대상이 되는 버전이 1.0 까지 수십개가 될 수 도 있습니다. 하나의 버그처리에 수십번의 코드수정과 테스팅이 필요하다고 생각해보면 정말 간단한 일이 아님을 알 것입니다. 그런데 위에서처럼 프로젝트를 할 때마다 기능을 수정해주게 되면 각각의 프로젝트의 소스 버전이 브랜치되는 상황이 발생했을 것입니다. 즉 예에서 말씀드린 수십개의 소스관리가 버전별로 뿐만 아니라 프로젝트별로도 관리를 해주어야 한다는 것입니다. 유지보수 비용이 기하급수적으로 늘어나게 될 수 밖에 없습니다.

물론 극단적인 방법으로 버그를 고쳐주지 않겠다면 위 문제는 발생하지 않습니다만 , 현실이 어디 그런가요.

깨끗하게 이 문제를 해결하기 위해서 큰맘먹고 업그레이드를 한다고 가정을 해보겠습니다. 가능 할까요 ? 어렵습니다.

이리저리 다르게 구현해준 기능들을 통합 할 수 있는 슈퍼셋이 존재하지 않습니다. 억지로 한대도 아마 늙어 죽을때까지 해야 할 수도 있습니다. 상황이 이런데 사업을 확대하면 어떻게 될까요. 결론은 뻔하겠지요.

이 문제 어떻게 해결해야 됩니까?

오늘은 시간이 안되서 문제만 띄워 놓고 다음에 해결 방안들에 대해서 말씀드려 보겠습니다.

R&D에서 R을 분리시켜 프로젝트를 하라

R&D에서 R을 분리시켜 프로젝트를 하라

오늘은 프로젝트 리스크 관리 부분을 말씀드리고자 합니다.

기획이나 제안 단계에서 개발자들이 일정을 제대로 못내는 경우가 있습니다. 이럴 때는 관리자로서 그 내용을 주의 깊게 기술적으로 살펴볼 필요가 있습니다. "다른 제품에도 다 있는 기능인데 무슨 문제가 있겠어. 개발자 실력이 안되는 것 아니야 ?" 라는 생각이 먼저 든다면 몇 달 뒤 정신적 육체적으로 정말 큰 고생을 할 가능성이 있습니다.

개발자들이 일정을 잘 못내는 경우는 보통 기술적인 문제가 있는 경우입니다. 이른바 "Technical Issue" 가 있는 것이지요.

이 Issue 는 사전 조사, 연구 과정을 거쳐야 판단이 가능한 것으로서 , 그 결과에 따라서 이 Issue가 쉽게 풀릴 수도 있고 그렇지 않을 수도 있습니다. 경험상 대부분의 경우는 후자에 속합니다. 위에서 "다른 제품에는 있는 기능이라는 것"의 의미도 안되는 일은 아니라는 정도로 이해 해야지 간단한 일이라고 판단해서는 안됩니다.

이러한 기술적 검토 없이 일정을 관리자가 대강 일정잡고 프로젝트를 진행해서는 안됩니다.

( 요즈음 이런 사람은 없겠지만, 특히, 관리자는 개발소요산정에 영향력을 행사해서는 안됩니다 )

그래서 일정이 안나오는 이런 "연구"가 필요한 분야는 프로젝트를 분리 진행하던지 아니면 사전 연구프로젝트를 진행한 후 그 결과를 보고 개발 프로젝트를 진행하는 것이 좋을 것입니다. 한정된 자원을 가지고 진행하는 개발 프로젝트에서 연구가 필요한 분야를 함께 가져 간다는 것은 결과를 예측 할 수 없는 대단히 위험한 프로젝트 관리가 될 것입니다.

프로젝트 중간에 Technical Issue가 나오게 된다면 정말 문제가 아닐 수 없습니다.

- 프로젝트 진행전에 반드시 기술 리뷰를 거쳐야 합니다. ( 기술위원회 또는 CTO가 있다면 좋을 것입니다. )

- R 과 D가 같이 있는 프로젝트는 분리하던지 아니면 순차적으로 진행해야 합니다.

   **R 프로젝트와 D 프로젝트는 진행 방법부터 다릅니다.

- 개발자 일정 산정 과정 및 결과를 주의깊게 살펴 보시기 바랍니다.

프로젝트 문서작업

오늘은 프로젝트 문서작업에 대하여 말씀드리고자 합니다.

보통의 경우에 SW개발 프로젝트가 끝나갈 즈음이 되면 검수를 위해서 발주처는 산출물들을 요청하게 됩니다. 계약사항에 명기된 인도품에 대한 검수 절차에 들어가는 것이지요. 어떤 경우에는 그 종류만 20여가지가 되는 문서 작업을 추가로 해야 하는 경우가 발생할 수도 있는데 , 나중에 사용되지도 않을 문서들을 작성하기 위해 개발 라이프싸이클 초기부터 기억을 더듬어 정리를 한다는 것은 개발팀으로서는 여간 고역이 아닐 수 없습니다.

"프로젝트 라이프싸이클 모델"을 어떻게 적용하는가에 따라 상당히 다르겠지만 ( 12207 같은 ) 이러한 산출물들의 예를 들어보면 아래와 같습니다. ( 인터넷에서 잠깐 긁었습니다. 내용에는 크게 관심갖지 마십시요. )

01. 착수

      01. 제안서

      02. 프로젝트 계획서

      03. 프로젝트 일정

02. 분석

      01. 기능 요구 사항

      02. 기능 흐름도

      03. 시스템 구성도

03. 설계

      01. 메뉴목록 및 구조도

      02. 화면목록 및 설명

      03. 데이터 흐름도(Data Flow Diagram)

      04. Entity 목록 및 상세

      05. ERD

04. 개발

      01. 작업 일정 및 담당자 배정표

      02. 어플리케이션 구조도

      03. 공용모듈목록 및 설명

      04. 개발 산출물 디렉토리별 설명

      05. 화면별 오브젝트

      06. 단위테스트 결과서

      07. 통합테스트 결과서

05. 구현

      01. Client 설치 및 운영메뉴얼(사용자 메뉴얼)

      02. Server 설치 및 운영메뉴얼(운영자 메뉴얼)

      03. 인수인계 계획서

      04. 검수 확인서

99. 참고자료

      01. 회의록

      02. 업무보고

문서가 한두장 정도라면 부담이 안되겠지만 , 책 한권 분량이 되는 문서도 있어 진짜 난감한 일이 아닐 수 없습니다. 게다가 이런 일에 대한 일정을 충분히 반영 해두지 않는 관리자가 있었다면 퇴근은 다 틀린 이야기입니다. 현실적으로 더 심각한 것은 실제로 이 문서들의 대부분은 유지보수 또는 추가개발등의 단계에서 재활용이 될 이유가 없다는 것입니다. 심하게 말하면 아까운 하드디스크 용량만 차지 한다는 것입니다. 이런걸 주고 받으려고 주소록 찾아가며 이메일도 주고 받고요.

이렇게 할 문서 작업은 차라리 하지 않는 것이 좋습니다.

고객을 설득하시기 바랍니다. 그 시간에 품질개선 작업을 하겠다고요.

내부 감사가 있어서 안된다고요 ? 문서의 품질에 대해 협상을 하시기 바랍니다.

이런 문제가 발생하는 원인은 제안 단계에서 또는 프로젝트 초기에 협의가 되었어야 할 사항을 놓쳤기 때문이기도 합니다.

문서작업에 대한 관점을 바꿔 보겠습니다.

먼저 프로젝트 관리자 (PM)은 이 번 프로젝트를 어떻게 진행 하겠다는 세부적인 계획이 있어야 합니다. 이 계획 수립 단계에서 개발자(리더)들을 활용 할 수는 있겠지만 주요 결정은 관리자가 해야 합니다.

여기서 관리자들이 기본적으로 생각하셔야 할 것은 "산출물"은 말 그대로 프로젝트를 진행하다보면 저절로 나오게 되는 문서가 되도록 계획을 해야 한다는 것입니다. 아래의 그림은 소프트웨어 라이프싸이클을 따라가며 발생 할 수 있는 문서들을 모두 나타낸 것입니다.

그런데 이 모든 문서가 다 나오게 되는 프로젝트 계획을 만들 수 있을까요 ?

아마도 이집트 피라미드 건설과 같은 일은 위의 그림에 나온 문서 만으로도 모자랄 수 있겠지만  현실에서

그런 계획을 세우기는 어렵습니다. 여하튼 계획을 세우게 되면 그 계획이 진행되는 경로를 따라서 발생하게 되는 문서들이 산출물들이 되는 것입니다.

그래서 산출물은 프로젝트를 하게 되면 저절로 나온다는 것이지요. 진행하지도 않은 프로세스 단계의 결과 문서가 나와서는 안된다는 것입니다. DFD ( Data Flow Diagram ) 같은 경우 , OOP 기반의 웹개발 환경에서는 작성의 필요가 거의 없습니다. 그리고 모듈명세서 등의 모듈기반의 여타 설계가 없는 프로세스에서 DFD를 만든다는 것도 앞뒤가 맞지 않습니다.

웹개발의 경우에 대체로 나올 수 있는 산출물은 다음과 같습니다.

- 제안서 : 이미 작성이 되어 있을 것입니다.

- 프로젝트 계획서 ( Scope & Plan ) : 프로젝트에서 개발의 범위를 정의해 둔 문서입니다.

- SRS ( Software Requirement Spec. ) : 기능 요구사항과 시스템 요구사항 , 품질기준 등등

       다음단계의 설계 작업에 영향을 미칠 수 있는 모든 사항을 명세화 해두는 문서 ,

       프로젝트에서 가장 중요한 문서로서 관리자, 고객, 개발자, 등 프로젝트 관련된

       모든 사람이 관여되는 문서

- 설계서 ( 데이터베이스 , 화면 , Action , SQL ) : UI 디자인 , 테이블 구성 , ERD , SQL 등 , 규약서 등

        디자이너 , UI개발자 , 설계자 , 관리자가 관여되는 문서로서 구현 단계에서 필요한 모든 내용을 기술

- 구현 스캐쥴 ( Time Table ) : 지난 포스팅 참조 "조엘따라하기"

        구현단계는 설계에 따른 구현 일정대로 구현을 진행

- 테스트 결과서 : SRS에 명기된 기능리스트를 중심으로 작성한 테스트 대상 리스트 및 그 결과

- 잔여 버그 및 개선이 필요한 사항

- 사용자 / 관리자 설명서

프로젝트 문서라는 것은 프로젝트 라이프싸이클의 진행에 따라서 현재 단계에서 나오는 문서는 다음 단계에서 진행이 되어야 할 내용들을 정리해 두는 것이라고 이해를 하셔야 되고 또 그렇게 작성을 하시면 됩니다. 즉 요구분석 단계의 산출물인 SRS는 설계단계에서 사용하게 되는 것이고 설계 단계의 결과인 설계문서는 다시 구현 단계에서 담당자들이 사용하게 되는 것입니다. 이렇기 때문에 문서는 프로젝트를 진행하게 되면 저절로 나오는 것이지 종료단계에 시간을 잡아서 한꺼번에 몰아서 하는 것이 아닙니다.

이번 글 문서 작업에 대하여 정리해 보겠습니다.

1. 관리자는 프로젝트 초기에 개발 프로세스를 세부적으로 정하여 필요한 산출물을 확정해야 한다.

2. 프로세스상 현단계의 문서 작성의 기준은 다음 단계에서의 활용을 기준으로 한다.

    프로젝트 멤버들간에 이미 알고 있는 내용들은 생략합니다.

3. 관리적으로 문서작업은 별도 시간을 잡지 않는다.

글을 쓰다보니 SI 형태의 개발에 관한 글이 많군요. ( 서비스 형태의 프로젝트이지요. )

시간나면 제품 개발 프로세스에 관해서도 써봐야겠군요.

 

개발자 제안서 쓰기

오늘은 "개발자 제안서 쓰기" 라는 주제로 말씀을 드리고자 합니다.

개발자의 경우 프로젝트가 종료가 되고 나서 이어지는 프로젝트가 없는 경우, 보통 다음 프로젝트 준비를 하게 되지요. 이런 기간에는 개발자가 영업담당자와 함께 고객사를 방문하기도 하고 제안 업무에도 참여하게 됩니다.

전제적인 제안작업은 영업담당자 ( 또는 기획담당자) 가 이끌게 되지만 개발자가 맡아서 해야할 부분도 많이 있습니다. 물론 회사의 표준제안서를 이용하여 각각의 제안에 맞게 변경을 하여 사용하는 경우라면 그다지 많지는 않겠지만 말이지요.

아래는 예를 들어서 본 제안서의 목차입니다. 3장이 기술부문이라서 나머지 목차는 간단히 줄였습니다.

일단 이 나머지 부분들은 누군가 다른 사람이 쓴다고 가정을 하겠습니다.

_____________________________________________________

1. 제안개요

2. 제안업체 일반사항

3. 기술부문

    3-1 제안시스템 구성 개요

        3-1-1 구성도

            3-1-1-1 전체 구성도

            3-1-1-2 단위 구성도

        3-1-2 구축전략

            3-1-2-1 현황/요구사항 분석 및 구성전략 도출

            3-1-2-2 네트워크 구축 전략

    3-2 시스템 구성 및 구성내역

        3-2-1 네트워크 구성방안

            3-2-1-1 네트워크 구성의 개요

    3-3 제품별 세부 사양서

        3-3-1 제품 선정

        3-3-2 제품 총괄표

        3-3-3 시스템 상세 사양 및 기능

            3-3-3-1 제품 개요 및 세부규격

            3-3-3-2 제품비교

            3-3-3-3 기능 및 특징

            3-3-3-4 설치사례

            3-3-3-5 요구사양 비교표

4. 제안시스템 운영방안

5. 이행방안

6. 유지보수 및 기술지원 계획

7. 사업관리 방안

_____________________________________________________

이런 목차는 제안을 요청하는 발주처에서 만들어 주는 경우가 많습니다. 제안 업체가 많기 때문에 업체간 비교가 용이하도록 양식을 통일해 보려는 것이지요. 때문에 표준 제안서가 있다고 해도 내용의 순서가 맞지 않거나 빠진 부분이 있어 보완을 해야 합니다. 표준제안서가 없는 경우라면 완전히 새로 만들 수 밖에 없겠습니다.

어쨌던 제안서 작성에서 중요한 것은 발주처에서 원하는 목차에 맞는 내용을 채우는 것이 될 것입니다.

그런데 여기서 문제는 목차에 나와 있는 기술 용어에 대한 이해도가 조직마다 또는 개인마다 다를 수 있기 때문에 발주처가 원하는 내용이 들어가지 않고 다른 내용이 들어가는 경우가 발생한다는 것입니다.

결국 이런 용어들에 대한 정확한 정의가 되어 있어야 정확한 제안서를 쓸 수 있을 것입니다.

3장부문에 나와 있는 용어들을 살펴보면 다음과 같습니다.

"기술" , "시스템" , "전체 구성도" , "단위 구성도" , "구축 전략" , "시스템 구성 내역" , "제품" , "사양서"

이 글을 보시는 분들은 위의 용어들을 일상에서 많이 접하는 분들일 것입니다만 , 개발자라고 하더라도 위의 용어에 대한 정의는 쉽지 않을 것입니다. 그래서 막상 제안서를 쓰면서 어렵다고 느끼게 되는 이유가 바로 이 점 때문이라고 생각이 됩니다.

 

그래서 이런 용어를 중심으로 제안서에 들어갈 내용을 나름대로 정리해 보겠습니다.

( 일반적인 정의가 아닙니다. 제 의견이 들어 있습니다. )

3. 기술부문

    : 기술( Technology ) 은 시스템 ( System ) 또는 디바이스 ( Device ) 를 말하는 것이라고 생각하시면 됩니다.

      또한 기술에는 이러한 것들을 만들 수있는 방법( Process , Method )도 포함이 됩니다.

    3-1 제안시스템 구성 개요

    : 시스템( System ) 은 입력을 받아서 내부 프로세스에서 처리를 한다음 출력을 만들어 내는 것입니다.

      따라서 입력, 처리프로세스, 출력이 시스템의 구성요소 입니다. 단, 내부프로세스는 다시 서브시스템으로

      구성이 될 수 있습니다.

 

        3-1-1 구성도

            3-1-1-1 전체 구성도

     : 전체 구성도는 위에서 정리해드린 시스템의 최상위 도면 입니다.

       즉 입력-처리프로세스-출력 이렇게 이루어진 그림입니다.

 

            3-1-1-2 단위 구성도

      : 단위 구성도는 전체 시스템을 이루는 서브시스템을 설명한 도면 입니다.

        3-1-2 구축전략

      : 구축전략은 구축하고자하는 시스템의 최종 모습을 이루기 위해서 누가, 언제 , 어디서 , 어떻게 , 무었을

        한다라는 내용이 들어가면 됩니다.

            3-1-2-1 현황/요구사항 분석 및 구성전략 도출

            3-1-2-2 네트워크 구축 전략

    3-2 시스템 구성 및 구성내역

      : 시스템 구성내역은 위의 시스템 구성도에 나온 내용을 글로써 설명한 내용입니다.

        3-2-1 네트워크 구성방안

            3-2-1-1 네트워크 구성의 개요

    3-3 제품별 세부 사양서

      : 제품은 디바이스 ( Device ) 또는 패키지형태의 소프트웨어을 말하는 것입니다.

        개발 또는 커스토마이징이 필요한 시스템이라면 제품 보다는 솔루션이라고 표현하는 것이 좋겠습니다.

        3-3-1 제품 선정

        3-3-2 제품 총괄표

        3-3-3 시스템 상세 사양 및 기능

      : 사양서는 제품의 동작에 필요한 입력명세와 그 결과로 나오게 되는 출력에 대한 명세를 기술한 것입니다.

            3-3-3-1 제품 개요 및 세부규격

저 같은 경우도 남들이 해 둔 제안서를 보면서 정확한 의미에 대한 생각없이 이리저리 짜집기를 했던 적이 많았고 또 앞으로도 계속 그렇게 하게 되겠지만 그래도 내용에 대한 의미는 한 번 짚어보자는 의미에서 정리해 보았습니다.

CTO의 역할

CTO의 역할

회사의 규모가 일정 정도 이상이 되면 기술 부문 이사를 별도 분리하여 CTO 형태로 운영하는 곳이 많이 있습니다. 저도 오래전에 국내 모 포탈회사에서 CTO를 1년 반 정도 지낸 적이 있었습니다 만, 그런데 이 CTO가 뭘하는 사람인지(또는 조직인지) 업계에 계시면서도 잘 모르는 분들이 꽤 계시고 , 제가 생각하는 것과는 전혀 다르게 이해하시는 분들도 계시더군요. 그래서 오늘은 제가 생각하는 CTO의 주요 역할에 대해서 몇 자 적어 보고자 합니다.

기본적으로 아셔야 될 것은 CTO ( Chief Technology Officer ) 는 회사의 이사라는 사실이지요. 주주총회에서 선임을 받아 일정기간동안 주주의 이익을 위해서 일해야 하는 아주 기본적인 임무가 있습니다. 그리고 관련 업계에 필요한 기술에 대하여 정통한 지식이 있고 이 기술의 동향을 알고 있는 사람들이 보통 CTO를 맡게 됩니다.

그러면 이 두가지를 합쳐보면 자질과 임무가 나오는데 이렇습니다.

"업계의 정통한 기술 지식과 동향을 파악, 이를 의사결정에 활용하여 주주의 이익을 극대화하는 사람"

그런데 위와 같이 정의를 해두고 다시 보게 되면 , 문장으로 정의는 잘 되었는데 실제 어떤 일을 하는 지 구체적으로 감이 잡히지 않습니다. 대체적으로 방향은 알겠는데 공허하다는 것입니다. 기술 영업하는 사람이라는 것인지 , 뭔지 알 수 없습니다. 두 문장의 사이에 "어떻게" 라는 부분이 빠져 있어서 그렇습니다.

첨부의 자료는 CTO의 역할에 대한 내용으로 보고서를 낸 자료입니다.

CTO의 역할을 중심으로.pdf

CTO는 참 여러가지 역할이 있다는 것을 보실 수 있을 것입니다.

그런데 말입니다.

이런 모든 CTO의 역할들을 읽어나가시다 보면 그 내면에 공통으로 깔려있는 경쟁이라는 개념을 발견하실 수 있을 것입니다. 현대는 어느 기업이나 무한 경쟁의 상황에 놓여 있지 않습니까. 따라서 전략이 너무나도 중요해진 시기이지요.

전략경영으로 유명한 마이클포터의 5Forces 모델을 보시게 되면 , 기업은 주변의 여러 "힘"들의 영향을 받게 됩니다. 이 힘들간의 강도에 따라서 기업들이 전략을 수립해야 된다는 모델이지요. 경영의 일부로서 기술 ( Technology ) 도 마찬가지일 것이라는 생각이 드시지 않나요?

기술적인 관점에서도 주변의 힘(기술)들이 어떻게 형성이 되어 있느냐를 파악해서 힘(기술)들간의 경쟁에서 이길 수 있는 최적의 기술전략을 찾아내는 일이 필요합니다. 또한 이러한 전략이 수행되게 하고 그 결과에 따라서 수정 전략을 수립하는 일들도 있어야 합니다.

이러한 관점에서 CTO의 여러가지 역할이 있겠지만 ,

CTO의 기본적이면서도 가장 중요한 역할은 (기술)전략의 수립과 실행이라는 생각입니다.

참고) 전략은 간단히 , "(누가) 무엇을 (언제) 어떻게 할 것인가를 정하는 것" 입니다.

개발자 뽑기 - 코딩테스트 문제내기

개발자 뽑기 - 코딩테스트 문제내기

SW개발회사에서의 자산은 개발자와 프로세스라는 분들이 있습니다, 무슨 소리냐 개발은 문화 , 기술(시스템)이 자산 아니냐 뭐 이런 분들도 있을 수 있겠습니다. 어쨌던 개발회사에서 개발자는 중요한 존재임에는 분명합니다. 그래서 오늘은 이러한 개발자 채용에 관한 방법을 이야기 해보고자 합니다.

관심있게 보는 AllOfSoftware ( allofsoftware.net ) 블로그에도 최근에 "뛰어난 개발자 ~" 라는 주제로 씨리즈글이 올라와 있던데  사실 뛰어난 개발자를 가려내기는 정말 쉽지 않습니다. 특히 아주 짧은 순간의 채용 면담(질문/답변)으로 개발자들의 기본 자질을 가려낼 수 있다는 말은 사실 거짓에 가깝습니다. 코딩을 해보게 하고 그 내용을 평가해 보는 것이 직접적이고 확실한 방법이라고 생각합니다. 하지만 여러가지 이유로 이러한 사전테스트에 응하지 않는 개발자도 많고 , 특히 중소개발업체는 채용에 응하는 개발자 자체가 거의 없는 것이 현실이기 때문에 이런 테스트를 거친다고 한다는 상황이 말도 안되는 소리일 수 있습니다.

그렇지만 코딩테스트를 해본 사람의 경험으로서 말씀드리자면 , 가능하다면 , 되도록이면 , 반드시 진행 해 보시라고 권하고 싶습니다. 채용 공고등에 관련 절차에 집어 넣는 것도 방법일 것입니다.

아래는 제가 '06년도에 개발하고(?) 사용했던 , 코딩테스트 문제가 들어 있는 기술력 평가지 입니다.

일종의 시험을 보는 것입니다.

=====================================================================================================

1차 면접 / 기술력 평가 시트

일자        : 2006년   월   일  

지원자 성명 :

평가자 성명 :

1. 네트워크

   OSI 7 Layer 에서 TCP / IP 가 차지하는 Layer는 어디 어디인가 ?

   OSI 7 Layer 에서 Physical 에 해당하는 요소들은 어떤 것들이 있는가 ?

   DataLink 층을 이루는 네트워크 표준들은 무엇이 있는가 ?

   기준 ) 각 문항에 대한 2가지 이상의 답을 제시해야함

2. 데이타베이스

   프로그램 코드에 SQL이 내장된 채로 구현된 시스템과 이를 별도로 분리한 시스템의 장단점을

   시스템 구축과 유지보수의 관점에서 설명하라 !

   기준 ) 답변의 타당성

3. 코딩테스트 결과 설명 : 문제파악 , 알고리즘설명

    기준 ) 본인이 작성 한 것인가 ?  문제를 정확히 파악했는가 ? 답은 맞는가 ?

비중 30 % :           /  30

4. 주요 프로젝트 경력에 관한 정확한 기술 : 이력서에 있는 내용중에서 본인이 맡은 부분을 정확히 기억하여 설명하라

    기준)  과거 프로젝트를 잘 기억하고 있으며 활용이 가능한 기술인가 ?

5. 구현된 시스템의 본인 담당 부분에서 장애가 발생했다면 어떠한 순서로 조치를 취하고자 하는가 ?

   기준 ) 프로젝트의 상황에 맞는 조치를 취하였는가 ?

비중 40 % :           /  40

6. 코딩테스트

   가. 확율을 구하는 프로그램을 만드는 것이 목적임

   나. 입력 : Command Line ( Dos , Unix , ... ) 에서 1< 자연수 * 2 < 23  짝수를 입력 받음

   다. 처리 제약사항

        - 입력으로 받은 짝수는 사람의 숫자이다.

        - 그 숫자의 절반인 사람은 500원을 가지고 500원짜리 과자를 사려고 한다.

        - 나머지 절반의 사람은 1000원을 가지고 500원짜리 과자를 사고 , 500원을 거슬러 받으려고 한다.

        - 과자를 파는 곳이 단 한군데 뿐이라서 과자를 사려는 사람은 일렬로 줄을 서서 순서를 기다렸다 과자를 사야한다.

        - 과자를 사는 사람들이 일렬로 줄을 서는 순서는 일정한 규칙이 없다.

        - 과자를 파는 사람은 최초에는 거슬러 줄 돈이 하나도 없다.

        - 과자를 파는 사람은 거스름돈이 없으면 더이상 과자를 팔 수 없다.

    라. 출력

        - 입력받은 사람들이 전부 과자를 살 수 있는 확율  

        - 범위 / 유효숫자 : 0.0000 <= 실수 =< 1.0000

    마. 기타 제약

        - 위의 문제를 푸는 방법은 "반사의 법칙"을 이용한 공식이 있으나 이를 이용해서는 안된다.  

        - 코딩의 상단 부분에 문제에 대한 이해 , 접근 방법 , 주요 알고리즘을 기술할 것

비중 30 % :           /  30

1차 면접 : 기술력 종합 평점 :        / 100    -->     S     A     B    C    D

=====================================================================================================

6. 번의 코딩테스트 문제는 면접진행 전 1주일 전에는 이메일로 전달이 되어야 합니다.

어떤 개발자는 반나절만에 답이 오기도 했지만 결과가 안 좋았습니다.

코딩테스트 결과 메일에서 보셔야 될 부분은 다음과 같습니다.

1. 실행이 되는가 ?

2. 사용자 입력 이후 실행 시간은 얼마나 걸리는가 ?

3. 소스코드에 comment 는 적절히 사용하는가 ?

4. 에러처리는 적절하고 실행중간에 오류는 없는가 ?

5. 알고리즘은 어떤 것을 사용하였는가 ?

6. 입력 값이 증가 함에 따라서 실행 시간이 증가하는 비율은 어떤가 ?

7. 함수,메소드 분리는 적절한가 ?

8. 코딩컨벤션은 적용이 된건가 ?

면접시에는 이러한 부분들에 대한 개발자의 의견을 물어 보는 것도 좋은 방법이 될 것입니다.

채용시에 개인의 배경이나 인성을 중시하는 분들도 있는데 , 물론 이런 부분도 중요하지만

개발은 엄연한 현실이고 개발자는 요구분석, 설계, 코딩을 잘해야 합니다.

Function Point

오늘은 Function Point 에 대하여 말씀드리겠습니다.

SW 개발 프로젝트의 개발 소요 산정하는 기준인 FP ( Function Point ) 를 실무에서 사용하기 편하도록  양식으로 만들어 보았습니다.

첨부의 문서

"2009 소프트웨어사업 대가의 기준 해설" 는 '09년 5월 진흥원 자료입니다.

"사업예산수립시 기능점수(FP) 산출실무" 마찬가지로 진흥원 SW공학센터 자료입니다.

FP는 사업수행자의 관점에서도 볼 수 있지만 , 발주자의 입장에서 전체 소요를 예상해 보고 필요시 사업계획에 반영을 하는 기준 수치가 되는 자료를 제공합니다.

살펴보시면 내용중에는 상당히 많은 특정 숫자들이 존재합니다. 언어별 가중치 같은 숫자들 입니다. 이 숫자들에 대한 근거까지는 확인해 보지 않습니다. 진흥원에서 특정 연구가 진행되어 필드의 실측치가 산출되었을 것으로 생각할 뿐입니다.

참고로 , 2010년 5월 부터는 공공발주는 FP를 이용한다는 보도가 있었습니다.

첨부의 엑셀 문서중 마지막 Sheet 는  제가 MM ( Man Month ) 기준 프로젝트를 하면서 이를 FP방식으로 재 산정 해본 것입니다. 관리자마다 많은 차이가 있을 것으로 생각됩니다만 , 두가지 기준을 서로 비교해 보면 FP기준 원가가 MM 기준보다 많습니다. FP 소요산정치가 예산이 될 것이므로 FP 기준으로 발주가 이루어져도 실제 수주금액은 이보다 낮아져 비슷해지지 않을까 합니다. (다른 모든 상황이 같다면 말이죠.)

FP방식이 중요한 것은 현재의 MM 기준의 소요산정은 결과지향적이지 않고 과학적이지도 않습니다.

뭐냐면 , 투입되는 개발자의 등급, 투입 기간 등이 원가 산정의 기준이고 전부 입니다. 하지만 그렇게 개발자 투입을 하더라도 결과가 달성된다는 보장은 또 다른 문제란 것입니다.

하지만 FP기준의 프로젝트라면 투입인력 기간등의 제약에서 벗어나 수행업체마다의 효율적인 방법으로 결과물을 만들어 내는 방법 개발이 가능해서 다양한 수행 방법이 생겨날 것입니다.

좀 더 나아가서 바래본다면 , MM 방식의 단가 경쟁 구조 ( SI 개발 악순환 구조 ) 를 벗어나서 개발 경쟁력을 개발, 이를 확보한 업체들이 살아남아 시장을 형성해가는 , 현재와 같이 개발자 모집 , 배급 방식과 같은 인력시장 형태를 벗어나 , Software House 같은 개발 회사가 많이 생길 수 있는 환경이 되기를 바래봅니다.

2009 소프트웨어사업 대가의 기준 해설_1.pdf

기능점수 측정 실무 매뉴얼_1.pdf

기능 점수에 의한 개발비 산정 양식_1.xlsx