[66] 소프트웨어공학 02차시 소프트웨어 프로세스와 생명주기

1. 소프트웨어 개발 프로세스의 중요성

가. 소프트웨어 개발의 목표

정해진 기한 내에, 주어진 예산을 이용해 사용자가 원하는 좋은 품질로 개발하는 것

나. 소프트웨어 프로젝트 실패의 원인

소프트웨어의 요구사항이 복잡해지고 규모가 점점 커짐.

정해진 기간 내에 고품질의 소프트웨어를 개발하는 것이 점점 더 어려워짐.

다. 소프트웨어 개발 프로세스의 중요성

소프트웨어 제품의 품질은 그 제품을 만들기 위해 사용된 프로세스의 품질에 의해 결정됨.(Watts S. Humphrey)

2. 소프트웨어 개발 생명주기

가. 소프트웨어 개발 생명주기란?

소프트웨어를 어떻게 개발할 것인가에 대한 전체적인 큰 흐름을 나타내는 추상적 표현으로, 순차적 또는 방법적인 단계로 구성됨.

개발 생명주기의 각 단계에는 관련된 여러 활동들이 정의되어 있고, 이 활동들을 통해 다음 단계에 활용될 수 있는 산출물이 만들어 짐.

전체 프로젝트의 비용 산정과 개발 계획을 수립할 수 있는 기본 골격을 제시하고 참여자들 간에 의사소통의 기준과 용어의 표준화를 가능하게 함.

각 단계별로 그 단계의 완성을 나타내는 산출물을 정의함으로써 문서화가 충실한 프로젝트 관리를 가능하게 함.

나. 주먹구구식 개발 모델(Build-Fix Model)

요구사항 분석, 설계 단계 없이 일단 개발에 들어간 후 만족할 때 까지 수정 작업 수행

크기가 매우 작은 규모의 소프트웨어 개발에 적용 가능

정해진 개발 순서가 없기 때문에 계획이 정확하지 않음.

관리자는 프로젝트 진행 상황 파악에 어려움.

개발 문서가 없기 때문에 개발 및 유지보수에 어려움.

다. 폭포수 모델(Waterfall Model)

순차적으로 소프트웨어를 개발하는 전형적인 개발 모델

기본적 모델이며 가장 많이 사용되는 모델

유구사항 분석, 설계, 구현, 테스팅, 유지보수 과정을 거침.

프로세스가 단순하여 초보자가 쉽게 적용 가능

중간 산출물이 명확, 관리하기 좋음

코드 생성 전 충분한 연구와 분석 단계

앞 단계가 완료될 때까지 다음 단계들은 대기 상태

실제 작동되는 시스템을 개발 후반부에 확인 가능하기 때문에 고객이 요구사항을 확인하는데 많은 시간이 걸림.

단순하거나 이미 잘 알고 있는 문제에 적합

변화가 적은 프로젝트에 적합

1) 요구사항 분석

What의 단계

사용자 요구나 주어진 문제를 정확히 분석 이해하는 과정

구현 시스템의 기능, 목표, 제약사항 등을 정확히 파악

발주자와 개발자가 요구분석 사항에 동의하여야 다음 단계(설계)로 진입

요구사항 명세서가 결과물로 작성됨.

2) 설계

How의 단계

분석된 결과를 어떻게 프로그램으로 구성할 것인가

솔루션에 집중

시스템 구조 설계: 시스템을 구성하는 모듈의 관계와 구조

프로그램 설계: 각 모듈 내에서의 알고리즘을 설계

사용자 인터페이스 설계: 사용자에게 보이는 부분을 설계

설계 명세서가 결과물로 작성됨.

3) 구현

Do it의 단계

이전 단계의 모듈 설계를 기준으로 프로그래밍

소스 코드가 결과물로 작성됨.

4) 테스트

프로그램이 입력에 따라 요구되는 결과대로 작동하는지, 내부적 이상 여부 및 오류 발견을 위해 수행

테스트 계획을 세운 후 문서화

5) 유지보수

개발된 소프트웨어의 변경사항을 수정하는 것

수정 유지보수, 적응 유지보수, 기능 추가 유지보수 등이 있음.

https://ko.wikipedia.org/wiki/폭포수_모델

폭포수 모델 - 위키백과, 우리 모두의 백과사전

라. 원형 모델(Prototyping Model)

폭포수 모델의 단점을 보완한 모델

점진적으로 시스템을 개발해 나가는 접근 방법

원형(Prototype)을 만들어 고객과 사용자가 함께 평가한 후 개발될 소프트웨어의 요구사항을 정제하여 보다 완전한 요구사항 명세서를 완성함.

소프트웨어 개발 초기에 고객의 요구사항을 완전히 파악하기 어려울 때 원형을 가능한 빨리 개발하여 고객과 검증하는 것

고객으로부터 피드백을 받은 후 원형을 폐기

시스템 기능 중 중요한 부분만 구현하여 피드백을 얻은 후 지속적으로 발전시켜 완제품을 제작

사용자의 의견 반영이 잘 됨.

사용자가 더 관심을 가지고 참여할 수 있고, 개발자는 요구를 더 정확히 도출할 수 있음.

원형이 최종 결과라고 믿고 소프트웨어 개발이 완성되리라는 사용자의 오해, 기대심리 유발

개발 착수 시점에 사용자 요구가 불투명하거나, 실험적으로 실현 가능성을 확인해보고 싶거나, 혁신적인 기술을 사용할 때 적용 가능

1) 요구사항 정의

일부 요구사항 또는 불완전한 요구 사항으로부터 제품의 윤곽을 잡음.

2) 원형 설계(Quick Design)

주어진 요구사항을 기반으로 빠른 설계를 함.

주로 제품의 인터페이스에 초점을 맞춤.

3) 원형 개발

설계된 원형을 RAD 도구 등을 사용하여 빠르게 구현함.

https://ko.wikipedia.org/wiki/고속_응용_프로그램_개발

고속 응용 프로그램 개발 - 위키백과, 우리 모두의 백과사전

고객이 요구하는 기능을 구현하고 필요한 요소를 파악하는데 중점을 둠.

프로그램의 신뢰도나 품질이 아니라 가능한 빨리 원형을 구현하는 것이 목적

4) 고객 평가

고객과 개발자가 함께하는 가장 중요한 단계

고객 요구사항을 정확하게 규명하기 위해 원형에 대한 사용 및 평가시간을 충분히 제공

개발될 소프트웨어의 요구사항 정제에 중요한 정보로 활용

5) 원형 정제

원형이 어떻게 수정되어야 할지를 결정

원형 개발과 검증, 요구사항 정제의 순환을 반복하여 추가적인 정보를 통해 요구사항을 완성해 나감.

마. 나선형 모델

폭포수 모형과 원형 모형의 장점을 수용하고 위험 분석을 추가한 점증적 개발 모델

프로젝트 수행 시 발생하는 위험을 관리하고 최소화하려는 것이 목적

고비용의 시스템이나 시간이 많이 소요되는 큰 시스템 구축 시 유용

모든 단계에서 기술적인 위험을 직접 고려할 수 있어, 사전에 위험 감소 가능

테스트 비용이나 제품 개발 지연 등의 문제 해결 가능

폭포수, 원형 모델에 비해 상대적으로 복잡하여 프로젝트 관리 자체가 어려울 수 있음.

1) 계획 및 정의 단계

개발자는 고객으로부터 요구사항을 수집

개발자는 시스템의 성능, 기능을 비롯한 시스템의 목표를 규명하고 제약 조건을 파악

목표와 제약 조건에 대한 여러 대안들을 고려하고 평가함으로써 프로젝트 위험의 원인을 규명 가능

2) 위험 분석 단계

초기의 요구 사항을 토대로 위험 규명

위험에 대한 평가가 이루어지면 프로젝트를 계속 진행할 것인지 아니면 중단할 것인지 결정

3) 개발 단계

시스템에 대한 생명주기 모델을 선택하거나 원형 또는 최종적인 제품을 만드는 단계

4) 고객 평가 단계

구현된 소프트웨어를 고객이나 사용자가 평가함.

고객의 피드백을 얻는데 필요한 작업이 포함

다음 단계에서 고객의 평가를 반영할 수 있는 자료 획득 가능

https://ko.wikipedia.org/wiki/나선_모형

나선 모형 - 위키백과, 우리 모두의 백과사전