Process Models - Traditional

Hongil Son·2022년 7월 7일
0

Software Engineering

목록 보기
2/2

INDEX

프로세스란

  • 프로세스 : 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 소프트웨어공학 강의
profile
pushing

0개의 댓글