Süreç Analizi

Özet

Bu döküman, yazılım geliştirmeye yönelik süreç analizlerinin kritik noktalarını örnekler yardımıyla açıklamaktadır. Bu örneklerde, örneklere konu edilen süreçlerden ziyade düşünce şekline odaklanmanız tavsiye edilir.

Genel Prensipler

Ekstrem Sayılar

Oluşturduğunuz süreçteki sayıları tespit edip, sürecin bu sayılar değiştiğinde nasıl etkileneceğini düşünmek önemli adımlardan biridir. Geliştirilecek olan yazılım, bu durumları da karşılayabiliyor olmalıdır.

Örnek: Kantar Süreci

Örnek bir süreçte; SAP içerisindeki bir satın alma siparişine istinaden kamyon içerisinde hammadde geleceğini varsayalım. İhtiyaç ise, sipariş ile kamyon plakasını ilişkilendirmek olsun. Bu süreçte akla ilk gelen çözüm, sipariş belgesi içerisindeki bir alana gelen kamyonun plakasını yazmak olabilir.

Şimdi… Sürecimizdeki sayılara bir göz atalım:

• “1” satın alma siparişi
• “1” satın alma siparişine ilişkin “1” kamyon

İlk maddedeki “1” değerini arttırdığımızda veya azalttığımızda süreç etkilenmeyecektir. Ne var ki, ikinci maddedeki değerlerle oynandığında sonuçlar değişecektir.

Örneğin; kapıya gelen bir kamyon “1” satın alma siparişine ait ürünleri getirmek yerine 2, 3, 5, …, n sayıda satın alma siparişine ait ürünleri bir arada getirdiyse ne olacak? Bunun cevabı, her bir satın alma siparişini birer birer açıp gelen kamyonun plakasını yazmak olabilir. Ancak; müşteri bu çözümü muhtemelen pratik bulmayacaktır. O yüzden, n sayıda siparişe aynı kamyon plakasının topluca girilebileceği bir ekran hazırlamak gerekiyor olabilir.

Şimdi bir diğer sayıyı değiştirelim. “1” satın alma siparişine istinaden; “3” kamyon gelemez mi? Sipariş çok büyükse gelebilir. Bu durumda, sipariştek bir alana kamyon plakasını yazma çözümü iyi bir çözüm olmayacaktır, zira gelen diğer kamyonların plakaları girilemeyecektir. Bu durumda; çözümümüzü, bir başka veritabanı tablosu yaratma yönünde değiştirmemiz gerekecektir. Bu tabloda, bir sipariş numarasına istinaden birkaç plaka girilebilmelidir.

Şimdi, aynı maddedeki iki sayıyı birden değiştirelim. Aynı hammaddenin ısmarlandığı “3” siparişe istinaden “4” kamyon gelirse ne olur? Özellikle bu hammadde akışkan bir hammadde ise ve kamyonları sipariş sipariş ayırmak mümkün değilse, bir önce ürettiğimiz çözüm de yeterli olmayacaktır. Bu durumda; çözüm şu şekilde modifiye edilmelidir:

• Kapıya bir(kaç) kamyon geldiğinde, kullanıcı önce “Teslimat numarası” diye bir numara almalıdır. Bu, SAP’nin standart teslimat süreci ile çözülebilir.
• Bu teslimat numarasının içine, ait olduğu siparişler girilmelidir (n sayıda girilebilmelidir). Bu da SAP’nin standart teslimat süreci ile çözülebilir.
• Aynı teslimat numarasının içine, siparişi getiren kamyonların plakaları girilmelidir (n sayıda girilebilmelidir). Buna karşılık, bir önceki adımımızda olduğu gibi, teslimat numarasına istinaden birkaç plaka girilenilecek bir tablo ve ekran yazılabilir.

Şimdiye kadar sayıları hep yukarıya çektik. Ya aşağı çekersek? Örneğin, “n” sayıda siparişe istinaden gönderilecek olan hammaddeler “0” kamyon ile gelirse? Örneğin; yakın lokasyondaki bir üretici, hammaddeyi doğrudan el arabasıyla getiriyor olabilir. O halde, kamyon plakasının yanı sıra “Diğer” gibi bir seçenekle bir başka teslimat şekline ait serbest metin girilmesi isteniyor olabilir.

İstisnai Durumların Değerlendirilmesi

Ekstrem Sayılar bölümündeki bir durumun hangi sıklıkta meydana geliyor olduğu da değerlendirilmesi gereken bir faktördür. Sadece arada sırada olacak bir olay için bütün sistemi değiştirmek her zaman iyi bir fikir olmayabilir – senaryoyu çözümsüz bırakmamak şartıyla ara çözümler üretilebilir. Ancak; arada sırada olan bir olay, sürecin geri kalanından daha önemli bir başka süreç de olabilir.

Bir senaryoya süreç kapsamında ne kadar önem verilmesi gerektiği, şu formül ile değerlendirilebilir: Senaryonun Oluşma Sıklığı x Senaryonun Önemi

Örnek: Talepsiz Siparişler

Bu örneğimizde; bir firmanın satın alma sürecini ele alacağız. Satın alma talebindeki miktarlarla satın alma siparişindeki miktarları bir arada listeleyecek bir rapor talep edildiğini ele alalım.

Ekstrem Sayılar analizi sonucunda, bazı ender durumlarda satın almacıların hiç satın alma talebi açmadan doğrudan doğruya satın alma siparişi açtıkları tespit edilmiş olsun.

Eğer bu durum; (örneğin) sadece 50 YTL’yi geçmeyen ender alımlarda gerçekleşen bir durumsa, belki de raporun kapsamından çıkartılabilir. Zira, “Senaryonun Oluşma Sıklığı x Senaryonun Önemi” formülünde hem “Senaryonun Oluşma Sıklığı” hem de “Senaryonun Önemi” değişkeni çok küçük bir değer aldığı için, bu senaryonun yazılım tarafından karşılanma gerekliliği ortadan kalkabilir.

Örnek: Toplu Ödeme

Bu örneğimizde; bir avukatlık firmasını ele alacağız. Bu firmada, avukatların aktivitelerine istinaden fatura kesildiğini varsayalım. Ancak; yılda 1-2 kereye mahsus olmak üzere, bazı büyük müşterileri davalara istinaden peşin ödeme yapmaktadırlar.

Yılda sadece 1-2 kez gerçekleşen bu olayı görmezden gelip, “Workaround”’lar ile idare etmeye çalışmak ilk bakışta iyi bir fikir gibi gelebilir. Ancak bu olaylar firma cirosunun %40’ını oluşturuyorsa; ödeme takibi ve maliyetlendirme adımlarında bu senaryonun detaylı bir şekilde ele alınması gerekliliği ortaya çıkacaktır.

“Senaryonun Oluşma Sıklığı x Senaryonun Önemi” formülünde “Senaryonun Önemi” değişkeni çok büyük bir değer aldığı için, bu senaryonun yazılım tarafından karşılanma gerekliliği de öne çıkmıştır.

Varsayımların Gözden Geçirilmesi

Süreçteki öğelere ait varsayımların bir listesini çıkartmak; ve yazılımın, varsayımların riske girdiği durumları da idare edebilir hale getirilmesi, bir diğer önemli prensiptir. “Bu beklendiği gibi olmazsa ne yaparız?” sorusu, her bir varsayım için cevaplanmış olmalıdır.

Örnek: Kur Süreci

Bu örnekte; müşterin, IMKB’deki kurları günlük olarak indirip SAP’ye otomatik atacak bir geliştirme istediğini varsayalım. Bu ihtiyaca istinaden, şöyle bir çözüm geliştiriyor olabiliriz: Yazılacak bir Java programı, kurları IMKB’nin sitesinden XML formatında indirecek ve SAP’de yazılan bir RFC üzerinden sisteme kaydedilmesini sağlayacaktır. Bu program, ortak bir File Server üzerinde çalışacak ve Windows ortamındaki bir Scheduled Task olarak kurulacaktır.

Şimdi, bu çözümdeki varsayımların bir listesini çıkartalım:

• IMKB, kurları her gün XML formatında sağlıklı bir şekilde sunuyor olacak
• Java programının çalıştığı bilgisayar, çalışır halde ve IMKB sitesine ve SAP’ye ağ üzerinden erişebiliyor olacak
• Java programını çalıştıran Scheduled Task silinmemiş olacak
• SAP tarafındaki RFC, kurları sisteme herhangi bir hata olmadan kaydedebiliyor olacak

Bu varsayımların herhangi birinin aksadığı durumda, kur aktarım programı görevini başarılı bir şekilde gerçekleştiremiyor olacaktır.

Bu varsayımlara ait riski toplu halde bertaraf edecek bir çözüm; SAP’ye girildiği zaman sistemdeki en güncel kur tarihini kullanıcıya bildirmek olabilir. Kullanıcı olması gerekenden daha eski bir kur tarihi görürse, yukarıdaki gereksinimlerden birinin aksadığını anlayacak ve problemi çözmeye yönelecektir.

İhtiyaç Kapsamının Değerlendirilmesi

Müşteri ihtiyacının gerisinde kalacak bir çözüm kadar; ihtiyacın çok ötesinde, belki de kullanılmayacak kadar çok özellik barındıran bir çözüm de kaçınılması gereken bir durumdur.

Proje Kapsamının Değerlendirilmesi

Geliştirmelerin bir proje çerçevesinde yapıldığı durumlarda, gelen talebin proje kapsamında olup olmadığının değerlendirilmesi de büyük önem taşımaktadır. Projeyi maliyet, süre veya kapsam anlamında aşabilecek ihtiyaçlar konusunda müşteriye bir söz vermeden önce proje yöneticisiyle konuşmak iyi bir fikir olacaktır.

Sürecin Kabul Ettirilmesi

Teknik açıdan doğru bir süreç üretmek kadar, bu süreci proje ortamında kabul ettirebilmek de önemlidir. Burada sık karşılaşılabilecek problemler ve bunlara karşılık kullanılabilecek bazı yaklaşımlar aşağıda açıklanmıştır.

Sürecin Gerçekçi Olduğundan Emin Olma

Bir süreci sadece yöneticilerden dinlemek, sahada yürüyen gerçek hayata uymayacak bir analiz yapmanızla sonuçlanabilir. Bu konuda sık rastlanan durumlardan biri, yöneticinin size ideal bir dünyayı anlatması veya yazılım üzerinden daha fazla kontrol / güç / vs sahibi olmak için gerçekçi olmayan kurallar talep etmesidir.

Sadece sahadakilerden dinlemek ise, istisnai durumları tamamen gözden kaçırmak veya kural olarak kabul etmek gibi hatalar içeren bir analiz yapmanızla sonuçlanabilir.

İdeal bir analizde; hem yöneticiler hem de sahadaki kişileri bir araya getirmeli ve ikisinin anlaştığından emin olduğunuz sonuçları almalısınız.

Müşteriyi Yanlışlama

Sürece istinaden yapılan bir toplantı sırasında; karşı taraf, yanlış bir bilgiye veya varsayıma dayanarak yanlış bir ifadede bulunabilir. Bu durumda; müdahele ederek karşı tarafın yanlışını doğrudan doğruya ifade etmek, bazı kişiler üzerinde olumsuz bir etki yaratabilir.

Bunun yerine, soracağınız sorularla karşı tarafı yönlendirerek hatalı ifadesini kendisinin bulmasını ve kendi kendini düzeltmesini sağlamaya çalışın.

Uzlaşmacı Yaklaşımı Sağlama

Karşılaşabileceğiniz bazı insan tipleri; uzlaşmacı olmaktan ziyade, her konuda hata arayan olumsuz bir yaklaşım sergiliyor olabilir. Bu tarz bir durumda; sürecinizi karşı tarafa olduğu gibi ifade etmeniz halinde, karşı taraf sizce mükemmel olan sürece müdahele etme ihtiyacı hissedecek ve bir anlamda sürecinizi bozacaktır.

Bu özellikte biriyle karşı karşıya olduğunuzu fark ederseniz; sürecinizi sunarken, süreci mükemmel halinde sunmak yerine araya bu kişinin fark edebileceği 2-3 ufak kusur / hata serpiştirin. Karşınızdaki kişi bu hataları tespit edip ifade ettiğinde; hem hata arayıp bulma ihtiyacını gidermiş olacak, hem de süreci kendisinin mükemmelleştirdiğini düşünerek süreci sahiplenecektir. Bu şekilde, potansiyel bir düşmanı kendi tarafınıza çekmiş dahi olabilirsiniz.

Serpiştirdiğiniz kusurlar fark edilmezse; bu kusurları süreci uygularken fark edip düzeltmiş olmanıza kimse itiraz etmeyecektir.

Advertisement