2. 소프트웨어 개발방법론과 개발 프로세스 모델

2.1 프로세스

2.1.1 프로세스란 무엇인가?

소프트웨어 공학에서의 프로세스: 소프트웨어 개발 과정의 각 작업 단계

2.1.2 단계적 개발 프로세스(SDLC)와 주요 산출물

1. 계획수립: 시스템 정의서, 시스템 요청서, 프로젝트 관리 계획
2. 요구사항분석: 요구사항 명세서, 단위 테스트 계획서, 시스템 제안서, 사용자 매뉴얼 초안, 요구사항검토보고서
3. 설계: 소프트웨어 설계 명세서(SDD), 설계 검토 보고서, 테스트 케이스 생성, 통합 테스트 계획서
4. 구현(코딩) 및 테스트: 프로그램 코드, 단위테스트 보고서, 통합테스트 보고서, 시스템테스트 보고서
5. 전개: 시스템 설치 계획서, 설치 테스트 보고서, 인수 테스트 보고서
6. 유지보수: 유지보수 계획서, 유지보수 결과 보고서

2.2 소프트웨어 개발 접근 방식

기능 중심 개발방법론, 데이터 중심 개발방법론, 객체지향 개발방법론

2.2.1 기능 중심 개발방법론

• 문제를 기능, 처리절차 중심으로 분해하고 모듈화해서 해결.
• 특징: 단계적 정제 + 하향식
• 단점: 한 함수가 여러 데이터를 처리하니까 시스템이 꼬여서 확장성과 유지보수성이 크게 떨어진다

2.2.2 데이터 중심 개발방법론

• 객체지향의 모태
• 문제를 데이터 중심으로 분해하고 그 데이터에 필요한 기능을 붙인다. 따라서 시스템이 자연스럽게 데이터(구조)+관련프로그램으로 나뉜다.
• 주 활용처: 대규모 데이터를 다루는 게임 프로그래밍에 주로 사용됨.
• 장점
  1. CPU의 참조 지역성을 이용해 이게 최적화되면 멀티 CPU에서 병렬 처리가 쉬워진다.
  2. 메모리 캐싱을 효율적으로 써서 처리 시간이 준다

2.2.3 객체지향 개발방법론

• 문제를 객체 중심으로 분해 후, 문제 영역을 객체 클래스의 집합으로 보고 모델링&구현

데이터 중심과 비교

• 유사점: 둘 다 데이터(자료구조)와 그걸 처리하는 연산이 함께 다닌다.

• 차이점: 객체지향엔 캡슐화에 의한 정보은닉, 상속, 다형성이 있지만 데이터 중심에는 없다.

• 따라서 웬만하면 객체지향이 더 낫다.

2.3 소프트웨어 생명주기의 프로세스 종류

• 2.1의 "프로세스"는 개발 단계(공정)이었지만, 여기서는 범위를 넓혀서, 소프트웨어 생명주기 전체(수주, 공급, 기술 관리, 계획, 개발, 운영, 폐기)에서 일어나는 모든 활동을 프로세스로 분류

4대 분류

1. 계약 프로세스

   • 수집(구매자쪽), 공급(판매자쪽)
   • 매매 계약

2. 프로젝트 조직관리 프로세스

   • 생명주기 모델 관리, 기반 구조, 품질, 지식, 포트폴리오 관리
   • 조직 차원에서 프로젝트를 할수있게 서포트

3. 기술 관리 프로세스

   • 위험관리, 형상관리, 정보관리, 평가, 품질보증
   • 프로젝트 하나를 관리

4. 기술 프로세스

   • 업무분석, 이해관계자 및 요구사항 정의, 시스템/SW 요구사항정의, 아키텍처 설계, 설계 정의, 시스템 분석, 구현, 통합, 검증 및 보증, 운영, 전개, 유지보수, 폐기
   • 실제 개발(SDLC단계들이 전부 여기에 해당)

2.4 소프트웨어 개발 프로세스 모델

• 일반적인 SDLC 프로세스: 요구사항분석 → 설계 → 개발(구현) → 테스트 → 전개 → 유지보수
  • 테스트: 단위 테스트, 통합 테스트, 시스템 테스트
  • 전개: 설치 테스트, 인수 테스트
• SDLC는 발표 기관에 따라 6~8단계로 다름
• 대표 모델 7개: 폭포수(waterfall), 프로토타이핑(rapid prototyping), 나선형(spiral), V-모델(V-model), 반복적 증감형(iterative incremental), 애자일(agile), 익스트림 프로그래밍(XP)

2.4.1 폭포수 모델

정의: 요구사항분석 → 설계 → 구현 → 테스트 → 전개 → 유지보수

• 이전단계로 돌아갈 수 있지만 비용이 크다

1. 적합한 프로젝트
   1. 요구사항 변경이 적은 프로젝트
   2. 기간이 짧고 위험이 적은 소규모 프로젝트
2. 단점
   1. 개발 주기가 김(최종 단계가 되어야 작동하는 SW를 확인 가능)
   2. 요구사항 변경이 많을 때 부적합
   3. 단계별 진척도 측정이 어려움

2.4.2 프로토타이핑 모델(rapid prototyping model)

정의

요구사항 수집 → 빠른 결정 → ┬ 고객과 요구사항 정제 ┬ → 프로토타입의 고객 평가 → 설계 → 구현 → 유지보수
                      └ 프로토타입 개발     ┘

• 요구사항 정제랑 프로토타입 개발이 병렬로 갈라졌다가 고객 평가에서 다시 합쳐진다.
• 실제 개발에 들어가기 전에 동작하는 시스템 프로토타입 구축을 요구하는 접근법
• 장점
  1. 프로젝트 초기에 모델 모형 확인 가능
  2. 누락된 기능 발견이 쉽고 요구사항 자주 변경시 적합
  3. 에러를 완성 전에 더 빨리 탐지, 유지보수 비용감소
  4. 응용 시스템 개발에 적합
• 단점
  1. 시간 많이 걸림
  2. 안좋은 프로토타입이 최종 제품이 되기도 한다
  3. 클라이언트와 폭넓은 협업 필요
  4. 코딩에만 빠지기 쉽다

2.4.3 나선형 모델

• 위험중심
• 계획(Planning) → 위험분석(Risk Analysis) → 개발(Engineering) → 평가(Evaluation) → 다시 계획 …
• 장점
  • 불명확한 요구사항을 가진 대형 프로젝트에 적합
  • 위험도가 적음
  • 고객 피드백 반영이 높음
• 단점
  • 반복이 지나치면 고비용
  • 소규모엔 부적합

2.4.4 V-모델

• 폭포수 모델의 확장 형태

요구사항분석 ·········· 인수 테스트 설계 ··········→ 인수(승인) 테스트
  시스템 설계 ········· 시스템 테스트 설계 ········→ 시스템 테스트
    아키텍처 설계 ······ 통합 테스트 설계 ·······→ 통합 테스트
      모듈 설계 ········ 단위 테스트 설계 ·····→ 단위 테스트
                          코딩

• 폭포수와 차이점: 폭포수는 소프트웨어 개발 주기마다 요구사항분석서 및 테스트계획서, 설계명세서, 코드, 테스트(단위테스트와 통합테스트) 단계를 거치지만, V-모델은 요구사항분석서와 승인 테스트 계획서, 시스템 설계서와 시스템테스트 계획서, 아키텍처 설계와 통합테스트 계획서, 모듈 설계와 단위테스트 계획서, 코드 구현 등을 단계적으로 생산한다.

2.4.5 반복적 증감 프로세스 모델

• SDLC의 반복 모델 + 증감형 모델의 조합

  • 증감형 모델: 기능을 조금씩 덧붙여 나가는 것

• 장점

  • 소규모~중간 규모 제품의 요구사항 변경에 적합
  • 주기적인 위험분석
  • 초기 결함 발견
  • 제품 관리 용이

• 단점

  • 요구사항 엄격히 이해해야함
  • 클라이언트한테 계속 피드백을 요구해야함
  • 완성버전을 검토하지 않으면 자원을 빠르게 소모

4단계

1. 인지: 예비 요구사항 분석
2. 상세화: 소프트웨어 아키테거 설계
3. 구축: 버전과 아키텍처 개발, 클라이언트 피드백 반영
4. 전이: 버전을 제품 생산 환경에 인도

2.4.6 애자일 모델

• 스크럼: 소규모 개발팀
• 스프린트 2~4주 분량 소규모 작업단위, 하나의 스크럼 팀이 여러 스프린트 병렬로 돌릴 수 있다
• 스프린트 하나의 생명주기: 계획 → 설계 → 구현 → 테스트 → 전개 → 검토
• 스크럼 구성: 보통 7명 이내
  • 대규모: 스크럼 마스터 1 + 제품 주인 1 + 개발자 5
  • 소규모: 스크럼 마스터 1 + 제품 주인 1 + 개발자 3

스크럼 진행 8단계

1. 제품 백로그 작성: 이해관계자의 요구사항을 나열하고 우선순위를 내림차순으로 부여
2. 스프린트 계획 회의: 스크럼 마스터, 제품 책임자, 개발팀이 무엇을(what), 어떻게(how) 할지 결정
3. 스프린트 백로그 작성: 제품 백로그에서 이번 스프린트 작업을 작은 task로 분할. 업무 보드 형식 = 스크럼 보드
4. 일일 스크럼 회의: 매일 서서 15분. 어제 한 일, 오늘 할 일, 문제점 공유. 주당 2시간 초과 X. 현황판은 할 일 / 진행 중 / 완료
5. 실행 가능한 제품 개발: 스프린트마다 목표한 실행 가능한 제품을 완성해서 배포
6. 스프린트 검토: 수행한 기능을 고객·이해관계자에게 발표하고 피드백 받음
7. 스프린트 회고(sprint retrospective): 슬라이드엔 6단계와 같은 문장으로 나옴
8. 다음 스프린트 반복 수행

• 제품 백로그 = 제품 전체 요구사항 목록 / 스프린트 백로그 = 이번 스프린트 작업 목록

장단점

• 장점
  • 작동하는 제품을 수시로 전달 → 고객 만족도 높음
  • 시장 변화에 빠르게 대처, 적기 납품
  • 이해관계자·사용자 피드백 받기 쉬움
  • 프로세스·도구보다 협업 중시, 면대면 대화가 최고의 통신 수단
  • 초기부터 코드 품질 중시, 문제가 커지기 전에 해결
• 단점
  • 경험 많은 고숙련 팀 필요 (신입이 설 자리 없음)
  • 문서 작업과 설계에 집중하기 어려움
  • 고객의 최종 목표가 불명확하면 궤도 이탈
  • 격렬한 스프린트로 팀이 지침
  • 대형 제품은 초기 노력 평가가 어려움

애자일 vs 나선형

XP(익스트림 프로그래밍)

• Kent Beck이 제안한 애자일 방법론 중 하나
• 목적: 고객이 원하는 양질의 SW를 빠른 시간 내에 전달
• 소규모 인원에 적합. 문서보다 소스코드, 개인의 책임과 용기 중시
• 5단계: 릴리즈 계획 → 설계 → 반복적인 코딩 → 테스트 → 경청과 고객 동의
  • 릴리즈 계획: 고객이 사용자 스토리로 요구사항 제시
  • 설계: 단순성
  • 반복적인 코딩: 페어 프로그래밍, 지속적 통합, 공동 코드 소유권
  • 테스트: XP의 핵심. 단위 + 인수 테스트, 하루에 여러 번 통합
• 용어
  • 사용자 스토리: 필요한 기능에 대한 고객의 간단하고 비공식적인 설명
  • 메타퍼(은유): 시스템이 어떻게 작동하는지에 대한 비전
  • 스파이크: 불명확한 요구사항을 명확하게 만드는 토의. 아주 간단한 프로그램이라 프로토타입과 유사
• 특징: 테스트 강조(코딩하면서 테스트 코드 작성), 현장 고객 필수, 코드 개별 소유권 없음(팀 전체 소유)

모델 비교표

2.5 소프트웨어 개발 프로세스 모델에서 주의할 점

• 기본 모델 3개(폭포수, 프로토타이핑, 반복적 증감형)를 충분히 이해해야 함
• 나선형, V-모델, 애자일, XP를 적용해도 내부적으로는 기본 모델을 부분 적용하기 때문
  • 예1: 나선형의 개발(engineering) 단계에서 폭포수나 프로토타입 모델을 적용
  • 예2: 애자일(스크럼 5~8명)의 각 스프린트도 실제로는 기본 모델로 진행