[Software Engineering] Software Process

The Software Process

• Software system 을 개발하기 위해 요구되는 structured된 activities의 집합
• 다양한 Software process들이 있지만 모두 밑의 것들을 포함한다.
  • Specification
  • Design and Implementation ( Development)
  • Validation ( Testing)
  • Evolution ( Maintenance)
• Software Process Model
  • 어떠한 관점으로부터의 process의 대표

Plan-driven and Agile processes

• Plan- driven processes
  • 모든 Process activities들은 미리 계획된다.
  • 계획에 따라 진행되는 process ( 계획이 중요하다 )
  • Progress는 이 계획에 비교하여 잘 되는지 측정한다.
  • 가장 전통적인 방법
• Agile processes
  • 민첩한, 신속한 process
    • 변화에 신속하게 대응하는 process
  • 한번에 끝나는 것이 아니라 점점 계획을 나아간다.
  • Planning의 누적
  • 쪼개서 진행하는데 쪼개는 단위를 Increment라고 한다.
  • Increment를 계획 후 다음 increment를 계획하고의 반복
    • 왜? Requirement의 agile하기에
  • System 은 increments 혹은 version의 series로 개발되어진다.
  • Customer의 요구를 반영하여 바꾸는 것이 쉽다.
• 둘 중 하나를 사용하는 것이 아니라 , 둘 동시에 사용한다.
• Software process에는 옳고 그름이 없다. 그래서 ad hoc approach 가 필요하다.
  
• Process의 차이점을 잘 알고 있자.
  (Plan-Driven / Agile)

  ⇒ 모든 단계별로 검증과 문서화를 거침 (plan-driven)
  
  ⇒ 단계별로 검증과 문서화를 최소화하며 리소스를 최소화한다. ⇒ 변화에 상대적으로 유연하게 대처 가능 (agile)⇒(overhead 줄일 수 있다.)

Software process models

• The waterfall model
  • Process가 다단계 폭포처럼 끊긴다.
  • 분리되어 서로가 겹치는 것이 없다.
  • Plan-driven model
• Incremental development
  • Specification , development 와 validation이 interleaved(중간에 서로 끼어질 수 있다, 사이 사이에 끼어들 수 있다. ) 되어 있다.
  • Plan -driven or Agile
• Integration and configuration
  - 기존에 있던 components를 reuse한다.
  - Plan-driven or Agile

  위 두개와 상관없이 Integration은 무조건 필요하다.

The Waterfall Model

• 간단하지만 Critical 한 모델에서 사용
• Sperate된 indentified phases
  • 각 phase는 다른 phase로 넘어가기 전에 무조건 끝내야 한다.

• 장점
  • 모든 문서가 나와야 다음 단계로 넘어감
  • 문서는 각 phase에서 나옴
• 단점
  • 이러한 끊어져 있는 각 단계는 cutomer 의 requirement에 반응하여 변화하기 힘들다.
  • Software의 requirement는 매번 바뀐다.
• 활용하기 적합한 상황
  • Requirements 들이 초기 stage에서 잘 이해될 때
  • 바뀔 가능성이 매우 적을 경우
  • 큰 시스템에서 개발될 경우
    • 굉장히 제한적이지만 가장 기본적인 process model 이다.
  • 개발자가 이해 되었을 때 사용
  • 좀 더 critical 한 system에서 많이 사용

Incremental deveopment

• Increment 단위로 개발하여 붙여서 완성하는 형태
• 기초 Idea
  • 첫 Implementation을 빠르게 하여 유저에게 보내준다.
  • 다시 Refine하여 다음 것으로 넘어간다
  
• Incremental Development의 예
  • Throw-away prototyping
    • 목적
      • Requirement를 더 잘 이해하기 위해 만든다.
    • Prototyping을 버린다는 의미로 주로 UI에서 사용된다.
    • Requirement를 어떻게 만들어가야하나?
      • Prototyping을 하여 요구에 대응
    • Customer의 반대로 버리고 살리고 버리고 살리고의 반복으로 대부분의 prototyping은 버려진다.
    • UI를 생각하면 제일 쉬우며 무엇을 필요로 하는지 prototyping을 통하여 clarify하게 만들어간다.
  • Waterfall은 Requirement가 완전히 이해되었을 때 사용하지만 Incremental development는 이해가 잘 되지 않으며 하나하나 prototyping을 하고 버리는 과정 속에서 단계가 나아간다.
• 장점
  • Incremental 하게 진행 = system의 이해도 증가
  • 불명확한 점들이 구체화 된다.
• 단점
  • Software가 change될 수록 어려워지고 비용이 비싸진다.
  • 임시방편으로 하게 되는데 그렇게 되면 망한 코드 ( poorly structured) 되기 쉬워진다.
  • Porcess visibility 부족
• 활용하기 적합한 상황
  • Small or Medium-size interactive systems
  • 처음에 잘 이해 되지 않는 큰 시스템
    • UI

Integration and Configuration === Reuse

• Reuse-oriented approach
  • 기존에 있던 component나 application을 가지고 와서 reuse하는 것
• Reuse가 Standard approach 이다.
• 장점
  • 개발되는 시간과 비용을 줄일 수 있다.
  • Software 의 delivery ( 시장에 전달 , software를 고객에게 전달, release와 같음) 와 deployment (install program , 배포) 가 빨라진다
• 단점
  • Requirement가 바뀌는 것은 어쩔 수 없다.
  • 딱맞는 component가 있으면 좋지만 없으면 requirement를 고칠지 아니면 처음부터 만들 것인지 결정해야한다.
  • 훼손되는 것이 어쩔 수 없고 조금 바꿔야한다
  • Needs하고는 안맞을 수 있다.
  • Component도 software이므로 version up 이 될텐데 그때마다 바꿔야하며 최악의 경우는 그 회사가 망하면 본인도 끝
  • 자신의 control 하에 있지 못하다

Types of reuseable software

• Stand-alone application systems ⇒ 프레임워크
  • Open source로 나와 있음
  • 특정 환경에서 사용
• Collections of objects ⇒ 라이브러리
  • 가장 흔하며 Library , Package같은 것들을 갖고와서 사용
  • .NET or Java EE
• Web services ⇒ 웹서비스
  • Web standard에 따라서 web에서 api를 call 하여 사용
  • 기존에 있던 시스템들을 reuse

Reuse-oriented software engineering

Process activities

• 기초적인 processSpecification

  Software specification

  • 시스템 운영 및 개발에 대한 제약 조건 및 필요한 서비스를 확립하는 과정

    • 요구사항과 제약조건!

  • Requirement engineering process

    - Requirements elicitation(이끌어냄) and analysis
        - 시스템으로부터 어떤 요구사항이 있나?
    - Requirements specification
        - 위에서 한 일을 정리하여 document로 만든 것
        - 기존에 있던 system 을 분석
    - Requirements validation
        - Requirements가 valid한지 확인
            - Valid하다는 것은 실현가능한지 확인하는 것이며 consistency(일관성) 이 맞아야함

    

    • Design and implementation

      • 자연어를 binary code로 바꾸는 것

        • Requirement specification을 실행 가능한 binary code로 converting하는 process

      • Software Design

        • Specification을 기반으로 software structure을 design하는 것
        • Design activities
          • Architectural design
            • 전체를 보는 Big picture 느낌이며 제일 처음 봐야할 그림
            • 전반적인 structure, subsystem , module, components간의 연관(관계)를 보여준다.
          • Database design
            • System data 구조들을 디자인하며 이러한 것들이 DB에 어떻게 나오게 할 것인지 디자인
          • Interfact design
            • 단계 사이의 interface가 필요하며 call 에 쓰임
            • Subsystem 사이의 통신, 메세지 교환을 위한 디자인
          • Component selection and design
            - Reusable한 components검색
            - 사용 못하게 되면 어떻게 할 것인지 디자인

      • Implementation

        • 이렇게 만든 구조를 executable program으로 해석하는 것
        • System Implementation
          • 다른 사람이 읽기 쉬운 코드 ( 가독성이 좋은 코드) 를 짜야한다.
            • convention을 정해야한다.
            • 좋은 코드를 봐야한다.
          • Design 과 implementation은 대부분의 software system을 위한 interleaved activities이다.
          • Programming은 개인적인 활동 ( 코딩)
            • Standard programming process는 없다.
          • Debugging은 프로그램의 에러를 찾고 고치는 것 ⇒ Locate Error

      • Design과 Implementation은 inter-leaved와 관련 있다.

    

  • Validation (Testing)

    • Verification 과 Validation ( V&V)는 …

      • Verification
        • 스펙에 맞게끔 동작하는지 검증
        • 유저가 원하지 않더라도 기능 좋으면 합격
      • Validation
        • Customer가 원했던 결과인지 검증
        • 원했던 기능이 아니면 validation 실패

    • Checking , review, system testing포함

    • Testing은 가장 많이 쓰이는 V&V의 일종

    • Testing stages

      • Component testing (unit testing)

        • Implementation한 사람이 testing
        • Components는 함수나 객체 또는 이러한 개체들의 일관된 그룹일 수 있음

      • System testing

        • 시스템 전체를 testing
        • 지금 표출하고 새로 고침하는 부분이 중요하다
          • Interface를 testing한다고 생각하면 된다

      • Acceptance testing

        • Customer의 data를 가지고 실제 유저가 사용하듯이 testing한다.
          =Alpha testing( 출시 전 마지막 testing)
          →회사에서 하는 마지막 검증

          

      • Testing phases in a plan-driven software process ( Beta Testing)

        → 출시 후 회사 외부 소비자에게 testing받는 것

        

  • Evolution (Maintenance)

    • Software evolution

      • Software는 본질적으로 flexible하며 바뀔 수 있다.

      • Business 상황들이 바뀌며 requirements가 바뀜에 따라, business를 support하는 business 또한 evolve하며 바뀐다.

        

• Development processes에 따라 달라진다.

  • Waterfall model의 경우 순서대로 진행되어 진다
  • Incremental development의 경우, 왔다갔다(interleaved)하며 진행되어진다.

Process iteration

• 계속해서 바뀌는 requirements에 어떻게 반응할 것인지 알아보는 part

• 큰 software system을 만들 때 process iteration은 어쩔 수 없다.

  • Business changes는 새로우며 바뀐 system requirements를 야기한다.
  • 새로운 기술들은 implementation을 발전시키는 새로운 가능성을 제공한다.
  • Platforms을 바꾸는 것은 application changes를 요구

• Process를 반복하는 이유는 ==requirement가 계속해서 change된다==. 다시 돌아가지 못하면 iteration안되는 model이다.

• Requirement change는 process iteration을 야기한다

  • Iteration이란 반복으로써 그 전단계를 다시 해야한다는 뜻이다.
  • Coding하다가 requirement가 바뀌면 specification으로 돌아가야한다.
  • 큰 software system을 만들 때 process iteration은 어쩔 수 없다.
  • ex) re-analyzing requirements and re-design

• Related approach

  Incremental delivery

  • Incremental 하게 delivery한다는 뜻은 한번에 delivery (software를 고객,user, 시장에 전달)하는 것이 아니라 단계별로 조금씩 delivery하겠다는 말

  • Sigle delivery로 시스템을 delivery 하는 것보다 increment 단위로 쪼개어 기능에 도움이 되게끔 release한다.

    • 각 increment는 요구된 기능을 deliver한다.

  • User requirements에 대해 우선순위 부여

    • 쪼개서 increment로 나누고 제일 먼저 delivery할 것을 정한다.

    • 그 기준은 중요한 것부터 delivery

    • 가장 높은 우선순위의 requirements는 그 전 increments를 포함한다.

      • common services : 여기저기 공통되게 필요한 것들 (우선순위 높음)
      • most critical services: 제일 중요한 기능들

    • Increment가 개발되기 시작하고 requirements가 중지 된다면 ( 밀린다면 ) 그 다음 increment에 반영된다.

      

    • 장점

      • Customer value가 inrement에 각각 전달 됨, 가장 중요한 기능을 먼저 이용 가능하게 넣는다.
      • 먼저 출시한 increment를 사용한 것에 대한 불만이 발생할텐데 다음번 increment의 requirement로 사용될 수 있다.
      • 가장 높은 우선순위의 system services가 가장 많이 testing을 받는다.
        • 첫번째 것을 했으니 두번째 할때 testing을 안하지 않는다. 두개를 합쳤을 때 첫번째 것에서 오류가 날 수 있다
        • = 첫번째 increment의 quality가 높아진다.
        • 완전히 fail하는 increment가 줄어든다.
          • 계속해서 수정하고 testing하기 때문
          • 개선의 여지가 있음

    • 문제점

      • Common service를 찾아야하는데 초반에 찾기 힘들다.

    • 단점보다 장점이 훨씬 많기에 대부분 incremental delivery를 사용한다.

Rational Unified Process ( RUP )

• Iterative software development process framework는 UML 그리고 관련된 process의 작업에서부터 나왔다.

• 일반적으로 3개의 관점에서 설명된다.

  Dynamic Perspective

  • 동적 관점이며 시간에 따라서 변화해 나가는 것을 보여주는 단계

    

  • 특징

    • 각 단계에서 iteration하며 각 phase에서 잘 안된다면 계속해서 iteration을 진행한다
    • 전체도 iteration이 될 수 있는데 이유는 요구사항이 언제든 변할 수 있기 때문
    • Inception은 개시를 뜻하며 project를 시작한다는 뜻이기도 하고 Business case를 만든다
    • Inception이 가장 중요
    • Phase들은 techincal한 문제가 아니라 business에 관한 문제가 크다.

  • Inception

    • Business case를 만든다.
    • Prototype을 만든다.
    • Inception에서 대부분의 과정이 다 일어난다 ( prototype, specification, implementation , testing, …)
    • 이러한 과정을 Inception이라고 부른다.

  • Elaboration = 계획

    • Problem domain에 대한 이해를 발전
    • System을 위한 architectural framewrok를 설립
    • Project plan 개발
    • Project의 key risk 확인 ( Identify key project risks)

  • Construction

    • System design, programming and testing

  • Transition
    - Operating environment에서 시스템을 배포

    Static Perspective (tool)

  • Process activities를 보여준다.

    

  • Prototype의 version 또한 관리하며 tool 도 쓴다.

  • 특정 phase에서 workflow를 사용하는 것이 아니라 필요하면 모두 다 사용한다.

  • 특정 phase에서 필요한 workflow를 선택하여 진행하면 된다.

  • Flexible하게 진행

    Practice Perspective

  • 이렇게 하면 software가 좋아진다라는 방향을 보여준다.

    • Develop software iteratively
      • Software 개발 반복
      • Requirement change에 대해 대비
      • 계속 iteration하여 요구에 대응
    • Manage requirements
      • Requirement를 다 만들어 놓고 histroy를 tracking하여라
      • Requirement 관리를 확실히 하라
    • Use component-based architectures
      • Reuse가능한 architecture를 사용하라
      • 기존에 있던 component를 많이 사용해라
    • VIsually model software
      • Software를 modeling할 때 그림을 그려서 해라 (이해에 도움)
    • Verify software quality
      • Software quality를 확인해라
      • 제대로 된 test해라
    • Control changes to software
      • Software change를 control하라
      • Version 관리를 잘해라
      • Git을 써서 관리해라