미완성 블로그입니다

[TOC]

소프트웨어 프로세스

소프트웨어 시스템을 개발하는 데 필요한 일련의 체계적인 활동

다양한 소프트웨어 개발 프로세스가 있지만 모두 다음 과정을 포함합니다.

  • Specification: 시스템이 무엇을 해야 하는지 정의 (요구사항 엔지니어링 프로세스)
    • RE (Requirements Engineering) : 필요한 서비스(FR)와 시스템 운영, 개발에 대한 제약 조건(NFR)을 파악하는 프로세스
    • 요구사항의 명세, 상세 정의(검증), 유효성 확인
  • Design / Implementation: 시스템 구성을 정의하고 시스템을 구현(대부분의 시스템에서 설계와 구현은 상호 연계)
    • 소프트웨어를 설계하고, 시스템 사양을 실행 가능한 시스템으로 변환(구현)하는 과정
    • 아키텍처 설계 - 시스템의 전체 구조, 하위 시스템/모듈 등 주요 구성 요소와 각 요소의 관계 및 배포 방식 파악 (ISO/IEC/IEEE 42010:2011)
    • 프로그래밍: 표준 프로세스가 없는 개별 활동 (클린 코드+리팩토링+단위 테스트)
    • 디버깅: 프로그램 오류를 찾아 수정 (테스트와는 다름)
  • Validation: 고객의 요구사항대로 작동하는지 확인
    • Verification and Validation (V & V): 시스템이 사양을 준수하고(Verification) 요구사항을 충족함을 보여주는 것(Validation)을 목표
    • (static) 코드 검사, (dynamic) 검토 및 시스템 테스트를 포함
    • 테스트는 가장 일반적인 V&V 활동 : IEEE 1012-2016
    • 테스트에는 단위 테스트, 시스템 테스트, 인수 테스트가 있다.
  • Evolution: 변화하는 요구에 맞추어 시스템을 변경
    • 소프트웨어는 본질적으로 유연하며 변화 가능 (S3M : SW Maintenance Maturity Model)

Software (Develop) Process Model : 소프트웨어 프로세스를 추상적으로 표현한 것으로, 다양한 관점에서 프로세스를 설명합니다.


프로세스 개선

기존 프로세스를 이해하고 이를 변경하여 제품 품질을 향상시키거나, 비용과 개발 시간을 단축합니다.

  • CMMi 와 같은 프로세스 성숙도 수준은 조직의 소프트웨어 개발 프로세스에 우수한 기술 및 관리 관행이 얼마나 도입되었는지를 반영합니다.

  • 프로세스 개선 활동: 분석(Analysis), 변경(Change), 측정(Measurement)

    • 프로세스 분석: 현재 프로세스 평가, 취약점과 병목현상 파악 - 프로세스를 설명하는 프로세스 모델(맵)을 개발 가능

    • 프로세스 변경: 파악된 프로세스 취약점 중 일부를 해결하기 위해 제안 - 변경 사항을 도입하고 변경의 효과에 대한 데이터를 수집하기 위해 주기를 재개(cycle resumes)

    • 프로세스 측정: 소프트웨어 프로세스 또는 제품의 하나 이상의 속성을 측정 - 프로세스 개선이 효과적이었는지 판단하는 데 도움이 되는 기준 제공

      • 가능하다면, 정량적 데이터를 수집해야 함
      • 하지만 현실적으로 명확하게 정의된 프로세스 표준을 확립하지 못한 경우가 많음
      • 측정이 가능하기 전에 프로세스를 정의해야 하며, 조직의 목표는 프로세스 개선을 이끌어내야 함
      • 프로세스 지표의 예시: 소요 시간(캘린더 시간, 노력), 자원(person-days), 이벤트 발생 횟수(발견된 결함 수)

​

  • CMMi (Capability Maturity Model Integrated)


    500px-Characteristics_of_Capability_Maturity_Model.svg_

    https://www.servicedeskacademy.com/cmmi-capability-maturity-model-integration/

    • CMU의 SEI에서 개발
    • 개발(Development), 서비스(Service), 획득(Acquisition) 등 여러 분야의 CMM 모델을 통합(integrated)
    • 소프트웨어 품질 향상 + 생산성 증가 + 개발 프로세스 표준화 를 목표
    • 조직의 개발 프로세스가 얼마나 성숙(mature)했는지를 5단계로 평가하는 프로세스 개선 모델
      1. Initial : 본질적으로 통제되지 않음
      2. Repeatable(반복 가능) : 제품(프로젝트) 관리 절차가 정의되고 사용
      3. Defined : 프로세스 관리 절차와 전략이 정의되고 사용됨
      4. Managed : 품질 관리 전략이 정의되고 사용됨
      5. Optimizing : 프로세스 개선 전략이 정의되고 사용됨


소프트웨어 개발방법론

소프트웨어 개발 ≈ 컴퓨터에서 작동하는 소프트웨어로 문제 해결 ①②③

① 문제를 자연어로 정의

② 프로그래밍 언어로 기술

③ 컴퓨터 시스템을 통해 프로그램 실행


절차적 프로그래밍 (Procedural Programming)

  • 프로그램은 절차로 구성
  • 절차/함수 는 절차적 프로그래밍의 구성 요소로, 변수 값을 변경하는 명령문
  • 자료 구조, 알고리즘, 단계 순서에 포커싱
  • C에서 FORTRAN 까지의 대부분의 컴퓨터 언어는 절차적 프로그래밍 언어에 해당
  • SASD(Structured Analysis and Structured Design, 구조적분석설계 개발방법론)
    • 절차적 프로그램을 위한 전통적인 소프트웨어 개발방법론
    • 하향식 분할 정복(Top-Down Divide and Conquer)
    • DFD(Data Flow Diagram)을 사용하여 문제에 대한 기능적 관점
    • SASD 예시: RVC Control


객체 지향 프로그래밍 (Object-Oriented Programming)

  • 프로그램은 객체로 구성
  • 객체 간 통신을 통해 시스템 기능 제공
  • 객체: 데이터와 연산으로 구성
  • 객체 통신: 객체가 자신의 데이터를 사용해 다른 객체의 연산 호출
  • 명시적인 데이터 흐름은 없고, 객체 간의 통신 순서만 있음
  • OOAD(Object-Oriented Analysis and Design, 객체지향개발방법론)
    • 요구사항 식별, 도메인 모델 생성 후 적절한 클래스에 메서드를 추가
    • 요구사항을 충족하기 위해 객체 간 메시징 정의
    • 객체지향 분석(OOA)
      • 도메인 개념, 객체 발견 (도메인 모델)
      • 요구사항 식별 (Use-Case 모델)
    • 객체지향 설계(OOD)
      • 소프트웨어 객체 정의(정적 모델에서 클래스 다이어그램)
      • 객체들의 협업 정의(동적 모델에서 시퀀스 다이어그램)
    • Waterfall, Up(Iterative) 모델을 사용 가능


소프트웨어 프로세스 모델

고품질 소프트웨어를 설계하는 데 필요한 일련의 활동, 조치, 작업, 마일스톤 등 작업 산출물을 체계적으로 정의

  • 누가, 무엇을, 언제, 어떻게, 특정 목표를 달성하는지 정의
    • SDLC (SW 개발 수명주기) 모델


주로 사용되는 SDLC 모델

  • Waterfall
  • V-Model
  • Evolutionary - Prototype, Sprial
  • Phase (Incremental, Iterative)
  • CBD(Component-Based Development)
  • Iterative - Agile
  • Iterative - RUP (Rational Unified Process)


Waterfall (폭포수) 모델

waterfall-model

출처: https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/

  • 폭포수 모델은 1960년대 제안된 고전적인 소프트웨어 생명주기 모델
  • 선형적 Top-Down 방식의 체계적이고 순차적인 접근 방식을 제시하며, 각 단계를 구분
  • 원칙적으로 다음 단계로 넘어가려면, 이전 단계를 완료해야 하며 거슬러 올라갈 수 없음
  • 다만, 프로젝트를 여러 단계로 분할하는 것은 고객 요구사항 변화에 대응하기 어려움


폭포수 모델의 프로세스 단계

  1. 요구사항 분석 및 정의
    • 시스템 사용자와의 면담 등을 통해 시스템의 서비스, 제약 조건과 목표를 설정하며 설정된 내용은 구체화 후 시스템 명세서로 사용
  2. 디자인 및 설계
    • 요구사항을 HW, SW 시스템으로 구분하여 할당
    • 전체 시스템 아키텍처 작성
    • 소프트웨어 설계는 기본적인 시스템 추상화와 이들 간 관계를 파악하고 기술하는 활동 포함
  3. 구현 및 테스트
  4. 통합과 시스템 테스팅
    • 개별 프로그램 단위나 프로그램을 통합하고 전체 시스템 검사
    • 테스트 후에는 고객에게 소프트웨어 전달
  5. 운영과 유지보수
    • 일반적으로, 가장 긴 생명 주기 단계로 시스템이 설치되고 실제로 사용된다
    • 유지보수는 오류 수정 및 새로운 요구사항 발견을 포함한다


어떨 때 폭포수 모델을 사용하는 것이 유리한가?

  • 요구사항이 조기에 수정되는 경우
  • 작업이 선형적으로 완료될 수 있거나 완료되어야 하는 경우
  • 여러 사이트에서 시스템이 개발되는 대규모 시스템 엔지니어링 프로젝트
  • 즉, 요구사항이 충분히 이해되고 일찍 정의,수정되며, 변경이 제한적인 상황에서 유리


V 모델

v-model

출처: https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/

  • 폭포수 모델의 변형으로, 테스트 단계를 추가 확장
  • 각 개발 단계의 검증을 통해 오류를 줄일 수 있다.
  • 분석, 설계 단계는 왼쪽에 나타내고, 테스트는 오른쪽에 나타낸다. 구현은 가장 아래 꼭지점에 위치한다.


Evolutionary Process 모델


evolutionary-process-model

출처: https://www.geeksforgeeks.org/software-engineering/what-are-evolutionary-process-models/


소프트웨어 엔지니어링에서 진화 모델은 일련의 반복 또는 릴리즈를 통해 소프트웨어 시스템을 개발하는 반복적이고 점진적인 접근 방식입니다.

기존 폭포수 모델은 이미 완료된 단계를 거슬러 올라가기 쉽지 않으며, 요구사항이 자주 변하는 상황에서는 부적절하였지만,
진화적 프로세스 모델이서는 변화하는 요구사항에 맞추어 시간이 지남에 따라 진화하고 개선될 수 있습니다.

  • 초기 요구사항이 완전히 이해되지 않았거나 개발 과정에서 변경될 수 있는 소프트웨어 프로젝트에서 유용합니다.
  • 반복적인 개발을 통해 지속적으로 개선 및 향상시킴으로써, 최종 제품이 요구사항을 충족하도록 보장합니다.
  • 프로토타입을 사용하면, 개발자와 사용자 간의 의사소통 도구로도 활용되어 사용자의 요구를 충분히 반영 및 개선할 수 있습니다.


나선형 모델

spiral-model

출처: https://www.geeksforgeeks.org/software-engineering/what-are-evolutionary-process-models/

  • 진화 모델의 일종으로, 1986년 Barry Boehm 이 처음으로 제시

  • 위험 분석이 추가된 폭포수 모델의 반복 버전 이라고도 할 수 있음

  • 나선형의 각 루프는 소프트웨어 개발 프로세스의 단계(Phase) 에 해당

    • 매 단계별 초기 요구분석 후 프로토타입 개발 이전 단계에 위험 분석 단계를 거침
    • 프로토타입을 사용자가 평가한 후, 수정 요구를 반영해 2차, 3차, … 프로토타입을 반복해서 만듬

  • 위험 요소란 소프트웨어 개발 과정에서 Interrupt 가 되는 모든 것 (인력 부족 등의 문제도 포함)

  • 변화와 위험에 충분히 대응 가능하지만, 프로젝트 기간 및 관리, 비용 측면에서는 회의적


Phase Process (단계적 프로세스 모델)


incremental-model

출처: https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/

예를 들어, 개발자가 v1.0.0을 개발해 사용자에게 제공하면, 사용자가 이를 사용하는 동안 개발자는 다음 버전인 v1.0.1을 개발한다.
이런 식으로 개발과 사용을 병행하는 모델을 단계적 프로세스 모델이라고 한다.

  • 단계적 개발 모델은 Incremental 방식과 Iterative 방식으로 구분할 수 있다.


Incremental vs Evolutionary Model

  • 점진적 및 진화적 개발 : 여러 단계가 병렬로 개발되며, 나중에 통합됩니다.
    • 점진적 개발: 최종 버전이 최종적으로 제공됩니다. (시스템을 여러 기능 단위로 나누어 단계적으로 완성)
    • 진화적 개발: 고객에게 유용한 소프트웨어를 더욱 신속하게 제공하고 배포 가능 (초기 버전을 빠르게 제공)
    • 고객에게 유용한 소프트웨어를 더욱 빠르게 전달하고 배포하는 것이 가능합니다.
  • 프로세스는 Invisible 합니다.
    • 여러 단계가 동시에 개발되며, 문서화가 어렵습니다.
  • 시스템 구조는 새로운 기능이 추가됨에 따라 degrade 되는 경향이 있습니다.
    • 정기적인 변경은 시스템의 구조를 corrupt 시키는 경향
    • 추가적인 소프트웨어 변경을 통합하는 것은 점점 더 어렵고 비용이 많이 듬

점진적 개발 모델의 예시

  1. 은행 시스템 개발: 단계별로 기능을 추가하고, 전체 시스템 완성 시 통합하는 경우
    1. Increment 1: 계좌 조회 및 이체 기능
    2. Increment 2: 대출 및 이자 계산 기능
    3. Increment 3: 신용카드 관리 및 결제 기능
  2. 쇼핑몰 웹사이트: 각 단계별 완성도 높은 기능을 순차적으로 추가
    1. Increment 1: 회원가입 / 로그인
    2. Increment 2: 상품 검색 및 장바구니 기능
    3. Increment 3: 결제 및 주문 내역 조회


진화적 개발 모델의 예시 : 대규모 복잡한 서비스 개발에 유리합니다.

  1. 챗 봇 시스템 개발
    1. 1차 프로토타입: 기본 질의응답만 지원
    2. 사용자의 피드백 반영 - 자연어 이해 개선
    3. 대화 이력 저장, 감정 분석 등 고도화 - 매 단계에서 사용자와의 피드백을 통해 시스템이 진화
  2. 모바일 앱 스타트업 MVP 개발
    1. 초기에 핵심 기능만 구현한 MVP 출시
    2. 사용자 반응을 바탕으로 UI / UX, 기능 개선
    3. 여러 버전을 거쳐 점진적 고도화


같은 예시에서 두 방식 비교

점진적 개발 모델: 전공서적을 집필할 때 챕터 1부터 자세히 작성한다.

진화적 개발 모델: 전공서적의 모든 챕터를 요약한 1차 원고를 작성하고, 이후 단계적으로 내용을 보충한다.


CBD(Component-Based Development)

재사용 기반 소프트웨어 개발 프로세스

  1. 요구사항 명세화
  2. 소프트웨어 발견 및 평가
  3. 요구사항 정제
  4. 애플리케이션 시스템 설정: 사용 가능한 애플리케이션 시스템이 있다면
  5. 컴포넌트 수정과 통합: 사용 가능한 컴포넌트가 있다면
  6. 시스템 통합

  • CBSE 라고도 하며 (도메인 엔지니어링과 병행하는), 느슨한 결합과 컴포넌트의 재사용을 추구

  • 재사용 가능한 소프트웨어 컴포넌트를 사용하여 시스템의 설계 및 개발에 중점을 두는 프로세스
  • 나선형 모델의 다양한 특징을 활용하며, 본질적으로 진화적

  • 컴포넌트는 독립적인 서비스를 제공하는 소프트웨어 모듈

  • Advantage
    • 재사용을 통해 비용과 위험 감소
    • 시스템 제공 및 및 배포 속도 빨라짐
  • Disadvantage
    • 요구 사항 웨손 불가피 - 실제 요구를 충족하지 못할 수 있음
    • 재사용되는 시스템 요소의 진화에 대한 통제 상실


RUP (Rational Unified Process) - Iterative

rup_over

https://setgetweb.com/p/portal61/RAD75/14-02.htm


  • Rational 사(현재 IBM)의 객체 지향 기반 소프트웨어 개발 프로세스 모델로, UP 이라고도 한다.
  • 4개의 단계와 9개의 disipline(개발 영역)이 존재한다.
    • 4 phase: 도입(inception), 구체화(elaboration), 구축(construction), 전이(transition)
    • 9 disipline: 비즈니스 모델링, 요구사항 정의, 분석&설계, 구현, test, batch/deployment, 변화 관리, 프로젝트 관리, 환경 점검
  • 반복적(점진적, 진화적)
    • 각 반복에는 3-4주 단위의 작은 폭포수 주기 포함
    • 구현 단계의 초기 반복 작업은 핵심 아키텍처 구축, 테스트 및 안정화에 중점
  • 위험 중심, 고객 중심, 아키텍처 중심
    • 아키텍처 측면에서 높은 위험을 파악하고 감소시킴
    • 고객이 가장 용요하게 생각하는 가시적 기능 구축
  • Use-case 중심
  • 객체 지향 소프트웨어 개발을 위한 사실상의 산업 표준



Agile (애자일 프로세스 모델) - Iterative

신속한 소프트웨어 개발

  • 신속한 개발 및 제공은 이제 소프트웨어 시스템에 있어 가장 중요한 요건이 되었음
  • 소프트웨어는 변화하는 비즈니스 요구를 반영하기 위해 빠르게 발전해야 함
    • 계획 기반 개발은 이러한 요구를 충족하기 어려움
  • 1980-1990년대 기존 소프트웨어 설계 방식(폭포수 모델)에 대한 불만이 지속적 제기됨
    • 프로세스의 간접 비용을 줄이고, 과도한 재작업 없이 변화하는 요구사항에 신속 대응할 필요성도 제기
  • 애자일 개발 방법은 1990년대 후반에 등장하여 작동 중인 소프트웨어 시스템의 제공 시간을 획기적으로 단축 (단, 실제 선언은 2001년에 이루어짐)
    • 시스템은 이해관계자가 참여하는 일련의 버전 또는 Increment로 개발
    • 자동화 테스트 도구 등 광범위한 도구 지원
    • 평가를 위해 새로운 버전을 자주 제공
    • 문서를 최소화하고, 디자인보단 코드 작동에 집중

  • Plan-Driven(Waterfall) 방식과 비교하면 Requirement specication(요구사항 명세화) 과정이 생략되고 바로 설계 및 구현 단계에 들어감

  • 애자일 프로세스 모델은 반복(Iterative) 모델의 한 형태

the-agile-umbrella-1

  • Agile (애자일) 의 사전적 의미는 날렵한, 민첩한
    • 소프트웨어에서 증분 전달, 팀 공동 작업, 지속적 계획 및 지속적 학습을 강조하는 소프트웨어 개발에 대한 접근 방식을 설명
  • 2001년 선언된 소프트웨어 개발 방법론으로, 기존의 폭포수 개발 방법론의 탈피를 선언
    • 프로세스 및 도구보다, 개별적인 접근 방식
    • 문서화보단 소프트웨어의 실제 동작을 우선
    • 계약과 협상보다, 고객 우선
    • 계획 준수보다, 변화에 대한 대응

애자일 소프트웨어 개발 선언 전문

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

애자일 선언문

  • 요구사항이 개발 후반부에 추가 및 수정되더라도, 바로 받아들여 대응한다.

  • 사용하는 증가분이 적은 점증적 개발 방법으로, 최소 2-3주마다 새로운 시스템을 만들어 사용
  • 개발 과정에서 직접 만나서 대화하는 것을 우선
  • 한마디로 말하면 계획과 문서와 같은 산출물 대신, 실시간으로 추가되는 요구사항에 민첩하게 대응하고 문제를 해결해나가는 방법론
    • 폭포수 모델이 철저한 계획 중심이라면, 애자일 모델은 능동적이고 그때그때 반응하는 것이다. 처음에는 폭포수 계획보다 완성도가 떨어질 지 몰라도, 시간이 지남에 따라 완성도가 점점 높아지는 방식이다.
  • 현재 거의 모든 소프트웨어 제품과 애플리케이션은 이제 애자일 방식을 사용하여 개발됨
  • 조직 내 맞춤형 시스템 개발: 고객의 명확한 참여 의지, 소프트웨어에 영향을 미치는 외부 규칙 및 규정이 거의 없음


애자일(Agile) vs 데브옵스(Dev-Ops)

  • 애자일은 빠른 대응과 변화 대응을 목표
    • 데브옵스는 개발과 운영의 협업 및 자동화를 통한 지속적 배포 문화
  • 애자일은 품질 높은 소프트웨어를 반복적으로 제공하는 것을 목표
    • 데브옵스는 코드 개발 후 신속하고 안정적인 운영 및 배포에 중점(CI, CD)
  • 애자일의 핵심 철학은 작게, 빠르게, 자주 개선, 개발 프로세스의 상위 철학
    • 데브옵스의 철학은 지속적 통합(CI)와 지속적 배포(CD), 애자일 철학을 운영 단계까지 확장한 실행 문화

요약하자면 애자일은 개발 과정의 민첩성 향상, 데브옵스는 개발 이후의 빠르고 안정적인 운영, 배포에 포커싱을 한다.


여러 애자일 방법론

  • 스크럼 (scrum)
  • eXtreme Programming (XP) - TDD를 포함
  • crystal family
  • 동적 시스템 개발 방법론(DSDM)
  • 적응형 소프트웨어 개발(ASD)
  • lean 소프트웨어 개발
  • 지능 주도 개발론(FDD)
  • Agile UP


애자일 프로젝트 관리자

  • 소프트웨어 프로젝트 관리자의 주요 책임은 프로젝트를 관리하여 소프트웨어가 정해진 기간 내에, 그리고 계획된 예산 내에서 제공되도록 하는 것
  • 프로젝트 관리의 표준 접근 방식은 계획 중심
    • 관리자는 무엇을, 언제 제공해야 하는지, 누가 프로젝트 결과물 개발을 담당할지를 포함흐는 계획을 수립합니다
  • 애자일 프로젝트 관리에는 다른 접근 방식이 필요
    • 점진적 개발 및 애자일(개발) 방법론에 사용되는 관행에 맞게 조정되어야 함
    • 스크럼(Scrum)


애자일 방법론 - 스크럼 (scrum)

  • 팀과 반복적인 개발 관리에 중심을 둔 애자일 방법론
  • 약 1달 정도의 개발 주기(스프린트) 설정, 각 주기별로 실제 결과물을 제공
  • 개발팀은 7명을 넘지 말아야 하며, 소프트웨어와 다른 문서 작성에 대한 책임을 가진다
  • 각 개발 주기마다 적용할 기능이나 개선점에 대한 목록 작성
  • 매일 15분씩 일일 스크람 회의를 진행하여 진행 상황 공유
    • 서서 하며, 진행 상황만 점검, 모든 팀원 참석
  • 스프린트 기간 개발 완료하면 검토 회의나, 스프린트 회고(retrospective)를 한다

스크럼의 3단계

Initial phase

  • 프로젝트의 전반적인 목표를 설정하고 소프트웨어 아키텍처를 설계하는 개략적인 계획 단계

A series of sprint cycles

  • 각 사이클은 시스템의 증분(increment)을 개발
  • 스프린트당 2-4주 (때때로 1-2주일 경우도 있음)

Project closure phase

  • 프로젝트를 마무리하고, 필요한 문서를 작성하고, 프로젝트에서 얻은 교훈을 평가



Term Features
Product backlog 우선순위가 매겨진, 개발할 제품의 요구사항을 나열한 목록 (To-do)
사용자 스토리를 통해 각 가능을 서술하며, 일반적으로 작성된 목록은 주기가 끝날 때까지 사용
Sprint 반복적인 개발 주기로, 일반적으로 1-4주 정도를 스프린트 기간으로 설정한다.
팀 전체가 회의하여 스프린트의 목표를 설정하며, 각 스프린트 끝에는 실행 가능한 결과물을 도출한다.
Sprint backlog 특정 스프린트(개발 주기) 동안 팀이 수행하기로 약속한 작업 목록
Increment (증분 결과물) 스프린트가 끝났을 때 실제로 완성된, 동작 가능한 소프트웨어 결과물
Product owner 제품 백로그(Product Backlog) 작성 및 우선순위 관리
스프린트 목표 설정 및 팀에게 명확한 방향 제시
Scrum Master 스크럼 이벤트(데일리 스크럼, 회고, 스프린트 계획 등) 원활히 진행하도록 지원,
팀의 장애 요소(Impeding factor) 제거, 팀이 스크럼을 따르도록 지원
Scrum 일일 회의, 진행 상황을 (전체 팀이 대면으로 참여하여) 검토하고 그날 할 작업의 우선순위를 정하는 자리


애자일 방법론 - XP (eXtreme Programming)

  • 1996년 Kent Beck 이 처음으로 제안
  • 애자일 방법론의 한 형태로, 코드 작성에 중점을 두고 문서 작성을 최소화
  • 1-3주의 개발주기로 릴리즈 권장, 5가지 핵심 가치와 12가지의 실행 관행을 기반으로 실천


XP의 5가지 핵심 가치

가치 Feature
용기 설계에 얽매여 다른 것을 구현하는 데 많은 노력이 필요하지 않도록 하기 위한 노력과
쓸모없는 코드를 과감하게 제거하는 것도 용기에 포함
존중 항상 높은 품질을 추구하며 자신에 대한 자존감 고취와 타인에 대한 존중 기초
높은 수준의 동기 부여를 보장하고 팀과 프로젝트 목표에 대한 충성심을 고취
피드백 시스템으로부터의 피드백, 의사소통에 따른 고객으로부터의 피드백, 팀의 피드백 강조
“낙관주의는 프로그래밍의 직업병입니다. 피드백은 해결책입니다.”
단순성 불확실한 미래의 요구 사항에 맞춰 코딩하고 설계하지 않음
핵심 기능에 집중하며 불필요한 기능은 과감히 배제
의사소통 모든 개발자에게 시스템 사용자의 관점과 동일한 시스템에 대한 공통된 관점을 제공하는 것
개발팀 구성원과 사용자 간 의사소통 강조

XP의 실천 사항

  • 미세한 피드백
    • Pair Programming
    • 계획 세우기
    • Test Driven Dev (TDD)
    • Whole team: 실제 고객이나 사용자 대표가 팀과 함께 상주하여 피드백 제공
  • 연속 프로세스
    • 지속적 통합(CI)
    • 지속적 리팩토링 또는 디자인 개선
    • 작은 릴리즈
  • 공유된 이해
    • 코딩 표준
    • 공동 코드 소유
    • 간단한 디자인
    • 시스템 메타포
  • 복지: 작업시간 준수


XP 방법론 자체는 현재 널리 사용되지는 않음

  • 기술적 측면에 포커싱하고, 대부분의 조직에서 경영 관행과 통합하기 쉽지 않음

그러나, XP 방법은 다른 개발 방법론에서도 널리 사용됨

  • 명세를 위한 사용자 스토리
    • 카드에 작성하고, 개발팀은 구현 작업으로 나누며, 작업은 일정 및 비용 추정의 기준이 됨
    • 고객 또는 사용자는 XP 팀의 일원이며 요구사항에 대한 의사 결정을 담당
    • 고객은 다음 릴리즈에 포함할 스토리를 선택
  • 리팩토링
    • 변화를 염두에 두고 설계하는 것은 소프트웨어 공학의 통념(wisdom)
    • 변화를 예측하는 데 시간과 노력을 투자하는 것은 수명주기 후반의 비용을 절감할 수 있기 때문에 가치있는 일
    • 그러나 XP는 변화를 확실하게 예측할 수 없기 때문에 시간과 노력의 투자는 가치가 없다고 주장 - 리팩토링 제안
    • 코드가 잘 구조화되고 명확하면 변경하기가 더 쉬움
    • 중복 코드를 제거하기 위해 클래스 계층 구조를 재구성하며, 속성과 메서드를 정리하고 이름을 이해하기 쉽도록 변경, 인라인 코드를 프로그램 라이브러리에 포함된 메서드 호출로 대체
    • 리팩토링의 유형 및 수준
      • 아키텍처 > 디자인 > 코드 > 데이터

  • 테스트 우선 개발(TFD)

    • 테스트는 XP의 핵심
    • “프로그램은 모든 변경 사항이 적용된 후에 테스트되어야 합니다”
    • 하지만, 프로그래머는 테스트보다 프로그래밍을 선호하며, 테스트를 작성할 때 숏컷을 택하기도 함, 일부 테스트는 점진적으로 작성하기 매우 어려울 수 있으며, 많은 테스트들의 완전성(completeness)를 판단하기 어려움
    • XP 테스트의 특징: 테스트 우선 개발, 시나리오 기반의 증분 테스트 개발, 테스트 개발 및 검증에 사용자 참여, 자동화된 테스트 하네스(harnesses) 사용하여 모든 구성 요소 테스트 실행
    • 테스트 자동화
      • 자동화된 테스트 프레임워크가 필요 (일련의 xUnit 등)
      • 각 테스트 구성 요소는 독립적이며 테스트할 입력 제출을 시뮬레이션 해야함
      • 결과가 출력 사양을 충족하는지 확인해야 함
      • 시스템에 기능이 추가될 때마다 테스트를 실행할 수 있으며, 새 코드로 인해 발생할 문제를 CTIP(컴퓨터 프로그래밍 인터페이스)를 통해 즉시 포착 가능
      • (CTIP: Continuous Testing and Integration Platform)
    • 오늘날 TFD 철학은 발전하여 테스트 주도 개발(TDD) 기법으로 일반화 되었다.
      • 코드 작성 전에 테스트를 작성하면 요구 사항이 명확해짐
      • 테스트는 데이터가 아닌 프로그램 형태로 작성되어 자동으로 실행 가능
      • 테스트에는 테스트가 올바르게 실행됐는지 확인하는 과정 포함
      • 자동화된 테스트 실행 환경은 필수: 새로운 기능이 추가되면 이전 테스트와 새로운 테스트가 모두 자동으로 실행되어 새로운 기능이 오류를 유발하지 않았는지 확인

  • 고객 참여(Customer Involvement)

    • XP에서 고객은 팀의 일원으로 다음 릴리즈에 구현될 스토리에 대한 인수 테스트 개발을 지원, 개발이 진행됨에 따라 테스트 작성

      • 모든 새로운 코드는 고객의 요구에 부합하는지 확인하기 위해 검증됩니다.
      • 테스트 케이스 ≠ 테스트 데이터

    • 하지만 고객은 시간에 제한되어 있어 개발팀과 함께 풀타임으로 일할 수 없음

      • 요구 사항을 제공하는 것만으로도 충분하다고 생각하여 테스트 프로세스 참여를 꺼릴 수 있음 = 발생할 가능성이 있는 모든 예외를 확인하지 않는 불완전한 테스트 케이스 작성 등

      테스트 케이스 예시: Dose checking (복용량 확인)

      Input:

      1. A number of mg representing a single dose of the drug.
      2. A number of representing the number of single doses per day.

      Test:

      1. 싱글 복용량은 맞지만 빈도가 높은 경우의 입력에 대한 테스트
      2. 싱글 복용량이 높거나 낮은 경우의 입력에 대한 테스트
      3. single dose * frequency가 높거나 낮은 경우의 입력에 대한 테스트
      4. single dose * frequency가 permitted range 안에 속한 경우의 입력에 대한 테스트

      Output:

      1. OK 또는 dose(복용량)이 안전 범위를 벗어났다는 오류 메세지
  • 페어 프로그래밍
    • 프로그래머들이 짝을 지어 같은 컴퓨터에 함께 앉아 코드를 개발
      • 일부 증거에 따르면 두 명의 프로그래머가 개별적으로 작업하는 것보다 두 사람이 함께 작업하는 것이 더 효율적이라고 합니다
    • 모든 팀원이 개발 과정에서 상호협력 가능하도록 동적으로 구성
    • 이 과정에서 발생하는 지식 공유는 팀원이 떠나더라도 프로젝트의 전반적인 위험을 줄여주며 팀 전체에 지식을 확산하는 데 도움을 줌
    • 코드에 대한 공동의 소유권 확립
    • 여러 사람이 각 코드 줄을 검토하므로 비공식 검토 프로세스 역할을 함
    • 시스템 코드 개선을 통해 팀 전체가 이익을 얻을 수 있으므로 리팩토링 장려


Waterfall vs Iterative (또는 Agile) 모델 비교 분석하기

구분 Waterfall (폭포수 모델) Iterative / Agile (반복적·애자일 모델)
요구사항 계획 단계에서 거의 모든 것이 정해지므로, 추가 요구사항을 반영하기 어려움 언제든지 추가 요구사항 자유롭게 수용
완성도 시작 상태부터 높은 완성도 시작 상태에서는 완성도 낮으나, 개발이 진행되면서 높아짐
개발 과정 단계별 순차 진행 (요구 → 설계 → 구현 → 테스트 → 유지보수)
모든 단계가 명확하며, 완벽히 수행되어야 다음 단계로 넘어감
이전 단계로 돌아가기 어려움		 분석, 설계, 구현, 테스트가 매 반복 주기마다 함께 수행됨
릴리즈 모든 개발이 완료된 후에 한 번만 릴리즈 각 반복 주기마다 작동 가능한 제품을 부분적으로 릴리즈
리스크 관리 후반부에 문제가 발견되면 수정 비용이 큼 위험을 조기에 발견하고 반복 과정에서 점진적으로 해결
적합 예시 요구사항이 명확하고 변경 가능성이 적은 프로젝트
여러 사이트에서 시스템이 개발되는 대규모 시스템 엔지니어링 프로젝트		 요구사항이 불명확하거나 자주 변경되는 프로젝트
사용자 피드백을 반영해 빠르게 개선해야 하는 제품 개발(예: 웹/앱 서비스)
  • 애자일 프로세스가 폭포수 모델보다 항상 좋은 것은 아니며, 최고의 방법론이란 없습니다.
  • 실제로 대부분의 실무에서는 두 가지 방식의 요소를 섞어서 사용합니다.


참고