1. YAZILIM YAPILANIŞI YÖNETİMİ - GİRİŞ

Bir sistem, belirli fonksiyon ya da fonksiyonları yerine getiren bileşenler topluluğu olarak tanımlanabilir. Bir sistemin yapılanışı yani konfigürasyonu ise sistemin donanım, bellenim (firmware), yazılım karakteristiklerinin ve fonksiyonlarının tanımlanmasıdır. Ayrıca, belirli bir amaca yönelik olarak yazılım, donanım ve bellenim öğelerinin belirli versiyonlarının bir araya getirilmiş bir topluluğu olarak da düşünülebilinir.

Yukarıdaki açıklamaları dikkate alırsak, Yapılanış Yönetimi (YY), sistem yaşam döngüsü boyunca bir sistemin yapılanışını belirgin noktalar ile tanımlayan, değişiklikleri sistematik olarak kontrol eden, yapılanışın bütünlüğünü ve izlenebilirliğini sağlayan bir disiplindir. diyebiliriz.

Yapılanış Yönetimi (YY) resmi tanımı:

Bir yapılanış öğesinin fonksiyonel ve fiziksel karakteristiklerini tanımlayan ve belgeleyen,bu karakteristiklerin değişimini kontrol eden, değişim sürecini ve gerçekleştirim durumunu kaydeden ve denetleyen, belirlenmiş gereksinimlerle uyumluluğunu doğrulayan bir disiplindir.

2. YAZILIM YAPILANIŞI AKTİVİTELERİ

Yazılım yapılanışını, en iyi olarak aktivitelerini inceleyerek anlayabiliriz. Bu bölümde yazılım yapılanışın aktiviteleri detaylı olarak ele alınacaktır. Yazılımsal Yapılanış Yönetimi (YYY) aktiviteleri genel olarak şu şekilde belirlenmiş ve dünyada bir standard olarak kabul görmüştür:

Şekil 1 � Yazılım Yapılanış Aktiviteleri

Şimdi şekilde görmüş olduğumuz parçaları tek tek inceleyeceğiz:

2.1. Yazılım Yapılanışı Yönetimi (YYY) Sürecinin Yönetimi

YYY, yazılım yaşam döngüsünü destekleyen, geliştirme ve bakım aktivitelerine, projenin tamamına, son kullanıcılara, müşterilere yarar sağlayan bir süreçtir.

Yönetimsel bir bakış açısıyla bakarsak, YYY, bir ürünün gelişimini, ürünün öğelerini tanımlayarak, değişimi yöneterek, kontrol ederek, yapılanış bilgisini raporlayarak kontrol eder. diyebiliriz. Geliştirici bakış açısıyla bakacak olursak, YYY, geliştirmeyi ve değişimleri gerçekleştirmeyi kolaylaştıran bir süreçtir. diyebiliriz. Başarılı bir YYY, dikkatli bir planlama ve yönetimi içerir. Bu da, YYY sürecinin kurumsal kavramını, sınırlarını, kavramını anlama ile sağlanabilir.

2.1.1. Kurumsal Yapı ile İlişki

Bir proje için bir Yazılım Yapılanışı Yönetimi planlayabilmek için kurumsal yapıyı kurum içi bölümler arası ilişkileri bilmek gereklidir çünkü YYY, bazı kurumsal birimlerle ve aktivitelerle içiçe olacaktır.

YYY, yazılım kalite güvencesi, yazılım doğrulama gibi süreçlerle birlikte yaşam döngüsünü destekleyen bir süreç olarak görülmektedir. Kurumsal birimler bu süreçlerin düzgün olarak yapılandırılmasından sorumludurlar. Bazı YYY aktivitelerini gerçekleştirmek başka kurumlara bırakılsa da, genel sorumluluk direkt olarak kurumun kendisinde olmak zorundadır.

Yazılım sık olarak donanım ve bellenim elemanlarını da içeren büyük sistemlerin bir parçası olarak geliştirilir. Bu durumda, donanım ve bellenim ile paralel bir geliştirme yapılması zorunlu duruma gelmektedir. İşte bu yüzden, kurumun birimleri bilinmelidir.

Yazılım Yapılanışı Yönetimi, Yazılım Kalite Güvence süreci ile yakından ilgilidir. Hatta bazı projelerde, Yazılım Kalite Güvencesi�nin önkoşulu Yazılım Yapılanışı Yönetimi olmaktadır. Buna bağlı olarak, YYY içinde bulunan bazı öğeler, yazılım kalite güvencenin de öğeleri olabilecek kadar birbirleriyle ilgili olabilirler. Tabiki en yakın ilişki, yazılım geliştirme ile yazılım bakım arasında olmaktadır. Yazılım ortamı aşağıdakileri içerir:

Bu ortam, gördüğünüz gibi, aynı zamanda bir çok yazılım yapılanış kontrolleriyle de ilgilidir.

2.1.2. Yazılım Yapılanışı Yönetimi Rehberi ve Kısıtlamaları

YYY kısıtlamaları ve rehberlikleri bir çok kaynaktan gelmektedir. Bir projenin yazılım yapılanış yönetimini, yapılan birçok anlaşma ve önceden var olan anlaşmalar kısıtlanabilir. Buna ek olarak, müşteri ile yapılan kontratta da süreci etkileyici maddeler bulunabilir. Örneğin, kontratta bazı yapılanış denetlemelerinin istendiği belirtilmiş olabilir ya da bazı belirlenmiş öğeler yazılım yapılanışı yönetimine özel olarak bırakılmış olabilir. Bunlardan başka, seçilen yazılım geliştirme metodolojisi de etkileyici bir faktör olabilir. YYY rehberi, Yazılım Mühendisliği Enstitüsü�nün yayımlamış olduğu CMM ya da ISO SPICE gibi standardlardan, süreçlerden elde edilebilir.

2.1.3. Planlama Aşaması

Yazılım Yapılanışı Yönetimi için yapılacak olan plan, kurumsal kavramlara, kısıtlamalara ve rehberlere, projenin doğasına, yapısına uygun olarak hazırlanmalıdır. Ele Alınan Planlama Adımları:

Bunlara ek olarak, kurum, sorumluluklar, kaynaklar, zaman çizelgeleri, araç seçimi, gerçekleştirim, arayüz kontrolü gibi konular da planlama içinde değerlendirilir. Planlama aktivitesinin sonucunda oluşan plan, Yazılım Yapılanış Yönetimi Planı olarak adlandırılır. Bu plan, yazılım kalite güvencesi denetlemesi için bir kaynak olmaktadır.

2.1.3. Yazılım Yapılanış Yönetimi Organizasyonu ve Sorumlulukları

Yapılması gereken yazılım yapılanış yönetimi aktivitelerinin kimin yapacağını karıştırmamak için, sorumluluklar, görevler tam olarak belirlenmek zorundadır. Belirli yazılım yapılanışı yönetimi sorumlulukları ve görevleri, belirli kurumsal birimlere, kişilere atanmalıdır. Yazılım yapılanışı yönetimi genel yetki mekanizması açıkça belirtilmelidir.

2.1.4. Yazılım Yapılanış Yönetimi Kaynakları ve Zaman Çizelgeleri

Yazılım yapılanış yönetimi planı, gerekli aktiviteleri yapabilmek için gerekli olan arçları, grupları belirler. Görevlerin arasındaki ilişkileri ve sıralarını belirleyerek zaman çizelgesi sorunlarını ortadan kaldırır. Gerekli olan herhangi bir eğitim de bu plan sayesinde ortaya çıkar ve belirlenir.

2.1.5. Araç Seçimi ve Gerçekleştirim

Yazılım yapılanış yönetimi için, değişik özelliklerde araçlar mevcuttur. İçinde bulunulan duruma bağlı olarak bu araç özelliklerinin hangilerine ihtiyaç duyulduğu belirlenir ve birden çok araç geretiren durumlarda bu araçların kombinasyonu kullanılabilir. Otomatik araçlar, büyüyen ve büyüdükçe karmaşıklaşan projelerde, büyük yarar sağlarlar. Bu araçların destekledikleri konuları şöyle sıralayabiliriz:

Aşağıdaki şekilde, Yazılım Yapılanış Yönetimi Araçlarının yapabildikleri aktiviteleri ve bunların Yazılım Yapılanış Yönetimi ile nasıl örtüştükleri gösterilmektedir.

Şekil 2 � Yazılım Yapılanış Yordamları ve Araçları

Yukarıdaki şekilde, kod yönetim sistemleri yazılım kütüphanelerinin çalışmasını kütüphane elemanlarına erişimi kontrol ederek, birden çok kullanıcının aktivitelerini kontrol ederek desteklemektedir. Diğer araçlar yazılım ve yayım belgeleri oluşturmayı desteklemektedir. Bunlar dışındaki araçlar ise veritabanı yönetimi desteği, yönetim için raporlama mekanizmaları desteği sağlamaktadır. Araçların bazılarının yetenekleri yazılım yapılanış yönetimi içine entegre edilebilir.

2.2. Yazılım Yapılanışı Yönetim Planı

Bir proje için belirlenen YYY planının sonuçları, Yazılım yapılanış Yönetimi Planında tutulur. Bu belge, Yazılım Yapılanış Yönetimi süreci için bir kaynak olur. Süreç boyunca, gerekli durumlarda güncellenir. Gerçekleştirim bölümünde ise, plandaki bazı parçaların daha detaylı açıklanması gerekebilmektedir. Bu yüzden bu belgeye yaşayan bir rapor diyebiliriz. Bir YYY Planında 6 kategoride bilgi bulunmaktadır:

2.3. Yazılım Yapılanış Tanımlaması

Yazılım Yapılanış Tanımlaması aktivitesi kontrol edilecek elemanları belirler ve bu elemanların versiyonlarını kontrol eder. Ayrıca, bu kontrol edilen elemanların yönetiminde kullanılacak araçları belirler.

2.3.1. Kontrol Edilecek Elemanların Tanımlanması

Değişim kontrolündeki ilk aşama, kontrol edilmesi gereken elemanların belirlenmesi işlemidir. Bu işlem, yazılım yapılanışının sistem yapılanışı ile birlikte ele alınıp anlaşılmasını, yapılanış elemanlarının seçimini, yazılım öğelerinin isimlendirilmesinde bir strateji belirlenmesini, aralarındaki ilişkilerin belirlenmesini gerektirir.

Yazılım Yapılanış Öğesi:

Yazılım yapılanış öğesi, yapılanış yönetimi için tasarlanmış olan yazılımın bir genellemesidir ve tek bir eleman olarak algılanır. Kod da dahil olmak üzere, çeşitli öğeler YYY tarafından kontrol edilir. Yazılım yapılanış öğeleri listesi:

Yazılım Versiyonları:

Yazılım projesi ilerledikçe, öğeler gelişir. Bir karışıklık sözkonusu olmaması için, bu gelişmelerin tutarlı, kontrollü bir şekilde ele alınması gereklidir. Bu da versiyonlar ile sağlanır. Bir yazılım öğesinin versiyonu, belirli özelliklere sahip olan bir öğedir. Uyarlama, geliştirilmiş olan bir yazılım versiyonuna verilen addır.

2.3.2. Yazılım Yapılanış Öğelerinin Bulunması

Yazılım yapılanış öğeleri farklı faklı zamanlarda bulunup farklı zamanlarda yazılım yapılanış yönetimi kontrolüne verilebilir.(yazılım yaşam döngüsünün belirli adımlarında bulunabilir) Genelde, bitirilmiş bir resmi görev, gözden geçirme yeni öğeler bulmayı sağlamaktadır. Aşağıdaki şekilde Şelale Modeli ile öğelerin bulunması örneklendirilmektedir.

Şekil 3 � Öğelerin Elde Edilmesi

2.4. Yazılım Yapılanış Kontrolü

Yazılım yapılanış kontrolü, yazılım yaşam döngüsü boyunca oluşan değişiklikleri yönetir. Hangi değişikliklerin uygulanacağı, belirli değişikliklerin onaylanması, bu değişikliklerin hayata geçirilmesinin desteği gibi konuları kapsar.

Yazılım değişiklikleri istekleri süreci, birçok araç kullanımını da beraberinde gerektirir. Ve bu araçlar (belgeleme arçları, koordinasyon araçları…) genelde geliştirme takımı tarafından yaratılır çünkü her projede, bu isteklerin tipi projeye bağımlıdır.

Kabul edilmiş, onaylanmış değişiklikler belilenen yazılım yordamlrına uyularak gerçekleştirilir. Aynı anda birden çok değişikliğin gerçekleştirimi yapılabileceği için bu gibi durumlarda gerçekleştirimlerin birbirine uyumlu olması sağlanmalıdır. Değişikliklerin gerçekleştirimleri bitirlikten sonra, sonuçların standardlara uygunluğu da test edilmelidir. Aşağıdaki şekilde değişim sürecini daha iyi görmekteyiz.

Şekil 4 � Değişiklik Kontrolü

2.5. Yazılım Yapılanış Durumu Kontrolü

Yazılım Yapılanışı Durum Kontrolü, verimli bir yapılanış yönetimi için gerekli olan bilgiyi, raporlamayı sağlar. Durum Kontrolü tasarımı, mevcut bilgi sistemlerinin tasarımlarından yola çıkarak yapılabilir.

Durum kontrolü aktivitesi, yaşam döngüsü boyunca, bilgiyi yakalamayı ve raporlamayı amaçlar. Her bilgi sisteminde olduğu gibi burada da, yapılanış durumu tanımlanmalı ve bakımı yapılmalıdır. Bu işlem içinde çeşitli ölçütler ve bilgiler gerekmektedir. Bu bilgiler yönetim kademesi, yazılım mühendisleri ve diğer kurumlardan elde edilecektir. Bilgi toplama esnasında, karışıklıkları kontrol etmek için bazı araçların kullanılmasında fayda vardır.

Raporlanan bilgiler, geliştirme akmı, bakım takımı, proje yönetimi, kalite güvence takımı gibi gruplar tarafından kullanılacaktır. Raporlama rasgele ortaya çıkan isteklere bağlı olarak hazırlanabildiği gibi düzenli aralıklarla da hazırlanabilmektedir.

Durum kontrolünden elde edilen bilgi, raporlamada kullanılabildiği gibi yönetim kademesinde bazı ölçütler için de kullanılabilir. Örnek olarak değişiklik isteklerinin sayısı ve bir değişikliğin gerçekleştirme zamanı verilebilir.

2.6. Yazılım Yapılanışı Denetleme

Yazılım denetlemesi, yazılım ürünün kabul edilirliğinin, standardların, rehberlerin, yordamların değerlendirildiği bağımsız olarak gerçekleştirilen bir aktivitedir. Denetlemeler, iyi tanımlanmış olan birçok süreci kapsar. Bu süreçlerde, farklı farklı sorumluluklar mevcuttur. Her denetleme, çok iyi olarak planlanmalıdır.

Denetlemeler, hangi öğelerin istenilen düzeyde olduğu, hangilerinin eksik olduğu hakkında bilgi verir. Bu denetlemeler proje yaşam döngüsünün önemli noktalarında yapılmalıdır. 2 çeşit denetleme vardır: Fiziksel Denetleme ve Fonksionel Denetleme. Bu denetlemelerin sağlıklı olarak yaılması, ortaya çıkarılacak olan ürünün kalitesini de ortaya koyar.

2.6.1. Fonsiyonel Denetleme

Fonksyionel denetlemenin amacı, denetlenen yazılımın belirtimlerle olan uyumluluğunu ölçmektir.Yazılım Doğrulama ve Testlerinin çıktıları, bu denetleme için iyi birer girdidirler.

2.6.2. Fiziksel Denetleme

Fiziksel denetlemenin amacı, tasarım dökümanının gliştirilmekte olan yazılım ürünü ile tutarlı olup olmadığını ölçmektir.

2.7. Yazılım Yayım Yönetimi

Yayım kelimesi, geliştirme aktivitesi boyunca ortaya çıkarılan farklı özelliklerdeki öğeler anlamına gelmektedir. (Mesela bir araçın yeni, farklı özellikteki versiyonları) Bu öğeler, müşteriye gönderilen dışsal öğeler olabileceği gibi geliştirme takımı içinde kalan içsel öğeler de olabilir. Bi yazılımın yeni bir versionu oluşturulduğunda, bu versiyonun yayım olarak açılanmadan önce diğer yazılımların hangi versiyonları ile uyumlu çalışabileceği belirlenmeli ve buna göre bir paket oluşturulmalıdır. Bu iş için de kütüphaneler kullanılmalıdır.

Çalıştırılabilir bir yazılım için, öğelerin doğru versiyonları bir araya getirilir ve kurulum paketi hazırlanır. Bu işlem yapılırken, en önemli nokta yazılımın çalışacağı donanımın yapılanışının doğu tespit edilmesidir. Çünkü donanım yapılanışı yanlış tespit edilmiş bir paket, çalışmayacağı için sonuç tam anlamıyla hüsran olacaktır.

Buna göre, yazılım yayım yönetimi, bir ürünün öğelerinin tanımlanması, bir araya geirilmesi, dağıtımı gibi konuları ele alan önemli bir aktivitedir. (Çalıştırılabilir kod, dökümantasyonu, yapılanış bilgisi…) Yazlım yayım yönetiminin diğer bir görevi de ne zaman bir yayım yaratmak gerektiğine karar vermektir. Çözülen problemlerin önemi ve hataları ne kadar yok ettiği bu kararı belireyen etkileyici bir faktördür.

3. KAYNAKÇA

Berczuk, Steve. Configuration Management Patterns, 1997.

http://www.bell-labs.com/cgiuser/

OrgPatterns/OrgPatterns?ConfigurationManagementPatterns.

Compton, Stephen B, Configuration Management for Software , VNR Computer Library,

Van Nostrand Reinhold, 1993.

Continuus Software Corp., Work Area Management, Continuus/CM: Change

Management for Software Development.

http://www.continuus.com/developers/developersACE.html.

Dart, Susan, Spectrum of Functionality in Configuration Management Systems,

oftware Engineering Institute, 1990.

http://www.sei.cmu.edu/technology/case/scm/tech_rep/TR11_90/TOC_TR11_90.html

Jameson, Kevin, Multi Platform Code Management , O�Reilly & Associates, 1994

Linenbach, Terris, Programmers� Canvas: A pattern for source code management 1996.

http://www.rahul.net/terris/ProgrammersCanvas.htm.

Lyon, David D, Practical CM , Raven Publishing, 1997

McConnell, Steve, Best Practices: Daily Build and Smoke Test, IEEE Software , Vol.13, No. 4, July 1996

van der Hoek, Andre, Hall, Richard S., Heimbigner, Dennis, and Wolf, Alexander L.,Software Release Management, Proceedings of the 6th European Software Engineering Conference , Zurich, Switzerland, 1997.

EK 1 � KULLANILAN TİCARİ YAZILIM YAPILANIŞI YÖNETİMİ ARAÇLARI

• AccuRev CM - Software Change Management - the 21st Century
• Aide-de-Camp/Pro (ADC/Pro) - True Software Inc.
• AllChange
• AllChange Professional Change and Configuration Management - Intasoft
• Apps*Integrity
• BitKeeper
• BuildForge
• Change Man
• Change Man MVS SCM, Optima Software
• CIG Suite for e-business - Chicago Interface Group
• ClearCase
• CMIS Product Services Home Page
• CMstat Corporation
• CMVC
• CMVision - CMF (Expertware)
• CMZ
• CO-OP
• Code Co-op
• ComponentSoftware RCS
• Configuration Management Solutions
• Continuus/CM
• Control, Control-CS, nciGENESIS
• CS-RCS Pro
• CVS
• Depot
• DevMan
• Diamond CM
• ENDEVOR/WSX
• EPM Technology
• HOPE — Human-Oriented Programming Environment
• InSync CM/PDM
• Librarian, JSSL
• LIFESPAN
• Merant PVCS and Merant Collage
• MKS RCS
• Multi-Platform Code Management Tools
• Object Technology International�s ENVY/Developer
• ObjectCycle
• OkCatalyst
• Openmake
• PCMS (by Doug Toppin)
• Perforce
• Platinum CCC/Harvest
• QVCS — Quma Version Control System
• Razor
• RCE - Revision Control Engine
• Sablime - Lucent Technologies
• SCLM
• SiberLogic Inc. - SourceTrack
• SoftBench CM Product
• SoftLanding Systems, Inc. - TurnOver
• StarBase Corporation - StarTeam
• Sun WorkShop TeamWare
• Surround SCM
• TeamVizor Developer
• Tesseract CM tools
• TrackWise Change Management Software
• VCS - Version Control System
• Visual Build
• Visual SCCS
• Voodoo - Versions Of Outdated Documents Organized Orthogonally
• VSMake

EK 2 � KULLANILAN BEDAVA YAZILIM YAPILANIŞI YÖNETİMİ ARAÇLARI

• /BriefCase 3
• AEGIS
• Anthill Build Management Server
• BCS - Baseline Configuration System
• CS-RCS
• The CVS Bubbles - Concurrent Version System
• CVSup
• Freepository
• ICE - Incremental Configuration Engine
• Librarian V1.4 Source Code Version Control Software
• PRCS - Project Revision Control System
• QVCS - Quema Version Control System
• RCS - Revision Control System
• SCCS - Source Code Control Syste
• Shape Tools
• Subversion

1. Yazılım Ürün Mühendisliği (YÜM)

YÜM, uygun araçları ve metodları kullanarak, projenin yazılım sürecinde yazılım ürünü üretmek için yürütülen mühendislik görevlerini içerir. Ayrıca;

Yazılım mühendisliği görevleri için belgeleme gerekir (örneğin yazılım gereksinimler belgesi, yazılım tasarım belgesi, test planları, test yordamları). Bu belgeleme işlerinde de YÜM�nin önemi vardır.

2. Yazılım Ürün Mühendisliği Hedefleri

• Yazılım ürünleri ölçütlerini pratiğe dökmek.
• Maliyet, zaman çizelgesi, fonksiyonellik, kalite arasındaki ilişkiyi kurmak ve bu 4�lü anlayışı geliştirmek.
• Proje/program yönetimi, sistem mühendisliği, süreç geliştirme ile ilgili bir ölçümleme yaklaşımı getirmek ve devam eden yazılım ölçütlerini kontrol etmek.

3. Yazılım Ürün Mühendisliği Tanımları

4. Yazılım Ürünü Mühendisliği Kapsamı

• Yazılım ürünü mühendisliği çalışmaları sırasında, tüm çaba, merak ve odaklanma yazılım ürünü fonskiyonelliği ve kalitesi üzerine olmalıdır.
• Tanımlanmış olan ölçütler, tek bir proje için fonksiyonelliği ve kaliteyi hedef almalıdır. Içiçe geçmiş çoklu projeler hedef alınmamalıdır.
• Yazılım ürünü mühendisliği sorunları üç değişik müşteri perspektiften bakarak ele almalıdır: Kullanıcı, geliştirici ve bakımcı.
• Sadece yazılım mühendisliği alanına giren konularda yazılım ürünü mühendisliği çalışması yapılmalıdır. Eğitim ile ilgili aktiviteler ve materyaller bu kapsama girmemektedir.
• Ürün fonksiyonelliği ve kalitesi ile ilgili ölçütleri belirlerken, süreçler ve ürün ile ilgili raporlar dikkate alınmalıdır.
• Çalışmalar, müşterinin fonksiyonelliği ve kaliteyi tahminleyebileceği konuları da içine almalıdır.
• Çalışmalar, ürünü iyileştirmede yardımı olabilecek etkileri de incelemelidir.
• Yazılım ürünü mühendisliği aktiviteleri içsel ve dışsal özellikleri de içermelidir.
• Çalışmalar, kullanıcı beklentileri göz önünde tutularak tamamlanmışlık derecesini de ölçmelidir. Bu da müşteri ihtiyaçlarını anlama ve belgemede doğruluk ile sağlanabilir.

5. Yazılım Ürün Mühendisliği Temelleri

• Tüm ölçütler sorunlara yönelik olmalıdır.
• Ölçütler tek başlarına karar vermeye yeterli olmamalıdır. Genelde, karar aşamasında birden çok ölçüt birarada değerlendirilerek yazılım ürününün kapsamlı bir karakteristiği çıkarılmalıdır.
• Ürün değerlendirmede, yazılım ürünü mühendisliği ölçütleri 2 amaca hizmet eder:
• Yazılım ürününün kalitesini ölçme ve en sonunda elde edilecek olan ürünün kalitesini tahminlemek. Bu ölçme ve tahminleme işlemleri süreçlere ve ürün bileşenlerine uygulanmalıdır.
• Ölçütler pozitif ve negatif sonuçları ortaya çıkarmalıdır.
• Ölçütler tüm müşterileri desteklemelidir.
• Ölçütler, ürünün fonksiyneliğini ve kalitesini incelemeye yönelik olmalıdır.

Şekil � 1 Yazılım Ürün Geliştirme Stratejisi

6. SEI � CMM Seviye 3 Kapsamında Yazılım Ürün Mühendisliği Nasıl Yapılmalıdır?

Bu bölümde, yazılım ürün mühendisliğinin SEI-CMM üçüncü seviyede nasıl düzgün, kontrollü bir şekilde ele alınacağı hakkında bilgi verilecektir. Aşağıdaki işlemler �adım adım� ilerleme şeklinde anlatılmıştır.

6.1. Hedefler

• Yazılım mühendisliği görevleri belirleme, bir araya getirme ve yazılım üretmek üzere gerçekleştirmek.
• Yazılım ürünlerininin birbirileriyle uyumlu ve tutarlı olmasını sağlamak.

Yapılan tüm işler, yukarıdaki iki hedef doğrultusunda yapılmalıdır.

6.2. Yapılacak İşler Hakkında

Proje, gereken yazılım mühendisliği aktivitelerini yapabilmek için yazılı bir anlaşmayı baz alır.Bu belge aşağıdakiler belirlenmiştir:

• Yazılım mühendisliği görevleri, proje yazılım sürecine uyumlu bir şekilde yapılmalıdır.
• Yazılım ürünleri yaratmak için uygun araçlar ve metodlar kullanılmalıdır.
• Yazılım planları, görevleri, ürünleri yazılıma atanmış olan sistem gereksinimleri ile uygunluk göstermelidir.

6.3. Yapılması Gerekenler

1. Yazılım mühendisliği görevlerini yerine getirebilmek için gerekli olan yeterli kaynağın ve bütçenin bulunması;

• Yazılım takımında bireyler aşağıdaki listedeki yazılım mühendislği görevlerini yapmalıdırlar:

i. Yazılım gereksinimleri analizi ii.Yazılım tasarımı

iii. Kodlama iv.Test etme

v.Yazılım bakımı

• Yazılım mühendisliği görevlerini destekleyecek araçlar belirlenmeli ve kullanıma sunulmalıdır.

Genel Araç Örnekleri: i. İş istasyonları

ii.Veritabanı yönetim sistemleri iii. Çevirim-içi yardımları

iv. Grafik araçları v. İnteraktif belgeleme araçları

vi. Ofis araçları (word, excel vs�) Yazılım Mühendisliği Araç Örnekleri:

i. Gereksinim takibi araçları ii. Belirtim araçları

iii. Prototip oluşturma araçları iv. Simulasyon araçları

v. Modelleme araçları Yazılım Kodlama Araç Örnekleri:

i. Editörler ii. Derleyiciler

iii. Çıktı makineleri Yazılım Test Araç Örnekleri:

i. Test yönetim araçları ii. Test yaratıcılar

iii. Test profili hazırlayıcılar iv. Test analiz araçları

2. Yazılım mühendisliği ekibinin, gerekli teknik görevleri yapabilmesi için gerekli olan eğitimin sağlanması Yazılım mühendisliği ekibi, uygulama alanı ile ilgili eğitim almalıdır çünkü uygulama yapılacak olan alanı (bankacılık, tıp, vs�) tam olarak kavramak zorundadırlar.

Yazılım Gereksinimleri Analizi İçin Eğitim Örnekleri: i. Yazılım gereksinimleri analizi prensipleri, temelleri

ii. Bakımı yapılan yazılımın var olan gereksinimlerini inceleme iii. Yazılım gereksinimleri bulabilmek için son kullanıcılar ile görüşme yapma yeteneğinin gelişimi

iv. Yazılım gereksinimleri analizi için projede seçilmiş olan araçların kullanımını, metodları, standartları öğrenim Yazılım Tasarımı İçin Eğitim Örnekleri:

i. Tasarım kapsamları ii. Var olan yazılım tasarımını inceleme

iii. Yazılım tasarımında kullanılacak olan araç, metot, standardları öğrenme Kodlama İçin Eğitim Örnekleri:

i. Seçilen programlama dilleri eğitimi ii. Var olan yazılımların kodlarını inceleme

iii. Kodlamada kullanılacak olan araç, metot, standardları öğrenme iv. Birim testi tekniklerini öğrenme

Yazılım Testi İçin Eğitim Örnekleri: i. Doğrulama metotları

ii. Test planlama iii. Testte kullanılacak olan araç, metot, standardları öğrenim

iv. Tamamlanma kriterlerini öğrenim 3. Yazılım mühendsiliği ekibi için, ilgili yazılım mühendisliği konuları hakkında oryantasyon yapılması.

Örnek Yazılım Mühendsiliği Konuları: i. Yazılım gereksinimleri analizi

ii. Yazılım tasarımı iii. Test

iv. Kodlama v. Yazılım yapılanışı yönetimi

vi. Yazılım kalite güvencesi 4. Yazılım yöneticisi ve diğre proje yöneticileri için yazılım projesinin teknik özellikleri hakkında oryantasyona yapılması

Örnek Oryantasyonlar: i. Yazılım mühendisliği metotları ve araçları

ii. Uygulama alanı, sahası iii. Yazılımla ilgili ürünler

iv. Seçilen yazılım metodu ve araçları ile projenin nasıl yönetileceği hakkında bilgi

6.4. Yapılan Aktiviteler

1. Projenin önceden belirlenmiş olan yazılım sürecine yazılım mühendisliği metotları ve araçları eklenir.

• Yazılım mühendisliği görevleri, projenin belirlenmiş olan yazılım sürecine göre eklenir.
• Projede kullanılması yararlı olacak olan metodlar ve araçlar seçilir.

Not: Aday metotlar, kurumun standardlarına uygunluk, projenin tanımlanmış yazılım sürecine uygunluk, varolan yetenekler, eğitim olanakları, gereksinimler, kullanım kolaylığı, destek hizmetleri açılarından değerlendirilmelidir

• Seçimdeki kriterler belgenir.

2. Projeye uygun olan yazılım yapılanışı yönetimi modelleri seçilir ve kullanılır. Örnek Yazılım Yapılanış Yönetimi Modelleri:

i. Seçerek alma modeli ii. Bileşim modelleri

iii. İşlem modelleri iv. Değişim modelleri

• Yazılım geliştirmede kullanılan araçlar yazılım yapılanış yönetimi tarafından kontrol edilir.

3. Yazılım gereksinimleri, yazılıma atanmış olan gereksinimlerin sistematik olarak düzenli bir şekilde analiz edilmesiyle geliştirilir, belgelenir ve doğrulanır.

• Yazılım gereksinimlerini geliştiren bireyler, gereksinimleri analiz ederek gereksinimlerin gerçekten yazılım gereksinimleri olup olmadıklarını kontrol ederler.

Yazılım gereksinimleri, yazılım fonksiyonlarını, performansı, donanım ve diğer sitemlerle olan arayüzleri incelerler.

• Yazılım gereksinimlerini belirleyebilmek için etkin metotlar kullanılır.

Örnek Gereksinim Analizi metotları: i. Fonskiyonel ayrıştırma

ii. Nesneye yönelik ayrıştırma iii. Simulasyonlar

iv. Modellemeler v. Prototip oluşturma

vi. Senaryo geliştirme

• Gereksinimlerin analizi sürecinin sonucları, proje standardlarına uygun bir şekilde belgelenir.
• Yazılım gereksinimlerinin projeye uygun olup olmadıkları, gerçekleştirilmelerinin mümkün olup olmadıkları, birbirleriyle tutarlılıkları, tamamlanmışlıkları analiz edilir.

Not: yazılım gereksinimleri ile ilgili problemler sistem gereksinimlerinden sorumlu takım tarafından belirlenir ve gerekli değişiklikler gereksinimlere uygulanır.

• Yazılım gereksinimleri belgelenir.
• Yazılım test ve doğrulama ekibi gereksinimleri inceleyerek test edilebilir olup olmadıklarını inceler.
• Her yazılım gereksinimi için doğrulama ve test işlemlerinin yapılabilirliği belirlenir ve belgelenir.

Örnek Doğrulama Metodları: i. Demo oluşturma

ii. Sistem testi iii. Kabul edilirlik testi

iv. Analiz v. İnceleme

• Yazılım gereksinimleri belgeleri, tamamlanmış olarak kabul edilmeden önce son bir kez gözden geçirilir.

Gözden Geçirme İşlemine Katılanlar:

i. Proje yöneticisi ii. Sistem mühendisliği yöneticisi

iii. Proje yazılım yöneticisi iv. Yazılım test yöneticisi

• Yazılım gereksinimleri belgesi kabul edilir.
• Yazılım gereksinimleri belgesi son kullanıcılar ve müşteri tarafından gözden geçirilir.
• Yazılım gereksinimleri belgesi yazılım yapılanışı yönetiminin kontrolüne geçirilir.
• Gereksinimler değişince, yazılım gereksinimleri belgesi de gerekli şekilde değiştirilir.

4. Projenin tanımlanmış yazılım süreci göz önünde tutularak yazılım tasarımı geliştirilir, belgenir, doğrulama yapılır. Yazılım Tasarımı aşağıdakileri içerir:

- Tasarım kriterleri geliştirilir ve gözden geçirilir. Bu kriterler:

• Doğrulanabilirlik
• Yapım kolaylığı
• Basitlik
• Planlama kolaylığı�dır.

- Tasarım ile ilgilenenler, yazılım gereksinimlerini gözden geçirerek yazılım tasarımını etkileyen konular incelenir.

- Uygun olduğu durumlarda, uygulama standardları kullanılır. Bu standardlar:

• İşletim sistemi arayüzü standardları
• İnsan-bilgisayar arayüzleri standardları
• Ağ arayüzü standardları�dır.

- Yazılım tasarımı için etkin yöntemler kullanılır. Bu yöntemler:

• Prototip oluşturma
• Yapısal modeller
• Tasarım yeniden kullanılabilirliği
• Nesneye yönelik tasarım
• Kritik sistem analizi�dir.

- Yazılım mimarisi, yazılım yaşam döngüsü kısıtlamaları ve kullanılan teknoloji göz önüne alınarak belirlenir. (Yazılım mimarisi iyi tanımlanmış arayüzlerle, üst seviye bir çerçeve anlamına gelmektedir.) - Yazılım mimarisi, yazılımı etkileyen mimari konularının tanımlanıp çözümlendiğini kontrol etmek için gözden geçirilir.

- Yazılım mimarisi üzerine yazılımın detaylı tasarımı yaratılır. - Yazılım tasarımı belgelenir.

• Yazılım tasarımı belgesi; yazılım bileşenlerini, bileşenler arasındaki arayüzleri, diğer yazılım sistemleriyle olan arayüzleri kapsar.

- Yazılım tasarımı dökümanının yönetimi, yazılım yapılanış yönetimi kontrolüne verilir.

- Gereksinimler değiştiği takdirde, yazılım tasarımı da buna uygun olarak değiştirilir. 5. Projenin tanımlı yazılım sürecine bağlı kalınarak, yazılım gereksinimlerinin ve tasarımının gerçekleştirilmesi için yazılım kodları geliştirilir, bakımı yapılır, belgelenir, doğrulanır.

• Kodlama ile uğraşanlar, yazılım tasarımını ve gereksinimlerini gözden geçirerek kodlamayı ilgilendiren konuların tanımlanıp çözüldüğünü garantilerler.
• Kodlamada etkin kodlama yöntemleri uygulanır.

Örnek yöntemler: i. Yapısal kodlama

ii. Yeniden kullanılabilir kod.

• Kodlama, müşteri istekleri, kritiklik, zorluk gibi kriterler dikkate alınarak oluşturulan bir plan çerçevesinde yürütülür.
• Kod, yazılım yapılanış yönetimi kontrolüne verilir.
• Yazılım gereksinimleri ve tasarımı değiştiği takdirde gerekli değişiklikler yapılır.

6. Projenin tanımlanmış yazılım sürecine göre test yapılır.

• Müşteri ve son kullanıcılar ile birlikte test kriterleri belirlenir.
• Yazılımı test etmek için etkin yöntemler kullanılır.
• Testlerin yeterliliği, testlerin uygulanma seviyesine göre belirlenir.

Örnek seviyeler: i. Birim testi

ii. Birleştirme testi

iii. Sistem testi

iv. Kabuledilirlik testi Ayrıca fonskyionel, yapısal, istatistiksel testler de önemlidir.

• Her test seviyesi için test hazırlık kriterleri belirlenir ve kullanılır.

Örnek kriterler:

i. Birleştirme testinden önce birim testinin sağlıklı bir şekilde bitmiş olması

ii. Sistem testine başlamadan önce birleştirme testinin sağlıklı bir şekilde bitmesi

iii. Kabul edilirlik testinden önce testin hazır olup olmadığının kontrol edilmesi

• Yazılımın veya ortamın değişmesi durumunda regresyon testleri yapılır.
• Test planı, süreçleri kullanılmadan önce gözden geçirilir.
• Test planları, süreçleri kontrol edilir ve yönetilir.

Kontrol etmek ve yönetmek, programın belirli bir zamandaki sürümünün biliniyor olması, değişikliklerin kontrollü yapılması anlamına gelmektedir.

• Yazılım gereksinimleri, tasarımı, kodlama değiştiği zamanlarda test planları, süreçleri de buna bağlı olarak değiştirilir.

7. Projenin tanımlanmış yazılım sürecine göre birleştirme testleri yapılır.

• Yazılım geliştirme planına bağlı olarak birleştirme testleri planları belgelenir.
• Yazılım gereksinimleri, tasarımı, kabul edilirlik testlerinden sorumlu kişiler, birleştirme testlerini, süreçlerini gözden geçirir.
• Yazılım birleştirme testleri yazılım gereksinimleri dökümanına bağlı kalarak gerçekleştirilir.

8. Yazılımın gereksinimleri karşılayıp karşılamadığını görmek için sistem testleri ve kabul edilirlik testleri yapılır.Sistem testleri, gereksinimlerin ne kadar karşılandığını ortaya koyar.Kabul edilirlik testleri ise, müşteri ve son kullanıcıya yazılımın tüm gereksinimleri karşıladığını göstermek için yapılır.

• Yazılımı test etmek için gerekli kaynaklar, önceden yapılır.

Örnek hazırlıklar: i. Test dökümanı hazırlama

ii. Test kaynaklarını planlama

iii. Test geliştirme iv. Simülator geliştirme

• Sistem testi ve kabuledilirlik testi, test planı ile belgelenir ve son kullanıcılar tarafından gözden geçirilir.

Test planının içeriği: i. Genel test yaklaşımı

ii. Müşterinin ve son kullanıcıların sorumlulukları

iii. Test özellikleri, aletleri, test destek gereksinimleri

iv. Kabul edilirlik kriterleri

• Test süreçleri, yazılım geliştiricilerinden bağımsız bir grup tarafından hazırlanır.
• Hazırlanan test süreçleri, müşteriler, son kullanıcılar tarafından gözden geçirilir ve onaylanır.
• Test sırasında karşılaşılan problemler raporlanır.
• Test sonuçları da yazılımın gereksinimleri karşılayıp karşılayamadığını bildirecek şekilde raporlanır.
• Test sonuçları yönetimi yapılır.

9. Yazılımın bakımının yapılması ve işletilmesi için gerekli dökümanlar, yazılımın proje yaşam döngüsü içinde yaratılır.

• Dökümanları geliştirmek için uygun olan araçlar kullanılır.

Örnek araçlar: i. Kelime işlemcileri

ii. Döküman tekrar kullanılabilirliğini sağlayan raporlar

• Raporlama uzmanları, döükmanın gelişmesi, bakımı, planlanması gibi evrelerde aktif olarak yer alırlar.
• Dökümanın ilk versiyonları, proje yaşam döngüsü içinde çok erken bir zamanda yaratılır.

Dökümanın bölümleri olarak aşağıdakileri sayabiliriz: i. Eğitim dökümanları

ii. Kullanım klavuzu

iii. Operatör klavuzu iv. Bakım klavuzu

• Dökümanın son hali, kabul edilebilirlik testi ile karşılaştırılır.
• Döküman gözden geçirilir.
• Döküman kontrol edilir ve yönetilir.
• Son döküman, son kullanıcılar ve müşteriler tarafından onaylanır.

10. Test sonucu elde edilen veriler incelnir, analiz edilir ve hatalar bulunur.

Analiz edilen veriler: i. Hata tanımlamaları

ii. Hata kategorileri

iii. Hatanın ciddiyeti

iv. Hata içeren birim

v Hatadan etkilenen birimler

vi. Hatanın bulunduğu aktiviteler

vii. Hatanın karşılaşıldığı senaryo

viii. Hata durumundaki gerçek sonuç ve beklenen sonuç

11. Yazılım planlarını, süreç açıklamalarını, gereksinimleri, tasarımı, test planlarını, test yordamlarını içine alan yazılım ürünü için, tutarlılık sağlanır.

• Yazılım ürününün dökümanları yaratılır.
• Yazılım gereksinimleri, tasarımı, kodlaması, testleri düzenli bir şekilde takip edilir, kontrol edilir.
• Yazılı ürünlerinde, planlarında, süreç tanımlarında, aktivitelerinde olan değişiklikler analiz edilir.

i. Değişklik yapılmadan önce, değişikliğin etkisi inelenir.

ii. Gereksinimlerin değiştirilmesi istendiğinde, herhangi bir yazılım değişikliğine gidilmeden önce, gereksinimlerin değişiklikleri onaylanır.

iii. Yazılım ürünlerine, planlarına ve aktivitelerine yapılan değişiklikler koordine edilir.

iv. Değişiklikten ekilenen gruplarla iletişime girilir. Etkilenmesi olası gruplar:

- yazılım mühendisliği grubu - yazılım tahminleme grubu

- yazılım test grubu - yazılım kalite güvencesi grubu

- yazılım yapılanış yönetimi grubu

6.5. Ölçümleme & Analiz

1. Yazılım ürünün fonksiyonelliğini ve kalitesini ölçmek için ölçümlemeler yapılır.

Örnek ölçümler: i. Yazılım ürünündeki hataların sayısı, ciddiyeti, tipleri

ii. Güvenlik, sistem yapılanışı, performans, güvenilirlik ölçümleri

2. Yazılım ürünü mühendislik aktivitelerini ölçmek için ölçümlemeler yapılır.

Örnek ölçümler:

i. Her gereksinimin proje yaşam döngüsündeki durumu ii. Ciddiyetine ve sürdüğü süreye göre problem raporları incelemesi

iii. Gereksinimlerdeki değişiklik aktiviteleri vi. Önerilen değişiklik sayısı

v. Değişiklikleri gerçekleştirmek için gerekli maliyet

6.6. Gerçekleştirim-Kodlama Doğrulaması

1. Üst yönetim tarafından periyodik olarak yazılım ürün mühendisliği aktiviteleri denetlenir.

2. Proje yöneticisi tarafından periyodik olarak yazılım ürün mühendisliği aktiviteleri denetlenir. Bu denetlemeler, aşağıdaki maddelerle test edilir:

i. Yazılım gereksinimlerinin tamamlanmış, doğru, tutarlı, uygulanabilir, test edilebilir olduğu, ii. Her yazılım mühendisliği görevinin tamamlanmışlık ve hazır olma kriterlerine uygunluğu,

iii.Yazılım ürünlerinin belirlenen standardlara ve gereksinimlere uygunluğu iv.Gerekli testlerin yapıldığı

v.Yazılıma uygulanan kabul edilirlik testlerinin önceden belirlenmiş plan ve yordamlara uygun olduğu vi.Testlerin kabul edilirlik kriterlerini sağladığı

vii.Testlerin yeterli olduğu viii.Testlerin kaydedildiği ve tamamlandığı

Yukarıdaki adımlardan geçildikten sonra, projemizin standardlara ugyunluğundan söz edilebilir. Standardlara uygunluk için anlatılan rehber, tabi ki mutlaka uygulanması gereken bir rehber değildir. Farklı yöntemler ile, farklı bakış açıları ile de yazılım ürün mühendisliği kapsamında CMM Seviye-3 kriterleri tanımlanabilir fakat yukarıda anlatılan rehber, genelde kabul edilmiş ve uygulanmaktadır.

7. KAYNAKÇA

Practical Software Measurement, A foundation for objective project management, PSM SPE Workshop, Office of the Under Secretary of Defense, Acquisition and Technology

SSC SAN DIEGO POLICY FOR SOFTWARE PRODUCT ENGINEERING, Version 1.1 - 10/9/97

Level 3 - Software Product Engineering, Software Product Engineering a key process area for level 3: Defined, www.sei.org

Selected Key Practices, http://www.dfki.de/fluids/References.html#Paulk:93b

www.stickyminds.com

Software Product Engineering Workshop 1999.pdf

Software Product Engineering Workshop 2000.pdf

http://www.dfki.de/fluids/Software_Quality_Assurance_Management.html

Şekil 1. CommandBehavior Davranışları

Tablo 1. CommandBehavior Davranışları

Şimdi dilerseniz basit Console uygulamaları ile, yukarıdaki davranışların işleyişlerini inceleyelim. CommandBehavior. CloseConnection durumunu önceki makalemizde işlediğimiz için tekrar işleme gereği duymuyorum. Şimdi en çok kullanacağımız davranışlardan birisi olan SingleRow davranışına bakalım. Uygulamamız ID isimli PrimaryKey alanı üzerinden bir sorgu çalışıtırıyor. Dönen veri kümesinin tek bir satırdan oluşacağı kesindir. Bu durum, SingelRow davranışını kullanmak için en ideal durumdur.