Pagsusuri ng sistema sa IT

From Systems analysis Wiki
Jump to navigation Jump to search

Pagsusuri ng Sistema sa IT (Systems Analysis and Design) — isang diskarte sa pagdidisenyo at pagpapaunlad ng mga sistema ng impormasyon mula sa konsepto hanggang sa operasyon, na kinabibilangan ng pagtukoy ng mga pangangailangan, pag-pormal ng mga kinakailangan, pagmomodelo ng domain ng paksa at mga proseso, gayundin ang pagtatasa ng mga alternatibo at panganib. Sa madaling salita, ang pagsusuri ng sistema sa IT — ito ang yugto ng pagpapaunlad kung saan pinag-aaralan ng mga espesyalista ang gawain, tinutukoy kung ano ang dapat gawin ng sistema, at binubuo ang mga solusyon para sa paglikha nito.

Klasikong pagsusuri ng sistema ay sumasaklaw sa malawak na hanay ng mga larangang inilalapat, hindi lamang ang pagpapaunlad ng software, kundi pati na rin ang mga pagbabago sa organisasyon, mga estratehiya at iba pang aspeto.[1] [2]

Paksa at mga Gawain ng Pagsusuri ng Sistema sa IT

Paksa ng pagsusuri ng sistema sa IT ay ang sistema ng impormasyon (software na produkto at/o serbisyo) sa buong ikot ng buhay nito — mula sa konsepto at pagpapatibay hanggang sa pagpapatupad at operasyon.

Gawain ng pagsusuri ng sistema — baguhin ang mga pangangailangan ng negosyo sa isang magkakatugmang at nabe-verify na hanay ng mga kinakailangan at mga desisyon sa arkitektura: tukuyin at idokumento ang mga layunin at limitasyon ng mga stakeholder, i-pormal ang mga kinakailangan, i-modelo ang domain ng paksa at mga proseso, suriin ang kakayahang isagawa at mga panganib ng mga alternatibo, at bigyang-katwiran ang napiling arkitektura. Bilang resulta, nilikha ang mga magkakatugmang dokumento at naitatag ang mga sinusubaybaygang ugnayan sa pagitan ng mga kinakailangan, mga desisyon sa proyekto, at mga pagsubok. Tinitiyak nito ang pamahalaan at kontrol sa proseso ng pagpapaunlad.

Kasama sa mga gawain ng pagsusuri ng sistema ang:

  • Pagtukoy ng mga pangangailangan at layunin ng mga stakeholder. Kinokolekta at nililinaw ng analista ang mga inaasahan ng mga customer, gumagamit, at iba pang mga interesadong partido; ginagamit ang mga panayam, survey, obserbasyon, at pagsusuri ng kasalukuyang mga proseso. Sa output, nabubuo ang pangunahing na espesipikasyon ng mga kinakailangan na may paghahati sa mga functional («ano ang dapat gawin ng sistema») at non-functional (pagiging maaasahan, pagganap, seguridad, atbp.).[1][2]
  • Pag-pormal at dokumentasyon ng mga kinakailangan. Ang mga kahilingan ay ginagawang napapatunayan na mga kinakailangan. Ang isang mahusay na binuong kinakailangan ay dapat na malinaw at hindi malabo, kumpleto, walang kontradiksyon, napapatunayan, at matatrace sa mas mataas na antas na mga layunin; ang hanay ng mga kinakailangan — magkakatugma at buo.[3][4] Sa pagsasanay, ginagamit ang mga standardisadong dokumento: SRS (Software Requirements Specification) ayon sa ISO/IEC/IEEE 29148, gayundin, sa ilang mga industriya, URS (User Requirements Specification) at mga functional na espesipikasyon.[5][6][7]
  • Pagsusuri at pagmomodelo ng sistema. Para maunawaan kung paano gagana at makikipag-ugnayan ang sistema sa labas ng mundo, binubuo ang mga modelo: mga diagram ng use case para sa mga senaryo ng paggamit, DFD para sa mga daloy ng data at mga proseso ng negosyo, mga diagram ng klase/sangkap, atbp. Ang mga modelo ay nagsisilbing batayan para sa paghahambing ng mga alternatibong solusyon at arkitektura.[8][9][10]
  • Pagtatasa ng kakayahang isagawa at pagpili ng solusyon. Isinasagawa ang feasibility study (teknikal, organisasyon, ekonomikal, kalendaryo na kakayahang isagawa) at paghahambing ng mga alternatibo sa arkitektura (trade-off). Para sa pagtatasa ng kalidad ng arkitektura ayon sa mga katangian (hal., pagganap, scalability, modifiability) ginagamit ang mga pamamaraan tulad ng ATAM (Architecture Tradeoff Analysis Method).[11][12] Ang pagpili sa pagitan ng, halimbawa, monolitic at microservices na arkitektura [3] ay nakabatay sa malinaw na mga kompromiso (kumplikado ng operasyon vs. independyenteng scalability at bilis ng paghahatid) ayon sa mga rekomendasyon ng mga gabay ng industriya.[13][14]
  • Paghahanda ng mga artifact ng proyekto. Batay sa mga resulta ng pagsusuri, nabubuo ang:
    • naaprubahang espesipikasyon ng mga kinakailangan (na may indikasyon ng kanilang kahalagahan),
    • konseptywal na modelo ng sistema (mga diagram/paglalarawan),
    • mga desisyon sa arkitektura at disenyo (mga iskema ng data, mga interface ng mga panlabas na sistema),
    • plano ng pagpapatupad (mga yugto/modyul).
    • Kritikal na tiyakin ang traceability (bidirectional traceability) ng mga kinakailangan sa mga elemento ng disenyo at mga pagsubok.[15][4]

Ang tagumpay ng proyektong IT ay lubos na nakasalalay sa mga mature na gawi sa pagtatrabaho sa mga kinakailangan at arkitektura. Ang pag-aaral na isinagawa ng McKinsey at Oxford ay nagpakita na ang malalaking proyektong IT ay madalas na lumagpas sa badyet at mga takdang panahon. Binibigyang-diin din ng pag-aaral na ito kung gaano kahalaga ang tamang pamamahala ng estratehiya, pakikipag-ugnayan sa mga interesadong partido, at marunong na pangangalap ng mga kinakailangan. Lahat ito ay maaaring lubos na makaapekto sa tagumpay o kabiguan ng proyekto.[16]

Mga Diskarte at Metodolohiya sa Pagsusuri ng Sistema sa IT

Ang pagsusuri ng sistema sa IT ay nakabatay sa mga prinsipyo ng sistemas na pag-iisip at mga pamamaraang inangkop para sa pagpapaunlad ng software. Sa pagsasanay, pinagsama ang mga «mahirap» at «malambot» na diskarte, mga strukturadong metodolohiya, mga notasyon na nakatuon sa object, gayundin ang mga wika sa pagmomodelo ng mga proseso at kinakailangan.

  • Mahirap at malambot na mga diskarte. Sa mga proyektong IT, ang mahirap na diskarte (hard systems) ay nagpapalagay ng mga layunin at kinakailangan na maaaring i-pormal nang maaga, decomposition, at pagdidisenyo «mula sa itaas pababa». Ang malambot na diskarte (soft systems) ay ginagamit kapag ang mga layunin ay hindi malinaw at may maraming pananaw: ginagamit ang mga elemento ng Soft Systems Methodology (SSM) (hal., rich picture, mga root definition, CATWOE) para sa pagkakaisa ng pag-unawa sa problema at mga nais na pagbabago; pagkatapos ay isinasalin ang mga resulta sa mga formal na kinakailangan.[17][18]
  • Metodolohiya ng SSM (Soft Systems Methodology). Orihinal na binuo ni Peter Checkland para sa mga pagbabago sa organisasyon, ang SSM ay kapaki-pakinabang sa mga pre-project na yugto ng IT: mula sa pag-aaral ng problematikong sitwasyon at pagbubuo ng mga root definition (kasama ang sa pamamagitan ng CATWOE) hanggang sa paghahambing ng mga konseptywal na modelo sa katotohanan at pagkamit ng akomodasyon sa pagitan ng mga stakeholder.[19][20]
  • Mga Strukturadong Metodolohiya: SADT/IDEF0. Ang SADT ay nagmomodelo ng sistema bilang isang hierarchy ng mga function; ang standard na notasyon ng IDEF0 (IEEE 1320.1) ay nagtatala ng mga function at ang kanilang mga interface ng I-C-O-M (Inputs, Controls, Outputs, Mechanisms). Ang pamamaraan ay maginhawa para sa functional decomposition at pagkakaisa ng mga hangganan ng sistema nang hindi isinasaalang-alang ang mga algorithm.[21][22]
  • Pagsusuri na nakatuon sa object: UML at SysML (MBSE). Naging pangunahing wika ang UML para sa mga kinakailangan at disenyo (mga diagram ng use case, klase, pagkakasunud-sunod, atbp.) at pinapadali ang pagpapatunay ng mga senaryo sa mga gumagamit; pinalawak ng SysML ang UML para sa systems engineering (mga diagram ng kinakailangan, parametric na mga diagram) at nakabatay sa diskarte ng MBSE, kung saan ang modelo ay ang sentral na artifact sa buong mga yugto mula sa mga kinakailangan hanggang sa mga pagsubok.[23][24][25]
  • Pagmomodelo ng mga proseso ng negosyo: BPMN. Ang pamantayan ng BPMN ay ginagamit para sa graphical na paglalarawan ng mga proseso (mga pool, mga daloy ng trabaho, mga kaganapan, mga gateway), kasama ang paghahambing ng as-is/to-be sa mga espesipikasyon ng kinakailangan at integrasyon.[26][27]
  • Ugnayan sa requirements engineering. Ang proseso ay kinabibilangan ng mga yugto ng elicitation–analysis–specification–validation–change management; ang mga pamantayan ng «magandang kinakailangan» at ang istraktura ng SRS ay kinokontrol ng ISO/IEC/IEEE 29148. Para sa priyoritisasyon, ginagamit ang mga teknik ng MoSCoW (Must/Should/Could/Won't) at mga pamamaraan ng multi-criteria na pagpili, halimbawa ang AHP. Sa mga flexible na proseso, ang aktibidad ng pagsusuri ng sistema ay makikita sa backlog refinement at traceability ng mga kinakailangan.[28][29][30][31]
  • Ugnayan sa systems engineering. Para sa mga kumplikadong (cyber-physical) na sistema, ginagamit ang V-model: sa «kaliwang» sangay — pagsusuri ng sistema at arkitektura, sa «kanang» sangay — integrasyon, verification, at validation na may ugnayan sa mga artifact ng kaliwang sangay. Kasama sa mga pamamaraan ng pagtatasa ng arkitektura ayon sa mga qualitative na katangian ang ATAM (trade-off analysis).[32][33]

Pinagsasama ng pagsusuri ng sistema sa IT ang mga napatunayang diskarte — mula sa malambot na mga pamamaraan ng pagkakaisa ng bisyon hanggang sa mga formal na notasyon at pamantayan. Ang pagpili ng mga kasangkapan ay tinutukoy ng antas ng katiyakan ng gawain: sa mataas na kawalan ng katiyakan, mas malaki ang papel ng SSM at fasilitasyon, sa malinaw na mga hangganan — mga formal na modelo (UML/SysML, IDEF0, BPMN) at mga regulasyon.

Ugnayan sa Arkitektura ng IT at Arkitektura ng Negosyo

Ang pagsusuri ng sistema sa mga proyektong IT ay malapit na nauugnay sa architectural na disenyo. Nagtatagpo ang mga papel ng analista at arkitekto: ang analista ay bumubuo ng mga kinakailangan at logical na modelo, ang arkitekto ay nagtatakda ng target na istraktura ng solusyon at mga teknikal na kompromiso; ang trabaho ay isinasagawa nang magkasama.

  • Arkitektura ng mga sistema ng IT. Sa makitid na kahulugan, ang arkitektura ng software — ito ang organisasyon ng mga sangkap, ang kanilang mga relasyon, at mga prinsipyong ginagabayan sa pagdidisenyo ng solusyon. Mahalaga para sa analista na isaalang-alang ang mga architectural style (layered, client–server, microservices, event-driven, atbp.), dahil ang mga non-functional na kinakailangan (pagiging maaasahan, scalability, modifiability) ay madalas na nagtatakda ng mga desisyon sa arkitektura at ang kanilang mga kompromiso.[34][35] Sa maagang yugto ng pagsusuri, binubuo ang architectural vision (high-level vision) at binibigyang-elaborasyon ang paunang balangkas ng solusyon para sa pag-verify ng kakayahang isagawa ng mga kinakailangan (ang haba ng mga iterasyon at detalye ay nakasalalay sa metodolohiya).[36]
  • Mga template at paunang desisyon. Para sa kasiyahan ng mga non-functional na kinakailangan, ginagamit ang mga architectural pattern. Halimbawa, para sa asynchronous na pakikipag-ugnayan at loosely-coupled na koneksyon — publish–subscribe sa pamamagitan ng message broker sa event-driven na arkitektura.[37]
  • TOGAF (The Open Group Architecture Framework). Isa sa mga pinaka-laganap na framework ng corporate na arkitektura; kinabibilangan ng pamamaraan ng ADM (Architecture Development Method) at mga artifact ng pamamahala ng arkitektura (repositoryo, mga katalogo/matris, mga prinsipyo). Sa TOGAF, ang pamamahala ng mga kinakailangan ay isang cross-cutting na proseso, na integrado sa lahat ng mga yugto ng ADM.[36] Para sa suporta ng mga kinakailangan at traceability, ginagamit ang mga katalogo at matris (hal., mga kinakailangan ↔ mga serbisyo, mga function ↔ mga sangkap), at pinaghihiwalay din ang Architecture Building Blocks at Solution Building Blocks.[38][39] Ang mga prinsipyo at pamantayan ng negosyo ay naitala sa mga kaukulang katalogo at nagsisilbing mga panlabas na non-functional na kinakailangan para sa mga koponan ng proyekto.[40] Ang pagsunod ng mga solusyon sa target na arkitektura ay kinukumpirma ng pamamaraan ng architectural compliance review (Architecture Compliance Review).[41] Ang diskarte ng TOGAF ay nagpapalagay ng paunang Architecture Vision at kasunod na detalye (data/mga aplikasyon/mga teknolohiya) na may plano sa migrasyonal at pamamahala ng mga pagbabago ng kinakailangan.[42][43]
  • Zachman Framework. Isang maagang at maimpluwensyang ontolohiya ng mga artifact ng arkitektura ng negosyo, na ipinakita bilang isang 6×6 matris (mga pananaw × mga aspeto «ano/paano/saan/sino/kailan/bakit»). Ang hilera ng «designer» ay nauugnay sa pagsusuri ng sistema at disenyo; ang mga kolum ay nagtatakda ng pagkakumpleto ng pagsasaalang-alang ng data, mga function/proseso, mga papel, lokasyon, at motibasyon. Ang framework ay nagsisilbing klasipikasyon (at hindi metodolohiya) at tumutulong na tiyakin ang pagkakumpleto ng paglalarawan ng solusyon sa landscape ng negosyo.[44]
  • Ugnayan sa Arkitektura ng Negosyo (Enterprise Architecture, EA). Ang sistema ng analista ay nagtatrabaho sa konteksto ng EA: ang mga bagong kinakailangan ay nagtatrace sa mga kakayahan sa negosyo at operational na modelo; ginagamit ang mga pamantayan at prinsipyal na limitasyon ng negosyo (seguridad, compatibility, atbp.).[45][36] Sa yugto ng inisyasyon, nabubuo ang Architecture Vision (mga layunin/limitasyon, mga pinagsama-samang kinakailangan), pagkatapos ay nagdedetalye ang analista, na pinapanatili ang traceability sa bisyon at mga corporate na pamantayan; ang hindi pagsunod sa mga pamantayan ay natutukoy sa mga architectural review at maaaring humantong sa mga revision ng solusyon.[36][46]

Sa kabuuan: ang pagsusuri ng sistema at architectural na disenyo ay bumubuo ng ugnayan na «mga kinakailangan → mga desisyon sa arkitektura → mga kompromiso sa mga katangian ng kalidad». Ang pagpili ng mga pamamaraan (mga estilo/template, mga artifact ng TOGAF, klasipikasyon ng Zachman) ay tinutukoy ng kalikasan ng proyekto at ng balangkas ng corporate na arkitektura.

Mga Proseso at Gawi

Ang pagsusuri ng sistema ay integrado sa buong ikot ng buhay ng pagpapaunlad at operasyon ng software, na nag-uugnay ng mga layunin ng negosyo, arkitektura, at paghahatid. Kasama ang pre-project na pananaliksik, pagpili ng diskarte, pagbuo ng mga napapatunayan na artifact, at mga kinakailangan para sa pagiging maaasahan, pagganap, seguridad, at pagpapanatili. Sa cascading na modelo, ang pagsusuri ay isinasagawa bago ang disenyo at pagpapatupad; sa mga flexible na pamamaraan — patuloy sa pamamagitan ng mga iterasyon; at sa DevOps — na may diin sa mga layunin ng operasyon. Anuman ang diskarte, tinitiyak ng pagsusuri ang traceability, pamamahala ng mga pagbabago at panganib, dokumentasyon ng mga arkitekturang kompromiso, at pagsunod sa mga regulatoryong limitasyon, na ginagawang predictable at mapamahalaan ang pagpapaunlad.

  • Klasikong SDLC (Waterfall). Ang yugto ng System Analysis & Requirements Definition ay nauuna sa disenyo at pagpapatupad; ang mga kinakailangan ay naitala sa detalyadong SRS bilang batayan ng pagpaplano at mga kontrata. Epektibo sa mga matatag at regulated na domain; ang mga panganib ng «pag-freeze» ng mga kinakailangan ay nababawasan ng SRR/review at pamamahala ng mga pagbabago sa pamamagitan ng CCB.[47][48][49]
  • Mga Flexible na Metodolohiya (Agile). Patuloy ang pagsusuri: sa halip na panghuling SRS, pinapanatili ang product backlog mula sa mga user story na may mga pamantayan ng pagtanggap, na nililinaw sa backlog refinement; ginagamit ang BDD (Given–When–Then); ang panganib ng pagkawala ng integral na arkitektura ay kinokompensahan ng maagang architectural na elaborasyon at transparent na traceability ng mga kinakailangan ↔ pagpapatupad/mga pagsubok.[50][51][52]
  • DevOps at SRE. Ang madalas na mga release ay nangangailangan ng mga operational na kinakailangan «bilang default»: automation, observability, rollback. Ang mga non-functional na kinakailangan ay binubuo bilang SLO/SLI, pinamamahalaan ang error budget; ang mga gawain para sa mga log/metric/trace/alert ay idinaragdag sa backlog; para sa release nang walang downtime — mga pattern na blue/green at iba pa.[53][54][55]
  • Pamamahala ng mga kinakailangan at panganib. Ang mga kinakailangan sa ALM ay may mga status at ugnayan sa mga gawain/release/depekto; obligatoryo ang version control, change impact analysis, at regular na re-priyoritisasyon.[56][57]
  • Pagtitiyak ng kalidad (QA). Ang kalidad ay inilalagay sa yugto ng mga kinakailangan: review, «Three Amigos», plano ng Acceptance Test Plan, mga automated na pagsubok ng mga pamantayan ng pagtanggap (BDD/ATDD).[58][59]
  • Observability at pagiging maaasahan. Kasama sa mga kinakailangan ang SLA/SLO, MTTR at MTBF na may mga nasusukat na layunin at mga pamamaraan ng kontrol; ang mga parameter ay nagmumula sa negosyo/operasyon at inilalagay sa arkitektura at mga pagsubok ng pagiging maaasahan.[60][61]

Mga Sukatan at Kalidad ng mga Artifact

Para sa pagtatasa ng trabaho ng sistema ng analista at kalidad ng kanyang mga resulta, ginagamit ang mga pangkalahatang tinatanggap na pamantayan. Ang mga kalidad na kinakailangan at modelo — pundasyon ng isang matagumpay na proyekto, kaya't pinamahalaan ang mga ito sa buong ikot ng buhay (elicitation → specification → verification/validation → change management). Ang mga pangunahing katangian ng kalidad ng mga kinakailangan ay nakasaad sa mga pamantayan ng ISO/IEC/IEEE 29148 at (sa kasaysayan) IEEE 830.[3][62][1]

  • Kawastuhan (Correctness) — ang kinakailangan ay sumasalamin sa tunay na pangangailangan at napagkasunduan sa mga eksperto sa domain ng paksa; kinukumpirma ng validation (review/inspection, mga prototype, mga senaryo).[1][4]
  • Pagkakumpleto (Completeness) — ang mga mahalagang aspeto at kondisyon ay isinaalang-alang.
    • Pagkakumpleto ng isang indibidwal na kinakailangan: ang mga kinakailangang detalye ay tinukoy (hal., «ang indicator ay lumilipat sa status na pula sa pagkabigo», hindi lamang «nagiging pula»).
    • Pagkakumpleto ng espesipikasyon: ang mga senaryo/papel ay natatakpan, ang NFR ay natukoy; naaabot sa pamamagitan ng mga checklist at traceability sa mga layunin ng negosyo; kapaki-pakinabang ang independyenteng audit ng pagkakumpleto (QA/review).[3][63]
  • Kawalan ng Kalabuan (Unambiguity) — ang mga pormulasyon ay binibigyang-kahulugan sa iisang paraan; timutulong ang glossary, mga template ng uri na «ang sistema ay dapat gumawa ng A, kapag B, kung C», mga halimbawa; ang mga diagram ay sinasamahan ng mga legend. Pag-verify — prinsipyo ng «apat na mata».[3][1]
  • Pagkakatugma (Consistency) — ang mga kinakailangan ay hindi nagkakasalungatan sa isa't isa at sa mga panlabas na limitasyon; ginagamit ang istrakturasyon, mga pinagsamang talahanayan ng mga katangian, mga koponan na review; inihahambing ang regulasyon/pamantayan.[3][63]
  • Napapatunayan/Nate-test (Verifiability) — ang pagkamit ay kinukumpirma ng pagsubok/demonstrasyon/pagsusuri; ang mga hindi napapatunayan na pormulasyon ay pinapalitan ng mga nasusukat na pamantayan; para sa NFR, ang mga sukatan ay natutukoy at ang mga pamantayan ng pagtanggap ay naitala nang maaga.[3][63]
  • Pagbabago at Traceability (Modifiability & Traceability) — mga natatanging ID, logical na istraktura («isang ideya — isang talata»), kawalan ng mga duplicate; pinapanatili ang mga ugnayan na «kinakailangan ↔ pinagmulan/layunin/disenyo/pagsubok», pinapanatili ang matris ng traceability (RTM).[64][3]
  • Pag-ranggo at priyoritisasyon — kalidad ng hanay ng mga kinakailangan; ginagamit ang mga teknik ng MoSCoW at MCDM (hal., AHP); ang priyoritisasyon kasama ang negosyo ay nakakaimpluwensya sa pagpaplano at mga panganib.[65][66]

Mga sukatan ng kalidad ng mga kinakailangan (mga halimbawa):[63][1]

  • density ng mga depekto ng kinakailangan (mga komento sa bawat 100 kinakailangan);
  • bilang ng mga pagbabago pagkatapos ng baseline na pag-fix;
  • mga sukatan ng coverage: bahagi ng mga kinakailangan na may mga pagsubok; bahagi ng mga kinakailangan na nagtatrace sa mga layunin ng negosyo;
  • katatagan ng mga kinakailangan (ratio ng mga idinagdag/tinanggal sa kabuuang bilang sa panahon);
  • laki/kumplikasyon ng espesipikasyon (average na bilang ng mga kinakailangan sa use case, lalim ng decomposition);
  • kasiyahan ng mga stakeholder (survey).

Sa mga mature na proseso (hal., CMMI antas 3+) may mga regulasyon ng kalidad ng mga kinakailangan: mga formal na pagsusuri, mga audit ng pagsunod sa mga template, koleksyon/pagsusuri ng mga sukatan.[67] Sa mga kritikal na domain (aviasyon, espasyo, atbp.) ginagamit ang mga formal na pamamaraan para sa pagpapahusay ng pagiging maaasahan.[68]

Mga Karaniwang Pagkakamali

Sa mga proyektong IT, madalas na makikita ang mga pagkakamali sa pagsusuri ng sistema: pagkukulang at kalabuan ng mga kinakailangan, mga kontradiksyon, malabong mga hangganan, pagwawalang-bahala sa mga non-functional na aspeto, napalampas na integrasyon, at nahuling seguridad. Humahantong ito sa mga muling paggawa, pagkaantala, pagtaas ng mga gastos, at mga depekto.

Mga karaniwang problema, ang kanilang mga kahihinatnan at mga paraan ng pag-iwas.

  • Pagkukulang at mga napalampas na kinakailangan. Naliligaw ang mga papel na may espesyal na mga karapatan, mga edge case, at NFR. Mga kahihinatnan: muling paggawa ng arkitektura at pagpapaliban ng paglulunsad. Paano umiwas: mga checklist, mga brainstorm na «paano kung…», maagang pakikilahok ng mga tester, traceability sa mga layunin ng negosyo.[1][69]
  • Mga malabo, ambiguous na pormulasyon. Mga kahihinatnan: ipinapatupad ng mga developer ang «maling bagay», hindi nasisiyahan ang customer. Paano umiwas: mga nasusukat na pamantayan, glossary, mga template na «A, kapag B, kung C», peer‑review.[3][69]
  • Mga magkasalungat na kinakailangan. Mga kahihinatnan: mga pagkaantala sa mga paglilinaw, muling paggawa sa integrasyon. Paano umiwas: istrakturasyon, paghahambing ng mga panuntunan sa negosyo/regulasyon, mga sesyon ng pagresolba ng mga salungatan, pagsusuri ng pagkakatugma sa review.[3][1]
  • Sindrom ng «gold‑plating». Mga kahihinatnan: paglaki ng dami, pagkukumplikado, mga bagong punto ng pagkabigo. Paano umiwas: pag-uugnay ng bawat kinakailangan sa layunin/sukatan; sa Agile — huwag isama ang hindi kailangan sa backlog; i-fix ang scope; tingnan ang YAGNI.
  • Labis na detalye kung hindi kailangan. Paano umiwas: paghiwalay ng ano/bakit (mga kinakailangan) mula sa paano (disenyo/pagpapatupad); pag-apply ng design‑free requirements kung saan naaangkop.[3]
  • Paglabag sa pamamahala ng kinakailangan. Mga kahihinatnan: kalituhan ng mga bersyon, pagpapatupad ng «maling bagay». Paano umiwas: iisang pinagkukunan ng katotohanan sa ALM, historikal na datos at mga status, RTM at change impact analysis; pamamahala ng mga pagbabago sa pamamagitan ng CCB.[64][1]
  • Kawalan ng pakikilahok ng mga gumagamit. Paano umiwas: mga panayam, obserbasyon, mga prototype, mga regular na pagpapakita; malinaw na validation sa mga stakeholder.[3][1]
  • Masyadong matagal na «analytical paralysis». Paano umiwas: zone ng sapat na antas, iterativity at timeboxing; paglulunsad ng MVP/mga increment at pagwawasto batay sa feedback.[1]
  • Pagwawalang-bahala sa mga non-functional na kinakailangan. Paano umiwas: paghiwalay ng NFR (hal., FURPS+), pagtatakda ng mga nasusukat na pamantayan, pagsasama ng mga ito sa plano ng pagsubok at mga desisyon sa arkitektura.[1][3]
  • Mga pagkakamali sa komunikasyon at «human factor». Paano harapin: paunlarin ang pakikipaganayam at fasilitasyon, mapanatili ang neutralidad, itala ang mga desisyon at mga pinagmulan ng mga kinakailangan (traceability sa mga layunin).[1]

Ang karamihan sa mga problema ay nagmumula sa kalidad ng mga pormulasyon, pagkakumpleto, at pamamahala ng mga kinakailangan; ang paglalapat ng mga pamantayan ng ISO/IEC/IEEE 29148 at mga gawi ng SWEBOK (validability, traceability, iterativity) ay lubos na nagpapababa ng panganib ng mga pagkaantala at muling paggawa.[3][1]

Mga Limitasyon

Sa kabila ng kahusayan nito sa pagbababa ng kawalan ng katiyakan, ang pagsusuri ng sistema ay may sariling mga limitasyon:

  • Ang katotohanan ay nagbabago at kumplikado. Imposibleng isaalang-alang ang lahat ng mga salik, lalo na sa mga pangmatagalang proyekto. Ang ilang mga kinakailangan ay hindi maiiwasang lumitaw pagkatapos ng paglulunsad ng sistema. Mahalaga na magsikap na mabawasan ang mga sorpresa, ngunit kailangang maging handa sa mga pagbabago.
  • Ang mga kinakailangan ay nakasalalay sa mga tao. Ang mga priyoridad ng negosyo, mga batas, at merkado ay maaaring magbago. Ang pagsusuri ng sistema ay nagtatala ng kasalukuyang estado at hindi maaaring mahulaan ang lahat ng mga panlabas na pagbabago. Upang mag-adapt, kinakailangang regular na i-update ang mga kinakailangan at magtrabaho nang iterative.
  • Hindi palagi alam ng mga gumagamit kung ano ang gusto nila hanggang hindi nila ito makita. Ito ay isang kilalang limitasyon. Ang prototyping at mga flexible na metodolohiya, tulad ng Agile, ay tumutulong na malagpasan ang problemang ito. Ang pagsusuri sa papel ay may sariling mga limitasyon, at para makakuha ng tumpak na data kailangan ng feedback mula sa mga pagpapatupad.
  • Balanse sa pagitan ng oras at kalidad. Ang labis na detalyadong pagsusuri ay maaaring maging lipas na. Sa mga innovative na larangan, mas mainam na mabilis na lumikha ng minimum viable product (MVP) at makakuha ng tunay na data. Ang pagsusuri ng sistema ay epektibo sa mga matatag na larangan, ngunit sa mga exploratory na proyekto (R&D) ang papel nito ay limitado.
  • Kadahilanan ng tao. Kahit ang pinakamahusay na mga metodolohiya ay hindi nagkokompensahan sa incompetence ng analista o kawalan ng availability ng customer. Mahalaga na ang lahat ng mga kalahok sa proseso ay involved at motivated.

Impluwensya ng Modernong Teknolohiya sa Pagsusuri ng Sistema sa IT

Ang pagsusuri ng sistema sa IT ay patuloy na umuunlad sa ilalim ng impluwensya ng mga teknolohikal na inobasyon. Ang analista ng ika-21 siglo ay nagtatrabaho sa mga kondisyon ng mabilis na paglago ng data, laganap na pagpapatupad ng AI, mabilis na ikot ng pagpapaunlad, at mas mataas na atensyon sa seguridad. Ang matagumpay na pagsasanay ng pagsusuri ng sistema ay nangangailangan ng pag-aaral ng mga bagong kaalaman (Data Science, cybersecurity, mga teknolohiya sa ulap) at kakayahang umangkop sa paglalapat ng mga pamamaraan.

  • Data at AI/ML: ano ang idinaragdag sa pagsusuri. Para sa mga sistema na may AI, mula pa sa simula, itinatala ang mga layunin at konteksto ng aplikasyon, mga kinakailangan sa mga pinagkukunan at kalidad ng data, gayundin ang mga sukatan ng tiwala sa mga desisyon ng modelo (pagiging maaasahan, seguridad, explainability, confidentiality, fairness). Pinaplano ang mga pagsusuri ng TEVV (testing, evaluation, verification, validation), pagmamatyag sa operasyon, at ligtas na pagpapatay/pag-retire ng modelo. Ang mga hakbang na ito ay tumutugma sa mga function ng GOVERN–MAP–MEASURE–MANAGE mula sa NIST AI Risk Management Framework; isinasalamin ang mga ito sa SRS, arkitektura, at mga plano ng verification/operasyon.[70]
  • DevSecOps: seguridad «sa kaliwa» at bilang default. Ang pag-embed ng seguridad sa bawat yugto ng CI/CD ay nagiging pamantayan: mga automated na pagsusuri (SAST/DAST), pag-scan ng mga dependency at container, mga patakaran sa deployment, pangunahing observability. Ginagamit ang mga trusted na registry ng artifact at standardisadong «hardened» na mga imahe; inilalapat ang mga prinsipyo ng zero trust. Sa pagsusuri ng sistema, ang mga control point ng pipeline (mga kondisyon ng paglipas ng mga yugto), ang ugnayan ng mga kinakailangan sa mga kontrol ng seguridad, at ang mga panuntunan ng paglipat sa pagitan ng mga kapaligiran (dev/test/stage/prod) ay inilarawan nang maaga.[71]
  • Ano ang nagbabago sa mga dokumento (mga artifact). Kung anong seksyon ang lumalabas o nililinaw sa mga pangunahing dokumento kapag may Big Data at AI/ML at kapag nagtatrabaho ayon sa DevSecOps:
    • SRS / Espesipikasyon ng kinakailangan: mga layunin at konteksto ng aplikasyon ng AI; mga kinakailangan sa data (pinagmulan, kalidad, etikal at legal na mga limitasyon); mga sukatan ng modelo (katumpakan, pagiging maaasahan, oras ng pagtugon); plano ng TEVV (testing, evaluation, verification, validation); mga kinakailangan sa transparency/explainability at privacy; mga pamantayan ng pagpapatay/pag-retire ng modelo mula sa operasyon.[70]
    • Arkitektura at mga desisyon (Architecture, ADR): mga resulta ng threat modeling; mga hakbang na «seguridad bilang default» (encryption, access control, secret‑management, prinsipyo ng least privilege); mga limitasyon sa paggamit ng data/mga modelo; mga tala ng ADR na may pagtatasa ng mga panganib at kompromiso.[71][70]
    • Plano ng verification at validation (V&V / TEVV): mga senaryo ng pagsubok ng mga modelo at data; mga threshold ng pagtanggap para sa mga sukatan ng kalidad; pagmamatyag ng drift ng data/modelo; mga pamamaraan ng periodic na muling pagtatasa at muling validation.[70]
    • Mga patakaran ng CI/CD at mga «gate» ng pipeline: mga automated na pagsusuri ng SAST/DAST, SCA (mga dependency), pag-scan ng container; paglagda at pag-iimbak ng mga artifact sa mga trusted na registry; mga panuntunan ng promosyon sa pagitan ng mga kapaligiran (dev/test/stage/prod) at mga kondisyon ng pag-block ng build sa pagkabigo ng mga pagsusuri; mga kinakailangan sa observability bilang default.[71]
    • Plano ng pamamahala ng data at mga modelo: katalogo ng mga pinagkukunan at lineage; mga pamantayan ng kalidad at availability ng data; mga bersyon ng dataset/modelo; iskedyul ng (re)training at kontrol ng bias; patakaran ng access at pag-iimbak; plano ng ligtas na deactivation ng modelo at pagtanggal ng data, kung kinakailangan.[70]
    • Operasyon at observability (Ops/Runbook): mga sukatan ng tiwala sa AI at SLO; audit at pag-log; mga alerto sa degradasyon/anomalya; plano ng pagtugon sa insidente; fallback/kill‑switch para sa mga AI‑component; mga kinakailangan sa pag-uulat at post-incident na pagsusuri.[70][71]
    • Traceability (end‑to‑end): malinaw na mga ugnayan na «kinakailangan ↔ kontrol/pagsusuri sa pipeline» at «kinakailangan ↔ pagsubok/pagmamatyag sa operasyon», upang maaaring patunayang masuri ang seguridad at kalidad sa buong ikot ng buhay.[71][70]
  • Papel ng sistema ng analista.
    • pinamamahalaan ang konteksto at mga panganib ng AI (mga aktor, mga senaryo ng aplikasyon, mga pagpapalagay at limitasyon ng data);
    • tinitiyak ang traceability na «kinakailangan ↔ kontrol ng seguridad sa pipeline»;
    • binubuo ang mga napapatunayan na non-functional na kinakailangan (seguridad, transparency, observability) sa buong ikot ng buhay ng sistema.[70][71]

Mga Pagkakaiba mula sa Klasikong Pagsusuri ng Sistema

Ang terminong «pagsusuri ng sistema» ay makasaysayang mas malawak kaysa sa pagpapaunlad ng software. Ang klasikong pagsusuri ng sistema — isang diskarte sa paglutas ng mga kumplikadong interdisciplinary na gawain (panlipunan, pang-ekonomiya, pampamahala), batay sa systems thinking at mga quantitative na pamamaraan, karaniwang para sa suporta ng mga desisyon sa pamamahala. Sa IT, ang pagsusuri ng sistema ay nangangahulugang isang applied na disiplina sa larangan ng software engineering, nakatuon sa paglikha ng mga sistema ng impormasyon.

Sa ibaba — mga pangunahing pagkakaiba.

  • Mga layunin at object ng pagsusuri. Ang klasikong pagsusuri ay nagreresolta ng mahina ang istraktura, «malabo» na mga problema at nagpapabuti ng mga umiiral na sociotechnical na sistema (lungsod na network ng transportasyon, estratehiya ng kumpanya, patakaran sa kalikasan). Ang object — isang tunay na sistema; ang gawain — tulungan ang tagagawa ng desisyon na pumili ng kurso ng aksyon. Para sa pagsusuri ng sistema sa IT, ang layunin — ay magdisenyo at lumikha ng isang bagong sistema ng impormasyon o software na produkto na nakakatugon sa mga kinakailangan. Ang object — ang system na idinisenyo; ang pokus — ang pag-uugali at mga katangian na kailangan ng mga gumagamit.
  • Mga methodological na pundasyon. Ang mga klasikong paaralan ay nakabatay sa systems thinking at madalas sa matematika. Ang mahirap na diskarte (hard systems) — pag-pormal ng problema, mga quantitative na pamantayan, optimisasyon (tulad ng sa operations research). Ang mga malambot na metodolohiya (soft systems) ay kinikilala ang pagkakaiba-iba ng mga pananaw; isang halimbawa — Soft Systems Methodology (SSM), kung saan sa pamamagitan ng mga talakayan at mga konseptywal na modelo, ang mga nais na pagbabago ay napagkasunduan. Sa IT, ang batayan — mga disiplina sa engineering: requirements engineering, software design, mga architectural framework. Ginagamit ang mga standardisadong proseso (ISO/IEC/IEEE 15288, 12207, 29148), mga notasyon ng UML/SysML, at mga gawi ng pamamahala ng mga pagbabago.
  • Mga papel at artifact. Sa klasikong pagsusuri, ang papel ng «sistema ng analista» ay madalas na hindi pormal; ang mga resulta — analytical na ulat, mga rekomendasyon, mga mathematical na modelo, mga senaryo ng «paano kung». Sa IT, ang papel ng analista (o business analyst) ay pormal; inilalabas ang mga espesipikasyon ng kinakailangan, mga modelo ng sistema (UML, ER), mga espesipikasyon ng interface, mga user story at backlog — mga artifact na direktang ginagamit ng mga developer at tester.
  • Ikot ng buhay at proseso. Ang klasikong pagsusuri ay walang iisang template: ang mga hakbang ay nakasalalay sa problema (sa SSM — mula sa pag-aaral ng sitwasyon hanggang sa pagpapatupad ng mga pagbabago). Sa IT, ginagamit ang mga standard na siklo ng SDLC: sa cascading na modelo, may hiwalay na yugto ng pagsusuri ng kinakailangan; sa mga iterative at flexible na diskarte, ang pagsusuri ay patuloy na aktibidad ng bawat sprint. Ang mga modernong gawi (DevOps, CI/CD) ay nagpapalawak ng balangkas ng pagsusuri sa operasyon: isinasaalang-alang ang mga kinakailangan para sa pagpapanatili, observability, at updatability. Sa madaling salita, ang pagsusuri ng sistema sa IT ay integrado sa ikot ng buhay ng pagpapaunlad, habang ang klasikong ay madalas na isinasagawa bilang isang proyekto/konsultasyon na aktibidad.

Sistema ng Analista

Sistema ng analista sa IT — isang espesyalista na responsable para sa systems thinking sa pagdidisenyo at pagpapaunlad ng mga sistema ng impormasyon: pagbuo at validation ng mga kinakailangan, pagmomodelo (UML/BPMN), pagkakaisa ng mga desisyon sa arkitektura, at pagtitiyak ng integrasyon. Ang papel at mga kwalipikasyon sa Russian Federation ay nakasaad sa professional standard at Federal State Educational Standard.

Pangunahing layunin ng uri ng propesyonal na aktibidad: Pagtitiyak ng pagsunod ng IT serbisyo, automated na sistema, automated na sistema ng impormasyon, automated na sistema ng pamamahala, software, information na produkto o paraan (mula rito — Sistema) sa kapaligiran, mga pangunahing kinakailangan at limitasyon, mga layunin ng automation at automated na aktibidad sa pamamagitan ng pagbuo at paglipat ng mga kalidad at magkakaugnay na mga desisyon sa proyekto sa mga interesadong partido sa paglulunsad at koordinasyon ng trabaho ng mga indibidwal na tagapagsagawa sa buong ikot ng buhay ng Sistema (Professional standard na «Sistema ng analista» (utos ng Ministry of Labor ng Russian Federation na may petsang 27.04.2023 № 367н).[72]

Glossary ng Mga Pangunahing Termino

Mga Pangunahing Konsepto at Kalahok

  • Pagsusuri ng sistema sa IT — isang disiplina na ang paksa ay ang sistema ng impormasyon sa buong ikot ng buhay nito, mula sa konsepto hanggang sa operasyon.
  • Mga stakeholder — mga tao o grupo na interesado sa proyekto o naaapektuhan nito (mga customer, gumagamit, mga manager).
  • Mga artifact ng proyekto — mga dokumento at resulta na nilikha sa proseso ng proyekto, tulad ng mga espesipikasyon, modelo, plano, at mga desisyon.

Mga Kinakailangan: Mga Uri at Dokumentasyon

  • Mga functional na kinakailangan — naglalarawan kung ano ang dapat gawin ng sistema; ang mga function at pag-uugali nito.
  • Mga non-functional na kinakailangan — naglalarawan ng mga katangian ng kalidad ng sistema (pagiging maaasahan, pagganap, seguridad, kaginhawahan ng paggamit, scalability, atbp.).
  • Espesipikasyon ng kinakailangan (pangunahin) — isang dokumento na naglalaman ng paunang hanay ng mga kinakailangan na nakolekta sa mga paunang yugto ng proyekto.
  • SRS (Software Requirements Specification) — isang standardisadong dokumento na detalyadong naglalarawan ng mga kinakailangan sa software ayon sa mga internasyonal na pamantayan (hal., ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — isang dokumento na naglalarawan ng mga kinakailangan ng gumagamit sa sistema mula sa pananaw ng mga proseso ng negosyo at mga inaasahan ng end user.
  • Mga architecturally significant na kinakailangan (ASR) — mga kinakailangan na lubos na nakakaimpluwensya sa mga desisyon sa arkitektura at mga kompromiso.
  • Mga cross-functional na kinakailangan (CFR) — kasingkahulugan ng mga non-functional na kinakailangan, na binibigyang-diin ang kanilang cross-cutting na katangian.
  • Mga pamantayan ng pagtanggap (Acceptance Criteria) — mga napapatunayan na kondisyon, sa pagsunod sa kung saan ang trabaho sa kinakailangan ay itinuturing na tinanggap.
  • Definition of Ready (DoR) — kasunduan sa pagiging handa ng isang elemento ng backlog para sa pagpapaunlad (kalinawan, pagtatasa, mga pamantayan).
  • Definition of Done (DoD) — kasunduan sa «pagkakumpleto» ng trabaho (code, mga pagsubok, dokumentasyon, deployment).
  • Limitasyon (Constraint) — isang mahigpit na kondisyon na naglilimita sa mga solusyon (mga takdang panahon, mga platform, mga pamantayan, mga lisensya).
  • Pagpapalagay (Assumption) — isang pagpapalagay na tinatanggap nang walang katibayan, na nangangailangan ng kasunod na validation.
  • Kalidad ng mga kinakailangan — mga katangian ayon sa ISO 29148: kawalan ng kalabuan, pagkakumpleto, walang kontradiksyon, napapatunayan, atomicity.

Pag-pormal, Traceability, at Priyoritisasyon ng mga Kinakailangan

  • Pag-pormal ng mga kinakailangan — proseso ng pag-transform ng mga informal na kahilingan sa mga malinaw, napapatunayan, at hindi malabong kinakailangan.
  • Traceability ng mga kinakailangan — kakayahang subaybayan ang ikot ng buhay ng kinakailangan mula sa pinagmulan nito hanggang sa pagpapatupad, pagsubok, at deployment.
  • Bidirectional traceability (bidirectional traceability) — kakayahang subaybayan ang mga ugnayan sa pagitan ng mga kinakailangan, mga elemento ng disenyo, at mga senaryo ng pagsubok kapwa sa pasulong at paatras na direksyon.
  • MoSCoW — isang teknik ng priyoritisasyon ng mga kinakailangan, na nag-uuri ng mga ito bilang Must-have (dapat na), Should-have (dapat mayroon), Could-have (maaaring mayroon), at Won't-have (hindi magkakaroon).
  • BDD (Behavior-Driven Development) — isang metodolohiya ng pagpapaunlad, kung saan ang mga pagsubok ay isinusulat sa natural na wika, nakatuon sa pag-uugali ng sistema mula sa pananaw ng gumagamit (format na Given–When–Then).

Mga Notasyon at Pagmomodelo

  • UML (Unified Modeling Language) — isang standardisadong wika ng graphical na pagmomodelo para sa espesipikasyon, visualization, konstruksyon, at dokumentasyon ng mga sangkap ng mga software system.
  • SysML (Systems Modeling Language) — isang extension ng UML para sa systems engineering, na sumusuporta sa pagmomodelo ng iba't ibang aspeto ng mga kumplikadong sistema, kasama ang mga kinakailangan, pag-uugali, istraktura, at mga parameter.
  • BPMN (Business Process Model and Notation) — isang pamantayan ng graphical na notasyon para sa paglalarawan ng mga proseso ng negosyo, na nagbibigay-daan sa visualization ng mga daloy ng trabaho, mga kaganapan, mga gateway, at mga pool.
  • MBSE (Model-Based Systems Engineering) — isang diskarte sa systems engineering, kung saan ang modelo ay ang sentral na artifact sa lahat ng mga yugto ng ikot ng buhay ng sistema, mula sa mga kinakailangan hanggang sa pagsubok.
  • ArchiMate — isang notasyon ng corporate na arkitektura (negosyo, mga aplikasyon, teknolohiya) at ang kanilang mga ugnayan.
  • DMN (Decision Model and Notation) — pagmomodelo ng mga desisyon sa negosyo at mga talahanayan ng patakaran.
  • DFD (Data Flow Diagram) — mga diagram ng daloy ng data (konteksto, mga antas ng decomposition).
  • ERD (Entity-Relationship Diagram) — modelo ng domain ng paksa na may mga entity, mga ugnayan, at mga katangian.
  • CRUD-matrix — pagsunod ng mga operasyon ng Create/Read/Update/Delete sa mga entity at mga papel/function.

Mga Architectural Style at Pagtatasa ng mga Solusyon

  • Monolithic na arkitektura — isang architectural na diskarte kung saan ang buong sistema ay binuo bilang isang solong, hindi mahahati na modyul.
  • Microservices na arkitektura — isang architectural na diskarte kung saan ang sistema ay binuo bilang isang hanay ng maliliit, independently deployable at scalable na mga serbisyo.
  • Trade-off (kompromiso) — pagpili sa pagitan ng mga mutually exclusive o magkasalungat na mga katangian o mga solusyon, kung saan ang pagpapabuti ng isang katangian ay nagaganap sa kapinsalaan ng isa pa.
  • ATAM (Architecture Tradeoff Analysis Method) — isang pamamaraan ng pagtatasa ng arkitektura ng software, na ginagamit para sa pagsusuri ng mga kompromiso sa pagitan ng mga qualitative na katangian (hal., pagganap, scalability).

Arkitektura ng Negosyo at Mga Framework

  • TOGAF (The Open Group Architecture Framework) — isa sa mga pinakakaraniwang framework ng corporate na arkitektura, na kinabibilangan ng pamamaraan ng ADM (Architecture Development Method) para sa pagpapaunlad at pamamahala ng arkitektura.
  • Zachman Framework — isang ontolohiya ng mga artifact ng arkitektura ng negosyo, na ipinakita bilang isang 6×6 matris, na nag-uuri ng iba't ibang aspeto ng arkitektura mula sa iba't ibang pananaw.

Mga Diskarte sa Pagsusuri at Mga Proseso ng Pagpapaunlad

  • Mahirap na diskarte (Hard Systems) — isang metodolohiya ng pagsusuri ng sistema, na nagpapalagay ng mga layunin at kinakailangan na maaaring i-pormal nang maaga, decomposition, at pagdidisenyo «mula sa itaas pababa», epektibo para sa mga malinaw na tinukoy na mga gawain.
  • Malambot na diskarte (Soft Systems) — isang metodolohiya ng pagsusuri ng sistema, na inilalapat kapag ang mga layunin ay hindi malinaw at may maraming pananaw ng mga stakeholder, naglalayong pagkakaisahin ang pag-unawa sa problema at mga nais na pagbabago.
  • SSM (Soft Systems Methodology) — isang tiyak na metodolohiya ng malambot na sistemang diskarte, na binuo ni Peter Checkland, na gumagamit ng mga kasangkapan tulad ng rich picture, mga root definition, at CATWOE.
  • Waterfall (cascading na modelo) — isang klasikong metodolohiya ng pagpapaunlad ng software, kung saan ang mga yugto (pagsusuri, disenyo, pagpapatupad, pagsubok, pagpapatupad) ay isinasagawa nang sunud-sunod, na may kumpletong pagkumpleto ng nakaraang yugto bago simulan ang susunod.
  • Agile — isang grupo ng mga flexible na metodolohiya ng pagpapaunlad ng software, nakatuon sa iterative na pagpapaunlad, pag-adapt sa mga pagbabago, pakikipag-ugnayan sa customer, at patuloy na paghahatid ng halaga.

Mga Pamamaraan ng Pagpili at Mga Karaniwang Pagkakamali

  • AHP (Analytic Hierarchy Process) — isang pamamaraan ng multi-criteria na pagpili, na nagbibigay-daan sa pag-istruktura ng mga kumplikadong problema at pagtatasa ng mga alternatibo batay sa hierarchy ng mga pamantayan.
  • Gold-plating (sindrom ng «gold-plating») — isang pagkakamali sa pagsusuri ng sistema, na binubuo sa pagdaragdag ng functionality na hindi kinakailangan ng mga stakeholder, na humahantong sa paglaki ng dami at kumplikasyon ng proyekto.

Mga Sanggunian

  • ISO/IEC/IEEE 15288:2023 — System life cycle processes
  • ISO/IEC/IEEE 12207:2017 — Software life cycle processes
  • ISO/IEC/IEEE 29148:2018 — Requirements engineering
  • ISO/IEC/IEEE 42010:2022 — Architecture description
  • ISO/IEC 25010:2023 — Product quality model (SQuaRE)
  • ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288
  • ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)
  • ISO/IEC/IEEE 42020:2019 — Architecture processes
  • ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts
  • IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation
  • UML 2.5.1 — OMG Specification
  • BPMN 2.0.2 — OMG Specification
  • SysML v1.7 — OMG Specification
  • TOGAF Standard, 10th Edition — The Open Group
  • ArchiMate 3.2 — The Open Group
  • SEI ATAM — Architecture Tradeoff Analysis Method
  • NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)
  • SWEBOK Guide v4.0a — IEEE Computer Society (PDF)
  • Guide to the Systems Engineering Body of Knowledge (SEBoK)
  • BABOK Guide v3 — IIBA
  • Google SRE Books — Official site
  • Microsoft Azure Well-Architected Framework — Official docs
  • Pagsusuri ng sistema sa simpleng salita. YouTube
  • Pagsusuri ng sistema sa IT sa simpleng salita. YouTube

Panitikan

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, ika-5 ed.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Opisyal na libreng bersyon.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Opisyal na libreng pag-download (sa ilalim ng lisensya).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, ika-4 ed.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, ika-3 ed.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, ika-2 ed.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, ika-5 ed.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, ika-3 ed.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, ika-4 ed.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, ika-11 ed.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, ika-8 ed.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, ika-7 ed.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, ika-3 ed.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, ika-2 ed.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, ika-4 ed.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, ika-4 ed.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, ika-2 ed.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Mga Tala

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (обзор). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).
Retrieved from "https://systems-analysis.info/int/index.php?title=Pagsusuri_ng_sistema_sa_IT&oldid=5425"