sdlc phases
소프트웨어 개발 수명주기 (SDLC) 란 무엇입니까? SDLC 단계, 방법론, 프로세스 및 모델 알아보기
SDLC (Software Development Life Cycle)는 각 단계에서 소프트웨어 개발과 관련된 단계를 정의하는 프레임 워크입니다. 소프트웨어 구축, 배포 및 유지 관리에 대한 세부 계획을 다룹니다.
SDLC는 전체 개발주기, 즉 소프트웨어 제품의 계획, 생성, 테스트 및 배포와 관련된 모든 작업을 정의합니다.
학습 내용 :
소프트웨어 개발 라이프 사이클 프로세스
SDLC는 고품질 제품을 제공하기위한 소프트웨어 개발과 관련된 다양한 단계를 정의하는 프로세스입니다. SDLC 단계는 소프트웨어의 전체 수명주기 (예 : 제품 시작부터 폐기까지)를 다룹니다.
SDLC 프로세스를 준수하면 체계적이고 규칙적인 방식으로 소프트웨어를 개발할 수 있습니다.
목적:
SDLC의 목적은 고객의 요구 사항에 맞는 고품질 제품을 제공하는 것입니다.
SDLC는 요구 사항 수집, 설계, 코딩, 테스트 및 유지 보수로 단계를 정의했습니다. 체계적인 방식으로 제품을 제공하려면 단계를 준수하는 것이 중요합니다.
예를 들어, 소프트웨어를 개발하고 팀을 나누어 제품의 기능을 작업하고 원하는대로 작업 할 수 있어야합니다. 개발자 중 한 명은 먼저 디자인하기로 결정하고 다른 한 명은 문서 부분에서 먼저 코딩하기로 결정합니다.
이는 예상되는 제품을 제공하기 위해 팀원들간에 좋은 지식과 이해가 필요하기 때문에 프로젝트 실패로 이어질 것입니다.
SDLC주기
SDLC Cycle은 소프트웨어 개발 프로세스를 나타냅니다.
다음은 SDLC주기의 다이어그램 표현입니다.
SDLC 단계
다음은 다양한 단계입니다.
- 요구 사항 수집 및 분석
- 디자인
- 구현 또는 코딩
- 테스팅
- 전개
- 유지
# 1) 요구 사항 수집 및 분석
이 단계에서 모든 관련 정보는 고객의 기대에 따라 제품을 개발하기 위해 고객으로부터 수집됩니다. 모호성은이 단계에서만 해결되어야합니다.
비즈니스 분석가와 프로젝트 관리자는 고객이 무엇을 만들고 싶은지, 누가 최종 사용자가 될지, 제품의 목적이 무엇인지와 같은 모든 정보를 수집하기 위해 고객과의 회의를 마련했습니다. 제품을 구축하기 전에 제품에 대한 핵심적인 이해 또는 지식이 매우 중요합니다.
예를 들어, 고객이 돈 거래와 관련된 애플리케이션을 갖고 싶어합니다. 이 경우 어떤 종류의 거래를 할 것인지, 어떻게 할 것인지, 어떤 통화로 할 것인지 등의 요구 사항이 명확해야합니다.
요구 사항 수집이 완료되면 제품 개발의 타당성을 확인하기위한 분석이 수행됩니다. 모호한 경우 추가 논의를 위해 호출이 설정됩니다.
요구 사항이 명확하게 이해되면 SRS (Software Requirement Specification) 문서가 작성됩니다. 이 문서는 개발자가 완전히 이해해야하며 향후 참조를 위해 고객이 검토해야합니다.
# 2) 디자인
이 단계에서는 SRS 문서에 수집 된 요구 사항을 입력으로 사용하고 시스템 개발을 구현하는 데 사용되는 소프트웨어 아키텍처를 도출합니다.
# 3) 구현 또는 코딩
개발자가 디자인 문서를 받으면 구현 / 코딩이 시작됩니다. 소프트웨어 디자인은 소스 코드로 번역됩니다. 소프트웨어의 모든 구성 요소는이 단계에서 구현됩니다.
이중 연결 목록 자바를 만드는 방법
# 4) 테스트
코딩이 완료되고 테스트를 위해 모듈이 출시되면 테스트가 시작됩니다. 이 단계에서는 개발 된 소프트웨어를 철저히 테스트하고 발견 된 모든 결함을 개발자에게 할당하여 수정합니다.
재 테스트, 회귀 테스트는 소프트웨어가 고객의 기대에 맞는 시점까지 수행됩니다. 테스터는 SRS 문서를 참조하여 소프트웨어가 고객의 표준에 맞는지 확인합니다.
# 5) 배포
제품이 테스트되면 프로덕션 환경에 배포되거나 UAT (사용자 수락 테스트) 고객의 기대에 따라 이루어집니다.
UAT의 경우 프로덕션 환경의 복제본이 생성되고 개발자와 함께 고객이 테스트를 수행합니다. 고객이 예상대로 애플리케이션을 찾으면 고객이 사인 오프를 제공하여 활성화합니다.
# 6) 유지 보수
제품을 프로덕션 환경에 배포 한 후 제품 유지 관리, 즉 문제가 발생하여 수정해야하거나 개선이 필요한 경우 개발자가 관리합니다.
소프트웨어 개발 수명주기 모델
소프트웨어 수명주기 모델은 소프트웨어 개발주기를 설명하는 표현입니다. SDLC 모델은 접근 방식이 다를 수 있지만 기본 단계와 활동은 모든 모델에서 동일하게 유지됩니다.
# 1) 폭포 모델
폭포 모델 SDLC에서 사용되는 최초의 모델입니다. 선형 순차 모델이라고도합니다.
이 모델에서 한 단계의 결과는 다음 단계의 입력입니다. 다음 단계의 개발은 이전 단계가 완료된 경우에만 시작됩니다.
- 먼저 요구 사항 수집 및 분석이 완료됩니다. 요구 사항이 동결되면 시스템 디자인 만 시작할 수 있습니다. 여기에서 생성 된 SRS 문서는 요구 사항 단계의 출력이며 시스템 설계에 대한 입력 역할을합니다.
- 시스템 설계 소프트웨어 아키텍처 및 설계에서는 구현 및 코딩과 같은 다음 단계의 입력 역할을하는 문서가 생성됩니다.
- 구현 단계에서 코딩이 완료되고 개발 된 소프트웨어가 다음 단계, 즉 테스트의 입력이됩니다.
- 테스트 단계에서는 개발 된 코드를 철저히 테스트하여 소프트웨어의 결함을 감지합니다. 결함은 결함 추적 도구에 기록되고 수정되면 다시 테스트됩니다. 버그 로깅, 재 테스트, 회귀 테스트는 소프트웨어가 가동 상태가 될 때까지 계속됩니다.
- 배포 단계에서 개발 된 코드는 고객이 사인 오프 한 후 프로덕션으로 이동됩니다.
- 프로덕션 환경의 모든 문제는 유지 관리중인 개발자가 해결합니다.
폭포수 모델의 장점 :
- 폭포 모델은 쉽게 이해할 수있는 간단한 모델로 모든 단계가 단계적으로 수행되는 모델입니다.
- 각 단계의 결과물이 잘 정의되어 있으므로 복잡하지 않고 프로젝트를 쉽게 관리 할 수 있습니다.
폭포수 모델의 단점 :
- 폭포수 모델은 시간이 많이 걸리며이 모델에서는 진행중인 단계가 완료 될 때까지 새 단계를 시작할 수 없으므로 단기간 프로젝트에서 사용할 수 없습니다.
- 폭포 모델은 요구 사항이 불확실하거나 요구 사항이 계속 변경되는 프로젝트에 사용할 수 없습니다. 모든 단계에서 변경이 필요합니다.
# 2) V 형 모델
V- 모델 검증 및 검증 모델이라고도합니다. 이 모델에서는 검증 및 검증이 함께 진행됩니다. 즉, 개발과 테스트가 병행됩니다. V 모델과 폭포수 모델은 V-Model에서 테스트 계획 및 테스트가 초기 단계에서 시작된다는 점을 제외하면 동일합니다.
a) 검증 단계 :
(i) 요구 사항 분석 :
이 단계에서는 필요한 모든 정보가 수집 및 분석됩니다. 검증 활동에는 요구 사항 검토가 포함됩니다.
(ii) 시스템 설계 :
요구 사항이 명확 해지면 시스템이 설계됩니다. 즉, 아키텍처, 제품의 구성 요소가 생성되고 설계 문서에 문서화됩니다.
(iii) 고급 설계 :
고수준 설계는 모듈의 아키텍처 / 설계를 정의합니다. 두 모듈 간의 기능을 정의합니다.
(iv) 저수준 설계 :
저수준 디자인은 개별 구성 요소의 아키텍처 / 디자인을 정의합니다.
(v) 코딩 :
코드 개발은이 단계에서 수행됩니다.
b) 검증 단계 :
(i) 단위 테스트 :
단위 테스트 저수준 설계 단계에서 설계되고 수행되는 단위 테스트 케이스를 사용하여 수행됩니다. 단위 테스트는 개발자가 직접 수행합니다. 조기 결함 감지로 이어지는 개별 구성 요소에서 수행됩니다.
(ii) 통합 테스트 :
통합 테스트 고급 디자인 단계에서 통합 테스트 케이스를 사용하여 수행됩니다. 통합 테스트는 통합 모듈에서 수행되는 테스트입니다. 테스터가 수행합니다.
(iii) 시스템 테스트 :
시스템 테스트 시스템 설계 단계에서 수행됩니다. 이 단계에서는 전체 시스템이 테스트됩니다. 즉, 전체 시스템 기능이 테스트됩니다.
(iv) 수락 테스트 :
수락 테스트는 요구 사항 분석 단계와 관련이 있으며 고객 환경에서 수행됩니다.
V의 장점 – 모델 :
- 간단하고 이해하기 쉬운 모델입니다.
- V 모델 접근 방식은 요구 사항이 정의되고 초기 단계에서 동결되는 소규모 프로젝트에 적합합니다.
- 고품질의 제품을 생산하는 체계적이고 체계적인 모델입니다.
V-Model의 단점 :
- V 자형 모델은 진행중인 프로젝트에 적합하지 않습니다.
- 나중 단계의 요구 사항 변경은 비용이 너무 많이 듭니다.
# 3) 프로토 타입 모델
프로토 타입 모델은 실제 소프트웨어에 앞서 프로토 타입이 개발 된 모델입니다.
프로토 타입 모델은 실제 소프트웨어와 비교할 때 제한된 기능과 비효율적 인 성능을 가지고 있습니다. 더미 함수는 프로토 타입을 만드는 데 사용됩니다. 이는 고객의 요구를 이해하는 데 유용한 메커니즘입니다.
소프트웨어 프로토 타입은 실제 소프트웨어보다 먼저 구축되어 고객으로부터 귀중한 피드백을받습니다. 피드백이 구현되고 변경 사항이 있는지 고객이 프로토 타입을 다시 검토합니다. 이 프로세스는 고객이 모델을 수락 할 때까지 계속됩니다.
요구 사항 수집이 완료되면 빠른 설계가 생성되고 평가를 위해 고객에게 제공되는 프로토 타입이 제작됩니다.
고객 피드백과 정제 된 요구 사항은 프로토 타입을 수정하는 데 사용되며 평가를 위해 고객에게 다시 제공됩니다. 고객이 프로토 타입을 승인하면 실제 소프트웨어를 구축하기위한 요구 사항으로 사용됩니다. 실제 소프트웨어는 Waterfall 모델 접근 방식을 사용하여 빌드됩니다.
프로토 타입 모델의 장점 :
- 프로토 타입 모델은 결함이 훨씬 더 일찍 발견되기 때문에 개발 비용과 시간을 줄여줍니다.
- 누락 된 기능이나 요구 사항의 변경은 평가 단계에서 식별 할 수 있으며 개선 된 프로토 타입에서 구현할 수 있습니다.
- 초기 단계부터 고객이 참여하면 요구 사항이나 기능에 대한 이해의 혼동이 줄어 듭니다.
프로토 타입 모델의 단점 :
- 고객이 모든 단계에 참여하기 때문에 고객은 최종 제품의 요구 사항을 변경하여 범위의 복잡성을 증가시키고 제품 배송 시간을 늘릴 수 있습니다.
# 4) 나선형 모델
나선형 모델 반복 및 프로토 타입 접근 방식이 포함됩니다.
반복에서 나선형 모델 단계를 따릅니다. 모델의 루프는 SDLC 프로세스의 단계를 나타냅니다. 다음 루프는 설계, 구현 및 테스트입니다.
나선형 모델에는 다음 네 단계가 있습니다.
- 계획
- 위험도 분석
- 공학
- 평가
(i) 계획 :
계획 단계에는 모든 필수 정보가 고객으로부터 수집되고 문서화되는 요구 사항 수집이 포함됩니다. 다음 단계를 위해 소프트웨어 요구 사항 사양 문서가 생성됩니다.
(ii) 위험 분석 :
이 단계에서는 관련된 위험에 가장 적합한 솔루션을 선택하고 프로토 타입을 구축하여 분석을 수행합니다.
예를 들어 , 원격 데이터베이스에서 데이터에 액세스하는 것과 관련된 위험은 데이터 액세스 속도가 너무 느릴 수 있다는 것입니다. 데이터 액세스 하위 시스템의 프로토 타입을 구축하여 위험을 해결할 수 있습니다.
(iii) 엔지니어링 :
위험 분석이 완료되면 코딩 및 테스트가 완료됩니다.
(iv) 평가 :
고객은 개발 된 시스템을 평가하고 다음 반복을 위해 계획합니다.
나선형 모델의 장점 :
- 위험 분석은 프로토 타입 모델을 사용하여 광범위하게 수행됩니다.
- 기능의 향상이나 변경은 다음 반복에서 수행 할 수 있습니다.
나선형 모델의 단점 :
- 나선형 모델은 대규모 프로젝트에만 가장 적합합니다.
- 최종 제품에 도달하는 데 많은 시간이 소요될 수있는 많은 반복이 필요할 수 있으므로 비용이 높을 수 있습니다.
# 5) 반복적 증분 모델
반복적 인 증분 모델은 제품을 작은 덩어리로 나눕니다.
예를 들어 , 반복에서 개발할 기능을 결정하고 구현합니다. 각 반복은 요구 사항 분석, 설계, 코딩 및 테스트 단계를 거칩니다. 반복에서 자세한 계획은 필요하지 않습니다.
반복이 완료되면 제품이 확인되고 평가 및 피드백을 위해 고객에게 전달됩니다. 고객의 피드백은 새로 추가 된 기능과 함께 다음 반복에서 구현됩니다.
따라서 제품은 기능 측면에서 증가하고 반복이 완료되면 최종 빌드에 제품의 모든 기능이 포함됩니다.
반복 및 증분 개발 모델의 단계 :
- 시작 단계
- 정교화 단계
- 건설 단계
- 전환 단계
(i) 개시 단계 :
시작 단계에는 프로젝트의 요구 사항과 범위가 포함됩니다.
(ii) 정교화 단계 :
정교화 단계에서는 시작 단계에서 식별 된 위험을 다루고 비 기능적 요구 사항도 충족하는 제품의 작업 아키텍처가 제공됩니다.
(iii) 건설 단계 :
구성 단계에서 아키텍처는 배포 준비가 완료된 코드로 채워지며 기능 요구 사항의 분석, 설계, 구현 및 테스트를 통해 생성됩니다.
(iv) 전환 단계 :
전환 단계에서는 제품이 프로덕션 환경에 배포됩니다.
반복 및 증분 모델의 장점 :
- 요구 사항의 변경은 쉽게 수행 할 수 있으며 다음 반복에서 새 요구 사항을 통합 할 수있는 범위가 있으므로 비용이 들지 않습니다.
- 위험은 반복에서 분석 및 식별됩니다.
- 결함은 초기 단계에서 감지됩니다.
- 제품이 작은 단위로 나누어 져있어 관리가 용이합니다.
단점 반복 및 증분 모델 :
- 점진적으로 분해하고 구축하려면 제품에 대한 완전한 요구 사항과 이해가 필요합니다.
# 6) 빅뱅 모델
빅뱅 모델에는 정의 된 프로세스가 없습니다. 투입물과 산출물이 고객이 필요로하는 것과 같을 수도 있고 같지 않을 수도있는 개발 된 제품으로 나오기 때문에 돈과 노력이 합쳐집니다.
빅뱅 모델은 많은 계획과 일정이 필요하지 않습니다. 개발자는 요구 사항 분석 및 코딩을 수행하고 자신의 이해에 따라 제품을 개발합니다. 이 모델은 소규모 프로젝트에만 사용됩니다. 테스트 팀이없고 공식적인 테스트가 수행되지 않으며 이는 프로젝트 실패의 원인이 될 수 있습니다.
장점 빅뱅 모델 :
- 매우 단순한 모델입니다.
- 적은 계획과 일정이 필요합니다.
- 개발자는 자신의 소프트웨어를 유연하게 구축 할 수 있습니다.
빅뱅 모델의 단점 :
- 빅뱅 모델은 크고 진행중인 복잡한 프로젝트에 사용할 수 없습니다.
- 높은 위험과 불확실성.
# 7) 애자일 모델
애자일 모델은 반복 및 증분 모델의 조합입니다. 이 모델은 요구 사항보다는 제품을 개발하는 동안 유연성에 더 중점을 둡니다.
Agile에서 제품은 작은 증분 빌드로 나뉩니다. 한 번에 완전한 제품으로 개발되지 않았습니다. 각 빌드는 기능 측면에서 증가합니다. 다음 빌드는 이전 기능을 기반으로합니다.
애자일 반복에서는 스프린트라고합니다. 각 스프린트는 2-4 주 동안 지속됩니다. 각 스프린트가 끝날 때 제품 소유자는 제품을 확인하고 승인 후 고객에게 전달됩니다.
고객 피드백은 개선을 위해 취해지고 그의 제안과 개선은 다음 스프린트에서 작업됩니다. 실패 위험을 최소화하기 위해 각 스프린트에서 테스트가 수행됩니다.
애자일 모델의 장점 :
- 변경 사항에 더 유연하게 적응할 수 있습니다.
- 새로운 기능은 쉽게 추가 할 수 있습니다.
- 피드백과 제안은 모든 단계에서 수행되므로 고객 만족도를 높입니다.
단점 :
- 문서 부족.
- 애자일은 숙련되고 고도로 숙련 된 리소스가 필요합니다.
- 고객이 자신이 원하는 제품이 얼마나 정확한지 명확하지 않으면 프로젝트가 실패합니다.
결론
프로젝트를 성공적으로 완료하려면 적절한 수명주기를 준수하는 것이 매우 중요합니다. 이것은 차례로 관리를 더 쉽게 만듭니다.
다른 소프트웨어 개발 라이프 사이클 모델에는 고유 한 장단점이 있습니다. 모든 프로젝트에 가장 적합한 모델은 요구 사항 (명확하거나 불명확 한 여부), 시스템 복잡성, 프로젝트 크기, 비용, 기술 제한 등과 같은 요인에 의해 결정될 수 있습니다.
예, 요구 사항이 명확하지 않은 경우 필요한 변경 사항을 어느 단계에서나 쉽게 수용 할 수 있으므로 Spiral 및 Agile 모델을 사용하는 것이 가장 좋습니다.
Waterfall 모델은 기본 모델이며 다른 모든 SDLC 모델은이를 기반으로합니다.
SDLC에 대한 엄청난 지식을 얻었기를 바랍니다.