참조 도서 정보
길벗알앤디, 정보처리기사 필기 시나공, 길벗, 2022

1. 소프트웨어 생명 주기

• 소프트웨어를 개발하기 위해 정희하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것.
• 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형

1-1 폭포수 모형

• 이전 단계로 돌아갈 수 없다가 전제이다.
• 개발 한 단계 끝나야 다음 단계 넘어갈 수 있는 선형 순차적 모형
• 각 단계 끝난 후 결과물이 명확해야한다.
• 두 개 이상의 과정이 병행 X
• 타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현 -> 시험 -> 유지보수

1-2 프로토타입 모형(원형 모형)

• 견본(시젬)품(prototype)을 만들어 최종 결과물을 예측하는 모형
• 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
• 모형은 이후 구현 단계에서의 골격 코드가 된다.
• 개발 완료된 시점에서 오류가발견되는 폭포수 모형의 단점이 보완된다.
• 요구수집 -> 빠른 설계 -> 프로토타입 구축 -> 고객 평가 -> 프로토타입 조정 -> 구현

1-3 나선형 모형(점진적 모형)

• 보헴이 제안한 것
• 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 나선 돌듯 여러번 소프트웨어 개발 과정을 거쳐 점진적으로 개발.
• 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객평가

1-4 애자일 모형

• '민접한'의 의미. 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행한다.
• 고객 소통에 초점을 맞춘 방법론
• 스프린트 또는 이터레이션이라 불리는 짧은 개발 주기를 반복. 주기마다 만들어진 결과물에 대한 고객 평과와 요구를 적극 수용.
• 애자일 모형 기반으로 하는 소프트웨어 개발 모형에는 스크럼, XP(익스트림 프로그래밍), 칸반, Lean, 크리스탈, ASD 등이 있다.

2. 스크럼(Scrum) 기법

• 팀(제품 책임자, 스크럼 마스터, 개발팀)의 중요성을 강조하는 용어이다.
• 팀원 스스로가 스크럼 팀을 구성, 개발 작업에 대한 모든 것을 스스로 해결할 수 있어야 한다.

2-1 제품 책임자(Product Owner)

• 제품에 대한 이해도 높고, 의사결정할 사람으로 선정, 주로 개발 의리자나 사용자가 담당
• 이해관계자 의견을 종합하여 요구사항을 작성하여 백로그를 작성하고 백로그에 대한 우선순위를 지정한다.(팀원들이 스토리 추가는 가능하지만 우선순위를 지정할 수는 없다X)
• 테스트를 수행하면서 주기적으로 요구사항 우선순위를 갱신한다.

2-2 스크럼 마스터(Scrum Master)

• 스크럼 팀이 잘 수행할 수 있도록 조언을 해주는 가이드 역할(통제가 목표X)
• 일일 스크럼 회의 주관하여 진행 사항을 점검, 장애 요소를 공론화하여 처리

2-3 개발팀(Development Team)

• 개발자, 디자이너, 테스터 등 제품 개발에 참여하는 모든 사람

2-4 스크럼 개발 프로세스

• 개발과정 순서: 스프린트 계획 회의 -> 일일 스크럼 회의 -> 스프린트 -> 스프린트 검토 회의 -> 스프린트 회고
• 제품 백로그: 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
  개발 과정에서 새로 도출되는 요구사항으로 지속적 업데이트된다
  제품 백로그에 작성된 사용자 스토리를 기반으로 릴리즈 계획을 수립한다
• 스프린트 계획 회의: 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립한다.
  task 작업 단위로 분할하여 개발자별로 수행할 작업 목록인 스프린트 백로그를 작성한다.
• 스프린트: 실제 개발 작업 진행하는 과정, 보통 2-4주 기간
  스프린트 백로그의 task를 대상으로 속도(Velocity)를 추정후 개발 담당자에게 할당한다
• 일일 스크럼 회의: 매일, 약 15분, 모든 팀원 참석하여 진행 상황 점검
  남은 작업 시간은 소멸 차트(Burn down chart)에 표시한다.
• 스프린트 검토 회의: 요구사항에 잘 부합되는지? 사용자가 포함된 참석자 앞에서 테스팅을 수행한다.
  스프린트의 한주당 한시간내에 진행
  제품 책임자는 피드백 정리후 다음 스프린트에 반영할 수 있도록 제품 백로그 업데이트한다.
• 스프린트 회고: 스프린트 주기 되돌아보며 규칙 준수 여부, 개선할 점 없는지 확인한다.

3. XP(eXtreme Programming) 기법

• 수시로 변하는 고객 요구사항에 유연하게 대응하기 위해 고객 참여와 개발과정 반복을 통해 개발 생산성을 향상시키는 방법
• 짧고 빠른 개발 주기, 단순한 설계, 고객 적극적 참여를 통해 빠르게 개발하는 것을 목표로한다.
• 릴리즈 기간 짧게 반복하여 고객 요구사항 반영에 대한 가시성을 높인다.
• 릴리즈 테스트마다 고객을 직접 참여시킨다
• xp의 5가지 핵심 가치: 의사소통, 단순성, 용기, 존중, 피드백

3-1 XP 개발 프로세스

• 사용자 스토리: 고객 요구사항을 시나리오로 표현
  내용은 기능 단위로 구성, 테스트 사항(test case)도 기재
• 릴리즈 계획 수립: 몇개 스토리가 적용되어 부분적 기능이 완료된 제품을 제공하는 것
  부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것
• 스파이크: 요구사항 신뢰성 높이고 기술 문제 위험 감소시키기 위해 별도로 만드는 간단한 프로그램
  처리할 문제 외 다른 조건은 모두 무시하고 작성
• 이터레이션(iteration): 하나의 릴리즈를 더 세분화 한 단위
  1-3주 정도의 기간으로 진행한다.
  기간동안 새로운 스토리가 작성될 수도 있고 작성된 스토리는 진행중인 이터레이션 혹은 다음 이터레이션에 포함
• 승인 검사(Acceptance Test,인수 테스트): 사용자 스토리 작성시 함께 기재한 테스트 사항에 대해 고객이 직접 테스트를 수행한다.
  테스트 과정에서 발견한 오류사항은 다음 이터레이션에 포함한다.
• 소규모 릴리즈: 소규모로 릴리즈하여 고객 반응을 기능별로 확인할 수 있어 고객의 요구사항에 유연하게 대응할 수 있다.

3-2 XP의 주요 실천 방법

• Pair Programming: 함께 개발, 함께 책임하는 환경
• Collective Ownership(공동 코드 소유): 개발 코드에 대한 권한과 책임 공동으로 소유
• Test Driven Development: 실제 코드 작성전 테스트 케이스 먼저 작성하고 무엇을 진행할지 파악, 자동화된 테스팅 도구를 사용한다.
• Whole Team(전체 팀): 개발에 참여하는 모든 구성원은 자신의 역할이 있고 그 역할에 책임진다.
• Continuous Integration(계속적인 통합): 모듈 단위로 나눠 개발된 코드는 지속적으로 통합된다.
• Design Improvement 또는 Refactoring: 기능 변경 없이 단순화, 유연성 강화등 통해 시스템 재구성
• Small Realeases: 릴리즈 기간 짧게하여 고객 요구 변화에 신속히 대응