[소프트웨어공학] 프로세스(Process) & 프로세스 모델(Process Model)

- 프로세스(Process)

• 정의 : 시스템을 구축 및 유지하기 위해 수행되는 방법 및 작업의 set
• 필요성
  • Software Work 를 구성하는 People, Process, Technology 3요소 중에 Cost, Schedule, Quality 에 가장 큰 영향을 줌
  • 고객 및 마켓에게 신뢰성 증대 효과
  • 개발 분야에서의 표준 역할
• 특징
  1. 예측 가능성 (predictability) : 프로세스 결과가 프로젝트 완성 전에 얼마나 정확하게 예측이 가능한지
  2. 유지보수 용이성 (testing) : 테스팅 및 유지보수가 쉬운 소프트웨어 개발 목표
  3. 변경 용이성 : 새로운 요구사항에 대해 쉽게 변경이 가능하도록
  4. 결함 제거 용이성 : 단계별 발생하는 오류 및 결함은 그 단계에서 수정되도록

 

- SPI (Software Process Improvement)

• 정의 : process quality 를 향상시켜 product 의 quality 를 향상시키려는 노력
• Model-based SPI
  • 프로세스 모델을 프레임워크로서 사용하여 SPI 를 이끌어내는 방법
  • 프로세스 모델
    • 정의 : 프로젝트 작업 단계 및 순서, 각 단계 작업 수행의 제약사항이나 조건을 모아놓은 것
    • 역할
      • software process 의 visibility 향상
      • software process 에서의 common language 역할
    • Process model is not a silver bullet
      • 모든 문제를 해결해줄 수 있는 것이 아니라, goal 에 도달할 수 있도록 도와주는 것

 

- CMMI (Capability Maturity Model Integration)

• 정의
  • 업체들의 업무 능력 및 조직의 성숙도를 평가하기 위한 모델
  • 질 높은 product 를 만들어낸 사례들의 Collection 기반으로 만들어짐
  • 이전 단계가 충족되어야 다음 단계로 넘어갈 수 있음
• Mature Case
  • Communication
  • Plan 기반의 업무 진행
  • 프로세스와 일치하는 작업
  • 프로세스 update
  • 체계적인 역할 및 책임
• 5 Capability Levels & 22 Process Areas
  • Level 1 : Initial
    • Process unpredictable with poor control
    • 일부 능력있는 구성원에 대해 dependency 가 강해 adhoc & chaotic process 발생
    • Frequently Cost & Time 초과 발생
    • Process Area
      • None
  • Level 2 : Managed
    
    • Process based on project management
    • Focus on individual project
    • Projects are managed according to their documented plans
    • Project 단위로 얻은 Feedback 을 다음 Project 에 반영
    • Process Area (+이전 Level)
      • Requirements Management (요구사항 관리)
      • Project Planning (프로젝트 계획 수립)
      • Project Monitoring and Control (프로젝트 통제, 이슈 관리)
      • Configuration Management (형상 관리)
      • Process and Product Quality Assurance (품질 보증)
      • Measurement and Analysis (측정 및 분석활동)
      • Supplier Agreement Management (아웃소싱 관리)
  • Level 3 : Defined
    
    • Process based on organization management
    • Organization 단위의 standard process 가 잡혀있는 상태
    • Organization Standard 로부터 tailoring 된 process 를 각 project 에 적용할 수 있는 단계
    • Proactive Level (<-> Reative Level)
    • Process Area (+이전 Level)
      
      • Requirements Development (요구사항 추출/명세)
      • Technical Solution (설계 활동)
      • Product Integration (구현/통합 활동)
      • Verification (시험 활동)
      • Validation (시험 활동)
      • Integrated Project Management (proactive 프로젝트 관리)
      • Risk Management (리스크 관리)
      • Decision Analysis and Resolution (체계적인 의사결정)
      • Organizational Process Definition (조직 차원 프로세스 정의)
      • Organizational Process Focus (조직 차원 프로세스 개선)
      • Organizational Training (조직 차원 교육)
  • Level 4 : Quantitatively Managed (정량적으로 관리가능한 상태)
    
    • Process measured and controlled
    • Quantitative objectives 를 기반으로 품질 및 성능 관리
    • Predictable Level (with statistic)
    • Capable Process
    • Process Area (+이전 Level)
      • Qunatitative Project Management (정량적 프로젝트 관리)
      • Organizational Process Performance (성능 예측 모델 구축)
  • Level 5 : Optimizing 
    • Focus on Process Improvement
    • Process Contorol Limit 을 상향시키는 단계
    • Process Area (+이전 Level)
      • Causal Analysis and Resolution (근본원인 분석을 통한 예방활동)
      • Organizational Performance Management (정량적이고 지속적인 개선)

 

- Stable Process vs Capable Process

• Stable Process
  • Process 결과의 편차를 Control Limit 내로 줄인 상태
• Capable Process
  • Control Limit 을 고객의 요구 Limit 인 Spec Limit 내로 줄인 상태

 

- Process Assessment (프로세스 평가)

• 정의
  • apprasial reference model 및 process assessment model 을 이용해서 Strength & Weekness 를 찾고, 개선을 제안하는 것
• SCAMPI (Standard CMMI Appraisal Method for Process Improvement)
  1. Plan and Prepare for Appraisal
  2. Conduct Appraisal
  3. Report Result
• SPICE
  • ISO 15504 - information technology - Process Assessment
• SP
  • 국내 소프트웨어 프로세스 품질인증 모델
  • 3 Levels & 5 Process Areas
    
    • 1등급
      • Process Area (+이전 Level)
        • None
    • 2등급
      • Process Area (+이전 Level)
        • 프로젝트 관리
        • 개발
        • 지원
    • 3등급
      • Process Area (+이전 Level)
        • 조직관리
        • 프로세스 개선
  • Process Areas
    • 프로젝트 관리 영역
      • 프로젝트 계획
        • 프로젝트 목표 및 범위 결정
        • 프로젝트에 적용할 생명주기와 프로세스 정의
        • Cost & Schedule 산정
        • 프로젝트 관리에 필요한 계획 수립
        • 프로젝트 계획서 작성 및 승인 획득
      • 프로젝트 통제
        • 프로젝트 계획 요소 점검
        • 프로젝트 진척사항 검토
        • 주요 단계별 산출물 검토
        • 문제 분석 및 Feedback 실행
      • 협력업체 관리
        • Scope 설정
        • 협력업체 선정 및 계약
        • 협력업체의 계약 이행 여부 확인
        • 제품 검수
    • 개발 영역
      • 고객 요구사항 관리
        • 요구사항 정의
        • 요구사항 변경 관리
        • 요구사항 & 산출물 Tracing
      • 분석
        • 요구사항 분석 및 검토
        • What 을 정의하는 과정
      • 설계
        • 구조 설계 수행
          • 전체 시스템의 구성요소 및 이들의 상관관계 확인 (시스템 아키텍처)
          • 비기능적 요구사항 반영(성능, 사용성 등 품질 요구사항)
        • 상세 설계 수행
          • 개별 구성 요소의 내부 구조 설계
          • 구현 가능 단위로 분할 및 내부 로직 및 인터페이스 설계
        • 테스트 계획 수립
      • 구현
        • 단위 구현
        • 단위 테스트 수행
        • 소프트웨어 통합
      • 테스트
        • 통합 테스트 수행
          • 테스트 완료된 단위들을 DEV 환경에서 통합하는 과정의 테스트
          • 개발자 관점
          • 기능적 요소에 초점
        • 시스템 테스트 수행
          • 100% 통합이 완료된 상태에서 STG 및 PRD 환경에서 테스트
          • 사용자 관점
          • 기능적 요소 + 비기능적 요소(품질 등)에 초점
        • 인수 지원
    •  지원 영역
      • 품질 보증
        • Process & Product 에 대한 적합성 및 완성도 여부 확인
        • 품질 보증 계획 수립
        • 품질 보증 활동 수행
        • 품질 보증 활동 결과 관리
      • 형상 관리
        • 형상 항목 식별 및 형상 관리 계획 수립
          • 형상 항목
            • 소스 코드
            • 실행 파일
            • 데이터 구조 (DB 스키마)
            • 사용자 메뉴얼, 운영 메뉴얼
            • 분석서, 설계서, 테스트케이스 등 개발 산출물
            • 프로젝트 계획서 등 관리 산출물
        • 형상 통제 실시
          1. 변경 및 통제가 필요할 경우, baseline 설정
          2. 영향이 있을 경우, 변경 및 확인/공지
        • 형상 관리 History Management
        • 형상 감사 실시
      • 측정 및 분석
        • 프로젝트 관련 Data(Cost, Time, Quality)를 측정 & 분석하여 목표 달성 정도 관리
        • 측정 및 분석 계획 수립
        • 측정 실시
        • 측정 결과 분석
        • 측정 분석 결과 관리
    • 조직 관리 영역
      • 조직 프로세스 관리
      • 기반 구조 관리
      • 구성원 교육
    • 프로세스 개선 영역
      • 정량적 프로세스 관리
      • 문제 해결
      • 프로세스 개선 관리

 

- Software Life Cycle Model

• Software Life Cycle (SLC)
  • 정의
    • 요구사항 정의부터 분석/설계/개발/배포 및 유지보수까지의 주기
    • Sequence of Activities and Tasks
• Software Life Cycle Model
  • Code-and-Fix Model
  • Waterfall Model
  • Prototyping Model
  • Incremental Model
  • Evolutionary Model
  • Unified Software Development Process
  • V Model
  • Agile Methods

 

• Code-and-Fix Model
  • No plan, design, specification
  • Program is the only product
  • 장점
    • PoC project 에 적합
  • 단점
    • No visibility
    • expensive for maintenanace

 

• 폭포수 모델 (WaterFall Model)
  
  • 프로세스 사이에 결과물이 있어 명확히 구분되며, 이전 단계로 돌아가는 재작업이 없음
  • 크고 복잡한 오래 지속되는 프로젝트에 적합
  • 장점
    • 각 단계가 명확하여 진행 사항 관리 용이
    • 적용 경험이 많고, 성공 사례도 많음
  • 단점
    • 이전 단계로 돌아갈 수 없기 때문에, 각 단계의 문제가 발견되지 않고 다음 단계로 넘어가는 경우 risk 발생
    • requirement 에 대한 test 를 SWLC 후반부에 가능
  • V Model
    • WaterFall 모델을 다른 표현 방법으로, 각 단계는 대응하는 테스트의 baseline 이 됨.

V Model

 

 

• 프로토타입 모델 (Prototyping Model)
  • 요구 사항에 대한 피드백을 받기 위해 프로토타입을 만들어 stake-holder 에게 피드백을 받는 방식
  • stake-holder 는 한번에 완전한 요구를 낼 수 없기 때문에 프로토타입을 통해 요구사항 보완
  • 장점
    • 개발 완료 후 테스트 단계에서나 결함을 찾을 수 있는 Waterfall Model 단점 보완 가능
    • 요구사항을 긴밀하게 반영 가능
  • 단점
    • 개발에 많은 비용이 듬 (Customer의 지속적인 참여)
    • 체계적이지 않은 요구사항이 반영될 가능성 (일정 및 체계성의 문제)
    • unstable 한 prototype 이 final product 까지 이어질 수 있음 (Evolutionary prototype, <--> Throw-away prototype)

 

• Incremental Model
  • 전반적인 requirement Elicitation 후, release 단위(increment)로 잘라서 waterfall model 진행하는 방법
  • 장점
    • stakeholder 에게 빠른 feedback 받을 수 있음
    • 단위 별로 개발해서 배포하기 때문에 priority 및 risk 관리 가능
  • 단점
    • 개발과 유지보수가 함께 이루어지므로, 유지보수 및 기존 release 에 신규 개발 내용 간의 통합 테스트 등의 activity 가 많아짐

 

• Evolutionary Model
  • requirement 의 detail 은 쉽게 정의되지 않고, 바뀔 수 밖에 없기에 이에 대응하는 방법
  • Iteration 을 반복하여 수정해서 version N 을 만들어 완성시키는 과정
  • Types
    • Evolutionary prototype Model
    • 나선형 모델 (Spiral Model)
      • 프로세스를 risk management 측면에서 바라보는 모델
      • 개발 주기를 여러번 거치며 risk 관리
      • 장점
        • risk 관리 및 반복적인 개발 과정으로 인해 품질 높은 개발 가능
      • 단점
        • risk 관리를 제대로 하지 못할 경우, 많은 노력과 비용 소모
        • 모델이 복잡하여 사용하기 어려움

​

 

 

• Unified Software Development Process (USDP)
  • 기존의 SWLC 단계를 Workflow 형태로 만들고, 4 Level Phases 만들어 각 Phase 에 적절한 Workflow를 하는 방법
  • Use-Case 중심의 process
  • 4 Phases
    • Inception (도입)
      • Use-Case Model
      • 프로젝트 계획
    • Elaboration (정련)
      • Use-Case 및 UML 다이어그램 작성
    • Construction (구축)
      • Use-Case 기반으로 구현
      • 시스템 통합
    • Transition (전환)
      • 시스템 Production 배치 작업
      • 시스템 테스트 수행

 

• 애자일 프로세스 (Agile Process)
  • 변화하는 요구사항에 대한 관리 측면에서 바라보는 프로세스
  • Iterative, Incremental, Evolutionary approach
  • 2~6주간의 짧은 주기로 요구사항 정의, 구현, 테스트까지 진행 및 이에 대한 피드백을 다음 주기의 계획에 반영
  • Software based Process, Not Documentation
  • Communication is important (especially face-to-face)
  • Pull system, Not Push system
    • 팀원들이 Backlog 에서 해야할 일을 Pull & Work 하는 모습
  • Methods
    • XP (eXtreme Programming)
    • Scrum
    • Lean Software Development
    • DevOps
  • 장점
    • 불필요한 문서화 최소화
    • 빠른 요구사항 반영 및 피드백에 따른 요구사항의 변동성에 긴밀한 대처 가능 
  • 단점
    • 문서화가 등한시되어 새로 들어온 구성원의 적응 시간이 늘어남
    • 명확한 끝이 정의되어 있지 않으면 프로젝트가 종료되지 않고 계속 늘어남