위키원
소프트웨어 개발방법론
소프트웨어 개발방법론(SDM; Software Development Methodology)이란 소프트웨어를 개발하는 방법에 대한 이론으로서, 소프트웨어 개발 과정, 절차, 방법, 산출물, 기법, 도구들을 체계적으로 정리하고 표준화시킨 것이다.[1]
목차
개요
소프트웨어 개발방법론은 소프트웨어를 어떻게 만들지에 대해 관심을 가진다. 따라서 개발 방법론에는 단계별 산출물뿐만 아니라 산출물은 누가 어떤 순서로 어떻게 만들어야 하는지 그리고 어떤 도구를 사용해야 하는지 구체적으로 정의한다.[2]
역사
- 1969년까지 구조적 프로그래밍이 주로 쓰였다.
- 1980년대 구조적 시스템 분석과 설계 방법론이 쓰였다.
- 1990년대 객체 지향 프로그래밍이 1960년대부터 개발되어, 1990년대 중반에 주류 개발 방법론이 된다.
- 고속 개발 방법론이 1991년부터 쓰인다.
- 스크럼이 1990년 후반부터 쓰인다.
- SEI의 와츠 험프리가 팀 소프트웨어 프로세스를 개발한다.
- 2000년대 익스트림 프로그래밍이 1999년부터 쓰인다.
- 래셔널 통합 프로세스 (RUP)가 1998년부터 쓰인다.
- 스콧 앰블러가 2005년에 애자일 통합 프로세스 (AUP)를 시작한다.
종류
소프트웨어의 개발 방법론은 크게 정보공학 방법론, 객체지향 방법론, CBD방법론, 애자일 방법론으로 나눌수 있다. 4가지 방법론의 단점을 보완하거나 각각의 방법론의 장점을 따온 개발론도 있다.[2]
구조적 방법론
구조, 흐름, 간결, 간단 이 구조적 개발방법의 특징이다. 요구사항 분석 → 구조적 분석 → 구조적 설계 → 구조적 프로그래밍의 순서로 이루어져 있다.[3]
구조적 방법론 특징
구조적 방법론 기본 개발 과정 과정 설명 요구사항 분석 고객이 원하는 요구사항을 끌어내 명세화 하는 것. 구조적 분석 고객이 원하는 기능/시스템환경/데이터를 종합하여 데이터 흐름도(Data Flow Diagram) 작성 구조적 설계 모듈 중심 설계 단계, 목적 : 재활용, 결합도를 낮춰 독립성을 높임 구조적 프로그래밍 순차, 선택, 반복의 논리 구조 구성으로 프로그램 복잡성 최소화
구성요소 종류 내용 데이터흐름도 DFD(Data Flow Diagram) 각 기능을 분할하여 표현한 구조도 자료사전 DD(Data Dictionary) * 자료나 의미나 자료의 단위 및 값에 대한 사항을 정의하는 도구
* DFD에 표현된 자료 저장소를 구체적으로 명시하기 위해 사용상태전이도 STD(State Transition Diagram) 보통 어떤 상태에서 다른 상태로 변경되는 과정 및 해당 과정의 프로세스 명세 소단위명세 Minispec(Mini Specification) 쪼갤 수 없을 정도 까지의 기능으로 분리 후 명세(구조 언어 사용하거나 N-S Chart 이용)
구조적 개발 방법론 장점
- 정형화/체계화 : 명확한 요구사항을 추출하여 설계에 반영 가능
- 모듈화 : 효율적인 재사용 및 유지보수 가능
구조적 개발 방법론 단점
- 거시적 관점 인식 부족 : 방법론에 대한 다양한 시도를 하고 있지 않다는 뜻으로 프로젝트에서만 사용하는 추세
- 실제 사례 자료 부족으로 데이터 모델링 방법과 명확한 방법론적 지침이 미흡함
- 유지보수성 및 재사용성이 낮기 때문에 기능이 불완전하고 자주 변한다.
정보공학 개발 방법론
정보공학 개발방법론은 비즈니스 시스템 규모 성장과 소프트웨어 공학 발전에 따라 1980년대 중반에 등장한 방법론으로 기업 전체 , 또는 기업의 주요부분을 계획 , 분석 , 설계 및 구축에 정형화된 기법들을 상호 연관성 있게 통합 , 적용하는 데이터 중심 방법론이다. [4] [2]
절차
1. 정보전략계획 수립단계(Information Strategy Planning) 기업의 경영전략을 뒷받침할 수 있는 정보화 전략을 수립하기 위해 현행 업무프로세스와 시스템을 분석하고 미래 아키텍처와 전략계획을 수립하게 된다.
- 경영전략, 관련조직, 업무자료 거시적 분석
- 현행시스템의 평가
2. 업무영역 분석단계(Business Area Analysis) 기업의 업무 현황을 분석해서 개념 수준의 데이터와 프로세스를 설계하는 업무분석 단계이다.
- 데이터 모델링 : ERD
- 프로세스 모델링 : 프로세스 계층도(PHD), 프로세스 의존도(PDD), 자료흐름도(DFD)
3. 시스템 설계단계(System Design) 실질적으로 시스템을 설계하는 단계로 우리가 많이 사용하고 있는 논리적 ER 다이어그램으로 데이터를 설계하고 분할 다이어그램, 액션 다이어그램, 의존 다이어그램을 사용해 프로세스를 설계한다.
- BSD(Business System Design)
- 업무절차 정의
- Presentation 설계
- 분산 설계
4. 시스템 구축단계(Construction) 확정된 설계명세서로부터 데이터베이스 생성기와 프로그램 코드 생성기를 이용해 데이터베이스와 실행 가능한 프로그램 코드를 생성한다. [5] [2]
개념
설계할 때는 스토리보드, 데이터 설계서, UI 설계서 정도를 작성하고 개발 과정에서는 이를 바탕으로 물리적 테이블과 프로그램 코드가 만들어 진다. 이런 관점에서 정보공학 방법론을 바라 본다면 BAA에 해당하는 요구분석 단계에서는 요구사항 명세서가 만들어지고 BSD에 해당하는 시스템 설계 단계에서는 논리 ERD와 업무 프로세서를 설명하는 프로세스 구조도/흐름도가 만들어 진다. 그리고 SC에 해당하는 개발 단계에서는 물리 ERD, UI, 프로그램 코드가 개발된다. [2]
객체지향 개발 방법론
객체지향 개발방법론은 현실 세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object)로 표현하며, 현실세계에 존재하는 실체 및 개념들을 객체(Object)라는 독립된 단위로 구성하고 이 객체들이 메시지 교환을 통해 상호작용함으로써 전체시스템이 운영되는 개념이다. [2]
개념
객체지향 개발 방법론에서는 분석, 설계, 구현의 전 과정을 객체 중심으로 진행한다. 심지어 데이터를 저장하는 테이블도 따로 설계하지 않고 데이터 객체로 설계한다. 데이터는 결국 데이터베이스에 저장되는데 만일 데이터베이스가 객체형 DB라면 별다른 변환과정 없이 데이터 객체를 그대로 저장하면 되지만, 관계형 DB를 사용한다면 객체를 관계형 테이블로 변환하는 과정이 필요하다. 이 과정을 객체-관계 매핑(Object Relation Mapping)이라 하며 현재 대부분의 회사에서 관계형 데이터베이스를 사용하고 있기 때문에 객체-관계 매핑은 필수적인 과정이라 할 수 있다. [2]
CBD 개발 방법론
CBD 개발방법론(Component Base Development) 은 개발된 S/W 컴포넌트를 조립, 시스템을 개발하여 객체지향의 단점인 S/W 재사용성을 극대화한 개발 방법론이다. 컴포넌트는 인터페이스로 접근 가능하고 독립적인 기능을 수행하는 모듈로써 교체가 가능한 소프트웨어 부품이다. [2]
개념
CBD 개발 방법론은 크게 컴포넌트를 개발하는 CD(Component Development) 단계와 개발된 컴포넌트를 사용해서 개발을 진행하는 CBD(Component Base Development) 단계로 나눌 수 있다. CD 단계에서는 도메인을 분석해 컴포넌트 대상 업무를 선별하고 컴포넌트를 개발해 저장소에 입력한다. CBD 단계에서는 요구 분석을 통해 컴포넌트 기반으로 설계하고 필요한 컴포넌트를 저장소에서 찾아서 조립하는 방식으로 프로그램 개발을 진행한다. 만일 필요한 컴포넌트가 저장소에 없다면 CD 단계로 돌아가서 컴포넌트를 개발하고 이를 사용해 개발을 계속 진행한다. [2]
애자일 개발 방법론
애자일 개발 방법론은 기존 방법론들이 너무 절차를 중시한 나머지 변화에 대응하기 어려웠던 단점을 개선하기 위해 나왔다. 애자일 방법론은 절차보다는 사람을, 문서보다는 작동하는 소프트웨어를, 미리 철저하게 계획하기 보다는 변화에 대한 민첩한 대응을, 계약과 협상에 얽매이기 보다는 고객과의 협력을 중요하게 생각한다. [2]
개념
애자일 방법론에서는 먼저 개발 범위 안에 있는 요구사항을 분석해 우선순위가 높은 요구사항을 먼저 개발한다. 개발된 부분에 대해 실행하는 모습을 보여줘서 고객의 평가를 받고 고객의 요구사항과 개선사항을 반영해 다음 요구사항 개발에 참고한다. 이런 방식을 계속 반복하면서 소프트웨어 개발 범위를 점진적으로 늘려가게 된다. 여기에서 가장 핵심이 되는 사항은 단계별로 고객에게 동작하는 소프트웨어를 계속 보여주고 요구사항에 대한 변경을 적극적으로 수용한다는 것이다.[2]
각주
참고자료
- 〈소프트웨어 개발 방법론〉, 《위키백과》
- 개발 방법론 〈개발 방법론이란〉, 《깊고넓은지식창고》, 2018-11-19
- 구조적 방법론 〈구조적 방법론〉, 《유혁의 엉터리 개발》, 2019-06-07
- 정보공학 방법론 〈정보공학 개발방법론〉, 《네트워크 이야기》, 2019-10-18
- 정보공학 방법론 절차 〈정보공학 개발방법론 구성단계〉, 《기억을 이기는 기록》, 2018-04-19
같이 보기
