J2EE 기반 프로젝트에 Rational 툴 적용하기, Part 1: 도입 (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.  제안 및 의견 피드백

난이도 : 초급

Steven Franklin, Software Design and Process Specialist, Software Design and Process Specialist

2006 년 5 월 02 일

Rational Unified Process와 기타 Rational 툴을 빡빡한 스케줄과 예산으로 진행되는 개발 프로젝트에 사용하는 방법을 연구합니다. Part 1에서는 고급 플래닝 방법과 요구 사항을 이끌어 내는 방법을 설명합니다.

Rational의 개발 툴 슈트는 라운드트립 엔지니어링(RTE), 분산 및 협업 개발, 매우 반복적인 개발 사이클 등을 지원한다. Rational 툴의 작동을 설명하고 이것을 분산된 J2EE(Java 2 Platform, Enterprise Edition) 프로젝트에서 사용하는 방법을 설명하겠다. 가상의 프로젝트를 설정해 놓고 고급 플래닝과 요구 사항 이끌어 내는 것부터 Rational Unified Process (RUP) 단계 까지 살펴보도록 하겠다. 물론 이 글을 읽는 독자 여러분들은 RUP에 대한 지식이 어느 정도는 있어야 한다. 참고자료 섹션을 참조하라.

RUP의 모든 단계들을 반복하지는 않고, 각 단계들 마다 사용되는 주요 기능들만 설명하도록 하겠다. 샘플 프로젝트를 사용하여 다음과 같은 내용들을 다룰 것이다.

• 어려운 원격 개발, 빡빡한 스케줄, 제한된 예산에 맞추도록 적용된 많은 RUP 개념과 Rational 툴
• Rational 기술을 사용한 엔드투엔드 트레이싱 및 요구 사항 관리
• 자동화된 테스팅, RTE, 지리적으로 분산된 코드 리뷰, 품질 보장(QA) 등을 갖춘 J2EE 프로젝트에서의 툴 통합
• J2EE, DB2나 Oracle 같은 관계형 데이터베이스, Java IDE를 최종 솔루션에 적용할 수 있도록 하는 J2EE 툴과 Rational 기술의 통합

본 시리즈는 다음과 같이 구성된다. 각 파트별로 링크가 되어 있다.

• Part 1: 프로젝트 소개, 고급 플래닝
• Part 2: 상세 플래닝, 리스크 관리, 요구 사항 관리
• Part 3: Rational Rose 모델 생성과 액세스 제어, 요구 사항 분석
• Part 4: 유스 케이스 조정, 리포트 생성, 툴과 기술 선택
• Part 5: 아키텍처와 디자인
• Part 6: 디자인 상세, 초기 개발, 라운드트립 엔지니어링, 초기 단위 테스트
• Part 7: 개발, 초기 구현, 데모
• Part 8: 단위 테스팅 전략, 기능 테스트, GUI 테스트 스크립트
• Part 9: 시스템 구현과 테스팅, 오류 트래킹, 제품 승인
• Part 10: 프로젝트 결과, 결론, 앞으로의 작업

샘플 프로젝트 소개

가상의 Lookoff Technologies Incorporated라는 소프트웨어 회사는 통합, 지원, 개발 등 IT 시스템을 전문으로 다루고 있다. 토론토에 본사가 있으며, 캐나다 전역에 많은 사무소들을 두고 있다. 이 회사 구조는 전문 기술(백엔드 개발과 프로젝트 관리)을 중앙에, 분석과 개발 팀들은 전국적으로 많은 고객과 밀접한 곳에 배치했다.

New Brunswick의 St. John 근처에 위치한 Audiophile Speaker Design, Inc. (ASDI)는 벽감 스피커 조립과 디자인 회사로 시작하여, 개인용 커스텀 스피커 솔루션을 개발하고 있다. 인기가 많아지면서 더 많은 주류 스피커 라인을 개발했고, 캐나다와 미국 북동부에 걸쳐 프랜차이즈 오디오와 전자 대리점에 제품을 공급하고 있다.

ASDI의 기술 인프라는 규모면에서는 성장하지 않았다. 주문 관리, 재고 플래닝, 필요한 부품 트래킹, 선적 관리에 어려움을 겪고 있었다. 더욱이 ASDI의 고객들은 가용성과 전달 과정을 볼 수 없다는 것에 불만을 품고 있었다.

종이나 스프레드 시트에서 반자동화된 자산 관리 시스템으로 옮길 경우의 위험성을 인식한 ASDI는 IT 관련 요구 사항들을 Lookoff에 위임하기로 결정했다. Lookoff를 선택한 가장 큰 이유는 명성과 사무실에서 가장 가까웠기 때문이다.

이 샘플 프로젝트는 허구이기는 하지만 분명한 것은, 나 자신의 개인적인 경험, 다른 프로젝트의 관찰, 관련 서적 탐독(참고자료)을 기반으로 구성했다는 점이다.

위로

고급 요구사항

비 IT 기업들과 마찬가지로, ASDI는 자신들의 문제를 인식하고는 있지만, 요구 사항에 대한 명확한 사명서가 없었다. 원래의 작업 사명서(SOW)는 두 페이지 분량에, 계약상의 요구 사항부터 기능 및 프로그래밍 요구 사항 까지 혼합되어 있었다. 우리(Lookoff)는 먼저 고객과 마주 앉아서 각 관점의 중요성을 논하기 시작했다. 여기서 가장 중요한 것은 계약상의 문제와 프로그래밍 문제이다.

계약상의 문제

고객(ASDI)은 우리(Lookoff)와 110만 캐나다 달러의 고정 가격(FFP) 계약을 맺고 싶어했다. 여기에 10 개월의 계약 기간 내에 소프트웨어 공급을 받기 원했다. 요구 사항에 대한 명확한 비전 없이 여기에 동의하기는 어려웠다. 엄청난 위험성이 예상되고, 고객에게도 불공정한데 그들의 기술적 요구 사항들은 맞추기란 더 힘든 일이었다. 우리는 순차적("폭포형") 개발 보다 반복적이고 증감적인 소프트웨어 개발의 강점을 논의하기 위해 미팅에 참석했다.

우리가 고객에게 강조했던 RUP의 핵심 요소들은 다음과 같다.

• 반복적인 엔지니어링. FFP SOW에 제시된 것에 맞추기 보다는 올바른 솔루션에 대한 리스크와 커버리지를 줄인다.
• 기존 툴, 기술, 제품(OTS)들을 최대한 활용하여 비용을 줄이고 품질을 높인다.
• 변경 사항들을 관리 하고 제어한다.
• 고객들이 신제품을 볼 수 있도록 한다.
• 고급 제품을 만든다.

고객은 여전히 소프트웨어의 전달 날짜를 신경 쓰고 있었다. 우리는 몇 차례의 논의를 통해 프로젝트의 시작과 끝 까지 프로그래스에 대애 중요한 통찰력을 가져야 한다는 것을 설명했다. 그들은 또한 예산 한도 내에서 진행해 줄 것과 신뢰성 있는 퍼포먼스를 요구했다. 결국 프로젝트 플랜은 두 단계 구조로 까지 진화했다.

• Phase 1 -- 시스템에 대한 "뚜렷한 개념" 확립. 일정한 상한선 하에 노력의 정도(LOE)를 기반으로 한 지급 조건.
• Phase 2 -- 제품화 된 시스템 생성. 이것에 대한 비용은 FFP로 하기로 했다.

Phase 1에 대해서 고객은 최대 250K$CDN라는 상한선을 제시했고, 이 금액은 프로토타이핑 시스템의 첫 번째 구현 데모에는 충분한 예산이었다. 우리는 그림 1과 같은 Gantt 차트를 만들었고 4달 주기로 데모를 배치하고 이를 고객과 함께 리뷰하기로 했다. (후에 자세히 설명하도록 하겠다.)

그림 1의 다이어그램은 Microsoft Visio로 만들었지만 Microsoft Project나 비슷한 소프트웨어 툴을 사용해도 쉽게 만들 수 있었다. 이 차트를 만든 목적은 스케줄과 마일스톤에 동의하고, 트래킹, 평가, 실행할 수 있는 작업 분해 구조(WBS) 아이템의 계층을 설정하는 것이다.

프로그래밍 문제

ASDI는 ISO에 속해 있고 막대한 문서화, 순차적 마일스톤, 확장적인 QA 개입의 광신도이다. 이 회사는 그렇게 기술력이 있는 회사는 아니고 프로세스에 대한 자체적인 개념을 갖고 있었다. 이들과 함께 일하는데 있어서 가장 큰 도전 중 하나는 팀을 방해하지는 않고 이들을 만족시킬 수 있는 프로세스와 인도물을 찾는 것이었다. 이들은 문서를 매우 중요시 했다. 더욱이 마일스톤은 순차적이어야 했다. 즉, 다음 태스크가 시작하기 전에 각 태스크는 완전히 완료되어야 한다는 생각을 갖고 있다. 이러한 생각 때문에 RUP를 최상의 방법으로 적용하는데 더욱 도전이 되었다.

비록 ASDI는 우리가 반복적이고 점증적인(RUP 기반) 방식을 사용하는데 동의는 했지만 관심은 별로 없었다. 그들은 다음과 같은 것을 원했다.

• 고정된 마일스톤
• 시스템 요구사항 리뷰 (SRR), 사전 디자인 리뷰 (PDR), 중요한 디자인 리뷰 (CDR)
• 이머징 소프트웨어에 대한 두 가지 데모
• 팩토리 수락 테스트 (FAT)와 고객 수락 테스트 (CAT)

이러한 마일스톤을 우리의 프로세스에 쉽게 맞출 수 있었다. (그림 1)

• 공식적인 요구사항 문서, 디자인 스팩, 수락 테스트 문서. ASDI는 RUP 기반 방식의 객체 지향 표기법에 익숙치 않았지만 RUP 생성물들로 만족시킬 수 있을 정도로 인도물 디스크립션을 고급으로 유지하는 데에 동의했다. 우리는 Rational 툴을 사용하여 프로세스에 악영향을 끼치지 않고 필요한 문서를 생성하고 고객과 통신할 수 있었다. 특히 Rational SoDA는 우리의 모델에서 문서를 쉽게 생성할 수 있다.

ASDI는 IT 매니저를 고용하여 우리 팀과 대응하도록 하고 완료된 프로젝트의 유지 및 관리를 맡길 예정이었다. 우리에게도 그런 일을 맡을 사람이 필요했다. 안타깝게도 IT 관리자는 (신입사원이기 때문에) 우리 팀이 하는 일에 대해서 잘 몰랐다.

위로

요약

고객과 첫 번째 미팅에서 놀라운 성과를 거두었다. 인도물과 스케줄에 대한 그들의 기대는 다소 유연하고 그렇게 큰 영향을 미치지 않고 RUP 기반의 접근 방식으로 운영할 수 있도록 하였다. 우리는 프로젝트에 대한 대강의 스케줄 구조에 동의했고 고객과 좋은 관계를 확립했다. 그들과의 논의를 통해 몇 가지 위험요소 들을 규명할 수 있었다.

Looking Ahead

가장 우선시 해야 할 것은 고객과 함께 프로젝트 비전을 수립하는 일이다. 우리는 요구 사항에 대해 간략히 이해는 했지만 특정 작업들의 범위를 정할 필요가 있었다.

또한 우리는 스케줄을 조정하고 가능한 한 빨리 실험 단계에 진입했어야 했다. Phase 1 동안 우리는 비용 효율적이고 만족스러운 솔루션을 만들면서 요구 사항들을 만족시키는 방법을 규명해야 했다. 고객은 최종 시스템의 관리와 시스템 인프라의 소프트웨어/하드웨어 비용이 Phase 2로 가는 중요한 결정 요인이라고 했다.

요약하자면 첫 번째 몇 주 동안에는 다음과 같은 작업들이 수행되어야 한다.

• 프로젝트의 SOW를 확장하고 프로젝트 요구 사항들을 Rational RequisitePro에 적용하기
• Phase 1에 맞게 스케줄 조정하기
• 성공적인 디자인 리뷰 후에 Phase 2로의 이동할 때 우리가 제안했던 방법을 보여주기 위한 프로젝트 플랜 만들기
• 규명된 리스크를 완화하기 위한 구체적인 실행 계획 세우기

주요 리스크

프로젝트 초반 몇 주 동안에는 고객과의 효과적인 관계를 확립하고 프로젝트에 올바른 방향을 제시하는 것이 중요하다. 필요한 기술을 찾고 이것을 팀에 통합할 시간이 많이 없었다. 고객은 우리가 매우 바르게 진행하기를 원했기 때문이다.

우리는 액션 아이템, 이슈, 리스크들을 중앙에 위치한 데이터베이스에 올릴 수 있는 이슈 데이터베이스를 설정해야 할 필요를 느꼈다. 이 정보를 웹에 배치함으로서 우리는 중앙 사무소와 원격 개발 팀이 이를 감시할 수 있도록 하였다. 심지어 재택 근무자들도 필요하다면 리스크를 트래킹 하고 업데이트 할 수 있다.

기사의 원문보기

• Applying Rational tools to a simple J2EE-based project Part 1: project introduction; high-level planning

위로

참고자료

• The Rational Unified Process: An Introduction, Second Edition (Philippe Kruchten, Addison-Wesley, 2000)
• Rapid Development: Taming Wild Software Schedules (Steve McConnell, Microsoft Press, 1996)
• The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering (Frederick P. Brooks, Jr.,Addison-Wesley, 1995)
• Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects (Edward Yourdon, Prentice Hall PTR, 1999)

위로

위로

필자소개

		Steven Franklin, Software Design and Process Specialist, Software Design and Process Specialist

위로

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로