rumah Manual Contoh catatan penjelasan untuk kerangka acuan. Dokumentasi teknis

Contoh catatan penjelasan untuk kerangka acuan. Dokumentasi teknis

Hari ini kita akan berbicara tentang standar domestik untuk dokumentasi desain. Bagaimana standar ini bekerja dalam praktiknya, mengapa itu buruk dan apa yang baik. Saat mengembangkan dokumentasi untuk pelanggan publik dan swasta yang serius, kami biasanya tidak punya pilihan - kepatuhan terhadap standar tertulis dalam persyaratan untuk mendokumentasikan spesifikasi teknis. Dalam praktiknya, saya telah menemukan berbagai contoh kesalahpahaman tentang struktur standar, apa yang harus ada dalam dokumen dan mengapa dokumen tersebut diperlukan. Akibatnya, terkadang permata seperti itu keluar dari pena penulis teknis, analis, dan spesialis sehingga tidak jelas dalam kondisi kesadaran apa mereka ditulis. Namun nyatanya, semuanya cukup sederhana. Pencarian di Habr tidak menghasilkan link ke materi yang kurang lebih lengkap tentang topik ini, oleh karena itu saya mengusulkan untuk mengisi celah yang mengganggu ini.

Apa standar dokumentasi?

Hanya ada 3 standar pendokumentasian utama dalam 34 seri yang dimaksud:

Standar yang paling disukai dan populer untuk pengembangan spesifikasi teknis. Satu-satunya hal yang tidak boleh Anda lupakan adalah bahwa itu terkait erat dengan standar seri lainnya dan jika Anda menerima spesifikasi teknis, dijalankan sesuai dengan standar ini, sangat diinginkan untuk mematuhi standar lain, bahkan jika tidak ada persyaratan langsung untuk ini. Setidaknya dalam hal ideologi umum (tentang yang di bawah)

Ini adalah dokumen dasar yang memberikan daftar lengkap dokumentasi GOST 34, rekomendasi untuk pengkodean dokumen, tahapan proyek apa yang dimiliki dokumen tersebut (tahapan tersebut dijelaskan dalam GOST 34.601-90), dan bagaimana mereka dapat digabungkan satu sama lain.

Faktanya, standar ini adalah tabel beranotasi besar. Ini dapat didorong ke Excel untuk kemudahan penggunaan.

Standar yang sangat banyak yang mendeskripsikan isi dokumen proyek dengan berbagai tingkat detail. GOST 34.201-89 yang disebutkan di atas digunakan sebagai indeks.

Ada banyak pertanyaan dan interpretasi atas ketentuannya terhadap standar RD 50-34.698-90, yang karena ambiguitasnya, sering kali dipahami secara berbeda oleh pelanggan dan kontraktor, atau bahkan anggota tim proyek. Tapi, sayangnya, kami tidak memiliki yang lebih konkret.

Sekarang mari kita pertimbangkan pro dan kontra dari standar, dimulai secara tradisional dengan yang kontra.

Kontra standar

Kerugian utama jelas bagi semua orang - standarnya sudah lama. Mereka berisi pemahaman yang sudah ketinggalan zaman tentang arsitektur sistem otomatis. Sebagai contoh:

aplikasi dua tingkat, terdiri dari program klien dan server basis data (tidak ada tiga atau lebih aplikasi "tingkat", tidak ada Weblogic atau JBoss)
struktur tabel database, yang dijelaskan, akan memberikan gambaran tentang model data logis (fakta bahwa mungkin ada beberapa Hibernate antara aplikasi dan database tampak seperti kelebihan yang buruk)
antarmuka pengguna adalah satu jendela (mungkinkah berbeda? Apa itu "browser"?)
Tidak banyak laporan dalam sistem, semuanya berupa kertas dan dicetak pada printer dot matrix
Program yang dikembangkan difokuskan pada pemecahan "masalah pemrosesan informasi", yang memiliki masukan dan keluaran yang jelas dan sangat terspesialisasi. Pemrosesan informasi didasarkan pada "algoritma". Terkadang ada beberapa "algoritma". (Pemrograman berorientasi objek hanya mengambil langkah pertama saat itu dan tidak dipertimbangkan secara serius.)
administrator database memahami informasi apa yang ada dalam tabel dan secara aktif berpartisipasi dalam pengeditan direktori sistem (apakah benar-benar ada satu server DBMS untuk 50 aplikasi yang berbeda?)

Oleh karena itu, standar tersebut memiliki artefak seperti berikut:

5.8. Menggambar bentuk dokumen (bingkai video)
Dokumen tersebut harus berisi gambar dalam bentuk dokumen atau bingkai video sesuai dengan persyaratan standar negara sistem dokumentasi terpadu R 50-77 dan penjelasan yang diperlukan.

Arti dari dokumen tersebut adalah bahwa apa yang disebut "Area Percetakan" digunakan di perusahaan Soviet, tempat printer dot matrix berkecepatan tinggi berada, yang drivernya sering kali ditulis oleh para insinyur itu sendiri. Oleh karena itu, mereka harus menyimpan daftar semua dokumen yang perlu dicetak untuk memastikan bahwa dokumen yang dicetak akan terlihat sebagaimana mestinya.

Sebuah "bingkai video" juga merupakan dokumen yang ditampilkan pada tampilan teks. Tampilan tidak selalu mendukung karakter yang diperlukan dan jumlah karakter yang diperlukan secara horizontal dan vertikal (dan tidak mendukung grafik sama sekali). Oleh karena itu, di sini juga, perlu juga untuk mengoordinasikan bentuk dari semua dokumen layar.

Sekarang kata-kata "mesin-gram", "bingkai video", "ADCP" tidak berarti apa-apa. Saya juga tidak menemukannya sedang digunakan, meskipun saya lulus dari institut khusus di tahun 90-an. Ini adalah waktu kemunculan Windows 3.1, tampilan VGA, floppy disk tiga inci, dan situs Internet domestik pertama. Tetapi kata-kata ini ada dalam standar, dan pelanggan terkadang dengan gegabah meminta untuk memberinya kumpulan dokumentasi lengkap sesuai dengan GOST 34.201-89. Selain itu, rumusan serupa di TK merembes dari satu kementerian ke kementerian lain dan telah menjadi semacam template tak terucapkan ke dalam bagian substantif didorong.

Jadi dokumen dengan nama bodoh "Menggambar bentuk dokumen (bingkai video)" dalam proyek harus dan tidak boleh kosong.

Apa yang bagus di standar

Setiap standar sudah baik karena memungkinkan pelanggan dan kontraktor untuk berbicara dalam bahasa yang sama dan memberikan jaminan bahwa, setidaknya dalam bentuk, pelanggan tidak akan memiliki klaim "dalam bentuk" untuk hasil yang dikirimkan.

Dan standar GOST 34 juga bagus karena disusun oleh orang-orang pintar, diuji selama bertahun-tahun dan memiliki tujuan yang jelas - untuk mendeskripsikan semaksimal mungkin di atas kertas entitas abstrak kompleks yang diwakili oleh ACS mana pun.

Saat Anda perlu menetapkan tugas secara kompeten untuk kontraktor Barat yang belum pernah mendengar tentang GOST kami, Anda juga dapat mengandalkan standar ini, atau lebih tepatnya pada konten mereka, komponen semantik. Sebab, lagi-lagi jaminan kelengkapan informasi itu bernilai tinggi. Tidak peduli bagaimana kita memanjakan diri kita dengan profesionalisme tingkat tinggi kita, kita bisa lupa untuk memasukkan hal-hal dasar dalam persyaratan kita, sementara GOST 34.602-89 yang sama "mengingat" semuanya. Jika Anda tidak memahami bagaimana hasil pekerjaan kontraktor Barat seharusnya terlihat, lihat persyaratan untuk dokumentasi, untuk bagian yang direkomendasikan. Saya yakinkan Anda, lebih baik tidak memikirkannya! Kemungkinan besar, ada analogi Barat dari standar kami, di mana semuanya bisa lebih lengkap, lebih modern dan lebih baik. Sayangnya, saya tidak mengenal mereka, karena belum ada satu kasus pun yang GOST kami tidak akan cukup.

Anda dapat menertawakan fakta bahwa pencipta standar tidak tahu apa-apa tentang java atau .NET, tentang monitor HD dan Internet, tetapi saya tidak akan merekomendasikan meremehkan skala pekerjaan mereka dan nilainya bagi komunitas profesional kami.

Cara membaca dan memahami standar dokumentasi GOST seri 34

Standar membagi semua dokumen dalam dua sumbu - waktu dan area subjek. Jika Anda melihat tabel 2 di GOST 34.201-89, Anda dapat dengan jelas melihat divisi ini (kolom "Tahap pembuatan" dan "Bagian dari proyek"

Tahapan pembuatan ACS

Tahapan pembuatan ditentukan di GOST 34.601-90. Tiga di antaranya relevan dengan dokumentasi:

Proyek draf (EP)
Desain teknis (TP)
Pengembangan dokumentasi kerja (RD)

Desain awal mengikuti tahapan Kerangka Acuan dan berfungsi untuk mengembangkan solusi desain awal.

Proyek teknis menggambarkan sistem masa depan dari semua sudut. Dokumen tahap TP harus, setelah membaca, meninggalkan kejelasan lengkap dalam pendekatan, metode, arsitektur dan solusi teknis yang diusulkan. Pada fase berikutnya, akan sangat terlambat untuk mendeskripsikan pendekatan dan membenarkan solusi teknis, sehingga fase P adalah kunci keberhasilan pengiriman pekerjaan, karena semua variasi persyaratan TOR harus tercermin dalam dokumen fase P. Pada tahap P, sistem mungkin tidak ada sama sekali.

Dokumentasi kerja dirancang untuk penerapan yang sukses, komisioning, dan operasi lebih lanjut dari sistem baru. Ini adalah dokumen yang berisi informasi sangat spesifik yang menggambarkan entitas yang ada secara fisik, berbeda dengan Fase P, yang menggambarkan kemegahan masa depan.

Bagian (bagian) dari dokumentasi proyek untuk pembuatan sistem kendali otomatis

Bidang subjek dibagi menjadi "Ketentuan". Pada awalnya tampaknya pembagian seperti itu mubazir dan tidak perlu. Tetapi ketika Anda mulai menggunakan perangkat ini dalam praktiknya, ideologi yang tertanam di dalamnya secara bertahap mencapai.

Sistem otomatis yang ada di benak penyusun GOST merupakan gabungan dari perangkat keras, perangkat lunak dan saluran komunikasi yang memproses informasi yang datang dari sumber yang berbeda sesuai dengan algoritma tertentu dan memberikan hasil pengolahan berupa dokumen, struktur data atau tindakan kontrol. Model primitif dari robot paling sederhana.

Untuk mendeskripsikan "robot" ini sepenuhnya, pemotongan berikut dilakukan (seperti pada gambar):

Perangkat Lunak (MO), yang menjawab pertanyaan: logika apa yang tertanam di dalam "kotak hitam"? Mengapa algoritma ini dipilih, rumus yang persis seperti itu dan koefisien yang persis seperti itu?

Perangkat lunak tidak tahu apa-apa tentang prosesor atau database. Ini adalah area abstrak terpisah, tempat tinggal "kuda bulat dalam ruang hampa". Tetapi perangkat lunak ini sangat erat hubungannya dengan subjek, alias kehidupan nyata. Misalnya, algoritma kendali untuk sistem kendali lalu lintas harus disetujui oleh polisi lalu lintas sebelum disetujui oleh pelanggan. Dan kemudian Anda mengerti mengapa mereka dikhususkan sebagai buku terpisah. Karena di polisi lalu lintas, tidak ada yang tertarik dengan OS apa yang akan dijalankan oleh server aplikasi, tetapi tanda dan batas kecepatan apa yang akan muncul di papan skor saat hujan atau salju sangat menarik. Mereka bertanggung jawab atas bagian mereka, dan tidak akan menandatangani apa pun. Di sisi lain, ketika mereka menandatangani, tidak akan ada pertanyaan ke sisi teknis dari pertanyaan - mengapa mereka memilihnya dan bukan papan atau lampu lalu lintas lain. Kebijaksanaan "leluhur" justru dimanifestasikan dalam kasus praktis seperti itu.

Dukungan informasi (IO)... Potongan lain dari sistem. Kali ini kotak hitam sistem kami menjadi transparan dan kami melihat informasi yang beredar di dalamnya. Bayangkan sebuah model sistem peredaran darah manusia, ketika semua organ lainnya tidak terlihat. Ini adalah sesuatu yang serupa dan ada dukungan Informasi. Ini menggambarkan komposisi dan rute informasi yang lewat di dalam dan di luar, organisasi logis informasi dalam sistem, deskripsi buku referensi dan sistem pengkodean (siapa pun yang membuat program untuk produksi tahu betapa pentingnya program itu). Bagian deskriptif utama berada pada tahap TP, tetapi beberapa "dasar" mengalir ke tahap RD, seperti dokumen "Katalog database". Jelas bahwa sebelumnya isinya persis seperti yang tertulis di judulnya. Tetapi hari ini mencoba untuk membentuk dokumen seperti itu untuk sistem yang kompleks yang kompleks, ketika sangat sering membeli subsistem dengan penyimpanan informasi misterius mereka digunakan sebagai bagian dari sistem. Saya bahkan tidak berbicara tentang fakta bahwa dokumen ini tidak terlalu dibutuhkan sekarang.

Atau di sini adalah "Pernyataan Media Informasi Mesin". Jelas bahwa itu dulunya berisi sejumlah drum magnet atau gulungan film. Dan sekarang apa yang harus dibawa ke sana?

Singkatnya, selama fase RD, dokumen Dukungan Informasi adalah dasar yang agak merusak, karena secara formal seharusnya begitu, tetapi tidak ada yang khusus untuk diisi.

Software (perangkat lunak)... Bagian favorit semua orang dari dokumentasi proyek. Ya, jika hanya karena ini hanya satu dokumen! Dan kemudian, semua orang mengerti apa yang perlu direkam di sana. Tapi saya, sama saja, akan mengulanginya.

Dalam dokumen ini, kita harus mengetahui dengan perangkat lunak apa algoritma yang dijelaskan dalam IO dijalankan, yang memproses informasi yang dijelaskan dalam IO. Artinya, tidak perlu menggandakan informasi dari bagian lain di sini. Ini memberikan arsitektur sistem, alasan untuk teknologi perangkat lunak yang dipilih, deskripsi mereka (semua jenis sistem: bahasa pemrograman, kerangka kerja, sistem operasi, dll.). Juga dalam dokumen ini kami menjelaskan bagaimana alat pemrosesan informasi diatur (antrian pesan, penyimpanan, alat cadangan, solusi ketersediaan, semua jenis kumpulan aplikasi, dll.). Standar tersebut berisi penjelasan rinci tentang isi dokumen ini, yang dapat dipahami oleh semua pakar.

Dukungan teknis (TO)... Tidak kurang dicintai oleh semua orang, menjadi bagian dari dokumentasi proyek. Gambar yang cerah menjadi gelap hanya dengan banyaknya dokumen yang akan dikembangkan. Secara total, standar tersebut membutuhkan pengembangan 22 dokumen, dimana 9 di antaranya berada pada tahap TP.

Faktanya adalah bahwa standar memberikan gambaran tentang semua dukungan teknis, termasuk perangkat keras dan jaringan komputer, sistem teknik dan bahkan bagian konstruksi (jika diperlukan). Dan ekonomi ini diatur oleh sejumlah besar standar dan peraturan, konsisten di berbagai organisasi dan oleh karena itu lebih mudah untuk membagi semuanya menjadi beberapa bagian dan mengoordinasikan (edit) dalam beberapa bagian. Pada saat yang sama, standar memungkinkan Anda untuk menggabungkan beberapa dokumen satu sama lain, yang masuk akal untuk dilakukan jika seluruh heap dikoordinasikan oleh satu orang.

Jangan lupa juga bahwa kumpulan standar kualitas menyiratkan akuntansi dan penyimpanan dokumen teknis, dan "pembukuan" kami di pelanggan mungkin tersebar di berbagai arsip, tergantung pada subjek deskripsi. Ini adalah argumen lain yang mendukung fragmentasi dokumentasi.

Dukungan organisasi (OO)... Setelah menekan keinginan, normal bagi seorang teknisi, untuk melewati bagian ini sesegera mungkin, sebaliknya, saya akan mempertimbangkannya secara lebih rinci. Sejak itu, kolega, dalam beberapa tahun terakhir tren buruk telah diuraikan pada proyek-proyek yang membutuhkan klarifikasi di bagian ini.

Pada tahap TP, bagian tersebut hanya berisi satu dokumen " Deskripsi struktur organisasi", Di mana kami harus memberi tahu pelanggan apa yang harus dia persiapkan dalam hal mengubah struktur organisasi. Tiba-tiba Anda perlu mengatur departemen baru untuk mengoperasikan sistem Anda, memperkenalkan posisi baru, dll.

Pada tahap RD, muncul dokumen lain yang lebih menarik, yang ingin saya pertimbangkan secara terpisah.

Panduan pengguna... Komentar tidak berguna, saya kira.

Metode (teknologi) desain dengan bantuan komputer... Dalam dokumen ini, jika perlu, Anda dapat mencantumkan deskripsi proses pembuatan perangkat lunak, kontrol versi, pengujian, dll. Tetapi ini jika di TK pelanggan ingin merakit perangkat lunak secara pribadi. Jika dia tidak menuntutnya (dan tidak membayarnya), maka seluruh dapur batin Anda bukanlah urusannya, dan dokumen ini tidak perlu diselesaikan.

Instruksi teknologi... Sehubungan dengan gaya untuk formalisasi proses bisnis, pelanggan yang licik terkadang berupaya menjejalkan prosedur operasi ke dalam dokumen ini. Jadi, ini sama sekali tidak perlu.

Deskripsi proses bisnis, peran dan deskripsi pekerjaan, peraturan kerja - semua ini adalah ORD, yaitu dokumentasi organisasi dan administrasi. Yang merupakan produk dari proyek konsultasi yang, sejauh yang saya mengerti, tidak dibeli dari Anda. Dan mereka membeli proyek teknis dari Anda dan juga dokumentasi teknis untuk itu.

Instruksi teknologi adalah lapisan antara ORD dan manual pengguna. RP menjelaskan secara rinci sebagai Anda perlu melakukan tindakan tertentu dalam sistem. Kata instruksi teknologi jenis apa tindakan harus dilakukan dalam kasus tertentu yang terkait dengan pengoperasian sistem. Secara kasar, instruksi teknologi adalah intisari singkat dari RP untuk posisi atau peran tertentu. Jika pelanggan tidak menentukan peran, atau dia ingin Anda membuat peran dan persyaratan pekerjaan sendiri, sertakan peran paling dasar dalam dokumen, misalnya: operator, operator senior, administrator. Komentar pelanggan tentang topik “tapi kami tidak menyukainya” atau “tapi kami tidak menyukainya” harus disertai dengan daftar peran dan uraian tugas. Karena bisnis proses kita jangan letakkan... Kami adalah proses bisnis ini mengotomatisasikan.

Saya akan menulis tentang penggaruk yang dijelaskan secara terpisah, dengan contoh yang berwarna-warni, karena ini bukan pertama kalinya hal itu diulangi di berbagai sektor "ekonomi nasional".

Deskripsi proses teknologi pemrosesan data (termasuk teleprocessing)... Sebuah dasar yang menyedihkan dari zaman gua, ketika ada "Operator Komputer" yang ditunjuk memberi makan mesin dengan kartu berlubang dan mengemas hasil cetakan ke dalam amplop. Instruksi ini untuk mereka. Apa yang harus ditulis di abad XXI - Saya tidak bisa memberi tahu Anda secara pasti. Lepaskan diri Anda. Hal terbaik adalah melupakan dokumen ini.

Solusi seluruh sistem (OR)... Standar menyediakan 17 dokumen bagian OP. Pertama, ada hampir semua dokumen dari tahap Draft Design awal. Kedua, ini semua adalah jenis perkiraan, penghitungan, dan deskripsi singkat tentang fungsi otomatis. Artinya, informasi untuk orang-orang bukan dari produksi TI utama, tetapi untuk personel pendukung - manajer, perkiraan biaya, spesialis pengadaan, ekonom, dll.

Dan ketiga, OR menyertakan mega-dokumen yang disebut "Catatan penjelasan untuk proyek teknis", yang menurut idenya, adalah semacam Ringkasan Eksekutif, dan pada kenyataannya banyak desainer memasukkan ke dalamnya semua konten yang berguna dari tahap TP. Pendekatan radikal seperti itu terkadang dapat dibenarkan dan bahkan saling menguntungkan baik bagi pelanggan maupun kontraktor, tetapi dalam kasus tertentu.

Varian penggunaan GOST 34

Kepatuhan penuh dan tepat terhadap standar... Secara alami, tidak ada yang secara sukarela akan menulis dokumen awan seperti itu. Oleh karena itu, satu set lengkap dokumen disiapkan hanya atas permintaan pelanggan yang mendesak, yang ia amankan di TK dan menghancurkannya dari atas dengan kesepakatan. Dalam hal ini, Anda perlu memahami semuanya secara harfiah dan memberikan "buku" fisik kepada pelanggan, yang akan berisi nama-nama dokumen dari tabel 2 GOST 34.201-89, kecuali yang sama sekali tidak perlu, daftar yang pasti harus Anda diskusikan dan perbaiki secara tertulis. Isi dokumen juga harus sesuai tanpa imajinasi apa pun dengan RD 50-34.698-90, sampai ke judul bagian. Agar otak pelanggan meledak, terkadang sistem besar dibagi menjadi beberapa subsistem, dan dokumentasi desain terpisah dikeluarkan untuk setiap subsistem. Itu terlihat menakutkan dan tidak dapat dikendalikan secara normal dengan bantuan pikiran duniawi. Terutama dalam hal integrasi subsistem. Ini sangat menyederhanakan penerimaan. Hal utama adalah Anda sendiri tidak bingung dan sistem Anda masih berfungsi sebagaimana mestinya.
Kami sangat menyukai GOST... Perusahaan besar yang serius menyukai standar. Karena mereka membantu orang lebih memahami satu sama lain. Jika pelanggan Anda terlihat menyukai ketertiban dan standardisasi, cobalah untuk mengikuti ideologi standar GOST saat mengembangkan dokumen, meskipun hal ini tidak diwajibkan oleh spesifikasi teknis. Anda akan lebih dipahami dan disetujui oleh spesialis koordinator, dan Anda sendiri tidak akan lupa untuk memasukkan informasi penting dalam dokumentasi, Anda akan lebih baik melihat struktur target dokumen, lebih akurat merencanakan pekerjaan pada tulisan mereka dan menyelamatkan diri Anda dan kolega Anda dari banyak saraf dan uang.
Kami tidak peduli dengan dokumentasi, selama semuanya berfungsi... Jenis pelanggan tidak bertanggung jawab yang menghilang. Pandangan serupa tentang dokumentasi masih dapat ditemukan di antara pelanggan kecil dan miskin, serta dalam "idiotokrasi" otoriter yang tersisa dari perestroika, di mana bos dikelilingi oleh teman-teman setia - direktur, dan semua masalah diselesaikan dalam percakapan pribadi. Dalam kondisi seperti itu, Anda bebas untuk melupakan dokumentasi secara umum, tetapi lebih baik, jangan sampai merusak pandangan dan setidaknya secara skematis mengisi dokumentasi dengan konten. Jika bukan ke pelanggan ini, maka transfer (jual) ke pelanggan berikutnya.

Kesimpulan

Artikel ini tentang GOST kami untuk mendokumentasikan ACS. GOST memang sudah tua, tapi ternyata masih sangat berguna dalam rumah tangga. Terlepas dari beberapa dasar yang jelas, struktur dokumentasi memiliki sifat kelengkapan dan konsistensi, dan kepatuhan terhadap standar menghilangkan banyak risiko proyek, yang keberadaannya mungkin tidak kita duga.

Saya harap materi yang disajikan bermanfaat bagi Anda, atau setidaknya menarik. Terlepas dari kebosanan eksternal, mendokumentasikan adalah pekerjaan yang penting dan menuntut, di mana akurasi sama pentingnya dengan menulis kode yang baik. Tulis dokumen yang bagus, kolega! Dan minggu depan saya akan melakukan dua perjalanan bisnis berturut-turut, jadi saya tidak menjamin publikasi materi baru (saya tidak memiliki toko, saya menulis dari kepala saya).

27.10.2016 09:57:23

Artikel ini membahas tahapan proyek teknis, yang mengacu pada salah satu tahapan siklus hidup sistem keamanan informasi (ISS) - tahap "desain", yang, sesuai dengan standar domestik GOST 34.601-90, segera mengikuti perkembangan Kerangka Acuan untuk sistem keamanan informasi.

1. Pengembangan dokumentasi desain teknis untuk NIB

Siklus hidup sistem keamanan informasi (selanjutnya - NIB) umumnya terdiri dari tahapan berikut:

analisis persyaratan NIB;
rancangan;
penerapan;
penerapan;
eksploitasi.

Artikel ini membahas tahap desain teknis, yang termasuk dalam tahap "desain" dan, sesuai dengan standar domestik GOST 34.601-90, segera mengikuti perkembangan Kerangka Acuan untuk sistem keamanan informasi.

1.1. Mengapa mengembangkan dokumentasi untuk NIB sama sekali

Jawaban atas pertanyaan ini harus dipertimbangkan dalam dua bidang: di bidang pemilik sumber daya informasi (untuk perlindungan yang darinya ISS dibuat) dan di bidang pengembang langsung ISS.

Penting bagi pemilik sumber daya informasi untuk mendapatkan hasil berupa sistem keamanan informasi yang berfungsi mengurangi risiko kompromi informasi dengan akses terbatas di organisasi. Rancangan teknis dalam hal ini berfungsi untuk mengembangkan fondasi fundamental dari sistem masa depan, yaitu memuat uraian tentang bagaimana NIB akan dibangun dan dioperasikan, tindakan dan cara apa yang akan menjamin perlindungan informasi, apa saja kemungkinan untuk pengembangan dan perbaikan sistem. Setelah menyelesaikan pengembangan desain teknis untuk sistem keamanan informasi, Pelanggan menerima satu set dokumentasi lengkap untuk NIB, yang menjelaskan semua nuansa teknis dari sistem masa depan.

Untuk kontraktor langsung pada tahap proyek teknis, perlu untuk meletakkan arsitektur NIB yang paling sesuai, serta membuat pilihan tindakan dan cara yang tepat untuk melindungi informasi dalam organisasi. Penting juga untuk memastikan bahwa karakteristik dan properti sistem sesuai dengan spesifikasi teknis, atau membenarkan, dengan partisipasi dan persetujuan Pelanggan, penyesuaian persyaratan yang ditentukan dalam TOR untuk meningkatkan efisiensi sistem yang dibuat.

Dengan demikian, sebagai hasil dari pengembangan dokumentasi desain teknis, Pelanggan akan mendapatkan jawaban atas pertanyaan-pertanyaan berikut:

apa arsitektur umum NIB;
tindakan dan cara apa yang akan digunakan untuk menerapkan persyaratan perlindungan informasi;
bagaimana NIB akan berfungsi;
perubahan apa dalam organisasi, yang diperlukan untuk meningkatkan tingkat keamanan informasi, akan mengikuti sebagai hasil dari pengenalan SBI;
apakah persyaratan Pelanggan (persyaratan bisnis) dan persyaratan peraturan perundang-undangan di bidang keamanan informasi akan dipertimbangkan dalam pengembangan dan implementasi SBI dan, jika demikian, bagaimana caranya.

Kontraktor dalam proses pengembangan dokumentasi proyek teknis akan menerima hasil sebagai berikut:

dasar untuk transisi ke tahapan pembangunan NIB berikutnya, yaitu tahapan dokumentasi dan pelaksanaan kerja;
pemahaman tentang arsitektur, teknologi dan alat yang digunakan, tatanan bangunan sistem;
bagaimana persyaratan Pelanggan (persyaratan bisnis) dan dokumen peraturan di bidang keamanan informasi untuk sistem diimplementasikan.

1.2. Review pendekatan untuk pengembangan dokumentasi desain teknis

Pengembangan proyek teknis untuk sistem keamanan informasi paling sering dilakukan atas dasar standar dan pedoman yang relevan. Apalagi untuk instansi pemerintah, penggunaannya bersifat wajib, namun untuk komersial dianjurkan. Dalam praktiknya, organisasi komersial juga menggunakan standar negara saat mengembangkan dokumentasi desain teknis karena alasan berikut:

pendekatan berulang kali diuji untuk pembuatan sistem informasi;
struktur dan isi dokumen yang dipikirkan dengan matang;
satu set dokumen yang cukup untuk pengembangan dan deskripsi dari hampir semua sistem.

Untuk mengembangkan dokumentasi untuk tahap desain teknis (TP) di NIB, standar negara dan pedoman dari seri 34 digunakan:

GOST 34.201-89 "Jenis, kelengkapan, dan penunjukan dokumen saat membuat sistem otomatis." Standar ini menentukan:
- jenis dan nama dokumen pada tahap TP;
- kelengkapan dokumentasi;
- penunjukan dokumen yang diterima;
- aturan penunjukan NIB dan bagiannya.
GOST 34.003-90 "Istilah dan definisi";
GOST 34.601-90 “Sistem otomatis. Tahapan penciptaan ". Standar tersebut menentukan:
- daftar tahapan pekerjaan yang dilakukan pada tahapan TP;
- penjelasan rinci tentang pekerjaan yang dilakukan pada tahap TP;
- daftar organisasi yang terlibat dalam pembuatan NIB;
RD 50-34.698-90 “Sistem otomatis. Persyaratan untuk isi dokumen ". Dokumen panduan ini menetapkan persyaratan konten untuk dokumen tahap TP.

Penting untuk dipahami bahwa menurut standar seri 34, proyek teknis adalah tahap pembuatan sistem, dan bukan hanya kumpulan dokumen. Dalam praktiknya, tahap ini sering digabungkan dengan tahap desain konseptual, yang berfungsi untuk mengembangkan beberapa solusi awal dan menjustifikasi solusi yang paling sesuai. Kombinasi seperti itu diperbolehkan oleh standar, tetapi harus diingat bahwa hal ini tidak meniadakan kebutuhan untuk mewujudkan tujuan tahap desain draf.

Paling sering, tahap rancangan rancangan dikembangkan dalam kasus ketika persyaratan tugas teknis untuk sistem dapat diimplementasikan dalam beberapa cara yang berbeda secara fundamental, serta jika tidak ada metode yang disukai secara unik di antara metode-metode ini.

Namun, perlu dicatat bahwa standar di atas terlalu umum dan terutama menerapkan desain dan fungsi struktural umum. Untuk mengembangkan bagian substantif dokumen pada tahap desain teknis, desainer menggunakan informasi dari sumber berikut:

Dokumen normatif terkini (NLA) yang mengatur persyaratan untuk perlindungan informasi ini atau itu dengan akses terbatas. Undang-undang dan peraturan ini memberikan persyaratan untuk langkah-langkah untuk melindungi informasi dalam sistem informasi, menjelaskan nuansa pelaksanaan langkah-langkah ini dan langkah-langkah penguatan tambahan. Di antara tindakan hukum saat ini, yang dapat dibedakan adalah:

perintah FSTEC Rusia tertanggal 18 Februari 2013 No. 21 "Atas persetujuan komposisi dan isi dari tindakan organisasi dan teknis untuk memastikan keamanan data pribadi selama pemrosesan mereka dalam sistem informasi data pribadi";
perintah FSTEC Rusia tanggal 11 Februari 2013 No. 17 "Atas persetujuan persyaratan untuk perlindungan informasi yang bukan merupakan rahasia negara yang terkandung dalam sistem informasi negara"
perintah FSTEC Rusia tanggal 14 Maret 2014 No. 31 "Tentang persetujuan persyaratan untuk memastikan perlindungan informasi dalam sistem kontrol otomatis untuk produksi dan proses teknologi di fasilitas penting, fasilitas yang berpotensi berbahaya, serta fasilitas yang meningkatkan bahaya bagi kehidupan dan kesehatan manusia dan untuk lingkungan alam;
dokumen metodologi "Tindakan perlindungan informasi dalam sistem informasi negara", disetujui oleh FSTEC Rusia pada 11 Februari 2014

Persyaratan untuk perlindungan informasi yang dibatasi dan daftar tindakan perlindungan berbeda untuk IS pada tingkat / kelas keamanan yang berbeda. Jika informasi dalam organisasi bukan milik dilindungi sesuai dengan hukum federal Federasi Rusia (misalnya, rahasia resmi), maka pemilik informasi ini dapat menggunakan pendekatan yang diusulkan dalam data peraturan hukum untuk membangun NIB perusahaan.

Standar Rusia dan luar negeri yang menjelaskan berbagai pendekatan metode penerapan tahapan siklus hidup pembangunan NIB, termasuk tahap proyek teknis:

serangkaian standar negara GOST R ISO / IEC 2700X, identik dengan standar internasional ISO / IEC 2700X. Standar ini menjelaskan pendekatan proses PDCA (Plan, Do, Check, Act) untuk implementasi siklus hidup sistem manajemen keamanan informasi, yang merupakan bagian integral dari SBI;
NIST SP 800-64 adalah Institut Standar dan Teknologi Nasional AS yang menjelaskan siklus hidup pengembangan sistem informasi;
NIST SP 800-37 adalah Institut Standar dan Teknologi Nasional AS yang memberikan panduan tentang pengintegrasian manajemen risiko ke dalam siklus pengembangan sistem informasi.

Dokumentasi operasional pabrikan untuk keamanan informasi dan sarana tambahan. Dokumen-dokumen ini memuat informasi teknis yang lengkap tentang alat-alat yang digunakan dalam pembangunan NIB, termasuk yang terkait langsung dengan implementasi langkah-langkah IS yang tidak terkait, misalnya server, sistem penyimpanan, alat virtualisasi, dan lain-lain. Kumpulan umum dari dokumen semacam itu berbeda untuk pabrikan yang berbeda dan tergantung, antara lain, pada pelaksanaan alat tertentu (perangkat keras / lunak). Di bawah ini adalah seperangkat dokumentasi operasional standar untuk alat keamanan informasi yang digunakan untuk mengembangkan dokumen pada tahap desain teknis:

gambaran umum (lembar data);
panduan administrator (mungkin termasuk panduan manajemen lokal dan terpusat);
panduan pengguna;
panduan Pemasangan dan Penerapan Cepat (untuk ISS perangkat keras);
manual operator;
panduan Penerapan Infrastruktur Virtual (untuk perangkat lunak ISS);

Informasi umum tentang arsitektur ISS yang tersedia, praktik terbaik dalam hal membangun ISS, panduan tentang keamanan dan integrasi ISS satu sama lain, informasi tentang masalah dalam interaksi ISS tertentu. Contoh informasi tersebut dapat berupa dokumen-dokumen berikut:

panduan arsitektur keamanan informasi, misalnya: Defense-in-Depth, Cisco SAFE, Check Point SDP, dan lain-lain;
praktik terbaik dalam keamanan informasi, seperti yang tersedia dari tautan ini (https://www.sans.org/reading-room/whitepapers/bestprac/, http://csrc.nist.gov/publications/nistpubs/800-14 /800-14.pdf). Dokumen-dokumen ini paling sering disajikan dalam bahasa Inggris, namun, setiap produsen sistem keamanan informasi Rusia memiliki praktik terbaik mereka sendiri untuk menerapkan sarana perlindungan dan dapat menyediakannya berdasarkan permintaan;
panduan keamanan untuk keamanan informasi dan lingkungan operasional. Contohnya adalah bagian "Keamanan" di portal resmi Microsoft (https://technet.microsoft.com/ru-ru/library/dd637672.aspx).

1.3. Pengembangan desain teknis untuk NIB sesuai dengan GOST 34

Pengembangan dokumen pada tahap desain teknis di NIB paling sering dilakukan oleh integrator layanan ini dan diimplementasikan terutama sesuai dengan rencana berikut:

Penentuan daftar dokumen yang akan dikembangkan - informasi ini ditunjukkan dalam kerangka acuan untuk NIB. Dalam beberapa kasus, pengembang dokumen, dalam perjanjian dengan Pelanggan, dapat memperluas atau memperpendek daftar ini, jika kemungkinan hal ini disediakan di TK;

Pengembangan templat dokumen untuk tahap TP - struktur digunakan sesuai dengan RD 50-34.698-90 dan GOST 2.106 (untuk beberapa dokumen), eksekusi sesuai dengan GOST 2.105-95;

Pengembangan esensi dokumen. Persyaratan sistem ditetapkan dalam kerangka acuan untuk NIB. Sesuai dengan persyaratan ini, daftar tindakan teknis dan organisasi pelindung yang diperlukan untuk implementasi dalam sistem ditentukan. Tindakan perlindungan dapat didefinisikan dalam tindakan hukum regulasi yang relevan (tergantung pada jenis informasi yang dilindungi), standar perusahaan dan kebijakan keamanan informasi, serta berdasarkan adanya ancaman keamanan saat ini yang diidentifikasi pada tahap pengembangan model ancaman organisasi. Berdasarkan daftar langkah-langkah keamanan, pengembang NIB memilih sarana keamanan informasi yang sesuai dan mengembangkan struktur fungsional sistem keamanan informasi (subsistem, komponen). Lebih lanjut, dokumen desain teknis menjelaskan implementasi praktis tindakan perlindungan berdasarkan ISS yang dipilih atau tindakan organisasi dalam infrastruktur organisasi.

Koordinasi dokumentasi yang dikembangkan dan solusi yang disajikan di dalamnya dengan Pelanggan Sistem.

Saat mengembangkan dokumentasi untuk proyek teknis, paling sering tidak diperlukan untuk mengembangkan daftar lengkap dokumen yang ditentukan dalam GOST 34.201-89, karena standar ini sudah usang dan beberapa dokumen tidak memperhitungkan tren perkembangan dan teknologi sistem informasi modern. Kumpulan dokumen minimum yang diperlukan untuk menggambarkan sistem keamanan informasi adalah sebagai berikut:

lembar proyek teknis;
catatan penjelasan untuk proyek teknis;
diagram struktur fungsional;
diagram struktural kompleks sarana teknis;
struktur organisasi;
daftar produk yang dibeli.

Atas permintaan Pelanggan atau dalam hal NIB adalah sistem multikomponen yang kompleks, dokumen-dokumen berikut juga dapat dikembangkan sebagai tambahan:

skema otomatisasi;
deskripsi fungsi otomatis;
deskripsi dukungan informasi dari sistem;
deskripsi kompleks sarana teknis;
deskripsi perangkat lunak;
deskripsi struktur organisasi.

Perlu dicatat bahwa GOST 34.201-89 memungkinkan perluasan cakupan dokumen pada tahap TP, namun, dalam praktiknya, dokumen ini cukup berlimpah.

Lembar proyek teknis

Penunjukan: TP.

Dokumen ini dimaksudkan untuk mendeskripsikan daftar dokumen yang dikembangkan pada tahap desain teknis. Jumlah halaman dari masing-masing dokumen yang dikembangkan juga ditunjukkan.

Catatan penjelasan untuk proyek teknis

Sebutan: P2.

Dokumen ini adalah yang utama untuk tahap TP dan mencakup deskripsi arsitektur NIB, ukuran teknis dan organisasi, fungsi NIB, kompleks perangkat lunak dan perangkat keras, dan lain-lain. Menurut standar, ini terdiri dari empat bagian utama:

ketentuan umum;
uraian proses kegiatan;
solusi teknis dasar;
langkah-langkah untuk mempersiapkan objek otomatisasi untuk mengoperasikan sistem.

Diagram struktur fungsional

Penunjukan: C2.

Dokumen ini menjelaskan tentang struktur logis NIB, yaitu:

subsistem logis dan komponen yang merupakan bagian dari NIB;
fungsi yang diimplementasikan melalui subsistem dan komponen;
tautan informasional antara elemen logis dari ISB dan jenis pesan selama pertukaran.

Diagram struktural dari sarana teknis yang kompleks

Penunjukan: C1.

Dokumen ini mencakup deskripsi dari elemen NIB berikut:

sarana teknis sebagai bagian dari subsistem logis dan komponen NIB;
saluran komunikasi dan pertukaran antara sarana teknis dengan indikasi protokol transportasi.

Struktur organisasi

Penunjukan: С0.

Dokumen ini menjelaskan tentang struktur organisasi organisasi dalam hal pengelolaan NIB, yaitu:

subdivisi dan orang yang bertanggung jawab dari organisasi yang berpartisipasi dalam fungsi NIB;
fungsi yang dilakukan dan komunikasi antara departemen dan orang yang bertanggung jawab.

Daftar produk yang dibeli

Penunjukan: VP.

Dokumen ini mencakup daftar semua perangkat lunak dan perangkat keras, serta lisensi yang digunakan untuk membuat NIB. Dikembangkan sesuai dengan GOST 2.106.

Catatan. Perlu juga dicatat di sini bahwa dokumen panduan RD 50-34.698-90 memungkinkan penambahan dokumen apa pun dari tahapan TP (penyertaan bagian dan informasi selain yang diusulkan), penggabungan bagian, serta pengecualian beberapa bagian individual. Keputusan tentang hal ini dibuat oleh pengembang dokumen pada tahap TP dan didasarkan pada fitur NIB yang sedang dibuat.

1.4. Aturan pengembangan dokumentasi

kepatuhan struktural dengan standar pemerintah;
kepatuhan yang ketat dengan persyaratan spesifikasi teknis untuk sistem;
penerapan templat dokumen (penerapan gaya seragam, markup, margin, dll.);
pendekatan individu dan penggunaan simultan dari perkembangan yang ada saat mengisi bagian dokumen.

Catatan penjelasan untuk proyek teknis:

pengembangan dokumen dilakukan di lingkungan Microsoft Word, setelah selesainya pengembangan disarankan untuk kenyamanan mengkonversi dokumen ke format PDF;
istilah dan singkatan harus seragam di semua bagian dokumen;
dianjurkan untuk menghindari pengulangan eksplisit dan peningkatan volume dokumen yang tidak perlu;
solusi teknis harus dijelaskan sedetail mungkin, yang menunjukkan:
- arsitektur dan teknologi yang digunakan;
- tempat untuk menempatkan perangkat lunak dan perangkat keras dalam infrastruktur organisasi;
- alat keamanan informasi yang digunakan dengan deskripsi karakteristik, fungsi yang diterapkan, informasi sertifikasi;
- pengaturan dasar alat perlindungan informasi dalam hal mekanisme perlindungan, pengalamatan, perutean, interaksi dengan sistem dan alat yang berdekatan, dan lain-lain;
- kontrol, metode akses ke sana dan tempat pemasangannya;
- skema (struktural, fungsional, organisasi):
  - mengembangkan diagram di lingkungan Microsoft Visio;
  - setelah pengembangan, masukkan skema ke dalam dokumen menggunakan dialog "Tempel Khusus" dalam format EMF (Windows metafile);
  - mengembangkan sirkuit terpisah untuk sistem, subsistem dan komponen subsistem;
  - buat desain skema dengan tipe yang sama, menggunakan elemen, singkatan, ikon, gaya teks, dan hal lain yang sama.

1.5. Sumber daya untuk membantu Anda mengembangkan dokumentasi

Sejumlah besar informasi yang diposting di Internet, dengan satu atau lain cara, mampu membantu dalam pengembangan dokumentasi proyek teknis. Sumber daya utama disajikan pada tabel di bawah ini.

Meja. Sumber Daya Desain Rekayasa NIB

Jenis sumber daya	Informasi	Contoh sumber daya
Portal internet otoritas eksekutif federal	Dokumen peraturan, rekomendasi metodologis, register (termasuk sistem keamanan informasi bersertifikat), database (termasuk database kerentanan dan ancaman)	fstec.ru clsz.fsb.ru minutesvyaz.ru/ru/
Portal internet produsen keamanan informasi, distributor solusi keamanan informasi	Deskripsi solusi SI, dokumentasi operasional untuk SBI, bahan analitik dan artikel	securitycode.ru kaspersky.com/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html checkpoint.com altx-soft.ru
Sumber daya keamanan informasi khusus	Perbandingan solusi keamanan informasi, review artikel tentang solusi keamanan informasi, pengujian solusi keamanan informasi, informasi teknis mendalam tentang teknologi keamanan informasi	anti-malware.ru bis-expert.ru safe.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov itsecurity.com owasp.org sans.org

1.6. Contoh dokumen tahap desain teknis

Untuk memahami persyaratan konten dokumentasi tahap TP, contoh pengisian dokumen utama (bagian dokumen) disajikan di bawah ini.

1.6.1. Catatan penjelasan untuk proyek teknis

Catatan penjelasan adalah dokumen yang agak panjang, oleh karena itu, berikut adalah contoh isi bagian "Solusi teknis dasar" di bagian dari salah satu subsistem ISS - subsistem analisis keamanan.

Subsistem analisis keamanan NIB

Struktur dan komposisi subsistem

Subsistem analisis keamanan (PAZ) dimaksudkan untuk pemantauan sistematis status keamanan workstation otomatis (AWS) personel dan server organisasi. Dasar dari PAZ adalah software "Test" yang diproduksi oleh perusahaan "Information Security". Uji SZI memiliki sertifikat dari FSTEC Rusia untuk kepatuhan dengan spesifikasi teknis (TU) untuk keamanan informasi dan untuk tingkat kontrol ke-4 atas tidak adanya kemampuan yang tidak disebutkan.

PAZ mencakup komponen berikut:

uji Server manajemen server
uji konsol manajemen Konsol.

Komponen subsistem dijelaskan pada tabel di bawah ini.

Meja. Komponen ESD

Komponen	Deskripsi
Uji Server Manajemen Server	Menyediakan manajemen tugas pemindaian, melakukan fungsi pemantauan status keamanan workstation dan server organisasi. Parameter pemindaian ditetapkan oleh administrator IB di server manajemen Server Tes. Semua informasi yang dikumpulkan tentang hasil pemindaian disimpan di penyimpanan Test Server berdasarkan sistem manajemen database Microsoft SQL Server 2008
Konsol Uji	Memungkinkan administrator IB untuk terhubung ke Server Tes, melihat dan mengubah konfigurasinya, membuat dan mengubah tugas untuk pemindaian, melihat informasi tentang kemajuan tugas dan hasil pelaksanaannya. Konsol manajemen diinstal pada workstation administrator IS

Menyediakan fungsi

PAZ menyediakan fungsi-fungsi berikut:

implementasi perlindungan proaktif dari tempat kerja otomatis dan server perusahaan dengan memantau status keamanan informasi;
otomatisasi proses untuk memantau kepatuhan terhadap kebijakan internal dan standar keamanan tertentu;
pengurangan biaya untuk audit dan pengendalian keamanan, persiapan laporan status;
otomatisasi inventaris sumber daya, manajemen kerentanan, kepatuhan kebijakan keamanan, dan proses kontrol perubahan.

Solusi untuk seperangkat perangkat keras dan perangkat lunak

Daftar perangkat lunak dan perangkat keras ESD yang digunakan diberikan dalam tabel di bawah ini.

Meja. Perangkat lunak dan perangkat keras PAZ

Server kontrol PAZ

Sarana teknis

Server fisik yang digunakan sebagai server kontrol ESD harus memenuhi persyaratan teknis untuk perangkat lunak dan OS yang diinstal di dalamnya, seperti yang diberikan dalam tabel di bawah.

Meja. Persyaratan untuk OS dan perangkat lunak server kendali PAZ

Perangkat lunak	Persyaratan teknis
Perangkat lunak	CPU	RAM, MB
Microsoft Windows Server 2008 R2	3000 MHz, 4 core	8192
Microsoft SQL Server 2008 R2
Uji perangkat lunak Server

Perangkat lunak

OS server manajemen

OS Windows 2008 R2 diinstal di server manajemen dengan cara biasa dari kit distribusi yang dapat di-boot.

OS server manajemen dikelola secara lokal dari konsol dan melalui protokol RDP.

DBMS Server Manajemen

Pangkalan data Microsoft SQL Server 2008 R2 diinstal di bawah akun dengan hak administrator lokal menggunakan wizard penginstalan standar dari kit distribusi yang disediakan oleh pengembang produk.

Uji perangkat lunak Server

Perangkat lunak Test Server diinstal di server manajemen menggunakan wizard penginstalan standar.

Konfigurasi awal dan manajemen selanjutnya dari perangkat lunak Test Server dalam mode normal dilakukan menggunakan Test Console, yang diinstal pada workstation administrator IS.

Stasiun kerja administrator IS

Sarana teknis

Sebagai platform, AWS yang ada milik karyawan dari unit organisasi yang bertanggung jawab atas keamanan informasi digunakan, menjalankan OS dari keluarga Microsoft Windows.

Sarana teknis workstation administrator IS harus memiliki karakteristik konfigurasi perangkat keras berikut (setidaknya disarankan):

CPU 2 GHz;
RAM 4 GB;
HDD 80 GB.

Perangkat lunak

Uji perangkat lunak Konsol

Stasiun kerja administrator IS, tempat perangkat lunak Test Console diinstal, harus beroperasi di bawah salah satu sistem operasi berikut:

Microsoft Windows 7, 32-bit dan 64-bit;
Microsoft Windows 8 / 8.1, 32- dan 64-bit.

Selain itu, untuk pengoperasian yang benar dari perangkat lunak konsol manajemen Konsol Tes, Microsoft .NET Framework versi 3.5 SP1 atau lebih tinggi harus diinstal pada stasiun kerja administrator IS, dan pengaturan keamanan sistem operasi harus mengizinkan akses ke Server Tes.

Perangkat lunak Test Console diinstal di workstation administrator PAZ menggunakan wizard penginstalan perangkat lunak Test Server standar dengan opsi penginstalan Test Console yang dipilih dan pengaturan default lainnya.

Interaksi dengan sistem yang berdekatan

Untuk PAZ yang berdekatan adalah:

sarana subsistem firewall;
layanan direktori Active Directory
AWS dan server organisasi.

Untuk memastikan interaksi jaringan dengan sistem yang berdekatan dan langsung antara komponen ESD itu sendiri, jalur lalu lintas jaringan yang diperlukan harus diatur.

Untuk memastikan kemampuan menerima pembaruan pada basis pengetahuan dan modul perangkat lunak Uji untuk pemindai Server Tes, perlu menyediakan akses ke server pembaruan web Information Security LLC update.com melalui port 443 / tcp.

Saat memindai dalam mode PenTest, interaksi antara pemindai Server Tes dan workstation dan server organisasi dilakukan melalui protokol IP. Pemeriksaan Audit dan Kepatuhan menggunakan protokol kendali jarak jauh WMI, RPC, dan sebagainya. Untuk memindai host pada perangkat dengan fungsi firewall, Anda harus mengizinkan koneksi IP dari Server Uji ke host yang dipindai. Oleh karena itu, untuk Test Server, perlu untuk menyediakan akses ke port jaringan dari node yang dipindai menggunakan protokol remote control yang sesuai.

Karena ESD saat memindai dalam mode Audit dan Kepatuhan menggunakan protokol kendali jarak jauh untuk analisis, alat pemindaian perangkat lunak Uji harus diautentikasi dan disahkan pada node yang dipindai. Dalam ESD, untuk memindai node dalam mode Audit dan Kepatuhan di setiap jenis node (AWP, server, sistem aplikasi, DBMS, dll.), Akun dengan hak administratif digunakan.

Semua peristiwa keamanan informasi terdaftar disimpan di Microsoft SQL DBMS. Peristiwa ini dapat dikirim melalui konektor khusus ke subsistem pemantauan peristiwa keamanan informasi.

Operasi dan pemeliharaan PAZ

Pengguna subsistem

Operasi dan pemeliharaan fasilitas ESD dilakukan oleh karyawan organisasi dengan peran fungsional "administrator IS".

Administrator IS adalah spesialis yang tugasnya meliputi:

penentuan parameter pemindaian node organisasi;
menyiapkan dan meluncurkan tugas pemindaian;
analisis hasil pemindaian untuk mengetahui adanya kerentanan, kesalahan konfigurasi, atau ketidakpatuhan dengan standar teknis dalam sistem informasi;
pengendalian penghapusan kerentanan;
pembentukan standar dan persyaratan untuk memastikan keamanan workstation dan server organisasi.

Mode operasi sistem

Operasi normal

Dalam operasi normal, PAZ beroperasi 24 jam sehari, 7 hari seminggu.

Dalam mode operasi normal, administrator IS melakukan:

pemindaian node yang terjadwal dan tidak terjadwal;
menghasilkan laporan;
memperbarui basis pengetahuan dan modul perangkat lunak Tes.

Operasi darurat

Jika terjadi kerusakan sarana ESD, fungsi subsistem terganggu. Pelanggaran fungsionalitas peralatan keselamatan tidak mempengaruhi fungsi tempat kerja otomatis dan server organisasi.

1.6.2. Diagram struktur fungsional

Diagram fungsional dapat dikembangkan untuk keseluruhan NIB atau sebagiannya, misalnya subsistem atau komponen.

Contoh diagram fungsional umum dari NIB ditunjukkan pada gambar di bawah.

1.6.3. Diagram struktural dari sarana teknis yang kompleks

Diagram struktural kompleks sarana teknis dapat dikembangkan baik untuk seluruh NIB dan untuk bagian-bagiannya - subsistem dan komponen. Kelayakan sirkuit pengembangan untuk bagian NIB ditentukan oleh skala sistem dan detail yang diperlukan.

Contoh diagram struktural kompleks sarana teknis NIB ditunjukkan pada gambar di bawah ini.

Catatan penjelasan (PZ) adalah salah satu poin terpenting dari Proyek Teknis, yang berisi deskripsi lengkap dan karakteristik dari teknologi terpilih yang menentukan jenis dan desain sistem yang diteliti.

Catatan penjelasan diperlukan untuk mencerminkan informasi tentang objek, solusi teknis yang diadopsi dan justifikasinya.

Komposisi catatan penjelasan

Catatan penjelasan untuk proyek OKS apa pun berisi subbagian:

Pengantar. Bagian ini menunjukkan nama objek atau sistem, topik pengembangan dan daftar dokumen - dasar untuk memulai pekerjaan. Dokumentasi dasar disediakan di Pendahuluan:

Bagian ini juga mencakup:

Fungsionalitas, tujuan objek, operasi lebih lanjut. Bagian ini menjelaskan tujuan, sasaran dan ruang lingkup objek yang dikembangkan.
Spesifikasi. Ini adalah bagian terbesar dengan subbagian yang saling terkait. Bab ini meliputi:

Indikator teknis dan ekonomi - mencerminkan informasi tentang kapasitas desain ACS, signifikansinya bagi populasi, jumlah karyawan di masa depan, jumlah pekerjaan, dll.

Juga pada tahap ini, dimungkinkan untuk mengkarakterisasi program komputer yang digunakan dalam pengembangan proyek. Memberikan informasi tentang kemungkinan biaya pembongkaran bangunan dan bangunan, relokasi orang, relokasi komunikasi, bangunan, dll. (Jika perlu). Penjelasan dan pembenaran kemungkinan penerapan tahap demi tahap konstruksi suatu objek, menyoroti tahapan (jika perlu) dilakukan.

Bagian PP harus berisi konfirmasi dari organisasi desain bahwa semua dokumentasi telah dikembangkan dan dijalankan sesuai dengan dokumen:

Daftar referensi. Bagian ini berisi sumber, dokumen, artikel, buku, tautan yang disebutkan di bagian teks proyek.

Juga, catatan penjelasan berisi informasi tekstual tentang pembenaran solusi teknologi dan teknis yang diadopsi, indikator untuk rencana induk, transportasi internal dan eksternal, dll.

Bagian grafik dari PZ diwakili oleh gambar yang sesuai untuk persepsi yang lebih baik dari informasi teks yang ditulis sebelumnya. Sub-bagian ini mencakup tata letak umum umum dari area dengan jaringan komunikasi dan rekayasa transportasi, di mana objek yang diproyeksikan ditumpangkan; gambar detail dari objek desain itu sendiri (untuk fasilitas produksi, proses teknologi juga harus diterapkan); skema catu daya, catu panas, dll.

Perusahaan kami akan melaksanakan catatan penjelasan untuk proyek tersebut untuk pembangunan, perbaikan atau rekonstruksi fasilitas perumahan atau industri sesuai dengan norma dan persyaratan yang ditetapkan. Bantuan kami akan membantu Anda dengan masalah dan keterlambatan dalam mengkoordinasikan proyek dalam berbagai kasus dan akan memastikan penerimaan segera izin bangunan.

Tujuan utama dari Catatan Penjelasan adalah untuk memberikan informasi umum tentang sistem dan justifikasi untuk solusi teknis yang diadopsi dalam proses pengembangannya. Oleh karena itu, dasar untuk pengembangan Catatan Penjelasan terutama adalah Kerangka Acuan.

Catatan penjelasan adalah salah satu dokumen terpenting dari sebuah proyek teknis. Desain teknis dikembangkan untuk mengidentifikasi solusi teknis akhir yang memberikan gambaran lengkap tentang desain produk.
Saat mengembangkan program untuk membuat catatan penjelasan, disarankan untuk menggunakan GOST 19.404-79 “Catatan penjelasan. Persyaratan untuk konten dan desain ".

Untuk membuat catatan penjelasan untuk proyek teknis yang menjelaskan sistem otomatis (AS), disarankan untuk menggunakan RD standar 50-34.698-90 “Sistem otomatis. Persyaratan untuk isi dokumen ".

Banyak bagian dari dokumen di atas tumpang tindih, oleh karena itu, misalnya, kami akan mempertimbangkan dokumen Catatan Penjelasan, dibuat berdasarkan RD 50-34.698-90

1. Ketentuan Umum

1.1 Nama PLTN yang dirancang

Bagian dokumen Penjelasan ini berisi nama lengkap dan pendek AU.

Misalnya: “Dalam dokumen ini, sistem yang dibuat disebut Portal Informasi Perusahaan. Juga diperbolehkan menggunakan nama singkatan KIP atau Sistem. "

1.2 Dokumen yang menjadi dasar sistem dirancang

Di bagian dokumen ini, Catatan Penjelasan harus menyediakan tautan ke kontrak dan Kerangka Acuan untuk pengembangan sistem otomatis.

1.3 Organisasi yang terlibat dalam pengembangan sistem

Di bagian Catatan Penjelasan ini, nama pelanggan dan organisasi pengembang ditunjukkan.

1.4 Tujuan pembangunan AU

Di bagian dokumen ini, Catatan Penjelasan harus menunjukkan manfaat teknis, ekonomis, dan produksi yang akan diterima pelanggan setelah penerapan sistem yang dikembangkan.

Misalnya: “Tujuan dari sistem yang dibuat adalah:

optimalisasi alur kerja perusahaan;
dukungan budaya perusahaan perusahaan;
optimalisasi komunikasi antar karyawan perusahaan. "

1.5 Tujuan dan ruang lingkup AU yang dikembangkan

Bagian dokumen ini Catatan penjelasan harus mencakup deskripsi jenis aktivitas otomatis dan daftar proses untuk otomatisasi yang dimaksudkan sistem.

Contoh: “KIP dirancang untuk memberikan informasi yang lengkap dan operasional, serta pengorganisasian kerja karyawan yang efektif. Sistem harus memastikan organisasi kolaborasi antara karyawan menggunakan kemampuan berikut:

Pembuatan konferensi untuk membahas masalah;
Mengirim / Menerima pesan email;
Memastikan kerja bersama pada dokumen;
Persetujuan dokumen;
Menyimpan catatan dokumentasi masuk dan keluar. "

1.6 Informasi tentang dokumen normatif dan teknis yang digunakan dalam desain

Bagian ini harus menunjukkan standar yang digunakan untuk membuat Catatan Penjelasan.

Misalnya: “Selama desain, dokumen peraturan dan teknis berikut digunakan:

GOST 34.201-89 “Teknologi informasi. Set standar untuk sistem otomatis. Jenis, kelengkapan, dan penunjukan dokumen saat membuat sistem otomatis ";
GOST 34.602-89 “Teknologi informasi. Set standar untuk sistem otomatis. Kerangka acuan untuk pembuatan sistem otomatis ";
GOST 34.003-90 “Teknologi informasi. Set standar untuk sistem otomatis. Sistem otomatis. Istilah dan Definisi ";
GOST 34.601-90 “Teknologi informasi. Set standar untuk sistem otomatis. Sistem otomatis. Tahapan penciptaan ";
RD 50-682-89 Instruksi metodis. Teknologi Informasi. Satu set standar dan pedoman untuk sistem otomatis. Ketentuan Umum ";
RD 50-680-88 “Pedoman. Sistem otomatis. Ketentuan Dasar ";
RD 50-34.698-90 “Pedoman. Teknologi Informasi. Serangkaian standar dan pedoman untuk sistem otomatis. Sistem otomatis. Persyaratan untuk isi dokumen. "

1.7. Urutan pembuatan sistem

Untuk sistem yang dibuat dalam beberapa iterasi, Catatan Penjelasan harus menunjukkan jumlah pekerjaan untuk setiap iterasi. Secara terpisah, perlu menyoroti pekerjaan yang direncanakan untuk iterasi ini.

Misalnya: “Pelaksanaan proyek Portal Informasi Perusahaan direncanakan dalam dua tahap.

Tahap pertama instrumentasi mencakup pengorganisasian kerja bersama karyawan perusahaan melalui pengenalan peluang seperti:

Pesan singkat;
Organisasi konferensi;
Pengiriman / penerimaan email;
Persetujuan dokumen melalui Sistem. "

2 Deskripsi proses aktivitas

Bagian dari Catatan Penjelasan ini harus mencerminkan proses dan fungsi yang diotomatiskan oleh sistem dalam keseluruhan proses bisnis.

Untuk mengilustrasikan materi dalam catatan penjelasan, diperbolehkan menggunakan notasi UML, ARIS atau IDF0, serta gambar skematik yang dibuat menggunakan aplikasi standar (Visio).

Untuk memahami hubungan fungsi otomatis dengan fungsi non-otomatis dalam dokumen Catatan Penjelasan, perlu dibedakan secara jelas antara tindakan pengguna dan tindakan sistem.

Misalnya: “1. Pengguna menghasilkan dokumen

Pengguna memulai proses pengiriman dokumen untuk persetujuan
Sistem mengubah status dokumen menjadi "dalam persetujuan". "
Solusi teknis utama

2.1. Keputusan tentang struktur sistem dan subsistem.

Bagian Catatan Penjelasan ini memberikan solusi untuk struktur fungsional sistem dan subsistemnya.

2.2. Sarana dan metode interaksi antara komponen sistem. Interaksi dengan sistem eksternal

Di bagian dokumen Catatan Penjelasan ini, perlu untuk menunjukkan daftar sistem yang harus berinteraksi dengan produk yang dibuat. Saat menjelaskan interaksi komponen sistem dalam Catatan Penjelasan, perlu untuk menunjukkan format pertukaran data.

Misalnya: "Teknologi berikut digunakan dalam interaksi instrumentasi dengan sistem eksternal:
- "Akuntansi Perusahaan" - pertukaran file dalam format XML / Excel yang sudah mapan. "

2.3. Cara pengambilan keputusan operasi

Bagian dokumen Catatan Penjelasan ini mencakup daftar dan deskripsi mode operasi sistem. Mode berikut biasanya dibedakan: mode normal, mode operasi uji, mode layanan. Catatan penjelasan harus memberikan gambaran tentang rezim itu sendiri dan kasus-kasus di mana rezim itu diperkenalkan.

2.4. Keputusan tentang jumlah, kualifikasi dan fungsi personel instalasi

Bagian Catatan Penjelasan ini mengatur aktivitas personel pemeliharaan dan fungsional. Dalam catatan penjelasan, perlu untuk menunjukkan kategori karyawan yang termasuk dalam jenis personel ini atau itu dan menjelaskan fungsinya dalam kerangka sistem.

Misalnya: "Administrator portal bertanggung jawab untuk:

integritas database dan perangkat lunak;
tindakan pencegahan untuk memastikan keamanan data;
distribusi hak akses dan pendaftaran pengguna dalam sistem. "

2.5. Memastikan karakteristik konsumen dari sistem yang ditentukan dalam spesifikasi teknis

Bagian Catatan Penjelasan ini dibuat berdasarkan persyaratan kualitas produk yang ditentukan dalam kerangka acuan. Di sini perlu untuk mendeskripsikan parameter yang dengannya kualitas sistem ditentukan. Juga, catatan penjelasan menunjukkan solusi yang dengannya karakteristik ini dicapai dalam sistem.

Misalnya: "Toleransi kesalahan dan pengoperasian modul perangkat lunak instrumentasi dipastikan melalui penggunaan platform perangkat lunak industri IBM WebSphere Portal, Enterprise Oracle 10g."

2.6. Komposisi fungsi dan sekumpulan tugas yang diimplementasikan oleh sistem

Bagian dokumen ini Catatan penjelasan berisi daftar tugas yang diselesaikan oleh sistem. Dalam catatan penjelasan, fungsi dan kompleks tugas dapat direpresentasikan sebagai daftar tak bernomor.

2.7. Solusi untuk seperangkat sarana teknis, penempatannya di fasilitas

Bagian dokumen ini Catatan penjelasan berisi solusi tentang arsitektur teknis sistem dan persyaratan untuk seperangkat alat teknis yang diperlukan untuk memastikan fungsinya yang benar.

Direkomendasikan untuk menempatkan persyaratan seperangkat sarana teknis dalam catatan penjelasan dalam bentuk tabel.
Sebagai contoh: "

Peralatan	Spesifikasi teknis
Server Database
Versi pemasangan rak	Tidak lebih dari 4U
Arsitektur prosesor	RISC (64-bit)
Frekuensi CPU	tidak kurang dari 1,5 GHz
Cache prosesor	Setidaknya 1MB
Sistem operasi	Windows 2003 SP2
Kemungkinan jumlah prosesor yang terpasang	Tidak kurang dari 4
Jumlah prosesor yang dipasang
RAM yang memungkinkan	32 GB dengan ECC
Ukuran RAM	Minimal 8 GB
Ketersediaan antarmuka	10/100/1000 Base-T Ethernet antarmuka 2 pcs .; Ultra320 SCSI 2 buah; USB 4 buah; antarmuka serial 1 pc .; Slot ekspansi PCI 64-bit 6 pcs.
Kartu video:	Setidaknya 8MB.
Jumlah hard drive yang mungkin untuk dipasang	Tidak kurang dari 4
Jumlah disk yang terpasang
Pembaca
Sumber Daya listrik	Parameter masukan: 200-240 V, frekuensi arus: 50-60 Hz; daya input maksimum tidak lebih dari 1600 W; setidaknya 2 catu daya memberikan toleransi kesalahan.

Saat menjelaskan penempatan fasilitas kompleks sarana teknis dalam catatan penjelasan, perlu dipandu oleh persyaratan SNiP 11-2-80 untuk bangunan kategori "B".

2.8. Volume, komposisi, metode organisasi, urutan pemrosesan informasi

Dukungan informasi mencakup dukungan informasi di dalam mesin dan di luar mesin. Database (DB), dokumen input dan output yang berasal dari sistem eksternal bertindak sebagai pendukung informasi intramachine.

Basis informasi di luar mesin dibentuk oleh data yang terdapat dalam dokumen kertas. Seringkali, ketika mengembangkan sistem otomatis, hanya basis informasi dalam mesin yang digunakan, oleh karena itu penekanan utama dalam Catatan Penjelasan harus dibuat pada konten bagian ini.

Saat menjelaskan basis informasi dalam mesin dalam dokumen Catatan Penjelasan, penting untuk menunjukkan dokumen dan pesan masukan dan keluaran untuk semua subsistem dan sistem eksternal.

Contoh: “Informasi masukan untuk subsistem pengelolaan dokumen elektronik adalah:

versi elektronik dari dokumen alur kerja produksi;
tanda tangan digital elektronik;

Informasi keluaran untuk subsistem manajemen dokumen elektronik adalah:

mendokumentasikan log riwayat siklus hidup;
dokumen log riwayat persetujuan;
file versi elektronik dokumen dalam format RTF. "

2.9. Komposisi produk perangkat lunak, bahasa aktivitas, algoritme prosedur dan operasi, serta metode penerapannya

Di bagian dokumen ini, catatan penjelasan harus menyediakan teknologi dan alat untuk mengembangkan sistem.

Sebagai contoh:
«

Server Basis Data: Oracle 10g
Portal: Perpanjang Portal Websphere v6.0.
Pemodelan Bisnis: ARIS

3 Langkah-langkah untuk mempersiapkan objek otomasi untuk mengoperasikan sistem

Bagian Catatan Penjelasan ini menjelaskan aktivitas berikut:

langkah-langkah untuk membawa informasi ke dalam bentuk yang sesuai untuk diproses di komputer;
langkah-langkah untuk pelatihan dan pengujian kualifikasi personel;
langkah-langkah untuk menciptakan unit dan pekerjaan yang diperlukan;
tindakan untuk mengubah objek otomatisasi;
ukuran lain berdasarkan fitur khusus dari speaker yang dibuat

Contoh "Catatan penjelasan" (P2 oleh), dikembangkan untuk pengukuran otomatis dan sistem informasi untuk pengukuran komersial listrik (AIIS KUE) sesuai dengan, dan dokumen. oleh dan. Edisi 20.06.2018.

Catatan penjelasan (P2 sesuai dengan GOST 34.201-89) dari pengukuran otomatis dan sistem informasi untuk pengukuran komersial listrik (AIIS KUE) (contoh)

Dibuat pada 25.03.2014 11:48:18

Perhatian! Persyaratan teknis pasar listrik grosir (WEM), yang poin-poinnya dirujuk dalam contoh dokumen untuk pengukuran otomatis dan sistem informasi untuk meteran listrik komersial (AIIS KUE), cukup sering berubah, tetapi tidak oleh kami, tetapi oleh administrator sistem perdagangan (ATS). Mohon mengerti ini.

Semua dokumen tempur, yang telah lulus banyak, termasuk ujian di Federal State Unitary Enterprise "All-Russian Research Institute of Standardization and Certification in Mechanical Engineering" (VNIIMASH) dari ROSSTANDART, oleh karena itu, tidak ada keraguan.

Menerima gratis versi singkat dari apa pun dalam bentuk * .pdf, cukup klik pada halaman judul. Dokumen akan terbuka di browser dengan opsi untuk. Versi penuh dokumen dibayar, dapat diperoleh dalam format dengan jumlah tertentu menggunakan. Dokumen apa pun dapat diselesaikan untuk beberapa waktu untuk memenuhi persyaratan khusus pelanggan. Persyaratan sedang dibahas.