소프트웨어 프로세스(1)

1. 1장 : 단계별 소프트웨어 개발과 진화

① 소프트웨어 프로세스

    ▪ 소프트웨어 시스템을 개발하기 위해 필요한 일련의 활동들의 구조적 집합
- Specification(명세)
- Design(설계)
- Validation(확인)
- Evolution(진화)

② 소프트웨어 프로세스 모델

▪ 소프트웨어 프로세스의 추상적 표현
- The waterfall model
- Evolutionary development
- Formal systems development
- Reuse-based development. 

③ 일반적인 소프트웨어 프로세스 모델(Generic software process models)

▪ 폭포수 모델(The waterfall model): 명세(Specification), 설계(Design) 등 각 단계별 작업이 분리되어 있으며, 한 단계를 마치고 다음단계로 넘어가게 된다.
▪ Evolutionary development: 초기에 얻어진 추상적인 명세로부터 계속적으로 고객의 요구사항을 고려하면서 원하는 시스템이 완성될때까지 추가적인 명세와 개발 및 확인을 반복하게 된다.
▪ Formal systems development: 수학적인 시스템 모델을 만들고 이를 수학적인 방법으로 변형시켜서 실제 시스템을 구하게 된다.
▪ Reuse-based development: 기존에 존재하는 컴포넌트를 조합하여 시스템을 개발한다.

④ The “Waterfall” model

▪ 소프트웨어 개발 프로세스의 최초모델은 다른 공학에서 사용하는 프로세스로부터 유도된 것이었는데(Royce, 1970), 이에 대한 것이 아래 그림에 있다.
p.45 Figure3.1 The software life cycle

- Requirements analysis and definition
시스템의 서비스, 제약사항과 목표등을 시스템 사용자와의 면담을 통해 얻게 되며, 그 내용을 보다 자세하게 정리하여 시스템 명세(System specification)을 구한다.

 

- System and software design
시스템 설계를 위해 요구사항을 소프트웨어 및 하드웨어 관련 사항으로 나눈뒤, 전체 시스템의 아키텍쳐를 구한다. 소프트웨어 설계의 경우는 기본적인 시스템의 구성요소들과 그들의 관계에 대해 기술하게 된다.

 

- Implementation and unit testing
이 과정에서 소프트웨어 설계는 프로그램이나 실제 구현상의 단위로 쪼개어 진다. 유닛 테스팅(unit testing)의 경우는 각각의 유닛(unit)이 명세(specification)을 만족하는지 확인(verification)을 하게 된다.
 

 

- Integration and system testing
전단계에서 구현된 프로그램 유닛(program unit)을 통합하여 전체 시스템을 가지고 소프트웨어 요구사항에 맞는지를 테스트한다. 테스트가 완료되면 소프트웨어 시스템은 고객에게 전달된다.

 

- Operation and maintenance
이 단계가 가장 주기가 길다. 시스템은 설치되어 실제 사용에 들어가게 된다. 유지보수(maintenance)는 이전 단계에서 발견하지 못했던 에러(error)를 수정하거나 새로운 요구사항에 대한 추가적인 시스템 개선등의 작업을 하는 것을 말한다.

⑤ Waterfall model의 고려사항

▪ 각 단계가 분리되어 독립적이기 때문에 유연하지 못하다.
- 즉, 고객의 바뀌는 요구사항에 대응하기가 어렵다.
=> 그러므로, 이 모델은 요구사항(requirements)가 명확한 경우에 사용하는 것이 적당하다.

⑥ Evolutionary development

▪ 이 모델은 초기 구현을 사용자에게 보여주고, 사용자의 피드백(feedback)을 통해 시스템을 점진적으로 완성시켜 나가는 것이 기본적인 아이디어이다. 크게 아래와 같이 2가지 방법으로 나뉜다.

 

- Exploratory development : 고객과 함께 요구사항을 계속적으로 찾아가면서 우선 확정된 부분부터 개발을 점진적으로 진행해 나가 최종적으로 완성된 시스템을 구하는 것이다. 즉, 명확히 이해된 부분부터 시작해서 추가적인 요구사항들을 덧붙혀 나가는 방식이다.

 

- Throw-away prototyping : 이 방법은 고객의 요구사항을 명확히 파악하는데 목적이 있다. 그러므로 시스템에 대한 보다 나은 요구사항(requirements)를 도출하기 위해 명확하지 않은 부분에 대해 작업을 진행하게 된다.
p.47 Figure 3.2 Evolutionary development


⑦ Evolutuonary development 고려사항
▪ 프로세스가 가시적이지 않다.
- 관리자는 진행사항을 측정하기 위해 일반적으로 관련 산출물(deliverables)을 필요로 하는데, 시스템이 자주 바뀌기 때문에 모든 버전에 대해 문서를 만드는 것은 비용효율적이지 못하기 때문에 이러한 문제가 발생한다.
▪ 시스템의 구조가 허술한 경우가 많다.
- 계속적인 시스템의 변경 때문에 소프트웨어 구조가 붕괴될 수도 있다. 이렇게 될 경우 유지보수에 대한 비용이 더 증가하게 된다.
▪ 특별한 도구나 기술이 요구될 수 있다.
- 고객과 다양한 도메인에 대한 요구사항을 받아들여야 하기 때문에 각각의특별한 경우와 관련한 전문가가 그리 많지 않다.
=>중,소규모의 시스템, 큰 시스템의 일부(예-사용자 인터페이스), 개발주기가 짧은 시스템의 개발에 적합하다.


⑧ Formal systems development

▪ 시스템 명세를 수학적인 방법으로 표현, 변환하여 실행가능한 프로그램을 얻는 방법이다.
▪ 변환을 할 때는 정확성이 유지되어야 한다.(correctness-preserving)
▪ 예) Cleanroom process

p. 48 Figure 3.3 Formal systems development

p. 48 Figure 3.4 Formal transformation
T:변환 (Transformation)
R:개선 (Refinement)
P:프로세스 (Process - transformational development process) 

⑨ Formal systems development 고려사항

▪ 수학적인 기법을 사용하므로 관련 기술의 습득이나 훈련이 필요하다.
▪ 사용자 인터페이스(user interface)같이 수학적인 명세가 어려운 부분이 있다.
=> 안전성(safety)나 보안(security)이 요구되는 Critical system에 적용

⑩ Reuse-oriented development

▪ 기존의 컴포넌트나 COTS(Commercial-off-the-shelf)시스템을 체계적으로 재사용하여 빠르게 새로운 시스템 개발 Reuse-oriented development
- 컴포넌트 분석(Component analysis) : 
- 요구사항 수정(Requirements modification)
- 재사용을 위한 시스템 설계(System design with reuse)
▪ 주요 프로세스 단계
- 개발 및 통합(Development and integration)
▪ 장점
- 개발해야 할 소프트웨어의 양을 줄일 수 있다.
- 비용(cost)과 위험(risk)를 줄일 수 있다.
- 빠른 개발(faster delivery)이 가능
▪ 단점
- 사용자의 요구사항을 완전히 소화하기 어렵다.
- 시스템 진화에 대한 통제권을 상실할 수 있다. (예-재사용 컴포넌트의 새로운 버전에 대한 주도권이 없음)

P.50 Figure 3.5 Reuse-oriented development
   

• 기타

최근 “eXtreme Programming” 이라는 Incremental approach가 개발되었다.(Beck, 1999) 이는 프로세스 과정에 고객이 직접 개입하여 지속적이고 추가적인 개발이 이루어진다. 즉, 개발자와 고객과의 커뮤니케이션이 중요하며, 이들간의 피드백이 자주 그리고 빠르게 이루어진다.

2. 2장 : 단계별 소프트웨어 개발과 진화

① Software specification

▪  시스템의 서비스나 조작에 대한 제약사항 등 요구사항을 명세하는 단계로 일반적으로 시스템 개발 초기에 이루어진다. 이러한 활동을 요구공학(Requirements engineering)이라고 부르기도 하는데, 이와 같이 초기에 이루어지는 요구분석단계에서 오류가 생길 경우 추후 이루어지는 설계나 구현에 막대한 지장을 주기 때문에 상당히 중요하다고 할 수 있다.

 

▪  이 단계에서 얻어지는 요구사항에 대한 산출물로는 크게 2개의 문서가 있는데, 사용자관점의 높은 수준의 요구사항 문서와 시스템 개발자를 위한 보다 상세한 시스템 명세 문서이다.

 

▪ 요구공학 프로세스(Requirements engineering process)
- Feasibility study : 현재의 소프트웨어 또는 하드웨어 기술로 시스템 실현이 가능한지를 확인하는 과정이다. 만들려는 시스템이 사업적인 관점에서 볼 때 비용효율적이어야 하며, 주어진 예산이나 시간내에 달성할 수 있는지를 조사해야 한다. 또한 이 작업은 빠르고, 큰 비용없이 이루어질 수 있어야 한다. 결국, 여러가지 현실적인 면을 고려해 볼 때 시스템 개발을 해야할지의 여부를 판단하는 단계라고 볼 수 있다.

- Requirements elicitation and analysis : 기존의 시스템을 관찰하거나 사용자들과의 면담을 통해 시스템 요구사항을 도출해내는 과정이다. 이 과정에서 시스템 모델이나 프로토타이핑(prototyping)이 만들어지기도 한다.

- Requirements specification : 도출된 요구사항을 형식에 맞추어 문서로 정리하는 단계이다. 이 단계에서 사용자 요구사항(user requirements)과 시스템 요구사항(system requirements)가 정리된다. 사용자 요구사항은 고객이나 최종 사용자들을 위한 추상적인 문장으로 정리된 것이고, 시스템 요구사항은 제공되어야할 기능들이 보다 명확하고 자세하게 정리된 것이다.

- Requirements validation : 요구사항에 대한 현실성(realism), 일관성(consistency), 완전성(completeness)를 확인한다. 이 과정에서 요구사항의 오류들이 발견되어야 한다.

P.55 Figure 3.8 The requirements engineering process

② Software design and implementation

▪ 소프트웨어 설계(Software design) 단계에서는 구현될 소프트웨어의 구조, 스템의 일부인 데이터나 시스템 컴포넌트 사이의 인터페이스, 사용된 알고리즘 등을 상세하게 기술한다.

 

▪ 구현(implementation)단계에서는 통해 시스템 명세(system specification)으로부터 실행가능한 프로그램(executable program)을 만들게 된다.

 

▪ 설계 프로세스 활동
- Architectural design : 시스템을 구성하는 서브 시스템(sub-system)과 그들간의 관계를 파악하고 문서화
- Abstract specification : 각각의 서브 시스템에 대해서 서비스와 제약사항들에 대해 추상적으로 명세화
- Interface design : 각각의 서브 시스템에 대해서 다른 서브 시스템과의 인터페이스에 대해 설계 및 문서화. 인터페이스 명세는 모호성(ambiguity)가 없어야 하므로 정형화된 방법(formal specification)이 사용되는 경우가 많다.
- Component design : 서비스들이 다른 컴포넌트들에 할당되고 이 컴포넌트들에 대한 인터페이스가 설계된다.
- Data structure design : 시스템 구현상의 자료 구조가 자세하게 설계되고 명세화 된다.
- Algorithm design : 서비스를 제공하기 위한 알고리즘이 자세히 설계되고 명세화 된다.

p.57. Figure 3.9. A general model of the design process

▪ 프로그래밍(Programming)과 디버깅(Debugging)

- 설계를 프로그램으로 바꾸고 그 프로그램에서 발생하는 에러(error)를 제거하는 것으로, 프로그래밍은 개별적인 활동이라 볼 수 있다. 그러므로, 프로그래밍 과정에서는 일반적인 프로세스가 존재하지 않는다.
    - 디버깅(Debugging)은 프로그램의 결함(defects)를 찾고(locating) 수정(correcting)하는 작업을 의미한다.

p.60. Figure 3.10 The debugging process

③ Software Validation

▪  Verification: 시스템이 주어진 명세(specification)에 따라 만들어졌는지 확인

 

▪  Validation : 시스템이 사용자 또는 고객이 원하는 대로 만들어졌는지 확인

 

▪  V&V 기술은 개발 각 단계에서 수행되는 정적 검증방법인 inspection 기술과 아래 테스팅 프로세스를 포함한다. P.421 Figure 19.1 Static and dynamic verification and validation
▪  테스팅 프로세스(Testing process)
- Unit testing : 독립적인 컴포넌트에 대해서 제대로 동작하는지를 테스트한다. 
- Module testing : 관련한 컴포넌트들을 묶어서 모듈별로 테스트를 진행한다.
- Sub-system testing : 서브시스템을 구성하는 모듈을 묶어서 테스트를 진행한다. 큰 규모의 시스템의 경우 인터페이스 불일치(Interface mismatch)문제가 자주 발생하므로, 이러한 모듈 인터페이스 오류(module interface error)를 발견하는데 주로 초점이 맞추어진다.
- System testing : 서브 시스템을 통합하여 전체 시스템을 테스트한다. 서브시스템간의 인터페이스 문제를 찾기 위한 것이며, 시스템의 기능적(functional), 비기능적(non-functional) 요구사항을 확인하며, 창발적 시스템 속성(emergent system properties)에 대해 테스트한다.
- Acceptance testing : 시스템이 실제로 사용되기 전 테스팅 프로세스의 마지막 단계이다. 시스템 사용자로부터 얻은 실제 데이터로 테스트가 이루어진다. Alpha testing 이라고도 불리운다.
(참고로, beta testing 은 몇몇 가망 고객들(potential customers)을 대상으로 실제로 시스템을 고객에게 전달하여 테스트하는 것을 의미한다. 시스템을 테스트하는 고객들은 사용중 문제점들을 시스템 개발자에게 보고하게 된다.)

p.61 The testing process

④ Software evolution

▪ 소프트웨어는 유연하기(Flexible) 때문에 변화할 수 있다.

 

▪ 비즈니스 환경(business circumstances)이 바뀌면서 요구사항(requirements)도 바뀔 수 있고, 그 비즈니스를 지원하는 소프트웨어도 진화하고 바뀔 수 있어야 한다.

 

▪ 개발(development)과 진화(evolution) 또는 유지보수(maintenance)의 경계가 점점 사라지고 있다.

p.63 Figure 3.13 System evolution

 

[ 정리하기 ]

1. 요약정리
▣ 소프트웨어 프로세스(Software process)는 소프트웨어 시스템을 생산하는 것과 관련한 일련의 활동이고, 소프트웨어 프로세스 모델(Software process model)은 그 프로세스를 추상적으로 표현한 것이다.
▣ 소프트웨어 프로세스는 소프트웨어 명세(Software specification), 소프트웨어 설계(Software design), 구현(Implementation)과 소프트웨어 확인(Software validation) 및 소프트웨어 진화(Software evolution)을 포함한다.

2. 참고자료

자료명	자료 설명
Ivar Jacobson著, The Unified Software Development Process, Addison-Wesley刊	-Unified Process는 UML에 익숙한 개발자를 위한 개발 과정의 표준이라 할 만하다. Unified Process의 기본 원칙은 사용사례(use-case)를 강조하며 아키텍쳐 중심적이고 반복적/점진적 개발 방식이다. -개발과정에서 나오는 여러 UML 문서를 구조적으로 관련시키고 있으며 기본 원칙들을 어떻게 적용하는지를 알려준다.
Rational Unified Process Best Practices for Software Development Teams	Ration Unified Process와 Rational社의 지원제품을 설명