�ݺ�ߣ

Editor's Notes

• #5: Görsel Tasarım (Visual Modeling) geliştirilen bir çözüme yönelik olarak, gereksinim, analiz ve tasarım çalışmalarının büyük oranda yazılı metinlerden ziyade, sembolik bir dil kullanılarak, görsel olarak gerçekleştirilmesine denir. Böylelikle, sistemin karmaşıklıklarının gizlenebilmelerine ve ihtiyaç duyulduğunda (yazılı metinlere başvurularak, vs.) detayların öğrenilmesine imkan verir.
• #6: Unified Modeling Language yazılım süreci aşağıdaki hedeflere hizmet etmek üzere tanımlanmış ve geliştirilmiştir: Use Case Driven Geliştirilen yazılımın parçalara ayrılması için kullanılan en alt birim, kullanıcıya sağlanan faydalar bazında gruplanmış senaryolardır. Bu senaryolara use case veya kullanım Senaryoları denir. Örneğin, Banka Müşterisi para çekmek için ATM kullanıyorsa: bu işlemle ilgili olarak ATM’den bakiyesini öğrenip, para çekmek istediği hesabı seçerek para çekebiliyorsa, UML kullandığımızda tüm gereksinim, analiz, tasarım ve implementasyon çalışmalarımızı bu çerçevede, yani “Para Çekmek” kapsamında yapacağız demektir. 2. Architecture Centric Geliştirilen yazılımın çeşitli referanslara bağlı olarak (Örneğin, tekrar kullanım, çok katmanlı mimari, middleware kullanımı, vs.) katmanlar halinde oluşturulmasıdır. Tasarım çalışmaları esnasında kesinleşecek bu katmanlar geliştirilen yazılımın modüler yapısı (Örneğin, muhasebe, kredi modülleri gibi) ve kullanıcı faydası odaklı olarak tanımlanan kullanım senaryolarıyla da örtüşeceğinden, çok daha esnek, bakımı ve tekrar kullanılabilirliği kolay bir sistem yapısı oluşturmak mümkündür. 3. Iterative Geliştirilen bir ürüne yönelik olarak kullanılan yazılım mühendisliği süreç tanımı içerisindeki faaliyetlerin (disiplinlerin) tekrar edilmesiyle, yazılımın en riskli parçalarından en önemsiz parçalarına kadar kademe kademe oluşturulmasına imkan veren bir yaklaşımdır. 4. Incremental Iterative yaklaşımla oluşturulan yazılım parçalarının birbirlerini tamamlayarak, sistemin bir bütünlük içerisinde oluşturulmasını sağlayan bir yaklaşımdır.
• #7: UML’in gelişti ri lmesindeki en önemli üç kişiden biri olan, James Rumbaugh’un model ve görsel tasarım (visual modeling) tanımlarına bakacak olursak, Model: Bir model sistemin tüm detay bilgilerine sahip olarak kullanımı karmaşık olan bir dokümantasyondan ziyade, o sistemin sadece vazgeçilmez özelliklerini gösteren, gerçeğin basitleştirilmiş bir gösterimidir. Görsel Tasarım (Visual Modeling): Anlamı kişiye göre değişmeyen tanımlı ve standartlaşmış sembollerin kullanımıyla yapılan gereksinim, analiz ve tasarım çalışmalarıdır. Bu arada, tekrar vurgulayacak olursak, UML’in gelişimi açısından en önemli üç kişi, diğer bir deyişle “Three Amigos”: Grady Booch, James Rumbaugh ve Ivar Jacobson’dur.
• #8: Görsel Tasarımın (Visual Modeling) Faydaları: Mevcut veya oluşturulmak istenen iş akışı bilgisini derlemek, değerlendirmek ve Geliştirmek, Farklı rollere kendi önceliklerine göre bilgiyi filtreleyerek göstererek ve bu roller arasındaki bilgi alış verişi standartlarını belirleyerek, iletişimi kolaylaştırmak, Proje kontrolünü geliştirilen sistemi müşteri ihtiyaçlarına ve tasarım kısıtlamalarına direkt olarak bağlayarak ve proje süresince müşteri etkileşimiyle sistemin devamlı test edilmesini sağlayarak artırmak. Sistemin yazılım ekibi rollerine ek olarak teknolojik, yazılım süreç tanımı gereksinimleri veya şirketinizin önceliklerine bağlı olarak tanımlı bir mimari çerçevesinde geliştirilmesine imkan vermek. Mümkün olan en üst düzeyde tekrar kullanımı sağlamak. En uç örnekler olarak Konuya Özel Uygulama Referans Modellerini verebiliriz.
• #9: Geleneksel yaklaşım altında birbirinden kopuk fonksiyonlar olarak algılanan problem ortamı ve geliştirilen sistem, Use Case (Kullanım Senaryoları) yaklaşımı altında birbiriyle alakalı fonksiyonların gruplanmasına dönüşmüştür. Bu yeni yaklaşım, geliştirilen yazılıma yönelik tüm çalışmaların (Gereksinim Yönetimi, Analiz ve Tasarım, İmplementasyon, Deployment, vs.) müşteri ihtiyaç ve önceliklerine uygun olarak sürdürülebilmelerine imkan vermektedir.
• #10: Birlikte çalışması gereken bu iki takım çoğu zaman farklı kelime hazneleri yüzünden anlaşamıyor. Görsel Tasarımda UML kullanımı müşterinin dünyasıyla sistemin dünyasını birbirine bağlar . Farklı rolleri canlandıran yazılım ekibi, sahip oldukları çıkar farklılıkları ve çalışma ürünlerini korumalarına rağmen, standart ve anlamı kişilere göre değişmeyen sembolik bir dil kullandıklarından, birbirleriyle anlaşabilirler. Bunun da ötesinde, aynı rolü canlandıran kişiler UML aracılığıyla birbirlerinin yaklaşımlarını değerlendirebilmekte ve daha isabetli yaklaşımı seçebilmektedirler. Herhangi bir konunun deneyimli kadronuzdan daha az deneyimli kadronuza transferi, istenilen bilgi birikimlerinin şirketler arasında el değiştirebilmesi ve hatta satılabilir ürünler haline gelmeleri yine UML sayesinde mümkün olan faydalardan bazılarıdır.
• #11: Nesne Tabanlı Analiz ve Tasarım doğuşundaki temel nedenlerden biri uzayıp giden kod dosyalarındaki fonksiyonların arasında kaybolmaktan kurtulmak ve yazılımın kavramsal tasarımını daha kolay ve etkili bir şekilde yapabilmekti. Bununla birlikte giderek artan yazılım karmaşıklıkları, yüzlerce hatta binlerce class’dan oluşan sistemleri birer istisna olmaktan çıkarınca, daha üst seviyede tasarım modeline ihtiyaç ortaya çıktı. Buradaki en temel ihtiyaç geliştirilen sisteme farklı yönlerden bakabilmek ve tüketilen bilgilerin detay seviyelerini kontrol altına alabilmek olarak kendini gösterdi. UML’in yardımıyla görsel tasarım bu imkanları sağlayarak proje kontrolümüzü artırmamıza yardımcı olmaktadır.
• #12: Görsel Tasarımın sağladığı diğer fayda oluşturulan problem çözümünün olabildiğince implementasyon detaylarından arındırılabilmesidir. Böylece tasarımcılar diledikleri teknoloji değişikliklerine daha kolayca adapte olabilirler. Desteği, seçilen UML ürününe göre değişmekle birlikte, yeni yaklaşımlardan bir tanesi Platform Independent Model (PIM) yaklaşımıdır. Bu yaklaşım altında, tanımlanan tasarım herhangi bir teknolojiye uyarlanmamıştır. Dolayısıyla aynı tasarımın ileride istenen bir Platform Specific Model’e (PSM) dönüştürülmesi daha kolayca yapılmaktadır. Geleneksel UML yaklaşımı altında ise Analiz Modeli sonrasında yapılan çalışmalar bir teknolojiye has olarak yapılmak zorundadır. Bu iki yaklaşım arasında pek çok benzerlikler olsa da ilkinde tasarımı dahi bir teknolojiden bağımsız yapmak mümkündür. Dolayısıyla analizi takiben yeni bir soyutlama (abstraction) seviyesi daha mümkündür.
• #13: UML kullanımının bizlere sağladığı diğer bir fayda da dilenen seviyede Tekrar Kullanım imkanıdır. Kullanmak istediğimiz herhangi bir modülü UML projemize import ederek ve/veya projemizi mevcut bir altyapının üstüne geliştirerek yüksek seviyede tekrar kullanılabilirlik sağlayabiliriz. Bunun da ötesinde, eğer tekrar kullanılabilirlik imkanı tasarımdan ziyade gereksinim ve analiz çalışmaları için mümkünse bunu da UML aracılığıyla kolaylıkla sağlayabiliriz. Ayrıca, ihtiyaç duyduğumuz analiz ve tasarım kalıplarını tanımlayarak onları da tekrar tekrar kullanabiliriz. Yine, UML ürününe bağlı olmakla birlikte, proje yönetimi açısından ihtiyaç duyduğumuz metrikler ve dokümantasyon şablonlarını da tekrar kullanmamız mümkündür.
• #14: UML öncesi Yazılım Dünyasına baktığımızda, daha çok Yapısal analiz ve tasarım tekniklerinin, Fonksiyon ve Modül bazında yazılım geliştirmenin egemen olduğunu görmekteyiz. Bunun aksine UML sonrasında, Nesne Tabanlı Teknolojilerin, Hızlı Yazılım Geliştirme Ürünlerinin, SDK yazmaktan SDK kullanma eğiliminin ve Standart Yazılım Mühendisliği Süreçlerinin arttığını görürüz.
• #15: UML öncesinde, Yazılım Geliştirme yöntemleri açısından müşteri istekleri, tasarım kısıtlamaları ve yazılım projesi sürecinde gerçekleştirilen faaliyetlerin birbirleri arasındaki takip zorlukları nedeniyle o günkü yazılım sistemleri için aşağıdaki tanımlama çok sık kullanılmıştır: “ Eğer yazılım projelerini mimari projelerle karşılaştıracak olursak, köpek kulübesi yaparken takındığımız yaklaşımın gökdelen yaparken takındığımızdan farklı olması gerekir. Yazılım dünyasında ise bunun aksini, proje üzerindeki kontrol eksikliğinden dolayı, çok sık olarak görmekteyiz. Genellikle bir gökdelen gibi gözümüzün önünde yükselen yazılım sistemi, sadece pek çok köpek kulübesinin üstüste inşa edilmesinden ibaret. Yazılım projelerinin yüksek başarısızlık oranlarının en önemli nedeni de bu olsa gerek.” Grady Booch – IBM Rational – Chief Scientist
• #17: Bir UML modeli çeşitli şemaların yazılım süreci içindeki rolerine uygun olarak gruplanması ve ilişkilendirilmesiyle oluşturulur. Gereksinimlerin, Analiz ve Tasarım çalışmalarının, İmplementasyonla (üretilen kod) ilişkilendirilmesini ve Değişikliğin Yönetilmesini oluşturulan bu model yapısıyla sağlayabiliyoruz. Sizin de tahmin edeceğiniz gibi, oluşturulacak model yapısı kurumunuz ve elemanlarınızın özelliklerine, geliştirdiğiniz yazılımın yapısına ve kalite hedeflerinize bağlı olarak değişecektir. Aynı kurum içerisinde farklı amaçlara yönelik, farklı model yapıları (farklı süreçleri) kullanmak mümkündür. Çalışmalarımızda özel bir önem göstereceğimiz UML Şemalarını, göreceli önemlerine göre (Daha önemliler ‘*’ ile işaretlenmiştir), sıralayacak olursak, Davranış Şemaları: Use Case Şeması [*] Activity Şeması [*] Sequence Şeması [*] Collaboration Şeması State Machine Şeması [*] Yapısal Şemalar: Class Şeması [*] Paket Şeması [*] Component Şeması Deployment Şeması
• #18: Modellerin faydalarına değinecek olursak, Problem Çözme Mekanizması Modelleri kullanarak problem ortamını (problem domain) farklı açılardan inceleyebilir, riskli unsurları saptayabiliriz. Dolayısıyla, UML problem tahlili amaçlı olarak kullanılabilir. Alternatif Çözümleri Görebilme Aynı rolü canlandıran kişilerin yaklaşımlarını karşılaştırabildikleri ve deneyimli kişilerin diğerlerine olası yaklaşımları ifade ettiği çalışma türleridir. Bu tür çalışmalar neticesinde Bugün adlarını çok sık duyduğumuz Design Patterns (GOF) ve Analysis Patterns (Martin Fowler) yaklaşımları geliştirilebilmişlerdir. Birbirine bağlı olarak çalışan, birinin ürettiği bilgileri diğerinin tüketerek yeni çalışmalar yapan kişilerin ilişkileri açısından da önem taşıyan bu imkan, bu tür grupların da birbirlerini etkiyerek toplam verimliliğin artmasını sağlamaktadır. Sistem Karmaşıklığının Kontrolü UML Modelleri sistemin karmaşıklarının kontrol edilebilmesini bilgileri muhatabına göre filtreleyerek ve detay seviyesini yine bu muhataba yönelik olarak belirleyerek sağlar. Çalışma türleri de (Gereksinimler, Analiz ve Tasarım vs.) en seviyede modüller ve kullanım senaryoları aracılığıyla yönetilebildiklerinden, proje yönetim sorunlarının çözümleri büyük ölçüde kolaylaşmaktadır. Proje Maliyetini Düşmesi Maliyetin düşmesindeki en önemli nedenler, risklerin projenin başında tanımlanmaları, önemli tasarım kısıtlamalarının gereksinim aşamasından itibaren değerlendirilmeleri, kısa süreli iterasyonlarla müşteriden kopmayarak manevra kabiliyeti kazanmak ve yine aynı nedenden ötürü devamlı olarak ürünün test edilebilmesidir. Hataları Azaltmak Yukarıda saydığımız tüm imkanlar hataların azaltılmasına katkıda bulunmaktadır. UML hem kişisel olarak, hem de kurumunuzun yeterliliklerini her projenizde tekrar değerlendirebilmenize imkan verir. Yazılım ekibiniz ve müşterileriniz arasındaki haberleşmeyi ve verimliliği artırır. Yazılım ekibiniz arasındaki bilgi alış verişini hızlandırır ve yorum hatalarını ortadan kaldırarak, ekibinizin reaksiyon süre ve kalitesini iyileştirir.
• #19: Gündelik hayatta bir bina, otomobil veya uçağa ait modeller görebiliriz ancak yazılım dünyasında bu tür bir yaklaşım yakın zamana kadar mevcut değildi. Bugünlerde geliştirilen devasa sistemler ve başarısızlığın yüksek maliyeti yazılım dünyasını da aynı yaklaşımlara zorluyor. Bir sistemi oluşturmadan bir modelini oluşturmak ve olası problemleri büyük ölçüde azaltmak hedeflenmekte. Grady Booch’a göre bir model bir sistemin oluşturulma planını bize sağlamaktadır.
• #20: Kağıttan bir uçağı yaparken plan yapmayız çünkü işler yolunda gitmezse bir başka kağıt parçası alıp tekrar deneyebiliriz. Buna başarısızlık maliyetinin düşüklüğü diyebiliriz.
• #21: Eğer uçak mühendisleri hükümetten F-15 uçaklarını üretme isteklerini alsaydı tatmin etmeleri gereken iki merci olacaktı. Bunlardan bir tanesi hava kuvvetlerinin istekleri, diğeriyse havacılık mühendisliği kuralları. Bunun da ötesinde proje ekibinin elemanlarının profesyoneller olarak kabul edilmelerini sağlamak ve onları dayanabileceklerinden kötü iş koşullarına tabii tutmamak da önemli olacaktı. Tuhaf olan pek çok yazılım ekibinin F-15 ciddiyetindeki projelere kağıttan uçak yaklaşımıyla yaklaşıyor olmaları. Günümüzde daha karmaşık sistemlerin daha kısa sürede hazır olması talep ediliyor. Bu durumda yazılım ekipleri geleneksel yaklaşımlarına güvenerek daha uzun süre çalışıp, gereksinim dokümanlarını tek bilgi kaynağı olarak kullanarak daha sık kod üretmeye çalışıyorlar. Ne yazık ki, iyi düşünülmemiş sistem mimarisi yüzünden projeler çoğu zaman başarısızlığa uğramaya mahkümlar.
• #22: Grady Booch’a göre bir modelin dört temel amacı vardır: Modeller oluşturmak istediğimiz sistemi olası bir çözüm olarak tasavvur edebilmemizi sağlarlar. Bir model geliştirilen sistemin vizyonunun bir yazılım ekipleri arasında paylaşılabilmesini sağlar. Ellerinde sadece spesifikasyon ve gereksinim dokümanları olduğunda bir sistemin herkesçe paylaşılan bir vizyonunu oluşturmak son derece güçtür. Modeller bir sistemi anlaşılabilir kılarlar. Modeller bir sistemin davranışlarını belirleyecek yapısal özelliklerini belirleyebilmemizi sağlarlar. Bir model geliştirilen sistemin davranış ve yapısını kodlamadan önce dokümante etmeye yarar. Modeller sistemi oluştururken bize yol gösterecek birer şablon görevini görürler. Bir programcı için bir model işini yapmak için izleyebileceği bir yoldur. Bir programcını terimleri hatalı anladığı için farklı bir algoritmayı kodladığını düşünün. Modeller yoruma açık olmadığından bu tür hataları gidermeye yöneliktirler. Modeller aldığımız kararları dokümante etmeye yararlar. Uzun vadede bu kararları tekrar incelememiz gerektiğinde kolayca başvurup onları yeniden değerlendirebiliriz.
• #24: Doğru olarak oluşturulmuş modeller en büyük yazılım problemlerinizi işaret edenlerdir. Hatalı modellerse sizin için önemsiz konulara odaklananlardır. Yazılımda seçilen her model farklı bir dünya görüşüne tekabül eder. Örneğin konuya sadece Veri Tabanı Tasarımcı gibi bakarsak, elimizde entity relationship modelleri olur ve sistemin davranışını stored procedure ve trigger’larla canlandırmaya çalışabiliriz. Öte yandan eğer sisteme nesne tabanlı yazılım geliştiren bir programcı olarak bakarsak, karşımıza daha çok sistem mimarisi odaklı bir yaklaşımla çok sayıda class ve etkileşim senaryoları çıkar. Her modelin geçerlilik durumları ve bize sağlayacakları fayda / zarar oranı amaçlarımıza bağlıdır.
• #25: Bir GUI sistemi geliştirirken hedeflerinizi ifade edebilmek için tek gereken çabuçak oluşturulabilecek bir kullanıcı arayüzü prototipi olabilir. Diğer durumlarda, iletişim problemlerini inceleyebilmek için sistemler arası interface’lere yönelebilirsiniz. Her iki durumda da en iyi modeller detay seviyesini seçmenize imkan veren ve muhatabına göre şekillendirilebilenlerdir.
• #26: Model gerçekçiliği pek çok farklı anlama gelebilmektedir: Müşteri odaklılık, müşteriye sağlanacak faydalara ve sağlanma şekillerine duyarlılık Uymamız gereken tasarım kısıtlamaları ve kalite standartları Kullanmak istediğimiz satın alacağımız veya mevcut altyapılar Bizim için özellikle önemli yazılım mühendisliği süreçleri (Analiz, Tasarım vs.) Modelin gereğinden fazla ‘toz pembe’ bir tablo çizmemesi. Riskli unsurları işaret etmesi. Gerçeğin tüm gereksiz detaylarla anlaşılmaz hale gelmemesi. Önemli unsurların işaret edilerek, gerçeğin basitleştirilmesi.
• #27: Sistemin mimarisiyle ilgilenen pek çok rol var (sistem analisti, programcı, kullanıcı vs.). Bu farklı rollerin birbirleriyle anlaşabilmeleri ve sistemi birlikte değerlendirebilmeleri için hepsinin anlayabileceği bir sistem gösterimine ihtiyacımız var. Paydaşların farklı beklentileri olması ve sistemin karmaşıklığı nedeniyle sistem mimarisine farklı referanslarla bakabileceğimiz modellere ihtiyacımız var (architectural view). Architectural View: Belli bir referansa göre oluşturulan sistemin basitleştirilmiş bir resmidir. Bu basitleştirme referansa uygun olmayan elemanların ayıklanması ile sağlanır. Örnekler: Rational Unified Process tanımında 4+1 standarttır. Logical view: Sistemin fonksiyonel gereksinimlerine karşılık olarak oluşturulur. Tasarım Modeli, Temel Tasarım Paketleri, Modüller ve Class’ları içerir. Implementation view: Koda senkronize olan yazılım modülleri, paketlenmeleri, katmanlara ayrılmaları ve versiyonlanmalarını içerir. Process view: Sistemin run-time esnasındaki eş zamanlı özellklerini resmetmeye yöneliktir (task, thread veya process’ler ve etkileşimleri). Deployment view: Run-time bileşenlerinin platformlara ve donanıma nasıl dağıtıldığını resmetmeye yöneliktir. Use case view: Sistem mimarisini belirleyen senaryoları ve başarı kriterlerini içerir.
• #28: Modeller birbirlerine ‘tamamen bağımlı değillerdir.’ Ayrıca oluşturulup incelenebilirler fakat hala birbirleriyle ilişkileri vardır. Use Case View : Sistemin gereksinimleri Logical View : Problem ve Çözüm kelime haznesi Process View : Sistem process ve thread’lerinin dağılımları Implementation View : Sistemin fiziki olarak gerçekleştirilmesi Deployment View : Sistem mühendisliği odaklıdır. Unutulmamalıdır ki her sistem aynı sayıda modele ihtiyaç duymaz. Örneğin, tek CPU’lu bir sistem deployment modeline ihtiyaç duymayacaktır.
• #30: UML’in bahsettiğimiz faydaları sayesinde geliştirebileceğimiz çözümlerin pek çok çelişen ihtiyacı kolaylıkla tatmin edeceği düşüncesiyle, en sık verilen örnek Frank Lloyd Wright’ın “Fallingwater” adlı eseri olmuştur. Bir mimari şaheseri olarak kabul edilen ev, hem modern insanın ihtiyaçlarına hem de insanın doğasına uyarak geliştirilmiştir. Aynı zamanda, eser doğanın içinde bir bitki gibi doğal bir şekilde ‘yeşermiştir.’ Böyle yaklaşıldığında, yazılım terminolojisi kullanacak olursak, Gereksinim Yönetimi müşterinin güncel ve değişmez ihtiyaçlarını karşılamış, Analiz ve Tasarım müşteri istekleri ile tasarım kısıtlamalarına (Doğaya uyum, vs.) bağlı kalınarak gerçekleştirilmiştir. Mimarla ilgili daha detaylı bilgi için aşağıdaki linki kullanabilirsiniz: www.franklloydwright.org
• #31: UML netice itibariyle sadece sembolik bir dildir. Öğrenmesi ve kullanması kolay bir sembolik dildir. Bununla birlikte, bu dil şirket ihtiyaçlarımıza göre kişiselleştirilmemiş bir süreç tanımıyla birlikte kullanılmadığı zaman eksiktir. UML kullanımı esnasında gözümüzden pek çok şey kaçabilir. Bunlardan en önemlileri, mevcut olduğunu varsaydığı pek çok çalışma türü ve ürünü, yazılım mühendisliği rolleri ve genel olarak yazılım mühendisliğ süreçleri açısından vermemiz gereken stratejik kararlardır. Eğitim esnasında bu konulardan pek çoğuna değineceğiz ve eğitimi takiben verdiğimiz uyarlama çalışmalarında bu kararları gerçek projenize yönelik olarak birlikte vereceğiz.
• #32: Marantz ( http://www.marantz.com ) elektronik ses ve görüntü sistemlerinde kalitesiyle haklı bir ün kazanmış bir teknoloji şirketidir. Marantz’ın kaliteli tasarımlarının en uç noktasında ise elektronik mühendisi Ken Ishiwata’nın çalışmaları yer almaktadır. Ishiwata iyileştirdiği her Marantz ürününün üzerine imzasını atmakta ve ürün piyasaya bu şekilde verilmektedir. Ishiwata’nın konumuzla ilgisi ise, UML sayesinde yazılım mühendislerinin de altlarına imzalarını atabileceği, ürünün de ötesinde problem çözümü yöntemlerini tanıtıp yayabilecekleri bir ortam söz konusu olmaktadır. Bu düşünce doğrultusunda, UML’i değerlendirecek olursak, Yetenekli bilişim elemanları çalıştıkları şirketlerin ötesinde tanınabilecekler, Yeni mezunların ustaların bilgi edinmek için harcadıkları ‘dirsek çürütme’ süresi azalacak, Problem çözümü öğelerinin kendilerinin birer ürüne dönüşmeleri gerçekleşecek, İşverenler yazılımlarının kritik bölümlerini ayırarak, koruyup geliştirebilecekler ve Müteşebbis bilişim elemanları kendilerini gereksiz teknolojik detaylardan soyutlayarak, yeni iş fikirlerine odaklanabilecekler. Diğer bir deyişle, uzun zamandır anlaşma zorlukları yaşadıkları yönetim, satış ve pazarlama elemanları arasındaki yerlerini alabileceklerdir.
• #33: UML ile mümkün olan fırsatlara bir kaç örnek verirsek, Menkul Kıymetler yazılımlarında uzman bir şirket olan İnfina, bu iş bilgisini edinmek isteyenlere UML süreci ve ürünleriyle satmıştır, Anadolu Hayat Java/J2EE platformuna geçerken satın almaya karar verdiği altyapıyı UML şemalarıyla incelemiş ve serçmiştir. Kazanan Cybersoft altyapısı olmuştur, İş bilgisini yazılım gereksinimlerine dönüştürmek işteyen ve bu yüzden UML öğrenenler doktorlar ve diğer iş erbabı istisna olmaktan çıkmıştır, Bir Alman şirketi kavramsal olarak zor bir konu olan sigortacılık için bir uygulama referans modeli geliştirmiş ve ücretsiz olarak kullanıma sunmuştur. Bu modeli geliştiren ve eksiksizleştiren IBM, aynı modeli Kore’li bir şirkete 2,500,000 USD’a satmıştır.
• #35: İlham Kaynakları Max Goff: http://www.maxgoff.com Uzun yıllar Sun kadrosunda Teknoloji Yayıcı (Technological Evangelist) olarak çalışan Goff, bir süre önce Sun'daki görevinden ayrılarak kendi danışmanlık şirketini kurmuştu. Yazılımın insanlar üzerindeki sosyolojik ve ekonomik etkilerini düşüncelerine baz alan Goff'un en akılda kalıcı sözü ise: "If there is hope for humanity, it's in software" olmuştur.