Transcript PowerPoint 프레젠테이션

Software Engineering
고형석
정보관리기술사
정보시스템 감리사
[email protected]
0
소프트웨어 공학 Overview
개요
추상화
Devide&Conquer
단계적정제
델파이기법
ERD
데이터모델링
DFD
기능모델링
DD
제어모델링
행위모델링
이벤트모델링
결합도
모듈화
응집도
FAN-IN/OUT
CASE Tool
개발
단계별
목적별
테스트
Black box,White box
Stub,Driver
SLM
SLA
ITIL
유지보수
Outsourcing
ISO9126
ISO9000
ISO12207
CMMi
SW-CMM
SE-CMM
P-CMM
IPD-CMM
SA-CMM
CMM
SW프로세스모델
분석
설계
SW개발방법론
SW개발
SW공학개념
개념
객체지향
UML
SW재사용
SW공학
제품품질
프로세스품질
SW품질
SPICE
Review
Waikthrough
Inspection
신뢰도
감리보고서
1
SW프로젝트
FTR
감리
SW산업육성방안
SI사업평가제
SW위기
SW이슈
폭포수모델
프로토타이핑
나선형모델
점증적모델
4GT 모델
구조적방법론
정보공학방법론
객체지향방법론
CBD방법론
추상화
캡슐화
상속성
다형성
정보은닉
View
Diagram
RUP
component
CBD
재공학
역공학
유일성,한시적,점진적상세화
프로젝트정의
PPD,PPE,OCC
통합관리
Initiation,SP,SD,SV,SCC
범위관리
AD,AS,ADE,SD,SC
일정관리
RP,CE,CB,CC
원가관리
QP,QA,QC
품질관리
프로젝트관리
OP,SA,TD
인력관리
CP,ID,PR,AC
의사소통관리
RMP,RI,QRA,QRA,RRP,RC
위험관리
PP,SP,S,SS,CA,CC
구매외주관리
변경관리
형상관리
프로젝트계획서
계획수립
제안서
제안프로세스
SW프로젝트추정
LOC
COCOMO
FP
양과질을고려한방식
양적추정방식
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
2
SW공학
SDLC(생명주기)
SW 개발 모델
개발방법론
객체지향방법론
CBD
SW 테스트 단계
SW 테스트 방법
유지보수
위험관리
아웃소싱
SPEED 경영을 위한 SE 접근
SPEED 경영의정의(삼성경제연구소)
􀂃급변하는 경영환경에 대한 대응력을 극대화함으로써 고객이 만족하는 제품 및 서비스를
남보다빠르게제공하는경영
• 먼저경영 : 미래유망 사업의 조기발굴, 사전준비, 선행투자
 SE 접근방법
• Enterprise modeling
• Enterprise Architect
• Risk Management using OT
􀂃 시간단축경영: 리드타임의단축, 상품개발시간의단축
 SE 접근방법
• Faster cycle time
• QM
• Process관리(Process 성과모니터링, Process deploy)
• OT (Opportunity Tree)
3
SE-1. 소프트웨어공학
1. 소프트웨어 발전과정
1세대
-일괄처리
-주문형S/W
2세대
-멀티유저
-멀티프로그램
-실시간처리
-DB사용
-제품화 S/W
3세대
-분산시스템
-내장된 “지능”
-저가의 H/W
-고객중심
-마이크로프로세서
출현
4세대
-강력한 DeskTop
-객체지향기술
-전문가 시스템
-인공지능망
-병렬컴퓨팅
-N/W컴퓨터
2. 소프트웨어 위기
1) 하드웨어 기술의 급속한 발전, 범용컴퓨터의 광범위한 보급, S/W엔지니어 위기
- 하드웨어 기술은 소프트웨어 개발 능력의 발전속도보다 휠씬 빠름
- 새로운 S/W를 요구하는 시장의 수요를 감당할 수 없음
- 기존 정보기술로 개발된 S/W의 유지보수가 어려워짐
- 무어의 법칙: 마이크로칩에 저장할 수 있는 데이터량/속도가 매 18개월마다
두 배씩 증가 한다는 법칙  깨질 정도로 빨라지고 있음
2) S/W분야의 인건비 상승, 우수한 S/W의 부족, S/W생산성에 대한 위기의식
3) S/W 위기 도래
- 개발 예산초과, 개발일정 지연, 생산성 저하, 품질 저하
4
SE-1. 소프트웨어공학
4) S/W위기의 원인
- S/W 특성에 대한 이해의 부족
- S/W 프로그래밍에만 치중하고 관리의 부재
소프트웨어의 특성




무형(intangible) : 사실은 집 짖는 일과 동일하나 형체가 없음
진화(evolution) : 유기체와 같이 변하므로 효과적인 관리필요
비소멸성: bathtub curve, 교환 불가(patch pgm으로 해결)
제조가 아닌 개발(developed / not manufactured)
Failure Curve for S/W
Failure rate
Change
Ideal curve
Time
5
SE-1. 소프트웨어공학
3. 소프트웨어 공학의 목표
- 소프트웨어 위기 해결
- 고품질(Quality)의 소프트웨어 제품 생산
- 소프트웨어 생산성(Productivity) 향상
- 소프트웨어 개발, 운영, 유지보수 비용 절감
4. 소프트웨어 공학의 정의
1) Fritz Bauer
- 컴퓨터 하드웨어에서 신뢰성 있게 운영되는 소프트웨어를 경제성있게 개발하기
위해 공학적 원리를 응용하고 확립 시킨 이론
- 기계에서 안정적이고 효율적으로 작동하는 소프트웨어를 얻기 위한 올바른
공학 원칙을 수립하고 사용하는 것
2) ANSI/IEEE : 소프트웨어 개발, 운영, 유지보수 및 폐기 과정에 적용되는 체계적인
접근 방식 및 일련의 기술
3) Berry Boehm : 컴퓨터 프로그램을 설계, 개발, 운영, 유지보수에 관련된 문서를
작성하는 데 필요한 과학적인 지식의 실용화
4) Richard R. Fairley : 전산학, 경제학, 경영과학 및 의사소통기술과 문제해결을 위한
공학적인 접근방안을 토대로 소프트웨어 개발에 임하는 신기술 체계
Keyword : 비용, 품질, 생산성, 소프트웨어, 공학
6
SE-1. 소프트웨어공학
5. 소프트웨어 공학의 구성
도구
방법론
프로세스
품질 초점
1) 프로세스 계층
- 소프트웨어 공학 기술의 효과적인 인도를 위해 설정해야 하는 핵심프로세스
영역(Key Process Areas)에 대한 프레임워크를 정의
- KPA : 소프트웨어 프로젝트들의 관리제어에 대한 기준을 만들고, 기술적인 방
법들을 적용하고, 작업 제품들(모형,문서,데이터,보고서,형식 등)을 만들어
내고 이정표를 설정하고,품질을 확인하고 변경을 적절하게 관리하는 내용들을
포함
2) 방법론(Method)
- 소프트웨어를 구축하는 기술적인 "How to"를 제공
- 요구사항분석, 설계, 프로그램 구축, 테스트, 유지보수 등의 태스크들로 구성
3) 도구(Tool)
- 프로세스와 방법을 자동화나 반자동화를 지원하는 기능을 제공
- CASE : 도구들이 통합되어 한 도구가 생성한 정보를 다른 도구가 사용할 수
있도록 도구들을 통합하는 것
소프트웨어 공학 환경을 만들기 위해 소프트웨어, 하드웨어, 소프트웨어 공학
데이터베이스(분석,설계,코딩,테스트에 관한 중요한 정보를 포함하는 저장소)
들을 결합시켜 놓은 것
7
SE-1. 소프트웨어공학
6. 소프트웨어 공학 프로세스
정의
What(계획, 요구분석)
개발
How(설계, 개발, 테스트)
유지보수
Change(적응, 예방)
1) 정의단계 (Definition Phase)
- 무엇(What)에 초점
- 처리되는 정보, 성능과 기능, 인터페이스, 설계제약 조건, 검증기준 등의 기술
- 시스템과 소프트웨어의 주요 요구사항 결정단계
- 소프트웨어 프로젝트 계획, 요구분석 단계
2) 개발단계(Development Phase)
- 어떻게(How)에 초점
- 데이터 구조화, 소프트웨어 기능 및 설계, 개발, 테스트에 대한 기술 단계
- 소프트웨어 설계, 코드생성, 소프트웨어 테스트 단계
3) 지원단계(Support Phase)
- 변화(Change)에 초점
- 오류수정, 소프트웨어 사용환경변화에 따른 변화, 사용자 요구에 따른 변경
- 기존 소프트웨어의 성질은 변화시키지 않는 범위에서 적용시킴
- 종류:수정(결함수정), 적응(환경변화), 강화(기능추가), 예방(품질향상)
8
SE-2. SDLC(Software Development Life Cycle)
1. Digital Convergence
Ⅰ. 소프트웨어 위기 극복을 위한 소프트웨어 개발 생명 주기 모델
가. 소프트웨어 개발 생명주기의 정의
- 소프트웨어를 개발하기 위한 정의 과정, 개발 과정, 유지 보수 과정, 폐기과정까지를
하나의 연속된 주기로 보고, 효과적으로 수행하기 위한 방법론을 모델화한 것임
나. 소프트웨어 개발 생명주기의 필요성
- 소프트웨어를 획득하는 과정에서 나타나는 소프트웨어 위기를 극복하기 위한 방안 필요
- 효과적으로 소프트웨어를 개발하기 위해 표준화된 수행 방법과 절차가 필요
- 고품질의 소프트웨어를 획득하는 데에도 일정 수준이상의 생산성을 확보하는 것
II. 소프트웨어 개발 생명주기의 구성
가. 국제표준에서의 소프트웨어 개발 생명주기 모델의 위치
9
SE-2. SDLC(Software Development Life Cycle)
Process Maturity
SPICE
ISO 15504
Process Quality
ISO/IEC 12207
15288
Quality Management
ISO 9001/9000-3
Maturity
Life Cycle
Quality
나. 소프트웨어 개발 생명주기 모델의 단계
타당성
조사
요구분석
정의 단계
What(계획,요구분석)
구분
10
설계
개발
테스트
개발 단계
How(설계,개발,테스트)
유지보수
폐기
지원 단계
Change(적응,예방,폐기)
내용
정의단계
Definition Phase
타당성, 요구 명세화
타당성 조사, 소프트웨어의 기능과 제약조건을 정의하는 명세서 작성하는 단계
개발단계
Development Phase
개발 단계
명세서를 만족하는 소프트웨어를 실제 개발, 구현하는 단계 (설계, 구현)
확인, 검증 단계
요구 명세화 내용을 기준으로 사용자가 원하는 소프트웨어인지를 확인하는 검증 단계
(시험, 설치)
지원단계
Support Phase
유지보수, 폐기 단계
운영환경의 변화 및 사용자 요구사항의 변화를 수용하기 위한 진화/적응 및 프로그램 폐기
SE-2. SDLC(Software Development Life Cycle)
III. 소프트웨어 개발 생명주기 모델의 분류 및 선정기준
가. 소프트웨어 개발 생명 주기 모델의 분류
구분
폭포수 모델
내용
Waterfall Model
-고전적 라이프사이클 패러다임(Classic Life-cycle Paradigm)
-분석,설계,개발,구현,시험,유지보수를 순차적으로 접근하는 방법
Prototyping Model
프로토타이핑 모델
-개발 대상인 시스템 주요기능을 초기에 운영모델로 개발하는 것
-점진적 개발방법(Waterfall Model의 단점 보완)
-일회용, 진화용 시제품
1.Incremental Development Model
반복적 개발 모델
1.증분 모델
2.진화형 모델
RAD기법 모델
-폭포수 모델변형으로, 소프트웨어를 구조적 관점에서 하향식
계층구조의 수준별 증분을 개발하여 이를 통합하는 방식
2.Evolutionary Development Model
-시스템이 가지는 여러 구성요소의 핵심부분을 개발한 후 각
구성요소를 개선 발전시켜 나가는 방법
Rapid Application Development
-사용자의 주도로 요구사항 정의, 분석, 설계
-Code Generator에 의한 신속한 시스템 개발 기법
4th Generation Technique
4세대 모형
- CASE 및 자동화도구를 이용하여 요구사항 명세로부터
실행코드를 자동으로 생성할 수 있게 해주는 기법
11
SE-2. SDLC(Software Development Life Cycle)
다. 소프트웨어 개발 생명주기 모델의 선정기준
- 수행해야 하는 프로젝트의 규모와 성격에 따라서 개발주기를 선정하고 개발생명 주기 기반의 개발
방법론과 관리 방법론을 도입
- 소프트웨어 개발에 사용되는 개발 및 관리방법론과 연계하여 최대한의 생산성을 확보할 수 있나를
고려해야 함
- 소프트웨어 개발에 소요되는 시간과 비용을 고려하고 품질에 관한 사항을 고려하여
불필요한 작업항목을 최소화하여 진행할 수 있는 기준을 도입
- 개발과정에서의 통제수단과 소프트웨어 산출물 인도 방식에 따라서 개발모형을 선정 해야 함
IV.소프트웨어 개발 생명 주기의 문제점과 발전방향
가. 소프트웨어 개발 생명 주기의 문제점
- RAD(Rapid Application Development)개발 모델과 프로토타이핑 모델에서는 사용자 참여가
충분하지만, 여타의 개발 모델에서는 사용자의 참여가 미흡하여 완료단계에서 품질 문제가 발생할 수
있음
- 각 진행단계별로 진행내용에 대한 점검을 대부분의 개발모델에서 문서위주로 확인 하는 방식이기
때문에 비효율적인 작업진행 가능성 있음
- 단계별로 진행내용을 수행하고 이에 따라서 다음 단계를 진행하기 때문에 전체 생명주기의 진행이
늦어질 가능성이 있음
- 지속적으로 발전해서 개발이 필요하고 계속해서 확장하는 시스템을 적용하는 경우에는 오히려
적합하지 않을 가능성이 있음
12
SE-3. SW 개발 모델
1. Waterfall 모형(폭포수형)의 정의
- 고전적 라이프사이클 패러다임(Classic Life-cycle Paradigm)
- 분석, 설계, 개발,구현, 시험 및 유지보수과정을 순차적으로 접근하는 방법
2. Waterfall 모형의 특징
- S/W개발을 단계적으로 정의한 체계이며 순차적 접근방법 사용
- 개념 정립에서 구현까지 하향식 접근 방법을 사용
( 높은 추상화 단계 -> 낮은 추상화 단계로 옮겨가는 방식)
- 각 단계 종료 시 검증 후에 다음 단계로 진행(이전단계산출물 ->다음단계의 기초)
3. Waterfall 모형의 장/단점
장점
- 프로젝트 진행과정을 세분화하여 관리
용이
- 가장 오래되고 폭넓게 사용 : 사례 풍부
- 전체과정이 이해하기 용이
- 기술적 위험이 작고, 경험이 많아 비용,
일정예측이 용이한 경우 적합
13
단점
- 실제 프로젝트는 이 모델을 따르지 않음
(간접적으로만 각 단계의 반복을 허용함)
- 고객 요구사항을 초기에 구체적으로 정의
어려움(초기 불확실성 수용 어려움 )
- 중요 문제점의 발견이 늦어짐
(목표 시스템이 후반부에 가서야 구체화됨)
- 순환발생으로 순차적흐름을 따라가기 곤란
- 초기 단계 강조 시 코딩, 테스트 지연
SE-3. SW 개발 모델
4. Waterfall 모형의 구성 단계
Waterfall 모형에 적합한 프로젝트
• 기술적 위험이 낮고 유사한 프로젝트 경험이 있는 경우
• 요구사항이 명확히 정의되어 있는 경우
14
SE-3. SW 개발 모델
1. Spiral 모형의 정의
- 이미 개발된 Prototype을 지속적으로 발전시켜 최종SW에 이르게 하는 모델
- Waterfall Model 및 Prototyping Model의 장점에 위험 분석을 추가
- 위험 최소화가 목적
- 점진적으로 시스템을 완성해 나가는 방법
2. Spiral 모형의 특징
- 대규모 시스템 및 위험 부담이 큰 시스템 개발에 적합(위험분석 추가)
- 반복적인 접근법
- 위험의 최소화
3. Spiral 모형의 장/단점
장점
- 프로젝트 개발의 완전성 부여
(정확한 사용자 요구사항)
- 위험 부담 감소
- 문서화의 충실로 유지보수 용이
- 품질 확보
- 대규모 시스템에 적합
15
단점
- 프로젝트 개발에 많은 시간소요
- 충분한 검증 미흡(새로운 접근방법이며 많
이 사용되지 않았음)
- 모델이 복잡하여 프로젝트관리를 어렵게
만들 가능성 존재
- 다수 고객 상대의 상용제품 개발에는
부적합
SE-3. SW 개발 모델
4. Spiral 모형의 구성 단계
단계
16
내용
계획 수립
목표, 제약조건 설정
위험 분석
위험 요소들의 분석과 관리기술을 통한 해석
개발
다음 단계 프로토타입 개발
고객 평가
개발된 프로토타입의 평가
SE-3. SW 개발 모델
Ⅰ. 사용자 요구사항을 구체화 위한 프로타이핑 모델
가.프로토타이핑 모델 의 정의
- 프로토타이팅(시스템 일부 또는 시스템 모델을 만드는 과정)을 통하여 개발하려는 시스템주요기능을 사
용자의 요구사항을 최대한 반영하여 초기에 개발하는 방법
- 폭포수 모델(Waterfall Model)의 단계적 개발방법의 단점 보완하여 실제의 소규모운영 모델을 단기간에
구체화 시키는 방법
- 일회용, 진화용 시제품으로 구체적인 요구분석에 임하는 전략 또는 방법
나.프로토타이핑 모델의 필요성
- 비전문가인 사용자와 개발될 소프트웨어에 대한 목적과 기능을 원활하게 의사소통하기 위한 방안이 필
요함
- 업무기능이 복잡해진 경우의 입력과 출력을 정확하게 요구사항을 분석하기 위함
- 사용자의 요구를 근거로 개발 타당성을 검토하고 사용자의 참여를 유도하기 위함.
- 간단한 시제품(프로토타이프)을 만들어서 사용자의 요구사항을 정확히 적용할 수 있음
II. 프로토타이핑 모델의 특징과 구성
가. 프로토타이핑 모델의 특징
17
SE-3. SW 개발 모델
구분
18
내용
요구분석을 위한
Approach 방법
- 개발을 위해 필요한 전체단계에 대한 Approach가 아님
- 요구분석의 어려움을 해결하기 위해 시범시스템에 적용
- 사용자 요구가 불명확한 경우에 정확히 요구사항을 추출
반복 작업
- 반복해서 모형을 개발해서 실제에 더 가까운 시제품을 작성
- 짧은 기간 내에 소프트웨어 상품을 개발하고자 할 때 사용
- 알고리즘 타당성, 운영체제와의 조화, 인터페이스 시험제작
사용자 참여 모델
- 사용자의 요구사항의 수정이 반복되어 적용되어 시스템 진화
- 개발단계에서 사용자가 참여하여 유지보수가 이루어지는 모델
- 사용자와 개발자 모두에게 공동의 참조모델을 제공
SE-3. SW 개발 모델
나.프로토타이핑 모델의 구성
변경된
요구사항
요구분석
프로토타이프
설계
프로토타이프
개발
불만족
프로젝트
취소
만족
구현
개발
유지보수
19
프로토타이프
평가
인수/설치
SE-3. SW 개발 모델
다.프로토타이핑 모델의 구성 단계
구분
20
내용
요구분석
- 사용자의 요구사항을 정리하고 명세화 하는 단계
- 명세화의 방법을 프로토타이프를 사용하여 진행
프로토타이프 설계
- 프로토타이프에 대한 방향과 내용을 정리하여 명세화
- 명세화된 설계내용은 폭포수모델의 입력으로 사용 가능
프로토타이프 개발
- 예비로 작동되는 시범모델에서 사전 구축하여 결함을 발견
- 프로토타이프를 검증하면서 설계방향과 내용을 제시
프로토타이프 평가
- 사용자에 의해서 프로토타이프에 대한 평가를 수행
- 사용자의 평가에 따라 프로젝트 승인 및 취소까지 고려
구현
- 프로토타이프 승인에 따라서 실제 시스템을 구현하는 단계
- 완전한 시스템의 프로덕트 전체를 구현하여 진행
인수 및 설치
- 구현된 시스템을 인수하고, 설치하여 시스템을 가동
- 수행절차에 따라 유지보수 단계로 진행
- 유지보수 활동에 따라 요구,명세,설계,구현단계로 재진입
변경된 요구사항
관리
- 유지보수 활동에서 나타난 변경된 요구사항을 SDLC에 재진입
- 각 단계의 진행 내용에 따라 개발,구현,인수 단계를 수행
SE-3. SW 개발 모델
III. 프로토타이핑 모델의 장단점과 고려사항
가. 프로토타이핑 모델의 장단점
21
장점
단점
- 사용자 요구사항이 불명확할 때 사용하는 것이
용이
- 제품의 추적성, 시험가능성 확보
- 개발자와 사용자의 의사소통 원활
- 소프트웨어 기능을 나누어 점증적으로
발전시켜 최종 소프트웨어에 도달하는
개발방법
- 시스템의 이해와 품질향상에 기여
- 개발자와 사용자 의사소통 원활
- 프로토타입의 결과를 최종의 프로젝트 결과물
로 오해할 수 있음
- 사용자 요구사항을 프로토타이프로 검증할 때
는 문서작성 경시, 산출물 부족
- 프로토타입 폐기 시 비경제적임
- 소프트웨어 개발에 많은 시간이 소요되며, 보
고서 등 출력물이 많아짐
- 중간과정을 점검할 수 있는 일정표와
산출물이 없기 때문 관리 통제 어려움
SE-3. SW 개발 모델
나. 프로토타이핑 모델의 도입 시 고려사항
구분
22
내용
품질보증
- 사용자 충족도 기준으로 평가 척도로 사용
- 초기과정에서 평가하여 오류 감소
변덕스러운 사용자 요구의 수용
- 구조적 기법의 보완
- 초기 수정
개발과 유지 보수의 비용 절감
- 설계와 개발을 동일한 생명주기에서 처리
- 설계변경은 개발과정에 즉시 적용
생산성 향상
- 폭포수 모델과 프로토타이핑 모델의 장점을
취합하여 위험관리를 강화
S/W 유지보수 요구의 평가
-현업 부서의 변경 추가 요구의 타당성 조사 혹은 설득용 도구
로 활용
SE-3. SW 개발 모델
Ⅰ. 반복적 개발 모델의 개념
가.반복적 개발모델 의 정의
- 소프트웨어의 구조적 관점에서 하향식 계층구조의 수준별 증분을 개발하여 이들을 통합하는 개발 모델
- 사용자의 요구사항의 일부분을 제품의 일부분으로 반복적으로 개발하여 최종제품을 완성
하는 방법으로 전통적인 폭포수 모델과 프로토타이핑 모델을 결합한 것
나.반복적 개발모델의 필요성
- 폭포수, 프로토타이핑 개발모델의 개념을 포괄하는 보다 진보된 개발 모델
- 사용자 요구사항의 일부분을 제품의 일부분으로 반복적으로 개발하여 최종제품을 완성
하는 중/대규모 시스템 구축에 적합한 모델
- 모든 프로세스 단계마다 프로덕트가 생산되는 가시화 가능한 진행
- 진화 또는 증분 개발모델로 시스템의 복잡도가 급격하게 늘지 않음
- 손쉽게 사용자의 평가가 이루어져서, 시장 변화에 효율적인 대응이 가능
다. 대표적 반복적 개발모델
23
SE-3. SW 개발 모델
구분
내용
- Incremental Development Model
- 증분 개발 모델은 전통적인 폭포수 모델에 반복적 수행 개념을
증분 개발 모델
결합하여 적용한 모델
- 여러 개발 팀들이 전체 시스템을 기능별로 나누어서 개발하고자
할 때 유용
- Evolutionary Development Model
- 시스템이 가지는 여러 구성요소의 핵심부분을 개발한 후 각
진화적 개발 모델
구성요소를 개선 발전시켜 나가는 방법
- 시스템이 완성된 후에도 요구사항을 시스템에 적용
- 발견된 오류를 수정하는 활동, 즉 개선을 위한 개발노력을 반복
적으로 시행
24
SE-3. SW 개발 모델
II. 반복적 개발 프로세스와 특징
가. 반복적 개발모델의 구성
반복적 개발 프로세스 (Iterative Development Process)
소프트웨어
요구사항
설계
구현
시험
각각의 사이클은 정해진 Time-Box 내에 수행될 수 있도록 적절한 부하를 할당
(Time-Box는 2주~2달 정도가 적절)
나. 반복적 개발모델 사용의 특징
- 초기에 가시화되는 프로세스사용, 조기에 높은 위험 가능성을 회피 하거나 경감
- 사용자가 참여하므로 조기에 평가하여 적응시키고, 성숙된 프로세스 도출
- 반복하여 진행하기 때문에 개발 프로세스 자체를 개선해서 산출물의 복잡성을 관리 가능
25
SE-3. SW 개발 모델
Ⅲ. 대표적 반복적 개발 기법
가. 증분 개발모델 (Incremental Development Model)
1) 증분 개발 모델의 생명주기
증분 #1
설계
구현/
시험
설치/
운영
정보흐름
소프트웨어
요구사항
증분 #2
증분 #3
증분 #4
설계
구현/
시험
설치/
운영
구현/
시험
설계
설계
설치/
운영
구현/
시험
2) 증분 개발 모델의 특징
- 규모가 큰 개발 조직일 경우 자원을 각 증분 개발에 충분히 할당할 수 있어 각 증분의
병행 개발을 통해 개발 기간을 단축 시킬 수 있음
- 증분의 수가 많고, 병행개발이 빈번하게 이루어지면 개발 프로젝트의 관리가 어려워지고
PM은 증분 개발 활동간의 조율에 많은 노력을 기울여야 함
26
설치/
운영
SE-3. SW 개발 모델
나. 진화적 개발 모델 (Evolutionary Development Model)
1) 진화형 개발 모델의 생명주기
핵심요구사항 개발
소프트웨어
요구사항 1
피드백
구현/
시험
설계
소프트웨어
요구사항 2
피드백
구현/
시험
설계
소프트웨어
요구사항 3
최초 시스템
설치/
운영
설계
설치/
운영
1단계 진화
구현/
시험
설치/
운영
N 단계 진화
2) 진화적 개발 모형의 특징
-
기능의 일부를 최초로 개발하고, 이를 사용자에게 확인 받아가면서 만족할 때까지 반복
1단계 진화에서 시스템의 각 구성항목의 핵심부분을 포함하는 최소의 시스템을 개발
2단계 진화부터는 이 시스템을 개선하는 프로세스 진행
다음 단계로의 진화를 위해 전체 진화 과정에 대한 개요(Outline)가 필요
IV. 반복적 개발모델의 도입 시 고려사항
27
SE-3. SW 개발 모델
가. 반복적 개발모델의 도입 시 고려사항
구분
사용목적
-각 단계에서 운영 가능한 고품질의 결과물을 제공
-단계별 결과물은 요구사항의 일부 만을 만족시킴
프로세스
구성
-구현단계별로 결과물을 제공
-최종의 결과물은 10-50개 구현 단계로 구성
프로세스 주기
28
내용
-수주 내에 사용 가능한 품질 높은 유용한 결과물을 사용가능
장점
-사용자가 새로운 결과물을 이용하고 적응하는 데 거부감 적음
-지속적으로 반복하여 프로세스가 진행되므로 프로세스 진화 및 성숙
-따라서, 유지보수 단계에서의 비용절감 효과
-예측 가능하여 계획되고 관리되고 위험에 의해 진행됨
-반복적인 개발주기로 혼란을 적게 하면서 요구사항의 변경을 수용
-문서가 아닌 실행 가능한 프로토타입의 발전에 바탕을 두고 있음
-전체 프로세스에 걸쳐 사용자를 참여 시킴
단점
-반복적인 설계단계의 결과내용을 이전설계단계의 내용과 조율 필요
-더욱 세심한 요구관리 필요
-구축,수정의 프로세스를 진행하여 프로세스 관리가 어려움
SE-3. SW 개발 모델
1. RAD(Rapid Application Development) 모형의 정의
- 사용자에 의한 요구사항 정의, 분석 및 설계와 Code Generator에 의한
신속한 시스템 개발 방법론
2. RAD 모형의 특징
- 도구의 활용(CASE 도구, RDB, 재사용 Library 등)
- Prototyping 사용
- 사용자 적극 참여
- 소요기간 : 60일 ~ 90일 정도의 짧은 기간
- 기술적 위험이 적고 빠른 개발이 요구될 때 적합
모델링
비즈니스
모델링 단계
데이터
모델링 단계
어플리케이션
생성 단계
프로세스
모델링 단계
60~90일
3. RAD 모형의 단계
1) JRP(분석) : 사용자와 함께 Biz모델 작성/검토 반복을 통한 분석
2) JAD(설계) : 사용자화 함계 Prototype 개발/수정/보완 반복을 통한 시스템 설계
3) 구축/운영 : 관련기술을 이용하여 시스템 구축/ 운영
4. 장/단점
장점
- 요구사항의 완전한 이해와 프로젝트 범위
의 명확한 설정 시 신속한 개발 및 완전한
기능 구현 가능
29
단점
- 책임감 있는 구성원이 없을 경우 실패
- 적절한 모듈화 가능성 전제
- 기술적 위험이 높을 경우 부적합
테스트 및
인수 단계
SE-4. 개발방법론
Ⅰ. 소프트웨어 개발생명주기의 구체적 실천방안 개발방법론
가.소프트웨어 개발방법론의 정의
- 소프트웨어공학원리를 소프트웨어개발생명주기(SDLC)에 적용한 소프트웨어 개발방법
- 정보시스템을 개발하기 위한 작업활동, 절차, 산출물, 기법 등을 체계적으로 정리한 것
나.소프트웨어 개발방법론의 필요성
- 개발작업공정을 표준화 및 모듈화하여 개발경험 축적과 재사용을 가능히게 하여 개발
생산성 향상방안
- 수행공정을 관리 가능하게 가시화하여 효과적인 개발 및 관리방법을 제시
- 사용자 및 개발자간의 의사소통을 위한 수단으로 표준화된 용어가 필요
다.대표적인 개발방법론의 진화
1960년
1970년
1980년
1990년
2000년
정보공학 방법론
구조적 방법론
객체지향 방법론
CBD
30
SE-4. 개발방법론
구분
특징
구조적방법론
Logic중심,제어 가능 모듈로 구조화→재사용 및 유지보수성 제고
정보공학방법론
전사적 통합 데이터모델,Logic은 데이터 구조에 종속 (CRUD)
객체지향방법론
고도의 모듈화, 상속에 의한 재사용 (White Box Reuse)
CBD
Black Box Reuse 지향, 컴포넌트 생산/선택/평가/통합의 개발방법
II. 개발방법론의 적용단계와 구성요소
가. 개발방법론의 적용단계
계획
WHAT
분석
설계
HOW
CHANGE
31
구축
유지보수
비용 및 일정 추정, 개발 계획 수립
사용자 요구분석, 기본기능과 성능요건 파악
분석된 내용을 기준으로 기초설계 및
상세설계
설계내용을 구현(개발,테스트,수정) 단계
시스템 운영 및 유지보수
SE-4. 개발방법론
나.개발방법론의 구성요소
구성
내용
요소
작업
절차
작업
방법
산출물
- 프로젝트 수행 시 이루어지는 작업단계의 체계
- 단계별 Activity의 정의, Activity별 세부작업 열거,
- 각 단계별 수행해야 하는 항목 정의
-절차와 작업방법을 명시 (누가, 언제, 무엇을 작업
도구
32
작업방법
하는지 기술)
- 각 단계별로 만들어야 하는 산출물의 목록 및 양식
- 계획수립, 진행관리, 품질, 외주, 예산, 인력관리 등
기록
기법
단계별 작업항목
Activity의 순서 명시
- 프로젝트의 진행 기록
관리
비고
- 각 단계별로 작업수행 시 기술 및 기법의 설명
-기법에서 제시된 긱 기법별 지원도구에 대한 구체
적인 사용표준 및 방법
설계서 등
계획서, 실적,
품질보증 등
구조적,객체지향,
ERD,DFD
CASE 등
SE-4. 개발방법론
III. 개발방법론 도입 시 고려사항
가. 개발방법론의 도입 시 고려사항
1) 재사용 관점
- 수작업을 최소화하고 자동화되어 있을수록 좋음(시간과 비용)
- 프로젝트 결과물(모듈,설계서,컴포넌트) 재사용을 위한 정보공유체제 마련
- 의사소통,형상관리,품질관리를 위한 Repository 구축
2) 개발생산성 관점
- 소프트웨어 개발 프로세스 능력향상 기대, 성능기대
- 검증된 결과물/컴포넌트을 사용하여 안정성 및 생산성 향상
- 프로젝트 특성 (응용분야, 시스템 규모, 복잡도, 성격 등)을 고려하여 방법론을 선택해야
하고, 향후 유지보수 단계에서 사용 가능한 결과물을 선택하고 작성해야 함
3) 관리적 관점
- 최신 개발 방법론인 CBD 도입 시에는 인력을 ROLE기반으로 재배치 고려해야 함
- 소규모 프로젝트에 방대한 규모의 방법론 적용하는 것은 지양하고, 상황에 따라 우선
순위를 정해서 점진적 단계별로 추진필요
- 성공을 위한 가이드라인, 함정에 대한 경고 및 실제 활동에서 잊기 쉬운 점들을 체크
(통제수단과 산출물 인도방식)
- 개발자들에게 공감 하에 적절히 이용할 수 있어야 함 (방법과 도구, 경험)
33
SE-4. 개발방법론 – 구조적방법론
1. 구조적 기법의 개요
1) 구조적 기법의 정의
- 업무활동 중심의 방법론으로 정형화된 절차 및 도형 중심의 도구를 이용하여
사용자 요구사항 파악 및 문서화하는 기법
- 구조적 방법론의 기본적인 뿌리는 구조적 프로그래밍에서 출발하여 설계의
원칙들을 정리한 구조적 설계, 시스템 복잡성 해결을 위한 구조적 분석으로 발전
2) 구조적 기법의 등장 배경
- 소프트웨어 위기의 해결책 필요성
- 생산성 향상, 품질 개선, 유지보수성 향상
3) 특징
- 정보와 정보의 구조를 중심으로 분석, 설계, 구현
- 정형화된 분석절차에 따라 사용자 요구사항을 파악하고 도형중심의 다이어그램을
이용하여 문서화
- GOTO 분기 대신에 3개 논리적인 구조(Constructs)인 순차(Sequencing), 선택(Selection),
반복(Iteration)을 구성하여 프로그램 흐름 복잡성을 감소
34
SE-4. 개발방법론
4) 구조적 기법의 기본원리
① 추상화(Abstraction)
② 구조화(Structuring) : Avoid “pancaked” structure
- 수평분리(Horizontal Partitioning) : factoring, 입력/자료변환/출력
- 수직분리(Vertical Partitioning) : 상위제어모듈 변경시 하위모듈로의 파급이 큼
③ 단계적 상세화(Stepwise Refinement)
④ 모듈화(Modulization) : Divide & Conquer
2. 구성요소
1) 구조적 프로그래밍
- Dijkstra에 의해 정형화
- 계층적 형식, 제한된 제어구조, 작성순서대로 PGM 실행
- 연속(Sequence) 구조
35
SE-4. 개발방법론
- 선택(Selection or IF-Then-Else) 구조
- 반복(Repetition)
2) 구조적 설계
① 개념 : 소프트웨어기능과 프로그램 구조, 모듈을 설계하기 위한 전략, 평가지침,
문서화 도구를 지원하는 체계적 설계 기법
② 기본 원칙 : 복합 설계의 기본 원칙(결합도, 응집도)
3) 구조적 분석
① 개념
- 도형중심 : DFD, DD, Minispec(구조적 문언, 의사결정 트리) 이용
- 정형화된 분석절차, 사용자요구파악, 문서화 하는 체계적 기법
36
SE-4. 개발방법론
② 기본 원칙 : 분할과 정복, 추상화, 정형화, 구조적 조직화, 하향식 기능분해
4) 구조적 언어
- Structured COBOL, Fortran 77, PL/1, Pascal
3. 구조적 기법의 설계평가 및 구조적 설계의 단점
1) 설계평가 : 결합도, 응집도
2) 단점
37
- 데이터 설계방법 결여
- 변환분석과 거래분석 측정기준 모호
- 응집도, 결합도 측정기준 모호
- 대규모,복잡한 시스템에 비효율적
SE-4. 개발방법론 - 정보공학방법론
1. 정보공학 방법론 개요
1) 정보공학 방법론의 정의
- 기업전체 또는 주요부문을 대상으로 정보시스템 계획수립, 분석, 설계, 구축에
정형화 된 기법들을 상호 연관성 있게 통합.적용하는 데이터 중심 방법론
- 기업에 필요한 정보와 업무를 총체적, 체계적, 효과적으로 파악하여 이를
모형화하고 빠른 시간 내에 정보시스템으로 발전시키기 위해 필요한 일련의 작업
절차를 자동화한 공학적인 방법론
2) 정보공학 방법론의 등장배경
① 환경의 변화
- 비즈니스의 변화 : 컴퓨터 이용 활성화, 업무 기능 및 데이터의 분업화
- 정보기술의 발달 : 하드웨어, 네트워크, R-DBMS 성능향상 등
② 구조적 방법론의 한계 : 1990년대 초 James Martin이 제창
- 데이터 모델링 방법의 미흡
- 기업 전반의 거시적 관점의 부족
- 명확한 방법론적 지침의 미흡
- 설계와 코딩을 강조
38
SE-4. 개발방법론 - 정보공학방법론
3) 정보공학 방법론의 특징
- 기업업무중심(ISP포함), 자료중심, 도형중심 접근
- 프로젝트 계획, 개발, 운영 단계의 명확한 구조기반 제시
- 정보시스템 개발의 자동화 지향
- 고객지향적, 최신 정보기술 능동적 수용
- 공학적 접근방식을 사용
- 적극적인 사용자 참여를 유도함
독립기술에
독립적
정보전략계획(ISP)
프로젝트단위
업무영역분석(BAA)
독립기술에
종속적
업무시스템설계(BSD)
2. 추진 원칙 및 추진 단계
시스템구축(SC)
1) 추진 원칙
- 프로젝트를 관리 가능한 단위로
분할, 정복
[정보공학 피라미드]
계획
- 데이터와 프로세스의 균형 유지
분석
- 모듈화, 하향식 구현
설계
- 핵심기술 : 레파지토리, CASE, 4GL, RAD
구축
[수직적 분할]
39
데이터
프로세스
상관관계
[수평적 분할]
SE-4. 개발방법론 - 정보공학방법론
2) 단계별 수행 내용
① 정보전략계획 : 경영전략, 관련조직, 업무자료 거시적 분석, 현행시스템 평가
환경분석
경영환경
분석
현황분석
비즈니스
프로세스
분석
벤치
마킹
요구사항
개선과제
정보환경
분석
정보시스템
분석
신 기업모형 정립
G
A
P
차
이
분
석
신 비즈니스
프로세스
정의
전략경영
시나리오
실행계획수립
핵심
비즈니스
프로세스
비즈니스
프로세스
개선계획
핵심전략
정보
정보
시스템
구축계획
정보시스템
구조정의
정보화
전략수립
정보관리
체계수립
② 업무영역분석
- 데이터모델링 : ERD
- 프로세스 모델링 : PHD, PDD, DFD
③ 업무시스템설계(BSD) : 업무절차 정의, Presentation 설계, 분산설계
④ 시스템 구축(SC) : 응용프로그램 작성
40
통
합
실
행
계
획
SE-4. 개발방법론 - 정보공학방법론
3. 장, 단점
1) 장점
- 경쟁우위 확보의 전략적 기회 식별 및 방안 제공
- 일관성 있고 통일된 정보시스템 구축 가능
- 시스템의 장기적인 진화, 발전 허용
- 데이터 중심으로 업무절차 및 환경변화에 유연
2) 단점
- 정보공학의 효과를 위해 장기간 필요
- 소규모의 자동화 요구 사업영역에는 시간이 오래 걸림
- 특정 사업영역으로부터 독립된 시스템 개발에는 부적합
4. 문제점 및 개선대책
1) 문제점
- 구조적 방법의 SDLC 그대로 이용
- CASE Tool 이용 쉽지 않음
- 중소 규모 프로젝트의 무리한 적용
- 복잡한 논리, 많은 산출물
2) 동향 및 개선대책
- 재사용 패러다임이 대안
- 정보공학으로 커버 못하는 영역의 확산 (인터넷, 멀티미디어)
- 기업시스템 구축은 당분간 유지
41
SE-5. 객체지향방법론
Ⅰ. 객체지향의 개요
가. 객체지향의 정의
현실세계에서 개체(Entity)를 데이터(Attribute) 과 함수(Method)를 결합시킨 형태로
표현하는 개념으로 객체간의 메시지 통신을 통해 시스템을 구현하는 개발 방법
나. 객체지향의 기본개념
1) 객체(Object) 와 메시지(Message)
- 객체란 실세계에 존재하는 사물을 표현하는 것으로 데이터와 함수로 구성
- 객체간의 통신은 메시지를 통하여 전달하며 외부객체에 의해 함수를 구현하여
객체의 데이터(Attribute)에 접근함
2) 캡슐화(Encapsulation)와 정보은닉(Information Hiding)
- 객체의 데이터와 함수를 하나로 묶고 블랙박스화 하여 외부와 접근을 제한 함
- 데이터의 임의변경을 통제하기 위해 메소드를 통해서만 접근이 가능토록 하는
것을 정보은닉 이라 함
3) 클래스(Class)와 인스턴스(Instance)
- 같은 종류 및 특성을 가진 객체들을 모아서 공통의 특성으로 분류하고 탬플릿 화
하는 것 을 클래스로 정의 함
- 클래스의 실체들로서 탬플릿화 된 클래스에서 파생된 하나의 실제 객체를
인스턴스로 정의함(예: 붕어빵 틀 과 붕어빵을 생각하라)
42
SE-5. 객체지향방법론
4) 상속(Inheritance)
- 클래스간의 IS-A 및 IS-PART-OF의 계층구조를 통하여 공통 특성을 상위
클래스로부터 물려받는 것을 상속이라 함
- 다중상속 : 두 개 이상의 상위클래스로 부터 상속으로 C++ 언어가 이를 지원함
- 단일상속 : 오직 하나의 상위클래스로 부터 상속가능하며 Java 언어지원
5) 다형성(Polymorphism)
- 하나의 함수의 이름이나 연산자가 여러 목적으로 사용될 수 있는 것
- Overriding : 상위클래스에 정의된 Method를 하위 클래스에서 재정의
- Overloading : 매개변수의 데이터 형식에 따라 같은 이름의 Method 다중정의를
하여 여러 목적으로 사용함
Ⅱ. 객체지향 설계 방법
가. 일반적 설계기법 접근
1) 전통적 개발방법의 한계
- 종래의 폭포수 모형은 공정단계가 길고 문서 작업이 많았으나, 객체지향 개발방법론
은 인간의 사고방식과 유사한 분석 및 설계가 가능함
- 개발 공정간의 전환이 자연스럽고 신속하며 절차적 프로그래밍과는 달리 객체지향
설계는 문제해결을 위한 객체에 대한 이해가 선행되어야 함
- 소프트웨어 생산기술에 대한 관심이 프로그래밍에서 분석 및 설계로 옮겨지면서
프로그램을 객체단위로 분할하고 데이터의 동적 측면을 세분화
2) 전통적 방법론 과 비교
43
SE-5. 객체지향방법론
항목
구조적 설계기법
객체지향 설계기법
접근방법
Top Down
Bottom Up
설계방향
프로세스 중심(기능위주)
데이터중심(데이터+연산)
확장성/재사용성
확장어려움/ 중복 많음
확장용이/ 재사용성 높음
DBMS/CASE지원
전통적 DB(파일 및 관계형)
/ 상위레벨지원(다이어그램)
전통적DB 와 객체지향 DB 지원/ 상
위레벨지원(다이어그램)
방법 제시 모델
Jackson, Yourdon, Warnier-orr 제
시한
모델 도구
UML(Booch, Rumbaugh - OMT,
Jacobson - OOSE)
나. 객체지향 개발 방법론 이론적 배경
1) Booch
44
- 시스템 형성 구조를 모형화하는 데이터흐름도(DFD)를 사용하여 객체를 분해하고
객체간의 인터페이스 찾아 프로그램으로 변환시키는 방법
- 요구사항분석 : 요구분석을 위한 도구로서 시스템 함수명세서, 시스템차트 지원
- 도메인 분석 : 업무영역 분석을 위해 클래스다이어그램, 상속다이어그램,
객체시나리오 다이어그램 적용
- 시스템 설계 : 클래스 분류 다이어그램 적용
2) OMT(Object Modeling Technique)
- Rumbaugh의 객체모델링 기법은 분석, 설계, 구현으로 이루어져 있음
- 분석 : 소프트웨어 구성요소들을 그래픽 표기법을 이용 객체모델링(Object
Modeling), 동적모델링(Dynamic Modeling), 기능모델링(Function Modeling)을
통해 분설모델설정
SE-5. 객체지향방법론
- 시스템 설계 : 대상문제 파악에 중점을 둔 분석 단계와는 달리 시스템 구현을 위한
문제 해결방안 모색
- 객체설계 : 분석단계의 모델을 상세화 하고 구현을 위한 기초를 제공하여 클래스, 모듈
간의 인터페이스, 알고리즘등 함수의 정의
- 구현 : 객체 설계단계의 객체, 동적, 기능모델 및 기타 문서 등을 이용 시스템 구현
(객체지향 언어의 상속 및 다형성을 적용한 문제에 대한 해결방안 모색 및 개발)
3) OOSE(Object Oriented Software Engineering)
- Jacobson의 OOSE는Use Case 다이어그램을 적용하여 분석하며 Use Case
모델은 생성되는 다른 모델의 모든 근간을 제공
- 요구모델(Requirement model) : 시스템 정의 및 요구사항 파악
- 분석 모델(Analysis model) : 시스템 구조개발에 목적을 두고 논리적구조에
중점을 두고 기능을 Use Case로 분할
- 설계모델(Design model) : 분석모델의 정제 및 형식화를 통해 설계모델 생성 및
실제 환경에서 모델개발(프로그래밍언어, DBMS, 개발도구, 컴포넌트, 제품 등)
- 구현모델(Implementation model) : 실제적인 코드를 작성- 객체지향언어권고
- 검사 모델(Test model) : 개발된 시스템의 검증- Validation & Verification
다. 객체지향 개발 단계별 주요 Activity
45
SE-5. 객체지향방법론
객체지향개발프로세스단계 (개념화->상세화->구축->전이)
활단
동계
별
주
요
시스템계획
-요구사항 정의
- 계획수립
관련산출물
분석
-개념 모델링
-시스템설계
객체,동적,기능
-상세객체모델링
-User Interface
-User Interface
분석
설계
Validation & Verification
요구사항정의서
46
설계
프로토타입
분석/설계문서
구현
-로직 코딩
- UI 구현
-시스템통합
프로그래밍 산출물
소프트웨어 개발산출물에 대한 검증 및 확인활동은 공정별로 주요활동에 차이가 있음
1) 시스템계획 단계
- 시스템에 대한 비즈니스 요구사항(Business need)에 따른 요구사항 정의
- 요구사항 목표 달성을 위한 사례를 만들고 프로젝트의 범위를 정의 하고 계획수립
- 사례는 성공기준, 위험관리에 필요한 자원평가, 중요한 일정을 보여주는 단계별
전략 및 계획을 포함
2) 분석단계
- 주어진 요구사항의 문제에 대해 객체를 찾고, 이들 객체를 분류하고, 객체간의 관계를 분석함
(일반화, 특수화, 집단화)
- 객체모델링 : 시스템의 정적인 표현으로 객체 및 클래스 정의하고 시스템에 대한
전반적인 개념적 모델링 과정 수행
- 동적 모델링 : 객체의 활동 및 흐름을 분석하며 시스템의 동적인 표현으로 객체의
상태가 업무처리 흐름에 따라 변화되는 과정 기술
- 기능모델링 : 처리 행위자, 데이터저장, 정보의 흐름에 대하여 식별된 객체들의
기능처리 표현을 목적으로 하는 과정
- User Interface : 사용자와 원활한 의사소통을 위해 요구사항 전반에 대한 개념
이해를 돕기 위한 프로토타입 개발
SE-5. 객체지향방법론
3) 설계단계
- 시스템 구조설계 : 문제영역(Problem Domain) 분석에 따라 견고한 아키텍처 기초
를 마련하여 프로젝트 위험요소를 최소화 하고, 아키텍처에 대한 결정은 전체
시스템에 대한 충분한 이해를 통하여 이루어져야 함
- 상세객체모델링 : 분석단계에서 개념모델링(객체모델링, 동적 모델링, 기능모델링)
을 구체화된 모습으로 모델링하며 주된 작업내용은 문제영역으로 부터 클래스
도출, 동작(Operation)정의, 객체간의 관계파악, 클래스간의 인터페이스 정의하고
구체화 시켜가는 과정임
- 설계 단계에서 User Interface는 실제 화면설계 이며 정적 모델링에서 도출된 객체
를 데이터베이스 설계(ERD)로 전환을 포함.
4) 구현단계
- 설계단계의 산출물을 이용하여 객체지향 언어를 적용하여 프로그래밍 수행
- 클래스 변수 및 메소드 구현, 클래스간의 인터페이스, 화면구현
- 개발자는 화이트박스테스트 및 블랙박스테스트 수행
5) Validation & Verification : 개발산출물의 확인 및 검증활동
47
SE-5. 객체지향방법론 – 통합모델링언어 UML
1. 개요
1) 정의
- 객체기술에 관한 국제표준화기구(OMG:Object Management Group)에서 인정한
객체지향 분석, 설계를 위한 통합 모델링 언어
- Jabcoson(Use Case Model), Rumbaugh(OMT), Booch(Object Design)의 통합
정의
정의
Jacobson의 Use
Case Model
분석
분석
설계
설계
Rumbaugh의
OMT
Booch의
Booch 방법론(OD)
UML
2) 방법론과 모델링언어의 차이점
- 방법론 : 생각과 행동을 구조화 하는 방법을 제공(모델을 만들때 어떻게, 언제,
무엇을, 왜라는 모든 방법을 제시하는 것)
- 모델링언어 : 모델을 단지 표현하는 것
3) 출현 배경
- 시스템대형화 -> 복잡도증가 -> 좋은 모델링 언어 필요
- 모든 영역에 있어서 어떤 구조, 즉 복잡도라도 설명할 수 있는 표기(notation)와
의미(Semantic)를 표현 가능한 모델링 언어 필요
- 객체지향 분석/설계 개발 방법론의 표준 부재
48
SE-5. 객체지향방법론 – 통합모델링언어 UML
2. 특징
- 즉시 사용가능하고 표현력이 강한 시각적 모델링 언어
- 특정 개발 프로세스, 개발규모, 언어에 관계없이 적용가능
- Framework, Pattern, CBD에 적용 가능
- 분산처리/웹/Embedded System 에 적합
- 개발자, 관리자, 공급자, 획득자에게 통일된 인터페이스 제공
- 단순 표기법이 아닌 형식과 표기에 의미를 가진 언어
- 이용시 개발자간 의사소통 원할, 객체 개발 프로세스 : 반복적 점진적 과정
- 객체지향 개발 만을 위한 것이 아니라 통합 모델링이므로 다른 모델링시 사용가능
VIEW
모델화된 시스템을 표현하기 위한 모형(4+1 View)
모델화된 시스템의 서로 다른 모형
DIAGRAM
VIEW를 표현하기 위한 방법(9개Diagram)
MODEL
ELEMENT
클래스,
객체,
메시지,
관계성으로
구성됨
49
DIAGRAM에서 사용한
개념적 모델요소
GENERAL
MECHANISM
SE-5. 객체지향방법론 – 통합모델링언어 UML
50
SE-5. 객체지향방법론 – 통합모델링언어 UML
51
SE-5. 객체지향방법론 – 통합모델링언어 UML
52
SE-5. 객체지향방법론
Ⅳ. 객체지향 프로그래밍의 한계 극복 방안
가. 소프트웨어 재사용 향상 방안
1) 소프트웨어 컴포넌트(Component) 란 ?
- 공통 또는 특정 목적을 달성하기 위해 유사한 기능을 가진 어플리케이션들의 묶음
- 표준 인터페이스 정의를 가진 컴파일된 이진형태의 코드
- 컴포넌트는 응용개발시 선택 및 조립 통하여 개발 가능한 소프트웨어 조각모음
- 적당한 크기의 묶음을 통해 개발생산성 및 확장이 용이한 형태로 시장에 유통할 수
있게 표준인터페이스를 지원하는 소프트웨어
2) 객체지향 방법과 CBD(Component Based Development) 비교
항목
53
객체지향 프로그래밍
CBD
개발패턴
-개발자들이 세부적으로 모든
프로그램을 개발하고 표준 부재
- White Box 수준의 프레임워크
-응용개발시 개발자들은 미리 제공된
컴포넌트를 업무와 연관지어 결합
시키는 일에만 주안
- 표준 인터페이스 제공
숙련도
-개발자들은 객체지향 기술의
이해수준의 고급이어야 함
- 모듈의 생산기술 수준
-컴포넌트 전문가와 컴포넌트 조립
응용개발자가 공동작업 가능
- 개발자는 컴포넌트의 이해 및 조립
개발
프로세스
-전통적 소프트웨어 개발생명주기
를 따름
- 단계별 반복(literation)없음
-각 공정별로 반복적인 프로세스가
있어 미니프로젝트가 가능함
(literation)
상호
운용성
-서로 다른 유형간의 상호운영이
어려우며 특정 목적의 환경으로
개발될 가능성이 있음
-다른 객체와 컴포넌트를 연결시켜
하나의 대형 객체를 생성가능
- 표준화된 기술 적용
SE-5. 객체지향방법론
3) 소프트웨어 재사용 향상을 위한 MVC 모델
MVC(Model View Controller)은 웹 어플리케이션 환경에서 개발 소프트웨어의
재사용 및 유지보수의 효율성 향상을 위해 시스템구조를 표현부(View), 데이터 및
비즈니스 Logic 부(Model), 제어부(Controller)로 구분하여 소프트웨어를 설계하고
구현하는 방법 임
득데
이
터
획
벤변
트경
이
View
(사용자 화면)
구 분
Model
View
Control
54
Model
(데이터 및 로직)
사용자 요구
View 선택
제데
어이
터
변
경
Controller
(흐름제어)
내 용 설 명
• 데이터 조작 및 변경처리, 업무처리 Logic 등의 기능을 구현
예) DB 연결및 트랜잭션 처리
• User Interface 화면설계로 Boundary Object 영역
예) JSP(Java Server Page) /서블릿(Servlet)
• Model 과 View 간의 흐름 제어처리
예) 사용자 요구에 대한 화면선택 및 필요시 Model에 데이터 변경처리
SE-5. 객체지향방법론
Ⅵ . 객체지향 기술의 향후 전망
가. 방법론 측면
- 소프트웨어 개발이 복잡하고 다양해짐에 따라 프로토타입을 개발하여 위험요인을
사전에 제거하는 추가 요구 활동이 필요하며 아직 성숙되지 않은 개발방법론이나
생산성을 높일 수 있는 방법론임
- 웹 개발환경이 보편화 됨에 따라 유사 반복내용에 대한 디자인 패턴 개발 적용 및
소프트웨어 시스템 관점으로 접근하고 있음
- 개발의 생산성을 위한 CASE 도구 및 Repository 를 환경을 토대로 버전 및
형상관리를 위한 자동화 노력이 추세임
나. 기술적 측면
- 최근 프로그래밍 언어가 분산객체 환경을 지원하는 개념을 지원하는 웹 서비스가
가능한 플랫폼이 지원 되고 있으며 데이터베이스, 운영체제, 네트워크등 정보기술
분야에 신기술 적용을 위한 연구, 개발이 활발함.
- 객체지향 기술은 기업 비즈니스 또는 산업차원에서 소프트웨어 재사용성을 높이기
위해 CBD 프로젝트가 활성화 될 전망임
55
SE-6. CBD(Component Based Development)
Ⅰ. 컴포넌트 소프트웨어 개요
가. 컴포넌트 개념
1) 정의 : 독립적으로 실행가능하며 표준 인터페이스를 갖추고 소프트웨어의 대체가능성,
재 사용성, 기능적 독립성을 갖춘 소프트웨어 집합
2) 컴포넌트의 특징
- 컴포넌트는 독립적인 단위의 소프트웨어 모듈이며 인터페이스를 통해 접근 가능
- 컴포넌트는 구현(Implementation), 명세화(Specification), 표준(Standard), 패키지
(Package), 그리고 독립적인 배포(Deployment)가 가능함
- 하나 이상의 클래스들로 구성될 수 있으며 4단계 크기 수준으로 구분 가능 함
분산 컴포넌트
56
EJB, CORBA, COM+ 등 분산객체환경 지원 컴포넌트
비즈니스
컴포넌트
물리적으로 배포할 수 있는 독립된 하나의 비즈니스 개념을 구현한 컴포넌
트
확장 비즈니스 컴
포넌트
확장을 고려하여 설계된 Business Component 의 집합으로 그룹형태로 재사
용이 가능한 항목의 집합체
시스템
컴포넌트
비즈니스 가치를 제공하기 위해 같은 일을 하는 시스템 수준의 컴포넌트들
의 집합
SE-6. CBD(Component Based Development)
3) 컴포넌트 재사용의 장점
- 소프트웨어 개발기간 단축, 개발비용 감소, 생산성 증대 효과를 얻을 수 있음
- 테스트된 컴포넌트 사용으로 리스크 감소, 비즈니스 규칙을 적용한 일관성 확대
나. CBD 정의 및 필요성
1) CBD의 정의
- 테스트가 완료된 소프트웨어 컴포넌트를 조립하여 사용자의 요구에 맞는 응용
소프트웨어를 만드는 방법으로 전통적 개발방법론 개념을 수용하면서 새로운 웹 기반
개방형 아키텍처를 수용하려는 소프트웨어 공학적인 접근 개발방법
- 기존 객체지향 분석/설계에서 상속을 제외하고 인터페이스 중심의 접근을 강화한
재사용 프레임웍을 수용하는 방법론 임
CBD = CD + CBSD (컴포넌트 제작 + 컴포넌트 적용 응용개발)
•
CD : Component Development
•
CBSD : Component -Based Software Development
57
SE-6. CBD(Component Based Development)
2) CBD의 필요성
- 비즈니스 라이프사이클 타임에 적절히 대응할 필요가 있음 (Time to Market)
- 빠르게 변화하는 비즈니스 환경에 능동적으로 대처(flexibility)
- 네트워킹 및 통합을 위해 개방형 표준에 따른 정보시스템간 상호 운용성 필요
방법론 중심의 개발
접근
구조적 방법
(프로그램중심)
SW 개발 패러다임의
변화
정보공학 방법
(데이터 중심)
작다
비즈니스측면 SW 접
근
객체지향 방법
(프로그램+데이터)
소프트웨어 재사용 크기
CBD 방법
(아키텍처 중심)
크다
Ⅱ. 컴포넌트기반 개발 방법론
가. CBD 방법론의 특징
1) 쓰임새주도 (Use Case Driven)
- 프로젝트 이해당사자간 원활한 의사소통을 위해 UML(Unified Modeling Language)을 적용하며,
비즈니스 영역별로 현실에 맞게 쓰임새중심의 분석 및 설계단계 지원
2) 아키텍처 중심(Architecture Centric)
- 소프트웨어의 재사용 및 개발의 생산성을 위해 프로젝트 시작과 함께 목적에 맞게 체계적인 아키텍처
계획을 수립하고 표준화 및 지속적인 개선노력을 병행함, 즉 선택하고(Select), 적합화 시키고(Adapt),
마무리하여 개선시킴(Finalize & Evolution)
- 소프트웨어의 가시성(Visibility), 적응성(Adaptability)을 위해 컴포넌트 중심으로 웹기반 다 계층
아키텍처 등 다양한 환경에 적응 함
58
SE-6. CBD(Component Based Development)
3) 반복과 점진(iteration & inclement)
- 프로젝트 위험을 감소하기 위해 반복계획 수립시 목적을 명확히 하여 위험을 도출하며
계획대로 실행 되었는지를 사용자 참여 하에 평가가 이루어짐
나. 객체지향방법 과 비교
59
구분
CBD 방법론
객체지향 방법론
개발프로세스
소규모 단위의 프로젝트로
나누어 반복 과 점진 수행 (iteration &
inclement)
전통적 SDLC를 따르며
개발 품질향상 을 위해 Prototype 수
행 가능
아키텍처 측면
프로젝트 시작과 함께 계획 및 표준화
수립 후 지속적 개선
명확한 아키텍처 제시 및
표준화가 미흡 함
응용개발 기술
컴포넌트 단위의 블랙박스 상태에서
표준 인터페이스 적용
(객체지향의 상속개념 없음)
객체지향 언어 적용 중심 프로그래
밍(클래스 수준의 상속, 다형성 접근)
SW 공학 측면
비즈니스 중점의 소프트웨어 재사용
을 통한 생산성 향상
데이터 및 프로세스 융합을 통한 개
발 패러다임 변화
SE-6. CBD(Component Based Development)
Ⅲ. CBD 도입방안
가. CBD 도입전략
- 가능하면 많은 기능성의 서비스를 외부로부터 공급 받도록 하고 시험 완료된 검증된
컴포넌트로 부터 시스템을 구성하고 기존의 설계기법들을 최대한 활용하는 비즈니스
측면에서 재사용 전략 수립
- 기업 개발조직의 성숙도 평가에 따른 CBD 수준 조정 및 목적공유를 통한 품질정책
- 표준화 기술을 통해 하나의 컴포넌트가 다양한 환경에서 활용될 수 있도록 상호운용성
에 대한고려
나. CBD 성공요인
-
프로세스 : CBD를 위한 프로세스를 구성하는 활동들과 역할을 명확하게 정의해야 함
자동화 : 프로세스를 적극적으로 지원하는 컴포넌트 재사용과정의 자동화 도구
컴포넌트 : 활용 가능한 시험을 거친 검증된 컴포넌트 카탈로그 확보
접근방법 : CBD를 적용하기위해 기반구조 및 조직문화의 충분한 이해를 전제로 추진
접근방법
프로세스
(재사용활동 및 역할)
자동화
자동화 도구- CASE
(재사용서비스)
표준화
생산/사용
컴포넌트
유통시장
60
내부컴포넌트
CBD성공 요인들간의 연관성 개념도
SE-6. CBD(Component Based Development)
다. CBD 수행 및 관리방안
1) 역할과 조직(Role & Organization)
- 솔루션을 개발하는 팀, 컴포넌트를 개발하는 팀, 그리고 이를 지원하는 지원하는
팀으로 역할 분담이 이루어지도록 함
- 프로젝트 수행전략과 기술적, 문화적 환경에 따라 추진조직과 프로젝트 주체 결정
자체 주도형
사업관리를 독자적으로 수행 하며 조직 성숙도에 따라 성패좌우
일괄 발주형
사업관리를 SI 수주업체에게 위임, SI선정결과에 따라 성패좌우
관리 분산형
자체 주도형과 일괄 발주형 의 중간으로 사업관리만 위임
2) 표준 및 방법론( Standard & Methodology )
- 여러 부문의 표준이 존재할 수 있으며 컴포넌트 실행환경 표준(.NET, J2EE, CCM),
개발표준(UML기반 컴포넌트 식별), 프로세스표준(RUP, 마르미-III)의 정립이 필요
3) 아키텍처(Architecture) : 소프트웨어 구조를 서브시스템으로 나누고 인터페이스를
통해 연결하여 상호운용성 측면의 재사용 품질 향상 방안 수립 및 시행
4) 정책(Policy) : 컴포넌트 활성화를 위한 제도적장치(규정,홍보,인센티브제도)마련하고
재사용 및 유지보수성의 빠른 개발효과를 얻을 수 있어야 함
61
SE-6. CBD(Component Based Development)
Ⅳ. CBD 프로젝트 실무적용 방안
가. CBD 프로젝트 사전준비
1) 프로젝트관련 조직의 성숙도 진단
- 조직의 소프트웨어 재사용 및 관리능력에 대한 전문가 그룹의 진단을 통해 접근수준을 정의하며
초기에는 컴포넌트기반 프로그래밍 기술부터 시작해서 아키텍처 중심의 컴포넌트기반 분석, 전사적
차원의 비즈니스 컴포넌트로 점차 확대 해 나감
2) 프로젝트 대상업무 선정 및 교육
- 대상업무 선정은 요구사항 변화가 많거나 변화에 즉시 대응해야 하는 업무를 고려 함
- 업무지식의 전문가 확보 및 프로젝트 이해 당사자들에 대한 CBD 관련 UML, 아키텍처, 방법론,
자동화도구(CASE) 등 사전교육이 이행되어야 함
나. CBD 공정 및 활동
작업단계
62
공정의 흐름
요구사항
분석
현황평가 및 도메인분석 -> 요구사항정의 -> 시스템 구조정의(Architecture) ->
개발계획수립
분석
반복(iteration)계획수립 -> 유즈케이스 모델링 -> UI(화면)프로토타이핑, 유즈케
이스분석(분석 정적/동적 모델)
설계
UI(화면)설계, 컴포넌트 정의 -> 컴포넌트 설계 -> 구현모델설계 -> 컨버전 설계
개발
코딩 및 디버깅
구현
배치계획(Deployment) -> 테스트계획/실시 -> 시스템 릴리즈
-> 사용자 교육
SE-6. CBD(Component Based Development)
1) 분석 단계 활동
- 해당 Iteration에 대한 상세 계획을 수립
- 구현할 시스템에서 제공해야 할 기능을 고객의 사용관점에서 정의
- 핵심 기능에 대한 UI프로토타입을 통해 고객이 선호하는 UI방식과 UI Design요소검증
- 유즈케이스를 지원하기 위해 요구되는 비즈니스 엔티티와 사용자와 시스템간의 상호
작용 체계를 정의하고 이들간의 일관성을 검증
2) 설계 단계 활동
- 시스템에 구현될 화면 레이아웃을 정의하고 화면간의 Navigation 및 파라미터 전달
Signature를 정의, 컴포넌트 추출기법을 사용한 분석을 토대로 컴포넌트 식별하고,
컴포넌트간 연관관계를 정의하여 도출된 컴포넌트의 재사용 가능성 분석
- 상세 클래스 및 시퀀스 다이어그램 작성을 통해 개발할 컴포넌트를 구성하는 각 객체
의 속성 및 오퍼레이션과 객체간 메시지 전달흐름을 상세 설계
- 기존 Component를 재사용하기 위한 명세와 재사용에 필요한 Adaptor, Wrapper 명세
3) 개발 및 구현 단계 활동
- 분석/설계단계의 모델을 플랫폼 및 개발환경에 맞게 프로그래밍 함
- 컴포넌트 명세, 인터페이스 명세, DB설계 내용을 플랫폼에 매칭시키고 배포단위를
정의하고 물리적으로 구현함
다. 웹 CBD 컴포넌트 실행 환경
1) 계층적 아키텍처(Layered Architecture) 구성으로 영역별 변화에 대한 독립성이 유지
되도록 컴포넌트 실행환경을 구성함
63
SE-6. CBD(Component Based Development)
Presentation
(HTML, css,
Images, js,
etc)
Server
Side
Client
(JSP/Action)
Business
Logic
(Component)
Data Access
(Persistence
Platform)
2) 플랫폼 유형
- EJB(Enterprise Java Beans) : SUN사의 J2EE 명세에서 비즈니스 로직 영역에 대한
컴포넌트 아키텍처 및 실행환경 지원
- COM+ : 마이크로 소프트사의 분산 객체환경에서 컴포넌트 실행환경 지원
라. CBD 프로젝트의 고려사항
64
1) 프로젝트 관리측면
- 반복계획 수립은 명확한 목적 과 평가가 이루어지도록 체크리스트를 작성하고
반복횟수는 프로젝트 상황을 고려하여야 함(많은 반복계획은 가능한 제한할 것)
- UML 다이어그램 적용을 통한 문서들의 가독성 향상방안 노력과 함께, 아키텍처는
표준 또는 유사한 프로젝트 플랫폼 모델 을 참조하여 프로젝트 환경에 최적화 해야함
- 조직의 체계화 전략과 비전을 수립하고 단계별 프로젝트관리 목표를 가지고 진행
2) 개발 기술측면
- 공통계층의 컴포넌트 식별은 공통 유즈케이스, 배타적 공통클래스에 대해
클러스터링 과정 반복 수행
- 객체지향 설계에서 응용 Logic 재사용을 위한 컴포넌트 설계는 표현계층, 응용계층,
데이터계층이 일관성 있게 구성 할 것을 권고하며 기존 관계형 데이터베이스 설계로
매핑(Mapping)관계에서 Trade Off 발생 가능성을 고려해야 함
SE-7. 테스트단계
Ⅰ. 소프트웨어 테스트의 개요
가. 소프트웨어 테스트의 정의
- 노출되지 않은 숨어있는 결함(Fault)을 찾기 위해 소프트웨어를 작동시키는 일련의 행위
와 절차로 오류 발견을 목적으로 프로그램을 실행하여 품질을 평가하는 과정
- 디버깅(Debugging) : 이미 노출된 소프트웨어의 결함을 없애는 작업
나. 소프트웨어 테스트의 목표
- 프로그램에 잠재된 오류의 발견
- 기술적인 기능 및 성능의 확인
- 사용자 요구만족도, 제품신뢰도 향상
다. 소프트웨어 테스트의 특징
- 성공적인 테스트는 무결점이 아닌 결함을 찾는데 있음
- 테스트 케이스 선정, 테스트 계획 수립에 따라 영향(미발견 결함을 발견하게 해줄 확률)
- 테스트 케이스는 기대되는 표준결과를 포함하여 예측오류, 기대되지 않는 결함이 있다는
가정 하에 테스트계획 수립
- 개발자가 자기 프로그램을 직접 테스트하지 않음 (디버깅 수행)
- 능력 있는 테스트 수행자는 성공적이고 효율적으로 시험을 수행
라. 소프트웨어 개발 단계별 테스트
65
SE-7. 테스트단계
사용자 환경
문제
정의
설치 테스트
대칭관계
시스템 정의
분석
인수 테스트
요구 분석
시스템테스트
구조 설계
설계
통합 테스트
상세 설계
코딩
구현
소프트
웨어 테스트
모듈 테스트
디버깅
II . 소프트웨어 테스트 단계
가. 단위 테스트
내용
-설계의 최소 단위인
모듈을 TEST함
- 화이트박스 기법 이용
나. 통합 테스트
66
테스트 유형
인터페이스
다른 모듈과의 데이터 인터페이스에 대하여 TEST
자료구조
모듈 내의 자료 구조상 오류가 없는지를 TEST
수행경로
구조 및 루프 TEST 등에 의해 논리 경로 TEST
오류처리
각종 오류들이 모듈에 의해 적절히 처리여부 TEST
경계
오류가 발생하기 쉬운 경계 값으로 TEST 사례
SE-7. 테스트단계
내용
- 단위 TEST을
거친 모듈들의
인터페이스
(Interface)에
관한 오류발견
이 목적
테스트 유형
하향식(Topdown)
- 모듈간의 체
계적인 조합
과정
- 모듈들을
체계적으로
조합시킬
목적으로
모듈간의
인터페이스와
관련된 결함
들을 TEST에
의해 발견하
고 제거하는
작업
상향식
(Bottom-up)
샌드위치형
67
상위 모듈을 하위 모듈보다 먼저 TEST
중요 모듈을 가능한 먼저 TEST
stub(dummy module) 모듈 사용
4GL과 같은 Menu-Driven 화면구성 방식 사용
회귀 TEST(Regression test)
수정에 의해 새로운 결함 발생의 가능성에 대비하여,
이미 실시했던 TEST 사례들의 전부 혹은 일부를 재 시도
특성
실제 적용 가능한 테스트, menu 방식 소프트웨어 개발
에 적용, stub module 또는 대응모듈 요구
장점
실제 응용가능, 테스트 사례 풍부
단점
stub module 구현 곤란
-
하위계층 모듈을 상위계층모듈보다 먼저 TEST
입/출력과 관련된 모듈을 먼저 TEST
TEST DRIVEN 작성 필요
소프트웨어 계층 구조의 최하위부터 점진적으로
모듈들을 통합시켜 나아가는 방식
특성
대규모 시스템에 적용, 모듈의 신뢰성 향상 가능, 최종
결과 산출 곤란
장점
대형시스템 테스트에 적용
단점
Cluster 분류 곤란
- 하향식과 상향식 통합 방식을 절충한 방식
- 우선적으로 통합을 시도할 중요 모듈들의 선정 후,
그 모듈을 중심으로 통합 수행
SE-7. 테스트단계
다. 시스템 테스트
내용
사용자의
신뢰성을
확보하기
위하여
컴퓨터,
네트워크
제반 모든 사항
에 관계된 테스
트
라. 인수/설치 테스트
68
테스트 유형
회복
- 소프트웨어가 다양한 방법으로 실패하도록 유도하고 회복이 적절
하게 수행되는지를 검증하는 TEST
- 회복이 시스템에 의해 자동으로 수행되면 재초기화, 데이터 회복,
재시작 방법 등에 의해 정상적으로 회복되는지를 평가
- 운영체제, DBMS, 통신용 소프트웨어 등의 완전성 TEST
안전
- 시스템 내의 보호 기능이 불법적인 침투로부터 시스템을 보호하는지
에 대한 검증 TEST
- 해커 등의 불법적 침입자로부터 시스템의 보호 목적으로 시행
강도
- 비정상적인 값, 양, 빈도의 자원의 입력에 대한 정상 수행상태를
TEST
- 소프트웨어에게 다양한 스트레스를 가해 보는 TEST
- 민감도 TEST(Sensitivity Test) : 유효한 입력 유형 중에서 불안정하게
하거나 부적절한 결과를 일으키는 데이터의 조합을 밝히도록 함
성능
- 통합시스템의 전후관계에서 소프트웨어의 실행시간 TEST
- 소프트웨어의 효율성을 진단하는 TEST
- 자원 이용, 처리시간, 요구된 응답 반응 등 성능 TEST
SE-7. 테스트단계
라. 인수/설치 테스트
구분
내용
인수
- 사용자측 관점에서 소
프트웨어가 요구 사항
을 충족시키는 지를 평
가
- 소프트웨어가 고객의
합리적인 기대에 따라
제 기능을 발휘하는지
여부를 TEST
설치
69
- 소프트웨어를 사용자
환경에 설치하는 과정
중에 나타날 수 있는 결
함을 발견할 목적으로
수행
테스트 유형
알파
특정 사용자들에 의해 개발자 관점에서 수행되며, 개발자는 사용상
의 문제를 기록하여 반영되도록 하는 TEST
베타
선정된 다수의 사용자들이 자신들의 사용환경에서 일정 기간 동안
사용해 보면서 문제점이나 개선 사항 등을 기록하고 개발 조직에게
통보하여 반영되도록 하는 TEST
하드웨어/소프트웨어 구성, 파일분배 적재, 타 소프트웨어와 연결
SE-8. 테스트방법
III. 소프트웨어 테스트 방법의 유형
Black Box Test
White Box Test
- 원시 코드는 보지 않은 채 목적 코드를 수행시켜 결함
-논리적 경로를 파악하거나 경로의 복잡도를 이용
을 발견
- 시험 영역 (문장 영역, 물리적 경로 영역, 논리적 경로)
- 데이터 위주(Data-Driven) 혹은 입출력 위주(IO-Driven)
- 대상 결함 (부정확하거나 빠진 결함, 인터페이스 결함,
자료 구조상의 결함, 성능 결함, 시작과 종결상의 결함)
Ⅳ. 블랙박스 테스트(Black Box Test)
가. 블랙박스 테스트의 정의
- 블랙박스 시험은 원시코드는 보지 않은 채 목적코드를 수행시켜가면서 결함을 발견할
수 있는 시험사례를 준비하여 시험에 임하는 방식으로 데이터 위주 또는 입출력 위주
시험이라 함
- Dynamic Test
나. 블랙박스 테스트의 목적
- 부정확하거나 빠진 결함의 발견
- 인터페이스 결함 및 자료구조사의 결함 발견
- 성능 결함과 시작, 종결상의 결함 발견
70
SE-8. 테스트방법
다. 블랙박스 테스트의 기법
1) 동등분할 기법
- 다양한 입력 조건들을 갖춘 시험사례의 유형들로 분할
- 각 시험사례 유형마다 최소의 시험사례를 준비
- 시험 사례를 줄이기 위해 하나의 시험 사례가 비슷한 다른 유형의 시험 값에 대표될 수 있는 것으로 선정
2) 경계값 분석 기법
- 입력조건의 경계치에 치중하며 출력유형도 고려하여 시행
- 경계값을 기준으로 경계값 내의 것, 경계값, 경계값 밖의 것으로 시험 사례 선정
3) 원인-결과 그래프 기법
- 입력 데이터 간의 관계가 출력에 영향을 미치는 상황을 체계적으로 분석하여 효율성 높은 시험사례를
발견하고자 하는 기법
- 인과 관계 그래프를 이용하여, 명세서의 불완전성 및 애매모호함을 추출
4) 결함예측 기법
- 시험자의 감각과 경험으로 결함을 찾아보는 방식
Ⅴ. 화이트박스 테스트(White Box Test)
가. 화이트박스 테스트의 정의
- 프로그램상에 허용되는 모든 논리적 경로를 파악하거나 경로들의 복잡도를 계산하여 시험사례를 만들어
시험을 수행하는 기법
- Static Test
71
SE-8. 테스트방법
나. 화이트박스 테스트에서의 시험영역
- 문장 영역 : 각 원시코드 라인이 한 번이라도 수행되도록 설계
- 물리적 경로영역 : 프로그램의 모든 경로가 한 번이라도 수행되도록 설계
- 논리적 경로영역 : 물리적 경로의 순서가 결과에 영향을 미친다는 가정 하에 논리적
경로들이 수행되도록 설계
다. 화이트박스 테스트 테스트 조건
- 프로그램 내의 소스들은 적어도 한번은 수행 되어야 함
- 프로그램내의 모든 결정(Decision)이 각각 참, 거짓 값을 적어도 한번은 가져야 함
(ex: A=2 or X>1 일 경우 참을 만족하는 분기라면, A=2의 조건 하에서는 X값에 관계
없이 모든 값이 참이 됨)
- 결정내의 모든 조건들은 각각 참, 거짓 값을 적어도 한번은 가져야 함
(ex : A > 1 , A ? 1)
- 결정내의 모든 조건들은 참, 거짓 값을 적어도 한번은 가지며, 또한 결정 자체도 참,
거짓을 적어도 한번은 가질 수 있어야 함
- 프로그램내의 모든 수행 가능한 경로는 모두 수행 되어야 함
라. 화이트박스 테스트의 종류
1) 구조시험
- 프로그램의 논리적 복잡도를 측정 후 이 척도에 따라 수행시킬 기본 경로들의 집합 정의
- 시험영역을 현실적으로 최대화 시켜주며 독립경로 발견의 자동화가 강점
2) 루프(Loop)시험 기법
- 프로그램의 루프구조에 국한해서 실시하는 시험 기법
- 단순한 루프, 중첩 루프, 연결 루프, 비구조적 루프
72
SE-8. 테스트방법
Ⅵ. 소프트웨어 테스트 고려사항
가. 소프트웨어 테스트 유의사항
-
테스트 모형 설계 시 예상출력 정의
프로그래머는 자신의 프로그램 TEST 금지
테스트 결과의 철저한 분석의 요구
부당하거나 예기치 않은 입력도 테스트 등
TEST CASE 유지(재사용) 등
나. 소프트웨어 테스트와 유지보수 비용 관계
하나의 결함을 갖
고 수정하는
비용
( 고정비용
)
분석 /설계 /구현
73
변동비용
시험
유지보수
시간
SE-8. 테스트방법
Ⅶ . 소프트웨어 테스트 전망
가. 테스트 전략
개발자
사용자
Debugging
시험자
소프트웨어
Verification
( 검증 )
Validation
( 확인 )
품질보증
사용자
( Workthrough
Inspection,Review,
Verification,Validation)
품질보증요원
나. 테스트 발전방향
- S/W 테스트는 개발 및 시스템 구축의 완전성을 위한 중요 요소
- BLACK BOX 및 WHITE BOX 테스트 방법을 개발 과정 중 보편적 사용
- 효율적인 S/W TEST 위해 QA Check List Map을 이용, 요구대비 테스트 목표달성 여부 분석, 최적 테스트
케이스/ 테스트 계획 준비
- 사용자 참여하여 테스트 결과를 철저히 검토,기록,수정하고 개선사항을 반영
- 자동 테스트 케이스 생성 및 테스트 실시와 같은 선진 기법 필요
- 국가적으로 테스트 툴에 대한 연구개발 및 현장 도입이 필요
74
SE-9. 유지보수
Ⅰ. 유지보수의 개요
가. 유지보수의 정의
- SDLC(Software Develop Life Cycle)의 마지막 단계로 소프트웨어의 생명을 연장시키는
작업
- 소프트웨어 공학 재검토 과정의 각 단계에서 고려
- 오류의 수정, 원래의 요구를 정정, 기능과 수행력을 증진시키는 일련의 작업
- 소프트웨어가 인도된 후 결함의 제거, 성능향상, 변화된 환경에 적응토록 수정
- 소프트웨어 유지보수 및 운영 전담조직이 필요 (Maintenance-bound)
- 개발은 제작중심의 작업이며 유지보수는 운영중심의 작업
- 소프트웨어가 인수되어 설치된 후 일어나는 모든 소프트웨어 공학적 작업
나. 유지보수의 필요성
- 유지보수 비용이 전체 비용의 70~80%를 차지
- 소프트웨어 인력이 신규 프로젝트보다 유지보수 업무에 투입되는 낭비 요소 발생
- 유지보수의 비효율성으로 인해 패키지 소프트웨어의 도입 확산
- 프로젝트보다 기존 소프트웨어 개선에 더 많은 인력과 비용 소요
- 소프트웨어기능의 복잡화에 따른 난해함으로 문서화 등의 관리업무가 증가
- 개발은 1-2년 정도지만 유지보수는 5년 또는 10년 정도로 장기
- 용역개발보다 패키지의 선택이 확산됨에 따라 유지보수 부문이 증가 예상
75
SE-9. 유지보수
다. 유지보수의 목표
- 소프트웨어의 성능 개선
- 소프트웨어의 하자 보수
- 새로운 환경에서 동작할 수 있도록 이식 및 수정
- 예방적 조치
분류기준
사유
교정, 적응, 완전 유지보수
시간
계획, 예방, 응급, 지연 유지보수
대상
데이터/프로그램, 문서화, 시스템 유지보수
II. 유지보수의 구성
가. 유지보수 유형
76
유지보수의 종류
SE-9. 유지보수
형태
정정 유지보수
(Corrective
Maintenance)
- 처리오류 : 비정상적인 프로그램 중단, 입력 데이터 검증 누락,
출력 프로그램의 부정확
- 수행오류 : 느린 응답시간 또는 부적절한 트랜잭션 처리율
- 구현오류 : 프로그램 설계에 있어서 표준, 범칙 또는 불 일관성/
불 완전성
적응 유지보수
(Adaptive
Maintenance)
- 프로그램 환경 변화에 소프트웨어를 적응시키도록 수행
- 데이터 환경의 변화:데이터 매체의 변경, 일발 파일에서 데이터
베이스 관리시스템의 변환
- 처리환경의 변화 : 새로운 하드웨어 플랫폼 또는 운영체제로 이전
완전화 유지보수
(Perfective
Maintenance)
77
내용
- 수행력 향상, 프로그램 특성을 변경 또는 첨가, 또는 프로그램의
장래 유지보수성을 향상시키기 위해 수행
SE-9. 유지보수
나. 유지보수 활동
활동
문서 유지 관리
품질 보증
내용
분석/설계 산출물, MRF, CR, SCR 등
소프트웨어 유지보수 시기, 구성 계획 등의 적절성과 유지보수
내용의 관련 문서와 일치성 확보
사용자
요청서
기각
분석가
승인/결과
통보
승인요청
유지보수 관리위원회
유지보수결과
지시
유지보수자
78
SE-9. 유지보수
Ⅲ. 유지보수 프로세스
가. 유지보수 순서
소프트웨어
이해
유지보수
요구사항
분석
소프트웨어
설계
소스코드
수정
단계별
테스트
유지보수
결과 검토
나. 유지보수 추진 단계
79
단계
주요활동
활동주체
요청
MRF(Modification Request Form)작성
CR(Change Request)작성
사용자
분석
유지보수의 유형 분류, 심각성 판단
유지보수의 내용 분석, 영향도 분석
유지보수 우선순위 결정
분석가
승인
분석 내용에 따라 유지보수 여부 승인
유지보수 실행에 대한 승인
유지보수
관리위원회
실행
유지보수 대상에 대한 유지보수 실행
소프트웨어 번경 보고서(SCR) 작성
관련문서 변경
유지보수 담당
SE-9. 유지보수
다. 유지보수 발생 요인 분석
1) 소프트웨어의 유기적인 측면
- 소프트웨어 시스템에 대한 사용자 참여 및 만족도 미흡
- 개발된 시스템의 문서화, 유연성, 신뢰성 저하
2) 개발 환경적 측면
- 유지보수 보다는 신규 프로젝트에 치중
- 표준화된 방법론 및 개발 도구 적용의 부재
- 분석 설계 시 유지보수성 및 재 사용성 요인 반영의 미흡
Ⅳ. 유지보수 문제점 및 해결방안
문제점
- 유지보수에 따른 코드, 자료, 문서
상 불일치 발생
- 시스템의 신뢰성 저하 발생
- 유지보수 비용 및 인력의 증가
- 유지보수 절차, 조직 및 운영 방법
이 비체계적
80
해결방안
- 표준화된 개발방법론 및 개발도구 적용
- 소프트웨어 재공학 도구 활용 : 분석,
재구조화, 역공학
- 유지보수 요인에 대한 예방활동 실시
- 변경관리, 형상관리 등 적절한 프로젝트
관리기법 도입
SE-10. 위험관리
Ⅰ. 위험관리의 개요
가. 위험관리의 정의
- 경영 목적을 달성하는데 있어서 조직의 정보자원에 대한 취약성과 위협을 식별하고,
정보자원의 조직에서의 가치를 기반으로 위험을 수용 가능한 수준으로 감소시키기 위해
서 취해야 할 대응방안을 결정하는 프로세스이다.
- 총위험 = 위협 x 취약성 x 자산의 가치
나. 위험관리의 필요성
- 급속한 기술발전과 복잡도 증가로 인해 위험도 증가
- 프로젝트 수행과 정보시스템 운영을 위한 운영안 확보
다. 위험관리의 목표
- 범위, 품질, 시간, 원가에 대한 프로젝트 목표에 영향을 주는 요소들을 구체적으로 식별
- 각 요소들에 대한 가능한 영향을 계량화
- 프로젝트의 통제 불가능한 것을 위한 기준선(Baseline) 설정
- 프로젝트의 통제 가능 부분에 대한 활동을 통해 영향(Impact) 완화
- 프로젝트 수행 중 발생하는 위험요소를 사전에 감지하고 제거
- 프로젝트의 정상적인 수행을 보장하기 위한 사전활동
- 위험요소를 관리/제거를 통하여 프로젝트의 성공적 수행의 기반구축
- 프로젝트통제의 상위개념으로 우선순위가 높은 활동
- 프로젝트의 불확실성을 지속적으로 감소
81
SE-10. 위험관리
라. 프로젝트 관리에서의 위험관리 영역
범위
품질
통합
프로젝트 위험
소통
시간
인력
원가
조달
II. 위험관리의 구성
가. 위험관리의 프로세스
단계
인식
활동 내용
정의
구현방법
정의
분석
구현방법
평가
정의
구현방법
82
프로젝트와 관련된 불확실한 사항들을 측정가능하고, 서술 가능한 가시적
인 위험으로 변환하는 과정
체크리스트, EWS(Early Warning Signal)
식별된 위험에 대해 상세한 수준으로 정리하는 과정(의사결정이 가능한
(관리 가능한) 수준으로 위험 정리)
파급효과, 문제시 될 가능성, 대처시기 등 고려
위험 제거/감소를 위한 활동의 진행상황을 파악하기 위한 활동
위험 = 발생가능성 * 영향력으로 위험을 평가
SE-10. 위험관리
단계
활동 내용
정의
계획
구현방법
정의
통제
구현방법
위험의 제거/감소를 위해 필요한 실행항목을 도출하는 과정, 누가 무엇을
어떻게 해결해야 하는지를 도출하는 과정
위험발생시 결함보고, 의사결정요청, 변경요청 등 수행계획
위험 진행상황 분석에 근거한 의사결정 단계
위험통제위험 표에 의거 통제를 수행
나. 위험관리 대상
위험요소
83
위험관리 대응조치
인력 부족
유능한 인력모집 또는 사전 확보, 팀 구성, 교육 수행
비현실적 일정/예산
더 세부적인 비용, 일정 예측, 원가 분석
잘못된 SW 개발
사용자 회람, 프로토타이핑, 사용자 지침서의 조기 작성,
조직분석, 직능분석
잘못된 UI 개발
프로토타이핑, 시나리오 작성, 태스크 분석, 사용자 분류(기능, 스타일, 업
무)
계속적인 요구 변경
최대 변경 상한선, 점증적 개발, 다음 버전까지 변경 연기
실시간 성능 빈약
시뮬레이션, 벤치마킹, 모델링, 프로토타이핑, 튜닝
기술적 취약
기술 분석, 프로토타이핑 등
SE-10. 위험관리
III. 위험관리 구현방안
가. 위험관리 절차
단계
범위설정
위험분석 범위 설정
위험분석
위험요소 식별, 추출, 확인, 영향분석 및 관계분석, 자료수집
위험평가
위험 우선도 정의 (Accept 최소 Risk 등의 분류)
위험관리계획
위험관리를 위한 계획
위험 통제 및 대응책 구현
위험요소의 제거 및 절감, 해결
준수시험 및 검증, 사후관리
준거성 시험과 위험감시
나. 위험분석 모델
84
내용
SE-10. 위험관리
자산분석
세부자산 리스트 도출
자산 그룹화
자산가치 평가기준수립 자산
가치평가
위험 분석
위협분석
위험
분석
범위
설정
위험
분석
관련
자료
수집
자료
취합
및
분석
자산별 위협의 식별
위협평가
취약성 분석
관리적 취약성 분석
기술적 취약성 분석
물리적 취약성 분석
위험평가
위협과 취약성 매핑
위험도 산출
위험평가 보고서 작성
85
위험
수준
평가
위험
대책
제시
SE-10. 위험관리
IV. 위험관리의 전망
가. 위험관리(RMMM) 활동
위험요소
위험대응조치
위험회피,완화(Risk Mitigation)
위험관리의 최상의 전략
위험감시(Risk Monitoring)
프로젝트 전과정 동안 활동
위험관리와 비상계획
(Risk Management and Contingency Plan)
위험회피 실패 경우를 대비한 비상계
획/관리
나. 위험관리 향후 과제
- 최근 해킹, 테러, 재난재해 등 정보시스템의 상시운영을 위협하는 다양한 사건들이
빈번하게 일어나고 있으나, 대부분의 경우는 주로 사후대책에 그치고 있음
- 위험분야별 대응책에 대한 분류 및 표준화 방안수립이 요구됨
- 기술적 보호대책뿐만 아니라 관리적, 물리적인 위험관리 방안도 함께 수립되고
운영되어야 함
- 기술적인 위험을 정량적으로 측정하기 위해 위험분석 자동화 도구의 개발 및 활용
필요
86
SE-11. 아웃소싱
Ⅰ. Outsourcing의 개요
가. Outsourcing의 정의
- 핵심역량 집중을 위해 기업내 부가가치가 낮은 IS 자원, 관리, 운영 등을 외부에 위탁하고 기업은
핵심업무에만 주력하도록 하는 전략
- 조직이 명확한 전략 목표를 가지고 정보시스템 관련 정보 자원 관리 활동의 전부 또는 일부를
외부의 전문기관에 위탁 관리하게 하는 장기적인 계약
- 기업이 보유한 전산장비와 인력 등의 전산자원 중 부가가치가 낮거나 내부에서 소화할 수 없는 업무를
외부에 위탁하여 처리하고 기업은 핵심기능만을 보유하여 경영에 전념하는 전략
나. Outsourcing의 발전과정
자체개발
일부 외주개발
외주개발
외주개발
자체운영
자체운영
자체운영
외주운영
다. Outsourcing의 필요성
- 외부의 고급기술을 이용하여 급변하는 기술환경에 적응하고 이직 등 인력 이동에 따른 부작용 해소
- 전산비용의 절감과 핵심사업 위주로 역량 집중의 필요하여 매번 RFP 통한 계약발주 TCO 절감 효과
87
SE-11. 아웃소싱
라. 아웃소싱의 등장배경
- 비용 절감, 원가 절감
/ - 자체 기술력의 부족, 개발인력 부족
- 전문지식을 가진 업체나 기술인력으로부터 기술이전
- 전략적 차원에서 전문분야에 집중하여 고부가가치의 업무형태로 전화
마. 정보시스템 아웃소싱의 전략적 가치
- 업무수행부문의 위탁으로 경쟁우위를 위한 전략적 핵심 이슈 전념 가능
- 아웃소싱 회사가 신기술, 도구, 방법론, 전문가 등의 기술 또는 기능 이전 가능
- 내부 운영, 기능 및 프로세스의 생산성 제고
- 물적/인적자원의 유연성 제고
- 비핵심분야의 운영비용 절감
바. Outsourcing의 기대효과
1) 경영측면 : 핵심사업의 역량집중 가능
2) 재정측변 : 투자에 대한 Risk 관리가능
3) 기술측면 : Quality의 향상 기대
4) 정책측면 : 위기관리의 적절한 대응 가능
5) 조직측면 : 인력 및 적절한 배치의 문제 해소
88
SE-11. 아웃소싱
Ⅱ. Outsourcing의 대상과 유형
가. Outsourcing의 대상
Desktop
IT
BPR
기술
교육
N/W
Resource
ISP
개발
IS Resource
유지
보수
통합
운영
Application
나. Outsourcing의 유형
유형
89
장점
단점
Total
Outsourcing
-책임소재 명확, 친밀한 관계유지
-Outsourcing 비용효과
-독점적 선택 문제
-가격경쟁의 어려움
Selective
Outsourcing
-경쟁으로 인한 품질향상
-효율적인 가격경쟁 가능
-책임소재 불명확, 요구사항파악문제
-관리비용 발생
IT 자회사 설립
Outsourcing
-Family 의식
-의사소통 및 단결감 조성
-나태함
-필요이상의 전산투자 발생 가능
Co-Sourcing
-IT 기획, 총괄과 수행의 분리
-급변하는 환경에 적합
-전략과 수행의 Gap 발생 가능
SE-11. 아웃소싱
다. 아웃소싱의 형태
(1) 계약관점
분류
내용
도급
일정한 업무 결과에 대해 발주자가 보수지급, 성과물 수반
위임
발주자로부터 일정한 업무처리의 위임을 받은 수탁자가 업무처리, 성과물 수반 필수
아님
파견
파견선과 파견기술자 간에 체결된 파견계약에 정해진 업무만 수행
(2) 개발수명주기
분류
90
내용
감리위탁
외주업체에 대한 감독 업무 위임
업무위탁
업무분석, 기본설계 등 상위공정 부분 외부 전문가의 지원을 받아
업무수행
개발위탁
상세설계 이하 개발과 설치
인력위탁
코딩, 테스트 등 기술분야별 전문가
운영위탁
24시간 연중 무휴, 유지보수 전문 대행
교육위탁
기술향상, 업무지식 함양
SE-11. 아웃소싱
Ⅲ. Outsourcing의 Framework 및 위험요소
가. Outsourcing의 Framework
사전준비
실행
- 업체선정
- 협상 및 계약
- 이행
계약관리
91
-장단기 전략, MasterPlan 명시, 수립
-업부 프로세스의 재설계 및 분석
ISP
-팀구성 계획 및 조직
-RFI / RFP, SLO/SLA, 사업범위 명시화
-Partership 관리, SLM
ITA
EAP
SP
- 유지보수, 차기사업, 보상, penalty 등
SLA / SLM
SE-11. 아웃소싱
나. 정보시스템 아웃소싱 추진 절차
절차
내용
1. 대상업무 선정
- 정보시스템 전략 및 아웃소싱 수행계획 수립
- 아웃소싱 대상업무의 선정
2. 서비스 제공자 선정
- RFP에 의한 우선 서비스 제공자 선정
- 서비스 제공자 확정
3. 협상 및 계약
- 서비스 수준, 비용, 업무분담에 대한 협상
- 협상 결과를 바탕으로 계약
4. 전환 및 이행
- 정보 자원의 이전 및 서비스의 전환
- 자산, 인력 등의 이전
5. 계약 관리
- 서비스 수준에 따른 성과관리
- 계약기간 만료 후 계약 갱신
6. 계약 전환
- 제3의 서비스 제공자와 계약 또는 내부 전환
다. 정보시스템 아웃소싱 추진시 고려사항
- 대상 업무 선정 시 업무별 중요도와 핵심 역량 정도를 파악하여 업무 선정
- 협상 및 계약단계에서 명확한 서비스 수준에 대한 협상을 통한 SLA 도출
- 전환 및 이행시 자산의 이전과 인력의 고용유지 정책 필요
- 계약관리시 협상단계에서 도출된 SLA를 바탕으로 성과를 측정관리하는 SLM
92
SE-11. 아웃소싱
라. 정보시스템 아웃소싱 위험 요소 및 제거방안
구분
제거방안
- 성능측정, 관리부재
- 서비스 레벨, 성과측정 애로
- 미래환경의 불확실성에 따른
계약의 안정성 유지 곤란
- Pilot, 계약사항 위주 검토
- 적절한 Pilot시행을 통한 검증, 보완
- 계약사항조정, 변경을 위한 유연성 확보
- 전략정보, 프라이버시 정보 등의
유출에 의한 피해
- ESM, ITA, SLA
- 필요 보안수준의 명확한 정의
- 관리적/시스템적 보안수준의 제고
고객 비즈니스
이해 부족
(Knowledge)
- 고객 산업, 업무, 문화의 이해 부족
으로 인한 성과 저하 및 불필요한
충돌 발생 가능성
- 유사 영역의 경험보유 벤더 선정
- 효과적 커뮤니케이션 채널 확보
아웃소싱 전략
변경문제
(Reversibility)
- 교체, 변경에 따른 문제점
- 아웃소싱 대상 기능 및 서비스,
벤더의 변경, 혹은 아웃소싱 기능의
회수 등에 따르는 높은 교체비용
- 장기적 계획에 기반한 아웃소싱 추진
- 핵심(Core) 기능 및 핵심인력 유지
- CBD
의존성 문제
(Dependency)
- 정보시스템 서비스에 대한 벤더에의
과도한 의존으로 인해 필요한 정보
시스템 서비스의 조달시 유연성 및
선택범위 제한
- 핵심부분의 관리
- IT 트렌드 및 필수 Knowledge(기술,
벤더 아웃소싱 관리 등)에 대한 지속적
Follow-up
통제 문제
(Control)
보안 문제
(Security)
93
위험요소
SE-11. 아웃소싱
Ⅳ. Outsourcing의 CSF 및 기대효과
정보시스템 아웃소싱의 성공요인
사전준비
실행
 M/P 수립, 업무재설계 등
충분한 사전 준비
벤더
선정
 적절한 Vendor의 선정
협상/
계약
 사업 범위, 서비스 수준
등을 고려한 합리적인
계약의 확보
이행
계약관리
94
 장기적·전략적 계획과의 연계
및 목표의 명확화
 효과적인 아웃소싱 운영
및 체계적 성과 관리
 Vendor와의 파트너쉽
형성
정보시스템 아웃소싱의 기대효과
경영
측면
-전략적 사업에 기업
재정
측면
-공동자원의 활용
기술
측면
-수준높은 기술제공(신기술,
정책
측면
-위기관리의 사전대응이
조직
측면
-인사조직관리 및 기술인력
핵심역량의 집중
투자RISK 최소화
신시스템, 전문인력 활용)
가능
교육등의 효율화
SE-11. 아웃소싱
1) 정보시스템 아웃소싱의 핵심성공요소
- 아웃소싱 목표와 필요성의 명확한 정의와 이해
- 가장 적절한 아웃소싱 방법 선택, 파트너 선정
- 목표에 부합되는 적절한 대상활동선정
- 계약의 명료성과 효과성 확보 : SLA
- 외주관리절차 수립(업무진도관리, 품질관리절차)
- 외주비용견적의 명확화 및 합리적 선정
- 검수와 평가 철저
- 계약조건은 융통성 있게, 서비스 수준은 상세하게
2) 정보시스템 아웃소싱의 과제
구분
95
해결과제
서비스 제공자
-
아웃소싱 서비스에 대한 평가 방법론 수립
엄격한 SLA의 실행
아웃소싱 서비스에 대한 비용산정 기법의 개발
체계적인 정보시스템 운영 관리 방법론의 수립
발주자
-
아웃소싱의 본질
아웃소싱을 통한
아웃소싱의 수행
아웃소싱 전문가
이해
효과의 기대수준 조정
방법론 이해
양성