close

Enter

Log in using OpenID

598.49 KB - Inet-tr

embedDownload
Çevik bir Hikâye: Celal Bayar Üniversitesi Öğrenci
Kayıtlanma Modülü Bu Dönem Neden Çökmedi?
Onur LEBLEBİCİ, Deniz KILINÇ, Ceyhun ARAZ, Cihan DEMİREL, Bora
GÜRSEL, Seda GÖRMEZ
Celal Bayar Üniversitesi, Bilgisayar Araştırma ve Uygulama Merkezi, Manisa
[email protected], [email protected], [email protected], [email protected], [email protected],
[email protected]
Özet: Yazılım teknolojilerinin hızla ilerlediği bu dönemde üniversitelerde kullanılan yazılım
otomasyon sistemlerinin geride kalması önemli bir problemdir. Bu duruma ilave olarak;
üniversitelerin Bilgisayar Bilimleri, Bilgisayar Mühendisliği, Yazılım Mühendisliği ve
Bilgisayar Programcılığı gibi bölümleriyle sektör için uzman personel yetiştirdiğini
düşünürsek, olay farklı bir boyut almakta ve maalesef “Terzi kendi söküğünü dikemiyor”
sonucu ortaya çıkmaktadır. Tecrübe aktarımı niteliğindeki bu bildiride, CBÜ BAUM
tarafından geliştirilen Yeni Kayıtlanma Modülünün geliştirme süreçleri ve detayları hakkında
bilgilendirme yapılmıştır. Deneysel sonuçlarda da görüldüğü üzere hayata geçirilen bu modül,
33.000 kullanıcının üzerinde yoğun bir kullanıma rağmen, yüksek sistem performansı ve sıfır
hata sayısı ile ciddi bir başarı elde etmiştir. Hem yazılım performans metrikleri hem de
öğrencilerden gelen olumlu geri dönüşler dikkate alındığında üniversitelerin 100.000’lerce
kullanıcıyı kaldırabilecek kaliteli yazılım ürünü geliştirmelerinin hayal olmadığı ortadadır.
Anahtar Sözcükler: Üniversite Yazılım Otomasyonları, Çevik Yazılım Geliştirme, SCRUM
Abstract: Despite the rapid evolution of software technologies, software automation systems
in universities, could not keep up with. In addition to this situation, the fact that the
universities are responsible to educate professional engineers in Computer Science, Computer
Engineering, Software Engineering and Computer Programming reminds us the idiom “the
shoemaker's son always goes barefoot”. In this paper, a newly developed Student Registration
Module and its development process details are provided. The paper is in the form of
experience sharing and the development is done by CBÜ BAUM. As seen in the experimental
results, despite intensive usage over 33,000 users, system has zero defects and reached high
overall system performance. As a result, implemented module is an admirable success. Finally,
it is obvious that development of a high quality software, supporting 100.000 users is not a
fantasy.
1. Giriş
Son yıllarda yazılım teknolojileri hızlı bir
gelişim sürecine girerek, küçük, orta ve
büyük ölçekli yazılım geliştirme firmaları ve
açık kaynak kod toplulukları tarafından farklı
alanlarda kullanılabilen yazılımlar üretilmeye
başlanmıştır[1].
Teknoloji bu hızla ilerlerken üniversitelerde
kullanılan yazılım otomasyon sistemlerinin
buna ne kadar ayak uydurabildiği önemli bir
tartışma konusudur. Bir de üniversitelerin
Bilgisayar Bilimleri, Bilgisayar Mühendisliği,
Yazılım
Mühendisliği
ve
Bilgisayar
Programcılığı gibi bölümleriyle bu sektör için
uzman personel yetiştirdiğini düşünürsek,
olay farklı bir boyut almakta ve maalesef
“Terzi kendi söküğünü dikemiyor” sonucu
ortaya çıkmaktadır.
Bir üniversite yazılım otomasyon sistemi
temelde 3 kullanıcı grubuna hizmet
vermektedir: (1) Öğrenciler, (2) Akademik
Personel, (3) İdari Personel. Bu kullanıcı
grupları farklı alt kullanıcı gruplarına
ayırılabilmektedir.
Bir üniversitenin yazılım otomasyon sistemi
aslında kurumsal bir yazılım ürününden
farksız olup, değişik derinlikte alt yazılım
ürünlerini ve modüllerini içerebilmektedir.
Örneğin: Öğrenci Otomasyonu, Personel
Otomasyonu, Elektronik Belge Yönetim
Sistemi, Akademik Performans Yönetimi bu
alt ürünlerden bazılarıdır.
Türkiye’deki
üniversitelerde
kullanılan
yazılım otomasyonlarında herhangi bir
standart bulunmamaktadır ve bu durumu
normal
karşılamak
gerekir.
Çünkü
üniversiteler Yükseköğretim Kuruluna[3]
(YÖK) bağlı olsalar da kendi içlerinde özerk
birer kurumdurlar. Her üniversitenin kendine
süreçlerini tanımladığı çeşitli yönetmelikleri
bulunmaktadır (Örnek için bakınız [10]). Bu
yönetmelikler de bir yazılım ürününün veya
modülünün işleyişini ve fonksiyonlarını
oluşturmaktadır.
Üniversite
yazılım
otomasyonlarında
standartlaşması en zor olan ürünlerden birisi
de Öğrenci Otomasyonudur. Yüksek seviyede
dikey derinliğe sahip olan bu otomasyonun
üniversiteden üniversiteye değişen onlarca
farklı süreci ve uygulaması bulunmaktadır.
Öğrenci otomasyonlarındaki Kayıtlanma
Modülü
de tüm üniversite
yazılım
otomasyonundaki en zor modüllerden
birisidir. Özellikle kökleşmiş, lisans ve
lisansüstü bölümlere sahip ve 10.000’lerce
öğrencisi olan üniversitelerde 100’lerce farklı
öğrenci kayıtlanma senaryosu bulunmaktadır.
Kayıtlanma modülündeki diğer zorluk da
öğrencilerin istediği dersi, dersin kontenjanı
dolmadan seçmek istemesidir. Öğrencileri bu
noktada
“Başlatılmayı
beklenen
bir
yarışmanın yarışmacılarına” benzetebiliriz.
Yarışmanın başlatılması yani kayıtlanma
sistemin açılması ile birlikte öğrencilerin tek
hedefleri “bir an önce istedikleri dersi seçmek
ve kayıtlanmayı tamamlamaktır”.
Tam da bu noktada üniversite kayıtlanma
modülü
yoğun
bir
stres
testinden
geçmektedir. Binlerce öğrenci interaktif bir
web uygulamasından sisteme girmekte ve
kayıt olmaya çalışmaktadır. Böyle bir
sistemin çalışması için çeşitli yazılım kalite
metriklerinden söz edilebilir ancak buradaki
en önemli konu sistemin performansını
bütünüyle ele almaktır: (a)Yazılım mimarisi
ve kalitesi, (b) Sunucu konfigürasyonu ve
mimarisi, (c) Ağ mimarisi.
Eğer yazılım sistem performansı bütünüyle
ele alınmaz ve sistem bu kullanıcı sayısını
kaldıramazsa, o an interaktif olan binlerce
öğrenci sistemle ilgili olumsuz düşünceye
kapılmakta
ve
bunu
çevreleri
ile
paylaşmaktadırlar.
1992 yılında kurulan Celal Bayar Üniversitesi
[2] (CBÜ) 2014 yılında Bilgisayar Araştırma
ve Uygulama Merkezini (BAUM), üniversite
yazılım geliştirme ve test süreçlerini
yönetmesi ve gerçekleştirmesi için yeniden
yapılandırmıştır.
Celal Bayar Üniversitesi 2013-2014 Bahar
kayıtlanma döneminde, kayıtlanma sisteminin
öğrencilere açıldığı ilk 30 dakika sonrasında
servis veremez hale gelmiştir. Bu kötü
tecrübe sonrasında CBÜ BAUM ekibi
Kayıtlanma Sistemini yeniden yazma kararı
almıştır. Çevik bir yazılım geliştirme yöntemi
olan Scrum kullanılarak 4 kişiden oluşan
(Yazılım Mimarı, Yazılım Görsel Arayüz
Uzmanı, Yazılım Veritabanı Uzmanı, Yazılım
Test Uzmanı) bir Kayıtlanma Ekibi
oluşturulmuş ve sistem en baştan analiz
edilerek yeniden geliştirilmiştir.
2014-2015 Güz kayıtlanma döneminde bu
yeni kayıtlanma sistemi hayata geçirilmiş ve
33.000 kullanıcının üzerinde yoğun bir
kullanıma rağmen, yüksek sistem performansı
ile ciddi bir başarı elde edilmiştir. Hem
yazılım performans metrikleri hem de
öğrencilerden gelen olumlu geri dönüşler
dikkate
alındığında
üniversitelerin
100.000’lerce
kullanıcıyı
kaldırabilecek
kaliteli yazılım ürünü geliştirmelerinin hayal
olmadığı net bir başarı hikayesi ile ortaya
konulmuştur. Tecrübe aktarımı niteliğindeki
bu bildiride, CBÜ BAUM tarafından
geliştirilen Yeni Kayıtlanma Modülünün
geliştirme süreçleri ve detayları hakkında
bilgilendirme yapılmıştır.
Bildirinin 2. bölümünde CBÜ BAUM
ekibinin yapılanması ve yazılım geliştirme
süreci ile ilgili bilgilendirme yapılmıştır. 3.
bölümde kayıtlanma sisteminin yeniden
geliştirilmesi ile ilgili süreçler, teknik detaylar
ve dikkat edilen yazılım geliştirme metrikleri
üzerinde durulmuştur. 4. bölümde yeni
kayıtlanma sisteminin hayata geçirilmesi ve
sonuçları üzerinde durulmuş ve bu sistemin
diğer
üniversitelerde
uygulanabilirliği
tartışılmıştır.
2. BAUM Ekibi, Yazılım Geliştirme ve Test
Süreci
CBÜ BAUM ekibi, üniversite yazılım
otomasyonlarının yönetilmesi, geliştirilmesi
ve test edilmesi amacıyla 2014 yılında
yeniden yapılandırılmıştır. Toplam 11
personel ve 1 müdürden oluşan ekibin tek
odağı yazılım ve testtir. Çevik yazılım
geliştirme yöntemlerinden olan SCRUM
pratikleri BAUM’un yazılım geliştirme süreç
temelini oluşturmaktadır.
SCRUM, hem ülkemizde hem dünyada
yaygın olarak kullanılan çevik yöntemlerden
biridir. 2013 yılında Agile Türkiye tarafından
gerçekleştirilen Yazılım Üretkenlik Raporu
sonuçlarına[4]
göre
de
Türkiye’deki
projelerin % 64’ünde çevik yöntemler
uygulanmaktadır. SCRUM gibi çevik
yöntemlerin üretkenliği [5], yazılım kalitesini
[6] ve ekip üyeleri arasındaki iletişimi
arttırdığı [7] bilinmektedir.
SCRUM temelde, yinelemeli bir yaşam
döngüsü tanımlamakta ve büyük iş
kalemlerinin, küçük ve yönetilebilir işlere
bölünmesi ve önceliklendirilmesi ile ilgili
yöntemleri içermektedir.
Şekil 1. SCRUM Süreci
BAUM’da genelde 2-3 haftalık sprintler
oluşturulur. Arka planda sürekli güncel
tutulan bir backlog bulunmaktadır. Zaman
zaman birimlerden gelen ve o dönemde
öncelikli olmayan iş maddeleri veya yazılım
ekibi
tarafından
öngörülen
sistem
iyileştirmeleri bu backloga girilir.
Her sprinti tek sprint takımı gerçekleştirir.
Sprint planlama genelde 1-2 gün zaman alan
bir süreçtir. Sprint planında hangi iş
maddelerinin olacağına ürün yöneticisi ve
müşteri temsilcisi karar verir. Müşteri
temsilcisi genelde üniversite idare biriminde
çalışan bir personel (Örn: Öğrenci İşleri,
Personel Şube müdürleri) veya Rektör
Danışmanıdır. Sprint planlaması yapılırken
yazılım uzmanlarına istediği işi seçme hakkı
verilir.
BAUM’da Scrum Master rolünü Yazılım
Mimarı gerçekleştirir. Scrum Master, ekibin
lideridir ve sprintin başarılı bir şekilde
tamamlanması için elinden geleni yapar.
Ekibin dış etkenlerden en az şekilde
etkileneceği bir çalışma ortamı sağlar. Günlük
sprint toplantılarını yönetir.
Yazılım kaynak kod kontrol yönetim aracı ve
SCRUM sürecindeki planların yönetimi ve
gerçekleştirilmesi amacıyla Microsoft TFS
(Team Foundation Server) ürünü [8]
kullanılmaktadır.
Yazılım
ve
test
aşamalarında
çalışan
tüm
BAUM
personelinin TFS sisteminde bir kullanıcı
grubu ve hesabı bulunmaktadır.
SCRUM Backlog, TFS sistemi üzerinde
tutulur ve tüm sprint planları yine TFS
sistemi üzerinde gerçekleştirilir. Plandaki her
iş maddesi için bir kullanıcı hikayesi
oluşturulur ve daha sonra her hikaye alt
görevler
ile
detaylandırılır.
Yazılım
uzmanlarına bu görevler delege edilir.
Yazılım uzmanları geliştirdikleri bir isteğin
veya çözdükleri bir hatanın ilk testlerini
yaptıktan sonra işi bütünüyle test etmesi ve
kapatması için TFS üzerinden ilgili test
uzmanına delege ederler.
BAUM yazılım geliştirme sürecinde 3 farklı
dağıtım ve uygulama ortam bulunmaktadır:
(1)Dev Ortamı: Sadece yazılım geliştirmenin
yapıldığı ve yazılım uzmanlarının kendi temel
testlerini yaptıkları ortamdır.
(2)Test Ortamı: Yapılan sprint geliştirmeleri
test uzmanları tarafından ilk olarak test
ortamında test edilir. Test ortamının gerçek
ortama çok yakın olması gerektiği için test
veritabanı ve sistemi düzenli olarak canlı
ortamdan kopyalanır.
(3)Prod
Ortamı:
Üniversite
yazılım
otomasyonunun çalıştığı canlı ortamdır.
Sprintlerdeki işler tamamlandıkça, sprint
sonlarında bu ortam güncellenir. Acil hata
çözümlerinde sprintin sonu beklenmeden,
güncelleme önce test ortamında yapılır, testler
sonucunda hatanın çözüldüğü gözlemlenirse,
canlı ortam güncellenir.
2.1. BAUM Test Süreci
BAUM test sürecinin tamamı yine TFS
sistemi üzerinden yürütülür. Sprintteki iş
maddelerinin kullanıcı hikayelerine karşılık
gelen yeni test senaryoları oluşturulur.
BAUM test ekibi ISTQB tarafından
belirlenen 7 test prensibini [9] duvarına asar
ve benimser.
Prensip 1: Testler hataların varlığını gösterir.
Yazılım testleri hataların var olduğunu
gösterir fakat hiç bir hata kalmayacağını
garanti etmez.
Prensip 2: Yazılım ürünün komple test
edilmesi mümkün değildir.
Prensip 3: Erken test (Early testing).
Yazılım geliştirme süreci ne olursa olsun, test
aktivitesine mümkün olan en erken zamanda
başlanmalıdır.
Prensip 4: Hataların kümelenmesi (Defect
clustering).
Hatalar,
yazılımın
belirli
bölümlerinde kümelenebilir.
Prensip 5: DNT paradoksu (Pesticide
paradox). Tekrarlayan aynı tipteki test
aktiviteleri, yazılımda benzer hataların
bulunmasına neden olurlar. Dolayısıyla, test
koşulları sürekli yenilenmeli ve revize
edilmelidir. Amacımız bataklıkta sivrisinek
avlamak değil, bataklığı kurutmak olmalıdır.
Prensip 6: Testler içerik ve durum
bağımlıdır. Yazılımın modül içeriğine veya
kullanım durumlarına bakılarak farklı tipte
veya derinlikte test aktiviteleri uygulanabilir.
Prensip 7: Hatalar %100 giderilemez. Test
aktiviteleri esnasında hataların bulunması,
yazılımın hatalardan %100 arındırıldığı veya
son
kullanıcının
ihtiyaçlarının
%100
kapsandığı anlamına gelmez.
BAUM test uzmanı kendisine delege edilen
bir istekle ilgili temelde 4 test yapar:
1. Duman Testi: Genel anlamda ürünün ilk
çalıştırılmasında duman çıkıp çıkmama testi
olarak görülür. Bir bileşenin veya sistemin
ana görevinin en can alıcı veya kritik
fonksiyonlarının çalıştığını görmek için
detaydan uzak planlanmış\tanımlanmış tüm
test koşullarının kapsandığı test biçimidir.
2. Fonksiyon Testi: Kodların minimum veri
ile beklenen fonksiyonları ve işlevi yerine
getirdiğinden emin olunması için yapılan test
biçimidir. Genelde Kullanıcı Hikayeleri ve
Test Senaryoları baz alınarak yapılırlar.
3. Ekran Standartları Testi: Yazılım ürünün
belirlenen
ekran
standartlarına
uyup
uymadığının kontrol edildiği test biçimidir.
4. Kullanılabilirlik Testi: Gerçek hayat
kullanım koşulları altında bir yazılımın kolay
anlatılabilir, öğrenilebilir, kolay kullanılabilir
ve kullanıcıya cazip gelme standartlarını
içeren test türüdür.
Özellikle
doğrulama
(validation)
ve
kayıtlanma kuralları için esnek bir katman
tasarlanmıştır.
Bunun
sebebi
CBÜ
Kayıtlanma Yönetmeliğinde ileride olabilecek
değişikliklerin yazılım bakım maliyetinin
minimum düzeyde tutulmak istenmesidir.
Örneğin: Öğrencinin Alması Gereken,
Alabileceği ve/veya Seçebileceği derslerde
standart bir kural değişikliği olursa, değişiklik
maliyetinin test süreci dahil 1 saati
geçmemesi hedeflenmiştir.
Bu testlere ek olarak sprint tamamlandıktan
sonra beklenmeyen etkilerin tespiti ve
ölçümlenmesi için Test Uzmanı tarafından
Basit Regresyon Testi yapılır. Ürünle ilgili
önemli ve etkilenebilecek kısımlar baştan test
edilirler.
3. Öğrenci Kayıtlanma Modülü Yeniden
Yazılma Süreci
Şekil 3. Kod haritası
Öğrenci Kayıtlanma Modülünün yazılım
geliştirme ve test süreci 3'er haftalık toplam 4
sprintte tamamlanmıştır. Nesneye dayalı
modelleme yaklaşımı ile Öğrenci Kayıtlanma
Süreci yeniden modellenmiştir. Modelleme
sürecinde UML durum senaryoları ve sınıf
diyagramları oluşturulmuştur.
Toplam 210 tane kullanım senaryosu (usecase) çıkartılmıştır. Her senaryo üzerinden
Scrum ekibi ve öğrenci işleri ekibi birlikte
geçmiş ve senaryolar doğrulanmıştır. Bu
kullanım senaryoları, daha sonra test
senaryolarına dönüştürülmüştür.
Öğrenci kayıtlanma ekranları kullanıcı
deneyim kriterleri göz önünde bulundurularak
yeniden tasarlanmıştır. Ekranların tasarımında
basitliğe ve kullanım kolaylığına dikkat
edilmiştir. Ekranlarda etkin görselliği
yakalamak için ağırlıklı olarak CSS3[11]
teknolojisi kullanılmıştır.
Şekil 2. UML sınıf diyagramından bir bölüm


Şekil 4. Örnek Kayıt Ekranı
Üniversite sistemindeki kullanıcı sayısı
(Öğrenciler, Akademisyenler, Öğrenci İşleri
İdari Personel) 45.000’in üzerinde olduğu ve
kayıtlanma modülü, ekranlar dahil baştan
geliştirildiği için kayıtlanma modülü eğitim
videoları BAUM test departmanı tarafından
oluşturulmuş ve ilgili web ekranlarına kısa
yolları yerleştirilmiştir. Eğitim videolarının
toplam izleyici sayısı yaklaşık 13.000’dir.
Yazılım geliştirme sürecinde sürekli dikkat
edilen bazı önemli noktalar ve yapılan genel
performans iyileştirmeleri aşağıdaki gibi
özetlenebilir:





Web sayfalarının ebatları minimum
seviyede tutulmuştur.
Sunuculara giden toplam istek (request)
sayısı olabildiğince azaltılmıştır.
Yük optimizasyonu için harici CDN'ler
kullanılmıştır.
Java script dosyaları minify edilmiştir.
Java script dosyaları, CSS dosyaları,
resim dosyaları gibi statik içeriğe sahip
dosyalar cachlenmiştir.
4. Deneysel Sonuçlar
Kayıtlanma modülü 15 Eylül 2014 saat
10:00’da devreye alındıktan sonra ilk 30
dakikada gözlemlenen metrikler aşağıdaki
gibidir:
 Toplam 33.274 öğrenci sisteme girmiştir.
 Toplam 272.387 ders seçilmiştir.
 Ortalama sistem cevap verme süresi
(Average Response Time) 0,8 sndir.
 Ortalama web sunucu yoğunluğu (CPU)
%10 dur.
Ortalama servis sunucu yoğunluğu
(CPU) %12 dir.
Ortalama veritabanı sunucu yoğunluğu
(CPU) %8 dir.
Sistemi devreye alınmadan önce modülün
kodlama ve test sürecinde yaklaşık 40 hata
tespit edilmiş ve çözülmüştür. Sistem devreye
alındıktan sonraki 2 hafta kullanım sürecinde
yazılım modülü ile ilgili hiç hata çıkmamış
olup sadece 1 tane geliştirme yapılmıştır.
5. Tartışma ve Öneriler
Teknolojinin hızla ilerlediği bu dönemde
üniversitelerde kullanılan yazılım otomasyon
sistemlerinin bu duruma ayak uyduramaması
önemli bir problemdir. Bu duruma ilave
olarak; üniversitelerin Bilgisayar Bilimleri,
Bilgisayar
Mühendisliği,
Yazılım
Mühendisliği ve Bilgisayar Programcılığı gibi
bölümleriyle bu sektör için uzman personel
yetiştirdiğini düşünürsek, olay farklı bir boyut
almakta ve maalesef “Terzi kendi söküğünü
dikemiyor” sonucu ortaya çıkmaktadır.
Tecrübe aktarımı niteliğindeki bu bildiride,
CBÜ BAUM tarafından geliştirilen Yeni
Kayıtlanma Modülünün geliştirme süreçleri
ve
detayları
hakkında
bilgilendirme
yapılmıştır.
Deneysel sonuçlarda da görüldüğü üzere
hayata geçirilen bu modül, 33.000
kullanıcının üzerinde yoğun bir kullanıma
rağmen, yüksek sistem performansı ve sıfır
hata sayısı ile ciddi bir başarı elde etmiştir.
Hem yazılım performans metrikleri hem de
öğrencilerden gelen olumlu geri dönüşler
dikkate
alındığında
üniversitelerin
100.000’lerce
kullanıcıyı
kaldırabilecek
kaliteli yazılım ürünü geliştirmelerinin hayal
olmadığı ortadadır.
Kaynaklar
[1] Nermin SÖKMEN, Türkiye’de Yazılım
Üreticilerinin Yetkinlik Düzeyi, Firmaların ve
Sektörün Gelişimi
BILGEM.
cilt
1,
TUBITAK,
[2] Celal Bayar Üniversitesi
http://www.cbu.edu.tr,
Erişim
01/09/2014
tanıtımı,
tarihi:
[3] Yükseköğretim Kurulu (YÖK) tanıtımı,
http://www.yok.gov.tr,
Erişim
tarihi:
03/09/2014
[4] Agile Türkiye, 2013 Software Production
Report. http://www.agileturkey.org/ (2013)
[5] Sutherland, J., Jakobsen, C.R., Johnson,
K.: Scrum and CMMI Level 5: The Magic
Potion for Code Warriors. In: Proceedings of
the 41st Annual Hawaii International
Conference on System Sciences (2008)
[6] Livermore, J. A.: Factors that impact
implementing an agile software development
methodology. In: SoutheastCon Proceedings,
IEEE, pp. 82- 86 (2007)
[7] Pikkarainen, M., Haikara, J., Salo, O.,
Abrahamsson, P., Still, J.: The impact of agile
practices on communication in software
development.
Empirical
Software
Engineerging, 13 (3), pp. 303-337. (2008)
[8] Microsoft Team Foundation Server,
http://en.wikipedia.org/wiki/Team_Foundatio
n_Server, Erişim tarihi: 01.10.2014
[9] ISTQB test prensipleri, http://softwaretesting.pl/en/basics-of-software-testing/seventesting-principles-by-istqb, Erişim tarihi:
02.10.2014
[10] Celal Bayar Üniversite ÖnLisans ve
Lisans Eğitim ve Öğretim Yönetmeliği,
http://www.bayar.edu.tr/ogrenci/onlisans_ve_
lisans_egitim_ve_ogretim_yonetmeligi_yeni.
php, Erişim tarihi: 05.10.2014
[11] CSS3 teknolojisi ile ilgili genel tanıtım,
http://www.w3schools.com/css/css3_intro.asp
, Erişim tarihi: 02.10.2014
Author
Document
Category
Uncategorized
Views
2
File Size
598 KB
Tags
1/--pages
Report inappropriate content