소프트웨어 공학 (Software Engineering) 프로세스와 방법론 문양세 강원대학교 IT대학 컴퓨터과학전공

In this chapter … We will cover … 소프트웨어 공학의 접근 방법 바람직한 프로세스의 특징 소프트웨어 개발 프로세스 지원 프로세스 방법론

프로세스 정의 소프트웨어를 개발하는 과정, 즉 작업 순서 프로세스가 없는 개발 어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업으로 구성됨 (웹스터 영어 사전) 운영체제에서의 프로세스? 소프트웨어를 개발하는 과정, 즉 작업 순서 순서제약이 있는 작업의 집합 (작업이 순서 제약에 따라 수행됨) 원하는 결과  높은 품질과 생산성이 목표 프로세스가 없는 개발 Code-and-Fix

Code-and-Fix 문제점 요구나 설계 작업의 중요성을 깨닫지 못함 신중하게 잘 설계하지 않으면 소프트웨어 구조가 나빠짐 프로세스 요구나 설계 작업의 중요성을 깨닫지 못함 즉흥적인 방법으로는 사용자의 높은 요구 수준에 도달하기 어려움 (요구 수준 도달을 위해) 계속 고치는 작업이 필요 신중하게 잘 설계하지 않으면 소프트웨어 구조가 나빠짐 즉흥적인 방법은 설계를 “해도 되고 안 해도 되는” 작업이므로 잘 설계되지 않음 계획이 없어 작업의 목표가 없음 일을 한 후에도 잘한 것인지 못한 것인지 판단할 수가 없음 비용과 일정을 잘 조절할 수가 없음 체계적인 테스트 작업이나 품질 보증 차원의 활동에 대한 인식이 없음 발견되지 않은 결함이 남아 계속 고치게 됨 시스템이 더욱 악화

프로세스와 방법론의 비교 프로세스: 소프트웨어를 개발하는데 필요한 작업을 정의 (what) 방법론: 정의된 작업들을 어떤 순서/어떤 방법으로 진행할지의 방법 (how) 프로세스 방법론 특징 단계적인 작업의 틀을 정의한 것 무엇을 하는가에 중점 결과물이 표현에 대하여 언급 없음 패러다임에 독립적 각 단계가 다른 방법론으로도 실현 가능 프로세스의 구체적인 구현에 이름 어떻게 하는가에 중점 결과물을 어떻게 표현하는지 표시 패러다임에 종속적 각 단계의 절차, 기술, 가이드라인을 제시 사례 폭포수 프로세스 나선형 프로세스 프로토타이핑 프로세스 Unified 프로세스 애자일 프로세스 구조적 분석, 설계 방법론 객체지향 방법론 컴포넌트 애자일 방법론

In this chapter … 2.1 소프트웨어 공학의 접근 방법 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 2.4 지원 프로세스 2.5 방법론

소프트웨어 프로세스 소프트웨어 개발에 대한 기술적, 관리적 이슈를 다루는 작업 여러 가지 다른 타입의 작업이 소프트웨어 개발을 위해 수행됨  이들 작업을 모아서 소프트웨어 프로세스라 칭함 여러 작업이 서로 다른 목적을 가지며, 여러 사람들에 의해 수행됨  소프트웨어 프로세스는 개발 모델(내용)에 따라 여러 컴포넌트 프로세스, 즉, 여러 부프로세스가 존재

프로세스와 프로세스 모델 소프트웨어 프로젝트 프로세스 명세(specification) 프로세스 모델 비용, 일정, 품질의 세 목표의 예상치 달성을 위해, “수행할 작업을 조직화한 프로세스” 를 이용 결국, 비용, 일정, 품질에 대한 목표를 성취하는 것 프로세스 명세(specification) 프로젝트에서 수행하여야 하는 작업과 이들의 수행 순서를 정의 (실제 작업이 수행되는) 실행 프로세스는 다를 수 있음 프로세스 모델 일반적인 프로세스를 기술한 것 (generic process, 예: 폭포수 모형) 작업의 단계와 순서, 각 단계 수행의 제약사항이나 조건 등을 모아 놓은 것 프로세스(혹은 프로세스 명세)는 프로세스 모델의 인스턴스(instance)로 이해 가능

프로세스의 종류 프로젝트의 중심 프로세스 기타 프로세스 개발 프로세스: 실제 수행해야 할 개발과 품질 보증 작업에 해당 관리 프로세스: 비용, 품질, 기타 목표를 맞추기 위한 계획, 제어 작업에 해당 기타 프로세스 형상 관리 프로세스: 변경을 관리하여 제품의 일관성을 유지 프로세스 관리 프로세스: “프로세스”도 변하는 것으로, “프로세스” 자체를 관리하는 프로세스  소프트웨어 프로세스 개선이 목적임

프로세스의 정의 작업 결과와 검증 조건을 명확히 정의하여야 함 작업 방법 진입 조건, 출구 조건 각 단계의 결과를 명확히 정의하고 끝나는 시점에 검증 소프트웨어 작업 결과의 예: 요구 분석서, 설계 문서, 코드 등 작업 방법 특정 단계의 작업을 어떻게 수행하는지 언급이 필요함 진입 조건, 출구 조건 진입 조건: 각 단계의 작업을 시작하기 위해 만족하여야 할 조건 출구 조건: 그 단계의 작업을 종료하기 위하여 결과물이 만족하여야 할 조건

In this chapter … 2.1 소프트웨어 공학의 접근 방법 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 2.4 지원 프로세스 2.5 방법론

바람직한 프로세스의 특징 어떤 프로세스를 사용하는 것이 가장 적합한가? 바람직한 프로세스의 특징 (1) 예측 가능성 정의된 프로세스는 여러 프로젝트에 적용됨 여러 프로젝트에 대해 목표 달성을 위한 바람직한 특징이 필요함 바람직한 프로세스의 특징 (1) 예측 가능성 (2) 테스팅과 유지보수 편의성 (3) 변경 용이성 (4) 결함제거 용이성

(1) 예측 가능성 (Predictability) 프로세스 프로세스가 프로젝트를 완성하기 전에 얼마나 정확히 예측 가능한가? 비용을 얼마나 잘 예측할 수 있는가? 품질을 얼마나 잘 예측할 수 있는가? 예측 가능한 프로세스는 통계적으로 관리가 가능 과거 유사 프로젝트를 수행했을 때, 비용이 얼마나 들었는가? 과거 유사 프로젝트가 어느 단계에서 얼마나 오류가 발생했는가? 통계에 근거한 프로세스 제어 프로세스 없이도 좋은 품질과 낮은 비용의 소프트웨어를 만들 수는 있지만, 프로세스 없이는 한 번의 프로젝트를 완료하였다 해도 다음에 이를 재현할 수는 없다.

(2) 테스팅과 유지보수 편의성 유지보수에 드는 비용은 개발 비용을 초과함 프로세스의 목적은? 코딩은 전체 개발 노력의 1/3에 해당 프로그래머는 20% 정도 시간만을 프로그래밍에 투자 (Boehem) [나머지 시간은? 매뉴얼 작성, 의사소통, 기타 등] 프로세스의 목적은? 설계와 코딩에 드는 노력을 낮추는 것이 아니라, 테스팅과 유지보수에 드는 노력을 낮추어야 한다. 설계, 코딩을 대충하란 이야기? No!!!  테스팅과 유지보수가 쉽도록 설계하고 코딩해야 함

(3) 변경 용이성 완성된 제품도 변경을 요할 수 있다. (환경, 요구사항 변화) 개발 과정에서도 변경을 요할 수 있다. 프로세스 완성된 제품도 변경을 요할 수 있다. (환경, 요구사항 변화) 개발 과정에서도 변경을 요할 수 있다. 고객의 요구가 프로젝트 중간에 바뀔 수 있음 개발자의 판단에 의해 설계 내용이 변경될 수 있음 변경은 항시 일어남  변경을 쉽게 다룰 수 있는 프로세스가 요망됨

(4) 결함제거 용이성 오류는 개발 과정의 全단계에서 발생할 수 있음 오류가 발생된 후 발견이 지연될수록 수정 비용이 높아짐 프로세스 오류는 개발 과정의 全단계에서 발생할 수 있음 요구 분석: 20%, 설계: 30%, 코딩: 50% 오류가 발생된 후 발견이 지연될수록 수정 비용이 높아짐 예를 들어, 요구 분석에 오류가 있다면, 이는 설계 및 코드에도 영향을 줌  오류 탐색과 수정은 소프트웨어 개발 전체 단계에 지속적인 프로세스가 되어야 함

In this chapter … 2.1 소프트웨어 공학의 접근 방법 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 2.4 지원 프로세스 2.5 방법론

소프트웨어 프로세스 모델 프로세스 모델 소프트웨어 생명 주기 개발 전 개발 후 개발 단계 개념화 단계 유아 및 성장기 성년기 일반적인 모델이 될만한 프로세스를 기술한 것 프로세스의 generic 버전에 해당함 소프트웨어 생명 주기 개념화 단계 유아 및 성장기 성년기 장년기 (제품으로서는 유아기) 개발 전 개발 후 개발 단계

건축 프로세스 (요구 분석) 집을 짓기 위해서는 건축설계사가 집주인과 만나 어떤 집을 원하는지 들어본다. (구조 설계) 건축설계사는 집주인의 요구를 반영하여 층별 배치도와 개략적인 조감도를 그린다. (상세 설계) 평면도, 측면도 등 필요한 자세한 설계 도면을 준비한다. (구현(코딩)) 설계가 끝나면 시공단계에 들어가서 실제로 집을 짓는다. (테스트) 집을 지은 후에는 전등이 잘 켜지는지, 난방이 잘되는지 등의 각종 점검을 수행한다. (유지보수) 집이 완성된 후에는 하자에 대한 유지보수를 수행한다.

소프트웨어 프로세스 모델 개발 프로세스: 개발 과정을 체계적으로 정리한 과정 실정에 맞는 개발 팀의 고유한 모델의 정립 필요 소프트웨어 개발에 필요한 작업 요구 분석과 정의 시스템 설계 ( 건축의 구조 설계에 해당) 프로그램 설계 ( 건축의 상세 설계에 해당) 프로그램의 작성(구현 or 코딩) 테스트(단위 테스팅, 통합 테스팅, 시스템 테스팅) 시스템 설치 유지보수

대표적인 소프트웨어 프로세스 모델 폭포수 모델 (Waterfall Model) 프로토타이핑 모델 (Prototyping Model) 진화적/점증적 모델 (Incremental Model) 나선형 모델 (Spiral Model) V 모델 (V Model) Unified 프로세스 애자일 프로세스

폭포수 모델 (Waterfall Model) (1/3) 프로세스

폭포수 모델 (Waterfall Model) (1/3) 프로세스 계 획 요구 분석 설 계 구 현 테스팅 인수/설치

폭포수 모델 (Waterfall Model) (2/3) 프로세스

폭포수 모델 (Waterfall Model) (3/3) 프로세스 1970년대 소개 항공 방위 소프트웨어 개발 경험으로 습득 각 단계가 다음 단계 시작 전에 끝나야 함 순서적 - 각 단계 사이에 중복이나 상호작용이 없음 각 단계의 결과는 다음 단계가 시작 되기 전에 점검 바로 이전 단계로의 피드백만이 가능함 단순하거나 응용 분야를 잘 알고 있는 경우 적합 한 번의 과정, 비전문가가 사용할 시스템 개발에 적합 결과물(deliverable) 정의가 중요

폭포수 모델의 프로세스 및 결과물 요약 P 계획 R 요구 분석 D 설계 문제정의 타당성 분석 비용, 일정예측 DFD 자료사전 소단위명세서 시스템구조설계 프로그램설계 UI 설계 구조설계서 상세설계서 계획서 요구 분석서 I 구현 T 테스팅 A 인수/설치 통합시험 기능시험 성능시험 프로그래밍 단위테스트 통합된 프로그램 설치된 소프트웨어 프로그램 설치 인수 시험 (활동) (결과물)

폭포수 모델 – 계획 (Planning) 프로세스 문제의 실현 가능성을 타진한다. (feasibility study)  영구 기관(엔진)을 만들 수는 없다?, 물로 가는 자동차는? 개발하고자 하는 시스템의 성격을 파악하여 비용과 기간을 예측한다.  예측을 잘못하면 소위 “열심히 하고 욕먹는 결과”를 초래한다. 개발 방법과 각 단계에 필요한 자원을 결정한다.  좋은 도구를 사용할 경우, 인력을 크게 줄일 수도 있다. 열역학 법칙을 깬 세계 최초 영구기관?

폭포수 모델 – 요구 분석 (Requirement Analysis) 프로세스 개발을 의뢰한 사용자(일반인, 운영자, …) 요구나 주어진 문제를 정확히 분석하고 이해하는 과정이다. 발주자와 개발자가 요구 분석 사항에 동의하여야 다음 단계 진행이 가능하다. 소프트웨어가 어떤 품질을 만족해야 하는지 결정한다. 소프트웨어가 어떤 기능을 제공해야 하는지 결정한다. ( 세부적으로 어떻게 구현할 지는 추후 설계 단계에서 생각한다.) 요구분석서는 사용자와 개발자의 의사 소통 수단으로서, 정확하고 간결하고 완벽하며 이해하기 쉽고 일관성을 유지하도록 작성해야 한다.

폭포수 모델 – 설계 (Design) 시스템 구조 설계 프로그램 설계 사용자 인터페이스 설계 프로세스 시스템 구조 설계 소프트웨어 구조를 어떻게 가져갈 것인가? 일반적으로, 소프트웨어 모듈을 정의하고, 각 모듈간의 관계를 정의한다. 프로그램 설계 각 모듈내의 알고리즘을 설계한다. 모듈간의 인터페이스 방법을 설계한다. 사용자 인터페이스 설계 입력 형식(메뉴, 음성입력 등)을 결정하고 설계한다. 출력 형식(화면, 소리 등)을 결정하고 설계한다.

(Inter/eXter Process Communication) 폭포수 모델 – 설계 (시스템 구조 설계 예제) 프로세스 SANTA PDSN/IWF GGSN LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS IXPC (Inter/eXter Process Communication) MS LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS SANTA 메시지 송수신 페이징 처리 과금 처리 기타 연동 단말 정보 처리 정보 관리 및 공유 데이터베이스 메시지 파일 메시지 정보 관리 제어 및 호처리 운용 및 유지보수 운용자 정합 데이터베이스 관리 메시지 상태 관리 통계/장애/상태 관리 Graphical UI 파일(메시지) 관리 호처리 제어 운용/형상/구성 관리 Textual UI

폭포수 모델 – 설계 (사용자 인터페이스 설계 예제) 프로세스 GUI(Graphical User Interface): Java 기반으로 이식성 높고 편리한 환경 제공 TUI(Textual User Interface): 원격지에서 MML을 사용한 운영 기능 제공 명령어 입출력 환경

폭포수 모델 – 구현 (Implementation) 프로세스 미리 정해진 모듈 설계에 따라 프로그래밍, 즉 코딩을 수행한다. 코딩된 각 모듈은 테스트의 기본 단위이다.  모듈 테스트는 테스트 단계가 아닌 구현 단계로 보기도 한다. 코딩 작업 자체도 개발회사 전체적인 표준이 있어야 한다. 헤더 주석, 변수 작명 규칙, 모듈의 최소 및 최대 크기 등 모듈 테스트도 회사 전체의 표준이 있어야 한다.  테스트 계획서, Code Inspection, …

폭포수 모델 – 구현 (모듈 테스트의 예제) 프로세스

폭포수 모델 – 테스팅 (Testing) 프로세스 각 모듈들이 정의된 인터페이스에 따라 잘 동작하는지 통합 시험(integration test)을 수행한다. 여러 모듈을 조금씩 결합하면서 단계적으로 시험하는 방법을 취한다.  테스트: 개발 기관 내부에서 실제 사용해보는 시험이다.   version: 블레이트앤소울을 엔씨소프트 직원들을 대상으로 open한다.  테스트: 선택된 고객을 대상으로 실제 사용해보는 시험이다.   version: 플레이드앤소울을 프로게이머들을 대상으로 open한다.

폭포수 모델 – 인수/설치 (Acceptance/Installation) 프로세스 패키지 소프트웨어인 경우, 사용자가 소프트웨어를 설치할 수 있도록 설치 안내서를 제공한다. 주문형 소프트웨어인 경우, 사용자 앞에서 직접 설치하며, 필요한 경우 인수 시험(acceptance test)을 실시한다. 설치 단계가 끝나면 소프트웨어 생명 주기에 있어서 운용 및 유지보수 단계로 넘어간다.

폭포수 모델의 결과물(Deliverable) 프로세스 단, 프로젝트의 규모 및 성격에 따라서 크게 달라질 수 있다.

폭포수 모델의 장단점 장점 단점 개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다. 프로세스 장점 개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다. 프로세스가 간단하여 일반인도 쉽게 이해할 수 있다. 중간 산출물이 명확하게 지정되어 있다. 단점 처음 단계를 지나치게 강조하면 코딩, 테스트가 지연된다. 각 단계의 전환에 많은 노력을 기울여야 한다. (뒤로 돌아가기 어렵다.) 소용없는 다종의 문서를 생산할 가능성 있음

프로토타이핑 모델 (1/3) 프로토타이핑이란 시스템의 일부 혹은 모델을 만드는 과정이다. 시뮬레이션을 수행하거나, 데모 시스템을 만드는 방법 등이 있다. Rapid Prototyping Model ( 컬러링 예제) 요구 분석 프로토타입 개발/개선 Google phone prototype 프로토타입 평가 구현 인수/설치

공동의 참조 모델 (reference model) 제공 프로토타이핑 모델 (2/3) 프로토타이핑 시스템의 적용 사용자의 요구를 더 정확하게 추출한다. 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작을 통해 요구사항을 명확히 하고 위험을 줄일 수 있다. 프로토타이핑 도구 화면 생성기 비주얼 프로그래밍 4세대 언어 등 공동의 참조 모델 (reference model) 제공 개발 단계에서 유지보수가 이루어짐

프로토타이핑 모델 (3/3) 프로토타이핑의 장점 프로토타이핑의 단점 사용자의 의견 반영이 잘 됨 사용자가 더 관심을 높일 수 있고 개발자는 요구를 더 정확히 도출할 수 있음 프로토타이핑의 단점 오해 (프로토타입을 보고, 전부 다 개발한 것 아니냐고 할 수 있음) 기대심리 유발 (프로토타입이 이 정도이니, 최종 결과물은 …) 관리가 어려움(중간 산출물 정의가 난해)

진화적/점증적 모델 (1/2) 개발 싸이클이 짧은 환경 개발 시스템 개발자 사용자 완성 시스템 릴리스 1 구축 릴리스 2 구축 프로세스 개발 싸이클이 짧은 환경 빠른 시간 안에 시장에 출시하여야 이윤에 직결된다.  빨리 만들어 일단 반응을 보자. 개발 시간을 단축하는 법  시스템을 나누어 릴리스한다. 개발 시스템 개발자 릴리스 1 구축 릴리스 2 구축 릴리스 3 구축 릴리스 1 사용 릴리스 2 사용 릴리스 3 사용 사용자 완성 시스템

진화적/점증적 모델 (2/2) 릴리스 구성 방법 단계적 개발 점증적(incremental) 방법 – 기능별로 릴리스 프로세스 릴리스 구성 방법 점증적(incremental) 방법 – 기능별로 릴리스 반복적(iterative) 방법 – 릴리스할 때마다 기능의 완성도를 높임 단계적 개발 기능이 부족하더라도 초기에(빠른 시점에) 사용 교육이 가능 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음 자주 릴리스하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히 고쳐나갈 수 있음 개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음  이번 Release에서는 성능 짱  이번엔 GUI 짱  … 좋은 점만 있니? 빈번한 업그레이드에 따른 피로도 누적 (예: 안드로이드)

나선형 모델 (1/3) 프로세스

나선형 모델 (2/3) 소프트웨어의 기능을 나누어 점증적으로 개발 프로세스 소프트웨어의 기능을 나누어 점증적으로 개발 실패의 위험을 줄임  위험 분석에 초점을 맞춘 개발 모델 테스트 용이 피드백이 용이 여러 번의 점증적인 릴리즈(incremental releases) 진화 단계 계획 수립(planning): 목표, 기능 선택, 제약 조건의 결정 위험 분석(risk analysis): 기능 선택의 우선순위, 위험요소의 분석 개발(engineering): 선택된 기능의 개발 평가(evaluation): 개발 결과의 평가

나선형 모델 (3/3) 장점 단점 적용 대규모 시스템 개발에 적합 – Risk reduction mechanism 프로세스 장점 대규모 시스템 개발에 적합 – Risk reduction mechanism 반복적인 개발 및 테스트 – 강인성 향상 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능 단점 관리가 중요 (상당히 복잡하고, 긴 과정 …) 위험 분석이 중요 상대적으로 새로운 모델 ( 적용이 쉽지 않음) 적용 재정적 또는 기술적으로 위험 부담이 큰 경우 요구 사항이나 아키텍처 이해가 어려운 경우

V 모델 (1/2) 폭포수 모델에 시스템 검증과 테스트 작업을 강조함  높은 신뢰성이 요구되는 분야에 적용 프로세스 폭포수 모델에 시스템 검증과 테스트 작업을 강조함  높은 신뢰성이 요구되는 분야에 적용 폭포수 모델에서 감춰진 반복과 재작업을 드러내 놓은 모델임 인수/설치 요구분석 검증 요구 분석 시스템 테스팅 인터페이스 검증 시스템 설계 통합 테스팅 모듈 검증 상세 설계 단위 테스팅 구현(코딩)

V 모델 (2/2) 장점: 오류를 줄일 수 있음 단점: 반복이 없어 변경을 다루기가 쉽지 않음 프로세스 장점: 오류를 줄일 수 있음 단점: 반복이 없어 변경을 다루기가 쉽지 않음 적용: 신뢰성이 높이 요구되는 분야

Unified 프로세스 (1/2) 요구 분석, 설계, 구현, 테스팅을 포함한 일련의 작업을 여러 차례 반복함 여러 번의 반복 과정을 도입, 정련, 구축, 전환으로 구분함 예: 반복 #1에서는 요구 분석이 주로 이뤄지며, 설계, 구현, 테스팅 작업은 일부만 있음

Unified 프로세스 (2/2) 반복 과정의 네 단계 (각 단계는 여러 반복으로 구성될 수 있음) 특징 도입(inception): 1-2회 정도 반복되며, 사용 사례 모델, 소프트웨어 구조, 프로젝트 계획을 작성함 – 일부 사용 사례를 적용함 (ATM: 조회/인출 기능) 정련(elaboration): 여러 번 반복되며, 많은 사용 사례를 작성하고, 이를 바탕으로 아키텍처 설계를 수행하고 해당 사례들을 구현함 (ATM: 이체/입금 기능) 구축(construction): 남은 사용 사례를 구현하고 이를 시스템에 통합함 (ATM: 감시 기능) 전환(transformation): 베타 테스팅 등을 거쳐 시스템을 배치함 특징 사용 사례 중심의 프로세스 시스템 개발 초기에 아키텍처와 전체적인 구조를 확정 반복적이고 점증적인 모델

애자일 프로세스 (1/3) 폭포수 프로세스의 단점을 해결하고 만족스런 프로그램 개발에 중점 폭포수 프로세스의 단점: 많은 문서화, 계획 변경의 어려움, 엄격한 단계 등 애자일 프로세스는 팀워크, 사용자와 협력 개발, 변경을 고려한 설계, 짧은 주기로 개발하고 자주 출시 등의 특징을 가짐

애자일 프로세스 (2/3) 애자일 프로세스의 네 가지 가치 절차와 도구보다 개인과의 소통을 중요시 한다. 최근 소프트웨어는 개발자 지식은 물론 개인의 능력과 팀워크가 성공에 필수 요소임 잘 쓴 문서보다는 실행되는 소프트웨어에 더 가치를 둔다. 문서를 잘 준비한다는 것은 그 만큼 코딩과 테스팅에 시간을 적게 할애함 잘 실행되는 소프트웨어가 진정한 요구이며 설계라 여김 계약 절충보다는 고객 협력을 중요하게 여긴다. 계약 이전에 고객과의 절충도 중요하지만, 설계 이후 과정에도 고객이 참여하게 함 서로 의견을 교환하고 상호 이해하는 것이 프로젝트 실패 확률을 줄임 계획을 따라 하는 것 보다 변경에 잘 대응하는 것을 중요하게 여긴다. 과거에는 비용 상승을 이유로 변경을 최소화하거나 막고자 함 변경을 고려한 설계, 반복적인 제품 출시 등으로 변경에 잘 대응함

애자일 프로세스 (3/3) 사용 사례 또는 사용자 스토리나 피처(feature) 단위로 요구 파악 테스트 중심 개발(Test Driven Development)  각 기능은 다음 반복 주기로 넘어가기 전에 100% 구현되고 테스트 됨

모델이 많은 이유 모델의 선택은 프로젝트의 상황과 요구에 좌우됨 모델을 잘 선택하면, 소프트웨어 생산성이 높아짐 프로세스 모델의 선택은 프로젝트의 상황과 요구에 좌우됨 모델을 잘 선택하면, 소프트웨어 생산성이 높아짐 경우에 따라서는 최적의 효과를 내기 위하여 (두세 개) 모델의 융합이 이루어지기도 함

In this chapter … 2.1 소프트웨어 공학의 접근 방법 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 2.4 지원 프로세스 2.5 방법론

지원 프로세스 (기타 프로세스) 프로세스 개발 이외에 다른 성격(관리, 지원 등)의 프로세스가 필요함  지원 프로세스 혹은 우산(umbrella) 프로세스가 필요

프로젝트 관리 프로세스 비용, 품질, 일정 목표를 맞추기 위하여, 프로젝트를 관리하는데 필요한 모든 작업 계획: 비용과 일정 예측, 중간 점검에 대한 결정 모니터링 및 제어: 계획 대비 진행상황 점검, 위험 요소 모니터링 및 제어 ( 개발 프로세스의 모든 단계를 포함하므로 가장 긴 기간 동안 이루어짐) (사후)분석: 결과 분석을 통한 교훈 정리  프로세스 개선

품질 보증 프로세스 (1/3) 목적: 프로젝트의 프로세스와 프로덕트의 품질을 관리하고 향상시킴 종류: 인스펙션 프로세스, 프로세스 관리 프로세스 인스펙션 프로세스 개발 결과에서 결함을 찾거나 방지하기 위한 노력 (코드 인스펙션, 설계 인스펙션 등) 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사하는 과정

품질 보증 프로세스 (2/3) 단계별 인스펙션 프로세스 작업 결과물 인스펙션 주의점 참여자 요구 명세서 요구는 고객의 요구를 만족하는가? 요구는 구현 가능한가? 요구에 생략된 것이나 통일되지 못한 것, 애매모호한 것이 없는가? 고객 설계자 테스트 엔지니어 개발자 설계서 구조 설계가 요구를 구현하는가? 설계가 구현 가능한가? 설계에 생략된 것이나 결함이 없는가? 요구 분석가 설계가 코딩 코드는 설계를 잘 구현하는가? 코드는 완벽하고 정확한가? 결함은 없는가? 시스템 테스트 케이스 테스트 케이스가 요구의 모든 조건을 체크하는가? 테스트 케이스가 실행가능한가? 프로젝트 관리자 프로젝트 관리 계획 계획은 완벽한가? 프로젝트 관리 계획은 구현 가능한가? 생략된 것, 애매한 것은 없는가? SEPG담당자 기타 리더

품질 보증 프로세스 (3/3) 프로세스 관리 프로세스 프로세스 관리: 프로세스 자체를 개선하여 생성된 결과의 품질과 생산성을 향상시킴 (프로젝트 관리: 프로젝트를 수행하여 프로젝트의 목적을 달성) 프로세스 개선을 통해, 프로세스 상태가 변화하고, 이를 통해 새로운 능력이 생김

형상 관리 프로세스 (1/3) 형상 관리 (configuration management) 개발 중에 발생하는 변경을 체계적으로 제어(control)하고 관리하는 작업 개발 과정에서 어떤 자원 하나라도 잃지 않고 문서의 정확한 버전을 원시코드와 함께 제공하려는 활동

형상 관리 프로세스 (2/3) 형상 관리 기능 프로그램의 최신 버전 유지 지정된 버전으로 되돌아 갈 수 있는 기능 무허가 변경이나 삭제를 방지 (권한/접근 제어) 현 시스템에 대한 모든 정보, 문서 등의 정보를 모아 보관

형상 관리 프로세스 (3/3) 프로세스 형상관리 메커니즘 – 프로젝트에서 변경이 발생되었을 때 처리하는 시나리오를 다루는 메커니즘을 제공 형상 관리 대상 파악과 베이스라인 지정 버전 관리 접근 제어 형상관리 아이템의 생명 주기 반환 개발 중 검토 중 형상 관리 개발자 만족 승인

In this chapter … 2.1 소프트웨어 공학의 접근 방법 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 2.4 지원 프로세스 2.5 방법론

방법론 vs 프로세스 프로세스 방법론 일반적으로 개발할 때 수행해야할 작업들을 명시 작업들을 어떻게 진행할지, 어떤 관계가 있는지를 나타내지는 않음 방법론 소프트웨어 프로세스의 각 작업을 어떻게 수행할지를 정의함 방법론은 프로세스의 구현이라 생각할 수 있으며, 프로세스는 하나 이상의 방법론으로 구현될 수 있음 프로세스는 입력 자료와 산출물은 정하나 어떻게 표현되어야 하는지는 규정하지 않는 반면, 방법론은 각 단계와 입력 자료 및 산출물, 이들의 표현 방법까지 명시함

(1) 구조적 방법론 분할 정복(divide-and-conquer) 원리를 적용함 프로세스 분할 정복(divide-and-conquer) 원리를 적용함 복잡한 프로세스를 더 단순한 프로세스로 계속 분할해 나감 자료 흐름도(Data Flow Diagram)를 구조도로 변경하는 과정 자료 흐름도: 실제적 문제를 처리(process)라는 관점으로 모델링한 그래프 구조도: 소프트웨어 모듈을 도출하고 모듈 간의 관계를 간선으로 표현

(2) 객체지향 방법론 (1/2) 객체지향 패러다임 실세계를 객체와 객체간 인터랙션으로 모델링하는 방법론 프로세스 객체지향 패러다임 실세계를 객체와 객체간 인터랙션으로 모델링하는 방법론 자료와 함수를 가까운 곳에 정의하여 객체로 묶어 객체 사이의 메시지를 호출하여 원하는 기능을 담당하게 하는 방법 복잡한 대규모 시스템을 클래스로 모듈화하고 캡슐화 할 수 있는 좋은 방법임

(2) 객체지향 방법론 (2/2) 객체지향 방법론 사례 프로세스 객체지향 방법론 사례 전통적 방법론: OMT(Object Modeling Technique), Booch 방법론, 유스 케이스 접근법 최근 통합 방법론: UML(Unified Modeling Language), UP(Unified Process)

(3) 애자일 방법론 진화적 모델/나선형 모델처럼 점증적인 프로세스를 채택 짧은 반복 주기를 반복하며 제품을 점증적으로 자주 출시함 세 가지 애자일 방법론 익스트림 프로그래밍(eXtreme Programming) 스크럼(Scrum) 기능 중심 개발 (Feature Driven Development)

익스트림 프로그래밍 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하는 경우 프로세스 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하는 경우 시스템을 자주 통합하고 빌드, 필요 시 매일 빌드함 XP 프로세스의 여섯 단계 탐구(exploration): 고객과 함께 스토리 개발, 사용 가능 기술 탐색 (2주일) 계획(planning): 다음 릴리즈를 위한 스토리를 찾고 계획을 세움 (2-3일) 반복(iteration): 구현-테스트(고객) 과정을 반복 (반복주기: 1주-4주) 제품화(productionizing): 시험과 인증을 통해 사용환경에 설치 유지보수(maintenance): 새로운 기술/스토리에 따른 변경 추구 종료(death): 더 이상 스토리 추가가 필요 없는 단계

스크럼 개발팀이 개발을 연습하고 능력을 향상시킬 수 있는 프레임워크 프로세스 개발팀이 개발을 연습하고 능력을 향상시킬 수 있는 프레임워크 럭비의 스크럼을 짜듯이, 소프트웨어 개발자들의 팀 구성, 구성원의 역할, 시간 구성, 결과물, 스크럼 규칙 등으로 구성 위험을 관리할 수 있는 반복적이고 점증적인 접근 방법 요구와 반복과정을 스프린트라 부르며, 이에 대한 계획을 세워 진행함

기능 중심 개발 여섯 단계로 구성: 처음 세 단계는 한 번만, 나중 세 단계는 반복됨 처음 세 단계 나중 세 단계 프로세스 여섯 단계로 구성: 처음 세 단계는 한 번만, 나중 세 단계는 반복됨 처음 세 단계 전체 모델 개발 기능 리스트 구축 기능 단위의 계획 나중 세 단계 기능 단위의 설계 기능 단위의 구축 (구현에 해당) 기능 단위의 설치

In this chapter … 2.1 소프트웨어 공학의 접근 방법 2.2 바람직한 프로세스의 특성 2.3 소프트웨어 개발 프로세스 2.4 지원 프로세스 2.5 방법론