'객체지향'에 해당되는 글 1

  1. 2009.02.05 간략히 정리한 소프트웨어 방법론의 비교 연구

개발 방법론의 이해와 배경

계속해서 새로운 비즈니스 영역이 창출되고 새로운 비지니스가 산업 전반에 적용되면서 사용자(Stakeholder)들에게 보여지는 물리적인 시스템인 정보 시스템의 중요성이 강조되고 있다이에 비지니스 패러다임은 계속해서 복잡해 지고 이에 맞는 환경에 적응(Time to Market) 해야 할 필요가 있어 조금씩 진보된 개념들의 방법론들이 계속해서 만들어지고 있다또한 최근에 인터넷 비지니스에 대한 부분이 강화되면서 초기 임기응변적으로 구축되거나 과정보다는 결과를 우선하여 진행하는 시스템 구축되었던 시스템들이 대형화되면서 잘못된 결과들을 야기하면서 막대한 원가 손실과 고객 불만들이 가중되고 있어 방법론에 대한 관심은 더더욱 높아가고 있는 상황이다.


어떻게 하면 비용을 적게 들이면서 빠르게 좋은 소프트웨어를 만들까에 대한 고민에 대한 이야기 

방법론이란?
사용자(Stakeholder:이해당사자요구 사항을 정확히 파악하여 체계적이고 논리적으로 수행하는 처리 절차작업 방법산출물적용 기법,적용 도구를 기술하는 것이 방법론이다방법론을 잘 활용하는 것은 시스템 구축시 개발자들이 방법론을 이해하고 참조하며 시스템의 계획분석설계구현운영의Life Cycle을 따라 정보 시스템을 수행하는 것이며 이는 시스템 개발의 이론적 기반이 된다

처리 절차프로젝트 수행의 작업 단계의 쳬계

작업 방법각 단계별 작업의 구체적인 설명

산출물    단계별 산출물 목록

적용 기법 - 단계별 작업 수행시 소요 기술 또는 기법

적용 도구 - 단계별 필요한 Tool방법론을 표준화하고 개발 주기(Life Cycle)에 적용함으로써 개발 시스템의 품질 및 생산성을 높이는 수단       

방법론은 축척된 경험, KnowHow , 문서화 및 정리된 작업들로 구성이 된다.


방법론의 필요성

시스템 구축과 개발은 Software, Hardware, System Software, Network, DBMS등 모든 시스템의 기술 요소가 결합된 형태로 이루어지는 복잡한 작업이다다음과 같은 이유에서 방법론이 필요하다.


빠른 변화와 다양한 요구로 인해 비지니스 환경에 대응되는 유연한 Sytem 구축하기 위하여

최신의 IT기술을 시스템 구성 전략에 반영하기 위하여

비지니스 시스템 구축시 구성원간의 의사 소통의 표준화하기 위하여

개인의 경험이나 능력에의 의존도를 줄이기 위하여

다양한 능력과 위치의 사람을 효과적으로 시스템 구축에 참여시키기 위하여

 


방법론들의 변화의 동향 및 특성

구조적 방법론 (Structured Methodology)

1950년대 구조적이지 못한 무원칙의 개발 방식은 개발자의 사고능력에 따라 개발되었으며 Logic 구성 또한 개발자 자기 중심적이다이는 개발 생산성의 저하와 유지 보수의 어려움 등의 문제점을 발생시켰으며 결국 Software 위기를 불러 왔다이에 1960년대 GOTO문을 쓰지 말고 구조적으로 프로그래밍하자는 주장이 대두됨으로써 분석과 설계도 구조적으로 하자는 의견이 확대되었고 구조적 방법론의 틀이 완성되었다구조적 방법론은 다음과 같은 특징을 가진다.

특징

한계

기능과 프로세스 중심의 분석과 설계

모듈의 분할정복에 의한 설계 방법

개발 목적이 프로세스와 산출물의 구성

자료 흐름도,자료사전,단위명세서의 자료 중심

데이터 모델링 방법이 미흡

설계와 코딩을 강조자동화 도구 부족 
문제 해결단위가 소규모 ,자체적인 프로세스 변화가 너무 많음(데이터는 변화가 적은 반면)


정보 공학 방법론(Information Engineering Methodology)
80
년대를 거치면서 경영 정보 시스템(MIS),의사 결정 지원 시스템(DSS),임원 정보 시스템(EIS),전략정보시스템(SIS)등의 다양한 형태로 발전하게 되었고 이는 비지니스 시스템의 IT적 관점에서 보면 데이터베이스네트워크 등 다양한 시스템 구성요소의 결합을 의미하게 되었다.시스템의 규모화 복잡도 증가에 따라 체계적인 진행관리가 필요하게 되었고 이에 80년대 중반 이후 James Martin에 의해 정보공학(Information Engineering)의 체계가 정리된 정보공학 방법론이 본격적으로 활용되었다정보 공학 방법론은 다음과 같은 특징을 가진다

특징

한계

데이터와 프로세스의 상관 분석(CRM)

목표시스템은 개별 소프트웨어가 아닌 기업에서 사용되는 비지니스 시스템

정보전략 계획(ISP)작업이 포함되어 있음

데이터 중심의 분석과 설계 및 사용자 참여

CASE (Computer Aided Software Engineering)

분석과 설계의 연계 부족

요구 분석의 리스크는 여전히 존재

효과적인 개발을 위해서 시간이 많이 투자됨

소규모 독립된 시스템에는 부적합함

1980년대 중반 이후 정보공학 방법론은 대규모 비지니스 시스템의 개발에 가장 적합한 방법론으로 인정


객체지향 방법론 (Object Oriented Methodology) 

추상화캡슐화상속정보은닉 등 객체를 중심으로 프로그래밍 구조를 단순화하고재사용성을 강화하는 객체지향 프로그래밍 
방식이러한 원칙이 분석과 설계에 확대되면서 탄생했다.

이전 방법론에서 프로세스와 데이터가 분리되어 처리됨으로써 분석과 설계단계에서 개발단계로 연계 시키는데 많은 문제가 있었다면 객체지향 방법론은 이러한 부분에서 많이 진화된 방법론이다객체지향 방법론은 다음과 같은 특징을 가진다.

특징

한계

재사용성이 높고

안정성 객체단위의 자연스러운 설계

클래스를 통한 시스템의 복잡성 극복

신뢰도가 높고 무결성

새로운 소프트웨어 시장 형성 신속한 설계

신속한 설계 높은 품질의 설계도출

프로그래밍 개발 용이성유지보수 용이성 동적인 소프트웨어 생명 주기 보다 실제적 실감적 모델링 개발자와 관리자 간의 효율적이 의사 소통의 진보된 기법 모델

분석과 설계의 연계 부족

요구 분석의 리스크는 여전히 존재

효과적인 개발을 위해서 시간이 많이 투자됨

소규모 독립된 시스템에는 부적합함

 

- CBD 방법론 (Component Based Development or Design)

e-Business 와 더불어 소프트웨어의 수요 폭주하고 소프트웨어의 대형화복잡도 증가하고 객체지향의 개발 방법의 한계성 극복과 재사용성의 극대화하기 위해 탄생했다.S/W 컴포넌트의 재사용성과 독립성을 보장하여 S/W 복잡성과 생산성을 향상시키기 위해 컴포넌트의 생산선택평가 및 통합으로 구성되는 새로운 개발 패러다임이다. ( 소프트웨어도 하드웨어처럼 조립 해보자. )

          

특징

한계

실행코드를 기반으로 재사용
용도역할기술 표준인터페이스에 대한 정보 준비

교체 가능한 Component를 개발하기 위해 표준 분수

배포 시 관련 문서와 코드들이 독립적인 단위로 패키지화 되어 제공

비지니스 컴포넌트가 사실상 재사용 어려움

컴포넌트 크기아키텍처 스타일인터페이스 명세 등 표준화 미흡

J2EE, .NET, COM 등 주요 표준 컴포넌트 환경의 벤터 종속적

컴포넌트 Repository/Registry 등 공유체계 및 COST 등의 유통 구조가 추상적

비지니스 프로세스 지원에 적용하기 어려움

경영층 및 개발자의 지식 및 경험 부족에 의한 거부감

 


그래서 방법론은 시스템 구축의 표준화 도구이다

오프라인 과의 연계사업의 다각화콘텐트 연계시스템의 다양화 및 대형화도 동시에 진행되었다. E-biz 시대에서는 시스템 구축의 속도가 중요한 요인최초 시스템 구축 시에 시스템 확장에 대한 고려를 하지 않음시스템 구축단계에서 계획대로 실행을 한다면 문제점들을 많이 줄일 수 있을 것표준화된 규칙을 제공하는 것이 방법론이다

 

정리하자면

위와 같이 근 40년간 진보된 개념의 방법론들이 만들어져 왔다앞으로 계속해서 다양한 비지니스 환경의 복잡성은 지금보다 더 심해질 것이고 사용자들의 요구 사항도 지금보다 더 다양해 질 것이다어떠한 방법론이 맞느냐어떠한 방법론이 좋은 것이냐에 대한 논란은 끊이지 않겠지만 지금 내가 처한 환경에서의 가장 알맞은 것들을 편취해서 가장 빠른 시간에 질 좋은 소프트웨어를 사용자들의 요구사항에 맞게 만들 수 있다면 그것이 가장 좋은 방법론 이라고 생각한다.