[uzay95]

Konu bir programı BERABER yazmanın püfleri.

Bir yazılımı analiz ederken kullandığımız araçlar nelerdir?

UML bu işin neresinde nasıl kullanılır?

Ortak çalışma araçları (CVS-Bugzilla ya da Subversion-Mantis ikililerinin haricinde) class, kullanım, nesne diyagramlarını nasıl ortak göreceğimiz ve neresinde, % kaç bittiğini takip edebileceğimiz bir yazılım var mıdır?

Analizde neler sorarız? Örnek bir konu ve üzerine çizilmiş diyagramlar var mıdır?

Bizim bence eksigimiz beraber çalışma yöntemlerini bilmiyor oluşumuz ve sadece bireysel olarak bile bir ton eksigimiz varken küçük dağları ben yarattım edasından kurtulamayışımız.

Hadi gelin çalıştığımız şirketlerde neler kullanırız? Profesyonel çalışma tekniklerinden hangilerini kullanıyoruz? Bu tekniklerin ne kadarı hangi ortamlarda faydalı? sorularının cevaplarını konuşalım.

Soru çok belki üzerine sayfalarca sizlerin soruları ile bu konu daha faydalı olur.

Sevgi Saygı Birlik Beraberlik hep sizlerle olsun.

[ajemix]

Bir ogrenci olarak,

yazilim icin vazgecilmez unsur her zaman analizdir. Analiz olmadan yazilan kod surekli geri donecektir. Musteri ile iyi iletisim kurabilmenin özü UML de bitiyor.

Yazılıma başlarken önce müşteriden istenilen yazılım hakkında detaylı bilgi alınır. Bu yazılı olursa hem ileride oluşacak problemlerin önüne geçilir(müşterinin ben bunu istememiştim demesi gibi) hem de sürekli el altında olduğundan modellerde her zaman kolaylık sağlar.

Bu anlatım sayesinde önce Use-Case(kullanım senaryoları belirlenir. Daha sonra workflow çizilir.
Asıl can alıcı nokta ise use case diyagramda bitiyor. Burada hangi kullanıcının hangi olaydan sorumlu olduğu belirlenir ve ona göre diagramlar arasındaki bağlantılar belirtilir.

Eğer elinizde yazılı bir anlatım var ise domain model çizimi basit olur. O yazı kelime analizi yapılarak sistemin sorumlu olacağı objeler belirlenir ve aralarındaki bağlantılar kurulur. Bu bağlantılar veritabanı kısmındada çok işe yarar. Sıra Object Diaygram bölümüne gelir burada sistem daha detaylı ele alınır ve burdan sonrası müşteriyi ilgilendirmez ve gösterilmez. Burdan sonrası daha çok programcı ve yazılım mühendisi arasında geçer. Object diyagramın Use case de varolan senaryolar burada canlandırır. Oluşturulan sınıflar(class) arasındaki bağlantılar burada belirlenir ve operasyonlar tanımlanır. Object diyagram sayesinde Implementation class model çok kolaylaşır. Asıl programcıyada lazım olan budur. Tüm metodlar vs. burada belirtilir ve sistem kodlanmaya bir use case seçilerek başlanır. O bittikten sonra diğer Use case e geçilir ve o kodlanırken biten use case iyileştirilir. Daha sonra bir diğerine geçilir ve o da kodlanırken diğer ikisi iyileştirilir.

Gerçi daha çok UML diyagramı var ve daha büyük işlerde bunlarada başvurulur.

Örnek olarak ise;
http://www.cs.usask.ca/grads/bjr925/...r/usecases.htm

[kuduk]

amaca (zengin edecek bir program yazmak) ulaşmak için bu kadar çok sürecin takibine gerek yoktur. Bence özel yazılım iki ayrı saikle değerlendirlmeli:
1- para kazanmak: bu amaç kod geliştirenleri pek ilgilendirmemeli, bu dert işletmeci ve pazarlamacının mevzusu
2- ihtiyacı karşılamak: yazılım geliştirenleri esas ilgilendiren amaç budur.

İdeal ortamda tüm yazılım geliştirme işlerinde bu 2 nedenin optimumda birleştirilmesi gerekir.

[burakozgur]

Ne kadar güzel program olursa olsun herşey pazarlamada biter. O kadar çok programlar gördümki dandik ama bir o kadarda satılıyor. Eğer çok para kazanmaksa amacın pazarlama konusunda çok aktif olman gerekiyor.

[uzay95]

Aslında bu başlığı açarken aklımda pazarlama öncesi vardı. Yani bir müşteri geldi ve bize yazılıma ihtiyacı olduğunu söyledi.

Şimdi 2 ihtimal var

1. 1- Ne istediğini biliyor.
2. 2- Ne istediğini bilmiyor ama birisi "yazılım olsa güzel olur" demiş.

Biz öyle profesyonel bir yazılımcı takımıyız ki, içimizde analistler var ve ne soracağını, hangi araçları, yazılımları kullanacağını biliyorlar. Tam burada soru: HANGİ SORULARI ve YAZILIMLARI ve VARSA ARAÇLARI KULLANMALIYIZ.

(Örnek araç: Duvara yapışan rulo şeklinde elektrostatik beyaz kağıtlar var 100x 70 ebadında ve tahta kalemi ile yazıyorsunuz. Duvara izi çıkmıyor dilediğinizde yapıştırdığınız yüzeyden çekip kıvırıp çantanıza koyup evinizde tekrar açıyorsunuz.Belli bir süre sonra kağıttan yazı çıkmıyor.Ama yazdığınız sırada hiç sıkıntı çekmeden silebiliyorsunuz)

(Örnek bir yazılım varsa nedir?Analiz aşamasına UML girer mi girerse örnek bir analiz ve bu yazılım kullanılabilir mi? İlk cevabı yazan kardeşimiz ne güzel bir sayfa ile USE CASE örneği göndermiş bize.Acaba bu USE CASE çıkartmak için bir soru ve cevap bunların sonucunda da bir diyagram örneği var mı?)

Analiz bitti!
Süper analizcilerimiz artık müşterinin ne istediğini ve nasıl adımlarda bir yazılım olacağını anladı.Yazılımcı kardeşlerimize nasıl anlatacaklar peki? Varmı yeni bir diyagram ve yazılım veya kırtasiye malzemesi?

Yazılımcılar konuyu anladılar ve diyagramlarla devam edecekler ama NASIL? Koordine olacaklar ama NEYLE? Hangi yazılımlarla hangi XP yazılım tekniğini kullanmalılar?

Bu konu çok etraflıca biliyorum. Ama herkes fikrini ve en önemlisi tecrübesini yazarsa biz Türk yazılımcıların en önemli sorunu olan ortak dili ve yöntemleri bulmuş oluruz.

Hadi yazalım süpper bir program da kalitemize kalite katalım ne dersiniz?

[kuduk]

Selamalr yazılım geliştirme metodolojilerinden bağımsız olmak üzere aşağı yukarı çeşitli seviyelerde ticari bir yazılım şu aşamalardan geçerek üretilir.

1. Doğru uygulamayı bul
1.1. Muhtemel uygulamayı araştır

• Gözlemle (tümevarım)
• Derin düşün (içe doğuş)
• Esinlen (ideawarz, web 2.0, del.icio.us, digg, Google trends)

1.2.Taslak Yazılım Geliştirme Proje Planını hazırla
1.3. Fizibilite Raporu
1.4. Feasible değil ise her şeyi unut ve 1.1.'e dön

2. Gerçekleştirme
2.1. Yazılım Geliştirme Proje Planını hazırla
2.2. Yazılım Gereksinimleri Raporu hazırla
2.3. Yazılım Tasarım Raporu hazırla
2.4. Geliştirme ekibini görevlendir

3. Test
3.1. Birim testleri gerçekleştir
3.2. Gereksinim testlerini gerçekleştir
3.3. Kurulum testlerini gerçekleştir

4. Dokümantasyon
4.1. Son kullanıcı dokümantasyonunu hazırla
4.2. Programcı dokümantasyonunu hazırla
4.3. Kurulum dokümantasyonunu hazırla
4.4. Bakım ve servis dokümantasyonunu hazırla

5. Ürünü hazırla
5.1. Kurulum paketini hazırla
5.2. Medyaya çoğalt
5.3. Kullanıcı dokümantayonunu çoğalt
5.4. Paketle

6. Eğitim
6.1. Son kullanıcı eğitim çözümünü hazırla
6.2. Servis eğitim çözümünü hazırla

7. Destek
7.1. Servis destek seviyelerini belirle
7.2. Servis destek planını hazırla
7.3. Servis personelini görevlendir

8. Yazılım projesini kapat
8.1. Görevlilirin bonservislerini hazırla
8.2. Hesap ve ödemeleri kapat
8.3. Lesson learned raporunu hazırla
8.4. Proje dosyasını teslim et

9. Pazarlama

10. Dağıtım

ps:Toptan bir reddediş iile bunlara gerek yok diyerek eleştirecekleri, amele meydanının duvarına da bu eleştirilerini çiziktirmeleri daha doğru olacaktır.

[Darksist]

Analiz ve diyagramlarla ilgili birkaç ders dökümanı ekliyorum, işin detayları hakkında ortalama bir bilgiye sahip olabilirsiniz.Zira yazılım geliştirmek eziyet derecesinde bir süreç gerektiriyor. Tabi bu şekilde hazırladığınız bir projeye aylar sonra geri baktığınızda bile neyin nerede olduğunu hemen kavrayabiliyorsunuz.