[소소하게2] 10월 12일 월요일 소소한 공부

소프트웨어 공학 3장 공부!!

 

폭포수 모델

고전적 라이프 사이클 패러다임이라고도 한다.

계획 -> 요구사항 분석 -> 설계 -> 구현 -> 시험 및 유지보수의 순서로 시스템의 개발이 이루어진다. (피드백 있음)

SW 개발을 단계적으로 체계적이며 순차적인 접근 방법을 사용하여 정의.

가장 오래되고 널리 사용되고 있는 패러다임

개념 정립에서 구현까지 top-down(하향식) 접근 방법을 사용하여 높은 추상화 단계에서 시작하여 낮은 추상화 단계로 옮겨간다.

장점 : 프로젝트 진행 과정을 세분화하여 관리를 용이하게 한다.

단점 : 실제의 경우 대부분 feedback이 발생하기 때문에 순차적인 흐름을 따라가는데 어려움이 있다. 또한 고객이 원하는 요구사항을 초기에 구체적으로 기술하기 어렵고, 작동하는 시스템이 프로젝트 후반부에 가서 얻어지기 때문에 중요한 문제점이 뒤에 발견된다.

 

 

원형 패러다임

간단한 시제품인 prototype을 만들어 보여주는 것.

폭포수 모델의 단점을 보완하기 위해 점진적으로 시스템을 개발해나가는 접근방법

시스템의 유용한 일부를 초기에 개발하여 사용자로부터 피드백을 시스템 개발 초기에 얻을 수 있다.

시제품을 통해 이전에 밝혀지지 않았던 사용자의 요구사항을 구체적으로 규명할 수 있다.

프로젝트 초기에 요구사항이 확실치 않거나 모든 요구사항을 미리 뽑아낼 수 없는 불안정한 상황일 때 프로젝트를 쉽게 제어 관리할 수 있게 해주는 패러다임

사용자의 필요와 요구사항을 빠른 속도로 알아내고, 시스템에 대한 이해와 품질 향상을 위해 사용된다.

피드백을 얻고 시제품을 버리는 경우도 있고 계속 발전시켜 완제품을 만들어 낼 수도 있다.

ex) 아파트의 모델하우스, 미래에 만들 자동차의 견본

 

시제품 개발을 통해 얻어지는 장점

시스템의 기능이 사용자에게 보여짐으로써 개발자와 사용자의 오해가 규명된다.

생각하지 못한 기능과 서비스가 발견된다.

사용하기 어렵거나 혼동을 일으키는 기능들이 규명되어 명료화된다.

분석가나 개발자는 불완전하거나 일치하지 않는 요구사항을 시제품을 통해 발견 가능

완전하지 못하지만 작동하는 시스템을 만들어 가능성과 유용성을 관리자에게 보여줄 수 있다.

고품질 시스템의 요구사항을 명세화할 수 있는 기초 제공

만들어질 완제품이 어떨 것이라는 것에 대한 오해를 불러일으킬 수 있으며 시제품에서 완제품으로 옮겨가는 데 많은 변화가 예상될 수 있다.

시스템의 극한 상황 등에 대한 성능 평가가 어려움

다른 시스템들과의 교류 및 통합 등에 대한 결과가 쉽게 얻어지지 않는다.

쉽고 빠르게 시제품을 만들 수 있는 도구들의 개발에 힘입어 많은 응용분야에서 사용됨

 

원형 패러다임 단계

1. 요구사항 분석 단계

분석가와 사용자가 만나 소프트웨어의 전반적인 요구사항 정의

폭포수 모델의 요구사항 분석과 유사

폭포수 모델에서는 개발이 시작되기 전에 요구사항이 분명히 명시되지만 원형 패러다임에서는 고객으로부터 받은 일부 요구사항만 정의하고 완전치 않은 요구사항에 대하여 윤곽을 잡아놓는다. 추가적인 정의가 필요한 부분은 시제품이 개발된 후 계속 정제해 나간다.

 

2. 시제품 설계 단계

원형에 대한 설계.

빠른 시제품 개발은 사용자들이 볼 수 있는 면에 추점을 맞추어 이루어진다.

시제품 개발의 목표가 확립되고 시제품에 포함될 시스템의 기능들이 골라진다.

시제품에 포함되는 것과 시제품에서 배제되어야하는 것이 무엇인지 규명하는 것이 중요하다.

시제품에 마지막 제품과 같은 도구와 개발 표준을 사용하면 비용이 많이 든다.

시스템의 모든 기능을 시제품 안에 간략하게 만들어 볼 수도 있다.

 

 

3. 시제품 개발 단계

시제품 개발에 있어서 성능. 다른 시스템과의 인터페이스 등에 대한 것은 판단하기 어려워 중요하지 않다.

오류를 관리하고 다루는 면은 무시되거나 기초 수준 정도로 구현하면 된다.

시제품의 신뢰도와 프로그램 품질 수준은 떨어진다.

목표는 어떻게 하면 시제품을 빨리 만들 수 있는가

 

4. 고객의 시제품 평가 단계

원형 패러다임의 가장 중요한 단계

시제품이 고객에 의해 평가되고 개발될 소프트웨어의 요구사항을 구체적으로 정제하기 위해 사용된다. 사용자들이 원형을 사용하고 평가할 수 있도록 충분한 시간을 주어 원형에 대해 익숙하도록 해주어야한다. 이를 통해 요구사항의 오류를 발견하고 규명할 수 있게 되며 추가되어야하는 요구사항 발견 가능

 

5. 시제품 정제 단계

사용자가 원하는 것을 만족시키기 위해 시제품에 대한 조율이 필요하다. 이는 개발팀이 무엇을 만들 것인가를 이해하는데도 도움을 준다. 시제품이 어떻게 고쳐져야하는지 결정하고 다음 단계의 시제품이 빠르게 만들어질 수 있도록 한다. 이 시제품은 다시 고객에게 평가되는 순환을 하게 되며 고객이 요구사항에 대하여 만족할 때까지 게속 된다. 이를 통해 시스템의 모든 요구사항을 규명할 수 있다.

 

6. 완제품 생산 단계

목표 : 원하는 시스템 개발

원형을 버리고 최종 시스템이 새로 만들어질 것인지, 또는 원형을 확장하여 완제품을 만들 것인지의 결정에 따라 완제품 개발 계획이 달라질 수 있다.

만약 원형을 버리고 새 시스템을 개발해야한다면 이 단계에서 완전한 폭포수 모델의 생명주기를 따르거나 4세대 기법의 적용이 가능하다.

 

시제품의 목적

실제 개발 이전에 사용자들이 시제품을 보고 느끼게 하여 사용자들로부터 요구사항을 검증하려는 것

실제 제품이 만들어지기 전 사용자를 교육, 훈련시키는 용도. 이는 원행 개발의 중요한 장점 중 하나로 시스템이 개발되어 t ㅏ용자가 실제로 사용하기까지의 시간을 줄여줄 수 있다.

시제품은 시스템 테스트를 하며 연속적으로 사용될 수 있다. 이는 시제품과 최종 단계의 제품에 같은 테스트가 적용될 수 있음을 의미한다. 만약 이 두 시스템이 같은 결과를 보여준다면 최종 단계의 제품이 제대로 만들어졌거나 테스트 케이스가 잘못되어 오류를 발견하지 못하는 경우이다. 만약 결과가 다르게 나오면 최종 시스템에 결함이 있음을 의미한다. 시제품은 테스트 케이스의 검증을 미리하여 시스템 테스트에 들어가는 노력을 줄여줄 수 있다.

 

나선형 모델

폭포수 모델과 원형 패러다임의 장점에 새로운 요소인 위험 분석을 추가하여 만든 것

위험의 수위에 따라 나선형 패러다임을 선택할지 말지 결정

시스템을 개발하면서 생기는 위험을 관리하고 최소화하려는 것이 이 패러다임의 주 목적

나선을 돌면서 점진적으로 완벽한 시스템을 만들어 나간다.

비용이 많이 들고 시간이 오래 걸리는 큰 시스템을 구축해 나가는데 가장 현실적인 접근 방법

성과를 보면서 조금씩 투자하기 때문에 위험 부담을 줄일 수 있다.

단점 : 모델 자체가 앞의 두 모델보다 더 복잡하여 프로젝트 관리 자체를 어렵게 만들 가능성이 많다. 많은 고객을 상대로 하는 상업용 제품의 경우에는 적용하기 힘들다. 새로운 접근 방법이기 때문에 많이 사용되지 않아 충분한 검증을 거치지 못했다.

 

#객체지향 소프트웨어 개발 방법론은 원형 패러다임과 나선형 패러다임 등의 점진적인 시스템 개발을 가능하게 하는 우수한 기법

 

나선형 모델 단계

1. 계획 및 정의

목표, 요구사항, 제약 조건 등을 규명한다.

요구사항을 모으고 프로젝트 계획 수립

성능, 기능을 비롯한 시스템의 목표를 규명하는 것부터 시작.

다음으로 시스템의 목표와 제약조건에 대한 차선책이 평가, 고려될 수 있다.

이러한 평가 과정은 프로젝트 위험의 원인을 규명하는데 효과적으로 사용된다.

 

2. 위험분석

목표에 잠재되어 있는 위험을 분석한다. 이러한 위험에 대한 평가 결과가 프로젝트를 계속할 것인가 중단할 것인가를 결정하는 요인

초기 요구사항에 근거하여 위험이 규명된다.

위험은 보통 부정확한 정보로부터 온다.

위험에 대해 평가하고 프로젝트를 go할지 말지 결정

 

3. 개발

프로젝트를 계속 하기로 결정하면 시제품을 개발

어떠한 패러다임을 결정하여 시스템 개발이 이루어질 것인가 하는 개발 모델 결정

시제품을 개발하거나 최종 제품을 만드는 과정

 

4. 고객 평가

고객이 평가한다. 이는 다음 나선의 목표 및 요구사항에 반영되어 좀 더 구체적이며 안정된 시스템 개발에 사용된다.

개발과정에서 나온 결과를 사용자가 평가하는 과정