SW공학 : SW개발 방법론

■ SW 개발 방법론

1. 유지보수 및 생산성 증대를 위해 개발 방법론을 사용 

 - SW 개발에 관한 계획, 분석, 설계 및 구축에 관한 정형화된 방법과 도구를 사용하여 

   효과가 증명된 체계화된 방법으로 SW 개발

2. SW개발 방법론의 필요성

 - 생산성 향상

 - Reuse

 - 표준화된 용어와 템플릿화된 산출물

 - 프로젝트 관리 수월

 - 의사소통 수단 제공

3. SW 개발방법론의 진화

 1) 구조적 기법

 2) 정보공학

 3) 객체지향 

 4) CBD(Component Based Development)

4. SW 개발방법론의 구성요소 (작작산관기도)

 - 작업절차

 - 작업방법

 - 산출물

 - 관리

 - 기법

 - 도구

5. SW개발 방법론의 종류

 - 구조적 방법론

 - 정보공학 방법론

 - 객체지향 개발 방법론

 - CBD 개발 방법론

■ Agile 방법론

※ Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것

  “Agile”이란 개발과정에서의 시스템의 변경사항을 유연하게 또는 기민하게 대응할 수 있도록 

  방법론을 제공한다는 것을 의미함. 

1. 절차나 형식보다는 사람을 중심으로 신속하고 효율적으로 시스템을 개발하는 방법론

2. 등장배경

 - 정보시스템의 Life Cycle이 짧아짐

 - 사용자의 요구사항 다양화

 - 인터페이스 증가 및 생산성 저하

 - 빠른 변화에 따른 신속한 개발 필요

3. Agile 방법론의 필요성

 - 지속적 변화대응

 - Reuse를 통한 생산성 향상

 - 품질비용 관리

 - 인터페이스 최소화

 - 신속한 개발

4. Agile 방법론의 주요 특징

 - 변화적응 

 - 사람중심 (의사소통을 통한 민첩함 확보) : 프로세스 보다는 대화 중심

 - 소규모 프로젝트에 적용 : 소규모의 타임박스화된 서브 프로젝트나 반복 주기에 적합 

 ※ 타임박스 : 소프트웨어 개발 프로젝트의 계획이나 관리에서 사용되는 기법이다.

    각각의 타임박스는 보통 1주에서 4주의 정해진 기간으로 정해져있다. 

     타임 박스의 핵심 아이디어는 "각 타임박스의  종료 시간은 변하지 않는다"는 것이다. 

     따라서 정해진 기일에 어느 정도의 결과물이 반드시 나와야 한다.

 - 반복주기 수립(요구사항 대응)

 - Pair-programming : 두 사람이 하나의 System을 Cross-Check하면서 코딩

5. Agile 방법론의 종류

 - XP 

  · 테스트 강조, 용기/의사소통/피드백, 단순성, 12개 실천항목, 1~3주 반복

 - SCRUM

  · 프로젝트를 sprint(30일 단위 반복)로 분리

  · 팀은 매일 Scrum(15분 정도) 미팅

  · Iteration 계획과 Tracking에 중점

 - DSDM 

  · 기능모델, 설계와 구현, 수행  

  · 3단계 사이클(2~6주)로 구성

 - FDD

  · 짧은 iteration(2주), 5단계 프로세스 (전체 모델 개발, 특성 list 생성, 계획, 설계, 구축)

  · 설계, 구축 프로세스를 반복

 - Crystal

  · 프로젝트 상황에 다양한 방법론 적용

  · Tailoring하는 원칙 제공

6. Agile 방법론 vs 전통적인 방법론

항목	Agile 방법론	전통적인 개발 방법론
계획	다음 반복주기(Iteration)에 대해서만 상세 계획 수립	다음에 이어지는 단계까지 상세 계획 수립
요구사항	요구사항에 대한 베이스라인 설정을 강조, 베이스라인 설정 후 개발	요구사항 정의 단계에서 모든 요구사항을 완결할 것을 강조
아키텍처	실제 개발된 기능 구현을 통해 빠른 시간 내에 아키텍처의 실현 가능성을 증명해 보이고자 함	모델과 스팩을 상세화하는 과정을 통해 application 및 data 아키텍처를 초기에 정의하고자 함
검증(Test)	잦은 개발 테스트 주기를 통해 조기에 기능을 검증, 지속적 통합 및 검증	특정 기능 구현 후 단위-통합-시스템으로 확장해 나가는 방식
포준 프로세스의 적용	정의되고 반복적으로 수행되는 프로세스를 강조하지 않고, 대신 잦은 Inspection을 토대로 프로세스를 개발에 유연하게 적용하는 것을 강조	개발에 들어가기 전에 표준화된 프로세스를 제정하는 것을 중시함