소프트웨어공학의 발전사를 보면 크게 3가지의 방법론이 출현하였음을 알 수 있는데 과거 방법론이 없던 무방법론이 없던 무방법론 시대에서 구조적 분석/설계(또는 방법론), 정보공학,객체지향 방법론 들이 그것이다.
1.구조적 방법론(Structured Methodology) 구조적 방법론의 시작은 구조적 프로그래밍의 개념이 탄생하면서부터이고,구조적 프로그램밍의 탄생은 소프트웨어공학의 출범을 알리는 것이었다.
1950년대에 시작한 소프트웨어 개발의 역사는 구조적이지 못한 무원칙의 상향식 개발 방식이었다. 개발자의 손이 가는대로 코딩을 해 나갔으며, 조직의 구성 또한 자신만이 알아볼수 있는 그런 것있었다. 이것은 개발 생산성의 저하와 유지보수의 어려움 등 소프트웨어를 개발하는데 있어서 거의 모든 부분에 문제점을 갖게 만들었고 결국은 "소프트웨어 위기"라는 용어의 탄생을 불려왔다
1960년대 말 "GO TO"논쟁, 즉 GO TO 문을 쓰지 말고 구조적으로 프로그래밍을 하자라는 주장이 호응을 얻으면서, 분석과 설계도 구조적으로 하자라는 의견으로 확대되면서 구조적 방법로의 틀이 완성되어 갔다.
구조적 프로그래밍의 개념은 다음과 같다.
*코드가 계층적인 형식과 제한된 구조로 작성된 순서대로 순차적으로 실행함
*알고르즘을 기술하는데 순차(sequencing),반복(iteration)구조면 충분하며,단일입구/ 단일출국의 처리구조를 가짐
*철저한 모듈화로 추상화와 정보은닉을 이루어 프로그램의 구조를 읽기 쉽게 단순화함
구조적 방법론의 그 특징은 다음과 같다.
데이터 흐름 지향, 즉 프로세스 위주의 분석과 설계 방식 | 모듈의 분할과 정복에 의한 하향식 설계 방식
| SDLC의 구조를 가진 폭포수 모델이 기본
| 소프트웨어의 개발이 목표인 프로세스와 산출물의 구성
| 데이터의 구성에 대한 설계 방안이 부족
| 프로젝트 관리 및 조직, 역활 등 방법론적 다른 요소들의 정의가 없음
|
위의 특성들로 구조적 방법론의 단점을 추정할 수 있는데, 이것은 가장 오래전에 규정된 방법론이며, 단순한 소프트웨어 개발을 목표로 한다는 점에서 기인한 것이다.
2. 정보공학 방법론(Information Engineering Methodology)
구조적 방법론은 그 후 오랫동안 소프트웨어 개발의 방법론으로 사용되어 왔지만 정보기술의 발전에 따라 새로운 방법론의 필요가 생겼다.
1970년대 이후 소프트웨어는 기업에서도 많이 응용되었고 80년대를 거치면서 경영정 보시스템(MIS:Management Information System),의사결정지원시스템(DSS:Decision Support System),임원정보시스템(EIS:Executive Information System)등의 형태로 발전하여 갔고, 급기야 전략정보시스템(SIS:Strategic Information System)의 수준에 이르렀다.이것은 단지 소프트웨어 뿐 아니라 데이터베이스,네트워크, 운영조직 등 방대한 주변 정보기술들과 연계 되면서 정보시스템(Information System)이라는 개념의 한 요소에 포함되어 버리고 말았다. 이런 정보시스템은 그 규모도 클 뿐 아니라 구성내용도 복잡해서 개발의 조직도 커지고 개발기관도 몇 년 단위로 늘어났다. 한편으로, 정보기술은 급격히 발전해서 4GT,CASE,등의 자동화 도구, 다이어그래밍 도구의 등장으로 이것들을 활용할 필요도 생겨났다.
80년대 중반 James Martin에 의해 정보공학(Information Enfineering)의 체계가 정리되면서 정보공학은 본격적으로 활용되었다. 정보공학 방법론의 그 특징은 다음과 같다.
~소프트웨어공학의 기본적 사상, 즉 하향식,모듈화, 분할과 정복, 폭포수 등은 동일 ~정보공학은 개별 소프트웨어가 아닌 기업에서 사용되는 정보시스템을 목표로 함 ~단순한 업무지원 시스템의 개발은 의미가 없고 기업의 경영전략을 창출하는 정보전략 계획(ISP:Information Strategy Planning)작업이 포함됨 ~기업의 업무처리에는 안정된 데이터베이스가 중요하므로 데이터 중심의 분석과 설계를 진행 ~CASE 등 자동화를 요구
정보공학은 대규모 정보시스템의 개발에 가장 적합한 방법론으로 인정되어 왔으나, 경직되고 복잡한 구조로 인해 많은 단점들이 생겨났고, 때 맞춰 객체지향의 개념이 바람을 타고 정보공학의 영역을 허물어 가고 있다.
3. 객체지향 방법론 (Object Oriented Methodology) 모든 방법론이 그렇듯이 객체지향 방법론도 객체지향 프로그래밍으로부터 출발했다. 추상화와 캡슐화, 상속, 정보은닉 등 객체를 중심으로 프로그래밍 구조를 단순화하고 재사용 성을 강화하는 프로그래밍 방식의 유용성이 증명되면서, 분석과 설계도 객체지향의 원칙을 적용하려는것이 객체지향 분석/설계요 모든 제반환경이 결합되어 객체지향 방법론이 된 것이다.
구조적 방법론이나 정보공학 방법론 모두 프로세스와 데이터를 분리하여 처리한다는 단점은 이를 통합하여 처리하는 객체지향의 등장에 가장 큰 배경이 되었다. 프로세스와 데이터가 분리 됨으로써 이를 분석하여 설계와 개발로 연계시키는데 많은 애로를 겪어야 하면 복잡한 기법들이 활용되어야 한다.또한 완성된 시스템에 대한 요구사항의 확인 결과를 너무 늦게 확인할 수 있다는 점, 산출물의 양과 복잡도가 크다는 점 등 여러가지 문제를 객체지향 개발 방법론에서 해결하고 있다.
객체지향 방법론의 특징은 다음과 같다.
~반복적, 그리고 점증적인(Iterative and Incremental)개발 방식 ~재사용성의 강조 ~쉽고 표준화된 표기법 존재 ~분산객체 기술의 완벽한 지원 ~OODBMS의 원활한 연계 등 아직 개선의 여지가 많음
최근에 많은 프로젝트들이 점차 객체지향 방법론으로 진행되고 있으며, 객체지향 모델링 언어의 표준이 UML(Unified Modeling Language)를 기반으로 RUP(Rational Unified Process) 등 상용 방법론들이 등장하여 활용되고 있다.
3.3방법론간의 비교 이 외에도 기술의 발전에 따라 RAD(Rapid Appilcation Development)방법론 클라이언트/ 서버(Client/Server) 방법론, 패키지(Package) 개발 방법론,웹(Web) 개발 방법론 등 여려 방법론 유형들이 나올 수 있지만 아무래도 위의 3가지가 가장 큰 주류라 하겠다.또한 최근 들어 컴포넌트 기반 개발(CBD:Component Based Development)방식이 큰 반향을 얻고 있고, 조만간 표준화된 방법론도 등장(이미 여러 방법론들이 나와 있지만)할 것으로 보여 컴포넌트 방법론이 제 4의 비교 대상에 올려야 할지도 모르겠다.
|
