Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- to:standart_pro_aplikace [09.06.2018 06:40]
Jarmil [Fáze návrhu aplikace] čeština, překl
+++ to:standart_pro_aplikace [29.04.2020 16:36] (aktuální)
jan.hamal.dvorak
@@ Řádek 1: / Řádek 1: @@
-===== Standard pro aplikace pirátů =====
+===== Standard pro nové aplikace Pirátů =====
-Piráti pracují s širokou škálou software, který byl psán a zpravován dobrovolníky. V minulosti
+<note warning>Tento dokument není aktuální. Raději se zeptejte na [[https://zulip.pirati.cz/|Zulipu]].</note>
-vznikl velký technický dluh, který se postupně daří odstraňovat. Jako prevence podobných problému v budoucnu slouží tento seznam základních požadavků pro dobrý softwarový projekt a jeho nasazení.
+Piráti pracují s širokou škálou software, který byl psán a spravován dobrovolníky. V minulosti
+vznikl velký technologický dluh, který se postupně daří odstraňovat. Jako prevence podobných problémů v budoucnu slouží tento seznam základních požadavků pro dobrý softwarový projekt a jeho nasazení.
 Tyto standardy by měl dodržovat každý, kdo chce nasazovat nové aplikace, ať už jde o dobrovolníka, dodavatelskou firmu či propagátora konkrétního existujícího software.
-Nejdřív vám doporučuji projít si celý text, rozmyslet si jak splníte požadavky. S hotovým návrhem se můžete obrátit na technického koordinátora, dokud není vybrán, jeho roli zastávají
-Martin Rejman a Jitka Novotná.
+Pokud chcete vytvořit nějakou aplikaci, rozmyslete, jak splníte požadavky. S hotovým návrhem, nebo žádostí o pomoc, se můžete obrátit na Koordinátora technického odboru, případně na další členy TO (Martin Rejman, Jitka Novotná).
 ==== Fáze návrhu aplikace  ====
   * **Zadání problému** Konkrétní popis toho, k jakému účelu má aplikace sloužit, včetně příkladů.
-  * **Designové rozhodnutí** Zdůvodnit rozhodnutí výběru konkrétních knihoven, dalších projektů apod. Příklad: [[http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions|blog]], [[ https://github.com/npryce/adr-tools|nástroj]] ale i prostý text stačí.
+  * **Designové rozhodnutí** Zdůvodnit rozhodnutí výběru konkrétních knihoven, dalších projektů apod. Příklad: [[http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions|blog]], [[ https://github.com/npryce/adr-tools|nástroj]], i prostý text stačí.
   * **API** Cílem je sdílení dat mezi aplikacemi - je třeba určit, která data se mají poskytovat, a to ve strojové podobě. Ideální forma aplikací může být tedy oddělený “data provider” a “end-user GUI” (modularita). [[https://pirati.cz/api|současná api]]
-  * **Opensource** Preferovaná SW licence: MIT, Apache 2, LGPL, GPL, ve vyjimečných případech se dají vyuzít i nesvobodné licence, pokud budeme mít práva software i datům. Chceme omezit riziko vzniku závislosti na neudržovaných / proprietárních / licenčně nevhodných technologiích a produktech. Preferujeme použití rozšířeného opensource před psaním vlastních projektů.
+  * **Opensource** Preferovaná SW licence: MIT, Apache 2, LGPL, GPL, ve vyjimečných případech se dají vyuzít i nesvobodné licence, pokud bude mít Pirátská strana práva na software i k datům. Chceme omezit riziko vzniku závislosti na neudržovaných / proprietárních / licenčně nevhodných technologiích a produktech. Preferujeme použití rozšířeného opensource před psaním vlastních projektů.
   * **Technologie** Při výběru technologií zohledňujeme, zda je vhodná, má budoucnost, máme na ni kapacity.  Příklady: Operační systém: Linux, nejčastěji CentOS či Debian. Jazyky: Python, node.js, Ruby, php. Databáze: Postrgesql, mariaDB, případně lze použít elastic search.
-  * **SSO** Prauje-li aplikace s uživateli, tak nesmí zakládat vlastní, ale použít přihlášení přes SSO.
+  * **SSO** Pracuje-li aplikace s uživateli, tak nesmí zakládat vlastní, ale použít přihlášení přes SSO (Single-Sign-On server běžící na adrese auth.pirati.cz).
   * **HW požadavky** Definovat požadavky na výkonnost aplikace, škálování na počet uživatelů, souběžných činností, load balancing.
-  * **Pirátský vizuál** Aplikace by měly mít jednoté UI/UX kopírující [[https://www.pirati.cz/download/|grafický manuál]]
+  * **Pirátský vizuál** Aplikace by měly mít jednoté UI/UX odpovídající [[https://www.pirati.cz/ke-stazeni/|grafickému manuálu]]
   * **Intuitivnost** Jednoduché intuitivní uživatelské rozhraní.
-  * **Data** Data ukládat do systémů, které jsou rozumně zálohované - např databází. Preferujeme bezstavové aplikace, které jsou vícenásobně deployovat.
+  * **Data** Data ukládat do systémů, které jsou zálohované, tj. např. do databází. Variantou lokálního ukládání dat jsou  bezstavové aplikace, které lze nasadit např. paralelně pro zvýšení výkonu.
   * **Zákonné požadavky** Analýza ochrany osobních údajů/GDPR, případně dalších zákonných požadavků.
   * **Důvěryhodnost** Ideální je mít v době, kdy představujete projekt, již nasazenou minimalistickou verzi. Nahradit to lze poukázáním na jiné již dokončené vaše projekty.
@@ Řádek 26: / Řádek 28: @@
 ==== Fáze implementace aplikace  ====
-  * **Testy** Unit testy v samotném kódu - zejména za účelem zabránění vzniku budoucích problémů při předávání vytvořené aplikace jinému vývojáři či správci.  U některých projektů může unit testy nahradit skutečnost, že software už široce rozšířený.
+  * **Testy** Unit testy v samotném kódu - zejména za účelem zabránění vzniku budoucích problémů při předávání vytvořené aplikace jinému vývojáři či správci.  U některých projektů může unit testy nahradit skutečnost, že je software už široce rozšířený.
-  * **Dokumentace** Vysvětlení architektury projektu, složitějších myšlenek. Deployment dokumentace - závislosti, postup nasazení, a podobně. Ideálem je samopopisný kód s inline dokumentací kde je třeba. Snadno předatelný kód.  V případě rozsáhlých projektů je nutné mít i administátorskou a uživatelskou dokumentaci.
+  * **Dokumentace** Vysvětlení architektury projektu, složitějších myšlenek. Deployment dokumentace - závislosti, postup nasazení, a podobně. Ideálem je samopopisný kód s inline dokumentací v místech, kde je třeba (více informací je lépe). Snadno předatelný kód.  V případě rozsáhlých projektů je nutné mít i administátorskou a uživatelskou dokumentaci.
-  * **Event-hooks ** vstupní a výstupní události pro komunikaci mezi aplikacemi. Řeší případy, kdy se změní data v jiné aplikaci a ostatní aplikace se o tom musí dozvědět. Příkladem je single-logout v SSO Keycloak.
+  * **Event-hooks ** vstupní a výstupní události pro komunikaci mezi aplikacemi. Řeší případy, kdy se změní data v jiné aplikaci a ostatní aplikace se o tom musí dozvědět. Příkladem je single-logout v SSO Keycloak (tj. odhlášení uživatele na pokyn Centrální identity.
-  * **Vizuál** šablonování end-user UI pro přád změny vizuálu
+  * **Vizuál** šablonování end-user UI pro případ změny designu aplikace
-  * **Verzování** Verzování zdrojového kódu označování stabilních části pro případný roll-back. Continous integration.
+  * **Verzování** Verzování zdrojového kódu, označování stabilních části pro případný roll-back. Continous integration.
 ==== Postup deploymentu & testování ====
-  * **Contejnery** Preferujeme použítí dockeru.
+  * **Kontejnery** Pro nasazení preferujeme použítí technologie Docker.
   * **Napojení** na stávající systémy.
-  * **Testovaní** Aplikaci budou testovat klíčoví uživatelé (AO, PO, ...) a menší testovací skupinky.  Bezpečnostní audit na nasazené verzi.
+  * **Testovaní** Aplikaci budou testovat klíčoví uživatelé (AO, PO, ...) a menší testovací skupinky. Je třeba provést bezpečnostní audit na nasazené verzi.
   * **Testování výkonnosti** Ověření výkonnosti aplikace, škálování na počet uživatelů, souběžných činností.
-  * **Prezentace** Zapracování toho, jak se bude používat do stávajících procesů strany.  Příprava nových návodů pro procesy ve straně.
+  * **Prezentace** Zapracování toho, jak se bude aplikace používat, do stávajících procesů strany.  Příprava nových návodů pro procesy ve straně.