레슨 2: 소프트웨어 개발 생명주기¶

이전: 소프트웨어 공학이란 무엇인가 | 다음: 애자일과 반복적 개발

모든 소프트웨어 시스템은 개념 정립부터 폐기에 이르기까지 예측 가능한 일련의 단계를 거칩니다. 소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC)는 이러한 단계, 각 단계의 활동, 생성되는 산출물, 그리고 한 단계에서 다음 단계로 이동하기 위한 기준을 정의하는 구조화된 프로세스입니다. 적절한 SDLC 모델을 선택하는 것은 프로젝트 시작 시 내리는 가장 중요한 결정 중 하나입니다.

난이도: ⭐⭐

선수 학습: - 레슨 1: 소프트웨어 공학이란 무엇인가 - 소프트웨어 프로젝트에 대한 기본적인 이해

학습 목표: - 소프트웨어 개발 생명주기의 표준 단계를 설명한다 - 폭포수(Waterfall), V-모델(V-Model), 점진적(Incremental), 나선형(Spiral), RAD, 프로토타이핑(Prototyping) 모델을 설명한다 - 각 모델의 강점, 약점, 적합한 사용 사례를 식별한다 - 주어진 프로젝트에 적합한 모델을 선택하기 위한 의사결정 프레임워크를 적용한다 - 프로세스 모델이 리스크, 요구사항 안정성, 팀 규모와 어떻게 관련되는지 이해한다

1. SDLC 개요¶

소프트웨어 개발 생명주기는 초기 아이디어부터 폐기까지 소프트웨어 개발을 안내하는 구조를 설명합니다. 특정 모델과 관계없이 대부분의 SDLC 프레임워크는 다음과 같은 핵심 단계의 변형을 포함합니다:

┌─────────────────────────────────────────────────────────────────┐
│                   SDLC 핵심 단계                                 │
│                                                                 │
│  1. 계획      ──►  프로젝트는 무엇인가? 실현 가능한가?           │
│  2. 요구사항  ──►  소프트웨어는 무엇을 해야 하는가?              │
│  3. 설계      ──►  어떻게 구조화될 것인가?                       │
│  4. 구현      ──►  코드 작성                                     │
│  5. 테스트    ──►  올바르게 작동하는지 검증                       │
│  6. 배포      ──►  프로덕션 환경에 릴리스                        │
│  7. 유지보수  ──►  결함 수정, 시간 경과에 따른 기능 추가          │
└─────────────────────────────────────────────────────────────────┘

단계 1: 계획(Planning)¶

목표: 프로젝트가 진행할 가치가 있는지, 어떻게 접근할 것인지 결정합니다.

활동: - 프로젝트 범위와 목표 정의 - 이해관계자 식별 - 타당성 검토 수행 (기술적, 재정적, 법적, 운영적) - 높은 수준에서 비용과 일정 추정 - 팀과 역할 정의 - SDLC 모델 선택

주요 산출물: 프로젝트 헌장, 타당성 보고서, 초기 프로젝트 계획

단계 2: 요구사항 공학(Requirements Engineering)¶

목표: 소프트웨어가 정확히 무엇을 해야 하는지 이해하고 문서화합니다.

활동: - 인터뷰, 워크숍, 관찰을 통한 요구사항 도출 - 요구사항 분석 및 우선순위 결정 - 기능적 요구사항과 비기능적 요구사항 문서화 - 이해관계자와 요구사항 검증 - 요구사항 변경 관리

주요 산출물: 소프트웨어 요구사항 명세서(SRS), 유스케이스, 사용자 스토리

단계 3: 설계(Design)¶

목표: 시스템이 어떻게 구축될지 결정합니다.

활동: - 아키텍처 설계 (높은 수준의 구조: 컴포넌트, 레이어, 인터페이스) - 상세 설계 (클래스 구조, 데이터 스키마, 알고리즘) - UI/UX 설계 - 데이터베이스 설계 - 보안 설계

주요 산출물: 아키텍처 문서, 상세 설계 명세서, 데이터베이스 스키마, API 계약

단계 4: 구현(Implementation, 코딩)¶

목표: 설계를 작동하는 코드로 변환합니다.

활동: - 설계 명세서에 따른 소스 코드 작성 - 코드 리뷰 - 개발자가 수행하는 단위 테스트 - 컴포넌트 통합

주요 산출물: 소스 코드, 빌드 산출물, 단위 테스트

단계 5: 테스트(Testing)¶

목표: 소프트웨어가 요구사항을 충족하고 올바르게 작동하는지 검증합니다.

활동: - 시스템 테스트 (종단 간 검증) - 통합 테스트 - 성능 테스트, 보안 테스트 - 사용자 인수 테스트(UAT) - 결함 보고 및 해결

주요 산출물: 테스트 계획, 테스트 케이스, 결함 보고서, 테스트 결과

단계 6: 배포(Deployment)¶

목표: 소프트웨어를 의도한 환경과 사용자에게 릴리스합니다.

활동: - 배포 계획 및 롤백 절차 - 프로덕션 환경 구성 - 사용자 교육 및 문서화 - 레거시 시스템에서의 전환 (해당하는 경우)

주요 산출물: 배포 계획, 릴리스 노트, 사용자 매뉴얼

단계 7: 유지보수 및 발전(Maintenance and Evolution)¶

목표: 소프트웨어가 운영 가능한 상태를 유지하고 변화하는 요구사항을 충족하도록 발전시킵니다.

활동: - 프로덕션에서 발견된 결함 수정 (교정적 유지보수) - 새로운 환경에 적응 (적응적 유지보수) - 새로운 기능 추가 (완전화 유지보수) - 미래의 장애 예방 (예방적 유지보수)

주요 산출물: 변경 요청, 업데이트된 문서, 새 릴리스

2. 폭포수 모델(Waterfall Model)¶

폭포수 모델은 Winston Royce가 1970년 논문 "대형 소프트웨어 시스템 개발 관리(Managing the Development of Large Software Systems)"에서 설명한 최초의 공식 SDLC 모델입니다. Royce가 실제로는 순수한 순차적 개발이 위험하다고 주장하며 반복적 접근 방식을 권장했음에도 불구하고, 순차적 해석이 수십 년간 지배적인 모델이 되었습니다.

구조¶

각 단계는 완전히 완료되고 공식적으로 승인된 후에야 다음 단계가 시작됩니다. 이전 단계로 돌아가는 것은 가능하지만 예외적인 경우로 취급됩니다.

단계 게이트 기준¶

단계 게이트	진입 기준	완료 기준
요구사항 → 설계	프로젝트 승인, 팀 구성	서명된 SRS 문서
설계 → 구현	승인된 SRS	서명된 설계 문서
구현 → 테스트	승인된 설계	코드 완성, 단위 테스트 통과
테스트 → 배포	코드 완성	모든 심각한 결함 해결, UAT 통과
배포 → 유지보수	UAT 서명	프로덕션 배포 완료

강점¶

명확성: 프로세스가 이해하고 관리하기 쉬움
문서화: 각 단계에서 포괄적인 문서 생성
단계 제어: 명확한 마일스톤으로 진행 상황 측정 가능
안정적인 요구사항에 적합: 구축할 것이 잘 이해되고 변경 가능성이 낮은 경우, 순차적 개발이 효율적
공급업체 계약: 외부 공급업체와의 고정 범위 계약은 폭포수 방식으로 관리하기 쉬움

약점¶

결함의 늦은 발견: 테스트가 늦게 수행되어 테스트 단계에서 발견된 결함을 수정하는 비용이 높음
늦게까지 작동하는 소프트웨어 없음: 이해관계자는 테스트나 배포까지 아무것도 볼 수 없음
변화하는 요구사항에 부적합: 프로세스 후반부의 변경은 이전 단계의 비용이 많이 드는 재작업이 필요
완벽한 요구사항 가정: 실제로는 시작 시점에 요구사항이 완전히 알려지는 경우는 거의 없음
통합 문제의 늦은 발견: 컴포넌트가 서로 맞지 않으면 통합 테스트 중에 발견됨

폭포수 모델 사용 시기¶

요구사항이 잘 정의되어 있고 안정적이며 변경 가능성이 낮은 경우
기술이 잘 이해되어 있는 경우 (주요 R&D 없음)
개발 중 변경 가능성이 낮을 만큼 프로젝트가 충분히 짧은 경우
규제 또는 계약 요구사항으로 포괄적인 문서화가 의무화된 경우
고정 범위 납품물로 외부 계약업체와 협력하는 경우

실제 사례: 정부 기관이 법적으로 규정된 계산 규칙이 있는 급여 시스템을 구축하기 위해 공급업체와 계약을 체결합니다. 요구사항은 법령으로 정의되어 있으며 18개월 프로젝트 기간 동안 변경 가능성이 낮습니다. 폭포수 모델이 적절합니다.

3. V-모델(V-Model, 검증 및 확인 모델)¶

V-모델은 각 개발 단계를 대응하는 테스트 단계에 명시적으로 매핑하여 폭포수 모델을 확장합니다. V의 왼쪽은 분해(요구사항 분해)를 나타내고, 오른쪽은 검증(Verification)과 확인(Validation)을 나타냅니다.

구조¶

요구사항 ──────────────────────────── 인수 테스트
    │                                      │
    ▼                                      │
시스템 설계 ──────────────────── 시스템 테스트 │
    │                                │         │
    ▼                                │         │
아키텍처 설계 ──── 통합 테스트     │
    │                          │              │
    ▼                          │              │
모듈 설계 ── 단위 테스트      │              │
    │              │           │              │
    └── 코딩 ──────┘           │              │
                               │              │
        ◄── 검증(Verification) ┘──── 확인(Validation) ──►

왼쪽 (검증(Verification) — "제품을 올바르게 만들기")¶

각 단계는 테스트를 이끌기 위해 사용될 명세를 생성합니다: - 요구사항 → 인수 테스트 기준 정의 - 시스템 설계 → 시스템 테스트 기준 정의 - 아키텍처 설계 → 통합 테스트 기준 정의 - 모듈 설계 → 단위 테스트 기준 정의

오른쪽 (확인(Validation) — "올바른 제품 만들기")¶

테스트는 나중에 실행되더라도 대응하는 왼쪽 단계와 병렬로 설계됩니다: - 단위 테스트: 모듈 설계에 대해 개별 모듈을 검증 - 통합 테스트: 아키텍처 설계에 대해 모듈 상호작용을 검증 - 시스템 테스트: 시스템 설계에 대해 전체 시스템을 검증 - 인수 테스트: 사용자 요구사항에 대해 시스템을 확인

폭포수 모델 대비 강점¶

테스트가 처음부터 계획되어 일급 시민으로 취급됨
결함을 더 낮은 수준에서 발견 가능 (시스템 테스트 전에 단위 테스트)
요구사항에서 테스트까지의 명확한 추적성
안전 필수 시스템(항공우주, 의료, 국방)에 적합

약점¶

여전히 대체로 순차적; 변화하는 요구사항에 대한 수용도가 제한적
높은 문서화 부담
탐색적이거나 혁신적인 프로젝트에 부적합

실제 사례: 의료용 주입 펌프의 임베디드 소프트웨어를 개발하려면 FDA 규정에 의해 모든 요구사항에서 특정 테스트까지의 추적성이 필요합니다. V-모델의 명시적인 검증/확인 매핑이 규제 요구사항을 충족합니다.

4. 점진적 모델(Incremental Model)¶

점진적 모델은 이전 빌드에 기능을 추가하는 일련의 빌드(증분)로 시스템을 제공합니다. 요구사항은 일반적으로 사전에 정의되지만, 구현은 단계적으로 진행됩니다.

구조¶

요구사항 ──► 사전에 모두 계획 (또는 부분적으로)
    │
    ├──► 증분 1: 핵심 기능
    │         설계 ► 코딩 ► 테스트 ► 배포
    │                                  │
    ├──► 증분 2: 추가 기능
    │         설계 ► 코딩 ► 테스트 ► 배포
    │                                  │
    ├──► 증분 3: 확장 기능
    │         설계 ► 코딩 ► 테스트 ► 배포
    │                                  │
    └──► 증분 N: 최종 기능
              설계 ► 코딩 ► 테스트 ► 배포

강점¶

폭포수보다 일찍 작동하는 소프트웨어 제공
높은 우선순위의 기능을 더 빨리 사용 가능
사용자가 초기 증분에 대한 피드백 제공 가능
리스크 감소: 초기에 발견된 문제를 수정 가능

약점¶

초기에 좋은 아키텍처 구상 필요 (각 증분이 전체 설계에 맞아야 함)
주의하지 않으면 "패치된" 아키텍처로 이어질 수 있음
이후 증분의 요구사항이 잘 정의되지 않을 수 있음

5. 나선형 모델(Spiral Model)¶

Barry Boehm은 1988년 논문 "소프트웨어 개발 및 개선의 나선형 모델(A Spiral Model of Software Development and Enhancement)"에서 나선형 모델을 소개했습니다. 나선형 모델은 리스크 중심적입니다: 나선의 각 주기는 진행하기 전에 가장 중요한 리스크를 식별하고 완화하는 데 중점을 둡니다.

구조¶

나선형은 각 주기에서 반복되는 네 개의 사분면으로 구성됩니다:

            목표, 대안, 제약 사항 결정
                    │
                    ▼
    ┌───────────────────────────────┐
    │    사분면 1: 계획             │
    │  ┌──────────────────────────┐ │
    │  │       사분면 4:          │ │
    │  │    다음 반복 계획        │◄├─── 누적 리스크 ──►
    │  │                          │ │                   │
    │  └──────────────────────────┘ │    사분면 2:      │
    └───────────────────────────────┘   리스크 분석     │
                    │                        │          │
                    ▼                        ▼          │
            대안 평가,               리스크 식별,       │
            리스크 식별 및 해결       분석, 해결        │
                                           │          │
                    ┌──────────────────────┘          │
                    ▼                                  │
            사분면 3: 개발 및 테스트                   │
            (현재 증분 설계, 코딩, 테스트)              │
                    │                                  │
                    └───────────────────────────────────┘

더 정확하게, 각 나선형 주기는 다음을 포함합니다:

목표 결정: 이 주기에서 무엇을 달성해야 하는가? 제약 사항은 무엇인가?
리스크 식별 및 해결: 무엇이 잘못될 수 있는가? 불확실한 영역을 테스트하기 위한 프로토타입 구축.
개발 및 검증: 이 주기를 위한 제품 개발 및 테스트.
다음 주기 계획: 이해관계자와 검토하고 진행 여부 결정.

리스크 중심 특성¶

나선형 모델은 각 반복의 중심에 리스크 분석을 두는 점에서 독특합니다. 리스크를 합리적인 비용으로 해결할 수 없다면 프로젝트가 조기에 종료될 수 있습니다 — 이것은 결함이 아니라 특징으로, 실패가 예정된 프로젝트에 추가 투자를 방지합니다.

초기 나선형에서 다루는 리스크 예시: - "사용자가 이 인터페이스를 채택할지 확신할 수 없다" → 프로토타입을 구축하고 사용자와 테스트 - "이 알고리즘이 충분히 빠를지 알 수 없다" → 성능 스파이크 구축 - "공급업체의 API가 우리 요구사항을 지원하지 않을 수 있다" → 통합 개념 증명 작성

강점¶

탁월한 리스크 관리
유연성: 나선형 사이에서 변화하는 요구사항 수용 가능
초기 프로토타이핑으로 잘못된 제품을 구축할 가능성 감소
크고 복잡하며 고위험 프로젝트에 적합

약점¶

상당한 리스크 관리 전문 지식 필요
비용이 높을 수 있음 (각 나선형 주기에 오버헤드 발생)
작고 저위험 프로젝트에 부적합
종료 날짜 예측 불가능

실제 사례: 새로운 지휘통제 시스템을 개발하는 방위 계약업체는 상당한 기술적 리스크(새로운 통신 프로토콜), 조직적 리스크(변화하는 요구사항), 일정 리스크에 직면합니다. 나선형 모델은 전체 개발에 착수하기 전에 각 리스크를 체계적으로 해결할 수 있게 합니다.

6. RAD(Rapid Application Development, 신속 응용 프로그램 개발)¶

James Martin이 1990년대 초에 개발한 RAD는 타임박싱, 재사용, 높은 사용자 참여를 통한 매우 빠른 개발을 강조합니다. RAD는 일반적으로 60–90일 납품 주기를 목표로 합니다.

핵심 원칙¶

타임박싱(Timeboxing): 남은 작업량에 관계없이 고정된 기간 (일반적으로 60–90일)
프로토타이핑: 높은 사용자 피드백을 통한 지속적인 프로토타입 개선
SWAT 팀: 소규모의 고도로 숙련된 팀 (Skilled With Advanced Tools)
재사용: 기존 컴포넌트, 프레임워크, 도구의 최대 활용
지속적인 사용자 참여: 사용자가 요구사항과 UAT뿐만 아니라 개발 전반에 걸쳐 참여

RAD 단계¶

1. 요구사항 계획 ──► 비즈니스 목표와 제약 사항 식별
2. 사용자 설계   ──► 사용자와의 인터랙티브 프로토타이핑 (반복적)
3. 구축          ──► 승인된 프로토타입 기반의 신속한 코딩
4. 전환          ──► 테스트, 배포, 사용자 교육

강점¶

작동하는 소프트웨어의 빠른 납품
높은 사용자 만족도 (높은 참여)
잘못된 제품을 구축할 가능성 감소

약점¶

고도로 숙련되고 가용한 사용자 필요 (이해관계자 시간이 주요 제약)
새로운 기술이나 복잡한 알고리즘이 필요한 프로젝트에 부적합
대규모 시스템의 확장성 문제
품질보다 속도를 우선시하면 성능이나 아키텍처가 낮은 시스템 생성 가능

7. 프로토타이핑 모델(Prototyping Model)¶

프로토타이핑 모델은 전체 개발에 착수하기 전에 요구사항을 명확히 하고 아이디어를 테스트하기 위해 작동하지만 불완전한 버전의 시스템을 구축합니다.

프로토타입 유형¶

폐기형(탐색적) 프로토타이핑: 특정 질문에 답하기 위한 빠른 프로토타입을 구축한 후 폐기합니다. 프로토타입은 프로덕션 코드가 아니라 학습을 위한 도구입니다.

진화형 프로토타이핑: 프로토타입을 최종 제품으로 점진적으로 구축합니다. 프로토타입 코드가 품질 문제를 프로덕션으로 가져올 수 있어 더 위험합니다.

프로세스¶

┌─────────────────────────────────┐
│  1. 기본 요구사항 식별           │
└────────────┬────────────────────┘
             │
             ▼
┌─────────────────────────────────┐
│  2. 프로토타입 구축             │◄─────────────┐
└────────────┬────────────────────┘             │
             │                                  │
             ▼                                  │
┌─────────────────────────────────┐             │
│  3. 사용자 프로토타입 평가      │             │
└────────────┬────────────────────┘             │
             │                                  │
             ▼                                  │
       수용 가능? ──── 아니오 ──────────────────┘
             │
            예
             │
             ▼
┌─────────────────────────────────┐
│  4. 최종 시스템 구축            │
└─────────────────────────────────┘

프로토타이핑 사용 시기¶

요구사항이 불명확하거나 진화하는 경우
사용자 인터페이스 설계가 주요 관심사인 경우
새로운 기술의 타당성 탐색
더 큰 프로세스 모델의 일부로 (예: 나선형의 리스크 해결 단계에서 프로토타이핑)

8. SDLC 모델 비교¶

모델	요구사항	납품	리스크	문서화	최적 사용 대상
폭포수	사전에 안정적이어야 함	늦음 (단일 릴리스)	요구사항 오류 시 높음	포괄적	안정적이고 잘 이해된 프로젝트
V-모델	사전에 안정적이어야 함	늦음 (단일 릴리스)	중간 (더 나은 테스트)	매우 포괄적	안전 필수 시스템
점진적	대부분 사전에	단계적 릴리스	중간	보통	우선순위 기반 납품
나선형	진화적	나선형별 릴리스	낮음 (리스크 중심)	보통 ~ 높음	크고 고위험 프로젝트
RAD	빠르게 협상	매우 빠름	단순 프로젝트에서 낮음	가벼움	잘 이해된 비즈니스 도메인
프로토타이핑	초기에 불명확	프로토타입 승인 후	요구사항에서 낮음	가벼움	불명확한 요구사항, UI 중심
애자일*	스프린트마다 진화	지속적	낮음	경량	동적 요구사항, 집중 팀

*애자일은 레슨 3에서 다룹니다.

9. 올바른 모델 선택¶

어떤 모델도 보편적으로 최선은 아닙니다. 선택은 여러 프로젝트 요소에 따라 달라집니다:

의사결정 프레임워크¶

프로젝트가 안전 필수적이거나 고도로 규제받는가?
    └─ 예 → 엄격한 문서화를 갖춘 V-모델 또는 폭포수
    └─ 아니오 ↓

요구사항이 잘 이해되고 안정적인가?
    └─ 예 → 폭포수 또는 점진적
    └─ 아니오 ↓

상당한 기술적 또는 비즈니스 리스크가 있는가?
    └─ 예 → 나선형
    └─ 아니오 ↓

납품 속도가 주요 관심사인가?
    └─ 예 → RAD (소규모 팀, 비즈니스 도메인)
    └─ 아니오 ↓

요구사항이 자주 변경될 것으로 예상되는가?
    └─ 예 → 애자일 (스크럼, 칸반 — 레슨 3 참조)
    └─ 아니오 → 점진적

주요 의사결정 기준¶

요소	순차적 방식 선호 (폭포수/V)	반복적/애자일 방식 선호
요구사항 안정성	안정적, 잘 정의됨	가변적, 불명확
팀 규모	크고 분산됨	소~중, 집중
고객 가용성	제한적	높음 (빈번한 피드백)
프로젝트 기간	단~중기	중~장기
기술 참신성	알려진 기술	최첨단 또는 불확실
규제 환경	높은 규제	낮은 규제
계약 유형	고정 가격, 고정 범위	시간 및 재료 기준

10. 실제 사례¶

사례 1: NASA 미션 소프트웨어 (V-모델)¶

유인 미션을 위한 NASA의 비행 소프트웨어는 각 단계에서 공식 검증을 수행하는 엄격한 V-모델 프로세스를 사용합니다. 요구사항은 테스트까지 추적 가능하며, 모든 테스트는 독립적인 팀이 검토합니다. 우주에서의 결함 비용은 잠재적으로 치명적이므로 무거운 프로세스 오버헤드를 정당화합니다.

사례 2: 전자상거래 스타트업 (애자일/점진적)¶

온라인 마켓플레이스를 출시하는 스타트업은 시장에 빠르게 진출하고 사용자 피드백을 수집하며 효과적인 것을 기반으로 방향을 전환해야 합니다. 폭포수는 치명적일 것입니다 — 18개월 후 전체 시스템이 납품될 즈음에는 시장이 변해 있을 수 있습니다. 격주 릴리스를 통한 애자일 방식은 팀이 지속적으로 학습하고 적응할 수 있게 합니다.

사례 3: 은행 핵심 시스템 교체 (나선형)¶

30년 된 핵심 뱅킹 시스템을 교체하는 대형 은행은 엄청난 기술적 리스크(메인프레임 마이그레이션), 비즈니스 리스크(규제 준수), 조직적 리스크(수천 명의 직원 교육)에 직면합니다. 나선형 모델은 은행이 가장 위험한 통합을 초기에 프로토타이핑하고 규제 기관과 검증한 후, 중요한 리스크가 해결된 후에만 전체 개발로 진행할 수 있게 합니다.

사례 4: 내부 HR 도구 (RAD)¶

회사의 HR 부서는 직원 자격증 추적을 위한 새 도구가 필요합니다. 요구사항이 간단하고, 도메인이 잘 이해되어 있으며, 두 명의 개발자로 구성된 소규모 팀이 HR 관리자의 높은 참여로 6주 안에 납품할 수 있습니다. RAD (또는 간단한 반복적 방식)가 적절합니다.

요약¶

소프트웨어 개발 생명주기는 소프트웨어가 구축되는 구조적 프레임워크를 제공합니다. SDLC 모델의 선택은 팀이 어떻게 구성되는지, 납품물이 언제 생성되는지, 리스크가 어떻게 관리되는지, 변경이 어떻게 처리되는지 등 프로젝트의 모든 측면을 형성합니다.

주요 시사점: - 폭포수는 순차적이고 문서화가 많으며, 안정적이고 잘 이해된 요구사항에 적합 - V-모델은 각 단계에서 명시적인 테스트 계획으로 폭포수를 확장; 안전 필수 시스템에 선호 - 점진적은 단계적으로 소프트웨어를 납품; 구조와 더 이른 납품 간의 균형 - 나선형은 리스크 중심; 각 반복은 가장 중요한 리스크를 먼저 해결 - RAD는 타임박싱과 사용자 참여를 통해 극도의 속도를 강조 - 프로토타이핑은 전체 개발 전에 요구사항을 명확히 하기 위한 불완전한 시스템을 구축 - 어떤 단일 모델도 보편적으로 최선은 아니며, 선택은 요구사항 안정성, 리스크, 팀 규모, 규제 맥락에 따라 달라짐

연습 문제¶

연습 1: 시 정부가 전시 800개 교차로를 제어하는 새 교통 관리 시스템을 구축하고 있습니다. 프로젝트는 고정 예산, 안전 인증을 위한 규제 요구사항이 있으며 완성까지 3년이 주어집니다. 어떤 SDLC 모델을 추천하시겠습니까? 9절의 의사결정 기준 중 최소 세 가지를 다루어 선택을 정당화하세요.

연습 2: 다음 프로젝트의 폭포수 타임라인을 그리세요: 회사는 직원들이 경비 보고서를 제출할 수 있는 모바일 앱이 필요합니다. 앱은 회사의 기존 SAP ERP 시스템과 통합되어야 합니다. 각 단계의 기간을 (전체 프로젝트 시간의 백분율로) 추정하고 각 단계에서 생성되는 두 가지 주요 산출물을 나열하세요.

연습 3: 새로운 소셜 네트워킹 스타트업이 플랫폼을 구축하고 싶지만 사용자가 원하는 기능에 대한 대략적인 아이디어만 있습니다. 폭포수가 왜 좋지 않은 선택인지 설명하세요. 첫 6주 동안의 3-스프린트 점진적 계획을 설계하고, 각 증분에 포함될 기능을 명시하세요.

연습 4: V-모델과 폭포수 모델을 비교하세요. 다섯 가지 구체적인 차이점을 나열한 표를 만드세요. 더 높은 문서화 부담에도 불구하고 V-모델을 폭포수보다 선택하는 상황은 언제인가요?

연습 5: 나선형 모델은 리스크를 해결하기 위해 프로토타입을 사용합니다. 은행을 위한 실시간 사기 감지 시스템을 구축하는 프로젝트에서 세 가지 중요한 리스크를 식별하고, 각 리스크를 해결하기 위한 초기 나선형에서 구축할 프로토타입이나 스파이크를 설명하세요.

더 읽을거리¶

Winston W. Royce, "Managing the Development of Large Software Systems" (1970) — 폭포수로 알려지게 된 것을 소개한 논문
Barry W. Boehm, "A Spiral Model of Software Development and Enhancement" (1988) — IEEE Computer, Vol. 21, No. 5
James Martin, Rapid Application Development (1991) — Macmillan
Ian Sommerville, Software Engineering (10th ed.) — 2장과 3장에서 프로세스 모델을 심도 있게 다룸
Roger Pressman, Software Engineering: A Practitioner's Approach — 2장: 프로세스 모델
SEI CMMI: https://cmmiinstitute.com — 모든 프로세스 모델에 걸쳐 있는 능력 성숙도 모델 통합

이전: 소프트웨어 공학이란 무엇인가 | 다음: 애자일과 반복적 개발