Site blog

Halaman: () 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ... 39 ()
Anyone in the world

Persyaratan perangkat lunak adalah bidang dalam rekayasa perangkat lunak yang berhubungan dengan membangun kebutuhan stakeholders yang harus diselesaikan oleh perangkat lunak. IEEE (Standard Istilah Rekayasa Perangkat Lunak Terminologi) mendefinisikan persyaratan sebagai:

  1. Sebuah kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai suatu tujuan.

  2. Sebuah kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen resmi yang dikenakan lainnya.

  3. Sebuah representasi didokumentasikan dari kondisi atau kemampuan seperti dalam 1 atau 2.

Untuk memahami kebutuhan user perlu adanya persyaratan-persyaratan antara lain:

  1. Persyaratan Fungsional dan Non Fungsional.

Contoh Persyaratan fungsional:

  • User dapat mencari semua atau satu set awal database atau memilih subset darinya.

  • System akan menyediakan viewer yang sesuai bagi user untuk membaca dokumen pada penyimpanan (store) dokumen.

  • Semua pemesanan diberi identifier yang unik (ORDER_ID) yang dapat di copy user ke area penyimpanan permanent untuk account tersebut.

Persyaratan non-fungsional terdiri dari:

  • Persyaratan Produk: persyaratan yang diambil dari spesifikasi produk, seperti persyaratan hardware untuk mendukung kinerja.

  • Persyaratan Organisasi: persyaratan yang berasal dari kebijakan dan prosedur pada organisasi.

  • Persyaratan Eksternal: persyaratan yang berasal dari factor eksteral terhadap system dan proses pengembangannya.

Ukuran persyaratan non-fungsional

  • Kecepatan: transaksi yang diproses perdetik, waktu tanggal user per event atau waktu refres layar.

  • Ukuran: KB atau jumlah Chip RAM.

  • Kemudahan Penggunaan: waktu pelatihan atau jumlah frame help.

  • Kehandalan: waktu rata-rata kegagalan, probabilitas ketidaksediaan, kecepatan terjadinya kegagalan atau ketersediaan.

  • Ketahanan: waktu start ulang setelah kegagalan, prosentase event yang gagal atau probabilitas korupsi data.

  • Portabilitas: prosentase peryataan tergantung target atau jumlah system target.

  1. Persyaratan User.

Mendeskprisikan persyaratan fungsional dan non-fungsional sehingga dapat dipahami oleh user yang tidak memiliki pengetahuan teknik. Persyaratan user harus ditulis memakai bahasa natural formal dan diagaram intuitif yang sederhana. Persyaratan user tidak boleh didefinisikan memakai model implementasi.

Masalah yang sering muncul:

  • Tidak ada kejelasan

  • Kesimpang-siuran persyaratan

  • Penggabungan persyaratan

  1. Persyaratan Sistem.

Persyaratan system ini lebih rinci dari persyaratan user, dan berfungsi sebagai dasar kontrak untuk implementasi system. Persyaratan system ini digunakan sebagai titik awal perancangan system. Bahasa natural banyak digunakan dalam mendefinisikan persyaratan system.

  1. Dokumentasi Persyaratan Perangkat Lunak.

Spesifikasi Persyaratan Sistem : User harus diberi fasilitas untuk mendefinisikan jenis file eksternal. Setiap file eksternal bisa memiliki alat bantu relevan yang bisa diterapkan pada file tersebut. Setiap file eksternal bisa direpresentasikan sebagai ikon yang spesifik pada display user. Fasilitas harus disediakan untuk ikon yang merepresentasikan suatu jenis file eksternal yang akan didefinisikan oleh user. Ketika user memilih suatu ikon yang merepresentasikan file eksternal, efek pemilihan adalah penerapan alat bantu yang berhubungan dengan jenis file eksternal ke file yang direpresentasikan oleh ikon yang dipilih.

Klasifikasi Requirements :

  1. Requirements Fungsional

Yaitu pernyataan layanan tentang bagaimana system harus bereaksi terhadap input. System harus berlaku pada situasi-situasi tertentu. Secara khusus menyatakan apa yang tidak boleh dilakukan system. Merupakan Fungsi teknis dari perangkat lunak yang akan dikembangkan.

  1. Requirements Non-fungsional

Yaitu pernyataan tentang batasan layanan dan fungsi yang diberikan system. Merupakan Persyaratan yang bersifat kualitatif terhadap sistem atau perangkat lunak yang akan dikembangkan. Biasanya mencakup batasan waktu, batasan proses pengembangan, penggunaan standar, dsb.

  1. Requirements Domain

Yaitu persyaratan yang datang dari domain aplikasi system dan merefleksikan karakteristik domain tersebut. Mencakup domain sistem beserta karakteristiknya. Persyaratan ini bisa berupa persyaratan fungsional maupun non-fungsional.

Notasi Spesifikasi Persyaratan

  1. Bahasa Natural Terstruktur

Pendekatan ini tergantung pada pendefinisian format atau template standar untuk menyatakan spesifikasi persyaratan.

  1. Bahasa Deskripsi Desain

Pendekatan ini menggunakan bahasa pemrograman tetapi dengan lebih banyak fitur abstrak.

  1. Notasi Grafis

Bahasa grafis dilengkapi oleh notasi teks yang digunakan untuk mendefinisikan persyaratan fungsional. Contoh bahasa grafis adalah SADT (Ross 1977), Use-Case (Jacobson et al. 1993).

  1. Spesifikasi Matematis

Notasi seperti himpunan atau finite-state machine, lebih dikenal dengan bahasa formal.

 

Metode Requirements

  • Metode -> Bagaimana menjembatani antara user dengan pengembang perangkat lunak atau developer.

  • Tujuan lebih lanjut adalah agar tidak terjadi kesalahan persepsi baik dari sisi user maupun developer.

  • Metode : SRS Document.

SRS Document

  • SRS: Software Requirements Specification

  • Tujuan:

    • Aspek legalitas antara user dengan developer

    • Dengan adanya SRS, diharapkan kebutuhan user akan dapat terpenuhi dengan baik

  • Syarat SRS Document:

    • Harus dapat menspesifikasi perilaku eksternal

    • Harus dapat menspesifikasi batasan-batasan implementasi

    • Harus mudah diubah

    • Sebagai alat bantu referensi untuk maintenance

    • Harus ada perkiraan mengenai siklus hidup sistem

    • Harus dapat mencirikan tanggapan yang dapat diterima terhadap kejadian yang tidak diinginkan

  • Ada standar tertentu untuk pembuatan SRS Document yaitu Standar IEEE

 

Sumber :

Associated Kursus: KI141325AKI141325A
 
Anyone in the world

Tujuan akhir dari proses rekayasa perangkat lunak adalah menghasilkan perangkat lunak berkualitas tinggi. Philip Crosby (Crosby, 1979), dalam bukunya yang terkenal tentang kualitas, menerangkan bahwa manajemen kualitas bukanlah suatu hal yang tidak diketahui. Para pengembang perangkat lunak percaya bahwa kualitas perangkat lunak merupakan sesuatu yang harus kita perhatikan sejak tahap awal proses rekayasa perangkat lunak.

Untuk memberikan penilaian terhadap proses perangkat lunak secara berimbang, maka diperlukan adanya standar yang baku. Ada beberapa jenis standar yang banyak digunakan oleh masyarakat industri, yaitu antara lain berdasarkan terminologi, klasifikasi, metode atau proses, produk, dan kode pembuatan. Antara satu standar dengan standar yang lain mempunyai persamaan dan perbedaan yang signifi- kan. Standar-standar itu dikeluarkan oleh sebuah organisasi atau badan dunia, yaitu antara lain ISO, IEC, CEN, BSI, ANSI dan DIN. Sebenarnya masih banyak lagi organisasi yang mengeluarkan standar, tetapi cukup kita batasi yang berhubungan dengan segi kualitas saja.

 

Secara umum, tujuan dari berbagai standarisasi yang ada adalah:

-          Menyediakan komunikasi antar pelbagai kelompok yang lebih berarti.

-          Memperkenalkan economy of effort.

-          Melindungi kepentingan pelanggan, ter- utama tentang kualitas.

-          Memajukan quality of life, yaitu keamanan, kesehatan dan perlindungan lingkungan sekitar.

-          Membantu mengurangi trade barrier

 

Secara ringkas, beberapa standarisasi perangkat lunak yang sudah ada antara lain:

-          ISO/IEC 9126, kualitas produk perangkat lunak

-          ISO/IEC 14598, evaluasi produk perangkat lunak

-          ISO 9000 series (BS 5750, EN 29000) sistem kualitas, tidak spesifik untuk perangkat lunak. Sebagai petunjuk pengaplikasian ke perangkat lunak, maka digunakan ISO 9000-3.

-          Software Process Improvement and Capability dEtermination (SPICE), menggabungkan standar dari ISO/IEC 15504

Pengukuran kualitas perangkat lunak adalah tentang mengukur sejauh mana sistem atau perangkat lunak memiliki karakteristik yang diinginkan. Hal ini dapat dilakukan melalui cara-cara kualitatif atau kuantitatif atau campuran keduanya. Menggunakan pendekatan Deployment Quality Function, atribut-atribut yang menjadi ukuran adalah "bagaimana"  melakukan “apa” yang seharusnya ada dalam Kualitas Software tersebut.

                Beberapa standar pengukuran kualitas :

-          Reliabilitas

Tidak diragukan lagi bahwa reliabilitas sebuah program komputer merupakan suatu elemen yang penting. Bila sebuah program berkali-kali gagal untuk melakukan kinerja, maka sedikit meragukan apakah faktor kualitas perangkat lunak yang lain dapat diterima. Reliabilitas perangkat lunak, tidak seperti faktor kualitas yang lain, dapat diukur, diarahkan, dan diestimasi dengan menggunakan data pengembangan historis. Reliabilitas perangkat lunak didefinisikan dalam bentuk statistik sebagai “kemungkinan operasi program komputer bebas kegagalan di dalam suatu lingkungan tertentu dan waktu tertentu.”

-          Efisiensi

Seperti realibilitas, penyebab kinerja inefisiensi sering ditemukan dalam pelanggaran praktek arsitektur dan coding yang baik yang dapat dideteksi dengan mengukur atribut kualitas statis sebuah aplikasi. Atribut-atribut statis memprediksi potensi kemacetan kinerja operasional dan masalah skalabilitas masa depan, terutama untuk aplikasi yang membutuhkan kecepatan eksekusi yang tinggi untuk menangani algoritma kompleks atau volume data yang sangat besar.

-          Keamanan

Kebanyakan kerentanan keamanan hasil dari coding yang buruk dan praktek arsitektur seperti SQL injection atau cross-site scripting.

-          Pemeliharaan (Maintainability)

Pemeliharaan meliputi konsep modularitas, saling pengertian, berubah-ubah, testability, usabilitas, dan pengalihan dari satu tim pengembangan yang lain. Ini tidak mengambil bentuk isu-isu kritis pada tingkat kode. Sebaliknya, pemeliharaan yang buruk biasanya merupakan hasil dari ribuan pelanggaran ringan dengan praktik terbaik dalam dokumentasi, strategi penghindaran kompleksitas, dan praktik pemrograman dasar yang membuat perbedaan antara kode yang bersih dan mudah dibaca vs kode terorganisir dan sulit dibaca .

 

 

Sumber :

-          Crosby, P. (1979). Quality is Free. New York: McGraw-Hill.

-          Willyanto, Leo dan Yulia. July 2013, “Sinergi ISO 9001:2000 – CMII pada Industri Pengembang Perangkat Lunak”. Volume 6, No. 1, http://jurnalinformatika.petra.ac.id/index.php/inf/article/viewFile/16314/16306, 12 Mei 2005.

-          http://handoko.blog.upi.edu/2016/05/05/71/

-          https://en.wikipedia.org/wiki/Software_quality

Associated Kursus: KI141325AKI141325A
 
Anyone in the world

Rapid Application Development (RAD) adalah strategi siklus hidup yang ditujukan untuk menyediakan pengembangan yang jauh lebih cepat dan mendapatkan hasil dengan kualitas yang lebih baik dibandingkan dengan hasil yang dicapai melalui siklus tradisional (McLeod, 2002). RAD merupakan gabungan dari bermacam-macam teknik terstruktur dengan teknik prototyping dan teknik pengembangan joint application untuk mempercepat pengembangan sistem/aplikasi (Bentley, 2004). Dari definisi-definisi konsep RAD ini, dapat dilihat bahwa pengembangan aplikasi dengan menggunakan metode RAD ini dapat dilakukan dalam waktu yang relatif lebih cepat.

 

Gambar 1 : Model RAD

Pemaparan konsep yang lebih spesifik lagi dijelaskan oleh Pressman (2005) dalam bukunya, “Software Engineering: A Practition’s Approach”. Ia mengatakan bahwa RAD adalah proses model perangkat lunak inkremental yang menekankan siklus pengembangan yang singkat. Model RAD adalah sebuah adaptasi “kecepatan tinggi” dari model waterfall, di mana perkembangan pesat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika tiap-tiap kebutuhan dan batasan ruang lingkup projek telah diketahui dengan baik, proses RAD memungkinkan tim pengembang untuk menciptakan sebuah “sistem yang berfungsi penuh” dalam jangka waktu yang sangat singkat. Dari penjelasan Pressman (2012) ini, satu perhatian khusus mengenai metodologi RAD dapat diketahui, yakni implementasi metode RAD akan berjalan maksimal jika pengembang aplikasi telah merumuskan kebutuhan dan ruang lingkup pengembangan aplikasi dengan baik.

Sedangkan menurut Kendall (2010), RAD adalah suatu pendekatan berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan serta perangkat-perangkat lunak. RAD bertujuan mempersingkat waktu yang biasanya diperlukan dalam siklus hidup pengembangan sistem tradisional antara perancangan dan penerapan suatu sistem informasi. Pada akhirnya, RAD sama-sama berusaha memenuhi syarat-syarat bisnis yang berubah secara cepat.

Menurut Kendall (2010), terdapat tiga fase dalam RAD yang melibatkan penganalisis dan pengguna dalam tahap penilaian, perancangan, dan penerapan. Adapun ketiga fase tersebut adalah requirements planning (perencanaan syarat-syarat), RAD design workshop (workshop desain RAD), dan implementation (implementasi). Sesuai dengan metodologi RAD menurut Kendall (2010), berikut ini adalah tahap-tahap pengembangan aplikasi dari tiap-tiap fase pengembangan aplikasi.

 

1)      Requirements Planning (Perencanaan Syarat-Syarat)

Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk megidentifikasikan syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Orientasi dalam fase ini adalah menyelesaikan masalah-masalah perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan perusahaan (Kendall, 2010).

2)      RAD Design Workshop (Workshop Desain RAD)

Fase ini adalah fase untuk merancang dan memperbaiki yang bisa digambarkan sebagai workshop. Penganalisis dan dan pemrogram dapat bekerja membangun dan menunjukkan representasi visual desain dan pola kerja kepada pengguna. Workshop desain ini dapat dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang akan dikembangkan. Selama workshop desain RAD, pengguna merespon prototipe yang ada dan penganalisis memperbaiki modul-modul yang dirancang berdasarkan respon pengguna. Apabila sorang pengembangnya merupakan pengembang atau pengguna yang berpengalaman, Kendall menilai bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada tingkat terakselerasi (Kendall, 2010).

 

3)      Implementation (Implementasi)

Pada fase implementasi ini, penganalisis bekerja dengan para pengguna secara intens selama workshop dan merancang aspek-aspek bisnis dan nonteknis perusahaan. Segera setelah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem diujicoba dan kemudian diperkenalkan kepada organisasi (Kendall, 2010).

Kelebihan dan kekurangan :

Metode pengembangan sistem RAD relatif lebih sesuai dengan rencana pengembangan aplikasi yang tidak memiliki ruang lingkup yang besar dan akan dikembangkan oleh tim yang kecil. Namun, RAD pun memiliki kelebihan dan kekurangannya sebagai sebuah metodoligi pengembangan aplikasi. Berikut ini adalah kelebihan metodologi RAD menurut Marakas (2006):

-          Penghematan waktu dalam keseluruhan fase projek dapat dicapai.

-          RAD mengurangi seluruh kebutuhan yang berkaitan dengan biaya projek dan sumberdaya manusia.

-          RAD sangat membantu pengembangan aplikasi yang berfokus pada waktu penyelesaian projek.

-          Perubahan desain sistem dapat lebih berpengaruh dengan cepat dibandingkan dengan pendekatan SDLC tradisional.

-          Sudut pandang user disajikan dalam sistem akhir baik melalui fungsi-fungsi sistem atau antarmuka pengguna.

-          RAD menciptakan rasa kepemilikan yang kuat di antara seluruh pemangku kebijakan projek.

Sedangkan, mengacu pada pendapat Kendall (2010), maka dapat diketahui bahwa kekurangan penerapan metode RAD adalah sebagai berikut:

-          Dengan metode RAD, penganalisis berusaha mepercepat projek dengan terburu-buru.

-          Kelemahan yang berkaitan dengan waktu dan perhatian terhadap detail. Aplikasi dapat diselesaikan secara lebih cepat, tetapi tidak mampu mengarahkan penekanan terhadap permasalahan-permasalahan perusahaan yang seharusnya diarahkan.

-          RAD menyulitkan programmer yang tidak berpengalaman menggunakan prangkat ini di mana programmer dan analyst dituntut untuk menguasai kemampuan-kemampuan baru sementara pada saat yang sama mereka harus bekerja mengembangkan sistem.

 

Sumber :

-          https://id.wikipedia.org/wiki/Rapid_application_development

-          http://yanaadhesta.blogspot.co.id/2013/05/v-behaviorurldefaultvmlo_9.html

-          https://piyaneo.wordpress.com/2014/05/10/rapid-application-development-rad/

-          Mc.,Leod, R. Jr. 2002. System Development: A Project Management Approach. New York: Leigh Publishing LLC.

-          Whitten, J.L. & Bentley, L.D. 2004. System Analysis & Design Methods: Sixth Edition. New York: Mc.Graw-Hill.

-          Pressman, R.S. 2012. Rekayasa Perangkat Lunak: Pendekatan Praktisi. Yogyakarta: Penerbit Andi.

-          Marakas, G.M. 2006. System Analysis Design: an Active Approach. New York: Mc.Graw-Hill.

-          Kendall, J.E. & Kendall, K.E. 2010. Analisis dan Perancangan Sistem. Jakarta: Indeks.

Associated Kursus: KI141325AKI141325A
 
Gambar dari M RASYID KAROMI 5114100101
by M RASYID KAROMI 5114100101 - Monday, 19 December 2016, 19:28
Anyone in the world

Distribusi perangkat lunak adalah proses penyampaian software untuk pengguna akhir (end user). Distribusi perangkat lunak sering adalah bentuk turnkey dari perangkat lunak bebas(freeware). Dapat mengambil bentuk distribusi biner, dengan installer executable yang dapat didownload dari internet. Contoh berkisar dari seluruh distribusi sistem operasi untuk server dan juru distribusi (misalnya WAMP installer). Distribusi perangkat lunak juga dapat merujuk ke careware dan donateware.

Dalam beberapa tahun terakhir, istilah ini mengacu pada software-software yang mendekati atau sudah selesai (sesuatu yang lebih atau kurang siap untuk digunakan, apakah sebagai sistem yang lengkap atau komponen dari sistem yang lebih besar) yang dirakit terutama dari komponen sumber terbuka.

Dukungan teknis merupakan isu utama bagi pengguna akhir dari distribusi, karena distribusi itu sendiri biasanya gratis dan tidak dapat "dimiliki" dalam arti komersial oleh vendor. Tergantung pada distribusi, dukungan dapat diberikan oleh vendor komersial, para pengembang yang menciptakan distribusi atau oleh komunitas pengguna itu sendiri.

Macam-macam jenis software berdasakan lisensi dan jenis distribusi :

  • Freeware: Freeware adalah perangkat lunak bebas alias gratis, biasanya untuk individu, ada versi berbayar untuk digunakan perusahaan. Umumnya iklan atau sponsor proyek terus hidup (ada) dalam aplikasi ini.

  • Shareware: adalah perangkat lunak yang berjalan hanya untuk jangka waktu tertentu (disebut masa percobaan), maka pengguna harus memutuskan apakah atau tidak membeli produk.

  • Demo dan Trial: cobaan dan demo versi adalah versi terbatas. Versi demo yang berhubungan dengan game dan biasanya versi lengkap, permainan pendek atau sementara untuk pemain untuk melihat apakah Anda menyukai permainan, gameplay. Versi trial berfungsi hampir dengan cara yang sama seperti program kerja, tetapi tidak sepenuhnya, biasanya tidak menyimpan atau mengekspor pekerjaan sama sekali, menggunakan potensi penuh harus membeli perangkat lunak lengkap atau hanya lisensi software tersebut.

  • Beta: versi masih dalam pengembangan atau dikembangkan secara konstan (seperti Gmail dan Google lainnya aplikasi). Setelah versi beta ini merilis sebuah Release Candidate (RC) yang merupakan versi terakhir sebelum rilis resmi dari perangkat lunak.

  • Adware: adalah program yang datang digabungkan dengan program lain, seperti spanduk dan bar pencarian. Adware dapat menjadi batasan dari program shareware dengan menampilkan iklan dan jenis iklan lainnya untuk mendukung proyek tersebut. Spanduk dihapus setelah lisensi dibeli

  • Opensource, GPL dan GNU: Ini adalah sumber, bebas terbuka dan didistribusikan secara bebas tersedia untuk di-download. Pengguna memiliki kebebasan total untuk membuat perubahan mereka sendiri dan kemudian pengembang dapat menggunakan kode ini dalam proyek mengikuti pola yang sama GPL (GNU Public License), yang merupakan format standar open source.

  • Malware: perangkat Lunak Berbahaya dari Inggris. Istilah ini digunakan untuk menggambarkan program-program yang bertujuan untuk menyerang dan merusak sistem dan VIRS sebagai Trojan Horse.

  • Spyware: Software yang bertujuan untuk memantau aktivitas pengguna dan mengumpulkan informasi Anda. Ada berbagai jenis distribusi sebagai Bookware yang terdiri dari membeli sebuah buku tertentu dari penulis untuk perangkat lunak menjadi sah. Beberapa pengembang untuk memperluas koleksi pribadi mereka atau hobi, dan mengembangkan Stampware postcardware dimana pengguna mengirimkan surat atau kartu pos dan pengembang mengirimkan pengguna lisensi atau mendaftarkan perangkat lunak Anda dari jarak jauh.

GNU Autotools adalah salah satu contoh tools untuk distribusi software gratis. LANDesk Management Suite menyediakan distribusi software secara komersial untuk Windows, OS X, dann Linux. Dell KACE menyediakan administrasi remote, distribusi software, dan instalasi software untuk Windows, Mac, atau Linux desktop atau server.

Sumber https://en.wikipedia.org/wiki/Software_distribution

Associated Kursus: KI141325AKI141325A
[ Mengubah: Monday, 19 December 2016, 19:54 ]
 
Gambar dari MUHSIN BAYU AJI FADHILLAH 5114100071
by MUHSIN BAYU AJI FADHILLAH 5114100071 - Monday, 19 December 2016, 19:22
Anyone in the world

Software deployment adalah proses membuat program siap untuk masuk pasar (dipakai oleh end user). Sebuah program yang baru dibuat dapat bekerja dengan baik pada komputer pengembang, tapi itu tidak berarti itu benar-benar siap untuk digunakan user lain. Ada banyak fitur program tambahan yang mungkin tidak diperlukan untuk diri sendiri, tetapi harus ada jika program tersebut akan digunakan oleh orang lain. Fitur-fitur ini diperlukan untuk membuat program lebih user friendly dan untuk membantu melindungi program Anda dari pembajakan. 

Hal-hal yang bisa dipertimbangkan untuk ditambahkan dalam program agar siap digunakan :

-Dokumen pembantu

Salah satu hal yang harus dipertimbangkan untuk membuat program lebih marketable adalh dengan membuatnya mudah dipakai. Aspek kunci untuk membuat program yang lebih mudah digunakan adalah adanya dokumen bantuan online.

 

Bisa dibuat file .txt sederhana dengan cepat untuk tutorial. Atau bisa dibuat .html atau .pdf file tersebut dengan screenshoot dan instruksi untuk bagaimana menggunakan fitur program. Atau bisa dibuat bantuan sistem lengkap dengan daftar isi, indeks, dan database yang bisa dicari.

Dokumen bantuan bisa berjalan secara independen dari program, atau bisa diintegrasikan ke dalam program, seperti tombol/menu pembantu atau link lain bisa yang bisa memuat dokumen bantuan. Dalam kasus apapun, bantuan dokumen yang baik akan membuat program lebih mudah digunakan bagi orang lain.

-File eksekusi

Yang dimaksud file eksekusi (executable file) adalah program file/shortcut yang dipakai untuk menjalankan program.

Dalam memulai program, tidak diperlukan perintah dengan parameter tertentu untuk dimasukkan di suatu tempat/direktori. Ini adalah cara yang sangat tidak ramah bagi pengguna untuk memulai program.

Jika program Anda mengharuskan pengguna untuk memasukkan perintah untuk memulainya, pertimbangkan memberikan wrapper executable untuk perintah. Bila diatur dengan benar, file wrapper executable, ketika diklik ganda, akan mengirimkan perintah dan semua parameter yang diperlukan untuk memulai program Anda.

-Icon library

Dengan ikon yang baik, program yang sudah terancang akan terlihat mempunya tampilan yang lebih profesional dan baik pula. Perlu diingat bahwa dalam pembuatan ikon haruslah dibuat sendiri ataupun memakai yang sudah ada dengan mempertimbangkan royalti dan tidak adanya plagiarisme atau pembajakan.

-License Agreement

Ada beberapa langkah yang dapat diambil untuk membantu melindungi kode program dari pembajakan. Pertama, klaim kepemilikan dan akses pengguna untuk terhadap kode program. Informasi ini harus diletakkan dalam perjanjian lisensi. Jika pengguna tidak setuju dengan ketentuan perjanjian lisensi saat instalasi, maka instalasi bisa dibatalkan.

-Code Obfuscation

Langkah lain dalam melindungi kode dari pembajakan adalah dengan membuat sulit bagi orang lain untuk melakukan apa yang developer tidak ingin orang lain lakukan. Salah satu teknik adalah dengan membuat sulit bagi  orang lain untuk memahami kode program. Ini disebut kode kebingungan. Obfuscating Code melibatkan penggantian nama benda, variabel, dan nama metode untuk simbol berarti; dan menata ulang dan mengubah kode sedemikian rupa, namun program akan tetap berjalan dengan cara yang sama tapi lebih sulit untuk memahami kode program.

-Trial Version

Membuat versi trial mungkin bisa jadi solusi dari teknik pemasaran. Dengan menyediakan versi percobaan dari program, dapat memungkinkan pengguna untuk mencoba program sebelum ia membelinya. Mudah-mudahan, dengan mencoba, ia akan memutuskan untuk membelinya.

-Install Wizard

Install Wizard membuat program mudah untuk diinstal dengan menempatkan semua sumber daya di lokasi yang diperlukan. Membuat program mudah untuk men-download atau berbagi dengan orang lain dengan program bundling dan semua sumber daya ke dalam instalasi file tunggal.

-Uninstall program

Pastikan bahwa program mudah untuk di-uninstall seperti ketika menginstal. Menyediakan program yang akan menghapus semua file yang disalin ke komputer pengguna saat program telah terinstal, dan membersihkan sistem perubahan registry saat instalasi program dibuat.

Membuat program uninstall mudah untuk menemukan. Jika program telah terinstal pada komputer Windows, maka tambahkan program uninstall ke menu Start Windows dan Windows Add / Remove Programs.

Kesimpulannya, ada banyak cara untuk membuat program/software siap masuk pasar daripada hanya menciptakan sebuah program besar yang belum tentu dibutuhkan pasar. Deploying Program membuat orang lain lebih mudah untuk ikut menggunakan, membantu mengurangi pembajakan program, dan memberikan program yang jauh lebih lengkap dan terkesan profesional

Associated Kursus: KI141325AKI141325A
 
Anyone in the world
  1. Introduction

          The estimated cost of software is one of the main problems and very important in the management and development of software projects to help software companies make a good management when developing software. In addition, one sign of good management of software development tends precise in estimating costs and software resources. 1-3It can handle both overestimates and underestimates the software effort and costs. Methods to estimate the cost of software has been introduced by the software industry. 4Among all the methods to estimate software costs, Constructive Cost model (COCOMO) is the most famous and widely used to calculate the cost of the software. 5In 2000, Barry Boehm introduced COCOMO II has proven to be more accurate with some improvement in some of the cost drivers. In addition to using COCOMO II, this paper also uses Fuzzy Logic Model. Basically, fuzzy logic is the logic of rights imprecision and approximate reasoning. More specifically, fuzzy logic can be seen as an attempt formalization / mechanization two remarkable human ability. 1,6Some of the advantages of fuzzy logic is: First, the ability to communicate, reason and make rational decisions in an environment of imprecision, uncertainty, incompleteness of information, conflicting information, the truth alignments and alignments of possibilities - in short, in an environment of imperfect information. Second, the ability to perform a variety of physical and mental tasks without any measurements and calculations. 6In another study, Triangular membership functions have been used to improve the accuracy of estimates from COCOMO II effort. Thus, this paper uses Trapezoidal Membership Function (TMF) to achieve better accuracy and a smooth transition in membership functions. By applying the TMF in COCOMO II cost drivers, the results are expected to be closer to the actual effort as well as the resulting error is getting less.

 

 2. Experimental Details

           Poor estimates not only lead the project over budget and schedule, but also entirely stopped. The ability to accurately estimate software development time, cost and labor, the change as newer methodology replaces the old one. Therefore, the software cost estimation model that is accurate is indispensable in project management software. This research is trying to learn every effort multipliers in COCOMO II. Every effort multiplier ( EM ) using linguistic values to represent each character EM. From the linguistic values ranging from Vey Low to Extra High, this study divides the two categories such as EM to EM qualitative and quantitative. Qualitative effort multiplier is DEPEND, Cplx, Doc, guile, PVOL, PCON, EQUIPMENT, SITE and other business that quantitative multiplier. Fuzzy models used to redesign EM quantitative descriptions can be translated into Fuzzy Logic. The difference for each level is the percentage of execution time available. This study uses a trapezoidal Membership Function ( TMF ) to Fuzzy Logic. TMF create a smooth transition from one level to another. Fuzzy Logic implemented using fuzzy logic tool box in MATLAB software. There are several types of Fuzzy Logic as Gaussian Membership Function, Triangular Membership Functions, Trapezoidal Membership Function and others in the tool box. The tool box is named as Editor Fuzzy Inference System ( FIS ). This FIS Editor GUI helps us to make the input and output with the range and number of membership functions we need. FIS Editor allows us to create rules from input to output. In this study, the following rules will look like this, R1 : IF Input DATA is low THEN Output data is decreased, R2 : IF Input DATA is nominal THEN Output data is unchanged. Cost estimate method proposed in this paper uses fuzzy logic tool box MATLAB software. Fuzzy Systems ( FIS ) used to implement various processing steps. The options available for creating and editing FIS with fuzzy logic software tool box using a graphical tool. This GUI tools helps to edit high-level features such as the number of input and output variables of the FIS. By using FIS editor, the membership function can be added to each of the cost drivers use the command ‘addmf’. Each driver in the hazy COCOMO can be defined by membership functions. Membership function editor by mfedit which allows us to examine and modify all membership function we can change the name, type and parameters.  7Proposed method redesign effort Multiplier by studying the behavior of COCOMO II. Trapezoidal membership functions is defined as follows :

f(x,a,b,c,d) = 0                                     when x < a and x > d

                = (x-a) / (b-a)                       when a <= x <= b

                = 1                                     when b <= x <= c

                = (d-x) / (d-c)                       when c <= x <= d

Click on the variable boxes to select a variable to edit. The box is highlighted in red and the Current Variable field displays the default settings of the selected variable. Double-click one of the variables to open the Membership Function Editor. Double-click the fuzzy rule processor to open the Rule Editor. If a variable exists but is not mentioned in the rule base, it is connected to the rule processor block with a dashed line. The value of TMF is taken from the value of every level in DATA EM. For example, low level has value of <10 so it draw the decreased interval to <10. After creating input and output to TMF, it set the rules based on rules that have been stated before. Then the new value of each level is resulted. Apply this to other qualitative EM. This paper try to improve accuracy to fuzzifying COCOMO II cost drivers which is includes a set of input software attributes : 17 Effort Multipliers ( Ems ), 5 Scale Factors ( SFs ), one size in KLOC ( SZ ). Study the behavior of COCOMO II cost drivers, then proposed to characterize the use of Trapezoidal Membership Function ( TMF ) for cost drivers to represent the linguistic values. The experimental result shows a more accurate effort estimation rather than COCOMO II and Gaussian Membership Function ( GMF ). These are the steps to calculate new set of weight and to improve error : First, inputs, there are three set of inputs ( size in KLOC, 17 Effort Multipliers ), 5 scale factors. Second, fuzzification, divided into three sub modules, SZ-Fuzzifications, SF-Fuzzifications, EM-Fuzzifications. The terms very low, low, nominal, high, very high and extra high. Third, inference engine, operates on a set of fuzzy rules. The fuzzy model rules contain the linguistic variables related to the project. Implemented this model using FIS tool in MATLAB. Fourth, defuzzification, calculates and converts the fuzzy output into crisp data form.

 

3. Results and Discussion

         Presents the result achieved by applying the proposed fuzzy model with Turkish Software Industry dataset consists of 17 projects and 5 different software companies it consists of 24 attributes. The attributes is divided into four categories such as seven attributes describe the project, fifteen attributes show COCOMO II Effort Multiplier in the range from Very Low to Extra High, kilo line of code ( KLOC ), and actual effort in person months. This research tries to compare the accuracy of the estimated effort with actual effort. To evaluate the accuracy of estimated effort, it use most common criteria such as Magnitude Relative Error ( MRE ) and Mean Magnitude Relative Error ( MMRE ), which is defined as . The MRE values are calculated for each project, while mean magnitude relative error computed the average of MRE from N projects. Which defined . The smaller value of MMRE is the closer to actual effort. For example, Project ID 4 by using COCOMO II Model 1032.58 % error by using Gaussian membership Function 1032.58 %, by using proposed method 1022.73 %. It means this proposed model can reduce 98.5 % error from COCOMO II Model and Gaussian Membership Function. And also for MMRE value in COCOMO II Model 733.14 %, by using Gaussian is 717.67 %, by using Trapezoidal is 716.85 %

 

4. Conclusion

          In conclusion, Fuzzy Logic is used to improve the accuracy of COCOMO II models and proposed model use Turkish Software Industry dataset. It has been found that the trapezoid function works better than COCOMO II and Gaussian function, it shows a smooth transition in the interval, the results are closer to the actual effort. The value of proposed method shows smaller than the MRE or MMRE is closer to the actual effort. MMRE had a 733.14% by using COCOMO II, using Gaussian 717.67%, 716.85% by using a trapezoid. The proposed method can reduce 16.29 % from the previous method.

 

Acknowledgments

        The authors would like to express heartfelt thanks to the Prof.Drs.Ec.Ir.Riyanarto Sarno,M.Sc.,Ph.D., Daniel Oranova Siahaan,S.Kom.,M.Sc.,PDEng, Adhatus Solichah Ahmadiyah S.Kom,M.Sc., Dr.Ir. Siti Rochimah,MT. for their helpful discussions.

 

References and Notes

  1. R.Sarno,J.Sidabutar,Sarwosri, “Improving the Accuracy of COCOMO’s Effort Estimation Based on Neural Networks and Fuzzy Logic Model,” Int. Conf. Information, Commun. Technol. Syst., pp. 197–202, (2015).
  2. R.Sarno, J.Sidabutar,Sarwosri, "Comparison of different Neural Network architectures for software cost estimation,"Int.Conf.Compt.Control.Informatics Its Appl., pp. 68-73 (2015).
  3. S.Waghmode, Dr. K. Kolhe, “A novel way of cost estimation in software development based on clustering techniques”, International Journal of Innovative Research in Computer and Communication Engineering, vol.2,Issue 4 (2014).
  4. B.Boehm,Software Engineering Economics, New Jersey,USA: Prentice-Hall,Englewood Cliffs (1994).
  5. L.Zadeh,”A new direction in AI-toward a compational theory of perceptions,”AI Magasine,pp.73-84 (2011).
  6. V. Chandra, "Software effort estimation: a fuzzy logic approach," International Journal of Computer Applications, vol. 103, pp. 39-43 (2014).
  7. Ziauddin, S.Kamal,S.Khan,J.A.Nasir,”A fuzzy logic based software cost estimation  model”,International Journal of Software Engineering and Its Applications,vol.7, no.2 (2013).

Table caption

Table 1.  Comparison of effort estimation result in MRE and MMRE

Project ID

MRE(%) using COCOMO II Model

MRE(%) using Gaussian Membership Function

MRE(%) using  Trapezoidal Membership Function

1

190,67

190,67

190,67

2

42,84

44,54

44,54

3

106,76

100,95

100,95

4

1032,58

1032,58

1022,73

5

1478,89

1475,73

1457,73

6

26,05

31,12

31,12

7

14,43

20,45

20,45

8

2841,79

2696,16

2696,16

9

1553,36

1539,47

1539,47

10

1499,90

1472,90

1472,90

11

0,07608

3,90

3,90

12

0,02745

3,56

3,56

MMRE(%)

733,14

717,67

716,85

 

 

Associated Kursus: KI142303BKI142303B
[ Mengubah: Monday, 19 December 2016, 17:54 ]
 
Gambar dari Rahmi Rizkiana Putri 5115201012
by Rahmi Rizkiana Putri 5115201012 - Monday, 19 December 2016, 17:51
Anyone in the world

Sebuah perangkat lunak dibuat atau dikembangkan untuk membantu aktivitas manusia. Dalam proses pembuatan atau pengembangan perangkat lunak terdapat beberapa tahapan yang harus dilalui, salah satunya adalah tahapan analisis. Tahapan ini merupakan tahapan awal yang dilakukan oleh pengembang perangkat lunak selama proses pengembangan berlangsung. Dalam tahapan ini, pengembang harus mengetahui kebutuhan-kebutuhan dari perangkat lunak yang akan dikembangkan. Kebutuhan perangkat lunak berkaitan dengan elisitasi, analisis, spesifikasi, validasi dan pengelolaan kebutuhan perangkat lunak secara kesuluruhan selama siklus hidup perangkat lunak. Kebutuhan perangkat lunak juga mencakup kebutuhan dan batasan terhadap suatu produk perangkat lunak yang dikembangkan agar dapat secara optimal dalam membantu memenuhi kebutuhan manusia dalam menghadapi permasalahan di kehidupan nyata.

Software Requirements Fundamental :

Dalam fundamental kebutuhan perangkat lunak, yang terpernting adalah tahapan verifikasi kebutuhan. Alasannya adalah dalam tahap pengujian kualitas perangkat lunak harus dapat diverifikasi dengan sumber daya yang tersedia untuk mengetahui kesesuaiannya. Dalam perangkat lunak terdapat beberapa macam kebutuhan yang harus dipahami. Kebutuhan fungsional menggambarkan fungsi perangkat lunak yang dapat dieksekusi atau  lebih dikenal sebagai fitur pada perangkat lunak. Jadi kebutuhan fungsional merupakan fitur atau layanan yang harus didefinisikan dan juga dapat berinteraksi secara langsung dengan pengguna perangkat lunak. Dalam skala proyek yang besar dan kompleks, untuk dapat mencapai pendefinisian yang benar memiliki sedikit kemungkinan. Alasannya adalah sering terjadi kelalaian dalam membuat spesifikasi yang kompleks. Sedangkan kebutuhan nonfungsional merupakan kebutuhan kualitas atau kebutuhanyang tidak secara langsungberkaitan denganlayanan pada sistem untukpenggunanya, misalnya kebutuhan kinerja, kebutuhan pemeliharaan, kebutuhan keselamatan, kebutuhan keandalan, kebutuhan keamanan, kebutuhan interoperabilitas.

Ada juga kebutuhan produk dan kebutuhan sistem. Kebutuhan produk merupakan batasan pada perangkat lunak yang akan dikembangkan, misalnya perangkat lunak yang  memverifikasi bahwa seorang siswa telah memenuhi semua persyaratan sebelum dia mendaftar kursus. Sedangkan kebutuhan sistem adalah kebutuhan sistem secara keseluruhan yang mencakup kebutuhan pengguna, kebutuhan para stakeholder lainnya (seperti peraturan otoritas).

Associated Kursus: KI142303BKI142303B
 
Gambar dari Rahmi Rizkiana Putri 5115201012
by Rahmi Rizkiana Putri 5115201012 - Monday, 19 December 2016, 17:49
Anyone in the world

Software refactoring is the process of applying changes to the internal structure of software without changing its observable behavio. Improving a computer program by reorganising its internal structure without altering its external behaviour.  When software developers add new features to a program, the code degrades because the original program was not designed with the extra features in mind.  This problem could be solved by either rewriting the existing code or working around the problems which arise when adding the new features. Redesigning a program is extra work, but not doing so would create a program which is more complicated than it needs to be. Refactoring is a collection of techniques which have been designed to provide an alternative to the two situations mentioned above. The techniques enable programmers to restructure code so that the design of a program is clearer. It also allows programmers to extract reusable components, streamline a program, and make additions to the program easier to implement.  Refactoring is usually done by renaming methods, moving fields from one class to another, and moving code into a separate method.  Although it is done using small and simple steps, refactoring a program will vastly improve its design and structure, making it easier to maintain and leading to more robust code.

Before a refactoring project is actually started, an assessment and an in-depth analysis are made which result in a list of findings. Ideally, these findings will be translated into a master plan, which defines WHAT should be refactored. This master plan helps to keep the overall picture of the refactoring project in mind and to divide it into several sub-projects or refactoring parts. Once the master plan is defined we use an iterative approach to tackle the individual refactoring steps. 

Refactoring, which is one of the techniques to keep software maintainable. Function the refactoring is modification of code so as to improve internal structure and preserve external functionality. Refactoring is a technique that makes the source code of the software easier, more readable, and more understandable by eliminating the bad smells from the source code. Refactoring has a two kinds of techniques, source code refactoring and non source code refactoring. Source code refactoring identified bad smell in code. Bad smell likely mean should change the source code. For example, a characteristic of a design that is a strong indicator it has poor structure and should be refactored. We discussed in this paper, which good techniques for refactoring in bad code smell. Especially bad code smell for object oriented refactoring, Java programming.  Therefore object oriented refactoring has some kind technique to eliminating bad smell. So, we should to know how to identified which is good technique for bad smell object oriented refactoring.

Associated Kursus: KI142303BKI142303B
 
Gambar dari Rahmi Rizkiana Putri 5115201012
by Rahmi Rizkiana Putri 5115201012 - Monday, 19 December 2016, 17:48
Anyone in the world

Sofware Quality - Definition IEEE

1. The degree to which a system, component, or process meets specified requirements.

2. The degree to which a system, component, or process meets customer or user needs or expectations.

 

1. Classification of the causes of software errors :

    - software errors are the cause of poor software quality

    - software errors can be : code error, documentation error, software data error

    - the cause of all these errors are human.

2. The nine causes of software errors :

    - faulty requirement definition

    - client - developer communication failures

    - deliberate deviation from SW requirements

    - logical design errors

    - non-compliance with documentation and coding instruction

    - shortcomings of the testing process

    - procedure errors

    - docmentation errors

3. Faulty requirement definition :

    - erroneous definition of requirements

    - absence of vital requirements

    - incomplete definition of requirements

    - inclusion of unnecessary requirements

 

Associated Kursus: KI142303BKI142303B
 
Anyone in the world

RPL yang sukses membutuhkan kemampuan :

  • Komputasi seperti algoritma, pemrograman, dan basis data yang kuat
  • Penentuan tujuan yang baik
  • Identifikasi cara penyelesaian
  • Metode pengembangan, urutan aktifitas, identifikasi kebutuhan sumber daya

Model Pengembangan Perangkat Lunak :

  • Waterfall Model
  • Jpint Application Development ( JAD )
  • Information Engineering ( IE )
  • Rapid Application Development ( RAD )
  • Unified Process ( UP ) termasuk di dalamnya Prototyping
  • Structural Analysis and Design ( SAD )
  • Framework for the Application of System thinking ( FAST )

Tahapan Rekayasa Perangkat Lunak :

  • Pola tahapan analysis
  • design
  • coding
  • testing 
  • maintenance
Associated Kursus: KI142303BKI142303B
 
Halaman: () 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ... 39 ()