소프트웨어 공학에서의 프로세스란?
↪️ 소프트웨어 개발 프로세스: 소프트웨어 시스템을 개발하거나 유지보수하기 위해 하는 활동이다. (= 소프트웨어 생명 주기)
소프트웨어 개발에서의 프로세스는 작업 순서의 집합 + 제약 조건(일정, 예산, 자원)을 포함하는 일련의 활동이다.
소프트웨어를 개발하는 과정에서 수행하는 가장 작은 단위가 '작업(Task)'이고, 소프트웨어 개발에서 이런 작업들이 모여 프로세스를 이룬다.
✅ 소프트웨어 생명 주기의 단계
Planning(계획) → Analysis(분석) → Design(설계) → Implementation(구현) → Testing & Integration(테스트 및 통합) → Maintenance(유지보수) 와 같은 단계를 거친다.
프로세스가 왜 필요할까?
-
품질 보장: 프로세스를 통해 소프트웨어 개발 단계마다 품질 관리와 검증이 이루어지기 때문이다.
-
효율성 향상: 잘 정의된 프로세스는 작업의 중복을 최소화하고, 리소스를 효율적으로 배분해 시간과 비용이 절감된다.
-
팀워크 촉진: 프로세스는 팀 멤버들이 명확한 역할과 책임을 가지고 협업할 수 있는 기반을 제공한다.
-
위험 관리: 프로세스는 프로젝트의 가능한 위험 요소를 사전에 식별하고, 이에 대한 대응 계획을 수립하는 데 도움을 준다.
-
지속 가능한 개발: 프로젝트가 종료된 후에도 소프트웨어의 유지보수와 확장이 용이하도록 해 준다.
-
고객 만족도 향상: 프로세스를 통해 고객의 요구 사항을 정확하게 이해할 수 있다.
-
문서화: 프로세스는 프로젝트의 진행 상황과 결정 사항들을 체계적으로 문서화하는 데 도움을 준다.
소프트웨어 개발 프로세스의 목적은 '전체적인 개발에 대한 가이드라인 제공'이라 할 수 있다.
CMMI란?
💯 CMMI(Capability Maturity Model Integration): 조직의 프로세스 능력과 성숙도를 평가하는 모델
-
조직의 현재 프로세스 성숙도를 결정한다.
-
효과적인 소프트웨어 프로세스의 핵심 요소를 설명하는 프레임 워크이다.
-
임시적이고 미성숙한 프로세스에서 성숙하고 규율 있는 프로세스로 진화하는 개선 경로를 설명한다.
-
소프트에어 개발 및 유지 관리를 계획, 공학 및 관리하는 관행을 다룬다.
✅ 소프트웨어 성숙도
CMMI에는 5가지 성숙도 수준이 있는데, 다음과 같다.
① Initial(초기): 프로세스가 예측 불가능하고, 제어되지 않는 단계
② Managed(관리): 프로젝트 수준에서 프로세스가 계획되고, 수행되는 단계
③ Defined(정의): 조직 수준에서 프로세스가 표준화되고, 가이드라인을 따르는 단계
④ Quantitatively Managed(정량적 관리): 프로세스가 정량적으로 측정되고, 관리되는 단계
⑤ Optimizing(최적화): 지속적인 프로세스 개선이 이루어지는 단계
프로세스의 종류
-
워터폴 모델(Waterfall Model): 워터폴 모델은 전통적인 소프트웨어 개발 프로세스로, 순차적(선형) 접근 방식을 따른다.
-
애자일(Agile): 애자일은 빠르고 유연한 대응을 강조하는 소프트웨어 개발 방법론이다. 이 방법론은 개발 과정을 짧은 주기의 스프린트로 나누어, 지속적인 고객 피드백을 바탕으로 소프트웨어를 개발한다.
-
스크럼(Scrum): 스크럼은 애자일 개발의 한 형태로, 특히 복잡한 프로젝트 관리에 적합하다. 스크럼은 소규모 팀이 짧은 주기의 스프린트(보통 2-4주) 동안 작업을 진행하며, 정기적인 회의를 통해 진행 상황을 점검하고 다음 단계를 계획한다.
-
데브옵스(DevOps): 데브옵스는 개발(Dev)과 운영(Ops)의 합성어로, 소프트웨어 개발과 운영을 통합하여 더 빠른 소프트웨어 배포와 더 높은 품질을 달성하기 위한 문화, 운동 또는 관행을 의미한다.
-
린(Lean): 린 개발 방법론은 낭비를 최소화하고 효율성을 극대화하기 위해 노력한다. "린"은 제조업에서 유래한 개념이지만, 소프트웨어 개발에도 적용된다.
워터폴 모델
워터폴 모델은 소프트웨어의 개발 과정을 요구분석, 설계, 구현, 통합, 운영 및 유지보수의 단계로 구분하여 순차적으로 진행하는 프로세스 모델이다.
① 요구 사항 분석 및 정의: 사용자의 요구 사항을 수집하고 분석하여 문서화하는 단계. 이 단계에서는 시스템이 해야 할 일을 명확히 정의한다.
② 시스템 및 소프트웨어 설계: 요구 사항을 바탕으로 시스템의 아키텍처와 소프트웨어의 세부 설계를 수행하는 단계. 이 단계에서는 소프트웨어의 전체 구조와 각 부분의 상세를 설계한다.
③ 구현 및 단위 테스트: 설계된 소프트웨어를 실제로 코딩하고, 각 단위(모듈)별로 테스트를 수행하는 단계. 이 단계에서는 소프트웨어가 실제로 작동하는지 확인한다.
④ 통합 및 시스템 테스트: 모든 모듈을 통합하고 전체 시스템이 요구 사항을 만족하는지 테스트하는 단계. 이 단계에서는 소프트웨어의 전체적인 기능과 성능을 검증한다.
⑤ 운영 및 유지보수: 소프트웨어를 실제 운영 환경에 배포하고, 필요한 경우 유지보수를 수행하는 단계. 이 단계에서는 소프트웨어의 안정성을 확보하고, 사용자의 피드백을 반영해 개선 작업을 진행한다.
장점
- 프로젝트의 각 단계가 명확하게 정의되어 있어 계획 및 관리가 용이하다.
- 문서화가 잘 되어있어 후속 프로젝트에 참고자료로 활용 가능하다.
단점
- 초기 단계에서 요구사항의 변화를 수용하기 어렵다.
- 실제 테스트가 개발 막바지에 진행되어 초기에 문제점을 발견하기 어렵다.
RAD(신속 애플리케이션 개발) 모델
RAD 모델은 짧은 개발 주기로 빠른 피드백과 반복을 중요시하는 모델로, 프로토타입을 중심으로 개발하는 모델이다.
장점
- 사용자 피드백을 신속하게 반영할 수 있다.
- 개발 주기가 짧아 빠르게 제품을 시장에 출시할 수 있다.
단점
- 대규모 프로젝트에는 적용하기 어렵다.
- 잦은 변경으로 인해 시스템의 복잡도가 증가할 수 있다.
프로토타이핑 모델
프로토타이핑 모델은 사용자 요구사항을 정확히 이해하고자 초기 단계에서 프로토타입을 개발하고, 이를 바탕으로 시스템을 개발해 나가는 모델이다.
장점
- 초기 단계에서 사용자의 요구사항을 명확히 파악할 수 있다.
- 프로토타입을 통해 디자인과 사용성을 개선할 수 있는 기회를 제공한다.
단점
- 프로토타입에 과도한 시간과 비용이 소요될 수 있다.
- 프로토타입에서 최종 제품으로의 이행이 어려울 수 있다.
그 외의 모델
진화적 프로세스 모델
진화적 프로세스 모델은 프로토타입을 기반으로 개발하는 방법론으로, 사용자 요구사항을 깊이 이해하고 이를 바탕으로 소프트웨어를 점진적으로 발전시켜 나가는 개발 방식이다.
장점
- 실제 사용자의 요구사항을 반영하여 반복적으로 프로토타입을 개선한다.
- 사용자의 피드백을 직접 받아 제품을 개선할 수 있는 기회를 제공한다.
단점
- 반복적인 프로토타이핑 과정으로 인해 비용과 시간이 증가할 수 있다.
- 반복적인 개발 과정이 관리하기 어려울 수 있다.
증분 모델
증분 모델은 전체 소프트웨어를 여러 개의 작은 증분들로 나누어 개발하는 방식이다.
장점
- 개발 과정에서 변경사항이 생겨도 쉽게 대응할 수 있다.
- 초기 단계에서 사용자의 피드백을 반영할 수 있다.
단점
- 전체 프로젝트가 증분으로 나뉘어지므로, 초기 계획이 매우 중요하다.
- 후반부 증분 개발 시 앞선 증분에 대한 의존도가 높을 수 있다.
스파이럴 모델
스파이럴 모델은 위험 분석과 프로토타입을 반복적으로 수행하면서 개발하는 방식이다.
장점
- 각 단계에서의 위험 분석을 통해 대규모 프로젝트의 위험을 최소화한다.
- 반복적인 검토를 통해 사용자의 요구사항을 지속적으로 반영할 수 있다.
단점
- 위험 분석과 반복 개발 과정으로 인해 비용과 시간이 많이 소요될 수 있다.
- 반복적인 단계와 위험 분석 과정이 관리하기 복잡할 수 있다.
요구사항 명세 예시(워터폴 모델)
워터폴 모델을 기반으로, 해당 모델 단계의 2단계인 '오늘의집' 서비스의 요구사항 명세를 해 보았다.
- 요구 분석과 명세
- 애플리케이션에 필요한 특성을 식별
- 기능적 및 비기능적
- 무엇을 해야 하는지 명시 O, But 어떻게 해야 하는지는 명시 X
