Teknologi

Pemecahan Masalah TI – Enam Prinsip untuk Memecahkan Masalah Ilmiah

[ad_1]

Makalah ini menjelaskan pendekatan ilmiah untuk pemecahan masalah. Meskipun ditulis untuk mengatasi masalah yang berkaitan dengan teknologi informasi, konsepnya juga dapat diterapkan pada disiplin ilmu lain. Metode, konsep, dan teknik yang dijelaskan di sini bukanlah hal baru, tetapi yang mengejutkan adalah banyaknya “pemecah masalah” yang gagal menggunakannya. Di antaranya, saya akan menyertakan beberapa contoh dunia nyata.

Mengapa menebak pemecahan masalah daripada pendekatan ilmiah untuk pemecahan masalah? Mungkin karena tampaknya lebih cepat? Mungkin kurangnya pengalaman dalam memecahkan masalah secara efisien? Atau mungkin karena sepertinya kerja keras untuk melakukannya secara ilmiah? Mungkin saat Anda terus menebak-nebak dan bukan solusinya, Anda menghasilkan lebih banyak pendapatan dan menambah keamanan kerja? Atau mungkin karena Anda melanggar prinsip pertama pemecahan masalah: memahami masalah.

Prinsip #1. Pahami masalah sebenarnya.

Bukankah sudah jelas bahwa Anda perlu memahami masalah sebelum Anda dapat menyelesaikannya? Bisa. Namun, sebagian besar waktu, analis akan mulai memecahkan masalah tanpa mengetahui masalah sebenarnya. Apa yang pelanggan atau pengguna gambarkan sebagai “masalah” biasanya hanya ditampilkan! Tampilan “Komputer saya tidak mau menyala”. Masalah sebenarnya mungkin bahwa seluruh bangunan tanpa listrik. Tampilan “Setiap kali saya mencoba menambahkan produk baru saya mendapatkan pesan kesalahan”. Di sini masalah sebenarnya adalah “Hanya dua produk terakhir yang saya coba tambahkan yang memberikan kesalahan ‘Produk sudah ada’.” Contoh klasik lainnya: “Tidak ada yang berfungsi”…

Anda memulai penyelidikan dengan mengidentifikasi “masalah sebenarnya”. Ini akan memerlukan mengajukan (dan kadang-kadang memeriksa) pertanyaan dan mengambil beberapa tes dasar. Ajukan pertanyaan kepada pengguna seperti “Kapan terakhir kali berhasil?” , “Sudah berapa lama Anda menggunakan sistem ini?” , “Apakah ini berfungsi di komputer lain atau pengguna lain?” , “Apa sebenarnya pesan kesalahan itu?” dll. Mintalah untuk mencetak kesalahan jika memungkinkan. Tes utama Anda adalah untuk memastikan bahwa peralatan lengkap dan berjalan. Periksa komputer pengguna, jaringan, server web, firewall, server file, database backend, dll. Kasus terburuk Anda dapat menghilangkan banyak domain untuk menyebabkan masalah.

Contoh kehidupan nyata. Gejala oleh pengguna: “Sistem rusak secara acak saat melakukan pemesanan.” Lingkungan: Pengguna memasukkan detail pesanan ke dalam formulir di aplikasi mainframe. Ketika semua rincian selesai, pengguna akan menutup formulir. Komputer master kemudian mengirimkan rincian ini melalui perangkat lunak komunikasi ke sistem Oracle Client/Server pabrik. Sistem Oracle akan memplot kapasitas dan mengembalikan kesalahan atau tanggal perintah yang diharapkan ke sistem komputer utama. Masalah ini sangat serius, karena Anda bisa kehilangan pelanggan jika mereka mencoba memesan dan sistem tidak menerimanya! Untuk mencoba untuk memecahkan masalah ini, orang-orang mulai untuk menyelidiki: 1) beban dan kapasitas komputer utama 2) memonitor beban jaringan antara komputer utama dan sistem oracle 3) menunjuk konsultan untuk men-debug software komunikasi 4) men-debug oracle sistem perencanaan kapasitas setelah menghabiskan dua bulan mereka tidak bisa memecahkan masalah.

Itu disebut “pemecah masalah ilmiah”. Butuh waktu kurang dari satu hari dan masalahnya telah diperbaiki! Bagaimana? Analis menghabiskan hari pengguna untuk melihat apa “masalah sebenarnya” itu. Ditemukan bahwa masalah hanya terjadi dengan perintah ekspor. Dengan memeriksa layar tangkap dan tindakan pengguna, ditemukan bahwa dengan perintah ekspor, bidang terakhir pada formulir selalu dikosongkan dan pengguna tidak menampilkan bidang itu. Sistem tidak hang, hanya menunggu pengguna menekan “tab” lagi. Masalah telah diselesaikan. Perlu dicatat bahwa Pemecah Masalah Ilmiah memiliki pengetahuan yang sangat terbatas tentang komputer mainframe, sistem pengambilan pesanan, perangkat lunak komunikasi, dan sistem perencanaan kapasitas Oracle. Ini membawa kita ke prinsip nomor 2.

Prinsip #2. Jangan takut untuk memulai proses solusi, meskipun Anda tidak memahami sistemnya.

Berapa kali Anda mendengar “Saya tidak dapat menyentuh kode ini, karena dikembangkan oleh orang lain!” , atau “Saya tidak bisa membantu karena saya seorang konsultan SDM dan ini masalah keuangan”? Jika Anda tidak ingin menjalankan mesin cuci Anda, Anda tidak perlu menjadi insinyur listrik, tukang reparasi mesin cuci, teknisi, atau profesional lainnya untuk melakukan beberapa pemecahan masalah dasar. Pastikan steker berfungsi. Periksa sakelar penerbangan, dll., “Saya belum pernah melihat kesalahan ini sebelumnya” seharusnya tidak menghentikan Anda untuk mencoba memperbaiki masalah. Dengan pesan kesalahan dan mesin pencari Internet, Anda bisa mendapatkan banyak titik awal.

Dalam setiap sistem yang kompleks ada dua prinsip kerja dasar. Sistem A membaca data dari Sistem B bisa sangat rumit (mungkin spektrometer laboratorium yang membaca data dari komputer logika yang dapat diprogram melalui port RS-232). Namun, ada beberapa dasar untuk diuji: Apakah kedua sistem memiliki daya? Apakah ada pesan kesalahan dalam log peristiwa di salah satu sistem ini? Bisakah Anda “ping” atau melacak paket jaringan dari satu sistem ke sistem lain? Coba kabel koneksi lain. Cari di Internet untuk pesan kesalahan.

Setelah Anda mengidentifikasi masalah, Anda harus mulai memecahkannya. Terkadang penyelidikan awal akan mengarahkan Anda ke solusi (nyalakan daya, ganti kabel yang rusak, dll.). Tapi, terkadang masalah sebenarnya rumit, jadi prinsip selanjutnya adalah menyelesaikannya secara sederhana.

Prinsip #3. Menaklukkan itu sederhana.

Mari kita mulai bagian ini dengan contoh kehidupan nyata. Dalam kondisi tertentu, prosedur tersimpan akan ditangguhkan. Prosedur tersimpan biasanya membutuhkan waktu sekitar satu jam untuk dijalankan (bila tidak tertunda). Oleh karena itu, pengembang mencoba memperbaiki kesalahan tersebut. Buat beberapa perubahan, lalu tunggu sekitar satu jam lagi untuk melihat apakah masalah telah teratasi. Setelah beberapa hari, pengembang menyerah dan melakukan “pemecahan masalah”. Pemecah Masalah yang dimilikinya harus tahu bahwa prosedur tersimpan akan macet dalam keadaan ajaib. Oleh karena itu, pekerjaan salinan prosedur adalah latihan sederhana, dan kemudian menggunakan salinan ini untuk menghapus semua kode tidak perlu. Semua parameter telah diubah dengan nilai yang dikodekan. Potongan kode dieksekusi satu per satu dan set hasil kemudian dikodekan kembali ke dalam instance prosedur. Dalam waktu 3 jam masalah teratasi. Loop tak terbatas terdeteksi.

Apa yang dilakukan Pemecahan Masalah adalah mereplikasi masalah dan pada saat yang sama mencoba mengisolasi kode yang menyebabkan masalah. Dengan demikian, prosedur tersimpan yang kompleks (dan memakan waktu) menjadi hal yang cepat dan sederhana.

Jika masalahnya ada di dalam aplikasi, buat aplikasi baru dan coba simulasikan masalah di dalam aplikasi baru sesederhana mungkin. Jika masalah terjadi saat metode tertentu dipanggil untuk kontrol tertentu, coba sertakan hanya kontrol itu dalam aplikasi kosong dan panggil metode itu dengan nilai hardcoded. Jika masalahnya ada pada SQL yang disematkan dalam aplikasi C#, coba simulasikan SQL dalam alat kueri basis data (mis. SQL* Plus untuk Oracle, Penganalisis Kueri untuk SQL Server, atau gunakan kode di MS Excel melalui ODBC ke basis data).

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

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

Prinsip No. 4. Koreksi.

Sebagian besar alat pengembangan aplikasi datang standar dengan debugger. Apakah itu Macromedia Flash, Microsoft Dot Net, Delphi, atau lingkungan pengembangan apa pun akan ada semacam debugger. Jika alat tidak datang standar dengan debugger, Anda dapat mensimulasikan salah satunya.

Hal pertama yang ingin Anda lakukan dengan debugger adalah menentukan di mana masalahnya. Anda dapat melakukan ini dengan menambahkan breakpoint di area utama. Kemudian Anda menjalankan program dalam mode debug dan Anda akan mengetahui titik henti sementara di mana masalah terjadi. Gali ke bawah dan Anda akan menemukan tempatnya. Sekarang Anda tahu di mana masalahnya, Anda bisa “mengalahkannya”

Fitur bagus lainnya dari sebagian besar debugger termasuk kemampuan untuk melihat variabel, nilai, parameter, dll. saat Anda menelusuri program. Dengan menggunakan nilai-nilai yang diketahui ini dalam langkah-langkah tertentu, Anda dapat menyandikannya dalam “Versi Sederhana” dari program

Jika alat pengembangan tidak mendukung debugging, 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 saat Anda menyelesaikan masalah… Anda tidak ingin sistem file Anda berantakan atau penuh dengan file log!

Prinsip # 5. Ada banyak informasi tentang database backend yang akan membantu memecahkan masalah.

Pemecah Masalah telah dipanggil untuk membantu memecahkan masalah yang sangat sulit. Ada proyek yang memigrasikan sistem dari teknologi mainframe ke server klien. Itu berjalan dengan baik selama pengujian, tetapi ketika sistem dimulai, tiba-tiba ada beberapa “kesalahan perlindungan umum” dan cukup acak. (Kesalahan GPF adalah jebakan kesalahan umum di Windows 95 dan 98.) Upaya telah dilakukan untuk menyederhanakan kode, upaya dilakukan untuk men-debug, tetapi tidak mungkin untuk mereplikasinya. Dalam lingkungan LAB, masalah tidak akan terjadi! Debugging file log melacak pesan menunjukkan bahwa masalah terjadi sangat acak. Beberapa pengguna telah mengujinya lebih dari yang lain, tetapi pada akhirnya semua pengguna akan mendapatkannya! masalah yang menarik.

Pemecah Masalah memecahkan masalah ini setelah dia mulai menganalisis database backend. Saya tidak yakin apakah itu kebetulan atau karena telah dipindahkan secara sistematis ke arah yang benar karena pendekatan ilmiah. Dengan melacak apa yang terjadi di tingkat back-end, dia menemukan bahwa semua aplikasi ini menciptakan lebih banyak koneksi ke database. Setiap kali pengguna memulai transaksi baru, koneksi lain dibuat ke database. Jumlah total koneksi hanya dirilis saat aplikasi ditutup. Saat pengguna membuka jendela baru dalam aplikasi yang sama, semakin banyak koneksi yang dibuka, setelah sejumlah koneksi yang ditetapkan, aplikasi akan cukup dan kemudian macet. Ini adalah bug pemrograman dalam template yang digunakan oleh semua pengembang. Solusinya adalah menguji terlebih dahulu apakah pointer database sudah terbuka, sebelum membukanya lagi.

Bagaimana Anda melacak apa yang terjadi di database backend? Penyedia basis data utama memiliki alat antarmuka pengguna grafis (GUI) yang membantu Anda melacak atau menganalisis kueri yang diluncurkan pada basis data. Ini juga akan menunjukkan kepada Anda ketika orang terhubung, terputus atau tidak dapat terhubung karena pelanggaran keamanan. Sebagian besar database juga menyertakan beberapa tabel kamus sistem yang dapat ditanyakan untuk informasi ini. Efek-efek ini terkadang dapat menceritakan keseluruhan cerita mengapa sesuatu gagal. Kode kueri yang Anda ambil dari pelacakan dapat membantu “menyederhanakan pencarian”. Anda dapat melihat dari jejak apakah program berhasil terhubung ke database. Anda dapat melihat berapa lama waktu yang dibutuhkan untuk mengeksekusi kueri.

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

Ingatlah bahwa backend ini dapat membebani sumber daya backend. Jangan biarkan berjalan untuk waktu yang tidak perlu lama.

Prinsip nomor 6. Gunakan mata yang segar.

Ini adalah prinsip terakhir. Jangan buang waktu terlalu banyak untuk memecahkan masalah sebelum Anda meminta bantuan. Bantuan tidak harus datang dari seseorang di atas Anda. Prinsipnya adalah Anda membutuhkan sepasang mata yang segar untuk perspektif yang segar dan terkadang sedikit udara segar dengan istirahat. Orang lain akan mencari dan kemudian mengajukan satu atau dua pertanyaan. Terkadang ini adalah sesuatu yang sangat jelas sehingga mereka terlewatkan. Terkadang hanya menjawab pertanyaan membuat Anda berpikir ke arah yang baru. Juga, jika Anda menghabiskan waktu berjam-jam mencari bagian kode yang sama, sangat mudah untuk mulai mencari bug konyol. Banyak masalah anggaran keuangan diselesaikan dengan bir. Ini bisa berupa perubahan pemandangan, dan/atau suasana santai yang akan memunculkan solusi. Mungkin oksigen segar yang masuk ke otak saat berjalan ke bar. Mungkin karena masalahnya sudah dibicarakan dengan orang lain.

kesimpulan

Setelah membaca makalah ini, penulis berharap Anda akan mencoba ini lain kali Anda memiliki masalah yang perlu dipecahkan. Kami berharap bahwa dengan menerapkan enam prinsip ini Anda menyadari keuntungan yang mereka bawa, daripada “menebak” jalan Anda menuju solusi.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button