SW설계 - SW 생명주기

소프트웨어 생명 주기(Software Life Cycle)란?

소프트웨어 생명 주기는 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것.
소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 활동의 결과에 대한 산출물로 표현한다.

대표적인 생명주기 모형:

• 폭포수 모형(Waterfall Model)
  - 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론. 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 하는 '선형 순차적 모형'이다.
  - '고전적 생명 주기 모형'으로도 불리며, 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모델.
  - 모형을 적용한 경험과 성공 사례가 많음.
  - 단계: 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현(코딩) -> 시험(검사) -> 유지 보수
  

• 프로토타입 모형(Prototype Model, 원형 모형)
  - 사용자의 요구사항을 파악하기 위해 실제 개발될 소프트웨어에 대한 Prototype(견본품)을 만들어 최종 결과물을 예측하는 모형.
  - 견본품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발.

• 나선형 모형(Spiral Model, 점진적 모형)
  - 나선을 따라 돌듯이 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형.
  - 보헴(Bhoehm)이 제안한 모형으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형.
  - 개발 과정에서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 하며, 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고 유지 보수 과정이 필요 없음.
  - 단계: (계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가) -> 반복
  

• 애자일 모형(Agile Model)
  - '민첩한', '기민함'이라는 의미로, 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기 반복을 통해 개발하는 모형.
  - 폭포수 모형과 대조적인 모형. 특정 개발 방법론이 아닌, 좋은 것을 신속하고 낭비없이 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭한다.
  - 기업 활동 전반에 걸쳐 사용.
  - 대표적인 개발 모형: 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), 기능 중심 개발(FDD, Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) ...
  - 핵심 가치:

  • 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
  • 방대한 문서보다는 실행되는 소프트웨어에 더 가치를 둔다.
  • 계약 협상보다는 고객과 협업에 더 가치를 둔다.
  • 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

스크럼(Scrum) 기법

• 팀이 중심이 되어 개발의 효율성을 높이는 기법.

• 팀원 스스로가 스크럼 팀을 구성(self-organizing)해야 하며, 개발 작업에 관한 모든 것을 스스로 해결(cross-functional)할 수 있어야 한다.

• 구성원

  • 제품 책임자(PO, Product Owner):
    • 요구사항이 담긴 Backlog를 작성하는 주체.
    • 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람으로 선정.
    • 제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위를 갱신함.
  • 스크럼 마스터(SM, Scrum Master):
    • 스크럼 팀이 스크럼을 잘 수행할 수 있도록 가이드 역할 수행. 팀원을 통제하는 것이 목표가 아님.
    • 일일 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화하여 처리.
  • 개발팀(DT, Development Team):
    • PO와 SM를 제외한 모든 팀원. 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상.
    • 보통 최대 인원은 7~8명이 적당하다.

• 개발 프로세스: 계획 -> 진행(스프린트) -> 회의 -> 검토 -> 회고
  - 제품 백로그(Product Backlog): 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록.
  - 스프린트 계획 회의(Sprint Planning Meeting): 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의.
  - 스프린트(Sprint): 실제 개발 작업을 진행하는 과정으로, 2~4주 정도의 기간 내에서 진행. 스프린트 백로그(Sprint Backlog)에 작성된 태스크를 대상으로 속도(Velocity)를 추정한 후 담당자에게 할당함.
  - 일일 스크럼 회의(Daily Scrum Meeting): 모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 점검하는 회의로, 남은 작업 시간은 소멸 차트(Burn-down Chart)에 표시함.
  - 스프린트 검토 회의(Sprint Review): 부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 사용자가 포함된 참석자 앞에서 테스팅하는 회의.
  - 스프린트 회고(Sprint Retrospective): 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부 및 개선할 점 등을 확인하고 기록함.
  

XP(eXtreme Programming) 기법

• 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법.
• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함.
• 릴리즈(Release)의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높임.
• 핵심 가치:
  - 의사소통(Communication)
  - 단순성(Simplicity)
  - 용기(Courage)
  - 존중(Respect)
  - 피드백(Feedback)
• 개발 프로세스: 계획 -> 진행(이터레이션) -> 검사(릴리즈) -> 출시
  - 릴리즈 계획 수립(Release Planning): 부분 또는 전체 개발 완료 시점에 대한 일정을 수립하는 것. 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함.
  - 이터레이션(Iteration, 주기): 실제 개발 작업을 진행하는 과정으로, 보통 1~3주 정도의 기간으로 진행됨.
  - 승인 검사(Acceptance Test, 인수 테스트): 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트.
  - 소규모 릴리즈(Small Release): 요구사항에 유연하게 대응할 수 있도록 릴리즈의 규모를 축소한 것.
• 주요 실천 방법:
  • Pair Programming(짝 프로그래밍): 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성.
  • Colletive Ownership(공동 코드 소유): 개발 코드에 대한 권한과 책임을 공동으로 소유함.
  • Teat-Driven Development(테스트 주도 개발): 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하여 자신이 무엇을 해야할지를 정확히 파악함. 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구(구조, 프레임워크)를 사용.
  • Whole Team(전체 팀): 고객을 포함해 개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 함.
  • Continuous Integration(계속적인 통합): 모듈 단위로 나눠서 개발된 코드들을 하나의 작업이 마무리 될 때마다 지속적으로 통합.
  • Refactoring(리팩토링): 프로그램 기능의 변경 없이 시스템을 재구성. (목적 - 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위해)
  • Small Release(소규모 릴리즈): 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응 가능.

소프트웨어 공학(SE, Software Engineering)이란?

소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문으로 , 여러 가지 방법론과 도구, 관리 기법들을 통해 소프트웨어의 품질과 생산성 향상을 목적으로 한다.

SE의 기본원칙:

• 현대적인 프로그래밍 기술을 계속적으로 적용해야 된다.
• 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 한다.
• 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.