소프트웨어 개발 방법론

소프트웨어 개발은 프로세스만이 아니라

방법론, 즉 개발 방법도 필요하다.

 

프로세스와 혼동하는 경우가 많으니

관계를 잘 이해하여 사용하자.

 

[ 방법론 ]

소프트웨어 프로세스의 각 작업을

어떻게 수행하느냐를 정의한 것

 

[ 프로세스 ]

일반적으로 개발할 때 해야할 작업을 명시,

어떤 관계에 있는지는 나타내지 않는다.

 

즉 방법론은 프로세스의 구현이다.

 

따라서 소프트웨어 개발은

프로세스와 방법론이 모두 필요하다.

---

방법론은 각 단계와 입력 자료 및 산출물,

이들의 표현 방법까지 명시한다.

 

방법론에서 제공하는 산출물의 표현 방법은

패러다임, 즉 소프트웨어를 보는 관점에 따라 다르다.

 

예를 들면 객체지향 패러다임은

소프트웨어를 객체들의 상호작용으로 본다.

따라서 분석 설계는 객체를 기반으로 모델링 한다.

 

결국 방법론은 프로세스가 구체적으로 구현된 것이며

소프트웨어 프로세스는 하나 이상의 방법론으로 구현된다.

 

[ 구조적 방법론 ]

실세계의 문제를 처리 라는 관점으로 모델링

> 모델링은 자료 흐름도를 사용

 

외부 엔티티, 프로세스, 자료 저장소 표현

> 자료 흐름 관계를 간선으로 표기

 

복잡한 문제를 쉽게 다루기 위하여

분할과 정복 (divide and conquer) 원리를 적용.

• 최상위 레벨의 DFD 설정
• 복잡한 프로세스를 더 단순한 프로세스로 분할
• 말단 프로세스를 쉽게 구현할때까지 반복
• 말단 프로세스의 입력, 출력, 자료구조, 알고리즘 명시

하지만 소프트웨어 모듈 사이의 구동 관계를

나타내기에는 적합하지 않다.

 

DFD는 자료 흐름을 나타낸 관계이지만

소프트웨어 모듈은 제어 흐름이기 때문인데

이 차이를 메우는 것이 구조적 설계이다.

 

구조적 설계는 자료 흐름도를 구조도로 변경하는 과정이다.

구조도는 모듈 사이의 관계를 나타내는 그래프로

각 노드는 모듈을 나타내며 간선은 상위층의 모듈이

서브루틴을 함수로 호출하는 의미다.

---

[ 정보공학 방법론 ]

계획, 분석, 설계, 구축 등의 기술 집합이

기업의 부문과 연계 통합하는 방법이 필요해졌다.

 

구조적 방법은 기업 데이터의 통합이 어렵기 때문에

이를 극복하고자 정보공학 방법론이 고안되었다.

 

특징

• 기업 중심
• 전략적 시스템 계획 중심
• 데이터 중심
• 분할과 정복
• 공학적 접근
• 사용자의 적극적 참여

정보공학 방법론의 산출물은 종류가 많지 않다.

 

설계 시)

• 스토리보드
• 데이터 설계서
• UI 설계서

개발 과정)

• 물리적 테이블
• 프로그램 코드

---

[ 객체지향 방법론 ]

실세계를 객체라는 눈으로 보고

객체 사이의 인터랙션을 모델링하는 방법

 

복잡한 대규모 시스템을 클래스로 모듈화하고

캡슐화할 수 있는 좋은 방법으로

 

주어진 작업을 수행하기 위하여 협력하는

객체들의 모임이 바로 시스템이라는 관점이다.

 

유명한 3가지 접근법

• OMT(Object Modeling Technique)
• Booch 방법론
• 유스케이스

---

[ 세 가지 방법론의 비교 ]

	구조적 방법론	정보공학 방법론	객체지향 방법론
특징	프로그램 로직 중심, 그림으로 요구사항 분석, 문서화하는 체계적 형식	기업정보 중심 전략 계획을 수립 후 데이터 중심으로 CASE 도구 사용	유스케이스로 비즈니스 분석, 자료와 함수를 묶은 클래스를 파악 후 객체로 시스템 구성
설계 관심사	함수 위주	자료 위주	클래스 위주
설계의 핵심	모듈	엔티티	객체
중심 방법	프로그래밍 기법	기억의 전략 및 산출물 중심	설계의 표현