🔷 1. SDLC의 개요
| 정의 | 소프트웨어의 기획, 개발, 운용, 폐기까지의 모든 과정을 단계적으로 정의한 개발 생명주기 |
| 등장 배경 | SW 대규모화로 인한 품질/납기 문제 해결, 체계적인 관리 필요성 증가 |
| 적용 목적 | 고품질 소프트웨어 개발, 프로젝트 관리 효율화, 자원 효율적 사용, 개발 표준화 |
🔷 2. SDLC 단계별 상세 설명
1단계. 요구사항 수집 및 분석 (Requirement Analysis)
목적: 이해관계자(관리자, 사용자, 개발자 등)의 요구사항과 제약조건을 수집, 문서화, 분석
- 기법: 인터뷰, 설문조사, 브레인스토밍, 워크샵, 프로토타입, 사용 사례 작성(Use Case) 을 통해 수
- 산출물: SRS (Software Requirement Specification) ex) 로그인 기능, 장바구니 기능 요구사항 상세 정리
- 문제점: 요구사항 충돌, 변경, 동의 부족
2. 타당성 조사 (Feasibility Study)
목적: 요구사항의 현실적 구현 가능 여부 평가
- 검토 항목:
- 간결한, 재정적(예산 내 가능 여부)
- 적법(규정 및 법률 준수 가능 여부)
- 기술적(기술적 구현 가능성)
- 운영적(고객 기대 충족 여부)
- 일정적(일정 내 완료 가능성)
3. 설계 (Design)
목적: 요구사항을 실제 구현할 수 있도록 아키텍처, 시스템 구성 설계
- 유형:
- High-Level Design (HLD): 전체 시스템 구조, 모듈화 => 기능과 flow 간단
- 각 모듈의 간략한 설명과 이름 / 모든 모듈에 대한 기능 설명
- 모듈 간 인터페이스 관계 및 종속성
- 식별된 데이터베이스 테이블
- Low-Level Design (LLD): 각 모듈의 디테일한 구현 방법 => 디테일하게!
- 모듈의 기능적 논리
- 데이터베이스 테이블 (유형과 크기가 포함된)
- 인터페이스의 완전한 세부사항
- 모든 모듈의 입출력 구조
- High-Level Design (HLD): 전체 시스템 구조, 모듈화 => 기능과 flow 간단
- 산출물: 설계문서, DFD, Flowchart, Decision Table 등
4. 코딩 (Coding)
- 주요 활동: 코드 작성, 공통 개발 도구(형상관리, 빌드 도구 등) 활용 , 버전 관리, 코드 리뷰 => 다양한 개발자들에게 할당
- 특징: 개발 자원과 시간이 가장 많이 소요되는 단계
5. 테스트 (Testing)
- 단위 테스트(Unit Test): 개별 모듈 검증
- 하나의 모듈기준으로 독립적으로 진행되는 가장 작은 단위의 테스트
- 디버깅 용이, 빠른 실행가능 -> 즉각적인 피드백 및 모듈 오류 확인 가능
- 단일 모듈의 정상기능 작동한다고 해서 결합될때 기능이 보장되는것은 X
- 통합 테스트(Integration Test): 모듈 간 인터페이스 검증
- 모듈 결합하고 작동 테스트
- 하향식, 상향식, 샌드위치 테스트
- 시스템 테스트(System Test): 전체 시스템에 대한 기능/비기능 테스트
- 통합테스트 완료 후 완전 한 시스템에 대해 테스트
- 기능+ 비기능 ( 사용성, 견고성, 신뢰성, 성능테스트) 적 요구사항 도 테스
- 인수 테스트(Acceptance Test): 사용자에 의한 검증 (알파/베타 테스트)
- 알파테스트: 회사 내 사용자, 즉 시스템 잘 아는 사람이 테스트
- 베타테스트: 일부 일반인 사용자에게 배포 후 피드백확인
6. 설치/배포 (Installation/Deployment)
최종 배포: 빅뱅 릴리즈 혹은 CI/CD 활용
- 활동: 설치 테스트, 호환성 테스트, 인프라 구성
- 설치 테스트: 설치 과정이 올바르게 작동하는지 확인
- 호환성 테스트: 플랫폼 및 장비 간 호환성 검증
- 기법: CI/CD를 통한 자동화 배포 -> 사람 개입 최소화 -> 배포속도 , 안정성 향상
7. 유지관리 (Maintenance)
- 주요 활동: 버그 수정 및 기능 업데이트, 로그 모니터링, 확장 및 인프라 관리
- 문서화 및 지식 이전: 지식 이전 및 문제 해결 촉진
- SDLC에서 가장 긴 기간 (기간이 긴것임. 코딩단계는 자원, 시간 소모가 가장 많은것.)
🔷SDLC 모델별 특징 정리
1. Build & Fix 모델 (주먹구구식)
- 특징: 요구사항·설계 없음, 코드부터 작성
- 사용처: 단기 수업 프로젝트, 개인 개발
2. 폭포수 모델 (Waterfall)
- 가장 고전적인 SDLC 모델로, 단계가 명확하게 구분되고 선형 순차적으로 진행됨
- 각 단계가 완료되어야 다음 단계로 진행 가능
계획 → 요구분석 → 설계 → 구현 → 시험 → 운영/유지보수
- 각 단계별 산출물
- 계획: 계획서
- 요구분석: 요구사항 명세서
- 설계: 기본/상세 설계서
- 구현: 소스 코드
- 시험: 테스트 결과
- 운영: 운영 가능 SW
- 장점
- 단순하고 이해 쉬움
- 문서화 철저 → 프로젝트 관리 용이
- 각 단계 명확히 정의됨
- 변경 수용이 어려움, 피드백 경로 부재
- 실사용자와 소통 부족 → 요구사항 미반영 위험
- 프로토타입 없음 → 결과 예측 어려움
- 적합한 경우
- 요구사항이 명확하고 변경이 거의 없는 프로젝트
- 크리티컬 시스템, 단기 고정형 시스템
3. 프로토타이핑 모델 (Prototyping Model)
- 실제 제품이 아닌 **시제품(프로토타입)**을 통해 사용자의 요구사항을 반복적으로 반영
- 사용자와 소통을 강화하여 요구사항 명확화
요구 분석 → 프로토타입 개발/개선 → 사용자 검토/평가 → 구현 → 시험 → 유지보수
↑ ↑ ↓
↑ ↑ ↓
←─────── [개선 필요시 반복] ←────────────
- 장점
- 사용자 요구를 명확히 파악 가능 = 사용자와 의사소통이 용이
- UI/UX 개발에 적합
- 사용자 참여도와 만족도 향상
- 중간 단계 산출물 문서화 어려움 → 관리 소홀 위험
- 폐기 시 자원 낭비
- 사용자 기대치 과도 상승 우려
4. 나선형 모델 (Spiral)
- 특징: 위험 분석 중심의 반복적 개발
- 폭포수와 프로토타입의 장점 + 위험 분석을 결합
- 단계(한 사이클)
계획 → 위험분석 → 개발/테스트 → 고객 평가 (반복)
- 단계별 산출
- 계획: 프로젝트 관리 계획서, 요구사항 분석서
- 위험분석: 위험관리 계획서, 위험 분석서
- 개발 및 검증 : 소스코드, 프로토타입(진화적)
- 고객평가: 고객 피드백
- 장점
- 고위험 프로젝트에 적합
- 반복을 통해 지속 개선 가능
- 고객 요구 반영 용이
- 복잡한 관리
- 반복이 많아질 수록 관리 어려
- 위험 관리 전문가 필요
5. 점증적 모델 (Iterative / Incremental Model)
- 전체 시스템을 작은 단위(증분)로 나누어 반복적으로 개발
- 사용자에게 핵심 기능부터 점차 제공
- 증분형 vs 반복형
- Incremental: 기능 단위 릴리즈 (기능 1 → 기능 2…)
- Iterative: 기존 기능을 반복 개선 (기능1 v1 → v2…)
- 장점: 핵심 기능 다수에게 조기 제공하여 테스트 가능, 사용자 피드백 반영 쉬움 , 전체 프로젝트의 실패 부담감 감소
- 단점: 증분 간 통합 어려움, 증분 수 많을 시 관리 복잡, 적절한 증분으로 나누기 어
6. RAD 모델 (Rapid Application Development)
- 짧은 기간(60~90일) 동안 고객 참여를 바탕으로 CASE Tool를 활용한 신속 개발
- 분석/설계/개발 과정을 도구 기반으로 자동화
- 프로세스 구성
- 분석(JRP): 사용자와 요구사항 정의 , 데이터와 프로세스 모델링 결정(1~2주)
- 설계(JAD): 사용자와 함께 프로토타입 반복 개발/수정/보완하여 시스템 설계 , case tool사 (3~5주)
- 구현: 도구 활용, 빠른 구축
- 이관: 실제 환경으로 전환
- 특징: JRP, JAD 등을 통한 빠른 요구분석 및 프로토타이핑
- 장점
- 짧은 시간 내 개발 가능
- 반복적 사용자 피드백 반영
- 신속한 기능 릴리즈
- 고성능 요구 시스템엔 부적합
- 명확한 책임과 역할 필요
- 적절한 모듈화 가능성을 전제로 함
7. V-모델
- 특징: 폭포수 + 각 단계에 대응하는 검증(Verification), 확인(Validation)
- 검증(Verification) -요시구모
- 개발자 관점
- 각 단계가 명세에 맞게 개발되었는지 확인
- 요구사항 분석, 시스템설계, 구조설계, 모듈설계
- 사용자 관점
- 소프트웨어가 실제 요구에 맞게 구현되었는지 검증
- 단위테스트, 통합테스트, 시스템 테스트, 인수 테스트
요구사항 분석 -인수테스트
시스템 설계- 시스템테스트
구조 설계 -통합테스트
모듈 설계 -단위테스트
- 장점
- 문제 조기 발견
- 테스트 계획을 초기부터 수립
- 명확한 책임 분담
- 변경 수용 어려움
- 복잡한 시스템에는 부적합
- 불필요한 문서생산 가능성
8. 애자일 모델 (Agile)
계획보다는 변화에 유연하게 대응하고, 반복적으로 소프트웨어를 개선해가는 방법론
- 특징: 짧은 반복 주기(1~4주), 변화 수용 중심
- 대표 방법론:
🔸 스크럼 (Scrum) :
-
-
-
- 특징
- 1~4주 단위 스프린트
- 팀 중심의 반복 개발
- PO(Product Owner), SM(Scrum Master), 개발팀 구성
- 제품 요구기능과 우선순위를 제품 백로그로 결정
- PO가 작업 조율하여 스프린트 목표 세움
- 백로그 작성 뒤 작업 할당
- 스프린트 진행: 개발
- 일일 스크럼 회의: 상태 공유
- 스프린트 리뷰 미팅
- 스프린트 회고
- 장점
- 빠르고 유연한 개발
- 빠르게 결함인지 가능
- 스프린트 마다 사용자 의견 수렴
- 단점
- 스크럼 마스터 필요
- 번거로움, 팀원 잘 구성되어야함
- 특징
-
-
🔸 익스트림 프로그래밍 (XP):.
고객의 참여와 개발 과정의 반복을 극대화하여 생산성 향상/ 단순설계, 고객참여로 빠르게 개발하는것이 목적
- 주요 실천사항
- 테스트 주도 개발(TDD): test case를 먼저 만들고 코딩시작
- 짝 프로그래밍(Pair Programming):2인이 공동개발 참여
- 고객을 프로젝트 팀원으로 상주
- 지속적 통합(CI)
- 집단 공동 소유권
- 소규모, 릴리즈 기간 짧게 반복
- 디자인개선 , 리팩토링: 기능 변경없이 시스템 개선 (단순화 , 유연성강화)
- 프로세스
- 사용자스토리 :사용자 요구사랑 기술, 형식없고 단순하게
- 스파이크 : 핵심기능 간단 구현 -> 구현가능한가, 얼마나 오래걸리나 파악
- 릴리즈 계획
- 주기 :1~3주 기간 단위
- 인수 테스트 :test case에 따라 고객이 직접 수행
- 소규모 릴리즈 : 고객의 반응을 기능별로 확인, 고객 요구사항 유연하게 대응
SDLC 주요 모델 비교표
| 모델명 | 특징 | 장점 | 단점 | 적합 대상 |
| Build & Fix 주먹구구식 |
요구분석 없이 즉흥적 개발 | 빠른 구현 | 유지보수 어려움 | 1인 단기과제 |
| Waterfall 폭포수 모델 |
고전적 소프트웨어 생명주기 선형 순차 개발 문서화 중시 |
단계 명확 관리 용이 |
변화 수용이 어려움 이전 단계 중복 불가 오류수정 매커니즘X |
고정된 요구사항일 경우( 수정 거의 X경우) |
| Prototype 프로토타이핑 모델 |
시제품 반복 사용자와 소통 |
사용자 소통 우수 (사용자 요구사항 이해 쉬움) |
중간단계 문서화 어려움 폐기 시 낭비 |
UI 중심 개발 |
| Spiral 나선형 모델 |
반복적 개발 + 위험 분석 계확>위험분석>개발>고객평가 |
리스크 관리에 우수 | 복잡 , 고비용 | 위험도가 큰 대형 프로젝트 |
| Iterative /Incremental 점증적 모델 |
증분 릴리즈 증분형: 기능별 릴리즈 반복형: 릴리즈 시 마다 완성도 증가 |
핵심 기능에 대해 다수의 테스트 가능 실패 부담감 감소 |
증분 너무 많으면 관리 어려움 적절한 증분으로 나누기 애매 통합문제 |
기능별 우선 개발 프로젝트 |
| RAD 모델 | 도구 (vs code 등)활용 기반 신속 개발 고객참여 |
요구사항 완전한 이해 빠른 결과 |
적절한 모듈화 가능성 전제로 함 | 2~3개월 단기 소규모 기술적 위험이 적고 빠른 개발 요구 시 요구사항 변화가 작은것 |
| V-Model | 검증 중심 폭포수 + 검증 |
문제 조기 발견 | 유연성 부족 변화 수용 불가 불확실정 존재 |
안전 중시 산업 (항공 우주 등) |
| Agile 모델 | 문서화 보단 프로그래밍 과정과 테스팅에 초점 기능 추가, 피드백을 모든 단계에서 수행 |
변화 대응 강함 | 팀 역량 중요 | 1~4주 중소규모 변화 많은 프로젝트 |
애자일 모델 유형
| Scrum | Sprint 중심 관리 | 빠른 피드백 | 팀 미성숙시 문제 스크럼 마스터 필요 |
중소 프로젝트 |
| XP | 테스트 주도개발 2인 짝 프로그래밍 |
높은 품질 | 고객 지속 참여 필요 | 소규모 집중형 |
'보안' 카테고리의 다른 글
| 보안 설계 (1) | 2025.04.25 |
|---|---|
| 위협 모델링 (0) | 2025.04.23 |
| 네트워크 보안: 정보 목록화(Footprinting & Scanning) (0) | 2025.04.21 |
| 네트워크 보안: 스니핑(Sniffing) (0) | 2025.04.21 |
| 네트워크 보안 : 스푸핑(Spoofing) (0) | 2025.04.21 |