Vývojové prostředí SMART Process Acceleration - SMART Process Acceleration Development Environment - Wikipedia

Tento článek má několik problémů. Prosím pomozte vylepši to nebo diskutovat o těchto otázkách na internetu diskusní stránka. (Zjistěte, jak a kdy tyto zprávy ze šablony odebrat) tento článek potřebuje další citace pro ověření. Prosím pomozte vylepšit tento článek podle přidávání citací ke spolehlivým zdrojům. Zdroj bez zdroje může být napaden a odstraněn. Najít zdroje: „Vývojové prostředí SMART Process Acceleration Development“  – zprávy  · noviny  · knihy  · učenec  · JSTOR (Červen 2016) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) Téma tohoto článku nemusí splňovat požadavky Wikipedie obecný pokyn k notabilitě. Pomozte prosím demonstrovat pozoruhodnost tématu citováním spolehlivé sekundární zdroje to jsou nezávislý tématu a poskytnout jeho významné pokrytí nad rámec pouhé triviální zmínky. Pokud nelze prokázat pozoruhodnost, článek pravděpodobně bude sloučeny, přesměrovánnebo smazáno. Najít zdroje: „Vývojové prostředí SMART Process Acceleration Development“  – zprávy  · noviny  · knihy  · učenec  · JSTOR (Říjen 2020) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) tento článek obsahuje obsah, který je napsán jako reklama. Prosím pomozte vylepši to odstraněním propagační obsah a nevhodné externí odkazy, a přidáním encyklopedického obsahu napsaného z a neutrální hledisko. (Říjen 2020) (Zjistěte, jak a kdy odstranit tuto zprávu šablony) (Zjistěte, jak a kdy odstranit tuto zprávu šablony)

RÝČ (SMART Process Acceleration Development Environment) je nástroj pro produktivitu a kvalitu vývoje softwaru používaný k vytváření profesionálního softwaru v krátké době as minimálním úsilím. Jak je vidět na schématu, SPADE (zelená ikona) automatizuje mnoho manuálních činností Proces vývoje softwaru. Plný vývojový cyklus softwaru proto trvá méně času a úsilí.

U SPADE jsou zbývající ruční kroky:

• Požadavky: shromažďování přání zákazníka a jeho zdokumentování v jasných požadavcích, uživatelských příbězích apod.
• Testovací případy: vytváření integračních testovacích případů, které se během Testu spustí automaticky.
• Test: testování použitelnosti a testování integrace s externími (ne-SPADE) systémy.
• Akceptovat: přijetí vytvořeného řešení

Automatizace dalších kroků je možná, protože (obchodní) požadavky jsou jasně specifikovány pomocí metody SMART Požadavky 2.0.^[1] SPADE pak používá inteligentní algoritmy, které zahrnují analýzu závislostí a sadu návrhových vzorů, k transformaci těchto požadavků na optimalizovaný design obchodního procesu, včetně toku uživatelských interaktivních a plně automatizovaných kroků, které jsou součástí tohoto obchodního procesu.

SPADE je nástroj pro vývoj softwaru založený na konkrétním modelu domény, který je vhodný pro vytváření jak složitých, tak jednoduchých systémů pro zpracování informací. V současné době je méně vhodný pro vytváření softwaru, který dokáže ovládat hardware v reálném čase, nebo pokročilých grafických uživatelských rozhraní. Lze však přidat doplňky pro přístup k funkcím, které SPADE nevytváří.

Detaily

Vysvětlíme vytvoření jasných požadavků pomocí jazyka SMART notace^[1] který je součástí metody SMART Požadavky 2.0^[1] následuje vysvětlení, jak a co SPADE z těchto požadavků automaticky vytvoří. Vysvětlíme také vytváření a spouštění testovacích případů a typickou architekturu softwarového řešení, které vytváří SPADE.

Vytváření jasných požadavků

Vstupem SPADE jsou specifikace obchodních požadavků orientovaných na konečné výsledky. Vysvětlují:

Tyto informace se vloží do dokumentu, obvykle do nějakého souboru, a zapíší se pomocí jazyka formální specifikace. Níže je uveden příklad v šedé barvě s vysvětlením v kurzíva text.

Začněte tím, že proces a jeho nejdůležitější informace pojmenujete jako předmět

Zpracovat „Objednat produkty“ s předmětem # („Objednávka“: OBJEDNAT)

Shrňte výsledky na vysoké úrovni. Dvojité uvozovky se používají k definování požadavků a pomáhají vytvořit strukturu rozložení orientovanou na výsledky.

 Platí následující: „Zákazník si objednal produkty“ a „Zákazník má fakturu, pokud je schválena“ a „Objednávku je třeba v případě potřeby schválit“

Vizuální specifikace požadavku „Zákazník má fakturu“

Jasně definujte požadavky. Použijte if-then-else k definování „Kdy“ by výsledky měly platit nebo by měly být vytvořeny. „Odkud“ informace pochází, je definováno pomocí odkazů. Například ORDER.approved je část dostupných informací, která je buď vytvořena během procesu, nebo je již dostupnou informací. Některé požadavky (výsledky) lze určit vizuálně. Po vaší pravici je „Zákazník má fakturu“ uveden jako e-mail.

 „Zákazník má fakturu, pokud je schválena“ = pokud je ORDER.approved pak „Zákazník má fakturu“ „Objednávka musí být schválena, pokud je potřeba“ = pokud „příliš drahá“, pak „Objednávka musí být schválena“ else ORDER.approved = true "příliš drahé" = OBJEDNÁVKA.celkem> 500

Osoba může být také zdrojem informací tím, že uvede „vstup od“ následovaný jménem, ​​které identifikuje roli této osoby nebo skutečného uživatele. V níže uvedeném příkladu osoba s rolí CONTROLLER. Pokud tyto osoby zase potřebují informace, aby mohly tento vstup poskytnout, musíte uvést, že tento vstup lze poskytnout „na základě“ určitých dalších informací. V tomto případě datum, KUPUJÍCÍ a ŘÁDKY OBJEDNÁVKY.

 „Objednávku je třeba schválit“ = ORDER.approved = vstup od CONTROLLER na základě # (ORDER.date, ORDER.BUYER, ORDER.LINES)

Skutečnou osobu, která dává vstup v době, kdy je systém používán (aktuální uživatel), lze také použít jako informaci. Následující příklad definuje OBJEDNÁVKU a její atributy. Jeden, pokud se atributy nazývají KUPUJÍCÍ a ten je vyplněn skutečným ZÁKAZNÍKEM, který (v době spuštění skutečného procesu) hraje tuto roli, jinými slovy dává vstup.

 „Zákazník si objednal produkty“ = Jeden OBJEDNÁVKA existuje v OBJEDNÁVKÁCH s: date = currentDate () BUYER = CUSTOMER LINES = "řádky objednávky" "řádky objednávky" = V ORDER_LINES existuje několik ŘÁDKŮ s: PRODUCT = vstup od CUSTOMER number = vstup od CUSTOMER

Požadavky také vyžadují obchodní nebo logický datový model. Většinu logického datového modelu lze odvodit z požadavků. Například ví, které entity jsou potřeba (OBJEDNÁVKY, ORDER_LINES a PRODUCST) a v některých případech také může odvodit typ atributu. Například __approved__ může být pouze true nebo false, protože se používá jako podmínka a LINES by měl být vztahem k ORDER_LINES. Některé typy však nelze odvodit a je třeba je v tomto datovém modelu explicitně definovat. Níže je uveden příklad tohoto datového modelu.

   OBJEDNÁVKY = datum: datum KUPUJÍCÍ: UŽIVATELÉ (1) ŘÁDKY: ORDER_LINES (*) naproti schválené OBJEDNÁVCE: boolovský součet: desítkové (10,2) = součet (LINES.total) souhrn: text zobrazen = '{celkem} euro od { BUYER.firstName} {BUYER.lastName} dne {date} '

   ORDER_LINES = PRODUKT: PRODUKTY (1) číslo: celé číslo OBJEDNÁVKA: OBJEDNÁVKY (1) naproti LINES celkem: desítkové (10,2) = číslo * PRODUCT.price

   PRODUKTY = název: cena textu: desítkové (10,2) souhrn: zobrazený text = '{name} ({cena} euro)'

Většina tohoto datového modelu je docela přímočará a podobá se ostatním techniky modelování dat. Některé věci vynikají:

• Relační atributy: relace jsou specifikovány pomocí relačních atributů. Například BUYER, který obsahuje 1 instanci ve standardní entitě USERS a LINES, která obsahuje více (*) instancí entity ORDER_LINES a je opakem relace ORDER (což je relační atribut entity ORDER_LINES).
• Vypočítané atributy: atributy lze vypočítat, což znamená, že se neukládají, ale vypočítávají se podle potřeby. Například součet jedné instance OBJEDNÁVEK je součtem součtu jejích ŘÁDEK. Souhrn je textová hodnota, což je text šablony s některými zástupnými symboly uvnitř, které obsahují celkem, jméno a příjmení KUPUJÍCÍho a datum.
• Zobrazeno: což znamená, že pokud systém potřebuje vykreslit instance z OBJEDNÁVEK a neví, jak to udělat, použije atribut označený zobrazí se.

SPADE automatizuje design a tvorbu kódu

Návrh procesu vytvořený automaticky SPADE.

SPADE proveďte následující kroky:

1. Analýza: jinými slovy si přečtěte obchodní požadavky
2. Analyzovat závislosti: jsou analyzovány závislosti mezi různými částmi obchodních požadavků.
3. Vytvářejte návrhy procesů: inteligentní algoritmus transformuje závislosti na návrhy procesů. Využívá sadu návrhových vzorů a několik optimalizačních technik k vytvoření optimalizovaného návrhu procesu, který v sobě nemá žádný odpad. Návrh je jak designem na vysoké úrovni (např. Řetězce obchodních procesů), tak designem na nízké úrovni (např. Na úrovni výpisu).
4. Generovat zdroje: pro pracovní tok a všechny obrazovky a kroky v návrhu procesu.

Form1 - Zadejte řádky objednávky od zákazníka

Formulář 2 - Zadejte souhlas správce

Napravo je příklad návrhu procesu, který vytvořil SPADE. Celý proces je obchodní proces, žluté kroky jsou uživatelské interaktivní kroky nebo kroky, ve kterých systém interaguje s externím aktérem, například s externím systémem. Modré kroky jsou plně automatizované kroky. Ukázkové snímky obrazovky formulářů jsou přidány pod diagram procesu.

Vytváření a spouštění testovacích případů

Když používáte vytvořené řešení, současně nahráváte také testovací případy. Tyto testovací případy jsou poté rozšířeny o výroky, které ověřují výsledek procesu. Níže je uveden příklad v šedé barvě s vysvětlením v kurzíva text.

Každý testovací scénář začíná uvedením, který proces je spuštěn kterým uživatelem. V tomto případě zpracovejte „Objednat produkty“ pro uživatele „edwinh“.

START_PROCESS = Objednat produkty, edwinh

Další část popisuje, které role a uživatelé si budou nárokovat, a poté zadají data, ve které úloze. V tomto případě a zákazník s uživatelským jménem marcusk zadá 2 ŘÁDKY a každý řádek bude mít vybraný produkt a řadu produktů. Druhý úkol je pro manažer s uživatelským jménem edwinh a naplní schválené pravdivou.

   # -------- PRVNÍ NÁROK A ZADEJTE 1. ÚKOL ---------- task01.CLAIM_NEXT_GROUP_TASK = zákazník, marcusk task01.LINEs = 2 task01.LINEs [0] -c-product = 1 task01.LINEs [0] -c-number = 10 task01.LINEs [1] -c-product = 2 task01.LINEs [1] -c-number = 20 # -------- PRVNÍ NÁROK A ZADEJTE 2. ÚKOL ---------- task02.CLAIM_NEXT_GROUP_TASK = manažer, edwinh task02.approved = true

Další částí jsou kontroly, zda proces dosáhl předpokládaného konečného výsledku. Ty se nezaznamenávají a je třeba je přidat ručně. V tomto příkladu jsme přidali 2 tvrzení. První zkontroluje, zda existuje o +1 další instance OBJEDNÁVEK se schváleným atributem vyplněným TRUE. Druhý zkontroluje, zda byly přidány +2 nové instance ORDER_LINES.

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

Nasazení řešení

SPADE může běžet sám, ale často běží jako Apache Maven plugin, a proto je součástí cyklu sestavování Maven. Tento cyklus sestavení také zahrnuje spuštění testovacích scénářů, které zase

1. nasadí vygenerovanou funkcionalitu jako soubor .jar,
2. načte data testů,
3. provede testovací scénář a
4. ověří výsledek.

Cyklus sestavení Maven lze použít v denních sestaveních až do kontinuální dodávka / nasazení. Pro ukázkové účely lze uvedené kroky provést také ve standardním rozhraní výsledného softwarového řešení. Se standardní frontendem je také možné automatizovat následující:

• analyzovat existující databázi a zkontrolovat, zda databáze již vyhovuje generované funkčnosti;
• pokud není k dispozici žádná databáze, lze automaticky vytvořit vyhovující databázi;
• pokud databáze dosud nesplňuje požadavky, lze tabulky a relace vytvářet nebo aktualizovat automaticky.

Migrace dat ze staré databáze nebo ze starého vydání do nového vydání se také provádí automatizovaně. Migrační software (např. Pomocí SQL nebo ETL ) je vytvořen ručně.

Všimněte si, že automatizace, kterou poskytuje SPADE během nasazení, se často používá pro menší systémy a pro ukázky sprintu. Pro nasazení větších projektů se běžně používají další pokročilejší nástroje pro nasazení.

Globální architektura SPADE a řešení, které vytváří

Výsledné softwarové řešení

Diagram napravo ukazuje, jak SPADE souvisí s vytvořeným řešením, stejně jako globální architekturu tohoto řešení. Níže jsou vysvětleny různé prvky diagramu:

• SMART obchodní požadavky: jsou (ručně) shromažďovány a dokumentovány pomocí jazyka specifikace požadavků SMART notace.^[1] Tohle je Jazyk specifický pro doménu které lze použít k definování konečných výsledků založených na informacích, které by podniky nebo organizace chtěly produkovat.
• Automaticky vytváří návrhy, dokumenty, zdrojový kód: z požadavků pak SPADE automaticky vytvoří návrhy, dokumentaci a zdrojový kód, který lze zkompilovat do softwarového řešení.
• Uživatelé a grafické uživatelské rozhraní: řešení může komunikovat s autorizovanými uživateli založenými na rolích různými GUI. Řešení již bude mít standardní grafické uživatelské rozhraní pro všechny funkce, ale může být rozšířeno o vlastní grafické uživatelské rozhraní. Grafické uživatelské rozhraní obou typů lze v případě potřeby kombinovat.
• REST / MÝDLO: všechny funkce budou mít vždy odpovídající službu REST nebo SOAP, které jsou používány různými grafickými uživatelskými rozhraními, ale mohou být použity také autorizovanými externími systémy.
• DBAL: server má také režim hibernace nebo podobný vrstva abstrakce databáze komunikovat s databází.
• Pluginy: lze použít nebo přidat na server ke komunikaci s externími systémy nebo s externími zařízeními. To umožňuje řešení je také schopen používat zařízení z Internet věcí doména. Všechny plug-iny lze vyvolat z obchodních požadavků, ale vždy netechnickým způsobem. Například pokud jako výsledek definujete DOKUMENT, SPADE bude vědět, že zavolá zásuvný modul spojený s entitou DOKUMENTY. Plug-in skutečně vytvoří a uloží fyzický dokument.
• Specifické funkce: toto je funkce, která je vytvořena na základě obchodních požadavků. S ním můžete vytvořit širokou škálu funkcí. Uživatelé SPADE mohou používat knihovnu běžných požadavků, například CRM, HR, porovnávání profilů a finanční funkce. To lze vložit a upravit tak, aby vyhovovalo konkrétním potřebám klienta. Specifická funkce může využívat všechny moduly plug-in i všechny obecné funkce k rozšíření domény dostupných funkcí.
• Obecné funkce: ve výchozím nastavení je řešení již vybaveno řadou standardních obecných funkcí. Například DMS, generování dokumentů, automatické e-maily, SMS, zprávy, pokročilé vyhledávání, procházení dat a export.

Které činnosti vývoje softwaru jsou automatizované a které jsou manuální?

Následující tabulka ukazuje, které aktivity vývoje softwaru jsou automatizovány SPADE a jaké výjimky platí.

Dějiny

• 2000: v roce 2000 Edwin Hendriks společnosti CMG (společnost) (nyní součást Skupina CGI ) vyvinul metodu zlepšování procesů zvanou Zrychlení procesu. Jádrem této metody byl způsob, jak definovat požadovaný konečný výsledek obchodního procesu zcela jednoznačně, stejně jako strukturovaný přístup k odvození nejoptimálnějšího obchodního procesu, který by tohoto konečného výsledku dosáhl. To bylo zrození první verze SMART notace^[1] (v té době volal PA notace), což je formální jazyk, který lze použít ke specifikaci konečných výsledků celých procesních řetězců (oproti specifikaci samotného procesního řetězce). CMG (společnost) použil tuto metodu a SMART notace^[1] pro několik jejich projektů a jejich klientů.
• 2007: ačkoli úspěšný, CMG (společnost) v té době nebylo známo, že poskytuje poradenství v oblasti zlepšování procesů. To byl důvod CMG (společnost) (v té době sloučeno s Logica ) zaměřit se na jádro Zrychlení procesu, což má za následek v roce 2007 v metodě, která zlepšuje vývoj softwaru, tzv PA SMART požadavky (nyní volal SMART Požadavky 2.0^[1]). Od té doby SMART Požadavky 2.0^[1] byl použit uživatelem Skupina CGI a jejich zákazníci i další společnosti a organizace.
• 2008: mít jednoznačnou definici konečného výsledku procesního řetězce a strukturovaný přístup k odvození nejoptimálnějšího procesu z tohoto konečného výsledku, vyvolalo myšlenku vytvořit nástroj, který by dokázal přečíst konečný výsledek, odvodit nejoptimálnější proces z a vygenerujte software pro každý krok procesu. Edwin Hendriks, Marcus Klimstra a Niels Bergsma vyvinul první funkční prototyp RÝČ (v té době nazývaný generátor PA) používající [.NET] a také produkující systémy využívající architekturu [.NET].
• 2010: Logica se rozhodl zahájit vývoj komerční použitelné verze RÝČ.
• 2011: verze 2.12 nástroje SPADE byla použita k vytvoření prvních 2 systémů, které byly uvedeny do provozu. Jako mezirezortní systém sledování času a anonymní hlasovací systém, který používá Logica sám.
• 2012: byla vytvořena verze 3 SPADE. Jednalo se o první komerční použitelnou verzi SPADE. Od té doby byl SPADE používán k vytváření řešení pro klienty. Často se používalo k obnovení existujících starší systémy z důvodu krátké doby a nákladů spojených s vytvářením řešení pomocí SPADE. I přes zvýšenou rychlost vývoje a nízké náklady měl SPADE stále problémy s kousáním. Díky tomu bylo obtížné odhadnout skutečný čas potřebný k (znovu) vytvoření řešení, což ztěžovalo plánování projektů. Byl to stejný rok Logica byl získán uživatelem Skupina CGI.
• 2015: verze 4 SPADE byla poprvé použita dětmi základních škol k vytvoření systému zkoušek. Ukázalo se, že vytvoření požadavků SMART a následné požádání společnosti SPADE o vytvoření profesionálního systému pro ně bylo ve srovnání s jinými způsoby vytváření softwaru relativně snadné. Ve stejném roce byla vypuštěna malá raketa, která interagovala se softwarem SPADE vytvořeným pozemní stanicí. Ukázalo se, že SPADE může ve skutečnosti komunikovat s externími zařízeními docela rychle (ale stále ještě není dostatečně rychlý na to, aby byl použitelný pro vytváření systémů v reálném čase).
• 2016: ve verzi 4.4 SPADE byla vyřešena většina problémů s kousáním, což umožnilo (znovu) vytvořit velké a složité systémy v krátké době. SPADE se v současné době rozšiřuje, aby poskytoval snadnější způsob vytváření a změn požadavků a také snadnější způsob přizpůsobení standardního grafického uživatelského rozhraní. To umožní více vývojářům používat SPADE k vytváření řešení.

Výhody, nevýhody a úvahy

Na druhou stranu SPADE vykazuje pozoruhodné rychlosti vývoje. Mezinárodní měřítka ukazují, že kompletní vývojový cyklus bude ve srovnání s konvenčními technikami dokončen v průměru 20krát rychleji a v mnoha případech je ještě rychlejší zcela obnovit funkčnost stávajících softwarových řešení ve srovnání s jejich nákupem a konfigurací. Tato rychlost vývoje samozřejmě klientům usnadňuje prohlížení a vyzkoušení nově vytvořeného řešení. Samozřejmě automatizací designu a kódování nedojde téměř k žádným chybám designu a kódování. Skutečnost, že výsledná řešení nemají zámek dodavatele a jsou zcela založeny na volně použitelných komponentách open source, je také velkým plusem. SPADE se samozřejmě také snadno naučí.

Na druhou stranu SPADE zůstane jazykem specifickým pro doménu, a proto nebude vhodný pro žádný typ funkcí. To bude vyžadovat konvenční vývoj nebo jiné nástroje. Kromě tohoto výkonu v reálném čase a schopnosti snadněji měnit grafické uživatelské rozhraní je něco, co vyžaduje další vývoj. SPADE je také poměrně nový a dosud není považován za běžný vývojový nástroj. Vytváření požadavků SMART samozřejmě vyžaduje více úsilí a dovedností ve srovnání s jejich pouhým popisem několika větami.

Vždy je třeba vzít v úvahu, že při normálním vývoji softwaru požadavky definují pevnou „smlouvu“ funkčnosti, která by měla být vytvořena. Například uživatelský příběh ve vývojovém týmu Scrum by měl být také opraven, než bude uživatelský příběh během sprintu vyvinut. To je stejné pro projekty SPADE. Když jsou však požadavky nebo uživatelské příběhy připraveny k vývoji, sprint provede SPADE a bude to trvat jen pár minut. To mělo za následek tendenci přesunout fázi požadavků (vytváření uživatelských příběhů) do sprintu. To je proto považováno za špatnou praxi jak v normálním agilním vývoji, tak v agilním vývoji pomocí SPADE.

Další úvaha spočívá v tom, že je tak snadné dosáhnout velké a složité funkce. Ačkoli to pro SPADE nepředstavuje žádný problém, určitým lidem to znesnadňuje zvládnout naprostou velikost a složitost funkčnosti systému. Proto je vhodné stále řešit velikost a složitost stejným způsobem, jako byste postupovali při normálním vývoji systému. Rozřezáním a strukturováním funkcí do srozumitelných částí.

Viz také

• Disciplinované agilní doručení

Reference

externí odkazy