23 Şubat 2010 Salı

İş Analisti

Bir önceki makalemizde iş analisti hakkında kısaca “Müşterilerin ihtiyacını anlamaya yönelik çalışmalar yapan , senaryoları ortaya koyan pozisyondur.” demiştik. Bu yazımızda iş analistinin özellikleri ve görevlerinden bahsedeceğiz.
İş analistinin özellikleri
  1. İnsanların gerçek ihtiyaçlarını saptamak için gerekli sabra ve yeteneğe sahiptir.
  2. Alternatif yaklaşımları güçlü ve zayıf yanlarına göre karşılaştırabilir.
  3. Yüz yüze iletişim tekniklerinde bilgili ve beceri sahibidir.
  4. Karmaşık sorunları kavramsal olarak inceleyebilir. Seçenekleri belirleyerek, çözümler üretebilir.
  5. Hizmet sağlama ilkeleri ve süreçleri (İhtiyaç belirleme, hizmet kalite standartları, müşteri memnuniyeti ölçmeyi de içerir) hakkında deneyim sahibidir.
  6. Dokümanla ifade edilen bilgileri kolay ayrıştırır ve alakalandırır.
İş analistinin görevleri
  1. İş analisti proje yaşam döngüsünde projenin başlangıç aşamasında müşteriler ile yapılan ön analiz toplantılarında proje yöneticileri ile birlikte rol alır.
  2. Müşteri gereksinimlerini anlayıp, yapılacak işe özel ihtiyacı belirlerler. Gereksinimleri derleyerek geliştirilecek ürünleri tanımlar.
  3. Derlediği bilgileri etkili bir kullanımı sağlayacak şekilde dokümante eder.
  4. Kalite ve performansa yönelik olarak ürünleri, hizmetleri ve süreçleri değerlendirir
  5. Analiz sürecinde şirketin diğer birimleri ile koordineli şekilde çalışır (Başlangıç, Değişiklik, Tamamlama)
  6. Yazılım departmanı ile istek yapmaktan bıkıp usanmamış müşteriler arasında köprü görevi görür.
  7. İş  Süreçleriyle ilgili gerçekleştirilecek analiz ve tasarım çalışmalarında aktif görev alarak, analiz detaylarını analiz yazılım uzmanına aktarır. Gerektiğinde analiz yazılım uzmanı ile koordineli çalışır.
Bir sonraki yazımızda analist yazılım uzmanının özellikleri ve görevlerinden bahsedeceğiz.
Neslihan ÇALIŞKANEL

Analiz Süreci ve Rol Tanımları

Yazılım yaşam döngüsü sürecindeki (waterfall, spiral, agile,  XP vb.) ilk adım planlama ve analiz sürecidir. Proje Ekibi ve Roller isimli yazımızda, proje sürecindeki analist rolüne genel olarak değinmiştik. Kısa bir alıntı yapalım “Analist; hem proje yöneticisinin hem de geri kalan teknik ekibin iş-modeli ile ilgili sorularını cevaplayan kişidir. Yazılımcının müşterideki gözü, proje yöneticisinin analiz toplantılarındaki güvencesidir. Müşterilere gider ve ihtiyaçları belirler. Gerektiği zaman ihtiyacın yapılabilirliğinin ne kadar zor olabileceğini müşterilere anlatır. Kısacası, kod yazmaktan gözleri bozulmuş yazılımcılarla, istek yapmaktan bıkıp usanmamış müşteriler arasında köprü görevi görür…” .

Peki Analiz nedir? Analiz ve analist arasındaki bağlantı nedir? Kaç çeşit analist tipi vardır? Bu makalemizde bu sorulara kısaca cevap vereceğiz.
Bir konuyu küçük parçalara ayırıp, parçalar arasında ilişki kurarak bütünü oluşturma işlemine analiz diyoruz. Analiz işleminde öncelikle müşterinin ihtiyaçları belirlenir ve daha sonra yazılımcılar tarafından kodlama yapılır. Bir bakıma analiz insan ilişkilerinin yeniden tanımlanması ve düzenlenmesi işidir de diyebiliriz. Bir sistem yada müşteri ihtiyaçlarını analiz ederek çözüm üreten kişiye analist denir.
Analist Tipleri ve Tanımları
  • İş Analisti : Müşterilerin ihtiyacını anlamaya yönelik çalışmalar yapan , senaryoları ortaya koyan pozisyondur.
  • Analist Yazılım Uzmanı : İş analistinin oluşturduğu analizin tasarım ve modellemesini yaparak yazılımın işleyişini tanımlayan pozisyondur.
  • Sistem Analisti : Bilgi işlem sistemini tasarlayıp ihtiyaca göre çözüm öneren kişidir.
Bir sonraki makalemizde iş analisti hakkında daha detaylı bilgi vereceğiz.
Neslihan ÇALIŞKANEL, Deniz KILINÇ

22 Şubat 2010 Pazartesi

Bilgiye Erişim Sistemlerinde Arama Kalitesini İyileştirme: Normalleştirme Etkeninin Önemi

Bu makalede Akademik Bilişim 2010’da yayınlanmış olan bir çalışmanın giriş kısmı anlatılmıştır. Bilgiye erişim sistemleri, belge arşivlerinde kullanıcıların isteklerine uygun belgelere, kullanıcıların kolay bir şekilde erişimlerini sağlayan sistemlerdir. Bu sistemlerin temel amacı, kullanıcıların bilgi ihtiyaçlarını karşılamak için, belge arşivlerindeki ilgili (relevant) belgelerin hepsine erişmek, ilgisiz (non-relevant) belgeleri ise çıkartmaktır.
İnternetin yaygınlaşmasıyla daha da büyüyen veri havuzundaki bilginin çıkarılması günümüzün en popüler konularından biri olmuştur. Kullanıcıların arama motorlarında yaptıkları sorgulamalarının sonuçlarının kullanıcıların isteklerine en iyi cevabı verebilmesi de büyük önem kazanmıştır. Bilgiye erişim modeli, kullanıcının ihtiyaç duyduğu belgeye ulaşırken, belge arşivindeki sorgulamasını, belgenin içerdiği kelimeler ile yapmasına olanak tanımaktadır.
Çalışmada, kullanıcının ihtiyacı olan ilgili belgelere en iyi oranda erişerek arama kalitesinin arttırılması amaçlanmıştır. Bu amaçla, vektör uzay modeli ve eksenli benzersiz normalleştirme modeli kullanılarak bu modelinin arama kalitesindeki olumlu etkileri gözlemlenmiştir.
Bilgiye erişim modelinde kullanılan en klasik yöntemlerden biri de vektör uzay modelidir. Salton’un vektör uzay modeli, her bir belgeyi içerisindeki terimlerin ağırlığından oluşan bir vektör olarak tanımlar. Her bir terimin ağırlığını hesaplarken, terimin belgede geçme sayısıyla, bütün belge arşivinde geçme sayısını oranlayarak bir ağırlık elde eder. Bir terimin belgedeki ağırlığı hesaplanırken, uzun belgeler kısa belgelere göre avantajlı duruma geçebilir. Bu yüzden belge uzunluklarını normalleştirmek gerekmektedir. Belge uzunluklarının normalleştirilme gereksinimleri şunlardır:
  • Yüksek terim frekansları: Uzun belgeler, genelde aynı terimi çokça kez tekrar eder. Bu yüzden terim sıklık etkeni uzun belgeler için çok yüksek olur. Bu da belgedeki terimlerinin ağırlığının artmasına; sorgu ve belge benzerliği değerinin yüksek olmasına ve uzun belgelerin kısa belgelere göre daha avantajlı hale gelmesine sebep olur.
  • Fazla sayıda terim: Uzun belgeler fazla sayıda farklı terim içerir. Bu da bir sorgu ile belgenin eşleşme sayısını arttırırken aynı zamanda da belge doküman benzerliğini arttırır ve erişimde kısa belgelere göre uzun belgeleri daha şanslı bir konuma getirir.
Çalışmada ilk yöntem olan vektör uzay modelindeki normalleştirme için kosinüs benzerliği kullanılmıştır. Belgeler vektör uzunluklarına bölünerek birim vektör haline getirilmişlerdir. Fakat bu durumda belgelerin uzunlukları tamamen göz ardı edilmiştir. Belgedeki normalizasyon faktörü yine terimin ağırlığına bağımlı kalmıştır. Belgeler büyüdükçe kosinüs benzerliğinin erişim performansında zayıf kaldığı gözlemlenmiştir.
Çalışmadaki ikinci yöntem olan eksenli benzersiz normalleştirme modelinin, farklı uzunluktaki belgeler için çıkan sorunlara daha etkin bir çözüm getirerek, daha başarılı olduğu gözlemlenmiştir. Bu durumda vektörlerin birim vektör olması gerekmemektedir. Eksenli benzersiz normalleştirme modeli belgelerdeki farklı terim sayısını bir normalleştirme etkeni olarak kullanarak, farklı uzunluklardaki tüm belgelerin erişim aşamasında aynı şansa sahip olmasını sağlamaktadır. Sonuç olarak bu durum da erişim performansı arttırmaktadır.
Çalışma ile ilgili detaylara bu linkten erişebilirsiniz.
Referanslar
  • Salton G, Wong A, Yang CS. A Vector Space Model For Automatic Indexing. Communications of ACM. 1975. 18 (11): 613-620
  • Singhal A, Buckley C and Mitra M. Pivoted Document Length Normalization. Proceedings of SIGIR. 1996. p. 21-29
  • Theodora Tsikrika and Jana Kludas. Overview of the wikipediaMM task at ImageCLEF 2008. In Evaluating Systems for Multilingual and Multimodal Information Access, Proceedings of the 9th Workshop of the Cross-Language Evaluation Forum, Lecture Notes in Computer Science, vol. 5709, pp. 539-550, Springer 2009.
  • Manning D. Chirstopher, Raghavan Prabhakar and Schütze Hinrich. An Introduction to Information Retrieval, Cambridge University Press, 2009.
  • E. Garcia. Implementation and application of term weights in mysql environment, 10 2006.
  • E. Garcia. The Classic Vector Space Model,10,2006.
  • Singhal A, "Modern Information Retrieval: A Brief Overview,2006.
  • April Kontostathis and Scott Kulp, The Effect of Normalization when Recall Really Matters,2008.
  • Ricardo Baeza-Yates,Berthier Ribeiro-Neto,Modern Information Retrieval,1999.
Özlem KARAGEDİK, Deniz KILINÇ

15 Şubat 2010 Pazartesi

Mobil Cihazların Teknik Özellikleri ve Proje Tasarım Aşamasında Dikkat Edilmesi Gerekenler

En genel tanımıyla el bilgisayarı (PDA), isim ve adreslerin saklanabildiği bir veritabanı ve kişisel iş planlarının tutulduğu bir takvimi olan, çeşitli iletişim özellikleri (Wireless, GPRS, Bluetooth) ile internet erişimine olanak sağlayan bir araçtır. PDA olarak nitelendirilebilen ilk cihaz (Psion Organizer) sadece telefon rehberi ve ajanda gibi özelliklere sahipken, her türlü komünikasyon tekniğini destekleyen, çok çeşitli programların rahatlıkla çalıştırılabildiği bir bilgisayar haline gelmiştir.
Elektronik, yazılım ve haberleşme alanlarının paralel gelişimiyle birlikte el bilgisayarlarının artan özellikleri, çok farklı alanlarda, farklı amaçlarla kullanılabilmelerine olanak sağlamıştır. Cihazların farklı kullanım amaçları için özelleştirilmesi, temelde benzer olan el bilgisayarlarının farklı isimlendirilmelerine neden olmuştur. Buna örnek olarak, telefon ve bilgisayar özelliklerini birleştiren fakat telefon işlevleri ön planda olan ‘smartphone’(Şekil 1-a), harita üzerinde konum belirleme ve rehberlik yapma özelliği ön plana çıkan ‘Navigator’(Şekil 1-b) örnek verilebilir. PDA’lar ayrıca kişisel kullanım amaçları dışında endüstriyel alanda da kullanılmaya başlanmıştır. Endüstriyel kullanıma uygun olarak barkod okuyucusu, tuş takımı ve daha uzun ömürlü güç kaynağı olan, daha sağlam cihazlar üretilmiş, endüstriyel cihazlar(Şeil1-c) olarak isimlendirilmişlerdir.
image
Bizim için önemli olan cihazların hangi işlevlerinin ön planda olduğu değil, Windows Ce tabanlı bir işletim sisteminin olup olmadığıdır. Çünkü Visual Studio ile geliştirdiğimiz smart device projelerini sadece Windows tabanlı işletim sistemi olan akıllı cihazlarda (smart device) çalıştırabiliyoruz.
El bilgisayarlarının zaman içindeki fonksiyonel gelişimi, bilgisayar elektroniğindeki gelişmeler zemininde mümkün olmuştur. İlk PDA’nın basit işlevleri için 8 bitlik işlemci, 4K ROM ve 2K RAM yeterli görünüyordu. Fakat şu anda masaüstü bir bilgisayarda gerçekleştirilen birçok işlemi, sınırlı özelliklerle de olsa gerçekleştirebilen akıllı cihazlardan bahsediyoruz. Bu işlemlere olanak sağlayan, temelde işlemci, bellek ve güç kaynağı gibi teknik özelliklerin ilk zamanlara nazaran çok ileri seviyelerde olduğunu söyleyebiliriz.
Bu makalenin konusu olan ve mobil yazılım geliştirmeyi çok yakından ilgilendiren teknik özellikleri alt başlıklar halinde, yazılım geliştirme sırasında dikkat etmemiz gereken bazı konulara da değinerek, özetlemeye çalışacağım;
İşlemci: Windows Ce tabanlı el bilgisayarlarında en çok kullanılan ve Visual Studio’ nun desteklediği işlemci tipleri; ARM, SH4 ve MIPS’ tir. Yeni çıkan cihazların işlemci hızları çoğunlukla 512 Mhz- 1 Ghz arasındadır. Fakat şu an piyasada kullanımda olan bazı eski cihazlarda işlemci hızı 100 Mhz’ ye kadar düşmektedir. Yeni üretilen el bilgisayarı işlemcileri hızlı olsa da paralel işleme yetenekleri masaüstü işlemcilerden oldukça sınırlıdır. Bu yüzden çok kanallı (multithreaded) tasarımlarda child thread’lerin işlemciyi çok fazla boğmayacak şekilde düzenlenmesi gerekmektedir.
Bellek: İlk olarak 6K’lık bellekle kendini gösteren PDA’ ların günümüzdeki temsilcileri 512 MB’ a varan bellek donanım desteğiyle piyasaya sürülmektedir. El bilgisayarlarında hard drive yoktur, “Storage” ve “Program” olarak ikiye ayrılan RAM vardır. “Storage” bölümü işletim sisteminin ve sonradan kurulan yazılım dosyalarının tutulduğu, dosya kopyalanıp silinebilen bir bellek alanıdır(ROM gibi düşünülebilir). “Program” bölümü ise, isminden de anlaşılacağı gibi, programların çalışırken kullandıkları bellek alanıdır. Masaüstü bilgisayarlardaki RAM gibi işlev görür. El bilgisayarı belleği başlangıçta her iki bölüme eşit büyüklükte yer tahsis edecek şekilde bölünür. Fakat Windows Mobile 5.0 işletim sisteminden önceki Windows CE sürümleri “program” ve “storage” bellek bölümlerinin büyüklüklerini değiştirmek için olanak sağlar.
Yeni çıkan el bilgisayarlarının bellek büyüklükleri yeterli görünebilir fakat piyasada kullanımda olan cihazların belleklerinin 32 MB – 512 MB arasında değişkenlik gösterdiği düşünülerek yazılımsal tasarım yapılmalıdır. Executable dosyaların veya dll’lerin boyutunun çok büyük olması programın çalışması sırasında bellek yetersizliği hatalarının alınmasına ve programın kullanılamamasına neden olabilir. Bellek yetersizliğine sebep olabilecek başka bir tasarım hatası da ekranların çok kalabalık olması ve anlık olarak belleğe çok büyük boyutlarda verinin yüklenmesidir. Ekranlar, masaüstü program ekranları gibi bütün işlemleri tek bir ekrandan yapacak şekilde değil, işlemi mantıksal küçük parçalara bölerek adım adım gerçekleştirecek şekilde tasarlanmalıdır.
Güç Kaynağı: El bilgisayarlarında güç kaynağı konusu, tüm mobil cihazlarda olduğu gibi problemli bir konudur. Ebatları küçük olan el bilgisayarlarına entegre edilecek güç kaynağının çok uzun ömürlü olmayacağı tahmin edilebilir. Endüstriyel cihazlarda daha dayanıklı güç kaynakları kullanılmakta, fakat onlar da tatmin edici değildir. Ayrıca cihazlar uzun süre kullanıldıkları zaman bataryaların güç depolama yetenekleri de azalmaktadır.
Mobil cihazlarda en fazla güç tüketimine neden olan işlemler, sürekli ortamdaki sinyalleri dinleyen kablosuz haberleşme process’leridir. Programın kullanmadığı veya sürekli açık kalması gerekmeyen telefon, wireless, Bluetooth, Kızılötesi, GPS gibi özellilerin kapatılması az da olsa güç kullanımını azaltır.
Ekran: PDA ekranlarının boyutları kullanım amaçlarına göre farklılık gösterir. Fakat bizim için önemli olan ekranın fiziksel büyüklüğü değil, çözünürlüğüdür. Piyasadaki el bilgisayarlarına baktığımız zaman ekran çözünürlüklerinin 240x240 piksel, 240x320 piksel, 320x320 piksel vb. şekilde tasarlandığını görürüz. Geliştirdiğimiz programlardaki ekranları ve ekran bileşenlerini kullanacağımız el bilgisayarının ekran çözünürlüğüne göre düzenlememiz gerekir. Aksi durumda, programın çalışması sırasında hem görsel hem de işlevsel sorunlarla karşı karşıya kalırız. Örneğin, 320x320 piksel ekran boyutuna göre düzenlenmiş bir ekran, 240x240 piksel çözünürlükte bir el bilgisayarında çalıştığında ekranın tamamı görünmeyeceği için, sağda ve altta scrollbar’lar çıkar. Bu durum kullanıcının ekranı sürekli sağa-sola, yukarı-aşağı kaydırmasını gerektirir ve kulanım açısından istenen bir durum değildir.
Çözünürlük dışında dikkate alınması gereken bir diğer konu da ekranın dokunmatik özelliğidir. Ekranın dokunmatik olmaması durumunda ekransal işlemler cihaz klavyesiyle yönetilecek şekilde tasarlanır. Dokunmatik özelliği olan cihazlarda ise ekran bileşenleri üzerindeki hareketleri algılayabilir, ona göre programın tepki vermesini sağlayabiliriz.
Klavye: Kulanım amacına bağlı olarak, bazı el bilgisayarlarında tuş takımı var, bazılarında da yoktur. Tuş takımı ve ekranın dokunmatik özelliği birbirini yakından ilgilendiren özelliklerdir. Çünkü birbirinin yerine kullanılabilen girdi (input) araçlarıdır. “Ekran” alt başlığında da belirttiğim gibi, ekranın dokunmatik olmaması durumunda, geliştireceğimiz programlardaki ekranlarda tüm işlemler klavye aracılığı ile gerçekleştirilmek zorundadır. Bu durumda işlemler çoğunlukla ‘kısa yol’ (shift+1, ctrl+2 vb) kullanımı ile kolaylaştırılır. Kısa yollar, hem dokunmatik ekranı hem de tuş takımı olan el bilgisayarlarında da, kullanımı daha da kolaylaştırmak için tercih edilebilir.
Günümüz el bilgisayarlarının yetenekleri oldukça iyi bir seviyeye ulaşmıştır. Fakat mobil yazılım geliştirme ortamı olarak kullandığımız “Visual Studio” da aynı oranda gelişmiş ve cihazların teknik özelliklerini zorlar bir duruma gelmiştir. Bu yüzden kullandığımız yazılım araçlarının ve el bilgisayarlarının teknik detayları dikkate alınarak, geleceği gören bir vizyonla programlarımızı tasarlamamız gerekir. Aksi durumda, programların kullanılmaya başlamasıyla karşılaşılacak birçok hata, altyapısal değişiklik gerektirir ve onarımı zordur.
Mehmet BÜYÜKAŞIK

13 Şubat 2010 Cumartesi

Yazılım Yeniden Yapılandırma (Reengineering) Mühendisliği (Bölüm 1)

Düzenli olarak kullandığınız bir ürünü düşünün. Zamanında ondan çok verim almanıza rağmen, ürünün teknolojisi giderek yaşlanmaya başlar. Sürekli bozulmalarla birlikte tamir süresi daha çok zaman alır. En önemlisi, gelişen diğer teknolojilere ayak uyduramaz. Eğer kullandığınız ürün, fiziksel bir donanımsa onu atar ve yenisini satın alırsınız, eğer geliştirdiğiniz bir yazılım ise atmak yerine, tekrar düzenlersiniz.
Yeniden yapılandırma mühendisliği, herhangi bir organizasyonda yapı, sistem, süreç ve uygulanan politikalarda hızlı ve radikal yeniden tasarım ve değişiklikler yapılarak organizasyonun daha yüksek performansa ulaşmasını amaçlayan bir yönetim tekniğidir. 1990’ lı yılların başında ortaya çıkan bu kavram, yönetim dünyasında çok büyük bir ilgi görmüş ve günümüze değin bu alanda çok önemli ilerlemeler kaydedilmiştir.
Bugün çevremizde kullanılan birçok yazılımın yaşam süresi ortalama 5 yıl ve üzerindedir. Bu programlar yazıldığı zamanın en iyi kodlama ve tasarım teknikleri ile geliştirilmiş olsalar bile, o zamanki en önemli sistem sorunlarına göre kurgulanmışlardır. Yazılan bu programlar daha sonra yeni platformlara taşınmaya çalışılmış, çeşitli donanımlara ve işletim sistemlerine göre tekrar düzenlenmiş ve en güzeli de :) yeni müşteri istekleri bu programlara entegre edilmiştir. Sonuçta kötü tasarlanmış yapılar, kodlamalar, mantık ve dokümantasyon oluşmuştur. Bu durumu önlemek için çeşitli süreç modelleri kullanılmaktadır. Bunlardan en çok kullanılanı, “Yeniden Yapılandırma Mühendisliği Süreç Modeli”dir[1].

Yazılımlar İçin Yeniden Yapılandırma Süreç Modeli
Bu süreç modeli gerçekten çok zaman ve kaynak isteyen bir modeldir. Aylar sürebilir. Sürecin her bir adımını tamamı ile işletmek zorunda değilsiniz. Bulunduğunuz organizasyona göre değişiklikler yapabilirsiniz. 6 ana aktiviteden oluşur.
image
Şekil 1. Yazılım yeniden yapılandırma mühendisliği süreç modeli
1. Envanter Analizi
Sistemdeki tüm uygulamalar bir tabloya yazılır ve her uygulama için kriter listesi doldurulur. Bu listede;
  • Uygulama adı
  • Uygulamanın yazılma tarihi
  • Uygulama üzerinde yapılan değişiklik sayısı.
  • Yapılan değişikliklerin tamamlanması için harcanan toplam kaynak
  • En son yapılan değişiklik tarihi
  • En son yapılan değişiklik için harcanan toplam kaynak
  • Uygulamanın çalıştığı sistemin altyapı bilgisi (İşletim sistemi bilgileri...)
bilgileri yer alır.
2. Dokümanın Yapılandırılması
Bu aktivitede uygulanabilecek çeşitli yaklaşımlar mevcuttur. Sistemin kritikliğine göre dokümantasyonun en baştan yaratılması ya da hiç değiştirilmemesi seçilebilir. Yaklaşımlar aşağıdaki gibidir:
  • “Dokümantasyonu tekrar yazmak çok zaman alıcıdır”. Bazı durumlarda en doğru yaklaşım olabilir. Mesela yüzlerce uygulaması olan bir sistemde, her biri için ayrı doküman yaratmak uzun zaman alacaktır.
  • “Dokümantasyon az kaynak ayrılarak yenilenmelidir”. Uygulamanın tamamını baştan dokümante etmek gerekmeyebilir. Onun yerine sistemin değişmeye başlayan kısımları için doküman yazılır.
  • “Kritik bir sistemdir ve tüm doküman baştan yazılmalıdır.”
Önümüzdeki makalede (Bölüm 2) diğer aktiviteleri anlatacağız.
Referanslar
  1. Ralyte J., Rolland C, An Approach for Method Reegineering, Springer Berlin / Heidelberg, 2001, ISBN: 978-3-540-42866-4
Deniz KILINÇ

10 Şubat 2010 Çarşamba

Visual Studio 2008 Test Edition Web ve Load Test İncelemesi (Bölüm 4)

Diğer makalelerimizde kurulum sürecini tamamladığımız (Bölüm 1, Bölüm 2, Bölüm 3) Visual Studio 2008 Test Edition’ın bu makale ile birlikte kullanımına giriş yapacağız.
Visual Studio içerisinden Controller Seçimi ve Yönetimi
Visual Studio Team System Test Edition kurulduktan sonra, “Test” menüsünden, “Administer Test Controllers …” menü adımına tıklayalım.
image
Eğer ilk kez giriş yapılıyorsa, ekran görüntüsü aşağıdaki gibi olacaktır.
image
Yük testi sonuçlarının kaydedilebilmesi için, “Load Test Results Store” adı altındaki veritabanı bağlantı metnini kontrol etmeniz gerekmektedir. Bağlantı için gereken veritabanı adı “LoadTest” olmalıdır. Bu ayar yapılmadığı takdirde, yük testi gerçekleştiremezsiniz. Yük testini sadece yerel makinenizden yapacaksanız, “Web Testing”  bölümüne geçebilirsiniz.

Dağıtık Yük Testi için “Controller” Seçimi ve “Agent” Ayarları
Dağıtık yük testi için diğer makinelere “Agent” kurulumu yapıldıysa ve bu servisler, yine farklı bir makinedeki “Controller” servisine bağlandıysa, “Controller” servisinin bulunduğu makinenizin adını yazmanız gerekir.

image
Bir süre bekledikten sonra, “Agents” listesine, bu “Controller” servisine bağlı olan servisler listelenir. Açıklamak gerekirse, “Controller” servisi ve bir adet “Agent” servisi yerel makinemde kuruludur. Bir başka “Agent” servisi ise, “VMW7ALI” sanal makinesinde kuruludur. Eğer bu listede gözüken “Agent” servislerinden bir veya birkaçı “Disconnected” durumda ise, servisiniz, Windows Kimlik Denetimine takılıyor olabilir. Bunu aşmak için, ilgili makineye yönetici hakları ile bağlanabiliyor olmanız gerekmektedir. Bu örnekte;
\\VMW7ALI\c$\
C sürücünüzün yöneticiler için yaratılan varsayılan paylaşım dizinine erişmek istediğinizde aşağıdaki ekran ile karşılaşacaksınız.
image
Buraya, o makinede tanımlı (yerel kullanıcı da olabilir) yönetici hakları ile bağlanın ve tamama tıklamadan önce bilgilerinizin kaydedilmesi için onay kutusunu işaretleyin. Daha önce de bahsetmiştik, test ortamınız bu haklar ile erişime imkân tanımıyorsa, sanal makineler üzerinden test ağınızı kurmanız gerekmektedir.
“Agent” servisleriniz hazır hale geldikten sonra, dilerseniz bu servisleriniz arasında yük paylaşımı yapabileceğiniz gibi, NLB (Network Load Balancing) olan ağlarda simülasyonunuzu daha gerçekçi kılmak için IP değişimi (IP Switching)  de yapabilirsiniz.
“Agent” servislerine, yük testinde vereceğiniz toplam sanal kullanıcı sayısını “Weighting” özelliği üzerinden paylaştırabilirsiniz. Buraya girilen değer % olup, toplam sanal kullanıcı sayısının % kaçını bu servisin oluşturacağını belirtebilirsiniz. Örneklemek gerekirse, toplamda 500 sanal kullanıcı yaratılacaksa, %60lık bir oran, 300 sanal kullanıcının ilgili servis tarafından yaratılacağını ifade eder. Aşağıdaki örneklerde, yerel makinem zaten “Controller” servisi ve Visual Studio IDE sine hizmet ettiği için %30luk (150 kullanıcı) oran girildi. Sanal makinede ise %100 ü tamamlaması için, %70 girildi.
image
Ali KALFAOĞLU

3 Şubat 2010 Çarşamba

Visual Studio 2008 Test Edition Web ve Load Test İncelemesi (Bölüm 3)

Son makalemizde, Bölüm 2’de anlatmaya başladığımız kurulum sürecinin devamındaki Controller ve Load Agent servislerinin kurulumlarını detaylandırmaya çalışacağız.
Controller Kurulumu
Controller kurulumu için, açılan kurulum sayfasından, “Install Team Test Load Agent Controller” bağlantısına tıklamanız gerekmektedir. Biraz bekledikten sonra, aşağıdaki ekran görüntüsü karşımıza çıkar. Burada, Controller servisinin açılışta otomatik başlatılması için, ilgili makinede mutlaka Yönetici (Administrator) haklara sahip kullanıcı adı ve şifresi girilmelidir. Aksi durumda, kurulum başarı ile tamamlansa bile servis başlatılamaz.
image_thumb[15]
Kurulum sonrasında yapılması gereken basit ama yapılmadığı durumlarda, Visual Studio – Controller – Load Agent çemberinde iletişim problemlerini gideren bir ayarımız var. Bu düzenlemenin yapılmadığı durumlarda, kullanılan makinelerinizin statik IP adresi yoksa ve/veya yerel ağ bağlantısı varken, kablosuz ağ bağlantısı da açıksa, servisler arası iletişimde problem yaşanabiliyor.
Bu problemi aşmak için, “Controller” servisinin XML “Config” dosyasına, hangi IP adresi üzerinden diğer servislerle iletişime geçeceğini belirtmemizde fayda var. Bunun için;
  • “IPConfig” ile “Controller” kurduğumuz makinenizin bağlantı adresini öğrenelim. Bu örnekte, yerel ağ bağlantısını tercih ettiğimiz için, IP adresimiz, “192.168.1.157”dir.
image_thumb[18]
  • Kurulumda varsayılan olarak gelen dizinin değişmediğini düşünürsek;
“C:\Program Files\Microsoft Visual Studio 9.0 Team Test Load Agent\LoadTest”
Dizini altındaki “QTController.exe.config” dosyasını açalım ve dosyanın en sonuna, “appsettings” etiketleri arasına aşağıdaki satırı ekleyelim.
<add key="BindTo" value="192.168.1.157" />
Dosyanın son hali aşağıdaki gibidir.
image_thumb[21]
“Services.msc” konsolunu açıp “Visual Studio Team Test Controller” servisimizi tekrar başlatıp, kullanıma hazır hale getirelim. Bu şekilde, “Controller” servisimiz için hangi IP adresi üzerinden bağlantı kurulacağını sabitlemiş oluyoruz. Bağlantımızın, dolayısıyla IP adresimizin değişmesi durumunda, mutlaka bu bilginin de güncellenmesi gerekmektedir.
Yukarıdaki ekran görüntüsünde gözümüze çarpan bir diğer nokta da, “ControllerServicePort“ bilgisidir. Burada, kurulum ile gelen varsayılan bağlantı noktası 6901dir ve eğer sisteminizde kullandığınız bir firewall programı varsa, TCP ve UDP protokolleri için 6901 numaralı bağlantı noktası için açık olması gerekmektedir.
Load Agent Kurulumu
“Controller” kurulumumuzu tamamladıktan sonra, sıra, yük testlerinin dağıtımının yapılacağı makinelerde hazırlanması gereken “Load Agent” kurulumuna geldi. Bunun için kurulum sayfasında gelen “Install Team Test Load Agent” bağlantısına tıklayalım.
Bir süre bekledikten sonra, “Controller” kurulumunda olduğu gibi, “Service Logon” hesap bilgilerinin girilmesi gereken bir ekran karşımıza gelecek. Bu hesap bilgisinin, “Agent” kurulumunun yapıldığı makinede, Yönetici (Administrator) haklarına sahip olması gerekmektedir.
image_thumb[24]
Hesap bilgilerini girip, “İleri”ye tıkladıktan sonra, “Controller” kurulumundan farklı olarak, “Load Agent” ın hangi IP adresine bağlanacağını belirteceğimiz bir ekran daha karşımıza gelecek.
image_thumb[27]
Buraya, daha önce kurulumunu yaptığımız “Controller” servisi ile bağlantı kurulacak IP adresini girelim. Kurulum tamamlandıktan sonra, “Load Agent” servisine ait 2 adet XML Config dosyasına, yine “Controller” kurulumunda yaptığımız gibi, kurulduğu makinenin IP adreslerini girelim. Bunun için;
  • IPConfig ile “Agent” kurduğumuz makinenin bağlantı adresini öğrenelim. Bu örnekte, yerel ağ bağlantısını tercih ettiğimiz için, IP adresimiz, “192.168.1.59”dur.
image_thumb[31]
  • Kurulumda varsayılan olarak gelen dizinin değişmediğini düşünürsek;
“C:\Program Files\Microsoft Visual Studio 9.0 Team Test Load Agent\LoadTest”
Dizini altındaki “QTAgent.exe.config” ve “QTAgentService.exe.config” dosyalarını açalım ve en sonuna, “appsettings” etiketleri arasına ekleyelim.
<add key="BindTo" value="192.168.1.59" />
Dosyaların son hali aşağıdaki gibidir.
image_thumb[34]
“Services.msc” konsolunu açıp “Visual Studio Team Test Agent” servisimizi tekrar başlatıp, kullanıma hazır hale getirelim.
Kullanım sırasında karşılaşılabilecek bir problem ise, “Controller” servisinin kurulu olduğu makine, “Agent” servislerinin kurulu olduğu makinelere, Visual Studio geliştirme ortamından erişmeye çalıştığı sırada, “Windows Kimlik Denetimine” takılabilir. Bunu aşmak için, “Controller” servisinin kurulu olduğu makineden, “Agent” servisinin kurulu olduğu makineye Yönetim hakları ile bağlanılabiliyor olmanız gerekmektedir. Böyle bir durumda, bulunduğunuz ağ sistemi bu tür yetkileri vermeye uygun değilse, “Agent” kurulumlarınızı Sanal Makinelere kurmanızı (Microsoft Virtual PC / Windows 7 XP Mode / VMWare Workstation) tavsiye ederiz.
Ali KALFAOĞLU

2 Şubat 2010 Salı

Mobil Cihazların Gelişimi

Bilgisayarda ‘Mobilite’ kavramı, insanların bulundukları yerden bağımsız olarak bilgiye ulaşma ve bilgiyi işleme gereksinimleri ile tartışılmaya başlanan ve günümüze kadar çok ciddi gelişim aşamalarından geçen bir kavramdır. Tarihte ilk taşınabilir bilgisayar 1981 yılında Adam Obsorne tarafından geliştirilen ve “Obsorne 1” olarak isimlendirilen sistemdir.(Şekil 1-a)
image
Obsorne 1, “BASIC”, “WordStar”, ve “SuperCalc” programlarından oluşan bir yazılım paketi içeriyordu. Günümüz taşınabilir bilgisayarları ile kıyaslandığı zaman komik görünüyor olabilir, fakat geliştirildiği dönemin ihtiyaçlarını fazlasıyla karşılıyordu.
Obsorn 1’in ardından, Rod Canion, Jim Harris and Bill Murto tarafından 1982’de geliştirilen ve 1983’te piyasaya sürülen taşınabilir kişisel bilgisayar tüm dikkatleri üzerine çekmeyi başardı.(Şekil 1-b)
Dönemin en popüler kişisel bilgisayarı olan IBM PC ile %100 uyumlu olması, MS-DOS işletim sistemi çalıştırması ve yüksek performansı ile “Obsorne 1”i gölgede bıraktı. 8088 işlemcisi, 2 adet 5.25” disk yuvası, 128 KB Ram ve 9” yeşil monochrome ekranı, IBM PC’ye yakın işlevleri yerine getirmesini sağlıyordu.
İlerleyen zamanlarda farklı firmalar, var olanın üstüne yeni özellikler ekleyerek taşınabilir bilgisayarların çok daha ileri noktalara taşınmasını sağladılar. “Obsorne 1” ve “Compaq Portable” ile başlayan taşınabilir bilgisayar sektörünün günümüzdeki temsilcileri “notebook” veya “laptop” olarak isimlendirdiğimiz, çok geniş ürün yelpazesine sahip dizüstü bilgisayarlardır.

Asıl ilgi alanımız olan PDA konusunda ise ilk girişim 1983 yılında Casio firması tarafından geliştirilen CASIO PF-3000’dir.(Şekil 2-a) İleri matematiksel işlemlerin yapılabildiği, telefon rehberi, ajanda gibi özelliklere sahip bu ürünü PDA olarak nitelendirmek yanlış olur. Fakat PDA fikrinin geliştirilmesinde büyük pay sahibi bir öncüldür. PDA olarak kabul edilen ilk cihaz Psion firması tarafından 1984 yılında piyasaya sürülen “Psion Organizer”dır.(Şekil 2-b) 8 bitlik Hitachi işlemcisi, 4K ROM ve 2K RAM’i ile PDA tanımına yakın özellikler taşıyordu, fakat bir işletim sistemi yoktu. (Psion firması aynı zamanda Symbian işletim sistemini geliştiren firmadır)
PDA terimi ilk olarak 1992 başlarında Apple firmasının tanıttığı “Apple Newton” ürünü ile kullanılmaya başlandı.(Şekil 2-c) Dokunmatik ekran özelliği ve üzerinde birçok program çalıştırılabilen bir işletim sistemine sahip ( Newton ) olan “Apple Newton” ilk PDA olarak kabul edilir.
image
1996 yılında Nokia firmasının, PDA özellikleri ile telefon özelliğini birleştirerek geliştirdiği “9000 Communicator” ilk smartphone olarak kabul edilir.(Şekil 2-d) Nokia firması, bu üründen sonra ürettiği tüm smartphone’larda işletim sistemi olarak Symbian’ı kullanmıştır.
Aynı sene Palm şirketi “PalmPilot” isimli PDA’sını piyasaya sürdü. Motorola 6800 işlemci ve Palm işletim sistemi ile çalışıyordu.(Şekil 3-a)
image
1996 yılı aynı zamanda Microsoft’un PDA’lar ve endüstriyel cihazlar için geliştirdiği Windows CE (Versiyon 1.0 ) işletim sistemini kullanıma sunduğu yıldır. 1 MB’ın altında RAM’le çalışmak üzere tasarlanmış olan Windows CE daha çok endüstriyel cihazlarda kullanım alanı bulmuştur. Masaüstü işletim sistemlerine benzetilen görselliği PDA’lardaki kullanımını zorlaştırmıştır. Windows tabanlı işletim sistemi kullanan ilk PDA’lar bu tarihten itibaren üretilmeye başlanmıştır.
1999 yılında Palm şirketinden ayrılan Jeff Hawkins, Donna Dubinsky, ve Ed Colligan, kurdukları “HandSpring Visor” şirketi bünyesinde “Visor” olarak isimlendirdikleri bir PDA geliştirdiler.(Şekil 3-b) Visor hem donanım hem de yazılım olarak günümüz PDA’ları ile benzerliği ile dikkat çekicidir.
2000 yılına gelindiğinde Microsoft şirketi Windows CE’deki başarısızlığının ardından “Pocket PC 2000” işletim sistemi ile piyasayı yeniden zorlamaya başladı. PocketPC2000’in ekran tasarımları, Windows CE’ye nazaran daha kullanışlıydı, fakat hala eksiklikleri vardı.
2002’de RIM firması “Blackberry” olarak isimlendirdiği smartphone’u piyasaya sürdü.(Şekil 3-c) Birçok PDA özelliği ve kullanımı rahat klavyesiyle dönemin gözdesi haline geldi. Popülaritesinin kısa zamanda azalacağı yönündeki düşünceler vardı. Fakat Blackberry, hızlı gelişimi ve piyasanın ihtiyaçlarına adaptasyonu sayesinde popülaritesini daha da arttırıp, günümüzün smartphone alanındaki lideri haline geldi.
Microsoft, işletim sistemi çalışmalarına devam ettiğini, 2002’de çıkardığı Pocket PC 2002 ile gösterdi. Pocket PC 2002 ile Pocket PC2000 arasında çok fazla bir fark yoktu. 2003 yılında Windows Mobile ismini kullandığı ilk işletim sistemi olan “Windows Mobile 2003”ü piyasaya sürdü. “Pocket PC” versiyonlarına nazaran değişen görselliği ve kullanışlılığı ile, pazar payını çok büyük oranda arttırdı.
Aynı sene Palm şirketi, “Visor” versiyonu üzerinde donanımsal ve yazılımsal geliştirmeler sonucunda ortaya çıkardığı “PalmOne”’ı tanıttı.(Şekil 3-d) Sonraki yıllarda Windows Mobile işletim sistemi üzerinde çalışan (Treo 750 modeli gibi) farklı versiyonlar çıkardı.
2007 yılı, Apple firmasının, “Apple Newton”dan 15 sene sonra çıkardığı “IPhone” ile çalkalandı.(Şekil 3-e)Müthiş görselliği, işlevsellik ve kullanılabilirlik özellikleri ile smartphone konusuna çok farklı bir bakış açısı kazandırdı. IPhone’un İlk versiyonuna dahil edilmeyen GPS, MMS gibi özellikler, sonraki yıllarda çıkarılan yeni versiyonlara dahil edilmiştir.
Google firması, 2005 yılında çalışmalarına başladığı Linux tabanlı işletim sistemi (Google Android) 2007’de tamamlayıp, tanıtımını yaptı.(Şekil 3-f) 2008 yılında çıkarılan 1.0 versiyonu ile Amerika’da en başarılı 5 smartphone arasına girmeyi başardı. 2009 yılında birçok donanım üreticisi firma, Android işletim sisteminin 1.5 versiyonunu kullanan yeni cihazlar geliştirdi.
Donanım, yazılım ve telekomünikasyon firmalarının PDA ve smartphone sektöründeki rekabeti günümüzde devam etmektedir. Microsoft firması 2003 yılından sonra Windows Mobile 5.0, 6.0 ve 6.5 versiyonlarını çıkardıktan sonra 7.0 versiyonu üzerinde çalışmalarını devam ettirmektedir. RIM firmasının, “Blackberry” ürünü piyasadaki popülaritesini koruyor. Diğer taraftan Google “Android 1.5”’ten sonra 2.0 ve 2.1 versiyonları ile, Apple firması ise 3G IPhone ve 2010 yılı başlarında piyasaya sürdüğü, ve alanında devrim olarak nitelendirilen “ipad” ile bu piyasanın iddialı isimleri olduklarını göstermektedirler.
Referanslar
Mehmet BÜYÜKAŞIK

1 Şubat 2010 Pazartesi

Visual Studio 2008 Test Edition Web ve Load Test İncelemesi (Bölüm 2)

Kurulum ve Ayarlar
Bölüm 1’de genel bir giriş yaptıktan sonra Visual Studio Test Sürümünün kurulumuna başlıyoruz. Bunun için, aşağıda belirtilen bağlantılardan 90 günlük deneme sürümlerini indirebilirsiniz.
Team System Team Suite için:
http://www.microsoft.com/downloads/details.aspx?FamilyId=D95598D7-AA6E-4F24-82E3-81570C5384CB&displaylang=en
Team Suite Test Load Agent için:
http://www.microsoft.com/downloads/details.aspx?FamilyID=572e1e71-ae6b-4f92-960d-544cabe62162&DisplayLang=en
Team Suite Kurulumu

image
Bir süre bekledikten sonra, kurulum şeklini soran bir ekran karşımıza gelecektir. Burada, bütün araçların kurulması için tam kurulumu seçebiliriz veya eğer, özel kurulum seçiliyorsa, aşağıdaki ekran karşımıza geldikten sonra;

image
Resimde gösterilen seçeneklerin işaretlendiğine emin olduktan sonra kuruluma devam edip tamamlayabiliriz. Kurulum sonrasında karşılaşabileceğiniz problemlerden biri, Visual Studio geliştirme ortamını çalıştırdığımızda, Proje şablonlarınızın kaybolması olabilir. Bunu gidermek için (varsayılan kurulum dizinin değişmediğini kabul edersek) komut isteminden;
“C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ devenv.exe /installvstemplates”
İle çalıştıralım. Bu şekilde Visual Studio, açılışı, Proje Şablonlarını olması gereken dizinlere geri yükleyerek gerçekleştirecektir.
Yukarıda belirttiğimiz bağlantıdan Team Suite Test Load Agent 90 günlük deneme sürümünü indirilip, setup.exe çalıştırıldıktan sonra, aşağıdaki ekran karşımıza gelir. Bu ekrandan, “Controller” ve “Load Agent” kurulumu yapılabilir.
image
“Agent Controller” olarak adlandırılan servis, dağıtık yük testi yapabilmek için farklı makinelere kurulan “Load Agent” servislerinin yönetiminden sorumlu olan servistir. “Load Agent” servisi, Web ve yük testi metriklerinin anlık toplanmasını ve bu bilgilerin Visual Studio IDE sine aktarılmasını sağlar.
Dolayısıyla, uygulamanız için yük testi düşünmüyorsanız veya bu yük testini, sadece “Visual Studio” geliştirme ortamının kurulu olan makineden gerçekleştirecekseniz, “Controller” ve/veya “Load Agent” kurmanıza gerek yoktur. Bölüm 3’de bu servislerin kurulumlarını detaylandıracağız.
Ali KALFAOĞLU

.NET Mobil Yazılım Geliştirmeye Giriş

Microsoft Visual Studio ortamında mobil yazılım geliştirme, ortamın bize sağladığı araçlar, kütüphaneler ve kullanıcı dostu arayüzler ile çok basit bir hale getirilmiştir. Bu konuyla daha önce hiç ilgilenmemiş, mobil cihazlar ve compact işletim sistemlerine yabancı olsak bile kısa bir çalışmanın sonunda mobil dünyaya dahil olabilir, kendimizi geliştirmeye devam edebilmek için gereken altyapıyı sağlayabiliriz.
Mobil yazılım geliştirmeye yeni başlayan birini en çok endişelendirecek ve ona en çok zamanı kaybettirecek süreç, VS.Net ortamının sunduğu araçları, mobil cihazları, Windows tabanlı compact işletim sistemlerini tanımaya çalışacağı süreç olacaktır. Sistematik bir çalışma yapılmadığı zaman bu süreç yıpratıcı ve varılmak istenen hedeften soğutucu bir hal alabilir.
Bu yüzden işin tarihinden, yani hikayesinden başlayarak, el bilgisayarlarının genel teknik özellikleri, Windows CE (Compact Edition) tabanlı işletim sistemlerinin gelişim süreçleri ve Visual Studio’nun mobil yazılım geliştirme ile ilgili araçlarını konu alan bir makale dizisi hazırlamanın faydalı olacağını düşünüyorum. Bu yazı dizisini bütünsel olarak mobil programlamaya başlamak için ihtiyacımız olan tüm materyal ve bilgileri kapsayacak şekilde detaylandırıp, basit bir mobil projesi ile sonlandırmayı hedefliyorum.
Konu başlıkları şu şekilde:
  1. Mobil Cihazların Gelişimi
  2. Windows CE tabanlı işletim sistemleri
  3. El bilgisayarlarının teknik özellikleri ve proje tasarımı sırasında dikkat edilmesi gerekenler
  4. Visual Studio’da Emülatör kullanımı
  5. PDA-PC haberleşmesi (ActiveSync)
  6. Basit bir mobil uygulaması
Başlangıç olarak şu anda aklıma gelen konular bunlar. Yeni konular eklenebilir veya sıraları değişebilir. Makale eklendikçe yukarıdaki listede linkler aktif olacaktır.
Mehmet BÜYÜKAŞIK