[SW 공학] 프로세스와 프로세스 모델

프로세스와 프로세스 모델

프로세스 관리의 목표는 비용과 기간.

• 컴퓨터를 이용하는 모든 이유는 문제해결
• 어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업으로 구성된 것이 프로세스
• 즉 개발하는 과정, 순서를 말한다.
• 높은 품질과 생산성을 위한 프로세스.

프로세스가 없는 개발은 즉흥적 개발로 비생산적 개발.

요구 분석을 하지 않아 생기는 비효율, 즉흥으로 부실한 아키텍처, 계획이 없으니 잘했는지 비교대상도, 비용과 일정예측도 없다.

• 프로세스는 무엇을하는가 방법론은 그것을 어떻게하는가.
• 소프트웨어 프로세스는 기술적 관리적으로 수행되는 작업의 단계이며 각 단계의 결과물은 다음 단계의 입력이 된다.
• 그리고 이는 소프트웨어 프로젝트에 적용이 된다.
• 프로젝트는 프로세스를 이용해 비용, 일정, 품질에 대한 목표를 성취해야한다.

프로세스 명세 : 프로젝트에서 수행해야하는 작업과 이들의 수행 순서를 정의

프로세스 모델 : 일반적인 프로세스를 기술한 것. 작업의 단계와 순서, 각 단계 작업 수행의 제약사항이나 조건 등을 모아 놓은 것.

바람직한 프로세스의 특징

4가지는 trade-off 관계에 있다고도 볼 수 있다(4가지 다 갖추기 힘듦)

1. 예측가능성

   비용, 품질, 기간을 제어하려면 과거 경험을 바탕으로 예측 가능한 프로세스를 사용하면 된다.

2. 테스팅과 유지 보수 지원

   유지보수 비용 > 개발비용

   임을 고려한 프로세스

3. 변경 지원

   요구분석 이후 요구사항 변경이 되었을 때 쉽게 반영이 된느 프로세스.

4. 결함 제거

   결함이 늦게 발견되면 늦을수록 수정비용이 커진다. 때문에 품질 측정을 통해 결함을 찾아내야 한다.

---

'개발 프로세스'의 모델

목표와 필요에 맞게 커스터마이징하기 위해 모델을 공부한다.(카피가 답이 아님)

• 폭포수 모델
• 프로토타이핑 모델
• 점증적 모델
• V모델
• 일정 중심 설계 모델
• 애자일 모델

1. 폭포수 모델


• 위에서 아래로 물이 흐르는 듯한 모양.

• 계획, 요구 분석, 설계, 구현, 시험, 인수/설치

• 각 단계가 끝나야 다음 단계가 시작됨.(중복, 상호작용 x)

• 만족되지 않으면 전 단계로 돌아가 다시 수행.

• 순차적이라 직능중심의 프로젝트 조직화가 가능.(요구분석팀, 구현팀 등등 ..)

• 단순하거나 응용 분야를 잘 알고있는 경우 적합(요구사항이 명확하고 변경이 거의 없는 경우)

• 단순해서 비전문가도 개발과정을 이해하기 쉽다.

• 크고 복잡한 오래 지속되는 프로젝트에 적합(공장 제어 시스템, 우편물 정리 분류)

단점

• 설계와 코딩 및 테스팅이 지연될 가능성이 있다.(초기 단계들이 지나치게 강조되어 불필요한 문서작성의 가능성)
• 요구 변경을 수용하기 어려움(구현단계로 넘어갔다면 특히)
• 개발 기간동안 환경이나 표준이 바뀌면서 요구가 바뀌는 분야라면 폭포수모델로는 힘듦.
• 프로토타입이 없으므로 최종 결과가 나오기 전까지는 어떤 결과물이 나올지 알 수 없음.
• 때문에 중간에 프로젝트가 취소되면 손실이 큼.
• 각 단계가 끝난 후 나오는 결과물에 대한 명확한 정의가 필요함.(어중간해서 추후 수정하는 일 없도록)

2. 프로토타이핑 모델


• 요구분석 단계에서 비전문가 입장으로 입력, 출려게에 대해 정확히 요구하기 어렵다. 또 이 프로젝트의 실현 가능성에대해 확신하기 힘들다. 그런경우 프로토타이핑 모델을 채택해 프로젝트의 실현가능성을 체크하고 정확한 요구사항을 제시할 수 있다.
• 요구된 소프트웨어의 일부를 보여주기 위한 프로토 타이핑 도구(화면 생성기, 비주얼 프로그래밍, 4세대 언어)
• 폭포수 모델의 단점인 사용자와 개발자 간의 의사소통을 돕는 모델.(설계이전 요구를 이해시키고 동결해 요구 변경을 막음)
• 개발 착수시점에 요구가 불투명할 때, 실험적으로 실현 가능성을 타진해 보고 싶을 때, 혁신적인 기술을 사용해 보고 싶을 때쓰는 모델
• 대규모 자본 투입 전 실현 가능성을 보기 위해 쓰임

단점

• 프로토타입이 최종결과라고 믿어 곧 개발이 완료 될 것이라 생각하는 부작용.
• 오해와 기대심리로 인해 생기는 기간 단축 요구와 그로 인한 소프트웨어 품질 저하.
• 요구사항 과다의 위험과 중간 산출물 정의가 난해해 중간 과정 관리가 어렵다.

종류

• evolutionary : 프로토타입 바탕 피드백을 받아 수정하는 방식
  • 개발기간이 긴 것을 허용하지 않는 최근 요구에 알맞은 모델
  • 릴리즈 구성방법은 두가지
    • 시스템의 일부를 경험하게 하고 점증적(increments)으로 개발(기능별 릴리스) 릴리스의 반복을 통해 시스템이 완전구현 될 때까지 설계 조정, 확장 등 유용한 피드백을 이용할 수 있다.
    • 반복적 개발(iterative) : 처음부터 시스템 전체 기능을 대상으로 릴리스 한느 것으로 릴리스마다 기능을 향상시키는 개발.
  • 두가지 구성방법을 병행해 릴리스를 반복함.
  • 장점
    • 기능이 부족하더라도 초기에 사용 교육 가능, 부족한 부분 피드백 반영
    • 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음.
    • 자주 릴리스 하면 가동중인 시스템에서 일어나는 예상하지 못했던 문제를 꾸준히 고쳐나갈 수 있음. (유지보수)
    • 개발 팀이 릴리스마다 다른 전문영역에 초점을 둘 수 있음.
  • 하지만 일정이 정확하게 예측되어야하는 프로젝트에는 적합하지 않다.
• throwaway : 요구분석만을 위해 이해되지 않는 요구사항을 바탕으로 프로토 타입을 만들고 버리는 방식.

3. 나선형 모델


• 소프트웨어의 기능을 나누어 점증적으로 개발. + 위험분석
• 실패 위험을 줄이고 피드백, 테스트에 용이한 모델
• 절차
  • 계획 수립(planning): 목표, 기능 선택, 제약 조건의 결정
  • 위험 분석(risk analysis): 기능 선택의 우선순위, 위험요소의 분석
  • 개발(engineering): 선택된 기능의 개발
  • 평가(evaluation): 개발 결과의 평가
• 위험 요소가 많은 프로젝트에 어울리는 모델
• 변수가 많은 대규모 시스템
• 성능, 기술 문제로 실패할 가능성이 있는 시스템
• 재정적이나 기술적 위험부담이 큰 경우
• 요구사항이나 아키텍처 이해가 어려운 경우.
• 비선형적이며 반복적인 개발로 품질중 '강인성'을 높일 수 있는 모델이며 요구사항을 사이클마다 반영함
• 단점
  • 위험분석 자체가 비용이 많이 드는 작업. 위험분석의 방식에 따라 프로젝트의 성패가 달려있음

4. V 모델


• 폭포수 모델에서 시스템 검증과 테스트 작업을 강조한 모델
• 검증이라 써있는 부분은 테스트 단계에서 오류가 생겼을 시 돌아갈 단계를 이어 놓은 것.
• 장점
  • 모든 단계에 검증과 확인이 있어 오류를 줄일 수 있다.
  • 때문에 신뢰도가 높고 높은 신뢰도를 요구하는 프로젝트(의료산업, 원전제어)에 적합한 모델이다.
• 단점
  • 작업이 끝나버리면 변경이 쉽지 않다.
  • 때문에 요구ㅁ여세가 아주 상세하고 확실해서 개발 기간동안 변경이 필요없는 경우에나 적합하다.

5. Unified 프로세스


• 여러 사이클(iterations)로 구성 되어 있다

• 4단계로 구성

  • 도입(inception)

    • 1, 2회 정도 반복으로 간단한 유스케이스 모델과 소프트웨어 구조, 프로젝트 계획을 작성한다.

      (유스케이스란 어떤 시스템이 개발될 것인지 나타내기 위한 비즈니스 프로세스 모델링)

      (ex. 현금 인출기를 위한 유스케이스 : 입금, 출금, 잔액조회)

  • 정련(elaboration)

    • 여러 번의 반복 과정
    • 대부분의 유스케이스를 작성
    • 아키텍처 설계(UML 다이어그램)

  • 구축(consstruction)

    • 남아있는 유스케이스에 대하여 구현하고 통합.
    • 시스템을 목표 환경에 점증적으로 설치

  • 전환(transition)

    • 시스템을 배치, 사용자를 교육
    • 베타 테스팅, 결함 수정, 기능 개선

• 유스 케이스를 식별하여 시스템 개발에 활용하는것이 특징(유스케이스 중심 프로세스)

• 아키텍쳐를 개발 초기에 확정하고 개발의 가이드로 활용하기도함(아키텍쳐 중심의 프로세스)

• 반복과정을 통해 개발하는 것이 진화적 모델과 유사하지만 release하지 않는다는 차이점이 있음.

• 장점

  • 방법론과 프로세스가 잘 문서화 되어 있어 교육받기 좋다
  • 고객의 요구 변경과 관련된 리스크를 적극적으로 해결한다
  • 통합을 위한 노력과 시간을 줄일 수 있다.
  • 쉽고 빠르게 코드를 재사용 할 수 있다.

• 단점

  • 프로세스가 너무 복잡, 이해하기 어렵고 정확히 적용하기 어렵다.
  • 소프트웨어 프로젝트 참여자들의 협동, 의사소통에 대한 가이드가 없다.

6. 애자일(agile) 프로세스

• 폭포수 프로세스의 단점(요구사항 변경 리스크가 큰 것)을 해결한 모델

• 팀워크, 사용자와 협력개발, 변경을 위한 설계, 짧은 개발 사이클(2~6주)

• 4가지 철학

  1. 절차와 도구보다 개인과 소통을 중요시

     • 계획 위주의 절차가 프로젝트의 성공이 아님
     • 프로세스에 의하여 소프트웨어 품질이 좌우 되는 것이 아니라 팀워크와 팀원의 능력이 더 중요

  2. 문서보다 실행되는 소프트웨어에 더 가치를 둔다.

     • 기존 분석과 설계 문서를 준비하는데 많은 시간을 쏟아옴.
     • 하지만 경험적으로 설계를 아무리 잘해도 실제 구현은 해봐야 알 수 있기 때문에 소프트웨어가 더 실질적임.

  3. 계약 절충보다는 고객 협력이 중요하다.

     • 고객의 요구를 분석하고 그것의 절충하는 과정을 제외한 고객과의 소통은 없었다.
     • 하지만 에자일은 고객과 함께 의견을 교환하고 상호 이해하는 것이 프로젝트의 실패율을 줄인다고 본다.

  4. 계획을 따라 하는 것보다 변경에 잘 대응하는게 중요하다.

     • 프로세스는 변경을 제어한다. 변경은 비용을 초래하기 때문이다
     • 하지만 이제는 변경 요구가 변하는 것이 당연해졌고 변경 요구에 대한 대응이 성패를 가르는 요소가 됐다.
     • 따라서 계획 중심의 프로세스는 최근 흐름과 맞지 않기에 애자일 프로세스가 등장했다.

• 유스케이스, 사용자 스토리, feature단위, TDD(테스트 중심 개발)의 방향성

• 익스트림 프로그래밍

  • 사용자 스토리, 모듈 개발
  • 매일 빌드와 통합, 모듈 통합
  • 테스트 주도 개발(Test-Driven Development)
  • 페어 프로그래밍 (pair) 한사람은 개발, 다른 한사람은 테스팅.


'지원 프로세스'(umbrella)의 모델

• 프로젝트 관리 프로세스
• 형상 관리 프로세스
• 품질 관리 프로세스
• 프로세스 관리 프로세스

1. 관리 프로세스


• 비용을 낮추고 품질을 높이는 등 프로젝트 관리에 필요한 모든 작업(모니터링, 자원 할당 등)

• 관리 프로세스의 3단계

  • 계획 : 비용, 일정예측, 중간점검에 대한 결정으로 모니터링 및 제어 작업 기준을 결정
  • 모니터링 및 제어 : 개발 프로세스 모든 단계에서 수행됨
  • 분석

2. 품질 보증 프로세스

• 프로세스와 프로덕트 자체의 품질을 관리하고 향상시키는 작업.
• 개발과정이 올바로 되어있는지 확인하고 개선하는 작업
• 개발 프로세스 모델을 구축할 때 각 단계마다 관리 프로세스를 위한 정보를 생성하도록 정의해야 한다.
  • 인스펙션 프로세스
    • 개발 결과에서 결함을 찾거나 결함을 방지하기 위함
    • 정의 된 프로세스에 따라 작업 결과를 확인하고 검사
    • 초기에 결함을 찾아 비용을 절감하고 생산성을 높히기 위함.
  • 
    • 참여자가 단계마다 다른게 특징
  • 프로세스 관리 프로세스
    • 개발 과정 중 프로세스 효율이 좋지 않으면 교체하거나 다른 방법을 찾아 개선시킴.
    • 저비용 고품질 목적

3. 형상 관리 프로세스(configuration)

• 지속적인 변경 요구에따른 형상 관리를 체계적으로 관리
• 개발 작업과 독립적인 작업.


• 목적 : 높은 품질의 소프트웨어 프로덕트 개발

• 프로젝트 진행 되는 동안 많은 변경 버전들이 만들어지지만 모든 버전에 대한 원본 파일을 가지고 있는 것.

• 특징

  • 최신버전 유지
  • 지정된 버전으로 돌아갈 수 있는 기능
  • 무허가 변경이나 삭제를 방지
  • 현 시스템에대한 모든 문서, 정보를 다 가지고있음

  

• 버전 관리 : 개발 중에 있는 모듈이 만족되고 승인 되면 형상 관리로 넘어감(version) 이전 버전도 자동 보관한다.

• 접근 제어 : 동시에 작업 시 파일의 손상을 막기 위해 접근을 제어함. // 승인 대기 중인 작업물을 변경시키면 안됨.