Apa cara yang lebih baik untuk menggambarkan proses "Idiot Proofing" perangkat lunak [ditutup]


13

Bagi saya, Idiot Proofing hanya berarti memastikan pengguna tidak dapat merusak perangkat lunak bahkan jika dia mencoba. Misalnya, jika nilai dibaca dari kotak teks, dan dikonversi menjadi ganda, jika perangkat lunak yang mendasarinya adalah bukti idiot, itu tidak akan rusak jika pengguna mengetikkan nilai non-ganda.

Saya baru-baru ini menulis jadwal pengembangan dan salah satu item bernama "Idiot proof UI". Orang-orang yang saya bangun perangkat lunak ini dengan bercanda pura-pura tersinggung dengan istilah itu, tetapi saya bisa melihat di mana istilah ini benar-benar membuat orang kesal.

Apa cara yang lebih baik untuk mengatakan ini?


23
Sebut saja, ID-10T Proofing
Jarrod Nettles

2
Lol, saya menyadari 1337 ketika saya mencari Google ID-10T. saya gagal ...
sooprise

13
Pertanyaan ini mengingatkan saya pada salah satu kutipan favorit saya: "Pemrograman hari ini adalah perlombaan antara insinyur perangkat lunak yang berusaha untuk membangun program yang lebih besar dan lebih tahan terhadap idiot, dan Semesta berusaha untuk menghasilkan idiot yang lebih besar dan lebih baik. Sejauh ini, Semesta menang. " ~ Rich Cook
KallDrexx

3
bagaimana dengan teknik dasar?
jk.

4
"Tidak ada yang bisa dibuat sangat mudah, karena orang bodoh sangat cerdik."
M.Sameer

Jawaban:


27

Jika Anda memasukkan "Idiot proof UI" sebagai item jadwal maka Anda hanya mencoba menambah kualitas setelah itu ke perangkat lunak Anda. Setiap sistem yang dirancang dengan baik akan memvalidasi inputnya dan memberikan panduan yang jelas kepada pengguna sebagai hal yang biasa, itu bukan sesuatu yang dimasukkan ke dalam jadwal sebagai item diskrit (yang kemudian dapat dihapus ketika hit krisis yang tak terelakkan).

Atau, jika itu harus item diskrit (saya tahu bagaimana beberapa organisasi berpikir tentang penjadwalan), "Idiot proof UI" harus diubah menjadi "Input Validation Library" dan dipindahkan ke bagian depan jadwal.


2
+1. Jika Anda mencoba menambahkan validasi input apa pun setelah fakta, Anda telah kehilangan banyak hal. Lebih baik untuk memiliki sebagai titik berdiri dalam spesifikasi, "perangkat lunak harus dengan anggun menangani input yang tidak valid di mana saja". Cara persis "anggun" menangani input yang tidak valid sangat tergantung pada apa yang dilakukan perangkat lunak pada titik tertentu. Untuk UI yang sangat sederhana (bayangkan ATM), bahkan mungkin membuat input yang tidak valid menjadi tidak mungkin .
CVn

14
+1. Pemeriksaan idiot bukanlah tugas. Idiot-proof adalah konsekuensi dari desain yang bagus.
S.Lott

4
Pemeriksaan Idiot adalah proses yang berkelanjutan - karena alam semesta terus membuat orang-orang idiot yang semakin pintar
Steven A. Lowe

Walaupun mungkin terdengar salah dan berlebihan, perlu diperhatikan bahwa baik perancang antarmuka dan penguji beta mengetahui cetak biru dan desain umum perangkat lunak, dan mungkin tidak menyadari (mengabaikan) bahwa sesuatu yang tampaknya sangat jelas bagi mereka sebenarnya adalah benar-benar membingungkan bagi pengguna biasa. "Menguji dan men-debug keputusan desain UI" adalah apa yang bisa disebut. Validasi input adalah satu hal, membuat pengguna mengerti apa yang harus dimasukkan di mana yang lain.
SF.

Untuk semua pendukung: ... apa pun yang Anda lakukan, Anda akan selalu melupakan sesuatu. Perangkat lunak sangat kompleks sehingga memiliki tim yang membuat segalanya "sempurna" dalam tembakan pertama hampir tidak mungkin tercapai. Itu sebabnya pengujian diperlukan. Untuk mendeteksi kekurangan dan kelalaian, atau bahkan hal-hal yang tidak ada yang dipikirkan. "UI bukti idiot" seperti itulah yang diperlukan.
dagnelies

10

Validasi input pengguna saya pikir akan menjadi istilah profesional. Saya tidak melihat ada yang salah dengan pemeriksaan idiot jika digunakan dalam dokumen internal.


3
Anda meminta saya di "validasi input pengguna." Idiot proofing adalah istilah yang tidak profesional di mana pun itu digunakan.
Robert Harvey

2
Apa pun yang Anda lakukan, jangan menuliskannya.
JeffO

6

Mengeras adalah kata yang bagus. Jika ada yang bertanya, beri tahu mereka perangkat lunak pertama yang lulus biasanya ditulis untuk skenario ideal, dan seperti alat baja, perangkat lunak perlu "dikeraskan" ke arah penggunaan sehari-hari oleh pelanggan nyata.

Robustification adalah kata lain yang bagus untuk ini - Anda membuat kode menjadi kuat terhadap jenis tantangan yang akan dilontarkan pelanggan nyata.

Kedua kata itu terdengar keren dan industri, jangan salahkan pengguna atau pemrogram, dan sampaikan intinya.


BTW, inilah maskot lama Metrowerks, Arnold, pria yang dulu membantu kami para programmer Mac mengeraskan dan menguatkan kode kami dengan tungku perlakuan panas, bengkel, dan palu kecil dan landasan palu kecil:


pengerasan umumnya mengacu pada toleransi kesalahan dari perangkat keras yang mendasarinya - atau resistensi terhadap sinar gamma ;-) ketahanan dapat berarti banyak hal
Steven A. Lowe

@ Seven: Ya, ya. Tetapi ini untuk komunikasi dengan apa yang mungkin merupakan audiens non-teknis, dan pertanyaannya adalah tentang bagaimana "memutar" tugas tersebut sehingga sangat cocok untuk orang-orang itu.
Bob Murphy

itu masuk akal; audiens non-teknis mungkin telah melihat iklan TV untuk laptop 'keras'. Jadi mereka akan berpikir tidak apa-apa untuk menjatuhkan perangkat lunak Anda 3 kaki ke atas beton ;-)
Steven A. Lowe

@ Sebelas: Yup, dan jika mereka telah melihat iklan laptop Toshiba terbaru, mereka juga akan menyadari bahwa jika mereka tidak memberi Anda waktu dan sumber daya untuk mengeraskan perangkat lunak, itu akan membawa Zombie Apocalypse. B ^)
Bob Murphy

4

Pemrograman Defensif

Adalah apa yang diajarkan kepada saya. Kembali ketika kami harus memotong bit kami sendiri dari kayu.

Jika Anda ingin menjadi PC, sebut saja pemrograman "antisipatif".


4

Ketika saya sedang belajar, kami menyebutnya anti peluru .

Namun, sebagian besar eufemisme lain yang saya baca juga berlaku.



3

"Idiot proofing" harus terdiri dari keduanya

  • mendesain UI sehingga mudah digunakan dan mengarahkan pengguna untuk memasukkan data dengan cara yang diharapkan oleh para programmer, dan

  • menguji UI untuk menentukan apakah antarmuka dapat rusak dengan memasukkan nilai data yang tidak terduga.

Kedua langkah mungkin muncul pada jadwal pengembangan di mana desain diperiksa oleh ahli pengalaman pengguna dan di mana kode yang dikirimkan diperiksa oleh penguji untuk memastikan bahwa data yang tidak valid ditangani dengan benar (untuk apa pun "benar" artinya untuk aplikasi Anda).


Anda tidak menjawab pertanyaan yang diajukan.
Robert Harvey

@ Robert - saya yakin saya lakukan. Cara yang lebih baik untuk mengatakan "pemeriksaan idiot" adalah "meninjau desain untuk meningkatkan keramahan pengguna" atau "menguji bahwa antarmuka menangani data yang tidak valid" tergantung pada arti "pemeriksaan idiot" yang Anda maksud.
Justin Cave

Oke, itu masuk akal.
Robert Harvey

2

Idiot-proofing melibatkan lebih dari sekadar validasi input sederhana. Saya bahkan tidak akan memasukkan hal seperti itu dalam definisinya.

Validasi input adalah proses di mana Anda membersihkan dan memvalidasi data pengguna untuk menghilangkan nilai ilegal / tidak masuk akal. Ini harus selalu dilakukan dengan informasi yang berasal dari luar program Anda sehingga dapat menghilangkan yang jelas serta melindungi diri Anda dari serangan (misalnya serangan injeksi sql).

Saya akan menganggap pembuktian idiot sebagai serangkaian logika untuk menjaga agar pengguna tidak sengaja menyebabkan kerusakan besar pada dirinya sendiri melalui cara lain yang legal.

Misalnya, membuat rmtolak perintah rm -rf /dan menutup varian tidak ada hubungannya dengan validasi atau kebenaran. Ini perintah yang benar-benar valid. Sayangnya, ini adalah perintah yang dapat dan dapat menghapus semua data Anda dari semua disk Anda di Unix / Linux. Membuktikan idiot ini akan menolak perintah ini dan akan menyarankanrm -rf --i-really-mean-this / , atau jika dalam mode interaktif, minta pengguna mengetikkan tanggapan afirmatif setelah peringatan.

Apa pun yang merusak sistem harus dibuktikan dengan kebodohan. Apa pun yang dapat menyebabkan rasa malu mungkin juga menjadi kandidat (mis. "Anda yakin ingin mengirim email ini tanpa lampiran meskipun Anda menyebutkan satu di teks Anda?", Dan "Anda yakin ingin mengirim email ini ke seluruh perusahaan? ")

Idiot-proofing adalah kolaborasi antara QA (berusaha menjadi idiot terbaik) dan Pengembangan (mencoba mengantisipasi semua skenario ini dan mendesain di sekitarnya).

Adapun sinonim yang lebih ramah , mungkin saya sarankan "analisis jalur kode destruktif" atau "aktifkan umpan balik pengguna untuk operasi kritis". Apa pun Anda menyebutnya, Anda harus benar-benar memulainya sedini mungkin dalam proses desain.


1

"Sanity Checking" cenderung bekerja dengan cukup baik ...


3
Bagi saya, "pemeriksaan kewarasanan" berarti tentang hal yang sama dengan "menegaskan": memastikan bahwa keadaan internal sudah benar. Tidak benar-benar sama dengan validasi input eksternal.
Mason Wheeler

@ Alasan, saya menganggapnya sebagai memeriksa keadaan sistem, di semua titik, untuk input yang valid yang masuk akal. Misalnya, memeriksa bahwa tanggal akhir adalah setelah tanggal mulai, selain memeriksa masukan sampah, dll. Saya juga melihat sudut pandang Anda dan setuju dengan Anda.
Marlon


1

"Penanganan kesalahan" atau "validasi input" adalah istilah lain yang akan saya gunakan untuk apa yang Anda gambarkan. Antipeluru akan menjadi istilah lain yang bisa saya lihat digunakan di beberapa kalangan karena idenya di sini adalah membuat perangkat lunak yang cukup kuat untuk menangani hampir semua hal. Rock solid akan menjadi ungkapan slang lain yang bisa kubayangkan seseorang ingin gunakan di sini juga.


1

+ Msgstr "Pemeriksaan skenario kasus terburuk". Karena, sebagai pengembang, kita semua tahu bahwa jika itu bisa dilakukan, maka itu akan dilakukan . Jadi, Anda hanya harus siap untuk menangani situasi skenario terburuk dengan perangkat lunak Anda.

Langkah-langkah keamanan bukan hanya cara untuk melindungi pengguna dari invasi cyber luar, tetapi juga terhadap diri mereka sendiri. Kita hidup di dunia yang tidak sempurna dengan pengguna yang tidak sempurna.


1

Pelapisan emas adalah istilah sopan (dan terdengar sangat positif) yang saya gunakan ketika berbicara tentang meningkatkan pengalaman antarmuka pengguna akhir dengan cara apa pun (GUI atau lainnya).

Proof-proofing, seperti yang Anda katakan, adalah bagian terbesar dari proses itu, bersama dengan perbaikan desain atau alur kerja (pikirkan pengakuan umpan balik pengguna akhir).

Idenya di sini adalah bahwa Anda dapat menggunakan istilah itu secara bebas di lingkungan kerja dan dilihat sebagai proses yang berharga (setelah selesai) oleh manajemen dan pengguna, meskipun mungkin perlu waktu (dan dengan demikian umumnya membutuhkan sejumlah uang).

banyak istilah lain yang terkait dengan proses ini (sering kali merupakan akhir siklus) membuatnya terdengar seperti proses ini:

  • menyiratkan pengguna (seringkali manajemen ;-) bodoh
  • sulit untuk dicapai
  • memiliki sedikit kekayaan bersih

Dengan mengaitkan emas dengan proses (logam biasanya disamakan dengan "bernilai" daripada "biaya"), saya telah melihat proses menjadi berubah dari pengeluaran menjadi investasi dalam beberapa pola pikir manajer.

Ini seperti secara terbuka menyatakan bahwa sampai ini selesai, potongan baja yang kikuk belum menjadi perhiasan. Tapi begitu berlapis ... maka itu berharga.


Saya melihat bagaimana istilah ini bekerja untuk audiens Anda. Bagi sebagian besar manajer, pelapisan emas akan menjadi hal pertama yang dipotong dari proyek. Dengan kata lain, bagian yang tidak perlu.
Gilbert Le Blanc

Aneh - Saya melihat istilah "pelapisan emas" sebagai berarti Anda membuang-buang waktu untuk melakukan sesuatu yang tidak menawarkan peningkatan fungsional . Memastikan input yang valid, dll. Memang menawarkan peningkatan fungsional dan karenanya (menurut definisi saya) bukan pelapisan emas.
ChrisF

detailnya adalah pelapisan emas tidak meningkatkan internal perangkat lunak. itu hanya meningkatkan aspek eksternal itu. Saya menggunakannya ketika non-teknisi terlibat secara khusus karena tidak terkait dengan bagian spesifik dari akhir proses siklus. Orang memahaminya sebagai, setelah pelapisan emas selesai, bagus, mudah digunakan dan memiliki nilai tambah. itu bukan hanya sepotong perangkat lunak.
moliad

Dalam pengalaman saya, pelapisan emas biasanya digunakan untuk menggambarkan perangkat lunak yang sarat dengan fitur yang tidak perlu , yaitu sebagai sinonim untuk bloatware .
Mark Booth

ya, baru saja melakukan sedikit riset dan menemukan bahwa istilah ini kadang digunakan dalam literatur (terima kasih atas komentarnya). Lucunya di banyak tempat saya pernah bekerja, pemeriksaan idiot dianggap pelapisan emas dalam pengertian ini (Ini tergantung pada jenis pekerjaan yang saya kira).
moliad

1

Paling sering digunakan dalam kaitannya dengan proses pembuatan tetapi saya pikir yang benar-benar cocok adalah Poka-Yoke :

"[poka yo-ke] adalah istilah Jepang yang berarti" gagal menyelamatkan "atau" pemeriksaan kesalahan "

Awalnya digambarkan sebagai baka-yoke, tetapi karena ini berarti "pembodohan" (atau "pembodohan idiot"), namanya diubah menjadi poka-yoke yang lebih ringan.

Secara lebih luas, istilah ini dapat merujuk pada segala kendala pembentuk perilaku yang dirancang menjadi produk untuk mencegah operasi yang salah oleh pengguna. "


1

Istilah umum di toko-toko besar juga Jaminan Kualitas (QA) .

Ini adalah istilah yang umum dan tidak jelas yang dapat Anda gunakan untuk makna spesifik Anda sendiri dalam siklus rilis Anda.


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.