7 Lifecycle Planning

[jongfeel]

제 7장 생명주기 계획

생명주기는 버전 1.0이 누군가의 머리속에서 번뜩인 순간 부터
버전 6.74b가 고객 장비에서 마지막으로 동작하는 순간까지 일어나는 모든 활동을 얘기한다.
생명주기 모델은 위 생명 주기 동안 일어나는 활동을 규정하는 모델이다.

가장 친숙한 생명주기 모델은 유명한 폭포수 모델이다. 그리고 이름만큼 약점도 잘 알려져 있다.
다른 생명주기 모델이 좀더 쾌속 개발에 적합한 형태이다.

적절한 생명주기 모델을 사용하면 프로젝트를 유연하게 진행하고 목표에 한 걸음씩 다가갈 수 있다.

7.1 순수 폭포수 (Pure Waterfall)

폭포수 모델은 문서를 기바능로 한다.
한 단계에서 다음 단계로 넘기는 작업 결과물이 주로 문서이다.

매 단계 끝에 다음 단계로 넘어가도 되는지 검토하는 단계가 있다.
다은 단계로 넘어갈 수 없다면 다음 단계로 넘어갈 준비가 될 때 까지 현재 단계에 머무른다.

순수 폭포수 모델에서 단계들은 연속적이지 않으므로 서로 겹치지 않는다.
또 제품 정의가 안정적이고 익숙한 기술 방법론을 적용하는 경우에 효과가 있다.
비용이 적게 드는 초기에 오류를 발견할 수 있고, 개발자들이 바라는 요구사항 안정성을 얻을 수 있다.
유지보수성 버전이나 기존 제품을 새 플랫폼에 이식하는 경우라면, 폭포수 생명주기 모델은 쾌속 개발을 위해서 적합한 선택이다.
순수 생명주기 모델은 모든 계획을 초반에 세우기 때문에 계획 수립에 드는 부하를 최대한 줄일 수 있다.

반면, 생명주기가 끝나야 실제 결과물을 볼 수 있지만
문서를 볼 줄 안다면 서 자체가 진행상황을 보여주는 증거가 된다.

순수 폭포수 모델의 단점은 설계와 구현을 시작하기 전 단계에서 요구사항을 완벽하게 명시하기가 어렵다는 점이다.

소프트웨어 제품은 복잡하다.
소프트웨어를 명시하는 책임을 맡은 사람들이 전문가가 아닌 경우도 있다.
실제 작동하는 제품을 보고 나서야 자신들이 뭘 하고 싶은지 생각해낸다.
폭포수 모델에서는 무언가 잊어버리는 실수는 치명적이다.
요구사항 하나가 빠졌거나 틀렸다는 사실을 시스템 테스트 단계에서야 발견하게 된다.

또 폭포수 모델의 단점은 유연하지 않다는 것이다.
요구사항을 완벽하게 명시해야 하는데 그 시점이 소프트웨어가 나오기 몇 달 전 또는 몇 년 전일 수 있다.

폭포수 모델에서 실수를 고치기 위해 이전 단계로 되돌아갈 수 없다고 하는데, 정확히 옳은 말은 아니다.
이전 단계로 갈 수는 있지만 얼마나 많이 되돌아가느냐에 따라 비용이 많이 들게 된다.

폭포수 생명주기 모델의 약점은 작성할 문서가 지나치게 많다는 점이다.
마지막 순간까지 진행상황을 보여주지 못하므로 개발이 느리다는 인식을 줄 수 있다.

순수 폭포수 모델은 많은 약점들로 인해 쾌속 개발 프로젝트에는 적합하지 않다.
장점이 약점을 능가한다고 해도 순수 폭포수 모델보다는 변형 폭포수 모델이 더 효과가 있다.

7.2 짜보고 고치기 (Code-and-Fix)

이 모델은 쓸모없지만 흔히 사용하므로 언급한다.
짜보고 고치기 모델은 일정이 촉박해지면 미친 듯이 코딩하기 개발로 변한다.

제품을 출시할 준비가 될 때까지 비공식적인 설계, 구현, 디버깅, 테스트를 조합하여 적당하다 싶은 방법론은 무엇이든 사용한다.

이 모델의 장점은 두 가지이다.

• 부하가 없다. 계획, 문서, 품질보증, 표준 확립 등 여러 활동에 시간을 들이지 않고 구현을 바로해서 뭔가 되고 있다는 걸 바로 보여줄 수 있다.
• 전문가가 아니어도 된다. 프로그래밍을 해본 사람이면 짜보고 고치기는 익숙하며 누구나 사용할 수 있는 모델이다.

한 번 만들고 버릴 목적인 작업이면 이 모델이 유용하다.

그 외 모든 프로젝트에서 이 모델을 쓰면 위험하다.
진행 상황을 평가할 방법이 없으므로, 될 때 까지 구현만 한다.
품질 평가, 위험 인지 방법도 없어서 80% 구현했다고 해도 근본적인 설계 결함을 발견한다면 다시 0%로 시작해야 한다.

이 생명주기 모델은 작은 작업을 하고 버릴 게 아니라면 쾌속 개발 프로젝트에서 전혀 쓸모가 없다.

7.3 나선형 (Spiral)

짜보고 고치기 모델의 반대는 나선형 모델이다.
나선형 모델은 위험위주 생명주기 모델로, 소프트웨어 프로젝트를 소형 프로젝트 여러 개로 쪼갠다.
소형 프로젝트 각각은 주요 위험을 하나 이상씩 맡아 처리한다.
위험은 애매한 요구사항, 이해하기 힘든 아키텍처, 성능 문제, 기반 기술 문제등을 포함한다.
모든 위험을 처리하고 나면 나선형 모델은 폭포수 모델과 같은 방식으로 끝난다.

시나몬 롤 한 겹을 말고 원하는 모양인지 확인하여 다음 겹을 말아가는 과정과 유사하다.

나선형 모델에서는 초기 반복이 비용면에서 싸다.
운영 개념 확립에 드는 비용이 요구사항 수집보다 적다.

나선형 모델은 다른 생명주기 모델과 여러 가지 방법으로 조합할 수 있다.
초기에 위험 감소 반복을 여러번 거쳐서 낮춘 후에 폭포수 모델이나 다른 위험위주가 아닌 생명주기 모델을 사용해 개발을 마무리할 수 있다.
다른 생명주기 모델을 나선형 모델 내부에 반복으로 통합할 수 있다.

나선형 모델의 장점은 비용이 증가함에 따라 위험은 감소한다는 점이다.
시간과 돈을 많이 쓸수록 위험이 줄어드므로 쾌속 개발 프로젝트의 장점과 일치한다.

나선형 모델의 단점은 복잡성이다.
다음 반복 목표를 설정하기 힘들 경우가 있고 다음 겹을 말아야 할지를 나타내는 중간 목표를 확인하기 어려운 경우도 있다.
간단하고 위험이 적은 프로젝트에 나선형 모델의 유연성과 위험 관리가 필요 없을 수도 있다.

7.4 변형 폭포수 (Modified Waterfalls)

어떻게든 소프트웨어 개념은 세워야 하고 요구사항은 수집해야 한다.
꼭 폭포수 모델이 아니라도 무언가는 사용해야 한다.
개발 과정에서 아키텍처, 설계, 구현을 빠트릴 수는 없다.

폭포수 모델의 약점은 해야 하는 활동의 문제가 아니라 이걸 개별적인 단계로 취급하기 때문에 그렇다.
변형 폭포수 모델은 이 단계를 서로 겹치게 만들거나 문서를 더 강조하거나, 복원이 더 쉽도록 변형할 수 있다.

사시미 모델

사시미는 일본 후지 제록스의 하드웨어 개발 모델에서 따온 이름으로
생선을 얇게 썰어 겹치게 늘어 놓는 모양처럼 보인다.
이 겹치는 부분이 각 단계별 중복 부분이다.

프로젝트는 수행하는 동안 제품에 대해 더 많이 깨닫게 되므로 지나치게 순차적인 개발 계획은 효과를 발휘하기가 어렵다.

각 단계를 다른 사람이나 다른 팀이 아닌 같은 사람과 같은 팀이 하게 된다면 문서 작업도 많이 필요하지 않을 수 있다.
변형 폭포수 모델을 적용하면 문서량을 상당히 줄일 수 이싿.

사시미 모델의 문제는 단계가 겹치기 때문에 중간 목표가 아매해지고 프로젝트 감독이 어렵게 된다.
여러 활동을 겹쳐서 진행하므로 의사소통 장애, 잘못된 가정으로 비효율성을 일으키기도 한다.

하위 프로젝트 폭포수 모델

시스템에는 설계 도중에 허를 찌르는 분야가 있고
전에 많이 구현해봐서 별로 놀랄 일이 없는 분야도 있다.

즉 어려운 부분의 설계가 오래 걸리는 중에 그 다음의 쉬운 부분의 설계는 이미 끝나서 구현을 할 수 있는데 이걸 미루는 건 좋지 않다.
전체 시스템을 독립적인 하위 시스템으로 잘 분리할 수 있다면
각 하위시스템을 책임지는 별도 프로젝트를 만들 수 있다.

이 방법의 큰 위험은 하위 시스템 사이의 예측하지 못한 의존성을 발견하는 경우이다.
아키텍처 단계에서 의존성을 없애는 방법이나 상세 설계까지 끝내고 난 후에 하위 프로젝트를 만드는 방법으로 해결한다.

위험 감소 폭포수 모델

폭포수 모델의 약점은 요구사항을 완전히 정의해야 설계를 시작할 수 있다는 점이다.
이럴 때는 나선형 모델을 폭포수 맨 꼭대기에 두고 살짝 변형해서 요구사항 위험을 처리할 수 있다.
요구사항 분석 뿐 아니라 아키텍처 위험이나 다른 위험에도 적용할 수 있다.
시스템 핵심 부분을 개발하는 데 위험이 크다면, 그 핵심 부분에만 위험 감소 주기를 사용할 수 있다.

7.5 발전적인 프로토타이핑 (Evolutionary Prototyping)

프로젝트를 진행하면서 시스템 개념을 확립해가는 생명주기 모델이다.
눈에 띄는 부분부터 개발해 고객에게 보여주고 그 피드백에 따라 프로토타입 개발을 완성하면
나머지 보여주지 않은 부분의 작업을 마무리하고 프로토타입을 최종 제품으로 출시하는 것이다.

요구사항이 빠르게 변하거나, 고객이 요구사항을 확정하지 않았거나, 개발자와 고객이 해당 개발 분야에 익숙하지 않을 때 매우 적합하다.
개발자가 어떤 아키텍처나 알고리즘이 좋은지 확신하지 못할 때 효과가 있다.
진행 상황을 계속 확인할 수 있는 방법이므로 개발 속력을 강조하는 경우에 특히 효과가 있다.

단점은 초기에 완성까지 걸리는 시점을 알 수 없다는 것인데, 반복을 몇 번 거치면서 알아내야 하기 때문이다.
하지만 고객이 지속적으로 진행상황을 확인하므로 다른 개발법에 비해 덜 불안해하는 것으로 단점이 해소된다.
또 하나의 단점으로 짜보고 고치기 개발로 변질된다는 것인데, 발전적인 프로토타이핑에는 요구사항 분석, 설계, 유지보수 단계가 들어가야 한다.

7.6 단계적인 출시(Staged Delivery)

발전적인 프로토타이핑과 다른 점은 만들 제품을 정확하게 알고 시작한다는 점이다.
출시가 가장 마지막 단계에 한 번 일어나는 것이 아니라 프로젝트 진행 중간에 단계적으로 출시한다는 점이 특징이다.

소프트웨어 개념 정의 요구사항 분석, 아키텍처 설계 단계는 폭포수 모델의 과정을 거쳐서 한 번 진행하고
이후 상세 설계, 구현, 디버깅 테스트는 단계별로 여러번 반복하는 방법이다.

장점은
기능을 고객에게 빨리 넘겨줄 수 있다는 점이다.
각 출시 단계를 잘 계획하면 가장 중요한 기능부터 먼저 출시해 고객이 사용하도록 한다.
이는 실제 결과물을 보여주는 효과가 있으므로 일정 압력을 해소하는 데 도움이 된다.

단점은
관리와 기술 단계에서 주의깊게 계획을 세우지 않으면 실패하기 쉽다는 점이다.

7.7 일정맞춤 설계 (Design-to-Schedule)

단계적 출시 모델과 유사하지만 최종 출시 여부는 확실하지 않은 상태로 진행한다는 점이 다르다.
계획은 5단계로 했어도 특정 날짜 기준으로 3단계만 하고 끝낼 수도 있다.

특정 날짜 기준으로 제품 출시를 보장하는 실용적인 전략으로
전시회, 연말 등의 일정에 맞춰야 한다면 그 시점까지의 출시 단계까지는 기능이 동작한다는 보장이 된다.

그래서 이 모델의 핵심 활동은 기능 중에서 우선순위를 정해 초기 단계에 우선순위가 높은 기능을 넣는 방법으로 계획한다.

단점은 모든 단계를 거쳐 출시하지 않는다면 초기 분석 설계하는데 든 시간이 낭비된다는 것이다.

7.8 발전적인 출시 (Evolutionary Devlivery)

발전적인 프로토타이핑과 단계적인 출시 사이에 걸쳐있는 생명주기 모델이다.
어느 쪽 모델을 더 사용하는지는 고객 요구를 어디까지 수용하느냐에 달려있다.
고객의 요구를 받아들인다면 발전적인 프로토타이핑
고객의 요구를 받아들이지 않는다면 단계적인 출시와 비슷해진다.

7.9 도구맞춤 설계 (Design-to-Tools)

매우 급한 경우에만 사용하는 극단적인 방법이다.
비주얼 프로그래밍 환경, 데이터베이스 지원 환경 등 쓰기 쉽고 강력한 도구가 있어서 도구맞춤 설계를 사용하는 것이다.
이는 도구에서 지원하는 기능만 제품에 넣는 방법으로 지원하지 않는 기능은 제품에서 제외한다.
도구의 범위는 코드, 라이브러리, 코드 자동 생성기, 쾌속 개발 언어, 구현 시간 단축 등의 소프트웨어 도구들을 말한다.

Figure 7-12. Design-to-tools product concept. Design-to-tools can provide exceptional development speed, but it typically provides less control over your product's functionality than other lifecycle models would provide.

제품에 넣고 싶은 기능 모두를 구현할 수 없는 건 사실이지만,
도구를 잘 선정하면 원하는 기능을 많이 구현할 수 있다.
일정 제약까지 있다면 실질적으로 더 많은 기능을 구현할 수도 있다.
하지만 이런 기능은 도구를 써서 구현하기 쉬운 기능일 뿐 실제 우선순위가 높은 기능은 아니다.

나선형 모델, 일회성 프로토타입 작성을 할 때 도구맞춤 설계 방법을 사용할 수 있다.
도구로 기능을 쉽게 구현한 것만 프로토타입을 작성하고 이후는 다른 모델을 사용해 실제 소프트웨어를 개발한다.

이 방법에는 여러 단점이 있다.
제품에 대한 통제력을 잃고 원하는 기능 모두를 구현할 수 없기도 하고 정확하게 구현하지 못할 수도 있다.

7.10 상용 기성품 소프트웨어 (Commercial Off-the-Shelf Software)

기성품 소프트웨어 역시 필요한 기능을 모두 포함하는 경우는 없다.
하지만 장점은 고려해볼만 하다.

일단 구매하면 바로 사용할 수 있으므로 직접 개발해서 출시하기 전 까지 기성품 소프트웨어를 통해 일부 중요한 기능을 써보게 할 수 있다.
기성품 소프트웨어를 통해 익숙해질 무렵 제품 한계를 파악해 우회책을 얘기해줄 수도 있다.

7.11 프로젝트에 가장 적합한 생명주기 선정하기 (Choosing the Most Rapid Lifecycle for Your Project)

가장 효율적인 모델은 어떤 상황에서 사용하느냐에 달려있다. (그림 7-13)

Dinner Menu
Welcome to le Cafe de Lifecycle Rapide. Bon Appetit!

Entrees

Spiral
Handmade rotini finished with a risk-reduction sauce.
$15.95

Evolutionary Delivery
Mouth-watering melange of staged delivery and evolutionary prototyping.
$15.95

Staged Delivery
A five-course feast. Ask your server for details,
$14.95

Design-to-Schedule
Methodology medley, ideal for quick executive lunches.
$11.95

Pure Waterfall
A classic, still made from the original recipe.
$14.95

Salads

Design-to-Toois
Roast canard generously stuffed with juiienned multi-color beans.
*Market Price*

Commercial Off-the-Shelf Software
Chef's alchemic fusion of technology du jour. Selection varies daily.
$4.95

Code-and-Fix
Bottomless bowl of spaghetti lightly sprinkled with smoked design
and served with reckless abandon.
$5.95

Figure 7-13. Choosing a lifecvcle model. No one lifecycle model is best for ai projects. The best lifecycle model for any particular project depends on that project's needs.

프로젝트에 가장 적합한 생명주기 모델을 선택하기 위해 다음의 질문에 대답해 본다.

• How well do my customer and I understand the requirements at the beginning of the project? Is our understanding likely to change significantly as we move through the project?
• How well do I understand the system architecture? Am I likely to need to make major architectural changes midway through the project?
• How much reliability do I need?
• How much do I need to plan ahead and design ahead during this project for future versions?
• How much risk does this project entail?
• Am I constrained to a predefined schedule?
• Do I need to be able to make midcourse corrections?
• Do I need to provide my customers with visible progress throughout the project?
• Do I need to provide management with visible progress throughout the project?
• How much sophistication do I need to use this lifecycle model successfully?

이 질문에 대답한 후 표 7-1을 보고 어떤 생명주기 모델을 사용할지 결정할 수 있다.

Table 7-1. Lifecycle Model Strengths and Weaknesses

Capability	Pure Waterfall	Code-and-Fix	Spiral	Modified Waterfalls	Evolutionary Prototyping
Works with poorly understood requirements	Poor	Poor	Excellent	Fair to excellent	Excellent
Works with poorly understood architecture	Poor	Poor	Excellent	Fair to excellent	Poor to fair
Produces highly reliable system	Excellent	Poor	Excellent	Excellent	Fair
Produces system with large growth envelope	Excellent	Poor to fair	Excellent	Excellent	Excellent
Manages risks	Poor	Poor	Excellent	Fair	Fair
Can be constrained to a predefined schedule	Fair	Poor	Fair	Fair	Poor
Has low overhead	Poor	Excellent	Fair	Excellent	Fair
Allows for midcourse corrections	Poor	Poor to excellent	Fair	Fair	Excellent
Provides customer with progress visibility	Poor	Fair	Excellent	Fair	Excellent
Provides management with progress visibility	Fair	Poor	Excellent	Fair to excellent	Fair
Requires little manager or developer sophistication	Fair	Excellent	Poor	Poor	Poor

Capability	Staged Delivery	Evolutionary Delivery	Design-to-Schedule	Design-to-Tools	Commercial Off-the-Shelf
Works with poorly understood requirements	Poor	Fair to excellent	Poor to fair	Fair	Excellent
Works with poorly understood architecture	Poor	Poor	Poor	Poor to excellent	Poor to excellent
Produces highly reliable system	Excellent	Fair to excellent	Fair	Poor to excellent	Poor to excellent
Produces system with large growth envelope	Excellent	Excellent	Fair to excellent	Poor	N/A
Manages risks	Fair	Fair	Fair to excellent	Poor to fair	N/A
Can be constrained to a predefined schedule	Fair	Fair	Excellent	Excellent	Excellent
Has low overhead	Fair	Fair	Fair	Fair to excellent	Excellent
Allows for midcourse corrections	Poor	Fair to excellent	Poor to fair	Excellent	Poor
Provides customer with progress visibility	Fair	Excellent	Fair	Excellent	N/A
Provides management with progress visibility	Excellent	Excellent	Excellent	Excellent	N/A
Requires little manager or developer sophistication	Fair	Fair	Poor	Fair	Fair