[CS BASIC] 소프트웨어 개발 방법론

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

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

 

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

 

 

폭포수 모형(Waterfall Model)

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

 

나선형 모형(SpiralModel)

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

 

나선형 모형의 개발 단계

① 계획 수립 : 기능, 제약 등의 세부적 계획 단계

② 위험 분석 : 위험 요소 분석 및 해결 방안 설정 단계

③ 개발과 검증 :기능 개발 및 검증 단계

④ 고객 평가 및 다음 단계 수립 : 결과물 평가 및 추후 단계 진행 여부를 결정

 

fig1.0. 나선형 모형의 개발 단계

 

하향식과 상향식 설계

• 하향식 설계 : 소프트웨어 설계 시 제일 상위에 있는 Main User Function에서 시작하여 기능을 하위 기능들로 나눠가면서 설계하는 방식
• 상향식 설계 : 가장 기본적인 컴포넌트를 먼저 설계한 다음 이것을 사용하는 상위 수준의 컴포넌트를 설계하는 방식

 

프로토타입 모형(Prototype Model)

• 실제 개발될 시스템의 견본(Prototype)을 미리 만들어 최종 결과물을 예측하는 모형
• 개발이 완료되고 나서 사용을 하면 문제점을 알 수 있는 폭포수 모형의 단점을 보완하기 위한 모형으로 요구사항을 충실하게 반영할 수 있다.

 

HIPO(Hierachy Input Process Output)

① 입력, 처리, 출력으로 구성되는 시스템 분석 및 설계와 시스템 문서화용 기법이다.

② 일반적으로 가시적 도표(Visual Table of Contents), 총체적 다이어그램(Overview Diagram), 세부적 다이어그램(Detail Diagram)으로 구성.

③ 구조도(가시적 도표, Visual Table of Contents), 개요, 도표(index Diagram), 상세 도표(Detail Diagram)으로 구성.

④ 기능과 자료의 의존 관계를 동시에 표현할 수 있다.

⑤ 보기 쉽고 이해하기 쉬우며 유지보수가 쉬움

⑥ 하향식 소프트웨어 개발을 위한 문서화 도구이다.

 

V-모델

① 폭포수 모형에 시스템 검증과 테스트 작업을 강조한 모델이다.

② 세부적인 프로세스로 구성되어 있어서 신뢰도 높은 시스템 개발에 효과적이다.

③ 개발 단계의 작업을 확인하기 위해 테스트 작업을 수행한다.

④ 생명주기 초반부터 테스트 작업을 지원한다.

⑤ 코드뿐만 아니라 요구사항과 설계 결과도 테스트할 수 있어야 한다.

⑥ 폭포수 모형보다 반복과 재처리 과정이 명확하다.

⑦ 테스트 작업을 단계별로 구분하므로 책임이 명확해진다.

 

fig1.1. V-모델

 

애자일(Agile) 개발 방법론

• 특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위해 고객과의 협업에 초점을 둔 것으로 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있다.
• 절차와 도구보다 개인과 소통을 중요시하고 고객과의 피드백을 중요하게 생각한다.
• 소프트웨어가 잘 실행되는 것에 가치를 두며, 소프트웨어 배포 시차를 최소화할 수 있다.

 

애자일의 특징

① 짧은 릴리즈와 반복

② 점증적 설계

③ 사용자 참여

④ 문서 최소화

⑤ 비공식적인 커뮤니케이션 변화

 

애자일의 개발 방법론의 종류

① 익스트림 프로그래밍(XP, eXtrem Programming),

② 스크럼(SCRUM),

③ 린(Lean),

④ DSDM(동적 시스템 개발 방법론, Dynamic System Development Method),

⑤ FDD(기능 중심 개발, Feature Driven Development),

⑥ Crystal,

⑦ ASD(적응형 소프트웨어 개발 방법론, Adaptive Software Development),

⑧ DAD(학습 애자일 배포, Disciplined Aigle Delivery)

 

익스트림 프로그래밍(XP, eXtrem Programming)이란?

• 익스트림 프로그래밍는 켄트 백 등이 제안한 소프트웨어 개발 방법이다.
• 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다.
• Programming Explained - Embrace Change'에서 발표되었다.
• 사용자의 요구사항은 언제든지 변할 수 있다.
• 고객과 직접 대면하며 요구사항을 이야기하기 위해 사용자 스토리(User Story)를 활용할 수 있다.
• 기존의 방법론에 비해 실용성(Pragmatism)을 강조한 것이라고 볼 수 있다.

https://ko.wikipedia.org/wiki/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

익스트림 프로그래밍 - 위키백과, 우리 모두의 백과사전

 

익스트림 프로그래밍(XP, eXtrem Programming)의 핵심 가치

① 의사소통(Communication) : 개발자, 관리자, 고객 간의 원활한 소통을 지향

② 단순성(Simplicity) : 부가적 기능 또는 미사용 구조와 알고리즘은 배제

③ 피드백(Feedback) : 소프트웨어 개발에서 변화는 불가피함, 이러한 변화는 지속적 테스트와 통합, 반복적 결함 수정 등 빠르게 피드백 해야함.

④ 용기(Courage) : 고객 요구사항 변화에 능동적으로 대응한다.

⑤ 존중(Respect) : 개발 팀원 간의 상호 존중을 기본으로 한다.

 

fig1.2. 익스트림 프로그래밍(XP, Xtrem Programming)

 

익스트림 프로그래밍(XP, eXtrem Programming)의 용어와 설명

① User Story

• 일종의 요구사항으로, UML의 유즈케이스와 같은 목적으로 생성되나 형식이 없고 고객에 의해 작성된다는 점에서 다르다.

 

② Release Planning

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

③ Iteration

• 하나의 릴리즈를 세분화한 단위이며, 1-3주 단위로 진행된다.
• 반복(Iteration) 진행 중 새로운 스토리가 추가될 때 진행중 반복(Iteration)이나 다음 반복에 추가될 수 있다.

④ Acceptance Test

• 릴리즈 단위의 개발이 구현되었을 때 진행하는 테스트, 사용자 스토리에 작성된 요구사항을 확인하고 고객이 직접 테스트한다.
• 오류가 발견되면 다음 반복(Iteration)에 추가한다.
• 테스트 후 고객의 요구사항잉 변경되거나 추가되면 중요도에 따라 우선순위가 변경될 수 있다.
• 완료 후 다음 반복(Iteration)을 진행한다.

⑤ Small Release

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

⑥ Spike

• 어려운 요구사항, 잠재적 솔류션을 고려하기 위해 작성하는 간단한 프로그램이다.

 

익스트림 프로그래밍(XP, eXtrem Programming)의 12가지 실천사항

Fine Scale Feedback

① Pair Programming, 짝 프로그래밍

• 두 사람이 짝이 되어 한 사람은 코딩을 다른 사람은 검사를 수행하는 방식
• 코드에 대한 책임을 공유하고, 비형식적인 검토를 수행할 수 있다.
• 코드 개선을 위한 리팩토링을 장려하며, 생산성이 떨어지지 않음

 

② Plannig Game

• 게임처럼 선수와 규칙, 목표를 두고 기획에 임한다.

 

③ Test Driven Development

• 실제 코드를 작성하기 전에 단위테스트부터 작성 및 수행하며, 이를 기반으로 코드를 작성

 

④ Whole Team

• 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킨다

 

Continuous Process

⑤ Continuous Intergration

• 상시 빌드 및 배포를 할 수 있는 상태로 유지한다.

 

⑥ Design Improvement

• 기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 등을 위한 재구성을 수행한다.

 

⑦ Small Release

• 짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 한다.

 

Shared Understanding

⑧ Coding Standards

• 소스코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성한다.

 

⑨ Collective Code Ownership

• 시스템에 있는 소스 코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정할 수 있다.

 

⑩ Simple Design

• 가능한 가장 간결한 디자인 상태를 유지한다.

 

⑪ System Metaphor

• 최종적으로 개발되어야 할 시스템의 구조를 기술한다.

 

Programmer Wellfare

⑫ Sustainable Pace

• 일주일에 40시간 이상 작업 금지, 2주 연속 오버타임을 금한다.

 

효과적인 프로젝트 관리를 위한 3대 요소

① 사람(People) - 인적 자원

② 문제(Problem) - 문제 인식

③ 프로세스(Process) - 작업 계획

 

정형 기술 검토 지침 사항

① 의제와 그 범위를 유지하라.

② 참가자의 수를 제한하라.

③ 각 체크 리스트를 작성하고, 자원과 시간 일정을 할당하라.

④ 개발자가 아닌 제품의 검토에 집중하라.

⑤ 논쟁과 반박을 제한하라.

⑥ 검토 과정과 결과를 재검토하라.

 

SCRUM이란?

• 요구사항 변경에 신속하게 대처할 수 있도록 반복적이고 점진적인 소규모 팀원간 활발한 소통과 협동심이 필요한 팀 중심의 소프트웨어 개발 방법론
• 신속하게 반복적으로 실제 작동하는 소프트웨어를 제공
• 개발자들의 팀 구성과 각 구성원의 역할, 일정 결과물 및 그 외 규칙을 정하는 행위
• 기능 개선점에 우선순위를 부여하고, 개발 주기 동안 실제 동작 가능한 결과를 제공
• 개발 주기마다 적용된 기능이나 개선점의 리스트를 제공
• 커뮤니케이션을 위해 팀은 개방단 공간에서 개발하고, 매일 15분 정도 회의를 한다.
• 팀원 스스로 팀을 구성해야 한다 → Self Organizing
• 개발 작업에 관한 모든 것을 스스로 해결해야 한다 → Cross Functional

 

스크럼의 5가지 가치

① 확약 : 약속을 확실히 실현한다.

② 전념 : 확약을 위해 실현에 전념한다.

③ 정직 : 모든 사실을 숨기지 않는다.

④ 존중 : 다른 사람에게 경의를 표한다.

⑤ 용기 : 옳은 일을 할 수 있도록 갈등과 도전을 극복한다.

 

SCRUM의 기본 원리

• 기능 협업을 기준으로 배치된 팀은 스프린트 단위로 소프트웨어를 개발한다.
• 스프린트는 고정된 30일의 반복이며, 스프린트 시 행하는 작업은 고정된다.
• 요구사항, 아키텍처, 설계가 프로젝트 전반에 걸쳐 잘 드러나야 한다.
• 정해진 시간을 철저히 지켜야 하며, 완료된 모든 작업은 제품 백로그에 기록된다.
• 가정 기본적인 정보 교환 수단은 일일 스탠드 업 미팅, 또는 일일 스크럼이다.

 

SCRUM 팀의 역할

① 제품 책임자(PO, Product Owner)

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

 

② 스크럼 마스터(SCRUM Master)

• 업무를 배분만하고 일은 강요하지 않으며 팀을 스스로 조직하고 관리하도록 지원한다.
• 개발 과정에서 장애 요소를 찾아 제거한다.
• 개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원한다.

 

③ 스크럼 팀(SCRUM Team)

• 제품 책임자, 스크럼 마스터를 제외한 팀원(개발자, 디자이너, 제품 테스터 등 모든 팀원)이 해당되고 팀원은 5~9명 내외로 구성한다.
• 기능을 작업 단위로 분류하며, 요구사항을 사용자 스토리로 도출, 구현한다.
• 개발 일정, 속도를 추정한 뒤 제품 책임자에게 전달한다.
• 스프린트 결과물을 제품 책임자에게 시연한다.
• 매일 스크럼 회의에 참여하여 진행 상황을 점검한다.

 

스크럼(SCRUM)의 과정

① Product Backlog (제품 기능 목록)

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

 

② Sprint (스프린트)

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

 

③ Sprint Planning Meeting

• Product Backlog(제품 기능 목록)에서 진행할 항목을 선택한다.
• 선택한 스프린트에 대한 단기 일정을 수립하교 요구사항을 개발자들이 나눠 작업할 수 있도록 Task단위로 나눈다.
• 개발자별로 Sprint Backlog를 작성하고 결과물에 대한 반복 완료 시 모습을 결정한다.
• 수행에 필요한 요구사항을 SCRUM Master에게 보고하여 이해관계자로부터 지원을 받는다.

 

④ Daily SCRUM Meeting

• 매일 약속된 시간에 짧은 시간 동안(약 15분) 서서 진행 상황만 점검한다.
• 한 사람씩 어제 한 일과 오늘 할 일을 이야기하고, 스프린트 작업 목록을 잘 개발하고 있는지 확인한 뒤 완료된 세부 작업 항목을 완료 상탵로 옮겨 스프린트 현황판에 갱신한다.
• 스크럼 마스터는 방해 요소를 찾아 해결하고, 잔여 작업 시간을 소멸 차트(Burn Down Chart)에 기록한다.

 

⑤ Finished Work

• 모든 스프린트 주기가 완료되면 제품 기능 목록(Product Backlog)의 개발 목표물이 완성된다.

 

⑥ 스프린트 리뷰(Sprint Review)

• 스프린트 검토회의(Sprint Review)에 개발자와 사용자가 같이 참석한다.
• 하나의 스프린트 반복 주기(2~4주)가 끝나면 실행 가능한 제품이 생성되는에 디에 대해 검토하며 검토는 가능한 4시간 안에 마무리한다.
• 개선해야 할 사항에 대하여 제품 책임자(Product Owner)는 피드백을 정리하고 제품 백로그(Product Backlog)를 작성하여 다음 스프린트에 적용한다.

 

⑦ 스프린트 회고(Sprint Retrospective)

• 스프린트에서 수행한 활동과 결과물을 살펴본다.
• 개선점이 없는지 살펴보고 문제점을 기록하는 정도로 진행한다.
• 팀의 단점을 찾기보다는 강점을 찾아 팀의 능력을 극대화한다.
• 개발 추정 속도와 실제 작업속도를 비교하고 차이가 있다면 이유를 분석해본다.