소프트웨어 생명주기

소프트웨어 생명주기(Software Life Cycle)

소프트웨어 생명 주기는 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 단계 별로 나눈 것이다.

대표적인 생명 주기 모형 종류는 다음과 같다.

 

폭포수 모형(Waterfall Model)

폭포수 모형은 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고,
그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계로 진행하는 개발 방법론이다.

가장 오래되고 전통적인 소프트웨어 생명 주기 모형이다.

각 단계가 끝난 후, 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 한다.

 

프로토타입 모형(Prototype Model)

실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형이다.

기능을 우선으로 간단한 시제품을 만들고 이것을 바탕으로 고객의 의견을 듣고 보완해 나가는 방법론이다.

나선형 모형(Spiral Model, 점진적 모형)

나선형 모형은 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐
점진적으로 최종 소프트웨어를 개발하는 모형이다.

 

폭포수 모형과 프로토 타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.

유지보수 과정이 필요 없다는 특징이 있다.

 

애자일 모형(Agile Model)

애자일(Agile)은 민첩한, 기민한이라는 뜻으로
고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형이다.

이전 단계로 돌아갈 수 없는 폭포수 모형과는 대조적인 모형이라고 볼 수 있다.

 

어떤 특정 개발 방법론이 아니라 고객과의 끊임없는 소통을 통해 맞춤형으로 개발하여
시장의 변화에 빠르고 기민하기 위한 방법론이다.

 

애자일 개발 방식은 계획과 개발, 출시와 같은 개발 주기가 작고 여러번 반복되며
계속 요구사항을 추가하거나 변경하여, 결과적으로 고객에게 좀 더 빠른 결과물을 내놓고
고객의 피드백에 민첩하게 반응되는 장점이 있다.

 

애자일에는 4가지 핵심 가치가 있다.

1. 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
2. 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
3. 계약 협상보다는 고객과 협업에 더 가치를 둔다.
4. 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

대표적인 애자일 모형

• 스크럼(Scrum)
• XP(Extreme Programming)
• 칸반(Kanban)
• Lean
• 기능 중심 개발(FDD; Feature Driven Development)

스크럼(Scrum)

스크럼은 팀이 중심이 되어 개발의 효율성을 높이는 기법이다.

팀원 스스로가 스크럼 팀을 구성하고 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 한다.

스크럼 팀은 다음과 같이 구성된다.

• 제품 책임자(PO; Project Owner)
  - 요구사항이 담긴 백로그(Backlog)를 작성하는 주체
  - 이해관계자들 중 개발될 제품에 대한 이해도가 높은 사람
  - 요구사항을 책임지고 의사를 결정할 사람
• 스크럼 마스터(SM; Scrum Master)
  - 스크럼 팀이 스크럼을 잘 수행하도록 가이드 역할
• 개발팀(DT; Development Team)
  - 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
  - 제품 개발 수행

백로그(Backlog)

백로그란 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록이다.

 

스크럼의 개발 프로세스

1. 스프린트 계획
   - 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의
2. 진행(스프린트)
   - 실제 개발 작업을 진행하는 과정으로 보통 2 ~ 4주 정도의 기간 내에서 진행
3. 일일 스크럼 회의(Daily Scrum Meeting)
   - 모든 팀원이 매일 약속된 시간에 짧게 진행 상황을 점검하는 회의
   - 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시
4. 스프린트 검토 회의 (Scrum Review)
   - 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의
5. 스프린트 회고(Sprint Retrospective)
   - 정해놓은 규칙 준수 여부 및 개선점 확인 및 기록

XP(eXtreme Programming)

XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해
고객의 참여와 개발 과정 반복을 극대화하여 개발 생산성을 향상시키는 방법이다.

 

짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통하여
소프트웨어를 빠르게 개발하는 것을 목적으로 한다.

 

릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높인다.
가시성이란 대상을 확인할 수 있는 정도를 의미한다.

 

XP의 5가지 핵심 가치

• 의사소통(Communication)
• 단순성(Simplicity)
• 용기(Courage)
• 존중(Respect)
• 피드백(Feedback)

XP의 개발 프로세스

• 사용자 스토리 (User Story)
  - 고객의 요구사항을 간단한 시나리오로 표현한 것
• 릴리즈 계획 수립(Release Planning)
  - 부분 혹은 전체 개발 완료 시점에 대한 일정 수립
  - 몇개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함
• 스파이크
  - 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
• 주기(Iteration)
  - 실제 개발 작업을 진행하는 과정으로, 보통 1~3주 정도 기간으로 진행
• 승인 검사(인수 테스트)
  - 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트
• 소규모 릴리즈
  - 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것

XP의 주요 실천 방법(Practice)

• Pair Programming (짝 프로그래밍)
  - 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠갖도록 조성
• Collective Ownership (공동 코드 소유)
  - 개발 코드에 대한 권한과 책임을 공동으로 소유함
• Test-Driven Development (테스트-주도 개발)
  - 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하고 개발하는 방법
  - 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조,프레임워크)를 사용한다.
• Whole Team (전체 팀)
  - 개발에 참여하는 모든 구성원은 각자 자신의 역할이 있고 역할에 대한 책임을 가져야 한다.
• Continuous Integration (지속적인 통합)
  - 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적으로 통합되어야 한다.
• Refactoring (리팩토링)
  - 프로그램의 기능 변경 없이 시스템을 재구성하는 것이다.
  - 코드의 가독성을 높이고, 유지보수를 보다 쉽게 하기 위하여 진행하는 프로세스이다.
• Small Release (소규모 릴리즈)
  - 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있다.

 

칸반(Kanban)

칸반은 일별 작업을 시각적으로 추적하고 작업 흐름을 최적하하기 위해 설계하기 위한 방법론이다.

칸반보드 예시

칸반은 다음과 같은 특징을 갖고 있다.

• 시각적 보드
  - 작업 항목을 시각적 보드로 나타내며, 보드에는 할 일, 진행 중, 완료 등의 열이 있다.
  - 각 열에는 작업 항목을 표시한다.
• 한계랑(Work in Progress, WIP) 제한
  - 칸반은 각 열에 대한 작업 항목의 최대 한계량을 정의한다.
  - 한계량을 초과하지 않도록 작업을 진행하며 이는 작업 흐름을 원활하게 유지하게 도와준다.
• 풀 시스템 시각화
  - 전체 작업 흐름을 시각화하고, 각 작업 항목의 상태와 진행 상황의 실시간 추적을 도와준다.
  - 작업 상태를 파악하고, 문제를 빠르게 식별가능하다는 장점이 있다.
• 작업 우선순위
  - 작업 항목에 대한 우선순위를 설정하는 데 중점을 두며, 우선순위에 따라 작업을 선택하고 진행한다.
• 지속적인 개선
  - 칸반은 작업 흐름을 모니터링하고 문제를 해결한다.
  - 프로세스를 개선하기 위해 팀의 피드백을 활용하면서 지속적으로 개선한다.

칸반은 작은 팀 또는 서비스 지향 프로젝트에서 효과적으로 사용된다.
시각적 표현과 한계량 제한을 통해 팀이 작업을 조직하고 효율적으로 완료할 수 있록 도와준다.