소프트웨어 생명주기와 개발 방법론
폭포수·프로토타입·나선형·V 모델·반복개발·애자일과 일정·비용 추정의 핵심을 학습한다.
1. 소프트웨어 생명주기
소프트웨어 생명주기는 요구 파악부터 운영·폐기까지 소프트웨어가 거치는 활동의 흐름이다.
기획·타당성
↓
요구사항
↓
분석·설계
↓
구현
↓
테스트
↓
배포·운영
↓
유지보수·개선·폐기
실제 프로젝트에서는 단계가 완전히 한 번씩만 진행되지 않고 반복·병행될 수 있다. 프로세스 모델은 이 활동을 어떤 순서와 통제로 수행할지 정한다.
2. 폭포수 모델
폭포수는 단계별 산출물을 확인하고 다음 단계로 진행하는 선형 순차 모델이다.
요구 → 분석 → 설계 → 구현 → 테스트 → 운영
장점은 단계·책임·산출물이 명확하고 계획 관리가 비교적 쉽다는 점이다. 요구가 안정적이고 규제·계약 문서가 중요한 환경에 적합할 수 있다. 반면 후반에 요구 오류를 발견하면 수정 비용이 커지고 변화 대응이 경직될 수 있다.
3. 프로토타입 모델
핵심 기능이나 UI의 시제품을 빠르게 만들어 요구를 확인한다.
초기 요구 → 빠른 설계 → 프로토타입 → 사용자 평가
▲ │
└──────────── 요구 보완 ◄──────────────┘
↓
본 시스템 개발
- 폐기형: 요구 확인 후 버리고 정식 시스템을 새로 개발
- 진화형: 반복 개선해 최종 시스템으로 발전
프로토타입 코드를 품질 검토 없이 그대로 운영 코드로 전환하면 구조·보안·성능 문제가 남을 수 있다.
4. 나선형 모델
보헴이 제안한 위험 중심의 반복 모델이다.
목표·대안 결정
↓
위험 분석·프로토타입
↓
개발·검증
↓
다음 반복 계획
└────────► 다시 반복
대규모·고위험 시스템에서 위험을 조기에 식별하고 반복마다 완성도를 높이는 데 적합하다.
5. V 모델
V 모델은 개발 단계와 대응 테스트 단계를 연결한다.
사용자 요구 인수 테스트
\ /
시스템 요구 시스템 테스트
\ /
아키텍처 설계 통합 테스트
\ /
상세 설계 단위 테스트
\ /
구현
왼쪽은 명세·설계, 오른쪽은 검증·확인 활동이다.
6. 반복·증분 개발
- 반복: 같은 제품을 여러 번 학습·개선
- 증분: 기능 일부를 완성된 형태로 순차 제공
반복 1: 핵심 기능 A ─► 실행 가능한 제품
반복 2: 기능 B 추가 ─► 더 넓은 제품
반복 3: 기능 C 개선 ─► 품질과 범위 확대
7. 애자일과 Scrum
애자일은 변화 대응, 짧은 피드백, 동작하는 소프트웨어, 협업을 중시한다. 문서나 계획을 없애는 것이 아니라 가치 전달에 필요한 수준으로 유지한다.
| 구분 | Scrum 요소 |
|---|---|
| 책임 | Product Owner, Scrum Master, Developers |
| 이벤트 | Sprint, Planning, Daily Scrum, Review, Retrospective |
| 산출물 | Product Backlog, Sprint Backlog, Increment |
Product Backlog
↓ Sprint Planning
Sprint Backlog
↓ Sprint
설계·개발·테스트
↓
사용 가능한 Increment
↓ Review·Retrospective
Backlog 조정 후 다음 Sprint
8. DevOps와 방법론의 관계
DevOps는 개발과 운영의 협업, 자동화, 빠른 피드백, 지속적 개선을 강조하는 문화·실천 체계이다.
Plan → Code → Build → Test → Release → Deploy → Operate → Monitor
▲ │
└────────────────────── 피드백 ───────────────────────────────┘
Scrum 같은 관리 프레임워크를 대체한다기보다 빌드·테스트·배포·운영까지 흐름을 확장한다.
9. 규모·비용 추정
- 기능점수: 입력·출력·조회·내부 논리 파일·외부 인터페이스 기능을 이용해 규모를 계량한다.
- COCOMO: 소프트웨어 규모와 프로젝트 특성을 이용해 노력과 일정을 추정하는 모델 계열이다.
- 브룩스의 법칙: 지연된 프로젝트 후반에 인력을 무작정 추가하면 교육과 의사소통 비용 때문에 더 늦어질 수 있다.
10. 일정 계획
WBS
프로젝트 범위를 관리 가능한 작업 단위로 계층 분해한다.
시스템 구축
├─ 요구사항
│ ├─ 인터뷰
│ └─ 요구 명세
├─ 개발
│ ├─ API
│ └─ 화면
└─ 테스트
├─ 통합 테스트
└─ 인수 테스트
PERT
기대시간 = (낙관치 O + 4×최빈치 M + 비관치 P) / 6
CPM
작업 선후관계와 소요시간을 이용해 전체 일정에 직접 영향을 주는 임계경로를 찾는다.
Start ─ A(3) ─ C(4) ─ End = 7
└── B(2) ─ D(6) ─ End = 8 ← 임계경로
임계경로 작업의 여유시간은 일반적으로 0이며, 해당 작업이 지연되면 전체 일정이 지연될 수 있다.
11. 방법론 선택 기준
| 상황 | 상대적으로 적합한 접근 |
|---|---|
| 요구 안정·계약 산출물 중요 | 폭포수·V 모델 요소 |
| 요구가 모호하고 UI 피드백 필요 | 프로토타입 |
| 기술·안전 위험이 큼 | 나선형 위험관리 |
| 변화가 빠르고 작은 증분 제공 | 반복·증분·애자일 |
| 빈번한 배포·운영 피드백 | DevOps 실천 |
12. Scrum의 목표와 완료 기준
Product Backlog ↔ Product Goal
Sprint Backlog ↔ Sprint Goal
Increment ↔ Definition of Done
- Product Goal: 제품이 향하는 장기 목표
- Sprint Goal: 이번 Sprint가 제공할 단일한 목적
- Definition of Done: Increment가 품질 기준을 충족해 완료됐다고 판단하는 공통 기준
Sprint 중에도 범위를 더 명확히 하고 Product Owner와 재협상할 수 있지만 Sprint Goal을 위험하게 만드는 변경은 피해야 한다. velocity는 같은 팀의 단기 계획 보조값이며 팀 간 생산성 순위로 사용하면 추정 단위 차이와 품질 희생을 부른다.
13. PERT 분산과 프로젝트 불확실성
기대시간 te = (O + 4M + P) / 6
표준편차 σ = (P - O) / 6
분산 σ² = ((P - O) / 6)²
독립 작업을 가정한 단순 PERT 계산에서는 임계경로 작업의 분산을 더해 프로젝트 분산을 구하고, 제곱근으로 표준편차를 구한다.
14. CPM의 전진·후진 계산
ES: Earliest Start EF = ES + duration
LF: Latest Finish LS = LF - duration
Total Float = LS - ES = LF - EF
전진 계산으로 가장 빠른 완료 시각을 구하고, 후진 계산으로 프로젝트를 늦추지 않는 가장 늦은 시각을 구한다. 총여유가 0인 경로가 임계경로가 된다.
15. 일정 단축 전략
- Crashing: 비용을 추가해 임계 작업의 기간을 줄임
- Fast Tracking: 원래 순차 작업을 일부 병렬 수행해 기간을 줄임
Crashing은 비용 증가, Fast Tracking은 재작업·조정 위험 증가가 대표적인 대가다. 임계경로가 아닌 작업만 줄여서는 전체 일정이 단축되지 않을 수 있다.
16. COCOMO 계산 전제
기본 COCOMO 형태는 다음과 같다.
노력(Person-Month) = a × (KLOC)^b
개발기간(Month) = c × (Effort)^d
계수는 프로젝트 모드와 모델 버전에 따라 달라지므로 문제에서 주어진 값을 사용한다. KLOC 단위, 반올림 시점, 사람 수를 단순히 노력/기간으로 해석하는 전제도 확인해야 한다.
확인 문제
- Increment의 공통 완료 품질 기준을 무엇이라 하는가?
- PERT에서 O=2, M=5, P=8일 때 분산은 얼마인가?
- CPM에서 ES=4, LS=7인 작업의 총여유는 얼마인가?
- 비용을 추가해 임계 작업 기간을 줄이는 일정 단축 기법은 무엇인가?
- velocity를 서로 다른 팀의 생산성 순위로 사용하면 안 되는 이유는 무엇인가?