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

소프트웨어 공학 (Software Engineer-ing)

프로세스

문양세강원대학교 IT 대학 컴퓨터과학전공

Software Engineeringby Yang-Sae MoonPage 2

We will cover …• 소프트웨어 프로세스• 바람직한 프로세스의 특징 • 소프트웨어 개발 프로세스 모델• 지원 프로세스

프로세스In this chapter …


정의• 어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업으로 구성됨

( 웹스터 영어 사전 )• 운영체제에서의 프로세스 ?

소프트웨어를 개발하는 과정 , 즉 작업 순서• 순서제약이 있는 작업의 집합 ( 작업이 순서 제약에 따라 수행됨 )• 원하는 결과 높은 품질과 생산성이 목표

프로세스가 없는 개발• Code-and-Fix

프로세스프로세스


요구나 설계 작업의 중요성을 깨닫지 못함• 즉흥적인 방법으로는 사용자의 높은 요구 수준에 도달하기 어려움

• ( 요구 수준 도달을 위해 ) 계속 고치는 작업이 필요

신중하게 잘 설계하지 않으면 소프트웨어 구조가 나빠짐• 즉흥적인 방법은 설계를 “해도 되고 안 해도 되는” 작업이므로 잘 설계되지 않음

계획이 없어 작업의 목표가 없음• 일을 한 후에도 잘한 것인지 못한 것인지 판단할 수가 없음

• 비용과 일정의 조절을 할 수가 없음

체계적인 테스트 작업이나 품질 보증 차원의 활동에 대한 인식이 없음• 발견되지 않은 결함이 남아 계속 고치게 됨

• 시스템이 더욱 악화

Code-and-Fix 문제점프로세스


In this chapter …

2.1 소프트웨어 프로세스

2.2 바람직한 프로세스의 특성

2.3 소프트웨어 개발 프로세스 모델

2.4 지원 프로세스

프로세스


소프트웨어 개발에 대한 기술적 , 관리적 이슈를 다루는 작업• 여러 가지 다른 타입의 작업이 소프트웨어 개발을 위해 수행됨

이들 작업을 모아서 소프트웨어 프로세스라 칭함

• 여러 작업이 서로 다른 목적을 가지며 , 여러 사람들에 의해 수행됨 소프트웨어 프로세스는 개발 모델 ( 내용 ) 에 따라 여러 컴포넌트 프로세스 , 즉 , 여러 부프로세스가 존재

소프트웨어 프로세스프로세스


소프트웨어 프로젝트• 비용 , 일정 , 품질의 세 목표의 예상치 달성을 위해 , “ 수행할 작업을 조직화한 프로세

스”를 이용

• 결국 , 비용 , 일정 , 품질에 대한 목표를 성취하는 것

프로세스 명세• 프로젝트에서 수행하여야 하는 작업과 이들의 수행 순서를 정의

• ( 실제 작업이 수행되는 ) 실행 프로세스는 다를 수 있음

프로세스 모델• 일반적인 프로세스를 기술한 것 (generic process, 예 : 폭포수 모형 )• 작업의 단계와 순서 , 각 단계 수행의 제약사항이나 조건 등을 모아 놓은 것

• 프로세스는 프로세스 모델의 인스턴스 (instance) 로 이해 가능

프로세스와 프로세스 모델프로세스


프로젝트의 중심 프로세스• 개발 프로세스 : 실제 수행해야 할 개발과 품질 보증 작업에 해당

• 관리 프로세스 : 비용 , 품질 , 기타 목표를 맞추기 위한 계획 , 제어 작업에 해당

기타 프로세스• 형상 관리 프로세스 : 변경을 관리하여 제품의 일관성을 유지

• 프로세스 관리 프로세스 : “ 프로세스”도 변하는 것으로 , “ 프로세스” 자체를 관리하는 프로세스 소프트웨어 프로세스 개선이 목적임

프로세스의 종류프로세스


작업 결과와 검증 조건을 명확히 정의하여야 함• 각 단계의 결과를 명확히 정의하고 끝나는 시점에 검증

• 소프트웨어 작업 결과의 예 : 요구 분석서 , 설계 문서 , 코드 등

작업 방법• 특정 단계의 작업을 어떻게 수행하는지 언급이 필요함

진입 조건 , 출구 조건• 진입 조건 : 각 단계의 작업을 시작하기 위해 만족하여야 할 조건

• 출구 조건 : 그 단계의 작업을 종료하기 위하여 결과물이 만족하여야 할 조건

프로세스의 정의프로세스


In this chapter …





프로세스


어떤 프로세스를 사용하는 것이 가장 적합한가 ?• 정의된 프로세스는 여러 프로젝트에 적용됨

• 여러 프로젝트에 대해 목표 달성을 위한 바람직한 특징이 필요함

바람직한 프로세스의 특징

(1) 예측 가능성

(2) 테스팅과 유지보수 지원

(3) 변경 지원

(4) 결함 제거

바람직한 프로세스의 특징프로세스


프로세스가 프로젝트를 완성하기 전에 얼마나 정확히 예측 가능한가 ?• 비용을 얼마나 잘 예측할 수 있는가 ?• 품질을 얼마나 잘 예측할 수 있는가 ?

예측 가능한 프로세스는 통계적으로 관리가 가능• 과거 유사 프로젝트를 수행했을 때 ,

비용이 얼마나 들었는가 ?• 과거 유사 프로젝트가 어느 단계에서

얼마나 오류가 발생했는가 ?

통계에 근거한 프로세스 제어• 프로세스 없이도 좋은 품질과 낮은 비용의 소프트웨어를 만들 수는 있지만 ,• 프로세스 없이는 한 번의 프로젝트를 완료하였다 해도 다음에 이를 재현할 수는 없다 .

(1) 예측 가능성 (Predictabil-ity) 프로세스


유지보수에 드는 비용은 개발 비용을 초과함• 코딩은 전체 개발 노력의 1/3 에 해당

• 프로그래머는 20% 정도 시간만을 프로그래밍에 투자 (Boehem)[ 나머지 시간은 ? 매뉴얼 작성 , 의사소통 , 기타 등 ]

프로세스의 목적은 ? • 설계와 코딩에 드는 노력을 낮추는

것이 아니라 ,• 테스팅과 유지보수에 드는 노력을

낮추어야 한다 .

설계 , 코딩을 대충하란 이야기 ? No!!! 테스팅과 유지보수가 쉽도록 설계하고 코딩해야 함

(2) 테스팅과 유지보수 지원프로세스


완성된 제품도 변경을 요할 수 있다 . ( 환경 , 요구사항 변화 )개발 과정에서도 변경을 요할 수 있다 .• 고객의 요구가 프로젝트 중간에 바뀔 수 있음

• 개발자의 판단에 의해 설계 내용이 변경될 수 있음

변경은 항시 일어남 변경을 쉽게 다룰 수 있는 프로세스가 요망됨

(3) 변경 지원프로세스


오류는 개발 과정의 全단계에서 발생할 수 있음• 요구 분석 : 20%, 설계 : 30%, 코딩 : 50%

오류가 발생된 후 발견이 지연될수록 수정 비용이 높아짐• 예를 들어 , 요구 분석에 오류가 있다면 , 이는 설계 및 코드에도 영향을 줌

오류 탐색과 수정은 소프트웨어 개발 전체 단계에 지속적인 프로세스가 되어야 함

(4) 결함 제거프로세스


In this chapter …





프로세스


프로세스 모델ㅓㄱ인 • 일반적인 모델이 될만한 프로세스를 기술한 것

• 프로세스의 generic 버전에 해당함

대표• 예를 들어 , 요구 분석에 오류가 있다면 , 이는 설계 및 코드에도 영향을 줌

오류 탐색과 수정은 소프트웨어 개발 전체 단계에 지속적인 프로세스가 되어야 함

프로세스 모델프로세스


소프트웨어 프로세스 모델

프로세스 모델• 일반적인 모델이 될만한 프로세스를 기술한 것

• 프로세스의 generic 버전에 해당함

소프트웨어 생명 주기

개념화 단계

유아 및 성장기 성년기

( 제품으로서 )유아기

개발 단계 개발 후개발 전

프로세스


건축 프로세스

( 요구 분석 ) 집을 짓기 위해서는 건축설계사가 집주인과 만나 어떤

집을 원하는지 들어본다 .( 구조 설계 ) 건축설계사는 집주인의 요구를

반영하여 층별 배치도와 개략적인 조감도를

그린다 .( 상세 설계 ) 평면도 , 측면도를 필요한 자세한

설계 도면을 준비한다 .( 구현 ( 코딩 )) 설계가 끝나면 시공단계에 들어가서 실제로 집을 짓는

다 .( 테스트 ) 집을 지은 후에는 전등이 잘 켜지는지 , 난방이 잘되는지 등의

각종 점검을 수행한다 .( 유지보수 ) 집이 완성된 후에는 하자에 대한 유지보수를 수행한다 .

프로세스


소프트웨어 프로세스 모델

개발 프로세스 : 개발 과정을 체계적으로 정리한 과정

실정에 맞는 개발 팀의 고유한 모델의 정립 필요

소프트웨어 개발에 필요한 작업• 요구 분석과 정의

• 시스템 설계 ( 건축의 구조 설계에 해당 )• 프로그램 설계 ( 건축의 상세 설계에 해당 )• 프로그램의 작성 ( 구현 )• 테스트 ( 단위 테스트 , 통합 테스트 , 시스템 테스트 )• 시스템 설치

• 유지보수

프로세스


대표적인 소프트웨어 프로세스 모델

폭포수 모델 (Waterfall Model)프로토타이핑 모델 (Prototyping Model)점증적 모델 (Incremental Model), 나선형 모델 (Spiral Model)V 모델 (V Model)일정 중심 설계 모델

진화적 출시 모델 (Evolutionary Delivery Model)

프로세스


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


폭포수 모델 (Waterfall Model) (1/3)

계 획

인수설치

시 험

구 현

설 계

요구 분석

프로세스


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


폭포수 모델 (Waterfall Model) (3/3)

1970년대 소개항공 방위 소프트웨어 개발 경험으로 습득

각 단계가 다음 단계 시작 전에 끝나야 함• 순서적 - 각 단계 사이에 중복이나 상호작용이 없음

• 각 단계의 결과는 다음 단계가 시작 되기 전에 점검

• 바로 이전 단계로의 피드백만이 가능함

단순하거나 응용 분야를 잘 알고 있는 경우 적합• 한 번의 과정 , 비전문가가 사용할 시스템 개발에 적합

결과물 (deliverable) 정의가 중요

프로세스


폭포수 모델의 프로세스 및 결과물 요약

계획 요구 분석 설계

구현 시험 인수 / 설치

• 문제정의• 타당성 분석• 비용 , 일정예측

계획서• DFD• 자료사전 • 소단위명세서

요구분석서

• 시스템구조설계• 프로그램설계• UI 설계

구조설계서상세설계서

• 프로그래밍• 단위테스트

프로그램• 통합시험• 기능시험• 성능시험

통합된프로그램

• 설치• 인수 시험

설치된소프트웨어

( 활동 ) ( 결과물 )

P R D

I T A

프로세스


폭포수 모델 – 계획 (Planning)

문제의 실현 가능성을 타진한다 . (feasibility study) 영구 기관 (엔진 ) 을 만들 수는 없다 ?, 물로 가는 자동차는 ?

개발하고자 하는 시스템의 성격을 파악하여 비용과 기간을 예측한다 . 예측을 잘못하면 소위 “열심히 하고 욕먹는 결과”를 초래한다 .개발 방법과 각 단계에 필요한 자원을 결정한다 . 좋은 도구를 사용할 경우 , 인력을 크게 줄일 수도 있다 .

열역학 법칙을 깬세계 최초 영구기관 ?

프로세스


폭포수 모델 – 요구 분석 (Requirement Analy-sis)

개발을 의뢰한 사용자 ( 일반인 , 운영자 , …) 요구나 주어진 문제를

정확히 분석하고 이해하는 과정이다 .

발주자와 개발자가 요구 분석 사항에 동의하여야

다음 단계 진행이 가능하다 .• 소프트웨어가 어떤 품질을 만족해야 하는지 결정한다 .• 소프트웨어가 어떤 기능을 제공해야 하는지 결정한다 .

( 세부적으로 어떻게 구현할 지는 추후 설계 단계에서 생각한다 .)

요구분석서는 사용자와 개발자의 의사 소통 수단으로서 , 정확하고

간결하고 완벽하며 이해하기 쉽고 일관성을 유지하도록 작성해야 한다 .

프로세스


폭포수 모델 – 설계 (Design)

시스템 구조 설계• 소프트웨어 구조를 어떻게 가져갈 것인가 ?• 일반적으로 , 소프트웨어 모듈을 정의하고 , 각 모듈간의 관계를 정의한다 .

프로그램 설계• 각 모듈내의 알고리즘을 설계한다 .• 모듈간의 인터페이스 방법을 설계한다 .

사용자 인터페이스 설계• 입력 형식 (메뉴 , 음성입력 등 ) 을 결정하고 설계한다 .• 출력 형식 ( 화면 , 소리 등 ) 을 결정하고 설계한다 .

프로세스


폭포수 모델 – 설계 ( 시스템 구조 설계 예제 )

PDSN/IWFGGSN

IXPC(Inter/eXter Process Communication)

통계 / 장애 / 상태 관리 Graphical UI

데이터베이스메시지 파일

정보 관리 및 공유

MS LME

메시지 송수신

SMSC IPLS

페이징 처리

AAA JUICE

단말 정보 처리

SANTAWISE INBH

과금 처리

NMS WINGS

기타 연동

Textual UI

운용자 정합

운용 / 형상 / 구성 관리

운용 및 유지보수

데이터베이스 관리

파일 (메시지 ) 관리

메시지 정보 관리

메시지 상태 관리

호처리 제어

제어 및 호처리

LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS

SANTA

프로세스


폭포수 모델 – 설계 ( 사용자 인터페이스 설계 예제 )

GUI(Graphical User Interface): Java 기반으로 이식성 높고 편리한 환경 제공

TUI(Textual User Interface): 원격지에서 MML 을 사용한 운영 기능 제공

명령어 입출력환경

MMC Category 선택 Combo Box

MMC Command List

MMC Command Parameter Table

MMC Command Input Text Field

MMC Command Result Output Window

Command실행

Command도움말

Output Window

결과 삭제

Window닫기

프로세스


폭포수 모델 – 구현 (Implementation)

미리 정해진 모듈 설계에 따라 프로그래밍 , 즉 코딩을 수행한다 .

코딩된 각 모듈은 테스트의 기본 단위이다 . 모듈 테스트는 테스트 단계가 아닌 구현 단계로 보기도 한다 .

코딩 작업 자체도 개발회사 전체적인 표준이 있어야 한다 .• 헤더 주석 , 변수 작명 규칙 , 모듈의 최소 및 최대 크기 등

• 모듈 테스트도 회사 전체의 표준이 있어야 한다 . 테스트 계획서 , Code Inspection, …

프로세스


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


폭포수 모델 – 시험 (Test)

각 모듈들이 정의된 인터페이스에 따라 잘 동작하는지 통합 시험

(integration test) 을 수행한다 .

여러 모듈을 조금씩 결합하면서 단계적으로 시험하는 방법을 취한다 .

테스트 : 개발 기관 내부에서 실제 사용해보는

시험이다 . version: 블레이트앤소울을 엔씨소프트 직원들을

대상으로 open 한다 .

테스트 : 선택된 고객을 대상으로 실제

사용해보는 시험이다 . version: 플레이드앤소울을 프로게이머들을

대상으로 open 한다 .

프로세스


폭포수 모델 – 인수 (Acceptance)

패키지 소프트웨어인 경우 ,사용자가 소프트웨어를 설치할 수 있도록 설치 안내서를 제공한다 .

주문형 소프트웨어인 경우 ,사용자 앞에서 직접 설치하며 , 필요한 경우 인수 시험 (acceptance test) 을 실시한다 .

설치 단계가 끝나면 소프트웨어 생명 주기에 있어서 운용 및 유지보수

단계로 넘어간다 .

프로세스


폭포수 모델의 결과물 (Deliverable)

Activity Output documentsRequirements analysis Feasibility study, Outline requirementsRequirements definition Requirements documentSystem specification Functional specification, Acceptance test plan

Draft user manualArchitectural design Architectural specification, System test planInterface design Interface specification, Integration test planDetailed design Design specification, Unit test planCoding Program codeUnit testing Unit test reportModule testing Module test reportIntegration testing Integration test report, Final user manualSystem testing System test reportAcceptance testing Final system plus documentation

단 , 프로젝트의 규모 및 성격에 따라서 크게 달라질 수 있다 .

프로세스


폭포수 모델의 장단점

장점• 개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다 .• 프로세스가 간단하여 일반인도 쉽게 이해할 수 있다 .• 중간 산출물이 명확하게 지정되어 있다 .

단점• 처음 단계를 지나치게 강조하면 코딩 , 테스트가 지연된다 .• 각 단계의 전환에 많은 노력을 기울여야 한다 . (뒤로 돌아가기 어렵다 .)• 소용없는 다종의 문서를 생산할 가능성 있음

프로세스


프로토타이핑 모델 (1/3)

요구 분석

프로토타입개발 / 개선

프로토타입평가

구현

인수 / 설치

프로토타이핑이란 시스템의 일부 혹은 모델을 만드는 과정이다 .시뮬레이션을 수행하거나 , 데모 시스템을 만드는 방법 등이 있다 .Rapid Prototyping Model ( 컬러링 예제 )

google phoneprototype



시범 시스템의 적용• 사용자의 요구를 더 정확하게 추출한다 .• 알고리즘의 타당성 , 운영체제와의 조화 , 인터페이스의 시험 제작을

통해 요구사항을 명확히 하고 위험을 줄일 수 있다 .프로토타이핑 도구• 화면 생성기

• 비주얼 프로그래밍

• 4 세대 언어 등

공동의 참조 모델(reference model) 제공

개발 단계에서 유지보수가 이루어짐

http://www.evolus.vn/Pencil/Home.html



프로토타이핑의 단점• 오해 ( 프로토타입을 보고 , 전부 다 개발한 것 아니냐고 할 수 있음 )• 기대심리 유발 ( 프로토타입이 이 정도이니 , 최종 결과물은 … )• 관리가 어려움 ( 중간 산출물 정의가 난해 )


점증적 모델 (1/2)

개발 싸이클이 짧은 환경• 빠른 시간 안에 시장에 출시하여야 이윤에 직결된다 . 빨리 만들어 일단 반응을 보자 .• 개발 시간을 단축하는 법 시스템을 나누어 릴리스한다 .

릴리스 1 구축 릴리스 2 구축 릴리스 3 구축

릴리스 1 사용 릴리스 2 사용 릴리스 3 사용

개발

자사

용자

개발 시스템

완성 시스템

프로세스


점증적 모델 (2/2)

릴리스 구성 방법• 점증적 (incremental) 방법 – 기능별로 릴리스

• 반복적 (iterative) 방법 – 릴리스할 때마다 기능의 완성도를 높임

단계적 개발• 기능이 부족하더라도 초기에 ( 빠른 시점에 ) 사용 교육이 가능

• 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음

• 자주 릴리스하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히

고쳐나갈 수 있음

• 개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음

이번 Release 에서는 성능 짱

이번엔 GUI 짱 …

• 좋은 점만 있니 ? 빈번한 업그레이드에 따른 피로도 누적

( 예 : 안드로이드 )

프로세스


나선형 모델 (1/3)

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

프로세스



소프트웨어의 기능을 나누어 점증적으로 개발• 실패의 위험을 줄임 위험 분석에 초점을 맞춘 개발 모델

• 테스트 용이

• 피드백이 용이

여러 번의 점증적인 릴리즈 (incremental releases)

진화 단계• 계획 수립 (planning): 목표 , 기능 선택 , 제약 조건의 결정

• 위험 분석 (risk analysis): 기능 선택의 우선순위 , 위험요소의 분석

• 개발 (engineering): 선택된 기능의 개발

• 평가 (evaluation): 개발 결과의 평가

프로세스



대규모 시스템 개발에 적합• Risk reduction mechanism

반복적인 개발 및 테스트• 강인성 향상

단점• 관리가 중요 ( 상당히 복잡하고 , 긴 과정 … )• 위험 분석이 중요

• 상대적으로 새로운 모델 ( 적용이 쉽지 않음 )

프로세스


V 모델

폭포수 모델에 시스템 검증과 테스트 작업을 강조함

신뢰성이 높이 요구되는 분야에 적용

폭포수 모델에서 감춰진 반복과 재작업을 드러내 놓은 모델임

요구 분석

시스템 설계

상세 설계

구현 ( 코딩 )

단위 테스트

통합 테스트

시스템 테스트

인수 / 설치

모듈 검증

인터페이스 검증

요구분석 검증

프로세스


일정 중심 설계 모델 (1/2)

점증적 모델과의 비교• 반복적 사이클을 거친다는 점에서 유사

• 최종 목표와 출시가 명확하지 않으며 , 중간에 중단할 수 있는 점이 다름

기능의 우선순위에 따라 개발을 진행하다가 출시일이 되면 중단함

프로세스


일정 중심 설계 모델 (2/2)

특징• 사용자의 요구에 대하여 우선순위를 정하고 , 이를 기초로 각 사이클을 계획

• 초기 단계에 중요한 기능들을 설계 , 구현하여 시스템의 골격을 만듦

• 상대적으로 덜 중요한 기능을 나중에 함으로 일정 조정 가능

단점• 우선순위가 낮아 출시에 포함되지 않을 기능을 분석하고 설계하는 데 시간을 낭비

적용• 소프트웨어 제품의 출시 날짜가 매우 중요한 경우

• 목표 일정을 달성할 수 있을지 불확실할 때

프로세스


진화적 출시 모델 (1/2)

버전 하나를 개발하여 고객에게 보여주고 , 고객 반응에 따라 제품을

개발하고 발전적으로 출시해 나감

프로세스


진화적 출시 모델 (2/2)

진화적 출시 (evolutionary delivery)• 고객의 요구를 여러 사이클에 걸쳐 개발하여 보여주면서 제품을 개선해 나가는 모델

프로토타이핑 모델과 다른점• 고객의 요구를 프로토타이핑 모델처럼 전적으로 수용하지는 않음

• 진화적 출시는 고객의 반응으로 바뀔 가능성이 적은 부분을 시스템의 핵심으로 개발

( 즉 , 바뀔 가능성이 적은 부분 먼저 개발함 )• 프로토타이핑 모형은 시스템에서 눈에 띄는 부분을 먼저 강조하고 , 나중에 시스템

기반에 있는 구멍을 메워나가는 식

프로세스


모델이 많은 이유

모델의 선택은 프로젝트의 상황과 요구에 좌우됨

모델을 잘 선택하면 , 소프트웨어 생산성이 높아짐

경우에 따라서는 최적의 효과를 내기 위하여 (두세 개 ) 모델의 융합이

이루어지기도 함

프로세스


모델 비교와 선택프로세스


In this chapter …





프로세스


지원 프로세스 ( 기타 프로세스 )

개발 이외에 다른 성격 ( 관리 , 지원 등 ) 의 프로세스가 필요함

지원 프로세스 혹은 우산 (umbrella) 프로세스가 필요

프로세스


프로젝트 관리 프로세스

비용 , 품질 , 일정 목표를 맞추기 위하여 , 프로젝트를 관리하는데

필요한 모든 작업• 계획 : 비용과 일정 예측 , 중간 점검에 대한 결정

• 모니터링 및 제어 : 계획 대비 진행상황 점검 , 위험 요소 모니터링 및 제어

• ( 사후 ) 분석 : 결과 분석을 통한 교훈 정리 프로세스 개선

프로세스


품질 보증 프로세스 (1/2)

목적 : 프로젝트의 프로세스와 프로덕트의 품질을 관리하고 향상시킴

종류 : 인스펙션 프로세스 , 프로세스 관리 프로세스

인스펙션 프로세스• 개발 결과에서 결함을 찾거나 방지하기 위한 노력 ( 코드 인스펙션 , 설계 인스펙션 등 )• 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사하는 과정

프로세스


품질 보증 프로세스 (2/2)

프로세스 관리 프로세스• 프로세스 관리 : 프로세스 자체를 개선하여 생성된 결과의 품질과 생산성을 향상시킴

( 프로젝트 관리 : 프로젝트를 수행하여 프로젝트의 목적을 달성 )• 프로세스 개선을 통해 , 프로세스 상태가 변화하고 , 이를 통해 새로운 능력이 생김

프로세스


형상 관리 프로세스 (1/2)

형상 관리 (configuration management)• 개발 중에 발생하는 변경을 체계적으로 제어 (control) 하고 관리하는 작업

• 개발 과정에서 어떤 자원 하나라도 잃지 않고 문서의 정확한 버전을 원시코드와 함께

제공하려는 활동

프로세스


형상 관리 프로세스 (2/2)

형상 관리 기능• 프로그램의 최신 버전 유지

• 지정된 버전으로 되돌아 갈 수 있는 기능

• 무허가 변경이나 삭제를 방지 (권한 /접근 제어 )• 현 시스템에 대한 모든 정보 , 문서 등의 정보를 모아 보관

형상관리 메커니즘• 형상 관리 대상 파악과 베이스라인 지정

• 버전 관리

• 접근 제어

프로세스

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

Documents