live_tv
Livestream Starting Soon
00
Hours
:
00
Minutes
:
00
Seconds
Up next in 10
Auzef Bilişim Sistemleri Analiz ve Tasarımı 2024-2025 Vize Soruları
https://lolonolo.com/2026/03/06/bilisim-sistemleri-analiz-ve-tasarimi-2024-2025-vize-sorulari/
https://lolonolo.com
Show More Show Less View Video Transcript
0:00
Herkese merhaba. Bilişim sistemleri
0:02
kulağa biraz karmaşık geliyor, değil mi?
0:04
Ama aslında öyle olmak zorunda değil.
0:07
Bugün bu sistemlerin analiz ve tasarım
0:09
dünyasına dalacağız ve her şeyi adım
0:11
adım birlikte çözeceğiz. Aklınızda
0:14
harika bir fikir var diyelim. Peki bunu
0:16
gerçekten işe yarar, tıkır tıkır çalışan
0:18
bir teknolojiye nasıl dönüştürürsünüz?
0:20
Aslında bütün mesele bu soruda gizli.
0:22
Bunu şuna benzetebiliriz. Elinizde bir
0:24
mimari plan var ve ondan yola çıkarak
0:26
devasa bir gökdeleni inşa edeceksiniz.
0:29
Her şey o ilk konseptle başlıyor. Evet.
0:31
Ama o konsepti somut bir yapıya, bir
0:33
sisteme dönüştürmek için doğru adımlar
0:34
atmak hayati önem taşıyor. Peki o zaman
0:37
başlayalım. İlk durağımız bir bilişim
0:40
sisteminin anatomisi. Yani en temel yapı
0:43
taşlarını anlamak. Çünkü mantık basit
0:45
değil mi? Herhangi bir şeyi inşa etmeye
0:47
başlamadan önce elimizdeki malzemelerin
0:49
ne olduğunu çok iyi bilmemiz lazım.
0:51
Bakın her bilişim sistemi ama gerçekten
0:54
her biri şu beş temel bileşen üzerine
0:56
kuruludur. Donanım yani sistemin
0:58
fiziksel gücü, motoru, yazılım, o motora
1:01
ne yapacağını söyleyen akıl, komutlar,
1:04
veri, işlenecek olan hammadde. Tabii ki
1:06
insanlar yani bu sistemi kullanacak,
1:09
yönetecek olan bizler. Ve son olarak
1:11
süreçler yani tüm bu parçaların bir
1:13
orkestra gibi uyum içinde çalışmasını
1:15
sağlayan iş akışları. İşte projemizin
1:18
temel yapı taşları tam olarak bunlar.
1:20
İlk bileşenimiz donanım. Yani sistemin
1:23
elle tutabildiğiniz, gözle
1:25
görebildiğiniz kısmı. Sunucular,
1:27
bilgisayarlar, o karmaşık görünen
1:29
kablolar. Hani gökteren benzetmesi
1:31
yapmıştık ya işte bu da projemizin
1:33
çeliği, betonu ve bu fiziksel yapının,
1:36
bu bedenin öyle bir parçası var ki her
1:39
şeyin merkezinde beyni. Yani merkezi
1:42
işlem birimi. Evet. MIB ya da hepimizin
1:45
bildiği adıyla CPU. İşte bu küçük parça
1:48
sistemin tüm performansını belirliyor.
1:51
Aslında tam olarak bir beyin gibi
1:52
çalışıyor. Bir bilgisayarın aynı anda
1:55
kaç tane işi birden yapabileceği, ne
1:57
kadar hızlı düşünebileceği, ne kadar
1:59
karmaşık problemleri çözebileceği hepsi
2:02
ama hepsi ona bağlı. Şimdi o göktelen
2:05
benzetmemize geri dönelim. Çünkü cuk
2:07
oturuyor. Düşünün ki bir şirket o
2:10
göktelen. Her katında farklı işler
2:12
yapılıyor ve her katı olan sistem
2:15
farklı. Zemin katta yani operasyonun
2:18
kalbinde her gün binlerce kez
2:20
tekrarlanan işler var. Mesela bir market
2:22
kasasında okutulan ürünler gibi. İşte
2:25
bunları hareket işleme sistemleri
2:27
hallediyor. Orta katlara çıktığımızda
2:30
yöneticilerin eğer şunu yaparsak ne olur
2:33
diye sorduğu yerlere geliyoruz. Burada
2:35
karar destek sistemleri devreye giriyor.
2:38
En tepeye çatı katına çıktığımızdaysa
2:40
orada büyük resme bakılıyor. Üst
2:43
yöneticiler stratejik kararlar alırken
2:46
verileri şık grafiklerle özetleyen üst
2:48
yönetici destek sistemlerini kullanıyor.
2:51
İşte karar destek sistemlerinin asıl
2:53
sihri de bu. O meşhur ne olursa ne olur
2:56
sorusunu sorabilmek. Fiyatları %5
2:59
indirsek satışlarımız ne kadar artar?
3:01
yeni bir reklam kampanyasına şu kadar
3:03
bütçe ayırırsak pazar payımız nasıl
3:04
etkilenir gibi sorular. İşte bu tür
3:07
analizler bu sistemleri taktiksel
3:09
kararlar alırken gerçekten inanılmaz
3:11
güçlü bir müttefik haline getiriyor.
3:13
Tamam malzemelerimizi tanıdık. Elimizde
3:16
ne var ne yok biliyoruz. Şimdi sıra
3:17
geldi işin en eğlenceli kısmına. Bu
3:20
sistemi gerçekten nasıl inşa edeceğiz?
3:22
Yani planları bir kenara bırakıp inşaat
3:25
yöntemlerine, işin mutfağına geçiyoruz.
3:27
Her sistemin geliştirilmesi belirli bir
3:29
yaşam döngüsünü, bir yol haritasını
3:31
takip eder. Önce planlama yaparız. Yani
3:34
olası riskleri masaya yatırırız. Sonra
3:37
analiz. Bakın burası çok kritik.
3:39
Sistemin tam olarak ne yapması
3:41
gerektiğini burada tanımlarız. Başarısız
3:43
olan projelerin çoğu işte bu aşamada
3:45
tökezler ve sonra uygulama aşaması.
3:48
Artık kodların yazıldığı, teorinin
3:50
pratiğe döküldüğü, projenin en çok ter
3:52
dökülen, en çok zaman ve emek isteyen
3:54
kısmı burasıdır. Peki bu inşaata hangi
3:57
yöntemle girişeceğiz? Bu şuna benziyor.
3:59
Prefabrik bir ev mi yapacaksınız yoksa
4:01
temelden geleneksel yöntemlerle mi inşa
4:04
edeceksiniz? İkisinin de yeri ayrı.
4:06
Proje için doğru metodolojiyi seçmek
4:08
işte bu yüzden çok önemli. Diyelim ki
4:10
pazara bir an önce çıkması gereken bir
4:11
mobil uygulama yapıyorsunuz. O zaman
4:13
hızlı uygulama geliştirme yani ROAD adı
4:16
üstünde harika bir seçenek. Ama öte
4:18
yandan bir bankanın ana sistemini,
4:20
çekirdek sistemini yazıyorsanız orada en
4:22
ufak bir hatanın bile telafisi olmaz.
4:24
İşte o zaman her adımın milimetrik
4:26
hesaplandığı geleneksel şelale modelini
4:28
seçmek çok daha mantıklı. Ve bu çevik
4:31
yöntemler demişken karşımıza çok ilginç
4:33
bir unvan çıkıyor. Scram Master ya da
4:35
Türkçesiyle Scram ustası. Sakın ismini
4:38
aldanmayın. Bu kişi klasik bir proje
4:40
yöneticisi gibi şunu yapın, bunu yapın
4:42
diye emirler yağdırmaz. Onun görevi tam
4:45
tersi. Takımın önündeki engelleri
4:47
kaldırmak. Adeta bir hizmetkar lider
4:50
gibi takımın daha hızlı, daha verimli
4:52
çalışması için yolu temizler. İyi bir
4:54
Scram ustasının ekibi haftalarca
4:56
oyalayacak bürokratik bir sorunu bir
4:58
telefonla çözüp projenin seyrini
5:00
değiştirdiğini çok duymuşuzdur.
5:02
Yöntemler tamam ama bir projeyi proje
5:05
yapan insanlardır. Şimdi işin insan
5:08
boyutuna ve belki de en kritik
5:10
adımlardan birine geliyoruz. Roller,
5:12
sorumluluklar ve her şeyden önce bu
5:15
proje yapılabilir mi sorusuna dürüstçe
5:17
cevap vermek. Şöyle bir düşünün. Bir
5:20
takım projesindesiniz ve kimin tam
5:22
olarak ne yapması gerektiği belli değil.
5:24
Herkes birbirine bakıyor. Bu durumu
5:26
yaşadınız mı hiç? Eminim
5:28
yaşamışsınızdır. İşte bu belirsizlik
5:30
küçük projelerde can sıkarken büyük
5:33
projelerde tam bir kaosa hatta projenin
5:36
tamamen çökmesine bile neden olabilir.
5:38
Neyse ki bu karmaşayı bitiren basit ama
5:41
inanılmaz güçlü bir araç var. Rachi
5:43
matrisi her görev için rolleri kristal
5:46
gibi netleştirir. Sorumlu yani işi
5:49
fiilen yapan kişi hesap verebilir. Bakın
5:51
bu çok önemli. İşin nihai sahibi odur ve
5:54
her görevde sadece bir tane olabilir.
5:57
Danışılan yani fikrini aldığımız uzman
6:00
ve bilgilendirilen yani süreçten
6:02
haberdar ettiğimiz kişi. Bu basit
6:04
tabloyu kullandığınızda o meşhur bu iş
6:07
kimdeydi ya sorusu ortadan kalkar ve
6:09
hiçbir görev sahipsiz kalmaz. Tamam.
6:12
rolleri dağıttık. Herkes ne yapacağını
6:14
biliyor ama bir saniye durup en temel
6:16
soruyu sormamız lazım. Peki bu proje
6:19
gerçekten mümkün mü? Yapılabilir bir şey
6:22
mi? İşte bu her şeye başlamadan önce
6:25
dürüstçe cevaplanması gereken o milyon
6:27
dolarlık soru. İşte bu soruya cevap
6:30
bulmak için bir fizibilite analizi yani
6:32
bir yapılabilirlik analizi yaparız.
6:34
Kendimize şu soruları sorarız. Teknik
6:36
olarak bunu yapacak teknolojiye sahip
6:38
miyiz? Operasyonel olarak insanlar bunu
6:40
gerçekten kullanabilecek mi? iş
6:41
akışlarımıza uyacak mı? Zamanlama olarak
6:44
bu takvimde bitirmemiz gerçekçi mi? Ve
6:46
tabii ki en önemlisi ekonomik olarak. Bu
6:49
işin sonunda kara geçecek miyiz?
6:50
Mantıklı mı? Mesela yeni bir sunucu
6:53
almamız gerekiyor kararı işte tam da bu
6:55
teknik fizibilite kontrolünün bir
6:57
parçasıdır. Ve geldik son bölüme. Belki
7:00
de proje yönetiminin en gerçekçi
7:02
kısmına. Çünkü bilirsiniz hayatta her
7:04
şey planlandığı gibi gitmez. İşte bu
7:06
bölümde riskleri yönetmekten ve o
7:09
kaçınılmaz işler ters gittiğinde anı
7:12
için hazırlıklı olmaktan bahsedeceğiz.
7:14
Bütün o risk analizlerinden sonra
7:15
elimizde somut bir çıktı olur. Risk
7:18
yönetim planı. Bu bir resmi bir belge.
7:21
Projenin başına gelebilecek bütün
7:23
potansiyel tehditleri ve bu tehditlere
7:25
karşı hangi stratejiyi izleyeceğimizi
7:27
kaçınacak mıyız? Başkasına mı
7:29
devredeceğiz? Etkisini mi azaltacağız
7:31
yoksa siniye mi çekeceğiz? net bir
7:33
şekilde ortaya koyan ana yol
7:35
haritamızdır. Risk yönetim planı genel
7:38
stratejiyi çizer. Peki ya o risklerden
7:40
biri gerçeğe dönüşürse işte o zaman
7:42
devreye acil durum planı girer. Bu sizin
7:45
meşhur B planızdır. Artık ne olursa diye
7:48
düşünmeyiz. Şimdi ne yapıyoruz deriz. O
7:50
an geldiğinde panik yapmadan adım adım
7:52
ne yapılacağını gösteren önceden
7:54
hazırlanmış eylem kılavuzunuzdur. Evet
7:57
bayağı bir yol katettik. Peki bütün bu
7:59
yolculuktan cebimize ne koyduk? Gelin
8:01
şöyle bir toparlayalım. Öncelikle her
8:03
sistemin beş temel yapı taşı olduğunu
8:05
öğrendik. Donanım, yazılım, veri, insan
8:08
ve süreçler. İkincisi, sistem
8:11
geliştirmenin bir yaşam döngüsü olduğunu
8:13
ve projenin karakterine göre doğru
8:15
yöntemi seçmenin ne kadar kritik
8:17
olduğunu gördük. Üçüncüsü, başarı için
8:19
net rollerin hani o ragi matrisi ve en
8:22
başta yapılan sağlam fizibilite
8:24
kontrollerinin şart olduğunu anladık. Ve
8:26
son olarak belki de en önemlisi mükemmel
8:29
bir plan. içinde işler ters gittiğinde
8:31
ne yapılacağını söyleyen bir B planını
8:33
da barındırır. Ve şimdi bu son soruyla
8:36
sizi başa bırakıyorum. Aklınızdaki o bir
8:39
sonraki büyük proje için gerçekten doğru
8:42
bir plana sahip misiniz? Bugün
8:44
konuştuğumuz tüm bu yapı taşlarını,
8:46
yöntemleri ve kontrolleri düşündüğünüzde
8:48
o harika fikrinizi gerçeğe dönüştürmeye
8:50
ne kadar hazırsınız?
#Enterprise Technology
#Programming
#Education