생명주기

대가 산정 (프로젝트 성공률 1% 높이기)

로

소프트웨어 프로젝트 대가 산정

소프트웨어 프로젝트를 수행하면서 필요한 대가 산정에 대해서는 한국소프트웨어산업협회가 매년 발행하는 가이드가 있다. 그 이력이 2012년부터 공식적인 가이드가 제정, 공표되었으니 햇수로 벌써 20년을 훌쩍 넘어서고 있다. 일각에선 현장과 맞지 않는 비현실적 대가라고 말하기도 하지만 이러한 기준이 있기에 그간의 사업 진행도 어떻게든 진행이 되지 않았나 싶다.
 
그러면서 지나온 세월만큼 많은 논의와 고민의 흔적들을 보면서 이 또한 받아들이고 응용해 나아가는 지혜가 필요하지 않나 싶다. 이 가이드는 국가·지방자치단체·국가 또는 지방자치단체가 투자하거나 출연한 법인 또는 기타 공공단체 등(이하 “국가기관 등”이라 한다)에서 소프트웨어의 기획, 구현, 운영 등 수명주기 전체 단계에 대한 사업을 추진하면서 이에 대한 예산 수립, 사업 발주, 계약 시 적정 대가를 산정하기 위한 기준을 제공하는 것을 목적으로 하고 있다.
 
대가 산정 활동은 소프트웨어 프로젝트/사업 전체 생명주기 동안 반복적으로 수행되는 활동으로 발주자나 수주자를 비롯한 다양한 이해관계자들에게 큰 영향을 미치는 중요한 활동이다. 이 가이드를 통하여 사업의 합리적이고 객관적인 대가 산정을 유도하여 프로젝트의 품질을 향상하고 제값 주기 환경을 지속 정착시켜 유관 산업 전반의 경쟁력을 높이는 효과를 거두고자 기대하고 있다.
 
 

대가 산정 가이드 구성

본 대가 산정 가이드는 국가기관 등에서 발주하는 사업에 적용되고 공공부문 사업에 참여하는 공급자도 이를 준용할 수 있도록 개발되었다고는 하나 꼭 이 대상들에만 적용된다고 볼 수는 없으며 그 적용 및 활용 범위는 더 넓다고 할 수 있다. 즉, 이 기준에 따라 각자의 영역과 내용에 따라 이 가이드를 충분히 반영해볼 수 있는 여지가 있는 것이다. 
 
가이드는 또 사용자중심의 활용성을 고려하고 있고 프로젝트 생명주기를 따라 프로젝트관리에서 다루고 있는 기획, 구현, 운영 단계로 크게 체계구성을 하고 있다. 다시 말하면 단순히 구현 단계에서의 대가뿐만 아니라 프로젝트 기획 단계부터 운영 및 데이터베이스 구축 프로젝트에서도 적용해 볼 수 있는 내용을 다루고 있다. 이를 통해 사용자의 주요 업무단계에 따라 대가 산정에서 절차별로 설명하고 있는 것을 참고하여 현장에서의 실무 적용이 용이하도록 하고 있고 표준화하였기 때문에 PM을 포함한 프로젝트 이해관계자들도 이를 좀 더 면밀하게 살피고 공부해야 할 만한 이유가 있다.
 
대가 산정에 대한 방법은 가이드에서 다음의 구성으로 되어 있다.
 
✔️ 대가 산정 방식별 개요
✔️ 절차별 주요 내용
✔️ 단계별 설명
✔️ 주요 산출물
✔️ 관련 법령/규정 등 참고자료 및 유의 사항
✔️ 프로젝트 대가 산정 방식별 사례
 
 

대가 산정 가이드 적용 범위

본 대가 산정 가이드에서는 다양한 대가 산정 모형을 가지고 있다. 이러한 모형들은 하나에 국한되어 있지 않고 그 대상이 되는 사업의 유형과 종류, 시점에 따라 적절한 모형을 선택하여 적용하도록 하고 있다. 이에 따른 사업유형의 식별은 다음과 같다.
 
프로젝트 생명주기와 사업유형

< 프로젝트 생명주기와 사업유형 >

 
 
🚩 기획 단계
: 프로젝트 생명주기 상 기획 단계에 해당하는 사업으로 IT 컨설팅 사업(정보전략계획(ISP), 정보전략계획 및 업무재설계(ISP/BPR), 전사적 아키텍처(EA/ITA), 정보시스템 마스터플랜(ISMP), 정보보안 컨설팅 등)이 있다.
🚩 구현단계
: 프로젝트 생명주기 상 구현단계에 해당하는 사업으로 소프트웨어 개발 사업이 해당한다.
🚩 운영단계
: 프로젝트 생명주기 상 운영단계에 해당하는 사업으로 소프트웨어 유지관리, 소프트웨어 운영 및 소프트웨어 재개발 사업 등이 있다.
 
다음이 대가 산정 시점이다. 이는 대가를 산정하는 시점에 따라 가용한 정보의 양과 상세 정도가 달라지므로 해당 시점에 적합한 대가 산정 모형을 선택하여 사용해야 한다. 
🚩 예산확보 단계
: 프로젝트의 예산을 확보하기 위해 사업비를 개괄적으로 산정하는 단계
🚩 사업발주 단계
: 프로젝트를 발주하기 위해 제안요청서 등을 작성하고 발주금액을 산정하는 단계
🚩 사후정산 단계
: 프로젝트가 종료된 후 사전 산정된 사업비와 집행된 사업비의 차이를 파악하여 필요시 정산을 위한 대가를 산정하는 단계
 
 
그럼 이 대가 산정 모형들에 무엇이 있을까? 그리고 각각의 적용 시점은 어떻게 될까? 아마도 구현단계에 집중된 방식을 많이 접하겠지만 이외의 단계에서도 세부 과정에 따른 산정 방법들이 존재한다.
 
♾️ 기획 단계
   – 정보전략계획(ISP) 및 업무재설계(BPR): (업무량/투입공수) 수립비
   – 전사적 아키텍처(EA/ITA): 수립비
   – 정보시스템 마스터플랜(ISMP): 수립비
 
♾️ 구현단계
   – 소프트웨어 개발: 기능점수방식(정통법/간이법)
 
♾️ 운영단계
   – 유지관리 및 운영: 유지관리비, 운영비(투입공수, 고정비/변동비방식)
   – 재개발: 재개발비
 
 

 

기능점수방식(Function Point)

프로젝트 구현단계에서 주로 쓰이는 기능점수방식은 과거 소스 코드 라인을 카운팅하거나 인력수를 가늠하는 방식들에서 점차 발전하여 현재에 이르렀다. 이는 소프트웨어 개발 규모를 기능점수로 측정하고 기능점수당 단가를 적용하여 비용을 산출한다. 다만 모든 것에 적용할 수는 없는 특별한 경우에는 해당 사업의 과업 내용이나 특징 등을 고려하여 발주자의 판단에 의해 투입공수에 의한 방식도 적용할 수 있다.
 
➰ 기능점수방식 산정: (기능점수 X 기능점수 단가 X 보정계수) + 직접경비 + 이윤
➰ 투입공수방식 산정: (투입인력수 X 투입 기간 X 기술자직무별 단가) + 제경비 + 기술료 + 직접경비
 
기능점수방식은 사용자 관점에서의 사용자가 요구하고 사용자에게 인도되는 기능을 정량적으로 산정하는 소프트웨어 규모 측정 방법으로 ISO/IEC 14143(FSM; Functional Size Measurement)으로 SW Size에 대한 국제표준이며, 소프트웨어 개발, 유지관리 및 운영을 위한 비용과 자원 소요를 산정하는 데 가장 중요한 요소이다.
 
 
기능점수란 사용자 관점에서 측정된 소프트웨어 기능의 양으로서, 사용자에게 제공되는 소프트웨어 기능의 규모를 측정하는 단위이다. 소프트웨어 기능은 사용자 관점에서 갖는 논리적 의미에 따라 크게 데이터 측면의 기능과 트랜잭션 측면의 기능으로 구분된다. 이들을 다시 세분하면 데이터 기능에는 내부 논리파일(ILF)과 외부 연계 파일(EIF)의 2가지 유형이 있으며, 트랜잭션 기능에는 세부적으로 외부 입력(EI), 외부 출력(EO), 외부 조회(EQ)의 3가지 유형이 있다.
 
기능점수방식의 산정 방법은 일반적인 기능점수 산정 방법(정통법)과 평균 복잡도를 적용하는 방법(간이법)의 두 가지이다.
 
✅ 정통법
: 소프트웨어 기능을 도출하고, 각 기능의 유형별 복잡도를 고려, 정확한 기능점수 산정을 필요로 할 경우 사용되는 일반적인 방법으로 통상적으로 소프트웨어 개발 공정상 설계공정 후 사용된다.
✅ 간이법
: 기능의 복잡도를 판단하기 어려운 경우 적용하는 방법으로 계산 절차는 정통법과 동일하나 기능점수 산정 시 기능 유형별 평균 복잡도를 적용하여 기능점수를 산출한다. 통상적으로 기획 및 발주단계에서의 기능점수 측정에 사용된다.
 
 
 
 
※ 숫자가 중요하다
사실 대가 산정은 PM이 아니고선 해볼 일이 많지는 않다. 물론 소규모의 프로젝트에선 어깨너머로 본 숫자들을 만져볼 기회가 있기는 하지만 개발에만 전념하는 개발자들 사이에선 기회도 그렇고 이런 숫자 만지기를 꺼리는 사람도 꽤 있다. 하지만 숫자를 보면 알 수 있는 것들이 정말 많다. 개발도 중요하지만 잠시 눈을 돌려 내 주변을 돌아보면 어떨까? 그러면 적어본 본만큼의 시야가 넓어질 것이다. 정말이지 내가 어디에 와있고 여기서 무슨 일을 하고 있는지도 모르고 그저 열심히만 하고 있지는 않은지? 하늘을 봐야 별을 딴다. 내 별이 어디에 있는지 한번 생각해볼 일이다. 요즘은 더욱 그렇지 아니한가?

프로젝트생명주기 (프로젝트 성공률 1% 높이기)

로

프로젝트 생명주기!

일을 진행하는 과정에 있어서 그 단계와 절차들이 있는데 프로젝트에선 이를 생명주기(life cycle)로 표현하며 여러 단계(phase)를 통합적으로 지칭한다. 프로젝트 수행조직은 하나의 프로젝트를 여러 개의 단계로 구분, 관리하는데 이 단계는 프로젝트의 구성단위로 볼 수 있고 각 단계는 단계별로 중요한 산출물이 완료되는 시점이다. 이러한 단계는 종료 검토를 통해 다음 단계로 진행할 것인지를 결정하고 이 단계들이 모여 최종적인 프로젝트가 완성된다.

모든 프로젝트는 단계로 나눠진다고 이야기했다. 크든 작든 프로젝트와 상관없이 이 단계들은 일정한 생명주기를 가지는데 큰 틀에서는 엇비슷하다고 볼 수는 있으나 크게는 업종에 따라서도 그 내용이 상이하다. 그래서 동종업계의, 유사 프로젝트 성격을 가진 자료들을 바탕으로 이러한 생명주기를 참고하고 갖춰볼 수도 있다. 그러면서 내 프로젝트에 맞게끔 적용하거나 변경할 수 있다.

프로젝트관리 생명주기?

그간 프로젝트, 프로젝트관리, 생명주기 등 각각의 용어에 대해서 알아보았다. 그렇다면 프로젝트관리 생명주기는 무엇인가? 헷갈릴 수도 있지만 앞선 용어들을 참고해서 의미를 생각해 보자. 프로젝트 생명주기가 아닌 프로젝트관리에 대한 생명주기는 관리 절차, 관리프로세스라고 볼 수 있고 이는 각각 착수, 계획, 실행, 감시/통제 및 종료로 구성된다. 아래를 봐보자.

🚩착수
: 프로젝트의 시작이다. 고객이 프로젝트의 발의를 결정하고 수행조직에 전달되어 준비되는 이벤트이다. 첫 시작이기 때문에 이것저것 챙길 것이 많다. 그중에 몇 가지만 추려보면, 프로젝트 요구사항분석, 예비 범위 확인, 일정/예산 산정, 제약조건 확인, 이해당사자 분석, 성과기준 마련, PM 결정과 권한 부여, 팀 꾸리기 등이 있다. 이 모든 예비작업이 정의되고 기술되어 Big Picture로서 프로젝트계획이 수립된다.

🚩계획
: 앞서 그린 큰 그림을 바탕으로 프로젝트를 세세하게 계획한다. 프로젝트 관리계획, 실질적인 범위 기술서, WBS(Work Breakdown Structure), 각각의 액티비티와 우선순위, 기간, 자원할당, 비용산정, 품질계획, 인력/의사소통 관리, 위험관리 등 관리의 추상화 레벨을 내려가며 할 일들을 정리해 나간다. 이 계획들이 빠짐없이 세세하게 구축이 되어야만 프로젝트의 성공률을 끌어올리는 실마리가 될 수 있다.

🚩실행
: 이제 본격적인 활동의 시작이다. 프로젝트 구성원들에 대한 다양한 기초교육을 바탕으로 유관 조직, 기관, 업체들에 대한 선정 내지 작업지시, 본격적인 품질보증 활동을 토대로 도입된 방법론에 따라 지속적이고 점진적인 진행을 시작한다. 어떻게 보면 실행은 전체 프로젝트에서 약 20~30%에 해당하는 단계이다. 나머지 70~80%는 단순하게는 문서 형태로 귀결되는 모든 단계의 활동 산출물들이 담당한다. 근래에 들어 이런 부담을 줄이는 경량화되고 빠른 방법론들이 사용되고 있다. 다만 모든 경우를 포괄하는 것은 아니다.

🚩감시/통제
: 프로젝트의 빅브라더가 해야 할 일이다. 매 단계의 성과를 품질 기반으로 측정하고 진척을 관리한다. 문제가 발생하면 시정조치와 피드백을 받고 그 효과성을 평가하여 프로젝트에 재귀적 반영을 한다. 변경에 민감하며 비용을 통제한다. 위험 유발요인을 집요하게 추적하며 모든 활동을 감시한다. 감시라는 용어가 다소 거부감이 들 수도 있지만 감시가 몇몇 관리자가 하는 행위뿐만 아니라 프로젝트 모든 구성원이 해야 할 일이기에 그렇게 생각할 필요는 없다. 성공하고자 한다면, 성공의 책임은 모든 이해당사자 각각이다.

🚩종료
: 대망의 마무리 단계. 그간의 업무들을 총체적으로 정리, 마감한다. 산출된 결과물들을 고객에게 인도하고 승인을 득하며 프로젝트 전 과정을 통해 배울 것들, Lessons Learned를 문서화하고 공유한다. 점유된 자원들을 하나둘 해제하며 프로젝트는 서서히 끝날 기미를 보이며 종료된다. 완료 평가와 함께 최종 보고를 하고 고객관리 방안과 미결사항 등에 대한 복안을 논하고 오랜 시간의 마침표를 찍는다.

Project Management Lifecycle
< 프로젝트관리 생명주기 >

관리영역들

업무를 하면서 우리 알고 있는 PDS, 즉 Plan – Do – See와 다르게 프로젝트는 시작과 끝에 따라, 여러 특성과 환경 등에 따라 그 생명주기는 각기 다르다. 그래서 앞선 5가지는 세부적으로 여러 가지 프로세스들로 구성되어 있다. 이는 흔히 PMBOK(Project Management Body of Knowledge, 현재 7판)이나 SWEBOK(Software Engineering Body of Knowledge, 현재 4판)등에 자세히 나와 있다. 프로젝트에서 이것을 모두 활용하기엔 다소 무리가 있고 그중 가장 핵심적인 단계들만이라도 제대로 관리한다면 프로젝트 성공률은 높아질 수 있다. 세세한 내용은 차차 다루기로 하고 여기서 알아 둘 것은 크게 두 가지이다. 프로젝트 목표 달성을 위한 Core 프로세스는 원가, 일정, 범위 단계, 그리고 목표 달성을 위한 수단으로써의 Facilitating 프로세스는 품질, 인력, 의사소통, 위험, 아웃소싱단계가 그것이다.

 

※ 한곳을 향해.
PM은 프로젝트를 성공적으로 완수하고 싶다. 격하게 하고 싶다. 그래서 나름의 넘치는 욕심과 의욕으로 시작하지만 높고 낮은 벽들에 계속 부딪히고 싸우면서 점점 의기소침해지고 소극적으로 변하며 전의를 잃기도 한다. 이때 무엇이 필요할까? 멘털이다. 멘털을 잘 붙들어 매어야 나 자신을 지킬 수 있다. 그리고 이걸 옆에서 지켜보는 구성원들은 PM을 이해하고 지지해줘야 한다. 설사 내부 총질(!?)을 해대는 상황이 발생할지라도 그건 나중 일이다. 팀은 왜 존재하는가?

소프트웨어 생명주기 (소프트웨어 공학)

로

소프트웨어 생명주기 – Software Development Life Cycle

소프트웨어 공학의 목표는 “좋은 품질 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하는 것“이다. 즉 품질과 생산성이라는 명확한 두 가지 목표를 위하여 소프트웨어 공학은 지속 발전하고 있다. 이 발전의 중심에는 생명주기가 있다. 소프트웨어도 생명체처럼 자라고 성숙하고 쇠퇴하는 단계가 있다. 아무리 잘 개발된 소프트웨어라도 계속 변경되고 새로운 기능이 추가되며 사용되다가 어느 순간 소멸의 때를 맞이하게 된다. 

이러한 소프트웨어를 개발하는 과정은 생명주기 측면에서 보통 요구 분석, 설계, 구현, 테스트 및 설치 인도 등 과정을 거친다. 매 과정의 단계는 각기 범위와 해야 할 항목들이 정해져 있으며 하나의 단계가 마무리되면 다음 단계로 넘어가는 분명한 기준을 가지고 있다. 이런 일련의 프로세스들은 하나의 모형으로 제안되었으며 여러 모형이 SDLC로서 나와 있다. 

 




종류

SDLC는 소프트웨어 개발 프로세스를 가이드하는 구조화된 접근 방식으로서 여러 모델이 있으며 각각의 모델들은 모두 고유한 특징과 장단점을 가지고 있다. 

🚩 폭포수(Waterfall) 모델
: 순차적 프로세스를 따르고 각 단계가 완료되어야 다음 단계로 넘어갈 수 있는 선형적 접근법이다. SDLC의 원형에 가까우며 가장 오랜 역사를 지니고 있으며 산업계의 표준과도 같이 사용된다. 이 모델은 사용자의 의견이 상이하거나 중간 결과 점검에 따라 전 단계의 작업에 결함이 있다면 다시 수정하기 위해 전 단계로 돌아가는 피드백이 있다. 이 모델은 응용 분야가 단순하거나 잘 알고 있는 경우, 사용자 요구사항을 이미 잘 알고 있으며 연구 중심의 문제를 다루는 개발에 적합하다. 또한 생명주기 전반에 걸쳐 변경이나 진화가 예상되지 않는 비교적 위험이 적은 프로젝트에 알맞다.

  • 간단하고 이해하기 쉬움
  • 명확하고 잘 정의된 요구사항이 있는 소규모 프로젝트에 적합
  • 문서화가 잘되어 있어 유지 관리가 쉬움
  • 단계가 완료 시 변경 불가
  • 요구 사항 변경 직면 시 모델 적응력 저하
  • 긴 개발 주기로 인해 최종 사용자의 피드백 지연 가능

🚩 프로토타입(Prototyping) 모델
: 초기 요구 사항을 바탕으로 프로토타입을 개발하여 고객의 피드백을 받고 개선하는 과정을 계속 반복한다. 소프트웨어 개발은 전문가가 아닌 고객/발주자의 입장에서는 블랙박스에 가깝다. 이에 프로젝트의 실현 가능성은 보장받는 일이 묘연하다. 이런 경우 이 모델이 매우 적합할 수 있다. 프로토타이핑이란 시스템의 일부 혹은 시스템 모형이 될 만한 것을 만드는 과정이며 이를 시뮬레이션하여 사용자가 볼 수 있는 반응을 미리 보여준다.

  • 사용자 요구사항을 정확하게 파악하여 빨리 최적화 개발 가능
  • 고객은 완성 시스템을 사전에 확인하고 요구사항을 수정할 수 있음
  • SDLC 내 유지보수가 없어지고 개발 단계 내 유지보수 가능
  • 고객이 프로토타입을 최종 결과라고 믿고 곧 개발이 완료될 것이라는 오해 소지
  • 관리가 쉽지 않음
  • 완전한 문서화 어려움

🚩 나선형(Spiral) 모델
: 소프트웨어 개발 프로세스는 위험 관리 측면에서 매우 중요하다. 이는 개발 계획 및 요구사항 분석 후 각종 위험 요소와 차선책에 대해서 검토하는 단계를 필수로 갖는다. 이를 통해 프로젝트 초기 실패 요인과 위험 요소를 찾아내어 대비하는 것인데 이 모델은 이를 만족시킨다. 즉 반복과 폭포수 모델이 결합한 형태로 증분/진화모델과 함께 중요한 위치를 차지한다. 이 모델은 재정적 또는 기술적으로 위험 부담이 큰 경우 위험분석을 지속하면서 시스템을 발전시켜 나가는 데 적합하다. 

  • 개발 프로세스 전반에 걸쳐 위험 평가 및 관리 강조
  • 일련의 나선형으로 주기마다 소프트웨어를 반복적 구축
  • 개발 프로세스 초기에 위험 식별 및 완화 허용
  • 반복적 특성으로 인해 시간과 비용 과다 소요
  • 위험을 효과적으로 평가하고 관리하려면 숙련된 관리 필요
  • 익숙하지 않은 방법으로 적용에 어려움

🚩 V 모델
: 폭포수 모델에 시스템 검증과 테스트 작업을 강조한 모델이다. 이는 코딩단계를 중심으로 각 단계가 V자 모양의 대칭구조를 이루고 있다. 모듈의 상세 설계를 단위 테스트 과정에서 검증하고 시스템 설계는 통합 테스트 단계에서, 사용자 요구사항은 시스템 테스트 단계에서 검증한다. 또한 이러한 검증을 통해 오류가 발견된다면 요구분석, 설계, 코딩 단계로 되돌아갈 수 있는 모델이다. 이 모델은 무엇보다도 높은 신뢰성이 필요한 의료, 제어 시스템이나 원전 시스템 등의 분야에 적합하다.

  • 각 단계에서 확인 및 확인의 중요성 강조
  • 각 단계에서 광범위한 테스트로 인해 고품질의 소프트웨어 보장
  • 요구 사항과 테스트 사례 간의 추적 가능성 설정
  • 요구 사항의 변화에 ​​적응력 저하
  • 각 단계에서 광범위한 테스트로 인한 시간 소요
  • 개발 중 제한된 고객 참여

🚩 Agile(애자일) 모델
: 소프트웨어 개발 프로세스를 일정 크기의 작은 단위로 개발, 검증 및 수정 과정을 여러 차례 반복적이고 점진적인 개발 접근 방식이다. 이를 통해 협업을 원활히 하고 업무의 적응성과 고객의 피드백에 중점을 둔다. 또한 스프린트라고 하는 잠재적인 출하 가능한 제품에 대한 증분 형태를 제공하는 방식을 지속 반복한다. 이 모델은 프로젝트에 대한 초기 비용 추정이 다소 어려워 대규모 프로젝트보다는 빠른 응답성을 요구하는 프로젝트에 요긴하게 적용할 수 있다.

  • 변화하는 요구 사항에 유연하고 적응력 높음
  • 빈번한 고객 피드백을 통해 지속적인 개선 가능
  • 정기적으로 작동하는 소프트웨어를 제공하여 귀중한 기능을 조기 배포 가능
  • 팀원 간의 강력한 협업과 의사소통 필요
  • 크고 복잡한 프로젝트를 관리하기 어려움
  • 지속적인 변화는 효과적으로 관리되지 않으면 범위 증가 가능성

 




인기

최근에 가장 많이 사용되는 SDLC는 애자일 모델이다. 애자일 방법론은 기존 전통적인 개발 방식과는 달리 민첩하게 변화에 대응할 수 있는 개발 방식을 제공하며 요구사항의 변화에 적절하게 대처할 수 있는 작은 주기로 개발을 진행한다. 이는 요구 사항을 빠르게 반영, 개발의 품질과 고객 만족도를 높일 수 있는 장점이 있어서 대부분의 소프트웨어 개발 프로젝트에서 애자일 방법론을 많이 적용하고 있다. 하지만 모델 하나만으로 모든 것을 만족할 수는 없다. 현장과 업계는 끊임없이 진화하고 있으며 지속해서 새로운 방법론이나 변형들이 등장하고 있다. 

이는 한 상황에 충족되지 않는 부분들을 서로 다른 모델들을 결합하여 진행할 수도 있다. 다시 말해 SDLC는 필수적 요소이기는 하나 프로젝트 규모, 복잡성 및 각종 특성 등에 따라 적절한 방법을 선택해야 한다. 이를 통해 빠른 개발 속도, 높은 사용자 만족 및 프로젝트 성공률을 보장받을 수 있는 모델들이 선호되고 있다. 근래에는 특히 개발조직뿐만 아니라 운영조직 간의 긴밀한 협업이나 AI 등을 활용한 자동화에도 중점을 두며 발전되어 나가고 있다. 다만 SDLC를 따르더라도 프로젝트의 위험을 최소화하기 위해 지속해서 프로젝트를 모니터링하고 이에 응당한 조처를 해야 한다.