Sabtu, 03 Desember 2022

3 contoh "latent defects

Unsafe acts (atau bisa disebut active failure) kini lebih dianggap para expert sebagai "konsekuensi" dari beberapa penyebab utama yang melatar belakanginya, dan bukan merupakan penyebab tunggal terjadinya suatu kecelakaan dalam suatu organisasi. James Reason (2016) menyatakan bahwa Organizational Accident terjadi dalam sistem kompleks yang memiliki berbagai safeguard yang bersifat teknis dan prosedural. Mereka muncul dari sebuah akumulasi situasi/kondisi berbahaya dari “delayed-action failure” yang terletak pada tingkat manajerial dan organisasi. Kondisi laten tersebut (atau kegagalan laten) diibaratkan seperti patogen yang menetap di dalam sistem tubuh manusia. Kecelakaan organisasi dapat terjadi jika kondisi laten ini bergabung dengan active failure (error atau violation di bagian “sharp-end”) dan faktor pemicu lokal untuk menembus atau melewati sistem lapisan pertahanan. Untuk memperjelas bagaimana suatu kecelakaan itu dapat terjadi pada sebuah organisasi, James Reason (2016) menjelaskan lebih lanjut mengenai model swiss chesse-nya sebagai berikut :


  • Urutan kecelakaan dimulai dengan adanya konsekuensi negatif dari proses organisasi (seperti : keputusan yang berkaitan dengan perencanaan, kebijakan, perancangan, pengelolaan, komunikasi, penyediaan anggaran, pemantauan, audit, dan sejenisnya). Faktor lain yang sangat berpengaruh adalah budaya keselamatan perusahaan.

  • Beberapa kondisi laten yang tercipta pada contoh di atas ditransmisikan sepanjang jalur departemen dan organisasi ke berbagai tempat kerja / kelompok kerja tertentu di mana mereka menunjukkan diri mereka sebagai “local factor” (Reason (2016) mendefinisikan ulang sebagai “error/violation-producing condition”). Local factor atau “error/violation-producing condition” merupakan situasi tertentu yang dapat meningkatkan kemungkinan terjadinya error atau violation, misalnya : beban kerja yang tinggi, tekanan waktu, tipe moral pekerja, keterampilan dan pengalaman yang tidak memadai, dan peralatan yang buruk, dll.)

  • Pada level individu di bagian “sharp-end”, kondisi laten lokal ini digabungkan dengan psychological error dan violation tendencies untuk menciptakan unsafe act. Walaupun sejatinya banyak unsafe act yang dilakukan, tetapi hanya sedikit dari unsafe act tersebut yang akan menembus lapisan pertahanan dan pengaman untuk menghasilkan suatu hasil yang buruk (baca: kecelakaan). Mengapa demikian? Karena suatu organisasi biasanya menerapkan multiple defence / safeguard untuk mencegah terjadinya kecelakaan.

  • Namun, fakta menyatakan bahwa fitur keselamatan yang direkayasa, standar, kontrol, prosedur, dan sejenisnya ternyata dapat menjadi tidak sempurna karena adanya kondisi laten serta kegagalan aktif (ditunjukkan oleh panah yang menghubungkan Organization dengan Defence). Apabila hal itu terpenuhi, maka terjadilah kecelakaan.
Kegagalan Aktif (Active Failure) dan Kondisi Laten (Latent Condition)

Oleh karena manusia yang merancang, membuat, mengoperasikan, memelihara, dan mengelola sistem teknologi yang kompleks, maka tidak mengherankan bila keputusan dan tindakan manusia itu sejatinya terlibat dalam terjadinya semua kecelakaan dalam sebuah organisasi. Manusia sendiri berkontribusi secara langsung terhadap terjadinya kecelakaan dengan melakukan unsafe act, yang mana dapat terpenuhi melalui 2 cara yaitu kesalahan (Error), dan pelanggaran (violation).

Error muncul dari masalah informasi dan terbagi dalam tiga kategori: skill-based slips and lapses, rule-based mistakes and knowledge-based mistakes. Violation muncul dari faktor motivasi dan terbagi dalam empat jenis: routine (or corner-cutting) violations, thrill-seeking or optimizing violations, necessary violations and exceptional violations. Karena tindakan manusia ini memiliki dampak langsung dan efeknya terjadi secara cepat terhadap terjadinya kecelakaan, sehingga dinamakan “Active Failure” (Kegagalan Aktif). Dijelaskan lebih lanjut, ternyata Active Failure ini bukan satu-satunya penyebab terjadinya kecelakaan. Active failure (unsafe act) saat ini lebih dilihat sebagai konsekuensi daripada sebagai penyebab utama / pemicu dalam terjadinya suatu kecelakaan.

Sedangkan lainnya, yaitu “Latent Condition” (Kondisi Laten), bagi organisasi diibaratkan seperti patogen yang menetap di tubuh manusia. Seperti halnya patogen, kondisi laten - seperti desain yang buruk, celah dalam pengawasan, cacat produksi yang tidak terdeteksi, kegagalan maintenance, prosedur yang tidak dapat dijalankan, otomatisasi yang tidak tepat, kekurangan pelatihan, peralatan yang kurang memadai - mungkin ada selama bertahun-tahun dalam sebuah operasi organisasi sebelum mereka bergabung dengan local factor dan active failure untuk menembus sistem lapisan pertahanan. Mereka muncul dari keputusan strategis dan tingkat atas lainnya yang dibuat oleh stakeholder, regulator, produsen, perancang, dan manajemen organisasi. Dampak dari keputusan ini menyebar ke seluruh organisasi, membentuk budaya perusahaan yang khas dan menciptakan error/violation-promoting condition di tingkat tempat kerja individu.



Jumat, 14 Oktober 2022

Sketsa konseptual dan cara kerja salah satu sistem Traffic Light

 Sketsa konseptual dan cara kerja salah satu sistem Traffic Light (Lampu Lalulintas)

  • NAMA: IRSA ZUARSA
  • NPM: 20316022
  • KELAS: TK 20A

Berbasis Sistem Automatics Traffic-Light Control System (ATCS)

Secara keseluruhan, cara kerja lampu lalu lintas didasari oleh sistem ATCS. Sistem inilah yang menentukan berapa lama sebuah lampu hijau menyala. Lamanya nyala lampu hijau itu didasarkan pada kepadatan kendaraan yang terjadi saat itu.

Dilengkapi Bantuan Kamera Berbasis Mikrokontroler

Sistem yang ada pada lampu lalu lintas tak akan berfungsi maksimal bila tak ada kamera berbasis mikrokontroler. Kamera itulah yang membantu ATCS dan lampu lalu lintas untuk melihat sejauh mana kepadatan kendaraan di jalan raya.

Hasil tangkapan kamera itu nantinya akan diolah oleh komputer. Lalu, komputer bakal menghitung berapa persentase kepadatan yang terjadi di jalan raya saat itu. Nantinya, komputer akan menentukan berapa lama lampu hijau mesti menyala di suatu jalan raya.

Setelah itu, lampu lalu lintas akan mengalami pergantian nyala sesuai dengan waktu yang ditentukan komputer. Dimulai dari lampu hijau, kuning, dan diakhiri oleh lampu merah.

 Sejarah Singkat Lampu Lalu Lintas

Kehadiran lampu lalu lintas masih ada hubungannya dengan sejarah kendaraan bermotor itu sendiri. Lampu lalu lintas pertama sendiri pertama kali dibuat pada 1868 di London.

Pembuatan lampu lalu lintas itu dibuat lantaran saat itu kendaraan bermotor sudah mulai banyak. Lampu lalu lintasnya sendiri saat itu masih dua buah, yaitu merah dan hijau.

Tiga tahun setelahnya, lampu lalu lintas sempat dilarang oleh pemerintah London. Saat itu, salah satu lampu lalu lintas di sana meledak, serta melukai salah satu polisi yang tak jauh di sana.

Beberapa waktu berikutnya, lampu lalu lintas model baru pun dibuat dengan dilengkapi tanda ‘berhenti’ dan ‘jalan’. Tahun-tahun berikutnya, lampu lalu lintas pun mengalami perkembangan, hingga menjadi seperti sekarang.

Terinspirasi dari Zaman Peperangan

Setiap warna yang ada pada lampu lalu lintas rupanya terinspirasi dari zaman peperangan. Terutama, untuk lampu kuning dan merah. Lalu, apa saja makna di setiap lampu lalu lintas itu?

Hijau

Warna ini terinspirasi dari warna dedaunan. Warna hijau diidentikan dengan ketenangan. Dalam lampu lalu lintas, hijau merupakan tanda kalau siapa pun bisa melintasi jalan yang diberi lampu itu dengan aman. Dalam cara kerja lampu lalu lintas, lampu hijau adalah lampu pertama yang akan menyala.

 

Kuning

Warna kedua dalam lampu lalu lintas ini terinspirasi dari warna api yang dipakai di zaman perang. Saat itu, api lazim dipakai untuk senjata perang. Jika salah satu pihak membawa api saat perang, maka pihak lainnya akan bersikap lebih hati-hati.

Dalam lalu lintas, kuning menandakan bahwa pengendara harus siap karena lampu akan berubah menjadi hijau. Atau, justru harus lebih hati-hati, karena lampu akan berubah menjadi merah.

 

Merah

Dalam lampu lalu lintas, merah berarti setiap pengendara wajib untuk berhenti sejenak. Warna ini terinspirasi dari tanda merah yang dipakai di masa perang. Tanda itu dibuat sebagai simbol agar perang segera diakhiri, karena sudah banyak menimbulkan pertumpahan darah.

Demikianlah cara kerja lampu lalu lintas, serta informasi terkait dengannya. 

"DUDUK SENDIRI 

TANPA KEKASIH

CUKUP SEKIAN 

DAN TERIMA KASIH😸"













Minggu, 02 Oktober 2022

REKAYASA SISTEM

NAMA: IRSA ZUARSA
NPM   : 20316022
KELAS: TEKNIK KOMPUTER 20A
MATKUL: REKAYASA SISTEM

SKETSA KONSEPTUAL KOMPUTER


1. Monitor
2. Cpu
3. Mouse
4. Keyboard


Sabtu, 01 Oktober 2022

Pembelajaran Tentang Rekayasa Sistem

Pembelajaran Tentang Rekayasa Sistem 

   Rekayasa Sistem merupakan kumpulan konsep, pendekatan & metodologi, serta alat-alat bantu (tools) untuk bisa merancang dan juga menginstalasi sebuah kompleks sistem. Kompleksitas sistem tersebut dapat  diakibatkan karna 2 hal yakni :

  1. kompleksitas dinamis
  2. kompleksitas detail

Kompleksitas detail ketika komponen atau sub-sistem yang dirancang tidak hanya banyak tetapi ditambah pula dengan multi-sourcing (multi suplier), multi standard, multi kriteria dan lain sebagainya.

Pressman menyebut sistem yang didalamnya terdapat perangkat lunak sebagai sistem berbasis komputer. Pada sistem berbasis komputer terdapat komponen – komponen sebagai berikut :

  1. Perangkat Keras (Hardware)
  2. Manusia (People)
  3. Perangkat Lunak (Software)
  4. Basis Data (Database)
  5. Prosedur (Procedure)
  6. Dokumentasi

Pada dasarnya, dari ke-6 komponen tersebut pembentuk sistem berbasis komputer, 4  komponen terakhir diatas adalah  hasil aktivitas rekayasa perangkat lunak. Perangkat lunak itu sendiri terdiri dari artifak – artifak hasil rekayasa perangkat lunak (RPL) yang merupakan hasil dari suatu aktivitas proses rekayasa (pengembangan) sistem berbasis komputer.






Kamis, 16 Juni 2022

SYSTEMS ANALYSIS AND DESIGN

Latar belakang dan manfaat kegiatan Analisis dan Desain Sistem serta contoh kegagalan proyek perangkat lunak dan penyebab nya 

  • Latar belakang perlunya kegiatan Analisis dan Desain Sistem
Dalam pengembangan teknologi informasi saat ini, dibutuhkan analisa dan 

perancangan sistem pengolah data yang baik. Sistem pengolah data tersebut 

diharapkan mampu meningkatkan kinerja pada sistem informasi berbasis web pada 

Crown Christian School yang akan dibuat. Metode ini membutuhkan analisis yang 

tepat, kebutuhan bisnis dan beberapa teknis analisis untuk menghasilkan perencanaan 

yang baik. Analisa merupakan cara untuk menganalisa permasalahan berdasarkan 

data yang telah diperoleh dari hasil studi lapangan. Sedangkan desain sistem 

merupakan langkah yang harus ditempuh untuk menyajikan sebuah sistem informasi 

terorganisir dengan baik.

  • Manfaat kegiatan Analisis dan Desain Sistem
  1. Mengevaluasi sistem yang telah ada
  2. Merumuskan tujuan yang ingin dicapai berupa pengolahan data maupun pembuatan laporan baru
  3. Menyusun suatu tahap rencana pengembangan sistem. 
  4. Mengidentifikasi masalah atau mencari pemecah masalahnya
  5. Mempelajari sistem yang sedang berjalan saat ini.
  6. Memberikan pelayanan kebutuhan informasi kepada fungsi manajerial di dalam pengendalian pelaksanaan kegiatan operasional perusahaan
  7. Membantu para pengambil keputusan
  • Contoh kasus kegagalan proyek perangkat lunak dan penyebab terjadinya kegagalan tersebut
  1. Pada tahun 1988 kapal perang USS Vincennes menempak jatuh pesawat komersil Airbus 320 yang disebabkan oleh output program pelacakan yang ditampilkan tidak jelas.
  2. Kesalahan diagnosa pada perangkat lunak medis yang menyebabkan kematian.
    Sistem peringatan radar kapal yang mengidentifikasi roket Excocet sebagai teman yang mengakibatkan kapal The British Destroyer tenggelam.
  3. Therac 25 merupakan perangkat terapi radiasi medis yang bekerja dengan sistem terkomputerisasi. Pada tahun 1985 hingga 1987 terdapat 6 kali kecelakaan akibat overdosis radiasi yang dihasilkan oleh alat tersebut hingga mengakibatkan kematian dan luka serius. Sistem keamanan dari Therac25 ini lebih mengandalkan perangkat lunak bukan pada perangkat keras sementara pengujian keamanan yang dilakukan lebih ke arah perangkat keras dan tidak ke perangkat lunak sehingga mengakibatkan kesalahan perangkat lunak terutama system engneering.

Senin, 21 Maret 2022

EXTREME PROGRAMMING

 SEJARAH

Asal mula XP digunakan karena pada saat itu permintaan dari customer yang sering berubah dengan cepat sehingga mengakibatkan putaran kehidupan metode pengembangan perangkat lunak tradisional menjadi lebih pendek dan tidak selaras dengan metode tradisional karena pada umumnya memerlukan desain yang luas dan itu mengakibatkan perubahan desain yang terjadi dan tentu saja memerlukan biaya yang lebih tinggi. Tujuan utama dari XP adalah Meminimalisir biaya yang di perlukan jika ada perubahan dalam pengembangan Perangkat lunak.

Dari tujuan di atas maka Kent Beck dan Ward Cunningham mengusulkan metode baru yang bernama Extreme Programming pada bulan maret 1997.


  3. TAHAPAN DALAM EXTREME PROGRAMMING

XP membantu pengembang membuat code berkualitas dan cepat. Mendefinisikan kualitas sebagai sebuah basis code yang sesuai dengan desain spesifikasi dan Ekspektasi pelanggan.

Sasaran XP adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu sampai menggunakan sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements yang sangat cepat.


Seluruh kontributor dalam proyek yang mengguanakan pendekatan XP duduk Bersama sebagai suatu tim. Tim ini terdiri beberapa peran, antara lain :


- Programmer

- Penguji

- Orang yang mengerti bisnis

- Analis

- Manajer

- Dan lain-lainnya.

Setiap peran tidak mutlak menjadi peran dari satu orang saja. Tim terbaik dalam XP tidak harus memiliki pakar, hanya kontributor umum dengan keterampilan khusus saja. Semua orang di tim XP memberikan kontributor dengan cara apapun yang mereka dapat lakukan.

XP fokus pada:


- Implentasi desain sederhana

- Komunikasi antara pengembang dan pelanggan

- Secara terus menerus menguji basis code

- Refaktorisasi untuk mengakomodasi perubahan spesifikasi

- Mencari timbal bailk pelanggan

XP memiliki empat kegiatan dasar mengenai XP untuk proses pengembangan parangkat lunak :

a. Planning

Dasar XP adalah mekanisme berkelanjutan keterlibatan client melalui umpan balik dalam tahap pengembangan. Terlepas dari pelanggan, pengembang juga menerima umpan balik dari manajer proyek.

Dasar dari umpan balik adalah tes penerimaan pelanggan. Setiap umpan balik dari pelanggan yang menentukan persyaratan revisi menjadi dasar dari desain baru, dan proses desain-coding-tes-planning. Jika pelanggan tetap puas dengan hasl tes iterasi berakhir disana, dan desain untuk iterasi baru dimulai, yang lagi-lagi mengikuti siklus desain-coding-testing-planning.


b. Design

Iterasi pemrograman XP dimulai dengan merancang. Prinsip-Prinsip dari tahap ini adalah :

· Dorongan pada kesederhanan dengan mengekspresikan hal yang hanya seklai dan tidak menambahkan fungsi antisipasi.

· Menggunakan system metafora atau standar pada nama, nama kelas dan metode, dan menyepakati gaya seragam dan format untuk memastikan kompatibilitas antara kerja anggota tim yang berbeda.

· Menggunakan tanggung jawab software class dan kolaborasi (CRC) kartu yang memungkinkan untuk keberangkatan dari pola pikir prosedural tradisional dan membuat teknologi berorientasi objek. Kartu tersebut memungkinkan semua anggota tim proyek untuk menyumbangkan ide-ide, dan menyusun ide-ide terbaik dalam desain.

· Menciptakan solusi lanjutan atau program sederhana yang mengeksplorasi solusi protensi untuk masalah tertentu, mengabaikan semua masalah lain, untuk mengurangi resiko.

c. Coding

Coding merupakan fase paling penting dalam siklus hidup programming Extreme. Pemrograman XP memberikan Prioritas kepada coding yang sebenarnya atas semua tugas-tugas lain seperti dokumentasi untuk memastikan bahwa pelanggan menerima sesuatu yang substansial dalam nilai pada akhir hari. Standar terkait dengan coding meliputi:

· Mengembangkan kode berdasarkan metofora dan standar yang telah disepakati, dan mengadopsi kebijakan kepemilikan kode kolektif.

· Pasangan pemrograman atau kode berkembang oleh dua programmer bekerja sama pada satu mesin, yang bertujuan untuk menghasilkan kode berkualitas tinggi dengan biaya yang sama atau kurang.

· Kepatuhan yang ketat untuk 40 jam workweeks tanpa lembur. Hal ini memastikan para pengembang bekerja di puncak kemampuan mental dan fisik meraka.

· Integrasi sering kode ke repositori khusus, hanya dengan satu pasangan mengintegrasikan pada suatu waktu untuk mencegah konflik, dan optimasi di akhir.

d. Testing

Program ekstrim terintegrasi pengujian dengan tahap pengembang dari pada di akhir tahap pengembangan. Semua kode memiliki unit test untuk menghilangkan bug, dan kode melewati semua tes unit tersebut sebelum rilis.

Tes kunci lain adalah tes penerima client, berdasarkan spesifikasi pelanggan. Tas penerimaan dijalankan pada penyelesaian coding, dan pengembang menyediakan pelanggan dengan hasil tes penerimaan bersamaan dengan hasil tes penerimaan Bersama dengan demonstrasi.[2]


Contoh 

Pada penelitian dalam membuat sistem ini, penggunaan metode Extreme Programming(XP) memiliki beberapa tahapan atau step dalam penggunaannya. Tahapan-tahapan tersebut sebagai berikut :

1. Planning (Perencanaan).

Menganalisis permasalahan dan mengumpulkan segala kebutuhan yang diperlukan dalam pembuatan sistem.

2. Design (Perancangan).

Mendesain atau membuat rancangan sistem berupa gambar atau UI.

3. Coding (Pengkodean).

Pembuatan sistem yang dibangun menggunakan bahasa pemrograman.

4. Testing (Pengujian).

Pengujian sistem untuk mengetahui apakah sistem dapat beroperasi sesuai harapan.

Hasil Dan Pembahasan :

Hasil peracangan keseluruhan dalam model Mind Mapping :

Sistem Informasi Penjualan Toko Mainan Anak Dana Sentosa

Planning (Perencanaan)

a. Identifikasi Masalah.

Pembuatan sistem ini didasari oleh seringnya terjadi permasalahan dalam melakukan kegiatan pembelian yaitu :

1. Membutuhkan waktu yang lama untuk melakukan pembelian.

2. Kurang efektif serta perlu mengantri untuk membeli barang.

3. Pengelolaan atau pencatatan dan pembuatan laporan penjualan masih manual sehingga sering terjadi kesalahan.


b. Analisa Kebutuhan.

Berdasarkan permasalahan tersebut maka dapat didefinisikan kebutuhan dalam pembuatan sistem ini yaitu kebutuhan fungsional dan non fungsional.

Kebutuhan fungsional :

1. Pemilik Toko

    a. Pemilik toko dapat login dan logout.

    b. Dapat melihat data produk.

    c. Dapat melihat data transaksi.

    d. Dapat melihat data konsumen.

    e. Dapat melihat laporan.


2. Pegawai

    a. Pegawai dapat login dan logout.

    b. Dapat mengelola data produk.

    c. Dapat mengelola data konsumen.

    d. Dapat mengelola data transaksi.

    e. Dapat mengelola laporan.


3. Pembeli

    a. Dapat login dan logout.

    b. Dapat melihat, memesan dan membeli produk yang dijual.

    c. Dapat melihat laporan transaksi yang telah dilakukan.

Kebutuhan non-fungsional :


1. Sistem dapat menampilkan data produk atau barang.

2. Sistem dapat memiliki tampilan yang mudah dipahami, sehingga pembeli dapat lebih mudah dalam memesan dan melakukan kegiatan pembelian.

3. Sistem dapat dioperasikan dan menampilkan data dengan cepat, sehingga proses pembelian dapat berlangsung dengan efisien atau tidak membuang-buang waktu.

3. Sistem dapat dioperasikan dengan baik sesuai fungsinya.

Design (Perancangan)


a. Pemodelan Sistem

1. Use Case Diagram Pemilik Toko.

Pemilik Toko

2. Use Case Diagram Pegawai

Pegawai

3. Use Case Diagram Pembeli

Use Case Pembeli

4. Prosedur Pembelian.

Prosedur Pembelian

b. Pemodelan UI Sistem

1. Tampilan Pendaftaran/Login.

Login

2. Tampilan Halaman Barang/Produk.

Halaman Barang/Produk

3. Tampilan Halaman Pembelian Barang/Produk.

Halaman Pembelian Barang/Produk.

Coding (Pengkodean)

Pembuatan sistem ini menggunakan JAVA sebagai bahasa pemrogramannya. 

Testing (Pengujian)

Pengujian yang dilakukan menggunakan metode blackbox testing yaitu pengujian yang dilakukan pada tampilan program apakah program dapat berjalan dengan baik sesuai yang diinginkan.

Sabtu, 19 Maret 2022

PROTOTYPING DAN THROW AWAY PROTOTYPING - APPL

 PROTOTYPING DAN THROW AWAY PROTOTYPING


Sejarah Prototyping

Pada tahun 1960-an: Teknik-teknik prototyping pertama cepat menjadi diakses pada tahun delapan puluhan kemudian dan mereka digunakan untuk produksi komponen prototipe dan model. Sejarah prototipe cepat dapat ditelusuri sampai akhir tahun enam puluhan, ketika seorang profesor teknik, Herbert Voelcker, mempertanyakan dirinyasendiri tentang kemungkinan melakukan hal-hal menarik dengan alat komputer dikontroldan otomatis mesin. Alat-alat mesin baru saja mulai muncul di lantai pabrik itu. Voelcker  berusaha mencari jalan di mana alat-alat mesin otomatis dapat diprogram denganmenggunakan output dari program desain komputer.Kemudian 1970: Voelcker mengembangkan alat dasar matematika yang dengan jelas menggambarkan tiga aspek dimensi dan menghasilkan teori-teori awal teorialgoritma dan matematika untuk pemodelan solid. Teori-teori ini membentuk dasar  program komputer modern yang digunakan untuk merancang hampir segala hal mekanis,mulai dari mobil mainan terkecil ke gedung pencakar langit tertinggi. teori Volecker  berubah metode perancangan pada tahun tujuh puluhan, namun, metode lama untuk merancang masih sangat banyak digunakan. Metode lama terlibat baik alat masinis ataumesin dikendalikan oleh komputer. Para cowok logam dipotong dan bagian yangdibutuhkan tetap sesuai kebutuhan.


Namun, pada tahun 1987, Carl Deckard, bentuk penelitian dari University Of Texas, datang dengan ide yang revosioner yang baik. Dia memelopori manufaktur yang berbasis lapisan, dimana ia memikirkan membangun lapisan model dengan lapisan. Dengan dicetak model 3D dengan menggunakan sinar laser untuk bedak sekering logam dalam prototype solid, single layar pada suatu waktu. Deckard mengembangkan ide ini menjadi sebuah teknik yang disebut “Selective Laser Sintering”.


Tahapan Prototyping :

Tahapan-tahapan dalam Prototyping adalah sebagai berikut:

1. Pengumpulan kebutuhan

Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

2. Membangun prototyping

Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output).

3. Evaluasi protoptyping

Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulang langkah 1, 2 , dan 3.

4. Mengkodekan sistem

Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

5. Menguji sistem

Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.

6. Evaluasi Sistem

Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan. Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.

7.  Menggunakan sistem

Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.

Kelebihan Prototyping 

Adanya komunikasi yang baik anatar pengembang dan pelanggan

Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan

Pelanggan berperan aktif dalam pengembangan sistem

Lebih menghemat waktu dalam pengembangan sistem

Penerapan menjadi lebih mudah karena pemakai mengetahui 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 cetak biru sistem.

Hubungan pelangga dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik.

Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas kemudahan dipelihara atau dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika pelanggan cocok dengan prototype yang disajikan dan berkas terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.

Developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mugkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang sederhana. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh pelanggan dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan.

Perbedaan Antara Prototyping dan Throw Away Prototyping :

Prototype digunakan saat sampai sistem final.

Sedangkan throw away, prototype tidak digunakan atau dibuang.

Contoh Kasus Prototyping

   Seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, atupun input detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemampuan penyesuaian dari sebuah sistem operasi,atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini, serta pada banyak situasi yang lain, prototyping paradigma mungkin menawarkan pendekatan yang terbaik. Prototyping paradigma dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari software, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar diman definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari aspek-aspek software tersebut yang akan nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output). Perancangan kilat membawa kepada konstruksi sebuah prototipe. Prototipe tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan software. Iterasi terjadi pada saat prototipe disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami apa yang harus dilakukannya.


Sejarah Throw Away Prototyping


Pada tahun 1960-an Herbert Voelcker,1970: Voelcker mengembangkan alat dasar matematika yang dengan jelas menggambarkan tiga aspek dimensi dan menghasilkan teori-teori awal seperti teori algoritma dan matematika untuk pemodelan solid.


Pada tahun 1987, Carl Deckard, membentuk tim peneliti dari University of Texas. datang dengan ide yang revolusioner yang baik


Throw Away Prototyping adalah suatu metode yang sama persis dengan metode prototyping lainnya dimana hal ini merupakan hasil perkembangan dari prototype Tetapi throw away prototype lebih mengarah pada hasil presentasi nya.


Throw-Away prototyping menggunakan prototyping untuk tujuan yang berbeda dari prototyping sebelumnya

Melakukan analisis secara menyeluruh, untuk mengumpulkan informasi & mengembangkan ide-ide untuk sebuah konsep sistem.

Masalah yang muncul  diujicobakan/diselesaikan dengan menganalisa, mendesign, & membangun sebuah prototype (yang dinamakan design prototype)

Yang dibangun merupakan fitur yang blm dipahami dengan jelas

Sebagai contoh, pengguna tidak sepenuhnya jelas tentang bagaimana sistem entry order harus bekerja.

Tim analis membangun serangkaian halaman HTML yang diperlihatkan untuk membantu klien memvisualisasikan sistem yang dibangun.. Jika menginginkan program canggih di Java, tim bisa menulis bagian dari program dengan data contoh (sample) untuk memastikan bahwa mereka bisa mendapatkan apa yang diinginkan klien dengan tepat. Namun ini hanyalah design prototype (rancangan) ini bukan bagian dari produk. Membuat design prototype untuk  memahami kebutuha.Jika design prototype merupakan hal yang diinginkan & dapat mengatasi masalah, design prototype dibuang, selanjutnya memasuki tahap design, implementasi, system yang sesungguhnya.


Kelebihan Throw Away Prototyping


Setiap prototype yang dibangun dapat meminimalkan resiko terkait isu-isu / masalah yang akan dihadapi oleh sistem. 

Menyeimbangkan fase analisis & design Kekurangan.

Kekurangan Throw Away Prototyping


Sistem yang dikembangkan bergantung pada rancangan prototype.

Tahapan Throw-Away Prototyping :

Tentukan kebutuhan. Tentukan apa kebutuhan user. Analis system mewawancarai user untuk mendapatkan ide tentang apa yang diinginkan oleh user dari system yang akan dikembangkan.

Buat prototype. Analis system bekerja sama dengan ahli komputer yang lain, dengan memanfaatkan satu atau beberapa alat bantu untuk pembuatan prototype, mengembangkan prototype.

Evaluasi. Analis system memperkenalkan prototype kepada user, menuntun user untuk mengenali karakteristik dari prototype. Dari kesempatan uji coba ini, user akan memberikan pendapatnya pada analis sistem. Kalau prototype diterima dilanjutkan ketahap selanjutnya.

Kalau ada perbaikan maka langkah berikutnya adalah mengulangi tahap1, 2 dan 3 dengan pengertian yang lebih baik tentang apa yang diinginkan oleh user.


Contoh kasus Throw Away Prototyping

Dalam pelaksanaannya, system akademik yang berjalan di Sekolah Menengah Atas Negeri 1 Lampung dirasa belum optimal, hal ini dikarenakan sistem yang digunakan masih bersifat manual. Dengan permasalahan tersebut , maka muncul berbagai permasalahan terutama pada proses pendaftaran,registrasi, pembagian kelas, pembagian wali kelas, proses penilaian serta informasi mengenai perkembangan siswa kepada orang tua. Untuk itu, diperlukan suatu sistem informasi yang mampu mendukung pengambilan keputusan dalam memperoleh informasi kegiatan akademik. Pembuatan Sistem Informasi Akademik Sekolah Menengah Atas Negeri 1 Lampung menggunakan pendekatan terstruktur, sedangkan metode pengembangan menggunakan prototype dengan teknik pengumpulan data observasi dan wawancara, sedangkan alat yang digunakan dalam merancang sistem berupa Flow Map, Diagram Konteks, DFD dan pengembangan aplikasi berbasis desktop.Sistem yang dibangun disajikan secara client server sehingga dapat diakses beberapa komputer. Sistem yang dibangun diharapkan dapat mengatasi sebagian besar permasalahan yang ada seperti melakukan validasi kerangkapan data registrasi dan nilai siswa, pembagian kelas dan penilaian.

3 contoh "latent defects

Unsafe acts (atau bisa disebut active failure) kini lebih dianggap para expert sebagai "konsekuensi" dari beberapa penyebab utama ...