소프트웨어 개발 방법론 { 생명 주기, 폭포수 모형, 나선형 모형, 하향식, 상향식, 프로토타입, HIPO, V, Agile, XP }

소프트웨어 설계 방법론

• 소프트웨어 생명 주기 Software Life Cycle :
  소프트웨어 제품의 개념 형성에서 시작하여 운용 / 유지보수에 이르기까지 변화의 모든 과정이다. 
  
  -> 타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수 
• 폭포수 모형 waterfall Model 의 개요
  
  폭포의 물은 떨어지면 다시 올라가지 못한다. 이처럼 소프트웨어 개발은 처음부터 순서대로 쭉 해나가야 한다는 것이다. 폭포수 모형은 소규모 개발에 적합합니다. 왜냐하면 빠르게 우리가 해야하는 일들을 정리해서 정확하게 진행할 수 있기 때문이다. 단점은 변경사항이 발생하거나 이벤트가 발생하면 수정을 할 수가 없습니다. 그래서 나온 것이 나선형 모형입니다.

• 나선형 모형 Spiral Model 
  
  반복적인 작업을 수행하는데, 중간에 위험분석이 들어가 있는 형태입니다. 위험분석이라는 것은 개발을 하는 과정에 변동사항은 없는지 확인하는 것입니다. 
  
  -> 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가

• 하향식 설계
  
  소프트웨어 설계 시 제일 상위에 있는 주사용자함수 Main User Function 에서 시작하여 기능을 하위 기능들로 나눠 가면서 설계하는 방식이다. 즉 기둥을 먼저 만들고 가지를 후에 만드는 방식을 의미한다. 
• 상향식 설계
  
  아주 단순한 아이들을 먼저 만든 다음 이것을 사용하는 상위 수준의 컴포넌트를 설계하는 방식이다. 
• 프로토타입 모형
  
  프로토타입을 먼저 만듭니다. 이렇게 먼저 만들면 고객과의 소통이 아주 원활해집니다. 결과적으로는 프로토타입을 만들면 이것을 가지고 완성품을 만들기도 하지만 큰 프로젝트에서는 프로토타입은 보통 폐기시킵니다.
• HIPO (Hierarchy Input Process Output) 
  
  계층적 입력 처리를 의미하는 HIPO 는 폭포수 모델과 마찬가지로 입력, 처리, 출력으로 구성되는 시스템 분석 및 설계와 시스템 문서화용 기법이다. 일반적으로 가시적 도표(Visual Table of Contents), 총체적 다이어그램(Overview Diagram), 세부적 다이어그램 (Detail Diagram) 으로 구성된다. HIPO 는 하향식 소프트웨어 개발을 위한 문서화 도구이다. HIPO 는 가시적 도표를 활용하여 전체적인 기능과 흐름을 보여주는 구조이다. 보기 쉽고 이해하기 쉬우며 유지보수가 쉬운 특징이 있다. 

• V - 모델
  
  폭포수 모형에  시스템 검증과 테스트 작업을 강조한 모델이다. 아래 그림에서 왼쪽만 수행하는 것이 HIPO 가 된다. 요구사항 분석, 기능명세 분석, 설계, 개발 각각의 단계에 테스트 단계를 추가한 것을 의미한다. 아래 그림이 시험에 엄청 출제되므로 반드시 알아야 한다. 
  
  아래 그림을 한번 살펴보자면, 요구사항에 따라 우리가 어떤 기능을 구현해야 하는지 분석을 한 후, 설계를 하고, 실제 코딩을 하는 개발 단계로 구성되어 있으며, 이렇게 첫 단계에서는 테스트 계획 및 설계를 정적 테스트 하게 된다. 그리고 오른쪽에서는 동적 테스트를 하게 된다. 정적과 동적의 차이는 정적은 코드를 보면서 판별하는 것이고 동적은 실제로 코드를 실행시키는 것을 의미합니다. 실제 요구사항과 우리가 만들어낸 것이 각각의 단계에서 같은지 알아보는 것을 "확인"이라고 합니다. 

• 애자일 Agile 개발 방법론
  
  애자일 Agile 이란 화살이 날아가서 과녁에 명중하는 것을 의미하는 말로, 엄청 빠르게 날아가서 목표를 달성하는 것을 의미한다. 소프트웨어를 개발하는데, 정확하게 고객이 원하는 것만 구현하면 된다는 것이 Agile 개발 방법론이다. 절차와 도구는 중요하지 않고 고객이 원하는대로 고객이 의도한대로 제품이 만들어졌는냐가 중요하다. 
  
  애자일의 종류에는 익스트림프로그래밍(XP, eXtremeProgramming), 스크럼(SCRUM), 린(Lean), DSDM(Dynamic SYstem Development Method, 동적 시스템 개발 방법론), FDD(Future Driven Development 기능 중심 개발) 등이 있습니다. 

• Agile 선언문
  
  다른거 다 필요 없고 고객과 잘 소통해서 고객이 원하는 것을 만들어주자는 것이 Agile 선언문 입니다. 
• XP(eXteremProgramming)
  
  아주 빠르게 양질의 소프트웨어를 개발하는 것을 의미합니다. 
  
  XP 핵심 가치
  
  
  XP는 기본적으로 Agile 이다. 따라서 다음과 같은 핵심 가치를 가지고 있다. 
  소통, 단순성, Feedback, 용기(고객의 요구사항 변화에 능동적 대응할 용기), 존중

• XP 과정을 그린 위 그림에서 핵심은 Iteration 반복이다. 고객이 과정에 참여해서 이 제품이 정말 내가 원하는 것인지 반복 확인 하면서 개발을 하게 된다. 
• XP 용어
  
  
  Spike : 어려운 요구사항, 잠재적 솔루션을 고려하기 위해 작성하는 간단한 프로그램 
  User Stories : 사용자가 실제로 어떻게 사용할지를 시나리오로 표현한 것이다. 
  Release Planning : 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것으로 부분/전체 개발 완료 시점에 대한 일정을 수립한다. 
  Itertation : 하나의 릴리즈를 세분화한 단위이며 1~3주 단위로 진행된다. 반복 진행 중 새로운 스토리가 추가 될 때 진행 중 반복이나 다음 반복에 추가될 수 있다. 
  Acceptance Test : 릴리즈 단위의 개발이 구현되었을 때 진행하는 테스트로 사용자 스토리에 작성된 요구사항을 확인하여 고객이 직접 테스트한다. 오류가 발견되면 다음 반복(Iteration)에 추가한다. 테스트 후 고객의 요구사항이 변경되거나 추가되면 중요도에 따라 우선순위가 변경될 수 있다. 완료 후 다음 반복을 진행한다. 
  Small Release : 릴리즈 단위를 기능별로 세분화하면 고객의 반응을 기능별로 확인할 수 있다. 최종 완제품일 때 고객에 의한 최종 테스트 진행 후 고객에 제공한다. 
• XP 의 12가지 실천사항(Practice)
  
  1. Fine Scale Feedback
  - Pair Programming (짝 프로그래밍) : 짝을 이루어 한 사람은 코딩, 한 사람은 검사를 수행
  - Planning Game : 게임처럼 선수와 규칙, 목표를 두고 기획에 임한다. 
  - Test Driven Development : 실제 코드 개발 이전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드를 작성한다. 
  - Whole Team : 사용자가 팀에 속하여 개발한다. 
  
  2. Continuous Process
  - Continuous Integration : 상시 빌드 및 배포를 할 수 있는 상태로 유지한다.
  - Design Improvement : 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성을 수행한다. 
  - Small Releases : 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 한다. 
  
  3. Shared Understanding 
  - Coding Standards : 소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성한다. 
  - Collective Code Ownership : 시스템에 있는 소스 코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정할 수 있다. 
  - Simple Design : 가능한 가장 간결한 디자인 상태를 유지한다. 
  - System Metaphor : 최종적으로 개발되어야 할 시스템의 구조를 기술한다. 
  
  4. Programmer Welfare 
  - Sustainable Pace : 일주일에 40시간 이상 작업 금지, 2주 연속 오버타임을 금지한다. 

단순성

Iteration

정형분석

• 효과적인 프로젝트 관리를 위한 3대 요소 (3 P)
  
  - 사람 : 인적 자원
  - 문제 : 문제 인식
  - 프로세스 : 작업 계획