Yazılım Mühendisliğinin Temelleri Dersi Proj
advertisement
FIRAT ÜNİVERSİTESİ TEKNOLOJİ FAKÜLTESİ Yazılım Mühendisliği YMT114 - Yazılım Mühendisliğinin Temelleri Dersi Proje Uygulamaları ve Dökümantasyonu Fırat Üniversitesi Elektronik İmza Sistemi Proje Çalışma Grubu UĞUR GÜRTÜRK Proje Yürütücüleri MAYIS –2013 1 İÇİNDEKİLER 1. GİRİŞ ÖNSÖZ…………………………………………………………………………………………………………………………………………07 1.1 Projenin Amacı…………………………………………………………………………………………………………………………….08 1.2 Projenin Kapsamı…………………………………………………………………………………………………………………………08 1.3 Tanımlamalar ve Kısaltmalar………………………………………………………………………………………………………..08 2. PROJE PLANI 2.1 Giriş……………………………………………………………………………………………………………………………………………09 2.2 Projenin PlanKapsamı………………………………………………………………………………………………………………….09 2.3 Proje Zaman-İş Planı…………………………………………………………………………………………………………………..15 2.4 Proje Ekip Yapısı…………………………………………………………………………………………………………………………15 2.5 Önerilen Sistemin Teknik Tanımları……………………………………………………………………………………………16 2.6 Kullanılan Özel Geliştirme Araçları ve Ortamları………………………………………………………………………..17 2.7 Proje Standartları, Yöntem ve Metodolojiler……………………………………………………………………………..18 2.8 Kalite Sağlama Planı…………………………………………………………………………………………………………………..21 2.9 Konfigürasyon Yönetim Planı…………………………………………………………………………………………………….23 2.10 Kaynak Yönetim Planı…………………………………………………………………………………………………………..23 2.11 Eğitim Planı………………………………………………………………………………………………………………………….23 2.12 Test Planı …………………………………………………………………………………………………………………………….25 2.13 Bakım Planı………………………………………………………………………………………………………………………….25 3. SİSTEM ÇÖZÜMLEME 3.1 3.2 Mevcut Sistem İncelemesi…………………………………………………………………………………………27 3.1.1 Örgüt Yapısı……………………………………………………………………………………………………………………27 3.1.2 İşlevsel Model………………………………………………………………………………………………………………..27 3.1.3 Veri Modeli……………………………………………………………………………………………………………………29 3.1.4 Varolan Yazılım/Donanım Kaynakları….…………………………………………………………………………30 3.1.5 Varolan Sistemin Değerlendirilmesi………………………………………………………………………………35 Gereksenen Sistemin Mantıksal Modeli……………………………………………………………………36 3.2.1 Giriş……………………………………………………………………………………………………………………………..36 3.2.2 İşlevsel Model………………………………………………………………………………………………………………36 3.2.3 Genel Bakış……………………………………………………………………………………………………………………37 2 3.3 3.4 3.2.4 Bilgi Sistemleri/Nesneler……………………………………………………………………………………………….37 3.2.5 Veri Modeli……………………………………………………………………………………………………………………39 3.2.6 Veri Sözlüğü………………………………………………………………………………………………………………….40 3.2.7 İşlevlerin Sıradüzeni………………………………………………………………………………………………………41 3.2.8 Başarım Gerekleri………………………………………………………………………………………………………….42 Arayüz (Modül) Gerekleri………………………………………………………………………………………….42 3.3.1 Yazılım Arayüzü……………………………………………………………………………………………………………..42 3.3.2 Kullanıcı Arayüzü…………………………………………………………………………………………………………..42 3.3.3 İletişim Arayüzü…………………………………………………………………………………………………………….43 3.3.4 Yönetim Arayüzü…………………………………………………………………………………………………………..44 Belgeleme Gerekleri………………………………………………………………………………………………..44 3.4.1 Geliştirme Sürecinin Belgelenmesi………………………………………………………………………………..44 3.4.2 Eğitim Belgeleri……………………………………………………………………………………………………………..44 3.4.3 Kullanıcı El Kitapları……………………………………………………………………………………………………….44 4. SİSTEM TASARIMI 4.1 Genel Tasarım Bilgileri……………………………………………………………………………………………………45 4.1.1 Genel Sistem Tanımı………………………………………………………………………………………………………45 4.1.2 Varsayımlar ve Kısıtlamalar…………………………………………………………………………………………….47 4.1.3 Sistem Mimarisi……………………………………………………………………………………………………………..48 4.1.4 Dış Arabirimler……………………………………………………………………………………………………………….49 4.1.4.1 Kullanıcı Arabirimleri……………………………………………………………………………………………….49 4.1.4.2 Veri Arabirimleri……………………………………………………………………………………………………..49 4.1.4.3 Diğer Sistemlerle Arabirimler………………………………………………………………………………….50 4.1.5 Veri Modeli…………………………………………………………………………………………………………………….50 4.1.6 Testler…………………………………………………………………………………………………………………………….50 4.1.7 Performans……………………………………………………………………………………………………………………..50 4.2 Veri Tasarımı……………………………………………………………………………………………………………………51 4.2.1 Tablo tanımları…………………………………………………………………………………………………………………51 4.2.2 Tablo- İlişki Şemaları…………………………………………………………………………………………………………52 4.2.3 Veri Tanımları…………………………………………………………………………………………………………………..52 4.2.4 Değer Kümesi Tanımları……………………………………………………………………………………………………52 4.3 Süreç Tasarımı…………………………………………………………………………………………………………………52 4.3.1 Genel Tasarım…………………………………………………………………………………………………………………52 4.3.2 Modüller…………………………………………………………………………………………………………………………54 3 4.3.2.1 Giriş Modülü……………………………………………………………………………………………………………54 4.3.2.1.1 İşlev…………………………………………………………………………………………………………54 4.3.2.1.2 Kullanıcı Arabirimi…………………………………………………………………………………..54 4.3.2.1.3 Modül Tanımı………………………………………………………………………………………….55 4.3.2.1.4 Modül iç Tasarımı……………………………………………………………………………………55 4.3.2.2 Kullanıcı Modülü……………………………………………………………………………………………………..56 4.3.3 Kullanıcı Profilleri…………………………………………………………………………………………………………..56 4.3.4 Entegrasyon ve Test Gereksinimleri……………………………………………………………………………….56 4.4 Ortak Alt Sistemlerin Tasarımı…………………………………………………………………………………………57 4.4.1 Ortak Alt Sistemler…………………………………………………………………………………………………………57 4.4.2 Modüller arası Ortak Veriler…………………………………………………………………………………………..57 4.4.3 Ortak Veriler İçin Veri Giriş ve Raporlama Modülleri………………………………………………………57 4.4.4 Güvenlik Altsistemi…………………………………………………………………………………………………………57 4.4.5 Veri Dağıtım Altsistemi ………………………………………………………………………………………………….58 4.4.6 Yedekleme ve Arşivleme İşlemleri………………………………………………………………………………….58 5. SİSTEM GERÇEKLEŞTİRİMİ 5.1. Giriş………………………………………………………………………………………………………………………………………….59 5.2. Yazılım Geliştirme Ortamları……………………………………………………………………………………………………..59 5.2.1 Programlama Dilleri…………………………………………………………………………………………………….59 5.2.2 Veri Tabanı Yönetim Sistemleri……………………………………………………………………………………59 5.2.2.1 VTYS Kullanımının Ek Yararları……………………………………………………………………………..60 5.2.2.2 Veri Modelleri……………………………………………………………………………………………………..62 5.2.2.3 Şemalar……………………………………………………………………………………………………………….62 5.2.2.4 VTYS Mimarisi……………………………………………………………………………………………………..63 5.2.2.5 Veritabanı Dilleri ve Arabirimleri………………………………………………………………………….64 5.2.2.6 Veri Tabanı Sistem Ortamı…………………………………………………………………………………..68 5.2.2.7 VTYS'nin Sınıflandırılması…………………………………………………………………………………….68 5.2.2.8 Hazır Program Kütüphane Dosyaları…………………………………………………………………….68 5.2.2.9 CASE Araç ve Ortamları……………………………………………………………………………………….68 5.3. Kodlama Stili……………………………………………………………………………………………………………………………68 5.3.1 Açıklama Satırları………………………………………………………………………………………………………….69 5.3.2 Kod Biçimlemesi……………………………………………………………………………………………………………69 5.3.3 Anlamlı İsimlendirme……………………………………………………………………………………………………..69 4 5.3.4 Yapısal Programlama Yapıları…………………………………………………………………………………………69 5.4. Program Karmaşıklığı……………………………………………………………………………………………………………….69 5.4.1 Programın Çizge Biçimine Dönüştürülmesi…………………………………………………………………….70 5.4.2 McCabe Karmaşıklık Ölçütü Hesaplama…………………………………………………………………………70 5.5. Olağan Dışı Durum Çözümleme………………………………………………………………………………………………..71 5.5.1 Olağandışı Durum Tanımları…………………………………………………………………………………………..71 5.5.2 Farklı Olağandışı Durum Çözümleme Yaklaşımları………………………………………………………….71 5.6. Kod Gözden Geçirme………………………………………………………………………………………………………………..72 5.6.1 Gözden Geçirme Sürecinin Düzenlenmesi………………………………………………………………………72 5.6.2 Gözden Geçirme Sırasında Kullanılacak Sorular………………………………………………………………72 5.6.2.1 Öbek Arayüzü………………………………………………………………………………………………………….73 5.6.2.2 Giriş Açıklamaları…………………………………………………………………………………………………….73 5.6.2.3 Veri Kullanımı………………………………………………………………………………………………………….73 5.6.2.4 Öbeğin Düzenlenişi…………………………………………………………………………………………………74 5.6.2.5 Sunuş……………………………………………………………………………………………………………………..74 6. DOĞRULAMA VE GEÇERLEME 6.1. Giriş……………………………………………………………………………………………………………………..…………………….75 6.2. Sınama Kavramları……………………………………………………………………………………………………………………..75 6.3. Doğrulama ve Geçerleme Yaşam Döngüsü………………………………………………………………………………….76 6.4. Sınama Yöntemleri………………………………………………………………………………………………………………………76 6.4.1 Beyaz Kutu Sınaması………………………………………………………………………………………………………..76 6.4.2 Temel Yollar Sınaması………………………………………………………………………………………………………77 6.5. Sınama ve Bütünleştirme Stratejileri……………………………………………………………………………………………78 6.5.1 Yukarıdan Aşağı Sınama ve Bütünleştirme……………………………………………………………………….78 6.5.2 Aşağıdan Yukarıya Sınama ve Bütünleştirme……………………………………………………………………78 6.6. Sınama Planlaması………………………………………………………………………………………………………………………79 6.7. Sınama Belirtimleri………………………………………………………………………………………………………………………80 6.8. Yaşam Döngüsü Boyunca Sınama Etkinlikleri……………………………………………………………………………….81 7. BAKIM 7.1 Giriş……………………………………………………………………………………………………………………………………………..83 7.2 Kurulum……………………………………………………………………………………………………………………………………….84 7.3 Yerinde Destek Organizasyonu…………………………………………………………………………………………………….84 5 7.4 Yazılım Bakımı………………………………………………………………………………………………………………………………84 7.4.1 Tanım…………………………………………………………………………………………………………………………………….84 7.4.2 Bakım Süreç Modeli………………………………………………………………………………………………………………85 8. SONUÇ 9. KAYNAKLAR 6 ÖNSÖZ 7 1. GİRİŞ 1.1. Projenin Amacı Üniversitemizdeki dosya,rapor ve hertürlü işlemin web üzerinden daha hızlı ve güvenli yapılarak gerek akademisyen gerekse öğrencilere daha az maliyet ve daha hızlı bir şekilde verimli bir çalışma ortamı sağlamaktır.Yani elektronik ortamda belgelerin hangi kuruma ya da kişiye ait olduğunu doğrulamak ve üniversitemizde ıslak imza ile aynı hukuki yetkiye eşdeğer hale getirmek projenin hedefleri arasındadır. 1.2 Projenin Kapsamı Üniversitenin ağı üzerinde çalışacak bu sistem aynı zamanda ; bankalar,finans kurumları, sigorta şirketleri, kamu kurum ve kuruluşları, holdingler, büyük şirketler,üniversiteler gibi uzun vadede yaygın kullanım alanı bu- labilecek bir teknolojik sistemdir.Bazı uygulama alanları ; • Sosyal güvenlik uygulamaları, • Vergi ödemeleri, • Ticari uygulamalar, • E-sözleşmeler, • E-sipariş. 1.3 Tanımlamalar ve Kısaltmalar -EİS:Elektronik İmza Sistemi, -YS:Yönetim Sistemi. 8 2. PROJE PLANI 2.1 Giriş Elektronik İmza başka bir elektronik veriye eklenen veya elektronik veriyle mantıksal bağlantısı bulunan ve kimlik doğrulamak amacıyla kullanılan elektronik veriyi tanımlar.Aynı zamanda bilginin üçüncü bir kişinin erişimine kapalı bir ortamda , bütünlüğü bozulmadan ve tarafların kimlikleri doğrulanarak iletildiğini elektronik ve benzeri araçlarla garanti eden harf, karakter veya sembollerden oluşur. Şekil 2.1 Projenin Genel Yapısı 2.2 Projenin Plan Kapsamı Projenin plan kapsamında genel olarak mevcut sistem, sistemin gerekliliği ve bu sistemin güvenilirliğinden yola çıkıldı. E-imza ıslak imzaya eşdeğer olup, internet üzerinden her türlü kağıt ısrafını önleyerek ve elektronik ortamda arşivlenerek yürütülmesini sağlar.E-imza ile bilgiler, raporlar,dosyalar vb. bilgisayar ortamında tutulduğu için gerekli olan evrak ve dosyalar vakit kaybı olmadan ve daha kolay bir şekilde elde edilecektir. 9 Şekil 2.2 Projenin Genel İşleyişi -- E-İMZA SİSTEMİ ÜNİVERSİTEMİZDE NEDEN GEREKLİ ? • Verinin izinsiz ya da yanlışlıkla değiştirilmesini, silinmesini ve ekleme yapılmasını önlediği için yani veri bütünlüğü sağladığı için, • Mesajın ve sahibinin belli olması yani kimlik doğrulama ve onaylama imkanı sağladığı için, • Bireylerin elektronik ortamda gerçekleştirdiği işlemleri inkar edemedikleri için, ve israfı önlediği için bu teknolojinin başta Fırat Üniversitesi olmak üzere her türlü sektörde kullanılmasını gerekli kılmıştır. ----- Kamusal ve ticari iş ve işlemlerin elektronik ortamda yapılmaya başlaması ile birlikte, bu iş ve işlemlerin geçerliliğinin, bütünlüğünün, erişilebilirliğinin ve inkar edilemezliğinin sağlanması sorunu ortaya çıkmıştır. Bu sorunu çözmek için en uygun çözüm olarak elektronik imza uygulaması başlatılmış ve tüm dünyada kullanılmaya başlanmıştır. 10 Şekil 2.3 E-imza projesiyle tasarruf Şekil 2.4 E-imza Avantajları Bu teknoloji ekonomik ve zamansal katkı sağladığı için birçok destek sağlayan kuruluşlar tarafından da desteklenmektedir. Şekil 2.4 E-imza Avantajları 11 Şekil 2.5 E-imza’lı Bir Mesaj Nasıl Oluşur Güvenli Elektronik İmza ancak Nitelikli Elektronik Sertifika ile sağlanabilir. Nitelikli Elektronik Sertifika almak için başvurulabilecek yerler olan Elektronik Sertifika Hizmet Sağlayıcıları Telekomünikasyon Kurumu’nun internet sayfasından yayımlanacaktır. Kamu kurumunda çalışan ve elektronik imzaya sahip olan memurlar ve e-imzaları kurum içi ve kamu kurumları arasında işlemlerde kullanacaklardır. Sertifika Başbakanlık Genelgesi gereği TÜBİTAK UEKAE 'den temin edilebilir. Bunun için kamu kurumları personelleri için TÜBİTAK UEKAE 'ye kurumsal başvuru yaparak çalışanları için e-imza temin edebilirler. Eğer kamu kurumu çalışanı değilseniz ya da kamu çalışanı olduğunuz halde vatandaş olarak kurum dışındaki işlemlerinizde elektronik imzayı kullanmak istiyorsanız, bu işi yapmaya yetkili özel şirketlerden, yani elektronik sertifika hizmet sağlayıcılardan, sertifikanızı ücret karşılığında almanız gerekmektedir. Telekomünikasyon Kurumu nitelikli elektronik sertifika vermeye yetkili olan kuruluşları internet sayfasında duyurmaktadır. Burada önemli olan husus, internet sayfasında da duyurulan hizmet sağlayıcılar dışındaki kuruluşlardan elektronik sertifika temin edilmemesidir Elektronik İmza Altyapısı Nasıl Çalışır: • Kullanıcı elektronik sertifika için elektronik sertifika hizmet sağlayıcısına başvurur. • Sertifika hizmet sağlayıcısı kullanıcının kimliğini geçerli ve güvenilir belgelerle tasdik eder. • Sertifika hizmet sağlayıcısı sertifikanın kaydını bir dizinde toplar. • Kullanıcı kendi gizli anahtarıyla mesaj sahibinin kimlik doğrulaması, mesajın bütünlüğünü ve inkar edilemezliğini sağlayarak mesajı imzalar ve karşı tarafa gönderir. • Karşı taraf mesajı alır. Elektronik imzasını kullanıcının açık anahtarıyla onaylar ve kullanıcının sertifikasının geçerliliğini ve durumunu kontrol etmek için veri kütüğünde sorgulama yapar. Veri kütüğü sertifikanın geçerli/iptal durum bilgilerini karşı tarafa iletir. 12 Maliyet Kestirim Dökümanı Proje adı : Fırat Üniversitesi Elektronik İmza Sistemi Ölçüm Parametresi Kullanıcı Girdi Sayısı Kullanıcı Çıktı Sayısı Kullanıcı Sorgu Sayısı Kütük Sayısı Dışsal Arayüz Sayısı Ana İşlev Nokta Sayısı Sayı 4 4 6 12 13 Ağırlık 3 4 3 7 5 Toplam 12 16 18 84 65 401 Teknik Karmaşıklık Sorusu 1. Uygulama, güvenilir yedekleme ve kurtarma gerektiriyor mu? 2. Veri iletişimi gerekiyor mu? 3. Dağıtık işlem işlevleri var mı? 4. Performans kritik mi? 5. Sistem mevcut ve ağır yükü olan bir işletim ortamında mı çalışacak? 6. Sistem, çevrim içi veri girişi gerektiriyor mu? 7. Çevrim içi veri girişi, bir ara işlem için birden çok ekran gerektiriyor mu? 8. Ana kütükler çevrim-içi olarak mı günleniyor? 9. Girdiler, çıktılar, kütükler ya da sorgular karmaşık mı? 10. İçsel işlemler karmaşık mı? 11. Tasarlanacak kod, yeniden kullanılabilir mi olacak? 12. Dönüştürme ve kurulum, tasarımda dikkate alınacak mı? 13. Sistem birden çok yerde yerleşik farklı kurumlar için mi geliştiriliyor? 14. Tasarlanan uygulama, kolay kullanılabilir ve kullanıcı tarafından kolayca değiştirilebilir mi olacak? TOPLAM 0: 1: 2: 3: 4: 5: Hiçbir Etkisi Yok Çok Az etkisi var Etkisi Var Ortalama Etkisi Var Önemli Etkisi Var Mutlaka Olmalı, Kaçınılamaz İN = AİN x (0.65 x 0.01 x TKF) İN=401*(0,65*0,01*60) İN=156,39 Satır Sayısı = İN *30 13 Puan 5 5 5 4 1 5 0 5 3 2 3 1 5 1 60 SATIR SAYISI=156,39*30=4691,7 SATIR YAKLAŞIK 4700 SATIR Etkin Maliyet Modeli – COCOMO Organik proje: a=2,4 , b=1,05 , c=2,5 , d= 0,38 Yarı – Gömülü Projeler İçin: a=3,0 , b=1,12 , c=2,5 , d= 0,35 Gömülü Projeler İçin: a=3,6 , b=1,20 , c=2,5 , d= 0,32 Öncelikle projemizin türünü belirlememiz gerekiyor. Küçük ekip tarafından geliştirildiği için organik projeler arasına giriyor. Aylık Kişi Başı İş Gücü = E = a x (KSS)b Geliştirme Süresi (Ay) = D = c x (E)d Eleman Sayısı = E / D Formülde verilen değişkenler şöyle: KSS = Kod Satır Sayısı manasına gelmektedir ve birimi bin satırdır. Projenin tahmini kaç bin satırdan oluşacağını belirtmemizi sağlar. Aylık Kişi Başı İş Gücü = E= 2,4*0,81,05=1,89 Geliştirme Süresi =D= 2,5 x = 10 ay Tahmini Gerekli Personel Sayısı = 3,18 / 1,89= 2 (yaklaşık) 14 2.3 Proje Zaman-İş Planı Şekil 2.6 Proje İş-Zaman Çizelgesi 2.4 Proje Ekip Yapısı Şekil 2.6 Proje Ekibi 15 Şekil 2.7 Proje Ekip görevleri 2.5 Önerilen Sistemin Teknik Tanımları Kullanılan Teknoloji Açık Anahtarlı Altyapı Teknolojisi Matematiksel şifreleme yöntemleri kullanılır. Şifreleme için büyük sayı dizilerinden oluşan 2 anahtar kullanılır. Özel anahtar (imza oluşturma verisi) • E-imzayı oluşturmak için kullanılır. • Sadece kişinin kendisinde bulunur. • Akıllı kart içinde saklanır ve bu araçtan dışarıya çıkarılamaz. Açık anahtar (imza doğrulama verisi) • E-imzayı doğrulamak için kullanılır. • Gizli olmayan, herkese açık bir veridir. 16 Şekil 2.8 E-imzada Kullanılan Akıllı Kart 2.6 Kullanılan Özel Geliştirme Araçları ve Ortamları Çözümleme Ve Tasarım Araçları • Smart Draw 2010 Professional • IBM Rational Software Article • Adobe Photoshop CS5 • Adobe Dreamweaver CS5 • Adobe Flash CS5 Programlama Araçları Sınama Araçları • PHP • MYSQL • Action Script 2.0(Flash) • HTML • JAVA • XML • Microsoft Windows 7 • Iphone OS'X • Android 17 Destek Araçlar • Mozilla Firefox 11 • Google Chrome17 • Internet Explorer 9 • Safari 5 2.7 Proje Standartları, Yöntem ve Metodolojiler Spiralin başladığı ilk çeğrek içinde ilk isterler toplanır ve buna göre proje planlaması yapılır. İkinci çeyrekte, ilk tanımlanan isterlere göre risk çözümlemesi yapılır. Üçüncü çeyrekte, risk çözümlemesi sonunda ortaya çıkan isterlerin tanımlanmasındaki belirsizlikleri ortadan kaldırmak için prototipleme yöntemi kullanılır. Gerekirse benzetim(simülasyon) veya diğer modelleme kullanılarak isterlerin daha sağlıklı tanımlanması sağlanır. Dördüncü çeyrekte, müşteri, ortaya çıkan ilk ürünü inceleyerek değerlendirme yapar, önerilerde bulunur. Bu şekilde tenımlanan ilk döngü bir sonraki döngü için bir girdi oluşturur. Şekil 2.9 Proje Aşamaları Proje standartları yukarda belirtildiği gibidir. Bunu yanı sıra kullanılan sistem modelinde ise helezonik model kullanılmıştır. 18 Şekil 2.10 Proje Gelişim Modeli Şekil 2.11 Planlama Aşaması Bu aşamalar yazılım geliştirmede önemli unsurlardır.Bu kullandığımız yazılım geliştirme metodolojilerinden Spiral Model dir.Bunu kullanmamızın amacı döngü şeklinde kontrol edip hataları en aza indirebilmektir. 19 Şekil 2.11 Proje Risk Çözümleme Aşaması Şekil 2.12 Proje Üretim Aşaması Üretim aşaması uzun zaman alan bir aşamadır.Tasarıma yer verilir ve projenin büyük çoğunluğu bitmiş olur.Bu aşamada ara ürün üretilir.Proje bu aşamayla epeyce bir yol almış olacaktır. 20 Şekil 2.13 Kullanıcı Değerlendirme Aşaması Şekil 2.13 Ekip Yapısı Zaman Planı 21 2.8 Kalite Sağlama Planı Şekil 2.14 Kalite Sağlama Planı Projedeki kalite sağlama planımız yukardaki tabloda da belli olduğu üzere; 1.Ekonomi: Ekonomik açıdan yazılımın maliyeti her ne kadar ilk seferde pahalı olsa da ileriye dönük düşünüldüğünde ve zaman tasarrufundan ötürü gayet uygundur. 2.Tamlık: Projede herhangi bir açık olmamalı ve programda bulunan tüm butonlar textler vs. çalışır ve tamdır. 3.Yeniden Kullanılabilirlik: Otomasyon her koşulda tekrardan düzenlenip kullanılabilecek. 4.Etkinlik: Kullanıcı sistemin her alanına hakim olduğu için sistemi etkin bir biçimde kullanacak. 5.Bütünlük: Admin1 sistemin tüm kısımlarına hakim olacak ve program bir bütün halinde çalışacaktır. 6.Güvenilirlik: Otomasyon gerekli güvenlik önlemlerinin alınması yanı sıra şuan devlet bünyesinde bulunan çok yüksek güvenlik önlemli serverlarda saklanacaktır. 7.Modülerlik: Modülerlik otomasyonun her seviyesindeki kişinin ayrı ayrı sayfalardan söz sahibi olmasını sağlar. Örneğin: Yönetim modülü, Giriş Modülü… 8.Belgeleme: Bu belgeden de anlaşılacağı üzere tam anlamıyla sistemin özeti olacak bu 22 doküman oluşturulmuştur. 9.Kullanılabilirlik: Kullanılabilirlik olarak her seviyedeki insana hitap edeceğinden zor renkler karmaşık sistemlerden kaçınılmıştır. 10.Temizlik: 11.Değiştirilebilirlik: Otomasyonun veri tabanını erişme yetkisi olan ve sistem hakkında bilgisi olan herkes sistemde değişiklik yapabilecek. 12.Esneklik: Proje farklı platformlarda ve internet üzerinden çalışacağından gayet esnektir. 13.Genellik: Proje her üniversitede kullanılabileceğinden geneldir. Ve Türkiye genelinde kullanılacaktır. 14.Sınanabilirlik: Projedeki pilot bölge uygulaması sınana bilirliğinin göstergesidir. 15.Taşınabilirlik: Sistem internet üzerinden kullanılacağından herhangi bir özel cihaz gerektirmez ve istenilen cihazlarda taşınabilir ve kullanılabilir. 16.Birlikte Çalışılabilirlik: Bu projedeki en büyük sıkıntı olacak veri girişi şuanda var olan ve her bireyin bilgilerinin saklayan sistemle birleşik ve eş zamanlı çalışmakta. 2.9 Konfigürasyon Yönetim Planı Sistemin ilerde kullanıcının yeni istemlerini karşılayamaması veya sistemin yapısındaki bazı bileşenlerin değişmesi sonucu güncelliğini kaybettiğinde olası konfigürasyon planı hazırlandı. Üniversiteye giren yeni akademik görevli için sistem üye kadrosu açması, Herhangi bir sebepten dolayı ayrılan personel olması, Sistemde herhangi bir istenmeyen durum halinde, Durumları için konfigürasyon yönetim planı oluşturuldu. 2.10 Kaynak Yönetim Planı Mevcut bir kaynağımız olmadığından kaynak olarak sadece bu proje dokümantasyonu var. Bunun yanında 5070 Sayılı Elektronik İmza Kanununu kaynağından yola çıkarak mevcut sistemi geliştirdik. 23 2.11 Eğitim Planı Projeden kazanılacak en önemli olaylardan biride eğitimdir. Kullanılacak dillerin arayüz editör ve programların kullanımında hakim olunamaması halinde bu program başarıyla neticelendirilemez. Bu yüzden projede bazı eğitimler alınması gereklidir. Proje kapsamında alınacak olan eğitimler; • Adobe Flash CS5.5 Kullanım Eğitimi • Adobe Fireworks CS5.5 Kullanım Eğitim • PHP Dil Eğitimi • SQL Dil Eğitimi Gereken eğitimlerdir. Tablo 2.1 Eğitim Planı 24 Eğitimlerin zamana göre çizelgesi; Tablo 2.2 Proje Eğitim Planı Başlama Tarihi Bitiş Tarihi Adobe Flash CS5.5 Kullanım Eğitimi Mar.13 Haz.13 AdobeFireworks CS5.5 Kullanım Eğitim Mar.13 Haz.13 PHP Dil Eğitimi Mar.13 Haz.13 SQL Dil Eğitimi Mar.13 Haz.13 Uğur Gürtürk Bu şekilde bir eğitim planı uygulanmaktadır.Sistem tam olarak hazırlandığında eğitim planıda garanti olarak ayarlanacaktır ve ona göre eğitim semineri verilecektir.Zira verilmemesi halinde kullanıcılar sistemi tam olarak kullanamayaca ve bazı açıklıklar meydana gelecektir. 2.12 Test Planı Proje test ekipleri ve görevleri şu şekildedir; Fırat Üniversitesi bölgesindeki bir kısım personel kullanıcı ve admin olarak görev yapacak. Gerekli resmi kısımlarda ise resmi olarak ekip yapıları yapılacak. Bu ekiplerin test aşamasında yapacağı işler aşağıdaki gibidir; 25 2.13 Bu ekiplerden kullanıcı sadece gidip imzasını kullanacak. Ön hazırlık olarak ise üniversitemizden başlamak koşuluyla gerekli hiyerarşi takip edilecek ve pilot belgede bir uygulama gerçekleştirilecek. Bakım Planı Projenin bakım planına gelecek hergün kullanılacak bu sistem tüm değişim ve bazı durumlarda kullanıcı eklenip çıkarılacak tüm bu sistemsel değişiklikler bakım planında yapılacaktır. Şekil 2.15 Proje Bakım Planı Şekil 2.17 Üretim Sahası 26 3. SİSTEM ÇÖZÜMLEME 3.1 Mevcut Sistem İncelemesi Mevcut sistem incelemesi öncelikleüniversitemizde ilk olacağından çok zor olacaktır. Bunun yanı sıra internet üzerinde genellikle Elektronik imza kanunu ve E-GÜVEN , ESERTİFİKA gibi kaynaklardan incelenerek sistemin genel yapısı incelenmiş ve bizim sistemimize nasıl katkı yapılacağı araştırılmış sisteme uygulanmıştır. 3.1.1 Örgüt Yapısı Örgüt yapısı olarak E-Güven bünyesindeki bilgi işlem personellerinin ortak çalışmasıyla oluşan bir örgüt yapısı vardır. Şekil 3.1 Sistemin Örgüt Yapısını Oluşturan Örnek Bir Şirket E-imzaya Geçiş Süreci • Kurumun Yapması Gereken Çalışmalar Belirlemesi Gereken Politikalar • Belgenin E-imza ile İmzalanması Süreci • Kurumlar Arası E-imzalı Yazışma • E-mühür 27 3.1.2 İşlevsel Model Şekil 3.2 Use-Case Diyagramı Şekil 3.3 Basit Bir Use-Case 28 Admin1 Admin2 Dosya Belirlenir Admin2’ye Gönderir. Sistem Düzenleyiciler Bu Görev Yönetici Görevindeki Admin1’e Aittir. Yönetici görevlendirmesine göre çalışırlar. İmzalanacak Veriyi Gerekli Yere Gönderir. İmza Doğrulama İşlemine Ortam Hazırlar. Kullanıcılar İmzalama Yapan görevliler Değerlendiriciler İmza Doğrulaması Yapar Şekil 3.4 Temel Görevlendirme 3.1.3 Veri Modeli Veri tabanı ilişkisel veri modelinde veriler tablolar üzerinden kurulan ilişkiye dayanmaktadır. Kayıtlı Üye İMZA KULLANMA BÖLÜM NO KULLANICI NO() NUMARA BÖLÜM NO() ADI USER Şekil 3.5 Sistem Veri Modeli 29 3.1.4 Varolan Yazılım/Donanım Kaynakları Elektronik Sertifika Sağlayıcılar, Ms Word, Argo UML, RSA. Şekil 3.6 Donanımsal Kaynaklar Şekil 3.6 İmza Doğrulama Ve Veri Transferi 30 Şekil 3.6 İmza Doğrulama Ve Veri Transferi 31 Şekil 3.7 Elektronik Sertifika Oluşturma Şekil 3.8 Sertifika Başvuru Sistemi 32 Şekil 3.9 Sertifika Başvuru İşlemi Ve Giriş Seçimi 33 Şekil 3.10 Şifre Giriş Ekranı 3.1.5 Varolan Sistemin Değerlendirilmesi Yukarda da söylediğimiz gibi şifre var kullanıcılar bu şifre sayesinde sisteme giriş yapacaklar. Kullanıcıların şifrelerini yani güvenlik sözcüğünü unuttukları vakit cep telefona sms gelecek tir. Şekil 3.11 Şifre Unutma Durumunda Yapılacaklar 34 Gibi avantajlar sunarak kullanıcıya daha verimli bir çalışma sağlamak amaçlarımız arasındadır. 3.2 Gereksenen Sistemin Mantıksal Modeli 3.2.1 Giriş Mevcut sistemler incelendiğinde sonuca giden yolda epeyce bir eksikler ve resmi olmayan durumlar söz konusu artık bu sistemi Türkiye hukuk standartlarına uydurmak bize kalıyor. Sistemin işlevsel modeli ile başlamak gerekirse… 3.2.2 İşlevsel Model Şekil 3.12 Use-Case Diyagramı Durum İsmi Aktör başlatılıyor Aktör Katılımcı Giriş Durumu Olayların akışı Durum çıkışı Dosya paylaşımı Admin1 Admin2 Rektörlüğe Bağlı Admin1 Giriş Yapmış 1. Admin1 Dosya seçmesi 2. Seçtiği Dosyayı Admin2’ye gönder Evrak Paylaşımı ve İmza Doğrulama başarılı ise mesaj vermesi 35 Durum İsmi Aktör başlatılıyor Aktör Katılımcı Giriş Durumu Olayların akışı Durum çıkışı Gelen Dosyayı Onayla Admin1 Admin2 Admin1 Giriş Yapmış 1.Adminin dosyayı onaylaması Onaylama başarılı ise mesaj vermesi Durum İsmi Aktör başlatılıyor Aktör Katılımcı Giriş Durumu Olayların akışı Durum çıkışı Resmi Açıklama Yapar Admin1 Admin2 Admin1 Giriş Yapmış 1. Admin2 den işlem sonuçlarının gelmesi 2. Admin1 kamuya sonuçları açıklaması İşlemler doğru ise mesaj vermesi Durum İsmi Aktör başlatılıyor Aktör Katılımcı Giriş Durumu Olayların akışı Durum çıkışı Kullanıcıdan Gelen Dosyayı Onayla Admin1 Admin2 Admin1 Giriş Yapmış Admin1 in dosyayı onaylaması Onaylama başarılı ise mesaj vermesi Durum İsmi Aktör başlatılıyor Aktör Katılımcı Giriş Durumu Olayların akışı Durum çıkışı Arşiv Oluştur Admin1 Admin2 Admin1 Giriş Yapmış Arşiv kurullarını oluşturması Oluşturma başarılı ise mesaj vermesi 3.2.3 Genel Bakış Genel hatlarıyla sistemi inceleyecek olursak mevcut imza yönetim sisteminde mevcut olan tüm olaylar burada da var dökuman yönetim sistemiyle kıyaslayacak olursak sonuçlara hiçbir şekilde Admin1 dahil müdahale edilemiyor. Bunun yanı sıra olayın akış şekli USE-CASE diyagramında mevcuttur. Yani dosya,veri,evrak hiçbir şekilde başkası tarafından alınamaz, görülemez , işlem yapılamaz . 3.2.4 Bilgi Sistemleri/Nesneler ADMİN1: Yapının en üstünde bulunan ve en yetkili yapılanmadır. Admin2’ye ve kullanıcıya yetki verir. ADİMN2: Yapının ikinci nesnesidir.Kullanıcının isteğine, gerekli olan dosyaya göre 36 ADİMN1’e gereksinimi bildirir. KULLANICI: Yapının üçüncü nesnesidir .Evrak istemi imzalaması gibi birçok istemde bulunur. ARŞİV: Dosyaların elektronik ortamda saklanarak evrak azalımına olanak veren bir stok nesnesidir. Gerekli evrağı,dosyayı admin1 e göndermekle sorumludur. İkinci planda olduğu için Use-Case diyagramında işleme almadık. Şekil 3.13 Veri Tabanı İlişkileri 37 3.2.5 Veri Modeli Şekil 3.14 Veri Modeli 38 Şekil 3.15 Bazı İşleyiş Diyagramları Şekil 3.16 İmza-Kullanıcı 39 3.2.6 Veri Sözlüğü Ana bilgilerinin tanımlanması Tc_no = *11 haneli integer değer tipinde bir sayıdan oluşur* İsim= *String tipinde bir değerden oluşur* Soyisim= *String tipinde bir değerden oluşur* Gorev= *String tipinde bir değerden oluşur o kişinin görevlerini içeren kelimeye sahiptir* Yetki= *integer veri tipinde bir karakterdir ve kişinin yetkisine göre değişir.* Durum= *Boolean veri tipindedir imza durumunu gösterir * Akademik bilgilerinin tanımlanması Kisi= *Ana tablosundaki kişinin tc_no suna göre gelen bilgileri alır* Gorevlendirme= *Kendi altındaki kişiyi görevlendirip görevlendirmediği değerini içeren boolen tipindeki veridir * Gorev= *Kendi üstündeki kişi tarafından görevlendirilip görevlendirilmediği değerini içeren boolean tipindeki veridir* Sayım=*imza atan kişinin imzasının doğru olduğunu gösteren veridir* Gorevlendirme= * Kendi altındaki kişiyi görevlendirip görevlendirmediği değerini içeren boolen tipindeki veridir * Gorev= *Kendi üstündeki kişi tarafından görevlendirilip görevlendirilmediği değerini içeren boolean tipindeki veridir* Sayım=*İmza atan kişinin imzasının doğru olduğunu gösteren veridir* 3.2.7 İşlevlerin Sıradüzeni İmzalanan veri akademik görevli tarafından admin1 e gönderir,Admin1 fakülteye göre dosyayı admin2’yegönderir.Veriye,dosyaya göre o kullanıcı olan akademik personele gönderir ve imzalama işlemi gerçekleşir. 40 Şekil 3.17 Bazı İşleyiş Diyagramları Şekil 3.18 Aktivite Diyagramları 41 3.2.8 Başarım Gerekleri Mevcut sistemler incelendi ve mevcut sistemin eksiklerinden yola çıkılarak, sistemin başarımı için Sistemin sonuç üretim doğrulukları Tepki sürelerinin en aza indirilmesi Mali külfetin azaltılması Hile hata ve yanlışlıkların en aza indirilmesi Kullanım kolaylılığı Anlaşılabilirlik Tarafsızlık temel gereklilikler olarak tespit edilmiştir. 3.3 Arayüz (Modül) Gerekleri 3.3.1 Yazılım Arayüzü Projenin çalışması esnasında böyle bir açık verilmemesine özen gösterildi. Gerekli olan her türlü değişiklik seurce kodları üzerinden yapılıp tekrar derlenecek. 3.3.2 Kullanıcı Arayüzü Projede kullanıcının arayüzü tasarlanırken herhangi bir şekilde renkler seçilerek tarafsız rahat büyük puntolu yazılı bir arayüz tasarlanacaktır. 42 Şekil 3.18 Kullanıcı İş Akışı Şekil 3.19 Kullanıcı Arayüzü 3.3.3 İletişim Arayüzü İletişimle ilgili olarak iletişim modülümüzü yazacağız lakin üniversite ile yapılan anlaşmada bu modül konmayacak denirse çünkü bu onların hakkı olası bir kötü durumda muhatap biz olmamamız açısından koyulmayabilir. 3.3.4 Yönetim Arayüzü Projenin %90 ı genelde yönetimsel arayüzlerden oluşacak sadece personelin göreceği ekran kullanıcı arayüzüne girecek dışındaki her yer yönetimsel arayüz olacak. Yöneticinin ekrana girdiğinde karşılaşacağı arayüzdür.İki arayüz vardır:Biri Kullanıcı Arayüzü diğeri ise yönetimsel arayüzdür.Yani bu arayüz admin tarafından sisteme girişlerde gerçekleşecektir. 43 Şekil 3.120 Yönetimsel Arayüz 3.4 Belgeleme Gerekleri 3.4.1 Geliştirme Sürecinin Belgelenmesi Geliştirme sürecinde genel olarak belgelendirilmesi hem ileriye dönük hem de şimdiki geliştirme sürecinde projenin tamamlanma yüzdesini nerede kalınıp nerelerde eksikler olduğunu genel hatlarıyla göstermesi amacıyla yapıldı. Bunun yanı sıra projeye yeni dahil olan personellerin olaya hakimiyeti açısından bu yönteme başvuruldu. 3.4.2 Eğitim Belgeleri Mevcut bir belgemiz bulunmamaktadır. 3.4.3 Kullanıcı El Kitapları Bu kısma projenin en son safhasında kullanıcılara verilecek eğitimlerden pilot uygulamalardan yola çıkılarak hazırlanacak.Yani proje sonunda rahat ve kolay kullanımdan dolayı bir eğitim semineri ve bir kullanım kitapcığı hazırlanacaktır. 44 4. SİSTEM TASARIMI 4.1 Genel Tasarım Bilgileri 4.1.1 Genel Sistem Tanımı Şekil 4.1 Genel Sistem Tanımı Gereksinimler Gereksinimler kısmında üniversitede bir anket düzenlenecek ve ona göre bir tasarım oluşturmaya başlanacaktır.Çünkü her ne kadar da Teknoloji Çağı’nda yaşasakda bilgisayarı açıp kapamayı zor yapan insanlar var. İşlevsel Belirtimler Bu kısımda ilk önce sistemin ne yapacağı sorusuna cevap verelim. Sistem Türkiye de kâğıt üstünde yapılan ve birçok külfeti olan sistemin dijital ortama aktarılması diye özetlenebilir. Seçim öncesinde gerekli hiyerarşiler gene dijital ortamda yapılarak imza ortamı oluşturulacak ve personel imzasını atacak,dosya ve evrak paylaşımı yapacaktır. İkinci olarak yazılım ne yapacağı sorusuna cevap vermek gerekirse, yazılım ilk aşamada Admin1 ile her fakülte arasındaki iletişimi sağlayacak. Bundan sonra imzalama sırasında kimlik kontrolü yapmasını ve personelin rahat bir şekilde imzalama ve paylaşım ortamı sağlayacak. Tasarım Tasarım aşamasında neler olacağını grafiksel olarak aktarmak isterim. 1. İlk önce bir Süreç tasarımı olacak ve adımlar aşağıdaki gibi olacak. 45 2.Süreç tasarımı bittikten sonra sıra Arayüz tasarımına geldi ve arayüz tasarımı aşağıda göründüğü adımlarla gerçekleştirildi. 3.Arayüz tasarımını aştıktan sonra sora yapısal tasarıma geldi. Yapısal tasarımda izlenen yollar aşağıdaki gibi oldu. 46 4.Yapısal tasarımı da yapıp Veri tasarımına geçildi ve şu adımlar izlendi. Şekiller 4.2 Tasarım Aşamaları 4.1.2 Varsayımlar ve Kısıtlamalar Sistemde varsayılan değerler bulunmamakta bunun yanı sıra başlıca kısıtlamalar şunlardır: Üniversiteye ait personel olması Dosya paylaşımını sağlaması Daha önce bu konuda eğitilmiş olması 47 Dosya içeriğinin gizli tutulması 4.1.3 Sistem Mimarisi Şekil 4.3 Genel Sistem Mimarisi 48 Şekil 4.5 Veri Tabanı Sistemi Sistemin mimarisinin akış diyagramı şeklinde verilmesinin temel nedeni sistemin işleyiş mantığının nasıl olduğu ve nasıl bir yol çizileceğinin bilinmesidir.Akış diyagramı sistemin temel mantığı hakkında bize fikie verecektir. 4.1.4 Dış Arabirimler 4.1.4.1 Kullanıcı Arabirimleri Kullanıcı arabirimlerin ilk başında sistem giriş ekranı bulunacak. Ve her birimin kendine ait ekranları olacak. Kullanıcı girişi bu arabirimde amaçlanmıştır.Kullanıcı bilgilerini girerek bu sisteme giriş yapmış olacaktır. Şekil 4.6 Admin Doğrulaması 4.1.4.2 Veri Arabirimleri Veri arabirimlerinde sistem flash ile çalışacağından veritabanından kayıt yazıp okurken arada XML ve Php arabirimleri olacaktır. Veriler,dosyalar,evraklar bunlar veri halinde iletim sağlanacaktır. Eskiden var olan dosya ve evraklarda optik olarak okutulup arşivde tutulacaktır. 49 Şekil 4.7 İmza İşlemi 4.1.4.3 Diğer Sistemlerle Arabirimler Şuan tam bilgi sahibi olmadığımız için bu arabirim kullanılmayacaktır. 4.1.5 Veri Modeli Şekil 4.8 Veri Tabanı Diyagramları 50 «uses» «bind» Ekleme Islmeleri Islemler «uses» «uses» «bind» VeriTabanı Güncelleme İslemleri «bind» «uses» Silme Islemleri «bind» «uses» Listeleme Islemleri Şekil 4.8 Veri Tabanı Diyagramları 4.1.6 Testler Genel hatlarıyla testlerimiz iki aşamada gerçekleştirilecek. Bilinen adıyla pilot bölge uygulaması yapılacak. Alfa Aşaması: Sistemin geliştirildiği yerde kullanıcıların gelerek katkıda bulunması sistemi test etmesi ile yapılacak. Beta Aşaması: Kullanıcı, geliştirilen sistemi kendi yerleşkesinde, bir gözetmen eşliğinde yapılacak. 4.1.7 Performans Sistemin performansını etkileyen faktörlerin test verileri değerlendirilecek Sistemin Tasarıma Uygunluk Performansı; Tasarımı yapılan sistemin stabilitesi ve işleyiş performansı değerlendirilecek. Veri Yapısının Sistemle Performansı; Veri yapısının sistemle stabilitesi ve çalışma zamanındaki uyumluluk düzeyindeki performansı değerlendirilecek. 4.2 Veri Tasarımı 4.2.1 Tablo tanımları Sistem 5 tablodan oluşmaktadır. Bunun yanı sıra kullanıcının ekstra istekleri doğrultusunda ek tablolara açık bir sistem tasarlanmaktadır. İlk olarak sistemi kullanacak her varlığın insan olduğunu kabul edersek bu insanları tek bir tabloda tutmak en mantıklısı olacaktır böyle bir sistem ile ANA tablosunu yaptık. Bunun yanı sıra her kuruluş için ayrı tablo yapıldı ve kuruluşların içindeki en yetkili kişi tablonun ikincil 51 anahtarı oldu ve ANA tablosu ile ilişkilendirildi. Tablo 4.1 Kullanıcı Tablosu Veri Çeşitleri Kullanıcı Tablosu Veri Adı Veri Tipi KullanıcıId İnt (Primary Key) KullanıcıAdı Varchar(50) KullanıcıSifresi Varchar(50) KullanıcıTipId İnt (Foregin Key) Adi Varchar(50) Soyadı Varchar(50) Email Varchar(50) 4.2.2 Tablo- İlişki Şemaları Tablo 4.2 ilişki Şemaları 52 4.2.3 Veri Tanımları Veri tipi olarak integer(int) kullanılmasının amacı sayısal değerleri almaktan ötürüdür. String olarak kullanılan değerler kelime içeren değerleri tutacağından ötürü kullanıldı. Boolean veri tipi işte işin can alıcı noktası burası boolean veri tipi iki faklı değer alır ya truedir ya false eğer ki görevlendirme varsa true olur yada imzalamış ise kişi ANA tablosunun DURUM kısmı true olacak ve kişi bir daha imza kullanamayacak. 4.2.4 Değer Kümesi Tanımları Sayım, Sonuc: Kullanılan imzalar doğrultusunda oluşacak olan değerdir. Yetki: Yetki kişinin akademik kariyer derecesine göre değişen bir değerdir. 4.3 Süreç Tasarımı 4.3.1 Genel Tasarım Genel olarak tasarımda ilk önce veri tabanı modeli oluşturuldu. Ardından giriş modülü onun ardından yönetici modülleri ve en sonda kullanıcı arayüzü oluşturduk. 53 Şekil 4.10 Giriş Sayfası Modülleri 54 4.3.2 Modüller 4.3.2.1 Giriş Modülü 4.3.2.1.1 İşlev Kullanıcının sisteme müdahale edecebileceği ekrana erişmesi için aşması gereken bir modüldür. 4.3.2.1.2 Kullanıcı Arabirimi 55 Şekil 4.11 Kullanıcı Modülleri 4.3.2.1.3 Modül Tanımı Hükümet yetkilileri tarafından kullanıcılara verilecek çok gizli güvenlikli kullanıcı adı ve 56 şifreden meydana gelir. 4.3.2.1.4 Modül iç Tasarımı Kullanılacak değişkenler: private Connection con: Veri tabanı için bağlantı nesnesi. private String vtURL: Veritabanının bulunduğu yol. private String kullaniciAdi: veritabanına bağlantı için kullanıcı adı. private String sifre: veri tabanına bağlantı için şifre. Tablo 4.4 Metodlar 4.3.2.2 Yönetici Modülü 4.3.2.3 İşlev Sistem içindeki tüm arabirimler aslına bakacak olunursa yönetim modülüdür. Arayüzler tamamı ile birbirinin aynısı lakin işlevler farklıdır. Butonların isimleri farklıdır . 57 4.3.3 Kullanıcı Profilleri ADMİN1: Yapının en üstünde bulunan ve en yetkili yapılanmadır. Admin2’ye ve kullanıcıya yetki verir. ADİMN2: Yapının ikinci nesnesidir.Kullanıcının isteğine, gerekli olan dosyaya göre ADİMN1’e gereksinimi bildirir. KULLANICI: Yapının üçüncü nesnesidir .Evrak istemi imzalaması gibi birçok istemde bulunur. ARŞİV: Dosyaların elektronik ortamda saklanarak evrak azalımına olanak veren bir stok nesnesidir.Gerekli evrağı,dosyayı admin1 e göndermekle sorumludur.İkinci planda olduğu için Use-Case diyagramında işleme almadık. 4.3.4 Entegrasyon ve Test Gereksinimleri Sistemimizin daha öncede belirttiğimiz gibi devletin mevcut veri tabanlarıyla entegrasyon halinde olması gerekir bu yüzden devlet yetkililerinden bir ekibe gereksinimimiz var. Bunun yanı sıra pilot bölgedeki test süresince 1.derece yazılım yetkilileri orda bulunmalı ve sistem testini gözlemleyip notlar çıkartmalı. 58 4.4 Ortak Alt Sistemlerin Tasarımı 4.4.1 Ortak Alt Sistemler Kullanılacak tek ortak sistem devletin mevcut sistemidir bu sistemle tc numarası bazında kişinin tüm bilgisi alınacaktır. 4.4.2 Modüller arası Ortak Veriler Modüller arasında ilişkili veri modelinde olduğu üzere ortak veriler mevcuttur. Bunlar Tc_no, Görevlendirme, Görev ve sonuç birbirleriyle ilişkili ortak verilerdir. 4.4.3 Ortak Veriler İçin Veri Giriş ve Raporlama Modülleri Ortak veriler için böyle bir modül kullanılmadı 4.4.4 Güvenlik Altsistemi Yazılım sistemlerinin güvenilirliğe ilişkin nicelikleri, kullanıcıların gereksinimlerini karşılayacak şekilde ortaya koymak ve güvenilirliğin hesaplanmasına yönelik verileri toplama, istatistiksel tahminleme, ölçütlerin tespiti, yazılıma ait mimari özelliklerin belirlenmesi, tasarım, geliştirme ve bunlara yönelik çalışma ortamının belirlenmesi ve modellenmesini kapsamaktadır. 1. Model seçme ve düzenlemeye yönelik faaliyetlerin temelinde uygun hedeflerin tespit edilmesi bulunmaktadır. 2. Hata ve aksaklıkların analiz edilmesi için uygun verilerin tanımlanması gerekmektedir. Örneğin, arıza veya hataları önemine göre sınıflandırmak, hatalar arası ortalama süreyi bulmak, hata nedenlerini araştırmak, hataları bulmaya yönelik test verilerine karar vermek. 3. Belirtilen hedeflere yönelik veriler modellenir. 4. 5. 6. 7. 8. 9. Geçmişe yönelik verilerin zaman bilgilerini de içerecek şekilde elde edilerek yazılım geliştirme sürecine dâhil etmek. Yazılım geliştirme sürecinin modellenmesi, hata ile karşılaşılıp, test sürecine başlamak ve model doğrulama işlemlerine gerçekleştirmek. Güvenilirlik tahminleme modelinin seçilmesini sağlamak. Güvenilirlik modeli tarafından kullanılacak olan parametrelerini tespit etmek. Verilen bir noktayı kullanarak gelecekteki olası hatalar hakkında tahmin yapmak. Tahmin edilen hata ve arıza oranları ile gerçekleşen değerleri kıyaslamak. 59 4.4.5 Veri Dağıtım Altsistemi Veri dağıtımından ziyade veri alma üzerine bir sistem kuruldu. Dağıtılan sistemlerde zararlı kişilerin müdahalesi kolay olmaktadır bunun yanı sıra bizim sistemimizde terminaller serverlardan veri çekecek serverlar terminallere veri göndermeyecek. 4.4.6 Yedekleme ve Arşivleme İşlemleri Depolanan verilerin, herhangi bir nedenle zarar görmesi, sistemin çalışma süreçlerinde ciddi zararlar oluşturabilir. Yaşanabilecek bir felaket durumu sonrasında, depolanan verilerin geri yüklenememesi, sistemin sağlandığı kullanıcılara veya kurumlara çok ciddi zararlar verebilir. Bu nedenle sistemin çalışma süreçlerine bağlı olarak, yedekleme sistemleri kurulmalı ve yedekleme işlemleri günlük olarak takip edilmelidir. Yedekleme sistemlerinin kurulumu; yedeklenecek veri miktarı, yedekleme sıklığı, yedeklenen verinin zaman içerisinde değişme oranı ve maksimum veri kaybı gibi parametrelere bağlıdır. Sistemin birden fazla sunucusunun eş zamanlı yedekleme işlemini yapabilmesi, işletim sistemlerinin kayıt dosyalarını tam ve eş zamanlı olarak yedekleyebilmesi ve işletim sistemleri üzerinde çalışan veri tabanı uygulamasının yedeklerini sistem kapatılmadan alabilmesi gerekmektedir. 60 5.1 Giriş Gerçekleştirim çalışması, tasarım sonucu üretilen süreç ve veri tabanının fiziksel yapısını içeren fiziksel modelin bilgisayar ortamında çalışan yazılım biçimine dönüştürülmesi çalışmalarını içerir. Yazılımın geliştirilmesi için her şeyden önce belirli bir yazılım geliştirme ortamının seçilmesi gerekmektedir. Şekil 5.1 Sistem Gerçekleştirim Modeli 4.1 Yazılım Geliştirme Ortamları Yazılım geliştirme ortamı, tasarım sonunda üretilen fiziksel modelin, bilgisayar ortamında çalıştırılabilmesi için gerekli olan: Programlama Dili Veri Tabanı Yönetim Sistemi Hazır Program Kitapçıkları CASE Araçları belirlendi ve yazılım geliştirme ortamı hazırlandı. 4.1.1 Programlama Dilleri Sistemde kullanılan başlıca programlama dillerini daha öncelerde de yazmıştık fakat burada bir kez daha dile getirelim. Kendi içlerinde sınıflandırılan bu diller arasından bizim seçtiğimiz sınıf şüphesiz ki veri işleme yoğunluklu uygulamalarda kullanılacak dillerden olacaktır. Bu yüzden daha çok görsel programlamaya önem verilecek kullandığımız diller arasında FLASH,PHP,SQL,XML başlıcalarıdır. Flash sistemlerde her ne kadar görsel tasarım gibi gözükse de arka planda ki ACTİON SCRİPT kodları 61 gayet başarılı ve hızlıdır. Veri tabanı işlemleri içinde diğer dilleri kullandık. Çünkü flash direk veri tabanına bağlanamıyor. 4.1.2 Veri Tabanı Yönetim Sistemleri Flash ile hazırladığımız sistem ara yüz burada ki kullanıcı/programcının kullandığı uygulama kısmına denk geliyor. Xml sorgu ve programları işleyen yazılıma denk geliyor. Php ise veriye erişen yazılım oluyor. Veri tabanı tanımları ve Depolanmış veri tabanı ise SQL ile çözümleniyor. Veri tabanı yönetiminde kullandığımız hiyerarşiyi bir göstermek gerekirse: Şekil 5.2 Veri Tabanı Sistemi 62 4.1.2.1 VTYS Kullanımının Ek Yararları Şekil 5.3 VTYS nin Ek Yararları 4.1.2.2 Veri Modelleri Şekil 5.4 Veri Modeli Fiziksel Veri Modelinde verilerin Mysql de tablolar içindeki alanlarda saklanacağı ve birbirleriyle ilişki içinde olduğunu söyleyebiliriz. Kavramsal Veri Modelini iki ana başlık 63 altında inceleyebiliriz. Şekil 5.5 Şema Mimarisi Üçlü şema mimarisinde görülen yapıların, kullanıcı gereksinimlerinden yola çıkılarak aşamalı bir şekilde fiziksel olarak gerçekleştirilmesidir. 1. - Gereksinimlerin belirlenmesi Veri tipleri Veri grupları Veriler ile ilgili kurallar Veriler üzerinde yapılması gereken işlemler 2. Kavramsal Model Kullanıcıdan elde edilecek gereksinimler ile ilgili bir analiz çalışmasının yapılması ve birbiriyle bağlantılı verilerin gruplanarak bir düzenleme içinde modellenmesi gerekmektedir. Bu modeli grafiksel olarak varlık bağıntı seçenekleri ile gösteririz. 3. Mantıksal Model Veri tabanı tasarımlarımızın ilişkisel veritabanı modelinde tablolar ile ifade edilebilmesi için yapılması gereken dönüşümü içerir. 4. Fiziksel Model Fiziksel olarak sistemin kurulması sağlanır. Kullanılacak VTYS ile ilgili ilk temas burada kurulur. 64 «uses» Kullanıcı «uses» Admin User Şekil 5.6 Kullanıcı Şemaları 4.1.2.3 Şemalar Şekil 5.7 Şemalar Herhangi bir veri modelinde veri tabanının tanımlanması ile kendisini ayırmak önemlidir. Veri tabanının tanımlamaları veri tabanı şeması veya meta-veri olarak adlandırılır. Veri tabanı 65 şeması, tasarım sırasında belirtilir ve sıkça değişmesi beklenmez. Pek çok veri modeli şemaları, diyagramlar halinde göstermek için belli gösterim biçimlerine sahiptir. Diyagramlar her kayıt tipinin yapısını gösterir fakat kaydın gerçek örneğini göstermez. 4.1.2.4 VTYS Mimarisi VTYS mimarisini üç başlık altında ele aldık bunları özetlemek gerekir ise: 66 Şekil 5.6 Veri Tabanı Şemaları 4.1.2.5 Veritabanı Dilleri ve Arabirimleri Sistemimizde veritabanı dili olarak SQL kullanıldı. Henüz prototip aşamasında olan sistemimiz için MYSQL arabirimini yeterli gördük. Şekil 5.7 Veritabanı Dilleri ve Arabirimleri 1.1.1.1 Veri Tabanı Sistem Ortam Veri tabanı sistem ortamında phpMyAdmin bizim kahrımızı çekti. Tüm Yükleme, yedekleme, performans ölçme, sıralama, veri sıkıştırma, ve benzeri fonksiyonları yerine getirmek amacıyla bu ortamı kullandık. 1.1.1.2 VTYS'nin Sınıflandırılması En fazla kullanılan veri modelleri ilişkisel, ağ, hiyerarşik, nesne-yönelimli ve kavramsal modellerdir. Bizim Kullandığımız ise ilişkisel veri modelidir. 1.1.1.3 Hazır Program Kütüphane Dosyaları Zaten entegre olduğu için böyle bir şeye ihtiyaç duymadık. 1.1.1.4 CASE Araç ve Ortamları Case araçları olarak ise Microsoft un Visio Project ürünlerini kullandık. Bunun yanı sıra IBM RSA yazılımı Smart Draw yazılımını kullandık. 1.2 Kodlama Stili Kendimize has kodlama bicini kullandık herhangi bir hazır düzene bağlı kalmadık Bakım programcımıza da aynı stil üzerine eğitim verdik ve sorunları ortadan kaldırdık. 67 5.3.1 Açıklama Satırları Açıklama satırları karmaşık her satırın sonunda yapıldı. Ve biten her günün sonunda kodun kalındığı yere o günün tarihi atıldı. 5.3.2 Kod Biçimlemesi Kod biçimlemesine değinmek gerekirse alt alta oluşan kodlarda tabi indexleri kullandık ve iç içe bir biçimde hiyerarşi oluşturduk. 5.3.3 Anlamlı İsimlendirme Sistem kodlamasının genel yapısında kullanılan değişkenlerin veri tabanında karşılığı varsa önce “tabloadı_islevadı_sayısı” seklinde bir anlamlı isimlendirme yaptık. 5.3.4 Yapısal Programlama Yapıları Genel olarak 3 başlıkta incelersek: Ardışık işlem yapıları: Bu tür yapılarda genellikle fonksiyon, altprogram ve buna benzer tekrarlı yapıları tek bir seferde çözdük. Koşullu işlem yapıları: Bu yapıları ise neredeyse programın tamamında kullandık karşılaştırma yapılan her yerde bunlara yer verildi. Döngü yapıları: Tıpkı ardışık işlemler gibi alt alta birkaç satır yazıcığımıza tek bir döngüyle bu sorunların üstesinden geldik. 1.3 Program Karmaşıklığı Program karmaşıklığını ölçmek için bir çok teorik model geliştirilmiştir. Bu modellerin en eskisi ve yol göstericisi McCabe karmaşıklık ölçütüdür. Bu bölümde bu ölçüt anlatılmaktadır. Söz konusu ölçüt 1976 yılında McCabe tarafından geliştirilmiştir. Bu konuda geliştirilen diğer ölçütlerin çoğu, bu ölçütten esinlenmiştir. McCabe ölçütü, bir programda kullanılan "koşul" deyimlerinin program karmaşıklığını etkileyen en önemli unsur olduğu esasına dayanır ve iki aşamada uygulanır: Şekil 5.8 Program Karmaşıklığı 68 5.4.1 Programın Çizge Biçimine Dönüştürülmesi Şekil 5.9 Programın Çizgi Hali 5.4.2 McCabe Karmaşıklık Ölçütü Hesaplama k = 13 Kenar sayısı d = 9 Düğüm sayısı p = 1 Bileşen sayısı V(G)=k-d+2p (Formülüyle bulunur) 69 V(G)= k – d + 2p VG= 30 – 25+2*31 = 67 Şekil 5.10 Akış Diyagramı 1.4 Olağan Dışı Durum Çözümleme Olağan dışı durum, bir programın çalışmasının, geçersiz ya da yanlış veri oluşumu ya da başka nedenlerle istenmeyen bir biçimde sonlanmasına neden olan durum olarak tanımlanmaktadır. 5.5.1 Olağandışı Durum Tanımları Olağandışı gelişen durumlarda try-catch blokları devreye girecek ve program kırılmadan çalışmasına devam edebilecek şekilde tasarladık. 70 5.5.2 Farklı Olağandışı Durum Çözümleme Yaklaşımları Tüm olağan dışı durumlarda program kırılmadan hata mesajlarıyla tekrar başa dönecek şekilde tasarladık. Şekil 5.11 Olağan Dışı Halde Yapılacaklar 1.5 Kod Gözden Geçirme Hiç kimse, önceki sürümlerini gözden geçirmeden ve incelemeden okunabilir bir program yazamaz. Hiçbir yazı editörün onayını almadan basılamayacağı gibi hiçbir program da incelenmeden, gözden geçirilmeden işletime alınmamalıdır. Kod gözden geçirme ile program sınama işlemlerini birbirinden ayırmak gerekir. Program sınama, programın işletimi sırasında ortaya çıkabilecek yanlış ya da hataları yakalamak amacıyla yapılır. Kod gözden geçirme işlemi ise, programın kaynak kodu üzerinde yapılan bir incelemedir. Kod gözden geçirmelerinde program hatalarının %3-5 oranındaki kesimi yakalanabilmektedir. Eğer programı yazan kişi, yazdığı programın hemen sonra bir "kod inceleme" sürecine girdi olacağını bilerek program yazdığında daha etkin, az hatalı ve okunabilir programlar elde edilebilmektedir. 5.6.1 Gözden Geçirme Sürecinin Düzenlenmesi Gözden geçirme sürecinin temel özellikleri; Hataların bulunması, ancak düzeltilmemesi hedeflenir, Olabildiğince küçük bir grup tarafından yapılmalıdır. En iyi durum deneyimli bir inceleyici kullanılmasıdır. Birden fazla kişi gerektiğinde, bu kişilerin, ileride program bakımı yapacak ekipten seçilmesinde yarar vardır. Kalite çalışmalarının bir parçası olarak ele alınmalı ve sonuçlar düzenli ve belirlenen bir biçimde saklanmalıdır. biçiminde özetlenebilir. Burada yanıtı aranan temel soru, programın yazıldığı gibi çalışıp çalışmayacağının belirlenmesidir. 71 5.6.2 Gözden Geçirme Sırasında Kullanılacak Sorular Bir program incelenirken, programın her bir öbeği (yordam ya da işlev) aşağıdaki soruların yanıtları aranır. Bu sorulara ek sorular eklenebilir. Bazı soruların yanıtlarının "hayır" olması programın reddedileceği anlamına gelmemelidir. 5.6.2.1 Öbek Arayüzü Oluşturduğumuz öbekleri test etmek için belli sorular sorduk bu sorular: Her öbek tek bir işlevsel amacı yerine getiriyor mu? Öbek adı, işlevini açıklayacak biçimde anlamlı olarak verilmiş mi? Öbek tek giriş ve tek çıkışlı mı? Öbek eğer bir işlev ise, parametrelerinin değerini değiştiriyor mu? Şeklinde oldu. 5.6.2.2 Giriş Açıklamaları Oluşturduğumuz giriş açıklamalarını test etmek için belli sorular sorduk bu sorular: Öbek, doğru biçimde giriş açıklama satırları içeriyor mu? Giriş açıklama satırları, öbeğin amacını açıklıyor mu? Giriş açıklama satırları, parametreleri, küresel değişkenleri içeren girdileri ve kütükleri tanıtıyor mu? Giriş açıklama satırları, çıktıları (parametre, kütük vb) ve hata iletilerini tanımlıyor mu? Giriş açıklama satırları, öbeğin algoritma tanımını içeriyor mu? Giriş açıklama satırları, öbekte yapılan değişikliklere ilişkin tanımlamaları içeriyor mu? Giriş açıklama satırları, öbekteki olağan dışı durumları tanımlıyor mu? Giriş açıklama satırları, Öbeği yazan kişi ve yazıldığı tarih ile ilgili bilgileri içeriyor mu? Her paragrafı açıklayan kısa açıklamalar var mı? Şeklinde oldu. 72 5.6.2.3 Veri Kullanımı Oluşturduğumuz veri kullanımlarını test etmek için belli sorular sorduk bu sorular: İşlevsel olarak ilintili bulunan veri elemanları uygun bir mantıksal veri yapısı içinde gruplanmış mı? Değişken adları,işlevlerini yansıtacak biçimde anlamlı mı? Değişkenlerin kullanımları arasındaki uzaklık anlamlı mı? Her değişken tek bir amaçla mı kullanılıyor? Dizin değişkenleri kullanıldıkları dizinin sınırları içerisinde mi tanımlanmış? Tanımlanan her gösterge değişkeni için bellek ataması yapılmış mı? Şeklinde oldu. 5.6.2.4 Öbeğin Düzenlenişi Modüller birleşimi uyumlumu? Modüller arası veri aktarımları sağlanıyor mu? Bütün modüller birleştiğinde sistem çalışıyor mu? Gözden geçirme sırasında referans alınacak sorular olacaktır. 5.6.2.5 Sunuş Artık son kısma gelindiğinde ise şu sorular soruldu: Her satır, en fazla bir deyim içeriyor mu? Bir deyimin birden fazla satıra taşması durumunda, bölünme anlaşılabilirliği kolaylaştıracak biçimde anlamlı mı? Koşullu deyimlerde kullanılan mantıksal işlemler yalın mı? Bütün deyimlerde, karmaşıklığı azaltacak şekilde parantezler kullanılmış mı? Bütün deyimler, belirlenen program stiline uygun olarak yazılmış mı? Öbek yapısı içerisinde akıllı "programlama hileleri" kullanılmış mı? 73 6. DOĞRULAMA VE GEÇERLEME 6.1. Giriş Geliştirilecek bilgi sistemi yazılımının doğrulanması ve geçerlenmesi, üretim süreci boyunca süren etkinliklerden oluşur. Söz konusu etkinlikler: Yazılım belirtimlerinin ve proje yaşam sürecindeki her bir etkinlik sonunda alınan çıktıların, tamam, doğru, açık ve önceki belirtimleri tutarlı olarak betimler durumda olduğunun doğrulanması. Proje süresince her bir etkinlik ürününün teknik yeterliliğinin değerlendirilmesi ve uygun çözüm elde edilene kadar aktivitenin tekrarına sebep olması. Projenin bir aşaması süresince geliştirilen anahtar belirtimlerin önceki belirtimlerle karşılaştırılması. Yazılım ürünlerinin tüm uygulanabilir gerekleri sağladığının gerçeklenmesi için sınamaların hazırlanıp yürütülmesi biçiminde özetlenebilir. Şekil 6.1 Doğrulama Geçerleme 6.2. Sınama Kavramları Birim Sınama: Sistemin birimleri olan YSK-YSK il-YSK İlçe-Sandık Kurulu-Seçmen sırasıyla kendi içlerinde birimleri sınandı ve sonuçları çıkartıldı. Alt Sistem Sınama: Birimlerin birleşmesiyle modüller oluşturulup bunların kendi içinde sınaması yapıldı. Genel olarak arayüzde ki eksiklikler giderildi. 74 Sistem Sınama: Sistemin bütün olarak sınanması yapıldı ve programın eksiksiz olduğu onaylandı. Kabul Sınama: Sistem prototipten çıkartılıp gerçek veriler girildi ve sorunsuz olduğu bir kez daha onaylandı. 6.3. Doğrulama ve Geçerleme Yaşam Döngüsü Şekil 6.2 Yaşam Döngüsü 6.4. Sınama Yöntemleri Sınama işlemi, geliştirmeyi izleyen bir düzeltme görevi olmak ile sınırlı değildir. Bir "sonra" operasyonu olmaktan çok, geliştirme öncesinde planlanan ve tasarımı yapılması gereken bir çaba türüdür. 6.4.1 Beyaz Kutu Sınaması Denetimler arasında: Bütün bağımsız yolların en azından bir kere sınanması, Bütün mantıksal karar noktalarında iki değişik karar için sınamaların yapılması, Bütün döngülerin sınır değerlerinde sınanması, İç veri yapılarının denenmesi yapıldı. 75 Şekil 6.3 Beyaz Kutu Sınaması 6.4.2 Temel Yollar Sınaması Şekil 6.5 Sınama Şekli 76 6.5. Sınama ve Bütünleştirme Stratejileri Genellikle sınama stratejisi, bütünleştirme stratejisi ile birlikte değerlendirilir. Ancak bazı sınama stratejileri bütünleştirme dışındaki tasaları hedefleyebilir. Örneğin, yukarıdan aşağı ve aşağıdan yukarı stratejileri bütünleştirme yöntemine bağımlıdır. Ancak işlem yolu ve gerilim sınamaları, sistemin olaylar karşısında değişik işlem sıralandırmaları sonucunda ulaşacağı sonuçların doğruluğunu ve normal şartların üstünde zorlandığında dayanıklılık sınırını ortaya çıkarır. 6.5.1 Yukarıdan Aşağı Sınama ve Bütünleştirme Yukarıdan aşağı bütünleştirmede, önce sistemin en üst düzeylerinin sınanması ve sonra aşağıya doğru olan düzeyleri, ilgili modüllerin takılarak sınanmaları söz konusudur. En üst noktadaki bileşen, bir birim/modül/alt sistem olarak sınandıktan sonra alt düzeye geçilmelidir. Ancak bu en üstteki bileşenin tam olarak sınanması için alttaki bileşenlerle olan bağlantılarının da çalışması gerekir. Genel hatlarıyla özetlemek gerekirse şu mantıkla sitem sınaması yapıldı. Şekil 6.6 Yukarıdan Aşağı Sınama 6.5.2 Aşağıdan Yukarıya Sınama ve Bütünleştirme Aşağıdan yukarı bütünleştirmede ise, önceki yöntemin tersine uygulama yapılır. Önce en alt düzeydeki işçi birimleri sınanır ve bir üstteki birimle sınama edilmesi gerektiğinde bu üst bileşen, bir 'sürücü' ile temsil edilir. Yine amaç, çalışmasa bile arayüz oluşturacak ve alt bileşenin sınanmasını sağlayacak bir birim edinmektir. Fakat bu sınama sistemi kullanılmadı. 77 Şekil 6.7 Aşağıdan Yukarı Bütünleştirme 6.6. Sınama Planlaması Bir tablo ile özetlemek gerekirse şu şekilde özetleyebiliriz. Test raporu hazırlanırken şu özellikler mutlaka planda belirtilmelidir; Test planı kimliği: Test planının adı veya belge numarası Giriş: Test edilecek yazılımın elemanlarının genel tanıtım özetleri. Ayrıca bu plan kapsamı ve başvurulan belgeler. Kısaltmalar ve terim açıklamaları bu bölümde bildirilmelidir. Test edilecek sistem: Sistemde bileşenleri sürüm sayıları olarak sıralar ve sistemin özelliklerini bileşenlerini ve nasıl kullanıldıkları açıklanmalıdır. Ayrıca sistemde test edilmeyecek parçalar belirtilmelidir. Test edilecek ana fonksiyonlar: Sistemin test edilecek ana fonksiyonlarının kısa bir tanıtımı yapılmalıdır. Test edilmeyecek ana fonksiyonlar: Sistemde test edilmeyecek fonksiyonları ve bunların neden test edilmedikleri açıklanacaktır. Geçti/Kaldı Kriterleri: Bir test sonucunda sistemin geçmiş veya kalmış sayılacağını açıklanmalıdır. Test dokümanı: Test süresince yapılan işlemleri alınan raporları elde edilen bilgileri rapor içinde sunulmalıdır. Sorumluluklar: Hangi kişilerin nelerden sorumlu olduğu ve test takım lideri bilgileri mutlaka raporda belirtilmelidir. Riskler ve Önlemler: Test planında varsayılan ve olası yüksek riskli durumları belirtir ve bu durumların olması durumunda, etkilerinin en aza indirilebilmesi için alınması gereken 78 önlemleri açıklar. 6.7. Sınama Belirtimleri Sınama belirtimleri, bir sınama işleminin nasıl yapılacağına ilişkin ayrıntıları içerir. 79 Sınama verilerinin elle hazırlanması çoğu zaman kolay olmayabilir ve zaman alıcı olabilir. Bu durumda, otomatik sınama verisi üreten programlardan yararlanılabilir. Sınama senaryoları, yeni sınama senaryosu üretebilmeye yardımcı olacak biçimde hazırlanmalıdır. Zira sınama belirtimlerinin hazırlanmasındaki temel maç, etkin sınama yapılması için bir rehber oluşturmas Sınama raporları, sınama bitiminde imzalanır ve yüklenici ile iş sahibi arasında resmi belge niteliği oluşturur. 6.8. Yaşam Döngüsü Boyunca Sınama Etkinlikleri Bütün bu etkinlikleri bir hiyerarşi altında incelemek gerekirse: Planlama aşamasında genel planlama sınaması gerçekleştirilir. Bu olan tüm planların basit bir ön hazırlığı niteliğindedir. Çözümleme aşamasında sınama planı alt sistemler bazında ayrıntılandırılır. Tasarım aşamasında sınama plana detaylandırılır ve sınama belirtimleri oluşturulur. Bu oluşumlar daha sonra eğitim ve el kitabında kullanılır. Gerçekleştirim aşamasında teknik sınamalar yapılır sınama raporları hazırlanır ve elle tutulur ilk testler yapılır. Kurulum aşamasında sistemle ilgili son sınamalar yapılır ve sınama raporları hazırlanır. 80 Şekil 6.8 Sınama Etkinlikleri Bu ayrıtılar temel olarak: sınanan program modülü ya da modüllerinin adları, sınama türü, stratejisi (beyaz kutu, temel yollar vb.), sınama verileri, sınama senaryoları türündeki bilgileri içerir. Sınama sırasında bulunan her hata için, değişiklik kontrol sistemine (DKS), "Yazılım Değişiklik İsteği" türünde bir kayıt girilir. Hatalar, DKS kayıtlarında aşağıdaki gibi gruplara ayrılabilir: • • • • Onulmaz Hatalar: BT projesinin gidişini bir ya da birden fazla aşama gerileten ya da düzeltilmesi mümkün olmayan hatalardır. Büyük Hatalar: Projenin kritik yolunu etkileyen ve önemli düzeltme gerektiren hatalardır. Küçük Hatalar: Projeyi engellemeyen, ve giderilmesi az çaba gerektiren hatalardır. Şekilsel Hatalar: Heceleme hatası gibi önemsiz hatalardır. 81 Şekil 6.9-10 Gerçekleştirme aşama ve tarihleri diyagramlar 7.BAKIM 7.1 Giriş Sistemin tasarımı bittikten sonra artık seçimden seçime sistemin bakıma sokulması gerekir daha öncede belirttiğimiz gibi sistem hassas ve hata kabul etmeyecek bir sistemden bahsediyoruz. Bakım bölümüne ilişkin yapılan açıklamalarda IEEE 1219-1998 standardı baz olarak alınmıştır. 82 Değerlendirme İseği Bakım Kontrolcüsü Değerlendirme Sonucu Teknik Danışman Bakım İsteği Değişiklik Önerisi İsteğin reddi Değişiklik Kontrol Kurulu Değişiklik onayı ve görevlendirme Değişiklik Sorumlusu Kullanıcı İş Planı Son Sürüm Yeni Sürüm Bakım Personeli Düzenleşim Yönetimi Yeni Sürüm Teslim Personeli Şekil 7.1 Bakım Aşaması 7.2 Kurulum Sistem kurulumuna değinmek gerekirse devlet güvencesinde verilecek olan serverlara yüklenecek olan sistemimizde FTP arayüzü ile dosyaları servera aktaracağız ve internet explorer olan tüm cihazlarda çalışacak. 83 7.3 Yerinde Destek Organizasyonu Bu konuyla ilgili pilot bölgede bizzat desteği ben vereceğim bunun yanında sistem canlandırılıp gerçeğe geçirilirse sistem tanımlaması kurulum için bölgelerde bayilik sistemi gibi alt kuruluşlara yetki verilecek eğer profesyonel destek istenirse yol uçak masrafını karşılamak şartıyla bölgeye yetkili gönderilip orada bir organizasyon yapılacaktır. 7.4 Yazılım Bakımı Değişim isteği Sözleşme Destek Ekibi Kullanıcılar Hizmet İsteği Satıcı Yeni Arabirim Düzenleme Süreci Şekil 7.2 Bakım Aşaması 7.4.1 Tanım Şekil 7.3 Bakım Çeşitleri 7.4.2 Bakım Süreç Modeli Aslına bakmak gerekirse bakım süreç modeli yukardaki yapılan işlemlerin tümünün baştan yapılması demek bunları adım adım bir inceleyelim. 84 Şekil 7.4 Bakım Süreç Modeli 1. Adım: Sorunu Tanımlama Süreci İlk önce bakım ne için yapılıyor sorun ne buna bir bakalım. Şekil 7.5 Sorun Tanımlama 2. Adım: Çözümleme Süreci Sorun tanımlamadan çıkan karar doğrultusunda problemi kâğıt üzerinde çözelim. 85 Şekil 7.6 Çözümleme Süreci 3. Adım: Tasarım Süreci Çözümlenen sistem sonucunda tasarımı güncelleştirmeye geldi sıra. Şekil 7.7 Tasarım Süreci 4. Adım: Gerçekleştirim Süreci Tasarımı yapılan sistemin gerçekleştirmesine sıra geldi. 86 Şekil 7.8 Gerçekleştirim Süreci 5. Adım: Sistem Sınama Süreci Artık tekrardan tasarlanan sistemin sınama sürecini tekrar ele almak gerekiyor. Şekil 7.9 Sınama Süreci 87 6. Adım: Kabul Sınaması Süreci Kendi içimizde sınadığımız sistemi birde müşteri karşısında sınıyoruz. Şekil 7.10 Kabul Sınama Süreci 7. Adım: Kurulum Süreci Kabul sınamasını geçen sistemimiz artık tekrardan kurulum aşamasına geçiyor. 7.11 Şekil Kurulum Süreci 88 Sonuç olarak sistem hayata geçirildiği zaman neler değişeceği gözler önüne serdik. Bunun yanı sırabasit ama bir o kadarda güvenli olan bu sistemle ek masraflar ortadan kalkacak hataları ortadan kaldırılacak ve adil bir imza sistemi gerçekleştirilmiş olacak. Hem personel için hem yetkililer için oturdukları yerden işletebilecekleri bu sistem sayesinde artık eskisi kadar yorulmayacak ve herkes bu sisteme minnettar kalacak. Kurumumuz içinde iyi bir referans olacak olan bu sistem sayesinde hem biz hem kullanıcılar için çok güzel olacak. Bu zorlu süreç boyunca bize destek olan herkese bir kez daha teşekkürlerimi iletiyorum. 89 [1] G. Eason, B. Noble, and I. N. Sneddon, “On certain integrals of Lipschitz-Hankel type involving products of Bessel functions,” Phil. Trans. Roy. Soc. London, vol. A247, pp. 529– 551, April 1955. (references) [2] J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68–73. [3] I. S. Jacobs and C. P. Bean, “Fine particles, thin films and exchange anisotropy,” in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New York: Academic, 1963, pp. 271–350. [4] K. Elissa, “Title of paper if known,” unpublished. [5] R. Nicole, “Title of paper with only first word capitalized,” J. Name Stand. Abbrev., in press. [6] Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, “Electron spectroscopy studies on magnetooptical media and plastic substrate interface,” IEEE Transl. J. Magn. Japan, vol. 2, pp. 740– 741, August 1987 [Digests 9th Annual Conf. Magnetics Japan, p. 301, 1982]. [7] M. Young, The Technical Writer's Handbook. Mill Valley, CA: University İnternet kaynakları 1-http://www.fao.org., (25.03.2011) 2-www.atsdr.cdc.gov., (03.06.2010) 3-http://en.wikipedia.org/wiki/File:4-Hydroxybenzoic_acid.svg, (07.12.2011) 90
