"Bir yazılım projesinde, değişim kaçınılmazdır. Değişim yönetimi, bu değişiklikleri yönetmenizi ve koordine etmenizi sağlar. Bu sayede değişiklikler sorun olmaktan çıkar, yazılımı geliştirir."
!! Değişim Yönetimi, süreç içindeki değişiklikler üzerinde bir kontroldür.
Özet olarak bir değişim yönetimi senaryosu verecek olursak:
1. Değişimin gereksinimlerini analiz et
2. Değişimi planla
3. Değişimi gerçekleştir
4. Değişimi raporla
5. Değişim olası sonuçlarını incele
|
Yazılım geliştirmedeki tek sabit "değişim"dir. İlk kapsamdan, tamamlanma fazına ve bakıma kadar, yazılım devamlı değişir. Bu değişiklikler, yazılımın gereksinimleri karşılayıp karşılamadığını, yazılımın zamanında ve uygun bütçeyle tamamlanıp tamamlanamadığını belirler. Proje yöneticilerinin de asıl görevlerinden biri, değişim yönetimidir.
Süreç Değişim Yönetimi’nin Amaçları:
1. Değişim isteklerine proje bağlamında servis vermek.
2. Her değişikliği resmi olarak belgelemek.
3. Her değişikliğin potensiyel etkisini değerlendirmek.
4. Değişim için gerekli süreçleri ve yetkiyi sağlamak.
5. Tüm grupları değişikliklerden haberdar etmek.
|
Değişim yönetimi, 2’ye ayrılır: Değişim Planlaması ve Değişim Yönetimi.
1.1.Değişim Planlaması
Değişim planlaması, değişimin risk seviyesini belirleyen ve değişimin başarılı olabilmesi için gerekenleri tanımlayan bir süreçtir.
Değişim Planlamasının ana adımları şunlardır:
1. Değişim planı gereksinimlerine göre en az 3 risk seviyesi belirle.
2. Tüm değişimlere bir risk seviyesi ata.
3. Yazılım/donanım güncellemeleri, yapılanış değişimleri için yeni tanımlamalar yap.
1.2. Değişim Yönetimi
Şekil 1- Değişim Yönetimi
Değişim yönetimi adımları:
Değişim yönetimi aktivitelerini yönetebilecek olan, değişim isteklerini kabul edecek ve inceleyecek, süreç değişim gelişmelerini yönetecek bir değişim kontrolcüsü ataması yap.
Sistem yöneticisi, uygulama geliştiricileri, kullanıcılar ile periyodik olarak değişim gözden geçirme toplantıları düzenle.
Gereksinimleri düzenle, belgele.
Değişim çıktılarını belgele, düzenle.
Yüksek risk seviyeli değişimler için bir değişim onaylama yordamı belirle.
2. Değişim Yönetimi ve Yapılanış Yönetimi İlişkisi
Yapılanış yönetimi, değişim yönetiminin ana bileşenlerinden biridir. Yazılım yapılanışı yönetimi, yazılımın belirgin sürümlerini, ileride kullanılmak üzere tespit eder. Eğer yapılanış yönetimi alt seviyedeyse, proje yöneticisi değişiklikleri sadece uzaktan izlemekle yetinir. Ayrıca, gelişimin tahminlenmesi de zorlaşır.
Yazılım değişimi yönetimi, hangi değişikliklerin doğru olduğunu belirleyen bir süreçtir. Hangi değişikliklerin yapılması gerektiğini, hangilerinin önlenmesi gerektiğini proje zaman çizelgesi ve bütçesine göre belirler. Değişim Yönetimi süreci, değişikliklerin kaynağını belirler, kritik proje karar noktalarını tanımlar, proje sorumluluklarını belirler. Aşağıdaki şekilde, süreç bileşenleri ve aralarındaki ilişkiler gösterilmektedir. Şekilden de görüldüğü gibi, değişim yönetimi ile yapılanış yönetimi birbiriyle direkt ilişkilidir.
Şekil 2- Süreç Bileşenleri, İlişkileri
Yazılım Yapılanış Yönetimi (YYY) ve değişiklik takibi arasındaki ilişki, değişim yönetiminin merkezindedirler. YYY standardları, değişim kontrolünü, yapılanışın tanımından sonra gelen bir görev olarak görür. Bu da, bazı geliştiricilerin, YYY’nin değişimleri yönetmektense değişimleri engellediğini düşündürebilir. Oysa Değişim Yönetimi, doğru değişiklikleri en verimli şekilde seçerek uygulamayı hedefler. Bu bağlamda YYY sürümleri, versiyonları ele alırken değişimden Değişim Yönetimi sorumludur diyebiliriz.
Şekil - 2’de görülen değişiklik verileri havuzu, süreç değişim yönetimini destekler. Geliştiriciler, testçiler, kullanıcılar değişiklikler hakkındaki verileri buraya girerler. Değişiklik verileri havuzu kullanılarak, sürüm ve yayımların tutarlılığı sağlanır. Ve havuzdaki veriler, gerçekleştirim safhasında da gözönünde tutulurlar.
Süreç Değişim Yönetimi, proje yönetiminin bütünleşik bir parçasıdır. Geliştiriciler için, yazılımlarının başarıya ulaşmasındaki tek yol, yazılımı değiştirmekten geçer. Değişim Yönetimi de bu değişiklikleri koordine eder ve yönetir.
Anlatılanları daha iyi kavrayabilmek için aşağıdaki şekil yardımcı olacaktır.
Şekil 3- Süreç Değişim Yönetimi Bileşenleri
3. Değişiklikler Nerelerden Kaynaklanır?
Birçok konu yazılımda değişikliklere yol açar. Bu gelecek değişikliklerin kaynaklarını bulmak, öncelik sırasında koymamızda bize yardımcı olur. Değişimin kaynağı, planlı gelişim, beklenmedik sorunlar, iyileştirmeler olarak tanımlanabilir.
Şekil 4- Değişikliği Oluşturan Kaynaklar
3.1. Planlı, Düzenli Yazılım Geliştirme
Ideal olarak, tüm yazılım değişiklikleri, planlı geliştirme çabasından kaynaklanmaktadır. (Gereksinimler ve belirtimler tarafından ileriye sürülen gerçeklerle ilgili.) Yeni bir kod eklemek, yönetilmesi gereken bir değişiklik anlamına gelmektedir. Kullanılmayan fonksiyonların eklenmesi, projenin kaynaklarını tüketecek, hata oluşma riskini arttıracaktır. Bazen istenen özellikler gerçekleştirilmeden bile değişiklik yapılamdan önce üzerinde düşünlmesi gerekebilir. Maliyet-Yarar bağlamında, istenen her değişiklik, detaylıca incelenmeli ve planlı bir şekilde ele alınmalıdır.
3.2. Beklenmeyen Problemler
Geliştirme esnasında, doğal olarak sorunlar keşfedecek ve bunları çözebilmek çin kaynaklarınızın bir kısmını bu sorunlara harcayacaksınız. Problemin büyüklüğüne göre harcanan zaman ve çaba artacaktır. (küçük hatalar projenizin bütçesini harcayamaz)
Geliştirme takımı, kodun tasarımının düzgün olduğunu, gereksinimlerin karşılandığını belirler. Son olarak, tasarım ve gereksinim hatalarının düzeltildiğinden emin olunmalıdır. Sonraki bölümlerde anlatılacak olan bütünleşik süreç değişim yönetimi araçları, bir değişiklik yapıldığında gerekli belgelerin gözden geçirilip düzeltilmesi gerektiğini belirtir. Bu belge yenilemesinde, yeni problemler ortaya çıkabilir.
3.3. İyileştirme Çabaları
Tüm yazılım projeleri, bir araştırma ve geliştirme çabasının ürünleridir. Bu yüzden projelerde, iyileştirme fikirleri ortaya çıkar. Bu noktada proje yöneticisi öne çıkar. Fikir projeyi kestirmeden hedefine uaştırabilecek parlak bir fikir olabilir ya da projenin başarısını tehdit eden bir yanlış fikir olabilir.
4. Değişim Sürecindeki Kritik Karar Noktaları
Değişiklikler, potensiyel değişiklikler olduğundan, henüz projenin kaynaklarını tüketmeye başlamadan belirlenmelidirler. Her görev gibi, değişimin de takip edilmesi gereken bir yaşam döngüsü yada değişim süreci vardır. Genelde, şekilde görülen 3 kritik nokta, süreç değişimini belirler. Bu noktalar, değişim çerçevesini oluşturan etmenlerdir.
Şekil 5- Süreç Değişimi & Kritik Noktalar
Kavramı Onayla: Değişim istekleri, test grubundan, problemleri tanımlayan kullanıcılardan ve gereksinim ekleyip çıkaran müşterilerden gelir. Belirli miktarda kaynağı bu değişimlere ayırmadan önce, değişimleri onaylamak gerekir. Bu, Süreç Değişimi Yönetimi’nde ilk kritik karar noktasıdır. Bu noktada eğer bir fikir kabul edilirse, gerekli kaynakların sağlanması için o kavrama bir öncelik verilir.
İlerlemeyi Onayla: Bir süreç değişimi onaylandıktan sonra, ikinci adımda bu değişimi projenin gereksinimlerine, belirtimlerine, tasarımına, zaman çizelgesine, bütçesine karşı değerlendirmek gerekir. Böyle kapsamlı bir analiz, değişim için gereklidir çünkü süreç değişimi, büyük ihtimalle projenizi büyük ölçüde etkileyecektir. Maliyet-yarar bağlamında analiz edilen değişim hakkında, ilerleme kararı veya durdurma kararı alınır.
Kararlılığı Onayla: Değişim isteği, planlı geliştirme fazına geçince tamamlanmış demektir. Gereksinimlerin analizi ve tasarım aşamalaırnda bu adım, isteğin onaylanmasından hemen sonra olur. Ama kodlama aşamasında ise, planlı olmayan tüm değişiklikler için ayrı ayrı test ve gerçekleştirim yapılmalıdır. Bu testlerde hem orjinal durum hem de planlanan değişim durumu test edilerek yeni durumun herhangi bir sorun yaratıp yaratmadığı belirlenir.
Testten sonra, değişimin diğer uygulama parçalarını nasıl etkiledğini gözlemlemelisiniz. Örneğin, yanlış mantıkta olan bir kullanıcı girdisi alma modülü için doğru olan arayüz değiştirilirse, ileride açılacak problemler için bu değişiklik reddedilmelidir.
Reddedilen ve Ertelenen İstekler: Herhangi bir karar aşamasında, bir istek reddedilebilir veya ertelenebilir. Bu durumda, istek tüm dökümantasyonuyla birlikte rafa kaldırılırmalıdır. Böylelikle, aynı fikir tekrar ortaya atılacak olursa, neden reddedildiği hemen ortaya konur ve sebepleri düşünmek üzerine zaman harcanmaz. Eğer şartlar değişirse, ertelenme veya red, geri çekilebilir.
!! Eğer bir problem üretimi veya testi durduracak kadar aciliyet teşkil ediyorsa, kapsamlı bir analiz zamanı veya resmi bir karar verme zamanı olmayacaktır. Süreç Değişim Yönetimi mekanizmasının bir acil durum işleyişi olmak zorundadır. bu işleyiş, analizi ve karar aşamalarını daha hızlı geçmeyi sağlayacaktır.
Mesela acil durum yaratan problem, biraz değiştirilerek durum aciliyetten çıkarılabilir ve sonra normal işleyişe dönülebilir. Böylelikle sistem çalışır duruma getirilir ve kapsamlı bir analiz yapılabilir. Ya da sorun tamamen bir aşamada çözülebilir. Seçimi proje yöneticisi yapacaktır.
5. ROLLER VE SORUMLULUKLAR
Süreç Değişimi Yönetimi, karar noktalarında bazı karar veririlerin olması gerektiğine dikkat çeker. Değişim Yönetimi süreci, aşağıdaki soruları belirlemek zorundadır:
1. Kararı kim verecek? (Sonunda, kararların sorumluluğu proje yöneticisindedir ama bazı sorumluluklar proje liderlerine verilebilir.)
2. Karar için gerekli bilgileri kim verebilir? Kim verecek?
3. Analiz, gerçekleştirim ve testi kim yapacak? (Bu bölüm genel olarak belirlenebilir ama her alt konu için ayrı kişilerin ataması yapılmalıdır.)
4. Karar verilince kime haber verilmeli?(İlgili kişiye ne zaman, nasıl sorularının detaylı olarak anlatıldığı bir açıklama yapılmalıdır.)
5. Yordamları kim yönetecek?
Tüm konuları tüm proje aşamalarında aynı şekilde ele almaya gerek yoktur. Projeyi ortak merkezli dünyalardan olşuyor diye düşünürsek, geliştirme takımı, test takımı, kalite takımı, kullanıcılar ayrı birer dünya olmaktadırlar. Daha geniş gereksinim, tasarım kararları aldıkça daha çok dünyayı etkilemiş olursunuz. Örneğin kod modülünde bir değişimi kabul ederseniz, test takımı da bu değişiklikten etkilecektir. Standard değişim yönetimi müşteri ile proje takımı arasında, ürün hakkında yapılan bir anlaşma gibidir: ilk önce gereksinimler, sonra tasarım ve son olarak ürün ile ilgili anlaşmalar olarak düşünülür. Müşteri yapılacak değişiklikleri onaylamalıdır. Değişim yönetimi, bu yüzden müşteri ve geliştirme takımı arasındaki iletişimin de iyi olmasını sağlar.
6. Süreç Değişim Yönetimi Araçları
İlgilenilmesi gereken veri çok olduğundan, yazılım süreç değişikliklerini yönetmek için genelde araçlara ihtiyaç duyulur. Buradaki önemli nokta, işe yarayan aracın seçilmesidir. Araçların problemleri çözmesi beklenmemelidir, süreçlerinizin araçları yönetmesi gerekmektedir. En iyi süreci belirlemek ve bu süreçle ilgili problemleri tanımlamak daha iyi bir süreç tanımlamanın ilk adımıdr.
Not: Başarılı bir sistem, insanları, süreçleri, teknolojiyi koordine eder. Süreç belirlendikten sonra, takımın motive edilmiş ve eğitimli olmasına dikkat edilmelidir. En iyi araç bile düzgün kullanılmazsa yararsızdır.
Süreç Değişimi Yönetimi’nin en önemli bileşenleri, Yazılım Değişim Yönetimi araçları, sorun raporlama aracı, değişim isteği takibi araçlarıdır. Genelde bu araçlar, bir sistem olarak birleşik biçimde sunulmaktadır.
!! Büyük yazılım sistemleri için, bir Süreç Değişim Yönetimi aracına ihtiyaç vardır. Böyle bir araçtan üretilecek bilgi, süreç geliştirmede kullanılabilir.Bakım için, aracın olşturacağı değişim modelini kullanmak, modelsiz geliştirmeden daha iyidir.
Araçlar:
1. Continuus/CM (SCM)
2. Continuus/PT (Change Tracking)
Continuus Software
Irvine, Calif.
Tel: (949) 453-2200
http://www.continuus.com/
3. SourceSafe (SCM)
Microsoft Corp.
Redmond, Wash.
Tel: (800) 426-9400
msdn.microsoft.com/ssafe
4. Source Integrity Professional (SCM and Change Tracking)
MKS Inc.
W. Waterloo, Ont. Canada
Tel: (800) 265-2797
http://www.sdmagazine.com/documents/s=756/sdm9907e/mailto:[email protected]
5. PVCS (SCM and Change Tracking)
Merant (Intersolv/Micro Focus)
Beaverton, Ore.
Tel: (503) 645-1150
http://www.sdmagazine.com/documents/s=756/sdm9907e/mailto:[email protected]
6. ClearCase (SCM)
ClearDDTS (Change Tracking)
Rational Software Corp.
Lexington, Mass.
Tel: (617) 676-2400
http://www.sdmagazine.com/documents/s=756/sdm9907e/mailto:[email protected]
7. RCS (SCM)
Free Software Foundation
Boston, Mass.
http://www.sdmagazine.com/documents/s=756/sdm9907e/mailto:[email protected]
8. CCC/Harvest (SCM)
Apriori (Change Tracking)
Platinum Technologies
Oakbrook Terrace, Ill.
Tel: (800) 442-6861
http://www.platinum.com/
Kaynaklar
July 1999 Project Management Software Change Management.htm
Cisco - Change Management: Best Practices White Paper
Qwest Change Management Process Redesign Evaluation March 25, 2002 Version 3.0 Prepared for: Arizona Corporation Commission
IIR-Presentation, Ivica Ivica Crnkovic
Makale:
Süreç ve Yazılım Değişimi Yönetimi Yazılım Mühendisliği Tanıl Ergin
|