소프트웨어 개발단계 : 프로세스 모델

1. 프로세스의 정의

프로세스 : 일이 처리되는 과정이나 공정. 즉, 주어진 일을 해결하기 위한 목적으로 그 순서가 정해져 수행되는 일련의 절차

프로세스의 목적 : 이전에 얻은 노하우를 전달 -> 시행착오 감소 -> 빠르게 적응. 즉, 가이드 역할

프로세스의 3요소

 1. 작업들의 관계를 정의하는 절차와 방법

 2. 도구와 장비

 3. 능력, 교육 및 동기가 부여된 인원

2. 소프트웨어 프로세스의 정의

- 소프트웨어 개발에서의 프로세스

> 작업(task)순서의 잡합 + 제약 조건(일정, 예산, 자원) 을 포함하는 일련의 활동(activity)

> 작업(task) : 소프트웨어를 개발할 때 일을 수행하는 작은 단위

 

- 좁은 의미의 소프트웨어 개발 프로세스

> 소프트웨어 제품을 개발할 때 필요한 절차, 과정, 구조

> 사용자의 요구사항을 소프트웨어 시스ㅌ템으로 구현하기 위한 일련의 활동

 

- 넓은 의미의 소프트웨어 개발 프로세스

> 절차, 구조, 방법, 도구, 참여자까지 모두 포함.

> 소프트웨어 개발 목적을 이루는데 필요한 통합적 수단

 

 

3. 소프트웨어 개발 프로세스

- 단계(빨강은 input, 파랑은 output)

1. 계획(Project Plan, QA Plan, SRS - Sofeware Requirements Specification)

2. 요구분석

3. 설계(Design Document)

4. 구현(Software)

5. 테스트(Test Plan, Test Report)

6. 유지보수

 

 

- 소프트웨어 프로세스 모델의 정의

> 소프트웨어 개발 생명주기

> 소프트웨어를 어덯게 개발할 것인가에 대한 전체적인 흐름을 체계화한 개념

> 개발 계획 수립부터 최종 폐기 때까지의 전 과정을 다룸

> 순차적인 단계로 이루어 짐

 

- 소프트웨어 프로세스 모델의 목적

> 공장에서 제품을 생산하듯이 소프트웨어 개발의 전 과정을 하나의 프로세스로 정의

> 주어진 예산과 잔원으로 개발하고 관리하는 방법을 구체적으로 정의

> 고품질의 소프트웨어 제품 생산을 목적으로 함

 

- 소프트웨어 프로세스 모델의 역할

> 프로젝트에 대한 전체적인 기본 골격을 세워줌

> 일정 계획을 수립할 수 있음

> 개발 비용 산정 뿐 아니라 여러 자원을 산정하고 분배할 수 있음

> 참여자 간에 의사소통의 기준을 정할 수 있음

> 용어의 표준화를 가능하게 할 수 있음

> 개발 진행 상황을 명확히 파악할 수 있음

> 각 단계 별로 생성되는 문서를 포함한 산출물을 활용하여 검토할 수 있음

 

 

4. 소프트웨어 프로세스 모델

- 선형 순차적 모델

 > Linear sequential, Waterfall, Classic life cycle

 

- 폭포수 모델(Waterfall)

- 장점 : 관리의 용이, 체계적인 문서화, 요구사항의 변화가 적은 프로젝트에 적합

- 단점

   > 각 단계는 앞 단계가 완료되어야 다음 단계 수행 가능.

   > 각 단계의 결과물이 완벽한 수준으로 작성되어야 다음 단계에 오류를 넘기지 않음.

   > 사용자가 중간에 가시적인 결과를 볼 수 없다.

 

- V 모델

: 소프트웨어 개발 프로세스로 폭포수 모델의 확장된 형태

-> 산출물 중심(폭포수 모델) vs 각 개발 단계 검증에 초점(V 모델)

: 코딩 단계에서 위쪽으로 꺾여 알파벳 V자 모양으로 진행 

: 개발 생명 주기의 각 단계와 그에 상응하는 소프트웨어 시험 각 단계의 관계를 보여줌.

: 소프트웨어 개발의 각 단계마다 상세한 문서화를 통해 작업을 진행하는 방법을 사용.

: 테스트 설계와 같은 테스트 활동을 코딩 이후가 아닌 프로젝트 시작 시에 함께 시작함.

: 전체적으로 많은 양의 프로젝트 비용과 시간을 감소함.

 

 

 

- 진화적 프로세스 모델

: 선형순차적 모델의 대표가 폭포수 모델이라면, 진화적 프로세스의 대표는 프로토타입 모델

- 프로토타입 모델

: 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품으로, 제작물의 모형

 

- 소프트웨어에서의 프로토 타입

: 정식 절차에 따라 완전한 소프트웨어를 만들기 전에 사용자의 요구를 받아 일단 모형을 만들고 이 모형을 사용자와 의사소통하는 도구로 활용.

 

 

- 개발 절차

요구사항 정의 및 분석 -> 프로토타입 설계 -> 프로토타입 개발-> 사용자의 평가 -> 구현 추가 및 수정

1. 요구사항 정의 및 분석

> 1차로 개략적인 요구 사항 정의 후 2차, … n차를 반복하며 최종 프로토타입 개발

2. 프로토타입 설계

> 완전한 설계 대신, 사용자와 대화할 수 있는 수준의 설계

> 입출력 화면을 통한 사용자 인터페이스 중심 설계

3. 프로토타입 개발

> 완전히 동작하는 완제품을 개발하는 것이 아님.

> 입력 화면을 통한 사용자의 요구 항목 확인.

> 출력 결과를 통해 사용자가 원하는 것인지 확인

4. 사용자에 의한 프로토타입 평가

> (프로토타입 평가 -> 추가 및 수정 요구 -> 프로토타입 개발) 반복

5. 구현

> 최종 프로토타입 개발

 

 

- 장점

: 반복된 요구사항 정의를 통해 사용자 요구가 충분히 반영된 요구 분석 명세서 작성

: 프로토타입이 의사소통 도구로 활용

: 초기 프로토 타입 사용을 통한 새로운 요구사항 발견

: 프로토타입 사용을 통한 완성품의 예측 가능

 

- 단점

: 반복적 개발을 통한 투입 인력 및 비용 산정의 어려움

: 프로토타이핑 과정에 대한 통제 및 관리의 어려움

: 중간 산출물 생성의 어려움

: 불명확한 개발 범위로 인한 개발 종료 및 목표의 불확실성

 

 

 

- 나선형 모델

진화적 프로토타입 + 위험 분석

위험 분석 단계의 위험 요소의 예

: 빈번히 변경되는 요구사항

: 팀원들의 경험 부족

: 결속력이 떨어지는 팀워크

: 프로젝트 관리 부족

 

- 개발 절차

1. 계획 및 요구 분석 단계

2. 위험 분석 단계

3. 개발 단계

4. 사용자 평가 단계

 

- 장점

: 사전 위험 분석을 통한 돌출 위험 요소 감소 

 -> 프로젝트 중단 확률 감소

: 사용자 평가에 의한 개발 방식

 -> 요구가 충분히 반영. 사용자 불만 감소

 

- 단점

: 반복적 개발에 의한 프로젝트 기간 연장 가능.

: 반복 회수 증가에 따른 프로젝트 관리의 어려움.

: 위험 관리의 중요 -> 위험 전문가 필요에 따른 부담

 

 

- 단계적 개발 모델

릴리즈 구성에 따른 분류

1. 점증적 개발 방법

2. 반복적 개발 방법

> 개발 범위 증가, 품질 증가

 

 

 

 

 

 

- 통합 프로세스 모델

폭포수 모델 문제점 - > 해결 방안 -> 반복적 개발 방법

 

 

 - 통합 프로세스(UP) 모델 

> 기본 개념 전체 생명주기를 지원하는 절차 중심의 프레임워크

: 도입, 구체화, 구축, 전이 단계의 과정 안에서 세부 개발 활동이 반복적으로 이루어짐.

>요구사항에 적합하도록 프로세스의 조정 및 수정 가능

: 각 단계에 종합적으로 수행되는 활동이 있지만 어느 시점에서 종료되기 보다는 지속적인 반복과 개선이 수행됨

 

- 통합 프로세스 모델 특징

> 반복적이고 점진적임.

> 아키텍처의 정의를 중요하게 생각하며 견고한 개념 가능
   - 쓰임새와 물질을 토대로 아키텍처를 먼저 구축 후 구현

> 아키텍처와 객체지향이 중요해짐에 따라 활용도 증가

> actor와 usecase 활용

 

- 통합 프로세스 UP 방법

- 통합 프로세스 UP 모델의 절차

1.  도입 단계(inception phase)

 > 이해관계자가 협동으로 개발을 준비하는 단계

 > 프로젝트의 목표와 실현가능성에 대해 파악

 > 대략적인 비용 평가

 > 중요한 요구사항을 쓰임새, 행위자 수준으로 분석

 > 핵심 요구사항에 대한 프로토타입 구현

2. 구체화 단계(elaboration phase)

 > 대부분의 요구사항과 아키텍처를 정립하는 단계

 > 요구사항의 대부분을 쓰임새로 작성하고 설명

 > 설계 단계에서 실행 가능한 아키텍쳐의 설계

 > 구축 단계에 대한 상세한 프로젝트 계획 수립

 > 구현은 시스템의 중요한 기능에 국한

3. 구축 단계(construction phase)

 > 아키텍처 설계를 토대로 소프트웨어 구현

 > 사용자에게 인도 가능한 시스템 구현

 > 시스템의 모든 컴포넌트 개발, 평가

 > 구현, 평가에 치중

4. 전이 단계(transition phase)

 > 제품의 완성 단계

 > 개발을 완료하고, 품질을 보장하여 사용자에게 인도

 > 사용자 환경에서의 인수 시험, 교육훈련

 > 설계, 구현, 평가에 치중

5. 도입/구체화/구축/전이 단계의 공통 작업

 

- 장점

> 기술적 또는 요구사항 변경 등에 대한 위험요소를 초기에 완화시킬 수 있음 (반복, 점증적 개발 장점)

> 진척 사항을 가시화할 수 있음(UML)

> 발주자의 실제 요구 사항에 근접한 시스템을 만들 수 있음(고품질 소프트웨어 개발 확률 올라감)

> 이전 반복을 통해 얻은 교훈은 다음 반복의 피드백으로 작용함

     -> 반복이 거듭될수록 노하우 및 개발자의 스킬 숙달 

 

 

 

- 애자일 프로세스 모델

- agile : 날렵한, 민첩한

- 즉, 애자일 모델은 고객의 요구에 민첩하게 대응하고, 그때 그때 주어지는 문제를 풀어나가는 방법론

 

- 애자일의 기본 가치

> 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통 중시

> 문서 중심이 아닌, 실행 가능한 소프트웨어 중시

> 계약과 협상 중심이 아닌, 고객과의 협력 중시

> 계획 중심이 아닌, 변화에 대한 민첩한 대응 중시

 

- 애자일의 개발 방법

> 반복적인 개발을 통한 잦은 출시를 목표로 함.

프로토타입 개발 -> 사용자 확인 -> 일부 기능 사용

 

- 애자일과 폭포수 모델의 비교

구분	애자일 모델	폭포수 모델
추가 요구 사항의 수용	추가 요구 사항을 수용할 수 있는 방법의 설계	추가 요구 사항을 반영하기 어려운 구조
릴리스 시점	수시로 릴리스	최종 완성품을 릴리스
시작 상태	시작 단계는 미흡, 점차 완성도 높아짐.	시작 단계에서 완성도 매우 높음
고객과의 의사소통	처음부터 고객 참여 유도. 대화를 통해 개발 진행	사용자와 산출물의 근거 중심. 대화 부족
진행 상황 점검	개발자와 고객은 개발 초기부터 진행 상황 공유	단계별 산출물의 결과로 개발 진척 상황 점검
분석/설계/구현 진행 과정	하나의 단계나 반복 안에 분석/설계//구현 과정이 모두 포함되어 동시 진행	분석/설계/구현 과정이 명확
모듈(컴포넌트) 통합	개발 초기부터 빈번히 통합. 문제점을 빨리 발견하고 수정하는 방식	구현이 완료된 후에 모듈간의 통합 작업 수행

 

 

 

- 애자일 개발 방법론(스크럼)

 

-  스크럼 개발 프로세스

 : 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론
 : 경험적 관리 기법 중 하나

 : 구체적인 프로세스를 명확하게 제시하지 않음

 : 개발 팀(조직)을 운영하는 효율적인 운영 방식(지침)

 

- 스크럼 방식의 진행 과정

 

- 스크럼 방식에서 사용되는 용어

1. 제품 기능 목록(product backlog) 작성

    > 우선순위가 매겨진 사용자의 요구 사항 목록

2. 사용자 스토리(user story)작성 및 스토리 포인트(story point) 산정

    > 사용자 스토리 : 메모지 한 장에 구현할 기능을 사용자 관점에서 사용자 언어로 작성한 사용자 요구 사항

    > 스토리 포인트 : 사용자 스토리를 수행하는데 걸리는 상대적인 개발 기간(시간)

3. 스프린트(sprint)

    > ‘전력 질주’
    > 작업량으로 볼 때 그렇게 많지 않고, 개발 기간도 짧음

    > 작은 단위의 개발 업무를 단기간 내에 전력 질주하여 개발한다는 뜻

    > 예) 계획: 소프트웨어 공학 원고 작성, 총기간(1년), 1장/(10일~40일)  -> 스프린트 =  반복 주기 = 10일~40일

4. 스프린트 구현 목록(sprint backlog)

    > 각각의 스프린트 주기에서 개발할 작업 목록

    > 세부 작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 작성

5. 소멸 차트(burndown chart)

    > 시간이 지남에 따라 소멸되고 남은 것을 표현
    > 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별로 남은 작업량으로 표현

6. 스프린트 계획 회의(sprint planning meeting)

    > 전체적인 스프린트 계획 회의 : 가장 높은 순위의 항목에 관심. 그 배경과 목표에 대해 팀원들과 토의. 제품 책임자의 의도 파악.

    > 세부적인 스프린트 계획 회의 : 우선순위 높은 항목의 구현에 대한 구체적인 작업 계획 세움. 결정된 개발 항목에 대한 스프린트 구현      

                                                     목록 작성. 정해진 작업 수행 소요 시간 추정

 

7. 스프린트 현황판(task board)
    > 개발 팀의 개발 현황(진척도, 남은 작업, 진행 속도)을 나타냄

8. 최종 제품(finished work)

    > 모든 스프린트 주기가 끝나면 제품 기능 목록에서 개발하려고 했던 제품이 완성.

9.  스프린트 검토회의(sprint review)

    > 하나의 스프린트 반복 주기(2~4주)가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토

    > 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인

    > 전체 흐름을 확인하여 비즈니스 가치를 점검

10. 스프린트 회고(sprint retrospective)
    > 스프린트에서 수행한 활동과 개발한 것을 되돌아 봄

    > 개선점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지 등을 검토

    > 문제점을 확인하고 기록하는 정도로만 진행

    > 추정 속도와 실제 속도를 비교해보고, 차이가 크면 그 이유를 분석

    > 프로세스 품질은 측정하지 않음

 

 

- 스크럼 방식의 장점

> 실행 가능한 제품을 통해 사용자와의 충분한 의견 조율 가능

> 일일 회의를 통한 팀원들 간의 신속한 협조와 조율 가능

> 일일 회의 시 직접 자신의 일정 발표를 통한 업무 집중 환경 조성

> 다른 개발 방법론들에 비해 단순하고 실천 지향적

> 팀의 문제를 해결할 수 있는 스크럼 마스터의 능력(역할)

> 프로젝트 진행 현황을 통한 신속하게 목표와 결과 추정 가능, 목표에 맞는 변화 시도 가능

 

- 스크럼 방식의 단점

> 추가 작업 시간 필요 :  반복 주기가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 하기 때문.

> 일일 스크럼 회의를 15분 안에 마쳐야 함 : 길어지는 회의 시간으로 인한 작업의 방해

> 투입 공수 불측정에 따른 효율성 평가 불가 : 투입 공수 불측정으로 인해 얼마나 효율적으로 수행되었는지 모름

> 프로세스 품질 평가 불가 : 프로세스 품질 미평가로 인한 품질 관련 활동이 미약하고 품질의 정도를 알 수 없음

 

 

- XP(Extreme Programming)

> 고객이 원하는 양질의 소프트웨어를 짧은 시간에 구축, 전달

> Agile 기법 : 즉시 변경, 경량화 기법 

     : 고객의 요구사항은 변경된다는 가정

> 4개의 가치, 13개의 실천사항 제시

 

-  특징

> 모바일이나 쇼핑몰처럼 즉각 요구가 반영되어야 하는 분야에 적합

> 신기술 도입, 경험 부족, 이해가 부족한 상황에 사용

> 나선형 모델을 좀 더 극단적으로 사용(위험 분석) - 시험을 강조

> 개발자가 소규모(10명 내외), 같은 공간 사용시 적합.

 

- XP의 4가지 가치

1. 의사소통(Communications)

- 고객, 개발자, 관리자간의 원활한 의사소통

- On-site 고객, Whole-팀, Stand-up 미팅

2. 피드백(Feedback)

- 신속한 개발 -> 고객과 시험 -> 신규 요구 반영

- 지속적으로 시험결과를 통합 -> 도출 결과 반영

3. 단순성(Simplicity)

- 설계의 단순함-> 군더더기 제거, 100% 정상코드 추구

- 문서화 축소

4. 용기(Courage)

- 요구사항 및 기술변경에 대해 대처