-패러다임(paradigm)이란 바라보는 눈, 시각, 관점, 기본 틀 등을 의미하는 것으로 문제를 보는 방식을 말한다.
<소프트웨어의 개발>
① 소프트웨어 개발 방법 – 소프트웨어를 어떻게 만들 것인가를 결정하는 기술적인 요소들을 제시해 주고 프로젝트의 진행 단계에서 요구되는 기법과 수행되어야 할 과제를 포함한다.
② 소프트웨어 개발 환경 – 소프트웨어 개발 방법론을 지원해 주기 위해 필요한 자동화 시스템(CASE), 데이터베이스 관리 시스템(DBMS)등을 포함한다.
③ 소프트웨어 개발 관리 – 개발 방법과 환경을 묶어 시스템을 효율적으로 적시에 개발할 수 있도록 공정과정과 절차를 제시하는 것을 의미한다.
4.1 폭포수 모델
-폭포수 모델은 고전적 라이프 사이클 패러다임(classic life-cycle paradigm)이라고도 하며 다른 공학에서도 많이 사용되고 있는 전형적인 기법이다.
- 폭포수 모델은 소프트웨어 개발을 단계적이며 체계적인 순차적인 접근 방법을 사용하여 정의 하고 있으며 가장 오래되고 널리 사용되는 패러다임이다.
- 폭포수 모델은 개념 정립에서 구현까지 하향식(top-down) 접근 방법을 사용하여 높은 추상화 단계에서 시하여 낮은 추상화 단계로 옮겨가고 있다.
- 각 단계가 끝날 때 마다 과정의 끝을 알리고 그 다음 단계로 진행한다.
<폭포수 모델의 단계>
1. 요구사항 분석 (결과물: 요구사항 명세서)
2. 설계 (결과물: 설계 명세서)
3. 구현 (결과물: 컴퓨터 프로그래밍)
4. 시험 (테스트를 하기 위한 테스트 계획 필요)
5. 유지보수
<단점>
1. 프로젝트의 진행과정을 세분화 하여 관리를 용이하게 하나, 실제의 경우 대부분 순환이 발생하기 때문에 순차적인 흐름을 따라가는데 어려움이 있다.
2. 원하는 요구사항을 초기에 구체적으로 기술하기 어렵다.
3. 작동하는 시스템이 프로젝트의 후반부에 가서야 얻어짐으로써 중요한 문제점이 뒤에 발견된다.
4.2 원형(Prototyping) 패러다임
- 원형 패러다임은 엔지니어들이 고객의 요구를 불완전하게 이해하고 있는 경우를 대비해서 간단한 시제품을 만들어 보여주는 것
<시제품 개발을 통한 장점>
1. 시스템의 기능이 사용자에게 보여짐으로써 개발자와 사용자의 오해가 규명된다.
2. 생각지 못한 기능과 서비스가 발견된다.
3. 사용하기 어렵거나 혼돈을 일으키는 기능들이 규명되어 명료화된다.
4. 분석가나 개발자는 불완전 하거나 일치하지 않는 요구사항을 시제품을 통하여 발견 할 수 있다.
5. 완전하지 못하지만 작동하는 시스템을 만들어 가능성과 유용성을 관리자에게 보여줄 수 있다.
6. 시제품은 고품질 시스템의 요구사항을 명세화 할 수 있는 기초를 제공한다.
<원형 패러다임의 단계>
1. 요구사항 분석단계 – 원형 패러다임의 첫 번째 단계로 분석가와 사용자가 만나 소프트웨어의 전반적인 요구사항을 정의한다.
2. 시제품 설계단계 – 원형에 대한 설계를 한다.
3. 시제품 개발 단계 – 시제품 개발에 있어서는 일반적으로 성능. 다른 시스템과의 인터페이스 등에 대한 것은 판단하기 어려워 중요하게 다루어지지 않는다. 기초 수준 정도로 구현 되면 된다.
4. 고객의 시제품 평가 단계 – 원형 패러다임의 가장 중요한 단계, 시제품은 고객에 의해 평가되고, 개발된 소프트웨어의 요구 사항을 구체적으로 정제하기 위해 사용된다.
5. 시제품 정제단계 – 사용자가 원하는 것을 만족시키기 위해 시제품에 대한 조율이 필요하다.
6. 완제품 생산단계 – 원하는 시스템을 개발 하는 것.
4.3 나선형(Spiral) 패러다임
- 나선형 모델은 폭포수 모델과 원형 패러다임의 장점에 새로운 요소인 위헌 분석(risk analysis)을 추가하여 만든 것이다.
- 시스템을 개발하면서 생기는 위험을 최소화하는 것이 이 패러다임의 중요한 목적이다.
- 나선형 모델은 비용이 많이 들고 시간이 오래 걸리는 큰 시스템을 구축해 나가는데 가장 현실적인 접근 방법이다.
<나선형 패러다임의 단계>
1. 계획 및 정의 단계 – 요구사항을 모으고 프로젝트 계획을 수립한다
2. 위험분석 단계 – 요구사항에 근거하여 위험이 규명된다.
3. 개발단계 – 위험에 대한 평가 후 이루어진다. 이 단계에서는 “어떠한 패러다임이 적용되어 시스템의 개발이 이루어 질 것인가” 하는 개발 모델을 결정한다.
4. 고객 평가 단계 – 개발과정에서 나론 결과를 (예: 초기 소프트웨어 시제품)를 사용자가 평가하는 과정이다.
<단점>
1. 앞의 두 모델보다 복잡하여 프로젝트 관리 자체를 어렵게 만들 가능성이 많다.
2. 많은 고객을 상대로 하는 상업용 제품의 경우 적용하기 어렵다.
3. 새로운 접근 방법이기 때문에 충분한 검증이 되어 있지 않다.
4.4 4세대 기법(4th Generation Techniques)
- 4세대 기법(4GT)은 CASE를 비롯한 자동화 도구들을 이용하여 요구사항 명세서로부터 실행코드를 자동으로 생성할 수 있게 해주는 방법이다. 이러한 도구들은 고급언어 수준에서 요구사항이 명시되면 그것이 실행 할 수 있는 제품으로 전환 가능하게 한다.
-고급언어를 실행코드로 바꾸어줄 만큼 정교하지 못하고 불필요한 많은 양의 코드를 생성하고 유지보수에 어려운 점이 있다.
4.5 소프트웨어 제작 방법의 공통점
- 시스템의 정의(definition), 개발(development), 유지보수(maintenance)단계는 모든 시스템 공학에 적용되는 일반적인 공통점이다.
1. 시스템 정의 과정
: 요구사항 분석과정에 해당하며 사용자의 관점에서 시스템이 제공해야 하는 지능, 데이터, 인터페이스를 정의한다. 이 과정은 무엇(what)에 초점을 맞춘다.
2. 시스템 개발 과정
: 시스템을 어떻게(how to) 만들지에 초점을 맞춘 설계, 구현, 시험의 과정이다
3. 시스템 유지보수 과정
: 시스템이 개발된 후 오류의 수정, 환경의 변화, 기능의 행상 요구 등과 연관되어 발생하는 변화(change)에 초점을 맞춘다.
