Yazılımda “Saçım” N.Kaya KILAN

... konulu sunumlar: "Yazılımda “Saçım” N.Kaya KILAN"— Sunum transkripti:

1 Yazılımda “Saçım” N.Kaya KILAN
27 . ULUSAL BİLİŞİM KURULTAYI EYLÜL 2010 RIXOS GRAND ANKARA 23 Eylül Perşembe 2010 Eğitim ve Bilgilendirme Oturumu saat milenium-2 salonu Yazılımda “Saçım” N.Kaya KILAN Başkent Üniversitesi Mühendislik Fakültesi Bilgisayar Mühendisliği Bölümü, Ankara

2 Yazılımda “ Saçım ” Son yıllarda, yazılım geliştirme araştırmalarında Bilişim Teknolojisi uygulama yazılımı kullanımında iki aksaklık belirleniyor. Birincisi yazılım geliştirme aşamasında, ikincisi uygulama aşamalarında doğuyor. Bu iki ilginç olumsuzluk; "Tam Zamanında" tanımlama kuralı boyutunda "Lean yazılım geliştirme yöntemi” içinde sorgulanıyor.

3 Saçım (Waste) Saçım,Türk Dil Kurumu Sözlüğünde; “gereksiz yere para, zaman, emek vb harcamak “ olarak tanımlanıyor. Bu sözcüğü endüstriyel ve hizmet alanında “bir işleme sürecinde gereksiz yer alan işlem ya da işlem kümesinin yarattığı zaman ve işlem aksaklığı/Kaybı/ israfı ” olarak tanımlayabiliriz. Saçım yaratan istemsiz olgular, kuşkusuz her üretim ortamında ortadan kaldırılması ya da en aza indirilmesi beklenen düğümlerdir.

4 Yazılımda “Saçım” Son yıllarda, farklı ilkeli olsa da, yazılım tasarımı ve yazılımın uygulama sürecinin işletim ve kullanımını etkileyen “saçımı ” olabildiğince ortadan kaldırma gereksinimi, yazılım geliştirme süreçlerine etken yöntemsel kurallar olarak yansıtıldığı geliştirme yeni yöntemler içinde görülebilir.

5 Tarihçe; Zaman ve İşlem Çözümlemesi-Time and Motion Study”
Saçımı ortadan kaldırma, verimliliği artırma yaklaşımlarını endüstriyel üretim konularında; örneğin otomotiv üretim zincirinin irdelenmesinde 1900’lü yıllarda görüyoruz. Üretim verimliliğini, arıtılmayı amaçlayan ”üretim zinciri irdelemesi” nin endüstriyel üretim alanının etkinlik kuramı olarak geliştiğini de görüyoruz. Bu yaklaşım; gerek Frederich W.Taylor ( ) ‘un Taylorizm gerekse Henry Ford ( ) ‘nin “Yürüyen Band” kuramlarının düğümü olarak, üretim zincirinde saçımı en aza indirmeyi amaçlıyor.

6 Bilgi Teknolojisinin Gelişimi
1980’ lerde gerek “endüstriyel” gerekse “ticaret ve hizmetler” alanlarında “Uygulama Yazılım Paketleri” uygulamanın bir parçası ve içerik niteliği ile devrim niteliğinde çok önemli değişikliğe konu olmaya başlamıştır. 1990’larda ağ iletişimli yapıların yerel ve uzak ağ kapsaması ile, “Uygulama Yazılımının” iş alanlarının bir parçası olmada güçlü eğiliminin; sanal ortamlarda uzanması, değişime yeni donanımsal ve yazılımsal gerekler getirmiştir. Yeni dönemde, üçüncü boyut diyebileceğimiz “iletişim” teknolojisinin altyapı olması ile yazılım geliştirmenin içeriği konu ve kapsama alanı ile çok yönlü genişleme süreçlerine girdiğini görüyoruz. Uygulamanın çeşitli donanım-yazılım yapıları ile bütünleşmesi, farklı yazılım geliştirme yöntemleri gereksinimini de doğurduğuna kuşku da yoktur. Örneğin, Uluslar arası boyutta“Tedarik Zinciri”, “Müşteri İlişkileri Yönetimi”, “Ofis Uygulamaları Yönetimi” , “Mühendislik Uygulamaları”, “Karar Destek Süreçleri” gibi uygulamalar; sanal ağ ortamlarında bütünleştiği gibi, işleme zaman sürecinin “7Gün/24Saat” gibi süreklilik kazanmaya da başlaması yazılımın içeriğini ve işleyişini de etkilemiştir

7 Müşteri ve Son-Kullanıcı
Yazılıma yüklenen görevlerin uç noktasında bilişim teknolojisi içinde, iki yeni kullanıcı türünden de söz etmeliyiz. “Müşteri- Customer" ve “Son Kullanıcı-End User”. Ergonominin karmaşık bütüncül yapısında, “insanı” öne çıkaran “kullanabilirlik” öğesi kuşkusuz en önemli etmendir. yazılım geliştirme disiplinine insan- etmenin ağırlıklı eklenmesi kaçınılmaz olmuştur. Gelişen yazılım kullanım yapı ve kurgularında, kullanıcı kavramına çeşitli nitelikler yüklenebiliyor. Örneğin ekonomi ve ticarette, ürüne gereksinmesi olan ve onu kullanan kişiye “Son Kullanıcı” adı verilirken. “Müşteri” tanımı ile ilişkilendirilmesi zorunluğu da ortaya çıkıyor. Örneklemek gerekirse; aslan için yiyecek alan bakıcısı, müşteri ve fakat son kullanıcı aslandır. Böylece yazılımın işlevsel sürecinde gereksinmesini karşılamakla yükümlü olduğu varlık “müşteri” ve gereksinmesini yazılım aracılığı ile karşılamakla görevli varlık ise “son-kullanıcı”dır.

8 Kullanıcı Odaklı- User Centered” Tasarım
Bu nedenledir ki, yazılım tasarımında “Kullanıcı Odaklı- User Centered” tasarım irdelemesi öne çıkmaktadır. Böylece, bilgi teknolojisinde, Uygulama Yazılımı Hayat Çevriminde- “Software Application Lifecycle” İnsan-Bilgisayar Etkileşiminin değişimi bilişim çağının en çarpıcı özelliği olarak görülebilir. Diğer taraftan, “Bilgi Toplumu ” üst olgusunun yeni teknolojilerle kullanımı çevrimi 7/24 süreç döngüsü içinde, “doğru bilgiye, doğru yerde, doğru zamanda, doğru içerikte erişebilme” zorunluluğu, iş süreçlerinin yeniden değerlendirilmesini zorunlu kıldığı kolaylıkla söylenebilir.

9 Elektronik iş/ticaret
Güncel iletişim ve bilişim teknolojilerinin getirdiği değişimin en büyük etkeni kuşkusuz, Internet teknolojisine koşut olarak gelişen kurumsal iç ağ-(intranet) ve dış ağ (Extranet) kullanımındaki gelişme ve artıştır. Bu yapılanma 2000’li yıllarla başlayan Elektronik-İş / Elektronik Ticaret gibi yeni iş alanı yapıları ile, son kullanıcıyı hızla değiştiren teknolojiler getirdiğini de görüyoruz. Örneğin ABD’de 1990’ların ikinci yarısında iç ağ kullanan kurum sayısı 30 Milyonu, dış ağ kullanan kurum sayısı iki katını geçmiştir. Ülkemizde de bu gelişim kolaylıkla izlenebilir. Böylece bu günün bilgi teknolojisi kullanımını sağlayan yazılım içerik ve kullanabilirlik verimliliği yönünden, dili ve işleme süreci ile her zamandan çok önem kazanmıştır.

10 Yazılım kullanımında Sorunlar ve "Saçım"
Yazılım Geliştirme alanında ortaya çıkan iki temel sorundan birincisi yazılım projesinin zamanında tamamlanamaması, ikincisi yazılım projesinin kullanıcının beklentisini yeterince karşılayamaması olarak iki ayrımla öne çıkıyor. Konuya “Uygulama Yazılımı” kullanımı yönünden baktığımızda, kullanımda ortaya çıkabilen “saçım” konusu gerek tasarım gerekse uygulamada verimlik bağlamında irdelenebilir önem kazanıyor. Yukarıda sözünü ettiğimiz ABD de “Standish Group” tarafından 1994 yılında başlatılıp on yıl süren araştırma çalışması kullanımda önemli bilgiler içeriyor.

11 CHAOS Araştırma projesi
CHAOS Araştırma projesinin saptadığı ilginç bulgulardan biri; “Son Kullanıcının” ya da yerini alabilen “Müşteri”nin yazılım uygulama paketini oluşturan farklı işlem ve yanıt geri beslemesinin farklı katmanlarında (ya da alt program ve yordamlarına) kullanıcının , kullanım oranlarına ilişkin bulgulardır. Kuşkusuz, bir yazılımın tüm içeriği her uygulama adımının isteminde işlenmez. Yazılım bölümlerinin bir kullanım oranı her zaman söz konusudur. Ancak bu oran “saçım” yaratmamalıdır.

12 CHAOS Araştırma projesi
Yapılan araştırmalarda, uygulama yazılım bütününün özelliklerinin kullanımında 80/20 oranı öne çıkmaktadır. Bunun anlamı; kullanıcıların %80 ni uygulama yazılımının %20 özelliğini kullanmaktadır. Diğer bir deyişle uygulama yazılımının %80 ni nadiren ya da hiç kullanılmadığını ortaya çıkarmaktadır. “XP 2002 Konferansında Standish Group tarafından sunulan raporda yazılımın %45 özelliğinin hiç kullanılmadığını ancak özelliklerinin %20 kadarının her zaman ya da sıklıkla kullanıldığını ifade etmiştir.

13 Bir Diğer Araştırma Diğer bir çalışma, 2001 Yılı IEEE 26. Yazılım Mühendisliği Atölye Çalışmasının “Yazılım Geliştirme Yatırımında Gereksinmelerin Geçerliliği” başlıklı raporunda, 15 yıl boyunca 400 yazılım projesi üzerinde yapılan irdelemede; yazılım kodunun %5 den az bölümünün gerçekten sürekli kullanıldığının saptandığını ifade etmektedir.

14 CHAOS Araştırması uygulama yazılımının içeriği özelliklerin :
CHAOS Çalışmasında belirlenen bulgularda incelenen yazılım kümesinde ; uygulama yazılımının içeriği özelliklerin : %64 oranının nadiren ya da hiç kullanılmadığı ifade edilmektedir. Aynı araştırmada, 15 yıl boyunca 400 uygulama yazılımı üzerinde yapılan gözlemde: Hiç kullanılmayan özelliklerinin %45, bazen kullanılma oranın %16 , sıklıkla kullanılma oranının %13, nadiren kullanılma oranın %19 ve her zaman kullanılma oranının %7 olduğunu ifade etmektedir.

15 yazılımın özelliklerinin kullanım oranları grafiği

16 Bulgularla “Saçım” Araştırmanın özetlenen sonuçlarında, bir yazılım bütününün bölümlerinin kullanıcı ya da uygulama aşamasında kullanabilirlik gereksinmesi oranı acaba bir “saçımı” diğer bir deyişle israfı işaret ediyor mu?. Kullanılmayan yazılım parçasının %45 varan oranlarda görülmesi, yazılım geliştirmenin zaman, maliyet ve emek üçgeninde nedenli “saçım”, diğer bir değişle “israf” ya da “kayıp “ doğurduğunu işaret ediyor mu? savının irdelenmesi; yazılım tasarımının gereksinmelerin belirlenmesi aşamalarında, gereksinme özelliklerinin geçerliğinin işlev ve zaman koşulları ile bulgulanması ile ortaya çıkmaktadır. Bir Soru? Acaba bu irdeleme süreci, üretim zincirinin işlevsel parçalara ayrılıp incelenmesine ilke ve kuram getiren Fortism ya da Taylorism süreçlerine benzetilebilir mi?

17 “Lean” Yazılım Geliştirme Yaklaşımı
İşte bu soruların yanıtı “lean” ilkeleri ile bezenen bir yazılım geliştirme yöntemi ile veriliyor. 2003 Yılında Mary ve Tom Poppendieck’lerin “Lean Software Development” ve 2006 da “Implementing Lean Software Development: From Consept to Cash” isimli kitapları ile tanıttıkları fakat bir çok yazılım araştırmacısının katkıları ile oluşturulan, “Lean” adı ile tanıtılan yazılım geliştirme yöntemi (‘Denetim zincinciri’ yaklasımından esinlenerek) “saçımı” en aza indirecek yeni yaklaşımlar getirmektedir.

18 Yazılım Geliştirmede Tarihsel Süreç
Genellikle kurumsal uygulamalar için yazılım evlerince geliştirilen çok amaçlı programlar topluluğu Uygulama Yazılım Paketi olarak isimlendirilir. Kurumsal genel iş uygulamaları için hazırlanan çok kullanıcılı, çok amaçlı programlar içerdiği seçenek çizelgeleri ile, kullanıcının gereksinmelerine göre düzenlenebilme olanakları da sağlar. Rastgele örnek vermek gerekirse Kurumsal Kaynak Planlaması, Exel, Veritabanı uygulama yazılımı paketleri programları kullanıcı uygulamasına yönelik seçenekli içerik sunar.

19 Yazılım Geliştirmede Tarihsel Süreç
Kurumasal çok kullanıcılı bilgi sistemlerinin temel kullanıcı öğesi olan uygulama yazılım paketlerinin bütünleşik sistem içindeki kapsamı ile, geliştirilmesinde izlenen sistem ve yazılım mühendisliği süreçlerinin en önemli adımlardan biri; gereksinmelerin saptanması ve gereklilik koşullarının incelenmesi çözümlemesi ve sorgulanıp koşullandırılmasıdır. Bu süreçte, gereksinmelerin gizil gereksizlik işlemlerinden arındırılamayışı, yazılımı gerek geliştirme gerekse uygulama süreçlerinde parasal ve zamansal dolayısı ile verimlilik ve kullanabilirlik yönde ters etkileyen riskler taşıdığı kolaylıkla söylenebilir.

20 Alışıla Gelmiş Yaklaşım
Araştırmacılar, 1970 de Wiston Royce ‘un “Managing the Development of Large Software Systems” isimli kitabı ile ortaya attığı: Şelale-“Waterfal” Yazılım Geliştirme Yöntemini açıklarken, yöntemin “riskli” ve “başarısızlığı davet edebilir” olduğuna işaret ettiğini okumadıklarını söylüyor ... yaygın kullanılan bir yöntem olan Şelale Yönteminin uygulama yazılımı projesi geliştirmede ağırlıkla yer aldığı izlenen bir bulgudur.

21 Yazılım Geliştirmede Tarihsel Süreç
1990’li yıllarda “Şelale Yöntemi” önemini yitirmeğe başlamasına karşın, ABD Savunma Bakanlığı tarafından DOD-STD-2167 türevi ile standart olarak tanımlanması ardından, 1994 de bu değerlendirmesinden vazgeçerek Bakanlıkça, MIL-STD-498 ile yinelemeli yöntemlerin standart kabul ettiğini görüyoruz. Yazılım geliştirme yöntemlerinin 1990’larda “Lightwate”, 2000’lerde “Agile” adı verilen yöntemle yeni bakış açıları kazanarak güncelliği söylenebilir. Belirtmek gerekir ki, yeni yöntemlere uyum sağlayamadığı söylenen “Şelale Yöntemi”nin yaygınca kullanımı bu gün de devam etmektedirler. Diğer taraftan yalınlığı, iyi tanımlanmış adımlardan oluşması, adımlarının izlenebilir olma özellikleri bu yöntemin, üst-yöneticilerce tercih etmesine neden olduğu da bir gerçektir. Buna karşın, değişikliğe açık olmamasının yönetebilirliğini zorlaştırdığı ayrı bir görüş olarak not edilmektedir.

22 Yazılım Geliştirmede Tarihsel Süreç
1990’lardan sonra bütünleşik çok kullanıcılı sistemlerin yer alması ile, yazılım teknolojinin değişimi yanında özellikle uygulamanın çeşitlenmesi ve kullanıcı nüfusunda patlama denebilecek artışların, yazılım geliştirme yöntemlerinde yeni arayışlara yol açtığı söylenebilir. “Çevik –Agile” Yöntemi ile başlayan değişim içinde; “Scrum”, “XP”, “Cleanroom”, “Cristal”, “FDD”, “UP”, “RUP”, “AUP”, “EUP”, “DSDM” gibi yaklaşımlar üzerlerindeki tartışmalar sürdürülürken; “Lean Yazılım Geliştirme” yönteminin yeni bir yazılım geliştirme rüzgarının ilginç bir felsefe ile ortaya çıktığını görüyoruz...

23 Yeni Bir Yaklaşım: “Just-in-Time” ve “Lean”
İkinci Dünya Savaşından sonra 1945’lerde “Toyota Motor Company” başkanı Kiichiro, Toyota’un “Üç yıl içinde Amerika Otomobil Endüstrisine yetişmeliyiz.” Öngörüsü doğrultusunda yapılan çalışmada araştırmacılar ; Ford Motor Fabrikalarını ziyaret ediyor. Araştırmacı Taiichi Ohno’un kaydettiği iki önemli izlenimden biri “Büyük stoklar” ve ikincisi “Fabrikanın değişik noktalarda gereksiz işlemler” oluyor... Fabrikadaki İzlenimlerinden mutlu olamayan Ohno ve arkadaşları, Amerika’da Süper Marketleri gezerken ürün bilgilerinin kayıt ve stok işleminin, malın satışından hemen sonra işlendiğini belirliyor: Doğru malzemenin, doğru tutarının, doğru zamanda, doğru yerde, elde edilmesini işleyen bu uygulama Ohno’ya “Just-in-time system” adını verdiği işleme yöntemini oluşturmasına neden oluyor.

24 Yeni Bir Yaklaşım: “Just-in-Time” ve “Lean”
Yöntemin ilkesel yaklaşımı: Japon Otomobil Endüstrisinde, “Just-inTime Manufactoring” ya da “Toyota Production System” adı ile geliştirilen üretim yöntemine dayanıyor. Üretimde verimliği artırmak için geliştirilen bu yaklaşım, 1990’larda üç araştırmacının yazdığı “The Machine That Changed the World” isimli kitapla “Lean Production System” adını ile tanıtılıyor. Japon otomotiv endüstrisinin üretim verimliliği Amerikan devleri ile kıyaslandığında her açıdan yaklaşık 10 kat daha kötü durumda iken, geliştirilen üretim sistemi yöntemi ile, Toyota, 70’li yılların başlarına gelindiğinde durumu tersine çevirmeyi başarmış ve bu yıllarda tüm dünyayı etkileyen 1973 Petrol Krizi’nden nerede ise hiç etkilenmeden kârlılığını koruyabilmiştir.

25 Yeni Bir Yaklaşım: “Just-in-Time” ve “Lean”
"Tam Zamanında -Just in Time (JIT)” çarpıcı deyişi ile tanımlanan ilke; üretimi ve verimliliği artırmak için geliştirilen sayımlama yöntemidir. "Üretim sürecinde bir sonraki işlemin üretimini de göz önünde tutarak iş sırasını belirleme yaklaşımı; depolama işleminde sipariş verme konumunda gelindiğini ve bu noktadan sonra siparişin karşılanması gerektiğini bildiren bu strateji sayesinde en verimli depo hacmi ve üretim devamlılığı sağlanmaktadır.“ Kısaca,Tam Zamanında yalın gereksinme çözümlemesi ile, istemi mükemmel kalite ile artıksız olarak zamanında (gereksendiği gibi) üretmek ve istendiği zamanda doğru yere ulaştırma yöntemidir denebilir.

26 Tam Zamanında “Just-in-Time” ilkesi
. Bu yaklaşımdan esinlenen yazılım geliştiriciler ilginç bir tasarım yolu geliştirmişlerdir. Hemen söylemek gerekirse; Tam Zamanında ilkesinin “saçım” değeri üç temel niteliği içermektedir: 1- Gereksinmeye erişim , 2- Gereksinme belirlemesi, 3- Parçaların dökümü. Ayrıca, İki düzeyde yeniden sorgulama taşıyor: a) İşlem süreci tasarımı: (İş sürecinin yeniden tasarımı, işlem kümeleri parçalama, İşlemleri ilişkilendirme, iş süreci işlemlerini dengeleme, önleyici tamamlama, işlem zamanını azaltmak, b) Toplam kalite denetimi

27 Lean Yazılım Geliştirme Yöntemi
Yazılım geliştirme sürecine yeni bir yaklaşım getiren “Lean Yazılım Geliştirme Yöntemi; ” “saçım” içeriğini en aza indirmeye kuramsal çözüm getirmesi ile özellik taşır. Yaklaşımın ilkesel amaçları: Gereksizleri elemek, Kaliteyi yerleştirmek, Yeni bilgi yaratmak, Yüklenilenlere uymak, Çabuk dağıtım, Kişilere saygılı olmak, En uygun durumu seçmek olarak özetlenebilir.

28 Lean Yazılım Geliştirme Yöntemi
İşleme sürecinde gereksiz işlemleri yakalayıp ayırarak üreticiye, değer yaratan verimli işlem zincirini en kısa yoldan nasıl sağlarız? Ya da gereksiz işlemleri-“israfı” nasıl ortadan kaldırırız? İlkelerinin düşünce felsefesinden doğan kurguyu geliştiriyor. Örneğin, üretim bandı zincirinde olumsuz bir işlem ya da hata, tüm bant işleyişinin durmasına neden oluyor ve hata giderildikten sonra süreç devam ediyordu...

29 Lean Yazılım Geliştirme Yöntemi
Lean yönteminin en ilginç yaklaşımı; işleme süreçlerinin haritasını bölünmez parçalara ayırarak çıkarmak, hangi işlem adımlarının değer yarattığını ve hangi işlem adımlarının değer yaratmadığını belirleme önerisidir. “Değer akışı haritası” adını verilen bu yaklaşımın amacı; değer yaratan adımları geliştirmek ve değer yaratmayan/ gereksiz adımları yok etmekte düğümleniyor. İşlem süreç haritasının değerlendirmesinde değer yaratmayan adımlar ikiye ayrılıyor: Değer yaratmıyor fakat yer alması zorunlu adımlar, tam anlamı ile gereksiz kaldırılabilir adımlar...

30 Lean Yazılım Geliştirme Yöntemi
“Lean” dilinde Japon üretim sürecinden esinlenilen birçok yeni işlevsel sözcük/terim üretiyor. Örneğin: Jidoka- Bağımlı olmama, Kaizen- Değer ekleyen adım, Muda- Değer üretmeyen... Hemen her alandaki uygulama süreçleri; insanın el ve erişim becerisi ile yerine getirebileceği adımlar olarak tanımlanıyor, bu yapı genellikle yazılım tasarımcılarının gerekli ya da gerekli değil yaklaşımında sorun olageldiği de bilinmektedir...

31 Lean Yazılım Geliştirme Yöntemi
Toyoto Üretim Sisteminden esinlenilerek geliştirilen “Lean” yazılım geliştirme yönteminin beş temel prensibi : Değer, Değer Akışı, Akış, Çekme ve Kusursuzluk kavramları ile gerçekten yeni bir yaklaşım sergiliyor. Bu kavramların içeriğine yalın olarak bakacak olursak; Değer - Müşteri tarafından tanımlanır. Sonucu yaratmada müşteri değerinin etkisi nedir? Değer akışı sürecini oluşturmada değer yaratan ya da değer yaratmayan işlemlerin neler olduğu anlaşılmalıdır. Değer Akışı - Sonuç işleminde, önce müşteri değerinin yeri anlaşılır, sonucu yaratacak gerekli işlem adımlarına dayalı olarak değer akış süreci oluşur. Her adım değer katan işlem, değer katmayan fakat gerekli işlem ve değer katmayan işlem olarak sınıflandırılır. Akış- Üretim Süreci sürekli içerikte tasarlanmalıdır... “İşleme sürecinde gereksiz işlemleri yakalayıp ayırmak” ya da “Gereksiz işlemleri=israfı” ortadan kaldırmak”.

32 Lean Yazılım Geliştirme Yöntemi
Yazılım geliştirmede; uygulamanın küçük parçalı örneklerini geliştirip, kullanıcılarla birlikte deneme-sınama ve irdeleme (yanılma-düzeltme-geri besleme) “Modelleme-Prototyping” yöntemleri ile de, her ne kadar kullanıcıya en uygun ve en verimli uygulama adımlarını oluşturma yaklaşımı geliştiriliyor olsa da, “Lean” Yönteminin “israfı ortadan kaldırma” koşulu yakınlığı tartışılabilir... Yazılım projesi tasarımında yazılım parçalarının oluşumunun içerik kuralları ve gereksenen girdi ile oluşturulacak çıktı belirlemede birincil tanımlama, kullanıcının istemi doğrultusundadır. Yazılımın her koşulda bugün ve yarın geçerli yanıtı oluşturması beklentisi yaklaşım adımlarını çok dikkatlice irdelenme gereği, yukarıdaki çarpıcı sonuçlardan kolayca çıkarılabilir... “Lean” Yöntemi bu açığı “ Değer Akışı Haritası- Value Stream Map (VSM)” adını verdiği süreç değerlendirme yaklaşımı ile ortadan kaldırmayı öngörüyor...

33 Lean Yazılım Geliştirme Yöntemi
Bu yaklaşımda ayrıcalıklı bir özellik, işlem adımlarının belirlenmesinde farklı bakış açılı üç uzmanın birlikte çalışması ile belirlenmesinin koşul olmasıdır. Yazılım işlem adımlarının çözümlemesi ve tasarımında bu yaklaşımla; Konu uzmanı, Kullanıcı ve Yazılım Tasarımcısı - Mimarı grupları birlikte çalışmalı ve işlem adımlarının yeterliğini ve gerekliğini birlikte sınama ve geri besleme yolu ile karar vermelidir... Yazılım programının işlem adımlarının geçerliğinin bir başka açıdan önemi de yazılım geliştirme maliyeti olarak karşımıza çıkması hiç de şaşırtıcı değildir. Yöntemin,düğüm noktası olan “değer” kavramı bu düğümü irdelemesi ile de bir kez daha önem kazanıyor...

34 Lean Yazılım Geliştirme Yöntemi
"Tam Zamanında” kuralı ile yaratılan yeni terim ve kavramlar yöntemin can damarını oluşturuyor: Örneğin,“Lean” geliştiricilerinin Japoncada seçtikleri “Muda” terimi ; “kullanıcı tarafından öne sürülen fakat değer üretmeyen kaynaklar” ın yeterli çözümlemesini öne çıkarmaktadır. Kuşkusuz; bir yazılım paketinin tüm özelliklerinin (kodlarının) her kullanıcı adımında tarafından sıklıkla ile kullanılması beklenemez. Yazılım uygulamalarının uzun soluklu ve geniş olanaklı içerikte olması amaçlandığından, yazılımın her düzeyinin ve olanağının sürekli kullanılmaması beklenen bir sonuçtur da olabilir ?

35 Karşılaştırma Değer yaratan işlevin yönteminin içeriğinde aranması lean yöntemi ile öne çıkarmaktadır. Örneğin; alışılagelmiş Şelale yöntemi’nde; kullanıcının istek ve gereksinmelerine uygunluğunun “Sınanmasını” yazılımın tümü ile geliştirmesinden sonraki adım olarak tanımlaması, geri beslemede destekleme eksikliği gibi bir olanaksızlığı akla getiriyor. Diğerlerinde, tüm yazılım adımlarının “gerekli” ya da “gereksiz” değerlendirmesi ile süzgeçten geçirilmesi zorlaması son aşamada olanaksızdır. Kaldı ki yöntem bu sınamayı “Gereksenenler”in belirlenmesinde ağırlıklı olarak yerine getirdiğini varsayıyor...

36 Lean Yazılım Geliştirme Yöntemi
Sonuç “Lean” yaklaşımını uygulamaya kolaylık sağlamak için; acaba, uygulama yazılımlarının tasarımında “Gereksenenler”i önceden sınıflayan katmanlı bir tasarım yöntemi, "işlem", “maliyet” ve “zaman” gibi üç önemli etmenin ekonomisinde, geliştirme ve kullanım süreçlerinde koşut olarak yarar doğuracağında kuşku yoktur. Örneğin; “Gereksinimlerin” belirlemesinde ve tasarımda model: “Her zaman kullanılacak süreçler/işlemler”, “Bazen kullanılacak süreçler/ işlemler”, “Sıklıkla kullanılacak süreçler/işlemler” ve “Her zaman kullanılacak süreçler/işlemler” katmanları paylaşımında kurgulana bilir mi? Çok yönlü deneyimlerden geçmiş indirgenmiş "tam zamanında" irdelemesinin her yazılım yöntemine eklenmesi yazılımın verimliliğini artıracağında kuşku olmayacak bir uygulama içerdiği kolaylıkla söylenebilir.

37 Lean Yazılım Geliştirme Yöntemi
“Lean” üretim öngörülerinden, yazılım geliştirme yöntemine aktarılan “Saçımı Ortadan Kaldırma - Eliminate Waste” ilkesinin "son kullanıcıya ya da müşterinin" uygulama yazılım paketinin verimliğini artırmada artan oranlarda önem kazanacağı beklenmelidir. Yazılım geliştirmede bir genel değerlendirme gerekirse; ülke yönetimini yürütmek amaçlı politik partilerin yönetim görüşleri gibi, yazılım geliştirmede de çok farklı yaklaşımlar söz konusu olabilir.

38 Lean Yazılım Geliştirme Yöntemi
Kaynaklar: 1-Hibbs, S.Jewell, M.Sullivan, “The Art of Lean Software Development”,O’ReillyMedia Inc ABD 2- By Koichi Shimokawa, Takahiro Fujimoto · The Birth of Lean, Released January 2009 3-Software Development , wikipedia 4-brief history of waste reduction thinking, wikipedia 5- Scott.W.Ambler, The Principles of Lean Software Development, Submitted on Mon, ,www. 6- Zafer Uran Zaman Yalın, Üretim Metodolojisi, 7- Chiristoph Steindl, Lean Software Development, IBM Central Regin Germany,2004

39 Lean Yazılım Geliştirme Yöntemi
Sözlerimi, Albert Einstein’in bir sözünün yazılım geliştirmede de geçerli olabileceğini öğütleyerek bitirmek istiyorum. “Everything should be made as simple as possible, but not simpler.” Beni Dinlediğiniz için Teşekkür ederim! N. Kaya Kılan

40 Lean Yazılım Geliştirme Yöntemi
TEŞEKKÜRLER !!

41

42

43

44

45

46

47

48

49

50

51

52

53