13가지 소프트웨어 프로젝트 라이프 사이클 모델 – 소프트웨어 개발방법론 (펌)


게시 목적: 개발 수명 주기 모델들간의 소개 및 비교를 위해

출처: http://lachesis76.blogspot.kr/2011/01/13.html

1. 소프트웨어 라이프사이클 모델이란?

2. 소프트웨어 프로젝트 라이프사이클 모델 소개

2.1 전통적인 폭포수 모델 (Pure Waterfall)
2.2 연어형 폭포수 모델(Salmon Waterfall)
2.3 코딩- 디버깅 모델 (Code-and-Fix)
2.4 나선형 모델 (Spiral)
2.5 사시미 모델 (Sashimi)
2.6 서브프로젝트로 나누어진 폭포수 모델 (Waterfall with Subprojects)
2.7 위험관리를 위한 폭포수 모델 (Waterfall with Risk Reduction)
2.8 진화적 프로토타이핑 모델 (Evolutionary Prototyping)
2.9 단계적 납품형 모델 (Staged Delivery)
2.10 일정에 맞춘 설계형 모델(Design-to-Schedule)
2.11 진화적 납품형 모델 (Evolutionary Delivery)
2.12 도구에 맞춘 설계형 모델 (Design-to-Tools)
2.13 상용화 소프트웨어 구입형 모델 (Commercial Off-the-Shelf)

3. 프로젝트에 적합한 라이프사이클 선택 가이드

참고문헌


1. 소프트웨어 라이프사이클 모델이란?

소프트웨어 라이프사이클 모델이란, 소프트웨어 제품을 생산하기 위해 필요한 모든 활동들을 설명하는 모델이다. 일종의 제품을 개발하는 스타일이라고 할 수 있다. 소프트웨어 라이프사이클 모델은 우리가 소프트웨어 개발을 바라보는 시각이지 소프트웨어를 개발하는 방법이 아니다. 따라서, 제품의 종류가 다를 때는 다른 작업 내용과 작업 순서가 요구된다. 잘못된 라이프사이클을 선택했을 때는 필요한 타스크를 빠뜨릴 수 도 있고, 부적합한 타스크 순서로 진행되어 비효율적이거나 제품의 품질을 저하시킬 수 도 있다.

소프트웨어 라이프사이클 모델은

  • 소프트웨어 개발의 주요 단계를 설명한다.
  • 정의된 단계내에서 수행되어야 하는 주요 기능들을 정의한다.
  • 관리자가 진척사항을 추적하도록 돕는다.
  • 상세한 소프트웨어 개발 프로세스의 정의를 위한 프레임웍을 제공한다.

2. 소프트웨어 프로젝트 라이프사이클 모델 소개

다음은 널리 알려진 13가지의 소프트웨어 프로젝트 라이프사이클 모델의 개념과 특징들에 대하여 설명한다.

2.1  전통적인 폭포수형 모델 (Pure Waterfall)

가.  개요

Winston W. Royce[1970]에 의해 처음 개발된 소프트웨어 개발 라이프사이클 전략으로, 프로젝트를 관리가능한 단계(요구사항, 설계, 구현, 테스트)로 나누고, 마일스톤과 문서화 작업을 수립하며 각단계의 끝마다 리뷰하는 방법이다.

폭포수형 모델은 문서 중심의 모델이다. 이는 즉, 현 단계에서 다음 단계로 이동되는 주요 산출물이 문서라는 것이다. 순수 폭포수 모델에서는 단계들이 연속적이지 않기 때문에 단계들은 오버랩되지 않는다.

2-1-sara7499

< 그림 2-1. 전통적인 폭포수형 라이프사이클 모델 >

나.  장점

      • 프로젝트 라이프사이클 설계에 드는 시간이 짧다.
      • 비교적 경험이 부족한 스태프들을 활용하기에 적합하다.
      • 프로젝트를 관리하기가 쉽다.

다.  단점

    • 프로젝트의 중간 이후 단계에서나 사용자 요구사항에 대한 검증이 가능하다.
    • 단계간 검증시 주로 문서가 사용되므로 요구되는 문서량이 많다.
    • 단계간의 융통성이 적다.

2.2  연어형 폭포수 모델 (Salmon Waterfall)

가.  개요

전통적 폭포수 모델의 변형이다. 연어가 알을 낳기 위해 태어난 곳으로 거슬러 올라 가듯이 소프트웨어 라이프사이클의 이전 단계에서 저질러진 오류를 수정하기 위해 다시 이전 단계에서의 재작업을 허용하도록 하는 것이다.

그러나, 아래의 그림에서 보여 주듯이 맨 아래 단계에서 출발할 때는 연어들이 많았지만 위로 올라갈수록 연어의 숫자는 줄어들고 홀쭉하게 살이 빠져있다. 시스템이 거의 개발되고 나서 발견된 오류를 고치기 위해 요구사항 정의서부터 다시 들여다 보는 일은 가능하지만 그것은 그리 쉽지만은 않다는 것이다. 엄청난 의지와 노력이 필요한 것이다.

2-2-sara7499.jpg

< 그림 2-2. 연어형 폭포수 모델 >

나.  장점

      • 전통적 인 폭포수 모델에 비하여 융통성을 제공한다.
      • 후반의 라이프사이클에서도 전반으로 다시 돌아올 수 있다.

다.  단점

    • 프로젝트 전반부에 참여했던 사람들이 없으면 구현하기 힘들다.
    • 이전 단계로 돌아가기 위해서는 비용이 많이 든다.

2.3  코딩-디버깅 모델 (Code-and-Fix)

가.  개요

이 모델은 소규모의 실험적인 프로젝트나 소프트웨어하우스에서 주로 적용하는 방법이다. 대부분의 앞단계 산출물은 작성하지 않고 곧바로 코딩으로 들어가서 실행하면서 에러를 고쳐나가는 방식이다. 특정한 방법론을 적용하지 않았다면 대개가 코딩-디버깅 모델을 적용했을 것이다.

2-3-sara7499

< 그림 2-3. 코딩-디버깅 모델 >

나.  장점

      • 문서 작성에 드는 오버헤드 시간이 없다. 즉, 계획, 문서작성, 품질보증, 표준준수, 혹은 순수한 코딩이외의 어떠한 작업에도 시간을 들이지 않는다.
      • 고객에게 곧바로 작업의 진행을 보여 줄 수 있다.
      • 방법론에 대한 지식이 없어도 시작할 수 있다.
      • Proof-of-Concept 프로그램이나 프로토타입용과 같이 적은 규모의 코딩에 적합하다.

다.  단점

    • 변경관리가 불가능하다.
    • 일부분을 고치기 위해 개발한 모든 소스를 버리고 다시 개발해야 한다.
    • 개발자가 여러명일 경우 커뮤니케이션이 불가능하다.
    • 고객의 새로운 요구사항을 처리할 수 없다.

2.4  나선형 모델 (Spiral)

가.  개요

이 모델은 저명한 소프트웨어 공학자인 Boehm에의해 1988년 소개된 위험관리를 중요시한 프로젝트 라이프사이클이다.

이 모델에서는 소프트웨어 프로젝트를 작은 프로젝트로 잘게 나눈다. 각각의 미니 프로젝트들은 전체 모든 중요한 위험 요소가 규명될 때까지 하나 혹은 그 이상의 중요한 위험요소를 규명한다. “위험(risk)”의 개념은 여기서는 프로젝트가 처한 상황에따라  광범위하게 정의되며 그것은 완전하게 이해되지 않은 요구사항, 완전하게 이해되지 않은 아키텍처, 잠재적인 수행 에러, 기술에 포함된 문제들을 가리킨다. 중요한 위험요소들이 모두 규명되면 나선형 모델은 종료된다.

아 래의 <그림 2-4>는 나선형 모델을 보여주고 있는데 혹자는 이 모델을 보고 시나몬롤을 연상하게 될 것이다. 이 그림의 이면에는 나선의 중심에서 작은 규모로 시작하여 위험요소들을 알아내고 그 위험요소들을 처리하기 위한 계획을 세우고 그런 다음, 다음 단계를 반복하기 위한 접근 방법을 결정한다. 시나몬롤의 한 원이 돌고나면, 그것이 처음에 원한 것이었는지를 점검해 보고 다음 단계로 넘어간다. 각각의 사이클에는 bold체로 표시된 6개의 단계가 있다.

1. 목표, 대안, 제약사항을 결정
2. 위험요소를 식별하고 해결
3. 대안 평가
4. 하나의 원(cycle)에서 나와야할 산출물을 개발하고 정확한지를 검증
5. 다음 사이클을 계획
6. 다음 사이클을 위한 접근방법 결정

2-4-sara7499.jpg

< 그림 2-4. 나선형 모델 >

나.  장점

      • 위험요 소를 사전에 파악할 수 있다.
      • 비용의 낭비를 줄일 수 있다.
      • 프로토타입을 고객에게 미리 보여주므로 고객에게 빨리 신뢰를 준다.
      • 비용이 증가할 때마다 위험요소는 줄어든다.

다.  단점

    • 고도의 프로젝트 관리 기술이 필요하다.
    • 충분한 이해 없이 적용했을 경우 오히려 역효과를 낼 수 있다.
    • 각 사이클에 대한 범위를 적절하게 정의하기 힘들다.
    • 이 모델을 관리하는 데 적합한 프로젝트 관리 도구가 현재로서는 없다.

2.5  사시미 모델 (Sashimi : Waterfall with Overlapping Phases)

가.  개요

이 모델의 이름은 후지 제록스사의 일본 하드웨어 개발 모델에서 유래되었고, 일본식 회- 슬라이스가 서로 오버랩되어 있는 형태 – 를 가리킨다.

전 통적인 폭포수 모델은 각 단계의 마지막에 리뷰를 통해서 단계간의 아주 적은 오버랩만을 허용했다. 이 모델은 오버랩의 강한 정도를 나타낸다. 예를들면, 프로젝트에서 요구사항 분석이 끝나기 전에 아키텍처 설계단계와 상세설계의 일부분으로 무난히 진입했다고 가정했을 때, 이것은 많은 프로젝트를 위해 합리적일 것이다. 그것은 고지식한 순차적 개발 계획을 가지고 진행할 때는 아주 빈약한 기능을 갖지만 오버랩되는 단계들이 라이프사이클을 통하여 옮겨감에 따라 그들이 하는 일에 대한 중요한 통찰력을 얻게되는 것이다.

2-5-sara7499

< 그림 2-5. 사시미 모델 >

나.  장점

      • 단계가 오버랩되어 있으므로 문서의 양을 줄일 수 있다.
      • 앞 단계의 오류를 빠르게 찾을 수 있다.
      • 순수 폭포수 모델보다는 위험요소의 발견이 앞당겨진다.

다.  단점

    • 마일스 톤은 다소 모호하고, 진행 상황을 정확하게 추적하기가 어렵다.
    • 병행으로 액티비티를 수행하는 것은 의사소통의 오류와 잘못 추정된 가정, 비효율성들을 가져올 수 도 있다.

2.6  서브프로젝트로 나누어진 폭포수 모델 (Waterfall with Subprojects)

가.  개요

이 모델은 아키텍처 설계 이후에 서로 아키텍처가 다른 시스템이 여러개가 도출될 경우 이들 시스템들을 별도로 분리해서 이후 단계를 서브프로젝트들이 병행으로 진행되도록 하는 방식이다.

순수 폭포수 모델의 또 다른 문제점은 상세 설계에 들어 가기전 아키텍처 설계를 모두 완료해야 한다는 것이다. 시스템은 설계에 생소한 분야를 다소 가질 수 있으나, 설계의 대부분은 이미 수차례의 구현을 통해서 익숙한 부분이다. 설계하기 쉬운 분야의 구현이 늦어지는 이유는 어려운 분야의 설계를 기다려야 하기 때문이다. 만약 아키텍처가 논리적으로 독립적인 서브시스템으로 나누어 진다면, 별도의 분리된 프로젝트로 분리할 수 있을 것이다. 분리된 프로젝트들은 각각의 페이스대로 진행될 수 있다.

2-6-sara7499.jpg

< 그림 2-6. 서브프로젝트로 나누어진 폭포수 모델 >

나.  장점

      • 프로젝 트의 기간을 단축시킬 수 있다.
      • 업무 영역별로 최적화된 설계를 할 수 있다.
      • 업무 영역별로 집중화되어 부분적인 품질을 높일 수 있다.

다.  단점

    • 서브프 로젝트간에 예기치 않은 상호 의존성이 발견될 수 있다.
    • 서브시스템간에 인터페이스가 존재할 경우 데이터 통합을 위한 정교한 전략이 마련되지 않을 경우 시스템의 품질이 저하된다.

2.7  위험관리를 위한 폭포수 모델 (Waterfall with Risk Reduction)

가.  개요

폭포수 모델의 약점중 다른 하나는 아키텍처 설계 이전에 요구사항이 완전하게 정의되어야 한다는 것이다. 폭포수형을 약간만 변경하여, 요구사항에 관한 위험을 정의하기 위해 폭포수의 상위 단계에서 위험-감소 나선형 모델을 적용하는 것이다. 여기서는 사용자 인터페이스 프로토타입을 개발한다든지, 시스템 스토리 보딩의 사용, 사용자 인터뷰 실시, 구 시스템과 인터액팅하는 사용자를 보여주는 비디오테입, 그 밖의 당신이 유용하다고 생각되는 다른 요구사항 수집 방법을 사용할 수 있다.

이 러한 위험-감소 나선형 모델은 폭포수 모델의 상위 단계뿐만이 아니라 모든 단계에서도 적용가능하다. 만약 제품이 시스템에서 가장 위험이 많은 핵심을 개발하는데 의존한다면, 프로젝트의 전체 범위에 대하여 실시하기 전에 위험도가 높은 핵심 부분에 대해서 위험-감소 사이클을 적용할 수 있다.

2-7-sara7499.jpg

< 그림 2-7. 위험관리를 위한 폭포수 모델 >

나.  장점

      • 사용자 요구사항을 조기에 확정지을 수 있다.
      • 초기 단계에 사용자의 참여를 강화할 수 있다.

다.  단점

    • 신 기술 적용으로 인한 위험요소를 제거하기에는 적합하지 않다.
    • 설계 이후 단계시 사용자의 참여가 어렵다.

2.8  진화적 프로토타이핑 모델 (Evolutionary Prototyping)

가.  개요

진화적인 프로토타이핑은 프로젝트 동안 점진적으로 시스템 개념을 개발하는 방법이다. 대부분은 시스템의 가장 가시적인 부분을 개발함으로써 시작한다. 고객에게 시스템의 한 부분을 보여주고 고객으로부터 받은 피드백에 기초한 프로토타입을 계속 개발한다. 코딩단계동안 수차례의 프로토타이핑 설명회를 통하여 고객의 요구사항을 점검한다.

진 화적인 프로토타이핑은 요구사항이 빠르게 변한다든지, 프로젝트팀이 고객의 업무에 대해 잘 알지 못할 때, 혹은 프로젝트팀과  고객 모두 어플리케이션 분야에 대해 잘 알지 못할 때 특히 유용하다. 이 모델은 안정하고, 진행 내역이 눈에 보이고, 특히나 개발의 속도가 중요하게 요구되는 곳에서 특히 유용할 수 있다.

2-8-sara7499.jpg

< 그림 2-8. 진화적 프로토타이핑 모델 >

나.  장점

      • 잘못 정의된 요구사항에 의한 오류가 줄어든다.
      • 실행되는 프로토타입을 빨리 보여줌으로써 고객을 안심시킬 수 있다.
      • 개발자가 오류에 대하여 책임져야 하는 부분이 줄어 든다.
      • 유지보수 비용을 줄일 수 있다.

다.  단점

    • 요구사 항 범위관리를 하기가 어렵다.
    • 프로젝트의 최종 산출물을 관리하기가 어렵다.
    • 얼만큼 반복해야할 지 모를 수 있다.
    • Code-and-Fix 모델로 빠지기 쉽다.

2.9  단계적 납품형 모델 (Staged Delivery)

가.  개요

단계적 납품 (staged-delivery) 모델은 계속적으로 보완되는 단계내에서 고객에게 소프트웨어를 보여주는 다른 라이프사이클이다. 진화적인 프로토타이핑 모델과는 달리 이 모델을 사용할 때, 프로젝트팀은 개발하려고 하는 것이 무엇인지를 정확하게 안다. 이 모델이 다른 모델과 다른 것은 프로젝트의 마지막 단계에 갑자기 소프트웨어를 납품하지 않게 하는 것이다. 프로젝트를 통하여 계속적인 단계마다 소프트웨어를 납품하게 된다. 이 모델은 “점진적인 구현” 으로도 알려져 있다.

그 림에 나와 있는 것처럼, 전체 시스템을 개발을 위해 소프트웨어 개념, 요구사항 분석을 정의하고, 아키텍쳐 설계를 작성하는 폭포수 모델 스텝을 진행하게 된다. 그리고 나서 각 단계내에서 상세 설계, 코딩, 디버깅, 테스팅을 계속하게 된다.

이 모델의 주요 장점은 프로젝트팀으로하여금 고객에게 프로젝트의 마지막에 100% 완성된 제품보다는 일찍 고객에게 유용한 기능을 제공할 수 있다는 것이다. 만약, 단계에 대한 계획을 주의깊게 한다면, 가장 빨리 가장 중요한 기능을 제공할 수 있을 것이고, 고객은 그 시점에서부터 그 소프트웨어를 사용할 수 있게 된다.

2-9-sara7499.jpg

< 그림 2-9. 단계적 납품형 모델 >

나.  장점

      • 고객에 게 가장 중요한 기능을 먼저 제공할 수 있다.
      • 장기적인 개발로 인한 프로젝트팀 분위기 침체를 막을 수 있다.

다.  단점

    • 관리와 기술적인 레벨에서 세심한 계획이 없이는 잘 진행되지 않는다.
    • component에 대한 설계가 잘못되어 stage 2에서 계획된 component가 stage 4에서 계획된 component없이는 수행될 수 없을 때 stage 4까지 미루어야 한다.

2.10  일정에 맞춘 설계형 모델 (Design-to-Schedule)

가.  개요

이 모델은 계속되는 stage별로 제품 개발에 대한 계획을 세운다는 점에서 staged-release lifecycle model과 비슷하다. 차이는 마지막에 출시될 outset에 대하여 전부 알 필요가 없다는 것이다. 예를 들어, 5개의 계획된 stage를 가졌을 때, 조정할 수 없는 데드라인이 있기 때문에 세번째 stage만 미리 개발할 수 있을 것이다.

이 라이프사이클은 특정 날짜까지 출시할 제품에 대한 확신을 주는 가시적인 전략이 될 수 있다. 만약 트래이드 쇼를 위한 제품을 제시간에 만들어야 한다든지, 혹은 연말까지, 혹은 다른 시간까지 개발해야 한다면, 이 전략은 유용하다. 이 전략은 중대한 경로에 대해서는 원하지 않는 제품의 한 부분을 위해서 특히 유용하다. 예를 들면, Microsoft Windows operating system은 WordPad, Paint, Hearts 등을 포함하는 몇개의 applet을 포함한다. Microsoft는 Windows의 전체적인 delay를 방지하기 위해 이러한 applet에 대해서 “design-to-schedule”을 적용할 수 있다.

아 래의 그림에서 볼 수 있듯이 이 모델의 중대한 요소중의 하나는 특성들에 우선순위를 부여하고 단계에 대한 계획을 세워 앞의 단계에 높은 우선순위를 가진 특성이 포함되도록 하는 것이다. 나중 단계에는 우선순위가 낮은 특성들을 배치시키는 것이다.

2-10-sara7499.jpg

< 그림 2-10. 일정에 맞춘 설계형 모델 >

나.  장점

      • 제품이 완벽하지 않더라도 시장을 선점하여 고객을 확보할 수 있다.
      • 리소스에 대한 예측을 할 수 있다.

다.  단점

    • 철저한 일정관리가 뒷받침되지 않으면 다음 단계의 출시 계획을 지키기 힘들다.
    • 모든 Stage가 끝나기 전까지 해당 Stage에서 불필요한 요구사항 정의, 아키텍처, 설계를 하는데 시간을 소모하게 된다.

2.11  진화적 납품형 모델 (Evolutionary Delivery)

가.  개요

진화적인 납품은 진화적인 프로토타이핑과 단계별 납품형의 양쪽 특성을 모두 지닌 모델이다. 제품의 한 버전을 개발하고, 고객에게 보여주고, 고객의 반응에 따라 제품을 보완한다. 진화적인 프로토타이핑과 유사하게 얼마나 많이 진화적인 납품을 하는가 하는 것은 순전히 프로젝트팀이 고객의 요구사항을 얼마나 수용할 것인가 하는 계획에 달려 있다. 만약, 프로젝트팀이 고객의 요구사항 대부분을 수용할 거라면, 이 모델은 진화적 프로토타이핑과 매우 유사할 것이다.

진 화적 프로토타이핑과 진화적 납품간의 주요 차이는 기본적인 접근방법보다는 어디에 강조를 두느냐에 더 많은 차이가 있다. 진화적 프로토타이핑에서는, 첫번째 강조를 시스템의 가시적인 측면에 두고, 나중에 다시 돌아가 시스템의 기초가 되는 부분 중 미약한 부분을 보완한다. 진화적인 납품에서는, 고객의 반응에 의해서 바뀌지 않을 시스템의 낮은 레벨의 기능들로 구성된 시스템의 핵심 부분에 먼저 강조를 둔다.

2-11-sara7499.jpg

< 그림 2-11. 진화적 납품형 모델 >

나.  장점

      • 개발과 정에 고객의 참여가 높으므로 중간에 시스템을 변경하기 위한 의사결정 기회를 제공한다.

다.  단점

    • 요구사 항 범위관리를 하기가 어렵다.
    • 프로젝트의 최종 산출물을 관리하기가 어렵다.
    • Code-and-Fix 모델로 빠지기 쉽다.

2.12  도구에 맞춘 설계형 모델 (Design-to-Tools)

가.  개요

이 모델은 특히 시간에 민감한 환경에서만 사용될 수 있는 급진적인 접근방법이다. 도구들이 점점 융통적이고 강력해짐에 따라 – 완전한 어플리케이션 프레임웍, visual programming 환경, 모든 특성을 갖춘 데이타베이스 프로그래밍 환경 – 많은 프로젝트에서 design-to-tools 방법의 사용을 고려할 수 있다.

design-to-tools model의 뒷면에 깔린 생각은 기존에 존재하는 도구에 의해 지원될 때만 제품을 개발하는 것이다. 만약, 도구가 제공하지 않는다면, 취급하지 않는다. 여기서 도구란, code, class libraries, code 생성기, rapid-development language 및 기타, 구현 시간을 극적으로 줄여주는 소프트웨어 도구를 말한다.

아 래의 그림에서 보듯이 이 모델의 결과는 개발자가 생각하는 모든 기능을 제품에 포함시킬 수 없음을 피할 수 없다. 그러나, 만약  도구를 주의깊게 선택했다면, 원하는 대부분의 기능을 구현할 수 있을 것이다. 시간이 제약 조건일 때, 다른 점근 방법으로 충분히 구현할 수 있는 것 보다는 더 많은 전체 기능을 실제적으로 구현할 수 있을 것이다. 그러나, 그것은 도구가 구현을 쉽게 도와 주는 기능이지 고객이 원했던 기능은 아닐 수 도 있다.

이 모델은 다른 융통적인 라이프사이클 모델과 결합될 수 있다. 먼저, 기존의 소프트웨어 도구의 능력을 알아내고, 핵심 요구사항을 알아내고, design-to-tools model이 적합한지를 알아내기 위해 처음에는 나선형 모델을 적용할 수 있다. 그 다음, 일회용 프로토타입을 구현하기 위해 design-to-tools model을 사용하고, 그 도구로 쉽게 구현할 수 있는 지만을 알기 위해 프로토타이핑을 사용할 수 있다. 또한 design-to-tools model을 staged-delivery와, evolutionary delivery, design-to-schedule과도 결합할 수 있다.

2-12-sara7499.jpg

< 그림 2-12. 도구에 맞춘 설계형 모델 >

나.  장점

      • 기술적 으로 검증된 솔루션을 제공할 수 있다.
      • 성숙된 기술을 사용하므로 위험요소를 줄일 수 있다.
      • 개발에 동원할 인력이 풍부하다.
      • 기술 지원 인력이 풍부하다.

다.  단점

    • 소프트 웨어 벤더 – 그들의 제품 전략, 재정적인 안정도 – 에 의존적으로 된다.
    • 정작 고객의 요구사항을 만족시키지 못할 수 있다.

2.13  상용화 소프트웨어 구입형 모델 (Commercial Off-the-Shelf Software)

가.  개요

Off-the-shelf 소프트웨어는 고객의 모든 요구를 거의 만족시키지 못한다. 그러나 Off-the-shelf 소프트웨어는 즉시 사용할 수 있다. 고객이 그 소프트웨어를 살 수 있고 프로젝트팀이 개발한 제품을 납품할 수 있는 중간 시점에 고객은 최소한 몇가지 가치있는 기능을 제공받을 수 있을 것이다.  커스텀 소프트웨어는 대개가 고객이 갖고 있던 이상적인 소프트웨어에 대한 비전에 부합하지 않을 것이다.

2-13-sara7499.jpg

< 그림 2-13. 상용화 소프트웨어 구입형 >

나.  장점

      • 원하는 기능을 제공한다면 적은 비용으로 신속하게 적용할 수 있다.
      • 조직이 갖고 있지 못한 프로세스를 도구를 통해 (예를 들면, SAP-R3, MRP 패키지, etc) 구현할 수 있다.
      • 조직의 프로세스와 독립적인 업무라면 (예를 들면, MS-Office로 할 수 있는 일들) 비용대 효과가 높다.

다.  단점

    • 소프트 웨어 벤더 – 그들의 제품 전략, 재정적인 안정도 – 에 의존적으로 된다.
    • 업무가 확장되면서 소프트웨어와 갭이 생길 경우 활용도가 저하된다.

3.    프로젝트에 적합한 라이프사이클 선택 가이드프로젝트의 상황에 따른  적합한 라이프사이클 선택 가이드를 제시한다.

%ed%94%84%eb%a1%9c%ec%a0%9d%ed%8a%b8-%ec%83%81%ed%99%a9%eb%b3%84-%eb%9d%bc%ec%9d%b4%ed%94%84%ec%82%ac%ec%9d%b4%ed%81%b4

참고문헌


1. Steve McConnell, Rapid Development, Microsoft Press, 1996

2. Alan M. Davis, “Software Life Cycle Models”, Software Engineering Project Management, Second Edition, IEEE Computer Society, 1997

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중