Yazılım Yaşam Döngüsü Modellemeleri

“Bu okyanuslardaki bir maceradır.”

Yazılım Nedir?

Ana başlığımız bu olmasa da böyle bir giriş yapmayı doğru buluyorum çünkü “yaşam döngüsüne” sahip olan bir şeyi tanımlamak, onun yaşam döngüsünü kavramadan önceki atılabilecek en mantıklı adım gibi görünüyor benim gözümde. Yazılım, bilgisayarları çalıştırmak belirli görevleri yerine getirmek için kullanılan veriler, programlar ve komutlar bütünüdür. Genel kullanıcının donanımdan bağımsız bir şekilde daha çok ilişkili olduğu bu kısım, şu anda birçok kola ve türe ayrılmış adeta uçsuz bucaksız bir okyanusa dönüşmüş vaziyette. Bir nevi yaşayan bir form gibi gelişimini ve büyümesini sürdürmekte, bizi yeniliklerle karşılamaya devam etmektedir.

Yazılımcılar olarak bizler ise sonu gelmez bu gelişimde ilerlemek için kontrollü elimize almaya ihtiyaç duyuyoruz, yoksa kendimizi suya düşmüş yüzmeyi bilmeyen birisi gibi manasız bir çırpınma içerisinde buluruz. Sebebi budur ki yazılımcılar, suları kontrol edebileceğimiz, güvenli ve etkili çözümler aramışlardır. Bunun nihayetinde ise “yazılım yaşam döngüsü” gibi bir kavram ortaya çıkmış, bir yazılım geliştirme süreci standartlara bağlanmıştır. Böylece bu uçsuz bucaksız okyanuslardaki kaptanlar, artık bir harita ve pusula gibi bu standartları dayanak yapabileceklerdir.

Yazılım Geliştirme

Yazılımcılar için her yeni yazılım geliştirme süreci uçsuz bucaksız bir okyanusta yeni bir sefer gibidir. Gideceğiniz noktayı iyi seçmeli, nasıl gideceğinizi bilmeli, geminizin kontrolünü ele almalı ve haritanızı doğru okumalısınız, pusulanızı da unutmayın tabi! Yazılım geliştirme sürecinde dikkat edilmesi gereken bu kadar çok şey varken dilerseniz gelin alt başlıklar halinde hepsine hızlı bir bakış atalım:

Planlama: Bu seferki rota nereye acaba? Kesin olarak kararlaştırdınız mı? Ya da hangi yoldan gideceğinizi, yanınıza neler alacağınızı kesinleştirdiniz mi? Hayır mı? O zaman orada bir durun! Yazılım geliştirmenin ilk aşaması olan planlama, her şeyin başlayacağı yerdir. Güçlü bir planınız olmadan yola çıkarsanız sonucunda hüsranla karşılaşabilirsiniz. Planlama aşamasında temel ihtiyaçlarınızı belirlemeli, maliyetlerinizi kabataslak bir biçimde hesaplamalı, risklerinizi gözetmeli ve yol haritanızı çizmeye başlamalısınız. Unutmayın ki bir binanın temelini sağlam yapmazsanız, ilerisi için pek de umut vaat edebilecek bir yapı elde edemezsiniz.

Analiz: Planlama aşamasının devamı olarak nitelendirebileceğimiz bu kısımda, yapmanız gereken temel şey planlama aşamasındaki kararlarınızı daha derinden incelemek ve daha da önemlisi doküman haline getirmektir. Sonuçta söz uçar, yazı kalır demişler! Bu aşamada yol haritanızı kesinleştirin, daha net maliyet hesaplamalarına girişin, gereklilikleri ve ihtiyaçlarınızı tam manasıyla belirtmeye çalışın. Ayrıca bu aşamada mürettebatınızla da yardımlaşmanız büyük ölçüde faydanıza olacaktır. Müşterilerinizle, analistlerle, ürün yöneticileriyle vb. diğer proje ortaklarınızla bu konularda iş birliği yapın. Unutmayın ki bu okyanuslarda tek başına ilerlemek tahmin edemeyeceğiniz kadar zor olabilir. Siz en iyisi mürettebatınız ile iletişiminizi iyi tutun ve olabildiğince net, doğru kararları almaya çalışın.

Tasarım: Bu aşama, yazılımın hayata geçirilmesine giderek yaklaşıldığı aşamadır. Gereksinimleri belirlenmiş ve neyin yapılacağı kararlaştırılmış olan yazılım, bu aşamada nasıl yapılacağı konusuna gelir. Neyin nasıl yapılacağı burada belirlenir. “Gereksinimlerin karşılanması” hedefi esas alınarak yazılımın özellikleri, arayüzlerin tasarımı, yazılımın yetenekleri-becerileri gibi konular kararlaştırılır. Bahsi geçen aşama için dikkat edilmesi gereken temel nokta ise öncelik sıralamasıdır. Önceliklerinize göre bir tasarım yapıp, hedef odaklı bir ilerleme işlerinizi kolaylaştıracaktır.

Gerçekleştirme: Bu aşama işlerin daha da ciddileştiği, kaptan olarak kollarınızı tam manasıyla sıvamanız gerektiği aşamadır. Artık gereksinimleriniz belli olmuş, analizleriniz tamamlanmış, tasarımınız ve yol haritanız kesinleşmiş, geminiz yola çıkmaya hazır hale getirilmiştir. Bu aşama boyunca artık kodlamaya geçerek asıl işleri yapmaya başlayacaksınızdır. Ama merak etmeyin ki güçlü bir arka plan üzerine inşa ettiğiniz bu maceranız, er ya da geç başarıyla sonuçlanacaktır. Bu aşamada asıl dikkat etmeniz gereken nokta, amacınızın ne olduğudur. Hedefinize biran önce ulaşmak istemenize rağmen sonrasında da zorluk yaşamamanız gerekmektedir. Bunun için kodlamanın iyi bir şekilde yapılması gereklidir. İyi kod kısaca: “Okunması ve bakım yapılması kolay olan kod” olarak nitelendirilebilir. En kısa yol olmamasına rağmen ileriye dönük en verimli yoldur. Yolculuğunuz boyunca yaşayacağınız aksiliklere ve geri dönüşlere en müsait yöntem budur. Elbette yazılım dünyasında, yazılım yaşam döngülerinde olduğu gibi iyi kodlama için de standartlar vardır. Değişken isimlendirmelerinden tutun, metot yöntemlerine kadar birçok şeyin uygun ve en güvenilir yollarının standartlandırılmış halleri, biz kaptanların sıkıntısız bir macera yaşamalarına yardımcı olur.

Ayrıca gerçekleştirme aşamasının bir sonraki faslı test kısmıdır. Kodunuzu yazdıktan sonra onu test etme, güvenilirliğini sağlama, başarısını kesinleştirme yazılım geliştirmenin önemli noktalarındandır. Test etme işlemi ister doğrudan sizin tarafınızdan ya da ister mürettebatınızın uygun bir üyesinden beklenebilir. Test kısmı ayrıca sadece gerçekleştirme aşaması için değil tüm aşamalar için bir erken kontrol mekanizması olarak görülebilir. Sürekli olarak takip edilen bir test sistemi, istenmeyen sonuçların önüne geçecektir.

Teslim Ve Bakım: Tüm test aşamalarından alnın akıyla çıkmış bir yazılım projesi, teslim aşamasına gelmeyi hak etmiş demektir. Bu aşamada müşteriye uzun uğraşlar sonucu ortaya konmuş benzersiz yazılım projesi teslim edilir. Ancak bir kaptanın tüm sorumlulukları görevini başarıyla bitirip müşteriye ürünü teslim etmesiyle sona ermez. Daha sonrasında önemli bir kısım olan bakım süreci gelecektir. Tekrarlı ve sürekli bir aşama olan bakım aşaması, ilk bakışta işi uzatıyormuş gibi gözükse de iki taraf için de iyidir. Müşteri ürününü sürekli güncel tutup yardım alırken, yazılımcı ise bakımını yaptığı işler için kazanç elde edecektir. Bu sebepten bakım süreci önemli bir rol tutar ve “görevi yaptım bitti” anlayışı yerine daha tutarlı bir anlayışla iş yapılmasını sağlar.

Yazılım Yaşam Döngüsü Ve Tanımlamaları Hakkında

Yazılımları yaşayan bir form gibi kendini sürekli yenileyen, gelgitleri olan bir okyanusa benzetmiştik. Bizler ise gemilerimizdeki kaptanlar olarak bu okyanusta ilerlememizi güvence altına almak istemiştik. Bu durumlar sonucunda ise karşımıza bahsi geçen kavram çıkıyor, “yazılım yaşam döngüsü”.

Daha öncede dediğim gibi bu bir standarda bağlama biçimi. Ancak tek bir yolu yok, bu tanım başlığı altında birçok şekli ve türü var. Yazılım okyanusunda yeni yerler keşfedildikçe, yazılım yaşam döngülerine de yeni yöntemler eklenmeye, yeni haritalar oluşturulmaya devam ediliyor. Dilerseniz şimdi de bu yöntemlerin bazılarına göz atalım:

· Kodla Ve Düzelt:

Bu işlerde acemi iseniz ve şimdilik profesyonel bir sonuç gözetmiyorsanız, bu yöntem tam size göre. Doküman kısmını atlayıp hedef odaklı düz bir kodlama sürecini içeren bu yöntem. Hedefinize ulaşana kadar geri dönüşler olmaksızın ilerlemenize dayanıyor. Planlama gibi bir ön hazırlık istemeyen bu model genel de küçük çaplı projelerde kullanılıyor.

Kimler Kullanıyor? : Genelde küçük çaplı projeler üzerinde çalışan kişiler, tek seferlik projeleri yürüten bireyler ve ufak projeler üzerinde çalışan öğrenciler bu yöntemi tercih edebiliyorlar.

Hangi Durumlarda Kullanılmalı? : Geri dönmenize gerek kalmayacak tek seferlik bir projeniz varsa, sadece göstermelik bir prototipe ihtiyaç duyuyorsanız, yapmanız gereken tek şey dokümana ihtiyaç duymayan çalışan bir proje sunmaksa bu yöntem size hitap ediyor demektir.

Aklında Bulundurman Gerekenler: Dediğimiz gibi planlı bir proje yönetim biçimi değil ve doküman tutma gibi bir eğilim de bulunmuyor bu yöntem içerisinde, bu sebeplerden profesyonel sonuçlar elde edemeyeceğini aklında bulundurman gerekiyor. Ayrıca daha sonradan güncelleme gereken işler için de bu yöntem korkulu bir rüya olabilir.

“Bu henüz ilk seferiniz ise ya da sadece ufak bir macera arayışında iseniz, bu yöntem tam sizin için!”

· Şelale Modeli:

Bu yöntem daha profesyonel sonuçlar çıkarabileceğiniz, birikimli bir şekilde ilerleyen bir modeldir. Şelale modelinde temel prensip, bir önceki aşamadan kazanılan çalışmaların yeni aşamada harmanlanmasıyla ileriye doğru iletilmesidir. Bu yöntemde bir aşama tamamlanmadan diğerine geçilmez ve sürekli geri dönüşler gözlenmez.

Kimler Kullanıyor? : Organizasyonu büyük olmayan ekipler, çok da uzun vadeli bir sürece sahip olmayan projelerde çalışanlar ve projelerinde sürekli değişime ihtiyaç duymayacak ama yine de belgelemeye önem verip net sonuçlar elde etmek isteyen kişiler tarafından bu yöntem tercih edilebiliyor.

Hangi Durumda Kullanılmalı? : Düzenli ve iş bölümü kolay olduğundan küçük organizasyonlar için tercih edilebilirdir. Doğrudan müşteri hedefinde olmayan projeler için uygundur. Sürekli bir değişimin beklenmeyeceği, kalıplar ve standartlar üzerine kurulmuş projelere hitap eder.

Aklında Bulundurman Gerekenler: Bu yöntem belgelemeyi de içine alan geri dönüşlerin az olduğu düzenli bir yöntemdir. Daha sonra değişime ihtiyaç duymayacak projelerde iş bölümünün ve organizasyonun kolaylığı sebebiyle tercih edilebilir. Ancak bu yöntemde değişimler zahmetli sonuçlar ortaya koyabileceğinden, güncelleme ve değişime açık olması gereken projelerde tavsiye edilmez.

“Rüzgardan aldığınız hızla geriye dönüşlerinizin az olacağı eli çabuk ancak yine de düzenli bir çalışma prensibi arıyorsanız, bu yöntem tam size göre!”

· V Modeli

Bu yönteme çoğu yerde karşılaşacağınız gibi “Şelale Modelinin geliştirilmiş versiyonu” denmekte. Bunun sebebi birikimli bir yapıda ilerlemesi, kontrolünün kolay olması gibi yönlerinden Şelale Modeline benzemesidir. V Modeli, birçok yazılım yaşam döngüsü modeline zıt olarak başlangıç ve bitiş noktaları arasındaki ilerleyiş diyagramı standart bir çizgiyle gösterilemez. Bunun yerine isminden anlaşılacağı gibi ilerleyiş diyagramı V şeklindedir. Bu modelin en belirgin özelliği, gereksinimlere ve ürün tanımlamasına net olarak ihtiyacı olması ve test süreçlerinin ön plana çıkmasıdır.

Kimler Kullanıyor? : Şelale Modeliyle arasındaki benzerlikler burada da görünüyor ki yine benzer kişilere hitap eden modeller olmuşlardır. Organizasyonu kolaylaştırmak isteyen bireyler ve projelerinin gereksinimleri net olan kişiler bu yöntemi tercih edebilmektedirler.

Hangi Durumda Kullanılmalı? : Üzerinde çalışacağınız proje için geri dönüşler yok denilebilecek kadar az, risk faktörü göz ardı edilebilir ve test aşamaları önemliyse bu yöntem rahatlıkla tercih edilebilir. Ayrıca takibi ve organizasyonu net kalıpları sayesinde kolay olduğundan ilerleme hedeflerinin göz önünde bulundurulmak istenildiği durumlarda da kullanılabilir.

Aklında Bulundurman Gerekenler: Bu yöntemde unutmamanız gereken en önemli şey geri dönüşlerin ve risk analizlerinin bulunmadığıdır. Bu yöntem size kolay bir ilerleme izlenimi ve belirgin test aşamaları sunar.

“Hedefinize doğru ilerlerken, bulunduğunuz noktayı iyi saptamak; arkanıza bile bakmadan ilerlemek istiyorsanız, bu yöntem tam size göre!”

· Evrimsel Geliştirme Modeli

Bu yöntem özellikle gereksinimlerin netleştirilemediği durumlarda kullanılır. Temel bir tanımlama ardından “ilk evrim” olarak projenin başlangıç sürümü ortaya konur. Bu ilk sürümün başarı oranı diğer ürünlerinde başarısını dolaylı yoldan etkiler çünkü bundan sonraki “evrim” geliştirmeleri bu ilk sürüm üzerinden devam eder. Ayrıca bu metot kapsamlı projelerde alt projelerin yapılıp en sonunda birleştirilmesi amacıyla da kullanılır.

Kimler Kullanıyor? : Bu modelin iki temel kullanım alanı vardır. Birisi gereksinimlerin saptanması, diğeri ise alt projeler bütününden oluşan kapsamlı bir projenin ortaya konmasıdır. Coğrafi anlamda birbirinden bağımsız ekiplerin alt projeler üzerinde ayrı ayrı çalıştığı organizasyonlar bu yöntemi tercih etmektedirler. Yine benzer şekilde, projenin veya müşterinin gereksinimlerinden emin olunamadığı düşünülen proje ekiplerince de tercih edilebilmektedir.

Hangi Durumda Kullanılmalı? : Projenizin büyüklüğü onu alt projeler şeklinde ayırmanıza sebep oluyorsa veya proje gereksinimlerini tam olarak saptayamıyorsanız ve bunların yanında da ürünün oluşumu için aceleniz yok, ürün sonucunda da bakım beklentiniz bulunmuyorsa bu yöntemi tercih edebilirsiniz.

Aklında Bulundurman Gerekenler: Bu yöntemde en önemli kısım ürün oluşum sürecinin uzunluğu ve bakımın zorluğudur. Bu yöntem hata ve riski sürekli “evrim” süreçleriyle minimuma indirgese de yönetim ve süre konusunda bazı dezavantajlar teşkil edebilmektedir.

“Bir maceraya çıktıysanız ancak hedefinizi tam olarak kestiremiyorsanız ya da tek bir geminin değil de birden çok gemiden oluşmuş bir filonun kaptanıysanız, bu yöntem tam size göre!”

· Prototipleme

Bu yöntemin ön plana çıkan özelliği, hızlı bir şekilde kısmi bir ürünün ortaya çıkarılmasıdır. Prototipleme modelinde en önemli husus, başlangıç kısmı olan gereksinimlerin net bir şekilde belirlenmesidir.

Kimler Kullanıyor? : Hızlı bir ürüne ihtiyacı olan proje sahipleri, belgelemeyi göz ardı edebilecek ve gereksinimlerini net belirlemiş proje ekipleri bu yöntemi kullanabilmektedirler.

Hangi Durumda Kullanılmalı? : Hızlı bir şekilde kısmi ürünler elde etmek istiyor, bu kısmi ürünlerle hedefinizi daha da netleştirmeyi planlıyorsanız bu yöntemi tercih edebilirsiniz. Gereksinimleriniz net ve raporlamanın önemli olmadığı durumlarda kullanılabilir.

Aklında Bulundurman Gerekenler: Bu yöntemin ana amacı hızlı bir şekilde kısmi ürünler elde etmektir. Bu ürünler kimi zaman sunumlar için de kullanılabileceği gibi, özellikle hedeflerin daha da netleştirilmesinde önemli rol oynar. Bu modelde dikkat etmeniz gereken en önemli husus gereksinimlerinizi doğru ve net bir şekilde belirlemeniz gerektiğidir.

“Benim acelem var diyorsanız ve gereksinimlerimi zaten biliyorum bana ürün gerekli diyorsanız, bu yöntem tam size göre!”

· Spiral Model

Bu yöntemin ön plana çıkan özelliği, risk analizi ve aynı fazların birden çok tekrarlanmasıdır. Spiral Modeli genelde küçük çaplı projeler için önerilmez. Belgeleme işleminin ve risk analizlerinin yoğun olduğu bu model, genelde risk gözetiminin yüksek olduğu kapsamlı projelerde uygulanır.

Kimler Kullanıyor? : Geniş çaplı, raporlamanın ön planda olduğu proje ekiplerince kullanılmaktadır. Güvenlik yazılımları gibi risk faktörünün minimumda tutulmasının önemli olduğu projelerde bu yöntem ön plana çıkar.

Hangi Durumda Kullanılmalı? : Raporlamanın ve risk analizinin ön planda olması beklenen kapsamlı projelerde bu yöntem uygulanabilmektedir. Sürekli tekrarları ve uzun süren yapısı sebebiyle küçük proje ekiplerinin altından kalkamayacağı maliyetlere sebebiyet verebilir.

Aklında Bulundurman Gerekenler: Bu yöntemin ön plana çıkan özelliğinin tekrar eden süreçleri olduğunu unutmamak gereklidir. Uzun süren bir sürece sahip olan bu model, yapısı gereği maliyetleri arttırabilmektedir. Bu sebeplerdendir ki küçük ekipler için tavsiye edilmez.

“Bu macerada benim vaktimde bol, kaynaklarım da; yeter ki her şey en iyi şekilde ayrıntısıyla yapalım diyorsanız, bu yöntem tam size göre!”

· Birleşik Süreç

Bu yöntem çoğu yerde, “nesneye yönelik yazılım geliştirmek için var olan yöntemlerin en iyi yanlarının bir araya gelmiş hali” olarak nitelendirilmektedir. Yinelemeli, arttırmalı ve evrimsel aynı zamanda da risk güdümlü bir yöntemdir. Gereksinim ve hedeflerin belirlendiği aşama olan “başlangıç” aşaması, “ayrıntılandırma” başlığı altında gerçekçi çözümlerin ele alınması ve risk gibi faktörlerin hesaplanmasını kapsayan aşama, ürünün geliştirilmesi sürecini ele alan “tamamlama” aşaması ve son olarak da testlerin ardından ürünün sunulmasını içinde barındıran “yayım” aşaması bu yöntemin 4 temel yapı taşıdır.

Kimler Kullanıyor? : Büyük sistemler ve deneyimsiz bir sektöre girileceği zaman geniş çaplı ekipler tarafından bu yöntem kullanılabilmektedir.

Hangi Durumda Kullanılmalı? : Dokümasyonun önemli bir faktör olduğu bu yöntem, büyük çaplı ve değişime açık projelerde kullanılabilir.

Aklında Bulundurman Gerekenler: Küçük çaplı projeler için önerilmez, doküman yükünün ağırlığı ekiplere sıkıntı çıkarabilir. Bu yöntemin en öne çıkan özelliği uzun sürecine rağmen erken tepki verebilen yapısıdır. Sürekli küçük ürüncüklerle ilerler, geri beslemeleri toplar ve ilerlemesi boyunca deneyim kazanımını sürdürür.

“Güçlü bir mürettebatım, yeterli kaynağım var diyor ve uzun bir yolculuğa çıkmayı planlıyorsanız; bu yolda moraliniz yüksek, raporlarınız tam olsun istiyorsanız, bu yöntem tam size göre!”

· Çevik Modeller

Çevik Model kavramı yazılım dünyasında birikmiş deneyimler sonucu ortaya çıkmıştır, günümüzde popülerliği güçlü bir konumdadır. Daha iyi bir yazılım geliştirme süreci hedefleyen Çevik Modellerin temel prensipleri şunlardır:

- Yazılımın müşterilerle ve diğer taraflarla erken ve hızlı paylaşılması

- Değişime açık olunması

- İş paylaşımı ve ortak çalışma

- Ekip içerisinde güven

- Belli zaman aralıklarıyla bir araya gelişler

- Takım çalışması

- Etkili iletişim

- Dokümanlardan çok, başarılı çalışır çıktıların ön plana alınması

- Sürdürülebilirlik

- Esneklik

- İyi tasarım ve teknik mükemmellik

- Basitlik, gereksiz işlerden kaçınılması

Çevik Modeller başlığı altında da aynı yazılım yaşam döngülerinde olduğu gibi farklı yöntemler bulunuyor. Bunların en yaygınları ise XP ve Scrum modelleri olarak görülüyor:

§ XP — Extreme Programming

Bu model kendinden önceki tüm “doğru” yazılım geliştirme metotlarının “ekstrem” şekilde uygulanması prensibine dayanır. Bir projenin geriye dönülebilir olması iyidir, o halde her an geriye dönüşlerin sağlanması gereklidir. Müşteri ile iletişimin iyi olması önemlidir, o halde müşteri de ekibin bir parçası olarak bu iletişimi sürekli kılmalıdır. Uygulamanın test edilebilir olması iyidir, o halde proje her an test edilebilir olmalıdır. XP metodu, verilen örneklerdeki olduğu gibi iyi olanın en iyi halini kullanmayı hedefleyerek ortaya çıkmış bir metot olarak görülebilir.

§ Scrum

Bu metot, karmaşık projeleri yönetmek için ortaya konmuş basit çözümler sunan bir yönetimsel modeldir. Gereksinimlerin net olmadığı, karmaşık projeler için biçilmiş kaftan olarak görülür. Bunun sebebi zaten karmaşık olan durumu daha da karmaşık hale getirip kalıplara sığdırmaya çalışmak yerine esnek bir şekilde basit çözümler sunmasıdır. Bu modelin öne çıkan bir başka yönü ise şeffaf bir işleyiş sunarak varsa aksaklıkların tespit edilmesini kolaylaştırmasıdır. Scrum modelinin yaklaşımı diğer tüm çevik modellerde olduğu gibi motivasyonun yüksek tutulmasına dayalıdır.

Kimler Kullanıyor? : Büyük sistemlerden, küçük organizasyonlara kadar takım çalışmasına yatkın birçok projede çevik modeller kullanılmaktadır.

Hangi Durumda Kullanılmalı? : Takım çalışmasının — etkili iletişimin ön planda olmasının beklendiği ve etkili sonuçların istendiği çoğu projeler için uygun bir yöntemdir.

Aklında Bulundurman Gerekenler: Kapsamlı ama basit çözüm odaklı olan bu tip modeller etkili iletişimi zorunlu kılmaktadır. Bu sebepten ekibinizin iletişimini ve bağlarını iyi tutmanız gerekmektedir. Resmi kurumlarda uygulaması zor bir metot olabilir.

“Mürettebatınıza güveniyorsanız ve motivasyonu yüksek bir macera arayışında iseniz, bu yöntemler tam size göre!”

Kapanış

Bu yazı boyunca dilerim ki siz kaptanlar kendinize yakın bir model bulabilmişsinizdir. Ve yine dilerim ki macera dolu bu okyanuslarda rüzgarınız bol, pusulanız doğru olur. Şimdiden yapacağınız projelerde başarılar dilerim. Hepinize kolay gelsin!