Ch2. Software Processes(1)

Topic coverd

소프트웨어 공학은 소프트웨어 개발의 전과정에 관여한다.

• 소프트웨어 프로세스 모델
  (어떤 순서대로 activities를 배치해서 개발할 것인지)
• 프로세스 activities
• 변화에 대처하기
• 프로세스 개선
  
  

The software process

소프트웨어 시스템을 개발하기 위하여 필요한 과정(작업 순서)

• 소프트웨어 개발 프로세스는 다양하나, 다음 네가지를 모두 포함한다.
  -Specification: 시스템의 기능을 정의한다
  -Design and implementation: 시스템의 구조를 정의하고 구현한다
  -Validation: 예상했던 대로 동작하는지 검증한다
  -Evolution: 요구 변화에 대해 대응한다
• 소프트웨어 프로세스 모델은 한 프로세스의 추상적인 표현법으로, 특정한 관점에서의 프로세스를 보여준다.

Software process models

Software process models

소프트웨어 프로세스 모델들의 각 목적과 장단점

1. Waterfall model
   : *Plan-driven 모델. Specification과 development가 별개의 단계로 명확히 구분된다.
   *plan-driven: 계획이 많은 비중을 차지하는 프로세스
2. Incremental development
   : Specification, development 그리고 validation이 명확히 구분되어 있지 않다(plan-driven이나 agile일 수 있음).
3. Integration and configuration
   : 시스템을 변경 가능한 이미 존재하는 컴포넌트로 구성한다(plan-driven이나 agile일 수 있음).
4. V-model
5. Prototyping

+) agile 등 프로세스 모델은 더 많다.

Waterfall model phases

폭포수 모델(위에서 아래로 떨어지는 폭포 형태의 프로세스)
전통적인 모델로, 실제로 기업에서 적용하는 경우는 거의 없다.
대규모 시스템인 경우 활용한다.

1. 요구사항 정의
2. 시스템 그리고 소프트웨어 설계
3. 구현 및 작은 단위의 테스팅
4. 각 단위를 통합한 전체 시스템 테스팅
5. 운용과 유지보수

Waterfall 모델은 프로세스를 단계별로 나누어, 프로젝트를 완강하게 구분한다. 하나의 단계가 끝나면 다음 단계로 넘어가고, 넘어간 단계로 다시 돌아가지 않는다. 따라서 고객의 요구에 대응하기 어렵다.

설계 과정에서 변화가 제한되어 있고, 요구사항이 확실한 경우에만 적합하다. 적은 기업 만이 이러한 '안정적인 요구'를 가지고 있는데, 따라서 큰 시스템 프로젝트에 적용된다. 프로세스가 명확히 구분되어 있어, 관리가 용이하기 때문에 서로 다른 업체들이 협력하는 경우에도 적합하다.

Process activities

현실에서는 프로세스 각 액티비티가 확실하게 구분되지 않는다.

기본 네가지의 프로세스 액티비티(Specification, development, validation and evolution)은 각 개발 프로세스에서 다르게 조직된다.

예를 들어, waterfall 모델의 경우 차례차례로 조직되는 반면에 incremental 개발은 각 액티비티가 명확하게 구분되어 차례로 조직되지 않는다.
(model이 다르다는 것은 액티비티가 다르게 조직되어 있다는 것)

Software specification

요구사항과 제어사항(시스템 운용과 개발에서)을 확립하는 단계

• Requirements engineering process(요구 공학 프로세스)

  1. 요구사항 도출과 분석
     • 고객이 시스템에 요구하고 기대하는 것이 무엇인가?
  2. 요구사항 정의
     • 요구사항을 자세하게 정의
  3. 요구사항 검증
     • 요구사항이 가능한지 확인

• 요구사항 도출과 분석을 한 뒤 요구사항을 정의하고, 만약 정의할 수 없는 경우 다시 도출과 분석으로 돌아가는 반복 과정
• 각 과정 별로 문서 도출

Software design and implementation

소프트웨어 설계와 구현

• 시스템 specificaiton을 실행가능한 시스템으로 변환하는 과정
• 소프트웨어 design
  • specification을 실현화한 소프트웨어 구조 설계
• Implementation
  • 설계한 구조를 실행 가능한 프로그램으로 구현
• design과 implementation은 긴밀하게 연관되어 있다(inter-leaved)
  (실제로는 implementation하면서 design하게 되는 경우가 많다)

Design activities

• Architectural design
  : 시스템의 전체적인 구조와 주요 컴포넌트(서브 시스템 또는 모듈)를 정의하고, 그들의 관계 그리고 어떻게 배치할지 설계
• Database design
  : 시스템 데이터 구조와 그것이 데이터베이스에서 어떻게 표현되는지 설계
• Interface design
  : 시스템 컴포넌트들 간의 인터페이스들을 정의
• Component selection and design
  : 재사용 가능한 컴포넌트 찾기, 또 만약 이용가능하지 않다면 어떻게 운용할지 설계

A general model of the design process

System implementation

시스템 구현

• 프로그램 또는 프로그램들을 개발하거나 응용 시스템(an application system, 이미 존재하는 app 사용)으로 소프트웨어 구현
• 대부분 소프트웨어 시스템 유형은 Design과 Implementation가 인터리브(interleaved)된다.
• 프로그래밍(Programming)은 표준화된 과정이 없는 개별적인 과정
• 디버깅(Debugging)은 문제(faults)를 찾고 이를 해결하는 과정

Software validation

소프트웨어 검증

• V & V: Verification and Validation
• Verification은 시스템이 specification과 부합하는지 (A->A)
• Validation은 시스템의 요구사항을 customer가 만족하는지 (A->A')
  확인하는 과정
• Checking과 review 과정 그리고 *system testing 포함
• system testing은 시스템이 처리할 실제 데이터를 활용하여, specification에서 이끌어낸 테스팅 케이스로 시스템을 실행해보는 것을 포함
• 대부분의 V & V activity가 testing 단계에서 발생한다.

Testing stages

테스팅 종류

• Component testing 컴포넌트의 기능 테스팅
  • 각각의 컴포넌트를 독립적으로 테스트한다
  • components는 functions, objects, 또는 그것들을 그룹화한 것이 될 수 있다
• System testing
  • 전체 시스템 테스팅
  • 컴포넌트 사이의 의도하지 않은 상호 작용 또는 컴포넌트 인터페이스 문제로 인한 오류 탐색
  • 대규모 시스템의 경우, 서브시스템 별 다단계 프로세스로 진행
• Customer testing
  • customer의 요구를 충족하는지 확인하기 위해서 customer data로 테스팅한다
  • 판매용 소프트웨어의 경우, beta testing
  • Customized product의 경우 요구사항 명세서(specification)의 오류를 발견할 수 있다

Software evolution

개발 이후 유지 보수

• 소프트웨어는 내재적으로 개발하고도 유연하게 고칠 수 있다
• 비즈니스 환경의 변화로 요구사항이 변경되는 경우, 소프트웨어를 변경시켜 변화된 비즈니스 환경을 지원해야 한다
• 완전히 새로운 소프트웨어 시스템 개발은 거의 없으므로, 개발과 유지 보수는 연속적인 활동으로 받아들이고 있다