Memahami Rekayasa Perangkat Lunak

Memahami Rekayasa Perangkat Lunak

Ini adalah sistematisasi proses pengembangan perangkat lunak untuk memastikan solusi terbaik yang paling ekonomis. Tujuannya adalah untuk menghasilkan perangkat lunak berkualitas tinggi dengan kecepatan rendah.

Rekayasa Perangkat Lunak adalah penerapan pendekatan yang sistematis, disiplin, dan terukur untuk pengembangan, pengoperasian, dan pemeliharaan perangkat lunak. Proyek pengembangan perangkat lunak yang khas perlu melalui fase Analisis, Desain, Pemrograman, Pengujian, dan Implementasi. Software Project Management (SPM), Software Quality Assurance (SQA) dan penggunaan Computer Aided Software Engineering (CASE) akan berjalan paralel dengan fase lainnya dan akhirnya sampai pada fase pemeliharaan. Selalu dikatakan bahwa lebih dari 80% biaya digunakan untuk pemeliharaan perangkat lunak.

Metodologi Perangkat Lunak

Ini adalah rencana langkah demi langkah untuk menerapkan metode menggunakan alat dan prosedur tertentu. Ini sering menggambarkan kriteria masuk, kriteria keluar dan pos pemeriksaan untuk setiap aktivitas atau komponen dalam rekayasa perangkat lunak. Beberapa metodologi populer saat ini didasarkan pada teknik struktur atau rekayasa informasi atau teknik berorientasi objek. Pemilihan metodologi tergantung pada sifat proyek, jenis aplikasi, alat yang diusulkan untuk digunakan dan jenis kontrol dan dokumentasi yang diperlukan.

Waterfall, Prototyping, Spiral, Aplikasi Cepat, Penyempurnaan Bertahap, Standar industri dan militer, Perakitan dengan penggunaan kembali, Pembuatan aplikasi, Transformasi berkelanjutan, dan otomatisasi perangkat lunak berbasis Pengetahuan adalah beberapa metodologi yang populer.

Faktor-faktor apa yang akan mempengaruhi pilihan model untuk pengembangan perangkat lunak?

Itu tergantung pada sifat dan ukuran aplikasi, apakah itu pengembangan internal atau pengembangan melalui agen eksternal, ketersediaan berbagai alat dan sumber daya, kerangka waktu dan anggaran, dll.

Siapa Insinyur Perangkat Lunak?

Seorang insinyur perangkat lunak adalah seseorang yang menerapkan prinsip-prinsip rekayasa dalam pengembangan koperasi perangkat lunak. Seorang insinyur perangkat lunak yang baik seharusnya tidak hanya menghasilkan program komputer tetapi juga mempelajari keterampilan untuk menghasilkan dokumentasi, database, dan prosedur operasional yang baik untuk sistem komputer. Dia harus didefinisikan dengan baik tentang komponen atau modul rekayasa perangkat lunak.

Mengapa Kita Membutuhkan Rekayasa Perangkat Lunak?

Untuk memahami perlunya rekayasa perangkat lunak, kita harus berhenti sejenak untuk melihat kembali sejarah komputasi baru-baru ini. Sejarah ini akan membantu kita untuk memahami masalah yang mulai menjadi jelas pada akhir tahun enam puluhan dan awal tahun tujuh puluhan, dan solusi yang mengarah pada penciptaan bidang rekayasa perangkat lunak. Masalah-masalah ini disebut oleh beberapa orang sebagai “Krisis perangkat lunak”, dinamakan demikian karena gejala masalahnya. Situasi itu mungkin juga disebut “Penghalang Kompleksitas”, dinamai demikian karena penyebab utama masalah. Beberapa merujuk pada krisis perangkat lunak dalam bentuk lampau. Krisis masih jauh dari selesai, tetapi berkat pengembangan banyak teknik baru yang sekarang termasuk dalam judul rekayasa perangkat lunak, kami telah membuat dan terus membuat kemajuan.

Pada hari-hari awal komputasi perhatian utama adalah dengan membangun atau memperoleh perangkat keras. Perangkat lunak hampir diharapkan untuk mengurus dirinya sendiri. Konsensus menyatakan bahwa “perangkat keras” adalah “sulit” untuk diubah, sedangkan “perangkat lunak” adalah “lunak”, atau mudah diubah. Menurut, kebanyakan orang di industri ini dengan hati-hati merencanakan pengembangan perangkat keras tetapi kurang memikirkan perangkat lunak. Jika perangkat lunak tidak bekerja, mereka percaya, akan cukup mudah untuk mengubahnya sampai berhasil. Dalam hal ini, mengapa membuat upaya untuk merencanakan?

Biaya perangkat lunak berjumlah sangat kecil dari biaya perangkat keras sehingga tidak ada yang menganggapnya sangat penting untuk mengelola pengembangannya. Namun, semua orang melihat pentingnya menghasilkan program yang efisien dan berjalan cepat karena ini menghemat waktu pada perangkat keras yang mahal. Waktu orang diasumsikan menghemat waktu mesin. Membuat proses orang menjadi efisien hanya mendapat sedikit prioritas.

Pendekatan ini terbukti memuaskan pada hari-hari awal komputasi, ketika perangkat lunaknya sederhana. Namun, saat komputasi matang, program menjadi lebih kompleks dan proyek tumbuh lebih besar sedangkan program sejak itu secara rutin ditentukan, ditulis, dioperasikan, dan dikelola oleh orang yang sama, program mulai dikembangkan oleh tim pemrogram untuk memenuhi harapan orang lain.

Upaya individu memberi jalan kepada upaya tim. Komunikasi dan koordinasi yang pernah berlangsung di dalam kepala satu orang harus terjadi di antara kepala banyak orang, membuat seluruh proses menjadi jauh lebih rumit. Akibatnya, komunikasi, manajemen, perencanaan dan dokumentasi menjadi penting.

Pertimbangkan analogi ini: seorang tukang kayu mungkin bekerja sendiri untuk membangun sebuah rumah sederhana untuk dirinya sendiri tanpa lebih dari sekedar konsep umum dari sebuah rencana. Dia bisa menyelesaikan masalah atau membuat penyesuaian saat pekerjaan berlangsung. Begitulah program awal ditulis. Tetapi jika rumah itu lebih rumit, atau jika dibangun untuk orang lain, tukang kayu harus merencanakan dengan lebih hati-hati bagaimana rumah itu akan dibangun. Rencana perlu ditinjau dengan pemilik masa depan sebelum konstruksi dimulai. Dan jika rumah itu akan dibangun oleh banyak tukang kayu, seluruh proyek tentu harus direncanakan sebelum pekerjaan dimulai sehingga ketika seorang tukang kayu membangun satu bagian rumah, yang lain tidak membangun sisi lain dari rumah yang berbeda. Penjadwalan menjadi elemen kunci sehingga kontraktor semen menuangkan dinding basement sebelum tukang kayu memulai pembingkaian. Karena rumah menjadi lebih kompleks dan lebih banyak pekerjaan orang harus dikoordinasikan, cetak biru dan rencana pengelolaan diperlukan.

Ketika program menjadi lebih kompleks, metode awal yang digunakan untuk membuat cetak biru (bagan alur) tidak lagi memuaskan untuk mewakili kompleksitas yang lebih besar ini. Dan dengan demikian menjadi sulit bagi satu orang yang membutuhkan program yang ditulis untuk menyampaikan kepada orang lain, programmer, apa yang diinginkan, atau bagi programmer untuk saling menyampaikan apa yang mereka lakukan. Faktanya, tanpa metode representasi yang lebih baik, menjadi sulit bahkan bagi satu programmer untuk melacak apa yang dia lakukan.

Waktu yang dibutuhkan untuk menulis program dan biayanya mulai melebihi semua perkiraan. Bukan hal yang aneh jika sistem menghabiskan biaya lebih dari dua kali lipat dari yang diperkirakan dan membutuhkan waktu berminggu-minggu, berbulan-bulan atau bertahun-tahun lebih lama dari yang diharapkan untuk diselesaikan. Sistem yang diserahkan kepada klien sering kali tidak berfungsi dengan benar karena uang atau waktu telah habis sebelum program dapat dibuat berfungsi seperti yang dimaksudkan semula. Atau programnya begitu kompleks sehingga setiap upaya untuk memperbaiki masalah menghasilkan lebih banyak masalah daripada yang diperbaiki. Ketika klien akhirnya melihat apa yang mereka dapatkan, mereka sering berubah pikiran tentang apa yang mereka inginkan. Setidaknya satu proyek sistem perangkat lunak militer yang sangat besar yang menelan biaya beberapa ratus juta dolar telah ditinggalkan karena tidak pernah dapat dibuat untuk bekerja dengan baik.

Kualitas program juga menjadi perhatian besar. Karena komputer dan programnya digunakan untuk tugas yang lebih penting, seperti memantau peralatan pendukung kehidupan, kualitas program memiliki arti baru. Karena kami telah meningkatkan ketergantungan kami pada komputer dan dalam banyak kasus tidak dapat lagi hidup tanpa mereka, kami menemukan betapa pentingnya

itu adalah bahwa mereka bekerja dengan benar.

Membuat perubahan dalam program yang kompleks ternyata sangat mahal. Seringkali bahkan untuk membuat program melakukan sesuatu yang sedikit berbeda begitu sulit sehingga lebih mudah untuk membuang program lama dan memulai dari awal. Ini, tentu saja, mahal. Bagian dari evolusi dalam pendekatan rekayasa perangkat lunak adalah belajar mengembangkan sistem yang dibangun dengan cukup baik pertama kali sehingga perubahan sederhana dapat dilakukan dengan mudah.

Pada saat yang sama, perangkat keras tumbuh semakin murah. Tabung digantikan oleh transistor dan transistor digantikan oleh sirkuit terpadu sampai komputer mikro seharga kurang dari tiga ribu dolar menjadi beberapa juta dolar. Sebagai indikasi seberapa cepat perubahan terjadi, biaya sejumlah komputasi tertentu berkurang setengahnya setiap dua tahun. Dengan penataan kembali ini, waktu dan biaya untuk mengembangkan perangkat lunak tidak lagi begitu kecil, dibandingkan dengan perangkat keras, sehingga dapat diabaikan.

Ketika biaya perangkat keras merosot, perangkat lunak terus ditulis oleh manusia, yang gajinya meningkat. Penghematan dari peningkatan produktivitas dalam pengembangan perangkat lunak dari penggunaan assembler, compiler, dan sistem manajemen basis data tidak berlangsung secepat penghematan biaya perangkat keras. Memang, hari ini biaya perangkat lunak tidak hanya tidak dapat diabaikan, mereka telah menjadi lebih besar dari biaya perangkat keras. Beberapa perkembangan saat ini, seperti bahasa nonprosedural (generasi keempat) dan penggunaan kecerdasan buatan (generasi kelima), menjanjikan peningkatan produktivitas pengembangan perangkat lunak, tetapi kami baru mulai melihat potensinya.

Masalah lain adalah bahwa di masa lalu program seringkali belum sepenuhnya dipahami apa yang perlu dilakukan oleh program tersebut. Setelah program ditulis, klien mulai mengungkapkan ketidakpuasan. Dan jika klien tidak puas, akhirnya produser juga tidak senang. Seiring berjalannya waktu, pengembang perangkat lunak belajar menyusun kertas dan pensil dengan tepat apa yang ingin mereka lakukan sebelum memulai. Kemudian mereka dapat meninjau rencana dengan klien untuk melihat apakah mereka memenuhi harapan klien. Lebih sederhana dan lebih murah untuk membuat perubahan pada versi kertas dan pensil ini daripada membuatnya setelah sistem dibangun. Menggunakan perencanaan yang baik membuat kecil kemungkinan bahwa perubahan harus dilakukan setelah program selesai.

Sayangnya, sampai beberapa tahun yang lalu tidak ada metode representasi yang baik untuk menggambarkan sistem yang memuaskan serumit yang sedang dikembangkan saat ini. Satu-satunya representasi yang baik tentang seperti apa produk itu nantinya adalah produk jadi itu sendiri. Pengembang tidak dapat menunjukkan kepada klien apa yang mereka rencanakan. Dan klien tidak dapat melihat apakah perangkat lunak itu yang mereka inginkan sampai akhirnya dibuat. Kemudian terlalu mahal untuk berubah.

Sekali lagi, pertimbangkan analogi konstruksi bangunan. Seorang arsitek dapat menggambar denah lantai. Klien biasanya dapat memperoleh beberapa pemahaman tentang apa yang telah direncanakan arsitek dan memberikan umpan balik apakah itu sesuai. Denah lantai cukup mudah dipahami oleh orang awam karena kebanyakan orang akrab dengan gambar yang mewakili objek geometris. Arsitek dan klien berbagi konsep umum tentang ruang dan geometri. Tetapi perekayasa perangkat lunak harus mewakili klien suatu sistem yang melibatkan logika dan pemrosesan informasi. Karena mereka belum memiliki bahasa konsep umum, insinyur perangkat lunak harus mengajarkan bahasa baru kepada klien sebelum mereka dapat berkomunikasi.

Pemrograman