1. 요구사항 확인 [소프트웨어 생명주기]

소프트웨어 생명 주기

 

소프트웨어 생명 주기 [Life Cycle]

• 소프트웨어 개발 방법론의 바탕이 되어 소프트웨어를 개발하기 위해 정의하고 운용 유지보수 등의 과정을 각 단계별로 나눈것
• 소프트웨어 개발 단계와 각 단계별 주요 활동 및 활동의 결과를 산출물로 표현
• 소프트웨어 생명 주기를 표현하는 형태 : 소프트웨어 생명 주기 모형, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임
• 특정 모형을 선택하여 사용하거나 개별적인 모형을 사용할 수 있음

 

폭포수 모델 [Waterfall]

• 폭포수가 거슬러 올라갈 수 없듯 이전 단계를 확실히 마무리하고 다음 단계로 진행하는 개발 방법론
• 소프트웨어 공학에서 가장 도래되고 폭넓게 사용된 생명 주기 모형
• 한 단계가 끝나야 다음 단계로 넘어갈 수 있는 선형 순차적 모형
• 매뉴얼을 작성해야 함
• 단계를 끝내고 다음 단계로 가기 위해서는 결과물이 명확하게 나와야 함

▶▶ 폭포수 모형 진행과정 ▶▶
타당성 검토	계획	요구분석	설계	구현	시험	유지보수

 

프로토타입 모델

• 요구사항을 정확하게 파악하기 위해 실제 개발예정인 소프트웨어의 시제품을 만들어 최종 결과물을 예측하는 모형
• 폭포수 모델의 단점을 보완하기 위해 만들어진 모형
• 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발

▶▶ 프로토타입 모형 진행 과정 ▶▶
요구사항 수집	빠른 설계	프로토타입 구축	고객 평가	프로토타입 조정	구현
◀◀ 구현 이후, 고객의 피드백을 받은 다음 다시 1번 단계인 요구사항 수집단계로 돌아간다 ◀◀

 

나선형 모델

• 폭포수 모형과 프로토타입 모형의 장점 + 위험 분석 기능을 추가한 모형
• 나선을 따라 돌듯이 여러번의 개발 과정을 거쳐 점진적으로 최종 소프트웨어를 개발
• 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것이 목적
• 누락되거나 추가된 요구사항을 첨가할 수 있음
• 정밀한 모델이며 유지보수 과정이 필요 없음

출처 : https://en.wikipedia.org/wiki/Spiral_model

▶▶ 나선형 모델 ▶▶
계획 및 정의	위험 분석	공학적 개발	고객 평가
◀◀ 고객 평가를 바탕으로 다시 1번 단계인 계획 및 정의 단계로 돌아간다 ◀◀

 

애자일 모델

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 진행하는 모형
• 좋은 것을 빠르고 낭비없게 만들기 위해서 고객과의 소통에 초점을 맞춘 모든 방법론을 통칭
• 스프린트 또는 이터레이션이라고 부르는 짧은 개발 주기를 반복함
• 반복되는 주기마다 결과물에 대한 평가와 요구사항 수용
• 애자일 모형을 기반으로 하는 모델 : 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM 등

 

애자일 모델 기법 설명 1 - 스크럼
스크럼 개요	- 팀이 중심이 되어 개발 효율성을 높임 - 팀원 스스로 팀을 구성하고 개발에 대한 모든것을 스스로 해결할 수 있어야 함

스크럼 구성요소

제품 책임자	- 개발될 제품에 대한 이해도가 높고 요구사항을 책임짐 (의사결정자) - 개발의뢰자나 사용자가 담당함 - 이해관계자들의 의견을 종합하여 제품에 대한 요구사항 작성 - 백로그 작성 - 팀원들이 백로그에 스토리를 추가하면 제품 책임자는 우선순위를 지정함 - 테스트를 수행하면서 주기적으로 요구사항의 우선순위 갱신
스크럼 마스터	- 팀이 잘 수행할 수 있도록 객관적인 시각에서 조언함 (가이드 역할) - 일일 스크럼 회의 주관 (진행사항 점검, 개발시 장애요소 공론화 및 처리)
개발팀	- 제품 개발에 참여하는 모든 인원 (개발자, 디자이너, 테스터 등) - 보통 최대인원은 7~8명이 적당함

스크럼 개발 프로세스

출처 : https://tech.gsa.gov/guides/popular_approaches/

제품 백로그 (Product Backlog)	- 개발에 필요한 요구사항을 우선순위에 따라 나열한 목록 - 새롭게 도출되는 요구사항에 따라 지속적인 업데이트 - 작성된 사용자 스토리를 기반으로 릴리즈 계획 수립
스프린트 계획 회의 (Sprint Planning Meeting)	- 스프린트에서 수행할 작업을 대상으로 단기 일정 수입 - 요구사항을 '태스크'라는 작업단위로 나누어 개발자들이 작업할 수 있도록   구분한 다음, 스프린트 백로그 작성
스프린트 (Sprint)	- 실제 개발 작업 수행 과정 - 태스크의 작업 시간/업무량을 산정한 후 개발 담당자에게 할당 - 개발자가 원하는 태스크를 직접 고를 수 있도록 하는 것이 좋음 - 할당된 태스크의 상태값 :  할일, 진행중, 완료
일일 스크럼 회의 (Daily Scrum Meeting)	- 모든 팀원이 매일 약속된 시간에 진행상황 점검 (짧은 회의시간) - 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와줌 - 남은 작업 시간은 소멸 차트에 표시
스프린트 검토 회의 (Sprint Review)	- 부분 or 완성된 제품이 요구사항에 부합하는지 확인하는 절차 - 사용자가 포함된 상태로 테스트 수행
스프린트 회고 (Srpint Retrospective)	- 스프린트가 완료된 후 리뷰/점검하는 절차 - 정해놓은 규칙을 잘 준수했는지, 개선사항은 없는지 등 점검

 

애자일 모델 기법 설명 2 - XP
XP 개요 (eXtrem Programming)	- 목적1 : 수시로 발생하는 고객 요구사항에 유연하게 대응 - 목적2 : 고객 참여와 개발 과정 반복을 극대화 > 개발 생산성 향상 - 릴리즈 기간을 짧게 반복하면서 요구사항 반영에 대한 가시성이 높음 - XP의 5가지 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백

XP 개발 프로세스

사용자 스토리 (User Story)	- 고객 요구사항을 간단한 시나리오로 표현
배포 계획 수립 (Realsase Planning)	- 여러 스토리가 개발되어 부분적으로 기능이 완료된 제품을 배포하는 것에 대한 계획 수립
스파이크 (Spike)	- 요구사항의 신뢰성을 높이고 기술문제의 위험을 감소시키기 위해 별도로 만드는 프로그램
이터레이션 (Iteration)	- 하나의 배포를 세분화한 단위
승인검사 (Acceptance Tests)	- 하나의 이터레이션 안에서 계획된 배포 단위의 개발이 완료되면 수행하는 테스트 (배포 전 검사) - 사용자 스토리 작성시 함께 기재한 테스트 사항에 대해서 고객이 직접 수행
소규모 배포 (Small Release)	- 테스트에 대한 고객의 반응을 기능별로 확인하고 고객 요구사항에 유연하게 대응 - 진행된 이터레이션이 모두 완료되면, 고객의 최종 테스트 수행 후 최종결과물을 고객에게 전달

 

XP의 주요 실천 방법

• Pair Programming : 다른사람과 함께 프로그래밍 수행
• Test-Driven Development : 실제 코드 작성 전 테스트케이스를 먼저 작성하여 무엇을 해야할지 파악
• Whole Team : 개발에 참여하는 모든 구성원은 각기 역할에 책임을 다해야 함
• Continuous Intergration : 모듈 단위로 나누어 개발한 코드는 하나의 작업이 마무리되면 지속적으로 통합
• Design Improvement / Refactoring : 프로그램 기능의 변경없이 시스템 재구성
• Small Release : 배포 기간을 짧게하여 고객 요구사항 변화에 신속하게 대응