#title 프로세스 개요
[[TableOfContents]]

==== 프로세스 ====
 * 프로세스(process)란, 하나의 문제를 해결하기 위한 일련의 작업을 말한다. 
  * 수행하고자 하는 사람들이 쉽게 이해할 수 있어야 한다.
  * 수행하는 사람들이 일관된 행동을 할 수 있도록 명확하게 정의되어야 한다.
  * 이렇게 프로세스를 정의하는 이유는 일관된 방법을 사용함으로써 조직에서 발생하는 __중복 작업을 최소화__하기 위해서이다. 
 * 프로세스는 요리책과 비슷하다.
  * 요리책은 음식을 만들기 위해 무슨 재료가 얼만큼 필요하며, 몇 도에서 얼마 동안 요리해야 하는지 알려주지만, 계란 노른자가 가운데에 위치하도록 삶는 방법을 알려주지는 않는다. 
  * 구체적인 내용이나 스킬은 절차에서 다루는 것이 일반적
 * 제품, 사람, 기술이 아닌 프로세스에 초점을 맞춰야 한다.
  * 제품
   * 요구사항 명세서를 작성하는 일은 제품 중심의 활동. 
   * 조직에서 요구사항 명세서를 작성하는 모든 사람이 조직에서 인정한 하나의 방법으로 작업하고, 그 결과 거의 같은 수준의 요구사항 명세서를 개발할 수 있도록 가이드라인을 제공하는 것이 프로세스 중심.
  * 사람: 뛰어난 사람을 고용하라는 것이 아닌, 따를 수 있는 좋은 프로세스를 갖추라는 의미. 
  * 기술: 기술은 문제를 근본적으로 해결해 주는 것이 아니라, 근본적인 문제를 해결하기 위해 선택한 방법을 쉽게 실행하게 해주는 것

==== 모델 ====
 * 모델(model)이란, 성공적인 조직들로부터 수집한 우수 사례들의 결정체
  * 모델: What to do
  * 성공사례: How to do
 * 조직에서 모델을 사용하는 이유
  * 프로세스 개선 활동에 대한 계획을 수립하거나, 결과를 예측하는 것이 쉽지 않았기 때문에
  * 모델을 만드는 것은 많은 시간과 비용이 소요되는 등 굉장히 어려운 작업이기 때문에
 * 모델은 충분히 따를 만한 가치가 있는 것
  * 모델과 조직의 환경이 맞지 않는 것에 대한 대체 방법에 대한 인정
  * 많은 대안을 사용하면 사용할수록 모델이 지향하고자 하는 우수 사례들로부터 더 멀어질 것이며, 조직의 문제점에 대한 개선 정도를 축소

==== 비즈니스 목적과 목표 ====
 * 사실 비즈니스 목표를 정의하지 않는다는 표현보다 정의할 수 없다는 표현이 더 적절할 수도 있다
 * GQM(Goal-Question-Metric)기법
  * 실제로 Problem-Goal-Question-Metric 이다.
  * 문제점: 개발자는 요구사항 변경 내용을 몰라 최초 요구사항대로 코딩하는 경우가 많다.
  * 목적: 고객이 원하는 제품을 제공해야 한다.
  * 질문: 어떤 경우에 요구사항을 충족시킨다고 할 수 있는가?
  * 메트릭: 전체 요구사항 대비 설계서나 프로그램에 반영된 요구사항 비율, 테스트 커버리지, 테스트 성공률 등
  * 관련 프로세스 영역: 요구사항 관리, 제품 및 프로세스 품질보증, 요구사항 개발
 * 조직의 문제들을 완벽히 정의할 수 있어야하며, 이 문제들이 어떤 비즈니스 목적과 연관되어 있는지 파악할 수 있어야 하며, 현재 수준을 측정한 후 목표수준을 결정하고, 이를 추적/관리 할 수 있을 정도로 충분히 성숙해야 한다. 

==== 문제 ====
 * 프로세스에 초점을 두는 것은 대단히 힘든 일이다.
 * 먼저 경영진을 설득하고, 적극적으로 경영진을 참여시켜야 한다. 경영진이 회의적이라면 포기하는 편이 낫다.
 * 조직원들을 참여시키는 것이다. 프로세스 개선은 여러분 조직을 진정으로 변화시키는 것이다.