Site blog

Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 42 ()
Gambar dari NAHYA NUR 5116201035
by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 14:39
Anyone in the world

Grey Box Testing adalah sebuah metodologi kombinasi dari Black Box dan White Box Testing, menguji software berdasarkan spesifikasi tetapi menggunakan cara kerja dari dalam. Grey Box dapat di gunakan dengan baik dalam software testing.

Grey box testing mengacu pada teknik pengujian sistem dengan pengetahuan yang terbatas (limited knowledge) dari internal sistem. Grey box testing memiliki akses ke desain dokumen dengan rinci melalui informasi di luar persyaratan dokumen. Grey box testing yang dihasilkan berdasarkan informasi tersebut sebagai state-based models atau architecture diagrams of the target system.

Menurut Saleh (2009, p225) grey box mengasumsikan bahwa arsitektur software dan dokumentasi desain tersedia untuk tester. Grey box juga berdasarkan design document dan functional specifications. Dari beberapa definisi tersebut, dapat disimpulkan bahwa grey box testing adalah teknik pengujian sistem dengan pengetahuan yang terbatas (limited knowledge) dari internal sistem yang memiliki akses ke dokumen desain rinci. Pengujian grey box juga berdasarkan design document dan functional specifications dari suatu sistem.

 

Grey Box Testing biasa di gunakan pada software berorientasi object, dimana object – object tersebut adalah unit terpisah yang memiliki kode eksekusi atau data. Contoh aplikasi yang membutuhkan Grey Box Testing :

  • Architectural model
  • Unified Modeling Language – UML Design Model
  • Finite-state machine – State Model.

 

Teknik yang ada ada Grey Box Testing :

  • Matrix Testing: menyatakan laporan atau status proyek
  • Regression testing: menyatakan status apakah terjadi perubahan pada kasus uji yang baru dibuat.
  • Pattern Testing: memverifikasi aplikasi yang baik untuk desain atau arsitektur dan pola.
  • Orthogonal array testing: digunakan sebagai bagian dari semua kemungkinan kombinasi.

 

Efek penggunaan Grey Box Testing :

Efek Positif

  • Offers combined benefits : Mengambil kelebihan dari 2 kombinasi testing dan melakukan percobaan terhadap testing.
  • Non Intrusive : Hal ini didasarkan pada spesifikasi fungsional, tampilan arsitektur.
  • Intelligent Test Authoring : Grey Box Testing menangani scenario uji coba, misalnya tipe data, protocol komunikasi, dan penanganan eksepsi.
  • Unbiased Testing : terlepas dari semua keuntungan diatas, Grey Box Testing mempertahankan batas terhadapa pengujian Antara tester dan developer.

Efek Negatif

  • Partial Code Coverage : Dalam pengujian Grey Box, sumber kode dan binary akan hilang karenga akses yang terbatas pada struktur internal atau aplikasi akan menghasilkan akses terbats terhadap kode path traversal.
  • Defect Identification : Dalam aplikasi terdistribusi, sulit untuk mengidetifikasi cacat atau bug. Namun, pengujian di grey box dapat mengetahui bagaimana system cacat dalam lingkungan layana web.

 

Aplikasi

  • Pengujian Grey Box ini cocok untuk Aplikasi WEB. Aplikasi Web telah didistribuasikan jaringan atau system, karena tidak adanya sumber kode atau binary, tidak mungkin untuk menggunakan pengujian, white-box. Pengujian Black-box juga tidak digunakan karena hanya melakukan kontrak Antara pelanggan dan pengembang, sehinggal lebih efisien menggunakan Grey-box testing sebagai informasi penting yang tersedia dalam Web Service Definition Language (WSDL).
  • Pengujian Grey Box cocok untuk pengujian fungisonal atau domain bisnis. Pengujian fungsional dilakaukan pada dasarnya tes interaksi pengguna dengan system. Ini juga membantu untuk mengkonfirmasi software yangn memenuhi persyaratan yang di tetapkan untuk perangkat lunak.

 

Referensi

https://wirasetiawan29.wordpress.com/2014/04/04/gray-box-testing/

Associated Kursus: KI142303BKI142303B
 
Gambar dari NAHYA NUR 5116201035
by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 14:38
Anyone in the world

Pengujian white box adalah pengujian yang didasarkan pada pengecekan terhadap detail perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.

 

Penggunaan metode pengujian white box dilakukan untuk :

  • Memberikan jaminan bahwa semua jalur independen suatu modul digunakan minimal satu kali
  • Menggunakan semua keputusan logis untuk semua kondisi true atau false
  • Mengeksekusi semua perulangan pada batasan nilai dan operasional pada setiap kondisi.
  • Menggunakan struktur data internal untuk menjamin validitas jalur keputusan.

 

Persyaratan dalam menjalankan strategi White Box Testing

  • Mendefinisikan semua alur logika
  • Membangun kasus untuk digunakan dalam pengujian
  • Mengevaluasi semua hasil pengujian
  • Melakukan pengujian secara menyeluruh

 

Pengujian White Box Testing

Pengujian ke white box testing adalah menguji yang di dasarkan kepada pengecekkan ke dalam detail rancangan, penggunaan yang di lakukan struktur control dari suatu desain pemograman untuk dapat membagi pengujian ke beberapa kasus pengujian. Dan di dapat bahwasanya white box testing menggungakan petunjuk untuk menghasilkan program yang di harapkan dan efisien.

 

Metode pengujian pada white box testing ini sering di lakukan untuk

  • Memberikan dan membuat suatu jaminan bahwa seluruh jalur-jalur yang independen hanya menggunakan modul minimal satu kali.
  • Keputusan yang sifatnya logis dapat di gunakan di semua kondisi true (benar) atau false (salah).
  • Mengeksekusi seluruh perulangan yang ada ke pada batas nilai dan operasional di setiap situasi dan kondisi.

 

Kelebihan Yang Terdapat Di White Box Testing

  • Kesalahan Logika

Menggunakan sintax ‘if’ dan sintax pengulangan. Dan langkah selanjutnya metode white box testing ini akan mencari dan mendeteksi segala kondisi yang di percaya tidak sesuai dan mencari kapan suatu proses perulangan di akhiri.

  • Ketidaksesuaian Asumsi

Menampilkan dan memonitori beberapa asumsi yang di yakini tidak sesuai dengan yang di harapkan atau yang akan di wujudkan, untuk selanjutnya akan di analisa kembalai dan kemudian di perbaiki.

  • Kesalahan Pengetikan

Mendeteksi dan mencarian bahasa-bahasa pemograman yang di anggap bersifat case sensitif.

 

Kelemahan White Box Testing

Pada perangkat lunak yang jenisnya besar, metode white box testing ini dianggap boros karena melibatkan banyak sumberdaya untuk melakukannya.

 

Referensi

http://www.dosenpendidikan.com/pegujian-dan-pengertian-white-box-testing/

http://universitaspendidikan.com/pengertian-white-box-dan-contoh-white-box-testing/

Associated Kursus: KI142303BKI142303B
 
Gambar dari NAHYA NUR 5116201035
by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 14:37
Anyone in the world

Black Box Testing adalah metode pengujian perangkat lunak yang tes fungsionalitasnya dari aplikasi yang bertentangan dengan struktur internal atau kerja. Pengetahuan khusus dari kode aplikasi / struktur internal dan pengetahuan pemrograman pada umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni, aplikasi apa yang seharusnya dilakukan.Menggunakan deskripsi eksternal perangkat lunak, termasuk spesifikasi, persyaratan, dan desain untuk menurunkan uji kasus. Tes ini dapat menjadi fungsional atau non-fungsional, meskipun biasanya fungsional. Perancang uji memilih input yang valid dan tidak valid dan menentukan output yang benar. Tidak ada pengetahuan tentang struktur internal benda uji itu.

 

Metode ujicoba blackbox memfokuskan pada keperluan fungsional dari software. Karna itu ujicoba blackbox memungkinkan pengembang software untuk membuat himpunan kondisi input yang akan melatih seluruh syarat-syarat fungsional suatu program. Ujicoba blackbox bukan merupakan alternatif dari ujicoba whitebox, tetapi merupakan pendekatan yang melengkapi untuk menemukan kesalahan lainnya, selain menggunakan metode whitebox. Ujicoba blackbox berusaha untuk menemukan kesalahan dalam beberapa kategori, diantaranya :

1. Fungsi-fungsi yang salah atau hilang

2. Kesalahan interface

3. Kesalahan dalam struktur data atau akses database eksternal

4. Kesalahan performa

5. kesalahan inisialisasi dan terminasi

 

Dekomposisi kebutuhan  untuk dites secara  sistematis  :

  • Untuk dapat membuat test cases  yang efektif, harus dilakukan dekomposisi dari tugas-tugas testing suatu sistem ke aktivitas-aktivitas yang lebih kecil dan dapat dimanajemeni, hingga tercapai test case individual.
  • Tentunya, dalam disain test case juga digunakan mekanisme untuk memastikan bahwa test case yang ada telah cukup mencakup semua aspek dari sistem.
  • Pendisainan test case dilakukan secara manual, tidak ada alat bantu otomasi guna menentukan test cases yang dibutuhkan oleh sistem, karena tiap sistem berbeda, dan alat bantu tes tak dapat mengetahui aturan benar-salah dari suatu operasi.
  • Desain tes membutuhkan pengalaman, penalaran dan intuisi dari seorang tester.

 

 

Referensi

http://www.kompasiana.com/elisa_grace_heriberty/blackbox-testing_550051c7a333115b735107db

https://ratz3x.wordpress.com/2012/12/11/testing-dan-implementasi-black-box-testing/

Associated Kursus: KI142303BKI142303B
 
Gambar dari NAHYA NUR 5116201035
by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 14:36
Anyone in the world

Kualitas merupakan salah satu factor utama yang menunjang suatu bisnis dimana ia dianggap sebagai pembeda yang khas dengan 2 kriterianya yakni :

  1. Kualitas harus terukur (mempunyai standar ukuran).
  2. Kualitas sebisa mungkin dapat diprediksikan.

Sedangkan software itu sendiri adalah komponen di dalam suatu computer berupa data elektronik, yang nantinya akan membantu kinerja dalam proses input output.

Jadi, pengertian dari software quality itu sendiri adalah bagaimana dan seperti apa  suatu software memiliki suatu kualitas (pembeda) sehingga nantinya software tersebut benar-benar useful dalam pengaplikasianya di setiap bidang,baik itu bisnis maupun organisasi lainnya. Dimana kualitas itu sendiri, bisa dipecah kembali ke beberapa bagian sesuai spesifikasi si software itu sendiri.

Mengapa kualitas itu penting? Kaitannya dengan konsumen, kualitas disini benar-benar menjadi sebuah permintaan yang juga menjadi sebuah ‘alat’ dalam mencapai sukses dan bisa survive dari pesaing yang ada. Karena sejatinya kualitas adalah kepuasan konsumen. Untuk itulah, kualitas haruslah direncanakan ke dalam suatu struktur projek, lalu secara konstan dievaluasi dan

Bila kualitas adalah suatu prioritas, maka disini kualitas dari sebuah software harus direncanakan dan dibuat ke dalam suatu project lalu kemudian diatur dan dilolah menjadi suatu produk dan dimonitor bukan hanya melalui taksiran tetapi juga melalui evaluasi dari hasil kombinasi antara interaksi atau hubugan timbal balik antara software dan produk yang ada.

Sebuah software memiliki karakteristik sebagai berikut :

  1. Software dikembangkan dan direncanakan dan software bukan merupakan hasil sebuah manufaktur klasik seperti biasanya,sehingga bisa digunakan untuk mempertahankan konsumen dan meningkatkan keuntugan perusahaan.
  2. Untuk itu,software haruslah berkualitas,karena kualitas itu adalah sebuah ‘hallmark’ dari sebuah bisnis secara global.

 

Software Quality Assurance

Tujuan dari software quality assurance adalah untuk memastikan bahwa software yang dibuat dapat memenuhi standar kwalitas sebuah software. Software Quality Assurance menyediakan ukuran-ukuran atau patokan-patokan yang didesain untuk memasatikan suatu software berjalan sesuai fungsinya secara konsisten dana modifikasi terhadap software tersebut tidak menghasilkan suatu masalah yang besar. Patokan tersebut harus dipakai sepanjang pengembangan software secara sistematik, mulai testing, dokumentasi, sampai eksekusi suatu software dan saat pemeliharaan software.

 

Alur dari software quality assurance adalah :

  1. Rencana atau rancangaan ditetapkan sesuai standar.
  2. Prosedur dilaksanakan sesuai rencana.
  3. Produk diimplementasikan menurut standar.

 

Referensi

https://riesrantydjangkaru.wordpress.com/2011/12/26/software-quality/

https://sqaindonesia.wordpress.com/2010/02/08/pentingnya-software-qualty-assurance/

Associated Kursus: KI142303BKI142303B
 
Gambar dari NAHYA NUR 5116201035
by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 12:20
Anyone in the world

Definisi

Prototyping perangkat lunak (software prototyping) atau siklus hidup menggunakan protoyping (life cycle using prototyping) adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model). Tujuannya adalah mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat daripada metode tradisional dan biayanya menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.

Dengan prototype yang terbuka, model sebuah sistem (atau bagiannya) dikembangkan secara cepat dan dipoles dalam diskusi yang berkali-kali dengan klien. Model tersebut menunjukkan kepada klien apa yang akan dilakukan oleh sistem, namun tidak didukung oleh rancangan desain struktur yang mendetil. Pada saat perancang dan klien melakukan percobaan dengan berbagai ide pada suatu model dan setuju dengan desain final, rancangan yang sesungguhnya dibuat tepat seperti model dengan kualitas yang lebih bagus.

Protoyping membantu dalam menemukan kebutuhan di tahap awal pengembangan, terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface – bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.

Tujuan konvensional prototipe adalah memungkinkan pengguna perangkat lunak untuk mengevaluasi pengembang ‘proposal untuk desain produk yang akhirnya dengan benar-benar mencoba mereka keluar, daripada harus menafsirkan dan mengevaluasi desain berdasarkan deskripsi. Prototyping juga dapat digunakan oleh pengguna akhir untuk menjelaskan dan membuktikan bahwa pengembang persyaratan tidak dianggap, jadi “mengendalikan prototipe” dapat menjadi faktor kunci dalam hubungan komersial antara penyedia solusi dan klien mereka.

 

Tahap

Setelah kebutuhan awal disetujui, lalu dianalisis dan dibagi menjadi area-area berbeda untuk menyediakan basis bagi prototipe awal dari berbagai bagian yang berbeda dari sistem; setiap prototipe didemonstrasikan kepada klien dan dipoles untuk memasukkan kebutuhan lebih banyak dan modifikasi. Siklus demonstrasi dan pemolesan berlanjut sampai klien dan pengembang merasa puas. Proses ini dilaksanakan untuk setiap bagian sistem. Prototipe final diintegrasikan dan sistem lengkap diuji dan akhirnya diserahkan kepada klien.

 

Jenis-jenis prototyping

Software prototipe memiliki banyak varian. Namun, semua metode-metode tersebut dalam beberapa cara yang didasarkan pada dua jenis utama prototyping:

  • throwaway Prototyping
  • Evolutionary Prototyping

 

Keunggulan prototyping :

  • Komunikasi akan terjalin baik antara pengembang dan pelanggan.
  • Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.
  • Pelanggan berperan aktif dalam proses pengembangan sistem.
  • Lebih menghemat waktu dalam pengembangan sistem.
  • Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

Kelemahan prototyping :

  • Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama.
  • Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan sebuah kerangka kerja(blueprint) dari sistem .
  • Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.

 

Referensi

https://id.wikipedia.org/wiki/Prototyping_perangkat_lunak

https://itcompro.wordpress.com/2009/09/09/software-prototyping/

http://hardlogicom.blog.widyatama.ac.id/2015/02/15/proses-rekayasa-perangkat-lunak-menggunakan-model-prototype/

Associated Kursus: KI142303BKI142303B
 
Gambar dari NAHYA NUR 5116201035
by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 12:18
Anyone in the world

Kelebihan dan kekurangan beberapa model proses dalam rekayasa perangkat lunak

A. Waterfalll model

Kelebihan Waterfall Model:

  1. Mudah diaplikasikan.
  2. Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan pemeliharaan.
  3. Cocok digunakan untuk produk software yang sudah jelas kebutuhannya di awal, sehingga minim kesalahannya.

 

Kekurangan Waterfall model:

  1. Waterfall model bersifat kaku sehingga Penanganan perubahan pada saat proses sedang berlangsung menjadi lebih sulit.
  2. Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses.
  3. Customer harus sabar untuk menanti produk selesai, karena dikerjakan tahap per tahap,menyelesaikan tahap awal baru bisa ke tahap selanjutnya.
  4. Perubahan ditengah-tengah pengerjaan produk akan membuat bingung team work yang sedang membuat produk.
  5. Adanya waktu menganggur bagi pengembang, karena harus menunggu anggota tim proyek lainnya menuntaskan pekerjaannya.
  6. Semua kebutuhan sudah terefenisi sejak awal dan Software yang diberikan adalah versi terakhir dari setiap tahap,

 

B. RUP

Kelebihan dari RUP

  1. Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
  2. Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
  3. Mendukung proses pengulangan dalam pengembangan software.
  4. Memungkinkan adanya penambahan-penambahan pada proses.
  5. Memungkinkan untuk secara sistematis mengontrol perubahan- perubahan yang terjadi pada software selama proses pengembangannya.

 

Kekurangan dari RUP

  1. Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yang berorientasi objek dengan berfokus pada UML (Unified Modeling Language).
  2. Membutuhkan waktu yang cukup lama dibandingkan XP dan Scrum.

 

C. Agile

Kelebihan dari agile

  1. Meningkatkan kepuasan kepada klien.
  2. Dapat melakukan review pelanggan mengenai software yang dibuat lebih awal.
  3. Pembangunan system dibuat lebih cepat.
  4. Mengurangi resiko kegagalan implementasi software dari segi non-teknis.
  5. Jika pada saat pembangunan system terjadi kegagalan kerugian dari segi materi relatif kecil.

 

Kekurangan dari agile

  1. Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
  2. Agile tidak akan berjalan dengan baik jika komitmen tim kurang.
  3. Tidak cocok dalam skala tim yang besar (>20 orang).
  4. Perkiraan waktu release dan harga perangkat lunak sulit ditentukan.

 

D. Spiral

Kelebihan model Spiral:

  1. Setiap tahap pengerjaan dibuat prototyping sehingga kekurangan dan apa yang diharapkan oleh client dapat diperjelas dan juga dapat menjadi acuan untuk client dalam mencari kekurangan kebutuhan.
  2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar.
  3. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.
  4. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses.
  5. Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan di dalam evolusi produk.
  6. Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya ke dalam kerangka kerja iteratif.
  7. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permaslahan yang serius.

 

Kekurangan model Spiral:

  1. Banyak konsumen (Client) tidak percaya bahwa pendekatan secara evolusioner dapat dikontrol oleh kedua pihak. Model spiral mempunyai resiko yang harus dipertimbangkan ulang oleh konsumen dan developer.
  2. Memerlukan tenaga ahli untuk memperkirakan resiko, dan harus mengandalkannya supaya sukses.
  3. Belum terbukti apakah metode ini cukup efisien karena usianya yang relatif baru.
  4. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika resiko mayor tidak ditemukan dan diatur.
  5. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolute.

 

Sumber:

http://www.markijar.com/2015/04/kelebihan-dan-kekurangan-model-proses.html

http://dennis-louis.blogspot.co.id/2014/01/kelebihan-dan-kekurangan-agile.html

Associated Kursus: KI142303BKI142303B
 
Gambar dari NAHYA NUR 5116201035
by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 12:15
Anyone in the world

Picture1RPL.png

Software Development Life Cycle (SDLC) merupakan pendekatan bertahap untuk melakukan analisa dan membangun rancangan sistem dengan menggunakan siklus yang spesifik terhadap kegiatan pengguna. Beberapa metode SDLC diantaranya waterfall, spiral, RUP, agile, dan sebagainya.

 

 Tahapan-tahapan yang terdapat pada proses SDLC

  1.  Requirement specification
  2. Design
  3. Coding
  4. Testing
  5. Deploy

 

 

Software Operation Life Cycle (SOLC) merupakan proses untuk memindahkan perangkat dari lingkungan development ke operation. Pada tahapan operation dan pada penggunaannya terdapat masalah, maka akan diambil tindakan berdasarkan klasifikasi masalah yang ada

 

  • Minor, Contohnya apabila terdapat bug pada perangkat lunak maka tindakan yang diambil adalah proses maintenance.
  • Mayor, Contohnya apabila terjadi perubahan proses bisnis, maka tindakan yang diambil adalah fisibility study. Fisibility study dilakukan untuk menentukan apakah perlu dilakukan proses development ulang terhadap perangkat lunak atau tetap menggunakan perangkat lunak yang ada. Jika perangkat lunak yang telah ada sudah cukup efektif dan tidak menimbulkan kerugian yang berarti maka perangkat lunak tersebut tetap digunakan (Not Go). Tetapi jika sebaliknya, artinya dengan mengubah perangkat lunak akan lebih menguntungkan dan memudahkan, maka perangkat lunak akan dikembalikan ke proses Development (Go).
Associated Kursus: KI142303BKI142303B
[ Mengubah: Thursday, 22 December 2016, 12:15 ]
 
Gambar dari NAHYA NUR 5116201035
by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 10:44
Anyone in the world

Picture1RPL.png

Software Development Life Cycle (SDLC) merupakan pendekatan bertahap untuk melakukan analisa dan membangun rancangan sistem dengan menggunakan siklus yang spesifik terhadap kegiatan pengguna. Beberapa metode SDLC diantaranya waterfall, spiral, RUP, agile, dan sebagainya.

 

 Tahapan-tahapan yang terdapat pada proses SDLC

  1.  Requirement specification
  2. Design
  3. Coding
  4. Testing
  5. Deploy

 

 

Software Operation Life Cycle (SOLC) merupakan proses untuk memindahkan perangkat dari lingkungan development ke operation. Pada tahapan operation dan pada penggunaannya terdapat masalah, maka akan diambil tindakan berdasarkan klasifikasi masalah yang ada

  • Minor, Contohnya apabila terdapat bug pada perangkat lunak maka tindakan yang diambil adalah proses maintenance.
  • Mayor, Contohnya apabila terjadi perubahan proses bisnis, maka tindakan yang diambil adalah fisibility study. Fisibility study dilakukan untuk menentukan apakah perlu dilakukan proses development ulang terhadap perangkat lunak atau tetap menggunakan perangkat lunak yang ada. Jika perangkat lunak yang telah ada sudah cukup efektif dan tidak menimbulkan kerugian yang berarti maka perangkat lunak tersebut tetap digunakan (Not Go). Tetapi jika sebaliknya, artinya dengan mengubah perangkat lunak akan lebih menguntungkan dan memudahkan, maka perangkat lunak akan dikembalikan ke proses Development (Go).
 
Gambar dari DIAN SEPTIANI SANTOSO 5116201029
by DIAN SEPTIANI SANTOSO 5116201029 - Thursday, 22 December 2016, 09:07
Anyone in the world

Dalam pengembangan system menggunakan SDLC ada beberapa cara untuk mengimplementasinya dengan metodologi yaitu waterfall model, prototype model, RAD(Rapid Application Development) model, ASD(Agile Software Development) model. Diantara keempat model tersebut waterfall, dan prototype adalah model yang paling sering digunakan dalam pengembangan system.

1.      Waterfall Model
Merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Roger S. Pressman memecah model ini menjadi 6 tahapan, yaitu :
a. Sistem modeling                                                              d.  Coding
b. Analisis kebutuhan software                                           e.  Testing
c. Desain                                                                             f.  Maintenance
Keuntungan menggunakan teknik waterfall:
- Proses menjadi teratur
- Jadwal menjadi lebih menentu
Kelemahan menggunakan teknik waterfall:
- Membutuhkan daftar kebutuhan yang lengkap di awal, tapi jarang konsumen bisa memberikan             kebutuhan secara lengkap diawal
 
2.      Prototype
Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponen-komponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual dilakukan (Howard, 1997). Beberapa model prototype adalah sebagai berikut :
- Reusable prototype : Prototype yang akan ditransformasikan menjadi produk final.
- Throwaway prototype : Prototype yang akan dibuang begitu selesai menjalankan maksudnya.
- Input/output prototype : Prototype yang terbatas pada antar muka pengguna (user interface).
- Processing prototype : Prototype yang meliputi perawatan file dasar dan proses-proses transaksi
- System prototype : Prototype yang berupa model lengkap dari perangkat lunak.
 
Proses pada model prototyping adalah sebagai berikut :
- Pengumpulan kebutuhan
- Perancangan
- Evaluasi prototype
 
 Keuntungan menggunakan prototype model, yaitu :
    - Prototyping adalah model aktif, tidak pasif, sehingga end user dapat melihat, merasakan, dan                      mengalaminya.
    - Kesalahan yang terjadi dalam prototyping dapat dideteksi lebih dini.
 Kekurangan menggunakan prototype model, yaitu :
     - Prototyping tidak menolak kebutuhan dari fase analisis sistem. Prototype hanya dapat memecahkan           masalah yang salah dan memberi kesempatan sebagai sistem pengembangan konvensional.
     - Prototyping dapat mengurangi kreatifitas perancangan.
 
3.      RAD (Rapid Application Development)
Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction.
 
4.      Agile Software Development
Agile merupakan adalah jenis pegembangan sistem jangka pendek yang memerlukan adaptasi cepat dan pengembang terhadap perubahan dalam bentuk apapun. Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Agile juga dapat diartikan sebagai sekelompok metodologi pengembangan software yang didasarkan pada prinsip-prinsip yang sama atau pengembangan system jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun.
 
sumber :
http://glhmlyn.blogspot.co.id/2014/09/apa-itu-sdlc_25.html
 
Associated Kursus: KI142303KI142303
 
Gambar dari DIAN SEPTIANI SANTOSO 5116201029
by DIAN SEPTIANI SANTOSO 5116201029 - Thursday, 22 December 2016, 09:06
Anyone in the world

Menurut sommerville[1] requirement adalah spesifikasi dari apa yang harus diimplementasikan, deskripsi bagaimana sistem harusnya berkerja atau bagian-bagian yang ada didalam sistem, bisa juga dijadikan batasan dalam proses pengembangan sistem.

Ada beberapa macam requirement menurut sommerville [1] yaitu:

a.       User Requirement (kebutuhan pengguna)

Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan  perasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

b.      System requirement (kebutuhan system)

Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

c.       Software design specification ( spesifikasi rancangan perangkat lunak)

Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

Tujuan dari fase analisis adalah memahami dengan sebenar-benarnya kebutuhan dari sistem baru dan mengembangkan sebuah sistem yang mewadahi requirement tersebut-atau memutuskan bahwa sebenarnya pengembangan sistem baru tidak dibutuhkan. Penentuan kebutuhan sistem merupakan langkah yang paling crucial dalam tahapan SDLC. Kebutuhan Sistem bisa diartikan sebagai berikut: a. Pernyataan tentang apa yang harus dikerjakan oleh sistem b. Pernyataan tentang karakteristik yang harus dimiliki sistem.

Tipe-tipe Kebutuhan Sistem Untuk mempermudah system analis menentukan keseluruhan requirement secara lengkap, maka analis membagi kebutuhan sistem ke dalam 2 jenis yaitu :

A. Kebutuhan Fungsional (Functional requirement) : Kebutuhan fungsional adalah jenis kebutuhan yang berisi proses-proses apa saja yang nantinya dilakukan oleh system. Kebutuhan fungsional juga berisi informasi-informasi apa saja yang harus ada dan dihasilkan oleh sistem.

B. Kebutuhan Non fungsional(Nonfunctional Requirements) :Requirement jenis ini adalah tipe requirement yang berisi properti perilaku yang dimiliki oleh sistem, meliputi:

  • Operasional Pada bagian ini harus dijelaskan teknis bagaimana system baru akan beroperasi.
  • Platform sistem yang dipakai didefinisikan, apakah menggunakan windows atau Linux misalnya.
  • Software untuk mengembangkan sistem juga ditentukan.
  • Hardware spesifik yang diperlukan juga ditentukan.
  • Arsitektur sistem juga dijelaskan apakah 2-tier, 3 –tier atau yang lainnya

 

sumber :

http://indrakharisma.blog.unair.ac.id/2008/09/17/system-requirement/

http://free-materi.blogspot.co.id/2010/10/system-requirement-kebutuhan-sistem.html

Associated Kursus: KI142303KI142303
 
Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 42 ()