Software Development Life Cycle (SDLC) & Model

Software Development Life Cycle (SDLC)
소프트웨어 개발 수명 주기

소프트웨어 개발 수명 주기(SDLC)
소프트웨어 라이프 사이클 모델(프로세스 모델이라고도 함)은 소프트웨어 라이프 사이클을 그림으로 그리고 도식적으로 표현한 것입니다.(diagrammatic representation) 라이프 사이클 모델은 소프트웨어 제품이 라이프 사이클 단계를 통과하도록 하는 데 필요한 모든 방법을 나타냅니다. 또한 이러한 방법이 수행되는 구조를 포착합니다.

즉, 라이프 사이클 모델은 시작부터 폐기까지 소프트웨어 제품에서 수행된 다양한 활동을 매핑합니다. 다른 라이프 사이클 모델은 다른 방식으로 단계에 필요한 개발 활동을 계획할 수 있습니다. 따라서 라이프 사이클 모델을 따르는 요소가 없으며 모든 라이프 사이클 모델에 필수 활동이 포함되어 있지만 작업은 다른 라이프 사이클 모델에서 별개의 순서로 수행될 수 있습니다. 모든 라이프 사이클 단계에서 둘 이상의 활동도 수행될 수 있습니다.

 

Need of SDLC (필요성)

개발 팀은 특정 계획(particular plan)에 적합한(suitable) 수명 주기 모델을 결정한 다음 관찰해야 합니다.

정확한(exact) 라이프 사이클 모델을 사용하지 않고 소프트웨어 제품의 개발은 체계적이고(systematic) 훈련된 방식으로(disciplined manner) 이루어지지 않을 것입니다. 팀이 소프트웨어 제품을 개발할 때 팀 대표 간에 언제 무엇을 해야 하는지에 대한 명확한 이해가 있어야 합니다. 그렇지 않으면 혼란과 프로젝트 실패를 가리킬 것입니다. 이 문제는 예제를 사용하여 정의할 수 있습니다. 소프트웨어 개발 문제가 여러 부분으로 나뉘고 그 부분이 팀 구성원에게 할당된다고 가정합니다. 그때부터 팀 대표가 자신에게 할당된 역할을 원하는 방식으로 자유롭게 개발할 수 있다고 가정합니다. 한 담당자가 자신의 파트에 대한 코드 작성을 시작하고, 다른 담당자가 테스트 문서를 먼저 준비하고, 다른 엔지니어가 자신에게 할당된 역할의 설계 단계를 시작할 수 있습니다. 이것은 프로젝트 실패에(project failure) 대한 완벽한 방법 중 하나입니다.

 

SDLC Models

소프트웨어 개발 수명 주기(SDLC)는 초기 타당성 조사에서 완료된 애플리케이션의 유지 관리에 이르기까지 정보 시스템 개발 프로젝트에 포함되는 단계를 정의하는 프로젝트 관리에 사용되는 영적(spiritual) 모델입니다.

소프트웨어 개발 단계에서 따르는 다양한 소프트웨어 개발 라이프 사이클 모델이 지정(specify)되고 설계(design)됩니다. 이러한 모델을 "소프트웨어 개발 프로세스 모델(Software Development Process Models)"이라고도 합니다. 각 프로세스 모델은 소프트웨어 개발 단계에서 성공(success)을 보장하기 위해 해당 유형에 고유한 일련의 단계를 따릅니다.

다음은 SDLC 수명 주기의 몇 가지 중요한 단계입니다.

JavaTpoint

 

Waterfall Model (폭포 모형)

폭포수는 보편적으로 인정되는 SDLC 모델입니다.
이 방법에서 소프트웨어 개발의 전체 프로세스는 여러 단계로 나뉩니다.

폭포수 모델은 요구 사항 분석(analysis), 설계(design), 구현(implementation), 테스트(검증;validation), 통합(integration) 및 유지 관리의(maintenance) 단계를 통해 개발이 지속적으로 아래쪽으로(폭포처럼) 흐르는 것처럼 보이는 지속적인 소프트웨어 개발 모델입니다.

활동의 선형 순서는 몇 가지 중요한 결과를 낳습니다. 첫째, 단계의 끝과 다음 단계의 시작을 식별하려면 각 단계가 끝날 때 몇 가지 인증 기술을 사용해야 합니다. 일부 검증(verification) 및 검증(테스트, validation)은 일반적으로 단계의 출력이 입력(input, 이전 단계의 출력)과 일치하고 단계의 출력(output)이 시스템의 전체 요구 사항과 일치(consistent)하도록 하는 것을 의미합니다.

JavaTpoint

1. 요구 사항 분석 및 사양 단계: 이 단계의 목표는 고객의 정확한 요구 사항을 이해하고 적절하게 문서화하는 것입니다. 고객과 소프트웨어 개발자는 소프트웨어의 모든 기능, 성능 및 인터페이스 요구 사항을 문서화하기 위해 함께 작업합니다. 그것은 "어떻게"가 아니라 생산될 시스템의 "무엇"을 설명합니다. 이 단계에서는 공통 언어로 시스템이 수행할 작업에 대한 자세한 설명이 포함된 SRS(소프트웨어 요구 사항 사양) 문서라는 큰 문서가 생성됩니다.

2. 설계 단계: 이 단계는 SRS에 수집된 요구 사항을 프로그래밍 언어로 추가 코딩을 허용하는 적절한 형식으로 변환하는 것을 목표로 합니다. 높은 수준의 상세한 설계와 함께 전체 소프트웨어 아키텍처를 정의합니다. 이 모든 작업은 소프트웨어 설계 문서(SDD; Software Design Document)로 문서화됩니다.

3. 구현 및 단위 테스트: 이 단계에서 디자인이 구현됩니다. SDD(Software Design Document)가 완료되면 소프트웨어 개발자가 필요로 하는 모든 정보가 SDD에 포함되기 때문에 구현 또는 코딩 단계가 원활하게 진행됩니다.
테스트하는 동안 코드를 철저히 검사하고 수정합니다. 작은 모듈은 초기에 격리된 상태에서 테스트됩니다. 그런 다음 이러한 모듈과 중간 출력 흐름 간의 상호 작용을 확인하기 위해 일부 오버헤드 코드를 작성하여 이러한 모듈을 테스트합니다.

4. 통합 및 시스템 테스트: 이 단계는 수행된 테스트의 효율성에 따라 최종 제품의 품질이 결정되기 때문에 매우 중요합니다. 더 나은 출력은 고객 만족, 유지 보수 비용 절감, 정확한 결과로 이어집니다. 단위 테스트는 개별 모듈의 효율성을 결정합니다. 그러나 이 단계에서 모듈은 서로 및 시스템과의 상호 작용에 대해 테스트됩니다.

5. 운영 및 유지 관리 단계: 유지 관리는 소프트웨어가 고객에게 전달되고 설치 및 작동되면 모든 사용자가 수행하는 작업입니다.

 

Waterfall 모델은 언제 사용해야 합니까?

Waterfall 모델의 사용이 가장 적합한 일부 상황은 다음과 같습니다.

• 요구 사항이 일정하고 정기적으로 변경되지 않는 경우.
• 프로젝트는 짧다
• 상황은 조용(calm)하다
• 사용된 도구와 기술이 일관(consistent)되고 변경되지 않는 경우
• 리소스가 잘 준비되어 있고 사용할 수 있는 경우.

Waterfall 모델의 장점 (Advantages)

• 이 모델은 구현이 간단하며 필요한 리소스 수도 최소화(minimal)됩니다.
• 요구 사항은 간단(simple)하고 명시적(explicitly)으로 선언(declared)되어 있습니다.
  전체 프로젝트 개발 동안 변경되지 않은 상태로 유지됩니다.
• 각 단계의 시작 지점과 끝 지점이 고정(fixed)되어 있어 진행 상황을(cover progress) 쉽게 파악할 수 있습니다.
• 완제품의 출시일(release date)과 최종 비용은(final cost) 개발 전에 결정할 수 있습니다.
• 엄격한(strict) 보고 시스템으로 인해 고객에게 쉬운 제어 및 명확성(clarity)을 제공합니다.

Waterfall 모델의 단점(Disadvantages)

• 이 모델에서는 위험 요소가 더 높으므로 이 모델은 더 중요하고(significant) 복잡한(complex) 프로젝트에 적합하지 않습니다.
• 이 모델은 개발 중 요구 사항의 변경 사항을 수용할 수 없습니다.
• 단계로 돌아가기가 어려워집니다. 
  예를 들어, 애플리케이션이 이제 코딩 단계로 전환되었고 요구 사항에 변경 사항이 있는 경우 돌아가서 변경하는 것이 어려워집니다.
• 테스트는 후기 단계에서 수행되기 때문에 초기 단계의 과제와 위험을 식별할 수 없으므로 위험 감소 전략(risk reduction strategy)을 준비하기가 어렵습니다.

 

RAD 모델 (Rapid Application Development)

RAD 또는 Rapid Application Development 프로세스는 폭포수 모델(단기간에 소프트웨어를 개발하는 것을 목표로 하는 폭포수 모델)에서 기반합니다. RAD 모델은 포커스 그룹을 사용하여 시스템 요구 사항을 수집함으로써 더 짧은 시간에 더 나은 시스템을 개발할 수 있다는 개념을 기반으로 합니다.

• 비즈니스 모델링
• 데이터 모델링
• 프로세스 모델링
• 애플리케이션 생성
• 테스트 및 회전율

JavaTpoint

1. 비즈니스 모델링: 비즈니스 기능 간의 정보 흐름은 비즈니스 프로세스를 주도하는 데이터, 생성된 데이터, 생성한 사람, 정보가 어디로 가는지, 처리하는 사람 등과 같은 질문에 답함으로써 정의됩니다.

2. 데이터 모델링: 비즈니스 모델링에서 수집된 데이터는 비즈니스를 지원하는 데 필요한 데이터 개체(엔티티) 집합으로 세분화됩니다. 속성(각 엔터티의 문자)을 식별하고 이러한 데이터 개체(엔티티) 간의 관계를 정의합니다.
동영상 재생

3. 프로세스 모델링: 데이터 모델링 단계에서 정의된 정보 개체는 비즈니스 기능을 구현하는 데 필요한 데이터 흐름을 달성하기 위해 변환됩니다. 데이터 개체를 추가, 수정, 삭제 또는 검색하기 위해 처리 설명이 생성됩니다.

4. 애플리케이션 생성: 자동화된 도구는 소프트웨어 구축을 용이하게 하는 데 사용됩니다. 심지어 그들은 4차 GL 기술을 사용합니다.

5. 테스트 및 전환: 많은 프로그래밍 구성 요소는 RAD 강조 재사용 이후로 이미 테스트되었습니다. 이렇게 하면 전체 테스트 시간이 단축됩니다. 그러나 새 부품을 테스트해야 하고 모든 인터페이스가 완전히 실행되어야 합니다.

RAD 모델은 언제 사용합니까?

• 시스템이 짧은 시간(2~3개월)에 모듈화 하는 프로젝트를 만들어야 할 때.
• 요구 사항이 잘 알려진 경우.
• 기술적 위험이 제한된 경우.
• 2~3개월 만에 모듈화 한 시스템을 만들어야 할 때.
• 예산이 자동 코드 생성 도구를 사용할 수 있는 경우에만 사용해야 합니다.

RAD 모델의 장점 (Advantages)

• 이 모델은 변경이 가능합니다.
• 이 모델에서는 변경 사항을 적용할 수 있습니다.
• RAD의 각 단계는 고객에게 가장 높은 우선순위 기능을 제공합니다.
• 개발 시간을 단축했습니다.
• 기능의 재사용성을 높입니다.

RAD 모델의 단점 (Disadvantages)

• 고도로 숙련된 디자이너가 필요했습니다.
• 모든 응용 프로그램은 RAD와 호환되지 않습니다.
• 소규모 프로젝트의 경우 RAD 모델을 사용할 수 없습니다.
• 기술적 위험이 높기 때문에 적합하지 않습니다.
• 사용자 참여가 필요합니다.

 

Spiral Model (나선형 모델)

나선형 모델은 위험 주도 프로세스(risk-driven process) 모델입니다. 이 SDLC 모델은 그룹이 폭포수(waterfall), 증분(incremental) 등과 같은 하나 이상의 프로세스 모델 요소를 채택하는 데 도움이 됩니다. 나선형 기법은 설계 및 개발 활동에서 신속한 프로토타이핑과(prototyping) 동시성의(concurrency) 조합입니다.

나선형의 각 주기는 해당 주기의 목표, 목표 달성을 위해 가능한 다양한 대안, 존재하는 제약 조건을 식별하는 것으로 시작됩니다. 이것은 주기의 첫 번째 사분면(왼쪽 위 사분면)입니다.

주기의 다음 단계는 목표와(objectives)  제약 조건을(constraints) 기반으로 이러한 다양한 대안을 평가(evaluate)하는 것입니다. 이 단계에서 평가의 초점은 프로젝트에 대한 위험 인식을(risk perception) 기반으로 합니다.

다음 단계는 불확실성과(uncertainties)  위험을(risks) 해결하는 전략을 개발하는 것입니다. 이 단계에는 벤치마킹(benchmarking), 시뮬레이션(simulation) 및 프로토타이핑과(prototyping) 같은 활동이 포함될 수 있습니다.

JavaTpoint

- 목표 설정 : 나선형의 각 주기는 해당 주기의 목적 식별, 목표 달성을 위해 가능한 다양한 대안, 존재하는 제약으로 시작합니다.
- 위험 평가 및 감소 : 주기의 다음 단계는 목표와 제약 조건을 기반으로 이러한 다양한 대안을 계산하는 것입니다. 이 단계에서 평가의 초점은 프로젝트에 대한 위험 인식에 있습니다.
- 개발 및 검증 : 다음 단계는 불확실성과 위험을 해결하는 전략을 개발하는 것입니다. 이 프로세스에는 벤치마킹, 시뮬레이션 및 프로토타이핑과 같은 활동이 포함될 수 있습니다.
- 계획: 마지막으로 다음 단계가 계획됩니다. 프로젝트가 검토되고 나선형의 추가 기간을 계속할지 여부를 선택합니다. 유지하기로 결정되면 프로젝트의 다음 단계에 대한 계획이 수립됩니다.

개발 단계는 나머지 위험에 따라 다릅니다. 예를 들어, 성능 또는 사용자 인터페이스 위험이 프로그램 개발 위험보다 더 중요하게 취급되는 경우 다음 단계는 위험을 해결하기 위한 보다 상세한 프로토타입 개발을 포함하는 진화적 개발이 될 수 있습니다.

나선형 모델의 위험 중심 기능을 사용하면 사양 지향, 프로토타입 지향, 시뮬레이션 지향 또는 다른 유형의 접근 방식을 혼합하여 수용할 수 있습니다. 모델의 필수 요소는 나선형의 각 기간이 다음 주기에 대한 계획을 포함하여 해당 주기 동안 개발된 모든 제품을 포함하는 검토에 의해 완료된다는 것입니다. 나선형 모델은 개발 및 개선 프로젝트에 적용됩니다.

Spiral 모델은 언제 사용합니까?

• 자주 구출해야 할 때.
• 프로젝트가 클 때
• 요구 사항이 명확하지 않고 복잡할 때
• 언제든지 변경이 필요할 수 있는 경우
• 대규모 및 높은 예산 프로젝트

Spiral 모델의 장점 (Advantages)

• 많은 양의 위험 분석
• 크고 미션 크리티컬 한 프로젝트에 유용합니다.

Spiral 모델의 단점 (Disadvantages)

• 비용이 많이 드는 모델이 될 수 있습니다.
• 위험 분석에는 고도의 전문 지식이 필요했습니다.
• 소규모 프로젝트에서는 잘 작동하지 않습니다.

 

V-모델

이러한 유형의 SDLC 모델 테스트 및 개발에서는 단계가 병렬(parallel)로 계획됩니다. 따라서 측면에는 검증(verification)  단계가 있고 다른 측면에는 검증(테스트, validation) 단계가 있습니다.
V-Model은 코딩(Coding) 단계에 의해 조인됩니다.

JavaTpoint

Verification

코드를 실행하지 않고 수행되는 정적(static) 분석 방법(검토)을 포함합니다.
제품 개발 프로세스를(product development process) 평가하여 지정된 요구 사항을 충족하는지 여부를 확인하는 프로세스입니다.

Verification 단계에는 다양한 단계가 있습니다.
- 비즈니스 요구 사항 분석: 고객 입장에서 제품 요구 사항을 이해하는 첫 번째 단계입니다. 이 단계에는 고객의 기대와 정확한 요구 사항을 이해하기 위한 자세한 커뮤니케이션이 포함됩니다.
- 시스템 설계: 이 단계에서 시스템 엔지니어는 사용자 요구 사항 문서를 연구하여 제안된 시스템의 비즈니스를 분석하고 해석합니다.
- 아키텍처 설계: 아키텍처 선택의 기준은 일반적으로 모듈 목록, 각 모듈의 간략한 기능, 인터페이스 관계, 종속성, 데이터베이스 테이블, 아키텍처 다이어그램, 기술 세부 정보 등으로 구성된 모든 것을 이해해야 한다는 것입니다. 통합 테스트 모델은 특정 단계에서 수행됩니다.
- 모듈 설계: 모듈 설계 단계에서 시스템은 작은 모듈로 나뉩니다. 모듈의 세부 설계가 지정되며 이를 저수준 설계라고 합니다.
- 코딩 단계: 디자인 후 코딩 단계가 시작됩니다. 요구 사항에 따라 적절한 프로그래밍 언어가 결정됩니다. 코딩에 대한 몇 가지 지침과 표준이 있습니다. 리포지토리에 체크인하기 전에 최종 빌드는 더 나은 성능을 위해 최적화되고 코드는 성능을 확인하기 위해 많은 코드 검토를 거칩니다.

 

Validation

동적(dynamic)  분석 방법(기능;functional, 비기능;non-functional)을 포함하며 테스트는 코드를 실행하여 수행됩니다. 테스트는 소프트웨어가 고객의 기대와(customer expectations) 요구 사항을(requirements) 충족하는지 확인하기 위해 개발 프로세스가 완료된 후 소프트웨어를 분류(classify)하는 프로세스입니다.

Validation단계에는 다양한 단계가 있습니다.
- 단위 테스트: V-Model에서 UTP(Unit Test Plans; 단위 테스트 계획)는 모듈 설계 단계에서 개발됩니다. 이러한 UTP는 코드 수준 또는 단위 수준에서 오류를 제거하기 위해 실행됩니다. 단위는 프로그램 모듈과 같이 독립적으로 존재할 수 있는 가장 작은 개체입니다. 단위 테스트는 가장 작은 엔터티가 나머지 코드/단위와 격리될 때 올바르게 작동할 수 있는지 확인합니다.
- 통합 테스트: 통합 테스트 계획은 아키텍처 설계 단계에서 개발됩니다. 이 테스트는 독립적으로 만들고 테스트한 그룹이 서로 공존하고 통신할 수 있는지 확인합니다.
- 시스템 테스트: 시스템 테스트 계획은 시스템 설계 단계에서 개발됩니다. 단위 및 통합 테스트 계획과 달리 시스템 테스트 계획은 클라이언트의 비즈니스 팀에서 구성됩니다. 시스템 테스트는 애플리케이션 개발자의 기대가 충족되는지 확인합니다.
- 인수 테스팅: 수락 테스팅은 비즈니스 요구 사항 분석 부분과 관련이 있습니다. 여기에는 사용자 환경에서 소프트웨어 제품을 테스트하는 것이 포함됩니다. 승인 테스트는 사용자 환경 내에서 사용할 수 있는 다양한 시스템과의 호환성 문제를 나타냅니다. 실제 사용자 환경 내에서 부하 및 성능 결함과 같은 비기능적 문제를 공동으로 발견합니다.

 

그래서 V-Model은 다른 쪽에 있는 검증(Verification) 단계의 한쪽에 검증(테스트, Validation) 단계를 포함합니다. 검증 및 검증 과정은 V자 형태의 코딩 단계로 결합됩니다. 따라서 V-모델이라고 합니다.

소프트웨어 품질 활동 이해 (QC, QA, QI, QM)

 

V-Model은 언제 사용합니까?

• 요구 사항이 명확하고 모호하지 않은 경우.
• V자형 모델은 요구 사항이 명확하게 정의되고 고정된 중소 규모(medium-sized) 프로젝트에 사용해야 합니다.
• V자형 모델은 필수 기술 전문 지식과(essential technical expertise) 함께 샘플 기술 리소스를(ample technical resources) 사용할 수 있는 경우 선택해야 합니다.

V-Model의 장점(Advantages)

• 이해하기 쉬운(Easy to Understand).
• 계획, 테스트 설계와 같은 테스트 방법은 코딩 전에 잘 수행됩니다.
• 이것은 많은 시간을 절약합니다. 따라서 폭포수 모델보다 성공할 가능성이 더 높습니다.
• 결함의 하향 흐름을(downward flow) 방지(Avoids)합니다.
• 요구 사항을 쉽게 이해할 수 있는 소규모 계획에 적합합니다.

V-Model의 단점(Disadvantages)

• 매우 단단하고(Very rigid) 유연성(flexible)이 거의 없습니다.
• 복잡한(complex) 프로젝트에는 적합하지 않습니다.
• 소프트웨어는 구현 단계에서 개발되므로 소프트웨어의 초기 프로토타입이 생성되지 않습니다.
• 중간에 변경 사항이 발생하면 필요한 문서와 함께 테스트 문서를 업데이트해야 합니다.

 

Incremental Model (증분 모델)

증분형 모델은 별도도 분류된 모델이 아닙니다. 증분 모델은 폭포수 모델에서 갈라진 하나의 사이클이다. (necessarily a series of waterfall cycles)
요구 사항은 프로젝트 시작 시 그룹으로 나뉩니다. 각 그룹에 대해 SDLC 모델을 따라 소프트웨어를 개발합니다. 모든 요구 사항이 충족될 때까지 각 릴리스에 더 많은 기능(functionality)이 추가되면서 SDLC 프로세스가 반복됩니다(repeated). 이 방법에서 각 주기는 이전 소프트웨어 릴리스의 유지 관리 단계 역할을 합니다. 증분 모델을 수정하면 개발 주기가 겹칠 수 있습니다(overlap). 그다음 주기는 이전 주기가 완료되기 전에 시작될 수 있습니다.

JavaTpoint

1. 요구 사항 분석: 증분 모델의 첫 번째 단계에서 제품 분석 전문 지식이 요구 사항을 식별합니다. 그리고 시스템 기능 요구 사항은 요구 사항 분석 팀에서 이해합니다. 증분 모델에서 소프트웨어를 개발하기 위해 이 단계는 중요한 역할을 수행합니다.

2. 설계 및 개발: SDLC의 증분 모델의 이 단계에서 시스템 기능 및 개발 방법의 설계가 성공적으로 완료됩니다. 소프트웨어가 새로운 실용성을 개발할 때 증분 모델은 스타일과 개발 단계를 사용합니다.

3. 테스팅: 증분 모델에서 테스팅 단계는 추가 기능뿐만 아니라 기존의 각 기능의 성능을 확인합니다. 테스트 단계에서는 다양한 방법을 사용하여 각 작업의 동작을 테스트합니다.

4. 구현: 구현 단계는 개발 시스템의 코딩 단계를 활성화합니다. 설계 및 개발 단계에서 설계하고 테스트 단계에서 기능을 테스트하는 최종 코딩이 포함됩니다. 이 단계가 끝나면 작업하는 제품의 수를 늘리고 최종 시스템 제품까지 업그레이드합니다.

 

Incremental 모델은 언제 사용합니까?

• 요구 사항이 우수할 때.
  프로젝트에는 긴 개발 일정이 있습니다.
  소프트웨어 팀이 숙련되거나 훈련되지 않은 경우.
  고객이 제품의 빠른 출시를 요구할 때.
  우선순위가 지정된 요구 사항을 먼저 개발할 수 있습니다.

Incremental 모델의 장점 (Advantages)

• 오류는 인식하기 쉽습니다.
  테스트 및 디버그 용이성
  더 유연합니다.
  반복 중에 처리되기 때문에 위험 관리가 간단합니다.
  클라이언트는 중요한 기능을 일찍 얻습니다.

Incremental 모델의 단점 (Disadvantages)

• 좋은 계획이 필요하다
  총비용이 높습니다.
  잘 정의된 모듈 인터페이스가 필요합니다.

 

Agile Model (애자일 모델)

애자일 방법론은 모든 프로젝트의 SDLC 프로세스 중에 개발과 테스트의 지속적인 상호 작용을 촉진하는 방법입니다. 애자일 방법에서는 전체 프로젝트를 작은 증분 빌드로 나눕니다. 이러한 모든 빌드는 반복적으로 제공되며 각 반복은 1주에서 3주까지 지속됩니다.

모든 애자일 소프트웨어 단계는 대부분의 소프트웨어 프로젝트에 대한 몇 가지 주요 가정을 해결하는 방식으로 특성화됩니다.

• 어떤 소프트웨어 요구 사항이 지속되고 어떤 것이 변경될지 미리 생각하는 것은 어렵습니다. 프로젝트가 진행됨에 따라 사용자 우선순위가 어떻게 변경될지 예측하는 것도 마찬가지로 어렵습니다.
• 많은 유형의 소프트웨어에서 설계와 개발이 교차 진행됩니다(interleaved). 즉, 설계 모델이 생성될 때 입증될 수 있도록 두 가지 활동을 동시에 수행해야 합니다. 구성을 테스트하기 위해 구성을 사용하기 전에 얼마나 많은 설계가 필요한지 생각하기 어렵습니다.
• 분석, 설계, 개발 및 테스트는 (계획의 관점에서) 우리가 원하는 만큼 예측할 수 없습니다.

JavaTpoint

애자일 모델의 단계

애자일 모델의 단계는 다음과 같습니다.

1. Requirements gathering (요구사항 수집)
   이 단계에서는 요구 사항을 정의해야 합니다. 사업 기회를 설명하고 프로젝트를 구축하는 데 필요한 시간과 노력을 계획해야 합니다. 이 정보를 바탕으로 기술적, 경제적 타당성을 평가할 수 있습니다.
2. Design the requirements (요구 사항 설계)
   프로젝트를 식별했으면 이해 관계자와 협력하여 요구 사항을 정의합니다. 사용자 흐름 다이어그램 또는 상위 수준 UML 다이어그램을 사용하여 새 기능의 작업을 표시하고 기존 시스템에 적용하는 방법을 표시할 수 있습니다.
3. Construction/ iteration (구축/반복)
   팀이 요구 사항을 정의하면 작업이 시작됩니다. 디자이너와 개발자는 작동하는 제품을 배포하는 것을 목표로 프로젝트 작업을 시작합니다. 제품은 여러 단계의 개선을 거쳐 단순하고 최소한의 기능만 포함합니다.
4. Testing/ Quality assurance (테스트/품질 보증)
   이 단계에서 품질 보증 팀은 제품의 성능을 검사하고 버그를 찾습니다.
5. Deployment (전개, 배포)
   이 단계에서 팀은 사용자의 작업 환경에 맞는 제품을 출시합니다.
6. Feedback (피드백)
   제품 출시 후 마지막 단계는 피드백입니다. 여기서 팀은 제품에 대한 피드백을 받고 피드백을 통해 작업합니다.
   

Agile Testing Methods (애자일 테스트 방법)

Scrum (스크럼)

SCRUM은 팀 기반 개발 조건에서 작업을 관리하는 방법에 주로 초점을 맞춘 애자일 개발 프로세스입니다.
여기에는 세 가지 역할이 있으며 그 책임은 다음과 같습니다.
- 스크럼 마스터: 스크럼은 마스터 팀을 구성하고 회의를 주선하며 프로세스의 장애물을 제거할 수 있습니다.
- 제품 소유자: 제품 소유자는 제품 백로그를 만들고 지연의 우선순위를 지정하며 각 반복에 대한 기능 배포를 책임집니다.
- 스크럼 팀: 팀은 작업을 관리하고 스프린트 또는 사이클을 완료하기 위해 작업을 구성합니다.

eXtreme Programming(XP) (익스트림 프로그래밍)

이러한 유형의 방법론은 고객이 지속적으로 요구 사항이나 요구 사항을 변경하거나 시스템 성능에 대해 확신할 수 없는 경우에 사용됩니다..

Crystal (결정)

이 방법에는 세 가지 개념이 있습니다.
- Chartering(차터링): 이 단계에는 개발 팀 구성, 타당성 분석 수행, 계획 개발 등과 같은 여러 활동이 포함됩니다.
- Cyclic delivery (주기적인 전달): 이 아래에는 두 개의 주기가 더 있습니다. 팀에서 출시 계획을 업데이트합니다. 통합된 제품이 사용자에게 전달됩니다.
- Wrap up(마무리): 사용자 환경에 따라 배포, 배포 후 수행하는 단계입니다.

Dynamic Software Development Method(동적 소프트웨어 개발 방식, DSDM)

DSDM은 소프트웨어 개발을 위한 신속한 애플리케이션 개발 전략이며 민첩한 프로젝트 배포 구조를 제공합니다. DSDM의 필수 기능은 사용자가 적극적으로 연결되어야 하고 팀에 의사 결정 권한이 부여된다는 것입니다.
DSDM에서 사용되는 기술은 다음과 같습니다.
- Time Boxing
- MoSCoW Rules
- Prototyping
DSDM 프로젝트에는 7단계가 있습니다.
- Pre-project (사전 프로젝트)
- Feasibility Study (타당성 조사)
- Business Study (비즈니스 스터디)
- Functional Model Iteration (기능적 모델 반복)
- Design and build Iteration (반복 설계 및 구축)
- Implementation (구현)
- Post-project (프로젝트 후)

Feature Driven Development (기능 중심 개발, FDD)

이 방법은 "설계 및 구축" 기능에 중점을 둡니다. 다른 스마트 방법과 달리 FDD는 기능별로 별도로 얻어야 하는 작업의 작은 단계를 설명합니다.

Lean Software Development (린 소프트웨어 개발)

린 소프트웨어 개발 방법론은 "적시 생산(just in time production)" 원칙을 따릅니다. 린 방법은 소프트웨어 개발 속도의 증가와 비용 절감을 나타냅니다.
린 개발은 7단계로 요약할 수 있습니다.
- Eliminating Waste (낭비 제거)
- Amplifying learning (지식 창출)
- Defer commitment deciding as late as possible (가능한 한 늦게 결정)
- Early delivery (빠른 배포)
- Empowering the team (팀의 역량 강화)
- Building Integrity (무결성 구축)
- Optimize the whole (전체 최적화)

 

애자일 모델은 언제 사용합니까?

• 잦은 변경이 필요한 경우.
• 고도로 자격을 갖추고 경험이 풍부한 팀이 있는 경우. (highly qualified and experienced team)
• 고객이 항상 소프트웨어 팀과 회의를 가질 준비가 되어 있을 때.
• 프로젝트 크기가 작은 경우.

애자일 방식의 장점(Advantages):

• 빈번한 배포 (Frequent Delivery)
• 고객과의 대면 커뮤니케이션.
• 효율적인 디자인과 비즈니스 요구 사항을 충족합니다.
• 언제든지 변경이 허용됩니다.
• 총 개발 시간이 단축됩니다.

애자일 모델의 단점(Disadvantages):

• 공식 문서의(formal documents) 부족으로 인해 혼란을 야기하고 다양한 단계에서 내려진 중요한 결정이 다른 팀 구성원에 의해 언제든지 잘못 해석될(misinterpreted) 수 있습니다.
• 적절한 문서가 없기 때문에 프로젝트가 완료되고 개발자가 다른 프로젝트에 할당되면 완성된 프로젝트의 유지 관리가 어려울 수 있습니다.

 

Iterative Model (반복 모델)

이는 초기의 단순화된 구현에 초점을 맞춘 소프트웨어 개발 수명 주기의 특정 구현으로, 최종 시스템이 완성될 때까지 점점 더 복잡해지고 광범위한 기능 세트를 얻게 됩니다. 요컨대, 반복 개발은 대규모 애플리케이션의 소프트웨어 개발을 더 작은 조각으로 나누는 방법입니다.

이 모델에서는 일부 소프트웨어 사양으로 시작하여 소프트웨어의 첫 번째 버전을 개발할 수 있습니다. 첫 번째 버전 이후에 소프트웨어를 변경해야 하는 경우 새 버전의 소프트웨어가 새 반복으로 생성됩니다. 반복 모델의 모든 릴리스는 반복이라고 하는 정확하고 고정된 기간에 완료됩니다.

반복 모델을 사용하면 변형이 각각 이루어진 초기 단계에 액세스할 수 있습니다. 소프트웨어 개발 수명 주기(SDLC) 프로세스가 끝나면 갱신된 프로젝트의 최종 출력입니다.

JavaTpoint

반복 모델의 다양한 단계는 다음과 같습니다.
1. Requirement gathering & analysis:(요구사항 수집 및 분석): 이 단계에서는 고객으로부터 요구사항을 수집하고 분석가가 요구사항이 충족되는지 여부를 확인합니다. 분석가는 예산 내에서 달성할 필요가 있는지 여부를 확인합니다. 이 모든 작업이 끝나면 소프트웨어 팀은 다음 단계로 건너뜁니다.
2. Design(디자인): 디자인 단계에서 팀은 데이터 흐름 다이어그램, 활동 다이어그램, 클래스 다이어그램, 상태 전환 다이어그램 등과 같은 다양한 다이어그램으로 소프트웨어를 디자인합니다. 동영상 재생
3. Implementation(구현): 구현에서 요구 사항은 코딩 언어로 작성되고 소프트웨어라고 하는 컴퓨터 프로그램으로 변환됩니다.
4.Testing(테스트): 코딩 단계를 완료한 후 소프트웨어 테스트는 다른 테스트 방법을 사용하여 시작됩니다. 테스트 방법은 여러 가지가 있지만 가장 일반적인 것은 화이트박스, 블랙박스, 그레이 박스 테스트 방법이다.
5. Deployment(배포): 모든 단계를 완료한 후 소프트웨어가 작업 환경에 배포됩니다.
6. Review(검토): 이 단계에서는 제품 배포 후 개발된 제품의 동작 및 유효성을 확인하기 위해 검토 단계를 수행합니다. 그리고 오류가 발견되면 요구 사항 수집에서 프로세스가 다시 시작됩니다.
7. Maintenance(유지 관리): 유지 관리 단계에서 작업 환경에 소프트웨어를 배포한 후 일부 버그, 일부 오류 또는 새로운 업데이트가 필요할 수 있습니다. 유지 관리에는 디버깅 및 새로운 추가 옵션이 포함됩니다.

 

Iterative 모델은 언제 사용합니까?

• 요구 사항이 명확하고 이해하기 쉽게 정의된 경우.
• 소프트웨어 응용 프로그램이 큰 경우.
• 향후 변경 요구가 있는 경우.

Iterative 모델의 장점(Advantages)

• 더 작은 반복 동안 테스트 및 디버깅이 쉽습니다.
• 병렬 개발은 계획할 수 있습니다.
• 프로젝트의 끊임없이 변화하는 요구 사항에 쉽게 수용할 수 있습니다.
• 위험은 반복 중에 식별되고 해결됩니다.
• 문서화에 소요되는 제한된 시간과 설계에 추가 시간.

Iterative 모델의 단점(Disadvantages)

• 소규모 프로젝트에는 적합하지 않습니다.
• 더 많은 리소스가 필요할 수 있습니다.
• 불완전한 요구 사항으로 인해 디자인이 계속해서 변경될 수 있습니다.
• 요구 사항 변경으로 인해 예산 초과가 발생할 수 있습니다.
• 요구 사항 변경으로 인해 프로젝트 완료 날짜가 확인되지 않았습니다.

 

Big bang model (빅뱅 모델)

빅뱅 모델은 계획이 없거나 거의 없는 소프트웨어 개발 및 코딩의 모든 유형의 리소스에 중점을 둡니다. 요구 사항이 올 때 이해되고 구현됩니다.
이 모델은 소규모 개발 팀이 함께 작업하는 소규모 프로젝트에 가장 적합합니다. 학술 소프트웨어 개발 프로젝트에도 유용합니다. 요구 사항을 알 수 없거나 최종 릴리스 날짜가 지정되지 않은 이상적인 모델입니다.

이 모델에서 개발자는 특정 프로세스를 따르지 않습니다. 개발은 투입물의 형태로 필요한 자금과 노력으로 시작됩니다. 그리고 그 결과는 고객의 요구 사항에 따라 달라질 수도 있고 아닐 수도 있습니다. 왜냐하면 이 모델에서는 고객 요구 사항조차 정의되지 않기 때문입니다.

이 모델은 학술 프로젝트 또는 실제 프로젝트와 같은 소규모 프로젝트에 이상적입니다. 한 두 명의 개발자가 이 모델에서 함께 작업할 수 있습니다.

JavaTpoint

Big bang 모델은 언제 사용하나요?

위에서 논의한 바와 같이 이 모델은 이 프로젝트가 학술 프로젝트나 실제 프로젝트와 같이 소규모일 때 필요합니다. 이 방법은 개발자 팀의 규모가 작고 요구 사항이 정의되어 있지 않고 출시 날짜가 고객에 의해 확인되거나 제공되지 않은 경우에도 사용됩니다.

Big bang 모델의 장점(Advantages):

• 계획이 필요하지 않습니다.
• 단순한 모델.
• 리소스가 거의 필요하지 않습니다.
• 관리하기 쉽습니다.
• 개발자에게 유연합니다.

Big bang 모델의 단점(Disadvantages):

• 높은 위험도와 불확실성이 존재합니다.
• 대규모 프로젝트에 적합하지 않습니다.
• 요구 사항이 명확하지 않은 경우 비용이 많이 소요될 수 있습니다.

 

Prototype Model (프로토타입 모델)

프로토타입 모델은 요구 사항 수집으로 시작됩니다. 개발자와 사용자는 소프트웨어의 목적을 충족하고 정의하고 요구 사항을 식별합니다.
그런 다음 '빠른 디자인'이 생성됩니다. 이 디자인은 사용자가 볼 수 있는 소프트웨어 측면에 중점을 둡니다. 그런 다음 프로토타입 개발로 이어집니다. 그런 다음 고객은 프로토타입을 확인하고 필요한 수정이나 변경이 프로토타입에 적용됩니다.

이 단계에서 루핑이 발생하고 프로토타입의 더 나은 버전이 생성됩니다. 이는 프로토타입에서 새로운 변경 사항을 업데이트할 수 있도록 사용자에게 지속적으로 표시됩니다. 이 프로세스는 고객이 시스템에 만족할 때까지 계속됩니다. 사용자가 만족하면 프로토타입은 품질과 보안을 모두 고려하여 실제 시스템으로 변환됩니다.

프로토타입 모델은 실제 소프트웨어 개발을 수행하기 전에 시스템의 작동 프로토타입을 구축해야 합니다. 프로토타입은 시스템의 장난감 구현입니다. 프로토타입은 일반적으로 실제 시스템의 매우 조잡한 버전으로 밝혀지며 실제 소프트웨어와 비교하여 제한된 기능적 기능, 낮은 신뢰성 및 비효율적인 성능을 나타낼 수 있습니다. 많은 경우에 클라이언트는 소프트웨어 제품에서 기대되는 것에 대한 일반적인 견해만 가지고 있습니다. 시스템에 대한 입력, 처리 요구 사항 및 출력 요구 사항에 대한 자세한 정보가 없는 시나리오에서는 프로토타이핑 모델을 사용할 수 있습니다.

JavaTpoint

Prototype 모델의 단계

1. Requirement Gathering and Analyst (요구 사항 수집 및 분석)
2. Quick Decision (빠른 결정)
3. Build a Prototype(프로토타입 제작)
4. Assessment or User Evaluation (평가 또는 사용자 평가)
5. Prototype Refinement (프로토타입 개선)
6. Engineer Product (엔지니어 제품)

Prototype 모델의 장점

• 잘못된 사용자 요구 사항의 위험 감소
• 요구 사항이 변경되거나 커밋되지 않은 경우 적합
• 정기적으로 가시적인 프로세스가 관리를 돕습니다.
• 초기 제품 마케팅 지원
• 유지 보수 비용을 줄입니다.
• 시스템이 나란히 만들어지기 때문에 오류를 훨씬 일찍 감지할 수 있습니다.

Prototype 모델의 단점

• 불안정하거나 잘못 구현된 프로토타입이 종종 최종 제품이 됩니다.
• 광범위한 고객 협업 필요
  - 비용 고객 비용
  - 헌신적인 고객 필요
  - 고객이 철회하면 완료하기 어려움
• 너무 고객에 따라 다르고 시장이 넓지 않을 수 있음
• 프로젝트가 얼마나 지속될지 알기 어렵습니다.
  적절한 요구 사항 분석, 설계, 고객 평가 및 피드백 없이 코드로 돌아가 수정하기 쉽습니다.
• 프로토타이핑 도구는 비싸다.
• 프로토타입을 제작하려면 특별한 도구와 기술이 필요합니다.
• 시간이 많이 걸리는 과정입니다.

 

Evolutionary Process Model (진화 과정 모델)

진화적 프로세스 모델은 반복적 향상 모델과 유사합니다. 폭포수 모델에 대해 동일한 단계가 정의되어 순환 방식으로 여기에서 발생합니다. 이 모델은 각 주기가 끝날 때 유용한 제품이 필요하지 않다는 점에서 반복 향상 모델과 다릅니다. 진화적 개발에서 요구 사항은 우선순위가 아닌 범주별로 구현됩니다.

예를 들어, 간단한 데이터베이스 응용 프로그램에서 한 주기는 GUI(그래픽 사용자 인터페이스), 다른 파일 조작, 다른 쿼리 및 다른 업데이트를 구현할 수 있습니다. 작동 제품을 사용할 수 있으려면 4개의 사이클이 모두 완료되어야 합니다. 

진화 과정 모델의 이점 (Benefits)

EVO를 사용하면 소프트웨어 프로젝트의 위험을 크게 줄일 수 있습니다.

• EVO는 실험을 위한 체계적이고 훈련된 방법을 제공하여 비용을 절감할 수 있습니다.
• EVO를 사용하면 마케팅 부서에서 조기 납품에 액세스할 수 있으므로 문서 및 데모 개발이 용이합니다.
• 사용자 요구와 시장 요구 사항에 더 잘 맞는 제품.
• 초기 주기 내용의 정의로 프로젝트 위험을 관리합니다.
• 핵심 문제를 조기에 발견하고 적절하게 주의를 집중하십시오.
• 시장 창구에 도달할 기회를 늘립니다.
• 초기 고객 노출로 판매 주기를 가속화합니다.
• 프로젝트 진행 상황에 대한 관리 가시성을 높입니다.
• 제품 팀의 생산성과 동기를 높입니다.