소프트웨어 개발 방법론

 

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

• 소프트웨어 제품의 개념 형성에 시작하여 운용/유지보수에 이르기까지의 변화의 모든 과정

타당성 검토 > 개발 계획 > 요구사항 분석 > 설계 > 구현 > 테스트 > 운용 > 유지보수

 

1-2. 생명주기 모형의 종류

 

폭포수 모형 (Waterfall Model)

• boehm이 제시한 고전적 생명주기 모형으로 소프트웨어 개발 과정의 단계가 순차적으로 진행되는 모형이다
• 선형 순차 모델이라고도 한다

타당성검사 > 계획 > 요구분석 > 기본설계 >상세설계 > 구현 > 시험 > 운용 > 유지보수

 

폭포수 모형의 장점

• 적용경험과 성공사례가 많음
• 단계별 정의가 분명, 전체 구조 이해가 용이
• 단계별 산출물이 명확

 

폭포수 모형의 단점

• 개발 과정 중에 발생하는 새로운 요구나 경험을 설계에 반영하기 어려움
• 두개 이상의 과정이 병행 수행되거나 이전 단계로 넘어가는 경우가 없음
• 이전 단계의 오류수정이 어려움

 

프로토타입 모형 (Prototype Model)

• 실제 개발될 시스템의 견본을 미리 만들어 최종 결과물을 예측하는 모형
• 개발이 완료되고 나서 사용을 하면 문제점을 알 수 있는 폭포수 모형의 단점을 보완

요구수집 > 빠른 설계 > 프로토타입 구축 > 고객평가 > 프로토타입 조정 > 구현

 

프로토타입 모형의 장점

• 프로토타입은 발주자나 개발자 모두에게 공동의 참조모델 제공
• 구현단계의 골격이 될 수 있음
• 최종 결과물이 만들어지기 전에 의뢰자가 결과물의 일부 또는 모형을 볼 수 있다
• 요구사항이 충실히 반영됨

 

프로토타입 모형의 단점

• 프로토타입과 실제 소프트웨어와의 차이로 인해 사용자의 혼란이 야기될 수 있음
• 폐기 시 비경제적 일 수 있음

 

나선형 모형 (Spiral Model)

• boehm이 제시, 반복적인 작업을 수행하는 점증적 생명주기 모형
• 소프트웨어 개발 중 발생할 수 있는 위험을 관리하고 최소화하는 것이 목적
• 각 개발 순서를 반복하여 수행하는 점진적 방식으로 누락된 요구사항 추가가능
• 유지보수 과정이 필요없음

목표설정(계획수립) > 위험분석 > 공학적 개발(개발과 검증) > 고객평가/다음단계 수립

 

나선형 모형의 장점

• 위험 분석 단계에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로서 완성도 높은 소프트웨어 개발이 가능하다
• 비용이나 시간이 많이 소요되는 대규모 프로젝트나 큰 시스템 구축시 유리하다

 

나선형 모형의 단점

• 위험 분석 단계에서 발견하지 못한 위험 요소로 인한 문제 발생
• 적용 겸험이나 성공 사례가 많지않음

 

2-1. 애자일(Agile) 방법론

 

애자일 방법의 개념

• 사전적 의미로 '날렵한, 재빠른'의 뜻을 가지고 있음
• 소프트웨어 개발 중 설계 변경에 신속하게 대응하여 요구사항을 수용 할 수 있음
• 절차와 도구보다 개인과의 소통을 중요시하고, 고객과의 피드백을 중요시 여김
• 소프트웨어가 잘 실행되는 것에 가치를 둠
• 특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위해 고객과의 협업에 초점을 둠
• 짧은 릴리즈의 반복, 점증적 설계. 사용자 참여, 문서 최소화, 비공식적인 소통, 변화
• eXtremeProgramming, SCRUM, Lean, DSDM, FDD, Crystal 

 

애자일 선언문

• 프로세스나 도구보다 개인과의 소통이 더 중요하다.
• 완벽한 문서보다 실행되는 소프트웨어가 중요하다.
• 계약 협상보다 고객과의 협업이 더 중요하다.
• 계획을 따르는 것보다 변경에 대한 응답이 더 중요하다.

 

2-2. XP(eXtreme Progamming)

정의

• 1999년 Kent Beck이 제안
• 개발 단계 중 요구사항 변동이 심한경우 적합한 방법론
• 요구에 맞는 양질의 소프트웨어를 신속하게 제공하는 것을 목표로 함
• 요구사항을 모두 정의해 놓고 작업을 진행하지 않고, 변경되는 것을 적용하는 방식
• 예측성보단 적응성에 더 높은 가치를 부여
• 고객의 참여와 개발 과정의 반복을 극대화 하여 생산성을 향상하는 방법

 

XP의 핵심 가치 5가지

• 소통(Communication) :  개발자, 관리자, 고객간 원할한 소통 지향
• 단순성(Simplicity) : 부가적 기능, 미사용 구조와 알고리즘 배제
• 피드백(Feedback) : 지속적인 테스트와 통합, 반복적 결함 수정 등을 빠르게 피드백
• 용기(Courage) : 고객 요구사항 변화에 능동적으로 대응
• 존중(Respect) : 개발 팀원 간의 상호 존중을 기본으로 함

소단피용존 (CSFRC)

 

XP 프로세스

 

 

User Story

• 일종의 요구사항, UML의 유스 케이스와 같은 목적으로 생성되나 형식이 없고, 고객에 의해 작성됨

 

Release Planning

• 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것. (Spike)
• 부분/전체 개발 완료 시점에 대한 일정을 수립한다.

 

Iteration

• 하나의 릴리즈를 세분화한 단위. 1~3주 단위로 진행
• 반복 진행 중 새로운 스토리가 추가될 경우 진행 중 반복이나 다음 반복에 추가 될 수 있다.

 

Acceptance Test (인수 테스트)

• 릴리즈 단위의 개발이 구현되었을 때 진행하는 테스트
• 사용자 스토리에 작성된 요구사항을 확인하여 고객이 직접 테스트
• 오류가 발견되면 다음 반복에 추가

 

Small Release

• 릴리즈 단위를 기능별로 세분화하면 고객의 반응을 기능별로 확인 할 수 있음
• 최종 완제품일 때에는 고객에 의한 최종 테스트 진행 후 고객에 제공

 

XP의 12가지 실천사항(Practice)

Pair Programming

• 두 사람이 짝이 되어 한 사람은 코딩을, 한 사람은 검사를 수행
• 코드에 대한 책임을 공유, 비형식적인 컴토를 수행

 

 

2-3. SCRUM

스크럼의 개념

• 반복적이고 점진적인 소규모 팀 중심의 소프트웨어 개발 방법론
• 팀원 간 활발한 소통과 협동심이 필요
• 요구사항 변경에 신속하게 대처
• 개발자들의 팀 구성과 각 구성원의 역할, 일정 결과물 및 그 외 규칙을 정함
• Self Organizing : 팀원 스스로 팀을 구성해야 한다
• Cross Functional : 개발 작업에 관한 모든것을 팀원 스스로 해결해야 한다

 

스크럼의 특징

• 기능 개선점에 우선순위를 부여하고, 개발 주기 동안 실제 동작 가능한 결과를 제공한다
• 개발 주기마다 적용된 기능이다 개선점의 리스트를 제공한다
• 커뮤니케이션을 위하여 팀은 개방된 공간에서 개발하고, 매일 15분 정도 회의한다.

 

스크럼의 기본원리

• 스트린트 단위로 기능 협업을 기준으로 배치된 팀을 이룸.
• 스프린트는 고정된 30일의 반복이며, 행하는 작업은 고정됨.
• 정해진 시간을 철저히 고수해야함
• 완료된 모든 작업은 Product Backlog 에 기록

 

스크럼 팀의 역할

제품 책임자 (Product Owner)

• 개발 목표에 이해도가 높은 개발의뢰자, 사용자가 담담
• 제품 요구사항을 파악하여 기능목록(Product Backlog)을 작성
• 제품 테스트 수행 및 요구사항 우선순위 갱신 및 추가
• 스프린트 계획 수립까지만 수행
• 스프린트가 시작되면 팀 운영에 관여하지 않음

 

스크럼 마스터

• 업무 배분만 하고 일을 강요하지 않음
• 팀을 스스로 조직하고 관리하도록 지원
• 개발 과정의 장애 요소를 찾아 제거

 

스크럼 팀

• 팀원은 5~9명 내외로 구성
• 개발자, 디자이너, 제품 검사자 등 모든 팀원이 해당
• 요구사항을 사용자 스토리로 도출하고 구현
• 기능을 작업 단위로 나눔

 

스크럼 작업흐름도

 

Product Backlog > Sprint Planning Meeting > Sprint (+ Daily Scrum Meeting)
> Finished Work > Sprint 리뷰 > Sprint 회고

 

1. Product Backlog

• 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록
• 개발 과정에서 새롭게 도출되는 요구사항으로 인한 지속적 업데이트
• 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획을 수립

 

2. Sprint Planning Meeting

• Product Backlog(제품 기능 목록)에서 진행할 항목을 선택
• 선택한 스프린트에 대한 단기 일정을 수립, 요구사항을 개발자들이 나누어 작업할 수 있도록 Task 단위로 나움
• 수행에 필요한 각종 요구사항을 스크럼 마스터에게 보고하여 이해관계자로부터 지원을 받는다

 

3. Sprint

• 작은 단위의 개발 업무를 단기간에 전력으로 개발
• 반복주기(2~4주) 마다 이해관계자에게 일의 진척도 보고

 

4. Daily SCRUM Meeting

• 매일 짧은 시간동안 서서 진행상황을 점검한다.
• Burn Down Chart : 스크럼 마스터가 방해요소를 찾아 해결하고 잔여 작업시간을 기록하는 문서

 

5. Finished Work

 

6. Sprint Review

• 스프린트 검토회의에 개발자와 사용자가 같이 참석한다
• 하나의 스프린트 반복주기가 끝나면 실행 가능한 제품이 생성되며 이에 대해 검토한다.
• 개선해야 할 사항에 대하여 제품 책임자는 피드백을 정리하여 Product Backlog를 작성하여 다음 스프린트에 적용한다.

 

7. Sprint Retrospective

• 스프린트에서 수행한 활동과 결과물을 살펴본다.
• 개선점 문제점을 기록한다.