Kumpulan angka-angka disebut? Sistem bilangan

VE. Karpov

Dokumen ini berisi penjelasan singkat tentang standar ESPD, pengetahuan yang diperlukan bagi siswa untuk menyelesaikan kursus dan proyek yang berkaitan dengan pembuatan sistem perangkat lunak. Selain itu, dapat bermanfaat dalam hal meningkatkan kualitas dokumentasi perangkat lunak secara umum.

SPESIFIKASI TEKNIS (GOST 19.201-78)

1. Ketentuan Umum

TAHAP PERKEMBANGAN (GOST 19.102-77)

DESKRIPSI PROGRAM (GOST 19.402-78)

TEKS PROGRAM (GOST 19.401-78)

PROGRAM DAN METODOLOGI UJI (GOST 19.301-79)

PERSYARATAN DOKUMEN PERANGKAT LUNAK CETAK (GOST 19.106-78)

Standardisasi di bidang dokumentasi perangkat lunak

Bagaimana cara bergerak maju

Penyusunan dokumentasi perangkat lunak (PS) sesuai dengan standar negara yang ada

2. Ciri-ciri umum kondisi

2.3. Standar negara Federasi Rusia (GOST R)

2.4. Standar internasional ISO/IEC 12207: 01-08-1995

Mungkin tahap pekerjaan pemrograman yang paling tidak menyenangkan dan sulit adalah pembuatan dokumentasi program. Sayangnya, biasanya hal ini tidak diajarkan sama sekali, atau paling banter, mereka tidak memperhatikan kualitas dokumen yang diterima. Namun, penguasaan seni ini seringkali menjadi salah satu faktor terpenting yang menentukan kualitas seorang programmer.

Pertama, kemampuan membuat dokumentasi program menentukan tingkat profesional seorang programmer. Pelanggan tidak akan mempelajari seluk-beluk dan fitur program yang paling menakjubkan sekalipun. Pelanggan akan membaca dokumentasinya terlebih dahulu. Faktor psikologis juga berperan besar dalam hal ini. Secara khusus, bekas sekolah pemrograman Soviet (dan sekarang) dihargai di seluruh dunia. Pemrogram domestik modern tidak lagi dikutip. Kelasnya tidak sama. Saat ini, program tidak lagi ditulis, tetapi dikompilasi (dan ini adalah “dua perbedaan besar”). Jadi, paket dokumentasi perangkat lunak (selanjutnya disebut PD) yang dibuat dengan gaya “klasik” akan menciptakan kesan yang paling baik pada pelanggan atau perusahaan Anda. Terlebih lagi, jika penulis PD menghindari frasa seperti “klik pada scrollbar…”, “sekrup”, dll. Sayangnya, obrolan seperti jargon seperti itu biasanya menyembunyikan kurangnya pemikiran atau kekosongan total (penulis sangat terkesan dengan cerita salah satu kenalannya tentang “gamer” tertentu yang “mengobrol” dengan seseorang atau terlibat dalam “moderasi " Atau semacam itu.). Bahasa PD adalah bahasa birokratis yang sangat konservatif. Ia mempunyai daya tarik tersendiri. Setuju bahwa istilah hard disk drive, flat disk drive, manipulator genggam seperti “mouse” (atau “bun”, seperti yang tertulis di salah satu paket PD lama) terdengar sangat berbeda dari “sekrup” yang sesuai, “ gagal” dan cukup “mouse”. Ngomong-ngomong, banyak hal telah mencapai titik di mana, kata mereka, bahkan spesialisasi khusus telah muncul - penulis teknis, yaitu. seseorang yang tahu cara membuat dokumentasi perangkat lunak.

Kedua, paket PD yang dirancang dengan baik (lebih tepatnya, dibuat) akan menyelamatkan Anda dari banyak masalah. Secara khusus, Anda dapat menghilangkan pertanyaan mengganggu dan klaim tidak berdasar hanya dengan merujuk pengguna ke dokumentasi. Ini terutama berlaku untuk dokumen terpenting - Kerangka Acuan. Kami akan membicarakan hal ini di bawah, tetapi sekarang kami dapat mengingatkan Anda tentang tuntutan hukum bernilai jutaan dolar terhadap IBM. Gugatan ini diajukan oleh salah satu penerbit besar, yang tidak puas dengan kualitas VT dan perangkat lunaknya. IBM memenangkan kasus ini. Dan dia menang hanya karena dia menunjukkan Kerangka Acuan yang ditandatangani kedua belah pihak. Hal ini terjadi sudah lama sekali, pada tahun 70an, namun hal ini tidak mengubah inti permasalahan.

Satu hal lagi. Penting untuk membuat paket PD pertama. Ini akan cukup untuk membangun semua yang berikutnya berdasarkan itu, menggunakannya sebagai model atau templat. Tapi ini harus dilakukan dengan sangat efisien. Dengan santai. Sangat teliti.

Pertama, Anda perlu mempersenjatai diri dengan standar Gost. Gost mendefinisikan segalanya. Secara khusus, ini mencakup Sistem Terpadu Dokumentasi Program (USPD) yang menarik minat kami. Mungkin hal yang paling sulit adalah mendapatkan gost itu sendiri. Gost hanya boleh dalam bentuk cetakan asli. Mereka dijual (setidaknya demikian sebelumnya) di toko khusus. Secara khusus, untuk memperoleh standar di bidang dokumentasi, Anda dapat menghubungi organisasi berikut:

• IPK "Standar Penerbitan", Departemen distribusi teritorial NTD (toko "Standar"), 17961, Moskow, st. Donskaya, 8, telp. 236-50-34, 237-00-02, faks/telp. 236-34-48 (tentang gost dan gost r).
• VNIIKI Gosstandart Rusia (ruang baca), 103001, Moskow, Granatny per. no.4, telp. 290-50-94 (tentang standar internasional, asing dan dokumentasi ilmiah dan teknis lainnya).

Dan tidak ada kutipan atau sumber sekunder. Gost adalah hukumnya. Terlebih lagi, tidak ada internet (bayangkan pengadilan menjatuhkan hukuman menggunakan cetakan KUHP yang diunduh dari beberapa situs web). Jangan percaya siapa pun selain yang asli. Namun, penulis kemudian harus mengutip ESPD, sehingga melepaskan semua tanggung jawab.

Mari kita mulai dengan ketentuan umum tentang Sistem Terpadu Dokumentasi Program (yang juga didefinisikan dalam standar yang relevan dengan Gost 19.001-77).

Sistem dokumentasi program terpadu adalah seperangkat standar negara yang menetapkan aturan yang saling berhubungan untuk pengembangan, pelaksanaan dan sirkulasi program dan dokumentasi program.

Standar ESPD mendefinisikan ketentuan umum dan standar dasar, aturan pelaksanaan dokumentasi pengembangan, aturan pelaksanaan dokumentasi produksi, aturan pelaksanaan dokumentasi pendukung, aturan pelaksanaan dokumentasi operasional, aturan peredaran dokumentasi program dan standar lainnya. . ESPD meliputi:

• standar fundamental dan organisasional dan metodologis;
• standar yang menentukan bentuk dan isi dokumen program yang digunakan dalam pengolahan data;
• standar yang memastikan otomatisasi pengembangan dokumen program.

Secara umum, daftar dokumen ESPD sangat banyak. Secara khusus, ini mencakup GOST berikut:

• Gost 19.001-77 ESPD. Ketentuan umum.
• Gost 19.101-77 ESPD. Jenis program dan dokumen program (diterbitkan kembali pada bulan November 1987 dengan perubahan).
• Gost 19.102-77 ESPD. Tahapan pengembangan.
• Gost 19.103-77 ESPD. Penunjukan program dan dokumen program.
• Gost 19.104-78 ESPD. Prasasti dasar.
• Gost 19.105-78 ESPD. Persyaratan umum untuk dokumen program.
• Gost 19.106-78 ESPD. Persyaratan untuk dokumen program yang dicetak.
• Gost 19.201-78 ESPD. Tugas teknis. Persyaratan untuk konten dan desain.
• Gost 19.202-78 ESPD. Spesifikasi. Persyaratan untuk konten dan desain.
• Gost 19.301-79 ESPD. Program uji dan metodologi.
• Gost 19.401-78 ESPD. Teks program. Persyaratan untuk konten dan desain.
• Gost 19.402-78 ESPD. Deskripsi Program.
• Gost 19.404-79 ESPD. Catatan penjelasan. Persyaratan untuk konten dan desain.
• Gost 19.501-78 ESPD. Membentuk. Persyaratan untuk konten dan desain.
• Gost 19.502-78 ESPD. Deskripsi aplikasi. Persyaratan untuk konten dan desain.
• Gost 19.503-79 ESPD. Panduan Pemrogram Sistem. Persyaratan untuk konten dan desain.
• Gost 19.504-79 ESPD. Panduan Pemrogram.
• Gost 19.505-79 ESPD. Panduan operator.
• Gost 19.506-79 ESPD. Deskripsi bahasa.
• Gost 19.508-79 ESPD. Petunjuk Perawatan. Persyaratan untuk konten dan desain.
• Gost 19.604-78 ESPD. Aturan untuk melakukan perubahan pada dokumen program yang dieksekusi di media cetak.
• Gost 19.701-90 ESPD. Skema algoritma, program, data dan sistem. Konvensi dan aturan pelaksanaan.
• Gost 19.781-90. Perangkat lunak untuk sistem pemrosesan informasi.

Seperti yang Anda lihat, bagian utama dari kompleks ESPD dikembangkan pada tahun 70an dan 80an. Beberapa dari standar ini sudah ketinggalan jaman, dan ada beberapa kelemahannya. Pertama, standar ini tidak mencerminkan beberapa tren modern dalam desain program dan dokumentasi program, dan kedua, standar ini mengandung banyak duplikasi bagian dokumentasi program. Namun demikian, karena tidak ada yang lebih baik, kita harus fokus pada hal tersebut.

Jadi, standar ESPD menyederhanakan proses pendokumentasian sistem perangkat lunak. Namun, pertama, komposisi dokumen program yang diatur oleh standar ESPD sama sekali tidak “kaku” seperti yang terlihat: standar tersebut mengizinkan jenis tambahan untuk ditambahkan ke kumpulan dokumentasi untuk sistem perangkat lunak (PS), dan , kedua, berdasarkan kebutuhan pelanggan, beberapa perubahan dapat diterima baik dalam struktur maupun isi jenis PD yang ada. Selain itu, dapat dicatat bahwa standar ESPD (dan ini berlaku untuk semua standar lain di bidang PS - GOST 34, Standar Internasional ISO/IEC, dll.) bersifat nasihat. Faktanya adalah bahwa sesuai dengan Hukum Federasi Rusia “Tentang Standardisasi”, standar-standar ini menjadi wajib berdasarkan kontrak - yaitu. ketika mengacu pada mereka dalam kontrak untuk pengembangan (penyediaan) perangkat lunak.

Sebelum kita mulai mempertimbangkan aturan untuk menyusun dokumentasi perangkat lunak, perlu dibuat pernyataan berikut. Dianjurkan untuk mengawali setiap dokumen dengan beberapa pendahuluan. Pendahuluan berbicara secara umum. Tentang relevansi, kebutuhan, dll. Tujuan Pelaku di sini adalah untuk menunjukkan pentingnya dan perlunya melakukan pekerjaan ini. Permulaannya biasanya standar: “Berbagai sistem yang ada saat ini... ... membuka prospek nyata di...”, dll. Kutipan dari pidato-pidato berbagai tokoh biasanya disisipkan di sini (ini murni aspek psikologis): "... seperti yang dikatakan pada pleno, kongres, konferensi, dll.). Anda bisa mulai dengan fakta bahwa ".. . Saat ini, di era transformasi sosial-ekonomi yang mendasar...dll." Secara umum, hal utama di sini adalah jangan berlebihan.

Dan selanjutnya. Saat mendeskripsikan produknya, pengembang sering mengacaukan konsep komponen dan kompleks. Ini adalah jenis program yang berbeda. Komponen didefinisikan sebagai “suatu program yang dianggap sebagai satu kesatuan, menjalankan fungsi yang lengkap dan digunakan secara mandiri atau sebagai bagian dari suatu kompleks”, dan kompleks adalah “program yang terdiri dari dua atau lebih komponen dan (atau) kompleks yang melakukan tindakan yang saling terkait. fungsi, dan digunakan secara mandiri atau sebagai bagian dari kompleks lain."

Menurut Gost, standar ini (diterbitkan kembali pada bulan November 1987) menetapkan prosedur untuk membangun dan menyiapkan spesifikasi teknis untuk pengembangan program atau produk perangkat lunak untuk komputer, kompleks dan sistem, terlepas dari tujuan dan ruang lingkupnya.

Anda harus sangat berhati-hati dan berhati-hati saat membuatnya, karena... Seringkali spesifikasi teknis yang dirancang dengan terampil (dan kompeten) menentukan keberhasilan keseluruhan pekerjaan. Ini adalah spesifikasi teknis yang disepakati dengan Pelanggan, yang biasanya berusaha untuk memperkenalkan sebanyak mungkin persyaratan yang bertentangan dan berlebihan. Sebaliknya, tugas Pelaksana adalah membuat hidupnya lebih mudah. Namun setelah tanda tangan ditandatangani oleh kedua belah pihak, sudah terlambat untuk memutar ulang apa pun.

Kerangka acuan dibuat pada lembar format A4 dan/atau A3, biasanya tanpa mengisi kolom pada lembar tersebut. Nomor lembar (halaman) ditempatkan pada bagian atas lembar di atas teks.

Untuk melakukan perubahan dan penambahan latar belakang teknis pada tahap pengembangan selanjutnya suatu program atau produk perangkat lunak, tambahannya dirilis. Koordinasi dan persetujuan penambahan spesifikasi teknis dilakukan dengan cara yang sama seperti yang ditetapkan dalam spesifikasi teknis.

Kerangka acuan harus memuat bagian berikut:

• nama dan ruang lingkup penerapan;
• dasar pembangunan;
• tujuan pembangunan;
• persyaratan teknis untuk suatu program atau produk perangkat lunak;
• tahapan dan tahapan perkembangan;
• prosedur pengendalian dan penerimaan;
• aplikasi.

Tergantung pada karakteristik program atau produk perangkat lunak, dimungkinkan untuk memperjelas isi bagian, memperkenalkan bagian baru, atau menggabungkan bagian individual.

Dalam bab Nama dan ruang lingkup menunjukkan nama, uraian singkat tentang ruang lingkup penerapan program atau produk perangkat lunak dan objek di mana program atau produk perangkat lunak tersebut digunakan.

Dalam bab Dasar pembangunan harus ditunjukkan:

• dokumen yang menjadi dasar pelaksanaan pembangunan;
• organisasi yang menyetujui dokumen ini dan tanggal persetujuannya;
• nama dan (atau) lambang topik pengembangan.

Sehubungan dengan kekhususan proses pendidikan, dasarnya dapat berupa tugas desain mata kuliah, perintah dari institut tertanggal __.__. untuk N ___., kontrak __.__. untuk N___. , dan seterusnya.

Dalam bab Tujuan pembangunan Tujuan fungsional dan operasional dari program atau produk perangkat lunak harus ditunjukkan. Anda dapat membatasi diri Anda di sini pada satu atau dua frasa. Hal utama adalah mendefinisikan dengan jelas untuk apa program ini.

Misalnya: Program ini merupakan inti dari stasiun kerja otomatis (AWS) untuk pengembang sistem kontrol otomatis linier berkelanjutan (ACS), yang memungkinkan pengguna memecahkan masalah analisis model sederhana.

Bab Persyaratan teknis untuk suatu program atau produk perangkat lunak harus berisi subbagian berikut:

• persyaratan karakteristik fungsional;
• persyaratan keandalan;
• syarat Penggunaan;
• persyaratan komposisi dan parameter sarana teknis;
• persyaratan kompatibilitas informasi dan perangkat lunak;
• persyaratan pelabelan dan pengemasan;
• persyaratan pengangkutan dan penyimpanan;
• persyaratan khusus.

Dengan kata lain, di sinilah hal spesifik dimulai. Menjelaskan apa yang seharusnya dilakukan oleh program dan seperti apa tampilannya.

Persyaratan untuk karakteristik fungsional. Di sini persyaratan untuk komposisi fungsi yang dilakukan, organisasi data masukan dan keluaran, karakteristik waktu, dll.

Misalnya: Program harus memungkinkan ... untuk menghitung ... untuk membangun ... untuk membuat ...

Masukkan data: file teks dengan diberikan...

Data keluaran: informasi grafis dan teks - hasil analisis sistem...; file teks - laporan tentang ... diagnostik status sistem dan pesan tentang semua kesalahan yang terjadi.

Persyaratan keandalan. Persyaratan untuk memastikan pengoperasian yang andal harus ditentukan (memastikan pengoperasian yang stabil, memantau informasi masukan dan keluaran, waktu pemulihan setelah kegagalan, dll.).

Sulit untuk “menebak” sesuatu di sini. Skenario terbaiknya adalah program Anda hanya bekerja dengan data yang benar-benar benar. Biasanya Pelanggan tidak menyetujui hal ini, namun Anda bisa mencobanya.

Misalnya: Program harus bekerja dengan matriks insiden yang diperluas dari grafik yang dipelajari sesuai dengan algoritma operasi, menghasilkan pesan kesalahan ketika data awal salah ditentukan, dan mendukung mode interaktif dalam kemampuan yang diberikan kepada pengguna.

Syarat Penggunaan. Kondisi pengoperasian (suhu lingkungan, kelembaban relatif, dll. untuk jenis media penyimpanan tertentu) di mana karakteristik tertentu harus dipastikan, serta jenis layanan, jumlah dan kualifikasi personel yang diperlukan harus ditunjukkan.

Biasanya tidak ada kesulitan dalam hal ini. Sayangnya, klausul tentang profesionalisme pengguna oleh Pelanggan tersirat. Ini, tentu saja, merupakan alasan lain untuk mencari-cari kesalahan pada program Anda. Namun, di sini kita dapat membatasi diri pada frasa seperti “Kondisi pengoperasian program sama dengan kondisi pengoperasian PC IBM dan PC yang kompatibel”, “Program harus dirancang untuk pengguna non-profesional”. dan seterusnya.

Persyaratan komposisi dan parameter sarana teknis. Tunjukkan komposisi sarana teknis yang diperlukan dengan indikasi karakteristik teknisnya.

Hal utama di sini adalah jangan melupakan apa pun dan menyediakan segalanya, di satu sisi (jika tidak, mereka akan menyelinap ke dalam semacam IBM PC/XT dengan layar monokrom dan tanpa mouse), dan di sisi lain, tidak untuk berlebihan dengan peningkatan persyaratan, jika tidak, Pelanggan akan menemukan Kontraktor yang lebih fleksibel.

Misalnya: Anda harus memiliki PC yang kompatibel dengan IBM PC dengan adaptor grafis EGA (VGA). Ruang disk yang dibutuhkan minimal 600 KB, jumlah RAM kosong minimal 400 KB. Diinginkan untuk memiliki driver EMS dan manipulator tipe mouse.

Persyaratan untuk kompatibilitas informasi dan perangkat lunak. Fiturnya sama seperti pada paragraf sebelumnya. Di sini persyaratan struktur informasi pada input dan output serta metode solusi, kode sumber, dan bahasa pemrograman harus ditentukan. Bila perlu, perlindungan informasi dan program harus dipastikan.

Misalnya: Program harus bekerja secara mandiri di bawah OS MS DOS versi minimal 3.3. Bahasa pemrograman dasarnya adalah Turbo Pascal 6.0.

Persyaratan pelabelan dan pengemasan serta persyaratan transportasi dan penyimpanan cukup eksotik. Secara umum, hal ini menunjukkan persyaratan untuk pelabelan produk perangkat lunak, pilihan pengemasan dan metode. Dan persyaratan pengangkutan dan penyimpanan harus menunjukkan kondisi pengangkutan produk perangkat lunak, lokasi penyimpanan, kondisi penyimpanan, kondisi penyimpanan, periode penyimpanan dalam berbagai kondisi.

Persyaratan khusus adalah hal yang sangat penting. Lebih baik menghindarinya jika memungkinkan. Dan nyatakan segera.

Misalnya: Tidak ada persyaratan khusus untuk karakteristik waktu program. Tidak ada persyaratan khusus untuk karakteristik kapasitif program.

Indikator teknis dan ekonomi. Poin tersulit bagi seorang programmer ini tidak selalu ada. Hal ini diperlukan terutama ketika tujuan Anda adalah untuk membenarkan efektivitas dan pentingnya pekerjaan yang sedang dilakukan. Item ini biasanya bekerja dengan sangat baik untuk Pelanggan. Setidaknya, hal ini merupakan pembenaran terbaik untuk menentukan waktu dan besaran dana pembangunan.

Bagian ini harus menunjukkan: perkiraan efisiensi ekonomi, perkiraan kebutuhan tahunan (misalnya: perkiraan jumlah panggilan ke kompleks secara keseluruhan per tahun - 365 sesi kerja), keuntungan ekonomi dari pembangunan dibandingkan dengan sampel dalam dan luar negeri terbaik atau analog.

Selain itu, disarankan untuk memberikan definisi perkiraan biaya pengembangan program dan definisi kompleksitas pemrograman.

Tahapan dan tahapan perkembangan(hal ini akan dibahas lebih rinci di bawah) menetapkan tahapan pengembangan yang diperlukan, tahapan dan isi pekerjaan (daftar dokumen program yang harus dikembangkan, disepakati dan disetujui), serta, sebagai suatu peraturan, tenggat waktu pengembangan dan menentukan pelakunya.

Langkah-langkah standar dijelaskan di sini. Hal utama adalah menentukan waktunya dengan benar. Jika memungkinkan, cobalah untuk mendistribusikan tahapan secara merata pada tenggat waktu (dan jumlah). Ingatlah bahwa tidak semua proyek berhasil mencapai tahap akhir. Dan harus ada laporan untuk setiap tahap. Ingat juga bahwa proyek pekerjaan akan memakan waktu paling lama. Jika Anda gagal menyelesaikan dokumentasi tepat waktu, Pelanggan berhak untuk tidak menerima pekerjaan tersebut sama sekali dengan segala konsekuensi yang timbul.

Tahapan dan tahapan yang utama dan sangat diperlukan adalah kerangka acuan itu sendiri, desain awal, desain teknis dan kerja.

• Desain awal. Pada tahap ini struktur data masukan dan keluaran dikembangkan secara rinci, dan bentuk penyajiannya ditentukan. Gambaran umum tentang algoritma, algoritma itu sendiri, dan struktur program sedang dikembangkan. Rencana aksi untuk pengembangan dan implementasi program sedang dikembangkan.
• Proyek teknis. Berisi algoritma yang dikembangkan untuk memecahkan masalah serta metode untuk memantau informasi awal. Di sini, alat untuk memproses kesalahan dan mengeluarkan pesan diagnostik dikembangkan, formulir untuk menyajikan data awal dan konfigurasi peralatan teknis ditentukan.
• Draf kerja. Pada tahap ini dilakukan pemrograman dan debugging program, pengembangan dokumen program, program dan metode pengujian. Contoh pengujian dan debugging sedang disiapkan. Dokumentasi dan materi grafis telah diselesaikan. Biasanya ditentukan bahwa selama pengembangan program, dokumentasi berikut harus disiapkan:

• teks program;
• Deskripsi Program;
• program dan metodologi pengujian;
• deskripsi aplikasi;
• panduan pengguna.

Ini adalah persyaratan standar. Jika Pelanggan setuju bahwa tidak semua daftar ini dapat disajikan, berarti niatnya terhadap Anda dan produk Anda tidak serius.

Mungkin tidak ada materi grafis apa pun. Apalagi bila Anda tidak akan melaporkan hasil pekerjaan Anda. Tetapi untuk proyek yang serius, item ini diperlukan.

Misalnya: Selama pengembangan program, materi grafis berikut harus disiapkan:

• indikator teknis dan ekonomi;
• struktur program;
• format penyajian data masukan program;
• diagram algoritma umum (2 lembar);
• algoritma komputasi dasar;
• contoh cara kerja program.

Dalam bab Prosedur pengendalian dan penerimaan jenis pengujian dan persyaratan umum untuk penerimaan pekerjaan harus ditunjukkan. Jika memungkinkan, maka dalam paragraf ini tunjukkan bahwa “kontrol dan penerimaan pengembangan dilakukan dengan menggunakan peralatan yang disediakan oleh Pelanggan”, jika tidak, Anda mungkin diminta untuk membawa peralatan tersebut.

Misalnya: Kontrol dan penerimaan pengembangan dilakukan berdasarkan contoh pengujian dan debugging. Ini memeriksa pelaksanaan semua fungsi program.

DI DALAM Aplikasi Jika perlu, spesifikasi teknis disediakan oleh:

• daftar penelitian dan karya lain yang mendukung pengembangan;
• diagram algoritma, tabel, deskripsi, justifikasi, perhitungan dan dokumen lain yang dapat digunakan selama pengembangan;

• sumber pembangunan lainnya.

Standar ini mengatur tahapan pengembangan program, dokumentasi program, serta tahapan dan isi pekerjaan:

Tahapan pengembangan	Tahapan pekerjaan
Tugas teknis	Pembenaran atas perlunya mengembangkan program	Rumusan masalah. Koleksi bahan sumber. Seleksi dan pembenaran kriteria efektivitas dan kualitas program yang dikembangkan. Pembenaran perlunya pekerjaan penelitian.
	Pekerjaan penelitian	Menentukan struktur data masukan dan keluaran. Pemilihan awal metode pemecahan masalah. Justifikasi kelayakan penggunaan program yang dikembangkan sebelumnya. Penetapan persyaratan sarana teknis. Pembenaran atas kemungkinan mendasar pemecahan masalah.
	Pengembangan dan persetujuan spesifikasi teknis	Menentukan persyaratan program. Penyusunan studi kelayakan untuk pengembangan program. Penetapan tahapan, tahapan dan waktu pengembangan program serta dokumentasinya. Pilihan bahasa pemrograman. Penentuan kebutuhan penelitian pada tahap selanjutnya. Koordinasi dan persetujuan spesifikasi teknis.
Desain awal	Pengembangan desain awal	Pengembangan awal struktur data masukan dan keluaran. Klarifikasi metode untuk memecahkan masalah. Pengembangan gambaran umum algoritma untuk memecahkan masalah. Pengembangan studi kelayakan.
	Persetujuan desain awal	Koordinasi dan persetujuan desain awal
Proyek teknis	Pengembangan proyek teknis	Klarifikasi struktur data masukan dan keluaran. Pengembangan algoritma untuk memecahkan masalah. Menentukan bentuk penyajian data masukan dan keluaran. Pengertian semantik dan sintaksis bahasa. Pengembangan struktur program. Penentuan akhir konfigurasi perangkat keras.
	Persetujuan desain teknis	Penyusunan rencana aksi untuk pengembangan dan pelaksanaan program. Pengembangan catatan penjelasan. Koordinasi dan persetujuan desain teknis.
Draf kerja	Pengembangan program	Pemrograman dan debugging
	Pengembangan dokumentasi perangkat lunak	Pengembangan dokumen program sesuai dengan persyaratan Gost 19.101-77.
	Pengujian program	Pengembangan, koordinasi dan persetujuan program dan metodologi pengujian. Melakukan pengujian pendahuluan negara, antardepartemen, penerimaan dan jenis lainnya. Koreksi program dan dokumentasi program berdasarkan hasil pengujian.
Penerapan	Persiapan dan transmisi program	Persiapan dan transfer program dan dokumentasi perangkat lunak untuk pemeliharaan dan (atau) produksi. Pendaftaran dan persetujuan tindakan pengalihan program untuk pemeliharaan dan (atau) produksi. Transfer program ke dana algoritma dan program.

Catatan:

1. Diperbolehkan untuk mengecualikan pengembangan tahap kedua, dan dalam kasus yang dibenarkan secara teknis - tahap kedua dan ketiga. Kebutuhan tahapan ini ditunjukkan dalam spesifikasi teknis.
2. Diperbolehkan untuk menggabungkan, mengecualikan tahapan pekerjaan dan (atau) isinya, serta memperkenalkan tahapan pekerjaan lain sesuai kesepakatan dengan pelanggan.

Standar ini difokuskan untuk mendokumentasikan produk pengembangan yang dihasilkan.

Sebenarnya, ada dua dokumen berbeda, namun memiliki banyak kesamaan. Ini adalah DESKRIPSI UMUM (GOST 19.502-78) dan DESKRIPSI PROGRAM (GOST 19.402-78). Namun, karena sangat sulit untuk benar-benar membuat keduanya dengan kualitas tinggi, tanpa melakukan duplikasi yang hampir lengkap dan merobek-robeknya, maka cukup menerapkan satu dokumen “hibrida” yang lebih umum. Sebut saja "Deskripsi Program".

Faktanya, “Deskripsi Program” dalam isinya dapat dilengkapi dengan bagian dan paragraf yang diambil dari standar dokumen dan manual deskriptif lainnya: GOST 19.404-79 ESPD. Catatan penjelasan, GOST 19.503-79 ESPD. Panduan Pemrogram Sistem, GOST 19.504-79 ESPD. Panduan Pemrogram, GOST 19.505-79 ESPD. Panduan operator, dll. Secara khusus, dari Catatan Penjelasan Anda dapat mengambil diagram algoritma, gambaran umum algoritma dan (atau) fungsi program, serta alasan keputusan teknis dan teknis-ekonomi yang diambil.

Deskripsi program harus menyertakan bagian informasi - anotasi dan konten.

Bagian utama dokumen harus terdiri dari bagian pendahuluan dan bagian berikut:

• tujuan fungsional;
• deskripsi logika.
• kondisi penggunaan;
• komposisi dan fungsi.

Tergantung pada spesifikasi programnya, bagian tambahan mungkin diperkenalkan.

DI DALAM Bagian pengantar Dokumen tersebut memberikan informasi umum tentang program - nama lengkap, penunjukan, kemungkinan penerapannya, dll.

Misalnya: Program "Stasiun kerja otomatis untuk pengembang senjata self-propelled" dimaksudkan untuk... diimplementasikan pada.... Program ini mendukung...

Dalam bab Tujuan menunjukkan tujuan program dan memberikan gambaran umum tentang fungsi program, karakteristik utamanya, informasi tentang batasan yang dikenakan pada ruang lingkup program, dan juga menunjukkan jenis komputer dan perangkat elektronik yang digunakan selama pengoperasian.

Misalnya: Program ini dirancang untuk memecahkan masalah... Program ini mewakili inti dari stasiun kerja otomatis...

Pengguna mempunyai kesempatan untuk..., mengimplementasikan..., menjalankan..., menganalisis..., memperoleh hasil analisis dan pemrosesan..., membangun..., dll.

Dalam bab " Deskripsi logika" menunjukkan:

• uraian tentang struktur program dan bagian-bagian utamanya

(misalnya: Program ini mencakup hal-hal berikut:

• antarmuka pengguna,
• modul untuk menentukan jalur dalam grafik,
• modul perhitungan fungsi transfer,
• modul untuk membangun karakteristik amplitudo dan frekuensi fase,
• modul untuk membangun respons terhadap pengaruh polinomial,
• editor teks).

• uraian tentang fungsi komponen-komponen dan hubungan antar komponen;

Misalnya: Program ini terdiri dari enam modul: modul antarmuka; modul definisi...; modul perhitungan...; modul...dll..

Modul antarmuka dibangun pada dua jenis dialog: dialog tanya jawab dan dialog tipe menu. Modul antarmuka mengontrol...

Modul definisi... Ini adalah...

Modul perhitungan...dst.

• informasi tentang bahasa pemrograman;

Contoh : Program ditulis dalam bahasa ... menggunakan compiler ...

• uraian data masukan dan keluaran masing-masing komponen;

Misalnya: MASUKAN DATA. Data masukan untuk program ini adalah file teks yang menggambarkan matriks kejadian yang diperluas dari grafik sistem yang diteliti.

KELUARAN. Outputnya adalah:

• informasi grafis dan teks yang ditampilkan di layar (hasil analisis sistem);
• file dalam salah satu format grafik - salinan gambar karakteristik yang dibangun (respons frekuensi, respons fase, dll.);
• file teks - laporan penelitian yang dilakukan;
• diagnostik keadaan sistem dan pesan tentang semua kesalahan yang terjadi.

• deskripsi logika bagian-bagian komponen (jika perlu, deskripsi diagram program harus ditulis).

Saat mendeskripsikan logika program, tautan ke teks program diperlukan.

Dalam bab Komposisi dan fungsi menunjukkan uraian tentang susunan dan fungsi program serta metode yang digunakan untuk memecahkan masalah.

Dalam bab Kondisi penggunaan kondisi yang diperlukan untuk pelaksanaan program ditunjukkan (persyaratan sarana teknis yang diperlukan untuk program ini dan program lainnya, karakteristik umum informasi masukan dan keluaran, serta persyaratan dan ketentuan yang bersifat organisasi, teknis dan teknologi, dll. ).

Contoh: Program dioperasikan pada komputer pribadi (PC) jenis IBM PC/AT. Untuk bekerja dalam mode interaktif, tampilan layar, keyboard dan mouse digunakan. Untuk mendukung mode grafis, diperlukan adaptor EGA (VGA). Data masukan disimpan pada floppy dan/atau hard disk. Program ini berjalan di bawah OS...

Lampiran uraian dapat memuat bahan referensi (ilustrasi, tabel, grafik, contoh, dll.)

Dan jangan lupa untuk menunjukkan nama modul pemuatan, serta deskripsi keseluruhan prosedur

Memanggil dan mem-boot sistem

Persyaratan untuk mendesain teks program cukup sederhana dan wajar bagi seorang programmer yang kompeten. Hal utama yang harus dipandu saat membuat dokumen ini adalah teks program harus dapat dibaca.

Masih wajib untuk menyusun bagian informasi - anotasi dan isinya.

Bagian utama dokumen harus terdiri dari teks dari satu atau lebih bagian, yang diberi nama.

Teks setiap file program dimulai dengan “header”, yang menunjukkan:

• nama programnya,
• pengarang,
• tanggal pembuatan program,
• nomor versi,
• tanggal modifikasi terakhir.

Komentar diperlukan, serta kepatuhan ketat terhadap aturan indentasi. Ingat, bahkan ketidakmampuan untuk membuat dokumentasi perangkat lunak dapat dibenarkan. Tapi teks program jelek - tidak pernah. Referensi pada fakta bahwa teks ini dapat dimengerti oleh penulisnya sendiri tidak dianggap serius. Tidak ada salahnya memberikan teks program kepada orang lain untuk dibaca.

Di bawah ini adalah contoh teks program yang mudah dibaca (diambil dari situs web Nikolai Gekht, email: [dilindungi email], http://users.omskreg.ru/~geht)

/* Sumber Windows 98

Kode Sumber untuk Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # definisikan INSTALL = KERAS char make_prog_look_big; void main() ( while(!CRASHED) ( display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) ( make_50_megabyte_swapfile(); do_nothing_loop(); total_screw_up_HPFS_file_system(); search_and_destroy_the_rest_of_OS/2(); menonaktifkan_Netscape(); nonaktifkan_RealPlayer(); nonaktifkan_Corel_Products(); hang_system(); ) write_something(apa saja); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(masih_not_crashed) ( display_copyright_message(); do_nothing_loop(); pada dasarnya_run_windows_3.1(); do_nothing_loop (); do_nothing_loop(); ) ) if(detect_cache())disable_cache(); if(fast_cpu()) ( set_wait_states(lots); set_mouse(kecepatan, sangat_lambat); set_mouse(aksi, gelisah); set_mouse(reaksi, kadang-kadang ); ) /* printf("Selamat datang di Windows 3.11"); */ /* printf("Selamat datang di Windows 95"); */ printf("Selamat datang di Windows 98"); if(system_ok()) crash(to_dos_prompt ) else system_memory = open("a:\swp0001.swp", O_CREATE); while(sesuatu) ( sleep(5); get_user_input(); tidur(5); act_on_user_input(); tidur(5); ) buat_umum_perlindungan_kesalahan();

Dokumen ini berisi penjelasan tentang apa dan bagaimana yang perlu dilakukan untuk memastikan (dan meyakinkan Pelanggan) bahwa program bekerja dengan benar. Faktanya, dokumen ini sangat menentukan untuk tes penerimaan. Program dan metodologi pengujian yang dirancang dengan baik adalah kunci untuk menandatangani sertifikat penerimaan, mis. hal yang membuat Anda menghabiskan begitu banyak tenaga dan waktu.

Secara formal, GOST ini digunakan untuk mengembangkan dokumen perencanaan dan melakukan pekerjaan uji untuk menilai kesiapan dan kualitas sistem perangkat lunak. Dokumen tersebut memuat uraian tentang objek dan tujuan pengujian, persyaratan dokumentasi program dan perangkat lunak, sarana dan tata cara pengujian, serta uraian contoh pengujian.

Komponen-komponen dokumen ini dijelaskan lebih mudah dan jelas dalam bentuk contoh.

Benda uji

Contoh: Benda ujinya adalah program..., ditujukan untuk...

Tujuan pengujian

Contoh: Memeriksa keandalan program.

Persyaratan program

Contoh: Pengoperasian program tidak boleh mengakibatkan kegagalan (gangguan fatal pada sistem). Organisasi dialog harus memberikan perlindungan terhadap memasukkan data yang salah. Program ini harus memberikan diagnostik status sistem dan pesan tentang kesalahan apa pun yang terjadi... dll.

Persyaratan untuk dokumentasi perangkat lunak

Contoh: Isi dokumentasi perangkat lunak yang disajikan selama pengujian:

• deskripsi program (GOST 19.402-78);
• program dan metodologi pengujian (GOST 19.301-79);
• teks program (GOST 19.401-78).

Sarana dan prosedur pengujian

Contoh: Program beroperasi sesuai dengan kondisi pengoperasian sistem operasi MS DOS (versi tidak lebih rendah dari 3.0) pada PC seperti IBM PC/AT, serta pada PC yang kompatibel. Adaptor EGA (VGA) juga diperlukan untuk pengoperasian.

Prosedur pengetesan:

1. Program ini diluncurkan….
2. Terpilih...
3. Ditekan...
4. Dipilih secara berurutan...

Uji kasus

Contoh: Untuk pengujian, diusulkan ..., yang uraiannya terdapat dalam file ... Isi file pengujian dan hasil program diberikan dalam Lampiran 1.

Dan terakhir, mari kita lihat standar ESPD terbaru yang disebut

Standar ini menetapkan aturan untuk pelaksanaan dokumen program untuk komputer, kompleks dan sistem, terlepas dari tujuan dan ruang lingkup penerapannya dan disediakan oleh standar ESPD.

Ketentuan Umum. Penting untuk memasukkan setiap kata, rumus, simbol (dengan tangan dalam font gambar), huruf alfabet Latin dan Yunani, serta menggambar diagram dan gambar dalam dokumen program yang dibuat dengan mengetik, mesin dan tulisan tangan, dengan tinta hitam. atau tinta.

Kesalahan ketik dan ketidakakuratan grafis yang ditemukan selama proses eksekusi dapat diperbaiki dengan menghapus bagian teks (gambar) yang dieksekusi dengan buruk dan menerapkan teks (grafik) yang dikoreksi pada lembar yang sama dengan skrip ketikan atau tinta hitam, tergantung pada metode eksekusi. dokumen.

Kerusakan pada lembar dokumen, noda dan bekas teks (grafik) yang tidak terhapus seluruhnya tidak diperbolehkan.

Dokumen program dibuat pada lembar A4. Di samping itu:

• Dapat diterima untuk mencetak pada lembar A3;
• dengan metode mesin pelaksanaan dokumen, diperbolehkan adanya penyimpangan ukuran lembaran yang sesuai dengan format A4 dan A3, ditentukan oleh kemampuan sarana teknis yang digunakan; pada lembar format A4 dan A3, disediakan oleh karakteristik keluaran perangkat keluaran data, saat menghasilkan dokumen dengan mesin;
• Saat membuat dokumen menggunakan metode tipografi, dimungkinkan untuk menggunakan lembaran format tipografi.

Materi dokumen program disusun dengan urutan sebagai berikut:

• bagian judul:

• lembar persetujuan (tidak termasuk dalam jumlah lembar dokumen);
• halaman judul (halaman pertama dokumen);

• bagian informasi:

• anotasi;
• Daftar isi;

• bagian utama:

• teks dokumen (dengan gambar, tabel, dll.);
• daftar istilah dan definisinya;
• Daftar Singkatan;
• aplikasi;
• indeks subjek;
• daftar dokumen referensi;

• ubah bagian logging:

• ganti lembar registrasi.

Konstruksi dokumen. Jika perlu, diperbolehkan untuk membagi dokumen menjadi beberapa bagian. Pembagian menjadi beberapa bagian dilakukan pada tingkat tidak lebih rendah dari bagian. Setiap bagian diselesaikan secara terpisah, dan pada akhir isi bagian pertama harus dicantumkan nama-nama bagian yang tersisa.

Diperbolehkan untuk memasukkan bagian dokumen dari teks program, yang diformat sesuai dengan aturan bahasa di mana teks program ditulis.

Abstrak ditempatkan pada halaman (halaman) tersendiri, diberi judul “ABSTRAK”, diberi nomor dan dicantumkan dalam isi dokumen.

Teks setiap dokumen, bila perlu, dibagi menjadi paragraf, dan paragraf menjadi subparagraf, terlepas dari apakah dokumen tersebut dibagi menjadi beberapa bagian, bagian, dan subbagian atau tidak.

Judul bagian ditulis dengan huruf kapital dan ditempatkan secara simetris terhadap batas kanan dan kiri teks. Judul subbagian ditulis dari paragraf dengan huruf kecil (kecuali huruf kapital pertama). Tanda hubung kata dalam judul tidak diperbolehkan. Tidak ada titik di akhir judul. Disarankan untuk memulai setiap bagian pada lembar baru.

Bagian, subbagian, paragraf, dan subparagraf diberi nomor dengan angka Arab dan diberi titik. Bagian harus memiliki nomor seri (1, 2, dst.)

Teks dokumen. Teks dokumen harus singkat, jelas, tidak termasuk kemungkinan salah tafsir. Istilah dan definisi harus seragam dan mematuhi standar yang ditetapkan, dan jika tidak ada, harus diterima secara umum dalam literatur ilmiah dan teknis, dan diberikan dalam daftar istilah.

Penjelasan yang diperlukan terhadap teks dokumen dapat diberikan dalam catatan kaki. Catatan kaki ditandai dengan angka dengan tanda kurung ditempatkan setinggi tepi atas font.

Jika catatan kaki merujuk pada satu kata, maka tanda catatan kaki diletakkan tepat di sebelah kata tersebut, tetapi jika merujuk pada kalimat secara keseluruhan, maka di akhir kalimat. Teks catatan kaki diletakkan di akhir halaman dan dipisahkan dari teks utama dengan garis sepanjang 3 cm yang ditarik di sisi kiri halaman.

Ilustrasi. Ilustrasi dapat ditemukan di teks dokumen dan (atau) di lampiran. Ilustrasi, jika terdapat lebih dari satu ilustrasi dalam suatu dokumen, diberi nomor dengan angka Arab di seluruh dokumen.

Dalam lampiran, ilustrasi diberi nomor dalam setiap lampiran sesuai urutan yang ditetapkan untuk teks utama dokumen. Referensi ilustrasi diberikan berdasarkan jenis: “Gbr. 12” atau “(Gbr. 12)”. Ilustrasi boleh mempunyai judul tematik dan teks keterangan yang menjelaskan isi ilustrasi.

Rumus. Rumus-rumus dalam suatu dokumen, apabila jumlahnya lebih dari satu, diberi nomor dengan angka Arab, nomor tersebut diletakkan di sebelah kanan halaman, dalam tanda kurung pada tingkat rumus. Dalam keseluruhan dokumen atau bagian-bagiannya, jika dokumen itu dibagi menjadi beberapa bagian, rumusnya mempunyai penomoran yang berkesinambungan.

Referensi dalam teks untuk nomor urut rumus diberikan dalam tanda kurung, misalnya: “dalam rumus (3)”. Saat membagi dokumen menjadi beberapa bagian, nomor bagian ditempatkan sebelum nomor urut rumus dan dipisahkan dari titik terakhir, misalnya: “pada rumus (1.4)”.

Arti simbol-simbol yang terdapat dalam rumus harus diberikan tepat di bawah rumus. Arti setiap karakter dicetak pada baris baru sesuai urutan yang diberikan dalam rumus. Baris pertama transkrip harus dimulai dengan kata "di mana", tanpa titik dua setelahnya.

Tautan. Referensi terhadap standar dan dokumen lain diperbolehkan dalam dokumen kebijakan. Referensi harus dibuat pada dokumen secara keseluruhan atau pada bagian-bagiannya (menunjukkan penunjukan dan nama dokumen, nomor dan nama bagian atau lampiran).

Diperbolehkan untuk menunjukkan hanya penunjukan dokumen dan (atau) bagian tanpa menyebutkan namanya. Referensi ke masing-masing subbagian, paragraf, dan ilustrasi dokumen lain tidak diperbolehkan. Tautan dalam dokumen ke paragraf, ilustrasi, dan subbagian individual diperbolehkan.

Catatan Catatan pada teks dan tabel hanya menunjukkan data referensi dan penjelasan. Satu not tidak diberi nomor. Setelah kata "Catatan" beri titik. Beberapa not harus diberi nomor secara berurutan menggunakan angka Arab dengan titik. Setelah kata "Catatan" beri tanda titik dua. Teks catatan hanya dapat dicetak pada satu interval.

Singkatan. Singkatan kata dalam teks dan tulisan di bawah ilustrasi tidak diperbolehkan, kecuali:

• singkatan yang ditetapkan dalam GOST 2.316-68 dan diterima secara umum dalam bahasa Rusia;
• singkatan yang digunakan untuk menunjukkan program, bagian-bagiannya dan mode pengoperasiannya, dalam bahasa kontrol tugas, dalam alat konfigurasi program, dll., dilambangkan dengan huruf alfabet Latin.

Aplikasi. Materi ilustrasi, tabel atau teks pendukung dapat disajikan dalam bentuk lampiran. Lampiran dibuat sebagai kelanjutan dari dokumen ini pada halaman berikutnya atau diterbitkan sebagai dokumen tersendiri.

Setiap lamaran harus dimulai pada halaman baru dengan kata "Aplikasi" di pojok kanan atas dan memiliki judul topik. Apabila suatu dokumen terdapat lebih dari satu lampiran, maka semua lampiran diberi nomor angka Arab (tanpa tanda No), misalnya:

Lampiran 1, Lampiran 2, dst.

Saat menerbitkan permohonan sebagai dokumen terpisah, kata “Lampiran” harus dicantumkan pada halaman judul di bawah nama dokumen, dan jika ada beberapa permohonan, nomor serinya juga harus dicantumkan.

Standar ESPD mendefinisikan ketentuan umum dan standar dasar, aturan pelaksanaan dokumentasi pengembangan, aturan pelaksanaan dokumentasi produksi, aturan pelaksanaan dokumentasi pendukung, aturan pelaksanaan dokumentasi operasional, aturan peredaran dokumentasi program dan standar lainnya. . ESPD meliputi:

· · standar fundamental dan organisasional dan metodologis;

· · standar yang mendefinisikan bentuk dan isi dokumen program yang digunakan dalam pengolahan data;

· · standar yang menjamin otomatisasi pengembangan dokumen program.

Secara umum, daftar dokumen ESPD sangat banyak. Secara khusus, ini mencakup GOST berikut:

Gost 19.001-77 ESPD. Ketentuan umum.

Gost 19.101-77 ESPD. Jenis program dan dokumen program (diterbitkan kembali pada bulan November 1987 dengan perubahan).

Gost 19.102-77 ESPD. Tahapan pengembangan.

Gost 19.103-77 ESPD. Penunjukan program dan dokumen program.

Gost 19.104-78 ESPD. Prasasti dasar.

Gost 19.105-78 ESPD. Persyaratan umum untuk dokumen program.

Gost 19.106-78 ESPD. Persyaratan untuk dokumen program yang dicetak.

Gost 19.201-78 ESPD. Tugas teknis. Persyaratan untuk konten dan desain.

Gost 19.202-78 ESPD. Spesifikasi. Persyaratan untuk konten dan desain.

Gost 19.301-79 ESPD. Program uji dan metodologi.

Gost 19.401-78 ESPD. Teks program. Persyaratan untuk konten dan desain.

Gost 19.402-78 ESPD. Deskripsi Program.

Gost 19.404-79 ESPD. Catatan penjelasan. Persyaratan untuk konten dan desain.

Gost 19.501-78 ESPD. Membentuk. Persyaratan untuk konten dan desain.

Gost 19.502-78 ESPD. Deskripsi aplikasi. Persyaratan untuk konten dan desain.

Gost 19.503-79 ESPD. Panduan Pemrogram Sistem. Persyaratan untuk konten dan desain.

Gost 19.504-79 ESPD. Panduan Pemrogram.

Gost 19.505-79 ESPD. Panduan operator.

Gost 19.506-79 ESPD. Deskripsi bahasa.

Gost 19.508-79 ESPD. Petunjuk Perawatan. Persyaratan untuk konten dan desain.

Gost 19.604-78 ESPD. Aturan untuk melakukan perubahan pada dokumen program yang dieksekusi di media cetak.

Gost 19.701-90 ESPD. Skema algoritma, program, data dan sistem. Konvensi dan aturan pelaksanaan.

Gost 19.781-90. Perangkat lunak untuk sistem pemrosesan informasi.

Seperti yang Anda lihat, bagian utama dari kompleks ESPD dikembangkan pada tahun 70an dan 80an. Beberapa dari standar ini sudah ketinggalan jaman, dan ada beberapa kelemahannya. Pertama, standar ini tidak mencerminkan beberapa tren modern dalam desain program dan dokumentasi program, dan kedua, standar ini mengandung banyak duplikasi bagian dokumentasi program. Namun demikian, karena tidak ada yang lebih baik, kita harus fokus pada hal tersebut.

Jadi, standar ESPD menyederhanakan proses pendokumentasian sistem perangkat lunak. Namun, pertama, komposisi dokumen program yang diatur oleh standar ESPD sama sekali tidak “kaku” seperti yang terlihat: standar tersebut mengizinkan jenis tambahan untuk ditambahkan ke kumpulan dokumentasi untuk sistem perangkat lunak (PS), dan , kedua, berdasarkan kebutuhan pelanggan, Beberapa perubahan diperbolehkan baik dalam struktur maupun isi jenis PD yang sudah ada. Selain itu, dapat dicatat bahwa standar ESPD (dan ini berlaku untuk semua standar lain di bidang PS - GOST 34, Standar Internasional ISO/IEC, dll.) bersifat nasihat. Faktanya adalah bahwa sesuai dengan Hukum Federasi Rusia “Tentang Standardisasi”, standar-standar ini menjadi wajib berdasarkan kontrak - yaitu. ketika mengacu pada mereka dalam kontrak untuk pengembangan (penyediaan) perangkat lunak.

Sebelum kita mulai mempertimbangkan aturan untuk menyusun dokumentasi perangkat lunak, perlu dibuat pernyataan berikut. Dianjurkan untuk mengawali setiap dokumen dengan beberapa pendahuluan. Pendahuluan berbicara secara umum. Tentang relevansi, kebutuhan, dll. Tujuan Pelaku di sini adalah untuk menunjukkan pentingnya dan perlunya melakukan pekerjaan ini. Permulaannya biasanya standar: "Banyaknya sistem yang ada saat ini... ...membuka prospek nyata di..." dll. Kutipan pidato berbagai tokoh biasanya disisipkan di sini (ini murni aspek psikologis) : “...seperti yang dikatakan pada pleno, kongres, konferensi, dll.). Anda bisa mulai dengan fakta itu "...Saat ini, di era transformasi sosial-ekonomi yang radikal...dll.". Secara umum, hal utama di sini adalah jangan berlebihan.

Dan selanjutnya. Saat mendeskripsikan produknya, pengembang sering mengacaukan konsep komponen dan kompleks. Ini adalah jenis program yang berbeda. Komponen didefinisikan sebagai “suatu program yang dianggap sebagai keseluruhan, menjalankan fungsi yang lengkap dan digunakan secara mandiri atau sebagai bagian dari suatu kompleks”, dan kompleksnya adalah “sebuah program yang terdiri dari dua atau lebih komponen dan (atau) kompleks yang menjalankan fungsi yang saling terkait, dan digunakan secara mandiri atau sebagai bagian dari kompleks lain”.

Aturan untuk menyiapkan dokumentasi perangkat lunak

Panduan ini berkaitan dengan penyusunan laporan program yang dibuat oleh mahasiswa selama praktikum di berbagai disiplin ilmu. Ketentuan umum peraturan ini juga berlaku ketika menyiapkan bagian individu dari makalah dan makalah kualifikasi, laporan praktik industri dan pendidikan, dan karya penelitian mahasiswa, jika hasil atau tahapan dalam pekerjaan tersebut adalah produk perangkat lunak atau modul perangkat lunak yang dibuat.

Dokumentasi perangkat lunak merupakan komponen integral dari produk perangkat lunak dan harus disusun sesuai dengan Sistem Dokumentasi Perangkat Lunak Terpadu (USPD - Seri Gost 19). Sebagai bagian dari pekerjaan pendidikan, diperbolehkan untuk memasukkan seluruh isi dokumentasi program ke dalam satu “laporan program”, sedangkan persyaratan formal untuk penyusunan laporan tersebut sesuai dengan persyaratan laporan penelitian. Bagian ini menguraikan poin-poin penting dari standar negara ESPD.

Dokumentasi program, selain dokumen formal (spesifikasi, daftar pemegang asli, formulir, dll), meliputi:

• kerangka acuan (tujuan, ruang lingkup penerapan program, persyaratan program);
• teks program (catatan program dengan komentar yang diperlukan);
• deskripsi program (informasi tentang struktur logis dan fungsi program);
• catatan penjelasan (diagram algoritma, gambaran umum tentang fungsi algoritma dan/atau program, alasan pengambilan keputusan);
• dokumen operasional.

Dokumen program “Catatan Penjelasan” dibuat pada tahap desain awal atau teknis program. Biasanya tidak digunakan pada tahap desain detail.

Dokumen operasional meliputi:

• deskripsi aplikasi (informasi tentang tujuan program, ruang lingkup, metode yang digunakan, kelas masalah yang harus diselesaikan, batasan penggunaan, konfigurasi minimum perangkat keras);
• panduan pemrogram sistem (informasi untuk memeriksa, memastikan berfungsinya dan menyesuaikan program untuk kondisi aplikasi tertentu);
• panduan programmer (informasi untuk mengoperasikan program);
• manual operator (informasi untuk memastikan komunikasi antara operator dan sistem komputer selama pelaksanaan program);
• deskripsi bahasa (deskripsi sintaksis dan semantik bahasa);
• manual pemeliharaan (informasi untuk menggunakan program pengujian dan diagnostik saat menyervis peralatan teknis)

Bagian utama dari dokumentasi perangkat lunak dikompilasi pada tahap desain rinci. Kebutuhan suatu dokumen tertentu ditentukan pada tahap penyusunan spesifikasi teknis. Diperbolehkan menggabungkan jenis dokumen tertentu.

Dokumen operasional "Deskripsi Bahasa" disertakan dalam dokumentasi program jika produk perangkat lunak yang dikembangkan mengimplementasikan bahasa pemrograman tertentu, manajemen tugas, organisasi proses komputasi, dll.

Dokumen operasional "Manual Pemeliharaan" disertakan dalam dokumentasi perangkat lunak jika produk perangkat lunak yang dikembangkan memerlukan penggunaan program pengujian atau diagnostik.

Kerangka acuannya meliputi:

• pendahuluan (nama, deskripsi singkat tentang bidang penerapan program);
• alasan pengembangan (dokumen yang menjadi dasar pengembangan, organisasi yang menyetujui dokumen tersebut, tanggal persetujuan, nama dan penunjukan topik pengembangan);
• tujuan pengembangan (tujuan fungsional dan operasional program);
• persyaratan program dan dokumentasi program;
• indikator teknis dan ekonomi;
• tahapan dan tahapan perkembangan;
• prosedur pengendalian dan penerimaan.

Bagian terpenting dari spesifikasi teknis adalah bagian “persyaratan”. » Bagian ini berisi:

• persyaratan karakteristik fungsional (komposisi fungsi yang dilakukan, organisasi data input dan output, karakteristik waktu);
• persyaratan keandalan (memastikan operasi yang stabil, memantau informasi input dan output, waktu pemulihan setelah kegagalan);
• persyaratan kompatibilitas informasi dan perangkat lunak (persyaratan struktur informasi pada input dan output, metode solusi, kode sumber, bahasa pemrograman dan perangkat lunak; persyaratan perlindungan informasi);
• persyaratan komposisi dan parameter sarana teknis;
• persyaratan untuk dokumentasi perangkat lunak.

Bagian ini mungkin berisi persyaratan pelabelan, pengemasan, pengangkutan dan penyimpanan, serta kondisi pengoperasian.

Selain persyaratan yang dijelaskan secara eksplisit dalam spesifikasi teknis, Anda harus mematuhi aturan pengembangan program yang berlaku umum, dengan mempertimbangkan paradigma pemrograman yang dipilih:

1. Program tidak boleh berisi elemen yang berlebihan (semua elemen program memadai untuk tugas yang ada: tidak ada elemen loop, array, dll. yang dapat diabaikan).
2. Algoritme harus terstruktur: untuk gaya pemrograman fungsional - perincian yang memadai ke dalam fungsi (prosedur), untuk gaya berorientasi objek - hierarki kelas yang memadai. Setiap fungsi (metode kelas) harus mengimplementasikan tepat satu tindakan.
3. Fungsi (metode kelas) harus memiliki parameter. Penggunaan variabel global dalam fungsi harus dihindari.
4. Program harus menggunakan memori dengan hati-hati: bekerja dengan array dinamis, tidak boleh berisi blok memori yang tidak terpakai atau variabel yang tidak diperlukan.
5. Rentang nilai dan parameter yang dimasukkan pengguna yang diteruskan antar modul program harus diperiksa.
6. Saat menggunakan komponen yang sudah jadi (fungsi perpustakaan, kelas) dalam suatu program, jika suatu fungsi atau metode kelas mungkin gagal, hal ini perlu dilakukan tanpa bergantung pada kecilnya kemungkinan kejadian seperti itu.
7. Program harus dapat dikonfigurasi (parameter program yang penting harus dipisahkan menjadi satu blok).

Teks program adalah catatan simbolis dalam bahasa sumber atau bahasa perantara atau representasi simbolis dari kode mesin. Teks program diformat dalam font monospace (Courier, Lucida Console, dll.) sesuai dengan standar desain yang berlaku umum:

1. Jumlah operator per baris harus 1.
2. Semua pernyataan yang termasuk dalam pernyataan majemuk harus digeser ke kanan dengan jumlah posisi yang sama, dan tanda kurung operator (yaitu yang membatasi pernyataan majemuk) yang termasuk dalam blok yang sama harus ditempatkan sebagai berikut: tanda kurung siku pembuka harus berada di bahwa baris yang sama dengan pernyataan pembuka blok, dan baris penutup harus berada pada kolom yang sama dengan awal pernyataan pembuka blok. Dibolehkan menempatkan tanda kurung buka pada baris setelah pernyataan yang membuka blok, pada kolom yang sama dengan awal pernyataan tersebut.
3. Seluruh baris teks sumber program harus ditempatkan pada satu baris tipografi (hingga 80 karakter tergantung fontnya). Kegagalan untuk mematuhi aturan ini menunjukkan terlalu banyak blok yang bersarang, yang berarti algoritma atau struktur program tidak berhasil. Dalam hal ini, disarankan untuk memikirkan kembali struktur program, memperkenalkan fungsi tambahan, mengganti beberapa bagian besar kode dengan panggilannya, mengulang algoritma, dll.
4. Jika sintaks bahasa memungkinkan, disarankan untuk memisahkan tanda operasi dengan spasi dari operan. Seperti pada teks biasa, koma harus diikuti spasi.
5. Definisi fungsi atau bagian logis dari suatu program harus dipisahkan satu sama lain dengan baris kosong.
6. Pengidentifikasi (nama variabel, tipe, subrutin) harus bermakna sehingga pembaca teks program dapat memahami maknanya tanpa kehadiran penulis. Jika diperlukan, deklarasi suatu variabel atau tipe dapat disertai dengan komentar.
7. Teks program harus berisi komentar yang mencerminkan tujuan fungsional blok program tertentu dan struktur program.

Dokumen "Deskripsi Program" berisi:

• informasi umum (penunjukan, nama program, perangkat lunak yang diperlukan untuk pengoperasian program, bahasa pemrograman di mana program tersebut ditulis);
• tujuan fungsional (kelas tugas yang harus diselesaikan, informasi tentang batasan fungsional pada aplikasi);
• deskripsi struktur logis (algoritma program, metode yang digunakan, struktur program dengan deskripsi komponen dan hubungan antar komponen);
• sarana teknis yang digunakan (jenis komputer dan perangkat yang digunakan saat menjalankan program);
• panggilan dan muat (metode memanggil program dari media penyimpanan yang sesuai);
• data masukan (sifat, organisasi dan persiapan awal data masukan, serta format, deskripsi dan metode pengkodeannya);
• data keluaran (sifat dan organisasi data keluaran, serta format, deskripsi dan metode pengkodeannya).

Deskripsi struktur logis program harus disertai dengan diagram blok program.

Dokumen "Deskripsi Program" juga dapat berisi diagram data, diagram interaksi program, diagram sumber daya sistem, dll., yang dirancang sesuai dengan GOST 19.701-90.

Dokumen “Deskripsi Aplikasi” mengacu pada dokumen operasional dan terdiri dari bagian-bagian berikut:

• tujuan program (kemampuan, karakteristik utama, batasan ruang lingkup penerapan);
• kondisi penggunaan (persyaratan perangkat keras dan perangkat lunak, karakteristik umum informasi masukan dan keluaran, serta persyaratan dan ketentuan yang bersifat organisasi, teknis dan teknologi);
• deskripsi masalah (definisi masalah dan metode penyelesaiannya ditunjukkan);
• data masukan dan keluaran.

Panduan Pemrogram Sistem

Dokumen "Panduan Pemrogram Sistem" mengacu pada dokumen operasional dan disertakan dalam dokumentasi program jika produk perangkat lunak yang dikembangkan memerlukan pemeliharaan oleh pemrogram sistem. Dokumen ini terdiri dari bagian-bagian berikut:

• informasi umum tentang program (tujuan dan fungsi program, informasi tentang perangkat keras dan perangkat lunak yang menjamin terlaksananya program ini);
• struktur program (informasi tentang struktur, hubungan antar modul program dan dengan program lain);
• pengaturan program (pengaturan komposisi sarana teknis, pemilihan fungsi, dll.);
• verifikasi program (metode dan teknik verifikasi, kasus uji, metode yang dijalankan, hasil);
• fitur tambahan;
• pesan ke pemrogram sistem (teks pesan yang dikeluarkan selama konfigurasi, pengujian program, selama eksekusi program dan deskripsi tindakan yang harus diambil sebagai tanggapan terhadap pesan-pesan ini).

Dokumen "Panduan Pemrogram" mengacu pada dokumen operasional dan disertakan dalam dokumentasi program jika produk perangkat lunak yang dikembangkan memerlukan pemeliharaan oleh pemrogram. Dokumen ini terdiri dari bagian-bagian berikut:

• tujuan dan ketentuan penggunaan program (tujuan dan fungsi program, informasi tentang perangkat keras dan perangkat lunak yang menjamin terlaksananya program ini);
• karakteristik program (karakteristik waktu, mode operasi, sarana pemantauan pelaksanaan yang benar, dll.);
• akses ke program (metode mentransfer parameter kontrol dan data);
• data masukan dan keluaran (format dan pengkodean);
• pesan (teks pesan yang diberikan kepada pemrogram atau operator selama eksekusi program dan deskripsi tindakan yang harus diambil sebagai tanggapan terhadap pesan tersebut).

Dokumen "Panduan Operator" mengacu pada dokumen operasional dan terdiri dari bagian-bagian berikut:

• tujuan program (informasi yang cukup untuk memahami fungsi program dan pengoperasiannya);
• kondisi untuk pelaksanaan program (perangkat keras dan perangkat lunak minimum dan/atau maksimum, dll.);
• eksekusi program (urutan tindakan operator yang memastikan pemuatan, peluncuran, eksekusi, dan penghentian program; menjelaskan fungsi, format, dan kemungkinan versi perintah yang digunakan operator untuk memuat dan mengontrol eksekusi program, serta respons program terhadap perintah-perintah ini);
• pesan ke operator (teks pesan yang dikeluarkan ke operator selama eksekusi program dan deskripsi tindakan yang harus diambil sebagai respons terhadap pesan tersebut).

Menurut Gost ini, :

• Bagian judul.
• Bagian informasi.

• Bagian utama.
• Bagian dari mendaftarkan perubahan.

A.V.ХХХХХ-ХХ ХХ ХХ-Х

:

• Bagian judul:
• Bagian informasi:
  • anotasi;
  • Daftar isi;
• Bagian utama:
  • aplikasi;
  • ubah bagian logging:
  • ganti lembar registrasi.

Aturan untuk menyiapkan dokumentasi perangkat lunak

Diperbolehkan menggabungkan jenis dokumen operasional tertentu (kecuali daftar dokumen operasional dan formulir). Kebutuhan untuk menggabungkan dokumen-dokumen ini ditunjukkan dalam spesifikasi teknis. Dokumen yang digabungkan diberi nama dan penunjukan salah satu dokumen yang digabungkan.

Jenis dokumen program dan isinya

Ke atas
GOST 19.103-77 (Penunjukan program dan dokumen program)
Dari Gost ini kita memperoleh struktur penunjukan program dan dokumen program. Di bawah ini adalah bagian terpenting.

Struktur penunjukan program dan dokumen programnya - spesifikasi:

• Standar ini mengatur bentuk, ukuran, lokasi dan tata cara pengisian prasasti utama lembar persetujuan dan halaman judul dalam dokumen program yang diatur oleh standar ESPD, apapun metode pelaksanaannya.

• Standar ini menetapkan persyaratan umum untuk pelaksanaan dokumen program untuk komputer, kompleks dan sistem, terlepas dari tujuan dan ruang lingkup penerapannya dan diatur oleh standar Sistem Dokumentasi Program Terpadu (USPD) untuk metode apa pun dalam melaksanakan dokumen di berbagai bidang. pembawa data.
• Dokumen program terdiri dari bagian konvensional berikut:
  • judul;
  • informasional;
  • dasar;
  • pendaftaran perubahan.
• Bagian sampul terdiri dari lembar persetujuan dan halaman judul. Aturan untuk menyusun lembar persetujuan dan halaman judul ditetapkan sesuai dengan Gost 19.104-78.
• Bagian informasi harus terdiri dari abstrak dan isi.
  • Kebutuhan untuk memasukkan bagian informasi dalam berbagai jenis dokumen program ditetapkan oleh standar ESPD yang relevan untuk dokumen-dokumen tersebut.
  • Anotasi memberikan informasi tentang tujuan dokumen dan ringkasan singkat bagian utamanya.
  • Isinya meliputi daftar catatan tentang unsur-unsur struktur bagian utama dokumen, yang masing-masing meliputi:
    • penunjukan elemen struktur (jumlah bagian, subbagian, dll);
    • nama elemen struktur;
    • alamat elemen struktural pada media penyimpanan (misalnya, nomor halaman, nomor file, dll.).
• Komposisi dan struktur bagian utama dokumen program ditetapkan oleh standar ESPD untuk dokumen terkait.
• Bagian dari pendaftaran perubahan (harus ada di setiap dokumen program)
  • Setiap perubahan dalam dokumen program dicatat di bagian ini sesuai dengan persyaratan Gost 19.603-78.

Ke atas
==================================
GOST 19.106-78* (Persyaratan umum untuk dokumen program yang dihasilkan dalam bentuk cetakan
jalan)
Dari Gost ini kami mendapatkan aturan umum untuk metode pencetakan dalam mengeksekusi dokumen program. Di bawah ini adalah bagian terpenting.

• Standar ini menetapkan aturan untuk pelaksanaan dokumen program untuk komputer, kompleks dan sistem, terlepas dari tujuan dan ruang lingkup penerapannya dan disediakan oleh standar Sistem Terpadu Dokumentasi Program (USPD) untuk metode eksekusi tercetak.
• Standar ini tidak berlaku untuk dokumen program “Teks Program”.
• Komposisi dan struktur dokumen program ditetapkan sesuai dengan Gost 19.105-78.
• Dokumen program dijalankan pada satu sisi lembar, dengan dua interval; diperbolehkan pada satu atau satu setengah interval.
• Dokumen program dibuat oleh:
  • pada lembar format A4 (GOST 2.301-68) - saat menyiapkan dokumen dengan mengetik atau menulis tangan (formulir 1). Menggambar pada lembar A3 diperbolehkan.

• Materi dokumen program disusun dengan urutan sebagai berikut:
  • bagian judul:
    • lembar persetujuan (tidak termasuk dalam jumlah lembar dokumen);
    • halaman judul (halaman pertama dokumen);
  • bagian informasi:
    • anotasi;
    • Daftar isi;
  • bagian utama:
    • teks dokumen (dengan gambar, tabel, dll.);
    • aplikasi;
    • daftar istilah, daftar singkatan, daftar gambar, daftar tabel, indeks pokok bahasan, daftar dokumen acuan;
  • ubah bagian logging:
    • ganti lembar registrasi.

• Abstrak ditempatkan pada halaman tersendiri (bernomor) dengan judul “ABSTRAK” dan tidak diberi nomor sebagai suatu bagian.
  • Anotasi menunjukkan edisi program dan menguraikan secara singkat tujuan dan isi dokumen. Jika dokumen terdiri dari beberapa bagian, jumlah bagian dicantumkan dalam anotasi.
• Isi dokumen ditempatkan pada halaman (halaman) tersendiri (bernomor) setelah anotasi, diberi judul “ISI”, tidak diberi nomor satu bagian dan termasuk dalam jumlah halaman seluruh dokumen.
• Judul bagian ditulis dengan huruf kapital dan ditempatkan secara simetris terhadap batas kanan dan kiri teks.
• Judul subbagian ditulis dari paragraf dengan huruf kecil (kecuali huruf kapital pertama).
• Tanda hubung kata dalam judul tidak diperbolehkan. Tidak ada titik di akhir judul.

• Jarak antara judul dengan teks berikutnya, serta antara judul bagian dan subbagian, harus sama dengan:
  • saat mengeksekusi dokumen dengan mengetik - dua interval.
• Untuk bagian dan subbagian yang teksnya ditulis pada halaman yang sama dengan teks bagian sebelumnya, jarak antara baris teks terakhir dan judul berikutnya harus sama dengan:
  • saat mengeksekusi dokumen menggunakan metode yang diketik - tiga interval yang diketik.
• Bagian, subbagian, paragraf, dan subparagraf diberi nomor dengan angka Arab dan diberi titik.
• Dalam suatu bagian harus ada penomoran yang berkesinambungan untuk seluruh subbagian, paragraf, dan subparagraf yang termasuk dalam bagian ini.
• Penomoran subbagian meliputi nomor bagian dan nomor urut subbagian yang termasuk dalam bagian ini, dipisahkan dengan titik (2.1; 3.1, dst).
• Apabila terdapat bagian dan subbagian, maka nomor urut klausa dan subayat (3.1.1, 3.1.1.1, dst.) ditambahkan pada nomor subbagian setelah titik.

• Teks dokumen harus singkat, jelas, tidak termasuk kemungkinan salah tafsir.
• Istilah dan definisi harus seragam dan mematuhi standar yang ditetapkan, dan jika tidak ada, harus diterima secara umum dalam literatur ilmiah dan teknis, dan diberikan dalam daftar istilah.
• Penjelasan yang diperlukan terhadap teks dokumen dapat diberikan dalam catatan kaki.
  • Catatan kaki ditandai dengan angka dengan tanda kurung setinggi tepi atas font, misalnya: “alat cetak 2) . " atau "kertas 5) ".
  • Jika catatan kaki merujuk pada satu kata, maka tanda catatan kaki diletakkan tepat di sebelah kata tersebut, tetapi jika merujuk pada kalimat secara keseluruhan, maka di akhir kalimat. Teks catatan kaki diletakkan di akhir halaman dan dipisahkan dari teks utama dengan garis sepanjang 3 cm yang ditarik di sisi kiri halaman.
• Ilustrasi, jika terdapat lebih dari satu ilustrasi dalam suatu dokumen, diberi nomor dengan angka Arab di seluruh dokumen.
• Rumus-rumus dalam suatu dokumen, apabila jumlahnya lebih dari satu, diberi nomor dengan angka Arab, nomor tersebut diletakkan di sebelah kanan halaman, dalam tanda kurung pada tingkat rumus.
• Arti simbol dan koefisien numerik yang disertakan dalam rumus harus diberikan tepat di bawah rumus. Arti setiap karakter dicetak pada baris baru sesuai urutan yang diberikan dalam rumus. Baris pertama transkrip harus dimulai dengan kata “di mana”, tanpa titik dua setelahnya.
• Dalam dokumen program, referensi ke standar (kecuali standar perusahaan), spesifikasi teknis, dan dokumen lainnya (misalnya, dokumen badan Pengawasan Negara, peraturan dan regulasi Komite Pembangunan Negara Uni Soviet) diperbolehkan. Jika mengacu pada standar dan spesifikasi teknis, peruntukannya ditunjukkan.
• Referensi harus dibuat pada dokumen secara keseluruhan atau pada bagian-bagiannya (menunjukkan penunjukan dan nama dokumen, nomor dan nama bagian atau lampiran). Saat mengulang referensi ke suatu bagian atau aplikasi, hanya nomornya yang ditunjukkan.
• Catatan pada teks dan tabel hanya menunjukkan data referensi dan penjelasan.
  • Satu not tidak diberi nomor. Setelah kata “Catatan” beri tanda titik.
  • Beberapa not harus diberi nomor secara berurutan menggunakan angka Arab dengan titik. Setelah kata “Catatan” beri tanda titik dua.
• Singkatan kata dalam teks dan tulisan di bawah ilustrasi tidak diperbolehkan.
• Materi ilustrasi, tabel atau teks pendukung dapat disajikan dalam bentuk lampiran.
• Setiap lamaran harus dimulai pada halaman baru dengan kata “LAMPIRAN” di pojok kanan atas dan mempunyai judul tematik, yang ditulis simetris dengan teks dengan huruf kapital.

Ke atas
==================================
GOST 19.604-78* (Aturan untuk membuat perubahan pada dokumen program selesai
dalam bentuk cetak)
Dari gost ini kita mendapatkan aturan umum untuk melakukan perubahan pada dokumen program (akibatnya untuk membuat suatu proyek kita hanya memerlukan lembar registrasi perubahan).

• Standar ini menetapkan aturan untuk melakukan perubahan pada dokumen program yang diatur oleh standar Sistem Terpadu Dokumentasi Program (USPD) dan dicetak.

Karena banyaknya informasi dalam Gost ini dan untuk menghemat ruang di halaman ini, saya sarankan Anda meninjau sendiri gost 19.604-78*. Anda dapat melihat contoh desain "lembar pendaftaran perubahan" yang sudah jadi di dokumen program apa pun yang disediakan di bagian UNDUH

Desain program menurut Gost (caranya)

Program komputer disusun sesuai dengan persyaratan Sistem Terpadu Dokumentasi Program (USPD). ESPD adalah seperangkat GOST yang menetapkan aturan untuk desain, konten, dan struktur dokumen program.
Petunjuk ini berisi kutipan dari ESPD. Informasi lengkap dapat diperoleh langsung dari gosts.

Algoritma desain program singkat

Secara singkat algoritma perancangan program dan jenis dokumen program ditunjukkan pada gambar. Proses pendaftaran dijelaskan lebih rinci di bawah ini.

Persiapan dokumen program

Dokumen perangkat lunak adalah dokumen yang berisi informasi yang diperlukan untuk pengembangan, produksi, pemeliharaan, dan pengoperasian program.

Setiap dokumen program individu dibuat sesuai dengan (umum untuk semua dokumen ESPD) persyaratan Gost 19.101-77, Gost 19.103-77, Gost 19.104-78, Gost 19.105-78, Gost 19.106-78, Gost 19.604-78 ( penjelasan lebih rinci tentang gost ini berikut di bawah) dan gost untuk dokumen program tertentu.

Persyaratan umum untuk dokumen program. Gost 19.105 - 78

GOST 19.105-78 menetapkan persyaratan umum untuk persiapan dokumen program.

Menurut Gost ini, dokumen program harus terdiri dari bagian-bagian berikut:

• Bagian judul. Bagian sampul terdiri dari lembar persetujuan dan halaman judul. Tata cara pembuatan lembar persetujuan dan halaman judul dijelaskan di bawah ini.
• Bagian informasi. Bagian informasi harus terdiri dari abstrak dan isi.
  • Anotasi memberikan informasi tentang tujuan dokumen dan ringkasan singkat bagian utamanya.
  • Isinya mencakup daftar catatan tentang elemen struktural bagian utama dokumen.

Kebutuhan akan bagian informasi dalam berbagai jenis dokumen program ditentukan oleh Gost yang relevan untuk dokumen program ini.

• Bagian utama. Komposisi dan struktur bagian utama dokumen program ditetapkan oleh standar ESPD untuk dokumen terkait.
• Bagian dari mendaftarkan perubahan. Pada bagian ini, setiap perubahan dalam dokumen program dicatat sesuai dengan persyaratan Gost 19.603 - 78.

Jenis dokumen program. Gost 19.101 - 77

GOST 19.101-77 menetapkan jenis program dan dokumen program untuk komputer, kompleks dan sistem, terlepas dari tujuan dan ruang lingkupnya.

Gost menetapkan 2 jenis program:

• Komponen - suatu program yang dianggap secara keseluruhan, menjalankan fungsi yang lengkap dan digunakan secara mandiri atau sebagai bagian dari suatu kompleks;
• Kompleks - program yang terdiri dari dua atau lebih komponen dan (atau) kompleks yang menjalankan fungsi yang saling terkait, dan digunakan secara mandiri atau sebagai bagian dari kompleks lainnya.

GOST juga menentukan jenis dan isi dokumen program.

Penunjukan program dan dokumen program. Gost 19.103 - 77

GOST 19.103-77 menetapkan struktur penunjukan program dan dokumen program untuk komputer, kompleks dan sistem, terlepas dari tujuan dan ruang lingkup penerapannya.

Sederhananya, gost ini menjelaskan apa yang seharusnya menjadi kode dokumen formulir A.V.ХХХХХ-ХХ ХХ ХХ-Х, dan arti setiap bidang sandi ini.

Prasasti dasar. Gost 19.104 - 78

GOST 19.104-78 menetapkan bentuk, ukuran, lokasi dan prosedur pengisian prasasti utama lembar persetujuan dan halaman judul dalam dokumen program yang disediakan oleh standar ESPD, terlepas dari metode penerapannya.

GOST berisi contoh halaman judul dan lembar persetujuan, serta bentuk umum lembar, dibagi menjadi beberapa bidang. Anda juga dapat melihat contohnya.

Persyaratan untuk dokumen program yang dicetak. Gost 19.106 - 78

GOST 19.106-78 menetapkan aturan untuk pelaksanaan dokumen program untuk metode eksekusi tercetak.

Penting untuk dicatat bahwa GOST ini tidak berlaku untuk dokumen program “Teks Program”.

Bahan dokumen program harus dalam urutan berikut:

• Bagian judul:
  • lembar persetujuan (tidak termasuk dalam jumlah lembar dokumen);
  • halaman judul (halaman pertama dokumen);
• Bagian informasi:
  • anotasi;
  • Daftar isi;
• Bagian utama:
  • teks dokumen (dengan gambar, tabel, dll.);
  • aplikasi;
  • daftar istilah, daftar singkatan, daftar gambar, daftar tabel, indeks pokok bahasan, daftar dokumen acuan;
  • ubah bagian logging:
  • ganti lembar registrasi.

Anotasi menunjukkan edisi program dan menguraikan secara singkat tujuan dan isi dokumen. Jika dokumen terdiri dari beberapa bagian, jumlah bagian dicantumkan dalam anotasi. Isi dokumen ditempatkan pada halaman (halaman) tersendiri (bernomor) setelah anotasi, diberi judul “ISI”, tidak diberi nomor satu bagian dan termasuk dalam jumlah halaman seluruh dokumen.

• Dokumen program dijalankan pada satu sisi lembar, dengan dua interval; diperbolehkan pada satu atau satu setengah interval.
• Abstrak ditempatkan pada halaman tersendiri (bernomor) dengan judul “ABSTRAK” dan tidak diberi nomor sebagai suatu bagian.
• Judul bagian ditulis dengan huruf kapital dan ditempatkan secara simetris terhadap batas kanan dan kiri teks.
• Judul subbagian ditulis dari paragraf dengan huruf kecil (kecuali huruf kapital pertama).
• Tanda hubung kata dalam judul tidak diperbolehkan. Tidak ada titik di akhir judul.
• Jarak antara judul dengan teks berikutnya, serta antara judul bagian dan subbagian, harus sama dengan:
  • saat mengeksekusi dokumen dengan mengetik - dua interval.
• Untuk bagian dan subbagian yang teksnya ditulis pada halaman yang sama dengan teks bagian sebelumnya, jarak antara baris teks terakhir dan judul berikutnya harus sama dengan:
  • saat mengeksekusi dokumen menggunakan metode yang diketik - tiga interval yang diketik.
• Bagian, subbagian, paragraf, dan subparagraf diberi nomor dengan angka Arab dan diberi titik.
• Dalam suatu bagian harus ada penomoran yang berkesinambungan untuk seluruh subbagian, paragraf, dan subparagraf yang termasuk dalam bagian ini.
• Penomoran subbagian meliputi nomor bagian dan nomor urut subbagian yang termasuk dalam bagian ini, dipisahkan dengan titik (2.1; 3.1, dst).
• Apabila terdapat bagian dan subbagian, maka nomor urut klausa dan subayat (3.1.1, 3.1.1.1, dst.) ditambahkan pada nomor subbagian setelah titik.
• Teks dokumen harus singkat, jelas, tidak termasuk kemungkinan salah tafsir.
• Istilah dan definisi harus seragam dan mematuhi standar yang ditetapkan, dan jika tidak ada, harus diterima secara umum dalam literatur ilmiah dan teknis, dan diberikan dalam daftar istilah.
• Penjelasan yang diperlukan terhadap teks dokumen dapat diberikan dalam catatan kaki.
• Catatan kaki ditandai dengan angka dengan tanda kurung setinggi tepi atas font, misalnya: “perangkat pencetakan2). " atau "kertas5)".
• Jika catatan kaki merujuk pada satu kata, maka tanda catatan kaki diletakkan tepat di sebelah kata tersebut, tetapi jika merujuk pada kalimat secara keseluruhan, maka di akhir kalimat. Teks catatan kaki diletakkan di akhir halaman dan dipisahkan dari teks utama dengan garis sepanjang 3 cm yang ditarik di sisi kiri halaman.
• Ilustrasi, jika terdapat lebih dari satu ilustrasi dalam suatu dokumen, diberi nomor dengan angka Arab di seluruh dokumen.
• Rumus-rumus dalam suatu dokumen, apabila jumlahnya lebih dari satu, diberi nomor dengan angka Arab, nomor tersebut diletakkan di sebelah kanan halaman, dalam tanda kurung pada tingkat rumus.
• Arti simbol dan koefisien numerik yang disertakan dalam rumus harus diberikan tepat di bawah rumus. Arti setiap karakter dicetak pada baris baru sesuai urutan yang diberikan dalam rumus. Baris pertama transkrip harus dimulai dengan kata “di mana”, tanpa titik dua setelahnya.
• Dalam dokumen program, referensi ke standar (kecuali standar perusahaan), spesifikasi teknis, dan dokumen lainnya (misalnya, dokumen badan Pengawasan Negara, peraturan dan regulasi Komite Pembangunan Negara Uni Soviet) diperbolehkan. Jika mengacu pada standar dan spesifikasi teknis, peruntukannya ditunjukkan.
• Referensi harus dibuat pada dokumen secara keseluruhan atau pada bagian-bagiannya (menunjukkan penunjukan dan nama dokumen, nomor dan nama bagian atau lampiran). Saat mengulang referensi ke suatu bagian atau aplikasi, hanya nomornya yang ditunjukkan.
• Catatan pada teks dan tabel hanya menunjukkan data referensi dan penjelasan.
• Satu not tidak diberi nomor. Setelah kata “Catatan” beri tanda titik.
• Beberapa not harus diberi nomor secara berurutan menggunakan angka Arab dengan titik. Setelah kata “Catatan” beri tanda titik dua.
• Singkatan kata dalam teks dan tulisan di bawah ilustrasi tidak diperbolehkan.
• Materi ilustrasi, tabel atau teks pendukung dapat disajikan dalam bentuk lampiran.
• Setiap lamaran harus dimulai pada halaman baru dengan kata “LAMPIRAN” di pojok kanan atas dan mempunyai judul tematik, yang ditulis simetris dengan teks dengan huruf kapital.

GOST berisi lembar contoh yang menunjukkan bidang, tempat penomoran halaman, dan kode.

Templat saya yang terbaru (2016).

Ini menarik:

• Pesan 109/GS Atas persetujuan seperangkat aturan "SNiP 3.03.01-87 "Struktur penahan beban dan penutup" Beli Pesanan 109/GS - dokumen kertas resmi dengan hologram dan segel biru. lebih detail Harga untuk dokumen ini belum diketahui Klik tombol "Beli" dan lakukan pemesanan dan kami akan mengirimkan [...]
• 1C:Enterprise 8 Konfigurasi standarAkuntansi Kazakhstan (dasar), edisi 2.0 Versi 2.0.13 Baru di versi 2.0.13.5 Pembaruan indikator yang diatur per 1 Januari 2014 Sesuai dengan Hukum Republik Kazakhstan "Tentang Anggaran Republik untuk 2014-2016" mulai 1 Januari 2014 […]
• Notaris Ippolitova Nina Aleksandrovna di Odintsovo Ulasan tentang notaris Ippolitova Nina Aleksandrovna Saya dengan ini dengan bebas, atas kemauan saya sendiri dan untuk kepentingan saya sendiri, memberikan persetujuan saya kepada Media Solutions LLC, yang berlokasi di Tyumen st. 50 tahun VLKSM 19 - 76 (selanjutnya disebut Operator) untuk otomasi dan […]
• 20 Notaris di Novorossiysk Dengan ini saya dengan bebas, atas kemauan saya sendiri dan untuk kepentingan saya sendiri, memberikan persetujuan saya kepada Media Solutions LLC, yang berlokasi di Tyumen st. 50 tahun VLKSM 19 - 76 (selanjutnya disebut Penyelenggara) untuk pemrosesan data pribadinya secara otomatis dan non-otomatis sesuai dengan […]
• 13 Notaris di Naberezhnye Chelny Saya dengan ini dengan bebas, atas kemauan saya sendiri dan untuk kepentingan saya sendiri, memberikan persetujuan saya kepada Media Solutions LLC, yang berlokasi di Tyumen st. 50 tahun VLKSM 19 - 76 (selanjutnya disebut Operator) untuk pemrosesan data pribadi mereka secara otomatis dan non-otomatis di […]
• Putra jaksa disinari fajar pucat, Halaman kuburan tua itu, Dan di atas kuburan yang lembap, Seorang pencuri muda menangis. Dan di atas kuburan yang lembap, seorang pencuri muda menangis. Ibuku yang malang, Mengapa kamu pergi begitu cepat, Kamu tidak melihat hidupmu, Kamu menemukan ayah yang bajingan. Hidupmu tidak [...]
• Hukuman penyelesaian Asuransi mobil Sengketa perumahan Sengketa tanah Hukum administratif Partisipasi dalam konstruksi bersama Perselisihan keluarga Hukum perdata, KUH Perdata Federasi Rusia Perlindungan hak-hak konsumen Perselisihan perburuhan, pensiun Rumah Jenis hukuman: offset, […]
• Perintah (instruksi) tentang insentif bagi pegawai Perintah tentang insentif (bonus atau penghargaan) bagi pegawai dikeluarkan oleh pimpinan organisasi, dan perintah tersebut dikeluarkan oleh pejabat lain yang berwenang. Pimpinan organisasi juga berhak mengajukan insentif bagi pegawai […]

		Aturan pendaftaran dan persyaratan isi kursus		Edisi 2
		proyek (pekerjaan) dan pekerjaan kualifikasi akhir		halaman 39 dari 73
	Gambar perakitan unit perakitan
	di bawah nomor 8, termasuk dalam produk 1		PK.760108.000 SB
	Gambar rakitan dari rakitan terpisah
	unit 4		PK.760004.000 SB
	Gambar pandangan umum dari rakitan terpisah
	unit 4		PK.760004.000 VO
	Gambar bagian nomor 16 termasuk dalam
	unit perakitan 8 produk 1
	Gambar bagian nomor 120 disertakan dalam
	unit perakitan terpisah 4
	Diagram rangkaian listrik produk 1		PK.760100.000 E3
	Diagram rangkaian kinematik, terpisah
	tidak ada unit perakitan 4		PK.760400.000 K3
	Spesifikasi unit perakitan 8 produk 1

10 Persiapan dokumen teknologi

10.1 Dokumen teknologi proyek kursus (pekerjaan) dan pekerjaan kualifikasi akhir disusun sesuai dengan persyaratan standar ESTD.

10.2 Dokumen teknologi harus mencakup:

– halaman judul, dirancang sesuai dengan Gost 3.1105-84 “ESTD. Bentuk dan aturan pelaksanaan dokumen tujuan umum” (Formulir 2a).

– peta rute dikeluarkan sesuai dengan Gost 3.1118-82 “ESTD. Bentuk dan aturan penyusunan peta rute";

– kartu operasi permesinan dan operasional

perhitungan dan peta teknologi untuk operasi teknologi pada mesin CNC - sesuai dengan GOST 3.1404-86 “ESTD. Bentuk dan aturan penyiapan dokumen untuk proses teknologi dan operasi pemotongan”;

– kartu operasi tukang kunci, pekerjaan pipa dan perakitan sesuai dengan GOST 3.1407-86 “ESTD. Formulir dan persyaratan pengisian dan pemrosesan dokumen untuk proses teknologi (operasi) khusus dalam metode perakitan”;

– peta sketsa (jika perlu) menurut Gost 3.1105-84 dan Gost 3.1128-93 “ESTD. Aturan umum untuk pelaksanaan dokumen teknologi grafis";

– kartu kendali proses operasional menurut Gost 3.1502-85 “ESTD. Bentuk dan aturan penyiapan dokumen untuk pengendalian teknis";

– dokumen teknologi lainnya (jika perlu atau seperti yang diputuskan oleh manajer proyek).

10.3 Gambar perbaikan dilakukan sesuai dengan aturan yang ditentukan oleh "Gambar perbaikan" GOST 2.604-88.

10.4 Dokumen teknologi harus dijilid

langsung dalam catatan penjelasan pekerjaan kursus (proyek) atau setelah aplikasi, spesifikasi dan daftar elemen. Dokumen teknologi memiliki penomorannya sendiri.

11 Penyiapan dokumen program

11.1 Dokumen berbagai bidang masalah yang dikembangkan dalam proyek kursus (pekerjaan) dan pekerjaan kualifikasi akhir harus diformat sebagai berikut:

– dokumen program - sesuai dengan persyaratan ESPD,

– dokumen untuk sistem kendali otomatis - sesuai dengan standar negara bagian untuk dokumentasi teknologi sistem kendali otomatis. 11.2 Dokumen program (daftar program) harus mencakup:

– teks program, dirancang sesuai dengan Gost 19.401;

– deskripsi program, dibuat sesuai dengan Gost 19.402;

– deskripsi catatan yang diberikan sesuai dengan Gost 19.502;

– dokumen program lainnya (jika perlu).

11.3 Daftar program ditempatkan dalam aplikasi dengan tautan wajib ke program tersebut di PP.

11.4 Kode program dapat disertai komentar. Saat mendesain listingan, disarankan untuk menggunakan font Courier New, ukuran – 12 pt, spasi baris – tunggal. Disarankan untuk memisahkan blok semantik dengan garis kosong, serta secara visual menunjukkan struktur bersarang menggunakan indentasi.

11.5 Kata kunci dan komentar dalam daftar program mungkin dicetak miring. Dalam teks utama PP, nama perpustakaan, subrutin, konstanta, variabel, dll harus dicetak miring.

11.6 Daftar program harus diberi nomor urut dalam aplikasi. Nomor pencatatan harus terdiri atas peruntukan permohonan dan nomor urut pencatatan, dipisahkan dengan titik, contoh: “Listing A.3” adalah listing ketiga dari Lampiran A. Apabila proyek (pekerjaan) hanya memuat satu listing, itu disebut “Listing 1”. Apabila mengacu pada suatu daftar dalam teks PP, harus dituliskan kata “Daftar” yang menunjukkan nomornya.

11.7 Judul daftar program menggunakan jenis huruf yang sama dengan teks utama dan diletakkan di atas daftar sebelah kiri, tanpa lekukan, dipisahkan dengan tanda hubung, setelah nomor daftar.

Contoh desain listing program Listing A.3 – Program “Output array dua dimensi”

mas:array bilangan bulat; ( deklarasi array dua dimensi) i,j: bilangan bulat;

Aturan pendaftaran dan persyaratan isi proyek kursus (karya) dan karya kualifikasi akhir – 09.1

(Memasukkan nilai elemen array) untuk i:=1 hingga 5 lakukan

untuk j:=1 sampai 5 lakukan readln(mas);

(Mencetak nilai elemen array) untuk i:=1 hingga 5 dimulai

untuk j:=1 sampai 5 lakukan write(" ",mas); menulis;

12 Kontrol standar

12.1 Pengendalian standar merupakan tahap akhir dalam pengembangan dokumen untuk proyek kursus (pekerjaan) dan proyek.

12.2 Kontrol standar harus mematuhi persyaratan Gost 2.111.

12.3 Pekerjaan kualifikasi akhir tunduk pada kontrol standar. Pengendalian standar proyek kursus (karya) dilakukan oleh guru ketika mempertahankan karya. Pengendalian standar ditujukan untuk pelaksanaan yang benar dari dokumen teks dan grafik proyek kursus (pekerjaan) dan pekerjaan teknis (selanjutnya disebut dokumen) sesuai dengan persyaratan standar GOST, ESKD, ESPD dan ESTD.

12.4 Pengendalian standar dilakukan oleh pemeriksa norma dengan memperhatikan persyaratan, standar dan yang berlaku saat ini dokumen peraturan dan teknis.

12.5 Dalam proses pengendalian normatif catatan penjelasan proyek kursus (pekerjaan) dan pekerjaan teknis, hal-hal berikut diperiksa:

– kepatuhan terhadap aturan pendaftaran sesuai dengan Peraturan ini;

– penampilan PZ;

– kelengkapan desain sesuai dengan penugasan desain;

– halaman judul diisi dengan benar dan tanda tangan yang diperlukan ada;

– penyelesaian pernyataan proyek (pekerjaan) dengan benar;

– keberadaan dan kebenaran bingkai dan prasasti utama pada semua halaman;

– penyorotan judul, bagian dan subbagian, adanya garis merah;

– pemformatan konten yang benar, kesesuaian nama bagian dan subbagian konten dengan nama yang sesuai dalam teks catatan;

– penomoran halaman, bagian, subbagian, gambar, tabel, rumus yang benar;

– kebenaran gambar;

– pemformatan tabel yang benar;

– kebenaran dimensi besaran fisika, kesesuaiannya dengan SI;

– kepatuhan terhadap norma-norma bahasa Rusia modern;

– kebenaran singkatan kata yang digunakan;

Aturan pendaftaran dan persyaratan isi proyek kursus (karya) dan karya kualifikasi akhir – 09.1

– ketersediaan dan kebenaran referensi terhadap sumber yang digunakan;

– ketersediaan dan kebenaran referensi dokumen peraturan;

– kebenaran daftar sumber yang digunakan;

– desain aplikasi yang benar.

12.6 Dalam proses pengendalian normatif dokumen grafik proyek kursus (pekerjaan) dan pekerjaan teknis, hal-hal berikut diperiksa:

– kesesuaian gambar dengan persyaratan standar yang berlaku;

– pelaksanaan gambar sesuai dengan persyaratan dokumen peraturan;

– kepatuhan terhadap format, kebenaran desainnya;

– gambar dan penerapan garis yang benar;

– kepatuhan terhadap skala, kebenaran peruntukannya;

– kecukupan gambar (jenis, bagian, bagian), kebenaran peruntukan dan lokasinya;

– pemenuhan simbol-simbol unsur dalam diagram dan aturan pelaksanaannya sesuai dengan persyaratan ESKD.

12.7. Pengendalian standar pekerjaan kualifikasi akhir direkomendasikan untuk dilakukan dalam dua tahap: setelah draft (atau dalam garis tipis) dan pengembangan akhir dari dokumen asli. Dokumen yang sedang dikembangkan harus diserahkan untuk pengendalian regulasi dalam satu set lengkap, mis. teks (catatan penjelasan) dan dokumentasi grafis (gambar, spesifikasi, dll.).

12.8 Daftar komentar dari pemeriksa standar disusun jika pengendalian dilakukan tanpa kehadiran pengembang siswa dan inti kesalahannya dapat disalahartikan olehnya.

12.9 Dokumen yang diperiksa oleh pemeriksa normatif di hadapan pengembang siswa, bersama dengan daftar komentar (jika ada), dikembalikan kepada siswa untuk dikoreksi dan direvisi. Jika ada komentar, catatan pemeriksa norma disimpan sampai dia menandatangani dokumen tersebut. Jika suatu dokumen dikerjakan ulang oleh seorang siswa, maka kedua salinan itu diserahkan untuk diperiksa kembali: dengan tanda pemeriksa normatif dan yang telah direvisi.

12.10 Dokumen yang diserahkan untuk ditandatangani kepada pengawas normatif harus memiliki semua visa persetujuan, kecuali visa kepala departemen. Dokumen asli akhir dari tugas kuliah dan proyek diploma (karya) ditandatangani oleh inspektur normatif

V kolom "N.lanjutan." prasasti utama.

12.11 Dilarang memperkenalkan tanpa sepengetahuan pemeriksa normatif setiap perubahan pada dokumen setelah dokumen ini ditandatangani dan disahkan oleh pengawas regulasi.

12.12 Pemeriksa peraturan berhak, dalam hal-hal yang dibenarkan, untuk tidak menandatangani dokumen yang disediakan:

– dalam hal kegagalan untuk mematuhi persyaratan dokumen peraturan;

– jika tidak ada tanda tangan wajib;

- jika dilakukan secara sembarangan;

– jika terjadi pelanggaran terhadap kelengkapan yang telah ditetapkan.

Aturan pendaftaran dan persyaratan isi proyek kursus (karya) dan karya kualifikasi akhir – 09.1

12.13 Pengontrol normatif bertanggung jawab untuk mematuhi persyaratan standar saat ini dan dokumen peraturan dan teknis lainnya dalam dokumentasi yang sedang dikembangkan, bersama dengan pengembang dokumentasi.

13 Tinjauan WRC

13.1 Untuk mendapatkan penilaian obyektif tambahan atas pekerjaan kualifikasi akhir yang diajukan untuk pertahanan, tinjauan eksternal terhadap pekerjaan kualifikasi akhir dilakukan oleh spesialis di bidang yang relevan.

13.2 Peninjau karya kualifikasi akhir adalah spesialis berkualifikasi tinggi, yang daftar pribadinya ditentukan oleh departemen kelulusan. Berikut ini mungkin terlibat sebagai peninjau: praktisi dan guru dari universitas lain.

Rujukan untuk peninjauan dikeluarkan oleh departemen yang lulus, yang bentuknya disajikan dalam Lampiran T Peraturan ini.

13.3 Reviewer harus memahami semua persyaratan untuk pekerjaan kualifikasi akhir (GQR).

13.4 Tinjauan disiapkan secara tertulis dan berisi penilaian yang beralasan:

– relevansi topik WRC;

– kesesuaian isi penelitian dan pengembangan dengan tugas pengembangannya;

– kebenaran struktur logis WRC;

– efektivitas dan validitas keputusan desain;

– kelebihan dan kekurangan sekolah pascasarjana, kesesuaiannya dengan persyaratan kualifikasi lulusan di bidang studi;

– pendaftaran VKR.

Pada bagian akhir tinjauan diberikan kesimpulan tentang kelengkapan pengembangan topik, sesuai dengan tugas yang diberikan, tentang signifikansi teoritis atau praktis dari penelitian ilmiah, dan tentang kemungkinan bidang penggunaan penelitian ilmiah. hasil penelitian ilmiah tersebut. Peninjau mengevaluasi pekerjaan pada skala empat poin (“sangat baik”, “baik”, “memuaskan”, “tidak memuaskan”) dan menunjukkan kemungkinan untuk memberikan kualifikasi yang tepat kepada siswa.

13.5 Volume peninjauan pekerjaan kualifikasi akhir seharusnya 2-3 halaman teks yang dicetak atau ditulis tangan dengan jelas. Review yang ditandatangani harus diserahkan ke departemen selambat-lambatnya tiga hari sebelum pembelaan tesis.

13.6 Peninjauan dapat dilakukan pada kop surat organisasi (tempat kerja peninjau), atau pada formulir standar yang diatur oleh Peraturan ini (Lampiran U) dan disertifikasi dengan stempel organisasi, atau stempel departemen personalia (umum departemen, kantor) dengan tanda “tanda tangan benar”.

13.7 Untuk mempertahankan tesis Anda, Anda juga dapat mengirimkan ulasan dari organisasi terkemuka yang ditugaskan oleh komisi pengesahan negara

Aturan pendaftaran dan persyaratan isi proyek kursus (karya) dan karya kualifikasi akhir – 09.1

VCR telah dilakukan. Tinjauan tersebut harus menyoroti nilai praktis dari hasil yang diperoleh.

14 Masukan mengenai WRC

14.1 Ulasan pekerjaan kualifikasi akhir dikumpulkan langsung oleh atasannya. Tinjauan harus mencirikan tesis dari berbagai aspek: isi, struktur, kelengkapan topik yang dipilih, dll.

14.2 Pembimbing harus menyatakan dalam tinjauan pendapat obyektifnya tentang pekerjaan kualifikasi akhir siswa. Secara khusus, tinjauan harus berisi informasi:

– tentang relevansi topik pekerjaan;

– tentang kepatuhan pekerjaan kualifikasi akhir dengan persyaratan standar;

– tentang pengetahuan siswa tentang metode pengumpulan, pengolahan dan analisis informasi yang digunakan dalam bidang kegiatan profesional;

– tentang kemampuan siswa untuk bekerja secara mandiri dengan sumber dengan jelas dan jelas serta menyajikan materi secara konsisten;

– tentang aspek positif pekerjaan;

– tentang kekurangan dan komentar terhadap isi karya, dll.

14.3 Tinjauan supervisor terhadap pekerjaan kualifikasi akhir dapat berisi saran mengenai penilaian pekerjaan secara keseluruhan.

14.4 Di akhir peninjauan, pengawas membuat kesimpulan tentang kemungkinan penyerahan karya kualifikasi akhir untuk pembelaan kepada Komisi Pengesahan Negara.

14.5 Teks resensi dosen pembimbing skripsi dicetak pada lembar A4 dan ditandatangani oleh dosen pembimbing. Formulir masukan untuk WRC disajikan pada Lampiran F.

15 Laporan dan presentasi

15.1 Laporan (pidato) merupakan karya yang bersifat presentasional, mencerminkan esensi WRC.

Laporan tersebut harus menyentuh relevansi topik yang dipilih, landasan teoretis dan metodologis dari pekerjaan tersebut, serta merangkum dan merangkum hasil yang diperoleh selama penelitian.

Di akhir presentasi, perlu dicerminkan signifikansi praktis dari hasil, kemungkinan penerapannya dalam praktik atau penggunaan dalam pengajaran.

15.2 Laporan ini dirancang untuk waktu bicara yang terbatas dan terkait erat dengan presentasi (handout).

Aturan pendaftaran dan persyaratan isi proyek kursus (karya) dan karya kualifikasi akhir – 09.1

15.3 Presentasi (handout) adalah materi visual digital, tabular dan ilustratif yang disiapkan dengan menggunakan program khusus (misalnya Microsoft PowerPoint) yang berhubungan langsung dengan laporan.

15.4 Untuk presentasi, bahan ilustrasi yang diperlukan dipilih, yang dapat diambil baik dari teks karya maupun dari lampiran. Bisa berupa tabel, gambar, diagram, diagram, rumus, dll. Tabel tidak boleh besar, gambar tidak boleh terlalu detail, rumus harus jelas.

Materi harus menggambarkan semua poin yang disampaikan dalam laporan.

15.5 Presentasi dapat ditampilkan dalam dua cara:

– menggunakan proyektor dan dudukan;

– menggunakan handout dalam bentuk salinan kertas untuk setiap anggota komisi.

Volume presentasi bisa 8 hingga 12 slide.

15.6 Laporan hanya boleh berisi inti permasalahan yang sedang dipertimbangkan, minimal data digital, nama khusus, dan pencacahan.

Laporan dibangun menurut skema logis yang sama dengan proyek (pekerjaan), yaitu: bagian pendahuluan, bagian utama dan kesimpulan. Bagian pendahuluan harus memuat relevansi dan tujuan pekerjaan, bagian utama harus mengungkapkan sepenuhnya topik yang sedang dipertimbangkan. Kesimpulan harus ringkas dan tidak ambigu;

dalam 1-2 kalimat, pertimbangkan rekomendasi untuk memecahkan masalah yang diajukan.

15.7 Yang pertama harus berupa slide dengan topik proyek (pekerjaan) dan rincian pelaku, yaitu: nama belakang, nama depan, patronimik, grup, spesialisasi (arah). Dianjurkan untuk menunjukkan pembimbing ilmiah.

15.8 Proyek mata kuliah (karya) dan tesis diserahkan ke arsip bersama dengan presentasi yang dibuat dalam bentuk elektronik dan direkam pada media digital (misalnya CD/DVD).

Aturan pendaftaran dan persyaratan isi proyek kursus (karya) dan karya kualifikasi akhir – 09.1

Lampiran A

Aturan pendaftaran dan persyaratan isi proyek kursus (karya) dan karya kualifikasi akhir – 09.1

Lampiran B

(nama fakultas)

(nama departemen)

____________ ________________

CATATAN PENJELASAN

untuk proyek kursus (pekerjaan) dalam disiplin (modul)__

(nama disiplin ilmu (modul))

pada topik __________________________________________________________________________

_____

	_______________________	______________________________

Arah/spesialisasi, profil/spesialisasi:

___________ _________________________________________________________________

kode arah nama arah (khusus)

________________________________________________________________________________

nama profil (spesialisasi)

Penunjukan proyek kursus (pekerjaan) ___________ Kelompok ________

Rostov-on-Don

Lampiran B

KEMENTERIAN PENDIDIKAN DAN ILMU PENGETAHUAN FEDERASI RUSIA

LEMBAGA PENDIDIKAN PROFESIONAL TINGGI ANGGARAN NEGARA FEDERAL

"UNVERSITAS TEKNIK NEGARA DON" (DSTU)

Fakultas ___________________________________________

(nama fakultas)

Departemen ____________________________________________________________________________

(nama departemen)

Kepala departemen "______________"

____________ ________________

CATATAN PENJELASAN

untuk proyek kelulusan (pekerjaan) dengan topik:

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

			__________________________
	(tanda tangan, tanggal)
Penunjukan proyek kelulusan ________________				Kelompok ______________
Arah (khusus) ___________		___________________________________
				(Nama)
Manajer proyek (pekerjaan).			____________________________
	(tanda tangan, tanggal)			(posisi, I.O.F.)
Konsultan menurut bagian:
_______________________________				_____________________
(nama bagian)		(tanda tangan, tanggal)		(posisi, I.O.F.)
_______________________________				_____________________
(nama bagian)		(tanda tangan, tanggal)		(posisi, I.O.F.)
Kontrol standar				_____________________
		(tanda tangan, tanggal)		(posisi, I.O.F.)

Rostov-on-Don

Aturan pendaftaran dan persyaratan isi proyek kursus (karya) dan karya kualifikasi akhir – 09.1

Gost 19.101-77

Grup T55

STANDAR INTERSTATE

Sistem dokumentasi program terpadu

JENIS PROGRAM DAN DOKUMEN PROGRAM

Sistem terpadu untuk dokumentasi program. Jenis program dan dokumen program

MKS 35.080

Tanggal perkenalan 1980-01-01

Dengan Resolusi Komite Standar Negara Dewan Menteri Uni Soviet tertanggal 20 Mei 1977 N 1268, tanggal pengenalan ditetapkan pada 01/01/80

EDISI (Januari 2010) dengan Amandemen No. 1, disetujui pada bulan Juni 1981 (IUS 9-81).


Standar ini menetapkan jenis program dan dokumen program untuk komputer, kompleks dan sistem, terlepas dari tujuan dan ruang lingkupnya.

Standar ini sepenuhnya sesuai dengan ST SEV 1626-79.

(Edisi Perubahan, Amandemen No. 1).

1. JENIS PROGRAM

1. JENIS PROGRAM

1.1. Program (menurut Gost 19781-90) dapat diidentifikasi dan digunakan secara mandiri dan (atau) sebagai bagian dari program lain.

1.2. Program dibagi menjadi beberapa jenis yang ditunjukkan pada Tabel 1.

Tabel 1

Jenis program	Definisi
Komponen	Suatu program yang dianggap sebagai keseluruhan, menjalankan fungsi yang lengkap dan digunakan secara mandiri atau sebagai bagian dari suatu kompleks
Kompleks	Suatu program yang terdiri dari dua atau lebih komponen dan (atau) kompleks yang menjalankan fungsi yang saling terkait, dan digunakan secara mandiri atau sebagai bagian dari kompleks lainnya

1.3. Dokumentasi yang dikembangkan untuk program dapat digunakan untuk implementasi dan transfer program ke media penyimpanan, serta untuk pembuatan produk perangkat lunak.

1.2, 1.3. (Edisi Perubahan, Amandemen No. 1).

2. JENIS DOKUMEN PROGRAM

2.1. Dokumen perangkat lunak mencakup dokumen yang berisi informasi yang diperlukan untuk pengembangan, produksi, pemeliharaan, dan pengoperasian program.

2.2. Jenis dokumen program dan isinya disajikan pada Tabel 2.

Meja 2

Jenis dokumen program
Spesifikasi	Komposisi program dan dokumentasinya
	Daftar perusahaan yang menyimpan dokumen program asli
Teks program	Merekam program dengan komentar yang diperlukan
Deskripsi Program	Informasi tentang struktur logis dan pengoperasian program
	Persyaratan yang harus diverifikasi saat menguji program, serta prosedur dan metode pengendaliannya
Tugas teknis	Tujuan dan ruang lingkup program, teknis, kelayakan dan persyaratan khusus untuk program, tahapan dan syarat pengembangan yang diperlukan, jenis pengujian
Catatan penjelasan	Diagram algoritma, gambaran umum tentang algoritma dan (atau) pengoperasian program, serta pembenaran keputusan teknis dan teknis-ekonomi yang diambil
Dokumen operasional	Informasi untuk memastikan berfungsinya dan pengoperasian program

2.3. Jenis dokumen operasional dan isinya disajikan pada Tabel 3.

Tabel 3

Jenis dokumen operasional
	Daftar dokumen operasional program
Membentuk	Ciri-ciri utama program, kelengkapan dan informasi tentang pengoperasian program
Deskripsi aplikasi	Informasi tentang tujuan program, ruang lingkup aplikasi, metode yang digunakan, kelas masalah yang harus diselesaikan, batasan penggunaan, konfigurasi minimum perangkat keras
	Informasi untuk memeriksa, memastikan berfungsinya dan menyesuaikan program untuk kondisi aplikasi tertentu
Panduan Pemrogram	Informasi untuk menggunakan program ini
Panduan operator	Informasi untuk memastikan prosedur komunikasi antara operator dan sistem komputer selama eksekusi program
Deskripsi bahasa	Deskripsi sintaksis dan semantik bahasa
	Informasi tentang penggunaan program pengujian dan diagnostik saat menyervis peralatan teknis

2.4. Tergantung pada metode implementasi dan sifat penerapannya, dokumen program dibagi menjadi asli, duplikat, dan salinan (GOST 2.102-68), dimaksudkan untuk pengembangan, pemeliharaan, dan pengoperasian program.

2.5. Jenis dokumen program yang dikembangkan pada berbagai tahap dan kodenya diberikan pada Tabel 4.

Tabel 4

Kode jenis dokumen	Tipe dokumen	Tahapan pengembangan
		Desain awal	Proyek teknis	Draf kerja
				komponen	kompleks
	Spesifikasi
	Daftar pemegang asli
	Teks program
	Deskripsi Program
	Daftar dokumen operasional
	Membentuk
	Deskripsi aplikasi
	Panduan Pemrogram Sistem
	Panduan Pemrogram
	Panduan operator
	Deskripsi bahasa
	Petunjuk Perawatan
	Program uji dan metodologi
	Catatan penjelasan
	Dokumen lainnya

Legenda:

- dokumen itu wajib;

- dokumen tersebut wajib untuk komponen yang dapat digunakan secara mandiri;

- kebutuhan pembuatan dokumen ditentukan pada tahap pengembangan dan persetujuan spesifikasi teknis;

- - dokumen belum dibuat.

2.2-2.5. (Edisi Perubahan, Amandemen No. 1).

2.6. Diperbolehkan menggabungkan jenis dokumen operasional tertentu (kecuali daftar dokumen operasional dan formulir). Kebutuhan untuk menggabungkan dokumen-dokumen ini ditunjukkan dalam spesifikasi teknis. Dokumen yang digabungkan diberi nama dan penunjukan salah satu dokumen yang digabungkan.

Dokumen yang digabungkan harus menentukan informasi yang harus disertakan dalam setiap dokumen yang digabungkan.

2.7. Pada tahap pengembangan dan persetujuan spesifikasi teknis, kebutuhan untuk menyusun spesifikasi teknis yang memuat persyaratan untuk produksi, pengendalian dan penerimaan program ditentukan.

Spesifikasi teknis dikembangkan pada tahap “Desain Terperinci”.

2.8. Kebutuhan untuk menyusun spesifikasi teknis untuk komponen yang tidak dimaksudkan untuk penggunaan mandiri, dan kompleks yang termasuk dalam kompleks lain, ditentukan berdasarkan kesepakatan dengan pelanggan.

(Diperkenalkan sebagai tambahan, Amandemen No. 1).



Teks dokumen elektronik
disiapkan oleh Kodeks JSC dan diverifikasi terhadap:
publikasi resmi
Sistem perangkat lunak terpadu
dokumentasi: Sat. gost. -
M.: Standartinform, 2010