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

왜 대형 IS 프로젝트는 실패할까?

 
요구사항 명세서를 작성해서 계약함.
 
사용자의 정보 요구가 달라진다는게 큰일이에요. 뭔가 바뀌는 게 있는데, 잘 안바뀌는거 위에 바뀌는게 올라가는건데. 5~6가지 시스템 구성 요소에서 가장 중요한게 Data랑 SW가 가장 중요하다고 하죠. SW랑 Data가 중요하지. 데이터가 안정적인데, 데이터에서 안정적인게 무엇일까. Logical Representation of data가 안정적인거에요. 그 조직에서 중요시 여기는 엔티티의 종류는 잘 안바뀐다.
 

 
Entity Type과  Entity Occurrence은 다르다. Entity Occurrence은 각 프로덕트의 라인.
 

 
데이터 모델과 프로세스 모델을 헷갈린다. 데이터 모델은 흐름이 없음. 데이터 모델은 특정 상황을 스냅샷을 찍은 것임.
또 다른 채널이 나타나도 그대로에요. 데이터 종류. 데이터 간의 관계를 나타내 주는 것이 데이터 모델이다. 즉, 어떤 종류의 데이터, 그들간의 관계를 나타낸 것이 데이터 모델임.
 
원재료가 ER임. 추가 요구조건을 바꾸는건 별거 아님.
 

물리적인 DB랑 개념적인 DB는 다른거에요. 개념적인 DB는 하나에요. 애플리케이션끼리 공유를 하는데요. Cash flow 계획을 세워야 하는데요. 안정적으로 공유하면서 사용할 수 있음. 왜 이런식으로 설계를 하면, DB가 안정적이라서. 저거 말고 뭐가 있을까. 회사와 관련된 데이터가 각 애플리케이션 마다 따로 저장되어 있었음. 예전에는 중앙 DB에서 관리할 수 있는 기술이 없었어요.
 

서로 사용하는 용어가 다름.
Bloc Time 비행시간.

# 비행기 그림
 

 
개발자와 관련된 문제가 뭘까요. 문제점과 해결방안. 사용자 관련 문제점과 해결방안을 써라 하면 잘 못쓰는 경우가 많음. 시험에 잘 나와요.
 

회계 시스템 만드는데, 공대 전공 출신에게 시스템 구축을 맡김. 공대생이 회계 거래의 8요소 물어보면 알 수 있나? 그러면 SI 회사 입장에서는 어떻게 해야하나. 방법론이에요.
 

방법론이 뭐냐면 시스템 development life cycle을 구체화 하는거에요.
 
# 소프트웨어 개발 사이클 그림

엔티티란? 크게보면 회사에서 중요한 리소스가 무엇이냐.
 (내가 웹에서 찾아본거: 엔터티에 대해서 데이터 모델과 데이터베이스에 권위자가 정의한 사항은 다음과 같다.)
변별할 수 있는 사물 - Peter Chen (1976)
데이터베이스 내에서 변별 가능한 객체 - C.J Date (1986)
정보를 저장할 수 있는 어떤 것 - James Martin (1989)
정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념 등 - Thomas Bruce (1992)
 
 
다대다 관계는 DB상에서 구현이 불가능 하기 때문에 중간에 변환해야 함.

 
검증은 사용자가 하고 쓰는건 프로그래머들이 씀.
 

 
위의 4단계 시험에 나옴. 안나올 수도 있고. ㅎㅎ
물리적으로 SDLC를 구현해 놓은게 방법론. 일관된 프로젝트의 퀄리티를 보장할 수 있는게 방법론.
 

하나는 Data의 관점 하나는 process(activity) 관점.
 

건물 설계하고 짓는거랑 똑같다고 했잖아요.
나중에 가면 심각해져요.
 
# 과제: 교재
 

저자들의 방법론을 정리해볼 것. 테이블을 만들 것.
#과제

 

 
 
DA가 여러명인 경우에 2번 같은 문제가 발생할 수 있음. 여러 사람들이 하다가 보면 Coordination이 잘 안될 수 있음. 개발자들은 Documentation을 싫어해요. 왜냐면 Documentation은 설거지 같은 것. 프로그래밍은 요리와 같은 것. 나름대로 재밌음. 그런데 문서작업은 그런게 아님. 5) 리소스는 항상 부족해.

Maintenance를 Analysis 단계에서 하는 것임. 프로그램은 지가 짬. ER에서. 코드 자체를 바꾸려고 하면 이해를 해야함. 그러면 시간이 걸리는 것임. 진흙탕에 안빠지고 앞단에서 만드는 것.
 

 

CASE랑 방법론은 상호 보완적인 관계임. CASE가 methodology가 아니고, 대안도 아님. 서포트해주는 하나의 기술일 뿐.

Repository가 무엇인가. 제일 중요한 거에요.
 

시스템에 대한 모든 knowledge가 한 곳에 모여 있는거야.

Source & Object Code 는 조금 달라요. 이건 다음에 설명해줄게요.
 
# 딕셔너리

데이터 딕셔너리의 단위는 어트리뷰트 Attribute (field): 이름, 학번 -> 모이면 Record (Entity Occurrence): 이순규 -> Entity Type: 학생

 

Oracle Desinger 9i
 

 

 
프로그램 구조는 Repository에 들어있음. 실제 코딩한 건 Program Library에 있음. 이건 외워야 함.

 
Lack of IS development Resource 같은 경우는 자동으로 코드를 짜주는 툴이 있음.
 

분석 설계할 때 가장 많은 비용이 들어감. 왜냐면 구현에는 다양한 툴이 있어서 비용의 절감이 가능함. 100% 짜주는 것은 아니지만 많은 도움을 줌.

SQL 고치는 것과 ER 고치는 것의 차이.
 
I-CASE는 개발 전반적인 부분을 설계할 수 있는 통합툴을 의미함. ERwin은 DB만 부분적으로 설계할 수 있기에 I-CASE 툴은 아님.
 

 
선후관계를 나타내는 것이 PERT

 

MS Project로 그린 차트.
 
교재 p105 14번 문제. Activity J, H, I, B에서 B가 빠져있음. 이걸 추가

 
 
2016-03-15 정량적 데이터 분석 - 연세대학교 정보대학원 수업내용

 
정말 중요한 것 인가. new와 interesting 사이에서 고민. Interesting 부터 시작할 것.
방법론 이슈는 가장 중요한 이슈중 하나.

항상 시작은 phenomenon에서 시작임. 참고 문헌이 아니라. 사회 현상이나 비즈니스 인사이트를 지니는 현상 부터 시작해야함. 그렇지 않으면 연구를 위한 연구를 하게 된다. 연구를 위한 연구를 하게되면 여러가지 문제를 가질 수 있음. 리뷰를 통과하기도 어렵고. New 한 걸 만든다고 하더라도 interesting하지 않을 수 있음. '사회 현상'을 뒤져야 함. 신문, 아티클을 많이 보세요. 컨퍼런스나 저널 같은 곳의 Call for paper를 보면 여기에 도움이 될 것임. 여기에 대해 initial literature review를 함. 기존에 비슷한 연구가 있는지. 있으면 어떻게 할 것인지 이런 것들을 고민해볼 것.
 
Theory 라고 하는 것은 창문임. 그 하나로 모든 것을 볼 수는 없을 것임. 하나의 스터디로 모든 것을 커버할 수는 없을 것임. 그래서 하나의 관점이 필요한 것이고 이것이 theory. 하나의 연구에 대해서 어떤 관점으로 바라보느냐. 그것이 theory의 역할임. 온라인 behavior를 측정하는 theory도 많은데, 이 중에 어떤 것을 선택하느냐도 중요한 부분임.
 
Research Model을 만들기 전에 Theoretical Framework를 만들 것.
 

Research Topic을 선택을 할 때, 어떠한 토픽을 선택할 것인가.
 
이 과목에 최종 Output은 Term output을 내는 것. 이번학기를 통해서 학위논문을 만드는 것이 가장 좋을 것.
Topic을 빨리 골라야함. 저널의 special issue 쪽 찾아볼 것.
 

 
논문 자체를 이런 structure로 가져간다고 하면 논문 구성에 있어서는 반 이상 먹고 갈 수 있을것.

 
----

요즘에 세컨더리 데이터 관련된 분석이 늘어나는 추세임.
이 과목은 주로 behavioral Research 가 주된 목적. Relevance에 관련된 3가지 포인트가 있죠.

기존 연구가 없는 이유는 뭘까요? 두 가지가 있어요.  1. 토픽 자체가 의미가 없어서 연구가 안될 수 있고, 2. 상당히 중요함에도 불구하고 아직 연구가 이루어지지 않을 수 있다. 만일 1이 아니라 2라면 Relevance에 대한 서술이 먼저 이루어져야 한다. 기존 문헌 연구가 없을 때, 졸업논문으로 쓰면 안된다. 이 토픽이 과연 어떤 연구하고 연관지을 수 있는가. 어떤 Theory와 연결 시킬 수 있는 부분에 대해 고민해 보아야 함. 좀 더 Refine 하는 작업이 필요할 수도 있겠다. 이것이 결국 new에 대한 이야기를 할 수 있어야 해요. Contribution에 대해 화두를 던질 필요가 있다. 차별화 된 부분을 쉽게 알 수 있겠죠. 실제로 주어진 기간안에 해결할 수 있는 논문인가에 대해 생각해볼 필요가 있어요. 항상 시작 포인트는 비즈니스 측면에서 재밌는 부분인가에 대해 생각해보아야 해요.
실제로 It에서 인정받고 있는 부분의 저널을 나열해봤어요. 여기에서 topic에 대한 인사이트를 찾을 수 있겠죠.

Key symptoms을 찾아보아야 해요.
 

ERP 시스템이 상당히 중요한데, 인더스트리 리포트를 보니까, ERP 시스템의 구현과정의 실패를 찾아보니까. 6~80%가 원래 의도한 것을 만족시키지 못한다고 함. 그렇다면 Management 입장에서는 안좋은 것이죠. 프로젝트 실패의 가장 큰 원인중에 하나가 '사용자 저항' 이더라. User 저항. 위의 슬라이드에서 1~3 단계가 굉장히 중요한 이슈에요.
 예를 들어, 빅데이터가 요즘 이슈인데, 사실 투자대비 효과를 못 뽑고 있다. 그런 상황에서 key problem은 시스템은 잘 있는데, 잘 못쓰고 있다는 것이 key 문제임. 그럼 IS-infusion (full-utilazation)을 위한 동기는 무엇인가. 항상 흐름이 이렇게 1~3단계가 유기적으로 잘 돌아가야 해요.
 
--

 
인트로덕션을 잘못쓰면 심사위원들에게 가장 bias를 많이 주는 것임. 그래서 잘써야함.
 

Setting the hook이 정말 중요함.

 
이 후에 스토리 라인이 정말 중요한 것임. 아무리 강조해도 모자라지 않을 정도로 introduction이 정말 중요합니다.
----
 

정리할 포맷이 무엇인가. 여기에 따라 테이블 포멧이 달라져야 해요.

이런 유형의 선행연구 정리 방법이 있죠. 다른 방법으로 어떻게 정리할 수 있을지도 고려해 보아야함.

IS-infuion에 관한 연구. 예시.

각 기준들을 잘 정리하고 연관성있는 구조를 찾아본 결과. 기존 연구의 체계를 통해 선행연구를 정리하면 새로운 장점을 얻을 수 있음. 아래와 같이. 매핑하면 두 가지를 얻을 수 있음. Status Quo Bias Theory의 타당성이 어느정도 설명이 된다. 기존연구를 보면 내가 택한 이론에 다 들어가므로 타당성을 지닌다. 두번째로는 기존 연구에서는 모든 3가지 도메인을 한꺼번에 연구한 경우는 없다. 때문에 우리 연구가 더 중요하다라고 말할 수 있음. 이렇게 되려면 Background Theory랑 Literature Review가 조합되어야 함.

결국 Literature Review를 통해 테이블을 만들고, 이 2개를 이야기 해야합니다.
 

기존 연구의 missing point, 이 연구의 목적과 연결되도록. 여기에서 나온 테이블을 통해 우리가 적용한 Theory의 타당성을 설명할 수 있다면 금상첨화.
 

절대불편의 진리. 협의의 Theory.
광의의 Theory. 누구든지 만들 수 있으면서 어떤 현상을 설명할 수 있는. 원인과 결과를 설명할 수 있는. 추가적으로 리서치가 이루어진. Statement.
우리는. 기존 연구에서 검증된 theory.
어떤 변수들 간의 관계를 define한. 원인과 결과에 대한 Statement의 집합체. 현상을 설명하는 것이 Theory.
 

 

 
Variance Theory : 요인을 찾아내는 건 정량적 연구
Process Theory : 순서를 밝히는 건 대부분 정성적 연구
 

리서치 모델을 가져오면, 이게 원인과 결과에 따른 모델인가 프로세스 모델인가를 혼돈하는 경우가 있음. Time Sequence가 아님. 리서치 모델은 여러분들에게 있어 광의의 theory가 됩니다.

What은 변수
how는 화살표. 원인과 결과를 말함.
Why왜.
 

초반에 변수를 찾아내는거. 선행연구에서 찾아냈다? 절대 그러면 안된다. 선행연구 150개 봤다? 그러면 1000개 보면 변수가 달라지는 건가? 여기에 답할 수 없음. Theory에서 찾아냈다고 해야함. 하나의 Theory가 Boundary Condition이 되는 것임. 때문에 왜 여러가지 이론중에 이걸 쓴지가 정말 중요한 포인트가 된다. 그래서 Theoretical Foundation이라고 하는거에요.

하나의 연구에는 하나의 뷰 포인트를 담아야 함. 그래서 background Theory가 필요함. 아주 안좋은 리서치의 전형적인 예시임. 리서치 모델은 As simple as possible 해야함.

이론에서 찾아낸 변수들이 무엇인지를 Psychological commitment에서 설명.
기존의 연구들에 대한 걸 종합해서 Technology Acceptance literature에서 설명.
그리고 new point를 switching costs를 통해 설명.

 

 

 
Self-Presentation Desire 때문에 물품을 구매하는 이유? 명품구매 같은거.
---
논문의 포지셔닝. 해당 모델이 모바일 쇼핑에 적용이 되고 오프라인 쇼핑에도 적용이 되는 모델이면, Context Unique를 어떻게 잡는 것이 중요함. 인트로덕션을 다르게 써야 한다는 의미. 하지만, 현실적으로는 모든 영역에 적용될 수 있는 모델이 아니라 특정 도메인에서 적용될 수 있는 모델에 대해 적용할 수 있는 걸 해야함.
 
가설의 설명 3가지 방법. 1. 기존 연구에서 이렇게 했기 때문에 우리는 이렇게 한다. (가장 안좋음) 2. 이론적 설명이 되어야 함. Theoretical implication 측면. 3. 본인 생각. Conceptual argument

Customer Value 이론 2가지. Value의 타입을 고려할 수 있는거랑.
 

Overall Value에 관한거랑. 전혀 다른 approach.
 
2016-03-10 Business Models - 연세대학교 정보대학원 수업내용

Case study. 첫번째까지 2주 남음.
총 9개의 팀 구성이 이루어져야 함. 일부는 혼자 발표하거나 2번 발표하거나 해야함. 비즈니스 케이스를 하나 골라서 해야함.

린 스타트업이라는 개념은 상당히 시간과 금액이 많이든다. 비즈니스 모델을 만드는데. 충분하게 만드는데 시간이 걸리는데, 일단 시장에 던져보고 이걸 바탕으로 피드백을 받아서 고객으로부터 수정을 해나가는 것이 린스타트업의 핵심임. 짧게 짧게 빨리빨리.

프로토타입을 한 번 만들어보라. Term Project를 할 때, 그런식으로 진행될 것이다. 이런식으로 만들어 보면 보다 현실적이 될 것임.

Every product have their lifecycle.

TV나 자동차는 Time이 길게감.

 

스마트폰이 차별화가 안되기 시작했음.

Differentiation - high price doesn't matter. 어떻게 하면 high 퀄리티 서비스를 제공할 것인가가 중요함.

예전에는(Unfilled need) 상품만 가지고도 괜찮았었는데, 이제는 이미 니즈가 다 충족된 상황에서 그 이상이 필요해지기 시작함. 김밥천국 -> 불쑈 있는 음식점.

 

Product innovation approach 보다 Business model approach 가 더 나은 성과를 가지고 온다.

Target Customer: 일반 대학생들과 청담에 있는 레스토랑에 갈 커플이나 사람들의 가치는 다름. 고객에 따라 비즈니스 모델이 맞물려 가는 것임.

Functional Value : 기능적인 가치.
Monetary Value : 금전적인 가치. ( e.g. lower price)
Social Value: Social Image.

* 플랫폼 비즈니스. 다양한 비즈니스 주체들이 콜라보레이션하면서 비즈니스 가치를 창출하는 것. Value Network을 형성하는 것.

 

위에 있는 비즈니스 모델 중에서 6가지 컴포넌트를 선택할 수 있음.
 

나이키의 가치? 브랜드 밸류. 
가장 중요한 거. Revenue, 타겟 커스터머, 커스터머 밸류.

How to Start an Internet Business - Video 3A of 10

Affiliate Marketing 제휴 마케팅: 예를 들어, 아마존
 
How to Start an Internet Business - Video 3B of 10
 

 
아마존 닷컴 -> Revenue 모델. Sales + Transaction fee 모델.
AWS -> Subscription 모델 사용.
 
페이스북이나 구글은 직접적으로 생산하는 것이나 기여하는 게 없다는 비판을 받기도 함.
아마존의 경쟁상대는 월마트인데, 이미 작년에 주식이 아마존이 더 높아짐.

Facebook은 광고비용이 95% 수익을 차지함.
 

대표적인 예가 구글 search. 싸이. 예전의 음반 판매 수익이 BM의 가장 큰 비중을 차지함. 하지만 지금은 유튜브.  인지도를 높여서 콘서트로 돈을 범. 대부분 초기 비즈니스에 freeconomics를 활용함. 대표적으로 카카오톡을 이야기 할 수 있죠.
 

Process flow 그리는거 처럼.
Flow chart 에서 중요한게 비즈니스 파트너를 찾은거에 있음. 그들간에 뭐가 흘러다니는 건가가 중요함.
 
* 비즈니스 모델 캔버스.

 
Flow chart는 큰 그림을 그리기엔 좋음. 그러나 디테일이 부족함. 그걸 Business Model Canvas가 채워줌.
스타벅스 BM Canvas 예시.

 
BM에서 고객의 기준: 단순히 수익을 주는 사람이 아니라, 서비스를 받는 사람을 고객으로. 유튜브의 경우 고객은 영상을 보는 사람. 광고주는 파트너.
 
2016-03-10 SAD - 연세대학교 정보대학원 수업내용

 

우리가 알고 있는 시스템은 뭐가 있을까요? 수강신청? 정부도 시스템이고. 자동차도. 시스템 정의의 첫번째는 서브 시스템과 컨포넌트가 많다는 것. 몸도 시스템. 장기도 각각 시스템. 상호작용을 함. 생명체도 하나의 시스템. 살아 있는 것은 다 같다. 학교도 하나의 시스템. 체계적으로 구성되어 있는 것. 교학과도 하나의 체계가 있음. 목적은 뭐에요. 목적을 위해서 interact 하는 거에요. 행정체계. 수강신청 받는 것도 하나의 체계. 3가지는 꼭 있어야 함. 엔티티, 인터렉트, 목적.

시스템은 Boundary가 있어요. 시스템 안과 밖을 구분해주는 경계. 사람 몸의 바운더리는 피부. 연세대학교의 구성원은 어디까지인가. 이 경계가 조금 애매하죠. 여기에서 Boundary : 물리적, 추상적. 확실한 것은 고대 다니는 학생들은 연대 학생들이 아닌거죠. 그럼 이 Boundary의 역할은 뭐냐. Filtering 의 역할을 하죠. 바운더리가 있으면 외부에서 이렇게 리소스가 들어오죠. 이 경계해서 걷어내는 것이죠. 환경에서 들어오는 것을 다 받는게 아니라 경계를 통해 걸러내는 것이죠. 그리고 시스템을 통해 나가는 경우 변화가 일어나죠.

환경하고 상호작용 하는 경우 오픈 시스템. 상호작용 안하는 경우 closed 시스템. 예를 들어 북한. 은하계를 포함한 우주. 대부분 오픈 시스템이라 할 수 있겠다.

시스템의 중요한 특성을 이야기 할 수 있는데, Entropy에 대해 이야기 할 수 있죠. 시스템은 가만히 놔두면 죽는다는 거에요. 회사나 학교는 망하고 없어지겠죠. 한 30년? 없어지지 않으려면 어떻게 해야 하는가. Negative Entropy를 계속 줘야 해요. Negative Entropy를 계속 준다는 게 뭐에요? 컨트롤 하는거에요. 피드백을 주는거죠.
 

Output을 계속 분석하는 거에요. 개선을 하기 위해서. 그런 노력을 하지 않으면 변하는 거에요. Output의 수준을 평가해야해요. 이 과정에 문제가 생기면 죽는거에요. 학교 같은 경우. 사회에서 요구하는 인재를 배출해야해요. 어떻게 체크하죠? 취업률. 연봉. 고용 만족도 등. 학교 입장에서 학생 수를 늘리면 학생들의 수준이 떨어질 수 있음. 우리 필드에서 5년만 변하지 않고 있으면 도태될거에요.

어떤 현상의 수를 구하는 것이 Measure의 정의임.  만족도. 교수의 강의는 수준을 어떻게 측정할 수 있나요?

다른 과목 같은 경우, 90년대 사례를 쓰는 경우가 많아요. 우리 필드 수업은 힘들죠. Objective Measure 수단을 찾기가 힘들어요. 이걸 찾는게 중요하죠.

전체 시스템에서 Sensor에 해당하는 Objective Measure 수단을 찾는게 정말 중요해요. 인사고과 평가하는 것도 마찬가지. 객관적인 dimension으로 사전에 합의된 기준으로 평가 해야하는 거에요. 이거 굉장히 중요한거에요.

산출물이 정보 혹은 비즈니스 프로세싱이에요. 정보가 뭘까요. 정보하고 Raw data하고 뭐가 다를까요.

Data: Descriptions about facts. 사실에 대한 묘사.
정보는 기본적으로 데이터에요. 정제되고 조직된 목적을 위한.

모델은 현상을 추상화 시켜놓은 것이에요. 데이터 중에서 의사결정과 연관이 있는 것이 정보임. 유용성 Usefulness과 관련성 Relevance. 한남대교와 관련된 교통 정보는 나와 관련성이 있기 때문에 정보임. 연남대교와 관련된 Data는 raw data임. 그렇기 때문에 Refine과 processing이 중요한 것이 아님. 의사결정에 얼마나 연관되어 있는가가 가장 중요함.

내 시스템의 사용자들 혹은 고객이 그 데이터의 바다 중에서 어떤 데이터를 필요로 하냐. 그것들을 찾아내는 테크닉이 중요한 것. 

지식. Knowledge 란, (내가) 인증한 정보임. 내 마음속에 있는 것이 지식임. 지식이 그렇기 때문에 자신의 행동에 영향을 미치는 것임. 개인화된 정보. 정확하지 않을 수도 있음. Huber나 Nanaka에 있어서 지식은 entity(사람)에 의해 정당화된 믿음임. 지식에 관한 2번째 정의에 의하면 지식간의 포함관계가 달라질 수 있음. 이전까지는 정보중에 지식이 있다고 배웠지만, 2번째 정의에 의해서는 정보가 아닌 지식이 존재함. 지식으로 가는거면 전달할 수 있는거냐 없는거냐 이런 것도 있고. 어렵죠. 구분하기. 예를 들어 연구 능력의 경우는 전달하기 참 어려워요. 그래서 도제 제도라는게 있어요. 그렇게 되면 가능하죠. 테싯 날리지는 전달이 가능해요. 그게 바로 도제제도에요. 이게 날리지라는게 참 어려운 면이 있어요. 표현은 가능하지만 전달은 가능한 부분. 날리지 이론에 대해서는 Explicit knowledge 표현이 가능한 지식.(Information) 그리고 Tacit Knowledge 표현이 불가능한 지식도 있죠.

상호작용의 의미가 뭐냐. 하나가 바뀌면 다른 것들도 연쇄적으로 바뀐다는 것임. 예전에 프로젝트 들어갔던 부분 중에, 쿼리가 오래걸린다였는데. 백업을 안한대. (쉬는시간) 서로 영향을 주고 받기 때문에 시스템 분석가는 시스템 전체를 봐야 함. Systems Philosophy 조직 안에는 어떤 구성요소가 있을까요. 조직도 위의 그림처럼 볼 수도 있어요.

정보시스템이 바뀌는 것 때문에 조직내의 구성 요소가 바뀔수도 있음. 이런 것은 시험에 나올 수 있음. 기술 때문에 회사의 목적이나 Value가 바뀌는 경우.

 
아마존의 경우가 그렇죠. 크리스 마스 시즌에 정보시스템 용량 때문에 못팔았죠. 아마존이 크리스마스 시즌에 파는 매출 비중이 한 해 매출의 40%를 차지하죠. 그래서 아마존은 4억불을 매년 IT에 투자했죠. 매년 5천억을 그렇게 투자했죠. IT 기반이 단단해졌고 이걸 기반으로 AWS를 도입. 그리고 요즘 드론 배송하죠. 아마존은 이제 로봇해요. 창고에서 물류관리를 로봇이 해요. IT 때문에 이제 회사의 목적이 달라져요. 구글이 뭐하는 회사야? 검색? 안경도 한다고 하고 인공지능도 한다고 하고. 목적이 달라지는 거죠. IoT 시대에 빅데이터 시대의 Management는 어떻게 할 것인가.

Span of control : 예전에 매뉴얼로 컨트롤 할 수 있는 직원의 숫자가 Maximum 10~15명임. Manage 할 수 있는 능력이 한계가 있었음. 그런데 지금은 그게 아님. IoT와 빅데이터 시대에 달라진 것임.

94년에 쓰여진 논문에 제시된 개념. Middle-up-Down Management 스킬. IoT나 빅데이터 시대가 오면 M.C가 확 줄어들 것이다 라고 접근을 할 수도 있는데, 그렇지 않다는 거죠. Middle Level Manager 들의 역할이 점점 더 중요해질 것임.

중간관리자 레벨이 현실에서 Sense Making 할 수 있는 위치임.

IoT 시대에서는 팔고 끝이 아니죠. 때때로는 product은 공짜로 줄 수도 있죠. 정보를 분석해서 더 큰 Value를 줄 수 있죠. 거기서 Charge를 할 수도 있죠. 물건이 파는 대상이 아니게 되는거죠. 그렇게 되면 Customer Success Management 라는 조직이 생기겠죠? // 회사에 생겼습니다. 이번에. // 데이터가 리소스가 되는 것이죠. 데이터 전담 부서는 왜 없나. 가트너에서 2017년 정도에는 데이터 전담 조직이 생길 것이라고 말함. 전체적으로 Architecture가 달라지잖아요. Security가 뚫릴 수 있는 여지가 많아졌죠. 이것을 전담할 부서도 생길 것이다. 

이야기 하는 포인트가 뭐냐면, Technology가 변화하면서 그 외에 것들이 계속 변화한다는 것이죠. Informal Organization도 요즘에는 스마트 워크랑 스마트 오피스가 확대되고 있죠. 키스디에 있는 제자가 서울역에 있는 스마트 워크 센터에서 근무하더라고.
 

전체를 봐야 한다는 것임. Technology 때문에 서로 영향을 받아서 바뀐다는 것이죠. 그 중에 아주 중요한 것이 무엇이냐. interrelationship이 정말 중요한 거죠. 기존에 있던 M.C 관리자들은 어떻게 될까요. 기존에 있던 M.C 관리자들은 요즘 시대에 요구하는 Sense Making을 제대로 처리하기 어려워져요. 그래서 중간 관리자들이 저항을 할 수 있고, 저항을 하면서 시스템을 때때로 공격할 수도 있다. "(제대로 된 데이터 넣지 않고) 봐라 데이터 결과 잘 안나오지 않느냐" 이런식.

시스템 분석은 뭘하는가. 문제해결능력이 중요한 것이죠. 서울에 짜장면 집이 몇 개나 있느냐. 이세돌과 알파고는 누가 이길 것인가. 문제를 프레임화 하는 것이죠. 분석하고 종합하는 것이에요. 시스템 분석이라는 것은. 세상의 문제가 복잡하니까 단순화 시켜 나가는 것임. 주요 변수를 뽑아가지고 이것들을 집중적으로 보는 것이죠. 이것이 분석이에요. 정보시스템 분석에서 관련된 변수는 어떤 것일까요. 정보시스템의 문제는 무엇일까. 정보시스템이 Address 하는 문제는 뭘까.

정보처리 요구가 뭐냐를 결정하는 것임. 2가지. 하나는 데이터. 하나는 프로세스.

요구사항 분석은 위의 슬라이드에 나온 것들을 찾아내는 것.

나온 요구사항을 어떤 관점으로 볼 것인가. 크게 두 가지. 프로세스, 데이터 관점. (프로세스 모델링, 데이터 모델링)
Data, Process,
Event (Logic & Timing)

Alternative Generation and Selection은 이런 문제를 어떻게 해결할지에 대한 대안들. 직접 개발한 것인가. 패키지를 가져다가 쓸 것인가. 이런 것들을 하는 것이죠.

설계는 뭐에요. Technology Dependant 한 거에요. 코딩하는 사람들이 알아볼 수 있도록 기술 배경을 정하는 거죠.

부모의 기본키를 외래키로 갖게 되면 관계 표시가 되죠. 구체적으로 오라클이나 IBM DB에 표시를 해줘야 하는데. 그게 물리적 설계에요. 파일이 깨진다는 말이 뭐에요? 링이 끊어진다는 거죠. 자식에 있는 포인터가 다시 부모를 가리키면 링형이 되는거죠.

하드웨어 설계, 소프트웨어 설계, DB 설계, 프로세스 설계, 네트워크 설계. 이런게 시스템 분석 설계에요. 우리 수업에서는 네트워크 요구사항 뽑아내는거 까지만 해요. 두 서버 사이에 얼마만큼 자주 커뮤니케이션이 있어야 하는지 등을 결정하는 것이죠.

SDLC라는 것이 다음과 같은 절차를 거침. 

 

Feasibility가 차지하는측면이 큼.

경제적, 기술적, 운영적, 일정상, 법적, 정치적.
클라우드가 왜 클라우드? 구름 저편은 안보여서. 필요에 따라 쓰기만 하면 되는거지. 독일에서 법을 발표함. 독일에서 발생한 데이터는 독일에서 가져갈 수 없음. 데이터 센터를 독일에 만들라는 뜻. 클라우드 말고.

교재에 나오는 SDLC에요. 논리적인 개발 절차임. 그렇기 때문에 어떠한 시스템 개발이라도 이 절차를 따라가게 되어 있음.
 
정보공학 방법론 Information Engineering.
이게 어떻게 되어 있느냐.

정보 전략 계획.
전략 -> 분석 -> 설계 -> 구축.
프로세스(Activities), 데이터
 
정보전략계획 (Information Strategy Plan)

ISP를 하게 되면 프로세스 관점에서 나와야 하는 산출물이 있고 데이터 측면에서 나와야 하는 산출물이 있어요. 현업에서는 이렇게 따라가지 않는 경우가 많음. 시스템 내용은 안나오고 높은 레벨의 이야기만 나옴. 어떤 솔루션을 도입해야 하고, 견적에 대한 이야기만 함. PM의 감에 의해 견적을 이야기하더라. ㅋㅋ; 감리와 자문. Function Point 따져서 해야하는데, 대부분 그렇게 하고 있지 못하다.

ISP는 보면 사실 그대로 버리고, 단순히 비용 산정의 근거의 역할만 하고 있는 실정임. 저걸 안하면 이렇게 되는 것임. 사실 ISP가 제대로 되어야 실제 구현 단계에서 다시 처음부터 하는 그런 결과는 나타나지 않는 것임. ERP를 고치면 되요? 안되요.
 

+ Recent posts