Yazılım Notları
Bilgi Paylaştıkça Çoğalır...

Yazılım Geliştirme Süreciniz Böyle OLAYDI İyiydi

Öncelikle, Yazılım Birimi kurulur kurulmaz yazılım geliştirme yaşam döngüsü prosedürlerini hazırlamalıdır. Bu prosedürler aşağıdaki başlıkların her birisi için ayrıntılı bilgi içermelidir. Uygulanmadığında mutlaka yaptırımı olmalıdır. En önemli nokta ise, bu konuda mutlaka Yönetim Desteği alınmalıdır.

Yazılım Geliştirme Süreciniz “Böyle OLAYDI İyiydi”

 

Öncelikle, Yazılım Birimi kurulur kurulmaz yazılım geliştirme yaşam döngüsü prosedürlerini hazırlamalıdır. Bu prosedürler aşağıdaki başlıkların her birisi için ayrıntılı bilgi içermelidir. Uygulanmadığında mutlaka yaptırımı olmalıdır. En önemli nokta ise, bu konuda mutlaka Yönetim Desteği alınmalıdır.

 

1.      Yazılım Talebi                           :Yazılım talebinde bulunan birim, talebini ya bir talep yönetim sistemi gibi bir uygulama yoluyla ya da en azından bir form doldurarak, mail atarak konu hakkında çok sınırlı özet bir bilgi vererek görüşme talebinde bulunur.

 

2.      Ön Analiz Toplantısı               :Yazılım Birimi yöneticisi, en az bir analist, en az bir sitem uzmanı, en az bir network uzmanı ile birlikte yazılım talep eden birimden konu hakkında uzmanlığına güvenilen en az 2 kişinin (bir asil bir yedek) katılımı ile gerçekleştirilir. Bu toplantının amacı talep edilen işin gerçekten yazılım geliştirilmesini gerektirip gerektirmediğine karar verilmesidir. Eğer yeni bir yazılım geliştirilmesine ihtiyaç duyulmaksızın, mevcut sistemler üzerinden bir çözüm üretilebiliyorsa zaten sorun çözülmüş demektir. Eğer mevcut sistemler ihtiyaca cevap vermiyorsa yeni bir yazılım geliştirilmesine gerek olabilir.

Bu toplantıda yazılım geliştirilmesine karar verilirse, bu işin Kurum içindeki insan kaynaklarıyla gerçekleştirilip gerçekleştirilemeyeceği sorgulanmalıdır. Bu noktada dikkate alınması gereken asgari hususlar şunlar olabilir:

 

                 i.          Yazılım Biriminde bu konuda çalışacak iş gücü var mı?

               ii.          Bu işgücü, yazılımı geliştirmek için gereken teknik bilgiye sahip mi?

              iii.          Teknik personelin, eğitim alması gerekiyor mu? Bu eğitimlerin süresi nedir?

              iv.          İşin aciliyeti nedir? Teslim için talep edilen son tarih nedir?

               v.          Eğitim gerekiyorsa, eğitimde geçecek süre de dahil ederek, işin teslim edilmesi için söylenen tarihlerle uyumluluğu nedir?

Bu değerlendirmeden çıkacak sonuca göre, yazılımın Kurum İçinde mi yoksa İhale yoluyla mı gerçekleştirileceğine karar verilir.

Her iki durumda da aşağıdaki sürecin işletilmesine devam edilmelidir:

 

3.      Yazılım Geliştirme Metodolojisinin Seçilmesi              :Talep edilen yazılım uygulamasının özellikleri, aciliyeti, süreçte yer alabilecek personel sayısı, yazılım talep edilmesine sebep olan işle ilgili kullanımda olan çözümler, müşterinin BT altyapısı gibi kısıtlar dikkate alınarak uygun bir metodoloji seçilmelidir.

 

 

4.      Proje Planı                               :Proje planı hazırlanır. Etkin ve etkili bir proje yönetimi için MS Project ile hazırlanmasında ve sürekli güncellenmesinde fayda vardır.

 

5.      Analiz Toplantıları                  :Analiz süreci için analiz ekibi tarafından bir yöntem belirlenir. Burada tümdengelim şeklinde öncelikle ana başlıklar belirlenip, sonra detay çalışmasına inilebilir. Bu yazıda analiz toplantılarının bu şekilde gerçekleştirileceği kabul edilmiştir.

 

Bu aşamada yapılacak çalışmalar şu şekilde sıralanabilir:

                      i.     Çalışma Grubu oluşturulur.

                     ii.     Bu grup için bir mail hesabı açılması sağlanır.

                    iii.     İlk Toplantı :

·        Yazılım geliştirme sürecinden bahsedilir.

·        Analiz toplantılarının amacı kısa ama net bir şekilde anlatılır.

·        Konu genel olarak ele alınır ve detayına inilmeden ana başlıklar belirlenir.

·        Çalışma Grubundan son kullanıcı testlerinde görev alacak personeli belirlemeleri istenir.

                    iv.     İkinci Toplantı:

·        Ana başlıklar arasındaki bağımlılıklar incelenir.

·        Gerekiyorsa birbiriyle bağımlılığı olan konularda uzman personelden oluşan alt çalışma grupları oluşturulur.

·        Toplantıların gerçekleşme sırası ve takvimlendirmesi yapılır.

·        Proje Planı güncellenir.

                     v.     Detay Analiz Toplantıları: Bu toplantılarda daha önce belirlenen alt konu başlıklarının en ince ayrıntısına girilene kadar analizi yapılır. Toplantılara en az 1 analist, en az 1 yazılım uzmanı, en az 1 veri tabanı uzmanı katılmasında fayda vardır. Gerektiği durumlarda ise, Sistem ve network uzmanlarının, tasarımcının ve Bilgi Güvenliği uzmanının katılması sağlanabilir

 

Bütün toplantılarda, katılımcıların imzaları mutlaka alınmalıdır. İmza föyünde bulunması gereken asgari bilgiler:

                      i.          Doküman Numarası/Kodu

                     ii.          Tarih

                    iii.          Konusu

                    iv.          Toplantı Yeri

                     v.          Katılımcılar (Ad Soyad, Görevi, İmzası)

                    vi.          Gündem

                  vii.          Alınan Kararlar (Karşılıklı teyitleşildikten sonra doldurulabilir)

 

 

6.      Sentez Süreci            :Analiz toplantılarında alınan notlar, analist tarafından kendi ifadeleriyle düzenlenerek çalışma grubuna gönderilir. Çalışma grubu üyelerinden, bu dokümanda belirtilen hususlarda yanlış anlama ya da eksik kalan bir noktanın olup olmadığı hakkında geri bildirim istenir. Bu mailde, geri bildirim için son tarih mutlaka bildirilmelidir. Aksi halde, söz konusu çalışma grubu üyeleri muhtemelen hiçbir zaman geri bildirimde bulunmayacaktır. Bu mail aynı zamanda, çalışma grubu üyelerinin amirlerine de cc lenmelidir ki, işin ciddiyeti konusunda farkındalık oluşsun.

 

7.      Gereksinimlerin Belirlenmesi             :Çalışma grubu üyelerinden gelen geri bildirimler doğrultusunda analiz dokümanına son hali verilir ve çalışma grubu üyeleriyle paylaşılır. Bundan sonra analist, gruplandırarak ve önceliklendirerek gereksinimleri belirler. Burada, fonksiyonel gereksinimler, MUST gereksinimler, SHOULD gereksinimler şeklinde bir gruplandırmaya gidilmesi, önceliklendirme noktasında analiste yardımcı olacaktır. Bu çalışmayı yapması durumunda proje sürecinde zaten gerekli olacak Tracebility Matrix için de analistin elinde hazır bir şablon bulunacaktır.

 

8.      Tasarım       :Gereksinim dokümanı doğrultusunda tasarım çalışmalarına başlanır. Bu aşamada, İş akış şemaları, UML diagramları, ER diagramları, sistem mimarisi hazırlanır ve ekran arayüzleri oluşturulur. Gereksinim dokümanından elde edilecek bilgi doğrultusunda aşağıdaki sorulara da cevap verilmiş olması gerekir:

 

                      i.     Yazılım uygulamasını geliştirirken hangi yöntem seçilecek: code-centric mi, database-centric mi?

                     ii.     Programlama dili hangisi olmalı?

                    iii.     Uygulama geliştirme ortamı ne olmalı?

                    iv.     Veritabanı ilişkisel mi hazırlanmalı?

                     v.     Seçilecek veritabanı yönetim sistemi ne olmalı?

                    vi.     Ekip çalışması için kullanılacak araç ne olmalı?

 

9.      Geliştirme   :Bu aşamada yer alan iş adımları aşağıdaki gibi olabilir:

 

8nci aşamada belirtilen sorulara aşağıdaki cevapların verilmiştir:

                      i.     database-centric

                     ii.     ASP.Net C#

                    iii.     Microsoft Visual Studio 2013

                    iv.     Evet, veri tabanı ilişkisel olarak geliştirilmeli

                     v.     Microsoft SQL Server 2012

                    vi.     Microsoft Team Foundation Server 2013

Geliştirme aşamasına geçmeden önce en azında şu iki ortamın oluşturulması gerekir: Development ve Test. Development ortamı için projenin kapsamına göre en azından 2 sunucu ihtiyacı olabilir. Bunlar: TFS sunucusu ve Veritabanı sunucusu.

 

TFS sunucunda kaynak kodlar güncel olarak tutulmalıdır. Gerekiyorsa, yazılım geliştirme ekibine bu konuda bir eğitim ya da workshop aldırılmalıdır.

 

Veritabanı sunucusu ise, gereksinim dokümanına bağlı kalarak Veritabanı nesnelerinin oluşturulup yönetileceği sunucudur.

 

Veritabanı ve kod geliştirme aşamasında aşağıdaki başlıklara dikkat edilmesi önemlidir. Bunlar:

 

                     i.          Veri tabanı tasarımı : Veritabanı normalizasyon kurallarına uygun bir şekilde tasarlanmalı. Oluşturulan veri tabanı nesnelerinin (table, view, function, stored procedure, Index vb.) isimlendirmelerinde standart bir isimlendirme konvansiyonu(naming convention) kullanılmalı. Kolonların veri tipleri, bu kolonlarda saklanacak verinin tipine uygun olmalı. Örneğin bir TC Kimlik Numarası alanını NVarchar(MAX) olarak tutmamak gerekir. Kod geliştirilirken ortaya çıkacak Veritabanı nesnelerindeki değişiklik ihtiyaçları için aşağıdaki süreç işletilmelidir:

a.      Analiz dokümanında  gerekli güncellemeler, dokümanda gerekli versiyon değişikliği kaydedilerek yapılmalıdır.

b.      Veritabanında yapılacak değişiklik scriptleri belirli bir yönteme göre kayıt altına alınmalıdır.

c.      Veritabanının bir backup’ı alınmalıdır.

d.      Yazılım uygulamasının herhangi bir versiyonu deploy edilmişse, bunun da bir yedeği alınmalı ve Veritabanı yedek versiyonu ile eşleştirilerek kayıt altına alınmalıdır.

e.      Veritabanı değişiklik scripti çalıştırılmalıdır.

f.       Eğer yazılım uygulamasında herhangi bir değişiklik varsa, yeni versiyonu deploy edilmelidir.

 

                    ii.          Veri tabanı nesneleri oluşturulurken standart bir isimlendirme konvansiyonu izlenmelidir. Örneğin:

a.      Tablo adları “tbl”, “t”, gibi bir ön ek ile başlatılabilir.

b.      View adları “v” ile başlatılabilir.

c.      Foreign Key ler “FK_[TabloAdi]_[ReferansTabloAdi]” olabilir.

d.      Key indexler için “IX_[TabloAdi]_[IndexKolonAdi]”, Unique indeksler için “UQ_[TabloAdi]_[IndexKolonAdi]” olabilir.

e.      Stored Procedure lar için “SP_[YontemAdi]”

f.       Table valued Functionlar için “fn_tbl_[FunctionAdi]”, scalar valued functionlar için “fn_sc_[FunctionAdi]” kullanılabilir.

g.      Bu şekilde tüm Veritabanı nesneleri için standart bir isimlendirme konvansiyonu oluşturulması durumunda, Veritabanında kullanılan tüm nesneler arasındaki ilişkiler, nesnelerin ne anlama geldiği, ne iş yaptıkları gibi bir çok bilgiye INFORMATION_SCHEMA veritabanındaki TABLES, COLUMNS gibi tablolardan ulaşılabilir. Dahası, bu Veritabanı kullanılarak, tablolar arasındaki Foreign Keyler bile yazılım tarafında okunabilir ve bu özelliklerden faydalanan dinamik kodlar yazılabilir.

                  iii.          Veritabanı nesneleri mantıksal ve işlevsel olarak gruplandırılarak ilgili Veritabanı şemalarında oluşturulmalıdır. Örneğin, Veritabanı nesneleri İKYS, CRM gibi farklı işler için aynı yerde oluşturulmuş olabilir. Ancak, hem IKYS’de hem de CRM uygulamasında kullanılacak İl, İlçe gibi tablolar olabilir. Bu durumda, çok basit bir şekilde 3 tane şema oluşturulabilir: GENEL, IKYS, CRM.  İl, İlçe tabloları GENEL şeması altında oluşturulup, hem IKYS hem de CRM uygulamalarının erişebileceği şekilde ortak bir yerde tutulabilir. Şema bazlı Veritabanı yönetimi, Veritabanı kullanıcı yetkilendirmelerinde de çok büyük kolaylıklar sağlamaktadır. Ayrıca, MS SQL Server Always on özelliğinin kullanılmasında da veri tabanı nesnelerinin şema bazlı oluşturulması ve yönetilmesi de çok büyük avantajlar ve kolaylıklar sağlamaktadır.

                  iv.          Yazılım kodlaması yapılırken de standart bir isimlendirme konvansiyonu kullanılmalıdır. Örneğin: Button’lar “btn” ile, TextBox’lar “txt”, checkbox’lar “cbx” ile başlatılabilir. Bu şekilde uygulanacak bir isimlendirme konvansiyonu, hem yazılan kodların okunabilirliğini artıracak, hem kontrollerin ve nesnelerin gerektiği zaman dinamik olarak yönetilebilmesine imkan verecektir.

                    v.          Geliştirilen yazılım kodlarında ve Veritabanı nesnelerinde eklenecek yorum satırları çok büyük önem arz etmektedir. Bu nesneleri oluşturan kişiler herhangi bir şekilde, takımdan ya da işletmeden ayrılabilir. Böyle bir durumda, O kişinin geliştirdiği Veritabanı ya da Yazılım metodlarının ne işe yaradığını, ya da nasıl bir mantıkla geliştirdiğini daha kolay anlayabilmek için yorum satırlarını okumak gerekebilir.

                  vi.          Yazılım Geliştirme uzmanı ya da Yazılım Ekibi içinde görevlendirecek bir kişi, mutlaka unit testleri yapmalıdır. Geliştirilen fonksiyon ve metodların doğru bir şekilde çalıştığı test edilmelidir.

 

10.   Test Süreci:

                     i.            Uygulama ile yapılacak testler için mutlaka geliştirme ve gerçek (production) ortamından izole edilmiş bir test ortamı hazırlanmalıdır. Test Veritabanı sunucusu ve Test Uygulama Sunucusu. Bu iki sunucunun ayrı ayrı olmasında fayda vardır.

                    ii.            Son kullanıcıların geliştirilen uygulamayı test etmeleri planlanmalıdır.

                   iii.            Bunun için öncelikle bir test senaryosu oluşturulmalıdır. Bu test planına göre son kullanıcılara bir eğitim verilmelidir.

                   iv.            Son kullanıcıların uygulamayı test edebilmeleri için bir eğitim planlanmalıdır:

-              Eğitime kimler katılacak?

-              Hangi tarihler arasında yaşılacak?

-              Nerede gerçekleştirilecek?

-              Eğitim dokümanları hazırlanacak.

-              Uygulamanın nasıl kullanılacağı anlatılmalıdır.

-              Test senaryosunun nasıl kullanılacağı anlatılmalıdır.

-              Test Geri Bildirim Formlarının nasıl doldurulacağı anlatılmalıdır.

-              Eğitimin başarısı hakkında bir eğitim sonu değerlendirme sınavı yapılacak.

-              Eğitimin başarısız olduğu konular gözden geçirilecek.

                    v.            Test Senaryosu son kullanıcılara ulaştırılmalıdır.

                   vi.            Test geri bildirim formları son kullanıcılara ulaştırılmalıdır.

                 vii.            Test sürecinin son tarihi bildirilmelidir.

                viii.            Test geri bildirim formlarının geri bildirileceği son tarih bildirilmelidir.

                   ix.            Test geri bildirim formlarında belirtilen hususlara göre Veritabanı ve yazılım uygulamasında gerekli güncellemeler ve geliştirilmeler yapılmalıdır.

11.   Uygulama Devreye Alma(Release & Deployment)

                     i.            Uygulama test süreci de sorunsuz bir şekilde aşıldıysa uygulama devreye alınabilir.

                    ii.            Production ortamı geliştirme ve test ortamlarından tamamen izole edilmiş olmalıdır.

                   iii.            Production ortamında bir Veritabanı sunucusu ve bir uygulama sunucusu olmalıdır.

                   iv.            Yük analizi sonuçlarına göre, gerekiyorsa Veritabanı sunucusunun cluster yapıda oluşturulması gerekebilir. Yine bu durumda, uygulama sunucularının da çoklanarak, Load Balancer ile çoklanması gerekebilir.

                    v.            Uygulama devreye alma aşamasında, devreye alınan uygulamanın Veritabanı backup’ı ve uygulamanın bu Veritabanı versiyonuyla çalışabilir bir yedeği güvenli bir yerde yedeklenmeli ve versiyon bilgisi de yer almalıdır. Gerektiğinde bu versiyona geri dönüş için bir geri dönüş testi yapılmalıdır.

                   vi.            Release & Deployment Yönetimi için uygun bir yazılım kullanılabilir.

 

12.   Tüm aşamalar dokümante edilmiş ve tüm taraflarca imza altına alınmış olmalıdır.

13.   Yazılım uygulamasının devreye alınmasıyla birlikte SLA (Servis Level Aggreement) da devreye girmiş olmalıdır. Tarafların birbirlerine karşı hak ve sorumluluklarını kayıt altına alan bu tarz dokümanlar, müşteri (yazılım isteyen tarafın) memnuniyetini artırırken, yazılım geliştiren tarafın da yaptığı işleri daha şeffaf, sürdürülebilir ve tekrar kullanılabilir kılmasında büyük bir etkiye sahiptir.

14.   Sonuç: Herkes KAZANIR

                      i.     İş Birimindeki uzmanlar: KAZANIR,

Uzmanların yaptığı işlerdeki etkinlikleri artar, kendi alanlarında daha fazla uzmanlaşabilirler.

                     ii.     Yazılım Geliştirme Ekibi: KAZANIR

Yapılan her iş dokümante edildiği için, düzenli, planlı ve ön görülebilir bir şekilde çalışmalarına devam ederler. Konularında yeni teknolojileri takip edebilecek zamanları olur, daha fazla değer katarlar.

                    iii.     Yazılım Geliştiren Firma ya da Birim: KAZANIR

Geliştirilen uygulama, artık birçok firma için tekrar uygulanabilir ya da çok daha rahat bir şekilde uyarlanabilir olacaktır. Çünkü her aşama dokümante edilmiştir ve çok iyi yönetilebilmiştir. Çalıştırılan personelin verimliliği artacağı için, maliyetler azalacaktır. Karlılıkları artacaktır.

                    iv.     Sistem ve Network Birimi: KAZANIR

CPU, RAM, donanım sıkıntısı çekmeyecekler. J Aynı zamanda bulundukları kurumda bu kadar profesyonelce çalışan ve Kurumsal yazılım geliştirebilen bir ekip olduğu için, her uygulama için bir veri tabanı yedeği, bir uygulama sunucusu yedeği almak zorunda kalmayacaklar. J

 

Banka Hesap Numaralarınızı, IBAN Numaralarınızı bir kere telefonunuza kaydedin. İhtiyaç duyduğunuzda elinizin altında olsun.

Banka Hesaplarım

En Güzel Sözler Uygulaması İçin


En Çok Rating Alanlar
Ana Sayfa       Arama       Valid CSS!