1 이론적 측면의 소프트웨어 개발

2 반복과 점진

3 반복과 점진의 위험과 또 다른 측면

4 반복과 점진 관리하기

5 코드-픽스 생명주기 모델

6 폭포수 생명주기 모델

7 라피드 프로토타이핑 생명주기 모델

8 Extreme Programming과 Agile Processes

9 기타 모델

소프트웨어 개발은 이론적인 것과 실무적인 차이가 상당히 많다. 그 이유는 아래와 같은 2가지다.

• 소프트웨어 전문가들도 인간이기 때문에 실수한다.
  
• 클라이언트의 요구사항들은 소프트웨어가 개발 중인 경우에도 변경된다.
  
  

분명한 것은 소프트웨어 개발이 실제로 '무질서하게 개발되느냐?'가 문제다. 소프트웨어 전문가들도 인간이기 때문에 실수한다. 그리고 소프웨어 프로덕트는 실세계의 모델이기 때문에 계속적으로 변화한다는 사실을 항상 인지하고 있는 것이 중요하다. 그렇다고 소프트웨어의 잦은 변경은 이유가 어찌되었던지 소프트웨어 프로덕트에는 해롭다. 그래서 소프트웨어 프로덕트는 가능한 독립적인 컴포넌트들의 집합으로 설계하는 것이 중요하다. 잦은 변경은 다음과 같이 문제점들이 눈덩이처럼 불어난다.

1. 소프트웨어의 한 부분에 대한 변경에도 소위 회귀결함(regression fault)라 부르는 코드의 관련없는 부분에 결함이 반입된다.
   
2. 수많은 변경으로 코드내에 종속성(dependency)들이 반입되게 된다.
   
3. 종속성이 반입되게 되면 실제로 어떤 변경에도 하나 또는 그 이상의 회귀결함들을 반입하게 된다.
   
4. 계속된 변경으로 인하여 재설계 또는 재구현 할 수 밖에 없게 된다.
   
   

실세계 소프트웨어를 개발은 반복적, 점진적 과정이다. 다음그 설명이다.

반복적(iterative)
산출물(artifact)의 성공적인 버전[1]의 관점에서 기본 프로세스는 반복적(iterative)이다. 즉, 산출물의 첫 번째 버전을 생성한 후 이를 수정해서 두 번째 버전을 생성해 낸다. 또 이 프로세스는 반복된다.

점진적(incrementation)
실세계 소프트웨어를 개발하는 두 번째 측면은 Miller의 법칙[2]이 우리에게 가요한 제약이다. 예를 들면 코드 산출물은 7개 이상의 변수들을 가질 수 있고, 요구사항 문서에는 7개 이상의 요구사항들을 가질 수 있다. 인간이 처리할 수 있는 정보의 양에 대한 이러한 제약을 해결하는 한 방법으로 단계적 정제(stepwise refinement)가 사용된다. 이 방법은 현재 가장 중요한 것에 집중(7개)하고 그렇지 않은 것들은 차후로 연기시키고, 중요한 것들이 모두 처리되면 연기시킨 것들 중에서 중요한 것들을 추려내어 집중하고 그렇지 않은 것들을 차후로 연기시키는 과정을 반복하는 것이다. 결국은 모든 것이 처리된다. 이것이 점진적 프로세스(incrementation process)이다.

x: 시간, y: 1사람-시간(1 person-hour)

계획수립(planning)과 문서화 활동들(documentation actvities)은 반복-점진적 생명주기 전체에 수행된다. 테스팅(testing)은 각 반복 동안에, 그리고 특히 각 반복의 후반부에 주요 활동이다. 추가적으로 소프트웨어 개발이 완료된 후에는 전체적으로 철저하게 테스트되어야 한다. 각각의 웍플로우(요구사항, 분석, 설계, 구현, 테스트)는 각각 점진적 수행단계(IncrementA ~ D)에서 반복적으로 수행된다. 즉, 요구사항, 분석, 설계, 구현, 테스트는 소프트웨어 개발이 완료될 때까지 계속적으로 반복된다.

• 소프트웨어 프로덕트가 수정되는 것들 체킹하는 다중 기회들을 제공한다. (비용절감)
  
• 아키텍처의 강건성(robustness)이 바로 명확해진다. (반복-점진적인 과정에서 재조직, 재작성이 이루어지면 강건성이 없는 것이다.)
  
• 초기에 위험(risk)들을 완화시켜준다. 위험들은 개발과 유지보수 과정에 항상 내포되어 있다. 중요한 것을 먼저 하기 때문에 프로젝트에 큰 영향을 끼치는 risk는 초기에 발견된다.
  
  

반복-점진적 모델은 연속적으로 적용된 폭포수 모델이다.

프로덕트가 요구사항도 없이, 설계도 하지 않고, 구축된다는 의미이다. 제일 안 좋은 생명주기 모델이다. 일명 '주먹구구'

폭포수 생명주기 모델(waterfall life-cycle model)은 Royce(1970)가 처음 제안했다. 아래 그림은 단순한 폭포수 모델에 프로덕트가 개발되는 동안 유지보수를 위한 피드백 루프들을 반영시킨 폭포수 생명주기 모델이다.

폭포수 모델에 관한 중요한 시사점은 해당 페이즈에 대한 문서화가 완성되어 그 페이즈의 프로덕트가 SQA(software quality assurance)그룹의 승인을 받아야만 그 페이즈가 완료된다는 점이다. 모든 페이즈에 테스팅이 포한된다. 특히 유지보수 동안에 프로덱트의 수정된 버전이 이전 버전이 수행했던 것을 아직도 정확하게 수행하고 있는지 확인(회귀 테스팅)하고, 클라이언트가 요구한 새로운 사항들을 전체적으로 만족하는지 확인하는 것이 꼭 필요하다. 폭포수 모델은 많은 강점을 가지고 있지만 문서화 중심 모델이기 때문에 문서의 설명과 이해도가 매우 중요하다. 문서화 중심 모델은 다음과 같은 약점이 있다.

• 클라이언트의 이해부족(클라이언트와 문서간의 프로토콜이 맞지 않음)
  
• 클라이언트의 이해와 실제 문제와의 차이가 존재
  
  

다음의 소프트웨어 개발 프로세스 문서도 참고하라.

라피드 프로토타입(rapid prototype)은 기능적으로 프로덕트의 부분집합과 같은 작동 모델(working model)을 말한다. 즉, 클라이언트가 원하는 바가 무엇인지 간단하게 실제로 구현하여 클라이언트에게 보여주고 확인한다. 그리고 클라이언트가 대부분 만족한다면 실제 요구사항을 반영시켜 명세 문서를 작성한다. 그러므로 첫 번째 단계는 가능한 빠른 시간내에 프로토타입을 구축해서 클라이언트의 미래의 사용자들에게 이를 조사해서 실제로 필요한 것인 무엇인지 파악하는데 있다.

프로토타입 모델의 주요 강점은 프로덕트 개발이 실제로 라피드 프로토타입에서 인도되는 프로덕트로 선형적으로 진행된다는 점이다. 즉, 폭포수 모델의 피드백 루프가 라피트 프로토타이핑 모델에서는 거의 필요치가 않은데, 그 이유는 다음과 같다.

• 개발팀이 작성한 문서는 라피드 프로토타입을 기반으로 한다. (개발팀과 클라이언트는 함께 소프트웨어를 작성시켜가면서 검증하기 때문에 결과 문서는 명확하다고 판단되기 때문이다.)
  
• 설계 단계에서 프로토타입을 통해 방향과 내용을 얻을 수 있고, 최악의 경우에는 "그렇지 않은 방법"을 알게 된다.
  
• 구현 단계에서 이미 예비 작동 모델이 완성되었기 때문에 구현중이나 구현 후에 설계를 고칠 필요성을 줄여준다.
  
  

라피드 프로토타입의 유일한 사용 목적은 클라이언트의 진정한 요구가 무엇인지를 결정하는 것이고, 이것이 결정되는 라피트 프로토타입은 무시된다. 이러한 이유 때문에 라피드 프로토타입의 내부구조는 관련이 없다. 중요한 것은 프로토타입이 빨리 만들어져야 한다는 것이고, 클라이언트의 요구사하을 반영하기 위해 빨리 수정되어야 한다. 그러므로 속도가 핵심이 된다.

XP는 반복-점진적 모델에 기반을 둔 약간은 모순된 새로운 접근법이다.

1. 소프트웨어 개발팀이 클라이언트가 프로덕트를 지원하기를 바라는 다양한 특성들(stories)을 결정하는 것
   
2. 그리고 이러한 특성들 각각에 대해 팀은 클라이언트에게 해당 특성을 구현하여 소용되는 비용과 기간을 알려준다.
   
3. 클라이언트는 비용-이익분석(cost-benefit analysis)을 분석하여 각 계속적인 빌드(build)에 포함되어야 하는 특성들을 선택한다.
   
4. 제안된 빌드(proposed build)는 태스트(task)라고 부르는 작은 소규모 단위들로 분해된다.
   
5. 프로그래머는 우산 한 태스크에 대한 테스트-케이스(test case)들을 작성한다. 이를 TDD(test-driven development)라고 부른다. 한 화면상에서 파트너와 함께 작업하는 것(pair programming)은 프로그래머가 태스크를 구현하면서 모든 테스트 케이스들이 정확하게 작업되는 것을 보장해 준다.
   
6. 이후 태스크는 프로덕트의 현재 버전에 통합된다.
   
   

일반적으로 많은 페어(pair)들이 태스크를 병렬적으로 구현한 후 통합이 계속 진행된다. 태스크에 대한 사용되는 TDD 테스크 케이스는 계속 유지되어 구체적인 모든 통합 테스팅에 활용된다. 다음은 XP의 특성이다.

• XP팀의 컴퓨터들을 작은 칸막이가 설치된 큰 사무실의 중앙에 설치되어 있다.
  
• 클라이언트 대표자는 항상 XP팀과 작업한다.
  
• 개인이 2주 이상 연속으로 작업할 수 없다.
  
• 전문화(specialization)은 없다. 대신에 XP팀의 모든 맴버들이 분석, 설계, 코드, 그리고 테스팅을 작업한다.
  
• 다양한 빌드(build)들이 구축되기 전에 전체적인 설계단계는 없다. 대신에 설계는 프로덕트가......
  
  

XP는 다른 생명주기 모델에 비해 분석과 설계에 대해 크게 강조하지 않는다. 왜냐하면 작동 소프트웨어가 세부 문서보다 중요하기 때문이다. 변경에 대한 응답은 agile processes의 또 다른 주요 목표다. 그래서 클라이언트와 협업의 중요성이 있다.

Grady Booch의 유추(2000)

누구나 개집을 짓기 위해서 몇 장의 널빤지를 망치로 쉽게 두들겨 만들 수는 있지만 방이 세 개인 집을 지으려면 상세 설계 없이는 바보같은 짓이다. 추가로 방이 세 개인 집을 짓는 데는 배수, 배관, 지붕을 공사하는 스킬이 반드시 필요하고 또 인스펙션(inspection)들도 꼭 필요하다. (즉 소규모 소프트웨어 프로덕트를 구축하는 것에는 중간 규모 소프트웨어 프로덕트를 구축하는 스킬을 갖추어야 하는 의미는 꼭 아니다) 더욱이 초고층 빌딩이 1000개의 개집의 높이라는 사실은 초고층 빌딩이 1000개의 개집을 서로 위에 겹쳐서 구축한다는 의미는 아니다. 다른 말로 표현하면 대규모 소프트웨어 프로덕트를 건축하는 것은 소규모 소프트웨어 프로덕트들을 함께 포장하는 것 보다 더 전문적이고 더 정교환 스킬이 요구된다.

Agile processes가 소프트웨어 공학에서 정말로 주요 돌파구인지를 결정하는 핵심요소는 미래의 인도 후 유지보수의 비용이 될 것이다. 만약 agile processes의 사용이 인도 후 유지보수의 비용을 감소싴키는 결과를 갖게 된다면 XP와 다른 agile processes는 폭 넓게 채택될 것이다.

• 프로토타입 모델
  
• 나선형 모델