EDUCATION, SYSTEMS ANALYSIS, BABOK

🔍 Sistēmanalīze - vizuāli piemēri

Ceļš no idejas līdz pārbaudītai prasībai: kas ir iesaistīts, kā prasības izzina un sakārto, kā tās pieraksta, modelē un izseko līdz testam. Piemēri balstīti uz šo platformu un ir vienkāršoti apmācībām.

ISO/IEC/IEEE 12207:2017 - dzīves cikls

SDLC: viena secība vai īsi atkārtoti cikli

Fāzes ir tās pašas. Atšķiras tas, cik reizes tās iziet: Waterfall - vienreiz visai sistēmai, iteratīvi - katrā sprintā mazai daļai.

SDLC: Waterfall un iteratīvā pieeja Augšā septiņas fāzes vienā secībā. Apakšā produkta krājums un trīs sprinti, katrs piegādā inkrementu, un pēc katra ir atgriezeniskā saite. Waterfall - vienreiz, lineāri PlānošanaPlanning PrasībasRequirements ProjektēšanaDesign IzstrādeImplementation TestēšanaTesting IeviešanaDeployment UzturēšanaMaintenance Iteratīvi (Agile, Scrum) - īsi sprinti, katrs piegādā daļu Produkta krājums backlog, prioritātes Sprints 1 (2 nedēļas) plāno - izstrādā - testē - pārskata Sprints 2 plāno - izstrādā - testē - pārskata Sprints 3 plāno - izstrādā - testē - pārskata inkrements 1 lietotājam inkrements 2 inkrements 3 atgriezeniskā saite pēc katra sprinta maina krājumu

Kad kuru

Waterfall - kad prasības ir stabilas un jāapstiprina iepriekš (līgums, regulējums). Iteratīvi - kad prasības mainās un vērtību grib piegādāt pa daļām.

Atsauces

ISO/IEC/IEEE 12207:2017, ISO/IEC/IEEE 15288:2023, Scrum Guide (2020), NIST SP 800-218 (SSDF).

Drošība katrā fāzē

Drošības prasības raksta kopā ar pārējām, ne pirms ieviešanas. Iteratīvi - katrā sprintā, kā daļu no gatavības definīcijas. Droša izstrāde.

Mendelow (1991) - ietekmes un intereses matrica

Kurš jāiesaista cieši, kurš tikai jāinformē

Ieinteresēto pušu ietekmes un intereses matrica Četri kvadranti: uzturēt apmierinātus, cieši iesaistīt, uzraudzīt, regulāri informēt, ar piemēra pusēm katrā. Ietekme (vara) → Interese → Uzturēt apmierinātuskeep satisfied Cieši iesaistītmanage closely Uzraudzītmonitor Regulāri informētkeep informed Valde, finansētājs Uzraudzības iestāde Produkta īpašnieks Galvenais klients Plašā sabiedrība Gala lietotāji Datu aizsardzības speciālists Pozīcija mainās projekta gaitā - matricu pārskata katrā fāzē.

Kad

Pirms prasību vākšanas: aizmirsta puse nozīmē aizmirstas prasības. Atkārto, kad mainās organizācija vai prioritātes.

Atsauces

Mendelow A. (1991), IIBA BABOK v3 (3.2 Plan Stakeholder Engagement), PMI PMBOK 7 (2021), ISO 21502:2020.

Drošības puses

Uzraudzība pēc Nacionālās kiberdrošības likuma ir dalīta starp kompetentajām iestādēm, incidentus ziņo incidentu novēršanas institūcijai (parasti CERT.LV) - agrīnais brīdinājums 24 h, paziņojums 72 h. Abas iekļauj sarakstā jau projekta sākumā.

IIBA BABOK v3 - 4. nodaļa, MoSCoW

Kā prasības iegūst, sakārto un padara pārbaudāmas

Izzināšana, MoSCoW un lietotāja stāsts Kreisajā pusē sešas izzināšanas metodes ar to stiprajām pusēm, vidū MoSCoW prioritātes, labajā lietotāja stāsts ar pieņemšanas kritērijiem. 1. Izzina Intervijadziļums, motīvi Darbnīcavienošanās starp pusēm Novērošanareālais darbs Aptaujadaudz respondentu Dokumentu analīzeesošie noteikumi Prototipsapstiprina izpratni 2. Sakārto (MoSCoW) Must - obligātibez tā izlaidumam nav jēgas Should - vajadzētusvarīgi, bet ir apkārtceļš Could - varētuja paliek laiks Won't - šoreiz nēpierakstīts, atlikts apzināti 3. Pieraksta pārbaudāmi Kā pircējs, es gribu filtrēt pēc kategorijas, lai ātri atrastu speciālistu. Pieņemšanas kritēriji Givenkategorijā ir 20 sludinājumi Whenizvēlos šo kategoriju Thenredzu tikai tās sludinājumus un to skaitu (20) kritērijs = tests, ko var palaist

Kā lietot

Vienu metodi nepietiek: intervija dod motīvus, novērošana - to, ko cilvēki patiesībā dara. Must daļai ieteicams ne vairāk par 60% no darba apjoma, citādi nav rezerves.

Atsauces

IIBA BABOK v3 (4. nod. Elicitation and Collaboration), ISO/IEC/IEEE 29148:2018, DSDM / AgilePM (MoSCoW), Cohn M. (2004) User Stories Applied, INVEST.

Drošības prasības

Izzina tāpat kā pārējās - ar stāstu "Kā uzbrucējs es gribu..." un OWASP ASVS kā kontrolsarakstu. Pieteikšanās aizsardzība ir Must, ne Could.

ISO/IEC/IEEE 29148:2018 - ISO/IEC 25010:2023

Četri prasību līmeņi - no "kāpēc" līdz "cik labi"

Prasību līmeņu piramīda Biznesa, lietotāju, funkcionālās un nefunkcionālās prasības ar šīs platformas piemēriem. Ierobežojumi attiecas uz visiem līmeņiem. Biznesa Lietotāju prasības Funkcionālās prasības Nefunkcionālās (kvalitāte) ISO/IEC 25010:2023 Kāpēc? Kam? Ko? Cik labi? piemērs - šī platforma BiznesaĀtrāk atrast pārbaudāmu speciālistu LietotājuKā pircējs meklēju pēc kategorijas FunkcionālāFiltrs atgriež 20 rezultātus lapā Nefunkcionālāp95 < 300 ms, 99,9%, 2FA Ierobežojumi - NIS2, VDAR, līgumi, tehnoloģija nav atsevišķs līmenis: tie ierobežo visus četrus

Kā lietot

Katrai zemākā līmeņa prasībai jāizriet no augstākā. Nefunkcionālā prasība ir izmērāma: nevis "ātri", bet "p95 < 300 ms".

Atsauces

ISO/IEC/IEEE 29148:2018 (aizstāj IEEE 830-1998), ISO/IEC 25010:2023, IIBA BABOK v3, OWASP ASVS.

Drošība ir kvalitātes prasība

Autentifikācija, šifrēšana un žurnāli ir nefunkcionālas prasības ar mērāmu kritēriju. NIS2 21. pants ir ierobežojums, no kura tās izriet.

UML 2.5.1 - misuse cases

Kas sistēmu lieto - un kā to varētu izmantot ļaunprātīgi

Lietojuma gadījumu diagramma ar ļaunprātīgas lietošanas gadījumiem Apmeklētājs, reģistrēts lietotājs un administrators lieto platformu. Uzbrucējs mēģina pārņemt kontu un viltot vērtējumu. Pieteikšanās ar 2FA mazina konta pārņemšanu. Platforma (sistēmas robeža) Apmeklētājs Reģistrētslietotājs Administrators Uzbrucējs Skatīt sludinājumus Meklēt pēc kategorijas Reģistrēties Publicēt sludinājumu Apmaksāt plānu Pieteikties ar 2FA Sūtīt ziņu Vērtēt speciālistu Moderēt saturu Pārņemt kontu Viltot vērtējumu «extend» «apdraud» «mazina» «apdraud»

Trīsstūra bulta - vispārināšana: reģistrēts lietotājs var visu, ko apmeklētājs. «extend» - neobligāts paplašinājums (bezmaksas plāns publicē bez apmaksas). Sarkanie - ļaunprātīgas lietošanas gadījumi.

Kad

Vācot prasības: attēls ļauj lietotājiem pārbaudīt, vai nekas nav aizmirsts. Katram gadījumam vēlāk raksta scenāriju un pieņemšanas kritērijus.

Atsauces

OMG UML 2.5.1 (2017), Cockburn A. (2001) Writing Effective Use Cases, Sindre G., Opdahl A. L. (2005) Eliciting security requirements with misuse cases.

Ļaunprātīgi gadījumi

Katram svarīgam gadījumam pajautā: kā to varētu izmantot uzbrucējs? Atbilde kļūst par drošības prasību - piemēram, 2FA pret konta pārņemšanu, parakstīti vērtējumi un moderācija pret viltojumiem.

BPMN 2.0 (ISO/IEC 19510:2013)

Process ar joslām: kurš ko dara un kur ceļš sazarojas

Piemērs - sludinājuma publicēšana. Joslas rāda, kas veic soli, vārteja - kur process izvēlas vienu no ceļiem.

BPMN process: sludinājuma publicēšana Speciālists aizpilda sludinājumu, platforma pārbauda laukus. Ja plāns ir bezmaksas, platforma publicē uzreiz. Ja maksas, speciālists apstiprina un maksā, maksājumu vārteja apstrādā maksājumu un paziņo platformai, kas publicē. Vārteja Speciālists Platforma Aizpilda sludinājumu Pārbauda laukus Apstiprina un maksā Apstrādā maksājumu Publicē Plāns? maksas bezmaksas paziņojums ar parakstu Publicēts

Plāns aplis - sākums, biezs aplis - beigas, noapaļots taisnstūris - uzdevums, rombs ar X - ekskluzīvā vārteja (tikai viens ceļš).

AS-IS un TO-BE

Vispirms modelē, kā process notiek tagad, tad - kā tam jānotiek. Starpība starp abiem ir atšķirību analīzes ievade.

Atsauces

OMG BPMN 2.0.2 (2014), ISO/IEC 19510:2013, IIBA BABOK v3 (10.35 Process Modelling).

Uzticamības robežas

Katra pāreja starp joslām, kas pieder dažādām organizācijām, ir uzticamības robeža. Tur vajag pārbaudi un žurnālu - piemēram, vārtejas paziņojuma paraksta pārbaudi pirms publicēšanas.

ISO/IEC/IEEE 29148:2018 - izsekojamības matrica

Katra prasība līdz testam un kontrolei - abos virzienos

Izsekojamības ķēde Mērķis, prasība, risinājums, tests un kontrole saistīti abos virzienos: uz priekšu - vai viss ieviests, atpakaļ - kāpēc tas vispār ir. Biznesa mērķisBR-01 PrasībaFR-03, NFR-07 Risinājumsmodulis, izmaiņa TestsTC-12, TC-31 KontroleISO 27001 A.8.5 → uz priekšu: vai katra prasība ir ieviesta un pārbaudīta ← atpakaļ: kāpēc šis kods vai tests vispār ir
IDPrasībaAvotsTestsKontroleStatuss
FR-03Filtrēt pēc kategorijasBR-01TC-12: tikai izvēlētā kategorija-Pārbaudīts
NFR-07Pieteikšanās ar 2FABR-02, NIS2 21. p. 2. d. j)TC-31: bez koda piekļuves navISO/IEC 27001 A.8.5Pārbaudīts
NFR-09Maksājuma paziņojums ar parakstuBR-03TC-40: viltots paraksts noraidītsISO/IEC 27001 A.8.24Pārbaudīts
FR-11Sūdzība par saturuDSA 16. p.--Nav testa - plaisa

Ko tas dod

Pierāda, ka nekas nav aizmirsts un nekas nav lieks. Mainot prasību, uzreiz redz, kurus testus un kontroles tas skar.

Atsauces

ISO/IEC/IEEE 29148:2018, IIBA BABOK v3 (5.1 Trace Requirements), ISO/IEC 27001:2022 A.8.25, A.8.29.

Audits

Auditors prasa tieši šo ķēdi: prasība - kontrole - pierādījums. Rinda bez testa ir atradums. Audita ceļvedis.

IIBA BABOK v3 - 6. nodaļa

Tagad, darbība, vēlamais - katra plaisa savā rindā

Vēlamais stāvoklis apraksta rezultātu, ko var izmērīt. Tehnoloģija ir darbība, kas pie tā noved.

Atšķirību analīze: pašreizējais, darbība, vēlamais Septiņas rindas, katrā pašreizējais stāvoklis, darbība un izmērāms vēlamais stāvoklis. Apakšā kopējie resursi. Tagad (AS-IS) Darbība Vēlamais (TO-BE), izmērāms 2FA tikai 30% kontuTOTP visiem, adminiem obligāti100% adminu, ≥80% lietotāju Nav audita žurnālaŽurnalēt piekļuvi un izmaiņasŽurnāls ≥12 mēn., pārskats ik mēn. Maksājumi pa e-pastuMaksājumu vārteja ar parakstuApmaksa automātiska, bez e-pastiem Kopija reizi nedēļāIkdienas šifrēta kopija ārpus vietasRPO ≤ 24 h, atjaunošana pārbaudīta Nav incidentu plānaIzstrādāt un izmēģināt plānuNIS2 paziņojums 24 h / 72 h Sertifikāti manuāliAutomātiska TLS atjaunošanaNav beigušos sertifikātu Tikai LV valodaPašmitināta EN tulkošanaLV + EN, dati paliek pie mums Resursi: ~3 mēneši - 2 inženieri - ~5 k EUR/gadā infrastruktūrai - ārējs audits ~3 k EUR

Kad

Plānojot izmaiņas vai gatavojoties auditam. Rinda bez izmērāma vēlamā stāvokļa nav pabeigta - nevar pateikt, kad plaisa ir slēgta.

Atsauces

IIBA BABOK v3 (6.1 Analyze Current State, 6.2 Define Future State, 6.4 Define Change Strategy), ISO/IEC 27003:2017.

NIS2 atbilstība

Kontroles salīdzina ar NIS2 21. panta 2. daļas a)-j) punktiem. Maksimālais sods: būtiskām struktūrām 10 M EUR vai 2%, svarīgām 7 M EUR vai 1,4% no gada apgrozījuma - lielākā no summām.

Saīsinājumi

Ceļvedī lietotie saīsinājumi: oriģinālais nosaukums un ko tas nozīmē.

SDLC
Software Development Life Cycle - programmatūras izstrādes dzīves cikls.
BABOK / IIBA
Business Analysis Body of Knowledge / International Institute of Business Analysis - biznesa analīzes zināšanu kopums un tā izdevējs.
MoSCoW
Must, Should, Could, Won't - prioritāšu metode: obligāts, vēlams, varētu, šoreiz nē.
INVEST
Independent, Negotiable, Valuable, Estimable, Small, Testable - laba lietotāja stāsta pazīmes.
NFR
Non-Functional Requirement - nefunkcionāla prasība - cik labi (ātrums, drošība, pieejamība).
BPMN
Business Process Model and Notation - biznesa procesu diagrammu standarts.
UML / OMG
Unified Modeling Language / Object Management Group - modelēšanas valoda un organizācija, kas to uztur.
DSDM / AgilePM
Dynamic Systems Development Method - Agile projektu metode, no kuras nāk MoSCoW.
PMBOK / PMI
Project Management Body of Knowledge / Project Management Institute - projektu vadības zināšanu kopums.
ASVS
Application Security Verification Standard - OWASP pārbaudāmo drošības prasību katalogs.
SSDF
Secure Software Development Framework - NIST drošas izstrādes prakses.
RPO
Recovery Point Objective - cik datus drīkst zaudēt avārijā.
VDAR
Vispārīgā datu aizsardzības regula - GDPR latviski.
TOTP
Time-based One-Time Password - laikā balstīts vienreizējs kods (autentifikatora lietotne).