이전까지 소프트웨어 공학에서 다루는, 소프트웨어 개발 activity를 다뤘다.
- Specification: 시스템 요구사항 정의
- design and implementation: 설계와 구현
- validation(testing): 검증과 테스팅
- evolution: 유지보수
이러한 activity들은 소프트웨어 개발에 반드시 포함된다.
어떤 순서로, 어떻게 배치되느냐에 따라서 차이가 발생하고,
이를 model이라고 한다.
앞에서는 waterfall model을 설명했다.
이제부터 설명할 model은 다음과 같다.
- V-model: 테스팅을 강화한 모델로 waterfall 모델에서 파생
- Incremental development: 기존의 것을 확장하는 식의 개발
- Integration and configuration: 소프트웨어 재사용을 기반
Software process models
Software process models
소프트웨어 프로세스 모델들의 각 목적과 장단점
- Waterfall model
: *Plan-driven 모델. Specification과 development가 별개의 단계로 명확히 구분된다.
*plan-driven: 계획이 많은 비중을 차지하는 프로세스 - Incremental development
: Specification, development 그리고 validation이 명확히 구분되어 있지 않다(plan-driven이나 agile일 수 있음). - Integration and configuration
: 시스템을 변경 가능한 이미 존재하는 컴포넌트로 구성한다(plan-driven이나 agile일 수 있음). - V-model
- Prototyping
+) agile 등 프로세스 모델은 더 많다.
1. Waterfall model phases
폭포수 모델(위에서 아래로 떨어지는 폭포 형태의 프로세스)
전통적인 모델로, 실제로 기업에서 적용하는 경우는 거의 없다.
대규모 시스템인 경우 활용한다.
- 요구사항 정의
- 시스템 그리고 소프트웨어 설계
- 구현 및 작은 단위의 테스팅
- 각 단위를 통합한 전체 시스템 테스팅
- 운용과 유지보수
Waterfall 모델은 프로세스를 단계별로 나누어, 프로젝트를 완강하게 구분한다. 하나의 단계가 끝나면 다음 단계로 넘어가고, 넘어간 단계로 다시 돌아가지 않는다. 따라서 고객의 요구에 대응하기 어렵다.
설계 과정에서 변화가 제한되어 있고, 요구사항이 확실한 경우에만 적합하다. 적은 기업 만이 이러한 '안정적인 요구'를 가지고 있는데, 따라서 큰 시스템 프로젝트에 적용된다. 프로세스가 명확히 구분되어 있어, 관리가 용이하기 때문에 서로 다른 업체들이 협력하는 경우에도 적합하다.
2. Testing phases in a plan-driven software process (V-model)
V-model은 테스팅을 강화한 모델이다.
requirement, 즉 요구사항(기능 따위)이 정해지는 시점에 해당 요구사항을 테스트하는 test plan이 작성된다. 이와 같이 Specification 단계 뿐만 아니라 설계 등 각 단계에서 test plan을 작성하고, 해당 plan을 기반으로 테스팅을 진행한다.
에러를 줄일 수 있지만, waterfall 모델과 같이 변화에 취약하다.
3. Incremental development
점진적 개발
Incremental development는 final version이 나오기 전까지 Specification, Development, Validation을 반복해, 점진적으로 개발하는 모델이다.
- 요구사항 변화로 발생하는 비용이 줄어든다. 또 waterfall model과 비교해, 다시 해야 하는 요구사항 분석과 문서의 양도 현저히 적다.
- 개발이 끝나고 Customer의 피드백을 받기가 수월하다. Customer는 소프트웨어 설명에 대한 평가를 할 수 있고, 또얼마나 구현되었는지 볼 수 있다.
- 사용가능한 소프트웨어를 빠르게 전달하고 배포하는 것이 가능하다.
Incremental development problems
- 진척도를 확인할 수 없다.
경영자들은 진척을 확인할 수 있는 정기적인 성과물을 필요로 한다. 그러나 시스템이 빠르게 개발되는 경우, 시스템의 모든 버전을 반영한 문서를 생산하는 것은 비용 효율적이지 않다. - 반복되는 개발로 시스템 구조의 질이 저하된다.
소프트웨어를 향상 시키기 위한 리팩토링에 시간과 돈을 할애하지 않으면 주기적인 변화는 그것의 구조를 변질시킨다
4. Integration and configuration
재사용 개발
- 이미 존재하는 컴포넌트들이나 Application 시스템들로부터 통합된 시스템과 같이, 소프트웨어 재사용을 기반으로 한다.
(COTS: Commercial-off-the-shlf 라고도 한다.) - 재사용된 요소들은 사용자의 요구사항에 따라서 동작과 기능이 조정되기도 한다.
- 재사용은 현재 표준은 아니지만 가장 일반화되어 있다
Types of reusable software
재사용할 수 있는 소프트웨어 유형
- Stand-alone application systems
- Collections of objects
- Web services that are developd according to service standards ana which are available for remote invocation
