1. SW Process
앞선 글에서와 같이, 소프트웨어 프로세스는 기본적으로 4가지 단계로 구성된다. 소프트웨어의 기능과 제약조건을 명세하는 단계, 실제 소프트웨어의 구현 단계, 소프트웨어 검증 단계, 그리고 계속해서 변화하고 진화하는 발전 단계이다.
소프트웨어 프로세스를 설명할 때에는 이 뿐만 아니라, 다음 세가지도 묘사되어야 한다.
1) Products and Deliverables : 프로세스 액티비티의 결과물
2) Roles : 프로세스에 관련된 팀원들의 역할
3) Pre and Post conditions : 프로세스 액티비티 전후 조건
2. SW Process Model (= SW Development Life Cycle = SDLC)
소프트웨어 프로세스를 하이레벨로, 추상화(단순화)하여 표현한 것을 'SW Process Model'이라고 한다. 대표적으로 소프트웨어 프로세스 모델에는 다음과 같이 3가지가 있다.
1) Waterfall Model
S->D->V->E 각 소프트웨어 개발 단계가 독립적으로 분리되어 있는 단계이다. Plan-driven Process에 적합한 모델이다.
소프트웨어 개발을 시작하기 전에 모든 프로세스의 activity를 계획한다.
이전 단계가 끝나기 전까지는 다음 단계는 실행되지 않는다.
소프트웨어 요구사항이 빠르게 변화하는 환경에는 맞지 않는 모델이다.
Embedded system, Critical System과 같은 특정 타입의 시스템에 적절하다.
(1) Requirements 분석 및 정의
(2) System과 Software 디자인
(3) Implement and Unit Testing
-> Implement를 하면서 유닛 테스팅을 한다.
(4) Integration and Ssytem Testing
(5) Operation and Maintenance
2) Incremental Development
각 단계별로 철저하게 구분되어 구현하는 것이 아니라, S했다가 D를 하고, D를 했다가 다시 돌아와서 S를 하는 등 여러 기능들을 하나씩 쌓아가는 것이다.
Specification, Development, Validation의 세 단계는 분리되어 있지 않고 interleaving한다. 초기 구현을 하고, 유저로부터 피드백을 받고, 다시 여러 버전으로 소프트웨어가 진화하게 된다. 구현을 하다가 다시 명세 단계로 돌아갈 수 있다.
변화된 요구사항을 구현하는 비용이 폭포수 모델에 비해서 더 저렴하다.
개발 과정에서 유저와 고객의 피드백을 얻는 것이 더욱 쉽다.
사용 가능한 소프트웨어를 고객에게 초기에 사용하도록 하는 것이 가능하다.
그러나 프로세스가 잘 보이지 않는다는 단점이 있다. activity가 전체 system의 어느 단계에 있는지 불분명하다.
더불어 새로운 increments가 더해질수록 시스템 구조는 다운그레이드되는 경향이 있다. 일반적으로 변화는 코드를 더욱 더 더럽게 만들고, 결국 새로운 기능을 더하는 것은 더 어렵고 비용이 많이 들게 된다. 이를 해결하기 위해 주기적으로 소프트웨어를 리팩토링해야 한다.
상당한 양의 소프트웨어 개발 비용과 리스크를 줄이며, 더 빠르게 시스템을 deliver할 수 있다.
요구사항을 현실적인 이유로 타협하게 되어 실제 이용자들의 니즈를 충족시키지 못할 수도 있다. 더불어 시스템을 발전하는 데 일정 부분의 통제가 어려울 수 있다.
3) Integration and Configuration
위 두 모델은 모두 코드를 처음부터 개발하는 모델이지만 Integration and Configuration 모델은 오픈 소스 코드를 활용하여 통합시키는 모델이다.
(1) Requrements Specification
디테일하지는 않지만, 간략하게 가장 필수적인 요구사항들에 대해서 명세하는 단계
(2) Software Discovery and Evaluation
사용 가능한 코드를 서치하고, 올바른 기능을 제공하는 컴포넌트/시스템인지 평가하는 단계
(3) Requirements Refinement
서치를 토대로 찾은 이용가능한 코드를 토대로, 요구사항을 더욱 더 구체화하여 개선한 형태로 명세하는 과정이다.
(4-1) Application System Configuration (COTS IS AVAILABLE)
바로 상용 가능한 시스템일 경우에 해당한다.
- COTS = Commercial Off the Shelf System. 상용 기성품 소프트웨어로서, 제3자 입장의 업체가 사전에 만들어놓은 소프트웨어
(4-2) 새로운 기능을(찾지 못한 기능) 개발하고 통합 (COTS IS NOT AVAILABLE)
재사용 가능한 컴포넌트와 새롭게 개발한 컴포넌트를 통합시켜 새로운 시스템을 만듦
3. Process activity
Specification, Development, Validation, Evolutiondml 4가지 프로세스 Activity는 각 모델에 따라서 다르게 구성된다.
1) Specification
- 어떠한 서비스들이 요구되는지 이해하고 정의하기
- 시스템 작동과 개발의 제약조건을 밝히기
- 명세 과정에서 발생하는 실수는 이후에 시스템 디자인과 개발에서 문제로 이어질 것이다.
(1) Requirements Engineering Process
Requirements Elicitation and Analysis:현존하는 시스템을 관찰함으로서 요구사항을 이끌어내고, 잠재 고객들과 이야기를 나누는 것
(2) Requirements Specification : 요구사항을 문서화하는 것
(3) Requirements Validation : 구현 가능하고 현실성 있는 요구사항인지 확인하는 것
2) Software Design and Implementation
(1) Design 과정
- Architectural Design : 전체적 시스템 구조, 주요 컴포넌트와 관계를 디자인
- Database Design : 데이터 구조와 데이터베이스에 어떻게 데이터들이 표현될지 디자인
- Interface Design : 시스템 컴포넌트 간 인터페이스 디자인
- Component Selection and Design : 재사용 가능한 컴포넌트를 찾고 새로운 컴포넌트 디자인
(2) Implementation 과정
- 프로그래밍은 표준화되어 있지 않은 개개인의 actvity다.
- 테스팅은 프로그램 버그를 밝히기 위한 과정이다. 즉 오류를 드러내는 test case를 만드는 것이 테스팅의 주요 과제이다. 그렇지만 현실적으로 코드의 길이가 길수록 오류를 드러낼 테스트 케이스를 만드는 것이 어렵기 때문에, code coverage를 높이는 것이 현실적 목표다. line coverage가 100%라면 모든 코드를 실행한 것을 의미하는데, 이 coverage 비율이 높을수록 신뢰도가 높다.
- 디버깅은 이러한 버그를 고치는 과정이다.
3) Software Validation
시스템이 그 명세서와 요구사항에 따르는지 확인하는 것
요구사항 명세부터 프로그램 개발까지의 각 단계를 모두 확인하는 것
(1) Component Testing(Unit Testing)
컴포넌트/함수를 각각 모두 독립적으로 테스트하는 것이다.
Unit Testing은 함수 하나씩 그 함수의 기능을 테스트 하는것으로서 난이도는 낮지만, 오류가 나도 실제의 entry point에서 실행하면 절대 오류가 나지 않는 오류일 수도 있다(오류가 실제 오류가 아닐 수도 있다). 따라서 Unit Testing과 관련되어 False Positive를 줄이는 연구도 진행되고 있다.
(2) System Testing
컴포넌트들이 통합되어 있는 전체 시스템을 테스트하는 것이다.
System Testing은 각각의 함수를 통합해 main함수를 테스트하는 것으로서 프로그램 자체, 즉 전체 시스템을 테스트 하는 것이다. 즉 프로그램의 entry point부터 테스트하기 때문에 어렵다는 단점이 있다.
(3) Customer Testing
실제 사용자에 의해서 직접 사용하면서 테스트하는 것이다.
4) Software Evolution
소프트웨어는 기본적으로 자주 바뀔수 있으며 유연하다. 더불어 하드웨어를 바꾸는 것보다는 소프트웨어를 바꾸는 것이 훨씬 더 저렴한 경우가 많다. 따라서 요즘은 개발과 유지보수를 같은 연장선상에서 보기도 한다.
재 작업 비용을 줄이는 두가지 방법
(1) Change Anticipation
가능성이 있는 변화에 대해서 프로토타입을 먼저 만들어보기
(2) Change Tolerance
시스템이 쉽게 변화할 수 있도록 코드 리팩토링 등 프로세스를 디자인 하기
4. 변화에 대응하는 방법
1) Prototyping
- 실제 구현품은 아니지만 이를 통해 고객에게 보여줌으로써 빠진 부분이나 바뀌니 요구사항을 반영할 수 있다.
- 프로토타입 개발에서는, 특정 기능은 뺄 수 있고, response time이나 memory usage 등 기능이 아닌 요구사항에 대해서는 신경을 쓰지 않으며, 에러 핸들링을 무시해도 된다.
- 유저가 글로 보는 것보다 직관적이다.
- 그러나 결국 프로토타입은 결과물이 아니고, 프로토타입 테스터도 실제 고객이 아닐 수 있다.
2) Incremental Delivery
- 고객에게 초반에는 핵심적 기능부터 제공하고, 점차 기능을 추가하여 늘려가는 방법
- 고객이 초기 increments에 대해 프로토타입처럼 이용하고 경험을 할 수 있다. (전체 시스템이 개발되기 전에 일찍 사용해볼 수 있다)
- 시스템에 변화를 수용하기 상대적으로 편리하다.
- 가장 중요한 기능부터 제공하므로, 중요한 기능은 누적되어 테스팅 횟수가 늘어난다.
- 기존 시스템을 새로운 것으로 바꾸면서 유저는 기존의 기능이 사라지니 불편할 수도 있다.
