Week 2 - Software Processes

1. 소프트웨어 프로세스 정의

1-1. 소프트웨어 프로세스란?

1. Specification (명세화): 시스템이 무엇을 해야 하는지 정의하는 단계.

2. Design and Implementation (설계 및 구현): 시스템의 구조를 정의하고 실제로 구현하는 단계.

3. Validation (검증): 고객이 원하는 대로 시스템이 동작하는지 확인하는 단계.

4. Evolution (진화): 변화하는 고객 요구에 맞추어 시스템을 수정하고 발전시키는 단계.

💡 소프트웨어 개발에서 프로세스가 없을 경우:

• 설계의 중요성을 깨닫지 못함: 체계적인 설계 없이 잘못된 방식으로 진행될 수 있음.

• 계획 없음, 작업 목표 없음: 명확한 계획이나 목표가 없이 진행됨.

• 체계적인 테스트 작업이나 품질 보증 활동의 필요성을 인식하지 못함: 테스트와 품질 보증이 중요하다는 인식이 부족.

• 프로세스를 묘사하고 논의할 때, 우리는 일반적으로 데이터 모델 지정, 사용자 인터페이스 설계 등과 같은 프로세스의 활동과 이러한 활동 순서에 대해 이야기한다.

• 프로세스의 설명에는 아래도 포함된다:
• Products (제품): 프로세스 활동의 결과물.
• Roles (역할): 프로세스에 관여하는 사람들의 책임을 반영.
• Pre- and post-conditions (사전, 사후 조건): 활동 전후에 참인 진술.

1-2. 좋은 프로세스의 특징

1-3. Plan-driven과 Agile

1️⃣ Plan-driven processes (계획 주도형 프로세스):

• 모든 프로세스 활동이 사전에 계획되고, 진행 상황이 그 계획에 따라 측정되는 프로세스를 의미.

• 원칙적, 계획적인 접근 방식으로, 처음부터 모든 단계가 명확히 정의됨.

2️⃣ Agile processes (기민형 프로세스):

• 계획이 점진적으로 이루어지며, 변화하는 고객 요구에 맞춰 프로세스를 수정하는 것이 더 용이한 프로세스.

• 기민한 방식으로, 고객의 요구 변화에 빠르게 대응할 수 있음.

• 실무에서는 대부분의 프로세스가 두 접근 방식을 모두 포함하고 있으며, 올바르거나 잘못된 소프트웨어 프로세스란 존재하지 않는다.

2. 소프트웨어 프로세스 모델

1. 폭포수 모델
• Plan-driven 모델.
• 명세와 개발의 별도의 구분된 단계.

2. 점진적 개발
• 명세, 개발, 검증이 상호 연관됨.
• Plan-driven 혹은 Agile 방식일 수 있음.

3. 통합 및 구성
• 시스템이 기존의 구성 가능한 구성요소로부터 조립됨.
• Plan-driven 혹은 Agile 방식일 수 있음.

1️⃣ 폭포수 모델

1. 요구사항 분석 및 정의

2. 시스템 및 소프트웨어 설계

3. 구현 및 단위 테스트

4. 통합 및 시스템 테스트

5. 운영 및 유지보수

📌 폭포수 모델의 문제점

1. 프로젝트를 별개의 단계로 유연하지 않게 분할하면 변화하는 고객 요구사항에 대응하기 어렵다.
• 따라서 이 모델은 요구사항이 굉장히 명확하고 설계 과정 중 변경이 제한적일 때만 적합하다.
• 즉 소수의 몇몇 비즈니스 시스템만이 안정적인 요구사항을 가지고 있다.

2. 폭포수 모델은 주로 시스템이 여러 사이트에서 개발되는 대규모 시스템 엔지니어링 프로젝트에 사용된다.
• 이러한 상황에서, 폭포수 모델의 Plan-driven 특성이 작업을 조율하는 데 도움이 된다.

2️⃣ Incremental development (점진적 개발)

• 점진적 개발의 이점
1. 변화하는 고객 요구사항 수용 비용 감소: 폭포수 모델에 비해 분석과 문서화 작업의 재작업 양이 훨씬 적다.
2. 고객 피드백 수집 용이성: 고객이 소프트웨어 데모를 보고 구현된 기능에 대해 즉시 의견을 제시할 수 있다.
3. 유용한 소프트웨어의 빠른 제공 및 배포: 고객이 폭포수 방식보다 더 일찍 소프트웨어를 사용하고 가치를 얻을 수 있다.

• 점진적 개발의 단점
1. 프로세스의 가시성 부족:
• 관리자들이 진행 상황을 측정하기 위해 정기적인 산출물이 필요함.
• 시스템이 빠르게 개발되는 경우, 모든 버전에 대한 문서를 생성하는 것은 비용 효율적이지 않음.
2. 시스템 구조의 점진적 악화:
• 새로운 증분(increment)이 추가될 때마다 시스템 구조가 저하되는 경향이 있음.
• 소프트웨어 개선을 위한 리팩토링에 시간과 비용을 투자하지 않으면, 지속적인 변경으로 인해 구조가 손상될 수 있음.
• 시간이 지남에 따라 추가적인 소프트웨어 변경 작업이 점점 더 어렵고 비용이 많이 들게 됨.

2️⃣ Integration and configuration (통합 및 구성)

• 소프트웨어 재사용 기반:
• 기존 컴포넌트나 애플리케이션 시스템을 통합하여 새로운 시스템을 구축한다.
• 이는 종종 'COTS(Commercial-off-the-shelf) 시스템'이라고도 불린다.

• 재사용 요소의 구성:
• 재사용되는 요소들은 사용자의 요구사항에 맞게 동작과 기능을 조정할 수 있도록 구성될 수 있다.

• 표준 접근 방식:
• 재사용은 현재 많은 유형의 비즈니스 시스템을 구축하는 데 있어 표준적인 접근 방식이 되었다.

• 독립형 애플리케이션 시스템 (Stand-alone application systems):
• 때로는 COTS(Commercial Off-The-Shelf)라고도 불린다.
• 특정 환경에서 사용하기 위해 구성된 시스템이다.
• 예: 사무용 소프트웨어 패키지, ERP 시스템 등

• 객체 컬렉션 (Collections of objects):
• 컴포넌트 프레임워크와 통합되도록 패키지로 개발된 객체들의 모음이다.
• .NET이나 J2EE와 같은 프레임워크와 함께 사용된다.
• 예: UI 컴포넌트 라이브러리, 데이터 접근 객체 등

• 웹 서비스 (Web services):
• 서비스 표준에 따라 개발되었으며, 원격 호출이 가능하다.
• 네트워크를 통해 접근 가능한 기능을 제공한다.
• 예: 결제 처리 서비스, 지도 API, 날씨 정보 서비스 등

💡 재사용 지향 소프트웨어 공학

1. 요구사항 명세: 초기 요구사항 제안

2. 소프트웨어 발견 및 평가: 요구사항 개요를 바탕으로 필요한 기능을 제공하는 구성 요소와 시스템 발견

3. 요구사항 개선: 발견된 구성 요소나 시스템을 사용하여 요구사항 개선

4. 애플리케이션 시스템 구성: 요구사항을 충족하는 경우 COTS(상용 기성품) 애플리케이션 시스템 사용

5. 구성 요소 적응 및 통합: 적합한 COTS가 있는 경우 구성 요소 개발

1. 처음부터 개발하는 소프트웨어가 적어 비용과 위험 감소

2. 시스템의 더 빠른 제공 및 배포

1. 요구사항 타협이 불가피하여 사용자의 실제 요구를 충족하지 못할 수 있음

2. 재사용된 시스템 요소의 진화에 대한 통제력 상실

3. 프로세스 활동

• 실제 소프트웨어 프로세스는 상호 교차되는 활동들로 구성됨:
• 소프트웨어 프로세스는 기술적, 협업적, 관리적 활동들이 혼합된 순서로 구성되며, 궁극적인 목표는 소프트웨어 시스템을 명세, 설계, 구현, 테스트하는 것이다.

• 네 가지 기본 프로세스 활동:
• 소프트웨어 프로세스에는 네 가지 기본 활동이 있다:
1. 명세
2. 개발
3. 검증
4. 진화

3-1. 소프트웨어 명세

📌 요구사항 엔지니어링 프로세스 흐름도

3-2. 소프트웨어 설계 및 구현

• 설계는 명세를 실현하는 소프트웨어 구조를 설계하는 것이며, 구현은 이 구조를 실행 가능한 프로그램으로 변환 하는 것이다.

1️⃣ 설계 활동

• 아키텍처 설계: 시스템의 전체 구조, 주요 컴포넌트(서브시스템 또는 모듈), 이들의 관계 및 분포 방식을 정의.

• 데이터베이스 설계: 시스템의 데이터 구조를 설계하고 이를 데이터베이스에 어떻게 표현할지를 결정.

• 인터페이스 설계: 시스템 컴포넌트 간의 인터페이스를 정의.

• 컴포넌트 선택 및 설계: 재사용 가능한 컴포넌트를 찾고, 없을 경우 설계.

2️⃣ 구현 활동

• 소프트웨어는 프로그램을 개발하거나 애플리케이션 시스템을 구성하여 구현됨.

• 설계와 구현은 상호 교차되는 활동.

• 프로그래밍은 표준화된 과정이 없으며 개인별로 다르게 수행.

• 디버깅은 프로그램의 결함을 찾아 수정하는 활동. 디버깅도 구현의 한 활동이다.

3-3. 소프트웨어 검증

• 검증 및 확인 (Verification & Validation): 시스템이 명세를 준수하고, 고객의 요구 사항을 충족하는지 확인하는 과정. 즉, 내가 설계대로 잘 구현했는지 / 사용자 요구사항이 잘 반영되었는지 확인한다.

• 검증 과정은 시스템 테스트와 리뷰를 포함한다.

• 테스팅은 가장 많이 사용되는 V&V 활동으로, 테스트 케이스를 통해 시스템을 검증한다.



• 컴포넌트 테스트: 개별 컴포넌트를 독립적으로 테스트.
• 시스템 테스트: 시스템 전체를 테스트하며, emergent property(신규 속성) 테스트가 중요.
• 고객 테스트: 고객 데이터를 사용해 시스템이 고객의 요구를 충족하는지 확인.
 

⚙ V-Model의 테스트 단계

• 요구 사항 명세 -> 시스템 명세 -> 시스템 설계 -> 세부 설계 -> 모듈/유닛 코드 및 테스트.

• 각 단계마다 테스트 계획을 세우고, 통합 테스트 및 승인 테스트를 통해 시스템의 적합성 확인.

3-4. 소프트웨어 진화

4. 변화에 대응하기 (Coping with change)

• 모든 대규모 소프트웨어 프로젝트에서, 변경은 불가피하다.
• 비즈니스 변화: 새로운 요구 사항 발생.
• 새로운 기술: 개선 가능성을 열어줌.
• 플랫폼 변화: 애플리케이션 변경 요구.

🔍 rework(재작업)의 비용을 줄이는 방법

• 변경 예측: 중요한 재작업 전에 가능한 변경 사항을 예상하는 활동 포함.
• 예시: 프로토타입 시스템을 개발해 고객에게 주요 기능을 보여줌.

• 변경 허용: 비교적 저렴한 비용으로 변경이 수용되도록 프로세스 설계. (주요 기능을 계속 개발해 나가면서)
• 점진적 개발 방식 포함.
• 일부 변경 사항만 시스템의 작은 부분에 적용 가능.

🔍 요구사항 변경 대응

• 시스템 프로토타이핑: 고객의 요구를 확인하고 설계 결정을 평가하기 위해 시스템 또는 일부를 빠르게 개발. (동작은 하지 않고 껍데기만, 사용자의 요구사항을 도출하기 위한)
• 이 접근법은 변경 예측을 지원한다.

• 단계적 인수 (Incremental delivery): 시스템 증분을 고객에게 전달하여 피드백과 실험을 지원.
• 변경 방지와 허용 모두 지원한다.

4-1. 시스템 프로토타이핑

• 프로토타입 정의: 시스템의 초기 버전으로 개념을 시연하고 설계 옵션을 시험한다.
→ 요구 사항 도출과 검증, 설계 옵션 탐색, 테스트에 활용할 수 있다.

• 프로토타입의 이점에는 다음과 같은 점이 있다:
• 시스템 사용성 향상
• 사용자의 실제 요구와 더 가까워짐
• 설계 품질 향상
• 유지보수성 향상
• 개발 노력 감소

• 프로트타입 개발 과정

📌 프로토타입 개발

• 빠른 프로토타이핑 도구 사용 가능하다.

• 일부 기능 제외 가능:
• 이해되지 않은 영역에 집중
• 오류 체크 및 복구는 포함되지 않을 수 있음
• 신뢰성, 보안보다는 기능적 요구에 집중

• 일회용 프로토타입은 개발 후 폐기한다:
• 비기능적 요구 충족 불가
• 문서화가 이루어지지 않음
• 빠른 변경으로 구조 악화
• 품질 기준 미달 가능성

4-2. 단계적 인수 (Incremental delivery)

• 사용자 요구 사항은 우선순위가 매겨지고, 우선순위가 높은 요구 사항은 초기 단계에 포함.

• 한 단계의 개발이 시작되면 해당 단계의 요구 사항은 고정되지만, 이후 단계의 요구 사항은 계속 진화 가능.

• 단계적 개발: 시스템을 단계적으로 개발하고, 각 단계를 평가한 후 다음 단계로 진행.
• 애자일 방법론에서 일반적으로 사용되며, 사용자나 고객의 평가에 의해 진행.

• 단계적 전달: 사용자에게 각 단계별로 전달하여 소프트웨어의 실제 사용에 대해 더 현실적인 평가가 가능.
• 기존 시스템을 대체하는 경우, 단계별 전달은 구현이 어려울 수 있음.

📌 단계적 전달의 이점

• 각 단계가 완료될 때마다 기능이 빠르게 제공되어 고객 가치가 전달됨.

• 초기 단계는 후속 단계의 요구 사항을 도출하는 프로토타입 역할.

• 프로젝트 전체 실패의 위험 감소.

• 우선순위가 높은 시스템 기능이 더 많이 테스트됨.

📌 단계적 전달의 문제점

• 대부분의 시스템은 여러 부분에서 사용하는 기본 기능 세트가 필요함.
• 요구 사항이 모든 단계에 필요한 공통 기능을 식별하기 어렵게 만듦.

• 반복적 프로세스의 본질은 소프트웨어와 함께 명세가 개발된다는 것.
• 그러나 많은 조직의 계약 모델과 충돌할 수 있음(완전한 시스템 명세가 개발 계약의 일부인 경우).

5. 프로세스 개선

• 많은 소프트웨어 회사들은 프로세스 개선을 통해 소프트웨어 품질을 향상시키고, 비용 절감 또는 개발 프로세스를 가속화한다. 프로세스 개선이란 기존 프로세스를 이해하고 변경하여 제품 품질을 높이고 비용 및 개발 시간을 줄이는 것이다.

5-1. 개선 접근법

• 프로세스 성숙도 접근법: 프로세스와 프로젝트 관리를 개선하는 데 초점을 맞추며, 좋은 소프트웨어 공학 관행을 도입한다.

• 애자일 접근법: 반복적인 개발과 오버헤드 감소에 중점을 두며, 빠른 기능 제공과 고객 요구에 신속히 대응한다.

• 측정 -> 분석 -> 변경의 주기로, 프로세스를 지속적으로 개선한다.

5-2. 프로세스 개선 활동

• 프로세스 측정: 프로세스나 제품의 특성을 측정하여 개선 여부를 판단한다.

• 프로세스 분석: 현재 프로세스를 평가하고 약점과 병목 현상을 식별한다.

• 프로세스 변경: 식별된 문제를 해결하기 위해 프로세스 변경을 제안하고 다시 데이터 수집을 통해 효과 평가한다.

📌 프로세스 개선 평가를 위한 측정

• 가능한 경우 정량적 데이터 수집한다.

• 프로세스 측정은 개선을 평가하는 데 사용되어야 하지만, 측정 자체가 개선을 주도해서는 안 된다.

• 조직의 목표가 개선의 동력이 되어야 한다.

• 프로세스 매트릭스?
• 소요 시간: 프로세스 활동이 완료되는 데 걸리는 시간.
• 필요 자원: 활동에 필요한 인력 자원.
• 특정 이벤트 발생 횟수: 예를 들어, 발견된 결함 수.

5-3. SEI 성숙도 모델

1. 레벨 1: 초기(통제가 거의 없음)

2. 레벨 2: 반복 가능(제품 관리 절차 정의 및 사용)

3. 레벨 3: 정의(프로세스 관리 절차 및 전략 정의 및 사용)

4. 레벨 4: 관리(품질 관리 전략 정의 및 사용)

5. 레벨 5: 최적화(프로세스 개선 전략 정의 및 사용)