소프트웨어 개발 방법론 (2)

2. 소프트웨어 개발 수명 주기

 

반응형

 

1) 소프트웨어 개발 수명 주기

정의

- 소프트웨어 개발 과정을 단계별로 구성한 것으로 단계별 산출물이 존재한다.

- 개발 단계를 정의하는 방식

 

폭포수 모델

- 과거에 가장 폭넓게 사용된 방식

- 정해진 단계를 한 번씩만 진행하며 이전 단계로 돌아갈 수 없다.

- 단계별로 결과물이 명확하게 산출되어야 다음 단계로 넘어가는 방식이다.

- 제품의 기능 보완이 불가능하므로 매뉴얼 작성이 필수적이다.

 

폭포수 모델

 

폭포수모델 단점

- 문제를 발견해도 되돌릴 수 없다. 

 

프로토타입 모델

- 폭포수 모델의 단점을 보완한 모델로 시제품을 통해 최종 결과물을 예측할 수 있다.

- 시제품은 추후 최종 구현 단계에서 골격으로 사용된다.

 

 

나선형 모델

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

- 나선을 돌듯이 여러 번의 지속적인 개발 과정을 통해 점진적으로 개발하는 것이다.

- 개발 중 발생할 수 있는 위험을 최소화하는 것이 목적이며 유지보수가 필요없다.

- 누락 및 추가된 요구사항 반영이 가능하다.

 

*반복적인 사이클을 통해 완성도가 점점 올라간다.

 

 

애자일 모델    *중요

- 소프트웨어를 사용할 고객과의 소통에 중심을 둔 방법론들의 통칭이다.

- 짧은 개발 주기를 반복하면서 고객의 피드백을 소프트웨어에 반영한다.

- 고객과의 소통을 통해 작업의 우선순위를 지정하여 개발을 진행한다.

- 애자일 모델을 기반으로 하는 개발 모델은 Scrum, XP 등 이 존재한다. 

- 절차, 문서, 계획보단 소통, 협업, 변화 대응에 가치를 둔다

 

* 고객의 요구사항을 최대한 반영하여 소프트웨어의 품질을 상승키신다.

 

2) 스크럼 모델

특징

- 스크럼 팀을 구성하여 팀을 중심으로 개발의 효율성을 높이는 개발 모델이다.

- 제품 책임자와 스크럼 마스터, 개발팀으로 구성된다.

- 반복적인 스프린트(개발주기)를 통해 제품을 완성시켜 나간다.

스프린트 : 2~4주 정도의 기간 내에서 하나의 task를 개발하는 과정

task : 개발 요구사항(사용자스토리)을 개발자별로 나눈것.

- 스크럼의 가치는 확약, 전념, 정직, 존중, 용기 등이 있다.

 

제품책임자

- 목표 제품에 대한 책임을 지고 의사를 결정하는 역할

- 이해 관계자들의 의견을 종합하여 요구사항을 백로그에 작성하고 우선순위를 조정한다.

이해 관계자 : 소프트웨어에 영향받는 모든사람

제품(전체) 백로그 :  우선 순위에 따라 개발에 필요한 사용자 스토리를 나열한 목록

스프린트 백로그 :  해당 스프린트에서 개발해야 할 테스크를 나열한 목록

사용자 스토리 : 사용자 요구사항을 단어의 나열이 아닌 이야기(시나리오)의 형태로 표현한 것

릴리즈 계획 : 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 개발 일정 수립

- 팀원들은 백로그에 스토리 추가만 가능하고 우선순위 조정은 불가능하다.

 

스크럼 마스터(팀장)

- 개발 팀원들의 원할한 업무를 위한 가이드 역할을 담당한다.

- 일일 스크럼 회의를 주관할 수 있으며 개발 과정에서 발생된 장애 요소를 공론화하여 해결할 수 있도록 처리한다.

- 스크럼 마스터의 역할은 팀원들이 상황에 유연하게 대응할 수 있도록 조력하는 역할이며 통제의 권한은 없다.

 

개발팀

- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원

- 개발팀에는 개발자 뿐만아니라 디자이너 테스터 등도 포함

- 개발팀원들은 능동적으로 팀을 구성하고 문제를 해결할 수 있어야 한다.

 

스크럼 모델 개발 프로세스

 

1차 스프린트를 통해 결과물(산출물)이나오고 2차도 3차도 마찬가지다.

이 전체과정을 릴리즈라고 한다.

 

3) XP모델

특징

- 짧은 개발 과정의 반복을 극대화 한다. 개발생산성을 높이는 개발 모델

- 소규모 인원으로 진행하는 프로젝트에 효과적이며 단계별 단순한 설계를 통해 개발 속도를 향상시킨다.

- XP가치는 의사소통, 단순성, 용기, 존중, 피드백

 

* 스크럼과 XP는 애자일이라는 방법론에서 같이 출발했기 때문에 용어를 기준으로 구분해야한다.

 

 

XP 모델 개발 프로세스

- 사용자 스토리에 기록된 내용을 바탕으로 릴리즈 계획을 수립하고 분석된 스토리에 따라 스파이크 또는 이터레이션을 진행한다.

소규모 릴리즈 : 기능별로 고객의 피드백을 받을 수 있도록 릴리즈의 규모를 작게 분할한다.

스파이크 : 특정 기능 검증만을 위해 개발하는 프로그램

이터레이션 : 하나의 릴리즈를 1~3주 개발 기간으로 세분화 단위

 

- 스파이크를 통해 기술이 검증되면 해당 부분을 이터레이션으로 전달한다.

- 이터레이션 진행 도중 새로운 스토리가 작성될 수 있다.

- 이터레이션을 통해 부분 완성된 제품(소규모 릴리즈)을 고객이 직접 사용자 스토리에 포함된 테스트 사항을 통해 승인 검사를 수행한다.

- 테스트 과정에서 새로운 요구사항, 오류 등이 발견되면 다음 이터레이션에 반영한다.

 

 

 

XP 기본원리 (실천 사항)

항목	설명
Planning Game	게임처럼 선수, 규칙, 목표 등을 설정하여 계획 수립
Small Releases	짧은 주기의 릴리즈로 고객의 피드백을 최대화
System Metaphor	개발 과정에서 최종 목표 시스템의 구조를 조망
Simple Design	가능한 가장 단순한 설계
Test Driven Development	우선 단위 테스트 이후 실제 코드 작성
Design Improvement	기능을 유지하면서 코드 개선 작업 수행
Pair Programming	2명의 개발자가 코딩, 리뷰 공동 수행
Collective Ownership	시스템의 코드는 언제나 개발자 누구나 수정 가능
Continuous Integration	항상 빌드 및 배포가 가능한 상태유지
Sustainable Pace	주당 일정 시간 이상을 일하지 않도록 오버타임 지양
Whole Team	개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킴
Coding Standards	원활한 의사소통 위해 표준화된 관례에 따라 코드 작성

 

 

다음글 참고

https://yonggyu-memo.tistory.com/14

소프트웨어 개발 방법론 (3)