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

문) 마르미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 기반으로 이해쉽도록 주석 활용코딩, 임의로 생성 탬플릿
        변경없도록 유의."끝"