2011/03/31 11:40
동영상 RIA
 



저작자 표시 비영리 동일 조건 변경 허락

'PE' 카테고리의 다른 글

RIA  (0) 2011/03/31
5W2H  (0) 2011/03/03
마인드맵  (0) 2011/03/01
u-City  (0) 2011/02/22
Tim O'Reill가 주장한 Web2.0의 7가지 원칙은 무엇인가?  (0) 2011/02/21
SDLC 모델 - 폭포수(watefall), Prototyping(PoC, Pilot), 나선형(Spiral), 반복&점진적(iterative&incremental)  (0) 2011/02/21
Posted by 푸른_바람
2011/03/03 13:43
5W2H 원칙에 충실하라.
  • What?
    목적이 무엇인가?
  • Who?
    대상은 누구인가?
  • When?
    언제?
  • Where?
    어디서?
  • Why?
    왜?
  • How?
    어떤 방법으로?
  • How much?
    얼마의 예산으로?

저작자 표시 비영리 동일 조건 변경 허락

'PE' 카테고리의 다른 글

RIA  (0) 2011/03/31
5W2H  (0) 2011/03/03
마인드맵  (0) 2011/03/01
u-City  (0) 2011/02/22
Tim O'Reill가 주장한 Web2.0의 7가지 원칙은 무엇인가?  (0) 2011/02/21
SDLC 모델 - 폭포수(watefall), Prototyping(PoC, Pilot), 나선형(Spiral), 반복&점진적(iterative&incremental)  (0) 2011/02/21
Posted by 푸른_바람
2011/03/01 08:30
관련주제어를 중심으로 뻗어나가는 가지의 깊이를 같은 개념으로 채워 사고를 확장시키는 개념의 생각을 정리하는 방법.
  • 어떤것을 읽고 공부하고 사고하고 기억하기 위해서 머리속에 그림을 그리는 것

마인트맵 요소
  • 중심주제 - 이미지화해서 나타내는게 좋다. 중심이미지는 전체 내용을 모두 포함할 수 있다.
  • 이미지 - 이미지를 더 강화하라
  • 핵심어
    • 핵심단어를 찾아라
    • 문장을 표현할 수 있는 이미지로 표현할 수 있다.
    • 핵심 이미지는 핵심단어보다 더 압축된다.
  • 주가지
    • 부가지
    • 세부가지
  • 부가지
  • 세부가지

Note
  • Note Taking
    • 다른사람의 생각이나 사설을 지면에 적는것.
    • Note Taking 중심 이미지 잡기 
      • 다른사람의 생각을 정리하여 주제를 이미지화 한것
  • Note Making
    • 나의 생각 나의 아이디어, 자신만의 이야기를 지면에 적는것.
    • Note Making 중심 이미지 잡기
      • 자신의 고유한 생각을 이미지화 한것.

공부진행 순서
  1. Copy
    • 설명을 단순히 적는다.
  2. Question
    • ?를 던진다.
  3. Mind Map
    • 고민
  4. Talk
    • 복습
  5. Teach
    • 복습

부가지와 세부가지를 꺼집어 내는 방법은 중심주제에 맞는 생각을 무작위로 나열 한 뒤(꺼집어 낸 뒤) 각 요소와 동등한 개념의 요소를 유추해서 추가한다.

에빙하우스의 망각곡선
준비효과 - 어떤 내용을 학습하기 전에 관심에 의해 학습효과가 증진되는 효과
창의성 - 공부한 내용을 다른 방식을 생각하면 창의성이 늘어는다.
저작자 표시 비영리 동일 조건 변경 허락

'PE' 카테고리의 다른 글

RIA  (0) 2011/03/31
5W2H  (0) 2011/03/03
마인드맵  (0) 2011/03/01
u-City  (0) 2011/02/22
Tim O'Reill가 주장한 Web2.0의 7가지 원칙은 무엇인가?  (0) 2011/02/21
SDLC 모델 - 폭포수(watefall), Prototyping(PoC, Pilot), 나선형(Spiral), 반복&점진적(iterative&incremental)  (0) 2011/02/21
Posted by 푸른_바람
2011/02/22 17:38
문) u-City
답)
  1. 정의
    1. 정보통신과 건설의 융합모델로 첨단 IT기술을 바탕으로 도시의 효율적 관리 및 시민이 필요한 정보를 언제 어디서나 제공할 기본을 갖춘 도시를 말한다.

  2. 공정 모델




* u-City 서비스 활성화방안 정리
  1. 개념 및 배경
    • 도시경쟁력강화와 삶의 질 향상을 위해 유비쿼터스도시건설 기술을 이용해 건설된 도시의 기반시설을 이용 유비쿼터스도시 서비스를 제공.
  2. 현황
    1. City 형
      1. 도시전체에 기반시설을 조성하고 이를 이용해 u-서비스를 제공.
      2. 정부 및 공공기관 중심의 사업.
    2. Town 형
      1. 일부 개발된 기반시설 또는 건축무을 통해 u-서비스를 제공.
      2. 민간개발자 및 재개발/재건축 조합 중심의 사업.
    3. u-City 사업 주체인 LH공사가 재무구조 악화를 이유로 사업중단을 검토중(2010년 12월 현재).
      1. 118조원 부채.
      2. 감사원 감사 결과 택지분양가격 상승및 재무구조 악화의 원인이 되는 과도한 시설 설치 재검토 권고.
      3. 사업추진 지자체에서 u-City구축은 택지개발의 필수시설이므로 LH공사의 결정에 반대입장.

  3. 문제점 분석
    1. 예산문제
      1. 파급효과와 편익을 명확하게 예측하기 어렵다.
      2. 사업의 지속적인 수행을 위해 지자체의 재정자립도나 추진역량이 고려되지 않았다.
      3. 정부예산에 의존하여 지역홍보사업을 u-City라는 명목으로 추진하는 경우가 많다.
      4. 시범사업이 종료되어 정부지원이 끝날경우 직접 수행할 여력이 없다.
    2. 공공서비스 위주의 u-서비스만 존재.
      1. 기존 행정서비스를 오프라인에서 온라인으로 전환 서비스가 대부분이다.
      2. 수익창출이 어렵과 예산을 소비하는 서비스이다.
      3. 국토해양부 제시 228개 서비스에 대한 분석이 미비해 공공과 민간부문 추진이 모호하다.
    3. 표준화된 플랫폼, u-서비스 검토가 이루어지지 않고있다.
      1. 각 서비스간 호환/연계 문제 발생 가능성 대두된다.
      2. 서비스 학산과 완성도 높은 서비스 제공에 어렵다.
    4. 정보통신 하드웨어 측면을 강점으로 하는 Push 전략
      1. 공급자 위지의 서비스 개발과 이를 확대하는 Push 전략이다.
      2. 수요자 참여가 없어 수요자가 체감할 수 있는 서비스 부족하다.
      3. 제공 서비스가 기존 행정서비스 전산화가와 차별되지 않고있다.
      4. 주민 편익을 위한 실질적인 서비스 제공이 안된다.
    5. 벌률 상충
      1. 유비쿼터스도시화에 관한 법률은 유비보수를 확보하기 위한 수익사업을 할 수 있는 법률이 마련되어 있다.
      2. 개별법인 의료법, 전기통신기본법, 옥외광고물들관리법에서 허용하지 않고 있다.

  4. u-City 서비스 활성화 전략
    1. 행정, 방범, 방재 분야
      1. 공공성은 높고, 시장은은 낮음.
      2. 지자체에서 당연히 제공해야 하지만 시장성이 낮기 때문에 재정자립도가 저조한 지자체는 국고 보조 등 다른 비용 조달 방안 마련이 필요하다.
      3. 행정분야 서비스는 전국적으로 서비스되어야 함으로 중앙저부 차원에서 서비스 플랫폼을 만들어 보급하는 편이 유리하다.
      4. 지자체간 연계성이 낮기 때문에 정보, 지자체등 공공부문에서 주도하여 수행하는것이 바람직하다.
    2. 교통 분야
      1. 시장성은 높고, 공공성은 보통.
      2. 서비스 제공을 통해 수익을 기대할 수 있다.
      3. 재정적으로 어려움을 겪고 있는 지자체에서도 용이하게 추진할 수 있다.
      4. 확장성과 연계성이 높다. 이는 전국 어느지역에서는 교통서비스가 제공되고 있다는 점에서 중앙정부가 표준 모델을 만들어서 보급하는것이 적절하다.
    3. 시설물 관리 분야
      1. 시장성은 낮고, 공공성은 보통.
      2. 사업경쟁성이 낮기 때문에 지자체에서 수행하지 않는것이 적절하다.
      3. 연계성도 낮기 때문에 민간과 연계하지 않고 공공부문 중심으로 서비스를 제공하는것이 낫다.
    4. 물류 및 기타 분야
      1. 공공성은 낮고, 시장성은 높음.
      2. 사업화가 가능한 분야로 연계성도 높기 때문에 민간부문에 아웃소싱하여 수행하는것이 바람직하다.
    5. 환경 분야
      1. 공공성은 높고, 나머지는 낮음.
      2. 주민의 삶의 질 제고를 위해서 환경 분야 서비스를 제공해야 하지만 수익을 기대하기는 어렵다.

  5. 결론
    1. 국토해양부가 분류한 68개의 통합 서비스를 기초로 서비스의 속성을 팍악한 후, 속성을 고려한 전략적 u-서비스 추진이 이루어져야 한다.
    2. 신도시 건설 중심의 기존 u-City 사업은 건설경기에 따라 부침이 심하기 때문에 민간부문이 주도하는 주민 체감형 u-서비스 개발/보급을 통해 지속 가능한 u-City 사업으로 정핵방향을 전활할 필요가 있다.
    3. 수익성 향상을 통한 u-City의 안정적 운영을 위하여 민간부문의 참여를 고려한 u-City 추진체제로 개선해야하며, 기본 IT인프라 구축등 대기업 위주의 건설이 중심인 u-City 추진체계를 종소기업의 u-Learning서비스와 지자체의 u-서비스를 연계하여 제공할 필요하 있다.
    4. u-City 및 u-서비스의 활성화를 위한 관련 법제도를 정비해야 한다.
      1. u-Health서비스 활성화를 위을 '의료법' 개정.
      2. u-광고서비스와 '옥외공고물관리법' 개정.
      3. 경찰청과 자자체 간의 사고차량저보 교류등 다양한 분야의 공공정보 고류를 저해하는 제약 요인 제거가 필요하다.
      4. ITSㅎ 활성화를 위한 구가 차원의 통신표준화 제정 및 컨트롤타워 부재에 따른 부처이기주의 제거가 필요하다.
      5. 현행 법제도 개선이 단기적으로 어렵다면 u-City 지역만이라도 우선적으로 u-서비스가 정착되어 발전할 수 있는 여건 조성이 필요.

저작자 표시 비영리 동일 조건 변경 허락
Posted by 푸른_바람


  1. The Web as Platform - 플랫폼으로서의 웹
  2. Harnessing Collective Intelligence - 집단지능으로 힘을 모은다.
  3. Data is the Next Intel Inside -  다음 인텔 인사이드는 데이터
  4. End of the Software Release Cycle - 소프트웨어 릴리스 주기의 종말
  5. Lightweight Programming Models - 가벼운(Lightweight) 프로그래밍 모델
  6. Software Above the Level of a Single Device - 단일 디바이스를 넘어선 소프트웨어
  7. Rich User Experiences - 풍부한 사용자 경험
From What is Web 2.0, Tim O’Reilly, 2005

  1. 웹2.0은 인터넷 비즈니스 기술의 변화를 요약, 정리하여 체계화한 것이다.
  2. 웹 2.0 핵심개념
    1. 개방(Openness)
      정보와 서비스를 개방하고 공유하여, 정보자원의 가용성과 효용성 증대를 지향하는 열린, 평등공간을 위한 기술
    2. 공유(Sharing)
      개방된 정보자원을 상호 공유하므로써, 정보자원의 재사용성과 가용성등을 제고할 수 있으며, 공유된 정보자원의 창조적 혼합을 통해서 새로운 유용한 정보자원의 생성과 풍부한 사용자 경험을 제공
    3. 참여(Participation)
      공급자로부터 소비자로의 권력이동(power shift)이 발생하여, 정보자원의 생성, 공급 및 소비의 모든 과정에 사용자가 직접 참여하는 양방향 상호작용의 기술로 변모
    4. 협업(Collaboration)
       함께 연구 토의하고, 함께 설계 개발하고, 함께 조립 제작하는 공동의 작업공간으로 변모
  3. 웹 2.0이 가지는 특징
    1. 플랫폼으로서의 웹
      효율적이고 확장성을 가진 서비스를 제공
    2. 집단지능으로 힘을 모은다.
      집단지능을 이용한다.
    3. 다음 인텔 인사이드는 데이터
      재창조가 어려운 데이터 소스를 컨트롤한다.
    4. 소프트웨어 릴리스 주기의 종말
      사용자를 신뢰하고 공동 개발자로 여긴다.
    5. 가벼운(Lightweight) 프로그래밍 모델
      가벼운 사용자 인터페이스, 개발 모델, 그리고 비즈니스 모델을 채용한다.
    6. 단일 디바이스를 넘어선 소프트웨어
      단일 디바이스를 넘어서는 소프트웨어를 제공한다.
    7. 풍부한 사용자 경험
      많은 사람들이 사용할수록 보다 풍부해지 서비스.




저작자 표시 비영리 동일 조건 변경 허락
Posted by 푸른_바람
소프트웨어 생명주기 모델


문) 폭포수(watefall) 모델
답)
  1. 정의
    • 소프트웨어 생명주기(SDLC)에 기반하고 있는 소프트웨어 개발기법중 하나로 개념정립부터 구현까지 높은 추상화에서 낮은 추상화 단계로 하양힉 접근하는 방법을 사용하며, 각 단계는 끝날때마다 과정의 끝을 알리고 그 다음단계로 진행하게 된다.
  2. 진행단계
  3. 장/단점
    1. 진행과정을 세분화하여 관리가 용이하다.
    2. 개발단계가 겹쳐서 각 진행단계에 문제가 발생시 그 이전단계로 피드백이 되는경우가 발생한다.
    3. 개발단계마다 대부분 순환이 발생되어 순차 흐름을 따라가기 힘들다.
    4. 고객요구를 개발초기에 구체화하기 어렵다.
    5. 시스템이 개발완료되는 시점에야 완성이 가능하다.


문) 프로토타입(Prototyping) 모델
답)

  1. 정의
    • 불완전한 요구사항 분석에 대한 해결책으로 간단한 시제품을 만들어 사용자의 요구를 수용해서 시스템을 보완해 나가는 방법
  2. 진행단계
  3. 장/단점
    1. 폭포수 모델보다 사용자요구를 철처히 분석하게 되므로 실패율이 적다.
    2. 시스템의 기능이 사용자에게 보여짐으로 이해당사자간의 오해와 기능에대한 정의가 명확해져 고품질의 시스템을 명세화하는데 기초가 된다.
    3. 완제품에 대한 오해를 불러일으켜 너무 많은 변화를 유도할 수 있다.
    4. 시스템의 극한상황에 대한 평가가 어려워 시스템간 교류및 평가가 힘들다.

 

문) 나선형(Spiral) 모델
답)
  1. 선형순차형과 프로토타입 모델의 정점을 결합한 모델. 위험분석을 추가하여 시스템 개발시 발생하는 위험을 관리하고, 최소화하는 벙법
  2. 진행단계
  3. 장/단점
    1. 비용이 많이들고, 시간이 오래걸리는 큰 시스템 구축시 현실적인 접근법
    2. 모델자체가 어려워 프로텍트 관리가 힘들 수 있다.
    3. 예산과 시간낭비라는 큰 어려움에 부딪칠수 있다.
    4. 많은 고객을 상대로하는 상없제품에 적용하기 힘들다.


문) 반복(iterative) & 점진(incrementation) 모델
답)
  1. 정의
    • Miller의 법칙에 의해 가해진 제약을 바탕으로 인간이 처리할 수 있는 정뵤량에 대한 단계적 정제를 사용하여 현재 가장 중요한 것에 집중하고, 그렇지 않은것은 연기한다. 중요한것을 모두 처리하면 연기한 정보들에 대해 집중과 연기를 반복적으로 적용한다.
  2. 진행단계
  3. 장점
    1. 중요한 정보를 먼저하기 때문에 risk는 초기에 발견된다.
    2. 아키텍처가 견고해진다.
    3. 소프트웨어 형상환리 기회가 많이 제공된다.





저작자 표시 비영리 동일 조건 변경 허락
Posted by 푸른_바람
문) Object,  Class,  Inheritance(상속), concealment(은닉), polymorphism(다형성), encapsulation(캡슐화)

Object


  1. 클래스로 이루어져 규정되어 구현된 결과(인스턴스).
  2. 저장공간에 할당된 공간과 값을 의미한다.
  3. 실세계에서 어떤사람이 집에서 살기를 원할때 그 집의 청사진이나 축소모형 따위는 필요없고, 필요한것은 설계에 맞는 집이다. 이 유추에서 청사진을 클래스, 실제집은 객체이다.


Class
  1. 공통성질을 가진 종류의 집합.
  2. 객체지향 프로그래밍에서 객체내에 있는 메소드와 변수를 정의하는 틀.
    1. 클래스는 전부 혹은 일부를 그 클래스 특성으로부터 상속 받는 서브클래스를 가질 수 있다.
    2. 스브클래스는 자신만의 메소드와 변수를 정의할 수 있다.
    3. 클래스와 서브클래스 간의 구조를 "클래스 계층(hierarchy)"라 한다.



inheritance

  1. 클래스의 함수성 즉 행위가 분명히 정의된다면, 클래스의 재사용이 확실히 보장된다.
  2. 재사용성을 위한 "분명한 정의" 원칙
    1. 매서드는 더 이상 나누어 질 수 없는 단일 기능만 실행할 수 있도록 응집된 최소의 단위함수로서 서로 밀접하게 관계되는 함수그룹을 수행한다.
    2. 메서드는 재사용이 가능하도록 최소화되어야 한다.
    3. 유사한 메서드는 이름부터 매개변수, 자료형, 반환값, 조건에 이르기까지 동일한 구조를 갖도록 일관성이 있어야 한다,
    4. 알고리즈은 자체적으로 종결되어야 한다,
    5. 메서드는 모든 조건에서 일어날 수 있는 일치된 적용범위를 가져야 한다.
    6. 메서드는 추후에 확정될 수 있도록 매개변수면, 조건, 구문등이 일반화되어야 한다.
    7. 메서드는 외부참조 내지는 전역변수의 사용을 되도록 피해야 한다.
    8. 메서드의 행위는 쉽게 변경할 수 있도록 특정한 구문에 종속되지 않아야 한다.


concealment
  1. OOP (Object Oriented Programming) 3원칙.
  2. 프로그램은 처리 활동을 은폐하여 정의되어진 인터페이스에 의해서만 전달.
  3. 객체는 자신의 상태를 기억하기위한 속성과 이를 관리하는 동작을 정의한다. 이중 일부만 사용할수있게 하는것을 정보은폐라고한다.


polymorphism

  1. 객체지향에서 다형성은 매개변수(=아규먼트)등을 하나의 메서드로 선언하여 사용해 매개변수에 리턴값이 변하는 혁식.
  2. 오버로드, 오버로딩의 으해 구현되는 기법으로 오버로드는 객체안에 함수명은 같지만 매개변수 타입과 개수가 다른것을 말한다.
    오버라이딩은 함수 이름과 매개변수타입이 완전 일치하는것을 말한다.


encapsulation
  1. 관련있는 데이터와 코드를 한 울타리 안으로 모으는 것.
  2. 하나의 클래스 안에 필듣르과 메소드들을 정의한다. 단 클래스의 특성과 관련되어야 한다.
  3. 캡슐화를 함으로서 정보은익이 이루어진다.





저작자 표시 비영리 동일 조건 변경 허락
Posted by 푸른_바람
컴포넌트(Component)와 서비스(Service)

컴포넌트

  1. 더 큰 프로그램이나 구조물에서 식별 가능한 "일 부분".
  2. 특정 기능이나 관련된 기능들의 조합을 제공.
  3. 프로그래밍 설계에서, 시스템은 모듈로 구성된 컴포넌트로 나뉜다.



서비스

  1. 물질적 재화 이외의 모든 생산과 소비에 관련한 경제활동
  2. 서비스로의 소프트웨어.
    1. SaaS(Software as a Service)는 ASP의 확장 개념
    2. 네트워크 기반으로 접근/관리되는 상업적으로 사용 가능한 소프트웨어
    3. 각 고객 사이트가 아닌 중앙에서 활동을 관리하고, 고객을 웹을 통해 애플리케이션에 접근하도록 함.
    4. 일대다 모델(Single instance, multi-tenant 아키텍처)에 가깝다.
    5. 중앙화된 기능 업데이트로 클라이언트의 업그레이드 다운로드의 필요가 없음.


차이

  1. 서비스는 기능전체가 완성된 형태로 구성되는 포괄적인 전체영역과 전체중 하나의 기능 요소로 구성된 컴포넌트로 나뉘어 진다.
  2. 컴포넌트는 입력과 출력을 제공할수 있는 하나이상의 기능을 가지는 소프트웨어 결과물이나 객체를 말하며, 하나이상의 기능을 가진 컴포넌트가 입력을 받아 출력을 제공하는 행위를 서비스라고 한다.










저작자 표시 비영리 동일 조건 변경 허락
Posted by 푸른_바람
플랫폼

- 하나의 플랫폼은 소프트웨어인 운영체제와 컴퓨터시스템의 보조 프로그램 그리고  하드웨어인 마이크로 프로세스와, 마이크로 칩으로 구성된다.

프레임워크

- 문제를 해결(소프트웨어를 개발, 구축)하는 방법을 체계적으로 정리한 정형화된 기본틀
저작자 표시 비영리 동일 조건 변경 허락
Posted by 푸른_바람
TAG PE
정보공학방법론






저작자 표시 비영리 동일 조건 변경 허락
Posted by 푸른_바람
이전버튼 1 2 이전버튼