시스템 개발 패러다임 4가지
과거 틀이 정해지지 않은 소프트웨어 개발은 이에 위기를 불러왔고 그 결과 소프트웨어 개발 방법론이 등장하게 되었다. 소프트웨어 패러다임으로 우리는 개발에 대한 여러 가지 시각과 관점, 틀을 생각하게 되었고 다양한 생각의 전환으로 목표를 달성하기 위해 필요한 방법, 개발 환경 및 관리에 대한 포괄적인 틀을 고려한 결과 많은 방식 중 대표적인 4가지 방법론이 대두되었다.
폭포수 모델(Waterfall Model)
폭포수 모델은 고전적 라이프 사이클 패러다임이라 불리며 건축과 같은 설계 공학에서 가장 많이 사용되고 있는 기법이다. 소프트웨어 개발에단계적이며 체계적인 순차적 접근법을 사용하여 정의하고 있으며 개념 정립에서 구현까지 하향식 접근 방법을 사용하여 요구사항 분석, 설계같은추상화 단계에서 구현, 테스팅과같은 낮은 추상화 단계까지 각 단계마다 결과물을 산출하며 단계가 끝날 때 마다 과정의 끝을 알리고 현 단계에서그 이전 단계로의 피드백 여부에 따라 참여자들의 서명으로 동결되며 다음 단계로 진행된다. 폭포수 모델은 프로젝트 진행과정을 세분화하기 때문에관리가 용이하지만 초기 단계를 제외하면 후반부로 갈 수 록 고객의 요구 반영이 어렵기 때문에 설계에 있어 가장 중요한 문제점이 최종 결과물에서발견된다는 단점이 있다.
원형 패러다임(Prototyping Paradigm)
원형 패러다임은 소프트웨어 개발에 있어 엔지니어들이 고객의 요구를 불완전하게 이해하고 있는 경우를 대비하여 간단한 시제품을 만들어서 보여주는 것을 의미한다. 이는 시스템 개발 시 고객이 초기 요구사항을 전달하였지만 실제 개발에 있어 고객의 요구사항은 상시 변동이 가능한 점을 감안하여 간단한 프로토타입을 만들어 보여주는, 점진적 개발을 통한 접근 방법이다. 최초의 요구사항 분석 후 시제품을 설계하고 개발하며 고객에게 전달하여 고객은 시제품을 평가한다. 이러한 평가 이 후 다시 수정할 부분을 토대로 시제품을 정제하고 요구사항을 재수렴 후 위의 단계를 반복한다. 그리고 마지막으로 완제품을 생산하여 최종 결과물을 고객에게 제공한다.
이러한 원형 패러다임은 프로토타입을 사용한다는 점에서 기존 폭포수 모델과 차이가 있으며 결과물과 유사한 시제품이 초기 고객에게 보여진다는 점에서 고객과 개발자의 오해뿐만 아니라 고객 자신도 생각지 못했던 부분을 제시할 수 있도록 하며 실제 개발에 어렵거나 혼돈이 생기는 부분을 완제품 생산 이 전에 규명할 수 있다. 다만 프로토타입을 접한 고객으로 하여금 완제품에 대한 오해가 생길 수 있으며 극한 상황에 대한 성능 평가가 어렵고 다른 시스템과의 교류 및 통합에 대한 결과를 얻기 어렵다는 단점 역시 존재한다.
나선형 패러다임(Spiral Paradigm)
나선형 모델은 폭포수 모델과 원형 패러다임의 장점들에 ‘위험 분석’이라는 새로운 요소를 추가하여 만든 패러다임이다. 시스템을 개발하는데 있어 위험은 반드시 생길 수 밖에 없는 요소이지만 이러한 위험이 단순한 것이 아닌 막대한 손해를 불러올 수 있다면 개발은 쉽게 이루어지지 않을 것이다. 따라서 이러한 문제점을 보완하기 위하여 계획 및 정의 이후 위험 분석 단계를 진행하여 초기 요구사항에 따른 위험을 분석하고 평가하여 프로젝트를 계속 진행할 것인지, 아니면 중단할 것인지를 결정한다. 실제로 나선형 패러다임은 초고속 정보 통신망 개발이나 대형 국책 사업과 같은 시간이나 비용이 많이 들고 오래 걸리는 큰 시스템을 구축하는데 많이 사용되는 가장 현실적인 접근 방법론이다. 그러나 각 단계에서 요구되는 분석이나 평가, 그리고 차선책, 고려해야될 사항 등이 많이 존재하여 프로젝트 관리 자체가 복잡하고 어렵기 때문에 성공을 위해서는 리스크(Ri나) 관리에 능한 전문가가 필요하고 각 공정별 인원 배치가 복잡하다는 단점을 가지고 있다.
4세대 기법(4th Generation Techniques)
4세대 기법은 CASE와 같은 자동화 도구들을 이용하여 요구사항 명세서를 토대로 실행코드를 자동으로 생성할 수 있게 해주는 방법이다. 이러한 도구들은 고급언어 수준에서 요구하사항이 명시되면 그것을 시행할 수 있는 제품으로 전환이 가능하게 하지만 실제로 현재의 4세대 기법들은 고급 언어에서 실행 코드로의 전환이 정교하지 못하고 불필요한 많은 양의 코드를 생성하기 때문에 유지보수에 어려운 점이 있고 모호성을 해결하기 위한 정형 명세 언어로 표현하려는 노력이 진행되고 있다. 그러나 많은 CASE 도구들이 코드 생성을 지원해주고 실행 코드로 전환해주기 때문에 소프트웨어 생상성에 대한 요구나 소프트웨어 위기를 해결할 주요 기법으로 대두되고 실제로 많은 응용 분야에서 폭넓게 사용될 것이라는 전망이 있지만 이 기법이 실용화되면 많은 기존 프로그래머들이 소프트웨어 컨설턴트나 요구사항 분석 직무로 직업을 변경하게 되거나 심하면 일자리를 잃게되는 음지적인 요소가 존재한다.