kapat

c ile etiketlenmiş kayıtlar

0:3 suları
google chrome kararlı sürümü 6.0.472.53 versiyonuna yükseltildi
yaklaşık 2 senedir severek kullandığım google chrome, 2 eylülde kararlı versiyonunun sürümünü 5.0.375.127 versiyonundan 6.0.472.53 versiyonuna çıkardı.

genel olarak bu versiyonda görsel arayüzde biraz renk değişiklikleri yapılmış, ayrıca az önce denerken doğru çalışmayan bir iframe'in de artık düzgün çalıştığını görüyorum.

tam olarak nelerin değiştiğini görmek için tıklayınız.

0 tane yorum var

9:43 suları
visual studio 2010 lab management indirilmeye hazır hale geldi
lab management, microsoft'un application lifecycle management konseptini hyper-v tabanlı sanal makine destekli test çözümleri eşsiz hale getiren ve uzun zamandır olgunlaşması beklenen bir üründü. sonunda visual studio 2010'a entegre olarak ürün hazır hale geldi ve indirilmeye hazır hale geldi.
lab management özelliğinin ayrı bir fiyatlandırma ile satılmayacağı daha önce açıklanmıştı; dolayısı ile şayet msdn subcriber üyeliğiniz varsa visual studio 2010 lab management 2010 deployment guide aracılığı ile bu özelliği edinebilirsiniz. şayet msdn subscriber değilseniz, trial versiyonlara aşağıdaki linklerden ulaşabilirsiniz.

lab management trial download

tamamen konfigure edilmiş windows server 2008 r2 hyper-v tabanlı sanal makine

ayrıca,

visual studio lab management's blog ve getting started guide ilginiz çekebilir.

0 tane yorum var

1:15 suları
yazılım metodolojileri - ı
application lifecycle management konusunda başladığımız yazı serisine yazılım metodolojileri - ı ile devam ediyoruz.
bu yazıda, waterfall ve spiral modelleri inceliyoruz.
yazı, maxiasp.net üzerinde daha iyi göründüğü için orada yayınladım.

0 tane yorum var

17:37 suları
professional application lifecycle management with visual studio 2010
bir süredir sabırsızlık ile beklediğim wrox'tan çıkan professional application lifecycle management with visual studio 2010 kitabı elime ulaştı.

0 tane yorum var

10:5 suları
alm summit
Eğer Application Lifecycle Management (ALM) ile ilgileniyorsanız, Kasım'ın 16'sı ve 18'i arası müsaitseniz, takriben 3000 TL - 4000 TL civarında bir bütçe ayırabilirseniz MaxiASP.Net'in size tavsiyesi ALM Summit.
16 - 18 Kasım tarihlerinde Microsoft Redmond kampüsünde (ABD) gerçekleşecek bu zirvede sunum yapacaklardan bazıları aşağıdaki isimler:
devamını oku >>

0 tane yorum var

9:56 suları
visual studio 2010 architecture tooling guidance
the visual studio alm rangers ekibi visual studio 2010 ultimate içindeki gelen architecture tool hakkında güzel bir kılavuz hazırlamışlar. application lifecycle management araçlarında önemli bir yere sahp architecture tool'un genel kullanım senaryoları ve uygulamalı çalışma yöntemleri (hands on labs) içeriyor. ayrıca tersine mühendislik (reverse engineering) işlemlerinin nasıl yapılacağını da bu kılavuz ile öğrenebilirsiniz.

0 tane yorum var

13:50 suları
team foundation server 2010 ve project server 2010 entegrasyonu
yazılım geliştirmenin aşamalarından bu yazıda bahsetmiştim; sürecin aslında ne kadar karışık olduğunun farkındasınızdır.
ne kadar sade planlansada birçok rol, görev, iş proje yöneticisinin planlamasını bekliyor olacaktır.

microsoft application lifecycle management konsepti içinde iki dev ürününün birbirine sıkıca bağladı, biri team foundation server 2010 diğeri de project server 2010.

örnekler ve anlatılanlar son derece güzel, zaten yakın zamanda çıkması bekleniyor.

buraya tıklayarak webcast'e ulaşabilirsiniz veya buraya tıklayarak örneklere ulaşabilirsiniz.

0 tane yorum var

22:39 suları
application lifecycle management (alm)
application lifecycle management  - alm

application lifecycle management (alm), adını son
zamanlarda sık sık duyduğumuz bir kavram. özellikle microsoft'un team foundation
server 2010 ve visual studio 2010 sürümlerini çıkarması ve visual studio 2010
lab management'ı duyurması ile neredeyse birçok sitede adı defelarca zikredilir
durumda. peki nedir bu alm?

alm kabaca bir yazılımın planlanmasını,
doğuşunu, büyümesini ve gelişmesini,
emekliliğini ve aramızdan ayrılmasını kontrol
altında tutmayı amaçlayan bir yaklaşımdır. yalnız burada alm'yi waterfall gibi
klasik ya da agile, scrum gibi popüler yazılım metodolojilerinin bir alternatifi
değil onların biraz daha üstünde bir kavram olarak düşünmek gerekir.

neden böyle bir yaklaşıma gerek var diye bakacak olursak,
yazılım (ne yazık ki) çok az önemsenen bir süreçtir; çünkü müşteri için de, çoğu
zaman bizim için de, basit gelir. sonuçta kodu yazmayı biliyorsak, herşeyi
yapabiliriz değil mi? maalesef değil, günümüzde birçok yazılım projesinin sonu
aşağıdaki gibi olmaktadır.

1. proje zamanında bitmedi, uzadı

2. proje bütçesinin üstüne çıktı

3. proje başarısız oldu, kabul testlerini geçemedi,
müşteri nihai ürünü istemedi.

gartner'a göre amerika birleşik devletleri'nde başlanan
projelerin %75'i başarısız olmaktadır. temel sebepleri ise yine yukarıda
saydığımız sebepler. [kaynak]

yazılım projeleri böyle bitiyor çünkü yazılım geliştirme
işi dışarıdan göründüğü kadar basit değil ya da sadece bir teknoloiyi ya da
programlama dilini kullanabiliyor olmak bu süreci başarılı bir şekilde yürütmeye
yetmiyor. açıkçası kod yazmak uygulama geliştirme sürecinin kolay kısımlarından
birisidir. zor olan, müşteriyi ve ihtiyaçlarını doğru anlamak, bu ihtiyaçlara
göre doğru sistemi oluşturmak, müşterinin isteklerini yönetmek, müşteri
ilişkilerini yönetmek, ekibi planlamak, test, analiz, tasarım gibi süreçlerin
doğru şekilde yapılmasını sağlamak, vb..

gördüğünüz üzere uygulama geliştirme kod yazmaktan çok
daha fazlası, bu yüzden de microsoft kod yazılan arabiriminin (visual studio
2010) daha çok amaca hizmet edebilmesini sağlayan bir yapıya dönüştürdü ve içine
gelişmiş bir test arabirimi ekledi, mimariyi yönetebilmek için imkanlar ekledi
ve bunları team foundation server 2010 ile birleştirip visual studio alm
konseptini duyurdu.

şimdi standart bir yazılım sürecinin hangi aşamalardan
oluştuğuna bakalım,



    1. ihtiyacın belirlenmesi

    2. proje ekibinin oluşturulması ve projenin
başlaması

    3. müşteri ihtiyaçlarının müşteriden
alınması ve analizinin çıkarılması (gereksinim analizi süreci)

    4. müşteri ihtiyaçlarının çözüm olacak
yazılım teknik çözümünün ve tasarımının oluşturulması

    5. toplanan gereksinimlerin sağlandığından
emin olmak için test ekibince test senaryolarının oluşturulması

    6. yazılımın yazılmaya başlanması

    7. müşteriden gelebilecek değişiklik isteklerinin yönetilmesi

    8. kabul testi

    9. uygulamanın canlı hayata alınması

    10. bakım ve destek sağlanması

    11. uygulamanın yayından/kullanımdan kaldırılması

saydığımız 11 aşama üç aşağı beş yukarı daha sonraki
yazılarımızda daha detaylı olarak bahsedeceğimiz tüm yazılım metodolojilerinde
bir şekilde yer almaktadır. dolayısı ile şimdi her aşamaya biraz daha detaylı
olarak bakalım.

1. ihtiyacın belirlenmesi:
insanoğlu neredeyse her zaman kendi ihtiyaçlarını giderebilmek için
çalışan bir organizmadır. sadece yazılım olarak düşünmeyelim, havayolu
endüstrisi insanların seyehat ile ilgili problemlerine çare olmak için gelişti,
ondan önce trenler daha büyük yükleri uzun misafirlerde taşımak için, konut
endüstrisi insanın barınma ihtiyaçlarına çözüm olmak için gelişti ve bugün yer,
konfor, güvenlik ve teknoloji gibi değişen ihtiyaçlarına da çözüm olabilmek için
bu kadar farklılaştı. bu liste bu ve bundan sonraki tüm makalaler boyunca
özetlenebilecek örneklerle uzatılabilir. yani temelde ortada bir ihtiyaç vardır
ve bizim amacımız bunu çözmektir. yazılım projeleri de hep bu amaçla yapılmaz
mı?

bazen bir hastanenin hastalarını ve stoklarını daha iyi
yönetebilmesi için, bazen de şirketin muhasebe kayıtlarını doğru şekilde
tutabilmesi için. dolayısı ile bir yazılım projesinin başlaması için ortada bir
ihtiyaç olması gerekmektedir. eğer projeniz başlıyorsa muhtemelen bir ihtiyacı
görmüş ve buna çözüm bulmaya çalışıyorsunuzdur.

2. proje ekibinin
oluşturulması ve projenin başlaması: başlanan bir projenin başarıya
ulaşmasında anahtar faktör doğru insanları bi araya getirmektir. örneğin iyi bir
film yapmak için senaryo, yönetmen, çekim ekibi ne kadar önemli ise oyuncu
kadrosu da aynı derecede önemlidir. ünlü ya da ünsüz farketmez başarısız
oyuncularla başlanan bir filmin başarılı olma ihtimali çok düşüktür. yazılım
projeleri için de aynı şey geçerlidir. hangi teknoloji veya ortamda yazılım
geliştiriliyor olursa olsun, doğru yetkinliğe sahip insanlar bi araya gelmezse
başarısızlık kaçınılmaz olacaktır.

proje ekibi genelde program yöneticisi (koordinatörü),
proje yöneticisi, iş analistleri, yazılımcılar, test ekibi, teknik analist,
mimar ve müşteri (paydaş) şeklinde vücuda gelir.

proje, bazen müşterinin size ulaşıp çözüm talep etmesi
bazen de sizin müşteriyi bulup belki henüz onun bile fark etmediği bir
ihtiyacını çözüme kavuşturma teklifinizi takiben müşterinin bu teklifi kabul
etmesi ile başlar.

3. müşteri ihtiyaçlarının
müşteriden alınması ve analizinin çıkarılması (gereksinim analizi süreci):
bir yazılım projesinin köşe taşlarından birisi analiz alınma
safhasıdır. ister müşteri ihtiyacını fark edip size ulaşmış olsun, ister siz
müşteriye ulaşmış olun müşteriden tam olarak ihtiyacını ve isteklerini almak
gerçekten başarı isteyen bir süreçtir. bu noktada müşteri ile etkin bir iletişim
şarttır. ayrıca bu sürec program yöneticisi ve proje yöneticisinin kontrolünde
alanında uzman iş analistleri tarafından yürütülür.

deneyimli bir iş analisti, müşteriden ihtiyaçları alırken
çoğu zaman müşterinin ilerde talep edebileceği şeyleri de kestirip bunları
analize dahil eder. bu da size birçok zaman kazandırır. ancak ne kadar deneyimli
olursa olsun hiç bir iş analisti müşteriden tek seferde mükemmel bir analiz
alamaz. çünkü müşteri hiç bir zaman tam olarak ne istediğini bilmez, çoğu zaman
müşteri uygulamanın ilk prototiplerini gördükçe aslında neye ihtiyacı olduğunu
anlamaya başlar ve burada değişiklik istekleri gelmeye başlar. bu nokta da ise
değişiklik yönetim sürecini başarılı şekilde yönetmek çok önemlidir. ayrıca daha
sonra yazılım metodolojilerinden bahsederken de vurgulayacağız ama; geliştirilen
birçok yazılım metodolojisi artık müşteriye erken safhalarda prototipler sunarak
değişiklik yönetim sürecini erken safhalarda işletmeyi hedefliyor.

4. müşteri ihtiyaçlarının
çözüm olacak yazılım teknik çözümünün ve tasarımının oluşturulması:
başlangıç analizi alındıktan ve gereksinimler belirlendikten sonra nihayatinde
ortaya çıkacak uygulamanın mimari tasarımı ve teknik çözümlemesi yapılır. bu
aşama yine konusunda uzman olan ekip üyeleri tarafından yapılır. kullanılacak
teknoloji belirlendikten sonra oluşturulacak sisteminin taslağı (blue print)
oluşturulur.

burada önemli olan bir önceki adımın ne kadar başarı bir
şekilde yönetildiğidir. eğer analiz aşaması layıkınca yerine getirilmezse,
yazılım geliştirme safhasında öngörülemeyecek birçok değişiklik isteği gelebilir
ve bunlarda bazen sistemin başta kurulan yapısına tamemen ters düşebilir. bu
durum ise projenin kararsız haline gelmesine yol açabilir ya da ön görülmemiş ve
planlanmamış bir çok eforun harcanmasına sebep olabilir.

5. toplanan gereksinimlerin
sağlandığından emin olmak için test ekibince test senaryolarının oluşturulması:
test gerçeklenmek istenen projenin, müşterinin ihtiyaçlarını tam olarak
kapsayıp kapsamadığının kontrolü, üretilen çözümün kalitesinin sağlanması ve
canlı hayatta istenmeyen birçok durumun önüne geçilebilmesini sağlayan hayati
önemdeki bir süreçtir. birçok proje de test süreci tamamen yanlış
işletilmektedir. örneğin test ya hiç yapılmaz ya da tamamen yazılımın sonunda
yapılır; bazen de bu işin uzmanı olan ekip elemanları ile test süreci yürütülmek
yerine yazılım geliştiren ekip üyeleri ile bu süreç yürütülmeye çalışılır. bu
yanlış uygulamalar da yine projenin başarısız olmasına sebep olabilmektedir.

test yazılım geliştirmenin ayrılmaz bir parçası olup,
test ile paralelde yürümesi gereken bir süreçtir. daha en başta yazılım
başlamadan önce, analiz alındıktan sonra alınan analizin uygulama ile karşılanıp
karşılanmadığını ölçmek için analizlere göre test senaryoları oluşturulmalıdır.
yine burada da görülebileceği gibi analizin doğru alınmaması test sürecinin
verimini düşürüp, olumsuz sonuçlara sebep olabilmektedir.

6. yazılımın yazılmaya
başlanması: ne kadar kod yazmak, sürecin kolay kısımlarından biri
desekte tabi ki aslında herşeyidir de. sonuçta amaçlanan iş yazılım
geliştirmektir, dolayısı ile bu sürecin de gerekli önem verilerek, gerekli
yeterlilikteki uzmanlar ile gerçekleştirilmesi gerekir. birçok yazılım
metodolojisinde yazılım geliştirme işi farklı düzenlerde yapılmaktadır ki
bunlara daha sonra ki yazılarımızda değineceğiz.

yazılım geliştirme sürecinde önem verilmesi gereken bir
konu kod gözden geçirmesidir; çünkü yazılım belli bir mimari yapıya ve kurallara
uygun olarak yapılmaktadır. özellikle yazılım ekibine yeni katılan üyeler olmak
üzere yazılımcıların bu kurallara ve mimariye mümkün olduğunca sadık kalması
zorlanması gerekir. bu amaçla yazılan kodlar daha deneyimli yazılımcılar
tarafından gözden geçirilerek kod kaynağına atılmalıdır ki mimariye ve kurallara
uyuma gerekli önem verilsin. şayet bu süreç de gereğince yerine getirilmezse
mimariye ve kurallara uymayan yazılımcılarda bu alışkanlık haline gelecektir.

7. müşteriden gelebilecek
değişiklik isteklerinin yönetilmesi: üçüncü adımdaki müşteri
ihtiyaçlarının toplanması süreci ne kadar başarılı şekilde yürütülmüş olursa
olsun, daha önce de bahsettiğim gibi müşteriler tam olarak ihtiyaçlarının ne
olduğunu bilemezler. gereksinim analiz sürecinde harcanan onlarca saate ve
yapılan onlarca toplantıya rağmen müşteri sonuçta ortaya çıkacak resmi
göremedikçe kendilerinin bile fark etmediği ihtiyaçlarını size aktaramayacaktır.
bu ihtiyaçlarda yazılım sürecinin ilerleyen safhalarında size değişiklik isteği
olarak dönecektir.

yazılım projelerinde bu değişiklik isteklerini doğru
şekilde yönetmek hayati ise öneme sahiptir. ilerleyen yazılarımızda bu
isteklerin en sorunsuz şekilde yönetilmesi için izlenmesi gereken yöntemlerden
de bahsedeceğiz.

8. kabul testi:
yazılım sürecinin sonunda ortaya çıkan uygulamanın canlı hayata alınması için
öncelikle müşterinin katılımı ile gerçekleştirilen bir teste tabi tutulması
gerekir. bu testte ortaya çıkan nihai ürünün müşteri ihtiyaçlarını ne kadar
karşıladığı ve kabul edilebilir olup olmadığı test edilir.

kabul testlerinin uygulanması da çoğu zaman önemsenmeyen
bir durumdur ya da yanlış şekilde uygulanması da sık sık karşılaşılan bir
durumdur.

9. uygulamanın canlı hayata
alınması: yazılımı tamamlanan ve kabul testlerinden geçen projelerin
canlı hayata alınması sürecine geçilir. bu süreç normalde bu konu için özelleşen
ekipler tarafından yürütülmesi en idalidir. ancak yine çoğu zaman görülüyor ki
bu işte proje ekibine kalmaktadır.

uygulamanın canlı hayata nasıl alınacağı gereksinim
analizi sürecinden sonra belirlenmesi gerekir. çünkü bazen projenin sonuna
gelindiğinde uygulamanın canlı hayata alınma şekli tamamen projenin yapısına
ters düşmekte ve yine planlanmayan eforların harcanmasına sebep olmaktadır.

10. bakım ve destek
sağlanması: uygulama canlıya alındıktan sonra, garanti süresine
benzeyen bir süreç yürütülür. uygulama da kodlamadan veya yazılımdan kaynaklanan
oluşabilecek kesintilere destek verilir ve anlaşmalara bağlı olmak üzere yazılım
üzerindeki güncelleştirmeler ile bakım yapılır.

bu süreç de profesyonelce yürütülmesi gereken bir
süreçtir, çünkü bu süreci yürütmekteki başarınız size aynı müşteriden yeni
işlerin gelmesini sağlayıp müşteri memnuniyetini arttırabileceği gibi; sürecin
başarısız bir şekilde yürütülmesi halinde ise hukuki anlaşmazlıklara varan
sorunların ortaya çıkması mümkündür.

11. uygulamanın
yayından/kullanımdan kaldırılması: her şeyin bir sonu olduğu gibi, onca
emek ile oluşturulan projenin de elbet bir sonu olacaktır. bu son sadece
uygulamayı silmek kadar basit değildir, uygulamayı yayından kaldırmakta başlı
başlı başına üzerinde durulması gereken bir eylemdir.

bu süreç müşteri ve program yöneticisi tarafından alınan
karar ile başlar ve iki tarafın gözetiminde uygulama yayından kaldırılır.

bu yazımızı alm'nin tarifi ve standart bir yazlım
sürecinin aşamalarını anlatarak noktalıyoruz. bundan sonraki makalelerimizde
yazılım metodolojilerini, visual studio 2010 ile alm gibi konulara bakacağız.

 

0 tane yorum var

14:0 suları
yanlışlıkla giden bir maili geri alma
özellikle şirketlerde çok yaşanan bir durumdur aslında, tüm şirketin alıcı olduğu bir mail gelmiştir ve gönderene cevap vermek için yanlışlıkla "reply all/tümüne yanıtla" der ve gönderirsiniz. ne yaptığınızı anlamanız sadece 3-5 saniye sürer, hemen iş arkadaşlarınız kafalarını kaldırır ve size bakmaya başlar. şanslıysanız maili çok insan okumadan recall ile tekrar çağırırsınız (exchange üzerinde); ancak tabi ki o sırada outlook'ları açık olan veya cep telefonundan "push mail" ile maillerini alan özellikle yöneticiler çoktan mailinizi okumuştur. hepsi bir tarafa "recall" komutu verdiğiniz zaman exchange tek tek tüm kullanıcılar için bu işlemi yapıp yapamadığına dair bir rapor döndürür ki, bu cidden çok daha sıkıcı olabiliyor.

0 tane yorum var

17:33 suları
visual studio 2010 lab management'ın relase'i yayınlanmış
microsoft visual studio alm'nin önemli bir parçası olan visual studio 2010 için lab management ile ilgili daha önce duyurduğu güncellemeyi yayınlanmış durumda.

aslında ben daha büyük bir paket bekliyordum ama sadece 17 mb'lık bir paket ile halledilmiş gibi görünüyor, henüz kurmadığım için de kesin konuşmak istemiyorum ama bi yarım saat sonra daha net konuşabileceğim gibi geliyor.

update'i hemen buraya tıklayarak indirebilirsiniz

0 tane yorum var

ffwinmobile
secim2007
pixelMaxi
db2class
filmhatalari
Tarihci