Kamis, 13 Desember 2018

Life Cycle Software

Penjelasan Tentang Model Life Cycle Software

Model Pada Life Cycle Software

Model siklus pada perangkat lunak sebenarnya sangatlah banyak, namun disini saya akan menjelaskan beberapa saja diantaranta model Waterfall, V-model, Simple Interaction Desaign Model, Star Lifecycle Model. Berikut penjelasan dari masing-masing model yang akan di jelaskan secara berurutan.

1. Model Waterfall

Model waterfall dulu dikenal dengan nama “Linear Sequential Model” merupakan model tertua dan paling handal dan sering dikenal sebagai “classic life cycle”. Model ini pertama kali diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi model tersebut merupakan model yang paling banyak dipakai didalam Software Engineering (SE).

Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematik dan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini melingkupi aktivitas-aktivitas sebagai berikut yaitu; rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, pengujian dan pemeliharaan.

Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.

berikut adalah gambar tahap-tahap pengembangan software menggunakan model waterfall :



Berikut ini adalah penjelasan dari masing-masing tahapan yang terdapat pada model waterfall :

System Engineering :
Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Tahap ini sering disebut dengan Project Definition.
Analysis 
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.
Design 
Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk“blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya.
Coding : 
Untuk dapat dimengerti oleh mesin, maka design yang ada di komputer tadi harus diubah bentuknya menjadi ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
Testing : 
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. Begitu saoftware berjalan dengan sempurna dan sesuai dengan kebutuhan maka akan diimplementasikan.
Maintenance : 
Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.Keuntungan model waterfall :
Merupakan model pengembangan paling handal dan paling lama digunakan.
Cocok untuk system software berskala besar.
Cocok untuk system software yang bersifat generic.
Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.Kelemahan model waterfall :
Waktu pengembangan lama. hal ini dikarenakan input tahap berikutnya adalah output dari tahap sebelumnya.
Biaya mahal, hal ini juga dikarenakan waktu pengembangan yang lama.
Terkadang perangkat lunak yang dihasilkan tidak akan digunakan karena sudah tidak sesuai dengan requirement bisnis customer. hal ini juga dikarenakan waktu pengembangan yang lama. selain itu dikarenakan waterfall merupakan aliran yang linear, sehingga jika requirement berubah proses tidak dapat diulang lagi.
Karena tahap-tahapan pada waterfall tidak dapat berulang, maka model ini tidak cocok untuk pemodelan pengembangan sebuah proyek yang memiliki kompleksitas tinggi.
Meskipun waterfall memiliki banyak kelemahan yang dinilai cukup fatal, namun model ini merupakan dasar bagi model-model lain yang dikembangkan setelahnya.

2. V-Model


V-Model merupakan pengembangan dari model Waterfall. V-Model merupakan kepanjangan dari Validasi/ Verivikasi Model.V-model pertama kali diusulkan oleh Paul Rook pada tahun 1980 dan dikenal dengan nama V-Model tradisional. V-model mendemonstrasikan hubungan antara proses pembangunan sistem (development activities) dan proses pengujian system (testing activities). Berbeda dengan pemodelan lainnya, dalam pemodelan V-Model proses pengujian jauh lebih kompleks karena dibagi menjadi beberapa bagian yang lebih detail. Proses pengembangan sistem meliputi requirement analysis, requirements specification, design specification, dan program specification. Sedangkan dalam proses pengujian meliputi acceptance testing, system testing, integration testing, dan units testing. Diantara develompment activities dan testing activities terdapat proses penulisan kode. Alur tahapan pada V-Model dapat dilihat pada gambar dibawah ini :




Penjelasan dari berbagai tahapan V-Model sebagai berikut :

Requirement & Acceptance Testing.
Requirement Analysis adalah 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.
General Design Specification & Component 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.
Detailed Design Specification & Unit testing. Dalam Tahapan ini, 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.
Source Code/Coding.
Ini merupakan tahap paling bawah pada V-Model sehingga merupakan tahapan yang terpenting. Tahapan ini berfungsi mengubah modul-modul desain yang telah dilakukan pada tahapan sebelumnya kedalam bentuk bahasa yang di mengerti oleh komputer (melakukan pengkodingan) hal ini dilakukan oleh pihak pengembang.

Keuntungan V-Model :

Sederhana dan mudah digunakan.
Pengujian aktivitas seperti perencanaan, pengujian perancangan terjadi sebelum coding sehingga menghemat banyak waktu. Maka memiliki keberhasilan yang lebih tinggi dari model waterfall.
Jika perubahan terjadi perubahan, maka proses requirement dapat diperbarui.
Bekerja dengan baik untuk proyek-proyek kecil di mana persyaratan mudah dipahami.
Meminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnya Penyesuaian yang cepat pada projek yang baru Memudahkan dalam pembuatan dokumen projek Biaya yang murah dalam perawatan dan modifikasinya V-Model sangat fleksibel.
V-Model mendukung project tailoring dan penambahan dan pengurangan method dan tool secara dinamis. 
User dari V-Model berpartisipasi dalam change control board yang memproses semua change request terhadap V-Model.

Kelemahan V-Model :

Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi.
Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.
Metode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik.
Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “ software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT ”.
V-Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
V-Model terlalu fleksibel dalam arti ada beberapa activity dalam V-Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.

3. Simple Interaction Design Model

Simple interaction design model merupakan sebuah model pengembangan software yang sederhana. Karakteristik dari model Simple interaction design adalah proses interactive design secara ekplesit antara penggabungan dari keterlibatan pengguna, iterasi, kriteria usability tertentu. Berikut ini merupakan gambar tahapan dari model Simple interaction design :

Penjelasan dari berbagai tahapan yang terdapat pada model Simple interaction design :


Identify needs/Establish requirement : 
pada tahap ini, kita menerima masukkan dari satu titik, lalu di identifikasi apa saja kebutuhannya dan apakah sesuai dengan kebutuhannya. Sebelum menetapkan Establish requirement ada beberapa hal yang harus dipahami yaitu siapa penggunanya, dan apa tujuan yang mereka inginkan ketika menggunakan software yang akan rancang/dikembangkan ini.
Design/(Re) Design : 
pada tahap ini dilakukan desain dan alternatif desain software dari kebutuhan yang diperlukan dan sesuai dengan persyaratan yang ditetapkan (dapat dengan meilhat desain orang lain sebagai referensi yang berguna). sedangkan Redesign adalah melakukan desain ulang dikarenakan hasil sebelumnya tidak sesuai dengan kebutuhan atau tidak sesuai dengan hasil evaluasi akhir.
Build interactive versions : 
tahapan ini membuat sebuah prototype desain interaktif yang mana dapat memiliki fungsi terbatas. Sehingga penggembang dapat berkomunikasi dengan pengguna dengan mengujicobakannya. Jika terdapat design yang memiliki kesalahan/kekurangan/belum ada maka proses akan kembali ketahapan Redesign.
Evaluate : 
tahapan ini, tahapan dimana pengguna mengevaluasi terhadap software yang telah di buat. Jika terdapat kekeliruan dari segi design maka tahapan akan kembali kepada tahap Redesign. Jika kesalahan terjadi karena kesalahan identifikasi kebutuhan maka akan kembali ketahapan Identify needs/Establish requirements. Jika telah sesuai kebutuhan pengguna maka ini akan menjadi final project.
Jika dilihat dari tahapan diatas, maka dapat disimpulkan bahwa model Simple interaction design memiliki 3 (tiga) prinsip yaitu :
Melibatkan pengguna pada proses design dan evaluation.
Tentukan kriteria dari quantifiable & measurable usability.
Akan terjadinya iterasi yang tidak dapat di hindari.

4. Star Lifecycle Model (Hartson & Hix, 1989)

Model Star life cycle diusulkan oleh Harton dan Hix di akhir 1980-an, sebagai hasil pengamatan yang luas dari pengembang di lingkungan real-time (Helms 2001).
Model ini merupakan model yang bersifat elastis tidak seperti model waterfall yang bersifat sangat kaku. Model Star life cycle memiliki karakteristik yaitu melakukan pengujian secara terus-menerus, hal ini disebabkan karena semua tahapan selalu di lakukan evaluasi. Berikut ini gambaran dari tahapan model Star life cycle :


Dapat dilihat di setiap tahapan memiliki input dari luar (dari berbagai sumber) untuk dilakukan kegiatan sesuai dengan tahapan yang bersangkutan lalu dilakukan evaluasi. Berikut ini merupakan penjelasan dari setiap tahapan yang terdapat pada model Star life cycle :

Task analysis/Functional analysis : 
tahapan ini, akan melakukan functional analysis dari input yang di berikan yang kemudian akan dilakukan evaluation. 
Requrements/Specification 
tahapan ini, akan mengumpulkan informasi terkait dengan kebutuhan dan segala sesuatu yang bersangkutan dengan software yang akan dikembangkan, lalu dilakukan tahapan evaluation.
Conceptual design/Formal design representation : 
tahapan ini akan mendesain sebuah desain konseptual dari software yang akan dikembangkan bersadarkan semua inputan yang masuk ketahapan ini. Kemudian dilakukan tahapan evaluation.
Prototyping : 
Sama halnya seperti tahapan pada Simple interaction design model. dimana prototype merupakan desain interaktif yang memiliki fungsi terbatas yang akan di ujicobakan kepada pengguna lalu melakukan tahap evaluation.
Implementation 
tahapan ini merupakan tahapan dimana software diimplementasikan dan digunakan oleh pengguna lalu dilakukannya tahap evaluation.
Evaluation : 
tahapan ini adalah melakukan evaluasi terhadap setiap tahapan yang menggunakan tahapan ini untuk melihat apakah hal yang dilakukan pada tahapan sebelumnya telah sesuai dengan kebutuhan terbaru dari pengguna lalu memberikan feedback terhadap tahapan sebelumnya.



References :
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjz5u-F7LE0jfCbD5GMQQg_MQSsQiac5gs49D-INbckQcu3F-8F5N2HfPQX_El4LVUMaIymmKeXSMtZDqimTTB5jhE4WpMpjtFwB3QVwpg79fOOohr9zFQdmWJL_pqpK4TgcYlP0V3fD4nq/s1600/Star+Lifecyucle+Model_2.png
https://i2.wp.com/s3.amazonaws.com/production-wordpress-assets/blog/wp-content/uploads/2016/12/08151155/waterfall-model.png?fit=604%2C270&ssl=1
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMm5At1jX2uz70CE1eVjJK1cL0ph_FAs2oflnahpw266wsEdYRDaTleOh9Yy5-YAEcaFHH6Dy4fc_6AtDCKr-bfonSMjuo0QDamiSKuvJ7EAWUCLQJfrYLxJ3R-st9TR3q5gorqzCI7Ls/s1600/simple+interaction+dsgn+lenpyo+nyuss.jpg


Rabu, 12 Desember 2018

Standard Proses UCD Untuk Sistem Interaktif

Proses User Centered Design (UCD) Menurut ISO



Berikut ini penjelasan dari proses UCD diatas : 

Plans for human-centered design 

Rencana perancangan adalah dokumen kerja yang pada awalnya dibuat dalam bentuk outline yang selanjutnya ditinjau kembali, dipelihara, dikembangkan, dan diperbarui selama proses perancangan dan pengembangan. Langkah awal ini membutuhkan komitmen dari seluruh pihak yang terlibat dalam proses pengembangan dengan metode UCD, dan untuk membuat rencana perancangan dengan cukup waktu dan kesempatan yang digunakan dalam mendapatan user requirements dan pengujiannya serta aspek teknis lain dalam pengembangan.


Understand and specify the context of use

Mutu kegunaan dari sistem tergantung dari pemahaman dan perencanaan dari karakteristik pemakai, tugas-tugas, lingkungan fisik dan organisasi dimana sistem akan digunakan. Sangatlah penting untuk mengerti dan mengidentifikasi dari konteks ini dalam memandu keputusan awal desain, dan menyediakan dasar untuk menerapkan konteks dimana usabilitas harus dievaluasi.
Pada tahap ini sistem ditingkatkan dan diperluas. Untuk sistem yang sudah berjalan, umpan balik dari pemakai dan laporan help desk akan menjadi dasar prioritas kebutuhan pemakai untuk modifikasi dan perubahan sistem. Untuk produk atau sistem baru sangat penting untuk mengambil informasi tentang konteks kegunaan melalui pertemuan dan wawancara. 
Identifikasi orang-orang yang akan menggunakan produk tersebut, untuk apa yang akan mereka gunakan, dan dalam kondisi apa mereka akan menggunakannya. Konteks dari sistem yang digunakan akan mengidentifikasikan:
  • Karakteristik pengguna yang diharapkan 
  • Pekerjaan yang akan dilakukan pengguna
  • Pemecahan secara hirarki atas pekerjaan global 
  • Tujuan global penggunaan sistem untuk setiap kategori pengguna, termasuk karakteristik tugas yang mungkin menggangu penggunaan dalam skenario khusus, seperti frekuensi dan lama kinerja
  • Deskripsi harus mencakup alokasi aktivitas dan langkah operasional antara manusia dan sumber daya teknologi. Tugas ini tidak boleh digambarkan hanya dalam bentuk fungsi atau sifat yang disediakan sistem
  • Seluruh sasaran kegunaan dari sistem untuk setiap kategori pemakai. Seperti karakteristik-karakteristik yang dapat mempengarruhi tugas dalam skenario khusus
  • Pahami lingkungan tempat pengguna akan menggunakan system
  • Sangat penting langkah awal untuk menentukan kebutuhan sistem minimal dan optimal dengan memperhatikan user-test dalam lingkungan tersebut sebelum dilepaskan. Perlu juga diperhatikan karakteristik yang relevan dengan lingkungan fisik dan sosial


Specify the user and organizational requirements  

Pada hampir semua model pengembangan software, terhadap aktivitas utama dimana kebutuhan fungsional produk atau sistem ditentukan. Dalam UCD penting untuk memperluas aktivitas kebutuhan fungsional sistem dengan membuat pernyataan eksplisit kebutuhan pengguna dan organisasi. Identifikasi kebutuhan bisnis atau tujuan pengguna yang harus dipenuhi produk untuk menjadi sukses. Berikut ini kaitannya dengan context of use :
  • Kualitas perancangan interaksi manusia dan komputer serta workstation
  • Kualitas dan isi tugas pengguna (termasuk alokasi tugas diantara kategori penguna yang berbeda). Misalnya, apakah operator bertanggung jawab melakukan konfigurasi sistem seperti kenyamanan, keselamatan, kesehatan dan khususnya motivasi
  • Kinerja tugas yang efektif khususnya dalam hal transparansi aplikasi ke pengguna
  • Kerjasama dan komunikasi yang efektif diantara pengguna dan pihak ketiga yang relevan
  • Dibutuhkan kinerja sistem baru terhadap tujuan finansial


Produce design solutions

Tahapan berikutnya adalah membuat solusi desain yang potensial dengan menggambar atau mendesain bentuk dari pengalaman dan pengetahuan para partisipan. Ini bagian dari proses yang dilakukan secara bertahap, membangun dari konsep kasar untuk desain lengkap. Pada tahapan ini diberikan solusi yang dibutuhkan terhadap design yang telah dihasilkan.
  • Dengan menggunakan pengetahuan yang ada (standards, contohnya : petunjuk sistem, dll) untuk mengembangkan suatu solusi perancangan
  • Membuat solusi perancangan lebih konkrit ( misalnya dengan simulasi, prototipe, dll)
  • Memperlihatkan prototipe ke pengguna dan mengamatinya saat melakukan tugas spesifik, dengan atau tanpa bantuan evaluatur
  • Menggunakan umpan balik untuk perbaikan rancangan yang dibuat
  • Melakukan iterasi untuk mengulang proses ini sampai tujuan perancangan dipenuhi


Evaluate design against requirements

Tahapan ini merupakan tahapan evaluasi perancangan terhadap kebutuhan pengguna. Evaluasi adalah suatu tahap penting dalam UCD. Evaluasi idealnya dilakukan melalui pengujian kegunaan (usability testing) dengan pengguna yang sebenarnya adalah sebagai bagian yang tak terpisahkan untuk pengujian kualitas dalam pengembangan perangkat lunak yang baik. Ada dua jenis evaluasi perancangan, yaitu :
  • Formative, yakni menyediakan umpan balik yang dapat digunakan untuk memperbaiki rancangan.
  • Summative, yakni melakukan penilaian apakah tujuan pengguna dan organisasi telah tercapai
Apapun jenis evaluasi yang digunakan, penting untuk dipahami bahwa hasil evaluasi hanya bermakna dalam konteks dimana sistem diuji.
Pada tahapan ini juga memantau penggunaan produk atau sistem dalam jangka panjang dan melaporkan hasil evaluasi.

Referensi :

Life Cycle Software

Penjelasan Tentang Model Life Cycle Software Model Pada Life Cycle Software Model siklus pada perangkat lunak sebenarnya sangatlah bany...