CH02. Software Process

Software process

• Software process: SW system 을 제품화 하기 위한 structured set of activities 
• 특징
  
  • 종류가 많다. universally applicable한 process는 없다. 
  • 네가지의 활동으로 이뤄져있다. (명세화, 설계 및 개발, 검증, 진화)
• process description에 포함되어야할 것들 
  • process = activities + ordering of activities
  • product: 각 프로세스 활동에 대한 결과물
  • roles: 참여하는 사람들의 responsibility
  • pre / post condition 
• Process type
  • Plan-driven process: 프로세스 활동이 planned in advance and progress is measured against this plan.
  • agile process: Planning is incremental, easier to chage the process(고객 요청 반영)
  • 대부분은 양쪽 접근법을 적당히 섞어서 씀. 

Software process models (aka. SW development life cycle)

• Software process model: SW process를 abstract하게 represesntation한 것. 
• particular perspective으로 process를 표현한 것. (활동 순서는 보여주지만 사람들의 역할은 보여주지 않는다.)
• 대규모 시스템은 모든 일반적 프로세스에서 가장 좋은 특징을 일부 조합해서 사용함 
• waterfall model
  • Plan-driven model
  • 각 process phase가 개별적인 단계로 인식된다.
  • waterfall model의 phases
    • Requirements analysis & definiton: 요구사항 얻기, 명세서 작성
    • System and software design: 명세서대로 설계
    • Implementation and unit testing: 설계대로 구현(여러개의 프로그램이나 프로그램단위로 실체화), 명세를 만족하는지 test
    • Integration and system testing: 구현한 개별 프로그램들 통합, 전체 시스템 test, 고객에게 전달 
    • Operation and maintenance: 운영 및 유지보수. 가장 긴 생명주기. 오류수정, 시스템 서비스 향상 
    
  • 특징 
    • 원칙적으로 각 phase의 결과는 approve된 하나이상의 document로 나와야한다.
    • 이전 phase가 완벽하게 끝나기 전까지 다음 phase를 시작할 수 없다. 
    • HW개발에서는 폭포수 모델이 적합하다. 그러나 SW개발 에서는 각 단계가 overlap되고, 서로에게 정보를 제공하는 방식으로 이뤄지기 때문에 적합하지 않은 경우가 많다. 
    • 자유로운 팀 커뮤니케이션이 가능하고, SW 요구사항이 빨리 변경되는 상황에서는 본 모델은 적합하지 않다. 이 경우 반복적 개발(Iterative development)이나 ailge 방법론이 더 적절하다. 
  • 문제점
    • Inflexible. Difficulty of accommodating change. 
  • 적용하기에 적합한 시스템 
    • Embedded system : HW는 inflexible하다.
    • Critical system: 안정성과 보안분석이 필요한 중대한 시스템 (safety and security analysis)
    • Large software system : 수많은 파트너사가 개발한 더 큰 공학적 시스템의 일부에 속하는 대규모 SW system 
• Incremental development (점증적 개발)
  • 특징
    • specification, development가 interleaved. 
    • Most commin approach for SW development
    • Plan-driven, agile모두에서 쓸 수 있다. 일반적으로는 섞어쓴다.
      • Plan-driven에서는 시스템 증가분(Increments)를 미리 찾아서 정의하고 시작한다.
      • Agile에서는 증가분을 미리 찾아두기는 하지만 나중에 발생하는 증가분은 고객의 우선순위에 따라 달라질 수 있다. 
    • Agile에서는 폭포수보다 Incremental이 더 효과적이다.
  • Phases
    • Developing initial implementation (초기버전 제작)
    • Getting feedback from users and others (피드백 받기)
    • Evolving the SW through several version until the required system has been developed (완성될 때 까지 진화)
    • + 매번 이루어지는 증가분을 고객에게 전달할 필요는 없다. (매번 고객의 환경에 맞춰서 배포할 필요는 없다.)
    
  • 장점
    • accomodating changing cost가 reduced. : 변경사항이 발생했을 때 다시 작성해야하는 문서의 양이 적다.
    • 이미 진행된 개발작업에 대해서 customer feedback을 받기 쉽다. 
    • 비록 전체 기능을 제공하지는 못해도 useful SW를 customer에게 rapid delivery가능 (전달, 배포가 빠름)
  • 단점
    • The process is not visible : 시스템이 빨리 개발되어야 한다면 모든 버전을 반영한 문서 작성은 비효율적이다.
    • Added new increments tends to degrade System structure: 새로운 증가분 반영시 시스템 구조 훼손 가능성 있음.
      • 새로운 코드는 어떻게든 코드를 망치게 된다. 따라서 시스템에 새로운 기능이 추가될 수록 어렵고 많은 비용이 든다.
      • 품질 저하, 코드 망가짐을 방지하기 위해 정기적으로 소프트웨어 개선, 재구성하는 Regulary Refectoring 필요
    • 이러한 문제로 인해 복잡하고 긴 생명주기를 가진 시스템에는 본 모델이 적합하지 않다. 
• Integration and configuration(통합과 환경설정) 
  • SW reuse에 초점을 맞춘 프로세스 (Based on software reuse)
  • 특징
    • Standard approach
  • 널리 사용되는 세가지 유형의 Reuse sw 컴포넌트 
    • Stand-alone application system (COTS: Commercial-off-the-shelf)
    • Collection of objects
    • Web services
  • Phases
    • Requirements specification
    • SW discovery, evaluation: 소프트웨어 발견 및 평가. 재사용가능한 SW 컴포넌트 찾고, 사용에 적합한지 평가
    • Requirement refinement: 요구사항 정체. 찾은 재사용 가능한 컴포넌트의 정보를 활용해서 요구사항을 다듬는다. 요구사항 수정, 시스템 명세 다시 정의 등을 한다. 수정이 불가능하면 대안을 찾기 위해 컴포넌트 분석을 다시 재개하기도 한다. 
    • Application System available: 재사용가능한 system 확보, 이걸 설정해서 새로운 system 만드는데 사용
    • Component 수정과 통합: 적합한 COTS이 없으면 개별적으로 재사용 가능한 컴포넌트를 수정해서 새로운 컴포넌트를 만들어서 system에 통합시킬수도 있다. 
    
  • 장점
    • Reduce cost and risks
    • Faster delivery and deployment
  • 단점
    • 시스템이 사용자의 실제 요구를 충족시키지 못할 수 있다. 요구사항 타협이 불가피하다
    • 재사용되는 시스템 요소의 진화에 대한 제어력 상실 

 

Process activities

• Real software process = interleaved sequences
• 활동은 organized differently in different development processes. 
  • waterfall -> in sequence / incremental development -> interleaved
• Specification
  • the process of establishing what services are required and the constraints on the sys's operation and development.
  • Requirement engineering process: 요구사항을 얻어내는 과정. 
    • elicitation and analysis(요구사항 도출, 분석)
    • specificaiton(요구사항 명세화)
    • valication(요구사항 검증): 요구사항의 realism, consistency, completencess검증. 문서상의 오류 발견 
    • 이들은 서로  중첩된 활동이다. 
    
• Design and Implementation
  • converting sys 명세  -> executable sys
  • 대부분의 SW유형에서 설계와 구현은 interleaved
  • SW design
    • 개발하려는 System 유형에 따라 다양하다. (DB를 안쓰는 sys면 뺄수 있다.)
    • Architectural design: identify overall structure
    • Database design
    • Interface design: 컴포넌트 사이의 interface정의. 명세가 정황해야한다. 
    • Compoment selection and design: 재사용할 컴포넌트 찾기. 없으면 설계(구현이 아니라 설계까지만)
    
  • Implementation
    • programming은 individual activity이다. no standard process. 
    • Debugging 은 프로그램의 fault를 찾는것. 
• Validation
  • V&V(verification & validation): 검증 및 확인. 시스템이 주어진 명세에 잘 따르고, 고객의 요구에 맞는가
    • Verification: product를 잘 build하고 있는가. 
    • Validation: 맞는 product를 build하고 있는가. 
  • Testing은 V&V 활동에서 most commonly used  
    • Component testing: 개발자가-> 시스템을 구성하는 컴포넌트를 개별적으로 test
    • System testing: 각 컴포넌트 통합해서 완전한 시스템 구성후에 전체 시스템 test(컴포넌트간의 상호작용, 인터페이스 오류 확인)
    • Customer testing: 실제 운영 전에 사용자가 test
    
    • testing은 다음과 같이 사용된다. 
      • incremetal development: 매번 개발하는 증가분에 대해 해당 부분이 요구에 맞는지 test
      • agile process: before development start, 요구사항을 가지고 test를 development한다.
      • plan-driven process: test driven by a set of test plan
      (테스트 계획이 testing과 개발활동 사이를 어떻게 연결해주는지 보여준다. )
• Evolution
  • SW는 inherently flexible
  • requirement change -> SW must evolve and change
  • Implement와 Evolution활동은 완전히 구분된게 아님. continuum(연속적인)한 과정으로 보는것이 맞음. 
  

Coping with change

• Change -> Rework -> costs of change발생 -> 결론적으로 SW개발 비용 증가 
• Cost of change = rework + implementing new functionality 
• 재작업 비용(Rework cost)를 줄이기 위한 두가지 접근법
  • Change anticipation: 재작업이 많이 생기기 전에 가능한 변경을 미리 예측하는 활동을 수반하는 process.(프로토타이핑)
  • Change tolerance: 시스템에 쉽게 변경을 가할 수 있도록 프로세스 설계. 이 활동은 Incremental development 방식을 수반한다. 제한된 변경을 아직 개발하지 않은 증가분에 포함시켜서 구현하는 것. 
• Coping with changing requirements: 변경을 처리하고 시스템 요구사항을 바꾸기 위한 두가지 방법
  • System prototyping: Initial version을 만드는 것. 시스템의 한 부분을 빠르게 개발. 인도 전에 사용자가 미리 써보고 요구사항 개선할 수 있도록함. 
    • rapid prototyping languages or tools
    • involve leaving out functionality: not well-understood한 부분에 집중, error체킹, recovery는 포함하지 않을 수 있음.  functional한 부분에 집중
    • 개발 후 should be discarded. 생산시스템의 좋은 기반이 아니다. 
    • 프로토타입이 사용되는 
      • requirement engineeing: 시스템 요구사항 도출, 검증을 돕는다. 
      • design processes: SW 해결방안 탐색, UI디자인 탐색 
      • testing process: to run back-to-back tests
    • 장점
      • improved system usability
      • a closer match to user's real needs
      • improved design quality
      • improved maintainability
      • reduced development effort
      
  • Incremental delivery: 점증적 인도.
    • 개발을 마친 증가분을 고객에게 배포. 순서는 고객이 정한 우선순위에 따라. 
    • 일단 시스템 증가분을 정하면 -> 해당 증분에 대한 요구사항을 상세 정의 후 개발. 개발하는 동안에는 요구사항 변경못함 
    • Incremental development vs Incremental delivery
      • incremental development: 각 증분을 개발, 평가 -> 다음 증분 개발 (매 증분이 최종본이 아님)
      • Incremental delivery : 여기서의 증가분 = 실제 시스템의 한 부분. no relearning. 바로 사용자가 사용.
      
    • 장점
      • 시스템 기능을 고객이 더 일찍 사용가능
      • 초기증분은 이후 증분에 대한 요구사항을 도출하는데 도움이 되는 프로토타입역할을 한다. 
      • 초기 증분 -> 가장 중요한 부분. 이걸 가장 많이 테스트 가능. -> 실패 리스크 reduce
    • 단점
      • user like old system and reluctant to use a new one
      • 대부분의 경우 시스템은 서로다른 시스템의 일부 기능을 필요로 하는데, 요구사항이 상세하지 않으면 모든 증분이 피룡로 하는 공동기능 찾기 어려움. 
      • 반복적 프로세스의 본질 = SW와 함께 명세를 개발하는 것 -> 이게 조달문제가 발생할 수 있음. 

Process Improvement

• 산업계 개발 가속화, 비용절감 요구 -> 프로세스 개선을 해서(기존 프로세스 이해+바꾸기) -> 품질향상. 비용단축
• Process improvement approaches 2가지
  • The process maturity approach (프로세스 성숙도 접근법)
    • 프로세스 improving / 프로젝트 management / introducing SE practice 
    • 성숙도가 올라가면 기술적 관리적 실무가 프로세스에 잘 적용됨. 
  • The agile approach: 반복적 개발, 오버헤드 감소에 중점. 기능을 빠르게 구현, 배포하고 고객의 요구사항변경에 대응. 
  •  The process improvement cycle
    • Measurement:  프로세스 속성 measure -> 개선이 효과가 있었는지 평가 
    • Analysis: 현 프로세스 평가 -> 약점, 방해물 찾기
    • Change: 프로세스 변경