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

문) 마르미III
답)
  1. 한국형 CBD방법론 마르미III
    가. 마르미III(Magic and Robust Methodology Integrated)의 정의
      - 국내에서 널리 사용중이나 체계화 되지 못한 개념,방법,기법,절차 경험적 지식
        을 정립하여 대한민국의 개발여건에 맞게 만든 CBD방법론
    나. 특징 및 등장배경
      - 소프트웨어 컴포넌트의 조립을 통한 정보시스템 개발의 적시성 제공
      - 컴포넌트 기반 시스템 개발방법론의 자체 개발통한 외국 방법론의 수입억제, 경쟁
        력 확보, 대외 신인도 향상
  2. 마르미III의 개발 절차 및 방법론간 비교
    가. 개발절차
요구사항분석        -> 아키텍처 정의 -> 아키텍처프로토타이핑 -> 테스트 및 전환계획
유즈케이스 모형정제| SW아키텍처 정의  | 아키텍처프로토타입계획 | 테스트계획
UI설계             | 설계전략정의     | 아키텍처프로토타입개발 | 전환 계획
객체모형 작성      | 비지니스컴포넌트설계 | 아키텍처프로토타입평가|
                   | 컴포넌트 획득/데이터모형작성|
    나. CBD 개발방법론 비교
구분  | RUP                        | Catalysis               |  마르미III
정의 | 대규모프로젝트의 포괄적 F/W | UML표기법개발 CBD방법론 | 한국형 CBD기반 표준방법론
목적 | 계획범위내에서 고품질SW개발 | 개발적 분산시스템 모델링 및 구축 | 체계적컴포넌트 개발 관리절차 확립
재사용 | SW 컴포넌트               | 모든 산출물             | 모든산출물(재사용컴포넌트)
모델링 | UML                       | UML기반 다소 변경       | UML, PERT/CPM, 간트차트
  3. 마르미III의 기대효과 및 전망
    가. 국내 개발진에 의한 기술 확보 및 축적이 가능
    나. 개발현장에서 활용되고 있는 경험적 지식의 체계화
    다. 완벽한 한글화를 통한 사용자 편리성 및 커뮤니케이션 활성화로 향후 정부기관 및
        외국어에 익숙치 않은 고객사로 확대 사용 예측됨."끝"

문) 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 : 기능성,편의성,신뢰성,성능, 지원성
     나. "+" : 구현성, 연계성, 운영성, 합법성. "끝".

문) UML과 JAVA코드변환
답)
  1. UML의 개요
    가. UML(Unified Modeling Language)의 정의
      - OMG에서 객체모델링기술과 방법론을 표기한 표준화 모델링 언어로서 모델링을 위한 Notation을 말함
    나. UML의 구성요소
      1) 사물(Things) : 추상적 개념으로서 모델구성의 기본요소
      2) 관계(Relations) : 사물간의 의미있는 연결, 객체들 간 대화경로, 데이터 흐름아닌 메시지통로, 의존,연관,일반,실체화
      3) 도식(Diagram) : 사물과 관계를 각종 도식으로 표기
  2. UML의 4가지관계와 JAVA코드변환
    가. UML의 4가지관계
      - 의존관계 : 독립사물의 변화가 종속사물에 영향끼침
      - 연관관계 : Has-a 관계, 모델요소간 링크를 설명하는 구조적관계
      - 일반화관계 : 상속(Inheritance)의 관계, 한클래스가 다른 클래스를 포함
      - 실체화관계 : 구현(Implement)의 관계, 필요한 인터페이스를 구현
    나. JAVA 코드변환
      1) 의존관계  =>   코드변환        
         Diagram  class A {              
                  public void getB(B pB) {
                  {.....}
                  }
                  class B {.....}
      2) 연관관계  =>   코드변환        
         Diagram  class A {
                   public B[] B;}
                  class B {
                   public A a;}
      3) 일반화관계 =>   코드변환
         Diagram  class A{}
                  class B extends A {...}
      4) 실체화관계 =>  코드변환
         Diagram  interface A{}
                  class B implements A {..}
  3. UML의 JAVA 변환시 고려사항
    가. 사용자 : Business Process, 요구사항 구체적 도출
    나. 분석자 : 코드변환의 용이성 위해 모델링 용어 통일, 표기법 점검
    다. 개발자 : CASE Tool 기반으로 이해쉽도록 주석 활용코딩, 임의로 생성 탬플릿
        변경없도록 유의."끝"

공부하기 시작한지 2주가 되어간다.
누군가 4-5번만쓰니 암기가 된다기에 열심히 4번썼는데, 반도 못외웠다.
손만 아프고...100분동안 10문제를 써야 되는데, 미리 써놓은걸 베끼는 데도 평균 15분이다.
밤에 잠만 안잔다고 장땡이 아니라 뭔가 요령이 있어야 되는데...
5년전에만 시작했어도 머리가 팽팽돌텐데...
이따위의 짜증이 밀려온다.ㅎㅎㅎ