Bu sayfanın seçili sürümü ile mevcut sürümü arasındaki farkları gösterir.
Sonraki sürüm | Önceki sürüm | ||
hiz.yoen.04 [2016/04/16 11:47] root oluşturuldu |
— (mevcut) | ||
---|---|---|---|
Satır 1: | Satır 1: | ||
- | ====== SÜRÜM YÖNETİMİ SÜRECİ ====== | ||
- | ===== Süreç Politikası ve Hedefleri ===== | ||
- | Bu sürecin amacı, müşteriye teslim edilecek sürümlerin entegrasyon ve versiyon sorunları yaşamadan müşterinin beklediği şekilde en kısa sürede teslimatını sağlamaktır. | ||
- | Bu süreç gerçekleştiğinde, | ||
- | * Sürüm stratejisi yazılım yaşam döngüsüne ve şartnameye uygun şekilde belirlenmiş, | ||
- | * Sürüm etiketleme ve versiyonlama kuralları belirlenmiş, | ||
- | * Sürüm yönetimi, konfigürasyon, entegrasyon ve test süreçleri arasındaki etkileşim projeye uygun tarif edilmiş, | ||
- | * Sürüm onaylarının müşteri tarafından hangi yöntemlerle yapılacağı ve kabul süreci belirlenmiş, | ||
- | * Sürüm başarı kriterleri ve test yöntemleri oluşturulmuş olur. | ||
- | Bu süreç başarılı uygulandığında, sürümler mümkün olan en kısa aralıklarla birbirlerinin üzerine eklendiğinden kabul aşamasının proje hedefleriyle uyumlu ve müşteri beklentilerine uygun gerçekleşmesi beklenir. | ||
- | =====Tanımlar ve Kısaltmalar ===== | ||
- | **Proje:** Tanımlanmış, kısıtlı bir süre içerisinde ürünün ya da hizmetin geliştirilmesi için gerçekleştirilen aktiviteler bütünü. | ||
- | |||
- | **Müşteri:** Sözleşme kapsamında ve koşullarına uygun olarak Şirket’ in hizmet verdiği kişi ya da kurum. | ||
- | |||
- | **Kullanıcı:** Müşteriye Şirket tarafından temin edilen hizmeti/ürünü kullanan kişi ya da kurum. | ||
- | |||
- | **Ürün Kapsamı:** Proje sonunda ortaya konacak ürünün/hizmetin sahip olması gereken fonksiyonalite ve özelliklerin tümü. | ||
- | |||
- | **Proje Kapsamı:** Proje sonunda ortaya konulacak ürünün/hizmetin sahip olması gereken fonksiyonalitenin ve özelliklerin sağlanması için proje boyunca yapılması gereken iş. | ||
- | |||
- | **İDA:** İş Dağılım Ağacı | ||
- | |||
- | **WBS:** Work Breakdown Structure (İDA) | ||
- | |||
- | **PYP:** Proje Yönetim Planı | ||
- | |||
- | **PDR:** Proje Durum Raporu | ||
- | |||
- | **PKR:** Proje Kapanış Raporu | ||
- | |||
- | **YT:** Yönetim Temsilcisi | ||
- | |||
- | **PY:** Proje Yöneticisi | ||
- | ===== Referanslar ===== | ||
- | * ISO 9000:2008 | ||
- | * TS ISO/IEC 15504-1 | ||
- | * TS ISO/IEC 15504-2 | ||
- | * TS ISO/IEC 15504-3 | ||
- | * TS ISO/IEC 15504-4 | ||
- | * TS ISO/IEC 15504-5 | ||
- | * TS ISO/IEC 15504-6 | ||
- | * TS ISO/IEC 15504-7 | ||
- | * CMMI v1.2 | ||
- | ===== Uygulama Kapsamı ve Uyarlama Koşulları ===== | ||
- | Şirket, yapısı gereği anahtar teslim proje tabanlı, şartname ya da çerçeve sözleşmelerine bağlı olarak müşteriyle birebir olarak çalışır. Dolayısıyla Microsoft, ORACLE gibi büyük kitlelere paketlenmiş hazır ürün sunmaz. Projede sürüm oluşturma sürecinin uygulanması müşteriye belirli aralıklara istediği ürünü kısım kısım sunmak, geri bildirim almak, ürün ve iletişim kaynaklı hataları bir an önce tespit edip projedeki riskleri projenin başlangıç aşamalarında belirlenmesi gibi proje başarısını olumlu etkileyecek yönlere sahiptir. | ||
- | Sürüm yönetim süreci, projede şartnameye uygun olarak belirlenen yazılım yaşam döngüsüne uygun olarak planlanmalıdır. Aksi belirtilmiyorsa bu süreç iteratif bir yaklaşıma sahip olmalıdır. | ||
- | Sürüm yönetim süreci, test, entegrasyon, proje yönetimi ve konfigürasyon yönetimi süreçleriyle uyumlu olarak projelerde işletilmelidir. | ||
- | =====Roller, Sorumluluklar ve Yetkiler ===== | ||
- | **Sürüm Sorumlusu:** Sürümlerin konfigürasyon ve sürüm yönetim planlarına uygun şekilde oluşturulması için gerekenlerin yapılması | ||
- | |||
- | **Konfigürasyon Yöneticisi:** Konfigürasyon yönetim planı, entegrasyon ve sürüm yönetim planları arasında tutarlılığın sağlanması, sürümler için konfigürasyon denetimlerinin planlanması ve gerçekleştirilmesi | ||
- | |||
- | **Proje Yöneticisi:** Yazılım yaşam döngüsüne uygun sürüm stratejisinin proje yönetim planıyla kayıt altına alınması, sorumluların atanması ve proje takvimiyle gerçekleşen sürümlerin karşılaştırılıp değerlendirilmesi | ||
- | |||
- | **Yazılım Geliştirme Ekibi:** Sürümlerin geliştirilmesi ve kurulan altyapıya uygun şekilde sürüm oluşturmaktan sorumlu ekibe teslim edilmesi | ||
- | |||
- | **Test Uzmanı:** Sürümlerin fonksiyonel testlerinin gerçekleştirilmesi | ||
- | |||
- | **Müşteri:** Sürüm stratejisinin belirlenmesi ve onaylanması, sürümlerin kabul testlerinin gerçekleştirilmesi | ||
- | ===== Sürecin Tedarikçi ve Müşteri Süreçleri ===== | ||
- | ==== Tedarikçi ==== | ||
- | * Proje Yönetim Süreci | ||
- | * Risk Yönetim Süreci | ||
- | * Gereksinim Yönetimi Süreci | ||
- | * Konfigürasyon Yönetimi Süreci | ||
- | ====Müşteri ==== | ||
- | * Test Süreci | ||
- | * Entegrasyon Süreci | ||
- | * Kurulum ve Yaygınlaştırma Süreci | ||
- | * Risk Yönetimi Süreci | ||
- | * Problem Çözüm Süreci | ||
- | =====Girdiler ===== | ||
- | * Şartname | ||
- | * Proje Yönetim Planı | ||
- | * Konfigürasyon Yönetim Planı | ||
- | * Entegrasyon Araçları | ||
- | * Gereksinim Tanımları Dokümanı | ||
- | * Konfigürasyon Yönetim Aracı | ||
- | ===== Uygulama ve İş Akışı ===== | ||
- | ====Oluşturulacak Sürümlerin Planlanması ==== | ||
- | Seçilen yazılım yaşam döngüsüne uygun olarak projenin sürüm çıkarma ve planlama stratejisi proje yöneticisi, konfigürasyon yöneticisi ve ilgili teknik proje personeli tarafından oluşturulur. Oluşturulan bu stratejiyi müşteriye sunulur ve onayı alınır. Sürüm stratejisi, proje yönetim planında yazılım yaşam döngüsünün açıklandığı teknik planda genel olarak açıklanır. Proje yönetim planında hangi sıklıkla sürüm çıkarılacağı, tahmini teslim tarihleri belirtilir. Proje yönetim planının müşteri tarafından onaylanmasıyla sürüm stratejisi de onaylanmış olur. Projede seçilen yaşam döngüne uygun olarak çıkacak her sürüm ya da ileriye yönelik birkaç sürüm için sürüm yönetim planı oluşturulur. | ||
- | Proje organizasyonunda sürüm (build) sorumlusu atanmışsa sürüm yönetim planını oluşturmaktan sorumlu odur. Eğer ayrıca bir rol tanımlanmamışsa proje ekibiyle koordineli çalışarak projede uygulanacak build sürecinin organizasyon yapısını oluşturur. | ||
- | Sürüm planında, | ||
- | * O sürümün yerine getireceği işlevsel gereksinimler | ||
- | * Zaman planı | ||
- | * Sürüm için oluşturulacak dokümantasyon | ||
- | * Sürümün Şirket içinde kullanılmak üzere yayınlanacak bir sürüm ya da müşteriye teslim edilecek bir sürüm olup olmadığı | ||
- | * Sürüm test ve başarı kriterleri | ||
- | * Araç, donanım, entegrasyon ve diğer ortam şartları belirtilir. | ||
- | ====Ürünlerin Oluşturulması ve Ana Hatta Alınması ==== | ||
- | Konfigürasyon yönetim sürecine ve projenin konfigürasyon planına uygun olarak çıkacak sürümlerin içerikleri (yazılım, donanım ve ilgili dokümantasyon) hazırlanır ve ana hatta alınır. Oluşturulan sürümlerin içeriğini tanımlayan Sürüm Notları dokümanı build yöneticisi tarafından hazırlanır. Ana hatta alınmış sürümler projede kullanılan konfigürasyon yönetim aracının özellikleri göz önünde bulundurularak versiyonlama sisteminde saklanır. | ||
- | ====Sürümlerin Etiketlenmesi, Sınıflandırılması ve Versiyonlanması ==== | ||
- | İki tip sürüm vardır: Şirket sürümü ve Müşteri sürümü | ||
- | Müşteriye çıkarılan sürüm, müşterinin kabul testlerini gerçekleştirdikten sonra onay vereceği sürümdür. | ||
- | Şirket sürümü, yazılım geliştirme sırasında yazılıma yeni işlevsellik eklendikçe ve bir önceki sürümün üzerine özellik katan ya da hata düzelten iç sürümlerdir. | ||
- | Müşteriye giden sürümle Şirket iç sürümlerini ayırt edebilmek için farklı etiketleme sistemi kullanılabilir. Konfigürasyon yönetim planında konfigürasyon yöneticisi isimlendirmenin kurallarını anlatır. Şirket’te kullanılan etiketleme ve versiyonlama sistemi Sürüm Yönetim Kılavuzunda anlatılmıştır. Bu kılavuzda anlatılanın dışında teknolojiler kullanan projeler konfigürasyon yönetim planlarında ya da ilgili sürüm planında metodolojilerini açıklarlar | ||
- | Her bir sürümün bir öncekinden farklı bir versiyon numarası vardır. Bu numaralar versiyonlama sistemi tarafından otomatik olarak sürüme atanır. | ||
- | ====Build Ortamının Oluşturulması ve Build Faaliyetlerinin Tanımlanması ==== | ||
- | Şirket’te kullanılan build ortamı Sürüm Yönetim Kılavuzunda anlatılmıştır. Eğer altyapı ekibinin kurduğu ortamdan farklı bir yapı kullanılacaksa projeler konfigürasyon yönetim planında build ortamlarını tarif ederler. | ||
- | Build faaliyetleri planlanırken | ||
- | * Tasarım | ||
- | * Kodlama ve birim test | ||
- | * Build | ||
- | * Test faaliyetleri için gerekecek kaynak ve süre ayrı ayrı hesaplanır. Eğer çıkacak sürüm başka bir sisteme entegre edilecekse entegrasyon testleri ve müşteri sürümüyse kabul testleri için de planlama yapılmalıdır. | ||
- | ====Build İşleminin Gerçekleştirilmesi ve Entegrasyon ==== | ||
- | Konfigürasyon Yönetim Planında sürüm çıkarma sıklığı ve kullanılacak araçlar listelenir. Şirket Sürüm Yönetim Kılavuzunda altyapıya bağlı projeler için yöntemler, akış ve araçlar anlatılmıştır. Altyapıya bağlı çalışacak projeler kendi ihtiyaçlarını altyapı grubuna bildirirler. Proje veya konfigürasyon yönetim planında belirtilen organizasyon şemasına göre iş paylaşımı yapılır ve sürüm altyapısı proje için oluşturulur. | ||
- | Projeler var olan sistemden farklı ihtiyaçlara sahipse konfigürasyon yönetim ya da sürüm yönetim planında build otomasyonu diğer araçlarla akışı konfigürasyon yöneticisi tarafından açıklanır. | ||
- | ====Sürüm Dağıtım, Paketleme ve Kurulum Faaliyetlerinin Tanımlanması ve Gerçekleştirilmesi ==== | ||
- | Müşteri sürümü, Şirket iç testlerinden geçtikten sonra müşteri ortamına kurulum yapılır. Sürüm, müşteriye teslim edilmeden önce Sürüm Notları müşteriye yollanır. Bu notlarla, sürümün içeriği ve uygulama dosyalarında yapılan değişiklikler açıklanır. Müşteri sürüm notlarını onayladıktan sonra ve iç testler tamamlanınca belirlenen kurulum tarihinde kurulum yapılır. Kurulumdan kimin sorumlu olduğu ve paketleme koşulları şartnamede belirtilir. | ||
- | Varsayılan olarak kurulumu müşteri gerçekleştirir. Bu durumda kurulumda ihtiyaç duyulan scriptler müşteriye e-posta ile diğer uygulama dosyaları networkden müşteriye güvenlik sağlanarak gönderilir. Kurulum sırasında müşterinin verdiği hizmetin aksamaması için kurulum zamanı günün uygun saatlerinde yapılmak üzere kararlaştırılır. Kurulum yeni isteklerin yapıldığı bir sürüm içinse Şirket personeli de kurulum sırasında hazır bulunur, eğer hata düzeltme için yapılıyorsa o zaman Şirket personeli bulunmayabilir. | ||
- | Paketleme ve kurulum faaliyetleri konfigürasyon yönetim planında konfigürasyon yöneticisi tarafından proje gereksinimlerine uygun detaylandırılır. | ||
- | ==== Kurulum Sonrası Destek ve Bakım Hizmetlerinin Planlanması ==== | ||
- | Müşteride kurulumu tamamlanan sürüm için verilecek bakım ve destek hizmetleri şartnameyle belirlenmiş olmalıdır. Bakım aşamasında yapılacak işlemler proje yönetim planında yazılım yaşam döngüsünde anlatılmıştır. | ||
- | Kullanıcının sorunlarını iletmesi için Şirket ve müşteri arasında bir iletişim altyapısı kurulur. Bulunan problemler problem çözüm sürecine uygun bir şekilde Şirket’ e iletilir. Problem çözüm aracı için ERP kullanılır. Müşterinin ERP’ yi kullanabilmesi için gerekli yetki tanımları yapılır. ERP kullanımı, ERP kullanım kılavuzunda açıklanmıştır. | ||
- | ==== Sürüm Dokümantasyonun Hazırlanması ve Kontrolü ==== | ||
- | Sürümle ilgili test, sürüm yönetim, entegrasyon planları, sürüm notları, kullanıcı kılavuzları ve diğer belgeler müşteriye teslim edilir ve konfigürasyon yönetim sürecine uygun versiyonlanır. Yazılım ve diğer doküman versiyonları arasında tutarlılık sağlanır. Hazırlanan dokümanlar projenin dokümantasyon planında ve doküman kontrolü sürecinde belirtildiği şekilde gözden geçirilip onaylanır. | ||
- | ==== Sürüm Başarı Kriterlerinin Tanımlanması ve Sürümün Test Edilip Onaylanması ==== | ||
- | ŞİRKET sürümlerinin başarılı şekilde çıkması için tüm birim testleri ve statik kontrolleri sürüm oluşturma esnasında geçmesi gereklidir. Sürekli entegrasyon aracından başarıyla geçen sürüm proje test planına uygun şekilde test uzmanlarına gönderilir. Geliştirme ortamından test ortamına kurulumun hangi sıklıkta ve hangi yöntemler kullanılarak gerçekleştirileceği projenin test planında belirtilir. Test ve problem çözüm sürecine uygun şekilde testi başarıyla tamamlanmış sürüm başarılı kabul edilir. | ||
- | Müşteri sürümlerindeyse yukarıdakine ek olarak müşterinin kabul testi yapması ve buradan sürümün başarıyla geçip kabul edilmesi gereklidir. Projelerin test planlarında kabul testiyle ve resmi işlemlerle ilgili bilgi verilir. Eğer aksi belirtilmemişse Şirket müşteriye test sürecine uygun şekilde test durumlarını sunar. Müşteri test durumlarını, sürüm notlarıyla birlikte değerlendirerek kabul kriterlerini onaylar. Sonrasında kabul edilen test durumları müşterinin erişimi olduğu ortamda müşteri tarafından test edilir. Başarılı geçen kabulde test durumlarına ön yazıyla sürümün kabul edildiği belgesi eklenir ve müşteri tarafından imzalanır | ||
- | ==== Sürümün Müşteriye Teslimi ve Kurulum ==== | ||
- | Müşteriye teslimatın nasıl yapılacağı şartname ve proje yönetim planında belirtilir ve müşteri onayına gerekirse sunulur. Aksi belirtilmedikçe ürünün müşteriye kurulumu network üzerinden gerçekleştirilir. Kabul testlerini başarıyla geçen ve bunu belgeleyen sürüm müşteri tarafından teslim alınmış demektir. Müşteri teslim aldıktan sonra verilecek bakım ve destek hizmetleri şartnameyle ve proje yönetim planıyla belirtilir. | ||
- | ==== Müşteri Kabulü ==== | ||
- | Müşteri kabulü, kabul testlerinin başarıyla tamamlanması ve kabul yazısının müşteri tarafından onaylanmasıyla yapılır. | ||
- | ===== Çıktılar ===== | ||
- | * Sürüm Yönetim Planı | ||
- | * Sürüm Notları | ||
- | * Test Durumları Dokümanı ve Test Sonuçları | ||
- | * Sürüm | ||
- | * Kabul Belgesi | ||
- | * Sürüm Yönetim Kılavuzu | ||
- | ===== Eğitim, İnsan Kaynakları ve Altyapı İhtiyaçları ===== | ||
- | Sürüm sorumlusu ve konfigürasyon yöneticisi, | ||
- | * Yazılım Yaşam Döngüsü (iteratif) | ||
- | * Sürüm ve konfigürasyon yönetim süreçleri | ||
- | * Sürüm oluşturmak için kullanılan araçlar | ||
- | * Yazılım geliştirme hakkında bilgi sahibi olmalıdır. | ||
- | =====Kayıtların Kontrolü ve Saklanması ===== | ||
- | Sürüm yönetim planı, sürüm notları ve ilgili dokümanlar proje yönetim ya da konfigürasyon yönetim planında aksi belirtilmedikçe proje portalında (FTP Sunucu) saklanır, versiyonlanır ve konfigürasyon yönetimi altına alınır. Bütün planlara gelen değişiklikler anahatta alındıktan sonra konfigürasyon yönetim sürecine uygun şekilde kontrol edilir. | ||
- | ===== Süreç Performansının Kontrolü ve İyileştirilmesi ===== | ||
- | Sürüm yönetim sürecinin kontrolü projelere yapılan iç denetimlerle yapılır. Ortaya çıkan düzeltici ve önleyici faaliyet istekleri incelenerek süreç performansı değerlendirilir. Eğer düzeltici faaliyetlerin oranı yapılan denetimlere ve soru sayılarına göre yüksekse projede süreç uygulanmıyor olabilir. Bu durumda proje yönetim süreci performansını değerlendirmek mümkün olmaz. | ||
- | Süreç uygulanmasına rağmen aksaklıklar olabilir. Eğer çıkan sürümler için yapılan testlerde versiyonlamadan kaynaklanan hatalar varsa, sürüm oluşturma proje için proje sure hedeflerini olumsuz etkileyecek kadar zaman alıyorsa, çıkan hataların hangi sürümlere ait olduğu, bu sürümlerin oluşturulması ve hataların giderildiği sürümlerin belirlenmesi projede karışıklığa neden oluyorsa sürüm yönetimi sürecinin iyileştirilmesi gerekir. | ||
- | Süreç performansı, veriler yıllık olarak tüm süreçlerden alınarak kalite grubu tarafından değerlendirilir ve kalite yönetim sistemi performans raporuna yansıtılır. Bu raporda süreçlerle ilgili iyileştirme önerileri sunulur. Yönetim kurulu, proje yöneticileri, kalite ekibi iyileştirme önerileri için önceliklendirme yapıp plan hazırlarlar. Öncelik verilen süreçler veya hedefler için süreç iyileştirme çalışması başlatılır ve takip edilir. Bu çalışmanın sonunda değerlendirme yapmak için sağlıklı veri bulunmadığı yorumu da çıkabilir. O zaman verilerin doğru değerlendirilebilmesi için metrik toplamaya devam edilmesine ve sürecin izlenmesine karar verilir. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||