Arayüzler (Interfaces)

Java’da arayüz soyut sınıf yerine kullanılır, ama soyut sınıftan farklı ve daha kullanışlıdır. Arayüz kullanarak, bir sınıfın neler yapacağını belirlerken, onları nasıl yapacağını gizleyebiliriz. Arayüzün yapısı sınıfın yapısına benzese de aralarında önemli farklar vardır.

  • Arayüz ,interfaceanahtar sözcüğü ile tanımlanır. Arayüz abstract(soyut) metotlar içerir.
  • Arayüz, anlık (instance) değişkenler içeremez. Ancak, belirtkeleri konmamış olsa bile, arayüz içindeki  değişkenler final ve staticolur. Bu demektir ki, arayüzde tanımlanan değişkenler, onu çağıran sınıflar tarafından değiştirilemez.
  • Arayüz, yalnızca publicve ön-tanımlı (dafault) erişim belirtkesi alabilir, başka erişim belirtkesi alamaz.
  • publicdamgalı arayüzpublicdamgalı class gibidir. Her kod ona erişebilir. 
  • Erişim damgasız arayüz, erişim damgasız class gibidir. Bu durumda, arayüze, ait olduğu paket içindeki bütün kodlar ona erişebilir. Paket dışındaki kodlar erişemez.
  • Arayüzpublicerişim belirtkesi ile nitelenmişse, içindeki bütün metotlar ve değişkenler otomatik olarak publicnitelemesine sahip olur.
  • Bir sınıf birden çok arayüze çağırabilir (implement).
  • Aynı arayüzü birden çok sınıf çağırabilir.
  • Sınıftaki metotlar tam olarak tanımlıdır, ama arayüzde metotların gövdeleri yoktur. Onlar abstract metotlardır. Metodun tipi, adı, parametreleri vardır, ama gövde tanımı yoktur; yani yaptığı iş belirli değildir. Metotların gövdesi, o arayüzü çağıran sınıf içinde yapılır. Böylece bir metot, farklı sınıflarda farklı tanımlanabilir. Bu özelik, Java’da polymorphismi olanaklı kılan önemli bir niteliktir.

Arayüz’ün yapısı

Erişim-belirtkesi ya public olur ya da hiç konmaz, o zaman default erişim etkin olur.

Şimdi Java dilinde yazılmış bir arayüzü inceleyelim.

 
[crayon-5c3f3a0e52e01940853312/]
Yukarıdaki örnekte örneğin bir insan’ın sofor olabilmesi için araba kullanması gerektiği anlatılmıştır. Bunun kullanımı aşağıdaki şekilde olabilir:
[crayon-5c3f3a0e52e1c460477191/]
Örnekte bulunan taksici sınıfı (class) insan sınıfını miras almış aynı zamanda sofor arayüzünün kurallarına uyduğunu belirtmiştir. Buna göre sofor sınıfında bulunan soyut (abstractmetodu barındırmak zorundadır.

Bu özellik JAVA dilinde birden fazla sınıfın miras alınamamasına (multiple inheritance) bir çözüm olarak da kullanılabilir.

Örneğin yeni tanımlayacağımız bir sınıfın hem Thread hem de Applet sınıflarından miras almasını isteyelim (yani hem thread hem de applet olmasını istiyoruz). Bu durumda tek bir sınıfı inherit edebileceğimiz için diğerini implements etmemiz gerekir.
[crayon-5c3f3a0e52e2c245454475/]
Örnek kodda Runnable arayüzü kullanan örnek bir deneme sınıfı verilmiştir. Bu sınıfın uyması gereken kural bir run fonksiyonunun bulunmasıdır.  Bu sınıfın bir thread olarak kullanılması için aşağıdaki şekilde bir sınıf tanımına nesneyi parametre geçirmek gerekir:

Thread denemeThread = new Thread(deneme);

Yukarıdaki satırda olan denemeThread isminde yeni bir thread nesnesi tanımlamak ve bu nesneyi deneme sınıfından türetmektir. Bunun olabilmesi için deneme sınıfının Runnable arayüzünü implement etmesi gerekir. Aksi halde thread olarak oluşturulamaz.

Dolayısıyla her ne kadar JAVA da doğrudan çoklu miras (multiple inheritance) yok denilse de bu sorunu çözmek için arayüz kullanımı mümkündür.

Kullanacağımız erişim belirteçleri public, static ve final tipindedir ve de ilk değer ataması zorunludur, tanımladığımız değişkenler daha çok diğer sınıflarda sabit olarak kullanacağımız değişkenlerdir.

Not: Arayüzler direk iş yapamayacaklarından, implement edildikleri sınıflarda override edilmelidirler.

Bir örneği daha inceleyelim.
[crayon-5c3f3a0e52e3b776776531/]
Çıktı:

Bu örneğimizde 3 adet İnterface tanımladık. Hayvan ve Surungen iç içe olarak, Canli ise tek olarak içlerinde gövdesiz metodlar tanımladık,sonrasında kalıtım ile yeni sınıflar oluşturduk ve metodlarımızı override ederek çağırdık. Mainimiz de yeni nesneler oluşturarak metodlarımızı çağırdık.

Implements

Arayüz tanımlamayı öğrendik. Sınıfların kalıtım işleminde kullandığımız extends anahtar kelimeyi hatırlayın. Ancak arayüzleri kalıtım alırken kullanılacak anahtar kelimesi implements’dir. Arayüzlerin varoluş amacı çoklu kalıtımı sağlamaktır. Dolayısıyla kalıtım için extends ,çoklu kalıtım için ise implements anahtar kelimesi kullanılır.

 

 

 

Arkadaşlar sizlere Arayüzleri anlattım bu kez. Başka konularda görüşmek üzere :))

Pdf olarak paylaşacağım buradan ulaşabilirsiniz.

JAVA-Arayüzler




Yılan Oyunu

Yılan Oyunu Hakkında:

  • Sağa gitmek için sağ tuşu ve D harfi kullanılır.
  • Sola gitmek için sol tuşu ve A harfi kullanılır.
  • Yukarı gitmek için yukarı tuşu ve W harfi kullanılır.
  • Aşağı inmek için aşağı tuşu ve S harfi kullanılır.
  • Yılan yemi her yediğinde yeni yem gelir ve  yılan büyür.
  • Yılan kendini yediğinde ve duvarlara çarptığında ölür.
  • Oyun boyunca yapılan en yüksek skor gösterilir.
  • Yandığımızda yeni oyun dersek skor sıfırlanır ve yılan ilk haline geri gelir.
  • Yılan öldüğünde ekrana “Kaybettiniz !” mesajı gelir.                                                         Yilan Oyununu Githup Bağlantısı



Konfigürasyon Yönetimi

Konfigürasyon Yönetiminin Tanımı

Konfigürasyon:

• Mevcut olan veya tasarlanan bir ürünün, teknik dokümanlarda tanımlanan ve daha sonra ulaşılması amaçlanan fonksiyonel ve fiziksel karakteristiğidir.

Konfigürasyon Yönetimi :

• Ürün veya sistemin ömür devri (yaşam döngüsü) boyunca hem fiziksel hem de fonksiyonel konfigürasyonunun izlenmesi ve kontrol edilmesi sürecidir.

Şekil 1. Konfigürasyon Yönetimi

Konfigürasyon yönetiminin öncelikli hedefi;

Müşteriye teslim edilen ürünün sözleşmede belirtilen çizim ve şartnamelerdeki fonksiyonel ve fiziksel özelliklere sahip olduğunu garanti etmek, Fiziksel konfigürasyonu ürünün tekrar üretilmesine imkan sağlayacak, Beklenmedik operasyon, tamir-bakım ve değiştirme ihtiyaçlarını karşılayabilecek bir detaya kadar dokümante edildiğinden emin olmaktır.

Konfigürasyon Yönetimini Süreçleri

Şekil 2. Süreçler

Müşteri isteklerinin belirlenmesi, Ürün yapısı ve konfigürasyon birimlerinin belirlenmesi, Konfigürasyon birimlerinin dokümante edilmesi, Konfigürasyon birimlerinin numaralandırılması, Konfigürasyon anahatlarının oluşturulması faaliyetlerini kapsamaktadır.

Konfigürasyon Dokümantasyonu: konfigürasyona tabi parçaların fonksiyonel ve fiziksel karakteristiklerini tam olarak tanımlamak için ihtiyaç duyulan, resmi olarak onaylanmış ve dağıtımı yapılmış teknik dokümanları içermektedir. Bu dokümanlar; ürün, proses ve malzeme şartnameleri, teknik resimler, ilgili parça listeleri, akış şemaları ve teknik el kitaplarıdır.

Konfigürasyon anahat dokümanlarının oluşturulmasından sonra konfigürasyona tabi parçaya ilişkin değişikliklerin teklif edilmesi, değerlendirilmesi, koordinasyonu ve onaylanması için gerçekleştirilen sistematik işlemler bütünüdür. Konfigürasyon Kontrol Kurulu (Configuration Control Board) kurulur. Konfigürasyon değişiklikleri mühendislik değişiklikleri, sapma ve feragatler olmak üzere üçe ayrılmaktadır. Mühendislik Değişiklik Teklifi Formu- MDT Formu ile yapılır.

Sınıf-I ve Sınıf-II olmak üzere ikiye ayrılan mühendislik değişiklikleri, konfigürasyona tabi parçanın veya anahat dokümanının, oluşturulduktan sonra değiştirilmesidir Sınıf-I değişiklikler, ürünün şekil, uyum ve işlevinde değişikliğe yol açan ve değiştirilebilirlik ile lojistik desteği etkileyen değişikliklerdir. Sınıf-II değişiklikler, Sözleşmeyi ve spesifikasyonları etkilemeyen ve Sınıf-I kapsamına girmeyen değişikliklerdir.

Şekil 3. Mühendislik Değişiklik Teklifi Formu

Konfigürasyon Değişiklik Kontrolü

Sapma (Deviation): Sapma, konfigürasyona tabi parçanın üretimden önce, spesifikasyonlarda belirlenmiş olan performans veya tasarım isteklerinden, çizimlerden veya diğer dokümanlardan farklılığına belli sayıda veya belli bir süre için verilen izindir. Sapma ve mühendislik değişiklikleri arasındaki en temel fark; onaylanmış bir mühendislik değişikliğinin, ilgili birimi tanımlayan dokümanlarda revizyonu gerekli kılması; sapmaların, mevcut şartname veya çizimlerde herhangi bir değişikliğe neden olmaması ve anahat dokümanlarını etkilememesidir. Sapma/Feragat İstek Formu (Request for Deviation/Waiver – RFD/RFW) kullanılır.

Feragat (Waiver): Feragat, bir konfigürasyon biriminin üretimi veya muayeneye sunulması sırasında belirlenmiş isteklerden ayrıldığının ve olduğu gibi kullan veya yeniden işle kararlarının verilmesine uygun olmadığının tespit edilmesi halinde, konfigürasyona tabi parçanın belirli bir miktarı için bu şekliyle kabul edildiğini belirten yazılı izindir. Feragatler, anahat dokümanlarını etkilemeyen değişikliklerdir. Feragat ve sapma arasındaki temel fark; sapmanın değişikliğe oluşmadan önce, feragatin ise oluştuktan sonra izin vermesidir. Bir konfigürasyon birimine aynı konuda ikiden fazla sapma ve feragat gerekiyorsa, bu durumda mühendislik değişikliği daha uygundur.

Konfigürasyon Durum Değerlendirmesi

Şekil 4. Konfigürasyon Durum Değerlendirmesi

Konfigürasyon durum değerlendirmesi için bilgi yönetim sistemlerinden yararlanılmalı ve bir veritabanı oluşturulmalıdır. Dokümanların onaylanarak yayınlanmasından itibaren tüm tarihsel bilgi ve değişiklik kayıtları tutulmalı ve değişikliklerin izlenebilirliği sağlanmalıdır. Konfigürasyon listesindeki değişiklikler için konfigürasyon veritabanı güncellenir ve gerektiğinde çıktı alınarak konfigürasyon durumu raporlanır.

Konfigürasyon Denetimi

Konfigürasyona tabi parçanın, konfigürasyon yönetim personeli tarafından ilgili konfigürasyon dokümanlarına uygunluk bakımından resmi olarak kontrol edilmesi, Hem ürün çizim ve şartnamelerinin talep edilene uygunluğunun ve üretim işlemlerinin bu dokümanlara göre devam edeceğinin teyit edilmesi, Üretilen ürünün istenilen performans değerlerini sağladığının kanıtlanması anlamına gelmektedir.

Konfigürasyon denetimleri, fonksiyonel konfigürasyon denetimi ve fiziksel konfigürasyon denetimi olmak üzere iki çeşittir. Fonksiyonel konfigürasyon denetimi, konfigürasyona tabi parçanın kabulünden önce, konfigürasyon dokümantasyonunda belirtilmiş olan fonksiyonel ve performans özelliklerine ulaşıldığının kontrolü ve doğrulanması amacıyla, test verilerinin ve kayıtlarının incelenmesidir Bu denetim seri üretim için onay verilecek konfigürasyonu temsil eden prototip üzerinde, prototipin olmadığı durumlarda ise üretilen ilk parça üzerinde yapılmalıdır.

Fiziksel konfigürasyon denetimi, imal edilmiş konfigürasyona tabi bir parçanın imalat konfigürasyonunun, tasarım dokümanlarına göre uygunluğunun denetlenmesidir. Fonksiyonel konfigürasyon denetiminin başarıyla tamamlanmasının ardından üretimin ilk parçası üzerinde uygulanan bu denetim, ürünle ilgili teknik resim, şartname, test gereksinimleri ve diğer teknik veriler ile tasarım dokümanları, el kitabı ve listelerin detaylı denetimini içermektedir. Prototip kafile üretimi sırasında üretim dokümanlarında yer alan muayene ve test gereksinimlerinin konfigürasyon dokümanlarına uygunluğunun değerlendirilmesi ve seri üretim sırasında bu üretim dokümanlarının kullanılacağından emin olunmasının sağlanmasıdır.

Konfigürasyon Yönetim Planı

Konfigürasyon yönetim politikası ve hedefleri, Konfigürasyon yönetim organizasyonu, sorumluluk ve yetkileri, Konfigürasyon yönetim kaynakları ve bu kaynakların nasıl elde edileceği, Konfigürasyon kontrol yöntemi, Konfigürasyon denetimlerinin nasıl ve ne zaman yapılacağı, Konfigürasyon durum değerlendirmesinin nasıl ve ne zaman yapılacağı, Konfigürasyon yönetiminin müşteri ve alt yükleniciler ile nasıl koordine edileceği.

Şekil 5. Konfigürasyon Yönetim Planı

Konfigürasyon Yönetim Organizasyonu

Şekil 6. Konfigürasyon Yönetim Organizasyonu

Referanslar

* MIL-HDBK-61B DoD Military Handbook Configuration Management Guidance, 2001.

* MIL-STD-3046 Department of Defense Interim Standard Practice Configuration Management, 2013.

* MSB.lığı SATEM K.lığı, Konfigürasyon Yönetimi Seminer Notları, Ankara.

* EIA Standard – 649, National Consensus Standard for Configuration Management, U.S.A., 1998.

* Ünal Hande, “Konfigürasyon Yönetimi ve Savunma Sanayiinde Uygulaması”, Gazi Üniversitesi Fen Bilimleri Enstitüsü, Ankara, 2005, (Yayımlanmamış Yüksek Lisans Tezi).

*https://www.slideshare.net/akdenizli33/konfigrasyon-ynetimi-sunumu

 

 




Yazılım Nitelik Güvencesi

1.YAZILIM NİTELİK GÜVENCESİ (SOFTWARE QUALITY ASSURANCE)

Bilgisayar tabanlı sistemlerin düzgün çalışması, insanların isteklerini en iyi şekilde karşılamak için uygun niteliğe sahip olmaları gerekir. Nitelik kelimesiyle anlatmak istediğimiz bir ürün veya hizmetin belirlenen istekleri karşılayabilme yeteneğine yönelik özelliklerin tümüdür.

1.Yazılım Niteliği (Software Quality)

Yazılım mühendisliğinin temel amacı yüksek nitelikli yazılım üretmektir. Bunun için yazılımda belirli nitelikler belirleriz. Yazılım niteliği;

Kullanım amaçlarına göre işlev ve başarım gereksinimlerine uyum,

İşlev ve başarım gereçlerine uyum,

Kullanıcı isterlerine yanıt verebilme,

Yazılım geliştirme standartlarına sadık kalma,

Yüksek güvenirlilik sağlama,

Teslim sonrası destek,

İşlevselliklerle tanımlanır.

1.1 Nitelik Etmenleri (Quality Factors)

İyi bir yazılımda aranan ve ürünün kalitesini anlamamızda yardımcı olan nitelikler vardır. Nitelik etmenleri farklı ürünleri birbirleriyle kıyaslamak amacıyla 3 grup altında incelenir.

  • Kullanıma yönelik özellikler
  • Taşınmaya yönelik özellikler
  • Yenileştirmeye yönelik özellikler

Tablo 1. Nitelik Etmenleri Sınıflandırması

 

 

1.2 Nitelik Metrikleri (Quality Metrics)

Nitelik etmenlerinin ölçülmesi çoğu zaman oldukça zordur, hatta bazen de imkansızdır. Bu nedenle bazı metrikler ya da bir diğer ismiyle ölçütler tanımlanır her metrik için bir not verilir (1 ile 10 arasında) ve bu notlar yardımıyla sayışıl değerler elde edilir. Değerlendirmede dikkate alınabilecek metriklerin bir kısmı şunlardır;

  • Denetlenebilirlik
  • Doğruluk
  • Hassaslık
  • Başarım
  • Arayüzün yaygınlığı
  • Verilerin yaygınlığı
  • Bütünlük
  • Büyüklük
  • Tutarlılık
  • Hata dayanıklılığı
  • Verimlilik
  • Genişleyebilirlilik
  • Donanım bağımlılığı
  • İzlenebilirlilik
  • Modülerlik
  • Kullanım kolaylığı
  • Bakım kolaylığı
  • Belgelendirme
  • Müşteri tatmini

1.3 Nitelik Güvence Gereksinimi (Quality Assurance Requirement)

Her yazılım geliştirici grup, kurum ya da fırına niteliği artırmaya ve korumaya yönelik birtakım düzenler kurmaktadırlar. Her türlü düzenin en alt düzeyinde mühendislik işlerini yürüten bireyin nitelik anlayışı bulunmaktadır. En üst düzeyde ise, nitelikli yazılım geliştirebilmek üzere standartları koyan, yöntemleri belirleyen ve bunların uygulanmasını sağlayan yazılım nitelik güvence ekibi bulunur. Yazılım geliştiren grup veya firmalar bu düzeyler arasında herhangi bir yerde bulunabilirler.

Genel yönetim işlevlerinin nitelik politikası belirleyen ve uygulayan bölümüne Nitelik Yönetimi denir. Nitelik yönetimi uygulaması için geliştiricinin yeterli nedeni olması gereklidir.

Nitelik güvence etkinliklerinin olumlu yanları;

Geliştirilen yazılımın sonradan ortaya çıkan kusurları azaltılmış olur

Test ve bakım aşamalarında daha az işgücü gerekir
Yüksek güvenilirlik müşteri memnuniyetini arttırır
Bakım maliyeti düşer
Yazılımın tüm yaşam çevrimi maliyeti düşer
Çalışanlar arasında kurulan iş disiplini sayesinde verimlilik artar.

Nitelik güvence etkinliklerinin olumsuz yanları;

Küçük örgütlenmelerde ayrı bir ekip oluşturmak güçtür. Çünkü asıl geliştirme etkinlikleri için ayrılacak özkaynaklar dahi kısıtlıdır.

Alışık olmayan kurum ya da firmalar için köklü değişiklikler gerekir.

Belirli bir düzene uyum sağlama kültürel bir sorun olabilir.

Yazılım geliştirme etkinlikleri dışında önemli bir bütçe ayrılması gereklidir.

1.4 Nitelik Güvence Etkinlikleri (Quality Assurance Activities)

Yazılım mühendisliği yöntembilimleri;

Yazılım mühendisliği çözümleme, tasarım, gerçekleştirim ve test için kullanılan yöntemlerin ve araçların tanımlandığı belirli geliştirme yöntemlerini ve standartları uygulayan bir yöntembilime göre yürütülür.

Standartlar ve yöntemler;

Yazılım nitelik güvencesi, çözümleyici ve tasarımcının işini daha iyi yapabilmesine yardımcı olan bir dizi kurallardan oluşan teknik yöntemlerle yapılır. Bu iş için çeşitli araçlarda kullanılabilir. Nitelik güvence, çeşitli standartları olan bu yöntem ve araçların tanımlanması ve kullanımının kabul edilmesiyle başlar.

Nitelik güvence denetimi;

Nitelik güvence denetimi nitelikle ilgili etkinliklerin ve sonuçlarının. planlanan düzenlemelere uyup uymadığının, bu düzenlemelerin etkili olarak uygulanıp uygulanmadığının ve amaca ulaşmak için uygun olup olamadığının sistematik ve tarafsız olarak incelenmesidir.

Resmi teknik gözden geçirmeler;

Resmi teknik gözden geçirmeler, her aşamada ortaya çıkan her ürün için uygulanan bir inceleme yöntemidir. Çözümleme ve tasarımın nitelikli bir şekilde yapıldığının denetlenmesi için teknik personel ile belirli kurallara bağlı olarak toplantılar yapılır. Bu gözden geçirme toplantıları yazılımın testten geçirilmesi gibidir; hatta, olası hataların önceden bulunup giderilmesini sağladığı için daha da etkindir.

Yazılım düzenleşim yönetimi;

Yazılımın herhangi bir geliştirme aşamasında ya da kullanımı sırasındaki bakım aşamasında isterlerde çeşitli değişiklikler yapılması olağandır. Fakat denetim altında yapılmayan her değişiklik, aslında, yeni bir kusura neden olması veya yan etkiler yaratması açısından potansiyel birer tehlikedir. Yazılım niteliğini düşürecek bu tehlikeyi en aza indirgemenin tek yolu da düzenleşim yönetiminin bir parçası olan değişiklik denetim sürecinin uygulanmasıdır.

Ölçme;

Ürün niteliği ile ilgili temel veriler genellikle kullanıcı ile beraber çalışan geliştirme, test, destek, hizmet ve satış birimlerinde toplanır ve değerlendirilir. Yazılım niteliğini ölçmek, harcanan özkaynakları saptayabilmek ve daha iyi planlama yapabilmek için yazılım metrikleri kullanılır. Nitelik güvence etkinliklerinden biri olan yazılım metrikleri önceden belirlenir, toplanır, değerlendirilir ve somut sonuçlar elde edilerek daha sonraki geliştirme etkinliklerinde kullanılır. Teknik gözden geçirmeler, denetimler, değişiklik denetimi, testler ve diğer nitelik güvence etkinliklerinin kayıt altında tutulması ile projenin bir tarihçesi oluşturulur. Gerektiğinde bu tarihçe hem hata gidermede bir başvuru kaynağı olarak kullanılabilir, hem de diğer projeler için örnek oluşturur. Geliştirici personel bu teknik ve nitelik güvence kayıtlarını inceleyerek daha nitelikli yazılım üretir.

Test;

Yazılımın bir ürün haline gelip kusurlarından arındırılması için önceden tasarlanmış test yordamlarıyla bir dizi test yapılır. Dikkatli bir şekilde ve belirli yöntemlere göre yapılan testler hataların ayıklanması için önemli bir aşama olur. Ancak, nitelik güvence denetimi altında yapılmayan testler yalnızca deneme-yanılma taktiği ile, ya zaman elverdiği sürece yapılır ya da yeteri kadar kusursuz yazılım üretilinceye kadar devam ettirilir. Her iki durumda da aşırı maliyet artışı söz konusudur.

Belgelendirme;

Yapılan her işin ve etkinliğin seçilmiş olan yöntembilimin gerektirdiği şekilde belgelendirilmesi, hem yapılanların kayıt altına alınması hem de daha sonraki geliştirme ve değişiklik işlerinde kolaylık sağlaması nedeniyle nitelik güvence etkinliklerinin tanımında kullanılır.

1.6 Nitelik Güvence Yönetimi (Quality Assurance Management)

Her projede mutlaka belirli bir nitelik güvence yönetimi bulunmalıdır. Bir yazılım geliştirme kurumu ya da firması yazılım nitelik güvence etkinliklerini yerine getirmeni karar verdiyse belirli standartlar seçilerek kullanılmalı ve bir yazılım nitelik güvence planı (software Quality assurance plan) hazırlanmalıdır. Bu plan için IEEE  730 standardı kullanılabilir.

Yazılım nitelik güvence planı geliştirme etkinlikleri boyunca nitelik yönetimine ait ne tür işlerin yapılacağını hangi standartların kullanılacağını gözden geçirme ve denetimlerin ne şekilde yapılacağını belirleyen ve diğer destek etkinliklerini tanımlayan bir yol haritası gibidir.

Nitelik güvence yöneticisi bulunmalıdır. Bu yöneticinin sorumlulukları maddeler halinde sıralanırsa;

Proje yönetimine yardımcı olmak üzere kendi sorumluluk alanıyla ilgili bir plan (Nitelik Güvence Planı) hazırlamak ve proje yönetimine onaylatmak,
Nitelik Güvence Planı kapsamında düzenli aralıklarla proje etkinliklerini değerlendirmek, ortaya çıkan hataları derlemek, düzeltici işlem talebinde bulunmak ve takibini yapmak; bu kapsamda durum raporları hazırlamak ve yönetimin dikkatine sunmak,

Proje uygulamalarını standartlar ve sözleşme isterleri doğrultusunda denetlenmesiyle ilgili etkinliklerin yürütülmesinde proje yönetimine yardımcı olmak,

1.Kendi sorumluluk alanıyla ilgili olarak yönetime yardımcı olabilecek tüm bilgileri derleyip toplamak.

2.Yönetimin dikkatine sunmak, proje yönetimi ile ilgili toplantılara katılmak, gözden geçirmeleri yapmak
3.Belgelendirme çalışmaları sonunda ortaya çıkan belgeleri onaylamak ya da geri çevirmek

4. Belgelerde içerik denetimi yapmak, içeriğin şablonlara uygunluğunu denetlemek

5.Yazılım geliştirmede kullanılan gereçlerin seçilmiş olan standartlara uygunluğunu denetlemek

6.Yazılım geliştirme süreciyle ilgili her türlü planlamayı onaylamak

7.Geliştirilen her ürünün kayıt altında olduğunu denetlemek, belgelerin ve kaynak kodların tahsisli yerlerinde olduğunu denetlemek, eksiklikleri uyarmak ve tedbir alınmasını sağlamak

8.Uygulama alanı ile ilgili standartları ve yenilikleri takip etmek

1.7 Toplam Nitelik Yönetimi (Total Quality Management)

Toplam Nitelik Yönetimi, yürütülen bir işin bütününde etkinliğin, esnekliğin. iyileştirici ve rekabeti artırıcı düzenlemelerin tümüne verilen addır. Örgütlenmenin her düzeyinde ve çalışan herkesi kapsar. Gerçekten etkin bir örgüt içinde tüm bölümler birlikte çalışırlar; her birey diğerini etkiler ve kendisi de etkilenir. Nitelik tanımlaması işletme içinde yukarıdan aşağıya doğru tanımlanır.

Niteliği sağlamada başarı yatay örgüt yapısındadır. Örgüt içindeki bir bölümün başarısızlığına neden olabilecek yanlış ürün üretilmesini ya da geliştirilmesini diğer bölüm önlemeye çalışır. Toplam Nitelik Yönetimi uygulayarak fırına ya da kurumlar asıl hedeflere odaklanırlar, yüksek başarım elde ederler, sorunları daha kısa sürede çözerler, ürün niteliğini giderek artırırlar. Tabii ki, bunun için niteliği anlamak, inanmak, belirli bir politika ortaya koymak, iyi örgütlenmek, iyi planlama ve ölçüm yapabilmek, denetimi sağlamak gerekmektedir.

1.8 Örgütleme Ve Nitelik (Organizing and Quality)

Örgütlenmelerin olgunlaştırılması için yazılım ve süreç arasındaki ilişkinin bilinmesi ve uygulanması gereklidir. Süreç (process), belirli bir işi yapmakta izlenen yordamdır. Genellikle, altsüreçlerden, onlar da adım ve işlemlerden oluşur.

Sürecin amacı belirli bir standart oturtmak, değişkenliği azaltmak ve iyileştirmeye olanak sağlamaktır. Süreç yazılı halde bulunur, tekrarlanabilir şekilde tanımlanmıştır. Girdileri ve çıktıları vardır.

Örneğin;

İsterler çözümlemesi süreci.

2.NİTELİK SİSTEM STANDARTLARI (QUALITY SYSTEM STANDARDS)

Standart oluşturan kuruluşlar;

Amerikan Ulusal Standartlaştırma Enstitüsü (American National Standardization Institute -ANSI)

  1. BSI(ingiltere)
  2. AFNOR(fransa)
  3. Amerika Birleşik Devletleri Savunma Bakanlığı (Department Of Defense-DOD)
  4. NATO
  5. Uluslararası Standartlaştırma Ofisi(ınternational Standardization Office-ISO)
  6. Elektrik Ve Elektronik Mühendisleri Enstitüsü(ınstitute Of Electrical And Electronics Engineers-IEEE)
  7. Yazılım Mühendisliği Enstitüsü (Software Engineering Institute-SEI)

Standart oluşturan kuruluşlar birbirleri ile sürekli ilişki içerisinde olup ortak standart üretmektedirler. Ortak çalışmalar sonucu uluslararası kabule sahip nitelik yönetim sistemi standartları oluşmuştur:

  1. Watts Humphrey ve Yetenek olgunluk Modeli (CMM)
  2. ISO-9000 Nitelik Yönetimi ve Nitelik Güvence Standartları Seçim ve Kullanım Rehberi
  3. ISO 9001 Nitelik Sistemleri Tasarım, Geliştirme, Üretim, Tesis ve Servis İçin Nitelik Güvence
  4. ISO 9002 Nitelik Sistemleri Üretim ve Tesis İçin Nitelik Güvence
  5. ISO 9003 Nitelik Sistemleri Son Muayene ve Testlerde Nitelik Güvence
  6. ISO 9004 Nitelik Yönetimi ve Nitelik Sistemi Öğeleri
  7. Trillium (Kanada)
  8. SPICE

2.1 CMM (Capability Maturity Model)

CMM Amerika Savunma Bakanlığının 1980’lerde ortaya çıkan yazılım krizine çözüm bulması amacıyla Carnegie Mellon Üniversitesinden yardım istemesi üzerine üniversitede kurulan SEI tarafından geliştirilmiştir. İlk CMM yazılım için geliştirilmiş ve 1990’da yayımlanmıştır.

CMM yazılım süreç iyileştirmede kullanılacak araç ve olgunluk sorguları aracılığıyla oluşturulmuş bir modeldir. Bu modelin ortaya çıkmasının nedeni yazılım sektöründeki kalite ve verimlilik sorunlarıdır. Bunlar; zaman, para, durağanlık olarak sayılabilir. Tüm bu sorunlar için yazılım sürecinin olgunluğu hakkında karar vermek ve endüstrideki pratiklerle karşılaştırmak amacıyla çeşitli ölçüm araçları ortaya atılmıştır.

CMM asıl olarak olgun olmayan bir süreçten olgun ve disiplinli bir sürece giden evrimsel bir yol çizer. Olgun bir yazılım örgütlenmesine giden aşamaları öncelik sırasıyla veren bir modeldir.

CMM nin yapısı;

1.Olgunluk düzeyleri (maturity levels):Süreç yeteneğini tanımlar.

2.Anahtar süreç alanları (key process area):hedefleri belirler.

3.Ortak öznitelikler (common features):gerçekleştirim ve kurumsallaşma için gerekli özelliklerdir.

4.Anahtar uygulamalar (key practices):Temel etkinliklerdir.

CMM uygulaması için sıradüzensel olarak;

Düzey belirleme,

Bir sonraki düzeye geçmeden önce eksiklikleri belirleme,

Eksiklikleri sıradüzensel sıraya dizme,

Eksikliklerin giderilmesi için plan yapma,

Planı hayata geçirmek için kaynak ayırma ve uygulama,

Döngüye yeni baştan başlama

Aşamaları uygulanır.

2.2 CMMI (CMM Integration)

Çeşitli uygulamalardan edinilen deneyimlerle, pazarlama, sistem, yazılım ve donanım temsilcilerinin bir arada çalışmalarıyla verimliliğin arttığı gözlemlenmiştir. CMM ile sağlanan başarımdan sonra, sistem mühendisliği, insanlar, tümleşik ürün geliştirme, yazılım edinme, yazılım nitelik güvence, ölçme gibi konulardaki istekler üzerine başka CMM’ler geliştirilmiştir.

Bu kadar çok çeşitli model olunca da birbirine karışmalar, örtüşmeler ve tezatlar oluşmuş, kolay anlaşılır olmayan arayüzler ve standartlar ortaya çıkmıştır. Bunlara ek olarak ISO 9001 ve ISO 9000-3 denetimlerinin kullanılması sonucunda da yüksek maliyetler ve kafa karıştırıcı uygulamalar oluşmuştur.

Karşılaşılan sorunları çözmek üzere, var olan gelecekte var olacak modelleri birleştirecek bir yapı kurmak ve başlangıç için bir tümleşik modeller seti oluşturmak amacıyla, Amerikan Savunma Bakanlığı’nın desteğiyle SEI tarafından CMM Tümleştirme (CMM Integration) Projesi başlatılmıştır.

Projenin amacı, üç kaynak modelini birleştirmekti. Bunlar:

  • Capability Maturity Model for Software (SW-CMM) v2.0
  • Electronic Industries Alliance Interim Standard (EIA/IS) 731
  • Integrated Product Development Capability Maturity Model (IPB-CMM) v0.98

CMMI sürüm-1.1 Mart 2002 yılında ortaya çıkartılmıştır.

CMMI, sürekli ve basamaklı olmak üzere iki gösterim şekli kullanmaktadır. Sürekli (continuous) CMM gösterimi yetenek düzeylerini tanımlarken basamaklı CMM gös-ı terimi olgunluk düzeylerini tanımlar. Yetenek düzeyleri, bir örgütün herbir süreç alanında süreç iyileştirmede gösterdiği başarı için uygulanır. 6 yetenek düzeyi vardır:

Eksik (incomplete)

Yerine getirilen (performed)

Yönetilen (managed)

Tanımlı (defined)

Nicel olarak yönetilen (quantitatively managed)

Eniyilenen (optimizing)

2.3 Trillium

Trillium modeli kanada iletişim sektörü tarafından geliştirilmiştir.

Yol haritası yaklaşımını getirmiştir bu yaklaşım ürün geliştirme süreci içerisinde bir örgüt alanına bir gereksinime yada bir öğeye odaklanan uygulamalar seti olarak tanımlanır. Trillium un 8 yetenek alanından oluşur.

Örgüt süreç niteliği

İnsan kaynakları geliştirme ve yönetimi

Süreç

Yönetim

Nitelik

Sistem geliştirme uygulamaları

Geliştirme ortamı

Müşteri desteği.

 

2.4 TickIT

Daha çok İngiltere ve Norveç yazılım geliştiricileri tarafından desteklenen TickIT, yazılım sektöründeki yetkili belgelendirme kuruluşları aracılığıyla nitelik yönetim sistemi belgelendirmesi yaparak;

  • Pazar güvenilirliğini artırmak.
  • Bu sektördeki nitelik yönetim sistemi denetleyicileri için profesyonel yöntemleri geliştirmek.
  • Yetkili bir kılavuz yayınlamak.

Amacıyla oluşturulmuş bir yordamlar topluluğudur.

ISO 9001 ’in karşılaştığı bir takım güçlükler nedeniyle ISO 9000-3 çıkarılmış, onun da yetersiz kalması üzerine TickIT modeli ortaya çıkarılmıştır. TickIT, değerlendirdiği nitelik sisteminde ISO 9001 standardına göre uyumsuzluk olup olmadığını araştırır.

Yazılım geliştiricilerin nitelik güvence sistemlerinin belgelendirmesi Ingiliz ve Norveç kurumları tarafından yetkilendirilmiş üçüncü parti bağımsız ve yetkili organlar tarafından yapılır. İngiltere devlet daireleri tarafından resmi olarak tanınan TickIT içinde ISO 9001, ISO 9002 ve ISO 9003 standartları kullanılmaktadır.

Değerlendirme en az iki aşamalı bir süreçtir. llkinde, örgütün nitelik sistemi, standarda (Ticle için: ISO 9001) göre değerlendirilir. İkincisinde, örgütün pratikte gerçekten kendi nitelik sistemine ve standarda uyumlu çalışıp çalışmadığı denetlenir, nitelik sisteminin etkinlik derecesine bakılır.

2.5 SPICE (Software Process Improvement and Capability dEtermination )

Yazılım Süreci  İyileştirme ve Yetenek Belirleme’dir. 1995 yılında ISO ve IEC tarafından çıkarılmıştır. Yazılım geliştirme projelerinin yönetim tarafı çoğunlukla yetersiz planlama, geliştirme süreçlerin tam anlaşılmaması, iyi bir yönetim çerçevesinin olmayışı gibi problemlerle karşı karşıyadır. Bu çerçevede daha disiplinli geliştirme süreçleri için standartlar geliştirilmeye başlanmıştır. SPICE da bu standartlardan biri olup,  yazılım süreçlerini iyileştirmek ve süreç yeteneklerini belirler.

SPICE İlkeleri;

  • Standartlaşma
  • Değerlendirme, yetenek belirleme ve iyileştirme
  • Diğer modellere uyum sağlama
  • Gelişmeyi ölçme
  • Nesnel, tutarlı ve tekrarlanabilir olma
  • Sertifikasyon amacı taşımaz

SPICE süreç boyutu ve yetenek seviyeleri olmak üzere iki boyuttan oluşur.

Süreç boyutları 5’e ayrılmaktadır. Bunlar:

  • Müşteri-satıcı süreçleri (Customer-supplier)
  • Mühendislik süreçleri (Engineering)
  • Yönetim süreçleri (Management)
  • Destek süreçleri (Support)
  • Organizasyon süreçleri (Oganization)

İkinci boyut olan yetenek düzeyleri altı adet olarak tanımlanmıştır. Bunlar;

Düzey Düzey adı Açıklama
5 Eniyileşen (optimizing) Geri beslemelerde sürekli iyileştirme vardır
4 Kestirilebilir(predictable) Denetim altındaki süreçte ayrıntılı başarım ölçümleri toplanır ve ona göre yönetilir.
3 Yerleşmiş (established) Örgütlenmede belgelendirilmiş standart süreçler ve uygulamalar vardır.
2 Yönetilen (managed) Süreç tanımlanır. İş planı uygulanır
1 Yerine getirilen(performed) Planlama yapılmadan süreçler genel olarak yerine getirilir.
0 Eksik (incomplate) Başarı sadece bireylere bağlıdır.

Tablo 2. SPICE ye ait yetenek düzeyleri

2.6 ISO 9000

Uluslararası Standartlaştırma Örgütü (International Standardization Organization -ISO) tarafından yayınlanan ISO 9000 serisi Nitelik Sistemi ve Güvencesi Standartları Özellikle Avrupa‘da büyük ilgi görmüştür.

1987 yılında ilk ISO 9000 (Ed. l ) serisi standartlar oluşturulmuştur. 1994 yılında ikinci ISO 9000 (Ed.2) serisi standartlar tamamlanmıştır.

ISO 9000 serisi standartlar çok çeşitlidir, ancak ana kaynaklar ele alındığında, yayınlanmış ve sürekli güncellenen bu nitelik sistemlerine ilişkin beş temel ISO standardı vardır.

ISO 9000

Nitelik Yönetimi ve Nitelik Güvence Standartları Seçim ve Kullanım Rehberi

ISO 9001
Nitelik Sistemleri Tasarım, Geliştirme, Üretim, Tesis ve Servis İçin Nitelik Güvence

ISO 9002

Nitelik Sistemleri Üretim ve Tesis İçin Nitelik Güvence

ISO 9003

Nitelik Sistemleri Son Muayene ve Testlerde Nitelik Güvence

ISO 9004

Nitelik Yönetimi ve Nitelik Sistemi Öğeleri

ISO 9000 Kalite Standartları Serisi, kuruluşların kaliteye önem verdiğini ve kalite ihtiyaçlarını karşılayabileceklerini müşterilerine kanıtlayacak etkin bir kalite sistemini kurulması, dökümante edilmesi ve sürekliliğinin sağlanması konusunda yol gösterir. Bu nedenle bir çok resmi veya özel kuruluş tarafından ihale şartı olarak istenmektedir.

Yazılımda nitelik için ISO 9001 öngörülebilir. Ancak bu standart bir süreç modelinden farklı olarak, dışarıya nitelik güvencesi vermeye yönelik belgelendirmeye önem verirler. Bir denetim yöntemine gereksinim duyan bu standartlar, firma düzeyi hakkında ayrıntı değil, genel bir bilgi verirler

2.7 AQAP (Allied Quality Assurance Publications) 150/160

NATO içinde müşterek uygulamaların temini için standardizasyon anlaşması (STANAG-MOS) çerçevesinde Müttefik Nitelik Güvence Yayınları (Allied Quality Assurance Publications-AQAP) 1983’ten itibaren uygulamaya alınmıştır. NATO tarafından ISO nitelik standartlarındaki son gelişmeler göz önüne alınarak savunma sistemlerinin edinilmesinde ISO 9000 serisi nitelik güvence standartlarının 1994’ten itibaren uygulanması zorunlu kılınmıştır. Daha sonra, ISO 9000 1994 sürümü dikkate alınarak 1995 Şubat’ında yeni AQAP belgelerinin kullanımına başlanmıştır.

NATO ülkelerinde askeri amaçlı ürün geliştiren firma veya kuruluşlarda AQAP-150 veya 160 belgesi aranmaktadır. Bu belgeler her devletin yetkilendirdiği organlarca verilmekte, belirli aralıklarla yenilenmektedir. Türkiye’de bu konudaki denetimleri Milli Savunma Bakanlığı yapmakta, savunma sistemleri ile ilgili ihalelere giren firmalardan bu belge istenmektedir.

2.8 Karşılaştırma

                                              Tablo 3.Nitelik sistem standartları karşılaştırılması

3. RESMİ NİTELİK GÜVENCE SİSTEMLERİ (OFFICIAL QUALITY ASSURANCE SYSTEMS)

Nitelikli bir yazılım geliştirmek her geliştiricinin sorumluluğundadır. Bu sorumluluğun belirli kurallar çerçevesinde yürütülmesi için resmi yöntemler ortaya atılmıştır. Bu yöntemlerden birkaçı şunlardır;

  • Doğruluğun kanıtlanması
  • İstatiksel yaklaşım
  • Temiz oda süreci
  • Yardımcı araç desteği

3.1 Doğruluğun Kanıtlanması

Bilgisayar bilimlerinde bir programın istenen özellikleri yerine getirip getirememesine verilen isimdir. Buna göre şayet bir program, istenen durumu tam ve eksiksiz yerine getiriyor, istenmeyen sonuçlar ortaya çıkmıyor ve program başladıktan sonra her durumda başarılı bir şekilde bitiyorsa bu programa tam doğru ( total correctness) ismi verilir.

Bazı program hataları yalnızca zarar verir, ancak bazıları yaşamı ve ekstremiteyi tehlikeye atabilir. Bir daha ki sefere, uçağın seyir sisteminde doğru program davranışının önemini düşünerek bir dakika harcayın. Üreticinin programın bir takım ampirik testlere dayanılarak doğru olduğunu “düşün” istemesini mi, yoksa kesin ve kesin bir ispatı mı tercih edersiniz?

Program doğruluğunun hem mühendislik hem de teorik sorun olarak önemini ortaya koyduğumuzda, dikkatimizi aslında onu çözmeye dönebiliriz.

Örneğin, bir programın belirli bir belirtimi doğru bir şekilde uyguladığını kontrol eden (veya kanıtlayan) genel algoritmaların bulunmadığı kanıtlanabilir. Daha basit problemler için de genel çözümler veremiyoruz.

Örneğin, rasgele bir programın belirli bir girdi için yürütmeyi durdurup durdurmayacağına karar verebilecek bir algoritma yoktur.

Yazılımın doğruluğunun matematiksel olarak kanıtlanması oldukça pahalı bir yöntemdir.Ancak, otomatik kod üreten yazılım araçlarının geliştirilmesinde bu  yaklaşımın da kullanımında yarar vardır.

3.2 İstatiksel Yaklaşım

İstatistiksel olarak toplanmış bilgilere göre niteliği artırıcı yaklaşımda şu aşamalar bulunur:

  1. Yazılım kusurları toplanır ve sınıflandırılır.
  2. Her kusur izlenerek neden kaynaklandığı bulunur ve bu bilgiler de kaydedilir.
  3. Neden olan ortak kusurlar bulunur.
  4. Bulunan kusurlar düzeltilir.

Bu yöntemin işleyebilmesi için uzun süreli, yoğun bir geliştirme yapılması ve bilgilerin eksiksiz toplanması gereklidir. Yazılım kusurlarının oluşmasına neden olan en yaygın nedenler arasında şunları sayabiliriz:

  1. Hatalı yapılmış isterler çözümlemesi ortaya çıkan hatalı belirtim
  2. İsterlerin yanlış anlaşılması
  3. Kodlama standartlarına uyulmaması
  4. Veri yapılarında hata
  5. Tutarlı olmayan modül arayüzleri Tasarımda mantık hatası
  6. Tasarımı koda geçirmede yapılan hata
  7. Kodlamada yapılmış hatalar
  8. Yetersiz yapılmış testler
  9. Hatalı veya eksik belgelendirme
  10. İnsan-makine arayüzündeki eksiklikler ve hatalar
  11. Dikkatsiz ve isteksiz çalışma

Yazılım kusurunun oluşmasına neden olan durumun belirlenmesinden sonra her bir kusura ilişkin istatiksel veriler toplanır ve bir sıraya konulur. Buradan yola çıkılarak yeni bir hata oluştuğunda çözüm için incelenecek yol konusunda bir fikir elde edilmiş olur

3.3 Temiz Oda Süreci (Clean Room Process)

Nitelikli yazılım geliştirmenin ve doğruluğunu kanıtlanmanın bir tekniği de temiz oda sürecidir (cleanroom process).Endüstride çeşitli alanlarda kullanılan bu teknikte ilke olarak geliştirme ortamının her türlü zararlı etmenden arındırıldığı kabul edilir.

Örneğin, yüksek nitelikli bir elektronik tümdevre üretim hattında havanın temizliği esastır. Bunun için ortam hataya sebebiyet verecek en küçük toz parçacıkları dahi ortamdan uzaklaştırılır.

Burada hatanın oluşmasına engel olmak amaçlanır. Benzer bir şekilde istatiksel nitelik denetimi uygulanarak, matematiksel olarak yapılan doğrulama işlemleri ile, ilk testlerden bile daha önce, hataların büyük ölçüde bulunup giderilmesi sağlanır. Amaç, hatanın oluşabileceği ortamı ortadan kaldırmaktır. Fakat bunun için matematik modellerinin çok iyi geliştirilmiş ve oturtulmuş olması gereklidir. Bu nedenle, temiz oda süreci daha çok, küçük ölçekli yazılım projelerinde kullanılmaktadır.

3.4 Yardımcı Araç Desteği 

Günümüzde pek çok yardımcı araç nitelikli kod üretimi ve üretilen kodun sınanması (bellek ve işlemci kullanımının ölçülmesi gibi) amacıyla kullanılmaktadır.

Sıkça kullanılan yazılım modüllerinin ortak hale dönüştürülmesi ve kalıpsal bir yapıya sokulması hem hataları azaltır hem de geliştirme süresini düşürür. Bunun yanında, verilen parametrelere göre aynı tür kod üreten araçlar da bulunmaktadır. Hatta, bu koddan belgelendirme de yapabilen araçlar da vardır.

Genel olarak nitelik güvence ekibi tarafından benimsenmiş araçlarla yapılan yazılım geliştirme sonucu elde edilen ürün yüksek nitelikli olarak kabul edilir.

4.REFERANSLAR

  1. https://www.slideshare.net/nuricankaya/capability-maturity-model-7650442
  2. http://www.turhaltemizer.com/2014/04/ts-isoiec-15504-spice-software-process.html
  3. http://www.avinal.net/index.php/tr/insaat-proje-yoenetim-suerecleri-safhalar/yueruetme/kalite-yoenetimi/iso-9000-nedir
  4. https://www.cs.cornell.edu/courses/cs312/2004fa/lectures/lecture9.htm
  5. http://bilgisayarkavramlari.sadievrenseker.com/2009/09/10/program-dogrulugu-program-correctness/
  6. Dr. M. Erhan SARIDOĞAN Yazılım Mühendisliği (İstanbul Papatya yayıncılık Ocak 2008 ) 327-347



Sistem Analizi

Giriş

Birbiriyle ilişkili ve ortak amaca yönelik olarak hareket eden parçalardan oluşan bütüne sistem adı verilmektedir. Sistem kavramı, özellikle endüstri devriminden sonra ekonomik ve sosyal alanlarda kullanım alanı genişleyen bir kavramdır.

Sistemin bazı temel ortak özellikleri vardır. İlişkiler, amaçlar, eylemler, hedefler, bütünlük, işbirliği gibi. Sistem, bir bütünlük oluşturacak şekilde bir arada bulunan unsurlar (öğeler), bu unsurlar arasındaki ilişkiler ve bunların birbiriyle ve çevreyle ilişkili ve bağlantılı olan nitelikleri dizisidir.

sistem ile ilgili görsel sonucu

Resim 1.Sistem

Etki Alanı

Herhangi bir projede anlaşılan , konuşulan kavramların anlaşılabilir olması gerekmektedir. Bunun nedeni projenin iki taraftanda aynı şekilde kabul görmeli. Bir tarafın konuyu yanlış anlaması projeninde olumsuz sonuçlanmasına yol açar.

İsteklerin , hedeflerin ve bunlar dahilindeki ulaşılması gerekilen sonucun açık olması hangi alana ne dahilinde ulaşılması gerektiği belirlenmelidir.

 

 

Projeye Başlama Noktası

Problemi Bulma Ve Çözme

Bu durum iki başlıkta incelenebilir ;

  • Programdaki sıkıntılar
  • Programdaki geliştirmeler

Mevcut bir yazılımda problem kullanıcıların yazılımdaki süreç , teknoloji , performans gibi bazı sıkıntılarında geliştirme yapılabilir. Veya yazılımda ekstra bir eklenti gibi bir talepte bulunulması durumunda mevcut yazılım geliştirilmesi gerekmektedir.

Proje Alanını Anlamak

Proje alanını anlamak için ;

  • Bu alanı küçük parçalara ayırmak
  • Oluşan parçalar hakkında sorular sormak

Yapılan parçalar net olmalı ve büyük sistemin parçaları olmalıdır.

araba sistemi ile ilgili görsel sonucu

Şekil 2.Elektrik Araba Motoru

Örneğin bir banka sistemi

Banka yazılımları çeşitli varyasyonlara sahiptir;

  • Müşteri bilgileri
  • Ödeme bilgileri
  • İşlem Tarihleri
  • Database bilgileri

Ve bunun gibi bir çok farklı özellikleri vardır.

banka sistemi ile ilgili görsel sonucu

Tablo 2.Banka Şubeleri

İster Nedir ?

Kelime anlamı bakımından “bir işin gerektirdiği, yapılabilmesinin ya da olabilmesinin bağlı bulunduğu şey, gerek, zorunluk” anlamına gelir.

Aslında baside indirgersek müşteri veya kullanıcının bizden istekleridir.

İsterler tipleri bakımında iki başlık altında incelenir ;

  1. Fonksiyonel isterler
  2. Fonksiyonel olmayan isterler

6.1 Fonksiyonel isterler

  1. Sistemin yerine getirmesi gereken görevleridir. Bu isterlerin sağlanmaması durumunda sistemde aksama ve bozulmalar yaşanabilir.
  2. Örneğin : Hesap makinesinde dört işlemin yerine getirilmesi için yapılan hesaplamaları sistem kendiliğinden yerine getirir.

6.2 Fonksiyonel olmayan isterler

  1. Sistemin onlar olmadanda işlemesinde herhangi bir sıkıntı olmayan lakin dış görünüş veya bazı formatlar açısından kullanımda yardımcı olan isterlerdir.
  2. Örneğin : Hesap makinesindeki arayüzün kullanıcı dostu olması açısından düzenli ve çekici bir görünüşe sahip olması veya bir rapor programında şirketin verdiği rapor çıktısına uygun sayfa düzeninin yazılıma tanıtılmış olmasıdır. Ne kadar yazılımda risk etmesede şirket için belirli forma uygun olmaması sorun teşkil edebilir.

Sistem Analizi Yöntemleri

7.1 Yapılandırılmış analiz (Kağıt prototip yöntemi)

  • Eski bir metoddur.
  • Fazlar şeklinde düzenlenir
  • Yazılı belgelere dayanır
  • Proje yönetimi araçları ve tekniklerine çok uygundur.
  • Gereksinimler çok erken tanımlanır.
  • Değişiklikler çok maliyetli olabilir.
  • Kullanıcılar fonksiyon ve özelliklerin örneklerini görmeden ihtiyaçları belirlemek zorunda kalabilir.

7.2 Nesne Tabanlı Analiz

  • Objeler gerçek hayatı temsil eder.
  • Her obje bir classa denk gelir.
  • Nesne tabanlı analiz sistemin ne yaptığını odaklanır.
  • Yeniden kullanılabilir bileşenler tasarlanarak hem sistemin geliştirilmesi hızlanır hemde geliştirme ve analiz maaliyeti azalmış olur.
  • Büyük sistematik yazılımlarda karışıklık yapabilir.İş büyüdükçe daha karmaşık bir hale gelir.

yapboz portre ile ilgili görsel sonucu

Şekil 3.Yapboz

7.3 Agile

  • Yoğun bir takım çalışması gerektirmektedir.
  • Projenin öncelikle haftalık , aylık bazen de biraz daha uzun sürebilecek süreçler içerisinde değerlendirilir.
  • Devam eden bu süreçte; tasarlanır geliştirilir ve test edilir.
  • Esnek ve değişime müsaittir.
  • Ürünleri bileşenler halinde test etmeye olanak sağlar.
  • Uzman bilgi ve iletişim becerisi gerektirir.
  • Yapı ve dökümasyon eksiklikleri görülebilir.

agile ile ilgili görsel sonucu

Şekil 4.Agile Yapısı

İster Analizi Raporu

Gereksinimlerin rapor edilmesi ve isterlere göre projeye başlanması için gerekli rapordur.

İki riskli durum söz konusudur;

1. Raporun gereğinden fazla detaycı ve büyük bir yaklaşım sergilemiş olması

Bu gereksiz olduğu gibi maaliyet açısındanda büyük sıkıntı kaynağıdır.

2. Raporun üstün körü olması ve isterlerin tam anlaşılamama durumu

Bu da yapılması istenen projenin dışında bir proje yapılması sonucu doğurabilir.

İster Analizinin Olmazları

  • Maaliyetin çıkarılmış olması
  • Tutarlı olması
  • Gerçekci olması
  • Doğrulanabilir olması
  • Tekrar olmamalı ve net olmalı
  • Önemli konular anlaşılmış olmalı
  • Tutarlı olmalıdır.
  • Takip edilebilir olmalı (Talebe göre referans verilmeli)

İster Analizindeki Sorunlar

  • Anlaşılamama durumları (Etki alanı analizi)
  • İstek çakışmaları
  • Adapte olma sorunu

Bunun gibi sorunlar ortaya çıkabilir.

sorunlar ile ilgili görsel sonucu

Şekil 5.Çıkmazlar

Referanslar




Proje Risk Yönetimi

1.Proje Nedir ?

Belirli bir yerde , belirli bir süre içerisinde belirli bir bütçe ile, net olarak tanımlanan araçların, gerçekleştirilmesine yönelik faaliyetler bütünüdür.

2.Proje Yönetim Süreçleri

Proje fikrinin doğması

Proje yapılabilirliğinin araştırılması

Projenin tanımlanması/tasarlanması ve onay alması

Projenin planlanması

Projenin yürütülmesi ve değerlendirilmesi

Projenin sona erdirilmesi

 

 

3.Risk Nedir?

Zarar, kayıp, tehlike veya hasar olmasına yönelik belirsizlik içeren unsur, etken veya gidişattır.

 

4.Projede Risk Yönetimi

Risk projenin zamanında ve eksiksiz olarak tamamlanmasına engel olabilecek etmendir.Projede risk oluşturabilecek unsurların belirlenmesi çok önemlidir.Bu şekilde erken önlem alınabilir.Buradan yola çıkarak projede karşılaşılabilecek riskler belirlenmeli ve listelenmelidir.Ardından bu oluşabilecek risklere karşı alınabilecek önlemler belirlenmelidir.

Risk yönetimi , sistemin ilk kavramlarının tanımından itibaren uygulanarak sistemin kullanımdan kalktığı ana kadar sürdürülür.

5.Risklerin İzlenmesi

Büyük projelere ait riskler mutlaka bir veritabanında tutulmalı ve izlenmelidir.Proje çalışanları ve ya projeye yeni katılan birisi bu risklerden haberdar olur ve uygun bir yol izlerler.Veritabanının yönetimi proje yöneticisi ve risk yöneticisinde olur.Çözümü bulunamayan riskler için gerekirse yeni çözüm planı çıkartılır.

6.Yazılım Risk Yönetimi 

Yazılım projelerinde oluşabilcek riskler maliyet , zamanlama , teknik başarı , yazılım niteliği ve personel morali üzerinde etkili olabilir.Yazılım risklerine verilebilecek örnekler şöyle olabilir:

  • İsterler
  • Müşteri
  • Yönetim
  • Personel
  • Teknoloji
  • Bağımlılık
  • Dış Kaynaklar

6.1.İsterler 

  • Ne üretileceğinin tam anlaşılmamış olması
  • Yeni isterlerin ortaya çıkma durumu
  • İsterlerin belirsizlikleri
  • Ürün isterlerinin sabitlenmesi için anlaşma olmaması
  • Teknoloji ve uygulama alanlarının değişmesi
  • Değişen isterlerin takip edilememesi gibi risk unsurları oluşabilir.

6.2.Müşteri

  • Müşteri ile iletişim eksikliği
  • Müşterinin ne istediğini tam bilmemesi
  • Uygulama alanının özelliği
  • Birden fazla müşteri olması durumunda çelişkilerin oluşması gibi nedenler.

6.3.Yönetim

  • Yönetimin proje durumunu iyi takip edememesi
  • Yönetimin bilgi ve deneyim eksikliği
  • Proje için oluşturulan takımlarda uyum sorunları
  • İletişim eksikliği
  • Kişilerin yetki ve sorumluluklarının belirlenmesindeki eksiklikler

6.4.Personel

  • Personel eğitiminin yetersizliği
  • Personel deneyimin az olması
  • Oluşan yeni teknolojilerin kabul edilme ve uygulanma güçlüğü
  • Yazılım mühendisliği kültürünün yerleşmemiş olması gibi nedenler

6.5.Teknoloji

  • Geliştirme araçlarının tam oturmuş olmaması
  • Başka sistemlerle olan arayüzlerin değişikliğe uğraması

6.6.Bağımlılık

  • Müşteri tarafından sağlanan bilgilere ve yazılımlara bağlı kalmak
  • Eğitimli ve deneyimli personelin paylaşılamaması
  • Alt yüklenicilere olan bağımlılık
  • Tekrar kullanım için gösterilen fazla çaba

6.7.Dış Kaynaklar

  • Geliştirici ve müşteri arasında gerçekleşen olumsuz ilişkiler
  • Zamanın dar olması halinde oluşan psikolojik baskı
  • Müşterinin beklenmedik kabul ölçütleri ortaya konması
  • Farklı dilde çalışanlar için çeviri sorunu gibi nedenler gösterilebilir.

7.Kaynakça

[1].Sarıdoğan,E.(2008).Yazılım Mühendisliği.İstanbul:Papatya Yayıncılık Eğitim

[2]. http://gelisenbeyin.net/proje-nedir.html

[3]. https://emrealic.wordpress.com/tag/it-surecleri/

[4]. http://www.pro-ge.com/hiz_risk_yonetimi.html

[5]. http://www.kalderankara.org/bilgi-merkezi/yonetim-ve-kalite-araclari/proje-yonetimi-1




Programlama Dilleri

Programlama dillerine girmeden önce algoritma nedir öncelikle onu öğrenelim. Algoritma,bir sorunu çözmede kullanılacak kuralların sıralı listesi olarak açıklanabilir. Programlama dili ise bir yazılım programı oluşturabilmek için gereken kodlar, talimatlar ve yazım kurallarını kapsayan sete verilen isimdir. Algoritma ve programlama dilleri arasındaki ilişki basittir. Algoritma kalıcıdır,diller geçicidir. Örnek olarak Assembly dilinin geliştirildikten sonraki ilk 5 yılındaki kullanım yüzdesiyle şimdiki yüzdesi aynı değildir. Bu konuyla alakalı bu blogdaki yazıyı okuyabilirsiniz.

Programlama Dillerinin Tarihçesi

Charles Babbage, 1910 yılında Analytical ve Difference adında iki makine tasarladı. Charles ve asistanı Ada Lowelace Bernoulli sayılarının Analytical Engine ile çözümü için bir yöntem geliştirdi. Bu yöntem çoğu tarihçi tarafından programcılığın başlangıcı olarak görülüyor.

Şekil 1. Difference Engine ve Charles Babbage

Programlamaya Yaklaşım Türleri

Çok sayıda yaklaşım türü bulunmaktadır ama günümüzde çok kullanılanlardan 5 tanesini açıklayarak devam edelim.

Fonksiyonel Programlama

Bu yaklaşımda matematik fonksiyonlarındaki gibi alt programlar tanımlanmakta ve bu alt programların değişik argümanlar ile çalışması sağlanmaktadır. Yani sıra sıra işlemler neyse onlar yapılıyor.

Bu yaklaşımda kullanılabilecek bazı diller : C,F#

Nesne Yönelimli Programlama

Bütün yapıyı nesneler ve nesneler arası ilişki olarak gören modellemedir. Bu yapıya göre her nesne bir sınıfa ait ve bu sınıftan türetilir. Çomar bir köpektir. Çomar nesne,köpek bunun sınıfıdır.

Bu yaklaşımda kullanılabilecek bazı diller : Java,C#

Yapısal Programlama

Amaç problemi alt parçalara bölerek bu parçaların çözümlerinin birleştirilmesidir. Bu yönüyle parçala fethet (Divide and conquere) yaklaşımı olarak kabul edilebilir.

Bu yaklaşımda kullanılabilecek bazı diller : Java,C

Emirli Programlama

Bir programlama dilindeki komutların satır satır emirlerden oluşmasıdır. Örneğin bir robota komut verecek olsaydık:

  • Kolu 10 derece sağa döndür
  • 2 metre yürü
  • Kolu 20 derece sola döndür gibi emir komutlarıyla oluşan yaklaşımdır.

Bu yaklaşımda kullanılabilecek bazı diller : Fortran,C

Otomat Yönelimli Programlama

Kaynağını otomatlar (automata)’dan alır ve sonlu durum makinaları (finite state machine, FSM) ile tasarlanan bir makinanın kodlanmasını hedefler. C dilindeki switchlerin dallanması gibi düşünülebilir.

Bu yaklaşımda kullanılabilecek bazı diller : Visual Basic,C

Programlama Dilleri Türleri

3’e ayrılır.

Düşük Seviyeli Diller

Kullanılan donanımdaki en temel işlemler yapmayı kullanılır.Eskisine oranla kullanımı cok düşmüştür.Makine koduna en yakın dillerdir. Örnek olarak Assembly verilebilir.

Orta Seviyeli Diller

Esnek yapıdadırlar .Hem düşük hemde yüksek seviyeli programlama yapabilir. Günümüzde kullandığımız işletim sistemleri çoğunlukla C’de yazılmıştır. Örnek olarak C verilebilir.

Yüksek Seviyeli Diller

İnsan diline en yakın seviyedeki dillerdir.Belirli bir fonksiyon üzerinde çalışırlar,bu kısıtlama programlama hakimiyetini azaltır.En kolay öğrenilecek diller bu seviyede olur.En etkin ve hızlı programlama bu seviyededir. Örnek olarak Java,C#,Basic verilebilir.

Dil Türleri arasındaki farklar

Düşük seviyedeki diller, güçlüdür, hakimiyet en üst seviyededir ve programın çalışması diğer seviyelere göre hızlıdır. Eksi yönleri ise kod yazımı,anlaşılması ve öğrenimi zordur. Programın geliştirilmesi uzun zaman alır.

Yüksek seviyedeki diller, öğrenimi ve anlaşılması kolaydır. Kod yazımı ve düzenlemesi hızlıdır. Eksi yönleri ise, programın çalışması diğer seviyelere göre yavaş ve hakimiyeti kısıtlıdır.

Orta seviyedeki diller, iki türün ortasıdır. Bunun için kullanılan bir denklem vardır :

Düşük seviye = Uzun geliştirme süresi + Hızlı çalıştırma

Yüksek seviye = Kısa geliştirme süresi+ Yavaş çalıştırma

Orta seviye ikisinin arasında.

Programlama Dilleri Kronolojisi

Hepsini eklemek mümkün değil ama önemli ve bu sektörde çalışan çoğu kişinin de haberdar olduğu dilleri yazarsak eğer :

  • Grace Hooper 1951 yılında A-0 adında ilk derleyiciyi tasarlıyor.
  • İlk Nesne yönelimli dil olan Simula ortaya çıkıyor.
  • C dili Dennis Ritchie ve Ken Thompson tarafından geliştiriliyor. Daha önce UNIX OS’u ve B dilini de yazarken calışmışlardı. Sistem programcılığında,kernellarda kullanılır.
  • C++ dili günümüzde oyun yapılırken veya görüntü işleme yapılırken kullanılır.
  • Perl ise metin işleme ve görüntü tanıma üzerinde ciddi güçlü olan dildir.
  • Python dili Data Science, Veri Madenciliği, gömülü donanımlarda kullanılır.
  • Java dili genel amaçlı kullanım, sistem programcılığında, bilim ve mühendislik gibi birçok alanda kullanılır.
  • PHP dili web programcılığından genel amaçlı kullanıma kadar geniş bir yelpazesi vardır.
  • Javascript de aynı PHP gibi webte kullanılır, yorumlanmayan browser üzerinde çalışan bir dildir.
  • C#, MS tarafından OOP olarak tasarlanan bir dildir. MS ve .NET framework olmadan çalışmaz. MS ürün ve yazılımlarında kullanılır.
  • Go, Google tarafından geliştirilmiştir. Öbür dillerinin popülarite artışına göre çok çok hızlı popüler olup kullanımı artmıştır.Sistem programlamada, webte kullanılmaktadır.
  • Swift, Apple tarafından Objective-C’nin yerini alması için geliştirilen dildir. Apple ürünlerinde kullanılır.

Programlama öğrenilirken neler bilinmeli ?

  • İngilizce bilmek
  • Seçeceğiniz alanı belirlemek (Web,Mobil,Sistem,Sunucu…)
  • Seçtiğiniz alan ve dillerde önemli işler başarmış veya paylaşımlar yapan insanların projelerinin takip edilmesi
  • Açık kaynaklı olan projelerdeki kodların, düzenlerin, sistematiklerin daima takip edilmesi

Alanlarına göre Programlama Dilleri

Mobil

  • iOS içinse Swift veya Objective-C
  • Android ise Kotlin, Java, C#

Web

  • Front-end için HTML başta olmak üzere CSS, Javascript..
  • Back-end için PHP, ASP.NET ve C#, (Frameworkler sayesinde de yapılabilir Ruby on Rails,Django gibi)

Desktop

  • Windows ise C#, .NET kullanan diller, C++, Java..
  • Tüm ortamlarda çalışanlar için Java, Python, HTML5..

Oyun

  • Grafik kütüphaneleri için uğraşacaksanız C
  • Oyun motorlarıyla gelişticekseniz C#, C++..

Elektronik Cihazlar

  • C, Assembly, Python

Yapay Zeka

  • Haskell, Scala, Prolog

Programlamayı nerelerden öğrenebilirim ?

Online eğitim veya kurs veren siteler

  • Codecademy, W3schools, Udemy, Coursera.

Programlama kitapları

  • C#, Java için Deitel’ın kitapları, Dikeyeksen yayınevi kitapları.

Programlama kursları

  • Bilge Adam,belediye meslek eğitim kurumları gibi kurumlar.

Bilişim dünyasındakilerin eğlendiği dil : Brainfuck

1993 yılında Urban Mülller tarafından üretilen bu dilin asıl çıkış amacı mümkün olan en küçük boyutlu derleyiciyi yapmaktı. Sonraları programcıların kendi sınırlarını zorlayıp eğlendiği bir dile dönüşmüştür. Turing-Complete bir dil olduğundan teoride herhangi bir algoritma bu dilde yazılıp işlenebiliyor. Brainfuck, sekiz komut karakteri +-<>[],. haricindeki tüm karakterleri yok sayar. Bu nedenle (eklenecek yorum, komut karakterleri içermediği sürece) koda yorum eklemek için özel bir söz dizimine ihtiyaç yoktur.

Komut Anlamı
        > İşaretçiyi bir sonraki hücreye kaydır
        < İşaretçiyi bir önceki hücreye kaydır
        + İşaretçinin bulunduğu hücredeki baytı 1 arttır.
         – İşaretçinin bulunduğu hücredeki baytı 1 azalt.
         . İşaretçinin bulunduğu hücredeki baytı standart çıktı birimine yaz.
         , Standart girdi biriminden bir baytlık girdi al ve bunu işaretçinin bulunduğu hücreye yaz.
         [ Eğer işaretçinin bulunduğu hücrenin değeri sıfırsa, ] karakterinden sonraki komuta atla.
         ] Eğer işaretçinin bulunduğu hücrenin değeri sıfır değilse, önceki [ karakterinden bir sonraki komuta atla.

Brainfuck dilinde Hello World örneği

[crayon-5c3f3a0e59a4f453852136/]

Programlama Dillerinin Popülaritesi

Google indexlerine göre son bir yıl içindeki popülarite tablosu

 

Bu tabloyu göstermenin sebebi eğitim için çoğunlukla Google Search’ün kullanılması ve diller üzerinde eğitim veren siteleri indexleri olduğu için.

Java en popüler dilken,Son 5 yılda en çok popülerleşen Python ve en çok popülarite kaybeden PHP’dir aynı zamanda.

 

Bütün internet indexlerine göre son bir yıl içerisindeki popülarite tablosu

Ekim 2017

Ekim 2016 Diller Reytingleri Değişim yüzdesi

1.

1. Java 12.43% -6.37%

2.

2. C 8.37% -1.46%
3. 3. C++ 5.00%

-0.79%

4.

4. C# 3.85%

-0.51%

5. 5. Python 3.80%

+0.03%

6.

6. Javascript 3.01% +0.26%
7. 7. PHP 2.79%

+0.05%

8.

8. Visual Basic 2.73% +0.08%
9. 11. Assembly 2.37%

+0.14%

10. 13 Ruby 2.32%

+0.32%

Assembly ve Ruby yükselişteyken, Java ciddi derecede kan kaybetmiştir.

Referanslar :

  1. http://computer.howstuffworks.com/question717.htm
  2. https://www.bannerconnect.net/dont-fear-another-programming-language/ Dil degistiren adam
  3. http://www.baskent.edu.tr/~tkaracay/etudio/agora/bt/pe.html Tarihçe kisminda kullanilan kaynak
  4. https://scracthegitim.wikispaces.com/Programlama+Dillerinin+Tarihçesi
  5. http://bilgisayarkavramlari.sadievrenseker.com/2011/04/25/algoritma-algorithm/
  6. http://bilgisayarkavramlari.sadievrenseker.com/2007/12/18/yapisal-programlama-structured-programming/
  7. http://bilgisayarkavramlari.sadievrenseker.com/2007/12/18/fonksiyonel-programlama-procedural-programming-functional-programming/
  8. http://bilgisayarkavramlari.sadievrenseker.com/2007/04/14/nesne-yonelimli-programlama-object-oriented-programming/
  9. http://bilgisayarkavramlari.sadievrenseker.com/2009/11/16/emirli-programlama-imperative-programming/
  10. http://bilgisayarkavramlari.sadievrenseker.com/2007/12/18/otomat-yonelimli-programlama-automata-based-programming
  11. https://stackoverflow.com/questions/3468068/low-mid-high-level-language-whats-the-difference
  12. http://www.godoro.com/Divisions/Ehil/Mecmua/Magazines/Articles/txt/html/article_ProgrammingAndLanguage.html
  13. https://en.wikipedia.org/wiki/Timeline_of_programming_languages
  14. http://devnot.com/2017/go-programlama-diline-genel-bakis/
  15. https://tr.wikibooks.org/wiki/C_Sharp_Programlama_Dili/C_Sharp_hakkinda_temel_bilgiler
  16. http://www.webmasto.com/hangi-programlama-dilini-ogrenmeliyim-infografik
  17. https://www.technopat.net/sosyal/blog-icerik/hangi-programlama-dili-nerede-kullanilir-yeni-baslayanlara-tavsiyeler-nelerdir.699
  18. http://tr.0wikipedia.org/index.php?q=aHR0cHM6Ly90ci53aWtpcGVkaWEub3JnL3dpa2kvQnJhaW5mdWNr
  19. https://eksisozluk.com/brainfuck–254183
  20. https://learnxinyminutes.com/docs/tr-tr/brainfuck-tr/
  21. http://pypl.github.io/PYPL.html
  22. https://www.tiobe.com/tiobe-index/

 




Yazılım Tasarımı(Software Design)

Yazılım Nedir ? Hem bilgisayar sistemini oluşturan donanım parçalarının yönetimini hem de kullanıcıların işlerini yapmak için gerekli olan konular topluluğuna yazılım denir.

Tasarım ise herhangi bir mühendislik ürünü geliştirme sürecindeki ilk adım sayılabilir.

Bir kodlayıcı , ne kadar iyi olursa olsun , bir tasarım yapıp onu yeterli bir şekilde yazılı hale getirmedikten sonra verimli bir geliştirme yapamaz .

Yazılım tasarımı , Bir binanın temeline benzetilebilir yeteri kadar sağlam olmayan bir  temel üzerine plansızca inşa edilen katlardan inşa edilen katlardan oluşan bir binanın depreme dayanıklı olması da beklenemez. Ayrıca üzerine başka katlarda çıkmak da mümkün olmayabilir.

Tasarımın temel amacı, ziyaretçi ile içerik arasında gerçekleşen iletişimi kolaylaştırmaktır. Ziyaretçilerin içeriği özgürce keşfedebilecekleri arayüz çalışmasını geliştirmek öncelikli prensip olmalıdır.

 Tasarım Aşaması (Design stage)

Tasarım, yazılımın testine kadar her şeyi etkilediğinden nitelik unsurunun öne çıktığı  ilk aşama olma özelliğini taşımaktadır. Yazılım geliştirme sürecinin ana aşamalarından ilki olan isterler çözümlemesi daha kuramsal iken , tasarım, kodlama ve test daha tekniktir.

Tasarım aşaması bir tür süreç şeklindedir. Aşamalar halinde sürdürülen bu süreç sonunda ortaya çıkan tasarım , kodlamanın ve testin temelini oluşturduğu için  mutlaka yeterli dikkat ve zaman ayrılmalıdır.

Tasarımcılar , sistem tasarımının yapılması , sisteminin yazılım öğelerinin tasarlanması , öğeler de yer alacak standart yazılım birimlerinin belirlemesi ve bu uygulama için hazırlanması , iç yapılarının tasarlarken sıfırdan başlamak zorunda değildir. Daha önce benzer bir iş yapılmış ve başarılı olduğu görülmüş bir tasarım tekrar kullanılabilir.

Tasarımın birinci amacı her zaman basitlik olmalıdır. Çünkü anlaşılır ve basit bir tasarım hem kodlamada hem de sonraki değişikliklerde kolaylık sağlar . Sistem öyle tasarlanmalıdır ki bir dizi değişiklik yapılsa bile sistem hala basit kalabilmelidir. Bunun için veri yapılarında esneklik sağlanmalı, Programlama dilinin sağladığı kolaylıklar göz önüne alınmalıdır.

Basit tasarım , yetenekleri ve özellikleri kısıtlı tasarım olarak algılanmamalıdır.

 

Tasarım Nitelikleri(Design Attributes)

  • İşlevselliği , başarımı ve güvenilirliği yüksek , nitelikli bir ürün oluşturmak ana hedef olmalıdır.
  • Öğrenim ve kullanım kolaylığı göz önünde tutulmalıdır.
  • Tasarımın isterler ile izlenebilirliği olmalıdır.
  • Geliştirilen birimin kodu ve testleri ile izlenebilirliği olmalıdır.
  • Tasarım programlama dilinden olabildiğince bağımsız , kolay anlaşılabilir kolay değiştirilebilir Ve tekrar kullanılabilir olmalıdır.
  • Yazılım projelerinde tasarım , projenin büyüklüğüne göre yazılım tasarım uzmanları veya yazılım mimarları tarafından kullanılır.

 

 

Yazılım Tasarım  Süreci(Software Design Process)

Genelde bir bütün olarak düşünülmesine rağmen yazılım tasarım aşaması da adımlar halinde gerçekleştirilir. En önemli adımlardan biri veri tasarımı olup , çözümleme sırasında toplanan bilgilerin ve bilgi yapılarının yazılımda kullanılacak veri yapılarına dönüştürülmesini içerir.

Tasarım sırasında isterlerin yazılım geliştirmede kullanılacak ifadelere dönüştürülmesi ana amaçtır. Teknik olarak, süreç başında , bu ifadeler ve gösterim tarzı ile yazılımın genel görünüşünü oluşturulurken , süreç sonunda tasarım kaynak koda yakın bir hale gelir.

 

Veri Tasarımı(Data Design)

Veri , Bilgilerin işlenmemiş halidir. Örnek Verecek olursak Öğrenci bilgi Sistemindeki(Obis) öğrencininAdi , ÖğrenciniSoyadi, ÖğrencininNumarasi  Veya şirkette çalışan personelAdı, PersonelSoyadi,PersonelCalistigi Departman bunların hepsi veriye örnektir.

Veri yapısı , Bilgisayar ortamında verilerin ,etkin olarak saklanması ve işlenmesi için kullanılan yapıya denir.

 

Veri modelleme, bir işletmenin, kurumun hatırlamaya değer bulduğu verilerin şekil ve metin olarak ifade edilmesidir.

Veri Yapıları ve veri modelleri , Birbirleriyle mantıksal olarak ilişkili olan verileri yönetilebilir  şekilde bir arada tutmaya yararlar.  Bu yapı ve modeller,  veriler arasındaki sıradüzensel ilişkileri ve erişim yöntemlerini de belirler. Yapıların düzenlemesi ve karmaşıklık düzeyi tamamen tasarımcı belirler.

Tasarımcı, veriye erişim yöntemi, hız, etkinlik, büyüklük, işlev bakımından çözümlenmesini yaparak en uygun veri türlerini ve yapılarını belirler.

Veri yapısı ile veri modeli, iç içe geçmiş iki ayrı kavramdır. Birisi verinin bellekte tutulması veya saklanmasıyla ilgilenirken diğeri veriler arasındaki ilişki ve bağıntılar konusuyla ilgilenir.

İşlevsel çözümlemeye verilen önem kadar veri çözümlemesi ve tasarımı da önem verilmelidir.

 

İyi Bir Veri Tasarımı Nasıl Olmalı ?(How to Design a  Good  Data)

 

Veri Yapıları  ve modelleri  yanında bu yapılar üzerinde yapılacak işlemlerin de tanımlanması gereklidir. Bu tanımlama , nesneye  yönelik tasarımda doğal olarak yapılır . Ancak tasarımda ayrı dikkat edilmelidir.

Kullanılacak veri yapılarını oluşturan birimlerin türleri , sınırları ve birbirleri ile olan ilişkileri bir Veri Sözlüğü içinde toplanmalıdır. Bu sözlükte kullanılacak karmaşık yapıların ve algoritmaların tasarımında kolaylık sağlanır.

Veri yapıları yalnızca kullanan modüllere görünür olmalıdır . Bu şekilde ‘Bilgi Gizleme’ ilkesine uyulmuş olur.

Çok kullanılacak veri yapıların soyut veri türleri şeklinde önceden geliştirilerek bir kütüphane haline getirilirse , tasarım sırasında bunlarla ilişkilendirilir ve kodlama test için zaman ayrılmasına gerek kalmaz . C, C++ dillerindeki kütüphaneler örnek verilebilir.

Tasarım sırasında, kodlamada kullanılacak programlama dilinin özellikleri dikkate alınarak veri yapıları tanımlanır.

Karmaşık veri yapılarının kullanımı gerekiyorsa kullanılacak programlama dili soyut veri türlerini(abstract data types) destekleyecek şekilde seçilmelidir.

Mimari Tasarım(Architectural Design)

Mimari Tasarım, Sistemin tüm yapısının tasarımı ve sistemin nasıl kurulduğunu anlamayla ilgili aşamadır. Daha net olarak ifade edecek olursak, bu aşamada, sistemin nasıl bir yapı üzerine oturması gerektiği hakkında karar verilir.

Uygulama yazılımı bir problemin çözümünü çeşitli parçalara bölerek sağlayabilir. Bu parçaların yazılımdaki karşılığı modüllerdir. Modüllerin sıradüzensel ilişkilerini gösteren yapıya uygulama yazılımı mimarisi  denir.

 

Yazılım içindeki modüller birer nesne olabileceği gibi, tasarım veya gerçekleştirme yönteminin özelliğine göre, birer programi birer paket, birer nesne veya birer yordam olabilirler. Yapının çıkış yelpazesi, genişliği ve derinliği modüler yapı hakkındaki önemli ölçütlerdir.

 

Uygulama Yazılım Tasarımı

Uygulama alanının özellikleri

Yazılımın kullanılacağı alanın gereksinimine göre yazılım birimlerini fiziksel olarak belirli donanım ögeleri üzerinde çalıştırmak gerekebilir. Sistemin merkezi yada dağınık olması, açık sistem olması, belirli bir amaçla kullanmak üzere tahsis edilmesi veya gömülü sistem olması mimari seçimine etki eder.

Uygulama yazılımının karmaşıklık derecesi

Basit uygulamalar, tek program içinde, her türlü arayüz ve bilgi işlemeyi kapsayacak şekilde geliştirilebilirler. Daha karmaşık uygulamalarda, hem geliştirme hem de yürütme bakımından yazılımı ögelere, ögeleri bileşenlere, onları da birimlere bölmek, daha kolay şekilde geliştirme, test ve bakım olanağı sağlar.

Kullanıcı arayüz kısıtlamaları

Geliştirilen yazılımın sonradan başka işletim sistemi veya donanım ile kullanılmak üzere farklı ortamlara taşınması gerekiyorsa, katmanlı bir yaklaşımla, asıl yazılımı olası taşıma işinden etkilenmeyecek şekilde tasarlamak gerekir. Bu nedenle, yazılım mimarisi içine uygun katmanlar yerleştirilebileceği gibi iletişimin zorluklarını gidermek üzere bir ara katman mantığı da kullanılabilir.

 

Yordamsal Tasarım(Procedural Design)

Yordam(procedure, function) , bilgi işlemeyi gerçekleştirmek üzere yazılım modülünün iç yapısında bulunan ve belirli işlevleri olan kod parçalarıdır.

Bir yordam , veri yapıları , döngüler , karşılaştırmalar , dallanmalar yardımıyla tüm bilgi işleme özelliklerini tanımlamalıdır.

Veri ve program yapılarının tasarımı tamamlandıktan sonra yordamsal tasarım başlar. Yordamsal tasarım , modüllerin iç yapılarındaki algoritmik ayrıntıların tanımlanmasıdır.Tasarım ,konuşma diline yakın bir anlatımla yapılabileceği gibi çeşitli şekilsel gösterimlelr de yapılabilir.

Yordamsal Tasarım Nasıl Yapılır?(How to Do Procedural  Design)

A-)Yapısal Programlama Gösterimi:  Yazılım tarihinin en eski tasarım yöntemlerinden biri işlevleri metinsel bir şekilde anlatmaktır. Bu anlatım için genellikle ingilizce kullanılmaktadır.

Program tasarım  dili(programming design language) adı verilen bir dil de tasarım için tanımlanmıştır. Sözde Kod(Psodue) adı verilen yöntem , Gerçek programlama dili yapılarına benzer şekilde ,ancak daha serbest bir sözdilimiyle her yapı ve her yordam tanımlanır.

Program tasarım dilleri genellikle ADA veya Pascal gibi yüksek düzey bir dili andırırlar. Özel bir yazılım paketi getirmeksizin normal bir metin yazıcı kullanılabilir. Tasarım dili ile yazılmış metin dosyalarını grafiksel bir tasarım yöntemine dönüştürülebilen araçlar da bulunmaktadır.

Yordamsal Tasarım Dillerinin Sahip Olduğu Ortak Özellikler
  • Her türlü yapıyı destekleyebilen sabit bir anahtar sözcük listesi
  • Veri yapıları ve veri tipleri tanımlama yeteneği
  • Alt program tanımlama ve çağırma düzeneği
  • Bilgi işlemeyi serbest bir dille anlatabilme yeteneği
  • Arayüz tanımlama yeteneği
  • Giriş/Çıkış yapıları
  • Zaman belirtimleri

Bilinen yapıların kullanımı nedeniyle okunması ve takibi kolaydır. Programlama diline yakın olduğu için kodlayıcının işi daha kolaydır. Ancak , bu anlatımda aşırıya kaçılır . ve gereksiz ayrıntıya girilirse tasarım uzar (örneğin anlaşılır olmasına rağmen bir veri yapısının tüm alanlarına tek tek veri atamayı göstermek gibi), ayrıntıya boğulur ve amacı dışına çıkılır.

B-) Grafiksel Gösterimi: Bazen bir resim birçok satırdan oluşan bir anlatımın yerine geçebilir. Bu gerçekten hareketle , çeşitli grafiksel gösterim yöntemleri bulunmuş ,bu yöntemleri kullanan yazılım tasarım araçları geliştirilmiştir.Ancak bir şeklin eksik yada yanlış çizilmesi okuyucunun gösterim simgelerini iyi bilmemesi sınucu tasarımı yanlış anlaması hatalı kodlamaya neden olabilir. Bu nedenle grafiksel gösterimlerinin iyi öğrenilmesi ve iyi anlaşılması gereklidir.

Yapısal çözümleme ve tasarım yapmak için veri akış diyagramları ve durum geçiş diyagramları kullanılır.

Unified Modelling Language(UML) : Nesneye yönelik çözümleme ve tasarımın hem metinsel hem de grafiksel olarak yapılanilmesine yardımcı olan uluslararası çevrelerce kabul edilmiş , Standart ve yaygın bir tanımlama dilidir.

 

UML Diyagram Türleri (Tr)

 

UML Diyagram Türleri (ENG)

 

 

Akış Diyagramları (Flow Charts):En Eski ve en yaygın program tasarım yöntemlerinden biri akış diyagramları(Flow Chart) kullanılmaktadır. Günümüzde bir program çok sayıda modülden veya yordamdan oluştuğundan , çok sayıda akış diyagramı kullanmak   gerekebilir.

Basit Flow Chart Kullanımı (Eng)

 

 

Basit Flow Chart Kullanımı (Tr)

Arayüz Tasarımı(interface design)

Arayüz tasarımı, kullanıcının faydalanması amacıyla sunmuş olduğunuz çeşitli yazılımsal ürünlerde onların işini kolaylaştırmak ve dilediklerini yapabilmelerini sağlamak amacıyla gerçekleştirilir. Arayüz tasarımlarının genel prensibi kullanıcı odaklı olmalarıdır.
Kullanıcı odaklı arayüzün mutlaka sahip olması gereken üç nitelik bulunmaktadır. Etkileşimli arayüz, görsel tasarım ve bilgi mimarisi bu üç niteliği oluşturmaktadır.

Kullanıcı odaklı arayüzün mutlaka sahip olması gereken üç nitelik bulunmaktadır. Etkileşimli arayüz, görsel tasarım ve bilgi mimarisi bu üç niteliği oluşturmaktadır.

   Bileşen Arayüz Tasarımı

Büyük Yazılımlar birkaç ana ögeden , her bir öge birkaç bileşenlerden ya da birimden oluşabilir. Bu bileşenler arasında mutlaka tanımlı bir arayüz vardır. Bileşenler ya da birimler birer yürütülebilir program olabilecekleri gibi , bir program grubu da olabilirler.

   Sistem- Altsistem Arayüz Yazılım Tasarımı

Bilgi sistemlerinin bazıları , başka sistemleri , altsistem veya aygıtları tümleştirerek daha büyük sistemler elde etmek üzere tasarlanırlar .Tümleştirme için özel olarak tasarlanan altsistem arayüz yazılımları kullanılır.
Kullanıcı Arayüz Tasarımı

Bilgi Sistemleri , insanların denetiminde çalıştıkların için kullanımı kolay , etkin ve açık arayüzlere sahip olmalıdırlar. Arayüz tasarımı gerçekleştirmek istiyorsanız öncelikli olarak kullanıcıyı merkeze yerleştirmelisiniz. Kullanıcının beklentilerini karşılayabilmeli, ihtiyaçlarına cevap verebilmeli ve onların eğilimlerini tahmin edebilmelisiniz.

Referanslar(Kaynakçalar)

  • Erhan SARIDOĞAN Yazılım Mühendisliği Kitabı Papatya Yayıncılık,
  • http://baskaisler.com/arayuz-tasarimi
  • http://www.ihs.com.tr/blog/10-arayuz-tasarim-kurali
  • https://www.slideshare.net/TurulCanll/cb-yazlm-mimarisi-ve-tasarm
  • https://sherpa.blog/5-adimda-veri-bilgi-data-gorsellestirme#.We-EY2i0PIU

 

 

Hazırlayan:Necmi Altuk  – Rifai Kuçi