SMART 프로세스 가속화 개발 환경

이 문서에는 여러 가지 문제가 있습니다.개선을 돕거나 토크 페이지에서 이러한 문제에 대해 논의해 주십시오.(이러한 템플릿메시지를 삭제하는 방법과 타이밍에 대해 설명합니다) 이 글은 검증을 위해 추가 인용문이 필요합니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 : 'SMART 프로세스 가속화 개발 환경'– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2016년 6월) (이 템플릿 메시지 삭제 방법 및 삭제 시기 확인) 이 문서의 주제는 위키피디아의 일반적인 알림 가이드라인을 충족하지 못할 수 있습니다. 주제와는 무관하고 단순한 언급을 넘어 상당한 내용을 다루는 신뢰할 수 있는 2차 출처를 인용함으로써 주제 인지도를 입증할 수 있도록 도와주시기 바랍니다. 알림을 표시할 수 없는 경우 문서가 병합, 리디렉션 또는 삭제될 수 있습니다.출처 : 'SMART 프로세스 가속화 개발 환경'– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2020년 10월) (이 템플릿 메시지 삭제 방법 및 삭제 시기 확인) 이 글은 광고처럼 쓰여진 내용을 담고 있습니다. 판촉 내용 및 부적절한 외부 링크를 삭제하고 중립적인 관점에서 작성된 백과사전 내용을 추가하여 개선해 주십시오. (2020년 10월) (템플릿 메시지 삭제 방법 및 시기 확인) (이 템플릿메시지를 삭제하는 방법과 타이밍을 확인합니다)

SPADE(SMART Process Acceleration Development Environment)는 소프트웨어 개발 생산성 및 품질 향상 도구이며, 짧은 시간 동안 적은 노력으로 전문적인 소프트웨어를 만들 때 사용됩니다.그림에서 보듯이 SPADE(녹색 아이콘)는 소프트웨어 개발 프로세스의 많은 수동 작업을 자동화합니다.따라서 전체 소프트웨어 개발 주기를 수행하는 데 시간과 노력이 덜 듭니다.

SPADE를 사용하는 나머지 수동 단계는 다음과 같습니다.

• 요구 사항: 고객의 요구를 수렴하여 명확한 요건이나 사용자 사례 등으로 문서화합니다.
• 테스트 케이스: 테스트 중에 자동으로 실행되는 통합 테스트 케이스를 만듭니다.
• 테스트: 조작성 테스트 및 외부(SPADE 이외) 시스템과의 통합 테스트.
• 동의: 생성된 솔루션 수락

다른 단계 스마트 요구 사항(비즈니스) 요구 사항 2.0.1]를 사용하여 설계 및 종속 알고리듬의 설계 및 종속 알고리듬에 최적화되어 있다.- 아니, 엑스테네요이 비즈니스 프로세스의 일부인 비액티브하고 완전히 자동화된 단계입니다.

SPADE는 복잡한 정보처리 시스템과 단순한 정보처리 시스템 모두에 적합한 도메인별 모델 기반 소프트웨어 개발 도구입니다.현재는 실시간 또는 고급 그래피컬 사용자 인터페이스에서 하드웨어를 제어할 수 있는 소프트웨어를 만드는 데 적합하지 않습니다.그러나 SPADE에 의해 생성되지 않은 기능에 액세스하기 위한 플러그인을 추가할 수 있습니다.

세부 사항

SMART Requirements 2.0 방법의^[1] 일부인 언어 SMART^[1] 표기법을 사용하여 명확한 요건을 작성하는 방법에 대해 설명한 후 이러한 요건에서 SPADE가 자동으로 생성되는 방법과 내용을 설명합니다.또, 테스트 케이스의 작성과 실행, 및 SPADE에 의해서 작성되는 소프트웨어 솔루션의 전형적인 아키텍처에 대해서도 설명합니다.

명확한 요건 작성

SPADE의 입력 내용은 최종 결과 지향 비즈니스 요구사항 사양입니다.이하에 대해 설명합니다.

'뭐야'	프로세스가 생성해야 하는 바람직한 결과입니다.
'언제'	원하는 결과를 얻을 수 있습니다.즉, 생산해야 하는 조건입니다.
'어디'	그 정보는 에서 나온다.이것은 이용 가능한 정보, 계산 또는 사람일 수 있습니다.

이 정보는 문서(일반적으로 어떤 종류의 파일)에 저장되며 정식 사양 언어를 사용하여 기록됩니다.다음은 회색으로 표시된 예시와 이탤릭체로 된 설명을 나타냅니다.

프로세스와 프로세스에서 가장 중요한 정보를 대상으로 하는 것부터 시작합니다.

제목 #('Order': ORDER)를 사용하여 '제품 주문'을 처리합니다.

개괄적인 결과를 정리합니다.큰따옴표는 요건을 정의하고 결과 지향적인 세분화 구조를 작성하는 데 사용됩니다.

'고객님이 제품을 주문하셨습니다', '승인된 경우 고객님께 청구서가 있습니다', '필요에 따라 주문을 승인해야 합니다'가 해당됩니다.

요건을 명확하게 정의한다.if-then-else를 사용하여 '언제' 결과를 적용하거나 생성해야 하는지 정의합니다.정보의 출처'는 참조를 사용하여 정의됩니다.예를 들어 ORDER.approved는 프로세스 중에 생성되거나 이미 사용 가능한 정보 중 하나입니다.일부 요구사항(결과)은 시각적으로 지정할 수 있습니다.오른쪽에는 "고객이 청구서를 가지고 있습니다"가 전자 메일로 지정되어 있습니다.

"승인된 경우 고객에게는 청구서가 있습니다." = ORDER.approved의 경우 "고객에게는 청구서가 있습니다." = "필요한 경우 주문을 승인해야 합니다." = "주문이 너무 비쌉니다." 그렇지 않은 경우 "주문서를 승인해야 합니다." = "너무 비쌉니다." = ORDER.approved.to > 500

또한 사용자는 'input from' 뒤에 이 사람 또는 실제 사용자의 역할을 식별하는 이름을 입력하여 정보원이 될 수 있습니다.아래 예에서는 CONTROLER 역할을 가진 사람이 있습니다.이러한 담당자가 이 입력을 하기 위해 정보가 필요한 경우, 이 입력은 특정 다른 정보를 '기반'으로 제공할 수 있음을 명시해야 합니다.이 경우, 구매자 및 주문의 LINEs 날짜입니다.

"주문이 승인되어야 합니다." = ORDER.approved = #(ORDER.date, ORDER)에 기반한 CONTROLER로부터의 입력.구매자님, 주문해주세요.회선)

시스템 사용 시 입력을 제공하는 실제 사용자(현재 사용자)도 정보로 사용할 수 있습니다.다음 예시는 ORDER와 그 Atribute를 정의하고 있습니다.하나는 속성이 구매자(BUYER)라고 불리며 실제 고객(실제 프로세스 실행 시)으로 채워지는 경우, 즉 입력을 제공합니다.

"고객이 제품을 주문했습니다" = 주문에 한 개의 주문이 있습니다. 날짜 = currentDate() BUYER = 고객 라인 = "주문 라인" "주문 라인" = ORDER_LINES에 여러 개의 LINE이 있습니다. 제품 = 고객 번호에서 입력 = 고객 입력

또한 비즈니스 또는 논리 데이터 모델도 필요합니다.대부분의 논리 데이터 모델은 요구 사항에서 파생될 수 있습니다.예를 들어 어떤 엔티티(ORDERS, ORDER_LINES 및 PRODUCTS)가 필요한지 알고 있으며 경우에 따라 속성 유형을 도출할 수도 있습니다.예를 들어 __approved__는 조건으로 사용되며 LINES는 ORDER_LINES와의 관계여야 하므로 true 또는 false만 가능합니다.그러나 일부 유형은 파생할 수 없으므로 이 데이터 모델에서 명시적으로 정의해야 합니다.다음은 이 데이터 모델의 예입니다.

ORDERES = date : buolean total : 10진수(10,2) = sum (LINES.total) summary : 텍스트가 {BUYER.firstName} {BUYER.lastName}에 의해 표시되는 ORDER 승인과는 반대입니다.n {date}'

ORDER_LINES = PRODUCT : PRODUCTS (1) 번호 : LINES 총계 : 10진수(10,2) = 번호 * PRODUCT 가격과는 반대되는 정수 ORDER : ORDER(1) 번호입니다.

제품 = 이름 : 텍스트 가격 : 10진수(10,2) 요약 : 텍스트 표시 = '{name}({price}유로)'

이 데이터 모델의 대부분은 매우 간단하며 다른 데이터 모델링 기법과 유사합니다.몇 가지 눈에 띄는 점이 있습니다.

• 관계 속성: 관계는 관계 속성을 사용하여 지정합니다.예를 들어 구매자는 표준 엔티티 사용자 및 LINE에 엔티티의 여러 (*) 인스턴스를 포함하는 하나의 인스턴스를 포함하며 ORDER(엔티티 ORDER_LINES의 관계 속성)와는 반대입니다.
• 계산된 속성: 속성을 계산할 수 있습니다.즉, 저장되지 않고 필요할 때 계산됩니다.예를 들어, ORDER의 한 인스턴스의 총합은 LINE의 총합입니다.요약은 전체, 구매자의 이름, 이름 및 날짜를 포함하는 일부 자리 표시자가 포함된 템플릿 텍스트 값입니다.
• Displayed: 즉, 시스템이 ORDES에서 인스턴스를 렌더링해야 하는데 그 방법을 모를 경우 displayed로 표시된 속성을 사용합니다.

SPADE는 설계와 코드 생성을 자동화합니다.

SPADE 는, 다음의 순서에 따릅니다.

1. 해석: 즉, 비즈니스 요건을 읽습니다.
2. 의존관계 분석: 비즈니스 요구사항의 서로 다른 부분 간의 의존관계를 분석합니다.
3. 프로세스 설계 생성: 지능형 알고리즘이 프로세스 설계에 대한 종속성을 변환합니다.또한 일련의 설계 패턴과 여러 최적화 기법을 사용하여 낭비 없이 최적화된 공정 설계를 만듭니다.설계는 높은 수준의 설계(예: 비즈니스 프로세스 체인)와 낮은 수준의 설계(예: 스테이트먼트 수준)입니다.
4. 소스 생성: 워크플로우 및 프로세스 설계의 모든 화면 및 단계에 대한 소스 생성.

오른쪽은 SPADE에 의해 작성된 프로세스 설계의 예시입니다.전체 프로세스는 비즈니스 프로세스입니다. 노란색 단계는 사용자 인터랙티브 단계 또는 시스템이 외부 시스템(예: 외부 시스템)과 상호 작용하는 단계입니다.파란색 단계는 완전히 자동화된 단계입니다.폼의 화면 캡처 예는 프로세스 다이어그램 아래에 추가됩니다.

테스트 케이스 작성 및 실행

생성된 솔루션을 사용할 때는 테스트 사례도 동시에 기록합니다.그런 다음 프로세스의 결과를 검증하는 단언으로 테스트 케이스를 확장합니다.다음은 회색으로 표시된 예시와 이탤릭체로 된 설명을 나타냅니다.

각 테스트 시나리오는 어떤 프로세스가 어떤 사용자에 의해 시작되었는지 기술하는 것으로 시작합니다.이 경우 사용자 'edwinh'에 대한 '제품 주문' 프로세스입니다.

START_PROCESS = 제품 주문, edwinh

다음 부분에서는 어떤 역할과 사용자가 클레임을 하고 어떤 작업에 데이터를 입력할지에 대해 설명합니다.이 경우 사용자 이름 marcusk를 가진 고객은 2개의 LINE을 입력하고 각 행에 선택된 제품과 다수의 제품이 있습니다.두 번째 작업은 edwinh라는 사용자 이름을 가진 매니저를 위한 것으로, 매니저는 true로 승인합니다.

# ---------------------------------------------------------------------------------------------------------CLARM_NEXT_GROUP_TASK = 고객, marcusk task01.LINE = 2 task01.LINE [0]-c-product = 1 task01 。LINE [0]-c-number = 10 task01 。LINE [1]-c-product = 2 task01.LINEs[1]-c-number = 20 # ----------- 첫 번째 클레임과 두 번째 작업 입력02.CLARM_NEXT_GROUP_TASK = 관리자, edwinh task 02.approved = true

다음 부분은 프로세스가 예측된 최종 결과를 달성했는지 여부를 확인하는 것입니다.이들은 기록되지 않으므로 수동으로 추가해야 합니다.이 예에서는 2를 추가했습니다.첫 번째는 TRUE로 채워진 승인된 Atribute의 ORDER 인스턴스가 +1개 더 있는지 확인합니다.두 번째는 ORDER_LINES의 +2개의 새로운 인스턴스가 추가되었는지 확인합니다.

ASSERT_PROCESS_VALUE_COUNT_01 = ORDERS.approved = TRUE, +1 ASST_PROCESS_ROW_COUNT_02 = ORDER_LINES, +2

솔루션 도입

SPADE는 자체적으로 실행할 수 있지만 Apache Maven 플러그인으로 실행되는 경우가 많기 때문에 Maven 빌드 사이클의 일부입니다.이 빌드 사이클에는 테스트 시나리오 실행도 포함됩니다.

1. 생성된 기능을 .jar 파일로 전개합니다.
2. 테스트 데이터를 로드합니다.
3. 테스트 시나리오와
4. 는 결과를 검증합니다.

Maven 빌드 사이클은 일상적인 빌드부터 지속적인 제공/도입까지 사용할 수 있습니다.데모의 목적으로, 전술한 순서는, 소프트웨어 솔루션의 표준 프런트 엔드에서도 실행할 수 있습니다.표준 프런트 엔드를 사용하면 다음을 자동화할 수도 있습니다.

• 기존 데이터베이스를 분석하여 데이터베이스가 이미 생성된 기능을 준수하는지 확인합니다.
• 데이터베이스가 존재하지 않는 경우 컴플라이언스 데이터베이스를 자동으로 작성할 수 있습니다.
• 데이터베이스가 아직 준수하지 않으면 테이블 및 관계를 자동으로 만들거나 업데이트할 수 있습니다.

이전 데이터베이스 또는 이전 릴리스에서 새 릴리스로 데이터를 마이그레이션하는 작업도 자동으로 수행됩니다.단, 이행 소프트웨어(예를 들어 SQL 또는 ETL 사용)는 수동으로 작성됩니다.

SPADE가 도입 중에 제공하는 자동화는 소규모 시스템이나 스프린트 데모에 자주 사용됩니다.대규모 프로젝트를 전개하는 경우에는 보다 고도의 다른 전개 툴이 일반적으로 사용됩니다.

그 결과 얻을 수 있는 솔루션

오른쪽 그림은 SPADE가 생성된 솔루션 및 이 솔루션의 글로벌 아키텍처와 어떻게 관련되어 있는지를 보여 줍니다.이 다이어그램의 다양한 요소에 대해 설명합니다.

• SMART 비즈니스 요건: 요건 사양 언어 SMART ^[1]표기법을 사용하여 (수동으로) 수집 및 문서화합니다.이것은, 정보 베이스의 최종 결과를 정의하기 위해서 사용할 수 있는 도메인 고유의 언어입니다.
• 요건으로부터 설계, 문서, 소스 코드를 자동적으로 작성합니다.SPADE는, 소프트웨어 솔루션에 컴파일 할 수 있는 설계, 문서, 및 소스 코드를 자동적으로 작성합니다.
• 사용자 및 GUI: 이 솔루션은 다양한 GUI에 의해 역할 기반의 인증된 사용자와 상호 작용할 수 있습니다.이 솔루션에는 이미 모든 기능에 표준 GUI가 탑재되어 있습니다만, 커스텀 GUI로 확장할 수 있습니다.필요에 따라서, 양쪽 타입의 GUI를 혼재시킬 수 있습니다.
• REST/SOAP: 모든 기능에는 항상 다른 GUI에서 사용되는 일치된 REST 또는 SOAP 서비스가 있지만 인증된 외부 시스템에서도 사용할 수 있습니다.
• DBAL: 서버에는 데이터베이스와 통신하기 위한 휴지 상태 또는 유사한 데이터베이스 추상화 계층도 있습니다.
• 플러그인: 외부 시스템 또는 외부 장치와 통신하기 위해 서버를 사용하거나 서버에 추가할 수 있습니다.이를 통해 솔루션은 사물인터넷 도메인의 디바이스를 사용할 수도 있습니다.모든 플러그인은 비즈니스 요건에서 호출할 수 있지만 항상 비기술적인 방법으로 호출할 수 있습니다.예를 들어, 결과적으로 DOCUMENT를 정의하면 SPADE는 엔티티 DOCUMENTS와 연결된 플러그인을 호출하는 것을 인식합니다.플러그인은 실제 문서를 만들고 저장합니다.
• 특정 기능: 비즈니스 요건에 따라 생성되는 기능입니다.이것에 의해, 폭넓은 기능을 작성할 수 있습니다.SPADE 사용자는 CRM, HR, 프로파일 매칭 및 재무 기능 등과 같은 기성 요구사항 라이브러리를 사용할 수 있습니다.이것은, 클라이언트의 특정의 요구에 맞추어 삽입 및 조정할 수 있습니다.특정 기능에서는 모든 플러그인과 모든 범용 기능을 사용하여 사용 가능한 기능 영역을 확장할 수 있습니다.
• 범용 기능: 디폴트에서는, 솔루션에는 표준 범용 기능이 다수 탑재되어 있습니다.예를 들어 DMS, 문서 생성, 자동 이메일, SMS, 메시징, 고급 검색, 데이터 검색 및 내보내기 등이 있습니다.

어떤 소프트웨어 개발 작업이 자동화되고 어떤 작업이 수동입니까?

다음 표에서는 SPADE에 의해 자동화되는 소프트웨어 개발 활동과 적용되는 예외를 보여 줍니다.

소프트웨어 개발 활동	수동 또는 자동화	예외
요구 사항들	설명서	n.a.
설계.	자동화	외부 시스템으로의 착신 인터페이스 및 복잡하고 화려한 그래피컬 사용자 인터페이스의 설계는 수동으로 작성해야 합니다.
코딩/프로그래밍	자동화	수작업으로 설계된 부품
테스트 준비	설명서	n.a.
테스트 실행	자동화	첫 번째 릴리스에 대한 스모크테스트 및 사용자 인터페이스 테스트는 수동으로 수행해야 합니다.
도입	자동화	데이터 이행의 작성은, 대부분의 경우 수동으로 행해집니다.위에서 설명한 바와 같이 대규모 시스템에서는 다른 도입 도구와 기술을 사용하는 경우가 많습니다.이러한 설정은 수동으로도 행해집니다.
문서	자동화	설계와 생성된 소스는 자동으로 문서화됩니다.이것은 많은 경우 수동으로 작성한 소량의 매뉴얼로 보완됩니다.

역사

• 2000년: 2000년 CMG(현 CGI Group의 일부)의 Edwin Hendriks는 프로세스 가속이라는 프로세스 개선 방법을 개발했습니다.이 방법의 핵심에는 비즈니스 프로세스의 바람직한 최종 결과를 명확하게 정의하는 방법 및 이러한 최종 결과를 달성할 수 있는 최적의 비즈니스 프로세스를 추론하는 구조화된 접근 방식이 있었습니다.이것은 SMART 표기법의 첫 번째 버전(당시 PA 표기법이라고 불림)이 탄생한 것입니다.SMART^[1] 표기법은 프로세스 체인 전체의 최종 결과를 지정하는 데 사용할 수 있는 형식 언어입니다(프로세스 체인 자체를 지정하는 것과는 반대).CMG(회사)는 이 메서드와 SMART^[1] 표기법을 여러 프로젝트와 클라이언트에 사용했습니다.
• 2007년: 성공적이었지만, 당시 CMG(기업)는 프로세스 개선 컨설팅을 제공하는 것으로 알려져 있지 않았습니다.이것이 CMG(당시 Logica와 합병)가 프로세스 액셀러레이션의 핵심에 초점을 맞춘 이유이며, 그 결과 2007년에 PA SMART Requirements(현 SMART Requirements 2^[1].0)라고 불리는 소프트웨어 개발을 개선하는 방법이 탄생했습니다.그 후 SMART Requirements^[1] 2.0은 CGI 그룹과 그 고객 및 다른 기업 및 조직에서 사용되고 있습니다.
• 2008년: 프로세스 체인의 최종 결과에 대한 명확한 정의와 이 최종 결과로부터 최적의 프로세스를 추론하는 구조화된 접근방식을 가지고 있으며, 최종 결과를 읽고, 그 결과로부터 최적의 프로세스를 추론하고, 프로세스의 각 단계에 대해 소프트웨어를 생성할 수 있는 도구를 만드는 아이디어를 얻었습니다.Edwin Hendriks, Marcus Klimstra 및 Niels Bergsma는 []를 사용하여 SPADE의 첫 번째 작동 프로토타입(당시 PA 제너레이터라고 함)을 개발했습니다.또한 [NET]를 사용하여 시스템을 생산합니다.NET] 아키텍처.
• 2010년: Logica는 SPADE의 상용 버전 개발을 시작하기로 결정했습니다.
• 2011년: SPADE 버전 2.12를 사용하여 처음 2개의 시스템을 만들었습니다.부서간 시간 추적 시스템과 로지카 자체에서 사용하는 익명 투표 시스템입니다.
• 2012: SPADE 버전 3이 생성되었습니다.이것은 최초의 상용 사용 가능한 SPADE 버전입니다.그때부터 SPADE는 클라이언트의 솔루션을 작성하기 위해서 사용되었습니다.SPADE를 사용하여 솔루션을 만들 때 시간과 비용이 짧기 때문에 기존 레거시 시스템을 재현하는 데 자주 사용되었습니다. 개발 속도가 향상되고 비용이 낮았지만 SPADE는 여전히 치아의 문제가 있었습니다.이로 인해 솔루션 작성(재작성)에 필요한 실제 시간을 추정하는 것이 어려워져 프로젝트 계획 수립이 어려워졌습니다.로지카가 CGI그룹에 인수된 해였다.
• 2015년 : SPADE 버전 4는 초등학생 최초로 시험 시스템을 구축하였습니다.SMART 요건을 작성하고 SPADE에 이를 위한 프로페셔널 시스템을 구축하도록 의뢰하는 것은 다른 소프트웨어 작성 방법에 비해 비교적 쉬운 것으로 나타났습니다.같은 해에 SPADE와 상호작용하여 지상국 소프트웨어를 만든 작은 로켓이 발사되었다.SPADE는 실제로 외부 장치와 매우 빠르게 상호 작용할 수 있다는 것을 보여주었습니다(그러나 아직 실시간 시스템을 만들 수 있을 만큼 빠르지는 않습니다).
• 2016년: 버전 4.4 SPADE에서는 대부분의 치아의 문제가 해결되어 크고 복잡한 시스템을 단시간에 작성할 수 있게 되었습니다.SPADE는 현재 표준 GUI를 보다 쉽게 커스터마이즈할 수 있을 뿐만 아니라 요건을 보다 쉽게 작성 및 변경할 수 있도록 확장되고 있습니다.이를 통해 더 많은 비개발자가 SPADE를 사용하여 솔루션을 만들 수 있습니다.

장점, 단점 및 고려사항

위쪽 SPADE는 놀라운 개발 속도를 보여줍니다.국제적인 벤치마크에 따르면 전체 개발 사이클은 기존 기술에 비해 평균 20배 빠르게 완료되며, 많은 경우 기존 소프트웨어 솔루션의 기능을 완전히 재구축하는 것이 구입 및 구성에 비해 훨씬 더 빠릅니다.물론 이러한 개발 속도 덕분에 고객은 새로 생성된 솔루션을 쉽게 확인하고 사용해 볼 수 있습니다.물론 설계와 코딩을 자동화함으로써 설계와 코딩 오류가 거의 발생하지 않습니다.그 결과 얻을 수 있는 솔루션에는 벤더 록이 없으며 완전히 무료로 사용할 수 있는 오픈 소스 컴포넌트를 기반으로 한다는 점도 큰 장점입니다.물론 SPADE도 배우기 쉽습니다.

단점으로는 SPADE는 도메인 고유의 언어로 남아 있기 때문에 어떤 유형의 기능에도 적합하지 않습니다.이를 위해서는 기존 개발 또는 기타 도구가 필요합니다.이와 같은 실시간 퍼포먼스와 GUI를 보다 쉽게 변경할 수 있는 기능도 추가 개발이 필요합니다.SPADE는 또한 새로운 제품으로 아직 주류 개발 도구로 간주되지 않습니다.물론 SMART 요건을 작성하려면 몇 문장으로 설명하는 것보다 더 많은 노력과 기술이 필요합니다.

통상적인 소프트웨어 개발에서는 작성해야 할 기능의 고정 '계약'이 요건에 의해 정의된다는 점을 항상 고려해야 합니다.예를 들어 스크럼 개발팀의 사용자 스토리도 스프린트 중에 사용자 스토리를 개발하기 전에 수정해야 합니다.이는 SPADE 프로젝트에서도 마찬가지입니다.그러나 요건이나 사용자 스토리를 개발할 준비가 되면 SPADE에 의해 스프린트가 수행되며, 이 작업은 몇 분밖에 걸리지 않습니다.그 결과 요건 단계(사용자 사례 작성)를 스프린트로 이동하는 경향이 있습니다.따라서 이는 일반적인 Agile 개발뿐만 아니라 SPADE를 사용한 Agile 개발에서도 좋지 않은 관행으로 간주됩니다.

또 하나의 고려사항은 기능이 매우 쉽고 복잡하다는 것입니다.SPADE에는 문제가 없지만 시스템 기능의 단순한 크기와 복잡성에 대처하기 어려운 사람도 있습니다.따라서 일반적인 시스템 개발과 동일한 방법으로 크기와 복잡성에 대처하는 것이 좋습니다.기능을 알기 쉬운 조각으로 잘라 구조화한다.

「 」를 참조해 주세요.

• 규율된 신속한 이행

레퍼런스