건희아범의 지속가능한 삽질

문) CBD방법론
답)
  1. 컴포넌트 재사용을 통한 생산성 향상 CBD방법론
    가. CBD(Component Based Development)방법론의 정의
      - 컴포넌트의 개발 및 기존 컴포넌트의 재사용을 통해 조립하여 소프트웨어를
        개발하는 방법론
    나. 특징
      - 정의된 인터페이스 단위의 조립을 통한 개발(Black-Box framework)
      - 아키텍처 중심 재사용 개발 방법론 : 기반 아키텍처 없이는 공용컴포넌트 개발 불가
      - 반복점진적 개발프로세스 제공 : 일련의 반복을 통해 개별위험 식별/제거
  2. CBD방법론의 특성
    가. CBD방법론의 장점
      - 생산성 : 부품조립을 통해 SW개발기간 단축, Plug&Play
      - 변경용이성 : 요구사항 수용에 신속/안정적 변경지원, Time To Market
      - 재사용성 : 바이너리 기반의 재사용 및 컴포넌트 대체 용이
      - 관리용이성 : 독립적인 컴포넌트 단위로 복잡성 최소화, 장애의 Locality
      - 기술집약성 : 기술숙련에 대한 검증, 아키텍처, 프레임워크, 분산 기술 등
    나. CBD 방법론의 종류
구분  |  RUP                            | Catalysis                 | 마르미III       |
정의  | 대규모프로젝트의 포괄적 F/W     | UML표기법개발 CBD방법론   | 한국형 CBD기반 표준방법론|
목적  | 계획/범위 내에서 고품질 SW/개발 | 개방적 분산시스템 모델링 및 구축 | 체계적 컴포넌트 개발관리절차 확립|
재사용| SW컴포넌트                      | 모든산출물(F/W)           | 모든산출물(재사용컴포넌트)
모델링| UML                             | UML기반 다소 변경         | UML, PERT/CPM, 간트차트
  3. 향후 전망
    가.컴포넌트를 넘어 아키텍처 기반의 재사용(MDA/MDD), 제품라인(Product Line)에 의한
       재사용으로 발전예상
    나. Business Architecture, SW Architecture등의 영역별 세분화, 전문화 진행
    3. Web서비스의 출현 이후 비지니스 컴포넌트의 진화예상. "끝"

----추가 -----------
    *. 컴포넌트 구조와 객체지향 모듈과의 차이점
구분                  객체지향모듈                    컴포넌트
재사용방식/플랫폼 | 주로소스기반/동일Compiler기반 | Binary code기반/이종Compiler수용
상속성/접근방법   | 상속허용/객체지향언어 | 상속불가/모든언어대상
종속성/서비스제공 | 구현기술종속/타모듈결합필요 | 구현기술에 독립적/독자적 가능

문) 요구공학
답)
  1. 요구사항 검증을 통한 SW위기의 해결 요구공학
    가. 요구공학(Requirement Engineering) 의 정의
      - 초기 개발 요구사항 및 이후 상세요구사항들이 설계와 구현 단계에서 제대로
        지켜지고 있는지 검증하는 기법
    나. 요구사항의 특성
      1) 정확성 : 명확화된 요구사항이 실제 구현시 필요한 것인지 알수 있게 정확해야함
      2) 명확성 : 여러가지가 아니라 단 한가지로 해석되어야 함, 프로토타이핑으로 해결가능
      3) 완전성 : 시스템 구현에 필요한 모든 것이 표현되어야 함
      4) 일관성 : 요구사항들 간의 충돌이 없어야 함
      5) 수정용이성 : 구조와 스타일에 일관성유지, 요구사항 변경 용이
      6) 추적성 : 요구사항들간 유기적 연결, 산출물이 각 단계와 mapping 되어야 함.
                  RTM(Requirements Traceability Matrix) - 순방향, 역방향 검색
  2. 요구공학 구성 및 절차
    가. 요구공학 구성
      - 도구 : 요구사항 요청, 영향분석, 변경수행, 배포 등의 자동화도구
      - 프로세스 : 요구사항 관리를 수행하기 위한 절차와 방법
      - 방법론 : 요구사항 추출,분석,정의,검증,관리의 각단계룰 정의한 정형화된 방법
    나. 요구공학 절차
      1) 추출 : 문제를 이해하고, 요구사항 추출
      2) 분석 : 추출된 요구사항을 분석하여 요구사항을 구조화하고, 각종 대안을 결정
      3) 정의 : 시스템이 무엇을 해야하는지를 기술, 분석된 요구사항을 명세화(명확성,
           완전성,검증가능성,일관성,수정용이성, 추적가능성,개발후 이용성)
      4) 검증 : 문제를 기술하고, 상이부분의 일치여부를 확인, (Review,Work-Through,Inspection)
      5) 관리 : 요구사항에 대한 최종결정 및 Baseline관리, 변경통제 및 확인기능
  3. 정형명세 기법과 비정형 명세기법 비교
    구분 |            정형명세      |        비정형명세
    -------------------------------------------------------
    기법 |      수학적기반/모델기반 |  상태/기능/객체중심
    종류 |      Larch,OBJ/Z,UDM,CSP |  FISM/Decision Table/SADT
    장점 | 시스템요구특성정확,명세간결,명세/구현의 일치성| 명세작성/이해용이, 의사전달방법 다양성
    단점 | 수학적이해, 이해관계자 부담| 불충분한 명세 가능, 모호성

------- 추가분--------
 **. 요구사항 분석의 문제점과 해결방안
    가. 요구사항 검증을 위한 V&V : 프로젝트 SDLC개발단계의 Verification(검증)과
        Test 단계의 Validation을 통한 검증 필요
    나. 요구사항 해결책에 대한 비문서화된 경험을 형식화한 Repository 관리, 업무 전문가
        양성계획 수립 및 프로젝트 참여로 제품품질 향상 기여."끝"

    *. 프레임워크 개요도 - 구성요소에 해당내용이 설명되어 1교시에서는 제외
        (추출/분석/정의/검증/관리 해당 구조도 첨부)

    *. 요구사항 분석이 어려운 이유
      1) 문제영역에 대한 명확한 이해부족 : 개발자의 도메인 이해부족으로 요구사항
         이 불명확하게 작성
      2) 참여자 사이의 이해문제 : 참여자들의 Role에 따라 서로다른 관점으로
         표현하고 분석함으로써, 같은 내용에 대해 충돌 또는 불명확성 발생
      3) 의사소통에 대한 문제 : 공동작업 중 충분한 의견교환이 없어 문제 발생
      4) 요구사항의변경 : 사용자의 변경요구, 습득된 지식 및 환경변화에 따른 변경

    * 요구사항 명세시 고려사항
      1) 기술적 내용과 제약조건은 언급하지 않는다. (외부 Entity 관점)
      2) 명세화 이전 자료에 기반두어 작성한다. - RFP, 제안서, 상위 요구사항
      3) 비기능적 요구사항도 모두 포함 작성
      4) 사용자별 중요도 및 난이도 고려하여 우선순위 정의.
         - 중요도 및 난이도는 어떤 기준으로 산정하는가?? 고민해볼것.
         - 중요도 난이도 구한 후에는 우선순위는 무엇으로 정하는가. - 중요도/난이도 차트?

    * 요구사항 명세서의 이해관계자별 목적
      1) 사용자측면 : 요구사항정의, 정의된 요구사항의 적용 및 추적성, 의사소통,
            프로젝트 품질, 납기기준 (특징:친숙한 용어사용베이스라인 제공, 연결)
      2) 개발자측면 : 사용자와의 의사소통 창구역할 수행(JRP), 프로젝트 목적에
            맞는 설계,개발 진행 (특징:정형화된 형식, 정량화,측정가능한 가치제공)
      3) PM측면 : 프로젝트 관리기준(일정, 비용, 품질), 프로젝트 범위에 대한 기준
           및 수용가능성 (특징:요구사항추적매트릭스-요구사항 관리)

  *. 요구사항 유형 분류를 위한 FURPS+ 모델
     가. FURPS : 기능성,편의성,신뢰성,성능, 지원성
     나. "+" : 구현성, 연계성, 운영성, 합법성. "끝".

쌍용차 해직노동자가 또 자살을 했단다.
벌써 14명째라던가..
또 자살이라는 의미는 우리가 트는 저녁 뉴스에는 거의 나오지 않는다는 얘기렸다.

우리의 MBN(MB님)은 G20세대가 나타났다며,
세계에 어깨를 나란히 하는 대한민국, 국격이 상승되었다는데,
이렇게 좋은나라에서 왜 이렇게 못살겠다고 죽는지 모르겠다.

무상급식관련해서도 말이 많다. 솔직히 무상급식은 아니다.
세상에 공짜가 어디에 있나? 다 우리가 내는 세금이다.
하지만 적어도 내가 내는 세금은 애들 먹이는 급식에 쓰여졌으면 좋겠다.
그 밥을 먹고, 그 아이들이 열심히 미래에 대한 꿈을 키웠으면 좋겠다.
(하지만, 한반도 대운하에 그 돈이 쓰여지길 원치는 않는다.
한반도 대운하에 미래에 대한 꿈이 있는 건 MBN 뿐인것 같으니까..)

회사에서 퇴직을 당해도 적어도 죽음을 생각하지는 않을 정도의 돈을 받는것,
어린이들이 학교에서 돈내지 않고 밥먹을 수 있는것,
아이가 많이 아프다고 해도, 치료비로 집 날리지 않고 이혼도 하지 않는 것.
이런거 하면 나라 망하는걸까..

내가 너무 많은 것을 기대하고 있나...
하긴 그래서 이렇게 지속가능한 삽질을 위해 열공중인지도 모른다.

거짓말로 쓴것, 애플리케이션 프레임워크라는 주제를 놓고
아는것과 검색한 것을 짜집기 하다가 포기함.
그냥 답안 복사를 해야하나..
----------------
문) 애플리케이션 프레임워크
답)
 1. 애플리케이션 프레임워크 개요
   가. 애플케이션프레임워크(Application Framework)의 정의
      -  기본적인 아키텍처와 공통 모듈을 제공하면서
         별도의 추가 모듈 구현이 가능한 컴포넌트 및 툴들의 집합
   나. 애플리케이션 프레임워크의 특징
      - 확장성 (extensibility) : 프레임워크의 기본기능에 선택적인 overriding을
        통해 기능을 확장 할 수 있다.
      - 수정불가코드 (non-modifiable framework code) : 프레임워크의 코드는
        기본적으로 변동될수 없다.

  2. 애플리케이션 프레임워크의 구조
   가. 애플리케이션 프레임워크의 구조
      - Run Tier, JobTier, Application Tier, Data Tier : Spring
      - 채널, 비지니스, 데이터 Tier : 프로프레임
      - 개발환경, 실행환경, 관리환경, 운영환경
  

문) ISP
답)
  1. ISP의 개요
    가. ISP(Information Strategy Plan)의 정의
      - 기업의목표달성을 위해 최적의 정보화를 추진/중장기 전략 계획
      - 경영/IT 환경 및 현행/개선 업무 분석, 개선과제 도출, 이행계획 수립, 중장
        기 IT마스터플랜 수립으로 구성
    나. 관련 경영기법 비교
      구분  |       ISP          |          BPR          |           EA        |
      목적  | 정보시스템방향설정 | IT활용/업무프로세스개선| 비지니스와 IT전략  |
      중심  | 데이터 중심        | 프로세스 중심         | Architecture 중심   |
      결과  | 정보화중장기 마스터플랜| 조직/제도/문화개선| 정보시스템구조 청사진(BA/AA/DA/TA, EA컨버젼스)|
  2. ISP추진절차도 및 분석기법
    가. ISP 추진절차도
      1) 기업환경분석 . 경영환경분석 -> 기업내/외부환경분석:기회위협요소파악
                                     -> 내부역량/비전/전략분석:강점/약점파악
                      . 정보환경분석 -> 정보기술트랜드, 적용가능성, 정보화요구사항(CIR)도출
      2) 현황분석 : . Biz Process분석 -> 현행업무기술서, 조직/업무 상관도, 프로세스모형
                       업무체계문제점, 개선사항도출(BPR)
                    . 정보시스템분석 -> 현행정보시스템 자원/운영현황분석, 문제점/개선 도출
                       요구사항정리, 선진사벤치마킹/차이 분석, 개선방향설정, 만족도조사
      3) 신기업모델정립 : 신비지니스프로세스 정의->프로세스 모형/Biz프로세스정립,개선방안수립
                          정보화전략수립->정보화목표/추진전략/정보화추진과제요건
                          시스템구조정의->프로세스모형,정보자원관리방안
                          관리체계수립->정보화통합조직/관리체계정립,IT표준,투자효과지표설정
      4) 실행계획수립 : 실행전략수립, 추진체제정의, 일정수립, 단계별 투자계획 수립
    나. 경영환경분석을 위한 분석기법
      - 5-Force : 잠재적경쟁자, 대체상품, 기존기업간 경쟁, 공급자, 구매자(경쟁요인) - 기업외부환경
      - Value Chain : 주업무(사업활동), 부업무(지원활동)을 구분 분석
      - 7S Analysis 분석 : 기업조직의 변화대처 능력에 영향을 끼치는 7가지 - 내부역량
      - SWOT 분석 : 기업내외부 환경을 기회/위협/강점/약점으로 분류 (CSF->CIR도출)
        (SWOT 분석표 첨부)
  3. ISP 활용방안과 기대효과
    가. 활용방안
      - 경영측면 : 경영비전, 목표전략에 대한 공유, 사업방안/업무활도엥 대한 정의수립,
        과제도출, 업무개선에 IT활용기회 모색
      - IT측면 : 정보화마인드 향상, 정보화추진 지침서, 투자효율성 향상, 정보화 전략과
        IT아키텍처 수립을 위한 ISP와 EA동시추진
    나. 기대효과
      - 경영관점 : 비전/전략/목표 및 과제도출, 사업방안 명확화, 업무효율개선, IT를
        통한 신규 수익 창출
      - IT관점 : 정보시스템 투자효율성 향상,정정보기반 통합관리 및 운영."끝"

    * ISP 구축방법
      1) 환경분석 : 경영환경분석 -> 기업내/외부환경분석 : 기회/위협요소파악
                                 -> 내부역량/비전/전략분석 : 강점/약점 도출
                    정보환경분석 -> 정보기술트랜드, 적용가능성, 정보화요구사항(CIR)도출
      2) 현황분석 : Biz프로세스 분석 -> 현행업무기술서, 조직/업무 상관도, 프로세스모형,
         (AS-IS)             업무체계 문제점, 개선사항도출(BPR)
                    정보시스템 분석 -> 현행정보시스템, 자원/운영 현황분석, 문제점/개선도출
                             요구사항정리, 선진사 벤치마킹/차이분석, 개선방향 설정, 만족도 조사
      3) 신기업모형정립 :
         (TO-BE)    신비지니스 프로세스 정의 -> 프로세스 모형/Biz프로세스 정립, 개선방안 수립
                    정보화 전략 수립 -> 정보화 목표, 추진전략, 정보화추진과제 요건
                    시스템구조정의->프로세스 모형, 정보자원 관리 방안
                    관리체계 수립->정보화통합조직/관리체계 정립, IT표준, 투자효과지표 설정
      4) 실행계획 수립 : 실행전략수립, 추진체제정의, 일정수립, 단계별 투자계획수립
      (5-Force, 7S Analysis 구성도 확인할것)


*
ISP 추진절차도
       [기업환경분석] ->|[업무프로세스분석] ---> [요구정의개선과제도출]->[GAP분석및]|->
       [IT환경분석]   ->|[정보시스템분석]  --┘    [벤치마킹] ---------┘[개선방향 ]|
      |<-환경분석     ->|<- 현황분석(AS-IS)                                       ->|

      ->|[.신비지니스프로세스정의]| -> [실행계획수립]
        |[.정보화전략수립        ]|
        |[.시스템구조정의        ]|
        |[.관리체계수립          ]|
        |<-  미래모형정립(TO-BE)->|

문) BRE
답)
  1. 신속한 Time to Market 실현을 위한 BRE의 이해
    가. BRE(Business Rule Engine)의 정의
      - 비지니스 유연성과 경쟁력 강화를 위하여 비지니스룰을 정리하고 자동화를
        수행할 수 있는 BPM의 핵심요소
    나. BRE의 주요기능
      - GUI기반 개발도구 : 설계,개발,시험,검증,배포의 전과정 처리가능
      - Rule 표현언어 : 비지니스 Rule 표현언어 제공 (SRL:Structured Rule Language)
      - 지원도구제공 : 디버깅, 분석, Rule 추적도구 제공
      - 자동 Rule분석 : Rule 타장성, 일관성, 무결성 테스트 및 자동보고서 생성
      - Rule 시뮬레이션 지원 : Question Set에 의한 질의 및 Rule 처리결과 출력
  2. BRE 구성요소 및 비지니스 프로세스 개선기술 비교
    가. BRE의 구성요소
      - Rule Base : 기업내 모든 비지니스 룰에 대한 저장소
      - Rule Engine : 비지니스 룰 검색 및 처리기능 수행
      - 추론 알고리즘 : 최적화 된 업무처리를 위한 알고리즘
    나. 비지니스 프로세스 개선기술 비교
       |        | BPM                           | BAM             | BRE         |
       |특성    | 핵심프로세스개선              | 실시간모니터링  | 실시간Rule관리|
       |정보유형| 프로세스 모델                 | Activity상태/KPI| 비지니스룰  |
   |비지니스목적|고객지향EndToEnd프로세스 통합, 관리|민첩성위험파악|비지니스융통성,적시성|
  3. BRE기대효과 및 활용분야
    가. 비지니스 측면 : 다변화 비지니스 환경 신속한 대처 및 대응력 향상
    나. IT측면 : 생산성 향상 및 비용절감
    다. 자금세탁방지 등 각종금융사기방지, 보험 개발 및 여신관리, 방카슈랑스."끝"

  * 추가활용분야
    가. 금융상품매매 : 우수고객별 이자율 계산 Rule 정의 이자율은 Dynamic하게 적용
    나. TMS : 위험관리시스템에서 위험룰셋을 모든 위험관리시스템에 전파
    다. e-CRM : 개인화 서비스를 위한 Click&Stream 기반의 One Stop Service
    라. u-교통 : GPS기반의 사용자 운전패턴분석을 통한 10대 위험운전행위 분석