프로그램 개발 방법론

< 애자일이란? >
 

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.

- 소프트웨어 개발 생산성과 품질 향상을 위하여 개발자의 잠재력 발휘와 개발팀의 협업 최적화를 중심으로 하는 개발 방법론. 

- 소프트웨어 개발 팀원들을 고무하는, 협력적 개발 접근 방법 

- “Agile”이란 개발과정에서의 시스템의 변경사항을 유연하게 또는 기민하게 대응할 수 있도록 방법론을 제공한다는 것을 의미함.

 

< 왜? 쓰는가? >

<다른 개발 방법>

접기

1) 폭포수 개발 모델
한 과정을 모든 사람들이 완벽하게 한다음에 다음 과정을 넘어가게 됨

문제점: 
한과정이 제대로 되지 않으면 다음으로 못넘어감
다음 단계가 되더라도 전 단계가 문제가 생기면 다시 처음으로 돌아가게 됨

-> 이러한 문제점의 한가지 방법론으로 애자일이 생김

접기

1). 전통적인 폭포수 모델의 의 한계

-전통적인 폭포수 모델의 요구분석단계에서 사용자가 개발자에게 한 번에 모든 요구사항을 정확하게 전달하는 것을 가정하고 있으나, 현실적으로 불가능함.

- SW의 비가시성으로 사용자의 요구사항이 프로젝트 진행 시 지속적으로 변경

2). 개발환경의 변화

- 개발환경의 개선:고급개발자의 양산, 컴퓨팅환경의 발전

- 신속한 개발을 지원하는 GUI환경의 모델링 및 개발 도구의 발전

- 테스트 및 디버그 자동화 도구의 등장

- CBD,MDA등의 신속성을 제공하는 개발방법론 등장

  -점차 짧아지는 정보시스템의 수명주시

3) 기업 경영환경의 변화

-경영전략이 빈번히 그리고 짧아지는 RTE기업의 등장

-사용자 요구사항의 지속적인 변화

 

4) 소프트웨어 구축 비용의 낭비
- 자주 사용하는 기능은 전체 기능의 20%밖에 되지 않더라~ 나머지에서  64%는 전혀사용하지 않더라~ 낭비생김
-> 즉 탐욕은 모든 프로젝트 실패의 원인이더라! 이러한 탐욕은 의욕 저하를 만듬

 

 

<애자일 방법론의 핵심 가치>
 
핵심가치 ( 제일 중요함! )
용기,자신감
단순성
의사소통
피드백
존중
자발적 헌신
집중 

정리하면,
고객 참여 -> 계약 협상에 앞서 고객과의 협력
프로세스보다 사람 -> 프로세스나 도구에 앞서 개인과 상호 협력 
변경을 포용 -> 계획 준수에 앞서 변화에 대한 대응
단순함을 유지 ->
소프트웨어 중심->포괄적인 문서화에 앞서 작동하는 소프트 웨어
반복적 릴리스 ->


  
 

<애자일과 전통적인 개발방법론의 다른 차이점,특징>

 

<애자일 개발 절차>
 

 

< 애자일의 종류 >

익스트림 프로그래밍(Extreme Programing, XP)

->
의사소통, 단순성, 피드백, 자신감

애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
ex) 짝 프로그래밍 

Scrum
-> 백로그와 스프린트
30일마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다

[출처] 애자일 개발 프로세스|작성자 폭풍우

 

익스트림 모델링 
- 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 
다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다. 

크리스털 패밀리 
이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다. 

FDD( Feature-Driven Development )
-> 기능 중심 개발
feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다. 

 

< Agile Process의 적용분야 >

-소규모의 타임 박스화 된 서브 프로젝트나 반복주기(Iteration)에 적합 (3~12주)

-사용자나 개발자가 정확한 요구사한 도출이 힘들 때

-대규모의 프로젝트보다는 기업내 단위시스템에 적합

-프로토타이핑, 속성개발(RAD)을 할 수 있는 프로젝트에 적합

-소프트웨어 품질 수준이 낮고, 산출물의 범위변경이 불가능하다면 애자일 기법은 활용하기 힘듦

< Agile Process의 향후전망 >

 가. 부정적인 측면

- 방법론 그 자체로서 적용하기에는 프로세스 정립은 부족함

- 대형프로젝트에서 적용하기에 적합하지 않음

- 감리에 대한 대응의 어려움

- 관리 방법에 대한 가이드라인이 부족함

- 해당 프로세스를 적용하기 위해서 갖추어야할 제약(선수)조건이 실제 가장 중요하면서도 하기 어려운 부분일수 있고, 안되고 있는 부분이기도 함

나.긍정적인 측면

- 방법론 그 자체로서가 아니라, 일부 기법 또는 사상을 선택하여 쓰기에 매우 좋음.

- 중.소형프로젝트에서 적용하기에 적합하며, 대형 프로젝트라 할지라도 특정 TASK에 대해 이 프로세스를 채택하는 것이 바람직한 영역이 있음

-아키텍처설계 및 프로토타이핑 수립과 같은 태스크 수행시 적합하다고 봄