1

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

2

İÇİ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 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

3.2 Gereksenen Sistemin Mantıksal Modeli……………………………………………………………………36

3.2.1 Giriş……………………………………………………………………………………………………………………………..36

3.2.2 İşlevsel Model………………………………………………………………………………………………………………36

3.2.3 Genel Bakış……………………………………………………………………………………………………………………37

3

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

3.3 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

3.4 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

4

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

5

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

6

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

7

ÖNSÖZ

8

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.

9

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.

10

Ş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.

11

Ş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ı

12

Ş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.

13

Maliyet Kestirim Dökümanı

Proje adı : Fırat Üniversitesi Elektronik İmza Sistemi

Ölçüm Parametresi Sayı Ağırlık Toplam

Kullanıcı Girdi Sayısı 4 3 12

Kullanıcı Çıktı Sayısı 4 4 16

Kullanıcı Sorgu Sayısı 6 3 18

Kütük Sayısı 12 7 84

Dışsal Arayüz Sayısı 13 5 65

Ana İşlev Nokta Sayısı 401

Teknik Karmaşıklık Sorusu Puan

1. Uygulama, güvenilir yedekleme ve kurtarma gerektiriyor mu? 5

2. Veri iletişimi gerekiyor mu? 5

3. Dağıtık işlem işlevleri var mı? 5

4. Performans kritik mi? 4

5. Sistem mevcut ve ağır yükü olan bir işletim ortamında mı

çalışacak?

1

6. Sistem, çevrim içi veri girişi gerektiriyor mu? 5

7. Çevrim içi veri girişi, bir ara işlem için birden çok ekran gerektiriyor

mu?

0

8. Ana kütükler çevrim-içi olarak mı günleniyor? 5

9. Girdiler, çıktılar, kütükler ya da sorgular karmaşık mı? 3

10. İçsel işlemler karmaşık mı? 2

11. Tasarlanacak kod, yeniden kullanılabilir mi olacak? 3

12. Dönüştürme ve kurulum, tasarımda dikkate alınacak mı? 1

13. Sistem birden çok yerde yerleşik farklı kurumlar için mi

geliştiriliyor?

5

14. Tasarlanan uygulama, kolay kullanılabilir ve kullanıcı tarafından

kolayca değiştirilebilir mi olacak?

1

TOPLAM 60

0: Hiçbir Etkisi Yok

1: Çok Az etkisi var 2: Etkisi Var 3: Ortalama Etkisi Var

4: Önemli Etkisi Var 5: 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

14

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)

15

2.3 Proje Zaman-İş Planı

Şekil 2.6 Proje İş-Zaman Çizelgesi

2.4 Proje Ekip Yapısı

Şekil 2.6 Proje Ekibi

16

Ş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.

17

Çö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ı

• PHP

• MYSQL

• Action Script 2.0(Flash)

• HTML

• JAVA

• XML

Sınama Araçları

• Mozilla Firefox 11

• Google Chrome17

• Internet Explorer 9

• Safari 5

Destek Araçlar

• Microsoft Windows 7

• Iphone OS'X

• Android

Şekil 2.8 E-imzada Kullanılan Akıllı Kart

2.6 Kullanılan Özel Geliştirme Araçları ve Ortamları

18

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.

19

Ş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.

20

Ş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.

21

Şekil 2.13 Kullanıcı Değerlendirme Aşaması

Şekil 2.13 Ekip Yapısı Zaman Planı

22

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

23

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.

24

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ı

25

Eğitimlerin zamana göre çizelgesi;

Tablo 2.2 Proje Eğitim Planı

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;

Başlama Tarihi Bitiş Tarihi Uğur Gürtürk

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

26

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.

2.13 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ı

27

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 , E-

SERTİ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

28

3.1.2 İşlevsel Model

Şekil 3.2 Use-Case Diyagramı

Şekil 3.3 Basit Bir Use-Case

29

Ş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

USER

Şekil 3.5 Sistem Veri Modeli

NO KULLANICI NO()

BÖLÜM NO()

ADI

NUMARA

Admin1

Dosya Belirlenir

Admin2’ye Gönderir.

Admin2

Yönetici görevlendirmesine göre çalışırlar.

İmzalanacak Veriyi Gerekli Yere Gönderir.

İmza Doğrulama İşlemine Ortam Hazırlar.

Sistem Düzenleyiciler

Bu Görev Yönetici

Görevindeki Admin1’e

Aittir.

Kullanıcılar

İmzalama

Yapan

görevliler

Değerlendiriciler

İmza Doğrulaması

Yapar

30

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

31

Şekil 3.6 İmza Doğrulama Ve Veri Transferi

32

Şekil 3.7 Elektronik Sertifika Oluşturma

Şekil 3.8 Sertifika Başvuru Sistemi

33

Şekil 3.9 Sertifika Başvuru İşlemi Ve Giriş Seçimi

34

Ş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

35

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 Dosya paylaşımı

Aktör başlatılıyor Admin1

Aktör Katılımcı Admin2

Giriş Durumu Rektörlüğe Bağlı Admin1 Giriş Yapmış

Olayların akışı 1. Admin1 Dosya seçmesi

2. Seçtiği Dosyayı Admin2’ye gönder

Durum çıkışı Evrak Paylaşımı ve İmza Doğrulama başarılı ise mesaj vermesi

36

Durum İsmi Gelen Dosyayı Onayla

Aktör başlatılıyor Admin1

Aktör Katılımcı Admin2

Giriş Durumu Admin1 Giriş Yapmış

Olayların akışı 1.Adminin dosyayı onaylaması

Durum çıkışı Onaylama başarılı ise mesaj vermesi

Durum İsmi Resmi Açıklama Yapar

Aktör başlatılıyor Admin1

Aktör Katılımcı Admin2

Giriş Durumu Admin1 Giriş Yapmış

Olayların akışı 1. Admin2 den işlem sonuçlarının gelmesi

2. Admin1 kamuya sonuçları açıklaması

Durum çıkışı İşlemler doğru ise mesaj vermesi

Durum İsmi Kullanıcıdan Gelen Dosyayı Onayla

Aktör başlatılıyor Admin1

Aktör Katılımcı Admin2

Giriş Durumu Admin1 Giriş Yapmış

Olayların akışı Admin1 in dosyayı onaylaması

Durum çıkışı Onaylama başarılı ise mesaj vermesi

Durum İsmi Arşiv Oluştur

Aktör başlatılıyor Admin1

Aktör Katılımcı Admin2

Giriş Durumu Admin1 Giriş Yapmış

Olayların akışı Arşiv kurullarını oluşturması

Durum çıkışı 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 dos-

ya,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

37

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

38

3.2.5 Veri Modeli

Şekil 3.14 Veri Modeli

39

Şekil 3.15 Bazı İşleyiş Diyagramları

Şekil 3.16 İmza-Kullanıcı

40

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.

41

Şekil 3.17 Bazı İşleyiş Diyagramları

Şekil 3.18 Aktivite Diyagramları

42

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.

43

Ş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.

44

Ş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.

45

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.

46

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.

47

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ı

48

Dosya içeriğinin gizli tutulması

4.1.3 Sistem Mimarisi

Şekil 4.3 Genel Sistem Mimarisi

49

Ş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ın-

da 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.

50

Ş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ı

51

Islemler VeriTabanı

«uses»

Ekleme Islmeleri

Güncelleme İslemleri

Silme Islemleri

Listeleme Islemleri

«bind»

«bind»

«bind»

«bind»

«uses»«uses»

«uses»

«uses»

Ş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

52

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ı

53

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.

54

Şekil 4.10 Giriş Sayfası Modülleri

55

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

56

Ş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

57

ş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 .

58

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ı.

59

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. Geçmişe yönelik verilerin zaman bilgilerini de içerecek şekilde elde edilerek

yazılım geliştirme sürecine dâhil etmek.

5. 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.

6. Güvenilirlik tahminleme modelinin seçilmesini sağlamak.

7. Güvenilirlik modeli tarafından kullanılacak olan parametrelerini tespit etmek.

8. Verilen bir noktayı kullanarak gelecekteki olası hatalar hakkında tahmin

yapmak.

9. Tahmin edilen hata ve arıza oranları ile gerçekleşen değerleri kıyaslamak.

60

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.

61

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ı

62

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

63

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

64

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.

65

Kullanıcı

Admin User

«uses» «uses»

Ş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ı

66

ş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:

67

Ş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.

68

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ığı

69

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)

70

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.

71

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.

72

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.

73

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ı?

74

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.

75

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ı.

76

Şekil 6.3 Beyaz Kutu Sınaması

6.4.2 Temel Yollar Sınaması

Şekil 6.5 Sınama Şekli

77

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ı.

78

Ş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

79

ö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.

80

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.

81

Ş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.

82

Ş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.

83

Bakım Kontrolcüsü

TeknikDanışman

Değişiklik Kontrol Kurulu

DeğişiklikSorumlusu

Kullanıcı

BakımPersoneli

Düzenleşim Yönetimi

Teslim Personeli

Değerlendirme İseği

Değerlendirme Sonucu

Değişiklik Önerisi

Değişiklik onayı ve görevlendirme

Son Sürüm

Yeni Sürüm

Yeni Sürüm

Bakım İsteği

İsteğin reddi

İş Planı

Ş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.

84

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ı

KullanıcılarDestek Ekibi

Değişim isteği

Sözleşme

Hizmet İsteği

Satıcı Düzenleme SüreciYeni Arabirim

Ş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.

85

Ş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.

86

Ş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.

87

Ş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

88

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

89

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.

90

[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 magneto-

optical 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)