1. 소프트웨어 공학에서 프로세스란?
*작업 순서의 집합과 일정, 예산, 자원 등 제약 조건을 포함하는 일련의 활동과 그것들의 순서
*작업(task) : 소프트웨어를 개발할 때 일을 수행하는 작은 단위
프로세스를 설명할 때에는 누가 참여하는지, 무엇을 만드는지와 일련의 활동에 영향을 주는 조건들이 중요하다.
- 제품과 산출물 : 프로세스 활동의 결과물이다.
- 역할(role) : 프로세스에 참여하는 사람들의 책임을 나타낸다.
- 사전/사후 조건 : 프로세스 활동이 이루어지거나 제품이 만들어지는 전과 후에 만족해야 하는 조건들이다.
그냥 소프트웨어 시스템을 개발하거나 유지보수할 목적으로 수행되는 활동 또는 그 절차를 뜻한다.
2. 프로세스가 필요한 이유
소프트웨어 개발 프로세스의 목적은 전체적인 개발에 대한 가이드라인을 제공하는 데 있다.
소프트웨어 개발 프로세스를 이용하면 전체 프로세스의 이해에 도움을 주고, 자원 사용에 대한 사전 계획을 가능하게 하며 자원사용을 추적하고 통제할 수 있다.
체계적인 개발을 지원할 수 있으며 프로젝트의 관리에도 도움을 주기에, 개발 조직은 적당한 프로세스 모델을 보유하여 공통의 개발문화와 공통의 기술을 제공해야한다.
소프트웨어 개발 프로세스 모델은 SDLC, Software Development Life Cycle를 기반으로 설명된다.
생명주기 5단계 요구분석 -> 설계 -> 구현(코딩) -> 테스트 -> 발전&유지보수
3. CMMI 란?
조직의 프로세스 개선 활동을 효율적으로 지원하기 위한 모델
조직의 개발능력이 얼마나 성숙되었는지를 평가할 수 있도록 만든 모델로써, 현재 전 세계 106개국에서 도입하여 적용하고 있는 산업계 표준이다.
CMMI에서는 조직의 프로세스 성숙도를 다음의 성숙도 레벨 5단계로 표현한다.
CMMI의 성숙도 단계
- 레벨 1: 초기 (Initial): 이 단계의 조직은 프로세스가 문서화되거나 표준화되지 않아 예측 불가능하며, 제어되지 않는 상태입니다. 결과는 종종 예측할 수 없고, 프로젝트의 성공은 개인의 역량에 크게 의존합니다.
- 레벨 2: 관리 (Managed): 프로젝트 수준에서 기본적인 프로젝트 관리 프로세스가 수립되어 있습니다. 계획, 수행, 측정 및 통제의 기본적인 접근 방식이 존재하여 프로젝트 결과를 더 예측 가능하게 합니다.
- 레벨 3: 정의됨 (Defined): 조직 수준의 표준 프로세스가 정의되어 있으며, 프로젝트 팀은 이 표준을 기반으로 자신의 프로세스를 맞춤화합니다. 조직 전체의 활동이 더 일관되고 예측 가능해집니다.
- 레벨 4: 양적 관리 (Quantitatively Managed): 프로세스의 성능을 측정하고 관리하기 위해 양적(정량적) 목표를 사용합니다. 이 단계에서는 데이터를 분석하여 프로세스 성능을 지속적으로 개선합니다.
- 레벨 5: 최적화 (Optimizing): 지속적인 프로세스 개선을 통해 신규 목표 달성과 현재 프로세스의 성능 개선에 집중합니다. 이는 혁신과 기술 개발을 통해 이루어지며 변동 및 미래의 위험을 더 잘 관리하게 됩니다.
4. 프로세스의 종류
워터풀 모델, RAD 모델, 프로토타이핑 모델, v모델, 나선형 모델, 애자일 모델, 반복형 개발 모델, 스크럼, TDD 등이 있다.
아래에서 더 자세히 살펴보자
5. 워터폴 모델
소프트웨어 개발 시 단계적으로 개발하는 방법론
폭포수 모델은 계획->요구분석->설계->구현->테스트->유지보수의 단계들이 하향식으로 진행되며, 병행이나 거슬러 올라가지 않는다. 따라서, 각 단계의 종료마다 확실하게 작업을 종료하고 그 결과를 확인한 뒤 다음 단계로 내려간다.
장점
- 관리의 용이
- 체계적인 문서화
- 요구사항의 변화가 적은 프로젝트에 효과적
단점
- 각 단계는 이전 단계가 완료되어야 수행됨
- 각 단계의 결과물이 완벽한 수준이 되어야 다음 단계에서 오류없이 작업 수행 가능
- 사용자가 중간에 가시적인 결과를 볼 수 없음
6. RAD 모델
특별한 계획 없이 프로토타입을 기반으로 하는 소프트웨어 개발 방법론
계획 수립&요구분석->프로토타입 개발->프로토타입 평가->구현->테스트->유지보수의 단계로 진행된다.
장점
- 요구사항의 완전한 이해와 프로젝트 범위의 명확한 설정 시 신속한 개발 및 완전한 기능 구현이 가능
- 재사용 가능 컴포넌트 활용으로 시스템 시험 기간이 짧아짐
단점
- 책임감 있는 구성원이 없을 경우 실패
- 적절한 모듈화 가능성이 전제되어야 함
- 기술적 위험이 높을 경우 부적합
7. 프로토타이핑 모델
요구분석 -> 프로토타입 설계 -> 초기 프로토타입 개발 -> 고객 피드백 수집 -> 프로토타입 수정의 단계로 진행된다.
장점
- 요구사항을 명확히 정의하기 힘들 때 효과적
- 실제적이고 구체적임
- 정확한 요구사항을 도출하여 클라이언트가 원하는 시스템을 개발할 수 있음
- 클라이언트의 참여를 증진시킴
단점
- 명세가 없음
- 작은 프로젝트에 적합
- 오늘날의 환경에 부적합
그 외의 모델
v모델
개발 과정과 테스트 과정이 V자 형태로 대칭을 이루면서 진행되는 소프트웨어 개발 방법론
각 개발 단계가 끝날 때마다 해당 단계에서 발생할 수 있는 결함을 테스트하여 품질을 보장한다.
장점
- 이해와 적용법이 쉬움
- 작업의 순서가 명확하여 관리가 용이
단점
- 요구사항 변경에 유연하지 않음
나선형 모델
계획, 위험 분석, 엔지니어링 및 고객 평가의 4가지 주요 활동을 반복적으로 수행하는 개발 방법론
결과적으로 위험을 최소화할 수 있다.
장점
- 위험 분석에 중점을 두어 대규모 프로젝트에 적합
- 요구사항 변경에 유연
단점
- 비용 산정&프로젝트 기간의 예측이 어려움
애자일 모델
일정한 주기를 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더 하고 수정해나가는 탄력적인 방법론
장점
- 변화하는 요구사항에 신속하게 대응 가능
- 고객의 지속적인 피드백으로 품질 향상
단점
- 문서화가 충분하지 않아 후기 단계에서 어려움이 발생할 수 있음
- 프로젝트 방향 설정이 어려움
+ 워터폴 모델의 요구사항명세서 예시
나는 오늘의집의 요구사항 명세서를 작성해 보았다.
딱히 좋은 예시는 아니긴 하다.
요구사항 정의서에는 필수적으로 요구사항 구분, 요구사항 ID, 요청사항(기능), 요청사항에 대한 설명, 요청자, 수용 여부가 필요하다. 물론 플로젝트마다 다르긴 하겠지만, 잘 된 예시는 아래 링크에서 찾도록 하자
https://brunch.co.kr/@uxuxlove/123
끝~
