[정보처리기사] 01 - 03 : 소프트웨어 생명주기 모델

Chlln's Code/정보처리기사

[정보처리기사] 01 - 03 : 소프트웨어 생명주기 모델

Chlln Vlln 2023. 3. 15. 15:45

1. 소프트웨어 생명 주기

1) 개요

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

2) 폭포수 모델(Waterfall model)

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

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

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

4) 나선형 모델(Spiral model)

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

5) 애자일 모델

특징
- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정 주기를 반복하면서 개발과정을 진행
- 특정 개발 모델이 아니라 고객과의 소통에 초점을 맞춘 방법론을 통칭하는 것
- 각 개발 주기에는 고객의 요구사항에 우선순위를 부여하여 개발을 진행
애자일의 핵심가치
- 절차보다 상호작용에 더 가치를 둠.
- 방대한 문서보다는 실행되는 소프트웨어에 더 가치를 둠.
- 계약 내용보다는 고객과의 협업에 더 가치를 둠.
- 계획을 따르기보다는 변화에 대응하는 것에 더 가치를 둠.

2. 스크럼 모델(Scrum model)

1) 특징

팀(Team)을 중심으로 개발을 진행하여 개발의 효율성을 높이는 개발 기법
제품 책임자, 스크럼 마스터, 개발팀으로 구성
스크럼의 가치 : 확약, 전념, 정직, 존중, 용기
- 자기 구속의 의도로 상대방에게 일정한 행위 여부를 약속하는 의사 표시

2) 스크럼 모델의 구성

제품 책임자(PO : Project Owner)
- 요구사항을 책임지고 의사를 결정하는 역할을 담당
- 제품에 대한 요구사항을 작성하는 주체
- 백로그(Backlog)에 스토리를 작성하고 우선순위를 지정, 갱신할 수 있음.
스크럼 마스터(SM : Scrum Master)
- 팀이 개발을 잘 수행할 수 있도록 가이드 역할을 담당
- 팀원을 통제하는 것이 목표가 아님.
- 일일 스크럼 회의를 주관하고 발생된 장애 요소를 공론화하여 처리
개발팀(DT : Development Team) : PO와 SM을 제외한 개발자 및 디자이너, 테스터 등 참여하는 모든 팀원을 말함.

3) 개발 프로세스

제품 백로그
- 제품 개발에 필요한 User Story를 우선순위에 따라 나열한 목록
- 개발 과정에서 지속적으로 업데이트됨.
스프린트(Sprint) 계획 회의
- 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 짧은 일정을 수립하는 것
- 처리할 요구사항을 개발자들이 나눠서 작업할 수 있도록 작업을 분리(Task)한 후 스프린트 백로그를 작성
스프린트
- 실제 개발을 2~4주간 진행하는 과정
- 스프린트 백로그에 작성된 Task를 대상으로 작업 시간을 측정한 후 담당 개발자에게 할당함.
- Task는 할 일, 진행 중, 완료의 상태로 구성된다.
일일 스크럼 회의
- 모든 팀원이 15분 정도의 짧은 시간 동안 소멸차트를 통해 진행도를 점검하는 것
- SM은 회의에서 발견된 장애요소를 해결할 수 있도록 도와야 한다.
스프린트 검토 회의
- 사용자를 포함한 참석인원 앞에서 부분 또는 완성 제품을 테스트하는 것
- PO는 개선 사항에 대한 피드백을 정리하여 제품 백로그에 반영
스프린트 회고
- 규칙을 준수하며 스프린트를 진행했는지, 개선점은 없었는지 확인
- 스프린트가 끝난 시점이나 일정 주기를 정하여 수행

3. 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 Releases : 짧고 잦은 릴리즈로 고객이 변경사항을 볼 수 있게 함
Shared understanding
- Coding Standards : 표준화된 관례에 따라 코드 작성
- Collective Ownership : 시스템에 있는 소스코드는 팀의 모든 프로그래머가 언제라도 수정 가능
- Simple Design : 가능한 가장 간결한 디자인 상태 유지
- System Metaphor : 최종적으로 개발되어야 할 시스템의 구조를 조망
Programmer welfare
- Sustainable Pace : 오버타임 지양

4. 프로젝트 관리

1) 개념

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

2) 프로젝트 관리의 종류

일정 관리 : 활동 순서, 활동 기간 산정, 일정 개발, 일정 통제
예산 관리 : 원가 산정, 예산 편성, 원가 통제
인력 관리 : 프로젝트 팀 편성, 조직 정의, 팀 관리, 자원의 선정 및 통제
위험 관리 : 위험 식별, 위험 평가, 위험 대처
품질 관리 : 품질 계획, 품질 보증 수행, 품질 통제 수행
프로젝트 관리의 3P : 사람(People), 문제(Problem), 절차(Process)

3) 프로젝트 계획 수립

소프트웨어 영역 측정

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

자원 측정

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

4) 인적 자원

책임 프로그래머 팀(중앙 집중형)
- 단기적인 소규모 소프트웨어 개발에 유리
- 팀원 대다수의 만족도가 낮아 이직률이 높음.
- 1인 독재 체제의 스타형 구조
민주주의식 팀(분산형)
- 장기적인 대규모 소프트웨어 개발에 유리
- 팀원 대다수의 만족도가 높아 이직률이 낮음.
- 수평식 링형 구조

5) PERT(Program-Evaluation and Review Techique) 네트워크

PERT의 개념
- 소요 기간의 예측이 어려운 경우에 적합한 프로젝트 평가 및 검토 기술
- 작업별로 낙관치, 기대치, 비관치로 구성하여 종료 시기를 결정
PERT를 이용한 일정 계획 순서
- 소프트웨어의 전체 규모를 추정
- 작업을 기능과 특징별로 분류
- 단계별로 작업 일정을 예측하여 기간을 예측
PERT 일정 계획
- 노드와 간선으로 작업을 구분
- 작업별로 낙관치, 기대치, 비관치를 이용하여 예측치를 구함.
- 예측치 측정 = (낙관지 + (4 × 기대치) + 비관치) / 6
PERT 제공 항목
- 프로젝트 개발 기간을 결정하는 임계경로를 알 수 있음.
  - 임계경로 : 가장 오래 걸리는 경로
- 개별 작업의 가장 근접한 시간을 측정
- 비용 측정은 별도로 진행

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

CPM의 개념
- 소요 기간이 확실한 경우에 적합한 프로젝트 평가 및 검토 기술
- 작업명을 표시하는 원형 노드와 이정표, 예상 완료 시간을 표시하는 박스 노드로 구성
- 이정표 간의 이동은 이전 작업을 완료해야 함
CPM을 이용한 일정 계획 순서
- 소프트웨어의 전체 규모를 추정
- 작업을 기능과 특징별로 분류
- 단계별로 작업 일정을 예측하여 기간을 예측
- 간트 차트를 작성
  - 간트 차트 : 각 업무별로 일정의 시작과 끝을 바(bar) 형태의 그래픽으로 표시하여 전체 일정을 한눈에 볼 수 있고 각 업무 사이의 관계를 파악하기 수월
CPM 일정 계획 : 노드와 이정표, 간선으로 작업을 구분
CPM 제공 항목
- 프로젝트 개발 기간을 결정하는 임계경로를 알 수 있음.
- 개별 작업의 가장 근접한 시간을 측정
- 단계별 작업 간의 경계 시간을 계산할 수 있음.
- 비용 측정은 별도로 진행

7) 위험 관리

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

5. 형상 관리

1) 형상 관리의 개념

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

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

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

3) 형상 관리의 절차

형상 식별
- 절차와 표준, 스키마, 문서, 파일, 코드 등 모든 산출물을 대상으로 함.
  - 스키마 : 어떤 작업을 진행하거나 결과를 내는 데 있어 준수해야 하는 제약 사항
- 형상 관리 대상을 식별하고 이름과 관리 번호를 부여
- 각 대상을 계층(Tree) 구조로 구성
- 수정 및 추적이 용이하도록 베이스라인의 기준을 정하는 활동
변경 제어(형상 통제)
- 형상 항목의 변경 요구를 검토, 승인하는 작업
- 변경 항목을 적절히 제어하여 현재의 베이스라인에 잘 반영되도록 조정
- 형상통제위원회 승인을 통한 통제가 이루어질 수 있어야 함.
형상 상태 보고
- 형상의 식별, 통제, 감사 작업의 결과를 기록하고 관리하는 작업
- 베이스 라인의 상태 및 변경된 형상의 정상 반영 여부를 관리
형상 감사 : 베이스라인의 무결성을 공식 승인하기 위해 검증 과정을 거치는 단계