Ketika mempertimbangkan teknologi pengembangan perangkat lunak, perlu untuk menggunakan pendekatan sistematis, yang melibatkan tidak mempertimbangkan beberapa aspek individu dari masalah pengembangan perangkat lunak, tetapi masalah secara keseluruhan. Pendekatan sistem diimplementasikan dalam ruang dan waktu.

Pendekatan sistematis dalam waktu mempertimbangkan urutan tahapan pembuatan perangkat lunak dari saat pembentukan kebutuhan perangkat lunak yang tidak terpenuhi sampai izinnya dan dukungan dalam pengoperasian yang diterima produk perangkat lunak.

Pendekatan sistem dalam "ruang" menyediakan untuk pertimbangan perangkat lunak yang dikembangkan sebagai bagian dari sistem. Pada saat yang sama, berdasarkan studi kebutuhan informasi sistem, yang akan mencakup perangkat lunak yang dikembangkan, tujuan dan serangkaian fungsi perangkat lunak dirumuskan, prototipe dianalisis. alat perangkat lunak. Persyaratan perangkat lunak dibentuk dan didokumentasikan.

Teknologi modern Pengembangan perangkat lunak menganggap pemrograman sebagai salah satu tahap pengembangan dalam rantai tahapan yang berurutan dari siklus pengembangan. Semua tahapan ini disatukan oleh konsep siklus hidup perangkat lunak dan harus didukung oleh perangkat lunak dan perangkat keras yang sesuai.

Sesuai dengan standar internasional ISO/IEC 12207" Teknologi Informasi– Proses siklus hidup perangkat lunak” proses pengembangan perangkat lunak berisi tahapan berikut dari siklus hidup perangkat lunak:

1) analisis Persyaratan sistem dan ruang lingkup;

2) desain arsitektur sistem;

3) analisis kebutuhan perangkat lunak (spesifikasi, antarmuka eksternal,);

4) desain arsitektur perangkat lunak;

5) desain rinci dari setiap unit perangkat lunak;

6) pengkodean perangkat lunak (pemrograman)

7) pengujian unit perangkat lunak;

8) integrasi (penyatuan perangkat lunak) dan pengujian satu set unit perangkat lunak;

9) tes kualifikasi perangkat lunak (pengujian terintegrasi);

10) unit struktur perangkat lunak integrasi sistem harus terintegrasi dengan unit perangkat keras;

11) uji kualifikasi sistem;

12) instalasi perangkat lunak.

Dengan demikian, proses pengembangan perangkat lunak dimulai dari sistem dimana perangkat lunak ini akan digunakan dan berakhir kembali pada sistem.

Setelah tahap pengembangan dalam siklus hidup perangkat lunak, tahap operasi perangkat lunak dan pemeliharaan dalam operasi berikut. Terkadang daftar tahapan siklus hidup perangkat lunak diberikan dengan beberapa generalisasi (agregasi) dari 12 tahapan. Misalnya tahapan merancang sistem dan menentukan kebutuhan perangkat lunak, merancang paket perangkat lunak, merancang algoritma perangkat lunak, pemrograman (coding), debugging perangkat lunak offline, debugging perangkat lunak yang kompleks, operasi perangkat lunak.

Mengabaikan tahapan desain perangkat lunak, keinginan untuk segera memulai pemrograman tanpa studi algoritma yang memadai dan masalah interaksi unit struktural perangkat lunak sering menyebabkan proses pengembangan perangkat lunak yang kacau dengan sedikit peluang untuk berhasil.

Model siklus hidup perangkat lunak spiral. Teknologi pengembangan perangkat lunak "berat dan ringan" (cepat)

Model siklus hidup yang dipertimbangkan (LC) termasuk dalam model tipe kaskade. Jenis model siklus hidup ini baik untuk perangkat lunak yang, pada awal pengembangan, memungkinkan untuk merumuskan semua persyaratan perangkat lunak secara lengkap dan akurat.

Skema siklus hidup perangkat lunak spiral. Namun, proses nyata pengembangan perangkat lunak tidak selalu sesuai dengan skema yang kaku dan seringkali ada kebutuhan untuk kembali ke tahap sebelumnya dengan klarifikasi atau revisi keputusan yang dibuat.

Untuk perangkat lunak, serta untuk sistem kompleks lainnya, persyaratan awal yang tidak cukup lengkap, proses pengembangan berulang adalah karakteristik. Pada saat yang sama, untuk beberapa jenis perangkat lunak, bahkan diinginkan untuk pindah ke tahap berikutnya secepat mungkin. Pada saat yang sama, kekurangan yang tak terhindarkan dengan pekerjaan tergesa-gesa seperti itu dihilangkan pada iterasi berikutnya atau tetap selamanya.

Tugas utama adalah untuk mencapai perangkat lunak yang dapat diterapkan sesegera mungkin, sehingga mengaktifkan proses klarifikasi dan penambahan persyaratan. Inilah yang disebut model siklus hidup perangkat lunak spiral.

Pada setiap putaran spiral, versi produk dibuat, persyaratan perangkat lunak ditentukan, dan pekerjaan putaran berikutnya direncanakan. Model siklus hidup perangkat lunak spiral mencerminkan proses pengembangan perangkat lunak berulang yang ada secara objektif (Gbr. 8.2).

Diyakini bahwa skema spiral siklus hidup perangkat lunak dimaksudkan tidak begitu banyak untuk pengembang yang tergesa-gesa, tetapi untuk perangkat lunak, versi pertama berkualitas rendah yang dapat diterima untuk tujuan fungsional perangkat lunak.

Ada arah "Teknologi Cepat" pengembangan perangkat lunak (Agile Software Development), yang memberikan pembenaran ideologis untuk pandangan yang terkait dengan model spiral siklus hidup. Teknologi ini didasarkan pada empat ide:

Interaksi interaktif individu lebih penting daripada prosedur dan alat formal,

Perangkat lunak yang berfungsi lebih penting daripada memiliki dokumentasi untuk itu,

Kerjasama dengan pelanggan lebih penting daripada kontrak formal,

Respon cepat untuk perubahan eksternal lebih penting daripada mengikuti rencana secara ketat.

Beras. 8.2 - Skema siklus hidup perangkat lunak spiral

Dengan kata lain, teknologi cepat ditujukan untuk menggantikan prosedur interaksi terdokumentasi formal dan memakan waktu selama pengembangan dengan yang interaktif, yang dimungkinkan dengan ukuran proyek kecil, kualitas karyawan yang dipilih, penempatan pengembang dan pelanggan "di ruangan yang sama" dan untuk mengembangkan perangkat lunak untuk sistem non-kritis.

Kebenaran prinsip-prinsip ini sampai batas tertentu ketika pengembangan perangkat lunak dilakukan oleh sejumlah kecil "penggemar" yang memenuhi syarat dan berdedikasi untuk pengembangan jenis perangkat lunak tertentu sulit untuk diperdebatkan. Namun, teknologi Agile dan ideolognya mengakui bahwa ini dapat diterapkan dalam proyek perangkat lunak dari kelas dan skala tertentu, seperti model siklus hidup spiral pada umumnya, yaitu, di mana kesalahan perangkat lunak menyebabkan ketidaknyamanan atau hilangnya dana yang dapat dipulihkan.

Jika perangkat lunak yang tidak berfungsi dengan benar menyebabkan ancaman terhadap kehidupan manusia atau kerugian materi yang besar, teknologi yang dipikirkan dengan matang harus digunakan untuk memastikan keandalan produk perangkat lunak.

Dengan peningkatan skala proyek perangkat lunak - peningkatan jumlah orang yang berpartisipasi di dalamnya, kebutuhan akan teknologi pengembangan yang kaku yang membentuk siklus hidup perangkat lunak kaskade meningkat. Dokumentasi diperlukan di sini, karena setiap saat kehilangan salah satu pengembang mungkin terjadi, formalisasi komunikasi antarprogram, manajemen perubahan perangkat lunak, dll. Tidaklah sia-sia bahwa model siklus hidup kaskade telah diperkenalkan ke dalam pengembangan perangkat lunak standar. Pada saat yang sama, ini juga memungkinkan untuk mengimplementasikan proses pengembangan berulang karena pentahapan desain CTS dan perangkat lunak yang disediakan untuk mereka.

Untuk proyek perangkat lunak yang sangat besar (lebih dari 100 pengembang), teknologi pengembangan merupakan faktor kunci yang tidak hanya mempengaruhi kualitas perangkat lunak, tetapi juga kemungkinan untuk membuatnya.

Teknologi pengembangan perangkat lunak "berat dan ringan" . Pengembang dari banyak jenis perangkat lunak menganggap model siklus hidup air terjun terlalu diatur, terlalu didokumentasikan dan berat, dan karena itu tidak rasional. Ada arah "Teknologi cepat" (teknologi ringan) pengembangan perangkat lunak (Pengembangan Perangkat Lunak Agile), yang memberikan pembenaran ideologis untuk pandangan ini. Teknologi ini didasarkan pada empat ide:

1. interaksi interaktif individu lebih penting daripada prosedur dan alat formal,

2. perangkat lunak yang berfungsi lebih penting daripada ketersediaan dokumentasi untuk itu,

3. kerjasama dengan pelanggan lebih penting daripada perjanjian formal dengan dia,

4. respon cepat terhadap perubahan eksternal lebih penting daripada kepatuhan yang ketat terhadap rencana.

Kebenaran prinsip-prinsip ini, kecuali yang ketiga, sampai batas tertentu (pengembangan perangkat lunak dilakukan oleh sejumlah kecil programmer yang memenuhi syarat - "penggemar" yang tidak memerlukan kontrol dan motivasi tambahan) untuk pengembangan perangkat lunak sulit untuk diperdebatkan. Namun, teknologi Agile dan ini diakui oleh ideolognya berlaku untuk proyek perangkat lunak dari kelas dan skala tertentu, serta model siklus hidup spiral secara umum, yaitu di mana kesalahan perangkat lunak menyebabkan ketidaknyamanan atau hilangnya dana yang dapat dipulihkan dan di mana perangkat lunak persyaratan terus berubah, karena mereka didefinisikan dengan buruk sebelumnya, dan adaptasi cepat terhadap perubahan ini diperlukan.

Teknologi Cepat - upaya untuk mencapai kompromi antara disiplin pengembangan yang ketat dan ketiadaan sama sekali atas nama pengurangan aliran dokumen yang menyertai pengembangan Teknologi cepat tidak dapat memastikan keandalan yang tinggi dari produk perangkat lunak justru karena minimalisasi dokumen yang secara hukum menegaskan tanggung jawab pengembang .

Contoh teknologi Agile adalah Extreme Programming (XP). Iterasi di XP sangat singkat dan terdiri dari empat operasi: pengkodean, pengujian, mendengarkan pelanggan, merancang. Prinsip-prinsip XP - minimalis, kesederhanaan, partisipasi pelanggan, waktu siklus pendek, interaksi yang erat antara pengembang - mereka harus duduk di ruangan yang sama, rapat operasional harian bersama dengan pelanggan tampaknya masuk akal dan telah lama digunakan tidak hanya dalam teknologi cepat, tetapi di XP mereka dibawa ke nilai-nilai ekstrim.

Analisis terhadap banyak proyek perangkat lunak telah menunjukkan bahwa teknologi ringan yang mengajarkan prinsip-prinsip pengorganisasian mandiri, menekankan penggunaan kemampuan individu pengembang, iterasi pengembangan singkat dalam model spiral, XP, SCRUM adalah umum dan sering juga mengarah pada kesuksesan, membuat sebagian besar fitur bekerja dalam tim kecil.

Jika perangkat lunak yang bekerja secara tidak benar mengarah pada ancaman terhadap kehidupan manusia atau kerugian materi yang besar, teknologi "berat" yang diformalkan secara teratur, dipikirkan sepenuhnya dan dapat diprediksi harus digunakan untuk memastikan keandalan produk perangkat lunak bahkan dalam kasus pengembang berketerampilan menengah. Dengan peningkatan skala proyek perangkat lunak, peningkatan jumlah peserta di dalamnya, kebutuhan akan teknologi pengembangan yang kaku dan formal yang memperbaiki tanggung jawab setiap peserta pengembangan yang membentuk siklus hidup perangkat lunak kaskade meningkat . Bukan tanpa alasan bahwa model siklus hidup air terjun telah diperkenalkan ke dalam standar pengembangan perangkat lunak.

Dalam tim pengembangan besar, masalah manajemen mengemuka.

Untuk proyek perangkat lunak yang sangat besar, masalah pengembangan terkoordinasi yang teratur: penataan, pengintegrasian, memastikan bahwa program berinteraksi dengan benar, pengorganisasian implementasi yang benar dan terkoordinasi dari perubahan yang tak terhindarkan adalah kuncinya. dan mempengaruhi kemungkinan penciptaan mereka.

Dalam proyek perangkat lunak kecil, penyempurnaan algoritmik, pengaruh individu berbakat individu memainkan peran yang menentukan, sedangkan dalam proyek besar faktor-faktor ini diratakan dan tidak memiliki pengaruh yang menentukan pada proses pengembangan.

Pengembang perangkat lunak yang memiliki kemampuan rata-rata, dan mereka mayoritas, dan yang memelihara disiplin teknologi dalam teknologi yang tepat, harus mengembangkan perangkat lunak dengan kualitas yang dibutuhkan. "Jaga ketertiban dan dia akan menjagamu."

Model Waterfall Analisis kebutuhan Desain Implementasi Pengujian Integrasi Draf spesifikasi produk Draf arsitektur produk Pengembangan kode sumber Mengintegrasikan bagian kode sumber Pengujian dan pemecahan masalah

Model Kasus Penggunaan Proses Pengembangan Perangkat Lunak Terpadu (USDP) menjelaskan kasus-kasus di mana aplikasi akan digunakan. Model analitik menggambarkan kelas dasar untuk aplikasi. Model desain menggambarkan koneksi dan hubungan antara kelas dan objek khusus.Model penyebaran menggambarkan distribusi perangkat lunak di seluruh komputer. Model implementasi menggambarkan organisasi internal dari kode program. Model pengujian terdiri dari komponen pengujian, prosedur pengujian, dan berbagai pilihan pengujian

Komponen arsitektur produk perangkat lunak yang khas dan persyaratan perangkat lunak yang khas Organisasi program Kelas sistem utama Organisasi data Aturan bisnis Antarmuka pengguna Manajemen sumber daya Keamanan Kinerja Skalabilitas Interaksi dengan sistem lain (integrasi) Internasionalisasi, pelokalan Data input-output Penanganan kesalahan

Komponen Arsitektur Produk Perangkat Lunak Khas dan Persyaratan Perangkat Lunak Khas Toleransi kesalahan adalah seperangkat properti sistem yang meningkatkan keandalan sistem dengan mendeteksi kesalahan, memulihkan, dan mengisolasi konsekuensi buruk bagi sistem. Saat merancang sistem nyata apa pun untuk memastikan toleransi kesalahan, perlu untuk mengantisipasi semua kemungkinan situasi yang dapat menyebabkan kegagalan sistem dan mengembangkan mekanisme untuk menangani kegagalan. Keandalan adalah kemampuan suatu sistem untuk menahan berbagai kegagalan dan kegagalan. Kegagalan adalah transisi sistem sebagai akibat dari kesalahan ke keadaan yang sama sekali tidak dapat dioperasikan. Kegagalan adalah kesalahan dalam pengoperasian sistem yang tidak menyebabkan kegagalan sistem. Semakin sedikit kegagalan dan kegagalan untuk jangka waktu tertentu, sistem dianggap lebih andal.

Komponen khas arsitektur produk perangkat lunak dan persyaratan perangkat lunak khas Kemungkinan penerapan arsitektur yang dikembangkan. Kemungkinan mengimplementasikan arsitektur yang dikembangkan. fungsionalitas yang berlebihan. fungsionalitas yang berlebihan. Memutuskan pembelian komponen perangkat lunak yang sudah jadi. Memutuskan pembelian komponen perangkat lunak yang sudah jadi. Ubah strategi. Ubah strategi.

Apakah organisasi umum program dijelaskan dengan jelas; apakah spesifikasi mencakup gambaran umum arsitektur dan alasannya. Apakah organisasi umum program dijelaskan dengan jelas; apakah spesifikasi mencakup gambaran umum arsitektur dan alasannya. Apakah komponen utama program didefinisikan secara memadai, bidang tanggung jawab mereka dan interaksi dengan komponen lain. Apakah komponen utama program didefinisikan secara memadai, bidang tanggung jawab mereka dan interaksi dengan komponen lain. Apakah semua fungsi yang ditentukan dalam spesifikasi persyaratan diimplementasikan oleh sejumlah komponen sistem yang wajar. Apakah semua fungsi yang ditentukan dalam spesifikasi persyaratan diimplementasikan oleh sejumlah komponen sistem yang wajar. Apakah kelas yang paling penting dijelaskan dan dibenarkan. Apakah kelas yang paling penting dijelaskan dan dibenarkan. Apakah deskripsi organisasi database diberikan. Apakah deskripsi organisasi database diberikan. Apakah semua aturan bisnis sudah ditentukan? Apakah semua aturan bisnis sudah ditentukan? Apakah dampaknya terhadap sistem dijelaskan? Apakah dampaknya terhadap sistem dijelaskan? Daftar pertanyaan yang memungkinkan Anda membuat kesimpulan tentang kualitas arsitektur:

Daftar pertanyaan yang memungkinkan Anda membuat kesimpulan tentang kualitas arsitektur: Apakah strategi desain antarmuka pengguna dijelaskan. Apakah strategi desain antarmuka pengguna dijelaskan. Apakah antarmuka pengguna dibuat modular sehingga perubahannya tidak mempengaruhi sistem lainnya. Apakah antarmuka pengguna dibuat modular sehingga perubahannya tidak mempengaruhi sistem lainnya. Apakah deskripsi strategi I/O telah disediakan. Apakah deskripsi strategi I/O telah disediakan. Apakah analisis kinerja sistem yang akan diimplementasikan menggunakan arsitektur ini telah dilakukan. Apakah analisis kinerja sistem yang akan diimplementasikan menggunakan arsitektur ini telah dilakukan. Apakah analisis keandalan sistem yang dirancang telah dilakukan? Apakah analisis keandalan sistem yang dirancang telah dilakukan? Apakah analisis skalabilitas dan ekstensibilitas sistem telah dilakukan? Apakah analisis skalabilitas dan ekstensibilitas sistem telah dilakukan?

Kode refactoring perangkat lunak diulang; implementasi metode terlalu besar; terlalu banyak loop bersarang, atau loop itu sendiri sangat besar; kelas memiliki konektivitas yang buruk (properti dan metode kelas harus menggambarkan hanya 1 objek); antarmuka kelas tidak membentuk abstraksi yang konsisten; metode ini membutuhkan terlalu banyak parameter. Anda harus mencoba menjaga jumlah parameter seminimal mungkin; bagian individu dari kelas berubah secara independen dari bagian lain dari kelas; Refactoring melibatkan mengadaptasi perangkat lunak ke yang baru perangkat keras dan untuk sistem operasi baru, alat pengembangan baru, persyaratan baru, serta arsitektur dan fungsionalitas perangkat lunak. Ini adalah perubahan dalam struktur internal perangkat lunak tanpa mengubah perilaku eksternalnya, yang dirancang untuk memastikan modifikasi perangkat lunak. Alasan yang masuk akal untuk melakukan refactor:

Refactoring perangkat lunak saat mengubah program membutuhkan perubahan paralel dari beberapa kelas. Jika situasi seperti itu muncul, perlu untuk mengatur kembali kelas-kelas untuk meminimalkan kemungkinan perubahan di masa depan; harus mengubah beberapa hierarki pewarisan secara paralel; Anda harus mengubah beberapa blok kasus. Hal ini diperlukan untuk memodifikasi program sedemikian rupa untuk membuat implementasi blok kasus, dan menyebutnya beberapa kali dalam program; anggota data terkait yang digunakan bersama tidak diatur ke dalam kelas. Jika Anda berulang kali menggunakan kumpulan elemen data yang sama, maka disarankan untuk mempertimbangkan menggabungkan data ini dan menempatkan operasi yang dilakukan pada mereka di kelas terpisah;

Metode refactoring perangkat lunak menggunakan lebih banyak elemen dari kelas lain daripada miliknya sendiri. Ini berarti bahwa metode tersebut perlu dipindahkan ke kelas lain dan dipanggil dari kelas yang lama; tipe data dasar kelebihan beban. Untuk menggambarkan esensi dari dunia nyata, lebih baik menggunakan kelas daripada membebani semua tipe data yang ada; kelas memiliki fungsionalitas yang terlalu terbatas. Lebih baik untuk menyingkirkan kelas ini dengan mentransfer fungsinya ke kelas lain; data "nyasar" dilewatkan di sepanjang rantai metode. Data yang dilewatkan ke suatu metode hanya untuk diteruskan ke metode lain disebut stray data. Ketika situasi seperti itu muncul, cobalah untuk mengubah arsitektur kelas dan metode untuk menghilangkannya.

Memfaktorkan ulang objek media tidak menghasilkan apa-apa. Jika peran kelas adalah untuk mengalihkan panggilan metode ke kelas lain, maka yang terbaik adalah menghilangkan proxy itu dan melakukan panggilan ke kelas lain secara langsung; satu kelas tahu terlalu banyak tentang kelas lain. Dalam situasi ini, enkapsulasi perlu dibuat lebih ketat untuk memastikan bahwa ahli waris memiliki pengetahuan minimal tentang orang tuanya; metode ini memiliki nama yang tidak menguntungkan; anggota data bersifat publik. Ini mengaburkan batas antara antarmuka dan implementasi, tak terhindarkan merusak enkapsulasi, dan membatasi fleksibilitas program; tempatkan komentar di kode sumber;

Subkelas refactoring perangkat lunak hanya menggunakan sebagian kecil dari metode pendahulunya. Situasi ini terjadi ketika kelas baru dibuat hanya untuk mewarisi beberapa metode dari kelas dasar, dan bukan untuk menggambarkan entitas baru. Untuk menghindari hal ini, perlu untuk mengubah kelas dasar sedemikian rupa sehingga memberikan akses ke kelas baru hanya untuk metode yang dibutuhkan; kode berisi variabel global. Hanya variabel yang benar-benar digunakan oleh keseluruhan program yang harus bersifat global. Semua variabel lain harus lokal atau harus menjadi properti dari beberapa objek; program berisi kode yang suatu saat mungkin dibutuhkan. Saat mengembangkan sistem, disarankan untuk menyediakan tempat di mana kode sumber dapat ditambahkan di masa mendatang.

1. Tujuan teknologi pemrograman. Sejarah perkembangan teknologi pemrograman. Jenis proyek perangkat lunak. Komponen teknologi pemrograman. Proyek, produk, proses, dan orang

2. Siklus hidup program. Sifat siklus perkembangan. Konsep dasar teknologi pemrograman. Proses dan model. Fase dan belokan. Tonggak sejarah dan artefak. Pemangku kepentingan dan karyawan.

3. Identifikasi dan analisis kebutuhan. Persyaratan Perangkat Lunak. Skema Pengembangan Persyaratan. Manajemen persyaratan.

4. Desain arsitektural dan detail. Implementasi dan pengkodean. Pengujian dan Verifikasi. Proses kontrol kualitas. Metode kotak putih dan kotak hitam. Inspeksi dan ulasan. Tujuan pengujian. Verifikasi, validasi dan pengujian sistem. Pemeliharaan dan pengembangan berkelanjutan.

5. Model proses pengembangan. Model air terjun dan konveyor. Model spiral dan inkremental. Model proses pengembangan yang fleksibel.

6. Merancang model proses. Identifikasi kebutuhan proses. Fase, tonggak, dan artefak yang digunakan. Pilihan arsitektur proses. Prosedur untuk melakukan proyek tipikal. prosedur terdokumentasi.

7. Model tim pengembangan. Sifat kolektif pembangunan. Ukuran tim yang optimal. Subordinasi peserta proyek. Pengembangan tim dan pengembangan staf. Spesialisasi, kerjasama dan interaksi.

8. Model tim pengembangan. Model tim hierarkis. Metode tim bedah. Model tim yang setara.

9. Sifat pemrograman. Ilmu pemrograman. Seni pemrograman. Kerajinan pemrograman. paradigma pemrograman. Pemrograman terstruktur. Pemrograman logika. Pemrograman berorientasi objek.

10. Arsitektur perangkat lunak. Pengaturan acara. arsitektur klien/server. Jasa. arsitektur tiga lapis. Desain program. Desain konsep. Desain logika. Desain yang rinci.

1. Pendekatan Novikov untuk pengembangan perangkat lunak” http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Pemrograman ekstrim. - St. Petersburg: Peter, 2002.

3. Teknologi pengembangan perangkat lunak. - Sankt Peterburg. : Petrus, 2004.

4. Brooks Jr. sistem perangkat lunak dirancang dan dibuat. Moskow: Nauka, 1975; edisi terjemahan baru: Mythical man-month. Sankt Peterburg: SIMBOL+, 1999.

5. Algoritma + struktur data = program. M., Mir, 1978.

6. Pemrograman sistematis. Pengantar. M.: Mir, 1977.

7. Pemrograman terstruktur. M.: Mir, 1975.

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

9. Teknologi pengembangan perangkat lunak. - St. Petersburg: Peter, 2002.

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

11. Rambo J. Proses pengembangan perangkat lunak terpadu. Sankt Peterburg: Peter, 2002.

Teori Ekonomi untuk Manajer

Teori ekonomi mikro dasar. Contoh aplikasi dalam analisis proses ekonomi. Teori ekonomi makro dasar. Contoh aplikasi dalam analisis proses ekonomi. Prinsip dan metode mengelola proses ekonomi. Alat untuk menilai tingkat perkembangan proses ekonomi Masalah reproduksi yang diperluas. Faktor pertumbuhan ekonomi ekonomi Rusia. Kriteria dan indikator pembangunan berkelanjutan. Menghaluskan fluktuasi siklik. Peran multiplier dan accelerator dalam menilai laju pembangunan ekonomi. Fungsi produksi dalam perekonomian. Contoh aplikasi dalam analisis proses ekonomi. Laba. Perhitungan indikator yang mempengaruhi keuntungan, representasi grafis dari titik impas. Metodologi implementasi kebijakan investasi.

Kursus teori ekonomi: buku teks untuk universitas / Ed. . -Kirov: "ACA", 2004. Kolemaev - pemodelan matematika. Pemodelan proses dan sistem ekonomi makro: buku teks. M.: UNITY-DANA, 2005. Sibernetika Bazhin. Kharkiv: Konsul, 2004. Lokakarya Leushin tentang metode pemodelan matematika: buku teks. Negara Bagian Nizhny Novgorod teknologi univ - N. Novorod, 2007. Politisi tentang ekonomi: Ceramah peraih Nobel di bidang ekonomi. Moskow: Ekonomi dan Hukum Modern, 2005. Cheremnykh. Tingkat Mahir: Textbook.-M.:INFRA-M, 2008. Evolusi lembaga ekonomi mini. Institut Ekonomi Cabang Ural dari Akademi Ilmu Pengetahuan Rusia, - M.: Nauka, 2007.

Teknologi untuk pengembangan dan adopsi keputusan manajerial [N]

Pengambilan keputusan adalah dasar dari aktivitas seorang manajer. Pengantar teori keputusan. Konsep dasar teori keputusan. Model manajemen bisnis dan dampaknya terhadap pengambilan keputusan. Berbagai cara klasifikasi solusi. Klasifikasi: menurut tingkat formalitas, menurut tingkat rutinitas, menurut frekuensi, menurut urgensi, menurut tingkat pencapaian tujuan, menurut metode pemilihan alternatif. Metode pengambilan keputusan dasar. Metode pengambilan keputusan secara sukarela. Tujuan pengambilan keputusan. Saatnya mencari solusi. Kesalahan dasar Metode matematis dalam pengambilan keputusan. Aspek matematis dari teori pengambilan keputusan. Operasi pencarian. Pendekatan matematis untuk pengambilan keputusan. Pohon keputusan. Model pengembangan dan pengambilan keputusan. Teori permainan. Metode matematis untuk pengambilan keputusan. Aspek matematis dari teori pengambilan keputusan. Model teori antrian. Model manajemen persediaan. Model pemrograman linier. tugas transportasi. Pemodelan simulasi. Analisis jaringan. Analisa ekonomi. Keterbatasan model rasional. Fitur pengembangan dan pengambilan keputusan dalam kelompok. Suatu metode untuk menentukan kohesi kelompok berdasarkan derajat keterhubungan himpunan. Metode membuat keputusan kolektif. metode konsensus. metode pemungutan suara. Metode kreatif dalam pengambilan keputusan. Brainstorming. Konferensi ide. Dewan Kapal. Metode Topi Mental oleh de Bono. Teori pemecahan masalah inventif (TRIZ). Solusi akhir yang ideal. Contoh masalah dan solusinya menggunakan TRIZ. Penerapan metode TRIZ dalam membuat keputusan yang unik dan kreatif. Metode untuk mengembangkan ide-ide solusi dan menyesuaikannya dengan situasi. Model pohon sasaran. Strategi koordinasi kepentingan. Pembentukan keputusan tentang koordinasi kepentingan. Metode untuk menentukan kepentingan pihak lawan. Sistem pendukung keputusan (sistem pakar). Sejarah penciptaan sistem pengambilan keputusan. Klasifikasi sistem pengambilan keputusan. Struktur khas dari sistem pakar. Cara representasi pengetahuan. Metode inferensi logis. Penerapan sistem pakar dalam praktek.

I. Teori pengambilan keputusan: buku teks. - M.: Ujian, 2006. - 573 hal. I. Pengambilan keputusan. Teori dan metode pengembangan keputusan manajemen. Tutorial. - M.: Maret, 2005. - 496 hal Pengembangan keputusan manajemen - M.: Delo Publishing House, 2004 - 392 hal. G. Penilaian ahli dan pengambilan keputusan - M.: Patent, 1996. - 271 hal. Taha // Pengantar Riset Operasi = Riset Operasi: Sebuah Pengantar. - edisi ke-7. - M.: "Williams", 2007. - S. 549-594. G. Theil. Prakiraan ekonomi dan pengambilan keputusan. M.: Kemajuan, 1970. K. D. Lewis. Metode untuk meramalkan indikator ekonomi. M.: "Keuangan dan statistik" 1986. G. S. Kildishev, A. A. Frenkel. Analisis dan peramalan deret waktu. M.: "Statistik" 1973. O. Kim, C. W. Muller, W. R. Klekka dkk. Analisis faktor, diskriminan, dan klaster. M.: "Keuangan dan statistik" 1989. Manajer yang efektif. Buku 3. Pengambilan keputusan. - MIM LINK, 1999 Turevsky dan manajemen perusahaan transportasi motor. - M.: lulusan sekolah, 2005. , ; ed. . Analisis sistem dalam manajemen: tutorial. - M .: Keuangan dan statistik, 2006. , Tinkov: buku teks. – M.: KNORUS, 2006.

Pemodelan proses bisnis dalam sistem manajemen terintegrasi

Apa saja prinsip-prinsip proses bisnis? Apa masalah dari deskripsi holistik proses bisnis. Apa itu sistem, properti apa yang dimilikinya? Peran analisis sistem dalam pemodelan proses bisnis? Proses sebagai objek kontrol. Lingkungan proses. Elemen dasar dari proses bisnis. Keuntungan dan kerugian dari manajemen fungsional dan proses. siklus manajemen PDCA. Tahapan siklus manajemen proses. Siklus PDCA dan implementasi persyaratan ISO 9001:2008. Metodologi SADT (Analisis Terstruktur dan Teknik Desain - metode analisis dan desain struktural). Esensi. Ketentuan dasar. Bagaimana model fungsional aktivitas disajikan dalam metodologi IDEF0? Apa arti karya dalam diagram model fungsional, bagaimana mereka ditampilkan menurut metodologi IDEF0? Untuk apa panah dalam diagram model fungsional, untuk apa jenis dan tipenya? metodologi DFD. Esensi. Komponen dasar grafik DFD. Apa saja fitur diagram DFD, apa yang dijelaskan di dalamnya? Apa saja fitur objek diagram DFD? Apa yang dilambangkan oleh panah pada diagram DFD? metodologi IDEF3. Esensi. Sarana dokumentasi dan pemodelan. Apa saja fitur diagram IDEF3, apa yang mereka gambarkan? Apa saja fitur objek diagram IDEF3? Dan penembaknya? Klasifikasi proses. Proses bisnis yang khas. Rekayasa ulang dan teknologinya. Kapan waktu yang tepat untuk menggunakan rekayasa ulang dalam manajemen perusahaan? Pemantauan dan pengukuran proses. Indikator proses organisasi. Evaluasi numerik dan penilaian proses.

"Memodelkan proses bisnis dengan AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Membuat sistem informasi dengan AllFusion Modeling Suite" ed. "Dialogue-MEPhI" 2003 "Praktek pemodelan fungsional dengan AllFusion Process Modeler 4.1. (BPwin) Di mana? Mengapa? Bagaimana?" ed. "Dialogue-MEPhI" Pemodelan Dubeikovsky 2004 dengan AllFusion Process Modeler (BPwin). ed. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Metodologi analisis struktural dan desain SADT" 1993 karya klasik tentang metodologi SADT. Analisis Cheremnykh sistem: IDEF-teknologi, Pemodelan dan analisis sistem. teknologi IDEF. Bengkel. M.: Keuangan dan statistik, 2001. , “Model bisnis struktural: DFD-technologies” http://www. /Level4.asp? ItemId=5810 "Teori dan praktik reorganisasi proses bisnis"2003/ P50.1.. Metodologi pemodelan fungsional. Moskow: Gosstandart Rusia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Pemodelan proses bisnis melalui BPwin http://www. /department/se/devis/7/ IDEF0 dalam manajemen pemodelan proses bisnis http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Evaluasi efektivitas produk perangkat lunak

1. arsitektur TI

2. Domain proses manajemen.

3. Daftar proses domain Perencanaan dan Organisasi

4. Daftar proses domain Akuisisi dan Implementasi

5. Daftar proses dalam domain Operasi dan Pemeliharaan

6. Daftar proses dalam domain Monitoring dan Evaluasi

7. Karakterisasi tingkat model kematangan proses

9. KPI dan KGI hubungan dan tujuannya

1. 10. Kontrol TI umum dan kontrol aplikasi. Area tanggung jawab dan tanggung jawab bisnis dan TI.

Cobit 4.1 edisi Rusia.

Regulasi hukum atas pembuatan dan penggunaan kekayaan intelektual

1. Buat daftar hak kekayaan intelektual atas hasil aktivitas intelektual dan ungkapkan isinya.

2. Sebutkan jenis-jenis kontrak untuk pelepasan hak eksklusif. Jelaskan masing-masing kontrak ini tentang pelepasan hak eksklusif.

4. Menjelaskan ketentuan pokok perlindungan hukum Program Komputer sebagai objek hak cipta.

5. Membandingkan ketentuan utama perlindungan hukum Basis Data sebagai objek hak cipta dan sebagai objek hak terkait.

6. Mendeskripsikan syarat-syarat dapat dipatenkannya obyek hak paten: invensi; model yang berguna; sampel industri.

7. Memperluas isi kriteria paten dapat dipatenkan: kebaruan; langkah inventif; penerapan industri.

8. Mendeskripsikan syarat-syarat dan tata cara memperoleh paten atas suatu invensi, model kegunaan atau desain industri, serta syarat-syarat yang menjamin keabsahan paten dan masa berlakunya.

9. Berikan definisi "know-how" dan daftar kondisi di mana perlindungan hukum rahasia produksi muncul dan dilakukan.

10. Sebutkan cara-cara individualisasi yang dilindungi dan berikan ciri-ciri komparatifnya.

1., hukum kekayaan intelektual di Federasi Rusia, buku teks // M, Prospekt, 2007

2., hukum kekayaan intelektual, buku teks // M, RIOR, 2009

Manajemen Proyek dan Pengembangan Perangkat Lunak [R]

Apa itu metodologi, mengapa dibutuhkan. Struktur umum metodologi, elemen utama metodologi. Prinsip-prinsip merancang metodologi sendiri. Contoh berbagai artefak, peran, kompetensi, kondisi batas. Struktur metodologi Cowburn, metrik metodologi. Kriteria proyek Cowburn. Kriteria pemilihan metodologi, matriks Cowburn. Siklus hidup proyek. Model siklus hidup air terjun dan iteratif. Batas penerapan untuk model air terjun dan iteratif. RUP sebagai contoh metodologi iteratif. Konsep dasar RUP, batasan penerapan. Peran manusia dalam pengembangan perangkat lunak. Metodologi tangkas, prinsip dasar metodologi tangkas. Asal usul metodologi tangkas. Scrum sebagai contoh metodologi tangkas. Peran, artefak, aktivitas di Scrum. Batasan penerapan Scrum. Extreme Programming (XP) Ide, nilai, praktik dasar, batas penerapan. Persamaan dan perbedaan antara Scrum dan XP. Pengumpulan dan pengelolaan persyaratan. Praktek dasar, istilah, prinsip. Pendekatan untuk mendokumentasikan proyek dan produk, jenis utama dokumen. Contoh praktik manajemen persyaratan dari metodologi yang dibahas dalam kursus. Perencanaan pengembangan perangkat lunak. Jenis rencana, manajemen risiko, risiko populer. Contoh praktik perencanaan pembangunan dari metodologi yang dibahas dalam kursus. Pengujian dalam pengembangan perangkat lunak. Konsep perakitan (build) suatu produk perangkat lunak. Metode pengujian dasar, istilah. Contoh praktik pengujian dari metodologi yang dibahas dalam kursus. Konsep perakitan (build), cara menyimpan kode, alat. Dua prinsip untuk mengatur pekerjaan dengan sistem kontrol versi. Fitur proses rilis/tata letak produk untuk kategori produk yang berbeda, contoh praktik. Konsep modern arsitektur perangkat lunak, arsitektur bertingkat, kriteria arsitektur. Daftar keputusan yang diperlukan saat merancang perangkat lunak, pendekatan untuk memilih sistem penyimpanan data.

Kent Beck - Pemrograman Ekstrim Frederic Brooks - The Mythical Man-Bulan atau Bagaimana Mereka Diciptakan sistem perangkat lunak. Tom de Marco - Batas waktu. Sebuah novel tentang manajemen proyek. Tom de Marco, Timothy Lister - Waltzing with Bears. Tom de Marco, Timothy Lister - Faktor manusia_ proyek dan tim yang sukses. Alistair Cowburn - Setiap proyek memiliki metodologinya sendiri. Alistair Cowburn - Orang-orang sebagai non-linear dan komponen terpenting dalam pengembangan perangkat lunak. Andriy Orlov - Catatan seorang automator. Pengakuan profesional. Philip Krachten - Pengantar Proses Terpadu Rasional. Henrik Kniberg - Scrum dan XP: catatan dari garis depan. Presentasi kuliah kursus

Ilmu komputer, sibernetika, dan pemrograman

Iterasi N USDP Unified Software Development Process Model use case menggambarkan kasus-kasus dimana aplikasi akan digunakan. Model analitik menggambarkan kelas dasar untuk aplikasi. Model desain menggambarkan koneksi dan hubungan antara kelas dan objek khusus.Model penyebaran menggambarkan distribusi perangkat lunak di seluruh komputer.

Pelajaran #20
Prinsip dan pendekatan umum untuk pengembangan perangkat lunak

Model Pengembangan Perangkat Lunak

1. Vodopadnaya
2. Model kaskade
3. Spiral
4. Pemrograman Ekstrim
5. tambahan
6. Metodologi MSF

model air terjun

model spiral

Perkembangan Inkremental

Analisa Kebutuhan

Rancangan

Penerapan

Komponen

pengujian

Integrasi

Pengujian

utuh

Iterasi 1 Iterasi 2 …. Iterasi N

Proses Pengembangan Perangkat Lunak Terpadu (USDP)

1. Model use case menggambarkan kasus-kasus di mana aplikasi akan digunakan.
2. Model analitik menggambarkan kelas dasar untuk aplikasi.
3. Model desain menggambarkan koneksi dan hubungan antara kelas dan objek yang dipilih
4. Model penyebaran menggambarkan distribusi perangkat lunak di seluruh komputer.
5. Model implementasi menggambarkan organisasi internal dari kode program.
6. Model uji terdiri dari komponen uji, prosedur uji, dan kasus uji berbeda.

Metodologi MSF

Komponen arsitektur produk perangkat lunak yang khas dan persyaratan perangkat lunak yang khas

toleransi kesalahanseperangkat properti sistem yang meningkatkan keandalannya dengan mendeteksi kesalahan, memulihkan, dan melokalisasi konsekuensi buruk bagi sistem. Saat merancang sistem nyata apa pun untuk memastikan toleransi kesalahan, perlu untuk mengantisipasi semua kemungkinan situasi yang dapat menyebabkan kegagalan sistem dan mengembangkan mekanisme untuk menangani kegagalan.

Keandalan kemampuan sistem untuk menahan berbagai kegagalan dan kegagalan.

Penolakan adalah transisi sistemsebagai akibat dari kesalahan ke keadaan yang benar-benar tidak dapat dioperasikan.

menabrak kesalahan dalam pengoperasian sistem yang tidak menyebabkan kegagalan sistem.

Semakin sedikit kegagalan dan kegagalan untuk jangka waktu tertentu, sistem dianggap lebih andal.

Serta karya-karya lain yang mungkin menarik bagi Anda
57355.		Ragam senyawa organik, klasifikasinya. Zat organik dari alam	48.5KB
	Variasi senyawa organik ditentukan oleh kemampuan unik atom karbon untuk bergabung satu sama lain melalui ikatan sederhana dan ganda untuk membentuk senyawa dengan jumlah atom yang hampir tidak terbatas yang dihubungkan dalam rantai, siklus, sepeda, becak, polisiklus, kerangka, dll.
57359.		Memproses model informasi verbal	291KB
	Konsep dasar: model; model informasi; model informasi verbal; anotasi; abstrak. Sinopsis Sinopsis dari lat. Buat garis besar untuk 2. Simpan dokumen di folder Anda sendiri dengan nama Abstrak.
57361.		Nomor dan nomor 3. Memasangkan nomor di pinggir 3. Nomor tertulis 3. Memasangkan barang lama	35.5KB
	Jumlah semua makhluk Siapa yang harus menjadi yang pertama Siapa yang harus menjadi yang terakhir Siapa yang harus di bawah nomor 1 Siapa yang harus di bawah nomor 2 Siapa tupai susid tangan kanan Siapa jerapah kidal susid

Ada model pengembangan perangkat lunak. Dan ada metodologi. Ada banyak informasi yang saling bertentangan di Internet tentang apa itu dan bagaimana membedakannya. Mungkin sulit bagi pemula untuk memahami hal ini. Pada artikel ini, kita akan menandai i.

Tahap siklus hidup perangkat lunak

Setiap perangkat lunak memiliki siklus hidup - tahapan yang dilaluinya dari awal pembuatan hingga akhir pengembangan dan implementasi. Paling sering itu adalah persiapan, desain, kreasi dan dukungan. Tahapan dapat disebut berbeda dan dapat dibagi menjadi tahap yang lebih kecil.

Pertimbangkan tahapan ini pada contoh siklus hidup toko online.

Pelatihan. Ivan memutuskan untuk meluncurkan toko buku online dan mulai menganalisis situs serupa apa yang sudah ada di jaringan. Informasi yang dikumpulkan tentang lalu lintas, fungsionalitasnya.

Rancangan. Ivan memilih kontraktor dan berdiskusi dengan spesialisnya tentang arsitektur dan desain toko online masa depan.

Penciptaan. Ivan menandatangani perjanjian dengan para pengembang. Mereka mulai menulis kode, menggambar desain, menulis dokumentasi.

Mendukung. Ivan menandatangani sertifikat penerimaan, dan kontraktor menempatkan toko online di server "pertempuran". Pengguna mulai mengunjunginya dan melaporkan bug untuk mendukung, dan programmer dengan cepat memperbaiki semuanya.

Model Pengembangan perangkat lunak menjelaskan tahapan siklus hidup perangkat lunak yang dilaluinya dan apa yang terjadi di masing-masing tahapan tersebut.

TETAPI metodologi mencakup seperangkat metode manajemen pengembangan: ini adalah aturan, teknik, dan prinsip yang membuatnya lebih efisien.

Model pengembangan perangkat lunak dasar

• Kode dan perbaiki - model untuk pengkodean dan perbaikan kesalahan;
• Model Air Terjun - model kaskade, atau "air terjun";
• Model-V - Model berbentuk V, pengembangan yang digerakkan oleh tes;
• Model Inkremental - model inkremental;
• Model Iteratif - model iteratif (atau iteratif);
• Model Spiral - model spiral;
• Model kekacauan - model kekacauan;
• Model Prototipe - model prototipe.

Dari model-model ini, lima yang utama adalah yang paling populer: kaskade, berbentuk V, inkremental, iteratif, dan spiral. Mari kita menganalisis mereka secara lebih rinci.

Air terjun (model kaskade, atau "air terjun")

Dalam model ini, pengembangan dilakukan secara bertahap: setiap tahap berikutnya dimulai hanya setelah yang sebelumnya berakhir. Selesai benar, air terjun akan menjadi model tercepat dan paling sederhana. Ini telah digunakan selama hampir setengah abad, sejak tahun 1970-an.

Manfaat air terjun

• Perkembangannya mudah dikendalikan. Pelanggan selalu tahu apa yang dilakukan programmer sekarang, dapat mengatur waktu dan biaya.
• Biaya proyek ditentukan pada tahap awal. Semua langkah sudah direncanakan pada tahap menyetujui kontrak, perangkat lunak ditulis terus menerus "dari dan ke".
• Tidak perlu menyewa penguji dengan latar belakang teknis yang serius. Penguji akan dapat mengandalkan dokumentasi teknis terperinci.

Kekurangan model air terjun

• Pengujian dimulai pada tahap terakhir pengembangan. Jika kesalahan dibuat dalam persyaratan untuk produk, maka akan mahal untuk memperbaikinya. Penguji akan menemukannya ketika pengembang telah menulis kode, dan penulis teknis - dokumentasi.
• Pelanggan melihat produk jadi pada akhir pengembangan dan baru kemudian dapat memberikan masukan. Sangat mungkin bahwa hasilnya tidak akan cocok untuknya.
• Pengembang menulis banyak dokumentasi teknis, yang menunda pekerjaan. Semakin luas dokumentasi proyek, semakin banyak perubahan yang perlu dilakukan dan semakin lama harus disetujui.

"Air Terjun" cocok untuk mengembangkan proyek di industri medis dan luar angkasa, di mana database dokumen yang luas telah terbentuk(SNIP dan spesifikasi), atas dasar itu Anda dapat menulis persyaratan untuk perangkat lunak baru.

Saat bekerja dengan model air terjun, tugas utamanya adalah menulis persyaratan pengembangan terperinci. Selama fase pengujian, seharusnya tidak menjadi jelas bahwa mereka memiliki bug yang memengaruhi keseluruhan produk.

Model berbentuk V (pengembangan yang digerakkan oleh tes)

Ini adalah model air terjun yang ditingkatkan di mana pelanggan dan tim pemrograman secara bersamaan menuliskan persyaratan untuk sistem dan menjelaskan bagaimana hal itu akan diuji pada setiap tahap. Sejarah model ini dimulai pada 1980-an.

Manfaat Model-V

Jumlah kesalahan dalam arsitektur perangkat lunak dikurangi seminimal mungkin.

Kekurangan model berbentuk V

Jika terjadi kesalahan dalam desain arsitektur, maka akan mahal untuk kembali dan memperbaikinya, seperti pada "air terjun".

V-model cocok untuk proyek yang keandalannya penting dan biaya kesalahannya sangat tinggi. Misalnya, ketika mengembangkan airbag untuk mobil atau sistem pemantauan untuk pasien di klinik.

Model Inkremental (model inkremental)

Model perkembangan sebagian (increment in translation dari bahasa Inggris - increment) berakar pada tahun 1930-an. Pertimbangkan pada contoh membuat jejaring sosial.

1. Pelanggan memutuskan bahwa dia ingin meluncurkan jejaring sosial dan menulis kerangka acuan yang terperinci. Pemrogram mengusulkan untuk mengimplementasikan fungsi utama - halaman dengan informasi pribadi dan mengobrol. Dan kemudian uji pada pengguna, "lepas landas atau tidak."
2. Tim pengembangan menunjukkan produk kepada pelanggan dan melepaskannya ke pasar. Jika pelanggan dan pengguna jaringan sosial Saya menyukainya, mengerjakannya terus, tetapi sebagian.
3. Programmer secara bersamaan membuat fungsionalitas untuk mengunggah foto, bertukar dokumen, mendengarkan musik, dan tindakan lain yang disepakati dengan pelanggan. Kenaikan demi kenaikan, mereka meningkatkan produk, mendekati yang dijelaskan dalam kerangka acuan.

Keuntungan dari model inkremental

• Tidak perlu menginvestasikan banyak uang pada tahap awal. Pelanggan membayar untuk pembuatan fungsi utama, menerima produk, "meluncurkannya" ke pasar - dan, berdasarkan hasil umpan balik, memutuskan apakah akan melanjutkan pengembangan.
• Anda dapat dengan cepat mendapatkan umpan balik dari pengguna dan dengan cepat memperbarui kerangka acuan. Ini mengurangi risiko menciptakan produk yang tidak dibutuhkan siapa pun.
• Kesalahan lebih murah. Jika kesalahan dibuat selama pengembangan arsitektur, maka memperbaikinya tidak akan memakan biaya sebanyak pada model "air terjun" atau berbentuk V.

Kekurangan dari model inkremental

• Setiap tim pemrograman mengembangkan fungsinya sendiri dan dapat mengimplementasikan antarmuka produk dengan caranya sendiri. Untuk mencegah hal ini terjadi, penting untuk menjelaskan pada tahap pembahasan kerangka acuan seperti apa nantinya sehingga semua peserta proyek memiliki pemahaman yang sama.
• Pengembang akan menunda finalisasi fungsi utama dan "melihat hal-hal kecil." Untuk mencegah hal ini terjadi, manajer proyek harus mengontrol apa yang dilakukan setiap tim.

Model tambahan cocok untuk proyek di mana kerangka acuan yang tepat sudah ditulis di awal, dan produk harus segera memasuki pasar.

Model Iteratif (model berulang)

Ini adalah model di mana pelanggan tidak berkewajiban untuk memahami produk apa yang ingin dia terima sebagai hasilnya, dan mungkin tidak segera meresepkan tugas teknis yang terperinci.

Mari kita lihat contoh pembuatan messenger, cara kerja model ini.

1. Pelanggan memutuskan bahwa dia ingin membuat utusan. Pengembang telah membuat aplikasi tempat Anda dapat menambahkan teman dan memulai obrolan untuk dua orang.
2. Utusan itu "diluncurkan" ke toko aplikasi, pengguna mulai mengunduhnya dan menggunakannya secara aktif. Pelanggan menyadari bahwa produk tersebut populer dan memutuskan untuk memperbaikinya.
3. Pemrogram menambahkan kemampuan untuk menonton video, mengunggah foto, merekam pesan audio ke messenger. Mereka secara bertahap meningkatkan fungsionalitas aplikasi, menyesuaikannya dengan kebutuhan pasar.

Manfaat model iteratif

• Rilis cepat dari produk minimum memungkinkan Anda untuk dengan cepat menerima umpan balik dari pelanggan dan pengguna. Ini berarti berfokus pada fungsi perangkat lunak yang paling penting dan meningkatkannya sesuai dengan kebutuhan pasar dan keinginan klien.
• Pengujian pengguna terus menerus memungkinkan Anda untuk dengan cepat mendeteksi dan memperbaiki kesalahan.

Kekurangan model iteratif

• Penggunaan awal database atau server- yang pertama sulit untuk diukur, dan yang terakhir tidak dapat menahan beban. Anda mungkin harus menulis ulang sebagian besar aplikasi.
• Kurangnya anggaran dan tenggat waktu yang tetap. Pelanggan tidak tahu seperti apa tujuan akhir dan kapan pengembangan akan berakhir.

Model iteratif cocok untuk dikerjakan proyek besar dengan persyaratan yang tidak pasti, atau untuk tugas dengan pendekatan inovatif ketika pelanggan tidak yakin dengan hasilnya.

Model Spiral (model spiral)

Dengan menggunakan model ini, pelanggan dan tim pengembangan secara serius menganalisis risiko proyek dan menjalankannya dalam iterasi. Tahap berikutnya dibangun di atas yang sebelumnya, dan pada akhir setiap siklus iterasi, keputusan dibuat apakah akan melanjutkan proyek. Model ini mulai digunakan pada tahun 1988.

Mari kita pertimbangkan bagaimana model ini berfungsi, dengan menggunakan contoh pengembangan sistem "Rumah Pintar".

1. Pelanggan memutuskan bahwa dia ingin membuat sistem seperti itu dan memerintahkan pemrogram untuk menerapkan kontrol ketel dari telepon. Mereka mulai bertindak sesuai dengan model "air terjun": mereka mendengarkan idenya, menganalisis proposal di pasar, mendiskusikan arsitektur sistem dengan pelanggan, memutuskan bagaimana mereka akan menerapkannya, mengembangkan, menguji, dan "diluncurkan" produk akhir.
2. Pelanggan menilai hasil dan risiko: seberapa banyak pengguna membutuhkan versi produk berikutnya - sudah dengan kontrol TV. Menghitung persyaratan, anggaran dan memerintahkan pembangunan. Pemrogram bertindak sesuai dengan model air terjun dan memberi pelanggan produk yang lebih kompleks yang dikembangkan berdasarkan yang pertama.
3. Pelanggan berpikir sudah waktunya untuk membuat fungsionalitas untuk mengontrol lemari es dari telepon. Tetapi, menganalisis risikonya, saya menyadari bahwa sulit untuk mengintegrasikan modul Wi-Fi ke dalam lemari es, dan produsen tidak tertarik untuk bekerja sama dalam masalah ini. Oleh karena itu, risikonya lebih besar daripada potensi manfaatnya. Berdasarkan data yang diterima, pelanggan memutuskan untuk menghentikan pengembangan dan meningkatkan fungsionalitas yang ada agar pada akhirnya memahami bagaimana mengembangkan sistem Smart Home.

Model spiral mirip dengan model inkremental, tetapi lebih banyak waktu dikhususkan untuk penilaian risiko. Dengan setiap putaran baru dari spiral, prosesnya menjadi lebih rumit. Model ini sering digunakan dalam proyek penelitian dan di mana risikonya tinggi.

Manfaat Model Spiral

Banyak perhatian diberikan pada studi risiko.

Kekurangan Model Spiral

• Ada risiko terjebak pada tahap awal- meningkatkan versi pertama produk tanpa henti dan tidak melanjutkan ke yang berikutnya.
• Pengembangannya memakan waktu lama dan mahal.

Berdasarkan model berulang, Agile diciptakan - bukan model atau metodologi, melainkan pendekatan untuk pengembangan.

Apa itu Agile?

Agile ("gesit") diterjemahkan dari bahasa Inggris sebagai "fleksibel". Mencakup praktik, pendekatan, dan metodologi yang membantu menciptakan produk secara lebih efisien:

• pemrograman ekstrim (Extreme Programming, XP);
• pengembangan perangkat lunak ramping (Lean);
• kerangka kerja manajemen proyek scrum;
• pengembangan berbasis fitur (FDD);
• pengembangan melalui pengujian (Pengembangan berbasis pengujian, TDD);
• metodologi "ruang bersih" (Rekayasa Perangkat Lunak Cleanroom);
• metode pengembangan iteratif-incremental (OpenUP);
• metodologi pengembangan Microsoft Kerangka Solusi (MSF);
• metode pengembangan sistem dinamis (DSDM);
• Metode manajemen pengembangan Kanban.

Kami merangkum perbedaan antara Agile dan pendekatan tradisional untuk pengembangan dalam sebuah tabel:

Tidak semua yang ada dalam daftar adalah metodologi. Misalnya, Scrum sering disebut bukan sebagai metodologi, tetapi sebagai kerangka kerja. Apa bedanya? Kerangka kerja adalah metodologi yang lebih matang dengan aturan yang ketat. Di Scrum, semua peran dan proses didefinisikan dengan jelas. Selain Scrum, Kanban juga sering digunakan.

Kanban

Ini adalah salah satu metodologi pengembangan perangkat lunak yang paling populer saat ini. Tim bekerja dengan bantuan papan virtual, yang dibagi menjadi beberapa tahapan proyek. Setiap peserta melihat tugas mana yang sedang berlangsung, yang macet di salah satu tahap, dan mana yang sudah mencapai kolomnya dan membutuhkan perhatian.

Tidak seperti Scrum, di Kanban Anda dapat segera mengambil tugas-tugas mendesak ke dalam pengembangan, tanpa menunggu sprint berikutnya dimulai. Kanban nyaman digunakan tidak hanya di tempat kerja, tetapi juga untuk keperluan pribadi - untuk mendistribusikan rencana Anda sendiri atau tugas keluarga untuk akhir pekan, untuk melacak kemajuan secara visual.

Segera kami akan mengadakan acara tiga hari. Di atasnya, Anda akan belajar bagaimana menggunakan semua keuntungan dari pendekatan ini, mengelola proyek pengembangan dan rilis dengan kompleksitas apa pun. Menunggumu!