소프트웨어 설계-요구사항 확인

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

소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해
정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것

(Software Development Life Cycle) SDLC 라고 하거나 소프트웨어 수명 주기라고도 한다.

소프트 웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형 이라고 함.
(소프트웨어 프로세스 모형 또는 소프트웨어 공학 패러다임이라고도 한다.)

개발자는 문제의 유형이나 개발 방법 등에 따라 특정 모형을 선택하여 사용할 수도 있고, 개별적인 모형을 사용할 수도 있다.

소프트웨어 공학(Software Engineering)

소프트웨어 공학(SE)은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
여러 방법론과 도구,관리 기법들을 통하여 소프트웨어의 품질과 생산성을 향상시키는 것이 목적이다.

소프트웨어 공학의 기본 원칙

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

소프트웨어 생명주기 모형

폭포수 모형(Waterfall Model)

• 한 단계가 완전히 끝난 후에만 다음 단계로 넘어가는 선형 순차적 모형
• 가장 오래되고 가장 폭넓게 사용된 전통적인 고전적 생명 주기 모형
• 모형을 적용한 경험과 성공 사례가 많고 제품의 일부가 될 메뉴얼 작성해야 함
• 단계별 결과물이 명확/ 계획, 문서 중심
• 두 개 이상의 과정이 병행하여 수행되지 않는다.
• 개발 중간에 요구사항의 변경이 용이 x
  타당성 검토 - > 계획 - > 요구 분석 - > 설계 - > 구현(코딩) - > 테스트(검사) -> 유지보수 #분설구테유

프로토타입 모형(Prototype Model, 원형 모형)

• 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형
• 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
• 추후 구현 단게에서 사용될 골격 코드가 된다.
• 개발 중간에 요구사항의 변경이 용이
• 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형

나선형 모형(Spiral Model, 점진적 모형)

• 보헴이 제안
• 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 나선을 따라 돌듯이 개발 과정을 여러 번 수행 하여 점진적 모형이라고도 함.
• 위험 관리/최소화를 목적으로 함.
• 개발 과정
  💡 계획 수립 - > 위험 분석 - > 개발 및 검증 - > 고객 평가

애자일 모형(Agile Model)

• 애자일은 '민첩함','기민한'이라는 의미
• 고객의 요구사항 변화에 유연하게 대응
• 일정한 주기(스프린트,이터레이션)를 반복/ 주기가 끝날 때마다 테스트
• 어느 특정 개발 방법론이 아닌 좋은것을 빠르게 낭비 없게 만들기 위해
  고객과의 소통에 초점을 맞춘 방법론을 통칭
• 기업 활동 전반에 걸쳐 사용
• 고객의 평가와 요구를 적극 수용하는 점에서 폭포수 모형과 대조적
• 소규모 프로젝트, 고도로 숙달된 개발자, 급변하는 요구사항에 적합
• 애자일 모형을 기반으로 하는 소프트웨어 개발 모형
  스크럼, XP, 칸반, Lean, 크리스탈, ASD, 기능 중심 개발, DSDM, DAD 등

🌠 ★★★ 애자일 개발 4가지 핵심 가치

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

---

스크럼(Scrum) 기법

스크럼(scrum)은 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중의 하나이다.
스크럼(scrum)은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.

• 팀이 중심이 되어 개발의 효율성을 높인다는 의미를 내포
• 팀원 스스로 스크럼 팀을 구성해야 함
• 개발 작업에 관한 모든 것을 스스로 해결할 수 있어야 함
• 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성됨

제품 책임자 ( PO; Product Owner )

• 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정
  (주로 개발 의뢰자 or 사용자가 담당)
• 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체
• 제품에 대한 테스트를 수행하면서 주기적으로 요구사항의 우선순위 갱신

스크럼 마스터 ( SM; Scrum Master )

• 객관적인 시각에서 조언을 해주는 가이드 역할 수행
• 팀원들의 통제가 목표가 아님
• 일일 스크럼 회의를 주관하여 진행 사항 점검, 개발 과정에서 발생된 장애 요소를 공론화하여 처리

개발팀 ( DT; Development Team )

• 제품 책임자와 스크럼 마스터를 제외한 모든 팀원
• 개발자 외에도 디자이너, 테스터 등
  제품 개발을 위해 참여하는 모든 사람이 대상이 된다.
• 보통 7~8명이 적당하다.

<그 외 스크럼 기법의 주요 용어>

• 제품 백로그 : 스크럼 팀이 해결해야 하는 목록/ (제품 개발에 필요한 요구사항(user story)을 모두 모아 우선순위에 따라 나열한 목록)

• 스프린트 : 하나의 완성된 최종 결과물을 만들기 위한 주기 / 보통 2~4주 정도의 기간 내에서 진행

• 속도 : 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치

<스크럼 개발 과정>

💡 스프린트 계획 회의 - > 스프린트 - > 일일 스크럼 회의 - > 스프린트 검토 회의 - > 스프린트 회고

---

🌠 ★★★ XP(eXtreme Programming)

수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법

• 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함.
• 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높인다.
• 릴리즈 테스트마다 고객을 직접 참여시킴으로써 고객이 직접 요구한 기능에 대한 확인 가능
• 비교적 소규모 인원의 개발 프로젝트에 적합

💡 개발 문서보다는 소스코드에 중점을 둔다.

< XP 개발 프로세스 관련 용어 >

• 릴리즈 계획 수립
  부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것
  몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라 함.

• 스파이크 : 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램 (처리할 문제 외의 다른 조건은 모두 무시하고 작성)

• 이터레이션(=주기)
  하나의 릴리즈를 더 세분화 한 단위 / 보통 1~3주 정도의 기간으로 진행됨

• 승인 검사(=인수 테스트)
  하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트

🌠 XP의 5가지 핵심 가치

의사소통(Communication), 단순성(Simplicity), 용기(Courage),
존중(Respect), 피드백(Feedback)

의.단.용.존.피

🌠 XP의 주요 실천 방법(Practice)

---

현행 시스템 파악

---

참고
https://blog.naver.com/dreaming_ryan/223099648320
https://m.blog.naver.com/wook2124/222102990691