[Chap 3] Software Process

3.1 Software Engineering as a Layered Technology   

- Quality, Process, Methods, Tools의 4가지 계층구조로 Software Engineering이 이루어짐.

- 여기서 Process는 Software을 개발하는과정을 말하며 Software Engineering의 토대가 되는 부분임.

3.2 Software Process의 Phases

- Process는 Definition(정의), Development(개발), Support(지원, 유지보수)들의 3가지 단계(Phases)를 거침.

=> Definition: 무엇을 만들려는 것인지에 집중된 것. Project management나 요구사항 분석등이 주요 과제

=> Development: 어떻게 만들것인가에 집중된 것. Software design이나 코드 짜기, 테스팅등이 주요 과제

=> Maintenance: 변화에 집중된 것. 결함을 수정하거나, 특정 환경에 적용시키고, 기능을 추가하는 것이 주요 과제.

- 위의 3단계를 Generic Phases(일반적인 단계들)로서 Framework Activities라고 한다.

- Framework Activities의 위 단계로서 Umbrella Activities라는 것이 있다. 여기서의 주 과제는  프로젝트 관리, 품질보장, Configuration 관리, 예측, 등 많은 과제들이 있음.

-대표적인 Process 중 하나로 CMMI(Capability Maturity Model Integration)이 있다. 이 CMMI는 조직에서의 Software Process maturity(성숙도)를 판단 하는 일을 한다.

=> Initial -> Repeatable -> Define -> Managed -> Optimizing의 5단계로 조직을 평가한다. Optimizing 단계로 갈수록 높은 등급이다.

=> Initial: 몇몇의 Process들이 저의되어 있고 성공이라는 것이 개인적인 노력에 달려있는 단계

=> Repeatable: 기본적인 프로젝트 관리의 프로세스들이 정의되어 있음. 일찍이 성공한 프로젝트들에 대하여 반복하는 단계

=> Defined: Management와 Engineering activities가 모두 정의되어 있는 단계. 모든 프로젝트들이 문서화되어 있는, 인정되는 프로세스들을 사용한다.

=> Managed: 프로세스 및 제품 품질의 상세한 측정들이 모여진 단계. 프로세스와 제품들이 둘 다 양적으로 측정되며 제어된다.

=> Optimizing: 많은 피드백으로 지속적인 프로세스 향상이 이루어지는 단계

 

3.3. Software Process : Model

- Software 생산에 있어서 필요한 활동의 집합 또는 사람들을 잘 가이드해 줄 수 있는 것들의 집합이라 할 수 있다.

- Software Process는 Process model이라는 추상화된 표현을 사용한다. 이는 사람들을 더 잘 이해시키고 커뮤니케이션을 가능하게 하며, 프로세스의 향상과 관리를 돕는다. 

=> 이 Process Model들을 도식화하여 나타낸 일련의 흐름을 Software Life Cycle이라고 한다. 이는 어떤 Software를 만들지 계획하는 순간부터 시작해서 소프트웨어가 더이상 이용가능하지 않을 까지의 시간순의 활동들이 도식화되어 있다.

- Software Process Model은 다양한 종류가 있다. 하나하나의 모델들을 살펴보기로 하자.

1) Build and fix model

- 처음 버전을 만들어 낸 후, Modify(수정)을 계속 반복하는 방법이다. 

- 아주 작은 일의 경우 혼자하는 것이 효율적이며 Specification(명시) 없이 만들어 질 수 있다. 오늘날에는 알맞지 않는 모델이다.

2) Linear Sequential Model

- 차례 차례 하나씩 개발해 나가는 방법이다.

- 예를 들면, 분석(analysis) -> 설계(Design) -> Code -> Test 와 같이 차례로 개발해 나감.

3) Waterfall Model

- 1970년 대에 유행하던 모델로서, 많은 사람들이 사용하게 됨으로 표준의 역할을 했던 모델.

- Document-oriented가 가장  중요한 특징으로 각 단계별로 문서화가 이루어졌던 모델

- 각 단계들은 각 다음단계들에 영향을 줌.

- 많은 변형된 모델들이 후에 많이 나옴

- 특징들은 다음과 같다.

=> 소프트웨어 개발을 단계적, 순차적으로 수행되는 절차적 프로그래밍 기법이다.

=> 이전 단계가 끝난 후 다음 단계가 진행된다.

=> 하향 접근 방식이다.(Top-down)

=> 결함 발견시 전 단계로 돌아가는 피드백 단계는 존재한다. (Waterfall 모델은 뒤로 되돌아 갈 수 없는데, 피드백이 존재 한다는 이유는, 사람이 모델링 하는 것이므로 무언가 잘못된다면 전단계로 되돌아가는 유연성 정도는 존재함. 하지만 심각한 오류는 대체적으로 테스트단계에서 발견되고, 그때는 이미 되돌아 가기에는 늦은 경우가 대부분.)

- 여러 Activity들을 포함하고 있다.

=> Feasibility Study(타당성 조사): 제안된 솔루션에 대하여 비용(cost)와 이익(benefit)을 평가하며, 문제를 분석한다. 나중에 있을 개발 프로세스를 시뮬레이션 하기도 하며, 문서화 작업에는 문제의 정의, 대안 해결책, 예상되는 이익 요구되는 리소스들 등등이 들어간다.

=> Requirements Analysis and Specification(요구 분석과 명시): 요구들을 확인하는 것으로 기능적인(functional) 것과 비기능적(nonfunctional)것을, 그리고 무엇을 해야하며, 어떻게 해야할지를 명시해야한다. 

=> Design and Specification(설계 및 명시): 문제에 대한 해결책을 제안하며, 높은 단계(high-level)와 낮은 단계(Low-level)로 나눠 질 수 있음. 높은 단계에서는 시스템을 모듈들로 나누며 각 모듈들 사이의 관계들을 명시하는 단계이다. 낮은 단계에서는 각 모듈들을 상세히 설게환다.

=> Coding and Module Testing(코딩 및 모듈 검사)

=> Integration and System Testing(통합과 시스템 검사): 모듈과 모듈간의 통합을 하는다. 시스템 검사는 기능적인 부분과 비기능적인부분의 품질들을 평가한다.

=> Delivery and Maintenance(배포와 유지보수): 유지보스는 수정(20%), 적용(20%), 완성(60%)로 이루어짐.

=> 이 외, 다른 activity들은 Documentation(문서화), Verification(검증), Management(관리)등이 있다.

- Waterfall Model의 문제점

=> 병행 작업이 안된다. (각 단계는 앞 단계가 끝이 날때 까지 대기해야하므로 수행하기 까지 시간이 오래 걸림. 특히 요구 분석 단계가는 시간이 오래 소요됨)

=> 피드백에 대한 반복 단계가 어렵다

=> 테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다.

=> 고객 요구사항에 대한 상세한 반영이 어렵다. 

4) Prototyping Model

- Linear Sequential Model의 단점들을 보완하기 위해 만들어짐.

- 요구사항이 불분명한 경우에 유요한 모델로 고객과 개발자 사이의 원활한 의사소통이 가능하게 하는 모델

- 요구사항들을 모음으로써 시작되며, 빠른 설계가 뒤따른다. 그런 다음 프로토타입(시스템의 Working model)이 만들어지며 이 프로토 타입은 첫 번째 시스템으로서 다른 요구사항 수집 및 작동 여부가 목적이다. 

- 장점

=> Linear Sequential과 달리 배포되기전에 고객들이 소프트웨어를 확인을 해볼 수 있다.

=> 적절하며 정확한 요구사항들을 추출해낼 수 있으며, 고객의 요구사항을 만족 시킬 수 있다.

=> 프로젝트에 대한 고객의 참여를 구축할 수 있다.

- 단점

=> 프로토타입이 완성된 제품이라 잘못된 생각을 만들 수 있음. 

=> 프로토타입을 부풀려 최종 시스템에 대한 기대감을 높일 수 있음.

=> 관리와 제어가 어려움.(어느 단계까지 진행되었는지 평가하기가 어려움)

5) RAD(Rapid Application Development Model)

- RAD는 우수한 소프트웨어 개발 도구를 이용하여 전통적인 개발 방법보다 더 적은 시간과 비용을 투자하더라도 보다 나은 품질의 소프트웨어를 개발할 수 있는 소프트웨어 개발 과정을 말함.(60-90일 내에 완선한 시스템을 만들어냄)

- 재사용가능한 프로그램 콤포넌트들을 사용한다는 점이 특징이다.

- 단점

=> 대규모의 확장 가능한 프로젝트를 진행하기 위해서는 여러 팀들이 구성되어야 하므로 많은 인적 자원이 요구됨

=> 개발자와 클라이언트 모두 제시간에 시스템을 완성하기 위해서 신속하고 정확한 행동이 요구된다.

6) Evolutionary Process Model(Incremental Mode)

- 소프트웨어에 요구되는 기능이나 성능 조건들을 우선 순위, 난이도, 상관 관계등을 고려해 몇 개의 그룹으로 나누어 이들을 점차적, 반복적으로 구현 및 추가해가는 모델

- 위의 그림에서 알 수 있듯이 Linear Sequential Model(Waterfall Model)과 Prototype Model이 결합된 형태이다. 

- 소프트웨어의 기능을 나누어 점진적으로 개발하며, 각 Incremental마다 실제로 작동 가능한 결과물을 산출할 수 있다.

- 장점

=> 단계마다 product를 test한 다음 incremental을 위한 계획을 수립할 수 있다.

=> 개발 중 변화된 내용을 적용하기 쉽다.

- 단점

=> 추가되는 개발은 개발중인 프로세스가 아니라 이미 개발된 프로세스에 통합된다.

=> 조금 더 조심스러운 설계가 요구된다. (이 점은 장점이 될 수 도 있다. 주의 깊게 잘 해 놓으면 나중에 유지보수를 쉽게 할 수 있다는 장점이 될 수 있기 때문에.)

=> 자칫하면 Build & Fix 모델로 전락할 수 있다.

7) Spiral Model

- 단계별로 뱅뱅 돌며 프로세스가 진행되는 모양이 나타나는 모델로, 위험 분석 단계를 포함한 개발 단계를 점진적으로 반복하여 개발을 완성하는 모델

- 리스크 최소화((위험 최소화)와 점진적이라는 것이 키워드이며, 리스크 최소화를 위해 위험 분석 단계가 존재한다는 것이 가장 큰 특징

- 장점

=> 위험 관리로 인해 위험성이 큰 프로젝트를 수행 할 수 있음

=> 고객의 요구사항을 보다 더 상세히 적용 할 수 있으며, 변경되는 요구사항에 대해서도 정요이 가능

- 단점

=> 프로젝트 기간이 오래 걸린다는 점과 반복 단계가 길어질수록 프로젝트 관리가 어렵다는 단점이 있음

=> 클라이언트를 납득시키기 어려움

8) WINWIN Spiral Model

- Spiral Model의 협의 작업의 부족한 점을 보완한 현실적인 프로세스 모델

- 각 타원의 진행 맨 처음마다 협상 작업이 있음

=> 시스템에서 주요 Stakeholder(만들려는 시스템과 관련있는 사람 또는 장치)을 인식하며 이 Stakeholder들이 만족할 사항들을 결정한다. 개발자들과 stakeholder들이 서로 만족할 수 있는 상황(WINWIN)들을 협상한다.

9) Component-Based Development

- 독립적인 업무 또는 기능을 수행하는 소프트웨어의 모듈인 컴포넌트를 기반으로 기존의 컴포넌트를 조립하거나 신규로 개발하는 방법이다.

- Spiral Model의 많은 특징등을 결합시켰다.

- 개발에 요구되는 방복적인 접근 방법을 가진 진화적인 특성을 가지고 있다.

- 이미 패키지지화 된 컴포넌트 또는 클래스를 재사용하여 어플리케이션을 구성한다.

- 높은 재사용율로 개발시간과 프로젝트 비용 등을 줄일 수 있다.

10) Formal Methods Model

- 수학적인 식으로 컴퓨터 소프트웨어의 사양을 표한하는 프로세스 모델이다.

- 엄격한 수학적인 표현으로으로 소프트웨어를 적절한 기준으로 검증 할 수 있다.

- 수학적인 식은 아주 명확하게 표현할 수 있다는 장점이 있으며, 단점으로는 많은 시간과 노력, 그리고 많은 배경지식을 요구한다.