소프트웨어 개발방법론

Waterfall model

소프트웨어 개발 프로세스 각 단계를 체계적(순차적)으로 거쳐가는 모델

각 단계마다 review와 approval 필요. 필요하다면 "loop-back" 가능

1. Requirements definition
2. System and software design 
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance

- 장점: 관리와 실행이 간단, 고정된 비용의 프로젝트에 적합, 전체 프로젝트에 대한 예산과 일정 추정이 쉬움

- 단점: 완전한 요구사항을 추출하기 위해서 많은 시간이 필요, 제품이 실패할 확률이 높음(21%), 정적인 시장에만 적합함, 기술적 어려움으로 고객의 예상과 다를 수 있음

 

<예시>

 

---

(Iterative and) Incremental development

정해진 요구사항을 여러 단계로 나누어 각 단계별로 소프트웨어의 설계 및 구현 그리고 테스팅을 반복하면서 기능을 추가하고 점진적으로 제품을 완성해 나가는 방법

 

- 장점: 변경사항에 대응하기 좋음, 결과물들이 자주 나오므로 피드백을 받기 쉬움

- 단점: 프로세스 단계가 명확하지 않아 프로젝트의 진행상황을 알기 어려움

• Sync-and-Stabilize: MS사의 사례. 프로젝트 모듈을 팀 별로 나누어 병렬로 효율적으로 작업.
• 3~4개의 이정표 subprojects가 있음, 개발 과정에서의 끊임없는 고객 피드백, 잦은 동기화와 안정화 
  1.  Planning:
     • Vision statement (제품 기능의 전반적인 명세와 특징의 우선순위 확인)
     • Specification Document(interdependencies 정의)
     • Schedule and Feature Team Formation (일정에 맞게 팀 조정, 1명의 프로젝트 매니저, 3-8명의 개발자, 3-8명의 테스터)
  2. Development: 3개의 subproject로 나누어 각 phase 별로 1/3 feature 구현
  3. Stabilization: 프로젝트 매니저는 고객의 피드백 추적, 개발자는 마지막 디버깅과 코드 안정화, 테스터는 오
     류 재생성 및 격리 
     • internal testing(회사 내 완성 제품 검사), external testing ('beta'사이트를 통한 회사 외 검사), 출시 준비

---

Agile model

프로젝트의 생명주기동안 반복적인 개발을 촉진

일정한 짧은 주기마다 필요한 요구를 더하고 수정

team size가 작은 프로젝트에서 주로 사용하는 방법

 

- 장점: waterfall과 비교했을 때 실패할 위험이 2.5배 낮음, 잦은 출시와 피드백 수집, 개발 동안에 생긴 요구사항 변화를 잘 다룸, 고객의 높은 참여가 기대 충족 보장, 오류가 일찍 발견됨.

- 단점: 고정된 비용의 프로젝트에 부적합, 개발 종료 일자와 정해진 마지막 가격이 없음, 숙련된 팀원이 필요, Technical debt(기술 부채: 개발 팀이 나중에 리팩터링해야 하는 기능 또는 프로젝트의 제공을 촉진하기 위해 조치를 취할 때의 이후 더 많은 작업이 필요함에 따라 발생하는 모든 문제)

 

• 애자일의 여러 방법론 및 핵심 개념
  • TDD(Test-driven development) - 코드 개발 전 테스트 케이스를 먼저 만듦
  • Scrum: 기능의 우선 순위 부여, 개발 주기마다 실제 동작하는 결과/적용할 기능/개선 목록 제공, 매일의 15분 회의
  • XP(Extreme programming): pair programming, daily meeting, 실제로 필요할 때까지 기능을 프로그래밍하지
    않음, 코드의 단순성 및 명확성, 고객과의 잦은 소통, 광범위한 코드 검토 수행 등
  • Pair programming: 프로그래머와 리뷰어 역할을 자주 바꿈 - 바꾸는 시간이 짧을 수록 오류를 미리 고칠 수 있음, 프로그램이 복잡할수록 개발기간 및 defect rate 감소(품질향상), knowledge transfer 증가(junior-senior 일수록)
  •  Retrospective: 애자일 주기마다 잘 진행된 것, 그렇지 않은 것, 다음에 향상될 수 있는 것 등을 회의하며 팀이 문제를 해결하고 스스록 개선하도록 도움
  • Sprint/iteration Planning: 팀이 next sprint(*sprint: 계획, 개발, 리뷰 등 최소 단위의 cycle. 보통 1~4주 단
    위)에 무엇을 어떻게 완료할 것인지 결정하는 단계
  • Sprint/iteration Review: sprint의 마지막에 열리는 회의로 팀은 달성한 내용을 보여주고 이해관계자는 피드백을 제공
  • Short Iterations: 작업 섹션이 개발되고 테스트되는 짧은 기간이며 각 반복에는 모든 결과물을 달성해야 하는 정해진 완료 날짜가 있음. 이를 통해 위험 요소를 빠르게 파악하고 문제가 확대되기 전에 해결 가능
  • Kanban: 프로젝트 전달성과 팀원 간의 협동을 높이기 위해 보드에 전체 프로젝트를 시각화하는 것에 집중하는 agile 기법
  • Planning poker/team estimation: 각 단계마다 팀원들의 의견을 통해 일정을 추정 및 합의
  • Daily standup: 프로젝트 팀이 10-15분 동안 지난 회의 이후 완료한 작업과 향후 작업을 조정하는 회의, 목적은 정보 공유 및 하루를 효율적으로 보내는 것. 각 직원에게 3가지 질문(어제 무엇을 했니? 오늘 무엇을 하니? 장애물은 무엇이니?)