© Copyright International Business Machines Corporation 2003. All rights reserved.

머리말

대부분의 소프트웨어 프로젝트는 실패한다. Standish 그룹의 보고에 따르면 80% 이상의 프로젝트가 실패하고 있고, 원인은 예산초과, 지연, 기능 소실 등 때문이다. 더욱이 소프트웨어 프로젝트의 30%는 너무나도 어설프게 진행되다가 완료되기도 전에 취소된다. 자바, J2EE, XML, 웹 서비스 같은 현대적인 기술을 사용하는 소프트웨어 프로젝트 역시 예외는 아니다.

이 글에서 소프트웨어 개발 프로젝트의 Best Practice를 정리했다. Scott Ambler, Martin Fowler, Steve McConnell, Karl Wiegers 같은 이 분야의 선각자들이 인터넷 상에 올린 많은 글들을 참조했다. 이 글의 마지막 섹션인 관련 정보섹션도 참조하기 바란다. 소프트웨어 개발 프로젝트 가이드에는 프로젝트 성공률을 높이기 위한 10가지 주요 요소들이 망라되어 있다.

위로

Best Practices

1. 개발 과정 - 프로젝트에 맞는 개발 과정을 선택하는 것이 중요하다. 여타의 모든 작업들이 이 과정에서 파생되기 때문이다. 대부분의 현대적인 소프트웨어 개발 프로젝트에서 몇 가지 유형의 나선형의 방법론이 사용된다. Rational Unified Process(RUP), IBM® Global Services Method, eXtreme Programming(XP) 등 선택권은 많이 있다. 프로세스가 있는 것이 없는 것 보다 낫고, 많은 경우 무슨 프로세스가 사용되느냐 보다는 이것이 얼마나 잘 실행되느냐가 더 중요하다. 위에 열거한 일반적으로 사용되는 방법론에는 객체들에 대한 프로세스와 템플릿을 실행하는 방법에 대한 가이드가 포함되어 있다. RUP의 경우 RUP[1][2][3][4]의 Best Practice를 설명해 놓은 책 시리즈도 있다. 여러분이 RUP를 선택하지 않았더라도 최상의 Best Practice 소스가 될 것이다. RUP에 플러그인을 추가할 수도 있다. WebSphere® J2EE 기반의 프로젝트의 경우, WebSphere 플러그인을 다운로드 하라.

2. 요구사항 - 요구 사항들을 모으고 이에 동의하는 것은 성공적인 프로젝트의 기본이다. 모든 요구 사항들이 아키텍처, 디자인, 코딩이 수행되기 전에 결정되어야 한다는 의미는 아니다. 하지만 개발팀 스스로 무엇을 구현되어야 하는지를 이해하는 것은 중요하다. 품질 요구 사항들은 두 가지 종류로 나뉜다. 기능적 요구사항과 비 기능적 요구 사항이다. 기능적 요구 사항을 문서화 하는 좋은 방법은 사용 케이스를 사용하는 것이다. 사용 케이스는 비 객체 지향(OO) 프로젝트에 사용된다. 사용 케이스를 주제로 한 Armour와 Miller[5]가 쓴 글을 참조하기 바란다. 비 기능적 요구 사항들은 애플리케이션의 퍼포먼스와 시스템 특성 분야의 것들이다. 이들은 애플리케이션 아키텍처, 디자인, 퍼포먼스에 중요한 영향을 미치기 때문에 중요하다. Construx 웹 사이트에서 비 기능적 요구 사항 체크리스트를 참조하라.

3. 아키텍처 - 애플리케이션에 맞는 아키텍처를 선택하는 것이 중요하다. IBM이 여러 차례에 걸쳐 문제에 봉착한 프로젝트들을 리뷰해 보면, 그 개발팀이 잘 알려진 산업 아키텍처 Best Practice를 적용하지 않는다는 것을 발견하게 된다. 이러한 유형의 문제를 피하는 가장 좋은 방법은 IBM과 연락하는 것이다. IBM의 컨설턴트가 여러분 팀을 도울 것이고 프로젝트가 방향성을 갖고 시작될 것이다. 실제로 시도된 방법들은 전통적인 Gang of Four[6] 패턴, 자바 패턴[7]부터 EJB 디자인 패턴[8]까지 다양하다. Sun의 경우는 Core J2EE Patterns 카탈로그[9]가 있다. IBM 역시 best practices 와 참조 아키텍처[10]를 발표했다. 머리말에서 설명했던 것 처럼 많은 프로젝트들이 실패한다. 이러한 실패에 대한 연구를 통해 반패턴(antipatterns)이라는 개념이 탄생했다. 이들은 무엇이 왜 작동하지 않는지에 대한 실질적인 지식을 제공하기 때문에 가치가 있다.

4. 디자인 - 좋은 아키텍처가 있음에도 나쁜 디자인이 될 가능성이 있다. 많은 애플리케이션들은 과도하게 설계되거나 디자인 과정을 과소평가 한다. 두 가지 기본적인 원리 "단순함을 유지할 것"과 정보 숨기기가 있다. 많은 프로젝트에서 UML을 사용한 객체 지향 분석과 디자인을 수행하는 것이 중요하다. UML에 관련된 많은 책들이 있지만 UML User Guide [11]와 Applying UML and Patterns [12]를 추천한다. OO가 약속하는 것 중 하나가 재사용이지만, 재사용 가능한 자산을 만들어 내는 데는 추가 노력이 필요하기 때문에 실현 가능성은 적다. 코드 재사용도 재사용의 한 형태이며 더 나은 생산성을 보이는 또 다른 재사용 유형도 있다.

5. WebSphere 애플리케이션 디자인 - IBM은 WebSphere 제품군에 대한 Best Practice와 디자인 패턴 정보를 갖추고 있다. 프로젝트는 각기 다르며, IBM 컨설턴트는 그 동안 많은 경험들을 쌓아왔다. 짧은 시간 동안 컨설턴트만 사용하더라도 엄청난 투자회수(ROI)를 보장 받는다. IBM 전문가들은 고성능 웹 사이트와 자율 컴퓨팅 가이드라인 등을 통해 값진 정보를 제공하고 있다.

6. 코드 작성 - 코드 작성은 전체 프로젝트 과정의 일부이지만 가장 눈에 띠는 작업이다. 소위 말하는 "코드와 픽스" 같은 개발 프로세스가 없는 프로젝트에서도 코딩 작업이 있기는 하지만 프로그래밍이라는 큰 테두리 안에 속해있다. 최고의 코딩 방법은 "daily build and smoke test" 일 것이다. Martin Fowler는 한 단계 더 나아가서 단위 테스트와 자가 테스팅 코드의 개념을 통합하는 지속적인 통합을 제안한다. 지속적인 통합과 단위 테스트가 XP를 통해 대중성을 확보했더라도 모든 프로젝트 유형에 이 방법을 사용할 수 있다. Ant와 JUnit같은 표준 프레임웍을 사용할 것을 권한다.

7. 피어 리뷰 - 다른 사람들의 작업을 리뷰하는 것도 중요하다. 이러한 방식을 통해 초기에 문제를 줄일 수 있으며 리뷰는 테스팅 만큼 또는 그 이상으로 효과적이다. 개발 과정에서 나온 모든 객체들이 리뷰 대상이다. 계획, 요구 사항, 아키텍처, 디자인, 코드, 테스트 케이스 등이 모두 리뷰 대상인 것이다. Karl Wiegers의 Seven Deadly Sins of Software Reviews에서는 피어 리뷰를 수행하는 정확한 방법을 설명하고 있다. 피어 리뷰는 빠른 속도로 양질의 소프트웨어를 만들어내는데 효과적인 방법이다.

8. 테스팅 - 테스팅은 스케줄이 빡빡하다고 해서 뒤로 물러나거나 축소될 성질의 것이 아니다. 이것은 소프트웨어 개발 계획의 중요한 일부이다. 또한 테스팅이 제대로 수행되는 것도 중요하다. 테스트 케이스는 코딩이 시작하기 전에 계획되고, 애플리케이션이 설계 및 코딩 되는 동안 개발되어야 한다. 그 동안 많은 테스팅 패턴들이 개발되었다.

9. 퍼포먼스 테스팅 - 일반적으로 테스팅은 애플리케이션 결점을 포착하는 마지막 방법이다. 주로 코딩 결점을 포착하는데 집중되어 있다. 아키텍처와 디자인 오류는 간과되기도 한다. 아키텍처 오류를 포착하는 한 가지 방법은 애플리케이션이 전개되기 전에 애플리케이션에 대해 부하 테스팅을 시뮬레이션 하여 실제로 문제를 일으키기 전에 해결해야 한다.

10. 설정과 관리 - 설정 관리는 시스템이나 프로젝트를 구성하는 모든 객체들의 상태를 알고 그러한 상태들을 관리하며 시스템을 다각적으로 관리하는 것이다. 단순한 소스 제어 시스템(Rational Clearcase) 보다 설정 관리에는 더 많은 것이 있다. 또한 설정 관리를 위한 best practices와 패턴들도 있다. [13]

11. 품질 관리와 결점 관리 - 프로젝트의 품질과 릴리스 기준을 확립하여 팀이 양질의 소프트웨어를 만들 수 있도록 하는 것이 중요하다. 프로젝트가 코딩 및 테스팅 되면서 오류 발생과 픽스 비율은 코드의 성숙도를 측정하는데 도움이 된다. 오류 트래킹 시스템이 소스 제어 관리 시스템과 연결되어 사용되는 것이 중요하다. 예를 들어, Rational ClearCase를 사용하는 프로젝트는 Rational ClearQuest도 사용한다. 오류 트래킹을 사용함으로서 프로젝트의 릴리스 시점을 가늠 할 수 있다.

12. 전개 - 전개는 애플리케이션을 사용자에게 배포하는 마지막 단계이다. 여러분의 프로젝트가 이 지점에 도달했다면 축하한다. 하지만 잘못된 것도 있을 수 있다. 전개 계획을 세우고 Construx 웹 사이트에서 전개 체크리스트를 사용해 보라.

13. 시스템 운영과 지원 - 운영 부서 없이 새로운 애플리케이션을 전개 및 지원할 수 없다. 지원 영역은 사용자 문제에 대응하고 해결하는 중요한 분야이다. 문제의 원활한 관리를 위해 지원 문제 데이터베이스가 애플리케이션 오류 트래킹 시스템과 연결된다.

14. 데이터 마이그레이션 - 대부분의 애플리케이션들은 새로운 것이 아니다. 기존 애플리케이션을 강화하거나 재작성한 것이다. 기존 데이터 소스로 부터의 데이터 마이그레이션은 그 자체로 중요한 프로젝트가 된다. 이는 어린 프로그래머에게 맞는 프로젝트는 아니다. 이것은 새로운 애플리케이션 만큼 중요하다. 일반적으로 새로운 애플리케이션은 더 나은 비즈니스 규칙을 갖고 있고 더 고급의 데이터를 갖출 것으로 기대를 받고 있다. 데이터의 품질을 향상시키는 문제는 이 글의 범위를 벗어난다.

15. 프로젝트 관리 - 프로젝트 관리는 성공적인 프로젝트의 열쇠이다. 이 글에서 설명한 여타 다른 Best Practice 영역 중 많은 것들이 프로젝트 관리와 연결되어 있고 좋은 프로젝트 매니저라면 이러한 Best Practice의 존재를 이미 알고 있다. 프로젝트 관리 바이블이라고 할 수 있는 Steve McConnell의 Rapid Development[14]를 추천한다. 프로젝트 관리를 위한 기타 체크리스트와 팁을 보면 얼마나 많은 프로젝트 매니저들이 이들을 잘 모르고 있으며 이전의 프로젝트에서 배운 교훈들을 적용하지 못하는 지가 증명이 된다. 계획이 실패하면 모든 것이 실패한다. 어려운 프로젝트를 관리하는 한 가지 방법은 timeboxing이다.

16. 성공도 측정 - Carnegie Mellon University의 Software Engineering Institute가 개발한 Capability Maturity Model(CMM)이라는 산업 표준에 준하여 개발과정을 평가할 수 있다. 대부분의 프로젝트는 레벨 1(초기)에서 시작한다. 위에 기술한 Best Practice와 가이드( Guide to Running Software Development Projects) 대로 구현했다면 고급 성숙도 레벨을 획득하고 성공적인 프로젝트로 평가 받을 것이다.

위로

결론

지금까지 소프트웨어 개발 프로젝트의 성공을 도울 Best Practice 리스트를 설명했다. 이러한 Best Practice를 따르다 보면 프로젝트를 성공적으로 끝낼 수 있는 기회에 더 다가갈 수 있다고 본다.

위로

관련 정보

1. Ambler, Scott and Constantine, Larry, The Unified Process Inception Phase, ISBN 1929629109
2. Ambler, Scott, The Unified Process Elaboration Phase, ISBN 1929629052
3. Ambler, Scott and Constantine, Larry, The Unified Process Construction Phase, ISBN 192962901X
4. Ambler, Scott and Constantine, Larry, The Unified Process Transition and Production Phases, ISBN 157820092X
5. Armour, Frank and Miller, Granville, Advanced Use Case Modeling, ISBN 0201615924
6. Gamma, E., Helm, R., Johnson, R., and Vlissides, J., Design Patterns, ISBN 0201633612
7. Grand, Mark, Patterns in Java, ISBN 0471258393
8. Marinescu, Floydd, EJB Design Patterns, ISBN 0471208310, PDF file
9. Alur, D., Crupi, J., Malks, D., Core J2EE Patterns, ISBN 0130648841, also see http://java.sun.com/blueprints/corej2eepatterns
10. IBM Redbooks. Search for "patterns AND e-business".
11. Booch, G., Rumbaugh, J., and Jacobson, I., The Unified Modeling Language User Guide, ISBN 0201571684
12. Larman, Craig, Applying UML and Patterns, ISBN 0130925691
13. Berczuk, Stephen, and Appleton, Brad, Software Configuration Management Patterns, ISBN 0201741172
14. McConnell, Steve, Rapid Development, ISBN 1556159005

필자소개

아티클 순위

의견

위로

목차

• 머리말
• Best Practices
• 결론
• 관련 정보
• 필자소개
• 의견