mecㆍviewer v1.4 :: 0 1 2 3 전체개론 개요.pptx

0. 전체 책의 내용

전체 개론

개요 및

전체적 시각

정보시스템에

대한 관점



정의



역사



필요성



학문적 체계



전체 구성



분석의 관점



종류

정보시스템

구현



개발단계



개발원칙



전제사항

프로젝트

관리



프로젝트 관리



프로젝트 단계



도구



문서화

요구사항관리



분석단계



각 단계별
상세절차

요구사항
발견기법



범위



기법

설계 및 아키텍쳐



설계



구조



품질요소



아키텍쳐 정의



아키텍쳐 종류

개발 프로세스

및 방법론



개념



개발프로세스



개발 방법론

테스팅



개념



종류



도구

유지보수



개념



절차



형상관리



역공학



리엔지니어링

품질보증



개념



방법



기법



도구

I 부 : 소프트웨어 공학의 대상인 정보시스템의 개념과 개발

II 부 : 소프트웨어공학 일반론

III 부 : 소프트웨어 방법론 및 개발 실무

소프트웨어

방법론

(모델링)



정의



종류



기본원리



방법



과정

구조적 방법론



역사



정의



구성



DFD사례 및 작성



도구

정보공학

방법론



역사



정의



단계



ERD사례 및 작성



도구

객체지향

방법론

코딩기법



코딩가이드



클래스의 처리기법



디자인패턴



리펙토링



TDD



개념



UML, 소개



클래스다이어그램



시퀀스다이어그램



유스케이스



Aspect-Oriented

소프트웨어공학 과정

개요 및

전체적 시각

정보시스템에

대한 관점



정의



역사



필요성



학문적 체계



전체 구성



분석의 관점



종류

정보시스템

구현



개발단계



개발원칙



전제사항

프로젝트

관리



프로젝트 관리



프로젝트 단계



도구



문서화

요구사항관리



분석단계



각 단계별
상세절차

요구사항
발견기법



범위



기법

설계 및 아키텍쳐



설계



구조



품질요소



아키텍쳐 정의



아키텍쳐 종류

개발 프로세스

및 방법론



개념



개발프로세스



개발 방법론

테스팅



개념



종류



도구

유지보수



개념



절차



형상관리



역공학



리엔지니어링

품질보증



개념



방법



기법



도구

소프트웨어 모델링

/디자인 과정

소프트웨어

방법론

(모델링)



정의



종류



기본원리



방법



과정

구조적 방법론



역사



정의



구성



DFD사례 및 작성



도구

정보공학

방법론



역사



정의



단계



ERD사례 및 작성



도구

객체지향

방법론



개념



UML, 소개



클래스다이어그램



시퀀스다이어그램



유스케이스



Aspect-Oriented

코딩기법



코딩가이드



클래스의 처리기법



디자인패턴



리펙토링



TDD

설계 및 아키텍쳐



설계



구조



품질요소



아키텍쳐 정의



아키텍쳐 종류

개발 프로세스

및 방법론



개념



개발프로세스



개발 방법론

테스팅



개념



종류



도구

1. 소프트웨어 공학 개요

1.1 소프트웨어의 정의

1.2 소프트웨어 발전의 역사

1.3 소프트웨어의 종류

1.4 소프트웨어 공학의 정의

1.5 소프트웨어 공학의 도입 배경

1.6 소프트웨어 공학의 관심 대상

1.7 소프트웨어 공학의 단계 및 중요작업

1.8 소프트웨어 공학의 범위

1.9 정리

1.10 연습문제

1.1 소프트웨어의 정의



컴퓨터는 하드웨어

(Hardware)와 소프트웨어(Software)로 구성된다

다양한 형태의 하드웨어와 다양한 기능의 소프트웨어가 필요에 따라 존재하므로 “보편 만능의 기계＂라고도 한다

즉

, 동일한 하드웨어에 소프트웨어를 바꿈으로써 다른 기능을 수행할 수 있다.

동일하게 환경에 맞추어 여러 형태의 하드웨어가 존재한다

. (컴퓨터라는 발명품이 가지는 특징)



컴퓨터 소프트웨어

(computer software), 혹은 소프트웨어는 저장장치에 저장된 특정한 목적의 하나 또는 다수의 컴퓨터

프로그램을 의미한다 – 위키백과

소프트웨어라는 용어는

1957년에 존 터키(John W. Tukey)가 처음 사용하였다.



소프트웨어의 특징

(Brooks, 1987)

     - 비가시성(Invisibility) : 소프트웨어는 눈으로 볼 수 없다
     - 복잡성(Complexity) : 소프트웨어는 개발 과정이 어렵고, 복잡한 구조를 가진다
     - 적합성(Conformity) : 소프트웨어는 정형화된 구조가 없고 환경에 따라 변형된다
     - 변형성(Changeability) : 소프트웨어 구성 요소는 항상 변화해야 한다.



소프트웨어는 제조가 아닌 개발되어야 하는 것이며

, 소모되는 것이 아닌 환경 변화에 따른 품질 저하가 고려되어야 하는 대상이다

1.2 소프트웨어 발전의 역사

절차 중심

데이터 중심

주제 중심

주어진 작업의 반복수행
(예) 성적처리
암호해독



1960년대



구조적 프로그래밍

- 함수기능(단위기능 분리)
- Goto 금지



구조적 방법론

    - DFD
    - MiniSpec
    - Data Dictionary

데이터를 저장하고 관리하는 기능
(예) 은행업무 프로그램
인사관리 프로그램



1970~80년대



데이터중심 프로그래밍

- DBMS의 도입



정보공학 방법론

     - ER Modeling
     - ISP

거의 모든 업무에 컴퓨터를
사용하므로

, 크고 복잡하고

변화하는 환경 지원 기능
(예) 재무, 회계관리
물류처리…



90년대 ~



처리순서의 변화를

수용하는 프로그래밍
(클래스 중심)



객체지향 방법론

- UML, Agile

소프트웨어 개발의 역사는 아래와 같이 요약할 수 있다

오늘날의 소프트웨어 개발을 위해서는 절차

, 데이터, 변화를 수용하는 크고 복잡한 환경을 모두 수용해야 하므로,

아래의

3가지 환경을 동시에 고려해야 한다

1.3 소프트웨어의 종류

관 점

종 류

제작방식



주문형

: 고객의 요구에 따라 개발해 주는 것 (예) 기업 인사시스템



패키지형

: 시장에서 판매할 목적으로 개발하는 것 (예) ERP, DBMS 프로그램, Excel



임베디드형

: 장치에 설치할 목적으로 개발하는 것 (예) 세탁기, 자동차에 설치되는 것

하드웨어 환경



대형

(슈퍼) 컴퓨터형 : 일기예측 등의 소프트웨어



클라이언트

/서버형 : 네트웍으로 연결된 컴퓨터간의 통신을 이용한 소프트웨어



PC형 : PC에 사용하기 위해 개발된 소프트웨어



모바일형

: 스마트폰 등에 사용하기 위해 개발된 소프트웨어

운영체제



윈도우

/ Mac용 소프트웨어



UNIX / Linux용 소프트웨어



안드로이드

/ ios 소프트웨어

사용환경



운영체제 직접 구동 소프트웨어



웹 구동 소프트웨어



VM 구동 소프트웨어

사용하는 업무



행정

, 금융, 의료, 국방, 운송, 자동차, 교육, 건축, 유통, 무역 등 사용하는 업무에 따른 구별

처리방식



실시간 처리 또는 온라인 처리



트렌젝션 처리

(은행이나 금융 시스템)



배치 처리

( 대용량, 정산 작업 등)

사용자 화면



그래픽 사용자 환경

(Graphic User Interface) 형



글자

(Text) 형

1.4 소프트웨어 공학의 정의



소프트웨어공학은 소프트웨어

+ 공학으로 만들어진 단어이다

-----------------------------------------------------



소프트웨어

: 저장장치에 저장된 특정한 목적의 하나 또는 다수의 컴퓨터 프로그램을 의미한다



공학

(engineering) : 현장에서 쓰이던 기술을 체계화(=반복적이며 동일한 효과를 보이도록 하는 것) 시키는 것 – 나무위키

-----------------------------------------------------

[정의]
소프트웨어 공학은 소프트웨어의 개발

, 운용, 유지보수 및 폐기에 사용되는 기술을 체계화함으로써,

소프트웨어에 관련된 분야를 서술적이며 정량적으로 다루는 학문이다

(참고) IEEE의 정의
소프트웨어공학이란 소프트웨어의 개발

, 운용, 유지보수 및 파기에 대한 체계적인 접근 방식이다.

[특징]


소프트웨어의 품질과 생산성을 좌우하는 기술

, 인력, 프로세스를 균형있게 고려한다(삼각균형, triangle seesaw)

[목표] : 실현가능성에 중심을 둔다



소프트웨어 개발이 체계적이고 공학적인 방법으로 이루어져 추정된 비용과 기간에 고객이 원하는 품질 높은 소프트웨어를

개발하는 것



기술적 부채

(technical debt)를 줄이는 것.

(기술적 부채는 기존의 결함으로 인해 새로운 기능을 개발하거나 확장하는데 어려움이 발생하는 것을 말한다)

1.5 소프트웨어 공학의 도입 배경



소프트웨어 공학은 소프트웨어 개발이 보편화되고 많이 사용되면서 큰 프로그램을 여러명이 오랜시간동안 만들어야 하는

상황때문에 필요해 진 것입니다


소프트웨어 위기

(Software crisis) : 소프트웨어 수요 증가에 대배히여 개발, 공급의 어려움을 나타내는 말

: 1968년 NATO conference에서 소프트웨어 위기의 해결을 위해 소프트웨어 공학이 제안되었다

수십

, 수백명의 개발자가 참여하는 환경



조직의 구성 및 운영



의사소통 및 상호 협력의 필요성



권한과 책임의 명문화



사용하는 용어 및 처리 절차의 표준화

개발기간이 긴 환경



프로젝트의 관리 필요



비용 및 효과의 산정 및 평가



관리 및 평가 체제의 수립



지속적인 팀의 운영

복잡하고 변화하는 요구사항을

가지는 환경



요구사항의 다양화

, 복잡화



요구사항의 빈번한 변화



요구사항 관리의 체계화



요구사항의 명확화 및 문서화

소프트웨어 공학

(Software Engineering)

개발

/운영/변경의

복잡성 해결을 위한

제시스템의 체계적 개발

전체 비용 절감

및 관리의 효율화

시스템 성능 및

디자인

, 운영에 대한

고객만족

1.6 소프트웨어 공학의 관심 대상

소프트웨어 공학의 관심대상은 아래와 같이 정리할 수 있다



소프트웨어 개발의 규모

: 인원, 기간, 예산의 측면에서 큰 소프트웨어의 개발이 관심의 대상이다



좋은 품질의 소프트웨어의 개발이 관심의 대상이다

    [ 소프트웨어의 품질 속성 ]

    -  기능성(Functionality) : 요구사항을 만족하는 것
    -  신뢰성(Reliability) : 안정적인 성능과 기능 오류가 없는 것
    -  사용용이성(Usability) : 사용하기 편리할 것
    -  효율성(Efficiency) : 환경에 따른 적절한 성능을 나타내는 것
    -  유지보수성(Maintainability) : 수정 및 개선하기 편리한 것
    -  이식성(Portatility) : 다른 환경에 적용하기 편리한 것



품질의 유지가 관심의 대상이다

: 소프트웨어의 품질을 개발자나 분석가에 의존하지 않고, 공식적인 절차나 방법론에 의존하는 것



변경의 효율이 관심의 대상이다

: 유지보수와 변경이 용이하도록 프로그램을 제작하는 것

1.7 소프트웨어 공학의 단계 및 중요작업

소프트웨어 공학을 구성하는 핵심 요소는 아래와 같이 정리할 수 있다


각 핵심요소와 책의 목차를 연계시켜 정리해 본다



소프트웨어 개발 프로세스의 정형화



소프트웨어 품질보증 작업의 정형화

: 11장 품질 보증



소프트웨어 개발 프로젝트 관리

: 6장 프로젝트 관리

단계

중요 관심사항

중요작업

산출물

분석

고객의 요구 사항 파악

개발할 시스템의 성격

(2,3장)

요구사항 관리

(4장)

요구사항발견기법

(5장)

요구사항 명세서

설계

시스템의 모델링을 위한
방법론의 적용

방버론

(모델링) 개념(12장)

구조적 방법론

(13장)

정보공학 방법론

(14장)

객체지향 방법론

(15장)

설계 및 아키텍쳐

(7장)

개발 프로세스 및 방법론

(8장)

설계 명세서

구현

코딩 및 리펙토링

- 코딩기법(16장)

소스코드

테스팅

테스팅 및 유지보수

테스팅

(9장)

유지보수

(10장)

테스트보고서

종료보고서

측면

종류

설명

주요 요소

소프트웨
어
엔지니어

링 측면

소프트웨어 요구사항
(Requirement)

소프트웨어에 관련한 이해당사자들의 요구를 파악하는 절차

, 명세, 분석,

분류

, 검증과 관련된 지식영역

Requirement Process

Specification

소프트웨어 설계
(Design)

소프트웨어 설계의 개념과 설계시 다루어 져야 할 핵심 이슈의 인식 및
아키텍쳐뷰에 대한 정보를 제공하는 지식영역

Key Issues in Software Design

SW Structure and Architecture

소프트웨어 개발
(Construction)

소프트웨어 개발에 대한 기본지식과 관리적 요소

, 실무적인 고려사항과

관련된 지식영역

Managing Construction

Practical Considerations

소프트웨어 시험
(Testing)

소프트웨어 테스팅 기본지식

, 대상 및 목적파악, 다양한 테스트 기법,

프로세스의 지식을 제공하는 지식영역

Test Levels, Technique

Test Related Measures

소프트웨어 유지보수
(Maintenance)

소프트웨어 유지보수 기본지식

, 핵심이슈파악, 프로세스파악과 관련한

지식 영역

Key Issues in Software Mainte-
nance

Maintenance process

소프트웨
어 관리
측면

소프트웨어 형상관리
(Configuration Manage-
ment)

소프트웨어 형상관리의 배경파악

, 형상식별/통제/보고/감사활동의 주요

업무 이해등과 관련된 지식 영역

- Software configuration Identifica-
tion /control/status/accounting/Audit-
ing

소프트웨어 공학관리
(Engineering Management)

요구사항명확화

, 정교한 프로젝트 계획 수립, 프로젝트 수행/통제/검토

및 평가활동의 지식 영역

SW Project Planning

Review, Evaluation, Closing

소프트웨어공학도구

/방법

(Engineering Tool&Methods)

생산성의 향상

, 고객만족 실현, 의사소통 활성화, 개발 노하우 전수,

조직문화 형성과 관련된 지식 영역

Software Tools

Software Engineering Tools

소프트웨어 품질
(Quality)

소프트웨어 품질에 대한 기본 지식

, 프로젝트 관리 프로세스 주요활동,

품질에 대한 실무적 고려사항과 관련된 지식영역

Software Quality Management
Process

Practical Considerations

소프트웨어공학 프로세스
(Engineering Process)

소프트웨어 프로세스에 대한 전사적 관리

, 소프트웨어 라이프사이클,

표준화등과 관련된 지식영역

Process Definition

Process Assessment



SWEBOK(Software Engineering Body of Knowledge v2, 2004)에서 정리한 소프트웨어공학의 영역은 아래의 10개 영역이다.

•

2014년 개정된 v3에는 “공학적 기반“, “수학적기반“, “컴퓨팅기반“, “소프트웨어 경제학”, “소프트웨어공학 전문가 기량＂이 추가되고

“소프트웨어공학 도구

/방법＂이 “소프트웨어 모델과 방법론＂으로 바뀌어서 15개로 구성된다

1.8 소프트웨어 공학의 범위

요구사항의

파악 및 정리

설계

구축

테스트

유지보수

형상관리

프로젝트

관리

모델링

소프트웨어공학

도구의 사용

하드웨어 및

제품 지식

시스템

분석 및 설계

프로세스

관리

인간 및

조직 관리

프로그래밍

코딩 개념

품질특성 및

품질보증

소

프

트

웨

어

공

학

의

범

위

구조적
모델링

정보공학

모델링

객체지향

모델링

이 교재에서 정의한 소프트웨어공학의 범위

라이프
사이클

프로젝트

및 조직관리

소프트웨어

모델링

도구 및

개발기법

2. 정보시스템(Information System)에 대한 관점

2.1 기본 용어의 정의

2.2 소프트웨어공학과 정보시스템의 관계

2.3 정보시스템의 도입

2.4 정보시스템의 관련자

2.5 정보시스템의 분석 관점

2.6 정보시스템의 전체적 관점

2.7 정보시스템의 종류

2.8 정보시스템 관련 중요 개념 정리

2.9 정리

2.10 연습문제

2.1 기본 용어의 정의



시스템

(System)이란 ?

   - 단일 구성요소로는 수행할 수 없는 유일한 기능을 수행하기 위하여
   - 연결되거나 관련있는
   - 다른 요소들의 모임  -- 컴퓨터용어사전
   (예) 컴퓨터 – 계산기능의 수행을 위해 CPU, M/M, Disk들이 모여있는 것
        자동차 – 달리기 위하여 차체

, 바퀴, 엔진 등이 모여있는 것



아키텍쳐

(Architecture)란?

   - 시스템의 목적을 달성하기 위해
   - 시스템의 각 구성요소에 대해 설계 및 구현을 지원하는 수준으로
   - 자세히 기술한 것 (일반적으로 Top-Down으로 서술한다) – IEEE 1471 또는 TOGAF
   (예) 소프트웨어 아키텍쳐
          – 특정 역할을 수행하는 소프트웨어를 구성하는 모듈의 구성 및 구현에 대한 사항을

Top-Down으로 자세히 서술한것



데이터

(Data)란?

   - 이론을 세우는 데 기초가 되는 사실 또는 바탕이 되는 자료
   - 관찰이나 실험, 조사로 얻은 사실이나 자료
   - 컴퓨터가 처리할 수 있는 문자, 숫자, 소리, 그림 따위의 형태로 된 자료

정보

(Information)은 목적을 위하여 수정, 보완, 재정의된 데이터를 말한다 … from 나무위키

정보는 필요한 시기에 얻어진 데이터를 말한다고 본다

2.1 기본 용어의 정의

고객등록

소프트웨어

로그인 기능

고객등록기능

등록완료 후

안내 메일 보내는 기능

ID/PWD

넣기 기능

ID/PWD

찾기 기능

연간회원
등록기능

종신회원
등록기능

특별회원
등록기능

임시회원
등록기능

고객등록 소프트웨어의 아키텍쳐

(예)

2.2 소프트웨어공학과 Information System의 관계



프레임워크

(Framework)

어떤 목적을 달성하기 위해 복잡하게 얽혀있는 문제를 해결하기 위한 구조이며

소프트웨어 개발에 있어 복잡한 환경과 다양한 개발자를 묶어주는 뼈대 역할을 한다 …

. from 나무위키

(예) 스프링 프레임워크 : 자바 개발자들이 사용하는 라이브러리, 클래스 등을 지정된 환경에 맞추도록
제한하는 역할을 한다

. 프레임워크가 없으면 복잡한 환경과 개발자의 다양한 취향을 콘트롤 할 수 없다.



인포메이션 시스템

(Information System)이란 ?

데이터를 원하는 형태로 수정

, 보완, 재정의하는 것을 목적으로 연관되거나 관련된 구성 요소들의 모임

결론적으로
소프트웨어공학은 인포메이션 시스템을 제작

, 운영, 확장(변형)하기 위한 것을 다루는 학문이다

그러므로

, Information System에 대한 관점, 관련자, 기술, 프레임워크 등에 대한 것을 파악할 수 있어야

소프트웨어 공학을 통해 무엇을

, 어떻게 추구해야 하는지 할 수 있다

2.3 정보시스템의 도입

정보시스템의 분석 관점

(Information System’s view)

( I

tio

)

정

보

시

스

템

관

련

자

정보시스템

= 소프트웨어 공학을 통하여 구현하고자 하는 대상

정보시스템 구현을 위해서는
아래의

2가지 관점을 우선 고려하여야 한다

관련자
: 누가 어떤 데이터를 언제 원하는지

분석관점

: 데이터를 어떤 형태로 어떻게 제공하는지

그리고

, 프로젝트 관리와 컴퓨터 장비 및 환경,

기타 필요한 것들이 추가로 고려되어야 한다

2.4 정보시스템의 관련자

정보시스템의 분석 관점

(Information System’s view)

정보시스템

= 소프트웨어 공학을 통하여 구현하고자 하는 대상

Information System의 관련자는 다음과 같다

경영진

(Owner) : 시스템의 만들고, 유지하는 의사결정 수행

사용자

(Users) : 시스템을 사용하는 사람

시스템설계자

(System Designer) : 사용자/경영진의 요구에

따라 시스템을 설계하는 사람

시스템개발자

(System Builder) : 시스템을 구성, 테스트, 인도

하는 사람

시스템 분석가

(System Analyst) : 경영진/사용자와 설계자/개발자

사이에서 종합적으로 조정하는 사람

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

2.4 정보시스템의 관련자

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

정보시스템의 범위

(SCOPE)

: 목적(purpose), 비전(Vision), 목표(Goal or Objective), 비용(Costs), 이익(Benefit)

정보시스템의 요구사항

(Requirement)

: 기술과는 무관하게 필요한 기능을 정리

정보시스템의 설계

(Design)

: 기술적으로 시스템을 어떻게 구현할지에 대한 정리

정보시스템의 구현

(Implement)

: 실제적으로 시스템을 개발

정보시스템의 분석 관점

(Information System’s view)

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

데이터 관점

(Data)

프로세스 관점

(Process)

연결 서비스

관점

(Interface)

외부서비스

관점

(Network)

서비스 수준

서비스 기능

연결 서비스

요구사항

외부 서비스의

요구사항

필요한

데이터

업무처리

순서

연결서비스의

기능

, 위치

외부 서비스의

기능

, 위치

데이터베이스

구조

어플리케이션의

구조

연결서비스의

연결방안

외부 서비스의

연결 방안

데이터베이스

프로그램

어플리케이션

제작

연결서비스의

연결

외부서비스의

연결

2.5 정보시스템의 분석 관점

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

프로세스 관점

(Process)

연결 서비스

관점

(Interface)

외부서비스

관점

(Network)

서비스 수준

서비스 기능

연결 서비스

요구사항

외부 서비스의

요구사항

필요한

데이터

업무처리

순서

연결서비스의

기능

, 위치

외부 서비스의

기능

, 위치

데이터베이스

구조

어플리케이션의

구조

연결서비스의

연결방안

외부 서비스의

연결 방안

데이터베이스

프로그램

어플리케이션

제작

연결서비스의

연결

외부서비스의

연결

데이터 관점

(Data)

시스템이 필요한 기능
(에) 수강 신청 시스템은 신청과
수정 기능이 필요하다

수강신청 시스템을 위한 상세 내용
(에) 신청과 수정 기능을 위해서는
학번

, 과목이름, 교수명이 필요

수강신청 시스템의

DB 구조

(에) 수강 신청 시스템은 신청과
수정 기능을 위해서는 학생

과목

, 교수의 테이블이 필요하다

수강신청 시스템의

DB 구성 및 이용

(에) 수강 신청 시스템에서 필요한
테이블을 구성하고

, 접근을 위한

모듈을 제작

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

데이터 관점

(Data)

연결 서비스

관점

(Interface)

외부서비스

관점

(Network)

서비스 수준

서비스 기능

연결 서비스

요구사항

외부 서비스의

요구사항

필요한

데이터

업무처리

순서

연결서비스의

기능

, 위치

외부 서비스의

기능

, 위치

데이터베이스

구조

어플리케이션의

구조

연결서비스의

연결방안

외부 서비스의

연결 방안

데이터베이스

프로그램

어플리케이션

제작

연결서비스의

연결

외부서비스의

연결

프로세스 관점

(Process)

시스템이 필요한 기능의 처리절차
(에) 수강 신청시, 국내/국외 학생,
외국인도 지원한다

처리절차별 순서
(에) 로그인후, 재학생, 복학생,
외국인을 선택하는 메뉴를 보여
준다

. 그리고 ….

수강신청 시스템의

DB 연관성

(에) 수강 신청을 위해서는 과목,
신청 테이블을 동시에 체크하고
작업을 수행한다

, 웹환경 구성

수강신청 시스템의

DB 프로그램

(에) 웹에서 신청 작업을 위한
프로그램 제작
(JQuery를 이용하여 작성)

2.5 정보시스템의 분석 관점

2.5 정보시스템의 분석 관점(한글버전)

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

데이터 관점

(Data)

프로세스 관점

(Process)

외부서비스

관점

(Network)

서비스 수준

서비스 기능

연결 서비스

요구사항

외부 서비스의

요구사항

필요한

데이터

업무처리

순서

연결서비스의

기능

, 위치

외부 서비스의

기능

, 위치

데이터베이스

구조

어플리케이션의

구조

연결서비스의

연결방안

외부 서비스의

연결 방안

데이터베이스

프로그램

어플리케이션

제작

연결서비스의

연결

외부서비스의

연결

연결서비스

관점

(Interface)

시스템이 필요한 회사내 다른 모듈
(에) 수강 신청시, 학생확인 부분도
지원해야 한다

시스템이 필요한 회사내 다른 모듈
기능 및 위치
(에) 수강 신청시, 학생확인을 위한

     로그인 기능은 인사시스템의
     기능을 활용한다

시스템이 필요한 회사내 다른 모듈
연결을 위한 상세 내용 결정
(에) 인사시스템의 로그인 기능은
LOGACC 메소드를 콜 한다

시스템이 필요한 회사내 다른 모듈
구현
(에) 수강 신청시, 학생확인 부분을
위해 로그인 기능 구현

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

데이터 관점

(Data)

프로세스 관점

(Process)

연결 서비스

관점

(Interface)

서비스 수준

서비스 기능

연결 서비스

요구사항

외부 서비스의

요구사항

필요한

데이터

업무처리

순서

연결서비스의

기능

, 위치

외부 서비스의

기능

, 위치

데이터베이스

구조

어플리케이션의

구조

연결서비스의

연결방안

외부 서비스의

연결 방안

데이터베이스

프로그램

어플리케이션

제작

연결서비스의

연결

외부서비스의

연결

외부서비스

관점

(Network)

시스템이 필요한 회사외 다른 모듈
(에) 수강 신청시, 카카오톡 기능
지원

시스템이 필요한 회사외 다른 모듈
연결 방안 및 시기
(에) 수강 신청시, 화면 오른쪽에
카카오톡을 넣어서 실시간
채팅 지원

시스템이 필요한 회사외 다른 모듈
연결을 위한 상세 내용 결정
(에) 수강 신청시, 카카오톡기능
지원을 위한 상세 사항 결정

시스템이 필요한 회사외 다른 모듈
구현
(에) 수강 신청시, 화면의 오른쪽에
카카오톡 기능 구현

2.5 정보시스템의 분석 관점

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

데이터 관점

(Data)

프로세스 관점

(Process)

연결 서비스

관점

(Interface)

외부서비스

관점

(Network)

서비스 수준

서비스 기능

연결 서비스

요구사항

외부 서비스의

요구사항

필요한

데이터

업무처리

순서

연결서비스의

기능

, 위치

외부 서비스의

기능

, 위치

데이터베이스

구조

어플리케이션의

구조

연결서비스의

연결방안

외부 서비스의

연결 방안

데이터베이스

프로그램

어플리케이션

제작

연결서비스의

연결

외부서비스의

연결

객체지향 관점

(Object-Oriented View)프로그래밍 + 프레임워크



class, object, inheritance, encapsulation, polymorphism, interface



component, service, design pattern, refactoring, TDD, unified process

Information Sys-

tem Architecture

2.5 정보시스템의 분석 관점

2.6 정보시스템의 전체적 관점

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

데이터 관점

프로세스 관점

연결 서비스

관점

외부서비스

관점

서비스 수준

서비스 기능

연결 서비스

요구사항

외부 서비스의

요구사항

필요한

데이터

업무처리

순서

연결서비스의

기능

, 위치

외부 서비스의

기능

, 위치

데이터베이스

구조

어플리케이션의

구조

연결서비스의

연결방안

외부 서비스의

연결 방안

데이터베이스

프로그램

어플리케이션

제작

연결서비스의

연결

외부서비스의

연결

PIECE Framework

하드웨어

/소프트웨어 제품

지식 및 표준화 동향

의사소통 및 문서화 기술

1. 사전탐색

2. 문제분석

4. 제안요청 및

업체 결정

요

구

사

항

관

리

3. 요구사항분석

객체지향 관점

(Object-Oriented View)프로그래밍 + 프레임워크

프

로

젝

트

관

리

1. 범위협상 및

확정

2. 타스크 식별

3. 타스크수행

기간 예측

4. 타스크간 의존성

확인 및 일정관리

5. 자원의 할당 및

조직구성

6. 개발팀의 구성

및 운영

7. 감시와 통제

8. 프로젝트 종료

공통 기술

2.6 정보시스템의 전체적 관점

< 정보 시스템 전체 아키텍쳐를 통해 얻을 수 있는 것 >


소프트웨어공학을 통해 구현하고자 하는 것은 정보시스템이다



정보시스템은 “정보시스템 관련자”와 “정보시스템 분석 관점”을 기반으로 분석하면
구현에 필요한 것을 모두 얻을 수 있다



정보시스템 구현의 관련자는 아래의

5가지로 나누어 볼 수 있다

- 경영진
- 사용자
- 시스템 설계자
- 시스템 개발자
- 시스템 분석가



정보시스템 구현의 분석관점은 아래의

4가지로 나누어 볼 수 있다

- 데이터 관점
- 프로세스 관점
- 연결 서비스 관점
- 외부 서비스 관점



정보 시스템을 구현함에 있어서 분석해야 하는 내용은 총

16가지이다

이에 대한 설명은

<그림 2-6> ~ <그림 2-8>에서 확인할 수 있다



정보시스템은 큰 프로그램을 대상으로 하므로

, 대부분의 경우, 객체지향 기술이 적용되며

“시스템 설계자”와 “시스템 개발자”는 이에 대한 지식과 기술을 가지고 있어야 한다



정보시스템 개발을 수행하는 프로젝트의 수행도 중요한 요소이다



정보시스템의 구현을 위한 분석 단계에서

PIECE Framework과 의사소통, 문서화는 절대적으로 중요하다



마지막으로 필요한 하드웨어와 소프트웨어 제품에 대한 지식도 필요하다

2.7 정보시스템의 종류

[ Front and Back Office Information System ]



프론트 오피스

(Front Office) Information System : 고객과 관련된 업무를 지원하는 프로그램

(예) 마케팅 시스템, 영업 시스템, 고객관리 시스템



백 오피스

(Back Office) Information System : 내부 직원과 관련된 업무를 지원하는 프로그램

(예) 인사관리, 재무관리, 제조, 재고관리 시스템

[ 트렌젝션 처리(Transaction Processing) 시스템 ]

트렌젝션 기반으로 업무를 처리하는 시스템
(Transaction : 시작하면 반드시 수행되어야 하는 업무의 단위, 중간에서 에러가 나면 처음의 상태로 돌아가야 한다(Roll-Back))
(예) 은행에 돈을 입금하는 경우

[ 경영정보 시스템(Management Information System:MIS) ]

기업의 경영 목표를 달성하기 위하여 다른 하위 시스템을 효율적으로 작동하도록 지원하는 시스템

[ 의사결정 지원 시스템(Decision Support System:DSS) ]

1978년 킨(Keen)과 스캇 모턴(Scott Morton)의 저서에서 처음 사용된 것으로 단순한 정보의 수집, 저장, 분배를 넘어서 기업의 의사결정을
지원할 수 있도록 분석의 기능을 수행하는 시스템으로 중역정보시스템

(Executive Information System:EIS)이라고도 한다

효과적인

DSS의 구성을 위해서 필요한 데이터를 한곳에서 관리하는 Data WareHouse/Data Mart 환경의 구현이 필요하다

2.7 Information System의 종류

[ 전문가 시스템(Expert System) ]

인간의 전문지식을 컴퓨터에 기억시켜서 일반인이 이용할 수 있도록 하는 시스템으로 인공지능

(Artificial Intelligence) 기술을 이용한다

최근에는

BI(Business Intelligence)로 확대하여 사용한다

(예) 의료진단 시스템, 설계 시스템

[ 사무자동화 시스템(Office Automation) ]

직원의 위치에 무관하게 직원간의 업무처리

, 의사소통, 정보공유, 일정관리 (=Work Group Information System, 그룹웨어(Groupware)) 또는

문서작업

, 메일, 개인일정, 보고서(=Personal Information System)의 업무를 지원하는 시스템을 말한다

2.7 정보시스템의 종류

경영정보

시스템

(조회)

트랜잭션

처리 시스템

경영정보

시스템

사무자동화

(워크그룹)

사무자동화

(개인)

데이터

웨어하우스

데이터

마트

의사결정

지원시스템

중역정보

시스템

전문가
시스템

운영

데이터베이스

운영

데이터베이스

운영

데이터베이스

워크그룹

데이터베이스

개인

데이터베이스

실무자

임원

실무자
임원

A 그룹

B 그룹



A 그룹 : 실무자들이 경영정보나 트랜젝션시스템을
이용하여 업무를 처리하는 환경

(입력, 조회)

 프런트 또는 백 오피스 시스템


B 그룹 : 의사결정시스템, 전문가시스템이
통합데이터베이스인 데이터 웨어하우스나 데이터

마트를 이용하여 업무를 처리하는 환경


C 그룹 : 팀이나 개인이 업무를 처리하는 환경

C 그룹

2.8 정보시스템 관련 중요 개념 정리



소프트웨어 아키텍쳐

(Software Architecture)는 소프트웨어의 구성 요소와 요소의 기능 그리고 그들간의 상호 관계를 top-down 형태로

정리한 것

. 소프트웨어 개발에 있어 고객과 개발자간의 의사소통을 위안 공통적인 표현 수단이다



엔터프라이즈 아키텍쳐

(Enterprise Architecture)는 전체 조직의 관점에서 application/software architecture, technology architecture,

Information/data architecture, organization/business architecture를 포함하는 개념으로 이를 통하여 전체 조직을 구성하는 각 요소들의

일치성

, 통합성, 연결성, 보안, 유연성, 재사용성을 높여서 비용절감과 경쟁력을 향상하고자 하는 개념이다



BPR(Business Process Reengineering)는 워크플로우(workflow)를 확장한 개념으로 기업의 핵심 프로세스를 최적화하도록 재설계하는
것을 말한다

. 일반적으로 ISP(Information Strategy Plan)과 연계하여 진행한다

BPR 방법론은 IDEF(Integration DeFinition) 방법론, EDS의 BPR 방법론, BCG의 W Reengineering, IBM의 BTC 방법론이 있다
BPM(Business Process Management)는 비즈니스 프로세스 모델링을 위한 표준이다



RTE(Real Time Enterprise)은 기업 내,외부의 지속적인 프로세스 개선과 실시간 정보 제공으로 업무 지연을 최소화하고 의사결정 스피드를
높여 경쟁력을 극대화한 기업을 말한다

. 이를 위해서는 BPM의 도입이 중요하다



ERP(Enterprise Resource Planning)은 기업이 필요한 정보 시스템을 통합하여 제공하는 것을 말한다. 하지만, 단순히 기능(인사, 재무…)의
통합으로만 보면 안되고 기업이 필요한 리소스

(프로그램, 직원, 기물, 일정, 업무처리 순서….)를 통합적으로 제공하는 개념이다.



EC(Electronic Commerce)는 미군이 물자 조달을 위해 개발한 CALS(Commerce At Light Speed)가 발전하여 성립된 개념으로 인터넷을
기반으로 비즈니스를 수행하는 것을 말한다

. B2B, B2C, B2G 등 다양한 종류가 있다

2.8 정보시스템 관련 중요 개념 정리

지혜

지

(Wiseness

Wisenes )

지식

지

(

Knowledge)

Knowledge

정보

정

(

Information)

Informati

데이타

데이

(Data)

Data

Decision

Experience

Timing

정보의 주관적 가치 확보

(의미론적 협업적 기능)

정보의 중개와 객관화

< 지식의 내용에 따른 분류 >
사물지

: 존재 자체를 앎

사실지

: 사물의 특성, 상태, 원리

방법지

: 인간 욕구를 해결하는 방법을 앎

< 지식의 형태에 따른 분류 >
암묵지

: 기억속에 저장

형식지

: 책, 설계도면, 말,...

* 터득에 시간이 필요
* 나누어도 줄지 않음
* 모두가 공유할 수 있음

* 암묵지가 형식지로
바뀌어야 가능함



KMS(Knowledge Management System)

2.8 정보시스템 관련 중요 개념 정리



BOS(Business Operating System)은 비즈니스의 수행을 위해 기본적으로 필요한 시스템을 말한다

< BOS의 구성요소>



EAI(Enterprise Application Integration: 전사적 응용 통합)



EIP(Enterprise Information Portal : 전사적 정보 포털)



GroupWare



KM(Knowledge Management)



SCM(Supply Chain Management: 공급망 관리)



CRM(Customer Relationship Management : 고객 관리 시스템)



SRM(Supplier Relationship Mangement : 공급업체 관계 관리 시스템



경영 전략적 기업 경영

(SEM : Strategy Enterprise Management)는 기업과 경영자가 전략적 목표를 달성하고 가치를 창출

하도록 지원하는 것을 말한다

< SEM의 구성 요소 >



VBM(Value Based Management) : 가치 중심 경영

: 주주와 투자자에게 최대의 이익이 가도록 각종 의사결정 및 평가를 수행



ABC/ABM(Activity Based Costing/Activity Based Management)
: 원가 관리 체계를 활동에 근거하여 측정한다



BSC(Balanced Score Card)
: 기업의 성과 관리 체계를 재무적 관점에서 벗어나 핵심적인 관점

(예: 고객 만족, 내부 프로세스 효과, 팀 학습 )을 균형있게 측정 관리하여 반영하는 것)

2.8 정보시스템 관련 중요 개념 정리



CMM(Capability Maturity Model) Process Management Model



CMM은 미국 카네기 멜론 대학의 SEI(S/W Engineering Institute)에서 개발한 모델



처음에는 국방성이 자신이 발주하는

S/W 프로젝트의 성공 가능성을 높이고 리스크를 줄이기 위하여 입찰자들에 대한

능력의 일관적 심사의 필요로 인해 개발되었으나

소프트웨어 프로세스 개선과 평가를 위한 실질적인

산업표준이 되고 있음



이 모델이 갖고 있는 성숙도에 대한 프레임웍이 국방 프로젝트

뿐 만이 아닌 상업적인

S/W 개발 업체에서도

인정을 받으면서 널리 활용되기 시작



1단계( 초기단계) ~ 5단계(최적화단계)의 5가지 단계가 있음

3. 정보시스템의 구현

3.1 정보시스템의 모습

3.2 정보시스템 개발의 기본 원칙

3.3 정보시스템 개발의 공통 기술

3.4 정보시스템 개발 단계

3.5 Information System 개발의 공통 원칙

3.6 정리

3.1 정보시스템의 모습

경영진

사용자

시스템
설계자

시스템
개발자

( S

)

시

스

템

분

석

가

데이터 관점

프로세스 관점

연결 서비스

관점

외부서비스

관점

서비스 수준

서비스 기능

연결 서비스

요구사항

외부 서비스의

요구사항

필요한

데이터

업무처리

순서

연결서비스의

기능

, 위치

외부 서비스의

기능

, 위치

데이터베이스

구조

어플리케이션의

구조

연결서비스의

연결방안

외부 서비스의

연결 방안

데이터베이스

프로그램

어플리케이션

제작

연결서비스의

연결

외부서비스의

연결

PIECE Framework

하드웨어

/소프트웨어 제품

지식 및 표준화 동향

의사소통 및 문서화 기술

1. 사전탐색

2. 문제분석

4. 제안요청 및

업체 결정

요

구

사

항

관

리

3. 요구사항분석

객체지향 관점

(Object-Oriented View)프로그래밍 + 프레임워크

프

로

젝

트

관

리

1. 범위협상 및

확정

2. 타스크 식별

3. 타스크수행

기간 예측

4. 타스크간 의존성

확인 및 일정관리

5. 자원의 할당 및

조직구성

6. 개발팀의 구성

및 운영

7. 감시와 통제

8. 프로젝트 종료

공통 기술

3.2 정보시스템 개발의 기본 원칙



경영진이나 사용자가 개발에 참여하여야 한다



문제해결 절차를 사용해야 한다

     -  문제를 구체적으로 정의한다
     -  문제를 발생한 이유를 파악하고, 잠재원인도 살펴야 한다
     -  문제의 해결을 위한 방안을 정리한다
     -  정리된 방안 중에서 최선의 방안을 선정한다
     -  선정된 방안의 수행을 위한 계획을 수립하고 실행에 옮긴다
     -  실행에 대한 상황을 점검한다
     -  문제가 해결되었는지를 확인하고, 미해결되었으면 위의 과정을 반복한다



개발 업무를

Top-Down으로 단계별 분리하고, 구체적인 내용을 정리한다  다음 페이지



개발에 관련된 표준을 세워

, 적용한다( 문서양식, 용어통일, 업무처리 절차, 개발자 환경, 공용 라이브러리 구성….)



예산에 맞는 시스템 개발 범위를 정한다



개발 요구사항의 변경

, 취소를 당연한 것으로 받아들여라



발생하는 문제는

Divide and Conquer 방법을 이용하여 분할하여 해결한다



시스템의 확장이나 변화에 대비하여 설계를 수행한다

3.2 정보시스템 개발의 기본 원칙

[ Top-Down 분석의 예 ]

인사관리시스템

정규직

임시직

해외지사

근무직

임원

유럽지역

미주지역

아시아

지역

생산직

사무직

3.2 시스템 개발의 기본 원칙

[ Top-Down 분석의 예 ]

택배 시스템

국내

해외

가격

무게

취급

VIP

일반

보통

무거운것

일반

가벼운것

부서짐

조심

일반

가격

무게

취급

VIP

일반

보통

무거운것

일반

가벼운것

부서짐

조심

일반

- 우리회사는 택배회사입니다.
- 택배는 국내, 해외 택배로 나누어 처리됩니다
- 택배는 가격에 따라 VIP, 일반, 보통으로 나누어집니다
- 택배는 무게에 따라 무거운 것, 일반, 가벼운 것으로 나누어집니다.
- 택배는 취급에 따라 부서짐, 조심, 일반으로 나누어집니다.

Top-Down으로 나누어 보면
전체 시스템의 모습과
공통요소

, 각 모듈의 기능, 연관성등을

알 수 있다

3.3 정보시스템 개발의 공통기술

Information System을 개발하는 과정에서 유용한 기법의 하나가 PIECES 프레임워크이다.
PIECES 프레임워크는 기존 Information System의 문제점을 식별할 때 사용하는 체크리스트이다.
(https://www.scribd.com/doc/7298188/PIECES-Framework 참조)

[ PIECES Framework ]

the need to improve Performance

(성능이나 반응속도)
I

the need to improve Information (and data)

( 출력데이터, 입력데이터, 저장된 데이터의 정확성, 중복성, 필요데이터의 존재, 접근성, 확장성)
E

the need to improve Economics, control costs, or increase profits

( 비용 및 새로운 분야에 대한 확장성)
C

the need to improve Control or security

( 입,출력 데이터의 조작성, 보안성, 데이터의 에러, 보안정책의 적정성)
E

the need to improve Efficiency(능률) of people and processes

( 업무지원 기능의 적절성, 사용하기 위해 필요한 것이 너무 많지않을 것)
S

the need to improve Service to customers, suppliers, partners, employees, etc.

( 배우기 쉽고, 사용하기 쉽고, 변경이 쉽고, 정확한 결과, 타 시스템과 연결이 쉽다)

Information System 개발을 위하여 고객과 인터뷰를 하거나 현재 운영중인 시스템을 분석하는 경우에

PIECES에서 제공하는 6가지 관점을 가지고 질문리스트를 만들거나 분석을 수행하면 좋다

(예)

경영진에게 질문리스트를 만드는 경우를 생각해 보자

고려할 것은
-

Data/Process/Interface/Network에 대하여 물어보아야 하고

PIECES( Performance, Information, Economics, Control, Efficecy, Service) 관점에서 질문리스트를 만들고 체크한다



현재 시스템에서 보여지는 데이터에 만족하시나요

? 좀더 보고 싶은 데이터가 있으신가요? (Data, Information)



현재 시스템에서

A 화면에서 B, C화면으로 넘어가는 데, 순서가 마음에 드시나요 ? (Process, Control, Service)



현재 시스템에서

C화면의 성능이 5초 정도를 나타냅니다. 불편하신가요? (Performance)



현재 시스템에서 사용자 정보에 대한 것을 추가로 보기 원하시나요

? (Interface, Efficiency)



….

고객으로 부터

Information System 개발에 필요한 정보를 얻기 위해서는 위와 같이 PIECES와 Data/Process/Interface/Network의

관점을 기준으로 질문하고 답을 얻으면 된다

다른 방법도 있겠지만

, Information System개발에 유용한 방법으로 이미 검증된 것이므로 사용하기를 추천한다

3.3 정보시스템 개발의 공통기술



의사소통 및 문서화 기술

- 상대방의 입장에서 대화하는 자세

- 모든 사항에 대한 문서화를 위한 양식과 절차의 표준화



하드웨어

/소프트웨어 및 표준화 동향

- 하드웨어 제품의 기능과 동향 파악(예: 서버, 네트웍 등

- 소프트웨어 제품의 기능과 동향 파악 (예: 데이터베이스, 개발도구 등)

- 표준화동향 파악(예: 데이터베이스 연결 표준 방식, 네트웍 연결 최근 표준, 오픈소스관련 표준 동향 등)

3.3 정보시스템 개발의 공통기술

3.4 정보시스템 개발 단계

임원

외부컨설턴트

문제분석

(Problem
Analysis)

요구사항분석

(Require-

mentAnaly-

sis)

제안요청 및

업체 결정

(RFP)

프로젝트팀

(Project Team)

: 고객, 임원, System Analyst, System Designer

새로운 비즈니스의 수행

새로운 영역의 추가

운영중인 시스템의
문제 해결