맨위로가기

동적 시스템 개발 방법

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

동적 시스템 개발 방법(DSDM)은 1990년대 초 신속 응용 프로그램 개발(RAD)의 비구조적인 문제점을 해결하기 위해 1994년 DSDM 컨소시엄에 의해 개발된 프레임워크이다. DSDM은 기술보다는 사람 간의 협력을 중요하게 여기며, 타임박싱, MoSCoW 방법론, 프로토타입 제작 등 핵심 기술을 활용한다. 비즈니스 요구사항에 집중하고, 협업을 강조하며, 품질 저하를 방지하는 8가지 기본 원칙을 기반으로 한다. DSDM은 애자일 소프트웨어 개발과 유사하게 반복적이고 점증적인 개발 방식을 따르며, 스크럼, XP 등 다른 개발 프레임워크와 공통적인 특징을 공유한다. 2016년 DSDM 컨소시엄은 애자일 비즈니스 컨소시엄(ABC)으로 명칭을 변경했다.

더 읽어볼만한 페이지

  • 소프트웨어 개발 프로세스 - 버전 관리
    버전 관리는 파일 변경 이력을 체계적으로 관리하는 시스템이며, 다양한 구조와 소스 관리 모델을 통해 협업을 지원하고, 비즈니스 등 다양한 분야에서 활용된다.
  • 소프트웨어 개발 프로세스 - 소프트웨어 개발 수명 주기
    소프트웨어 개발 수명 주기(SDLC)는 시스템 설계자와 개발자가 따르는 일련의 단계로, 예비 분석부터 폐기까지 여러 단계를 거치며, 폭포수 모델, 시스템 분석 및 설계(SAD), 객체 지향 분석 및 설계(OOAD) 등 다양한 방법론을 포함한다.
동적 시스템 개발 방법
개요
이름동적 시스템 개발 방법
원어Dynamic systems development method
약칭DSDM
유형애자일 소프트웨어 개발 방법론
특징
핵심 원칙적극적인 사용자 참여
권한 있는 팀
빈번한 제공
적합성 기준
반복적이고 점진적인 개발
모든 변경 사항은 되돌릴 수 있음
요구 사항의 수준별 기반
협력적이고 협조적인 접근 방식
역사
개발 배경고속 응용 프로그램 개발(RAD)의 문제점 해결 및 보완
창시1994년, DSDM 컨소시엄
관련 자료
참고 서적Business Focused Development

2. 역사

신속 응용 프로그램 개발(RAD) 운동의 비구조적인 문제점을 해결하고, 품질을 보장하는 프레임워크를 개발하기 위해 1994년 영국에서 DSDM 컨소시엄이 설립되었다. 이 컨소시엄은 벤더 및 전문가 협회에 의해 설립되었으며, 최우수 사례 경험을 결합하여 독립적인 RAD 프레임워크를 개발하고 홍보하는 것을 목표로 했다. 런던에서 버틀러 그룹이 주최한 행사가 DSDM 컨소시엄의 기원이며, British Airways, American Express, Oracle, Logica와 같은 우량주(Blue chip (stock market)) 조직들이 참여했다.

이후 DSDM은 발전을 거듭하여 2006년에는 공용 버전 4.2가 공개되었고[7], 2014년에는 핸드북과 템플릿이 온라인으로 공개되었다.[8][9] 2016년 DSDM 컨소시엄은 '''애자일 비즈니스 컨소시엄'''(ABC)으로 이름을 바꾸었으며[10], 현재 애자일 비즈니스 컨소시엄이 DSDM 프레임워크를 소유 및 관리하고 있다.[11]

2. 1. 탄생 배경

1990년대 초, 신속 응용 프로그램 개발(RAD)이 IT 업계 전반으로 확산되었다. 소프트웨어 애플리케이션의 사용자 인터페이스는 이전의 텍스트 기반 환경에서 현재 사용되는 그래픽 사용자 인터페이스로 전환되었다. PowerBuilder와 같은 새로운 애플리케이션 개발 도구가 시장에 출시되어, 개발자는 제안된 솔루션을 고객과 훨씬 쉽게 공유하고 프로토타입을 제작할 수 있게 되었으며, 고전적이고 순차적인 폭포수 개발 방식의 문제점을 해결할 수 있었다.

그러나 RAD 운동은 매우 비구조적인 경향을 보였다. 적절한 프로세스에 대한 일반적으로 합의된 정의가 없었고, 많은 조직이 자체 정의와 접근 방식을 고안했다. 많은 주요 기업은 RAD의 가능성에 주목했지만, 자유로운 개발 방식이 초래할 수 있는 최종 결과물의 품질 저하를 우려했다.[7]

2. 2. DSDM 컨소시엄의 설립과 발전

1994년, 소프트웨어 공학 분야의 벤더 및 전문가 협회는 최우수 사례 경험을 결합하여 "독립적인 신속 응용 프로그램 개발(RAD) 프레임워크를 공동 개발하고 홍보"하는 것을 목표로 DSDM 컨소시엄을 설립하였다. DSDM 컨소시엄의 기원은 런던에서 버틀러 그룹이 주최한 행사였으며, 이 행사에는 British Airways, American Express, Oracle, Logica와 같은 우량주(Blue chip (stock market)) 조직들이 참여하였다.

2006년 7월, DSDM 공용 버전 4.2가 개인의 열람 및 사용을 위해 제공되었다. 그러나 DSDM을 재판매하는 모든 사람은 여전히 비영리 컨소시엄의 회원이어야 했다.[7]

2014년, DSDM 핸드북이 온라인에 공개되었고, DSDM 템플릿을 다운로드할 수 있게 되었다.[8][9]

2016년 10월, DSDM 컨소시엄은 '''애자일 비즈니스 컨소시엄'''(ABC)으로 명칭을 변경했다.[10] 애자일 비즈니스 컨소시엄은 DSDM 프레임워크를 소유하고 관리하는 비영리, 벤더 독립적인 조직이다.[11]

3. 특징

DSDM은 기술적인 문제보다 사람 간의 문제를 중요하게 여기는, 특정 공급업체에 종속되지 않는 접근 방식이다.[8] DSDM은 사람들이 효과적으로 협력하여 비즈니스 목표를 달성하도록 돕는 데 중점을 둔다.[8] 또한 도구 및 기술에 독립적이므로, 모든 비즈니스 및 기술 환경에서 사용할 수 있다.[8]

3. 1. 기본 원칙

DSDM은 다음 8가지 원칙을 기반으로 한다.[12]

  • 비즈니스 요구사항에 집중
  • 정해진 시간에 인도
  • 협업
  • 품질 저하 절대 불가
  • 확고한 토대 위에서 점진적으로 구축
  • 반복적으로 개발
  • 지속적이고 명확하게 의사소통
  • 통제력 입증


이 원칙들은 팀이 일관성 있게 결과를 도출하기 위해 취해야 하는 태도와 마음가짐을 제시한다.

3. 2. 핵심 기술


  • 타임박싱: 프로젝트를 여러 부분으로 나누어 각 부분에 정해진 예산과 마감일을 할당하여 점진적으로 완료하는 방식이다. 각 부분에 대한 여러 요구 사항의 우선순위를 정하고 선택한다. 시간과 예산이 고정되어 있으므로, 남은 변수는 요구 사항뿐이다. 따라서 프로젝트에 시간이나 예산이 부족해지면 우선순위가 낮은 요구 사항은 제외된다. 이는 파레토 법칙에 따라 시스템 요구 사항의 80%가 프로젝트의 20%에서 나오기 때문에, 가장 중요한 20%의 요구 사항이 시스템에 구현된다면 비즈니스 요구를 충족할 수 있다는 것을 의미한다. 또한, 어떤 시스템도 처음부터 완벽하게 구축되지 않는다.
  • MoSCoW: 작업 항목 또는 요구 사항의 우선순위를 정하는 기술이다. 이는 다음을 나타내는 약어이다.
  • '''반드시 해야 함(Must have)'''
  • '''해야 함(Should have)'''
  • '''할 수 있음(Could have)'''
  • '''하지 않을 것임(Won't have)'''
  • 프로토타입 제작: 프로젝트 초기에 개발 중인 시스템의 프로토타입을 만드는 것을 의미한다. 이를 통해 시스템의 단점을 조기에 발견하고, 미래 사용자가 시스템을 시험 사용해 볼 수 있다. 이러한 방식으로 사용자 참여를 효과적으로 유도할 수 있으며, 이는 DSDM 또는 해당 시스템 개발 프로젝트의 주요 성공 요인 중 하나이다.
  • 테스팅: 양질의 솔루션을 보장하는 데 도움이 되며, DSDM은 각 반복 과정에서 테스팅을 권장한다. DSDM은 도구와 기술에 독립적인 방법이므로, 프로젝트 팀은 자체 테스트 관리 방법을 자유롭게 선택할 수 있다.
  • 워크숍: 프로젝트 관계자들이 모여 요구 사항, 기능 및 상호 이해에 대해 논의한다.
  • 시스템 모델링: 비즈니스 영역을 시각화하고 이해도를 높이는 데 도움이 된다. 개발 중인 시스템 또는 비즈니스 영역의 특정 측면을 그림으로 표현한다.
  • 형상 관리: 여러 결과물이 동시에 개발되고 각 타임박스 종료 시 점진적으로 제공되므로, 결과물을 완성될 때까지 잘 관리해야 한다.

3. 3. 역할

DSDM 환경에는 여러 역할이 도입되어 있다. 프로젝트 구성원은 프로젝트를 시작하기 전에 각 역할에 지정되어야 하며, 각 역할은 고유한 책임을 갖는다. 역할은 다음과 같다.

  • '''최고 후원자''' (프로젝트 챔피언): 적절한 자금과 자원을 할당할 수 있는 능력과 책임을 가진 사용자 조직의 중요한 역할로, 최종 의사 결정 권한을 갖는다.[1]
  • '''비저너리''': 필수 요구 사항을 초기에 발견하여 프로젝트를 초기화하는 책임을 맡는다. 시스템 및 프로젝트의 비즈니스 목표에 대한 가장 정확한 인식을 갖고 있으며, 개발 프로세스를 감독하고 올바른 방향으로 유지하는 과제를 수행한다.[1]
  • '''대사 사용자''': 사용자 커뮤니티의 지식을 프로젝트에 가져오고, 개발자가 개발 과정에서 충분한 사용자 피드백을 받도록 한다.[1]
  • '''자문 사용자''': 중요한 관점을 나타내고 프로젝트에 대한 일상적인 지식을 제공하는 모든 사용자가 될 수 있다.[1]
  • '''프로젝트 관리자''': 사용자 커뮤니티 또는 IT 직원의 일원으로서, 일반적으로 프로젝트를 관리한다.[1]
  • '''기술 코디네이터''': 시스템 아키텍처를 설계하고 프로젝트의 기술적 품질을 관리하는 역할을 한다.[1]
  • '''팀 리더''': 팀을 이끌고 팀 전체가 효과적으로 작동하도록 보장한다.[1]
  • '''솔루션 개발자''': 시스템 요구 사항을 해석하고, 프로토타입 구축을 포함하여 이를 모델링한다.[1]
  • '''솔루션 테스터''': 테스트를 수행하여 기술적 범위 내에서 정확성을 확인하고, 필요한 경우 결함을 제기하고 수정된 후 다시 테스트한다. 테스터는 의견과 문서를 제공해야 한다.[1]
  • '''서기''': 워크숍에서 이루어진 요구 사항, 합의 및 의사 결정을 수집하고 기록하는 역할을 한다.[1]
  • '''진행자''': 워크숍의 진행 상황을 관리하고, 준비 및 의사 소통의 동기 부여 역할을 한다.[1]
  • '''전문가 역할''': 비즈니스 아키텍트, 품질 관리자, 시스템 통합자 등이 있다.[1]

3. 4. 성공 요인

DSDM에서 성공적인 프로젝트를 보장하기 위해 중요하다고 판단되는 요인은 다음과 같다.

  • 요인 1: 고위 경영진 및 기타 직원의 DSDM 수용. 이는 프로젝트의 다양한 주체가 처음부터 동기를 가지고 프로젝트 전체에 참여하도록 보장한다.
  • 요인 2: 요인 1에서 직접적으로 파생되는 것으로, 최종 사용자 참여를 보장하기 위한 경영진의 노력이다. 프로토타입 접근 방식은 최종 사용자가 기능적 프로토타입을 테스트하고 판단하기 위해 적극적이고 헌신적으로 참여해야 한다.
  • 요인 3: 프로젝트 팀은 안정적인 연합을 형성하는 숙련된 구성원으로 구성되어야 한다. 중요한 문제는 프로젝트 팀의 권한 부여이다. 이는 팀 (또는 팀 구성원 중 한 명 이상)이 상위 경영진에게 공식적인 제안서를 작성할 필요 없이 프로젝트와 관련된 중요한 결정을 내릴 수 있는 권한과 가능성을 가져야 함을 의미하며, 이는 매우 시간이 오래 걸릴 수 있다. 프로젝트 팀이 성공적인 프로젝트를 수행할 수 있도록 하기 위해서는 프로젝트를 수행하기 위한 적절한 기술, 즉 개발 환경, 프로젝트 관리 도구 등이 필요하다.
  • 요인 4: 마지막으로, DSDM은 고객과 공급업체 간의 지원적인 관계가 필요하다고 명시한다. 이는 회사 내부 또는 외부 계약자에 의해 실현되는 모든 프로젝트에 적용된다. 지원적인 관계를 보장하는 데 도움이 될 수 있는 것은 ISPL이다.

4. 다른 개발 프레임워크와의 비교

DSDM은 애자일 소프트웨어 개발객체 지향 프로그래밍 방식을 지원하는 광범위한 반복적이고 점증적인 개발 프레임워크의 일부로 간주될 수 있다. 여기에는 스크럼, 익스트림 프로그래밍(XP), 훈련된 애자일 전달(DAD), 래셔널 유니파이드 프로세스(RUP) 등이 포함된다.[5]

DSDM과 다른 개발 프레임워크의 공통점은 다음과 같다.


  • 모두 요구 사항의 우선 순위를 정하고 반복적으로 처리하여 시스템 또는 제품을 점진적으로 구축한다.
  • 도구 독립적인 프레임워크이다. 이를 통해 사용자는 원하는 고유한 기술 및 소프트웨어 지원으로 프로세스의 특정 단계를 채울 수 있다.
  • 개발의 변수는 시간/자원이 아니라 요구 사항이다. 이 접근 방식은 DSDM의 주요 목표, 즉 마감일과 예산을 준수하도록 보장한다.
  • 시스템의 모든 이해 관계자 간의 의사 소통과 참여에 중점을 둔다. 이는 다른 방법에서도 다루어지지만, DSDM은 성공적인 결과를 보장하기 위해 프로젝트에 대한 헌신을 강력하게 믿는다.

참조

[1] 간행물 Agile project management: running PRINCE2 projects with DSDM Atern https://agilekrc.com[...] OGC – Office of Government Commerce. The Stationery Office 2007-07-31
[2] 논문 UX Design in Agile: A DSDM Case Study Springer International Publishing 2014
[3] 논문 New directions on agile methods: a comparative analysis http://secure.com.sg[...] Ieee 2003
[4] 서적 Business Focused Development Pearson Education 2003-01
[5] 서적 Managing Agile Springer 2015-03
[6] 문서 The DSDM Agile Project Framework manual 2014
[7] 웹사이트 http://www.dsdm.org
[8] 웹사이트 The DSDM Agile Project Framework (2014 Onwards) https://www.agilebus[...] 2016-02-04
[9] 웹사이트 atern-template-complete-set https://www.agilebus[...]
[10] 웹사이트 Agile's DSDM Consortium evolves into Agile Business Consortium https://pressdispens[...]
[11] 웹사이트 Terms and Conditions of Community Membership https://globalgapfil[...] GLOBAL G.A.P
[12] 웹사이트 The DSDM Agile Project Framework (2014 Onwards) Handbook – Principles https://www.agilebus[...] Agile Business Consortium
[13] 간행물 Agile project management: running PRINCE2 projects with DSDM Atern https://agilekrc.com[...] OGC – Office of Government Commerce. The Stationery Office 2007-07-31
[14] 논문 UX Design in Agile: A DSDM Case Study Springer International Publishing 2014
[15] 논문 New directions on agile methods: a comparative analysis http://secure.com.sg[...] Ieee 2003
[16] 서적 Business Focused Development https://archive.org/[...] Pearson Education 2003-01



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com