Oleh itu, piawaian utama, metodologi dan badan pengetahuan yang menyebut TK atau SRS (Spesifikasi Keperluan Perisian (atau Sistem)):
GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK, dll.
GOST 34
GOST 34.602-89 Terma rujukan untuk penciptaan sistem automatik mengawal struktur spesifikasi teknikal untuk penciptaan SISTEM, yang merangkumi perisian, perkakasan, orang yang bekerja dengan perisian dan proses automatik.Menurut GOST 34, spesifikasi teknikal mesti termasuk bahagian berikut:
1. Maklumat am
2. Tujuan dan matlamat penciptaan (pembangunan) sistem
3. Ciri-ciri objek automasi
4. Keperluan sistem
5. Komposisi dan kandungan kerja untuk mencipta sistem
6. Prosedur untuk kawalan dan penerimaan sistem
7. Keperluan untuk komposisi dan kandungan kerja untuk menyediakan objek automasi untuk pentauliahan sistem
8. Keperluan dokumentasi
9. Sumber pembangunan
Apabila membangunkan spesifikasi teknikal untuk projek kerajaan, Pelanggan, sebagai peraturan, memerlukan pematuhan dengan piawaian khusus ini.
GOST 19
“GOST 19.xxx Sistem Dokumentasi Program Bersepadu (USPD)” ialah satu set piawaian negeri yang mewujudkan peraturan yang saling berkaitan untuk pembangunan, reka bentuk dan peredaran program (atau perisian) dan dokumentasi program. Itu. Piawaian ini terpakai khusus untuk pembangunan perisian.Menurut GOST 19.201-78 Spesifikasi teknikal, keperluan untuk kandungan dan reka bentuk, spesifikasi teknikal mesti termasuk bahagian berikut:
1. Pengenalan;
2. Sebab pembangunan;
3. Tujuan pembangunan;
4. Keperluan untuk program atau produk perisian;
5. Keperluan untuk dokumentasi program;
6. Penunjuk teknikal dan ekonomi;
7. Peringkat dan peringkat pembangunan;
8. Prosedur untuk kawalan dan penerimaan;
9. Permohonan.
Sememangnya, GOST 34 (dan 19) sudah ketinggalan zaman, dan saya tidak suka menggunakannya, tetapi dengan tafsiran piawaian yang betul, anda boleh mendapatkan spesifikasi teknikal yang baik, lihat Kesimpulan.
IEEE STD 830-1998
Takrifan standard 830-1998 yang cukup baik - Amalan Disyorkan IEEE untuk Spesifikasi Keperluan Perisian diberikan dalam perihalannya:Menghuraikan kandungan dan ciri kualiti spesifikasi keperluan perisian (SRS) yang ditulis dengan baik dan menyediakan beberapa templat SRS. Amalan yang disyorkan ini bertujuan untuk mewujudkan keperluan untuk perisian yang sedang dibangunkan, tetapi juga boleh digunakan untuk membantu dalam pemilihan produk perisian proprietari dan komersial.
Mengikut piawaian, terma rujukan mesti termasuk bahagian berikut:
1. Pengenalan
- 1. Tujuan
- 2. Skop
- 3. Definisi, akronim dan singkatan
- 4. Pautan
- 5. Gambaran keseluruhan ringkas
- 1. Interaksi produk (dengan produk dan komponen lain)
- 2. Ciri-ciri produk (huraian ringkas)
- 3. Ciri-ciri pengguna
- 4. Had
- 5. Andaian dan kebergantungan
- 1. Keperluan untuk antara muka luaran
- 1. Antara Muka Pengguna
- 2. Antara muka perkakasan
- 3. Antara muka perisian
- 4. Antara muka
- 2. Keperluan fungsian
- 3. Keperluan prestasi
- 4. Kekangan Reka Bentuk (dan Rujukan kepada Piawaian)
- 5. Keperluan tidak berfungsi (kebolehpercayaan, ketersediaan, keselamatan, dsb.)
- 6. Keperluan lain
5. Indeks abjad
Sebenarnya, agak sukar bagi seorang pemula untuk memahami apa yang harus terkandung dalam bahagian ini mengikut struktur di atas (seperti dalam kes GOST), jadi anda perlu membaca standard itu sendiri, yang mana. , walau bagaimanapun, dalam bahasa Inggeris. bahasa.
Nah, bagi mereka yang membaca hingga habis, ada bonus: contoh spesifikasi teknikal yang saya tulis bertahun-tahun yang lalu (sekarang saya sudah lama tidak bekerja sebagai penganalisis, dan contoh lain yang lebih berjaya dilarang daripada menjadi dibuka untuk tontonan umum oleh NDA).
- Pembentangan oleh Yuri Buluy Klasifikasi keperluan perisian dan perwakilannya dalam piawaian dan metodologi.
- Analisis keperluan untuk sistem maklumat automatik. Kuliah 11: Mendokumentasikan keperluan.
- Peraturan untuk merangka spesifikasi keperluan perisian (baca bersama dengan ulasan)
- Contoh spesifikasi teknikal dan dokumentasi lain untuk pembangunan AS untuk Kementerian Pembangunan Ekonomi
- Gaya pengurusan GOST. Artikel Gaperton mengenai kerja yang betul dengan spesifikasi teknikal mengikut GOST
- Templat Dokumen Penganalisis Perniagaan daripada
Bidang tugas untuk reka bentuk sistem maklumat. Bahagian utama spesifikasi teknikal. Piawaian yang menerangkan spesifikasi teknikal. Analisis dan pembangunan keperluan.
Tugas teknikal- dokumen teknikal (spesifikasi) yang menyatakan satu set keperluan untuk sistem dan diluluskan oleh kedua-dua pelanggan/pengguna dan kontraktor/pengilang sistem. Spesifikasi sedemikian mungkin juga mengandungi keperluan sistem dan ujian.
Spesifikasi teknikal mengandungi bahagian berikut:
Maklumat am. Bahagian ini termasuk: nama penuh pembangunan, nama penuh dan butiran pelanggan dan kontraktor, senarai dokumen yang menjadi asas untuk pembangunan, kemungkinan tarikh mula dan tamat untuk kerja, prosedur untuk memproses dan membentangkan kepada pelanggan hasil kerja untuk mencipta sistem atau bahagiannya.
Sebab dan tujuan pembangunan. Tujuan pembangunan merujuk kepada jenis proses aktiviti automatik.
Keperluan Sistem. Mengandungi subseksyen dengan keperluan untuk sistem secara keseluruhan dan fungsi yang dilakukan oleh sistem.
Komposisi dan kandungan kerja untuk mencipta sistem. Senarai kerja dan kandungannya yang dijangka akan dilaksanakan dalam rangka projek ini
Prosedur untuk kawalan dan penerimaan sistem. Mengandungi tarikh anggaran kawalan perantaraan dan tarikh anggaran penghantaran kepada pelanggan.
Keperluan untuk komposisi dan kandungan kerja untuk menyediakan objek pembangunan untuk meletakkan sistem beroperasi. Kerja persediaan untuk menjalankan sistem diterangkan.
Keperluan dokumentasi. Mengandungi senarai dan komposisi dokumentasi sistem.
Sumber pembangunan. Mengandungi senarai dokumentasi dan literatur yang akan digunakan dalam membangunkan sistem.
Terdapat tiga piawaian yang menerangkan spesifikasi teknikal untuk mereka bentuk IS: GOST 34.602-89, GOST 19.201-78, GOST 19.102-77.
Pembangunan keperluan boleh berdasarkan tinjauan, soal selidik, dsb. Di samping itu, keperluan boleh dibentuk berdasarkan sumbang saran, pemerhatian aktiviti pengeluaran, analisis dokumentasi peraturan, analisis IS yang telah dibuat, analisis versi IS yang digunakan.
Apabila membangunkan keperluan, masalah kekaburan, ketidaklengkapan, dan ketidakkonsistenan keperluan individu sering timbul. Membetulkan masalah ini semasa peringkat pembangunan keperluan memerlukan kos beberapa urutan magnitud kurang daripada membetulkan masalah yang sama kemudian dalam pembangunan.
Antara muka pengguna sistem maklumat. Prinsip umum pembinaan. Gaya antara muka pengguna. Kriteria keberkesanan antara muka pengguna. Garis panduan reka bentuk antara muka pengguna. Peraturan reka bentuk.
Antaramuka pengguna– ini adalah bahagian perisian sistem maklumat, bertanggungjawab untuk menguruskan peranti yang digunakan pengguna berkomunikasi dengan program.
Perancangan dan reka bentuk antara muka pengguna hendaklah berdasarkan model berikut:
- Model mental– beberapa jangkaan seseorang berdasarkan rasa realiti dan pengetahuan serta pengalamannya bekerja dengan komputer.
- Model tersuai- dengan memerhati cara pengguna bekerja dengan antara muka baharu dan menganalisis maklum balas mereka tentang kerja, anda boleh membentuk idea umum tentang antara muka masa hadapan. Adalah penting bahawa pengguna disertakan dalam kerja mengenai IS seawal mungkin.
- Model pengaturcara– dilahirkan dalam kepala pengaturcara dan berdasarkan aktiviti profesionalnya.
Gaya antara muka pengguna. Terdapat empat gaya antara muka pengguna utama:
- Antara muka pengguna grafik (Grafik pengguna Antara muka, GUI) – antara muka ini berdasarkan empat elemen asas: tingkap, penunjuk (tetikus), menu dan ikon. Elemen lain juga digunakan: butang, suis, medan input, dsb. Ciri antara muka ini ialah keupayaan lanjutan reka bentuk skrin dan kawalan menggunakan penuding tetikus.
- Web-antara muka (Web pengguna Antara muka, WUI) – antara muka menyerupai antara muka GUI, tetapi pada mulanya lebih lemah daripadanya. Khususnya, ia menggunakan mod tetingkap tunggal dan tidak mempunyai keupayaan untuk "seret dan lepaskan" objek. Dengan pembangunan JavaScript dan Ajax, ia menjadi lebih seperti antara muka GUI.
- Antara mukaHUI (Manusia pengguna Antara muka) ialah antara muka pengguna peranti pegang tangan. Biasanya, peranti sedemikian mempunyai skrin yang sangat kecil. Ia mengandungi beberapa elemen GUI, seperti item menu dan ikon.
- Gaya antara muka objek. Keupayaan pengaturcaraan objek membawa sifat objek ke dalam antara muka pengguna. Pendekatan objek dicirikan oleh ciri seperti menyeret elemen, menu konteks, petua alat, dll.
Pertimbangkan satu set kriteria kualiti antara muka pengguna:
- Memahami pengguna - sejauh mana keperluan pengguna ditunjukkan dalam antara muka program.
- Kecekapan dalam proses reka bentuk– menentukan sama ada produk difikirkan dan direka bentuk dengan teliti.
- Keperluan projek– sama ada produk itu mempunyai kepentingan ekonomi dan sosial.
- Kesesuaian untuk kajian dan penggunaan– betapa sukarnya produk untuk dipelajari dan digunakan.
- Surat-menyurat– sama ada reka bentuk produk sepadan dengan penyelesaian masalah yang ditimbulkan.
- Perasaan estetik– betapa estetik produk itu digunakan.
- Kebolehubah– berapa banyak reka bentuk boleh diubah mengikut keperluan pengguna.
- Kebolehkawalan– sejauh manakah fungsi kebolehkawalan produk dilaksanakan: pengurusan pemasangan, latihan, sokongan.
Prinsip umum untuk membina antara muka grafik:
Menggunakan persekitaran pengguna tunggal dalam bentuk desktop yang dipanggil;
Menggunakan tetingkap grafik untuk memaparkan data;
Menggunakan input bukan papan kekunci (menggunakan tetikus).
Peraturan reka bentuk antara muka pengguna:
- Kawalan pengguna - pembangun mesti memberi pengguna kawalan paling lengkap ke atas IP (setakat yang dibenarkan oleh keselamatan). Mari kita pertimbangkan beberapa pelaksanaan tertentu prinsip ini:
1) mengurangkan beban memori - memori pengguna tidak begitu besar dan tidak begitu pantas.
2) keserasian antara muka – keupayaan pengguna untuk memindahkan pengalaman dan pengetahuan mereka untuk bekerja dengan perisian baharu.
Memodelkan sistem maklumat. Keperluan bahasa pemodelan. BahasaUML. Prinsip reka bentuk berorientasikan objek. Gambaran Keseluruhan Rajah BahasaUML. Gunakan rajah kes dan rajah kelas.
Permodelan– ini ialah penggantian objek yang dikaji (asal) dengan imej konvensionalnya atau objek lain (model) dan kajian sifat-sifat asal dengan mengkaji sifat-sifat model.
Keberkesanan pemodelan boleh dicapai jika dua syarat dipenuhi: model menyediakan paparan yang betul bagi sifat-sifat asal; Model ini menghapuskan masalah yang wujud dalam mengambil ukuran pada objek sebenar.
Bahasa pemodelan - ialah tatatanda, terutamanya grafik, yang digunakan untuk menerangkan projek. Notasi mewakili koleksi objek grafik yang digunakan dalam model. Notasi ialah sintaks bahasa pemodelan. Bahasa pemodelan, dalam satu pihak, harus membuat keputusan pereka bentuk dapat difahami oleh pengguna, dan sebaliknya, menyediakan pereka dengan cara untuk perwakilan sistem maklumat yang paling formal. Perwakilan grafik selalunya merupakan bentuk penyampaian maklumat yang paling mudah difahami.
UML (Bersatu Permodelan Bahasa– bahasa pemodelan bersatu) ialah bahasa penerangan grafik untuk pemodelan objek dalam pembangunan perisian. UML menggunakan tatatanda grafik untuk mewakili model abstrak sistem, dipanggil model UML. Bahasa ini dibangunkan untuk pemodelan IS. UML bukan bahasa pengaturcaraan, tetapi kod dijana berdasarkan model UML.
Model berorientasikan objek ialah satu set gambar rajah yang menerangkan, menggunakan bahasa UML, pelbagai aspek struktur dan tingkah laku IS.
Gambar rajahUML ialah perwakilan grafik bagi satu set elemen, paling kerap digambarkan sebagai graf dengan bucu (entiti) dan tepi (hubungan).
Saya sering ditanya: "Bagaimana untuk membangunkan spesifikasi teknikal dengan betul untuk sistem automatik?" Topik yang sama sentiasa dibincangkan di pelbagai forum. Soalan ini sangat luas sehingga mustahil untuk dijawab secara ringkas. Oleh itu, saya memutuskan untuk menulis artikel panjang mengenai topik ini.
- Pada bahagian pertama" Pembangunan spesifikasi teknikal. Apakah itu, mengapa ia diperlukan, di mana untuk bermula dan bagaimana ia sepatutnya kelihatan? Saya akan cuba menjawab soalan topik secara terperinci, mempertimbangkan struktur dan tujuan Terma Rujukan, dan memberikan beberapa cadangan mengenai penggubalan keperluan.
- Bahagian kedua " Pembangunan spesifikasi teknikal. Bagaimana untuk merumus keperluan? akan menumpukan sepenuhnya untuk mengenal pasti dan merumus keperluan untuk sistem maklumat.
Mula-mula, anda perlu memikirkan soalan yang sebenarnya menarik minat mereka yang bertanya "Bagaimana untuk membangunkan spesifikasi teknikal?" Hakikatnya ialah pendekatan untuk membangunkan spesifikasi teknikal akan sangat bergantung pada tujuan ia dilakukan, serta oleh siapa ia akan digunakan. Apakah pilihan yang saya bincangkan:
- Sebuah organisasi komersial memutuskan untuk melaksanakan sistem automatik. Ia tidak mempunyai perkhidmatan IT sendiri dan memutuskan untuk melakukan ini: Pihak yang berminat mesti membangunkan Spesifikasi Teknikal dan menyerahkannya untuk pembangunan kepada pihak ketiga;
- Sebuah organisasi komersial memutuskan untuk melaksanakan sistem automatik. Ia mempunyai perkhidmatan IT sendiri. Kami memutuskan untuk melakukan ini: membangunkan Spesifikasi Teknikal, kemudian bersetuju mengenainya antara perkhidmatan IT dan pihak yang berminat, dan melaksanakannya sendiri;
- Agensi kerajaan memutuskan untuk memulakan projek IT. Segala-galanya di sini sangat keruh, banyak formaliti, sogokan, pemotongan, dll. Saya tidak akan mempertimbangkan pilihan ini dalam artikel ini.
Sebuah syarikat IT menyediakan perkhidmatan untuk pembangunan dan/atau pelaksanaan sistem automatik. Ini adalah kes yang paling sukar, kerana anda perlu bekerja dalam pelbagai keadaan:
- Pelanggan mempunyai pakar sendiri dengan pandangan mereka sendiri, dan mereka membuat keperluan khusus untuk Spesifikasi Teknikal;
- Terma rujukan dibangunkan untuk pembangun dalaman (pelanggan tidak peduli);
- Terma rujukan dibangunkan untuk pemindahan kepada kontraktor (iaitu sekumpulan pengaturcara pada kakitangan syarikat, atau pakar individu);
- Salah faham timbul antara syarikat dan pelanggan mengenai hasil yang diperoleh, dan syarikat itu berulang kali bertanya soalan: "Bagaimanakah Spesifikasi Teknikal perlu dibangunkan?" Kes terakhir mungkin kelihatan seperti paradoks, tetapi ia adalah benar.
- Pilihan lain yang kurang biasa juga mungkin;
Saya fikir pembaca kini harus mempunyai soalan:
- Mengapakah Spesifikasi Teknikal tidak boleh sentiasa dibangunkan dengan cara yang sama?;
- Adakah terdapat sebarang piawaian, kaedah, cadangan? Di mana saya boleh mendapatkannya?
- Siapa yang harus membangunkan Terma Rujukan? Sekiranya orang ini mempunyai pengetahuan khusus?
- Bagaimana untuk memahami sama ada Terma Rujukan ditulis dengan baik atau tidak?
- Atas perbelanjaan siapa ia harus dibangunkan, dan adakah ia perlu?
Senarai ini boleh menjadi tidak berkesudahan. Saya mengatakan ini dengan yakin kerana saya telah berada dalam pembangunan perisian profesional selama 15 tahun, dan persoalan Spesifikasi Teknikal muncul dalam mana-mana pasukan pembangunan yang bekerjasama dengan saya. Sebab-sebab ini adalah berbeza. Membangkitkan topik membangunkan Terma Rujukan, saya amat sedar bahawa saya tidak akan dapat membentangkannya 100% kepada semua orang yang berminat dengan topik tersebut. Tetapi, saya akan cuba, seperti yang mereka katakan, "untuk menyelesaikan segala-galanya." Mereka yang sudah biasa dengan artikel saya tahu bahawa saya tidak menggunakan "copy-paste" karya orang lain, tidak mencetak semula buku orang lain, tidak memetik piawaian berbilang halaman dan dokumen lain yang anda sendiri boleh temui di Internet, menganggapnya sebagai pemikiran genius anda sendiri. Hanya taip enjin carian "Bagaimana untuk membangunkan Spesifikasi Teknikal" dan anda boleh membaca banyak perkara yang menarik, tetapi, malangnya, perkara yang berulang. Sebagai peraturan, mereka yang suka menjadi pandai di forum (cuba cari sahaja!) Tidak pernah membuat sendiri Spesifikasi Teknikal yang betul, dan sentiasa memetik cadangan GOST mengenai isu ini. Dan mereka yang benar-benar serius tentang isu ini biasanya tidak mempunyai masa untuk duduk di forum. Dengan cara ini, kita juga akan bercakap tentang piawaian GOST. Selama bertahun-tahun bekerja saya, saya telah melihat banyak versi dokumentasi teknikal yang disusun oleh kedua-dua pakar individu dan pasukan terkemuka dan syarikat perunding. Kadang-kadang saya juga terlibat dalam aktiviti ini: Saya memperuntukkan masa untuk diri sendiri dan mencari maklumat mengenai topik yang diminati daripada sumber luar biasa (seperti sedikit kecerdasan). Akibatnya, saya terpaksa melihat dokumentasi mengenai raksasa seperti GazProm, Keretapi Rusia dan banyak lagi syarikat menarik. Sudah tentu, saya mematuhi dasar kerahsiaan, walaupun pada hakikatnya dokumen-dokumen ini datang kepada saya daripada sumber yang tersedia secara umum atau tidak bertanggungjawab perunding (menyebarkan maklumat di Internet). Oleh itu, saya katakan dengan segera: Saya tidak berkongsi maklumat sulit yang dimiliki oleh syarikat lain, tanpa mengira sumber (etika profesional).
Apakah spesifikasi teknikal?
Perkara pertama yang akan kita lakukan sekarang ialah mengetahui jenis binatang "Spesifikasi Teknikal" ini.
Ya, memang terdapat GOST dan piawaian yang cuba mengawal selia bahagian aktiviti ini (pembangunan perisian). Pada suatu masa dahulu, semua GOST ini adalah relevan dan digunakan secara aktif. Kini terdapat pendapat yang berbeza tentang kaitan dokumen ini. Ada yang berpendapat bahawa GOST telah dibangunkan oleh orang yang sangat berpandangan jauh dan masih relevan. Yang lain berkata mereka sudah ketinggalan zaman. Mungkin seseorang kini berfikir bahawa kebenaran berada di suatu tempat di tengah-tengah. Saya akan menjawab dengan kata-kata Goethe: “Mereka mengatakan bahawa antara dua pendapat yang bertentangan terletak kebenaran. Walau apa pun! Ada masalah antara mereka." Jadi, tidak ada kebenaran antara pendapat ini. Kerana GOST tidak mendedahkan masalah praktikal pembangunan moden, dan mereka yang mengkritik mereka tidak menawarkan alternatif (khusus dan sistemik).
Perhatikan bahawa GOST jelas tidak memberikan definisi, ia hanya mengatakan: "TK untuk loji tenaga nuklear adalah dokumen utama yang menentukan keperluan dan prosedur untuk mencipta (pembangunan atau pemodenan - kemudian penciptaan) sistem automatik, mengikut mana pembangunan loji tenaga nuklear dijalankan dan penerimaannya selepas pentauliahan beraksi."
Jika sesiapa berminat dengan GOST yang saya maksudkan, inilah mereka:
- GOST 2.114-95 Sistem dokumentasi reka bentuk bersatu. Spesifikasi teknikal;
- GOST 19.201-78 Sistem dokumentasi program bersatu. Tugas teknikal. Keperluan untuk kandungan dan reka bentuk;
- GOST 34.602-89 Teknologi maklumat. Set piawaian untuk sistem automatik. Terma rujukan untuk penciptaan sistem automatik.
Definisi yang lebih baik dibentangkan di Wikipedia (walaupun mengenai spesifikasi teknikal secara umum, dan bukan hanya untuk perisian): " Tugas teknikal– ini adalah dokumen reka bentuk asal teknikal objek. Tugas teknikal menetapkan tujuan utama objek yang sedang dibangunkan, ciri teknikal dan taktikal-teknikalnya, penunjuk kualiti dan keperluan teknikal dan ekonomi, arahan untuk melengkapkan peringkat yang diperlukan untuk mencipta dokumentasi (reka bentuk, teknologi, perisian, dll.) dan komposisinya, sebagai serta keperluan khas. Tugas sebagai dokumen awal untuk mencipta sesuatu yang baharu wujud dalam semua bidang aktiviti, berbeza dalam nama, kandungan, susunan pelaksanaan, dll. (contohnya, tugas reka bentuk dalam pembinaan, tugas pertempuran, kerja rumah, kontrak untuk karya sastera, dll.). d.)"
Oleh itu, seperti berikut dari definisi, tujuan utama Spesifikasi Teknikal adalah untuk merumuskan keperluan untuk objek yang dibangunkan, dalam kes kami, untuk sistem automatik.
Ia adalah perkara utama, tetapi satu-satunya. Masanya telah tiba untuk pergi ke perkara utama: untuk meletakkan segala-galanya "di rak", seperti yang dijanjikan.
Apa yang anda perlu tahu tentang keperluan? Adalah perlu untuk memahami dengan jelas bahawa semua keperluan mesti dibahagikan mengikut jenis dan sifat. Sekarang kita akan belajar bagaimana untuk melakukan ini. Untuk memisahkan keperluan mengikut jenis, GOST akan membantu kami. Senarai jenis keperluan yang dibentangkan terdapat contoh yang baik tentang jenis keperluan yang perlu dipertimbangkan. Sebagai contoh:
- Keperluan kefungsian;
- Keperluan keselamatan dan hak akses;
- Keperluan untuk kelayakan kakitangan;
- …. Dan lain-lain. Anda boleh membaca tentang mereka dalam GOST yang disebutkan (dan di bawah saya juga akan melihatnya dengan lebih terperinci).
Saya fikir adalah jelas kepada anda bahawa faktor utama dalam Spesifikasi Teknikal yang berjaya adalah keperluan fungsi yang dirumus dengan tepat. Kebanyakan kerja dan kaedah yang saya bicarakan ditumpukan kepada keperluan ini. Keperluan kefungsian adalah 90% daripada kerumitan kerja untuk membangunkan Terma Rujukan. Segala-galanya selalunya merupakan "penyamaran" yang meliputi keperluan ini. Sekiranya keperluan dirumuskan dengan buruk, maka tidak kira apa penyamaran cantik yang anda letakkan pada mereka, projek yang berjaya tidak akan keluar. Ya, secara rasmi semua keperluan akan dipenuhi (mengikut GOST J), spesifikasi teknikal telah dibangunkan, diluluskan dan ditandatangani, dan wang telah diterima untuknya. Dan apa? Dan kemudian bahagian yang paling menarik bermula: apa yang perlu dilakukan? Jika ini adalah projek dalam Perintah Negeri, maka tidak ada masalah - bajet yang ada sedemikian rupa sehingga ia tidak akan masuk ke dalam poket sesiapa, dan semasa proses pelaksanaan (jika ada) semuanya akan dijelaskan. Beginilah cara majoriti belanjawan projek dibelanjakan untuk Perintah Negeri (mereka menulis "TZ", kerugian berpuluh-puluh juta, tetapi tidak melakukan projek. Semua formaliti diperhatikan, tidak ada pihak yang bersalah, kereta baru berada berhampiran rumah. Kecantikan!). Tetapi kita bercakap tentang organisasi komersial di mana wang dikira, dan keputusan yang berbeza diperlukan. Oleh itu, mari kita fahami perkara utama, bagaimana untuk berkembang berguna dan berfungsi Spesifikasi teknikal.
Saya berkata tentang jenis keperluan, tetapi bagaimana dengan hartanah? Sekiranya jenis keperluan boleh berbeza (bergantung pada matlamat projek), maka dengan sifat semuanya lebih mudah, terdapat 3 daripadanya:
- Keperluan mestilah boleh difahami;
- Keperluan mestilah khusus;
- Keperluan mestilah pengambil ujian;
Selain itu, harta terakhir adalah mustahil tanpa dua yang sebelumnya, i.e. adalah sejenis "ujian litmus". Jika keputusan sesuatu keperluan tidak dapat diuji, ini bermakna ia tidak jelas atau tidak spesifik. Cuba pertimbangkan. Dalam penguasaan ketiga-tiga sifat keperluan ini terletaknya penguasaan dan profesionalisme. Ia sebenarnya sangat mudah. Apabila anda memikirkannya.
Ini menyimpulkan cerita tentang apa itu Spesifikasi Teknikal dan beralih kepada perkara utama: bagaimana untuk merumuskan keperluan. Tetapi ia tidak begitu pantas. Terdapat satu lagi perkara yang sangat penting:
- Dalam bahasa apakah (dari segi kesukaran memahami) spesifikasi teknikal harus ditulis?
- Patutkah ia menerangkan spesifikasi pelbagai fungsi, algoritma, jenis data dan perkara teknikal lain?
- Apakah reka bentuk teknikal, yang, dengan cara itu, juga disebut dalam GOST, dan bagaimana ia berkaitan dengan Spesifikasi Teknikal?
Terdapat perkara yang sangat berbahaya tersembunyi dalam jawapan kepada soalan-soalan ini. Itulah sebabnya pertikaian sering timbul tentang kecukupan atau kekurangan butiran keperluan yang diperlukan, tentang kefahaman dokumen oleh Pelanggan dan Kontraktor, tentang redundansi, format persembahan, dsb. Di manakah garisan antara Terma Rujukan dan Projek Teknikal?
Tugas teknikal– ini adalah dokumen berdasarkan keperluan yang dirumuskan dalam bahasa yang boleh difahami (biasa, biasa) kepada Pelanggan. Dalam kes ini, istilah industri yang boleh difahami oleh Pelanggan boleh dan harus digunakan. Seharusnya tidak ada sambungan dengan spesifik pelaksanaan teknikal. Itu. pada peringkat spesifikasi teknikal, pada dasarnya, tidak kira di platform mana keperluan ini akan dilaksanakan. Walaupun terdapat pengecualian. Jika kita bercakap tentang melaksanakan sistem berdasarkan produk perisian yang sudah sedia ada, maka pautan sedemikian boleh berlaku, tetapi hanya pada tahap borang skrin, borang laporan, dll. Penjelasan dan perumusan keperluan, serta pembangunan Terma Rujukan hendaklah dilaksanakan penganalisa perniagaan. Dan pastinya bukan pengaturcara (melainkan dia menggabungkan peranan ini, ini berlaku). Itu. orang ini mesti bercakap dengan Pelanggan dalam bahasa perniagaannya.
Projek teknikal– ini adalah dokumen yang bertujuan untuk pelaksanaan teknikal keperluan yang dirumuskan dalam Terma Rujukan. Dokumen ini menerangkan struktur data, pencetus dan prosedur tersimpan, algoritma dan perkara lain yang diperlukan pakar teknikal. Pelanggan tidak perlu mendalami perkara ini sama sekali (malah terma sedemikian mungkin tidak jelas kepadanya). Projek teknikal tidak Arkitek Sistem(menggabungkan peranan ini dengan pengaturcara adalah perkara biasa). Atau sebaliknya, sekumpulan pakar JSC yang diketuai oleh seorang arkitek. Lebih besar projek, lebih ramai orang bekerja pada Terma Rujukan.
Apa yang kita ada dalam amalan? Ia lucu untuk menonton apabila pengarah dibentangkan dengan spesifikasi teknikal untuk kelulusan, yang penuh dengan istilah teknikal, penerangan jenis data dan nilainya, struktur pangkalan data, dll. Dia, sudah tentu, cuba memahami, kerana dia perlu meluluskan , cuba mencari perkataan biasa di antara baris dan tidak kehilangan keperluan perniagaan rantaian. Adakah ini situasi biasa? Dan bagaimana ia berakhir? Sebagai peraturan, spesifikasi teknikal sedemikian diluluskan, kemudian dilaksanakan, dan dalam 80% kes, maka mereka sama sekali tidak sesuai dengan fakta kerja yang dilakukan, kerana mereka memutuskan untuk berubah, membuat semula banyak perkara, salah faham, salah sangka, dsb. dan sebagainya. Dan kemudian siri tentang menghantar kerja bermula. "Tetapi di sini bukan apa yang kami perlukan," tetapi "ini tidak akan berfungsi untuk kami," "ini terlalu rumit," "ini menyusahkan," dll. Macam kenal?!! Itu biasa kepada saya, saya terpaksa memukul lebam dalam masa yang ditetapkan.
Jadi apa yang kita ada dalam amalan? Tetapi dalam amalan, kami mempunyai sempadan yang kabur antara Terma Rujukan dan Projek Teknikal. Dia terapung di antara TK dan TP dalam pelbagai manifestasi. Dan itu buruk. Ini berlaku kerana budaya pembangunan telah menjadi lemah. Ini sebahagiannya disebabkan oleh kecekapan pakar, sebahagiannya disebabkan oleh keinginan untuk mengurangkan belanjawan dan tarikh akhir (lagipun, dokumentasi mengambil banyak masa - itu fakta). Terdapat satu lagi faktor penting yang mempengaruhi penggunaan Reka Bentuk Teknikal sebagai dokumen berasingan: pembangunan pesat alat pembangunan pesat, serta metodologi pembangunan. Tetapi ini adalah cerita yang berasingan; Saya akan mengatakan beberapa perkataan mengenainya di bawah.
Satu lagi perkara kecil tetapi penting. Kadangkala Terma Rujukan dipanggil sekeping kecil keperluan, mudah dan boleh difahami. Sebagai contoh, tingkatkan carian untuk objek mengikut beberapa syarat, tambah lajur pada laporan, dll. Pendekatan ini agak wajar, mengapa merumitkan kehidupan. Tetapi ia tidak digunakan pada projek besar, tetapi pada penambahbaikan kecil. Saya akan mengatakan ini lebih dekat dengan penyelenggaraan produk perisian. Dalam kes ini, Terma Rujukan juga boleh menerangkan penyelesaian teknikal khusus untuk melaksanakan keperluan tersebut. Contohnya, "Buat perubahan begini dan begitu kepada algoritma itu dan ini," menunjukkan prosedur khusus dan perubahan khusus untuk pengaturcara. Ini berlaku apabila sempadan antara Terma Rujukan dan Projek Teknikal dipadamkan sepenuhnya, kerana tidak ada kebolehlaksanaan ekonomi untuk mengembang kertas kerja di mana ia tidak diperlukan, tetapi dokumen yang berguna dicipta. Dan memang betul.
Adakah spesifikasi teknikal perlu sama sekali? Bagaimana pula dengan Projek Teknikal?
Adakah saya terlalu panas? Adakah ini mungkin tanpa sebarang Spesifikasi teknikal? Bayangkan ia mungkin (atau lebih tepatnya, mungkin), dan pendekatan ini mempunyai ramai pengikut, dan bilangan mereka semakin meningkat. Sebagai peraturan, selepas pakar muda membaca buku tentang Scrum, Agile dan teknologi pembangunan pesat yang lain. Sebenarnya, ini adalah teknologi yang hebat, dan ia berfungsi, tetapi mereka tidak benar-benar mengatakan "tidak perlu melakukan tugas teknikal." Mereka mengatakan "kertas kerja minimum," terutamanya yang tidak perlu, lebih dekat dengan Pelanggan, lebih spesifik dan hasil yang lebih cepat. Tetapi tiada siapa yang membatalkan rakaman keperluan, dan ini jelas dinyatakan di sana. Di sanalah keperluan ditetapkan berdasarkan tiga sifat luar biasa yang saya nyatakan di atas. Cuma, fikiran sesetengah orang distrukturkan sedemikian rupa sehingga jika sesuatu boleh dipermudahkan, maka marilah kita permudahkan sehingga ketiadaan sepenuhnya. Seperti kata Einstein " Jadikan ia semudah mungkin, tetapi tidak lebih mudah daripada itu." . Ini adalah kata-kata emas yang sesuai dengan segalanya. Jadi Tugas teknikal perlu, jika tidak, anda tidak akan melihat projek yang berjaya. Soalan lain ialah bagaimana untuk mengarangnya dan apa yang perlu disertakan di sana. Berdasarkan metodologi pembangunan pesat, anda hanya perlu memberi tumpuan kepada keperluan, dan semua "penyamaran" boleh dibuang. Pada dasarnya, saya bersetuju dengan ini.
Bagaimana pula dengan Projek Teknikal? Dokumen ini sangat berguna dan tidak kehilangan kaitannya. Lebih-lebih lagi, selalunya anda tidak boleh melakukannya tanpanya. Terutama apabila ia berkaitan dengan kerja pembangunan penyumberan luar, i.e. atas prinsip penyumberan luar. Jika anda tidak melakukan ini, anda berisiko untuk belajar banyak tentang rupa sistem yang anda fikirkan. Sekiranya Pelanggan membiasakan diri dengannya? Jika dia mahu, mengapa tidak, tetapi tidak perlu mendesak dan meluluskan dokumen ini, ia hanya akan menahan dan mengganggu kerja. Hampir mustahil untuk mereka bentuk sistem hingga ke perincian terkecil. Dalam kes ini, anda perlu terus membuat perubahan pada Reka Bentuk Teknikal, yang memerlukan banyak masa. Dan jika organisasi itu sangat birokratik, maka anda akan meninggalkan semua saraf anda di sana. Mengurangkan reka bentuk jenis ini adalah betul-betul metodologi pembangunan pesat moden yang saya nyatakan di atas. By the way, mereka semua berdasarkan XP klasik (pengaturcaraan melampau) - pendekatan yang sudah berusia kira-kira 20 tahun. Jadi buat Spesifikasi Teknikal berkualiti tinggi yang boleh difahami oleh Pelanggan, dan gunakan Reka Bentuk Teknikal sebagai dokumen dalaman untuk hubungan antara arkitek sistem dan pengaturcara.
Perincian yang menarik tentang reka bentuk teknikal: beberapa alat pembangunan yang direka berdasarkan prinsip reka bentuk berorientasikan subjek (seperti 1C dan yang serupa) menganggap bahawa reka bentuk (bermaksud proses dokumentasi) hanya diperlukan dalam kawasan yang benar-benar kompleks di mana interaksi antara keseluruhan subsistem diperlukan. Dalam kes paling mudah, sebagai contoh, mencipta direktori atau dokumen, hanya keperluan perniagaan yang dirumus dengan betul sudah mencukupi. Ini juga dibuktikan dengan strategi perniagaan platform ini dari segi pakar latihan. Jika anda melihat kad peperiksaan pakar (itulah yang dipanggil, bukan "pengaturcara"), anda akan melihat bahawa hanya terdapat keperluan perniagaan, dan cara melaksanakannya dalam bahasa program adalah tugas pakar. Itu. sebahagian daripada masalah yang Projek Teknikal bertujuan untuk menyelesaikan, pakar mesti menyelesaikan "dalam kepalanya" (kita bercakap tentang tugas-tugas kerumitan sederhana), di sini dan sekarang, mengikuti piawaian pembangunan dan reka bentuk tertentu, yang sekali lagi dibentuk oleh syarikat 1C untuk platformnya. Oleh itu, daripada dua pakar yang hasil kerjanya kelihatan sama, seorang boleh lulus peperiksaan, tetapi yang lain tidak boleh, kerana secara terang-terangan melanggar piawaian pembangunan. Iaitu, jelas diandaikan bahawa pakar mesti mempunyai kelayakan sedemikian rupa sehingga mereka boleh mereka bentuk tugas biasa secara bebas, tanpa penglibatan arkitek sistem. Dan pendekatan ini berkesan.
Mari kita teruskan mengkaji soalan: "Apakah keperluan yang perlu disertakan dalam Terma Rujukan?"
Perumusan keperluan untuk sistem maklumat. Struktur Terma Rujukan
Mari kita jelaskan dengan segera: kita akan bercakap secara khusus tentang merumuskan keperluan untuk sistem maklumat, i.e. dengan mengandaikan bahawa kerja membangunkan keperluan perniagaan, memformalkan proses perniagaan dan semua kerja perundingan sebelumnya telah pun selesai. Sudah tentu, beberapa penjelasan boleh dibuat pada peringkat ini, tetapi hanya penjelasan. Projek automasi itu sendiri tidak menyelesaikan masalah perniagaan - ingat ini. Ini adalah aksiom. Atas sebab tertentu, sesetengah pengurus cuba menafikannya, percaya bahawa jika mereka membeli program itu, pesanan akan datang kepada perniagaan yang huru-hara. Tetapi aksiom adalah aksiom kerana ia tidak memerlukan bukti.
Seperti mana-mana aktiviti, keperluan merumus boleh (dan harus) dibahagikan kepada beberapa peringkat. Semuanya ada masanya. Ini adalah kerja intelektual yang sukar. Dan, jika anda merawatnya dengan perhatian yang tidak mencukupi, maka hasilnya akan sesuai. Menurut anggaran pakar, kos membangunkan Terma Rujukan boleh menjadi 30-50%. Saya pun sependapat. Walaupun 50 mungkin terlalu banyak. Lagipun, Spesifikasi Teknikal bukanlah dokumen terakhir yang mesti dibangunkan. Lagipun, mesti ada reka bentuk teknikal. Variasi ini disebabkan oleh platform automasi, pendekatan dan teknologi yang berbeza yang digunakan oleh pasukan projek semasa pembangunan. Sebagai contoh, jika kita bercakap tentang pembangunan dalam bahasa klasik seperti C++, maka reka bentuk teknikal yang terperinci amat diperlukan. Jika kita bercakap tentang melaksanakan sistem pada platform 1C, maka keadaan dengan reka bentuk agak berbeza, seperti yang kita lihat di atas (walaupun, apabila membangunkan sistem dari awal, ia direka mengikut skema klasik).
Walaupun pernyataan keperluan adalah bahagian utama Spesifikasi teknikal, dan dalam beberapa kes ia menjadi satu-satunya bahagian spesifikasi teknikal, anda harus memberi perhatian kepada fakta bahawa ini adalah dokumen penting, dan ia harus disediakan dengan sewajarnya. Di mana untuk bermula? Pertama sekali, anda perlu bermula dengan kandungan. Tulis kandungan dan kemudian mula mengembangkannya. Secara peribadi, saya melakukan ini: mula-mula saya melakar kandungan, menerangkan matlamat, semua maklumat pengenalan, dan kemudian turun ke bahagian utama - perumusan keperluan. Kenapa tidak sebaliknya? Saya tidak tahu, ia lebih mudah untuk saya. Pertama, ini adalah bahagian masa yang lebih kecil (berbanding dengan keperluan), dan kedua, semasa anda menerangkan semua maklumat pengenalan, anda mengikuti perkara utama. Nah, siapa yang suka. Lama kelamaan, anda akan membangunkan templat Spesifikasi Teknikal anda sendiri. Sebagai permulaan, saya cadangkan mengambil sebagai kandungan tepat yang diterangkan dalam GOST. Ia sesuai untuk kandungan! Kemudian kami mengambil dan mula menerangkan setiap bahagian, tidak lupa tentang cadangan tiga sifat berikut: kebolehfahaman, kekhususan dan kebolehujian. Mengapa saya bertegas dengan perkara ini? Lebih lanjut mengenai perkara ini dalam bahagian seterusnya. Dan sekarang saya bercadang untuk melalui titik-titik spesifikasi teknikal yang disyorkan dalam GOST.
- maklumat am;
- tujuan dan matlamat penciptaan (pembangunan) sistem;
- ciri-ciri objek automasi;
- Keperluan Sistem;
- komposisi dan kandungan kerja untuk mencipta sistem;
- prosedur untuk kawalan dan penerimaan sistem;
- keperluan untuk komposisi dan kandungan kerja untuk menyediakan objek automasi untuk meletakkan sistem beroperasi;
- keperluan dokumentasi;
- sumber pembangunan.
Secara keseluruhan, 9 bahagian, setiap satunya juga dibahagikan kepada subseksyen. Mari kita lihat mereka dalam susunan. Untuk kemudahan, saya akan membentangkan semuanya dalam bentuk jadual untuk setiap item.
Bahagian 1. maklumat am.
| Cadangan mengikut GOST | |
| nama penuh sistem dan simbolnya; | Segala-galanya jelas di sini: kami menulis apa yang akan dipanggil sistem, nama ringkasnya |
| kod subjek atau kod (nombor) kontrak; | Ini tidak berkaitan, tetapi anda boleh menentukannya jika perlu |
| nama perusahaan (persatuan) pembangun dan pelanggan (pengguna) sistem dan butirannya; | nyatakan siapa (organisasi mana) akan mengusahakan projek tersebut. Anda juga boleh menentukan peranan mereka. Anda juga boleh mengalih keluar bahagian ini (agak formal). |
| senarai dokumen berdasarkan sistem yang dicipta, oleh siapa dan bila dokumen ini diluluskan; | Maklumat berguna. Di sini anda harus menunjukkan dokumentasi kawal selia dan rujukan yang diberikan kepada anda untuk membiasakan diri dengan bahagian tertentu keperluan |
| tarikh mula dan tamat yang dirancang untuk kerja mencipta sistem; | Permintaan untuk masa. Kadang-kadang mereka menulis tentang ini dalam spesifikasi teknikal, tetapi lebih kerap perkara sedemikian diterangkan dalam kontrak kerja |
| maklumat mengenai sumber dan prosedur untuk membiayai kerja; | Sama seperti dalam perenggan sebelumnya tentang tarikh akhir. Lebih relevan untuk pesanan kerajaan (untuk kakitangan kerajaan) |
| prosedur untuk pendaftaran dan pembentangan kepada pelanggan hasil kerja untuk mencipta sistem (bahagiannya), mengenai pengeluaran dan pelarasan cara individu (perkakasan, perisian, maklumat) dan perisian dan perkakasan (perisian dan metodologi) kompleks sistem. | Saya tidak nampak keperluan untuk perkara ini, kerana... Keperluan dokumentasi ditetapkan secara berasingan, dan di samping itu terdapat keseluruhan bahagian berasingan "Prosedur untuk kawalan dan penerimaan" sistem. |
Bahagian 2. tujuan dan matlamat penciptaan (pembangunan) sistem.
| Cadangan mengikut GOST | Apa yang perlu dilakukan dalam amalan |
| Tujuan sistem | Di satu pihak, tujuannya mudah. Tetapi dinasihatkan untuk merumuskannya secara khusus. Jika anda menulis sesuatu seperti "automasi perakaunan gudang berkualiti tinggi di syarikat X", maka anda boleh membincangkan hasilnya untuk masa yang lama selepas ia selesai, walaupun tanpa mengira perumusan keperluan yang baik. Kerana Pelanggan sentiasa boleh mengatakan bahawa dengan kualiti dia bermaksud sesuatu yang lain. Secara umum, anda boleh merosakkan saraf satu sama lain, tetapi mengapa? Adalah lebih baik untuk segera menulis sesuatu seperti ini: "Sistem ini direka untuk mengekalkan rekod gudang dalam syarikat X mengikut keperluan yang dinyatakan dalam Spesifikasi Teknikal ini." |
| Matlamat mencipta sistem | Matlamat pastinya bahagian penting. Jika kita ingin memasukkannya, maka kita mesti dapat merumuskan matlamat ini. Jika anda mengalami kesukaran merumuskan matlamat, maka lebih baik untuk mengecualikan bahagian ini sama sekali. Contoh matlamat yang tidak berjaya: "Pastikan pengurus melengkapkan dokumen dengan cepat." Apa yang cepat? Ini kemudiannya boleh dibuktikan tanpa henti. Jika ini penting, maka adalah lebih baik untuk merumuskan semula matlamat ini seperti berikut: "Pengurus jualan sepatutnya dapat mengeluarkan dokumen "Jualan barang" sebanyak 100 baris dalam masa 10 minit. Matlamat seperti ini mungkin muncul jika, sebagai contoh, seorang pengurus sedang meluangkan masa kira-kira sejam untuk perkara ini, yang terlalu banyak untuk syarikat itu dan ia penting bagi mereka. Dalam rumusan ini, matlamat sudah bersilang dengan keperluan, yang agak semula jadi, kerana apabila mengembangkan pokok matlamat (iaitu, membahagikannya kepada matlamat berkaitan yang lebih kecil), kita sudah akan semakin hampir dengan keperluan. Oleh itu, anda tidak sepatutnya terbawa-bawa. |
Secara umum, keupayaan untuk mengenal pasti matlamat, merumuskannya, dan membina pokok matlamat adalah topik yang berasingan sepenuhnya. Ingat perkara utama: jika anda tahu bagaimana, tulis, jika anda tidak pasti, jangan menulis sama sekali. Apa yang berlaku jika anda tidak merumuskan matlamat? Anda akan bekerja mengikut keperluan, ini sering diamalkan.
Bahagian 3. Ciri-ciri objek automasi.
Bahagian 4. Keperluan Sistem
GOST menguraikan senarai keperluan tersebut:
- keperluan untuk struktur dan fungsi sistem;
- keperluan untuk bilangan dan kelayakan kakitangan sistem dan cara operasi mereka;
- penunjuk destinasi;
- keperluan kebolehpercayaan;
- keperluan keselamatan;
- keperluan untuk ergonomik dan estetika teknikal;
- keperluan kebolehangkutan untuk pembesar suara mudah alih;
- keperluan untuk operasi, penyelenggaraan, pembaikan dan penyimpanan komponen sistem;
- keperluan untuk melindungi maklumat daripada capaian yang tidak dibenarkan;
- keperluan untuk keselamatan maklumat sekiranya berlaku kemalangan;
- keperluan untuk perlindungan daripada pengaruh luar;
- keperluan untuk ketulenan paten;
- keperluan untuk penyeragaman dan penyatuan;
Walaupun fakta bahawa bahagian utama pastinya akan menjadi bahagian dengan keperluan khusus (berfungsi), bahagian ini juga boleh menjadi sangat penting (dan dalam kebanyakan kes ia adalah). Perkara yang mungkin penting dan berguna:
- Syarat Kelayakan. Ada kemungkinan sistem yang dibangunkan memerlukan latihan semula pakar. Ini boleh menjadi pengguna sistem masa depan dan pakar IT yang diperlukan untuk menyokongnya. Perhatian yang tidak mencukupi kepada isu ini sering berkembang menjadi masalah. Sekiranya kelayakan kakitangan sedia ada jelas tidak mencukupi, adalah lebih baik untuk menentukan keperluan untuk organisasi latihan, program latihan, masa, dll.
- Keperluan untuk melindungi maklumat daripada capaian yang tidak dibenarkan. Tiada ulasan di sini. Ini adalah tepat keperluan untuk mengehadkan akses kepada data. Sekiranya keperluan sedemikian dirancang, maka ia perlu ditulis secara berasingan, sedetail mungkin, mengikut peraturan yang sama seperti keperluan fungsian (kefahaman, kekhususan, kebolehujian). Oleh itu, keperluan ini boleh dimasukkan ke dalam bahagian dengan keperluan fungsian
- Keperluan untuk penyeragaman. Jika terdapat sebarang piawaian reka bentuk yang boleh digunakan untuk projek, ia boleh dimasukkan dalam keperluan. Sebagai peraturan, keperluan sedemikian dimulakan oleh perkhidmatan IT Pelanggan. Sebagai contoh, syarikat 1C mempunyai keperluan untuk reka bentuk kod program, reka bentuk antara muka, dsb.;
- Keperluan untuk struktur dan fungsi sistem. Di sini keperluan untuk menyepadukan sistem antara satu sama lain boleh diterangkan, dan penerangan tentang seni bina umum dibentangkan. Lebih kerap, keperluan penyepaduan secara amnya dipisahkan kepada bahagian yang berasingan atau malah Spesifikasi Teknikal yang berasingan, kerana keperluan ini boleh menjadi agak rumit.
Semua keperluan lain adalah kurang penting dan tidak perlu diterangkan. Pada pendapat saya, mereka hanya membuat dokumentasi lebih berat dan mempunyai sedikit manfaat praktikal. Dan sangat sukar untuk menerangkan keperluan ergonomik dalam bentuk keperluan umum, lebih baik untuk memindahkannya kepada yang berfungsi. Sebagai contoh, keperluan "Dapatkan maklumat tentang harga produk dengan menekan satu butang sahaja" mungkin dirumuskan. Pada pendapat saya, ini masih lebih dekat dengan keperluan fungsi tertentu, walaupun ia berkaitan dengan ergonomik.Keperluan untuk fungsi (tugas) yang dilakukan oleh sistem Ini adalah perkara utama dan utama yang akan menentukan kejayaan. Walaupun segala-galanya dilakukan dengan sempurna, dan bahagian ini adalah "3", maka hasil projek akan menjadi yang terbaik "3", atau projek itu akan gagal sama sekali. Inilah yang akan kita bincangkan dengan lebih terperinci dalam artikel kedua, yang akan disertakan dalam surat berita keluaran ke-5. Setakat ini, "peraturan tiga sifat keperluan" yang saya bicarakan terpakai. Keperluan untuk jenis cagaran
GOST mengenal pasti jenis berikut:
- Matematik
- Bermaklumat
- Linguistik
- Perisian
- Teknikal
- Metrologi
- berorganisasi
- berkaedah
- dan lain lain…
Pada pandangan pertama, keperluan ini mungkin kelihatan tidak penting. Dalam kebanyakan projek ini adalah benar. Tetapi tidak selalu. Bila hendak menerangkan keperluan ini:
- Tiada keputusan telah dibuat mengenai pembangunan bahasa (atau platform) yang akan dijalankan;
- Sistem ini memerlukan antara muka berbilang bahasa (contohnya, Rusia/Inggeris)
- Untuk sistem berfungsi, unit berasingan mesti diwujudkan atau pekerja baharu mesti diambil;
- Untuk sistem berfungsi, Pelanggan mesti menjalani perubahan dalam kaedah kerja dan perubahan ini mesti dinyatakan dan dirancang;
- Penyepaduan dengan mana-mana peralatan dijangka dan keperluan dikenakan ke atasnya (contohnya, pensijilan, keserasian, dsb.)
- Situasi lain mungkin, semuanya bergantung pada matlamat khusus projek.
Bahagian 5. Komposisi dan kandungan kerja untuk mencipta sistem
Seksyen 6. Prosedur untuk kawalan dan penerimaan sistem
Keperluan am untuk penerimaan kerja secara berperingkat (senarai perusahaan dan organisasi yang mengambil bahagian, tempat dan masa), prosedur untuk penyelarasan dan kelulusan dokumentasi penerimaan; Saya amat mengesyorkan agar anda bertanggungjawab terhadap prosedur untuk menyerahkan kerja dan menyemak sistem. Inilah sebabnya mengapa keperluan yang boleh diuji diperlukan. Tetapi kehadiran keperluan yang boleh diuji mungkin tidak mencukupi apabila sistem dihantar jika prosedur untuk penerimaan dan pemindahan kerja tidak dinyatakan dengan jelas. Sebagai contoh, perangkap biasa: sistem dibina dan beroperasi sepenuhnya, tetapi Pelanggan atas sebab tertentu tidak bersedia untuk bekerja di dalamnya. Sebab ini boleh jadi apa-apa: tiada masa, matlamat telah berubah, seseorang berhenti, dsb. Dan dia berkata: "Memandangkan kami belum bekerja dalam sistem baharu, ini bermakna kami tidak dapat memastikan ia berfungsi." Jadi belajar mengenal pasti peringkat kerja dengan betul, dan cara menyemak keputusan peringkat ini. Selain itu, kaedah sedemikian mestilah jelas kepada Pelanggan dari awal lagi. Jika ia ditetapkan pada tahap Spesifikasi Teknikal, maka anda sentiasa boleh beralih kepada mereka jika perlu dan menyelesaikan kerja dengan pemindahan.
Seksyen 7. Keperluan untuk komposisi dan kandungan kerja untuk menyediakan objek automasi untuk pentauliahan sistem
Mungkin terdapat sebarang peraturan lain untuk memasukkan maklumat yang diterima pakai oleh syarikat (atau dirancang). Sebagai contoh, maklumat tentang kontrak pernah dimasukkan sebagai rentetan teks dalam sebarang bentuk, tetapi kini nombor berasingan, tarikh berasingan, dsb. diperlukan. Terdapat banyak syarat sedemikian. Sesetengah daripada mereka mungkin dilihat dengan rintangan daripada kakitangan, jadi adalah lebih baik untuk mendaftarkan semua kes sedemikian pada tahap keperluan untuk susunan kemasukan data. Perubahan yang perlu dibuat dalam objek automasi
Penciptaan syarat untuk berfungsi objek automasi, di mana pematuhan sistem yang dicipta dengan keperluan yang terkandung dalam spesifikasi teknikal dijamin. Sebarang perubahan yang mungkin diperlukan. Sebagai contoh, syarikat itu tidak mempunyai rangkaian tempatan, kumpulan komputer yang sudah lapuk di mana sistem tidak akan berfungsi.
Mungkin beberapa maklumat yang diperlukan telah diproses di atas kertas, dan kini ia perlu dimasukkan ke dalam sistem. Jika anda tidak melakukan ini, maka beberapa modul tidak akan berfungsi, dsb.
Mungkin sesuatu telah dipermudahkan, tetapi kini perlu diambil kira dengan lebih terperinci, jadi seseorang mesti mengumpul maklumat mengikut peraturan tertentu.
Senarai ini boleh panjang, lihat kes khusus projek anda. Penciptaan jabatan dan perkhidmatan yang diperlukan untuk berfungsi sistem;
Masa dan prosedur untuk kakitangan dan latihan Kami telah pun membincangkan perkara ini sebelum ini. Mungkin sistem sedang dibangunkan untuk struktur atau jenis aktiviti baharu yang tidak wujud sebelum ini. Sekiranya tiada kakitangan yang sesuai, malah mereka yang terlatih, sistem itu tidak akan berfungsi, tidak kira betapa cekapnya ia dibina.
Seksyen 8. Keperluan Dokumentasi
Pertimbangkan cara manual pengguna akan dibentangkan.
Mungkin Pelanggan telah menerima piawaian korporat, yang bermaksud kita perlu merujuk kepada mereka.
Mengabaikan keperluan dokumentasi selalunya membawa kepada akibat yang paling tidak dijangka pada projek. Sebagai contoh, semuanya telah selesai dan semuanya berfungsi. Pengguna juga tahu cara bekerja. Tiada perjanjian atau perbualan sama sekali tentang dokumentasi. Dan tiba-tiba, apabila menyerahkan kerja, salah seorang pengurus tertinggi Pelanggan, yang tidak mengambil bahagian dalam projek itu, tetapi terlibat dalam menerima kerja, bertanya kepada anda: "Di manakah manual pengguna?" Dan ia mula meyakinkan anda bahawa tidak perlu bersetuju dengan ketersediaan manual pengguna, ini sepatutnya "tentu saja" tersirat. Dan itu sahaja, dia tidak mahu mengambil kerja anda. Atas perbelanjaan siapa anda akan membangunkan garis panduan? Banyak pasukan telah jatuh untuk mata kail ini.
Bahagian 9. Sumber Pembangunan
Oleh itu, adalah lebih baik merujuk kepada laporan tinjauan dan keperluan orang penting sahaja.
Oleh itu, kami telah mempertimbangkan semua bahagian yang boleh disertakan dalam Terma Rujukan. “Boleh” dan bukan “Mesti” dengan tepat kerana sebarang dokumen mesti dibangunkan untuk mencapai keputusan. Oleh itu, jika jelas kepada anda bahawa bahagian tertentu tidak akan membawa anda lebih dekat dengan hasilnya, maka anda tidak memerlukannya dan anda tidak perlu membuang masa di atasnya.
Tetapi tiada spesifikasi teknikal yang kompeten boleh dilakukan tanpa perkara utama: keperluan fungsian. Saya ingin ambil perhatian bahawa dalam amalan Spesifikasi Teknikal sedemikian berlaku, dan bagaimana! Terdapat orang yang akan dapat memisahkan perairan di semua bahagian, menerangkan keperluan umum secara umum, dan dokumen itu ternyata sangat berat, dan terdapat banyak perkataan bijak di dalamnya, malah Pelanggan mungkin suka ia (iaitu, dia akan meluluskannya). Tetapi ia mungkin tidak berfungsi mengikutnya, i.e. Ia mempunyai sedikit kegunaan praktikal. Dalam kebanyakan kes, dokumen sedemikian dilahirkan apabila anda perlu mendapatkan banyak wang khusus untuk Terma Rujukan, tetapi ia perlu dilakukan dengan cepat dan tanpa menyelami butiran. Dan terutamanya jika diketahui bahawa perkara itu tidak akan pergi lebih jauh, atau orang yang sama sekali berbeza akan melakukannya. Secara amnya, sekadar mengurus bajet terutamanya belanjawan negeri.
Dalam artikel kedua, kami hanya akan bercakap mengenai bahagian 4 "Keperluan sistem", dan secara khusus kami akan merumuskan keperluan atas sebab kejelasan, kekhususan dan kebolehujian.
Mengapa keperluan mesti jelas, khusus dan boleh diuji.
Kerana amalan menunjukkan: pada mulanya, kebanyakan spesifikasi teknikal yang dibangunkan oleh pakar sama ada ternyata tidak dalam permintaan (tidak sesuai dengan realiti), atau menjadi masalah bagi orang yang mesti melaksanakannya, kerana Pelanggan mula memanipulasi syarat dan keperluan yang tidak jelas. Saya akan memberikan beberapa contoh tentang frasa yang ditemui, apa yang menyebabkannya, dan kemudian saya akan cuba memberikan cadangan tentang cara mengelakkan masalah tersebut.
Adakah keperluan ini boleh diuji? Ia kelihatan seperti perkara yang mudah, tetapi bagaimana anda boleh menyemaknya jika tidak ada yang spesifik?
Bagaimana ini boleh dirumuskan semula: "Jumlah kos yang dinyatakan dalam dokumen mesti diagihkan kepada semua barang yang dinyatakan dalam dokumen ini mengikut perkadaran dengan kos barangan ini." Ternyata jelas dan spesifik. Cara menyemak juga tidak sukar.
Ergonomik Program ini mesti mempunyai antara muka yang mesra pengguna. Saya harus mengakui, saya pernah terpaksa melanggan formula ini sendiri - terdapat banyak masalah kemudian. Sudah tentu, formulasi sedemikian tidak sepatutnya wujud. Tiada butiran khusus di sini, mahupun peluang untuk mengesahkan keperluan ini. Walaupun, sudah tentu, ia boleh difahami (subjektif). Tiada cara untuk merumuskannya semula; setiap elemen "kemudahan" mesti diterangkan secara terperinci, memandangkan Pelanggan berkeras mengenainya. Sebagai contoh:
- Garis hendaklah ditambah pada dokumen kedua-duanya dengan mengklik pada butang "Tambah" dan dengan menekan kekunci "masukkan", serta oleh pengguna yang memasukkan sebahagian daripada nama;
- Apabila melihat senarai produk, anda boleh mencari mengikut nama, kod bar dan artikel;
- Dan lain-lain.
Pembezaan hak aksesAkses kepada data keuntungan seharusnya hanya tersedia kepada pengarah kewangan. Adakah itu jelas? Hampir. Benar, keuntungan berbeza-beza, kita perlu jelaskan. Sudah tentu tidak. Bagaimanakah ini kelihatan seperti dalam pelaksanaan? Jika kita bercakap tentang keuntungan kasar, maka perlu untuk mengehadkan akses kepada data mengenai kos pembelian, kerana jika tidak, keuntungan kasar tidak akan sukar untuk dikira, kerana data mengenai kos jualan diketahui oleh pelbagai orang. Perkara yang berkaitan dengan hak akses mesti ditangani dengan sangat berhati-hati. Dan jika motivasi pengurus jualan adalah berdasarkan keuntungan kasar, maka keperluan ini juga bercanggah antara satu sama lain, kerana pengurus tidak akan dapat mengesahkan perkara ini. Jika kami ingin memasukkan keperluan sedemikian, maka kami perlu menentukan laporan dan objek sistem tertentu yang menunjukkan bahagian data yang sepatutnya tersedia untuk kategori orang tertentu. Dan pertimbangkan setiap kes sedemikian secara individu. Produktiviti Laporan jualan harus dijana dalam masa 1 minit. Ya, saya faham. Malah terdapat had masa tertentu: 1 minit. Tetapi tidak diketahui jenis perincian yang dijangkakan: untuk setiap produk, kumpulan produk, pelanggan atau sesuatu yang lain? Ia boleh dirumuskan seperti ini: "Laporan jualan oleh pelanggan dengan butiran untuk setiap item produk (lihat sampel) harus tidak dipaparkan lebih daripada 1 minit, dengan syarat bilangan produk dalam sampel tidak melebihi 5000 baris.”
Saya harap idea itu jelas. Jika anda mempunyai soalan khusus, tulis, saya akan cuba membantu.
Kepada Terma rujukan terdapat lebih spesifik, terdapat banyak cadangan. Malah terdapat senarai perkataan yang tidak disyorkan untuk digunakan dalam Spesifikasi Teknikal. K. Wiegers menulis dengan menarik tentang perkara ini dalam bukunya "Pembangunan Keperluan Perisian." Saya akan memberikan yang paling menarik dan mudah, pada pendapat saya, cadangan:
- Anda tidak boleh menggunakan perkataan yang mempunyai banyak sinonim. Jika ini perlu, adalah lebih baik untuk memberikan definisi istilah yang jelas dalam bahagian "Terma dan Takrifan" Terma Rujukan.
- Anda harus cuba untuk tidak menggunakan ayat yang panjang;
- Jika keperluan kelihatan terlalu umum kepada anda, ia perlu diperincikan kepada keperluan yang lebih kecil tetapi khusus;
- Gunakan lebih banyak gambar rajah, graf, jadual, lukisan - dengan cara ini maklumat dilihat lebih mudah;
- Perkataan yang perlu dielakkan ialah: “berkesan”, “mencukupi”, “mudah”, “jelas”, “cepat”, “fleksibel”, “diperbaiki”, “optimum”, “telus”, “mampan”, “mencukupi”, “ mesra", "mudah", dsb. Senarai boleh diteruskan, tetapi saya rasa idea itu jelas (cuba teruskan sendiri).
Semua yang ditulis di atas adalah maklumat penting, tetapi bukan yang paling penting. Seperti yang anda ingat, pada permulaan artikel saya memanggil ini istilah "penyamaran", kerana. perkara paling penting yang akan membentuk sekurang-kurangnya 90% daripada masa dan kerumitan kerja pada dokumen ialah mengenal pasti dan merumuskan keperluan. Dan anda masih perlu dapat mengumpul, menstruktur dan merumuskan maklumat tentang keperluan. Ini, dengan cara ini, mempunyai banyak persamaan antara tinjauan aktiviti perusahaan dan penerangan seterusnya mengenai proses perniagaan. Tetapi terdapat juga perbezaan penting. Salah satu perbezaan utama ini ialah kehadiran peringkat membina prototaip sistem masa hadapan, atau kerana ia juga dipanggil "model sistem maklumat".
Dalam artikel seterusnya kita hanya akan bercakap tentang kaedah untuk mengenal pasti keperluan, dan juga mempertimbangkan perkara biasa antara kerja mengumpul keperluan untuk sistem maklumat dan mengumpul maklumat untuk menerangkan proses perniagaan.
Jenis kerja apabila mengumpul keperluan untuk sistem perakaunan dan maklumat untuk menerangkan proses perniagaan. Bahagian 2
Dalam bahagian ini kita akan bercakap tentang cara mengatur peringkat pengumpulan keperluan, apa yang harus terdiri daripada dan alat apa yang boleh digunakan. Saya ulangi bahawa dari sudut pandangan peringkat, kerja ini sangat serupa dengan tinjauan perusahaan untuk menerangkan proses perniagaan.
Seperti yang biasa berlaku dalam kehidupan:
| Ini adalah bagaimana ia berlaku dalam kebanyakan projek. |
|
| Bagaimana ini berlaku |
|
| Sudah jelas bahawa ada sebab untuk kegembiraan, terutamanya jika projek itu besar, tidak ada yang salah dengan itu! Perkara utama adalah untuk tidak bergembira terlalu lama, menangguhkan permulaan kerja sebenar, mulai sekarang masa akan bergerak secara berbeza. | |
| Biasanya proses ini terhad kepada beberapa mesyuarat dengan pihak pengurusan, kemudian dengan ketua jabatan. Setelah merekodkan "desakan" tertentu di pihak Pelanggan, ia direkodkan dalam bentuk rumusan umum. Kadangkala dokumentasi sedia ada ditambah kepada ini (seseorang pernah cuba menjalankan tinjauan, dokumen mengikut peraturan sedia ada, bentuk laporan yang digunakan). Anehnya, selepas ini, majoriti pelaksana sistem automasi dengan gembira berseru: "ya, sistem kami mempunyai semua ini. ! Baiklah, ubah suai sedikit dan semuanya akan berfungsi.” Apabila ditanya sama ada hendak membincangkan cara perkara harus berfungsi (atau cara proses tertentu dilakukan) dengan pengguna akhir, jawapannya biasanya tidak. Pendapat dinyatakan bahawa pemimpin mengetahui segala-galanya untuk orang bawahannya. Tetapi sia-sia... Di sebalik ini terdapat banyak perangkap dan halangan, dan menghantar kerja boleh bertukar menjadi maraton di sepanjang laluan berhalangan. Seperti yang anda ketahui, adalah kebiasaan untuk berlari maraton di jalan yang rata, dan berlari dengan halangan hanya boleh dilakukan dalam jarak yang dekat (anda mungkin tidak selesai). | |
| Mendokumentasikan hasil kerja | Selepas ini, dokumentasi keputusan bermula, bergantung pada matlamat kerja: Jika perlu untuk membangunkan Spesifikasi Teknikal, perunding mula meletakkan maklumat yang diterima ke dalam templat dokumen yang disediakan supaya ia kelihatan cantik dan keperluan utama adalah direkodkan (yang disuarakan oleh pihak pengurusan, jika tidak, mereka mungkin tidak meluluskan). Memahami bahawa dalam amalan Terma Rujukan sedemikian tidak digunakan secara khusus dan segala-galanya perlu difikirkan "sepanjang perjalanan", beliau menetapkan matlamat utama Terma Rujukan sebagai masa minimum untuk penyelarasan dan kelulusan. Dan, jika boleh, maklumat untuk anggaran kasar kos kerja masa depan (dengan cara itu, juga penting). Jika anda perlu menerangkan proses perniagaan. Cukup aneh, tetapi selalunya semua tindakan sebelumnya kelihatan serupa, seperti halnya dengan pembangunan Spesifikasi Teknikal. Satu-satunya perbezaan adalah dalam dokumentasi. Terdapat pilihan di sini: perunding menerangkan proses dalam perkataan sewenang-wenangnya atau menggunakan sebarang peraturan untuk menerangkan proses perniagaan (notasi). Dalam kes pertama, dokumen sedemikian ternyata serupa dengan Spesifikasi Teknikal. Malah berlaku bahawa jika anda menggantikan halaman tajuk, anda tidak akan melihat apa-apa perbezaan. Dalam kes kedua, penekanan sering diberikan bukan pada pematuhan dengan realiti, tetapi pada "ketepatan penerangan," i.e. pematuhan rasmi kepada peraturan penerangan. Malangnya, kedua-dua pilihan bukanlah amalan terbaik, kerana lebih bersifat formal dan tidak membawa banyak faedah. |
Mengapakah amalan itu berkembang seperti yang diterangkan di atas? Terus terang, saya tidak tahu. Tanya sesiapa, tiada siapa yang tahu. Pada masa yang sama, keadaan tidak berubah dengan cepat, walaupun orang sentiasa membincangkan topik ini, bertukar pengalaman, menulis buku. Ia juga mungkin disebabkan oleh fakta bahawa ramai pakar datang dari perniagaan lain dan mempelajari segala-galanya dalam amalan, i.e. pengalaman mereka terbentuk dalam persekitaran di mana mereka mendapati diri mereka. Sikap universiti dan ketiadaan keinginan mereka untuk mendekati realiti juga adalah fakta yang diketahui, tetapi kadang-kadang saya terkejut dengan kedudukan mereka. Sebagai contoh, saya mempunyai kes apabila seorang pelajar siswazah, seorang pakar berbakat, ingin menulis tesis pada platform 1C (pembangunan industri yang baik), tetapi jabatan itu memberitahunya bahawa tanpa mengira topik, dia tidak boleh bergantung pada " cemerlang” gred, kerana 1C bukan sistem yang serius. Perkara di sini bukanlah kesungguhan dan objektiviti pendapat ini, tetapi hakikat bahawa tugas primitif dalam bahasa pengaturcaraan klasik segera dianggap layak untuk penarafan "cemerlang".
Mari cuba berikan proses yang dibincangkan di atas pendekatan yang lebih sistematik. Apakah rupa dia kemudian?
Seperti yang anda lihat, proses itu berakhir dengan soalan, kerana Pada ketika ini, kerja masih jauh dari selesai, dan kemudian perkara yang paling sukar dan paling praktikal akan bermula - apa yang akan menentukan kebolehgunaan hasil yang diperoleh dalam kehidupan sebenar. Inilah yang akan menentukan nasib kerja sebelumnya: sama ada ia akan pergi ke almari (di rak atau di tempat lain), atau ia akan mewakili sumber maklumat yang berharga. Dan lebih baik jika ia menjadi model untuk projek seterusnya.
Saya ingin ambil perhatian terutamanya bahawa sehingga langkah terakhir dalam rajah (di mana persoalannya), prinsip umum mengumpul maklumat mengenai aktiviti syarikat kelihatan sama, tidak kira apa yang anda merancang untuk lakukan pada masa hadapan, menerangkan proses perniagaan atau melaksanakan sistem automatik. Ya, urutan langkah itu sendiri adalah sama, tetapi alat yang digunakan dalam sesetengahnya mungkin berbeza. Kami pasti akan mempertimbangkan perkara ini apabila kami mengkaji kaedah dan alat peringkat individu. Kami akan melakukan ini secara terperinci dalam artikel berasingan, tetapi sekarang kami hanya akan mempertimbangkan perkara yang paling penting. Langkah selanjutnya akan berbeza dan akan ditentukan oleh perkara yang diperlukan daripada projek: menerangkan proses perniagaan atau melaksanakan sistem perakaunan.
Mari kita lihat bagaimana kita boleh menyusun semula pendekatan untuk mengumpul maklumat tentang aktiviti syarikat.
| Bagaimana ini boleh berlaku dengan organisasi kerja yang lebih cekap |
|
| Bagaimana ini berlaku |
|
| Keputusan telah dibuat, projek akan dilancarkan! | Tiada apa-apa yang berubah di sini berbanding dengan pilihan pertama, emosi tidak dibatalkan |
| Kami mengadakan pertemuan dengan pengurus dan mengumpul beberapa maklumat tentang visi mereka tentang keputusan. | Langkah ini juga kekal, dan ia amat penting. Tetapi tujuan utama pertemuan pertama (atau beberapa mesyuarat) dengan pengurus dan pemilik adalah untuk mengenali satu sama lain. Mengenali orang dan syarikat terlebih dahulu. Matlamat dan hasrat yang dirumuskan pada mesyuarat agung sedemikian boleh menjadi sangat berbeza, termasuk hebat. Kesemua mereka, sudah tentu, akan didengari, tetapi ia bukan fakta bahawa ia akan dilaksanakan. Dengan menyelami lebih mendalam dalam perniagaan syarikat, matlamat lain akan muncul dan matlamat sebelumnya akan ditolak. Apa yang saya maksudkan ialah mustahil untuk merumuskan matlamat yang jelas dari mesyuarat awal; semua ini memerlukan kajian yang teliti. Pada mesyuarat sedemikian, adalah perlu untuk mencatat semua mesej daripada pemilik dan pegawai atasan, supaya kemudian anda boleh kembali kepada mereka dan membincangkannya apabila jumlah maklumat yang mencukupi telah dikumpulkan. Malah keperluan yang kelihatan mudah mungkin menjadi mustahil untuk dilaksanakan atau sangat intensif buruh. |
| Pembentukan kumpulan kerja daripada Pelanggan dan Kontraktor, pengagihan peranan | Adalah perlu untuk memutuskan siapa yang akan bekerja pada projek itu, baik di pihak Pelanggan dan di pihak Kontraktor. Walaupun kesederhanaan jelas tahap ini, ia mempunyai peranan yang sangat penting. Jika anda tidak merekodkan dengan jelas siapa yang bertanggungjawab untuk apa, anda berisiko menghadapi kekeliruan semasa pelaksanaan kerja. Jika, bagi pihak anda, anda sentiasa boleh menentukan peranan dalam pasukan anda, maka Pelanggan mungkin menghadapi masalah dengan perkara ini. Perkara yang perlu anda perhatikan: Kumpulan kerja Pelanggan mesti termasuk mereka yang pada masa hadapan sekurang-kurangnya akan mempengaruhi penerimaan keputusan. Jika kita menganggap situasi bahawa apabila kerja diserahkan, pekerja Pelanggan yang tidak mengambil bahagian dalam kerja untuk merumuskan matlamat dan mengenal pasti keperluan akan terlibat, maka masalah dijamin. Malah situasi yang tidak masuk akal seperti itu adalah mungkin bahawa segala-galanya ternyata tidak dilakukan seperti yang diperlukan. Dalam amalan saya, saya telah menghadapi situasi sedemikian lebih daripada sekali. Oleh itu, anda boleh melindungi diri anda jika anda menetapkan dan mendokumenkan bahawa tiada siapa kecuali pelanggan bekerja kumpulan boleh mengambil bahagian dalam penerimaan dan penyampaian kerja. Dan yang terbaik adalah menulis ini dalam syarat kontrak (dalam kontrak atau piagam projek). Saya masih ingat ada kes sedemikian: dalam satu projek besar, pengasas memutuskan untuk menyertai proses (saya tidak tahu mengapa, ia kelihatan membosankan) dan menghadiri salah satu mesyuarat kerja di mana isu penjanaan invois untuk pelanggan dibincangkan. Dia terkejut apabila mengetahui bahawa pengurus jualan mengeluarkan invois kepada pelanggan. Dalam fikirannya, akauntan harus mengeluarkan invois, dan tidak ada yang lain. Tetapi sebenarnya, akauntan itu tidak tahu apa yang dia bercakap tentang, dan pengurus tidak dapat membayangkan bagaimana untuk bekerja seperti ini jika dia terpaksa pergi ke akauntan untuk setiap bil. Akibatnya, kami kehilangan banyak masa, tetapi tiada apa yang berubah, pengurus terus mengeluarkan invois. Dan pengasas tetap tidak yakin, tetapi tidak campur tangan dalam proses itu lagi. Pada peringkat yang sama ini, adalah dinasihatkan untuk membangunkan Piagam Projek, yang menetapkan peranan peserta, prosedur untuk komunikasi, peraturan dan pelaporan, serta semua perkara lain yang perlu dinyatakan dalam Piagam. Pembangunan Piagam Projek sekali lagi menjadi topik yang berasingan. |
| Melatih pasukan projek dalam kaedah dan alatan kerja, bersetuju dengan peraturan kerja, jenis dan komposisi dokumentasi | Pertama sekali, adalah perlu untuk menerangkan kepada pasukan projek semua yang dinyatakan dalam Piagam dan bagaimana ia akan digunakan dalam amalan. Kedua, pasukan projek Pelanggan mesti dilatih dalam kaedah kerja yang akan anda gunakan pada semua peringkat seterusnya. Adalah wajar untuk membincangkan format dokumen yang akan digunakan dan mempertimbangkan sampel. Jika sebarang peraturan untuk menerangkan model atau proses perniagaan akan digunakan, maka peraturan ini juga mesti dibincangkan supaya ia jelas. |
| soal selidik | Peringkat tinjauan membolehkan anda mendapatkan keratan rentas maklumat yang agak boleh dipercayai tentang syarikat dengan cara yang agak cepat. Kualiti maklumat tersebut akan ditentukan oleh tiga faktor:
Sila ambil perhatian bahawa metodologi tinjauan untuk pelaksanaan seterusnya sistem automatik atau perihalan proses perniagaan dalam kes yang betul berbeza. Sudah tentu, struktur soal selidik mungkin sama, tetapi ini bukan pilihan terbaik. Apabila kita menerangkan proses perniagaan, soal selidik biasanya lebih bersifat umum, kerana Ia tidak diketahui dengan tepat apa yang akan anda hadapi. Jika kita bercakap tentang pelaksanaan sistem automatik tertentu, maka adalah lebih baik untuk mempunyai soal selidik yang mengambil kira ciri-ciri sistem ini. Dengan pendekatan ini, anda boleh mengenal pasti dengan segera semua kesesakan sistem yang tidak sesuai untuk perusahaan tertentu. Sebagai peraturan, kaedah untuk melaksanakan sistem siap sedia menyediakan kehadiran soal selidik tersebut. Soal selidik tersebut boleh dibangunkan sama ada untuk bidang perakaunan tertentu (contohnya, perakaunan pesanan, jualan, harga) atau untuk jawatan tertentu (contohnya pengarah kewangan). Komposisi soalan adalah lebih kurang sama. |
| Undian | Tinjauan ialah temu bual lisan dengan pakar untuk mengetahui ciri-ciri proses individu. Adalah perlu untuk mengatur tinjauan supaya ia tidak kelihatan seperti hanya "bertemu dan bercakap", tetapi dengan cara yang lebih teratur. Untuk melakukan ini, anda perlu menyediakan pelan tinjauan yang dipanggil. Anda boleh memasukkan di dalamnya bahagian-bahagian soal selidik yang menimbulkan soalan untuk anda, bercanggah dengan maklumat daripada soal selidik lain, atau maklumat itu dibentangkan secara cetek. Adalah dinasihatkan untuk menambah soalan hanya dari pengalaman peribadi. Jawapan mesti dicatat tanpa gagal. Ia sesuai jika anda bersetuju dengan rakaman audio. Pada peringkat yang sama, anda harus memastikan kesempurnaan maklumat yang diberikan pada aliran dokumen (kedua-dua bentuk dokumen utama dan pelbagai laporan) |
| Pengenalpastian proses perniagaan utama atau bidang automasi | Selepas soal selidik dan tinjauan, boleh diandaikan secara munasabah bahawa terdapat maklumat yang mencukupi untuk membuat kesimpulan tentang pengenalpastian proses perniagaan utama. Malah, sudah mungkin untuk mengenal pasti bukan sahaja proses perniagaan utama, tetapi hampir semuanya (jika peserta dipilih dengan betul). Isu mengenal pasti proses perniagaan adalah topik yang berasingan dan bukan mudah. Belajar di sini adalah sukar dan dibangunkan terutamanya oleh pengalaman. Senarai (pengelas) harus disusun daripada proses perniagaan yang dikenal pasti. Anda kemudian boleh membuat keputusan tentang mana yang perlu diterokai dengan lebih mendalam, yang mana tidak dan keutamaan. |
| Perumusan keperluan utama untuk sistem, matlamat, kriteria kejayaan projek, proses untuk kajian terperinci | Pada peringkat ini, semua maklumat utama tentang aktiviti syarikat harus dikumpulkan dan senarai proses perniagaan mesti disusun. Sekarang adalah masa untuk kembali kepada matlamat, nyatakannya, dan, jika perlu, bincangkannya dengan pegawai atasan syarikat. Apabila merumuskan matlamat, kita harus mengambil kira petunjuk khusus, apabila pencapaiannya kita akan menganggap projek itu berjaya. Jika kita bercakap tentang pelaksanaan sistem automatik, maka senarai berasingan boleh menyerlahkan keperluan untuk sistem daripada pengguna utama. Saya melakukan ini dalam bentuk jadual berasingan, di mana semua keperluan dikumpulkan mengikut subsistem, untuk setiap keperluan pengarang keperluan, kata-kata dan keutamaan ditunjukkan. Maklumat ini boleh digunakan untuk merangka pelan penggunaan sistem (urutan pelaksanaan subsistem individu), serta cadangan untuk pembangunan selanjutnya sistem (jika subsistem individu tidak dirancang untuk dilaksanakan dalam projek semasa). Jika perlu untuk menerangkan proses perniagaan, keputusan dibuat tentang proses tersebut yang perlu dikaji dengan lebih terperinci. |
Jadi kita sampai kepada soalan "Apa yang seterusnya?" Seterusnya kita akan mempertimbangkan tugas-tugas menerangkan proses perniagaan dan membangunkan spesifikasi teknikal secara berasingan. Bukan kebetulan saya menganggap tugas-tugas ini selari. Terdapat banyak persamaan antara mereka, itulah yang saya ingin tunjukkan. Mula-mula, mari kita lihat urutan kerja apabila menerangkan proses perniagaan.
| Apa dan bagaimana untuk dilakukan |
|
| Kami menyerlahkan proses perniagaan | Daripada senarai umum proses perniagaan yang diperoleh pada peringkat sebelumnya, kami memilih satu (mengikut keutamaan) untuk pembangunan terperinci. Kami kemudian melakukan perkara yang sama dengan yang lain. |
| Kajian terperinci tentang proses perniagaan | Kami menundukkan proses perniagaan yang dipilih kepada kajian terperinci: kami menganalisis dokumen utama yang diterima, laporan dan strukturnya yang digunakan dalam proses program, pelbagai fail (contohnya, Excel), dan berbincang dengan pelaksana akhir. Kami mengumpul pelbagai idea tentang cara proses itu boleh diperbaiki. Ia sangat berguna jika anda berjaya memerhatikan proses itu dengan tepat di bawah keadaan di mana ia sedang dijalankan (tidak ramai orang suka ditonton, tetapi apa yang boleh anda lakukan) |
| Perihalan grafik dan/atau teks proses perniagaan (utama) | Kami mula menerangkan maklumat terperinci yang diterima. Sebelum menerangkan proses, kami perlu memutuskan sama ada ia memerlukan penerangan grafik. Sekiranya proses itu mudah dan jelas, terdapat beberapa fungsi di dalamnya, dan perwakilan grafik tidak akan meningkatkan pemahaman atau persepsinya, maka tidak perlu membuang masa untuk itu. Dalam kes ini, cukup untuk menerangkannya dalam bentuk teks dalam bentuk jadual. Sekiranya proses itu rumit, dengan pelbagai keadaan logik, maka lebih baik untuk menyediakan gambarajah grafiknya. Gambar rajah sentiasa lebih mudah difahami. Jika anda memutuskan untuk menerangkan proses secara grafik, ini tidak bermakna anda tidak perlu memberikan penerangan teks. Itu. Harus ada penerangan teks proses dalam apa jua keadaan, dan ia harus dilakukan mengikut skema yang sama. Adalah mudah untuk melakukan ini dalam bentuk jadual di mana anda menunjukkan: pelaku setiap langkah, maklumat yang mereka terima sebagai input, penerangan setiap langkah, maklumat yang dihasilkan pada output. Di bawah ini kita akan melihat contoh bagaimana ini mungkin kelihatan. |
| Penyelarasan dengan penghibur dan pemilik proses perniagaan | Cara terbaik untuk memahami sejauh mana anda telah memilih gaya penyampaian maklumat ialah dengan menunjukkan hasil kepada pengguna (pelaku) proses tersebut. Perkara yang paling penting dalam demonstrasi sedemikian adalah untuk memahami sejauh mana anda memahami dengan betul bagaimana proses itu Jika latihan pasukan projek berjaya, anda boleh mengharapkan maklum balas yang mencukupi daripada penghibur. Dan jika mereka berminat, maka semuanya akan bergerak ke hadapan dengan lebih pantas. Penjelasan dan ketidakkonsistenan yang dikenal pasti mesti ditunjukkan dalam huraian (dikemas kini), dan jika perlu, operasi mesti diulang. |
| Pengasingan penunjuk proses perniagaan | Sebaik sahaja anda telah membangunkan pemahaman yang betul tentang cara proses perniagaan dilakukan, anda perlu memikirkan penunjuk yang boleh mengukur kualiti atau kelajuan proses. Ini tidak mudah, tetapi ia perlu. Penunjuk mestilah boleh diukur, i.e. dinyatakan dalam istilah berangka dan mesti ada cara mudah untuk mendapatkan nilai ini. Jika penunjuk yang diukur tidak dapat dikenal pasti, terdapat risiko proses perniagaan telah dikenal pasti tidak berjaya. Di samping itu, tidak akan ada cara untuk memahami (lagipun, ia tidak boleh diukur) sama ada perubahan pada proses akan membawa kepada peningkatan atau tidak. |
| Dokumentasi akhir proses perniagaan | Setelah kami memastikan bahawa kami mempunyai pemahaman yang baik tentang cara sesuatu proses itu (atau sepatutnya) dilaksanakan, kami boleh memasukkannya ke dalam dokumentasi. |
| Pilihan selanjutnya adalah mungkin: proses yang sedang dipertimbangkan akan dianalisis dan dioptimumkan, huraian kerja akan dibangunkan, keputusan akan dibuat tentang keperluan untuk mengautomasikan proses individu, dsb. Ini boleh menjadi projek yang berasingan: penerangan tentang proses perniagaan. |
Sekarang mari kita lihat bagaimana pendekatan untuk mengkaji keperluan untuk sistem maklumat akan kelihatan dengan refleksi mereka selanjutnya dalam Terma Rujukan
| Apa dan bagaimana untuk dilakukan |
|
| Kami menyerlahkan keperluan perniagaan/bidang automasi | Mengasingkan keseluruhan kawasan automasi (contohnya, "Inventori") sebagai keperluan digunakan dalam amalan, bagaimanapun, ini bukanlah cara paling berkesan untuk memperincikan keperluan. Kawasan automasi ialah sekumpulan keperluan, dan sebaiknya pertimbangkan secara individu. Sebagai contoh, "Perakaunan untuk penerimaan barang di gudang" |
| Kajian terperinci tentang keperluan perniagaan | Kajian terperinci tentang keperluan perniagaan merujuk kepada bagaimana pengguna akhir ingin melihatnya dan akan menggunakannya (sudah tentu, mengikut matlamat projek). Dalam teknologi kejuruteraan perisian ini sering dirujuk sebagai "kes penggunaan". Oleh itu, kajian terperinci tentang keperluan perniagaan adalah untuk membangunkan kes penggunaan. Contoh pilihan ini diberikan dalam Lampiran 2 kepada artikel. Dalam kes yang paling mudah, kes penggunaan tidak semestinya perlu dilukis dalam bentuk gambar rajah grafik; anda boleh menghadkan diri anda kepada penggubalan teks. Sebagai contoh, keperluan "Apabila memasukkan item, harga mesti dikira sebagai harga belian + 20%" tidak masuk akal. Dalam bentuk gambar rajah, masuk akal untuk mewakili keperluan yang digabungkan ke kawasan automasi, seperti yang ditunjukkan dalam contoh dalam Lampiran 2. |
| Keperluan pemodelan dalam sistem maklumat | Ini dia! Seperti yang anda mungkin ingat, saya telah menarik perhatian kepada elemen terpenting ini dalam metodologi untuk membangunkan Spesifikasi Teknikal. "Bina model - anda akan mendapat hasilnya!" Apa yang perlu dimodelkan? Ia adalah perlu untuk memodelkan kes penggunaan yang diperoleh pada peringkat sebelumnya. Apakah yang sepatutnya menjadi output simulasi? Hasilnya mestilah program demonstrasi di mana data pengguna dimasukkan, sebaik-baiknya yang biasa dengan pendengarannya (pengguna), dengan mengambil kira spesifik industri dan masalah semasa. Dan mereka dimasukkan atas sebab tertentu, tetapi harus jelas dari mana data ini datang dan bagaimana ia dikira. Pada ketika ini pembaca harus mempunyai soalan:
Sudah tentu, anda perlu menghadapi situasi sedemikian, dan itu adalah perkara biasa. Apa nak buat? Jika sistem itu benar-benar baharu (seperti yang mereka katakan, "dari awal"), maka anda perlu memodelkan kebanyakannya di atas kertas, di sini rajah kes penggunaan akan banyak membantu anda. Sebahagiannya, masuk akal untuk melakar beberapa bentuk skrin yang sepatutnya dibangunkan (betul-betul dalam persekitaran di mana pembangunan akan dijalankan), kerana melukisnya dalam sesetengah editor akan mengambil masa yang lebih lama dan kerja ini membosankan. Jika sistem siap sedia sedang dilaksanakan dan ia tidak mempunyai fungsi, maka tiada apa yang perlu dikhuatiri, data dimasukkan secara manual, dan pengguna diberitahu bahawa selepas pengubahsuaian yang diperlukan ia harus dikira sedemikian dan sedemikian (dan dia nampak). Adalah dinasihatkan untuk mengiringi model sedemikian dengan penerangan teks, walaupun ringkas, supaya pengguna boleh secara bebas cuba bekerja dengan model pada masa lapangnya. Dalam huraian yang sama, anda boleh merumuskan keperluan untuk penambahbaikan. |
| Demonstrasi model maklumat kepada kumpulan kerja | Kami menunjukkan model yang terhasil kepada Pelanggan dan memberitahu bagaimana semuanya harus berfungsi. Adalah lebih baik untuk menunjukkan model mengikut subsistem, i.e. mengikut kumpulan keperluan. Jika ternyata skim yang dicadangkan tidak akan berfungsi untuk pelanggan, anda perlu memikirkan kes penggunaan lain, membuat perubahan pada model dan menunjukkannya semula. Hanya jika terdapat keyakinan bahawa model yang dirancang akan "hidup" untuk pelanggan tertentu boleh model itu dianggap berjaya. |
| Pembangunan ujian | Mengapakah ujian diperlukan? Bagaimana kami dapat melaksanakan keperluan perlu diuji. Sehubungan itu, adalah dinasihatkan untuk melakukan ujian untuk semua bidang utama, algoritma kompleks, dsb. Ujian ini juga boleh digunakan semasa menghantar kertas kerja. Tidak perlu melakukan ujian untuk setiap fungsi sistem; akal sehat harus digunakan di mana-mana. Jika kita bercakap tentang sistem sedia, maka melakukan ujian untuk "memasukkan elemen baru ke dalam direktori pelanggan" akan kelihatan bodoh dan membuang masa dan usaha. Tetapi jika ini adalah sistem yang sama sekali baru, ini agak mungkin. Mengapa ujian jika belum ada sistem? Pertama, ia akan lebih jelas kepada pemaju apa yang mereka mahu capai daripadanya. Kedua, kami menjadikan kehidupan lebih mudah untuk penguji (seseorang akan menguji hasil pembangunan). Secara umum, ujian adalah disiplin yang berasingan, tidak begitu mudah dengan banyak teknik. Dalam amalan, sebagai peraturan, kaedah ujian paling mudah masih digunakan. |
| Mendokumentasikan keperluan dalam bentuk Spesifikasi Teknikal | Maklumat yang dikumpul pada peringkat sebelumnya adalah tepat seperti yang harus dimasukkan dalam asas dokumen "Spesifikasi Teknikal" dalam bahagian dengan keperluan. Jadi yang tinggal hanyalah memformat semuanya dengan betul. |
| Langkah seterusnya (atau kekurangannya), bergantung pada matlamat projek | Proses pembangunan mungkin mengambil masa yang lebih lama untuk dimulakan, pencarian rakan kongsi untuk projek, tender, dsb., semuanya bergantung pada keadaan. |
Ya, pembangunan Terma Rujukan adalah proses intensif buruh, dan oleh itu memerlukan kos yang tinggi. Tetapi jika ia dilakukan dengan betul, ia melegakan Pelanggan daripada jangkaan yang tidak tercapai. Kontraktor perlu melakukan apa yang diperlukan oleh Pelanggan dan tidak membuat semula perkara yang sama seratus kali. Dan secara umum, ia memberikan ketelusan keseluruhan projek.
TUGASAN TEKNIKAL
untuk pembangunan sistem maklumat
1. Maklumat am
4. Keperluan sistem
6. Prosedur untuk kawalan dan penerimaan sistem
1. Maklumat am
Selaras dengan perjanjian No. MP23 antara LLC TechnoPlus (selepas ini dirujuk sebagai Pemaju) dan LLC OptoTorgovlya (selepas ini dirujuk sebagai Pelanggan), Pemaju mereka bentuk pangkalan data, membangunkan dan melaksanakan sistem maklumat "Perakaunan untuk operasi perdagangan"
Tarikh mula reka bentuk BDB dianggap sebagai hari selepas menandatangani Spesifikasi Teknikal ini
Jika semasa proses pembangunan Pelanggan mengubah keperluan yang diterangkan dalam dokumen ini, maka ia disediakan dalam dokumen berasingan dan memerlukan perubahan atau penambahan kepada Perjanjian antara Pelanggan dan Pembangun DB mengenai tarikh akhir penyiapan dan pembayaran perjanjian.
Pelanggan membayar untuk kerja Pembangun Pangkalan Data mengikut Perjanjian No. XXX
2. Tujuan dan matlamat penciptaan (pembangunan) sistem
IS "Perakaunan untuk Operasi Perdagangan" direka untuk menyimpan, memproses dan menganalisis maklumat yang berkaitan dengan aktiviti utama Pelanggan.
Tujuan mewujudkan IS "Perakaunan untuk Operasi Perdagangan" ialah:
Menyimpan maklumat mengenai operasi dagangan yang telah selesai;
Refleksi urus niaga perdagangan dalam perakaunan;
Analisis keputusan kewangan operasi perdagangan;
Analisis aktiviti perdagangan mengikut rangkaian produk dan rakan niaga.
3. Ciri-ciri objek automasi
3.1. Aktiviti utama Pelanggan ialah perdagangan perabot dan produk berkaitan melalui pindahan wang melalui bank.
3.2. Pelanggan bukan pembayar VAT
3.3. Pada siang hari, Pelanggan membuat tidak lebih daripada 100 transaksi perdagangan untuk pembelian dan penjualan barangan.
3.4. Jumlah volum julat produk tidak melebihi 3000 unit
3.5. Jumlah bilangan rakan niaga - pembekal tidak lebih daripada 100 unit.
3.6. Bilangan rakan niaga – pembeli – tidak terhad. Pada masa menandatangani kontrak N XXX ialah 300 unit.
3.7. Pelanggan menghapus kira barangan dari gudang menggunakan kaedah kos purata wajaran.
3.9. Hanya akaun kelas 9 digunakan sebagai akaun perbelanjaan.
3.10. Keputusan kewangan aktiviti perdagangan perusahaan (keuntungan dan keuntungan operasi) dikira berdasarkan perbezaan antara sektor 702 dan 902.
3.11. Urus niaga perdagangan direkodkan dalam dokumen utama Invois resit, Invois perbelanjaan, Penyata bank.
Invois Pributkov (PN) akan menunjukkan fakta bahawa barang telah tiba di gudang perusahaan dan termasuk maklumat berikut:
- nombor;
- Tarikh;
– Nama rakan niaga (syarikat - pemilik pos);
– nama produk;
- kekuatan;
– harga seunit produk;
- sumu.
Invois Vidatkov (VN) mewakili fakta bahawa barang telah dipromosikan dari gudang pembeli dan mengandungi maklumat yang serupa dengan maklumat dalam PN (bukan syarikat penghantaran, syarikat pembelian ditunjukkan).
Barisan penyata bank mengesahkan fakta penerimaan/getaran dana daripada perusahaan rozrakhunku (r/r) dan mengandungi maklumat berikut:
- Tarikh;
– tanda ketibaan/pembayaran dana;
– Nama rakan niaga (yang ditemui / yang terlebih insurans).
3.12. Dokumen utama kulit Ia adalah platform untuk membuat urus niaga biasa yang mengakibatkan perubahan kepada rekod perakaunan sedia ada. Urus niaga perdagangan memerlukan urus niaga berikut (Jadual 3.1)
Jadual 3.1 – Penyiaran yang digunakan dalam perakaunan di perusahaan Pelanggan
Operasi | Dokumen | Debit akaun | Kredit akaun | Jumlah transaksi |
Penyiaran | Invois Belian | jumlah dokumen |
||
Penghantaran barang | Invois jualan | jumlah dokumen |
||
kos barang dihantar |
||||
Penerimaan wang ke akaun semasa | Penyata bank (resit) | jumlah dokumen |
||
Memindahkan wang dari akaun semasa | Penyata bank (perbelanjaan) | jumlah dokumen |
||
Penentuan keputusan kewangan | untuk jumlah penutupan 902 akaun |
|||
untuk jumlah penutupan 702 akaun |
de 281 – barang dalam stok;
311 – rozrakhunkovy rakhunok dalam mata wang ganas;
361 – kedai runcit dengan pembelian rotan;
631 – rozrakhunki dengan pekerja pos;
702 – pendapatan daripada jualan barangan;
902 – keserasian barang yang dijual (pengeluaran).
3.13. Kunci kira-kira bentuk sintetik kelihatan seperti dalam Jadual 3.2.
Jadual 3.2 – Baki pusing ganti produk sintetik
Nombor item | Baki tongkol | terbalikkan | Baki Kintseve |
|||
bersama-sama |
4. Keperluan sistem
IS "Perakaunan untuk Operasi Perdagangan" mesti memenuhi keperluan berikut:
4.1. Pangkalan data untuk IS "Perakaunan untuk Operasi Perdagangan" mesti menyediakan penyimpanan, paparan dan penyuntingan rujukan dan maklumat operasi.
Maklumat Rujukan:
o perihalan barang:
Nomenklatur (produk) nombor;
Nama Produk;
Penerangan;
o rakan niaga – pembekal;
Nombor rakan niaga;
Nama Kontraktor;
Alamat rakan niaga;
Kenalan;
o rakan niaga – pembeli;
Nombor rakan niaga;
Nama Kontraktor;
Alamat rakan niaga;
Kenalan;
o carta akaun di mana perakaunan dijalankan untuk merekodkan operasi dagangan dan menganalisis keputusan kewangan;
o senarai transaksi asas untuk memaparkan transaksi perdagangan dalam perakaunan yang disebabkan oleh dokumen utama, yang kelihatan seperti ini, seperti dalam jadual 3.1;
Maklumat operasi:
o Dokumen utama: Invois resit, Invois perbelanjaan, Penyata bank (huraian dokumen diberikan dalam 3.11)
o Catatan perakaunan yang disebabkan oleh dokumen utama (jenis catatan ditunjukkan dalam jadual 3.2)
o Maklumat tentang barangan dalam stok:
Nombor Item;
Kuantiti;
Jumlah;
Harga purata.
4.2. IS "Perakaunan Operasi Perdagangan" sepatutnya membenarkan anda mengautomasikan tindakan berikut:
4.2.1 Mencerminkan fakta penerimaan (receipt) dan penghantaran barang di gudang iaitu mengira semula kuantiti barang di gudang dan kos puratanya.
4.2.2 Hasilkan catatan perakaunan secara automatik berdasarkan dokumen utama.
4.2.3 Cari maklumat berikut:
Dokumen utama jenis yang ditentukan untuk tempoh tertentu;
Penyiaran untuk jenis dokumen tertentu untuk tarikh tertentu;
Maklumat tentang rakan niaga
Informasi produk
4.2.4 Menjalankan analisis aktiviti perdagangan untuk tempoh yang ditetapkan dalam bahagian berikut:
Keputusan kewangan aktiviti perdagangan;
Keputusan penyelesaian untuk setiap rakan niaga;
Baki barang di gudang untuk setiap item;
Kos urus niaga untuk setiap rakan niaga;
Kos dan bilangan jualan bagi setiap jenis produk
4.2.5 Hasilkan laporan untuk tempoh yang ditetapkan:
Peralatan di mana IC dipasang mesti dilengkapi dengan bekalan kuasa yang tidak terganggu. Sekiranya berlaku gangguan bekalan elektrik, IS hendaklah ditutup secara automatik tanpa kehilangan data.
IS mesti mempunyai mekanisme sandaran, dan IS mesti dilengkapi dengan perkakasan dan perisian yang sesuai:
Nilai kuantitatif penunjuk kebolehpercayaan:
- masa penutupan automatik hendaklah tidak lebih daripada 1 minit;
- masa pemulihan selepas kegagalan hendaklah tidak lebih daripada 30 minit;
- indeks toleransi kesalahan IS hendaklah 11/7, iaitu operasi tanpa gangguan bagi IS 11 jam sehari, 7 hari seminggu.
Penyelenggaraan IS mesti dijalankan tanpa mengganggu operasinya.
4.5 Keperluan kaedah untuk menilai dan memantau petunjuk kebolehpercayaan pada peringkat operasi percubaan
Untuk memantau penunjuk kebolehpercayaan pada peringkat operasi percubaan IS, kakitangan penyelenggaraan mesti mengekalkan Log Kegagalan, yang mesti mengandungi tanda maklumat berikut:
Tarikh ralat berlaku;
Jumlah masa operasi objek dari permulaan operasinya sehingga ralat dikesan;
Tanda-tanda luaran dan sifat kesilapan;
Jenis kerja di mana ralat ditemui.
4.6 Keperluan prestasi IC
Sistem mesti menyokong keupayaan untuk memproses sehingga 1000 dokumen setiap hari
Sistem mesti mempunyai prestasi berikut:
80% daripada operasi mesti mempunyai masa tindak balas (masa pelaksanaan operasi) kurang daripada 1 saat;
15% daripada operasi – dari 5 saat. sehingga 10 saat;
5% daripada operasi - lebih daripada 10 saat, tetapi tidak lebih daripada 30 minit.
4.7 Keperluan untuk volum (skala)
Sistem mesti menyokong akses kepada data selama 10 tahun.
Anggaran peningkatan volum pangkalan data setiap hari operasi ialah 20 MB.
4.8 Keperluan untuk bilangan, fungsi dan kelayakan kakitangan IS dan cara operasi mereka
Kerja dengan IS akan dijalankan oleh kakitangan Pelanggan berikut:
Pentadbir:
Kuantiti: 1;
Kelayakan: pentadbir rangkaian, pentadbir pangkalan data;
Fungsi: pengurusan keselamatan sistem, sandaran data pada awal setiap hari bekerja, pengarkiban data sekali setahun;
Waktu bekerja: 1 jam sehari, 5 hari seminggu
Pengendali (pengguna) yang merekodkan fakta operasi perdagangan dan menganalisis hasil aktiviti perdagangan:
Kuantiti: 2;
Kelayakan: akauntan, pengguna PC;
Fungsi: memasukkan dokumen utama, mengekalkan keadaan semasa maklumat tentang gudang, menjana entri perakaunan, menganalisis hasil aktiviti perdagangan, membuat sandaran data pada awal hari bekerja yang jatuh pada hari Sabtu dan Ahad.
Waktu bekerja: mengikut syif untuk memastikan operasi sistem 11 jam sehari, 7 hari seminggu;
Akses kepada kerja: Kursus latihan 8 jam;
Sebelum menggunakan IS, untuk mendapatkan kebenaran untuk bekerja, kakitangan mesti melengkapkan kursus latihan selama 8 jam. Selepas menamatkan kursus, ujian dijalankan, di mana ketepatan dan kelajuan menyelesaikan masalah praktikal, serta pengetahuan tentang kerja dan arahan teknikal dinilai.
Sistem harus menyediakan akses kepada fungsinya hanya kepada pengguna IS berdaftar dengan menyatakan kata laluan.
4.10 Keperluan untuk perisian dan komposisi, struktur dan kaedah menyusun pangkalan data IS
Data dalam Sistem mesti disimpan dalam DBMS MS SQL Server 2000 hubungan.
- T-SQL (dialek bahasa SQL);
DENGAN # .
Perisian ini terdiri daripada perisian sistem umum yang dibeli dengan perbelanjaan Pelanggan (perisian yang dibeli), dan perisian khas yang dibangunkan sebagai sebahagian daripada kerja untuk mencipta IP.
Perisian berikut harus digunakan sebagai perisian seluruh sistem:
Sistem operasi;
Sistem pengurusan pangkalan data MS SQL Server 2000;
Perisian sandaran;
4.11 Keperluan perkakasan
Pelayan pangkalan data, 2 stesen kerja.
Daya pemprosesan rangkaian ialah 100 Mbit sesaat.
4.12 Keperluan untuk prospek pembangunan dan pemodenan IS
Adalah mungkin untuk memodenkan dan membangunkan IS tanpa melibatkan Pembangun oleh pentadbir IS pada tahap:
- menambah, menukar, memadam maklumat rujukan IS;
- menyambung/mengalih keluar pengguna IS baharu;
- perubahan kata laluan;
- import/eksport data dari/ke sumber data luaran.
Adalah mungkin untuk memodenkan dan membangunkan IS dengan penyertaan terhad Pembangun (perundingan telefon) pada tahap memodenkan laporan lama dan mencipta laporan baharu. Kemungkinan dan syarat perundingan telefon oleh Pembangun mengenai pemodenan IS dirundingkan secara berasingan dengan menandatangani perjanjian baharu.
5. Komposisi dan kandungan kerja untuk mencipta sistem
Kerja-kerja reka bentuk IS "Perakaunan untuk Operasi Perdagangan" dijalankan dalam tiga peringkat.
Peringkat pertama termasuk:
Menyemak kemungkinan mendapatkan semua maklumat yang diminta oleh Pelanggan berdasarkan data awal;
reka bentuk pangkalan data IS;
Mengisi pangkalan data yang dibangunkan dengan set data ujian;
Pembangunan reka bentuk antara muka pengguna;
Pembangunan spesifikasi teknikal peringkat rendah untuk pembangunan IS "Perakaunan untuk Operasi Perdagangan"
Penghujung peringkat pertama disahkan dengan menandatangani Sijil Kerja Siap Kerja dalaman dan kelulusan spesifikasi teknikal peringkat rendah untuk pembangunan IP.
Peringkat kedua ialah pembangunan versi ujian IS "Accounting for Trade Operations". Penghujung peringkat ini ialah pengenalan versi ujian ke dalam operasi percubaan.
Peringkat ketiga ialah operasi percubaan IS "Perakaunan untuk Operasi Perdagangan", yang merangkumi penghapusan ralat, kekurangan dan ketidakkonsistenan yang dikenal pasti dengan Spesifikasi Teknikal ini. Penghujung peringkat kedua ialah pengenalan IS ke dalam operasi komersial.
Penyiapan setiap peringkat kedua dan ketiga disahkan oleh Pihak-Pihak kepada perjanjian dengan menandatangani Sijil Pemindahan dan Penerimaan.
Tempoh peringkat pertama ialah 10 hari. Permulaan peringkat pertama dianggap sebagai hari selepas hari Pelanggan dan Pembangun DB menandatangani Spesifikasi Teknikal ini.
Tempoh peringkat kedua ialah 20 hari. Permulaan peringkat kedua dianggap sebagai hari selepas hari kelulusan spesifikasi teknikal peringkat rendah untuk pembangunan IP.
Tempoh peringkat ketiga ialah 20 hari. Permulaan peringkat ketiga dianggap sebagai hari selepas hari Pelanggan dan Pembangun DB menandatangani Sijil Penerimaan versi ujian IS untuk operasi percubaan.
Set data untuk menguji IS disediakan oleh Pelanggan.
Pada penghujung peringkat kerja kedua, Pembangun DB memasang IS ujian pada pelayan ujian Pelanggan dan menyediakan Pelanggan dengan manual pengguna awal yang mengandungi penerangan tentang prosedur yang diperlukan untuk bekerja dengan IS "Perakaunan Perdagangan". Penerangan disediakan secara elektronik.
Pada akhir peringkat ketiga kerja, Pembangun DB menyediakan Pelanggan dengan program untuk memasang pangkalan data pada pelayan, serta arahan pengguna dan pengaturcara dan arahan untuk memasang IS dengan penerangan tentang prosedur yang diperlukan untuk bekerja dengan IS "Perakaunan untuk Operasi Perdagangan".
6. Prosedur untuk kawalan dan penerimaan sistem
Pada akhir peringkat pertama, Sijil Kerja Siap Kerja dalaman ditandatangani dan spesifikasi teknikal peringkat rendah untuk pembangunan IP diluluskan.
Pada penghujung peringkat kedua dan ketiga reka bentuk, Pembangun memasang IS pada Pelanggan, menunjukkan operasi IS mengikut keperluan yang ditetapkan dalam Spesifikasi Teknikal ini, dan menandatangani Sijil Pemindahan dan Penerimaan.
7. Keperluan untuk komposisi dan kandungan kerja untuk menyediakan objek automasi untuk pentauliahan sistem
Pada hari permulaan operasi percubaan, Pelanggan bertanggungjawab untuk memberikan Pembangun akses yang diperlukan kepada pelayan di mana versi ujian IS "Perakaunan Operasi Perdagangan" akan digunakan.
Kekurangan pelayan untuk memasang pangkalan data "Accounting for Trade Operations" IS tidak boleh menjadi asas untuk keengganan menandatangani Sijil Penerimaan untuk IS "Accounting for Trade Operations" untuk percubaan atau operasi komersial.
Pada akhir peringkat kedua membangunkan IS "Perakaunan untuk Operasi Perdagangan," Pembangun menjalankan kursus latihan 8 jam dengan kakitangan Pelanggan mengenai penyelenggaraan IS. Pada akhir kursus ini, kakitangan Pelanggan menjalani ujian.
8. Keperluan dokumentasi
Pada akhir peringkat ketiga, Pembangun IS "Perakaunan untuk Operasi Perdagangan" memindahkan dokumentasi berikut kepada Pelanggan:
1. Arahan pengaturcara.
Arahan Pengaturcara menerangkan prosedur yang diperlukan untuk bekerja dengan IS "Perakaunan Operasi Perdagangan". Penerangan mengenai prosedur termasuk:
Nama prosedur;
Penerangan mengenai tindakan yang dilakukan oleh prosedur;
Perihalan parameter input, menunjukkan jenis parameter, format rakamannya dan nilai lalai, jika satu ditakrifkan untuk parameter;
Perihalan parameter output dan (atau) set rekod kembali, menunjukkan jenis dan formatnya
Contoh panggilan prosedur dan nilai yang dikembalikan. Jika prosedur boleh mempunyai beberapa pilihan panggilan, maka contoh untuk setiap pilihan.
2. Arahan untuk memasang IS "Perakaunan untuk Operasi Perdagangan".
3. Arahan untuk pengguna IS "Perakaunan untuk operasi perdagangan".
Tiada dokumentasi lain diberikan kepada Pelanggan. Arahan disediakan dalam format bercetak dan elektronik. Arahan bercetak disediakan dalam satu salinan.
