[소프트웨어공학] 프로세스 - 생명주기 모델(Build-Fix/Waterfall/Prototyping/Spiral), 개발 방법론(UX/XP)

Github로 보기

---

소프트웨어 개발 프로세스

소프트웨어 개발의 목표

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

계속되는 프로젝트 실패

• 소프트웨어의 요구사항이 복잡해지고 규모가 점점 커짐
• 정해진 기간 내에 고품질의 소프트웨어 개발하는 것이 점점 더 어려워짐

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

• 소프트웨어 제품의 품질은 그 제품을 만들기 위해 사용된 프로세스의 품질에 의해 결정된다

정의

• 소프트웨어 개발에 필요한 절차만이 아니라, 그와 관련된 인력, 방법, 도구 들이 통합되는 수단
• 활동, 방법, 절차의 집합

소프트웨어 생명주기

의미

• 소프트웨어를 어떻게 개발할 것인가에 대한 추상적 표현
• 순차적 또는 병렬적 단계로 구성됨
• 개발 모델 또는 소프트웨어 공학 패러다임이라고도 함

특징

• 개발 생명주기의 각 단계에 관련된 활동들이 정의되어 있음
• 단계별 활동들을 통해 다음 단계에 활용될 수 있는 산출물이 작성됨
• 비용 산정과 개발 계획을 수립할 수 있는 기본 골격 제시
• 참여자들 간에 의사소통의 기준과 용어의 표준화를 가능케함
• 문서화가 충실한 프로젝트 관리를 가능하게 함

소프트웨어 생명주기 모델의 종류

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

생명주기 모델의 체계적 연구 이전

• 개요
  • 일단 개발에 들어간 후 만족할 때까지 수정작업 수행
• 적용 가능한 경우
  • 크기가 매우 작은 규모의 소프트웨어 개발
• 단점 : 정해진 개발 순서가 없음
  • 계획이 정확하지 않음
  • 관리자는 프로젝트 진행 상황 파악이 어려움
  • 개발 문서가 없기 때문에 개발 및 유지보수에 어려움

Waterfall Model (폭포수 모델)

• 개요

  • 순차적으로 소프트웨어를 개발하는 전형적인 개발 모델
  • 소프트웨어 개발의 가장 기본적인 모델

• 단계

  • 요구사항 분석 - 설계 - 구현 - 테스팅 - 유지보수
  • 다른 공학과 다르게 소프트웨어 개발은 단계를 거슬러 올라갈 수 있음

• 장점

  • 각 단계별로 정형화된 접근 방법 가능
  • 체계적인 문서화가 가능하여 프로젝트 진행을 명확하게 할 수 있음

• 단점

  • 앞 단계가 완료될 때까지 다음 단계들은 대기 상태여야 함
    • 실제 회사에서는 단계별로 다른 팀이 있음
  • 고객이 요구사항을 확인하는데 많은 시간이 걸림
    • 테스팅 단계에서 확인 가능한데, 요구사항에서 문제가 있으면 치명적
    • 때문에 요구사항이 명확한 프로젝트에서 많이 사용

Prototyping Model (원형 모델)

• 개요

  • 폭포수 모델의 단점을 보완한 모델
  • 소프트웨어 개발 초기에 고객 욕구사항을 완전히 파악하기 어려울 때 사용
  • 원형(prototype)을 만들어 고객과 사용자가 함께 평가한 후 개발될 소프트웨어의 요구 사항을 정제하여 보다 완전한 요구사항 명세서를 완성함

• 목적

  • 원형을 가능한 빨리 개발하여 고객과 검증하는 것

• 방법

  • 피드백을 받은 후 원형을 폐기하는 방법 (throw away prototype model)
  • 중요한 부분만 구현하여 피드백을 얻은 후 지속적으로 발전시켜 완제품을 제작하는 방법

• 단계

  • 요구사항 정의
  • 원형 설계 및 개발: 요구사항을 기반으로 빠른 설계 개발을 함
  • 고객 평가
  • 원형 정제: 원형이 어떻게 수정돼야 할지 결정, 설계~정제를 반복하여 요구사항을 완성해 나감

• 단점

  • 정제와 설계가 언제 끝날지 모르며 그만큼 비용이 낭비됨

Spiral Model (나선형 모델)

• 개요

  • 폭포수 모델과 원형 모델의 장점을 수용하고 위험 분석(Risk analysis)을 추가한 점증적 개발 모델
  • 프로젝트 수행 시 발생하는 위험을 관리하고 최소화하는 것이 목적

• 특징

  • 여러 개의 작업 영역으로 구분
  • 나선상의 각 원은 소프트웨어 개발의 점증적 주기 표현
    • 원의 바깥으로 갈 수록 완성도가 높아짐
  • 단계가 명확히 구분되지 않고, 엔지니어가 프로젝트 성격이나 진행상황에 따라 단계 구분

• 단계

  • 계획 및 정의 단계
  • 위험 분석 단계
    • 초기 요구사항을 토대로 위험 규명
    • 위험에 대한 평가 후 프로젝트를 계속 진행할 지 중단할 지 결정
  • 개발 단계
  • 고객 평가 단계

• 적용 경우 : 개발에 따른 위험을 잘 파악하여 대처 가능함

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

• 장점

  • 사전에 위험 감소 가능

• 단점

  • 정확하지 않은 위험 분석을 했을 경우 심각한 문제 발생 가능
  • 폭포수, 원형 모델에 비해 상대적으로 복잡하여 PM 자체가 어려울 수 있음

소프트웨어 개발 방법론

의미

• 소프트웨어 개발 생명주기 내의 각 단계에서 수행 방법과 활동들을 구체적으로 정의

방법론의 종류

• UX (unified process)
• XP (extreame programming)
• 마르미 (magic and )

UP (Unified Process)

• 개요

  • 객체지향 소프트웨어 개발 방법론 중 하나
  • 소프트웨어 개발 단계를 시간의 순서에 따라 네 범주로 나눔
  • 각 범주에는 요구사항 도출부터 평가까지 생명주기가 포함됨

• 특징

  • 반복적(Iterative)이고 점진적(Incremental)으로 개발
    • 반복되는 과정을 통해 실행 가능한 release가 산출되어, 최종 시스템으로 발전 ex) v1.0.1, v1.0.2, ...
  • 유스케이스(Usecase)를 기반으로 함
    • (사용자의 시나리오를 표기하는 문서 기법)
  • 아키텍쳐(Architecture) 중심의 개발을 지향
  • 위험관리를 중시

• 단계

  

  • 도입 (Inception)
    • 전체 요구사항을 대략적으로 이해하는 것에 중점을 둠
  • 상세 (Elaboration)
    • 요구사항을 더 강화하는 단계
    • 아키텍처를 실행 가능한 수준으로 확장, 구축단계 계획 수립
  • 구축 (Construction)
    • 실제 시스템을 구축하고 평가하는 데 중점을 둠
  • 이행 (Transition)
    • 제품 릴리즈 완성 단계
    • 사용자 환경에서 테스트가 진행됨

• 단점

  • 프로세스가 너무 무거움(개발 외에 들어가는 비용이 많음)
    • 대형 프로젝트에 적합.

XP (eXtreme Programming)

• 개요

  • 요구사항 변경으로 인한 비용이 개발 기간에 상관없이 일정하게 유지되도록 하는 것을 주목적으로 함

• 특징

  • 요구사항이 변경된다는 것을 가정하고, 고객의 피드백을 수용하기 위해 고객과 개발 팀이 함께 상주
  • 문서가 적어서, 동료 프로그래머와의 의사소통을 중요시 함
  • 단순하고 명확한 설계 유지 - 설계도를 계속 변화 시켜 나감
  • 우선순위가 높은 요구사항을 먼저 개발
  • 되도록 초기에 고객에게 시스템을 전달하여 피드백을 받음

• XP에서 사용하는 용어

• XP에서의 역할

• XP의 가치

마르미 (MaRMI)

• 개요
  • 한국형 소프트웨어 개발 방법론, UML 기반 객체지향 시스템 개발 지원

---

reference

• 상명대학교 한종대교수님 소프트웨어공학 수업