Dalam bahagian pertama, kami memilih untuk membandingkan metodologi pembangunan perisian seperti penunjuk seperti hubungan metodologi dengan pembangunan berulang dan tahap formaliti dalam reka bentuk bahan kerja dan secara umum dalam proses pembangunan. Dalam bahagian ini, kami menggunakan penunjuk ini untuk membandingkan kaedah pembangunan perisian yang paling terkenal.

Bagaimana kesudahannya...

Malangnya, ini adalah kategori yang paling sukar untuk diterangkan - lagipun, ia termasuk kedua-dua produk dari melontar panik seorang pemula yang cuba menyelesaikan projek pertamanya pada sebarang kos, serta metodologi yang cukup matang dan mantap yang telah menyerap bertahun-tahun pengalaman pelbagai pasukan pembangunan khusus malah diterangkan dalam peraturan dalaman Oleh kerana orang yang dapat membangunkan metodologi mereka sendiri, sebagai peraturan, boleh menilai sendiri dari segi iteratif dan pemformalkan, kami akan memberi tumpuan kepada pemula. Malangnya, selalunya ini bermakna peraturan pembangunan sama ada tidak wujud sama sekali, atau ia telah dibangunkan dan diterima pakai, tetapi tidak diikuti. Adalah wajar dalam keadaan sedemikian untuk mempunyai tahap formalisme yang sangat rendah dalam pembangunan. Jadi semuanya jelas dengan ini.

Pembangunan "Bagaimana ia ternyata"

Bagaimana pula dengan pendekatan berulang? Malangnya, sebagai peraturan, ia tidak digunakan dalam projek sedemikian. Pertama sekali, kerana ia akan membolehkan untuk menilai projek walaupun dalam lelaran pertama sebagai sangat meragukan dan memerlukan campur tangan segera daripada pengurusan yang lebih tinggi untuk memulihkan keadaan. Sesungguhnya, dalam projek lelaran, jawapan tradisional pengaturcara bahawa dia mempunyai segala-galanya 90% sedia hanya bertahan sehingga selesai lelaran pertama...

Metodologi struktur

Metodologi struktur

Kaedah struktur adalah sekumpulan metodologi yang dibangunkan, sebagai peraturan, walaupun sebelum penggunaan meluas bahasa berorientasikan objek. Kesemuanya melibatkan pembangunan air terjun. Walaupun, ternyata, walaupun dalam artikel itu, yang sering disebut sebagai pembentangan pertama pendekatan air terjun, dikatakan bahawa adalah dinasihatkan untuk memulakan projek dengan pembangunan prototaip, iaitu, menjalankan sekurang-kurangnya dua lelaran.

Walau bagaimanapun, asas metodologi ini adalah peralihan yang konsisten dari kerja ke kerja dan pemindahan keputusan (dokumen) peringkat seterusnya kepada peserta peringkat seterusnya.

Selain itu, semua metodologi ini memerlukan pendekatan yang sangat formal, walaupun kenyataan tentang jumlah dokumentasi yang munasabah boleh didapati di dalamnya. Salah satu contoh yang tidak jelas bahawa metodologi pembangunan perisian yang dibangunkan bukan sahaja di Barat ialah petikan daripada buku yang diterbitkan di negara kita pada awal 1980-an, yang menyatakan bahawa tahap pemformalkan tugas pengaturcaraan harus ditentukan berdasarkan seberapa baik penganalisis dan pengaturcara. Dan ini walaupun fakta bahawa subjek buku itu melibatkan pembangunan agak kritikal, kerana mereka kini dipanggil, sistem, kesilapan yang membawa kepada kerugian yang serius atau bahkan bencana.

Metodologi tangkas

Metodologi tangkas adalah berdasarkan sepuluh prinsip, yang mana kami akan menamakan hanya mereka yang menentukan penilaian metodologi ini mengikut parameter yang dipilih:

• perkara utama adalah untuk memuaskan hati pelanggan dan memberikannya produk secepat mungkin;
• keluaran produk baharu sepatutnya muncul setiap beberapa minggu, atau paling banyak bulan;
• cara paling berkesan untuk memindahkan pengetahuan kepada peserta pembangunan dan antara mereka adalah komunikasi peribadi;
• program kerja adalah penunjuk terbaik kemajuan pembangunan.

Oleh itu, kaedah ini jelas tertumpu pada pembangunan perisian berulang dan pemformalkan minimum proses. Walau bagaimanapun, mengenai perkara kedua adalah perlu untuk membuat tempahan: kaedah yang dinamakan tertumpu pada tahap pemformalan minimum yang boleh diterima untuk projek tertentu. Sekurang-kurangnya satu daripada metodologi yang termasuk dalam kumpulan yang fleksibel - Crystal - mempunyai pengubahsuaian yang direka untuk menjalankan proses dengan bilangan peserta yang berbeza dan kritikal yang berbeza terhadap perisian yang sedang dibangunkan (kekritisan perisian ditentukan oleh kemungkinan akibat ralat, yang boleh berbeza daripada kerugian kewangan kecil kepada pembetulan ralat sebelum bencana). Untuk memastikan perbandingan selanjutnya dengan metodologi fleksibel tidak sia-sia, kami akan memberikan penerangan ringkas tentang beberapa daripadanya.

Pengaturcaraan eXtreme, atau XP (pengaturcaraan melampau)

Metodologi XP, yang dibangunkan oleh Kent Beck, Ward Cunningham dan Ron Jeffries, adalah yang paling terkenal dalam metodologi tangkas hari ini. Kadangkala konsep "metodologi tangkas" dikenal pasti secara eksplisit atau tersirat dengan XP, yang menyampaikan komunikasi, kesederhanaan, maklum balas dan keberanian. Ia digambarkan sebagai satu set amalan: permainan perancangan, keluaran pendek, metafora, reka bentuk ringkas, pemfaktoran semula, pembangunan ujian ke hadapan, pengaturcaraan pasangan, pemilikan kod dikongsi, minggu kerja 40 jam, kehadiran pelanggan sentiasa aktif dan standard kod . Minat terhadap XP meningkat dari bawah ke atas - daripada pembangun dan penguji, diseksa oleh proses yang menyakitkan, dokumentasi, metrik dan formalisme lain. Mereka tidak menolak disiplin, tetapi mereka tidak mahu mematuhi keperluan formal secara sia-sia dan mencari pendekatan baharu, pantas dan fleksibel untuk membangunkan program berkualiti tinggi.

Apabila menggunakan XP, reka bentuk perisian awal yang berhati-hati digantikan, di satu pihak, dengan kehadiran pelanggan yang berterusan dalam pasukan, bersedia untuk menjawab sebarang soalan dan menilai sebarang prototaip, dan di sisi lain, dengan semakan kod biasa (kononnya pemfaktoran semula). Kod yang diulas dengan teliti dianggap sebagai asas dokumentasi projek. Banyak perhatian dalam metodologi diberikan kepada ujian. Sebagai peraturan, untuk setiap kaedah baharu, ujian ditulis terlebih dahulu, dan kemudian kod kaedah sebenar dibangunkan sehingga ujian mula berjalan dengan jayanya. Ujian ini disimpan dalam suite ujian yang dilaksanakan secara automatik selepas sebarang perubahan kod.

Walaupun pengaturcaraan pasangan dan minggu kerja 40 jam mungkin merupakan ciri XP yang paling terkenal, ia bersifat menyokong dan menyumbang kepada produktiviti pembangun yang tinggi dan mengurangkan ralat pembangunan.

Cerah Kristal

Crystal ialah keluarga metodologi yang menentukan tahap pemformalan proses pembangunan yang diperlukan bergantung pada bilangan peserta dan kritikal tugasan.

Metodologi Crystal Clear adalah lebih rendah daripada XP dari segi prestasi, tetapi sangat mudah untuk digunakan. Ia memerlukan usaha yang minimum untuk dilaksanakan kerana ia tertumpu kepada tabiat manusia. Adalah dipercayai bahawa metodologi ini menerangkan susunan semula jadi pembangunan perisian yang ditubuhkan dalam pasukan yang cukup berkelayakan, jika mereka tidak terlibat dalam pelaksanaan sasaran metodologi lain.

Ciri-ciri Utama Crystal Clear:

• pembangunan incremental berulang;
• ujian regresi automatik;
• pengguna dijemput untuk mengambil bahagian secara aktif dalam projek;
• komposisi dokumentasi ditentukan oleh peserta projek;
• Biasanya, alat kawalan versi kod digunakan.

Selain Crystal Clear, keluarga Crystal termasuk beberapa metodologi lain yang direka untuk mengendalikan projek yang lebih besar atau lebih kritikal. Mereka mempunyai keperluan yang lebih ketat sedikit untuk skop dokumentasi dan prosedur sokongan seperti perubahan dan kawalan versi.

Pembangunan Didorong Ciri

Feature Driven Development (FDD) beroperasi dengan konsep fungsi atau sifat (ciri) sistem, yang agak hampir dengan konsep use case yang digunakan dalam RUP. Mungkin perbezaan yang paling ketara ialah sekatan tambahan: "setiap fungsi mesti membenarkan pelaksanaan dalam masa tidak lebih daripada dua minggu." Iaitu, jika kes penggunaan cukup kecil, ia boleh dianggap sebagai fungsi, dan jika ia besar, maka ia mesti dibahagikan kepada beberapa fungsi yang agak bebas.

FDD merangkumi lima proses, dengan dua yang terakhir diulang untuk setiap fungsi:

• pembangunan model umum;
• menyusun senarai fungsi sistem yang diperlukan;
• merancang kerja pada setiap fungsi;
• reka bentuk fungsi;
• pembinaan fungsi.

Kerja pada projek melibatkan binaan yang kerap dan dibahagikan kepada lelaran, setiap satunya dilaksanakan menggunakan set fungsi tertentu.

Pembangun dalam FDD dibahagikan kepada "guru kelas" dan "ketua pengaturcara". Pengaturcara utama melibatkan pemilik kelas yang terlibat dalam mengusahakan harta seterusnya. Sebagai perbandingan, dalam XP tidak ada individu yang bertanggungjawab untuk kelas atau kaedah.

Ciri umum

Senarai metodologi yang fleksibel pada masa ini agak luas. Namun begitu, metodologi yang telah kami huraikan memberikan gambaran yang sangat lengkap tentang seluruh keluarga.

Hampir semua metodologi fleksibel menggunakan pendekatan berulang, di mana hanya sejumlah kerja terhad yang dikaitkan dengan keluaran keluaran seterusnya dirancang secara terperinci.

Hampir semua metodologi fleksibel tertumpu pada pendekatan paling tidak formal untuk pembangunan. Sekiranya masalah itu dapat diselesaikan semasa perbualan biasa, maka lebih baik berbuat demikian. Selain itu, adalah perlu untuk memformalkan keputusan yang dibuat dalam bentuk kertas atau dokumen elektronik hanya apabila mustahil untuk dilakukan tanpanya.

Metodologi tangkas

Piawaian GOST

GOST, seperti keperluan model CMM yang diterangkan dalam bahagian seterusnya, bukanlah metodologi. Sebagai peraturan, mereka tidak menerangkan proses pembangunan perisian itu sendiri, tetapi hanya merumuskan keperluan tertentu untuk proses, yang dipenuhi pada tahap yang berbeza-beza oleh pelbagai metodologi. Membandingkan keperluan menggunakan kriteria yang sama yang kami gunakan untuk membandingkan metodologi akan membantu anda dengan segera memutuskan metodologi yang harus digunakan jika anda perlu menjalankan pembangunan mengikut GOST.

Pada masa ini di Rusia, GOST lama siri ke-19 dan ke-34 dan GOST R ISO IEC 122207 yang lebih baharu berkuat kuasa pada siri ke-19 dan ke-34 tertumpu secara ketat pada pendekatan lata kepada pembangunan perisian. Pembangunan mengikut GOST ini dijalankan secara berperingkat, setiap satunya melibatkan pelaksanaan kerja yang ditetapkan dengan ketat, dan berakhir dengan pelepasan sejumlah besar dokumen yang sangat formal dan luas. Oleh itu, pematuhan segera yang ketat terhadap piawaian ini bukan sahaja membawa kepada pendekatan air terjun, tetapi juga memastikan tahap pemformalan pembangunan yang sangat tinggi.

Keperluan GOST

GOST 12207, berbeza dengan piawaian siri ke-19 dan ke-34, menerangkan pembangunan perisian sebagai satu set proses utama dan tambahan yang boleh beroperasi dari awal hingga selesai projek. Model kitaran hayat boleh dipilih berdasarkan ciri-ciri projek. Oleh itu, GOST ini tidak secara eksplisit melarang penggunaan pendekatan berulang, tetapi juga tidak secara eksplisit mengesyorkan penggunaannya. GOST 12207 juga lebih fleksibel dari segi keperluan untuk formaliti proses pembangunan. Ia mengandungi hanya arahan tentang keperluan untuk mendokumenkan hasil utama semua proses, tetapi tiada senarai dokumen dan arahan yang diperlukan mengenai kandungannya.

Oleh itu, GOST 12207 membenarkan pembangunan perisian berulang dan kurang formal.

Model kematangan proses pembangunan (CMM, CMMI)

Sebagai tambahan kepada piawaian negeri dan antarabangsa, terdapat beberapa pendekatan untuk pensijilan proses pembangunan. Yang paling terkenal di antara mereka di Rusia, nampaknya, CMM dan CMMI.

CMM (Model Kematangan Keupayaan) ialah model kematangan proses penciptaan perisian, yang direka untuk menilai tahap kematangan proses pembangunan dalam syarikat tertentu. Menurut model ini, terdapat lima peringkat kematangan proses pembangunan. Tahap pertama sepadan dengan pembangunan "seperti yang berlaku," apabila pemaju mendekati setiap projek seolah-olah ia adalah satu kejayaan. Yang kedua sepadan dengan proses yang lebih atau kurang mantap, apabila anda boleh mengira dengan keyakinan yang munasabah pada hasil positif projek. Yang ketiga sepadan dengan kehadiran proses yang dibangunkan dan diterangkan dengan baik yang digunakan dalam pembangunan, dan yang keempat sepadan dengan penggunaan aktif metrik dalam proses pengurusan untuk menetapkan matlamat dan memantau pencapaian mereka. Akhir sekali, tahap kelima merujuk kepada keupayaan syarikat untuk mengoptimumkan proses mengikut keperluan.

Keperluan CMM dan CMMI

Selepas kemunculan CMM, model kematangan khusus mula dibangunkan untuk penciptaan sistem maklumat, untuk proses pemilihan pembekal, dan beberapa yang lain. Berdasarkan mereka, model bersepadu CMMI (Capability Maturity Model Integration) telah dibangunkan. Di samping itu, CMMI membuat percubaan untuk mengatasi kelemahan CMM yang telah muncul pada masa itu - keterlaluan peranan penerangan formal proses, apabila kehadiran dokumentasi tertentu dinilai lebih tinggi daripada sekadar yang mantap tetapi tidak diterangkan. proses. Walau bagaimanapun, CMMI juga memberi tumpuan kepada menggunakan proses yang sangat formal.

Oleh itu, asas model CMM dan CMMI ialah pemformalkan proses pembangunan. Mereka menyasarkan pemaju untuk melaksanakan proses yang diterangkan secara terperinci dalam peraturan dan arahan, yang seterusnya, tidak boleh tetapi memerlukan pembangunan sejumlah besar dokumentasi projek untuk kawalan dan pelaporan yang sesuai.

Hubungan antara CMM dan CMMI dan pembangunan berulang adalah lebih tidak langsung. Secara formal, tidak seorang pun atau yang lain mengemukakan keperluan khusus untuk mematuhi pendekatan air terjun atau berulang. Bagaimanapun, menurut beberapa pakar, CMM lebih serasi dengan pendekatan air terjun, manakala CMMI juga membenarkan penggunaan pendekatan berulang.

RUP

Sudah tentu, RUP adalah metodologi berulang. Walaupun keperluan mandatori untuk melengkapkan semua fasa atau bilangan lelaran minimum tertentu tidak ditunjukkan secara rasmi di mana-mana dalam RUP, keseluruhan pendekatan tertumpu pada fakta bahawa terdapat banyak daripada mereka. Bilangan lelaran yang terhad tidak membenarkan anda mengeksploitasi sepenuhnya semua faedah RUP. Pada masa yang sama, RUP juga boleh digunakan dalam praktikal projek air terjun, yang sebenarnya merangkumi hanya beberapa lelaran: satu dalam fasa "Bina" dan satu lagi dalam fasa "Pemindahan". By the way, dalam projek air terjun bilangan lelaran ini sebenarnya digunakan. Lagipun, ujian dan operasi percubaan sistem melibatkan membuat pembetulan, yang mungkin melibatkan tindakan tertentu yang berkaitan dengan analisis, reka bentuk dan pembangunan, iaitu, sebenarnya, mereka adalah satu lagi laluan melalui semua fasa pembangunan.

metodologi RUP

Bagi formaliti metodologi, RUP membentangkan pengguna dengan pelbagai kemungkinan yang sangat luas. Jika anda melakukan semua kerja dan tugas, mencipta semua artifak, dan menjalankan semua ulasan secara formal (dengan penyemak rasmi, dengan penyediaan semakan penuh dalam bentuk dokumen elektronik atau kertas, dll.), RUP boleh ternyata menjadi metodologi yang sangat formal dan rumit. Pada masa yang sama, RUP membenarkan anda untuk membangunkan artifak tersebut sahaja dan melaksanakan kerja dan tugasan yang diperlukan sahaja dalam projek tertentu. Dan artifak terpilih boleh dilaksanakan dan disemak dengan tahap formaliti sewenang-wenangnya. Anda boleh menuntut perincian terperinci dan pelaksanaan yang teliti bagi setiap dokumen, penyediaan semakan yang disiapkan dan dilaksanakan dengan teliti, malah, mengikut amalan lama, kelulusan bagi setiap semakan sedemikian oleh majlis saintifik dan teknikal perusahaan. Atau anda boleh menghadkan diri anda kepada e-mel atau lakaran di atas kertas. Di samping itu, sentiasa ada satu lagi kemungkinan: untuk membentuk dokumen di kepala anda, iaitu, memikirkan isu yang berkaitan dan membuat keputusan yang membina. Dan jika keputusan ini hanya melibatkan anda, maka hadkan diri anda, sebagai contoh, kepada komen dalam kod program.

Oleh itu, RUP ialah metodologi berulang dengan pelbagai kemungkinan penyelesaian yang sangat luas dari segi memformalkan proses pembangunan.

Mari kita ringkaskan bahagian kedua artikel. RUP, tidak seperti kebanyakan metodologi lain, membolehkan anda memilih dalam julat luas tahap pemformalan dan lelaran proses pembangunan, bergantung pada ciri-ciri projek dan organisasi yang sedang membangun.

Kami akan membincangkan mengapa ini sangat penting dalam bahagian seterusnya.

Hari ini dalam kejuruteraan perisian terdapat dua pendekatan utama untuk pembangunan perisian EIS, perbezaan asas antara yang disebabkan oleh kaedah penguraian sistem yang berbeza. Pendekatan pertama dipanggil fungsional-modular atau struktur. Ia berdasarkan prinsip penguraian berfungsi, di mana struktur sistem diterangkan dari segi hierarki fungsinya dan pemindahan maklumat antara elemen fungsi individu. Kedua, pendekatan berorientasikan objek menggunakan penguraian objek. Dalam kes ini, struktur sistem diterangkan dari segi objek dan hubungan antara mereka, dan kelakuan sistem diterangkan dari segi pertukaran mesej antara objek.

Jadi, intipati pendekatan struktur untuk pembangunan perisian EIS terletak pada penguraiannya (pecahan) ke dalam fungsi automatik: sistem dibahagikan kepada subsistem berfungsi, yang, seterusnya, dibahagikan kepada subfungsi, mereka menjadi tugas, dan seterusnya hingga ke prosedur tertentu. Pada masa yang sama, sistem automatik mengekalkan pandangan holistik di mana semua komponen saling berkaitan. Apabila membangunkan sistem "dari bawah ke atas", dari tugas individu kepada keseluruhan sistem, integriti hilang, dan masalah timbul apabila menerangkan interaksi maklumat komponen individu.

Semua kaedah pendekatan struktur yang paling biasa adalah berdasarkan beberapa prinsip umum. Prinsip asasnya ialah:

prinsip "bahagi dan takluk" (lihat subseksyen 2.1.1);

prinsip susunan hierarki ialah prinsip penyusunan komponen sistem ke dalam struktur pokok hierarki dengan penambahan butiran baru pada setiap peringkat.

Menyerlahkan dua prinsip asas tidak bermakna bahawa prinsip yang selebihnya adalah sekunder, kerana mengabaikan mana-mana daripadanya boleh membawa kepada akibat yang tidak dapat diramalkan (termasuk kegagalan keseluruhan projek). Yang utama daripada prinsip ini ialah:

prinsip abstraksi - menonjolkan aspek penting sistem dan mengabstraksikan daripada yang tidak penting;

prinsip ketekalan - kesahan dan ketekalan elemen sistem;

prinsip penstrukturan data - data mesti berstruktur dan teratur secara hierarki.

Pendekatan struktur menggunakan terutamanya dua kumpulan alat yang menerangkan struktur fungsi sistem dan hubungan antara data. Setiap kumpulan alat sepadan dengan jenis model tertentu (rajah), yang paling biasa ialah:

DFD (Data Flow Diagrams) - gambar rajah aliran data;

SADT (Analisis Berstruktur dan Teknik Reka Bentuk - kaedah analisis dan reka bentuk struktur) - model dan gambar rajah berfungsi yang sepadan;

ERD (Rajah Perhubungan Entiti) - gambar rajah hubungan entiti.

Gambar rajah aliran data dan gambar rajah hubungan entiti ialah jenis model yang paling biasa digunakan dalam alat CASE.

Bentuk khusus rajah yang disenaraikan dan tafsiran reka bentuknya bergantung pada peringkat kitaran hayat perisian.

Pada peringkat membentuk keperluan perisian, model SADT dan DFD digunakan untuk membina model "AS-IS" dan model "TO-BE", sekali gus mencerminkan struktur sedia ada dan cadangan proses perniagaan organisasi dan interaksi antara mereka ( penggunaan model SADT , sebagai peraturan, terhad kepada peringkat ini sahaja, kerana ia pada asalnya tidak bertujuan untuk reka bentuk perisian). Dengan bantuan ERD, penerangan tentang data yang digunakan dalam organisasi dijalankan pada peringkat konsep, bebas daripada alat pelaksanaan pangkalan data (DBMS).

Pada peringkat reka bentuk, DFD digunakan untuk menerangkan struktur sistem perisian yang direka, dan ia boleh diperhalusi, dikembangkan dan ditambah dengan reka bentuk baharu. Begitu juga, ERD diperhalusi dan ditambah dengan binaan baharu yang menerangkan perwakilan data pada tahap logik yang sesuai untuk penjanaan skema pangkalan data berikutnya. Model ini boleh ditambah dengan gambar rajah yang mencerminkan seni bina sistem perisian, gambar rajah blok program, hierarki bentuk skrin dan menu, dsb.

Model yang disenaraikan bersama-sama memberikan penerangan lengkap mengenai perisian EIS, tidak kira sama ada sistem itu sedia ada atau baru dibangunkan. Komposisi gambar rajah dalam setiap kes tertentu bergantung pada kerumitan sistem dan kesempurnaan penerangan yang diperlukan.

Bidang subjek untuk kebanyakan contoh rajah yang diberikan dalam bab ini ialah sistem cukai Persekutuan Rusia, penerangan paling lengkap yang terkandung dalam Kod Cukai Persekutuan Rusia. Teknologi maklumat yang digunakan dalam sistem cukai Persekutuan Rusia mempunyai ciri-ciri tertentu.

1.Pengekodan

Pada peringkat pembangunan perisian, tindakan utama berikut dilakukan: pengekodan; ujian; pembangunan sistem bantuan PP; penciptaan dokumentasi pengguna; mencipta versi dan pemasangan perisian,

Pengekodan ialah proses menukar hasil reka bentuk peringkat tinggi dan peringkat rendah kepada produk perisian siap. Dalam erti kata lain, apabila pengekodan, model perisian yang disusun diterangkan menggunakan bahasa pengaturcaraan yang dipilih, yang boleh menjadi mana-mana bahasa sedia ada. Pilihan bahasa dijalankan sama ada atas permintaan pelanggan, atau mengambil kira masalah yang sedang diselesaikan dan pengalaman peribadi pembangun.

Apabila pengekodan, anda mesti mengikut standard untuk bahasa yang dipilih, contohnya, untuk bahasa C ia adalah ANSI C, dan untuk C++ ia adalah ISO/IEC 14882 "Standard untuk C++ ProgrammingLanguage".

Sebagai tambahan kepada piawaian yang diterima umum untuk bahasa pengaturcaraan, syarikat juga boleh membangunkan keperluan tambahannya sendiri untuk peraturan untuk menulis program. Mereka terutamanya berkaitan peraturan untuk memformat teks program.

Mengikuti standard dan peraturan syarikat membolehkan anda mencipta program yang berfungsi dengan betul, mudah dibaca dan difahami oleh pembangun lain, yang mengandungi maklumat tentang pembangun, tarikh penciptaan, nama dan tujuan, serta data yang diperlukan untuk pengurusan konfigurasi.

Pada peringkat pengekodan, pengaturcara menulis program dan mengujinya sendiri. Ujian jenis ini dipanggil ujian unit. Semua isu yang berkaitan dengan ujian perisian dibincangkan dalam Bab. 10, teknologi ujian yang digunakan pada peringkat pembangunan perisian juga diterangkan di sini. Teknologi ini dipanggil ujian "kotak kaca" (kotak kaca); kadang-kadang ia juga dipanggil ujian "kotak putih" (kotak putih) bertentangan dengan konsep klasik "kotak hitam".

Dalam ujian kotak hitam, program dianggap sebagai objek yang struktur dalamannya tidak diketahui. Penguji memasukkan data dan menganalisis hasilnya, tetapi dia tidak tahu dengan tepat bagaimana program itu berfungsi. Apabila memilih ujian, pakar mencari data input dan keadaan yang menarik dari sudut pandangannya, yang boleh membawa kepada keputusan yang tidak standard. Beliau amat berminat dengan wakil bagi setiap kelas data input di mana ralat dalam program yang sedang diuji kemungkinan besar berlaku.

Apabila menguji "kotak kaca" keadaannya berbeza sama sekali. Penguji (dalam kes ini pengaturcara sendiri) membangunkan ujian berdasarkan pengetahuan tentang kod sumber, yang dia mempunyai akses penuh. Akibatnya, dia menerima faedah berikut.

1. Arah ujian. Pengaturcara boleh menguji atur cara dalam bahagian, membangunkan subrutin ujian khas yang memanggil modul yang sedang diuji dan menghantar kepadanya data yang menarik kepada pengaturcara. Adalah lebih mudah untuk menguji modul berasingan sebagai "kotak kaca".

2.Liputan kod penuh. Pengaturcara sentiasa boleh menentukan serpihan kod yang berfungsi dalam setiap ujian. Dia melihat cabang kod lain yang masih belum diuji dan boleh memilih keadaan di mana ia akan diuji. Berikut menerangkan cara menjejak tahap liputan kod ujian yang dilakukan.

3. Kebolehan mengawal aliran arahan. Pengaturcara sentiasa mengetahui fungsi mana yang harus dilaksanakan seterusnya dalam program dan keadaan semasanya. Untuk mengetahui sama ada program berfungsi seperti yang difikirkannya, pengaturcara boleh memasukkan perintah penyahpepijatan yang memaparkan maklumat tentang pelaksanaannya atau menggunakan alat perisian khas yang dipanggil penyahpepijat untuk melakukan ini. Penyahpepijat boleh melakukan banyak perkara berguna: memantau dan menukar urutan pelaksanaan perintah program, tunjukkan kandungan pembolehubahnya dan alamatnya dalam ingatan, dsb.

4.Keupayaan untuk memantau integriti data. Pengaturcara tahu bahagian mana program harus menukar setiap elemen data. Dengan memantau keadaan data (menggunakan penyahpepijat yang sama), dia boleh mengenal pasti ralat seperti data yang diubah oleh modul yang salah, tafsiran yang salah atau organisasi yang tidak berjaya.

5. Visi titik sempadan dalaman. Dalam kod sumber, titik sempadan program yang disembunyikan dari pandangan luar kelihatan. Sebagai contoh, beberapa algoritma yang sama sekali berbeza boleh digunakan untuk melakukan tindakan tertentu, dan tanpa melihat kod, adalah mustahil untuk menentukan yang mana yang dipilih pengaturcara. Satu lagi contoh biasa ialah masalah limpahan dalam penimbal yang digunakan untuk menyimpan data input buat sementara waktu. Pengaturcara boleh segera memberitahu jumlah data penimbal akan melimpah, dan dia tidak perlu menjalankan beribu-ribu ujian.

6. Kemungkinan ujian ditentukan oleh algoritma yang dipilih. Menguji pemprosesan data yang menggunakan algoritma pengiraan yang sangat kompleks mungkin memerlukan teknologi khas. Contoh klasik termasuk transformasi matriks dan pengisihan data. Seorang penguji, tidak seperti pengaturcara, perlu mengetahui dengan tepat algoritma apa yang digunakan, jadi dia perlu beralih kepada kesusasteraan khusus.

Ujian kotak kaca adalah sebahagian daripada proses pengaturcaraan. Pengaturcara melakukan kerja ini sepanjang masa; mereka menguji setiap modul selepas menulisnya, dan sekali lagi selepas menyepadukannya ke dalam sistem.

Apabila melakukan ujian unit, anda boleh menggunakan sama ada teknologi ujian struktur atau fungsi, atau kedua-duanya.

berstruktur ujian adalah sejenis ujian kotak kaca. Idea utamanya ialah pilihan laluan perisian yang betul untuk diuji. Berbeza dengan dia berfungsi ujian termasuk dalam kategori ujian kotak hitam. Setiap fungsi program diuji dengan memasukkan data input dan menganalisis outputnya. Pada masa yang sama, struktur dalaman program sangat jarang diambil kira.

Walaupun ujian struktur mempunyai asas teori yang lebih kukuh, kebanyakan penguji lebih suka ujian berfungsi. Ujian struktur lebih sesuai untuk pemodelan matematik, tetapi ini tidak bermakna ia lebih berkesan. Setiap teknologi membolehkan anda mengenal pasti ralat yang terlepas apabila menggunakan yang lain. Dari sudut pandangan ini, mereka boleh dipanggil sama berkesan.

Objek ujian boleh bukan sahaja laluan penuh program (urutan arahan yang dilaksanakan dari awal hingga akhir), tetapi juga bahagian individunya. Adalah tidak realistik untuk menguji semua cara yang mungkin untuk melaksanakan program. Oleh itu, pakar ujian mengenal pasti dari semua laluan yang mungkin kumpulan yang benar-benar perlu diuji. Untuk pemilihan mereka menggunakan kriteria khas yang dipanggil kriteria perlindungan (kriteria perlindungan), yang menentukan bilangan ujian yang sangat nyata (walaupun agak besar). Kriteria ini kadangkala dipanggil kriteria liputan logik, atau kriteria kesempurnaan.

3. Pembangunan sistem bantuan untuk produk perisian. Mencipta Dokumentasi Pengguna

Adalah dinasihatkan untuk melantik salah seorang pekerja projek sebagai editor teknikal dokumentasi. Pekerja ini juga mungkin melakukan kerja lain, tetapi tugas utamanya adalah menganalisis dokumentasi, walaupun pekerja lain juga sedang membangunkannya.

Selalunya berlaku bahawa beberapa orang bekerja pada penciptaan perisian, tetapi tiada seorang pun daripada mereka bertanggungjawab sepenuhnya untuk kualitinya. Akibatnya, perisian itu bukan sahaja tidak mendapat manfaat daripada fakta bahawa lebih ramai orang membangunkannya, tetapi juga rugi, kerana masing-masing secara tidak sedar mengalihkan tanggungjawab kepada yang lain dan menjangkakan bahawa rakan sekerjanya akan melakukan ini atau bahagian kerja itu. Masalah ini diselesaikan dengan melantik editor yang bertanggungjawab sepenuhnya ke atas kualiti dan ketepatan dokumentasi teknikal.

Sistem bantuan PP dibentuk berdasarkan bahan yang dibangunkan untuk manual pengguna. Ia dibentuk dan dicipta oleh orang yang bertanggungjawab untuk melaksanakan kerja ini. Ia boleh sama ada editor teknikal atau salah satu pembangun bersama-sama dengan editor teknikal.

Perisian yang didokumentasikan dengan baik mempunyai kelebihan berikut.

1. Kemudahan penggunaan. Jika perisian didokumentasikan dengan baik, ia lebih mudah digunakan. Pengguna mempelajarinya dengan lebih cepat, membuat lebih sedikit kesilapan, dan akibatnya melakukan kerja mereka dengan lebih cepat dan lebih cekap.

2. Kos sokongan teknikal yang lebih rendah. Apabila pengguna tidak dapat memikirkan cara untuk melakukan tindakan yang dia perlukan, dia menghubungi perkhidmatan sokongan teknikal pengeluar PCB. Menjalankan perkhidmatan sedemikian adalah sangat mahal. Manual yang baik membantu pengguna menyelesaikan masalah mereka sendiri dan mengurangkan keperluan untuk menghubungi pasukan sokongan teknikal.

3. Kebolehpercayaan yang tinggi. Dokumentasi yang tidak dapat difahami atau ceroboh menjadikan perisian kurang boleh dipercayai kerana penggunanya lebih cenderung melakukan kesilapan dan sukar untuk memahami apa yang menyebabkannya dan cara menangani akibatnya.

Kemudahan penyelenggaraan. Sejumlah besar wang dan masa dihabiskan untuk menganalisis masalah yang disebabkan oleh kesilapan pengguna. Perubahan yang dibuat dalam keluaran perisian baharu selalunya hanyalah perubahan pada antara muka fungsi lama. Mereka diperkenalkan supaya pengguna akhirnya mengetahui cara menggunakan perisian dan berhenti menghubungi sokongan teknikal. Pengurusan yang baik pada tahap yang besar

Jadi, intipati pendekatan struktur untuk pembangunan perisian EIS terletak pada penguraiannya (pecahan) ke dalam fungsi automatik: sistem dibahagikan kepada subsistem berfungsi, yang, seterusnya, dibahagikan kepada subfungsi, mereka menjadi tugas, dan seterusnya hingga ke prosedur tertentu. Pada masa yang sama, sistem mengekalkan pandangan holistik di mana semua komponen saling berkaitan. Apabila membangunkan sistem "bottom-up", dari tugas individu kepada keseluruhan sistem, integriti hilang, masalah timbul apabila menerangkan interaksi maklumat komponen individu.

Semua kaedah pendekatan struktur yang paling biasa adalah berdasarkan beberapa prinsip umum:

1. Prinsip "bahagi dan takluk";

2. Prinsip susunan hierarki ialah prinsip penyusunan komponen sistem ke dalam struktur pokok hierarki dengan penambahan butiran baru pada setiap peringkat.

Mengasingkan dua prinsip asas tidak bermakna bahawa prinsip yang selebihnya adalah sekunder, kerana mengabaikan mana-mana daripadanya boleh membawa kepada akibat yang tidak dapat diramalkan (termasuk kegagalan keseluruhan projek"). Yang utama daripada prinsip ini ialah:

1. Prinsip abstraksi - menonjolkan aspek penting sistem dan mengabstraksikan daripada yang tidak penting.

2. Prinsip ketekalan, kesahan dan ketekalan elemen sistem.

3. Prinsip penstrukturan data - data mestilah berstruktur dan teratur mengikut hierarki.

Dalam pendekatan struktur, terdapat terutamanya dua kumpulan alat yang menerangkan struktur fungsi sistem dan hubungan antara data. Setiap kumpulan alat sepadan dengan jenis model tertentu (rajah), yang paling biasa di antara mereka ialah:

· DFD (Data Flow Diagrams) - rajah aliran data;

· SADT (Analisis Berstruktur dan Teknik Reka Bentuk - metodologi analisis dan reka bentuk struktur) - model dan gambar rajah berfungsi yang sepadan: tatatanda IDEF0 (pemodelan fungsi sistem), IDEF1х (pemodelan konseptual pangkalan data), IDEF3х (pembinaan sistem untuk menilai kualiti kerja objek; penerangan grafik proses aliran, interaksi proses dan objek yang diubah oleh proses ini);

· ERD (Entiti - Rajah Hubungan) - rajah hubungan entiti.

Hampir semua kaedah pendekatan struktur (analisis struktur) pada peringkat pembentukan keperluan perisian menggunakan dua kumpulan alat pemodelan:

1. Gambar rajah yang menggambarkan fungsi yang mesti dilakukan oleh sistem dan hubungan antara fungsi ini - DFD atau SADT (IDEF0).

2. Gambar rajah yang memodelkan data dan hubungannya (ERD).

Bentuk khusus rajah yang disenaraikan dan tafsiran reka bentuknya bergantung pada peringkat kitaran hayat perisian.

Pada peringkat membentuk keperluan perisian, model SADT dan DFD digunakan untuk membina model “AS-IS” dan model “TO-BE”, dengan itu mencerminkan struktur sedia ada dan cadangan proses perniagaan organisasi dan interaksi antara mereka ( penggunaan model SADT seperti biasanya terhad kepada peringkat ini sahaja, kerana ia pada asalnya tidak bertujuan untuk reka bentuk perisian). Dengan bantuan ERD, penerangan tentang data yang digunakan dalam organisasi dijalankan pada peringkat konsep, tanpa mengira alat pelaksanaan pangkalan data (DBMS).

1. Tujuan teknologi pengaturcaraan. Sejarah perkembangan teknologi pengaturcaraan. Jenis projek perisian. Komponen teknologi pengaturcaraan. Projek, produk, proses dan orang

2. Kitaran hayat program. Sifat kitaran pembangunan. Konsep asas teknologi pengaturcaraan. Proses dan model. Fasa dan pusingan. Pencapaian dan artifak. Pihak berkepentingan dan pekerja.

3. Pengenalpastian dan analisis keperluan. Keperluan perisian. Carta alir pembangunan keperluan. Pengurusan keperluan.

4. Reka bentuk seni bina dan terperinci. Pelaksanaan dan pengekodan. Pengujian dan pengesahan. Proses kawalan kualiti. Kaedah kotak putih dan kotak hitam. Pemeriksaan dan ulasan. Menguji matlamat. Pengesahan, pengesahan dan ujian sistem. Penyelenggaraan dan pembangunan berterusan.

5. Model proses pembangunan. Model air terjun dan penghantar. Model lingkaran dan tambahan. Model proses pembangunan yang fleksibel.

6. Pembinaan model proses. Kenal pasti keperluan proses. Fasa, peristiwa penting dan artifak yang digunakan. Memilih seni bina proses. Prosedur untuk menjalankan projek standard. Prosedur yang didokumenkan.

7. Model pasukan pembangunan. Sifat pembangunan kolektif. Saiz pasukan yang optimum. Penubuhan peserta projek. Pembangunan pasukan dan pembangunan kakitangan. Pengkhususan, kerjasama dan interaksi.

8. Model pasukan pembangunan. Model pasukan hierarki. Kaedah pasukan pembedahan. Model pasukan rakan sebaya.

9. Sifat pengaturcaraan. Ilmu pengaturcaraan. Seni pengaturcaraan. Kerajinan pengaturcaraan. Paradigma pengaturcaraan. Pengaturcaraan berstruktur. Pengaturcaraan logik. Pengaturcaraan berorientasikan objek.

10. Seni bina perisian. Pengurusan acara. Seni bina pelanggan/pelayan. Perkhidmatan. Seni bina tiga lapisan. Reka bentuk program. Reka bentuk konsep. Reka bentuk logik. Reka bentuk terperinci.

1. Pendekatan Novikov kepada pembangunan perisian" http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Pengaturcaraan yang melampau. – St. Petersburg: Peter, 2002.

3. Teknologi pembangunan perisian. – St. Petersburg. : Peter, 2004.

4. Brooks Jr. sistem perisian direka dan dicipta. M.: Nauka, 1975; edisi baharu terjemahan: The Mythical Man-Month. SPb.: SYMBOL+, 1999.

5. Algoritma + struktur data = atur cara. M., Mir, 1978.

6. Pengaturcaraan sistematik. pengenalan. M.: Mir, 1977.

7. Pengaturcaraan berstruktur. M.: Mir, 1975.

8. Disiplin pengaturcaraan. M.: Mir, 1978.

9. Teknologi pembangunan perisian. – St. Petersburg: Peter, 2002.

10. Pengaturcaraan Terekhov. M.: BINOM, 2006.

11. Rambo J. Proses pembangunan perisian bersatu. St. Petersburg: Peter, 2002.

Teori Ekonomi untuk Pengurus

Teori asas mikroekonomi. Contoh aplikasi dalam analisis proses ekonomi. Teori asas makroekonomi. Contoh aplikasi dalam analisis proses ekonomi. Prinsip dan kaedah mengurus proses ekonomi. Alat untuk menilai tahap pembangunan proses ekonomi Masalah pembiakan berkembang. Faktor pertumbuhan ekonomi ekonomi Rusia. Kriteria dan petunjuk pembangunan mampan. Melancarkan turun naik kitaran. Peranan pengganda dan pemecut dalam menilai kepesatan pembangunan ekonomi. Fungsi pengeluaran dalam ekonomi. Contoh aplikasi dalam analisis proses ekonomi. Untung. Pengiraan penunjuk yang mempengaruhi keuntungan, perwakilan grafik titik pulang modal. Metodologi untuk melaksanakan dasar pelaburan.

Kursus teori ekonomi: buku teks untuk universiti / Ed. . –Kirov: “ASA”, 2004. Kolemaev - pemodelan matematik. Memodelkan proses dan sistem makroekonomi: buku teks. M.: UNITY-DANA, 2005. Bazhin cybernetics. Kharkov: Konsul, 2004. Bengkel Leushin mengenai kaedah pemodelan matematik: buku teks. Negeri Nizhny Novgorod teknologi univ. - N. Novorod, 2007. Ahli politik tentang ekonomi: Syarahan oleh pemenang Nobel dalam bidang ekonomi. M.: Ekonomi dan undang-undang moden, 2005. Cheremnykh. Tahap lanjutan: Buku Teks.-M.:INFRA-M, 2008. Evolusi institusi ekonomi mini. Institut Ekonomi, Cawangan Ural Akademi Sains Rusia, - M.: Nauka, 2007.

Teknologi untuk pembangunan dan membuat keputusan pengurusan [N]

Membuat keputusan sebagai asas aktiviti pengurus. Pengenalan kepada teori keputusan. Konsep asas teori keputusan. Model pengurusan perniagaan dan kesannya terhadap pembuatan keputusan. Cara yang berbeza untuk mengklasifikasikan penyelesaian. Klasifikasi: mengikut tahap formaliti, mengikut tahap rutin, mengikut kekerapan, mengikut segera, mengikut tahap pencapaian matlamat, mengikut kaedah memilih alternatif. Kaedah asas membuat keputusan. Kaedah sukarela membuat keputusan. Matlamat membuat keputusan. Masa apabila mencari penyelesaian. Kesilapan asas Kaedah matematik membuat keputusan. Aspek matematik teori keputusan. Penyelidikan Operasi. Pendekatan matematik untuk membuat keputusan. Pokok keputusan. Model pembangunan dan membuat keputusan. Teori permainan. Kaedah matematik membuat keputusan. Aspek matematik teori keputusan. Model teori beratur. Model pengurusan inventori. Model pengaturcaraan linear. Tugas pengangkutan. Pemodelan simulasi. Analisis rangkaian. Analisis ekonomi. Had model rasional. Ciri-ciri pembangunan dan membuat keputusan dalam kumpulan. Kaedah untuk menentukan kesepaduan kumpulan berdasarkan tahap ketersambungan set. Kaedah untuk membuat keputusan kolektif. Kaedah muafakat. Kaedah pengundian. Kaedah kreatif membuat keputusan. Sumbangsaran. Persidangan idea. Majlis Kapal. Kaedah "Thinking Hats" De Bono. Teori penyelesaian masalah inventif (TRIZ). Penyelesaian akhir yang sempurna. Contoh masalah dan penyelesaiannya menggunakan TRIZ. Penggunaan kaedah TRIZ semasa membuat keputusan yang unik dan kreatif. Kaedah untuk membangunkan idea penyelesaian dan menyesuaikannya dengan situasi. Model pokok matlamat. Strategi untuk menyelaraskan kepentingan. Pembentukan keputusan untuk menyelaraskan kepentingan. Kaedah untuk menentukan kepentingan rakan niaga. Sistem sokongan keputusan (sistem pakar). Sejarah penciptaan sistem membuat keputusan. Klasifikasi sistem membuat keputusan. Struktur tipikal sistem pakar. Kaedah penyampaian ilmu. Kaedah inferens logik. Aplikasi sistem pakar dalam amalan.

I. Teori Membuat Keputusan: Buku Teks. - M.: Peperiksaan, 2006. - 573 p. I. Membuat keputusan. Teori dan kaedah untuk membangunkan keputusan pengurusan. Panduan belajar. - M.: MarT, 2005. - 496 ms Pembangunan keputusan pengurusan - M.: Publishing House "Delo", 2004 - 392 pp. G. Penilaian pakar dan membuat keputusan - M.: Paten, 1996. - 271 p. Taha // Pengenalan kepada Penyelidikan Operasi = Penyelidikan Operasi: Satu Pengenalan. - ed ke-7. - M.: "Williams", 2007. - P. 549-594. G. Theil. Ramalan ekonomi dan membuat keputusan. M.: "Kemajuan" 1970. K. D. Lewis. Kaedah untuk meramal penunjuk ekonomi. M.: "Kewangan dan Statistik" 1986. G. S. Kildishev, A. A. Frenkel. Analisis dan ramalan siri masa. M.: "Statistik" 1973. O. Kim, C. W. Muller, U. R. Klekka dan lain-lain analisis faktor, diskriminasi dan kelompok. M.: “Kewangan dan Perangkaan” 1989. Pengurus yang berkesan. Buku 3. Membuat keputusan. – MIM LINK, 1999 Turevsky dan pengurusan perusahaan pengangkutan motor. - M.: Sekolah Tinggi, 2005. , ; disunting oleh . Analisis sistem dalam pengurusan: buku teks. – M.: Kewangan dan Statistik, 2006. , Tinkov: buku teks. – M.: KNORUS, 2006.

Memodelkan proses perniagaan dalam sistem pengurusan bersepadu

Dengan prinsip apakah proses perniagaan dibezakan? Apakah masalah penerangan holistik proses perniagaan? Apakah sistem, apakah sifat yang ada padanya? Peranan analisis sistem dalam pemodelan proses perniagaan? Proses sebagai objek kawalan. Persekitaran proses. Elemen asas proses perniagaan. Kebaikan dan keburukan pengurusan fungsian dan proses. Kitaran pengurusan PDCA. Peringkat kitaran pengurusan proses. Kitaran PDCA dan pelaksanaan keperluan ISO 9001:2008. Metodologi SADT (Analisis Berstruktur dan Teknik Reka Bentuk - kaedah analisis dan reka bentuk struktur). Intipati. Peruntukan asas. Bagaimanakah model fungsi aktiviti diwakili dalam metodologi IDEF0? Apakah maksud aktiviti dalam rajah model berfungsi, bagaimana ia dipaparkan mengikut metodologi IDEF0? Untuk apa anak panah dalam rajah model berfungsi, apakah jenis dan jenisnya? Metodologi DFD. Intipati. Komponen asas gambar rajah DFD. Apakah ciri-ciri gambar rajah DFD dan apakah yang diterangkan di dalamnya? Apakah ciri-ciri objek gambar rajah DFD? Apakah maksud anak panah pada gambar rajah DFD? Metodologi IDEF3. Intipati. Alat dokumentasi dan pemodelan. Apakah ciri-ciri gambar rajah IDEF3 dan apakah yang diterangkan di dalamnya? Apakah ciri-ciri objek gambar rajah IDEF3? Dan penembak? Klasifikasi proses. Proses perniagaan biasa. Kejuruteraan semula dan teknologinya. Bilakah dinasihatkan untuk menggunakan kejuruteraan semula semasa menguruskan syarikat? Proses pemantauan dan pengukuran. Penunjuk proses organisasi. Penilaian berangka dan penilaian proses.

"Memodelkan proses perniagaan dengan AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Mencipta sistem maklumat dengan AllFusion Modelling Suite" ed. "Dialogue-MEPhI" 2003 "Amalan pemodelan berfungsi dengan AllFusion Process Modeler 4.1. (BPwin) Di mana? Mengapa? Bagaimana?" ed. "Dialogue-MEPhI" 2004 Dubeykovsky modelling dengan AllFusion Process Modeler (BPwin). ed. "Dialog-MEPhI" 2007 D. Mark, K. McGowan "Metodologi analisis struktur dan reka bentuk SADT" 1993 kerja klasik mengenai metodologi SADT. Analisis Cheremnykh sistem: IDEF-teknologi, Pemodelan dan analisis sistem. teknologi IDEF. Bengkel. M.: Kewangan dan Statistik, 2001. “Model perniagaan struktur: teknologi DFD” http://www. /Level4.asp? ItemId=5810 "Teori dan amalan penyusunan semula proses perniagaan" 2003/ P50.1.. Metodologi pemodelan fungsional. M.: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Memodelkan proses perniagaan menggunakan BPwin http://www. /department/se/devis/7/ IDEF0 dalam memodelkan proses pengurusan perniagaan http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Menilai keberkesanan produk perisian

1. Seni bina IT

2. Domain proses pengurusan.

3. Senarai proses dalam domain Perancangan dan Organisasi

4. Senarai proses domain Pemerolehan dan Pelaksanaan

5. Senarai proses dalam domain Operasi dan Penyelenggaraan

6. Senarai proses dalam domain Pemantauan dan Penilaian

7. Ciri-ciri tahap model kematangan proses

9. KPI dan KGI hubungan dan tujuan mereka

1. 10.Kawalan IT am dan kawalan aplikasi. Bidang tanggungjawab dan tanggungjawab perniagaan dan IT.

Cobit 4.1 edisi Rusia.

Peraturan undang-undang mengenai penciptaan dan penggunaan harta intelek

1. Senaraikan hak intelek terhadap hasil aktiviti intelektual dan dedahkan kandungannya.

2. Senaraikan jenis perjanjian untuk pelupusan hak eksklusif. Terangkan setiap perjanjian mengenai pelupusan hak eksklusif ini.

4. Huraikan peruntukan utama perlindungan undang-undang Program Komputer sebagai objek hak cipta.

5. Bandingkan peruntukan utama perlindungan undang-undang Pangkalan Data sebagai objek hak cipta dan sebagai objek hak berkaitan.

6. Huraikan syarat untuk kebolehpaten objek hak paten: ciptaan; model utiliti; reka bentuk perindustrian.

7. Kembangkan kandungan kriteria kebolehpaten bagi sesuatu ciptaan: kebaharuan; langkah inventif; kebolehgunaan industri.

8. Huraikan syarat dan prosedur untuk mendapatkan paten bagi ciptaan, model utiliti atau reka bentuk perindustrian, serta syarat yang memastikan kesahihan paten dan tempoh sahnya.

9. Tentukan "pengetahuan" dan senaraikan syarat semasa penciptaan perlindungan undang-undang rahsia pengeluaran timbul dan dijalankan.

10. Senaraikan cara-cara individuisasi yang dilindungi dan berikan ciri-ciri perbandingannya.

1., Hak harta intelek di Persekutuan Rusia, buku teks // M, Prospekt, 2007.

2., Undang-undang Harta Intelek, buku teks // M, RIOR, 2009.

Pengurusan pembangunan projek dan perisian [I]

Apakah metodologi, mengapa ia diperlukan. Struktur am metodologi, elemen utama metodologi. Prinsip untuk mereka bentuk metodologi anda sendiri. Contoh pelbagai artifak, peranan, kecekapan, syarat sempadan. Struktur metodologi mengikut Cowburn, metrik metodologi. Kriteria reka bentuk Cowburn. Kriteria untuk memilih metodologi, matriks Cowburn. Kitaran hayat projek. Air terjun dan model kitaran hayat berulang. Had kebolehgunaan untuk model air terjun dan lelaran. RUP sebagai contoh metodologi berulang. Konsep asas RUP, had kebolehgunaan. Peranan manusia dalam pembangunan perisian. Metodologi tangkas, prinsip asas metodologi tangkas. Sebab kemunculan metodologi yang fleksibel. Scrum sebagai contoh metodologi yang fleksibel. Peranan, artifak, aktiviti dalam Scrum. Had kebolehgunaan scrum. Pengaturcaraan Ekstrim (XP) Idea, nilai, amalan asas, had kebolehgunaan. Persamaan dan perbezaan antara Scrum dan XP. Pengumpulan dan pengurusan keperluan. Amalan asas, istilah, prinsip. Pendekatan untuk mendokumentasikan projek dan produk, jenis dokumen utama. Contoh amalan pengurusan keperluan daripada metodologi yang dibincangkan dalam kursus. Perancangan pembangunan perisian. Jenis pelan, pengurusan risiko, risiko popular. Contoh amalan perancangan pembangunan daripada metodologi yang dibincangkan dalam kursus. Pengujian dalam pembangunan perisian. Konsep pemasangan (bina) produk perisian. Kaedah ujian asas, syarat. Contoh amalan ujian daripada metodologi yang dibincangkan dalam kursus. Konsep pemasangan (bina), kaedah menyimpan kod, alat. Dua prinsip untuk mengatur kerja dengan sistem kawalan versi. Ciri-ciri proses keluaran/paparan produk untuk kategori produk yang berbeza, contoh amalan. Konsep moden seni bina perisian, seni bina pelbagai peringkat, kriteria seni bina. Senarai keputusan yang diperlukan semasa mereka bentuk perisian, pendekatan untuk memilih sistem penyimpanan data.

Kent Beck - Pengaturcaraan Extreme Frederick Brooks - The Mythical Man-Month atau cara sistem perisian dicipta. Tom DeMarco - Tarikh Akhir. Novel tentang pengurusan projek. Tom De Marco, Timothy Lister - Bersiar-siar dengan Beruang. Tom de Marco, Timothy Lister - Faktor manusia_ projek dan pasukan yang berjaya. Alistair Cowburn - Setiap projek mempunyai metodologi tersendiri. Alistair Cowburn - Orang sebagai bukan linear dan komponen terpenting dalam mencipta perisian. Andriy Orlov - Nota jurutera automasi. Pengakuan profesional. Philipp Kratchen - Pengenalan kepada Proses Bersepadu Rasional. Henrik Kniberg - Scrum dan XP: nota dari barisan hadapan. Pembentangan kuliah mengenai kursus