Process Activities

4개의 기본적인 Process Activities가 있다.

• Specification
• Development
• Validation
• Evolution

Requirements Engineering Process

요구사항을 파악하고, 제한 사항을 파악한다. 이를 통해 최종적으로 SRS(사용자 요구 사항)을 만든다.

• Requirements elicitation and analysis
  • 사용자들의 요구사항과 시스템에 바라고 있는 점들은 무엇인가?
• Requirements specification
  • 요구 사항의 상세한 부분들은 어떤 것들이 있는가?
• Requirements validation
  • 요구 사항이 실현 가능성이 있는가?(어떤 제한 사항이 있는가?)

Software Design and Implementation

• Software design : 정의된 요구사항들을 따라서 소프트웨어의 구조를 설계한다.
• Implementation : 설계된 요구사항들을 구현한다.
  

Design Activities

• Architectural design
  • 시스템 구조, 구성하는 요소, 요소들의 관계성을 정의하고, 어떻게 구분할 것인지를 정한다.
• Interface design
  • 요소들 간의 인터페이스를 정의한다.
• Component selection and design
  • 재사용 가능한 요소들을 찾는다. 만약 있다면 어떻게 사용할 것인지 설계한다.
• Database design
  • 데이터들과 데이터를 보관하는 데이터베이스를 어떻게 만들지 설계한다.

Implementation Activities

• 소프트웨어를 만들고 적용시키는 활동이다.
  • Programming
    • 특별히 정해진 방법 없이 독립적으로 프로그램을 만드는 것을 의미한다.
    • Clean code + Refactoring + Unit Testing 등을 지켜야 한다.
  • Debugging : 문제가 일어났을 때 버그를 찾는 액티비티로, 프로그램의 오류를 찾는 Testing과 다르다.

Software Validation

확인과 검증을 하는 단계이다.

• Verification and Validation (V&V) intends to show that a system conforms to its specification (→ Verification) and meets the requirements of the system customer (→Validation).
• 코드를 확인하고 시험하며 테스트한다.
• 테스트에는 대부분 V&V를 사용한다.

Software Testing

테스팅의 과정

• 컴포넌트 테스팅
  • Unit testing / Module testing
  • 각각의 컴포넌트를 독립적으로 테스트한다.
  • 컴포넌트들을 기능이나 비슷한 부류끼리 그룹짓는다.
• 시스템 테스팅
  • • Integration Testing
  • 전체적인 시스템을 테스트한다.
  • 핵심 기술을 중심적으로 테스트한다.
• 수락(Acceptance) 테스팅
  • 고객을 만나고 요구사항을 잘 구현했는지 체크한다.
  • 확인 작업
    

V-Model

• Unit / Components에서 Module test를 통해서 Unit/Components Specs를 나오게 한다. 이 과정으로 나온 결과물은 개별적으로 보장되어 있다.
• SubSystm에서 Integration Test를 통해서 Subsystem Design/Specs를 낸다. 각각의 Component들을 비슷한 부류나 서로 통신해야 하는 것 들 끼리 모으고 테스트한다.
• System Integration에서 System Test를 통해서 System Specification을 낸다. 모든 Component들을 모으고 하나의 시스템을 테스트 한다.
• Delivered Package를 통해 User Acceptance를 거친다. 알파/베타 테스트가 예시이며, 사용자의 요구 사항을 받고 적용한다.
• 최종적으로 결과물을 낸다.(Actual Needs and Constraints)

Software Evolution

소프트웨어는 필연적으로 바뀌고 진화해야 한다. 사용자의 요구사항은 고정되어 있는 것이 아니라 변하기 때문에 진화(유지보수)하지 않으면 쓸모가 없다.