프로세스 - 결함 제거의 용이성
프로그래밍이 소프트웨어 개발에서 중심이 되는 작업이라고 생각하는 것은 프로그래밍이 그만큼 어렵고 재능이 있어야 하는 작업이기 때문입니다. 이런 생각 때문에 대부분의 오류는 가장 어려운 작업인 프로그래밍을 하는 동안 발생할 것이라고 믿어 의심치 않습니다. 하지만 실제는 개발 과정의 모든 단계에서 오류가 발생할 수 있습니다. 단계별 오류 발생 시점의 분포는 요구 사항 분석 단계에 20%, 설계 단계에 30%, 코딩 단계에 50% 정도로 알려져 있습니다. 오류를 발견하고 수정하는 데 소요되는 노력은 발생 시점에 따라 다릅니다.
오류가 발생한 후 발견이 지연될수록 수정하는 데 드는 비용이 더 듭니다. 요구 사항 분석 단계에 발생한 오류를 테스팅 단계에 수정한다면 분석 단계에서 수정하는 비용보다 100 정도까지 올라갈 수 있습니다.
뒤로 갈수록 수정 비용이 많이 드는 것은 명백한 사실입니다. 요구에 오류가 있다면 설계와 코드에도 영향을 줄 것이기 때문입니다. 코딩 이후에 오류를 수정하려면 설계와 코드 모두 따라서 수정 비용은 자연스럽게 증가합니다.
결국 개발 각 단계에서 발생한 오류는 그 단계에 수정되어야 하며 구현 후 오류를 찾아내기 위한 테스팅 작업까지 기다리지 말아야 합니다. 바꾸어 말하면 오류 탐색과 수정은 소프트웨어 개발 전체 단계에 지속적인 프로세스가 되어야 합니다. 개발 단계의 관점에서는 각 단계의 출력을 다음 단계를 시작하기 전에 검증해야 합니다. 다시 말해 품질 보증 작업을 프로세스 전체와 각 단계별로 하여야 합니다. 품질 보증 작업의 주목적은 결함을 찾아내고 수정하는 일입니다.
품질 보증 작업은 분명히 프로세스에서 지원되어야 할 목표입니다. 하지만 결함을 미리 방지하기 위한 지원을 제공하는 것이 더 좋습니다. 현존하는 품질 보증 기술은 한계가 있어 유입된 오류를 전분 발견할 수는 없습니다. 시스템을 릴리즈 할 시점에 시스템에 남아 있는 결함의 총수를 줄이려면 오류의 유입을 막는 방법이 더욱더 확실합니다. 결함 방지를 지원하기 위하여 따르는 일반적인 방법은 과거의 프로젝트에서 배우기 위하여 개발 프로세스를 사용하는 것입니다. 이렇게 하면 작업 수행하는 방법을 향상시킬 수 있습니다.
이렇게 프로세스 정할 때는 예측 가능성, 테스팅과 유지 보수성, 변경의 용이성, 결함 제거의 용이성을 파악 후에 프로세스를 나누며 작업 단위를 너무 나누지 않은 한 안에서 프로세스를 만들어 사용하는 것이 좋은 품질, 낮은 비용의 프로젝트를 하여 성공적인 프로젝트를 마무리할 수 있습니다. 이번 글은 여기서 마무리하며 다음 글부터는 소프트웨어의 개발 프로세스에 관하여 포스팅할 것이며, 소프트웨어의 생명주기에 관하여 알아볼 것입니다. 여기서 소프트웨어에는 폭포수 모델, 프로토타이핑 모델, 점진적 모델, 나선형 모델, V 모델 있습니다. 맛보기로 말씀드리면 폭포수 모델은 고전적인 방식으로 앞서 하나의 일을 끝내면 다음 일을 하지 않는 방식입니다. 프로토타이핑 모델은 시제품을 하나 만들어 고객과 소통하는 방식이며, 나선형 모델은 계획 - 위험 - 개발 - 고객 이런 구조를 반복하여 소프트웨어를 만들어 가는 생명주기 모델입니다. 여기서 더 말씀드리면 너무 많은 것을 말씀드리는 것 같으니 그럼 이만 ~~!!! 다음 글에서 뵙겠습니다.
소프트웨어 개발 프로세스
소프트웨어의 개발 프로세스 모델을 이해하는 것은 소프트웨어 공학을 공부하는 것이 필수적입니다. 소프트웨어도 사람과 같이 소프트웨어에도 생명주기가 있습니다. 개발된 소프트웨어도 계속 적으로 변경되고 새로운 기능이 추가되어 쓰이다가 마침내 소멸되는 것입니다. 소프트웨어가 성장하고 있는 단계를 소프트웨어 개발 프로세스 모델이라 하며 여러 가지 모델이 제안되어 있습니다.
소프트웨어를 개발하는 과정은 아파트나 빌딩을 짓는 건축과 비슷합니다. 아파트를 짓는다면 먼저 건축설계자가 입주민 대표와 만나 어떤 아파트를 원하는지 들어볼 것입니다. 입주민들은 아파트의 모양 뿐 아니라 부대시설이 몇 개 필요하며 각 부대시설의 용도와 기능들을 요구할 것입니다. 건축설계사는 이런 요구 사항을 반영하여 층별 배치도와 대략적인 조감도를 그려 입주민 대표와 입주민들에게 자세히 설명합니다. 의견을 조정한 후 동의를 얻는다면 시공단계에 들어갑니다.
물론 시공 단계에 들어가기 전에 자세한 여러 가지 설계가 필요합니다. 평면도와 측면도는 물론이며 자세한 배관 및 전기 배선이 표시된 설계 도면이 준비되어야 합니다. 시공 단계를 점검하던 입주민 대표가 설계가 마음에 들지 않는다면 수정하는 경우도 발생합니다. 설계를 수정하여 결국에는 아파트가 완성되었다 라고 합시다. 입주하기 전에 거쳐야 할 중요한 단계가 있습니다. 그것이 바로 테스트입니다. 방에 전등이 잘 켜지며 어둡지 않은 지, 수도에서 물이 잘 나오는지, 난방이 잘 작동되는지 점검해야 합니다. 완공되어 입주한 후에도 고장이나 수리할 필요가 생깁니다. 이는 유지보수 단계로 볼 수 있습니다. 시공회사가 애프터 서비스 차원에서 고쳐줄 수 있지만 시간이 많이 흐른 후에는 유지보수는 집주인 책임입니다.
소프트웨어 프로젝트도 유사한 단계로 진행됩니다. A 회사의 회계업무 처리를 위하여 소프트웨어를 개발하기로 하였다 합시다. 내부에서 개발하든 외부에 맡기든 일단 사용자의 요구 사항을 결정할 것입니다. 시스템의 범위를 정하고 개발된 시스템을 사용할 회계업무 처리부서의 사원들이 무엇을 원하는지를 개발자가 이해한 점으로 정리합니다. 요구 사항이 정의되면 시스템 설계에 들어갑니다. 건축에서 층별 배치도를 작성하듯이 소프트웨어 시스템을 구성하는 컴포넌트와 인터페이스에 대하여 정의합니다. 또한 건축의 외형을 조감도나 모형으로 나타내듯이 소프트웨어의 외형, 즉 사용자 인터페이스를 설계합니다.
설계가 끝나면 비로소 프로그래밍 작업을 시작합니다. 설계까지는 프로그램에 대한 것은 언급하지 않고 주로 기능과 외형, 데이터베이스에 대하여 설계합니다. 건축에서 층별 배치도와 조감도를 작성하여 확정한 후 시공에 들어가듯이 소프트웨어의 기능과 컴포넌트의 상호 관계를 정확히 작성한 후 프로그래밍을 시작합니다.
개별적으로 작성한 프로그램이 완성되면 모아서 통합하기 전에 단위테스트를 합니다. 모듈 단위의 테스트가 끝나면 비로소 통합하여 테스트를 하고 전체 시스템의 기능이 잘 작동되며 원하는 성능이 발휘되는지 테스트합니다. 개발된 시스템을 고객과 사용자가 최종적으로 점검한 후 완성을 확인합니다. 인수 결정이 나면 고객이 원하는 하드웨어에 설치하고 사용에 들어가는데 이후부터 유지보수 작업이 시작됩니다.
이상과 같이 소프트웨어를 개발하는 과정에는 여러 가지 작업이 필요하여 나열하면 아래와 같습니다.
- 요구 분석과 정의
- 시스템 설계
- 프로그램 설계
- 프로그램의 작성(코딩)
- 테스트(단위 테스트, 통합 테스트, 시스템 테스트)
- 시스템 설치
- 유지보수
이렇게 소프트웨어의 개발도 교량이나 건물을 건설할 때와 같이 일정한 공정을 따라 진행합니다. 각 공정, 즉 개발 단계는 수행되어야 할 작업이 정해져 있고 각 단계 작업을 위하여 필요한 입력 자료와 수행 결과가 정의되어 있어야 합니다. 또한 한 단계가 끝나서 다음 단계로 넘어가는 분명한 기준이 설정되어야 합니다. 이러한 관점에서 소프트웨어 개발 모델은 소프트웨어 엔지니어가 여러 기술적 업무를 어떤 순서로 할 것인가에 대한 지침을 제공합니다. 또한 개발과 유지보수 작업을 관리할 수 있도록 비용과 자원을 예측하고 중간 결과물의 품질을 관리하고 진척도를 조율할 수 있게 합니다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)