[소프트웨어 공학] Software Processes

Software Process

소프트웨어 공학에서 소프트웨어 프로세스는 소프트웨어 시스템을 개발하기 위해 필요한 일련의 구조화된 활동들을 의미한다. 소프트웨어 프로세스는 매우 다양한 형태가 존재하지만, 일반적으로는 다음과 같은 네 가지 기본 활동을 포함한다.

첫째, 명세(Specification) 단계에서는 시스템이 무엇을 해야 하는지를 정의한다. 둘째, 설계 및 구현(Design and Implementation) 단계에서는 시스템의 구조를 정의하고 실제로 시스템을 구현한다. 셋째, 검증(Validation) 단계는 고객이 원하는 시스템이 제대로 만들어졌는지를 확인하는 과정이다. 마지막으로, 진화(Evolution) 단계에서는 고객의 요구 변화에 따라 시스템을 수정하고 발전시킨다.

이러한 활동들을 하나의 모델로 추상화한 것이 바로 소프트웨어 프로세스 모델이다. 소프트웨어 프로세스 모델은 특정 관점에서 소프트웨어 개발 과정을 설명한 추상적 표현이다.

프로세스를 설명할 때 우리는 일반적으로 데이터 모델 명세, 사용자 인터페이스 설계와 같은 개별 활동들과, 이 활동들이 어떻게 순차적으로 진행되는지에 대해 논의한다. 이 외에도 프로세스 설명에는 다음과 같은 요소들이 포함될 수 있다.

• 산출물(Products) : 프로세스 활동의 결과물
• 역할(Roles) : 프로세스에 참여한 사람들이 맡은 책임
• 사전 조건과 사후 조건(Pre- and Post-conditions) : 어떤 활동이 수행되기 전과 후에 반드시 성립해야 하는 조건들

소프트웨어 프로세스는 크게 두 가지 범주로 나눌 수 있다. 하나는 계획 기반 프로세스(Plan-driven Process)이고, 다른 하나는 애자일 프로세스(Agile Process)이다.

계획 기반 프로세스는 모든 활동을 사전에 철처히 계획하고, 그 계획에 따라 진행 상황을 측정하는 방식이다. 반면, 애자일 프로세스는 계획을 점진적으로 수립하며, 고객 요구사항의 변화에 따라 유연하게 프로세스를 변경할 수 있다. 실제 현업에서는 이 두 가지 접근 방식의 요소들을 혼합하여 사용하는 경우가 대부분이다. 중요한 점은 “올바른 소프트웨어 프로세스”라는 것은 없으며, 상황에 따라 적절한 방식을 선택하는 것이 중요하다는 것이다.

소프트웨어 프로세스 모델

대표적인 소프트웨어 프로세스 모델로는 폭포수 모델(Waterfall Model), 점진적 개발(Incremental Development), 통합 및 구성(Integration and Configuration) 모델이 있다.

1. 폭포수 모델

폭포수 모델은 전통적인 계획 기반 모델로, 명확하게 구분된 단계들을 순차적으로 진행하는 구조이다. 이 모델은 다음과 같은 단계를 거친다.

• 요구사항 분석 및 정의
• 시스템 및 소프트웨어 설계
• 구현 및 단위 테스트
• 통합 및 시스템 테스트
• 운영 및 유지보수

폭포수 모델의 가장 큰 단점은 프로세스가 진행된 후에 변경을 수용하기 어렵다는 점이다. 원칙적으로는 한 단계를 완료한 후에만 다음 단계로 넘어갈 수 있기 때문이다. 이러한 특성 때문에 요구사항이 명확하고 변경 가능성이 적은 경우에만 적합하다.

또한, 폭포수 모델은 여러 지역에 걸쳐 개발되는 대규모 시스템이나, 정해진 문서와 계획이 필요한 상황에서 많이 사용된다. 이러한 환경에서는 계획 중심의 접근이 개발 작업을 조율하는 데 유리하기 때문이다.

2. 점진적 개발(Incremental Development)

점진적 개발은 명세, 개발, 검증 단계를 반복적으로 수행하면서 시스템을 점진적으로 완성해 나가는 방식이다. 계획 기반일 수도 있고 애자일 방식일 수도 있다.

이 방식의 장점은 다음과 같다.

• 고객 요구 변경에 유연하게 대응 가능하다.
• 분석과 문서를 반복적으로 작성할 필요가 없기 때문에 비용이 절감된다.
• 개발 중간 결과를 보여줌으로써 고객의 피드백을 빠르게 받을 수 있다.
• 유용한 소프트웨어를 더 빠르게 전달할 수 있다.

그러나 점진적 개발에도 단점이 있다.

• 프로세스가 외부에서 명확히 보이지 않는다. 관리자는 진행 상황을 파악할 수 있는 정기적인 산출물이 필요하지만, 점진적 개발에서는 이를 제공하기 어렵다.
• 지속적인 변경은 시스템 구조를 점점 손상시킬 수 있다. 구조 유지를 위해 정기적으로 리팩토링이 필요하며, 그렇지 않으면 점차 유지보수가 어려워진다.

3. 통합 및 구성(Integration and Configuration)

통합 및 구성 방식은 기존에 개발된 소프트웨어 구성 요소나 상용 시스템(COTS: Commercial Off-The-Shelf)을 재사용하여 시스템을 구성하는 방식이다.

이러한 구성 요소는 사용자 요구에 맞게 기능을 조정하거나 설정(configure)할 수 있으며, 대부분의 비즈니스 시스템에서는 이 방식을 기본으로 사용하고 있다.

재사용 가능한 소프트웨어에는 다음과 같은 종류가 있다.

• 독립 실행형 애플리케이션 시스템(COTS 소프트웨어)
• .NET이나 J2EE와 같은 프레임워크와 통합되도록 설계된 객체 모음
• 웹서비스 : 표준에 따라 개발되어 원격으로 호출 가능한 서비스

이러한 재사용 지향 소프트웨어 엔지니어링(Reuse-Oriented Software Engineering)에서는 다음과 같은 단계로 프로세스를 진행한다.

1. 요구사항 명세
2. 소프트웨어 발견 및 평가
3. 요구사항 정제
4. 애플리케이션 시스템 구성
5. 구성 요소 수정 및 통합

이 방식의 장점은 다음과 같다.

• 처음부터 개발할 필요가 없기 때문에 비용과 위험을 줄일 수 있다.
• 시스템을 더 빠르게 배포하고 전달할 수 있다.

하지만 다음과 같은 단점도 존재한다.

• 구성 요소가 기존에 만들어진 것이기 때문에, 사용자 요구에 딱 맞게 설계되지 않았을 가능성이 있다. 그 결과로 요구사항을 절충해야 하는 상황이 발생할 수 있다.
• 시스템 진화에 대한 제어권을 일부 잃을 수 있다.

이처럼 다양한 소프트웨어 프로세스와 모델은 각각의 장점과 단점이 존재하며, 특정 프로젝트의 특성에 따라 적절한 방식이나 조합을 선택하는 것이 중요하다. 소프트웨어 공학에서는 이러한 모델들을 이해하고, 실무에 맞게 유연하게 적용할 수 있는 능력이 요구된다.

Process Activities

실제 소프트웨어 프로세스는 단순히 기술적인 활동만으로 이루어지는 것이 아니다. 소프트웨어 개발 과정에는 기술적인 활동뿐 아니라 협업 및 관리 활동이 복합적으로 얽혀 있다. 이 모든 활동은 하나의 공통된 목표, 즉 소프트웨어 시스템의 명세, 설계, 구현 그리고 테스트를 수행하기 위한 것이다.

앞서 소개한 네 가지 기본 프로세스 활동(명세, 개발, 검증, 진화)은 소프트웨어 개발 모델에 따라 다양한 방식으로 구성된다. 예를 들어, 폭포수 모델에서는 이러한 활동들을 순차적으로 배치되며, 각 단계를 완료한 뒤에 다음 단계로 넘어가는 구조를 갖는다. 반면, 점진적 개발 모델에서는 이 활동들이 상호 얽혀서 진행되며, 필요에 따라 유연하게 반복된다.

The Requirements Engineering Process

요구사항 공학(Requirements Engineering)은 시스템이 제공해야 하는 서비스와, 시스템의 운영 및 개발에 적용될 제약사항을 정의하는 과정을 의미한다.

Requirements Engineering은 다음과 같은 세 가지 주요 활동으로 구성된다.

1. 요구사항 도출 및 분석(Requirments Elicitation and Analysis) : 시스템 이해 관계자들이 시스템에서 필요로 하거나 기대하는 사항을 수집하고 분석하는 과정이다.
2. 요구사항 명세(Requirments Specification) : 도출된 요구사항을 문서화하여 구체적으로 정의하는 단계이다.
3. 요구사항 검증(Requerments Validation) : 작성된 요구사항이 타당하며, 고객이 실제로 원하는 내용을 포함하고 있는지를 확인하는 과정이다.

Software Design and Implementation

소프트웨어 설계 및 구현은 시스템 명세를 실행 가능한 형태의 시스템으로 변환하는 과정이다. 설계 단계에서는 명세를 만족시키는 소프트웨어 구조를 구상하고, 구현 단계에서는 이를 실제 프로그램으로 작성한다.

설계와 구현은 서로 밀접하게 연결되어 있으며, 대부분의 경우 이 두 단계는 서로 섞여(interleaved) 진행된다.

A General Model of the Design Process

소프트웨어 설계는 다음고 같은 주요 활동들로 구성된다.

• 아키텍쳐 설계(Architectural Design) : 시스템의 전반적인 구조를 정의한다. 주요 구성 요소(서브 시스템이나 모듈), 이들 간의 관계, 그리고 어떻게 배치될지를 식별한다.
• 데이터베이스 설계(Database Design) : 시스템이 사용할 데이터 구조를 설계하고, 데이터 베이스에 어떻게 저장될지를 정의한다.
• 인터페이스 설계(Interface Design) : 시스템 구성 요소 간의 인터페이스를 정의한다.
• 구성 요소 선택 및 설계(Component Selection and Design) : 기존에 사용할 수 있는 재사용 가능한 구성 요소를 탐색하며, 없다면 새로운 구성 요소를 설계하고 동작 방식을 정의한다.

System Implementation

소프트웨어 구현은 직접 새로운 프로그램을 개발하거나, 기존 애플리케이션 시스템을 설정(configure)하여 수행될 수 있다.

일반적으로 설계와 구현은 완전히 분리되지 않으며, 서로 교차하면서 동시에 진행된다.

프로그래밍은 대부분 개발자 개인이 수행하는 활동으로, 명확하게 정해진 표준 절차는 없다. 구현 중 발생하는 오류를 찾아 수정하는 디버깅(Debugging)도 구현 단계의 중요한 활동 중 하나다.

Software Validation

소프트웨어 검증(Verification)과 확인(Validation), 즉 V&V 활동은 시스템이 명세에 부합하는지, 그리고 고객의 요구를 만족하는지를 보여주는 데 목적이 있다.

검토, 리뷰, 테스트와 같은 확인 절차가 여기에 포함된다. 특히 시스템 테스트는 명세를 기반으로 작성된 테스트 케이스를 사용하여 실제 데이터를 입력하고, 시스템이 제대로 동작하는지 검증한다.

실무에서 가장 일반적으로 사용되는 V&V 활동은 바로 테스트(Testing)이다.

Stages of Testing

테스트 활동은 다음과 같은 세 단계로 구성된다.

1. 컴포넌트 테스트(Component Testing) : 개별 구성 요소(함수, 객체, 모듈 등)를 독립적으로 테스트한다.
2. 시스템 테스트(System Testing) : 전체 시스템을 통합하여 테스트하며, 시스템의 창발적 특성(emergent properties)을 확인하는 것이 중요하다.
3. 고객 테스트(Customer Testing) : 실제 고객 데이터를 사용하여 시스템이 고객 요구를 만족하는지를 테스트한다.

Testing Phases in a Plan-Driven Process(V-Model)

계획 기반 프로세스에서 테스트는 개발 단계와 긴밀하게 연계되어 있다. 이러한 구조는 종종 V-Model로 표현되며, 요구사항과 설계 단계에 대응되는 검증 단계가 각기 존재한다.

Software Evolution

소프트웨어는 본질적으로 유연하며, 변화가 가능하다.

업무 환경이 바뀌면 그에 따라 시스템의 요구사항도 달라지게 되며, 이에 따라 소프트웨어도 진화하고 변화해야 한다.

과거에는 개발(development)과 유지보수(evolution)를 명확히 구분했지만, 점점 더 많은 시스템이 유지보수를 전제로 개발되기 때문에 이 구분은 점차 무의미해지고 있다.

System Evolution

오늘날 대부분의 시스템은 완전히 새로운 형태로 개발되지 않는다. 기존 시스템을 수정하거나 확장하는 식으로 진화하며, 이러한 변화는 끊임없이 일어난다. 따라서 소프트웨어 프로세스는 초기 개발뿐 아니라 시스템의 전 생애 주기를 포괄해야 하며, 진화에 유연하게 대응할 수 있는 구조를 갖추어야 한다.

Coping with Change

변화는 모든 대규모 소프트웨어 프로젝트에서 불가피하게 발생한다. 이는 단순히 개발 과정에서의 변수 때문이 아니라, 비즈니스 환경의 변화, 신기술의 등장, 플랫폼의 변화 등이 복합적으로 영향을 미치기 때문이다.

예를 들어, 기업이 새로운 전략을 수립하거나 시장의 요구가 변하면 시스템 요구사항 또한 새롭게 정의되거나 변경될 수밖에 없다. 마찬가지로 새로운 기술이 도입되면 더 나은 구현 방식이 가능해지고, 이를 적용하기 위해 기존 시스템의 변경이 요구된다. 또한, 소프트웨어가 운영되는 플랫폼이 변경되면 호환성을 유지하기 위해 애플리케이션의 수정이 불가피하다.

이러한 변화는 재작업(rework)을 유발하며, 이는 단순히 새로운 기능을 추가하는 비용뿐 아니라 기존 요구사항을 재분석하고 기존 시스템을 수정하는 데 드는 시간과 비용을 포함한다.

Reducing the Costs of Rework

재작업의 비용을 줄이기 위한 방법은 크게 두 가지로 나눌 수 있다.

1. 변화 예측(Change Anticipation) 변화를 미리 예측하고 이를 프로세스 안에 반영하는 것이다. 예를 들어, 고객에게 시스템의 핵심 기능을 보여주기 위한 프로토타입 시스템을 먼저 개발함으로써, 이후 발생할 수 있는 요구사항 변화를 조기에 확인하고 반영할 수 있다.

2. 변화 수용(Change Tolerance) 프로세스를 유연하게 설계하여 변화가 발생했을 때도 낮은 비용으로 수용할 수 있도록 하는 것이다. 일반적으로는 점진적 개발 방식(Incremental development)을 활용하여, 아직 개발되지 않은 다음 단계에서 변화된 요구사항을 반영할 수 있도록 한다. 만약 그마저도 불가능하다면, 최소한의 영향 범위 내에서 하나의 인크리먼트만 수정하여 변화를 반영할 수 있다.

Coping with Changing Requirments

변화하는 요구사항에 대응하기 위해 실질적인 접근 방식으로는 시스템 프로토타이핑(system prototyping)과 점진적 납품(Incremental delivery)이 있다.

• 시스템 프로토타이핑은 시스템의 전부 혹은 일부를 빠르게 개발하여, 고객의 요구사항을 확인하고 설계 결정의 타당성을 점검하는 데 도움을 준다. 이는 변화 예측을 지원하는 방식이다.
• 점진적 납품은 각 인크리먼트를 고객에게 제공하고, 실사용을 통해 피드백을 받는 방식이다. 이 방식은 변화 회피와 변화 수용을 모두 지원한다.

Software Prototyping

프로토타입(prototype)은 초기 버전의 시스템으로, 개념을 시연하거나 설계 대안을 실험하는 데 사용된다. 프로토타입은 다음과 같은 다양한 프로세스 단계에서 활용될 수 있다.

• 요구사항 공학(Requirments Engineering) 과정에서는 요구사항 도출과 검증을 지원하며,
• 설계 과정에서는 다양한 UI 또는 구조적 설계 옵션을 실험할 수 있고,
• 테스트 과정(Testing)에서는 실제 구현된 시스템과 비교하여 테스트할 수 있다.

Benefits of Prototyping

프로토타이핑을 활용하면 다음과 같은 이점이 있다.

• 시스템 사용성이 향상된다.
• 사용자 요구에 더 밀접하게 부합하는 시스템이 개발된다.
• 설계 품질이 개선된다.
• 시스템의 유지보수성이 향상된다.
• 개발 노력이 줄어들어 전체적인 효율성이 향상된다.

The Process of Prototype Development

프로토타입 개발은 일반적으로 빠른 프로토타이핑 도구나 언어를 기반으로 수행되며, 전체 기능을 포함하지 않을 수도 있다.

• 프로토타입은 제품의 이해되지 않은 영역에 집중해야 하며,
• 오류 처리 및 복구는 생략되기도 한다.
• 또한 신뢰성이나 보안과 같은 비기능 요구사항보다는 기능적 요구사항에 초점을 맞춘다.

Throw-away Prototypes

프로토타입은 개발 후 버려져야(throw-away)한다. 그것을 실제 제품 시스템의 기반으로 삼는 것은 바람직하지 않다. 이유는 다음과 같다.

• 비기능 요구사항을 충족하기 위해 시스템을 튜닝하기 어렵다.
• 프로토타입은 문서화되어 있지 않은 경우가 많다.
• 빠른 변경 과정을 통해 구조가 손상되었을 가능성이 높다.
• 일반적으로 조직의 품질 기준을 만족하지 못한다.

Incremental Development and Delivery

점진적 납품(Incremental Delivery)은 시스템을 한 번에 모두 전달하는 대신, 개발과 납품을 여러 인크리먼트로 나누는 방식이다. 각 인크리먼트는 일부 기능을 포함하며, 점진적으로 전체 시스템을 완성해 나간다.

• 사용자 요구사항은 우선순위에 따라 정렬되며,
• 가장 중요한 요구사항은 초기 인크리먼트에 포함된다.
• 한 인크리먼트의 개발이 시작되면 해당 인크리먼트의 요구사항은 고정(frozen)되며, 이후 인크리먼트에 대한 요구사항은 계속해서 진화할 수 있다.

Incremental Developmet는 시스템을 인크리먼트 단위로 개발하고, 각 인크리먼트를 평가한 후 다음 인크리먼트 개발로 넘어간다. 이 방식은 애자일 방법에서 일반적으로 사용되며, 사용자 또는 고객 대리인이 각 인크리먼트를 평가한다.

Incremental Delivery는 각 인크리먼트를 최종 사용자에게 배포하고, 실제 사용을 통해 소프트웨어의 실용성을 평가할 수 있게 한다.

그러나 대체 시스템을 개발하는 경우에는 기존 시스템보다 인크리먼트의 기능이 적기 때문에 점진적 납품이 어려울 수 있다.

Incremental Delivery의 장점은 다음과 같다.

• 각 인크리먼트마다 고객에게 가치를 제공할 수 있어, 기능이 더 빨리 제공된다.
• 초기 인크리먼트는 프로토타입 역할을 하여 이후 인크리먼트에 대한 요구사항을 도출하는 데 도움을 준다.
• 전체 프로젝트 실패 위험이 낮아진다.
• 우선순위가 높은 시스템 기능이 더 많이 테스트된다.

하지만 Incremental Delivery에는 다음과 같은 문제가 있다.

• 대부분의 시스템은 다양한 부분에서 사용되는 공통 기반 기능을 필요로 한다. 이러한 기능을 사전에 정의하지 않으면 모든 인크리먼트에서 중복되거나 누락될 수 있다.
• 반복적 프로세스의 핵심은 명세와 구현이 동시에 발전하는 데 있다. 그러나 많은 조직에서는 완전한 시스템 명세서가 계약 조건으로 요구되기 때문에, 이러한 방식과 충돌이 발생할 수 있다.

Process Improvement

많은 소프트웨어 회사들은 소프트웨어의 품질을 향상시키고 비용을 절감하며 개발 속도를 가속화하기 위해 소프트웨어 프로세스 개선(Software Process Improvement)에 주목하고 있다.

소프트웨어 프로세스 개선이란, 조직 내의 기존 프로세스를 이해하고 이를 변화시켜 제품의 품질을 높이고, 개발 비용과 시간을 줄이는 것을 의미한다.

Approaches to Improvement

프로세스 개선을 위한 접근 방식은 크게 두 가지가 있다.

1. 프로세스 성숙도 접근법(Process Maturity Approach) 이 접근법은 프로세스 및 프로젝트 관리 능력 향상과 함께 우수한 소프트웨어 공학 실천 방안의 도입에 초점을 맞춘다. 조직의 소프트웨어 개발 프로세스가 얼마나 좋은 기술과 관리 관행을 채택하고 있는지를 측정하는 척도가 바로 프로세스 성숙도이다.

2. 애자일 접근법(Agile Approach) 애자일 접근법은 반복적인 개발과 프로세스 내의 불필요한 오버헤드(Overhead)를 줄이는 데 초점을 둔다. 애자일의 핵심 특징은 기능의 빠른 전달과 고객 요구사항 변화에 대한 민첩한 대응이다.

The Process Improvement Cycle

프로세스 개선은 반복적인 주기를 가진다. 다음의 활동들을 반복함으로써 점진적인 개선이 이루어진다.

1. 프로세스 측정(Process Measurement)
   • 소프트웨어 프로세스 또는 산출물의 속성 중 하나 이상을 측정한다.
   • 이러한 측정치는 기준선(baseline) 역할을 하며, 프로세스 개선이 효과적이었는지 판단하는 데 도움을 준다.
2. 프로세스 분석(Process Analysis)
   • 현재 사용 중인 프로세스를 평가하여 약점(weaknesses)이나 병목현상(bottlenecks)을 식별한다.
   • 때로는 프로세스를 설명하는 프로세스 모델(또는 프로세스 맵)을 개발하기도 한다.
3. 프로세스 변경(Prcess Change)
   • 발견된 문제를 해결하기 위한 변경안을 제안하고, 이를 실제 프로세스에 반영한다.
   • 변경이 적용된 이후에는, 변경 효과를 다시 측정하여 새로운 데이터로 개선 주기를 반복한다.

Process Measurement

가능한 경우에는 정량적인 데이터를 수집해야 한다. 하지만 조직 내에 명확한 프로세스 표준이 없을 경우에는 어떤 데이터를 측정해야 할지조차 명확하지 않기 때문에, 먼저 프로세스를 정의해야 하는 상황이 생기기도 한다.

프로세스 측정치는 개선 효과를 평가하는 데 사용되어야 하지만, 이 측정값들이 개선 활동을 주도해서는 안 된다. 진정한 개선의 원동력은 조직의 목표이어야 한다.

Process Metrics

다음은 일반적인 프로세스 측정 항목들이다.

• 활동 완료 시간 : 활동 또는 전체 프로세스를 완료하는 데 걸린 달력 시간 또는 실제 노력 시간
• 소요 자원 : 특정 활동에 투입된 전체 인력 자원
• 특정 이벤트 발생 횟수 : 예를 들어, 발견된 결함의 수

Capability Maturity Levels

소프트웨어 공학 연구소(SEI, Software Engineering Insitute)에서 제시한 프로세스 성숙도 모델(Capability Maturity Model)은 조직의 프로세스 수준을 다음과 같이 5단계로 구분한다.

1. Initial(초기) : 프로세스가 거의 통제되지 않은 상태로, 즉흥적으로 작업이 이루어진다.
2. Repeatable(재현 가능) : 일정한 제품 관리 절차가 정의되어 있으며 반복적으로 사용된다.
3. Defined(정의됨) : 전체 조직 차원의 프로세스 관리 절차와 전략이 정의되고 적용된다.
4. Managed(관리됨) : 품질 관리 전략이 도입되고 운영된다.
5. Optimising(최적화됨) : 지속적인 프로세스 개선 전략이 마련되어 있으며, 이를 통해 성과를 향상시킨다.

Key Points

• 소프트웨어 프로세스는 소프트웨어 시스템을 생상하는 데 필요한 일련의 활동이며, 소프트웨어 프로세스 모델은 이 과정을 추상화한 것이다.
• 일반적인 프로세스 모델로는 폭포수 모델(Waterfall model), 점진적 개발(Incremental Development), 재사용 중심 개발(Reuse-oriented development)이 있다.
• 요구사항 공학은 소프트웨어 명세(Specification)를 개발하는 과정이며, 설계와 구현은 명세를 실행 가능한 시스템으로 변환(transform)하는 활동이다.
• 소프트웨어 검증과 확인(Validation)은 시스템이 명세에 부합하고 사용자의 요구를 만족하는지를 검사하는 과정이다.
• 소프트웨어는 사용자의 새로운 요구에 맞춰 진화해야 하며, 이를 위해 프로토타이핑과 점진적 납품(Incremental Delivery) 같은 활동이 포함되어야 한다.
• 프로세스는 반복적인 개발 및 납품에 적합하도록 구성될 수 있으며, 이렇게 하면 시스템 전체를 방해하지 않고도 변경이 가능해진다.
• 프로세스 개선 접근 방식에는 두 가지가 있다.
  • 애자일(Agile) 접근은 프로세스 오버헤드를 줄이는 데 초점을 둔다.
  • 성숙도 기반(Maturity-based) 접근은 더 나은 관리 및 기술 관행을 도입함으로써 개선을 꾀한다.
• SEI의 프로세스 성숙도 프레임워크는 조직이 얼마나 좋은 소프트웨어 공학 관행을 채택하고 있는지를 단계별로 평가하는 기준이 된다.