컴포넌트 기반 개발(CBD; Component Based Development) 방법론

• 컴포넌트 기반 개발 개요
  
  • 컴포넌트 기반 개발 프로세스
    

    
    

  • 컴포넌트 기반 개발 프로세스의 특징
    
    • CD는 소프트웨어 개발에 필요한 부품을 만드는 것
      
      • 비즈니스 영역에 대한 이해와 기술 아키텍처에 대한 이해가 선행되어야 함
        
      • 재사용 목적상 해당 도메인에 대한 분석이 핵심사항
        
      • 비즈니스 컴포넌트와 소프트웨어 컴포넌트 병행 개발
        
    • CBD는 컴포넌트들을 조립하여 소프트웨어를 개발
      
      • 반복적 개발 프로세스를 적용하여 혁신적인 생산성 향상
        

         
         

• CBD 방법론의 개요
  
  • CBD 방법론의 정의
    
    • 재사용이 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 애플리케이션 개발 생산성과 품질을 높이고, 시스템 유지 보수 비용을 최소화할 수 있는 개발 방법 프로세스
      
    • 컴포넌트 단위의 개발 및 조립을 통하여 정보시스템의 신속한 구축, 변경, 확장의 용이성과 타 시스템과의 호환성을 달성하고자 하는 소프트웨어 공학 프로세스, 방법론 및 기술의 총체적 개념
      
  • CBD 방법론의 특징
    
    • 컴포넌트 기반 개발
      
    • 표준화된 UML을 통한 프로세스 제공
      
    • 반복 점진적 개발 프로세스 제공
      
    • 표준화된 산출물 작성 및 컴포넌트 제작 기법을 통한 재사용성 향상
      

       
       

• CBD 방법론의 공정 구성 및 Iteration 대책
  
  • CBD 방법론의 공정 구성
    

요구분석	분석	설계	개발	구현
AS-IS 모델링 TO-BE 모델링 요구 사항 정의	아키텍처 정의 Use-Case 모델링 UI 프로토타이핑	UI 설계 컴포넌트 정의/설계 DB, 컨버젼, 테스트 설계	코딩 테스트	릴리즈 교육
		N회 반복	N회 반복		N회 반복

 
 

• Iteration 대책
  
  • Iteration 특징
    
    • 프로젝트 수행 중 최소 두 번 이상 수행
      
    • Iteration의 결과물은 독립적으로 완벽히 동작하는 실행 모듈을 포함
      
  • Iteration 계획 수립 시 필수 고려 사항
    
    • 초기 Iteration은 가장 위험도가 높거나 중요하다고 생각되는 업무영역과 검증 혹은 경험이 없는 기술 아키텍처 포함하여 기간은 2개월 이하로 계획
      
    • 첫 Iteration 은 전체 범위의 70~80% 정도를 분석 대상으로 하고, 20/80 Rule을 적용하여 20% 정도의 기능만 실제 구현
      

     
     

• CBD 성공 요인 및 향후 전망
  
  • CBD 성공요인
    
    • CBD 수행을 위한 프로세스를 구성하는 활동들과 역할이 잘 정의되어야 함
      
    • CBD를 위한 컴포넌트 재사용 과정의 자동화 도구가 필요
      
    • 활용 가능한 풍부한 컴포넌트와 카탈로그의 확보 및 저장이 필요
      
    • CBD를 적용하기 위한 조직 차원의 체계적 접근법이 필요
      

       
       

  • CBD 향후 전망
    
    • 비즈니스 아키텍처, 소프트웨어 아키텍처 등의 영역별 세분화 및 전문화 진행(MDA)
      
    • MTS, EJB 컨테이너 등의 미들웨어 발전으로 CBD가 확산되고, UML 및 컴포넌트 기반 소프트웨어 구현 툴(웹 스피어, 웹 로직)의 발전과 함께 CBD촉진
      
    • WEB 서비스의 출현 이후 비즈니스 컴포넌트의 진화 예상
      

객체 지향 방법론

1. 객체 지향 방법론의 개요

1. 정의

· 프로그램을 객체와 객체 간의 인터페이스 형태로 구성하기 위하여 문제 영역에서 객체, 클래스 및 이들 간의 관계를 식별하여 설계 모델로 변환하는 방법론

· 복잡한 메커니즘의 현실 세계를 사람이 이해하는 방식으로 시스템에 적용시키는 개념으로, 이를 위해 객체, 클래스, 메시지를 기본 모형으로 제시

2. 필요성

· 객체 지향 시스템을 개발하기 위한 방법론이 필요

· 소프트웨어 위기와 낮은 생산성의 극복이 필요

· 반복적인 유사 프로그램의 개발로 인한 오버헤드 발생의 절감을 위해 필요

3. 특징

· 대부분 기존의 폭포수 모델을 근간으로 함

· 분석, 설계, 구현의 벽이 없고 일관성, 추적성, 재사용성, 유지보수성 향상

· 모형의 적합성, 즉 현실 세계 및 인간의 사고 방식과 유사

2. 객체 지향 방법론의 절차 및 단계별 작업 항목

1. 절차

2. 단계별 작업 항목

단계	작업 항목	설명
객체 지향 분석	객체 모델링	· 시스템 정적 구조 포착 · 추상화, 분류화,일반화, 집단화
	동적 모델링	· 시간의 흐름에 따라 객체 사이의 변화를 조사 · 상태, 사건, 동작
	기능 모델링	· 입력에 대한 처리 결과에 대한 확인
객체 지향 설계	시스템 설계	· 시스템 구조를 서브 시스템으로 분해 · 성능 최적화 방안, 자원 분배 방안
	객체 설계	· 상세 내역을 모형으로 개발의 상세화 · 구체적 자료구조와 알고리즘 구현
객체 지향 구현	객체 지행 언어(객체,클래스)로 상속 지원	· C++, JAVA

o 대표적인 객체 지향 방법론의 종류

· Rumbaugh의 OMT(Object Modeling Technique)

1. 특징

· 실세계에 대한 모형화를 추상화, 캡슐화, 모듈화, 계층화를 통해 수행

· 객체 지향 분석, 객체 지향 설계 및 구현 단계로 구성

· 분석의 강점(객체 모형, 동적 모형, 기능 모형)

2. 객체 지향 분석

· 실세계를 이해하기 위한 모형화 작업

구분	내용	산출물
객체모형	시스템의 정적 구조 파악(객체 식별, 관계 정의, 클래스의 속성(Attribute)과 연산 기능 정의)	객체도(Object Diagram)
동적모형	동시에 활동하는 객체들의 제어 흐름, 상호 반응 및 연산 순서를 표현	상태도(State Diagram)
기능모형	시스템 내에서 데이터 값이 변하는 과정을 표현	자료 흐름도(DFD)

o 객체 지향 설계

· 실세계의 문제 영역에 대한 표현을 소프트웨어로 된 해결 영역으로 사상

구분	내용
시스템 설계	· 전체 시스템의 구조 결정, 시스템을 서브 시스템으로 분해 · 동시성, 프로세서와 작업의 관계, 데이터 관리 등을 결정
객체 설계	· 객체 모형의 구체화 작업 · 자료구조와 알고리즘을 정의

· 구현

· 세부 객체 모형, 동적 모형, 기능 모형 및 기타 문서를 사용하여 시스템을 구현

· 객체 지향 언어를 사용하면 가장 용이하지만 비객체 지향 언어를 사용하여 구현도 가능

2. Booch의 OOD(Object Orient Design)

1. 특징 : 설계만 존재

2. 분석 : 정적 모델과 동적 모델로 표현

정적모델	· 논리적 관점을 표현(클래스도, 객체도) · 물리적 관점을 표현(구조도, 프로세스 구조도)
동적모델	· 실세계의 사건 발생에 의해 동작되어야 할 일들을 표현(상태도, 타이밍도)

3. 개발 프로세스

클래스와 객체 식별	· 문제 영역으로 클래스와 객체를 식별 · 객체 사이의 행위 메커니즘을 나타내는 객체도 생성
클래스와 객체 식별	· 객체 사이의 프로토콜을 결정(객체의 생성으로 부터 소멸에 이르기까지의 상태와 사건의 흐름으로 표현)
클래스와 객체의 관계 식별	· 객체의 사용성, 상속성, 관계성을 확립 · 객체의 정적/동적 성질, 메시지 동기화, 실행 타이밍 표현
구현	· 설계 결정을 검토하여 휴리스틱(Heuristic)한 방법으로 클래스를 모듈에 할당하고 프로그램을 프로세서에 할당

o Jacobson의 OOSE(Object Oriented Software Engineering)

· 특징

· 시스템의 변화에 유연성이 있음

· 분석

· 분석 모델은 프로그래밍 언어로 구현하기에는 정형적이지 못함(연산, 인터페이스, 파라미터 등의 정제화 필요)

· Use Case : 시스템과 사용자의 연관성 식별

· Actor : 정의 및 역할 작성 : Use Case Diagram, Use Case Description 작성

3. 설계 및 구현

· 실제 시스템은 구현될 환경에 적합하도록 설계 모델로 변환되며 성능 요구 사항, 실시간 요구 사항과 동시성, H/W, 시스템 S/W, DBMS와 프로그래밍 언어를 고려해야 함

· 객체 지향 설계를 진행하면서 분석 결과들이 시스템 구축에 적합한지 분석 모델을 통해 확인되고, 분석 모델에 대한 수정을 함

o 객체 지향 방법론의 발전 동향

1. 객체 지향 기술의 발전

o 객체 지향 방법론의 동향

· 구축 과정 일부만이 아닌 모델링, 분석, 설계, 구현, 테스트 전 과정에 걸쳐 포괄적으로 적용하는 것이 효과적

· 분산 객체 등을 통해 강력한 분산 환경을 구축하는 데 유용

· 인간의 사고 방식과 유사하고 개발 접근이 쉬워 인공지능이나 신경망 같은 차세대 컴퓨터 산업에 응용 가능

· CBD의 한 경로(Path)인 컴포넌트 개발에 객체 지향 분석, 설계 구현 기법이 사용되고 있음

· 소비자들도 개발(Build) 위주의 소프트웨어가 아닌 구매(Buy) 위주의 소프트웨어 이용 패턴을 가질 수 있음

o 객체지향 방법론의 한계점

· 이진 형태의 파일을 연결하는 표준이 부재하며 각 객체는 동일 컴파일러를 사용해야 함.

· 다른 언어간에 객체를 호출하거나 재사용은 거의 불가능함.

· 완성된 이진형태의 객체를 변경하고자 하면 소스 레벨의 어플리케이션을 재컴파일 해야 함

· 개발방법론은 전통적인 SDLC를 따르므로 문제점 인지 및 대응, 문서화에 제약이 따르며 절차적 프로그래밍에 익숙한 개발자에게는 충격이며, 적응력이 많이 떨어짐.

· 개발 수준이 저수준의 추상화개념이므로, 실제로 재사용 가능한 소프트웨어 개발은 기대하기 어려움.

· 개발의 생산성 및 유지보수성을 위한 아키텍쳐 및 표준적용이 어려움

· 대규모 프로젝트에서의 확장성이 떨어짐.

정보 공학 방법론

• 정보 공학 방법론의 개요
  
  • 정의
    
    • 기업 전체 또는 주요 부문을 대상으로 정보시스템 계획 수립, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합.적용하는 데이터 중심 방법론
      
    • 기업에 필요한 정보와 업무를 총체적. 체계적, 효과적으로 파악하여 이를 모형화하고, 빠른 시간 내에 정보시스템으로 발전시키기 위해 필요한 일련의 작업 절차를 자동화한 공학적인 방법론
      
  • 등장 배경
    
    • 환경의 변화
      
      • 비즈니스의 변환 : 컴퓨터 이용의 활성화, 업무 기능 및 데이터의 분업화
        
      • 정보 기술의 발달 : 하드웨어, 네트워크. RDBMS 성능 향상 등
        
    • 구조적 방법론의 한계
      
      • 데이터 모델링 방법의 미흡
        
      • 기업 전반의 거시적 관점의 부족
        
      • 명확한 방법론적 지침의 미흡
        
      • 설계와 코딩을 강조
        

         
         

• 정보 공학 방법론의 필요성 및 특징
  
  • 필요성
    
    • 구조적 방법론의 한계를 극복하기 위해 1990년대 초 James Martin이 제창
      
    • 기업 전체 조망과 데이터 통합의 문제에 새로운 정보시스템 개발 방법이 필요
      
    • 기업 경쟁력 확보, 통합 정보시스템 구축, 정보 이동 등의 요구에 대한 대응 방안
      
  • 특징
    
    • 기업 업무 중심, 자료 중심, 도형 중심의 접근
      
    • 프로젝트 계획, 개발, 운영 단계의 명확한 구조 기반 제시
      

       
       

• 정보 공학 방법론의 추진 원칙 및 추진 단계
  
  • 추진 원칙
    
    • 프로젝트를 관리 가능한 단위로 분할 및 정복
      
    • 데이터와 프로세스의 균형 유지
      
    • 모듈화, 하향식 구현
      
    • 핵심 기술 : 레파지토리, CASE, 4GL 등
      
  • 추진 단계 및 단계별 추진 내역
    
    • 정보 전략 계획(ISP; Information Strategy Planning)
      
      • 경영 전략, 관련 조직, 업무 자료 거시적 분석, 현행 시스템 평가
        
    • 업무 영역 분석(BAA; Business Area Analysis)
      
      • 데이터 모델링 : ERD
        
      • 프로세스 모델링 : PHD(Process Hierarchy Diagram), PDD(Process Dependency Diagram), DFD
        
    • 업무 시스템 설계(BSD; Business System Design)
      
      • 업무 절차 정의, Presentation 설계, 분산 설계
        
    • 시스템 구축(SC; System Construction)
      
      • 데이터베이스 생성과 프로그램 작성
        

     
     

• 정보 공학 방법론의 장.단점
  
  • 장점
    
    • 경쟁 우위 확보의 전략적 기회 식별 및 방안 제공
      
    • 일관성 있고 통일된 정보시스템 구축 가능
      
    • 시스템의 장기적인 진화 및 발전 허용
      
    • 데이터 중심으로 업무 절차 및 환경 변화에 유연
      
  • 단점
    
    • 정보 공학의 효과를 위해 장기간의 시간이 필요
      
    • 소규모의 자동화 요구 사업 영역에는 시간이 오래 걸림
      
    • 특정 사업 영역으로부터 독립된 시스템 개발에는 부적합
      

       
       

• 정보 공학 방법론의 문제점 및 개선 대책
  
  • 문제점
    
    • 구조적 방법의 SDLC를 그대로 이용
      
    • CASE 도구 이용이 쉽지 않음
      
    • 중소 규모 프로젝트의 무리한 적용
      
    • 복잡한 논리 및 다량의 산출물
      
  • 동향 및 개선 대책
    
    • 재사용 패러다임이 대안
      
    • 정보 공학으로 커버하지 못하는 영역의 확산(인터넷, 멀티미디어)
      
    • 기업 시스템 구축은 당분간 유지
      

구조적 방법론

• 구조적 방법론의 개요
  
  • 정의
    
    • 업무 활동 중심의 방법론으로 정형화된 절차 및 도형 중심의 도구를 사용하여 사용자 요구 사항 파악 및 문서화 하는 기법
      
    • 구조적 방법론의 기본적인 뿌리는 구조적 프로그래밍에서 출발하여 설계의 원칙들을 정리한 구조적 설계, 시스템 복잡성을 해결하기 위한 구조적 분석으로 발전
      
  • 등장 배경
    
    • 소프트웨어 위기의 해결책이 필요해짐
      
    • 생산성 향상, 품질 개선, 유지보수성의 향상
      
  • 특징
    
    • 정보와 정보의 구조를 중심으로 분석, 설계, 구현
      
    • 정형화된 분석 절차에 다라 사용자 요구 사항을 파악하고 도형 중심의 다이어그램을 이용하여 문서화
      
    • GOTO 분기 대신 3개의 논리적인 구조(Constructs)인 순차(Squencing), 선택(Selection), 반복(Iteration)을 구성하여 프로그램 흐름의 복잡성을 감소시킴
      
  • 원리
    
    • 추상화(Abstraction) : 현실 세계를 컴퓨터 세계로 전이
      
    • 구조화(Structuring)
      
      • 수평 분할(Horizontal Partitioning)
        
      • 수직 분할(Vertical Partitioning)
        
    • 단계적 상세화(Stepwise Refinement)
      
    • 모듈화(Modulization) : 분할과 정복(Divide & Conquer)
      

     
     

• 구조적 방법론의 구성 요소
  
  • 구조적 분석
    
    • 도형 중심 : DFD, DD, Mini-Spec 이용
      
    • 정형화된 분석 절차, 사용자 요구 파악, 문서화하는 체계적 기법
      
    • 기본원칙 : 분할과 정복, 추상화, 정형화, 구조적 조직화, 하향식 기능 분해
      
  • 구조적 설계
    
    • 소프트웨어 기능과 프로그램 구조, 모듈을 설계하기 위한 전략, 평가 지침, 문서화 도구를 지원하는 체계적 설계 기법
      
    • Flow-Chart, HIPO(Hierarchical Input Process Output) Chart, N-S(Nassi-Schneiderman) Chart, 프로그램 명세서 등 이용
      
      • Mini-Spec[소단위 명세서]
        
        • 자료 흐름도 상의 최하위 처리 절차를 상세하게 기술하는데 사용하는 도구로, 프로세스 명세서라고도 하며, 주로 구조적 언어, 의사 결정표, 의사 결정도를 이용하여 기술
          
      • HIPO Chart
        
        • 시스템을 설계하거나 문서화하기 위해 시스템 실행과정인 입력, 처리, 출력을 계층적으로 기술하는 방법으로, 하향식으로 표현하며, 도표상에 기능 위주로 입력 내용, 처리 방법, 출력 내용이 제시되므로 시스템을 이해하기 쉬워짐
          
          • 가시적 도표 : 도식 목차라고도 하며 전체적인 기능을 보여주는 트리 구조
            
          • 총체적(Overview) 다이어그램 : 주요한 기능을 담당하는 부분의 입력, 처리 출력을 기술
            
          • 세부적(Detail) 다이어그램 : 총체적 다이어그램과 같은 모양으로 하위 수준의 여러 기능을 표시
            
      • N-S Chart
        
        • 구조적 프로그래밍 방법에서 사용되는 논리 표현 기법의 도표로, 상세 처리 과정표현 도구로 사용되며 순서도의 대안으로 제시된 것인데, 하나의 입구와 출구가 있는 프로그램의 구조를 나타내기에 편리함
          
        • 논리적인 구조를 4각형의 박스로 표시하며 연속, 선택, 반복 등의 구조를 사용하고 분기 명령은 허용하지 않음
          
    • 기본 원칙 : 복합 설계의 기본 원칙(결합도, 응집도)
      
  • 구조적 프로그래밍
    
    • Dijkstra에 의해 정형화
      
    • 계층적 형식, 제한된 제어 구조, 작성 순서대로 PGM 실행
      
    • 연속(Sequence)구조
      
    • 선택(Selection or IF-Then-Else) 구조
      
    • 반복(Repetition) 구조
      
  • 구조적 언어
    
    • Structured COBOL, Fortran 77, PL/1, Pascal
      

     
     

• 구조적 방법론의 문제점 및 한계
  
  • 구조적 방법론의 문제점
    
    • 데이터 설계 방법이 결여
      
    • 변환 분석과 거래 분석 측정 기준이 모호
      
    • 응집도, 결합도의 측정 기준이 모호
      
    • 대규모의 복잡한 시스템에 비효율적
      
  • 구조적 방법론의 한계
    
    • 기업 전반의 거시 관점이 부족
      
    • 단위 프로젝트 위주의 접근
      
    • 활동 위주의 접근
      
    • 데이터 모델링 방법이 미흡
      
    • 방법론적인 명확한 지침이 미흡
      
    • 설계와 코딩을 강조
      

소프트웨어 개발 방법론

• 소프트웨어 개발 방법론의 필요성
  
  • 개발 경험 축적 및 재활용을 통한 개발 생산성 향상(작업의 표준화/모듈화)
    
  • 효과적인 프로젝트 관리(수행 공정의 가시화 포함)
    
  • 정형화된 절차와 표준 용어의 제공으로 의사소통 수단 제공
    
  • 각 단계별 검증 및 종결 승인을 통한 일정 수준의 품질 보증
    

     
     

• 소프트웨어 개발 방법론의 구성 요소
  

구성요소		내용	비고
작업절차		프로젝트 수행 시 이루어지는 작업 단계의 체계 단계별 활동 및 활동별 세부 작업 열거, 활동의 순서 명시	단계.활동.작업
작업방법		각 단계별로 수행해야 하는 일 절차/작업 방법(누가, 언제, 무엇을 작업하는지를 기술)	작업방법
산출물		각 단계별로 만들어야 하는 산출물의 목록 및 양식	설계서 등
관리		프로젝트의 진행 기록 계획 수립, 진행 관리, 품질, 외주, 예산, 인력 관리 등 기록	계획서, 실적, 품질보증 등
기법		각 단계별로 작업 수행 시 기술 및 기법의 설명	구조적, 객체지향,ERD, DFD
도구		기법에서 제시된 각 기법별 지원 도구에 대한 구체적인 사용 표준 방법	CASE 등

 
 

• 소프트웨어 개발 방법론의 분류별 비교
  

	구조적 방법론	정보 공학 방법론	객체지향 방법론	CBD 방법론
시기	1970년대	1980년대	1990년대	2000년대
중점	기능중심	자료구조 중심	객체 중심	컴포넌트 중심
장점	Batch 방식 개발에 유용함	자료 중심으로 비교적 안정적임	자연스럽고 유연함 재사용이 용이함	생산성, 품질, 비용, 위험 개선 소프트웨어 위기 극복
단점	기능은 불안정한 요소 데이터가 정보 은닉이 안됨 유지보수, 재사용성이 낮음	애플리케이션은 여전히 기능적 설계 기능의 유지보수, 재사용성이 낮음	전문가 부족 기본적인 소프트웨어 기술이 필요	컴포넌트 유통환경 개선 테스트 환경의 부족 컴포넌트의 평가, 인증 환경의 미흡

 
 

• 소프트웨어 개발 방법론의 분류별 비교
  

	구조적 방법론	정보 공학 방법론	객체지향 방법론	CBD 방법론
시기	1970년대	1980년대	1990년대	2000년대
중점	기능중심	자료구조 중심	객체 중심	컴포넌트 중심
장점	Batch 방식 개발에 유용함	자료 중심으로 비교적 안정적임	자연스럽고 유연함 재사용이 용이함	생산성, 품질, 비용, 위험 개선 소프트웨어 위기 극복
단점	기능은 불안정한 요소 데이터가 정보 은닉이 안됨 유지보수, 재사용성이 낮음	애플리케이션은 여전히 기능적 설계 기능의 유지보수, 재사용성이 낮음	전문가 부족 기본적인 소프트웨어 기술이 필요	컴포넌트 유통환경 개선 테스트 환경의 부족 컴포넌트의 평가, 인증 환경의 미흡

 
 

• 소프트웨어 개발 방법론 적용 시 문제점 및 개선 대책
  
  • 문제점
    
    • 프로젝트 특성을 무시한 특정 방법론 강요
      
    • 형식적인 적용으로 무용지물인 문서만 양산
      
    • 소규모 프로젝트에 방대한 규모의 방법론 적용
      
  • 개선 대책
    
    • 기업 차원의 품질 관리 인식 제고 및 교육과 효과적 활용 도모
      
    • 융통성이 있는 개발 방법론 적용
      
    • CMM, SPICE 등과 연계
      
  • 개발 방법론 선택 기준
    
    • 프로젝트 환경 고려(응용 분야, 시스템 규모, 복잡도, 성격 등)
      
    • 수작업을 최소화하고 자동화되어 있을수록 좋음(시간과 비용)
      
    • 성공을 위한 가이드라인, 함정에 대한 경고 및 실제 활동에서 잊기 쉬운 점들을 검사(통제 수단과 산출물 인도 방식)
      
    • 개발자들의 공감 하에 적절히 이용할 수 있어야 함(방법과 도구 및 경험)
      

   
   

• CMM(Capability Maturity Model)
  
  • CMM은 독립적인 평가를 통해 소프트웨어 개발 조직이 얼마나 정의된 프로세스를 잘 지키는지에 대한 등급을 매기는 모델이며, 이는 프로세스 자체의 품질이나 결과물인 소프트웨어 대한 평가 우선하여 이루어짐
    
  • CMM은 서서히 CMMI(Capability Maturity Model Integration)로 대체됨
    

   
   

• SPICE(Software Process Improvements Capability dEtermination, ISO15504)
  
  • SPICE는 소프트웨어 개발 프로세스의 평가를 위한 프레임워크로서, CMM이나, CMMI 만큼 널리 사용됨
    
  • SPICE를 이용하여 프로세스를 관리하고, 제어하고, 안내하며, 소프트웨어 개발 과정을 모니터링 할 수 있는 모델을 세울 수 있고, 세워진 모델을 이용하여 실제로 소프트웨어 개발 조직이나 개발팀이 소프트웨어 개발을 위해 수행하여야 하는 활동을 측정 할 수 있음
    

MDA(Model Driven Architecture)

• 
  
  MDA: 분산, 객체 지향의 사상
  • 
    
    MDA의 등장 배경
    • IT 환경의 지속적 변화 : 분산 시스템 환경, 다 기종 플랫폼, 다양한 언어와 프로그램, 신규 기술의 등장(XML, 웹 서비스 등)
    • 시스템 통합과 기술 간 상호 운용성 향상 및 재사용성 요구 증대
  • 
    
    MDA의 정의
    • OMG의 MDA 기본사상은 'Separation of Concern'으로 시스템 설계를 비즈니스, 설계, 구현 각각의 전문가 관점별 모델로 분리
    • 
      
      모든 컴포넌트 기술요소의 표준 메타 모델을 정의하고, 이를 기반으로 각 구성 요소를 정의
      
      
• 
  
  OMG의 모델 분류 및 MDA 관련 표준
  • OMG의 모델 분류

구분	설명	비고
비즈니스 모델	업무를 기술하는 영역	금융, 제조 등
PIM(Platform Independent Model)	기술 플랫폼에 독립적으로 기술된 모델	기본모델
PSM(Platform Specific Mode)	기술 플랫폼에 종속적으로 기술된 모델	상세모델

• 
  
  OMG의 MDA 관련 표준
  • 
    
    UML(Unified Modeling Language)
    • OMG에 의해 표준화된 객체 지향 분석 및 설계 표준으로, 구현 환경에 무관하게 표준화된 방법으로 시스템을 모델링
  • 
    
    MOF(Meta Object Facility)
    • 다른 메타 모델을 정의하기 위한 메타-메타 모델로, UML과 CWM은 MOF 기반 메타 모델이고, MOF는 모델 저장소의 역할
  • 
    
    CWM(Common Warehouse Mode)
    • 데이터 웨어하우징 영역에서 DW 아키텍처를 정의한 메타 모델로 데이터 소스, 타깃, 영역간 데이터 변환을 위한 표준 모델을 제시
  • 
    
    XMI(XML Metadata Interchange)
    • MOF 기반 모델을 XML로 매핑하기 위한 표준 사양, 즉 XML 기반 데이터 관리를 위한 표준
    
    

• 
  
  MDA 등장에 따른 소프트웨어 개발 방법의 변화
• 
• 
  
  MDA의 장점 및 기술 발전의 동향
  • 
    
    MDA의 장점
    • 구현 자동화 : 메타 모델을 이용하여 구현 공정의 대부분을 자동화 할 수 있는 구조
    • 재사용성 : 프로젝트 진행 전체 결과를 재사용 가능(분석, 설계, 구현 등)
    • 이식성(Portability) : 구현 환경과 독립적으로 정의되므로 이식성이 증가
  • 
    
    MDA에 기반한 도구 측면 연구 방향
    • 컴포넌트 생성 및 조립 도구 개발 : 비즈니스 모델 생성기, PIM 생성기, PSM 생성기, 컴포넌트 조립 및 생성기, MDA 지향 컴포넌트 시스템 변환기 등
    • 소프트웨어 아키텍처 재사용 시스템 개발 : 영역 아키텍처 및 시스템 아키텍처 생성기, 아키텍처 모델 관리기 등
  • 
    
    MDA에 기반한 산업 적용 측면 연구 방향
    • PIM과 PSM 간의 매핑에 대한 표준과 지원의 불충분으로 적용하기가 어려움
    • 과거 통합 CASE 툴에 대한 환상이라는 우려의 시각이 있음

XP(eXtreme Programming)

• XP : Agile 프로세스의 대표적 개발 기법
  
  • XP의 개념
    
    • 개발자, 관리자, 고객이 조화를 극대화하여 개발 생산성을 높이고자 하는 접근 방법
      
    • 라이프사이클 후반부라도 요구 사항 변경에 적극적이고 긍정적인 대처를 권고하는 역 발상의 소프트웨어 개발 방법
      
  • XP의 출현 배경
    
    • 현재의 소프트웨어 개발 과정에서 자주 발생되고 있는 문제점 극복 대안
      
    • 급변하는 환경에서 소프트웨어를 빨리 개발할 목적으로 설계
      

       
       

• XP의 특징 및 기존 개발 방법의 문제점 해결 방안
  
  • XP의 특징 : 프로젝트의 생산성 및 효과를 향상시키기 위한 핵심 사항 제시
    
    • 4가지 가치(용기, 의사소통, 피드백, 단순성)
      

Core Values	내용
용기	고객의 요구 사항 변화에 능동적인 대처
의사소통	실제 개발자들 사이의 의사소통을 통한 개발 사이클 채택
피드백	빠른 피드백이 기본 원칙으로 해결할 수 있는 일 먼저 처리
단순성	부가적 기능이나 사용되지 않는 구조와 알고리즘 배제

• 12개 실천 항목
  
  • Simple Design : 가장 단순 하며 정확히 작동하는 Design
    
  • Small Design : 고객이 원하는 기능 중심으로 짧은 시간내 릴리즈
    
  • Refactoring : 기능에 변화없이 코드 수정을 통해 디자인 개선
    
  • Pair Programming : 두명이 한 프로그램개발(오류감소, 생산성향상)
    
    • Pair 프로그래밍 - XP에 적용되는 기법으로 두 명의 프로그래머가 동시에 같은 프로그램에 대해 작업하는 것으로서, 한 명이 코드를 작성할 때 다른 한명은 각 코드를 점검하는 방식
      
  • Testing : 테스트주도(TDD), 테스트를 통한 고객검증, 승인
    
  • On-Site Customer : 고객의 팀합류, 의사 결정지원
    
  • Continuous Integration : 지속적인 통합으로 개발의 불일치 최소화
    
  • 메타포(Metaphor) : 문장 형태로 시스템 아키텍쳐 기술, 고객과 개발자간의 의사 소통언어
    
    • Metaphor - XP에 적용되는 개발 기법으로, 공통적인 이름의 체계를 가지고 공통적인 시스템 서술서를 가짐으로 인하여 개발과 의사소통을 돕는 것.
      
  • 기타 : 작은배포, 스토리카드에 의한 계획 수립, 코드공동소유, 코딩표준, 주당40시간
    

• 기존 개발 방법의 문제점 해결을 위한 전략
  
  • 관리 전략
    
    • 결정은 분산화, XP 관리 도구로 메트릭 사용, 코칭/트래킹/조정
      
  • 계획 전략
    
    • 가능한 한 적게 투자, 빨리 가치 있는 기능 구현 전략
      
  • 개발 전략
    
    • 지속적인 통합, 공동 소유, Pair 프로그래밍
      
  • 설계 전략
    
    • 테스트, 설계 및 구현, 반복과 단순화로 설계
      
  • 테스트 전략
    
    • 코딩 보다 단위 테스트를 먼저하고, 테스트를 자동화
      
    • 계획 세우기, 작은 시스템 릴리즈, Metaphor 등 12가지 실천사항 병행
      

 
 

• XP 구현 프로세스(역 발상)
  
  • 1단계 : 릴리스 계획 및 스토리 작성
    
    • 탐색 : 스토리 쓰기(고객) → 스토리 예측(개발자) → 스토리 분할(고객) & Spike(개발자)
      
    • 계획 : 우선순위 정하기(고객) → 개발 속도 정의(개발자) → 범위 정하기
      
  • 2단계 : Iteration 계획
    

    반복 시기 동안 구현할 스토리 계획 → 스토리 분할 → 개발자 할당
    

  • 3단계 : 개발자에 의한 개발 및 관리
    

     
     

• XP를 적용하여 프로젝트 추진 시 고려 사항
  
  • XP를 적용하지 말아야 할 경우
    
    • 고객이나 관리자가 큰 그림으로부터 시작하고자 할 때
      
    • 팀 작업이 회사가 원하는 속도에 맞출 수 없을 때
      
    • 피드백 시간이 너무 오래 걸릴 때
      
  • XP를 적용하여 프로젝트를 시작한 경우
    
    • 12가지 실천사항부터 먼저 적용하여 시작
      
    • 단순화, 명확화, 고객의 역할 정의 부분 등에 지속적으로 보완
      

소프트웨어 재사용

• 3R의 개요
  
  • 역공학(Reverse Engineering)
    
  • 재공학(Reengineering)
    
  • 재사용(Reuse)
    

     
     

• 역공학(Reverse Engineering)
  
  • 역공학의 정의
    
    • 기존에 개발된 시스템에 대해 도구를 이용하여 사양서/설계서 등의 문서로 자동 추출하는 작업
      
    • 개발 단계를 역으로 거슬러 올라가 기존에 개발된 시스템의 코드나 데이터로 부터 설계 명세서나 요구 분석서 등을 도출해 내는 작업
      
  • 역공학이 필요한 경우
    
    • 기존에 가동중인 시스템의 유지보수가 어려운 경우
      
    • 변경이 빈번하여 시스템 효율이 저하된 경우
      
    • 파일 시스템으로 개발된 업무를 데이터베이스 관리 시스템 형태로 재구축하려는 경우
      
    • 기존 메인 프레임 시스템을 다운사이징 하는 경우
      
  • 역공학 사용의 이점
    
    • 상용화된 소프트웨어의 분석을 도와줌
      
    • 기존 시스템의 자료를 분석하여 유지보수를 빠르게 함
      
    • 시스템과 일치하는 문서를 생성하여 시스템의 정보를 얻을 수 있음
      
  • 역공학에 사용되는 입력 유형과 출력 유형
    
    • 입력 : 원시코드, 목적코드, 작업 제어 절차, 라이브러리, 디스크 디렉토리, 텍스트 자료, 데이터 베이스 구조, 입출력 형태와 자료, 각종 문서
      
    • 출력 : 구조도, 자료 흐름도, 제어 흐름 그래프, 개체 관계도, 자료 흐름 그래프
      
  • 역공학의 종류
    
    • 논리 역공학 : 원시 코드로부터 정보를 뽑아내어 물리적 설계 정보 저장소에 저장하고, 물리적 설계 정보를 얻어내는 역할을 수행
      
    • 자료 역공학 :기존 데이터베이스를 수정하거나 새로운 데이터베이스 관리 시스템으로 전이하는 역할을 수행
      

       
       

• 재공학(Reengineering)
  
  • 재공학의 정의
    

    기존 시스템을 널리 사용하고 있는 프로그래밍 표준에 맞추거나 고수준 언어로 재구성하거나 타 하드웨어 등에서 사용할 수 있도록 변환하는 작업
    

  • 재공학의 사용 목적
    
    • 현재 시스템의 유지보수 향상
      
    • 시스템의 이해와 변형이 용이
      
    • 유지 보수 비용 및 시간이 절감
      
    • 표준의 준수 및 CASE의 사용이 용이
      
  • 재공학의 적용 방법론
    
    • 재구조화 방법
      

      시스템의 외부 행위(기능적이나 의미론적)는 유지하며, 동일한 추상화 표현 상태를 다른 표현 형태로 변환하는 과정
      

    • 재모듈화 방법
      

      시스템의 모듈 구조를 변화시키는 것으로, 시스템 구성 요소의 클러스터 분석 및 결합도와 관련됨
      

    • 의미론적 정보 추출 방법
      

      코드 수준이 아닌 문서 수준의 설계 복구 방법
      

     
     

• 재사용(Reuse)
  
  • 재사용의 정의
    

    다른 시스템에서 이용하고 있는 재사용 소프트웨어를 파악하고, 이를 재구성하여 새로운 시스템에 응용하기 위해 적합 시키는 작업
    

  • 재사용의 이점
    
    • 개발 기간과 비용의 감소
      
    • 소프트웨어 품질의 향상 및 생산성 향상
      
    • 시스템 개발에 대한 정보 공유 및 타 프로젝트의 산출물 공유
      
    • 기타 교육적 효과
      
  • 재사용 부품이 가져야 할 특성
    
    • 부품의 중요 특성 파악을 위해 부품 합성과 정정 조건이 기술되어 있어야 함
      
    • 각각의 부품들은 최소한 하나의 사용 목적을 가져야 함
      
    • 최소한의 매개변수만을 사용해야 함
      
    • 이해와 시험이 용이해야 함
      
    • 특정 언어로부터 독립적이어야 함
      
    • 부품 간의 합성이나 부품의 변경 시 부작용이 최소화 되어야 함
      
    • 재사용 가능성이 높아야 함
      

정보시스템 감리 의무 시행

• 감리 의무화
  
  • 공공기관에서 구축하는 정보시스템의 경우 시스템의 특성이나 사업의 규모에 따라 의무적으로 감리를 하도록 규정하고 있음
    
  • 현재는 공공부문의 정보시스템 구축 사업에 한하여 의무감리 제도를 도입하고 있음
    

    공공부문 정보화사업 감리
    

법

제11조(공공기관의 정보시스템 감리) ①공공기관의 장은 제12조의 규정에 따른 감리법인으로 하여금 정보시스템의 특성 및 사업의 규모 등이 대통령령이 정하는 기준에 해당하는 정보시스템 구축사업에 대하여 정보시스템 감리를 하게 하여야 한다.

시행령

제11조(정보시스템 감리의 대상) ①법 제11조제1항에서 "대통령령이 정하는 기준"이라 함은 다음 각 호의 어느 하나에 해당되는 경우를 말한다. 1. 정보시스템의 특성이 다음 각 목 중 어느 하나에 해당되는 경우. 다만, 총 사업비 1억원 미만의 소규모 사업으로서 감리의 비용 대비 효과가 낮다고 공공기관의 장이 인정하는 경우를 제외한다. 가. 대국민 서비스를 위한 행정업무 또는 민원업무 처리용으로 사용하는 경우 나. 다수의 공공기관이 공동으로 구축 또는 사용하는 경우 다. 공공기관간의 연계 또는 정보의 공동이용이 필요한 경우 라. 그 밖의 감리를 시행할 필요가 있다고 해당 공공기관의 장이 인정하는 경우 2. 정보시스템 구축사업으로서 사업비(총 사업비 중에서 하드웨어, 소프트웨어의 단순한 구입비용을 제외한 금액을 말한다)가 5억원 이상인 경우 3. 정보기술아키텍처 또는 정보화전략계획의 수립, 정보시스템의 운영유지보수 등을 위한 사업으로서 감리시행이 필요하다고 해당 공공기관의 장이 인정하는 경우

 
 

• 공공기관의 범위
  

  법에 의해 감리 시행을 의무적으로 해야 하는 공공기관의 범위는 아래의 표와 같음
  

공공기관의 정의(법 제2조)	구체적인 공공기관의 유형
국가기관, 지방자치단체	- 정부부처, 청 등 국가기관 - 시도, 시군구 등 지방자치단체
공공기관의 범의(시행령 제2조)	구체적인 공공기관의 유형
1. 『정부투자기관관리기본법』 제2조에 따른 정부투자기관	- 정부가 납입자본금의 50% 이상을 출자한 기업체
2. 『지방공기업법』 에 따른 지방공사 및 지방공단	- 지자체가 설립한 지방공사, 지방공단
3. 특별법에 따라 설립된 법인	- 각종 법률에 따라 설립된 법인[특별법인]
4. 『정부산하기관관리기본법』 제3조제1항의 적용을 받는 기관	- 정부출연금이 연간 50억원 이상인 기관/단체 - 정부가 납입자본금을 출자하여 최대지분을 보유한 기관단체 - 정부의 출연금, 보조금, 위착업무독점사업 수입금의 합계가 연간 총수입의 50% 이상이고, 연간 50억원 이상인 기관/단체
5. 『고등교육법』 제2조에 따른 학교	- 대학, 산업대학, 교육대학, 전문대학, 기술대학, 방송통신대학, 각종학교(기타 고등교육을 실시하는 교육기관)
6. 그 밖에 정보통신부령으로 정하는 기관	- 시행규칙에서 별도로 규정하는 기관

공공기간인 경우에는 일정 기준 이상의 정보시스템 구축사업을 추진할 경우, 법에 의해 감리를 의무적으로 시행해야 함

법

제2조(정의) 이 법에서 사용하는 용어의 정의는 다음과 같다. 1.~5. 생략 6. "공공기관"이라 함은 국가기관, 지방자치단체, 그 밖에 대통령령이 정하는 기관을 말한다.

시행령

제2조 (공공기관의 범위) 「정보시스템의 효율적 도입 및 운영 등에 관한 법률」(이하 "법"이라 한다) 제2조 제6호에서 "대통령령이 정하는 기관"이라 함은 다음 각 호의 기관을 말한다. <개정 2008.2.29> 1. 「정부투자기관관리기본법」 제2조에 따른 정부투자기관 2. 「지방공기업법」에 따른 지방공사 및 지방공단 3. 특별법에 따라 설립된 법인 4. 「정부산하기관관리기본법」 제3조제1항의 적용을 받는 기관 5. 「고등교육법」 제2조에 따른 학교 6. 그 밖에 행정안전부령으로 정하는 기관

 
 

• 의무감리 시행 대상 기준
  
  • 공공기관이 추진하는 정보시스템 구축사업인 경우, 정보시스템 특성, 사업비 규모 또는 공공기관의 장이 필요성 판단에 따라 감리 시행을 통하여 점검을 받도록 하고 있음
    
  • 감리를 시행하는 것이 필요하다고 판단되는 사업인 ITA구축, ISP 수립, 운영.유지보수 등의 경우 공공기관 장의 판단에 재량권을 부여하여 필요시 감리를 받을 수 있게 하고 있음
    

구분	대상 기준	비고
정보시스템의 특성	1. 대국민 서비스를 위한 행정업무 또는 민원업무 처리용으로 사용하는 경우 2. 다수의 공공기관이 공동으로 구축 또는 사용하는 경우 3. 공공기관간의 연계 또는 정보의 공동이용이 필요한 경우 4. 그 밖의 감리를 시행할 필요가 있다고 해당 공공기관의 장이 인정하는 경우	총사업비 1억원 미만의 소규모 사업으로 비용대비 효과가 낮다고 인정하는 경우는 제외
사업비 규모	정보시스템 구축사업으로서 사업비가 5억원 이상인 경우 ※ 총사업비 중에서 하드웨어, 소프트웨어의 단순한 구입비용을 제외한 금액	단순한 구입비인지 여부는 공공기관 장이 판단
공공기관 장의 필요성 판단	정보기술아키텍처 구축사업, 정보화전략계획 수립사업, 운영사업, 유지보수사업 등으로 감리시행이 필요하다고 공공기관의 장이 인정하는 경우	감리시행의 필요성을 판단하는 근거는 "정보시스템의 특성" 기준 참조

 

행정정보 DB 표준화 지침

• 개요
  

법

제1조(목적) 이 지침은 「전자정부법」제25조 및 같은 법 시행령 제21조제3항․제4항, 같은 법 시행령 제33조에 따라 행정기관이 전자정부를 구현함에 있어 구축․운영하는 행정정보데이터베이스의 설계․구축, 운영관리 및 품질관리에 관한 표준을 정함으로써 정확하고 신뢰할 수 있는 행정정보데이터베이스의 공유 활성화에 기여함을 목적으로 한다.

 
 

• 지침준수 진단표
  

  [별지 제2호 서식] 지침준수 진단표 (준수/부분준수/미준수/비고(사유작성))
  

사업 단계	순번	표준 준수수준측정 기준
계획	1	사업 내 DB 표준화 담당자를 지정하고, 가능하면 사업 초기에 참여시킨다.
	2	행정DB에 대한 품질관리계획이 수립되었다.
	2	사업 내 DB 표준화 담당자는 [별지 제3호 서식 표준화 담당자 요건 심사표]의 사항을 충족하는 자를 선정한다.
	3	작업 별 산출물 정의 및 양식 설계 시 DB와 관련된 산출물에 대해서는 이 지침의 명세 항목을 따른다.
수행	1	데이터베이스에 대한 명명을 위해 이 지침의 데이터베이스 명명 사항을 준수한다.
	2	데이터베이스에 대한 명세를 위해 이 지침의 데이터베이스 명세 사항을 준수한다.
	3	데이터 모델 표현을 위한 표기법은 이 지침에 정해진 권고표준을 준수한다.
	4	엔터티의 이름 부여를 위해 이 지침의 엔터티 명명 사항을 준수한다.
	5	엔터티에 대한 정의 기술을 위해 이 지침의 엔터티 정의 사항을 준수한다.
	6	엔터티에 대한 명세를 위해 이 지침의 엔터티 명세 사항을 준수한다.
	7	애트리뷰트의 이름 부여를 위해 이 지침의 애트리뷰트 명명 사항을 준수한다.
	8	애트리뷰트에 대한 정의를 위해 이 지침의 애트리뷰트 정의 사항을 준수한다.
	9	애트리뷰트에 대한 명세를 위해 이 지침의 애트리뷰트 명세 사항을 준수한다.
	10	릴레이션쉽의 이름 부여를 위해 이 지침의 릴레이션쉽 명명 사항을 준수한다.
	11	릴레이션쉽에 대한 정의를 위해 이 지침의 릴레이션쉽 정의 사항을 준수한다.
	12	릴레이션쉽에 대한 명세를 위해 이 지침의 릴레이션쉽 명세 사항을 준수한다.
	13	이 지침의 데이터 도메인 명명 사항을 준수하여 유도규칙을 명명한다.
	14	이 지침의 데이터 도메인 명세 사항을 준수하여 유도규칙을 명세한다.
	15	코드의 이름 부여를 위해 이 지침의 데이터 도메인 명명 사항을 준수한다.
	16	코드에 대한 명세를 위해 이 지침의 데이터 도메인 명세 사항을 준수한다.
	17	테이블 이름을 정할 때에는 이 지침의 테이블 명명 사항을 준수한다.
	18	테이블에 대한 명세를 위해 이 지침의 테이블 명세 사항을 준수한다.
	19	컬럼의 이름 부여를 위해 이 지침의 컬럼 명명 사항을 따른다.
	20	컬럼에 대한 명세를 위해 이 지침의 컬럼 명세 사항을 준수한다.
	21	데이터사전 정의서 작성을 위하여 데이터사전 명세지침을 준수한다.
	22	행정DB 품질관리계획에 따라 품질관리활동을 수행한다.
	23	사업담당자(공무원)는 관리시스템에 등록한다.
	24	사업담당자는 사업자 중 이 지침에 따른 산출물을 입력할 자를 관리시스템에 등록 요청한다.
	25	사업자는 행정표준용어사전을 관리시스템에서 내려받아 행정DB 설계단계에서 사용한다.
	26	사업자는 행정DB설계에 사용된 용어 중 행정표준용어사전으로 작성할 수 없는 신규용어를 행정표준용어로 신청한다.
	27	사업자는 행정표준용어사전에 등재된 용어 또는 행정표준용어사전에 등재된 용어의 조합 만으로 행정DB를 설계 및 구현한다.
인도	1	산출물점검표에 따라 산출물을 작성하였다.
	2	행정DB 품질진단표, 행정DB 품질관리계획, 제30조제1항에 따른 활동을 수행하였다.
	3	제13조의 항목에 대하여 최종감리 하였다.
	4	관리시스템에 산출물을 입력하였다.
	5	관리시스템에서 입력한 산출물에 대한 표준준수수준 측정값을 계산하였다.
	6	관리시스템을 통하여 산출물 승인요청을 하였다.
	7	사업담당자(공무원)은 검사단계에서 행정DB표준화지침 준수여부를 확인하였다.