Chapter 2 정보시스템 아키텍처 (IS Architecture) 시스템분석 및 설계 Chapter 2 정보시스템 아키텍처 (IS Architecture)

목 차 0. 학습개요 및 학습목표 1. 정보시스템 아키텍처의 개념과 필요성 2. 통합정보시스템 아키텍처 목 차 0. 학습개요 및 학습목표 1. 정보시스템 아키텍처의 개념과 필요성 1.1 정보시스템 아키텍처의 개념과 내용 1.2 정보시스템 아키텍처의 필요성 2. 통합정보시스템 아키텍처 2.1 시스템 뷰(View) 2.2 시스템 레벨(Level)

0. 학습목표 및 학습개요 정보시스템 아키텍처의 개념과 정의를 이해한다. 정보시스템 아키텍처의 필요성에 대해서 이해한다. 시스템개발에 있어서 정보시스템 아키텍처의 역할을 이해한다. 통합정보시스템 아키텍처에 대해서 학습한다. 시스템 뷰와 시스템 레벨의 개념과 관계를 학습한다. 시스템 뷰와 시스템 레벨의 개념을 이용한 시스템분 석 및 설계대상, 설계절차를 이해하고 학습한다.

1. 정보시스템 아키텍처의 개념과 필요성 시스템분석 및 설계의 이해 Tool Methodology IT Solutions (Information Systems) Business Requirement Analysis & Design & Implementation Business Problems (Reality)

1. 정보시스템 아키텍처의 개념과 필요성 1.1 정보시스템 아키텍처의 개념과 내용 사전적 의미: 건축공학분야에서 주로 사용 시스템개발 분야에서의 의미: 정보시스템의 구성요소, 구성요소의 특징, 구성요소 간의 관계를 나타내기 위한 의미로 사용 갖추어야 할 기능 개별 기능 사이의 연관관계 구현방법  시스템개발을 위한 컨셉트 사용자요구정의/설계/구현에 대한 프레임워크

1. 정보시스템 아키텍처의 개념과 필요성 시스템분석 및 설계의 범위 사용자의 요구에 맞는 시스템을 개발하기 위해서 어떤 내용을 분석 및 설계대상으로 하여야 하는가? 시스템분석 및 설계의 범위(대상)  시스템의 구성요소 프로세스(기능과 데이터 포함) 컴퓨터시스템 구성조직  프로세스, 시스템, 조직을 연결한 통합프로세스(integrated Process)

1. 정보시스템 아키텍처의 개념과 필요성 통합프로세스의 예

1. 정보시스템 아키텍처의 개념과 필요성 시스템분석 및 설계의 절차 시스템개발을 위한 라이프사이클(System Development Life Cycle) 시스템개발 방법론의 개념과 동일

1. 정보시스템 아키텍처의 개념과 필요성 프로세스 및 조직관리 측면에서의 효용 기업의 목표달성을 위해서 비즈니스 프로세스가 정의되며, 이는 단위 프로세스들이 연속된 형태로 나타남. 단위 프로세스에는 투입/산출데이터, 프로세스수행 주체가 연결됨. 투입/산출데이터, 수행주체  기업의 조직 정보시스템 아키텍처는 기업조직(투입/산출데이터, 수행주체)을 분석하고 설계하기 위한 프레임워크이기 때문에, 조직관리 및 프로세스 관리에 중요한 의미를 갖는다.

1. 정보시스템 아키텍처의 개념과 필요성 1.2 정보시스템 아키텍처의 필요성 프로세스 및 조직관리 측면에서의 효용 비즈니스 프로세스의 변화는 기업조직의 변화를 의미하기 때문에, 비즈니스 프로세스의 변화 즉, 조직변화를 최적화하기 위한 수단으로 활용 효율적인 비즈니스 프로세스모델을 작성하기 위한 프레임워크가 필요 비즈니스 프로세스모델은 단순한 단위 프로세스의 연속이 아니라, 다양한 정보와 데이터를 포함한 수많은 산출물(문서)을 생성하기 때문에, 이를 효율적으로 관리하기 위해서 필요 표준소프트웨어를 구입하여 커스터마이징, 워크플로우 시스템구현 등 다양한 IT Solutions 구현 조직변화, 문서관리, IT Solutions 구현을 위해서 필요 조직변화, 문서관리, IT Solutions 의 효율적 구현

1. 정보시스템 아키텍처의 개념과 필요성 프로세스 및 조직관리 측면에서의 효용 조직의 목적달성 업무의 효율화  비즈니스 프로세스의 효율적 재설계를 통해서 이루어지기 때문에, 이를 위한 아키텍처가 필요 데이터/정보흐름의 간소화  비즈니스 프로세스의 간소화를 통해서 이루어지기 때문에, 이를 위한 아키텍처가 필요 투입/산출되는 문서의 양 축소  비즈니스 프로세스의 간소화를 통해서 이루어지기 때문에, 이를 위한 아키텍처가 필요 효율적인 조직구조  비즈니스 프로세스의 효율적 재설계는 조직구조의 효율적 변화를 의미하기 때문에, 이를 위한 아키텍처가 필요  비즈니스 프로세스 모델을 작성하기 위한 프레임워크가 필요

1. 정보시스템 아키텍처의 개념과 필요성 시스템개발 측면에서의 효용 시스템개발 방법 직접구현: 자체적인 분석&설계를 통해서 구현 간접구현: 표준소프트웨어의 구입 간접구현의 경우: ISA의 의미 직접구현의 경우: ISA의 선택에 따라서 개발될 시스템의 품질/효율성/비용이 결정 부분작업을 통해서 개발이 이루어지기 때문에, 작업자간의 의사소통을 위한 도구로 활용 부분작업 간의 일관성을 유지하기 위해서 작업내용의 중복을 없애기 위해서

2. 통합정보시스템 아키텍처 2.1 시스템 뷰(View) 시스템 뷰: 복잡한 비즈니스 프로세스를 나누는 기준

2. 통합정보시스템 아키텍처 비즈니스 프로세스 사례 “ 고객주문이 접수되면, 고객데이터와 고객이 주문한 제품에 대한 데이터에 근거하여 시스템을 이용하여 판매부서의 담당자가 고객주문 업무를 처리하며, 그 결과 고객주문서가 작성된다. 주문처리가 완료되면, 주문제품을 생산해야 한다는 전제 하에 공급업체와 자재 그리고 고객주문제품에 대한 데이터를 근거로 필요한 주문제품을 생산하는데 필요한 자재에 대한 구매주문 작업에 들어간다. “  프로세스에 관련된 업무, 데이터, 담당부서, 담당자, … 을 동시에 고려하여 모델링하는 것이 복잡하기 때문에, 일정 기준으로 나누어 독립적으로 작업한 후, 이를 통합하여 전체 비즈니스 프로세스 모델을 완성

2. 통합정보시스템 아키텍처 일반적인 분할기준 CIMOSA Architecture: 기능, 자원, 정보, 조직 Zachmann Architecture: 데이터, 기능, 네트워크, 사람, 시간, 동기 ARIS Architecture: 데이터, 자원, 조직, 이벤트, 서비스 OOA/OMT Method: 기능, 정보 E-R Method: 개체(데이터)와 개체사이의 관계 IEM Method: 기능, 데이터 iPROMODA Architecture: 데이터, 기능, 조직, 자원

2. 통합정보시스템 아키텍처 iPROMODA Architecture 데이터 기능 조직 자원 고객주문접수 주문체크 생산계획수립 제품 고객주문내역 판매부서 생산부서 고객신용도 제품재고 작업스케줄 자재소요 작업데이터 제품데이터 정보/데이터 흐름 업무기능 흐름 조직간 커뮤니케이션 생산계획 정보개체 업무기능 정보 플로우 데이터 기능 조직 자원

Excurse: Symbol in iPROMODA 사람(People) 또는 조직( Organizations) 행위(Activities), 단계(Steps) 또는 기능(Functions) 입력(Inputs), 산출(Outputs) 그리고 데이터(Data) 규칙(Rules) 그리고 의사결정(Decisions)

Excurse: Business Process in iPROMODA 사건(Event) – 기능(Function) 사건은 기능을 유발시킨다. 자체정비 가능판정 자체정비 자체정비 완료 장비 수리 신청 접수됨 신청내용 분석 사건 기능 자체정비 불가판정 상급부대 정비요청 상급부대 정비요청 완료 사건의 결과 기능 사건 기능은 사건을 생성한다.

Excurse: Business Process in iPROMODA 사건(event) - 기능(function) - 데이터(Data) 데이터는 기능 내에서 처리된다. 자체정비 가능판정 자체정비 자체정비 완료 장비 수리 신청 접수됨 신청내용 분석 정비관련 정보 사건 장비수리 신청정보 자체정비 불가판정 상급부대 정비요청 상급부대 정비요청 완료 사건의 결과 사건 상급부대 정비요청 정보

Excurse: Business Process in iPROMODA 정비대대 사건(event) - 기능(function) - 데이터(Data) - 조직(Organization) 담당자는 기능을 책임진다. 정비담당 자체정비 가능판정 자체정비 자체정비 완료 정비대대 담당기술병 정비관련 정보 장비 수리 신청 접수됨 신청내용 분석 정비대대 담당기술병 사건 장비수리 신청정보 자체정비 불가판정 상급부대 정비요청 상급부대 정비요청 완료 사건의 결과 사건 상급부대 정비요청 정보

Excurse: View in iPROMODA 상이한 관점에 따라 업무 프로세스를 분리 복잡성 감소 데이터 관점 장비수리 신청정보 장비 수리 신청 접수됨 신청내용 분석 자체정비 가능 자체정비 . . . 기능 관점 정비대대 담당기술병 조직 관점

2. 통합정보시스템 아키텍처 iPROMODA Architecture 의 시스템 뷰

2. 통합정보시스템 아키텍처 2.2 시스템 레벨(Level) 시스템 레벨: 각각의 부분모델을 구체화하는 과정(절차)

2. 통합정보시스템 아키텍처 Requirements Definition – Function Function Tree(기능도): 기능을 여러 개의 하부기능으로 나누어 체계적인 계층구조를 확정  기능사이의 정적인 연관관계

2. 통합정보시스템 아키텍처 Requirements Definition – Function Work Flow Diagram(기능처리 수행도): 업무가 처리되는 순서  동적인 연관관계

2. 통합정보시스템 아키텍처 Requirements Definition – Organization Organization Chart(조직도): 누가 어떤 기능을 수행하는지? 어떤 기능의 수행책임이 어느 조직단위 내지는 어느 조직구성원에게 있는지?

2. 통합정보시스템 아키텍처 Requirements Definition – Data E-R Diagram(개체관계모델): 프로세스 수행에 투입/산출되는 데이터 사이의 관계 개체(Entity) 속성(Attribute) 관계(Relationship)

2. 통합정보시스템 아키텍처 Requirements Definition – Function/Org./Data 통합프로세스 모델: 조직-데이터 기능-데이터 조직-기능 조직-기능-데이터

2. 통합정보시스템 아키텍처 Design Specification – Function 기능도/워크플로우 다이어그램  모듈/트랜잭션 디자인

2. 통합정보시스템 아키텍처 Design Specification – Function

2. 통합정보시스템 아키텍처 Design Specification – Organization 조직도  조직단위 사이의 커뮤니케이션은 시스템 연결을 통해 이루어지므로 조직단위에 시스템이 어떻게 배치되는지를 설명하는 네트워크 토폴로지 설계

2. 통합정보시스템 아키텍처 Design Specification – Data E-R Model  데이터베이스 및 데이터의 구조 설계하기 위해서 릴레이션으로 전환 사원번호 이름 나이 소속 근무연한 A9501 김연수 40 영업부 7 A9601 이현석 37 6 A9602 김유미 32 …

2. 통합정보시스템 아키텍처 Implementation Description - Function

2. 통합정보시스템 아키텍처 Implementation Description - Organization

Chapter 3 시스템개발 방법론 (IS Development Methodology) 시스템분석 및 설계 Chapter 3 시스템개발 방법론 (IS Development Methodology)

목 차 0. 학습개요 및 학습목표 1. 시스템이 갖추어야 할 요구조건 2. 시스템개발 방법론의 평가와 선택기준 목 차 0. 학습개요 및 학습목표 1. 시스템이 갖추어야 할 요구조건 2. 시스템개발 방법론의 평가와 선택기준 3. 시스템개발 방법론 3.1 전통적 폭포수 모형 3.2 프로토타이핑 모형과 진화적 프로토타이핑 모형 3.3 나선형 모형 3.4 기타 개발방법론 3.5 개발방법론의 선택

0. 학습개요 및 학습목표 시스템개발에 참여하는 이해관계자(시스템사용자, 시스템관리자, 개발의뢰인) 의 시각을 이해한다. 시스템개발에 참여하는 이해관계자(시스템사용자, 시스템관리자, 개발의뢰인) 의 시각을 이해한다. 시스템개발 방법론의 평가방법과 평가기준을 이해한다. 전통적인 생명주기 모형의 개념과 한계점을 학습한다. 프로토타이핑 모형과 진화적 프로토타이핑 모형을 이해한다. 프로세스 중심의 구조적 개발방법론과 데이터 중심의 정보공학 방 법론을 이해한다. 객체지향적 개발방법론을 이해한다.

1. 시스템이 갖추어야 할 요구조건 시스템품질에 대한 이해관계자의 시각 시스템사용자 기업 시스템관리자 개발비용은 저렴한가? 원하는 기능이 있는가? 작업을 쉽게 처리할 수 있는가? 쉽게 배울 수 있는가? 작업 중에 다운되는지 않는가?   개발비용은 저렴한가? 업무처리의 정확도는 높은가? 업무처리 효율성은 높은가? 타 시스템과 호환성이 있는가? 문서화는 잘 되어 있는가? 오류를 쉽게 발견할 수 있는가? 쉽게 변경할 수 있는가? 코드를 쉽게 읽을 수 있는가? 쉽게 확장 가능한가? 기업 시스템관리자 시스템사용자

1. 시스템이 갖추어야 할 요구조건 시스템품질의 평가요인

1. 시스템이 갖추어야 할 요구조건 1.1 시스템품질의 평가요인 - 신뢰성 원하는 업무를 오류 없이 처리할 수 있도록 구현되어야 한다. 신뢰성 정도를 평가하기 위한 항목 시스템오류가 얼마나 자주 발행하는가? 얼마나 다양한 오류가 발생하는가? 오류의 심각성은 어느 정도인가? 오류가 미치는 영향이 시스템 중단 혹은 데이터의 부분적인 손실 혹은 오류에도 불구하고 작동하는가?

1. 시스템이 갖추어야 할 요구조건 1.1 시스템품질의 평가요인 – 견고성/정확성 견고성: 잘못된 자료를 입력하는 경우, 자료의 재 입력을 요구하거나, 메시지를 띄우거나, 오류수정을 자체적으로 행하도록 구현되어야 한다.  견고성이 유지되는 시스템은 치명적인 오류를 미리 방지할 수 있기 때문에, 신뢰성이 유지된다. 정확성: 구현된 세부 프로그램의 오류에 관련된 요인으로, 이는 효율성의 문제가 아니라, 해결하고자 하는 문제를 원하는 형태로 해결하기 위해서 세부기능이 얼마나 정확하게 구현되었느냐의 문제이다.  효율성이 아닌, 이론적인 구현의 정확성

1. 시스템이 갖추어야 할 요구조건 1.2 시스템품질의 평가요인 – 사용 편리성 시스템사용자(초보)가 얼마나 쉽게 배울 수 있는가? 시스템사용자가 얼마나 편리하게 사용할 수 있는가? 문제가 발생하는 경우, 원하는 도움을 쉽게 받을 수 있거나, 얼마나 쉽게 해결할 수 있는가? 사용편리성의 평가항목  얼마나 친밀한가? 사용자 인터페이스가 얼마나 쉽고 편리하게 설계되어 있는가? 사용자 지도 인터페이스가 구현되어 있는가? 도움말 기능이 구현되어 있는가?

1. 시스템이 갖추어야 할 요구조건 1.3 시스템품질의 평가요인 – 효율성 넓은 의미의 효율성: 업무처리 효율성 / 시스템 효율성 / 시스템성능 좁은 의미의 효율성: 업무처리 효율성  업무처리 내용과 절차가 잘 효율적으로 구현되어 있는가?  프로그램 구현의 효율성 업무처리를 위한 자료구조 및 알고리즘 구현의 효율성 부분적인 프로그램의 효율성을 추구  전체 프로그램의 논리 구현이 복잡  사용자의 불편함 초래  전체 프로그램의 비 효율성  신뢰성/견고성/정확성/사용 편리성을 유지하면서 적정 수준의 효율성 추구

1. 시스템이 갖추어야 할 요구조건 1.4 시스템품질의 평가요인 – 관리용이성 시스템관리의 필요성 업무처리 환경의 변화 사용자의 요구변화 시스템관리자의 관심 시스템오류를 쉽게 발견할 수 있는가? 프로그램 코드를 쉽게 해독할 수 있는가? 시스템구조 및 데이터베이스 구조변경은 용이한가? 새로운 기능, 성능 추가가 용이한가?  관리비용이 발생

1. 시스템이 갖추어야 할 요구조건 1.4 시스템품질의 평가요인 – 관리용이성

1. 시스템이 갖추어야 할 요구조건 1.4 시스템품질의 평가요인 – 관리용이성 시스템관리( 유지보수)를 위한 전제조건 시스템 자체에 대한 문서가 작성되고 지속적으로 관리되어야 한다. 사용자에 대한 문서가 완벽하게 작성되어야 한다. 자료흐름, 자료구조, 모듈에 대한 문서가 작성/관리되어야 한다. 유지보수를 고려하여 수정/변경이 용이하도록 설계되어야 한다. 시스템관리자 시스템개발에 참여한다. 시스템관리를 위해서 신속한 보고체계 및 제도적인 체계가 구축되어야 한다.

1. 시스템이 갖추어야 할 요구조건 1.5 시스템품질의 평가요인 – 문서화 문서는 시스템사용자, 시스템관리자, 기업 간의 의사소통 도구 시스템문서 관리자들이 시스템관리/유지보수를 위해서 필요 시스템개발 계획수립 ~ 구현 및 유지보수에 이르는 개발과정에 대한 문서 시스템운영상의 모든 내용 시스템 사양, 세부기능, 자료구조, … 사용자를 위한 문서 사용자들이 시스템을 사용하고 문제를 해결하기 위해서 필요 사용자 매뉴얼  모든 문서의 체계적이고 정확한 작성과, 지속적인 관리가 요구됨.

시스템개발 방법론마다 분석, 설계 및 구현을 위한 세부절차가 다르고, 모델링 방법이 다르며, 지원되는 도구가 다름 2. 시스템개발 방법론의 평가와 선택기준 시스템개발 방법론의 평가항목 시스템개발 방법론마다 분석, 설계 및 구현을 위한 세부절차가 다르고, 모델링 방법이 다르며, 지원되는 도구가 다름 시스템개발 방법론의 평가항목 Procedural Model: 시스템개발을 위한 체계적인 절차 Method: 작업 단계마다 적용되는 방법 CASE Tool: 시스템개발을 지원하는 도구

2. 시스템개발 방법론의 평가와 선택기준 2.1 시스템개발 방법론의 선택기준 모든 절차모델과 방법이 언제나 동일한 수준의 시스템품질을 보장하는 것이 아니기 때문에, 높은 수준의 시스템품질을 보장할 수 있는 절차모델과 방법론의 선택이 중요 절차모델과 방법의 선택기준 절차모델과 방법의 통합성 절차모델과 방법의 실제 이용가능성 절차모델과 방법의 인지도 절차모델과 방법의 습득용이성

2. 시스템개발 방법론의 평가와 선택기준 2.2 시스템개발 방법론의 선택기준 – 재사용성 재사용성: 새로운 시스템을 구현할 때, 어느 정도 기존 시스템 부분을 활용할 수 있는지? 재사용의 장점: 이전의 시스템 컴포넌트 중에 사용 가능한 부분이 많을수록 개발기간이 단축되고, 비용절감, 시스템 신뢰도 향상 재사용의 단점 이전의 시스템 컴포넌트에 대한 효율성 검증이 선행 다른 컴포넌트와의 관계분석이 선행 컴포넌트 재사용을 지원할 도구와 방법이 존재, 기반구조가 제공

2. 시스템개발 방법론의 평가와 선택기준 2.2 시스템개발 방법론의 선택기준 – 재사용성 재사용성 가능한 요인 시스템개발 계획수립 관련 산출물 개발비용 예측관련 산출물 요구분석 명세서 설계사양서 원시코드 프로세스 모델

2. 시스템개발 방법론의 평가와 선택기준 2.3 시스템개발 방법론의 선택기준 - 지원도구 지원도구: 시스템분석, 설계 및 구현작업을 지원할 자동화된 도구 지원도구의 지원 없이 복잡한 시스템개발 작업을 수행할 수 없음. 지원도구의 활용효과 효율적인 개발작업 체계적이고 일관된 작업 가능 산출물 자동생성 및 지속적인 관리 가능 의사소통 도구  개발도구가 작업을 대신할 수 없기 때문에, 활용경험과 활용능력요구

3. 시스템개발 방법론 3.1 전통적인 폭포수 모형 Just as water flows from one level to the next in a waterfall, with no flow back up the waterfall.

3. 시스템개발 방법론 전통적인 폭포수 모형의 개발단계 시스템계획(System Planning) 시스템정의 시스템개발의 당위성과 개발목적, 개발효과 명시 갖추어야 할 기능과 성능, 개발환경, 추진전략 정의  시스템정의서(System Definition) 작성 개발계획수립 타당성분석(경제적, 기술적, 법적) 인원/일정/비용계획, 개발방법론/지원도구, 산출물 관리, 문서화계획  시스템개발계획서(Project Plan) 작성

3. 시스템개발 방법론 전통적인 폭포수 모형의 개발단계 시스템분석(System Analysis) – 사용자 요구분석 기존의 업무처리 방식분석 기존 시스템 분석 기존의 데이터구조 분석 기존 업무처리 방식에서의 문제점 분석하고, 이를 해결하기 위한 방법제시  요구분석서(Requirements Specification) 작성 갖추어야 할 기능/성능의 구체적인 정의 기능(프로세스), 데이터, 조직구조

3. 시스템개발 방법론 전통적인 폭포수 모형의 개발단계 시스템설계(System Design) 시스템 계획 및 분석  어떤 시스템을 개발할 것인가? (WHAT) 시스템 설계  어떻게 구현할 것인가? (HOW)  설계사양서(Design Specification) 작성 시스템 구현범위 시스템 구현방법 시스템 처리방식 시스템 구현기술

3. 시스템개발 방법론 전통적인 폭포수 모형의 개발단계 시스템구현(System Implementation) 설계된 내용을 프로그래밍 언어를 이용하여 코딩하고 디버깅하면서 완성하는 과정 구현  인수시험  시스템 테스트 시스템 운용(Operation): 시스템 테스트를 거쳐 실제 업무에 활용 시스템 유지보수(Maintenance): 새로운 기능추가/삭제, 보완하여 생명을 연장시켜 나가는 과정  효율적인 운용과 용이한 유지보수를 위해서 철저한 요구분석 결과를 바탕으로 효율적이고 논리적으로 모순 없이 설계되고, 기술적으로 완벽하게 구현되어야 함.

3. 시스템개발 방법론 단점 장점 전통적인 폭포수 모형의 평가 개발비용이 많이 든다 개발시간이 오래 걸린다 시행착오 비용 융통성이 적다: 단계별 수정이 어려우며, 수정 시 과다한 시간과 비용이 소요 변화수용이 어렵다 사용자의 요구 를 변형하기 어렵다 장점 가장 전통적인 개발방법론 프로젝트의 통제가 용이하다

3. 시스템개발 방법론 반복적인 폭포수 모형 각 단계의 작업이 종료되어도 역 방향으로 수정 보완할 수 있도록 각 단계의 피드백이 가능

3. 시스템개발 방법론 3.1 프로토타이핑 모형(Prototyping Model)

3. 시스템개발 방법론 프로토타이핑 모형(Prototyping Model)의 이해 사용자의 복잡하고 다양한 요구를 일회적으로 분석해 내기 어려움 최초의 요구분석을 통해서 시스템 일부(프로토타입)를 실제로 개발하여 사용자에게 검증 받고, 이상이 있거나, 다른 요구가 있으면 이를 반영하여 본격적으로 시스템개발에 착수  사용자의 요구에 더 부합된 시스템을 개발하기 위한 노력 프로토타입을 개발하는 또 다른 목적: 기술적 구현가능성과 개발 타당성을 평가

3. 시스템개발 방법론 프로토타이핑 모형(Prototyping Model) 의 평가 장점 새롭고 갑작스러운 요구 수용이 가능 사용자가 시스템을 미리 접하게 되어 새로운 요구를 도출 개발가능성, 타당성 검증 가능 단점 상대적으로 개발기간이 길어짐 추가적인 개발비용이 소요됨 이를 지원할 지원도구가 많지 않음  독자적인 개발방법론이 아니라, 다른 방법론과 상호 보완적인 관계

3. 시스템개발 방법론 진화적 프로토타이핑 모형 Incremental Cycle Evolutionary Cycle

3. 시스템개발 방법론 진화적 프로토타이핑 모형의 평가 장점 사용자의 요구를 정확하게 분석하여 오류를 방지할 수 있음 불분명한 요구사항을 명확하게 정의 프로토타입을 통해서 사용자의 교육이 자동으로 이루어짐 단점 개발과정의 모든 문서들이 중복 작성될 수 있음 프로토타입의 지속적인 관리 요구 quick and dirty programming 문제 발생 기존의 방법에 비해서 프로젝트 통제가 어려움

3. 시스템개발 방법론 3.3 나선형 모형(Spiral Model) 전통적 폭포수 모형과 프로토타이핑 모형의 장점을 수용하고 단점을 보완하여 개발된 방법론 시스템개발 절차 Planning Risk Analysis Development Customer Evaluation

3. 시스템개발 방법론 나선형 모형(Spiral Model)의 개발단계

3. 시스템개발 방법론 나선형 모형(Spiral Model)의 단계별 작업내용 계획수립 및 요구분석 시스템기능/품질요구조건/컴포넌트 정의 확정 분석 및 설계방법, 지원도구, 구현방법 결정 개발일정, 인적자원배분, 하드웨어/소프트웨어 계획 위험분석 수립한 계획 및 분석한 요구사항의 분석 및 평가 위험요인을 추출하여 제거함으로써 사용자의 요구에 맞는 시스템을 개발하기 위함 프로토타입 개발 및 고객평가 프로토타입 개발 및 테스트 특정 방법론과 지원도구에 제한 받지 않음 프로토타입에 대한 고객의 평가

3. 시스템개발 방법론 나선형 모형(Spiral Model)의 평가 대규모의 복잡한 시스템 개발에 유리 전통적인 개발방법론처럼 이전의 단계에 종속적이지 않고 독립적임 위험요인을 추출하고 분석하는데 많은 비용 소요 초기의 요구분석 결과 자체가 불완전한 경우, 위험분석의 의미가 없음 위험분석 결과가 불완전한 경우, 사용자의 요구충족에 의미가 없음 위험분석 결과가 불완전한 경우, 개발비용만 낭비

3. 시스템개발 방법론 3.4 기타 방법론 - 구조적 개발방법론 기존의 개발방법론의 특징 개발단계가 독립적이다 개발단계가 순차적이다. 개발 단계간의 연계성이 부족하다 개발단계가 상향식(Bottom-Up) 방식으로 진행된다 기존의 개발방법론의 문제점 개발단계가 독립적/순차적 진행/연계성 부족  각 단계 사이의 피드백이 어려움  수정의 어려움  시스템 품질저하 상향식 구현방식  최종 통합시험을 거치기 전까지 전체 시스템의 윤곽 파악이 어려움  개별 모듈사이의 인터페이스 문제발생 가능 해결방법 독립적/순차적이지만, 각 단계사이의 연계성을 중시 상향식 구현방식보다 하향식 구현방식 혹은 혼합형

3. 시스템개발 방법론 구조적 개발방법론의 특징 기존의 개발방법론처럼 계획분석설계구현시험운용 각 단계사이의 연계성을 중시: 어떤 단계의 작업 중이라도 이전 단계의 작업내용을 쉽고 빠르게 수정 변경할 수 있도록 다음과 같은 분석 및 설계 원리를 도입 추상화(Abstraction): 상위단계  추상적, 하위단계  상세화 정형화(Formality): 단계마다 정형화된 형식에 근거하여 작업  자료흐름도-자료사전-소단위 기능명세서-… 계층적 구조(Hierarchical Structure): 분할의 개념을 도입하여 시스템을 하위 서브시스템으로 분할하고, 서브시스템 간의 상호 연관관계&구조를 고려하여 계층구조로 표현 그림 중심의 분석도구를 이용

3. 시스템개발 방법론 구조적 분석절차 현재의 물리적 모델작성(AS-IS Physical Model) 현재의 업무처리 방식 및 절차 업무처리 환경을 그대로 재현 어떤(WHAT) 보다는 어떻게(HOW) 업무를 처리하느냐에 초점  물리적으로 구현되어 있는 모습 현재의 논리적 모델작성(AS-IS Logical Model) 어떻게(HOW)보다는 어떤(WHAT) 업무를 처리하느냐에 초점  어떤 업무를 처리하고 있는가를 재현 미래의 논리적 모델작성(TO-BE Logical Model) 어떤 기능이 추가되어야 하는가? 어떤 기능이 삭제되어야 하는가? 어떤 기능이 어떻게 변경되어야 하는가?

3. 시스템개발 방법론 구조적 분석을 위한 사례: 재고관리 공급업자로부터 부품이 도착되면, 함께 도착한 송장의 내용을 일지에 기록하고 송장바인더에 보관한다. 동시에 도착한 부품량만큼 부품 재고장부를 갱신하며, 창고에서 부품 사용량을 통지하면 사용한 부품만큼 부품 재고장부를 갱신한다. 부품 재고장부의 내용(부품량과 최저 재고량)을 파악하여 일정 수준 이하로 재고가 내려가면 새로 주문한다. 송장일지에 기록된 대금지불 기한이 되면 부품대금을 지불한다.

3. 시스템개발 방법론 현재의 물리적 모델

3. 시스템개발 방법론 재고관리 업무내용 재고증가 처리 업무 재고감소 처리 업무 주문처리 업무 대금지불 업무

3. 시스템개발 방법론 현재의 논리적 모델

3. 시스템개발 방법론 미래의 논리적 모델 현재의 물리적/논리적 모델에 근거하여 미래의 논리적 모델작성 새로운 사용자의 요구가 없거나 추가/삭제될 기능이 없고 업무처리 방식만 변화시키기 원한다면, 현재의 논리적 모델과 미래의 논리적 모델은 일치  업무처리 방식의 변화는 물리적 구현을 의미하며, 이는 논리적 모델에 표현된 내용이기 때문 만일, 새로운 요구가 있거나 추가/삭제될 기능이 있다면, 미래의 논리적 모델을 새로이 작성

3. 시스템개발 방법론 미래의 논리적 모델 새로 추가될 업무: 관리자가 수시로 부품재고현황을 질의하면, 이에 신속하게 보고서를 작성하여 보고한다. 어떤 방식으로 구현하느냐는 차후의 문제

3. 시스템개발 방법론 미래의 물리적 모델 구조적 분석결과: 현재의 물리적/논리적 모델, 미래의 논리적 모델 작성 구조적 설계: 어떻게 구현할 것인가를 구상하는 단계 구조적 설계원리 구조적 분석과 동일한 추상화/정형화/계층적 구조원리를 도입 블랙박스의 개념 도입 블랙박스: 입/출력관계만 인지하여 표현 프로그램 모듈로 구체화 물리적 프로그램으로 구현 모듈과 물리적 프로그램간의 계층구조는 프로그램 간의 호출관계로 실현

3. 시스템개발 방법론 3.4 기타 방법론 - 객체지향 개발방법론 객체지향 개발방법론의 핵심 모든 시스템은 상호 연결된 객체(Object) 의 집합체 모든 객체에 데이터와 프로세스(기능)가 동시에 포함 객체지향 프로그래밍 언어를 사용 객체지향 데이터베이스 관리시스템을 이용하여 구현 객체(Object)의 개념 Object = Entity Type = Class 의 개념과 동일 객체지향의 원리 캡슐화(Encapsulation): 자료와 행동방법이 정의된 객체 내에 존재 상속성(Inheritance): 상/하위 객체 사이의 자료/행동방법의 공유 다형성(Polymorphism): 메시지를 전달 받은 객체에 따라서 메시지의 내용이 다르게 해석될 수 있음

3. 시스템개발 방법론 객체지향 분석 (OO Analysis) 클래스와 객체의 식별 및 정의: 분석대상 영역을 설명하기 위해서 필요한 객체와 클래스를 찾아내어 정의하는 과정 클래스와 객체의 구조 식별 및 정의: 식별된 클래스와 객체들의 구조와 클래스 간의 관계를 식별하여 정의하는 과정 속성과 관계의 파악 및 정의: 클래스를 설명할 속성을 파악하여 정의하며, 객체들 간의 관계를 정의하는 과정 서비스의 정의: 객체가 수행하는 행동을 정의하는 과정 (서비스: 객체가 수행하는 행동 = 객체의 속성값 = 프로세스의 개념과 동일)

3. 시스템개발 방법론 객체지향 설계 (OO Design) 분석과정에서 작성된 상위 클래스 또는 하위 클래스 간의 관계 재정립 클래스 라이브러리에 재사용 가능한 클래스를 이용하여 클래스 추가 사용자 인터페이스 설계 객체를 통한 데이터의 저장, 변경, 삭제, 검색 등의 데이터 관리를 위한 데이터/데이터관리 구조 결정

3. 시스템개발 방법론 3.5 시스템개발 방법론의 선택 시스템개발 방법론마다 지원도구가 다름 시스템개발 방법론마다 같은 수준의 시스템품질을 제공하지 못함  효율적인 방법론의 선택이 필요 평가기준: 개발방법론의 통합성 개발방법론의 이용가능성 개발방법론의 인지도 개발방법론의 습득 용이성 개발방법론의 재사용성 개발방법론의 지원도구