[정보처리기사] 소프트웨어 생명주기 모델 ( 정리, 공부 )

소프트웨어 생명주기 모델

소프트웨어 생명 주기

1) 개요

• 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어 개발 과정을 단계별로 나눈 것
• 각 개발 단계별 결과에 대한 산출물로 표현
• 소프트웨어 수명 주기, 소프트웨어 공학 패러다임

2) 폭포수 모델(Waterfall Model)

① 특징

• 개발 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓는다.
• 과거 가장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형이다.
• 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있다.
• 메뉴얼 작성이 필요하다.
• 단계별 결과물이 명확하게 산출되어야 한다.

② 개발 프로세스

 

3) 프로토타입 모델(Prototyping model)

① 특징

• 폭포수 모형의 단점을 보완한 모델이다.
• 사용자의 요구사항 파악을 위해 견봄품을 만들어 결과물을 예측한다.
• 사용자와 시스템 사이의 인터페이스에 집중하여 개발한다.

② 개발 프로세스

4) 나선형 모델(Spiral model)

① 특징

• 폭포수와 프로토타입의 장점에 위험 분석 기능을 추가한 것으로 보헴이 제안하였따.
• 여러 번의 개발 과정을 거쳐 점진적으로 완벽한 소프트웨어를 개발하는 것이다.
• 개발 중 발생할 수 있는 결함을 관리하여 최소화하는 것을 목적으로 한다.
• 누락되거나 추가된 요구사항을 반영할 수 있고 유지보수 과정이 필요 없다.

② 개발 프로세스

5) 애자일 모델

① 특징

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정 주기를 반복하면서 개발과정을 진행한다.
• 특정 개발 모델이 아니라 고객과의 소통에 초점을 맞춘 방법론을 통칭하는 것이다.
• 각 개발 주기에는 고객의 요구사항에 우선순위를 부여하여 개발을 진행한다.

② 애자일의 핵심가치 ★

• 절차보다 상호작용에 더 가치를 둔다.
• 방대한 문서보다는 실행되는 소프트웨어에 더 가치를 둔다.
• 계약 내용보다는 고객과의 협업에 더 가치를 둔다.
• 계획을 따르기보다는 변화에 대응하는 것에 더 가치를 둔다.

---

스크럼 모델(Scrum model)

1) 특징

• 팀(Team)을 중심으로 개발을 진행하여 개발의 효율성을 높이는 개발 기법이다.
• 제품 책임자, 스크럼 마스터, 개발팀으로 굿어된다.
• 스크럼의 가치 : 확약, 전념, 정직, 존중, 용기 ★

2) 스크럼 모델의 구성

① 제품 책임자(PO : Project Owner)

• 요구 사항을 책임지고 의사를 결정하는 역할을 담당한다.
• 제품에 대한 요구사항을 작성하는 주체이다.
• 백로그(Backlog)에 스토리를 작성하고 우선순위를 지정, 갱신할 수 있다.

② 스크럼 마스터(SM : Scrum Master)

• 팀이 개발을 잘 수행할 수 있도록 가이드 역할을 담당한다.
• 팀원을 통제하는 것이 목표가 아니다.
• 일일 스크럼 회의를 주관하고 발생된 장애 요소를 공론화하여 처리한다.

③ 개발팀(DT : Development Team)

• PO와 SM을 제외한 개발자 및 디자이너, 테스터 등 참여하는 모든 팀원을 말한다.

3) 개발 프로세스

① 제품 백로그

• 제품 개발에 필요한 User Story를 우선순위에 따라 나열한 목록이다.
• 개발 과정에서 지속적으로 업데이트된다.

② 스프린트(Sprint) 계획 회의

• 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 짧은 일정을 수립하는 것이다.
• 스프린트 백로그에 작성된 Task를 대상으로 작업 시간을 측정한 후 담당 개발자에게 할당합니다.
• Task는 할 일, 진행 중, 완료의 상태로 구성된다.

③ 스프린트

• 실제 개발을 2~4주간 진행하는 과정이다.
• 스프린트 백로그에 작성된 Task를 대상으로 작업 시간을 측정한 후 담당 개발자에게 할당합니다.
• Task는 할 일, 진행 중, 완료의 상태로 구성된다.

④ 일일 스크럼 회의

• 모든 팀원이 15분 정도의 짧은 시간 동안 소멸차트를 통해 진행도를 점검하는 것이다.
• SM은 회의에서 발견된 장애요소를 해결할 수 있도록 도와야 한다.

⑤ 스프린트 검토 회의

• 사용자를 포함한 참석인원 앞에서 부분 또는 완성 제품을 테스트하는 것이다.
• PO는 개선 사항에 대한 피드백을 정리하여 제품 백로그에 반영한다.

⑥ 스프린트 회고

• 규칙을 준수하며 스프린트를 진행했는지, 개선점은 없었는지 확인한다.
• 스프린트가 끝난 시점이나 일정 주기를 정하여 수행한다.

---

XP(eXtreme Programming) 모델

1) 특징

• 고객의 참여와 개발 과정(Release)의 반복을 극대화하여 개발 생산성을 향상시키는 방법
• 짧고 반복적인 개발 주기, 단순한 설계로 인한 빠른 개발을 목적
• 비교적 소규모 인원의 개발 프로젝트에 효과적
• XP의 가치 : 의사소통, 단순성, 용기, 존중, 피드백 ★

2) 개발 프로세스

① 사용자 스토리 : 고객의 요구사항을 긴으 단위로 구성하며, 간단한 테스트 항목도 기재

② 릴리즈 계획 수립

• 몇가지 스토리를 합하여 부분적 기능이 완성된 제품을 제공하는 것
• 부분 또는 전체 개발 완료 시점에 대한 일정을 계획

③ 스파이크

• 기술 문제를 해결하고 위험을 감소시키기 위해 별도로 제작하는 간단한 프로그램
• 처리할 기술 문제를 제외한 다른 요소는 모두 배제하고 작성

④ 이터레이션

• 하나의 릴리즈를 세분화한 단위
• 이터레이션 하나당 1~3주의 기간을 설정
• 이터레이션 진행 도중 새로운 스토리를 포함 가능

⑤ 승인 검사

• 릴리즈 단위의 부분 완료 제품이 구현되는 테스트
• 사용자 스토리에 기재된 테스트 항목에 대해 고객이 직접 테스트
• 테스트 과정에 발견되는 오류는 다음 이터레이션에 포함

⑥ 소규모 릴리즈

• 고객의 반응을 기능별로 확인할 수 있어 좀 더 유연하게 대응이 가능

3) XP의 기본 원리(실천 항목)

① Fine scale feedback

• Pair Programming : 하나의 작업을 2명의 프로그래머가 코딩/리뷰 공동 수행
• Planning Game : 게임처럼 선수와 규칙, 목표를 두고 기획 수행
• Test Driven Development : 선 단위 테스트 후 실제 코드 작성
• Whole Team : 개발 효율을 위해 고객을 프로젝트 팀원으로 상주

② Continuous process

• Continuous Integration : 상시 빌드 및 배포가 가능한 상태로 유지
• Design Improvement : 코드 개선 작업 수행(가시성, 성능 등), 불필요한 기능 제거 및 리팩토링
• Small Improvement : 짧고 잦은 릴리즈로 고객이 변경사항을 볼 수 있게 함

③ Shared understanding

• Coding Standards : 표준화된 관례에 따라 코드 작성
• Collective Ownership : 시스템에 있는 소스코드는 팀의 모든 프로그래머가 언제라도 수정 가능
• Simple Design : 가능한 가장 간결한 디자인 상태 유지
• System Metaphor : 최종적으로 개발되어야 할 시스템의 구조를 조망

④ Programmer welfare

• Sustainable Pace : 오버타임 지양

---

프로젝트 관리

1) 개념

• 사업의 목적에 맞게 미리 계획된 일정과 비용 범위에서 목적을 달성하기 위한 모든 활동
• 정해진 시간 안에서 단계적으로 진행되는 특성
• 업무마다 프로젝트 개발 방법이 다름

2) 프로젝트 관리의 종류

① 일정 관리 : 활동 순서, 활동 기간 산정, 일정 개발, 일정 통제

② 예산 관리 : 원가 산정, 예산 편성, 원가 통제

③ 인력 관리 : 프로젝트 팀 편성, 조직 정의, 팀 관리, 자원의 선정 및 통제

④ 위험 관리 : 위험 식별, 위험 평가, 위험 대처

⑤ 품질 관리 : 품질 계획, 품질 보증 수행, 품질 통제 수행

⑥ 프로젝트 관리의 3P : 사람(People), 문제(Problem), 절차(Process) ★

3) 프로젝트 계획 수립

① 소프트웨어 영역 측정

영역 분류	측정 항목
처리 기능	소프트웨어 기능의 범위 측정
성능	소프트웨어 처리 속도, 동시 접속자 수 등 측정
제한 조건	소프트웨어 한게 등의 제약 조건 측정
개발 인원	개발 인력 수, 개발 조직의 형태 측정
일정 계획	기간, 작업 시간, 단계별 기간 등 측정

② 자원 측정

자원 분류	측정 항목
하드웨어 자원	개발자 시스템, 사용자 시스템, 개발 지원 시스템 파악
소프트웨어 자원	프로그램 작성 도구, CASE 등 파악
인적 자원	개발 조직, 팀 구성, 프로그래밍 능력 파악

4) 인적 자원

① 책임 프로그래머 팀(중앙 집중형)

• 단기적인 소규모 소프트웨어 개발에 유리
• 팀원 대다수의 만족도가 낮아 이직률이 높음
• 1인 독재 체제의 스타형 구조

② 민주주의식 팀(분산형)

• 장기적인 대규모 소프트웨어 개발에 유리
• 팀원 대다수의 만족도가 높아 이직률이 낮음
• 수평식 링형 구조

5) PERT(Program-Exvaluation and Review Technique) 네트워크 

① PERT의 개념

• 소요 기간의 예측이 어려운 경우에 적합한 프로젝트 평가 및 검토 기술
• 작업별로 낙관치, 기대치, 비관치로 구성하여 종료 시기를 결정

② PERT를 이용한 일정 계획 순서

• 소프트웨어의 전체 규모를 추정
• 작업을 기능과 특징별로 분류
• 단계별로 작업 일정을 예측하여 기간을 예측

③ PERT 일정 계획

• 노드와 간선으로 작업을 구분
• 작업별로 낙관치, 기대치, 비관치를 이용하여 예측치를 구한다.
• 예측치 측정 = (낙관치 + ( 4 x 기대치 ) + 비관치) / 6

④ PERT 제공 항목

• 프로젝트 개발 기간을 결정하는 임계경로를 알 수 있다.
• 개별 작업의 가장 근접한 시간을 측정한다.
• 비용 측정은 별도로 진행한다.

6) CPM(Critical Path Method) 네트워크

① CPM의 개념

• 소요 기간이 확실한 경우에 적합한 프로젝트 평가 및 검토 기술
• 작업명을 표시하는 원형 노드와 이정표, 예상 완료 시간을 표시하는 박스 노드로 구성
• 이정표 간의 이동은 이전 작업을 완료해야함

② CPM을 이용한 일정 계획 순서

• 소프트웨어의 전체 규모를 추정
• 작업을 기능과 특징별로 분류
• 단계별로 작업 일정을 예측하여 기간을 예측
• 간트 차트를 작성

③ CPM 일정 계획

• 노드와 이정표, 간선으로 작업을 구분

④ CPM 제공 항목

• 프로젝트 개발 기간을 결정하는 임계경로를 알 수 있다.
• 개별 작업의 가장 근접한 시간을 측정한다.
• 단계별 작업 간의 경계 시간을 계산할 수 있다.
• 비용 측정은 별도로 진행한다.

7) 위험 관리

• 프로젝트 진행 과정에서 예상되는 각종 상황을 예상하고 대처하는 활동
• 위험 요소를 파악하고 위험의 비중과 영향력을 측정
• 위험 발생 시의 대처 방안을 준비하고 문서화
• 위험을 항상 관찰하고, 발생 즉시 조치

---

형상 관리

1) 형상 관리의 개념

• 소프트웨어 개발의 전 과정에서 발생하는 산출물들의 버전(Version)을 관리하기 위한 모든 활동

2) 형상 관리의 역할 및 특성 ★

• 동일한 프로젝트를 여러 개발자가 동시에 개발이 가능
• 사용자들의 불필요한 수정을 제한
• 버전 관리를 통해 배포본 관리에 유용하며 리비전(revision)이 가능

3) 형상 관리의 절차

① 형상 식별

• 절차와 표준, 스키마, 문서, 파일, 코드 등 모든 산출물을 대상으로 한다.
• 형상 관리 대상을 식별하고 이름과 관리 번호를 부여한다.
• 각 대상을 계층(Tree) 구조로 구성한다.
• 수정 및 추적이 용이하도록 베이스라인의 기준을 정하는 활동이다.

② 변경 제어(형상 통제) ★

• 형상 항목의 변경 요구를 검토, 승인하는 작업이다.
• 변경 항목을 적절히 제어하여 현재의 베이스라인에 잘 반영되도록 조정한다.
• 형상통제위원회 승인을 통한 통제가 이루어질 수 있어야 한다.

③ 형상 상태 보고

• 형상의 식별, 통제, 감사 작업의 결과를 기록하고 관리하는 작업이다.
• 베이스 라인의 상태 및 변경된 형상의 정상 반영 여부를 관리한다.

④ 형상 감사

• 베이스라인의 무결성을 공식 승인하기 위해 검증 과정을 거치는 단계

---

※ <이기적> 환상의 콤비 정보처리기사 책으로 공부하며 정리한 내용입니다.