Software engineering didefinisikan oleh Fritz Bauer sebagai: penerapan dan penggunaan prinsip-prinsip engineering yang baik dalam rangka menghasilkan software yang ekonomis, reliable, dan bekerja secara efisien pada komputer sungguhan. Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.
Sementara itu IEEE mendefinisikan software engineering sebagai: Aplikasi yang sistematis, tertata, mampu untuk dikembangkan, dioperasikan, dirawat dan diperbaiki, itulah sebuah aplikasi software engenering.dan mempelajarinya
Komponen Software Engenering :
Komponen adalah pokok bahasan yang sangat menarik jika kita membicarakan masalah reuse. Membangun software yang bersifatreusable akan sangat sulit dikarenakan desain komponen yang tidak baik. Hal ini dapat mengakibatkan komponen yang satu dengan yang lain sulit untuk dipisahkan. Di dalam membangun dan memelihara komponen memiliki hubungan external atau ketergantungan antar komponen dibutuhkan kejelasan pengertian dari dan antar komponen. Suatu komponen dapat saja (komponen dependence). Untuk itu diperlukan sebuah tools yang dapat melihat komponen dependence.
Metode software engineering memberikan tehnik-tehnik bagaimana membentuk software. Metode ini terdiri dari serangkaian tugas:
§ Perencanaan & estimasi proyek
§ Analisis kebutuhan sistem dan software
§ Desain struktur data
§ Arsitektur program dan prosedur algoritma
§ Coding
§ Testing dan pemeliharaan
Peralatan Software Engineering
Peralatan software engineering memberikan dukungan atau semiautomasi untuk metode. Contohnya :
§ CASE (Case Aided Software Engineering), yaitu suatu software yang menggabungkan software, hardware, dan database software engineering untuk menghasilkan suatu lingkungan software engineering.
§ Database Software Engineering, adalah sebuah struktur data yang berisi informasi penting tentang analisis, desain, kode dan testing.
§ Analogi dengan CASE pada hardware adalah : CAD, CAM, CAE
Prosedur Software Engineering
Terdiri dari :
§ urut-urutan di mana metode tersebut diterapkan
§ dokumen
§ laporan-laporan
§ formulir-formulir yang diperlukan
§ mengontrol kualitas software
§ mengkoordinasi perubahan yang terjadi pada software
2.Tanggung Jawab Profesional dan Etika
Menurut Donald Gotterbarn Etika rekayasa perangkat lunak dapat didekati dari tiga arah.
Pertama, Menggambarkan aktivitas sofware engineer membuat pilihan praktis lain yang mempengaruhi orang dalam cara yang signifikan.
Kedua, Digunakan untuk menggambarkan kumpulan prinsip-prinsip,
pedoman, atau imperatif etis yang membimbing atau tindakan legislatif.
ketiga, Dapat digunakan
untuk nama sebuah disiplin ilmu yang mempelajari etika hubungan antara dua indra lain.
Ada berbagai nama yang terlibat dalam pengembangan Software, seperti analis sistem informasi, bagi mereka yang terlibat dalam pengembangan perangkat lunak profesional. Terlepas dari judul yang digunakan, fokus perangkat lunak kegiatan rekayasa terutama pada kecukupan teknis produk yang dikembangkan. Tetapi fakta bahwa kira-kira satu milyar orang tergantung pada sistem perangkat lunak untuk secara efektif melakukan
kehidupan sehari-hari mereka (Reed, 2000) telah menyebabkan banyak di komputer untuk memberikan lebih banyak perhatian pada nonteknis aspek dan bergulat dengan dampak etis keputusan sehari-hari mereka dan nilai-nilai yang tertanam di dalamnya.
Hubungan antara komputer dan etika dapat digambarkan sebagai terjadi ketika manusia membuat keputusan tentang komputer, dan mereka keputusan yang mempengaruhi kehidupan masyarakat. Nilai-nilai kemanusiaan yang terkait dengan keputusan teknis dengan cara ini.
Kegiatan Software Engineering Etika Profesional terjadi ketika suatu keputusan
dibuat oleh komputer profesional selama desain, pengembangan, konstruksi dan
pemeliharaan artefak komputasi mempengaruhi orang lain. Keputusan ini dapat dilakukan oleh individu, tim, manajemen, atau profesi. Keputusan rekayasa perangkat lunak bagaimana merancang pelepasan kantong udara akan mempengaruhi kehidupan orang lain.
Keputusan ini juga dipandu oleh keputusan etis tentang nilai-nilai kemanusiaan. Barry Boehm (1981) memulai bekerja pada rekayasa perangkat lunak ekonomi dengan sebuah anekdot tentang bagaimana Kegagalan untuk mempertimbangkan nilai-nilai manusia mempengaruhi pengembangan perangkat lunak untuk sekolah tinggi
sistem kehadiran. Karyanya pada proyek ini membuatnya melihat bahwa insinyur perangkat lunak
"... Kesempatan untuk membuat dampak positif yang signifikan pada masyarakat, hanya dengan menjadi
lebih sensitif terhadap manusia dalam jangka panjang hubungan implikasi dari pekerjaan kita dan menggabungkan
kepekaan ini ke dalam perangkat lunak kami desain dan produk. "(Boehm, 1981)
Software Engineering Prinsip Etis
Aktivitas etika terlibat dalam keputusan-keputusan teknis harus didasarkan pada pemahaman dampak dari keputusan tersebut. Seringkali keputusan dibuat sementara hanya melihat masalah teknis, tetapi keputusan itu dampak lain dalam cara-cara positif dan negatif. Baik keputusan rekayasa perangkat lunak memerlukan kesadaran dan pertimbangan yang cermat baik dari teknis dan dimensi etika keputusan teknis harus sadar dipandu oleh nilai-nilai. Tidak adanya kesadaran dari hubungan antara
teknologi dan nilai-nilai berarti bahwa nilai-nilai yang terkait dengan teknologi serampangan.
Profesi menggambarkan nilai-nilai ini dalam Kode Etik, Kode Etik dan Kode Practice. Kode-kode ini melayani berbagai fungsi yang terkait dengan suatu profesi termasuk menyediakan panduan bagi praktisi pilihan etis dan mendidik praktisi dan publik tentang standar etika profesi.
Kode etik adalah pernyataan tentang interaksi teknologi dan nilai-nilai. Mereka
juga dimaksudkan untuk memastikan bahwa interaksi ini tidak sembarangan. Beberapa kode, seperti Australian Computer Society Kode Etik membawa berat badan hukum untuk menjamin terstruktur interaksi, sementara kode-kode lain, seperti Rekayasa Perangkat Lunak Kode Etik dan Praktek profesional, bergantung pada tekanan normatif. Tujuan dari semua kode ini adalah untuk memastikan bahwa kegiatan berlatih profesional sebagai individu, tim, manajemen, atau organisasi profesional, memajukan dan melindungi nilai-nilai kemanusiaan daripada melakukan kerusakan mereka.
Tata-tertib Software Engineering Etika
Disiplin studi etika rekayasa perangkat lunak interaksi etika prinsip-prinsip dan teknologi untuk memeriksa cara-cara ini yang mempengaruhi interaksi ini masyarakat, para warga negara, dan produk rekayasa perangkat lunak. Sebagai sebuah disiplin, perangkat lunak menggambarkan etika enjiniring, memurnikan dan lebih mengeksplorasi hubungan antara prinsip dan praktek teknis berkembang.
Perkembangan Etika Software Engineering
Software engineering adalah profesi yang muncul, yang sadar diri dari pengaruhnya terhadap masyarakat dan kewajiban yang dihasilkan. Kenyataan bahwa komputasi memiliki dampak yang signifikan harian pada kehidupan milyaran orang telah menyebabkan banyak dalam komputasi untuk bergulat dengan etika mereka kewajiban. Pada 1990-an banyak organisasi telah ditinjau ulang kode perilaku mereka atau
kode etik dan direvisi mereka dengan cara yang lebih jelas menyatakan kewajiban etis untuk masyarakat luas. Sebagai contoh, Association for Computing Machinery (ACM), yang Australian Computer Society, British Computer Society (BCS), IEEE Computer
Society (IEEE-CS), dan Selandia Baru Computer Society memiliki semua halus Codes mereka Etik. Sebuah usaha berbasis luas untuk professional rekayasa perangkat lunak dimulai oleh IEEE Computer Society, dan kemudian bergabung oleh ACM (Gotterbarn a, 1996).
Awal tujuan organisasi ini adalah untuk:
1. Adopsi Standar Definisi
2. Define Diperlukan Body of Knowledge and Recommended Practices (dalam listrik
teknik, misalnya, teori elektromagnetik adalah bagian dari tubuh pengetahuan
sementara Listrik Nasional Keselamatan Kode adalah praktek yang disarankan.)
3. Menetapkan Standar Etika
4. Define Pendidikan Kurikulum untuk (a) mahasiswa, (b) lulus (MS), dan (c)
melanjutkan pendidikan (untuk pelatihan ulang dan migrasi). (Gotterbarn b, 1996)
Tujuan tersebut konsisten dengan tujuan profesi lain. Salah satu elemen kunci
dalam setiap profesi adalah pengakuan dari etika dan tanggung jawab moral kepada para klien, untuk masyarakat, dan profesi itu sendiri. Banyak profesi, seperti teknik dan obat, menyatakan tanggung jawab tersebut secara terbuka dalam kode etik dan kemudian membutuhkan pelatihan etika profesional dalam rangka untuk memasuki profesi. Sebagai contoh, IEEE-CS Sertifikasi sebagai Rekayasa Perangkat Lunak Profesional memerlukan kepatuhan pada Perangkat Lunak Engineering Kode Etik dan Profesional Practice.
Namun, minat ini etika tidak selalu merupakan unsur utama rekayasa perangkat lunak.
Rekayasa perangkat lunak telah ditetapkan dirinya sebagai "pembentukan dan penggunaan suara prinsip-prinsip rekayasa [metode] dalam rangka untuk memperoleh perangkat lunak secara ekonomis yang dapat diandalkan dan bekerja pada mesin yang nyata. "(Bauer, 1972) tidak secara eksplisit menunjukkan keberadaan
isu-isu etis. Standar IEEE 610,12 definisi juga memiliki kekosongan yang sama.
"Software Engineering:
(1) Permohonan yang sistematis, disiplin, pendekatan kuantitatif
pembangunan, operasi, dan pemeliharaan perangkat lunak, yaitu penerapan
rekayasa perangkat lunak.
(2) Studi pendekatan seperti pada (1). "
Sebagai disiplin matang menuju profesi dan dampak dari produk yang diperbesar, deskripsi dari disiplin mulai secara eksplisit menyebutkan tempat-tempat di mana isu-isu etis mungkin muncul. Ketika rekayasa perangkat lunak digambarkan sebagai suatu disiplin yang "memerlukan pemahaman dan penerapan prinsip-prinsip teknik, keterampilan desain, manajemen yang baik praktek, ilmu komputer, dan matematika formalisme. (BCS, 1989) ", beberapa daerah keprihatinan etis seperti praktek manajemen yang baik mulai muncul. Awal ini deskripsi tidak memberikan keunggulan untuk isu-isu etis. Definisi Bauer tidak menyebut kepuasan dari kebutuhan klien atau memenuhi standar profesi, namun ini adalah tersirat dalam istilah-istilah seperti "diandalkan", "ekonomis" dan "bekerja". The BCS definisi lengkap
tidak termasuk beberapa referensi insinyur perangkat lunak tanggung jawab kepada profesi.
Sebagai dampak dari rekayasa perangkat lunak telah diperluas sehingga memiliki pengakuan atas tanggung jawab dari insinyur perangkat lunak.
Tanggung jawab ini dirumuskan dalam Rekayasa Perangkat Lunak Kode Etik dan
Perilaku Profesional (SECODE 1999) adalah diringkas sebagai:
Sofware Engineer akan berkomitmen untuk membuat analisis, spesifikasi, desain, pengembangan, pengujian dan pemeliharaan perangkat lunak yang menguntungkan dan
dihormati profesi. Sesuai dengan komitmen mereka terhadap kesehatan, keselamatan
dan kesejahteraan masyarakat, perangkat lunak insinyur harus mematuhi Delapanberikut
Prinsip:
1 PUBLIC - Software insinyur harus bertindak secara konsisten dengan kepentingan publik.
2 KLIEN DAN MAJIKAN - Software insinyur harus bertindak dengan cara yang ada di
kepentingan terbaik klien atau majikan mereka dan yang konsisten dengan publik
bunga.
3 PRODUK - Software insinyur harus memastikan bahwa produk mereka dan yang terkait
modifikasi memenuhi standar profesional tertinggi mungkin.
4 JUDGMENT - Software insinyur harus menjaga integritas dan kemandirian dalam
penilaian profesional mereka.
5 MANAJEMEN - Software engineering manajer dan pemimpin harus berlangganan ke
dan mempromosikan pendekatan etis dengan pengelolaan dan pengembangan perangkat lunak
pemeliharaan.
6 PROFESI - Software insinyur memajukan integritas dan reputasi
profesi konsisten dengan kepentingan publik.
7 KOLEGA - Software engineer harus bersikap adil dan mendukung mereka
rekan.
8 DIRI - Software insinyur akan berpartisipasi dalam mengenai belajar sepanjang hayat
praktek profesi mereka dan mempromosikan pendekatan etis praktek
profesi.
Seperangkat prinsip ini, dikembangkan dan direview oleh insinyur perangkat lunak dari setiap benua insinyur perangkat lunak mengungkapkan komitmen untuk tingkat perawatan profesional. Itu profesionalisasi dari setiap disiplin melibatkan kesadaran bahwa menjadi seorang profesional melibatkan lebih dari yang kaku penerapan teknologi terbaru ke artefak bahwa disiplin (Ford, 1996). Praktek kedokteran adalah lebih daripada aplikasi obat ke tubuh manusia. Dokter prihatin dengan kesejahteraan pasien mereka. Itu arsitek profesional tidak hanya menerapkan prinsip-prinsip struktural stres saat merancang sebuah bangunan namun berkaitan dengan efek desain pada orang-orang yang akan menggunakan gedung.
Dalam profesionalisasi disiplin ada adalah:
1) realisasi dari
dampak pada masyarakat dari penerapan keterampilan khusus,
2) pengetahuan oleh praktisi
dari standar profesi dan,
3) realisasi dari tanggung jawab yang datang dengan
hak istimewa untuk menjadi diperbolehkan untuk menerapkan keterampilan-keterampilan.
Semacam ini realisasi dalam rekayasa perangkat lunak terlihat dalam definisi yang ditawarkan oleh Software Engineering Institute. Ini mendefinisikan software engineering sebagai "bentuk rekayasa yang menerapkan prinsip-prinsip ilmu komputer dan matematika untuk mencapai costeffective solusi untuk masalah software (Ford, 1990). "Tetapi rekayasa perangkat lunak, sebagai subset dari rekayasa, adalah menciptakan dan membangun "biaya-efektif solusi praktis masalah dalam pelayanan umat manusia "(Ford, 1990). Ford terus menunjukkan secara eksplisit bahwa
biaya efektif tidak berarti membuat sesuatu yang berkualitas marjinal untuk meminimalkan waktu dan sumber daya, lebih tepatnya, "biaya-efektif ... berarti mendapatkan nilai yang baik bagi sumber daya yang diinvestasikan;
nilai ini termasuk kualitas (Ford, 1990).
SOFTWARE ENGINEERING ETIKA
Rekayasa perangkat lunak telah digambarkan sebagai "penerapan disiplin rekayasa,
ilmiah, dan prinsip-prinsip matematika, metode, dan alat untuk produksi ekonomis
perangkat lunak berkualitas ". (Humphrey, 1989). Sebagai insinyur perangkat lunak menerapkan prinsip-prinsip ini, nilai-nilai kemanusiaan menjadi terkait dengan keputusan teknis. Etika rekayasa perangkat lunak mempelajari interaksi nilai-nilai kemanusiaan dan keputusan teknis yang melibatkan komputasi. Software engineering sebagai teknik-seperti disiplin memiliki hubungan langsung dengan etika.
Software engineering adalah ilmu terapan. Setiap produk dari rekayasa perangkat lunak melibatkan orang dan begitu pada setiap tahap pengembangan produk para pengguna menengah dan produk akhir harus diingat. Lunak insinyur mempunyai kewajiban kepada pengguna produk mereka, yang tidak hanya mencakup sistem diimplementasikan, tetapi juga mencakup produk lain seperti persyaratan, rencana manajemen proyek perangkat lunak, spesifikasi, desain, dokumentasi, test suite, program, user manual, dan materi pelatihan.
Dalam mengembangkan artefak rekayasa perangkat lunak ini, setiap keputusan adalah kompromi yang dipengaruhi oleh kendala-kendala tersebut sebagai anggaran yang tersedia, kebutuhan klien, tersedia perangkat lunak, keandalan persyaratan, pertimbangan lingkungan, efek sosial, dan bahkan politik realitas. Semua ini membuat pekerjaan dari insinyur perangkat lunak profesional lebih sulit dan memerlukan penilaian lebih subyektif. Tetapi ada beberapa panduan untuk membuat ini
penilaian.
Dalam beberapa situasi mungkin standar dalam ketegangan dengan satu sama lain atau dengan standar dari sumber lain. Situasi ini memerlukan perangkat lunak insinyur untuk menggunakan etika penilaian untuk bertindak dengan cara yang paling konsisten dengan semangat dari Kode Etika dan Profesional Practice, mengingat keadaan.
Ketegangan etis terbaik dapat ditangani oleh pertimbangan pemikiran fundamental
prinsip, daripada buta ketergantungan pada peraturan rinci. Prinsip ini seharusnya mempengaruhi insinyur perangkat lunak untuk mempertimbangkan secara luas yang terpengaruh oleh mereka pekerjaan; untuk memeriksa jika mereka dan rekan-rekan mereka memperlakukan manusia lain dengan rasa hormat; untuk mempertimbangkan bagaimana publik, jika informasi yang cukup baik, akan memandang keputusan mereka; untuk menganalisis bagaimana paling tidak diberdayakan akan terpengaruh oleh mereka
keputusan; dan untuk mempertimbangkan apakah tindakan mereka akan dinilai layak ideal profesional yang bekerja sebagai insinyur perangkat lunak. Dalam penilaian semua perhatian kesehatan, keselamatan dan kesejahteraan masyarakat adalah utama, yaitu yang "Kepentingan Umum" adalah pusat Kode ini. (Kode SE, 1999)
3.Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)
Perangkat lunak adalah suatu benda tak berwujud (intangible) yang berpasangan dengan perangkat keras yang dibuat untuk memenuhi suatu maksud atau tujuan tertentu. Tujuan atau maksud ini bisa jadi bagian dari sebuah sistem atau bahkan sistem itu sendiri. Manusia berperan dalam membangun atau membuat kedua perangkat tersebut, dan berperan untuk menggunakan atau menerima hasilnya. Misalnya perangkat lunak personalia, perangkat lunak tersebut dijalankan pada suatu komputer (perangkat keras) untuk menangani masalah-masalah yang terkait dengan pengelolaan sumber daya manusia sebuah perusahaan. Ada orang-orang yang terlibat dalam mengembangkan perangkat lunak dan ada orang-orang yang menjalankan atau memakainya. Dari penjelasan di atas dapat dilihat ada beberapa hal atau elemen yang terlibat, yaitu perangkat lunak, perangkat keras, pembuat perangkat lunak, pemakai perangkat lunak dan masalah.
Pada Umumnya terdapat 4 siklus hiup pengembangan software Yaitu :
Pada Umumnya terdapat 4 siklus hiup pengembangan software Yaitu :
A. Model WaterFall
Menurut Pressman (2010), model waterfall adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini termasuk kedalam model generic pada rekayasa perangkat lunak dan pertama kali diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.
Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan. Langkah-langkah yang harus dilakukan pada metodologi Waterfall adalah sebagai berikut :
A. Analisis kebutuhan perangkat lunak
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada perangkat lunak. Untuk memahami sifat program yang dibangun, rekayasa perangkat lunak (analisis) harus memahami domain informasi, tingkah laku, unjuk kerja dan antar muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak di dokumentasikan dan dilihat dengan pelanggan.
Mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh software yang akan dibangun. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
B. Desain
Desain perangkat lunak sebenarnya adalah proses multi langka yang berfokus pada empat atribut sebuah program yang berbeda; struktur data, asitektur perangkat lunak, representasi interface dan detail (algoritma) prosedural. Proses desain menerjemahkan syarat/kebutuhan kedalam sebuah representasi perangkat lunak yang dapat di perkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak.
Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari dua aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada user. Proses software design untuk mengubah kebutuhan-kebutuhan di atas menjadi representasi ke dalam bentuk "blueprint" software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. seperti dua aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
C. Generasi Kode
Desain harus diterjemahkan dalam bentuk mesin yang bisa di baca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
D. Pengujian
Proses Pengujian dilakukan pada logika internal untuk memastikan semua pernyataan sudah diuji. Pengujian eksternal fungsional untuk menemukan kesalahan-kesalahan dan memastikan bahwa input akan memberikan hasil yang aktual sesuai yang dibutuhkan.
E. Pemeliharaan
Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau sistem operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja.
Sesuatu yang dibuat haruslah diujicobakan. demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yangdibuat tidak selamanya hanya seperti itu ketika dijalankan mungkin saja masih ada error kecil yang tidak ditemukan sebelumnya atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.
Kelebihan dari model ini adalah selain karena pengaplikasian menggunakan model ini mudah, kelebihan model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal proyek, maka Software Engineering(SE) dapat berjalan dengan baik dan tanpa masalah meskipun seringkali kebutuhan sistem tidak dapat didefinisikan se-eksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal proyek lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.
Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.
Masalah dengan waterfall :
A. Perubahan sulit dilakukan karena sifatnya yang kaku
B. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.
C. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar yaitu dengan proyek yang dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.
Berikut ini gambaran dari waterfall model.
Fase-fase dalam model waterfall menurut referensi Sommerfille :
B. V Model
Apa itu V Model?
Merupakan model pengembangan perangkat lunak yang didasarkan pada hubungan antara setiap fase pengembangan siklus hidup yang tercantum dalam model Watterfall yang merupakan pengembangan perangkat lunak dan fase yang terkait pengujian.
Apa saja tahapan V Model?
- Lifecycle Process Model
- Allocation of Methods
- Functional Tools Requirements
Apa saja Submodel pada V Model?
- Project Management (PM)
- System Development (SD)
- Quality Assurance (QA)
- Configuration Management (CM)
Fase Implementasi Pada V Model
a. Requirement Analysis & Acceptance Testing
Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan
pengguna.
Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para
pengguna atau tidak.
b. System Design & System Testing
Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada
tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan
yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram
dan Data Dictionary.
c. Architecture Design & Integration Testing
Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti:
pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.
d. Module Design & Unit Testing
Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi
penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan
logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.
e. Coding
Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.
Tahapan V Model
Tahapan pada V Model dibagi menjadi 2 garis besar yaitu tahap Verifikasi dan Validasi atau testing.
Tahap Verfiikasi mengacu kepada usaha penyesuaian spesifikasi software dengan kebutuhan klien/konsumen, tahapan ini meliputi serangkaian kegiatan sebagai berikut:
- Business Case: Merupakan tahapan awal yang menggambarkan kebutuhan/harapan konsumen terhadap sistem yang akan dikembangkan, termasuk manfaat sistem terhadap konsumen dan perkiraan biaya yang harus disediakan.
- Requirement: pada fase ini klien mendapatkan gambaran atau diminta memberikan gambaran kebutuhan yang diharapkan dapat dipenuhi oleh software, baik kebutuhan fungsional maupun non fungsional.
- Analisis Informasi: Setelah diperoleh spesifikasi sistem dari fase requirement, selanjutnya aktivitas difokuskan bagaimana cara kerja software untuk memenuhi kebutuhan tersebut, termasuk metode, hardware dan software apa saja yang diperlukan untuk mencapai kebutuhan yang sudah didefinisikan.
- Perancangan Sistem: pada tahapan ini akan dibuat rancangan software secara lebih terinci sesuai spesifikasi yang sudah disepakati.
- Unit Design: merancang setiap elemen/unit software termasuk rancangan modul/program, antarmuka, database dan lain-lain.
- Development: merealisasikan hasil rancangan menjadi satu aplikasi/program tertentu.
Tahapan Validasi merupakan serangkaian tahapan yang mengacu kepada kesesuaian software dengan spesifikasi yang sudah ditetapkan. Tahapan ini dicapai melalui serangkaian pengujian/testing sebagai berikut:
- Unit test: menguji setiap komponen/unit program apakah sesuai dengan rancangan unit yang sudah ditetapkan. Secara teoritis seharusnya pengujian dilakukan oleh orang tertentu yang bertugas sebagai software tester, tetapi dalam kenyataannya seringkali unit testing dilakukan oleh programmer sendiri.
- Interface test: setelah semua komponen diuji secara terpisah, tahapan selanjutnya dilakukan interface test untuk melihat sejauh mana setiap komponen dapat berinteraksi satu sama lain sesuai dengan fungsi yang diharapkan.
- System test: setelah semua interface berjalan dengan baik, selanutnya dilakukan system test untuk melihat sejauh mana sistem/software dapat memenuhi kebutuhan secara keseluruhan. System testing bersifat menyeluruh dan tidak dapat dilakukan berdasarkan fungsionalitas sistem yang diuji secara terpisah. Aktivitas pada system testing termasuk melakukan pengujian hal-hal berikut:
- Performance – apakah kinerja sistem sesuai dengan target yang sudah didefinisikan sebelumnya.
- Volume – apakah software/sistem dapat menampung volume informasi yang cukup besar.
- Stress – apakah software/sistem dapat menampung sejumlah informasi pada waktu-waktu tertentu.
- Documentation – apakah semua dokumentasi penting sudah disiapkan.
- Robustness – apakah software/sistem cenderung stabil pada berbagai kondisi diluar dugaan/ekstrim.
- Acceptance test merupakan aktivitas untuk menguji sejauh mana sistem/software dapat membantu memecahkan business case, dalam artian apakah sistem/software tersebut sudah sesuai dengan harapan konsumen/klien dan sejauh mana manfaat sistem/software ini bagi klien. Test ini sering kali disebut sebagai User Acceptance Test (UAT).
- Release testing: test ini dilakukan untuk menguji sejauh mana sistem/software dapat mendukung aktivitas organisasi dan berjalan dengan harmonis sesuai dengan kegiatan rutin organisasi. Beberapa pertanyaan coba dijawab pada fase ini misalnya apakah software tersebut mempengaruhi sistem lain? Apakah software tersebut kompatibel dengan sistem lain? Bagaimana kinerja sistem sebenarnya di dalam organisasi?
Dimana saja V Model Diterapkan?
- Dalam proyek teknologi informasi di Jerman
- V Model dibandingkan dengan CMM
- V Model didesain untuk mengembangkan sistem yang didalamnya terdapat dua komponen
- Pengembangan V Model dalam bidang industri dapat dilakukan dengan mudah
Kelebihan V Model
- V Model sangat fleksibel
- V Model dikembangkan dan dirawat oleh publik
- Kelebihan V Model dibandingkan dengan Waterfall biasa yaitu, pada setiap fase selalu dilakukan pengujian yang cukup memadai
Kekurangan V Model
- Model yang project oriented
- Memiliki beberapa activity
- Asusmsi yang digunakan adalah requirement bersifat tetap dan tidak berubah
- Requirement dan rancangan tidak diverifikasi
- Pada setiap fase terdapat peluang error
C. Simple Interaction Design Model Lifecycle
Simple Interaction Design Model Lifecycle Software adalah model yang menggabungkan tiga prinsip pengguna berpusat desain dan empat kegiatan desain interaksi.
Prinsip User-Centered Design
Prinsip-prinsip ini dikembangkan oleh John D. Gould dan Clayton Lewis. prinsipnya adalah sebagai berikut:
1. Fokus pada pengguna dan tugas
2. Pengukuran empiris
3. Desain Interatif
Dasar kegiatan Desain Interaksi
Preece et al. menggambarkan model dasar untuk proses desain interaksi yang mencakup empat kegiatan seperti yang ditunjukkan di bawah
ini. Sejumlah akademisi dan lembaga desain terkenal telah menciptakan model yang sama. Zimmerman, J., Forlizzi, J., dan Evenson, S., dari
Sekolah Desain di Carnegie Mellon University.
Kegiatannya adalah sebagai berikut:
1. Mengidentifikasi kebutuhan dan persyaratan mendirikan untuk pengalaman pengguna
2. Mengembangkan alternatif desain yang memenuhi persyaratan
3. Membangun versi interaktif dari desain
4. Mengevaluasi apa yang sedang dibangun di seluruh proses dan pengalaman pengguna yang menawarkan
Bentuk dari simple interaction design model lifecycle software adalah sebagai berikut:
Tahapan Simple Interaction Design Model
1. Identifikasi kebutuhan dan persyaratan sistem disini suatu sistem akan di identifikasi sesuai
dengan kebutuhan sistem itu sendiri.
2. Pengembangan desain alternatif (desain konseptual dan fisikal)
3. Membuat versi interaktif dari desain yang dihasilkan
4. Mengevaluasi desain (usabilitas dan user experience)
D. Star Lifecycle Model
Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama akan lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user.
Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.
Perbandingan Metodologi
Perbandingan Metodologi untuk mengembangkan Sistem informasi Web :
Waterfall Setiap phase pada Waterfall dilakukan secara berurutan namun kurang dalam iterasi pada setiap level. Dalam pengembangan Web Informasi Waterfall memiliki kekakuan untuk ke iterasi sebelumnya. Dimana Web Informasi selalu berkembang baik teknologi ataupun lingkungannya.
Prototipe Membantu user dalam menilai setiap versi dari sistem. Sangat baik untuk “aplikasi yang interaktif”, Umumnya user lebih tertarik pada tampilan dari pada proses pada sistem. Namun dalam prosesnya prototipe cenderung lambat karena user akan menambah komponen dari luar sistem. Sehinggakepastian penyelesaian project tidak jelas. Dan target user dalam Web lebih bervariasi.
Rapid Application Development
Bentuk dari prototipe dengan “throwaway” jika ada modul yang salah maka akan dibuang. Artinya setiap modul tidak akan dikembangkan sampai selesai, karena jika dianalisa salah langsung dibuang.“RAD involve building the wrong site multiple times until the right site falls out of the process”.
Incremental Prototipe
Digunakan untuk menyelesaikan sistem secara global terlebih dahulu, kemudian untuk feature dari sistem akan dikembangkan kemudian. Dengan ini mempercepat dalam pengimplementasian project. dan hal ini cocok digunakan dalam system informasi Web.
Untuk dapat melakukan langkah-langkah sesuai dengan metodologi pengembangan sistem maka dibutuhkan beberapa alat. Alat-alat yang digunakan biasanya berupa gambar atau diagram atau grafik.
Contohnya :
• HIPO diagram
• Data Flow diagram
• Structured chart
• SADT diagram
• Warnier/Orr diagram
• Jakson’s diagram
Diagram-diagram diatas digunakan untuk mengambarkan suatu metode tertentu, ada beberapa grafik yang lebih bersifat umum, antara lain :
• Bagan untuk menggambarkan aktifitas (activity charting), seperti : bagan alir sistem, bagan alis program, bagan alir kertas kerja, bagan alir hubungan database, bagan alir proses, dan Gantt chart.
• Bagan untuk menggambarkan tataletak
• Bagan untuk menggambarkan hubungan personil, seperti : Bagan distribusi kerja dan bagan organisasi.
Teknik yang Digunakan untuk Pengembangan Sistem
Teknik yang digunakan untuk pengembangan sistem antara lain :
• Teknik manajemen proyek, seperti CPM (Critical Path Method) dan PERT (Program Evaluation and Review Technique). Teknik ini digunakan untuk penjadualan proyek.
• Teknik menemukan fakta, yaitu teknik yang dapat digunakan untuk mengumpulkan data dan menemukan fakta-fakta dalam kegiatan mempelajari sistem yang ada. Contohnya : Teknik wawancara, observasi, daftar pertanyaan, pengumpulan sampel.
• Teknik analisis biaya/manfaat
• Teknik inspeksi/walkthrought
Gambar.
- Analisa
Metode : tanya kemampuan user dan buat daftar dengan skala prioritas, observasi ketrampilan di lapangan.
- Evaluasi kompetisi
Metode : pengguna diminta untuk mencoba menggunakan berbagi produk dan minta untuk menyebutkan kelebihan dan kelemahan dari masing-masing produk.
- Rancang sambil jalan
Metode : tanyai user sehubungan dengan pengalaman menggunakan prototipe.
- Evaluasi dan validasi
Metode : amati kebutuhan pokok user dalam menggunakan sistem.
- Benchmark
Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design ) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama aka lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user. Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir seperti model-model rancangan yang lainnya.
http://jackindigo.blogspot.co.id/2014/11/model-waterfall.html
Good Post (y)
BalasHapuspanjang ya dek
BalasHapus