Analisis Sistem dalam IT

From Systems analysis Wiki
Jump to navigation Jump to search

Analisis Sistem dalam IT (Systems Analysis and Design) — pendekatan untuk merancang dan mengembangkan sistem informasi dari konsep hingga operasional, yang mencakup identifikasi kebutuhan, formalisasi persyaratan, pemodelan domain dan proses, serta penilaian alternatif dan risiko. Dengan kata lain, analisis sistem dalam IT adalah tahap pengembangan di mana para spesialis mempelajari tugas, menentukan apa yang harus dilakukan sistem, dan mengembangkan solusi untuk pembuatannya.

Analisis sistem klasik mencakup spektrum bidang penerapan yang luas, tidak hanya pengembangan perangkat lunak, tetapi juga perubahan organisasi, strategi, dan aspek-aspek lainnya.[1] [2]

Pokok Bahasan dan Tugas Analisis Sistem dalam IT

Pokok bahasan analisis sistem dalam IT adalah sistem informasi (produk perangkat lunak dan/atau layanan) pada seluruh siklus hidupnya — dari konsep dan justifikasi hingga implementasi dan operasional.

Tugas analisis sistem — mengubah kebutuhan bisnis menjadi seperangkat persyaratan dan keputusan arsitektur yang terkoordinasi dan dapat diverifikasi: mengidentifikasi dan mendokumentasikan tujuan serta batasan pemangku kepentingan, memformalisasi persyaratan, memodelkan domain dan proses, menilai kelayakan dan risiko alternatif, serta membenarkan arsitektur yang dipilih. Hasilnya adalah dokumen-dokumen yang terkoordinasi dan ditetapkan hubungan yang dapat dilacak antara persyaratan, keputusan desain, dan pengujian. Hal ini memastikan keterlolaan dan kendali atas proses pengembangan.

Tugas analisis sistem meliputi:

  • Identifikasi kebutuhan dan tujuan pemangku kepentingan. Analis mengumpulkan dan mengklarifikasi ekspektasi pelanggan, pengguna, dan pihak-pihak yang berkepentingan lainnya; digunakan wawancara, survei, observasi, dan analisis proses yang sedang berjalan. Hasilnya adalah spesifikasi persyaratan awal dengan pembagian menjadi fungsional («apa yang harus dilakukan sistem») dan nonfungsional (keandalan, kinerja, keamanan, dll.).[1][2]
  • Formalisasi dan dokumentasi persyaratan. Permintaan diubah menjadi persyaratan yang dapat diverifikasi. Persyaratan yang dirumuskan dengan baik harus jelas dan tidak ambigu, lengkap, konsisten, dapat diverifikasi, dan dapat ditelusuri ke tujuan tingkat yang lebih tinggi; kumpulan persyaratan — terkoordinasi dan utuh.[3][4] Dalam praktiknya digunakan dokumen-dokumen terstandarisasi: SRS (Software Requirements Specification) sesuai ISO/IEC/IEEE 29148, serta, di industri tertentu, URS (User Requirements Specification) dan spesifikasi fungsional.[5][6][7]
  • Analisis dan pemodelan sistem. Untuk memahami bagaimana sistem akan bekerja dan berinteraksi dengan dunia luar, dibangun model-model: diagram use case untuk skenario penggunaan, DFD untuk aliran data dan proses bisnis, diagram kelas/komponen, dll. Model-model ini menjadi dasar untuk membandingkan solusi dan arsitektur alternatif.[8][9][10]
  • Penilaian kelayakan dan pemilihan solusi. Dilakukan feasibility study (kelayakan teknis, organisasional, ekonomis, jadwal) dan perbandingan alternatif arsitektur (trade-off). Untuk menilai kualitas arsitektur berdasarkan atribut (misalnya, kinerja, skalabilitas, modifiabilitas) digunakan metode seperti ATAM (Architecture Tradeoff Analysis Method).[11][12] Pemilihan antara, misalnya, arsitektur monolitik dan arsitektur mikrolayanan [3] didasarkan pada kompromi yang eksplisit (kompleksitas operasional vs. skalabilitas independen dan kecepatan pengiriman) sesuai rekomendasi panduan industri.[13][14]
  • Persiapan artefak desain. Berdasarkan hasil analisis dihasilkan:
    • spesifikasi persyaratan yang disetujui (dengan indikasi kepentingannya),
    • model konseptual sistem (diagram/deskripsi),
    • keputusan arsitektur dan desain (skema data, antarmuka sistem eksternal),
    • rencana implementasi (tahapan/modul).
    • Sangat penting untuk memastikan ketertelusuran (bidirectional traceability) persyaratan ke elemen desain dan pengujian.[15][4]

Keberhasilan proyek IT sangat bergantung pada praktik manajemen persyaratan dan arsitektur yang matang. Penelitian yang dilakukan oleh McKinsey dan Oxford menunjukkan bahwa proyek IT besar seringkali melampaui anggaran dan tenggat waktu. Penelitian ini juga menekankan betapa pentingnya mengelola strategi dengan benar, berinteraksi dengan pemangku kepentingan, dan mengumpulkan persyaratan dengan tepat. Semua ini dapat sangat memengaruhi keberhasilan atau kegagalan proyek.[16]

Pendekatan dan Metodologi dalam Analisis Sistem IT

Analisis sistem dalam IT berlandaskan pada prinsip-prinsip pemikiran sistemik dan metodologi yang diadaptasi untuk pengembangan perangkat lunak. Dalam praktiknya dikombinasikan pendekatan «keras» dan «lunak», metodologi terstruktur, notasi berorientasi objek, serta bahasa pemodelan proses dan persyaratan.

  • Pendekatan keras dan lunak. Dalam proyek IT, pendekatan keras (hard systems) mengasumsikan tujuan dan persyaratan yang dapat diformalisasi sebelumnya, dekomposisi dan desain «dari atas ke bawah». Pendekatan lunak (soft systems) diterapkan ketika tujuan tidak jelas dan terdapat banyak sudut pandang: digunakan elemen Soft Systems Methodology (SSM) (misalnya, rich picture, definisi akar, CATWOE) untuk menyelaraskan pemahaman masalah dan perubahan yang diinginkan; kemudian hasilnya diterjemahkan ke dalam persyaratan formal.[17][18]
  • Metodologi SSM (Soft Systems Methodology). Awalnya dikembangkan oleh Peter Checkland untuk perubahan organisasi, SSM berguna pada tahap pra-proyek IT: dari penelitian situasi masalah dan perumusan definisi akar (termasuk melalui CATWOE) hingga pembandingan model konseptual dengan realitas dan pencapaian akomodasi di antara para pemangku kepentingan.[19][20]
  • Metodologi terstruktur: SADT/IDEF0. SADT memodelkan sistem sebagai hierarki fungsi; notasi standar IDEF0 (IEEE 1320.1) menetapkan fungsi dan antarmuka I-C-O-M-nya (Inputs, Controls, Outputs, Mechanisms). Metode ini cocok untuk dekomposisi fungsional dan penyelarasan batas sistem terlepas dari algoritma.[21][22]
  • Analisis berorientasi objek: UML dan SysML (MBSE). UML menjadi bahasa dasar untuk persyaratan dan desain (diagram use case, kelas, urutan, dll.) dan memudahkan validasi skenario dengan pengguna; SysML memperluas UML untuk rekayasa sistem (diagram persyaratan, diagram parametrik) dan berlandaskan pendekatan MBSE, di mana model adalah artefak sentral di seluruh tahapan dari persyaratan hingga pengujian.[23][24][25]
  • Pemodelan proses bisnis: BPMN. Standar BPMN digunakan untuk deskripsi grafis proses (kolam, aliran kerja, peristiwa, gerbang), termasuk perbandingan as-is/to-be dalam spesifikasi persyaratan dan integrasi.[26][27]
  • Hubungan dengan rekayasa persyaratan. Prosesnya mencakup tahapan elicitation–analysis–specification–validation–change management; kriteria «persyaratan yang baik» dan struktur SRS diatur oleh ISO/IEC/IEEE 29148. Untuk prioritisasi digunakan teknik MoSCoW (Must/Should/Could/Won't) dan metode pemilihan multikriteria, misalnya AHP. Dalam proses agile, aktivitas analisis sistem tercermin dalam backlog refinement dan keterlacakan persyaratan.[28][29][30][31]
  • Hubungan dengan rekayasa sistem. Untuk sistem kompleks (siber-fisik) diterapkan V-model: pada cabang «kiri» — analisis sistem dan arsitektur, pada cabang «kanan» — integrasi, verifikasi dan validasi dengan keterkaitan ke artefak cabang kiri. Metode penilaian arsitektur berdasarkan atribut kualitas mencakup ATAM (analisis trade-off).[32][33]

Analisis sistem dalam IT menggabungkan pendekatan-pendekatan yang telah terbukti — dari metodologi lunak untuk menyelaraskan visi hingga notasi dan standar formal. Pilihan alat ditentukan oleh tingkat kepastian tugas: pada ketidakpastian tinggi, peran SSM dan fasilitasi menguat; pada batas yang jelas — model formal (UML/SysML, IDEF0, BPMN) dan regulasi.

Hubungan dengan Arsitektur IT dan Arsitektur Perusahaan

Analisis sistem dalam proyek IT berkaitan erat dengan perancangan arsitektur. Peran analis dan arsitek saling tumpang tindih: analis merumuskan persyaratan dan model logis, arsitek menentukan struktur solusi target dan kompromi teknis; pekerjaan dilakukan bersama.

  • Arsitektur sistem IT. Dalam arti sempit, arsitektur perangkat lunak adalah organisasi komponen, hubungannya, dan prinsip-prinsip yang memandu perancangan solusi. Penting bagi analis untuk mempertimbangkan gaya arsitektur (berlapis, klien–server, mikrolayanan, berbasis peristiwa, dll.), karena persyaratan nonfungsional (keandalan, skalabilitas, modifiabilitas) sering menentukan keputusan arsitektur dan komprominya.[34][35] Pada tahap awal analisis dibentuk visi arsitektur (high-level vision) dan dikerjakan garis besar solusi awal untuk memverifikasi kelayakan persyaratan (panjang iterasi dan tingkat rincian bergantung pada metodologi).[36]
  • Pola dan solusi awal. Untuk memenuhi persyaratan nonfungsional digunakan pola arsitektur (architectural patterns). Misalnya, untuk interaksi asinkron dan keterikatan rendah — publish–subscribe melalui message broker dalam arsitektur berbasis peristiwa.[37]
  • TOGAF (The Open Group Architecture Framework). Salah satu kerangka arsitektur perusahaan yang paling umum; mencakup metode ADM (Architecture Development Method) dan artefak manajemen arsitektur (repositori, katalog/matriks, prinsip). Dalam TOGAF, manajemen persyaratan adalah proses lintas yang terintegrasi ke dalam semua fase ADM.[36] Untuk mendukung persyaratan dan keterlacakan digunakan katalog dan matriks (misalnya, persyaratan ↔ layanan, fungsi ↔ komponen), serta dibedakan Architecture Building Blocks dan Solution Building Blocks.[38][39] Prinsip dan standar perusahaan ditetapkan dalam katalog terkait dan berfungsi sebagai persyaratan nonfungsional eksternal bagi tim proyek.[40] Kepatuhan solusi terhadap arsitektur target dikonfirmasi melalui prosedur Architecture Compliance Review.[41] Pendekatan TOGAF mengasumsikan Architecture Vision awal dan perincian selanjutnya (data/aplikasi/teknologi) dengan rencana migrasi dan manajemen perubahan persyaratan.[42][43]
  • Zachman Framework. Ontologi awal dan berpengaruh dari artefak arsitektur perusahaan, disajikan sebagai matriks 6×6 (perspektif × aspek «apa/bagaimana/di mana/siapa/kapan/mengapa»). Baris «desainer» berkorelasi dengan analisis dan perancangan sistem; kolom-kolom menentukan kelengkapan pertimbangan data, fungsi/proses, peran, lokasi, dan motivasi. Kerangka ini berfungsi sebagai klasifikasi (bukan metodologi) dan membantu memastikan kelengkapan deskripsi solusi dalam lanskap perusahaan.[44]
  • Hubungan dengan arsitektur perusahaan (Enterprise Architecture, EA). Analis sistem bekerja dalam konteks EA: persyaratan baru ditelusuri ke kemampuan bisnis dan model operasional; diterapkan standar dan batasan prinsip perusahaan (keamanan, kompatibilitas, dll.).[45][36] Pada tahap inisiasi dibentuk Architecture Vision (tujuan/batasan, persyaratan tingkat tinggi), selanjutnya analis merinci, menjaga keterlacakan ke visi dan standar korporat; ketidakpatuhan terhadap standar teridentifikasi pada architecture review dan dapat menyebabkan revisi solusi.[36][46]

Kesimpulan: analisis sistem dan perancangan arsitektur membentuk pasangan «persyaratan → keputusan arsitektur → kompromi berdasarkan atribut kualitas». Pilihan metode (gaya/pola, artefak TOGAF, klasifikasi Zachman) ditentukan oleh sifat proyek dan kerangka arsitektur perusahaan.

Proses dan Praktik

Analisis sistem terintegrasi ke seluruh siklus hidup pengembangan dan operasional perangkat lunak, menghubungkan tujuan bisnis, arsitektur, dan pengiriman. Mencakup penelitian pra-proyek, pemilihan pendekatan, pembentukan artefak yang dapat diverifikasi, serta persyaratan keandalan, kinerja, keamanan, dan pemeliharaan. Dalam model air terjun (waterfall), analisis dilakukan sebelum perancangan dan implementasi; dalam metode agile — secara berkelanjutan melalui iterasi; dan dalam DevOps — dengan penekanan pada tujuan operasional. Terlepas dari pendekatannya, analisis memastikan keterlacakan, manajemen perubahan dan risiko, pendokumentasian kompromi arsitektur, serta kepatuhan terhadap batasan regulasi, membuat pengembangan dapat diprediksi dan dikelola.

  • SDLC Klasik (Waterfall). Tahap System Analysis & Requirements Definition mendahului perancangan dan implementasi; persyaratan ditetapkan dalam SRS terperinci sebagai dasar perencanaan dan kontrak. Efektif dalam domain yang stabil dan diatur; risiko «pembekuan» persyaratan dikurangi melalui SRR/review dan manajemen perubahan melalui CCB.[47][48][49]
  • Metodologi Agile. Analisis bersifat berkelanjutan: alih-alih SRS final, dikelola backlog produk dari user stories dengan kriteria penerimaan, yang diperhalus pada backlog refinement; diterapkan BDD (Given–When–Then); risiko hilangnya integritas arsitektur dikompensasi dengan pengerjaan arsitektur awal dan keterlacakan persyaratan ↔ implementasi/pengujian yang transparan.[50][51][52]
  • DevOps dan SRE. Rilis yang sering membutuhkan persyaratan operasional «secara default»: otomatisasi, observabilitas, rollback. Persyaratan nonfungsional dirumuskan sebagai SLO/SLI, error budget dikelola; ke dalam backlog ditambahkan tugas untuk log/metrik/trace/alert; untuk rilis tanpa downtime — pola blue/green dan lain-lain.[53][54][55]
  • Manajemen persyaratan dan risiko. Persyaratan dalam ALM memiliki status dan hubungan dengan tugas/rilis/defek; version control, change impact analysis, dan reprioritisasi berkala bersifat wajib.[56][57]
  • Jaminan kualitas (QA). Kualitas diletakkan pada tahap persyaratan: review, «Three Amigos», rencana Acceptance Test Plan, pengujian otomatis kriteria penerimaan (BDD/ATDD).[58][59]
  • Observabilitas dan keandalan. Persyaratan mencakup SLA/SLO, MTTR dan MTBF dengan target terukur dan metode kontrol; parameter diperoleh dari bisnis/operasional dan ditanamkan dalam arsitektur serta pengujian keandalan.[60][61]

Metrik dan Kualitas Artefak

Untuk menilai pekerjaan analis sistem dan kualitas hasilnya, digunakan kriteria yang diterima secara umum. Persyaratan dan model yang berkualitas adalah fondasi keberhasilan proyek, sehingga dikelola sepanjang seluruh siklus hidup (elicitation → specification → verification/validation → change management). Atribut kualitas dasar persyaratan ditetapkan dalam standar ISO/IEC/IEEE 29148 dan (secara historis) IEEE 830.[3][62][1]

  • Ketepatan (Correctness) — persyaratan mencerminkan kebutuhan nyata dan disepakati dengan para ahli domain; dikonfirmasi melalui validasi (review/inspeksi, prototipe, skenario).[1][4]
  • Kelengkapan (Completeness) — aspek dan kondisi yang substansial telah dipertimbangkan.
    • Kelengkapan persyaratan individual: detail yang diperlukan telah ditentukan (misalnya, «indikator berubah ke status merah saat kegagalan», bukan sekadar «berubah menjadi merah»).
    • Kelengkapan spesifikasi: skenario/peran dicakup, NFR ditetapkan; dicapai melalui checklist dan keterlacakan ke tujuan bisnis; audit kelengkapan independen berguna (QA/review).[3][63]
  • Ketidakambiguan (Unambiguity) — rumusan ditafsirkan dengan satu cara; dibantu oleh glosarium, template dalam bentuk «sistem harus melakukan A, ketika B, jika C», contoh-contoh; diagram disertai legenda. Verifikasi — prinsip «empat mata».[3][1]
  • Konsistensi (Consistency) — persyaratan tidak saling bertentangan satu sama lain dan terhadap batasan eksternal; diterapkan penataan, tabel ringkasan atribut, review tim; persyaratan regulasi/standar diverifikasi.[3][63]
  • Keterpastian/ketestaban (Verifiability) — pencapaian dikonfirmasi melalui pengujian/demonstrasi/analisis; rumusan yang tidak dapat diverifikasi digantikan dengan kriteria terukur; untuk NFR ditetapkan metrik dan kriteria penerimaan ditetapkan lebih awal.[3][63]
  • Keterbacaan dan keterlacakan (Modifiability & Traceability) — ID unik, struktur logis («satu gagasan — satu paragraf»), tidak ada duplikat; hubungan «persyaratan ↔ sumber/tujuan/desain/pengujian» dipertahankan, matriks keterlacakan (RTM) dikelola.[64][3]
  • Peringkat dan prioritisasi — kualitas kumpulan persyaratan; teknik MoSCoW dan MCDM (misalnya, AHP) digunakan; prioritisasi bersama bisnis mempengaruhi perencanaan dan risiko.[65][66]

Metrik kualitas persyaratan (contoh):[63][1]

  • kepadatan cacat persyaratan (komentar per 100 persyaratan);
  • jumlah perubahan setelah pembekuan baseline;
  • metrik cakupan: persentase persyaratan yang memiliki pengujian; persentase persyaratan yang dapat ditelusuri ke tujuan bisnis;
  • stabilitas persyaratan (rasio persyaratan yang ditambahkan/dihapus terhadap total dalam periode tertentu);
  • ukuran/kompleksitas spesifikasi (rata-rata jumlah persyaratan dalam use case, kedalaman dekomposisi);
  • kepuasan pemangku kepentingan (survei).

Dalam proses yang matang (misalnya, CMMI level 3+) terdapat regulasi kualitas persyaratan: pemeriksaan formal, audit kepatuhan terhadap template, pengumpulan/analisis metrik.[67] Dalam domain kritis (avionik, luar angkasa, dll.) digunakan metode formal untuk meningkatkan keandalan.[68]

Kesalahan Umum

Dalam proyek IT, kesalahan analisis sistem sering ditemui: ketidaklengkapan dan ambiguitas persyaratan, kontradiksi, batas yang kabur, pengabaian aspek nonfungsional, integrasi yang terlewat, dan keamanan yang terlambat dipertimbangkan. Hal ini menyebabkan pengerjaan ulang, penundaan, peningkatan biaya, dan cacat.

Masalah umum, konsekuensinya, dan cara pencegahannya.

  • Ketidaklengkapan dan persyaratan yang terlewat. Peran dengan hak istimewa khusus, kasus tepi, dan NFR diabaikan. Konsekuensi: pengerjaan ulang arsitektur dan penundaan peluncuran. Cara menghindari: checklist, brainstorming «bagaimana jika…», keterlibatan awal penguji, keterlacakan ke tujuan bisnis.[1][69]
  • Rumusan yang tidak jelas dan ambigu. Konsekuensi: pengembang mengimplementasikan «sesuatu yang salah», pelanggan tidak puas. Cara menghindari: kriteria terukur, glosarium, template «A, ketika B, jika C», peer‑review.[3][69]
  • Persyaratan yang saling bertentangan. Konsekuensi: penundaan untuk klarifikasi, pengerjaan ulang pada integrasi. Cara menghindari: penataan, verifikasi aturan bisnis/regulasi, sesi resolusi konflik, pemeriksaan konsistensi pada review.[3][1]
  • Sindrom «gold-plating» (pelapisan emas). Konsekuensi: pertumbuhan ruang lingkup, peningkatan kompleksitas, titik kegagalan baru. Cara menghindari: mengikat setiap persyaratan ke tujuan/metrik; dalam Agile — tidak memasukkan hal-hal yang tidak perlu ke backlog; menetapkan scope; lihat YAGNI.
  • Perincian berlebihan di mana tidak diperlukan. Cara menghindari: memisahkan apa/mengapa (persyaratan) dari bagaimana (desain/implementasi); menerapkan design‑free requirements di mana sesuai.[3]
  • Pelanggaran manajemen persyaratan. Konsekuensi: kebingungan versi, implementasi «hal yang salah». Cara menghindari: sumber kebenaran tunggal dalam ALM, histori dan status, RTM dan change impact analysis; manajemen perubahan melalui CCB.[64][1]
  • Tidak adanya partisipasi pengguna. Cara menghindari: wawancara, observasi, prototipe, demonstrasi rutin; validasi eksplisit dengan pemangku kepentingan.[3][1]
  • «Kelumpuhan analitis» yang terlalu lama. Cara menghindari: zona kecukupan, iterativitas dan timeboxing; peluncuran MVP/inkrement dan koreksi berdasarkan umpan balik.[1]
  • Mengabaikan persyaratan nonfungsional. Cara menghindari: mengidentifikasi NFR secara eksplisit (misalnya, FURPS+), menetapkan kriteria terukur, memasukkannya ke dalam rencana pengujian dan keputusan arsitektur.[1][3]
  • Kesalahan komunikasi dan «faktor manusia». Cara mengatasi: mengembangkan keterampilan wawancara dan fasilitasi, menjaga netralitas, mendokumentasikan keputusan dan sumber persyaratan (keterlacakan ke tujuan).[1]

Sebagian besar masalah bermuara pada kualitas rumusan, kelengkapan, dan keterlolaan persyaratan; penerapan standar ISO/IEC/IEEE 29148 dan praktik SWEBOK (kemampuan validasi, keterlacakan, iterativitas) secara signifikan mengurangi risiko keterlambatan jadwal dan pengerjaan ulang.[3][1]

Keterbatasan

Meskipun efektif dalam mengurangi ketidakpastian, analisis sistem memiliki keterbatasannya sendiri:

  • Realitas bersifat dinamis dan kompleks. Tidak mungkin memperhitungkan semua faktor, terutama dalam proyek jangka panjang. Beberapa persyaratan pasti akan muncul setelah sistem diluncurkan. Penting untuk berupaya meminimalkan kejutan, tetapi harus siap dengan perubahan.
  • Persyaratan bergantung pada manusia. Prioritas bisnis, undang-undang, dan pasar dapat berubah. Analisis sistem mencatat kondisi saat ini dan tidak dapat memprediksi semua perubahan eksternal. Untuk beradaptasi, persyaratan perlu diperbarui secara berkala dan bekerja secara iteratif.
  • Pengguna tidak selalu tahu apa yang mereka inginkan sampai mereka melihatnya. Ini adalah keterbatasan yang dikenal. Pembuatan prototipe dan metodologi agile seperti Agile membantu mengatasi masalah ini. Analisis di atas kertas memiliki batasnya, dan untuk mendapatkan data yang akurat diperlukan umpan balik dari implementasi.
  • Keseimbangan antara waktu dan kualitas. Analisis yang terlalu terperinci dapat menjadi usang. Dalam bidang inovatif, lebih baik membuat produk yang layak minimum (MVP) dengan cepat dan mendapatkan data nyata. Analisis sistem efektif di bidang yang stabil, tetapi dalam proyek penelitian (R&D) perannya terbatas.
  • Faktor manusia. Bahkan metodologi terbaik pun tidak dapat mengkompensasi ketidakkompetensi analis atau ketidakhadiran pelanggan. Penting agar semua peserta proses terlibat dan termotivasi.

Pengaruh Teknologi Modern terhadap Analisis Sistem dalam IT

Analisis sistem dalam IT terus berevolusi di bawah pengaruh inovasi teknologi. Analis abad ke-21 bekerja dalam kondisi pertumbuhan data yang eksplosif, penerapan AI yang merata di mana-mana, siklus pengembangan yang cepat, dan perhatian yang meningkat terhadap keamanan. Praktik analisis sistem yang berhasil memerlukan penguasaan pengetahuan baru (Data Science, keamanan siber, teknologi cloud) dan fleksibilitas dalam penerapan metode.

  • Data dan AI/ML: apa yang ditambahkan dalam analisis. Untuk sistem dengan AI, sejak awal ditetapkan tujuan dan konteks penerapan, persyaratan terhadap sumber dan kualitas data, serta metrik kepercayaan terhadap keputusan model (keandalan, keamanan, kemampuan penjelasan, privasi, keadilan). Direncanakan pemeriksaan TEVV (testing, evaluation, verification, validation), pemantauan dalam operasional, dan penonaktifan/penarikan model yang aman. Langkah-langkah ini sesuai dengan fungsi GOVERN–MAP–MEASURE–MANAGE dari kerangka manajemen risiko AI NIST; tercermin dalam SRS, arsitektur, dan rencana verifikasi/operasional.[70]
  • DevSecOps: keamanan «di kiri» dan secara default. Menyematkan keamanan ke setiap tahap CI/CD menjadi norma: pemeriksaan otomatis (SAST/DAST), pemindaian dependensi dan container, kebijakan deployment, observabilitas dasar. Digunakan registri artefak tepercaya dan image «hardened» yang terstandarisasi; diterapkan prinsip zero trust. Dalam analisis sistem, titik kontrol pipeline (kondisi untuk melewati tahapan), hubungan persyaratan dengan kontrol keamanan, dan aturan transisi antar lingkungan (dev/test/stage/prod) dideskripsikan terlebih dahulu.[71]
  • Apa yang berubah dalam dokumen (artefak). Bagian mana yang muncul atau diperhalus dalam dokumen-dokumen utama dengan adanya Big Data dan AI/ML serta saat bekerja menggunakan DevSecOps:
    • SRS / Spesifikasi persyaratan: tujuan dan konteks penerapan AI; persyaratan data (asal, kualitas, batasan etis dan hukum); metrik model (akurasi, keandalan, waktu respons); rencana TEVV (testing, evaluation, verification, validation); persyaratan transparansi/kemampuan penjelasan dan privasi; kriteria penonaktifan/penarikan model dari operasional.[70]
    • Arsitektur dan keputusan (Architecture, ADR): hasil pemodelan ancaman; langkah-langkah «keamanan secara default» (enkripsi, kontrol akses, manajemen rahasia, prinsip hak istimewa minimum); batasan penggunaan data/model; catatan ADR dengan penilaian risiko dan kompromi.[71][70]
    • Rencana verifikasi dan validasi (V&V / TEVV): skenario pengujian model dan data; ambang batas penerimaan untuk metrik kualitas; pemantauan drift data/model; prosedur penilaian ulang berkala dan validasi ulang.[70]
    • Kebijakan CI/CD dan «gerbang» pipeline: pemeriksaan otomatis SAST/DAST, SCA (dependensi), pemindaian container; penandatanganan dan penyimpanan artefak di registri tepercaya; aturan promosi antar lingkungan (dev/test/stage/prod) dan kondisi pemblokiran build saat pemeriksaan gagal; persyaratan observabilitas secara default.[71]
    • Rencana manajemen data dan model: katalog sumber dan lineage; kriteria kualitas dan ketersediaan data; versi dataset/model; jadwal (re)training dan kontrol bias; kebijakan akses dan penyimpanan; rencana deaktivasi model yang aman dan penghapusan data bila diperlukan.[70]
    • Operasional dan observabilitas (Ops/Runbook): metrik kepercayaan AI dan SLO; audit dan pencatatan; alert untuk degradasi/anomali; rencana respons insiden; fallback/kill‑switch untuk komponen AI; persyaratan pelaporan dan analisis pasca-insiden.[70][71]
    • Keterlacakan (end‑to‑end): hubungan eksplisit «persyaratan ↔ kontrol/pemeriksaan dalam pipeline» dan «persyaratan ↔ pengujian/pemantauan dalam operasional», agar keamanan dan kualitas dapat diverifikasi secara demonstratif sepanjang seluruh siklus hidup.[71][70]
  • Peran analis sistem.
    • mengelola konteks dan risiko AI (aktor, skenario penerapan, asumsi dan batasan data);
    • memastikan keterlacakan «persyaratan ↔ kontrol keamanan dalam pipeline»;
    • merumuskan persyaratan nonfungsional yang dapat diverifikasi (keamanan, transparansi, observabilitas) sepanjang seluruh siklus hidup sistem.[70][71]

Perbedaan dari Analisis Sistem Klasik

Istilah «analisis sistem» secara historis lebih luas dari pengembangan perangkat lunak. Analisis sistem klasik — pendekatan untuk memecahkan masalah interdisipliner yang kompleks (sosial, ekonomi, manajerial), berdasarkan pemikiran sistemik dan metode kuantitatif, biasanya untuk mendukung keputusan manajerial. Dalam IT, analisis sistem dipahami sebagai disiplin terapan dalam bidang rekayasa perangkat lunak, yang berorientasi pada pembuatan sistem informasi.

Berikut adalah perbedaan-perbedaan utamanya.

  • Tujuan dan objek analisis. Analisis klasik memecahkan masalah yang kurang terstruktur dan «kabur» serta meningkatkan sistem sosio-teknis yang sudah ada (jaringan transportasi perkotaan, strategi perusahaan, kebijakan lingkungan). Objeknya — sistem nyata; tugasnya — membantu pengambil keputusan memilih arah tindakan. Untuk analisis sistem dalam IT, tujuannya adalah merancang dan membuat sistem informasi baru atau produk perangkat lunak yang memenuhi persyaratan. Objeknya — sistem yang dirancang; fokusnya — perilaku dan karakteristik yang dibutuhkan pengguna.
  • Dasar metodologis. Mazhab klasik berlandaskan pemikiran sistemik dan seringkali matematika. Pendekatan keras (hard systems) — formalisasi masalah, kriteria kuantitatif, optimasi (seperti dalam operations research). Metodologi lunak (soft systems) mengakui adanya berbagai sudut pandang; contohnya — Soft Systems Methodology (SSM), di mana melalui diskusi dan model konseptual, perubahan yang diinginkan diselaraskan. Dalam IT, dasarnya adalah disiplin rekayasa: rekayasa persyaratan, perancangan perangkat lunak, kerangka arsitektur. Digunakan proses terstandarisasi (ISO/IEC/IEEE 15288, 12207, 29148), notasi UML/SysML, dan praktik manajemen perubahan.
  • Peran dan artefak. Dalam analisis klasik, peran «analis sistem» seringkali tidak formal; hasilnya adalah laporan analitis, rekomendasi, model matematika, skenario «bagaimana jika». Dalam IT, peran analis (atau analis bisnis) diformalkan; dihasilkan spesifikasi persyaratan, model sistem (UML, ER), spesifikasi antarmuka, user stories dan backlog — artefak yang langsung digunakan oleh pengembang dan penguji.
  • Siklus hidup dan proses. Analisis klasik tidak memiliki template tunggal: langkah-langkahnya bergantung pada masalah (dalam SSM — dari mempelajari situasi hingga mengimplementasikan perubahan). Dalam IT, siklus SDLC standar diterapkan: dalam model waterfall terdapat fase analisis persyaratan yang terpisah; dalam pendekatan iteratif dan agile, analisis adalah aktivitas berkelanjutan setiap sprint. Praktik modern (DevOps, CI/CD) memperluas ruang lingkup analisis ke operasional: persyaratan pemeliharaan, observabilitas, dan kemampuan pembaruan diperhitungkan. Dengan kata lain, analisis sistem dalam IT tertanam dalam siklus hidup pengembangan, sedangkan analisis klasik lebih sering dilakukan sebagai kegiatan proyek/konsultasi.

Analis Sistem

Analis sistem dalam IT — spesialis yang bertanggung jawab atas pemikiran sistemik dalam perancangan dan pengembangan sistem informasi: pembentukan dan validasi persyaratan, pemodelan (UML/BPMN), penyelarasan keputusan arsitektur, dan memastikan integrasi. Peran dan persyaratan kualifikasi di Federasi Rusia ditetapkan dalam standar profesional dan FGOS.

Tujuan utama jenis kegiatan profesional: Memastikan kesesuaian layanan IT, sistem otomatis, sistem informasi otomatis, sistem kontrol otomatis, produk perangkat lunak dan informasi atau sarana (selanjutnya - Sistem) dengan lingkungan, persyaratan dan batasan awal, tujuan otomatisasi dan kegiatan yang diotomatisasi melalui pengembangan dan penyampaian keputusan desain yang berkualitas dan saling terkait kepada pihak-pihak yang berkepentingan saat peluncuran dan koordinasi pekerjaan para pelaksana individual sepanjang seluruh siklus hidup Sistem (Standar Profesional «Analis Sistem» (perintah Kementerian Tenaga Kerja Federasi Rusia tertanggal 27.04.2023 No. 367n).[72]

Glosarium Istilah Utama

Konsep Dasar dan Peserta

  • Analisis sistem dalam IT — disiplin yang pokok bahasannya adalah sistem informasi pada seluruh siklus hidupnya, dari konsep hingga operasional.
  • Pemangku kepentingan (Stakeholders) — individu atau kelompok yang berkepentingan dalam proyek atau terdampak olehnya (pelanggan, pengguna, manajer).
  • Artefak proyek — dokumen dan hasil yang dibuat selama proyek, seperti spesifikasi, model, rencana, dan keputusan.

Persyaratan: Jenis dan Dokumentasi

  • Persyaratan fungsional — mendeskripsikan apa yang harus dilakukan sistem; fungsi dan perilakunya.
  • Persyaratan nonfungsional — mendeskripsikan atribut kualitas sistem (keandalan, kinerja, keamanan, kemudahan penggunaan, skalabilitas, dll.).
  • Spesifikasi persyaratan (awal) — dokumen yang berisi kumpulan awal persyaratan yang dikumpulkan pada tahap awal proyek.
  • SRS (Software Requirements Specification) — dokumen terstandarisasi yang mendeskripsikan persyaratan perangkat lunak secara terperinci sesuai standar internasional (misalnya, ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — dokumen yang mendeskripsikan persyaratan pengguna terhadap sistem dari sudut pandang proses bisnis dan ekspektasi pengguna akhir.
  • Persyaratan yang signifikan secara arsitektur (ASR) — persyaratan yang secara substansial mempengaruhi keputusan arsitektur dan kompromi.
  • Persyaratan lintas fungsi (CFR) — sinonim dari persyaratan nonfungsional, yang menekankan sifat lintas sektornyal.
  • Kriteria penerimaan (Acceptance Criteria) — kondisi yang dapat diverifikasi yang, jika terpenuhi, pekerjaan berdasarkan persyaratan dianggap diterima.
  • Definition of Ready (DoR) — kesepakatan tentang kesiapan elemen backlog untuk pengembangan (kejelasan, estimasi, kriteria).
  • Definition of Done (DoD) — kesepakatan tentang «kelengkapan» pekerjaan (kode, pengujian, dokumentasi, deployment).
  • Batasan (Constraint) — kondisi ketat yang membatasi solusi (tenggat waktu, platform, standar, lisensi).
  • Asumsi (Assumption) — dugaan yang diterima tanpa bukti, yang memerlukan validasi selanjutnya.
  • Kualitas persyaratan — properti menurut ISO 29148: keunikan, kelengkapan, konsistensi, keterpastian, atomisitas.

Formalisasi, Keterlacakan, dan Prioritisasi Persyaratan

  • Formalisasi persyaratan — proses mengubah permintaan informal menjadi persyaratan yang jelas, dapat diverifikasi, dan tidak ambigu.
  • Keterlacakan persyaratan — kemampuan untuk melacak siklus hidup persyaratan dari sumbernya hingga implementasi, pengujian, dan deployment.
  • Bidirectional traceability (keterlacakan dua arah) — kemampuan melacak hubungan antara persyaratan, elemen desain, dan skenario pengujian baik dalam arah langsung maupun terbalik.
  • MoSCoW — teknik prioritisasi persyaratan yang mengklasifikasikannya sebagai Must-have (harus ada), Should-have (sebaiknya ada), Could-have (bisa ada), dan Won't-have (tidak akan ada).
  • BDD (Behavior-Driven Development) — metodologi pengembangan di mana pengujian ditulis dalam bahasa alami yang berorientasi pada perilaku sistem dari sudut pandang pengguna (format Given–When–Then).

Notasi dan Pemodelan

  • UML (Unified Modeling Language) — bahasa pemodelan grafis yang terstandarisasi untuk spesifikasi, visualisasi, konstruksi, dan dokumentasi komponen sistem perangkat lunak.
  • SysML (Systems Modeling Language) — ekstensi UML untuk rekayasa sistem, yang mendukung pemodelan berbagai aspek sistem kompleks, termasuk persyaratan, perilaku, struktur, dan parameter.
  • BPMN (Business Process Model and Notation) — standar notasi grafis untuk mendeskripsikan proses bisnis, yang memungkinkan visualisasi aliran kerja, peristiwa, gerbang, dan kolam.
  • MBSE (Model-Based Systems Engineering) — pendekatan rekayasa sistem di mana model adalah artefak sentral pada semua tahap siklus hidup sistem, dari persyaratan hingga pengujian.
  • ArchiMate — notasi arsitektur perusahaan (bisnis, aplikasi, teknologi) dan hubungannya.
  • DMN (Decision Model and Notation) — pemodelan keputusan bisnis dan tabel aturan.
  • DFD (Data Flow Diagram) — diagram aliran data (konteks, tingkat dekomposisi).
  • ERD (Entity-Relationship Diagram) — model domain subjek dengan entitas, relasi, dan atribut.
  • Matriks CRUD — korespondensi operasi Create/Read/Update/Delete dengan entitas dan peran/fungsi.

Gaya Arsitektur dan Penilaian Solusi

  • Arsitektur monolitik — pendekatan arsitektur di mana seluruh sistem dikembangkan sebagai modul tunggal yang tidak dapat dibagi.
  • Arsitektur mikrolayanan — pendekatan arsitektur di mana sistem dibangun sebagai kumpulan layanan-layanan kecil yang dapat di-deploy dan diskalakan secara independen.
  • Trade-off (kompromi) — pilihan antara karakteristik atau solusi yang saling eksklusif atau bertentangan, di mana peningkatan satu karakteristik terjadi dengan mengorbankan karakteristik lainnya.
  • ATAM (Architecture Tradeoff Analysis Method) — metode evaluasi arsitektur perangkat lunak yang digunakan untuk menganalisis trade-off antara atribut kualitas (misalnya, kinerja, skalabilitas).

Arsitektur Perusahaan dan Kerangka Kerja

  • TOGAF (The Open Group Architecture Framework) — salah satu kerangka arsitektur perusahaan yang paling umum, yang mencakup metode ADM (Architecture Development Method) untuk mengembangkan dan mengelola arsitektur.
  • Zachman Framework — ontologi artefak arsitektur perusahaan, disajikan sebagai matriks 6×6, yang mengklasifikasikan berbagai aspek arsitektur dari berbagai perspektif.

Pendekatan untuk Analisis dan Proses Pengembangan

  • Pendekatan keras (Hard Systems) — metodologi analisis sistem yang mengasumsikan tujuan dan persyaratan yang dapat diformalisasi sebelumnya, dekomposisi dan desain «dari atas ke bawah», efektif untuk tugas-tugas yang terdefinisi dengan jelas.
  • Pendekatan lunak (Soft Systems) — metodologi analisis sistem yang diterapkan ketika tujuan tidak jelas dan terdapat berbagai sudut pandang pemangku kepentingan, bertujuan untuk menyelaraskan pemahaman masalah dan perubahan yang diinginkan.
  • SSM (Soft Systems Methodology) — metodologi pendekatan sistem lunak yang spesifik, dikembangkan oleh Peter Checkland, menggunakan alat-alat seperti rich picture, definisi akar, dan CATWOE.
  • Waterfall (model air terjun) — metodologi pengembangan perangkat lunak klasik di mana tahapan-tahapan (analisis, perancangan, implementasi, pengujian, penerapan) dilakukan secara berurutan, dengan menyelesaikan sepenuhnya tahap sebelumnya sebelum memulai tahap berikutnya.
  • Agile — kelompok metodologi pengembangan perangkat lunak fleksibel yang berorientasi pada pengembangan iteratif, adaptasi terhadap perubahan, interaksi dengan pelanggan, dan pengiriman nilai secara berkelanjutan.

Metode Pemilihan dan Kesalahan Umum

  • AHP (Analytic Hierarchy Process) — metode pemilihan multikriteria yang memungkinkan penataan masalah kompleks dan evaluasi alternatif berdasarkan hierarki kriteria.
  • Gold-plating (sindrom «pelapisan emas») — kesalahan dalam analisis sistem yang terdiri dari penambahan fungsionalitas yang tidak diminta oleh pemangku kepentingan, yang menyebabkan pertumbuhan ruang lingkup dan kompleksitas proyek.

Referensi

  • 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
  • Analisis sistem dengan bahasa yang mudah. YouTube
  • Analisis sistem dalam IT dengan bahasa yang mudah. YouTube

Kepustakaan

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, edisi ke-5.
  • 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. Versi gratis resmi.
  • 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. Unduhan gratis resmi (berlisensi).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, edisi ke-4.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, edisi ke-3.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, edisi ke-2.
  • 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, edisi ke-5.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, edisi ke-3.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, edisi ke-4.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, edisi ke-11.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, edisi ke-8.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, edisi ke-7.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, edisi ke-3.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, edisi ke-2.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, edisi ke-4.
  • 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, edisi ke-4.
  • 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, edisi ke-2.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Catatan

  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=Analisis_Sistem_dalam_IT&oldid=316"