소프트웨어 설계 - 소프트웨어 생명주기 모형, Scrum 요점정리

이번에 정보처리기사를 준비하면서, 필기 내용이 방대하다보니, 

제가 다시 공부하기 위한 목적으로 요점정리를 업로드합니다.

 

아무래도, 공부 목적으로 업로드하는 것이다보니, 내용이 조금 부족할 수 있다는 점 양해 부탁드립니다.

 

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

 

• 소프트웨어 개발 방법론의 바탕
• 개발하기 위해 정의하고, 운용, 유지보수 등의 과정을 단계별로 나눈 것
• 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형, 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임이라고 칭함
• 대표적인 소프트웨어 생명 주기 모형에는 폭포수 모형(Waterfall), 프로토타입 모형(Prototype), 나선형 모형(Spiral), 애자일 모형(Agile) 등이 있다.
  
  

소프트웨어 공학 기본 원칙

 

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

폭포수 모형(Waterfall Model)

 

• 가장 오래되고 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형, 고전적 생명 주기 모형이라고도 함
• 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형(Linear Sequential Model)
• 제품의 일부가 될 메뉴얼을 작성해야 함
• 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현 -> 시험 -> 유지보수 순으로 진행
  
  

프로토타입 모형(Prototype Model)

 

• 사용자의 요구사항이 명확하지 않을 때 활용
• 실제 개발될 소프트웨어에 대한 프로토타입을 만들어 최종 결과물을 예측
• 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
• 개발이 다 끝난 후에 오류가 발견되는 Waterfall 방식의 단점을 보완
  
  

나선형 모형(Spiral Model)

 

• Boehm(보헴)이 제안한 것으로, Waterfall과 Prototype의 장점에 위험 분석 기능 추가
• 나선처럼 여러 번이 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 소프트웨어를 개발, 점진적 모형
• 소프트웨어 개발시 발생하는 위험을 관리하고 최소화 하는 것이 목적
• 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가 순으로 반복 진행하며 유지보수 과정 필요 X
  

애자일 모형(Agile Model)

 

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하며 개발과정 진행
• 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 모든 방법론을 통칭
• Sprint또는 Iteration이라고 불리는 짧은 개발 주기를 반복하며, 주기마다 고객에게 평가와 요구를 적극 수용
• 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합
• Scrum, XP, 칸반, Lean, 크리스탈, ASD, 기능 중심 개발(FDD), DSDM,  DAD등이 애자일 모형 기반
  

 

Scrum(스크럼)

 

• 팀원 스스로가 스크럼 팀을  구성(Self-Organizing)해야 하며 개발 작업에 관한 모든 것을 스스로 해결(Cross-functional)할 수 있어야 한다.
• 제품 책임자(PO; Product Owner), 스크럼 마스터(SM; Scrum Master), 개발팀 (DT; Development Team) 구성
• 제품책임자?
  - 이해관계자들 중 개발될 제품에 대한 이해도가 높고 요구사항을 책임지고 의사결정할 사람
  - 이해관계자들의 의견을 종합하여 제품에 대한 요구사항 작성을 진행하는 주체
  - 요구 사항이 담긴 백로그(Backlog)를 작성하고 우선순위를 지정
  - 주기적으로 요구사항의 우선순위를 갱신
  
• 스크럼 마스터?
  - 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할, 통제가 아님
  - 일일 스크럼 회의를 주관하여 진행 사항 점검 및 문제 발생 시 공론화하여 처리 진행
  
• 개발팀?
  - PO와 SM을 제외한 모든 팀원으로 개발자 뿐만 아니라 디자이너, 테스터등이 모두 포함된다.

 

스크럼 개발 프로세스

• 제품 백로그(Product Backlog)
  - 제품 개발에 필요한 모든 요구사항(User Story)을 우선 순위에 따라 나열한 목록
  - 개발 과정에서 새롭게 도출되는 요구사항으로  지속적 업데이트
  - 제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획 수립
• 스프린트 계획 회의(Sprint Planning Meeting)
  - 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정 수립
  - 스프린트에서 처리할 User Story를 개발자들이 나눠서 작업할 수 있도록 Task라는 단위로 분할, 개발자 별로 수행할 작업 목록인 Sprint Backlog를 작성
  
• 스프린트(Sprint)
  - 실제 개발 작업을 진행하는 과정, 2~4주 정도 기간
  - 스프린트 백로그에 작성된 태스크를 대상으로 작업 시간을 추정한 후 개발자에게 할당
  - 할당된 Task는 할 일(To Do), 진행 중 (In Progress), 완료 (Done)의 상태를 지님
• 일일 스크럼 회의(Daily Scrum Meeting)
  - 모든 팀원이 매일 약 15분 정도의 짧은 시간동안 진행상황을 점검
  - 남은 작업 시간은 소멸 차트(Burn-Down Chart)에 표시
• 스프린트 검토 회의(Sprint Review)
  - 스프린트 산출물이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅 수행
  - 제품 책임자(PO)는 개선할 사항에 대한 피드백 정리 후 반영하여 제품 백로그 업데이트
• 스프린트 회고(Sprint Retrospective)
  - 스프린트 주기를 되돌아보며 규칙 준수 여부, 개선점 확인 및 기록
  - 스프린트 마치고 수행하거나 일정 주기로 수행