İstek mi İhtiyaç mı Yoksa Problem mi? – I

İş ve İhtiyaç Analizi, Yazılım Mühendisliği

Bir yazılım projesi için en riskli durumlardan birisi de, o projeye girdi sağlayacak kullanıcıların, “işte istediğimiz an geldi, ne istiyorsak yaptıralım” şeklinde bir fikre sahip olmalarıdır. Dünyada hiç bir kimse, istediği her şeyi elde edemiyor, öbür dünyada bu söz konusu olabilir ama bu dünyada daha gerçekçi olmalıyız. Hayallerimiz ile gerçeklik arasındaki bu durum her şeyde geçerli olduğu gibi yazılım için de geçerlidir.

Yazılım zor zenaat, bu çok açık. Bu günlükte bu konuda pek çok yazı yayınlandı. Yazılımla ilgili pek çok şey, onun “zor” olmasına sebep oluyor. Örneğin onun kavramsal olan yapısı, algoritmik yapılarının karmaşıklığı, vs. Bu yazıda yazılımın karmaşıklığının en temel sebeplerinden birisi olan kullanıcı isteklerinden bahsedeceğim.

Yazılım, onu kullanacak olanlar için geliştirilir. Kullanıcılar, yazılım ile işlerini sadece daha hızlı yapmakla kalmaz aynı zamanda daha etkin bir şekilde yaparlar. Bu anlamda yazılım sistemleri çoğu defa iş yapış şeklimizi değiştiriler ya da değiştirmeleri beklenir. Gerçi bu ülkede özellikle devlet kurumlarında eski ve köhne anlayışla uygulanmakta olan pek çok alışkanlığın yazılımlara da taşındığını, bundan dolayı da yazılımların bilgisayarları sadece hızlı ve geniş hafızalı birer daktiloya dönüştürdüğüne çok sık şahit oluyoruz.

Neyse, konumuza dönersek, şunu rahatlıkla iddia edebiliriz ki yazılımlar, kullanıcılarının istekleri için geliştirilmezler. (Tabi yazılımlar derken burada iş yazılımlarını kastediyoruz, oyun ve eğlence sektörüne yönelik yazılımları ayrı bir kategoride değerlendirmek lazım.) Yazılımların bu kadar karmaşık olmasının, bu kadar sık değişmesinin, nihayetinde yazılım şirketleri ile BT bölümlerinin aşırı iş yoğunluğu altında ezilmesinin en temel sebebi, kullanıcıların, işlerini doğru ve etkin bir şekilde yapabilmek için neye ihtiyaçları olduğunu bilmemeleridir. İşine sistematik olarak bakamayan, onun hakkında düşünmek için, yaptığı işi daha basit, kolay ve etkin olarak nasıl yapacağını kurgulamaya, örneğin müşteriye verilecek hizmetin kalitesini arttırmayı düşünmeye vakit ayır(a)mayan kullanıcıların, proje başladığında, o projeye ihtiyaçlarıyla ilgili sağlıklı girdiler üretebilmesi de imkansızdır. Çoğu zaman yeni bir proje, kullanıcıların normal operasyonel iş yüklerinden bir şey eksiltmeden onlara fazladan yük getirdiğinden kullanıcılar tarafından angarya olarak bile görülebilmektedir. Dolayısıyla ne normal gündelik çalışmasında ne de proje esnasında, proje sorumluluklarının bir parçası olarak işini bir yazılım sistemiyle nasıl daha basit ve etkin hale getireceğine odaklanmayan kullanıcının, “ihtiyaçların nelerdir?” sorusuna verecekleri tek cevap, akıllarına ilk gelen ve çoğunlukla ihtiyaç bile olmayan isteklerdir. Bir de buna, “bu bizim için çok büyük bir fırsattır, ne istiyorsanız söyleyin” diye takıma moral ve motivasyon 🙂 aşılayan iş yöneticileri eklenirse varın bakın siz eğlenceye 🙂 Böyle projeler insanı bitirir ama kendileri bitmezler.

Yazılımların ve yazılım projelerinin en büyük risklerinden birisi kullanıcı ihtiyaçlarına değil de kullanıcı isteklerine odaklı olmasıdır. Dolayısıyla “kullanıcı istekleri” kavramı da yazılım ihtiyaçları açısından ele alındığında son derece sakıncalı bir kavramdır. Bu anlamda ben yazılım ihtiyaçları yerine “isterler” denmesine son derece karşıyım. Nedir isterler? Herkes her şeyi ister! Ama yazılımlar istekleri yerine getirmek için değil ihtiyaçları gidermek için geliştirilirler. İnsanların iş ihtiyaçlarına odaklanmadan isteklerine odaklanmaları, yani isteklerini ifade etmeden önce onların ne kadar ihtiyaçlarını gideren istekler olduklarını, ihtiyaçlarıyla ne kadar örtüştüğünü düşünmeleri gereklidir. Aksi taktirde isteklerini yerine getirmesine rağmen ihtiyaçlarını karşılamayan yazılımları kullanmak zorunda kalmaları kaçınılmazdır.

Bu duruma yazılımı geliştirenler açısından bakıldığında ise en iyi tarafından yazılımların bütçe ve zaman açısından planlananın dışına ciddi oranlarda sarkması sonucu ortaya çıkmaktadır. Daha kötüsü ise bitmeyen, iptal edilen projelerdir. Hayata geçse bile böyle projelerde geliştirilen şey, çoğu zaman incik-cıncık özelliklerle bezenmiş dolayısıyla da iç tutarlılığı (integrity) olmayan, nihayetinde kullanışsız, üzerine tonla emek harcanmış  pek çok özelliği kullanılmayan ama buna karşın en temel ihtiyaçlarla ilgili hala eksikleri olan yazılımlardır.

Bu blogda sıklıkla kendisinden alıntı yaptığım F. Brooks “No Silver Bullet” isimli makalesinde yazılımın doğasından bahsederken “uyumluluk” (confirmity) bahsinde bakın ne diyor:

“Uyumluluk: Karmaşıklıkla karşılaşma noktasında yazılımcılar yalnız değillerdir. Fizikçiler “temel” parçaçık seviyesindeki son derece karmaşık nesnelerle uğraşırlar. Fakat bir fizikçi, kuarklarda olsun, birleşik alan teorilerinde olsun hepsi için genel geçer prensiplerin bulunacagına dair sağlam bir inançla çalışır. Einstein, doğanın basitleştirilmiş açıklamalarının olması gerektiğini çünkü Tanrı’nın kaprisli ya da rastgele davranmayacağını ileri sürmüştü.

Böyle bir inanç, bir yazılım mühendisini kesinlikle rahatlatmaz. Çünkü üstesinden gelmek zorunda olduğu karmaşıklığın büyük çoğunluğu rastgele karmaşıklıktır ki pek çok insani kurum ya da sistem tarafından mantıksızca oluşturulmuştur ve yazılım mühendisinin arayüzleri bu yapılarla uyum içinde çalışmalıdır. Yazılım mühendisinin geliştirdiği bu arayüzler, arayüzden arayüze, zamandan zamana değişir ama bu durumun sebebi ihtiyaçlar değildir, sadece Tanrı yerine farklı kişiler tarafından tasarlanmış olmalarıdır.

Pek çok durumda yazılım uyumlu olmalıdır çünkü sahneye en son gelen odur. Diğer pek çok durumda da, yazılımın uyum  yeteneğinin yüksek olduğu düşünüldüğü için uyumlu olmak zorundadır. Fakat bütün bu durumlarda karmaşıklığın büyük çoğunluğu, diğer arayüzlere uyumdan kaynaklanmaktadır ki böyle bir karmaşıklık sadece yazılımın tekrardan tasarlanmasıyla basitleştirilemez.”

Bu yüzden iş yöneticileri hem kendilerine hem de birlikte çalıştıkları kullanıcılara, istekleri üzerinden değil de ihtiyaçları üzerinden hareket etmeleri için zaman ve fırsat tanımalılar, kendilerinin ve çalışanlarının farkındalıklarının bu yönde gelişmesine yardımcı olmalılardır. Aksi taktirde yazılımcılara boşuna saydırmaya devam ederiz.

Toplam görüntülenme sayısı: 1368

Yazılım ve Değişim – I

Yazılım Mühendisliği

Yazılım zor zenaat, bu çok açık. Çünkü yazılım, diğer mühendislik dalları gibi fiziksel değil, soyut bir uğraş alanı. Yazılımın soyut olan doğası, onun durumunu tüm detaylarıyla anlamayı imkansız hale getiriyor. Çünkü kontrol altında tutabildiğimiz etmenler, kontrol altında tutamadıklarımız yanında sayıca çok daha az. Bu yüzden örneğin bir yazılımı her türlü detayıyla test etmek pratikte imkansızdır. Bu yazıda, yazılımın karmaşık yapısı kadar önemli olan değişkenliğini ele almaya çalışacağım.

Hemen herkes yazılımda değişmesi mümkün olmayan bir şey olmadığında hemfikirdir. Yani yazılımda her şey değişebilir, tek fark değişimin maliyeti olabilir. Diğer mühendislik ürünlerindeki degişimi düşündüğümüzde, yazılımdaki değişmeyle çok ciddi mahiyet farklılıkları olduğunu gözlemleyebiliriz. Örneğin, araçlardaki, binalardaki ya da köprülerdeki değişimle ilgili konuştuğumuzda, yani inşaat ve makina mühendisliğinin ürünlerini ele aldığımızda, değişmenin asıl sebebinin ilgili malzemenin aşınmış, bozulmuş vb. durumda olması olduğunu söyleyebiliriz. Bu durumda yedek malzemelerin, orijinal olanlarla, montaj noktaları gibi ilgili açılardan aynı standartta üretilmiş olması, değişim için yeterli olur. Yani mühendislik ürünlerinde değişim, var olana yeni bir şey katmaktan ziyade, yerine geçirmek (replacing), var olanı, standartları açısında uyumlu olan daha yenisiyle değiştirmek anlamına geliyor. Yazılımda ise aşınma, bozulma söz konusu değil. Dolayısıyla değişimi gerektiren durumlar, temelde yeni ortaya çıkan ihtiyaçlardır. Bu yüzden yazılımın değişmesi, daha önce sahip olmadığı özelliklere sahip olması anlamına gelmektedir. Yeni fonksiyonel ihtiyaçlar, örneğin yeni süreçler ya da var olan süreçlerdeki değişiklikler, yeni iş kuralları ya da benzer şekilde var olan iş kurallarında değişiklikler, iş kurallarının çoğunlukla daha esnek hale gelmesi, yeni tür kullanıcılar, yeni entegrasyonlar, yeni teknoloji vs. hep yazılımı değişmeye zorlayan etkenlerdir.

Değişim, yazılım mühendisliğini çok derinden etkileyen bir faktördür. Örneğin, geliştirilmesine 100 TL harcanan bir yazılımın, ömrünün sonuna kadar değiştirilmesine ne kadar para harcandığını sorsam tahmininiz ne olurdu? Buna cevap aramak için Google’a gidip “software maintenance cost” aramasını yapın ve çıkan resimlere bakın. Farklı onlarca grafik göreceksiniz ama hepsi bir şeyi analtıyor: Yazılımın esas maliyeti geliştirilmesinde değil, değiştirilmesinde. O grafiklerdeki oranlara bakarak 100 TL’ye geliştirilen bir yazılımın ömrünün sonuna kadar 400-500 hatta 700-800 TL gibi masraflara bakımının yapıldığı sonucunu çıkarabilirsiniz. Ben bu oranın ülkemizde 10 gibi olduğunu düşünüyorum, yani 100 TL’ye geliştirdiğimiz yazılımın bakım maliyetinin onun 10 katına yani 1000 TL’ye kadar çıktığını düşünüyorum. Bunun pek çok anlamı var:

  • Yazılımlar için bütçeleme yaparken sadece geliştirme maliyetini göz önüne almanın doğru olmaması. Esas maliyet, buz dağının görünmeyen kısmı, bakımda aslında.
  • Bütçemiz kısıtlı olduğundan şunu/bunu yapamayacağız. Örneğin “dokümentasyon yapamayacağız”, “teste vakit yok”, “eğitim bütçemiz çok kısıtlı”, “ek kaynağa para ayıramıyoruz” gibi cümleler anlamsız. Gerekli olan  şeylere para ayıramayarak 100 TL’ye geliştirdiğimiz yazılımı ayakta tutmak, düzeltmek ve daha da geliştirmek için 5-6 senelik ömründe 1000 TL harcamak zorunda kalıyoruz ama.
  • Yanlış ata oynuyoruz, kafamızı “yazılımı nasıl geliştirelim ki ihtiyaçlarımızı karşılasın”a odaklamak yerine “yazılımı nasıl geliştirelim ki gelecekteki ihtiyaçlarımızı karşılaması kolay olsun”a odaklamalıyız. Yazılım Mühendisliğinde önemli olan yapmak değil, değiştirmektir çünkü.
  • Başarısız yazılımların değişeceğini sanıyoruz ama geçek şu ki başarısız yazılımlar çoğu zaman değişemediklerinden başarısızdırlar, değişen yazılımlar başarılı olanlardır.
  • En acısı da belki yeni mezunların, çalışacakları işlerde hep yeni projeler geliştireceklerini düşünürken, 12 aylık maaşlarının yaklaşık olarak sadece ve sadece 1,2 tanesini yeni projede kod yazmak için alıp, geri kalanını başkalarının yazdıgı berbat kodu önce anlamak sonra düzeltmek, yeni özellikler eklemek, başka bir teknolojiye çevirmek gibi bakım ya da değişim dediğimiz çalışmalar için hakediyor olmaları. Düşünsenize makina mühendisi olarak eğitim aldınız ve iş hayatına atıldınız, tek yaptığınız iş ise bir araba tamircisinde gelen arabaların bujilerini temizlemek, gerekirse değiştirmek. Ya da çiçeği burnunda bir inşaat mühendisi olarak elinizde mala, çatlayan duvarları sıva yapıyorsunzu devamlı, nasıl olurdu? Malesef bizim sektörde hayat böyle, sonra bu yazılımcılar niye böyleler? 🙂 (Gerçi bu duruma pek çok kötü örnek verilebilir, konservatuarda Dede Efendi ya da Beethoven’i öğrenip mezun olunca düğünlerde Ankara’nın Bağları çalmak zorunda kalmak da benzer bir şey. 🙂 )

Diğer mühendislik ürünleri olabildiğince az değişecek ve değişmesi gerektiğinde de kolay değişecek şekilde tasarlanıp üretilmektedirler. Bir araba üretilirken nelerin hızlıca değişmesi gerektiği çok açık bir şekilde belirlenmiş olduğundan, örneğin silecekler, tekerlekler, su ve yağ cinsinden şeyler, bunları bizler bile değiştirebiliyoruz. Çünkü buradaki değişim yukarıda da belirttiğimiz gibi parçayı değiştirmedir, yeni bir yapı ekleme değildir. Ya da bir köprü inşa edilirken örneğin üzerindeki asfalt vb. kaplamanın ya da varsa halatlarının nasıl değişeceği tamamen öngörülmüş durumda, bu yüzden de kolay değişecek şekilde tasarlanmıştır. Bu noktada fiziksel ortamlarda ve malzemelerle çalışan mühendislerin, sık değişecek kısımların kolay değişebilmesi gibi bir prensip üzerinde uzlaştıkları görülüyor. Bu yüzden örneğin bir arabanın sileceklerini değiştirmekle trigger kayışını ya da transmissionunu değiştirmek aynı kolaylıkta değil.

Yazılımın aşırı değişken olan doğasına rağmen “değişebilen yazılım” yerine yazılımın sadece geliştirilmesine odaklanmak, herhalde 100.000 TL’ye bir binek aracı satın alıp sonra sileceklerini değiştirmek için 5.000 TL ya da ne bileyim lastiklerini değiştirmek için 20.000 TL vermekle eşdeğer bence. Düşünün böyle, değişim göz önüne almadan, sadece ve sadece üretilmesine odaklanarak tasarlanmış bir aracın motorunun içindeki trigger kayışı gibi parçalarını değiştirmek muhtemelen 100.000 TL’ye mal olur. Böyle bir aracı kim almak ister ki? Dün aracıma 4 tane lastik aldım ve sadece lastikler için para ödedim, değiştirilmeleri ve balans için ücret ödemedim, çünkü eski lastiklerin janttan çıkarılıp yenilerinin takılması, balanslarının ayarlanması ve arabaya monte edilmeleri o kadar kolay ve hızlı ki yarım saatte işim bitmişti.

Aslında pek çok mühendislik ürününde ayırt edici unsur kalitedir. Neden durumumuz olduğunda 150.000 TL harcayarak bir araç satın alıyoruz da “aman canım aynı şeyi yapıyor” deyip 5.000 TLlik bir araçla yetinmiyoruz? Mühendis olarak ben örneğin, biraz vakit ayırsam, uğraşsam, herhalde bir araç yapabilirim ve 10.000 TLye sattığımı ilan edebilirim. Sonuçta gidiyor mu gidiyor, duruyor mu duruyor, nedir problem? Problem, “saatte 100 km hızla giderken, yerlere yeni yağmur düştüğünde 10 metre önünüzdeki araç sert bir fren yaptığında benim aracımda mı yoksa 150.000 TL verip aldığınız örneğin bir BMW 3.20’de mi olmak isterdiniz?” sorusu aklımıza geldiğinde ortaya çıkıyor. Ben yerler ıslak olmasa da, öndeki araç hiç fren yapmasa da BMW içinde olmayı tercih ederdim. Peki aynı durumda biz neden yazılımın değişim maliyetini göze almadan, sadece fonksiyonelliğine ve maliyetine bakarak tercihde bulunuyoruz ki? Bence en temel sebebi, yazılımın aşırı değişken olan mahiyetini henüz anlamamış olmamız. Buna günü kurtarmaya odaklı milli, aşırı faydacı karakterimiz de bu duruma katkıda bulunuyor ama yazılım konusundaki cehaletimiz daha önde bence.

Eğer bir araba reklamı yapsaydım, “evladiyelik” diye ilan ederdim arabayı. Ama bir yazılım sisteminin reklamını “evladiyelik” diye yapmayı düşünmezdim, onun yerine “kolay değişebilir” diye reklam yapmak daha akıllıca olurdu. Yapmak ile değiştirmek arasındaki denge, fiziksel mühendislik ürünlerinin tam tersine işliyor bizim mesleğimizde. Bu yüzden yazılımı yönetenler, 10 günde geliştirilmiş basit bir yazılıma bazı eklemelerin 2 haftada yapılabileceği gibi bir söz duyunca developera yükleniyorlar, çünkü kendilerini kandırılıyor hissediyorlar sanırım. Çünkü akıllarında 1 senede yapılan dairelerinin 3 günde boyanması ya da ne bileyim 1 haftada banyonun ya da mutfağın tamamen değiştirilmesi gibi tecrübeler duruyor. Yazılımı iyi yönetebilmemiz için, değişikliklerin kolay yapılabılabileceği yazılımlar geliştirmeye önem vermeliyiz. Ancak böyle bir anlayışla, yazılımın 10 gün yerine örneğin 50 günde geliştirilmesini planlar ve gerekli değişiklikler için developerdan “2 günde olur” diye tahminler bekleyebiliriz.

Bence bir programı, benim bir mühendis olarak bir binek aracı üretmem gibi matematiksel düşünme kabiliyetleri gelişmiş pek çok kişi, programcı ya da herhangi bir mühendis yazabilir. Bu kişinin üniversite mezunu bile olmasına gerek yoktur, akıllı ve meraklı bir lise mezunu yapabilir bu işi. Ancak yazılım, özellikle de rahat değişebilen bir yazılım, sadece ve sadece Yazılım Mühendisleri tarafından geliştirilebilir. Çünkü yazılım, programcılara ve proje yöneticilerine bırakılmayacak kadar zor bir iştir.

Yazımızı bir sloganla bitirelim: Kimileri program yazar, kimileri yazılım geliştirir. 🙂

Toplam görüntülenme sayısı: 1399

Yazılım Kalitesi, İhtiyaçları ve Sıradışı Durumlar

Yazılım Kalitesi ve Test, Yazılım Mühendisliği , ,

Yazılım sistemlerinin kalitesini belirleyen faktörler arasında, sıradışı durumlar çok önemlidir. Süreç analizleri, ister kullanım şekilleri (use-case) üzerinden yapılsın ister kullanıcı hikayeleri (user stories) gibi daha çevik yöntemler kullanılarak yapılsın, isterse çok farklı formal olan ya da olmayan tekniklerle yapılsın, şu gerçek değişmeyecek: Kullanılabilir ve tam yani eksiksiz bir yazılım sisteminin en temel özelliklerinden birisi, verdiği hizmetlerde normal, olması beklenen durum ve akışlar dışında, sıradışı durumları ve akışları gözetip, kullanıcılarını madur etmeyecek şekilde, muhtemel her durumu göz önüne alınarak geliştirilmiş olmasıdır. Bu anlamda, süreçlerin sadece beklenen çalışma şeklini değil aynı zamanda alternatif ve umulmadık durumları da kapsaması gereklidir.

Yazılım sistemlerindeki login/logout gibi son derece basit olan süreçlerde bile alternatif ve sıradışı durumlar sözkonusudur. Yani örneğin kullanıcıların, sisteme erişmelerini sağlayan “login” sürecinde bile, bilgilerin yanlış girilmesinde sistemin nasıl davranacağı, örneğin şifrenin arka arkaya yanlış girilmesi durumunda nasıl bir kilitleme sisteminin kullanılacağı ve bu durumun müşteriye nasıl bildirileceği gibisinden pek çok sıradışı akış söz konusu. Demek istediğimi, kullanılabilirlik ile ilgili güzel bir kitap hakkında kaleme aldığım bu yazıda da kısaca aktardığım yaşanmış, tipik bir olayı buraya aktararak anlatayım:

“Garanti Bankası’nın internet bankacılığı arayüzü üzerinden bir kredi kartı başvurusu yapmak gibi son derece basit bir tecrübem oldu üç-beş ay önce. Tonla ahiret sorusuna cevap verdiğim ve sonrasında ilerle gibi bir düğmeye basarak geçtiğim sürecin en son sayfasında “başvuruyu gönder” gibi bir son düğmeyi görünce sevinmiştim tabi olarak. Bu düğmeye de basıp, bir kredi kartı başvurusu yapmanın dayanılmaz hafifliğini yaşayacakken, düğmeyi basınca “bir hata oluştu” gibi bir mesajla karşılaştım. Şimdi, hiç yazılım üzerine bir eğitim almamış olsam da eğer IQ seviyem 70-80 üzerindeyse ve hele de iflah olmaz bir “iyi niyet” taşıyıcı ve saçıcıysam, “… değiller ya bu yapanlar, herhalde başvuru bilgilerimi saklamışlardır, 15 dakika vakit harcadım başvururken ve TCKN, bir yakınımın telefonu vs. gibi, bir kısmı aklımda bir kısmı telefonumdan ya da makinamdan bakıp söylediğim, bir sürü bilgi girdim” diye düşündüm hızlıca. Ama sonrasında web uygulamasının menuleri arasında böyle bir şeyi ima eden bir linke bile rastlamadım tabi. Sonra dedim ya ben iflah olmaz bir iyi niyetiliyim, “herhalde sanırım ben hata yaptım, öyle ya ben bir yazılımcıyım ama Garanti Bankası’nın bu web arayüzü için beni cebinden çıkaracak tonla yazılımcı, analist, kullanılabilirlik uzmanı :) çalışıyordur, boru değil ya …” diye düşünüp, güzel bir şekilde, hiçbir şey olmamış gibi, tekrar aynı süreci izledim. Sonuç değişmedi ama, iyi niyetten anlamıyor bu yazılımlar. Ayrıca web arayüzü de tamamen poker face :) ser verir sır vermez cinsten: “Bir hata oluştu” İyi tamam da abi zaten muhtemelen benim bilgilerimi girdiğim üç baş sayfalık süreçte sunucu tarafında bu bilgiler muhtemelen Http oturumunda (session) tutuluyor, varsa bir problem, bu bilgileri yaz bir yere, muhtemelen veri tabanına, bir daha aynı eziyeti çektirme bana. Belli ki, kredi kartı başvuru modülü/sistemi her neyse, o tarafta oluşan bir hatadan dolayı web arayüzü bu mesajı veriyor bana. Ama sonuç şu: İstediği kadar janjanlı bir arayüze sahip olsun, kullanılmaktan uzak bir web uygulaması bu.”

Bu sistemin kullanılabilirliğinin düşük olmasının en temel sebebi ise, son derece standart bir süreç için bile sıradışı durumların ele alınmamış olup, müşteriyi madur etmeyecek şekilde yönetilmemiş olmasıdır.

Bu konuda bir başka örnek de şu olabilir: Sıklıkla verdiğim eğitimlerden birisi de Java ile web teknolojileri üzerine oluyor. Servlet, JPS, JSF, Spring MVC gibi teknolojileri içeren eğitimlerde ele aldığımız konulardan birisi de tabi olarak oturum ya da session yönetimi.  HTTP’nin durumsuz/stateless olmasından kaynaklanan sıkıntıyı gidermek üzere 90’lı yılların ortasında Netscpae tarafında bulunan ve çoktan yaygınlaşmış olan cookie/kurabiye tekniği, oturum yönetiminde detaylıca ele aldığım konulardandır. Tarayıcıların ve web sunucularının cookileri nasıl yönettiğini anlatırken, tarayıcıların seçeneklerinden cookilerin kullanıcı makinasında saklanıp saklanmaması, dolayısıyla da tarayıcının web sunucusundan gelen cookieleri kabul edip etmemesi gibi durumları da ele alır ve açıklarım. İş mantığı açısından baktığınızda, cookie kabul etmeyen tarayıcı, işi yönetmeniz için sıradışı bir durum oluşturmaktadır. Bu durumun sistemin ihtiyaçlarını belirleme ya da en geç tasarım safhasında cok genel sıradışı bir hal olduğu gerçeğini ıskalamamamız ve bu durum için bir cevap üretmemiz gereklidir. tarayıcımızın seçeneklerini kullanarak cookieleri kullanmasını engellersek ne olur? Bu sıradışı bir durumdur ve web sistemleri ya bu konu ile ilgili kullanıcıya uyarı vermelidir ya da bu durumu cookie kullanmadan halletmelidir. Bakın tarayıcınızın cookieleri kullanmasını engellediğiniz zaman dünyanın bildiği Amazon.com’un davranışı ile Amazon’un ülkemizdeki karşılığı olarak görebileceğimiz Hepsiburada.com’un davranışı arasındaki farkı görelim.

Önce tarayıcımızdaki cookieleri engelleyelim yani disable edelim:

Mac OS'da Safari tarayıcısının cookie seçeneklerini kullanarak, cookieleri reddetmek.

Mac OS’da Safari tarayıcısının cookie seçeneklerini kullanarak, cookieleri reddetmek.

Bunu yapıp da Amazon.com’a gidip alış-veriş yapmak istediğinizde Amazon.com söyle bir uyarı veriyor ve cookileri aktive etmezseniz sizle çalışamam diyor:

Amazon.com'un, cookileri engelleyen taraycıya cevabı.

Amazon.com’un cookileri engelleyen tarayıcıya cevabı.

Hepsiburada.com ise cookielerle ilgili uyarı vermeden, hatta hiç bir uyarı vermeden “lütfen şifrenizi girin” diye insanı deli edercesine aynı ekranı tekrar tekrar görüntülemeye devam  ediyor. Ve siz arka tarafta olan biteni bilmiyorsanız ki bilmek için bu teknolojinin detaylarıyla ilgili şeylerden haberdar olmalısınız, bu durumu çözmeniz pek mümkün değil.

HepsiBurada.com’un, cookileri engelleyen tarayıcıya cevabı.

HepsiBurada.com’un cookileri engelleyen tarayıcıya cevabı.

Bir başka örnek ise Skype’dan. Bakın Skype’da bu konuda şöyle davranıyor:

Skype’ın, cookileri engelleyen tarayıcıya cevabı.

Skype’ın cookileri engelleyen tarayıcıya cevabı.

İşte yazılım kalitesi denen şey de bu, ne kadar basit, ne kadar kullanılabilir, müşterisini ne kadar doğru yönlendiriyor. İster analist olun, ister developer, analizini yaptığınız ya da geliştirdiğiniz süreçlerin sıradışı durumları olabileceğini akıldan çıkarmayın ve bu durumların avukatı olun. Yöneticiyseniz eğer, yapılacak işleri çıkarırken, maliyetlendirirken, muhakkak sıradışı durumların da göz önüne alındığından emin olun. Ne diyelim, mükemmellik ayrıntılarda gizliymiş 🙂

Toplam görüntülenme sayısı: 1209

«< 47 48 49 50 51 >»