'UP!/Software Engineering' 카테고리의 글 목록

ERP의 활용과 필요성

UP!/Software Engineering 2008. 8. 21. 14:03

1. 기업의 경쟁력 (3가지 측면)
1) 제품, 서비스의 경쟁
- 과거 : 제품과 서비스의 차별화가 명확.
- 현재 : 차별화가 어렵다.

Lifecycle이 짧다.
=> 경쟁력 유지를 위해서는 끊임 없이 혁신이 필요.

2) Business process의 경쟁
- Business process : 기업이 고객에게 가치를 제공하기 위한 Value chain 속의 가치 창조 구조를 의미
. 신제품 개발 설계 process
. 생산 process
. 조달 process
. 판매 영업 process
. 위 process들을 연계 시킨 사업 process

- 고객 만족도, 비용의 차별화는 Business process의 속도와 효율의 향상으로 가능

3) 신제품과 새로운 서비스, 새로운 Business process를 창조하는 능력의 경쟁
- 제품, 서비스 분야의 경쟁력과 Business process에서 경쟁력을 유지하기 위해 원천이 되는 경쟁력.

2. 정보 기술 활용 현황
1) 업무 통합화의 결여 = Speed 경영의 방해 요인
- 업무의 자동화, 기계화를 부문별로 추진
- 독립적이고 정보의 흐름이 단절
- 업무간 연계가 불 가능 : 통합화의 문제 발생
- 연계 불능으로 사전 회의나 문서 연락이 필요
- 업무 흐름의 속도 향상에 저해 요인

2) 정보 일원화의 결여 = Speed 경영의 방해 요인
- 업무간 통합 불능
. 중복 정보 발생
. 각기 다른 정보 보유

- 정보 공유 불능
. 여러 부문에 걸친 공동 작업(Collaboration)에 어려움
. 자율적인 판단과 신속한 의사 결정의 어려움

3) 즉시성 결여 = 기민한 경영의 방해 요인
- Batch 형태의 업무처리
- Summary 형태로 존재
- 정확한 판단과 의사결정을 적시에 내리기 어렵다.

4) Global화 결여 = Global 경영의 방해 요인
- 국내 사업에 특화시켜 구축 : Global화 대응에 미흡

5) 정보 시스템의 경직화 = 기업 혁신의 방해
- 안정된 환경, 안정된 경영을 전제로 구축
- 시스템이 복잡 방대해졌다.(계속되는 유지 보수)
- 환경 변화에 신속한 대응 미흡

=== 기업 경쟁력을 확보하기 위해서는 정보 기술의 활용이 필수적이다.

3. ERP 도입의 필요성
1) ERP는
- 정보 자원 기술을 이용하여 영업 생산, 회계, 인사, 구매, 자재 등 조직 내의 모든 업무를 통합 처리

하고
- Real-Time으로 정보를 주고 받으며
- 선진의 Business Process를 내장하고 있으므로 별도의 첨단 경영 기법이나 경영 Consulting을 받지

않고도 경영 혁신을 할 수 있다.

2) 필요성
(1) 치열한 경쟁의 시대 능동적인 대응 필요
- 효율적이지 못한 기업은 도태된다.

(2) 업무의 복잡성과 정보 시스템의 대규모화로 정보량의 방대한 증가

(3) 정보 기술의 급속한 발전
- H/W 비용의 저하
- 방대한 자료의 축적과 처리 기술의 발달

(4) 기업 환경의 글로벌 화
- 세계 표준, 다국적, 다언어 처리 기능 요구
- 상거래 제도와 관습, 문화의 경계를 넘어 정보를 통합할 수 있는 구조가 필요

(5) Outsourcing을 통한 자사의 핵심 역량에 집중

(6) 기능의 통합
- 원부자재의 조달, 제품의 제조, 판매에 이르기 까지 공급 체인 전체의 기능 통합
- 조직 전체 기능의 실시간 통합

(7) Business Speed
- 부품 조달 기간의 단축
- 생산 리드 타임의 단축
- 고객 응답 시간의 단축

4. ERP 시스템이 갖추어야 할 조건
1) Integration(통합성)
   - 기존 정보 시스템 : 부분적으로 지원 (인사, 회계, 생산, 재고 등)
   - ERP 에서는 프로세스 관점에서 기능의 통합이 전제
   - 통합을 통해 얻을 수 있는 장점
. 작업 및 데이터의 중복 배제
. 각종 자료간의 불일치 해소
. 프로세스의 최적화
. 업무의 비효율성 제거

2) Real-time Processing (실시간 처리)
- Source data의 발생과 동시 관련 업무에 Real-time으로 자동 처리
- 정보 제공의 적시성을 향상
- 정보 이용자에게 유용한 정보의 제공

3) End-user Computing(사용자 처리) 기능 강화
- 프로세스의 통합과 Real-time Processing이 가능하도록 설계됨으로써 End-user 입장에서 각종 자료

의 접근이 가능하여야 한다. (Client/Server 구조를 통해 EUC 환경이 강화되어야 한다)
- EXCEL 기능 활용

4) Flexibility (유연성)
- Hard-coding 방식을 탈피하여 Parameter 설정 방식으로 설계되어야 함
- Hard-coding의 문제점 ; 개발 기간의 장기화 개발 비용의 상승 유지 보수의 어려움
- 타 시스템과의 Interface의 용이성이 좋아야 한다.

5) Version-up의 용이성
- 최신의 정보 기술을 수용할 수 있도록 vendor의 노력이 필요.
- 새로 개발된 시스템은 기존 시스템에 대한 지원이 용이해야 한다.

5. ERP 구축과 경쟁력

경쟁기업 자기업		경쟁기업
경쟁기업 자기업		구축	미구축
자기업	구축	중립	경쟁우위
자기업	미구축	열세	퇴보

6. 분야별 경쟁력 강화 요소
1) 회계 분야
- 중복 Data 배제, 통합 정보 관리와 회계 업무의 정확도 향상 및 결산 기간 단축
- 기업 내부 기능의 통합, 기업 외부와의 연계 및 자금 정보의 통합 관리
- 정보 기술을 활용한 서류 업무의 감소
- 기업 내 사업부서, 단위 공장간의 통합으로 실시간 회계 처리
- Global company의 본사 및 해외 지사의 통합
- 회계 정보의 합리적 처리
- Cash Flow의 실시간 통제
- 정보 기술을 바탕으로 한 의사 결정이다.
- 국제화 경쟁에 대응하는 Multi Language 및 Multi Currency 지원

2) 인사분야
- 인사 보안 능력 향상
- 서류 작업 감소
- 인사와 관련한 신속한 의사 결정 지원.
- 교육 훈련 및 인재 양성 프로그램 지원.
- 인사 전략, 조직 관리, 채용 관리, 경력 관리지원.
- 인사 관리 업무의 정보 서비스 능력 향상
- 다양한 인사 정보 제공(그래픽, 동영상)
- 제조 및 회계와 연동한 급여 시스템 지원.

3) 정보 기술 분야
- 분산 환경에 의한 시스템의 경량화 및 유연성 확보
- 기업 내부 및 외부와의 이 기종 시스템의 연계 및 정보 교류(개방형 시스템, EDI 기술 등)
- 업무의 자동화(Work Flow)
- 업무의 분석 기능 강화 (DW 활용) : End-user 수준별(담당자, 관리자, 경영자) 보고서의

다양화 ( Graphic, Table 등)
- 기업간, 국가간의 자유로운 시스템 접근 : Web, EDI, EC기술 등
- End-user의 정보 시스템의 친숙도 향상 : GUI
- 재택 근무 환경제공

3) 제조/물류/서비스 분야
- 산업별(제조, 물류, 서비스, 공공 등) 특화된 자문 기능의 대응 및 통합관리
- 대용량 Data 처리 속도 향상에 따른 simulation 능력 향상
- 전반적인 제조 process의 효율 향상, 산업별 표준 process의 효율 향상
- 물류 및 제조 정보의 공동 활용으로 구매 및 설계 비용 감소
- 신제품 설계 process의 지원 : 신제품 개발 활동의 유연성 확보
- 제조/물류/서비스에 관련된 각종 정보의 신속한 지원 → 의사결정 속도 향상
- 산업별 자기업에 맞는 독자적 시스템 구현
- Internet/EDI 를 활용한 공급망 관리, 영업/고객 지원

7. ERP 도입 시 해결 과제

< ERP 도입의 과제 : B30>
1) 경영자의 이해
- ERP 도입으로 기업의 어떤 변혁이 가능한지 이해.
- 기업 변혁을 위해서 ERP도입을 서둘러야 한다는 점 이해
2) 경영 전략의 명확화
- 명확한 경영전략 => 명확한 혁신 이해.
- 혁신 목표 설정이 애매하면 ERP 도입은 성공하지 못함.
3) 현장 일임주위에서 탈피
- 업무 혁신 : 조직, 부문의 현장 업무 흐름의 재검토가 필요 (Global화도 고려)
- 현장 부문이 주체가 되어 개선을 거듭하는 식의 과거 성공 체험을 바탕으로 현장 일임주의로는

ERP 도입의 성공은 불가능
4) 전체 최적의 추구
- 각 부문별 부분 최적 → 각 부문에 걸친 전체 최적
5) 조직의 문화와 풍토에 대한 혁신의식
- 조직 구조의 변혁: 현재 상황을 유지하려는 저항이 크다.
- 경영자를 포함한 구성원 전원이 조직의 문화와 풍토를 변혁.
6) 기간 업무를 위한 정보 시스템의 전반적인 재구축
- 대규모 개발이 필요 : 신속하게
- System의 Flexibility 확보 : 신속한 변경이 가능하도록
- ERP 패키지 활용이 효과적
7) ERP package 이용에 대한 불안감
- 기성품에 대한 불안감 해소
- ERP package는 업계 표준 process를 제공한다.

(다년간 경험과 계속되는 개선으로 노하우를 가지고 있다.)
8) ERP package에 대한 습득
- 전문적인 지식과 방법이 필요
- 수작업으로 회귀하려 함

'UP! > Software Engineering' 카테고리의 다른 글

전사적 자원관리(Enterprise Resource Planning : ERP) (0)	2008.08.21
공급망관리 (0)	2008.08.21
시스템구현 (0)	2008.08.21
[CMMI] CMMI Project Status (0)	2008.08.21
객체지향 분석과 설계 (0)	2008.08.21

Posted by 으랏차

,

전사적 자원관리(Enterprise Resource Planning : ERP)

UP!/Software Engineering 2008. 8. 21. 14:03

전사적 자원 관리(ERP)는 1970년대에 개발되어 사용했던 자재소요량계획(Material Requirements Planning : MRP)에서 출발하여 제조자원계획(Manufacturing Resource Planning : MRP II)과 컴퓨터 통합 제조시스템 (Computer Intergrated Manufacturing : CIM)을 걸쳐 국제화된 기업 환경에서 기업의 현안에 대해서 실시간 분석 및 기업 전체의 최적화를 제공 할 수 있도록 유연한 IT 인프라를 바탕으로 하여 기업 내부의 모든 업무 기능을 통합하는 정보 시스템임.

1. ERP의 발전 과정
MRP(Material Requirements Planning: 자재소요량계획: 70년) → MRP-II(Manufacturing Resource Planning: 제조자원계획: 80년) → CIM(Computer Integrated Manufacturing: 컴퓨터 통합제조 시스템: 80년 중반) → ERP(전사적 자원관리: 90년 중반) 

1) MRP (자재 소요량 계획)
- Material Requirements Planning
- 1960년대 중반 IBM의 Joseph Orlicky가 개발업계에서 실무자들에 의해서 개발됨(학계나 이론가에

의해서 개발된 것이 아님)
- 자재 소요량 계획에 중점을 둔 system
- 개념 : 이미 수립된 제품 생산 계획을 바탕으로 조립품, 부품, 원자재 등의 종속 수요 품목에 대해서

“필한 물건(품목)을 필요한 때(납기)에 필요한 만큼(소요량)”을 구매하여 제조하기 위한 수배

계획을 수립하는 것. 즉, 자재 소요량을 합리적으로 관리하기 위한 자재 및 구매 관리 중심의

system
- 재고 품목 : 독립 수요 품목과 종속 수요 품목으로 구분
. 독립 수요 품목 : 최종 제품(end items) 생산용으로 사용되지 않는 스페어 부품
. 종속 수요 품목 : 최종 제품을 구성하는 구성품(components) 원료(raw-material), 부품(part), 중간

조립품(subassembly))

- MRP의 성공 요인
. 당시 전통적인 재고 관리 시스템은 독립 수요 품목 위주로 개발되었으나 더 중요한 것은 종속 수요

품목에 대한 관리가 더 필요했음 - 당시 MRP는 종속 수요 품목 관리에 초점을 둠. 즉, 필요한 자재

를 적절한 시기에 필요한 장소에 공급한다는 문제를 효과적으로 다룰 수 있었음.

- ERP의 시조
- 주요 기능 : 자재 수급 관리, 재고의 최소화

2) MRP-II (제조 자원 관리 system)
- Manufacturing Resource Planning.
- 기업의 전반적인 효율성 향상과 비용 절감을 위해서는 관리 대상을 회사 내부 전체로 확대한

system 이 필요.
- 제조, 영업, 회계, 설계와 관련된 제조 기업의 정보 시스템
- 주요 기능 : 제조 자원 관리, 원가절감

3) CIM (컴퓨터 통합제조 시스템)
- Computer Integrated Manufacturing
- MRP-II의 부족함을 인식
- 기업의 영업, 생산, 기술분야에서 물류와 정보, 관련 설비나 시설의 통합을 중시한 제조업 정보

시스템
- 문제점 : 기술 인력의 부족, 기술의 제휴, 기능 통합의 어려움, 구축 기간의 장기화 등으로 확산이

저조.

4) ERP ( Enterprise Resource Planning: 전사적 자원관리)
- CIM과 정확한 구분이 없다.
- Gartner Group의 정의
. 91년 최초로 ERP개념 제창
. 정의 : 제조(Manufacturing) 회계(Financial) 물류(Distribution) 그리고 다른 업무 기능들

(Business Function)이 균형을 이루도록 해주는 응용 애플리케이션 소프트웨어의 집합(A set of

applications software that brings manufacturing, Financial, distribution and other business

function into balance)

- 주요 기능 : 전사적 자원 관리, 경영 혁신 (기업 내 관련 기능의 통합 관리 및 기업 외부의 모든 관

련 자원과 연계한 전사적인 자원관리 system)
. 기업의 자원 : 사람(Man), 설비(Machine), 자재(Material), 자금(Money), 정보(Information), 시간

(Time), Service 등을 포함

- BPR (Business Process Reengineering : 비즈니스 프로세스 재 구축)기법을 도입하여 업무

개선 효과 얻음

- ERP는 BPR과 같이 추상적인 개념이 아니다.
. 패키지 내에 프로세스가 저장되어 있음
. Parameter에 의해서 실제로 기업에 적용 가능
. 최고의 실행(Best Practice)를 가지고 있음
. ERP를 도입함으로써 선진 기업의 프로세스를 도입할 수 있다.

- ERP는 혁신적인 새로운 개념이 아니다.
. 80년대에도 기업의 모든 자원의 통합에 대한 요구는 있었다

- 대용량의 데이터의 저장과 실시간 처리 기술이 요구됨.
. 당시에는 기술력에 한계가 있었다.
. 따라서 최근 IT의 발전 (H/W 비용의 급락과 첨단 IT 의 출현)으로 인하여 기업의 방대한 데이터 수

집과 저자, 가공이 가능해 짐으로 인하여 통합 Package로 개발 될 수 있었음.

- 기업 환경이 생산자 중심에서 소비자 중심으로 전환되고 있는 상황에서 기업들은 생존경쟁에서 살아

남기 위한 대안으로 IT자원을 활용한 첨단 경영 기법의 도입 요구가 증대하면서 ERP가 주목을 받기

시작함.

- 종합 정의
“기업이나 단체의 인사, 회계, 물류, 제조, 서비스 등 전 분야에서 일어나고 있는 전체 기능들에 대해 효과적 관리와 통제를 위한 통합 정보 시스템”으로 “관계형 또는 객체지향형 DBMS, GUI, 개방형 system, client/server, 4GL, web지원, EDI, Data warehouse의 최신 정보기술을 지원하는 Business system구조를 가진 system”이다.

5) 향후 추세
- ORP(Optimization of Resources and Process:자원과 프로세스의 최적화 시스템) or

e-ERP(Extended ERP: 확장 ERP)
- 주요 기능 : 기업간 최적화, Win-Win-Win
- 자원과 프로세스 최적화 시스템(ORP: Optimization of Resources and Process) : 기업 구성원들이 기

업의 모든 자원의 사용을 최적화하여 의사 결정권자로 하여금 최적의 의사결정을 할 수 있게 지원해

주는 시스템 임. 기존의 ERP 패키지들은 "What-If" 시뮬레이션 등과 같은 기능이 없음
-> 따라서 ERP를 이용해서 수립된 계획이 최적의 계획인지를 알 수 없었음.
-> 그러나 ORP는 프로세스와 자원을 최적화 하기 위해 각종 정보와 시뮬레이션 모델을 이용하여 최

적의 의사결정을 하는데 도움을 준다
- 확장 ERP (Extended ERP) : ERP의 확장 개념으로 기업의 내부 업무는 물론 기업과 기업간의 업무까

지도 통합하여 최적화를 지향하는 시스템 임.

6) 기존 시스템과의 차이점

구 분	기존 시스템	전사적 자원관리
구축 목적	업무의 단순한 전산화 (업무의 스피드 향상에 역점)	기업의 전략을 강화 (경쟁력 향상)
지역적 관점	특정 국가 및 지역에 국한 (Local)	국가나 지역에 관계 없이 지원(Global)
적용 범위	부분적 지원	업무의 통합적인 차원에서 지원
도입 결정 과정	업무를 부분적으로 지원 하기 때문에 중간 관리자에 의해 도입을 결정함 (Bottom-Up)	지원기능이 통합적인 관점에서 제공되므로 최고 경영자의 결정과 지시에 의해 이루어짐 (Top-Down)
구축 방법	Source Code의 작성과 수정	Parameter설정 (Customizing의 최소화)
System의 Up-grade	어렵다 (Source Code의 신규 작성과 수정이 어려움)	쉽다 (전문 공급업체에서 기업 환경 변화에 능동적으로 대응함)

2. ERP의 출현 배경
1) 경영 패러다임의 변화
- 과거의 경영 : 고도 성장의 매출 확대, 이익 중시 경영
- 현재의 경영
. 기업의 자금 능력 약화
. 수익성 감소
. 치열한 경쟁 시대 (대경쟁: Mega-competition)
- 다국적 기업의 평균 수명 : 40 – 50년
- 평균 수명이 긴 이유
. 민첩성(기업의 외부 환경에 발 빠른 대응)
. 결속력(기업 문화를 바탕으로 한 구성원의 단결)
. 보수적인 자금 운영
. 효율적 투자

2) 기업의 환경 변화 요인 (7가지)
(1) 세계화/국제화 : 무역 자유화 → 경쟁력 확보 → 세계화/국제화(다국적기업)

=> 다국적 기업의 관리를 위해 세계화/국제화된 정보 시스템의 필요성 대두

(2) 정보의 다량화/분산화 : 지역적으로 분산된 다량의 기업 정보를 통합 관리 요구

(3) 빠른 제품의 라이프 사이클과 수익성 감소. : 제품이나 서비스의 다양한 요구 → 제품 수명 단축

→ 제품의 라이프 사이클 단축 → 제품 개발에 투자 비용이 상승

(4) 제품의 초 고급화 : 최고의 기능과 최고의 품질 요구 → 품질 좋은 제조 절차(일품생산) 필요 =>

일품 생산 형태의 주문까지 지원할 수 있는 정보 시스템 요구

(5) Knowledge worker의 등장 : 지식 기반 사회에서 핵심 역할은 인간이며, knowledge worker의 생

산성은 기업 경쟁력 확보와 직결 => 새로운 정보 시스템은 지적 작업자의 사무 생산성을 극대화

(6) 외부 경쟁자의 도전 : 차별화 된 경쟁력 확보 (제품의 생산, 판매 A/S등 전 과정에서 총체적인 경

쟁 우위력을 확보)

(7) 강화된 고객 지원 체계 : 상세한 고객 정보 확보와 활용으로 고객의 기호와 개성에 맞는 제품이나

서비스 제공. => 방대한 고객 정보 확보와 활용은 새로운 정보 시스템 요구.

3. 정보 시스템 관련 기술의 변화 (9개 기술)
(1) GUI (graphical user Interface)기술
   - Text Base의 UI 환경 : 사용자의 접근성 미흡
   - GUI : 기업내 모든 사용자의 접근성 용이 (관리자, 경영자 계층)

(2) Open Standard System
   - Stand-Alone System (지역적 혹은 독립적으로 운영) Interface와 Integration 취약
   - Open system : 이 기종간의 Interface와 Integration이 가능. 전 사적 자원 관리를 가능케 함.

(3) Client/server 기술
   - 중앙 집중식 system : 대형화, 집중화에 따른 비용의 중가 Down sizing 필요성 인식
   - Client/server system
. Server system : 공용성 정보의 관리, 보관
. Client system : 개별 정보의 관리, 보관
. 중앙 집중식 system 보다 초기 투자 비용이 상대적으로 낮다.

(4) Relational Database (RDB) 와 객체지향 (object-oriented) 기술
- RDB : 분산 환경에 적합
- OO기법 : 새로운 설계와 개발 기법.

(5) 4GL과 Case Tool
- 4GL(fourth generation Language)
   . 사용자가 programming에 대한 전문 지식이 없어도 programming을 할 수 있도록 지원
   . 개발의 신속성
- CASE (Computer Aided Software Engineering)
   . 개발 생산성 증대
   . 개발의 자동화 지원
   - 복잡한 기업 정보 시스템을 구축하는데 유용한 기술

(6) Work Flow
- 기업 업무가 복잡해지고, 표준화가 어렵다.
- 기간 업무의 자동화, 표준화, 관련 업무의 Interface, 정보의 효율적 관리, 운영

(7) EDI 기술
EDI (Electronic Data Interchange) : 사람의 개입이나 재입력 없이 자료 전송 수단으로 활용. 기업간 정보 교환의 수단으로 활용.

(8) Data Warehouse 기술
- 다양한 Data로부터 활용 가치가 있는 정보 요구 (사용자의 요구와 필요에 부합하는 정보 요구 : 각
종 Table이나 Graphic 정보)
- DW기술 : 원천(Raw) data의 분류, 결합, 가공 기술

(9) Web 기술
- Web 기술 : 시간과 지역에 관계없이 정보 system에 쉽게 Access 가능

4. 정보 기술의 발전 추세
1) 정보 기술의 변화 (3대 변화)
- Don Tapscott와 Art Caston이 저서 “패러다임 쉬프트 (Paradigm Shift)” 에서 소개
(1) Personal computing → Work group computing
(2) 개별 System → 통합 System
(3) 기업 내부 Computing → 기업간 기업의 Computing환경

2) 정보 기술의 요소 기술 전환
- Don Tapscott와 Art Caston이 저서 “패러다임 쉬프트 (Paradigm Shift)” 에서 소개
   (1) Computer Chip : 반도체 → Micro processor
   (2) System : Host system → Network system
   (3) S/W 공급    : 공급자 독점    → Open Standard
   (4) 정보 형태    : 단일 미디어    → 멀티미디어
   (5) 고객과 공급자 관계 : 종속 → 협력 관계
   (6) S/W개발 : 독립된 개인 기술    → Module화, 표준화, 공동 개발
   (7) User Interface : Text Base    → GUI. (Graphical User Interface)
   (8) 응용 Program    : 독자형 → 통합형, Module형, 재사용 강화

'UP! > Software Engineering' 카테고리의 다른 글

ERP의 활용과 필요성 (0)	2008.08.21
공급망관리 (0)	2008.08.21
시스템구현 (0)	2008.08.21
[CMMI] CMMI Project Status (0)	2008.08.21
객체지향 분석과 설계 (0)	2008.08.21

Posted by 으랏차

,

공급망관리

UP!/Software Engineering 2008. 8. 21. 14:02

제1장 공급 사슬 관리의 개요
1 공급 사슬 관리의 개념
- 공급 사슬 (Supply chain) 이란 “공급 업체로부터 재화나 용역이 생산 과정을 거쳐 소비자에 이르는 과정에서 전반적인 유통에 관련된 정보 및 프로세스의 집합체 (Schroeder, 2000)
- 공급 사슬은 재화나 용역이 원재료의 공급 업체, 제조 업체, 유통 업체, 소매 업체 마지막으로 최종 소비자에 이르는 과정에서 원재료, 관련 정보, 지불, 서비스 등의 일련의 흐름을 의미하는데, 즉, 제품이 제조되고 최종 소비자에게 전달되는 과정으로 여러 기업이나 조직이 관여 함으로 하나의 확장된 기업 (extended enterprise) 개념으로 볼 수 있다.
- 공급 사슬의 주체
. 고객 . 제조 업체
. 소매업체 . 부품, 원자재 공급업체
. 도매업체 / 배송업체

- 공급 사슬 관리 (Supply chain Management) 란
공 급 사슬상에 존재하는 불필요 하고 비효율적인 요소들을 제거하여 공급 사슬에 참여하는 조직의 공통 비용을 절감하고, 이익을 증대시켜 궁극적으로 소비자 가치를 극대화 하려는 기업간 win-win 전략으로 제품의 원재료 조달에서부터 소비자에 이르기 까지의 공급 사슬에 참여하는 모든 업체들을 전략적인 제휴를 바탕으로 정보 기술을 활용하여 통합의 효율성을 추구하는 경영 방식이다.

- SCM 이란
고객과 참여하는 관계자들에게 부가 가치를 창출하기 위해서 최초 공급자로부터 소비자에게 이르는 과정에서 제품, 서비스, 정보의 흐름과 같은 비즈니스 프로세스들을 통합적으로 운영하는 전략이다 (Global Supply Chain Forum, 1988)

- SCM 이란
고객이 요구하는 서비스를 만족시켜 주면서 비용을 최소화 시키기 위해서 적정 수량의 제품을 적정한 장소까지 적정한 시간에 생산 및 유통될 수 있도록 공급자, 생산자, 물류업자, 유통업자 들을 효율적으로 통합하기 위한 경영 방식이다. (Simchi-Levi, 2000 : 대영, 고 266)

2. 공급망 관리의 출현
- 1980년대에 미국에서 시작된 개념
- SCM 에 관련한 기법들
. ECR (Efficient Consumer Response),
. QR (Quick Response)
. CAO (Computer-Assisted Ordering)
. CRP (Continuous Replenishment Program)
. CFAR (Collaborative Forecasting and Replenishment)
. CPFR (Collaborative Planning, Forecasting and Replenishment)
- 주요 업체
. i2 Technologies
. J. D. Edwards
. SAP.

- 초기 SCM은 주로 제조업체와 유통업체를 대상으로 발전.
- 향후 금융, 보험, 의료, 연예 등 서비스 업체로 확산 전망
- 국내에서는 90년대 중반에 미국계 Consulting 업체와 SI 업체들에 의해서 개념이 소개됨.

3. 공급망 관리의 중요성과 목적
1) SCM 의 중요성
(1) 공급 사슬의 연계에 대한 중요성
- 다양한 형태의 경쟁 상황에 직면 (Global 화)
- 기업 자체적인 경영 효율화에 한계 봉착
. 자전거 생산 업체가 내부적으로 경영의 효율화를 이루었다 하더라도 도매상이나 소매상까지

운송하는 시스템이 제대로 구축되지 않았다면 결과적으로 제품 자체의 경쟁력을 잃을 수도 있

다. 따라서 자전거를 잘 만드는 것도 중요하지만 운송 시스템도 잘 갖추어 판매 효율화를 이룩

하도록 한다.
- 최근 기업 경영은
. 자기 기업이 경쟁력이 별로 좋지 않아도 다른 기업들과 Outsourcing, 전략적 제휴, 파트너 쉽 등

을 통해 연계 관계를 강화시키거나, 효율적으로 활용하여 전체적인 제품 공급 라인을 효율화 시

킬 수 있다면 이것도 경쟁력을 강화 시킬 수 있는 방법 이라는 것을 인식함.
- 공급 라인의 변화
. 과거 : 제조업체 -> 도매상 -> 소매상 -> 소비자
. 현재 : 소비자 -> 소매상 -> 도매상 -> 제조업체

제조업체 중심에서 소비자 중심으로 변화 => SCM 의 핵심 요소

- 기업의 경영 효율화 = 생산 효율과 판매 효율화로 달성할 수 있음.
. 생산의 효율화 : 좋은 제품의 생산, 품질, 원재료와 도구의 적시 적절한 구매 등 기업 전방 분야

의 효율화를 이룰 수 있다.
. 판매 효율화 : 물류, 배송 등 기업 후방 분야의 효율화로 이룰 수 있다.
- 따라서 1980년대 90년대 들어서 기업의 위 전방 부분과 후방 부분의 연계가 기업전략의 핵심으

로 부각
- SCM이 최근에 관심을 집중시키는 이유
. SCM은 1800년대 이후 산업 사회로 진입하면서 항시 관심을 가지고 있었음
. 80년대, 90년대에 활용되기 시작한 공급망 관리 기법들 (이 당시 혁신적인 경영 전략가들에 의

해서 경영전략의 TOOL로 인식되기 시작함)
   . ECR (Efficient Consumer Response),
   . QR (Quick Response)
   . CAO (Computer-Assisted Ordering)
   . CRP (Continuous Replenishment Program)
   . CFAR (Collaborative Forecasting and Replenishment)
   . CPFR (Collaborative Planning, Forecasting and Replenishment)
   . 기업의 Computing 환경이 또한 Mainframe에서 PC 환경으로 변화되고, 졍영 전략과 정보 기술의

접목으로 새로운 관점에서 관심을 갖게됨

(2) SCM과 유통 관리의 차이점
. 유통관리의 대상 : 제조업체, 도매상, 소매상
. 90년대 초에 SCM이 기업의 경쟁 전략으로 부각하자 많은 유통관리 분야의 학자나 전문가들이 유

   통관리가 SCM의 함 부분으로 흡수될까 봐 우려함
   . SCM이 유통관리를 포함하고 있는 것은 사실이지만 50%정도는 서로 다른 점도 있음
   . 차이점
SCM : 제조업체의 생산 효율성과 유통업체의 판매 효율성에 목적을 둠
유통관리 : 제조업체의 생산 효율성 보다는 유통 업체의 판매 효율성에 중점을 둠

2) SCM 의 목적
(1) 소비자들의 다양한 요구를 제품의 공급 과정에 일치(Synchronization)시키려고 함
- Synchronization
. 소비자의 요구에 소매점이 자신의 활동을 일치
. 소매점의 요구에 도매상이 자신의 활동을 일치
. 도매상의 요구를 제조업체가 그들의 활동을 일치
. 제조업체의 요구를 원재료 공급 업체가 그들의 활동을 일치
. 궁극적으로 공급 라인 전체가 일치하게 된다.
- 공급 사슬간의 연결 고리가 제대로 연결되지 못하면
. 비용이 더 들거나
. 손해가 발생
- 수도 배관의 예

(2) 소비자 만족을 통한 매출 확대
- SCM은 소비자를 기본으로 시작하여 소매점, 도매상, 제조업체, 원재료 공급업체로 연결됨
- 따라서 공급망 상의 모든 구성 요소를 유기적인 통합하여 고객의 만족을 극대화하여 매출을 확대

한다.
- SCM이 소비자로부터 시작한다 하여 (Customer Chain Management)라고도 함
- 또, SCM을
. 소매상이 여러 도매상을, 제조업체가 여러 원재료 공급업체를 탐색하면서 거래를 한다 하여

Supply Network, Supply Web이라고도 함

(3) 공급망 상의 총 가치의 극대화
- 총가치 : 공급사슬 관리상에 투입된 전제 비용과 이로 인해 창출된 전체 수익과의 차이를 의미함
- 공급사슬 관리상에 투입된 전체 비용 : 소매상, 도매상, 제조업체, 원재료 공급업체들이 사용한 총

비용

   - 공급사슬 관리상의 전체 수익 : 최종 산출물인 제품을 구입하기 위해 소비자가 지불한 가격의 총합
   - 공급 사슬 수익성(Suppply Chain Profitability) 총가격 – 총 비용.
   - 공급 사슬 수익성의 극대화는 공급망 상의 개별 업체에 의해서 이루어지는 것이 아니고 공급망 상

   의 모든 업체가 공급망 상의 총 가치를 극대화시키므로 가능하다.

(4) 공급망의 최적화로 수익의 극대화
   - 참여하는 일부 업체만으로는 공급망의 최적화는 이룰 수 없다.
   - 공급망 상의 업체간의 비용 전가 등은 종국적으로 소비자 가격을 올리게 되어 수익의 극대화에 역

행이 됨

'UP! > Software Engineering' 카테고리의 다른 글

ERP의 활용과 필요성 (0)	2008.08.21
전사적 자원관리(Enterprise Resource Planning : ERP) (0)	2008.08.21
시스템구현 (0)	2008.08.21
[CMMI] CMMI Project Status (0)	2008.08.21
객체지향 분석과 설계 (0)	2008.08.21

Posted by 으랏차

,

시스템구현

UP!/Software Engineering 2008. 8. 21. 14:02

시스템 구현 단계는 설계 내용을 원시 코드로 설계 내용과 프로그램 작성 내용 일치 여부 검증 오류를 발견, 수정 용이 요구사항 변경, 기능 추가 시 원시 코드와 문서화 작성이 용이하도록

1. 프로그래밍 언어의 선택 기준
1) 친밀감이 있어야 한다
2) 프로그래밍 언어의 개념이 단순, 명료, 통일성을 가져야한다
3) 복잡한 연산이나 요구되는 연산 결과의 정확도를 고려해야 한다.
4) 구조적인 표현이 가능하고 검증이 쉬워야 한다.
5) 적절한 자료구조, 연산, 자연스러운 구문 제공이 가능해야한다.
6) 프로그래밍 지원 환경이 좋아야 한다.
7) 기계에 대한 독립성이 있어서 이식성이 높아야한다.
8) 프로그램의 길이가 짧은 언어가 좋다.

2. 구조적 프로그래밍의 개요
구조적 프로그래밍의 출현 배경
고전적인 소프트웨어 개발 문제점 해결

문제점
생산성과 신뢰성의 저하
유지보수, 확장성의 결여
시스템 관리 곤란

3. 구조적 프로그래밍의 배경 사상
1) GO TO 문 유해론
2) 프로그램의 기본 구조
① 순차처리 구조
② IF THEN ELSE 구조
③ DO WHILE 구조 or DO UNTIL 구조

4. 구조적 코딩기법
구조적 코딩이란?
- 구조정리에 따라서 프로그래밍하는 것
- 3개의 기본적인 제어구조를 조합한 구조로 표현한 것
- DO CASE, DO UNTIL, 순환(Recursion)기법 추가 사용

∙ CASE 구조
- 어떤 조건을 판별한 결과 3개 이상의 처리로 나누어지는 경우에 적용되는 구조
- 입구도 하나, 출구도 하나다

DO CASE 흐름도를 유사코드로 표현하면
DO CASE entry-name
CASE 조건1
처리1
CASE 조건2
처리2
CASE 조건3
처리3
:
:
CASE 조건N
처리N
END-CASE

◉ DO UNTIL구조
DO WHILE 구조 DO UNTIL 구조

* 모듈의 호출방법
모듈을 호출하는 경우 GO TO 문을 사용하지 않는다.
Call 명령이나 PERFORM 명령 등을 사용한다.

5 의사 코드와 흐름도와의 관계

구조적인 프로그램 작성
- 프로그램 명세서를 작성
- 명세서의 작성에는 의사코드를 많이 사용
- 구조적 프로그래밍 발전 ⇒ 흐름도 필요 없음

1) 문서화를 위한 관점

① 흐름도 : 『How』의 표현수단 우수, 『What』 표현수단 부적합
② 의사코드 : 『What』『How』 동시 표현 가능한 문서화 기법
③ 프로그래머가 생각한 결과의 전달 수단으로 의사코드가 흐름도보다 우수

2) 주의력 집중을 위한 관점
흐름도 :
4각형, 화살표, 마름모꼴, 원, 타원, 사다리꼴 등의 도형을 사용
도형을 배치항 위치, 크기 고려 ⇒ 생각 방해 요인
의사코드 :
문제의 논리적 해결에 주의력 집중 가능

3) 특정언어로의 변환이 쉬운 관점

의사코드 사용 제어구조 표현 규칙
① 제어구조를 표현하는 용어를 사용한다.
② 구조적 문장 표현과 문장 시작 위치를 일치 시킨다.

4) 다른 프로그래밍기법과 연결되는 관점

구조적 프로그래밍을 쉽게 하는 기법
구조화 설계
프로그램을 독립된 한개의 기능단위로 분할하여가는 기법
구조적 프로그래밍의 필수 불가결한 것
독립성이 높은 모듈구조로 설계하여가는 방법을, 지침으로 표시한 것
HIPO

6. 프로그램 설계
프로그램 작업의 유형
1) 자료 변환 프로그램
2) 분류(sort) 프로그램
3) 병합(merge) 프로그램
4) 분배(distribution) 프로그램
5) 대조(matching) 프로그램
6) 추출(extract) 프로그램
7) 갱신(update) 프로그램
8) 생성(generate) 프로그램

7 소프트웨어 생산성

소프트웨어의 생산성을 높이기 위한 방법
1) 먼저 인적자원의 확보가 선행되어야 한다
2) 여러 가지 업무를 개발한 경험자를 참여시킨다
3) 적절한 인원으로 팀을 이루고, 조직 내에 갈등이 생기지 않도록 한다
4) 개발자를 지리적으로 분산시키지 않는다
5) 개발에 사용자 참여
6) 고급언어 사용
7) 구조적 개발 방법론 등, 최신 기법 도입
8) 개발 도구들을 도입하여 분석과 설계 및 프로그램 생성에 활용
9) 재사용 가능한 모듈 활용, 모듈화 적극 추진
10) 프로토타이핑을 한다
11) 개발자들의 자질 향상을 위해 교육 훈련을 시킨다
12) 개발 환경을 개선한다
13) 진척 관리를 철저히 한다
14) 개발자 스스로가 생산성을 측정할 수 있도록 한다
15) 시험 방법을 잘 선택해야 한다

생산성에 영향을 미치는 또 다른 요소
1) 프로젝트의 크기
2) 프로젝트 개발 경험
3) 프로젝트가 복잡성
4) 정보 처리 유형
5) 개발 조직체의 규모
6) 자원 및 일정
7) 초과 근무 수당
8) 현업과의 협조
9) 경영자의 관심 정도
10) 대상 고객
11) 기존 소프트웨어 개선, 오류 정정, 새로운 시스템으로 변환하는 경우

정보 처리 유형
① 일괄 처리용
② 실시간용
③ 과학 기술 계산용
④ 시스템 소프트웨어
⑤ 통신용
⑥ 자동 제어용
⑦ 멀티미디어용
⑧ 인공지능용
⑨ ROM 내장용
⑩ 데이터 베이스 응용 4세대 언어용

'UP! > Software Engineering' 카테고리의 다른 글

전사적 자원관리(Enterprise Resource Planning : ERP) (0)	2008.08.21
공급망관리 (0)	2008.08.21
[CMMI] CMMI Project Status (0)	2008.08.21
객체지향 분석과 설계 (0)	2008.08.21
문서화 (0)	2008.08.21

Posted by 으랏차

,

[CMMI] CMMI Project Status

UP!/Software Engineering 2008. 8. 21. 14:01

Agenda

• Project History

• CMMI Structure

• Comparisons with SW-CMM v1.1, SE-CMM, and EIA/IS 731_

• Assessment Methodology

• Training

• Transition Timelines and Strategies

What is a CMM?

• Capability Maturity Model:
A reference model of mature practices in a specified discipline, used to assess a group’s capability to perform that discipline

• CMMs differ by

– Discipline (software, systems, acquisition, etc.)

– Structure (staged versus continuous)

– How Maturity is Defined (process improvement path)

– How Capability is Defined (institutionalization)

• “Capability Maturity Model®” and CMM® are used by the Software Engineering Institute (SEI) to denote a particular class of maturity models

Commonly Used CMMs

What is the Problem?

• Different structures, formats, terms, ways of measuring maturity

• Causes confusion, especially when using more than one CMM

• Hard to integrate them in a combined improvement program

• Hard to use multiple models in supplier selection

The CMMI Project

• DoD sponsored collaboration
between industry, Government, academia

• Over 100 people involved

• U.S. Army, Navy, Air Force

• Federal Aviation Administration

• National Security Agency

• Software Engineering Institute

• ADP, Inc.

• AT&T Labs

• BAE

• Boeing

• Computer Sciences Corporation

• EER Systems

• Ericsson Canada

• Ernst and Young

• General Dynamics

• Harris Corporation

• Honeywell

• KPMG

• Litton

• Lockheed Martin

• Motorola

• Northrop Grumman

• Pacific Bell

• Q-Labs

• Raytheon

• Rockwell Collins

• Sverdrup Corporation

• Thomson CSF

• TRW

CMMI Models

Source Models

• Capability Maturity Model for Software V2, draft C (SW-CMM V2C)

• EIA Interim Standard 731, System Engineering Capability Model (SECM)

• Integrated Product Development Capability Maturity Model, draft V0.98 (IPD-CMM)

• Combined System Engineering / Software Engineering model

– IPPD version being developed

• Can be applied to:

– Just the software engineering projects in an organization

– Just the system engineering project in an organization

– Both

CMMI Process Areas - Staged Representation

Common Features For Each Process Area

• Commitment to Perform includes practices that ensure the process is established and will endure.

– Establishing organizational policies and leadership.

• Ability to Perform includes practices that establish the necessary conditions for implementing the process completely.

– Resources, organizational structures, and training.

• Activities Performed includes practices that directly implement a process area.

– Developing plans and procedures, performing work, tracking work, and taking corrective actions as necessary.

• Directing Implementation includes measurement practices that are necessary to collect and analyze data related to the process.

– Insight into the performance of the process.

• Verification includes practices that ensure compliance with the process that has been established.

– Reviews and audits.

CMMI - Continuous Representation

Which Representation Should We Use?

• The staged and continuous representations are equivalent but expressed in different ways

– Equivalent staging defined

• Staged

– Specific Process Areas for each Maturity Level

– Guides incremental improvement by focusing attention on the next level’s Process Areas

• Continuous

– Each Process Area has Capability Levels

– Organizations must decide your own improvement path

» What level of capability is appropriate for each Process Area based on their business needs

• Generally, you should keep the representation you started with

– SW-CMM: staged; EIA 731: continuous

CMMI Model Components

• CMMI Models contain institutionalization (Generic) and implementation (Specific) parts:

• Front matter

• Process Areas that contain:

– Generic and Specific Goals

– Generic and Specific Practices
(in Common Features in staged representation)

– Subpractices

– Notes

– Discipline-specific amplifications

• Glossary and model scoping guidelines

SW-CMM v1.1 vs. CMMI

Process Areas

SW-CMM v1.1 vs. CMMI
Common Features

SE-CMM and SECM (EIA/IS 731) vs. CMMI
Common Features - Engineering

CMMI Assessment Requirements (CAR)

• Similar to the current CMM Appraisal
Framework (CAF) V1.0

– A guide to assessment method developers

• Specifies the requirements for classes of
assessment methods

– Class A: Full, comprehensive assessment methods

– Class B: Initial, incremental, self-assessments

– Class C: Quick-look

• Method developers can declare which class their method fits

• Method buyers will understand the implications of the method proposed

Standard CMMI Assessment Method for Process Improvement (SCAMPI)

• A Class A Method

• Similar to CBA IPI method

– Led by authorized Lead Assessor

– Tailorable to organization and
model scope

– SEI will continue to compile results

• Rules of evidence have been expanded

• Products:

– SCAMPI Method Description

• In work

– Maturity questionnaire, work aids, templates

– Incorporation of SECM appraisal methods

– Reducing the cost of assessments

CMMI Lead Assessor Program

• Similar to existing SEI Lead Assessor
and Lead Evaluator programs

– To be administered by SEI

• Will transition current SW & SE Lead Assessors

– Specific requirements, steps under discussion

• Lead Assessor requirements:

– Introduction to CMMI Training

– Assessment team experience

– Advanced CMMI Training

– SCAMPI Lead Assessor Training or
Upgrade Training (for current Lead Assessors)

Expectations

• We have simplified the method, but…

– CMMI models have more process
areas and more practices than each
of the individual source models

• Our goal:

– Assuming an organization
of 3-6 projects, 6-9 team members,
experienced Lead Assessor

– SCAMPI assessment of all process areas through Levels 2-5 in 2-3 weeks

– SCAMPI assessment of process areas through Levels 3 in 1-2 weeks

Introduction to the CMMI Course
Staged & Continuous (Separate Courses)

• Introduction course will enable the participant to

– Understand the importance of defined processes

– Understand the rationale for process improvement

– Comprehend the CMMI model

– Identify ways of applying the CMMI model
for process improvement

• Broad audience

– Systems and software developers

– Systems and software managers

– Practitioners of disciplines that support systems and software

– Government and industry acquirers of software-intensive systems

• Other courses in development

CMMI Transition Plan

How Do I Transition My Organization?

• Decide whether the staged or continuous representation is more appropriate

• Decide the scope of the improvement effort

– Software projects only

– Systems engineering projects only

– All projects

• Perform an gap analysis of your current practices against the model changes from SW-CMM and/or EIA 731

– New Process Areas

– New Common Features

– New/different practices

– Do you need a new infrastructure to cover a new discipline?

– Do you want a comprehensive assessment? Informal/formal?

• Set goals, develop a plan, implement the plan, assess progress

Summary

Organizations that are currently using SW-CMM v1.1 or EIA/IS 731 should be able to smoothly transition

http://www.sei.cmu.edu/cmmi/

• CMMI Model, SCAMPI Method Description

• IPPD Model (when available)

• CMMI news, presentations, articles, correspondence

• FAQs (Frequently Asked Questions)

• CMMI Plans and Schedules

• CMMI Transition Plan

'UP! > Software Engineering' 카테고리의 다른 글

공급망관리 (0)	2008.08.21
시스템구현 (0)	2008.08.21
객체지향 분석과 설계 (0)	2008.08.21
문서화 (0)	2008.08.21
CASE (0)	2008.08.21

Posted by 으랏차

,

객체지향 분석과 설계

UP!/Software Engineering 2008. 8. 21. 14:00

22 객체 지향 분석과 설계(Object-oriented Systems Analysys and Design)
객체 지향 이란?
SIMULA라는 시뮬레이션 언어에서 근원
∙Booch
Major : abstraction, encapsulation, modularity, and hierachy
Minor : typing, concurrency, and persistency
∙Cardelli
Inheritance and polymorphism
∙Coad
Class and objects, inheritance, and communication with messages
∙Khoshanfian
Abstract data type, inheritance, and object identity
∙Rumbaugh
Identity, classification, polymorphism, and inheritance

객체 지향 설계
추상화(Abstraction)
정보 은폐(Information hiding)
모듈화(Modulality)

1 객체 지향 개념(The Object Oriented Idea)
객체 지향 프로그래밍 특징
(1) 객체(Object)
(2) 클래스(Classes)
(3) 메시지(Messages)
(4) 캡슐화(Encapsulation)
(5) 상속(Inheritance)
(6) 다형성(Polimolphism)

1.1 Objects(객체)
객체란?
∙어떤 실세계의 일이나 사건의 컴퓨터 표현
∙시스템의 하나의 물리적인 개체(entity)로서 어떤 행위를 할 수 있는 한 단위
∙시스템을 구성하는 실체이며, 한 개체의 상태변화를 표현하는 기본단위

객체 식별
1) 시스템 분석자료로부터 명사 또는 명사절을 추출하여 별도의 표를 작성
2) 동의어 등과 명령적인 절차명을 정리
3) 다음 사항중 하나에 속하는지를 판단하여 객체를 식별.
- 외부 실체(external entity)
- 사물(thing)
- 조직(organization units)
- 상황이나 사건(occurences or events)
- 장소(places)
- 역할(roles)
- 객체구조(structures)
4) 수행절차나 연산, 행위같은 명령을 객체로 식별하지 않았는지를 점검.
∙ 속성(Attribute) : 객체를 정의 또는 설명해주는 것
∙ 메소드(Method) : 객체 내에 포함된 하나 이상의 속성 값을 변경시키는 것

1.2 클래스(Classes)
유사한 객체들의 집합
각 객체 : 클래스의 실체(instance)라고 한다
객체는 클래스를 설정함으로써 생성될 수 있다
실체는 클래스에 create나 new 등의 메시지 전달로 생성
1.3 메시지(Messages)
객체의 행위(Behavior)를 표현
1.4 캡슐화(Encapsulation)
∙추상화된 객체의 구현을 은닉하는 것
∙시스템의 한 콤포넌트의 내부 구현이 다른 콤포넌트에 의존하지 않는 것
∙추상화는 객체의 외부 인터페이스에 초점을 맞추지만 캡슐화는 객체 내부의 구현을 client에게 보이지 않게 하는 것
∙프로그래밍 언어에 따라 구현하는 강도가 다르다
∙동작을 일으키는 구현에 중점을 둔다

1.5 상속(Inheritance)
상속이란?
하나의 클래스가 다른 클래스로부터 애트리뷰트나 메소드를 물려받는 것
∙단일상속
∙다중상속

1.6 다형성(Polymorphism)

파생된 클래스와 관련되면서 또 다른 행위를 요구하는 것

2 객체 지향 분석(Object-Oriented Analysys)
(1) 클래스/객체 계층 ; 클래스와 객체를 설명하는 분석과 설계 단계
(2) 구 조 계 층 ; 1:n의 결합이나 상속과 같은 클래스와 객체들의 여러가지 구조를 포함시키는 단계
(3) 속 성 계 층 ; 메시지와 행위를 기술하는 단계
(4) 서 비 스 계 층 ; 클래스의 속성을 자세히 기술하는 단계
(5) 주 제 계 층 ; 실행 단위 또는 팀으로 설계를 분할하는 단계

2.1. 클래스와 객체의 분석(Analyzing Classes and Objects)

분석하는 동안에 찾을 수 있는 객체
. 유형의 사물
. 임무
. 사건들이나 결과
. 특별한 시간
. 서로 영향을 주는 것

클래스 판단 기준
1. 객체를 기억할 필요가 있다.
2. 객체의 어떤 행동들을 필요를 역설한다.
3. 한 객체는 여러 개의 속성을 갖게 된다.
4. 기본 클래스가 아니라면 하나의 클래스는 한 개 이상의 객체를 갖게 된다.
5. 속성들은 클래스에 속한 각각의 객체를 위한 의미 있는 값을 항상 가진다.
6. 서비스들은 클래스에 속한 모든 객체들에 대하여 항상 같은 방법으로 제공된다.
7. 객체는 해결기술이 아니라 문제발생으로부터 파생되어진 요구를 실행시키는 것.
8. 객체는 시스템내의 다른 객체에서 파생될 수 있는 중복된 속성이나 서비스일 수 없다.

2.2. 분석 구조(Analyzing Structure)
(1) Gen-Spec 구조 :
(2) Whole-Part 구조 :

2.3. 속성 분석(Analyzing Attribute)

클래스 속성의 명칭은 설계도상에서 클래스 상자의 가운데 부분에 쓰여진다.

2.4. 실체 관계(Instance Connection)

클래스들 사이가 아닌 객체들 사이에서 실체관계에 대한 설명이 항상 이루어진다.

2.5. 예비 명세서 모형(Preliminary Specification Temlate)

속성의 소개를 위해 분석 명세서가 필요하다.

2.6. 서비스 분석(Analyzing Service)

- 서비스 :
방법(methods) 또는 절차(procedures)
많은 면에서 객체의 일 부분
객체상태분석, 서비스 명세서 그리고 메시지 명세서 등의 세 가지로 구성

(1) 객체 상태 분석(Object State Analysis)
- 객체의 행동을 바꾸는 속성을 조사.
. 각 속성을 조사
. 어떤 상황하에서 다른 행위를 하게 되면 “상태” 속성을 추가.
(2) 서비스 명세서(Service Specification)
- 서비스는 객체생성, 저장, 검색, 결합, 취득, 객체 삭제 등을 포함
- 단순한 서비스들
- 복잡한 서비스들 :
(3) 메시지 명세서(Message Specification)
- 한 객체의 행위가 어떻게 다른 객체의 행동을 유발할 수 있는가를 서술
- 다른객체의 행동을 유발시키기 위한 목적으로 한 객체에 의해 만들어짐
- 서로 다른객체에 있는 별개의 절차에 한개의 절차가 종속되어져 있는 것을 기술
- 서비스들 사이 연결을 위해 하나만 존재, 제어흐름과 데이터 흐름 모두를 필요로 함
- 메시지는 보내는 서비스와 받는 서비스로 구분

2.7. 명세서 모형 구축(Assembling the Specification Template)
- 규정해야 할 필요가 있는 어떤 중요한 객체를 상세하게

2.8. 주제 분석(Analysing Subjects)
- 복잡한 명세서를 논리적 작업단위로 분할하는 단계
- 많은 클래스와 관련된 큰 프로젝트에서만 필요
- 주제는 객체지향 도표에 특별한 주제의 배경을 기술하는 넓은 그림자로 표시
- 주제명칭은 주제상자의 한 부분에 기술
- 일반적으로 주제는 ‘Owner’ 클래스에서 나타난다

2.9. 객체 지향 설계(Object-Oriented Design)
명세서를 완성시킬 분석 도구를 도입
- 객체 지향 설계 작업의 구성 요소
∙문제요소
∙인간과의 교류요소
∙데이타 관리요소
∙작업관리 요소

'UP! > Software Engineering' 카테고리의 다른 글

시스템구현 (0)	2008.08.21
[CMMI] CMMI Project Status (0)	2008.08.21
문서화 (0)	2008.08.21
CASE (0)	2008.08.21
소프트웨어 시험전략 (0)	2008.08.21

Posted by 으랏차

,

문서화

UP!/Software Engineering 2008. 8. 21. 14:00

21. 문 서 화
소프트웨어 구성
∙프로그램
∙데이터
∙문서

1 시스템 설계의 순서

시스템 설계의 개요
∙ 현상 분석 :
∙ 기본 설계 :
∙ 상세 설계 :

2 문서류 작성 순서
시스템설계의 순서 ⇔ 문서류 작성처리 순서
문서류를 차례로 작성 ⇔ 시스템 설계 구체화 의미

3 문서류 작성 순서의 설명

1) 기능 블럭도표를 작성
2) 조사 노트 작성
3) 기재하지 않은 전표나 장표의 표본(Sample)과, 정상적으로 기재한 전표, 장표의 표본을 수집
4) 현상 분석에 입각하여 새로운 시스템이 무엇을 하면 좋을지를 생각
5) 컴퓨터를 사용해서 어떤 형태의 출력을 어떤 주기로 제공할 것인가를 검토.
6) 결정된 출력을 기준으로, 출력 작성에 필요한 항목이 입력으로부터 들어오는가, 파일로부터 들어오는가 등을 분석
7) 설계를 효과적으로 수행하기 위하여 입력 설명서, 파일 설명서, 기본 도표를 작성하여 새로운 시스템의 요구 조건을 명백히 한다.
8) 전산화를 위해 필요한 코드 확정
9) 위의 4)～7)의 검토에 의해 나타난 시스템의 요구 조건을 구체적으로 시스템을 설계
10) 프로그래밍 설명서 작성

4 현상 분석과 문서화

1 MACRO 업무기능분석
1) 일반적인 업무활동

일반적인 업무활동

2) MACRO 업무 분석의 의의
① 기업 전체의 업무 기능을 나타낼 수 있고, 조사의 지연이나 재조사를 막을 수 있다.
② 기능 블록은 조사 대상 단위가 된다.
③ 업무 기능의 간섭이 명확하게 되어 부 시스템 단위의 기계화의 방향을 보다 올바르게 유도한다.
④ 시스템 관리를 위한 새로운 수법 도입 시 검토용이
⑤ 이 분석에 의해 표현된 기능 블록은 각각 기계화의 가능성, 구분성 또는 기계화 필수 부분 등의 판정 단위로 된다.

3) 기능 블록 도표의 작성 방법
① 면접 조사
② 참고 자료 조사
③ 기술 방법 결정

2 MICRO 업무 기능 분석
① 조사단위의 설정과 조사계획의 수립
② 조사 장부의 작성
- 조사범위, 조사계획 , 조사장부
③ 기능 설명서의 작성

3 문서 작성
1 기능 설명서의 기술 방법
- 흐름도의 기술
- 입력의 기술
- 출력의 기술
- 파일 사용의 기술
- 함수, 기능의 기술

2 전표와 장표의 표본 수집
표본은 기입하지 않은 것과 표본의 업무에 정통한 사람이 정상적으로 기입한 전표와 장표를 모두 수집한다.

3 논리표의 작성
(1) 논리도표
(2) 결정 테이블

4 기본설계
1) 귀납적 접근방법
2) 연역적 접근방법
3) 창조적 접근방법

5 전산화의 검토
현행업무의 필요성을 검토하여 판정하는 단계
1 전산화의 검토표
2 논리 도표를 사용한 전산화 검토

6 문서 작성의 기본 항목
1) 입출력(I/O)파일의 관련 분석
2) 입력 설명서
3) 파일 설명서
4) 출력 설명서
5) 기타 설계 명세서
① 코드 설계 명세서
② 시스템 개념도 : 8장 참조
③ 자료 흐름도(DFD) 또는 개체 관계도(ERD) : 8장과 9장 참조
④ 자료사전
⑤ 프로세스 명세서
⑥ 프로그램 설계 기준 명세서

'UP! > Software Engineering' 카테고리의 다른 글

[CMMI] CMMI Project Status (0)	2008.08.21
객체지향 분석과 설계 (0)	2008.08.21
CASE (0)	2008.08.21
소프트웨어 시험전략 (0)	2008.08.21
S/W 시험 (0)	2008.08.21

Posted by 으랏차

,

CASE

UP!/Software Engineering 2008. 8. 21. 13:59

20 CASE
CASE(Computer Aided Software Engineering)란
- 소프트웨어 수명주기 전 단계에서 사용되는 개발도구와 방법론을 이용하여 시스템 개발자들이 수작업으로 진행하고 있는 분석,

설계, 구현, 유지보수 과정을 자동화하거나 개발을 지원하도록 하는 시스템을 의미
- 소프트웨어 개발자동화를 지원하는 도구
- 정보 시스템 개발조직의 표준화 지원
- 소프트웨어 공학과정에서 필요로 하는 모든 도구들

1 CASE의 출현배경
1. 소프트웨어의 위기
2. 신기료 증후군(shoe-maker's syndrome)
3. 시스템 복잡도 증가 및 의사소통의 어려움 증가

2 CASE의 기능
(1) 체계적인 시스템 기술(記術)능력
(2) 분석기능
(3) 소프트웨어 수명주기 통합․지원
(4) 정보저장 기능
(5) 시스템 구조(system architecture)를 표현하는 기능

3 CASE의 분류
3.1 생명주기에 따른 분류
(1) 상위 CASE:
① 기능:
기능 모형, 분해도, 자료흐름도, 개체관계도, 액션 다이어그램, 프로세스 명세서, 화면 설계, 보고서작성, 자료구조도 등을 작성
② CASE 상품예:
SA, XL, Silverrun, OpenSelect, ER-Win, S-Designer, Bachman, PC-Prism, ISP, Excelerator 등

(2) 하위 CASE:
① 기능:
데이터베이스의 스키마 생성, 코드생성, 스키마 생성이나 코딩, 문서작성
② CASE 상품예:
Telon, Corvision, Esprit, Yesman, SQL/Windows, Power Builder 등
(3) 통합 CASE:
① 기능: 개발 단계의 전 공정 지원
② CASE 상품예: System Architect, Teamwork, ADW, IEF(Information Engineering Facility), PRIDE, Foundation,

CASE*Dictionary CASE*Designer, CASE* Generator, Promod, VAXset/DECdesign 등

통합 CASE가 가져야할 기능
① 공통된 자료 관리나 공통된 도구접근방법
② 객체 관리 시스템 구축
③ 인터페이스는 일관성 있게 제공
④ 도구들을 제어하는 기법, 기교 구비

3.2 기능에 따른 분류
① 개발일정과 자원을 관리하는 프로젝트 관리용
② 실제로 산출물을 생산하는 개발지원용
③ 정보자원의 통합 및 변경사항을 지원하는 정보저장소 (repository) 관리용
④ 프로젝트 관리 및 개발지원을 통합한 체계의 방법론 지원용

(1) 프로젝트 관리기능
① 업무 시스템 계획도구(business system planning tool):
② 프로젝트 관리도구(project management tool):
․프로젝트 계획도구
․요구사항 추적도구
․매트릭스와 관리도구

(2) 개발지원 도구
① 분석 및 설계도구
② 프로그래밍 도구
③ 지원도구

(3) 정보저장소 도구(database or repository)
① 개방된 정보저장소로서 다른 정보저장소와 데이터를 주고받아야 한다.
② 객체나 프로젝트간의 변경 관리기능을 가져야 한다.
③ 보안 관리기능을 가져야 한다.
④ 필요한 때, 필요한 형태의 유틸리티를 사용자가 개발, 사용할 수 있어 야 한다.

(4) 통합환경이나 방법론 지원도구
① 프레임워크 도구: CASE 도구들의 통합 처리능력 제공

3.3 지원범위에 따른 분류
① CASE Tool
② CASE Tool Kit
③ CASE Workbench
④ CASE Methodology Companion

3.4 통합 정도에 따른 분류
① 단위(stand-alone) CASE
② 통합(file-based integration) CASE

3.5 시스템 유형별 분류
① 메인 프레임 기준의 CASE
② UNIX 기준의 CASE
③ PC 기준의 CASE

3.6 규모와 가격으로 분류
① 대규모 CASE
② 소형 CASE

4 CASE 활용의 장단점
(1) 장점
∙빠르고 정확하게
∙일관성 유지
∙개발 생산성과 효율성 제고
① 그래픽을 이용한 다이어그램 작성도구 사용
② 국제표준화기구에서 정보저장소(repository)간의 데이터 전송 표준화를 추구
③ 소프트웨어 품질 향상, 수정 및 변경요구에 신속 대처 가능
④ 자동화된 코드생성에 의해 개발기간 단축
⑤ 문서화가 쉽다
⑥ 업무의 특성에 따라 단위 CASE를 사용하여 부분별 생산 성 향상을 기할 수 있다.

(2) 단점
① CASE마다 다른 점들이 있으므로 통합하는 데 어려움이 있다.
② CASE를 과신하는 경우, 도구에만 의존하여 오류발견이 늦을 수 있다.
③ 여러 CASE의 기능을 파악하고 있는 전문인력 확보하기가 어렵다.
④ 사용자 및 담당자의 교육에 많은 시간이 소요되어 개발부담이 가중된다.

5 전 망
(1) CASE TOOL의 보편화:
(2) 일반사용자 컴퓨팅:
(3) 지능형 CASE:
(4) 통합 CASE:

6 Nolan의 기술발전 6단계
① 조직 내의 시스템 개발환경의 평가작업
② 비전(vision)의 제시
③ 경영진의 지원약속 및 인식확립
④ 개발환경의 선택

7 CASE 툴의 선정기준
(1) 개발방법론 지원
(2) 사용자 인터페이스
(3) 데이터 관리기능
(4) 호환성
(5) 통합성

'UP! > Software Engineering' 카테고리의 다른 글

객체지향 분석과 설계 (0)	2008.08.21
문서화 (0)	2008.08.21
소프트웨어 시험전략 (0)	2008.08.21
S/W 시험 (0)	2008.08.21
DB 설계 (0)	2008.08.21

Posted by 으랏차

,

소프트웨어 시험전략

UP!/Software Engineering 2008. 8. 21. 13:59

19 소프트웨어 시험 전략

1. 시스템 통합 시험

시스템 통합시험이란
모듈별 테스트가 끝난 후 이 모듈들을 통합시켜 놓았을 때, 원하는 결과가 나오는가를 확인하여 그 통합순서를 확정하여 프로그램구조로 바꾸는 것이다.

시스템 통합시험의 목적
조기에 골격 코드 작성 가능토록
골격코드의 접속관계 확인
간단한 테스트 사례 표현

통합시험 방법
비 단계적통합
단계적 통합
하향식 통합방법
상향식 통합방법

1.1 하향식 통합
오류가 초기에 발견되어야만 하는 경우에 좋은 방법
깊이우선(depth-first) 방법 : A,B,E,F,H,C,G,D 순서
넓이우선(breath-first) 방법 : A,B,C,D,E,F,G,H 순서

하향식 통합시험

1.2 상향식 통합
프로그램구조의 하위수준인 모듈부터 한 단계씩 위로 통합하는 방법
(1) 1단계 통합시험
기능의 정확성
요구사항 수행 정도
범위이내의 값
특정값
범위이외의 값

(2) 2단계 통합시험
사용 편의성
작업 방법
사용 언어
사용 규칙 준수
사용 파일
작업 환경

(3) 3단계 통합시험
오류 검출
문제점에 대한 정의
해결방안 모색

2 개발된 소프트웨어의 통합시 중점 점검사항
(1) 정확성(accuracy)
(2) 의사 교환성(communicativeness)
(3) 완전성(completness)
(4) 일관성(consistency)
(5) 오류 허용성(error telerance)
(6) 모듈성(modularity)
(7) 응답시간 적합성(response time adequacy)
(8) 구조적 단순성(structural simplicity)
(9) 시험 적합성(test adequacy)
(10) 추적 가능성(traceability)
(11) 시험도구 설비성(instrumentation)

시험 도구의 분류
Miller의 분류
정적 분석기(static analyzer)
코드 감사(code auditor)
단언 처리기(assertion processor)
시험 파일 생성기(test file generator)
시험 자료 생성기(test data generator)
시험 검증기(test verifier)
시험 장치(test harness)
결과 비교기(output comparator)
Dunn이 추가한 사항
기호 실행(symbolic execution) 시스템
환경 시뮬레이터(environment simulators)
자료 흐름 분석기(data flow analyzers)

3 시스템 수준 테스트

시스템 수준 테스트란
전체로서의 시스템을 테스트하는 것

시스템 수준 테스트의 종류

1. 시스템 수준 수용 테스트(System Test)
2. 기능 테스트(Functional Test)
3. 유용성 테스트(Usability Test)
4. 과부하 테스트(Stress Test)
5. 성능 테스트(Performance Test)
6. 신뢰성 테스트(Reliability Test)
7. 복구성 테스트(Recovery Test)
8. 안전성 테스트(Security Test)
9. 회귀 테스트(Regression Test)

4 사용자 수용 테스트

사용자의 요구를 만족하는가를 검증하는 시험
사용자 참여
테스트의 명확한 목표설정 및 계획을 수립
시스템 수준 테스트나 통상적 운영자료의 일부분을 테스트 사례로 사용
실제 사용되는 데이터 활용
운영가능 여부를 판단하는 최종 절차
시스템의 기능을 상세히 검증하기 위한 테스트
시스템을 이관하기 위한 공식적인 형식절차
정해진 기간 안에 이루어져야하는 테스트

'UP! > Software Engineering' 카테고리의 다른 글

문서화 (0)	2008.08.21
CASE (0)	2008.08.21
S/W 시험 (0)	2008.08.21
DB 설계 (0)	2008.08.21
파일설계 (0)	2008.08.21

Posted by 으랏차

,

S/W 시험

UP!/Software Engineering 2008. 8. 21. 13:59

18 소프트웨어 시험(테스팅)

1 시험의 정의
-IEEE- 소프트웨어의 시험은 정의되어진 요구사항의 만족도 및 예상결과와 실제 결과와의 차이점을 검사하기 위하여 수동 혹은 자동으로 시스템을 수행 혹은 평가하는 과정이다.
-Glen Myers- 소프트웨어의 시험은 오류를 찾아내고자 하는 목적으로 프로그램 혹은 시스템을 수행하는 과정이며, 오류의 조기발견과 수정, 진행과정의 평가 및 결과에 대한 확인이다. 또한 소프트웨어 개발주기의 각 단계에서 시험 요구사항이 정의되고, 오류를 많이 발견할 수 있을 때 시험은 성공적이라 할 수 있다. 좋은 시험사례는 아직 발견되지 않은 오류를 찾아내는 확률이 높고, 성공적인 시험은 아직까지 발견되지 않은 오류를 발견해내는 것이다. 또한 시험 그 자체도 계획수립, 설계, 및 시험이 필요하다.
-Roger S. Pressman- 시험은 결함이 없다는 것을 보여줄 수는 없고, 단지 소프트웨어 결함이 나타나는 것만을 보여준다.
-이 주헌- 소프트웨어의 시험은 개발된 원시코드의 품질을 평가하는 것이 아니라 노출되지 않은 숨어있는 결함을 찾기위해 소프트웨어를 작동시키는 일련의 행위와 절차를 말한다.

2 시험의 사례
인력, 시간, 비용을 최소화하면서 결함발견 확률을 높일 수 있는 시험 가능한 사례

1) 블랙박스 시험(Black Box Test) :
부정확하거나 빠진 기능이 없이 완벽하게 작동하는지를 시험
입력, 출력은 정확한지를 검사하는 시험
자료 구조 결함, 성능결함, 시작과 종결상의 결함, 인터페이스 결함에 대하여 실시
시스템 측면만을 시험
목적코드를 수행시켜가면서 시험

2) 화이트박스 시험(White Box Test) :
특수한 조건이나 반복작업과 같은 세부적인 절차에 대한 시험
한정된 수의 중요한 논리적인 경로만 시험
완벽한 시험 곤란
프로그램의 모든 경로가 단 한번이라도 수행되도록 시험 설계

3 시험의 변화

과거
소프트웨어 개발주기 마지막 단계에서 프로그램을 시험하는 것으로 인식
개발단계마다 시험하지 않고, 마지막 단계에서 집중적인 시험 ⇒ 개발 지연 원인
현재
디버깅은 프로그래머의 영역
계획에 따라 검증, 확인하는 작업
사용자나 시험자가 수행시키면서 결함 발견
여러 가지 시험 데이터와 사례들을 만들어 시행

4 시험의 특성

완벽하고 철저한 시험은 불가능
기능을 전부 시험하기 위한 경우의 수는 너무 많다
시험을 위한 모든 데이터 작성 곤란
시험을 하는 목적 ⇒ 오류를 사전에 방지하기 위한 것
실행 중에 나타날 오류를 미리 정정

5 시험의 단계별 순서

1) 요구 분석 및 계획 단계
① 신 시스템의 현재 시스템 대체 가능성 검토, 대체안과 일정계획 작성
② 마스터 파일 구조, 데이터 베이스 구축 기술 검사
③ 시험 방법 결정, 시험 도구 선정
④ 시험 기준을 설정

2) 설계 단계
① 시험 기기 구성을 결정
② 시험 계획 수립. 즉, 시험의 체제, 방법, 항목, 환경, 일정 계획을 결정
③ 시험 도구를 설계
④ 설계의 실행 가능성 검토
⑤ 시험 시행 문제점 검토

3) 코딩 단계
① 모듈, 모듈간, 프로그램간의 결합시험 위한 사양 설계
② 시스템 시험을 위해 고려해야할 사항을 설계
기능, 성능, 형상, 구조적 코딩, 표준화 형태, 문서화 기준을 설계
③ 디버그 시스템이나 디버그 도구 같은 시험도구 작성
④ 시험계획서와 시스템 설계 내용의 일치 확인
· 기능
· 프로그램간의 인터페이스
· 성능 처리능력
· 프로그램 구조 유연성
· 시험 항목의 누락
· 실시 문제점
⑤ 시험 실시 계획을 세운다.
· Simulator 사용여부 결정, 사용방법 습득
· 각종장치의 사용방법 습득
· 시험 데이터 작성

4) 시험단계
① 모듈 시험
데이터 인터페이스, 자료구조상의 오류, 논리경로, 데이터 범위
② 결합 시험
모듈, 프로그램, 부 시스템, 시스템, 결합 단계마다 기능 시험
결합시험의 특징
(ㄱ) 하향식 결합시험
(ㄴ) 상향식 결합시험
(ㄷ) 샌드위치 결합시험
(ㄹ) Big Bang 결합시험
③ 시스템 시험
전체적인 시나리오를 구성하여 기능들의 연관관계를 시험
(ㄱ) 기능 시험    (ㅁ) 과부하 시험
(ㄴ) 유용성 시험    (ㅂ) 복구성 시험
(ㄷ) 성능 시험 (ㅅ) 안정성 시험
(ㄹ) 신뢰성 시험    (ㅇ) 설치용이성 시험

5) 유지보수 단계
① 회귀 시험
유지보수 단계, 문제해결, 새 기능 추가할 때, 변경된 부분과 대조하여 시스템을 다시 시험하는 것

6 검토, 검사 및 검증
6.1 검토 및 검사

검토(Review)란?
제품의 특정 부분을 다른 개발요원과 함께 조사하는 비 정형적 방법
수명주기 전 과정에서 수시 실행

검사(Inspection)란?
제품 품질을 평가 ⇒ 개선키 위한 조사
외부 설계 검사
내부 설계 검사
상세 설계 검사
코딩 검사
시험 계획 검사

1) 외부 및 내부 설계 검사 단계에서 조사해야할 사항
① 완전성 : 요구 기능, 성능 포함 여부
② 일관성 : 용어 정의 및 사용의 표준화
③ 정확성 : 입,출력 및 알고리즘의 정확
④ 확장성 : 기능, 데이터 량의 증가에 적응

2) 상세 설계 검사 및 코드 검사 단계에서 조사해야 할 사항
① 부 프로그램과의 접속 관계
② 판단 논리
③ 계산식
④ 입출력
⑤ 주석
⑥ 자료흐름, 기억장소 사용

3) 시험계획 의 작성 과정
① 검증해야할 요구사항을 식별
② 검증활동을 위한 검증 순서를 결정
③ 검증에 대한 요구사항과 관련된 소프트웨어 식별
④ 검증에 대한 요구사항과 관련된 소프트웨어 집단화
⑤ 테스트 순서도 작성
⑥ 테스트를 위해 필요한 자원 조사
⑦ 테스트 일정계획 작성

6.2 검정(verification)과 검증(validation)

1) 검정(verification)
생산품이 이전 단계에서 수립된 요구들을 수행하는가를 결정하는 과정
프로그램의 정확도, 항목, 프로세스, 서비스, 문서들이 요구에 맞는지 조사하고 문서화하는 행위
① 주기 검정(life-cycle verification)
② 형식 검정(formal verification)

2) 검증(validation)
소프트웨어 개발과정의 끝 부분에서 소프트웨어를 평가하는 과정
데이터가 미리 명시된 제약조건을 만족하는지를 증명하는 것

'UP! > Software Engineering' 카테고리의 다른 글

CASE (0)	2008.08.21
소프트웨어 시험전략 (0)	2008.08.21
DB 설계 (0)	2008.08.21
파일설계 (0)	2008.08.21
입력과 출력 설계 (0)	2008.08.21

Posted by 으랏차

,

으랏차

'UP!/Software Engineering'에 해당되는 글 28건

ERP의 활용과 필요성

'UP! > Software Engineering' 카테고리의 다른 글

전사적 자원관리(Enterprise Resource Planning : ERP)

'UP! > Software Engineering' 카테고리의 다른 글

공급망관리

'UP! > Software Engineering' 카테고리의 다른 글

시스템구현

'UP! > Software Engineering' 카테고리의 다른 글

[CMMI] CMMI Project Status

'UP! > Software Engineering' 카테고리의 다른 글

객체지향 분석과 설계

'UP! > Software Engineering' 카테고리의 다른 글

문서화

'UP! > Software Engineering' 카테고리의 다른 글

CASE

'UP! > Software Engineering' 카테고리의 다른 글

소프트웨어 시험전략

'UP! > Software Engineering' 카테고리의 다른 글

S/W 시험

'UP! > Software Engineering' 카테고리의 다른 글

카테고리

태그목록

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

달력

링크

티스토리툴바


	by 으랏차