[Software Processes]

The software process

• 소프트웨어 시스템을 개발하기 위해 필요한 구조화된 일련의 활동입니다.

• 많은 다양한 소프트웨어 공정이 있지만, 모두 다음을 포함합니다:
  • Specification(명세): 시스템이 무엇을 해야 하는지 정의합니다.
  • Design & implementation(설계 및 구현): 시스템의 조직을 정의하고 시스템을 구현합니다.
  • Validation(검증): 고객이 원하는대로 시스템이 작동하는지 확인합니다.
  • Evolutuin(진화): 고객의 요구 사항이 변경됨에 따라 시스템을 변경합니다.

• 소프트웨어 공정 모델은 공정의 추상적인 표현(abstract representation of a process)입니다. 특정한 관점에서의 프로세스 설명을 제시합니다.

Software process descriptions

• 공정을 설명하고 논할 때, 일반적으로 데이터 모델을 명시하거나 사용자 인터페이스를 디자인하는 등의 활동 및 이러한 활동의 순서에 대해 이야기합니다. 공정 설명은 또한 다음을 포함할 수 있습니다:
  • Products(제품): 공정에서 생성되는 결과물입니다.
  • Roles(역할): 공정에 참여하는 사람들의 책임을 반영합니다.
  • Pre-and post-conditions(사전 및 사후 조건): 프로세스 활동이 실행되거나 제품이 생성된 후에 참된 명제입니다.

Plan-driven and agile processes

• 계획 주도적인 공정은 모든 공정 활동이 미리 계획되고 진행 상황이 이 계획에 따라 측정되는 공정입니다.

• 즉각적인 공정에서는 계획이 점진적으로 이루어지며 고객 요구 사항의 변화를 반영하기 쉽습니다.

• 실제로 대부분의 실무 공정은 계획 주도적 및 즉각적인 접근 방식의 요소를 포함하고 있습니다.

• 소프트웨어 공정에는 옳고 그름이 없습니다.

---

[Software process models(a.k.a. Software Development Life Cycle)]

Software process models(SPM)

• The waterfall model(폭포수 모델)
  계획 주도적인 모델(Plan-driven model). 명확히 구분된 요구사항 및 개발 단계가 있습니다.

• Incremental development(점진적 개발)
  명세, 개발 및 검증이 교차(interleaved)됩니다. 계획 주도적이거나 즉각적일 수 있습니다.

• Integration and configuration(통합 및 구성)
  기존의 재사용(reusable) 가능한/구성(configurable) 가능한 요소를 사용하여 시스템을 조립합니다. 계획 주도적이거나 즉각적일 수 있습니다.

• 실제로 대부분의 대규모 시스템은 이러한 모델의 요소를 모두 포함하는 공정을 사용하여 개발됩니다.

SPM: The waterfall model

Waterfall model phases

• Waterfall model(폭포수 모델)에는 별도로 식별된 단계가 있습니다:
  • 요구사항 분석 및 정의
  • 시스템 및 소프트웨어 설계
  • 구현 및 단위 테스트
  • 통합 및 시스템 테스트
  • 운영 및 유지보수

• 폭포수 모델의 주요 단점은 공정이 시작된 후 변경을 수용하기 어렵다는 것입니다. 원칙적으로, 단계가 완료되어야 다음 단계로 이동할 수 있습니다.

Waterfall model problems

• 프로젝트를 명확하게 구분된 단계(Inflexible partioning)로 나누는 것은 변하는 고객 요구에 대응하기 어렵게 만듭니다.
  • 따라서, 이 모델은 요구사항이 잘 이해되어 있고 설계 과정 중 변경이 상대적으로 제한적일 때에만 적합합니다.
  • 적은 비즈니스 시스템이 안정적인 요구사항을 가지고 있습니다.

• 폭포수 모델은 대부분의 대규모 시스템 엔지니어링 프로젝트에서 사용됩니다.
  이러한 경우, 폭포수 모델의 계획 주도적 특성이 작업을 조정하는 데 도움이 됩니다.

Types of systems where the waterfall model is applicable

• 임베디드 시스템
  하드웨어가 유연하지 않습니다.

• 중요한 시스템
  명세 및 설계가 완료되어야 합니다.
  -> 그렇지 않으면, 철저한 안전 및 보안 분석이 불가능합니다.

• 대규모 소프트웨어 시스템
  여러 회사 간의 복잡한 의사소통을 피해야 합니다.

SPM: Incremental development

Incremental development benefits

• 고객 요구 사항을 수용하는 비용이 감소합니다.
  폭포수 모델보다 재분석 및 문서 작업이 필요한 양이 훨씬 적음.

• 개발된 작업물에 대한 고객 피드백을 받기 쉽습니다.
  고객은 소프트웨어의 시연을 통해 구현된 내용을 확인하고 의견을 제시할 수 있음.

• 유용한 소프트웨어를 고객에게 보다 신속하게 전달하고 배포할 수 있습니다.
  고객은 폭포수 모델보다 빠르게 소프트웨어를 사용하고 가치를 누릴 수 있음.

Incremental development problems

• 과정이 시각적으로 파악하기 어렵습니다.
  매니저들은 진행 상황을 측정하기 위해 정기적인 결과물이 필요합니다. 시스템이 빠르게 개발되면 모든 시스템 버전을 반영하는 문서를 작성하는 것이 비효율적입니다.

• 새로운 증분이 추가됨에 따라 시스템 구조가 저하됩니다.
  소프트웨어를 개선하기 위해 재구성하는 데 시간과 비용을 투자하지 않으면, 정기적인 변경이 구조를 손상시킬 수 있습니다. 추가적인 소프트웨어 변경 사항을 통합하는 것이 점점 더 어렵고 비용이 많이 들 수 있습니다.

SPM: Integration and configuration

• SPM의 통합 및 구성은 기존 구성 요소나 응용 프로그램 시스템을 사용하여 시스템을 통합하는 소프트웨어 재사용을 기반으로 합니다.

• 종종 COTS(Commercial-off-the-shelf) 시스템이라고도 불립니다. 재사용된 요소는 사용자의 요구에 맞게 동작과 기능을 적응시킬 수 있습니다.

• 재사용은 현재 많은 종류의 비즈니스 시스템을 구축하는 데 표준 접근 방식이 되었습니다.

Types of reusable software

• Stand-alone application systems(sometimes called COTS):
  특정 환경에서 사용하기 위해 구성된 COTS(상업용 구성요소)와 같은 시스템입니다.

• 객체 모음:
  .NET 또는 J2EE와 같은 컴포넌트 프레임워크와 통합할 수 있도록 패키지로 개발된 객체들의 모음입니다.

• 웹 서비스:
  서비스 표준에 따라 개발된 웹 서비스로, 원격으로 호출할 수 있습니다.

Reuse-oriented software engineering

Advantages and disadvantages

[Advantages]

• 비용과 위험 감소:
  기존 소프트웨어를 처음부터 개발하는 것이 아니기 때문에 개발 비용과 위험이 줄어듭니다.

• 시스템의 빠른 전달과 배포:
  재사용된 구성 요소들을 통합하여 시스템을 빠르게 구축하고 배포할 수 있습니다.

[Disadvantages]

• 요구 사항의 타협:
  기존 요구 사항과의 호환성을 고려해야 하기 때문에 실제 사용자의 요구 사항을 충족시키지 못할 수 있습니다.

• 재사용된 시스템 요소의 진화에 대한 제어 손실:
  재사용된 요소들의 진화에 대한 제어가 제한될 수 있으며, 이로 인해 시스템이 적절하게 업데이트되지 않을 수 있습니다.

---

[Process activities]

Process activities

• 소프트웨어 프로세스는 기술적, 협력적, 그리고 관리직 활동들의 교차된 일련의 과적으로 구성되어 있습니다.

• 프로세스의 네 가지 기본 활동인 명세화, 개발, 유효성 검사, 진화는 다양한 개발 프로세스에서도 서로 다른 방식으로 조직되어 있습니다. 이 프로세스들은 도구로 지원됩니다.
  예를 들어, 폭포수 모델에서는 이러한 활동들이 연속적으로 조직되어 있지만, 점진적 개발에서는 이러한 활동들이 교차로 조직되어 있습니다.

• 즉, 소프트웨어 프로세스는 다양한 활동들이 교차로 이루어지며, 이러한 활동들은 명세화, 개발, 유효성 검사, 진화라는 네 가지 기본 활동으로 구성됩니다. 이러한 활동들은 다양한 개발 프로세스에서 다르게 조직되어 있으며, 도구에 의해 지원됩니다

Software specification

• 소프트웨어 사양 (Software specification):
  시스템의 운영 및 개발에 대한 서비스 및 제약 조건을 설정하는 프로세스입니다.

• 요구 사항 공학 프로세스 (Requirements engineering process):
  시스템 이해관계자들이 시스템으로부터 요구하는 것 또는 기대하는 것을 파악하는 프로세스입니다.

  • 요구 사양 및 분석(Requirements elicitation and analysis):
    이해관계자들로부터 요구 사항을 수집하고 분석하는 단계입니다.

  • 요구 사양(Requirements specification):
    요구 사항을 자세히 정의하는 단계입니다. 이는 시스템이 어떻게 동작해야 하는지에 대한 명세를 포함합니다.

  • 요구 사양 검증(Requirements validation):
    요구 사항의 유효성을 검사하고 검증하는 단계입니다. 이는 정의된 요구 사항이 실제로 시스템이 충족해야 하는 기대에 부합하는지를 확인합니다.

The requirements engineering process

• 요구사항 식별:
  고객과 사용자와의 상호 작용을 통해 시스템이 제공해야 하는 기능과 제약 조건을 식별합니다.

• 요구사항 분석과 명세:
  수집된 요구사항을 분석하고 구조화된 형태로 명세화하여 시스템의 동작과 속성을 명확하게 정의합니다.

• 요구사항 검증:
  시스템이 요구사항을 충족하는지 확인하기 위해 요구사항을 검토하고 검증합니다.

• 요구사항 관리:
  요구사항을 추적하고 변경을 관리하여 프로젝트 수명 주기 동안 요구사항의 일관성과 완전성을 유지합니다.

Software design and implementation

• 소프트웨어 설계(Software Design)는 시스템 명세를 실행 가능한 시스템으로 변환하는 과정입니다. 이 과정에서 소프트웨어 구조를 설계하여 명세를 실현합니다.

• 구현(Implementation)은 이러한 설계된 구조를 실행 가능한 프로그램으로 번역하는 과정입니다.

A general model of the design process

• Design inputs(설계 입력):
  시스템 요구사항과 명세서 등의 입력 자료를 바탕으로 디자인 프로세스가 시작됩니다.

• Design activities(설계 활동):
  이러한 입력 자료를 기반으로 아키텍처 설계, 세부 설계 등의 다양한 활동이 수행됩니다.

• Design outputs(설계 결과물):
  설계 활동을 통해 생성된 결과물로서, 소프트웨어의 구조, 디자인 문서, 코드 등이 여기에 해당됩니다.

Design activities

디자인 활동은 소프트웨어 시스템을 구성하는 다양한 측면을 설계하는 과정으로, 주로 다음과 같은 활동으로 구성됩니다:

• Architectural desig(아키텍처 설계):
  시스템의 전반적인 구조를 식별하고, 주요 구성 요소(서브시스템 또는 모듈), 그들의 관계 및 분산 방법을 정의합니다.

• Database design(데이터베이스 설계):
  시스템의 데이터 구조를 설계하고, 이를 데이터베이스에 어떻게 표현할지를 결정합니다.

• Interface design(인터페이스 설계):
  시스템 구성 요소 간의 인터페이스를 정의하여, 각 요소가 서로 통신할 수 있도록 설계합니다.

• Component selection and design(구성 요소 선택 및 설계):
  재사용 가능한 구성 요소를 찾거나 사용 가능하지 않을 경우, 해당 구성 요소를 설계하여 시스템에 통합합니다.

이러한 디자인 활동을 통해 소프트웨어 시스템의 구조와 기능을 명확히 정의하고, 구현할 준비를 마칩니다.

System implementation

• 시스템 구현은 소프트웨어를 프로그램으로 개발하거나 응용 프로그램 시스템을 구성함으로써 이루어집니다.

• 디자인과 구현은 대부분의 유형의 소프트웨어 시스템에 대해 교차되는 활동입니다.

• 프로그래밍은 표준 프로세스가 없는 개별적인 활동으로, 디버깅은 프로그램 오류를 찾고 이를 수정하는 활동입니다.

Software validation

소프트웨어 검증은 시스템이 명세를 준수하고 시스템 고객의 요구를 충족하는지를 보여주기 위한 것입니다. 이는 확인 및 검증 (V & V) 과정을 통해 이루어집니다.

• 확인(Verification):
  "제품을 올바르게 만들고 있는가?"
  이는 설계가 명세를 따르고 있는지 확인하는 프로세스를 의미합니다. 다시 말해, 설계된 시스템이 정확하게 명세된 대로 구현되었는지를 확인하는 것입니다.

• 검증(Validation):
  "우리가 올바른 제품을 만들고 있는가?"
  이는 시스템이 요구 사항에 맞게 정상적으로 작동하는지를 확인하는 프로세스를 의미합니다. 다시 말해, 시스템이 실제 요구 사항을 충족시키고 있는지를 확인하는 것입니다.

이 과정은 검사 및 검토 프로세스와 시스템 테스트를 포함합니다. 시스템 테스트는 시스템이 실제로 처리할 데이터의 명세에서 파생된 테스트 케이스를 사용하여 시스템을 실행하는 것을 포함합니다. 테스팅은 가장 일반적으로 사용되는 V & V 활동입니다.

Stages of testing

• 구성 요소 테스트(Component Testing):
  개별 구성 요소를 독립적으로 테스트합니다. 이는 함수, 객체 또는 이러한 엔티티의 일관된 그룹화일 수 있습니다.

• 시스템 테스트(System Testing):
  시스템 전체의 테스트입니다. 나타나는 특성의 테스트는 특히 중요합니다.

• 고객 테스트(Customer Testing):
  고객 데이터를 사용하여 시스템이 고객의 요구를 충족하는지 확인하는 테스트입니다.

Testing phases in a plan-driven software process (V-model)

V-모델의 테스팅 단계는 요구 사항에 따라 상위 단계와 직접적으로 연관되어 있습니다. 이 단계는 다음과 같습니다:

• 단위 테스트(Unit Testing):
  개별적인 구성 요소 또는 모듈이 올바르게 작동하는지 테스트합니다.

• 통합 테스트(Integration Testing):
  단위 테스트된 모듈이 함께 작동하는지 확인합니다.

• 시스템 테스트(System Testing):
  시스템이 전체적으로 요구 사항을 충족하는지 확인합니다.

• 인수 테스트(Acceptance Testing):
  최종 사용자 또는 고객이 시스템을 테스트하고, 요구 사항을 충족하는지 확인합니다.

Software evolution

소프트웨어 진화는 소프트웨어의 유연성에 근거하여 이루어지며, 다음과 같은 특징을 갖습니다:

• 소프트웨어의 요구 사항은 비즈니스 환경의 변화에 따라 변할 수 있습니다. 이에 따라 비즈니스를 지원하는 소프트웨어도 진화하고 변경되어야 합니다.

• 예전에는 개발과 진화(유지보수) 사이에 구분이 있었지만, 점점 새로운 시스템이 적어지면서 이 구분은 무의미해지고 있습니다. 이제는 진화가 개발의 일부로 간주되며, 소프트웨어 시스템은 지속적으로 변화하고 발전해야 합니다.

System evolution

• 시스템 진화는 소프트웨어가 삶주변의 변화에 적응하고 발전하는 과정을 의미합니다.

• 새로운 요구사항이나 환경 변화에 따라 시스템은 수정, 확장 또는 개선되어야 합니다. 이는 기존 시스템의 생애주기 동안 계속적으로 발생할 수 있습니다.

• 진화는 비즈니스 요구사항, 기술 혁신, 사용자 피드백 등 다양한 요인에 의해 촉진됩니다.

---

[Coping with change]

Coping with change

변화는 대형 소프트웨어 프로젝트에서 불가피한 것입니다.

• 비즈니스 변화는 새로운 시스템 요구사항을 도입하거나 변경시킵니다.

• 새로운 기술은 구현을 개선할 수 있는 새로운 가능성을 제공합니다.

• 플랫폼 변경은 애플리케이션 변경을 요구합니다.

변화는 재작업을 유발하므로, 변화의 비용에는 요구사항 재분석과 같은 재작업 비용뿐만 아니라 새로운 기능을 구현하는 비용도 포함됩니다.

Reducing the costs of rework

• 변화 예측(Change anticipation):
  소프트웨어 프로세스에는 중요한 재작업이 필요하기 전에 가능한 변화를 예상할 수 있는 활동이 포함됩니다.
  • 변화 회피(Change avoidance):
    미래의 변화를 피하는 방법은 무엇일까요? 예를 들어, 프로토타입 시스템을 개발하여 시스템의 핵심 기능을 고객에게 보여줄 수 있습니다.

• 변화 용인(Change tolerance):
  프로세스가 변경 사항을 상대적으로 적은 비용으로 수용할 수 있도록 설계됩니다.
  • 일반적으로 이는 어떤 형태의 점진적인 개발(incremental devlopment)을 포함합니다. 제안된 변경 사항은 아직 개발되지 않은 구성 요소에 구현될 수 있습니다. 이것이 불가능한 경우에는 시스템의 작은 부분만 변경하여 변화를 통합해야 할 수 있습니다.

Coping with changing requirements

• 시스템 프로토타이핑(System prototyping):
  시스템이나 시스템의 일부 버전을 빠르게 개발하여 고객의 요구 사항 및 설계 결정의 타당성을 확인하는 것입니다. 이 접근 방식은 변화 예측(Change anticipation)을 지원합니다.

• 점진적인 전달(Incremental delivery):
  시스템의 부분들이 고객에게 전달되어 의견과 실험을 할 수 있습니다. 이것은 변화 회피(Change avoidance)와 변화 용인(Change tolerance)을 둘 다 지원합니다.

Software prototyping

소프트웨어 프로토타이핑은 시스템의 초기 버전으로, 개념을 시연하고 디자인 옵션을 시도하는 데 사용됩니다. 프로토타입은 다음과 같은 곳에서 사용될 수 있습니다:

• 요구 사항 공학 프로세스에서 요구 사항 수집 및 유효성 검사에 도움이 됩니다.

• 디자인 프로세스에서 옵션을 탐색하고 UI 디자인을 개발하는 데 사용될 수 있습니다.

• 테스트 프로세스에서 백투백 테스트를 실행하는 데 사용될 수 있습니다.

Benefits of prototyping

• 시스템의 사용성 향상(Improved system usability)
  프로토타입을 사용하여 사용자와의 상호작용을 미리 확인할 수 있기 때문에 시스템이 사용하기 더 쉬워집니다.

• 사용자의 실제 요구에 더 가깝게 맞춰짐(A closer match to user's real needs)
  프로토타입을 사용하여 초기에 사용자의 피드백을 수집하고 반영함으로써 시스템이 실제 사용 환경에서 필요한 기능을 더 잘 충족시킬 수 있습니다.

• 디자인 품질 향상(Improved design quality)
  프로토타입을 사용하여 다양한 디자인 옵션을 시도하고 검증함으로써 최종 시스템의 디자인 품질이 향상됩니다.

• 유지 보수성 향상(Improved maintainability)
  프로토타입을 통해 초기에 발견된 문제를 해결하고 수정함으로써 시스템의 유지 보수성이 향상됩니다.

• 개발 노력 감소(Reduced development effort)
  프로토타입을 사용하여 초기에 사용자 요구를 명확히 이해하고 시스템을 더 정확하게 개발할 수 있으므로 개발에 필요한 노력이 줄어듭니다.

The process of prototype development

1. 프로토타입 목표 설정(Establish prototype objectives):
   프로토타입을 개발하는 주요 목표와 기대되는 결과를 설정합니다. 이는 프로토타입이 달성해야 할 목적과 기능을 명확하게 정의하는 과정입니다.

2. 프로토타입 계획(Prototyping plan):
   프로토타입 개발의 계획을 수립합니다. 이 단계에서는 프로토타입의 개발 일정, 필요한 자원 및 개발 방법 등을 계획합니다.

3. 프로토타입 기능 정의(Define prototype functionality):
   프로토타입이 제공해야 할 기능과 사용자 요구사항을 명확히 정의합니다. 이는 프로토타입이 개발되는 동안 중점적으로 고려해야 할 기능을 결정하는 단계입니다.

4. 프로토타입 개발(Develop prototype):
   정의된 기능과 목표에 따라 프로토타입을 개발합니다. 이 단계에서는 프로토타입의 구조를 설계하고 구현합니다.

5. 개요 정의(Outline definition):
   프로토타입의 개요를 작성하고 개발 방향을 설정합니다. 이는 프로토타입이 제공할 핵심 기능과 사용자 경험을 개략적으로 설명하는 단계입니다.

6. 실행 가능한 프로토타입(Executable prototype):
   개발된 프로토타입을 실행 가능한 형태로 만듭니다. 이는 프로토타입이 실제로 작동하고 사용자에게 시연될 수 있도록 하는 단계입니다.

7. 프로토타입 평가(Evaluate prototype):
   개발된 프로토타입을 평가하고 검증합니다. 이 단계에서는 프로토타입의 기능, 성능, 사용자 경험 등을 평가하여 개선할 부분을 식별합니다.

8. 평가 보고서(Evaluation report):
   프로토타입의 평가 결과를 문서화하고 보고서 형태로 정리합니다. 이는 프로토타입 개발 과정에서 발견된 문제점과 개선 사항을 기록하는 단계입니다.

Prototype development

• 프로토타입 개발(Prototype development):
  시스템의 초기 버전 또는 모형을 만들어 내는 프로세스입니다.

• 신속한 프로토타입 언어 또는 도구를 기반으로 할 수 있습니다 (May be based on rapid prototyping languages or tools):
  빠른 프로토타입 언어나 도구를 사용하여 개발될 수 있습니다. 이는 빠르게 개발하고 시스템의 초기 모형을 신속하게 구축할 수 있도록 도와줍니다.

• 기능을 생략할 수 있습니다 (May involve leaving out functionality):
  프로토타입은 모든 기능을 포함할 필요가 없습니다. 주로 이해가 부족한 부분에 초점을 맞추기 때문에 일부 기능을 생략할 수 있습니다.

• 프로토타입은 잘 이해되지 않은 제품의 영역에 중점을 두어야 합니다 (Prototype should focus on areas of the product that are not well-understood):
  프로토타입은 주로 이해되지 않은 부분이나 불분명한 부분에 집중해야 합니다. 이를 통해 초기에 시스템의 복잡한 부분을 이해하고 문제를 해결할 수 있습니다.

• 오류 확인 및 복구는 프로토타입에 포함되지 않을 수 있습니다 (Error checking and recovery may not be included in the prototype):
  프로토타입은 오류 검사 및 복구와 같은 안정성 및 보안과 같은 비기능적 요구 사항보다는 기능적 요구 사항에 중점을 두는 경우가 많습니다.

• 기능적 요구 사항에 중점을 둬야 합니다 (Focus on functional rather than non-functional requirements such as reliability and security):
  프로토타입은 주로 기능적 요구 사항에 중점을 둡니다. 이는 시스템이 어떻게 동작해야 하는지에 대한 초기 이해를 돕기 때문입니다.

Throw-away prototypes

일회용 프로토타입은 다음과 같은 이유로 개발 후 버려져야 합니다:

• 비기능 요구사항을 충족하기 어려울 수 있습니다:
  일회용 프로토타입은 주로 주요 기능의 시연을 목적으로 개발되기 때문에 비기능적인 요구사항을 충족하기에는 한계가 있을 수 있습니다.

• 프로토타입은 일반적으로 문서화되지 않습니다:
  프로토타입은 주로 빠른 개발을 위해 빠르게 구축되기 때문에 문서화 과정이 무시되기 쉽습니다. 이는 프로토타입이 나중에 시스템으로 확장되거나 유지보수되기 어려울 수 있음을 의미합니다.

• 프로토타입의 구조는 빠른 변경으로 인해 점차 약화될 수 있습니다:
  프로토타입은 빠른 개발과 변경을 위해 설계되므로 시간이 지남에 따라 구조가 혼란스러워지고 유지보수가 어려워질 수 있습니다.

• 프로토타입은 일반적인 조직적 품질 기준을 충족하지 못할 수 있습니다:
  프로토타입은 빠른 개발을 위해 제한된 시간과 자원으로 개발되기 때문에 일반적인 조직적 품질 기준을 충족하지 못할 수 있습니다. 따라서 프로토타입은 본격적인 제품으로 사용하기에 적합하지 않을 수 있습니다.

Incremental delivery

• 점진적 전달(Incremental delivery)은 시스템을 단일 전달물로 제공하는 대신, 개발 및 전달을 요구되는 기능의 일부를 담은 증분으로 분할하는 방법입니다.

• 사용자 요구사항은 우선순위가 매겨지고, 가장 높은 우선순위의 요구사항이 초기 증분에 포함됩니다.

• 한 번 증분 개발이 시작되면 요구사항은 고정되지만, 후속 증분을 위한 요구사항은 계속 발전할 수 있습니다.

• 이는 애플리케이션, 웹, 플러그인 기반 응용 프로그램과 같은 다양한 형태의 소프트웨어에 적용될 수 있습니다.

Incremental development and delivery

• 점진적 개발(Incremental development):

  • 시스템을 증분 단위로 개발하고 각 증분을 평가한 후 다음 증분의 개발로 진행하는 프로세스입니다.

  • 대부분의 경우 애자일 방법론에서 사용되는 일반적인 접근 방식입니다.

  • 사용자/고객 대리인이 평가를 담당합니다.

• 점진적 전달 (Incremental delivery):

  • 증분을 최종 사용자에게 전달하는 것을 의미합니다.

  • 소프트웨어의 실제 사용에 대한 보다 현실적인 평가를 제공합니다.

  • 교체 시스템에 대해서는 기능이 더 적기 때문에 구현하기 어려울 수 있습니다.

Incremental delivery

Incremental delivery advantages

• 각 증분마다 고객 가치를 전달하여 시스템 기능이 더 빨리 사용 가능하다는 것입니다.

• 초기 증분은 후속 증분의 요구사항을 도출하는 데 도움이 되는 프로토타입 역할을 합니다.

• 전체 프로젝트 실패 위험이 줄어듭니다.

• 최우선 순위를 받은 시스템 서비스는 대부분의 테스트를 받게 됩니다.

Incremental delivery problems

점진적 전달이 교체할 목적으로 새로운 시스템을 도입할 때 문제가 발생할 수 있습니다. 이는 주로 두 가지 이유로 발생합니다.

• 기존 시스템에 대한 사용자의 선호도:

  • 사용자는 기존 시스템을 좋아하고, 새로운 시스템을 사용하기를 꺼립니다.
  • 새로운 시스템이 이전 시스템보다 더 효율적이거나 유용하더라도, 사용자들은 변경에 대한 저항감을 가질 수 있습니다. 이는 사용자들이 익숙한 환경을 떠나기를 꺼리는 자연스러운 반응입니다.

• 기본 시설의 부재:

  • 대부분의 시스템은 각 부분에서 사용되는 기본 시설이 필요합니다.
  • 요구 사항이 증분을 구현하기 직전까지 상세하게 정의되지 않기 때문에, 모든 증분에서 필요한 공통 시설을 식별하기가 어려울 수 있습니다.
  • 이로 인해 불확실성이 발생할 수 있습니다.

점진적 전달에서는 요구 사항이 점진적으로 발전하며 소프트웨어와 함께 명세가 개발됩니다. 이러한 접근 방식은 초기에 완벽한 명세와 전체적인 제품 전달을 요구하는 조직과 충돌할 수 있습니다. 이러한 조직은 증분적이고 조정 가능한 프로세스보다는 완전한 명세와 결과물을 선호할 수 있습니다. 이러한 요구 사항의 차이로 인해 조직과 개발 팀 간의 의사 소통과 협력이 어려워질 수 있습니다.

---

[Process improvement]

Process improvement

• 프로세스 개선은 소프트웨어 회사들이 소프트웨어의 품질을 향상시키고 비용을 줄이거나 개발 과정을 가속화하기 위한 방법으로 채택해왔습니다.

• 이는 기존 프로세스를 이해하고 제품 품질을 높이거나 비용과 개발 시간을 줄이기 위해 이러한 프로세스를 변경하는 것을 의미합니다.

Approaches to improvement

• 과정 성숙도 접근 방법(The process maturity apprach):

  • 이 접근 방법은 프로세스와 프로젝트 관리를 개선하고 좋은 소프트웨어 엔지니어링 관행을 도입하는 데 중점을 둡니다.

  • 과정 성숙도 수준은 조직의 소프트웨어 개발 프로세스에 좋은 기술적 및 관리적 관행이 채택된 정도를 반영합니다.

  • 이러한 방법은 ISO 15504와 같은 모델을 사용하여 조직의 프로세스를 측정하고 개선하는 데 도움이 될 수 있습니다.

• 민첩한 접근 방법(The agile approach):

  • 이 방법은 반복적인 개발과 소프트웨어 프로세스의 오버헤드를 줄이는 데 중점을 둡니다.

  • 민첩한 방법의 주요 특징은 기능의 신속한 제공과 변화하는 고객 요구에 대한 민첩한 대응입니다.

  • 이러한 방법은 스크럼, 익스트림 프로그래밍(XP), 칸반 등의 방법을 포함하며, 팀의 협력, 의사 소통, 소프트웨어의 지속적인 제공 등을 강조합니다.

이 두 가지 접근 방법은 각각 조직의 요구 사항과 성격에 따라 선택될 수 있습니다. 과정 성숙도 접근 방법은 전통적이고 구조화된 환경에서 더 적합할 수 있으며, 민첩한 접근 방법은 변화가 빈번하고 빠른 속도로 기능을 제공해야 하는 환경에서 더 적합할 수 있습니다.

The process improvement cycle

Process improvement activities

• 프로세스 측정(Process Measurement):
  소프트웨어 프로세스나 제품의 하나 이상의 속성을 측정합니다.
  이러한 측정값은 프로세스 개선이 효과적인지를 결정하는 데 도움이 되는 기준선을 형성합니다.

• 프로세스 분석(Process Analysis):
  현재 프로세스를 평가하고, 프로세스의 약점과 병목 현상을 식별합니다.
  프로세스를 설명하는 프로세스 모델(가끔 프로세스 맵이라고도 함)이 개발될 수 있습니다.

• 프로세스 변경(Process Change):
  식별된 프로세스의 약점을 해결하기 위해 프로세스 변경이 제안됩니다.
  이러한 변경 사항이 도입되고, 주기적으로 변경의 효과를 평가하기 위해 데이터를 수집하는 프로세스가 반복됩니다.