Bazı ilkeler o kadar temel ve bozulmazdır ki, yanlış uygulama için EVA ilkesi de dahil olmak üzere çeşitli durumlarda yardımcı olurlar.
Son blogumun üzerinden epey zaman geçti. Almanya’da yaz, tabiri caizse, bitti ve sonbahar geliyor. “İyi organize edilmiş” blogda yeni bir gönderi için bolca zaman var.
Bugün “Uygulama hataları nasıl ele alınır” blog yazımı takip etmek istiyorum. O zamanlar, bir hata durumunda bilgi toplamak için yönlendirici soruları kullanmak hakkında yazmıştım. Önerilen anahtar sorular şunları içeriyordu: “Hata ne zaman oluştu?” ve “Hata nasıl çoğaltılabilir?”.
Şaşırtıcı bir şekilde, çok eski bir BT konsepti, bir süreçte bu soruları ve ilgili problem analizini cevaplarken biraz daha yardımcı olur: EVA (girdi, işleme, çıktı) ilkesi. İngilizce’de “IPO modeli” (Input-Process-Output) olarak adlandırılır. İlke, veri işlemeyi üç alt aşamaya ayırır: girdi, işleme ve çıktı.
Örnek verecek olursak şöyle görünebilir: Bir ürün listeleme uygulamasında, seçim sırasında klavyeden 4711 ve 4712 ürün numaralarını girmektedir. Yürütmeyi Enter tuşuyla onaylayın ve kısa bir süre sonra ekranda bir liste alır. Ancak, “Ürün Açıklaması” sütunundaki listeleme yalnızca “®¯®à ¾” gibi şifreli karakterler içermektedir. Ancak kullanıcı, özellikle bir gün önce bu ürün numaralarıyla çalıştığı ve ürün açıklamasının doğru olduğu için, ilgili ürünün anlaşılır bir açıklamasını bekliyordu. Bu nedenle, teknik alanda hatanın nedeninden şüphelenin ve açıklığa kavuşturmak için destek ekibiyle iletişime geçin.
Bu örnek, üç alt adımı anlamayı kolaylaştırır. Yetkilendirmeye bağlı olarak, adımlar destek temsilcisi tarafından kolayca yeniden üretilebilir. Ekran çıktısına bağlı olarak, hatanın nedeni artık geriye doğru izlenebilir. Gerçekten çıktı mı yoksa işlem sırasında hata mı oluşuyor? Örneğin, liste işleme sırasında yanlış derlenebilir veya şifreli karakterler doğrudan veritabanından gelebilir. Tüm olası nedenler.
Örneği biraz değiştirirseniz ve çıktı bir yazıcıdaysa, bu destek personeli için paha biçilmez bir bilgidir. Girişin klavye aracılığıyla değil, bir barkod tarayıcı aracılığıyla yapıldığı ve ürün numaralarının “®¯®à ¾” gibi şifreli karakterler olarak görüntülendiği bir örnek düşünülebilir. Kullanıcı işlemeye veya çıktıya bile ulaşamıyor.
Örnekler, EVA ilkesinin olanaklarını ve avantajlarını göstermektedir: çeşitli yönleri bir sırayla birleştirir ve anlaşılması kolaydır. Bu, yalnızca çok kaba bir fikir veya sınıflandırmaya izin verse bile, hızlı ve kolay bir şekilde eğitilmesi ve kullanılması için idealdir. Elbette, destek sürecini iyileştirmek için bağımsız iyileştirmelere izin verilir.
Ayrıca, EVA ilkesi, katma değerini temel bir ilke olarak gösteren diğer birçok tipik BT durumunda da rol oynar. Günlük yaşamda artık farkında olmasanız bile…
Bunu akılda tutarak, yapılandırılmış ve sağlıklı kalın
senin Michael’ın
()
Haberin Sonu
Son blogumun üzerinden epey zaman geçti. Almanya’da yaz, tabiri caizse, bitti ve sonbahar geliyor. “İyi organize edilmiş” blogda yeni bir gönderi için bolca zaman var.
Bugün “Uygulama hataları nasıl ele alınır” blog yazımı takip etmek istiyorum. O zamanlar, bir hata durumunda bilgi toplamak için yönlendirici soruları kullanmak hakkında yazmıştım. Önerilen anahtar sorular şunları içeriyordu: “Hata ne zaman oluştu?” ve “Hata nasıl çoğaltılabilir?”.
Şaşırtıcı bir şekilde, çok eski bir BT konsepti, bir süreçte bu soruları ve ilgili problem analizini cevaplarken biraz daha yardımcı olur: EVA (girdi, işleme, çıktı) ilkesi. İngilizce’de “IPO modeli” (Input-Process-Output) olarak adlandırılır. İlke, veri işlemeyi üç alt aşamaya ayırır: girdi, işleme ve çıktı.
Örnek verecek olursak şöyle görünebilir: Bir ürün listeleme uygulamasında, seçim sırasında klavyeden 4711 ve 4712 ürün numaralarını girmektedir. Yürütmeyi Enter tuşuyla onaylayın ve kısa bir süre sonra ekranda bir liste alır. Ancak, “Ürün Açıklaması” sütunundaki listeleme yalnızca “®¯®à ¾” gibi şifreli karakterler içermektedir. Ancak kullanıcı, özellikle bir gün önce bu ürün numaralarıyla çalıştığı ve ürün açıklamasının doğru olduğu için, ilgili ürünün anlaşılır bir açıklamasını bekliyordu. Bu nedenle, teknik alanda hatanın nedeninden şüphelenin ve açıklığa kavuşturmak için destek ekibiyle iletişime geçin.
Bu örnek, üç alt adımı anlamayı kolaylaştırır. Yetkilendirmeye bağlı olarak, adımlar destek temsilcisi tarafından kolayca yeniden üretilebilir. Ekran çıktısına bağlı olarak, hatanın nedeni artık geriye doğru izlenebilir. Gerçekten çıktı mı yoksa işlem sırasında hata mı oluşuyor? Örneğin, liste işleme sırasında yanlış derlenebilir veya şifreli karakterler doğrudan veritabanından gelebilir. Tüm olası nedenler.
Örneği biraz değiştirirseniz ve çıktı bir yazıcıdaysa, bu destek personeli için paha biçilmez bir bilgidir. Girişin klavye aracılığıyla değil, bir barkod tarayıcı aracılığıyla yapıldığı ve ürün numaralarının “®¯®à ¾” gibi şifreli karakterler olarak görüntülendiği bir örnek düşünülebilir. Kullanıcı işlemeye veya çıktıya bile ulaşamıyor.
Örnekler, EVA ilkesinin olanaklarını ve avantajlarını göstermektedir: çeşitli yönleri bir sırayla birleştirir ve anlaşılması kolaydır. Bu, yalnızca çok kaba bir fikir veya sınıflandırmaya izin verse bile, hızlı ve kolay bir şekilde eğitilmesi ve kullanılması için idealdir. Elbette, destek sürecini iyileştirmek için bağımsız iyileştirmelere izin verilir.
Ayrıca, EVA ilkesi, katma değerini temel bir ilke olarak gösteren diğer birçok tipik BT durumunda da rol oynar. Günlük yaşamda artık farkında olmasanız bile…
Bunu akılda tutarak, yapılandırılmış ve sağlıklı kalın
senin Michael’ın
()
Haberin Sonu