소프트웨어 개발 생명주기 프로세스 모델(Software Development Lifecycle; SDLC)
라엘이가 요즘 소프트웨어 공학에 대해서 공부하고 있습니다.
양질의 소프트웨어를 개발하기 위해서 고려해야 할 사항등을 배우고 있습니다.
관련된 책 두권 읽고 (물론 해당 부분만 읽었음) 요약한 글입니다.
소프트웨어 공학과 함께 나오는 말 중에 “소프트웨어 위기” 라는 말이 있습니다. (대부분의 소프트웨어 공학 교재는 소프트웨어 위기 부터 알려줍니다.)
과거에는 고가의 하드웨어를 사용하고 단순한 소프트웨어를 사용했기 때문에 개발과 관련하여 그리 많은 노력이 필요하지 않았는데
하드웨어 가격하락과 요구사항이 복잡해지고 프로젝트가 대규모화 되면서 이를 개발&관리할 수 있는 “소프트웨어 공학”이 대두되었습니다.
Wiki Link : https://en.wikipedia.org/wiki/Software_crisis
< Software Crisis 를 설명하고 있는 그림. 출처 : IEEE 그룹 >
어떤 한 작업의 비용에서 HARDWARE 의 비중이 급격히 줄어들고 SOFTWARE 의 비중이 늘어나는 것을 볼 수 있을 것이다.
거대화되고 복잡화 되는 SOFTWARE 의 (개발부터의) 관리가 필요해 진 것이다.
이와 관련하여 요구사항 분석 부터 시작해서 설계, 구현, 유지보수 등 아주 방대한 정보를 다루고 있습니다.
Software Development Lifecycle Process 는 한마디로 소프트웨어의 생성부터 소멸까지 관리하는 프로세스입니다.
다음의 Lifecycle 이 있으며 장단점을 적습니다.
어느 것이 최적이라는 정답이 없으며 프로젝트의 상황에 따라서 적절한 모델을 선택하는 것이 중요합니다.
요약한 내용이므로 자세한 정보를 원하시면 wikipedia 에서 직접 검색하세요.
1) 주먹구구식 개발 모델(Build and Fix Model)
요구사항 분석, 설계등의 단계 없이 일단 개발에 들어간 후 만족할 때까지 수정작업을 진행
장점) 개발 시작이 빠름.
단점) 계획이 정확하지 않음.
관리자는 프로젝트 진행상황 파악에 어려움.
개발 문서가 없기 때문에 개발 및 유지보수에 어려움.
개인 아이디어 프로젝트 진행시 적용하면 좋다.
명확한 요구사항이 있거나 장기간 프로젝트에 적용하기에 부적합.
2) 폭포수 모델(Waterfall Model)
순차적으로 소프트웨어를 개발하는 전형적인 모델.
대부분의 개발프로젝트에서 가장 많이 사용되고 있는 모델.
각 단계는 [요구사항분석]-[설계]-[구현]-[테스팅]-[유지보수]로 나뉘며 각 단계가 지날때마다 산출물이 나온다.
장점) 각 단계별로 정형화된 접근 방법 가능.
체계적인 문서화가 가능하여 프로젝트 진행을 명확하게 할 수 있음.
단점) 앞 단계가 완료될 때까지 다음 단계들은 대기 상태여야 함.
실제 작동되는 시스템을 개발 후반부에 확인 가능하기 때문에 고객이 요구사항 적용을 확인하는데 많은 시간이 걸림.
3) 원형 모델(Prototyping Model)
폭포수 모델의 단점을 보완한 모델
점진적으로 시스템을 개발해 나가는 방법.
고객의 요구사항을 정확히 파악하기 어려울때 사용하는 방법이며, 쉽게말해 샘플을 먼저 개발한 후 고객의 피드백을 받고
샘플(Prototype=원형)을 폐기하고 다시 개발.
장점) 원형을 바탕으로 빠른 개발과 고객의 피드백을 받을 수 있음.
단점) 대규모의 프로젝트에는 부적합
4) 나선형 모델(Spiral Model)
폭포수 모형과 원형 모형의 장점을 수용하고 위험분석을 추가한 점층적 개발 모델
프로젝트 수행시 발생하는 위험을 관리하고 최소화 하려는 것이 목적.
중간중간 마다 위험분석을 하며 문제가 있을 경우 프로젝트를 중단하는 것이 목적(위험관리라고 부른다).
주로 고 비용의 시스템 개발이나 많은 시간이 걸리는 큰 시스템 구축시 선택되는 모델.
장점) 프로젝트 위험요인을 최소화 할 수 있음.
단점) 단계가 명확히 구분되어 있지 않다.
개발자가 정확하지 않은 분석을 했을 경우 심각한 문제가 발생한다.
다른모델에 비해 프로젝트 관리가 복잡하다.
5) RAD 모델(Rapid Application Development)
점진적인 소프트웨어 개발 방식.
컴포넌트를 사용하여 매우 빠르게 폭포수 모델을 적용시키는 방법
장점) 짧은 기간에 기능이 완벽한 소프트웨어 시스템을 개발할 수 있다.
단점) 소프트웨어의 주요 기능이 모듈화 되지 않으면 적용할 수 없다.
6) 반복적 개발 모델(Iterative Development Model)
고객의 필수 요구사항을 만족시키는 제품 일부를 먼저 개발
고객에게는 분석과 훈련의 수단을 제공하고 개발자에게는 학습경험을 제공
장점) 중간단계 제품을 바탕으로 새로운 요구사항을 추가하는 개발로 요구사항 수용이 빠름.
단점) 고객의 요구로 변화가 자주 발생하여 구조화가 힘들어질 수 있다.
7) V모델 (V Model)
- 폭포수 모형에 시스템 검증과 테스트, 작업을 강조한 모델
- 모듈의 상세설계를 단위테스트 과정에 검증하고 시스템 설계는 통합테스트 단계에 사용자의 요구는 시스템 테스트 과정에서 검증하는 방법
장점) 개발 후 발생하는 오류를 줄일 수 있음
단점) 반복이 없어 변경을 다루기가 쉽지 않음
8) 컴포넌트 기반 모델 (Component Based Development)
이미 만들어진 컴포넌트를 기반으로 소프트웨어를 개발하는 방법
장점) 개발주기와 개발비용을 대폭 단축하는 생산성향상 효과가 있다.
단점) 이미 만들어진 컴포넌트가 없다면 적용시킬 수 없다.
라엘이가 최근 개발을 계획중인 소프트웨어는 6) 반복적 개발 모델을 사용할 것입니다.
산출물 만들면서 관련 이론들을 포스팅 하도록 할께요.
위는 개발 생명주기 이고 아래는 개발 방법론 이다.
1) UP (Unified Process)
이해하기 조금 어려웠다.
도입, 상세, 구축, 이행의 프로젝트 단계로 나누고 해당단계를 여러번 반복하면서 실행한다.
요구사항분석, 설계, 구현, 시험(테스팅)을 각단계마다 구동하는데 집중하는 비중이 다르다.
도입은 분석위주, 상세는 설계위주, 구축은 구현위주, 이행은 최종릴리즈 위주로 시간이 배분된다.
주소 UML이 후에 동작되는 Rational UP(RUP) 와 빠른 개발을 할 수 있는 Agile UP(AUP) 가 주로 쓰인다.
http://www.youtube.com/watch?v=X19IVn4qkC8
장점 : UML 근간, 요구사항 수렴용이, 변경 대응용이, 위험식별 용이
단점 : 무겁고, 세부적, 반복중심. 범용적에 적합한 모델이라 특정업부에 대해서는 적용이 어렵다.
2) XP (eXtreme Process)
애자일 프로세스 (Agile Process) 방법론 중에 하나이다.
Agile Process란 기존의 개발방법론이
문제해결보다 그 외의 작업에 많은 시간과 노력을 요구하기 때문에 비 효율적이라고 생각하였다.
“가볍지만 충분한” 이라는 원칙을 가지고 있으며 고객과 개발자 간의 의사소통을 중요시한다.
관리자 : 개발자 앞에 놓인 개발이외의 장애물 제거. 개발에 직접 관여안함. 일을 지시하고 결과물 문서화
개발자 : 개발 난이도를 추정하고 개발실시
고객 : 스토리(요구사항을 이야기로 적어놓은것)를 준비하고 작업순서를 결정.
예시) 고객이 쇼핑몰을 만들기를 원하며 관리자의 상품등록, 고객의 물건구입진행, 고객의 후기남기기 등으로 스토리를 준비했다고 하자.
고객은 각 스토리의 순서를 먼저 정한다. 상품등록을 우선순위로 두었다고 가정하고
개발자는 상품등록의 난이도를 평가하고 작업단계를 나눈다. (상품등록, 상품삭제, 상품조회, 상품수정 등)
각 단계는 개발자가 알아서 구현한다. 고객은 개발자와 항상 붙어 있으며 개발자와 소통한다.
일정기간이 지나고 상품등록(등록,삭제,조회,수정등 기능이 되는) 1차버전(1st release)가 완성된다.
그 후 다음 스토리를 진행한다.