소프트웨어 프로세스
- 소프트웨어 시스템 개발에 필요한 구조화된 활동 세트
- 소프트웨어 개발에 포함되는 다양한 프로세스들이 있지만, 이들 모든 프로세스는 다음과 같은 공통적인 활동들을 포함합니다
- 명세화(Specification): 시스템이 수행해야 할 작업을 정의합니다.
- 설계 및 구현(Design and Implementation): 시스템의 구조를 정의하고 시스템을 구현합니다.
- 검증(Validation): 시스템이 고객의 요구사항을 충족하는지 확인합니다.
- 진화(Evolution): 고객의 요구사항 변화에 따라 시스템을 수정합니다.
- 소프트웨어 프로세스 모델은 프로세스를 특정 관점에서 설명하는 추상적 표현입니다. 이 모델은 소프트웨어 개발 동안의 다양한 활동들, 그 활동들의 순서, 결과물, 역할, 그리고 활동이 시작되기 전과 완료된 후의 전후 조건들을 포함할 수 있습니다.
소프트웨어 프로세스 모델들
종류
실제로 많은 대규모 시스템은 이 모든 모델의 요소를 혼합하여 사용합니다.
- 워터폴 모델 (Waterfall Model):
- 계획 주도적 모델로, 명확하게 구분된 여러 단계(요구사항 분석, 설계, 구현, 통합 및 테스트, 운영 및 유지보수)로 이루어져 있습니다.
- 각 단계는 이전 단계가 완료되어야 다음 단계로 진행할 수 있는 선형적 접근 방식을 취합니다.
- 변경 사항을 수용하기 어렵다는 단점이 있으며, 요구사항이 잘 정의되어 있고 변경 가능성이 적을 때 적합합니다.
- 증분 개발 (Incremental Development):
- 요구사항 분석, 개발 및 검증 단계가 서로 교차하며 진행됩니다.
- 계획 주도적이거나 애자일 방식일 수 있으며, 사용자 피드백을 받아 차례대로 시스템을 개발하고 배포합니다.
- 변경 요구에 더 유연하게 대응할 수 있으며 빠른 소프트웨어 전달이 가능합니다.
- 재사용 지향 소프트웨어 엔지니어링 (Reuse-oriented Software Engineering):
- 기존 구성 요소를 재사용하여 시스템을 조립하는 접근 방식입니다.
- 계획 주도적이거나 애자일 방식이 될 수 있으며, 시스템을 구성하는 데 필요한 비용과 시간을 절약할 수 있습니다.
- 사용자 요구에 완벽히 부합하지 않을 수 있는 단점이 있습니다.
- 애자일 개발 프로세스 (Agile Development Process):
- 계획은 점진적이며 사용자의 요구사항 변화에 따라 프로세스를 쉽게 변경할 수 있습니다.
워터폴 모델 (Waterfall Model)
단계
- 요구사항 분석 및 정의 (Requirements Analysis and Definition):
- 시스템이 수행해야 할 기능과 조건을 명확히 정의합니다.
- 시스템 및 소프트웨어 설계 (System and Software Design):
- 요구사항을 바탕으로 시스템의 구조와 소프트웨어의 아키텍처를 설계합니다.
- 구현 및 단위 테스트 (Implementation and Unit Testing):
- 설계된 시스템을 코드로 구현하고, 각 단위(컴포넌트)의 기능을 테스트합니다.
- 통합 및 시스템 테스트 (Integration and System Testing):
- 개별적으로 테스트된 컴포넌트들을 통합하고 전체 시스템이 명세를 만족하는지 검증합니다.
- 운영 및 유지보수 (Operation and Maintenance):
- 시스템을 실제 운영 환경에 배포하고, 발생하는 문제들을 수정하며 지속적으로 관리합니다.
문제점
- 변경 수용의 어려움:
- 워터폴 모델은 각 단계가 순차적으로 완료되어야만 다음 단계로 넘어갈 수 있는 구조로 되어 있습니다. 따라서 프로젝트가 진행 중일 때 요구사항의 변경이 발생하면 이를 수용하기 어렵습니다. 이는 재작업을 필요로 하며, 비용과 시간이 증가하는 주된 원인이 됩니다.
- 요구사항의 불안정성:
- 비즈니스 시스템의 경우 안정적인 요구사항을 설정하기 어려울 수 있습니다. 워터폴 모델은 초기에 요구사항을 명확히 정의하고 변경을 최소화하는 데 중점을 두기 때문에, 불확실한 요구사항을 가진 프로젝트에는 적합하지 않습니다.
- 대규모 시스템 엔지니어링 프로젝트에 적합:
- 워터폴 모델은 여러 사이트에서 시스템을 개발하는 큰 규모의 시스템 엔지니어링 프로젝트에서 유리합니다. 이러한 환경에서는 계획 주도적인 워터폴 모델이 작업을 조정하는 데 도움이 됩니다.
증분 개발(Incremental Development)
증분 개발이란?
- 증분 개발은 소프트웨어 개발 과정에서 점진적으로 시스템을 구축하고 테스트하는 방법론입니다.
- 증분적 접근: 요구사항을 분할하여 각각의 작은 부분에 대해 설계, 구현, 테스트를 반복적으로 수행합니다.
- 점진적 전달: 초기에 작은 기능부터 개발하고, 이후 증분적으로 기능을 추가하여 전체 시스템을 완성합니다.
장점
- 변경 수용 용이: 새로운 요구사항이나 변경사항이 발생할 경우, 이미 개발된 부분에 큰 영향을 주지 않고 다음 증분에 반영할 수 있습니다.
- 고객 피드백 활용: 초기에 개발된 기능을 고객에게 제공함으로써, 고객의 피드백을 받고 그 의견을 다음 개발 단계에 반영할 수 있습니다.
- 빠른 소프트웨어 전달: 초기 기능이 빨리 시장에 출시되어 고객이 사용할 수 있으므로, 전통적인 워터폴 모델보다 더 빨리 가치를 제공할 수 있습니다
단점
- 과정의 불투명성: 빠르게 진행되는 개발 과정에서는 각 버전에 대해 문서화를 완벽하게 수행하기 어려워 프로세스의 가시성이 떨어질 수 있습니다.
- 시스템 구조의 저하: 새로운 기능을 지속적으로 추가하면 시스템의 구조가 저하될 수 있으며, 이를 개선하기 위해 리팩토링에 시간과 비용을 투자해야 할 수도 있습니다.
- 비용 증가: 지속적인 변경과 추가 개발로 인해 전체적인 개발 비용이 증가할 수 있습니다.
통합 및 구성 (Integration and configuration)
통합 및 구성이란?
- 소프트웨어 재사용: 기존의 검증된 소프트웨어 구성 요소를 재사용하여 새로운 시스템을 구축함으로써 개발 시간과 비용을 절감합니다.
- 구성 요소 기반 개발: 구성 요소를 조합하고 구성하여 사용자의 특정 요구에 맞게 시스템을 맞춤화합니다.
재사용 가능한 소프트웨어 종류
- 스탠드얼론 애플리케이션 시스템(Stand-alone Application Systems):
- 이들은 일반적으로 상업용 오프더쉘프(COTS) 소프트웨어라고 불리며, 특정 환경에서 사용하기 위해 구성됩니다.
- 예를 들어, 회계 소프트웨어나 사무용 소프트웨어 패키지가 이에 해당합니다.
- 객체 컬렉션(Collections of Objects):
- 특정 기능을 수행하기 위해 개발된 객체들의 패키지로, 컴포넌트 프레임워크와 함께 통합되어 사용됩니다.
- 예를 들어, 자바 라이브러리나 .NET 프레임워크의 클래스 라이브러리가 이에 해당합니다.
- 웹 서비스(Web Services):
- 원격 호출이 가능한 서비스 표준에 따라 개발된 소프트웨어로, 소프트웨어 시스템 간의 상호작용을 가능하게 합니다.
- 이러한 웹 서비스는 SOAP, RESTful API 등을 통해 다른 시스템과 통합할 수 있으며, 예를 들어 날씨 정보, 결제 처리 등의 서비스를 제공합니다.
단계
- 요구 사항 명세화(Requirements Specification):
- 시스템이 충족해야 할 서비스와 운영 및 개발에 관한 제약 조건을 설정하는 단계입니다.
- 소프트웨어 발견 및 평가(Software Discovery and Evaluation):
- 사용할 수 있는 소프트웨어 구성 요소를 찾고, 이들이 프로젝트 요구 사항을 만족시킬 수 있는지 평가합니다.
- 요구 사항 정제(Requirements Refinement):
- 초기 요구 사항을 바탕으로 좀 더 상세하고 구체적인 요구 사항으로 정제합니다. 이 과정에서 재사용할 소프트웨어 구성 요소의 기능과 제약 조건을 고려해야 합니다.
- 응용 시스템 구성(Application System Configuration):
- 선택된 소프트웨어 구성 요소를 통합하고 구성하여 사용자의 요구에 맞게 시스템을 맞춤 설정합니다.
- 구성 요소 적응 및 통합(Component Adaptation and Integration):
- 필요에 따라 구성 요소를 수정하거나 적응시켜 전체 시스템과의 호환성을 보장하며, 모든 구성 요소가 효과적으로 작동하도록 통합합니다.
장점
- 개발 비용 및 위험 감소: 처음부터 새로 개발하는 것보다 기존 구성 요소를 재사용함으로써 개발 비용과 프로젝트 실패 위험을 줄일 수 있습니다.
- 빠른 시스템 전달 및 배포: 재사용 가능한 구성 요소를 활용하므로 시스템을 더 빠르게 구축하고 배포할 수 있습니다.
단점
- 요구사항 타협 필요성: 사용 가능한 구성 요소를 사용하여 시스템을 구축해야 하기 때문에 때로는 사용자의 진정한 요구사항과 완전히 일치하지 않을 수 있습니다.
- 시스템 요소의 진화에 대한 통제력 상실: 재사용된 구성 요소의 소스 코드에 접근할 수 없는 경우, 이 구성 요소의 진화 과정을 제어하기 어려울 수 있습니다.
프로세스 활동
프로세스 활동이란?
- 소프트웨어 개발 과정에서 필수적인 기본 활동들을 다룹니다. 이 활동들은 소프트웨어 시스템의 명세화, 개발, 검증, 그리고 진화를 포함하며, 각각의 개발 프로세스 모델에 따라 다르게 구성될 수 있습니다.
- 이러한 활동들은 워터폴 모델에서는 순차적으로 배열되지만, 증분 개발이나 애자일 모델과 같은 다른 프로세스 모델에서는 이 활동들이 서로 중첩되며 반복적으로 이루어질 수 있습니다.
요구공학 과정
- 요구사항 수집 및 분석(Requirements Elicitation and Analysis):
- 시스템 이해관계자들로부터 요구사항을 수집하고, 이를 분석하여 시스템이 충족해야 할 서비스와 제약 조건을 명확히 합니다. 이 단계에서는 이해관계자들의 필요와 기대를 파악하고, 모호하거나 충돌하는 요구사항을 해결합니다.
- 요구사항 명세화(Requirements Specification):
- 수집된 정보를 바탕으로 요구사항을 상세하게 정의하고, 이를 구조화된 형식(일반적으로 요구사항 명세서)으로 문서화합니다. 이 문서는 개발 과정에서 참조되며, 모든 관련 이해관계자가 이해할 수 있어야 합니다.
- 요구사항 검증(Requirements Validation):
- 명세화된 요구사항이 올바른지, 완전하고, 실행 가능하며, 이해관계자들의 원래 의도를 정확하게 반영하고 있는지 확인합니다. 이 단계는 요구사항이 시스템의 목적에 부합하는지 검증하기 위해 수행됩니다.
명세화
- 시스템의 기능적 및 비기능적 요구사항을 정의: 소프트웨어가 수행해야 할 모든 작업과 성능 기준을 명시합니다.
- 이해관계자 간의 의사소통 도구로 활용: 명세서는 개발자, 프로젝트 관리자, 고객 등 모든 관련 이해관계자가 참조하는 중요 문서입니다.
- 개발 및 테스트의 기준 제공: 명세서는 개발 과정과 테스트 시나리오를 구성하는 데 필요한 기준을 제공합니다.
소프트웨어 설계 및 적용
- 소프트웨어 설계(Software Design)
- 목적: 명세된 요구사항을 충족하는 소프트웨어 구조를 정의하고, 시스템의 아키텍처, 모듈, 인터페이스, 데이터베이스 등을 설계합니다.
- 아키텍처 설계: 시스템의 전체적인 구조와 주요 구성 요소들의 관계를 정의합니다.
- 상세 설계: 각 구성 요소의 내부 동작과 인터페이스를 상세히 설계합니다.
- 데이터베이스 및 인터페이스 설계: 데이터 저장 방식과 다른 시스템 또는 사용자와의 상호작용 방법을 설계합니다.
- 소프트웨어 구현(Software Implementation)
- 목적: 설계된 아키텍처를 바탕으로 실제 소프트웨어를 코딩하고, 모든 모듈을 개발하여 시스템을 구축합니다.
- 프로그래밍: 설계 문서를 참고하여 개별 모듈 또는 컴포넌트를 코딩합니다.
- 디버깅: 프로그램의 오류를 찾아 수정합니다. 이는 구현 과정에서 필수적인 단계입니다.
- 모듈 통합: 개별적으로 구현된 모듈들을 통합하고 시스템 전체가 원활하게 작동하는지 확인합니다.
설계 과정 (Design activities)
- 아키텍처 설계(Architectural Design)
- 목적: 시스템의 전체 구조와 주요 구성 요소들을 정의하고, 이들 간의 관계 및 상호작용을 설계합니다.
- 세부 활동: 서브시스템이나 모듈화된 구성 요소를 식별하고, 각 요소가 시스템 내에서 어떻게 통합될지를 계획합니다.
- 데이터베이스 설계(Database Design)
- 목적: 시스템이 요구하는 데이터를 효과적으로 저장하고 관리하기 위한 데이터 구조와 데이터베이스 스키마를 설계합니다.
- 세부 활동: 데이터의 저장 형식, 관계, 접근 방법, 보안 요구사항을 정의합니다.
- 인터페이스 설계(Interface Design)
- 목적: 사용자와 시스템 간의 상호작용을 용이하게 하며, 시스템 내부 구성 요소 간의 통신 인터페이스를 설계합니다.
- 세부 활동: 사용자 인터페이스(UI) 설계, API 및 데이터 교환 포맷을 정의하여 사용자 경험(UX)을 최적화하고, 시스템 간 통합을 지원합니다.
- 구성 요소 설계 및 선택(Component Design and Selection)
- 목적: 개별 구성 요소의 세부적인 작동 방식과 구현을 설계하고, 필요한 경우 외부에서 구매하거나 재사용할 구성 요소를 선택합니다.
- 세부 활동: 각 구성 요소의 기능적 요구사항을 만족하도록 설계하고, 외부 라이브러리나 서드 파티 구성 요소의 선택을 고려합니다.
시스템 구현 (System implementation)
- 구현과 프로그래밍:
- 설계 단계에서 정의된 소프트웨어 구조를 바탕으로 실제 프로그램을 개발합니다. 이는 주로 개발자들이 설계 사양에 따라 코드를 작성하는 과정을 말합니다.
- 디버깅:
- 개발 과정에서 발생하는 오류를 찾아내고 수정하는 활동입니다. 이는 소프트웨어가 제대로 작동하는지 확인하는 중요한 과정입니다.
- 프로그래밍과 구현의 관계:
- 프로그래밍은 개인적인 활동으로 간주되며, 표준 프로세스가 존재하지 않습니다. 디버깅은 프로그램의 결함을 찾아 수정하는 활동으로, 소프트웨어 구현의 일부입니다.
소프트웨어 검증 (Software validation)
- 검증(Verification)
- 목적: 소프트웨어가 그 명세에 따라 올바르게 구축되었는지 확인합니다.
- 활동: 소프트웨어가 설계 문서와 기술 명세서에 정의된 사항들을 정확하게 따르고 있는지 검토합니다. 이 과정에는 코드 리뷰, 정적 분석 도구 사용 등이 포함될 수 있습니다.
- 유효성 검사(Validation)
- 목적: 소프트웨어가 사용자의 실제 요구사항을 만족하는지 확인합니다.
- 활동: 실제 사용 환경에서 소프트웨어를 실행하여 사용자 요구사항을 충족하는지 테스트합니다. 이는 종종 사용자 테스트, 베타 테스팅 등을 통해 수행됩니다.
- 테스트 및 리뷰
- 활동: 소프트웨어 검증과 유효성 검사를 위한 주요 도구로서, 시스템 테스트가 광범위하게 사용됩니다. 이는 시스템이 실제 데이터와 상호작용하는 상황을 시뮬레이션하여 예상된 결과를 제공하는지 확인합니다.
- 문제 해결 및 피드백
- 활동: 검증 및 유효성 검사 과정에서 발견된 문제를 해결하고, 이를 기반으로 소프트웨어를 개선합니다. 이 과정은 개발주기 내내 반복적으로 수행되어 시스템의 품질을 지속적으로 향상시키는 데 기여합니다.
테스트 (testing)
단계
- 컴포넌트 테스팅(Component Testing)
- 목적: 개별 컴포넌트 또는 모듈이 정확하게 기능하는지 확인합니다.
- 세부 사항: 개발된 각 컴포넌트가 독립적으로 테스트되며, 이 단계에서는 주로 함수 또는 클래스 단위의 오류를 찾아냅니다.
- 시스템 테스팅(System Testing)
- 목적: 통합된 전체 시스템이 설계 사양에 따라 올바르게 작동하는지 평가합니다.
- 세부 사항: 시스템 테스팅은 통합된 시스템의 모든 모듈이 함께 제대로 작동하는지 확인하기 위해 수행됩니다. 이 단계에서는 시스템의 모든 구성 요소가 정상적으로 상호작용하는지 검증합니다.
- 고객(승인) 테스팅(Customer/Acceptance Testing)
- 목적: 실제 사용 환경에서 고객이 시스템을 테스트하여, 시스템이 사용자의 요구사항을 만족하는지 최종적으로 확인합니다.
- 세부 사항: 이 테스트는 종종 ‘베타 테스팅’으로도 수행되며, 실제 사용자가 시스템을 사용해 보고 그 피드백을 바탕으로 필요한 마지막 수정을 할 수 있는 기회를 제공합니다.
소프트웨어 진화 (Software evolution)
소프트웨어 진화의 필요성
- 비즈니스 요구사항의 변화: 시장 조건, 고객 요구사항, 법적 규제 변경 등 외부 환경의 변화에 대응하기 위해 소프트웨어를 수정하고 업데이트해야 합니다.
- 기술 발전: 새로운 기술의 등장으로 인해 소프트웨어를 최신 기술로 업그레이드하거나 리팩토링할 필요가 있습니다.
소프트웨어 진화의 과정
- 오류 수정: 발견된 버그나 성능 문제를 해결합니다.
- 기능적 개선: 사용자의 피드백을 바탕으로 새로운 기능을 추가하거나 기존 기능을 개선합니다.
- 환경적 적응: 운영 시스템이나 하드웨어 업그레이드에 맞추어 소프트웨어를 조정합니다.
소프트웨어 진화의 도전
- 비용 관리: 소프트웨어 진화는 추가적인 비용이 발생하며, 이는 프로젝트 예산에 영향을 미칠 수 있습니다.
- 기존 시스템과의 호환성: 새로운 기술이나 업데이트를 기존 시스템에 통합할 때 호환성 문제가 발생할 수 있습니다.
- 품질 유지: 지속적인 업데이트와 변경 과정에서 소프트웨어의 품질을 일관되게 유지하는 것이 중요합니다.
변화 다루기 (Coping with change)
- 변화는 큰 소프트웨어 프로젝트에서 불가피하다.
- 비즈니스 변화, 새로운 기술, 플랫폼 변화
- 변화는 재작업을 요구하기 때문에 비용을 발생시킨다.
재작업 비용 줄이기 방법
- 변화 예측 (Change anticipation)
- 소프트웨어 프로세스는 재작업이 필요하기 전에 가능한 변경 사항을 예측할 수 있는 활동을 포함해야 합니다. 예를 들어, 시스템의 핵심 기능을 보여주는 프로토타입을 개발하여 고객에게 제시함으로써 초기 단계에서 피드백을 받고 요구사항을 재정의할 수 있습니다.
- 변화 내성 (Change tolerance)
- 이 전략은 점진적 개발을 포함하며, 제안된 변경사항을 아직 개발되지 않은 증분에 구현할 수 있습니다. 이는 전체 시스템을 수정할 필요 없이 변경을 수용할 수 있게 하여, 필요한 경우에만 작은 부분의 시스템을 변경하게 합니다.
요구사항 변화 다루기
시스템 프로토타이핑 (System Prototyping)
- 시스템 또는 시스템의 일부를 빠르게 개발하여 고객의 요구사항과 설계 결정의 타당성을 확인합니다.
- 장점
- 프로토타이핑은 요구사항 공학 과정에서 요구사항 수집 및 검증에 도움을 줄 수 있으며, 설계 과정에서 다양한 옵션을 탐색하고 UI 설계를 개발하는 데 사용될 수 있습니다.
- 개선된 시스템 사용성: 프로토타이핑을 통해 사용자 인터페이스 및 경험을 테스트하고 최적화함으로써 최종 제품의 사용성을 향상시킬 수 있습니다.
- 사용자의 실제 필요에 더욱 부합: 초기 단계에서 사용자의 피드백을 받아 요구사항을 보다 정확하게 파악하고 반영할 수 있습니다. 이는 사용자의 실제 필요와 더 밀접하게 맞는 솔루션을 제공합니다.
- 개선된 디자인 품질: 다양한 디자인 옵션을 실험하고 비교함으로써, 더 나은 디자인 결정을 내릴 수 있습니다. 이는 전반적인 제품의 품질을 향상시킵니다.
- 개선된 유지 관리성: 초기 단계에서 발견되지 않았을 수 있는 설계상의 문제를 조기에 식별하고 수정할 수 있어, 시스템의 유지 관리가 용이해집니다.
- 개발 노력 감소: 초기 프로토타이핑을 통해 개발 과정에서 잠재적인 문제를 사전에 식별하고 해결함으로써, 장기적으로 더 많은 시간과 리소스를 절약할 수 있습니다.
- 테스트 과정: 프로토타입을 사용하여 백-투-백 테스트를 실행할 수 있습니다.
- 과정
- 프로토타입 목표 설립
- 프로토타입 기능 정의
- 프로토타입 개발
- 프로토타입 평가
- 프로토타입 개발
- 프로토타이핑 도구 사용: 프로토타입 개발에는 빠른 프로토타이핑 언어나 도구가 사용될 수 있습니다. 이러한 도구들은 개발 속도를 빠르게 하고, 쉽게 변경할 수 있게 해 줍니다.
- 기능 생략: 프로토타입에서는 전체 제품의 모든 기능을 포함하지 않습니다. 대신, 아직 잘 이해되지 않는 제품의 특정 영역에 초점을 맞춥니다.
- 오류 검사 및 회복 제외: 프로토타입은 일반적으로 오류 검사 및 회복 기능을 포함하지 않습니다. 이는 프로토타입이 주로 기능성을 시연하기 위한 목적으로 사용되기 때문입니다.
- 기능적 요구사항에 집중: 프로토타입은 신뢰성이나 보안과 같은 비기능적 요구사항보다는 기능적 요구사항에 더 많은 초점을 둡니다. 이는 프로토타입이 주로 기능적 측면을 검증하기 위해 사용되기 때문입니다.
- 버려지는 프로토타입
- 비기능적 요구사항 충족 불가: 일회용 프로토타입은 종종 시스템을 성능, 보안, 안정성 등의 비기능적 요구사항에 맞춰 조정하는 것이 불가능할 수 있습니다.
- 문서화 부족: 이러한 프로토타입은 일반적으로 충분히 문서화되지 않으므로, 개발 과정에서의 결정이나 변경 사항을 추적하기 어렵습니다.
- 구조의 저하: 빠른 변경을 통해 개발되는 프로토타입은 구조가 저하될 가능성이 높으며, 이는 유지 관리와 확장을 어렵게 만듭니다.
- 조직의 품질 기준 미달: 프로토타입은 종종 조직의 일반적인 품질 기준을 충족하지 못할 수 있습니다.
점진적 전달 (Incremental Delivery)
- 소프트웨어 개발 프로젝트에서 시스템을 단일 전달이 아닌 여러 단계의 증분으로 나누어 전달하는 접근법입니다. 각 증분은 요구되는 기능의 일부를 구현합니다.
- 사용자 요구사항은 우선순위에 따라 정렬되며, 가장 높은 우선순위를 가진 요구사항들이 초기 증분에 포함됩니다.
- 증분의 개발이 시작되면, 그 증분에 대한 요구사항은 고정됩니다. 그러나 후속 증분들에 대한 요구사항은 계속해서 진화할 수 있습니다.
- 점진적 개발 (Incremental development): 소프트웨어를 여러 증분으로 나누어 개발하고, 각 증분을 완성된 후에 평가합니다. 이 방식은 애자일 방법론에서 자주 사용되며, 사용자 또는 고객 대리인에 의해 각 증분이 평가됩니다.
- 점진적 전달 (Incremental delivery): 각 증분이 사용자에게 전달되어 실제 사용에 대한 평가를 받습니다. 이를 통해 소프트웨어의 실질적인 사용에 대한 보다 현실적인 평가를 받을 수 있습니다. 이러한 방식은 특히 기존 시스템을 대체하는 경우 어려움을 겪을 수 있는데, 새로운 증분이 기존 시스템보다 기능이 적기 때문입니다.
- 장점
- 기능의 조기 제공: 각 증분을 통해 사용자에게 시스템 기능을 조기에 제공할 수 있어, 사용자가 시스템을 더 빠르게 활용할 수 있습니다.
- 프로토타이핑의 이점: 초기 증분은 후속 증분의 요구사항을 정의하는 데 도움이 되는 프로토타입 역할을 할 수 있습니다.
- 프로젝트 실패 위험 감소: 점진적으로 전달함으로써, 전체 프로젝트가 실패할 위험이 감소합니다.
- 테스트의 집중: 가장 우선순위가 높은 시스템 서비스는 가장 많은 테스트를 받게 됨으로써, 높은 품질을 유지할 수 있습니다.
- 문제점
- 공통 기능의 식별 문제: 각 증분이 구현될 때 까지 상세한 요구사항이 정의되지 않기 때문에, 모든 증분에서 필요로 하는 공통 기능을 초기에 식별하기 어려울 수 있습니다.
- 반복적 프로세스와 조달 모델의 충돌: 소프트웨어의 사양을 점진적으로 개발하는 반복적 프로세스의 본질은 많은 조직에서 사용되는 조달 모델과 충돌할 수 있습니다. 조달 모델에서는 전체 시스템 사양이 시스템 개발 계약의 일부로 요구되는 경우가 많습니다.
프로세스 개선 (Process improvement)
프로세스 개선이란?
- 많은 소프트웨어 회사들이 그들의 소프트웨어 품질을 향상시키고, 비용을 줄이며, 개발 프로세스를 가속화하기 위해 소프트웨어 프로세스 개선에 착수하고 있습니다.
- 프로세스 개선은 기존 프로세스를 이해하고 이러한 프로세스를 변경하여 제품 품질을 높이고/또는 비용 및 개발 시간을 줄이는 것을 의미합니다.
개선 접근법
- 프로세스 성숙도 접근법: 이 접근법은 프로세스와 프로젝트 관리를 개선하고 좋은 소프트웨어 엔지니어링 실천을 도입하는 데 중점을 둡니다. 프로세스 성숙도의 수준은 조직의 소프트웨어 개발 프로세스에서 좋은 기술적 및 관리적 실천이 얼마나 채택되었는지를 반영합니다.
- 애자일 접근법: 애자일 접근법은 반복적인 개발과 소프트웨어 프로세스에서 오버헤드를 줄이는 데 초점을 맞춥니다. 애자일 방법의 주요 특성은 기능의 빠른 전달과 변화하는 고객 요구사항에 대한 반응성입니다.
프로세스 개선을 위한 주요 활동
- 프로세스 측정 (Process Measurement):
- 소프트웨어 프로세스나 제품의 하나 이상의 속성을 측정합니다.
- 측정된 데이터는 개선이 효과적이었는지 결정하는 데 도움이 되는 기준선(baseline)을 형성합니다.
- 프로세스 측정은 가능한 한 정량적인 데이터 수집에 초점을 맞추어야 합니다.
- 명확하게 정의된 프로세스 표준이 없는 조직에서는 측정하기 어렵기 때문에, 측정을 시작하기 전에 프로세스를 정의해야 할 수도 있습니다.
- 수집된 프로세스 측정치는 프로세스 개선을 평가하는 데 사용되어야 합니다.
- 측정은 개선을 추진하는 데 사용되어야 하지만, 측정치가 개선을 주도해야 하는 것은 아닙니다. 개선의 주된 동기는 조직의 목표가 되어야 합니다.
- 측정 지표 예시
- 프로세스 활동 완료 시간: 프로세스 활동이 완료되는 데 필요한 캘린더 시간 또는 노력(인력-일수)을 측정합니다.
- 프로세스 또는 활동에 필요한 자원: 프로세스 또는 활동에 필요한 총 노력을 인력-일수로 측정합니다.
- 특정 이벤트의 발생 횟수: 발견된 결함의 수와 같이 특정 이벤트가 발생하는 횟수를 측정합니다.
- 프로세스 분석 (Process Analysis):
- 현재 프로세스가 평가되고 프로세스의 약점과 병목 현상이 식별됩니다.
- 프로세스 모델(때로는 프로세스 맵이라고 함)이 개발되어 프로세스를 설명할 수 있습니다.
- 프로세스 변경 (Process Change):
- 식별된 프로세스 약점을 해결하기 위한 변경사항이 제안됩니다.
- 이 변경사항들이 도입되고 나면, 변경의 효과에 대한 데이터 수집이 재개됩니다.
The SEI capability maturity model
- 초기(Initial):
- 프로세스가 기본적으로 관리되지 않고, 예측 가능하거나 일관된 방법으로 진행되지 않습니다.
- 반복 가능(Repeatable):
- 프로젝트 관리 절차가 정의되어 있으며, 성공적인 프로젝트를 위한 기초를 마련할 수 있습니다.
- 정의됨(Defined):
- 프로세스 관리 절차와 전략이 기업 전체에 정의되고 사용됩니다.
- 관리됨(Managed):
- 품질 관리 전략이 정의되어 있으며, 제품과 프로세스 성능이 이해되고, 통제됩니다.
- 최적화됨(Optimizing):
- 지속적인 프로세스 개선이 추진되며, 성숙한 프로세스가 조직 전반에 퍼져 있습니다.