Search Results for '개론'


4 POSTS

  1. 2008.08.21 DFD(Data Flow Diagram)란?
  2. 2008.08.20 무료 UML 툴 & ERD 툴 [펌]
  3. 2008.08.19 DFD 흐름도 (1)
  4. 2008.08.06 SW품질 평가 기준 CMMI, 프로세스 개선 효과

DFD(Data Flow Diagram)란?

Posted 2008.08.21 14:45 by maxmini MAXMINI

DFD(Data Flow Diagram)란?

 DFD(Data Flow Diagram)데이터가 소프트웨어 내의 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림으로 소프트웨어 및 정보시스템의 분석과 설계에서 매우 유용하게 사용되는 다이아그램이다. 데이터 흐름도 또는 자료 흐름도 라고 칭하기도 한다.

 DFD는 시스템의 모형화 도구로서 가장 보편적으로 사용되는 것 중의 하나이며 데이타에 비해 기능이 매우 복잡하고 중요할 경우에 매우 유용하게 사용될 수 있다.

[그림 1] DFD의 예

 

 

구조적 방법론과 DFD

 DFD는 이른바 구조적 방법론을 대표하는 다이아그램이다.

   구조적 분석/설계 혹은 구조적 방법론은(DFD의 모습처럼 "자료흐름지향 방법론"이라고도 한다) 1968년 Dijskstra가 GOTO文의 폐해를 들어 구조적 프로그래밍(Structured Programming)의 개념을 소개하면서 시작되었다. 모든 방법론은 항상 프로그래밍으로부터 문제가 제기되고 이를 분석/설계에도 적용시켜보자는식으로 발전한다. 구조적 분석/설계에서의 데이터는 기능(또는 프로세스) 사이에서 주고 받는 형태로만 나타나며 기능의 계속된 분해와 이의 분석을 통해서만 데이터가 나타나게 된다.

 이 후 70년대를 거치면서 거의 대부분의 소프트웨어 개발은 '구조적'이라는 용어에 둘러싸이다시피 했으며 소프트웨어 공학에서도 가장 빈번한 이슈였다. 따라서 소프트웨어 개발과정의 중간 산출물로 DFD를 비롯한 DD(Data Dictionary), 구조도(Structured Diagram) 등이 많이 사용되었다. 그러나 소프트웨어의 규모와 복잡도가 커지고 기업에서 보다 많은 소프트웨어와 컴퓨터 시스템을 사용하게 됨에 따라 자료흐름 위주의 분석과 설계는 한계에 부닥치게 된다.

   정보시스템을 비롯한 MIS관련 소프트웨어는 많은 량의 데이터를 관리할 필요가 생기고 그 구조의 변경이 프로그램의 유지보수에 큰 영향을 미치기 때문이다. 따라서 프로세스 위주의 DFD보다는 데이터에 대한 분석/설계가 더 안정적이다. 최근의 정보시스템을 포함한 소프트웨어의 설계에서는 DFD의 중요성은 그만큼 덜 해지고 ERD(Entity Relationship Diagram) 같은 데이터 분석 도구가 더 유용하게 사용되고 있다.

 정보공학(Information Engineering)에서는 DFD를 거의 강조하지 않으며 데이터와 프로세스가 동시에 나타난다는 이유로 검증용 도구로 사용되는 정도에 그치고 있다. 그러나 실제 소프트웨어 개발 프로젝트에서는 아직도 DFD와 그에 따른 산출물들이 절찬리에 사용되고 있는데, 그 이유는 아마도 많은 개발자들이 이에 익숙해져 있고, 실제로 다른 다이아그램에 비해 DFD가 표현하고 이해하기가 매우 쉬운편이기 때문이 아닐까 생각된다.


DFD 작성의 이익

 다른 분석/설계용 문서 산출물들과 마찬가지로 다음과 같은 잇점을 가져다 줄 수 있다.

현업사용자의 업무 및 요구사항을 쉽게 문서화 할 수 있다.

현업사용자와 분석가(또는 개발자) 사이의 의사소통을 위한 공용어의 역할을 한다.

일관성 있고 정확한 사용자의 요구사항을 파악할 수 있는 요구분석용 도구의 역할을 한다


DFD의 특성

 DFD는 다른 다이아그램과 구별되는 다음과 같은 특징들을 갖는다.

도형으로 그려지는 그림 중심의 표현이다.

다차원적(Multidimensional)이다.

데이터(자료)의 흐름에 중심을 두는 분석용 도구이다.

제어(Control)의 흐름은 중요시 하지 않는다.


DFD의 구성요소

 DFD의 구성요소로는 프로세스, 데이터흐름, 데이터저장소, 외부엔티티 등이 있으며 표기법에 따라 표현하는 그림의 모양이 달라진다. 여기서는 Yourdon과 DeMarco에 의해 주장된 표기법을 기준으로 설명한다.

프로세스(Process) 

프로세스는 입력되는 데이터를 원하는 데이터로 변환하여 출력시키기 위한 과정으로 도형적 표기형태로는 원(Bubble)과 원안의 이름으로 표현한다.

원안에 기록하는 이름은 아래에 그림과 같이 프로세스가 수행하는 일 또는 프로세스를 수행하는 행위자를 기술한다.

프로세스는 자체적으로는 데이터를 생성할 수 없고 항상 입력되는 데이터가 있어야 한다.

프로세스는 항상 새로운 가치를 부가해야 한다.

[그림 2] Process

데이터흐름(Data Flow)

데이터흐름(Data Flow)은 DFD의 구성요소들간의 인터페이스를 나타낸다.

대부분의 데이터흐름은 프로세스들 사이를 연결하지만, 데이터 저장소(Data Store)로부터의 데이터흐름을 나타내기도  한다.

데이터흐름은 명칭이 부여거나 부여되지 않은 화살표로 표시한다. 단, 후속작업들의 참조를 위해 되도록 명칭이 부여되는 것이 바람직하다.

서로 다른 데이터 흐름에는 동일한 이름을 부여하지 않는다.

[그림 3] Data Flow

데이터저장소(Data Store) 

데이터저장소(Data Store)는 저장되어 있는 정보 집합이다.

데이터저장소는 테이프, 디스크, 카드 데이타, 캐비넷의 인덱스화일 등일 수도 있으며, 때로는 휴지통일 수도 있다.

데이터저장소는 단순한 데이터의 저장을 나타내는 것이지 데이터의 변동을 표시하는 것은 아니다.

데이터흐름을 표시함으로서 데이터의 입출력을 나타낸다.

데이터 흐름도에서 데이터저장소를 나타내는 표기법은 단순하게 두개의 직선 즉, 평행선으로 나타내고, 평행선 안에 데이터저장소의 명칭을 부여한다.

[그림 4] Data Store

  외부엔티티(External Entity) 

외부엔티티는 프로세스 처리과정의 데이터발생의 시작 및 종료를 나타낸다.

어떤 기업의 내적인(Inside) 외부엔티티는 관리, 부서, 기능, 시스템등을 포함하며, 기업 외적인(Outside) 외부엔티티는 고객, 거래처, 공공기관, 외부시스템등을 포함한다.

외부엔티티는 데이터 흐름도상에서 프로세스(Process)와의 상호관련성을 표시하며, 일반적으로 DFD 범위 밖에 사각형 형태로 표시한다.

[그림 5] External Entity


작성방법

 DFD의 작성방법은 다음과 같다.

업무를 분석하여 프로세스에 대한 모든 입출력 데이터흐름을 식별한다. 그리고 업무의 주변 경계에 그들을 표시한다.

데이터흐름상 필요하거나 제공되어야 할 외부엔티티를 정의한다.

입력으로부터 출력으로, 출력으로부터 입력으로, 또는 중간 지점부터의 데이터흐름을 식별한다.

모든 접속관계 데이터흐름에 주의깊게 명칭(혹은 자료 내역)을 부여한다.

프로세스에 대해 입력 데이터흐름과 출력 데이터흐름의 명칭에 따라 이름을 부여한다.

프로세스에 관련된 데이터저장소를 정의한다.

검토하고 보완한다.

상위레벨 DFD완성후 다음 하위 레벨의 DFD로 분할하여 최하위 레벨까지 그린다.

데이터 흐름도의 규모가 너무 커서 한 장의 종이에 그릴 수 없을 때는 시스템을 서브시스템(Subsystems)들로 분할한다.

 분할된 서브시스템들의 규모가 클때는 다시 분할을 계속한다. 이렇게 세분화를 계속하여 마지막에는 데이타 흐름도를 단순한 기능들만으로 그릴 수 있는 단계까지 분할한다. (일반적으로 레벨3까지면 적당하다)

배경도(Context Diagram) 

배경도는 분석하고자 하는 시스템과 외부 세계와의 접속관계를 식별하기 위한 것으로 시스템 분석의 범위를 결정하게 된다.

최하위단계 데이터 흐름도

최하위 단계의 DFD는 DFD 내의 모든 프로세스가 더 이상 하위 단계의 DFD로 분할되지 않는 데이터 흐름도를 말하며, 모든 프로세스들이 명세서를 갖는 기본단위인 것을 말한다.       상하관계

다음 그림은 분할된 데이터 흐름도의 상하관계를 보여주는데 상위 단계의 번호1로 표시된 프로세스가 다시3개의 하위 단계의 프로세스들로 분할되는 것을 보여주고 있다.

하위 단계에서는 분할된 프로세스들과 그들 간의 접속관계를 보여주며 상위 단계의 프로세스와 데이터흐름을 더욱 상세히 설명한다.

하위단계의 데이터 흐름도에서는 프로세스 분할뿐만 아니라 데이터 흐름의 변환과정도 자세히 나타나는데, 그림에서는 상위 단계의 데이터 흐름 A가 B와 C로 변환되는 과정을 상세히 설명하고 있다.

그러나 하위 단계는 상위 단계와 동일한 데이터변환을 하는 것이므로 순수입력과 순수출력은 상위와 하위 단계 모두 일치한다.

그림에서 또 유의해야 할 것은 상위 단계의 프로세스1이 분할된 하위 단계의 프로세스들은 1.1, 1.2, 1.3 등과 같은 번호를 부여받는다. 마찬가지로 하위 단계의 프로세스 1.2가 다시 분할된다면 그것의 하위 단계 데이타 흐름도는 다시 1.2.1, 1.2.2, 1.2.3 등과 같이 된다.

[그림 6] DFD의 분할


작성규칙

 DFD 만큼 애용되는 다이아그램도 없지만 또 DFD 만큼 잘못되게 그려지는 다이아그램도 없다. 많은 개발자들이 정확한 DFD의 작성 방법을 몰라서, 또는 시간이 부족해서 부실한 다이아그램을 그리고 만다.

   DFD는 일반적으로 Context Diagram을 포함해서 레벨 3까지 분할되면 적당하며, 레벨간의 데이터흐름, 외부엔티티, 데이터저장소가 반드시 일치해야 한다.

 또한 모든 데이터흐름과 데이터저장소는 프로세스에 연결되어 있어야 하고, 입력이나 출력 중 어느 하나만 있는 경우는 Blackhole과 Miracle이라 하여 옳지 않은 것으로 본다. 또한 데이터저장소간의 데이터흐름의 연결도 피해야 한다.

데이터 보존의 원칙(Conservation Rule)

어떤 프로세스의 출력 데이터흐름은 반드시 입력 데이터흐름을 이용하여 생성된 것이어야 한다는 것이다. 아래 예에서 사과라는 데이터는 쥬서라는 프로세스를 통해 사과 쥬스가 되어야 한다. 따라서 오렌지 쥬스라는 출력은 잘못된 것이다.

[그림 7] 데이터 보존의 원칙

최소데이터 입력의 원칙

최소데이터 입력의 원칙은 어떤 프로세스가 출력 데이터흐름을 산출하는데 반드시 필요로 하는 최소의 데이터흐름만을 입력해야 한다는 것이다.

아래 그림에서 보는 바와 같이 실급여액 계산이란 프로세스가 필요로 하지 않는 근무시간은 이 처리를 통과하지 않고 지나친 다는 것을 보여주고 있다.

[그림 8] 최소데이터 입력의 원칙

지속성의 원칙

프로세스는 입력 데이터흐름이 들어오기만 한다면 항상 수행할 준비를 갖추고 있어야 한다는 것이다. 다음 그림에서 보는 한영번역 처리는 어떤 개인용 컴퓨터에서 실행할 수 있는 소프트웨어로 구매할 수도 있다. 이 때 번역 프로그램을 수행시키면 항상 번역을 실행할 준비를 하고 한글단어가 입력되기를 기다리고 있다는 점에서 지속성을 갖게 된다.

[그림 9] 지속성의 원칙

순차처리의 원칙

순차처리의 원칙은 데이터흐름 또는 데이터저장소로부터 입력되는 데이터에 대한 처리 순서를 설명하는 데, 데이터흐름을 통해 입력되는 데이터는 도착되는 순서대로 처리하는 반면, 데이터저장소로는 어떤 순서에 의해 접근하여도 무방하다는 것을 의미한다. 다음 그림에서 주목해야 할 것은 한영사전이란 프로세스에서 보는 것처럼 한글단어 데이터흐름의 첫번째 단어인 책이 맨 먼저 처리되어 book이란 단어로 데이터저장소에 저장되는데, 이들은 접근 순서에 무관하게 저장되어 있다.

[그림 10] 순차처리의 원칙

영구성의 원칙

영구성의 원칙은 데이터흐름의 데이터는 처리된 후 없어지지만 데이터저장소의 데이터는 아무리 읽어도 없어지지 않는다는 것을 말한다.

데이터변환의 원칙

분석시 불명확한 점의 하나는 어떤 종류의 프로세스를 데이터 흐름도 상에 나타내야 하는지 판단하기가 어렵다는 것이다. 이러한 경우에 도움이 될 수 있도록 4가지 종류의 프로세스 형태가 존재한다. 데이터본질의 변환, 데이터합성의 변환, 데이터관점의 변환, 데이터구성의 변환 등이 있다.

데이터본질의 변환

아래 그림에서 보는 바와 같이 데이터흐름 본질의 변환은 일반적으로 입력 데이터흐름에 편집, 계산 등을 하여 출력 데이터흐름을 산출하는 것을 의미한다. 아래 그림에서 소득증가율 계산이라는 프로세스는 금액으로 표시된 소득의 값을 입력으로 받아 퍼센트로 표시된 증가율로 변환을 한다.

[그림 11] 데이터본질의 변환

데이터합성의 변환

아래 그림에서 예금처리라는 프로세스는 입력데이터의 본질을 변화시키지 않는다. 이러한 형태의 프로세스는 단순히 하나의 입력데이터를 여러가지 구성요소로 분리하여 2개 이상의 출력을 산출한다. 반대로 2개 이상의 입력 데이터흐름에 대하여 데이터합성의 변환이 발생할 수도 있는데, 그림에서와 같이 수표와 입금표라는 데이터항목이 합성되어 입력 트랜잭션이라는

       하나의 출력 데이터 흐름을 산출한다.

[그림 12] 데이터합성의 변환

  데이터관점의 변환

아래 그림에서 보는 것처럼 데이터관점의 변환은 데이터에 대해 실제적으로 변경을 하지는 않는다. 이러한 형태의 처리에서 입력 데이터 흐름은 동일하게 출력 데이터흐름으로 나타나게 된다. 그림에서 주문서 확인은 주문서에 대해 변경을 하지 않고 그대로 출력으로 내보내게 된다. 따라서 출력 데이터흐름의 이름을 적합한 주문서라 하였으며, 데이터사전에서도 주문서가 정의되어 있는 한 새롭게 정의할 필요가 없다.

[그림 13] 데이터관점의 변환

  데이터구성의 변환

데이터구성의 변환에서는 출력데이터가 입력데이터와 동일하지만, 데이터의 구성형태가 변환되게 된다. 구성의 변환은 포맷팅(Formatting) 또는 정렬(Sort) 등을 위한 처리를 필요로 하게 된다. 이러한 처리형태의 출력은 다른 데이터흐름으로 생각될 수도 있고 아닐 수도 있다.

다음 그림에서 판매보고서는 데이터사전에 새로운 데이터흐름으로 들어갈 수 있는데 보고서의 실물모형(Mock-Up)이 될 것이다. 만일 처리가 정렬을 위한 것이라면 출력을 입력과 다른 데이터흐름으로 간주하여 정렬된 판매데이터라 할 수 있다.

[그림 14] 데이터구성의 변환


출처 : Tong - byunji4558님의 Java, JSP, JDBC, Java Beans, and etc.통

Tag : dfd

Write your message and submit

무료 UML 툴 & ERD 툴 [펌]

Posted 2008.08.20 11:52 by maxmini MAXMINI

[펌] http://club.cyworld.com/5205735812/49408185

uml뿐만 아니라 그냥 요구사항 같은거 그림 그리기 좋은거 같아서요^^


starUML

https://sourceforge.net/project/showfiles.php?group_id=152825&package_id=169190&release_id=437438


이클립스 플러그인 UML이라네요

http://calamity84.oranc.co.kr/tt/entry/Eclipse-Plug-in-EclipseUML-320-Studio


DBDesigner라는 프로그램입니다

http://www.fabforce.net/downloads.php


디비디자이너에서, ERWin처럼 쓰려면( 즉, 테이블 간의 관계를 삼발이처럼 보이려면)

메뉴에서 Display->Notation->Crows foot( 까마귀발형태)로 하면 됩니다.

Tag : ERD, UML

Write your message and submit

DFD 흐름도

Posted 2008.08.19 14:18 by maxmini MAXMINI
http://blog.naver.com/airip/60024518696


업무 흐름도

사용자 삽입 이미지


DFD중위도
사용자 삽입 이미지


ERD
사용자 삽입 이미지


ER-Win
사용자 삽입 이미지


Tag : dfd

  1. | 2009.08.20 14:50 | PERMALINK | EDIT | REPLY |

    비밀댓글입니다

Write your message and submit

SW품질 평가 기준 CMMI, 프로세스 개선 효과

Posted 2008.08.06 15:55 by maxmini MAXMINI

CMM(Capability Maturity Model)은 미국 카네기 멜론 대학의 SEI(Software Engineering Institute)가 IT 개발의 프로세스 관리능력 향상을 위해 미국방성(Department of Defense)의 자금 지원을 받은 프로젝트로 1986년부터 연구하기 시작하여 1991년도에 발표한 표준 모델이다. CMM은 가장 먼저 개발된 SW-CMM을 일컫는 말이기도 하지만 현재는 소프트웨어 이외에도 적용할 수 있는 많은 분야가 있어 이런 부류의 성숙도 모델을 총칭하는 의미로 사용된다. SW품질 평가기준으로 널리 사용되고 있는 CMM의 후속 모델인 CMMI(Capability Maturity Model Integration)는 소프트웨어와 시스템 기술의 프로세스 개선을 위한 통합모델로 2001년 발표되었다. SEI는 2005년부터 CMM에 대한 지원과 업데이트를 중단하고 CMMI 확산에 주력하겠다는 방침을 밝힌바 있다.


CMMI 프로세스 능력 성숙도

CMMI는 조직의 프로세스 개선을 통한 소프트웨어 개발 과정에서의 비용, 품질, 일정 등 모든 것을 충족시키며 특정 성숙도 레벨로 진입하기 위한 최소한의 기준 제시와  반드시 수행해야할 활동들의 집합으로, 프로세스 프레임워크의 성숙도 향상을 위한 모델이다. CMMI 모델의 각 프로세스 영역(Process Areas)의 특별 목적(specific goals, SP)와 공통 목적(generic goals, GG)의 달성정도를 측정함으로써 프로세스 개선 수준을 나타낼 수 있다. CMMI는 조직의 SW 개발뿐만 아니라 시스템설계, 하드웨어, 운영 등 시스템통합(System Integration, SI) 사업 전반에 대한 프로세스를 평가하고 정의하는 방법인 SCAMPI(Standard CMMI Appraisal Method for Process Improvement)를 제공한다. 특히 제품 또는 서비스의 개발, 획득, 유지보수하기 위한 조직의 공정 및 관리 능력을 향상시키기 위한 가이드를 제공과 이를 통해 프로세스 개선 시 필요한 목표와 체계의 제공이 가능하다.  5단계로 구성되는 CMMI의 성숙도 레벨은 평가 조직의 프로세스를 개선 및 평가하기 위해 실행해야할 실행지침을 포함하며, 성숙한 조직의 각 레벨별 특징은 아래의 표에 설명하였다.


[소프트웨어 프로세스 성숙도 레벨 5단계]

레벨

특징

레벨 1

Initial

개인의 역량에 따라 프로젝트의 성공과 실패가 좌우된다. 소프트웨어 개발 프로세스는 거의 없는 상태를 의미한다.

표준화된 프로세스 없이 구행결과 예측이 곤란한 조직

레벨 2

Managed

프로세스 하에서 프로젝트가 통제되는 수준으로 조직은 프로세스에 대한 어느 정도의 훈련이 되었다고 볼 수는 있지만, 일정이나 비용과 같은 관리 프로세스 중심이다. 기존 유사 성공사례를 응용하여 반복적으로 사용한다.

기본 프로세스 구축에 의해 프로젝트가 관리되고 있는 조직

레벨 3

Defined

레벨 2에서는 프로젝트를 위한 프로세스가 존재한다면 레벨 3에서는 조직을 위한 표준 프로세스가 존재한다. 모든 프로젝트는 조직의 프로세스를 가져다 상황에 맞게 조정하여 승인받아 사용한다.

세부 표준 프로세스가 있어 프로젝트가 통제되는 조직

레벨 4

Quantitatively

Managed

소프트웨어 프로세스와 소프트웨어 품질에 대한 정량적인 측정이 가능해진다. 조직은 프로세스 데이터베이스를 구축하여 각 프로젝트에서 측정된 결과를 일괄적으로 수집하고 분석하여 품질평가를 위한 기준으로 삼는다.

프로젝트 활동이 정략적으로 관리․통제되고 성과 예측이 가능한 조직

레벨 5

Optimizing

이 레벨에서는 지속적인 개선에 치중한다. 조직적으로 최적화된 프로세스를 적용하여 다시 피드백을 받아 개선하는 상위 단계이다.

지속적인 개선활동이 정착화 되고 최적의 관리로

프로젝트가 수행되는 조직

 

프로세스 개선 효과

전세계 많은 기업들은 조직의 프로젝트 수행능력 향상을 위해 CMMI를 적용하고 있으며, 국내ㆍ외에서 최근 프로젝트 참여나 제품 공급을 위한 전제조건으로 제시되는 경우가 늘어나면서 IT서비스 기업은 물론 많은 제조, 금융권 기업 등이 CMMI 인증 획득을 추진하고 있는 추세이다. 흔히, CMMI 도입의 타당성을 얘기하면서 투자대비 효과를 언급한다. 아래 표는 SEI에서 CMMI를 적용한 기업의 프로세스 개선 효과에 대해 발표한 자료이다. 프로젝트 일정준수율 이나 생산성, 품질, 비용, 고객만족도 측면에서 많은 효과를 본 것으로 나타나고 있다. 물론 이런 긍정적인 효과를 본 조직이 전체적으로 많지는 않지만 충실하게 CMMI를 적용한 조직에서는 이러한 긍정적인 효과를 얻을 수 있을 것이다. 그러나 국내 기업들의 CMMI 적용의 효과는 조사 결과만큼 좋지 못한 것이 사실이다. 이러한 원인은 국내 SW개발 문화의 차이나 CMMI 적용방식의 차이 등에서 찾을 수 있을 것이다.

[프로세스 개선 효과]

Improvements

High

Low

Median

# of data points

Cost

83%

5%

26%

8

Schedule

90%

15%

55%

10

Productivity

75%

11%

28%

4

Quality

72%

33%

47%

6

Customer Satisfaction

55%

10%

33%

3

Return on Investment

13:1

2:1

3.8:1

4

* 출처 : Evidence about Impact and Value Added: One Year Later(Dennis R. Goldenson, Diane L.Gibson, 2004.11)

Tag : CMMI, SW품질 평가 기준, 프로세스 개선 효과

Write your message and submit