Contoh catatan penjelasan untuk kerangka acuan. Dokumentasi teknis

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

Apa itu standar dokumentasi?

Dalam 34 seri yang dimaksud, hanya ada 3 standar pendokumentasian utama:

Standar yang paling dicintai dan populer untuk pengembangan spesifikasi teknis. Satu-satunya hal yang tidak boleh Anda lupakan adalah bahwa itu terkait erat dengan standar lain dalam seri, dan jika Anda telah menerima spesifikasi teknis yang dibuat sesuai dengan standar ini, sangat disarankan 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 menyediakan daftar lengkap dokumentasi GOST 34, rekomendasi untuk pengkodean dokumen, tahap proyek apa yang dimiliki dokumen tersebut (tahapannya dijelaskan dalam GOST 34.601-90), dan juga bagaimana mereka dapat digabungkan dengan masing-masing lainnya.

Sebenarnya, standar ini adalah tabel beranotasi besar. Itu dapat didorong ke Excel untuk kemudahan penggunaan.

Sebuah standar tebal yang menggambarkan isi dokumen proyek dengan berbagai tingkat detail. GOST 34.201-89 yang disebutkan di atas digunakan sebagai indeks.

Ada banyak pertanyaan dan interpretasi ketentuannya terhadap standar RD 50-34.698-90, yang karena ambiguitasnya, sering 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, mulai secara tradisional dengan minus.

Kekurangan standar

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

• aplikasi dua tingkat, terdiri dari program klien dan server DBMS (tidak ada tiga atau lebih aplikasi "tingkat", tidak ada Weblogic atau JBoss)
• struktur tabel database, sedang dijelaskan, akan memberikan gambaran tentang model data logis (fakta bahwa antara aplikasi dan database mungkin ada beberapa Hibernate, maka tampaknya kelebihan yang buruk)
• antarmuka pengguna adalah satu jendela (bisakah berbeda? Dan apa itu "browser"?)
• Tidak banyak laporan di sistem, semuanya kertas dan dicetak di printer dot matrix
• Program yang dikembangkan difokuskan pada pemecahan "masalah pemrosesan informasi", yang memiliki input dan output 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 basis data memahami informasi apa yang ada di tabel dan secara aktif berpartisipasi dalam mengedit direktori sistem (apakah benar-benar ada satu server DBMS untuk 50 aplikasi berbeda?)

Dengan demikian, standar berisi artefak seperti berikut:

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

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

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 grafis sama sekali). Oleh karena itu, di sini juga perlu untuk mengoordinasikan bentuk-bentuk semua dokumen layar.

Sekarang kata-kata "gram mesin", "bingkai video", "ADCP" tidak memberi tahu kami apa pun. Saya juga tidak menemukannya digunakan, meskipun saya lulus dari lembaga khusus di tahun 90-an. Ini adalah waktu munculnya 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 tiba-tiba menuntut untuk memberinya satu set lengkap dokumentasi sesuai dengan GOST 34.201-89. Selain itu, formulasi serupa dalam TK mengembara dari satu kementerian ke kementerian lain dan telah menjadi semacam pola tak terucapkan di mana bagian substantif didorong.

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

Apa yang baik dalam standar?

Standar apa pun baik karena memungkinkan pelanggan dan kontraktor untuk berbicara dalam bahasa yang sama dan memberikan jaminan bahwa, setidaknya dalam hal bentuk, pelanggan tidak akan memiliki klaim "dalam bentuk" atas hasil yang dikirimkan.

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

Ketika 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 kontennya, komponen semantik. Karena, sekali lagi, jaminan kelengkapan informasi sangat berharga. Tidak peduli bagaimana kita memanjakan diri dengan profesionalisme tingkat tinggi, kita dapat lupa untuk memasukkan hal-hal dasar dalam persyaratan kita, sementara GOST 34.602-89 yang sama "mengingat" semuanya. Jika Anda tidak mengerti 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 analog Barat dari standar kami, di mana semuanya bisa lebih lengkap, lebih modern, dan lebih baik. Sayangnya, saya tidak akrab dengan mereka, karena belum ada satu pun kasus di mana GOST kami tidak akan cukup.

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

Cara membaca dan memahami standar dokumentasi seri GOST 34

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

Tahapan membuat sistem kontrol otomatis

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

• Rancangan desain (EDS)
• Desain teknis (TP)
• Perkembangan dari dokumentasi kerja(RD)

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

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

Dokumentasi kerja dirancang untuk penyebaran yang sukses, commissioning, dan operasi lebih lanjut sistem baru... Ini adalah dokumen yang berisi informasi yang 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 kontrol otomatis

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

Sistem otomatis dalam benak penyusun GOST adalah kombinasi perangkat keras, perangkat lunak, dan saluran komunikasi yang memproses informasi yang berasal dari sumber yang berbeda sesuai dengan algoritma tertentu dan memberikan hasil pemrosesan dalam bentuk dokumen, struktur data, atau tindakan kontrol. Model primitif dari robot paling sederhana.

Untuk sepenuhnya menggambarkan "otomat" ini, pemotongan berikut dibuat (seperti pada gambar):

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

Perangkat lunak tidak tahu apa-apa tentang prosesor atau database. Ini adalah area abstrak yang terpisah, tempat tinggal "kuda bulat dalam ruang hampa." Tetapi perangkat lunak ini sangat terkait erat dengan area subjek, alias Kehidupan nyata. Misalnya, algoritma kontrol untuk sistem kontrol lalu lintas jalan itu diperlukan untuk setuju dengan polisi lalu lintas sebelum mereka disetujui oleh pelanggan. Dan kemudian Anda mengerti mengapa mereka dipilih dalam 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 mereka tidak akan menandatangani apa pun. Di sisi lain, ketika mereka menandatangani, tidak akan ada pertanyaan di sisi teknis dari pertanyaan - mengapa mereka memilih itu, dan bukan papan atau lampu lalu lintas lainnya. Kebijaksanaan "leluhur" justru dimanifestasikan dalam kasus-kasus praktis seperti itu.

Dukungan informasi (IO)... Bagian lain dari sistem. Kali ini black box sistem kami dibuat transparan dan kami melihat informasi yang beredar di dalamnya. Bayangkan sebuah model sistem peredaran darah manusia, ketika semua organ lain tidak terlihat. Ini adalah sesuatu yang serupa dan ada dukungan Informasi. Ini menggambarkan komposisi dan rute perjalanan informasi 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 mereka). utama bagian deskriptif jatuh pada tahap TP, tetapi beberapa "dasar" mengalir ke tahap RD, seperti dokumen "Katalog Basis Data". Jelas bahwa sebelumnya berisi persis apa yang tertulis dalam judul. Tapi hari ini coba yang rumit sistem terintegrasi untuk membentuk dokumen seperti itu, ketika subsistem yang sangat sering dibeli dengan penyimpanan informasi misterius mereka sendiri 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 dulunya berisi nomor drum magnetik atau gulungan film. Dan sekarang apa yang harus dibawa ke sana?

Singkatnya, selama fase RD, dokumen Dukungan Informasi adalah dasar yang agak merusak, karena memang seharusnya demikian, tetapi tidak ada yang istimewa untuk diisi.

Perangkat lunak (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 akan, sama saja, ulangi.

Dalam dokumen ini, kita harus memberi tahu dengan perangkat lunak apa algoritma yang dijelaskan dalam IO dieksekusi, yang memproses informasi yang dijelaskan dalam IO. Artinya, tidak perlu menduplikasi informasi dari bagian lain di sini. Ini memberikan arsitektur sistem, alasan untuk teknologi perangkat lunak yang dipilih, deskripsinya (segala macam hal sistem: bahasa pemrograman, kerangka kerja, sistem operasi, dll.). Juga dalam dokumen ini kami menjelaskan bagaimana alat pemrosesan informasi diatur (antrean pesan, penyimpanan, alat pencadangan, solusi ketersediaan, semua jenis kumpulan aplikasi, dll.). Standar berisi deskripsi terperinci tentang konten dokumen ini, yang dapat dipahami oleh spesialis mana pun.

Dukungan teknis (TO)... Tidak kalah dicintai oleh semua orang, bagian dari dokumentasi proyek. Gambaran yang cerah hanya digelapkan oleh banyaknya dokumen yang perlu dikembangkan. Secara total, sesuai standar, dibutuhkan 22 dokumen yang harus dikembangkan, 9 di antaranya dalam tahap TP.

Faktanya adalah bahwa standar memberikan deskripsi segalanya dukungan teknis, termasuk perangkat keras dan jaringan komputer, sistem rekayasa dan bahkan bagian konstruksi (jika diperlukan). Dan ekonomi ini diatur oleh sejumlah besar standar dan peraturan, dikoordinasikan dalam organisasi yang berbeda dan oleh karena itu lebih mudah untuk membagi semuanya menjadi beberapa bagian dan mengoordinasikan (mengedit) menjadi beberapa bagian. Pada saat yang sama, standar memungkinkan Anda untuk menggabungkan beberapa dokumen satu sama lain, yang masuk akal untuk dilakukan jika seluruh tumpukan disetujui oleh satu orang.

Jangan lupa juga bahwa set standar kualitas menyiratkan akuntansi dan penyimpanan dokumen teknis, dan "buku" kami di pelanggan dapat tersebar di arsip yang berbeda, 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. Karena, rekan-rekan, dalam beberapa tahun terakhir, tren buruk telah digariskan pada proyek-proyek yang memerlukan klarifikasi di bagian khusus ini.

Pada tahap TP, bagian tersebut hanya berisi satu dokumen “ Deskripsi struktur organisasi", Di mana kita 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, dokumen lain yang lebih menarik muncul, yang ingin saya pertimbangkan secara terpisah.

Panduan pengguna... Komentar yang berlebihan, menurut saya.

Metodologi (teknologi) desain berbantuan komputer... Dalam dokumen ini, jika perlu, Anda dapat memasukkan deskripsi proses pembuatan perangkat lunak, kontrol versi, pengujian, dll. Tapi ini jika di TK pelanggan ingin merakit perangkat lunak secara pribadi. Jika dia tidak memerlukan ini (dan tidak membayarnya), maka seluruh dapur bagian dalam Anda bukan urusannya, dan dokumen ini tidak perlu dilakukan.

instruksi teknologi... Karena mode untuk memformalkan proses bisnis, pelanggan yang licik terkadang berusaha menjejalkan prosedur operasi ke dalam dokumen ini. Jadi, ini sama sekali tidak perlu.

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

Instruksi teknologi adalah lapisan antara OSD dan manual pengguna. RP menjelaskan secara rinci bagaimana Anda perlu melakukan tindakan tertentu dalam sistem. Instruksi teknologi mengatakan jenis apa tindakan harus dilakukan dalam kasus-kasus tertentu yang berkaitan dengan pengoperasian sistem. Secara kasar, instruksi teknologi Ini adalah ringkasan RP singkat untuk posisi atau peran tertentu. Jika pelanggan tidak memiliki peran yang ditentukan, atau dia ingin Anda menentukan sendiri peran dan persyaratan pekerjaan, sertakan peran paling dasar dalam dokumen, misalnya: operator, operator senior, administrator. Komentar pelanggan tentang topik "tetapi tidak demikian dengan kami" atau "tetapi kami tidak menyukainya" harus disertai dengan daftar peran dan deskripsi tanggung jawab pekerjaan. Karena proses bisnis kita jangan taruh... Kami adalah proses bisnis ini mengotomatisasikan.

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

Deskripsi proses teknologi pemrosesan data (termasuk teleprocessing)... Sebuah sisa menyedihkan dari zaman gua, ketika ada "Operator Komputer" yang ditunjuk khusus 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 dengan pasti. Lepaskan diri Anda. Yang terbaik adalah melupakan dokumen ini.

Solusi seluruh sistem (ATAU)... Standar menyediakan 17 dokumen dari bagian OP. Pertama, ini hampir semua dokumen dari tahap awal Rancangan Rancangan. Kedua, ini semua jenis perkiraan, perhitungan dan Deskripsi Singkat fungsi otomatis. Artinya, informasi untuk orang-orang bukan dari produksi TI utama, tetapi untuk personel tambahan - manajer, perkiraan biaya, spesialis pengadaan, ekonom, dll.

Dan ketiga, OR menyertakan dokumen besar yang disebut "Catatan Penjelasan untuk Proyek Teknis", yang, menurut gagasan, adalah semacam Ringkasan Eksekutif, tetapi pada kenyataannya, banyak desainer memasukkan semuanya ke dalamnya. konten yang bermanfaat tahap TP. Pendekatan radikal semacam itu terkadang dibenarkan dan bahkan saling menguntungkan baik bagi pelanggan maupun kontraktor, tetapi dalam kasus-kasus tertentu.

Varian menggunakan GOST 34

1. Kepatuhan penuh dan akurat terhadap standar... Secara alami, tidak ada yang secara sukarela akan menulis awan dokumen seperti itu. Oleh karena itu, satu set dokumen lengkap disiapkan hanya atas permintaan pelanggan yang mendesak, yang dia amankan di TK dan menghancurkannya dari atas dengan kesepakatan. Dalam hal ini, Anda perlu memahami semuanya secara harfiah dan memberikan "buku" fisik kepada pelanggan di mana nama-nama dokumen dari tabel 2 GOST 34.201-89 akan muncul, dengan pengecualian yang sama sekali tidak perlu, daftar yang Anda harus pasti membahas dan memperbaiki secara tertulis. Isi dokumen juga harus, tanpa imajinasi, sesuai dengan RD 50-34.698-90, sampai ke judul bagian. Agar otak pelanggan meledak, terkadang sistem besar dibagi menjadi subsistem, dan dokumentasi proyek terpisah dikeluarkan untuk setiap subsistem. Itu terlihat menakutkan dan tidak tunduk pada kontrol 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.
2. Kami sangat menyukai GOST... serius perusahaan besar standar cinta. Karena mereka membantu orang memahami satu sama lain dengan lebih baik. Jika pelanggan Anda terlihat menyukai ketertiban dan standarisasi, cobalah untuk mematuhi ideologi standar GOST saat mengembangkan dokumen, bahkan jika spesifikasi teknis tidak memerlukannya. Anda akan lebih dipahami dan disetujui oleh spesialis koordinator, dan Anda sendiri tidak akan lupa untuk memasukkan informasi penting dalam dokumentasi, Anda akan lebih melihat struktur target dokumen, lebih tepatnya merencanakan pekerjaan pada tulisan mereka dan menyelamatkan diri Anda dan kolega Anda banyak saraf dan uang.
3. Kami tidak peduli dengan dokumentasi, selama semuanya berfungsi.... Jenis pelanggan yang tidak bertanggung jawab menghilang. Pandangan serupa tentang dokumentasi masih dapat ditemukan di antara pelanggan kecil dan miskin, serta dalam "kebodohan" 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, sama saja, tidak merobohkan pandangan dan setidaknya secara skematis mengisi dokumentasi dengan konten. Jika tidak ke pelanggan ini, maka transfer (jual) ke yang berikutnya.

Kesimpulan

Artikel ini tentang standar GOST kami untuk mendokumentasikan ACS. GOST sudah tua, tetapi ternyata masih sangat berguna di 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 bahkan mungkin tidak kita duga pada awalnya.

Saya harap materi yang disajikan bermanfaat bagi Anda, atau setidaknya menarik. Terlepas dari kebosanan lahiriah, dokumentasi itu penting dan pekerjaan yang bertanggung jawab, di mana kerapian sama pentingnya dengan saat menulis kode yang baik. Tulis dokumen yang bagus, rekan! Dan minggu depan saya akan melakukan dua perjalanan bisnis berturut-turut, jadi saya tidak menjamin publikasi materi baru (saya tidak punya zagashnik, saya menulis dari kepala saya).

27.10.2016 09:57:23

Artikel ini membahas tahap desain teknis, yang mengacu pada salah satu tahap siklus hidup sistem keamanan informasi (ISS) - tahap "desain", yang, sesuai dengan standar nasional 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 - ISS) di pandangan umum terdiri dari langkah-langkah berikut:

• analisis persyaratan NIB;
• desain;
• 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 pengembangan Kerangka Acuan untuk sistem keamanan informasi.

1.1. Mengapa mengembangkan dokumentasi untuk NIB sama sekali

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

Penting bagi pemilik sumber daya informasi untuk mendapatkan hasil berupa sistem keamanan informasi yang berfungsi yang mengurangi risiko kompromi informasi dengan akses terbatas dalam organisasi. Proyek teknis di pada kasus ini berfungsi untuk mengembangkan fondasi fundamental dari sistem masa depan, yaitu, itu mencakup deskripsi tentang bagaimana NIB akan dibangun dan dioperasikan, langkah-langkah dan cara apa yang akan memastikan perlindungan informasi, apa kemungkinan untuk pengembangan dan peningkatan sistem . Setelah menyelesaikan pengembangan desain teknis untuk sistem keamanan informasi, Pelanggan menerima satu set dokumentasi lengkap untuk NIB, yang menjelaskan semua nuansa teknis sistem masa depan.

Untuk kontraktor langsung pada tahap proyek teknis, perlu untuk meletakkan arsitektur NIB yang paling sesuai, serta membuat pilihan tepat tindakan dan sarana untuk melindungi informasi dalam organisasi. Penting juga untuk memastikan bahwa karakteristik dan properti sistem cocok kerangka acuan, atau membuktikan, 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 memiliki 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, sebagai akibat dari penerapan ISS;
• apakah persyaratan Pelanggan (persyaratan bisnis) dan persyaratan tindakan hukum pengaturan di bidang keamanan informasi akan diperhitungkan dalam pengembangan dan implementasi ISS dan, jika demikian, bagaimana.

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

• dasar peralihan ke tahapan pembangunan NIB selanjutnya, yaitu tahapan dokumentasi kerja dan implementasi;
• pemahaman tentang arsitektur, teknologi dan alat yang digunakan, urutan pembangunan sistem;
• bagaimana persyaratan Pelanggan (persyaratan bisnis) dan dokumen peraturan di bidang keamanan informasi untuk sistem diimplementasikan.

1.2. Tinjauan pendekatan untuk pengembangan dokumentasi desain teknis

Pengembangan proyek teknis untuk sistem keamanan informasi paling sering dilakukan berdasarkan standar dan pedoman yang relevan. Dan untuk agensi pemerintahan penggunaannya adalah wajib, tetapi untuk tujuan komersial dianjurkan. Saat latihan organisasi komersial juga menggunakan standar negara dalam pengembangan dokumentasi desain teknis karena alasan berikut:

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

Untuk mengembangkan dokumentasi untuk tahap desain teknis (TP) pada NIB, standar negara dan pedoman dari 34 seri 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 bagian-bagiannya.
• GOST 34.003-90 "Syarat dan definisi";
• GOST 34.601-90 “Sistem otomatis. Tahapan penciptaan”. Standar menentukan:
  • daftar tahapan pekerjaan yang dilakukan pada tahapan TP;
  • Detil Deskripsi pekerjaan yang dilakukan pada tahap TP;
  • daftar organisasi yang berpartisipasi dalam pembuatan NIB;
• RD 50-34.698-90 “Sistem otomatis. Persyaratan 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 dikombinasikan dengan tahap desain konseptual, yang berfungsi untuk mengembangkan beberapa solusi awal dan membenarkan yang paling cocok. Kombinasi seperti itu diperbolehkan oleh standar, tetapi harus diingat bahwa ini tidak meniadakan kebutuhan untuk mengimplementasikan tujuan dari tahap rancangan rancangan.

Paling sering, tahap desain draf dikembangkan dalam kasus ketika persyaratan tugas teknis untuk sistem dapat diimplementasikan dalam beberapa cara yang berbeda secara mendasar, dan juga 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 dari dokumen pada tahap desain teknis, desainer menggunakan informasi dari sumber berikut:

Dokumen peraturan saat ini (NLA) yang mengatur persyaratan untuk perlindungan informasi ini atau itu dari akses terbatas. Undang-undang dan peraturan ini memberikan persyaratan untuk langkah-langkah untuk melindungi informasi di sistem Informasi, nuansa pelaksanaan langkah-langkah ini dan langkah-langkah penguatan tambahan dijelaskan. Di antara tindakan hukum saat ini, berikut ini dapat dibedakan:

• Perintah FSTEC Rusia tertanggal 18 Februari 2013 No. 21 "Atas persetujuan komposisi dan konten tindakan organisasi dan teknis untuk memastikan keamanan data pribadi selama pemrosesannya dalam sistem informasi data pribadi";
• Perintah FSTEC Rusia tertanggal 11 Februari 2013 No. 17 "Atas persetujuan persyaratan untuk perlindungan informasi yang bukan merupakan rahasia negara terkandung dalam sistem informasi negara”
• Perintah FSTEC Rusia tertanggal 14 Maret 2014 No. 31 "Atas persetujuan persyaratan untuk memastikan perlindungan informasi dalam sistem kontrol otomatis untuk produksi dan proses teknologi di fasilitas kritis, fasilitas yang berpotensi berbahaya, serta fasilitas yang menimbulkan bahaya yang meningkat terhadap kehidupan dan kesehatan manusia dan lingkungan alam;
• dokumen metodologis "Langkah-langkah perlindungan informasi dalam sistem informasi negara", disetujui oleh FSTEC Rusia pada 11 Februari 2014

Persyaratan untuk perlindungan informasi terbatas dan daftar tindakan perlindungan berbeda untuk IS dari berbagai tingkat / kelas keamanan. Jika informasi dalam organisasi bukan milik yang dilindungi sesuai dengan hukum federal RF (misalnya, rahasia dinas), maka pemilik informasi ini dapat menggunakan pendekatan yang diusulkan dalam data tindakan hukum untuk membangun NIB perusahaan.

Standar Rusia dan asing yang menjelaskan berbagai pendekatan untuk metode penerapan tahapan siklus hidup membangun NIB, termasuk tahapan proyek teknis:

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

Dokumentasi operasional pabrikan untuk alat dan bantu keamanan informasi. Dokumen-dokumen ini berisi informasi teknis yang komprehensif tentang alat-alat yang digunakan dalam pembangunan NIB, termasuk yang terkait langsung dengan penerapan langkah-langkah SI yang tidak terkait, misalnya, server, sistem penyimpanan, alat virtualisasi, dan lain-lain. Kumpulan umum dokumen tersebut berbeda untuk produsen yang berbeda dan tergantung, antara lain, pada pelaksanaan alat tertentu (perangkat keras / perangkat lunak). Di bawah ini adalah kumpulan standar dokumentasi operasional untuk alat keamanan informasi yang digunakan untuk pengembangan dokumen pada tahap desain teknis:

• deskripsi umum (lembar data);
• Panduan administrator (dapat mencakup 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 GIS);

Informasi umum tentang arsitektur ISS yang ada, praktik terbaik dalam membangun ISS, panduan tentang keamanan dan integrasi ISS satu sama lain, informasi tentang masalah dalam interaksi ISS tertentu. Contoh informasi tersebut dapat berupa 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 di bahasa Inggris, namun, setiap orang memiliki praktik terbaiknya sendiri untuk menerapkan perlindungan. Pabrikan Rusia SZI dan atas permintaan mereka dapat disediakan;
• panduan keamanan untuk ISS 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 kesepakatan dengan Pelanggan, dapat memperluas atau mempersingkat daftar ini, jika kemungkinan ini diatur dalam TK;

Pengembangan templat untuk dokumen 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 bagian substantif dari dokumen. Persyaratan sistem diatur dalam kerangka acuan untuk NIB. Sesuai dengan persyaratan ini, daftar teknis pelindung dan langkah-langkah organisasi diperlukan untuk implementasi dalam sistem. Tindakan perlindungan dapat didefinisikan dalam tindakan hukum peraturan yang relevan (tergantung pada jenis informasi yang dilindungi), standar perusahaan dan kebijakan keamanan informasi, serta berdasarkan keberadaan 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 dalam dokumen proyek teknis, implementasi praktis tindakan perlindungan berdasarkan keamanan informasi yang dipilih atau tindakan organisasi dalam infrastruktur organisasi dijelaskan.

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 pengembangan dan teknologi modern. sistem Informasi. 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 struktur kompleks sarana teknis;
• struktur organisasi;
• daftar produk yang dibeli.

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

• skema otomatisasi;
• deskripsi fungsi otomatis;
• deskripsi dukungan informasi sistem;
• deskripsi kompleks sarana teknis;
• keterangan perangkat lunak;
• penjelasan tentang struktur organisasi.

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

Lembar proyek teknis

Sebutan: TP.

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

Catatan penjelasan untuk proyek teknis

Penunjukan: P2.

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

• ketentuan umum;
• deskripsi proses kegiatan;
• solusi teknis dasar;
• langkah-langkah untuk mempersiapkan objek otomatisasi untuk menempatkan sistem ke dalam operasi.

diagram struktur fungsional

Penunjukan: C2.

Dokumen ini menjelaskan struktur logis NIB, yaitu:

• subsistem dan komponen logis yang membentuk NIB;
• fungsi yang dilaksanakan melalui subsistem dan komponen;
• link informasi antara elemen logis dari ISB dan jenis pesan selama pertukaran.

Diagram struktural dari kompleks sarana teknis

Penunjukan: C1.

Dokumen ini mencakup deskripsi elemen NIB berikut:

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

Struktur organisasi

Penunjukan: 0.

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

• divisi dan orang yang bertanggung jawab 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 tahap TP (penyertaan bagian dan informasi selain yang diusulkan), penggabungan bagian, serta pengecualian beberapa bagian individu. Keputusan tentang ini dibuat oleh pengembang dokumen pada tahap TP dan didasarkan pada fitur NIB yang dibuat.

1.4. Aturan pengembangan dokumentasi

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

Catatan penjelasan untuk proyek teknis:

• pengembangan dokumen dilakukan di lingkungan Microsoft Word, setelah selesai pengembangan disarankan untuk mengubah dokumen menjadi format PDF;
• istilah dan singkatan harus seragam di semua bagian dokumen;
• disarankan untuk menghindari pengulangan yang jelas 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 karakteristiknya, 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 diagram ke dalam dokumen menggunakan dialog "Tempel Spesial" dalam format EMF (Windows metafile);
    • mengembangkan diagram 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 diposting di Internet, dengan satu atau lain cara, yang mampu membantu dalam pengembangan dokumentasi proyek teknis. Sumber daya utama disajikan dalam tabel di bawah ini.

Meja. Sumber Daya Desain Teknik NIB

Jenis sumber daya	Informasi	Contoh sumber daya
Portal internet otoritas eksekutif federal	Dokumen peraturan, rekomendasi metodologis, registry (termasuk sistem keamanan informasi bersertifikat), database (termasuk database kerentanan dan ancaman)	fstec.ru clsz.fsb.ru minsvyaz.ru/ru/
Portal internet produsen keamanan informasi, distributor solusi keamanan informasi	Deskripsi solusi IS, dokumentasi operasional untuk keamanan informasi, materi dan artikel analitis	kode keamanan.ru kaspersky.com/ drweb.ru/ ptsecurity.ru/ infowatch.ru/ infotecs.ru/ cisco.com/c/ru_ru/index.html pos pemeriksaan.com altx-soft.ru
Sumber daya keamanan informasi khusus	Perbandingan solusi keamanan informasi, ulasan artikel tentang solusi keamanan informasi, pengujian solusi keamanan informasi, informasi teknis mendalam tentang teknologi keamanan informasi	anti-malware.ru bis-expert.ru aman.cnews.ru securitylab.ru/ vulners.com/ csrc.nist.gov keamanan.com owasp.org sans.org

1.6. Contoh dokumen tahap proyek teknis

Untuk memahami persyaratan isi dokumentasi tahapan TP, berikut ini disajikan contoh pengisian dokumen utama (bagian dokumen).

1.6.1. Catatan penjelasan untuk proyek teknis

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

Subsistem analisis keamanan NIB

Struktur dan komposisi subsistem

Subsistem analisis keamanan (PAZ) dirancang untuk pemantauan sistematis status keamanan workstation otomatis (AWS) personel dan server organisasi. Dasar dari PAZ adalah perangkat lunak "Tes" yang diproduksi oleh perusahaan "Keamanan Informasi". SZI Test memiliki sertifikat dari FSTEC Rusia untuk kepatuhan dengan spesifikasi teknis (TU) untuk keamanan informasi dan untuk kontrol tingkat 4 dari tidak adanya kemampuan yang tidak diumumkan.

PAZ mencakup komponen-komponen berikut:

• Uji server manajemen Server
• Konsol Uji.

Komponen subsistem dijelaskan pada tabel di bawah ini.

Meja. komponen ESD

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

Menyediakan fungsi

PAZ menyediakan fungsi-fungsi berikut:

• penerapan perlindungan proaktif 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 kontrol keamanan, persiapan laporan status;
• otomatisasi inventaris sumber daya, manajemen kerentanan, kepatuhan kebijakan keamanan, dan proses kontrol perubahan.

Solusi untuk satu set 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 ini.

Meja. Persyaratan untuk OS dan perangkat lunak server kontrol PAZ

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

Perangkat lunak

OS server manajemen

OS Windows 2008 R2 diinstal pada server manajemen secara teratur dari kit distribusi yang dapat di-boot.

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

DBMS server manajemen

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

Uji perangkat lunak Server

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

Konfigurasi awal dan manajemen selanjutnya dari perangkat lunak Server Uji dalam mode normal dilakukan dengan menggunakan Konsol Uji yang diinstal pada stasiun kerja administrator IS.

Stasiun kerja administrator IS

Sarana teknis

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

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

• CPU 2GHz;
• RAM 4 GB;
• Hardisk 80GB.

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-bit dan 64-bit.

Selain itu, untuk pengoperasian yang benar dari perangkat lunak konsol kontrol konsol uji, 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 Uji.

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

Interaksi dengan sistem yang berdekatan

Untuk PAZ yang berdekatan adalah:

• sarana subsistem firewall;
• Layanan direktori Direktori Aktif
• AWS dan server organisasi.

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

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

Saat memindai dalam mode PenTest, interaksi antara pemindai Test Server dan workstation dan server organisasi dilakukan melalui protokol IP. Pemindaian 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 Server Uji, perlu untuk menyediakan akses ke port jaringan dari node yang dipindai menggunakan protokol kendali jarak jauh 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. Di 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 yang terdaftar disimpan dalam Microsoft SQL DBMS. Peristiwa ini dapat dikirim melalui konektor khusus ke subsistem pemantauan peristiwa keamanan informasi.

Pengoperasian dan pemeliharaan PAZ

Pengguna subsistem

Pengoperasian dan pemeliharaan fasilitas ESD dilakukan oleh karyawan organisasi dengan peran fungsional "administrator SI".

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 terhadap standar teknis dalam sistem informasi;
• kontrol 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 terjadwal dan tidak terjadwal;
• menghasilkan laporan;
• memperbarui basis pengetahuan dan modul perangkat lunak Uji.

Operasi darurat

Jika alat ESD tidak berfungsi, fungsi subsistem terganggu. Gangguan sistem keselamatan tidak mempengaruhi fungsi tempat kerja otomatis dan server organisasi.

1.6.2. diagram struktur fungsional

Diagram fungsional dapat dikembangkan untuk seluruh NIB atau untuk bagiannya, misalnya, subsistem atau komponen.

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

1.6.3. Diagram struktural dari kompleks sarana teknis

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

Contoh diagram struktur kompleks sarana teknis NIB disajikan pada gambar di bawah ini.

Catatan penjelasan (PZ) adalah salah satu poin terpenting dari Proyek Teknis, yang membawa deskripsi lengkap dan karakteristik teknologi yang dipilih yang menentukan jenis dan desain sistem yang sedang dipelajari.

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

Komposisi catatan penjelasan

Catatan penjelasan untuk proyek OKS apa pun berisi subbagian:

1. Pengantar. Bagian ini menunjukkan nama objek atau sistem, topik pengembangan dan daftar dokumen - dasar untuk memulai pekerjaan. Dokumentasi dasar yang diberikan dalam Pendahuluan:
dokumen tingkat tertentu (federal, departemen, regional), yang memungkinkan pengembangan proyek; keputusan instansi terkait; keputusan investor.

Bagian ini juga mencakup:

penugasan desain (jika proyek dikembangkan berdasarkan kontrak); dokumen yang menetapkan kepemilikan suatu objek konstruksi modal(jika dokumentasi proyek sedang dikembangkan untuk rekonstruksi atau perbaikan suatu objek); penelitian teknik dan laporan pengujian; rencana yang disetujui sebidang tanah, disisihkan untuk bangunan; dokumen untuk penggunaan sebidang tanah yang tidak berada di bawah pengaruh peraturan perencanaan kota, yang diterima dari otoritas federal, eksekutif atau lokal yang berwenang; kondisi teknis dan dokumen yang memungkinkan penyimpangan darinya; tindakan pemilik fasilitas tentang pembongkaran yang diperlukan dari beberapa struktur dari lokasi konstruksi; izin untuk menyimpang dari nilai batas objek konstruksi modal.
2. Fungsionalitas, tujuan objek, operasi lebih lanjut. V bagian ini tujuan, sasaran, dan ruang lingkup objek yang dikembangkan dicirikan.
3. Spesifikasi. Ini adalah bagian yang paling banyak, terdiri dari subbagian yang saling terkait. Bab ini mencakup:
data kebutuhan penyediaan fasilitas gas, air, bahan bakar dan listrik; informasi tentang kapasitas desain (untuk fasilitas industri); informasi tentang volume bahan baku, air, bahan bakar dan sumber daya energi yang dibutuhkan dan data penggunaannya (untuk fasilitas produksi); informasi tentang area yang disita (untuk penggunaan sementara atau permanen), pembenaran ukurannya, jika tidak diatur oleh norma; dalam kasus perampasan tanah untuk penggunaan sementara atau permanen - data tentang jumlah sumber daya material yang diperlukan untuk mengkompensasi kerugian pemiliknya; karakteristik kategori tanah yang dialokasikan untuk bangunan; tersedia khusus kondisi teknis(jika diperlukan).
4. Indikator teknis dan ekonomi - mencerminkan informasi tentang kapasitas desain ACS, signifikansinya bagi populasi, jumlah karyawan 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 struktur, relokasi orang, relokasi komunikasi, struktur, dll (jika perlu). Deskripsi dan pembenaran kemungkinan penerapan konstruksi objek tahap demi tahap, menyoroti tahapan (jika perlu) dilakukan.

Bagian PP tentu harus berisi konfirmasi organisasi desain fakta bahwa semua dokumentasi dikembangkan dan dilaksanakan sesuai dengan dokumen:

rencana tata kota sebidang tanah; tugas desain; peraturan tata kota; peraturan dan persyaratan teknis lainnya.
5. Bibliografi. Bagian ini berisi sumber, dokumen, artikel, buku, tautan yang ditunjukkan di bagian teks proyek.

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

Bagian grafis dari PP diwakili oleh gambar yang sesuai untuk persepsi yang lebih baik dari yang ditulis sebelumnya informasi teks... Subbagian ini mencakup rencana umum umum area dengan komunikasi transportasi dan jaringan teknik, di mana objek yang diproyeksikan ditumpangkan; gambar rinci dari objek desain itu sendiri (untuk fasilitas produksi, juga perlu diterapkan proses teknologi); catu daya, skema pasokan panas, dll.

Perusahaan kami akan melakukan catatan penjelasan untuk proyek untuk konstruksi, perombakan atau rekonstruksi perumahan atau nilai produksi sesuai dengan norma dan persyaratan yang telah ditetapkan. Bantuan kami akan membantu Anda dengan masalah dan keterlambatan dalam mengoordinasikan proyek dalam berbagai kasus dan akan memastikan penerimaan izin bangunan yang cepat.

Tujuan utama Catatan Penjelasan adalah untuk memberikan informasi Umum tentang sistem dan pembenaran 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 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 standar RD 50-34.698-90 “Sistem otomatis. Persyaratan 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 AU yang diproyeksikan

Bagian dari dokumen Catatan penjelasan ini berisi nama lengkap dan pendek AU.

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

1.2 Dokumen yang menjadi dasar perancangan sistem dilakukan

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 organisasi pelanggan dan pengembang ditunjukkan.

1.4 Tujuan desain AU

Di bagian dokumen ini, Catatan Penjelasan harus menunjukkan manfaat teknis, ekonomi, 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 oleh sistem.

Misalnya: "Instrumentasi dirancang untuk memberikan informasi yang lengkap dan operasional, serta organisasi yang efisien pekerjaan karyawan. Sistem harus memastikan organisasi kerja tim antara karyawan menggunakan kemampuan berikut:

• Pembuatan konferensi untuk membahas masalah;
• Mengirim / Menerima pesan email;
• Memastikan kerja sama pada dokumen;
• Persetujuan dokumen;
• Mencatat 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. Satu set 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 untuk menyoroti pekerjaan yang direncanakan untuk iterasi ini.

Misalnya: “Pelaksanaan proyek Perusahaan portal informasi direncanakan dalam dua tahap.

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

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

2 Deskripsi proses kegiatan

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

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

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

Misalnya: “1. Pengguna membuat 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 antar komponen sistem. Interkoneksi 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, format pertukaran data perlu ditunjukkan.

Misalnya: “Sebagai bagian dari interaksi instrumentasi dengan sistem eksternal, teknologi berikut digunakan:
- "Enterprise Accounting" - pertukaran file dalam format XML / Excel yang sudah ada. "

2.3. keputusan operasional

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

2.4. Keputusan tentang jumlah, kualifikasi, dan fungsi personel PLTN

Bagian dari dokumen Catatan penjelasan ini mengatur kegiatan pemeliharaan dan personel fungsional. Dalam catatan penjelasan, perlu untuk menunjukkan kategori karyawan yang termasuk dalam jenis personel ini atau itu dan menggambarkan fungsinya dalam kerangka sistem.

Misalnya: “Administrator portal bertanggung jawab untuk:

• database dan integritas 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 menggambarkan parameter yang menentukan kualitas sistem. Juga, catatan penjelasan menunjukkan solusi yang karakteristik yang diberikan telah tercapai dalam sistem.

Misalnya: "Toleransi dan kinerja kesalahan modul perangkat lunak Instrumentasi disediakan melalui penggunaan platform perangkat lunak industri IBM WebSphere Portal, Enterprise Oracle 10g."

2.6. Komposisi fungsi dan kompleks tugas yang diterapkan oleh sistem

Bagian dokumen Catatan penjelasan ini berisi daftar tugas yang diselesaikan sistem. Dalam catatan penjelasan, fungsi dan kompleks tugas dapat disajikan dalam bentuk daftar tak bernomor.

2.7. Solusi untuk satu set sarana teknis, penempatannya di fasilitas

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

Disarankan untuk menempatkan persyaratan perangkat teknis dalam catatan penjelasan dalam bentuk tabel.
Sebagai contoh: "

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

»

Saat menjelaskan penempatan objek 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 dukungan informasi intramesin.

Basis informasi out-of-machine dibentuk oleh data yang terkandung 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, perlu untuk menunjukkan dokumen dan pesan input dan output untuk semua subsistem dan sistem eksternal.

Misalnya: "Informasi masukan untuk subsistem manajemen dokumen elektronik adalah:

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

Informasi keluaran untuk subsistem pengelolaan dokumen elektronik adalah:

• log riwayat siklus hidup dokumen;
• log riwayat persetujuan dokumen;
• mengajukan versi elektronik dokumen dalam format RTF. "

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

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

Sebagai contoh:
«

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

»

3 Langkah-langkah untuk mempersiapkan objek otomatisasi untuk mengoperasikan sistem

Bagian Catatan Penjelasan ini menjelaskan kegiatan berikut:

• langkah-langkah untuk membawa informasi ke bentuk yang sesuai untuk diproses di komputer;
• langkah-langkah untuk melatih dan menguji kualifikasi personel;
• langkah-langkah untuk menciptakan unit dan pekerjaan yang diperlukan;
• langkah-langkah untuk mengubah objek otomatisasi;
• kegiatan lain yang berasal dari fitur khusus speaker yang dibuat

Contoh "Catatan penjelasan" (P2 oleh), dikembangkan untuk pengukuran otomatis dan sistem informasi untuk pengukuran listrik komersial (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 listrik komersial (AIIS KUE) (contoh)

Dibuat pada 25-03-2014 11:48:18

Perhatian! Persyaratan teknis pasar grosir listrik (WEM), tautan ke titik-titik yang terdapat dalam contoh dokumen untuk pengukuran otomatis dan sistem informasi untuk pengukuran listrik komersial (AIIS KUE), cukup sering berubah, tetapi bukan oleh kami, tetapi oleh administrator sistem perdagangan(ATC). Harap mengerti ini.

Semua dokumen tempur, yang telah lulus banyak, termasuk ujian di Perusahaan Kesatuan Negara Federal "Lembaga Penelitian Standardisasi dan Sertifikasi Teknik Mesin Seluruh Rusia" (VNIIMASH) dari ROSSTANDART, oleh karena itu, tidak ada keraguan.

Menerima Gratis versi singkatan apapun dalam bentuk *.pdf, klik saja pada halaman judul. Dokumen akan terbuka di browser dengan opsi untuk. Versi lengkap dokumen dibayar, mereka dapat diperoleh dalam format untuk jumlah tertentu dengan menggunakan. Dokumen apa pun dapat diselesaikan untuk beberapa waktu untuk memenuhi persyaratan spesifik pelanggan. Persyaratan sedang dibahas.