Günümüzde bir çok web sayfası ticari nedenlerle arama motoru sonuçlarında yükselmek istemekte ve bunun için spam tekniklerini kullanmaktadır. Her sayfanın insan editörler tarafından incelenmesi çok zor olduğundan, bazı güvenilir sayfalar işaretlenir ve ondan alınan link çıkışlarındaki sitelere puanlar verilir.

Google genel politikası 2007-2008 yılına kadar genelde Pagerank üzerineydi. Webmasterlar olarak yakın geçmişimize baktığımızda, kaliteli veya kalitesiz linklerin sitelerimizi, arama sonuçlarında nasıl yükselttiğine pek çok kez şahit olduk. Sitelerimizin kalitesi veya içeriği pek önemli değildi; bizim için tek önemli konu ne kakadar çok link ve ne kadar yüksek rank … meselesi idi. Google’ın arama sonuçları bu yolla defalarca kez suistimal edildi. Tabii kendini geliştiren bir sistem olan Google, gelen olumsuz geri dönüşler üzerine bazı önlemler almaya başladı.

Öncelikle artık kişisel, hobi olarak uğraşılan sitelerin kolay kolay Pagerank 5 üstüne çıkması ( özellikle Türkçe backlinkli sitelerde ) mümkün olmuyor. Pagerank değerleri kurumsallamış siteler, devlet siteleri vb. sitelerde yüksek görünüyor. Bu sayede Google kalitesiz backlinklerin önünü kesmiş oluyor. Bildiğiniz üzere Pagerank değeri ne kadar yüksek olursa, backlinkin etkisi o ölçüde katlanıp büyüyor. Bu yolla Google backlink olayına az da olsa bir ciddiyet getirdi ve link değişimi ya da link satın alımı ile elde dilen linklerin önemsiz kalabileceğini webmasterlara iletti.

Trustrank‘ın gözlemlenen bir diğer etkisi sitelerin Google gözünde tek tek değerlenmesi ya da değerini kaybetmesi üzerine oluyor. Bu nasıl oluyor derseniz, Google botları siteleri gezerken belirli kriterler üzerinden, o siteleri puanlandırıp kendi içinde bir derece oluşturuyor. Bu derecelendirme, sitenin yaşı, güncelleme aralıkları, özğünlüğü, yeni nesil tasarım ve kodlamaya sahip olması, hatasız kodlama ile oluşturulması ( ayrı bir öneme sahiptir ) sitenin kendi içinde linkleme yapısı ( Google bot istediği her sayfaya rahatlıkla ulaşabilmeli ) , site içindeki anahtar kelime yoğunluğu, sitenin ulaşılabilirliği, site içindeki kelime yoğunlukları gibi daha sayabileceğimiz pek çok unsur Trustrank’ı  arttırabilir veya azaltabilir. Her sitenin Trustrank’ı farklı oluşacaktır. Bunun için Google gözünde her sitenin de yeri ayrı oluyor. Yani kısaca pr5 değerine sahip bir site pr6 bir siteden daha etkili olabilir.

Pagerank - Trustrank ilişkisine, gelince buradaçok açıkça söylemek gerekirse, Pagerank ile Trustrank doğrudan ilişkilidir. Bunu son zamanlardaki deneyimlerim ile de yaşadım. Örneğin; pek çok insan trafından sevilen ve takdir edilen bir sitenin seo hedef kelimesinde yükselmesi 5-10 link ile olabilirken; aynı alandaki, aynı Pagerank değerine sahip, aynı ortalama  Alexa değerlerine sahip bir başka sitenin yükselmesi 25-30 link ile olabilmektedir. Buradaki etki Trustrank’ın ortaya çıkması ile oluşmuştur. Google eski yapısında seyreden bir sistem olsaydı eğer, iki sitede değerleri aynı oluğu için aynı tarzda yükseliş gösterebilcektir. Sonuç olarak diyebiliriz ki : karşıdan gelen link kadar, linkin geldiği yer de önemlidir.

Trustrank çok iyi bir algoritma mıdır ? Trustrak Google’ın sistemine yenilikler getirmesine karşın, elbette bazı sorunları da beraberine getiriyor. Burada sorun, çok yüksek Trustrank’a ulaşan siteler arama sonuçlarında saçmalıklara neden olabiliyor. Trustrank’ı çok yüksek olan siteler, her sayfaları ile ilgili ya da ilgisiz sonuçlarda ilk sıraları işgal ediyor. Sonuç olarak, arama motoru kullanıcısı için bu zaman kaybına neden oluyor. Örneğin : Türkiye’de Oyunlar1.com’un , Trustrank’ı çok yüksek görünüyor. Google.com.tr’de “Pizza Siparişi” araması yaptığımzda dahi sitenin alt sayfası bizi ilk sırada karşılıyor. Google aramalrında daha mantıklı sıralanması için, semantik algoritmasını kısa zamanda daha da çok geliştirecektir. Bu sayede Trustrank’ın olumlu etkileri arama sonuçlarına daha da iyi yansıyacaktır.

Bir sitenin Trustrank’ı nasıl yükselir ?

• Site tasarımı,kodlaması,içeriği yeni nesil anlayışlara uygun olmalı. Hem ziyaretçinin hem de botun işini kolaylaştırmalıdır.
• Site  adı ile devamlı Google’dan arama geliyorsa, bu Trustrank’ı çok olumlu etkiler. Bu yüzden markalaşacak bir isim seçilmeli ve o yolda ilerlenilmelidir.
• Sitede ziyaretçini kalış süresi de çok önemlidir. Bu süreyi mümkün olduğunca yükseltmeliyiz.
• Sitenin içeriktaş linkleri ve özellikle yabancı içeriktaş - kaliteli linkleri sitenin Trustrank’ını çok iyi etkiler. Sitede farklı diller de varsa, site evrenselleşir ve seo puanlarını kazanır.
• Sadece önemli dizinlere üye olun. Link kalabalığı sizin için hem zaman kaybı hem de performans kaybı olacaktır. Bunun için yeni açılan veya iyi bir yapıya ulaşamamış sitelere, site adresinizi göndermeyin.
• Sitenizde farklılaşın ki , siteniz diğerlerinin arasından ayrılsın. Ziyaretçiyi memnun edecek uygulamalar yaparak bu işe çözüm sağlayabilirsiniz. Ziyaretçilerinizi yeni uygulamalar ile test edin ve en doğru sonuca ziyaretçiler ile ulaşın. Sonuçta site onlar için var.
• Güncelleme periyodlarınız olsun ve devamlı özgün - yeni bilgileri sunun. Google ve ziyaretçiler tekrarlanan içerikten pek hoşlanmazlar.

Bunlar gibi pek çok rank yükselten unsuru saymak mümkün. Size düşen görev sadece ziyaretçilerinizin daha da memnun kalabilmesini sağlayabilmek olacaktır.

SEO’nun mantığına biraz mizahi bir şekilde anlatmak daha keyifli olucaktır. Seo kelimesinin içindeki gizli anlam nedir, harfler neleri temsil ediyor mizahi bir şekilde bahsedeyim sizlere, yazar: seoliz.com cenk.

S, E ve O kelimeleri bazı kilit noktaların baş harfleridir. Bu yolda pes etmemeyi teşvikleyen kilit noktalar.

Sabır: Seo çalışmalarında sabır en önemli faktörlerden biridir. Bir şeyi anında elde etmek bazen çok risklidir. Ani çalışmalar ve müdahaleler gelecekte siteye büyük zararlar verebilecek sonuçlar doğurabilir. Arama motoru optimizasyonunda sabır çok önemlidir, sabretmenin emeklerinizin boşa gitmemesinde büyük bir rolü vardır.

Emek: Her işte olduğu gibi bu işte de emek çok önemlidir. Kısa yoldan veya uğraş vermeden çıkmaya çalışmak hem zoru hemde riski size iter. Üşenmeden yazdığınız özgün yazılar, üşenmeden düzelttiğiniz kod hataları veya üşenmeden siteyi güncel tutmanız başarıya giden yolda ivmenizi arttırır.

O harfide optimizasyonu simgelemektedir. Yani sabır ve emekle uğraşılan bir optimizasyondur. Seo’da sabretmek ve emek vermek bu yolda pes etmemek için en çok gereken 2 noktadır.

Yazılım teknolojisi geliştikçe yazılan programların karmaşıklığı ve zorluğu giderek artmaktadır. Donanım ve yazlımın iç içe girdiği, büyük ağ sistemlerinin giderek arttığı bir dönemde doğaldır ki biz programcıların yazacağı programlarda büyüyecektir.Yazacağımız programlar çok karmaşık olacağı için kod organizasyonu yapmamız zor olacaktır. Hele birçok programcının çalışacağı projelerde bu nerdeyse imkansız hale gelmiştir. Bu yüzden standart bir modelleme ve analiz diline ihtiyaç duyarız. Programımızın analiz ve dizayn aşamasında modellemeyi güzel yaparsak ileride doğabilecek birçok problemin çıkmasına engel olmuş oluruz. UML daha çok nesneye dayalı programlama dilleri için uygundur. Problemlerimizi parçalara ayırabiliyorsak, ve parçalar arasında belirli ilişkiler sağlayabiliyorsak UML bizim için biçilmiş kaftan gibidir. Mesela bir ATM siteminde müşteriyi, banka memurunu ve ATM makinasını ayrı parçalar halinde düşünebiliriz. Müşteri ATM makinasından para çeker, banka memuru ATM makinasına para yükler.Ama banka memuru ile müşteri arasında doğrudan bir ilişki yoktur.Bu tür ilişkiler UML 'de çeşitli diyagramlarla gösterilir. Bu diyagramlar hakkında geniş ve detaylı bilgiyi daha sonraki yazılarımızda ele alacağız.

Bu kısa girişten sonra UML 'in tarihine bakalım.UML 'in doğuşu son yıllarda yazılım endüstrisindeki en büyük gelişmelerden biri olarak kabul edilebilir. UML 1997 yılında yazılımın, diyagram şeklinde ifade edilmesi için bir standartlar komitesi tarafından oluşturuldu. Daha önce hemen hemen her daldaki mühendislerin standart bir diyagram çizme aracı vardı. Ve şimdi de programcıların UML 'si var.

UML ile hazırlanmış bir yazılım hem daha az maliyetli hem daha etkili ve daha uzun ömürlü olur. UML ile dokümantasyonu yapılmış bir programın sonradan düzenlenmesi daha kolay olur. Bütün bunlar UML kullanmamız için yeterli sebeplerdir diye düşünüyorum.Kısaca ,UML 'nin faydalarını maddeler halinde sıralarsak;

1-) Öncelikle programımız kodlanmaya başlamadan önce geniş bir analizi ve tasarımı yapılmış olacğından kodlama işlemi daha kolay olur. Çünkü programdan ne beklediğimizi ve programlama ile neler yapacağımızı profesyonel bir şekilde belirleriz UML ile.

2-) Programımızda beklenmedik bir takım mantıksal hataları (bug) minimuma indirgemiş oluruz.

3-) Tasarım aşaması düzgün yapıldıysa tekrar kullanılabilen kodların sayısı artacaktır. Buda program geliştirme maliyetini büyük ölçüde düşürecektir.

4-) UML diagramları programımızın tamamını kapsayacağı için bellek kullanımını daha etkili hale getirebiliriz.

5-) Programımızın kararlılığı artacaktır. UML ile dokümanlandırılmış kodları düzenlemek daha az zaman alacaktır.

6-) Ortak çalışılan projelerde programcıların iletişimi daha kolay hale gelir.Çünkü UML ile programımızı parçalara ayırdık ve parçalar arasında bir ilişki kurduk.

Bir sistemin geliştirilmesi kabaca aşağıdaki aşamalardan geçmektedir. İlk iki aşamada UML büyük ölçüde rol oynar.

 Unutmayın: UML bir programlama dili değildir. Bir diyagram çizme ve ilişkisel modelleme dilidir. Bu makalemizde UML 'de kullanılan başlıca UML diagramlarını ve kısa tanımlarını işleyeceğiz. Diyagram şekilleri ve kod oluşturma işlemlerini bundan sonraki makalelerimizde bulabilirsiniz.

Şimdi kısa ve öz bir şekilde UML komponentlerinden(diagramlar) bahsedelim: Nesneler arasında ilişki kurmak için UML bir takım grafiksel elemanlara sahiptir.Bu elemanları kullanarak diyagramlar oluşturacağız. Bu makalede sadece bu diagramların ne işe yaradığını göreceğiz. UML temel olarak 9 diyagram türünden oluşur.

CLASS DIAGRAM

Gerçek dünyada eşyaları nasıl araba, masa, bilgisayar şeklinde sınıflandırıyorsak yazılımda da birtakım benzer özelliklere ve fiillere sahip gruplar oluştururuz. Bunlara "Class"(sınıf) denir. Geliştirici açısından önemli olan "Class Diagramları" hakkında daha sonra detaylı bir makalemiz olacak.

OBJECT DIAGRAM

Bir nesne(object) sınıfın (class) bir örneğidir. Bu tür diyagramlarda sınıfın yerine gerçek nesneler kullanılır.

STATE DIAGRAM

Gerçek nesnelerin herhangi bir zaman içindeki durumunu gösteren diyagramlardır.Mesela, Ali nesnesi insan sınıfının gerçek bir örneği olsun. Ali 'nin doğması, büyümesi, gençliği ve ölmesi State Diagram 'larıyla gösterilir.

SEQUENCE DIAGRAM

Class ve Object diyagramları statik bilgiyi modeller.Halbuki gerçek zamanlı sistemlerde zaman içinde değişen interaktiviteler bu diyagramlarla gösterilemez. Bu tür zamanla değişen durumları belirtmek için sequence diyagramları kullanılır.

ACTIVITY DIAGRAM

Bir nesnesinin durumu zamanla kullanıcı tarafından ya da nesnenin kendi içsel işlevleri tarafından değişebilir.Bu değişim sırasını activity diyagramlarıyla gösteririz.

USE CASE DIAGRAM

Programımızın davranışının bir kullanıcı gözüyle incelenmesi Use Case diyagramlarıyla yapılır. Gerçek dünyada insanların kullanacağı bir sistemde bu diyagramlar büyük önem taşırlar.

COLLABORATION DIAGRAM

Bir sistemin amacının yerine gelmesi için sistemin bütün parçaları işlerini yerine getirmesi gerekir. Bu işler genellikle birkaç parçanın beraber çalışmasıyla mümkün olabilir. Bu tür ilişkileri göstermek için Collaboration Diyagramları gösterilir.

COMPONENT DIAGRAM

Özellikle birden çok geliştiricinin yürüttüğü projelerde sistemi component dediğimiz parçalara ayırmak, geliştirmeyi kolaylaştırır.Sistemi öyle modellememiz gerekir ki her geliştirici ötekinden bağımsız olarak çalışabilsin.Bu tür modellemeler Component Diyagramlarıyla yapılır.

DEPLOYMENT DIAGRAM

Bu tür diyagramlarla sistemin fiziksel incelenmesi yapılır. Mesela bilgisayarlar arasındaki baglantılar, programın kurulacağı makinalar ve sistemimizdeki bütün aletler Deployment Diyagramında gösterilir.

Evet,UML ile ilgili geniş bir giriş bilgisine sahip olduk sanırım. Bundan sonraki makalelerimizde, yukarıdaki Diyagramları detayları ile açıklayacağım.

NET ile tümüyle yenilenen ve klasik ASP'nin yeni bir versiyonu değil de dotNET'in yeni vizyonuna yakışan yenilikleri ve kolaylıkları içeren ASP.NET ile web uygulamalrımızı artık iki türlü yazabilme imkanına sahibiz. Birincisi eskiden olduğu gibi (ASP'de) inline code yani progam kodlarımız aspx dosyamızın içinde yer alıyor. Bu yaklaşımda çoğu zaman sayfalarımızda program kodarı ile html tasarımı birbirine karışıyor. Sayfalara yeni özellikler eklemek veya onlarda bulunan hataları düzeltmek programcı için çook zor oluyurdu.

Diğer yaklaşımda ise; tasarım ile kodlamayı birbirinden ayırmak ve böylelikle daha hızlı web uygulamaları geliştirmenin yanında kodumuzun bakımı ve yeni versiyonlarını üretmede de daha hızlı ve etkin çözümler üretebiliriz. Bu tarz web programlamaya Code-Behind programlama ismi veriliyor. Aslında Code-Behind programlamayı da iki farklı şekilde yapabiliriz. Birincisinde program kodumuz (c# veya vb.net) ayrı bir sayfada yeralıyor. Bu kod sayfasına aspx sayfasından referans veriyoruz ve kodumuz çalışma anında MSIL'e derleniyor. İkinci metotda ise, program kodumuzu dll olarak derleyip aspx sayfamızda direk olarak derlediğimiz dll'e referans veriyoruz.

cs uzantılı dosyamızı, ait olduğu aspx dosyasının ismi aspx + ve + cs şeklinde adlandırmak ASP.NET geliştiricileri ve Visual Studio.NET tarafından benimsenmiştir. Diyelimki aspx dosyamınızın ismi AspNetCodeBehind.aspx olsun bu durumda C# kodumuzun dosyasını AspNetCodeBehind.aspx.cs şeklinde isim veririz.

Önce AspNetCodeBehind.aspx.cs ismli dosyamızı aşağıdaki şekilde yazalım :

using System; using System.Web.UI;      // Önce gerekli isim uzaylarımızı kodumuza import edelim. namespace Ozcanilhan.com.tr {     public class AspNetCodeBehind : Page    // Sınıfımızı yazmaya başlıyoruz..      {           public int carpim;                         // tamsayı tipinde bir üye değişkenimiz var. İsmi ise capim           public int Carp(int s1, int s2)         // tamsayı döndüren üye fonksiyonumuzun adi Carp olsun             {                 carpim = s1*s2;                   // aldigimiz iki parametreyi çarpıp bunları carpim değişkenimize atayalım.                  return carpim;                     // elde ettiğimiz çarpımı fonksiyonumuzun sonucu olarak geri dönderelim.             }      } }

Her C# programında olduğu gibi önce gerekli isim uzaylarını programımıza using anahtar kelimesi kullarak ekledik. Bunlar System ve System.Web.UI sonra Ozcanilhan.com.tr isimli kendi isim uzayımızı yazmaya koyulduk. Bu isim uzayımız AspNetCodeBehind sınıfını içeriyor. Sınıfımızda bir değişken ve birde fonsksiyomuz var. Değişkenimizin ismi carpim, fonksiyonumuzun ismi ise Carp() olsun. Sonrada AspNetCodeBehind.aspx ismini verdğimiz ASP.NET dosyamızı yazalım:

<%@ Page Language="c#" Inherits="Ozcanilhan.Com.tr.AspNetCodeBehind" Src="AspNetCodeBehind.aspx.cs"%>

Yukarıdaki aspx sayfasını çalıştırdığımızda 8 x 7 = 56 şeklinde bir çıktı elde ederiz. Bu sayfaya önce <%@ Page Language="c#" Inherits="Ozcanilhan.com.tr.AspNetCodeBehind" Src="AspNetCodeBehind.aspx.cs"%> kodunu ekledik. Inherits="Ozcanilhan.com.tr.AspNetCodeBehind" ile cs dosyamızda Ozcanilhan.com.tr isim uzayında bulunan AspNetCodeBehind sınıfımızı kullanacağımızı CLR ve IIS'e bildirdik. İlgili isim uzayının yeraldığı c# kod dosyasının yerini Src="AspNetCodeBehind.aspx.cs" direktifi ile belirtik. public void Page_Load(Object sender, EventArgs e)
{
    Response.Write(7+" x " + 8 + " = " + Carp(7,8) ) ;
} Kod parçasında bir sayfa yüklenirken ( dikkat edin public void Page_Load(Object sender, EventArgs e) kullandık. Response.Write metodunu kullanarak birşeyleri yazdırdık. Çarpım işleminin sonucunu bulurken c# dosyamızdaki AspNetCodeBehind sınfının bir üyesi olan carpim() fonksiyonumuzu kullandık. Bu yazmızda ASP.NET'de code-behind program yazarken derlenmemiş bir C# dosyası kullanmayı inceledik. Gelecek yazımızda ise aspx sayfamıza kendi yazdığımız dll dosyasını eklemeyi ve bunu kullanmak üzerinde duracağız.

Genişletilebilir İşaretleme Dili ( eXtensible Markup Language ) SGML 'den türetilmiş, basit ve çok esnek bir işaretleme dildir. ( http://www.w3.org/XML/#intro "Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML") W3C ye göre XML' in tanımıdır.

Hala gelişim içinde bulunan XML bir çok kişinin düşündüğü gibi HTML in yerini almak için geliştirilmemiştir. Peki neden XML 'e ihtiyaç duyarız. Aslında XML büyük ölçekli elektronik yayıncılıkta kullanılmak üzere dizayn edilmiş, aynı zamanda da geniş çeşitlilikteki verilerin web üzerinden veya herhangi bir platformda alış verişinin sağlanmasında önemli bir rol oynamaya başlamıştır. ( http://www.w3.org/XML/#intro "Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.")

Maddeler halinde XML 'i anlatmak gerekirse;

- XML , HTML gibi bir işaretleme dilidir.
- XML, veri yi tanımlamak için dizayn edilmiştir.
- Önceden belirtilmiş etiketler (tag) yoktur. Kendi etiketlerinizi kendiniz oluşturmanız gerekir.
- XML de veriyi tanımlamak için doküman tipi tanımlaması DTD (Document Type Definition ) veya XML Schema kullanmanız gerekmektedir.
- XML DTD veya XML Schema ile birlikte kendini tanımlayıcı bir yapıda olması gerekmektedir.

Biraz maddeleri açmamız gerekirse XML, HTML gibi bir işaretleme dilidir. (Markup Language). XML, HTML 'in yerin almak için geliştirilmemektedir. İkisi de farklı amaçlar ile geliştirilmiştir. HTML verinin gösterilmesi için geliştirilmiştir ve verinin nasıl görüntülendiği ile ilgilenir. XML ise verinin tanımlanması için geliştirilmiştir ve verinin ne olduğu ile ilgilenir. Kısaca HTML, bilgiliyi gösterir, XML ise bilgiyi tanımlar.

XML de HTML deki gibi önceden belirtilmiş etiketler (tag) bulunmaz, bunların yerine kendi etiketlerinizi oluşturursunuz. İlk bakışta çok serbest bir yapı gibi görünse de verdiğiniz etiketlerin sıralamaları, içerdiği veri veya öğeleri, DTD 'iz de tanımlamanız ve bu kurallar sıkı sıkıya uymanız gerekmektedir. DTD yi kendiniz oluşturacağınız gibi hali hazırda başkaları tarafından kullanılmakta oldan DTD 'leri kullanabilirsiniz.

XML DTD veya XML Schema nızla beraber kendini tanımlayıcı bir yapıda bulunması gereklidir. Peki bu nedir? Az önce üst bölümde açıkladığım gibi DTD ler sayesinde XML belgenizde kullanmış olduğunuz etiketlerin niteliklerini, yapılarını ve içermesi gereken verileri veya diğer etiketleri tanımladığınız bölümdür. Bu bölüm XML belgesinin içinde olabileceği gibi bir dış belge olarak XML belgesinde link edilmiş olabilir. Bu DTD ler sayesinde XML belgeniz browser veya farklı bir program tarafında çözümlenerek görüntülenir.

XML(Extendsible Markup Language - Gelişleyebilir Markup Dili) yeni çağın internet üzerinden veri taşıma ve verileri işleme dili olarak tasarlanmıştır. İsminden anlaşılacağı gibi bu dilin tag'lerini kullanıcı kendi ihtiyaçları doğrultusunda genişletebilir. HTML kullanırken bildiğimiz gibi belirli sayıda tag ile web sayfalarımızı dizayn ediyorduk. Fakat artık XML sayesinde web üzerinde verileri taşıma ve işleme gibi görevleri daha kolay yapabaliriyoruz.

Burada şu hususa dikkat etmekte yarar var: HTML verinin kullanıcıya ulaştrırken hangi formatta sunulduğu ile ilgilenir. Buna karşın XML ise veriyi nasıl anlamlı bir bütün olarak ve sunulan verinin kendini programcı tarafından üretilen tag'larla nasıl tanımladığıyla ilgilenir. Aşağıda bir xml belgesi örneğmiz var:

Özcan İLHAN            Yazılım Muhendisi.            msn@ozcanilhan.com.tr                         Ahmet Faruk           Nacaroglu           Bilgisayar Ogrt.           nacaroglu@yahoo.com                      Ersoy          Ozcan          Endustri Muh.          ozcane@hotmail.com                     Ziya         Kaya         Ekonomist         ziyakaya@hotmail.com

Yukarıdaki XML belgesi örneğinde de görebileceğiniz gibi bir XML belgesinde ilk satır bulunmaz zorunda. Bu giriş satırı dosyanın bir XML belgesi olduğunu deklare eder. Sonraki satırda ise programcıya yardımcı olacak yorum/açıklama satırımız bulunuyor. Dikkat ederseniz XML' de yorum satırlarımızı aynı HTML'de olduğu gibi yazarabiliriz. Yukarıdaki kodumuz tag'larımız iç içice girmiş (nested-loops gibi). Burda tag'ından sonra tag'ı geliyor. Bu durumda önce yazar tagını, sonra yazarlar tagını kapatmalıyız. Yani en dıştaki tag en son kapanmalı.

............

Yukarıdaki kod parçasında önce açılmıştır. Sonra ve en son ise açılmıştır. Buna göre önce sonra ve enson olarak 'i kapatmak durumundayız. Son olarak XML'i HTML'den ayıran diğer bir önemli nokta ise XML büyük- küçük harf duyarlıdır (case-sensitive). , ve tag'larının hepsi birer tag olarak XML tarafından algılanır.

Normal Windows uygulamalarında kullandığımız veritabanı bağlantılarını artık rahatlıkla Console uygulamalarında kullanabiliriz.Visual Studio .NET ve C# birlikteliğiyle kodlarımızı platformdan bağımsız hale getirebilir, ister Web, ister Windows istersek de Console uygulaması olarak kullanabiliriz. Bu makalemizde Visual Studio .NET kitaplığını kullanarak bir Console uygulamasından veritabanına bağlanıp Console ekranına bir tablodaki bütün bilgileri yazdıracağız.Makalemizdeki uygulamayı ben Visual Studio da yazmama rağmen siz herhangi bir text editörünü kullanarak yazıp "csc" derleyicisi ile derleyebilirsiniz. Veritabanı olarak MS SQL Server kullandım ama siz bağlantı "String" ini kullandığınız veritabanına göre düzenleyerek istediğiniz veritabanı ile çalışabilirsiniz. Eğer Visual Studio .NET kullanıyorsanız New->Project ten Visual C# Console Application' seçerseniz programımızın iskelet yapısını hazır olarak görebilirsiniz.

Programı yazarken System.Data.SqlClient "namespace" i altında bulunan sınıflardan ve System.Text "namespace" inde bulunan StringBuilder sınıfından yararlanacağız.

Programımızın bütün kodları aşağıdaki gibidir.Satır aralarına ise size yardımcı olacak bilgiler vermeye çalıştım. Programı inceleyip çalıştırdıktan sonra .NET ve C#' a eminim bundan sonra başka gözle bakacaksınız :)



//Burasını açıklamaya gerek yok sanırım
using System;

namespace ConsoleApplication1
{

class Class1
{

[STAThread]
//Programımız buradan çalışmaya başlıyor
static void Main(string[] args)
{

     //Bütün işlemlerimizi bir "SqlCommand" nesnesi olan komut üzerinden gerçekleştireceğiz. Bunun için aşağıdaki satırda olduğu gibi bir komut nesnesi tanımlıyoruz.
     System.Data.SqlClient.SqlCommand komut= new System.Data.SqlClient.SqlCommand();
     //Komut nesnesine sql cümleciği vermek için StringBuilder sınıfı ile sql_komut nesnesi oluşturuyoruz.
     System.Text.StringBuilder sql_komut= new System.Text.StringBuilder();
     //Append metodu ile sql_komut nesnesine sql cümleciğimizi yerleştiriyoruz.
     sql_komut.Append("SELECT * FROM Employees");
     

     //Bu satırlarda komutumuzun sql ifadesini ve komut tipini belirliyoruz.
     komut.CommandType=System.Data.CommandType.Text;
     komut.CommandText= new sql_komut.ToString();

     //Veritabanına bağlanma hazırlıkları bittiğine göre artık bağlantı nesnesini oluşturabiliriz.Aşağıdaki gibi CsConn bağlantı nesnesi oluşturup MS Sql Server'a bağlanmak için gerekli yazıyı ConnectionString özelliğine atıyoruz.Bu metod ve özellikler hakkında MSDN kitaplığında detaylı bilgiyi bulabilirsiniz.Bunları burada anlatarak makalemizin konusunun dışına çıkmak istemedim.
     System.Data.SqlClient.SqlConnection CsConn=System.Data.SqlClient.SqlConnection();
     CsConn.ConnectionString = "userid=sefer;password=;initial catalog=Northwind;data source=localhost;Connect Timeout=500;";

      //Komut nesnemizin bağlantı özelliğine CsConn bağlantı nesnesini atayıp bağlantımızı açıyoruz.
      komut.Connection=CsConn;
      CsConn.Open();

      //Veritabanına bağlanıp kayıt bilgilerini almak için SqlDataReader sınıfını kullanıyoruz. komut.ExecuteReader dediğimizde istediğimiz bilgileri veritabınından çekmiş oluyoruz.
      System.Data.SqlClient.SqlDataReader Bilgiler=komut.ExecuteReader();

       //SqlDataReader 'ın Read metodunu kullanarak bir döngü içinde bilgileri ekrana yazdırıyoruz.Bilgiler içindeki kayıtlar bittiğinde false değeri dönecektir.
       while (Bilgiler.Read())
       {
              //Bilgiler kayıt kümesindeki Sutun adlarını yazarak istediğimiz alanları ekrana yazdırıyoruz.
              Console.WriteLine(Bilgiler["FirstName"] + " " + Bilgiler["Title"]);
       }
       
       //Eee artık işimiz bitti, bağlantılarımızı rahatlıkla kapatabiliriz.
       Bilgiler.Close();
       CsConn.Close();
}
}
}

*(SEI: Software Engineering Institute, Yazılım Mühendisliği Enstitüsü) *(CMM-Capability Maturity Level, Yetenek Olgunluk Seviyesi)

Proje yönetimi, gereksinimlerin yönetimi sürecinin verimliliğini ölçebilir. Bunun için şu ölçütler kullanılabilir: Her gereksinimin durumu, gereksinimlerin toplam kümülatif değişim sayısı, efor ve gereksinimlerin yönetiminde harcanan bütçe. Gereksinimlerin yönetimi sürecinin başarısızlığa uğraması direkt olarak proje yönetimini de etkileyeceği için detaylı bir “gereksinimlerin yönetimi planı” yapılmasında fayda vardır.

Amaçlar

Yazılıma atanmış olan gereksinimleri, yazılım mühendisliği ve yönetim için bir temel referans olmaları için kontrol etmek.Yazılıma atanmış   sistem gereksinimleri ile yazılım planları, ürünleri, aktiviteleri tutarlı tutabilmek. Bu amaçlara göre; 1 – Proje, yazılıma atanmış sistem gereksinimleri için yazılı ve kurumsal bir anlaşmayı takip etmelidir.

Yazılıma atanmış bu sistem gereksinimlerine “atanmış gereksinimler” denir. Atanmış gereksinimler, yazılım bileşenleri tarafından gerçekleştirilen sistem gereksinimlerinin bir alt kümesidir. Bu atanmış gereksinimler yazılım geliştirme planının birincil girdilerini oluşturur. Yazılım gereksinimleri analizi atanmış gereksinimleri sadeleştirerek yazılım gereksinimleri belgesi haline getirir. Bu oluşturulan belge şunları belirtir:

• Atanmış gereksinimler belge haline getirilmiş, raporlanmıştır.
• Atanmış gereksinimler, yazılım yöneticileri, sistem test grubu, yazılım mühendisliği grubu, sistem mühendisliği grubu, yazılım kalite güvence grubu, yazılım yapılandırma (konfigurasyon) yönetim grubu, belgeleme/raporlama destek grubu tarafından gözden geçirilmiştir.
• Yazılım planları, ürünleri, aktiviteleri atanmış gereksinimlerdeki değişikliklere tutarlı bir şekilde değiştirilmiştir.

Gerekli Yetenekler

Yetenek –1 Her proje için sistem gereksinimlerini analiz etme ve bunları yazılım, donanım ve diğer sistem bileşenlerine dağıtma sorumluluğu tanımlanma

Sistem gereksinilerinin analizi ve atamalarının yapılması yazılım mühendisliği grubunun sorumluluğu değildir fakat işleri için bir önkoşuldur. Sorumluluk şunları kapsar:     1. Gereksinimlerin yönetimi ve belgelendirilmesi ve bunların proje yaşam döngüsü boyunca dağıtımını yapma

    2. Sistem gereksinimlerindeki değişiklikleri ve dağıtımlarını etkilemek, yönlendirme

Yetenek – 2 Atanmış gereksinimleri belgeleme/raporlama, yazıya dönüştürme

Atanmış gereksinimler aşağıdakileri içerir:      1.Yazılım projesinin aktivitesini belirleyen teknik olmayan gereksinimler (anlaşmalar, koşullar, anlaşma ile ilgili terimler).

• Anlaşma, koşul, anlaşmadan doğan terim örnekleri:
• Hazırlanması gereken ürünler
• Hazırlanma tarihleri
• Ara raporlar (milestones)

    2.Yazılımın teknik gereksinimleri.

• Teknik gereksinim örnekleri:
• Son kullanıcı, işlemci, destek, birleştirme fonksiyonları
• Performans gereksinimleri
• Tasarım kısıtlamaları
•  Programlama dili
• Arayüz gereksinimleri

3.Yazılım ürünlerinin atanmış   gereksinimleri karşılayıp karşılamadığını ölçmek için kullanılacak olan kabul edilebilirlik kriterleri.

Yetenek – 3 Atanmış gereksinimler yönetiminin yapılabilmesi için kaynak ve bütçe sağlanması

    1. Uygulama alanında ve yazılım mühendisliğinde yeterli tecrübesi olan kişilerin gereksinimleri yönetmek için atanması.     2. Gereksinim yönetimi için gerekli olan araçların sağlanması.

    Örnek araçlar:

• Hesap çizelgesi programları
• Yapılandırma yönetimi programları
• İzleme programları
• Test yönetimi programları

Yetenek 4 – Yazılım mühendisliği grubu üyeleri ve diğer yazılm ile ilgili grupların üyelerinin kendi gereksinim yönetim aktivitelerini yapabilmeleri için eğitimi

    Örnek olarak:

• Projede kullanılan metod, standard, süreç eğitimi
• Uygulama alanı eğitimi (sağlık, eğitim, hukuk vs.)

Yapılacak Aktiviteler

Aktivite – 1 Yazılım mühendisliği grubu tarafından, gereksinimler yazılım projesine geçirilmeden önce atanmış gereksinimleri inceleme

    1. Tamamlanmamış ve unutulmuş gereksinimler düzeltilir.    2.Atanmış gereksinimlerin:

•  yapılabilir, yazılım ile gerçekleştirilebilir,
•  düzgün ve açıkca belirtilmiş,
•  test edilebilir,
•  birbiriyle tutarlı olup olmadıkları kontrol edilir.

    3. Gereksinimleri atamaktan ve analiz etmekten sorumlu olan grup tarafından potansiyel olarak sorun teşkil edecek gereksinimler gözden geçirilir ve gerekli değişiklikler yapılır.

    4. Atanmış gereksinimlerden etkilenen gruplar ile görüşmeler yapılır.

    Etkilenen grup örnekleri:

• Yazılım mühendisliği
• Yazılım tahminleme
• Sistem mühendisliği
• Sistem test
• Yazılım kalite güvence
• Belgeleme/raporlama destek

Aktivite – 2 Yazılım mühendisliği grubu, atanan gereksinimleri, yazılım planını, ürünü, aktiviteler için temel olarak kullanmak

    Atanmış gereksinimler:     1. Kontrol edilebilir, yönetilebilirdir. (Herhangi bir anda, ürünün hangi versiyonu olduğu bilinmektedir ve ne gibi değişiklikler yapıldığı bilinmektedir.)

    2. Yazılım planı için referans olur     3. Yazılım gereksinimleri geliştirme için referans olur.

Aktivite – 3 Atanmış gereksinimlere yapılan değişiklikler incelenir ve yazılım projesine dahil edilir.

    1. Kurum dışı gruplarla tayin edilen gereksinimler üst düzey yöneticiler tarafından gözden geçirilir, kurum içi gruplara tayin edilen gereksinimler etkilenen gruplar tarafından gözden geçirilir.     2. Atanmış gereksinimlerdeki değişikler yüzünden plan, ürün, aktivitelerde yapılması gereken değişiklikler

• belirlenir,
• değerlendirilir,
• risk analizi yapılır,
• planlanır,
• etkilenen gruplarla iletişime geçilir,
• tamamlanana kadar gözlemlenir.

Ölçümleme & Analiz

Atanmış gereksinimleri yönetmek için kullanılan aktivitelerin durumlarını belirlemek için ölçümlemeler kullanılır

    Ölçümleme örnekleri:

• Her gereksinimin durumu,
• Atanmış gereksinimler için değişim aktiviteleri,
• Atanmış gereksinimlere uygulanan değişimlerin kümülatif sayısı

Gerçekleştirimde Doğrulama

Doğrulama – 1 Atanmış gereksinimlerin yönetimi, periyodik aralıklarla üst düzey yönetim tarafından kontrol edilir

Belirli aralıklarla yapılan bu kontrollerin amacı yazılım sürecine belirli bir soyutlama ile bakarak yanlışlıkların farkında olmaktır. Kontroller arasındaki zaman, raporlamalar ve yeni gelişmeler için yeterli olmalıdır.

Doğrulama –2 Atanmış gereksinimlerin yönetimi, periyodik ve olay-tabanlı olarak proje yöneticisi tarafından kontrol edilir

Doğrulama – 3 Yazılım kalite güvence grubu iş ürünlerini ve diğer sonuçları kontrol eder

Bu kontroller aşağıdakileri doğrular:     1. Atanmış gereksinimlerdeki problemlerin, tutarsızlıkların yazılım mühendisliği grubu onları ele almadan önce çözülmesi

    2. Atanmış gereksinimlerin değişiminde iş planlarının, ürünlerinin, aktivitelerinin doğru olarak gözden geçirilmesi

Etkili gereksinim yönetimi, yazılım kalitesini arttırır, proje yaşam döngüsü zamanını azaltır.Tam gereksinimler daha iyi bir yazılım tasarımını sağlar ve daha bakımı kolay kod oluşmasını sağlar. Böylelikle zamandan ve paradan tasarruf sağlanır çünkü yanlış mantıkta kodlama yapma veya artık istenmeyen bir özelliğin gerçekleştirimi yapılmamış olur.

 

NOT: CMM gereksinimleri nasıl yöneteceğinizi söylemez. Onun yerine yazılımın gereksinimlerini karşılamak zorunda olduğunu belirtir ve aşağıdaki soruları dikkate almanızı ister:      - Gereksinimlerin ne olduğunu biliyor musun?       - Tüm yazılım geliştirme ekibi ne yapılmak istendiğini biliyor musun?       - Gereksinimler değişince ne yapacaksın? CMM, gereksinimler değişince onları bir şekilde yönetmek gerektiğini, bunu için de izlenmesi gereken yazılı bir belge/poliçe olması gerektiğini söyler. Gereksinimlerin yönetimindeki asıl amaç, tüm projeleri kapsayan bir süreç hazırlamaktır. Gereksinimler tüm projelerde farklı olacaktır fakat genel şablon aynı olacaktır. Süreç şablonları değişmeyecektir.

NEDEN GEREKSİNİMLERİN YÖNETİMİ?

Bu soruyu verilecek en güzel yanıt şudur: “Tahminlerinizden çok, müşterinin istekleri doğrultusunda bir yazılım üretebilmek için”.

Belirsizlik, tüm proje risklerinin kökünü oluşturur. Belirsizliğin büyük bir bölümünü de yetersiz gereksinimler analizi oluşturur. Gereksiz veya tekrarlanmış gereksinimler, projenin kapsamının, maliyetinin ne olacağının belirlenmesini engeller. Dahası, projeyi durdurma noktasına getirir. Gereksinimlerdeki eksikleri gidermek, tasarım sırasında 10 kat, gerçekleştirim sırasında ise 100 kat daha fazla maliyettedir.

İyi Gereksinim Yönetimi Nedir?

• Gereksinimlerin takibi, analizi için kullanıcı merkezli, organize bir yaklaşımdır.
• Gereksinimlerin nasıl ele alınacağını ve gereksinimlerin yönetimi planını kapsar

 -   Kimler nasıl iş ile ilgili olacak?

 -   Gereksinimler ile ilgili hangi bilginin bakımı yapılacak?

 -   Yeni gereksinimlerle karşılaşılınca hangi süreç izlenecek?

• Ek gereksinimlerin belirlenmesinde proje özellikleri de göz önüne alınmalıdır

Başarılı bir proje dikkatlice oluşturulmuş ve belgelendirilmiş gereksinimlerle başlar. İyi oluşturulmuş bir gereksinimlerin yönetimi süreci proje takımına tüm projeler boyunca yardımcı olur.

GEREKSİNİMLERİN YÖNETİMİNDE KULLANILAN ARAÇLAR

Aşağıda, gereksinim yönetiminde kullanılan araçları görmektesiniz. Şunu unutmayın ki, kullanılan araç ne kadar iyi olursa olsun, kötü belirlenmiş gereksinimleri yönetmek zordur, maliyeti arttırır, çizelgeyi aşmanıza sebep olur. İnternetteki GY Araçları:

Active!Focus: www.xapware.com

AnalystPro: analysttool.com/

Caliber-RM: www.borland.com/caliber/index.html

C.A.R.E. 2.0: www.sophist.de

Catalyze: www.chiaracorp.com/requirements.htm

CORE: www.vtcorp.com

Cradle: www.threesl.com

DOORS: www2.telelogic.com/doors/index/cfm

EasyRM: www.easy-rm.com/easyrm.php3

Focal Point: www.focalpoint.se

IRqA (Integral Requisite Analyzer): www.irqaonline.com

Mac A&D and Win A&D: www.excelsoftware.com

Projectricity: www.projectricity.com/specification_tool.htm

Prosareq Requirements Manager: www.prosa.fi/eng/pr2Req.htm

Qualica QFD: qualica.de/english/requirements_mgmt.htm

RDD-100: www.holagent.com/new/products/modules.html

RDT: igatech.com/rdt/rdtwalkthrough.html

Reconcile: compuware.com/products/reconcile.html

Requirement Tracing System: www.bandwood.com/cms_exec_summary.htm

Requirements Manager: toolforsystems.com/

Requisite Pro: www.rational.com/products/reqpro/index.jsp

RMTrak: www.rmtrak.com

RTM Workshop: www.chipware.com

SLATE: www.eds.com/products/plm/teamcenter/slate

SpeedReq: www.speedev.com

Team-Trace: www.team-trace.com

TrueReq: www.truereq.com

Vital Link:  www.complianceautomation.com

XTie-Requirements Tracer: tbe.com/products/xtie

Kaynaklar:

Brackett, J.W. "Software Requirements." Curriculum Module SEI-CM-19-1.2, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., Jan 1990. This paper can be downloaded from the web at http://www.asset.com/WSRD/abstracts/ABSTRACT_1715.html.

Romback, H. D. "Software Specification: A Framework." Curriculum Module SEI-CM-11-2.1, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., Jan. 1990. This paper can be downloaded from the web at http://www.asset.com/WSRD/abstracts/ABSTRACT_1709.html.

McConnell, Steve "Software Project Survival Guide: How to Be Sure Your First Important Project Isn’t Your Last." Redmond, WA: Microsoft Press, 1998.

Jones, Do-While "Repeatable Software Development, Part I: Quality Assurance." Software Developement, May 1995.

Jones, Do-While "Repeatable Software Development, Part II: Configuration and Requirements Management." Software Developement, June 1995.

A Field Guide to Effective Requirements Management Under SEI’s Capability Maturity Model

CMM Key Practices for Level 2 - Requirements Management

LTInsights Managing Requirements for Successful Software Projects

Requirements Management Policies and Procedures

Requirements Management Using Tables

Software Program Managers Network - 16 Critical Software Practices TM

Çok kısa bir zaman gibi gelmiş olsa da
Bedenim, yeni doğmuş bebek kadar susamış yine..

Anladım sonunda sensizlik neye benzermiş..
Geliyorum yanına..