컴포넌트 기반 개발(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가지 실천사항부터 먼저 적용하여 시작
      
    • 단순화, 명확화, 고객의 역할 정의 부분 등에 지속적으로 보완