요구사항 확인

소프트웨어 생명주기

소프트웨어 개발방법론의 바탕이 되며, 소프트웨어 개발을 위해 정의 · 운용 · 유지보수 등을 단계별로 나눈다.
소프트웨어 생명주기는 소프트웨어 개발단계와 각 단계별 주요활동, 활동 결과에 대한 산출물(소프트웨어 수명 주기)
생명 주기를 표현하는 형태 = 소프트웨어 생명 주기 모형
소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임

폭포수 모형

폭포수처럼 한 번 떨어지면 못 올라가듯 각 단계를 확실히 끝내고 다음 단계로 넘어가는 모형

• 소프트웨어 공학에서 가장 오래되고 폭넓게 사용된 방식(고전적 생명주기 모형)
• 소프트웨어 개발과정의 한 단계가 끝나야만 다음 단계로 이동(선형 순차적 모형)
• 매뉴얼 작성 필요
• 단계가 끝난 후에는 다음 단계를 수행할 결과물이 명확하게 산출되어야 한다.
• 두 개 이상의 과정 병행 X

프로토타입 모형

사용자 요구사항을 위해 프로토타입(견본)을 만들어 최종 결과물을 예측하는 모형.

• 프로토타입은 사용자-시스템 사이의 인터페이스에 중점을 둔다.
• 시스템 일부 혹은 모형을 프로토타입으로 만들어, 추후 구현 단계에서 골격 코드로 사용한다.
• 개발 완료 후 오류가 생기는 폭포수 모형의 단점을 보완한 모형이다.

나선형 모형(점진형 모형)

폭포수와 프로토타입 모형의 장점에 따른 위험분석 기능을 추가한 모형

• 나선처럼 여러 번의 소프트웨어 개발과정을 거쳐 점진적으로 완벽한 비전을 개발하는 것.
• 소프트웨어를 개발하며 발생하는 위험 관리 및 최소화를 목적으로 둠
• 개발과정이 반복되므로 누락되거나 추가된 요구사항 추가할 수 있으며, 유지보수 과정이 필요 없다.

애자일 모형

• 고객 요구사항에 유연하게 대흥할 수 있도록 일정 주기를 반복하며 개발과정 반복
• 특정 개발방법론이라기보다는 고객과의 소통에 초점을 둔 개발방법론이다.(폭넓은 개념)
• 스프린트 또는 이터레이션(짧은 개발 주기) 반복. 반복되는 주기마다 결과물의 고객평가와 요구를 수용.
• 요구사항에 우선순위를 두고 개발
• 소규모 프로젝트, 숙련된 개발자, 급변하는 요구에 걸맞는 타입
• 애자일 기반의 소프트웨어 개발 모형 : 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM, DAD 등

폭포수와 애자일 비교

	폭포수	애자일
새로운 요구사항 반영	어려움	지속적 반영
고객과의 의사소통	적음	지속적
테스트	마지막에 모든 기능을 한 번에 테스트	반복되는 일정 주기가 끝날 때마다
개발중심	계획, 문서(매뉴얼)	고객

2. 스크럼 기법

팀이 중심이 되어 개발 효율성을 높이며, 팀원 스스로가 스크럼 팀을 구성하여 개발작업을 스스로 해결할 수 있어야 한다.
스크럼 팀은 제품책임자, 스크럼마스터, 개발팀으로 구성

제품관리자

이해관계자 중 개발될 제품 이해도가 높고 요구사항을 책임지고 의사결정을 책임진다. 주로 개발의뢰자, 사용자.
이해관계자들의 의견을 종합하여 요구사항 작성
요구사항 백로그를 작성하고 백로그 우선순위를 지정한다.

스크럼 마스터

팀에게 객관적 조언을 하는 가이드 역할(팀원 통제 목표 X)
일일 스크럼 회의로 진행사항 점검하며, 개발과정 중의 장애요소를 공론화하여 처리

개발팀

• 제품관리자와 스크럼마스터를 제외한 모든 팀원. 디자이너, QA도 포함

스크럼 개발 프로세스

• 제품 백로그
  • 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
  • 지속적으로 업데이트된다.
  • 백로그의 요구사항에 따라 전체 일정 계획(릴리즈 계획)을 수립한다.
    
    
• 스프린트 계획 회의
  • 제품 백로그 중 이번 스프린트에서 수행할 작업의 단기 일정 수립
  • 스프린트에서 처리할 요구사항을 Task(작업 단위)로 분할하여 개발자별로 수행할 작업목록인 스프린트 백로그 작성
    
    
• 스프린트
  • 실제 개발작업 진행과정이며, 2~4주 내 진행
  • 스프린트 백로그에 작성된 Task 대상으로 작업시간 및 양을 추정하여 개발담당자에게 할당
  • Task 할당 시 개발자가 원하는 Task 직접 선별 · 담당
  • 개발담당자에게 할당된 Task는 보통 할일 · 진행중 · 완료의 상태를 가진다.
    
    
• 일일 스크럼 회의
  • 모든 팀원이 모여 짧게 진행 상황 점검하는 행위
  • 서서 진행하며, 남은 작업 시간은 소멸차트(Burn-down Chart)에 표시
  • 스크럼 마스터는 발견된 장애요소를 해결할 수 있도록 도와준다.
    
    
• 스프린트 검토 회의
  • 부분 또는 전체가 요구사항에 부합하는지 사용자를 포함한 참석자 앞에서 테스팅한다.
  • 스프린트 한 주당 한 시간 내 진행
  • 제품책임자는 개선할 사항에 대한 피드백 정리 후 다음 스프린트에 반영하도록 백로그 업데이트한다.
    
    
• 스프린트 회고
  • 스프린트 주기를 되돌아보며 정해진 규칙 준수 및 개선점 등을 확인하고 기록한다.
  • 해당 스프린트가 끝난 시점에서 수행하거나 일정 주기로 수행한다.