기능 중심 개발

Feature-driven development
다음에 대한 시리즈 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
연습
도구들
지식의 표준 및 본문
용어집
윤곽선

FDD(Feature-Driven Development)는 반복적이고 점진적인 소프트웨어 개발 프로세스다. 경량[according to whom?] 또는 애자일 방식으로 소프트웨어를 개발한다. FDD는 업계에서 인정하는[according to whom?] 다수의 모범 사례를 통합적인 전체로 혼합한다. 이러한 관행은 클라이언트 가치 기능성(기능성) 관점에서 추진된다[clarification needed]. 그것의 주요 목적은[according to whom?] 민첩한 매니페스토의 원칙에 따라 적시에 반복적으로 유형적이고 작동하는 소프트웨어를 제공하는 것이다.[1]

역사

FDD는 제프 드 루카가 1997년 싱가포르의 한 대형 은행에서 15개월 50인 소프트웨어 개발 프로젝트의 구체적인 요구를 충족시키기 위해 처음 고안한 것이다. 이로 인해 전체 모델의 개발과 기능의 나열, 계획, 설계 및 구축에 적용되는 다섯 가지 프로세스가 나왔다. 첫 번째 과정은 물체 모델링에 대한 피터 코드의 접근법에 의해 많은 영향을 받는다. 두 번째 프로세스에는 기능 요구 사항과 개발 작업을 관리하기 위해 기능 목록을 사용하는 코드의 아이디어가 통합되어 있다. 다른 과정들은 제프 드 루카의 경험의 결과물이다. FDD가 싱가포르 프로젝트에 성공적으로 사용된 이후 여러 차례 구현되었다.

FDD에 대한 설명은 1999년 피터 코아드, 에릭 르페브르, 제프 드 루카의 UML로[1] 색칠한 자바 모델링 책 6장에서 처음 세상에 소개되었다. 이후 Stephen Palmer와 Mac Felsing의 저서 특성 주도적 개발을[2] 위한 실용적 가이드(2002년 출판)에서 FDD에 대한 보다 일반적인 설명이 자바 모델링에서 분리되었다.

개요

FDD는 5가지 기본 활동으로 구성된 모델 중심의 단시간 반복 과정이다. 소프트웨어 개발 프로젝트의 정확한 상태 보고 및 추적을 위해 각 기능의 진행 상황을 표시하는 이정표를 정의한다. 이 섹션은 활동에 대한 높은 수준의 개요를 제공한다. 오른쪽 그림에는 이러한 활동에 대한 메타 프로세스 모델이 표시된다. 처음 두 개의 순차적 활동 동안 전체적인 모델 모양이 설정된다. 각 특징에 대해 최종 세 가지 활동을 반복한다.

FDD 프로세스 모델

전체 모델 개발

FDD 프로젝트는 시스템의 범위와 그 맥락에 대한 높은 수준의 워크스루로 시작한다. 다음으로, 각 모델링 영역에 대해 소그룹에 의해 상세한 도메인 모델이 생성되어 안전 점검용으로 제시된다. 제안된 모델 중 하나 이상이 각 도메인 영역에 대한 모델이 되도록 선택된다. 도메인 영역 모델은 전체 모델에 점진적으로 통합된다.

기능 목록 작성

초기 모델링에서 수집된 지식은 도메인을 대상 영역으로 기능적으로 분해하여 특징 목록을 식별하는 데 사용된다. 주제 영역은 각각 비즈니스 활동을 포함하며, 각 비즈니스 활동 내의 단계는 범주화된 특징 목록의 기초를 형성한다. 이 점에서 특징들은 '판매 총액 계산' 또는 '사용자의 비밀번호 검증'과 같은 "<행동> <결과> <객체>" 형식으로 표현되는 클라이언트 가치 함수의 작은 조각들이다. 기능을 완료하는 데 2주 이상 걸리지 않아야 하며, 그렇지 않으면 작은 조각으로 분해해야 한다.

기능별 계획

피쳐 리스트가 완료된 후, 다음 단계는 개발 계획을 작성하고 피쳐(또는 피쳐 세트)의 소유권을 프로그래머에게 클래스로 할당하는 것이다.

형상별 설계

각 특징에 대한 디자인 패키지가 제작된다. 수석 프로그래머는 2주 이내에 개발될 기능들의 소그룹을 선택한다. 수석 프로그래머는 해당 클래스 소유자와 함께 각 기능에 대한 상세 시퀀스 다이어그램을 작성하고 전체 모델을 다시 작성한다. 다음으로 등급 및 방법 프롤로그를 작성하고 마지막으로 설계점검을 실시한다.

피쳐별 빌드

기능 제작을 위한 각 활동에 대한 성공적인 설계 검사를 계획한 후, 클래스 소유자는 자신의 클래스에 대한 코드를 개발한다. 유닛 테스트와 코드 검사 성공 후 완성된 기능을 메인 빌드로 승격한다.

이정표

피쳐가 작기 때문에 피쳐를 완성하는 것은 상대적으로 작은 작업이다. 소프트웨어 개발 프로젝트의 정확한 상태 보고 및 추적 작업을 위해서는 각 기능에 대한 진행 상황을 표시하는 것이 중요하다. 따라서 FDD는 순차적으로 완료해야 하는 형상당 6개의 이정표를 정의한다. 처음 3개의 이정표는 특성별 설계 활동 중에 완료되고, 마지막 3개는 특성별 빌드 활동 중에 완료된다. 진행률을 추적하기 위해 각 마일스톤에 완료 백분율을 할당한다. 아래 표에는 이정표와 그 완료율이 표시되어 있다. 코딩이 시작되는 시점에서는 기능이 이미 44% 완료되었다(도메인 워크스루 1%, 디자인 40%, 디자인 검사 3% = 44%)

표 1: 이정표
도메인 워크스루 디자인 설계 검사 코드 코드 검사 구축으로 승격
1% 40% 3% 45% 10% 1%

모범 사례

기능 중심의 개발은 고객 가치의 기능 관점을 목표로 하는 소프트웨어 엔지니어링 모범 사례의 핵심 세트를 기반으로 구축된다.

  • 도메인 개체 모델링. 도메인 오브젝트 모델링은 해결해야 할 문제의 도메인을 탐색하고 설명하는 것으로 구성된다. 결과 도메인 오브젝트 모델은 형상을 추가하는 전체적인 프레임워크를 제공한다.
  • 기능별 개발. 너무 복잡하여 2주 이내에 구현할 수 없는 기능은 각각의 하위 문제가 특징이라고 불릴 만큼 작을 때까지 더 작은 기능으로 분해된다. 이것은 정확한 기능을 전달하고 시스템을 확장하거나 수정하는 것을 더 쉽게 한다.
  • 개별 클래스(코드) 소유권. 개별 클래스 소유권은 코드의 구별되는 부분이나 그룹이 단일 소유자에게 할당되는 것을 의미한다. 소유자는 클래스의 일관성, 성능 및 개념적 무결성에 대한 책임을 진다.
  • 피쳐 팀. 피처팀은 작은 활동을 전개하는 작고 역동적으로 구성된 팀이다. 각 설계 결정에는 항상 여러 개의 마음이 적용되며, 한 가지를 선택하기 전에 여러 설계 옵션을 평가한다.
  • 검사. 품질설계와 코드는 주로 결함의 검출에 의해 품질의 우수성을 확보하기 위해 검사를 실시한다.
  • 구성 관리. 구성 관리는 현재까지 완료된 모든 기능에 대한 소스 코드를 식별하고 피쳐 팀이 강화함에 따라 클래스에 대한 변경 이력을 유지하는 데 도움이 된다.
  • 일반 빌드. 정기적인 빌드는 항상 고객에게 시연할 수 있는 최신 시스템이 존재함을 보장하며, 기능의 소스 코드의 통합 오류를 조기에 강조하는데 도움이 된다.
  • 진행 상황 및 결과의 가시성. 관리자는 완료된 작업을 기반으로 프로젝트 내외부의 모든 단계에서 빈번하고 적절하며 정확한 진행 상황 보고를 사용하여 프로젝트를 관리한다.

메타모델(메타모델링)

FDD 프로세스 데이터 모델

변형은 방법의 프로세스와 데이터를 모두 시각화하는 데 도움이 된다. 이를 통해 방법을 비교할 수 있으며, 방법 엔지니어링 프로세스의 방법 파편도 쉽게 재사용할 수 있다. 이 기법의 사용은 UML 표준과 일치한다.

메타데이터 모델의 왼쪽은 FDD를 이용한 소프트웨어 개발 프로젝트에 관련된 5가지 기본 활동을 보여준다. 모든 활동은 FDD 프로세스 설명서의 하위 활동에 해당하는 하위 활동을 포함한다. 모델의 오른쪽은 관련된 개념을 보여준다. 이러한 개념은 다이어그램의 왼쪽에서 묘사된 활동에서 비롯된다.

참고 항목

참조

  1. ^ "Principles behind the Agile Manifesto". 2019-06-11.
  • 1. ^Coad, P, 르페브르, E. & De Luca, J. (1999년) UML을 사용한 Java 모델링: 엔터프라이즈 구성요소 및 프로세스. 프렌티스 홀 인터내셔널 (ISBN0-13-011510-X)
  • 2. ^ 팔머, S.R., & 펠싱, J.M. (2002) 기능 중심 개발에 대한 실제 가이드. 프렌티스 홀. (ISBN 0-13-067615-2)

외부 링크