[Software] 소프트웨어 프로세스 모델 - 어떻게 만들 것인가

목차

• 소프트웨어 프로세스
• 폭포수 모델 (waterfall model)
• 반복진화형 모델
• 점증적 모델
• 나선형 모델
• V 모델
• 애자일 방법

 

 소프트웨어 프로세스는 소프트웨어를 개발할 때의 여러 가지 방법론 (모델)들을 의미합니다.

 

 이 포스팅에서는 소프트웨어 프로세스에 자주 사용되는 개념과, 대표적인 모델들을 아주 간략하게 소개합니다. 이후 애자일, 스크럼, TDD 등에 대해서는 별도로 자세하게 다루겠습니다.

---

소프트웨어 프로세스

 

언제 누가 무엇을 어떻게 만들 것인가?

 

 소프트웨어 프로세스란 소프트웨어를 개발 또는 유지보수할 목적으로 수행하는 절차를 말합니다. 개발조직이라면 소프트웨어에 적합한 프로세스 모델을 보유하고 그에 맞는 개발문화와 공통 기술을 제공해야합니다.

 

일반적 프로세스

1. 명세 : 소프트웨어의 기능과 운영 상의 제약조건 선정
2. 개발 : 소프트웨어를 설계하고 프로그래밍 (개발)
3. 검증 : 요구사항대로 구현되었는지 검사 (검증)
4. 진화 : 소프트웨어 수정

 

프로세스 모델의 필요성

• 소프트웨어 전체 프로세스 이해에 도움
• 개발이 구조화된 방법으로 진행
• 사전에 자원사용을 계획하게 하고 자원을 통제할 수 있음
• 개발 과정을 추적, 관리할 수 있음

 

소프트웨어 프로세스의 주요 단계 (Stage)

 

타당성 조사

• 조직 측면 : 조직의 전략적 목표에 충족하는가
• 경제적 측면 : 비용대비 수익 효과
• 기술적 측면 : 주어진 시간 안에 현재 기술로 구현이 가능한가
• 운영 측면 : 운영 / 사용 능력 판단, 다른 시스템과의 연동 가능성 판단

 

요구사항 분석 / 명세

• 무엇을 개발할지 결정하는 단계
• 요구사항이란 문제를 해결하기 위해 시스템이 갖춰야 하는 조건 / 능력
• 요구사항 명세서 (SRS) : 클라이언트 (의뢰자, 고객)와 개발자 간의 의사소통 수단. 정확하고 일관성이 있어야 함
• 요구사항 명세서에는 시스템의 목적, 범위를 구체적으로 기술하고 대안 (방법)을 제시

 

코딩 and 단위 테스트

• 실제 결과를 프로그램에 작성 (코딩)
• 명세서를 만족하게 구현되어 있는지 테스트
• 고려사항 : 코딩 표준 (주석, 레이아웃, 명명 규칙 등), 테스트 절차 (테스트 계획, 방법, 수준), code inspection

 

통합 and 시스템 테스트

• 통합 테스트 : 모듈들을 통합하여 점증적으로 시스템을 구축, 테스트해 나감
• 시스템 테스트 : 모든 모듈이 통합된 다음 최종 완성 시스템이 요구사항에 만족하는지 확인

 

알파 테스트

• 소프트웨어 개발 현장에서 진행
• 일반 소트트웨어의 경우 독립적으로 테스트팀이 수행 후 베타버전 릴리즈
• 주문형 소프트웨어의 경우 개발자 플랫폼에서 실사용환경을 시뮬레이션한 후 고객이 제품 인수에 대한 동의가 이루어질 때까지 수행

 

베타 테스트

• 고객의 실제 운영환경에서 수행
• 가망 상용자로부터 미리 제품에 대한 평가받음

---

프로토타이핑 (prototyping)

 프로토타이핑은 요구사항을 파악하기 아주 좋은 방법입니다. 일반적인 의뢰자는 소프트웨어의 입출력, 처리기능 등을 자세히 요구하지 못하고, 개발자는 알고리즘의 효율성, 운영체제와의 호환성 등을 사전에 정확히 판단하기 어려울 수 있습니다.

 

장점

• 프로젝트의 실현 가능성, 소프트웨어의 개발 가능성을 판단하기 용이함
• 개발자 - 사용자 간의 의사소통 원활해짐
• 사용자가 성능, 유용성 등에 대해서도 품질요구를 명확히 할 수 있음
• 사용자가 시스템을 미리 사용해 볼 수 있음
• 개발단계에서 유지보수가 일어나지 않음

 

단점

• 문서화가 힘들고, 진척사항을 제어하기 힘들어짐

 

throwaway - prototyping

• 프로토타입을 고객과의 의사소통 수단으로만 사용
• 요구 확인 후 프로토타입을 없애고 새로운 시스템으로 개발

 

evolutionary - prototyping

• 잘 아는 부분부터 시작해서 점증적으로 발전시켜 완제품을 만듦

 

---

폭포수 모델 (Waterfall Model)

 

폭포수 모델 (출처 : https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%AA%A8%EB%8D%B8)

 각 단계가 병행 (병렬)으로 수행되지 않고, 역으로 거슬러 올라가지 않으며, 단방향으로 진행됩니다. (그러나 수정을 위해 앞단계로 돌아가 피드백을 하는 절차는 불가피) 선형 순차 모델, 고전적 소프트웨어 생명 주기라고도 합니다. 

 

장점

• 선형모델로서 단순하고 이해가 쉬움
• 단계들이 정형화되어 있고, 체계적인 문서화 가능
• 진행상황을 트래킹 하기 용이함

 

단점

• 요구사항을 완벽하게 문서화해야 함 => 문서화에 리소스가 많이 투입됨
• 프로세스 진행 중 변경을 수용하기 어려움
• 시스템 동작을 프로세스 후반에 확인 가능
• 대형 프로젝트에는 적용에 한계
• 일정 지연 가능성

 

---

반복진화형 모델 (Iterative Model)

 

iterative model (출처 : https://en.wikipedia.org/wiki/Iterative_and_incremental_development)

 

 초기 버전을 만들고 요구사항을 정제하여 새로운 버전을 개발하는 과정을 반복하면서 소프트웨어를 완성해 가는 모델입니다. 요구사항을 분명히 하고 시스템 범위를 정하는 노력이 필요하고, 진화가 한번 될 때마다 프로토타이핑을 통해 요구사항을 보완하는 방식입니다. 최종 버전이 나온 이후에야 비로소 유지보수 단계에 들어갑니다.

 

장점

• 요구사항이 완벽하지 않아도 초기버전을 만들어 점차 요구사항을 완벽하게 도출할 수 있음

 

단점

• 개발비용 예상이 힘듦
• 작업이 반복되면서 종료시점이 일정보다 늦어질 수 있음
• 잦은 수정작업이 유지보수성에 문제를 줄 수 있음

 

 

---

점증적 모델 (Incremental Model)

 

출처 : educba.com

 여러 개의 모듈로 분해하고 각 모듈을 점증적으로 개발하여 인도하는 방식입니다. 선형 순차모델을 여러 번 적용하여 결과물을 조합합니다. 이때 각 모듈을 증분 (increment)라고 합니다. 핵심모듈부터 개발하고 인도합니다.

 

장점

• 핵심 모듈 (중요 증분)이 먼저 개발되기에 사용자가 이른 시기에 사용이 가능함
• 핵심 모듈의 테스트 회수가 늘어남
• 릴리스 방식이 요구사항 변화에 대응이 용이함
• 프로세스가 진행됨에 따라 증분 규모가 작아져 관리가 쉬움

 

단점

• 최초에 증분을 분리하는 작업이 필요
• 증분을 분리하기 전에 요구사항을 명확히 정의해야 함
• 기능적으로 분해가 어려움

 

반복진화형 모델과의 차이점

반복 진화형 모델은 요구사항이 불안정할 때 사용 가능합니다. 개발이 진행되면서 요구사항의 변화를 수용하기 때문입니다. 또한 새로운 기술을 적용할 때나 한꺼번에 모든 기능을 포함해서 인도해야 할 때 적합합니다.

---

나선형 모델 (Spiral Model)

 

출처 : https://www.geeksforgeeks.org/software-engineering-spiral-model/

 

 반복 진화형 모델의 확장 형태입니다. 전체 생명 주기 (cycle)에서 위험을 분석하고, 프로토타피잉을 계획하여 위험을 최소화하는 것이 목적입니다. 위험관리에 비용이 들지만 가치를 둡니다. 위험요소는 프로젝트 수행이나 제품 품질에 악영향을 줄 수 있는 잠재요소로 보기 때문입니다. 실험적이고 복잡한 대형 프로젝트에 적합합니다.

 

장점

• 대형 프로젝트에서 위험관리 가능
• 프로젝트 특성, 개발 조직 문화에 맞게 변형 가능

 

단점

• 경험이 부족하면 검증이 어려움
• 모델이 복잡하고, 프로젝트 관리가 어려움

 

---

V 모델 (V - Model)

 

출처 : https://ko.wikipedia.org/wiki/V_%EB%AA%A8%EB%8D%B8

폭포수 모델의 확장형태로 생명주기 단계별로 대응하는 테스트 단계를 배치합니다. 위에서 아래로 진행되다가 코딩간계를 거치면서 다시 위로 향합니다. 테스트 작업을 중요시하며 적정 수준의 품질 보증을 지원합니다. 단계별 테스트에서는 코드뿐 아니라 요구사항과 설계 결과도 같이 테스트합니다.

 

장점

• 생명주기 초반부터 테스트 지원
• 폭포수 모델에 비해 반복, 재처리 과정이 명확
• 테스트 작업이 단계별로 구분되어 책임이 명확

 

---

애자일 방법 (Agile)

 변화를 수용, 협업, 제품의 빠른 인도를 강조하는 반복적 개발방법론입니다. 요구사항이 바뀌기 쉬운 종소형 비즈니스 시스템에 적합합니다. (요즘은 대형 개발사들도 사용함)

 

• 문서보다 소프트웨어 (코드)를 중요시함
• 요구사항의 변화는 불가피한 것으로 간주하고 대응하는 것이 현실적인 방안으로 간주
• 기존의 개발 프로세스들은 설계기간이 상대적으로 길고, 다시 작업 시 (수정, 유지보수) 오버헤드가 크다고 생각
• 환경에 빠른 변화에 대응하는 것을 중요시

---

익스트림 프로그래밍 (XP)

 

출처 : https://ko.wikipedia.org/wiki/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

 

 

애자일의 대표적인 방법 중 하나로서 good practices를 적극 수용할 것을 요구합니다.

 

good practices (실천 지침)

• 작고 빈번한 릴리스 => 빠른 피드백 후 지속적인 개선
• 고객이 개발팀의 일원
• 사람중심의 작업과 짝 프로그래밍
• 단순한 설계
• 테스트 주도 개발 (TDD)
• 리팩토링

 

짝 프로그래밍 (Pair Programming)

 두 사람이 짝이 되어 (A가 코딩 B가 검사 -> B가 코딩 A가 검사) 사이클을 바꿔가며 (ex. 30분) 프로그래밍하는 것을 말합니다. 

 

장점

• 코드에 대한 책임을 공유 (한 명의 코드가 아닌 공통의 코드)
• 코드 개선을 위한 리팩토링이 진행됨
• 생산성이 올라감

 

테스트 주도 개발 (Test Driven Development, TDD)

 테스트 케이스를 먼저 작성한 뒤 테스트를 성공할 수 있는 코드를 만드는 것입니다. 업무 (Task) 별로 테스트 케이스를 만들고 업무별로 테스트를 진행한 뒤 통합 과정에서 기존 소프트웨어의 오류가 유입되지 않는 통합 테스트를 강조합니다. 

 

스크럼 (Scrum)

출처 : https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%81%AC%EB%9F%BC_(%EC%95%A0%EC%9E%90%EC%9D%BC_%EA%B0%9C%EB%B0%9C_%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4)

 애자일 과정에서 관리에 초점을 둔 관리 / 개발 프레임워크입니다. 스크럼은 계획과 sprint의 반복입니다.

 

sprint cycle

1. Product Backlog : 작은 프로젝트를 10명 이내 인원이 한 달 이내 개발
2. Sprint Backlog : 스프린트 계획
3. Review : 리뷰 / 회고

 

---

참고

 

https://en.wikipedia.org/wiki/Iterative_and_incremental_development

Iterative and incremental development - Wikipedia

https://www.geeksforgeeks.org/software-engineering-spiral-model/

Software Engineering | Spiral Model - GeeksforGeeks

https://ko.wikipedia.org/wiki/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

익스트림 프로그래밍 - 위키백과, 우리 모두의 백과사전

https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%81%AC%EB%9F%BC_(%EC%95%A0%EC%9E%90%EC%9D%BC_%EA%B0%9C%EB%B0%9C_%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4) 

스크럼 (애자일 개발 프로세스) - 위키백과, 우리 모두의 백과사전