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

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

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

 

종류

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

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

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

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

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

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

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

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

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

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

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

 

인기

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

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