Pemecahan Masalah Teknologi Informasi – 6 Prinsip Pemecahan Masalah Ilmiah

Makalah ini akan menjelaskan pendekatan ilmiah untuk pemecahan masalah. Meskipun ditulis untuk mengatasi masalah-masalah terkait Teknologi Informasi, konsep-konsep ini juga dapat diterapkan dalam disiplin lain. Metode, konsep, dan teknik yang dijelaskan di sini bukanlah hal baru, tetapi mengejutkan berapa banyak "pemecah masalah" gagal menggunakannya. Di antara saya akan memasukkan beberapa contoh kehidupan nyata.

Mengapa para pemecah masalah menebak dengan tidak mengikuti pendekatan ilmiah untuk memecahkan masalah? Mungkin karena terasa lebih cepat? Mungkin kurangnya pengalaman dalam pemecahan masalah yang efisien? Atau mungkin karena itu terasa seperti kerja keras untuk melakukannya secara ilmiah? Mungkin saat Anda terus menebak dan tidak benar-benar menyelesaikan, Anda menghasilkan lebih banyak penghasilan dan menambahkan beberapa jaminan kerja? Atau mungkin karena Anda melanggar prinsip pertama pemecahan masalah: pahami masalahnya.

Prinsip # 1. Pahami masalah * nyata *.

Bukankah sudah jelas bahwa sebelum Anda bisa menyelesaikannya, Anda perlu memahami masalahnya? Mungkin. Namun, sebagian besar waktu solver akan mulai menyelesaikan tanpa mengetahui masalah sebenarnya. Apa yang klien atau pengguna gambarkan sebagai "Masalah" biasanya hanyalah gejalanya! "Komputer saya tidak mau menyala" adalah gejalanya. Masalah sebenarnya bisa jadi bahwa seluruh bangunan tanpa daya. "Setiap kali saya mencoba menambahkan produk baru, saya mendapat pesan kesalahan" adalah gejalanya. Di sini masalah sebenarnya adalah "Hanya 2 produk terakhir yang saya coba tambahkan yang memberi kesalahan 'Produk sudah ada'". Contoh klasik lain: "Tidak ada yang berfungsi" …

Anda memulai penyelidikan dengan mendefinisikan "masalah sebenarnya". Ini akan memerlukan mengajukan pertanyaan (dan kadang-kadang memverifikasi mereka), dan melakukan beberapa pengujian dasar. Tanyakan pertanyaan pengguna seperti "kapan terakhir kali berhasil?", "Sudah berapa lama Anda menggunakan sistem?", "Apakah ini berfungsi pada PC lain atau pengguna lain?", "Apa pesan kesalahan yang sebenarnya? " dll. Minta cetak-layar kesalahan jika memungkinkan. Pengujian dasar Anda adalah memastikan peralatan end-to-end sudah aktif dan berjalan. Periksa PC pengguna, jaringan, Server Web, Firewall, Server File, back-end Database, dll. Kasus terbaik Anda akan menunjukkan masalah. Terburuk-kasus Anda dapat menghilangkan banyak area untuk penyebab masalah.

Contoh kehidupan nyata. Gejala sesuai dengan pengguna: "Sistem hang pada waktu acak ketika saya melakukan pemesanan". Lingkungan: Pengguna memasukkan detail pesanan pada formulir dalam aplikasi mainframe. Ketika semua detail selesai, pengguna akan menghentikan formulir. Mainframe kemudian mengirimkan detail ini melalui perangkat lunak komunikasi ke sistem Klien / Server Oracle di pabrik. Sistem Oracle akan melakukan perencanaan kapasitas dan mengembalikan kesalahan atau tanggal pesanan yang diharapkan kembali ke sistem mainframe. Masalah ini cukup serius, karena Anda dapat kehilangan klien jika mereka mencoba melakukan pemesanan dan sistem tidak menerimanya! Untuk mencoba memecahkan masalah ini, orang mulai dengan menyelidiki: 1) Beban dan kapasitas perangkat keras mainframe 2) Pemantauan beban jaringan antara kerangka utama dan sistem Oracle 3) Mempekerjakan konsultan untuk mendebug perangkat lunak komunikasi 4) Meng-debug kapasitas Oracle sistem perencanaan Setelah menghabiskan beberapa bulan, mereka tidak bisa menyelesaikan masalah.

"Pemecah Masalah Ilmiah" dipanggil. Butuh waktu kurang dari sehari dan masalahnya terpecahkan! Bagaimana? Pemecah menghabiskan hari di pengguna untuk melihat apa yang "masalah sebenarnya" itu. Ditemukan bahwa masalah hanya terjadi dengan pesanan ekspor. Dengan menyelidiki layar tangkap dan tindakan pengguna, ditemukan bahwa dengan pesanan ekspor, bidang terakhir pada formulir selalu dibiarkan kosong dan pengguna tidak menghentikan bidang ini. Sistem tidak menggantung, menunggu pengguna untuk menekan "tab" lain waktu. Masalah dipecahkan. Dapat dicatat bahwa "Pemecah Masalah Ilmiah" memiliki pengetahuan yang sangat terbatas tentang mainframe, sistem penangkapan pesanan, perangkat lunak komunikasi, dan sistem perencanaan kapasitas Oracle. Dan ini membawa kita pada Prinsip # 2.

Prinsip # 2. Jangan takut untuk memulai proses penyelesaian, bahkan jika Anda tidak memahami sistemnya.

Berapa kali Anda mendengar "Saya tidak dapat menyentuh kode itu, karena itu dikembangkan oleh orang lain!", Atau "Saya tidak dapat membantu karena saya adalah Konsultan SDM dan itu adalah masalah Keuangan"? Jika Anda tidak ingin menyalakan mesin cuci, Anda tidak perlu menjadi Insinyur Listrik, Spesialis Perbaikan Mesin Cuci, Teknisi, atau spesialis apa pun untuk melakukan kesalahan mendasar. Pastikan colokannya berfungsi. Periksa tombol-perjalanan, dll. "Saya tidak pernah melihat kesalahan ini sebelumnya" seharusnya tidak menghentikan Anda untuk mencoba menyelesaikannya. Dengan pesan kesalahan dan mesin Pencarian Internet, Anda bisa mendapatkan banyak titik awal.

Di setiap sistem yang kompleks ada beberapa prinsip kerja dasar. Sistem A yang membaca data dari Sistem B dapat menjadi sangat kompleks (mungkin Spektrometer Laboratorium yang membaca data dari Komputer Logika yang Dapat Diprogram melalui port RS-232). Tetapi, beberapa dasar untuk diuji: Apakah kedua sistem memiliki kekuatan? Apakah ada pesan kesalahan di event log pada salah satu sistem ini? Bisakah Anda "ping" atau melacak paket jaringan dari satu sistem ke yang lain? Coba kabel komunikasi yang berbeda. Cari di internet untuk pesan kesalahan.

Setelah Anda menetapkan masalahnya, Anda harus mulai memecahkannya. Kadang-kadang penyelidikan awal akan mengarahkan Anda langsung ke solusi (nyalakan, ganti kabel yang salah, dll.). Tapi, kadang-kadang masalah sebenarnya sangat kompleks, jadi prinsip berikutnya adalah menyelesaikannya dengan sederhana.

Prinsip # 3. Menaklukkannya sederhana.

Mari kita mulai bagian ini dengan contoh kehidupan nyata. Dalam kondisi tertentu, prosedur yang tersimpan akan hang. Prosedur yang tersimpan biasanya membutuhkan waktu sekitar satu jam untuk dijalankan (ketika tidak menggantung). Jadi, pengembang mencoba melakukan debug. Buat perubahan dan tunggu satu jam atau lebih untuk melihat apakah masalah telah terpecahkan. Setelah beberapa hari, pengembang menyerah dan "Problem Solver" mengambil alih. The "Problem Solver" harus memiliki pengetahuan di bawah kondisi penyihir prosedur yang tersimpan akan menggantung. Jadi, ini adalah latihan sederhana untuk membuat salinan prosedur, dan kemudian dengan salinan ini untuk menghapus semua kode yang tidak perlu. Semua parameter diubah dengan nilai-nilai hard-coded. Bits kode dieksekusi pada suatu waktu dan hasilnya kemudian kembali dikodekan ke dalam salinan prosedur. Dalam waktu 3 jam masalah itu terpecahkan. Sebuah loop tak terbatas ditemukan.

Apa yang "Problem Solver" lakukan, adalah untuk mereplikasi masalah dan pada saat yang sama mencoba untuk mengisolasi kode yang menyebabkan masalah. Dengan demikian, prosedur tersimpan kompleks (dan memakan waktu) menjadi sesuatu yang cepat dan sederhana.

Jika masalahnya ada di dalam aplikasi, buat aplikasi baru dan cobalah untuk mensimulasikan masalah di dalam aplikasi baru sesederhana mungkin. Jika masalah terjadi ketika metode tertentu untuk kontrol tertentu dipanggil, maka cobalah untuk hanya memasukkan kontrol ini dalam aplikasi kosong dan memanggil metode tersebut dengan nilai-nilai hard-kode. Jika masalahnya adalah dengan embedded SQL di dalam aplikasi C #, maka cobalah untuk mensimulasikan SQL di dalam alat Query Database (seperti SQL * Plus untuk Oracle, Query Analyzer untuk SQL Server, atau gunakan kode di MS Excel melalui ODBC ke database ).

Saat Anda dapat mereplikasi masalah dengan cara yang sederhana, Anda lebih dari 80% dalam perjalanan untuk menyelesaikannya.

Jika Anda tidak tahu di mana di dalam program masalahnya, maka gunakan DEBUG.

Prinsip # 4. Debug.

Kebanyakan alat pengembangan aplikasi menjadi standar dengan debugger. Cuaca itu adalah Macromedia Flash, Microsoft Dot Net, Delphi, atau apa yang pernah lingkungan pengembangan akan ada semacam debugger. Jika alat tidak datang standar dengan debugger, maka Anda dapat mensimulasikannya.

Hal pertama yang ingin Anda lakukan dengan debugger adalah menentukan di mana masalahnya. Anda melakukan ini dengan menambahkan breakpoint di area utama. Kemudian Anda menjalankan program dalam mode debug dan Anda akan tahu di antara mana breakpoint masalah terjadi. Bor bawah dan Anda akan menemukan tempat itu. Sekarang Anda tahu di mana masalahnya, Anda dapat "menaklukkannya dengan mudah"

Fitur bagus lainnya dari kebanyakan debugger termasuk fasilitas untuk melihat variabel, nilai, parameter, dll. Saat Anda melangkah melalui program. Dengan nilai-nilai ini dikenal pada langkah-langkah tertentu, Anda dapat meng-kode-kan mereka ke dalam "versi sederhana" Anda dari program

Jika alat pengembangan tidak mendukung debugging, maka Anda dapat mensimulasikannya. Masukkan langkah-langkah dalam program yang menghasilkan nilai variabel dan pesan "halo saya di sini" baik ke layar, ke file log, atau ke tabel database. Ingatlah untuk mengeluarkannya ketika masalah teratasi … Anda tidak ingin sistem file Anda menjadi berantakan atau diisi dengan file-file log!

Prinsip # 5. Ada banyak informasi di back-end database yang akan membantu memecahkan masalah.

The "Problem Solver" dipanggil untuk membantu memecahkan masalah yang sangat rumit. Sebuah proyek memigrasi sistem dari mainframe ke teknologi client-server. Semua berjalan baik selama pengujian, tetapi ketika sistem mulai hidup, tiba-tiba ada beberapa, dan "Kesalahan Perlindungan Umum" yang cukup acak. (Galat GPF adalah jebakan kesalahan umum pada Windows 95 dan 98). Itu mencoba menyederhanakan kode, debugging dicoba, tetapi tidak mungkin untuk ditiru. Di lingkungan LAB, masalah tidak akan terjadi! Debugging trace messages to log files mengindikasikan bahwa masalah terjadi sangat acak. Beberapa pengguna mengalaminya lebih dari yang lain, tetapi akhirnya semua pengguna akan mendapatkannya! Masalah yang menarik.

The "Problem Solver" memecahkan ini setelah ia mulai menganalisis back-end database. Tidak yakin apakah itu secara kebetulan atau karena dia secara sistematis pindah ke arah yang benar karena pendekatan ilmiah. Melalui penelusuran apa yang terjadi pada tingkat back-end, ditemukan bahwa semua aplikasi ini menciptakan lebih banyak koneksi ke database. Setiap kali pengguna memulai transaksi baru, koneksi lain dibuat ke basis data. Jumlah total koneksi hanya dirilis ketika aplikasi ditutup. Ketika pengguna menavigasi ke jendela baru di dalam aplikasi yang sama, semakin banyak koneksi dibuka, dan setelah sejumlah koneksi tertentu, aplikasi akan memiliki cukup dan kemudian crash. Ini adalah kesalahan pemrograman dalam template yang digunakan oleh semua pengembang. Solusinya adalah untuk menguji terlebih dahulu apakah kursor ke database sudah terbuka, sebelum membukanya lagi.

Bagaimana Anda menelusuri basis data back-end apa yang terjadi? Penyedia basis data utama memiliki alat GUI yang membantu Anda melacak atau menganalisis kueri apa yang diluncurkan terhadap basis data. Ini juga akan menunjukkan kepada Anda ketika orang terhubung, memutuskan sambungan, atau tidak dapat terhubung karena pelanggaran keamanan. Sebagian besar basis data juga menyertakan beberapa tabel kamus sistem yang dapat diminta untuk mendapatkan informasi ini. Jejak-jejak ini terkadang bisa memberi tahu seluruh kisah mengapa ada yang gagal. Kode kueri yang Anda ambil dari pelacakan dapat membantu "menyederhanakan penelusuran". Anda dapat melihat dari jejak jika program berhasil melakukan kontak dengan database. Anda dapat melihat berapa lama waktu yang diperlukan untuk mengeksekusi kueri.

Untuk menambah Prinsip # 2 (jangan takut untuk memulai …); Anda dapat menganalisis informasi jejak ini, meskipun Anda mungkin tidak tahu apa-apa tentang detail aplikasi.

Ingat meskipun bahwa jejak-jejak back-end dapat menempatkan beban pada sumber daya back-end. Jangan biarkan mereka berlari untuk waktu yang tidak perlu.

Prinsip # 6. Gunakan mata segar.

Ini adalah prinsip terakhir. Jangan terlalu banyak menghabiskan waktu untuk masalah sebelum Anda meminta bantuan. Bantuan tidak harus dari seseorang yang lebih senior dari Anda. Prinsipnya adalah Anda perlu sepasang mata segar untuk perspektif baru dan terkadang sedikit udara segar dengan istirahat. Orang lain akan melihat dan kemudian mengajukan satu atau dua pertanyaan. Kadang-kadang itu adalah sesuatu yang sangat jelas yang terlewatkan. Terkadang hanya dengan menjawab pertanyaan itu membuat Anda berpikir ke arah yang baru. Juga, jika Anda menghabiskan berjam-jam melihat potongan kode yang sama, sangat mudah untuk mulai mencari kesalahan konyol. Banyak masalah keseimbangan keuangan diselesaikan dengan bir. Bisa jadi perubahan pemandangan, dan / atau suasana santai yang akan muncul solusinya. Mungkin itu adalah oksigen segar yang masuk ke otak sambil berjalan ke pub. Mungkin itu karena masalahnya didiskusikan dengan orang lain.

Kesimpulan

Setelah membaca makalah ini, penulis berharap Anda akan mencoba ini pada saat Anda menghadapi masalah untuk dipecahkan. Mudah-mudahan dengan menerapkan keenam prinsip ini, Anda akan menyadari keuntungan yang mereka bawa, daripada "menebak" jalan Anda menuju solusi.