2장 프로세스와 방법론
2.1 프로세스 (소프트웨어 프로세스)
소프트웨어 프로세스가 아닌 것
- 정해진 절차없이 코딩과 수정을 반복하는 형태 (code-and-fix)
(p.62 - 그림 2.1)
소프트웨어 프로세스의 정의
- 소프트웨어 시스템을 구축하기 위하여 수행하는 작업 단계
- 소프트웨어 프로세스의 각 단계는 잘 정의된 작업을 수행
: 결과물 (Work product) : 요구분석서, 설계문서, 코드, 프로토타입 등
: 앞 단계의 결과물이 다음 단계의 입력
- 소프트웨어 프로세스가 필요한 이유?
: 프로젝트 관리자와 팀 구성원들이 어떤 작업을 어떤 순서로 할지
결정하는데 도움을 주기 때문
넓은 의미의 소프트웨어 프로세스 정의
- 개발 프로세스 뿐만 아니라
- 지원 프로세스도 포함
: 프로젝트 관리 프로세스, 형상관리 프로세스, 프로세스 관리 프로세스
용어
- 소프트웨어 프로세스
: 개발 프로세스와 지원 프로세스를 모두 포함
- 소프트웨어 개발 프로세스 (Software development process)
: 계획 단계에서 인도 단계와 유지 보수 단계까지의 전체 소프트웨어 개발 과정
: 소프트웨어 프로젝트 성격에 따라 선택한 개발 전략
: e.g., Waterfall model, Agile model, ...
: 동일한 뜻으로 사용하는 용어들
1) 소프트웨어 개발 모델 (Software development model)
2) 소프트웨어 프로세스 모델 (Software process model)
3) 소프트웨어 개발 생명 주기 (Software development life cycle, SDLC)
- 방법론(Methods and tools)
: 각 단계에서 선택하는 구체적인 방법
: 각 단계의 결과물의 구체적인 표현을 정함 (표2.1)
: 예: 2장 강의 슬라이드 뒷쪽에 Android App 개발 방법 및 도구
2.2 바람직한 프로세스의 특성
- 예측 가능성
: 소프트웨어 개발 비용과 품질을 지난 경험을 사용하여 예측하여
프로젝트를 제어하기
: 예) 현재 프로젝트에서 100줄 당 10개 오류가 발생하였다면
많은 수의 오류일까 보통 정도일까?
동일한 프로세스로 수행했던 이전 프로젝트에서 100줄 당 2개
수준으로 오류가 났었다는 데이터가 있다면 현재 프로젝트에서
많은 수의 오류가 발생한 것으로 판단
(그림 2.5)
: 동일한 프로세스를 따랐을 때 동일한 결과를 생성한다면 통계에
근거하여 프로젝트를 제어할 수 있다.
- 테스팅과 유지보수 편이성
: 소프트웨어 개발 비용 보다 유지보수할 때 80:20 또는 60;40
정도로 비용이 더 많이 든다. (1장)
: 그림 2.6 - 요구분석 : 설계 : 코딩 : 테스팅 비용 비율: 10;10:30:50
: 따라서, 개발 뿐만 아니라 테스팅 및 유지보수에 더 집중해야 함
: 테스팅과 유지보수를 철저히 고려한 프로세스를 설계 또는 선택해야 함
- 변경 용이성
: 개발 중이 소프트웨어 시스템을 사용자나 고객에게 보여주고
요구한 것이 올바른지 추가할 것은 없는지 피드백을 받을 수 있는
프로세스가 바람직
- 결함제거 용이성
: 개발단계 후반부로 갈수록 더 많은 오류가 발생하고, 수정 비용이 많이 든다.
단계별 오류 발생 시점 분포
요구분석 단계 : 20%
설계 단계 : 30%
코딩 단계 : 50%
요구분석 단게에 발생한 오류를 테스팅 단계에 수정하는 경우
결함제거 비용이 100배에 달할 수 있음
(예: 그림 2.8)
: 오류 탐색과 수정은 소프트웨어 개발 전체 단계에서
지속적인 프로세스가 되어야 한다.
2.3 소프트웨어 개발 프로세스
- 소프트웨어 개발 프로세스
: 소프트웨어 개발 생명주기
- 소프트웨어 프로세스 모델
: 소프트웨어 프로젝트의 특성에 따라 선택한 개발 프로세스 전략
[폭포 모델]
- 1950년대 항공방위 소프트웨어 시스템 개발 경험에서 시작하여
1970년대 산업계에서 보편적으로 사용
- 특징
: 코딩하기 전에 충분히 요구사항 분석과 설계할 시간을 갖는다.
: 단순한 작업 단계
=> 예측이 쉽고
=> 중간 산출물(deliverable)을 명확하게 제시
=> 직능 중심의 프로젝트 조직이 가능
: 요구사항이 분명한 프로젝트에 적합
- 단점
: 불필요한 문서 작성에 많은 시간을 소요하여 설계, 코딩, 테스팅을 지연
: 요구변경을 수용하기 어려움
[프로토타이핑 모델]
- 설계 작업 이전에 요구를 동결하는 대신
요구사항을 이해하기 위해 프로토타입을 구축
- 사용자와 개발자의 공동 참조 모델로 의사소통을 도와주는 매개체
- 두 가지 종류의 프로토타입
: 단순한 요구 추출 - 만들고 버림 (Throw-away)
: 제작 가능성 타진 - 개발 단계에서 유지보수가 이루어짐
- 사용자 요구가 불투명할 때 전통적 방법인 폭포 모델을 대치 가능
- 단점:
: 발주자가 프로토타입을 최종 결과라 오해하지 않도록 주의
: 프로토타입 관리 통제의 어려움
(중간 산출물을 만드는 절차가 하나의 단계에 포함되어 있음)
- 예:
Google + 칩셋 회사 : 프로토타입 개발
-> 선행 팀: 해당 칩셋을 선택하여 모바일 폰 프로토타입 개발
-> 개발 팀: 상용 모바일 폰 개발
[진화적 모델]
- 새로운 소프트웨어 시스템을 빠른 시간에 시장에 내놓기 위하여
전체 시스템 중 조금씩 완성하여 반복적으로 출시
- 두 가지 릴리스 구성 방법
: 점증적 방법 (incremental) - 수직적 기능
일부 기능만 완성해서 릴리스, 다음에 빠진 기능을 완성해서 릴리스
: 반복적 방법 (iterative) - 수평적 기능
전체 기능을 최소한 부분적으로라도 처음에 모두 릴리스
[나선형 모델]
- Boehm이 제안한 나선형 모델은 위험 관리를 강조하는 개발 프로세스 모델
- 소프트웨어 시스템을 여러 부분으로 나누어
하나의 나선 주기에서 점차적으로 개발
=> 진화 단계
- 각 진화 단계 (나선 주기)에 실시하는 작업 내용
: 계획 수립
: 위험 분석 및 개발 전략 선택
: 개발
: 평가
[V 모델]
- Perry가 제안
- 폭포 모델에서 시스템 검증과 테스트 작업을 강조
: Unit testing (개별 모듈 테스팅, verification)
: Integration testing (모듈들간 인터페이스 테스팅, verification)
: System te sting (개발자가 주도, 요구사항에 부합한지 validation)
: Acceptance testing (사용자가 주도, 요구사항에 부합한지 validation)
- 신뢰성이 높은 소프트웨어 개발에 활용
: 의료제어 시스템
: 원전 제어 시스템
: 비행기
: 자동차 소프트웨어
cf. MDS 테크놀로지 자동차 소프트웨어 개발 관련 리소스
http://blog.naver.com/mdstec_auto
- Verification vs. Validation (우리말로 번역하면, 검증과 검증?)
: Verification : Did you build the thing right? (Did you meet the specification?)
: Validation : Did you build the right thing? (Is this what the customer wants? That is, is the specification correct?)
[Unified Process]
- Waterfall의 stage들을 여러 Phases로 반복해서 개발하도록 절차를 구성
1) Waterfall-style stages :
Business modeling, Requirements, Analysis & Design, Implementation, Test, Deployment
2) Sprial/Agile-style phases :
Inception, Elaboration, Concstruction, Transition
각 Phase는 여러 iteration으로 나누어 진행 가능
- UML(Unified Modeling Language) 기반 프로세스
: 사용사례 주도(Usecase-driven)
: Architecture-centric
시스템 개발 초기에 아키텍처와 전체적인 구조를 확정하고
시스템 개발의 가이드로 활용
: 여러 반복과정으로 통하여 점증적으로 개발
1) Inception (도입 단계)
간단한 사용사례 모델, 소프트웨어 구조, 프로젝트 계획
2) Elaboration (정련 단계)
대부분의 사용사례를 작성
아키텍처 설계를 UML로 표현
3) Construction (구축 단계)
남은 사용 사례에 대하여 구현하고 시스템에 통합
시스템을 목표 환경에 점증적으로 설치
4) Transition (전환 단계)
시스템을 배치하는 작업
사용자 교육
베타 테스팅을 통한 결함을 수정 및 기능 개선
[Plan-and-document 모델]
- 지금까지 논의한 모든 모델들을 통틀어 plan-and-document 모델이라 부름
- 기본적인 개발 행위들이 비슷함. 특히 계획을 수립하고 문서화에 집중하고
진행사항을 계획 대비 비교해서 점검하는 공통 특징을 가지고 있음
[Agile Process]
- 2001년 켄트 백, 워드 커닝햄, 알리스테어 콕번, 마틴 파울러 등이 모여
폭포수 모델로 대표되는 고전적 개발 방식으로부터의 독립을 선언하듯 소위
애자일 선언(www.agilemanifesto.org)을 발표
- 4가지 원리
: 절차와 도구보다 프로젝트 팀 구성원의 능력과 팀워크를 중요시
: 문서보다 잘 실행되는 소프트웨어를 진정한 요구이며 설계로 간주
: 고객과의 협력 또는 고객의 참여를 통한 요구사항 분석 및 피드백을 중요시
: 변화에 잘 대응하는 것을 중요시 (vs. 초기 계획을 따른 것)
- 애자일 프로세스
: 변화에 잘 대응하기 위하여 짧게는 1~4주 길어도 2~3개월의 주기를 갖는
여러 이터레이션으로 소프트웨어 개발 프로세스를 나누어 산출물을 개발
: 각 이터레이션에 고객의 피드백을 반영하여 변화에 빠르게 대응
- 스크럼, 익스트림 프로그래밍 (XP)
[스크럼]
- 스크럼이란 S/W 개발 팀 관리 방법으로 큰 목표를 일정 기간 내에 완료될 수 있는 단위로 분리해 개발 진행 매 단위 기간 후에 데모 진행, 매일 매일 서로의 진행 사항 공유 하는 등의 특징을 지닌다.
- 참고 문헌
* Scrum and XP from the Trenches: How we do Scrum (Henrik Kniberg, 2nd Ed., 2015)
PDF 책 다운로드 (https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2)
* 번역서 : 스크럼과 XP, 인사이트 출판사
- 스크럼 용어
* 제품 백로그 : 우선순위가 매겨진 요구 사항의 목록. 고객이 원하는 것을 고객의 용어로 설명한 것. 요구 사항을 스토리나 기능으로 부르기도 함.
* 스크럼 : 최소 규모의 한 팀
* 스프린트 : 최소 규모의 S/W 개발 cycle
* 스프린트 백로그 : 작업 현황판. 할 일, 진행 중, 완료, 스프린트 목표, 소멸 차트, 계획에 없던 항목, 다음 항목을 기재한 현황판.
* 일일 스크럼 : 스크럼 전체 팀원들이 매일 한 일과 할 일을 서로 알 수 있도록 공유
* 스프린트 데모 : 스프린트는 항상 데모를 수반.
* 스프린트 회고 : 코드 리뷰
* 스프린트들 사이의 휴식 시간 : lab day (개발자들이 하고 싶은 일을 하도록 허가해주는 날)
- 스크럼 vs. XP (eXtreme Programming)
* 스크럼은 관리 및 조직적 실천법에 집중하는 반면, XP는 실제 프로그래밍 실천법에 집중.
* 짝 프로그래밍 (Pair programming)
* 테스트 주도 개발 (TDD)
: 먼저 자동화된 테스트를 작성하고 그 테스트를 통과할 만큼의 코드를 작성한 다음 주로 가독성을 높이고 중복을 제거하기 위해 코드를 리팩터링
* 지속적 통합 (CI, Continuous Integration)
: 개발자가 소스 저장소에 코드를 올릴 때(commit) 마다 빌드하고 테스트해서 문제가 없는지 검사.
2.4 지원 프로세스
- 프로세스 관리 프로세스
: 소프트웨어 프로세스는 정적인 요소가 아니고, 작업 결과가 높은 품질과
저비용을 유지하도록 지속적으로 변경된다.
- 프로젝트 관리 vs. 프로세스 관리
: 프로세스 관리의 하나의 인스턴스로써 프로젝트 관리
- 관리 프로세스
: 계획, 모니터링과 제어, 결과 분석
: 전 개발 프로세스에 걸처 관리 프로세스를 연관시켜 적용
(교재 그림 2.19)
- 형상 관리 프로세스
: 시스템을 구성하는 아이템을 식별하고 정의하며
이들의 변경을 생명주기 동안 관리하고
아이템의 현재 상황과 변경 요청을 기록 보고하며
아이템의 완벽성과 정확성을 검증하는 작업
예) 소스 코드, 목적 코드, 빌드 스크립트, 관련 문서 등
: 버전에 대한 정확한 원시코드와 빌드 방법을 제공하려는 활동
* 베이스라인, 참조점
* 접근 제어
: 개발 프로세스의 결과물만 관리하고
결과물을 생성하는 작업에는 직접적인 관여를 하지 않는다.
2.5 방법론
- 소프트웨어 프로세스 모델의 각 단계에서 활용가능한 구체적인
방법이나 도구
예) 설계 단계
* 구조적 설계 방법 (2.5.1절)
* 객체지향 설계 방법 (2.5.2절)
예) 애자일 프로세스의 방법론 (2.5.3절)
* XP
* 스크럼
* 피처 주도 개발 방법
- 안드로이드 앱 개발
