프로세스 - 예측 가능성
프로세스의 예측 가능성이란 어떤 프로젝트 안의 프로세의 결과가 프로젝트를 완성하기 전에 얼마나 정확하게 예측될 수 있느냐는 것입니다. 예측 가능성이란 어떤 프로세스의 근본 특성으로 예측할 수 없는 프로세스는 사용하기 어렵습니다. 그러한 이유로는 지금부터 설명하겠습니다.
비용을 예측하는 방법을 이야기해봅시다. 프로젝트 B는 2년 전 종료한 프로젝트 A와 유사합니다. 따라서 B의 비용은 A의 비용과 거의 비슷할 것입니다. 하지만 여기에는 프로젝트 B를 수행할 때 사용될 프로세스가 프로젝트 A에 사용한 프로세스와 같을 것이라는 사실을 전제로 하고 있습니다. 즉 프로세스가 예측이 가능하지 않았다면 그 프로세스를 사용하여 유사한 프로젝트를 수행할 때 동일한 비용이 발생한다고 보장할 수 없습니다.
품질에 관한 사항도 마찬가지입니다. 품질 예측의 근본은 제품의 품질이 개발에 사용하는 프로세스에 의하여 결정된다는 사실입니다. 어떤 프로젝트에서 나올 제품의 품질은 사용하려는 프로세스를 채택하여 과거에 개발한 제품의 품질을 따져 보면 예측할 수 있습니다. 효과적인 품질 관리 활동을 주로 프로세스의 예측가능성에 의하여 좌우됩니다. 예를 들어 효과적인 품질 제어를 하기 위한 한가지 방법은 개발 단계 중 어디에서 어떤 오류가 얼마만큼 나올 것인지를 예측하는 것입니다. 이를 이용하여 품질 보증 활동을 적절히 수행할 수 있기 때문입니다.
프로세스가 예측가능 할 때 이런 일들이 가능합니다. 즉 프로세스의 과거 경험을 바탕으로 현재 프로젝트의 오류 분포를 예측할 수 있습니다. 예를 들면 현재 수행되는 프로젝트의 테스팅 과정에 100 줄 당 10개의 오류가 발견되었다. 라고 하면 수긍이 가는 수준인지 아닌지 어떻게 판단할 것인가요? 그 프로세스의 과거 프로젝트가 100 줄 당 2개의 오류만 발견되었다면 품질이 저하될 것으로 예상하여 테스팅 작업에 더욱더 신경을 기울여야 했을 것입니다.
과거의 경험을 사용하여 비용과 품질을 컨트롤 하려면 예측이 가능한 프로세스를 사용해야 합니다. 예측 가능성이 낮은 프로세스를 가진 프로젝트에서 얻는 경험은 쓸모가 없습니다. 예측이 가능한 프로세스를 통계적으로 관리가 가능합니다. 동일한 프로세스를 따랐을 때도 동일한 결과를 생성한다면 통계적으로 처리할 수 있습니다. 결과에 편차가 있지만 그 편차는 무작위로 진행한 프로세스의 편차가 아니기 때문입니다. 아래 이미지가 이러한 사실을 잘 나타내고 있습니다. Y축은 품질, 생산성 등 관리하고 싶은 변수이며 X축은 프로젝트를 나타냅니다. 중간 굵은 선은 이 프로세스의 예상 수준입니다. 통계적으로 관리라 함은 관심 있는 변수의 대부분이 예상하는 값의 일정한 범위 안에 있는 것들을 뜻하게 됩니다.
높은 품질의 소프트웨어를 낮은 비용으로 계속 개발하려면 통계적으로 관리가 가능한 프로세스를 지녀야 합니다. 예측 가능한 프로세스는 좋은 품질과 낮은 비용을 보장하는 것은 필수 조건입니다. 프로세스 없이 좋은 품질과 낮은 비용의 소프트웨어는 결코 만들 수 없는 것은 아니지만 프로세스 없이는 한 번의 프로젝트를 완료하였다 하더라도 다음에 재현을 할 수 없습니다. 따라서 여러 프로젝트에 걸쳐 일관된 품질을 원한다면 예측이 가능한 프로세스를 가지고 있는 것은 당연하다고 말 할 수 있습니다. 소프트웨어 엔지니어링은 다양한 소프트웨어를 개발하는데 사용할 수 있는 일반적인 방법에 관심을 두고 있습니다. 결론적으로 예측 가능한 프로세스는 소프트웨어 공학의 인프라라고 할 수 있습니다.
프로세스 - 테스트와 유지 보수 편의성
일반적으로 소프트웨어 유지보수에 드는 비용은 개발 비용을 초과하는 것으로 알려져 있습니다.
소프트웨어 개발 비용 부분만을 줄이는 것보다 전체 비용을 줄이려면 개발의 목표가 유지보수 노력을 줄이는 것이 되어야 합니다. 즉 개발 프로젝트에서 가장 중요한 사항 중의 하나는 유지보수가 쉬운 소프트웨어를 만들어야 한다는 사실입니다.
소프트웨어 개발에서는 코딩 작업이 가장 중요한 것으로 알려져 왔습니다. 그 작업이 제일 많다. 개발 기관과 프로세스의 성격에 따라 정확한 분포는 차이가 나겠지만 몇 가지 시사하는 바가 있습니다. 먼저 코딩은 전체 개발 노력의 3분의 1에만 해당된다는 것입니다. 소프트웨어를 개발할 때 주로 프로그램을 작성하는 일에 관심을 보이므로 프로그래밍이 주되 작업이라는 상식을 뒤 업고 있습니다.
프로그래밍에 드는 노력을 결정하는 또 다른 방법은 프로그래머가 시간을 어떻게 사용하는가를 조사해 보는 것입니다. 어느 조사에 의하면 프로그래밍 작성에 13%, 프로그램을 읽고 메뉴얼을 작성하는데 16%, 의사소통 32%, 기타 39%의 시간을 사용한다고 합니다. 이처럼 데이터는 프로그래밍이 프로그래머의 주된 작업이 아니라는 것을 보여주는 것입니다. 기타 작업에 소요되는 시간을 제외하더라도 남은 시간은 25%에 불과하다고 합니다. Bochm에 의하면 프로그래머는 20% 정도만의 시간을 프로그래밍에 사용한다고 합니다.
위 데이터에서 알 수 있는 또 한가지의 사실은 테스팅이 개발 단계에서 가장 노력이 많이 드는 작업이라는 것입니다. 일반적으로 테스팅은 준비를 소홀히 라는 부수적인 업무로 생각합니다. 테스팅 작업을 이렇게 이해하면 충분하지 않은 자원을 배정하게 되고 결구 신뢰도가 낮은 소프트웨어를 만들거나 일정이 지연됩니다.
결국 프로세스의 목적은 설계와 코딩에 드는 노력을 낮추려는 것이 아니라 테스팅과 유지보수에 드는 노력을 낮추는 일입니다. 테스팅과 유지보수 작업은 설계와 코드 품질을 좌우합니다. 테스팅과 유지보수가 쉽도록 소프트웨어를 설계하고 코딩한다면 비용을 상당히 낮출 수 있습니다. 따라서 개발 프로세스를 정할 때 중요한 이슈는 쉽게 테스팅 하고 수정할 수 있게 만드는 것입니다
프로세스 - 변경의 용이성
소프트웨어는 여러 가지 이유로 변경이 많이 됩니다. 소프트웨어는 변경이 많다는 것은 문제의 근본 특성입니다. 요구사항의 변경으로 인한 수정을 생각해 봅시다. 변경은 우리 생활의 일부이지만 요즘은 너무 빨리 변합니다. 조직과 비즈니스가 변하면 이를 지원하는 소프트웨어도 변경되어야 합니다. 하지만 소프트웨어를 구축하고 수정하기 어려운 모델이 있다면 그것은 어떤 상황에서도 적합한 것은 아닐 것입니다.
실행되고 있는 소프트웨어를 변경하는 것은 개발 작업을 벗어난 일이므로 논외로 하더라도 개발하는 과정에서도 변경이 이루어집니다. 무엇보다 고객의 요구가 프로젝트 중간에 바뀔 수 있습니다. 프로젝트가 장시간 수행된다면 상당한 변경을 예산할 수 있습니다.
비즈니스 요구에 의한 변경은 차지하더라도 개발자의 작업에 대한 결정이 바뀌어 변경될 수도 있습니다. 따라서 소프트웨어 시스템의 일부 개발된 부분을 사용자에게 보여줄 수 있고 사용자나 고객은 요구한 것이 올바른 지 또는 추가할 것은 없는지 피드백을 해 주길 원합니다. 다시 말해 변경은 항상 일어나며 변경을 쉽게 다룰 수 있는 프로세스를 원합니다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)