L03L04-Software Process

Topics covered

• 소프트웨어 프로세스 모델
• 프로세스 활동
• 변화 대응
• 프로세스 개선

The software process

• 소프트웨어 시스템을 개발하는 데 필요한 체계적인 활동 집합(structed set of activities)이다.
• 다양한 소프트웨어 프로세스가 존재하지만, 모든 프로세스는 다음을 포함한다(involve).
  • 명세(Specification): 시스템이 수행해야 할 기능 정의
  • 설계 및 구현(Design and implemenation): 시스템의 구조를 정의하고 시스템을 구현
  • 검증(Validation): 고객이 원하는 기능을 수행하는지 확인
  • 진화(Evolution): 변화하는 고객 요구에 맞춰 시스템 변경

• 소프트웨어 프로세스 모델은 프로세스의 추상적 표현(an abstract representation of a process)으로, 특정 관점(perspective)에서 프로세스를 설명하는 역할을 한다.

소프트웨어 프로세스는 소프트웨어 시스템 개발에 필요한 체계적인 활동 집합이다. 모든 프로세스는 명세(기능 정의), 설계 및 구현(구조 정의 및 시스템 구현), 검증(고객 요구 충족 여부 확인), 진화(고객 요구 변화에 따른 시스템 변경)를 포함한다. 소프트웨어 프로세스 모델은 이러한 프로세스를 특정 관점에서 추상적으로 표현하는 역할을 한다.

Software process descriptions

• 프로세스를 설명하고 논의할 때 일반적으로 데이터 모델 명세, 사용자 인터페이스 설계 등의 활동과 그 활동의 순서(the ordering of these activites)를 다룬다.
• 프로세스 설명에는 다음과 같은 요소도 포함될 수 있다.
  • 산출물(Products): 프로세스 활동의 결과물
  • 역할(Roles): 프로세스에 참여하는 사람들의 책임 반영
  • 사전 조건 및 사후 조건(Pre-and post-conditions): 프로세스 활동이 실행되거나 산출물이 생성되기 전후에 참이어야 하는 조건

소프트웨어 프로세스 설명은 데이터 모델 명세, UI 설계 등의 활동과 그 순서를 다룬다. 또한 산출물(활동 결과), 역할(참여자의 책임), 사전·사후 조건(활동 전후의 필수 조건) 등이 포함될 수 있다.

Plan-driven and agile processes (계획 중심의 민첩한 프로세스)

• 계획 기반 프로세스는 모든 프로세스 활동이 사전에 계획되며, 진행 상황이 해당 계획과 비교하여 측정된다.
• 애자일 프로세스에서는 계획이 점진적으로(incremental) 이루어지며, 변화하는 고객 요구사항을 반영하여(reflect) 프로세스를 쉽게 변경할 수 있다.
• 실제로(In practice) 대부분의 실용적인 프로세스는 계획 기반 접근 방식과 애자일 접근 방식을 혼합하여 사용한다.
• 올바른 또는 잘못된 소프트웨어 프로세스라는 것은 존재하지 않는다.

계획 기반 프로세스는 사전 계획에 따라 진행되고, 애자일 프로세스는 점진적으로 계획을 세우며 변경이 용이하다. 대부분의 실용적인 프로세스는 두 가지 접근 방식을 혼합하여 사용하며, 절대적으로 옳거나 그른 소프트웨어 프로세스는 없다.

 

---

 

Software process models (SPM)

• 폭포수 모델(Waterfall model)
  : 계획 기반 모델이며, 명세(specification)와 개발이 별개의 단계(distinct phases of)로 구분됨

• 점진적 개발 (Incremental development)
  : 명세, 개발, 검증(validation)이 상호 작용(interleaved)하며 진행되며, 계획 기반 또는 애자일 방식으로 수행될 수 있음

• 통합 및 구성 (Intergration and configuration)
  : 기존의 재사용 가능한 구성 요소를 조합하여(assemble) 시스템을 개발하며, 계획 기반 또는 애자일 방식으로 수행될 수 있음
• 실제로 대부분의 대형 시스템은 위의 모든 모델의 요소를 결합하여 개발된다.
• Q. 안전에 중요한 시스템인가요?
• A. 안전에 중요한 시스템이라면 폭포수 모델이 적합할 가능성이 크다. 사전에 명확한 명세와 단계별 검증이 필요하기 때문이다. 그러나 경우에 따라 점진적 개발이나 통합 및 구성 방식을 일부 적용할 수도 있다.

1. 폭포수 모델: 명세와 개발이 구분된 계획 기반 모델.

2. 점진적 개발: 명세, 개발, 검증이 상호 작용하며 진행되는 모델.

3. 통합 및 구성: 재사용 가능한 구성 요소를 조합하여 시스템 개발.

대형 시스템은 이 모델들의 요소를 결합하여 개발하며, 안전한 시스템은 폭포수 모델이 적합할 수 있지만, 다른 방법도 일부 적용 가능하다.

 

SPM: 폭포수 모델

• Requirments definition (요구사항 정의): 사용자 요구사항을 수집하고 문서화하여 명확한 명세를 작성하는 단계
• System and software design (시스템 및 소프트웨어 설계): 요구사항을 바탕으로 시스템 아키텍처와 세부 설계를 진행하는 단계
• Implementation and unit testing (구현 및 단위 테스트): 설계된 내용을 기반으로 코드를 작성하고, 개별 모듈 단위로 테스트하는 단계
• Integration and system testing (통합 및 시스템 테스트): 개발된 모듈을 통합하고 전체 시스템을 테스트하여 오류를 검출하는 단계
• Operation and maintenance (운영 및 유지보수): 실제 운영 환경에서 시스템을 사용하며, 필요에 따라 수정 및 개선을 수행하는 단계

Waterfall model phases

• 폭포수 모델에서는 별도로 식별된 단계가 있다.
  • 요구사항 분석 및 정의
  • 시스템 및 소프트웨어 설계
  • 구현 및 단위 테스트
  • 통합 및 시스템 테스트
  • 운영 및 유지보수 
  • → 각 단계에서 문서가 생성되며, 승인 후 다음 단계로 진행된다.
• 폭포수 모델의 주요 단점(drawback)은 프로세스가 진행된 후에는 변경을 수용(accommodating change)하기 어렵다는 점이다. 원칙적으로 한 단계가 완료되어야만 다음 단계(phase)로 넘어갈 수 있다.

각 단계에서는 문서가 생성되며, 승인 후 다음 단계로 진행된다. 폭포수 모델의 주요 단점은 프로세스 진행 후 변경을 수용하기 어렵고, 한 단계가 완료되어야만 다음 단계로 넘어갈 수 있다는 점이다.

Waterfall model problems

• 프로젝트를 명확한(distinct) 단계로 나누는 경직된(Inflexible) 구조로 인해 변화하는 고객 요구사항에 대응하기 어렵다.
  • 따라서, 이 모델은 요구사항이 명확하게 정의되어 있으며, 설계 과정에서 변경이 거의 없을 경우에만 적합하다.
  • 그러나 대부분의 비즈니스 시스템은 요구사항이 안정적이지 않다.
• 폭포수 모델은 주로 여러 장소에서 개발되는 대규모 시스템 엔지니어링 프로젝트에서 사용된다.
  • 이러한 상황에서는 계획 기반 접근 방식이 작업을 조율하는 데 도움이 된다.

프로젝트를 명확한 단계로 나누는 경직된 구조로 인해 변화하는 고객 요구사항에 대응하기 어렵다. 이 모델은 요구사항이 명확하고 설계 과정에서 변경이 거의 없을 때만 적합하다. 그러나 대부분의 비즈니스 시스템은 요구사항이 안정적이지 않다. 폭포수 모델은 주로 대규모 시스템 엔지니어링 프로젝트에 사용되며, 계획 기반 접근 방식이 작업 조율에 도움이 된다.

Types of systems where the waterfall model is applicable (워터폴 모델을 적용할 수 있는 시스템 유형)

• 임베디드 시스템
  • 하드웨어가 유연하지 않다.
  • -> 요구사항이 명확하게 정의되어 있어야 하고, 각 단계가 순차적으로 진행되는 워터폴 모델이 적합
• 크리티컬 시스템
  • 명세와 설계가 반드시 완벽해야 한다!
  • 그렇지 않으면 안전성과 보안 분석을 충분히(entenstive) 수행할 수 없다.
  • -> 이러한 시스템에서는 워터폴 모델의 철저한 문서화와 단계적 접근이 중요하다.
• 대형 소프트웨어 시스템
  • 여러 기업 간의 복잡한 커뮤니케이션을 피할 필요가 있다.
  • -> 워터폴 모델을 적용하면 각 단계가 명확하게 구분되어 있어 관리가 용이하고, 다양한 이해관계자 간의 협업을 체계적으로 진행할 수 있다.

SPM: 점진적 개발

• Outline description (개요 설명): 점진적 개발은 소프트웨어를 작은 부분으로 나누어 반복적으로 개발하고 개선하는 접근 방식이다.
• Specification (명세): 각 반복 주기마다 필요한 기능과 요구사항을 정의하여 명확한 목표를 설정한다.
• Development (개발): 정의된 명세에 따라 소프트웨어의 특정 부분을 구현하며, 매 반복마다 기능을 추가하거나 개선한다.
• Validation (검증): 각 반복 주기 후에 개발된 기능이 요구사항을 충족하는지 확인하고, 피드백을 반영하여 수정한다.
• Initial version (초기 버전): 첫 번째 반복에서 개발된 기본 기능을 포함한 초기 소프트웨어 버전이다.
• Intermediate versions (중간 버전): 각 반복에서 개발된 개선된 소프트웨어 버전으로, 기능이 점진적으로 추가된다.
• Final version (최종 버전): 모든 기능이 구현되고 검증된 후 출시되는 최종 소프트웨어 버전이다.

Incremental development benefits (점진적 개발 장점)

• 변화하는 고객 요구사항을 수용하는(accommdating) 비용이 감소한다.
  • 폭포수 모델에 비해 재분석 및 문서화 작업이 훨씬 적다.
• 개발 진행 중인 작업에 대해 고객 피드백을 받기 쉬워진다.
  • 고객이 소프트웨어 시연(demonstrations)을 통해 구현된 기능을 직접 확인하고 피드백할 수 있다.
• 유용한 소프트웨어를 고객에게 더 빠르게(rapid) 제공하고 배포할 수 있다.
  • 고객은 폭포수 모델보다 빠르게 소프트웨어를 사용하고 가치를 얻을 수 있다.

Incremental development benefits는 다음과 같다. 변화하는 고객 요구사항을 수용하는 비용이 감소하며, 폭포수 모델에 비해 재분석 및 문서화 작업이 적다. 개발 진행 중 고객 피드백을 받기 쉬워지고, 고객은 소프트웨어 시연을 통해 구현된 기능을 직접 확인하고 피드백할 수 있다. 유용한 소프트웨어를 고객에게 더 빠르게 제공하고 배포할 수 있으며, 고객은 폭포수 모델보다 빠르게 소프트웨어를 사용하고 가치를 얻을 수 있다.

Incremental development problems

• 프로세스가 명확하게 보이지 않는다.
  • 관리자는 진행 상황을 측정할 수 있도록 정기적인 산출물을 필요로 하지만, 빠르게 개발될 경우 모든 버전에 대한 문서를 만드는 것(reflect) 이 비용적으로 비효율적이다.
• 새로운 기능이 추가될수록 시스템 구조가 저하되는 경향이 있다 (tends to degrade)
  • 소프트웨어를 개선하기 위해 지속적인 리팩토링에 시간과 비용을 투자하지 않으면, 빈번한 변경(Incorporating further)이 구조를 손상시켜 유지보수가 점점 더 어렵고 비용이 많이 든다

1. 프로세스 불명확: 진행 상황을 측정하기 어려움.

2. 문서화 부담: 빠른 개발로 모든 버전의 문서 작성이 비효율적임.

3. 구조 저하: 새로운 기능 추가로 시스템 구조가 약화됨.

4. 유지보수 어려움: 리팩토링이 없으면 변경이 점점 더 어렵고 비용 증가.

SPM: 통합 및 구성(Integration and configuration)

• 기존 구성 요소나 애플리케이션 시스템을 통합하여 시스템을 개발하는 소프트웨어 재사용 기반 모델이며, 때때로 COTS(Commercial-off-the-shelf) 시스템이라고도 불린다.
• 재사용되는 요소는 사용자의 요구사항에 맞게 동작 및 기능을 조정할 수 있다.
• 재사용은 이제 대부분의 비즈니스 시스템을 구축하는 표준 접근 방식이다.
  • 재사용에 대한 자세한 내용은 15장에서 다룬다.

SPM: 통합 및 구성은 기존 구성 요소나 애플리케이션 시스템을 통합하여 시스템을 개발하는 소프트웨어 재사용 기반 모델로, COTS(상용 기성품) 시스템이라고도 불린다. 재사용되는 요소는 사용자 요구에 맞게 조정할 수 있으며, 이는 비즈니스 시스템 구축의 표준 접근 방식이다. 재사용에 대한 자세한 내용은 15장에서 다룬다.

재사용 가능한 소프트웨어의 유형

• 특정 환경에서 사용하도록 구성된(configured) 독립(Stand-alone) 실행형 애플리케이션 시스템(COTS라고도 함).
• .NET 또는 J2EE와 같은 구성 요소 프레임워크와 통합(be integrated)할 수 있도록 패키지로 개발된 객체 모음.
• 서비스 표준에 따라 개발되어 원격 호출이 가능한 웹 서비스. (Ex. LMS)

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

• Requirements specification (요구사항 명세): 시스템이 충족해야 할 기능과 성능에 대한 명확한 정의를 수립하는 단계로, 고객의 요구를 반영한다.
• Software discovery (소프트웨어 탐색): 필요한 기능을 충족할 수 있는 기존 소프트웨어 구성 요소나 시스템을 찾아내는 단계이다.
• Software evaluation (소프트웨어 평가): 탐색된 소프트웨어 구성 요소가 요구사항을 충족하는지 평가하고, 품질 및 적합성을 판단하는 단계이다.
• Requirements refinement (요구사항 세분화): 기존 요구사항을 더 구체적이고 명확하게 다듬어, 실제 적용 가능한 형태로 만드는 단계이다.
• Configure application system (응용 시스템 구성): 평가된 소프트웨어 구성 요소를 기반으로 응용 시스템을 설정하고 조정하는 단계이다.
• Adapt components (구성 요소 조정): 재사용할 소프트웨어 구성 요소를 필요에 맞게 조정하거나 수정하여 특정 요구사항에 맞게 만드는 단계이다.
• Develop new components (새로운 구성 요소 개발): 기존 구성 요소로 충족되지 않는 기능을 구현하기 위해 새로운 소프트웨어 구성 요소를 개발하는 단계이다.
• Integrate system (시스템 통합): 모든 구성 요소를 통합하여 하나의 완전한 시스템으로 작동하도록 만드는 단계이다.

Advantages and disadvantages

• 처음부터 소프트웨어를 개발하는 경우보다 비용과 위험이 감소.
• 시스템의 더 빠른 제공 및 배포 가능.
• 하지만 요구사항 타협(compromises)이 불가피(inevitable)하므로 시스템이 실제 사용자 요구를 충족하지 못할 수도 있음.
• 재사용된 시스템 요소의 진화에 대한 통제권이 상실될 위험이 있음.

장점: 비용·위험 감소, 빠른 제공 및 배포 가능.

단점: 요구사항 타협 필요, 사용자 요구 미충족 가능, 재사용 요소 진화 통제 어려움.

 

---

 

Process activities

• 실제 소프트웨어 프로세스는 소프트웨어 시스템을 명세, 설계, 구현 및 테스트하는 것을 목표로 하는 기술적, 협업적, 관리적 활동의 연속적인 흐름으로 구성됨(be interleaved).
• 명세, 개발, 검증 및 진화의 네 가지 기본 프로세스 활동은 개발 프로세스마다 다르게 구성됨.
  • 프로세스는 도구 지원을 받음!
• 예를 들어, 폭포수 모델에서는 순차적으로 구성되지만, 점진적 개발에서는 서로 얽혀 있음.

Process activities는 소프트웨어 시스템을 개발하는 기술적, 협업적, 관리적 활동의 흐름으로, 명세, 개발, 검증, 진화의 네 가지 기본 활동으로 구성된다. 개발 방식에 따라 순차적(폭포수 모델) 또는 얽혀 진행(점진적 개발)될 수 있으며, 도구 지원을 받는다.

Software specification

• 시스템이 제공해야 하는 서비스와 운영 및 개발에 대한 제약을 정의하는 과정.
• 요구사항 엔지니어링 프로세스
  • 요구사항 도출(elicitation) 및 분석
    • 시스템 이해관계자가 시스템에서 필요로 하거나 기대하는 것은 무엇인가?
  • 요구사항 명세
    • 요구사항을 상세히 정의
  • 요구사항 검증
    • 요구사항의 타당성 검토

Software specification은 시스템의 서비스와 제약을 정의하는 과정으로, 요구사항 도출, 명세, 검증의 단계를 거친다.

The requirements engineering process

• Requirements elicitation and analysis: 이해관계자로부터 요구사항을 도출하고 분석
• Requirem  ents specification: 도출된 요구사항을 명확하고 상세하게 문서화
• Requirements validation: 요구사항의 타당성을 검토하고 오류를 수정
• System Descriptions: 시스템의 전반적인 개요와 주요 기능을 설명
• User and system requirements: 사용자 요구사항(사용자가 원하는 기능)과 시스템 요구사항(구현을 위한 기술적 요구)으로 구분
• Requirements document: 요구사항을 정리한 공식 문서

Discussion: 밀레니엄 버그

• https://en.wikipedia.org/wiki/Year_2000_problem
• 한동대학교 학생 ID 형식

Software design and implementation

• 시스템 명세(systepm specification)를 실행 가능한(executable) 시스템으로 변환하는(converting) 과정.
• 소프트웨어 설계 : 명세를 실현할 소프트웨어 구조를 설계.
• 구현 : 이 구조를 실행 가능한 프로그램으로 변환.
• 설계와 구현 활동은 밀접하게 연관되며 상호 교차될 수 있음.

1. 정의 : 시스템 명세를 실행 가능한 시스템으로 변환.

2. 설계: 명세를 실현할 소프트웨어 구조 설계.

3. 구현: 구조를 실행 가능한 프로그램으로 변환.

4. 특징: 설계와 구현은 밀접하게 연관되고 상호 교차됨.

A general model of the design process

• Design inputs (설계 입력)
  1. Platform information: 하드웨어 및 소프트웨어 환경 정보
  2. Software requirements: 시스템이 충족해야 할 요구사항
  3. Data descriptions: 시스템에서 처리할 데이터의 구조 및 특성
• Design activities (설계 활동)
  1. Architectural design: 시스템의 전체적인 구조 설계
  2. Database design: 데이터 저장 및 관리 방식 설계
  3. Interface design: 사용자 및 시스템 인터페이스 설계
  4. Component selection and design: 시스템 구성 요소 선택 및 설계
• Design outputs (설계 출력)
  1. System architecture: 시스템의 전체적인 구조 및 구성
  2. Database design: 데이터베이스의 구조 및 스키마
  3. Interface specification: 사용자 및 시스템 인터페이스 정의
  4. Component description: 개별 구성 요소의 설계 및 동작 설명

Design activities (just read)

• 아키텍처 설계: 시스템의 전체 구조, 주요 구성 요소(하위 시스템 또는 모듈), 그 관계 및 분배 방식 식별.
• 데이터베이스 설계: 시스템의 데이터 구조를 설계하고 이를 데이터베이스에서 어떻게 표현할 것인지 결정.
• 인터페이스 설계: 시스템 구성 요소 간의 인터페이스를 정의.
• 구성 요소 선택 및 설계: 재사용 가능한 구성 요소를 검색. 사용 가능한 것이 없으면 직접 설계.

1. 아키텍처 설계: 시스템 구조 및 구성 요소 식별.

2. 데이터베이스 설계: 데이터 구조 및 표현 방식 결정.

3. 인터페이스 설계: 구성 요소 간 인터페이스 정의.

4. 구성 요소 설계: 재사용 가능한 요소 검색 또는 직접 설계.

System implementation

• 프로그램을 개발하거나 애플리케이션 시스템을 구성하여 소프트웨어를 구현.
• 대부분의 소프트웨어 시스템에서 설계와 구현은 상호 교차되는 활동.
• 프로그래밍은 표준화된 프로세스 없이 개별적으로 수행.
• 디버깅은 프로그램의 오류를 찾아 수정하는 활동.

소프트웨어 개발: 프로그램 개발 또는 시스템 구성.

설계·구현 연계: 두 활동이 상호 교차됨.

프로그래밍: 표준화 없이 개별 수행.

디버깅: 오류 탐색 및 수정.

Software validation

• 검증 및 확인(Verication and validation) (V & V)은 시스템이 명세를 준수하고 고객 요구사항을 충족하는지 확인하는 것.
  • 검증(Verification): 우리가 "올바른 제품"을 만들고 있는가? (설계(design)가 명세를 따르는가?)
  • 확인(Validation): 우리가 "필요한 제품"을 만들고 있는가? (요구사항에 맞게 동작(intended하는가?)
• 검토 및 점검 과정과 시스템 테스트를 포함.
• 시스템 테스트는 시스템이 처리해야 할 실제 데이터를 기반으로 한 테스트 케이스를 실행하는 과정.
• 테스트는 가장 일반적으로 사용되는 V & V 활동.

V&V 목적: 명세 준수 및 고객 요구 충족 확인.

검증(Verification): 설계가 명세를 따르는가?

확인(Validation): 요구사항에 맞게 동작하는가?

방법: 검토·점검·테스트 포함, 실제 데이터 기반 테스트 수행.

Stages of testing

• Component testing (구성 요소 테스트)
  : 개별 모듈이나 구성 요소가 정상적으로 동작하는지 확인
• System testing (시스템 테스트)
  : 통합된 시스템이 요구사항을 충족하는지 검증
• Customer testing (고객 테스트)
  : 실제 사용자가 테스트하여 소프트웨어가 기대한 대로 동작하는지 확인

Testing stages

• 구성 요소 테스트:
  • 개별 구성 요소를 독립적으로 테스트.
  • 구성 요소는 함수, 객체 또는 이러한 요소들의 그룹이 될 수 있음.
• 시스템 테스트:
  • 전체 시스템을 테스트.
  • emergent properties(종합적 속성) 테스트가 특히 중요.
• 고객 테스트:
  • 고객 데이터를 사용하여 시스템이 고객의 요구를 충족하는지 확인.

구성 요소 테스트: 개별 모듈이 정상 동작하는지 확인.

시스템 테스트: 통합된 시스템이 요구사항을 충족하는지 검증.

고객 테스트: 실제 사용자가 테스트하여 소프트웨어가 기대대로 동작하는지 확인.

계획 기반 소프트웨어 프로세스(V-모델)에서의 테스트 단계

1) V-모델의 주요 단계

(1) Requirements Specification (요구사항 명세)

• 시스템이 수행해야 할 기능과 비기능 요구사항을 정의하는 단계.
• 대응하는 테스트 계획: Customer Test Plan (고객 테스트 계획).

(2) System Specification (시스템 명세)

• 요구사항을 구체화하여 시스템 수준에서 설계하는 단계.
• 대응하는 테스트 계획: System Integration Test Plan (시스템 통합 테스트 계획).

(3) System Design (시스템 설계)

• 시스템을 세부적으로 설계하여 각 서브시스템과 모듈을 정의하는 단계.
• 대응하는 테스트 계획: Sub-system Integration Test Plan (서브시스템 통합 테스트 계획).

(4) Component Design (컴포넌트 설계)

• 개별적인 소프트웨어 모듈을 설계하는 단계.
• 대응하는 테스트 계획: Component Code and Test (컴포넌트 코드 작성 및 테스트).

(5) Component Code and Test (컴포넌트 코드 및 테스트)

• 코딩 작업을 수행하고 각 모듈의 단위 테스트(Unit Test)를 진행하는 단계.
• 이후 서브시스템 및 시스템과 통합하여 테스트 진행.

2) V-모델의 테스트 단계

(1) Sub-system Integration Test (서브시스템 통합 테스트)

• 서브시스템 간의 결합을 검증하는 테스트.
• 설계 단계에서 정의된 서브시스템 통합 테스트 계획을 기반으로 수행.

(2 System Integration Test (시스템 통합 테스트)

• 전체 시스템이 올바르게 동작하는지 검증하는 테스트.
• 시스템 명세 단계에서 정의된 테스트 계획을 기반으로 수행.

(3) Customer Test (고객 테스트)

• 실제 사용자 또는 QA팀이 최종 테스트를 수행하는 단계.
• 요구사항 명세 단계에서 정의된 고객 테스트 계획을 기반으로 진행하며, 베타 테스트를 포함할 수 있음.

(4) Service (서비스 운영)

• 테스트가 완료된 소프트웨어가 실제 운영 환경에서 서비스되는 단계.

이 모델은 각 개발 단계에 대응하는 테스트 계획이 수반되므로, 결함을 조기에 발견하고 품질을 보장하는 데 효과적이다.

Software evolution

• 소프트웨어는 본질적으로 유연하며 변경될 수 있음.
• 비즈니스 환경이 변화함에 따라 이를 지원하는 소프트웨어도 진화하고 변화해야 함.
• 기존에는 개발과 진화(유지보수)를 구분했지만, 완전히 새로운 시스템이 점점 줄어들면서 이 구분은 점점 의미를 잃고 있음.

System evolution

• Define system requirements (시스템 요구사항 정의)
  • 변경이 필요한 기능이나 성능 요구사항을 정의
• Assess existing systems (기존 시스템 평가)
  • 현재 시스템이 요구사항을 얼마나 충족하는지 분석
• Propose system changes (시스템 변경 제안)
  • 시스템 개선을 위한 변경 사항을 결정
• Modify systems (시스템 수정)
  • 변경 사항을 반영하여 시스템을 업데이트
• Existing systems (기존 시스템)
  • 현재 운영 중인 시스템
• New system (새로운 시스템)
  • 기존 시스템을 대체하거나 보완하는 새로운 시스템

변화 대응 (Coping with change)

• 대규모 소프트웨어 프로젝트에서는 변화(Change)가 필연적임(Inevitable).
  • 비즈니스 변화로 인해 새로운 시스템 요구사항이 생기거나 변경됨.
  • 새로운 기술이 등장하면 구현을 개선할 가능성이 열림.
  • 플랫폼이 변경되면 애플리케이션도 수정해야 함.
• 변화로 인해 재작업(rework)이 필요하므로, 변경 비용에는 기존 요구사항을 다시 분석하는 작업과 새로운 기능을 구현하는 비용이 포함됨.

대규모 소프트웨어 프로젝트에서는 변화가 필연적이며, 비즈니스 변화, 새로운 기술, 플랫폼 변경으로 인해 요구사항이 수정되고 재작업이 필요하다.

재작업 비용 절감 방법

• 변화 예측(Change anticipation): 소프트웨어 프로세스에서 재작업이 크게 발생하기 전에 변화 가능성을 예측하는(anticipate) 활동을 포함.
  • 변화 회피(Change avoidance): 미래의 변경을 어떻게 피할 것인가?
  • 예를 들어, 주요 기능을 고객에게 보여주기 위해 프로토타입 시스템을 개발할 수 있음.
• 변화 수용(Change tolerance): 프로세스가 변화에 대한 비용을 최소화할 수 있도록 설계됨.
  • 일반적으로 점진적 개발(incremental development)을 포함하며, 제안된 변경 사항을 아직 개발되지 않은 증분 단계에서 구현 가능.
  • 만약 불가능하다면, 하나의 작은 증분(시스템의 일부)만 수정하여 변경을 반영할 수 있음.

변화 예측: 재작업 발생 전에 변화 가능성을 예측하는 활동.

변화 수용: 변화에 대한 비용을 최소화하도록 프로세스를 설계하며, 점진적 개발을 통해 변경 사항을 구현하는 활동

변경되는 요구사항에 대응하기

• 시스템 프로토타이핑: 시스템 또는 시스템 일부의 버전을 빠르게 개발하여 고객의 요구사항을 확인하고 설계 결정의 타당성을 검토. 이 접근 방식은 변화 예측을 지원.
• 점진적 제공(Incremental delivery): 시스템의 일부를 고객에게 제공하여 피드백을 받고 실험(experimentation)할 수 있도록 함. 이 방식은 변화 회피(avoidance)와 변화 수용(change tolerance)을 모두 지원.

변경되는 요구사항에 대응하기 위해 시스템 프로토타이핑을 통해 요구사항을 확인하고, 점진적 제공으로 피드백을 받아 변화 회피와 수용을 지원한다.

소프트웨어 프로토타이핑

• 프로토타입은 개념을 시연하고 설계 옵션을 시험하기 위해 사용되는 시스템의 초기 버전.
• 프로토타입은 다음과 같은 과정에서 사용 가능:
  • 요구사항 엔지니어링 과정에서 요구사항 도출 및 검증을 지원.
  • 설계 과정에서 다양한 옵션을 탐색하고 UI 디자인을 개발.
  • 테스트 과정에서 백투백(back-to-back) 테스트를 수행.

소프트웨어 프로토타이핑: 프로토타입은 개념을 시연하고 설계 옵션을 시험하기 위해 사용되는 초기 버전으로, 요구사항 도출 및 검증, 다양한 설계 옵션 탐색, UI 디자인 개발, 백투백 테스트 과정에서 활용된다.

프로토타이핑의 장점

• 시스템 사용성 향상.
• 사용자 실제 요구사항과의 일치도 증가.
• 설계 품질 향상.
• 유지보수성 향상.
• 개발 노력 감소.

프로토타입 개발 프로세스

- 각 단계는 순차적으로 연결되어 있으며, 각 단계마다 구체적인 결과물이 산출된다. 이 프로세스는 소프트웨어나 제품 개발에서 초기 모델을 만들고 검증하는 체계적인 방법을 나타낸다.

1. 프로토타입 목표 수립(Establish prototype objectives)
   • 결과물: 프로토타이핑 계획(Prototyping plan)
2. 프로토타입 기능 정의(Define prototype functionality)
   • 결과물: 개요 정의(Outline definition)
3. 프로토타입 개발(Develop prototype)
   • 결과물: 실행 가능한 프로토타입(Executable prototype)
4. 프로토타입 평가(Evaluate prototype)
   • 결과물: 평가 보고서(Evaluation report)

Prototype development

• 빠른(Rapid) 프로토타이핑 언어 또는 도구를 기반으로 할 수 있음.
• 일부 기능이 제외될 수 있음.
  • 프로토타입은 제품에서 잘 이해되지 않은 영역에 집중해야 함.
  • 오류 검사 및 복구 기능이 포함되지 않을 수도 있음.
  • 신뢰성, 보안성과 같은 비기능적 요구사항보다 기능적 요구사항에 집중해야 함.

프로토타입 개발: 빠른 프로토타이핑 언어 또는 도구를 기반으로 하며, 일부 기능이 제외될 수 있고, 잘 이해되지 않은 영역에 집중해야 한다. 오류 검사 및 복구 기능은 포함되지 않을 수 있으며, 기능적 요구사항에 집중하고 비기능적 요구사항은 덜 고려한다.

일회성 프로토타입(Throw-away prototypes)

• 프로토타입은 개발 후 폐기해야 하며, 실제 운영 시스템의 기반으로 적절하지 않음.
  • 비기능적 요구사항을 충족하도록 시스템을 조정하는(tune) 것이 불가능할 수 있음.
  • 일반적으로 프로토타입에는 문서화가 되어 있지 않음(undocumented).
  • 빠른 변경으로 인해 구조가 손상될(degared) 가능성이 큼.
  • 일반적인 조직 품질 기준(organisational quality standards)을 충족하지 않을 가능성이 높음.

일회성 프로토타입: 개발 후 폐기되며 실제 운영 시스템의 기반으로 적절하지 않고, 비기능적 요구사항을 충족하기 어려울 수 있다. 일반적으로 문서화되지 않고 빠른 변경으로 구조가 손상될 가능성이 크며, 조직 품질 기준을 충족하지 않을 가능성이 높다.

점진적 제공(Incremental delivery)

• 전체 시스템을 한 번에 제공하는 것이 아니라, 개발 및 제공을 여러 단계(증분)로 나누어 각 단계에서 일부 기능을 제공함.
• 사용자 요구사항을 우선순위에 따라 정리하여 우선순위가 높은 기능부터 제공.
• 한 증분의 개발이 시작되면 해당 단계의 요구사항은 고정되지만, 이후 증분의 요구사항은 계속 진화할 수 있음.
• -> 앱, 웹, 플러그인 기반 애플리케이션

점진적 제공: 전체 시스템을 한 번에 제공하는 대신 여러 단계로 나누어 각 단계에서 일부 기능을 제공하며, 사용자 요구사항을 우선순위에 따라 정리하여 우선순위가 높은 기능부터 제공한다. 한 증분의 요구사항은 고정되지만, 이후 증분의 요구사항은 계속 진화할 수 있다.

점진적 개발 및 제공(Incremental development and delivery)

• 점진적 개발(Incremental development)
  • 시스템을 여러 단계로 개발하고 각 단계에서 평가 후 다음 단계 개발을 진행.
  • 애자일(Agile) 방식에서 일반적으로 사용됨.
  • 사용자가 직접 평가하거나 고객 대리인이 평가.
• 점진적 제공(Incremental delivery)
  • 개발된 증분을 최종 사용자에게 제공하여 실제 사용 가능하도록 배포.
  • 소프트웨어의 실제 사용에 대한 보다 현실적인 평가 가능.
  • 기존 시스템을 대체하는 경우, 제공되는 증분이 기존 시스템보다 기능이 적어 구현이 어려울 수 있음.

점진적 개발 및 제공: 점진적 개발은 시스템을 여러 단계로 개발하고 각 단계 평가 후 다음 단계를 진행하며, 애자일 방식에서 일반적으로 사용된다. 점진적 제공은 개발된 증분을 최종 사용자에게 제공하여 실제 사용 가능하도록 배포하며, 실제 사용에 대한 현실적인 평가가 가능하지만 기존 시스템을 대체할 경우 기능이 적어 구현이 어려울 수 있다.

점진적 제공

1. 개요 정의(Define outline)
2. 증분에 요구사항 할당(Assign requirements to increments)
3. 시스템 아키텍처 설계(Design system architecture)
4. 시스템 증분 개발(Develop system increment)
5. 증분 배포(Deploy increment)
6. 시스템 검증(Validate system)
7. 증분 통합(Integrate increment)
8. 증분 검증(Validate increment)

이 프로세스에는 두 개의 의사결정 포인트가 있다.

• 개발 후 "시스템이 불완전한가?(System incomplete?)" 질문에서 예라면 다시 증분 개발로 돌아간다.
• 검증 후 "시스템이 완성되었는가?(System complete?)" 질문에서 아니오라면 다시 증분에 요구사항 할당으로 돌아가고, 예라면 "최종 시스템(Final system)"으로 진행된다.

점진적 제공의 장점

• 각 증분마다 고객 가치를 제공하여 시스템 기능을 더 빠르게 활용 가능.
• 초기 증분이 프로토타입 역할을 하여 이후 증분을 위한 요구사항 도출(elicit)에 도움.
• 전체 프로젝트 실패 위험 감소.
• 우선순위가 높은 시스템 서비스가 더 많은 테스트를 받음.

점진적 제공의 장점: 각 증분마다 고객 가치를 제공하여 시스템 기능을 빠르게 활용할 수 있으며, 초기 증분이 프로토타입 역할을 하여 이후 증분 요구사항 도출에 도움을 준다. 전체 프로젝트 실패 위험이 감소하고, 우선순위가 높은 시스템 서비스는 더 많은 테스트를 받는다.

점진적 제공의 문제점

• 기존 시스템을 대체할 경우 문제가 발생할 수 있음(Problematic). >> 사용자들은 기존 시스템을 선호하며 새로운 시스템 사용을 꺼릴 수 있음.
• 대부분의 시스템은 여러 부분에서 공통적으로 사용하는 기본 기능을 필요로 함.
  • 각 증분이 개발될 때까지 상세 요구사항이 정의되지 않기 때문에, 모든 증분이 필요로 하는 공통 기능(common facilities)을 식별하는 것이 어려움.
  • 불확실성(Uncertainty)!
• 반복적 프로세스의 핵심(essence)은 소프트웨어 개발과 함께(in conjunction) 명세를 발전시키는 것.
  • 결과물(deliverables) → 추가/수정된(adjusted) 명세 → 결과물
  • 하지만 대부분의 조직은 명확한 사양과 결과물을 원함!

점진적 제공의 문제점: 기존 시스템을 대체할 때 사용자들이 새로운 시스템 사용을 꺼릴 수 있으며, 기본 기능이 필요하지만 각 증분 개발 시 상세 요구사항이 정의되지 않아 공통 기능 식별이 어렵다. 또한, 반복적 프로세스의 핵심은 소프트웨어 개발과 함께 명세를 발전시키는 것이나 대부분의 조직은 명확한 사양과 결과물을 원한다.

 

 

---

 

프로세스 개선(Process improvement)

• 많은 소프트웨어 기업이 소프트웨어 품질 향상, 비용 절감, 개발 속도 향상(accelerating)을 위해 소프트웨어 프로세스 개선을 도입함.
• 프로세스 개선은 기존 프로세스를 분석하고, 이를 변경하여 제품 품질을 향상시키거나 비용 및 개발 시간을 줄이는 것.

프로세스 개선: 많은 소프트웨어 기업이 소프트웨어 품질 향상, 비용 절감, 개발 속도 향상을 위해 프로세스 개선을 도입하며, 이는 기존 프로세스를 분석하고 변경하여 제품 품질을 향상시키거나 비용 및 개발 시간을 줄이는 것이다.

두 가지 개선 접근 방식

• 프로세스 성숙도 접근법(Process maturity approach): 프로세스 및 프로젝트 관리를 개선하고 소프트웨어 엔지니어링 모범 사례를 도입하는 데 초점.
  • 프로세스 성숙도(maturity) 수준은 조직 내 소프트웨어 개발 프로세스에서 기술적, 관리적 모범 사례가 얼마나 채택(adopted)되었는지를 반영.
• 애자일 접근법(Agile approach): 반복적 개발과 프로세스 오버헤드 감소에 중점.
  • 애자일 방식의 핵심은 기능의 빠른 제공과 변화하는 고객 요구사항에 대한 유연한 대응.

1. 프로세스 성숙도 접근법: 프로세스 및 프로젝트 관리를 개선하고 소프트웨어 엔지니어링 모범 사례 도입에 초점을 맞추며, 성숙도 수준은 기술적, 관리적 모범 사례의 채택 정도를 반영한다.

2. 애자일 접근법: 반복적 개발과 프로세스 오버헤드 감소에 중점을 둔다.

프로세스 개선 주기(Process improvement cycle)

- Measure :  현재 프로세스의 성과를 측정하여 데이터를 수집하고, 개선이 필요한 영역을 식별한다.

- Analyze : 수집된 데이터를 분석하여 문제의 원인을 파악하고, 어떤 개선이 필요한지를 결정한다.

- Change : 개선 사항을 구현하여 프로세스를 수정하고, 그 결과를 평가하여 효과를 확인한다. 

프로세스 개선 활동(Process improvement activities)

• 프로세스 측정(Process measurement)
  • 소프트웨어 프로세스 또는 제품의 하나 이상의 속성을 측정.
  • 측정(measurement)된 데이터는 프로세스 개선이 효과적인지 판단하는 기준이 됨.
• 프로세스 분석(Process analysis)
  • 현재 프로세스를 평가하고 약점 및 병목 현상을 식별.
  • 프로세스를 설명하는 모델(프로세스 맵)을 개발할 수도 있음.
• 프로세스 변경(Process change)
  • 식별된 문제를 해결하기 위해 프로세스 변경을 제안.
  • 변경 사항을 적용한 후, 효과를 측정하여 주기를 반복하며 개선 진행.

프로세스 측정: 소프트웨어 프로세스 또는 제품의 속성을 측정하여 개선 효과를 판단하는 기준이 된다.

프로세스 분석: 현재 프로세스를 평가하고 약점 및 병목 현상을 식별하며, 프로세스를 설명하는 모델을 개발할 수 있다.

프로세스 변경: 식별된 문제를 해결하기 위해 프로세스 변경을 제안하고, 변경 후 효과를 측정하여 개선 주기를 반복한다.