2. 소프트웨어 개발 프로세스

1. 소프트웨어 개발 프로세스 모델의 개요

가. 소프트웨어 개발 프로세스 모델의 정의

소프트웨어 개발 프로세스의 정의	-소프트웨어에 대한 계획부터, 요구사항분석, 설계, 개발, 테스트, 운영, 유지보수, 폐기까지 일련의 활동들 -소프트웨어 개발 생명주기 (SDLC)
소프트웨어 개발 프로세스 모델의 정의	-작업들 사이에 관련 작업의 추상화를 통해 주요 활동들을 정의하고 활동들의 순서를 표현하는 기법 -소프트웨어 개발 프로세스를 단순화, 모형화하여 정의하는 기법

나. 소프트웨어 개발 프로세스 모델의 특징

-소프트웨어 개발에 일관된 구조 제공

-프로젝트 관리를 위한 하부 구조 제공

-프로세스 개선 및 자동화 가능

-용어 표준화

 

2. 소프트웨어 개발 프로세스 모델의 유형

구분	특징	설명
폭포수 모델	-순차 진행 -문서 중심 -문제도메인 이해	-가장 고전적이고 전통적인 모델 -특정 단계별 순서가 엄격하게 진행되는 순차 모델 (순서 강조, 변화 예측 가능) -계획, 분석, 설계, 구현, 검사, 유지보수 -개발 초기 모든 요구사항 명확화 필요 -다른 모델의 기본 구조 모델 -각 단계에서 수행되는 모든 작업 결과를 문서화 강조 (문서 중심 모델) -문서 검토 및 승인 후 다음 단계로 진행 (전 단계를 완료해야 다음 단계 시작 가능) -문제 도메인에 대한 이해 또는 경험이 있는 경우 효과적임
병행 모델	-기간 단축 -통합 비용 상승	-폭포수 모델을 기본으로 병행 개발 수행 모델 -프로젝트 기간 단축 가능 -요구사항분석 및 설계 후 서브 프로젝트를 병행 완수 후 통합하여 최종 결과 생성 -하나의 서브 프로젝트 설계가 다른 서브 프로젝트 설계에 영향을 미칠 수 있어 통합 비용 상승 가능
프로토타입 모델	-요구사항 명확화 -빠른 시간 내에 프로토타입 제작	-개발 초기 사용자 요구사항 파악 어려움 극복 -완전한 요구사항 도출로 프로젝트 비용 감소 기대 -초기에 기본적인 요구사항(기본 입력, 출력 정보 포함)만 식별 후 프토토타입 제작 -실질적으로 실행될 수 있는 간단한 프로토타입 제작, 사용자 사용 및 피드백, 요구사항 식별하는 모델 -사용자 피드백 정보를 기초로 프로토타입 지속 개선 반복 후 개발 수행 -폐기 프로토타입 모델과 진화 프로토타입 모델로 분류 -프로토타입을 최종 결과물로 오해와 필요 이상의 기대심리 유발 가능
반복/점증 모델	-반복적 -점증적 -복잡/장기간 수행 프로젝트	-순차적인 폭포수 모델의 단점 극복 -순환적 소프트웨어 개발 프로세스 모델 -순차적인 특징을 갖는 폭포수 모델에 반복적인 특징을 갖는 프로토타입 모델을 적용 -소프트웨어 전체 기능을 나누어 중요 기능을 우선 개발, 다른 기능은 점증적 개발 -다른 점증과 통합 시 테스트 과정 반복 수행으로 결함 가능성 낮아질 수 있음 -점증 통합 시 통합 테스트 비용 증가
나선형 모델	-고비용 프로젝트 -대형 프로젝트	-폭포수 모델에 위험분석과 반복/검증 개발을 강조한 모델 -각 나선의 주기별로 위험요소에 중점을 두어 반복적, 점증적 개발 -위험을 사전에 예방 가능 -위험요인 분석 및 위험 최소화로 위험 부담을 감소시키는 모델 -계획, 위험분석, 개발, 평가 단계 수행 -개발 프로세스가 복잡하고 프로젝트 관리가 어려움 -숙련된 위험분석 전문가 섭외 어려움
재사용 모델	-도메인 분석 활동	-컴포넌트 기반 개발 모델 -재사용에 의해 개발 기간 단축 가능 및 품질 향상 가능 -CD모델(컴포넌트 자체 개발)과 CBSD모델(컴포넌트 기반 개발)로 분류 -단일 도메인이 아닌 유사 도메인에서도 재사용 가능한 컴포넌트 개발 필요 -요구분석 후 유사 컴포넌트를 레포지토리에서 검색 후 재사용
V 모델	-개발/테스트 -테스트 활동 중심	-폭포수 모델 변형 -개발활동과 테스트활동을 표현한 모델
UP 모델	-반복/점증 -분석/설계 강조 -단계 -작업흐름	-Booch, OMT, Objectory 등 객체지향 방법의 중요 특징 통합하여 UP 방법론 제안 -UP 방법론은 UP 개발 프로세스와 UML 분석/설계 모델링 표기법을 제안 -RUP은 Rational 사에서 제안한 UP 프로세스 보기 -반복/점증 개발과 사용자 상호작용을 강조 -4개 단계와 10개 작업흐름으로 구성된 2차원 프로세스 -단계는 시간 경과에 따른 시스템 진화 묘사 (시작, 정제, 구축, 전이) -작업흐름는 시스템이 진화하기 위해 개발자 수행 활동 의미 (공학 작업흐름은 기술적 결과물 생산 활동과 관련, 지원 작업흐름은 시스템 지원활동 관련) -4개 단계를 반복 수행하고 각 반복마다 여러 작업들을 수행
Agile 모델	-반복/점증 -실행 소프트웨어 중심 -자주적 팀 중심	-발생하는 변경에 신속, 유연하게 대처 가능 -가볍고 적응 가능한 프로세스  -XP, Scrum, DSDM, ASD 등 프로세스를 총칭 -애자일 선언문, 애자일 원리 -분석/설계 모델링과 문서화 작업에 소요되는 노력을 최소화하여 개발 프로세스 단순화 -문서보다 코딩과 테스트 활동(실행 소프트웨어)에 중점 (문서관리 소홀로 유지보수에 문제 발생 가능함) -짧은 시간에 점증 개발 수행 -자주적 팀 운영으로 작업 수행(인도작업, 인도일정)과 개발 프로세스를 자체 구성 가능 -사용자 피드백을 통해 최종 시스템에 대한 사용자 만족 향상 가능 (사용자와 지속적인 협력 강조, 하지만 지속적인 참여 기대 어려움) -사용자의 지속적인 차여로 초기 동의했던 범위와 비용 초과 가능성 존재
XP 모델	-반복/점증 -유저 스토리 -단순 설계 -짝 코딩 -리팩토링	-4개 주요활동(계획, 설계, 코딩, 테스트)로 구성 -XP Coach, Customer, Team -고객이 유저 스토리와 유저 스토리를 검증할 수 있는 테스트 기준 작성 -현 주기에 대한 간단한 일정 계획  -고객이 사용자 이야기에 대한 우선 순위 결정 -개발자는 개발일정, 비용 추정 -유저 스토리는 짧은 기간에 구현 가능(Iteration: 1~2주) -오랜 기간이 소요되는 유저 스토리는 더 작은 유저 스토리로 분할 -설계 활동은 간단히 수행하거나 생략 가능 (문서 생성은 최소화) -코딩 전 요구 기능을 확인하기 위한 단위 테스트 케이스 개발 -짝 코딩과 리팩토링 수행 -통합 테스트는 코딩 활동에서 지속적으로 수행
SCRUM 모델	-반복/점증 -적극적인 소통과 협업	-Product Owner는 이해관계자들과 협력을 통해 제품 백로그 작성, 관리 -Scrum Master, Product Owner, Team -스프린트는 짧은 개발 주기(1~4주) 단위로 수행 -스프린트 회의에서 우선순위가 높은 제품 백로그 선정 -선정된 제품 백로그를 기반으로 스프린트 백로그 작성 -스프린트 동안 매일 스크럼 회의 진행 -스프린트가 끝나고 스프린트 검토 회의에서 모든 이해관계자가 해당 스프린트 결과물 확인 -스프린트 검토 회의 후 스프린트 회고 회의에서 지난 작업 과정 회고, 개선점 반영

-현대의 대규모 프로젝트에서는 폭포수 모델의 주요 활동들을 기본적으로 수행되며, 사용자 요구를 빠른 시간 내에 파악하기 위해 프로토타입을 개발하고, 이러한 활동을 반복 수행하면서 결과물을 점진적으로 개발

-RUP과 Agile은 공통적으로 반복, 점증, 적응, 진화 특징을 갖지만 RUP은 분석/설계 모델링을 중시함

 

3. XP 모델 프로세스와 개발 원리

가. XP 모델 프로세스

나. XP의 5원칙

가치	설명
용기	고객 요구사항 변화에 능동적 대처
단순성	부가적 기능, 사용되지 않는 구조와 알고리즘 배제
의사소통	개발자, 관리자, 고객 간의 원활한 의사소통
피드백	지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백
존중	팀원 간의 상호 존중을 강조

다. XP의 개발 원리

구분	원리	설명
개발원리	짝 코딩(프로그래밍)	두 사람이 짝을 이루어 프로그래밍한다.
	공동 책임	모든 개발자가 소스코드에 대해서 공동 책임을 진다. (누구든지 코드 수정 가능)
	지속적인 통합	단위 테스트를 통과하면 작은 단위의 코드들은 지속적으로 시스템에 통합된다.
관리원리	게임 계획	사용자 스토리를 이용해 다음 릴리즈의 범위를 빠르게 결정한다. 비즈니스 우선순위와 기술적 평가를 결합하여 결정한다.
	짧은 릴리즈	필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈하여 짧은 단위로 업데이트 한다.
	메타포	공통적인 이름 체계를 갖고 이를 활용하면 개발과 의소소통을 돕는다.
구현원리	단순 설계	현 반복주기의 사용자 이야기로 한정된 작은 단위의 설계를 신속하게 수행한다.
	테스트 중심	코딩 전 사용자 이야기에 대한 테스트 케이스를 개발한다.
	리팩토링	코드의 수행 결과를 변화시키지 않고 효율적인 코드 구조로 변경한다.
환경요소	주 40시간 작업	일주일 40시간 초과근무 금지, 2주 연속 오버타임 금지
	고객 상주	시스템 기능과 범위를 신속하게 결정한다.
기타	코드 표준	코드 표준을 이용한다. 표준을 통해 재사용과 유지보수를 용이하게 한다.

 

4. 애자일 선언문과 원리

애자일 선언문

공정과 도구보다 개인과 상호작용을  포괄적인 문서보다 작동하는 소프트웨어를  계약 협상보다 고객과의 협력을  계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.

애자일 원리

1. 가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것을 최고 우선순위로 한다. 2. 개발 작업 후반부일지라도 요구사항 변경을 기꺼이 수용한다. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다. 3. 2주에서 2개월 주기로 작동하는 소프트웨어를 자주 제공하되, 더 짧은 시간 단위를 선호한다. 4. 프로젝트 전반에 걸쳐 비즈니스 담당자들과 개발자들이 매일 함께 작업해야 한다. 5. 동기가 부여된 개인들을 중심으로 프로젝트를 구성한다. 구성원들이 필요로 하는 환경과 지원을 제공하고, 담당 업무를 완수할 것임을 신뢰한다. 6. 개발팀에 그리고 팀 내부에서 가장 효과적, 효율적으로 정보를 전달하는 방법은 대면 대화이다. 7. 작동하는 소프트웨어가 진처의 주된 척도이다. 8. 애자일 프로세스는 지속 가능한 개발을 장려한다. 스폰서와 개발자, 사용자들이 일정한 속도를 계속 유지할 수 있어야 한다. 9. 기술적 탁월성과 좋은 설계에 대한 지속적인 관심으로 기민함을 향상시킨다. 10. 단순성 - 아직 하지 않은 작업량을 최대한 세분화하는 기술 - 은 필수적이다. 11. 최고의 아키텍처, 요구사항 및 설계는 자율구성팀에서 비롯된다. 12. 팀은 정기적으로 더 효과적인 방법을 찾아서 반영한 다음, 그에 따라 업무 활동을 조율하고 조정한다.