Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

Akın Kaldıroğlu 19 Ocak 2010 Akın Kaldıroğlu 19 Ocak 2010.

Benzer bir sunumlar


... konulu sunumlar: "Akın Kaldıroğlu 19 Ocak 2010 Akın Kaldıroğlu 19 Ocak 2010."— Sunum transkripti:

1 Akın Kaldıroğlu 19 Ocak 2010 Akın Kaldıroğlu 19 Ocak 2010

2  Akın Kaldıroğlu 1993 yılından bu yana yazılım geliştirmektedir.  Mesleğe C ve C++ ile başladı, 1996’da ilk sürümüyle birlikte Java’ya geçti ve daha sonra onun üzerine başka bir gül koklamadı.  1993 yılından bu yana ABD ve Türkiye’de pek çok projede değişik rollerle yer almaktadır. Şu anda serbest danışman ve eğitmen olarak çalışmaktadır.  Ayrıca, Yazılım Mühendisliği, yazılım mimarileri, nesne-merkezli programlama, tasarım şablonları, Java vb. pek çok konuda ders vermekte ve Türkiye’de sağlıklı bir yazılım kültürü oluşmasını arzu etmektedir.  adresinde günlük yazmakta olup, katkıda bulunacaklara şimdiden müteşekkirdir.  Kendisine günlüğünden, adresinden ve diğer Facebook/LinkedIn/Twitter/FriendFeed gibi alanlardan  Akın Kaldıroğlu 1993 yılından bu yana yazılım geliştirmektedir.  Mesleğe C ve C++ ile başladı, 1996’da ilk sürümüyle birlikte Java’ya geçti ve daha sonra onun üzerine başka bir gül koklamadı.  1993 yılından bu yana ABD ve Türkiye’de pek çok projede değişik rollerle yer almaktadır. Şu anda serbest danışman ve eğitmen olarak çalışmaktadır.  Ayrıca, Yazılım Mühendisliği, yazılım mimarileri, nesne-merkezli programlama, tasarım şablonları, Java vb. pek çok konuda ders vermekte ve Türkiye’de sağlıklı bir yazılım kültürü oluşmasını arzu etmektedir.  adresinde günlük yazmakta olup, katkıda bulunacaklara şimdiden müteşekkirdir.  Kendisine günlüğünden, adresinden ve diğer Facebook/LinkedIn/Twitter/FriendFeed gibi alanlardan 2

3 Gündem 3 Sorular ve Halimizin Pür Meali Sorular ve Halimizin Pür Meali Silver Bullet – Sihirli Değnek 20+ Yıl ve Silver Bullet 20+ Yıl ve Silver Bullet Silver Bullet ve Türkiye  Bu sunumda 53 sayfa vardır.

4 Gündem 4 Sorular ve Halimizin Pür Meali Sorular ve Halimizin Pür Meali Silver Bullet – Sihirli Değnek 20+ Yıl ve Silver Bullet 20+ Yıl ve Silver Bullet Silver Bullet ve Türkiye

5 Sorular  Yazılımı Mühendisliği’ni diğer mühendisliklerden ayıran temel özellikler nelerdir?  Yazılım geliştirmek niye zordur?  Yazılımın zorluklarının üstesinden gelmek için neler yapılmalıdır?  Türkiye’deki yazılım kültürünün ana özellikleri nelerdir? 5

6 6

7 Halimizin Pür Meali  Bu resimler neyi anlatıyor?  Temelde bir yazılım projesindeki iletişim problemlerini esprili bir şekilde resmediyor  Neden bu problemler oluyor?  Yazılımcılar ve müşteriler, iletişim yönünden problemli kişiler mi? 7

8 8 Sorular ve Halimizin Pür Meali Sorular ve Halimizin Pür Meali Silver Bullet – Sihirli Değnek 20+ Yıl ve Silver Bullet 20+ Yıl ve Silver Bullet Silver Bullet ve Türkiye

9 No Silver Bullet I  Frederick Brooks, 1987 yılında bir makale yazdı ve IEEE’nin Computer dergisinin Nisan sayısında yayınlandı No Silver Bullet: Essence and Accidents of Software Engineering  Makale, yazarın “Mythical Man Month” isimli eserinde de yayınlandı 9

10 No Silver Bullet II  Makale, Yazılım Mühendisliği’nin asli (ana) ve arızi (ikincil) özelliklerini ele alıyor  Yazılım dünyasında çıkan yenilikleri, bu özellikler açısından değerlendiriyor  Makale, yayınlanmasını müteakip pek çok eleştiri ve destek aldı, halen de alıyor  Ama aradan geçen 20+ yıl makaleyi çoğunlukla haklı çıkardı 10

11 Silver Bullet nedir?  “Silver Bullet” ya da “Gümüş Kurşun”, Amerikan halk hikayelerindeki “kurt adam”ı alt eden kurşundur  Gerektiğinde, bu sebepten “Gümüş Kurşun” yerine “Sihirli Değnek” olarak çevirmek sanırım daha anlamlı  Sihirli Değnek’in Yazılım Mühendisliği’yle ilgisi nedir?  Çünkü yazılım projeleri de bizim kurt adamlarımızdır  Bu kurt adamları öldürecek gümüş kurşunumuz da yoktur 11

12 Zor Olmak Zorunda Mı? But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any- -no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware. 12

13 Sorun Ne?  Öncelikle bilinmelidir ki problem Yazılım Mühendisliği’ndeki ilerlemenin yavaşlığı değil, donanımdaki ilerlemelerin hızlı olmasındadır  Zaten diğer mühendislik dallarındaki gibi bir üretim hızı artışı yaşanması da mümkün değildir  Üretim hızında 10 katlık bir artış sağlayacak ne teknolojik ne de yönetsel bir metod olabilir  Bu sadece şu an için geçerli birşey değildir, yazılımın tabiatı icabı her zaman için geçerlidir 13

14 Asli ve Arızi Özellikler  Bunun sebebi, Yazılım Mühendisliği’nin asli özellikleridir  Asli (ana, esas, birincil) – arızi (yanal, ikincil) özellik ayrımı Aristo’nun ayrımıdır  Yazılım Mühendisliği’nin asli özelliklerinde iyileştirme yapmadan, çok ciddi ilerlemeler kaydetmek mümkün değildir  Yenilikler ise genelde arızi zorlukları hedef almakta ama asli zorluklar var olmaya devam etmektedir 14

15 Yazılımın Aslı Nedir? The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed. I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems. 15

16 Asli Zorluklar  Yazılım Mühendisliği’nin asli özellikleri/zorlukları şunlardır:  Karmaşıklık (Complexity)  Uyumluluk (Conformity)  Değişebilirlik (Changeability)  Görülmezlik (Invisibility) 16

17 Karmaşıklık I  Yazılım varlıkları, belki de büyüklük itibarıyla diğer insan yapılarından daha karmaşıktırlar çünkü hiçbir parçası birbirinin benzeri değildir  Bilgisayarlar zaten insanların bina ettiği pek çok şeyden daha karmaşıktır  Çok fazla sayıda durumları vardır.  Yazılım sistemleri ise bilgisayarlardan onlarca kat daha fazla duruma sahiptirler 17

18 Karmaşıklık II  Bir yazılım varlığını büyütmek sadece aynı elemanların daha büyük ebattakilerini tekrarlamak değildir, farklı elemanlarla sayıca büyümek demektir  Elemanların birbirleriyle ilişkisi doğrusal değildir  Yazılımın karmaşıklığı asli bir özelliktir, arizi değildir.  Bu yüzden bir yazılım varlığının karmaşıklığını ortadan kaldıran bir tanım, çoğu zaman onun aslını da ortadan kaldırır 18

19 Karmaşıklığın Sonuçları I  Karmaşıklıktan  İletişim zorluğu doğar  Bütün durumları kavramak zolayısıyla anlamak imkansızlaşır  Bir fonksiyon karmaşıksa onu çağırmak bile zorlaşır  Yan etki oluşturmaksızın programları yeni fonksiyonlara sahip olacak şekilde genişletmek zorlaşır  Gözde canlandırılamayan durumlar oluşur ki bunlar da güvenlik açıklarına sebep olur 19

20 Karmaşıklığın Sonuçları II  Karmaşıklıktan sadece teknik değil yönetim sorunları da çıkar  Karmaşıklık genel bakışı zor hale getirir ki bu durum da kavramsal tutarlılığa engel olur.  Karmaşıklık bütün sıkıntılı noktaların bulunup kontrol altına alınmasını zorlaştırır.  Karmaşıklık, öğrenme ve anlama konusunda o kadar büyük bir yük oluşturur ki çalışanların işten ayrılmaları bir yıkım haline gelir. 20

21 Uyumluluk I  Fizik de karmaşıktır ama genel-geçer kurallara tabidir  Yazılımın karmaşıklığını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  Yazılım mühendisinin arayüzleri bu yapılarla uyum içinde çalışmalıdır  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. 21

22 Uyumluluk II  Pek çok durumda software 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 22

23 Değişebilirlik I  Diğer mühendisliklerin ürünleri ya çok seyrek değişir ya da asli özellikleri aynı kalarak bir sonraki modelle yer değiştirir  Yazılımlarda ise genel kanının aksine başarılı olanlar değişir  Yeni iş süreçleri ve kuralları  Yeni kanun ve düzenlemeler  Yeni tür kullanıcılar  Yeni entegrasyon noktaları  Yeni istemciler  Yeni teknoloji  Yeni veriler  Her türlü iyileştirme 23

24 Değişebilirlik II  Kısaca yazılım ürünü, uygulamalar, kullanıcılar, kurallar ve makina araçlarının kültürel matrisinde gömülü olarak bulunmaktadır  Bunlar sürekli değiştiğinden, onlardaki değişimler ister istemez yazılım ürününü de değişmeye zorlayacaktır 24

25 Görülemezlik I  Yazılım görülemez ve gözde canlandırılamaz  Çünkü yazılım doğal olarak mekanla ilişkili değildir  Pek çok şeyin bir çeşit geometrik bir soyutlaması vardır, şemalar, çizimler vs.  Yazılımı betimelemek amacıyla veri akışı vs. değişik diyagramlar yapılmaktadır ama bunlar da çok karmaşıktır, zaten yazılım tamamen görülebilir kılmazlar, tahayüül yeteneğimize hitap ederler 25

26 Görülemezlik II  Dolayısıyla yazılım tabi olarak görülür yapılamaz  Bu durum da zihnimizin en güçlü taraflaırnı kullanmasını engeller  Ve hem zihinde bir tasarım yapılabilmesini hem de iletişimi zorlaştırır 26

27 Geçmiş Sihirli Değnekler  Yüksek seviyeli diller:  It frees a program from much of its accidental complexity  To the extent that the high-level language embodies the constructs one wants in the abstract program and avoids all lower ones, it eliminates a whole level of complexity that was never inherent in the program at all  Birleşik programlama ortamları (IDEs)  They attack the accidental difficulties that result from using individual programs together, by providing integrated libraries, unified file formats, and pipes and filters.  Zaman paylaşım (Time-sharing) 27

28 Sihirli Değnek Ümitleri  Ada ve yüksek seviyeli diller  Nesne-merkezli programlama An order-of-magnitude gain can be made by object-oriented programming only if the unnecessary type-specification underbrush still in our programming language is itself nine- tenths of the work involved in designing a program product.  Yapay zeka  Expert sistemler  Grafik programlama 28

29 Asli Zorluklara Hucüm Etmek  Yazmak yerine satın almak  Yazılım ihtiyaçları yönetimi, prototip yapma ve artımlı geliştirme  Süper tasarımcılar 29

30 Yazmak Yerine Satın Almak The most radical possible solution for constructing software is not to construct it at all.... Any such product is cheaper to buy than to build afresh.... The key issue, of course, is applicability. 30

31 İhtiyaç Yönetimi I The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. 31

32 İhtiyaç Yönetimi II Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product. 32

33 Prototip Yapma  Therefore, one of the most promising of the current technological efforts, and one that attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements. Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for it construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. 33

34 Artımlı Geliştirme I Incremental development -- grow, don't build, software... I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process.... If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach. 34

35 Artımlı Geliştirme II Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there. 35

36 Süper Tasarımcılar I Good managers, scarce though they be, are no scarcer than good designers. Great designers and great managers are both very rare. Most organizations spend considerable effort in finding and cultivating the management prospects; I know of none that spends equal effort in finding and developing the great designers upon whom the technical excellence of the products will ultimately depend. 36

37 Süper Tasarımcılar II My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded. Not only salary, but the perquisites of recognition--office size, furnishings, personal technical equipment, travel funds, staff support--must be fully equivalent. 37

38 38 Sorular ve Halimizin Pür Meali Sorular ve Halimizin Pür Meali Silver Bullet – Sihirli Değnek 20+ Yıl ve Silver Bullet 20+ Yıl ve Silver Bullet Silver Bullet ve Türkiye

39 20+ Yılda Ne Değişti?  Makalenin yayınlanmasından bu yana geçen 20+ yılda iş ve yazılım dünyasındaki gelişmeler, yazılımın  Karmaşıklığını arttırdı mı yoksa azalttı mı?  Daha mı çok uyumlu olmasına sebep oldu  Daha mı çok değişebilir olmasını gerektirdi?  Daha mı görülemez kıldı?  Peki yazılımcılar bunlara karşı neler yaptılar? 39

40 20+ Yılda Karmaşıklıkta Ne Değişti?  Daha hayatın içinde bir yazılım dünyası, daha karmaşık süreçler ve iş kuralları  Internet, web ve mobil teknolojiler  Çok daha büyük ebatlar,  Ölçek, performans, güvenirlik ve güvenlik vs. kalite ihtiyaçları  Çok fazla sayıda ve değişik rolde kullanıcı  Çok daha fazla sayıda dış sistemle iletişim noktası  Ağ üzerinde dağınık yapılar  Çok farklı tipte istemciler  Çok daha fazla veri ve rapor 40

41 20+ Yılda Uyumlulukta Ne Değişti?  Daha fazla kullanıcı çeşidi  Daha fazla iletişim noktası  Daha fazla kanun, yönerge, standart vs. düzenleyici  Daha fazla iletişimde bulunulan dış sistem ve dolayısıyla da iletişim noktası 41

42 20+ Yılda Değişebilirlikte Ne Değişti?  Hayatın daha içinde olmak ve iş dünyasının değişim hızının artması, yazılımların daha sık ve temelden değişmesine sebep oldu. Yani yeni  Süreçler  İş kuralları  Kullanıcılar  İş ortamları  Dış sistemler  herşey... 42

43 20+ Yılda Görülemezlikte Ne Değişti?  Yazılım hala görülemez  Fakat, yazılım varlıklarını daha rahat tahayyül eder hale geldik  Zaman geçtikçe algımız gelişiyor ve nesillerle taşınıyor  Yazılımı modelleme ve tasvir etme yapıları gelişti  UML  Tasarım şablonları 43

44 Yazılımcılar Ne Yaptılar? I  Karmaşıklığı azaltmak ve rahat değişebilmek için yazılım geliştirme şeklimizi değiştirdik, yeni metodolojiler geliştirdik  Yazılım geliştirme artık:  Kullanım şekilleri tarafından sürülüyor – İhtiyaç yönetimi  Mimari-odaklı – Sistem kalite ölçütleri, tekrar kullanım, iletişim kolaylığı  Yinelemeli ve artımlı olarak yapılıyor– Prototipler yapma, big bang yerine büyüyen yazılım, müşteri ile daha fazla iletişim ve ona ne istediğini bulma imkanı ve hazım kolaylığı, hızlı geri dönüş ve zamanında müdahele 44

45 Yazılımcılar Ne Yaptılar? II  Nesne-merkezli diller – Gerçekliği daha iyi resmetme  Arayüz tabanlı (interface-based) tasarım ve programlama  Tasarım şablonları – Başarılı çözümler, iletişim kolaylığı  Mimariler – Başarılı ve ortak çözümler, tekrar kullanım, ürün aileleri  Platformlar – Java ve.NET – Ortak mimari  Bileşenler (components) ve çerçeveler (frameworks) – Tekrar kullanım, başarılı çözümler  Modeller ve UML – İletişim kolaylığı, anlama gücü artışı 45

46 Yazılımcılar Ne Yaptılar? III  Uyumluluk problemlerini azaltmak için  Standartlar  XML, Web Services ve SOA  Platformlar – Java ve.NET  Daha görülebilir yazılımlar için  Görsel modeller  UML  Belgeleme yaklaşımları ve standartları  Ortak dil  Tasarım şablonları, Java ve.NET platformları 46

47 Yoksa?  Yoksa tüm bunlar karmaşıklığı daha da mı arttırdılar? 47

48 48 Sorular ve Halimizin Pür Meali Sorular ve Halimizin Pür Meali Silver Bullet – Sihirli Değnek 20+ Yıl ve Silver Bullet 20+ Yıl ve Silver Bullet Silver Bullet ve Türkiye

49  Silver Bullet ve yazılımın asli özellikleri açısından Türkiye’deki yazılım kültürü hangi durumdadır?  Üniversiteler  Yazılım evleri  Şirketlerin BT birimleri  Resmi kurumlar  Çalışanlar, yazılım emekçileri  Müşteriler 49

50 Ülkemizde Yazılım Mühendisliği I  Yazılımın asli zorluklarından ve sonuçlarından habersiz olma  Karmaşıklığın yeterince algılanmaması  İndirgemeci yaklaşım- Yazılımı programa indirgeme  Gerek dikey gerek ise yatay boyutlarda çok kaba bir kaç soyutlama ile yetinilmesi: analiz, programlama, test ve pm gibi  Formal ihtiyaç analizi bilgi ve yetkinlik eksikliği  Mimariye önem vermemek  Yeterince test yapmamak, testi sadece fonksiyonel testten ibaret görmek  Aşırı dokümentasyon eksikliği Okumayan toplumun yazmaması, dolayısıyla bilginin gizli kalması  Proje yönetim zaafiyetleri 50

51 Ülkemizde Yazılım Mühendisliği II  Sistemli düşünmeme ya da hiç düşünmeme  Aşırı hedef odaklı olma  Kısa vade ile uzun vade arasına sıkışıp kalma  Aşırı çevik yöntemler  Sistem ve formalizm eksikliği  Planlama ve risk yönetimi eksikliği, yönetim zaafiyetleri  İş bölümü ve uzmanlaşmaya önem verilmemesi  Herkesin herşeyi yapması  Dolayısıyla sağlıklı soyutlamaların yapamamak ve ilgi alanlarını ayıramamak (separation of concerns) 51

52 Ülkemizde Yazılım Mühendisliği III  İş ve IT birimleri arasındaki uyumsuzluk  Liderlik eksikliği  Sıkıntılı projelerde stresi yönetmek/azaltmak ve empatik yaklaşmak  Problemleri hızlıca kişiselleştirme zaafiyeti  Problemlere ve süreçlere odaklanmak yerine kişilere odaklanmak 52

53 Dinlediğiniz için teşekkür ederim. Bu sunuma adresinden ulaşabilirsiniz.www.javaturk.org Geri dönüşleriniz için şimdiden müteşekkirim. Sorular? Dinlediğiniz için teşekkür ederim. Bu sunuma adresinden ulaşabilirsiniz.www.javaturk.org Geri dönüşleriniz için şimdiden müteşekkirim. Sorular? 53


"Akın Kaldıroğlu 19 Ocak 2010 Akın Kaldıroğlu 19 Ocak 2010." indir ppt

Benzer bir sunumlar


Google Reklamları