[TOPCIT Essence] 02 소프트웨어 개발 방법론

 

소프트웨어 개발 방법론의 특징은 개발 단계를 각각 정의하고 각 단계별 수행활동, 산출물, 검증절차, 완료 기준을 정의하고, 개발 계획, 분석, 설계 및 구현 단계에 대해 정형화된 방법과 절차, 지원 도구를 정의한다.

 

소프트웨어 개발 방법론의 필요성

1. 개발 경험의 축적 및 재활용을 통한 개발 생산성을 향상

2. 효과적인 프로젝트 관리

3. 공식 절차와 산출물을 제시하고 표준용어 통일하여 의사소통 수단 제공

4. 각 단계별 검증과 승인된 종료를 통해 일정 수준의 품질 보증

 

소프트웨어 개발 방법론 비교

구분	구조적 방법론	정보공학 방법론	객체 지향 방법론	CBD 방법
개요	업무 활동 중심의 방법론	데이터 중심의 방법론	객체, 클래스 간의 관계를 식별하여 설계 모델로 변환하는 방법론	재사용이 가능한 컴포넌트의 개발/상용 컴포넌트를 조합하는 방법론
기본 원리	추상화, 구조화, 단계적 상세화, 모듈화	정보전략계획, 업무영역분석, 업무시스템설계, 시스템 구축	요건정의, 객체지향분석(객체 모델링, 동적모델링, 기능모델링) 객체지향설계, 테스트/배포	요구분석, 분석(아키텍쳐 정의, 유스케이스 모델링), 설계, 개발, 구현
특징	분할과 정복의 원칙 프로그램 로직 중심 컨트롤 가능한 모듈로 구조화	기업업무 지원 시스템 지원방법론 데이터 모델 중시 프로그램 로직은 데이터 구조에 종속(CRUD) 전사적 통합데이터 모델	프로그램 단위는 개체 데이터와 로직 통합 고도의 모듈화 상속에 의한 재사용 분석 설계간 갭 없음	객체방법론의 진화 인터페이스 중시 인터페이스 구현은 컴포넌트 블랙박스 재사용 지향
산출물	Teamwork, SA	Cool Gen, SA	Rose, Sa, Palastic	Cool Joe, Together
언어	COBOL,C,VB,PASCAL	COBOL,C,,VB,PASCAL	C++,JAVA,VB	원칙적으로 개발언어 무관

 

소프트웨어 개발 단계

소프트웨어 개발 활동은 소프트웨어 생명 주기에 따라 정의된다.

 

1) 요구사항 분석

• 소프트웨어 개발에 있어서 가장 어려운 부분은 무엇을 개발할 것인가 정확히 결정하는 것
• 소프트웨어 요구분석은 소프트웨어 개발은 실제적인 첫 단계로 사용자의 요구에 대하여 이해하는 단계
• 전체 개발 과정에서 개발비용을 감소시킬 수 있는 결정적인 단계
• 초기에 요구사항을 잘 분석하여 정의 및 관리하기 위해 투자한다면 전체 소프트웨어 개발 기간과 비용의 초과, 품질 저하를 미연에 방지 가능

2) 설계

• 소프트웨어 요구분석 과정을 개념적인 단계라 한다면, 설계 과정은 물리적 실현의 첫 단계
• 시스템 설계는 서브 시스템들로 이루어지는 시스템 구조를 결정, 서브 시스템들은 하드웨어나 소프트웨어 등으로 구성요소에게 할당
• 설계는 품질에 직접적인 영향을 줌
• 설계가 제대로 되지 않으면 시스템의 안정감 저하, 안정감 없는 시스템은 유지보수도 어려움

3) 구현

• 소프트웨어 구현 단계의 목표는 설계 명세를 기반으로 요구사항을 만족할 수 있도록 프로그래밍 하는 것
• 프로그램은 상세 설계나 사용자 지침서에 기술된 것과 일치하도록 코딩해야함
• 구현 단계에서 가장 중요한 작업 중 하나는 코딩 표준을 정하고, 이를 기반으로 명확하게 코드를 작성하는 것

4) 테스팅

• 시스템이 정해진 요구를 만족하는지, 예상과 실제가 어떤 차이를 보이는지에 대해 검사하고 평가하는 일련의 과정
• 소프트웨어 품질 보증을 위한 마지막 단계로 소프트웨어의 품질을 확보하기 위해 결함을 찾아내는 작업
• 개발한 소프트웨어 품질에 대한 평가와 품질 향상을 위한 수정 작업 등이 포함

 

애자일 개발 방법론

 

애자일 방법론이란 오늘날에도 많은 기업에서 사용하고 있는 방법론으로 Agile은 기민한, 민첩한 이라는 뜻으로 일정한 주기를 가지고 빠르게 제품을 출시하여, 고객의 요구사항 변화된 환경에 맞게 요구를 더 하고 수정해나가는 탄력적인 방법론을 뜻한다.

 

애자일 방법론 종류

애자일 선언문이 나온 이후 다양한 애자일 방법론이 등장하게 된다. 이 중에서 가장 보편적인 방법은 스크럼과 익스트림 프로그래밍(XP)이다. 초창기엔 XP가 주를 이루었지만 스크럼이 점차 인기를 끌면서 최근에는 일반적으로 둘다 병용한다.

최근에는 도요타 시스템의 린 생산방식을 SW 개발에 적용하자는 린 SW 개발 방법론이 급부상하면서 스크럼과 함께 사용되기도 한다.

 

1. 애자일 개발 방법론 - XP

XP는 1990년대 후반 켄트 벡을 중심으로 여러 엔지니어들이 프로젝트를 진행하며 얻은 교훈을 기반으로 정립된 방법론으로, 보통 중소규모 개발 조직에 적합한 경량화된 개발 방식이다. XP의 경우 테스트 주도 개발, 일일 빌드, 지속적은 통합 등 개발 테크닉과 연관된 부분이 많아 방법론으로만 규정지을 수 없다는 논란도 있다. 국내에서도 작은 규모의 팀을 중심으로 기법 중 일부를 적용하는 것이 일반적이며, XP만을 고집하는 것 보다는 스크럼과 같은 추가적인 방법을 함께 적용하는 경우가 많다. XP를 적용함에 있어서는 그 가치(Value)와 그 가치를 달성하기 위한 실천법(Practice)으로 구성되어 있으며, 이 두가지 균형을 유지하기 위한 원칙(Principle)이 필요하다. 프로젝트 수행 과정에서 테스트 결과에 따라 여러번의 반복을 하며 업무를 수행한다.

 

XP 개발 용어는 다음과 같다.

• 유저 스토리 : 요구사항 수집, 의사소통의 도구를 말하고 기능단위의 필요한 내용을 간단하게 기재한다.
• 스파이크 : 어려운 요구사항 혹은 잠재 솔루션을 고려한 간단한 프로그램으로서, 사용자 신뢰성을 증대, 기술 문제의 위험을 감소하는 목적을 갖는다.
• 릴리즈 계획 : 전체 프로젝트에 대한 배포 계획을 수립하여 하나의 반복을 1~3주로 나누고 반복을 균일하게 유지
• 승인 테스트 : 릴리즈 하기 전 인수 테스트로서 고객이 직접 수행한다.
• 작은 릴리즈 : XP 주기의 마지막 단계이고, 소규모로 빈번하게 배포하면 고객에게 여러 이득을 조기에 제공가능

 

XP 개발 절차는 다음과 같다

 

XP 가치

XP에서는 기본적으로 다섯 가지 가치를 제안한다.

• 의사소통 : 팀 단위 소프트웨어 개발에서 가장 중요한 것은 의사소통이며, 실패한 프로젝트에서 볼 수 있는 전형적인 현상은 커뮤니케이션 오류이다. 고객, 개발자, 관리자들 간의 의사소통을 통해 문제를 해결하고 팀 빌딩을 강화해야 한다.
• 단순성 : 가장 단순하게 짤 수 있도록 사고한다. 불필요한 복잡성을 제거하여 설계를 단순하고 명확하도록 유지한다.
• 피드백 : 어제의 산출물이나 가치가 오늘 무용지물이 되는 변화의 흐름 속에서 완전성보다는 점진적인 개선이 효과적이다. 팀이 가능한 한 최대한 빨리, 최대한 많은 피드백을 수용하여 개선한다.
• 용기 : 가능한 한 빨리 변경된 사항을 반영하여 고객에게 인도한다는 정신 아래 요구사항 및 기술 변경에 용감하게 대처해야 한다. 해결하려는 용기는 단순함을, 구체화혀러는 용기는 피드백을 강화한다
• 존중 : 앞의 4가지 뒤에 숨어있는 가치로, 팀에 속한 다른 사람들을 중요하게 여기지 않고서는 프로젝트를 제대로 할 수 없다.

 

XP 실천방법

구분	실천방법	설명
개발	단순한 설계	현재의 요구사항을 만족시키도록 가능한 단순하계 설계해라
	테스트 기반 개발	코드를 작성하기 전에 테스트부터 작성하고 테스트 도구를 사용해 자동화해라
	리팩토링	코드의 중복과 복잡성을 제거하여 기존 코드의 디자인을 향상시켜라
	코딩 표준	효과적인 소통을 위해 코딩 표준을 만들어라
	짝 프로그래밍	두 명의 개발자가 한 컴퓨터 앞에 앉아서 같이 작업을 진행해라
	코드 공유	팀의 모두가 소스 코드에 대해 공동으로 책임을 져서 언제 누구던 코드를 발전시킬 수 있게 해라
	지속적인 통합	작업이 끝날 통합 작업을 수행해라
관리	계획 게임	프로젝트 전체 계획과 주기 계획을 비지니스와 기술적인 측면을 고려하여 세우고, 실행과 피드백을 통해 업데이트를 유지해라
	작은 릴리스	실행 가능한 모듈을 가능한 빨리 배포하여 고객이 수시로 소프트웨어가 어떻게 돌아가는지 볼 수 있도록 해라
	메타포	시스템에 대한 전체 모습일 이해하기 쉬운 그림과 스토리로 표현하라
환경	주 40시간 작업	품질의 유지를 위해 일주일에 40시간 이상 일하지 마라
	현장 고객	실제 시스템을 사용한 고객이 개발 현장에 상주하게 하라

 

 

2. 스크럼

스크럼이란 프로젝트 관리를 위한 애자일 방법론으로서 추정 및 조정 기반의 경험적 관리기법의 대표적인 형태이다.

 

스크럼 프로세스

스크럼 프로세스는 다음과 같은 3가지 구성 요소를 갖는다.

• 스프린트 : 달력기준 1~4주자 단위의 반복개발기간을 가리킨다.
• 3가지 미팅 : 일일 스크럼, 스프린트 계획, 스프린트 리뷰
• 3가지 산출물 : 제품 백로그, 스프린트 백로그, 소멸 차트

 

3가지 미팅

• 스프린트 계획 : 각 스프린트에 대한 목표를 세우고 제품 백로그로부터 스프린트에서 진행할 항목을 선택한다. 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립한다.
• 일일 스크럼 : 매일 진행하는 15분간의 프로젝트 진행상황을 공유하는 회의로, 모든 팀원이 참석하여 매일 진행 상황을 이야기한다.
• 스프린트 리뷰 : 스프린트 목표를 달성했는지, 진행과 결과물을 확인하는 회의이다. 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 피드백을 받고, 가능하면 해당 스프린트 동안 진행된 모든 작업에 대한 데모를 진행하고 고객을 참여시키는 것이 좋다. 이 때 스크럼 마스터는 스프린트 동안 발생한 애로사항에 대한 회고를 진행할 수 있다.

 

3가지 산출물

• 제품 백로그 : 제품에 담고자 하는 기능의 우선순위를 정리한 목록, 고객을 대표하여 제품 책임자가 주로 우선순위를 결정한다. 제품 백로그에 정의된 기능을 사용자 스토리라고 한다. 사용자 업무량에 대한 추정은 주로 스토리 포인트라는 기준을 이용한다.
• 스프린터 백로그 : 하나의 스프린트 동안 개발할 목록으로 사용자 스토리와 이를 완료하기 위한 작업을 과업으로 정의한다. 각 과업의 크기는 시간 단위로 추정한다.
• 소멸 차트 : 개발을 완료하기까지 남은 작업량을 보여주는 그래프, 각 이터레이션 별로 남아있는 작업량을 스토리 포인트라는 것으로 나타낸 것이다.

스크럼 역할자

• 제품 책임자 : 제품 기능목록에 해당하는 제품 백로그를 만들고 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리, 스프린트 계획 수립 시점에는 핵심 역할을 담당하지만 스프린트 시작 후 가능한 팀의 운영에 관여하지 않는 것을 권장한다.
• 스크럼 마스터 : 팀의 업무를 방해하는 요소 제거에 노력한다. 원칙과 가치를 지키면서 팀이 개발을 진행할 수 있도록 지원한다.
• 스크럼 팀 : 5~9명으로 구성하며, 사용자 스토리를 사용하여 한 스프린트 동안에 개발할 기능을 도출한다.

 

스크럼 특징

• 투명성 : 프로젝트가 현재 어떤 상태인지 계획대로 진행되고 있는지 어떤 문제점을 가지고 있는지 정확히 파악하는건 어려운 일이다. 스크럼은 스크럼 회의, 소멸차트, 스프린트 리뷰와 같은 기법을 이용해서 프로젝트의 상태나 문제점을 효과적으로 파악할 수 있다.
• 타임박싱 : 스크럼을 진행하는데 들어가는 시간을 제한함으로써 프로젝트 진행에만 집중하는 것이 가능해진다. 일일 스크럼은 매일 15분 제한으로 진행하여, 스프린트 리뷰는 매 이터레이션마다 주기적으로 진행된다.
• 커뮤니케이션 : 스크럼에서는 팀원 간 커뮤니케이션을 원할하게 하기 위해 많은 노력을 기울인다. 일일 스크럼에서 개발자들이 갖고 있는 문제점을 공유하고, 플래닝 포커를 사용하여 사용자 스토리의 구현 난이도, 시간을 토론하는 절차는 팀원간 커뮤니케이션을 원할하게 해주는 스크럼의 특징 중 하나이다.
• 경험주의 모델 : 스크럼은 고유의 프로세스 모델을 가지고 있지만 많은 기법들이 프로젝트에 참여하고 있는 개개인의 경험도 중요시한다. 프로젝트별 고유한 상황과 특징이 있기 때문에 기존에 정형화된 프로세스로는 이런 프로젝트의 상황을 따라가기 어렵다. 스크럼은 기본적인 구조만 동일할뿐 실제로 팀마다 달라지는 것을 인정한다.