Mari kita bahas metode pembuatan perangkat lunak yang ditemukan dalam sekitar 70 tahun keberadaannya. Jumlah mereka tidak sebanyak yang terlihat. Tapi cukup untuk membuat bingung.
Pepatah
Manusia pada dasarnya adaptif. Anda pergi, misalnya, ke dapur, tempat ayam berputar di atas panggangan. Aromanya menyentuh hidung, dan jika Anda lapar, Anda bahkan akan mengeluarkan air liur. Setelah sekitar lima menit Anda berhenti mencium. Satu-satunya hal yang mengingatkan pada makanan adalah sepotong daging yang berputar di balik gelas oven dengan sayap terentang. Baunya masih ada, Anda bisa mengukurnya, tetapi informasi dari reseptor diblokir oleh otak.
Ini terjadi di semua tempat, dan rekayasa perangkat lunak tidak terkecuali. Kita mulai dengan "penemuan luar biasa" bahwa "semangat pencerahan mempersiapkan kita", dengan lancar beralih ke rutinitas, rasa malu-dan-scrum, sprint-shmints, enkapsulasi-polimorfisme-kebangsaan, dan, oh sial, sepotong daging adalah berputar dalam oven, mengancam untuk terbakar sampai jangka waktu tertentu, meskipun stimulasi material secara teratur di atas rata-rata rumah sakit.
Pada 1960-an, seorang pria yang ingin tahu bernama Richard B. Doss menemukan bahwa di Amerika, yang jenuh dengan kecanduan kerja Protestan, 70-80% orang bekerja jauh di bawah kemampuan mereka untuk bekerja. Selain itu, tidak seperti manipulator robotik, pekerja protein dapat dengan cepat memotongnya. Studi diulangi dalam "nol" dan "persepuluhan" dengan hasil yang sama. Situasi seperti itu memengaruhi kesehatan, secara halus, itu tidak masalah.
Tujuan teks ini bukan untuk menghalangi Anda dari produktivitas yang tidak mencukupi atau untuk memberikan nasihat apa pun. Kami hanya akan membahas secara singkat metode pembuatan perangkat lunak yang ditemukan dalam sekitar 70 tahun keberadaannya.
Tiga jalan
Saya tidak akan menarik karetnya, saya akan mulai dengan yang utama. Hanya ada tiga cara untuk mengembangkan perangkat lunak. Ya, tiga itu angka yang bagus, bagus. Jadi:
Metode top-down . Pada awalnya mereka secara global berpikir "apa yang harus dilakukan", lalu "bagaimana melakukannya", dan kemudian mereka melakukannya, jika waktu tersisa.
Cara menanjak . Ini adalah saat mereka pertama kali melakukannya, sedikit demi sedikit, dalam bagian-bagian kecil. Mereka berpikir "apa, ya bagaimana" hanya di bagian ini, tidak peduli dengan global dan abadi.
Cara spiral . Kami mulai berpikir secara global, tetapi ketika alarm berbunyi, kami bangun dan meluncurkan prototipe. Dan beberapa kali, mengumpulkan pengalaman, sampai solusi muncul sesuai dengan kebutuhan.
Pengembangan dari atas ke bawah
Dalam bahasa umum, semua metode top-down disebut "air terjun". Jika Anda telah diberitahu tentang adanya beberapa ajile, maka "kesederhanaan lebih buruk daripada pencurian" seharusnya menimbulkan kecurigaan.
Metode turun ke massa terjadi pada tahun 1960-an, secara organik melengkapi persyaratan program terstruktur untuk mencuci tangan sebelum makan dan menggunakan alat makan dan serbet. Tugas global dibagi menjadi subtugas yang lebih kecil, yang, pada gilirannya, menjadi tugas yang lebih detail, dan seterusnya hingga tingkat blok struktural yang dapat langsung diimplementasikan dalam bahasa pemrograman. Omong-omong, tes untuk blok ini ditulis secara paralel, halo untuk TDD dari tahun 1960-an.
Pepatah Rusia "Ukur tujuh kali - potong sekali" hanyalah tentang metode top-down.
Dalam versi ortodoks dari "air terjun", umpan balik dari pelanggan datang hanya setelah pengiriman selesai. Kami bekerja selama setahun, mengeluarkan piano dari semak-semak, ternyata "kurang tepat", perlu beberapa sentuhan akhir. Sementara itu, pelanggan telah melahirkan sederet fitur baru. Tidak terbiasa bekerja dalam skema seperti itu agak bodoh. Oleh karena itu, dalam versi manusiawi, dimungkinkan untuk kembali ke tahap sebelumnya untuk klarifikasi dari titik mana pun, menghasilkan "kaskade dengan pengembalian".
Keuntungan dari metode ini jelas. Semakin banyak pemikiran di awal, semakin sedikit pekerjaan yang tidak perlu dilakukan di tengah dan di akhir. Beberapa penemuan kembali sepeda, duplikasi fungsi dan kesalahan dikecualikan.
Namun, jika pada awalnya banyak fungsi, maka tidak mudah untuk melahirkan pemecahan yang benar. Kami membutuhkan analis yang baik, desainer dengan pengalaman di bidang subjek ini. Dan bahkan dalam kasus ini, terdapat risiko penundaan perencanaan implementasi untuk periode yang tidak senonoh.
Ke depan, metode ini terus diperbaiki, misalnya metode V , di mana tahapan pengembangan di sepanjang kemiringan kiri huruf "V" sesuai dengan tahapan pengujian dan penerimaan pendakian di sebelah kanan. Tingkat horizontal segera menunjukkan dokumen proyek kontraktor mana yang menjadi dasar untuk dokumen penerimaan pelanggan.
Jelas bahwa perbaikan tidak dapat mengatasi keterbatasan fundamental dari metode ini. Itulah mengapa mereka berprinsip. Ini tidak berarti bahwa metodenya buruk. Dia hanya memiliki resiko seperti ini. Jika Anda dapat menangkis risikonya, maka semuanya baik-baik saja, kami mulai berpikir dan menikmati manfaat di sepanjang jalan.
Pengembangan hulu
Faktanya, metode ascending bahkan lebih tua dari metode descending. Pada 1950-an, Fortran dan Cobol sudah ada, tetapi tidak ada gagasan yang jelas tentang bagaimana membangun perangkat lunak. Karena itu, kami bertindak dengan cara yang paling alami: hari ini kami akan melakukan satu hal, besok hal lain, kemudian suatu hari kami akan merekatkannya menjadi yang ketiga. Jika Anda perlu menerapkan beberapa tugas, kami memilih yang paling penting.
Terkadang metode ini juga disebut inkremental, tampaknya dengan analogi
i++
. Menambahkan fungsi - kenaikan. Jika Anda ingin meregangkan globe ke proyeksi Mercator, Anda juga dapat memanggil metode spiral inkremental, tetapi akan dibahas lebih lanjut nanti. Mereka juga suka menggambarkan metode dalam bentuk siklus, meskipun untuk
i++
nilai akhir tidak ditentukan, jadi Anda harus "menggali" dari sini sampai waktu makan siang. Melanjutkan tema peribahasa Rusia, kami memiliki pepatah "berputar seperti tupai di roda" - ini hanya tentang metode naik.
Tekniknya dulu dan tetap yang paling umum untuk pengembangan in-house. Pemrogram mereka harus melakukan apa yang dibutuhkan bisnis kemarin. Untuk berpikir lebih global, tahun 1960-an melihat munculnya "rumah perangkat lunak" - kantor desain besar untuk pengembangan sistem kustom, termasuk monster seperti IBM .
Semua pembangunan perangkat lunak ke atas ini berlanjut tanpa perubahan signifikan hingga tahun 1990-an. Pertarungan utama untuk mencocokkan teori akademis dengan praktik teknik telah melewati tempat berlindung yang aman karena pertarungan itu terjadi di hutan metode top-down dan spiral.
Pada tahun 1990-an, ada tren yang kuat untuk mengganti programmer "rumahan" dengan konsultan eksternal. Salah satu penyebabnya adalah komplikasi teknologi dan spesialisasi, yang sulit dicapai dalam perusahaan di mana rekayasa perangkat lunak merupakan aktivitas non-inti. Perangkat lunak rumah sekarang dikembangkan oleh tim sementara
Dalam situasi seperti itu, metode fungsi-demi-fungsi yang sederhana lagi-lagi tampaknya cocok. Tetapi bekerja dengan kontraktor berupah harian membutuhkan lebih banyak pengawasan daripada pekerja penuh waktu yang digaji. Pendekatan tersebut perlu diadaptasi, menghindari prosedur birokrasi. Memang, untuk "mengeluarkan kerangka acuan" membutuhkan perencanaan umum dan dokumen yang relevan, yaitu, vollensnolens, seseorang harus beralih ke metode formal top-down atau spiral. Dan mengapa perusahaan transportasi atau pabrikan mobil membutuhkannya, misalnya? Orang hanya ingin menyelesaikan masalah internal kecil, menghitung gaji di sana, atau mengurangi jadwal liburan.
Permintaan menciptakan pasokan, pada akhir tahun 1990-an, apa yang disebut metode tangkas muncul, paling tidak, memungkinkan pelanggan untuk tetap memperhatikan denyut nadi, dan kontraktor secara bertahap memahami apa yang sebenarnya mereka terapkan.
Apa yang ditingkatkan:
- perencanaan masih pendek, tetapi mencakup lebih dari satu fungsi, dan kelompoknya, sedangkan jangka waktu tahapan sangat terbatas;
- catatan tentang apa yang telah dilakukan disimpan;
- secara teoritis, waktu harus dialokasikan untuk menyederhanakan dan membersihkan kode (refactoring);
- dalam teori, risiko regresi harus dilawan dengan pengujian komprehensif.
Mengapa saya menulis "secara teoritis"? Dalam praktiknya, ketika anggaran terbatas atau dalam kesulitan waktu, kedua poin ini dikorbankan terlebih dahulu. "Sapi suci" di ajiles bukanlah kualitas kode, seperti yang dimaksudkan penulis, tetapi tenggat waktu untuk fungsi selanjutnya.
Duplikasi kode, komplikasi yang tidak perlu, ditunda "untuk kemudian" implementasi yang tidak efektif - jika Anda tidak membersihkan apa yang telah dilakukan sebelumnya, maka hutang teknis akan bertambah. Nanti hutang dilunasi, semakin banyak yang harus Anda bayar pada akhirnya: waktu, hari kerja, kesalahan, kegagalan, pekerjaan lambat, dll.
Setelah sekitar 10-15 tahun, para penulis "Manifesto Ajaila" mulai membunyikan alarm: "Teman-teman, apa yang kamu lakukan, kami bermaksud sesuatu yang lain." Mereka agak benar, pengembangan dari bawah ke atas sangat sederhana dan sangat menarik sehingga semua prosedur tambahan ini tampaknya tidak diperlukan.
Mari kita rangkum apa yang baik tentang pengembangan bottom-up. Pertama-tama, ambang masuk berkurang tajam. Untuk memulai dari awal tidak membutuhkan ahli yang mahal dalam analisis dan desain dengan pengalaman. Meskipun seluruh konstruksi dapat bertahan tanpa batas waktu, barak pertama akan segera didirikan, dan Anda dapat mulai menetap di dalamnya. Lebih mudah untuk mengelola proses, titik kontrol dan tujuan lokal transparan.
Masalahnya, seperti dalam kasus "air terjun", sangatlah mendasar. Lebih mudah untuk mengelola proses, tetapi hampir tidak mungkin - hasil akhirnya, karena tidak dicatat dengan jelas di mana pun. Risiko diteruskan kepada pelanggan: biarkan pemilik produk berpikir bahwa dia adalah orang yang hebat. Jika tim menangani arsitektur teknis dengan pengalaman, pengujian, dan pemfaktoran ulang (hingga ambang batas kompleksitas tertentu), maka arsitektur fungsionalnya buruk. Penyederhanaan pernyataan masalah, sangat "refactoring", sekarang model domain, akan membantu untuk menyingkirkan kode mahal dan mahal untuk dipelihara, tetapi tidak ada yang membuatnya. Dan tidak ada model, jujur saja, semua semantik ada di kepala dan di kode.
Tapi tidak ada alasan untuk kecewa, ingatlah tentang sprint paling dahsyat dalam sejarah dunia: 5 hari penciptaan dan satu setengah miliar tahun refactoring terus menerus.
Rekayasa spiral
Batasan "air terjun" yang disebutkan di atas menjadi jelas pada tahun 1970-an, setelah penerapan besar-besaran dari metodologi yang sesuai seperti SADT / IDEF . Pada saat yang sama, kami mengerjakan metode bottom-up pada proyek "rumah" dengan masalah lain, yang menciptakan perasaan buntu. Oleh karena itu, para peneliti bingung dengan masalah (terutama Barry Boehm ), menggaruk lobak mereka, yang dikeluarkan pada pertengahan 1980-an visi yang diperbarui dari proses pembangunan perangkat lunak dalam bentuk spiral .
Logika dari penalaran "spiral" kira-kira sebagai berikut. Ya, seiring bertambahnya kompleksitas tugas, kita menghabiskan lebih banyak waktu untuk analisis dan desain, risiko kesalahan pada tahap ini semakin meningkat. Tetapi menerapkan fungsi individu tanpa rencana umum, kita berisiko membuat kesalahan, dan kita berakhir dengan bagian yang tidak efektif atau hanya tidak kompatibel. Oleh karena itu, kami akan membiarkan desain "sapi suci", tetapi a) kami akan membatasi kerangka waktu untuk itu dan b) kami akan memeriksa secara ketat keputusan yang dibuat, meluncurkan prototipe lengkap.
Poin "b" sangat penting. Dengan pengembangan dari bawah ke atas, Anda juga terus-menerus menghasilkan sesuatu, perbaikan bug di sana, fitur-fitur baru. Tetapi ini akan berfungsi jika sistem sudah beroperasi dan dalam pemeliharaan. Dan jika tidak? Bayangkan seorang pelanggan menginginkan sistem kendali lalu lintas kereta, dan dalam beberapa minggu Anda menunjukkan layar untuk memasukkan informasi tentang lok dan simulator jadwal. Tidak serius.
Prototipe harus menyertakan sebagian besar fungsi, bahkan jika tidak diimplementasikan sepenuhnya atau bahkan dengan "rintisan". Dari prototipe lengkap, masing-masing, kami mendapatkan umpan balik penuh: di sini mereka mengacaukan, tidak memahami esensi dari persyaratan, mereka tidak memperhitungkan lingkungan operasi, di sana format output tidak sesuai dengan format input, dll. Dengan umpan balik yang berharga ini, kami memulai putaran kedua spiral, cukup percaya bahwa peluang untuk membawa prototipe berikutnya ke tingkat produk jadi tinggi. Untuk sistem berukuran sedang (kira-kira hingga satu juta baris kode), dua atau tiga iterasi sudah cukup.
Dari apa yang telah dikatakan, jelas bahwa mengaitkan spiral dengan metode inkremental sama konyolnya dengan ikan, meskipun keduanya memiliki ekor.
Apa bagusnya spiral? Kami secara drastis mengurangi risiko peluncuran kepada pelanggan alih-alih produk, terus terang melanjutkan, tetapi pada saat yang sama kami tidak mengorbankan desain. Artinya, visi global situasi tetap, hasil akhirnya dapat dikelola dengan menghitung anggaran dan keuntungan. Setiap orang, klien dan kontraktor, dapat melihat cahaya di ujung terowongan. Pelanggan, jika dia serius dalam niatnya, juga tidak akan berteriak: "Mengapa Anda memasang ekor saya, kemudian menyelipkan belalai saya, tunjukkan seluruh gajah!" Di setiap belokan, seluruh gajah terlihat.
Namun, dibandingkan dengan peningkatan rekayasa perangkat lunak, tidak mungkin untuk mengelola satu peleton teknisi-programmer tanpa analis dan desainer, dan Anda harus menjelaskan momen rumit ini kepada pelanggan sebagai alasan harga yang lebih tinggi. Setelah tahap desain babak pertama, para spesialis tidak berdiri diam, tetapi terus menggigit tugas, menunggu umpan balik, tetapi di babak final kemungkinan besar mereka tidak akan dibutuhkan sama sekali. Panjang kumparan bisa sampai beberapa bulan, tapi biasanya harganya dua sampai tiga bulan. Ini tidak terlihat seperti sprint mingguan yang ekstrim, tetapi juga tidak terlihat seperti ekspektasi tahunan suatu produk. Juga tidak mudah untuk memilih kapan, pada tahap ini, “sudah cukup untuk mendesain” dan sudah waktunya untuk mulai memasang batu bata.
Penerapan teknik spiral yang paling terkenal dan sukses - MSF(Kerangka Solusi Microsoft). Microsoft kemudian memiliki versi yang dipotong, diasah untuk metode bottom-up, dan dipasarkan sebagai MSF untuk Agile untuk proyek dan tim yang relatif kecil.
Bukan epilog
Kakek Brooks menguraikan empat jenis perangkat lunak yang dibuat orang dalam buku larisnya .
Gambar tersebut menunjukkan bahwa pada titik tertentu Anda dapat berhenti "hanya menulis program" dan "dengan harga selangit" ingin menjadikannya produk (sesuatu yang dipasok ke banyak klien berbeda), atau kompleks (sesuatu yang terdiri dari banyak program dan dengan mulus diintegrasikan ke dalam lingkungan pelanggan, termasuk peralatan). Dan jika "menulis program", pada umumnya, dapat menjadi salah satu metode pembangunan lunak, maka rencana bagus Anda untuk pengembangan lebih lanjut dapat terganggu oleh kekurangan metode top-down dan bottom-up.
Dalam kondisi ketika sumber daya manusia teknisi-programmer berlebihan dengan kekurangan dan kesulitan dalam mempekerjakan desainer dan analis, alih-alih organisasi horizontal ("insinyur sistem" membuat platform untuk "pelamar"), mereka mulai menggunakan yang vertikal , di mana setiap tim menjalankan fungsinya berdasarkan sepeda masing-masing. Dari sudut pandang manajemen, metode kedua terlihat lebih sederhana, tetapi hanya sampai saat perintah "arsitektur" horizontal diperkenalkan, yang, melalui persuasi dan koordinasi yang lama, mengurangi risiko kesalahan berulang yang sama.
Dalam hal ini, mungkin kita bisa berhenti, karena orientasi awal pada ruang informasi sudah cukup. Terdapat kata kunci dan beberapa link di dalam teks tersebut, sehingga yang penasaran bisa menggali topik tersebut lebih jauh.
Teks asli di situs "Mekanika rekayasa perangkat lunak"