프로토타이핑 모델
프로그래밍에 관한 전문적 지식이 없는 대부분의 사용자들은 개발될 소프트웨어에 대한 개략적인 목적과 기능들에 대하여 요구할 수는 있으나 입력, 출력, 내부 처리에 대하여 정확히 요구하기란 쉽지 않습니다. 또한 발주자의 입장에서는 알고리즘의 타당성, 운영체제와의 조화, 사용자 인터페이스의 형식 등을 개발 도중에 확인할 방법이 없습니다. 즉, 프로젝트의 실현 가능성을 보장받을 수가 없습니다. 이러한 경우에 프로토타이핑은 좋은 방법이 될 수 있습니다. 프로토타이핑이란 시스템의 일부 혹은 시스템의 모형이 될 만한 것을 만드는 과정입니다. 예를 들면, 시스템을 사용하는 과정을 보여줄 시나리오나 화면 모형을 말합니다. 이는 시스템의 작동을 시뮬레이션 하여 사용자가 볼 수 있는 반응을 보여준다. 시범 시스템을 만드는 것도 하나의 방법 이 될 수 있다. 이것은 요구된 소프트웨어의 일부를 구현하여 보여주는 것으로 나중에 구현 단계에서 사용될 골격 코드가 된다. 화면생성기, 프로토 타이핑 도구를 이용하면 시범 시스템을 쉽게 만들 수 있다. 실제 소프트웨어의 첫 번째 버전을 만드는 경우도 있습니다. 이것은 실제 시스템이 설치될 환경과 같은 조건에서 사용될 시스템을 만드는 것으로 여기에 기능을 추가하고, 변경하고, 문서화하면 프로젝트의 최종 생산물이 됩니다.
프로토타이핑 기반 개발 프로세스의 목적은 폭포수 모델의 두 가지 단점을 보완하려는 것입니다. 즉, 설계 작업 이전에 요구를 동결하는 대신 요구의 이해를 목적으로 쓰고 버리는 프로토타입을 구축해 봅니다. 프로토타입의 개발은 완벽하지는 않지만 설계, 코딩, 테스트 단계를 밟게 되고 이렇게 함으로써 사용자도 시스템에 대하여 실감할 수 있고 요구를 이해할 수 있기 때문입니다.
프로토타이핑 모형은 아래 그림과 같이 요구분석 단계로부터 시작한다. 발주자나 사용자는 한 번에 완전한 요구를 낼 수 없기 때문에 프로토타입이 설계됩니다. 프로토타입이 구현된 후에 발주자와 개발자는 이를 평가하여 요구를 수정합니다. 프로토타입을 수정하거나 보완하고 이를 확장하면 시스템이 구현되는 것입니다. 이를 진화적 (evolutionary) 프로토타입이라고 하며 프로토타입을 계속 발전시켜 원래 정한 수준까지 만들어 나가는 형태입니다.
반면에 쓰고 버리는 프로토타입이 있다. 프로토타입의 개발은 요구 분석 명세서의 처음 버전이 나온 후에 시작합니다. 이 단계에는 시스템이 나 요구를 개략적으로 이해하지만 요구가 불분명하고 변경의 소지가 있기 때문에 프로토타입을 만든 후 사용자의 의견을 듣고 요구분석을 수정해 나가는 방법입니다. 이는 다루는 문제를 좀 더 정확히 이해할 목적으로 프로토타입을 만든 것입니다.
프로토타입을 개발한 후에는 사용자가 프로토타입을 사용할 기회를 줍니다. 사용 경험을 바탕으로 사용자가 개발자에게 피드백을 제공하는 것입니다. 올바른 것, 수정될 필요가 있는 것, 빠진 것, 필요 없는 것이 무엇인지 알려줍니다. 피드백을 기초로 프로토타입을 수정한 뒤 다시 시스템을 사용해 보게 합니다. 이런 주기를 반복하되 피드백에 의하여 얻어지는 이익이, 수정하여 피드백을 반영시키기 위한 비용이나 시간보다 더 가치가 있는 경우 계속합니다.
요구 분석을 위한 목적의 프로토타이핑은 비용이 적어야 합니다. 따라서 프로토타입에는 사용자의 경험으로 가치 있는 의견을 회수할 만한 기능만을 포함합니다. 예외 처리, 회복, 표준이나 형식의 준수와 같은 것은 프로토타입에 포함하지 않습니다. 이미 잘 이해된 요구에 대하여 프로토타입을 만들 필요는 없기 때문입니다. 잘 이해되지 않는 부분을 프로토타입으로 만들어 사용자에게 확인시킵니다.
프로토타입 개발은 약식으로 간단히 (quick and dirty) 한다. 프로토타입은 확인 후에 버릴 것이므로 품질보다는 빠르게 만들어야 합니다. 또한 프로토타입을 개발하는 과정에는 문서도 최소한으로 만들고 테스팅 작업에도 큰 비용을 투자하지 않습니다. 이러한 비용 절감 작업을 통하여 프로토타입의 비용을 최소화할 필요가 있습니다.
개발 비용이 늘어날 것이 염려되어 프로토타입을 자주 사용하지 않습니다. 그러나 프로토타이핑을 하지 않고 소프트웨어를 개발하는 비용이 프로토타이핑하는 것보다 더 많이 들 수도 있습니다. 두 가지 이유 때문입니다. 하나는 프로토타입 개발 경험이 실제 소프트웨어를 개발하는 후반의 비용을 절감시킵니다. 둘째는 개발이 오랫동안 이루어져 요구가 계속 바뀌기 때문입니다. 개발이 끝날 무렵 요구가 바뀌면 프로젝트의 비용은 상당히 상승한다는 것을 알 수 있습니다. 따라서 프로토타이핑을 개발하면서 요구 분석 단계를 길게 가져가면 요구는 좀 더 나중에 동결됩니다. 또한 사용자가 시스템 사용 경험을 가지게 되어 프로토타입 이후에 명시되는 요구는 실제 요구한 것과 가깝게 됩니다. 따라서 요구의 변경이 거의 없게 되고 개발 비용을 절감하게 됩니다.
프로토타입을 사용하면 여러 가지 장점이 있습니다. 발주자가 완성된 시스템의 모습을 먼저 볼 수 있고, 이를 보고 요구를 수정할 수도 있습니다. 프로토타입은 발주자나 개발자에게 공동의 참조 모델을 제공합니다. 발주자는 프로토타입으로 인하여 소프트웨어 개발에 더 관심을 가지고 참여할 수 있고, 개발자는 프로토타입을 통하여 사용자의 요구를 자세하게 도출할 수 있습니다. 또한 중요한 것은 프로토타이핑으로 소프트웨어 개발이 제대로 되고 있는지 확인할 수 있다는 점입니다.
다른 관점에서 보면 프로토타이핑 모형은 소프트웨어 생명 주기에서 유지 보수가 없어지고 개발 단계 안에서 유지보수가 이루어지는 것으로 볼 수 있습니다. 폭포수 모형은 개발 단계에 변경을 금지하여 이를 개발 후로 미루었습니다. 결국 뒤로 미룬 오류들을 변경하기 위하여 큰 비용과 노력이 유지보수 단계에 투입됩니다. 프로토타이핑은 두 차례에 걸쳐 개발할 기회가 있으므로 잘못된 부분을 고칠 기회가 많습니다.
프로토타이핑의 가장 큰 단점은 발주자가 프로토타입이 최종 결과라 믿고 곧 소프트웨어 개발이 완성되리라고 오해하는 것입니다. 프로토타입이 전체 시스템의 아주 작은 일부임에도 이를 인지할 수 없습니다. 때로는 발주자가 개발 일 정 단축을 요구하므로 소프트웨어의 품질을 저하할 우려도 있습니다. 또 다른 단점은 프로토타입이 과대 선전되어 발주자로 하여금 개발하여 인수해야 할 시스템보다 더 많은 기능을 기대하는 심리를 유발할 수 있습니다. 개발자 입장에서의 단점은 프로토타이핑 과정을 관리, 통제하기가 어렵다는 것입니다. 전통적 개발 모형과 같이 중간 과정을 점검할 수 있는 일정표와 산출물이 없다. 발주자의 참여를 계획하는 것은 쉽지 않습니다. 발주자가 프로토타입을 보고 승인한 후에는 곧 개발이 완료되는 것으로 오해합니다. 시스템을 완성하기 위하여 더욱 자세한 설계와 구현 과정에 대하여 이해하지 못하는 경우가 많습니다.
프로토타이핑 모형은 사용자 요구가 불투명할 때 전통적 방법인 폭포수 모 형을 대치할 수 있는 방법입니다. 폭포수 모델은 개발을 계속하기 위하여 요구를 동결하는 반면 프로토타입 구축을 경험한 후 동결된 요구는 더 안정적입니다. 따라서 개발 초기에 요구가 정확히 이해되지 않을 경우 프로토타이핑 모델을 사용하면 소프트웨어 개발이 더 효과적으로 이루어질 수 있습니다. 결국 프로젝트에서 요구를 잘못 파악하는 위험을 줄일 수 있는 획기적인 방법입니다. 또한 완전한 시스템을 개발하는 데 드는 대규모의 자원을 소비하지 않고 실험 적으로 실현 가능성을 타진하는 방법입니다. 이제까지 쓰이지 않았던 혁신적인 기술이 사용될 때 이러한 접근이 필요합니다.
참고자료 출처 : 새로쓴 소프트웨어 공학 (저자 : 최은만)