2장. 소프트웨어 프로세스와 생명주기

 

[프로세스]

: 주어진 목적을 위해 수행되는 일련의 절차

: 절차 + 인력 + 기술 / 각 순서와 활동이 명확히 정의됨

 

 

[소프트웨어 개발 프로세스]

: 소프트웨어 개발에 필요한 절차뿐만 아니라, 그와 관련된 인력, 방법, 도구들이 통합되는 수단

: 소프트웨어와 이에 관련된 산출물을 개발, 유지하기 위해 사용하는 활동, 방법, 절차의 잡합

- 기존체제는 요구사항 복잡, 규모증가 => 실패

 

 

[소프트웨어 개발 생명주기(SDLC)]

: 소프트웨어를 어떻게 개발할 것인지에 대한 추상적 표현

- 순차적, 병렬적 단계로 구성

# SDLC 특징

1. 각 단계에 관련된 활동들이 정의되어 있다

2. 다음단계에 활용될 수 있는 산출물이 작성됨

3. 전체 비용 산정, 개발 계획 수립 기본골격 제시

4. 의사소통의 기준과 용어의 표준화

5. 문서화를 통한 충실한 프로젝트 관리

 

 

[소프트웨어 개발 생명주기 모델의 종류]

1. 주먹구구식 개발 모델(Build-Fix Model)

  : 요구사항 분석, 설계 단계 없이, 일단 개발 들어간 후 만족할때까지 수정작업 수행

  - 크기매우 작은 규모의 개발서 사용

  - 정해진 개발 순서가 X => 진행상황파악, 유지보수등의 어려움

 

2. 폭포수 모델(Waterfall Model)

  : 순차적으로 소프트웨어를 개발하는 전형적인 개발 모델

  - 기본적 모델

  - 한 과정이 완벽히 끝나야 다음 단계로 넘어감(이전단계로 돌아가지 않음)

 <단계별활동>

    - 요구사항 분석 : 요구사항 수집, 분석, 문서화    # 산출물 : 요구사항 명세서

    - 설계 : 모든시스템의 구조 결정                     # 산출물 : 설계 명세서

    - 구현 : 설계 명세서를 실제 모습으로 변환        # 산출물 : 소스 코드 및 프로그램

    - 테스트

    - 유지보수

  <장점>

    - 각 단계별로 정형화된 접근 방법 가능

    - 체계적인 문서화로 명확히 프로젝트를 진행

  <단점>

    - 앞 단계 완료될때까지 다음단계들은 대기 상태

    - 실제 작동 되는 시스템을 후반부에나 확인 가능해서 고객의 요구사항 확인에 많은시간 걸림

 

 3. 원형 모델(Prototyping Model)

   : 점진적으로 시스템을 개발해 나가는 접근 방법

   - 폭포수 모델의 단점을 보완

   - 고객 요구사항을 초기에 완전히 파악하기 어려울떄 사용

   - 원형(prototype)을 만들어 고객과 사용자가 함께 평가후 개발될 소프트웨어의 요구사항을 정제해 보다 완전한 요구사항 명세서를 완성

   = (목적)원형을 가능한 빨리 개발해 고객과 검증

  <단계별활동>

    - 요구사항 정의 : 제품의 윤곽을 잡음

    - 원형 설계 : 빠른 설계, 사용자 인터베이스에 초점

    - 원형개발 : 설계된 원형을 RAD도구들을 사용해 빠르게 구현

    - 고객 평가

    - 원형 정제 : 어떻게 수정할지 결정, 순환반복

 

  4. 나선형 모델(Spiral Model)         #교재한번 읽기 - 위험분석에 관하여

    : 폭포수 모형과 원형 모형의 장점을 수용, 위험 분석을 추가한 점증적 개발 모델

    - 프로젝트 수행시 발생하는 위험을 관리하고 최소화 하려는 것이 목적

    - 한 사이클에선 폭포수 모델로 진행

    : 초기 요구사항을 기반으로 계획,위험분석,개발을 하고 고객의 피드백을 받아 다시 계획세워서 돌리고 반복.

   <단계별활동>

     - 계획 및 정의 단계 : 요구사항 수집, 프로젝트 위험의 원인을 규명 가능

     - 위험 분석 단계 : 초기 요구 사항 토대로 위험 규명 

     - 개발 단계 : 생명주기 모델 선택, 제품 만드는 단계

     - 고객 평가 단계 : 고객의 피드백

   <장점>

     - 사전에 위험 감소 가능

     - 테스트 비용, 제품 개발 지연등의 문제 해결 가능

   <단점>

     - 개발자가 정확하지 않은 위험 분석을 했을경우 심각한 문제 발생 가능

     - 복잡, 프로젝트 관리 어려움(완성도 파악 어려움)

 

 

[소프트웨어 개발 방법론]

: 소프트웨어 개발 생명주기 내의 각 단계에서의 수행 방법과 활동들을 구체적으로 정의

 

 

[소프트웨어 개발 방법론의 종류]

1. UP(Unified Process)

  : 객체지향 소프트웨어 개발 방법론(요즘은 잘 안씀)

 <특징>

 - 반복적(Iterative)이고, 점진적(Incremental)인 개발 방법

   : 사이클 반복되며 점진적 발전

   : 반복되는 과정 통해 실행가능한 Release가 산출(ex. 1.3.1 -> 1.3.3)

 - 유스케이스(Usecase) 기반(4장에 자세히)

 - 아키텍쳐 중심의 개발을 지향 : 시스템 전체를 표현한 아키텍쳐는 프로젝트 참여자들에게 최종 산출물의 모습을 초기에 인지하게 하고, 공통된 시각을 가지게 함.

 - 위험 관리를 중시 : 위험도 높은것일수록 프로젝트 초기에 처리 방안을 찾아 해결

# UP의 핵심 워크플로우와 페이즈

 - 도입(Inception)     <가중치> 요구사항1, 분석0.5, 설계0.5, 구현0.25, 평가0.25

  : 전체 요구사항 이해 중점 

  : 프로젝트 목표와 실현 가능성, 대략적 비용평가 통해 프로젝트 개발 여부 결정 단계

 

 - 상세(Elaboration)   <가중치> 요구사항1, 분석1, 설계1, 구현0.25, 평가0.25

  : 요구사항 분석 및 아키텍처를 확정, 위험 요소를 해결하는데 중점

  : 아키텍처를 실행 가능한 수준으로 확장, 구축 단계에 대한 계획을 수립

  : 비중을 낮으나, 시스템의 중요 기능에 대한 구현 및 평가는 이루어짐

 

 - 구축(Construction)  <가중치> 요구사항0.25, 분석0.25, 설계0.5, 구현1, 평가1

  : 사용자의 환경에서 실행 가능한 시스템을 구축하고 평가하는데 중점

 

 - 이행(Transition)       <가중치> 요구사항0.25, 분석0.25, 설계0.5, 구현0.5, 평가0.5

  : 릴리즈 완성 단계, 시스템개발완료, 품질 보장햇 사용자에게 인도하는데 중점

 

 <UP의 이점>

   - 위험 요소 초기 완화

   - 진척 사항 가시화

   - 발주자의 실제 요구사항에 근접한 시스템 만들수 있다(여러번의 평가를 통해..)

   - 다음반복의 피드백으로 교훈이 작용해 반복이 거듭될수로 개발

 

 

2. XP(eXtreme Programming) = Agile

: 개발 외 개발방법론이 더 많은 시간 잡아 먹는 불만 발생 

=> 문서화에 집중하기 보단 소프트웨어 개발에 집중, 개인간 상호작용에 집중, 고객의 협력에 집중

 

- 하나의 릴리즈 시작 시에는 해당 릴리즈에서 개발될 스토리가 결정, 해당 릴리즈가 몇번의 반복(계획,구현,통합,테스트)을 거칠지 결정

  : 여러번의 반복통해 릴리즈나옴

 

<특징>

- 요구사항이 변경된다는 사실을 가정. (여러번의 릴리즈,반복을 통해) 고객의 피드백을 수용하기 위해 고객과 개발팀이 함께 상주

- 동료와의 의사소통을 중요시함 : 각자 업무분담 X, 모든 직원이 모든 접근 권한 가짐

- 단순하고 명확한 설계 유지 : 코드먼저, 설계나중 = 큰 그림 그려놓고 내부는 나중에!

- 가장 우선순위가 높은것 먼저 개발

- 초기에 고객에게 시스템을 전달해 피드백 받음

- 변경부분 있으면 절차/담당자 거칠 필요없이 내가 그냥 하면 됨

 

<용어>

- 스토리(Story) : 고객이 직접 작성하는 (추상적) 요구사항.  ex)가입 버튼을 눌렀을때 가입창이 뜨고 그 창에는 이름, 나이를 입력하는 기능이...

- 스토리 추정 : 개발자가 고객이 제시한 스토리가 어느 정도의 난이도, 기간인지 추정하는것

- 릴리즈(Release) : 고객에게 구현된 제품을 배포하는것 ex) ver1.3.1

- 반복(Iteration) : 하나의 릴리즈 위해 반복되는 작업(반복하다가 고객이 ok하면 릴리즈 하는것)

- 드라이버(Drive) : Pair Programming에서 키보드를 치며 코드를 작성하는 사람

- 파트너(Partner) : Pair Programming에서 드라이버를 도와 코드의 구조 및 결함에 대한 조언을 하는사람

* Pair Programming : n명에게 키보드 한개 줘서 프로그래밍(한명이 구현할때, 다른 한명은 지켜봄. 번갈아가며 수행)

 

<역할>

- 개발자 : 스토리 추정, 설계, 구현, 테스트

- 관리자 : 개발자 앞에 높인 개발 이외의 장애물 제거 ex)컴퓨터 업그레이드등

            : 개발 활동 직접관여 X (개발자에게 어느 부분 개발하라 하지 않음. 개발자가 스스로 가져감)

- 고객    : 스토리제출, 테스트 실시, 개발팀과 상주(개발자가 구현하면서 계속 물어봄 = 실시간 피드백)

# 가볍지만 충분한 개발(= XP)위해 지켜야할 가치 및 실천사항

 

<가치>

- 단순성 : 설계의 단순함 실형(코딩스타일 통일, 주석처리)

- 의사소통 : 수평적, 고객과 실시간

- 피드백 : 실시간

- 용기 : 위 세가지 자치 꾸준히 이행되게끔 가져야 할 가치

- 존중 : 프로젝트 참여 모든 사람 인정 존중

 

<실천사항> 

- 계획 게임 : 매 릴리즈와 반복 시작시 구현해야 하는 스토리를 고객과 개발팀이 함꼐 결정

- 짧은 릴리즈 : 짧은 배포주기(고객의 피드백 통해 프로젝트가 의도된 방향에서 벗어나느거 방지)

- 메타포(MetaPhor) : 전체 시스템 대상으로 사용가능한 상징적인 내용을 찾아 개발팀의 쉬운 이해, 단순 설계 가능케 함. 

   ex)쇼핑몰 : 슈퍼에서 진열된 상품들 장바구니 넣어 계산대에서 결제

- 단순 설계 : 현재 구현중인 스토리에 필요한 부분만 설계

- 테스트 우선 개발

- 리팩토링 : 이미 구현된 코드도 개발기간중 언제든 코드 수정가능

- 짝 프로그래밍

- 코드 공동 소유

- 지속적인 통합 : 개발자가 구현한 단위시스템을 지속적으로 전체 시스템에 통합하는것.

- 주당 40시간 작업 : 워라벨

- 고객의 참여

- 코딩 표준 : 공동 개발이기에 규칙

- 전체 팀 : 대부분의 사람들이 같은 공간에서 함꼐 개발하도록 하는것(수평적)

 

3. 마르미 : UP와 특징 유사, 경량화한 한국산 RUP, 이젠 사용 안함.

 

---

[Summary]

1. 프로세스 : 목적수행위한 일련의 절차 / 인력+절차+기술 2. 소프트웨어 프로세스 : 절차, 인력, 방법, 도구 통합 기술 / 산출물 3. 소프트웨어 생명주기란 : 소프트웨어 개발 방법의 추상적 표현 / 순차적, 병렬적 4. 소프트웨어 생명주기 모델의 종류 : 주먹구구 / 폭포수 / 원형 / 나선형 5. 소프트웨어 개발방법론 : 소프트웨어 생명주기 내 각 단계에서의 수행방법과 활동들 구체적으로 정의 6. 소프트웨어 개발방법론의 종류 : UP / XE / 마르미