6. 소프트웨어 생명 주기 모델과 테스트

순차적 개발 모델

---

대표적으로 폭포수 모델과 V-모델이 있음

 

폭포수 모델

• 모든 소프트웨어 생명 주기 모델 중 가장 오래된 전통적인 모형
• 요구사항 변경이 개발 도중 빈번하게 이루어지지 않는 경우 적합한 개발 모형
• 문서와 정보가 많이 산출되어 테스트 작업에 필요한 정보를 얻기 좋음
• 테스트를 한 단계로만 생각해서 초기에 결함을 발견할 수 있는 일이 없음 - 나중에 시간과 비용이 많이 듦

 

• 요구사항 분석 : 요구사항을 수집하고 이해, 명세화. 산출물로는 요구사항 명세가 있음
• 구조 설계 단계 : 소프트웨어의 전체적인 구조를 결정하는 단계. 시스템의 전체적인 아키텍처를 보여주는 설계 명세
• 상세 설계 단계 : 각 모듈의 알고리즘 세부사항, 구체적인 데이터 표현, 루틴과 데이터 간의 인터페이스 결정. 주요 산출물은 모듈 명세를 포함하는 상세 설계 명세
• 코딩 : 주요 산출물은 프로그램
• 테스팅 : 완성된 시스템의 결함을 검출하기 위해 테스트 수행

V-모델

• 테스트 활동이 개발이 시작됨과 동시에 시작
• 개발에 관련된 단계들과 테스트에 관련된 단계들로 명확히 구분, 그들 간의 관계를 명시적으로 나타냄
• V 모델의 V는 Verification & Validation을 의미

• 요구사항을 수집하는 동안 인수 테스트 계획을 수립
  시스템 테스트 계획을 수립하기 위해 단위 및 통합 테스트 단계가 종료되길 기다릴 필요 없음
• 각 개발 단계의 산출물로 테스트에 필요한 정보를 얻을 수 있음

 

---

진화적 개발 모델

---

• 요구사항이 명확하지 않은 경우 적용되는 개발 모델
• 이터레이션과 점진적 개발 원칙에 바탕을 둠

 

• 시스템의 핵심 부분을 개발한 후, 각 구성요소와 추가 요구사항을 여러 이터레이션을 통해 개선, 발전

• 진화적 개발 모델은 수행하는 각 이터레이션마다 테스트 수행 계획을 작성하고 이 계획에 따라 테스트 수행
• 요구사항 분석 단계와 설계 단계에서 테스트 대상은 요구사항 문서나 설계 문서

 

• 진화적 모델처럼 반복적, 점진적으로 개발하는 모델의 예로 나선형 개발 모델이 있음

나선형 모델

• 반복적으로 요구사항을 정제하고 확장하는 과정을 사용자가 받아들일 수 있는 완전한 시스템이 개발될 때까지 반복
• 기술적으로 어렵거나 고객의 비즈니스 가치를 최상으로 만드는 요구사항들에 대해 프로토타입을 개발하고
  프로토타입에 대한 테스트 및 사용자의 평가를 거쳐 다음 개발 주기를 시작
• 새로운 개발 주기가 시작될 때마다 위험 분석을 수행해서 잠재적 위험 분야를 파악하여 해결 가능
• 이 과정이 반복되면서 기능이 파악되는 시점에 V 모델에 따라 시스템 개발

• 매 단계에서 적당한 테스트가 이루어지므로 개발 과정에서 발생하는 문제점을 해결할 수 있는 기회 제공

 

---

애자일 개발 모델

---

가볍고 민첩하다는 사전적 의미

 

애자일 방법이 추구하는 가치

• 사람 및 상호 의사 교환이 프로세스나 도구보다 우선
• 동작하는 소프트웨어가 포괄적인 문서보다 우선
• 고객과 협력이 계약 협상보다 우선
• 변화에 반응하는 것이 계획을 따르는 것보다 우선

 

• 애자일 개발 방법론은 진화적 개발모델과 같이 반복적이면서 점진적인 개발 접근 방식(IID)을 따름
• IID는 소프트웨어 개발 주기를 여러 개의 이터레이션으로 구분
• 요구분석, 설계, 구현, 및 테스트와 같은 활동들로 구성된 소규모 프로젝트로 생각할 수 있음
• 이터레이션에서 산출된 시스템은 내부 개발자가 관리하는 것, 
  사용자에게 외부적으로 릴리즈되는 것은 최종 반복 주기의 산출물

• 이터레이션이 짧기 때문에 고객이 실제 동작하는 소프트웨어를 빠르게 볼 수 있어 일의 진척 정도를 눈으로 확인할 기회가 많음
• 각 반복주기 시작마다 요구사항을 선정해서 자주 변경될 수 있는 고객의 요구사항을 탄력적으로 처리할 기회 제공

 

• 애자일 방법의 하나인 XP(extreme programming)는 프로그래머가 과도한 작업을 피하는 것을 매우 중요하게 봄 
• XP는 짝 프로그래밍을 통해 개발자 간의 지식 전달 및 공유를 꾀함

 

테스트 주도 개발 TDD

• 테스트 케이스 작성을 가장 먼저 함
• 테스트를 통과하는 코드 작성 - 필요 시 TDD 수행 중 리팩토링 수행
  리팩토링 : 기능을 변경하지 않고 코드 내부 구조를 개선하는 작업
• 지속적 통합(CI)은 TDD와 더불어 애자일 개발에서 중요한 실천 규칙임

 

지속적 통합의 이점

• 통합 지연에 따른 비용 증가를 막을 수 있음
• 빠른 결함 발견으로 비용 감소
• 항상 빌드 가능한 소프트웨어 버전이 있어서 소프트웨어 품질에 대한 확신이 있음