Şekil 29.1 Sistem Aileleri
Konfigürasyon yönetimi (Configuration Managenent – CM ) geliştirilen bir sistem ürününün yönetimi için standart ve prosedürlerin geliştirilmesi ve uygulanmasıdır. Geliştirilen sistemler yönetilmelidir çünkü; sistemler geliştirildikçe, yazılımın birçok versiyonu yaratılır. Bu versiyonlar, değişim için önerileri gerçekleştirir, hataları düzeltir ve farklı donanım ve işletim sistemleri için adaptasyonları sağlarlar. Aynı anda kullanımda ve geliştirilme aşamasında bir çok versiyon bulunabilir. Gerçekleştirilen değişikliklerin ve bu değişikliklerin yazılım içerisinde nasıl kapsandığının kayıtları tutulmalıdır.
Konfigürasyon yönetimi prosedürleri, önerilen sistem değişikliklerinin nasıl kaydedildiğini ve gerçekleştirildiğini, bunların sistem parçalarıyla nasıl ilişkilendirildiğini ve sistemin değişik versiyonlarının tanımlanması için kullanılan metotları tanımlarlar. Konfigürasyon yönetimi araçları, sistem parçalarının versiyonlarının tutulması, sistemin bu parçalardan inşası ve müşterilere sistem versiyonlarının sürümlerinin bildirilmesi için kullanılırlar.
Konfigürasyon yönetimi, bazen daha genel olan yazılım kalite yönetimi sürecinin bir parçası olarak görülür. Aynı müdür, kalite yönetimi ve konfigürasyon yönetimi sorumluluklarını paylaşabilir. Yazılım, geliştiriciler tarafından, sistemin kabul edilebilir kalitede olup olmadığını kontrol etmekle sorumlu olan bir kalite güvence (assurance) takımına teslim edilir. Daha sonra, yazılıma yapılan değişiklikleri kontrol etmekle sorumlu olan konfigürasyon yönetimi takımına geçirilir. Kontrol edilmiş sistemler, kontrollü geliştirimin başlangıç noktası oldukları için bazen baseline olarak adlandırılırlar
Sistemlerin farklı konfigürasyonlarda bulunmalarının bir çok sebebi vardır. Konfigürasyonlar, farklı bilgisayarlar, farklı işletim sistemleri için yapılmış olabilirler, istemciye mahsus fonksiyonlar eklenmiş olabilir (Şekil 29.1). Konfigürasyon yöneticileri, yeni versiyonların kontrollü bir şekilde türetildiğinden ve yeni versiyonların doğru müşterilere doğru zamanda sunulmasından emin olunması için, yazılım versiyonları arasındaki farkların izlenmesinden sorumludurlar.
Şekil 29.1 Sistem Aileleri
Konfigürasyon yönetimi süreci ve ilgili belgeler, standartlara dayalı olmalıdır. Buna örnek olan standartlardan biri, konfigürasyon yönetimi planları için standart tanımlayan IEEE 828-1983’tür. Bir organizasyon içerisinde bu standartlar bir konfigürasyon yönetim el kitabında veya bir kalite kitabının bir parçası olarak yayınlanmalıdır. Dışsal standartlar, özel çevrelere uyarlanan daha detaylı organizasyonel standartlar için temel olarak alınabilir. Tüm standartlar karşılaştırılabilir süreçler içerdikleri için başlangıç noktası olarak hangi standardın alındığı o kadar önemli değildir. Hem ISO 9000 standartlarında hem de SEI’nin Yetenek Olgunluk Modeli’nde (Capability Maturity Model) organizasyonlar, kalite belgelendirilmesi için resmi CM standartları tanımlamalı ve takip etmelidir.
Şelale modeline dayalı geleneksel bir yazılım geliştirme sürecinde, yazılım, geliştirme tamamlandıktan ve ayrışık yazılım parçaları test edildikten sonra konfigürasyon yönetim takımına verilir. Daha sonra bu takım, sistem inşasını tamamlama ve sistem testini yönetme sorumluluğunu alır. Sistem testi sırasında belirlenen hatalar, giderilmeleri için geliştirme takımına iletilirler. Hatalar giderilir ve düzeltilmiş parçacığın yeni versiyonu CM takımına iletilir.
Bu yaklaşım, konfigürasyon yönetimi standartlarının geliştirilmesini etkilemiştir ve bu standartlar, sistem geliştirimi için yazılım sürecinin şelale modeli kullanılacağına dair gömülü bir varsayıma sahiptir. Bu, standartların, evrimsel geliştirme (evolutionary development) veya arttırmalı geliştirme (incremental development) gibi alternatif yaklaşımlara doğrudan uygulanamaz anlamına gelmektedir. Bu stil geliştirmeyi cater etmek için bazı organizasyonlar concurrent geliştirmeyi ve sistem testini destekleyen modifiye edilmiş bir konfigürasyon yönetimi yaklaşımı geliştirmişlerdir. Bu yaklaşım, tüm sistemin parçalarından düzenli olarak (genellikle günlük) inşasına dayanır:
1. Geliştirme organizasyonu, sistem parçaları için teslim süresi (mesela saat 14) belirler.
2. Tam bir sistemin oluşturulması için bu parçaların derlenmesi ve bağlanmasıyla sistemin yeni bir versiyonu oluşturulur.
3. Daha sonra bu sistem, önceden tanımlanmış bir dizi sistem testini uygulayan test takımına iletilir. Aynı anda, geliştiriciler, parçalarının üzerinde çalışmaya devam ederler, fonksiyonellik eklerler ve önceki testlerde belirlenen hataları giderirler.
4. Sistem testi sırasında belirlenen hatalar belgelenirler ve sistem geliştiricilere iletilirler. Bu hatalar, parçanın bir sonraki versiyonunda giderilirler.
Yazılımın günlük oluşturulmasının avantajlarının en önemlisi, parçaların etkileşimlerinden oluşan hataların, sürecin erken dönemlerinde bulunma şansının arttırılmasıdır. Bundan öte, günlük oluşturma parçaların birim testlerinin “thorough” olmasını sağlar. Psikolojik olarak geliştiriciler, oluşumu bozmama (not to break the build) konusunda baskı altındadırlar; yani sistemin çökmesine sebep olabilecek parçaları teslim etmemelidirler. Bu yüzden tam olarak test edilmemiş yeni parça versiyonlarını teslim etme konusunda “reluctant”dırlar. Birim testinde olması gerekenden daha az sistem test süresi yazılım hatalarının bulunması ve “coping” edilmesine harcanır.
Günlük oluşturmaların başarısı, bulunan ve düzeltilen hataların kaydını tutan çok “stringent” bir değişim yönetim sürecini gerektirir. Bunun yanında yönetilmesi gereken çok sayıda sistem ve parça versiyonlarına sebep olur.
Konfigürasyon
Yönetimi Planlaması
Bir konfigürasyon yönetim planı, konfigürasyon yönetimi için kullanılması gereken standartları ve prosedürleri tanımlar. Planın geliştirilmesi için başlangıç noktası; genel, şirkete yaygın bir konfigürasyon yönetim standartları kümesi olmalı ve bunlar her proje için adapte edilmelidirler. CM planı birkaç bölümde organize edilmeli ve aşağıdakileri içermelidir.
1. Hangi elemanların yönetileceğinin tanımı ve bu elemanların tanımlanması için bir şema.
2. CM prosedürleri ve kontrol edilmiş elemanların CM takımına teslimi için kimin sorumluluk aldığını gösteren bir deyim (statement).
3. Değişim kontrolü ve versiyon yönetimi için kullanılan CM politikaları.
4. Değiştirilmesi gereken (should be maintained) CM sürecinin kayıtları.
5. CM için kullanılan araçların ve bu araçlar kullanılırken uygulanması gereken sürecin tanımı.
6. Konfigürasyon bilgilerinin kaydedilmesi için kullanılan konfigürasyon veri tabanının tanımı.
Dışsal sağlayıcılardan gelen yazılımların yönetimi ve CM süreci prosedürlerinin “auditing” edilmesi gibi diğer bilgiler de CM planında kapsanabilirler.
CM planının önemli bir kısmı, sorumlulukların tanımlanmasıdır. Her belgenin veya yazılım parçasının kalite güvenliği ve konfigürasyon yönetimine tesliminden kimin sorumlu olduğu tanımlanmalıdır. Her belgenin tekrar gözden geçiricileri de tanımlanabilir. Belge teslimiyle sorumlu kişi, belgeyi üreten kişiyle aynı olmak zorunda değildir. Ara yüzleri basitleştirmek için, proje yöneticilerini veya takım liderlerini takımlarının ürettiği belgelerin sorumlusu yapmak kullanışlıdır.
Büyük bir yazılımın geliştirilmesi süresince binlerce belge üretilir. Bunların çoğu, ilerideki geliştirmeler için fikir veren teknik belgelerdir. Bu belgeler, sık ve düzenli değişikliklerle ilgilidirler. Diğerleri, ofis içi notlar, grup toplantılarının dakikaları, plan içerikleri vs.’dir. Bu belgeler, bir projenin tarihiyle ilgili olabilirler. Bunun yanında bunlar, sistemin gelecek değişiklikleri için gerekli değillerdir.
Konfigürsyon yönetimi planlaması süreci sırasında, hangi varlıkların kontrol edileceğine karar verilir. Konfigürasyon kontrolü altındaki belgeler veya ilişkili belge grupları, resmi belgeler veya konfigürasyon varlıklarıdır. Proje planları, tanımlamalar, tasarımlar, programlar ve test verileri konfigürasyon varlıkları olarak nitelendirilirler. Bunun yanında sistemin gelecekteki değişiklikleri için gerekli olan tüm belgeler kontrol edilmelidir.
Belge isimlendirme şeması, konfigürasyon kontrolü altındaki tüm belgelere unique bir isim vermelidir. Bu belgeler arasında daima ilişkiler vardır. Mesela tasarım belgeleri, programlarla ilişkilendirileceklerdir. Bu ilişkiler, ilişkili belgelerin aynı kök ismine sahip oldukları bir isimlendirme şemasıyla, örtülü olarak kaydedilebilirler. Bu, aşağıdaki gibi örneklendirilebilecek hiyerarşik bir isimlendirme şeması oluşturur:
PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE
PCL-TOOLS/EDIT/HELP/QUERY/HELPFRAMES/FR-1
İsmin ilk kısmı proje ismidir (PCL-TOOLS). Bu projede dört ayrı araç vardır. Bu aracın ismi, ismin bir sonraki kısmı olarak kullanılmıştır. Her araç, farklı isimlendirilmiş modüllerden oluşmaktadır. Bu ayrıştırma, temel seviyede resmi belgelere erişilinceye kadar devam eder. Belgeleme hiyerarşisinin yaprakları, resmi proje belgeleridir. Şekil 29.2, her yönetilen eleman için üç resmi belgeye ihtiyaç duyulduğunu göstermektedir. Bunlar; bir nesne tanımı (OBJECTS), parçanın kodu (CODE) ve bu kod için bir grup test (TESTS).
Şekil 29.2 Konfigürasyon Hiyerarşisi
Bu tür isimlendirme şemalarının sorunu, proje tabanlı olmalarıdır. Tanımlayıcılar, parçalarla bir belli bir projeyi ilişkilendirirler. Bu, yeniden kullanılabilirlik olasılığını azaltabilir. Yeniden kullanılabilir parçaların kopyaları böyle bir şemadan çıkarılabilmeli ve uygulama domainine göre yeniden adlandırılabilmelidir. Diğer problemler eğer belge isimlendirme şeması, yönetilmiş parçaların saklanması için depolama yapısının tasarımında doğrudan temel alınarak kullanılırsa ortaya çıkabilir. Artık belgelerin kullanıcıları, belgelerin isimlerini bilmek zorunda kalırlar ve aynı tipteki tüm belgeler (mesela tasarım belgeleri) bir arada bir yerde tutulmazlar. İsimlendirme şeması ile versiyon yönetiminin kullandığı tanımlama şeması arasında ilişki kurmada da problemler çıkabilir.
Konfigürasyon Veri
Tabanı
Konfigürasyon veri tabanı, konfigürasyonlarla ilgili tüm relevant verileri kaydetmek için kullanılır. Temel fonksiyonları, sistem değişikliklerinin etkilerini azaltmak ve CM süreci hakkında yönetim bilgisi sağlamaktır. Konfigürasyon veri tabanının şemasını tanımlamak kadar, proje bilgilerinin kaydedilmesi ve bulunması için prosedürler de CM planlama sürecinin parçası olarak tanımlanmalıdır.
Bir konfigürasyon veri tabanı, sistem konfigürasyonları hakkında bir dizi sorguya cevaplar sağlamak zorundadır. Tipik sorgular:
1. Sistemin belli bir versiyonunu hangi müşteriler almıştır?
2. Verilen bir sistem versiyonunun çalıştırılması için hangi donanım ve işletim sistemi konfigürasyonu gerekmektedir?
3. Bir sistemin kaç versiyonu oluşturulmuştur ve oluşturulma tarihleri nedir?
4. Belli bir parça değiştirilirse, sistemin hangi versiyonları etkilenir?
5. Belli bir versiyon için kaç değişiklik isteği beklemektedir?
6. Belli bir versiyon için kaç hata bildirilmiştir?
İdeal olarak, konfigürasyon veri tabanı, resmi proje belgelerinin saklanıp yönetildiği versiyon yönetim sistemi ile tümleştirilmelidir. Bazı CASE araçlarıyla desteklenen bu yaklaşım, değişiklik ile etkilenen belge ve parçaların doğrudan bağlanmasına olanak tanır. Tasarım belgeleri gibi belgeler arasındaki bağlantılar, ve program kodu, bir değişiklik gerektiğinde, değişmesi gereken her şeyin göreceli olarak daha kolay bulunmasını sağlar.
Bunun yanında bir çok firma, konfigürasyon yönetimi için tümleşik CASE araçlarını kullanmazlar fakat; konfigürasyon veri tabanlarını ayrı bir sistem gibi değiştirirler. Konfigürasyon varlıkları, dosyalarda veya Unix’te iyi bilinen bir versiyon yönetim sistemi olan RCS gibi versiyon yönetim sistemlerinde saklanabilirler. Bu konfigürasyon veri tabanı, konfigürasyon varlıklarını saklar ve versiyon yönetim sistemindeki dosya isimlerine referans tutarlar. Bu göreceli olarak ucuz ve esnek bir yaklaşım iken; dezavantajı, konfigürasyon varlıklarının, konfigürasyon veri tabanından gitmeden değiştirilebilirler. Bu yüzden konfigürasyon veri tabanının sistemin güncel bir tanımı olduğundan emin olunamaz.
Değişiklik Yönetimi
Değişim, büyük yazılım sistemleri için bir yaşam gerçeğidir. Önceki bölümlerde anlatıldığı gibi, bir sistemin yaşam süresi boyunca organizasyonel ihtiyaçlar ve gereksinimler değişmektedir. Bu gereken değişikliklerin yazılıma yapılmasını gerektirir. Tanımlanmış bir değişim yönetim süreci ve ilgili CASE araçları, bu değişikliklerin sisteme maliyet açısından verimli olarak uygulanıp kaydedilmesini sağlarlar.
Değişim yönetim süreci (Şekil 29.3), yazılım veya ilgili belgele konfigürasyon yönetim takımının kontrolü altına verildiği zaman ortaya çıkar. Sistem testi sırasında veya yazılım müşteriye teslim edildikten sonra başlar. Değişim yönetim prosedürleri, değişimin gelir ve giderlerinin doğru olarak analiz edilmesi ve değişikliklerin sisteme kontrollü bir şekilde yapılmasının sağlanması için tasarlanmalıdırlar.
Değişiklik istek formu tamamlayarak değişiklik iste
Değişiklik isteğini analiz et
Eğer değişiklik geçerli ise
Değişikliğin nasıl gerçekleştirileceğine değer biç
Değişiklik maliyetine değer biç
Değişiklik isteğini veri tabanına kaydet
İsteği değişiklik kontrol kuruluna bildir
Eğer değişiklik kabul edildi ise
Tekrarla
Yazılıma değişiklikleri yap
Değişiklikleri kaydet ve ilgili değişiklik isteğine bağla
Değiştirilmiş yazılımı kalite onayı için bildir
Yazılım kalitesi yeterli olana kadar
Yeni sistem versiyonunu oluştur
Değilse
Değişiklik isteğini reddet
Değilse
Değişiklik isteğini reddet
Şekil 29.3 Değişiklik Yönetim Süreci
Değişim yönetim sürecindeki ilk kısım, isteklinin sisteme yapılması gereken değişikliği bildirmesi için kullanılan değişiklik isteği formunun (change request form – CRF) doldurulmasıdır. CRF, gerekli değişikliğin kaydedilmesi kadar, değişiklikle ilgili tavsiyeleri, değişikliğin tahmini maliyetini ve değişikliğin istendiği, onaylandığı, gerçekleştirildiği ve geçerlileştirildiği tarihleri de kaydeder. Ayrıca, değişiklik mühendisinin, değişikliğin nasıl gerçekleştirdiğinin ana hatlarını anlattığı bir kısım da içerebilir. Değişiklik istekleri, konfigürasyon veri tabanına kaydedilmelidir. Böylece CM takımı, değişiklik isteklerinin durumlarını ve belli bir yazılım parçasıyla ilgili değişiklik isteklerini takip edebilirler.
Bir kısmı doldurulmuş örnek bir değişiklik istek formu şekil 29.4’te görülmektedir. Değişiklik istek formu, genellikle CM planlama süreci sırasında tanımlanır. Genellikle hükümet kontratları gibi bazı kontratlar için, değişiklik istek formu, tanımlanmış bir istemci standardına uymalıdır.
Bir değişiklik istek formu verildikten sonra, değişikliğin geçerli olduğunun kontrolü için analiz edilir. Bazı değişiklik istekleri, sistem hatalarından değil de yanlış anlamalar yüzünden verilirken, diğerleri ise önceden bilinen hataları tekrar bildirir. Eğer analiz değişiklik isteğinin gereksiz olduğunu, iki kere verildiğini veya önceden halledilmiş olduğunu keşfederse, değişiklik isteğini reddetmelidir. Reddedilme için sebep, değişiklik isteğinin sahibine bildirilmelidir.
Geçerli değişiklikler için, sürecin bir sonraki kısmı, değişiklik değer biçimi ve maliyettir. Değişikliğin, sistemi geri kalanındaki etkisi kontrol edilmelidir. Değişikliğin nasıl gerçekleştirileceği ile ilgili bir teknik analiz yapılmalıdır. Değişikliği yapmanın ve diğer sistem parçalarının olası değişikliğinin maliyeti tahmin edilmelidir. Bu, değişiklik istek formuna kaydedilmelidir. Değer biçimi süreci, parça ilişkilerinin tutulduğu konfigürasyon veri tabanını kullanabilir. Böylece değişikliğin diğer sistem parçalarına etkisi göz önüne alınabilir.
Değişiklik, basitçe ekrandaki veya belgelerdeki küçük hatalarla ilgili olmadıkça, kabul edilip edilmeyeceğine karar veren değişiklik kontrol kuruluna bildirilmelidir. Değişiklik kontrol kurulu, değişikliğin etkisini teknik açıdan çok, stratejik ve organizasyonel açıdan ele alır. Eğer değişiklik ekonomik olarak uygunsa ve değişikliğin kabul edilmesi için iyi sebepler varsa değişiklik kabul edilir.
Değişiklik kontrol kurulu, çok resmi görünmektedir. Değişiklik kararlarını veren büyük grup için kullanılır. Yetişkin istemcileri ve müteahhitleri içeren resmi olarak oluşturulmuş değişiklik kontrol kurulları, askeri projelerin gereksinimidir. Küçük ve orta boylu projeler için, değişiklik kontrol kurulu, basitçe bir proje yöneticisi ve bir veya iki doğrudan yazılım geliştirmeyle uğraşmaya mühendisten oluşabilir. Bazı durumlarda, değişiklikler hakkında tavsiye verebilen sadece bir değişiklik gözden geçiricisi bulunabilir.
Bir dizi değişiklik onaylandığı zaman, yazılım, gerçekleştirim için geliştirme veya değişiklik takımına iletilir. Bunlar tamamlandıktan sonra, gözden geçirilmiş yazılım, değişikliklerin doğru olarak gerçekleştirildiğinin kontrolü için yeniden onaylanır. Sistem geliştiricilerden çok, CM takımı yazılımın yeni versiyonunu veya sürümünü oluşturur.
Günlük sistem oluşturmalarla sistemin yeni versiyonları oluşturulduğunda, daha basit bir değişim yönetim süreci kullanılır. Problemler ve değişiklikler hala kaydedilmelidirler fakat; değişiklikler sadece bağımsız parçacıkları etkilerler ve modüllere ayrıca değer biçilmesine gerek yoktur. Doğrudan sistem geliştiricilere geçirilirler. Kabul ederler veya niçin gereksiz olduğunu belirten bir sebep öne sürerler. Farklı geliştirme takımları tarafından üretilen ve sistem modüllerini etkileyen değişikliklere, hala gerçekleştirime karar veren bir çeşit değişiklik kontrol yetkilisi değer biçmelidir.
Yazılım parçaları değiştikçe, her parçaya yapılan değişikliğin kaydı da değiştirilmelidir. Bu bazen bir parçacığın türetme tarihi (derivation history) olarak adlandırılır. Böyle bir kaydı değiştirmenin en iyi yolu, parçanın başında bulunan bir standartlaştırılmış yorum prologue’dur (bkz. Şekil 29.5). Bu, yazılım değişikliği ile ilişkili değişiklik isteğine başvuru niteliğinde olmalıdır. Özelleştirilmiş araçlar, türetme tarihini işlemek ve bileşen değişiklikleri hakkında raporlar üretmek için kullanılabilirler.
Versiyon ve Sürüm
Yönetimi
Versiyon ve sürüm yönetimi, sistemin farklı versiyon ve sürümlerinin kayıtlarının tutulması ve tanımlanması sürecidir. Versiyon yöneticileri, gerektiğinde sistemin farklı versiyonlarının bulunabilmesi ve kazara değiştirilmemeleri için prosedürler geliştirirler. Ayrıca sistemin yeni sürümlerinin ne zaman dağıtılacağını planlamak için müşterilerle de çalışabilirler. Dışarıya sunum için olmasa bile, yeni sistem versiyonları, sistem geliştiriciler tarafından değil de CM takımı tarafından oluşturulmalıdırlar. Bu, sadece CM takımı versiyon bilgisini değiştirebileceği için, konfigürasyon veri tabanının tutarlılığına yardımcı olur.
Bir sistem versiyonu, bir şekilde diğer sistem örneklerinden ayrılan bir sistem örneğidir. Sistemin yeni versiyonları, farklı fonksiyonlara, performansa sahip olabilir veya hataları giderebilir. Bazı versiyonlar aynı fonksiyonlara sahip olabilir fakat farklı yazılım ve donanım konfigürasyonları için tasarlanmış olabilir. Versiyonlar arasında çok küçük farklar varsa, “variant” olarak adlandırılabilir.
Bir sistem sürümü, müşterilere dağıtılan versiyondur. Her sistem sürümü ya yeni bir fonksiyon ya da yeni bir donanıma uyum içermelidir. Versiyonlar, organizasyon içerisinde geliştirme veya test amaçlı üretilip müşterilere sunulmadığı için, versiyon sayısı sürüm sayısından çok daha fazladır.
Versiyon yönetimi, şimdi daima CASE araçları ile desteklenmektedir. Bu araçlar her sistem versiyonunun saklanmasını yönetirler ve sistem parçalarına erişimi kontrol ederler. Yazım için sistemden işaretlenmelidirler. Sisteme tekrar girildiğinde, versiyon yönetim sistemi tarafından yeni bir versiyon oluşturulur ve isimlndirilir.
Versiyon Tanımlama
Büyük bir yazılım sisteminde, her biri farklı versiyonlar halinde bulunan yüzlerce yazılım parçası vardır. Versiyon yönetimi için prosedürler, her parça versiyonunu ayrı olarak tanımlamalıdır. Sonraki değişiklikler için gerekli belli parça versiyonları tekrar elde edilebilir.
Parça tanımlama için üç temel teknik vardır:
1. Versiyon Numaralama: Parçaya dışsal ve unique bir versiyon numarası verilir. Bu en çok kullanılan tanımlama şemasıdır.
2. Öz Niteliğe Dayalı Tanımlama: Her parça bir isme sahiptir (versiyonlar arası unique olmayan) ve her versiyonda farklılık gösteren bir dizi öz nitelikle ilişkilidir. Bu yüzden parçalar isim ve öz niteliklerle beraber tanımlanırlar.
3. Değişikliğe Dayalı Tanımlama: Her sistem, öz niteliğe dayalı tanımlamadaki gibi isimlendirilir fakat bunun yanında bir veya daha fazla değişiklik isteği ile de ilişkilendirilir. Sistem versiyonu, isim ile parçacıkta gerçekleştirilen değişikliklerin ilişkilendirilmesiyle tanımlanır.
Basit bir versiyon numaralama şemasında, parça veya sistem ismi, bir versiyon numarası ile tanımlanır. Böylece Solaris 2.6 (Solaris sisteminin 2.6 versiyonu) ve getToken’in 1.4 versiyonu denebilir. İlk versiyon 1.0 olarak adlandırılabilirken, devam edenleri 1.1, 1.2 ... diye adlandırılabilirler. Bir seviyeden sonra yeni bir sürüm oluşturulur (sürüm 2.0) ve süreç yine versiyon 2.1, 2.2 olarak başlar. Şema, sistem versiyonlarının sırayla oluşturulduğu varsayımına dayanır. Bir çok versiyon yönetim aracı (RCS gibi), versiyon tanımlama için bu yaklaşımı destekler.
Bu yaklaşım ve sistemin önceki versiyonlarından bir dizi farklı sistem versiyonunun türetilmesi, Şekil’da gösterilmektedir. Bu diyagramdaki oklar, kaynak versiyondan, oluşturulan yeni sistem versiyonuna işaret ederler. Türetmelerin doğrusal olmasının gerekli olmadığına dikkat edilmeli ve art arda versiyon numarasına sahip sistemlerin farklı base line’lardan oluşabildiğine de dikkat edilmelidir. Şekilde versiyon 2.2, versiyon 2.1’den değil de versiyon 1.2’den oluşturulmuştur. Prensipte, her hangi bir versiyon, sistemin yeni bir versiyonu için başlangıç noktası olarak alınabilir.
Bu şema basit olmasına rağmen, versiyonlar arasındaki farkların ve ve versiyonlar ile sistem değişiklik proposallarının arasındaki ilişkilerin tutulabilmesi için büyük miktarda bilgi yönetimi gerekir. Bu yüzden gerektiğinde özellikle konfigürasyon veri tbanı ve sistemin saklı versiyonları arasında tümleşik bağlar yoksa, belli bir sistem veya bileşen versiyonunu bulmak zordur.
Dışsal versiyon isimlendirme şemalarıyla ilgili temel bir problem, versiyonları tanımlamak için kullanılabilecek bir çok farklı özelliği yansıtmamalarıdır. Bu tanımlayıcı özellikler:
Eğer bir versiyon unique bir grup özellikle tanımlanıyorsa, var olan versiyonlardan yeni bir versiyon oluşturmak kolaydır. Bunlar, unique bir özellik değerleri dizisiyle tanımlanırlar. Üretildikleri versiyonla çoğu değeri paylaşırlar, böylece versiyonlar arası ilişkiler değiştirilebilir olurlar. Versiyonlar, gerekli özellik değerleri belirtilerek bulunabilir. Özellikler üzerindeki fonksiyonlar, “son oluşturulan versiyon”, “verilen tarihler arasında oluşturulan versiyon” gibi sorguları desteklerler. Örnek olarak, yazılım sistemi AC3D, java’da oluşturulmuş, Windows NT için tasarlanmış ve Ocak 1999’da yaratılmışsa,
AC3D (language=Java, platform=NT4, date=Jan1999)
olarak belirtilebilir.
Özelliğe dayalı tanımlama, doğrudan versiyon yönetim sistemi tarafından gerçekleştirilebilir. Daha genel olarak, saklı bir versiyon isimlendirme şemasının tepesinde gerçekleştirilmiştir ve konfigürasyon veri tabanı, alttaki sistem ve parça versiyonları ile özellikleri tanımlama arasındaki bağları değiştirir.
Özelliğe dayalı sistem versiyonu tanımlaması, basit numaralama şemasının bazı problemlerini giderir. Bunun yanında bir versiyonun bulunması için, hala ilgili özelliklerin bilinmesi gerekir. Bundan öte, versiyonlar ve değişiklikler arasındaki ilişkilerin bulunması için ayrı bir değişiklik yönetim sistemi kullanılmalıdır.
Değişikliğe dayalı tanımlama, bileşenlerden çok sistemler için kullanılırlar, böylece farklı bileşen versiyonları CM sisteminin kullanıcılarından saklanır. Her sistem değişikliği, değişikliğin gerçekleştirilmesi için farklı sistem bileşenlerine yapılan değişiklikleri tanımlayan değişiklik kümesine sahiptir. Değişiklik kümeleri, sırayla uygulanabilirler ve böylece en azından prensipte, sistemin her hangi bir değişiklik kümesiyle etkileşen bir versiyonu oluşturulabilir. Bu yüzden dışsal bir versiyon tanımı gerekli değildir. CM takımı, değişiklik yönetim sisteminden dolaylı olarak versiyon yönetim sistemiyle etkileşir.
Pratikte, bir sisteme gelişi güzel değişiklik kümeleri uygulanması mümkün değildir. Farklı değişiklik kümeleri uyumsuz olabilir; yani değişiklik kümesi A’yı uyguladıktan sonra değişiklik kümesi D’yi uygulamak, geçersiz bir sistem oluşturabilir. Bundan öte, değişiklik kümeleri, farklı değişikliklerin sistemin aynı kodunu etkilemesi gibi çakışmalara sebep olabilirler. Bu zorlukları belirlemek için, değişikliğe dayalı tanımlamayı destekleyen versiyon yönetim araçları, değişiklik kümelerinin birleştirilmesini sınırlayan tutarlılık kuralları tanımlarlar.
Sürüm Yönetimi
Bir sistem sürümü, müşterilere dağıtılan bir sistem versiyonudur. Sistem sürüm yöneticileri, sistemin ne zaman müşterilere sunulacağına, sürüm yaratımı sürecinin yönetilmesini ve dağıtım ortamı ile gerekli olduğunda dağıtılan sistemin tamamen aynısının oluşturulabilmesi için gerekli belgelerin oluşturulmasını yerine getirirler.
Bir sistem sürümü, sadece çalıştırılabilir kod değildir. Sürüm, aşagıdakileri de içermelidir:
1. Belli yüklemeler için sürümün nasıl konfigüre edileceğini tanımlayan konfigürasyon dosyaları.
2. Başarılı sistem çalışması için gerekli veri dosyaları.
3. Hedef donanıma sistemin yüklenmesine yardımcı olan yükleme programı.
4. Sistemi tanımlayan elektronik ve kağıt belgeler.
5. Sürüm için tasarlanmış paket ve ilgili yayınlar.
Sürüm yöneticileri, müşterilerin daima yeni sistem sürümlerini yükleyeceklerini düşünmemelidirler. Bazı sistem kullanıcıları, var olan sistem versiyonundan memnun olabilirler. Yeni bir sürüme geçişin, maliyete değmeyeceğini düşünebilirler. Bu yüzden yeni sistem sürümleri, eski sürümlerin varlığına bağlı olmamalıdırlar. Aşağıdaki durumu inceleyiniz:
1. Sistemin sürüm 1’i dağıtılmış ve kullanıma koyulmuştur.
2. Yeni veri dosyalarının yüklenmesini gerektiren sürüm 2 sunulmuş fakat bazı müşteriler sürüm 2’nin sunduklarına ihtiyaç duymamaktadırlar ve sürüm 1’de kalmışlardır.
3. Sürüm 3, sürüm 2’nin veri dosyalarına ihtiyaç duymaktadır ve kendi yeni veri dosyası yoktur.
Yazılım dağıtıcısı, sürüm 3 için gerekli dosyaların tüm sitelerde önceden yüklenmiş olduğunu kabul edemez. Bazı siteler, sürüm 2’yi atlayarak doğrudan sürüm 1’den sürüm 3’e geçiş yapmış olabilirler. Bazı siteler, yerel durumları sebebiyle, sürüm 2’nin veri dosyalarını değiştirmiş olabilirler. Bu yüzden veri dosyaları, sistemin 3. Sürümüyle dağıtılmalı ve yüklenmelidir.
Bir sistem sürümünü hazırlamak ve dağıtmak, özellikle büyük ticari yazılım ürünleri için pahalı bir süreçtir. Eğer sürümler çok sıksa, müşteriler yeni sürüme geçmeyebilirler; eğer çok seyrekse, müşteriler alternatif sistemlere yönelecekleri için Pazar payı kaybedilebilir. Bu, tabi ki bir organizasyon için özel hazırlanan yazılımlar için gerekli değildir. Bunun yanında, bu tip yazılımlar için, seyrek olarak çıkarılan sürümler, yazılım ile yazılımın desteklenmesi gereken iş süreci arasındaki ayrıklığın artması anlamına gelebilir.
Bir sistemin yeni bir versiyonunun ne zaman sunulacağına dair kararlar, teknik ve organizasyonel şartlar göz önüne alınarak verilmelidir. Şekil 29.7, bu konudaki etkenleri göstermektedir.
Etken Tarif
Sistemin teknik kalitesi Bir çok müşterinin sistemi kullanma yolunu etkileyen ciddi sistem hataları bildirilirse, bir hata tamir sürümü çıkarmak gerekli olabilir. Bunun yanında, küçük sistem hataları, sistemin o anki sürümüne uygulanabilen yamalar (genellikle Internet’ten dağıtılan) çıkarılarak tamir edilebilir.
Lehman’ın beşinci kuralı Bu, her sürümde arttırılan fonksiyonelliğin yaklaşık olarak sabit olmasını önerir. Bu yüzden, dikkate değer yeni fonksiyonellikli bir sürüm çıkarılırsa, bu, bir tamir sürümüyle takip edilir.
Yarışma Yarışan bir ürün çıktığı için yeni bir sürüm gerekli olabilir.
Pazarlama gereksinimleri Bir organizasyonun pazarlama bölümü, brelli bir tarihte sürümlerin sunulması için yaptırımda bulunabilir.
Müşteri değişiklik istekleri Özelleşmiş sistemler için, müşteriler belli değişiklik isteklerinde bulunmuş ve ödemiş olabilirler ve bu isteklerin gerçekleştirildiği sürümün mümkün olduğunca çabuk sunulmasını beklemektedirler.
Sürüm oluşturma, sistem sürümünün tüm bileşenlerinin içermesi gereken dosya ve belgelerin oluşturulma sürecidir. Programın çalıştırılabilir kodu ve ilişkili tüm veri dosyaları toplanmalı ve tanımlanmalıdır. Konfigürasyon tarifleri, farklı işletim sistemleri ve donanımlar ve kendi sistemlerini konfigüre etme ihtiyacı duyan müşteriler içim yazılmalıdır. Eğer makine-okunabilir (machine-readable) el kitapçıkları dağıtılmışsa, elektronik kopyaları yazılımla birlikte saklanmalıdır. Yükleme programı için script yazılmalıdır. Son olarak tüm bilgi erişilebilir olduğunda, bir ana disk hazırlanır ve dağıtım için teslim edilir.
Sistem sürümleri için normal dağıtım ortamı, şu an 600 Mbyte’a kadar veri depolayabilen CD-ROM disklerdir. Buna ek olarak bir çok yazılım ürünü, Internet’ten erişilebilecek şekilde sunulurlar ve müşteriler indirebilirler. Bunun yanında, çoğu insan büyük dosyaları indirmenin aldığı süreyi çok uzun bulurlar ve CD-ROM dağıtımı tercih ederler.
Bir sistem sürümü üretildiğinde, gelecekte tamamen aynı şekilde üretilebilmesi için belgelenmelidir. Bu özellikle custumized, uzun ömürlü gömülü sistemler için önemlidir. Müşteriler bu sistemlerin tek bir sürümünü uzun yıllar kullanabilir ve belli bir yazılım sürümü için orijinal sürüm tarihinden çok sonra özel değişikliklere gereksinim duyabilirler.
Bir sürümü belgelemek için, çalıştırılabilir kodu oluşturmak için kullanılmış olan kaynak kod bileşenlerinin belirli versiyonları kaydedilmelidir. Ayrıca kaynak ve çalıştırılabilir kodun ve tüm veri ve konfigürasyon dosyalarının kopyaları da saklanmalıdır. Ayrıca işletim sisteminin, kütüphanelerin, derleyicilerin ve yazılımın oluşturulmasında kullanılan diğer araçların versiyonları da kaydedilmelidir. Bunlar, sistemin daha sonraki bir tarihte tamamen aynısının oluşturulabilmesi için gerekli olabilirler. Böyle durumlarda platform yazılımının ve araçların kopyaları da versiyon yönetim sisteminde saklanmalıdır.
Sistem Oluşturma
Sistem oluşturma, yazılım bileşenlerinin belli bir hedef konfigürasyonda çalışan bir program içine derlenmesi ve bağlanması sürecidir. Bir sistemi bileşenlerinden oluştururken, aşağıdaki sorular hakkında düşünülmesi gerekmektedir:
1. Oluşturma komutlarında, sistemi oluşturan tüm bileşenler kapsanmış mıdır?
2. Oluşturma komutlarında, gerekli her bileşenin uygun versiyonu kapsanmış mıdır?
3. Gerekli tüm veri dosyaları erişilebilir midir?
4. Veri dosyalarına bir bileşen içinden başvuruluyorsa, kullanılan isim, hedef makinedeki veri dosyasının ismiyle aynı mıdır?
5. Derleyicinin ve gerekli diğer araçların uygun versiyonları erişilebilir mi? Yazılım araçlarının şu anki versiyonları, sistemin geliştirildiği eski versiyonlarla uyumsuz olabilir.
Son günlerde, CM araçları, sistem oluşturma sürecini otomize etmek için kullanılmaktadırlar. CM takımı, sistemin farklı bileşenleri arasındaki bağımlılıkları tanımlayan bir oluşturma scripti yazar. Ayrıca sistem bileşenlerinin derlenmesinde ve bağlanmasında kullanılan araçları da belirtirler. Sistem oluşturma aracı, oluşturma scriptini yorumlar (interpret) ve çalışabilir sistemin oluşturulabilmesi için gerekli diğer programları çağırır.
Bileşenler arasındaki bağımlılıklar, oluşturma scriptlerinde belirtirlirler, böylece sistem oluşturma sistemi, bileşenlerin ne zaman yeniden derlenmesi gerektiğine ve ne zaman var olan nesne kodlarının yeniden kullanılabileceğine karar verebilir. Oluşturma scriptleri, bağımlılıkları genelde içinde kaynak kod bileşenlerinin saklandığı dosyalar arasındaki bağımlılıklar şeklinde belirtirler. Bunun yanında bileşenlerin farklı versiyonlarını temsil eden çoklu kaynak kod dosyaları olduğu zaman, nesne-kod bileşenlerini türetmek için hangi kaynak dosyalarının kullanıldığı bazen açık değildir. Bu karışıklık, kaynak ve nesne kod dosyaları arasındaki eşlemenin, kaynak ve nesne kod dosyalarının aynı isme fakat farklı uzantıya sahip olmalarına (örnek: .c ve .o) dayandığı zaman ortaya çıkar.
Fiziksel dosya bağımlılıklarının bazı zorluklarından kaçınmak için, modül tanımlama dillerine dayalı bazı deneysel sistemler üretilmişlerdir. Bunlar, mantıksal yazılım yapısının tarifini kullanırlar ve kaynak kod bileşenlerini içeren dosyalar arasındaki bağımlılığı infer etmek için bir depolama yapısına haritalama kullanırlar. Bu yaklaşım, hata için alanı daraltır ve sistem oluşturma sürecinin daha anlaşılabilir tariflerini sağlar.
Konfigürasyon
Yönetimi İçin CASE Araçları
Konfigürasyon yönetim süreçleri, genellikle standartlaştırılmışlardır ve önceden tanımlamış prosedürlerin uygulanması ile ilgilidirler. Çok büyük miktarda verinin dikkatli yönetimini gerektirirler ve ayrıntılara dikkat etmek gereklidir. Bir sistemi bileşen versiyonlarından oluştururken, ek bir konfigürasyon yönetimi hatası, yazılı doru çalışmayacağı anlamına gelebilir. Bu yüzden konfigürasyon yönetimi için CASE araç desteği gereklidir ve 190lerden beri, konfigürasyon yönetiminin farklı alanları ile ilgili çok sayıda farlı araç üretilmiştir.
İlk nesil CM araçlarının örnekleri arasında gözden geçirme kontrolü için SCCS ve RCS, sistem oluşturma için make bulunmaktadır. Bunlar, konfigürasyon yönetimi süreci içindeki belli etkinlikler için tek başına çalışabilen (stand-alone) araçlardır. Lifespan ve DSEE gibi ikinci nesil araçlar, bazı tümleşik CM süreci desteği sağlamışlardır fakat tüm CM etkinliklerini desteklememişlerdir. Yazım sırasında, konfigürasyon yönetimini, değişiklik yönetimini, versiyon yönetimini ve sistem oluşturmayı destekleyen tümleşik CASE araç kümeleri bulunmaktadır. Bununla beraber, bu tümleşik CM araç kümeleri karmaşık ve pahalıdırlar ve çoğu organizasyon hala birinci ve ikinci nesil CM araç desteğini kullanmaktadır.
Değişiklik Yönetimi
İçin Destek
Değişiklik yönetiminde rol alan herkes, bir etkinlikten sorumludur. Bu etkinliği tamamlarlar, formları ve ilgili konfigürasyon varlıklarını bir başkasına geçirirler. Bu surecin prosedüral doğası, bir değişiklik süreci modelinin tasarlanabileceği ve versiyon yönetim sistemi ile tümleştirilebileceği anlamına gelmektedir. Daha sonra bu model yorumlanabilir ve doğru belgeler, doğru insanlara, doğru zamanda geçirilebilir.
Bu yüzden, değişiklik yönetimi araçları, süreci desteklemek için aşağıdaki özellikleri sağlayabilirler:
1. Değişiklik bildirisi formlarının yaratılması ve doldurulması için bir form editörü.
2. CM takımının, değişiklik istek formunu kimlerin işleyeceğini ve işlemlerin sırasını belirtmesini sağlayan bir iş akış sistemi (workflow system). Bu sistem, otomatik olarak formları doğru insanlara doğru zamanda aktaracaktır ve değişiklik işleminin takımının ilgili üyelerini uyaracaktır. Elektronik posta, işlem ile ilgilenen insanlara işlemin güncellemelerinin bildirilmesi için kullanılır.
3. Tüm değişiklik isteklerinin yönetilmesi için kullanılan ve bir versiyon yönetim sistemine bağlanabilecek bir değişiklik veri tabanı. CM takımının belli değişiklik isteklerini bulmasını sağlayan sorgu özellikleri genellikle sğlanmıştır.
Versiyon Yönetimi
İçin Destek
Versiyon yönetimi, büyük miktarda verinin yönetimi ve sistem değişikliklerinin kaydedilmesi ve kontrol edilmesi ile uğraşır. Versiyon yönetim araçları, içeriği değiştirilemeyen bir konfigürasyon varlıkları deposunu kontrol ederler. Bir konfigürasyon varlığı üzerinde çalışmak için, varlık depodan bir çalışan klasöre işaretlenmelidir. İş tamamlandıktan sonra, varlık tekrar depoya girilir ve yeni bir versiyon otomatik olarak oluşturulur.
Tüm versiyon yönetim sistemleri, bazıları diğerlerinden daha detaylı özelliklere sahip olmalarına rağmen karşılaştırılabilir bir temel yetenek kümesi sağlarlar. Bu yeteneklerin örnekleri:
1. Versiyon ve sürüm tanımlama Yönetilen sistemler, sisteme bildirildiğinde, bunlara tanımlayıcılar atanır. Farklı sistemler, daha önce anlatılan farklı versiyon tanımlama tiplerini desteklerler.
2. Depolama yönetimi Büyük oranda aynı olan farklı versiyonların gereksinim duyduğu saklama alanını azaltmak için, versiyon yönetim sistemi, depolama yönetimi özellikleri sağlarlar, böylece, versiyonlar, bir ana versiyondan farklılıkları ile tariflenebilirler. Versiyonlar arasındaki farklar, ilgili sistem versiyonlarının yeniden oluşturulmaları için gerekli komutları saklayan bir delta ile gösterilirler. Bu, daha önceki sistem versiyonlarının yeniden yaratılması için son versiyona geriye dönük deltaların nasıl uygulanacağını gösteren şekil 29.9’da gösterilmiştir.
3. Değişiklik tarihi kaydedilmesi Bir sistem veya bileşen koduna yapılan tüm değişiklikler, kaydedilir ve listelenir. Bazı sistemlerde, bu değişiklikler belli bir sistem versiyonunu seçmek için kullanılabilir.
4. Bağımsız geliştirme Bir sistemin farklı versiyonları, paralel olarak geliştirilebilirler ve her versiyon bağımsız olarak değiştirilebilir. Örnek olarak, sürüm 1, sürüm 2’nin geliştirilmesi işleme konduktan sonra, yeni seviye 1 deltalar eklenerek değiştirilebilir. Versiyon yönetim sistemi, yazım için işaretlenen bileşenlerin kaydını tutar ve farklı geliştiriciler tarafından aynı bileşene yapılan değişikliklerin etkileşmemesini sağlar. Bazı sistemler sadece bir bileşen örneğinin yazım için işaretlenmesine izin verir; diğerleri, yazılan bileşenlerin tekrar sisteme işaretlenmesi sırasındaki olası çakışmaları çözer.
Sistem Oluşturma
İçin Destek
Sistem oluşturma, hesapsal olarak hassas bir süreçtir. Eğer büyük bir sistemin tüm bileşenleri derlenmeli ve bağlanmalıysa, bu birkaç saat alabilir. Eğer bunlar elle derleniyor ve bağlanıyorsa, olası insan hatalarıyla karşı karşıya kalan yüzlerce dosya vardır. Sistem oluşturma araçları, olası insan hatalarını azaltmak için oluşturma sürecini otomatikleştirir ve mümkün olduğunda, sistem oluşturma için gereken zamanı en aza indirir.
Sistem oluşturma araçları, Unix’in make özelliği gibi tek başlarına olabilirler veya versiyon yönetim araçlarıyla tümleştirilebilirler. Sistem oluşturma CASE araçları tarafından sağlanan özellikler, aşağıdakileri kapsayabilir:
1. Bir bağımlılık tanımlama dili ve ilgili yorumlayıcı Bileşen bağımlılıkları, tariflenebilir ve yeniden derleme en aza indirilebilir. Sonraki bölümde, bu konu, daha detaylı açıklanacaktır.
2. Araç seçimi ve örnekleme desteği Kaynak kod dosyalarını işlemek için kullanılan derleyiciler ve diğer işleyici araçlar, tanımlanabilir ve gerektiğinde örneklenebilir.
3. Dağıtık Derleme Bazı sistem oluşturucular, özellikle tümleşik CM sistemlerinin parçası olanlar, dağıtık, ağ derlemesini desteklerler. Tüm derlemelerin tek bir makine üzerinde gerçekleştirilmesindense, siste oluşturucu, ağda boş işlemcileri arar ve bir dizi paralel derleme kurar. Bu, sistem oluşturma için gereken zamanı büyük ölçüde azaltır.
4. Türetilmiş nesne yönetimi Türetilmiş nesneler, diğer kaynak nesnelerden yaratılan nesnelerdir. Türetilmiş nesne yönetimi, kaynak kodla türetilmiş nesneyi bağlar ve sadece kaynak kod değişiklikleri tarafından gereksinim duyulduğunda bir nesneyi yeniden türetir.
Türetilmiş nesnelerin yönetimi ve yeniden derlemenin en aza indirilmesi, en iyi olarak basit bir örnekle açıklanabilir. Comp adı verilen bir programın, scan.o, syn.o, sem.o ve cgen.o nesne modüllerinden oluşturulduğu bir durumu göz önüne alın. Her nesne modülü için, scan.c, syn.c, sem.c ve cgen.c adlı kaynak kod modülü bulunur. defs.h adlı, açıklamaların bulunduğu bir dosya, scan.c, syn.c ve sem.c tarafından paylaşılmaktadır oklar ‘-e bağlı’ (depends on) anlamına gelmektedir. Bu yüzden, comp; scan.o’ya, syn.o’ya, sem.o’ya bağlıdır ve cgen.o, scan.o; scan.c’ye bağlıdır vs.
Eğer scan.c değiştirilirse, sistem oluşturma aracı, türetilen nesne scan.o’nun yeniden oluşturulması gerektiğini belirleyebilir ve yeni bir scan.o türetilmiş nesnesinin oluşturulması için scan.c’nin derlenmesi için ilgili derleyiciyi çağırır. Daha sonra comp’un, scan.o’yu, syn.o’yu, sem.o’yu ve cgen.o’yu bağlayarak yeniden oluşturulması gerektiğini belirlemek için, comp ve scan.o arasındaki bağımlılık bağını kullanır. Sistem, diğer nesne kod bileşenlerinin değiştirilmediğini belirleyebilir yani, ilgili kaynak kodun yeniden derlenmesi gereksizdir.
Bazı sistem oluşturucular, yeniden derlemenin gerekli olup olmadığı konusunda karar vermek için ana öz nitelik olarak dosya değiştirme tarihini kullanır. Eğer bir kaynak kod dosyası, kendisine denk gelen nesne kod dosyasından sonra değiştirilmişse, nesne kod dosyası yeniden oluşturulur. Bunun yanında, bu, sadece son kaynak kod versiyonu için bir türetilmiş nesne bulunduğu anlamına gelir. Eğer kaynak kodun daha önceki bir versiyonu yeniden derlenmeliyse, bu kodun değiştirilme tarihi, sistem oluşturucunun yeniden derleme ihtiyacını fark etmesi için yapay olarak ayarlanmalıdır. Diğer sistemler, türetilmiş nesne yönetimi için daha detaylı bir yaklaşım kullanırlar. Türetilmiş nesneleri, kaynak kodun versiyon tanımlayıcısı ile başlıklandırırlar ve depolama kapasitesinin limitleri içerisinde, tüm türetilmiş nesneleri değiştirirler. Bu yüzden, kaynak kod bileşenlerinin tüm versiyonlarının nesne kodlarının, yeniden derlemeye gerek olmadan yeniden elde edilebilmesi genellikle olasıdır.