[소프트웨어공학] 3. Software Processes

 

🔎 Software Processes

 

 The software process

 

 - 소프트웨어 시스템을 개발하기 위한 체계적인 활동들

 - 많은 소프트웨어 프로세스 존재

 - 프로세스에 반드시 포함되는 활동들

  ① 명세화: 소프트웨어 시스템이 해야할 일을 정의

  ② 설계 및 구현: 시스템 구조를 정의하고 구현

  ③ 검증: 소프트웨어가 고객이 원하는 것과 일치하는지 확인

  ④ 진화: 변화하는 고객의 요구를 만족시키기 위해 진화

 - 소프트웨어 프로세스 모델은 소프트웨어 프로세스를 단순하게 나타낸 것 (소프트웨어 프로세스 모델: 추상화시켜 표현한 것)

 

 💡 소프트웨어 명세화 (specification)

  - 어떤 서비스가 필요한지를 이해하고 정의하며, 시스템 운영과 개발에 대한 제약사항을 찾아내는 과정

 

  💡소프트웨어 설계 및 구현 (design and implementation)

  (1) 소프트웨어 설계: 명세를 실현하는 sw 구조 설계

  (2) 구현: 구조를 실행 가능한 프로그램으로 변환

  ※ 설계와 구현은 밀접한 관련이 있고 중첩될 수 있음

 

 * 설계 과정

 

  - 아키텍처 설계: 시스템의 전체 구조, 주요 구성 요소(하위 시스템 or 모듈), 이들의 관계 및 배포 방법을 식별

  - 인터페이스 설계: 시스템 컴포넌트들 사이의 인터페이스 정의

  - 컴포넌트 설계: 각 시스템 구성 요소의 작동 방식 설계

  - 데이터베이스 설계: 데이터 구조 설계, 어떻게 데이터베이스에서 표현할지

 

💡 소프트웨어 검증(verification & validation)

  - 검증(verification)과 확인(validation)은 시스템이 명세를 잘 따르고 있다는 것과 고객의 요구사항을 만족시키고 있음을 보여주기 위함

  - 확인(checking), 검토(review), 테스팅

 

  * 테스팅 단계 : 컴포넌트 테스트 -> 시스템 테스트 -> 수락 테스트

   - 개발 / 컴포넌트 테스트: 개별 구성요소는 독립적으로 테스트됨. 구성요소는 함수나 객체 혹은 관련된 엔티티 그룹일 수 있음 -> 서브 시스템 모듈

   - 시스템 테스트: 시스템 전체 테스트

   - 수락 테스트: 시스템이 고객의 요구사항 충족하는지 확인하기 위해 고객 데이터로 테스트

 

💡 소프트웨어 진화(evolution)

  - 소프트웨어는 유연하며 변경 가능

  - 비즈니스 환경 변화로 요구사항이 변경됨에 따라, 소프트웨어도 진화하고 변해야함

타원: 프로세스 활동, 사각형: 산출물

 

 

 Software process descriptions

 

- 프로세스를 설명할 때 포함되는 것: 제품, 역할, 사전/사후 조건

 * 제품: 프로세스 활동의 결과물

 * 역할: 프로세스에 참여하는 사람들의 책임

 * 사전/사후 조건: 제품 만들어지는 전과 후에 만족해야하는 조건들

 

 

 Software Process

 

폭포수 모델, 점증적 개발, 재사용 기반 소프트웨어 공학 모델, 애자일

=> 실무에서, 특히 대규모 시스템에서는 모든 일반적 프로세스에서 가장 좋은 특징을 일부 조합해서 사용하여 개발

 

💡 폭포수 모델 (Waterfall model)

  - 소프트웨어 개발 프로세스를 별도의 식별된 단계로 나누어 표현 

  - 지금 제대로 진행되고 있는지 확인하기 쉬움

  - 명세, 설계/구현, 검증, 진화 포함

  - 폭포수 모델에서는 폭포처럼 아래 단계로 내려가면 다시 올라올 수 없음. 즉 이전 단계로 돌아가지 못함

 

 * 폭포수 모델의 문제점

  - 프로젝트를 개별 단계로 유연하지 않게 분할하면 고객 요구사항 변경 요구에 대응이 어려움

   => 요구사항이 이해 잘되고, 설계 과정에서 변경이 제한될 때 적합함. 안정적인 요구사항을 가진 비즈니스 시스템은 거의 없음

  ex) 무기, 항공, 우주 등 산업에서 많이 사용함 (변화보다 안정성을 우시하는)

  - 시스템이 여러 사이트에서 개발되는 대규모 시스템 엔지니어링 프로젝트에 주로 사용됨

   * 여러 사이트에서 개발되는 상황에서는 폭포수 모델의 계획 중심 특성이 작업 조정에 도움

 

💡 점증적 개발 모델 (Incremental development model)

 

  - 명세화, 설계/구현, 검증, 진화 단계 존재

 

* 점증적 개발 모델의 이점

 - 고객 요구사항 변경을 수용하는 비용이 절감

  + 다시 분석, 작성해야하는 문서 양이 폭포수보다 훨씬 적음

 - 이미 진행된 개발 작업에 대한 고객 피드백을 쉽게 얻음

  + 고객이 시연에 대한 의견 줄 수 있고, 얼마나 구현되었는지 확인 가능

 - 고객에게 유용한 소프트웨어를 빨리 전달하고 배포

  + 폭포수보다 고객이 더 빨리 소프트웨어가 제공하는 가치를 경험하고 실제 사용 가능

 

* 점증적 개발 모델의 문제점

 - 프로세스가 가시적이지 않음

  + 관리자가 진척도를 확인하기 위해서는 중간 산출물이 필요함. 하지만 시스템이 빨리 개발되기 위해서는 시스템 모든 버전을 반영한 문서를 작성하는 것은 비효율적. 즉 각 버전마다 문서가 없기 때문에 관리자가 진행 정도 파악 어려움

 -  새로운 증가분이 반영되면서 시스템 구조 훼손시키는 경향이 있음

  + 소프트웨어 개선을 위해 리팩토링 시 시간과 돈을 들이지 않으면, 정기적 변경으로 인해 구조가 손상될 수 있음. 새로운 기능을 추가하는 작업은 하면 할수록 더 어렵고 많은 비용이 들어감.

 

💡 재사용 기반 소프트웨어 공학 모델 (Reuse-oriented software engineering model)

 - 시스템이 기존 구성 요소 또는 COTS 시스템에 통합되는 체계적인 재사용을 기반으로 함

 * COTS: Commercial Off-The-Shelf  사용 기성 소프트웨어. 맞춤 개발 없이 이미 개발된 상태로 판매되는 소프트웨어.

 - 위의 프로세스 단계에서 "컴포넌트 분석", "요구사항 수정", "재사용 가능한 시스템 설계"가 이 모델의 차이점

 

* 재사용 기반 소프트웨어 공학 모델의 이점

 - 개발해야하는 소프트웨어 양 줄임

 - 비용 감소

 - 고객에게 소프트웨어 더 빨리 전달

 

* 재사용 기반 소프트웨어 공학 모델의 문제점

 - 요구사항 타협은 불가피 (위의 과정 중 요구사항 수정?)

 - 타협을 해야하므로 사용자의 진정한 요구사항을 만족시키기 어려울 수 있음

 

💡 애자일 (Agile)

 - 반복적이고 점진적인 개발

  * 반복 주기 -> 스프린트

  * 각 스프린트마다 새로운 기능 개발

 - 신속하게 sw 모듈 개발하고 사용자에게 배포

 - 고객의 요구사항 변화에 빠르게 대응

 - 개발 과정에 지속적인 피드백 반영

 - 팀의 협업 강화

 

애자일이 점진적 방법과 비슷해보여 둘의 차이를 생각해봤는데, 점진적은 우선 대략적으로 완성한 소프트웨어를 고객에게 전달하고, 이것을 받은 고객의 또 다른 요구사항을 기반으로 고쳐가며 여러 버전을 만들어 내는 것이고,
 애자일은 A 기능 구현하고 바로 고객에게 이 기능 확인해봐! 그 다음 B 기능 만들고 확인해봐! 할 수 있는 느낌. 

 

* 애자일 장점

 - 고객 만족도 향상, 빠른 출시 주기, 품질 향상, 리스크 감소

 

* 애자일 문제점

 - 명확한 계획 수립 어려움 -> 문서화 부족(빠른 개발의 공통 단점), 팀 협업 관리 어려움 

 

* 애자일 프레임워크

  애자일을 원칙으로 하는 프레임워크들. 각 프레임워크는 특화된 목적과 반복이 있음

 - 동적 시스템 개발 방법: 애자일 원칙에 기반한 프레임워크. 시간, 자원 고정 후 그 범위 내에서 유연하게 작업 조정

 - 적응형 소프트웨어 개발: 빠르게 변화하는 환경에 맞게 반복적으로 sw 개발

 - 크리스털 패밀리: 프로젝트 규모와 중요도에 따라 개발 방식 다르게 적용

 - 익스트림 프로그래밍: 테스트 주도 개발

 - 스크럼: 스프린트를 통해 소프트웨어 점진적으로 완성. 팀 간 협업과 매일 스프린트 미팅

 - 린 소프트웨어 개발: 낭비 줄이고, 가치 중심

 - 기능 주도 개발: 작고 가능한 기능 단위로 나눠서 개발

 - 애자일 유피(Agile Unified Process): 반복적 개발과 고객과의 긴밀한 협력 

 

 + 린(Lean) 사고방식

   - 낭비 요소 제거하고 사회에 더 많은 혜택을 제공하며 개인이 일을 통한 가치를 얻을 수 있도록 인간 활동을 체계화하는 방법

   - 크게 생각, 작게 행동, 빨리 실패, 빠르게 배우기

 

 

 

🔎 Coping with change

 

변화에 대응하는 방법에 대해 알아보자

 

- 모든 대규모 소프트웨어 프로젝트에서는 변경이 불가피 함

  * 비즈니스 변화로 인한 새롭고 변경된 요구사항

  * 새로운 기술은 설계나 구현 개선에 대한 새로운 접근이 가능해짐

  * 플랫폼 변경에는 애플리케이션 변경 필요

 

- 변경 비용

  * 요구사항 재분석

  * 새로운 기능 구현

 

 

 Reducing the costs of rework

 

다음은 재작업 비용을 낮추는 방법들이다. 

 

(1) 프로토타이핑

(2) 점증적 인도 (점증적 개발 방법과 비슷)

 

 

 Prototype

 

💡 Prototype system

  - 프로토타입은 제품의 아이디어를 시연하고, 디자인 선택 사항들을 시도해볼 수 있는 시스템의 초기 버전

  - 프로토타입 사용

   * 요구공학 프로세스에서, 시스템 요구사항 도출과 검증에 도움을 줌

   * 설계 프로세스에서, 소프트웨어에서 선택 가능한 옵션을 탐색하거나 UI  개발을 위해 사용

 

💡 프로토타입의 장점

 - 사용자의 실제 요구사항에 가까워질 수 있음

  * 프로토타입 시스템을 시스템 일부 주요 기능을 고객에게 보여주기 위해 개발될 수 있음

 - 사용성 향상

 - 디자인 품질 향상

 - 개발 노력 감소

 

💡프로토타입 개발

  - 신속한 프로토타이핑 언어 또는 도구 기반

  - 잘 이해되지 않는 제품 영역에 초점

  - 오류 검사 및 복구는 프로토타입에 포함되지 않을 수 있음

  - 기능 요구사항에 중점 (즉 개발자가 하는 일에 중점)

 

※ 폐기(Throw away) 프로토타입은 생산 시스템의 좋은 기반이 아니므로 개발 후 폐기해야함

 - 비기능 요구사항을 충족하도록 시스템을 조정하는 것은 불가능 할 수도 있음

 - 프로토타입은 일반적으로 문서화되지 않음

 - 프로토타입 구조는 일반적으로 급격한 변경으로 인해 저하됨

 - 프로토타입은 일반적인 조직의 품질 표준을 충족하지 못할 수 있음 

 

 

 Incremental delivery

 

- 시스템을 한 번에 제공하는 대신, 개발과 인도를 증분(incremental)로 나누고, 개발을 마친 증가분 일부를 고객에게 전달

- 사용자 요구 사항에 우선 순위를 정하고 가장 높은 우선 순위 요구 사항이 초기 증분에 포함

- 증분에 대한 개발이 시작되면 추가적으로 요구 사항을 분석할 수 있지만, 현재 증분에 대해서는 요구사항이 동결됨

 

💡 Boehm's spiral model

 - 프로세스를 나선형으로 표시

 - 나선형의 각 루프는 프로세스의 단계를 나타냄

 - 위험(Risks)은 프로세스 전반에 걸쳐 명시적으로 평가되고 해결됨 (리스크에 특화되어 있음)

 

프로세스 단계 - 사분면

 

 [Spiral model sectors]

 - 목표 설정 (objective setting): 단계에 대한 목표 식별

 - 위험 평가 및 감소 (Risk assesment and reduction): 위험을 평가하고, 주요 위험을 줄이기 위한 활동 수행

 - 개발 및 검증 (development and validation): 시스템 개발 모델(일반 개발 모델이 될 수 있음)을 선택/수행

 - 계획 (Planning): 프로젝트를 검토하고 나선형의 다음 단계를 기획

 

 [Spiral model usage]

 - 나선형 모델은 소프트웨어 프로세스의 반복에 대해 생각하도록 돕고, 위험 중심 접근 방법을 도입하는데 영향 미침

 - 그러나 실제로 나선형 모델은 실제 소프트웨어 개발에서는 거의 사용되지 않음