[소프트웨어공학] 제2장 소프트웨어 프로세스 (SDLC)

1. 단원 요약

• 소프트웨어 프로세스란 소프트웨어 개발 절차를 말한다.
• 폭포수 모델(waterfall model): 고전적 SDLC, 선형 순차 모델
  • 타당성 조사 단계
    • 타당서 조사 보고서
    • 사업 개요, 기술/경제적 타당성, 기대 효과, 비용, 인도일 등
  • 요구 분석 및 명세 단계
    • 무엇을 개발할 것인가? 
    • 정확·일관·완전한 요구사항명세서(SRS) 작성
  • 설계 및 명세 단계
    • what ➡️ how
    • 설계 단계의 구분
      • 시스템 아키텍처 설계
      • 인터페이스 설계
      • 프로그램 설계
    • 설계 방법의 구분
      • 전통적인 구조적 분석/설계
      • 객체지향 분석/설계
  • 코딩 및 단위 테스트 단계
    • 설계를 바탕으로 프로그램 작성
    • 테스트 계획, 방법, 수준 결정
    • 코드 인스펙션 수행
  • 통합 및 시스템 테스트 단계
    
    • 알파 테스트: SW 개발 현장에서 수행
    • 베타 테스트: 고객이 수행
  • 인도 및 유지보수 단계
    • 수정 유지보수: 오류 수정
    • 적응 유지보수: HW, OS, 법규 등의 변화에 대응
    • 완전 유지보수: 기능/성능 개선
    • 예방 유지보수: SW 이해성/유지보수성 개선
  • 원칙적으로 요구사항이 수정을 받아들이거나 이전 단계로 돌아가지 않음
  • 그러나 현실에서는 수정과 피드백이 발생함
• 반복 진화형 모델
  • 프로토타이핑 방법론(prototyping methodology)
  • 일반적으로 고객은 요구사항을 자세히 파악하지 못함
  • 프로토타이핑 방법론은 요구사항을 파악하기에 좋은 방법론
  • 프로토타입을 빨리 개발하고, 이를 평가하여 요구사항을 보완해 가며 개발한다.
  • 프로토타이핑 방법론의 장점
    • 프로젝트 성공 가능성을 가늠할 수 있다.
    • 고객과의 의사소통이 명확해진다.
    • 비기능적 요구사항도 수용한다.
    • 사용자 교육 효과가 있다.
    • 개발 단계에서 유지보수가 일어난다.
  • 프로토타이핑 방법론의 단점
    • 문서화 및 프로젝트 관리/통제가 힘들다.
    • 개발 일정을 계획하는 것이 힘들다.
• 점증적 모델(incremental model)
  • SW를 여러 모듈로 분해하고, 각 모듈을 개발하여 인도하는 SW 개발 모델
  • 핵심 모듈을 먼저 개발-인도한다. 각 모듈은 증분이라 부른다.
  • 선형 순차 모델을 여러 번 실행하고, 그 결과를 취합하는 모델이다.
  • 점증적 모델의 장점
    • 사용자가 시스템(핵심 모듈)을 이른 시기에 사용할 수 있음
    • 요구사항 변화 대응이 용이
    • 증분들은 점차 규모와 기능이 작아지므로 관리가 용이
    • 핵심 모듈은 반복적으로 테스트되므로 안전
  • 점증적 모델의 단점
    • 시스템을 기능적으로 분해하기 어려움
    • 증분의 크기를 정하기 어려움
    • 증분 개발을 위해서는 명확한 요구사항이 필요함
• 나선형 모델(spiral model)
  • 반복 진화형 모델(프로토타이핑 방법)의 확장형
  • 타당성 조사➡️요구사항 정의➡️설계
    • 목표와 대안 정의
    • 대안 평가(🟰위험 분석)
    • 개발
    • 다음 단계의 계획
  • 나선형 모델의 장점
    • 대형 프로젝트에 적합(위험 관리가 가능)
    • 프로젝트 특성/개발 조직에 맞게 변형 가능
  • 나선형 모델의 단점
    • 충분히 검증되지 않은 모델임
    • 복잡한 모델임
    • 프로젝트 관리가 어려움
• V 모델
  • 폭포수 모델의 확장형
  • 테스트를 중요시하며, 품질 보증이 가능함
  • V 모델의 특징
    • SDLC 초반 단계에서부터 테스트를 실행
    • 개발 단계 산출물의 검증을 위해 테스트를 실행
    • 폭포수 모델에 비해 반복과 재처리 과정이 명확하게 정의됨
    • 테스트 단계별로 책임이 명확해짐
• 애자일 방법론
  • 문서화 작업보다 소프트웨어의 완성에 집중
  • 요구사항의 가변적인 중소형 업무시스템이나 전자상거래 시스템 개발에 적합
  • 익스트림 프로그래밍 지침
    • 빈번한 릴리즈, 빠른 피드백, 지속적 개선
    • 고객 또한 개발 팀의 일부, 절차보다 사람 중심
    • 단순한 설계, 테스트 선행 개발
    • 리팩토링
  • 페어 프로그래밍: 두 명이 한 조가 되어 한 명은 코드 작성, 한 명은 검사 수행
  • 테스트 선행 개발: 테스트 케이스를 작성하고, 이를 통과하는 코드를 만드는 것
    • 요구사항➡️스토리 카드➡️태스크➡️태스트 케이스
    • 요구사항과 코드 간 관계가 명확해짐
    • 통합 테스트 강조, 테스트 케이스 재사용
  • 스크럼
    •  애자일 방법을 적용할 때 필요한 프로세스 관리 절차(프레임워크)
    • 프로젝트 계획 및 검토 단계: 목표 및 아키텍처 정의, Product backlog 작성
    • 이후 스프린트의 반복
  • 스프린트
    • 1개월 이하의 짧은 프로젝트 기간
    • 스크럼 마스터(Scrum Master): 스크럼 프로세스 관리자
    • 제품 책임자(Product Owner): Product backlog 작성/관리
    • 스프린트 계획: Backlog에서 개발할 항목을 선택, 그 방법을 계획(최대 8시간)
    • 일일 스크럼: 3~9명의 스크럼 팀이 수행하는 일일 미팅(진척도, 일일 업무 검토)
    • 스프린트 리뷰: 개발 산출물을 검토, 피드백
    • 스프린트 회고: 스프린트 프로세스에 대한 개선 사항 논의

 

2. 연습문제 요약

• 점증적(incremental) 모델: 증분(increments)을 만드는 모델
• 프로토타이핑 방법론: 중간 버전이 계속 나오는 모델 = 반복 진화형 모델