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

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가 빠져있음. 이걸 추가