INDEX

• 프로세스란
  • Generic Process Model
  • Process Framework
  • Process Flow
• Waterfall Model
• V Model
• Incremental Model
• Evolutionary Model
  • Prototyping
  • Spiral
• Unified Process Model
  • UP Model
• Reference

프로세스란

• 프로세스 : work product 생성을 위해 수행되는 activity, action, task의 집합
  
  Software Process & Software Engineering의 공통점 -> 소프트웨어 설계/개발을 위한 접근법 제안
  
  But, 기술적 방법론, 자동화 도구 또한 Software Engineering에 포함되는 부분이기 때문에 Software Process와 Software Engineering은 차이가 있다.
• 활동(activity)
  • 넓은 목표를 충족하는 것이 이상적
  • 도메인, 프로젝트 규모, 노력, 복잡도 등에 관계 없이 적용
• 행위(action)
  • 작고 명확한 목표를 통해 가시적 성과 창출
  • 결과 생성을 위한 task 포함
    
    
    

Generic Process Model

• Process framework는 전체 Software Process에 고르게 적용되는 activity인 Umbrella activities로 구성되어 있다.
• Umbrella activities는 framework activity[소통/기획/모델링/구축/배포]를 보완한다.

Process Framework

• Framework Activities는 Software action들로 구성되어 있고, 각각의 action은 Task Sets로 구성되어 있다.
• Task Sets 구성 요소
  • Work Tasks(완료해야하는 작업)
  • Work Products(산출물)
  • Quality Assurance Checkpoints(필요한 품질 보장 체크포인트)
  • Project Milestones(프로젝트 이정표)

Process Flow

• 선형(linear) process flow
  • 5개의 프레임워크 활동을 각각 순서대로 실행
    
    
• 반복적(iterative) process flow
  • 다음 프레임워크 활동으로 넘어가기 전 1 이상의 프레임워크 활동을 반복
    
    
• 진화적(evolutionary) process flow
  • 원형 방식으로 프레임워크 활동을 실행
  • 5개의 프레임워크 활동으로 이루어진 원을 한바퀴 돌 때마다 이전보다 더 완벽한 버전의 소프트웨어로 진화하는 것이 특징
    
    
• 병렬(parallel) process flow
  • 다른 프레임워크 활동을 실행하는 동시에 하나 이상의 프레임워크 활동을 실행
    
    

Waterfall Model

• 특징
  • 각 단계 사이에 중복이나 상호작용이 없음 - 순서적
  • 각 단계의 결과는 다음 단계가 시작되기 전에 점검
• 장점
  • 이해 및 계획이 용이
  • 잘 이해된 소규모 프로젝트에 적합
  • 분석과 테스트가 간단
• 단점
  • 변화를 잘 수용하지 못함
  • 프로세스 후반부에 테스트를 진행하여 피드백 시점이 늦어짐
• model 적용 상황
  • 단순한 시스템 개발일 경우
  • 응용 분야를 잘 알고 있는 경우
  • 일회성 프로세스
  • 비전문가가 사용하는 시스템일 경우
  • 요구사항이 고정되어있고 작업이 일정한 순서로 이루어지는 경우

V Model

• 특징
  • waterfall model의 변형
  • 작업과 결과의 검증에 초점을 맞춤
• 장점
  • 모든 phase에 따른 testing이 있어 오류를 줄일 수 있음
• 단점
  • 반복이 없어 변경을 다루기가 쉽지 않음
• model 적용 상황
  • 고신뢰성이 요구되는 분야에 적합
    
    
    

Incremental Model

• 특징
  • 실질적인 software를 기능/특징 별로 세분화하여 waterfall model로 진행
  • 각각의 increment가 release 될 때 다음 increment를 진행
• 장점
  • 기능이 부족하더라도 초기 교육에 사용 가능
  • 첫번째로 시장에 출시되는 소프트웨어가 빠른 시장 형성으로 이어짐
  • 잦은 배포는 가동중인 시스템에서 일어나는 예상하지 못한 문제들을 신속하고 꾸준히 고쳐나갈 수 있게함
  • 개발 팀은 각 release마다 다른 전문 영역에 초점을 둘 수 있음
    =>인력을 효율적으로 분배 가능
• 단점
  • waterfall model이 가지는 단점을 포함

Evolutionary Model

Prototyping

• 실행 단계
  1. Communication
     • 이해관계자와 미팅을 진행하며 소프트웨어의 전반적인 목표, 요구사항, 추가 정리가 필요한 학술 영역 파악
  2. Prototyping의 iteration 계획
  3. 모델링 디자인 (UI layout, Product display 등)
     • 사용자가 쉽게 이해할 수 있는 소프트웨어의 측면 표현에 집중
  4. Prototype 구현
  5. 이해관계자에게 Prototype 배포
     • 평가 후 피드백
     • 요구사항 세분화 & 구체화
  6. cycle 반복
     
     
• Prototype의 사용
  • 단순한 요구사항 추출 및 구현 가능성 예측
  • 개발 단계에서 유지보수가 이루어짐
    
    
• 장점
  • 요구사항 변경의 영향 감소
  • 제품 거부 가능성 감소
    
    
• 단점
  • 고객의 참여로 인한 지연 발생 가능
  • 계획과 관리가 어려움
    
    
• model 적용 상황
  • 고객이 소프트웨어의 목표 설정은 할 수 있지만 기능적 요구사항을 정확히 파악 불가능할 때 효과적
  • 개발자가 알고리즘, UI 등 기술적인 측면에서 활신이 없는 경우
  • 실험적으로 실현 가능성을 예측해보고 싶을 경우
    
    
    

Spiral

• 실행 단계
  1. 계획 수립(planning) : 목표와 기능 선택 및 제약 조건 결정
  2. 평가 및 추정(estimation) : 이전 단계의 평가 및 비용 추정
  3. 일정 조정(scheduling)
  4. 위험 분석(risk analysis) : 기능 선택의 우선순위 및 위험 요소 분석
     
     
• 특징
  • prototype의 cycle 측면 + waterfall의 통제/체계 측면
  • Anchor Point 마다 1개의 release 도출
  • 하나의 circuit을 진행할 때마다 risk analysis를 진행
    =>빠른 대처 가능
  • 소프트웨어의 기능을 나누어 점진적으로 개발
    
    
• 장점
  • 고객의 지속적 참여
  • 개발 위험 요소의 관리
    
    
• 단점
  • 위험 요소의 분석이 중요 -> 실패시 프로젝트에 불이익이 큼
  • 복잡한 과정 때문에 프로젝트 관리가 어려움
    
    
• model 적용 상황
  • 대규모 소프트웨어 프로젝트에 적합
  • 확장 가능한 소프트웨어 개발에 적합
  • 전문적 개발 팀이 존재할 경우
    
    
    

Unified Process Model

• Unified Process : use-case 주도, 아키텍쳐 중심, 반복적, 점진적 소프트웨어 개발 프로세스 - Unified Modeling Language(UML)과 밀접한 관계가 있음
  
  

UP Model

• UP 단계별 일반적 프레임워크 활동
  1. 인식(inception)
     • 소통 : 기본적 비지니스 요구사항 - 기능을 예비 use-case를 통해 설명
     • 기획 : 자원 식별, 주요 위험 요소 평가, 소프트웨어 증분에 대한 예비 일정
  2. 구체화(elaboration) : 기획 및 모델링
     • 예비 use-case 정제 및 확장
     • 소프트웨어의 5대 관점(use-case model, analysis model, design model, incrementation model, deployment model)을 포함하는 설계의 기준선 작성
     • 계획 수정
  3. 구현(construction)
     • 소프트웨어 증분의 필요 기능 전체를 소스 코드로 구현
     • 각 컴포넌트 별 단위 테스트의 설계 및 수행
     • 통합 수행 : 컴포넌트 조립 및 통합 테스트
     • use-case를 사용하여 인수 테스트 도출 및 수행
       =>완료 후 다음 단계 실행
  4. 전환(transition) : 구현 및 배포
     • 사용자에게 소프트웨어와 관련 문서들을 제공하여 베타 테스트 진행
     • 사용자 피드백 보고서에서 결함 도출 시 필요 변경 수행
  5. 생산(production) : 배포
     • 소프트웨어의 지속적 사용을 모니터링
     • 인프라 등 소프트웨어 운영 환경에 대한 지원
     • 결함 보고 및 변경 요청 제출 및 평가
       
       
• 장점
  • 품질 문서 강조 => documentation이 UML을 통해 만들어짐
  • 요구사항 변경 수용이 용이 => incremental하게 진행되기 때문
    
    
• 단점
  • use-case의 부정확성
  • 까다로운 소프트웨어 증분의 통합
  • 겹치는 단계의 문제 발생 가능성
    
    
• model 적용 상황
  • 전문적 개발 팀이 있을 경우
  • 유지보수 프로젝트에 적합

Reference

• Scott Uk-Jin Lee 소프트웨어공학 강의