[정보처리기사 실기] 1장 요구사항 확인 _ 소프트웨어 생명주기 (SDLC) 모형

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

- 소프트웨어 개발 및 운용, 유지보수 등 각 단계를 진행하는 것

- 소프트웨어 생성부터 소멸까지 변환되는 과정

 

타당성 검토 -> 계획 -> 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수

---

전통적 SDLC 모형

1) 폭포수 (Waterfall) 모형

- 전통적인 생명주기 모형

- 각 단계를 순차적으로 진행하고 단계별 마무리가 되어야 다음 단계로 진행하는 방식

 

장점

- 사용사례와 성공사례 많음

- 각 단계별 정의와 활동 분명하고 단계별 산출물 명확

 

단점

- 사용자 요구사항 반영 어려움

- 단계별 오류 없이 다음 단계로 진행 불가

---

2) 프로토타입 (Prototype) 모형

- 시제품 (Prototype) 만들어 제공하는 방식

 

요구분석 -> 프로토타입 설계 -> 프로토타입 구축 -> 고객 평가 -> 프로토타입 정제 -> 구현

 

장점

- 사용자 요구사항 반영 용이

- 최종 결과물 나오기 전 결과물 일부나 모형 볼 수 있음

- 개발자나 의뢰자 모두에게 공동 참조 모델 제공

- 개발단계에서 오류 수정 가능

 

단점

- 미리 개발된 소프트웨어 사용 시, 실제와 차이 발생할 수 있음

---

3) 나선형 (Spiral) 모형

- 폭포수 모형과 프로토타입 모형 장점 반영

- 분석 단계에 위험 분석 기능 추가해 위험 관리 가능

- 개발과정을 반복해 최종 소프트웨어 개발하는 것으로, 점진적 모형이라 함

---

애자일 (Agile) SDLC 모형

- 고객 요구 변화에 민첩하게 대응해 짧은 주기로 개발 반복하는 모형

- 각 주기마다 생성되는 결과물을 점진적으로 개발해 최종 시스템 완성

- 시제품을 끊임없이 제작하며 사이클 반복하는 개발 방법론

- 고객의 변화하는 요구사항과 환경 변화에 능동적

- 절차보다는 사람 중심으로 변화에 유연하고 신속하게 적응하며 개발 기간 짧고 워터폴에 대비

ex) XP (익스트림 프로그래밍), 스크럼, 칸반, 기능 중심 개발 등

 

애자일 모형이 추구하는 4가지 핵심 가치

- 프로세스나 도구보다 개인과 상호작용에 더 가치 둠

- 포괄적인 문서보다 작동하는 소프트웨어에 더 가치 둠

- 계약 협상보다 고객과의 협업에 더 가치 둠

- 계획 따르기보다 변화의 대응에 더 가치 둠

---

1) XP (익스트림 프로그래밍, eXtreme Programming)

- 고객의 참여와 개발 과정의 반복을 극대화하는 방법

- 소규모 개발 조직이 불확실하고 요구 변경 많을 때 적절한 애자일 모형

- 릴리즈 기간 짧게 반복하고, 고객 참여로 릴리즈 테스트 수행

 

XP 5가지 핵심 가치

1. 의사소통 (Communication)

2. 단순성 (Simplicity)

3. 용기 (Courage)

4. 존중 (Respect)

5. 피드백 (Feedback)

 

 XP 주요 실천 방안

짝 프로그래밍 (Pair Programming)	다른 사람과 함께 프로그래밍 수행함으로써 개발에 대한 책임 공동으로 나눠 갖는 환경 조성
공동 코드 소유 (Collective Ownership)	권한과 책임 공동 소유
테스트 주도 개발 (Test-Driven Development)	- 개발자가 실제 코드 사용하기 전 테스트 케이스 먼저 작성해 무엇을 해야 할지 정확히 파악 - 지속적 테스트 진행 위해 자동화된 테스팅 도구 (구조, 프레임워크) 사용
전체 팀 (Whole Team)	개발에 참여하는 모든 구성원 (고객 포함)들은 각자 역할과 책임 있음
계속적 통합 (Continuous Integration)	모듈 단위로 나눠 개발된 코드들은 마무리될 때마다 지속적 통합
리팩토링 (Refactoring)	프로그램 기능 변경하지 않고 중복코드 제거, 단순화, 유연성 강화 등 통해 시스템 재구성
소규모 릴리즈 (Small Release)	릴리즈 기간 짧게 반복해 고객 요구 변화에 신속 대응

---

2) 스크럼 (Scrum)

- 개발팀이 중심 되어 짧은 주기 (Sprint) 반복하며 소프트웨어 개발하는 모형

 

(1) 스크럼 팀 구성원과 역할

제품 책임자 (PO)	- 제품에 대한 요구사항 작성하는 주체 - 제품 백로그 (Backlog) 작성, 우선순위 지정
스크럼 마스터 (SM)	- 스크럼 수행 가이드 역할 - 개발 과정 장애요소 공론화해 처리
개발팀 (DT)	PO, SM 제외한 팀원 (디자이너, 테스터 등)

 

(2) 스크럼 개발 구성요소

제품 백로그 (Product Backlog)	- 제품이 제공해야 하는 모든 요구사항을 우선 순위에 따라 나열한 목록 - 프로젝트 수행하는 동안 지속적 업데이트됨
스프린트 계획 회의	- 제품 백로그 중 해당 스프린트에서 수행할 작업의 단기 일정 수립                                   스프린트 (Sprint)  : 2 ~ 4주 실제 작업 진행 기간 - 사용자 스토리 개발 할 타스크 (Task)로 분할 후 개발자 별 작업 목록인 스프린트 백로그 작성
일일 스크럼 회의	- 매일 약속된 시간에 모든 팀원이 모여 진행 상황 점검하는 회의 - 진행시간 15분 내외, 서서 진행하고 남은 작업시간은 번다운차트에 표시 - 스크럼 마스터가 발견된 장애요소 해결할 수 있도록 도움
스프린트 검토회의 (Sprint Review)	완성된 제품이 요구사항에 부합되는지 사용자 참석 하에 테스트
스프린트 회고 (Sprint Retrospective)	스프린트 주기 되돌아 보며 규칙 준수했는지, 좋았던 점, 문제점, 개선점 없는지 확인