2. SW Development Process

1) 소프트웨어 개발 프로세스란?

Software Developement Process = Software Developement life cycle(SDLC)

소프트웨어의 계획, 개발, 그 너머까지 다루는 과정이다. 계획된 기간 내에 일정한 퀄리티를 보장하는 소프트웨어를 만드는 것을 목표로한다.

Untitled

직접적으로 개발에 관련된 과정(software developement process)도 있지만, 지원만 해주는 support process(umbrella process)도 존재한다. 모든 과정을 합쳐서 software process라고 한다.

아래에서는 두 종류의 개발 프로세스에 대해서 설명한다.

  • Plan and Documentation model
  • Agile Model

전통적 소프트웨어 개발 과정

  1. 요구사항 분석(Requirment engineering)

    → 이해관계자들이 어떤 것을 원하는지, 무엇이 필요한지 확정한다.

    관련 : Elicitation(추출), Analysis(분석), Specification(명세), Validation(검증), Management(변경 추적 관리)

  2. 설계(Design)

    → 시스템 구성과 프로그램 내부 구조에 대하여 설계한다.

    관련 : Architectural design(아키텍처), Interface design(인터페이스), Data structure & algorithm design(모듈 상세 설계), UI design(사용자 인터페이스), database design(데이터베이스)

  3. 구현(Implementation)

    → 설계를 기반으로 구현한다. 코딩단계.

    관련 : Reduction of complexity (쉽게 이해하고 사용하도록), Anticipation of diversity(계획되지 않은 변경에 대비), Structuring for validation (테스트하기 쉬운 구조), Use of standards (내부: 코딩 표준, 외부: 의료/자동차 규격)

  4. 검증(Verification & Validation)

    → 시스템이 설계대로 올바르게 구현되었는지 확인한다. Verification은 개발자 입장에서 설계대로 구현되었는지 확인하는 것이며, Validation은 고객 입장에서 요청사항대로 구현되었는지 확인하는 것이다. 테스트는 규모에 따라 아래의 3가지로 구분할 수 있다.

    Untitled

  5. 유지보수(Maintenance)

    → 버그리포트를 관리하거나 버전 변경등에 대응한다.

    관련 : Corrective maintenance(오류 수정), perfective maintenance(새 기능 추가), adaptive maintenance(새로운 환경에 이식)

소프트웨어 개발 프로세스 사용의 장점

  • 예측가능성

    → 동일한 절차로 진행된다면, 이전 프로젝트들에서 비용이나 품질에 관한 데이터를 참고할 수 있다.

  • 테스트와 유지보수의 용이성

    → 소프트웨어 개발에 있어서 테스트 비용은 비중이 크다. 여기에 들어가는 비용을 줄일 수 있다.

  • 변화에 대응하기 쉽다

    → 예기치 못한 상황이나 고객의 추가 요청에 대응하기 쉽다. 피드백 과정 덕분이다.

  • 최소 비용 오류 수정

    → 오류는 초기 단계에서 발견해야 수정비용을 줄일 수 있다.

Plan-and-Documentation Model

Untitled

plan and documentation에 속하는 6가지 모델에 대하여 알아보자.

The Waterfall model

Untitled

가장 기본적인 모델. 변형하여 Prototyping model, Evolutionary model로 사용할 수 있다. 5가지 단계로 구성되며, 단계가 끝나면 되돌아 오지 않고 나아가는 One-shot 모델이다. 따라서 코딩 이전에 필요조건 분석과 설계에 충분한 시간을 가지는 것이 중요하다.

장점

  • 구조가 단순하여 문제를 찾기가 쉽다

단점

  • 유연하지 않다. 피할 수 없는 변화에 잘 적응하지 못한다.
  • 각 단계마다 만들어야 하는 문서가 많다.

Rapid Prototyping model

Untitled

기존의 Waterfall model에서 피드백 과정이 추가된 모델이다. 단순히 설계에서 멈추지 않고 프로토타입을 만든 다음, 이를 가지고 고객과 소통한다.

장점

  • Waterfall 모델보다 훨씬 유연하다
  • 프로토타입을 매개로 고객과 원활한 커뮤니케이션이 가능하다

단점

  • 프로토타입은 완제품이 아니다. 고객에게 이를 숙지시켜야한다.
  • 개발 과정의 통제가 어렵다. 언제 프로토타입에서 구현으로 넘어갈 것인가?

The Evolutionary model

Untitled

서비스가 완성되면 빠르게 사용자에게 공급하고, 해당 버전의 요구사항을 반영한 다음 버전을 구축하는 방식이다. 장단점은 프로토타입 모델과 유사하다.

The Spiral model

Untitled

리스크 관리에 중점을 둔 모델이다. 4개의 구역을 회전하는 방식이며, 각 회전마다 프로토타입 제작과 피드백 과정을 거친 후 최종 회전에서 완성 후 출시한다.

장점

  • 리스크 관리에 용이하다.
  • One-shot이 아닌 반복 모델이기에 변화에 유연하다.
  • 사이클마다 프로토타입이 나오기에 개발 주기가 빠르다.

단점

  • 위험 요인 분석에는 전문가가 필요하다.
  • 리스크 분석 비중이 크다보니, 실수하면 매우 위험하다.
  • 다른 모델들 보다 복잡하고 비용이 많이 들어간다.

The V model

Untitled

테스트와 분석 과정이 많기에, 안정성이 요구되는 작업에 적합한 모델이다. 의료기기, 비행기, 원자력과 같은 분야에 사용된다.

장점

  • 규모에 따라 자주 테스팅을 진행하기에 안정성이 높다.

단점

  • 테스팅 비용이 많이 소모된다.

The Unified Process

Untitled

Waterfall 모델에 여러 phase를 추가함으로써, evolutionary model같은 성질을 좀 가지게 된 모델. Use Case, 사용자 관점에서의 동작 기술을 중심으로 작동한다. Rational Unified Process의 약자로 RUP이라고 사용하기도 한다.

가로축은 시간, 세로축은 waterfall의 단계라고 할 수 있다. waterfall이 한번 돌리면 끝인 one-shot이라면, RUP은 여러번 반복하는 과정을 거친다. 그림을 보면, Inception에서 1번, Elaboration에서 2번, Construction에서 4번, Transition에서 2번 반복하는 모습이다. 반복 횟수는 정형화 되어있지 않다.

수직으로는 waterfall, 수평으로는 evolutionary model이라고 생각하면 편하다.

참고로 저 색깔들은 해당 과정에서의 업무량이다. Inception에서, 조금씩이지만 구현과 테스트마저 포함된 것을 볼 수 있다.

Agile Model

기존 plan and documentation model의 단점인 불필요한 계획과 문서를 생산에 반대하여 등장한 모델이다. 아래의 선언문에 중요 가치가 나와있다.

Untitled

문서보다는 작동하는 소프트웨어를, 동료나 고객과의 소통을, 계획보다는 변화에 대응하는 것을 중요시한다.

Untitled

개발 과정은 위의 이미지와 같이 작동한다. Iteration이라는 짧은 주기를 반복하는 모습이 spiral model과 유사하지만, 그 기간에 차이가 있다. spiral은 1회전에 1년 정도, agile은 1회전에 2달 정도가 소요된다.

method

agile 방식은 어떻게 구현할 수 있을까? 대표적으로는 Scrum과 XP(Extream Programming)이 있다. XP의 3가지 종류가 있다는 것만 알아두고, 다음 글에서 스크럼에 대해 말해보자

  • TDD(Test Driven Development)
  • Pair Programming
  • CI(continuous integration)

적합한 모델 선택을 위한 고려사항

  • 소프트웨어 요구사항을 잘 이해 했는가?
  • 어떤 리스크가 있는지 파악 했는가?
  • 고객과의 소통은 어느정도 할 수 있나?
  • 스케줄 제약사항, 수명은 어떻게 되나?
  • 우리 팀의 전문가 수준은 어느정도인가

참고자료