좀 오래된 책이긴 하지만, 여전히 매우 유용한 스티브 맥코넬의 RAPID Development이란
책에 나오는 RAD 적용 사례입니다.
열심히 하는 코딩만으로는 부족함을 느낄 때 반드시 읽어봐야 하는 내용이죠.

예전에 한번 봤던 책인데 이번에 다시보게되는 기회가 있어서
적용사례 한페이지를 타이핑했습니다. 도움이 되시기 바랍니다.




제품2.0을 만드는 프로젝트의 기술수석 사라의 이야기

첫 회의에서 그녀는 팀원을 소개한 후 바로 본론으로 들어갔다.
"회사 프로젝트 전체의 사후 분석을 검토했습니다. 이제까지 다른 프로젝트에서 저지른 실수 목록이 1킬로미터는 족히 되더군요. 이 목록을 회의실에 붙여놓겠습니다. 우리가 이들 중 어떤 실수라도 저지르는 기미가 보이면 경고해줄것을 부탁합니다. 또한 여러분이 이미 알고 있거나 앞으로 부딪히게 될 가능성이 있는 실수를 추가해 주십시오. 이미 겪은 일을 이유없이 반복할 필요는 없다고 봅니다."

"저는 여러분 각자가 개발 기본에 충실하기 때문에 이 팀 구성원으로 뽑았습니다. 나중에 불필요한 수정따위에 시간을 낭비하지 않을 수 있도록 제대로 요구사항을 분석하고 설계하는 활동이 얼마나 중요한지 여러분은 잘 알 것입니다. 저는 여러분이 그저 열심히 일하기 보다는 현명하게 일했으면 합니다. 무작정 열심히 일하면 그만큼 많은 실수를 저지르게 됩니다. 우리에게는 그럴 시간이 없습니다."

"위험 관리 계획도 세웠습니다. 일정이 너무 꽉 짜여 있기 때문에 미리 막을 수 있는 위험에 발목을 잡힐 수는 없습니다. 이 목록에서 가장 큰 위험은 일정을 맞출 수 없을지도 모른다는 점입니다. 그래서 이번주는 일정을 재평가했으면 합니다. 만약 달성할 수 없다면, 좀더 현실적인 계획을 세우도록 합시다."

팀원 모두가 고개를 끄덕였다. '죽음의 행군'식 프로젝트를 해왔던 사람들은 사라의 이야기에 매우 동감했다.

그 주 후반, 사라는 상사 에디와 회의를 했다. "개발팀과 프로젝트 일정을 진지하게 검토한 결과, 현재 일정으로 현재 요구기능을 완료할 확률이 약 5% 정도라고 결론을 내렸습니다. 아무것도 변하지 않는다는 가정에서입니다. 물론, 항상 뭔가가 변하게 마련이지요."

"그건 안됩니다." 에디가 말했다. "정시 출시 가능성이 적어도 50/50은 되야 합니다. 게다가 출시 후 12개월 동안은 시장의 변화에 대응할 수 있어야 합니다. 어떻게 했으면 좋겠습니까?"

"아직 제품을 완전히 구체화하지 않은 상태라서, 융통성은 약간 있습니다." 사라는 대답했다. "그렇지만 현재 요구기능을 완성하려면, 10개월에서 30개월 정도 걸린다고 봅니다. 너무 범위가 큰 줄은 알지만 우리가 만드는 제품에 대해 더 알기 전에는 이것이 최선의 추측입니다. 제품을 12개월만에 출시해야 하지요? 그 점을 고려한다면 개발자를 더 추가해야 합니다. 그리고 8개월 째에 첫 출시를 한 후 두달마다 출시용 버전을 만드는, 점진적인 출시계획을 세워야 한다고 봅니다."

"괜찮군요" 에디가 말했다. "게다가 이번 프로젝트에서는 기능이 일정보다 더 중요하다고 생각됩니다. 회사와 좀 더 논의한 후에 다시 이야기합시다."

에디는 사라에게 돌아와, 회사가 필요한 기능 완료를 위해 일정을 14개월까지 늘일 용의가 있다고 전했다. 또한 안전을 위해, 점진적인 개발법을 그대로 사용하도록 지시했다. 사라는 안심하며, 그것이 좀더 현실적인 목표라고 생각한다고 대답했다.

첫 몇 주 동안에 팀은 구체적인 사용자 인터페이스 프로토타입을 작성했다. '실수 목록'에서 프로토타입에 들이는 지나친 노력을 경고하였으므로, 프로토타입 치장을 피하기 위해 기간확정 방법을 사용하기로 했다. 팀은 구현할 기능을 결정하기 위해 고객들을 면담하는 데 프로토타입을 이용하고 사용자 피드백에 따라 이를 여러 차례 수정했다.

사라는 계속 위험 목록을 관리했다. 그녀는 프로젝트에서 가장 큰 위험은 '엄청난 수정을 요구하며 일정을 늘이는 낮은 품질', '무리한 일정', '경쟁력을 위해 도중에 추가하는 기능', 이 세 가지로 결정했다. 사라는 점진적인 출시 계획으로 '품질 위험'에 대응한다고 보았다. 팀은 8개월째에 첫 버전을 품질관리부에 넘길 예정이고, 품질관리부는 이에 맞춰 테스트 스크립트를 개발할 것이다.

팀은 기능 우선순위 목록을 만들어 일정 위험을 다루었다. 14개월안에 무조건 많은 기능을 개발하는 방법도 있겠지만, 제품을 두 달마다 출시가능한 상태로 만듦으로써 어느 시점이든 출시할 수 있는 제품을 확보할 것이다. 팀은 또한 몇가지 기능에 대해 구현시간을 줄이는 방식으로 설계를 했다. 시간을 덜 들여 구현할 기능은 별로 매끄럽지는 않겠지만 쓸만한 것이며, 이런 결정으로 일정 위험을 상당히 줄일 수 있었다.

팀은 '경쟁력 향상용 기능 위험'을 두 가지 방법으로 대응했다. 그들은 5개월정도 시간을 들여, 프로토타입한 모든 기능과 3.0에 포함할 기능을 지원할 수 있는 기반구조를 설계하였다. 이 기반구조로 변화를 큰 어려움 없이 수용하기 위함이다. 또한 팀은 12개월 째 시간을 할당하여, 경쟁사의 제품을 분석하고, 프로토타입을 재검토하기로 했다. 그 후 마지막 두달 동안, 경쟁력향상을 위해 필요한 기능을 구현하기로 했다.

6개월 시점에서 설계를 완성함과 동시에, 팀은 8개월째에 품질관리부에 넘길 첫 출시용 버전을 위해 중간목표를 상세하게 명시하는 세밀한 계획을 세웠다. 첫 버전은 별로 많은 기능을 포함하지는 않았다. 그러나 품질이 우수했고, 그 후 개발에 좋은 바탕이 되었다. 8개월째에 다시 10개월 지점을 위해 중간목표를 상세하게 명시하는 세밀한 계획을 세웠다. 12개월 지점을 위해서도 같은 방법을 사용했다.

12개월째 팀은 계획대로 경쟁회사제품을 분석했다. 경쟁사 하나가 10개월 무렵에 좋은 제품을 출시했고, 그 제품에는 우수한 기능이 들어 있었다. 제품2.0이 경쟁력을 가지려면 꼭 추가해야 하는 기능이었다. 팀은 새 기능들을 우선순위 목록에 추가하고 우선순위를 재조정하여 마지막 두달을 위한 상세계획을 세웠다.

그 즈음에 연구원들 중 호세가 좀더 나은 대화창 구성을 생각해내고, 팀회의에서 안건으로 제시했다. 선임 연구원 조지가 대답했다. "아이디어는 좋아. 바꾸는 편이 낫다고 생각하지만, 지금은 안되네. 호세 자네는 하루정도면 고칠수 있겠지만, 문서화 일정에 일주일 혹은 그이상 영향을 미치네. 버전 3.0 목록에 넣으면 어떨까?"

"문서화 일정에 미치는 영향을 미처 생각하지 못했습니다." 조는 말했다. "좋은 지적이군요. '나중에 할일' 목록에 추가하도록 요청하겠습니다.

14개월째 팀은 계획대로 최종 소프트웨어를 출시했다. 제품2.0의 품질은 8개월째부터 테스트를 해왔으므로 우수했다. 문서부는 소프트웨어가 완성되기를 기다리는 대신 상세한 인터페이스 프로토타입을 바탕으로 일할 수 있었기 때문에, 사용자 매뉴얼 역시 최종 소프트웨어와 같은 시기에 끝낼 수 있었다. 개발팀은 우선순위가 낮은 기능까지 구현할 시간은 없었지만 중요한 기능은 모두 구현했다. 제품2.0은 성공적이었다.

'개발도 하냐?' 카테고리의 다른 글

개인 주민등록번호 노출상태 확인  (0) 2010.08.02
QR코드  (0) 2010.07.26
소스코드만으로 부족함이 느껴질때-RAD  (0) 2010.07.14
Social Network, Social Media  (0) 2010.07.14
데이터에서 배우자  (0) 2010.07.14
RAD(Rapid Application Development)  (0) 2010.07.08
블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.

관련도서 : http://www.yes24.com/24/goods/380739

 

 

출처 : http://anyflow.net/397
참고 : http://neokido.tistory.com/576

RAD 도구 : http://en.wikipedia.org/wiki/Rapid_application_development#searchInput


1. 신속 S/W 개발(Rapid S/W development)
- 비즈니스 환경의 빠른 변화, 비즈니스는 새로운 기회와 도전에 신속히 응답해야. Time-to-market
- 이 경우, 신속한 개발과 인도는 종종 S/W 시스템에 관한 가장 중요한 요구사항
- 위와 같은 배경 기반의 비즈니스 영역에서는 주요 기능이 정상적으로 동작하기만 하면 빠른 인도의 장점이 낮은 품질이란 단점을 상쇄
- 요구사항
  1) 환경의 변화로 인해 안정적이고 일관적인 시스템 요구사항에 도달하기가 매우 어려움
  2) 따라서 waterfall 모델은 비현실적, 오직 반복적(iterative) 명세와 인도에 기반을 둔 개발 방법론만이 S/W를 신속하게 인도하는 유일한 방법

2. RAD 프로세스의 특성
- 명세, 설계, 구현 프로세스가 동시에 이루어짐. 상세 명세는 없으며 설계 문서는 최소화됨
- 시스템은 일련은 점증적 단계(증분; increment)를 통해 개발됨. 최종 사용자는 개발에 참여하여 각 점증 단계를 평가하며, 이후 점증 단계를 위한 제안을 함
- 시스템 UI는 일반적으로 반복적 개발 시스템을 이용하여 개발됨


점증적 개발 프로세스

3. 점증적 개발(Incremental development)의 장점
- 고객 서비스의 신속한 인도(accelerated delivery of customer services) : 각 점증 단계(증분; increment)는 고객의 가장 높은 우선순위의 기능을 인도
- 시스템에 대한 사용자의 참여 : 사용자는 개발에 참여하여 시스템이 좀더 그들의 요구에 다가서고, 사용자는 시스템에 대해 더 나은 만족을 얻을 수 있음

4. 점증적 개발의 문제점
- 관리 문제(Management problem) : 문서가 없으므로 상황 파악이 어려움
- 계약 문제(Contractual problem) : 명세가 없으므로 명세 이외의 타 형식의 문서를 사용해야
- 검증 문제(Validation problem) : 명세가 없으면, 어떤 기준으로 시스템을 테스트할 것인가
- 유지보수 문제(Maintenance problem) : 계속적인 변경은 S/W 구조에 문제를 일으키고(corrupt), 이로써 S/W는 새로운 요구에 대한 변경과 진화가 어려워짐

5. 프로토타이핑(Prototyping)
- 일부 대규모 시스템에서는 점증적 반복 개발과 인도는 비현실적. 특히 다수의 팀이 각가 다른 위치에서 일할 경우
- 실험적 시스템을 개발하는 프로토타이핑을 통해 요구사항의 타당성(실제 사용할만한지 여부 판단) 체계화(formulate)를 위한 기반을 세울 수 있음. 시스템 명세가 만들어지면(agreed) 프로토타입은 폐기됨(throw away)

6. 점증적 개발과 프로토타이핑
- 점증적 개발의 목적은 최종 사용자에게 실제 동작하는(working) 시스템을 인도함에 있음. 개발은 가장 잘 이해된 요구사항을 바탕으로 시작됨.
- 프로토타이핑의 목적은 시스템 요구사항의 검증 또는 추출임. 프로토타이핑 프로세스는 잘 이해되지 않은 이해사항에서 시작.

 

점증적 개발과 프로토타이핑의 목적

7. 애자일 기법(Agile Methods)
- 기존의 개발 접근법에 대한 불만,즉 계획 수립, 설계, 문서화에 대한 부하(overhead)에 대한 반기로 시작
- 설계와 문서화보다는 S/W 자체(특히 코드)에 초점을 두도록
- 점증적 접근법에 기반
- 빠르게 변화, 진화해가는 요구사항에 대한 신속한 S/W의 배포
- 주로 소/중규모 비즈니스 시스템이나 PC 제품이 알맞음
- XP는 가장 잘 알려진 애자일 기법 중 하나

8. 애자일의 원칙
- 고객 참여(Customer involvement) : 고객은 요구사항 개발 및 운선순위 결정, 시스템의 반복(iteration)을 평가
- 점증적 인도(Incremental delivery) : 고객이 지정한 요구사항이 포함된 점증 단계를 기반으로 s/w가 개발되고 인도됨
- 사람은 프로세스가 아님(People not process) : 기정의된 프로세스를 강요하지 않음. 개발자 및 개발팀 만의 방식, 그들의 기술을 인정
- 변화를 포용(Embrace change) : 요구사항의 변화를 받아들이고 ,변화 수용 가능한 시스템을 설계
- 단순성 유지(Maintain simplicity) : S/W 및 개발 프로세스 모두에서 단순성에 초점을. 수시로 시스템에 남겨진 복잡성을 제거하도록

9. 애자일의 문제점
- 고객은 전적으로, 계속하여 프로세스에 참여하기 어려움
- 개발팀 구성원이 집중적인 참여를 요구하는 애자일의 특성에 맞지 않을 수도
- 다수의 이해관계자(stackholder)가 있을 경우 우선순위 변경이 어려워짐
- 단순성 유지는 추가적 작업을 요구
- 내재화된 점증적 명세화 작업으로 인해, 명사가 포함된 계약서 작성이 난해. 따라서 타 외부 개발 조직과의 co-work이 어려워질 수도

10. Extreme Programming(XP)
- 가장 잘 알려지고, 가장 많이 사용되는 애자일 기법
- 반복적 개발과 같은 좋은 실무 관행과 고객 참여을 극한(extreme)까지 밀고 나감
  1) 새로운 버전이 하루에도 몇 번씩 빌드될 수 있음
  2) 매 2주마다 각 점증적 단계가 고객에게 인도
  3) 매 빌드마다 모든 테스트가 수행되고 테스트에 성공했을 때만 해당 빌드를 인정

 

XP 릴리즈(release) 사이클

11. Extreme programming Practices
- 점증적 계획(Incremental planning) : 시토리 카드를 이용, 작업으로 분할. 이들 작업은 스케줄링과 비용 산정의 근간. 시간을 고려하여 우선순위 결정
- 소규모 릴리즈(Small releases) : 비즈니스 가치를 제공하는 최소한의 유용한 기능을 먼저 개발. 릴리즈를 자주, 점증적으로 수행
- 단순한 설계(Simple design) : 현재의 요구사항을 충족하는 충분한 설계를
- 테스트 주도 개발(Test driven development): 구현 이전에 자동화된 단위 테스트 프레임워크를 통해 테스트 킷을 먼저 작성
- 리팩토링(Refactoring) : 계속적으로, 최대한 많이 코드를 리팩토링. 단순성, 유지보수성 증가
- 짝 프로그래밍(Pair programming) : 짝으로 팀을 이뤄 함께 개발. 서로가 상대의 작업을 검사(checking)하도록. 비공식적 검토(Informal review)가 자연스럽게 이루어짐
- 집단적 소유(Collective ownership) : 짝이 시스템의 모든 영역을 맡음으로 고립된 비 개발 영역이 없도록. 누구든지 변경 코드 변경 가능
- 계속적 통합(Continuous integration) : 작업이 완료되자마자 전체 시스템에 통합되도록. 이후 모든 단위 테스트를 통과해야
- 유지 가능한 속도(Sustainable pace) : 초과 근무는 낮은 품질, 보통의 생산성 만을 양성할 뿐
- 현장의 고객(On-site customer) : 고객은 개발팀의 일원. 전적으로 개발에 시간을 할당하여 시스템 요구사항을 전달할 책임이 고객에게 존재

12. Rapid application development(RAD)
- 데이터에 집중된 비즈니스 응용(application), 즉 DB로부터의 정보를 표현하는 응용에 주로 사용
- RAD 환경 도구 : DB 프로그래밍 언어, Interface 생성기, 오피스 응용 프로그램과의 연결, 리포트 생성기, 대화식 개발에 알맞는 Visual programming 도구

13. Visual development
- 단위가 작은 재사용 가능 S/W 컴포넌트의 통합에 의존하는 RAD 기법
- Visual Basic같은 스크립트 언어를 사용
- 대규모 컴포넌트가 기정의, 기구현되어 있음
- 특정 응용 요구사항에 맞도록 재구성될(tailored) 수도
- COTS(Commercial Off-the-Shelf; 상용 기성품) 기반 개발이라 부르기도. 기성품을 재구성(configure)하고 연결
- 복합 문서(Compound documents)
  1) 사용자 조작(computation)이 가능한 능동 요소(active element)가 내장된 문서. 복합 문서 자체는 각기 다른 응용을 통합하는 역할
  2) 각각의 능동 요소는 특정 응용과 연결되어 해당 요소 선택시 활성화됨
- 문제점
  1) 팀 기반 개발에 알맞지 않음
  2) 명시적 시스템 아키텍처가 없음
  3) 프로그램 부위간 복잡한 의존성이 유지보수 문제를 일으킬 수도

14. S/W 프로토타이핑(Prototyping)
- 개념을 보여주고(demonstrate), 설계 선택사항(option)을 시험해보기 위한 개발할 시스템의 초기 버전
- 용도는,
  1) 요구공학 프로세스 : 요구사항 추출 및 검증을 위해
  2) 설계 프로세스 : 선택사항 시험 및 UI 설계 개발을 위해
  3) 테스트 프로세스 : back-to-back 테스트 수행을 위해
- 장점
  1) 시스템 사용성 향상
  2) 사용자의 실제 필요에 더욱 근접
  3) 설계 품질 향상
  4) 유지보수성 향상
  5) 개발 노력(effort)의 절감
  6) back-to-back 테스트가 가능해짐

 

back-to-back 테스트(동일 결과면 OK, 다르면 결함 존재)

프로토타이핑 프로세스

15. 폐기용 프로토타입(Throw-away prototypes)
- 프로토타입은 개발 후 폐기되어야 : 제조 시스템(production system)을 위한 적절한 기반이 되지 못하기 때문에
  1) (보안성, 신뢰성 등의) 비기능적 요구사항을 만족시키기 위해 프로토타입을 손질할(tune) 수 없음
  2) 일반적으로 프로토타입에 대한 문서는 없음
  3) 프로토타입의 구조는 보통 많은 변경으로 인해 낙후됨(degraded)
  4) 프로토타입은 조직의 품질 기준(표준)에 미치지 못하는 경우가 다반사

'개발도 하냐?' 카테고리의 다른 글

Social Network, Social Media  (0) 2010.07.14
데이터에서 배우자  (0) 2010.07.14
RAD(Rapid Application Development)  (0) 2010.07.08
디자이너에게 배우다.  (1) 2010.07.07
PHP 코딩 규약 - PEAR  (0) 2010.06.25
mod_security AND fckeditor  (0) 2010.06.21
블로그 이미지

오픈비 chaeya

시간이 지날수록 늘어가는 좋아하는 것들에 대한 삽질 기록. 그리고 작은 목소리.