[요구사항 확인] Software Life Cycle

Software Life Cycle

소프트웨어 생명 주기

 

[ 소프트웨어 생명 주기 ]

  : 소프트웨어 개발 방법론의 바탕.

  : 각 단계별 주요 활동과 그에 대한 산출물로 표현.

 

[ 소프트웨어 생명 주기 모형 ]

  · 폭포수 모형(Waterfall Model)

    : 고전적 생명 주기 모형.

    : 선형 순차적 모형.

    : 구조적 방법론 기반.

        → 절차 지향의 SW 방법론.

    : 이전 단계로 돌아갈 수 없으며, 각 단계는 병행될 수 없이 순차적으로 실행됨.

    : 제품의 일부가 될 매뉴얼을 작성해야 함.

 

Waterfall Model

 

  · 프로토타입 모형(Prototype Model)

    : 원형 모형.

    : 사용자의 요구사항을 정확히 파악하기 위해 시제품을 만드는 방식.

    : 새로운 요구사항이 도출될 때 마다 새 Prototype을 만듦.

    : 단기간 제작이 목적. → 비효율적인 언어나 알고리즘이 사용될 수 있음.

 

Prototype Model

 

  · 나선형 모형(Spiral Model)

    : 점진적 모형.

    : 폭포수 모형과 프로토타입 모형의 장점을 합치고, 단점을 보완.

    : 소프트웨어 개발 단계의 위험 최소화. (위험 분석 단계 추가)

    : 점진적으로 개발이 반복되어 요구사항 첨가가 용이하며 별도의 유지 보수가 필요하지 않음.

 

Spiral Model

 

  · 애자일 모형(Agile Model)

    : 고객의 요구사항 변화에 유연하게 대처하기 위한 방식.

    : 일정한 주기를 반복.

        → 이 주기를 각각 Scrum에서 Sprint, XP에서 Iteration이라고 부른다. )

    : 반복되는 일정 주기가 끝날 때마다 테스트를 진행.

 

Agile Model

 

    - 스크럼(Scrum)

      : 애자일 모형을 기반으로 한 방법.

      : 팀 중심으로 개발 효율을 높이는 것을 목표. (작은 규모의 자율적인 팀 강조)

      : Self-Organizing과 Cross-Functional을 만족해야 함.

          → Self-Organizing : 팀원 스스로가 스크럼 팀을 구성.

          → Cross-Functional : 개발 작업에 관한 모든 것을 팀 스스로 해결.

      ▶ 스크럼 팀 구성

        1) 제품 책임자(Project Owner)

          : 이해관계자 중 제품에 대한 이해도가 가장 높은 사람.

          : 의사결정 담당. → 개발 의뢰자 또는 사용자

          : 백로그 작성 및 우선순위 지정 및 갱신.

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

          : 스크럼 팀 총괄 역할.

          : 객관적인 시각에서 팀원들에게 조언을 함.

          : 일일 스크럼 회의 주관.

          : 개발 과정의 장애 요소 공론화 및 처리.

        3) 개발팀(Development Team)

          : PO와 SM을 제외한 모든 팀원.

          : 개발자 외에도 디자이너, 테스터 등 모든 사람이 대상.

      ▶ 스크럼 개발 프로세스

        1) 스프린트 계획 회의

          : 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립.

          : 요구 사항(User Story)을 나눠 작업 단위인 Task로 나눈 후, 스프린트 백로그 작성.

        2) 스프린트

          : 실제 개발 과정. 보통 2~4주.

          : Task를 대상으로 속도(Velocity) 추정 및 Task 할당.

        3) 일일 스크럼 회의

          : 모든 팀원이 매일 짧은 시간 동안 진행 상황 점검.

          : 남은 작업은 시간 소멸 차트에 표시.

        4) 스프린트 검토 회의

          : 요구사항에 부합하는지 테스트.

          : PO에게 피드백을 받고 백로그를 최신화하는 단계.

        5) 스프린트 회고

          : 스프린트 주기를 회고하며 개선점을 기록.

          : 스프린트가 끝난 시점 또는 일정 주기마다 시행.

 

Scrum Process

    - 익스트림 프로그래밍(eXtreme Programming)

      : 애자일 모형을 기반으로 한 방법.

      : 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 SW를 빠르게 개발하는 것을 목표.

      : Release의 주기를 짧게 해 요구사항 반영이 빠르게 이루어짐을 보여줌.

      : Release 테스트마다 고객이 직접 참여하여 피드백을 함.

      : 소규모 인원의 개발 프로젝트에 효과적.

      ▶ XP의 핵심 원칙

        1) 의사소통(Communication)

        2) 단순성(Simplicity)

        3) 용기(Courage)

        4) 존중(Respect)

        5) 피드백(Feedback)

      ▶ XP 개발 프로세스

        1) 요구사항(User Story)

          : 요구사항을 간단한 시나리오로 표현.

        2) 릴리즈 계획 수립

          : 부분 혹은 전체 완료 시점에 대한 계획 수립.

        3) 스파이크(Spike)

          : 요구사항의 신뢰성을 높이고 위험을 감소시키기 위한 별도의 간단한 프로그램.

          : 처리할 문제 외의 조건은 모두 무시.

        4) 이터레이션(Iteration)

          : Release를 더 세분화한 단위.

          : 보통 1~3주의 기간.

          : 새로운 요구 사항이 작성될 수 있음.

        5) 승인 검사

          : Release 단위의 제품이 구현되면 테스트 하는 단계.

          : 고객이 직접 테스트를 수행.

          : 오류 사항은 다음 Iteration에 포함.

        6) 소규모 릴리즈(Small Release)

          : 고객의 반응을 기능별로 확인하여 요구사항에 유연하게 대처하도록 하는 단계.

          : 최종 릴리즈나 다음 릴리즈를 위한 개발로 넘어감.

 

XP Process

      ▶ XP 주요 실천 방법

        1) Pair Programming

          : 타인과 함께 프로그래밍을 진행하여 개발 공동 환경 조성.

        2) Collective Ownership

          : 개발 코드에 대한 권한과 책임을 공동으로 소유.

        3) Test-Driven Development

          : 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하여 목표를 명확히 하도록 함.

          : 지속적인 테스팅을 위해 자동화된 테스팅 도구 사용.

        4) Whole Team

          : 개발 팀원은 각자 자신의 역할이 있고, 이에 대한 책임을 지녀야 함.

        5) Continuous Integration

          : 코드는 모듈 단위로 나누어 작업되며, 마무리 될 때 마다 통합하도록 함.

        6) Design Improvement

          : 기능 변경 없이 디자인을 개선하여 유연성과 단순성을 높임.

        7) Small Releases

          : Release 기간을 짧게 반복하여 요구 변화에 신속히 대응하도록 함.

 

 

사진 출처 : ecomputernotes.com, sketchbubble.com