Öğretim tasarımı sürecinin son aşaması değerlendirmedir. Burada, başlangıçta saptanan eğitim gereksinimlerini gidermek üzere geliştirilmiş olan öğrenme sisteminin kendi özgül işlevini ne oranda yerine getirebileceği belirlenmeye çalışılmaktadır. Başka bir deyişle, geliştirilen sistem gerçek koşullarda uygulanmadan önce test edilmekte ve gelecekteki değerlendirme üzerinde durulmaktadır. Bunlar ara değerlendirme ve son değerlendirmedir.
Ara Değerlendirme: Sistemdeki olası hata ve eksiklerin araştırılarak gerekli düzeltmelerin yapılması işlemleridir. Bu amaca dönük olarak, akran incelemesi, bire-bir değerlendirme ve alan testi gibi işlemler yapılmaktadır. Öğretim tasarımcısının geliştirdiği ama henüz kesinleşmiş saymadığı ürün, meslektaşları tarafından incelenerek eleştiri ve öneriler getirilir(akran değerlendirme). Ürünü gerçek yaşamda kullanacak olan öğrenci kitlesini temsil edebilecek nitelikte küçük bir örneklem alınır ve bu insanlar ürünü bireysel biçimde sınayarak hataları bulmaya yada öneriler sunmaya başlar (Birebir değerlendirme)
Son Değerlendirme: Geliştirilen öğrenme sistemini müşteri gözüyle inceleyip kullanma ya da yaygınlaştırma konusunda karar vermeyi amaçlamaktadır. Burada yanıt aranan soru şudur: Eğitim sorunlarının çözümü için geliştirilen programın uygulaması yaygınlaştırılırsa, bunun kısa ve uzun dönemdeki sonuçları neler olabilir?
Değerlendirme aşamasında yapılan çalışmalar yalnızca ürün üzerinde yürütülen tartışmayla sınırlı değildir. Geliştirilen ürünün kullanılması ya da öngörülen eğitimin yapılması durumunda ne tür bir etkinin ortaya çıkacağı da ele alınmalıdır.
Aşamalar
İşlemler
Çıktılar
Analiz
Gereksinimleri saptama Hedef kitleyi inceleme Kurumsal çözümleme Eğitim önceliklerini belirleme
Veriler
Tasarımlama
Amaçları yazma içeriği seçme ve düzeltme Stratejileri geliştirme Ölçme araçlarını hazırlama
Kararlar
Geliştirme
Ders planlarını geliştirme Eğitici kılavuzunu hazırlama Görsel-işitsel gereçleri üretme
Ürünler
Uygulama
Zaman çizelgesi yapma Bütçeyi hazırlama Ortam düzenleme Eğiticileri eğitimden geçirme
Planlar
Değerlendirme
Ara değerlendirme yapma Hata ve eksiklikleri düzeltme Son değerlendirme yapma Gelecek kestirimlerde bulunma
Değerlendirme genel anlamda bir ölçme sonucunu bir ölçütle karşılaştırarak bir değer yargısına varmak demektir. Öğrencilerin belirlenen öğretim amaçlarını kazanıp kazanmadığı iki değerlendirme türü ile ifade edilebilir; süreci değerlendirme, ürünü değerlendirme (Şekil 1).
Süreci değerlendirme, 1967 yılında Michael Scriven tarafından ortaya atılmıştır. Süreç değerlendirme, uygulanan tasarımın ne kadar verimli olduğunu belirlemek, aksayan ve eksik kalan yönlerini belirlemek ve bunların giderilmesi için gerekli önlemleri almak amacıyla yapılır. Bu şekilde ürünün geliştirilmesi sürecinde ve sonunda yapılan kontrol süreci, öğretmene veya tasarımcıya ürünün daha iyi yapılandırılması için geri bildirim sağlamaktadır.
Ürün değerlendirmesi öğretim tasarım süreci tamamlandıktan sonra yapılır. Tasarım sonunda ortaya çıkan ürünün etkili olup olmadığını ortaya çıkarmak için yapılır. Elde edilen bulguları tasarımcılar yeni Eğitimde Materyal Tasarımı ve Kullanımı 8 müfredat programlarında veya özgün bir ürünü geliştirmek için kullanabilir.
Uygulamayla
ilgi olarak özellikle zaman çizelgelerinin hazırlanması, eğitimin yapılacağı
çevrenin düzenlenmesi, maliyete ilişkin hesaplamaların yapılması ve
eğiticilerin eğitimi gibi işlemler tamamlanır. Eğitimin yürütüleceği yer
seçilirken yada çevre ayarlaması yapılırken öğrencilerin sağlık, ulaşım ve
güvenliğinin yanı sıra, ergonomik açıdan öğrenmeyi kolaylaştıracak olumlu bir
atmosfer oluşturulmalıdır. Ayrıca seçilen ortam, değişik öğretim yöntemlerinin
öngördüğü bireysel yada kubaşık çalışma biçimlerine olanak sağlamalıdır.
Proje Uygulama Aşaması?
Proje, uygulama safhasına geldiğinde, proje ekibi ve gerekli kaynaklar
aktivitelerin gerçekleştirilmesi için öngörülen yerlerinde olmalı, proje planı
ise geliştirilmiş ve temellendirilmiş olmalıdır.
Proje Yönetimi
ekibi için bu aşamada gerçekleştirilmesi gereken kritik faktörler;
Aktivitelerin
planlanan ve gerçekleşen performanslarını izlemek
Olayları
gözden geçirmek ve gerekli komünikasyonu kurmak
Potansiyel
riskleri izlemek ve etkilerini düşürmek, tekrarlanma olasılığını azaltmak
Proje
amaçlarında, speklerinde ve tüm tanımında değişimleri kontrol etmek için
değişim yönetim süreci kurmak
Yeniden
planlama prensiplerini oluşturmak.
Proje Kontrol Süreci
Proje planı
projenin izlenmesi, kontrolü ve raporlaması için temel oluşturur. Planın
ardından toplantılardan ve raporlardan gelen bilgiler problemlerin erken
farkedilmesini, proje riskleri düşürülmesini, izleme ve kontrol ve raporlama
süreçlerinin tanımlanmasını sağlar.
Proje Gözden Geçirme ve İzleme
Proje
uygulama aşamasına geldiğinde, bilginin doğru ve düzgün akması gereklidir. Bu
aşamada proje ekibinin ve proje yöneticisinin dikkati yapılacakların izlenmesi
ve gözden geçirilmesi ile ilgili yolları keşfetmekte olacaktır. Bu bilgi
aşağıdaki şekilde olacaktır;
Yazılı
durum raporları
Güncellemeler
Finansal
Analizler, planlanan maliyetlerle gerçekleşenlerin ve bunlar arasındaki
farkların ölçümleri
Hariç
Raporu
Projeye ait
istenen bilgi proje ekibinden gelmektedir. Amaç performans, zaman, maliyet ve
kapsam bileşenlerinin izlenmesidir.
Harita Olarak Proje Planı
İzlemeye
başlamak bir başlangıç noktası gerekir. Bunuda Proje Planı sağlar. Hatta
mükemmel olmayan bir proje planı bile izlemeye başlamak için iyi bir fırsattır.
Proje planında izlenecek ve denetlenecek planlı bileşenler görülebilir.
Planlama
hangi bileşenlerin ne sıklıkta izlenmesi gerektiğini belirtir şekilde
hazırlanmalıdır. Proje Planı, temel plan dikkate alınarak projenin belirli bir
zamanda bulunduğu noktada değerlendirilmesini sağlayacak pratik ve çalışır bir
metod sunmalıdır.
Planlar
proje değişiklikleri ortamında değişen canlı varlıklardır. Yeni IT dünyası
başarıyı strateji, proje kaynakları ve personel'de görmektedir. Bunlara
konsantre olunmalı ve çok dikkatlice
izlenmelidirler.
Temel Proje Planı
İzleme yapabilmek için proje planında yer alması
gerekenler;
İş
tanımı.
Fonksiyonel
spesifikasyonlar ve ilgili dokümanlar.
Başarı
faktörleri.
İş
Ayrışım Yapısı (İAY -- aktivite listesi ve aktivite ağ diyagramı.
Organizasyon
Şeması
Bütçe
ve Zaman Tahminleri (mümkünse kabulleriyle birlikte)
Finans
ve fonlama planları.
Kalite
ve konfigürasyon yönetim planları.
İlgililer
Analizi, orta yönetim ve mü?teriler dahil.
Neden İzleme ve Takip?
Birer
yönetim fonksiyonu olarak izleme ve denetim etkin ve etkili proje yönetimi için
vazgeçilmezdir. Bu metodolojide izleme sorun bulma, takip ise sonuçların
değerlendirilmesi ve analizidir.
Kontrol
süreçleri neler olduğunu göstermez, sadece bulunulan durumda devam edilirse
gelecekte nelerle karşılaşılabileceğini gösterir.
Her proje ekibi performansı değerlendirebilmek için
gerçekleşenle planlananı karşılaştırmalıdır.
SORU:
Proje nasıl gidiyor?
İzleme ve takip süreçlerinde elde edilen bilgi, proje durumu hakkında bir
yargıya varılabilmesine ve düzeltici eylemin gerekip gerekmediğinin kararının
verebilmesine yetmelidir;
Genel
Proje programı, maliyet, teknik
performans, amaçlar ve hedeflerin neresindeyiz?
Bitmesi gereken aktiviteler ne
durumda?
Şu anki durum gelecekteki
aktiviteleri nasıl etkileyebilir?
Projede doğru gidenler nedir?
Yanlış gidenler nedir?
Yeni fırsatlar yakaladık mı?
Yeni ihtiyaçlar var mı?
Proje ile ilgililer sonuçlardan
memnunlar mı?
Organizasyon
Proje ekip yapısı verimli ve
uygun mu?
Proje yöneticisi yeterli
kontrol ve yetkiye sahip midir?
Projedeki kilit roller
belirlenmi? midir?
Proje ekibi yaratıcı ve
geliştirici mi?
Proje ekibi işlerin nasıl
gittiğinden haberdar mı?
Değişiklik isteklerinin
değerlendirildiği bir metod var mı?
Proje ekibi ilgililerin
görüşlerini alıyor mu?
Nasıl ve Ne izlenecek?
Önemli ve yönetimsel bir konu olarak, her projede
kritik bilginin aktarılmasını sağlayıcı süreçler geliştirilmelidir.
Planlama sürecinde, proje yöneticisi doğru detay
seviyesini belirleyerek proje raporlarının gerçekçi ve çabuk hazırlanmasını
sağlamalıdır.
Genel kural olarak izleme ile ilgili tüm materyaller
proje ürünü hesaba katılarak planlanmalıdır. Bilgi, üst yönetime doğru
taşındıkça detay seviyesi düşürülmelidir.
Örnek
Raporlama Tanımı:
Yazılım alanındaki her ekibin verdiği durum raporu
tüm alanları ifade edecek şekilde 2 sayfa olarak Proje Yöneticisine iletilmelidir.
Proje Yöneticisi tüm alanlardan topladığı 10 sayfa raporu tek sayfa halinde
idari rapor haline dönü?türmelidir. Bu süreç zamanla otomatikle?erek
yürütülmelidir.
"Nasıl ve ne izlenecektir?" hafife alınmaması gereken önemli
sorulardır. Proje yöneticisi, projenin karmaşa düzeyine göre, önce izleme ve
takip ile ilgili kritik noktalara fokus olmalı, sonra ikinci öncelikli konulara
yönelmelidir.
Minimum izleme ve takip bileşenleri;
·Durum şimdiki aktiviteler ve planlanan
aktiviteler
·Planlanan işlerle gerçekleşenleri
karşılaştırarak şimdiki pozisyonu değerlendirmek.
·Planlanan ve gerçekle?en aktivite ba?lama/biti?
tarihleri
·Program sapmalarının değerlendirilmesi ve projeye
etkilerinin tanımlanması
·Gerçekleşen harcama ile planlanan bütçenin
karşılaştırılması.
·Bugüne kadar gerçekleşen harcamalar
·Bulunulan tarihte projeyi tamamlanmak için
gerekli bütçe tahmini
·Proje bittiğinde beklenen toplam harcama
·Projenin tüm geliştirme aşamalarından gelen
teknik performans ve kalite göstergeleri
Proje Takip
Planlanan - Gerçekleşen Maliyetler
Proje yöneticisi bu karşılaştırmalarla, planın
kullanılmaya devam etmesine ya da planın güncellenmesine karar verebilir.
Planlananla gerçekleşen arasındaki fark yeniden
planlama yapılmasını gerektirecek kadar farklılık gösterdiğinde bütçelerinde
güncellenmeleri gerekir. Plandan ne kadar sapıldığı ise bazı standartlar
kullanılarak hesaplanabilir. Bazı organizasyonlar, maliyet yada bütçe planlanı
%10 aşıldığında Finansal Rapor şartı getirmektedir. Bu suretle organizasyon
kendi için önemli olan sapma yada değişiklik miktarını belirlemektedir.
Genel
uygulama aşağıdaki gibidir;
Her
aktivitenin süre ve direk maliyetleri tahmin edilir.
Gerçekleşme
bilgileri geldikten sonra kalan iş ve buna bağlı maliyetler tahmin edilir.
Bugüne
kadar gerçekle?en maliyetler bulunur
Proje
için kullanılabilecek yada gereken fon miktarı belirlenir.
Eğer
maliyetler artacaksa o zaman;
Proje
yeniden maliyetlendirilebilir,
Geri
kalan maliyetler eldeki fonlarla karşılanana kadar gereksiz ve önemsiz
gereksinimler elimine edilir,
İdari
yönetime, gelinen noktadaki proje maliyetinin tahmin edilenden daha fazla
olacağı ve gerekli kaynakların yaratılması gerektiği söylenir.
Yazılım
geliştirme sürecindeki dört temel aktivite genelde tüm yazılım geliştirme
süreçlerinde kullanılmakta ve bu aktiviteler sırasında bilgisayar destekli
yazılım geliştirme araçlarından yaygın bir şekilde istifade edilmektedir. Dört
temel yazılım geliştirme aktivitesi; tanımlama, geliştirme, doğrulama ve
iyileştirme aşamalarından oluşmaktadır.
Yazılım Geliştirme Süreci Nedir?
Bilinenin
ve sıklıkla uygulananın aksine yazılım geliştirme hadi “yeni bir proje açalım,
bir form çekelim” şeklinde yapılmaz. İlk olarak yazılımdan ne beklendiğinin
belirlenmesi gerekir. Yani çözümün tanımlanmasıyla başlanır yazılım
projelerine. Ardından çözümün geliştirilmesi adımı gelir. Son olarak da çözüm
müşteriye kurulur ve bakım/destek süreci başlar.
Yazılım İsteği
İstek Analizi
Müşteri Geribildirimi
Proje Planlaması
Proje Dökümantasyonu
Yazılım Geliştirme Aşaması
Test Aşaması
Yazılım Dökümantasyonu
Yazılım Geliştirme Süreç Modelleri
Bu
yazımda yazılım mühendisliği dersinde görmüş olduğumuz yazılım süreç
modellerinden bahsedeceğim. Yazılım ile ilgilenen ve küçük-büyük projelerde yer
alan-alacak olan herkesin bilmesi gereken modellerdir. Geçmişten günümüze
kullanılmış olan modellerden kısaca bahsederek bunları bilmemizin bizlere ne
gibi katkılar sağlayacağını, ne gibi getirileri olacağını daha iyi
anlayabiliriz. Yazılım geliştirmek için kullanacağımız bu modeller planlı
çalışmamızı ve geliştireceğimiz yazılımları en iyi biçimde geliştirmemizi
sağlaycaktır. Şimdi bu modellerin bir kısmına kısaca göz atalım.
1. Gelişigüzel Model
Bu süreç modelinde herhangi bir yöntem yoktur. Yazılım tamamen geliştiren
kişiye bağlıdır. İleri zamanlarda geliştirilen yazılımı hazırlayan kişi bile
anlamakta zorluk çekebilir. Bu yüzden izlenebilirliği ve bakımı çok zordur.
Daha çok 1960'lı yıllarda kullanılan bir yöntemdir. Genellikle tek başına
yazılım geliştirenler tarafından tercih edilmiştir. Geliştirilen yazılımın programlaması
diğer metotlarla geliştirilen yazılımların programlamasına göre basittir.
2. Barok Modeli
Bu modelde yazılım yaşam döngüsünün temel adımları doğrusal bir biçimde takip
edilir. Daha çok 1970'li yıllarda kullanılmış bir yöntemdir. Adımlar arası ilişkilerin
tanımlı olmadığı bir yöntemdir. Günümüzde pek kullanılmayan bir yöntemdir.
Bunun en büyük nedeni ise "Belgeleme" adımının bu modelde ayrı bir
adım gibi ele alınıp yazılımın geliştirilmesi ve testinin ardından
yapılmasıdır. Günümüzde kullanılan modellere aykırı bir durumdur. Günümüzde
tercih edilen modellerde "Belgeleme" geliştirilen yazılımın ürünü
olarak kabul edilmektedir. Ayrıca "Gerçekleştirme" adımını daha fazla
ağırlık veren bir modeldir.
3. Çağlayan (Şelale) Modeli
Bu modelde yazılım yaşam döngüsü adımları baştan sona en az bir kez izlenir.
İyi tanımlanmış projelerde ve yapımı için az süre gerektiren projelerde tercih
edilen bir yöntemdir. Geleneksel model olarak da adlandırılır. Ancak günümüzde
pek fazla kullanılmamaktadır. Barok modeline göre "Belgeleme" adımını
ayrı bir adım gibi almaz ve yazılımın ürünü olarak ele alır. Ayrıca Barok
modelinde olmayan adımlar arası ilişkiler bu modelde tanımlanmıştır. Ancak bu
modelde karşılaşılacak problemler vardır. Adımlar arası ilişkilerden dolayı yineleme
olabilir. Yazılımın kullanıcıya ulaşma zamanı uzundur. Gereksinimi analizi iyi
yapılmadığı takdirde adımlarda yineleme meydana gelir ve bu sebeple maliyet
artar. Yazılım geliştiriciler bir an önce yazılımın sonuçlanmasını isterler ve
bu sebeple kodlama dışı işlere önem vermezler.
4. V Modeli
Bu modelde adından da anlaşılacağı gibi "V" yapısında bir yol izlenir
ve adımlar bu şekilde gerçekleştirilir. Bu yol üzerinde sol taraf üretimi sağ
taraf ise test işlemini ifade eder. Bu modelde yer alan çıktıları
"Kullanıcı Modeli", "Mimari Model" ve "Gerçekleştirim
Modeli" adı altında toplayabiliriz. Kullanıcı modelinde geliştirme
sürecinin kullanıcı ile olan ilişkileri tanımlanmakta ve sistemin nasıl kabul
edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır.
Mimari modelde sistem tasarımı ve oluşacak alt sistem ile tüm sistemin sınama
işlemlerine ilişkin işlevler ele alınmaktadır. Gerçekleştirim modelinde de
yazılım modüllerinin kodlanması ve sınanmasına ilişkin fonksiyonlar ele alınmaktadır.
Bu model belirsizliklerin az iş tanımlarının belirgin olduğu bilişim
teknolojileri projeleri için uygun bir modeldir. Ayrıca model kullanıcının
projeye katkısını artırmaktadır.
5. Helezonik (Spiral) Model
Bu modelde risk analizi ön plana çıkmıştır. Yinelemeli artımsal bir yaklaşım
vardır. Her döngü bir fazı ifade eder ve doğrudan adım tanımlama gibi bir faz
yoktur. Ayrıca prototip yaklaşımı vardır. Bu modelde süreç 4 gruba ayrılır. Bu
süreçler planlama, risk analizi, üretim, kullanıcı değerlendirmesidir. Planlama
üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen
ara ürün ile bütünleştirmeyi sağlar. Risk analizi risk seçeneklerinin
araştırılması ve risklerin belirlenmesini sağlar. Üretim ara ürünün
üretilmesini sağlar. Kullanıcı değerlendirmesi ise ara ürün ile ilgili olarak
kullanıcı tarafından yapılan sınama ve değerlendirmelerini ele alır. Bu modelin
avantajları vardır. İlki üretim süreci boyunca ara ürün üretme ve üretilen ara
ürünün kullanıcı tarafından sınanması temeline dayanır. Yazılımı kullanacak
personelin sürece erken katılması ileride oluşabilecek istenmeyen durumları
engeller. Diğer bir avantajı gerek proje sahibi, gerekse yüklenici tarafındaki
yöneticiler, çalışan yazılımlarla proje boyunca karşılaştıkları için daha kolay
izleme ve hak ediş planlaması yapılır. Avantajlarından biri de yazılımın
kodlanması ve sınanması daha erken başlar.
6. Evrimsel Model
Bu model ilk tam ölçekli modeldir. Coğrafik olarak geniş alana yayılmış, çok
birimli organizasyonlar için önerilmektedir (banka uygulamaları). Her adımda
üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler.
Modelin başarısı ilk evrimin başarısına bağımlıdır. Zor kısımları mevcuttur.
Değişiklik denetimi ve konfigürasyon yönetimi bu modelin zorluklarıdır.
7. Artırımsal Model
Bu modelde üretilen her yazılım sürümü birbirini kapsayacak ve giderek artan
sayıda işlev içerecek şekilde geliştirilir. Uzun zaman alabilecek ve sistemin
eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir.
Örneğin öğrencilerin bir dönem boyunca geliştirmeleri gereken bir programlama
ödevinin 2 haftada bir gelişiminin izlenmesi gibi (bitirme tezleri). Bir
taraftan kullanım, diğer taraftan üretim yapılır.
8. Araştırma Tabanlı Model
Bu model yap-at prototipi olarak da bilinir. Araştırma ortamları bütünüyle
belirsizlik üzerine çalışan ortamlardır. Yapılacak işlerden edinilecek sonuçlar
belirgin değildir. Geliştirilen yazılımlar genellikle sınırlı sayıda kullanılır
ve kullanım bittikten sonra işe yaramaz hale gelir ve atılır. Model-zaman-fiyat
kestirimi olmadığı için sabit fiyat sözleşmelerinde uygun değildir. Bu model
için örnek yazılım projeleri olarak şu örnekleri verebiliriz: en hızlı çalışan
asal sayı test programı, en büyük asal sayıyı bulma programı, satranç programı
gibi.
Bu modeller süreç modellemeleri için geliştirilmiş modellerden sadece birkaçı.
Bunlar dışında geliştirilmiş veya bu modeller kullanılarak geliştirilmiş farklı
ve kullanılan modeller de mevcuttur. Kaliteli ve başarılı bir yazılım
geliştirmek için bu modellerden birini tercih etmeli veya kendi
modelimizi oluşturmalı ve kullanmalıyız. Böylece daha kaliteli daha başarılı
yazılımlar geliştirmeye adım atmış olacağız.
Tasarım
hazırlanarak sayfada bulunacaklar (menüler) hakkında ve kullanıcı yetkileri
hakkında ayrıntılı rapor hazırlanıp öğretim görevlileriyle görüştük. Geliştirme
aşamasında ihtiyacımız olacak geniş kapsamlı bir rapor hazırlandı.
Tasarım Hakkında Ne Biliyorsunuz?
Bir ürünün
tamamının veya bir parçasının çizgi,şekil,renk,biçim,doku,malzemenin esnekliği
veya süslemesi gibi insan duyuları ile algılanabilen çeşitli unsur ve
özelliklerin oluşturduğu görünümdür.
Tasarım bilgi
edinme öğesidir. Çünkü, duyumsal tasarım ile zihinsel tasarım daima
birbirini etkiler. Bu nedenle duyumsal bilgi ile ussal bilgi her zaman iç
içedir. Gerçek bilgi ise böylelikle oluşur.
Tasarım Amacı Nedir?
·Web Sitesi içeriğinin, Ölçme ve
değerlendirme bölümünü tam olarak yansıtacak şekilde düzenlenmesi,Sitenin kullanışlı olması,
siteye girenlerin gerekli bilgileri elde edebilmesi,Görsellik– İşlevsellik
açısından zengin olması için çalışılacaktır. Proje tasarım
öğeleri (renk, şekil, alan, doku, boyut, çizgi) ve tasarım ilkeleri (bütünlük, denge, vurgu, hizalama, yakınlık) göz önünde bulundurularak
oluşturulacaktır.
Uyguladığınız Tasarım Süreci
Bu projede Ölçme ve Değerlendirme
bölümü hocalarının istekleri doğrultusunda;
Yönetici Paneli
Öğretim elemanlarının geniş CV’leri,
Bölümün tanıtımı (tanıtıcı bilgi ve resimler),
Bölüm hocalarının yayınladıkları kitap ve makaleler,
Ders materyalleri (doc, ppt, pdf, jpeg türü dosyalarla verilecektir.), Sınav
tarihleri, Sınav sonuçları
Duyurular,
Ders içerikleri,
Ders Programları,
Sık kullanılanlar(Linkler),
Mimari Tasarım
Veri Tasarımı
Veriler Access
veritabanında tutulacaktır.
Arayüz Tasarımı
Bu kısımda, Anabilim Dalı başkanı bizden çeşitli arayüzler
hazırlayıp kendisine sunmamızı istedi ancak rahatsız olduğundan görüşemedik
bundan dolayı ilerleyen zamanlarada anabilim dalı başkanının onaylamış olduğu
arayüzünü yayınlayacağız.
Zaman Çizelgesi
Yapılacaklar
1
Projemizin Analiz aşamasında neler yapılmalıdır?
2
Analiz çalışması bitirilmiş olmalıdır.
3
Yazılım geliştirme sürecinde tasarım (design) aşamasında neler
yapılmalıdır? Projenizin tasarım aşamasında neler yapılmalıdır?
Sorunu Araştırma ve Tanımlama, Çözümü Tartışma Sorunlar
Mevcut sayfanın yetersiz oluşu, görselliğinin bulunmaması beklentileri karşılayamaması.
Bu eksiklikler doğrultusunda web sayfasında;
a) İçerik olarak;
1. Ölçme Değerlendirme bölümünün kapsamı, 2. Bölümün öğretim elemanlarının CV’leri (daha fazla bilgi), 3. Bölüm ile ilgili Güncel duyuruların yer alması, 4. Bölüm hakkında daha fazla bilgi sunma,
5.Yararlı linkler
b) Tasarım olarak;
1. Sayfanın görselliğini artırmak, 2. Herkes tarafından kullanılabilir ve anlaşılır olması amaçlanmaktadır.
Tasarımın Genel Özelliklerini Belirleme
Hazırlanacak web sayfasında;
Yönetici: Anabilim dalı Başkanı yönetici olarak belirlenecek.
Öğretim elemanları: Kendi CV’lerine ekleme çıkarma yapabilecek. Dosya paylaşımı yapabilecek. Sınav tarihlerini sınav sonuçlarını yayınlayabilecek. Diğer kullanıcılar: İstek ve şikâyette bulunabilecek.
Sayfada şunlar bulunacaktır;
· Öğretim elemanlarının geniş CV’leri, · Bölümün tanıtımı (tanıtıcı bilgi ve resimler), · Bölüm hocalarının yayınladıkları kitap ve makaleler, · Ders materyalleri (doc, ppt, pdf, jpeg türü dosyalarla verilecektir.), Sınav tarihleri, Sınav sonuçları · Duyurular, · Ders içerikleri, · Ders Programları, · Öğretim elemanlarının önerileri · Sık kullanılanlar(Linkler), · Bölüm açısından yararlı linkler,(Bölümdeki yenilikler)
Taslak Tasarım Önerileri
Tasarım Önerileri Geliştirme ve Yapım Aşaması Photoshop CS3 (paint), Easy PHP, MySQL ya da MS access, Dreamweaver CS4 programlarını yapım aşamasında kullanacağız.
Site Haritası Ana sayfa
1.Fakültemiz
Bölümlerimiz
2.Anabilim dalı
3.Ana bilim dalı hakkında
4.Akademik kadro
5.Dersler
6.Ders içerikleri
7.Ders Programı
8.Sınav Tarihleri
9.Bağlantılar (Linkler)
10.Duyurular
Değerlendirme ve Test Etme Tasarım aşaması için ön çalışma hazırlanmıştır. Hazırlanan taslaklar öğretim elemanlarıyla görüşülüp, uygunluğuna karar verilmiştir. Öğretim elemanlarının başka beklentileri olursa dikkate alınacaktır.sürekli iletişim içerisindeyiz.
