생명주기
생명주기
소프트웨어 생명주기 (Software Life Cycle)
: 소프트웨어 제품의 개념 형성에서 시작하여 운용/유지보수에 이르기까지 변화의 모든 과정
- 일반적인 소프트웨어의 생명 주기는 다음과 같으며, 생명주기 모형 별로 대동소이하다
타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수
소프트웨어 생명주기의 역할
- 프로젝트의 비용 산정과 개발 계획을 수립할 수 있는 기본 골격이 된다
- 용어의 표준화를 가능하게 한다
- 문서화가 충실한 프로젝트 관리를 가능하게 한다
- 소프트웨어 생명주기의 단계(공정)
타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트
생명주기 모형의 종류
폭포수 모형 (Waterfall Model)
- Boehm이 제시한 고전적 생명주기 모형 (선형 순차적 모델)
- 타당성 검사 : 개발 타당성 검사
- 계획 : 추진 방안 제시하고 개발 비용, 소요 기간, 인력 등 개발 계획 수립
- 요구분석 : 시스템의 기능, 성능, 환경 등의 요구사항을 면밀히 분석
- 설계
3-1. 기본 설계 : 하드웨어, 소프트웨어, 제어 구조, 자료 구조 등의 설계를 작성
3-2. 상세 설계 : 각 단위 프로그램의 제어, 자료 구조, 인터페이스 등을 상세히 작성 - 구현 : 설계된 문서를 통해 Executable한 코드 생성
- 테스트 : 구현한 프로그램을 테스트하여 요구조건에 맞는지 확인
- 운용: 실제 시스템에 적용하여 실행 확인
- 유지보수 : 개발 후 발생하는 문제점이나 수정사항 적용. 일반적으로 가장 많은 비용 소요
폭포수 모형의 장점
- 적용 경험과 성공 사례가 많다 (가장 오래됨)
- 단계별 정의가 분명하고, 전체 구조의 이해가 용이하다
- 단계별 산출물이 명확하다
폭포수 모형의 단점
- 개발 과정 중 발생하는 새로운 요구나 경험을 설계에 반영하기 어렵다.
( 이전 단계로 돌아가기 어렵기 때문. 선형적 동작이기 때문에 만약 돌아간다면 현 단계의 작업사항이 대부분 폐기된다) - 두 개 이상의 과정이 병행수행되거나 이전 단계로 넘어갈 수 없다.
- 이전 단계의 오류 수행이 어렵다
프로토타입 모형 (Prototype Model)
- 실제 개발될 시스템의 견본(Prototype)을 미리 만들어 최종 결과물을 예측하는 모형이다
- 개발이 완료 후 실사용 시점에서야 문제점을 알 수 있는 Waterfall 모형의 단점을 보완하기 위한 모형이다
프로토타입 모형의 장점
- 프로토타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공한다
- 프로토타입은 구현 단계의 골격이 될 수 있다
- 최종 결과물이 만들어지기 전에 의뢰자가 결과물의 일부 또는 모형을 볼 수 있다
- 요구사항이 충실히 반영된다
프로토타입 모형의 단점
- 프로토타입과 실제 소프트웨어와의 차이로 인해 사용자의 혼란이 야기될 수 있다.
- 프로토타입 폐기로 비경제적일 수 있다
나선형 모형 (Spiral Model)
- Boehm이 제시한, 반복적인 작업을 수행하는 점증적 생명주기 모형 ( 점증적 모형, 집중적 모형 )
- 소프트웨어 개발 중 발생할 수 있는 위험을 관리하고 최소화하는 것이 목적
- 나선을 따라서 돌아가면서 각 개발 순서를 반복하여 수행하는 점진적 방식으로, 누락된 요구사항을 추가할 수 있으며, 유지보수 과정이 별도로 필요하지 않은 것이 특징
나선형 모형의 개발 단계
- 계획 및 정의 (Planning) : 기능, 제약 등의 세부적 계획 단계
- 위험 분석 (Risk Analysis) : 위험 요소 분석 및 해결 방안 설정 단계
- 공학적 개발 (Engineering) : 기능 개발 및 검증 단계
- 고객 평가 (Customer Evaluation) : 결과물 평가 및 추후 단계 진행 여부를 결정
나선형 모형의 장점
- 위험 분석 단계에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로써 완성도 높은 소프트웨어 개발이 가능
- 비용이나 시간이 많이 소요되는 대규모 프로젝트나 큰 시스템 구축 시 유리 (반복 수행하며 Divide & Conqure 가능)
나선형 모형의 단점
- 위험 분석 단계에서 발견하지 못한 위험 요소로 인해 문제 발생 가능성
- 적용 경험이나 성공 사례가 많지 않음
애자일 방법론
애자일(Agile) 방법론이란?
Agile 방법의 개념
- 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있으며, 절차/도구보다는 개인과 소통, 고객과의 피드백에 포커싱한 방법론
- 특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위한 고객과의 협업에 초점을 준다
- 소프트웨어가 잘 실행되는지, 또 소프트웨어가 얼마나 빠르게 배포되는지에 대해 중점을 둔다
특징
- 짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적 커뮤니케이션, 변화
종류
- XP, SCRUM, LEAN, DSDM, FDD, Crystal 등
애자일 선언문
- 프로세스나 도구보다 개인과의 소통이 더 중요하다
- 완벽한 문서보다 실행되는 소프트웨어가 더 중요하다
- 계약 협상보다 고객과의 협업이 더 중요하다
- 계획을 따르는 것보다 변경에 대한 응답이 더 중요하다
XP(eXtremeProgramming)
1999년 Kent Beck이 제안한 방법론으로, 개발 단계 중 요구사항 변동이 심한 경우 적합
목표 및 특징
- 요구에 맞는 양질의 소프트웨어를 신속하게 제공하는 것이 목표
- 요구사항을 모두 정의해 놓고 작업을 진행하는 것이 아니라, 요구사항이 변경되는 것을 적용하는 방식으로 예측성보다는 적응성에 더 높은 가치를 부여
- 고객의 참여와 개발 과정의 반복을 극대화하여 생산성 향상
XP의 5가지 핵심가치
- 소통(Communication) : 개발자, 관리자, 고객 간의 원활한 소통 지향
- 단순성(Simplicity) : 부가적 기능 또는 미사용 구조와 알고리즘은 배제한다
- 피드백(Feedback) : 개발 과정 중 발생하는 변화는 지속적 테스트/통합, 반복적 결함 수정 등을 통해 빠르게 피드백
- 용기(Courage) : 고객 요구사항 변화에 능동적으로 대응
- 존중(Respect) : 개발 팀원간 상호 존중을 기본으로 함
XP 프로세스
(도식에서 스파이크와 릴리즈 계획 사이의 화살표 방향이 잘못되어 있음. 추후 수정 예정)
유저 스토리(User Story)
- 사용자의 요구사항을 간한 시나리오로 표현한 것
- UML UseCase와 같은 목적으로 생성되나 형식이 없고, 고객에 의해 작성됨
릴리즈 계획(Release Planning)
- 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공
- 부분/전체 개발 완료 시점에 대한 일정 수립
- 스파이크(Spike) : 어려운 요구사항, 잠재적 솔류션을 핸들링하기 위해 작성하는 간단한 프로그램
주기(Iteration)
- 하나의 릴리즈를 세분화한 단위로, 1~3week/unit으로 진행됨
- 주기 진행 중 새로운 스토리가 추가될 경우, 진행 중인 주기나 다음 주기에 추가 가능
승인 테스트(Acceptance Test)
- 릴리즈 단위의 개발이 구현되었을 때 진행하는 테스트
- 사용자 스토리에 작성된 요구사항을 확인하여 고객이 직접 테스트함
- 오류가 발견되면 다음 주기에 추가
- 테스트 후 고객의 요구사항이 변경되거나 추가되면 중요도에 따라 우선순위가 변경될 수 있음
- 완료 후 다음 주기 진행
작은 릴리즈(Small Release)
- 릴리즈 단위를 기능별로 세분화하여 작게 릴리즈함으로서 고객의 반응을 기능별로 확인 가능
- 최종 완제품일 때 고객에 의한 최종 테스트 진행 후 고객에게 제공
XP의 12가지 실천사항
Fine scale feedback
- Pair programming : 한 코드에 2명의 프로그래머가 코딩/리뷰 역할을 교대해가며 페어 프로그래밍 진행
- Planning Game : 게임처럼 선수와 규칙, 목표를 두고 기획에 임함
- TDD : 코드 작성 전 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드 작성
- Whole Team : 개발 효율을 위해 고객을 프로젝트 팀원으로 상주
Continuous process
- Continuous Integration : 상시 빌드/배포 가능한 상태로 유지
- Design Improvement : 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성 수행
- Small Releases : 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 의도
Shared understanding
- Coding Standards : 소스코드 작성 포맷 및 규칙을 표준화된 관례에 따라 작성
- Collective Code Ownership : 시스템에 있는 소스코드는 팀의 모든 프로그래머가 언제라도 수정 가능하게 유지
- Simple Design : 가능한 가장 간결한 디자인 상태 유지
- System Metaphor : 최종적으로 개발되어야 할 시스템의 구조 기술
Programmer welfare
- Sustainable Pace : 40hrs/week 이상 작업 금지, 2주 연속 오버타임 금지
SCRUM
반복적이고 점진적인 소규모 팀(Scrum) 중심의 소프트웨어 개발 방법론
스크럼이란?
개념
- 소규모 팀 중심이므로 팀원 간 활발한 소통과 협동심이 필요하다
- 요구사항 변경에 신속히 대처할 수 있다.
- 신속하게 반복적으로 실제 작동하는 소프트웨어를 제공한다
- 개발자들의 팀 구성과 각 구성원의 역할, 일정 결과물 및 그 외 규칙을 정한다
- 팀원 스스로 팀을 구성해야 한다(Self Organizing)
- 개발 작업에 관한 모든 것을 팀원 스스로 해결해야 한다(Cross Functional)
특징
- 기능 개선점에 우선순위를 부여하고, 개발 주기 동안 실제 동작 가능한 결과를 제공
- 개발 주기마다 적용된 기능이나 개선점의 리스트를 제공
- 커뮤니케이션을 위하여 팀은 개방된 공간에서 개발하고, 매일 15분정도 회의 진행
기본 원리
- 기능 협업을 기준으로 배치된 팀은 스프린트 단위로 소프트웨어를 개발함
- 스프린트는 고정된 30일의 반복이며, 스프린트 시 행하는 작업은 고정된다
- 요구사항, 아키텍쳐, 설계가 프로젝트 전반에 걸쳐 잘 드러나야 한다.
- 정해진 시간을 철저히 지켜야 한다
- 완료된 모든 작업은 제품 백로그에 기록된다
- 가장 기본적인 정보 교환 수단은 일일 스탠드업 미팅 또는 일일 스크럼이다
스크럼 팀의 역할
제품 책임자(Product Owner)
- 개발 목표에 이해도가 높은 개발의뢰자 및 사용자가 담당
- 제품 요구사항을 파악하여 기능 목록(Product Backlog)을 작성
- 제품 테스트 수행 및 요구사항 우선순위를 갱신
- 업무 관점에서 우선순위와 중요도를 표시하고 신규 항목을 추가
- 스프린트 계획 수립까지만 임무를 수행하며, 스프린트가 시작되면 팀 운영에 관여하지 않음
스크럼 마스터(Scrum Master)
- 업무를 배분만 하고 일은 강요하지 않음
- 팀을 스스로 조직하고 관리하도록 지원
- 개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원
- 개발 과정의 장애 요소를 찾아 제거
스크럼 팀(Scrum Team)
- 제품 책임자, 스크럼 마스터를 제외한 모든 팀원(개발자, 디자이너, QA 등)을 지칭하며, 한 팀은 5~9명 내외로 구성
- 요구사항을 사용자 스토리로 도출하고 구현
- 기능을 작업 단위로 분할
- 일정, 속도를 추정한 뒤 P.O에게 전달하고, 스프린트 결과물을 P.O에게 시연
- 매일 스크럼 회의에 참여하여 진행 상황을 점검함
SCRUM Workflow
Product Backlog
- 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록이다.
- 개발 과정에서 새롭게 도출되는 요구사항으로 인해 지속해서 업데이트된다.
- 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획을 수립한다.
Sprint
- 작은 단위의 개발 업무를 단기간에 전력 질주하여 개발한다
- 반복 주기(2~4주)마다 이해관계자에게 일의 진척도를 보고한다
Spring Planning Metting
- Product Backlog(제품 기능 목록)에서 진행할 항목을 선택한다
- 선택한 Sprint에 대한 단기 일정을 수립하고, 요구사항을 개발자들이 나눠 작업할 수 있도록 Task단위로 나눈다
- 개발자별로 Sprint Backlog를 작성하고 결과물에 대한 반복 완료 시 모습을 결정한다
- 수행에 필요한 각종 요구사항을 SCRUM Master에게 보고하여 이해관계자로부터 지원을 받는다
Daily SCRUM Meeting
- 매일 약속된 시간에 짧은 시간 동안(약 15분) 서서 진행 상황만 전담한다
- 스프린트 작업 목록을 잘 개발하고 있는지 확인한다
- 한 사람씩 어제 한 일과 오늘 할 일을 이야기한다
- 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판에 갱신한다
- 스크럼 마스터는 방해요소를 찾아 해결하고 잔여 작업시간을 소멸 차트(Burndown Chart)에 기록한다
Finished Work
- 모든 스프린트 주기가 완료되면 제품 기능 목록(Product Backlog)의 개발 목표물이 완성된다
Sprint Review
- 스프린트 검토 회의(Sprint Review)에 개발자와 사용자가 같이 참석한다
- 하나의 스프린트 반복 주기(2~4주)가 끝나면 실행 가능한 제품이 생성되며, 이에 대해 검토한다. 검토는 가능한 4시간 안에 마무리한다.
- 개선해야 할 사항에 대하여 제품 책임자(P.O)는 피드백을 정리하여 제품 기능 목록(Product Backlog)을 작성하여 다음 스프린트에 적용한다
Sprint Retrospective
- 그동안 스프린트에서 수행한 활동과 결과물을 살펴본다
- 개선점이 없는지 살펴보고 문제점을 기록하는 정도로 진행한다
- 정해진 규칙이나 표준을 잘 수행했는지 확인한다
- 팀의 단점을 찾기보다는 강점을 찾아 팀의 능력을 극대화한다
- 개발 추정속도와 실제 작업속도를 비교하고 차이가 있다면 이유를 분석한다
POST : Power-On Study Thoroughly