[ 소프트웨어공학 ] 소프트웨어 프로세스 : 소프트웨어 프로세스 모델과 소프트웨어 프로세스 활동

 

 

 

 

소프트웨어 프로세스

 

1.  소프트웨어 프로세스란 ?

소프트웨어 프로세스란, 소프트웨어를 개발할 때 수행해야 할 세부 활동들의 집합

• 핵심은 "무슨 활동을 할 것인가"를 정의하는 것이며, 활동들의 구체적인 순서나 구조는 포함하지 않음.
• 기본 활동 외에도, 필요에 따라 다음이 포함될 수 있음:
  • 프로젝트 관리
  • 형상 관리
  • 품질 관리
  • 문서화 등

즉, 소프트웨어 프로세스는 프로젝트의 성격에 따라 달라질 수 있으며, 하나의 고정된 답이 있는 것이 아니라 상황별 맞춤형 활동 집합입니다.

 

 

2. 소프트웨어 프로세스의 기본 활동

1. 명세화(Specification)
   • 소프트웨어가 무엇을 해야 하는지 정의.
   • 이해관계자 요구사항을 수집하고 분석하여 요구사항 문서로 정리.
   • 예: 로그인 기능이 필요하다 → 인증 절차, 보안 요구조건 등을 문서화.
2. 개발(Development)
   • 설계(Design)와 구현(Implementation) 단계.
   • 아키텍처 설계, UI/UX 설계, DB 설계 등을 포함.
   • 코드를 작성하여 실제 시스템으로 구현.
3. 검증(Validation / Verification)
   • 요구사항에 맞게 소프트웨어가 제대로 동작하는지 확인.
   • 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트 등 다단계로 진행.
4. 진화(Evolution)
   • 소프트웨어는 한 번 완성되면 끝나는 것이 아님.
   • 새로운 요구사항이 생기거나 환경이 변할 때 유지보수 및 기능 개선이 반복적으로 이루어짐.

 

 

3.  프로세스 정의 시 고려할 요소들

( 1 )  소프트웨어의 성격

• 예: 인슐린 펌프 소프트웨어 → 생명과 직결되므로 안전성 검증 활동 필수.
• 반면, 단순한 프로토타입 개발 프로젝트라면 빠른 구현과 반복적 검증이 더 중요.

( 2 )  제품 vs 산출물

• 제품(Product): 최종 결과물 (실제로 동작하는 소프트웨어).
• 산출물(Artifact): 중간 결과물 (요구사항 문서, 설계 다이어그램, 테스트 계획 등).
• 소프트웨어 프로세스에는 제품뿐 아니라 다양한 산출물도 포함되어야 함.

( 3 )  역할

• 개발자, 디자이너, 테스트 엔지니어, 프로젝트 매니저, 형상관리자 등 각자 다른 역할이 존재.
• 각 역할에 맞는 활동들이 프로세스에 반영되어야 함.

( 4 )  사전 조건과 사후 조건

• 사전 조건(Pre-condition): 특정 활동을 시작하기 전에 충족되어야 하는 조건.
  • 예: 설계를 시작하기 전에 요구사항 명세가 승인되어야 함.
• 사후 조건(Post-condition): 활동을 마친 후 확인해야 하는 결과 조건.
  • 예: 설계가 끝난 후, 결과물이 리뷰를 거쳐 합의되어야 함.

 

 

4.  소프트웨어 프로세스 모델 : 계획주도 방법론, 점진적 개발 방법론, 애자일 방법론, 재사용 중심 방법론

 

1 )  계획주도 방법론1 : 폭포수 모델 (Waterfall Model)

폭포수 모델은 가장 전통적이고 대표적인 소프트웨어 개발 프로세스 모델

이름처럼 물이 위에서 아래로 한 방향으로만 흐르는 것처럼, 단계가 순차적으로 진행

 

주요 단계

1. 요구사항 분석 (Requirements Analysis)
   • 어떤 소프트웨어를 만들지 정의하는 단계
   • 기능, 제약사항 등을 고객과 협의하여 문서화(명세서 작성)
2. 시스템 및 소프트웨어 설계 (System & Software Design)
   • 요구사항을 기반으로 전체 구조를 설계
   • 서버, 컴포넌트, 인터페이스, 배치 구조 등을 정의
   • 하드웨어가 필요한 경우, 하드웨어 설계팀과 역할을 분리
3. 구현 및 단위 테스트 (Implementation & Unit Testing)
   • 개발자가 맡은 모듈을 코딩하고, 함수/메소드 단위로 동작을 검증
   • 구현 전, 필요한 알고리즘·자료구조·로직 설계를 함께 진행
4. 통합 및 시스템 테스트 (Integration & System Testing)
   • 각 모듈을 통합하여 전체 시스템을 구성
   • 설계 단계에서 정의된 인터페이스와 컴포넌트 간 상호작용이 제대로 동작하는지 확인
   • 이후 실제 하드웨어나 운영 환경에서 동작하는지도 검증
5. 운영 및 유지보수 (Operation & Maintenance)
   • 고객에게 인도 후 운영 상태를 모니터링합니다.
   • 운영 환경에서 발생하는 오류 수정, 새로운 요구사항 반영, 버전 업데이트를 수행합니다.

 

폭포수 모델의 특징

• 단계적 진행: 앞 단계가 끝나야 다음 단계로 진행 가능.
• 피드백 가능: 문제 발생 시 이전 단계로 돌아갈 수 있지만, 비용과 시간이 많이 듦.
• 문서 중심: 각 단계마다 산출물이 문서 형태로 남음 (요구사항 명세서, 설계 다이어그램, 코드, 테스트 문서 등).
• 적합한 경우
  • 요구사항이 명확하고 변경 가능성이 낮은 경우
  • 문서화가 중요한 프로젝트 (예: 정부 과제, 전통적 소프트웨어)
  • 소규모라도 명확하게 정의된 프로젝트

 

장점과 한계

• 장점
  • 진행 상황을 관리하기 쉽고, 문서가 잘 남음.
  • 명확한 요구사항이 있는 프로젝트에서 효율적임.
• 한계
  • 요구사항 변경에 매우 취약.
  • 고객 피드백이 늦게 반영되므로, 긴 개발 주기 후 고객 불만이 발생할 수 있음.
  • 피드백 사이클이 길어 품질 문제를 뒤늦게 발견할 수 있음.

 

 

2 )  계획주도 방법론2 : V-모델 (V-Model)

V-모델은 폭포수 모델을 확장한 형태로, 특히 품질 보증과 테스트 계획에 집중한 모델

 

V-모델 구조

V-모델은 크게 왼쪽(설계/계획)과 오른쪽(테스트/검증)으로 나뉨

• 왼쪽: 요구사항 분석 → 고수준 설계 → 상세 설계 → 구현
• 오른쪽: 단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트

 

핵심 특징: 테스트 계획의 선행 수립

폭포수 모델과 달리, 각 설계 단계에서 대응되는 테스트 계획을 미리 세운다는 점이 가장 큰 차이

• 요구사항 분석 ↔ 시스템 테스트
  → 요구사항 단계에서, 최종적으로 시스템 테스트에서 무엇을 검증할지 기준을 수립
• 고수준 설계 ↔ 통합 테스트
  → 컴포넌트·인터페이스 설계 시, 나중에 통합 테스트에서 어떻게 확인할지 계획
• 상세 설계 ↔ 단위 테스트
  → 알고리즘·로직 설계 시, 단위 테스트 항목을 미리 정의
• 구현 ↔ 코드 실행
  → 실제 개발된 코드가 앞서 계획된 설계·테스트 기준에 맞게 동작하는지 검증

 

장단점

장점

• 체계적인 품질 보증: 프로젝트 초반부터 테스트를 고려하기 때문에 품질 관리가 용이.
• 문서화 강화: 각 설계 산출물이 대응되는 테스트 기준으로 연결됨.
• 위험 감소: 테스트가 후순위가 아니라 개발 전부터 고려되므로 오류를 조기에 방지 가능.

한계

• 요구사항 변경에 유연하지 않음.
• 테스트 계획을 미리 세우는 만큼, 초기 단계의 부담이 큼.

 

 

3 )  점진적 개발 방법론 : 나선형 모델

 

• 특징
  • 폭포수 모델의 순차적 특성과 점진적 개발의 반복적 특성을 결합.
  • 특히 위험 분석을 각 반복 주기에서 수행하는 것이 핵심.
  • 한 번의 반복(Spiral) = 계획 → 위험 분석 → 개발 → 고객 평가.
• 장점
  • 위험을 조기에 발견하고 관리할 수 있음.
  • 대규모, 고위험 프로젝트에 적합.
• 한계
  • 위험 분석 자체가 비용과 시간이 큼.
  • 소규모 프로젝트에는 과도할 수 있음.

 

 

4 )  애자일 방법론

 

• 특징
  • 소프트웨어를 점진적으로 개발하면서 고객 요구와 환경 변화에 유연하게 대응.
  • 문서보다 동작하는 소프트웨어, 계약보다 고객 협력을 중시.
• 장점
  • 변화가 많은 환경에서 효과적.
  • 빠른 피드백과 반복적 개선이 가능.
• 한계
  • 장기적 계획보다는 단기 목표 중심이어서, 큰 규모 프로젝트에서는 위험할 수 있음.

 

 

5 )  재사용 중심 방법론

• 특징
  • 새롭게 구현하는 코드를 최소화하고, 이미 검증된 컴포넌트를 재사용하는 접근법
  • 프레임워크, 라이브러리, 기존 모듈 등 이미 검증된 소프트웨어 활용
  • 가능한 기존 소프트웨어 컴포넌트를 재사용 → 개발 비용과 시간 감소, 품질 향상 목표
• 장점
  
  • 개발 비용과 위험 감소
  • 소프트웨어를 고객에게 더 빠르게 전달 가능
• 단점
  
  • 요구사항을 타협해야 할 수 있음
  • 요구사항 만족 어려울 수 있음
  • 개발 조직의 재사용 컴포넌트에 대한 통제권 부재
  • 시스템 진화에 대한 주도권 상실
• 프로세스 모델

 

 

프로세스 모델 정리

구분	계획주도형	점진적 개발	애자일 방법론	재사용 중심 방법론
핵심 개념	철저한 계획과 문서화 중심	반복(iteration)과 점진적 완성	빠른 피드백, 유연한 대응	기존 컴포넌트/패키지 재사용
개발 흐름	요구사항 → 설계 → 구현 → 테스트 → 유지보수 (단방향/순차적)	프로토타입 제작 → 위험분석 → 개발/검증 반복 → 점진적 완성	스프린트 단위 반복 개발, 지속적 통합	기존 모듈·프레임워크를 조합하여 개발
장점	체계적, 문서화로 품질 보장, 대규모 프로젝트에 적합	위험 관리에 강함, 고객 요구 반영 용이	변화 대응 유연, 빠른 결과물 제공	개발 속도 향상, 비용 절감
단점	변화 대응 어려움, 초기 오류 시 전체에 영향	반복 비용 증가, 관리 복잡	문서화 부족 가능성, 규모 커지면 관리 어려움	외부 모듈 의존성, 맞춤화 어려움
적합한 상황	명확히 정의된 요구사항, 안전-critical 시스템 (예: 항공, 의료)	위험 요소가 큰 프로젝트, 고객 요구가 불확실한 경우	스타트업, 웹/앱 서비스처럼 변화 많은 환경	범용 기능이 많고, 재사용 가능한 모듈이 풍부한 경우
전사본 언급 포인트	“계획 주도형으로 폭포수·V모델이 있다”	“점진적 개발 모델의 예로 나선형 모델이 있다”	“애자일 방법론이 등장했다”	“새로운 것을 만들기보다 기존 컴포넌트/라이브러리를 재사용”