통합검색
· 마을서비스란?  · 포럼마을  · 일반마을  · 테마마을  · 마을랭킹  · 활동왕
· 덱스퍼트란?  · TECBOX   · PRSBOX   · 이용안내  
· DEXT제품군  · 솔루션베이  · S/W & ESD 컴포넌트
· 프로그램베이
· LiveSeminar  · LiveConference
  마을등급 Architecture   이 마을은 포럼마을 입니다이 마을은 자유가입제 마을 입니다 마을소개 페이지로 이동 전입신청
마을촌장촌장 손영수 주민 963 since 2006-12-28
우리마을 공지사항
질문&답변
강좌&팁
자유게시판
자료실
앨범
개인게시판
[마을 게시판]
Architecture&Design
Pattern
Testing & QA
Development Process
SOA & SaaS
Eva네 컬럼
진행중인 스터디
Eva 네
Jornadan 네
랑데브 게시판
칼럼 게시판
개발자 고충상담
Dev Talk
자유토론방
벼룩시장
재나미 우스개
구인/프로젝트 정보
사람인 채용 게시판
  고객지원 게시판
마이 데브피아
 나의 e-Money 내역
 활동왕 My Page
 스크랩한 게시글보기
 쪽지관리
 주소록관리

 Development Process
 땅콩버터와 마천루 (Feature and Scenario) 2008-05-26 오후 1:08:50
 only2u4u  only2u4u님께 메시지 보내기only2u4u님을 내 주소록에 추가합니다.only2u4u님의 개인게시판 가기 번호: 36465  / 읽음:2,342

데브피아 아키텍쳐 시삽

(http://www.arload.net - 아키텍트로 가는 길)

 

 

 

혹시 소프트웨어를 만드실때, 땅콩버터 방식으로 만드시지는 않나요?

 

땅콩 버터라는 것은 Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스를 말합니다.

 

Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들때 주로 사용하는 방법입니다.이 방식은 견고하고, 더디지만 모든 Feature들이 골고루 기능 향상을 가져올수 있는 장점이 있습니다.

 

마치 땅콩 버터 (Peanut Butter) 처럼 모든 기능들이 골고루 퍼지고 진화할수 있어서 땅콩 버터 방식이라고 말합니다. 흔히 하위 레벨의 Framework이나 저수준의 Library를 개발할때는 이러한 방식이 선호 됩니다.

 

만약 여러분의 소프트웨어가 고객의 요구사항들을 많이 받아 들여야하고, 다양한 시나리오를 요구하는 경우인데도,

Feature 에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요?

 

국내의 많은 회사들이 이러한 구조를 가지고 있는데요. 새로운 시나리오가 탄생하면 많은 조직들이 협업을 해야 될뿐만 아니라, 딱 기능을 나누기에 애매한 경우 많은 정치, 책임의 분배 문제등이 발생됩니다.

 

 

반면에 이와 상반된 방식으로 마천루 (Skyscraper) 방식이 있습니다.

 

시나리오가 마천루처럼 높이 솟아 전체 소프트웨어의 기능을 구현하기 위한 좋은 기준이 된다는 것입니다.

 

명백한 기준이 있다는 것은 많은 시행착오를 줄일수 있을 뿐만 아니라. 고객의 관점에서 소프트웨어를 생각할수 있는 장점을 가질수 있습니다. 흔히 우리가 알고 있는 시나리오를 만들고 Protoype 방식으로 개발을 해 나가는 것이라고 생각하시면 됩니다.

 

바로 Top-Down 방식의 프로세스가 여기에 해당되어 지는데요. 여러분의 소프트웨어가 상위 레벨의 응용 소프트웨어로써, 많은 분들이 사용한다면 당연히 시나리오 기반( Sckscraper)의 방식으로 소프트웨어를 설계하는 것이 좋을 것입니다.

 

마이크로소프트의 VS2008 경우 개발자와 디자이너간의 협업에 중점을 두고 많은 시나리오를 만든 다음 제품을 개발했다고 합니다.

 

역시 이 방식도 단점이 있는데, 시나리오 기준으로 하다 보니 소

프트웨어가 잘 정리된 일괄적인 구조로 설계 되기 어렵고,

특정 Feature들이 먼저 개발되는 급성장으로 인해 전제 모듈간의 불균형을 야기시킬수 있습니다.

그리고 갑자기 시나리오가 수정된다면, 이것이 소프트웨어 구조에 많은 영향을 미치게 됩니다.

 

바로 땅콩버터가 언급하는 점진적이면서 균형있는 발전이라는 장점을 잃어버리게 됩니다.

 

그럼 둘다 장,단점이 있는데 ,단점을 상쇄 시키고 장점을 얻을려면 어떻게 해야 될까요? 정답은..이것들을 적절히 혼용하는 것이겠죠 ^^

 

이전 포스팅인 "Microsoft 가 좋은 소프트웨어를 만들수 밖에 없는 이유"에서 언급한 것과 같이 땅콩 버터 (기본적인 기능부터 구현해서 점진적으로 기능을 추가) 방식을 유지하되, 릴리즈가 거듭될때마다 더불어 사용 가능한 시나리오들을 점진적으로 증가시켜 테스트하는 방식이 좋은 예가 될것입니다.

 

물론 이러한 프로세스를 하기 이전에 잘 정의된 계획과 합리적인 조직 구조가 기반이 되어야 가능한 방식일 겁니다.

 

회사에 말단으로 있을때는 단순히 설계에만 관심을 가졌는데. 요즘은 더욱더 프로세스의 중요성을 깨닫게 됩니다.

 

혹시 이글을 읽는 분중에,

마천루 또는 땅콩버터 + 마천루를 결합한 프로세스를 경험하신 분이 있으시면 여러분의 이야기를 저에게도 들려주시겠습니까? ^^

[코멘트] 좋음
2008-05-27 01:27
 gonfly  gonfly님께 메시지 보내기gonfly님을 내 주소록에 추가합니다.gonfly님의 개인게시판 가기 
전에 다니던 회사내 개발 과정을 보면 처음 시작은 PM에서 이번 버전엔 어떤 기능이 들어갈것인가를 결정합니다. 그 에 따라 R&D, QA, UI부서에서 핵심적인 인간들의 회의를 거쳐 보다 세밀한 기능을 정한후 최종 SRS를 만들고 그 걸 가지고 UI팀, QA, R&D 다들 각자 보다 자세한 계획을 세우죠. 최종 개발자에게 오는 문서는 UI팀에서 만든 문서였습니다. 물론 SRS도 보긴하는데 그림이 없고 죄다 글로 표현하니 이해 속도가 그림을 보는것보다 느렸습니다. 일단 계획된일정에 맞쳐 릴리즈 한후 여기서 넣지 못하거나 부족한 부분은 다음 패치 버전 계획에 들어가게 스케줄이 만들어 지더군요. 일단 맨땅에서 새로 시작한 프로젝트가 아니래서 따져보면 마천루 방식인것 같군요.
저도 점점 경력이 쌓여가면서 개발 프로세스에 관심이 가져 가더군요. 요즘 테스팅에 대해서 좀더 넓게 공부를 할려고 합니다. 전에는 위에서 하라는대로만 해서 많은 생각이 없었던거 같네요. 나중에 더 좋은 탑픽이 있으면 저도 참여를 해보겠습니다. 그럼 이만
저장 취소
코멘트쓰기
  좋음   놀람   궁금   화남   슬픔   최고   침묵   시무룩   부끄럼   난감
* 코멘트는 500자 이내(띄어쓰기 포함)로 적어주세요.
목록 보기   지금 보고 계시는 글을 회원님의 my Mblog >> 스크랩에 넣어두고 다음에 바로 보실 수 있습니다.  
회사소개  |   개인정보취급방침  |  제휴문의  |   광고문의  |   E-Mail 무단수집거부  |   고객지원  |   이용안내  |   세금계산서
사업자등록번호 안내: 220-81-90008 / 통신판매업신고번호 제 2017-서울구로-0055호 / 대표: 홍영준, 서민호
08390, 서울시 구로구 디지털로32길 30, 1211호 / TEL. 02_6719_6200 / FAX. 02-6499-1910
Copyright ⓒ (주) 데브피아. All rights reserved.