Kataloğu Gör

Transkript

Kataloğu Gör

T.C
FIRAT ÜNĠVERSĠTESĠ
TEKNOLOJĠ FAKÜLTESĠ
YAZILIM MÜHENDĠSLĠĞĠ BÖLÜMÜ
TAġIT TANIMA SĠSTEMĠ
YAZILIM MÜHENDĠSLĠĞĠ TEMELLERĠ DERSĠ DÖNEM PROJESĠ
Hazırlayan
13542004
Metin ACUN
Taşıt Tanıma Sistemi
Sayfa 1
ÖNSÖZ
Sayfa 2
ĠÇĠNDEKĠLER
1.GĠRĠġ
1.1 Projenin Amacı....................................................................................................7
1.2 Projenin Kapsamı.................................................................................................8
1.3 Tanımlamalar ve Kısaltmalar...............................................................................9
2.PROJE PLANI
2.1 GiriĢ....................................................................................................................10
2.2 Projenin Plan Kapsamı.......................................................................................11
2.3 Proje Zaman - ĠĢ Planı........................................................................................12
2.4 Proje Ekip Yapısı...............................................................................................13
2.5 Önerilen Sistemin Teknik Tanımları.................................................................14
2.6 Kullanılan Özel GeliĢtirme Araçları ve Ortamları.............................................12
2.7 Proje Standartları, Yöntem Metodolojiler..........................................................13
2.8 Kalite Sağlama Planı..........................................................................................14
2.9 Konfigürasyon Yönetim Planı...........................................................................12
2.10 Kaynak Yönetim Planı.....................................................................................13
2.11 Eğitim Planı.....................................................................................................14
2.12 Test Planı.........................................................................................................13
2.13Bakım Planı......................................................................................................14
3.SĠSTEM ÇÖZÜMLEME
3.1 Mevcut Sistem Ġncelemesi...............................................................................20
3.1.1 Örgüt Yapısı..............................................................................................20
3.1.2 ĠĢlevsel Model............................................................................................21
3.1.3 Veri Modeli................................................................................................22
3.1.4 Var Olan Yazılım / Donanım Kaynakları..................................................23
3.1.5 Var Olan Sistemin Değerlendirilmesi........................................................24
3.2 Gereksenen Sistemin Mantıksal Modeli........................................................25
3.2.1 GiriĢ...........................................................................................................20
3.2.2 ĠĢlevsel Model............................................................................................21
3.2.3 Genel BakıĢ................................................................................................22
3.2.4 Bilgi Sistemleri/Nesneler...........................................................................23
3.2.5 Veri Modeli................................................................................................20
3.2.6 Veri Sözlüğü..............................................................................................21
3.2.7 ĠĢlevlerin Sıradüzeni..................................................................................22
Sayfa 3
3.2.8 BaĢarım Gerekleri......................................................................................23
3.3 Arayüz (Modül) Gerekleri..............................................................................25
3.3.1 Yazılım Arayüzü........................................................................................20
3.3.2 Kullanıcı Arayüzü......................................................................................21
3.3.3 ĠletiĢim Arayüzü........................................................................................22
3.3.4 Yönetim Arayüzü......................................................................................23
3.4 Belgeleme Gerekleri.........................................................................................25
3.4.1 GeliĢtirme Sürecinin Belgelenmesi...........................................................20
3.4.2 Eğitim Belgeleri.........................................................................................21
3.4.3 Kullanıcı El Kitapları.................................................................................22
4.SĠSTEM TASARIMI
4.1 Arayüz (Modül) Gerekleri..............................................................................25
4.1.1 Genel Sistem Tanımı.................................................................................20
4.1.2 Varsayımlar ve Kısıtlamalar......................................................................21
4.1.3 Sistem Mimarisi.........................................................................................22
4.1.4 DıĢ Arabirimler..........................................................................................23
Sayfa 4
Sayfa 5
Sayfa 6
1.GĠRĠġ
1.1 Projenin Amacı
ġirket aracınıza, istasyonlardan otomatik olarak, nakit kullanmadan ve faturaya
gerek kalmadan yakıt almanızı sağlayan, dolum bilgilerini ve isteğe bağlı olarak
taĢıt tüketim bilgilerini elektronik ortamda raporlayan bir sistemdir.
Filo sahibinin, ister filo bazında, isterse de araç bazında tanımlanabilecek olan
birçok değiĢik limitlime parametresi sayesinde tüm akaryakıt tüketimi tam olarak
kontrol altına almasını sağlayan bir filo yönetim sistemidir.
Sistem, aynı zamanda taĢıtların kilometre takibini basit ve güvenli olarak yakıt alım
anındaki zamana göre takip eder. Her 10 günde bir gönderilen raporlarla, hangi
taĢıtın hangi istasyonda, ne zaman, ne kadar, hangi km'de, ne cins yakıt aldığını
bildirir. TaĢıtların Lt/km değerlerini her ay raporlar.
1.2 Projenin Kapsamı
1.3 Tanımlamalar ve Kısaltmalar
TaĢıt Tanıma Sistemi (TTS) : ġirket araçlarınızın, monte edilen ekipmanlar
sayesinde anlaĢmalı olduğunuz petrol Ģirketinin Türkiye'nin her köĢesindeki taĢıt
tanıma hizmeti veren tüm istasyonlarından, otomatik olarak sürücü ve pompa satıĢ
görevlisinden bağımsız ve güvenli yakıt almasını sağlar.
Radyo Frekansı ile Tanımlama (RFID) : Teknolojisi , radyo frekansı
kullanarak nesneleri tekil ve otomatik olarak tanıma yöntemidir. RFID, temel
olarak bir etiket ve okuyucudan meydana gelir. RFID etiketleri Elektronik Ürün
Kodu (EPC) gibi nesne bilgilerini almak, saklamak ve göndermek için
Sayfa 7
programlanabilirler. Ürün üzerine yerleĢtirilen etiketlerin okuyucu tarafından
okunmasıyla tedarik zinciri yönetimi ile ilgili bilgiler otomatik olarak
kaydedilebilir veya değiĢtirilebilir.
Datapass : Aracın canbus sisteminden kilometre, yakıt, motor sıcaklığı, hız,
rolantide bekleme süresi, ilave güç çıkıĢlarının çalıĢma süre bilgilerini alır.RFID
teknolojisi ile kablosuz olarak sisteme aktarır.
FuelOpass ID Sticker : YapıĢkan özelliği sayesinde montajı kolaydır.Aracın
depo ağzına monte edilir.Yetkisiz müdahale durumunda yırtılarak etkisiz hale
gelir.FuelOpass ID Sticker dolum sırasında pompa üzerindeki nozzle okuyucularla
RFID teknolojisi ile kablosuz olarak iletiĢim kurar ve cihazdaki bilgileri sisteme
aktarır.
FuelOpass ID Chip : Aracın depo ağzına monte edilir. Chip bölümü vidalanır ve
epoxy ile araca yapıĢtırılır. Yetkisiz müdahale durumunda kırılarak etkisiz hale
gelir. FuelOpass ID Chip dolum sırasında pompa üzerindeki nozzle okuyucularla
RFID teknolojisi ile kablosuz olarak iletiĢim kurar ve cihazdaki bilgileri sisteme
aktarır.
Kablosuz Tabanca Okuyucu :Bu ekipman araç üzerinde monte edilmiĢ RFID
taĢıt kimlik ünitesinden bilgileri algılar. Tabanca depodan uzaklaĢınca yakıt
dolumunu durdurur.
Master Kablosuz Okuyucu (MWGT) : MWGT, wireless tabanca okuyucu ile
haberleĢerek araç üzerindeki RFID depo anteninden ve Canpass' tan araç ile ilgili
bilgileri alır ve otomasyon sistemine iletir.
Kısaltmalar
 TTS = TaĢıt Tanıma Sistemi
 RFID = Radyo Frekans ile Tanımlama
 MWGT = Master Kablosuz Okuyucu
Sayfa 8
2.PROJE PLANI
2.1 GiriĢ
Kurumunuza ait araçların akaryakıt harcamalarını yönetebilmenize ve güvenli
bir Ģekilde araca dolum yapılabilmesine imkan veren elektronik ödeme sistemi ve
optimize akaryakıt istasyon ağıdır.
2.2 Projenin Plan Kapsamı
 Aracınıza pratik ve hızlı akaryakıt ikmali sağlar.
 Ödeme kolaylığı sağlar.
 Muhasebede kolaylık sağlar.
 Kilometre / Litre takibi sağlar.
 Akaryakıt giderleri üzerinde tam ve detaylı bir kontrol sağlanıp,
olabilecek kayıplar engellenir.
 Filonuzun akaryakıt alımını 24 saat beklemeden anında kontrol
edebilme imkanı sağlar.
 Araçları Departman bazında gruplayıp, bu gruptaki araçlar için geçerli
standart limitler uygulanabilme imkanı sağlar.
 Miktar (Lt) veya Tutar (TL) bazında;
a.Günlük, (6 farklı zaman dilimi için ayrı limit giriĢine imkan
verilmektedir),
b.Haftalık,
c.Aylık,
d.Yıllık,e.Bayram ve Tatil Günleri (YılbaĢı, Kurban Bayramı, vs.)
için Gün/Saat Kısıtları oluĢturabilme imkanı sağlar.
Sayfa 9
2.3 Proje Zaman - ĠĢ Planı
Sayfa 10
2.4 Proje Ekip Yapısı
Proje Yöneticisi:
Metin ACUN
Sistem Yöneticisi:
Metin ACUN
Sistem Tasarım:
Eleman 1
Teknik Destek
Birimi
Donanım Uzmanı:
Eleman 1
Kalite Uzmanı:
Eleman 2
Yazılım Üretim
Birimi
Proje Ofisi:
Eleman 3
Eğitim Birimi:
Sistem
Çözümleyici:
Eleman 4
Uygulama Destek
Birimi
Web Tasarımcısı:
Eleman 3
Ağ Uzmanı:
Programcı:
Eleman 1
Eleman 1
Veri Tabanı
Yöneticisİ:Eleman
4
Proje Yönetici (Metin ACUN) :
Projemizin yöneticisi projeyi planlamak, örgütlemek, yönetmek ve koordinasyonu
sağlayarak proje elemanlarının bir bütün içerisinde ve koordineli olarak çalıĢmalarını
takip etmektir.
Sistem Yöneticisi(Metin ACUN):
Sistem Yöneticisi, bir sistemin ihtiyaçlarını analiz ederek oluĢturulacak sistemi
tasarlayan, kuran, destekleyen, geliĢtiren, sürekliliğini ve güvenliğini sağlayan
kiĢidir.Bağlı olduğu üst yönetici/yöneticileri tarafından verilen diğer iĢleri ve
iĢlemleri yapmakla hükümlüdür.
Sayfa 11
Sistem Tasarımcı(Eleman 1)
Sistem çözümleyicinin tanımladığı gereksinimleri mantıksal, ekonomik ve pratik
Sistem tasarımlarına dönüĢtürerek ilgili programların yazılabilmesi için gerekli
ayrıntılı hazırlayan kiĢidir.
Kalite Uzmanı(Eleman 2) :
Kalite Uzmanı, ihtiyaçların ve geliĢtirilen çözümün doğru belirlenip
belirlenmediğini, proje ile ilgili standartları belirleme, proje kalite izleme ve denetim
planını hazırlamak, projenin amacına ve planına uygunluğunu proje yönetim birimine
sunmakla sorumlu olan kiĢidir.
Proje Ofisi(Eleman 3):
Proje ile ilgili her türlü yönetsel iĢlemlerden (yazıĢmalar, personel izleme,
görevlendirme vb.) sorumlu kiĢidir.
Sistem Çözümleme(Eleman 4):
Sistem Çözümleyici, temel olarak mevcut sistemin nasıl çalıĢtığını araĢtırır ve
mevcut sistemin incelenmesi sırasında temel hedef olarak gereksinimleri belirler,
önerilen sistem için modelleme yapan kiĢidir.
Donanım Uzmanı (Eleman 1):
Projenin yapım aĢamasında ilerlemesini sağlayan gerekli donanımları temin eden
birimdir. Projemiz içinde kayıtlı ve talep formu ile gelen bilgisayar ve çevre
birimlerinin bakım, onarım, ve sistem / fiziksel kurulumunu yapmak ve bunların
verimli bir Ģekilde kullanılması için gerekli çalıĢmaları yapmak, garanti kapsamındaki
ürünlerin yetkili servise gönderilmesini ve takibini sağlamak, bağlı olduğu proses ile
üst yönetici/yöneticileri tarafından verilen diğer iĢleri ve iĢlemleri yapan kiĢidir.
Sayfa 12
Ağ Uzmanı (Eleman 1):
Projede sistem ve network alt yapısının planlanmasını ve kurulumunu yapar. Sistem
ve network analiz, tasarım, test ve bakım iĢlemleriyle ilgilenir. Gelen ağ kurulum ve ip
telefon taleplerine, Bilgi ĠĢlem Dairesi BaĢkanlığı Hizmet Uygulama Esas ve Usulleri
’ne uygun olarak cevap verilmesi ve gerekli iĢlemlerin yapılması. Mevcut sistem veya
gerekli konularla ilgili; bilgilendirme, istatistik, veya raporlama amacı ile
dokümantasyon çalıĢmalarının yapılması, tüm ağ kullanıcılarının ağ sorunlarına teknik
destek verilmesi, tüm IP telefon kullanıcılarının sorunlarına teknik destek verilmesi,
bağlı olduğu proses Ġle üst yönetici/yöneticileri tarafından verilen diğer iĢleri ve
iĢlemleri yapan kiĢidir.
Web Tasarımcısı(Eleman 3):
Web tasarımcısı web sitesinin görüntülenen grafik ara yüzünün kullanımı kolay,
bilgiye en kısa yolla ulaĢabilecek, iĢlevsel ve hızlı bir yapıda oluĢturulmasını
yapacaktır.
Programcı(Eleman 1):
Programcı üzerinde çalıĢtığı platformu, kullandığı teknolojileri iyi tanıması ve
bilgisayarın anlayacağı mantıksal dilde düĢünebilmesi gerekmektedir. Projemizde web
tasarımının kod kısmını üstlenen kiĢidir. Tasarımı ve modellemesi hazırlanan sistemin
gerçek hayata uygulamak için sistemi geliĢtirme ortamlarında koda dönüĢtüren kiĢidir.
Veri Tabanı Test Ekibi(Eleman 4)
Veri Tabanı bağlantısı ve sonuç oluĢturma kalitesini kontrol eder.Sistem Yönetimi
Servisi sorumluluğunda bulunan sunucuların bakım, onarım ve sistem/fiziksel
kurulumunu,sistem yönetimi Servisine ait mekanların emniyetini, tertip ve düzenini
sağlamakla görevlidir.
Sayfa 13
2.5 Önerilen Sistemin Teknik Tanımları
Sistemi kullanacak kiĢilerin eriĢimlerini sağlayabilmesi için bir internet bağlantısına
ihtiyaçları olacaktır. Bu ihtiyaçlarını Masaüstü Bilgisayar, Laptop, Tablet gibi internet
eriĢimi olan cihazlardan karĢılayabilirler.
Sistem programlama dilleri arasında büyük önemi olan ve diğerlerine göre daha
esnek bir yapıya sahip olan Java dilinde gerçekleĢtirilecektir.Veritabanı için ise SQL
dili kullanılacaktır.
2.6 Kullanılan Özel GeliĢtirme Araçları Ve Ortamları
 Sistem Java platformunda geliĢtirileceği için IDE olarak NETBEANS ya da
ELĠPSE seçilebilir.
 Projede IDE olarak NETBEANS seçilmiĢtir.
 Veri tabanı için SQL seçilmiĢtir.Java gibi birçok programlama diliyle uyumlu
olduğu için.
 Proje dokümantasyonu ve raporu için Microsoft Word, Microsoft Excel
kullanılmıĢtır.
 Grafik tasarımı için Adobe Photoshop CS6 kullanılacaktır.
 Proje süresi boyunca Çağlayan Model kullanılacaktır.
Sayfa 14
2.7 Proje Standartları, Yöntem ve Metodolojiler
Sistemde izlenilecek genel yaĢam döngüsü;
BAKIM
GERÇEKLEŞTİRİM
TASARIM
PLANLAMA
ÇÖZÜMLEME
Sistemde istemler tanımlı olduğundan ve üretimi az zaman gerektiren bir yazılım
projesi olarak düĢünüldüğünden, bu sistem için Çağlayan Model uygun görülmüĢtür.
Sayfa 15
Çağlayan modelde, sistemin geliĢtirilmesinde izlenecek yol Ģu Ģekildedir:
Sistem Gerekleri
Tanımları
Yazılım Gerekleri
Tanımları
Çözümleme
Tasarım
Kodlama
Sınama
 SĠSTEM GEREKLERĠ TANIMLAMA
Sistemin ihtiyaçlarının belirlenmesi ve kullanıcı istemlerinin tanımlanması
aĢamasıdır.
 YAZILIM GEREKLERĠ TANIMLAMA
Personel, donanım ve sistem gereksinimlerini belirlenme, sistemin fizibilite
çalıĢmasının yapılma aĢamasıdır.
 ÇÖZÜMLEME
Sistemdeki hangi verilerin, hangi kullanıcılar için ve nasıl iĢlenmesi
gerektiğinin irdelendiği; sistemin girdilerinin, mantığının, çıktılarının ve
bileĢenlerinin betimlendiği aĢamadır.
Sayfa 16
 TASARIM
Analiz aĢaması sonucunda belirlenen gereksinimlere yanıt verecek sistemin
temel yapısının oluĢturulduğu aĢamadır.
 KODLAMA
Kodlama aĢaması, tasarım sürecinde ortaya konan veriler doğrultusunda
yazılımın gerçekleĢtirilmesi aĢamasıdır. Bu süreç programlama çalıĢmalarının
yanı sıra yazılımın geliĢtirilmesi ve kullanıcıya ulaĢtırılması sürecindeki bütün
çalıĢmaları kapsar.
 SINAMA
Test aĢaması, yazılım kodlanması sürecinin ardından gerçekleĢtirilen sınama ve
doğrulama aĢamasıdır. Elde edilen uygulama yazılımının hem belirlenen
gereksinimleri sağlayıp sağlamadığının kontrol edildiği aĢamadır.
2.8 Kalite Sağlama Planı
Projede yapılacak bütün programların hatasız bir Ģekilde geliĢtirilmesi ve her
iĢlemin adım adım planlanan süreçte takip edilmesi, test aĢamasına geldiğinde
minimum sayıda hatayla karĢılaĢmak için aĢağıdaki basamaklar dikkate alınmalıdır.
 Test senaryolarını iĢ süreçlerinin gerektirdiği koĢulları dikkate alarak detaylı bir
Ģekilde oluĢturmak, Teknik Ekip Lideri’ne bildirmek,
 Testler sırasında gerçekleĢebilecek hataların belirli standartlar altında
dokümantasyon elde edilmesi için, gerekli Ģablonları ve rapor formatlarını
hazırlamak,
 Kalite Kontrol Testlerinden geçen modüllerin Kullanıcı Kabul Testlerini, ĠĢ
Süreç Analizi Sorumluları ile koordineli olarak gerçekleĢtirmek,
 Yazılım GeliĢtirme Ekibi tarafından geliĢtirilen ve testleri tamamlanan
yazılımın gerçek ortama geçiriliĢ aĢamasında, Yazılım GeliĢtirme Ekibi ile
birlikte planlamayı hazırlamak, bu konuda ilgili birimler ile koordinasyonu
sağlamak.
Sayfa 17
1
2
Önceki Adımların Bitişi
3
Geçerli Adımın Süresi
4
5
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ı.
Konfigürasyon Yönetimi süreci Ģunları içerir:
 Belirlenen zamanlarda, seçilen
konfigürasyonun tanımlanması
ürünlerin
ana
hatlarını
oluĢturacak
 Konfigürasyon birimlerindeki değiĢimleri kontrol edilmesi
 Konfigürasyon yönetimi altındaki ürünlerin oluĢturulması için gerekli Ģartların
oluĢturulması ya da sağlanması
 Takımın sahip olduğu veri girdilerinin değiĢmesi
 Kullanıcı sayısına göre sunucuların ve istemcilerin yetersizliği
Sayfa 18
2.10 Kaynak Yönetim Planı
2.11 Eğitim Planı
Proje kapsamında geliĢtirilecek olan TAġIT TANIMA SĠSTEMĠNĠ
kullanacak olan firmalarda çalıĢan kiĢilere sistemin çalıĢması ve kullanımı
hakkında eğitici bilgi verilecektir.Donanım kısmında oluĢabilecek sorunlar
hakkında da teknisyenlere bilgi verilecektir.Bakımında ise programcılara eğitim
verilecektir.
Sayfa 19
2.12 Test Planı
Her proje planı, geliĢtirme sürecinde üretilecek ürünün gerek teknik gerekse
kullanıcı açısından test edilmesinin sınanmasıdır.Tasarımın genel hatlarıyla
kullanıcıya kolaylık sağlamasını ve anlaĢıla bilirliğini test eder.Test senaryoları
çerçevesinde, biten yazılımların kontrolünü gerçekleĢtirir. Tespit edilen hata ya
da eksiklikler sistem üzerinden geri besleme ile yazılım ekibine
bildirilecektir. Yazılım GeliĢtirme Ekibi tarafından geliĢtirilen ve testleri
tamamlanan yazılımın gerçek ortama geçiriliĢ aĢamasında, Yazılım GeliĢtirme
Ekibi ile birlikte planlamayı hazırlamak, bu konuda ilgili birimler ile
koordinasyonu sağlamaktadır.
2.13 Bakım Planı
Düzenli olarak yapılacak bakım sürecinde aĢağıdaki maddelere uyulacaktır:
 Yeni iĢlev ve özelliklerin eklenmesi (yeni arĢiv kipi gibi)
 Eklenecek yeni teknolojiler
 Yeni donanımlar ekleme
 Yeni iĢletim sistemleriyle uyumluluk
 Yeni web tarayıcılarla uyumluluk
 Ġlgili iĢletim sisteminin yeni servis paketleriyle uyumluluk
 Kullanılan virüs tarayıcının yeni sürümleri ve güncellemeleriyle uyumluluk
 Yeni eğilimlere sürekli olarak uyarlanabilme özelliği
 Mevcut sürüm özellikleri hakkında bilgiler
 GeliĢmiĢ kullanıĢlılık ve iĢletim güvenliği
Sayfa 20
3.SĠSTEM ÇÖZÜMLEME
3.1 Mevcut Sistemin Ġncelenmesi
Mevcut Sistemin Aksaklıkları
 Hangi aracın ne zaman, nerede, ne kadar yakıt aldığının tespit edilmesi zor
bir uğraĢtı.
 Litre ve kilometre takiplerindeki aksaklıklar.
 Muhasebede yaĢanan problemler.

Ödemedeki aksaklıklar.
Yeni Sistemin Faydaları
 ġirketinizin hangi aracına , nerede , ne zaman ve ne kadar yakıt alınmıĢ ,
araçlarınız km. baĢına ne kadar yakıt harcamıĢ, haftalık olarak TaĢıt Tanıma
Sistemi sayesinde size rapor ediliyor.
 Ġstasyonda kredi kartı, fiĢ, imza, nakit ödeme, fatura alma, bekleme
yapmadan hızlı bir Ģekilde yakıt ikmali yapılır.
 Bütün ödemelerinizi tek bir noktaya ayda iki defa yapıyorsunuz. Yapı kredi,
Akbank,Denizbank,ĠĢBankası yada Garanti Bankası’ndan Ģirketimiz adına
açtıracağınız kredili hesabınız sayesinde tüm ödemeleriniz artık otomatik.
 Ayda sadece iki fatura ile muhasebe ve idari iĢlemlerinizin trafiği azalıyor.
Böylece masraf fiĢi düzenleme, fiĢlerin bilgisayara giriĢi, fiĢlerin kontrolü,
onlarca akaryakıt faturası, onlarca ödeme noktası,personel zamanı harcama,
düzenli rapor alamama gibi problemler ortadan kalkmaktadır.
 Akaryakıt giderleri üzerinde tam ve detaylı bir kontrol sağlanıp, olabilecek
kayıplar engellenir. Km kontrolü sayesinde aracınızın tüketim performansını
izleyebilirsiniz.
Sayfa 21
3.1.1 Örgüt Yapısı
Firma araç takibi ve yakıt bilgilerine ulaĢabilir.
Aracın nerede, ne zaman, ne kadar yakıt aldığına dair bilgilere ulaĢabilir.
Araç kaç km.de bir yakıt aldığına dair bilgilere ulaĢabilir.
Araca ait varsa kampanya veya indirim gibi bilgileri görebilir.
TaĢıt Tanıma Sistemi
Kullanıcı GiriĢleri
Benzinlik ġirketi
Firma
Yönetici
Personel
Araç Kullanıcısı
Sayfa 22
3.1.2 ĠĢlevsel Model
Benzinlik Şirketi
SİSTEM
Firma Yöneticisi
Araç Bilgileri
Araç Takibi
Kısıtlar ve Limitler
Kampanyalar
Akaryakıt Kontrolü
Use Case Diyagramı
Sayfa 23
3.1.3 Veri Modeli
Sistem
Benzinlik ġirketi
-veri Alma()
-aracKontrol
-kampanyalar()
-ödemeler()
-akaryakıtKontrol()
-aracKontrol()
-akaryakıtBilgi()
-akaryakıtÖdemeBilgi()
-kampanyaEkle()
-faturaGöster()
-kampanyaKontrol()
-aracBilgi()
Veri Tabanı
Firma
-veriSaklama()
-sistemeVeriGönderme()
-aracBilgi()
-akaryakıtLimitiEkle()
-akaryakıtÖdemeleri()
-lt/kmTakibi()
3.1.4 Varolan Yazılım/Donanım Kaynakları
 Ana Bilgisayar
 Masaüstü Bilgisayarlar
 Dizüstü Bilgisayarlar
 Yerel Alan Ağ altyapısı
 Yazıcılar
Sayfa 24
3.1.5 Varolan Sistemin Değerlendirilmesi
Mevcut sistemin yazılım kaynakları ve donanım kaynakları değerlendirilmiĢtir.
Değerlendirme sonucunda kullanılan yazılım kaynaklarının yetersizliği ve eski
versiyon kullanımı tespit edilmiĢtir. Kullanıcı ve yönetici giriĢlerinde eksiklerin
bulunduğu saplanılmıĢtır.Sistemin donanımsal yetersizliğinden kaynaklanan
kilitlenmeler, doğru sonuçlar üretmesini engellemektedir. Donanımsal ve
yazılımsal eksikliklerin varolan sistemde birçok hataya sebep olmuĢtur. Gerek
kullanıcı açısından gerek yönetici açısından birçok probleme sebep olmuĢtur.
3.1 Gereksenen Sistemin Mantıksal Modeli
3.2.1 GiriĢ
Sistem yapısında kullanılacak modeller belirlenir. Varolan modeldeki eksiklikler
giderilir. Doğruluk açısından varolan ve gereksenen sistem karĢılaĢtırılarak daha
doğru model elde edilir.
3.2.2 ĠĢlevsel Model
 Firma sisteme giriĢ yaparak araç ekleyebilir ve çıkartabilir.
 Firma,araçları takip edebilir nerede, ne zaman, ne kadar yakıt aldıklarına
dair bilgilere ulaĢabilir.
 Lt ve Km takibi yapabilir.
 Belirli bir akaryakıt limiti ekleyebilir.
 Benzinlik Ģirketi sisteme giriĢ yaparak kampanyalar oluĢturabilir ödeme
bilgilerine ulaĢabilir.
 Araç kullanıcısı sisteme girerek araç hakkındaki bilgilere varsa araca ait
olan kampanyalara ulaĢabilir.
Sayfa 25
Lt/Km takibi
Firma Yöneticisi
Benzinlik Şirketi
Akaryakıt limiti ekle
Kampanya Ekle
Akaryakıt Ödemesi
B.Şirketi Girişi
F.Yönetici Girişi
Akaryakıt Bilgi
Fatura Bilgi
Araç Ekle/Kaldır
Araç Bilgi Göster
Araç Güncelle
Kampanya Görüntüle
Kullanım durumları detaylı olarak aĢağıda açıklanmıĢtır.
Sayfa 26
Durum Ġsmi:
Aktör:
Katılımcı Aktör:
GiriĢ Durumu:
Olayların AkıĢı:
F.Yönetici GiriĢi
F.Yönetici
Yok
Yönetici numarası ve Ģifresi
1. Yöneticinin numarasının ve Ģifresinin girilmesi
2. Sistemin yönetici paneline giriĢi
Durum ÇıkıĢı:
Yönetici paneli kullanıma alınır
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Lt/Km Takibi
F.Yönetici
Yok
Yönetici giriĢ yapmıĢ
1. Akaryakıt Litre Takibi
2. Kaç km de ne kadar akaryakıt alındığı gösterilmesi
Durum ÇıkıĢı:
Yönetici akaryakıt,km hakkında bilgi sahibi oldu
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Akaryakıt Limiti Ekle
F.Yönetici
Yok
1. Litre veya TL bazında yakıt limiti ekleme
2. Ġstasyon limiti ekleme
3. Belirlenen ürün dıĢında ürün alımı engelleme
Durum ÇıkıĢı:
Yönetici akaryakıt alımında limitler eklemiĢ oldu
Sayfa 27
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Akaryakıt Ödemesi
F.Yönetici
Yok
1. Firma aylık veya yıllık bazda aldığı akaryakıt ücretinin
ödenmesi ve faturalandırılması
Durum ÇıkıĢı:
Yönetici akaryakıt alımındaki ödemeler yapılmıĢ oldu
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Durum ÇıkıĢı:
Akaryakıt Bilgi
F.Yönetici,Benzinlik ġirketi
Yok
Yönetici giriĢ yapmıĢ,Benzinlik ġirketi giriĢ yapmıĢ
1. Akaryakıt bilgilendirmesi
Yönetici ve Benzinlik Ģirketi akaryakıt bilgisi elde etti
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Durum ÇıkıĢı:
Araç Ekle/Kaldır
F.Yönetici
Yok
1. Yeni bir araç ekleme
2. Varolan bir aracı kaldırma
Yönetici yeni bir araç ekledi veya kaldırdı
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Araç Güncelle
F.Yönetici
Yok
1. Araç hakkındaki bilgileri güncelleme
Durum ÇıkıĢı:
Yönetici varolan araç hakkındaki bilgileri güncellemiĢ oldu
Sayfa 28
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Araç Bilgi Göster
F.Yönetici,Araç Kullanıcısı
Yok
1. Araç hakkındaki bilgiler gösterilir
Durum ÇıkıĢı:
Yönetici ve araç kullanıcısı araç hakkındaki bilgilere ulaĢtı
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
F.Yönetici,Araç Kullanıcısı
Yok
1. Araç için kampanya varsa olan kampanyaları gösterir
Durum ÇıkıĢı:
Araç kullanıcısı kampanyalara ulaĢtı
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Kampanya Ekle
Benzinlik ġirketi
Yok
Benzinlik ġirketi GiriĢ YapmıĢ
1. Benzinlik Ģirketi araçlara özel kampanyalar oluĢturur
Durum ÇıkıĢı:
Benzinlik Ģirketi kampanya oluĢturdu
Durum Ġsmi:
Aktör:
GiriĢ Durumu:
Yok
1. Araç için kampanya varsa olan kampanyaları gösterir
Durum ÇıkıĢı:
Araç kullanıcısı kampanyalara ulaĢtı
Sayfa 29
3.2.3 Genel BakıĢ
Firma sisteme giriĢ yaparak araç ekleyebilir ve çıkartabilir.Firma,araçları takip
edebilir nerede, ne zaman, ne kadar yakıt aldıklarına dair bilgilere ulaĢabilir.
Lt ve Km takibi yapabilir.Belirli bir akaryakıt limiti ekleyebilir.
Benzinlik Ģirketi sisteme giriĢ yaparak kampanyalar oluĢturabilir ödeme bilgilerine
ulaĢabilir. Araç kullanıcısı sisteme girerek araç hakkındaki bilgilere varsa araca ait
olan kampanyalara ulaĢabilir.
3.2.4 Bilgi Sistemleri / Nesneler
Site
• Yönetici
Dolaşımı,Kategori
• Yönetici Arayüzü
Tarama
• Benzinlik Şirketi
Site
Dolaşımı,Kategori • Benzinlik Şirketi
Tarama
Arayüzü
• Araç Kullanıcı
Site
Dolaşımı,Kategori • Araç Kullanıcı
Tarama
Arayüzü
Sayfa 30
3.2.5 Veri Modeli **********************###################
Sayfa 31
3.2.6 Veri Sözlüğü
KULLANICI GĠRĠġ BĠLGĠLERĠ ()
Kullanıcı Adı = Herhangi String değer tipinde bir addan oluĢur
Kullanıcı ġifresi = En az 6 basamaklı int-string-char tipinde bir değerden oluĢur
ARAÇLAR ()
Araç Ekle () :Yeni bir aracın ekleneceği yerdir.
Araç Kaldır ():Varolan bir aracın kaldırılacağı yerdir.
Araç Düzenleme ():Varolan bir araç hakkındaki bilgilerin düzenleneceği yerdir.
KAMPANYALAR ()
Bilgi () :Varolan kampanyaları gösterir.
Kampanya Ekle () :Yeni bir kampanya eklenecek olan yerdir.
AKARYAKIT ()
Akaryakıt Bilgi () :Akaryakıt hakkındaki bilgilerin görüntüleneceği yerdir.
Akaryayakıt Limiti () :Akaryakıta TL ve Lt bazında limitleri, istasyon limitleri ve
belirlenen ürün dıĢındaki ürünlerin alınmaması limitlerinin getirilebileceği yerdir.
Akaryakıt Ödemesi () :Akaryakıt ödeme ve fatura iĢlemlerinin yapılacağı yerdir.
Sayfa 32
3.2.7 ĠĢlevlerin Sıradüzeni
 Yönetici Sıradüzen Diyagramı Ģu Ģekildedir;
Sayfa 33
 Yönetici Kullanıcı Güncelleme Sıralama Diyagramı;
Sayfa 34
Sayfa 35
Sayfa 36
Sayfa 37
3.2.8 BaĢarım Gerekleri
Gereksinimlerin doğru tanımlanması isterlerin doğru çözümlenmesinde en önemli
etkenlerden biridir. Gerek use case diyagramı gerekse sıralama diyagramları
isterlerimizin ne derece doğru olduğunu ortaya koyar. Bu sebeptendir ki yazılım
projelerinin yarısından çoğu gereksinim analizi sürecindeki hataları yüzünden
baĢarısız oluyor.
Bir bilgi sisteminin ana iĢlevlerini, bu iĢlevlere iliĢkin veri kaynaklarını, veri
depolarını ve iĢlemleri arasındaki iliĢkiler ne kadar iyi anlaĢılırsa, isterlerin çözümü
de o derece iyi anlaĢılır.
3.3 Arayüz (Modül) Gerekleri
3.3.1 Yazılım Arayüzü
 Araçları Departman bazında gruplayıp, bu gruptaki araçlar için geçerli standart
limitler uygulayabilirsiniz,
 Miktar (lt) veya Tutar (YTL) bazında;
 Günlük,
 (6 farklı zaman dilimi için ayrı limit giriĢine imkan
verilmektedir),
 Haftalık,
 Aylık,
 Yıllık,
 Bayram ve Tatil Günleri (YılbaĢı, Kurban Bayramı, vs.) için Gün/Saat
Kısıtları oluĢturabilirsiniz,
 Ġstasyon Kısıtları;
 Belirlenen il,
 Bir ildeki sadece belirli istasyonlardan araçların yakıt almalarını
sağlanabilirsiniz,
Sayfa 38
 Belirlenen ürün dıĢında diğer ürünlerin alınmasını engelleyebilirsiniz,
 Aracın eurodizel yakıt alımını onay verirken, Motorin alımını
engelleyebilirsiniz,
Ġnternet üzerinden 7 gün-24 saat boyunca aracın yakıt alımı hemen
durdurulabilirsiniz.
 TanımlanmıĢ bir gruba yeni kısıt eklemek ya da varolan Gün/saat, Kullanım,
Ġstasyon, Özel Gün, Resmi Tatil ve Ürün kısıtları düzeltmek mümkün olup bu
iĢlemler ve kim tarafından yapıldığı kayıt altına alınmaktadır.
 Tanımlı bir gruba yeni araç veya gruptan araç çıkartmak eklemek mümkündür.
 Tüm bu kısıtlama ve tanım araç bazında da yapılabilmektedir.
 Araçlara, bir gruba ait olmalarının yanı sıra kendilerine özel, herhangi bir
grubun tanımlarına uymayan kısıtlar da tanımlanabilmektedir. Yani araçlar
gruplanarak kısıt tanımları yapılabildiği gibi her bir araca özel tanımlama
yapmak da mümkündür.
 MüĢteriler iĢlem bilgilerini kendi sistemlerine transfer edebilirler.
3.3.2 Kullanıcı Arayüzü
 Yeni araçlar eklenebilcek ve düzenlenebilecektir bu iĢlemler için uygun ve
anlaĢılabilir bir arayüz olmalıdır.
 Akaryakıt alım bilgileri ve ücret bilgilerine ulaĢılır.
 Benzinlik ġirketinin kampanya ekleyebileceği ve görebileceği bir arayüz.
 Firmanın araç takibi kısıtlamalarının görüntüleneceği ve yeni
kısıtlamalarının oluĢturulabilecek bir arayüz.
Sayfa 39
3.3.3 ĠletiĢim Arayüzü
Sayfa 40
3.3.4 Yönetim Arayüzü
 Yeni araçlar eklenebilcek ve düzenlenebilecektir bu iĢlemler için uygun ve
anlaĢılabilir bir arayüz olmalıdır.
 Akaryakıt alım bilgileri ve ücret bilgilerine ulaĢılır.
 Benzinlik ġirketinin kampanya ekleyebileceği ve görebileceği bir arayüz.
 Firmanın araç takibi kısıtlamalarının görüntüleneceği ve yeni
kısıtlamalarının oluĢturulabilecek bir arayüz.
3.4 Belgeleme Gerekleri
3.4.1 GeliĢtirme Sürecinin Belgelenmesi
Belgelendirme Microsoft Word ortamında raporlandırılacaktır. Ve bu rapor,
proje ile alakalı tüm çalıĢmaları içerecektir. Belgelendirme iĢlemlerini Ģu ana
baĢlıklarda sıralayabiliriz:
• Proje planı belgelendirilmesi
• Sistem çözümlemesinin belgelendirilmesi
• Sistem tasarımının belgelendirilmesi
• Sistem gerçekleĢtirilmesinin belgelendirilmesi
• Doğrulama ve geçerlemenin belgelendirilmesi
•
Sistem bakımının belgelendirilmesi
Sayfa 41
3.4.2 Eğitim Belgeleri
Sistemin kurulacağı yerlerde sistemin kullananlar içeriği hakkında ve kullanılıĢı
açısından kolaylık sağlaması için ;
o Görsel olarak hazırlanmıĢ kullanım kolaylığı sağlayan web sayfası
o Video Ģeklinde hazırlanmıĢtır.
o Power point sunusu ile de kullananlara yardımcı olunmaya çalıĢılmıĢtır.
Sistem kullanıcıları için baĢka herhangi bir dökümantasyon
oluĢturulmamıĢtır.Çünkü kullanım açısından gayet basittir.
3.4.3 Kullanıcı El Kitapları
Sistem kullanıcılar açısından kullanımı çok kolay olduğu için kullanıcı el kitabı
hazırlanmamıĢtır.Ama sistemin kurulacağı yerlerde çalıĢanlar için hazırlıklara da
3.4.2 ' de değinmiĢtik.
Sayfa 42
4.SĠSTEM TASARIMI
4.1 Genel Tasarım Bilgileri
4.1.1 Genel Sistem Tanımı
Sistem çözümleme çalıĢması sonucunda üretilen mantıksal modelin Fiziksel
Modele dönüĢtürülme çalıĢması olarak tanımlanabilir. Fiziksel model,
geliĢtirilecek yazılımın hangi parçalardan oluĢacağını, bu parçalar arasındaki
iliĢkilerin neler olacağını ve parçaların içyapısının ayrıntılarını, gerekecek veri
yapısının fiziksel biçiminin (kütük, veri tabanı tablosu vb.) tasarımını içerir.
Fiziksel tasarımın temel çıktısı, doğrudan programlanabilecek program ve veri
tanımlarıdır.
Sistemde kullanılacak veri yapılarının ve veri tabanının yedeklenir ve arĢivlenir
ortamları anabilgisayarda saklanacak. Kurulacak sunucular merkezi bilgi sistemi
olacaktır. Sistemin tüm bilgi alıĢı ve akıĢı bu sunuculardan olacaktır. Sistem
verilerinin sunucularda sistematik Ģekilde saklanması için MySQL veri tabanı
yönetim sistemi (VTYS) kullanılacaktır. PHP ile beraber web-veritabanı
uygulamalarında çok yaygın olarak kullanılması, Çok hızlı, güvenilir ve kullanımı
kolay olmasıdır.
4.1.2 Varsayımlar ve Kısıtlamalar
a. Sistemdeki Varsayımlar
 Proje iki kiĢinin katılımını içeren bir ekip çalıĢması gerektirecektir.
 En kısa zamanda güvenilir bir sistem elde edilmesi amaçlanmaktadır.
 Proje içerisinde görev alan kiĢilerle uyum içinde çalıĢılması sağlanacaktır.
 Projeye baĢlamadan önce gerekli kiĢilerle görüĢülecektir.
 Sistemde kullanıcı ile yöneticinin her zaman haber halinde olması
sağlanmalıdır.
Sayfa 43
 Sistemde güncellemeler için iletiĢim haline geçilmesi sağlanmalıdır.
 Kaynaklar bir çeĢit kısıtlama olarak değerlendirilmeyeceklerdir.
 Taahhüt edilen Ģeylere bağlı kalınacaktır.
 Her seviyede sürekli iletiĢim sağlanacaktır.
b. Sistemdeki Kısıtlamalar
 Bir gruptaki araç sayısı maksimum 10 olmalıdır.
 Herkesin birbirleriyle uyum içinde olması gerekmektedir.
 Sistem sürekli olarak güncellenmelidir.
 Sisteme maksimum 3 farklı yönetici girebilir.
 Araç kullanıcısı sisteme kaydedilmeden sistemdeki bilgilere ulaĢamaz.
Sayfa 44
4.1.3 Sistem Mimarisi
KULLANICI
VERİ TABANI
SUNUCU
Sayfa 45
Firma Yöneticisi
Başla
H
Yönetici
Girişi
E
Kullanıcı Adı
Şifre
H
Giriş Yap
E
Giriş Yapıldı
Sistem Hakkında
Araç Ekle/Kaldır
Lt / Km Limiti
İstasyon Limiti
Araç Kısıtlama
Ürün Limiti
Tahsilat Sorgulama
Bitir
Sayfa 46
4.1.4 DıĢ Arabirimler
4.1.4.1 Kullanıcı Arabirimleri
Kullanıcı ana arabirimi sitemizin giriĢ sayfasıdır. Basit ve sade olması ön planda
olmuĢtur. Yönetici olanlar veya ziyaretçi olarak sitemize gelenler Hakkımızda
kısmından taĢıt tanıma sistemi hakkında bilgiler alabilirler, Yöneticiler kullanıcı
Ģifreleri ile girildikten sonra kendi iĢlemlerini yapabilirler araç ekleme çıkartma ,
araç kısıtlama , tahsilat sorgulama , araç takibi gibi iĢlemlerini yapabilirler.
Kullanıcı bu ara yüzde kullanacağı isim ve Ģifresini belirler. Daha sonra Ģifre
değiĢtirmek için gerekli olacak e-postasını bu ara yüzde belirler. Gene daha sonra
Ģifresini değiĢtirmek için gerekli olacak gizli soru ve cevabını belirler.
4.1.4.2 Veri Arabirimleri
Veritabanında yönetici bilgileri, petrol ofisi bilgileri ve araç kullanıcısı bilgileri,
araç kaydı , araç durum bilgileri ve kampanyalar kayıt edilerek bilgi güvenliği
sağlanacaktır.
4.1.4.3 Diğer Sistemlerle Arabirimleri
Sistemimiz, bütün firmalarda aynı sistemin kullanılmasını amaçladığı için baĢka
hiçbir sistemle arayüzü bulunmamaktadır.
Sayfa 47
4.1.5 Veri Modeli *********************#####################
Sayfa 48
4.1.6 Testler
Yazılım geliĢtirme çalıĢmalarında hem ALFA hem de BETA test aĢamalarında
sistemin sınanması gereken alanlar ortaktır.
Fonksiyonel
Test
• Geliştirilen sistemin fonksiyonlarının sınandığı test çalışmasıdır.
Sistemde geliştirilen fonksiyonların tamlığının, doğruluğunun ve
tutarlılığının test edilmesidir
• Sistem üzerinde geliştirilen fonksiyonların kullanılabilirlik
seviyesinin testidir. Hem ALFA, hem BETA aşamalarında
Kullanılabilirlik
gerçekleştirilen bir test alanıdır.
Testi
Performans
Testi
Güvenlik Testi
• Bir sistemin kabul edilebilir bir hızda işlemesi beklenir. Sistemin
tüm fonksiyonel gereksinimleri karşılamasına rağmen kabul
edilebilir olmayan bir yavaşlıkta çalışması, müşterinin geliştirilen
sistemi kabul etmemesine neden olabilir.
• Geliştirilen sistemin depoladığı verileri işlediği ,bilgileri barındırdığı
fonksiyonları ve özellikleri sadece yetkili kullanıcı sunduğunu garanti
altına almak için yapılan testlerdir.
•Kullanıcıların sisteme sorunsuz girip çıkması aşamasının test edilmesidir.
Sorunsuz login olup olmadıkları kontrol edilir. Kullanıcı adı ve şifre kısmında
Kullanıcı ve Login sorun olup almadığı bakılır ve test verileri elde edilir
Testi
•Geliştirilen sistemin depoladığı verileri tanımlanan şekilde arşivleyip
arşivleyemediği, arşivlenen verilerin erişilebilir olup olmadığı, depoladığı
verilerin tanımlanan şekilde yedeklenip yedeklenmediği, yedeklenen
Arşivleme ve
verilerin erişilebilir olup olmadığının sınandığı test alanıdır.
Yedekleme Testi
Sayfa 49
Denetim Testi
• Geliştirilen sistemin, kullanıcının kurumlar tarafından
denetlenebilir olup olmadığının, denetlenmek istenebilecek
işlem izlerinin ve veri değişiklik tarihçesinin sistemde tutulup
tutulmadığının sınandığı test çalışmasıdır.
• Dökümantasyon kısmının doğru ve tutarlı olup olmadığının
sınandığı test çalışmasıdır
Dökümantasyon
Testi
4.1.7 Performans
 Projenin anlaĢılabilir olması
 Proje çalıĢanlarının uyum içinde olması
 Proje kurallarına uyulması
 Proje amaçlarına uygunluğunun ölçülmesi
 Projenin istenilen aĢamada ölçülebilir olması
 Projenin zamanlama kısmının incelenmesi
Sayfa 50
4.2 Veri Tasarımı
Yapı tasarımı, arayüz ve süreç tasarımından önce ilk yapılması gereken, veri
tasarımıdır. Bilgi saklama ve soyutlama bu iĢlem için değerli kavramlardır.
Çözümlemede faydalandığımız veri sözlüğü, tasarımda da yararlı olacaktır.
Tasarım sırasında, çözümlemede ortaya çıkarılan modellerin uygulanmasında
pratik sorunlar irdelenir, gerekirse çözümleme modelinin değiĢmesi bile istenebilir.
 DeğiĢik veri yapılandırılmaları değerlendirilmelidir.
 Kullanılacak veri yapılarını oluĢturan birimlerin türleri, sınırları ile birbirleri
ile olan iliĢkileri bir veri sözlüğü içinde toplanmıĢtır.
 Veri yapılarının tanımlanmasında döngüsel bir yol izlenmesi daha
uygundur.
 Veri yapıları yalnızca kendilerini kullanan modüllere görünür olmalıdır.
 KarmaĢık veri yapılarının kullanımı gerekiyorsa kullanılacak program dili,
soyut veri türlerini desteleyebilecek Ģekilde seçilmelidir.
 Gözden geçirmeler sırasında önemli veri yapılarının tasarımı da
incelenmelidir.
4.2.1 Tablo Tanımları
Veri tabanında tutulacak bilgilerin tanımları Ģu Ģekildedir;
1) Yönetici GiriĢi:
Sistemde kayıtlı olan yöneticilerin sisteme kullanıcı adları ve Ģifreleri ile giriĢ
yapmaları gerekmektedir.Bu tabloda kullanıcı adı ve Ģifre bilgileri tutulmaktadır.
2) Kullanıcı GiriĢi:
Petrol Ofisi Ģirketinin sisteme kullanıcı adı ve Ģifresi ile giriĢ yapması
gerekmektedir ve araç kullanıcısınında kullanıcı adı ve Ģifresiyle sisteme giriĢ
yapması gerekmektedir.Bu tabloda kullanıcı adları ve Ģifrelerin tutulacağı tablodur.
Sayfa 51
3) Kampanyalar:
Bu tabloda kampanyalar hakkındaki bilgiler ve kampanyalar yer alacaktır.
4) Araç Bilgi:
Bu tabloda da araç detayları ve araç hakkındaki bilgiler yer alacaktır.Araç ekleme
kaldırma ve düzenleme gibi bilgilerde yer alacaktır.
5) Araç Ekle/Kaldır:
Bu tabloda da yeni araç ekleme ve varolan bir aracı kaldırma iĢlemlerinin
yapılacağı tablodur.
6) Araç Düzenle:
Bu tabloda da araç bilgilerinin düzenlemelerinin yapılacağı tablodur.
7) Akaryakıt Kısıtlamaları:
Bu tabloda da akaryakıt kısıtlamaları, istasyon kısıtlamaları ve ürün
kısıtlamalarının tutulacağı tablodur.
Yönetici GiriĢ Tablosu
Veri Tipi
Kullanıcı Adı
String
Parola
String
Kullanıcı GiriĢ Tablosu
Veri Tipi
Kullanıcı Adı
String
Parola
String
Sayfa 52
Kampanya Tablosu
Veri Tipi
Kampanya No
String
Kampanya Adı
String
Kampanyalar Hakkında
Varchar
Araç Tablosu
Veri Tipi
Araç Adı
String
Araç Plaka
String
Araç Detayları
Varchar
Araç Bilgi Tablosu
Veri Tipi
Araç Adı
String
Araç Plaka
String
Araç Detayları
Varchar
Araç Ekle/Kaldır Tablosu
Veri Tipi
Araç Adı
String
Araç Plaka
String
Araç Cinsi
String
Grup Adı
String
Sayfa 53
Araç Düzenle Tablosu
Veri Tipi
Araç Adı
String
Araç Plaka
String
Araç Cinsi
String
Grup Adı
String
Akaryakıt Kısıtlama Tablosu
Veri Tipi
Araç Adı
String
Araç Plaka
String
Akaryakıt Lt/Km Limiti
Varchar
Ġstasyon Kısıtı
Varchar
Ürün Kısıtı
Varchar
4.2.2 Tablo-ĠliĢki ġemaları
Sayfa 54
Sayfa 55
4.3 Süreç Tasarımı
Süreç bir katma değer üretmek için gerçekleĢtirilen birbiri ile iliĢkili aktivite ve
iĢlemler dizisidir. Süreç içinde doğru bilgi akıĢı süreç performansını belirleyen en
önemli unsurlardan birisidir. Doğru bilgiye zaman kaybetmeden eriĢim zorlukları
ile yönlendirme ve onay belirsizlikleri süreç akıĢını olumsuz etkiler, zaman
israflarına yol açar.
Sayfa 56
Süreç tasarımını etkileyen temel etkenleri
Üretim sistemlerin temel iĢlevi, tüketicilerin istek ve arzularını doyuma ulaĢtırarak
biçim ve kalitedeki ürünleri, en düĢük maliyetle, en kısa zamanda ve yeteri miktarda
üretmektedir. Üretim sistemleri, bu iĢlevi yerine getirebilecek Ģekilde tasarlanmalıdır.
Söz konusu tasarım yapılırken, baĢlıca Ģu etkenler göz önünde bulundurulmalıdır;
Ürün Talebi
Üretim esnekliği
Otomasyon Düzeyi
Ürün Kalitesi
Tüketici İle İlişki
Düzeyi
Ürün Talebi
Üretim süreci tasarımı, ürün talebinin bütün yönlerinin açılımıyla baĢlar. Talep
tahminlerinin birinci boyutu, dönemsel talep miktarlarını öngörmektir. Talepteki
dönemsel artıĢ ve azalıĢlar, mevsimlik dalgalanmalar ve benzeri günlük, aylık ve yıllık
değiĢmeler, üretim sürecinin türünü ve kapasite saptamasını etkiler. Talep
tahminlerinin ikinci önemli boyutu, ürünün satıĢ fiyatı ile ilgilidir. Fiyat belirlenirken,
reklam, kredili satıĢ, satıĢ sonrası hizmetler, özel ürün tasarımı, stok politikası,
yükleme politikası, kalite ve diğer üretim ve pazarlama değiĢken ve politikaları da göz
önünde bulundurulmalıdır. Üretim sürecindeki iĢ tasarımları, ürünlerin fiyatlarına da
bağlıdır. Fiyatlar, pazar fiyatlarının altında tutulacaksa, talep fazla olacak ve buna
bağlı olarak üretim sürecinin kapasitesi de yüksek tutulacaktır. Fiyatlar yüksek
tutulacaksa, talep azalacak ve sürecin kapasitesi de düĢük tutulacaktır.
Sayfa 57
Diğer taraftan, değiĢik üretim süreci türleri, değiĢik rekabet üstünlükleri veya
zayıflıkları sağlar. BaĢka bir deyiĢle, üretim sürecinin türü, talebi azaltır veya çoğaltır.
Dolayısıyla, üretim süreci tasarlanırken, ürün miktarı, ürün fiyatı ve üretim süreci türü,
birbiriyle etkileĢimli olarak ele alınıp karara bağlanmalıdır.
Üretim Esnekliği
Üretim sürecinin, tüketicinin gereksinmelerine, hızla yanıt verebilme
yeteneğine, üretim esnekliği denir. Uygulamada, baĢlıca iki tür esneklikten söz edilir.
Bunlar, ürün esnekliği ve miktar esnekliğidir. Ürün esnekliği, bir ürünün üretiminden
diğer bir ürünün üretimine, hızla geçebilme yeteneğidir. Miktar esnekliği ise üretilen
ürün ya da verilen hizmet miktarını hızla arttırabilme yeteneğidir. Ürün esnekliği, çok
sayıda tüketiciye, farklı özelliklerdeki ürünün küçük partiler halinde üretilmesi ya da
ürünün hızlı bir Ģekilde üretilmesi istendiğinde gerekli olur. Örnek olarak, son yıllarda
gözlemlediğimiz esnek otomasyon sistemleri büyük ölçüde ürün esnekliği olanakları
sağlamaktadır. Miktar esnekliği, talepte büyük dalgalanmalar olduğunda ve ürün
stoklarının bu dalgalanmalara yanıt veremediği durumlarda önem kazanır. Genellikle
sermaye yoğun üretim sistemlerinde, miktar esnekliği yüksektir. Buna karĢılık, emek
yoğun hizmet iĢletmelerinde, miktar esnekliği daha düĢüktür. Dolayısıyla, emek yoğun
iĢletmeler, yüksek talep durumlarında, ya yarım gün (part-time) çalıĢan iĢ görenler
veya geçici çalıĢan iĢ görenler çalıĢtırma yoluna giderler.
Otomasyon Düzeyi
Süreç tasarımında, otomasyon olanaklarından ne ölçüde yararlanılacağına karar
vermek de önemli bir konudur. Son zamanlarda, iĢgücü giderlerinden tasarruf etmek,
çalıĢanların iĢi yavaĢlatma, iĢe devamsızlık, grev gibi eylemlerinden kurtulmak için
otomasyona gidildiği gözlemlenmektedir. Gerçekten de otomasyon düzeyi arttıkça,
üretim sisteminin kapalılık oranı artmakta ve iĢgücünden kaynaklanan sorunlar
azalmaktadır. Ancak, otomasyonun hem donanım olarak hem de bu donanımın iĢletimi
ve onarımı açısından pahalı bir sistem olduğu unutulmamalıdır. Üretim sürecindeki
otomasyon düzeyini belirlerken, otomasyonun ürün kalitesi ve ürün esnekliği
üzerindeki olumlu etkileri ölçülmeli ve toplam getirisinin toplam götürüsünden yüksek
olmasına çalıĢılmalıdır.
Ürün Kalitesi
Küresel dünya değerlerinin en baĢında, kalite yer almaktadır. Kalite, hem toplumun
yaĢam düzeyini yükseltmekte hem de iĢletmelere rekabet üstünlüğü sağlamaktadır.
Geleneksel iĢletmecilikte, yüksek kaliteli ürünler, üst gelir grubundaki az sayıdaki
tüketiciler için özel olarak üretilirdi. Mercedes, Jaguar, Rolls Royce gibi arabalar, bu
Sayfa 58
geleneksel yaklaĢımın ürünleri olarak ortaya çıkmıĢtır. Japonlar, öncelikle araba
alanında, bu eski görüĢü yıkmıĢlardır. Japonların Toyota otomobilleri, gelir grubuna
bakılmaksızın en yüksek kalitede ve geniĢ kitleler için üretilmektedir. Günümüzde,
hemen her ürünün üretiminde, birinci önceliği kalite almaktadır. Bu nedenle, üretim
süreci tasarlanırken, öngörülen kaliteyi tutturma koĢulu aranmalıdır. Ayrıca, süreç
iĢlerken, herhangi bir nedenle oluĢacak kalite hatalarını anında belirleyecek izleme ve
erken uyarı sistemleri, süreç tasarımıyla birlikte tasarlanmalıdır.
Tüketici Ġle ĠliĢki Düzeyi
Genellikle hizmet iĢletmelerinde, üretim sırasında, tüketiciyle birebir iliĢki
olmaktadır. Örnek olarak, tıbbi tedavi ve kuaförlük hizmetlerinde, tüketici, aktif olarak
üretim sürecinin içinde bulunmaktadır. Dolayısıyla, tüketiciyle iliĢki düzeyi, iĢin
özelliği nedeniyle yoğun olan durumlarda süreç, tümüyle tüketiciye göre
yönlendirilmelidir. Buna karĢılık, fast-food restoranlarda olduğu gibi, tüketicinin
üretim ortamında olmasına rağmen, üretim sürecine müdahale edemediği durumlar da
vardır. Böyle durumlarda, üretim süreci, yoğun ve standartlaĢtırılmıĢ hizmet verecek
biçimde tasarlanmalı ve bu süreç içinde maliyet, fiyat ve hizmetin tamamlanma süresi
iyi dengelenmelidir.
4.3.1 Genel Tasarım
Yazılım geliĢtirme süreçleri sürekli yaĢayan ve iyileĢtirilen süreçler olmak
zorundadırlar.Dolayısı ile, bir süreç yönetim mekanizması kurulması zorunldur.
Süreç yönetimi, süreç tanımlama, oraganizasyonel eğitim, süreç iyileĢtirme süreçleri
Ģeklinde organize edilebilir.
 Süreç Tanımlama Süreci : Süreç tanımlama sürecinin amacı, iĢ süreçlerinin
tutarlı, tekrarlanabilir, performansını destekleyecek süreç kütüphanesini
oluĢturmaktadır.Bu süreç için ,süreç tanımlama formu, süreç iĢ çıktıları
hazırlama formu gibi Ģablonlar tanımlanmalıdır.
 Organizasyonel Eğitim : Organizasyonel eğitim sürecinin amacı;
çalıĢanların, kendilerine verilen rolleri verimli ve etkin bir Ģekilde
gerçekleĢtirmeleri için ; bilgi ve beceri düzeylerinin geliĢtirilmesinin
sağlanmasıdır. Bu sürecin sonuçlarının ölçülebilmesi için eğitim kayıt listesi,
eğitim sonuçları değerlendirme formu vb. Ģablonlar tanımlanmalıdır.
Sayfa 59
 Süreç ĠyileĢtirme Süreci : Süreç iyileĢtirme sürecinin amacı ; organizasyon
süreçleri ve süreç varlıkları ile ilgili kuvvetli ve zayıf alanlar baz alınarak;
organizasyon süreç iyileĢtirme aktivitelerinin planlanması ve
uygulanmasıdır.
Süreç Yönetimi
Sürekli Gelişim
Süreç Tanımlama
Süreci
Organizasyonel
Eğitim
Süreç ĠyileĢtirme
Süreci
4.3.2 Modüller
Modüller, tanımlayıcı isimleri olan, tanımlanmıĢ iĢlevlere sahip asıl sistemi
oluĢturan birimlerdir. Tasarımı daha baĢarılı yapmanın diğer yolu da problemi
uygun parçalara bölerek yazılımı modüler bir Ģekilde geliĢtirmektir.
4.3.2.1 Yönetici Modülü
Yönetici modülü sistem iĢleyiĢinin kontrol eden kullanıcıdır.
4.3.2.1.1. ĠĢlev
Kullanıcı ve yöneticilerin sisteme giriĢ yaptığı yerdir.
4.3.2.1.2. Kullanıcı Arabirimi
Kullanıcı ve yöneticiler için ayrı ayrı giriĢ sistemimiz bulunacaktır.
Sayfa 60
4.3.2.1.3. Modül Tanımı
Kullanıcılar üye adı ve Ģifresi ile sisteme giriĢ yapabilirler.
Yöneticiler panelinden kullanıcı adı ve Ģifrelerini girerek sisteme giriĢ
yapabilirler.
Araç
Ekle/Kaldır/Düz
enle
Araç bilgisi
görüntüle
Akaryakıt
Kısıtlamaları
Tahsilat
Sorgulama
4.3.2.4 Araç Kullanıcı Modülü
Araç hakkındaki detaylara ve kampanyalara ulaĢabileceği modüldür.
4.3.3 Kullanıcı Profilleri
Sayfa 61
4.3.4 Entegrasyon ve Test Gereksinimleri
Veri tabanı sisteme bir değiĢiklik yapılmadan entegre edilecektir. Veri tabanı yük
altında sistemle uyumlu ve doğru çalıĢıyor mu, sistemle veri tabanı uyumluluğu veri
tabanı ve sistem arasında ki süre verme tepkisinin hızlılığı veri tabanının sistemdeki
bilgilerin okuma doğrululuğu kontrol edilir.
Fonksiyonel gereksinimlerin bazıları geliĢtirilen sistemin diğer mevcut sistemler ile
veri alıĢveriĢi yapmasını gerektirebilir. Bunun en sık karĢılaĢılan örnekleri,
geliĢtirilen sistemin eposta veya sms göndermesi, baĢka bir sistemdeki bir kaydı
güncellemesi veya baĢka bir sistemde yapılan bir iĢlem sonrasında yeni geliĢtirilen
sistemdeki kayıtların güncellenmesidir. Böylesi gereksinimlerin var olması
durumunda, entegrasyonun tam ve doğru yapıldığının garanti altına alınması için
entegrasyon testi gerçekleĢtirilir. Bu test çalıĢmaları sonucunda entegrasyonun tam,
tutarlı ve doğru çalıĢmadığı durumlar ortaya çıkarılarak, gerekli düzeltmelerin
yapılması sağlanır. Entegrasyon testi hem ALFA, hem BETA aĢamalarında
gerçekleĢtirilen bir test alanıdır ve yapılacak olan testler Ģunlardır;
 Sistem veri tabanı uygunluğu
 Veri tabanının sisteme en kısa sürede tepki verme performansı
 Veri tabanından bilgileri okuma doğruluğu
 Veri tabanına sistem bilgilerinin kayıt doğruluğu
 Veri tabanının yük altında sistemle uyumluluk ve doğru çalıĢma performansı
4.4 Ortak Alt Sistemlerin Tasarımı
Herhangi bir bilgi sistemi tasarlanırken, hemen hemen tüm bilgi sistemlerinde
ortak olarak bulunan bazı alt sistemlerin dikkate alınması gerekmektedir.
Sayfa 62
4.4.1 Ortak Alt Sistemler
Sistemlerin ortak noktaları Ģunlardır:
Alt sistemler olarak çeĢitli öğeleri vardır.
 Bu öğeler arasında sürekli, düzenli ve bilinçli iliĢkiler vardır.
 Gerek bütünün gerekse öğelerin (alt-sistemlerin) dıĢ çevre ile iliĢkisi vardır.
 Bir sistemin iyi bir iĢleyiĢe sahip olabilmesi için bazı temel ilkelere sahip
olması gerekir. Bu ilkeler:
 Ġyi bir sistem, kendinden beklenen görevi en düĢük maliyetle yerine
getirmelidir.
 Gereksiz iletiĢimden kaçınılmalıdır. Aksi halde bürokratik engel çoğalır, hata
olasılığı yükselir ve kontrol iĢlemlerine daha fazla gereksinim duyulur.
 Örgütlerde her bölümün kendi sorumluluklarını rasyonel ve düzenli olarak
yerine getirmesi ve amaçlardan sapmaması gerekir.
 Hiçbir fonksiyonun maliyeti sağladığı yarardan fazla olmamalıdır.
 Birbirine bağlı ve yardımcı fonksiyonlar konum bakımından birbirine yakın
olmalıdır.
 Her bölüm, sorumluluğunu yerine getirebilmek için gerekli yetkiye sahip
olmalıdır. Bir baĢka deyiĢle, yetki ve sorumluluk dengesi kurulmalıdır.
 Bir sistem mümkün olduğu kadar esnek olmalıdır.
 Yönetim basamakları olabildiğince kısa ve dar tutulmalıdır.
 Yetki ve sorumluluklar, politika, ilke ve kurallar ilgili yöneticilere yazılı
olarak verilmelidir.
Ġyi bir sistem açık, anlaĢılır, basit olmalı ve amaç bütünlüğü taĢımalıdır.
Sayfa 63
4.4.2 Modüller Arası Ortak Veriler
Eğer iki modül ortak bir alanda tanımlanmıĢ verilere ulaĢabiliyorsa bu iki modül
ortak veri bağlaĢımlı olarak tanımlanır.
Verilerin ortak veri bağlaĢımlı olmaları Ģu nedenlerden dolayı fazla istenmez;
 Ortak veri alanını izlemek zordur.
 Ortak veri kullanan modüllerde yapılan değiĢiklikler diğer modülleri etkiler.
 Ortak veri üzerinde yapılacak değiĢikliklerde bu veriyi kullanacak bütün
modüller göz önüne alınmalıdır.
4.4.3 Ortak Veriler Ġçin GiriĢ ve Raporlama Modülleri
4.4.4 Güvenlik Alt Sistemi
Sayfa 64
Ġyi bir yazılım güvenilirlik modelinin sahip olması gereken özellikler aĢağıda
verilmektedir :
 Gelecekte oluĢacak hatalara ait iyi bir tahminlemeye olanak vermesi
 Yararlı nicelikleri hesaplaması
 Basit olması
 GeniĢ bir uygulama alanının bulunması
 Kabul edilebilir varsayımları desteklemesi
 Parametrelerin kolay hesaplanması
4.4.5 Veri Dağıtım Alt Sistemi
Sayfa 65
4.4.6 Yedekleme ve ArĢivleme ĠĢlemleri
Yedekleme ve arĢivleme, küçük çaplı iletiĢim akıĢı olan yerlerde genel olarak,
gereksiz bir aĢama olarak gözükmüĢtür. Ancak, e-posta akıĢı yoğunlaĢtıkça ve
depolama özellikleri, herkes için eriĢilebilir oldukça, düĢünülmesi gerekmektedir.
Yedekleme ve arĢivleme iĢlemleri, özellikle resmi kurumları yönetenler için bir
zorunluluk olmuĢtur. Bunun dıĢında, hemen hemen bütün Ģirketler, belirli bilgileri,
denetim süreçleri için hazır tutmak zorundadır. Dijital çağda yaĢıyor olmamız ve
kâğıtlarda duran kâğıtların çevrimiçi belgelere dönüĢmesi sonucunda, belgeler ile
dosyalarda bulunan bilgilerin, kapsamlı bir dosyaya sıkıĢtırılması sonucu geliĢtirildi.
Dolayısıyla yedekleme yapmak; iĢletmeler için kullanıcı hatası ve teknolojik hatalar
nedeniyle bilginin kaybolma riskinin daha az olması anlamını taĢıyor.
Piyasada, yedeklenmiĢ verilerin arĢivlenmesi amacıyla çok sayıda ürün
bulunmaktadır. Bunların çoğu, kullanıcıyla daha az temasa geçerek; süreci
hızlandıracak birkaç adımı uygular. Bu kurallar, bir ağ veya proje yöneticisi tarafından
belirlenir ve Ģifreyle korunur. Dolayısıyla, birleĢik bir sistem bulunur.
Sayfa 66
5.SĠSTEM GERÇEKLEġTĠRĠMĠ
Sayfa 67

Kataloğu Gör

Transkript

Benzer belgeler

Eroğlu - Kıbrıs Postası

Otobüs Rayiç Bedelleri - izmir yüksek teknoloji enstitüsü

Facebook paylaşım detaylarını kişiselleştirme

Noterlik Bilgi Sisteminin Sahiplik ve Kullanım Hakları ile Şekline

Kataloğu Görüntüle