코딩딩/CS

소프트웨어 개발 생명주기 모형의 개요

전낙타 2023. 9. 9. 13:44

1. 학습 목표

  • 소프트웨어 개발 생명주기 모형의 개요
  • 폭포수 모형
  • 프로토타입 모형
  • 나선형 모형
  • 4GT 모형

2. 학습 내용

소프트웨어 개발 생명주기 모형의 개요

소프트웨어 개발 생명주기 모형

  • 소프트웨어 개발 생명주기를 표현하는 형태
  • 소프트웨어 공학 패러다임이라고도 함

폭포수 모형 (waterfall model)

  • 개요
    • 가장 오래된 모형임
    • 많은 적용사례가 있지만 요구사항의 변경이 어려움
    • 각 단계의 결과가 확인된 후에야 다음 단계로 넘어감
    • 선형 순차적 모형으로 고전적 생명주기 모형이라고도

  • 특징
    1. 소프트웨어 개발의 각 단계를 확실히 매듭짓고 다음단계를 진행, 이전 단계로 넘어갈 수 없는 방식
    1. 가장 오래되고 폭넓게 사용됨
    1. 소프트웨어 개발 과정의 각 단계가 순차적으로 진행
    1. 두개 이상의 과정이 병행 수행되거나 이전 단계로 넘어가는 경우가 없음
    1. 개발 과정 중에 발생하는 새로운 요구나 경험을 설계에 반영하기 어려움
    1. 단계별 전의가 분명
    1. 단계별 산출물이 명확

  • 개발순서
    1. 계획
      1. 개발할 소프트웨어가 법적 경제적 기술적으로 실현 가능성이 있는지 조사
      1. 소프트웨어 개발에 사용될 자원과 비용을 측정함
    1. 요구사항 분석
      1. 사용자 요구사항을 정의하기 위하여 시스템의 요구사항을 수집함
      1. 시스템의 목표를 정하는 과정임
      1. 결과물 : 요구사항 명세서
    1. 설계
      1. 요구사항 분석과정에서 모아진 요구사항을 설계도면에 옮김
      1. 물리적 실현의 첫 단계
      1. 결과물 : 설계 명세서
    1. 구현
      1. 시스템의 기능이 수행 가능한 모습으로 나타남
      1. 프로그래밍 또는 코딩이라고 부름
      1. 결과물 : 컴퓨터 프로그램
    1. 시험
      1. 품질보증 활동의 중요한 일부분
      1. 사용자 요구사항, 설계, 구현의 정 과정에 대한 최종 점검을 포함
      1. 제품의 오류를 발견, 수정
      1. 최소한의 시간과 비용을 투자해서 최대한의 확률로 오류를 찾아낼 수 있도록 이루어져야 함
    1. 유지보수
      1. 변화에 대비하는 과정
      1. 수정 유지보수, 적응 유지보수, 기능추가 유지보수, 관리 유지보수가 있음

  • 장점 및 단점
    • 장점
      • 모형의 적용경험과 성공사례가 많음
      • 단계별 정의가 분명하고 단계별 산출물이 명확하게 제시됨
    • 단점
      • 개발과정 중에 발생하는 새로운 요구나 경험을 반영하기 어려움
      • 처음부터 사용자들이 모든 요구사항들을 명확하게 제시해야 함
      • 소프트웨어 개발이 완료된 시점에서 오류가 발견

프로토타입 모형

사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 시제품을 미리 만들어 최종 결과물을 예측하는 모형

  • 개요
    • 시스템 개발 시 고객이 목표를 정의하였으나 요구되는 속성을 어떻게 만족시킬 수 있을지 모르는 경우가 자주 있음
    • 사용자 자신이 원하는 것이 무엇인지 구체적으로 모르거나 그들의 요구가 어떻게 변경될지 잘 알지 못하는 때도 있음
    • 엔지니어들이 고객의 요구를 불완전하게 이해하고 있는 경우도 있을 수 있음
다음의 경우를 대비해 간단한 시제품을 만들어 보여주는것

원형 패러다임 : 폭포수 모델의 단점을 보완하기 위해 점진적으로 시스템을 개발하여 나가는 접근 방법

  • 특징
    • 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발
    • 발주자나 개발자 모두에게 공동의 찬조모델을 제공
    • 시스템 일부 혹은 시스템의 모형을 만드는 과정으로서 요구된 소프트웨어의 일부를 구현하여, 추후 구현 단계에서 사용될 골격코드가 됨
    • 구축하고자 하는 시스템의 요구사항이 불명확한 경우 시제품을 만들어 사용자 요구사항을 도출할 수 있음
    • 소프트웨어 생명주기에서 유지보수가 없어지고 개발 단계 안에서 유지보수가 이루어지는 것으로 볼 수 있음
    • 시스템 기능을 사용자에게 미리 보여줌으로써 개발자와 사용자간의 오해요소를 줄임
    • 사용자와 개발자 간의 커뮤니케이션이 원활하지 못할 때 서로의 이해에 도움을 줌
    • 실제 개발될 시스템 견본을 미리 만들어 최종 결과물을 예측하는 모형임

  • 개발 순서
    1. 개발팀은 고객 및 사용자와의 대화를 통하여 전반적인 기능을 파악하고 우선 간단히 설계를 한 후 시제품을 만들어 사용자에게 보여줌
    1. 사용자는 시제품을 보고 만들어질 완제품의 모습을 파악함
    1. 사용자는 시제품에 대하여 평가하고, 그 결과는 시제품을 향상시키거나 완제품을 만들어 가는데 반영함

    요구사항 분석 → 시제품 설계 → 시제품 구축 → 고객의 시제품 평가 → 시제품 조정 → 완제품 구현

    • 요구사항의 분석
      • 폭포수 모델의 요구사항 분석단계와 유사함
      • 고객으로부터 받은 일부의 요구사항만 정의하고, 완전치 않은 요구사항에 대하여 윤관을 잡아놓음.
      • 추가적인 정의가 필요한 부분은 시제품이 개발된 후 계속 정제해 나감
    • 시제품 설계
      • 프로토타입에 대한 설계를 함
      • 사용자들이 볼 수 있는 면에 초점을 맞춤
      • 시제품 개발의 목표가 확립되고, 시제품에 포함될 시스템의 기능들이 선택되어짐
      • 시제품에 포함되는 것과 시제품에서 배제되어야 하는 것이 무엇인지 규명하는 것은 중요함
    • 시제품의 구축
      • 일반적으로 성능, 다른 시스템과의 인터페이스 등에 대한 것은 판단하기 어려워 중요하게 다루어지지 않음
      • 오류를 관리하고 다루는 면은 무시되거나 기초 수준정도로 구현함
      • 시제품의 신뢰도와 프로그램 품질 수준은 떨어짐
      • 목표 : 어떻게 하면 시제품을 빨리 만들 수 있겠는가?
    • 고객의 시제품 평가
      • 프로토타입 모형의 가장 중요한 단계라 할 수 있음
      • 시제품은 고객에 의해 평가되고, 개발될 소프트웨어의 요구사항을 구체적으로 조정하기 위해 사용됨
      • 요구사항의 오류를 발견하고, 규명할 수 있으며, 추가되어야 하는 요구사항을 찾아낼 수 있
    • 시제품의 조정
      • 사용자가 원하는 것을 만족시키기 위해 시제품에 대한 조율이 필요함
      • 시제품이 어떻게 고쳐져야 하는지 결정하고, 다음 단계의 시제품이 빠르게 만들어질 수 있도록 함
      • 시제품은 다시 고객에게 평가되는 순환을 하게 되며, 고객이 요구사항에 만족할 때까지 계속됨
    • 완제품 구현
      • 목표 : 원하는 시스템을 개발하는 것
      • 만약 시제품을 버리고 새 시스템을 개발해야 한다면, 완전한 폭포수 모형의 생명주기를 따르거나 4세대 기법(4GT)의 사용이 가능함

  • 장점 및 단점
    • 장점
      • 사용자 요구사항을 충실히 반영
      • 시제품을 통해 시스템의 기능을 사용자에게 먼저 보여줌으로써 개발자와 사용자의 오해가 규명됨
      • 생각하지 못하였던 기능과 서비스가 발견됨
      • 완전하지 못하지만 작동하는 시스템을 만들어 가능성과 유용성을 관리자에게 보여줄 수 있음
      • 프로토타입은 사용자와 개발자 모두에게 공동의 참조모델을 제공함
    • 단점
      • 시제품이 실제 소프트웨어와 차이가 발생할 경우 사용자에게 혼란을 줄 수 있음
      • 단기간에 제작해야 하기 때문에 비효율적인 언어나 알고리즘을 사용할 수 있음
      • 시제품 폐기시 비경제적임
      • 소프트웨어 개발에 많은 시간이 소요되며, 보고서 등 출력물이 많아짐

나선형 모형

  • 개요
    • 보헴이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 새로운 요소인 위험분석을 추가한 모형
    • 나선을 따라 돌듯이 여러번의 소프트웨어 개발과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것

  • 특징
    • 고객과의 의사소통을 통해 계획수립, 위험 분석, 개발, 고객평가의 과정을 거쳐 소프트웨어를 개발함
    • 가장 큰 장점인 위험분석 단계에서 기술과 관리의 위험 요소들을 하나씩 제거해 나감으로써 완성도 높은 소프트웨어를 만들 수 있음
    • 반복적인 작업을 수행하는 점증적 생명주기 모델임
    • 비용이 많이 들거나 시간이 많이 소요되는 대규모 프로젝트나 큰 시스템을 구축할 때 유리함

  • 개발 순서

    계획 및 정의 → 위험분석 → 개발 → 고객평가

    해당 과정을 반복하며 점진적으로 프로그램을 개발

    1. 계획 및 정의
      1. 요구사항을 모으고, 프로젝트 계획을 수립
      1. 나선형 사이클의 시작은 성능, 기능을 비롯한 시스템의 목표를 규명하는 것에서 시작함
      1. 시스템의 목표와 제약 조건에 대한 차선책이 평가, 고려될 수 있음
    1. 위험 분석
      1. 초기 요구사항에 근거하여 위험이 규명됨
      1. 정보를 찾아내는 활동을 통하여 불확실성과 위험을 줄여나갈 수 있음
      1. 프로젝트를 계속 진행할것인지, 또는 중단할것인지 를 결정하는 작업이 이루어짐
    1. 개발
      1. 위험에 대한 평가가 있음 후 이루어짐
      1. 어떠한 패러다임이 적용되어 시스템 개발이 이루어질 것인가 하는 개발모델을 결정함
      1. 시제품을 개발하거나 최종 제품을 만드는 과정이라 볼 수 있음
    1. 고객 평가
      1. 앞의 결과를 사용자가 평가하는 과정임
      1. 고객에 의해 시스템에 대한 평가가 이루어지고, 고객은 시스템의 수정을 요구하기도 함
      1. 엔지니어링의 결과는 시뮬레이션 모델, 시제품 또는 실제 시스템일 수 있음
      1. 고객의 평가에 의하여 다음 결과물을 계획함

  • 장점 및 단점
    • 장점
      • 비용이 많이 들고, 시간이 오래 걸리는 큰 시스템을 구축해 나가는 데 가장 현실적인 접근 방법임
      • 성과를 보면서 조금식 투자하여 위험 부담을 줄일 수 있는 이상적 방법이 나선형 모델임
    • 단점
      • 모델 자체가 앞의 두 모델보다 더 복잡하여 프로젝트 관리 자체를 어렵게 만들 가능성이 많음
      • 많은 고객을 상대로 하는 상업용 제품에 적용하기 힘듦

4GT 모형(4세대 기법)

  • 개요
    • 사용자와 개발자가 쉡게 접근, 사용할 수 있는 CASE를 비롯한 자동화 도구, 4세대 언어등을 이용하여 개발자가 조사한 요구사항 명세서로부터 원시 코드를 자동으로 생성할 수 있게 해주는 모형
    • CASE(Computer-aided Software Engineering)
      • 컴퓨터 프로그램의 개발에서 계획, 문서화까지 모든 공정을 자동화 한 것
      • 공학적 관점에서 구축하기 위해 컴퓨터를 이용하도록 설계된 소프트웨어의 총칭임
      • 컴퓨터 시스템의 응용 프로그램 설계와 작성을 자동화할 수 있도록 도와주는 각종 프로그램, 기법 및 기타 개발 툴이 제공되어 있는 작업환경을 의미함

  • CASE 특징
    • 개발 도구와 개발 방법론이 결합됨
    • 시스템 개발 과정의 일부 또는 전체를 자동화 시킴
    • 정형화된 구조 및 메커니즘을 소프트웨어 개발에 적용하여 소프트웨어 생산성 향상을 구현하는 공학 기법임

  • 4GT 모형의 특징
    • 자연어로 표현하는 4세대 언어를 이용하여 개발자가 조사한 요구사항을 자동으로 구현시키는 비절차적 기법임
    • 설계 단계를 단출할 수 있고, 원시 코드를 자동으로 생성할 수 있음
    • 중 소형 소프트웨어 개발에 사용하면 개발 시간이 감소되지만 대규모 소프트웨어 개발에서는 자동화로 인해 단축된 시간보다 분석, 설계, 단계 등에서 더 많은 시간을 필요로 함

  • 개발 순서

    요구사항 분석 → 설계 전략 → 4세대 언어를 이용한 구현 → 제품

  • 장점 및 단점
    • 장점
      • 설계 단계를 단축할 수 있음
      • 4세대 언어를 사용하므로 원시 코드를 자동으로 생성함
    • 단점
      • 중, 소형 소프트웨어 개발에 사용하면 개발 시간이 감소되지만, 대규모 소프트웨어 개발에서는 자동화로 인해 단축된 시간보다 분석, 설계 단계에서 더 많은 시간을 필요로 함

V모델

  • 개요
    • 폭포수 모델에 시스템 검증과 테스트 작업을 강조함
    • 높은 신뢰성이 요구되는 분야에 적당

  • 장점 및 단점
    • 장점
      • 모든 단계에 검증과 확인 과정이 있어 오류를 줄일 수 있음
    • 단점
      • 생명주기의 반복을 허용하기 않아 변경을 다루기가 쉽지 않음

  • 개발 순서

    요구분석 → 시스템 설계 → 상세 설계 → 코딩 → 단위테스트 → 통합테스트 → 시스템 테스트