소프트웨어 개발 생명주기
IT위키
소프트웨어 개발 생명주기(SDLC)는 소프트웨어의 생성에서 소멸까지의 과정을 단계별로 나눈 것 으로, 각 단계별 주요활동과 산출물을 통해 프로젝트의 진행방향을 명확하게 파악하고, 관리를 용이하게 한다.
일반적 생명주기[편집 | 원본 편집]
정의 단계[편집 | 원본 편집]
- 타당성 검토 단계: 개발할 소프트웨어가 법적, 경제적, 기술적으로 구축이 가능하고, 구축할 가치가 있는지 검토
- 개발 계획 단계: 개발에 필요한 자원을 산출하고 장소, 인력, 기간 등 대략적인 계획을 잡는다.
- 요구사항 분석 단계; RFP수준에서 제안된 요건보다 더 세부적인 요구사항을 도출한다.
개발 단계[편집 | 원본 편집]
- 설계 단계: 소프트웨어 아키텍처, 프레임워크, 인프라를 구성한다. 에러가 가장 많이 발생한다.
- 구현 단계: 설계된 내용을 기반으로 세부 기능을 코딩한다.
- 테스트 단계: 개발된 기능이 에러 없이 정상적으로 동작하는지 테스트한다.
유지보수 단계[편집 | 원본 편집]
- 소프트웨어를 직접 운용하며 잔존 버그 등을 찾고 추가 개선사항을 도출한다.
- 하드웨어, 환경 변화에 따라 소프트웨어를 적응 및 유지시킨다.
- 시간과 비용이 가장 많이 투입된다.
종류[편집 | 원본 편집]
개발수정 모델(Build-Fix Model)[편집 | 원본 편집]
주먹구구식 개발 모델 이라고도 부름- 요구사항, 분석·설계 단계 없이 일단 개발에 들어간 후 만족할 때까지 수정작업을 수행하는 방식
폭포수 모델(Waterfall Model)[편집 | 원본 편집]
- 소프트웨어 개발의 전 과정을 나누어 체계적이고 순차적으로 접근하는 방식
- 각 단계의 결과가 확인되어야지만 다음 단계로 넘어간다.
- Boehm이 제시한 고전적 생명주기 모델로 선형 순차적 모델이라고도 함
- 가장 오래된 모델로 많은 적용 사례가 있지만 요구사항의 변경이 어렵다.
- 순서: 타당성 검토, 계획, 요구사항 분석, 설계, 구현, 테스트, 유지보수
프로토타입 모델(Prototyping Model)[편집 | 원본 편집]
- 점진적으로 시스템을 개발해 나가는 접근 방식
- 프로토타입을 만들어 고객과 사용자가 함께 평가한 후 개발될 소프트웨어의 요구사항을 정제하여 보다 완전한 요구명세서를 완성하는 방식
- 장점
- 개발과정에서 사용자의 요구를 충분히 반영한다.
- 최종결과물이 만들어지기 전에 의뢰자가 최종결과물의 일부 혹은 모형을 볼 수 있다.
- 의뢰자나 개발자 모두에게 공동의 참조 모델을 제공한다.
나선형 모델(Spiral Model)[편집 | 원본 편집]
- 폭포수 모형과 원형모형의 장점을 수용하고 위험분석을 추가한 점증적 개발모델
- 프로젝트 수행시 발생하는 위험을 관리하고 최소화하기 위한 방식
- 대규모 시스템 개발에 적합
- 계획 수립 - 위험 분석 - 개발 및 검증 - 고객평가 순으로 반복
출처[편집 | 원본 편집]
- KISA, 전자정부 SW 개발·운영자를 위한 소프트웨어 개발보안 가이드
[프로세스]
: 주어진 목적을 위해 수행되는 일련의 절차
: 절차 + 인력 + 기술 / 각 순서와 활동이 명확히 정의됨
[소프트웨어 개발 프로세스]
: 소프트웨어 개발에 필요한 절차뿐만 아니라, 그와 관련된 인력, 방법, 도구들이 통합되는 수단
: 소프트웨어와 이에 관련된 산출물을 개발, 유지하기 위해 사용하는 활동, 방법, 절차의 잡합
- 기존체제는 요구사항 복잡, 규모증가 => 실패
[소프트웨어 개발 생명주기(SDLC)]
: 소프트웨어를 어떻게 개발할 것인지에 대한 추상적 표현
- 순차적, 병렬적 단계로 구성
# SDLC 특징
1. 각 단계에 관련된 활동들이 정의되어 있다
2. 다음단계에 활용될 수 있는 산출물이 작성됨
3. 전체 비용 산정, 개발 계획 수립 기본골격 제시
4. 의사소통의 기준과 용어의 표준화
5. 문서화를 통한 충실한 프로젝트 관리
[소프트웨어 개발 생명주기 모델의 종류]
1. 주먹구구식 개발 모델(Build-Fix Model)
: 요구사항 분석, 설계 단계 없이, 일단 개발 들어간 후 만족할때까지 수정작업 수행
- 크기매우 작은 규모의 개발서 사용
- 정해진 개발 순서가 X => 진행상황파악, 유지보수등의 어려움
2. 폭포수 모델(Waterfall Model)
: 순차적으로 소프트웨어를 개발하는 전형적인 개발 모델
- 기본적 모델
- 한 과정이 완벽히 끝나야 다음 단계로 넘어감(이전단계로 돌아가지 않음)
<단계별활동>
- 요구사항 분석 : 요구사항 수집, 분석, 문서화 # 산출물 : 요구사항 명세서
- 설계 : 모든시스템의 구조 결정 # 산출물 : 설계 명세서
- 구현 : 설계 명세서를 실제 모습으로 변환 # 산출물 : 소스 코드 및 프로그램
- 테스트
- 유지보수
<장점>
- 각 단계별로 정형화된 접근 방법 가능
- 체계적인 문서화로 명확히 프로젝트를 진행
<단점>
- 앞 단계 완료될때까지 다음단계들은 대기 상태
- 실제 작동 되는 시스템을 후반부에나 확인 가능해서 고객의 요구사항 확인에 많은시간 걸림
3. 원형 모델(Prototyping Model)
: 점진적으로 시스템을 개발해 나가는 접근 방법
- 폭포수 모델의 단점을 보완
- 고객 요구사항을 초기에 완전히 파악하기 어려울떄 사용
- 원형(prototype)을 만들어 고객과 사용자가 함께 평가후 개발될 소프트웨어의 요구사항을 정제해 보다 완전한 요구사항 명세서를 완성
= (목적)원형을 가능한 빨리 개발해 고객과 검증
<단계별활동>
- 요구사항 정의 : 제품의 윤곽을 잡음
- 원형 설계 : 빠른 설계, 사용자 인터베이스에 초점
- 원형개발 : 설계된 원형을 RAD도구들을 사용해 빠르게 구현
- 고객 평가
- 원형 정제 : 어떻게 수정할지 결정, 순환반복
4. 나선형 모델(Spiral Model) #교재한번 읽기 - 위험분석에 관하여
: 폭포수 모형과 원형 모형의 장점을 수용, 위험 분석을 추가한 점증적 개발 모델
- 프로젝트 수행시 발생하는 위험을 관리하고 최소화 하려는 것이 목적
- 한 사이클에선 폭포수 모델로 진행
: 초기 요구사항을 기반으로 계획,위험분석,개발을 하고 고객의 피드백을 받아 다시 계획세워서 돌리고 반복.
<단계별활동>
- 계획 및 정의 단계 : 요구사항 수집, 프로젝트 위험의 원인을 규명 가능
- 위험 분석 단계 : 초기 요구 사항 토대로 위험 규명
- 개발 단계 : 생명주기 모델 선택, 제품 만드는 단계
- 고객 평가 단계 : 고객의 피드백
<장점>
- 사전에 위험 감소 가능
- 테스트 비용, 제품 개발 지연등의 문제 해결 가능
<단점>
- 개발자가 정확하지 않은 위험 분석을 했을경우 심각한 문제 발생 가능
- 복잡, 프로젝트 관리 어려움(완성도 파악 어려움)
[소프트웨어 개발 방법론]
: 소프트웨어 개발 생명주기 내의 각 단계에서의 수행 방법과 활동들을 구체적으로 정의
[소프트웨어 개발 방법론의 종류]
1. UP(Unified Process)
: 객체지향 소프트웨어 개발 방법론(요즘은 잘 안씀)
<특징>
- 반복적(Iterative)이고, 점진적(Incremental)인 개발 방법
: 사이클 반복되며 점진적 발전
: 반복되는 과정 통해 실행가능한 Release가 산출(ex. 1.3.1 -> 1.3.3)
- 유스케이스(Usecase) 기반(4장에 자세히)
- 아키텍쳐 중심의 개발을 지향 : 시스템 전체를 표현한 아키텍쳐는 프로젝트 참여자들에게 최종 산출물의 모습을 초기에 인지하게 하고, 공통된 시각을 가지게 함.
- 위험 관리를 중시 : 위험도 높은것일수록 프로젝트 초기에 처리 방안을 찾아 해결
# UP의 핵심 워크플로우와 페이즈
- 도입(Inception) <가중치> 요구사항1, 분석0.5, 설계0.5, 구현0.25, 평가0.25
: 전체 요구사항 이해 중점
: 프로젝트 목표와 실현 가능성, 대략적 비용평가 통해 프로젝트 개발 여부 결정 단계
- 상세(Elaboration) <가중치> 요구사항1, 분석1, 설계1, 구현0.25, 평가0.25
: 요구사항 분석 및 아키텍처를 확정, 위험 요소를 해결하는데 중점
: 아키텍처를 실행 가능한 수준으로 확장, 구축 단계에 대한 계획을 수립
: 비중을 낮으나, 시스템의 중요 기능에 대한 구현 및 평가는 이루어짐
- 구축(Construction) <가중치> 요구사항0.25, 분석0.25, 설계0.5, 구현1, 평가1
: 사용자의 환경에서 실행 가능한 시스템을 구축하고 평가하는데 중점
- 이행(Transition) <가중치> 요구사항0.25, 분석0.25, 설계0.5, 구현0.5, 평가0.5
: 릴리즈 완성 단계, 시스템개발완료, 품질 보장햇 사용자에게 인도하는데 중점
<UP의 이점>
- 위험 요소 초기 완화
- 진척 사항 가시화
- 발주자의 실제 요구사항에 근접한 시스템 만들수 있다(여러번의 평가를 통해..)
- 다음반복의 피드백으로 교훈이 작용해 반복이 거듭될수로 개발
2. XP(eXtreme Programming) = Agile
: 개발 외 개발방법론이 더 많은 시간 잡아 먹는 불만 발생
=> 문서화에 집중하기 보단 소프트웨어 개발에 집중, 개인간 상호작용에 집중, 고객의 협력에 집중
- 하나의 릴리즈 시작 시에는 해당 릴리즈에서 개발될 스토리가 결정, 해당 릴리즈가 몇번의 반복(계획,구현,통합,테스트)을 거칠지 결정
: 여러번의 반복통해 릴리즈나옴
<특징>
- 요구사항이 변경된다는 사실을 가정. (여러번의 릴리즈,반복을 통해) 고객의 피드백을 수용하기 위해 고객과 개발팀이 함께 상주
- 동료와의 의사소통을 중요시함 : 각자 업무분담 X, 모든 직원이 모든 접근 권한 가짐
- 단순하고 명확한 설계 유지 : 코드먼저, 설계나중 = 큰 그림 그려놓고 내부는 나중에!
- 가장 우선순위가 높은것 먼저 개발
- 초기에 고객에게 시스템을 전달해 피드백 받음
- 변경부분 있으면 절차/담당자 거칠 필요없이 내가 그냥 하면 됨
<용어>
- 스토리(Story) : 고객이 직접 작성하는 (추상적) 요구사항. ex)가입 버튼을 눌렀을때 가입창이 뜨고 그 창에는 이름, 나이를 입력하는 기능이...
- 스토리 추정 : 개발자가 고객이 제시한 스토리가 어느 정도의 난이도, 기간인지 추정하는것
- 릴리즈(Release) : 고객에게 구현된 제품을 배포하는것 ex) ver1.3.1
- 반복(Iteration) : 하나의 릴리즈 위해 반복되는 작업(반복하다가 고객이 ok하면 릴리즈 하는것)
- 드라이버(Drive) : Pair Programming에서 키보드를 치며 코드를 작성하는 사람
- 파트너(Partner) : Pair Programming에서 드라이버를 도와 코드의 구조 및 결함에 대한 조언을 하는사람
* Pair Programming : n명에게 키보드 한개 줘서 프로그래밍(한명이 구현할때, 다른 한명은 지켜봄. 번갈아가며 수행)
<역할>
- 개발자 : 스토리 추정, 설계, 구현, 테스트
- 관리자 : 개발자 앞에 높인 개발 이외의 장애물 제거 ex)컴퓨터 업그레이드등
: 개발 활동 직접관여 X (개발자에게 어느 부분 개발하라 하지 않음. 개발자가 스스로 가져감)
- 고객 : 스토리제출, 테스트 실시, 개발팀과 상주(개발자가 구현하면서 계속 물어봄 = 실시간 피드백)
# 가볍지만 충분한 개발(= XP)위해 지켜야할 가치 및 실천사항
<가치>
- 단순성 : 설계의 단순함 실형(코딩스타일 통일, 주석처리)
- 의사소통 : 수평적, 고객과 실시간
- 피드백 : 실시간
- 용기 : 위 세가지 자치 꾸준히 이행되게끔 가져야 할 가치
- 존중 : 프로젝트 참여 모든 사람 인정 존중
<실천사항>
- 계획 게임 : 매 릴리즈와 반복 시작시 구현해야 하는 스토리를 고객과 개발팀이 함꼐 결정
- 짧은 릴리즈 : 짧은 배포주기(고객의 피드백 통해 프로젝트가 의도된 방향에서 벗어나느거 방지)
- 메타포(MetaPhor) : 전체 시스템 대상으로 사용가능한 상징적인 내용을 찾아 개발팀의 쉬운 이해, 단순 설계 가능케 함.
ex)쇼핑몰 : 슈퍼에서 진열된 상품들 장바구니 넣어 계산대에서 결제
- 단순 설계 : 현재 구현중인 스토리에 필요한 부분만 설계
- 테스트 우선 개발
- 리팩토링 : 이미 구현된 코드도 개발기간중 언제든 코드 수정가능
- 짝 프로그래밍
- 코드 공동 소유
- 지속적인 통합 : 개발자가 구현한 단위시스템을 지속적으로 전체 시스템에 통합하는것.
- 주당 40시간 작업 : 워라벨
- 고객의 참여
- 코딩 표준 : 공동 개발이기에 규칙
- 전체 팀 : 대부분의 사람들이 같은 공간에서 함꼐 개발하도록 하는것(수평적)
3. 마르미 : UP와 특징 유사, 경량화한 한국산 RUP, 이젠 사용 안함.
[Summary]
1. 프로세스 : 목적수행위한 일련의 절차 / 인력+절차+기술
2. 소프트웨어 프로세스 : 절차, 인력, 방법, 도구 통합 기술 / 산출물
3. 소프트웨어 생명주기란 : 소프트웨어 개발 방법의 추상적 표현 / 순차적, 병렬적
4. 소프트웨어 생명주기 모델의 종류 : 주먹구구 / 폭포수 / 원형 / 나선형
5. 소프트웨어 개발방법론 : 소프트웨어 생명주기 내 각 단계에서의 수행방법과 활동들 구체적으로 정의
6. 소프트웨어 개발방법론의 종류 : UP / XE / 마르미