2016-03-31 SAD - 연세대학교 정보대학원 수업내용

비즈니스 리소스를 규명하고 그리고 순서대로 따라가야함.

리소스 라이프 사이클을 따라가야함.

function에 대해 질문.

프로세스는 쪼갤 수 있는 Activity임.
 
프로세스는 딱딱 구분을 지을 수 있음. 인풋이 있고 아웃풋이 있음. 시작하는 시점이 있고 끝나는 시점이 있음.
 

고객이 주문을 내면 주문 접수가 되고 주문 접수가 완료되면.
주문 들어갈 때, 인풋 정보가 있어요. 짜장면 주문할 때, 내가 어디살고 원하는 메뉴는 무엇인지 등.  Output은 Order Accepted or Rejected에 관한거. 프로세스의 내용은 뭐야? 재고가 있는지 없는지. 공급자가 언제까지 줄 수 있는지 등. 고객 신용도 조사 등. 데이터를 써. CRUD 하는거죠. 이런 처리를 거쳐서. (Take order) 그 결과 Order Accepted or Rejected가 나오는거죠. 

 
프로세스하고 데이터가 헷갈리는거에요. 왔다갔다 하는게. 프로세스는 데이터를 쓰는 거임. 프로세스의 결과로 데이터가 나옴. 프로세스가 데이터를 순서대로 써야함. 처음에 고객 먼저 체크를 해.

데이터 모델링은 정적인거에요. 거기에는 순서를 들이대면 안된다.

고객이 오더를 낸다. 그리고 오더 내린 것이 아이템이다. 이런 순서를 데이터 모델링에 넣으면 안된다. 한 순간의 스냅샷을 찍어서 그 순간에 이루어지는 데이터들을 봐야하는 것이죠.
 
Function과 프로세스, Data. 구분할 것.

이런건 하지마세요. 나가는 것만 있거나 들어오는 것만 있는거는 만들면 안된다.
 

영어니까. 동사 중에서도 Strong Action Verb를 써야해요. 뒤에 나오는 명사가 Entitiy Type이 될 수도 있고 Attribute가 될 수도 있어요.

새로운 정보를 만들어 내면 프로세스임. 전혀 새로운 정보를 만들지 않는 프로세스도 있어요. 조회. 조회 프로세스도 정보를 만들어내요. 로그. 수표에 이서를 하는 것도 프로세스에요.

Function Decomposition Diagram이라고 했죠.

점점 구체화된 Activity로 나아가는거죠.

 

 

No more No less 하위의 프로세스를 합하면 위의 프로세스와 같은 거죠.
 

세부적으로 내려가면 위와 같은 장표가 수백개가 있죠.
 

Master Production Schedule
 

프로세스의 그룹핑을 사람마다 다를 수 있지만, 세부 프로세스가 빠진게 있으면 안된다.

재고관리에 원자재 관리랑 제품재고 관리를 같이 넣는 경우가 있는데 그러면 안되요. 왜냐면 리소스 라이프 사이클이 서로 다르기 때문이죠. 실제로 원자재 창고랑 완성품 창고가 달라요.

ER을 들여다 보면 parent가 없는 경우가 있어요. Sale Order는 parent가 있어요. FDD에서 오른쪽으로 넘어가기 전에 꼭 필요한 정보는 왼쪽에서 만들어 줘야 하는 것이죠.
 
프린트샵을 생각해보죠. 프린트샵이 주문생산이죠?
Element 간의 순서. 이런게 빠져있음. 프로세스들 사이의 관계.

Process Dependency Diagram 은 쉬움. 학교에서는 어려운거 배워야지.
DFD를 그리는 방법을 배우는 거죠.
위의 그리믄 고객이 수금처리하는 다이어그램이에요.

ERwin와 파트너는 BPwin.  BPwin으로 이거 그리는거죠. 패키지마다 표현 방식은 조금씩 달라요. I-CASE는 아님. Upper-CASE임.
사각형
외부객체. 시스템의 외부.
 
 

시스템 외부 객체끼리 주고 받는 것은 모델링 하는 것이 아님. Destination. 목적지. 프로세스안에는 데이터를 저장하는 공간이 없음. 끝날 때만. 프로세스는 Run이 끝나면 날아가는 거.

프로젝트하고 그림을 그려보면 화살표는 Data flow임. 툴 안에서 flow를 클릭하면 그 안에 필요한 데이터를 반드시 지정을 해야함. 프로세스 모델링을 어떻게 해야 하는가. 분석하고 설계할 때, 이게 반드시 아웃풋으로 나와야 실제 코딩으로 진행했었음.
 
 
 
 
 
 
 
 

+ Recent posts