- 소프트웨어 프로젝트란?
- 수행할 작업을 조직화한 프로세스
- 비용, 일정, 품질에 대한 목표를 성취하는 것
- 사전적 프로세스의 정의란?
- 어떤 일을 하기 위한 특별한 방법
- 일반적으로 단계나 작업으로 구성
- 소프트웨어 개발 프로세스란?
- 순서 제약이 있는 작업의 집합
- 높은 품질과 생산성이 목표
- Code-and-Fix
- 즉흥적 개발, 프로세스가 없는 개발
- 프로그래밍 → 만족할 때까지 수정 → 개선을 위한 아이디어 짜내기 → 만족할 때까지 수정
- 문제점
- 요구, 설계 작업의 중요성을 깨닫지 못함
- 즉흥적인 방법으로는 사용자의 높은 요구 수준에 도달하기 어려움
- 계속 고치는 작업이 필요
- 좋은 SW 구조를 만들 수 없음
- 프로세스가 없는 개발
- Code-and-Fix
- 즉흥적 개발, 프로세스가 없는 개발
- 프로그래밍 → 만족할 때까지 수정 → 개선을 위한 아이디어 짜내기 → 만족할 때까지 수정
- 문제점
- 요구, 설계 작업의 중요성을 깨닫지 못함
- 즉흥적인 방법으로는 사용자의 높은 요구 수준에 도달하기 어려움
- 계속 고치는 작업이 필요
- 좋은 SW 구조를 만들 수 없음
- 계획이 없기 때문에 작업의 목표가 없음
- 잘한 부분은 유지하고 잘못된 부분은 계속 고쳐야 하는데 개선의 밑바탕이 없음
- 공정이 없기 때문에 비용과 일정을 조절할 수 없음
- 체계적인 테스트 작업이나 품질 보증 차원의 활동에 대한 인식이 없음
- 결국 발견되지 않은 결함이 남아 계속 고쳐야 하므로 시스템이 더욱 악화
1. 폭포수 (waterfall) 모델
- 역사
- 1970년대 소규모 프로그램에 적용하는 Code-and-Fix model의 문제 해결을 위해 탄생했다.
- 처음으로 체계를 잡았다.
- 현재 나와 있는 모든 모델의 기본이다.
- 특징
- 단계적이다.
- 각 단계가 완전히 완료된 후 다음 단계로 진행된다.
- 이전 단계로 돌아갈 수 없으므로 피드백이 없다.
- 순차적으로 간 단계 사이에 중복이나 상호작용이 없다.
- 각 단계의 결과는 다음 결과가 시작되기 전에 점검한다. 따라서 단계가 끝날 때마다 오랜 시간 길게 검토한다.
- 결과물 정의가 중요하다. = 각 단계의 산출물 관리가 엄격하다. = 한 단계 안에서 여러 번 반복하여 산출물을 낸다.
- 진행 과정을 세분화하여 관리하기에 용이하다.
- 목표 시스템이 후반부에 가서야 구체화 한다. 따라서 중요한 문제점이 나중에 발견 되기도 한다. 그러나고치지도 못하여 축적된다.
- 적용 시 고려사항
- 관리가 상대적으로 쉬우나 요구 사항의 변경에 대한 대응력이 떨어진다.
- 기술 위험이 낮고 유사한 프로젝트 경험이 있을 경우 적용한다.
- 요구사항이 비교적 명확히 정의되어 있는 경우 적용한다.
- 제일 안 좋은 점
- 앞 단계에서 결과가 만족스럽지 못하면 다음 단계로 못 넘어간다.
- 앞 단계에만 치중하다 보니 뒷 단계에서는 시간이 부족하다.
2. 프로토타이핑 모델
- 정의
- 프로토타입(임시)을 만드는 모델이다.
- 사용자의 요구사항을 충분히 분석할 목적으로 시스템의 일부분을 일시적으로 간략히 구현한 다음 다시 요구 사항을 반영하는 과정을 반복한다.
- 목적
- 기능 목적이 아니라 시나리오 정도만 목표로 삼는다.
- 요구 분석의 어려움 해결을 위해 사용자의 참여 유도한다.
- 사용자와의 커뮤니케이션 수단으로 활용 가능하다. 따라서 요구사항 파악에 용이하여 요구사항이 분명하지 않을 때 유용하다. 이를 통해 요구사항 도출과 이해 가능하다.
- 사용자 자신이 원하는 것이 무엇인지 구체적으로 잘 모르는 경우에 간단한 시제품으로 개발할 수 있다.
- 개발 타당성를 검토한다.
- 요구사항 검증을 위해 프로토 타입 개발한 후, 폭포수 모델에 따라 전체 시스템 개발하여 폭포수 모델의 단점을 보완할 수 있다.
- 장점
- 프로토타입을 통해 요구 사항 도출이 용이하다.
- 실물화 덕분에 시스템 이해와 품질이 향상된다.
- 개발자와 사용자 간의 의사소통이 용이하다.
- 단점
- 프로트타입 결과를 최종 결과물로 오해할 수 있다.
- 잘못된 프로토타입 개발 시 폐기 처분에 따른 경제적인 손실이 발생한다. (시간/돈)
- 계속 개선하기 때문에 프로토타입에 대한 산출물 관리가 어렵다.
3. 진화적 모델
- 특징
- 진화적 개발이다
- 빠른 시간 안에 시장에 출시해야 유리하기 때문에 시스템을 나누어 release 할 때마다 기능의 완성도를 높인다.
- 완성도가 좀 떨어져도 일단 시장에 내놓는 전략을 가진다.
- 개발된 모듈을 upgrade 하는 방식으로 SW가 진화한다.
- 장점
- 사용자 요구를 빠르게 반영한다.
- 새로운 기능의 SW에 대한 시장을 빨리 형성한다. (사용자는 생각보다 본인이 원래 사용하던 것을 잘 바꾸지 않기 때문에 시장 선점 가능하다.)
- 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속하고 꾸준하게 고쳐나갈 수 있다.
- 단점
- 프로젝트 관리가 복잡하다.
- 반복적인 프로세스로 끝이 안보일 수 있으므로 실패의 위험이 커진다.
4. 나선형(spiral) 모델
- 특징
- 폭포수 모델의 장점 + 프로토타입 모델의 장점
- 위험 요소를 분석하고 해결할 수 있도록 지원하는 모델이다.
- 위험 평가에 대한 대안 여부에 따라 진행을 결정한다.
- 여러 번의 점증적인 릴리즈를 한다. ( ≠ 진화적 모델 )
- 처음에는 적게 했다가 갈수록 커진다.
- 여러 기능 중 우선 순위를 부여해 중요한 것부터 개발한다.
- 단계적 구성을 가진다.
- 장점
- 대규모 시스템 개발에 적합하다.
- 반복적인 개발과 테스트로 강인성(robustness)이 향상된다.
- 점증적인 것들이 갖는 특성이기도 하다
- 사이클을 돌수록 앞의 것들이 여러 번의 테스트를 거치며 견고해진다.
- 한 사이클에 추가 못한 기능은 다음 단계에 추가한다.
- 단점
- 관리/위험 분석이 중요하며 난이도가 높다.
- 개발기간이 장기화 될 수 있다.
- 적용
- 재정적/기술적 위험 부담이 큰 경우
- 요구 사항/아키텍쳐 이해가 어려운 경우
5. 점증적(Incremental) 모델
- 특징
- "사용자 요구사항의 일부분, 제품의 일부분을 반복적으로 개발 → 대상 범위 확대 → 최종 제품 완성" 순서로 진행한다.
- 증분들 생성하고 따로따로 개발하여 통합한다.
- 반복적이긴 하지만, 각 증분마다 실행 가능한 제품을 내놓는다.
- 폭포수 모델의 변형이다.
- 나선형 모델을 포함한다.
- 진화적 모델은 완성도는 떨어지더라도 10개 기능 모두 만들어 내보내지만, 점증적 모델은 10개 중 5개 먼저 만들고 이후 2개 추가하여 만든다고 볼 수 있다.
- 규모가 큰 개발인 조직인 경우 병행 개발 가능하기 때문에 증분을 동시에 개발하기도 한다.
- 릴리즈 과정
- "일부를 만들어 내놓고 → 더하여 내놓고 → 더하여 내놓고" 를 반복한다.
- 증분 계획을 정확히 해야 한다. 정확하지 않으면 끝나지 않는 진화적 모델의 단점을 닮아 갈 수도 있다.
- 장점
- 앞선 release 버전은 반복된 테스트를 거치기 때문에 강인성이 향상된다. ( = 나선형 모델 )
- 단점
- 여러 번 개발 해야 하는 것들(반복적인 모델)은 관리가 어렵다. ( = 진화적 모델 )
6. V 모델
- 특징
- 폭포수 모델 확장
- 감추어진 반복과 재작업이 이루어진다.
- 작업 결과 검증에 초점이 맞춰져 있다.
- 모든 과정에서 하는 일들로 이루어져 있지만 단계별로 test에 대한 기준이 엄격하여 따로 뺀 모델이다.
- 미리 분석 단계에서 테스트 기준을 미리 만들어 둔다.
- 장점
- 단점
- 폭포수 모델을 적용하여 되돌아 가지 않는다. 따라서 변경 다루기 어렵다.
- 적용
- 요구사항이 정확히 이해되는 작은 규모 개발 시 유용하다.
- 대규모 개발 시 테스트에 많은 시간 소비하여 적합하지 않다.
- 신뢰성이 높이 요구되는 분야에 사용된다. ( 예시 : 국방, 의료 시스템 )
- Humphrey(1995)는 "소프트웨어 제품의 품질은 소프트웨어 제품을 개발하고 유지보수 하는 데에 사용하는 프로세스의 품질에 의해 결정된다"라고 이야기 하셨다.
- SW 개발의 문제점
- 낮은 생산성과 품질 저하가 문제점이다.
- SW 프로젝트의 납기 지연과 비용 초과가 일어나고 있다.
- DoD 소프트웨어 프로젝트 중 품질/납기/비용 충족이 16%, 납기지연 및 비용초과가 53%, 실패가 31%를 차지한다. (F-22의 80%, B-2의 65%가 소프트웨어) [2015년 보고서]
- 프로세스 개선의 필요성
- 좋은 프로세스가 없으면 품질을 계획하거나 관리할 수 없다.
- 좋은 품질을 얻었더라도 그 이유가 무엇인지, 다시 또 반복적으로 좋은 품질을 얻을 수 있을 것인가에 대한 확신이 없다.
- 문제 해결 방향
- 하드웨어 개발 접근 방법의 도입하여 제도 및 생상 공정과 철저한 품질 관리 및 지속적인 공정 개선이 필요하다.
- 방법
- 국제 표준 인증제도들이 있다.
- CMM : 프로세스를 얼마나 잘했는지 5단계로 구성되어 있다.
- CMMI
- SPICE
- 6 시그마 (6σ) : 기업에서 전략적으로 완벽에 가까운 제품이나 서비스를 개발하고 제공하려는 목적으로 정립된 품질 경영 기법 또는 철학
- 기타 프로세스 표준 : ISO 12207, ISO 29110, ISO 15288 등
- 국내 프로세스 개선 : 정보통신산업진흥원의 SW 프로세스 품질인증제도
- SP인증 : 프로세스에 대한 것
- GS 인증 : 좋은 SW에 대한 것으로 필수이다.
![[CS][소프트웨어공학] SW 개발 프로세스, 전통적 프로세스 모델, SW 프로세스 개선](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbeoWPw%2FbtsxifyCn9Q%2FQawbVKDPlO5wWM6tQvyPeK%2Fimg.png)