[소프트웨어공학] 2. Software Processes

본 포스팅은 광운대학교 이기훈 교수님의 소프트웨어공학 수업을 듣고 공부하며 정리한 노트입니다.

소프트웨어 프로세스란?

소프트웨어 시스템을 개발하는데 필요한 모든 작업들을 말합니다. 소프트웨어 프로세스는 Plan-driven 방식과 Agile 방식으로 분류할 수 있습니다.

• Plan-driven

모든 프로세스에 대한 계획을 미리 세워두고 계획에 따라 개발이 이루어지는 방식입니다.

• Agile processes

사용자의 요구 사항 변화를 지속적으로 반영하기 위하여 계획을 수정하면서 개발이 이루어지는 방식입니다.

소프트웨어 프로세스 모델

소프트웨어 프로세스 모델은 소프트웨어 프로세스의 추상적인 구성을 설명합니다. 프로세스 모델에는 폭포수 모델, incremental development, reuse-oriented development가 있습니다.

• 폭포수 모델(The waterfall model)

Plan-driven 모델입니다. 요구 사항 분석과 개발 단계를 구별하여 시스템 개발을 수행합니다. 폭포수 모델은 프로세스 진행 후 고객의 요구 사항 변경을 수용하기 어렵다는 문제점이 있습니다. 따라서 폭포수 모델은 펌웨어 제품 개발과 같이 요구 사항이 잘 정의되어있고 요구 사항 변경이 최소화된 경우에 사용하는 것이 좋습니다. 또한 폭포수 모델은 여러 기관이 분업하여 개발을 진행하는 대규모 프로젝트에 적용하면 각 기관들의 협업을 원활하게 이끌어 낼 수 있습니다.

• Incremental development

이전 버전에 기능을 추가하며 시스템을 발전시켜 나가면서 개발합니다. 신속한 피드백을 주고받으며 요구 사항 분석, 개발, 검증의 과정이 유동적으로 수행됩니다. Plan-driven과 agile일 수 있습니다. Plan-driven으로 개발할 때는 시스템을 발전시켜 나가는 단계를 미리 계획합니다. Agile로 개발할 때는 어느 정도 개발이 진행되면 진행 과정과 고객의 우선 순위에 맞춰 프로세스가 진행됩니다. 폭포수 모델보다 고객의 요구 사항을 분석하고 명세화하는 비용이 절감됩니다. 또한 폭포수 모델보다 고객이 진행 상황을 보고 피드백을 제공하는 것이 쉽습니다. 그리고 폭포수 모델보다 빠르게 제품을 받아서 사용할 수 있습니다.

그러나 프로세스가 보이지 않는다는 단점이 있습니다. 프로세스를 보기 위하여 별도의 과정이 필요합니다. 버전 업그레이드마다 서류화를 하지 않는 것이 개발 속도를 높이기에 낫습니다. 새로운 기능을 추가할수록 시스템의 전체 구조는 복잡해집니다. 따라서 시간과 돈을 들여서라도 전체 구조를 재점검하는 것이 좋습니다.

• Reuse-oriented development

이미 존재하는 시스템 구성 요소들을 결합하여 하나의 전체 시스템을 구성합니다. Plan-driven과 agile일 수 있습니다. 적은 비용과 위험으로 개발할 수 있고 고객에게 빠르게 시스템을 전달할 수 있습니다.

그러나 고객의 요구 사항을 맞추기 위한 협상은 필수적입니다. 또한 재사용된 구성 요소들의 유지 관리가 더 이상 되지 않습니다.

각 프로세스 작업에 대한 설명

• 소프트웨어 요구 사항 분석(Software Specification)

시스템 이해관계자들이 무엇을 요구하는지 분석하고 세부적인 내용들을 정의합니다. 그리고 정의한 요구 사항을 검증하는 과정입니다.

• 소프트웨어 디자인(Software Design and Implementation)

정의한 요구 사항을 바탕으로 실행 가능한 시스템의 전체 구조를 설계하고 주요 모듈, 하위 시스템과 관계를 정의합니다. 또한 시스템 데이터 구조를 디자인하고 데이터베이스를 설계합니다. 그리고 시스템 구성 요소들 간의 인터페이스를 디자인합니다. 활용할 수 있는 기존 요소들이 있는지 찾아봅니다.

• 소프트웨어 검증(Software Validation)

Verification and validation(V & V) 테스트 기법을 통해 시스템이 고객의 요구 사항을 수행하는지 검증합니다. 시스템에 실제 적용될 데이터를 시험 케이스로 사용하여 테스트합니다. 테스트는 구성 요소 검사, 시스템 검사, 그리고 인수 검사 순서로 진행합니다.

구성 요소는 개별으로 테스트를 진행합니다. 여기서 구성 요소는 함수, 객체 등이 있습니다. 시스템 검사는 전체 시스템을 검사하는 과정입니다. 새롭게 추가된 기능을 테스트하는 것이 특히 중요합니다. 인수 검사를 통해 고객의 데이터를 통해 검사를 진행하며 시스템이 고객의 요구 사항을 만족시키는지 확인합니다.

Plan-driven 방식으로 소프트웨어를 개발할 때는 프로세스의 각 단계를 진행할 때마다 테스트 계획을 미리 세워서 소프트웨어 검증 시 활용합니다.

• 소프트웨어 유지 관리(Software Evolution)

비즈니스 환경이 바뀜에 따른 고객 요구 사항의 변화에 맞춰 소프트웨어를 수정합니다. 요구 사항의 변화에 맞춰 수정을 해줘야 비로소 다시 사용 가능한 소프트웨어가 됩니다.

재작업하는 비용을 어떻게 줄일 것인가?

대규모 소프트웨어 프로젝트를 수행할 때 수정은 불가피합니다. 따라서 프로세스는 수정이 불가피하다는 것을 인지하고 있어야 합니다. 단, 수정을 하려면 요구 사항을 다시 분석하고 재개발을 해야하기 때문에 비용이 많이 듭니다.

• 수정의 가능성 따지기(Change anticipation)

중요한 재작업 이전에 수정의 가능성을 따져보는 과정을 포함시킵니다. 예를 들어, 시스템을 프로토타이핑을 통해 고객들에게 몇 중요 특징들을 보여줍니다.

• 수정에 유연하게 대처할 수 있는 설계(Change tolerance)

낮은 가격으로 수정에 대처할 수 있도록 설계합니다. 일반적으로 점진적인 발전 개발의 형태를 말합니다. 제안된 수정은 아직 개발하기 시작하기 전의 발전 과정에서 수행됩니다. 만약 수정이 불가능하다면 하나의 단계만 수정될 수도 있습니다.

고객의 요구 사항 변화에 어떻게 대처할 것인가?

• 시스템 프로토타입 제작(System prototyping)

시스템의 프로토타입을 제작하여 고객의 요구 사항을 맞췄는지 확인하고 디자인을 검토합니다. 이 과정을 통해 추후 수정 여부를 따져볼 수 있습니다(change anticipation). 프로토타입은 시스템의 디자인 세부사항과 컨셉을 시연할 수 있는 초기 버전입니다. 프로토타입은 요구 사항 분석 단계와 UI 디자인에서 활용할 수 있습니다.

프로토타입을 제작하면 시스템 사용성을 높일 수 있고 고객의 요구 사항을 최대한 맞출 수 있습니다. 또한 디자인이 향상되고 유지성이 높아집니다. 그리고 개발에 드는 노력이 비교적 줄어듭니다.

프로토타입 제작 계획을 세우고 프로토타입에 들어갈 기능을 정합니다. 프로토타입을 정한 뒤 테스트를 합니다. 프로토타입은 이해하기 어려운 영역을 이해시킬 수 있고 기능적인 것을 보여주는데 목적이 있습니다.

프로토타입은 수행 후 처분해야 합니다. 프로토타입이 제품의 기초가 되기에는 부적합하기 때문입니다. 또한 프로토타입은 일반적으로 서류화하지 않습니다. 보통 구조적인 퀄리티의 기준을 만족하지 못합니다.

• 발전된 버전의 시스템 점검(Incremental delivery)

고객에게 각 단계마다 고객의 피드백이 전달됩니다. 시스템 기능이 더 빨리 가능해지도록 합니다. 또한 수정을 최소화할 수 있고 추후 수정이 필요할 때 유연하게 대처할 수 있습니다. 시스템 향상에 대한 내용은 기능별로 정리하여 고객에게 보여줍니다. 후에 고객의 요구 사항에 대한 우선순위를 따져 작업합니다. 하지만 모든 단계에 통용되는 기능을 정하기 힙듭니다.

프로세스 개선 방법론

기존 프로세스 분석을 통해 제품의 질과 개발 시간, 개발 비용을 줄이기 위한 프로세스 수정 방안을 찾습니다.

• Process maturity approach

프로세스의 성숙도를 높이는데 집중합니다. 프로세스 성숙도 수준은 조직화된 소프트웨어 개발 프로세스에서 우수한 기술 및 관리 관행이 채택된 정도를 반영합니다. 능력 성숙도 모델(CMM)은 소프트웨어 개발 업체들의 업무능력평가 기준을 세우기 위한 평가 모형을 말합니다. 소프트웨어 개발 능력 측정 기준과 소프트웨어 개발 조직의 성숙도 수준을 평가합니다. 이후 CMM은 능력 성숙도 통합 모델(CMMI)로 발전했습니다.

• Agile approach

반복적인 개발과 소프트웨어 프로세스 오버헤드를 줄이는데 집중합니다.