Templat rekod keputusan oleh arc42

1. Pengenalan dan Matlamat

Penerangan ringkas tentang keperluan, daya pendorong, ekstrak (atau abstrak) keperluan. Tiga (maksimum lima) matlamat kualiti teratas untuk seni bina yang mempunyai keutamaan tertinggi bagi pihak berkepentingan utama. Jadual pihak berkepentingan penting dengan jangkaan mereka mengenai seni bina.

1.1 Gambaran Keseluruhan Keperluan

Kandungan

Penerangan ringkas tentang keperluan fungsian, daya pendorong, ekstrak (atau abstrak) keperluan. Pautan ke dokumen keperluan (yang diharapkan wujud), dengan maklumat di mana untuk menemuinya.

Motivasi

Dari sudut pandangan pengguna akhir, sesebuah sistem dicipta atau diubah suai untuk meningkatkan sokongan kepada aktiviti perniagaan dan/atau meningkatkan kualiti.

Bentuk

Penerangan teks ringkas, mungkin dalam format kes penggunaan berjadual. Jika dokumen keperluan wujud, gambaran keseluruhan ini perlu merujuk dokumen tersebut.

Pastikan ekstrak ini sependek mungkin. Seimbangkan kebolehbacaan dokumen ini dengan potensi redundansi berkenaan dokumen keperluan.

1.2 Matlamat kualiti

Kandungan

Tiga (maksimum lima) matlamat kualiti teratas untuk seni bina yang pemenuhannya paling penting kepada pihak berkepentingan utama. Kami benar-benar maksudkan matlamat kualiti untuk seni bina. Jangan mengelirukannya dengan matlamat projek. Ia tidak semestinya sama. Piawaian ISO 25010 menyediakan gambaran keseluruhan yang baik tentang topik yang mungkin menarik.

Motivasi

Anda perlu mengetahui matlamat kualiti pihak berkepentingan terpenting anda, kerana ia akan mempengaruhi keputusan seni bina asas. Pastikan anda sangat konkrit tentang kualiti ini, elakkan perkataan bombastik. Jika anda sebagai arkitek tidak tahu bagaimana kualiti kerja anda akan dinilai …

Bentuk

Jadual dengan matlamat kualiti terpenting dan senario konkrit, disusun mengikut keutamaan.

1.3 Pihak berkepentingan

Kandungan

Gambaran keseluruhan yang jelas tentang pihak berkepentingan sistem, iaitu semua orang, peranan atau organisasi yang

perlu mengetahui seni bina
perlu diyakinkan tentang seni bina
perlu bekerja dengan seni bina atau dengan kod
memerlukan dokumentasi seni bina untuk kerja mereka
perlu membuat keputusan tentang sistem atau pembangunannya

Motivasi

Anda perlu mengetahui semua pihak yang terlibat dalam pembangunan sistem atau yang terkesan oleh sistem. Jika tidak, anda mungkin mendapat kejutan yang tidak menyenangkan kemudian dalam proses pembangunan. Pihak berkepentingan ini menentukan tahap dan tahap perincian kerja anda dan hasilnya.

Bentuk

Jadual dengan nama peranan, nama orang dan jangkaan mereka berkenaan seni bina dan dokumentasinya.

2. Kekangan

Apa-apa yang mengekang pasukan dalam keputusan reka bentuk dan pelaksanaan atau keputusan tentang proses berkaitan. Kadangkala boleh melangkaui sistem individu dan sah untuk seluruh organisasi dan syarikat.

Kandungan

Sebarang keperluan yang mengekang kebebasan arkitek perisian dalam keputusan reka bentuk dan pelaksanaan atau keputusan tentang proses pembangunan. Kekangan ini kadangkala melangkaui sistem individu dan sah untuk seluruh organisasi dan syarikat.

Motivasi

Arkitek perlu tahu dengan tepat di mana mereka bebas dalam keputusan reka bentuk mereka dan di mana mereka mesti mematuhi kekangan. Kekangan mesti sentiasa ditangani; walau bagaimanapun ia mungkin boleh dirunding.

Bentuk

Jadual kekangan yang mudah dengan penjelasan. Jika perlu anda boleh membahagikannya kepada kekangan teknikal, kekangan organisasi dan politik serta konvensyen (cth. garis panduan pengaturcaraan atau pembahagian versi, konvensyen dokumentasi atau penamaan)

3. Konteks dan Skop

Menetapkan sempadan sistem anda daripada rakan komunikasi (luaran)nya (sistem jiran dan pengguna). Menentukan antara muka luaran. Ditunjukkan dari perspektif perniagaan/domain (sentiasa) atau perspektif teknikal (pilihan)

Kandungan

Skop dan konteks sistem - seperti namanya - menetapkan sempadan sistem anda (iaitu skop anda) daripada semua rakan komunikasinya (sistem jiran dan pengguna, iaitu konteks sistem anda). Dengan itu ia menentukan antara muka luaran.

Jika perlu, bezakan konteks perniagaan (input dan output khusus domain) daripada konteks teknikal (saluran, protokol, perkakasan).

Motivasi

Antara muka domain dan antara muka teknikal kepada rakan komunikasi adalah antara aspek paling kritikal sistem anda. Pastikan anda memahaminya sepenuhnya.

Bentuk

Pelbagai gambar rajah konteks
Senarai rakan komunikasi dan antara muka mereka.

3.1 Konteks perniagaan

Kandungan

Spesifikasi semua rakan komunikasi (pengguna, sistem IT, …) dengan penjelasan input dan output atau antara muka khusus domain. Secara pilihan anda boleh menambah format khusus domain atau protokol komunikasi.

Motivasi

Semua pihak berkepentingan perlu memahami data apa yang dipertukarkan dengan persekitaran sistem.

Bentuk

Semua jenis gambar rajah yang menunjukkan sistem sebagai kotak hitam dan menentukan antara muka domain kepada rakan komunikasi.

Sebagai alternatif (atau tambahan) anda boleh menggunakan jadual. Tajuk jadual ialah nama sistem anda, tiga lajur mengandungi nama rakan komunikasi, input dan output.

3.2 Konteks teknikal

Kandungan

Antara muka teknikal (saluran dan media penghantaran) yang menghubungkan sistem anda dengan persekitarannya. Di samping itu pemetaan input/output khusus domain kepada saluran, iaitu penjelasan I/O mana yang menggunakan saluran mana.

Motivasi

Ramai pihak berkepentingan membuat keputusan seni bina berdasarkan antara muka teknikal antara sistem dan kontekstnya. Terutamanya pereka infrastruktur atau perkakasan menentukan antara muka teknikal ini.

Bentuk

Cth. gambar rajah penempatan UML yang menerangkan saluran ke sistem jiran, bersama jadual pemetaan yang menunjukkan hubungan antara saluran dan input/output.

4. Strategi Penyelesaian

Ringkasan keputusan asas dan strategi penyelesaian yang membentuk seni bina. Boleh merangkumi teknologi, penguraian peringkat teratas, pendekatan untuk mencapai matlamat kualiti teratas dan keputusan organisasi yang relevan.

Kandungan

Ringkasan dan penjelasan ringkas tentang keputusan asas dan strategi penyelesaian yang membentuk seni bina sistem. Ini termasuk

keputusan teknologi
keputusan tentang penguraian peringkat teratas sistem, cth. penggunaan corak seni bina atau corak reka bentuk
keputusan tentang cara mencapai matlamat kualiti utama
keputusan organisasi yang relevan, cth. memilih proses pembangunan atau mewakilkan tugas tertentu kepada pihak ketiga.

Motivasi

Keputusan ini membentuk batu asas untuk seni bina anda. Ia merupakan asas bagi banyak keputusan terperinci atau peraturan pelaksanaan lain.

Bentuk

Pastikan penjelasan keputusan utama ini ringkas.

Motivasikan apa yang telah anda putuskan dan mengapa anda memutuskan begitu, berdasarkan pernyataan masalah anda, matlamat kualiti dan kekangan utama. Rujuk butiran dalam bahagian berikut (bahagian 5 untuk butiran struktur, bahagian 8 untuk konsep merentas).

Anda boleh menggunakan senarai pendekatan penyelesaian atau jadual.

5. Paparan Blok Binaan

Penguraian statik sistem, abstraksi kod sumber, ditunjukkan sebagai hierarki kotak putih (mengandungi kotak hitam), sehingga tahap perincian yang sesuai.

Kandungan

Paparan blok binaan menunjukkan penguraian statik sistem kepada blok binaan (modul, komponen, subsistem, kelas, antara muka, pakej, pustaka, rangka kerja, lapisan, partisi, peringkat, fungsi, makro, operasi, struktur data, …) serta kebergantungannya (hubungan, perkaitan, …)

Paparan ini wajib untuk setiap dokumentasi seni bina. Secara analogi dengan sebuah rumah, ini ialah pelan lantai.

Motivasi

Kekalkan gambaran keseluruhan kod sumber anda dengan menjadikan strukturnya boleh difahami melalui abstraksi.

Ini membolehkan anda berkomunikasi dengan pihak berkepentingan pada peringkat abstrak tanpa mendedahkan butiran pelaksanaan.

Bentuk

Paparan blok binaan ialah koleksi hierarki kotak hitam dan kotak putih (lihat rajah di bawah) dan penerangannya.

5.1 Kotak Putih Keseluruhan Sistem

Di sini anda menerangkan penguraian keseluruhan sistem menggunakan templat kotak putih berikut. Ia mengandungi

gambar rajah gambaran keseluruhan
motivasi untuk penguraian
penerangan kotak hitam bagi blok binaan yang terkandung. Untuk ini kami menawarkan alternatif:
- gunakan satu jadual untuk gambaran keseluruhan ringkas dan pragmatik semua blok binaan yang terkandung dan antara muka mereka
- gunakan senarai penerangan kotak hitam blok binaan mengikut templat kotak hitam (lihat di bawah). Bergantung pada pilihan alat anda, senarai ini boleh menjadi sub-bab (dalam fail teks), sub-halaman (dalam Wiki) atau elemen bersarang (dalam alat pemodelan).
- (pilihan:) antara muka penting, yang tidak dijelaskan dalam templat kotak hitam blok binaan, tetapi sangat penting untuk memahami kotak putih.

Memandangkan terdapat begitu banyak cara untuk menentukan antara muka, mengapa tidak menyediakan templat khusus untuknya.

Dalam kes terbaik anda akan terlepas dengan contoh atau tandatangan mudah.

5.2 Peringkat 2

Di sini anda boleh menentukan struktur dalaman (sebahagian) blok binaan daripada peringkat 1 sebagai kotak putih.

Anda perlu memutuskan blok binaan sistem anda yang mana cukup penting untuk menjustifikasikan penerangan terperinci sedemikian. Utamakan kerelevanan berbanding kelengkapan. Tentukan blok binaan yang penting, mengejutkan, berisiko, kompleks atau tidak stabil. Tinggalkan bahagian sistem anda yang biasa, mudah, membosankan atau berpiawaian

5.2.1 Kotak Putih untuk blok binaan 1

Menentukan struktur dalaman blok binaan 1.

Gunakan templat kotak putih (lihat di atas).

6. Paparan Masa Larian

Tingkah laku blok binaan sebagai senario, meliputi kes penggunaan atau ciri penting, interaksi pada antara muka luaran kritikal, operasi dan pentadbiran serta tingkah laku ralat dan pengecualian.

Kandungan

Paparan masa larian menerangkan tingkah laku dan interaksi konkrit blok binaan sistem dalam bentuk senario daripada bidang berikut:

kes penggunaan atau ciri penting: bagaimana blok binaan melaksanakannya?
interaksi pada antara muka luaran kritikal: bagaimana blok binaan bekerjasama dengan pengguna dan sistem jiran?
operasi dan pentadbiran: pelancaran, permulaan, berhenti
senario ralat dan pengecualian

Catatan: Kriteria utama untuk pemilihan senario yang mungkin (jujukan, aliran kerja) ialah kerelevanan seni binanya. Tidak penting untuk menerangkan bilangan senario yang besar. Anda sepatutnya mendokumenkan pilihan yang mewakili.

Motivasi

Anda perlu memahami bagaimana (contoh) blok binaan sistem anda menjalankan tugas dan berkomunikasi pada masa larian. Anda terutamanya akan merakam senario dalam dokumentasi anda untuk menyampaikan seni bina anda kepada pihak berkepentingan yang kurang bersedia atau mampu membaca dan memahami model statik (paparan blok binaan, paparan penempatan).

Bentuk

Terdapat banyak tatatanda untuk menerangkan senario, cth.

senarai langkah bernombor (dalam bahasa semula jadi)
gambar rajah aktiviti atau carta alir
gambar rajah jujukan
BPMN atau EPC (rantaian proses peristiwa)
mesin keadaan
dan sebagainya.

6.n Senario Masa Larian n (1, 2, 3, dsb.)

Sisipkan gambar rajah masa larian atau penerangan teks senario.

Sisipkan penerangan aspek ketara interaksi antara contoh blok binaan yang digambarkan dalam gambar rajah ini.

7. Paparan Penempatan

Infrastruktur teknikal dengan persekitaran, komputer, pemproses, topologi. Pemetaan blok binaan (perisian) kepada elemen infrastruktur.

Kandungan

Paparan penempatan menerangkan:

infrastruktur teknikal yang digunakan untuk melaksanakan sistem anda, dengan elemen infrastruktur seperti lokasi geografi, persekitaran, komputer, pemproses, saluran dan topologi rangkaian serta elemen infrastruktur lain dan
pemetaan blok binaan (perisian) kepada elemen infrastruktur tersebut.

Selalunya sistem dilaksanakan dalam persekitaran berbeza, cth. persekitaran pembangunan, persekitaran ujian, persekitaran pengeluaran. Dalam kes sedemikian anda perlu mendokumenkan semua persekitaran yang relevan.

Dokumenkan paparan penempatan terutamanya apabila perisian anda dilaksanakan sebagai sistem teragih dengan lebih daripada satu komputer, pemproses, pelayan atau kontena atau apabila anda mereka bentuk dan membina pemproses perkakasan dan cip anda sendiri.

Dari perspektif perisian, memadai untuk merakam elemen infrastruktur yang diperlukan untuk menunjukkan penempatan blok binaan anda. Arkitek perkakasan boleh melangkaui itu dan menerangkan infrastruktur sehingga mana-mana tahap perincian yang mereka perlu rakam.

Motivasi

Perisian tidak berjalan tanpa perkakasan. Infrastruktur asas ini boleh dan akan mempengaruhi sistem anda dan/atau beberapa konsep merentas. Oleh itu, anda perlu mengetahui infrastruktur.

Bentuk

Mungkin gambar rajah penempatan peringkat tertinggi sudah terkandung dalam bahagian 3.2. sebagai konteks teknikal dengan infrastruktur anda sendiri sebagai SATU kotak hitam. Dalam bahagian ini anda akan mengezum ke dalam kotak hitam ini menggunakan gambar rajah penempatan tambahan.

UML menawarkan gambar rajah penempatan untuk menyatakan paparan itu. Gunakannya, mungkin dengan gambar rajah bersarang, apabila infrastruktur anda lebih kompleks.
Apabila pihak berkepentingan (perkakasan) anda lebih suka jenis gambar rajah lain berbanding gambar rajah penempatan UML, biarkan mereka menggunakan mana-mana jenis yang mampu menunjukkan nod dan saluran infrastruktur.

7.1 Infrastruktur Peringkat 1

Terangkan (biasanya dalam gabungan gambar rajah, jadual dan teks):

pengedaran sistem anda ke berbilang lokasi, persekitaran, komputer, pemproses, .. serta sambungan fizikal antara mereka
justifikasi atau motivasi penting untuk struktur penempatan ini
ciri kualiti dan/atau prestasi infrastruktur
pemetaan artifak perisian (blok binaan) kepada elemen infrastruktur

Untuk berbilang persekitaran atau penempatan alternatif sila salin bahagian arc42 itu untuk semua persekitaran yang relevan. **

7.2 Infrastruktur Peringkat 2

Di sini anda boleh memasukkan struktur dalaman (sebahagian) elemen infrastruktur daripada infrastruktur peringkat 1.

Sila salin struktur daripada peringkat 1 untuk setiap elemen yang dipilih.

8. Konsep Merentas

Secara keseluruhan, peraturan prinsip dan pendekatan penyelesaian yang relevan dalam berbilang bahagian (→ merentas) sistem. Konsep selalunya berkaitan dengan berbilang blok binaan. Termasuk topik berbeza seperti model domain, corak seni bina dan gaya, peraturan penggunaan teknologi tertentu dan peraturan pelaksanaan.

Kandungan

Bahagian ini menerangkan konsep merentas (amalan, corak, peraturan atau idea penyelesaian). Konsep sedemikian selalunya berkaitan dengan berbilang blok binaan. Ia mungkin merangkumi banyak topik berbeza.

Motivasi

Konsep membentuk asas integriti konseptual (konsistensi, kehomogenan) seni bina. Oleh itu, ia merupakan sumbangan penting untuk mencapai kualiti dalaman sistem anda.

Ini ialah tempat dalam templat yang kami sediakan untuk spesifikasi padu konsep sedemikian.

Banyak konsep ini berkaitan dengan atau mempengaruhi beberapa blok binaan anda.

Bentuk

Bentuknya boleh pelbagai:

kertas konsep dengan sebarang jenis struktur
pelaksanaan contoh, terutamanya untuk konsep teknikal
petikan model merentas atau senario menggunakan tatatanda paparan seni bina

Struktur bahagian ini

Pilih hanya topik yang paling diperlukan untuk sistem anda dan tetapkan setiap satu tajuk peringkat-2 dalam bahagian ini (cth. 8.1, 8.2 dan sebagainya).

JANGAN CUBA meliputi semua topik dalam gambar rajah yang dinyatakan di atas.

Latar belakang

Sesetengah topik dalam sistem selalunya melibatkan berbilang blok binaan, elemen perkakasan atau proses pembangunan. Mungkin lebih mudah untuk menyampaikan atau mendokumenkan topik merentas sedemikian di lokasi pusat, dan bukannya mengulanginya dalam penerangan blok binaan, elemen perkakasan atau proses pembangunan yang berkenaan.

Konsep tertentu mungkin melibatkan semua elemen sistem, yang lain mungkin hanya relevan untuk beberapa.

9. Keputusan Seni Bina

Keputusan seni bina yang penting, mahal, kritikal, berskala besar atau berisiko termasuk rasional.

Kandungan

Keputusan seni bina yang penting, mahal, berskala besar atau berisiko termasuk rasional. Dengan “keputusan” kami maksudkan memilih satu alternatif berdasarkan kriteria yang diberikan.

Sila gunakan budi bicara anda untuk memutuskan sama ada keputusan seni bina perlu didokumenkan di sini dalam bahagian pusat ini atau lebih baik anda mendokumenkannya secara setempat (cth. dalam templat kotak putih satu blok binaan). Elakkan teks berlebihan. Rujuk bahagian 4, di mana anda sudah merakam keputusan terpenting seni bina anda.

Motivasi

Pihak berkepentingan sistem anda sepatutnya dapat memahami dan menjejak semula keputusan anda.

Bentuk

ADR (rekod keputusan seni bina) untuk setiap keputusan penting
senarai atau jadual, disusun mengikut kepentingan dan akibat atau
lebih terperinci dalam bentuk bahagian berasingan bagi setiap keputusan

Latar belakang (tentang ADR)

Kepingan dokumentasi yang lebih kecil lebih mudah dibaca, dicipta dan diselenggara. Apabila melibatkan keputusan seni bina, pasukan pembangunan sering:

tahu tentang keputusan itu, kerana ia kelihatan cth. dalam kod sumber, tetapi
terlepas motivasi di sebalik keputusan itu (lihat Nygard 2011)

Oleh itu anda perlu mendokumenkan beberapa keputusan penting bersama motivasi dan penaakulan mereka

Cadangan kami mengenai keputusan

Simpan koleksi keputusan yang signifikan dari segi seni bina, iaitu keputusan yang mempengaruhi struktur, ciri kualiti, kebergantungan (terutamanya luaran) dan antara muka penting, atau teknik pembinaan (terima kasih kepada Michael Nygard untuk cadangan ini).

10. Keperluan Kualiti

Keperluan kualiti sebagai senario, dengan pokok kualiti untuk menyediakan gambaran keseluruhan peringkat tinggi. Matlamat kualiti terpenting sepatutnya telah diterangkan dalam bahagian 1.2. (matlamat kualiti).

Kandungan

Bahagian ini mengandungi semua keperluan kualiti yang relevan.

Yang terpenting daripada keperluan ini telah pun diterangkan dalam bahagian 1.2. (matlamat kualiti), oleh itu ia hanya perlu dirujuk di sini. Dalam bahagian 10 ini anda juga perlu merakam keperluan kualiti yang kurang penting, yang tidak akan mewujudkan risiko tinggi apabila tidak dicapai sepenuhnya (tetapi mungkin bagus untuk dimiliki).

Motivasi

Memandangkan keperluan kualiti akan mempunyai banyak pengaruh ke atas keputusan seni bina anda perlu mengetahui kualiti apa yang benar-benar penting untuk pihak berkepentingan anda, dengan cara yang khusus dan boleh diukur.

Maklumat Lanjut

Lihat model kualiti Q42 yang meluas di https://quality.arc42.org.

10.1 Gambaran Keseluruhan Keperluan Kualiti

Kandungan

Gambaran keseluruhan atau ringkasan keperluan kualiti.

Motivasi

Selalunya kami menemui berpuluh (atau malah beratus) keperluan kualiti terperinci. Dalam bahagian gambaran keseluruhan ini anda perlu cuba meringkaskan, cth. dengan menerangkan kategori atau topik (seperti yang dicadangkan oleh ISO 25010:2023 atau Q42

Jika penerangan ringkasan ini sudah tepat, cukup khusus dan boleh diukur, anda boleh melangkau bahagian 10.2.

Bentuk

Gunakan jadual mudah di mana setiap baris mengandungi kategori atau topik dan penerangan ringkas keperluan kualiti. Sebagai alternatif, anda boleh menggunakan peta minda untuk menstrukturkan keperluan kualiti ini.

Dalam literatur, idea pokok atribut kualiti juga telah diterangkan, yang meletakkan istilah umum “kualiti” sebagai akar dan menggunakan penghalusan istilah “kualiti” seperti pokok. [Bass+21] memperkenalkan istilah “Quality Attribute Utility Tree” untuk tujuan ini.

10.2 Senario Kualiti

Kandungan

Senario kualiti menjadikan keperluan kualiti konkrit dan membolehkan keputusan sama ada ia dipenuhi (dalam erti kriteria penerimaan). Pastikan senario anda khusus dan boleh diukur.

Dua jenis senario amat berguna:

Senario penggunaan (juga dipanggil senario aplikasi atau senario kes penggunaan) menerangkan tindak balas masa larian sistem terhadap rangsangan tertentu. Ini juga termasuk senario yang menerangkan kecekapan atau prestasi sistem. Contoh: Sistem bertindak balas kepada permintaan pengguna dalam masa satu saat.
Senario perubahan menerangkan kesan yang dikehendaki bagi pengubahsuaian atau lanjutan sistem atau persekitaran terdekatnya. Contoh: Fungsi tambahan dilaksanakan atau keperluan untuk atribut kualiti berubah, dan usaha atau tempoh perubahan diukur.

Bentuk

Maklumat biasa untuk senario terperinci termasuk yang berikut:

Dalam bentuk ringkas (diutamakan dalam model Q42):

Konteks/Latar belakang: Apakah jenis sistem atau komponen, apakah persekitaran atau situasi?
Sumber/Rangsangan: Siapa atau apa yang memulakan atau mencetuskan tingkah laku, tindak balas atau tindakan.
Metrik/Kriteria Penerimaan: Tindak balas termasuk ukuran atau metrik

Bentuk panjang senario (diutamakan oleh SEI dan [Bass+21]) lebih terperinci dan merangkumi maklumat berikut:

ID Senario: Pengecam unik untuk senario.
Nama Senario: Nama ringkas dan deskriptif untuk senario.
Sumber: Entiti (pengguna, sistem atau peristiwa) yang memulakan senario.
Rangsangan: Peristiwa atau keadaan pencetus yang mesti ditangani sistem.
Persekitaran: Konteks atau keadaan operasi di mana sistem mengalami rangsangan.
Artifak: Blok binaan atau elemen lain sistem yang terjejas oleh rangsangan.
Tindak balas: Hasil atau tingkah laku yang dipamerkan sistem sebagai tindak balas kepada rangsangan.
Ukuran Tindak Balas: Kriteria atau metrik yang digunakan untuk menilai tindak balas sistem.

Lihat juga

Sejak Januari 2023, arc42 menyediakan model kualiti pragmatik, yang mencadangkan melabel keperluan kualiti, dengan hashtag atau label seperti #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable.

11. Risiko dan Hutang Teknikal

Risiko teknikal atau hutang teknikal yang diketahui. Apakah masalah yang berpotensi wujud dalam atau sekitar sistem? Apakah yang membuatkan pasukan pembangunan berasa menyedihkan?

Kandungan

Senarai risiko teknikal atau hutang teknikal yang dikenal pasti, disusun mengikut keutamaan

Motivasi

“Pengurusan risiko ialah pengurusan projek untuk orang dewasa” (Tim Lister, Atlantic Systems Guild.)

Ini sepatutnya menjadi moto anda untuk pengesanan dan penilaian sistematik risiko dan hutang teknikal dalam seni bina, yang akan diperlukan oleh pihak berkepentingan pengurusan (cth. pengurus projek, pemilik produk) sebagai sebahagian daripada analisis risiko keseluruhan dan perancangan pengukuran.

Bentuk

Senarai risiko dan/atau hutang teknikal, mungkin termasuk langkah yang dicadangkan untuk meminimumkan, mengurangkan atau mengelakkan risiko atau mengurangkan hutang teknikal.