Yazılım mühendisliği açısından-VERİMLİLİK – 1ve-2(Murat SEVGİ -Köşe Yazısı)

Verimlilik öyle tartışma götürür bir konu değil.
Neredeyse “Mutlak” kriterleri oluşmuş bir konu.
1- Bir proje için ara zamanda verimlilik hesaplanamaz.
Bu demektir ki; iş bitmeden projenin ara safhalarından birinde verimlilik hesaplanması bütünün verilerine sahip olunmadığı için hatalıdır.
Ama bütünün, süreç olarak, öngörü olarak (tahmini) bir gelecek projeksiyonu çıkarılabilir.
Bu durumda eldeki tahmini veriye göre bir verimlilik değeri elde edilebilir.
2- Verimliliğin temel kaygısı tasarruftur.
Nedir bunlar: Zaman, işçilik, malzeme.
ZAMAN:
Bir işi daha az zamanda yapabilmeyi sağlamak.
Bunu yaparken (yazılım özelinde) deneyim ve analiz çabukluğu önemlidir.
Diyelim ki; A1 projesi ile uğraşırken aşırı zaman harcayarak çok başarılı bir algoritma ürettiniz.
Bu algoritma (Diğer sektörlerde proses) çok büyük faydalar sağlıyor.
A- Bu iş için (A1 projesi kapsamında) proje verimliği kötü bir değer alır. (Yani: verimliliği düşüktür)
B- Proje ekini, bu faydalı üretimi başarmış olmaktan dolayı, ekip verimliliği bazında iyi bir değer alır. (yani: verimliliği yüksektir)
İŞÇİLİK:
Bir işi daha az kişi ile yapabilmeyi sağlamaktır.
Aslında ZAMAN kriterine de bağlıdır.
Ama “hedef iş” bazında daha az “adam-saat” kullanımı önemlidir.
Yazılım işinde, altprogramlar ile yada programlama dili seçimi ile ilgilidir.
Mesela Assembler dili ile 100 adam-saat zamanda yapılabilecek bir işi, C dili ile 15 dakikada yapabilirsiniz.
MALZEME:
Bu kriter nesnel üretimi esas alan bir sistemin kriterlerinden.
Ama mamul olarak yazılım ürününü düşündüğümüzde bunun girdisi olan tek mal, işçilik ve ortam (soft ve hard) ekipmanlarıdır.
Malzeme girdisi olan bir sektör olmadığı için bu maddeyi yazılım ekibi verimliliğinde ele almak pek anlamlı değil.
Ama mekanik bir şeyler üretenler için önemi tartışılmaz.
Not: Yazıda verilen örnek: (Birim zamanda yazılan kod)
Bu kriter üretilen kodun işlerliğini içermediği için pek bir değer taşımıyor.
Yani satır sayısı ile verimlilik olmaz.
Aksine;
Bir işlevi, daha az kod ile yapmak, daha değerli bir çalışmadır.
Ama burada “zaman” değişkenini de ele almak gerekir.
Gelelim verimlilik nasıl belirlenir:
Proje ekibi işe başladığında projenin tümünün planlamasını yapar.
* Bu proje, gerekli ekiplere paylaştırılır. (Grafik, kodlama, veritabanı, test vb...) (Matrisin sütunları) “1D”- X ekseni
Her ekibin işlevinin bütüne etkisi yüzdesel olarak belirlenir.
* Her ekibin iş süreci de kendi içinde takvime bağlanır. (Matrisin Satırları) “2D” - Y Ekseni
Bu takvimler iş süresince birebir takip edilir.
* Ekipler de içlerinde ayrıca eleman bazında süreçleme yapabilir. (Matrisin derinliği) “3D” - Z Ekseni
Şimdii; XYZ matrisi, verimlilik vektörü oluşturuluş olur.
Hep sevgi ile kalın.
Murat SEVGİ
(Bu yazı, Yazılım Mühendisliği Gurubu için 07 Ağustos 2008 Perşembe, 13:08 tarihinde yazılmıştır.)



Yazılım mühendisliği açısından
VERİMLİLİK – 2
Murat SEVGİ
* Yazılım projesi özelinde düşünürsek ara zamanda hesaplanamıyor olması ara zamanda projede değer üretilmediğini göstermez mi?. Günümüzde kullanabilecekleri yazılımı projenin sonunda görmeye razı olacak müşteri var mi?
Projeyi planlayanın parçalara ayırması (bunu baştan yapması) gerekli.
Mesela modüller halinde....
Her modülün üretimin aşamasındaki yeri zaman cetvelinde başlangıç ve bitiş olarak belirtilir. Bu tahmini süreler; planlamacının işidir.
Müşterinize modülleri süreç devam ederken sunabilirsiniz.
Ama hedef matrisinde bunlar yapan departmanın hanesine eklenir.
* Bu kullandığınız yönteme göre değişir. Waterfall bir süreçte hatalı olduğu doğrudur. Fakat yazılımı adım-adım oluşturuyorsanız ve her adımda kullanılama hazır, kaliteli yazılım üretiyorsanız her adimin verimliliğini müşteriye verilen değer toplamı olarak ölçebilirsiniz.
Planlama ve öngörü (tahmin) ile bunu yaparsınız...
2 hafta sonra modül1, 4 hafta sonra Modül2 bitecek der, ve yapacak ekibe bir verimlilik hedefi koyabilirsiniz.
Ama aynı anda paralel çalışan ekiplerde senkronize üretimi kaydıran ekipler, sadece kendi verimliliklerine değil tüm projenin verimliliğine zarar verir.
Birçok ekiple çalışıyorsanız, senkronizasyonu dengelemek, bazen planlamacılıktan zor olabilir.
* Bu tanımın içinde yazılımı kullanacak müşterinin tatmini ölçülmeli eklenmeli mi? Bir işin bitti denmesi ve verimlilik hesaplarına katılması müşteri tatmin kriteri önemli değil mi?
Matriste departmanlar dizisine; test departmanı gibi implemantasyon işini de ekleyebilirsiniz. Planlama ekibi projeyi müşteriye giydirecek olan departmanı da planlamış olmalıdır. Bunu ayrıca belirtmeye gerek duymamıştım.
Müşteri tatminine yönelik yapılacak ek işçilikler bu şekilde eklenemez.
Bu ek işçilikler; ancak minör versiyon uygulaması gibi görülebilir.
Ve ek bir proje gibi oluşturulacak yeni bir matris ile hesaplanmalıdır.
Bu durumda: P projesi için P' ek külfeti oluşur. Müşteri bununla da tatmin olmazsa ikincil iyileştirmeler P'' .... devam eder
Verim = XYZ - X'Y'Z' - .... şeklinde olur.
Toplam iyileştirme kaybı. Projenin faydasını geçerse işte o zaman işi batırmışsınız demektir.
Bu durumu tekstil sektörüne yönelik yazılım üretiminde ne yazık ki çokça görüyorum.
Müşteri tatminini sağlamada en başta tanımladığımız planlama ekibine ve bu ekibin çekirdeğini oluşturacak süreç analizcilerine (Buna diğer sektörlerde "Proses tasarımcısı" da deniyor.) Çok iş düşüyor.
Ne yazık ki planlamacıların verimsizliği en tehlikeli verimsizliktir.
Ve hesaplanamaz.
Bunu genelde çok sayıda proje sonrasında şirket verimi şeklinde gözlemlemek mümkündür.
Ki bu durumda işler kötüye gitmişse çok geç kalınmış demektir.
* * *
Bir de ek olarak şunu belirtmekte fayda var
Bazı süreç akışlarında;
Bir departman, iş yapabilmek için diğer bir departmanın çıktısını kullanabilir.
Mesela
sizin, fırıncıya
fırıncının un fabrikasına
un fabrikasını çiftçiye
bağlantısı gibi.
Çiftçi mahsulü geç toplarsa bu size bir silsile şeklinde yansır.
Bir departmanın, başka birkaç departmanın çıktısını, girdi olarak alması durumunda iş daha da karmaşıklaşır.
Ama çözülemez bir denklem değildir.
Benzer bir süreç rOi de ve iRR de de uygulanır.
Aslında proje bazında hesaplanacak rOi ve iRR de verimlilik denkleminde yer almalıdır.
Ama burada sadece süreçten bahsettik.
Hep sevgi ile kalın.
Murat SEVGİ
(Bu yazı, Yazılım Mühendisliği Gurubu için 08 Ağustos 2008 Cuma, 13:08 tarihinde yazılmıştır.)
Sözlük:
rOi: (Return Of Investmen) Yatırımın geri dönüşü süresini ifade eder.
Bu konuda daha ayrıntılı bilgiyi http://muratsevgi.blogspot.com/2007/01/yatirim-projelerinde-roi-nin.html adresinde bulabilirsiniz.
iRR: (Internal Rate Of Return) İç kaynakların geri dönüşünü ifade eder.