동적 시스템 개발 방법

Dynamic systems development method
DSDM 프로젝트 관리 방법의 모델.
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

DSDM(Dynamic Systems Development Method)은 신속한 변화를 위한 프로젝트 제공 프레임워크로, 처음에는 소프트웨어 [1][2]개발 방법으로 사용됩니다.1994년에 처음 출시된 DSDM은 원래 신속한 애플리케이션 개발([3]RAD) 방식에 대한 몇 가지 규율을 제공하고자 했습니다.이후 버전에서는 DSDM Agile Project Framework가 개정되어 소프트웨어 개발 및 코드[clarification needed][citation needed] 작성에 초점을 맞춘 것이 아니라 프로젝트 관리와 솔루션 제공에 대한 일반적인 접근 방식이 되었습니다.또, IT프로젝트 [4]이외의 프로젝트에도 사용할 수 있었습니다.DSDM Agile Project Framework는 프로젝트 라이프사이클 전체에 걸쳐 광범위한 활동을 포괄하며 강력한 기반과 거버넌스를 포함하고 있어 다른 Agile 방식과 [5]차별화됩니다.DSDM Agile Project Framework는 사용자/고객의 지속적인 참여를 포함하여 Agile 개발 원칙을 수용하는 반복적이고 증분적인 접근 방식입니다.

DSDM은 처음에 비용, 품질 및 시간을 수정하고 MoSCoW의 적용범위를 필수, 필요, 가능 및 불가능으로 분류하여 지정된 시간 제약을 충족하도록 프로젝트 성과물을 조정할 수 없습니다.DSDM은 소프트웨어 및 비 IT 솔루션을 개발하기 위한 여러 가지 신속한 변화를 위한 방법 중 하나로, 신속한 변화를 위한 제휴의 일부를 구성합니다.

2014년 DSDM은 'DSDM Agile Project Framework'에서 최신 버전의 방법을 발표했습니다.동시에 새로운 DSDM 매뉴얼은 서비스 제공(특히 ITIL) PRINCE2, 성공적인 프로그램 관리 및 PMI를 [6]위한 다른 프레임워크와 함께 운영해야 할 필요성을 인식했습니다.이전 버전(DSDM 4.2)에는 극한 프로그래밍에서 DSDM을 사용하는 방법에 대한 지침만 포함되어 있었습니다.

DSDM의 역사

1990년대 초반에는 IT업계 전반에 걸쳐 신속한 애플리케이션 개발(RAD)이 확산되었습니다.소프트웨어 애플리케이션의 사용자 인터페이스는 기존의 녹색 화면에서 오늘날 사용되는 그래픽 사용자 인터페이스로 이동했습니다.PowerBuilder와 같은 새로운 애플리케이션 개발 툴이 시장에 출시되었습니다.이를 통해 개발자는 제안된 솔루션을 훨씬 더 쉽게 고객과 공유할 수 있게 되었습니다. 프로토타이핑이 현실화되었고 기존의 순차적(워터폴) 개발 방식에 대한 좌절감이 사라졌습니다.

그러나 RAD의 움직임은 매우 구조화되지 않았습니다.적절한 프로세스에 대해 일반적으로 합의된 정의는 없었고, 많은 조직이 독자적인 정의와 접근방식을 생각해 냈습니다.많은 대기업은 그 가능성에 매우 관심을 가지고 있었지만, 자유 흐름의 개발이 가져올 수 있는 최종 성과물의 품질을 잃지 않았다는 점도 우려했다.

DSDM 컨소시엄은 1994년 소프트웨어 엔지니어링 분야의 벤더와 전문가 협회에 의해 설립되었으며, 베스트 프랙티스 경험을 결합하여 "독립적인 RAD 프레임워크의 공동 개발 및 추진"을 목적으로 설립되었습니다.그 기원은 런던의 버틀러 그룹에 의해 조직된 행사였다.이 회의에 참석한 사람들은 모두 British Airways, American Express, Oracle, Logica와 같은 우량 조직에서 일했습니다(데이터 사이언스, Allied Domecq와 같은 다른 회사는 이후 다른 조직에 흡수되었습니다).

2006년 7월에 DSDM Public Version 4.2가[7] 개인이 열람 및 사용할 수 있게 되었습니다.단, DSDM을 재판매하는 사람은 비영리 컨소시엄의 회원이어야 합니다.

2014년에는 DSDM 핸드북이 온라인 및 [8]일반에 공개되었습니다.또한 DSDM용 템플릿을 다운로드할 [9]수 있습니다.

2016년 10월 DSDM Consortium은 Agile Business Consortium(ABC)[10]으로 재브랜드되었습니다.Agile Business Consortium은 DSDM [11]프레임워크를 소유하고 관리하는 비영리 벤더 독립 조직입니다.

DSDM

DSDM은 벤더에 의존하지 않는 접근법으로, 기술보다 더 많은 프로젝트가 사람의 문제로 인해 실패한다는 것을 인식합니다.DSDM은 사람들이 비즈니스 목표를 달성하기 위해 효과적으로 협력할 수 있도록 지원하는 데 중점을 두고 있습니다.또한 DSDM은 툴과 기술에 의존하지 않으므로 특정 [8]벤더와 비즈니스를 연결하지 않고도 비즈니스 및 기술 환경에서 사용할 수 있습니다.

원칙

DSDM을 [12]뒷받침하는 8가지 원칙이 있습니다.이러한 원칙은 일관성 있는 전달을 위해 팀이 취해야 할 태도와 채택해야 할 사고방식을 지시합니다.

  1. 비즈니스 요구에 집중
  2. 정시에 납품하다
  3. 콜라보레이션
  4. 품질 저하 없음
  5. 견고한 기반에서 점진적으로 구축
  6. 반복적으로 개발하다
  7. 지속적이고 명확한 커뮤니케이션
  8. 제어 시연

핵심 기술

  • 타임박스: 프로젝트를 여러 부분으로 분할하여 단계적으로 완성하는 접근법입니다.각각은 고정 예산과 납기일이 정해져 있습니다.각 부분에 대해 많은 요건이 우선시되고 선택된다.시간과 예산은 고정되어 있기 때문에 남은 변수는 요건뿐입니다.따라서 프로젝트의 시간이나 비용이 부족할 경우 우선순위가 가장 낮은 요건은 생략됩니다.프로젝트의 80%가 시스템 요건의 20%에서 나온다는 Pareto 원칙 때문에 미완성 제품이 납품되는 것은 아닙니다.따라서 가장 중요한 요건의 20%가 시스템에 구현되는 한 시스템은 비즈니스 요구를 충족시키고 한 번에 완벽하게 구축되는 시스템은 없습니다.
  • MoSCoW: 작업 항목 또는 요구 사항에 우선순위를 부여하는 기술입니다.다음 약어입니다.
    • 가져야만 한다
    • 했어야 했는데
    • 할 수 있었을지도 모른다
    • 없다
  • 프로토타이핑: 프로젝트의 초기 단계에서 개발 중인 시스템의 프로토타입을 만드는 것을 말합니다.시스템의 단점을 조기에 발견할 수 있으며 향후 사용자가 시스템을 '시승'할 수 있습니다.이를 통해 DSDM의 주요 성공 요인 중 하나 또는 이와 관련된 시스템 개발 프로젝트의 우수한 사용자 참여를 실현할 수 있습니다.
  • 테스트: 우수한 품질의 솔루션을 보장하는 데 도움이 됩니다.DSDM은 매번 테스트를 권장합니다.DSDM은 툴과 기술에 의존하지 않는 방법이기 때문에 프로젝트 팀은 자체 테스트 관리 방법을 자유롭게 선택할 수 있습니다.
  • 워크숍: 프로젝트 관계자를 한자리에 모아 요건, 기능 및 상호 이해에 대해 논의합니다.
  • 모델링: 비즈니스 영역을 시각화하고 이해도를 높이는 데 도움이 됩니다.개발 중인 시스템 또는 비즈니스 영역의 특정 측면을 도식으로 표현합니다.
  • 구성 관리: 여러 성과물이 동시에 개발 중이며 각 타임박스 끝에 점진적으로 제공되므로 성과물은 완성될 때까지 적절하게 관리되어야 합니다.

역할

DSDM 환경에는 몇 가지 역할이 도입되어 있습니다.프로젝트를 시작하기 전에 프로젝트 구성원을 다른 역할로 임명해야 합니다.각각의 역할은 각자의 책임이 있다.역할은 다음과 같습니다.

  • 이그제큐티브 스폰서:프로젝트 챔피언이라고 하죠적절한 자금과 자원을 투입할 수 있는 능력과 책임을 가진 사용자 조직의 중요한 역할.이 역할은 결정을 내릴 수 있는 궁극적인 힘을 가지고 있습니다.
  • 비전:중요한 요건을 조기에 발견하여 프로젝트를 초기화할 책임이 있는 사람.Visionary는 시스템 및 프로젝트의 비즈니스 목표를 가장 정확하게 인식하고 있습니다.또 다른 과제는 개발 과정을 감독하고 올바른 방향으로 유지하는 것입니다.
  • 앰배서더 사용자: 프로젝트에 사용자 커뮤니티에 대한 지식을 도입하여 개발 프로세스 중에 개발자가 충분한 사용자 피드백을 받을 수 있도록 합니다.
  • 어드바이저 사용자: 중요한 관점을 나타내며 프로젝트에 대한 일상적인 지식을 제공하는 모든 사용자일 수 있습니다.
  • 프로젝트 매니저: 프로젝트를 일반적으로 관리하는 사용자 커뮤니티 또는 IT 스태프 중 누구라도 상관없습니다.
  • 기술 조정자:시스템 아키텍처 설계 및 프로젝트 기술 품질 관리 담당
  • 팀장: 팀을 이끌고 팀 전체가 효율적으로 일할 수 있도록 합니다.
  • 솔루션 개발자:성과물 코드 개발 및 프로토타입 제작을 포함하여 시스템 요구 사항을 해석하고 모델링합니다.
  • 솔루션 테스터:일부 테스트를 수행하여 기술적 범위의 정확성을 점검하고, 필요한 경우 결함을 제기하고, 수리된 후 다시 테스트합니다.테스터는 몇 가지 의견과 문서를 제공해야 합니다.
  • 스크라이브: 모든 워크숍에서 이루어진 요건, 계약 및 결정을 수집하고 기록할 책임이 있습니다.
  • 퍼실리테이터:워크숍의 진행 상황을 관리할 책임이 있으며, 준비와 의사소통의 동기 부여 역할을 합니다.
  • 스페셜리스트 역할:비즈니스 아키텍트, 품질 매니저, 시스템 인테그레이터 등

중요한 성공 요인

DSDM에서는 프로젝트의 성공을 보증하기 위해 매우 중요한 요소가 다수 포함되어 있습니다.

  • 요인 1: 첫째, 고위 경영진과 다른 직원들이 DSDM을 수용하는 것입니다.이를 통해 프로젝트의 다른 액터들이 처음부터 동기부여를 받고 프로젝트 내내 관여할 수 있습니다.
  • 요인 2: 요인 1에서 직접 도출된: 최종 사용자의 참여를 보장하기 위한 경영진의 약속.프로토타이핑 접근 방식은 기능성 프로토타입을 테스트하고 판단하기 위해 최종 사용자의 강력하고 헌신적인 참여가 필요합니다.
  • 요소 3: 프로젝트 팀은 안정적인 조합을 형성하는 숙련된 구성원으로 구성되어야 합니다.중요한 문제는 프로젝트 팀의 역량 강화입니다.즉, 팀(또는 팀원 중 1명 또는 여러 명)은 경영진에게 공식적인 제안서를 작성할 필요 없이 프로젝트에 관한 중요한 결정을 내릴 수 있는 권한과 가능성을 보유해야 합니다.이는 시간이 많이 걸릴 수 있습니다.프로젝트 팀이 프로젝트를 성공적으로 실행할 수 있도록 하기 위해서는 프로젝트를 수행하기 위한 적절한 기술도 필요합니다.개발환경, 프로젝트 관리도구 등을 의미합니다.
  • 요인 4: 마지막으로 DSDM은 고객과 벤더 간의 지원적인 관계가 필요하다고 말합니다.이는 기업 내부 또는 외부 계약자에 의해 실현되는 두 프로젝트 모두에 해당됩니다.ISPL이 지원 관계를 보장하는 데 도움이 될 수 있습니다.

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

DSDM은 특히 민첩하고 객체 지향적인 방법을 지원하는 광범위한 반복 및 증분 개발 프레임워크의 일부로 간주할 수 있습니다.여기에는 스크럼, Extreme Programming(XP; 익스트림 프로그래밍), 규율된 신속한 변화를 위한 전달(DAD) 및 RUP(Rational Unified Process)가 포함됩니다.

DSDM과 마찬가지로 이러한 기능에는 다음과 같은 특징이 있습니다.

  • 이들은 모두 요건에 우선순위를 부여하고 반복적으로 작업하여 시스템 또는 제품을 단계적으로 구축합니다.
  • 툴에 의존하지 않는 프레임워크입니다.이를 통해 사용자는 자신이 선택한 기술과 소프트웨어 보조 도구로[5] 프로세스의 특정 단계를 입력할 수 있습니다.
  • 개발 변수는 시간/리소스가 아니라 요건입니다.이 접근방식을 통해 DSDM의 주요 목표, 즉 기한과 예산 내에 머무르는 것이 보증됩니다.
  • 시스템 내 모든 이해관계자 간의 커뮤니케이션과 관여에 중점을 둔다.이 문제는 다른 방법으로 해결되지만 DSDM은 성공적인 결과를 보장하기 위해 프로젝트에 전념할 것을 강력히 믿고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Keith Richards, Agile 프로젝트 관리: DSDM Atern과 함께 PRINCE2 프로젝트를 실행합니다.OGC – 정부 상업 사무소.문방구 사무실, 7월 31일2007.
  2. ^ 플로카, 로라 등"신속한 UX 설계: DSDM 사례 연구"소프트웨어 엔지니어링 및 Extreme Programming의 신속한 변화를 위한 프로세스.Springer International Publishing, 2014.1-15.
  3. ^ 아브라함슨, 페카 등"신속한 방법에 대한 새로운 방향: 비교 분석"Software Engineering, 2003.의사진행동.제25회 국제회의 개최.IEEE, 2003.
  4. ^ Stapleton, Jennifer (January 2003). Business Focused Development. Pearson Education. p. 113. ISBN 9780321112248.
  5. ^ a b Moran, Alan (March 2015). Managing Agile. Springer. pp. 21–24. ISBN 9783319162614.
  6. ^ DSDM 신속한 변화를 위한 프로젝트 프레임워크 매뉴얼, 2014년 4, 16페이지
  7. ^ (www.dsdm.org Wayback Machine에서 2016-10-02 아카이브 완료)
  8. ^ a b "The DSDM Agile Project Framework (2014 Onwards)". Agile Business Consortium. February 4, 2016.
  9. ^ www.agilebusiness.org https://www.agilebusiness.org/resources/templates-and-tools/atern-template-complete-set. {{cite web}}:누락 또는 비어 있음 title=(도움말)
  10. ^ "Agile's DSDM Consortium evolves into Agile Business Consortium". Press Dispensary.
  11. ^ "Terms and Conditions of Community Membership" (PDF). DSDM Consortium. Retrieved 7 March 2013.
  12. ^ 신속한 변화를 위한 비즈니스 컨소시엄.DSDM 신속한 변화를 위한 프로젝트 프레임워크(2014년 이후) 핸드북 - 원칙.

추가 정보

외부 링크

Wikimedia Commons에는 동적 시스템 개발 방법과 관련된 미디어가 있습니다.