[소프트웨어 공학] 개발 프로세스 모델

이전 포스팅

[소프트웨어 공학] 프로세스

 

이번 포스팅에서 다루는 내용

프로세스 모델, 폭포수 모델, 프로토타이핑 모델, 나선형 모델, Unified 프로세스, 애자일 프로세스

 

 

0️⃣ 프로세스 모델

---

개발 프로세스를 단순화 하여 표현한 것이다. 

모델은 각기 다른 관점에서 프로세스를 표현했다. 

 

개발을 할 때, 조직에 맞게 모델을 참조해서 구체적인 프로세스를 정의하는 것이다.

각 모델별 특징을 이해하고, 적합한 모델을 참고하면 되겠다. 

 

여러가지 프로세스 모델에 대해서 살펴보자.

 

1️⃣ 폭포수 모델

한단계 한단계씩

---

- 가장 오래된 모델. 원래 하드웨어 모델에서 사용하던 것이다. 

- 한 단계가 끝나야 다음 단계로 넘어갈 수 있다.

-> sequential. 각 단계 사이의 중복, 상호작용 ❌ 

 

하나의 단계가 끝난다는 것을 명확히 정의하기 위해서 

-> 각 단계의 결과물을 명확히 정의해야 한다. 그리고 점검 과정도 거쳐야 한다.

 

장점

• 각 단계가 분리되어 있기 때문에,

-> 각 작업을 담당하는 전문팀을 구성할 수 있다. 동시에 파이프라인 형태로 작업이 가능해진다.

• 단순하다 

• 중간 산출물이 명확 -> 관리 easy 

 

단점

• 결과물 정의가 중요한만큼

-> 각 단계마다 많은 결과물을 산출해내야 한다. 

• 이전 단계 작업을 취소 또는 변경 불가능 

• 테스트 작업이 늦게 이루어짐 

-> 결함을 늦게 발견할 수 있다. 

 

추천

크고 복잡한 오래 지속되는 프로젝트에 적합. 

하드웨어와 연관된 개발에 적합.

지식과 경험이 있는 개발자, 요구 사항이 명확한 개발에 적합 

 

 

2️⃣ 프로토타이핑 모델

요구 사항을 명확하게 

---

- 고객의 요구사항을 명확하게 하기 위해 시스템을 간단하고 빠르게 만들어서 피드백을 받는다. 

- 시스템이 어떻게 작동하는지 시뮬레이션

- 사용자와 개발자 사이의 의사소통을 쉽게 함 

 

프로토타입은 단순히 요구를 명확하게 하기 위한 수단이기 때문에, 만들고 버려짐. 

프로토타입을 만들어보먀 제작 가능성을 타진

 

프로토타입을 어느정도의 수준으로 만들어야 하는지에 대한 정의는 불명확함 

 

장점

• 사용자의 의견 반영이 잘 됨 

• 사용자의 참여도 올라감, 개발자는 요구를 명확히 도출 

 

단점

 

• 사용자가 완성품 수준으로 요구할 수 

• 중간 산출물 정의가 명확하지 않음 -> 관리 어려움

 

추천

• 개발 착수 시점에 요구 사항이 불명확할 때

• 실험적으로 실현 가능성을 타진해 보고 싶을 때

• 혁신적인 기술 사용을 원할 때 

 

3️⃣ 나선형 모델

리스크 조심

---

- 소프트웨어 기능을 나누어 점증적으로 개발한다. 

-> 실패할 위험이 줄어들고, 테스트하기 용이하며 피드백이 잘 이루어짐

 

- 여러 번의 점증적인 릴리스를 한다.

 

단계

1. 목표, 방법, 제약 조건 결정
2. 위험 요소 분석 및 해결
3. 개발과 평가
4. 다음 단계의 계획 

-> 이걸 반복 순환 (복잡함)

 

a기능 (1~4) ~  b기능 (1~4)

 

장점

• 리스크가 큰 대규모 시스템 개발에 적합하다. 

• 계속 같은 과정을 반복 -> 강인성 향상됨 

 

• 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능

-> 한 단계에 모든 걸 다 끝내지 않아도 됨 <-> 폭포수 모델 

 

단점

 

• 관리 복잡

 

• 위험 분석을 잘못해서 발견하지 못하면 -> 큰 피해 

 

• 성공 사례가 별로 알려지지 않음 (잘 안쓰임)

 

 

추천

• 재정적, 기술적 위험 부담이 큰 경우 

 

• 요구 사항, 아키텍처 이해가 어려운 경우 

 

 

4️⃣ 진화적 모델

조금씩 릴리스

---

- 빠른 개발을 위해서 시스템을 나누어 릴리스한다. 

- 시스템이 점점 진화함 

 

릴리스 구성 -> 어떻게 시스템을 나눌지?

 

방법1 : 점증적 방법

-> 기능별로 나누어 릴리스 한다.

a 릴리스하고, 그 다음에 a&b 릴리스, 그리고 a&b&c 릴리스 .. 

 

방법2 : 반복적 방법

-> 완성도를 나누어서

완성도가 좀 떨어지는 a&b&c 릴리스 -> 좀 더 보완한 a&b&c 릴리스 -> ... 

 

장점

• 기능이 모두 완성되지 않았거나, 완벽하지 않아도 빠르게 출시 가능 

-> 이후 개발에 사용자의 피드백을 반영할 수도 있음 

 

•  빠른 출시 -> 빠른 시장 형성 -> 이득 

 

• 잦은 릴리스 -> 문제점, 오류 신속하게 찾을 수 있음 

 

• 릴리스마다 다른 영역에 초점을 맞출 수 있음. 처음에는 UI, 두번째는 성능에 초점을 맞춘 릴리스 

 

단점

• 프로젝트 관리 복잡 -> 소규모 프로젝트 비추

• 반복적인 프로세스 -> 끝이 안보여 -> 실패 위험

• 프로젝트 진행이 위험 분석에 크게 의존함

 

 추천

 

•  3~6개월 정도로 개발 사이클이 짧은 환경.

•  빠른 시간 안에 시장에 출시해야 함. -> 이윤 직결 

 

 

 

 

 

5️⃣ Unified Process

초점을 바꿔가며 계속 반복

---

- 모든 단계에서 개발에 필요한 과정을 다 진행하나, 각 단계별로 집중하는 내용이 다름 

- 모든 개발 내용(모델링, 요구, 설계, 구현, 테스팅, ...등)을 진행하는 단계를 계속 반복함

 

- 초반 반복에서는 모델링, 요구, 환경 셋팅 등에 집중하고, 이후에는 구형, 테스팅, 마지막에는 배포에 집중

 

단계

1. 도입 inception : 1,2회 정도. 일부 유스케이스 모델, sw구조, 프로젝트 계획 작성
2. 정련 elaboration : 여러번. 대부분 유스케이스. 아키텍처, 상세 설계. 중요 유스케이스 설계 구현.
3. 구축 construction : 남은 유스케이스 구현, 통합. 
4. 전환 transition : 시스템 배치. 사용자 교육. 베타 테스팅. 결함 수정.

 

-> 단계가 진행될수록 집중하는 내용이 달라진다. 

 

 

장점

 

• 방법론, 프로세스에 대한 문서화가 잘 되어 있음. -> 교육받기 좋음 

• 모든 내용을 계속 반복 -> 고객 요구 변경 관련 리스크 -> 적극 해결

 

• 통합을 위한 노력, 시간 줄어듦

• 코드 재사용 용이

 

단점

 

• 너무 복잡한 프로세스. -> 이해 어렵. 정확한 적용 어렵

 

• 프로젝트 참여자들의 협동, 의사소통에 대한 가이드가 없다

• 조직화되지 않은 개발 

 

6️⃣ 애자일 프로세스

짧게 자주!

---

 

- 2~6주 정도 짧은 주기로 개발을 반복한다. 

 

- 팀 커뮤니케이션이 중요하다. 엔지니어의 역량과 기술 중요. 

- 고객도 참여해! 어차피 장기 계획을 세워봐야 변경된다! 유연하게! 

 

애자일 선언

2001년, 17명의 개발 리더들 ..

1. 프로세스와 도구보다는 개인과 상호작용을
2. 포괄적인 문서보다는 작동하는 소프트웨어를
3. 계약 협상보다는 고객 협조를
4. 계획을 따르기보다는 변경에 대응하는 것을