폭포수 모델과 점진적 개발방법론

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. **

기존의 방법론에서 어떤 단점? 그리고 어떻게 극복? 주어진 환경과 제약사항을 고려했을 때 어떤 후보? 등을 생각해보자

Waterfall : 폭포수 모델

• 요구공학 → 디자인 →  코드 구현 → 모듈 단위 시험 테스트 → 통합테스팅
• 이전 단계로의 Loop back이 가능하다. 누락된 것이 있으면 멈추고 다시 돌아가서 하라는 뜻
• NASA (폭포수 모델 + 각 단계가 동시다발적으로 실행되기도 함) - 복잡한 소프트웨어 환경이라는 것을 인지
  • 요구사항 분석 단계에서 디자인 + 구현 → 프로토타입 구현, 선행적인 디자인 작업 등
  • 재작업, 변경은 추가 비용을 발생시키므로 최소화 하는 것이 좋음.
  • Document: entry criteria, exit criteria, products 산출물, measures 측정 지표, key activities 담당 역할
    ex) measures - staff hours 소요 시간, TBD 미확정 요구사항 개수, 요구사항 변경 주기... 등 → 자동화 도구 이용

Incremental / Iterative : 점진적 모델

• 매년 신제품/버전을 출시할 때, 기본적인 기능은 자주 변하지 않음 → 소프트웨어의 재사용 + 테스팅 자동화 환경
• 정해진 요구사항을 여러 단계로 나누고, 단계별로 설계, 구현, 테스팅을 반복하여 기능을 점진적으로 추가하며 완성
• 마이크로소프트 1990년대  sync-and-stablize 개발 단계: Planning → Development → Stabilization → 공식 출시
  • Planning: 기능 명세 + 전체 계획 + feature별 team 분배
  • Development: 프로젝트를 (2~4개월 걸리는) 3개로 나누어 점진적으로 구현 
    - buffer time: 예비 개발기간 20~50% 할애 → 돌발상황이 발생할 수 있기 때문 (요구사항 변경, 버그 수정 등)
    - Code Stabilization: 주관적인 판단. ① No severe bug ③ Zero bug release (오류가 없을 수는 없음)
                                                → Issue Tracking (Bug) System 사용: 오류의 등급별로 수정 여부를 결정
    
  • Stabilization: internal testing + beta testing →  버그 수정 및 개선
  • 번외) Daily build: 특정 모듈이 완성될 때 마다 repository에 check-in! 다른 모듈 동작의 영향 끼치는지 확인
    수정 위해선 check-out 해야 함 → 오류를 빨리 발견하기 위한 방법, continuous integration 실시간 통합(?)
    

---

추가 자료 리스트

• Michael Cusumano and Richard Selby, How Microsoft Builds Software, ACM (1997)