Ch2 소프트웨어 개발 프로세스

1 소프트웨어 개발 프로세스의 이해

01. 프로세스

• 일을 처리하는 과정 또는 순서를 일컫는다
• 주어진 일을 해결하기 위한 목적으로 그 순서가 정해져 수행되는 일련의 절차

02. 소프트웨어 개발 프로세스

• 작업: 소프트웨어를 개발할 때 일을 수행하는 작은 단위
• 프로세스는 이 작업 순서의 집합이다.
• 단순히 작업 순서만이 아니라 일정, 예산, 자원과 같은 제약 조건을 포함하는 일련의 활동을 말한다.
• 의미론적
  • 좁은 의미
    • 소프트웨어 제품을 개발할 때 필요한 절차, 과정 그리고 구조를 일컫는 말
    • 사용자의 요구 사항을 소프트웨어 시스템으로 구현하기 위한 일련의 활동이라고 볼 수 있다.
  • 넓은 의미
    • 절차나 구조뿐 아니라 그 작업을 수행하는 데 필요한 방법과 도구를 비롯해 개발과 관련된 실제 절차를 따라 작업을 수행하는 참여자들까지도 포함한다.
    • 즉 소프트웨어 개발 목적을 이루는 데 필요한 통합적 수단
• 프로세스는 가이드 역할을 한다.
• 프로세스의 3요소
  1. 능력, 교육 및 동기가 부여된 인원
  2. 작업들의 관계를 정의하는 절차와 방법
  3. 도구와 장비

process, problem, people

---

2 소프트웨어 프로세스 모델의 이해

• 운영체제나 데이터베이스 관리 시스템처럼 대규모 소프트웨어는 개발에 참여하는 개발자가 많고 기간도 길며 예산도 많이 필요하다.
• 따라서 개발 전에 여러 소프트웨어 프로세스 모델 중에서 가장 적합한 모델을 프로젝트의 표준으로 정하고, 모든 참여자가 그 표준의 절차에 따라 개발해야한다.

소프트웨어 프로세스 모델의 정의

• 소프트웨어 개발 생명주기 라고도 한다.
• 어떻게 개발할 것인가에 대한 전체적인 흐름을 체계화한 개념으로 개발 계획 수립부터 최종 폐기 때까지의 전 과정을 다루고 있다.

소프트웨어 프로세스 모델의 목적

• 주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의한다.
• 즉 각 단계에서 무엇을 하고 어떤 순서로 하며 어떤 자원을 사용할 것인지에 대한 지침과 프로세스 관리, 개발된 소프트웨어에 대한 품질 관리 등을 명확히 한다

소프트웨어 프로세스 모델의 역할

• 전체적인 기본 골격을 세워준다.
• 일정계획을 수립할 수 있고, 개발 비용 산정뿐 아니라 여러 자원을 산정하고 분배할 수 있다.
• 참여자 간에 의사소통의 기준을 정할 수 있다,
• 용어의 표준화 가능케
• 개발 진행상황 명확히 파악
• 각 단계별로 생성되는 문서를 포함한 산출물을 활용하여 검토할 수 있다.

  ---

 

3 주먹구구식 모델

• build-and-fix 모델은 즉흥적 소프트웨어 개발 또는 코딩과 수정 모델이라고 한다.
• 공식적인 가이드라인이나 프로세스가 없는 개발 방식이다.
• 즉 요구 분석 명세서나 설계 단계 없이 간단한 기능만을 정리하여 개발하는 형태를 말한다.
• 일반 코드를 작성하여 제품을 만들어 본 후에 요구분석, 설계 , 유지 보수에 대해 생각하는 것이다.
  1. 첫 번째 버전의 코드를 작성하여 제품을 완성한다.
  2. 작성된 코드에 문제점이 있으면 수정하여 해결한다.
  3. 문제가 없으면 사용한다.
• 개발자 한 명이 단시간에 마칠수 있는 경우에나 사용할 수 있는 방법이다.
• 대학 수업의 한 학기용 프로젝트 정도이다.
• 따라서 실제 개발 현장에서 사용하기에는 문제가 많다.
• 이 모델은 정해진 개발 순서나 각 단계별로 문서화된 산출물이 없다.
  1. 관리 및 유지보수가 매우 어렵다.
  2. 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍쳐를 만들수도 없다.
  3. 개발자가 일을 효과적으로 나눠 개발할 수도 없다. 진척 상황을 파악안됌
  4. 여러번 수정하다보면 구조적으로 가독성이 높았던 프로그램의 구조가 나빠져 수정이 매우 어려워 진다

4. 선형 순차적 모델

• 폭포수 모델로 알려짐 (고전적 생명 주기classic life cycle)이라고 한다.

  

1. 폭포수 모델의 개발 절차

• 하향식으로 진행되며 병행되거나 거슬러 반복되지 않는다
• 확실히 매듭을 짓고 그 결과를 확인한 후에 다음 단계로 진행한다.
• 요구 사항 분석 단계가 끝나면 요구 분석 명세서라는 문서가 산출된다.

각 단계에서 하는 일

1. 계획 단계(planning)

• 문제를 정의한 후 프로젝트 영역을 결정한다.
• 작업 분할 구조도(WBS)를 이용하여 세부 작업을 결정한다.
• CPM(Critical Path Method)를 이용해 작업 순서를 결정한다.
• 간트 차트를 이용해 일정표를 작성한다.
• 기능 점수(FP)등을 이용해 프로젝트에 소요되는 비용을 산정한다.
• 계획 단계의 최종 산출물인 ‘개발 계획서’를 작성한다.

2. 요구 분석(requirement analysis) 단계

• 기존 시스템을 분석하고, 인터뷰 등을 통해 사용자의 요구 사항을 수집한다.
• 사용자가 요구하는 기능적 요구 사항과 비기능적 요구 사항을 파악한다.
• 각 방법론에 따른 표기법을 이용해 정리된 요구 사항을 표현한다.
• 객체지향 방법론에서는 유스케이스 다이어그램을 작성한다.
• 요구 분석 단계의 최종 산출물인 요구 분석 명세서를 작성한다.

3. 설계(design)단계

• 크게 전체적인 시스템 구성을 나타내는 상위 설계(아키텍처 설계)와 각 모듈 (컴포넌트, 자료구조, 알고리즘)의 세부 내용을 설계하는 하위 설계로 나뉜다.
• 상위 설계
  • 개발하려는 소프트웨어의 전체 구조를 볼 수 있는 아키텍처를 설계한다.
  • 아키텍처의 품질 속성을 결정한다.
  • 아키텍처의 스타일을 결정한다.
  • 설계 패턴을 결정한다.
• 하위 설계
  • 모듈 간의 결합도의 모듈 내의 응집력을 고려해 모듈의 세부 내용을 설계한다.
  • 객체지향 방법론에 따라 설계를 한다면 설계 원리, 클래스 간의 관계, 클래스 설계 원칙을 고려한다.

4. 구현 단계 (implementation)

• 코딩을 하는 단계이다.
• 보안이 매우 중요하므로 시큐어 코딩(secure coding)하는 방법도 고려하자

5. 테스트(test) 단계

• 프로젝트의 성격에 맞는 방법을 선택한다.
  • 개발자 또는 사용자 시각에 따른 분류
  • 사용되는 목적에 따른 분류
  • 프로그램의 실행 요구 여부에 따른 분류
  • 품질 특성에 따른 분류
  • 소프트웨어 개발 단계에 따른 분류

6. 유지보수 (maintenance) 단계

• 사는 집에 불편한 부분이 발견되거나 낡으면 계속 고치면서 살아가는 것과 유사하다.
• 소프트웨어도 사용하다 보면 추가 요구사항, 수정 사항 등이 많이 발생 한다.
  • 수정 유지 보수(correction)
  • 적응 유지 보수(adaption)
  • 기능 보강 유지 보수 (enhancement)
  • 예방 유지 보수(prevention)

2. 폭포수 모델의 장점과 단점

폭포수 모델은 각 단계마다 요구 분석 명세서, 설계 사양서, 코드 문서, 데이터베이스 메뉴얼, 사용자 매뉴얼, 운영 매뉴얼 등의 상세한 문서가 생성되는 문서 중심의 모델이라 할 수 있다.

폭포수 모델을 사용했을 때의 장점

• 관리가 용이하다.
• 체계적으로 문서화할 수 있다.
  • 단계별 산출물을 체계적으로 문서화할 수 있다.
• 요구 사항의 변화가 적은 프로젝트에 적합하다.

폭포수 모델을 사용했을 때의 단점

• 폭포가 위에서 아래로 흐르듯이 각 단계는 앞 단계가 완료되어야 수행할 수 있다.
• 각 단계마다 작성된 결과물이 완벽한 수준으로 작성되어야 다음 단계에 오류를 넘겨주지 않는다.
  • 현실은 그렇지 못하다. 산출물을 충분히 검토했다 해도 발견하지 못한 오류가 있을 수 있다.
• 사용자가 중간에 가시적인 결과를 볼 수 없어 답답해 할 수 있다.
  • 사용자가 실제로 소프트웨어 작동 모습을 보려면 구현이 끝나야 한다.
  • 원하는 결과가 아니라면 수정 요구 사항을 받아 보완하기 위해 시간과 비용이 많이 들어가게 된다.

5. V 모델

V모델은 폭포수 모델의 변형이다.

테스트 단계를 추가 확장하여 테스트 단계가 분석 및 설계와 어떻게 관련되어 있는지를 나타낸다.

단위 테스트 (unit test)

• 목표 : 개별 모듈 검증
• 내용
  • 단위 테스트는 모듈 테스트라고 하며, 시스템을 구성하는 모듈(함수, 서브루틴, 컴포넌트 등)이 기능을 올바르게 수행하는지 판별한다.
  • 내부에 존재하는 논리적인 오류를 검출할 목적으로 상세 설계 사양서의 내용대로 정확히 구현되었는가를 집중적으로 확인한다.

통합 테스트 (interation test)

• 모듈이란? 기능상 성격이 비슷한 또는 연관성 있는 부분들이 조립된 덩어리를 말합니다.
• 목표 : 모듈 간의 인터페이스 확인
• 내용
  • 단위 테스트를 마친 각 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는다
  • 모듈 사이에 인터페이스 오류는 없는지 모듈 사이의 상호작용이 적절하게 수행되는지
  • 모듈이 올바르게 연계되어 동작하고 있는지 확인
  • 모듈 상호 간에 잘 결합되었는지를 확인

시스템 테스트(system test)

• 목표: 모듈이 모두 통합된 후 사용자의 요구 사항들을 만족하는지 확인
• 내용
  • 모듈 간의 인터페이스에 문제가 없는지 확인하는 통합 테스트까지 끝나면, 시스템 테스트를 통해 시스템 전체가 정상적으로 작동하는지 테스트한다.

인수 테스트 (accptance test)

• 목표 ; 시스템이 예상대로 동작하고 요구 사항에 부합하는지 확인
• 내용
  • 요구 분석 명세서에 명시된 사항을 모두 충족하는지 테스트한다.
  • 인수 테스트가 끝나면 사용자에게 정상적으로 인수한 후 프로젝트를 종료한다.

6. 진화적 프로세스 모델

프로토타입 모델

1. 진화적 프로세스 모델의 등장 배경(목적)

• 폭포수 모델의 가장 큰 단점 중 하나가 단계를 거슬러 올라가 작업하는 것이 쉽지 않은 구조이다.
• 새로운 요구가 수시로 발생해 이에 민첩하게 대응할 수 있는 방법이 필요 → 진화적 프로세스 모델
• 특징
  • 사용자 요구에 따라 가상으로 실행되는 초기 버전의 프로토타입을 만들고 사용자는 인터페이스 중심의 화면과 실행 후 나타나는 가상의 결과 화면을 본다
  • 그런 다음 변경된 요구 사항을 반영하거나 추가해 2차 프로토타입을 만들어 사용자에게 보여준다.
  • 이 같은 작업을 반복하여 완성
  • 프로토 타입을 활용하면 반복적인 추가 및 수정 요구가 그때그때 반영되므로 완성 제품을 대폭 수정해야 하는 대형 사고를 막을 수 있다.
  • 사용자 요구 사항을 파악하여 가능한 빠른 시간 내에 프로토타입을 개발한 후 이것을 고객과의 의사소통 도구로 활용→ 사용자가 만족하는 최종 완제품을 만들 수 있다.

2. 프로토타입

• 프로토 타입의 사전적 의미: 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품으로, 제작물의 모형이라 할 수 있다.
• 완전한 소프트웨어를 만들기 전에 사용자의 요구를 받아 모형을 만들고 이 모형을 사용자와 의사소통하는 도구로 활용한다.
• 예시 : 모델 하우스
• 모델 만드는 것을 모델링이라고 하듯, 프로토타입을 만드는 것을 프로토타이핑이라 한다.
• 개발자는 사용자의 초기 요구 사항을 반영하여 1차 프로토타입을 만들고, 이것을 사용자에게 보여준다. 그러면 사용자는 1차 프로토타입을 보면서 추가 요구나 수정 요구를 하고, 개발자는 이런 요구 사항을 받아들여 2차 프로토타입을 만든다. 이과정을 사용자가 만족할 때까지 여러 번 반복하여 사용자의 최종 요구를 반영한 완성품을 만드는 개발 방식이다.
• 프로토타입 모델은 폭포수 모델을 기반으로 개발하면서 사용자의 요구를 충분히 반영하기 위해 프로토타입을 추가한 모델이다.

  

• 프로토타입 모델은 사용자의 요구가 불투명하고, 요구 사항의 변화가 계속 많이 발생하는 경우에 적합하다.
• 또한 비용이 많이 필요한 대규모 시스템이나 새로운 혁신 기술을 사용할 경우 개발 전에 프로토타이핑을 통해 실현 가능성을 타진해볼 수 있다.

프로토타입 모델은 최종 프로토타입을 어떻게 활용하느냐(두가지 형태)

1. 최종 프로토타입을 버리고 처음부터 새로 소프트웨어를 개발하는 실험적 프로토 타입 모델
2. 최종 프로토타입을 버리지 않고 지속적으로 발전시켜 개발해 가는 진화적 프로토타입 모델이다.

2.1 실험적 프로토타입 모델

• 사용자의 요구 사항을 반복적으로 반영하여 최종 프로토타입을 만드는 데 목적이 있다.

2.2 진화적 프로토타입 모델

• 구현된 프로토타입을 버리지 않고 지속적으로 개선. 보완하여 최종 시스템으로 완성시킨다.(나선형 모델)

3. 프로토타입 모델의 개발 절차

1. 요구 사항 정의 및 분석

• 사용자의 요구를 파악하고 정리하여 요구 사항을 정의한 후 분석한다.

2. 프로토 타입 설계

• 사용자와 대화할 수 있는 수준으로 설계

3. 프로토 타입 개발

• 완제품 개발 x
• 출력 결과가 사용자 원하는 것인지 보여주는 데 목적이 있다.
• 가상 수행을 전제로 한 실행을 보여주는 것이 우선이다.
• 완전한 실행 여부, 개발된 제품의 신회도, 품질 등은 나중으로 미루고 RAD(Rapid Application Development) 같은 도구를 이요해 빠르게 실행한다.

4. 사용자에 의한 프로토타입 평가

• n번 반복 하여 사용자의 추가 요구 사항이 더 이상 없을 때 최종 프로토 타입이 만들어진다.

5. 구현

• 첨부터 다시하면 실험적
• 개선해나가면 진화적

4. 프로토 타입 모델의 장점과 단점

장점

• 가시적인 결과인 프로토타입이 개발자와 사용자 간의 의사소통 도구로 사용되어 구체적이고 원활하게 대화할 수 있다는 것이다.
• 사용자의 요구가 충분히 반영 된 요구 분석 명세서를 만들 수 있다는 것이다.
• 사용자의 요구가 충분히 반영되어 최종 제품이 나오므로 유지보수에 필요한 노력과 시간을 많이 줄일 수 있다.

단점

• 필요한 투입 인력과 비용산정이 어렵다.
• 빠른 시간 안에 최종 결과가 나올 것처럼 착각을 줄 수 있다.
• 관리-통제하기 어렵다.
• 이정표나 산출물을 생성하기가 쉽지 않기 때문이다.
• 목표가 불명확해질수있고 추가 비용이 들수 있다.

7. 나선형 모델

1. 나선형 모델의 특성

‘나선형’은 소라 껍데기처럼 빙빙 비틀려 돌아가는 모양을 말한다.

• 진화적 프로토타입 모델 절차를 따른다.
• 위험 분석 단계가 추가되었다.

위험 분석 단계

• 위험 요소는 소프트웨어 개발하는데 방해되는 모든요소들
• 예
  • 번번하게 변경되는 요구 사항, 팀원들의 경험 부족, 결속력이 떨어지는 팀워크
  • 프로젝트 관리의 부재
• 반복적 개발 모델

2. 나선형 모델의 개발 절차

1. 계획 및 요구 분석 단계

• 개발 의도를 파악
• 기능 요구사항 , 성능 같은 비기능 요구 사항 정의 및 분석

2. 위험 분석 단계

• 위험 요소를 찾아 목록을 작성
• 위험 요소를 평가 진행해도 되는 지 평가
• 개발하는데 일반적으로 나타날 수 있는 위험 요소
  • 개발자의 이직
  • 요구 사항 변경
  • 발주사의 재정적 어려움
  • 예상을 빗나간 투입 인력
  • 개발 기간의 부족
  • 개발비의 초과

3. 개발 단계

4. 사용자 평가 단계

• n번 반복하여 더 이상의 추가 및 수정 요구가 없으면 최종 제품을 만든다

3. 나선형 모델의 장점과 단점

장점

• 위험을 고려를 하면서 개발이 진행된다
• 위험으로 인해 프로젝트가 중단되는 심각한 사태가 발생할 확률이 비교적 적다는 장점이 있다.
• 사용자의 요구도 충분히 반영되는 매우 유용한 소프트웨어 프로세스 모델이다.

단점

• 요구분석, 위험 분석, 개발, 사용자 평가가 반복적으로 계속 진행되기 때문에 프로젝트 기간이 길어질 수 있고, 반복 횟수가 많아질수록 프로젝트 관리가 어렵다.
• 위험 관리 전문가를 필요로 한다.

8. 단계적 개발 모델

개발과 사용을 병행하는 과정을 반복하여 진행하면서 완료한다.

• 단계적 개발 모델은 릴리스를 구성하는 방법에 따라 점증적 개발 방법과 반복적 개발 방법으로 나눌 수 있다.

1. 점증적 개발 방법 : 개발 범위의 증가

• 코스요리 처럼 ‘하나가 끝나면 그다음, 또 하나가 끝나면 그다음과 같이 하나씩 늘려간다.’
• 점증적 방법은 중요하다고 생각되는 부분부터 차례로 개발한 후 그 일부를 사용하면서 개발 범위를 점차 늘려가는 방식이다.

2. 반복적 개발 방법 : 품질의 증가

• 한정식
• 초기에 시스템 전체를 일차적으로 개발하여 인도한 후 , 각 서브 시스템의 기능과 성능을 변경 및 보강하여 완성도를 높인다. 이렇게 업그레이드된 릴리스 버전을 다시 내놓는 것이다.
• 초기의 요구사항이 불분명한 경우 적합
• 실제 개발에서는 점증적 과 반복적 함께 사용

9. 통합 프로세스 모델

• 반복적 개발 방법론

  

통합 프로세스 (UP: United Process)모델

통합 프로세스(UP) 방법

OMG(object Management Group)가 공개한 UML(Unified Modeling Language)과 함께 제안되어 통합된 프로세스이다.

• 이후 Ration사에 의해 RUP (Rational Unified Peocess)라는 이름으로 상품화

1. 통합 프로세스(UP 모델의 절차)

• 개발 과정은 크게 4단계 (도입, 구체화, 구축, 전이)로 나뉘고 각 단계도 여러 개의 작은 단위 (반복 iteration)로 나뉘어 각 반복 구간을 하나씩 정복해간다.
• 객체지향 분석/설계 중심의 프로젝트에서 많이 사용되는 대표적인 반복적/점증적(interative, incremental)프로세스 이다.

1. 도입 단계 (inception phase)

• 준비 단계, 인지 단계, 시작 단계, 발견 단계, 개념 정립의 단계와 같이 다양한 이름으로 불린다.
  • 개발의 기초가 되는 아이디어 도출
  • 투자 비용 대비 효과 분석
  • 사업의 타당성 및 프로젝트의 실현 가능성 확인
  • 소프트웨어 개발 목표 수립
  • 프로젝트의 개발 범위 파악
  • 비용과 기간 산정
  • 프로젝트 계획
  • 프로젝트의 위험 요소 발굴
  • 사용자의 전체 요구 사항 이해 및 정의
  • 사용자와 의사 교환할 수 있는 프로토타입 개발
  • 몇 가지 요구 사항의 명확화
  • 액터와 유스케이스 도출
  • 유스케이스의 일부만 상세하게 기술
  • 아키텍처 후보군 발굴
  • 반복에 대한 계획과 평가 수행
• 통합 프로세스 모델의 도입단계

2. 구체화 단계 (eleboration phase)

• 상세 단계, 정련 단계라고도 불린다.
• 비즈니스 모델링과 요구 사항 정의 작업은 점차 줄어든다.

구체화 단계 활동

• 아키텍처 수립
• 상세한 프로젝트 계획
• 요구 사항의 기능 요소에 대한 문서화
• 도입 단계에서 파악한 요구 사항을 상세하게 분석
• 유스케이스 확실히 파악
• 아키텍처 계획 수립
• 핵심 아키텍처 설계
• 아키텍처 설명서 작성
• 첫 번째 반복을 통한 산출물로 아키텍처 프로토타입 생성
• 생성된 첫 번째 프로토타입을 다음 단계의 아키텍처 기준선으로 활용
• 프로젝트 수행을 방해하는 중대한 위험 요소들을 찾아 위험 축소 및 제거
• 반복에 대한 계획과 평가 수행
• 이 단계가 끝나면 유스케이스 모델을 대략 80% 정도

3. 구축 단계 (construction phase)

• 구축 단계에서는 구현 작업이 가장 많이 이루어 진다.
• 모든 개발 요소 구현
• 사용자 설명서 및 현재 버전의 설명서 작성

4. 전이 단계(transition phase)

• 이행 단계라고 한다.
• 사용자를 위한 제품을 완성하는 단계이다.
• 완성된 제품을 사용자에게 넘겨주는 과정에서 수행해야 할 일을 한다.

전이 단계 활동

• 개발된 모듈에 대해 베타 테스트 실시
• 사용자에게 배포 가능한 단위로 묶는 작업 수행
• 개발된 소프트웨어를 사용자 환경에서 사용자가 직접 테스트(인수테스트)
• 소프트웨어 제품과 사용자 설명서 등 단계별로 생성된 최종 산출물을 사용자에게 인도
• 제품 사용자 및 유지보수 담당자에게 교육

5. 도입. 구체화. 구축. 전이 단계의 공통 작업

• 분석 , 설계, 구현, 테스트 작업을 공통으로 수행한다.
• 각 작업을 반복 수행
  • 구체화, 전이 단계는 2회씩 구축 단계는 3회 반복

10. 애자일 프로세스 모델