소프트웨어 개발 생명 주기 모델 과정
- 계획 -> 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
계획
- 목표를 세우고 달성하기 위항 체계적인 진행 상황 관리를 할 수 있도록 행동 방안을 마련합니다.
분석
- 사용자의 요구사항을 명세서로 작성하는 과정으로 프로젝트에 관계된 모든 사람이 이해하기 쉽게 작성해야 합니다.
설계
- 요구사항을 반영하여 시스템 구조, 프로그램, 인터페이스 등의 설계서를 작성하는 과정으로 변화에 쉽게 적응할 수 있고 유지보수가 용이하도록 작성해야 합니다.
구현
- 프로그램을 제작 및 구현하는 단계로 이후 시험 단계로 진행됩니다.
테스트
- 프로그램 구현 이후 요구대로 소프트웨어가 적합하게 작동하는지 확인하고 품질 보증을 위하여 제품의 오류를 발견합니다.
유지보수
- 수정, 배포 이후에는 사용 시에 생기는 문제에 관하여 관리하거나 새로운 기능을 추가합니다.
소프트웨어 개발 프로세스 모형
폭포수 모델
- 요구분석 -> 설계 -> 구현 -> 시험 -> 유지보수
- 1950년대 항공 방위 소프트웨어 시스템 개발 경험을 토대로 처음 개발되어 1970년대부터 널리 알려졌습니다.
- 소프트웨어 개발을 단계적으로 체계적이며 순차적인 접근 방법을 사용하는데 가장 오래되고 널리 사용되고 있는 방법입니다.
- 개념 정립에서 구현까지 하향식 접근 방법을 사용하여 높은 추상화 단계에서 시작하여 낮은 추상화 단계로 옮겨갑니다.
- 각 단계가 끝날 때마다 과정의 끝을 알리고 그 다음 단계로 진행합니다.
- 문서와 결과물에 중점을 둡니다.
- 요구사항이 잘 이해되고 시스템 개발 중 급격한 변경이 없는 경우에 효과적입니다.
- 고객이 원하는 요구사항을 초기에 구체적으로 기술하기 어렵고 작동하는 시스템이 프로젝트의 후반부에 가서야 얻어짐으로써 중요한 문제점이 나중에 발견된다는 단점이 있습니다.
프로토타이핑 모델(원형 모델)
- 요구 사항 분석 -> 시제품 설계 -> 시제품 개발 -> 고객의 시제품 평가 -> 시제품 정제 -> 완제품 생산
- 요구사항을 반영하기 위해 빠르게 프로토타입을 만들어 확인 후 설계합니다.
- 사용자 요구가 불투명할 때 폭포수 모형을 대치할 수 있는 방법입니다.
- 고객의 요구를 완전히 이해하여 개발을 진행하는 것으로 시스템 이해도가 낮은 관리자가 있는 경우 유용합니다.
- 품질보다는 빠르게 만들어야 합니다.
나선형 모델
- 계획 및 정의 -> 위험분석 -> 개발 -> 고객평가
- 보헴이 제안한 것으로 폭포수 모델과 프로토타이핑 모델의 장점에 새로운 요소인 위험분석을 추가하여 만든 것입니다.
- 나선을 돌면서 점진적으로 완벽한 시스템을 만들어가는 점증적 모델의 일종입니다.
- 비용이 많이 들고 시간이 오래 걸리는 대규모 시스템의 소프트웨어를 개발하는데 가장 적합합니다.
- 비선형적이며 반복적으로 개발이 진행되므로 소프트웨어 품질 중 강인성을 높일 수 있습니다.
- 초기에 위험 분석을 잘못하여 위험 요소가 발견되지 못하고 계속 진행될 경우 많은 비용을 투입하고 실패로 끝날 수 있습니다.
V 모델
- 요구 분석 -> 시스템 설계 -> 상세 설계 -> 코딩 -> 단위 테스트 -> 통합 테스트 -> 시스템 테스트 -> 인수 및 설치
- 폭포수 모델에 시스템 검증과 테스트 작업을 강조한 모델입니다.
- 작업과 결과의 검증에 초점을 둡니다.
- 높은 신뢰성이 요구되는 분야에 적합합니다.
익스트림 프로그래밍 모델
- 애자일 방법론의 하나로 소프트웨어 개발 프로세스가 문서화하는 데 지나치게 많은 시간과 노력이 소모되는 단점을 보완하기 위해 개발되었습니다.
- 의사소통, 단순함, 피드백, 용기, 존중의 5가지 가치와 팀워크, 관리자, 고객에 초점을 맞춰 '고객에게 최고의 가치를 가장 빨리' 전달하도록 하는 방법론으로 켄트 백이 고안하였습니다.
- 요구 사항이 많거나 잦은 변화가 예상되는 프로젝트를 하는 경우에 소규모 소프트웨어 개발에 유리합니다.
컴포넌트 기반 모델
- 개발될 소프트웨어의 양을 줄일 수 있습니다.
RAD 모델
- CASE 도구를 활용하여 빠른 개발을 지향합니다.
일정 중심 설계 모델
진화적 출시 모델
소프트웨어 개발 방법론
애자일 개발 방법론
- 고객의 요구에 민첩하게 대응하고 그때그때 주어진 문제를 풀어나가는 방법론을 지칭합니다.
- 프로세스와 도구 중심이 아닌 개발 과정의 소통을 중요하게 생각하는 소프트웨어 개발 방법론으로 반복적인 개발을 통한 잦은 출시를 목표로 합니다.
- 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시합니다.
- 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시합니다.
- 계약과 협상 중심이 아닌 고객과의 협력을 중시합니다.
- 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시합니다.
소프트웨어 프로젝트 관리의 구성 요소
- 사람(people) : 프로젝트 관리에 있어 가장 기본이 되는 인적 요소입니다.
- 문제(problem) : 처리해야 할 사항을 사용자 입장에서 분석하고 기획하는 것입니다.
- 프로세스(process) : 소프트웨어 개발에 필요한 골격을 제공합니다.
프로젝트 관리 지식체계 지침서(PMBOK)
- 프로젝트 통합 관리
- 프로젝트 범위 관리
- 프로젝트 시간 관리(일정)
- 프로젝트 원가 관리(비용)
- 프로젝트 품질 관리
- 프로젝트 인적 자원 관리
- 프로젝트 의사소통 관리
- 프로젝트 리스크 관리
- 프로젝트 조달 관리
CASE
- 소프트웨어를 개발하는 동안 여러 작업들을 자동화하도록 도와주는 도구입니다.
- 소프트웨어 품질을 효율적으로 제어할 수 있습니다.
- 소프트웨어 유지보수 비용을 절감할 수 있습니다.
통합 CASE 도구
- 소프트웨어 개발 주기의 전체 과정을 지원합니다.
상위 CASE 도구
- 요구 분석과 설계 단계를 지원합니다.
하위 CASE 도구
- 코드 작성 및 문서화 등을 지원합니다.