7 분 소요



소프트웨어 프로세스

소프트웨어 프로세스는 소프트웨어 시스템을 제품화하기 위한 일련의 활동들의 집합이다. 다양한 종류의 소프트웨어 시스템이 있고 이 모든 시스템에 보편적으로 적용할 수 있는 소프트웨어 공학 기법은 존재하지 않는다. 하지만 모든 프로세스는 어떤 형태로든 다음 네 가지 공학 활동을 포함하게 된다. 소프트웨어 프로세스 모델은 프로세스의 추상적 표현이다.

  1. 소프트웨어 명세화
    • 소프트웨어의 기능과 소프트웨어 운영상의 제약조건을 정의해야 한다.

  2. 소프트웨어 개발
    • 명세를 만족하는 소프트웨어를 만들어야 한다.

  3. 소프트웨어 검증
    • 소프트웨어가 고객이 원하는 것과 일치하는지를 검증해야 한다.

  4. 소프트웨어 진화
    • 소프트웨어는 변화하는 고객의 요구를 충족시키기 위해 진화해야 한다.


소프트웨어 프로세스 설명


우리가 보통 프로세스라고 말할 때는 주로 데이터 모델 명세와 사용자 인터페이스 설계와 같이 프로세스 상의 활동과 이 활동들의 순서를 의미한다. 프로세스를 설명할 때는 누가 참여하는지, 무엇을 만드는지와 일련의 활동에 영향을 주는 조건들이 중요하다.

  1. 제품과 산출물 : 프로세스 활동의 결과물이다.

  2. 역할(role) : 프로세스에 참여하는 사람들의 책임을 나타낸다.

  3. 사전/사후 조건 : 프로세스 활동이 이루어지거나 제품이 만들어지는 전과 후에 만족해야 하는 조건들이다.


Plan-driven과 agile processes

Plan-driven(계획기반) process

  • 안전성 중심 시스템에서는 상세한 기록관리가 이루어질 수 있는 매우 구조적인 개발 프로세스가 필요하다.

Agile process

  • 빨리 변화하는 요구사항을 다루어야 하는 비즈니스 시스템에서는 더 유연한 애자일 프로세스가 더 적합하다.




소프트웨어 프로세스 모델

일반적인 프로세스 모델


  1. 폭포수 모델
    • 이 모델은 명세화, 개발, 검증과 진화를 기본적인 프로세스활동으로 가지며 요구사항과 명세화, 소프트웨어 설계, 구현 및 데스팅과 같은 개별적인 프로세스 단계로 프로세스 모델을 나타낸다.

  2. 점증적 개발
    • 이 접근법에서는 명세화, 개발 및 검증 활동이 서로 중첩된다. 연속적인 버전을 통해 시스템을 개발하며, 각각의 버전은 이전 버전에 기능을 추가하게 된다.

  3. 통합 및 환경 설정
    • 재사용 가능한 컴포넌트나 시스템의 사용가능 여부에 의존하는 접근법으로 시스템 개발 프로세스는 새로운 설정에 사용할 컴포넌트들을 조합하고 하나의 시스템으로 통합하는 데 초점을 맞춘다.


Waterfall model(폭포수 모델)


폭포수 모델의 단계는 기본적인 소프트웨어 개발 활동을 직접적으로 반영한다.

  1. 요구 사항 분석 및 정의
    • 시스템 사용자와의 면담을 통해 시스템의 서비스, 제약 조건과 목표를 설정한다. 설정한 내용은 더 구체화시킨 후 시스템 명세서로 사용한다.

  2. 시스템 / 소프트웨어 설계
    • 시스템 설계 프로세스를 통해 요구사항을 하드웨어와 소프트웨어 시스템으로 나누어 할당하고, 전체 시스템 아키텍처를 작성한다.

  3. 구현 및 단위 테스트
    • 소프트웨어 설계는 프로그램 단위로 실체화한다. 단위 테스팅은 각각의 단위가 주어진 명세를 만족하는지를 검증하는 활동이다.

  4. 통합 및 시스템 테스트
    • 소프트웨어 요구사항을 만족하는지를 보증하기 위해 전체 시스템을 검사한다. 테스트 후에는 소프트웨어 시스템을 고객에게 전달한다.

  5. 운영 및 유지 보수
    • 이 활동이 가장 긴 생명 주기 단계이다. 시스템이 설치되고 사용된다. 오류를 수정하고 구현을 개선하고 새로운 요구사항을 발견함으로써 시스템 서비스를 향상시키는 것을 포함한다.


Waterfall model(폭포수 모델)의 문제점


  1. 프로젝트를 개별 단계로 유연하지 않게 분할하면 변화하는 고객 요구 사항에 대응하기 어렵다.따라서 이 모델은 요구 사항을 잘 이해하고 설계 프로세스 중에 변경이 상당히 제한되는 경우에만 적합하다. 안정적인 요구 사항을 가진 비즈니스 시스템은 거의 없다.

  2. 폭포수 모델은 시스템이 여러 사이트에서 개발되는 대규모 시스템 엔지니어링 프로젝트에 주로 사용된다. 이러한 상황에서 폭포수 모델의 계획중심(plan-driven) 특성은 작업을 조정하는 데 도움이 된다.


Incremental development(점증적 개발)


점진적 개발의 아이디어는 초기 구현을 개발하고, 사용자와 다른 사람들로부터 피드백을 받아서, 여러 버전을 거쳐 소프트웨어를 진화시킴으로써 요구한 최종 시스템을 개발하는 것이다. 점증적 개발은 폭포수 모델에 비해 다음의 세 가지 중요한 장점을 가진다.

  1. 요구사항 변경을 구현하는 비용이 줄어든다.

  2. 이미 진행된 개발 작업에 대해서는 고객의 피드백을 받기가 더 쉽다.(고객은 문서만으로는 진척사항을 파악하기 힘들다.)

  3. 비록 전체 기능을 제공하지 못하더라도 고객에게 유용한 소프트웨어를 빠르게 전달하고 배포하는 것이 가능하다.(고객은 폭포수 모델보다 더 일찍 사용해볼 수 있다.)


Incremental development(점증적 개발) 문제점


  1. 프로세스가 가시적이지 못하다
    • 관리자는 진척도를 확인하기 위해 정기적으로 중간 산출물이 필요하다. 만약 시스템이 빨리 개발되어야 한다면, 시스템의 모든 버전을 반영한 문서를 작성하는 것은 비용 측면에서 효율적이지 않다.

  2. 새로운 증가분이 반영되면서 시스템 구조를 훼손시키는 경향이 있다.
    • 정기적인 변경 때문에 새로운 기능이 추가되면서 코드를 망치게 된다. 애자일 방법에 의하면 품질 저하와 코드 망가짐을 방지하기 위해 정기적인 리팩토링(refactoring)이 필요하다.


통합 및 환경설정


대부분의 소프트웨어 프로젝트의 경우, 일부라도 소프트웨어를 재사용하게 된다. 즉, 재사용할 수 있는 코드를 찾고, 요구에 맞추어 수정한 후 이미 개발한 새로운 코드와 통합을 한다. 재사용 중심 방법론은 재사용 가능한 소프트웨어 컴포넌트와 이 컴포넌트를 조합하기 위한 통합 프레임 워크에 기반을 두고 있다. 다음은 세 가지 유형의 소프트웨어 컴포넌트가 널리 사용된다.

  1. 특정 환경에서 사용할 수 있도록 설정된 독립형 애플리케이션 시스템
    • 이 시스템은 범용 목적 시스템으로 다양한 특성을 가지고 있지만 특정 애플리케이션에서 사용할 수 있도록 맞춤 작업을 해야 한다.

  2. 컴포넌트 프레임워크에 통합할 수 있도록 개발한 컴포넌트나 패키지 객체들의 모음

  3. 서비스 표준에 따라 개발하고, 인터넷을 통해 원격 실행이 가능한 웹 서비스

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



통합 및 환경설정에 기반한 재사용 중심 프로세스의 각 단계


  1. 요구사항 명세화
    • 시스템에 대한 초기 요구사항을 제안한다.

  2. 소프트웨어 발견 및 평가
    • 필요한 기능을 제공하는 컴포넌트 및 시스템을 찾고 요구사항을 만족하는지 평가한다.

  3. 요구사항 정제
    • 기존의 재사용 가능한 컴포넌트와 애플리케이션의 정보를 활용해 요구사항을 다듬는다.

  4. 애플리케이션 시스템 설정
    • 요구사항을 만족하는 COTS 애플리케이션 시스템을 확보한다면 이 시스템을 설정해 새로운 시스템을 만드는 데 사용할 수 있다.

  5. 컴포넌트 수정과 통함
    • 만약 적당한 COTS가 없으면 개별적으로 컴포넌트를 수정해 새로운 컴포넌트를 개발해 시스탬 개발에 통합시킬 수 있다.


통합 및 환경설정에 기반한 재사용 중심 소프트웨어 공학의 장단점


  • 처음부터 개발되는 소프트웨어가 적어 비용 및 위험 감소

  • 더 빠른 시스템 제공 및 배포

  • 요구 사항 타협은 불가피하므로 시스템이 사용자의 실제 요구 사항을 충족하지 못할 수 있음

  • 새로운 버전의 재사용 컴포넌트에 대한 통제권을 개발직이 가지지 못하기 때문에 시스템 진화에 대한 주도권 상실



프로세스 활동

실제 소프트웨어 프로세스는 소프트웨어 시스템을 명세하고, 설계하고, 구현하고, 테스팅하기 위한 전반적 목표를 가지고 기술적이고 관리적인 측면을 가진 공동의 활동들이 서로 중첩되어(inter-leaved sequences) 진행된다.

명세화, 개발, 검증과 진화라는 네 가지 기본 프로세스 활동은 다른 개발 프로세스상에서 서로 다른 방식으로 구성된다.

inter-leaved sequences 예시

요구 공학 프로세스



소프트웨어 명세화

소프트웨어 명세화 또는 요구공학은 시스템을 개발하기 위해 어떤 서비스가 필요한지를 이해하고 정의하며, 시스템의 운영과 개발에 대한 제약사항을 찾아내는 프로세스에 해당한다.

요구공학 프로세스에는 다음의 세 가지 주요 활동이 있다.

  1. 요구사항 도출과 분석

  2. 요구사항 명세화

  3. 요구사항 검증



소프트웨어 설계 및 구현

소프트웨어 개발에서의 구현 단계는 실행가능한 시스템을 개발하는 프로세스다.

소프트웨어 설계

소프트웨어 설계는 구현해야 하는 소프트웨어의 구조, 시스템이 사용하는 데이터 모델과 구조, 시스템 컴포넌트들 사이의 인터페이스와 경우에 따라서는 사용하는 알고리즘을 기술한 것이다.

설계 프로세스의 일반적인 모델

위 그림은 정보 시스템을 설계하기 위한 일부 프로세스에서의 네 가지 활동이다.

  1. 아키텍처 설계 : 시스템의 전반적인 구조, 주요 컴포넌트와 그 관계를 찾고, 이러한 구성요소들이 어떠한 방식으로 분산될지를 알아낸다.

  2. 데이터 베이스 설계 : 시스템 데이터 구조를 설계하고 데이터 베이스에서 어떻게 표현할지를 결정한다.

  3. 인터페이스 설계 : 시스템 컴포넌트 사이의 인터페이스를 정의한다.

  4. 컴포넌트 선택 및 설계 : 재사용할 컴포넌트를 찾고, 없다면 새로운 소프트웨어 컴포넌트를 설계한다.


시스템 구현

  1. 설계 및 구현은 대부분의 소프트웨어 시스템 유형에 대한 인터리브 활동이다.

  2. 프로그래밍은 표준 프로세스가 없는 개발 활동이다.

  3. 디버깅은 프로그램 오류를 찾아 이러한 오류를 수정하는 활동이다.

소프트웨어 검증

소프트웨어 검증, 일반적으로 검증 및 확인은 시스템이 주어진 명세를 잘 따르고 있는 것과 시스템 고객이 원하는 것을 그대로 반영하고 있다는 것을 보이기 위한 것이다.

이는 확인 및 검토 프로세스와 시스템 테스트가 포함된다. 시스템 테스트에는 시스템에서 처리할 실제 데이터의 명세에서 파생된 테스트 사례로 시스템을 실행하는 작업이 포함된다.

시스템 테스팅 단계

  1. 컴포넌트 테스팅 : 시스템 개발자가 시스템을 구성하는 컴포넌트를 테스트한다.

  2. 시스템 테스팅 : 시스템 컴포넌트를 통합해 완전한 시스템을 구성한다.

  3. 고객 테스팅 : 최종단계로 고객이 직접 시스템을 테스트하게 된다.

계획기반 테스팅 단계



소프트웨어 진화

소프트웨어는 본질적으로 유연하고 변경될 수 있다.

요구사항이 변경됨에 따라 비즈니스를 지원하는 소프트웨어도 진화하고 변겨오디어야 한다.

변경처리(coping with change)

모든 대규모 소프트웨어 프로젝트에서 변경은 불가피하다. 변경은 재작업으로 이어지므로 변경 비용에는 재작업과 새로운 기능 구현 비요이 모두 포함된다.

재작업 비용 절감

다음은 재작업 비용을 줄이기 위해 사용할 수 있는 두 가지 접근법이다.

  1. 변경 예측
    • 시스템의 주요 특성을 고객에게 보여주기 위해 프로토타입 시스템을 개발하는 것을 예로 들 수 있다. 따라서 요구사항을 개선할 수 있다.
  2. 변경 허용
    • 시스템을 쉽게 변경할 수 있도록 프로세스와 소프트웨어를 설계한다.

프로토타이핑

프로토타입은 제품의 아이디어를 시연하고 디자인 선택 사항들을 시도해 보고, 문제점과 가능한 해결책을 찾아내기 위해 사용하는 소프트웨어 시스템의 초기 버전이다.

빠른 프로토타이핑은 언어 또는 도구를 기반으로 할 수 있다.

  • 프로토타입은 잘 이해되지 않는 제품 영역에 초점을 맞춰야 한다.
  • 오류 검사 및 복구는 프로토타입에 포함되지 않을 수 있다.
  • 안정성 및 보안과 같은 비기능적 요구 사항보다 기능적 요구 사항에 중점을 둔다.

프로토타입의 장단점

시스템 사용성이 향상, 디자인 품질 및 유지 보수성 향상, 개발노력 감소 등 웬만한건 다 장점이다. 단점으로는 프로토타입은 버려지며 문서화되지 않는다.

변화수용

변화수용은 일반적으로 점증적 인도를 할 때 사용된다.


점증적 인도

점증적 인도는 어떤 서비스가 중요하고 별로 중요하지 않은지를 정해 시스템의 기능 일부분을 제공하는 각 증가분 몇 개를 모아 전달할 증가분으로 정한다. 그 후 서비스 우선순위에 따라 증가분에 할당할 서비스를 결정한다. 가장 중요한 서비스를 먼저 구현하고 전달하는 방법이다.

  1. 사용자 요구사항이 우선시된다.

  2. 우선 순위가 가장 높은 요구 사항은 초기 증분에 포함된다.

  3. 증분 개발이 시작되면 이후 증분에 대한 요구 사항이 계속 발전할 수 있지만 요구 사항은 동결된다.

증분 개발의 특징

  1. 시스템 기능을 더 일찍 사용가능
  2. 초기증분은 이후 증분에 대한 요구사항을 도출하는데 도움이 되는 프로토타입 역할을 한다.
  3. 가장 중요한 시스템 서비스는 가장 많은 테스트를 받는다. 단점
  4. 사용자에게는 이전 시스템의 모든 기능이 필요하다.
  5. 모든 증가분이 필요로 하는 공통 기능을 찾기가 어렵다.
  6. 최종 증분이 지정될 때까지 완전한 시스템 명세가 없다.

프로세스 개선

프로세스 개선은 소프트웨어 품질을 향상시키고 비용을 줄이거나 개발 프로세스를 가속화한다.

프로세스 개선은 기존 프로세스를* 이해하고 이러한 프로세스를 변경하는 것*을 의미한다.

개선에 대한 접근


  1. 프로세스 성숙도 접근법
    • 프로세스와 프로젝트 관리 기법을 개선하는 것과 바람직한 소프트웨어 공학 실무를 조직에 소개하는 것에 중점을 둔다.
    • 프로세스 성숙도 접근법을 따르는 일반적인 프로세스 개선 방식은 프로세스 측정, 프로세스 분석, 프로세스 변경 다시 프로세스 측정순으로 진행된다.

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

댓글남기기

참고