Software Engineering

소프트웨어 개발 프로세스 모델

taey 2024. 10. 26. 02:10

전통적인 소프트웨어 프로세스 모델 

  1. 폭포수 모델
  2. 점진적 모델
  3. 프로토타입 모델
  4. 나선형 모델
  5. V 모델
  6. 변환 모델

 

전통적인 소프트웨어 개발 과정 

  • 실현 가능성 분석
    • 사용자의 요구사항에 따라 소프트웨어 시스템을 개발하고자 할 때, 비용, 일정, 기술적 수준 등이 충분히 가능한가를 살펴보는 것
    • 따라서 개발 비용, 이득, 대안을 평가   
개발 비용 ▪ 개발 인건비뿐만 아니라 백업용 하드웨어 비용, 개발 및 운영 소 프트웨어 도구 비용, 유지보수 비용, 문서화 소요 비용, 개발자 교 육비, 시스템 교체 비 용 등 모든 비용
이득 ▪  새로운 시스템이 제공 하는 비즈니스 프로세 스의 개선된 영역은?

▪  운영의 효율성과 정확 성은 증진되는가?

▪  의사결정을 위한 정보 제공을 적시에 제공받 을 수 있는가?
대안 ▪ 비용과 이득 산정 시 다양한 측면을 고려하 여 Trade-off 분석

▪ 예) 고급 기술자를 고 용하는 경우와 기존 직원을 교육하는 경우 를 각각 고려해 분석
  • 실현 가능성 분석을 위해 고려할 측면
    • 경제적 측면
      • 비용 대 효과 분석을 수행하여 프로젝트가 비용 측면에서 정당하게 평가받을 수 있는가?
    • 기술적 측면
      • 소프트웨어 개발 프로젝트에서 필요한 이론이나 기술에 대해 제약 사항이 없는가?
      • 현재 가용한 기술 수준으로 목표 소프트웨어를 구현하기에 충분한가?
    • 스케줄 측면
      • 소프트웨어 개발 프로젝트를 가용한 인력과 자원으로 주어진 기간 내에 완료할 수 있는가?
    • 운영적 측면
      • 개발된 소프트웨어가 사용자에게 전달되었을 때, 데이터 입력이 가능한가?
      • 소프트웨어 운영에 대한 역할이나 책임을 수행하기에 시스템 관리자가 주저함이 없는가?
    • 동기적 측면
      • 개발된 소프트웨어를 실제로 사용할 사용자가 그 필요성을 인정하고 있는가?
      • 소프트웨어가 사용자에게 배포되었을 때, 지체 없이 정확하게 업무에 적용할 수 있는가?
    • 법적•윤리적 측면
      • 개발된 소프트웨어 기능을 사용하는 과정에서 개인 정보 유출과 같은 법적 분쟁의 소지가 발생할 수 있는가?
      • 사회적인 문제를 유발할 수 있는 기능이 포함되어 있는가?

1. 폭포수 모델(Waterfall Model)

  • 폭포의 물이 아래로 떨어지는 것처럼 순차적인 단계로 소프트웨어를 개발하는 것
  • 각 단계마다 정해진 소프트웨어 문서를 작성
    • 작성된 문서는 사용자 확인 과정을 거쳐 다음 단계의 입력으로 사용됨
  • 폭포수 모델의 단점
    • 개발 과정에서 요구되는 변경을 수용하기가 어렵다
    • 입력으로 사용되는 이전 단계의 결과물에 오류가 잔존하는 경우, 다음 단계에 영향을 준다.
  • 폭포수 모델의 변형
    • 피드백이 가능한 폭포수 모델
    • 각 단계를 중첩하여 진행하는 폭포수 모델(점진적 모델) 등

 

 

2. 점진적 모델의 전략

  • 개발 및 배포 : 개발자는 실사용자가 원하는 것을 개발하여 제공한다.
  • 측정 및 모니터링 : 배포된 부분에 대한 사용자 유용성을 평가한다.
  • 조정 및 수정 : 모니터링 결과를 설계와 구현에 반영한다.
  • 점진적 모델의 이점
    • 새로운 제품 개발 시 사용자의 요구사항이나 변경을 반영할 시간이 주어진다.
    • 변경을 쉽게 수용할 수 있다.
    • 점진적• 단계적 개발을 통해 사용자에게 사용 가능한 소프트웨어 시스템을 신속하게 전달할 수 있다.
  • 점진적 모델의 문제점
    • 각 빌드에 대한 테스트와 통합이 반복적으로 수행되어 오버헤드가 발생할 수 있다.
    • 사용자 피드백을 반영하면 이미 개발된 시스템의 구조화가 무너질 수 있다.
    • 일부 기능만 있는 소프트웨어의 신속한 배포가 오히려 전체 시스템을 기대한 사용자에게 실망을 줄 수 있다.

 

3. 프로토타입 모델 (Prototype Model)

  • 점진적 모델의 한 유형으로, 개발 및 배포, 사용자 만족도 측정, 조정 및 수정을 통한 시스템 개발 전략을 기반으로 소프트웨어 시스템 개발
  • 기능 메뉴(혹은 버튼)만 포함하는 사용자 인터페이스 원형을 보여주거나 사용자에게 중요하다고 판단되는 핵심 모듈만 우선적으로 개발하여 사용자에게 제공하고 이를 통해 사용자의 요구 사항을 만족했는지 여부를 판단하고, 이를 바탕으로 최종 시스템을 구현
  • 즉, 요구 사항을 검증하기 위해 프로토타입 개발 → 폭포수 모델에 따라 전체 시스템을 개발
  • 프로토타입 모델의 이점
    • 사용자 요구사항을 검증하여 개발 비용과 시간을 단축할 수 있다.
    • 프로토타입을 통해 사용자와 개발자 혹은 개발자 간 의사소통이 이루어져 상호 동일한 개념을 확보할 수 있다.
    • 소프트웨어를 개발하는 동안 보다 빠른 시점에서 오류 탐지가 가능하다.
  • 프로토타입 모델의 문제점
    • 사용자 검증 과정 이후에 변경이 발생하는 부분을 고려하지 못한다.

 

4. 나선형 모델 (Spiral Model)

  • 소프트웨어 시스템 개발 시 위험을 최소화하기 위해 점진적으로 전체 시스템으로 개발해나가는 모델로 소프트웨어 개발 과정이 반복적이고 점진적으로 진행되는 나선 모양
  • 목표 설정 → 위험 분석 → 구현 및 테스트 → 평가 및 다음 단계 수립의 활동 반복 
  • 나선형 모델의 장점
    • 체계적인 위험 관리로 위험성이 큰 프로젝트를 수행하기에 적합하다.
    • 사용자 요구 사항을 더욱 상세히 적용할 수 있다.
    • 변경되는 요구 사항을 반영하기 쉽다.
    • 최종 개발된 소프트웨어 시스템에 대한 사용자 만족도와 품질이 높아진다.
  • 나선형 모델의 문제점
    • 프로젝트 기간이 길어진다.
    • 반복되는 사이클이 많아질수록 프로젝트 관리가 어렵다.
    • 위험 분석에 따른 비용이 발생하고, 위험 관리를 위한 전문적 지식이 요구된다. 

 

5. V 모델 (V Model)

  • 폭포수 모델의 확장한 Verification and Validation 모델
  • V 모양의 왼쪽은 아래 방향으로 내려가면서 폭포수 모델에 따른 소프트웨어 개발 과정이 진행하고, 코딩 단계 이후에는 다시 오른쪽으로 올라가면서 테스트(시험) 과정이 단계별로 수행
  • V 모델의 장점
    • 소프트웨어 개발 결과물에 대한 단계적인 검증과 확인 과정을 거침으로써, 개발 소프트웨어에 대한 오류를 줄일 수 있다.
    • 요구사항이 정확히 이해되는 작은 시스템 개발 시 매우 유용하다.
  • V 모델의 단점
    • 폭포수 모델을 적용함으로써 개발 활동에 대한 반복이 허용되지 않기 때문에 변경을 다루기 쉽자 않다.

 

6. 변환 모델 (Transformation Model)

  • 정형 명세(Formal Specification)를 기반으로 하는 소프트웨어 개발 프로세스
  • 일반적으로 소프트웨어 요구 사항을 제트(z), 패트리 넷(Pertri Nets), SDL(Specification and Description Language), 상태 차트(State Chart), 시간 논리(Temporal Logic) 등의 정형 기법을 이용하여 명세한 후에, 자동화된 도구를 사용해 직접 코드로 변환하여 소프트웨어 개발

소프트웨어 프로세스 개선

프로세스 개선모델 

  1. CMM
  2. CMMI
  3. SPICE
  4. A-SPICE
  5. 6 시그마

1. CMM (Capability Maturity Model)

  • 1986년 미 국방부가 방산 업체의 소프트웨어 개발 활동에 대한 데이터를 수집하고 이를 체계화하여 개발한 시스템 개발 프로세스의 성숙 모델
  • 성숙도 (Maturity) : 임의로 수행해온 개발 활동을 공식적인 개발 단계, 단계별 활동에 대한 측정 및 평가, 프로세스 최적화 등의 관점에서 얼마나 잘하고 있는지 나타내는 척도
  • CMM 모델은 기존 소프트웨어 개발 프로세스를 개선하는 것을 목적으로 함

 

2. CMMI (Capability Maturity Model Integration)

  • 다양한 CMM 모델의 형식•용어 •측정 방법의 차이점 존재
  •  통합 적용의 어려움과 같은 단점을 해결하기 위한 시도 발생 → CMMI 탄생
  • CMMI 성숙도 수준
    • '무엇을 하는가'라는 프로세스 기반 활동 영역과 '얼마나 잘하는가'를 나타내는 능력도 범위로 표현  

  • CMMI 구성 요소

 

3. SPICE (Software Process Improvement and Capability dEtermination)

  • 소프트웨어 개발 프로세스 개선을 목적으로 제정된 ISO 15504 표준의 별칭
  • 6개의 성숙도 수준 정의
    • 레벨 5 - 최적화 프로세스
    • 레벨 4 - 예측 가능한 프로세스
    • 레벨 3 - 구축된 프로세스
    • 레벨 2 - 관리되는 프로세스
    • 레벨 1 - 적용하는 프로세스
    • 레벨 0 - 불완전한 프로세스
  • 15504 표준에서 정의하는 프로세스 속성
    1. 프로세스 성능
    2. 성과 관리
    3. 산출물 관리
    4. 프로세스 정의
    5. 프로세스 배포
    6. 프로세스 측정
    7. 프로세스 제어
    8. 프로세스 혁신
    9. 프로세스 최적화

4. A - SPICE (Automotive SPICE)

  • 레벨 5 - Innovating : 장기 전략과 조직의 변화에 따라 조직 차원의 정량적 피드백을 통해 프로세스를 개선하고(개선 시 이득을 정량적으로 분석), 이에 맞게 표준을 개선하며, 프로젝트에서는 개선된 표준이 바로 적용 가능한 수준
  • 레벨 4 - Predictable : 비즈니스 목표 정의 및 이에 따른 프로세스 성과를 정량적으로 측정 기록하고, 통계적으로 히스토리를 분석하여 객관적인 결정을 내리며, 그 결정이 특정 범위 안에 유지되는 수준
  • 레벨 3 - Established : 조직 수준의 표준 프로세스와 테일러링 가이드가 있으며, 조직 차원 피드백을 통해 표준 자산(프로젝트 산출물)을 개선하는 수준
  • 레벨 2 - Managed : 프로세스 수행이 통제(계획, 관리, 조정)되며 역할이 정의되어 있고, 결과물은 품질 보증, 형상 관리 절차에 따라 관리되는 수준
  • 레벨 1 - Performed : 프로세스가 체계적이지는 않지만, 어떻게든 목표가 달성되고 결과물이 존재하는 수준
  • 레벨 0 - Incomplete : 프로세스 수행 결과가 존재하지 않음. 불완전하거나 부적절한 프로세스로 인하여 목적 달성이 불가능한 수준

5. 식스 시그마

  • 프로세스 개선을 위한 공학적 기술 및 지원 도구를 제공하는 프로세스 관점의 접근 방법론
  • 1986년 모토로라의 인제니어인 빌 스미스가 제시
  • 결함의 원인을 식별 및 제거하고, 기존의 제조 및 비즈니스 프로세스에 대한 변경을 최소화하면서, 공학적 활동의 품질을 개선하는 것을 목표로 함
  • 식스 시그마 도입을 위한 개선 목표들
    • 공정 주기 단축
    • 결함 및 문제 감소
    • 비용 감소
    • 고객 만족도 향상
    • 이익 증가 

 

기타 프로세스 표준

프로세스 표준

  1. ISO 12207
  2. ISO 29110
  3. ISO 15288

1. ISO 12207 (Systems and software engineering - software life cycle processes)

  • 합의 프로세스 : 구매자와 공급자 간의 계약 수립과 관련된 프로세스를 포함하며, 세부 프로세스로 Acquisition 프로세스와 Supply 프로세스가 있음
  • 조직 프로젝트 지원 프로세스 : 조직에서 시스템 개발 및 관련 프로젝트를 시작하고, 통제 및 관리하고, 지원하기 위해 사용될 수 있는 프로세스 영역, 수명 주기 모델 관리 프로세스, 인프라 구조 관리 프로세스, 포트폴리오 관리 프로세스, 품질 관리 프로세스 등으로 구성
  • 기술 관리 프로세스 : 프로젝트 계획, 프로젝트 평가, 의사 결정, 리스크 관리, 형상 관리, 품질 보증과 같은 활동을 정의하는 프로세스들로 구성
  • 기술 프로세스 : 소프트웨어 개발과 직접적으로 관련된 프로세스. 요구사항 정의, 아키텍처 정의, 시스템 분석, 구현, 통합, 검증, 운영 유지 등의 프로세스를 포함  

 

2. ISO 29110 (Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs) )

  • Planning, Execution, Evaluation, Closure의 활동으로 구성되는 프로젝트 관리 프로세스와 Initiation, Analysis, Design, Construction, Integration and test, Delivery 활동으로 구성되는 구현 프로세스 영역으로 구분
  • Entry 태스크, Basic 태스크, Intermediate 태스크, Advanced 태스크로 구분해 선택적으로 태스크를 수행할 수 있도록 함
  • 프로젝트 관리 프로세스에서는 117개의 태스크를, 구현 프로세스에서는 164개의 태스크를 정의
  • 외부에서 제품을 구매하는 작은 기업을 위해 획득 관리 프로세스와 이관 프로세스를 보조적으로 제시

3. ISO 15288 ( Systems and software engineering-System life cycle processes)

  • 합의 프로세스 : ISO 12207과 동일하게 획득 프로세스와 공급 프로세스로 구성
  • 조직 프로세스 : 조직 환경 관리 프로세스, 투자 관리 프로세스, 시스템 수명주기 프로세스 관 리 프로세스, 자원관리 프로세스, 품질 관리 프로세스 등으로 구성
  • 프로젝트 프로세스 : 프로젝트 계획, 평가, 관리, 의사결정, 위험 관리, 형상 관리 등과 같은 프 로세스로 구성
  • 기술 프로세스 : 요구사항 정의, 요구사항 분석, 아키텍처 설계, 구현, 통합, 검사 및 검증, 운영, 유지보수 등의 프로세스로 구성

'Software Engineering' 카테고리의 다른 글

UML 모델링 언어  (3) 2024.10.26
사용자 요구 사항  (3) 2024.10.26

'Software Engineering'의 다른글

  • 현재글소프트웨어 개발 프로세스 모델

관련글

티스토리툴바