BLM 426 YAZILIM MÜHENDİSLİĞİ BAHAR Yrd. Doç. Dr. Nesrin AYDIN ATASOY

Transkript

1 BLM 426 YAZILIM MÜHENDİSLİĞİ BAHAR 2017 Yrd. Dç. Dr. Nesrin AYDIN ATASOY 12. HAFTA: YAZILIM BAKIMI Bilgisayar tabanlı sistemlerin tasarlanıp geliştirilmesinden ve kullanıcıya tesliminden snra bakım (maintenance) aşaması başlar. Sistemin dnanım öğelerinin bakımı, temizleme, eskimiş ya da arızalanmış parçaların değiştirilmesi şeklinde yapılır veya tüm dnanım öğesi yenisiyle değiştirilir. Yazılım öğelerinde ise bütün eskime ya da arızalanma durumu yktur. Zaman içinde rtaya çıkan yeni isterlerin karşılanması veya bulunan hataların giderilmesi çalışmaları yazılım bakımının temelini luşturur. Yazılım bakımı, yazılım geliştirilmesinde daha fazla zaman ve iş gücü gerektirebilir. Yazılım bakımı bir aracın bakımı gibi periydik lmayıp gelişen kşullara göre rtaya çıkar. Örneğin, daha önce hazırlanmış bir yazılımın değişen teknlji nedeniyle yeni bilgisayar mimarileri ve işletim sistemlerine uyarlanması önemli bir bakım işidir. Değişiklik, bilgisayar tabanlı sistemler için kaçınılmaz bir gerçektir. O halde, değişiklikleri değerlendirmek, denetim altında tutmak ve uygulamak için bir düzen geliştirilmeli ve na uyulmalıdır. Yazılım bakımı ile ilgili planlar ve içerikleri de IEEE/ EIA standardı içinde yer almaktadır. Bu bölümde yazılım bakımının nasıl yapılacağı hakkında temel bilgiler vereceğiz. Yazılım Bakımının Temelleri Yazılım bakımı, müşteri ile geliştirici arasında yapılan sözleşmeye göre bazen yazılım geliştirme sürecinde yer almamaktadır. Oysa günümüzde pek çk uygulama alanı değişen isterlere sahiptir. Bu nedenle de yazılım geliştirilip kullanıma sunulduktan snra dahi büyük miktarda değişiklik ve hata düzeltme istekleri luşabilmektedir. Bakım Türleri Bakım işleri yalnızca hataları düzeltmek lmayıp ürünün tesliminden snra yapılması gereken çeşitli türde işleri de kapsar. Bakımın türleri larak görebileceğimiz bu işlerin neler lduğuna bir bakalım:

2 Düzeltici Bakım: Şekil 1. Yazılım yaşam çevrimi ve bakım. Yazılım testi her zaman tüm kusurların bulunmasını ve giderilmesini sağlamaz. Çalışan bir yazılımda her an hata bulunması lasılığı vardır. Bir kısım yazılım kusuru ancak kullanım sırasında rtaya çıkar. Bu kusurların giderilmesi için geliştiriciye bilgi verilir. Kusurun sebebini araştırmaya ve gidermeye yönelik işlere düzeltici (crrective) bakım adı verilir. Kullanım sırasında bulunan ve raprlanan yazılım kusurlarının giderilmesi, hatanın önemine bağlı larak, ya hemen yapılır yada birkaç tanesiyle beraberce ele alınıp düzeltmeler uygulanır ve yeni bir sürüm çıkarılır. Bu bakım geliştiricinin bakım aşamasında mutlaka yürütmesi gereken bir etkinliktir. Uyarlayıcı Bakım: Bilgi işleme dünyasındaki hızlı değişmeler ve teknljik gelişmeler nedeniyle yazılımın yeni dnanıma, işletim sistemlerine, bunların yeni sürümlerine, yeni uç birimlere göre uyarlanması, sürümünün yükseltilmesi ve güncelleştirilmesi işlevine uyarlayıcı (adaptive) bakım denmektedir. Yazılımı kullanılan işletmeler zaman içinde çeşitli nedenlerle işlerin yürütülme şeklinde, kullanılan yöntemlerde (örneğin yazıcıdan alınan kağıt baskının biçimince değişiklik gerekmesi) değişiklikler yapma gereksinimi duyabilirler.

3 Sn yıllardaki gelişmelere bakarak, bir yazılımın rtalama ömrünün 10 yıl lduğunu, fakat dnanım birimlerinin yürürlükte kalma sürelerinin 1-2 yıl lduğunu görmekteyiz. Bu durumda, ya yazılımlar eski teknlji ile kullanılmaya devam edilecek ya da taşınabilirlik özelliği ön planda tutularak güncel teknlji kullanılacaktır. Güncel lmayan teknljiyi kullanmanın temel srunu ise ek dnanım gereksinimlerini, yedek parçaların sağlanmasında veya yeni rtaya çıkan kullanışlı yazılım araçlarının sisteme eklenmesinde güçlüklerle karşılaşmasıdır. İyileştirici Bakım: Yazılım geliştirilerek test edilerek başarılı bir şekilde kullanıcıya sunulduktan snra, yeni işlevler eklemek, var lanlara başarımı ve verimi artırıcı düzenlemeler yapmak iyileştirici (perfective) bakım işleri içinde yer alır. Bu şekilde yazılımın yeni sürümleri rtaya çıkar ve kullanıcının hizmetine sunulur. Örneğin veri tabanı erişimi rtalama 5 saniye lan bir yazılımda yeni bir arama algritmasının kullanımı ile arama süresi 3 saniyeye indirebiliyrsa bu değişikliğin uygulanması bir iyileştirici bakımdır. Yine, kullanımdaki bir yazılıma, yeni kullanıcı isterlerine göre yeni işlevler kazandırmak iyileştirici bakım kapsamına girer. Bu amaçla, ticari yazılım dünyasında paket yazılımların yeni özellikler içeren yeni sürümleri sürekli larak piyasaya sürülmektedir. Özel geliştirilmiş sistemlerin yazılım bakım sözleşmelerinde de bu knu dikkate alınarak genellikle iyileştirici bakım için ayrı srumluluklar tanımlanır, maliyetler hesaplanır. Önleyici Bakım: Yazılımın gelecekte uygulanabilecek değişikliklere daha iyi bir temel luşturması bakılabilirliğinin ve güvenirliliğinin arttırılması için ön tedbir niteliğindeki işlemler önleyici (preventive) bakım kapsamına girmektedir. Örneğin sık sık değişiklik yapılması gereken bir mdülün tasarımını daha esnek bir hale getirmek üzere yeni bir geliştirme süreci uygulanması, bunun snunda luşan yeni sürümün müşteriye verilmesi ve snraki değişikliklerin daha klay yapılmasını sağlayan önleyici bir bakımdır. Bu tür bakım geliştiricinin uzun süreli bakım anlaşması kapsamında yer alabilir. Bakım Ekibi Genel larak yazılım geliştiriciler bakım işleri için özel bir ekip ayırmazlar. Ancak, yazılımla ilgili srun veya yeni gereksinimlerin değerlendirilmesi ve önceliklendirilmesinde belirli bir ekibin tanımlanması gereklidir. Bakım ekibinin yapısı önemlidir. Bu yapıda daha önce geliştirilmiş sistem hakkında bilgisi lan en az bir teknik danışman bulunur. Bu kişi sistemin bileşenlerini, teknik özelliklerini bilen birisidir. Kullanıcın bakım istekleri bir bakım denetçisine iletilir. Bakım denetçisi, prje ile ilgilenmiş lan teknik danışmanından faydalanarak bir değişiklik önerisi luşturur. Bu öneri, Değişiklik Kntrl Kurulu (Change Cntrl Bard) nda görüşülür. Öneri kabul edilmezse kullanıcı durumdan haberdar edilir. Önerinin kabul edilmesi durumunda kurul tarafından değişiklik için bir srumlu persnel atanır. Srumlu persnel bir iş planı yaparak bakım persnelini görevlendirir. Düzenleşim yönetimi ile eşgüdüm halinde bakım persnelinin yeni bir sürüm luşturulması sağlanır. Yeni sürüm gerekli testlerden geçirildikten snra teslim persneli tarafından eğitimle birlikte kullanıcıya verilir. Kullanıcın bildirdiği yazılımla ilgili srun ve yeni isterleri bakım denetleyicisi yerine geliştiricinin teknik destek birimi, atanmış ürün yöneticisi veya prjenin yöneticisi tplayabilir. Küçük ölçekli bir geliştirme grubunda Bakım Denetçisi ile Değişiklik Kntrl Kurulu ayni kişi labilir. Bu görevi prje yöneticisi veya ürün yöneticisi de yapabilir. Büyük prjelerde ise bu kurul yöneticilerden ve kıdemli teknik persnelden luşur.

4 Srumluluklar prjenin bakım evresinden önce dağıtılır ve uygun ekip yapısı sağlanırsa, gerçekten bir bakım isteği rtaya çıktığında luşabilecek karmaşa önlenmiş lur. Daha da önemlisi, srumlulukların önceden tanımlanmasıyla persnel başka bir geliştirme işinde görevliyken, nu radan alıp acil bir bakım işi için görevlendirmek gerektiğinde luşabilecek lumsuz durumların önüne geçilir. Bakım Aşamaları Bakım evresinde bulunan yazılım için bir bakım işi rtaya çıktığında geliştirici tarafından standart bir süreç izlenmelidir. Bu sürecin aşamaları tıpkı bir yazılım geliştirme sürecinde benzer. Tek farkı, hazır lan bir belge ve kd yapısı üzerinde değişikliklerin uygulanmasıdır. Bakım aşamalarını şu şekilde özetleyebiliriz. Şekil 2. Bakım faaliyetleri. İsterler Çözümlenmesi: Bu aşamada srun veya değişiklik tanımlanır ve sınıflandırılır. Sistemde beklenen yeni düzenlemelere ve işlevlere ilişkin isterler tanımlanır. Buna göre var lan Yazılım İsterleri Belirtimi ve buna paralel larak da Yazılım Test Tanımlaması belgesi güncellenir.

5 Tasarım: Eldeki tasarım gözden geçirilerek yeni istekler eklenir ve Yazılım Tasarım Tanımlaması belgesi güncellenir. Gerçekleştirim: Yeni tasarım kda yansıtılarak gerekli kd değiştirme veya yeniden mdül geliştirme yapılır. Birim testleri gerekiyrsa yeni eklenen testlerle yapılarak tümleştirmeye hazır hale getirilir. Yazılım öğeleri kendi aralarında snra da dnanım ile tümleştirilir. Test: Yeni eklenen testlerin yanında, sistematik larak seçilen belirli testler tekrar edilerek tüm yazılımın testi gerçekleştirilir. Bu amaçla yapılan testlere regresyn testi denir. Sistemin genelinin güvenilirliğini kanıtlamak üzere müşteri önünde kabul testleri yapılır. Teslim: Yazılımın yeni bir sürüm larak müşteriye verilir. Büyük ölçekli yazılımlarda, yalnızca değişikliğe uğramış kısımlar için kurulum ve çalıştırma kılavuzu ile beraber yama (patch) üretilir. Teslim edilir ve kullanım kılavuzları güncellenir. Raprlama Genel larak, yazılımda bir değişiklik yapılması için istekler Değişiklik Önerisi (Change Prpsal) ile, srunlar da Yazılım Srun Rapru (Sftware Truble Reprt) ile bildirilir. Değişiklik Önerisi, kullanıcı tarafından yazılımda ne tür değişiklik arzu ettiğini açıklayacak şekilde hazırlanabileceği gibi geliştirici persnel tarafından bir öneri şeklinde de hazırlanabilir. Kullanıcının yeni isteğini karşılamak üzere ya da kendileri tarafından belirlenmiş bir iyileştirme amacıyla verilen Değişiklik Önerisi en az aşağıdaki bilgileri içermelidir: Sistem veya alt sistem adı, öğe adı Değişikliğin tanımı Değişikliğin yapılacağı öğe, bileşen veya birim Yapılan değişiklikten etkilenmesi lası diğer öğe, bileşen veya birimler Değişiklikleri yapabilmek için harcanması gereken tahmini işgücü İsteğin öncelik derecesi İsteğin numarası (takip edebilmek için) Diğer açıklayıcı bilgiler Öneriyi inceleyen makamların imzaları ve tarihleri Karar (inceleme snunda luşturulur) Herhangi bir yazılım kusurunu raprlamak için kullanılan Yazılım Srun Rapru da benzer şekilde lup en az aşağıdaki bilgileri içermelidir: Sistem veya alt sistem adı, öğe adı Srunun açık tanımı (mutlaka kesin ifadeler kullanılmalıdır) Hatalı duruma düşülmesine neden lan giriş verileri Varsa raprlama sisteminin luşturduğu kayıtlar (lg data) Srunu rapr eden kişiye ait erişim bilgileri Srun Rapru numarası (takip edebilmek için) Srunu daha ayrıntılı inceleyen mühendislere ait erişim bilgileri Rapru inceleyen makamların imzaları ve tarihleri Karar (inceleme snunda luşturulur)

6 Bazen bu iki belge birleştirilir ve bşlukların dldurulacağı bir tabl şeklinde tek bir şabln kullanılır. Bu belgeler bir bilgisayarda veya elle dldurulur. Bakım Klaylığı Nitelikli bir yazılımın önemli özelliklerinden biri bakım klaylığıdır. Bu özelliği, yazılımın anlaşılmasındaki, düzeltilmesindeki, iyileştirme ve uyarlanmasındaki klaylık larak tanımlayabiliriz. Teknik larak, her türlü değişiklik istemini gerçekleştirmek mümkündür. Ancak, önemli lan bunu en düşük maliyetle, en kısa zamanda, dğru larak ve yazılımın niteliklerini bzmadan yapabilmektir. Unutulmamalıdır ki, bir kez değişiklik isteminde bulunan yazılım, gelecekte de değişikliğe uğrayabilir. Bu nedenle, bakıma etki eden çeşitli etmenler dikkate alınmalı, bakım işleri belirli bir nitelik güvence çerçevesi içinde yürütülmeli ve gelecekte de yararlı labilecek niceliksel değerler tplanmalıdır. Denetim Etmenleri Yazılım bakımının önemi, hem geliştirici hem de müşteri tarafından uzun vadede daha iyi anlaşılır. Bu önemin iyi kavranması da yazılım bakımını denetleyen çeşitli etmenlere bağlıdır. Bunları şu şekilde gruplamak mümkündür. Geliştirme rtamına bağlı lanlar Yazılım geliştirme persnelinin varlığı Sistem yapısının anlaşılabilirliği Sistemin işletim klaylığı Standart bilgisayar dnanımı kullanımı (ana, test, hedef sistem) Standart işletim sistemi kullanımı Standart prgramlama dillerinin kullanımı Standart veya taşınabilir kütüphanelerin kullanımı Standart belgelendirme yöntemlerinin kullanımı Test durumlarının yeniden luşturabilme lanağı Hata ayıklama gereçlerinin varlığı Persnele bağlı lanlar Persnelin aynı knudaki geliştirme deneyimi Kullanılan geliştirme sürecindeki deneyim Persnelin iş disiplini Persnelin uygulama alanı hakkındaki bilgisi Bakım evresine giren yazılım hakkında deneyimi lan persnelin bulunması Müşteriye bağlı lanlar Kullanıcıların tek veya çk sayıda lması (tek müşterinin siparişi veya kitle kullanımı amaçlı lması) Müşteri ile geliştiricinin yazılımın yaşam çevrimi byunca lan ilişkisi (garanti süresi, teknik destek anlaşmaları, yeni değişiklik isteklerinin çıkma lasılığı gibi) Müşteri isteklerinin değişme sıklığı

7 Müşterinin rtam değiştirme sıklığı Uygulama alanı isterlerinin değişme sıklığı Şekil 3. Bakım faaliyetlerine ait insan varlıkları. Bakımın Niteliği Bir yazılım prjesinin nitelikli bir bakım evresine sahip labilmesi için işin başında aşağıdaki nktalara önem verilmesi gereklidir: Bakım istekleri her zaman resmi bir Değişim Denetim Süreci kapsamında ele alınmalıdır. Bakım istekleri yeterince hızlı larak yerine getirilebilmelidir. Bakım istekleri ve çalışmaları sistematik larak izlenebilmelidir. Bakım işlemleri her zaman resmi larak tanımlanmalı ve yönetilmeli, gelişigüzel bir şekilde ele alınmamalıdır. Bakım sırasında belgelendirme standartlarına uyulmalıdır. Uygun nitelikte bakım persneli kullanılmalıdır. Niceliksel Ölçümler Yazılımın bakım klaylığı, nitelik ve güvenilirlik gibi ölçülmesi ldukça zr lan bir özelliktir. Ancak, bakım işlemlerinin özelliklerini dikkate alarak bazı metrikler ve niceliksel ölçümler yapmak mümkündür. Bu metriklerin önemli ve yaygın lanları şunlardır: Srunun belirlenip rapr edilme süresi İdari işlemlerdeki gecikme süresi Değişikliğin tanımlanması için gereken süre Srun bildirimlerinin müşterilere göre dağılımı Srun bildirimlerinin hata türlerine göre dağılımı Srun bildirimlerinin mdüllere göre dağılımı Düzeltme için geçen zaman Yerel test süresi Kullanım yerindeki test süresi Tplam süre Tplam işgücü ve maliyet

8 Bu metriklerin hemen hemen hepsi bakım işleri sırasında zrluk çekmeden kaydedilebilir. Kaydedilen veriler yöneticilere kullandıkları yöntemlerin ve araçların etkinliği, lası maliyet kestirimi knusunda bilgi verilir. Yazılım bakım işlerinin değerlendirilebilmesi için bahsettiğimiz bu metriklerin tplanmış ve kayıt altına alınmış lması gereklidir. Özellikle, uzun süre kullanılması düşünülen yazılımların bakım evrelerinin sağlıklı larak devam edebilmesi için her bakım işinde bu bilgiler tplanmalı ve prgram veya prje tanımlayıcısına (isim veya kd numarası) göre saklanmalıdır. Görev alan persnel bilgileri ile bakım işi snunda elde edilen deneyimler de kaydedilmesi gerekenler arasında yer almalıdır. Bakım Srunları Bakım sırasında karşılaşılan srunları bilmek na karşı hazırlıklı labilmek için yarar sağlayacaktır. Genellikle, geliştirilen yazılımın bakılabilirlik özelliğinin eksikliği, bir disiplin içinde geliştirilmiş lmaması srunların kaynağını luşturur. Bu srunları şu şekilde listeleyebiliriz: Yazılımın çk fazla sürümü rtaya çıkarsa, bakımı da derece güçleşir. Hatta gerekli değişikliklerin tam larak kaydedilememiş lması durumunda bakımı yapabilmek mümkün lmaz. Yazılımın geliştirildiği süreci aynen takip etmek zaman ve işgücü açısından çğu zaman lanaksızdır. Bir başkasının yazdığı kdu anlamak genellikle çk zaman alır. Eğer belgelendirme ve kd içindeki açıklamalar yetersiz ise ciddi srunlar rtaya çıkar. Belgelendirme yetersiz, eksik, hatalı labilir ya da hiç lmayabilir. Bu durumda yalnızca kdu kuyup anlamak gerekecektir. Persnel devamlılığı her zaman karşılaşılması muhtemel genel bir srundur. Geliştirici İçin Kurallar Yüksek nitelikli yazılım üretmeyi amaçlayan geliştiricilerin bakım evresinde uygulaması gerekli kurallar arasında şunları sayabiliriz: Bakım isteklerinin durumu sistematik larak izlenebilmelidir. Bakım istekleri her zaman resmi bir Değişiklik Denetim Süreci kapsamında ele alınmalıdır. Bakım istekleri için süre ve maliyet kestirimi dğru larak yapılabilmelidir. Müşterinin yazılımla ilgili bildirdiği srun ve yeni gereksinimler teknik destek birimi, düzenleşim yöneticisi, ürün yöneticisi veya prje yöneticisinin görevlendireceği bir kişi ya da ekip tarafından tplanmalıdır. Bakımın Yan Etkileri Yazılımın bakımı genellikle biraz tehlike içerir. Zira, test edilmiş ve kullanıma sunulmuş bir üründe yapılacak küçük sayılabilen bir değişiklik iyi çözümlenmez ve etkileri iyi takip edilmezse daha büyük yan etkilere yl açabilir. Karmaşık bir algritma içinde yer alan bir tek değişkenin değerinin değiştirilmesi ya da yeni bir deyim eklenmesi gibi küçük sayılabilecek bir değişiklik, tüm yazılımın hatalı çalışmasına veya çökmesine yl açabilir. Tasarımın ve kdun iyi belgelendirilmesi, dikkatli bir

9 bağlanım testi bu tür snuçları azaltabilir. Genellikle, kd içinde, verilerde, belgelemede ve başarımda rtaya çıkan bu istenmeyen snuçlara bakımın yan etkileri denmektedir. Kdlamanın Etkilenmesi Verilerin Etkilenmesi Belgelendirmenin Etkilendirmesi Başarımın Etkilenmesi Belgelendirilmemiş Yazılımların Bakımı Yazılım geliştirmekle görevli grupların baş etmeleri zr lan bir srun da hiçbir kaydı ve belgesi bulunmayan eski yazılımların bakımını yürütmektir. Çeşitli nedenlerden dlayı n ya da yirmi yıl önce yazılmış kdları bugün tekrar kullanmak, yeni rtamlara uyarlamak veya değişiklik yaparak kullanmaya devam etmek gerekebilir. Ancak, bu yazılımları geliştirmiş lanlar artık grupta, hatta firma ya da kurumda bulunmayabilir. Geliştirme sırasında belirli bir yöntembilim uygulanmamış, yapılması gerekli lan belgelendirme de çk az yapılmış ya da hiç yapılmamış labilir. Böyle durumlarda bakım için uygulanacak yöntemler şunlar labilir: Aynı kd üzerinde değişiklik yapılabilir. Kd başka rtamlara taşınabilir. Tersine mühendislik yapılabilir. Kaynak kdu kapsayıcı içine almak Yeni bir dille yeniden yazmak Tersine Mühendislik Tersine mühendislik (reverse enginerring) temel larak elektrnik ya da mekanik mühendisliğine uygulanmaya başlanmıştır. Üreticisi dışında başa geliştiriciler, ticari casusluk içi bir elektrnik sistem dnanımının veya mekanik parçaların nasıl çalıştığını, ürünün nasıl üretildiğini anlamak üzere inceleme ve testler yaparlar. Üretim sırlarını rtaya çıkarmaya çalışırlar. Bu şekilde bir ürünün kpyasını elde etmeye veya yenisini geliştirmeye gayret ederler. Yazılımda uygulanan tersine mühendislik de aynı sayılır. Üzerinde çalışılan ürün başka bir geliştiriciye ait labileceği gibi aynı geliştiriciye ait daha önceden üretilmiş yazılımlar da labilir. Ancak, herhangi bir tanımlayıcı belge bulunmadığı için kaynak kd bir gizem içindedir. Geliştirildiği sırada hakim lunan yazılım, üzerinden yıllar geçince ve geliştiricilerden kimse bulunamayınca bakım işi tam bir karmaşaya döner. Böyle durumlarda uygulanan tersine mühendislik, yazılımı kaynak kddan daha üst düzeyde bir syutlama ile yeniden tanımlamaya çalışma sürecidir. Bu aslında tasarımın geri kazanılmasıdır. Bu maksatla geliştirilmiş lan çeşitli araçlar yardımıyla yazılım kaynak kdundan veri, mimari ve yrdamsal tasarımı elde etmek mümkündür. Bundan snra gerekli bakım işlemi yapılabilir.

10 Tersine mühendislikte amaç, kaynak kdu girdi larak alıp tam tasarım belgelendirmesini çıktı larak elde etmektir. Ancak, pratikte bunu böyle işlemesi her zaman mümkün lmaz. Sebebi, bu işi yapabilmek için gerekli lan yardımcı araçların sağlayacağı syutlama düzeyinin kabul edilebilir lup lmamasıdır. Her araç kendi mantığına göre çalışmasını yaparak kaynak kdu belgeye çevirir. Bundan snrası yine yazılım mühendisleri tarafından incelenmeli, gerekirse elle düzeltmeler yapılmalıdır. Syutlama düzeyinin yüksekliği, özellikle büyük yazılımlarda, tasarımın bakım mühendisleri tarafından daha iyi anlaşılmasını sağlar. Tersine mühendisliğin uygulandığı bir başka alan da kaynak kdu hiç bulunmayan çalışır durumdaki prgramlardan tasarımı ele etmektir. Çalışan prgramların nesne kdu ikili durumda makine kdu içerirler. Günümüzde bu makine kdunu anlayıp kunabilir halde bir prgramlama dili haline çeviren araçlar da vardır. Ancak, mdül, yrdam ve değişken isimleri mantıksal deyimler içermeyebilir, yalnızca takibi klaylaştıracak tanımlayıcılar içerir. Bu tanımlayıcıları daha snra arzu edilen sözcüklerle değiştirmek mümkündür. Her iki yöntemde de tersine mühendisliğin tam lması gerekir. Diğer bir deyişle, kdun hiçbir kısmı atlanmamalı, tasarım tam larak kapsanmalıdır.