KURULUŞLARIN YAZILIM ŞARTNAMELERİ, NİTELİKLERİ, BAKIM VE EĞİTİM STANDARTLARI ARAŞTIRMASI

KURULUŞLARIN Y AZILIM ŞARTNAMELERİ,

NİTELİKLERİ, BAKIM VE EĞİTİM STANDARTLARI

ARAŞTIRMASI

1991 yılında DPT;

A Türkiye'de Yazılım Üretimi ve İnsan Gücü Araştırması

*• Kuruluşların Yazılım Şartnameleri, Nitelikleri, Bakım ve Eğitim Standartları Araştırması,

** Kuruluşların Yazılım Gereksinimlerini Belirleme Araştırması

*• Uluslararası Yazılım Sektörünü İnceleme ve Türkiye'nin

Bu Alandaki Olası Yerini Belirleme Araştırması

konularında dön: araştırma projesinin gerçekleştirilmesi görevini TÜBiTAK'a vermişti.

Türkiye'nin yarınına yönelik politikalarının saptanmasına önemli katkılar da bulunacağına inandığımız bu proje sonuç raporlarının daha geniş çevrelere duyurulmasında büyük yarar görmekteyiz.

Bu sayımızda, Teletaş uzmanlarınca hazırlanan "Kuruluşların Ya

zılım Şartnameleri, Nitelikleri, Bakım ve Eğitim Standartları Araştır

ması" başlıklı raporu yayınlıyoruz.

J |

7/ OC

0. KAPSAM VE ORGANİZASY ON

0.1. Kapsam 0.2. Organizasyon

Bu rapor, yazılım ihtiyaçlarını satın alma ya da sipariş yoluyla, kendi bünyelerinin dışında karşılamak durumunda kalan kuruluşların. Yazılım Teknik Şartnamelerini hazırlama sürecinde izleyecekleri yöntemler ve Yazılım Teknik Şartnamesinin nitelikleri ve belgelendirme, eğitim, destek ve bakım hizmetleri standartları konularında yönlendirici olma amacını taşımaktadır.

Bölüm 1'de başlıca yazılım türleri, yazılım edinme biçimleri tanımlanmakta. Yazılım Yaşam Döngüsü kavramı aglmakta ve raporun izleyen bölümlerine çatı teşkil edecek olan Yazılım Edinme Aşamaları tanıtılmaktadır..

Bölüm 2'de Kullanıcı İhtiyaçları Tanım Belgesi'nin tanımı, kapsamı ve hazırlanmasındaki ilkeler ele alınmaktadır.

• Bu raporun kapsamı, mevcut ya da saptanmış bir donanım platformu üzerinde yürütülecek olan yazılımlara yöneliktir. Raporda, yazılımın kendisi dışındaki, donanım

Bölüm 3, raporun temelini oluşturmaktadır. Bu bölümde. Yazılım Teknik Şartnamesi'nin kapsamı ve hazırlanış yöntemleri anlatılmaktadır.

ve çevre koşullan gibi tüm diğer unsurların Yazılım Teknik Şartnamesinde ifade edilen önceden belirlenmiş olduğu kabul edilmektedir. hususların dışında, genel olarak belgelendirme,

• Anahtar teslimi bilgi işlem sistemlerinin ediniminde sözkonusu olan, ihtiyaç duyulan donanım ve yazılım birimlerinin etkileşimli olarak birlikte saptandığı süreç bu raporun

yazılım geliştirme sürecinin izlenebilirliği, eğitim, bakım ve destek hizmetlerine ilişkin temel noktalar raporun izleyen bölümlerinde ele alınmaktadır. Bu bağlamda,

kapsamının dışındadır. Bölüm 4, sipariş yoluyla yazılım ediniminde,

• Raporda, uygulama yazılımları ele alınmaktadır. Sistem yazılımlarının edinimi ve ilgili standartlar bu raporun kapsamı dışında

yazılım sürecinin gözlenebilir ve denetlenebilirliği açısından dikkate alınması gereken genel ilkelere ,

bırakılmıştır. Bölüm 5, genel olarak yazılım test ve kabul

• Yazılımın edinimi açısından bu rapor, hazır prosedürlerine;

paket satın alımı ve/veya sipariş ile yazılım geliştirme durumlarına uygulanabilir. Sözkonusu iki farklı yazılım edinimi yolunda izlenecek olan yöntemlerdeki farklılıklar, raporun ilgili

Bölüm 6, genel olarak, yazılımla birlikte müşteriye teslim edilmesi gereken belgelere;

Bölüm 7 ise bakım, eğitim ve destek

bölümlerinde belirtilmektedir. hizmetlerine ayrılmıştır.

176 387 E L E K T R İ K MÜHENDİSLİĞİ

1. GİRİŞ

1.1. Yazılım

Yazılım, bir bilgisayar sistemi üzerinde işletilerek belirli bir işlevi yerine getiren bilgisayar programı, prosedürler, kurallar, ilişkin veri ve belgeler bütünüdür.

1.2. Yazılım Türleri

Yazılım, en genel biçimde,

1) Sistem yazılımı, 2) Uygulama yazılımı olarak iki kategoride ele alınabilir [7]. Uygulama yazılımlarının ediniminde kuruluşların izleye cekleri yöntemler bu raporun araştırma konusunu oluş turmaktadır. Sistem yazılımlarının edinimini ise, Bölüm O'da belirtildiği üzere, bu raporun kapsamı dışındadır. Bu iki yazılım türünün tanımını Bölüm 1.2.1 ve 1.2.2'de veril mektedir.

1.2.1. Sistem Yazılımı

Sistem yazılımı, özel bir bilgisayar sistemi ya da bilgisa yar sistemi ailesi için tasarlanmış, sistemin ve ilişkili programların işletilmesi ve bakımını gerçekleştiren yazı lımdır. Örnek olarak, işletim sistemi, derleyici ve yardım cı programlar v.b. verilebilir.

1.2.2. Uygulama Yazılımı

Uygulama yazılımı, bir bilgisayar sisteminin özel bir iş levsel kullanımı için üretilmiş yazılımdır. Örnek olarak, hava trafik denetim yazılımı, muhasebe yazılımı, kelime işlem yazılımı v.b. verilebilir.

1.3. Yazılım Edinme Türleri

Yazılım ihtiyacı olan kuruluşlar bu ihtiyaçlarını aşağıdaki yollardan biriyle karşılayabilirler:

1) Yazılımı, kendi bünyeleri içinde geliştirebilirler.

2) Yazılımı, hazır olarak, piyasadan satın alabilirler.

3) Yazılımı, piyasadaki hazır yazılım araçlarını alarak, kuruluşun ihtiyaçlarına göre konfigürasyonunu ve enteg rasyonunu yaptırabilirler.

4) Yazılımı, sipariş vererek geliştlrtebilirler.

Madde 1'de belirtilen, kuruluşların yazılımlarını kendileri nin geliştirmeleri seçeneği bu raporun kapsamı dışında dır.

Raporun izleyen bölümlerinde, Madde 2 ve 3'de belirti len seçeneklerin her Idsi de »atın alma yoluyla yazılım edinimi adı altında geçecektir. Madde 4'de belirtilen se çenek ise sipariş yoluyla yazılım edinimi olarak adlan dırılacaktır. Her iki durumda da izlenecek yöntemler ve uygulanacak standartlar bakımından ortak noktalar mev cuttur. Farklılıklar ise, sözkonusu olan yerlerde ayrıca belirtilecektir. Nihayet, sipariş yoluyla yazılım edinimin de, yazılımı geliştiren firma ile yazılım ihtiyacı olan kuru luş arasında, yazılım geliştirme sürecinin takibine yöne lik ilişkilerin düzenlenmesi ayrıca ele alınması gereken bir alanı oluşturmaktadır. Bu alan, "Yazılım Geliştirme Gözetim ve Denetimi" başlığı altında Bölüm 4'de ele alı nacaktır.

1.4. Yazılım Yaşam Döngüsü

Yazılım Yaşam Döngüsü (Softvvare Life Cycle), bir yazı lım ihtiyacının ortaya çıktığı andan başlayarak, yazılımın tüm geliştirme ve bakım sü reçlerini kapsayan zaman ara lığı olarak tanımlanır [29].

Yazılım mühendisliği literatü ründe çeşitli Yazılım Yaşam Döngüsü Modelleri bulunmak — _ — _ _ _ tadır. Bu modeller Yazılım Ya şam Döngüsünü, temel yazılım geliştirme ve bakım faali yetlerini kapsayan ve belirli ürünlerle sonuçlanan evreler türünden tanımlarlar. Yazılım Yaşam Döngüsünün, "Ya zılım Geliştirme ve Bakım Evreleri" türünden modellen mesi, ilgili süreçlerin izlenebilir ve denetlenebilir olması na olanak sağlar. Her bir evre yazılım geliştirme ve bakım süreci için bir kilometre taşı teşkil eden ürünlerle sonuçlanır. Bu ürünler, yazılım belgeleri, planları, rapor lar ya da yazılım modülleri olabilir.

Yazılım Yaşam döngüsü modelleri içerisinde en eski ve yaygın olarak kullanılan model, en genel hatlarıyla Şekil 1'de verilmektedir. Bu modelde Yazılım Geliştirme ve Bakım Evrelerinin ardışıl olarak birbirlerini izledikleri göz lenmektedir. Gerçekte bu evreler birbirlerini ardışıl ola rak izlemezler, zaman içinde birbirleriyle örtüşürler. Bir diğer deyişle yazılım geliştirme doğrusal değil "iterative" bir süreçtir. Bir evreden önceki evrelere dönüş mümkün ve kimi kez de gereklidir. Örneğin test sırasında tasarım hatalarının gözlenmesi tasarım evrelerine dönüşü gerek li kılabilir. Diğer yandan, özellikle doğrulanma (verificati on) amaçları açısından ardarda gelen evreler arasında döngüler sözkonusu olabilir, örneğin tasarımın doğru lanması süreci, Üst Düzey Tasarım ile Yazılım Özellikleri ve İşlevleri Tanım Evreleri arasında gidiş dönüşleri ge rekli kılar. Nihayet yeniden kulanılabilir yazılım modülleri

387 E L E K T R İ K 4 7 7 MÜHENDİSLİĞİ | / #

ni destekleyen araçlar, işletilebilen tanım dilleri ve bunlar gibi yazılım tekniklerindeki diğer modern gelişmeler Y a zılım Geliştirme ve BakımEvrelerinin birbirine paralel sü reçler halinde düzenlenebilmesine olanak sağlamıştır.

1.5 Y azılım Edinme Aşamaları

Yazılım gereksinimi olan kuruluş ile yazılımı sağlayacak olan (satıcı ya da üretici firma arasındaki ilişkiler, üç ayrı aşamada ele alınabilir:

1) Sözleşme Öncesi Yazılım Tanımlama Aşaması

Problem

2) Yazılım Geliştirme Evreleri 3) İşletme ve Bakım Dönemi

KULLANICI İHTİYAÇLARI TANIM EVRESİ

YAZILIM ÖZELLİKLERİ VE İŞLEVLERİ TANIM EVRESİ

ÜST DÜZEY TASARIM EVRESİ

AY RINTILI TASARIM EVRESİ

KODLAMAVETEST EVRESİ

ENTEGRASY ON VE TEST EVRESİ

İŞLETME VE BAKİM EVRESİ

Bu raporda, yazılımın tanımlanması (sözleşme öncesi evre), geliştirilmesi ve işletim ve bakımı dönemleri bo yunca, yazılım ihtiyacı olan kuruluş, yazılım satıcısı/ üreticisi firma ve olası diğer firma ve kuruluşlar arasında ki ilişkiler, yürütülecek faaliyetler ve bu faaliyetlerin ürün leri tanımlanmaktadır. Satın alma yoluyla yazılım edini minde, Yazılım Geliştirme Evresi mevcut değildir.

Şekil 2, Sözleşme Öncesi Yazılım Tanımlama Aşaması nı göstermektedir. Bu aşamada yazılım için kullanıcı ihti yaçları tanımlanır ve Yazılım Teknik Şartnamesi hazırla nır. Aşama, müşteri kuruluş ve yazılım satıcısı/üreticisi firma arasındaki sözleşme ile sonuçlanır. İlgili belgelerin tanım ve hazırlanış yöntemleri Bölüm 2 ve 3'de verilmek tedir.

Yazılım ihtiyacının hazır bir paketle karşılanamadığı ve dolayısıyla yazılımın sipariş edileceği durumlarda söz leşme sonrasını Yazılım Geliştirme Evreleri izleyecektir. Bu evreye ilişkin aşamalar, yazılımın türüne, varolan araçların ve teknik birikimin düzeyine bağlı olarak farklı lıklar gösterebilir. Yazılım Teknik Şartnamesinde belirti len özelliklere bağlı olarak müşteri kuruluş ile üretici fir ma arasında anlaşmaya varılan ve sözleşmeyle onaylanan Yazılım Geliştirme Planı asıl aşamaları belir ler. Ancak en genel şekliyle bu evreler, Şekil 3'deki gibi modellenebilir. Şekil 3'de faaliyetlerin ayrı kutular halinde gruplandırılması olası eşzamanlı faaliyetleri ve değişik aşamalardan geri dönüşleri dışlamamaktadır. Bu evreye ilişkin genel ilkeler, ilgili belgelerin tanım ve hazırlanış yöntemleri Bölüm 4'de verilmektedir.

Yazılımın işletime alınması, işletim sırasındaki aestek hizmetlerinin verilmesi, olası yazılım hatalarının düzeltil mesi, değişen çevre koşullarına ya da isteklere göre ya zılım değişikliklerinin kotarılması faaliyetleri İşletme ve Bakım evresini oluşturmaktadır. Bu faaliyetlerin yürütül mesine ilişkin prosedürler ve ilgili belgelerin tanım ve ha zırlanış yöntemleri Bölüm 7de verilmektedir.

Yeni versiyon

Şekil 1 YAZILIM Yaşam Döngüsü 4 7 O 387 E L E K T R İ K I /O MÜHENDİSLİĞİ

2. KULLANICI İHTİY AÇLARI TANIM BELGESİ

2.1. Giriş

Bir yazılımın başarısı, kullanıcı ihtiyaçlarına yanıt verme deki yeteıiiliğiyİG ölçülür. Başarılı ve kaliteli bir yazılım, kullanıcı ihtiyaçlarını eksiksiz olarak karşılayan yazılım dır. Kullanıcı ihtiyaçlarının sağlıklı ve eksiksiz analizi bir yazılım ürünün edinilmesi sürecindeki ilk ve en önemli aşamadır.

Yazılım ihtiyacı olan kuruluş, öncelikle yazılımın yerine getirmesi gereken işlevleri ve sahip olması gereken özel likleri saptamalı ve bunları, tam ve açık bir biçimde "Kul lanıcı İhtiyaçları Tanım Bekjesi'nde belgelemelidir.

2.2. Kullanıcı ihtiyaçları Tanım Belgesi: Tanım ve Kapsamı

Kullanıcı ihtiyaçları Tanım Belgesi, kullanıcının zorunlu ve/veya opsiyonel ihtiyaçlarını olabildiğince eksiksiz ola rak ve kullanıcının doğal dilinde ifade eder.

tHTrY AÇLARMN TAMMLANMASI

Kullanıcı İhtiyaçları Tanım Belgesi, Yazılım Özellikleri ve İşlevleri Tanım Belgesi ile Yazılım Teknik Şartnamesi'nin hazırlanmasında kaynak teşkil eder. (Şekil 2)

Kullanıcı ihtiyaçları

1) İşlevsel ihtiyaçlar

2) Ortalama uyum ihtiyaçları

3) Performans, kapasite ve verimlilik ihtiyaçları

4) Bakım, eğitim ve destek ihtiyaçları

5) Desteklenmesi istenen standartlar

6) Kalite ihtiyaçları

7) Yerelleştirmeye (localization) ilişkin ihtiyaçlar başlıkları altında saptanır.

2.2.1. işlevsel İhtiyaçlar

İşlevsel ihtiyaçlar yazılımın ye rine getirmesi istenen işlevler dir. Yazılımın karşılaması iste nen temel işlevler ile karşılanmasında yarar olan yardımcı işlevler arasında ay rım yapılması gerekmektedir.

K u t a n İMIyaçian Taran

Y AZBJM ÖZELLİKLERİ VE İŞLEVLERİM»

Y AZ&JM TEKNİK ŞARTNAMESİ HAZRLANMASI

mini p ı m u n um

VESC

ŞeM 2 SÖZLEŞME öncesi Yazılım Tanımlama Aşaması

ÜST DÜZEY TASARIM AY RINTILI TASARIM KOOLAMAVETEST ENTEGRASY ON TESTLERİ

SİSTEM TESTLERİ

• Onaylanmış Y azılım Teknik Şartnamem . Y anlım özellikleri ve İşlevleri Taran

Belgesi Yanlan Geliştirme Planı • Taslak Test Planı Taslak Kullanıcı Kılavuzu

Tasanm Belgesi Test Belgesi GOncellenmiş Test Planı

• işlevsel özellikler Belgeleri Ayrıntılı Tasanm Belgeleri Modül Test Belgelen GOncellenmiş Test Planı

Program Üsteleri . Test Raporları • Test Plan

Program Üsteleri Test Raporları • Test Plan

Y az*m Paketi KutanaKılavuzu KuaancıDılgılırl

Şekil 3 Y AZIUM Geiştirme Evreleri

387 ELEKTRİK J 7 A MÜHENDİSLİĞİ | İ V

azılımda kalite,

tanımı oldukça güç ve

2.2.2. Ortama Uyum İhtiyaçları

öznel bir kavramdır. • Hizmete giriş sırasında istenen

Yazılımın üzerinde çalışacağı ve/ Her yazılım için geçerli bakım istekleri

veya etkileşimde bulunacağı kaynak lara bağlı olarak sağlaması gereken özelliklerdir. Başlıcaları aşağıda veril mektedir:

genel kalite ölçütleri tanımlamak mümkün değildir."

• İşletme sırasında istenen bakım hizmetleri

• Hata düzeltmeye yönelik istekler

1) Donanıma ve çevre birimlerine m^^^^^^^m

• Müşteri ortamına uyarlama sıra ^ m sında beklenenler

bağlı ihtiyaçlar

• Yazılımın yeni versiyonunun sağlanmasına ilişkin

beklentiler (örnek: Yazılımın işletileceği donanım, kullanıcı termi nalleri, depolama ortamı, yazıcı ve çiziciler, optik tarayı • Test gereçleri

cılar, diğer çevre birimleri ve bunların gerektirdiği özellik

ler)

• İstenen eğitimin türü ve kapsamı

2) İşletim sistemine bağlı ihtiyaçlar

2.2.5. Desteklenmesi istenen Standartlar

(örnek: Yazılımın işletileceği işletim sistemi ya da sis temleri)

3) Veri tabanına bağlı ihtiyaçlar (örnek: Varolan ya da tercih edilen Veri Tabanı Yöne tim Sistemi)

4) Haberleşme ihtiyaçları

Yazılım ihtiyacı olan kuruluşun, ihtiyaç duyduğu yazılı mın özelliklerinden bağımsız olarak, satın aldığı ya da si pariş verdiği yazılımlarda uyulmasını istediği standartlar olabilir. Bunlar, Kullanıcı İhtiyaçları Tanım Belgesinde açık olarak yeralmalıdır.

2.2.6 Kalite İhtiyaçları

(örnek: Yazılım, tek bir makinada mı yoksa bir bilgisa yar ağı üzerinde mi kullanılacak? Ağ üzerinde kullanıla cak ise desteklemesi gereken ağ mimarileri nelerdir?)

5) Varolan/planlanan diğer yazılımlarla beraber çalış ma istekleri ve kısıtları

2.2.3. Performans, Kapasite ve Verimlilik İhtiyaçları

1) Yazılımın beklenen genel performansı ve yerine ge tireceği işlevlere ilişkin performans ölçütleri verilmelidir.

Yazılımda kalite, tanımı oldukça güç ve öznel bir kav ramdır. Her yazılım için geçerli genel kalite ölçütleri ta nımlamak mümkün değildir. Her bir yazılım, kullanıcının o yazılımdan beklediklerine yanıt verme ölçüsünde kali telidir, örneğin, "güvenilirlik" (reliability) tek başına bir ka lite ölçütü değildir, ama bir kalite unsurudur. Bir yazılım, güvenilirlik derecesine göre değil, bu yazılımda güvenilir lik unsuruna duyulan ihtiyacı karşıladığı oranda kaliteli dir. Yazılım kalitesi için en uygun tanım, onun öznel içeri ğini yansıtan aşağıdaki tanımdır.

örnek: (Hız, yanıt süresi, işlem (transaction) süresi, Yazılım kalitesi, yazılımın kullanıcı ihtiyaçlarına yanıt ver

parametre duyarlılığı, v.b.)

medeki yeterlilik derecesidir.

2) Kullanıcı sayısı, veri saklama ve işleme kapasitesi v.b. kapasite ölçütleri belirlenmelidir.

3) Yazılımın bellek, merkezi işlem birimi v.b. kaynakları değerlendirme ölçütleri, eğer varsa, belirtilmelidir.

2.2.4. Bakım, Eğitim ve Destek İhtiyaçları

Kullanıcı İhtiyaçları Tanım Belgesinde yazılımın bakımı na ilişkin istekler ile istenen eğitim ve destek hizmetleri ve bu doğrultuda yazılımın sağlaması gereken özellikler belirtilmelidir. Bunların başlıcaları aşağıda verilmiştir:

• İstenen belgeler

• Belgelerin güncellenmesi prosedürleri

Yazılım ihtiyacı olan kuruluş, yazılımda kalite açısından ihtiyaç duyduğu özellikleri saptamalı ve bunları Kullanıcı ihtiyaçları Tanım Belgesi'nde belgelemelidir.

Satın alma yoluyla yazılım ediniminde kalite ihtiyaçları, yazılımın zorunlu ya da tercih nedeni olabilecek özellikle rine işaret ederler. Örneğin, kalite ihtiyaçları, güvenilirlik, emniyet, hizmette süreklilik gibi kalite unsurlarından biri ne ya da birkaçına ilişkin olup, yazılımın sahip olması ge reken zorunlu özellikleri ifade edebilirler. Ya da kullanışlı lık gibi bir kalite unsuru ile bağlantılı olup, işlevsel ve performans ihtiyaçlarının karşılanmasının yanısıra tercih nedeni teşkil edebilecek özellikleri ifade edebilirler.

Sipariş yoluyla yazılım ediniminde kalite ihtiyaçlarının be lirlenmesi ayrı bir önem taşımaktadır. Yazılımdan bekle

J O / N 387 E L E K T R İ K l O U MÜHENDİSLİĞİ

nen kalite özelikleri, yazılımın geliştirilme yöntemlerini de belirleyici olacaktır. Yazılımın, kullanıcı ihtiyaçlarına yanıt vermedeki yeterliliğinin saptanmasında Yazılım Değerlendirme (Software Reviews) Yöntemlerine ve testlere başvurulur. Ancak, yazılım kalite düzeyinin yal nızca ürün sonrası test ve incelemelerle sınanması pa halı bir yöntemdir. Yazılım ürününün kullanıcı ihtiyaçları nı karşılamada yetersiz kalması durumunda, geliştirme sürecinin önceki evrelerine, zaman ve maliyet açısından istenmeyen geriye dönüşler gerekli olacaktır. Bunun ye rine, Yazılım Geliştirme Evresinin, Yazılım Kalite İhtiyaç larına göre örgütlenmesinin sağlanması ve bu amaçla Yazılım Kalite Planının oluşturulması ve izlenmesi tercih edilmesi gereken yoldur.

7) Genişleyebilirlik (expandability), yazılımın yeni ihti yaçları karşılayabilmek amacıyla, işlevsel yeteneklerini ya da performansını artırabilme kolaylığıdır.

8) Gizlilik/bütünlük (security/irrtegrity), yazılımın, yazılı ma ya da veriye istenmeyen ya da kötü niyetli erişimi, kullanımı, değiştirmeyi ve bozmayı önleyici yetenekleri dir.

9) Doğrulanabilir* (veriftability), yazılımın doğru çalış tığının gözlenebilmesi ve denetlenebilmesi kolaylığıdır.

10) Birlikte çalışabilirlik (interoperability), yazılımın baş ka yazılım ve uygulamalarla birlikte çalışabilme yetenek leridir.

Öte yandan yazılımın kullanıcı ihtiyaçlarını karşılamada ki yeterliliğinin sağlanması kadar, yazılım maliyetinin be lirlenmesinde de yazılım kalite ihtiyaçları büyük önem ta şır. Belirli kalite unsurları (örneğin güvenilirlik ya da emniyet) geliştirme süresini ve maliyeti artırıcı yazılım geliştirme tekniklerinin ve izleme ve denetim yöntemleri nin uygulanmasını gerekli kılacaktır. Bu nedenle kalite ihtiyaçlarının doğru olarak saptanması, yazılım geliştir me sürecinin zaman ve maliyet açısından gerçekçi bir şekilde planlanmasında temel unsurlardan biridir.

11) Taşınabilirlik (portability), yazılımın kullanılageldiği ya da tasarlandığı sistemden farklı bilgisayarlarda ve iş letim sistemlerinde kullanıla bilme yeteneğidir.

12) Verimlilik (efficiency). yazılımın kendisinden bekle nen işlevselliği yerine getir mek için kaynaklarını kullan ma oranıdır.

Kalite ihtiyaçları, belirli kalite unsurları başlıkları altında gruplandırılabilir. Aşağıda belli başlı yazılım kalite unsur ları ve bunların tanımları verilmiştir.

13) Bakım kolaylığı (maintai nabilüy), yazılımda olası hata ları bulma ve düzeltme kolay lığıdır.

Yazılım Kalite Unsurları:

Aşağıda, belli başlı Yazılım Kalite Unsurları ve bunların tanımları verilmiştir [24]:

1) Güvenilirlik (reliabilrty), yazılımın, belirli koşullar al tında, tanımlanmış bir zaman aralığında hatasız çalışma olasılığıdır.

2) Emniyet (safety), yazılımın cana ya da mala zarar verecek bir durum oluşturmadan çalışma yeteneğidir.

3) Hizmette süreklilik (availability), yazılımın, ihtiyaç duyulduğunda, kimi işlevlerini yerine getirmese bile te mel işlevlerin kullanılabilir durumda olma yeteneğidir.

4) Kullanışlılık (usability). yazılımın kullanımının ve kul lanımı öğrenmenin kolaylık derecesidir.

14) Yönetilebilirlik (manageability), yazılımda destek ortamının tamamlığı ve kullanım kolaylığına ilişkindir.

15) Türkçe kalitesi, yazılımın kullanıcı arabağında ve yazılım belgelerinde kullanılan Türkçe'nin gramer ve keli me dağarcığı bakımından doğru ve tutarlı olma derecesi dir.

2.2.7. Y erelleştirmeye İlişkin İhtiyaçlar

Satın alınacak yazılımın yabancı bir firmanın ürünü oldu ğu ya da geliştirilecek yazılımın altyapısında yabancı kaynaklı yazılımların kullanılacağı durumlarda, müşteri kuruluşun bu yazılımın/yazılımların ve belgelerinin ne öl çüde yerelleştirilmesini istediği Kullanıcı İhtiyaçları Ta nım Belgesinde belirtilmelidir.

5) Yeniden kullanılabilirlik (reusability), yazılım modül lerinin başka uygulamalarda kullanılabilirliğidir.

6) Esneklik (flexibility), yazılımın farklı ortamlara uyar lanma kolaylığıdır.

2.3. Kullanıcı ihtiyaçları Tanım Belgesinin Hazırlan ması

Kullanıcı İhtiyaçları Tanım Belgesi, asıl olarak problemin

387 EELLEEKKTTRRİİKK 4 O 4 MÜHENDİSLİĞİ I ö l

tanımlanması amacını taşır. Bundan sonra, yazılımla bu problemin nasıl çözüleceğinin belirlenmesi aşaması ge lir. Çözümün modellenmesi açısından problemin sağlıklı ve eksiksiz biçimde tanımlanmasına gerek vardır.

Kullanıcı ihtiyaçlarının saptanmasında şu yöntemler izle nebilir [24]:

3. Y AZİUM TEKNİK ŞARTNAMESİ

3.1. Giriş

Yazılım ihtiyacı olan kuruluşun, ihtiyaçlarına uygun ürü nü saptamasında belirleyici olan Yazılım Teknik Şartna m esidir.

• varolan belgelerin incelenmesi,

Kuruluş, ihaleye Yazılım Teknik Şartnamesi ile çıkar.

• varsa eski sistemin kullanıcılarıyla yapılan görüşme ler,

• planlanan sistemin kullanıcıları ve planlayıcılarıyla ya pılan görüşmeler,

• anketler,

• uzmanlara hazırlatılan raporlar

Saptanan kullanıcı ihtiyaçlarının değerlendirilmesi, arala rında olası tutarsızlıkların giderilmesi ve önem derecele rinin belirlenerek Kullanıcı İhtiyaçları paragraf Tanım Belgesinde belgelendirilmesi gerekmektedir.

Kullanıcı İhtiyaçları Tanım Belgesi, Yazılım özellikleri ve İşlevleri Tanım Belgesi ile Yazılım Teknik Şartnamesinin hazırlanmasında kaynak teşkil eder.

Kullanıcı İhtiyaçları Tanım Belgesi yazılım ihtiyacı olan kuruluş tarafından hazırlanır.

Yazılım Teknik Şartnamesi, Kullanıcı İhtiyaçları Tanım Belgesi kaynak alınarak hazırlanır. (Şekil 2)

Yazılım Teknik Şartnamesi, ürünü teknik olarak tanımlar, ayrıca sipariş yoluyla yazılım ediniminde tasarıma kıla vuzluk eder ve teknik bir dille yazılır.

Yazılım Teknik Şartnamesinin hazırlanmasında, istenen yazılımın karmaşıklık derecesine ve çapına göre iki farklı yöntem izlenebilir. Kuruluş, Yazılım Teknik Şartnamesini kendi bünyesi içinde oluşturabileceği gibi, sözkonusu şartnamenin hazırlanması görevini bir diğer firma ya da kuruluşa devredebilir. Yazılım Teknik Şartnamesinin ha zırlanmasına ilişkin prosedürler Bölüm 3.3'de ele alın maktadır.

3.2. Y azılım Teknik Şartnamesi: Tanım ve Kapsamı

Yazılım Teknik Şartnamesi, yazılım ürününden beklenen

1) bütün teknik özellikleri,

2) kalite özelliklerini,

tanımlayan ve

3) yazılımla birlikte istenen belgelerin tür ve niteliklerini,

4) istenen eğitim hizmetlerini,

5) bakım ve destek isteklerini,

6) yazılım test ve kabul aşamalarını,

belirten ve

7) yazılımın sipariş yoluyla yaptırılması durumunda, ya zılım geliştirme sürecinin aşamalarını ve uygulanacak yazılım geliştirme denetim yöntemlerini de saptayan bel gedir.

Yazılımın beklenen teknik özellikleri ile kalite özellikleri, Yazılım özelikleri ve işlevleri Tanım Belgesinde ifade edilir ve adı geçen belge Yazılım Teknik Şartnamesinin önemli bir bölümünü oluşturur.

182 387 E L E K T R İ K MÜHENDİSLİĞİ

3.2.1. Y azılım özellikleri ve İşlevleri Tanım Belgesi (Y ÖİTB): Tanım ve Kapsamı

Yazılım Özellikleri ve İşlevleri Tanım Belgesi (Softvvare Requirement Specification), bir yazılımı bütün teknik ve kalite özellikleriyle tanımlayan belgedir [11].

Yazılım özellikleri ve İşlevleri Tanım belgesi, Kullanıcı İhtiyaçları Tanım Belgesinden hareketle yazılır. (Şekil 2)

Yazılım özellikleri ve İşlevleri Tanım belgesi, Yazılım Teknik Şartnamesinin bir bölümünü oluşturur. (Şekil 2)

Yazılım özellikleri ve İşlevleri Tanım Belgesi, ürünü tek nik olarak tanımlamaya, ayrıca sipariş yoluyla yazılım ediniminde tasarıma kılavuzluk etmeye elverişli teknik bir dille yazılır.

Yazılım Özellikleri ve İşlevleri Tanım Belgesi'nde ifade edilen her yazılım isteri yazılımın beklenen temel bir özelliği ve işlevini tanımlar. Yazılım isterleri, Kullanıcı İh tiyaçları Tanım Belgesinde ifade edilen kullanıcı ihtiyaç larından kaynaklanır. Kullanıcı İhtiyaçları Tanım belgesi, çözümlenmesi gereken problemi tanımlarken, Yazılım Özellikleri ve İşlevleri Tanım Belgesi tanımlanan proble min formel bir dille ifadesini ve modellenmesini sağlar.

Yazılım Özellikleri ve İşlevleri Tanım Belgesi, yazılım is terlerinin tümünü, doğru ve eksiksiz olarak tanımlamalı, ancak yazılımın geliştirilme ve bakım sürecine ilişkin ay rıntılara ve yazılımla birlikte istenen ve Yazılım Teknik Şartnamesinde yer alacak olan hizmetlerin tanımına gir memelidir. Kaynak [4] ve Kaynak [11], Yazılım Özellikleri ve İşlevleri Tanım Belgesinin hazırlanmasında temel başvuru kaynaklarını oluştururlar.

Yazılım isterleri, kullanıcı ihtiyaçlarıyla kısmen örtüşen başlıklar altında toplanır.

1) İşlevsel isterler

2) Çevre ile arabağlar

3) Performans, kapasite ve verimlilik isterleri

4) Kalite isterleri

5) Desteklenmesi gereken standartlar

6) Yerelleştirme isterleri

3.2.1.1. İşlevsel İsterler

İşlevsel isterler, yazılımın yerine getirmesi gereken işlev leri tanımlar. Yazılımın karşılaması istenen temel işlevler ile karşılanmasında yarar olan yardımcı işlevler arasında ayrım yapılması gerekmektedir.

Yazılımın İşlevsel İsterlerinin Tanımlanması Yöntemleri:

Yazılımın işlevsel isterlerinin ifadesinde

2) Örnek kullanarak davranışın betimlenmesi

3) Modelleme yöntemlerinden biri ya da bir kaçı kullanılabilir [11]. Yazı lımdan beklenen işlevsel özelliklerin saptanmasında kul lanıcı kılavuzunun taslağının hazırlanması yararlı ve yar dımcı bir etkinlik olacaktır.

Yazılımın istenen davranışının betimlenmesinde giriş/ çıkış çifti dizilerinin tanımlan ması kullanılan etkin yöntem lerden biridir. Tanımlanan ya zılımın özelliklerine bağlı olarak farklı yöntemler izlene bilir:

1) Kimi yazılımların davranışı en iyi şekilde istenen çıkışla rın tanımlanmasıyla betimle nebilir, (örneğin raporlama _ _ _ — _ — _ — sistemleri.) Bu tür yazılımlar, genellikle veri dosyaları üzerinde işlem yaparlar. Kullanı cı girişi, denetim bilgisini sağlamaya ve veri dosyası iş lemlerini tetkiklemeye yöneliktir.

ii) Kimi yazılımlar ise en iyi şekilde giriş/çıkış çiftleriyle tanımlanabilir. Bu tür yazılımlarda asıl işlem o andaki gi riş verisi üzerinden yapılır.

iii) Kimi yazılımlar ise bir giriş karşısında yapılacak olan işleme o andaki girişle birlikte geçmiş giriş/çıkış davranı şına göre yanıt verirler. Bu tür yazılımlar sonlu durum makinaları olarak modellenebilirler.

Yazılım davranışının betimlenmesinde giriş/çıkış çiftleri nin kullanılmasını zor hatta olanaksız kılan durumlar sözkonusu olabilir. Pek çok yazılım sonsuz sayıda giriş kabul eder. Giriş/çıkış çiftlerinin hepsinin belirlenmesi, dolayısıyla yazılımın tümüyle tanımlanması bu gibi du rumlarda olanaksızdır.

2) Örnek kullanarak davranışın betimlenmesi. Yazılım davranışının betimlenmesinde istenen bir kaç davranış örneğinin verilmesi bir başka seçenek teşkil eder. Bu du rumda bütün giriş/çıkış davranışı gösterilemeyecektir. Ancak seçilen örnekler, yazılımın tüm davranışının ta nımlanmasında yeterince aydınlatıcı olabilir.

3)

Yazılım isterlerinin tanımlanmasında bir diğer yöntem ise model kuHanımı dır. OzeNHde karmaşık davranışların betimlenmesinde modelleme hassas ve etkin bir yaklaşımdır. Matematik sel modeller, işlevsel modeller ve za manlama modelleri belli başlı model leri oluştururlar:

I) Matematksel modeller

Matematiksel bir model, yazılım davranışını matematiksel ilişkiler türünden tanımlar. Ma tematiksel modeller özellikle havacılık, doğrusal prog ramlama, ekonometri, işaret işleme ve hava durumu analizi alanlarında kullanışlıdırlar.

II) İşlevsel modelleme

İşlevsel bir model giriş ve çıkış çiftleri arasında eşlen meleri gösterir. Sonlu durum makinaları, Petri ağları gibi işlevsel modeller, yazılımın çeşitli özelliklerini tanımlama da ya da amaçlanan yazılım davranışını sergilemekte yardımcı olurlar.

IH) Zamanlama modelleri

Zamanlama modelleri zaman kısıtları ile genişletilmiş modellerdir. Özellikle gerçek zamanlı sistemlerin davra nışını betimlemekte zamanlama modelleri son derece yararlıdırlar.

iv) Diğer modeller

Yukarıdaki genel modellerin dışında, özel uygulamalar kendilerine uygun modellere sahip olabilirler. Özellikle belirli bir Formel İster Tanım Dilinin (Formal Require ments Specrfication Language) kullanımı beraberinde belirli bir modelin kullanımını gerektirebilir.

Model kullanımında dikkat edilecek noktalar:

Hangi model kullanılırsa kullanılsın ilgili Yazılım Özellik leri ve İşlevleri Tanım belgesinde kullanılan model tam olarak tanımlanmalıdır. Modelle ilgili olarak

1) Model parametrelerinin sınırları

2) Sonuçların istenen hassaslığı

3) İş yükleme kapasitesi

4) İstenen işlem süresi

5) Normal yanıtı ile hata yanıtı belirtilmelidir.

3.2.1.2. Çevre ile arabağlar

Yazılımın, donanımla, çevre birimle ri ile, diğer yazılımlarla ve insanlarla arabağlarını tanımlayan isterlerdir.

3.2.1.3. Performans, Kapasite ve Verimlilik İsterleri

Yazılımın,

çütlerini;

1) genel olarak ve işlevlerine ilişkin hız, yanıt süresi, işlem süresi, para metre duyarlılığı v.b. performans öl

2) kullanıcı sayısı, veri saklama ve işleme kapasitesi v.b. kapasite ölçütlerini;

3) bellek, merkezi işlem birimi v.b. kaynakları değerlen dirme ölçütlerini tanımlayan isterlerdir.

3.2.1.4. Kalite İsterleri

Kullanıcının yazılımdan beklediği kalite ihtiyaçlarının kar şılanması için yazılıma ve sipariş yoluyla yazılım edini minde yazılım geliştirme süreçlerine ilişkin isterlerdir.

Yazılım Kalite İsterleri, yazılım ihtiyacı olan kuruluşun yazılımdan beklediği kalite özelliklerinin sağlanması için gerçekleştirilmesi gereken

1) Yazılımın kendisine,

2) Tasarım sürecine

3) Kodlamaya (programların yazılması)

4) Test süreçlerine

5) Yazılım gözetim ve denetim süreçlerine

6) Belgelendirmeye

ilişkin isterler olarak gruplandırılabilir.

Bu isterlere ilişkin bir kaç örnek aşağıda verilmektedir:

1) Yazıhmın kendisine ilişkin kalite isterlerine örnekler:

örnek (1) : "Kullanıcıya veri girişlerinde öntanımlı (default) değer sunulmalıdır." (İlgili kalite unsuru: Kulla nışlılık)

örnek (2) : "Bellek kullanımı dinamik olmalıdır." (İlgili kalite unsuru: Verimlilik)

örnek (3) : "Ana haberleşme hattında arıza durumun

184 387 E L E K T R İ K MÜHENDİSLİĞİ

da alternatif haberleşme hatları seçilmelidir.* (kg* kalite unsurları: Güvenilirlik, emniyet, hizmette sürektiKk)

2) Tasarım sümek* ilişkin kalite isterleri örnekleri:

örnek (5) : "Performans isterleri uyarlanabilir para metreler olarak gerçeklenmelidir.* (ilgili kalite unsuru: Genişleyebiliri*)

örnek (6) : "Y apısal tasarım teknkleri kullanılmalıdır." (ilgili kalite unsuru: Genişleyebiliri*, esneklik, birlkte ça lışabilirlik, bakım kolaylığı, taşınabilirlik, yeniden kullanı labilirlik, doğrulanabüirlik)

3) Kodlamaya ilişkin kalite isterleri örnekleri:

örnek (7) : "Makina dili ya da birleştirici dili kullan maktan kaçınılmalıdır." (İlgili kalite unsuru: Birlikte çalı şabilirlik, taşınabilirlik, yeniden kullanılabilirlik)

örnek (8) : "Modül kod satır sayısı 100 ile sınırlı ol malıdır." (ilgili kalite unsuru: Genişleyebildik, esneklik, birlikte çalışabilirim, bakım kolaylığı, taşınabilirlik, yeni den kullanılabilirlik, doğrulanabildik)

mın ve aynca sipariş yoluyla yazılım ediniminde Y azılım Geliştirme eylemlerinin uyumlu olması istenen standart lar var ise belirtilmelidir. Bu standartlar, uluslararası ya da ulusal standart organizasyonları tarafından kabul edi len standart ve öneriler, de facto endüstri standartları ya da firmaların kendi standart ya da kılavuzları olabilir. Ör nek olarak

• Veri Gösterimi Standardı (Örneğin ASCII, EBCDIC)

• Tasarım Gösterim Standardı (Örneğin SDL, ANSI/ IEEE Std 1016) [16]

• Program Kodlama standartları (ANSI C FORTRAN 77, SOL)

• Kullanıcı arabağı standartları (örneğin X Windows)

• Haberleşme standartları (örneğin IEEE 802.3)

• Belgeleme standartları (DOD STD 2167, ANSI/IEEE 829) [3,10]

4) Test süreçlerine ilişkin kalite isterieri örnekleri:

örnek (9) : "Bütün modül arabağları test edilmelidir." (İlgili kalite unsuru: Bakım kolaylığı, doğrulanabilirlik)

5) Yazılım gözetim ve denetim süreçlerine ilişkin kalite isterieri örnekleri:

örnek (10) : "Bütün kritik modüllerde kod incelemesi yürütülmelidir." (İlgili kalite unsuru: Güvenilirlik, emniyet, bakım kolaylığı)

örnek (11) : "Y azılım doğrulama ve test faaliyetleri bağımsız bir kuruluş tarafından yürütülmelidir." (İlgili kali te unsuru: Güvenilirlik, emniyet, bakım kolaylığı)

• Kod yazım kuralları (Çeşitli kuruluş ve firmalara ilişkin)

• İşletim sistemi arabağı _ _ _ _ _ _ _ _ „ _ _ standardı (System Cali Inter face) (UNIX SVID Rel. 2) verilebilir.

3.2.1.6. Y erelleştirme İsterleri

Satın alınan yazılımların dış kaynaklı olması ya da geliş tirilecek yazılımın dış kaynaklı yazılımları kullanması du rumunda yazılımın yerelleştirilmesi gündeme gelmekte dir. Y erelleştirme,

1) ekran bilgisinin Türkçe çıkması,

Örnek (12) : "Taslak kullanıcı kılavuzu tasarım evre sinde yayınlanmalıdır." (ilgili kalite unsuru: Birlikte çalışa bilirlik, kullanışlılık)

6) Belgelendirmeye ilişkin kalite isterleri örnekleri:

Örnek (13) : "Kod listeleri belgelendirmeye dahil edil melidir." (İlgili kalite unsuru: Y önetilebiliriik, yeniden kul lanılabilirlik)

örnek (14) : "Y azılım belgelerinde indeks bölümü bu lunmalıdır." (ilgili kalite unsuru: Y önetilebiliriik, yeniden kullanılabilirlik)

3.2.1.5. Uyulması Gereken Standartlar

Y azılım özellikleri ve İşlevleri Tanım Belgesinde, yazılı

2) girişlerin Türkçe yapılması,

3) çıkışların Türkçe sunulması,

4) Türkçe karakter içeren bilginin yazılım tarafından iş lenebilmesi (sıralama, büyük harf/küçük harf çevrimi, v.b.),

5) hata mesajlarının Türkçe olması,

6) yardım mönüsünün Türkçe sunulması,

7) yazılım belgelerinin (Bölüm 6.1'de tanımlanan) Türk çe olması,

8) tarih, saat, para birimi, sayı gösterimi ve diğer ölçü birimlerinin Türkiye'de kabul edilen ve kullanılan notas

387 E L E K T R İ K J Q P MÜHENDİSLİĞİ I öO

yonda girilmesi ve sunulması olanaklarının gerçekleştiril mesini içerir.

Bir yazılımın yukarıda ifade edilen bütün özellikleri sağ layacak biçimde yerelleştirilmesi yoğun emek gerektiren ve maliyet yükseltici bir süreçtir. Müşteri kuruluş, hangi yerelleştirme olanaklarını talep ettiğini Yazılım özellikleri ve İşlevleri Tanım belgesinde belirtmelidir.

Kod Tablosu:

Yerelleştirmede bugüne kadar karşılaşılan önemli sorun lardan biri, Türkçe karakterler için kabul edilmiş bir stan dart Kod Tablosunun bulunmayışıydı. Bu durum, şimdi ye kadar yapılan yerelleştirmelerde firmaların kendilerine özgü Türkçe karekter kod tabloları kullanmalarına ve bundan doğan uyumsuzluklara neden olmuştur. Bugün, uluslararası (ISO) ve ulusal (TSE) standart organizas yonları tarafından onaylanmış Türkçe karakterler için 8 ikilik (bit) kod tablosu mevcuttur (TSE 5881 Bilgisayar ve Veri iletişiminde Kullanılan 8 İkil Uzunluğunda Türkçe karakter Kodlama Kuralları/ISO 8859 Text Communicati on Registration of graphics character subrepertoires 8 bit single byte coded graphic character sets Table 9 (Latin 5) ) [33, 34]. Yerelleştirmelerde, sözleşmede aksi belirtilmediği sürece, TSE 5881'e uyulmalıdır.

Terminoloji

Yazılımın yerelleştirilmesi sürecinde Türkçe terminoloji büyük önem taşımaktadır. Müşteri kuruluş, satıcı/üretici firmadan çeviri sırasında belirli bir Türkçe terim sözlüğü nün kullanılmasını talep edebilir, yazılımla birlikte kulla nılan terim sözlüğünün teslimini isteyebilir ve/veya yazı lımla birlikte teslim edilecek Türkçe Belgelerin her birinin terim sözlüğünü içermesini talep edebilir.

3.2.2. Y azılım özellikleri ve İşlevleri Tanım Belgesi nin Özellikleri

Yazılım isterlerinin tümü, doğal olarak, eşit öneme sahip değildir. Yazılım Özellikleri ve İşlevleri Tanım Belge si'nde yeralan yazılım isterlerinin göreli önemlerinin belir tilmesi gerekmektedir. Her bir yazılım isterinin göreli önemi açık ve kesin olmalıdır [11].

ise kabul kriteri teşkil etmeyecek, ancak gerçeklenmesi halinde yazılımın daha üstün nitelikli olmasını sağlaya cağından tercih nedeni olabilecektir.

Yazılım özellikleri ve İşlevleri Tanım Belgesi, tüm yazı lım isterlerini doğru ve eksiksiz olarak tanımlamalıdır. Ancak YÖİTB tasarım ya da doğrulanma gibi yazılım ge liştirme süreçlerine ya da proje yönetimine ilişkin ayrıntı ları kapsamamalıdır.

Yazılım özellikleri ve İşlevleri Tanım Belgesi, sözkonusu yazılımın nasıl olacağını tanımlar. Olası tasarım kısıtla maları dışında, geliştirilmesine ilişkin konuları ele almaz.

Yazılım Özellikleri ve İşlevleri Tanım Belgesinin özellik leri:

1) YÖİTB açık ve kesin olmalıdır.

YÖİTB'de ifade edilen her isterin tek bir yorumu olmalı dır. Bu ise yazılımın özelliklerini belirten her terimin belir li tek bir anlama sahip olmasıyla mümkündür. Özel bir bağlam içerisinde kullanılan herhangi bir terim, bir kaç anlama sahipse, ilave edilen bir terim sözlüğü ile kullanı lan anlamı netleştirilmelidir.

Gündelik konuşma diliyle (örneğin Türkçe) yazılım ister lerinin ifadesinde doğabilecek olası belirsizliklerin önlen mesinde güvenli bir yöntem olarak Formel İster Tanım Dilleri (Formal Requirements Specifications Languages) kullanılabilir.

2) YÖİTB eksiksiz (complete) olmalıdır.

Eksiksiz bir YÖİTB, i) Bütün yazılım isterlerini içermelidir;

ii) Yazılımın, bütün gerçeklenebilir durumlarda, bütün gerçeklenebilir giriş veri sınıflarına yanıtlarını tanımlama lıdır;

iii) İlgili standartlarına uymalıdır. Özel bir nedenle ilgili standartın bir bölümü uygulanamaz ise, uygulanamayan bölüm ve uygulanamama nedeni belirtilmelidir.

1) Yazılım isterlerinin bir kısmı yazılımın işletim süresi boyunca sabit kalacaktır. Kimi yazılım isteri ise değişikli ğe açık ya da geçici olabilir. Her bir isterin sürekli, ya da geçici olup olmadığı, değişiklik beklentisinin bulunup bu lunmadığının belirtilmesi gerekmektedir.

iv) İçindeki bütün şekil, şema ve tabblar eksiksiz ola rak adlandırılmalı ve numaralandırılmalı ve kullanılan bü tün terimler ile ölçü birimleri tanımlanmalıdır.

"Daha sonra belirlenecek" ifadeleri üzerine:

2) Her bir yazılım isteri "zorunlu" ya da "tercih edilir" ni teleyicilerinden biri kullanılarak tanımlanmalıdır. "Zorun lu" olarak tanımlanan bir ister yazılımın kabulünde belir leyici olacaktır. "Tercih edilir" olarak nitelenen bir ister

İçinde "daha sonra belirlenecektir" ifadesini kullanan bir YÖİTB eksiksiz olamaz. Ancak, bir YÖİTB'de "daha son ra belirlenecektir" ifadesinin kullanılması çeşitli nedenler le gerekli olabilir. Bu durumlarda

186 387 E L E K T R İ K MÜHENDİSLİĞİ

i) Belirsizliğin çözümlenebileceği zaman belirtilmelidir.

ii) Belirsizliğin ortadan kakması için ne yapılması ge rektiği belirtilmelidir.

ve dolayısıyla YÖİTB'nin tutarsızlaşması riskini barındı rır.

6) YÖİTB izlenebilir olmalıdır.

Hazır yazılım paketi alımına gidilen durumlarda YÖİTB "daha sonra belirlenecektir" ifadesi içeremez.

Sipariş yoluyla yazılım ediniminde ise sözleşmeyle ke sinleşen YÖİTB "daha sonra belirlenecektir" ifadesi içe remez.

Sipariş yoluyla yazılım ediniminde sözleşmeye kadar olan evrede kesinleşmemiş YÖİTB'de "daha sonra belir lenecektir" ifadesi yeralıyor ise, buna dayanılarak üreti len her belge sözkonusu YÖİTB'nin versiyon ya da baskı numarasını belirtmelidir.

3) YÖİTB doğrulanabilir olmalıdır.

İçindeki her yazılım isterinin kaynağı açık bir şekilde be lirtilen ve ilerideki yazılım değişiklikleri ya da yeni versi yon geliştirme evresinde isterlere referansı kolaylaştıran bir YÖİTB izlenebilirdir.

7) YÖİTB işletme ve bakım evresinde de kullanılabilir ol malıdır.

YÖİTB, işletme ve bakım evresindeki ihtiyaçlara yanıt verebilmelidir. Geniş çaplı değişiklik gerektiğinde ya da yeni versiyon geliştirme durumunda YÖİTB ve tasarım belgeleri kaynak teşkil edecektir. Bu bakımdan YÖİTB (6)'da belirtildiği biçimde izlenebilir olmalıdır. Ayrıca YÖ İTB'deki her yazılım isterinin

İçindeki her yazılım isteri doğrulanabilir olan bir YÖİTB doğrulanabilirdir. Bir ister, sonuçtaki yazılımın kendisini sağlayıp sağlamadığı maliyet etkin bir şekilde bir makina ya da insan tarafından kontrol edilebiliyor ise doğrulana bilirdir.

4) YÖİTB tutarlı (consistent) olmalıdır

Birbiriyle çelişen yazılım isterleri barındırmayan YÖİTB tutarlıdır. Başlıca tutarsızlık türleri şöyle olabilir:

i) önem derecesi, ii) geçici ihtiyaçlara karşılık gelip gelmediği ve iii) kaynağı belirtilmelidir. 3.2.3. Belgeleme İsterleri

• İki ya da daha fazla yazılım isteri aynı nesneye farklı Yazılım Teknik Şartnamesinde, yazılımla birlikte istenen

adlarla başvurursa;

belgelerin

• İki ya da daha fazla yazılım isteri aynı nesneyi farklı ve çelişen özelliklerle tanımlarsa;

• İki ya da daha fazla yazılım isteri tarafından tanımla nan işlevler arasında bir çatışma varsa sözkonusu YÖİTB tutarsız olur.

5) YÖİTB kolaylıkla değiştirilebilir (modifiable) olmalıdır.

Yapısı ve yazım biçimi, isterlerde gereken değişikliklerin kolayca, eksiksiz ve tutarlı biçimde yapılmasına elveren bir YÖİTB değiştirilebilirdir. Değiştirilebilir bir YÖİTB şu özelliklere sahiptir:

i) Kolay okunabilen ve izlenebilen, bağlantılı bir yapısı olmalıdır. İçindekiler ve indeks bölümleri bulunmalıdır. Bütün bölümler arasındaki çapraz referansları açık olma lıdır.

ii) Aynı yazılım isteri YÖİTB içinde birden fazla yerde bulunmamalıdır. Bir isterin bir kaç yerde dile getirilmesi belgeyi daha okunabilir kılmakla birlikte ilgili isterdeki de ğişiklik durumunda değişikliğin her yere yansıtılmaması

i) türleri ii) kapsam ve nitelikleri iii) varsa belgelendirmede uyulması istenen standartlar iv) belgelerin güncellenmesi prosedürlerine ilişkin ister ler olarak belirtilmelidir.

Yazılım Teknik Şartnamesinde belirtilen belgelendirme isterlerinin haricinde, her tür yazılım tesliminde, yazılı mın türü, karmaşıklığı ve büyüklüğünden bağımsız ola rak üretici/satıcı firmanın sağlaması gereken belgeler ve içerikleri Bölüm 6'da verilmektedir.

3.2.4. İstenen Eğitim Hizmetleri

Yazılım kullanıcılarının, yazılımın işletme ve bakımından sorumlu olacak personelin eğitim gereksinimleri ve bu doğrultuda yazılım üreticisi/satıcısı firmadan istenen eği timin kapsam ve süresi Yazılım Teknik Şartnamesinde belirtilmelidir.

387 E L E K T R İ K 4 o ^ MÜHENDİSLİĞİ l O f f

3.2.5. Bakım v* Destek İsterleri

• Yazılımın hizmete alınması sıra sında beklenen destek hizmetleri

• Müşteri ortamına uyarlamaya iliş kin destek hizmetleri

• Yazılımla birlikte istenen test ge reçleri, performans gözleme gereçle

• Hatalı çalışma durumunda verile cek düzeltmeye yönelik bakım hiz

Sipariş yoluyla yazılım ediniminde, müşteri kuruluş ile üretici firma arasında imzalanan sözleşme Yazılım Geliştirme

Planını kapsamalıdır. **

ve aşamalara ait takvim ve ayrıla cak kaynaklarla birlikte belirten, söz konusu aşamalarda hedeflere ulaşı lıp ulaşılmadığının doğrulanma prosedürlerini tanımlayan, müşteri ile üretici arasındaki her aşamadaki ilişkileri belirleyen ve belgelendirme sistemini tanımlayan plandır [7].

Sipariş yoluyla yazılım ediniminde, müşteri kuruluş ile üretici firma ara sında imzalanan sözleşme Yazılım Geliştirme Planını kapsamalıdır. Ya

metlerinin çerçevesi

• Yeni versiyon geliştirme ya da güncelleme prosedür leri v.b. bakım ve destek hizmetlerine ilişkin isterler Yazılım Teknik Şartnamesinde saptanmalıdır.

3.2.6. Yazılım Kabul ve Kabul Testi

Yazılım Teknik Şartnamesinde, Yazılım Geçici ve Kesin Kabul Prosedürleri belirtilmeli, Yazılım Kabul testleri ve ölçütleri tanımlanmalı ve kabul için yazılımla birlikte veril mesi gereken diğer materyelin (belgeler, kod listeleri, ya zılım destek gereçleri, v.b.) listesi verilmelidir.

Yazılım Kabul Testi, yazılımın kabul ölçütlerini sağlayıp sağlamadığının ve müşterinin yazılımı kabul edip etme yeceğini saptar, yazılımın kullanım ortamında yürütülür ve bağlayıcıdır [7].

Yazılım Teknik Şartnamesinde, yazılım kabul ölçütleri belirtilmeli ve Yazılım Kabul Test isterleri tanımlanmalı dır. Yazılım Kabul Test isterleri,

1) Test nesneleri (yazılım artsistemleri) 2) Test edilecek özellikler 3) Test nesneleri için kabul/ret ölçütleri

4) Test belgeleri

5) Test işlemleri

6) Ortam koşulları olarak belirtilmelidir.

3.2.7. Yazılım Geliştirme Planı ve Yazılım Geliştirme Gözetim ve Denetimine Yönelik İsterler

zilim Geliştirme Planı, yazılım üreticisi firma tarafından hazırlanır, teklifle birlikte sunulur ve müşteri kuruluşun kabulü sonucu sözleşmeyle kesinlik kazanır. Amacı, ya zılım ihtiyacı olan kuruluş için yazılım geliştirme sürecini gözlenebilir ve denetlenebilir kılmaktır. Yazılım Geliştir me Planının kapsam ve ayrıntıları projenin türüne, bü yüklüğüne ve karmaşıklığına göre farklılıklar gösterecek tir. Müşteri kuruluş Yazılım Teknik Şartnamesinde Yazılım Geliştirme Planına yönelik isterlerini belirtmeli dir.

Yazılım Teknik Şartnamesindeki yazılım geliştirme pla nıyla ilgili isterler, müşteri kuruluşun yazılımın geliştiril mesi sırasında talep ettiği denetim ve gözetimin ölçü ve tekniklerini saptar. Bu doğrultuda, sözleşmeyle bağlana cak olan plana kaynak teşkil etme amacını taşır.

Bu bağlamda müşteri kuruluş Yazılım Teknik Şartname sinde:

1) Yazılım Değerlendirme faaliyetlerinin (Bkz. Bölüm 4.1) yürütülmesi, izlenmesi, belgelendirilmesi ve değer lendirilmesine ilişkin isterlerini ifade eder.

2) Yazılım geliştirme süreci aşamalarının ürünleri olan belgeler içerisinde, kendisine teslim edilmesi gereken belgeleri belirtir. (Tasarım belgeleri. Test Belgeleri, Test Raporları, Yazılım Değerlendirme Raporları, Test Planla rı, Kalite Denetim Plan ve Belgeleri, v.b.)

3) Yazılım Geliştirme süreci sonunda yazılımın toptan teslimi yerine, varsa, bağımsız yazılım altsistemlerini te ker teker teslimini talep edebilir ve bu doğrultudaki ister lerini belirtir.

4) Geliştirme sürecinin çeşitli aşamalarında yazılımda gerçekleştirilen işlevselliği gözlemek üzere ara gösteriler (demonstration) talep edebilir ve bunları tanımlar.

Yazılım Geliştirme Planı, yazılımın yaşam döngüsünün her evresinde yürütülecek başlıca işleri, ulaşılacak aşa maları, bu aşamalarda ortaya çıkarılacak ürünleri, bu iş

5) Entegrasyon Testlerinin (Bkz. Bölüm 4.2) yürütülme si, izlenmesi, belgelendirilmesi ve değerlendirilmesine ilişkin isterlerini ifade eder.

188 387 E L E K T R İ K MÜHENDİSLİĞİ

Geçici Kabul öncesi yazılım faaliyetlerinin kısmi ücretlen dirilmesi, Yazılım Geliştirme Planında belirtilen aşamalar temel alınarak belirlenir. Sözleşme, Yazılım Geliştirme Planındaki belirli aşamaların geçilmesi durumunda o aşamalara ilişkin ödenecek proje bedeli oranını gösterir. Bu bedel, ilgili aşamaya ilişkin ürünlerin (alt sistem ve/ veya belgeler) teslimi karşılığında ödenir. Sözleşme, ara ödemenin yapılacağı aşamayı (örneğin, yazılımın bir alt sisteminin teslimi, ya da tasarım değerlendirmesinin olumlu sonuçlanması, entegrasyon testlerine başlanma sı, v.b.), bu aşamaya erişildiğinde teslim edilmesi gere ken ürünleri ve ödenecek bedeli tam ve açık olarak ta nımlamalıdır. Ara ödemelerle ilgili öneriler Bölüm 4.3'de verilmektedir.

Yazılım Geliştirme Planındaki aşamalara ulaşmadaki olası gecikmeler, sözleşme ile tanımlanan cezai yaptırı ma tabi tutulabilir.

Yazılım Teknik Şartnamesi ve Yazılım Özellikleri ve İş levleri Tanım Belgesinin Uzman Firma ya da Kuruluşlar tarafından Hazırlanması

Bu durumda yazılım ihtiyacı olan kuruluş, Kullanıcı Özel likleri Tanım Belgesini hazırlayarak Yazılım Teknik Şart namesinin ve Yazılım Özellikleri ve İşlevleri Tanım Bel gesinin yazılmasını ayrı bir proje olarak bir ya da bir kaç firma ya da kuruluştan talep eder.

Yazılım ihtiyacı olan kuruluş, bu firma ya da kuruluşlar tarafından hazırlanan Yazılım Teknik Şartnamelerinden birini kabul edebilir, ya da bunları kullanarak kendisi yeni bir şartname hazırlayabilir. Her durumda, Yazılım Teknik Şartnamesini hazırlayan firma ya da kuruluşların her biri ücretlendirilir

Müşteri kuruluş, Yazılım Geliştirme Planının izlenmesini ya da yazılım geliştirme süreci içerisinde belirli denetim faaliyetlerinin (doğrulama ya da testler) yürütülmesini üretici firmanın dışında ayrı bir firma ya da kuruluştan ta lep edebilir. Yazılım Teknik Şartnamesinde, varsa bu ta lep ifade edilmelidir Bu durumda, yazılım geliştirme sü recini denetleyecek ve/veya bağımsız bir kuruluş olarak testleri ya da doğrulama faaliyetlerini yürütecek olan fir ma ya da kuruluşla ilişkiler ayrı bir sözleşme konusudur.

3.3. Y azılım Teknik Şartnamesinin ve Y azılım Özellik leri ve İşlevleri Tanım Belgesinin Hazırlanması

Yazılım Teknik Şartnamesi ve Yazılım Özellikleri ve İş levleri Tanım Belgesi, ihtiyaç duyulan yazılımın karma şıklık derecesine ve büyüklüğüne bağlı olarak iki şekilde hazırlanabilir.

1) İhtiyaç duyulan yazılımın görece basit ve küçük ölçek te olduğu ve yazılım ihtiyacı olan kuruluşun bünyesinde sözkonusu yazılımı teknik olarak tanımlamaya yetecek birikimin mevcut bulunduğu durumlarda adı geçen bel geler yazılım ihtiyacı olan kuruluş tarafından hazırlanır.

2) Yazılımın karmaşıklık derecesi ve büyüklüğünün, ya zılım isterlerinin tanımlanmasında ve teknik olarak ifade sinde özel uzmanlığı gerekli kıldığı durumlar olabilir. Sağlıklı bir Yazılım Teknik Şartnamesinin ve Yazılım Özellikleri ve İşlevleri Tanım Belgesinin yazılması, bu gi bi durumlarda yazılım ihtiyacı olan kuruluşun ya da satı cı/üretici firmanın sahip olduğu uzmanlığın dışında olabi lir. Böyle durumlarda yazılım ihtiyacı olan kuruluş. Yazılım Teknik Şartnamesinin ve Yazılım Özellikleri ve İşlevleri Belgesinin hazırlanması işini bu konuda uzman firma ya da kuruluşlara devreder.

387 E L E K T R İ K 4 A f l MÜHENDİSLİĞİ | Ö Î 7

4. Y AZİLİM GELİŞTİRME GÖZETİM VE DENETİMİ

4.1 . Yazılım Değerlendirme Faaliyetleri

Sipariş yoluyla yazılım ediniminde, yazılım üreticisi fir ma, geliştirme sürecinin çeşitli aşamalarında ortaya çı kan ürün ve belgelerin istenen özellikleri sağlayıp sağla madığının tespiti amacıyla Yazılım Geliştirme Planı ve Yazılım Kalite Planı uyarınca Yazılım Değerlendirme fa aliyetleri yürütür. Bu faaliyetleri müşteri kuruluşun izle mesi ve/veya müşteri kuruluş temsilcilerinin katılımı, Ya zılım Teknik Şartnamesindeki isterler doğrultusunda saptanır ve Yazılım Geliştirme Planı'nda ve Yazılım Kali te Plam'nda yeralır.

Yazılım Değerlendirme, yazılım ürünlerinin ya da yazılım geliştirme projesinin eriştiği durumun, hedeflere ulaşıp ulaşmadığının incelenmesi, değerlendirilmesi ve düzelti ci ve/veya geliştirici önerilerin oluşturulması faaliyetidir. Yazılım Değerlendirme faaliyetinin,

1) Yönetim Değerlendirmesi (Management revievv),

2) Teknik Değerlendirme (Technical revievv)

3) Yazılım inceleme (Software inspectbn),

4) Yazılım Tarama (VValkthrough)

olarak dört genel türü tanımlanabilir [17].

Yönetim Değerlendirmesi, yazılım geliştirme faaliyetleri nin Yazılım Geliştirme Planına göre ilerlemesinin sağlan ması ve kaynakların bu hedefler doğrultusunda uygun olarak kullanılması amacıyla yürütülür. Proje yönetim belgeleri ve raporları, tamamlanmış diğer değerlendirme faaliyetlerinin raporları ve tamamlanmış test raporları Yönetim Değerlendirmesi faaliyetinin kaynaklarını oluş turur.

Teknik Değerlendirme, Yazılım İnceleme ve Yazılım Ta rama faaliyetleri ise, yazılım ürünlerinin isterleri sağlayıp sağlamadığının ve standartları ve kılavuzlara uyumlulu ğunun incelenmesi, denetlenmesi, hataların araştırılma sı, gözlenen problemlerin belgelendirilmesi amacını ta şır. Tasarıma ya da kodlamaya alternatif üretilmesi bu faaliyetlerin kapsamının tamamen dışındadır. Tasarım belgeleri, test belgeleri, test planları, kaynak kodlar ve test raporları başlıca kaynak materyeli oluşturur.

Teknik Değerlendirme, sonucun değerlendirilmesine yö neliktir, dolayısıyla bir aşama sonrası faaliyetidir (Örne ğin, tasarım sonrası Tasarım Değerlendirme). Teknik Değerlendirme ekibinde müşteri temsilcisi ya da bağım sız bir denetleyici bulunabilir.

Yazılım Tarama, ilgili ürünün tasarım, kodlama ve test

süreçlerinden sorumlu personelin kendi arasında yürütü len ve süreç içi bir faaliyettir. Hata ve uyumsuzlukların bulunmasına, çözüm ve alternatifin üretilmesine ve geliş tirme ekibinin iç eğitimine yöneliktir.

Yazılım Inceleme'de ise, inceleme ekibini yazılım ürünün geliştirilmesinde yeralmayan farklı bir teknik grup oluştu rur. Bu çalışmanın amaçları da hata ve uyumsuzlukların bulunmasıdır, ancak tasarım ya da kodlamaya alternatif geliştirilmesi Yazılım inceleme grubunun amaçlarının ve sorumluluklarının tamamen dışındadır.

Yazılım Değerlendirme faaliyetleri, tasarımın, kodlama nın, test sonuçlarının değerlendirilmesi için ve ürünün sonlandırılması ve değerlendirilmesi amacıyla, geliştirme süreci içinde farklı aşamalarda düzenlenebilir.

Üretici firma, Yazılım Geliştirme Planı'nda, geliştirme sü reci içerisinde yürütülecek Yazılım Değerlendirme faali yetlerini tanımlar ve planlar. Planlanan her değerlendir me faaliyeti için, aşağıdaki bilgilerin saptanması ve geliştirme planında belgelendirilmesi gerekir:

1) Amaç,

2) Değerlendirme çalışmalarının başlama zamanı, plan lanan süresi, düzenlenecek toplantıların zamanı ya da göreli planı,

3) Değerlendirme ekibinin tanımı ve sorumlulukları,

4) İncelenecek ya da teftiş edilecek materyalin listesi,

5) Yöntem,

6) Değerlendirme raporunun kapsamı, dağıtımı ve kulla nımı,

7) Faaliyetin sonlandırılma ölçütü.

4.2 Entegrasyon Testleri

Entergrasyon testi, yazılım modüllerinin, modül testleri yapıldıktan sonra, diğer modüller ve donanım ile belirli bir plan dahilinde, teker teker entegre edilerek test edil mesi sürecine denir [7]. Yazılımın kodlanması, test pla nındaki entegrasyon hedeflerine uygun sırada gerçek leştirilir.

Sistem testi, yazılım ve donanımın, entegrasyon sonra sı, bir bütün olarak test edilmesi sürecidir [7]. Donanımın hazır olduğu ve yazılımla birlikte geliştirilmediği durum larda bu test, tüm yazılım özelliklerinin ve donanımla bir likte işleyişinin testi anlamını taşır ve bu bağlamda Yazı lım Teknik Şartnemesi ve Yazılım Test Planının konularından birini oluşturur. Donanım ve yazılımın bir likte geliştirilmesi ve bu durumdaki sistem testleri ise bu raporun kapsamının dışındadır.

Test Planı, taslak halinde tasarım öncesinde oluşturul malıdır [24]. Planın ayrıntılandırılması ve attsistemler ile ilgili altplanlar süreç içerisinde oluşturulur ve plan gün cellenir. Bu plan, müşteri kuruluş Yazılım Teknik Şartna mesinde talep ettiği takdirde, Yazılım Geliştirme Planı ile birlikte müşteri kuruluşun ya da müşteri kuruluşun seçtiği denetleyici firma ya da kuruluşun incelemesine sunulur.

4.3. Y azılım Geliştirme Sürecinde Ocretlendirme Da ğılımı

Yazılım siparişinde kısmi ücretlendirme, Bölüm 3.2.7"de belirtildiği üzere sözleşme tarafından belirlenen aşama lar esas alınarak yapılır. Ancak, sözleşmede belirlene cek bu kısmi ödemeler için, aşağıda belirtilen ödeme planı, genel bir örnek olarak, sunulabilir:

1) Sözleşmenin bağlanmasıyla birlikte toplam proje be delinin %10 15'i oranında ilk ödeme (avans) yapılır.

2) Kodlamaya geçilmeden önce, toplam proje bedelinin %25 40'ı oranında ödeme gerçekleştirilir.

3) Entegrasyon testlerine geçilmeden önce toplam proje bedelinin %50 60'ı oranında ödeme gerçekleştirilir.

4) Yazılım alt sistemlerinin peyder pey tesliminde yapı lan ödemelerde, yukarıdaki (Madde 1 3) ilkeler gözönü ne alınır.

5) Geçici Kabul ile birlikte toplam proje bedelinin %90 95'i ödenir.

6) Kesin Kabul sonucunda bütün proje bedeli ödenir.

4.4. Yazılım Geliştirme Sürecinde Değişiklik İstekleri

5. Y AZIUM TESTLERİ VE Y AZHJM KABUL PROSEDÜRLERİ

Yazılım, sözleşme ile kesinlik kazanmış Yazılım Teknik Şartnamesinde tanımlanan Kabul Testleriyle Geçici Ka bul alır. Geçici Kabul alan yazılım için, sözleşmede belir lenen oranda Ücretlendirme yapılır. Bu oran için toplam proje bedelinin %95 100'ü önerilmektedir.

Geçici Kabul alan yazılım kullanıma alınarak, sözleşme ile belirlenen süre içerisinde olağan çalışma koşullarında kullanılır. Olağan çalışma koşullarındaki bu kullanımın sonucu tatminkar ise yazılım kesin kabul kazanır. Yazılı mın Kesin kabul kazanmasıyla bedelinin geri kalanı da ödenir. Bu dönem içerisinde yazılım hataları ve/veya Teknik Şartnamede belirtilen yazılım isterlerinin birinin ya da birkaçının karşılanamamış olduğu gözlemlenebilir. Bu durumun kotarılması için,

1) Yazılım ihtiyacı olan kurulu şun durumu üretici firmaya ne kadar süre içerisinde ve ne şekilde bildireceği,

2) Üretici firmanın sorunu ne kadar süre içerisinde çözüm lemesinin beklendiği; sözleş meyle saptanır.

Kesin kabul öncesi bu tür bakım hizmetleri ücretsiz ol malıdır.

Sipariş yoluyla yazılım ediniminde, sözleşmeyle kesinlik kazanan Yazılım Teknik Şartnamesi bağlayıcıdır. Yazı lım Teknik Şartnamesinde ifade edilen yazılım isterlerin den herhangi birinde, ya da birkaçında değişiklik, bir özellikten tamamen vazgeçme ya da yeni bir özellik iste me şeklindeki her tür talep, hangi taraftan gelirse gelsin yeni bir pazarlığa yolaçabilir. Müşteri kuruluş ve üretici firma arasında bu tür isteklerin değerlendirilmesi sonu cunda, talebin Yazılım Geliştirme Planı ya da yazılım maliyeti üzerinde herhangi önemli bir değişiklik getirme diği üzerinde mutabakat sağlanırsa Yazılım Teknik Şart namesine, sözleşmenin diğer koşulları sabit kalmak kay dıyla gereken değişiklikler yapılabilir. İstenen değişiklik, program ve maliyete etki ediyor ise, sözleşmenin feshine ve yeni bir Yazılım Teknik Şartnamesi ile sözleşmeye gi dilebilir.

Yazılım değişiklik önerisinin taraflarca onaylanması du rumunda, bütün ilgili ürün ve belgelerde gereken gün celleştirmenin yapılması gerekmektedir.

387 E L E K T R İ K J A J MÜHENDİSLİĞİ İ 9 İ

6. Y AZIUM BELGELENDİRME

6.1. Y azılımla Birlikte Teslimi Zorunlu Belgeler

Yazılımın tür, büyüklük ve karmaşıklığından ve yazılım edinme yolundan bağımsız olarak, müşteri kuruluşa ya zılımla birlikte, Kullanıcı kılavuzu (ve/veya Kullanıcı Baş vuru kılavuzu) ve İşletme kılavuzunun teslimi gerekmek tedir. Kullanıcının aynı zamanda yazılımın işleticisi olduğu, ayrı bir işleticiye ihtiyaç duyulmayan kimi yazı lımlarda, bu iki belge tek bir belgede toplanabilir.

ii) Yazılımın çalıştırılması için gerekli komut ve prosedür ler; durdurulması için gerekli komut ve prosedürler; her hangi bir nedenle yazılım durduğunda yeniden başlatıl ması için gereken komut ve prosedürler.

iii) Hata mesajları, bunların format ve anlamları, hata durumunda yapılması gereken işlemler, hata tanıma iş lemleri (diagnostics).

iv) Yazılımın performansını gözlemlemek için gerekli ko mut ve prosedürler.

Yazılım ihtiyacı olan kuruluş, bu belgenin dışında belge ler talep edebilir ve/veya belgelerin içerikleri ve biçimleri üzerinde isteklerde bulunabilir. Yazılım bekjelendirilme sine ilişkin bütün bu isterler Yazılım Teknik Şartnamesin de yer almalıdır.

Kullanıcı Belgelerin hazırlanmasında, Kaynak [20] refe rans alınabilir.

6.1.1. Kullanıcı Kılavuzu ve Kullanıcı Başvuru Kılavu zu

Kullanıcı kılavuzu şu bilgileri kapsamalıdır:

i) Yazılımın temel işlevleri ve özellikleri tanıtılmalıdır.

ii) Yazılımın giriş komutları ve formatları, giriş ortamı, gi riş prosedürleri, yazılımın işlemesi için zorunlu giriş de ğerleri ile seçeneğe bağlı özellikler için gerekli giriş de ğerleri verilmelidir. Kullanım için gerekli bu bilgiler, birkaç yaygın kullanım örnek alınarak, yazılım temel işlevlerinin yerine getirilebilmesi için ardarda yapılması gereken iş lemler dizisi olarak sunulmalıdır.

iii) Ekran ya da baskı formatları verilmelidir.

iv) Kullanıcıyı ilgilendiren hata mesajları, format ve içe rikleri ve bu mesajlar alındığında yerine getirilmesi gere ken işlemler belirtilmelidir.

Kullanıcı Başvuru kılavuzu, yazılımın bütün giriş komut larını, format ve açıklamaları ile birlikte sıralı olarak su nan başvuru belgesidir. Her tür yazılım için Kullanıcı Kı lavuzu ile Kullanıcı Başvuru kılavuzunun ayrı iki belge olarak teslimi gerekmeyebilir. Bu gibi durumlarda, içeriği her ikisini de kapsayan tek bir Kullanıcı Kılavuzu yeterli olabilir.

6.1.2. İşletme Kılavuzu

İşletme Kılavuzu aşağıdaki bilgileri içerir:

i) Yazılımın hizmete alınması, ortama uyumun gerçek leştirilmesi ve konfigürasyon için gereken bilgi ve prose dürler.

6.2. Bakım Kılavuzu

Bakım kılavuzu genel olarak aşağıdaki bilgileri içerir:

i) Yazılımın tanımı, teknik özellikleri ve işlevler;

ii) Ayrıntılı Tasarım; (Bütün tasarım adımları verilmelidir. "Optimality" gibi tasarımda hemen göze çarpmayacak özellikler açıkça belirtilmelidir.)

iii) Okunabilir ve anlamlı açıklamalar bulunduran kaynak kod;

iv ) Test planları, modül testlerinin ve genel testlerin so nuçları.

Bakım kılavuzunun müşteri kuruluşa hangi durumlarda verileceği ve kapsamının saptanması konusu Bölüm 7'de ele alınmaktadır.

7. BAKIM, EĞİTİM VE DESTEK HİZMETLERİ

7.1. Bakım Hizmetleri

Yazılımın yaşam süresi boyunca;

1) Yazılım hatalarını ve performans yetersizliklerini sap tamak ve düzeltmek,

2) Yazılımı, veri yapılarında ve/veya çalışma ortamında ortaya çıkan değişikliklere uyarlamak,

3) Yazılımın performansını, maliyet etkinliğini, işlem ve rimliliğini vb. özelliklerini iyileştirmek, amacıyla yazılımda düzeltici (corrective), uyarlayıcı (adaptive) ya da iyileştirici (perfective) değişiklikler yap ma gerekliliği ortaya çıkacaktır. Yazılımın müşteriye tes liminden sonra gerekli olan bütün bu değişiklikler yazılı mın bakım sürecini oluşturur [31].

Bakım hizmetleri içerisinde, yukarıda Madde 1'de tanım lanan hata düzeltmeye yönelik bakım Düzeltici Bakım olarak nitelendirilir. Hatasız yazılım, bir hedef olmakla birlikte gerçekçi olmaktan uzaktır. Yazılım hataları, yazı lımın müşteriye teslimini izleyen ilk dönemde ağırlıkla or

• 4 n O 387 E L E K T R İ K i y ^ MÜHENDİSLİĞİ

taya çıkarlar. Hatalı tasarım, hatalı kodlama ya da yazı lım isterlerinin yanlış yorumlanmasından kaynaklanan bu tür yazılım hatalarını onarmaya yönelik düzeltici ba kım, bakım hizmetleri içindeki ağırlığın bir süre sonra yi tirir. Ancak, yazılımın yaşam süresi içinde yazılımı deği şen koşullara uyarlamak ya da yeni özellikler eklemek ve/veya özelliklerini geliştirmek amacıyla değişiklikler ge rekli olacaktır. Bu tür yazılım değişikliklerini karşılamaya yönelik, sırasıyla madde 2 ve 3'de tanımlanan Uyarlayıcı Bakım ve İyileştirici Bakım hizmetleri sonunda yazılımda yeni hatalar üretilmesi kaçınılmazdır. Böylece, yazılımın artık ihtiyaçları karşılamamaya başladığı dönemde dü zeltici bakımın ağırlığı yeniden artmaya başlayacaktır. Yazılımın yaşam süresi boyunca ortaya çıkacak bakım hizmetlerinin yoğunluğundaki değişim için Şekil 4'deki eğri genel ve yaygın bir gösterimdir.

Bakım Garantisi:

Hata onarımına ilişkin düzeltici bakım yükümlülükleri asıl olarak sözleşmeyle saptanır. Ancak satıcı/üretici firma, yazılımın tesliminden sonra belirli bir süre için, örneğin, sipariş yoluyla yazılım ediniminde. Kesin Kabulü takiben ilk bir yıl içerisinde, ücretsiz bakım garantisi vermelidir.

Bakım Anlaşmaları:

Bakım garanti süresi sonrasındaki düzeltici bakım yü kümlülükleri Bakım Anlaşmaları çerçevesinde yerine ge tirilecektir. Sözleşme, sözleşme sonrası düzeltici bakım ihtiyaçlarının karşılanma yöntemlerini ve tarafların so rumluluklarını belirleyerek ilerdeki bakım anlaşmalarının çerçevesini çizmelidir.

Uyarlama ve/veya iyileştirmeye yönelik bakım hizmetleri asıl olarak ayrı sözleşme konularını oluşturur. Ancak, ye ni versiyon geliştirme ya da güncellemeye yönelik yü kümlülükler ve Yazılım Teknik Şartnamesinde belirtilen (Bölüm 3.2.5) diğer bakım isterlerinin karşılanma yön temleri sözleşmeyle bağlanır.

Bakım Kılavuzu:

Bakım Kılavuzu, Bölüm 6.2'de belirtildiği gibi, yazılım de ğişikliklerinin kotarılmasına yönelik kapsamlı bir yazılım belgeleri grubudur. Bakım Kılavuzunun müşteri kuruluşa teslimi, bakıma yönelik değişiklikleri yürütebilecek bir ya zılım ekibinin müşteri kuruluş bünyesinde olması duru munda ya da bakım hizmetleri yazılım üreticisi firmanın dışında bir başka firma tarafından kotanlacak ise anlam kazanır. Her iki durumda da yazılımın mülkiyeti konusu gündeme gelir. Dolayısıyla Bakım Kılavuzunun müşteri kuruluşa teslimi, yukarıdaki ihtiyaçların varlığı durumun da taraflar arasında çözülmesi gereken bir mülkiyet an laşmasıyla bağlanabilir.

7.2. Eğitim Hizmetleri

Müşteri

kuruluş,

eğitim

konu

sundaki ihtiyaçlarını ve isterle

rini Yazılım Teknik Şartname

sinde ifade eder. Taraflar

arasında bağlanan sözleşme,

satıcı ya da üretici firmanın

vereceği eğitim hizmetlerini

belirler. Bu hizmetler, kullanı

cıya ya da işletme personeli

ne yönelik olabilir, basit ve kü

çük yazılımlar için kısa süreli

eğitim programı olabileceği gi ——————————^—

bi, daha karmaşık yazılımlar için yaygın ve yoğun eğitim

programlarına ihtiyaç duyulabilir. Yazılım Teknik Şartna

mesi, varsa Yardım mönüsü (Help Menu) talebini ve bu

mönünün özelliklerini belirtir. Ayrı bir eğitici yazılım ve/

veya Eğitim Belgesi ihtiyacı yine Yazılım Teknik Şartna

mesinde ifade edilir.

7.3. Destek Hizmetleri

Yazılımın kullanım süreci boyunca yazılımda değişiklik gerektirmeyen, ancak kullanıcı ya da işletici personelin yazılımın olanaklarını daha iyi değerlendirebilmeleri, ha ta belirleme ya da performans ölçme türünden işleyişi anlamaya yönelik faaliyetleri yürütebilmeleri, v.b. işler için üretici ya da satıcı firmadan bekledikleri destek hiz metleri olacaktır. Bu tür yazlım destek isterleri Yazılım Teknik Şartnamesinde ifade edilir ve sözleşme ile yü kümlülükler saptanır.

Doğum

Y azılım Y aşam Döngüsü

Ölüm

Ş«kil 4 YAZILIM yaşam Döngüsü Boyunca Bakım İhtiyaçların daki Değişmeler

N

1. DOD STD 480, Configuration Control Engineering Chan ges, Deviations and Waivers.

2. DOD STD 1467, Softvvare Support Environment,

3. DOD STD 2167. Defense System Softvvare Development.

4. DOD STD 2167A, Softvvare Requkements Specifications.

5. DOO STD 2168, Software Ouality Evaluabon.

6. DOO STD 7935, Automated Data Systems Documentation.

7. ANSI/IEEE Ski 729 1983, IEEE Standard Glossary of Soft vvare Engineering Terminology.

8. ANSI/IEEE Std 730.1 1989, IEEE Softvvare Ouality Assu rance Plans.

9. ANSI/IEEE Std 828 1983, IEEE Standard for Softvvare Configurabon Management Plans.

10. ANSI/IEEE Std 829 1983. IEEE Standart for Softvvare Test Documentation.

11. ANSI/IEEE Std 830 1984, IEEE Gukte to Softvvare Requi rements Specifications.

12. ANSI/IEEE Std 983 1986, IEEE Guide for Softvvare Oua lity Assuranos Planning.

13. ANSİ/IEEE Std 1002 1987, IEEE Standard Taxonomy of Softvvare Engineering Standards.

14. ANSI/IEEE Std 1008 1987. IEEE Standart for Softvvare Unit Testing.

15. ANSI/IEEE Std 1012 1986, IEEE Standart for Softvvare Verification and Vaüdation Plans.

16. ANSI/IEEE Std 1016 1987. IEEE Recommended Practice for Softvvare Design Descriptions.

17. ANSI/IEEE Std 1028 1988, IEEE Standard for Softvvare Revievvs and Audits.

18. ANSI/IEEE Std 1042 1987, IEEE Guide to Softvvare Con figuration Management.

19. ANSI/IEEE Std 1058 1987. IEEE Standard for Softvvare Project Management Plans.

20. ANSI/1EEE Std 1063 1988, IEEE Standard for Softvvare User Documentation.

2 1 . IEEE Std 982.1 1988, IEEE Standard Dictionary of Mea sures to Produce Reliable Softvvare.

22. IEEE Std 982.2 1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Softvvare.

23. TR TSY 000179. Bellcore Technical Reference, Softvvare Ouality Program Generic Requirements.

24. Deutsch, M S. , WiHis, R.R. Softvvare Ouality Engineering: A Total Technical and Management Approach, Prenbce Hail 1988.

25. Ledgard, H., Tauner, J., Softvvare Engineering Concepts, Addison VVesley, 1987.

26 Fox, J.M.. Sotvvare and its Developments, Prentice Hall. 1982.

27. Matsumoto, Y ., Ohno, Y .. Japanese Perspectives in Soft vvare Engineering, Adtfson Wesley, 1987.

28. DeMarco, T., Sfcuctured Analysis and System Specificati on, Y ourdon Press, 1979.

29. Macro, A , Buxton, J., Th* Craft of Softvvare Engineering, Addison VVesley, 1967.

30. Booch. G., Softare Engineming wüh Ada, The Benjamin/ Cummings Pub. Com., 1983.

3 1 . Martin, J.. McCkıre, C, Sofftvare Maintenance, Prentice HaN, 1983.

32. C. Summers, Softvvare Ouality AMurance, Reliability and Testing, UNICOM Technical Press, 1987.

33. TSE 5 8 8 1 . Bilgisayar ve Veri İletişiminde Kullanılan 8 İkil Uzunluğunda Türkçe Karekter Kodtama Kuradan.

34. ISO 8859 Text Communication Registration of graphics character subrepertoires 8 bit single byte ooded graphic charac ter sets.

EDA BATKAL M.FATİH DİNÇER

Odamız 13745 Sicil Nolu Üyesi

Eda BAY KAL'ı kaybettik.

Elektrik Mühendisi MLFatih DİNÇER i kaybettik!

AİLESİNE, Y AKINLARINA YE ODAMIZ

TOPLULUĞUNA BAŞSAĞLIĞI DİLERİZ.

AİLESİNE, Y AKINLARINA VE ODAMIZ TOPLULUĞUNA.

BAŞSAĞLIĞI DİLERİZ.

194 387 E L E K T R İ K MÜHENDİSLİĞİ