소프트웨어 개발 생명주기 모델
- 주먹 구구식 모델 -> No Document
- 선형 순차적 모델
- 폭포수 모델
- V 모델 - 진화적 프로세스 모델
- 프로토타입 모델
- 나선형 모델 - 단계적 개발 모델
- 점증적 개발 모델 - 일정 중심 설계 모델
- 애자일 프로세스 모델 -> No Document
-> 주먹 구구식 모델과 애자일 프로세스 모델을 제외한 모델들은 모두 Plan and Document 모델
주먹 구구식 모델
- 계획 단계 없이 바로 구현(코딩)에 들어감 (code and fix)
- 제품을 완성까지 시킨다음에 문제가 생기면 수정하고 문제가 없으면 사용하는 형식
- 매우 간단함 (장점)
- 반려동물 집 짓기와 유사
단점
- 문서화된 산출물이 없음
-> 유지보수 및 관리가 어려움
- 문제 범위를 정하지 않음
-> 전체 프로그램을 알기 어렵고 좋은 아키텍쳐를 만들 수 없음
- 대규모 프로젝트에 적합하지 않음
- 코딩을 먼저하기 때문에 코드 수정 가능성이 높아지고, 이는 코드의 가독성을 떨어뜨리고 수정을 어렵게 함
선형 순차적 모델 (Linear Sequential Model , 폭포수 모델)
- '계획 -> 요구 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수' 순서로 진행
- 물이 떨어지는 흐름(아래에서 위로갈 수 없음)처럼 한 방향으로 진행됨 (하향식)
- 한 단계가 완벽하게 끝났다는 가정하에 다음 단계를 진행함 (전 단계로 돌아갈 수 없음)
- 요구 사항을 변경할 수 없기 때문에 소규모 프로젝트(요구사항이 확정)에 적합함
- 확실하게 해당단계를 마쳐야 하기 때문에 문서화가 중요함
- 전 단계가 끝나야 다음 단계를 진행할 수 있음
- 전 단계의 문서를 참고하여 다음 단계를 진행함
구현
(계획, 요구분석, 설계는 뒤에서 나오기 때문에 생략)
- 'Do it' 단계
- 전체 일정을 줄이기 위해 설계랑 합치기도 함
테스트
- 모듈을 통합하면서 점진적으로 진행 (작은 함수 테스트 -> 전체 코드 테스트 )
-> 어디에 문제가 있는지 알기 위함- 테스트는 따로 테스트 팀이 담당
유지보수
- 가장 긴 단계
- 성능 추가
- 새 기능(요구사항) 추가
- 결함 고침
특징
- 각 단계간의 중복이나 상호작용이 없음 (순서적)
- 단순하거나 응용분야를 잘 아는 경우 유용함 (경험이 있는)
- 각 단계의 결과는 다음 단계를 넘어가기 전에 점검
vs 주먹 구구식 모델
- 주먹 구구식 모델은 단계가 없지만(code and fix) 폭포수 모델은 단계가 있음
- 주먹 구구식 모델은 문서화된 산출물이 없지만 폭포수 모델은 있음
장점
- 절차가 단순하여 이해하기 쉬움 (초보자도 쉽게 적용 가능)
- 단계별 진척상황에 대한 관리가 쉬움
- 각 단계별 산출물이 명확하여, 체계적으로 문서화할 수 있음
단점
- 앞 단계가 완벽하 완료되어야 다음 단계를 시작할 수 있음
-> 앞 단계가 지나치게 강조되면 코딩이나 테스트가 지연될 수 있음
- 사용자가 중간에 가시적인 결과를 볼 수 없음
-> 잘못된 것을 테스트 단계 이후에 알 수도 있음
- 새로운 요구사항을 받아들이기 힘듦
-> 유지보수 때 힘들어질 수 있음
선형 순차적 모델 - V모델
- 테스트 단계를 추가한 폭포수 모델의 변형 (테스트 단계가 여러 stage로 나누어져 있음)
- 각 개발 단계를 검증하는데 초점을 맞춤 (폭포수 모델은 산출물 중심) -> 오류를 줄일 수 있음
장점
- 각 개발 단계의 검증에 초점을 두기 때문에 오류를 줄일 수 있음
- 신뢰성이 높이 요구되는 분야에 사용 가능
단점
- 변경사항을 받아들이기 힘듦
- 구현까지 끝나야 테스트 단계를 시작할 . 수있음
(폭포수 모델의 단점과 같음)
진화적 프로세스 모델
- 폭포수 모델의 단점을 해결하기 위해 등장
-> 단계를 거슬러 올라갈 수 없음 (요구사항의 변화에 대응할 수 없음)
-> 새로운 요구사항에도 민첩하게 대응할 수 있는 방법
- 주로 요구분석 단계를 고려한 모델
- 초기의 사용자 요구사항을 토대로 초기 버전의 프로토타입(더미 소프트웨어) 개발
- 이를 바탕으로 가상의 결과 화면을 관찰
- 변경된 요구사항을 반영하여 지속적인 프로토타입 개선 (프로토타입)
- 추가로 프로토타입에 위험분석단계(우리가 이 요구를 정말 반영해야 하는가?)까지 추가 가능 (나선형 모델)
프로토타입 모델
- 사용자의 요구사항을 충분히 분석할 목적으로 개발된 모델
- 시스템의 일부분을 시험적으로 구현하여 사용자의 피드백을 받고 이를 바탕으로 프로토타입을 개선하는 과정을 반복 (사용자 중심 모델)
- 설계 이후의 과정에서는 반복이 이루어지지 않음
주의할 점
- 프로토타입은 완전한 설계가 중요한 것이 아니라 사용자와 대화할 수 있는 정도의 설계가 필요
- 입출력 화면을 통해 사용자 인터페이스 중심의 설계 진행 (가시적인 것 중요)
- 많은 에너지를 쏟아서는 언됨
- 결과를 통해 사용자가 원하는 것인지 확인
vs 폭포수 모델
- 요구사항 정의 분석
폭포수 모델은 요구 사항을 완전히 명세하고 다음 단계로 넘어감
프로토타입 모델은 요구사항을 반복적으로 수용하여 완성도를 높여서 최종 프로토타입을 개발
- 프로토타입 설계 및 개발
폭포수 모델은 완성된 요구사항을 바탕으로 설계 이후 바로 구현에 들어감 (프로토타입 없음)
프로토타입은 출력 결과가 사용자가 원하는 것인지 보여주기 위해 프로토타입을 구현
- 사용자에 의한 평가
폭포수 모델은 사용자의 평가를 받지 않음
프로토타입 모델은 요구분석 단계에서 반복된 프로토타입으로 사용자에게 평가를 받음
- 공통점 : 요구사항이 끝난 뒤에는 돌아올 수 없음
장점
- 사용자의 새로운 요구 사항을 받을 수 있음 (사용자 중심)
- 프로토타입을 의사소통 도구로 이용 가능
- 프로토타입으로 완성품을 미리 예측해볼 수 있음 (ex 모델하우스)
- 유지보수때 필요한 노력과 시간을 줄일 수 있음
단점
- 반복되는 개발 과정으로 인해 투입 인력과 비용 산정이 어려움
- 개발자 입장
프로토타이핑 과정을 관리/통제하기 어려움
개발 범위가 명확하지 않아 언제 끝날지 알 수 없음 (개발자가 지침)
- 사용자 입장
기대 심리 유발
진화적 프로세스 모델 - 나선형 모델
- 시스템 개발시 위험을 최소화하기 위해서 점진적으로 완벽한 시스템으로 개발해 나가는 모델
- 진행순서 : 요구분석 -> 위험분석 -> 개발 -> 평가
- 위험 부담이 큰 시스템 개발에 적함
요구분석
- 사용자와 미팅
- 요구 사항을 분석하고 타당성을 검토
- 각 단계에 대한 목적 수립
목적 : 해당 cycle에서 완료되는 목표, cycle마다 새로운 목적으로 변경됨
위험분석
- 사용자와 같이 하는 것 X
- 요구 사항을 바탕으로 예측되는 위험 사항에 대한 분석
위험 사항
-> 개발자의 이직
-> 요구사항의 변경
-> 개발비의 초과
-> 개발 기간의 부족
개발
- 구축하려고하는 시스템과 개발 환경에 맞는 개발 모델 선택
평가
- 고객이 평가후 추가 반복에 대한 여부 결정
- 고객의 추가 및 수정 요청사항 반영
장점
- 사용자 요구를 최대한 반영
- 이번 cycle에 반영 못한 요구를 다음 cycle에 반영 가능
- 위험 분석 단계가 있기 때문에 개발 후반에 갑작스럽게 발생하는 문제 때문에 프로젝트가 중단될 가능성 적음
- 대규모 시스템 개발에 적합 (Risk reduction 메커니즘)
- 반복적인 개발 및 테스트 (강인성 향상)
단점
- 요구분석, 위험분석, 개발, 평가가 반복적으로 일어나기 때문에 개발 기간이 길어질 수 있음
- 반복횟수가 많아질 수 있기 때문에 프로젝트 관리가 힘듦
- 위험 분석이 중요하기 때문에 위험 분석 전문가(ex 경험이 많은 사람)가 필요
단계적 개발 모델
- 개발자가 먼저 릴리즈 1(완전히 만들어진 것 아님)을 개발하여 사용자가 사용
- 사용자가 릴리즈 1을 사용하는 동안 릴리즈 2를 개발 (업데이트)
- 개발과 사용을 병행하는 과정을 반복
- 빠른 출시를 해야할 때 좋음 (개발 사이클이 짧은 환경)
- 비교적 개발자 친화적인 방법
단계적 개발 모델 - 점증적 개발 모델 (Incremental)
- 중요하다고 생각하는 기능부터 개발하고 점점 기능을 추가해나가는 방식
- 요구분석명세서에 기록되어있는 전체 서비스의 기능을 서브 시스템으로 분할
- 서브 시스템을 단계적으로 하나씩 릴리즈
장점
- 기능이 부족해도 일단 출시할 수 있음 (내부적 부족, 사용자는 모름)
- 사용자의 요구를 받아들이기 쉬움
- 한꺼번에 많은 비용을 들이지 않아도 됨
- 전체 시스템을 한 번에 주었을 때 조직이 받는 충격을 완화할 수 있음
- 이미 사용하고 있는 서브 시스템이 있기때문에 어떤 유형으로 개발하면 되는지 잘 알 수 있음
단점
- 처음 설계할 때부터 이후에 개발할 다른 서브 시스템과의 연관성을 고려해야 함
- 이미 개발한 서브 시스템과 새로운 서브 시스템 통합 시 어려움을 느낄 수 있음
일정 중심 설계 모델
- 사용자의 요구사항을 바탕으로 우선순위를 정하고 이를 따라서 사이클을 계획 (설계, 구현, 테스트)
- 초기 단계 : 중요한 기능을 설계, 구현하여 골격을 만듦
- 상대적으로 덜 중요한 기능을 나중에 구현 -> 일정 조정 가능
- 빠르게 출시하기 위한 모델
장점
- 소프트웨어 제품 출시 날짜가 매우 중요할 때 유용
- 목표 일정을 달성할 수 있을지 불확실할 때 유용 (우선순위에 따라 진행)
단점
- 우선순위를 정하는데 시간을 낭비할 위험 있음
- 우선순위를 낮게 설정했는데 실제로는 중요할 위험 있음
- 출시를 하고 우선 순위가 낮은 기능을 미개발할 수 있음
애자일 프로세스 모델
- 애자일(Agile) : 민첩한, 날렵한
- 진화적 프로세스 모델의 장점을 살리며 요구사항의 변화를 주기적으로 수용하여 반복적으로 개발하는 모델
- 고객의 요구사항에 민첩하게 대응하고, 그때그때 주어지는 문제를 풀어나가는 방법론
목표
- 프로세스 중심이 아닌 개개인의 소통을 중요시함
- 문서화가 중심이 아닌, 실행 가능한 소프트웨어를 중시 ( != 프로토타입 )
- 계약의 관계가 아닌, 고객과의 협력을 중시 (사용자를 많이 만남)
- 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시
vs 폭포수 모델
- 폭포수 모델은 실행 가능한 소프트웨어를 한 번 만들면 개발이 끝나지만 애자일 프로세스 모델은 실행 가능한 소프트웨어를 계속해서 만들고 업데이트함
- 폭포수 모델은 문서화를 중요시하지만 애자일 프로세스 모델은 고객과의 협력, 빠른 시간안에 실행가능한 소프트웨어, 환경과 고객의 변화에 능동적으로 대처하는 것을 중요시함
vs 프로토타입 모델
- 프로토타입 모델의 프로토타입은 실행할 수 없는 더미 소프트웨어이지만 애자일 프로세스 모델의 제품은 실행가능한 소프트웨어임
- 프로토타입은 요구분석 단계가 지나면 요구사항에 대한 변화를 받아들일 수 없지만 애자일 프로세스 모델은 스프린트 단위로 요구 사항의 변화를 수용하면서 개발
vs 나선형 모델
- 나선형 모델은 위험 식별 및 완와에 목적을 두고 있고 애자일 프로세스 모델은 소통을 중요시 하는 모델
- 나선형 모델은 불확실성이 높은 복잡한 프로젝트에 적합하고, 애자일 프로세스 모델은 유연성과 응답성이 중요시되는 작고 간단한 프로젝트에 적합
( 애자일 프로세스 모델에는 위험 분석을 할 시간이 없음 )
스크럼
- 애자일 프로세스 모델 중 가장 대표적
- 팀(Team)이라는 의미
- 하나의 팀이 하나의 사람처럼 움직이고 따라줘야 성공할 수 있는 프로세스
- 너무 큰 모델에는 적합하지 않음 (사람이 너무 많으면 하나의 사람처럼 움직이기 어려움)
- 스크럼 방식
1. 제품 기능 목록 작성
2. 스프린트 계획 회의
3. 스프린트 수행 (1주 ~ 4주)
4. 스프린트 개발완료: 최종 제품 (실행 가능한)
5. 스프린트 검토 회의 및 회고
장점
- 반복 주기 마다 제품이 생성되기 때문에 사용자와 많이 소통할 수 있음
- 프로젝트 계획에 걸리는 시간을 최소화 할 수 있음 (가까운 미래만 예측해도 됨)
- 점진적으로 테스트할 수 있음 -> 버그를 쉽게 발견할 수 있음
- 계획, 기능의 수정과 변경에 빠르게 대처할 수 있음
- 프로젝트의 진행 현황을 볼 수 있어, 목표에 맞게 변화를 시도할 수 있음
단점
- 스프린트마다 제품이 만들어져야함
- 불완전하고 예측불가능한 요소들이 있음 (반복되기 때문에)
- 빈번한 수정으로 인해 개발인력들의 피로도가 높음
- 잦은 소통과 미팅이 있기 때문에 대규모 프로젝트에 적합하지 않음
'소프트웨어공학' 카테고리의 다른 글
| 설계 (Part1) (0) | 2024.10.21 |
|---|---|
| 요구분석 (Part2) (0) | 2024.10.21 |
| 계획(프로젝트 계획과 관리) (part 2) (0) | 2024.10.20 |
| 계획 (프로젝트 관리와 계획) Part 1 (1) | 2024.10.20 |
| 소프트웨어 공학과 개발 프로세스 (Part 1) (1) | 2024.10.19 |