SDLC(Systems Development LifeCycle)
소프트웨어를 개발하기 위한 일련의 절차입니다. 소프트웨어를 만들고, 유지하기 위해서는 많은 공정들이 필요한데 이에 대한 전체 과정을 하나의 생명 주기로 정의하여 각 단계 별 공정을 체계화한 모델입니다. '주기'라는 단어에 맞게 프로세스가 한 번으로 끝나지 않고 목표하는 소프트웨어의 품질에 도달 할때까지 순환되는 고리 형태를 가집니다.
등장배경
컴퓨터 기술의 발전에 따라 다양해지는 고객의 요구사항을 만족시키기 위해 소프트웨어는 기존보다 많은 기능이 필요해졌고, 이는 곧 소프트웨어의 대규모화를 야기했습니다. 소프트웨어의 규모가 커짐에 따라 개발의 복잡성과 시간적인 비용도 당연히 상대적으로 늘어났으며, 이를 해결하기 위해 체계적인 개발 프로세스가 필요했습니다.
필요한 이유?
일련의 프로세스를 통해 개발 간 각 단계를 세밀하게 분석할 수 있습니다. 이는 각 단계에서 효율성을 극대화하는데 도움이 되며 곧 비용 절감과 빠른 피드백, 높은 생산성으로 이어져 고객의 요구를 빠르게 충족시킬 수 있습니다. 즉, SDLC는 비효율성과 더 높은 비용을 식별하고 원할하게 실행되도록 수정하여 이러한 목표를 달성하기 위한 모델이라고 할 수 있습니다.
구성
일반적으로 요구사항 분석 → 디자인 → 설계 및 구현→ 문서화 및 테스트 → 배포 → 유지관리의 형태를 가지며 프로젝트 관리자는 프로젝트의 범위나 규모에 따라 단계를 결합, 분할 또는 생략하여 6~8단계로 만들어집니다. 이는 현재 모든 소프트웨어 개발 프로젝트에 표준으로 자리잡았습니다.
구성-A. 계획
프로젝트 리더는 인건비 및 재료비 계산을 비롯해 프로젝트 조건을 평가하여 목표가 설정된 일정표를 구성합니다. 계획에는 소프트웨어와 관련된 다양한 이해 관계자들의 피드백도 포함되며 소프트웨어가 갖추어야할 기능과 비즈니스의 타당성을 검토 하고 목표를 설정합니다. 그리고 프로젝트의 범위를 넘어서 확장되거나 바뀌지 않도록 프로젝트의 경계를 명확히 해야합니다.
구성-B. 요구 사항 분석/시스템 명세
프로젝트 관리자는 응용 프로그램이 수행해야 하는 작업과 요구 사항을 결정합니다. 개발에 앞서 모호성은 이 단계에서 모두 해결되어야 하며 소프트웨어의 목적, 기능, 과정과 발생할 이슈 등을 규정하고 문서화하여 이해관계자들에게 승인을 받아야 합니다. 요구 사항이 명확하게 이해되면 SRS(Software Requirement Specification)문서를 작성합니다.
구성-C. 디자인/구조 설계
SRS문서의 요구 사항을 기반으로 디자인과 소프트웨어 설계를 진행합니다. 이 단계에서는 아키텍처를 비롯한 통신, 보안, 기술 스펙등을 정의합니다.
구성-D. 구현
설계된 내용을 프로그래밍 언어로 표현하며 소스 코드가 생성됩니다. 소프트웨어의 규모에 따라 한 명의 개발자 또는 여러 팀의 협업 형태로 진행되며, 개발자 모두가 합의된 하나의 청사진을 고수해야합니다.
구성-E. 테스트
소프트웨어를 출시 하기전에 사전 테스트를 진행합니다. 고객의 요구 사항을 충족하는지, 소프트웨어의 각 부문이 문제없이 상호작용 하는지, 생각하지 못한 결함은 없는지 등을 전반적으로 확인함으로써 추후 사용자가 소프트웨어를 사용할 때 발생될 수 있는 버그를 줄아고 사용률을 높이며 만족도를 개선합니다.
구성-F. 배포
테스트를 통과하면 소프트웨어가 배포되어 사용자에게 제공됩니다. 이 때, 조직에 따라서 사용자가 사용할 수 있는 프로덕션 환경 뿐만 아니라 개발과 스테이징같은 다양한 배포 환경을 갖추기도 합니다. 배포 프로세스는 소프트웨어의 복잡성과 요구 사항에 따라 수/자동화 될 수 있습니다.
구성-G. 유지 보수
소프트웨어가 출시 되었지만 사용자가 테스트 중에 발견하지 못한 버그를 발견할 수 있습니다. 이슈의 심각도에 따라 핫픽스를 하거나 다음 릴리스에서 수정합니다. 또한, 추가 기능을 계획하여 새로운 개발 주기를 시작할 수 있습니다.
방법론
소프트웨어 개발에는 여러가지 접근 방식이 있으나, 접근 방식이 조금씩 다를 뿐 기본 단계와 활동은 동일합니다. 프로젝트 관리자는 프로젝트의 목표와 규모에 따라 또, 시장 환경에 따라 적절한 방법론을 채택하여야 하며 이는 추후 프로젝트의 성공 여부를 좌지우지할 수 있는 근간이 됩니다.
방법론-A. Waterfall
가장 오래되고 원시적인 방법입니다. 이 방법은 각 단계가 완전히 완료되어야만 다음 단계를 진행하는 완전 동기적 방식입니다. 해당 모델 적용에 대한 성공 사례가 많고 각 단계의 연속성과 실행 가능성을 온전하게 평가할 수 있다는 장점이 있으나, 이전 단계가 완료되기 전에는 다음 단계로 넘어갈 수 없다는 단점 또한 가지고 있습니다. 그리고 과정 사이에 요구 사항에 대한 수정이 생긴다면 처음부터 다시 진행해야 하기때문에 요구사항이 명확하고 변경 가능성이 적을 때 유리한 모델입니다. 사용자의 요구사항이 급변하고 시장 경제가 불안한 현재 시점에서는 조금 부적절한 방법론이라고 할 수 있습니다.
방법론-B. Agile
가장 인기 있는 방법론중 하나이며, 작고 빠른 단계로 소프트웨어 개발을 촉진합니다. 애자일 방식은 기업이 사용자에게 더 자주 업데이트를 릴리스할 수 있도록 하는 소프트웨어의 지속적인 반복을 기반으로 합니다. 폭포수의 경우 미래에 발생할 수 있는 모든 요구 사항에 대한 자세한 개요를 만들고 예측된 모든 요구 사항을 충족 하도록 소프트웨어를 설계해야 하므로 개발 프로세스에 시간이 많이 걸린다면, 애자일은 기업이 필요한 변경 범위를 결정하고 분석 -> 설계 -> 개발 -> 테스트의 단계를 거칩니다. 이를 통해 팀은 단일 주요 업데이트를 릴리스 하는 대신 작은 변경 사항을 프로덕션에 릴리스 할 수 있습니다. 애자일의 라이프 사이클에 대한 주기를 스프린트라고 지칭하며 14일 ~ 30일 사이로 기업마다 다르게 적용됩니다. 애자일 수명 주기는 지속적인 소프트웨어 결과물, 지속적인 프로젝트 개선, 즉각적인 업데이트 및 신속한 개발에 기여하도록 설계되어 적시 개발 및 제공을 가능하게 해주며, 끊임없이 변화하는 고객 요구 사항과 함께 빠르게 변화하는 환경에서 소프트웨어 개발에 대한 유연한 접근 방식을 제공합니다. 결과적으로 애자일 방법론은 MVP(Minimum Viable Product)를 빠르게 제공할 수 있도록 해주는 모델입니다.
방법론-C. Iterative
반복 프로세스는 연속적인 개선을 통해 점진으로 소프트웨어의 품질을 향상 시켜나가는 방법입니다. 즉, 개발자는 빠르게 초기 버전(프로토 타입)을 만들고 추후 반복으로 검토하며 부족한 기능을 추가하고 개선해나갑니다. 반복 프로세스는 곧 증분형과 진화형. 애자일 방식과 비슷하게 순환적 방식을 가지지만 반복적 방법론은 '계획'이 반영되지 않고 요구 사항에 대한 개발 부분에 한정됩니다. 즉, 애자일이 전체적인 프로세스에 대한 순환이라면 반복 프로세스는 전체 범주 내의 특정 단위를 반복해서 작업합니다.
방법론-D. V-Shaped
프로세스가 V형태로 순차적으로 실행되는 방법론으로, 검증 및 검증 모델이라고도 합니다. 폭포수 모델의 확장이며 각 개발 단계에 대한 테스트 단계의 연결을 기반으로 하며, 이전 단계가 완료된 후에만 다음 단계로 진행됩니다. 따라서 제품 자체가 안정적인 장점은 있으나 폭포수와 동일하게 변경 사항에 취약하므로 요구 사항이 명확하고 변동 가능성이 적을떄 유용한 모델입니다.
요구사항 분석
- 고객의 관점에서 제품 요구 사항을 이해하며, 고객과의 자세한 의사소통이 포함됩니다.
시스템 설계
- 아키텍처 사양을 설계하며, 하나 이상의 기술적 접근 방식이 제안됩니다.
- 시스템은 곧 세부적인 모듈로 설계되며, 이를 HLD(High Level Design)이라고 합니다.
- 내부 모듈과 외부 시스템 간의 데이터 전송 및 통신 방식이 정의됩니다.
모듈 설계
- 시스템 모듈에 대한 내부 설계가 지정되며, 이를 LLD라고 합니다.(Low Level Design)
- 모듈은 상위 HLD와 호환되는 것이 중요하며 모든 개발 프로세스의 필수적인 부분입니다.
단위 테스트
- 모듈 설계 단계에서 설계된 테스트로, 코드 수준의 테스트입니다.
- 초기 단계에서 버그를 잡을 수 있지만, 단위 테스트로 모든 결함을 발견할 수 없습니다.
통합 테스트
- 시스템 내 내부 모듈의 공존 및 통신을 테스트합니다.
- 대부분의 소프트웨어 및 하드웨어 호환성 문제는 이 시스템 테스트 실행중에 발견할 수 있습니다.
수락 테스트
- 비즈니스 요구 사항과 비교하여 사용자 환경에서 제품을 테스트합니다.
- 사용자 환경에서 사용 가능한 다른 시스템과의 호환성을 확인하고, 부하 및 성능 결함과 같은 비기능적 문제를 발견합니다.
방법론-F. Spiral
폭포수 모델의 순차 프로세스와 함께 프로토타입 그리고 반복 프로세스를 혼합한 모델입니다. 폭포수와 동일한 단계를 사용하지만, 추가 계획과 위험 평가, 프로토타입 또는 반복이 동반됩니다. 즉, 폭포수의 순차적 방식에 '위험 분석'과 '프로토타입'이 추가되며, 평가 단계에서 반복 여부를 결정하여 반복적으로 프로세스를 진행하여 소프트웨어를 완성/개선합니다. 나선형 모델은 비용이 많이 들지만 크고 복잡한 시스템에서 높은안정성을 제공하는 것이 특징입니다.
방법론-G. ProtoTyping
프로토타이핑 모델은 고객에게 피드백을 받기 위한 소프트웨어의 초기 모델(MVP)을 만드는데 중점을 둡니다. 즉, 변칙적인 고객의 요구 사항에 맞추는게 핵심입니다. 프로토타입 방식으로 빠르게 결과물을 만들 수 있지만 완성도는 떨어지는게 특징이며, 고객의 피드백 결과에 따라 기존 코드를 '폐기'하는 방법과 기존 코드를 개선해나가는 '진화'적 방식을 선택하여 반복합니다.
'Development Log > Knowlege' 카테고리의 다른 글
| 처음부터 끝까지, 종단 간 테스트(E2E) (0) | 2022.08.28 |
|---|---|
| 클라우드 서비스(IaaS, PaaS, SaaS) (1) | 2022.08.24 |
| 헷갈리는 WS와 WAS (1) | 2022.08.23 |
| 버전을 의미있게, Semanctic Versioning (1) | 2022.08.23 |
