소프트웨어 개발 프로세스 Ⅱ

KMooc에 공개 되어 있는 '쉽게 배우는 소프트웨어 공학' 강의 내용을 정리한 것입니다.(강의: 공주대학교 컴퓨터공학부 김치수 교수)

또한, https://terms.naver.com/list.nhn?cid=58528&categoryId=58528를 확인하시면, '쉽게 배우는 소프트웨어 공학' 책 또한 공개되어있으니 참고하여주시면 감사하겠습니다.

10.agile process model

agile process model

1.정의

• 고객의 요구에 민첩하게 대응하고, 그때 그때 주어지는 문제를 풀어나가는 방법론

  • agile : 날렵한, 민첩한

• 가볍고 비교적 변화를 수용하기 쉬운 방법론

  • XP(eXtreme Programming) 방법
  • scrum 방법론
  • crystal 방법론

process 중심 모델 : 예> waterfall model

• 산출물 위주의 거대하고 무거운 방법론
• 단점 : 요구사항 변화에 대한 유연한 대처의 어려움

• agile 의미 : 가벼운 프로세스 방법론의 공텅적인 특성을 정의하는 말

• Agile alliance에서 서로 공통점을 찾아 선언문 발표

• agile 선언문의 기본가치

  • 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시
  • 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시
  • 계약과 협상 중심이 아닌, 고객과의 협력을 중시
  • 계획 중심이 아닌, 변화에 대한 민첩하게 대응을 중시

waterfall model	agile model
계획, 프로세스에 중점	고객과의 협업 강조
프로젝트 관리에 중점	빠른시간안에 작동하는 SW 강조
문서 (산출물)에 중점	환경/고객 변하에 능동적 대처 강조

2.agile의 원칙

원칙	설명
최우선 목표	고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것
추가 요구 사항	개발 후반에 새로 추가되는 요구 사항도 기꺼이 받아들임.
	agile process는 고객의 경쟁력을 위해 요구 사항의 변경을 받아들임
동작 가능 SW 주기	동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 자주 고객에게 전달
	간격은 짧을수록 좋음
업무 담당자와 개발자의 잦은 의사소통	프로젝트가 진행되는 동안, 매일 서로 의견을 주고받으며 함께 참여
면대면 대화 강조	정보 전달을 위한 많은 매체 수단(전화, 팩스, 인터넷 등)보다 가장 효과적인 의사소통 방법은 역시 직접 만나 얼굴을 보면서 대화하는 것
진척상황은 실행 가능 SW로	진척 사항의 척도를 나타내는 방법은 여러 도구로 표현할 수 있으나, 가장 좋은 방법은 실행 가능한 소프트웨어를 보여주는것
자유로운 팀의 분위기	자율적 사고와 자유로운 분위기의 프로젝트 팀에서 최고의 아키텍처, 요구사항, 설계가 나옴
정기적 미팅	프로젝트의 효율성을 향상시키기 위해 개발팀 스스로 정기적인 미팅을 진행하여 자신들의 행동을 되돌아 보고 조율 및 수정

3.agile 개발 방법

• 반복적인 개발을 통한 잦은 출시를 목표로 함
• 실행 가능한 prototype을 만들어 사용자에게 확인 받고, 좀더 빠른 시간에 일부이지만 SW를 사용할 수 있게 하는것을 중요하게 생각
  • 개발자 : 1차 분석 후 개발 (단순기능: 문서작성, 단순편집, 저장, 불러오기 등)
  • 사용자 : 1차 개발된 기능 사용
  • 개발자 : 2차 개발(복잡헌 편집 등 기능 추가)

4.agile 방법론과 폭포수 모델의 비교

• 추가 요구 사항의 수용

agile model	waterfall model
처음 수집한 요구 사항을 전체 요구사항 중 일부로 인정하고 시작	요구사항분석이 완전히 완료된 후 설계 단계로 넘어감
언제든지 추가 요구 사항이 있을 것으로 간주	새로운 요구사항을 추가하기 쉽지 않음
추가 요구 사항을 수용할 수 있는 방법으로 설계	추가요구 사항을 반영하기 어려운 구조

• release 시점

agile model	waterfall model
가능하면 자주, 빨리 제품에 대한 프로토타입을 만들어 사용자에게 보여줌	요구사항에 대한 분석, 설계, 구현 과정이 끝나고 최종 완성된 제품을 release 함
이러한 방식을 반복적으로 수행하여 최종 제품을 만들기 때문에 자주 release 됨

• 시작 상태

agile model	waterfall model
계속적인 추가 요구사항을 전제로 하는 방식	한번 결정된 단계는 그 이후에 변동이 적어야 함
시작단계에서는 부족한 점이 많지만 점차 완성도가 높아짐	단계별 완성도를 최대한 높여야함
	그 다음 단계가 지금 완료한 단계의 시작이기 때문

• 고객과의 의사소통

agile model	waterfall model
사용자와 함께 일한다는 개념을 담고 있음	사용자의 요구사항을 정의한 후 더 이상 추가 요구가 없다는 확답을 받고 개발 시작
처음부터 사용자의 참여를 유도하고 많은 대화를 하면서 개발을 진행	확답받은 산출물을 근거로 개발하기 때문에 빈번한 대화를 하지 않음

• 진행 상황 점검

agile model	waterfall model
개발자와 사용자는 개발 초기부터 지속적으로 진행 상황을 공유	단계별 산출물을 중요시 함
함께 관심을 갖고 진행	단계별 산출물에 대한 결과로 개발의 진척 상황을 점검

• 분석 / 설계 / 구현 진행 과정

agile model	waterfall model
하나의 단계(도는 반복)안에 분석 / 설계/ 구현 과정이 모두 포함되어 동시에 진행	단꼐별 생산되는 산출물 중심의 개발 방식이기 때문에 분석/설계/구현 과정이 명확
다만 분석이 구현보다 많은 단계와 그 반대인 경우의 차이만 있을 뿐	분석 끝난 후 설계를, 설계 끝난 후 구현 작업을 진행

• 모듈(컴포넌트) 통합

agile model	waterfall model
개발 초기부터 빈번한 통합을 통해 문제점을 빠리 발견하고 수정하는 방식을 택함	프로세스 모델에서 설명한 것처럼 구현이 완료된 후에 모듈간의 통합 작업을 수행
문제점을 빨리 발견하여 비용을 많이 절감할 수 있음

5.agile 개발 방법론의 종류

• Scrum
• XP: eXtreme Programming
• 적응형 소프트웨어 개발 방법론
• 린 소프트웨어 개발 방법론
• Crystal family
• 기능 주도 개발 방법론(FDD: Feature Driven Development)
• 동적 시스템 개발 방법론(DSDM: Dynamic Systems Development Method)
• 애자일 UP(AUP: Agile Unified Process)

Scrum

• 럭비 경기에서 사용되던 용어

  • 스크럼에서 팀이라고 하는 단어가 주는 의미
  • 개발 팀에 적용
  • 효율적인 성과를 얻기 위해

• scrum development process

  • SW 개발 기술에 중점을 두지 않고, 팀 (조직)의 개선과 프로젝트 관리에 중점을 둔 agile 방법론
  • 경험적 관리 기법 중 하나
  • 구체적인 process를 명확하게 제시하지 않음
  • 개발팀(조직)을 운형하는 효율적인 운영 방식(지침)

1.Scrum 방식의 진행 과정

• ① 제품 기능 목록 작성
• ② 스프린트 계획 회의 -> 스프린트 구현 목록 작성
• ③ 스프린트 수행 (1~4주)
  • 스크럼 마스터 필요
  • 일일 스크럼 회의
  • 소멸 차트
• ④ 스프린트 개발 완료 : 최종 제품
• ⑤ 스프린트 완료 후 스프린트 검토 회의 및 스프린트 회고

2.제품 기능 목록(product backlog)작성

product backlog: 우선순위가 매겨진 사용자의 요구사항 목록

• 일반적인 개발 방법의 요구사항에서 기능 목록에 해당
• 사용자가 요구하는 제품의 기능목록을 말함
• 제품에 관한 요구 사항에 대해 우선순위가 정해짐
• 우선 순위 결정자: 제품 책임자(고객 측 대표인)

product backlog 특징

• 사용자와 계속 미팅하면서 목록 완성
• 한번 결정된 제품 기능 목록은 확정된 것이 아니고 개발중에도 수정 가능
• 그러나, 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않음

product backlog의 예

• 원고를 써 내려갈 때 사용자가 결정된 소프트웨어 공학의 원고 목록
• 반드시 1장 2장 ... 10장의 순서는 아님

순위	요구사항목록	요구사항내역	작업소요기간	작업 월
1	품질(9장)	프로세스 품질과 제품 품질에 대해 기술	30일	2017.12.
2	테스트(8장)	테스트의 종류를 분류하고 단계별로 설명	40일	2018.01.
...	...	...	...	...
10	소프트웨어 공학 소개(1장)	소프트웨어 공학의 일반적인 내용 기술	10일	~

3.사용자 스토리(user story) 작성

• 메모지 한 장에 쓰인 사용자 요구 사항
• 구현할 기능이 사용자 관점에서 사용자의 언어로 작성
• 우선순위가 결정되어야 함
• user story의 업무량 파악 -> 수행하는데 걸리는 개발 기간 산정 필요
• 제품 기능 목록에 정의된 사용자 관점에서의 기능
• 사용자에게 가치를 평가 받을 수 있도록 기능을 표현
• 보통 작은 인덱스 카드(post it)를 사용해 필요한 것만 짧게 표현
• 고객의 요구사항을 문서화한 것이라기 보다는 표현했닥 보는 것이 적합
• usecase보다 작은 규모
• user story는 반복을 마치면 사라지지만 usecase는 개발 기간 동안 지속
• 사용자와 충분히 대화하여 세부사항을 구체적 서술
• test를 통해 story가 완료된것을 확인
• 다른 story에 종속되지 않고 독립ㅂ적이며, 협상 가능해야함
• 추정 및 측정 가능해야함
• 사용자 스토리는 story가 큰것 보다는 개수가 많은 것이 좋음
• test가 가능해야 좋은 user story

4.story point 산정

• user story를 수행하는데 걸리는 상대적인 개발 시간
• 산정 역할 : 개발자
• 중요도 판단 역할: 업무분석가

5.sprint

정의

• 작업량으롭 볼 때 그렇게 많지 않고, 개발기간도 짧음
• 작은단위의 개발 업무를 단기간 내에 전력질주(sprint)하여 개발한다는 뜻
• 보통 2~4주

예

• 계획 : 소트웨어공학 원고 작성, 총기간(1년), (10일 ~ 40일)/ 1장
  • sprint = 반복주기 = 10~40일

sprint(반복주기) 기간

• sprint회의에서 결정
• 보통 2~4주 정도
  • 2주 : 요구사항이 안정적이고 개발팀이 agile 방법에 대해 지식과 경험이 풍부한 경우
  • 4주 : 요구사항의 피드백이 많고 개발 팀의 역량이 낮은 경우

sprint 주기가 결정되면

• 결정된 sprint의 목표와 내용이 개발 도중에 바귀지 않아야함
• 그 누구도 팀원의 동의 없이 바꿀 수 없는 원칙을 지켜야함
• 개발 팀은 팀원의 역량에 맞게 sprint에 배정된 작업을 중간에 멈추는 일이 없이 전력질주 해서 끝냄

scrum master의 역할

• 외부로부터 오는 개발 방해 요소 차단

sprint 개발 일정 완료 후

• 사용자에게 시연 -> 사용자는 피드백 제공
• 개발 완료가 안되었어도 일정이 끝나면 개발은 끝냄

sprint 구현 목록의 진척 관리

• scrum의 한 주기가 끝나면
  • output: 실행가능한 제품(shippable product)

6.스프린트 구현 목록(sprint backlog)

product backlog

• 사용자가 원하는 우선 순위가 부여된 제품의 기능 목록

sprint backlog

• 각각의 sprint주기에서 개발할 작업 목록
• 세부작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 작성
• sprint 계획 회의에서 결정
• 작업 목록 하나하나가 개발 완료되면 sprint주기 완성

sprint backlog 역할

• sprint를 개발하는데 걸리는 일정 계산 기능
• 필요한 자원확보 가능
• 개발 진척사항 파악 가능

7.소멸차트(burndown chart)

burndown chart

• 시간이 지남에 따라 되고 남은 것을 표현
• 계획 대비 작업이 어떻게 진행되고 있는지를 날짜 별로 남은 작업량으로 표현
• 계획대비 작업량이 실제 얼마나 줄어들고 있는지를 정략적으로 확인 가능
• story point
  • 각 반복 구간별로 남은 작업량

그래프의 기울기를 보면 작업 수행 속도 확인 가능

• 기울기 높음: 빠른 작업 진행
• 기울기 완만: 느린 작업 진행

같은 날짜에서 현재 남은 작업량의 그래프가 계획된 작업량의 그래프보다

• 위에 놓이면: 계획대비 늦게 진행
• 아래에 있으면: 남은 작업량이 적기 때문에 빨리 진행

8.스프린트 계획 회의

스프린트 미팅

• 1.전체적인 sprint 계획 회의
• 2.세부적인 sprint 계획 회의
  • 우선 순위가 높은 항목의 구현 방법에 대한 구체적인 작업 계획을 세움

방법

• 결정된 개발 항목에 대한 sprint 구현 목록 작성
• 정해진 작업 수행 소요 시간 추정

9.일일 스크럼 회의

• 매일, 서서, 짧게 (15분 정도), 약속된 시간에 함
• 진행 상황만 점검, 스프린트 작업 목록을 잘 개발하고 있는지 확인
• 모든 팀원이 참석, 한 사람씩 어제 한 일을 얘기
• 한 사람씩 오늘 할 일과 문제점 및 어려운 점 정도만 얘기
• 매일 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판(task board)을 업데이트
• 개별 티무언에 대한 진척 상태를 확인
• 그날의 남은 작업량을 소멸 차트에 표시

scrum master 역할

• 팀원들이 개발하는데 방해되는 요소를 찾아 문제 해결
• 개발자 개개인이 수행하고 있는 일의 진행 상황 확인
• Burndown chart에 그날의 남은 작업량을 표시

10.스프린트 현황판(task board)

task board

• 개발 팀의 개발 현황(진척도, 남은 작업, 진행속도)을 나타냄

최종제품(finished work)

• 모든 sprint 주기가 끝나면 배포일정에서 개발하려로 했던 제품이 완성

11.sprint 완료 후

스프린트 검토회의(sprint review)

• 하나의 sprint 반복 주기(2~4주)가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토
• sprint 목표를 달설했는지 작업 진행과 결과물을 확인
• 전체 흐름을 확인하여 business 가치를 점검

스프린트 회고

• sprint에서 수행한 활동과 개발한 것을 되돌아 홈
• 개선점은 없는지, 팀이 정한 규칙이하 표준을 잘 준수했는지 등을 검토
• 단점 보다는 장점을 더 극대화하는데 주안점을 둠
• 문제점의 해결 방안이 아닌, 확인하고 기록하는 정도로만 진행
• 추정 속도와 실제 속도를 비교해보고, 차이가 크면 그 이유를 분석
• process 품질은 측정하지 않음

12.배포 목록(release backlog)

배포(release)

• 사용자에게 시스템 일부를 제공하는 것

release backlog

• 제품 기능 목록의 항목 중에서 이번 배포 본에 포함하기로 결정한 항목

release backlog을 작성하면

• 금번 배포 보늬 개발 범위와 일정 수립 가능
• 사용자에게 전달되는 배포 본의 기능 내역과 시기, sprint 주기, 배포일정을 결정

13.scrum 방식 단계별 진행절차

단계	수행목록	내용
1	제품 기능 목록 작성	요구사항 목록에 우선순위를 매겨 제품 기능 목록 작성
2	스프린트 계획 회의	스프린트 구현 목록 작성
		스프린트 개발 시간 추정
3	스프린트 수행	스프린트 개발
		일일 스크럼 회의
		스프린트 현황한 변경
		소멸차트 표시
4	스프린트 개발 완료	실행 가능한 최종 제품 생산
5	스프린트 완료 후	스프린트 검토 회의
		스프린트 회고
		두 번째 스프린트 계획 회의

14.product owner, scrum master, scrum team의 역할

담당자	역할
제품 책임자	제품 기능 목록을 만듦
	비즈니스 관점에서 우선순위와 중요도를 매기고 새로운 항목을 추가함
	스프린트 계획 수립 시까지만 역할을 수행하고, 스프린트가 시작되면 팀 운영에 관여하지 않음
스크럼 마스터	제품 책임자를 돕는 조력자
	업무를 배분만 하고, 일은 강요하지는 않음
	스크럼 팀이 스스로 조직하고 관리하도록 지원함
	개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원함
	개발과정에 방해될 만한 요소를 찾아 제거함
스크럼 팀	팀원은 보통 5~9명으로 구성되며, 사용자 요구 사항을 사용자 스토리를 도출하고 이를 구현
	기능을 작업 단위로 나누고, 일정이나 속도를 추정해서 제품 책임자에게 알려줌
	하나의 스프린트에서 생산된 결과물을 제품 책임자에게 시연함
	매일 스크럼 회의에 참여하여 진척 상황을 점검함

15.scrum 방식의 진행과정

16.scrum 방식의 장점

• 반복 주기 마다 생산되는 실행 가능한 제품을 통해 사용자와의 충분한 의견 조율 가능
• 일일회의를 통한 팀원들 간의 신속한 협조와 조율 가능
• 일일회의 시 직접 자신의 일정 발표를 통한 업무 집중 환경 조성
• 다른 개발 방법론들에 비해 단순하고 실천 지향적
• 팀의 문제를 해결할 수 있는 스크럼 마스터의 능력(역할)
• 프로젝트 진행 현황을 통한 신속하게 목표와 결과 추정가능, 목표에 맞는 변화 시도 가능

17.scrum 방식의 단점

• 추가 작업 시간 필요

  • 반복 주기가 끝날 때 마다 실행 및 테스트 가능 제품을 만들어야 하기 때문

• 일일 스크럼 회의를 15분 안에 마쳐야 함

  • 길어지는 회의 시간으로 인한 작업의 방해

• 투입 공수 불측정에 따른 효율성 평가 불가

  • 투입 공수 불측정으로 인해 얼마나 효율적으로 수행되었는지 모름

• 프로세스 품질 평가 불가

  • 프로세스 품질 미평가로 인한 품질 관련 활동이 미약하고 품질의 정도를 알 수 없음