rumah Waralaba Kerangka acuan yang disepakati disediakan oleh dimensi. Kerangka acuan: bagaimana melindungi diri dari kesalahan dan resiko

Kerangka acuan yang disepakati disediakan oleh dimensi. Kerangka acuan: bagaimana melindungi diri dari kesalahan dan resiko

Teks ini dibuat murni demi keberadaan tautan permanen, yang penulis sendiri, dan Anda semua, dapat kirimkan dengan aman ke pelanggan, kolega, kerabat, dan teman masa depan Anda dalam bentuk jawaban standar untuk pertanyaan: “Apakah saya memerlukan spesifikasi teknis Anda dan secara umum apa ini?"

Seperti kata pepatah - "bukannya seribu kata", karena setiap kali menginjili selama 4-5 jam di Skype tentang topik ini sudah melelahkan, dan kecenderungan global untuk menyelipkan omong kosong di bawah definisi "Kerangka Acuan" hanya meningkat selama bertahun-tahun.

Masalah

Faktanya adalah bahwa ketika ada format tertentu, serta definisi istilah yang jelas dan dapat dipahami, maka semua manipulasi dan penggantiannya untuk brief Anda sendiri, prototipe, kuesioner, deskripsi, dan aplikasi yang masuk dengan cepat, setidaknya, tidak profesional. Oleh karena itu, kami mulai dengan definisi ilmiah dari konsep kami:

Kerangka Acuan - dokumen awal untuk desain objek teknis (produk). TK menetapkan tujuan utama dari objek yang dikembangkan, yaitu spesifikasi, indikator kualitas dan persyaratan teknis dan ekonomi, resep untuk implementasi tahap-tahap pembuatan dokumentasi yang diperlukan (desain, teknologi, perangkat lunak, dll.) dan komposisinya, serta persyaratan khusus. Kerangka acuannya adalah dokumen legal - bagaimana aplikasi disertakan dalam kontrak antara pelanggan dan kontraktor untuk dilakukan pekerjaan desain dan merupakan dasarnya: menentukan prosedur dan kondisi kerja, termasuk tujuan, sasaran, prinsip, hasil yang diharapkan, dan tenggat waktu. Artinya, harus ada kriteria obyektif yang memungkinkan untuk menentukan apakah item pekerjaan tertentu telah dilakukan atau belum. Semua perubahan, penambahan dan klarifikasi kata-kata TK harus disetujui oleh pelanggan dan disetujui olehnya. Ini juga diperlukan karena dalam kasus deteksi dalam proses pemecahan tugas proyek ketidakakuratan atau ketidakakuratan data awal, menjadi perlu untuk menentukan tingkat kesalahan masing-masing pihak yang berpartisipasi dalam pengembangan, distribusi kerugian yang terjadi dalam hubungan ini. Penugasan teknis, sebagai istilah di bidang teknologi informasi, adalah dokumen penting secara hukum yang berisi informasi lengkap yang diperlukan untuk menetapkan tugas bagi pelaksana untuk mengembangkan, mengimplementasikan, atau mengintegrasikan produk perangkat lunak, sistem informasi, situs web, portal, atau layanan TI lainnya.

Kami menerjemahkan ke dalam bahasa yang bisa dimengerti

1) Penugasan Teknis - menetapkan tugas. Ini berarti harus pergi sebelum prototipe, sketsa, tes, proyek desain, karena setiap peta pikiran, diagram aliran data, arsitektur sudah kinerja tugas tertentu, ini adalah jawaban dari sebuah pertanyaan. Dan sebelum pertanyaan itu sendiri belum ditanyakan, dirumuskan dan ditandatangani oleh semua pihak - setiap jawaban akan menjadi salah apriori, bukan? Jadi, awal dari pekerjaan apa pun pada proyek apa pun adalah pernyataan masalah, bukan pencarian panik untuk sketsa dari selusin opsi untuk menyelesaikannya.

2) Sebenarnya, yang baru secara logis mengikuti dari paragraf pertama - teks TK itu sendiri harus dimulai dengan bab "Sasaran dan Sasaran", yang dengan jelas merumuskan tujuan bisnis apa yang dikejar oleh upaya selanjutnya untuk meningkatkan entropi di dunia ini. Tugas tanpa tujuan yang tidak menyelesaikan masalah apa pun, tidak mencapai apa pun dan dilakukan "karena bosan" - tidak secara resmi dianggap sebagai Tugas Teknis, dan sejak saat itu berstatus "selembar kertas biasa".

3) Bagaimana Anda memahami apakah konsep desain yang diusulkan atau prototipe interaktif, atau bahkan situs web siap pakai, dapat menyelesaikan masalah bisnis di atas? Tidak ada yang bisa dilakukan, kita harus kembali ke definisi lagi: “menentukan… hasil yang diharapkan dan kerangka waktu untuk implementasi. Artinya, harus ada kriteria obyektif yang memungkinkan untuk menentukan apakah suatu item pekerjaan tertentu telah diselesaikan atau belum. " Artinya, tidak ada TK tanpa indikator terukur yang jelas dalam rubel, detik, ton-kilometer atau derajat Celcius. Sebuah kaleng singkat, atau prototipe, atau selembar kertas absurd lainnya, tetapi bukan Tugas Teknis.

Dari sini kita menyimpulkan bahwa di TK ini harus ada bab "Prosedur penerimaan dan evaluasi", ketika indikator yang sama diambil, diukur, dan para pihak bersalaman atau mengirim proyek untuk dikerjakan ulang.

4) Penugasan teknis harus konsisten dengan rencana bisnis umum pelanggan, dengan strategi pengembangan bisnis dan analisis segmen pasar. Ini semua yang akan memungkinkan Anda untuk menetapkan tujuan yang tepat, untuk menyimpulkan metrik yang akurat, yang menurutnya Anda akan cukup melakukan penerimaan produk informasi jadi. Kurangnya rencana bisnis pelanggan secara otomatis menjamin pelaksanaan Kerangka Acuan yang tidak profesional.

Apakah studio outsourcing mengetahui tujuan bisnis dan kinerja bisnis yang terukur lebih baik daripada pemiliknya? Jelas tidak, artinya TK yang benar harus ditulis oleh perwakilan Pelanggan, dan bukan oleh karyawan Kontraktor. Tidak masuk akal ketika seorang pelaku menetapkan tugas untuk dirinya sendiri, kemudian menemukan cara untuk mengevaluasinya, dan pada akhirnya ia memberi dirinya nilai akhir untuk pekerjaan yang telah diselesaikan. Idealnya, "inisiatif" seperti itu tidak boleh, meskipun dalam praktiknya inilah yang terjadi di mana-mana, akibatnya Penugasan Teknis tidak menyediakan membutuhkan bantuan proyek, terlalu sering menjadi dokumen palsu. Jangan lakukan seperti ini.

5) Setiap perubahan TK yang sudah jadi harus mengeluarkan biaya. Tidak mungkin untuk mengedit Konstitusi Proyek Anda secara gratis dan tanpa akhir hanya karena salah satu pihak berubah pikiran, tidak cukup tidur, tiba-tiba memutuskan untuk menabung, dll. Harga setiap perubahan di TK juga harus dinyatakan dengan jelas sebelumnya di bab terkait.

Ngomong-ngomong, secara teori, setiap perubahan desain atau perubahan daftar halaman atau fungsi harus memiliki harga yang jelas, yang dibayar di muka, sebelum perubahan dilakukan. Secara pribadi, saya mengusulkan untuk memperkirakan revisi TK yang disetujui sebesar 30% dari total anggaran proyek, tetapi Anda dapat melakukan sebaliknya.

Apakah perlu disebutkan bahwa hanya perlu menunjukkan sebelumnya waktu dan total anggaran untuk pembangunan, serta daftar semua sumber daya dan batasan yang ada? - Tidak, itu akan terlalu jelas.

Jadi: Apa yang kita lakukan? Untuk apa? Bagaimana kita memahami apa yang kita lakukan? Berapa biaya setiap pivot? - jawaban atas semua pertanyaan yang tertulis di selembar kertas adalah "peluru perak" yang mampu mengeluarkan proyek yang paling gagal sekalipun.

Kontrol pertanyaan

Dan di sini saya akan mencantumkan jawaban atas pertanyaan yang paling sering diajukan dari pelanggan:

1) Jadi, bisakah ada GOST resmi untuk penulisan Tugas Teknis? - Ya, bahkan sedikit.

2) Apa, Penugasan Teknis tidak menyertakan deskripsi halaman yang diperlukan, jumlah tombol, pustaka yang digunakan, pedoman, dll.? - Tidak ada TK itu sendiri, tetapi semua ini dapat Anda letakkan di Lampiran, tentunya menyesuaikan semua ini dengan tujuan di atas, batasan dan cara penilaian lebih lanjut hasil yang dicapai... Posting setidaknya semua konten yang akan datang, setidaknya deskripsi karakter yang umum - tetapi bukan pernyataan masalah yang jelas, tetapi setelahnya.

3) Jadi mungkin saya tidak membutuhkannya? - Mungkin saat ini ribuan situs dibuat tanpa TK sama sekali, sama seperti ribuan orang di dunia yang hidup indah, buta sejak lahir. Tetapi jika Anda ingin melihat kemana tujuan Anda secara umum, membuat keputusan secara sadar dan mengevaluasi hasil yang diperoleh secara mandiri, maka Anda tidak dapat melakukannya tanpa TK.

4) Jadi Anda dan Wikipedia menulis bahwa spesifikasi teknis dibuat oleh pelanggan. Tapi saya tidak tahu bagaimana / saya tidak punya waktu / saya hanya tidak ingin melakukannya sendiri. Bagaimana menjadi? - Serahkan pengembangan spesifikasi teknis kepada pihak ketiga yang sepenuhnya memahami bisnis Anda, tugasnya, audiens target, dan kebutuhannya, dan pada saat yang sama mengetahui semua tahapan pengembangan web secara menyeluruh. Pihak ketiga ini akan menjadi semacam "notaris web", yaitu, penjamin bahwa kontraktor tidak akan meremehkan indikator yang Anda butuhkan atau menunda tenggat waktu, dan bahwa pelanggan akan menetapkan metrik yang dapat dicapai dan pada penerimaan akhir tidak akan mengevaluasi produk yang dibuat secara subjektif, mengubah rekaman sebelumnya Persyaratan.

5) Dan bagaimana jika TK adalah dokumen resmi, maka saya dapat menuntut agen outsourcing, tidak membayarnya, memaksanya untuk mengulang semuanya untuk kesepuluh kalinya? - Jika dokumen disusun dengan benar, tujuan dan metodologi untuk menilai pencapaian mereka ditunjukkan; jika dokumen ditandatangani oleh para pihak dan disebutkan dalam Perjanjian (Spesifikasi Teknis itu sendiri bukanlah perjanjian) - tentu saja Anda bisa. Tetapi dengan brief biasa, prototipe, tata letak seni-kreatif, kesepakatan Aman di FL - tidak lagi.

6) Saya diberitahu bahwa pekerjaan akan dilakukan menurut Scrum, atau Ajail; yang berarti saya tidak lagi membutuhkan TK kuno. Ini benar? - Nilailah untuk diri Anda sendiri: mereka menyebut Anda kata yang tidak bisa dipahami, jelas sesuatu yang menyamar, dan sekarang, atas dasar istilah yang tidak dikenal, mereka menawarkan untuk meninggalkan dokumen yang kompeten secara hukum yang berisi tujuan dan metrik. Agile sendiri tidak dapat menetapkan tujuan apa pun seperti "untuk mencapai setidaknya 10.000 kunjungan pada akhir tahun" atau "untuk mencapai lebih dari 25 pesanan dari situs dalam sebulan", ini hanya cara mengadakan rapat dan organisasi baru karyawan yang ceroboh. Pikirkan beberapa kali: "Bukankah hal itu didorong oleh Anda?" Faktanya, TK profesional tidak dapat merugikan Scrum bermodel baru, tetapi bantuan adalah suatu keharusan.

Saya sering ditanya: "Bagaimana cara mengembangkan spesifikasi teknis untuk sistem otomatis dengan benar?" Tema pengembangan spesifikasi teknis terus menerus dibahas di berbagai forum. Pertanyaan ini sangat luas sehingga tidak mungkin menjawab secara singkat. Jadi saya memutuskan untuk menulis artikel panjang tentang topik ini. Dalam proses mengerjakan artikel, saya menyadari bahwa tidak akan berhasil untuk memasukkan semuanya ke dalam satu artikel, karena itu akan menjadi di bawah 50 halaman dan memutuskan untuk membaginya menjadi 2 bagian:

Di bagian pertama " Pengembangan spesifikasi teknis. Apa itu, mengapa dibutuhkan, di mana harus memulai dan bagaimana seharusnya tampilannya? " Saya akan mencoba menjawab secara rinci pertanyaan topik, mempertimbangkan struktur dan tujuan Kerangka Acuan Kerja, serta memberikan beberapa rekomendasi tentang rumusan persyaratan.
Bagian kedua " Pengembangan spesifikasi teknis. Bagaimana Merumuskan Persyaratan? " akan sepenuhnya dikhususkan untuk mengidentifikasi dan merumuskan persyaratan untuk sistem Informasi.

Pertama, Anda perlu mencari tahu pertanyaan apa yang benar-benar menarik bagi mereka yang bertanya "Bagaimana cara mengembangkan spesifikasi teknis?" Faktanya adalah bahwa pendekatan pengembangan spesifikasi teknis juga akan sangat bergantung pada tujuan dilakukannya, dan juga oleh siapa itu akan digunakan. Opsi apa yang saya bicarakan:

Sebuah organisasi komersial memutuskan untuk menerapkan sistem otomatis. Itu tidak memiliki layanan TI sendiri dan memutuskan untuk melakukan hal berikut: Orang yang tertarik harus mengembangkan Kerangka Acuan dan menyerahkannya untuk pengembangan organisasi pihak ketiga;
Sebuah organisasi komersial memutuskan untuk menerapkan sistem otomatis. Ia memiliki layanan IT-nya sendiri. Kami memutuskan untuk melakukan ini: mengembangkan Kerangka Acuan, lalu menyepakati antara layanan TI dan pemangku kepentingan, dan menerapkannya sendiri;
Badan pemerintah memutuskan untuk memulai proyek TI. Semuanya sangat berlumpur di sini, banyak formalitas, sogokan, pemotongan, dll. Saya tidak akan mempertimbangkan opsi ini dalam artikel ini.
Perusahaan IT bergerak dalam layanan untuk pengembangan dan / atau implementasi sistem otomatis. Ini adalah kasus tersulit, karena Anda harus bekerja dalam berbagai kondisi:
Klien memiliki spesialisnya sendiri dengan pandangan mereka sendiri, dan mereka membuat persyaratan khusus untuk Kerangka Acuan;
- Kerangka acuan dikembangkan untuk pengembang kami sendiri (klien tidak peduli);
- Kerangka acuan dikembangkan untuk transfer ke kontraktor (yaitu sekelompok pemrogram yang berlokasi di luar staf perusahaan, atau spesialis individu);
- Ada kesalahpahaman antara perusahaan dan klien dalam pertanyaan tentang hasil yang diperoleh, dan perusahaan berulang kali mengajukan pertanyaan: "Bagaimana sebaiknya Kerangka Acuan dikembangkan?" Mungkin kasus terakhir tampak seperti sebuah paradoks, tetapi itu benar.
- Pilihan lain yang kurang umum juga dimungkinkan;

Saya pikir sekarang pembaca harus memiliki beberapa pertanyaan:

Mengapa tidak mungkin mengembangkan Kerangka Acuan yang selalu sama ?;
Apakah ada standar, metode, rekomendasi? Dimana saya bisa mendapatkannya?
Siapa yang harus mengembangkan Kerangka Acuan? Haruskah orang ini memiliki pengetahuan khusus?
Bagaimana memahami Kerangka Acuan ditulis dengan baik atau tidak?
Atas biaya siapa itu harus dikembangkan, dan apakah itu perlu?

Daftarnya bisa tidak ada habisnya. Saya berbicara dengan sangat percaya diri karena saya telah masuk pengembangan profesional perangkat lunak, dan pertanyaan tentang Kerangka Acuan muncul di tim pengembangan mana pun yang Anda ajak kerja sama. Alasannya berbeda. Mengangkat topik pengembangan Kerangka Acuan, saya sangat menyadari bahwa saya tidak dapat menyajikannya 100% untuk semua orang yang tertarik dengan topik tersebut. Tapi, saya akan mencoba, seperti yang mereka katakan, "taruh semuanya di rak." Mereka yang sudah familiar dengan artikel saya tahu bahwa saya tidak menggunakan "copy-paste" dari karya orang lain, saya tidak mencetak ulang buku orang lain, saya tidak mengutip standar multi-halaman dan dokumen lain yang Anda sendiri dapat temukan di Internet, menganggapnya brilian. pikiran. Cukup mengetik di mesin pencari "Bagaimana mengembangkan tugas teknis" dan Anda dapat membaca banyak hal menarik, tetapi, sayangnya, berkali-kali berulang. Biasanya, mereka yang suka menjadi pintar di forum (coba cari semuanya!) Tidak pernah melakukan Kerangka Acuan yang masuk akal sendiri, dan terus menerus mengutip rekomendasi GOST di masalah ini... Dan mereka yang benar-benar serius tentang masalah ini biasanya tidak punya waktu untuk duduk di forum. Ngomong-ngomong, kami juga akan membicarakan GOST. Di tahun-tahun yang berbeda dalam pekerjaan saya, saya telah melihat banyak pilihan dokumentasi teknisdisusun oleh ahli individu dan tim terkemuka dan perusahaan konsultan... Kadang-kadang saya juga melakukan kegiatan semacam ini: Saya menyisihkan waktu untuk diri saya sendiri dan mencari informasi tentang topik yang menarik dari sumber yang tidak biasa (seperti kecerdasan yang kecil). Akibatnya, saya harus melihat dokumentasi monster seperti GazProm, Kereta Api Rusia, dan banyak perusahaan menarik lainnya. Tentu saja, saya mematuhi kebijakan privasi, terlepas dari kenyataan bahwa dokumen-dokumen ini datang kepada saya dari sumber yang tersedia untuk umum atau konsultan yang tidak bertanggung jawab (menyebarkan informasi di Internet). Oleh karena itu, saya langsung mengatakan: Saya tidak membagikan informasi rahasia milik perusahaan lain, terlepas dari sumber kemunculannya (etika profesional).

Apa kerangka acuannya?

Hal pertama yang akan kita lakukan sekarang adalah mencari tahu jenis binatang apa ini, "Kerangka Acuan".

Ya, memang ada GOST dan standar di mana upaya dilakukan untuk mengatur bagian aktivitas ini (pengembangan perangkat lunak). Dahulu kala, semua GOST ini relevan dan digunakan secara aktif. Sekarang ada pendapat berbeda tentang relevansi dokumen-dokumen ini. Beberapa orang berpendapat bahwa GOST dikembangkan oleh orang-orang yang berpandangan jauh ke depan dan masih relevan. Yang lain mengatakan bahwa mereka sudah ketinggalan zaman. Mungkin seseorang sekarang berpikir bahwa kebenaran ada di tengah-tengah. Saya akan menjawab dengan kata-kata Goethe: “Mereka mengatakan bahwa di antara dua pendapat yang berlawanan ada kebenaran. Sama sekali tidak! Ada masalah di antara mereka. " Jadi, tidak ada kebenaran di antara pendapat ini. Karena GOST tidak mengungkapkan masalah praktis pembangunan modern, dan mereka yang mengkritiknya tidak menawarkan alternatif (spesifik dan sistemik).

Perhatikan bahwa GOST secara jelas bahkan tidak memberikan definisi, ia hanya mengatakan: “Spesifikasi teknis untuk PLTN adalah dokumen utama yang mendefinisikan persyaratan dan prosedur untuk pembuatan (pengembangan atau modernisasi - pembuatan lebih lanjut) dari sistem otomatis, yang sesuai dengan pengembangan AU dan penerimaannya saat commissioning menjadi tindakan ”.

Jika seseorang tertarik dengan GOST yang saya bicarakan, maka ini dia:

GOST 2.114-95 Sistem terpadu untuk dokumentasi desain. Kondisi teknis;
GOST 19.201-78 Sistem terpadu dokumentasi program... Tugas teknis. Persyaratan konten dan desain;
GOST 34.602-89 Teknologi Informasi... Set standar untuk sistem otomatis. Kerangka acuan untuk pembuatan sistem otomatis.

Definisi yang jauh lebih tepat disajikan di Wikipedia (benar tentang TK secara umum, dan tidak hanya untuk perangkat lunak): Tugas teknis - ini adalah dokumen desain awal teknis obyek. Tugas teknis menetapkan tujuan utama dari objek yang dikembangkan, teknis dan karakteristik taktis dan teknis, indikator kualitas dan persyaratan teknis dan ekonomi, instruksi untuk implementasi tahap-tahap yang diperlukan untuk membuat dokumentasi (desain, teknologi, perangkat lunak, dll.) dan komposisinya, serta persyaratan khusus. Tugas sebagai dokumen sumber untuk membuat sesuatu yang baru ada di semua bidang kegiatan, berbeda dalam nama, konten, urutan pendaftaran, dll. (Misalnya, tugas proyek dalam konstruksi, tugas tempur, pekerjaan rumah, kontrak untuk karya sastra, dll.). dll.) "

Jadi, sebagai berikut dari definisi tersebut, tujuan utama dari Kerangka Acuan adalah untuk merumuskan persyaratan untuk objek yang dikembangkan, dalam kasus kami untuk sistem otomatis.

Tepat sekali, tapi unik. Waktunya telah tiba untuk menangani hal utama: memilah-milah semuanya "di rak", seperti yang dijanjikan.

Apa yang perlu Anda ketahui tentang persyaratannya? Penting untuk dipahami dengan jelas bahwa semua persyaratan harus dibagi berdasarkan jenis dan properti. Sekarang kita akan belajar bagaimana melakukan ini. GOST akan membantu kami memisahkan persyaratan berdasarkan jenis. Daftar jenis persyaratan yang disajikan di sana merupakan contoh yang baik tentang jenis persyaratan yang harus dipertimbangkan. Sebagai contoh:

Persyaratan fungsionalitas;
Persyaratan hak keamanan dan akses;
Persyaratan kualifikasi personel;
…. Dll Anda dapat membaca tentang mereka di GOST yang disebutkan (dan di bawah ini saya juga akan membahasnya secara lebih rinci).

Saya pikir jelas bagi Anda bahwa faktor kunci untuk Kerangka Acuan yang sukses justru adalah persyaratan fungsionalitas yang dirumuskan dengan baik. Untuk persyaratan inilah sebagian besar karya dan teknik yang saya bicarakan dikhususkan. Persyaratan fungsionalitas adalah 90% dari kompleksitas pekerjaan pengembangan Kerangka Acuan. Sisanya seringkali merupakan "kamuflase" yang diterapkan pada persyaratan ini. Jika persyaratannya dirumuskan dengan buruk, maka betapa indahnya kamuflase yang tidak boleh Anda pakai, proyek yang sukses tidak akan berfungsi. Ya, secara formal semua persyaratan akan terpenuhi (menurut GOST J), TK sudah dikembangkan, disetujui dan ditandatangani, uang sudah diterima untuk itu. Terus? Dan kemudian hal yang paling menarik akan dimulai: apa yang harus dilakukan? Jika ini adalah proyek di Tatanan Negara, maka tidak ada masalah - ada anggaran sedemikian rupa sehingga tidak akan masuk ke kantong mana pun, dalam proses pelaksanaan (jika ada) semuanya akan diklarifikasi. Ini persis bagaimana sebagian besar anggaran proyek untuk Pesanan Negara dipotong (mereka menyalakan "TZ", mereka menggelontorkan sepuluh juta, tetapi proyek itu tidak selesai. Semua formalitas diikuti, tidak ada pihak yang bersalah, mobil baru di dekat rumah. Cantik!). Tapi kita sedang membicarakannya organisasi komersialdimana uang diperhitungkan, dan hasilnya berbeda. Oleh karena itu, mari kita hadapi yang utama, bagaimana mengembangkan kerangka Acuan yang berguna dan berfungsi.

Saya mengatakan tentang jenis persyaratan, tetapi bagaimana dengan properti? Jika jenis persyaratan dapat berbeda (tergantung pada tujuan proyek), maka dengan properti semuanya lebih sederhana, ada 3 di antaranya:

Persyaratannya harus bisa dimengerti;
Persyaratannya harus spesifik;
Persyaratannya harus diuji;

Selain itu, properti terakhir tidak mungkin tanpa dua sebelumnya, yaitu. adalah semacam "tes lakmus". Jika hasil pemenuhan persyaratan tidak dapat diuji, maka tidak jelas atau tidak spesifik. Pikirkan tentang itu. Dalam kepemilikan ketiga sifat persyaratan inilah keterampilan dan profesionalisme terletak. Padahal, semuanya sangat sederhana. Saat Anda mengetahuinya.

Dalam hal ini, cerita tentang Kerangka Acuan itu dapat diselesaikan dan beralih ke hal utama: bagaimana merumuskan persyaratan. Tapi tidak semuanya secepat itu. Ada yang sangat lain poin penting:

dalam bahasa apa (dalam hal kompleksitas pemahaman) tugas teknis harus ditulis?
Haruskah spesifikasi dari berbagai fungsi, algoritma, tipe data dan hal-hal teknis lainnya dijelaskan di dalamnya?
Dan apakah desain teknis itu, yang juga disebutkan dalam GOSTs, dan bagaimana kaitannya dengan Kerangka Acuan?

Ada hal yang sangat berbahaya dalam menjawab pertanyaan-pertanyaan ini. Itulah mengapa sering muncul perselisihan tentang kecukupan atau kurangnya perincian persyaratan yang diperlukan, tentang kejelasan dokumen oleh Pelanggan dan Kontraktor, tentang redundansi, format presentasi, dll. Dan di manakah batas antara Kerangka Acuan dan Desain Teknis?

Tugas teknis adalah dokumen berdasarkan persyaratan yang dirumuskan dalam bahasa yang dapat dimengerti (umum, akrab) bagi Pelanggan. Pada saat yang sama, terminologi industri yang dimengerti oleh Pelanggan dapat dan harus digunakan. Tidak boleh ada pengikatan pada spesifikasi teknis implementasi. Itu. pada tahap TK, pada prinsipnya tidak masalah di platform mana persyaratan ini akan diterapkan. Namun ada pengecualian. Jika kita berbicara tentang implementasi sistem berdasarkan produk perangkat lunak yang ada, maka tautan semacam itu dapat terjadi, tetapi hanya pada tingkat formulir layar, formulir laporan, dll. Klarifikasi dan perumusan persyaratan, serta pengembangan Kerangka Acuan harus analis bisnis.Dan tentu saja bukan seorang programmer (kecuali dia menggabungkan peran ini dalam dirinya sendiri, ini terjadi). Itu. orang ini harus berbicara dengan Pelanggan dalam bahasa bisnisnya.

Proyek teknis adalah dokumen yang ditujukan untuk pelaksanaan teknis dari persyaratan yang dirumuskan dalam Kerangka Acuan Kerja. Dokumen ini menjelaskan struktur data, pemicu dan prosedur tersimpan, algoritme, dan hal lain yang diperlukan. teknisi... Pelanggan sama sekali tidak perlu mempelajari hal ini (dia mungkin tidak memahami persyaratan tersebut). Desain teknis membuatnya Arsitek sistem(Di sini, cukup normal untuk menggabungkan peran ini dengan seorang programmer). Lebih tepatnya, sekelompok spesialis AO dipimpin oleh seorang arsitek. Semakin besar proyeknya, semakin banyak orang yang mengerjakan Kerangka Acuan.

Apa yang kita miliki dalam praktik? Sangat lucu untuk melihat ketika sutradara diminta untuk mendapatkan persetujuan oleh Kerangka Acuan, yang penuh dengan terminologi teknis, deskripsi tipe data dan nilainya, struktur database, dll. Dia, tentu saja, mencoba untuk memahami, karena dia perlu menegaskan, mencoba menemukan kata-kata yang akrab yang tersirat dan tidak kehilangan rantai persyaratan bisnis. Apakah ini situasi yang familiar? Dan bagaimana ini berakhir? Biasanya, TK tersebut disetujui, kemudian dilaksanakan, dan dalam 80% kasus kemudian tidak sesuai sama sekali dengan fakta pekerjaan yang dilakukan, karena mereka memutuskan untuk berubah, banyak membuat ulang, salah paham, berpikir salah, dll. dll. Dan kemudian seri tentang pengiriman pekerjaan dimulai. “Tapi ini bukan cara yang kita butuhkan,” tapi “ini tidak akan berhasil untuk kita,” “ini terlalu sulit,” “ini tidak nyaman,” dll. Terdengar familiar? !! Itu tidak asing bagi saya, saya harus mengisi kerucut pada waktunya.

Jadi apa yang kita miliki dalam praktik? Dalam praktiknya, kami memiliki batas kabur antara Kerangka Acuan dan Desain Teknis. Dia mengapung di antara TK dan TP dalam berbagai bentuk. Dan itu buruk. Dan ternyata demikian karena perkembangan budaya menjadi lemah. Hal ini sebagian disebabkan oleh kompetensi spesialis, sebagian karena keinginan untuk mengurangi anggaran dan tenggat waktu (bagaimanapun juga, dokumentasi membutuhkan waktu lama - ini adalah fakta). Ada faktor penting lain yang mempengaruhi penggunaan Desain Teknis sebagai dokumen terpisah: perkembangan dana yang pesat perkembangan yang cepatserta metodologi pengembangan. Tetapi ini adalah cerita terpisah, saya akan mengatakan beberapa kata tentang ini di bawah.

Poin kecil tapi penting lainnya. Terkadang Kerangka Acuan merupakan bagian kecil dari persyaratan, sederhana dan dapat dimengerti. Misalnya, untuk mempersempit pencarian objek menurut beberapa kondisi, menambahkan kolom ke laporan, dll. Pendekatan ini cukup dibenarkan, mengapa mempersulit hidup. Tetapi ini digunakan tidak pada proyek besar, tetapi pada perbaikan kecil. Saya akan mengatakan ini lebih dekat dengan pemeliharaan produk perangkat lunak. Dalam hal ini, solusi teknis khusus untuk penerapan persyaratan dapat dijelaskan dalam Kerangka Acuan. Misalnya, "Membuat ini dan itu perubahan dalam algoritma ini dan itu," menunjukkan prosedur tertentu dan perubahan khusus untuk pemrogram. Ini adalah kasus ketika batas antara Kerangka Acuan dan Proyek Teknis benar-benar terhapus, karena tidak ada kelayakan ekonomi untuk menyebarkan dokumen jika tidak diperlukan, dan dokumen yang berguna dibuat. Dan itu benar.

Apakah Anda sama sekali membutuhkan tugas teknis? Bagaimana dengan Desain Teknis?

Apakah saya kepanasan? Apakah ini mungkin, tanpa Kerangka acuan? Bayangkan itu mungkin (lebih tepatnya, itu terjadi), dan pendekatan ini memiliki banyak pengikut, dan jumlah mereka meningkat. Biasanya, setelah spesialis muda membaca buku tentang Scrum, Agile, dan teknologi lain yang berkembang pesat. Sebenarnya, ini adalah teknologi yang luar biasa, dan berhasil, hanya saja mereka tidak mengatakan secara harfiah "tidak perlu melakukan spesifikasi teknis". Mereka mengatakan "sedikit dokumen", terutama yang tidak perlu, lebih dekat dengan Pelanggan, lebih spesifik dan lebih cepat ke hasilnya. Tetapi tidak ada yang membatalkan fiksasi persyaratan, dan itu dengan jelas dinyatakan di sana. Di sanalah persyaratan ditetapkan berdasarkan tiga properti luar biasa yang saya bicarakan di atas. Hanya saja beberapa orang memiliki kesadaran yang terstruktur sehingga jika sesuatu dapat disederhanakan, mari kita sederhanakan menjadi tidak ada sama sekali. Seperti yang dikatakan Einstein " Buat sesederhana mungkin, tetapi tidak sesederhana mungkin. " ... Kata-kata emas cocok untuk semuanya. Yang seperti itu Tugas teknis itu perlu, jika tidak, Anda tidak akan melihat proyek yang berhasil. Pertanyaan lainnya adalah bagaimana menulis dan apa yang harus dimasukkan. Mengingat metodologi perkembangan pesat, Anda hanya perlu fokus pada persyaratan, dan semua "kamuflase" dapat dihapus. Pada prinsipnya, saya setuju dengan ini.

Bagaimana dengan Proyek Teknis? Dokumen ini sangat berguna dan tidak kehilangan relevansinya. Selain itu, seringkali tidak mungkin untuk hidup tanpanya. Terutama dalam hal pekerjaan pengembangan outsourcing, mis. atas dasar outsourcing. Jika ini tidak dilakukan, ada risiko mempelajari banyak hal baru tentang bagaimana seharusnya sistem yang Anda bayangkan. Haruskah Pelanggan mengenalnya? Jika dia mau, kenapa tidak, tapi tidak perlu memaksa dan menyetujui dokumen ini, itu hanya akan menahan dan mengganggu pekerjaan. Hampir tidak mungkin merancang sistem hingga detail terkecil. Dalam hal ini, Anda harus terus melakukan perubahan pada Desain Teknis, yang membutuhkan banyak waktu. Dan jika organisasi sangat birokratis, maka secara umum, tinggalkan semua saraf di sana. Justru tentang pengurangan jenis desain inilah yang kita bicarakan dalam metodologi modern perkembangan pesat, yang saya sebutkan di atas. Omong-omong, semuanya didasarkan pada XP klasik (pemrograman ekstrim) - sebuah pendekatan yang sudah berusia sekitar 20 tahun. Jadi buatlah Kerangka Acuan yang berkualitas tinggi, dapat dimengerti oleh Pelanggan, dan gunakan Desain Teknis sebagai dokumen internal untuk hubungan antara arsitek sistem dan pemrogram.

Detail menarik tentang desain teknis: beberapa alat pengembangan yang didasarkan pada prinsip orientasi subjek (seperti 1C dan yang serupa) mengasumsikan bahwa desain (artinya proses pendokumentasian) diperlukan hanya di area yang sangat kompleks di mana diperlukan interaksi antara seluruh subsistem. Dalam kasus yang paling sederhana, misalnya, untuk membuat buku referensi, dokumen, persyaratan bisnis yang dirumuskan dengan benar saja sudah cukup. Ini dibuktikan dengan strategi bisnis platform ini dalam hal pelatihan spesialis. Jika Anda melihat tiket ujian seorang spesialis (inilah namanya, dan bukan "programmer"), maka Anda akan melihat bahwa hanya ada persyaratan bisnis, dan bagaimana menerapkannya dalam bahasa pemrograman adalah tugas spesialis. Itu. bagian dari tugas yang dirancang untuk diselesaikan oleh Proyek Teknis, spesialis harus menyelesaikan "di kepala" (kita berbicara tentang tugas dengan kompleksitas menengah), dan di sini dan sekarang, mengikuti standar pengembangan dan desain tertentu, yang lagi-lagi dibentuk oleh 1C untuk platformnya. Dengan demikian, dari dua dokter spesialis yang hasil kerjanya terlihat sama, yang satu dinyatakan lulus, dan yang lainnya tidak bisa, karena sangat melanggar standar pembangunan. Artinya, para spesialis harus memiliki kualifikasi sedemikian rupa sehingga mereka dapat merancang tugas-tugas khas mereka sendiri, tanpa melibatkan arsitek sistem. Dan pendekatan ini berhasil.

Mari kita lanjutkan meneliti pertanyaan: "Persyaratan apa yang harus dimasukkan dalam Kerangka Acuan?"

Perumusan kebutuhan sistem informasi. Struktur Kerangka Acuan

Mari kita putuskan sekarang juga: kita akan berbicara secara khusus tentang perumusan persyaratan untuk sistem informasi, yaitu. dengan asumsi bahwa pekerjaan pengembangan persyaratan bisnis, formalisasi proses bisnis, dan semua pekerjaan konsultasi sebelumnya telah diselesaikan. Tentu saja, beberapa penyempurnaan bisa dilakukan pada tahap ini, tapi justru penyempurnaan. Proyek otomasi itu sendiri tidak memecahkan masalah bisnis - ingatlah ini. Ini adalah aksioma. Untuk beberapa alasan, beberapa eksekutif mencoba membantahnya, percaya bahwa jika mereka membeli program tersebut, maka pesanan akan datang dalam bisnis yang kacau balau. Tetapi aksioma tersebut juga merupakan aksioma yang tidak memerlukan bukti.

Seperti halnya aktivitas apa pun, perumusan persyaratan dapat (dan harus) dibagi menjadi beberapa tahap. Segala sesuatu ada waktunya. Ini adalah pekerjaan intelektual yang keras. Dan, jika dia memperlakukannya dengan perhatian yang tidak memadai, maka hasilnya akan sesuai. Menurut perkiraan ahli, biaya pengembangan Kerangka Acuan mungkin 30-50%. Saya juga sependapat. Meskipun 50 mungkin terlalu banyak. Bagaimanapun, Kerangka Acuan bukanlah dokumen terakhir yang dikembangkan. Toh harus ada juga desain teknisnya. Penyebaran ini disebabkan platform yang berbeda otomatisasi, pendekatan, dan teknologi yang digunakan oleh tim proyek dalam pengembangan. Misalnya, jika kita berbicara tentang pengembangan dalam bahasa klasik seperti C ++, maka seseorang tidak dapat melakukannya tanpa desain teknis yang terperinci. Jika kita berbicara tentang implementasi sistem pada platform 1C, maka situasi dengan desain agak berbeda, seperti yang kita lihat di atas (meskipun, saat mengembangkan sistem dari awal, dirancang sesuai dengan skema klasik).

Terlepas dari kenyataan bahwa pernyataan persyaratan adalah bagian utama Kerangka acuan, dan dalam beberapa kasus menjadi satu-satunya bagian dari Taman Kanak-Kanak, Anda harus memperhatikan fakta bahwa ini adalah dokumen penting, dan harus dibuat sesuai. Mulai dari mana? Pertama-tama, Anda harus mulai dengan kontennya. Buat konten Anda, lalu mulailah mengembangkannya. Secara pribadi, saya melakukan ini: pertama saya membuat sketsa konten, menjelaskan tujuan, semua informasi latar belakang, dan kemudian saya turun ke bagian utama - pernyataan persyaratan. Mengapa tidak sebaliknya? Saya tidak tahu, itu lebih nyaman bagi saya. Pertama, ini adalah bagian waktu yang jauh lebih kecil (dibandingkan dengan persyaratan), dan kedua, saat menjelaskan semua informasi pengantar, Anda mendengarkan hal utama. Nah, ini yang Anda suka. Seiring waktu, Anda akan mengembangkan template Kerangka Acuan Anda sendiri. Untuk memulainya, saya sarankan untuk mengambil persis seperti yang dijelaskan di GOST sebagai konten. Ini sangat cocok untuk konten! Kemudian kami mengambil dan mulai mendeskripsikan setiap bagian, tidak melupakan rekomendasi untuk kepatuhan pada tiga properti: kejelasan, konkret, dan dapat diuji. Mengapa saya begitu bersikeras tentang ini? Lebih lanjut tentang ini di bagian selanjutnya. Dan sekarang saya mengusulkan untuk melewati poin-poin TK yang direkomendasikan di GOST.

informasi Umum;
maksud dan tujuan menciptakan (mengembangkan) sistem;
karakteristik objek otomasi;
persyaratan sistem;
komposisi dan isi pekerjaan untuk membuat sistem;
prosedur untuk pengendalian dan penerimaan sistem;
persyaratan untuk komposisi dan konten pekerjaan pada persiapan objek otomasi untuk menjalankan sistem;
persyaratan dokumen;
sumber pengembangan.

Total ada 9 bagian yang masing-masing juga dibagi menjadi subbagian. Mari kita analisis mereka secara berurutan. Untuk memudahkan, saya akan menyajikan semuanya dalam bentuk tabel untuk setiap item.

Bagian 1. informasi umum.

Rekomendasi GOST
nama lengkap sistem dan nya simbol;	Semuanya jelas di sini: kami menulis apa yang akan disebut sistem, nama pendeknya
kode subjek atau kode kontrak (nomor);	Ini tidak relevan, tetapi Anda dapat menentukan jika diperlukan
nama perusahaan (asosiasi) pengembang dan pelanggan (pengguna) sistem dan detailnya;	menunjukkan siapa (organisasi mana) yang akan mengerjakan proyek. Anda juga dapat menentukan peran mereka. Anda dapat menghapus bagian ini sekaligus (agak formal).
daftar dokumen yang menjadi dasar pembuatan sistem, oleh siapa dan kapan dokumen-dokumen ini disetujui;	Informasi yang berguna. Di sini perlu ditunjukkan dokumentasi normatif dan referensi yang diberikan kepada Anda untuk membiasakan diri dengan bagian tertentu dari persyaratan
tanggal mulai dan akhir yang direncanakan untuk pembuatan sistem;	Permintaan tenggat waktu. Kadang-kadang mereka menulis tentang hal itu di TK, tetapi lebih sering hal-hal seperti itu dijelaskan dalam kontrak kerja
informasi tentang sumber dan prosedur pembiayaan pekerjaan;	Begitu juga seperti pada paragraf sebelumnya tentang timing. Lebih relevan untuk perintah pemerintah (untuk pegawai negeri)
prosedur pendaftaran dan presentasi kepada pelanggan hasil pekerjaan pada pembuatan sistem (bagian-bagiannya), pada pembuatan dan penyesuaian sarana individu (perangkat keras, perangkat lunak, informasi) dan perangkat lunak dan perangkat keras (perangkat lunak dan metodologis) kompleks sistem.	Saya tidak melihat perlunya poin ini, karena persyaratan untuk dokumentasi dibuat secara terpisah, dan sebagai tambahan, ada bagian "Prosedur untuk kontrol dan penerimaan" yang terpisah dari sistem.

Bagian 2. maksud dan tujuan penciptaan (pengembangan) sistem.

Rekomendasi GOST	Apa yang harus dilakukan dalam praktiknya
Tujuan sistem	Di satu sisi, semuanya sederhana dengan penunjukan. Tetapi diinginkan untuk lebih spesifik. Jika Anda menulis sesuatu seperti "kontrol inventaris otomatis secara kualitatif di perusahaan X", Anda dapat mendiskusikan hasilnya untuk waktu yang lama pada penyelesaiannya, bahkan terlepas dari perumusan persyaratan yang baik. Karena Pelanggan selalu dapat mengatakan bahwa maksudnya adalah sesuatu yang berbeda dengan kualitas. Secara umum, Anda dapat merusak banyak saraf satu sama lain, tetapi mengapa? Sebaiknya segera tulis sesuatu seperti ini: "Sistem dirancang untuk memelihara akuntansi gudang di perusahaan X sesuai dengan persyaratan yang ditetapkan dalam Kerangka Acuan ini."
Tujuan dari sistem	Tujuan pasti merupakan bagian penting. Jika Anda benar-benar memasukkannya, maka Anda harus bisa merumuskan tujuan tersebut. Jika Anda mengalami kesulitan dengan perumusan tujuan, maka lebih baik mengecualikan sama sekali bagian ini... Contoh tujuan yang tidak berhasil: "Menyediakan dokumen cepat untuk manajer." Apa yang cepat? Ini kemudian dapat dibuktikan tanpa akhir. Jika ini penting, maka lebih baik dirumuskan kembali tujuan ini jadi: "Seorang manajer penjualan harus dapat menyusun dokumen" Penjualan barang "sebanyak 100 baris dalam 10 menit." Sasaran serupa mungkin muncul jika, misalnya, manajer saat ini menghabiskan waktu sekitar satu jam untuk itu, yang terlalu banyak untuk perusahaan ini dan itu penting bagi mereka. Dalam perumusan seperti itu, tujuannya sudah bersinggungan dengan persyaratan, yang sejak itu cukup wajar saat mengembangkan pohon tujuan (yaitu membaginya menjadi tujuan terkait yang lebih kecil), kami akan tetap mendekati persyaratannya. Karena itu, jangan sampai terbawa suasana.

Secara umum, kemampuan untuk mengidentifikasi tujuan, merumuskannya, membangun pohon tujuan adalah topik yang sepenuhnya terpisah. Ingat hal utama: jika Anda tahu caranya - menulis, Anda tidak yakin - jangan menulis sama sekali. Apa yang akan terjadi jika Anda tidak merumuskan tujuan? Anda akan bekerja sesuai kebutuhan, ini sering dipraktikkan.

Bagian 3. Deskripsi objek otomasi.

Bagian 4. Persyaratan Sistem

GOST menguraikan daftar persyaratan tersebut:

persyaratan untuk struktur dan fungsi sistem;
persyaratan untuk jumlah dan kualifikasi personel sistem dan cara kerjanya;
indikator tujuan;
persyaratan keandalan;
persyaratan keamanan;
persyaratan untuk ergonomi dan estetika teknis;
persyaratan pengangkutan untuk speaker seluler;
persyaratan operasi, pemeliharaan, perbaikan dan penyimpanan komponen sistem;
persyaratan untuk perlindungan informasi dari akses yang tidak sah;
persyaratan untuk keamanan informasi jika terjadi kecelakaan;
persyaratan untuk perlindungan dari pengaruh pengaruh luar;
persyaratan kemurnian paten;
persyaratan standardisasi dan unifikasi;

Terlepas dari kenyataan bahwa bagian utama niscaya akan menjadi bagian dengan persyaratan khusus (fungsional), bagian ini mungkin juga memiliki sangat penting (dan dalam banyak kasus memang demikian). Apa yang mungkin penting dan berguna:

Persyaratan kualifikasi... Mungkin sistem yang sedang dikembangkan akan membutuhkan pelatihan ulang dari para spesialis. Ini bisa menjadi pengguna sistem masa depan dan spesialis TI yang akan dibutuhkan untuk mendukungnya. Perhatian yang tidak memadai terhadap masalah ini sering berkembang menjadi masalah. Jika kualifikasi dari personel yang ada jelas tidak mencukupi, lebih baik menentukan persyaratan untuk penyelenggaraan pelatihan, program pelatihan, waktu, dll.
Persyaratan untuk melindungi informasi dari akses yang tidak sah.Komentar tidak diperlukan di sini. Inilah persis persyaratan untuk diferensiasi akses ke data. Jika persyaratan tersebut direncanakan, maka persyaratan tersebut perlu dijelaskan secara terpisah, sedetail mungkin sesuai dengan aturan yang sama dengan persyaratan fungsional (kejelasan, kekhususan, kemampuan untuk diuji). Oleh karena itu, persyaratan ini dapat dimasukkan ke dalam bagian persyaratan fungsional.
Persyaratan untuk standardisasi. Jika ada standar desain yang berlaku untuk proyek tersebut, mereka dapat dimasukkan ke dalam persyaratan. Biasanya, persyaratan tersebut dimulai oleh layanan TI Pelanggan. Misalnya, perusahaan 1C memiliki persyaratan untuk desain kode program, desain antarmuka, dll .;
Persyaratan untuk struktur dan fungsi sistem. Persyaratan untuk integrasi sistem satu sama lain dapat dijelaskan di sini, deskripsi arsitektur umum disediakan. Lebih sering, persyaratan integrasi umumnya dialokasikan dalam bagian terpisah atau bahkan Kerangka Acuan terpisah. persyaratan ini bisa sangat kompleks.

Semua persyaratan lainnya kurang penting dan tidak perlu dijelaskan. Menurut saya, mereka hanya membuat dokumentasi lebih berat, dan sedikit kegunaan praktisnya. Dan sangat sulit untuk mendeskripsikan persyaratan ergonomi dalam bentuk persyaratan umum; lebih baik memindahkannya ke persyaratan fungsional. Misalnya, persyaratan "Dapatkan informasi tentang harga suatu barang dengan mengklik hanya satu tombol" dapat dirumuskan. Menurut saya, hal ini lebih mendekati persyaratan fungsional tertentu, meskipun berkaitan dengan ergonomi Persyaratan fungsi (tugas) yang dilakukan oleh sistem Ini adalah yang utama dan intiyang akan menentukan kesuksesan. Bahkan jika segala sesuatunya dilakukan dengan sempurna, dan bagian ini adalah "3", maka hasil dari proyek akan menjadi "3" yang terbaik, atau bahkan proyek akan gagal sama sekali. Kami akan membahasnya secara lebih rinci di artikel kedua, yang akan disertakan dalam milis edisi ke-5. Pada titik inilah "aturan tiga properti klaim", yang saya bicarakan. Persyaratan untuk jenis agunan

GOST membedakan jenis berikut:

Matematis
Informasi
Linguistik
Perangkat lunak
Teknis
Metrologi
Organisasi
Metodis
lain…

Sekilas, mungkin terlihat bahwa persyaratan ini tidak penting. Di sebagian besar proyek, ini benar. Tapi tidak selalu. Kapan harus menjelaskan persyaratan ini:

Keputusan tentang bahasa mana (atau platform mana) yang akan digunakan untuk pengembangan tidak dibuat;
Sistem memiliki persyaratan untuk antarmuka multibahasa (misalnya, Rusia / Inggris)
Agar sistem berfungsi, divisi terpisah harus dibuat atau karyawan baru dipekerjakan;
Agar sistem berfungsi, Pelanggan harus mengalami perubahan dalam metode kerja dan perubahan ini harus ditentukan dan direncanakan;
Integrasi dengan peralatan apa pun diasumsikan dan persyaratan diberlakukan padanya (misalnya, sertifikasi, kompatibilitas, dll.)
Situasi lain dimungkinkan, semuanya tergantung pada tujuan spesifik proyek.

Bagian 5. Komposisi dan konten pekerjaan pada pembuatan sistem

Bagian 6. Prosedur untuk pengendalian dan penerimaan sistem

Persyaratan umum untuk penerimaan pekerjaan secara bertahap (daftar perusahaan dan organisasi yang berpartisipasi, tempat dan waktu), prosedur untuk menyetujui dan menyetujui dokumentasi penerimaan; Saya sangat menyarankan agar Anda bertanggung jawab atas prosedur penyerahan pekerjaan dan memeriksa sistem. Untuk itulah persyaratan yang dapat diuji, tetapi keberadaan persyaratan yang dapat diuji mungkin tidak cukup ketika sistem diserahkan, jika urutan penerimaan dan pemindahan pekerjaan tidak ditentukan dengan jelas. Misalnya, jebakan umum: sistem dibuat, beroperasi penuh, tetapi Pelanggan karena alasan tertentu belum siap untuk bekerja di dalamnya. Alasan ini bisa apa saja: sekali, tujuan telah berubah, seseorang berhenti, dll. Dan dia berkata: “Karena kita belum bekerja sistem baru, jadi kami tidak dapat memastikan bahwa ini berhasil. " Jadi belajarlah untuk mengidentifikasi dengan benar tahapan pekerjaan, cara untuk memeriksa hasil untuk tahapan ini. Selain itu, metode tersebut pada awalnya harus jelas bagi Pelanggan. Jika mereka ditetapkan pada tingkat Kerangka Acuan, maka Anda selalu dapat menghubungi mereka jika perlu dan membawa pekerjaan dengan transfer.

Bagian 7. Persyaratan untuk komposisi dan isi pekerjaan pada persiapan objek otomatisasi untuk menjalankan sistem

Mungkin ada aturan lain untuk memasukkan informasi yang diadopsi oleh perusahaan (atau direncanakan). Misalnya, informasi tentang kontrak sebelumnya dimasukkan dalam baris teks dalam bentuk sewenang-wenang, tetapi sekarang nomornya diperlukan secara terpisah, tanggalnya terpisah, dll. Ada banyak kondisi seperti itu. Beberapa dari mereka dapat dianggap dengan penolakan dari staf, jadi lebih baik untuk mendaftarkan semua kasus tersebut pada tingkat persyaratan untuk prosedur entri data Perubahan yang perlu dilakukan di objek otomatisasi

Penciptaan kondisi untuk pengoperasian objek otomatisasi di mana sistem yang dibuat dengan persyaratan yang terkandung dalam TZ dijamin sesuai. Setiap perubahan yang mungkin diperlukan. Misalnya, perusahaan tidak punya jaringan lokal, armada komputer yang sudah ketinggalan zaman di mana sistem tidak akan berfungsi.

Mungkin beberapa informasi yang diperlukan diproses di atas kertas, dan sekarang perlu dimasukkan ke dalam sistem. Jika ini tidak dilakukan, maka modul apa pun tidak akan berfungsi, dll.

Mungkin ada sesuatu yang disederhanakan, tetapi sekarang perlu diperhitungkan secara lebih rinci, masing-masing, seseorang harus mengumpulkan informasi sesuai dengan aturan tertentu.

Daftar ini bisa panjang, lihat kasus spesifik proyek Anda Penciptaan unit dan layanan yang diperlukan untuk berfungsinya sistem;

Waktu dan prosedur untuk kepegawaian dan pelatihan staf Kami telah membicarakan hal ini sebelumnya. Mungkin sistem sedang dikembangkan untuk struktur atau jenis aktivitas baru yang tidak ada sebelumnya. Jika tidak ada personel yang sesuai, dan bahkan dilatih, maka sistem tidak akan berfungsi, betapapun kompetennya itu tidak dibangun.

Bagian 8. Persyaratan dokumentasi

Pertimbangkan bagaimana panduan pengguna akan disajikan.

Mungkin Pelanggan telah menerima standar perusahaan, jadi perlu untuk merujuknya.

Mengabaikan persyaratan dokumentasi sering kali menyebabkan konsekuensi yang paling tidak terduga pada proyek. Misalnya, semuanya sudah selesai dan semuanya berfungsi. Pengguna juga tahu cara bekerja. Mereka sama sekali tidak setuju atau tidak membicarakan dokumentasi tersebut. Dan tiba-tiba, ketika pekerjaan diserahkan, salah satu manajer puncak Pelanggan, yang bahkan tidak berpartisipasi dalam proyek, tetapi berpartisipasi dalam penerimaan pekerjaan, bertanya kepada Anda: "Di mana manual pengguna?" Dan dia mulai meyakinkan Anda bahwa tidak perlu menyetujui ketersediaan manual pengguna, ini "dengan sendirinya" seharusnya tersirat. Dan itu saja, dia tidak ingin mengambil pekerjaan Anda. Atas biaya siapa Anda akan mengembangkan pedoman? Banyak tim telah jatuh pada hook ini.

Bagian 9. Sumber pengembangan

Rekomendasi GOST	Apa yang harus dilakukan dalam praktiknya
Dokumen dan bahan informasi (studi kelayakan, laporan pekerjaan penelitian yang telah selesai, bahan informasi untuk sistem analog dalam negeri, luar negeri, dll.), Yang menjadi dasar pengembangan TK dan yang harus digunakan saat membuat sistem, harus dicantumkan.	Sejujurnya, ini lebih dekat dengan liriknya. Apalagi jika berbicara tentang dampak ekonomi dan hal-hal lain yang praktis tidak mungkin bisa dihitung secara objektif. Itu. mungkin saja, maka itu akan menjadi lebih di atas kertas, secara teoritis murni.

Oleh karena itu, lebih baik merujuk hanya pada laporan survei, persyaratan dari orang-orang kunci.

Jadi, kami telah mempertimbangkan semua bagian yang dapat dimasukkan dalam Kerangka Acuan. “Mei”, bukan “Wajib” justru karena dokumen apa pun harus dikembangkan untuk mencapai hasil. Oleh karena itu, jika jelas bagi Anda bahwa beberapa bagian terpisah tidak akan membawa Anda lebih dekat ke hasil, maka Anda tidak membutuhkannya dan tidak perlu membuang waktu untuk itu.

Tetapi tanpa hal utama: persyaratan fungsional, tidak ada satu pun tugas teknis yang lengkap. Saya ingin mencatat bahwa dalam praktiknya, Kerangka Acuan seperti itu ditemukan, dan bagaimana caranya! Ada tokoh yang akan dapat mengencerkan air di semua bagian, menjelaskan persyaratan umum secara umum, dan dokumen tersebut ternyata sangat berbobot, dan ada banyak kata-kata cerdas di dalamnya, dan bahkan Pelanggan mungkin menyukainya (yaitu dia akan menyetujuinya). Tetapi mengerjakannya mungkin tidak berhasil, mis. hanya ada sedikit manfaat praktis darinya. Dalam kebanyakan kasus, dokumen semacam itu lahir ketika Anda membutuhkan banyak uang khusus untuk Kerangka Acuan, dan itu harus dilakukan dengan cepat dan tanpa detail. Dan terutama jika diketahui bahwa segala sesuatunya tidak akan berjalan lebih jauh, atau orang yang sama sekali berbeda akan melakukannya. Pada umumnya hanya untuk pengembangan anggaran, khususnya negara.

Pada artikel kedua, kami hanya akan berbicara tentang Bagian 4 "Persyaratan Sistem", dan secara khusus kami akan merumuskan persyaratan untuk alasan kejelasan, kekhususan, dan kemampuan untuk diuji.

Mengapa persyaratan harus jelas, spesifik, dan dapat diuji.

Karena praktek menunjukkan: pada awalnya, sebagian besar spesifikasi teknis yang dikembangkan oleh spesialis ternyata tidak diminati (tidak sesuai dengan kenyataan), atau menjadi masalah bagi yang harus melaksanakan, karena Pelanggan mulai memanipulasi persyaratan dan persyaratan non-spesifik. Saya akan memberikan beberapa contoh frasa apa yang ditemukan, apa yang menyebabkannya, dan kemudian saya akan mencoba memberikan rekomendasi tentang bagaimana menghindari masalah tersebut.

Jenis kebutuhan

Kata-kata yang salah

1. TK proyek untuk PLTN dikembangkan oleh organisasi-pengembang sistem dengan partisipasi pelanggan berdasarkan persyaratan teknis (penerapan, tugas taktis dan teknis, dll.).

Dalam organisasi kerja yang kompetitif, opsi untuk spesifikasi desain PLTN dipertimbangkan oleh pelanggan, yang memilih opsi yang disukai atau, berdasarkan analisis komparatif, menyiapkan versi final spesifikasi desain untuk PLTN dengan partisipasi pengembang PLTN masa depan.

2. Perlunya persetujuan spesifikasi draf untuk NPP dengan otoritas pengawas negara dan organisasi lain yang berkepentingan ditentukan bersama oleh pelanggan sistem dan pengembang spesifikasi draf untuk PLTN.

3. Jangka waktu persetujuan draft TOR untuk NPP di setiap organisasi tidak boleh lebih dari 15 hari sejak tanggal diterimanya. Disarankan untuk mengirimkan salinan draft TK ke AC (salinan) secara bersamaan ke semua organisasi (departemen) untuk disetujui.

4. Komentar atas draft TOR PLTN harus disampaikan dengan alasan teknis. Keputusan atas komentar harus dibuat oleh pengembang spesifikasi proyek untuk PLTN dan pelanggan sistem sebelum persetujuan TS untuk PLTN.

5. Jika, ketika menyetujui draf TOR untuk NPP, muncul ketidaksepakatan antara pengembang dan pelanggan (atau organisasi lain yang berkepentingan), maka protokol ketidaksepakatan (bentuk sewenang-wenang) dibuat dan keputusan khusus dibuat dalam pesanan mapan.

6. Persetujuan draft TOR PLTN dapat dibuat dalam dokumen (surat) tersendiri. Dalam kasus ini, di bawah judul "Setuju" buat tautan ke dokumen ini.

7. Persetujuan spesifikasi teknis PLTN dilakukan oleh pimpinan badan usaha (organisasi) pengembang dan pelanggan sistem.

8. TK untuk NPP (selain TK) harus diperiksa oleh layanan pengawasan standar organisasi pengembang TK sebelum diajukan untuk disetujui dan jika perlu dilakukan pemeriksaan metrologi.

9. Salinan TK yang disetujui untuk NPP dalam waktu 10 hari setelah persetujuan dikirim oleh pengembang TK di NPP kepada peserta dalam pembuatan sistem.

1O. Koordinasi dan persetujuan penambahan TS untuk PLTN dilakukan dengan cara yang ditetapkan untuk TS PLTN.

11. Perubahan TK di NPP tidak diperbolehkan untuk disetujui setelah sistem diajukan atau giliran tes penerimaan.

FORMULIR LEMBAR JUDUL

Nama organisasi-pengembang spesifikasi teknis untuk NPP

ketik nama

nama objek otomatisasi

nama singkatan AU

TUGAS TEKNIS

Di lembar ______

Berlaku dari "" ________ g

SEPAKAT

Manajer (posisi, nama

organisasi koordinasi)

Transkrip Pribadi

tanda tangan

BENTUK LEMBAR TERAKHIR TK UNTUK AU

MINUMAN

SEPAKAT

Jadi, kerangka acuan telah dikembangkan, disepakati dan disetujui. Apa berikutnya? Selanjutnya - pembuatan sistem sesuai dengan TOR. TK mengatur isi karya, urutan dan ketentuan penerimaannya. Implementasi AS:

- tahap 4 Desain awal;

- tahap 5 Proyek teknis;

- tahap 6 Dokumentasi kerja.

Menurut skema yang disingkat, tahap 4, 5 dan 6 dilaksanakan sebagai proyek teknisi (TRP). Isinya ditentukan oleh sub-bagian 4 dari TK - pengembangan persyaratan sistem umum, persyaratan untuk fungsi dan penyediaan pembangkit listrik tenaga nuklir menurut jenis. Ini adalah PROYEK. Dan implementasinya dalam bentuk informasi, software dan hardware (selebihnya menjadi bagian dari mereka atau sebagai organisasi berupa peraturan, pedoman dan perintah). Proyek menentukan pekerjaan apa yang harus dilakukan untuk kepentingan implementasi praktis dari solusi desain. Artinya, TK menentukan APA yang harus dilakukan, dan TRP - BAGAIMANA.

Pembuatan sistem otomatis

Setelah disepakati dan disetujui Kerangka Acuan PLTN, mereka langsung melanjutkan ke pengembangan - tahapan draft, proyek teknis dan tahap desain terperinci yang mengarah ke komisioning sistem. Dalam hal komposisi dokumentasi, konsep dan desain teknisnya sama. Sebuah rancangan rancangan dikembangkan untuk sistem pengeras suara yang kompleks dan unik yang membutuhkan pengembangan awal yang cermat, pembenaran dan koordinasi keputusan rancangan utama. Proyek teknis adalah pengembangan solusi desain akhir baik untuk fungsi sistem dan untuk semua jenis dukungan. Untuk sebagian besar sistem, sebagai aturan, tahap desain awal dihilangkan, dan tahap desain teknis serta dokumentasi kerja digabungkan ke dalam tahap desain techno-working (TRP).

Pada tahap desain teknis, ketentuan utama dari sistem yang dibuat dikembangkan, prinsip-prinsip dasar fungsi dan interaksinya dengan AS lainnya dirumuskan, struktur AS dan subsistemnya ditentukan, keputusan desain dibuat berdasarkan seperangkat sarana teknis, pembuatan basis informasi, pengembangan dan adaptasi perangkat lunak sistem.

Banyak perhatian diberikan pada desain subsistem pendukung. Dokumentasi desain teknis sangat luas dan beragam. Catatan penjelasan memberikan ringkasan dari isi proyek, yang menunjukkan kepatuhannya dengan aturan dan peraturan yang ada. Perhatian khusus diberikan solusi desain pada satu set sarana teknis. TK menunjukkan komposisi, struktur, bentuk organisasi digunakan di berbagai tingkat AU yang dibuat, menjelaskan metode pertukaran data dalam sistem dan dengan AU yang serupa. Kumpulan spesifikasi khusus sedang dibuat untuk jenis peralatan seperti VT, perangkat keras periferal, instrumentasi, peralatan kantor, dll. Rencana tindakan untuk menyiapkan fasilitas untuk implementasi harus berisi daftar pekerjaan yang memastikan implementasi sistem, yang menunjukkan konten dan waktu pelaksanaannya, eksekutif yang bertanggung jawab dan formulir penyelesaian.

Berdasarkan hasil pelaksanaan tahap pertama, efisiensi ekonomi proyek. Hasil perhitungan yang mengkarakterisasi biaya pembuatan dan pengoperasian sistem, faktor efisiensi yang diperkirakan dan waktu pengembalian modal, menimbulkan proposal akuntansi untuk penghematan. Deskripsi struktur organisasi berisi perubahan dalam struktur objek otomatisasi dan rekomendasi untuk objek yang diatur ulang dan yang baru dibuat. Proyek teknis mengungkapkan perumusan tugas otomatis, fungsi dan karakteristik targetnya, memberikan algoritme dan teknologi untuk memecahkan masalah di komputer, dan menentukan langkah-langkah efektif untuk memantau keandalan data. Ini juga memberikan deskripsi dari komponen kompleks tugas yang diimplementasikan menggunakan paket aplikasi (APP). Dalam proyek teknis, persyaratan untuk mendukung subsistem dibentuk, metode pengumpulan dan pengorganisasian data ditentukan, struktur susunan informasi pada media teknis, dan struktur logis dari basis data diberikan.

Untuk perangkat lunak pada tahap ini, solusi seluruh sistem dipilih, termasuk sistem operasi, sistem manajemen basis data, kemungkinan penyesuaian paket aplikasi, dll. Ditentukan. Pelanggan pada tahap ini menyelesaikan pekerjaan untuk menyusun rencana organisasi - kegiatan teknis untuk mempersiapkan fasilitas untuk pelaksanaan AU, mengambil langkah-langkah untuk menyesuaikan personel manajemen dengan kondisi kerja baru, mengambil bagian dalam desain bentuk dokumen input dan output, mengembangkan, di bawah bimbingan desainer, sistem klasifikasi dan pengkodean yang digunakan dalam perusahaan ini... Ini memberikan klarifikasi data awal tentang komposisi dan struktur basis informasi, dan melakukan berbagai kegiatan persiapan di fasilitas otomasi. Tugas utama pengembang pada tahap ini adalah membuat proyek teknis sesuai dengan kerangka acuan. Dia mengembangkan dan menyampaikan program kepada pelanggan dan dokumentasi kerja mengatur dan memelihara kumpulan data primer, mengembangkan dan menyetujui dengan pelanggan bagian kasus uji yang sesuai ("Program dan Metodologi Pengujian"), menjelaskan komposisi paket perangkat lunak yang diterapkan, mengambil bagian dalam pelatihan personel pelanggan.

Pengembangan spesifikasi teknis.

Menurut tahap "Kerangka Acuan", yang hanya mencakup satu tahap 3.1 "Pengembangan dan persetujuan spesifikasi teknis untuk pembuatan pembangkit listrik tenaga nuklir" melaksanakan pengembangan, pelaksanaan, koordinasi dan persetujuan spesifikasi teknis untuk ASOIU dan, jika perlu, spesifikasi teknis untuk bagian ASOIU. Pengembangan spesifikasi teknis dilakukan sesuai dengan GOST 34.602.

TK untuk ASOIU adalah dokumen utama yang mendefinisikan persyaratan dan prosedur untuk pembuatan (pengembangan atau modernisasi - pembuatan lebih lanjut) dari sistem otomatis, yang sesuai dengan pengembangan ASOIU dan penerimaannya setelah commissioning dilakukan. TK untuk ASOIU dikembangkan untuk sistem secara keseluruhan, dirancang untuk bekerja secara mandiri atau sebagai bagian dari sistem lain.

Selain itu, spesifikasi teknis dapat dikembangkan untuk bagian dari ASOIU: untuk subsistem ASOIU, kompleks tugas ASOIU, dll. Sesuai dengan persyaratan; untuk komponen dukungan teknis dan sistem perangkat lunak dan perangkat keras yang sesuai dengan standar ESKD dan SRPP; untuk perangkat lunak yang sesuai dengan standar ESPD; untuk produk informasi sesuai dengan GOST 19.201 dan NTD, bertindak di departemen ASOIU pelanggan.

TK untuk ASOIU berisi bagian-bagian berikut, yang dapat dibagi menjadi beberapa subbagian:

1) informasi umum;

2) maksud dan tujuan menciptakan (mengembangkan) sistem;

3) karakteristik objek otomasi;

4) persyaratan sistem;

5) komposisi dan isi pekerjaan untuk menciptakan sistem;

6) prosedur untuk pengendalian dan penerimaan sistem;

7) persyaratan untuk komposisi dan konten pekerjaan pada persiapan objek otomasi untuk menjalankan sistem;

8) persyaratan untuk dokumentasi;

9) sumber pembangunan.

Prosedur pengembangan, koordinasi dan persetujuan TK untuk pembentukan ASOIU.

Informasi rinci konten kerangka acuan disajikan dalam. Mari perhatikan fitur berikut yang harus diperhatikan saat mengembangkan tugas teknis.

Karena kerangka acuan menjelaskan persyaratan untuk sistem otomatis di masa mendatang, maka tepat untuk menggunakan kata "harus", "harus", "akan", dll.

Dalam subbagian "Tujuan pembuatan sistem", nama dan nilai yang diperlukan dari indikator teknis, teknologi, produksi-ekonomi atau indikator lain dari objek otomatisasi, yang harus dicapai sebagai hasil dari pembuatan ASOIU, diberikan, dan kriteria untuk menilai pencapaian tujuan pembuatan sistem ditunjukkan. Seperti yang disebutkan sebelumnya, tujuan pembuatan ASOIU adalah untuk mengubah indikator teknis dan ekonomi perusahaan. Dalam perumusan tujuan, diperbolehkan menggunakan prinsip dekomposisi tujuan.

Pada bagian "Karakteristik objek otomasi", disarankan untuk mengacu pada hasil pemeriksaan objek otomasi yang diberikan dalam lampiran pada kerangka acuan. Bisa jadi kartu proses bisnis, IDEF 0, grafik DFD. Agar tidak mempersulit proses membaca dokumen, lebih baik memasukkan diagram yang tidak praktis ke dalam aplikasi.

Subbagian "Persyaratan untuk sistem secara keseluruhan" menunjukkan persyaratan untuk struktur dan fungsi sistem. Biasanya, ASOIU menyertakan subsistem yang membentuknya dan jenis dukungannya.

Dalam persyaratan untuk struktur dan fungsi sistem, disarankan untuk memberikan diagram struktur fungsional... Referensi yang diizinkan ke dokumen "Skema struktur fungsional", yang pada gilirannya berisi:

1) elemen struktur fungsional ASOIU (subsistem AS); fungsi otomatis dan (atau) tugas (kompleks tugas); serangkaian tindakan (operasi) yang dilakukan selama implementasi fungsi otomatis hanya dengan cara teknis (otomatis) atau hanya oleh seseorang;

2) hubungan informasi antara elemen dan dengan lingkungan luar dengan indikasi singkat tentang isi pesan dan (atau) sinyal yang dikirimkan melalui komunikasi, dan, jika perlu, jenis komunikasi lain (entri, subordinasi, dll.);

3) diagram rinci bagian-bagian struktur fungsional (jika perlu).

Dalam sub-bagian "Persyaratan untuk jenis agunan", persyaratan untuk jenis agunan yang termasuk dalam arsitektur sistem diberikan. Pada subbagian kebutuhan dukungan informasi, disarankan untuk memberikan diagram arus data, yang menjadi dasar pembentukan model data. Selain itu, disarankan untuk memberikan model data konseptual dengan deskripsi jenis entitas dan jenis hubungan.

Untuk dukungan teknis sistem, disarankan untuk mencerminkan persyaratan dalam bentuk tingkat dukungan teknis.

Pada bagian "Prosedur untuk kontrol dan penerimaan sistem" tunjukkan jenis, komposisi, ruang lingkup dan metode pengujian sistem sesuai dengan GOST 34.603-92.

Bagian "Komposisi dan konten pekerjaan pada pembuatan (pengembangan) sistem" harus berisi daftar tahapan dan tahapan pekerjaan pada pembuatan sistem sesuai dengan GOST 24.601. Perhatikan bahwa waktunya tergantung pada modelnya lingkaran kehidupan ASIOU dan eksekusi paralel dimungkinkan.

Ada prosedur untuk menyetujui dan menyetujui dokumen setelah pengembangannya. Jadi koordinasi dilakukan di semua departemen pengembang organisasi dan pelanggan terkait dengan proses pengembangan ASOIU. Waktu untuk persetujuan harus distandarisasi dengan ketat dan tidak boleh melebihi 15 hari. Jika, ketika menyepakati TK, muncul ketidaksepakatan antara pengembang dan pelanggan (atau organisasi lain yang berkepentingan), maka protokol ketidaksepakatan (bentuk arbitrer) dibuat dan keputusan khusus dibuat dengan cara yang ditentukan. Setelah persetujuan, TK untuk ASOIU disetujui, yang dilakukan oleh kepala perusahaan (organisasi) pengembang dan pelanggan sistem.

Persiapan untuk pekerjaan laboratorium

Untuk berkenalan dengan materi perkuliahan dengan topik “Model Perangkat Lunak Siklus Hidup. Tahapan siklus hidup sesuai dengan GOST 19.102-77. Rumusan masalah " disiplin akademis "Pengembangan dan standarisasi perangkat lunak dan TI".

1. Pelajari bagian yang relevan dalam publikasi.

Bagian teoritis. Pengembangan spesifikasi teknis

Tugas teknismerupakan dokumen yang merumuskan tujuan utama pengembangan, persyaratan suatu produk perangkat lunak, mendefinisikan istilah dan tahapan pengembangan, serta mengatur proses uji penerimaan. Baik perwakilan pelanggan dan perwakilan kontraktor berpartisipasi dalam pengembangan tugas teknis. Dokumen ini didasarkan pada kebutuhan awal pelanggan, analisis kemajuan teknologi maju, hasil pekerjaan penelitian, penelitian pra-desain, peramalan ilmiah, dll.

Prosedur pengembangan spesifikasi teknis

Pengembangan spesifikasi teknis dilakukan dengan urutan sebagai berikut. Pertama-tama, satu set fungsi yang dilakukan ditetapkan, serta daftar dan karakteristik data awal. Kemudian daftar hasil, karakteristik dan metode penyajiannya ditentukan.

Selanjutnya, lingkungan operasi perangkat lunak ditentukan: konfigurasi spesifik dan parameter sarana teknis, versi yang digunakan sistem operasi dan kemungkinan versi dan parameter dari perangkat lunak terinstal lain yang akan berinteraksi dengan produk perangkat lunak di masa mendatang.

Dalam kasus di mana berkembang perangkat lunak mengumpulkan dan menyimpan beberapa informasi atau termasuk dalam pengelolaan proses teknis apa pun, juga perlu mengatur dengan jelas tindakan program jika terjadi kegagalan peralatan dan catu daya.

1. Ketentuan Umum

1.1. Kerangka acuan dibuat sesuai dengan GOST 19.106-78 pada lembar A4 dan A3 sesuai dengan GOST 2.301-68, sebagai aturan, tanpa mengisi bidang lembar. Nomor lembar (halaman) ditempatkan di bagian atas lembar di atas teks.

1.2. Lembar persetujuan dan halaman judul dibuat sesuai dengan GOST 19.104-78. Bagian informasional (anotasi dan konten), lembar registrasi perubahan diperbolehkan untuk tidak disertakan dalam dokumen.

1.3. Untuk membuat perubahan dan penambahan pada latar belakang teknis pada tahap selanjutnya dari pengembangan program atau produk perangkat lunak, tambahannya dirilis. Koordinasi dan persetujuan penambahan kerangka acuan dilakukan dengan urutan yang sama dengan yang ditetapkan untuk kerangka acuan.

1.4. Kerangka acuan harus memuat bagian-bagian berikut:

Pengantar;

Nama dan ruang lingkup;

Dasar pengembangan;

Tujuan pembangunan;

Persyaratan teknis ke program atau item perangkat lunak;

Indikator teknis dan ekonomi;

Tahapan dan tahapan perkembangan;

Prosedur kontrol dan penerimaan;

Aplikasi.

Bergantung pada fitur program atau produk perangkat lunak, diperbolehkan untuk memperjelas konten bagian, memperkenalkan bagian baru atau menggabungkan beberapa di antaranya. Jika perlu, diperbolehkan untuk memasukkan aplikasi dalam kerangka acuan.

2.1 Pendahuluan harus mencakup penjelasan singkat tentang ruang lingkup program atau produk perangkat lunak, serta objek (misalnya, sistem) yang seharusnya digunakan. Tujuan utama pendahuluan adalah untuk mendemonstrasikan relevansi perkembangan ini dan untuk menunjukkan di mana tempat perkembangan ini berada di antara perkembangan yang serupa.

2.2 Pada bagian "Nama dan ruang lingkup" menunjukkan nama, deskripsi singkat tentang ruang lingkup program atau produk perangkat lunak dan objek di mana program atau produk perangkat lunak digunakan.

2.3. Di bagian "Dasar Pengembangan", hal berikut harus ditunjukkan:

Dokumen (dokumen) yang menjadi dasar pengembangannya. Dokumen semacam itu bisa berupa rencana, pesanan, kontrak, dll .;

Organisasi yang menyetujui dokumen ini dan tanggal persetujuannya;

Nama dan (atau) lambang tema pembangunan.

2.4. Bagian "Tujuan pengembangan" harus menunjukkan tujuan fungsional dan operasional dari program atau produk perangkat lunak.

2.5. Bagian "Persyaratan teknis untuk program atau produk perangkat lunak" harus berisi subbagian berikut:

Persyaratan karakteristik fungsional;

Persyaratan keandalan;

Syarat Penggunaan;

Persyaratan komposisi dan parameter sarana teknis;

Persyaratan untuk informasi dan kompatibilitas perangkat lunak;

Persyaratan pelabelan dan pengemasan;

Persyaratan transportasi dan penyimpanan;

Persyaratan khusus.

2.5.1 Subbagian "Persyaratan untuk karakteristik fungsional" harus menentukan persyaratan untuk komposisi fungsi yang dilakukan, organisasi input dan output data, karakteristik waktu, dll.

2.5.2 Subbagian "Persyaratan untuk Keandalan" harus menetapkan persyaratan untuk memastikan operasi yang andal (memastikan operasi yang stabil, memantau informasi masukan dan keluaran, waktu pemulihan setelah kegagalan, dll.).

2.5.3. Dalam sub-bagian "Kondisi operasi", kondisi operasi (suhu sekitar, kelembaban relatif, dll. Untuk jenis pembawa data yang dipilih) harus ditentukan, di mana karakteristik yang ditentukan harus dipastikan, serta jenis layanan, kuantitas dan kualifikasi yang diperlukan staf.

2.5.4 Pada subbagian "Persyaratan komposisi dan parameter sarana teknis" menunjukkan komposisi sarana teknis yang diperlukan dengan indikasi karakteristik teknisnya.

2.5.5 Dalam sub-bagian "Persyaratan untuk informasi dan kompatibilitas perangkat lunak," persyaratan untuk struktur informasi pada masukan dan keluaran dan metode solusi, kode sumber, bahasa pemrograman harus ditunjukkan. Perlindungan informasi dan program harus dipastikan jika diperlukan.

2.5.6 Dalam sub-bagian "Persyaratan untuk pelabelan dan pengemasan", dalam kasus umum, tunjukkan persyaratan untuk pelabelan produk perangkat lunak, opsi dan metode pengemasan.

2.5.7 Dalam sub-bagian "Persyaratan untuk pengangkutan dan penyimpanan", persyaratan pengangkutan, lokasi penyimpanan, kondisi penyimpanan, kondisi penyimpanan, waktu penyimpanan dalam berbagai kondisi harus ditentukan untuk produk perangkat lunak.

2.5.8. Bagian "Indikator teknis dan ekonomi" harus menunjukkan: perkiraan efisiensi ekonomi, perkiraan permintaan tahunan, keuntungan ekonomi dari pembangunan dibandingkan dengan sampel atau analog domestik dan luar negeri terbaik.

2.6 Di bagian "Tahapan dan tahapan pengembangan", tahapan pengembangan, tahapan, dan konten pekerjaan yang diperlukan ditetapkan (daftar dokumen kebijakan, yang harus dikembangkan, disepakati, dan disetujui), serta, sebagai aturan, persyaratan pengembangan dan menentukan pelakunya.

2.7 Bagian "Prosedur untuk pengendalian dan penerimaan" harus menunjukkan jenis pengujian dan persyaratan umum untuk penerimaan pekerjaan.

2.8 Dalam lampiran kerangka acuan, jika perlu, berikan:

Daftar penelitian dan pekerjaan lain yang membenarkan pengembangan;

Diagram algoritme, tabel, deskripsi, justifikasi, perhitungan, dan dokumen lain yang dapat digunakan dalam pengembangan;

Sumber pengembangan lainnya.

Dalam kasus di mana pelanggan tidak membuat persyaratan apa pun yang ditentukan oleh kerangka acuan, perlu untuk menunjukkan di tempat yang tepat "Persyaratan tidak disajikan".

Contoh pengembangan spesifikasi teknis diberikan dalam Lampiran B dan C.

Kontrol pertanyaan

1. Berikan konsep model siklus hidup perangkat lunak.

2. Beri tahu tahapan-tahapan pengembangan perangkat lunak.

3. Apa yang termasuk dalam pernyataan masalah dan penelitian pra-proyek?

4. Buat daftar persyaratan fungsional dan kinerja untuk produk perangkat lunak.

5. Buat daftar aturan untuk mengembangkan spesifikasi teknis.

6. Apa bagian utama dari kerangka acuan.

Lampiran A

Opsi pekerjaan

Pekerjaan laboratorium No. 1-5 dilakukan untuk opsi yang sama.

1. Kembangkan modul program "Akuntansi untuk kemajuan siswa." Modul perangkat lunak ini dirancang untuk pembukuan operasional kemajuan siswa dalam sesi oleh dekan, wakil dekan dan karyawan kantor dekan. Informasi tentang kemajuan siswa harus disimpan selama seluruh periode studi mereka dan digunakan dalam persiapan sertifikat kursus yang dihadiri dan suplemen diploma.

2. Untuk mengembangkan modul program "File pribadi siswa". Modul program dirancang untuk memperoleh informasi tentang mahasiswa oleh karyawan kantor dekan, komite serikat pekerja dan departemen personalia. Informasi tersebut harus disimpan selama masa pelatihan siswa dan digunakan dalam persiapan sertifikat dan laporan.

3. Untuk mengembangkan modul perangkat lunak "Solusi masalah optimasi kombinatorial". Modul harus berisi algoritma untuk menemukan siklus dengan panjang minimum (masalah penjual keliling), menemukan jalur terpendek, dan menemukan pohon penghubung minimum.

4. Mengembangkan modul program "Pemrosesan matriks". Modul harus berisi algoritma untuk menemukan jumlah dan hasil kali elemen matriks berdasarkan baris dan kolom, serta menghitung nilai rata-rata, minimum dan maksimum dalam matriks.

5. Kembangkan aplikasi Windows "Organizer". Aplikasi ini dirancang untuk merekam, menyimpan dan mencari alamat dan nomor telepon individu dan organisasi, serta jadwal, rapat, dll. Aplikasi ini ditujukan untuk semua pengguna komputer.

6. Kembangkan aplikasi Windows "Calculator". Aplikasi ini ditujukan untuk semua pengguna dan harus berisi semua operasi aritmatika (dengan memperhatikan prioritas) dan lebih disukai (tetapi tidak harus) beberapa fungsi matematika.

7. Menyusun modul program "Departemen" yang berisi informasi tentang staf departemen (nama lengkap, jabatan, gelar akademis, disiplin, beban, pekerjaan sosial, pekerjaan paruh waktu, dll.). Modul ini ditujukan untuk digunakan oleh karyawan departemen personalia dan kantor dekan.

8. Menyusun modul program “Laboratorium” yang berisi informasi tentang staf laboratorium (nama, jenis kelamin, umur, status perkawinan, keberadaan anak, jabatan, gelar akademik). Modul ini dimaksudkan untuk digunakan oleh karyawan dari komite serikat pekerja dan departemen personalia.

9. Kembangkan modul program "Dry Cleaning". Saat mendaftar untuk layanan, aplikasi diisi, yang menunjukkan nama pemilik, deskripsi produk, jenis layanan, tanggal penerimaan pesanan dan biaya layanan. Setelah menyelesaikan pekerjaan, kwitansi dicetak.

10. Untuk mengembangkan modul perangkat lunak "Akuntansi pelanggaran aturan lalu lintas jalan raya". Untuk setiap mobil (dan pemiliknya) daftar pelanggaran disimpan dalam database. Untuk setiap pelanggaran, tanggal, waktu, jenis pelanggaran dan jumlah denda dicatat. Ketika semua denda dibayarkan, mobil dihapus dari database.

11. Untuk mengembangkan modul perangkat lunak "file kartu Autoshop" yang ditujukan untuk digunakan oleh karyawan instansi. Basis data berisi informasi tentang mobil (merek, ukuran mesin, tanggal rilis, dll.). Saat permintaan pembelian diterima, pencarian dilakukan untuk opsi yang sesuai. Jika ini tidak terjadi, klien dimasukkan ke dalam basis klien dan diberi tahu saat opsi muncul.

12. Untuk mengembangkan modul perangkat lunak "file kartu pelanggan ATS". File tersebut berisi informasi tentang ponsel dan pemiliknya. Memperbaiki tunggakan pembayaran (langganan dan berbasis waktu). Diyakini bahwa upah waktu untuk panggilan lokal telah diperkenalkan.

13. Untuk mengembangkan modul perangkat lunak "Autokassa" yang berisi informasi tentang ketersediaan kursi gratis di rute bus. Database tersebut harus berisi informasi tentang nomor penerbangan, rute, pengemudi, jenis bus, tanggal dan waktu keberangkatan, serta harga tiket. Setelah menerima aplikasi untuk tiket, program mencari penerbangan yang cocok.

14. Mengembangkan modul perangkat lunak “Toko Buku” yang berisi informasi tentang buku (penulis, judul, penerbit, tahun terbit, harga). Pembeli membuat aplikasi untuk buku yang dia butuhkan, jika tidak ada, dia dimasukkan ke dalam database dan diberi tahu ketika buku yang diperlukan tiba di toko.