Değişiklikler

Kullanım safhasındaki diğer bir konu ise yazılım mühendislerine spesifik bir hata hakkında bilgi vermek ve yazılım hatalarından kaynaklı gereksiz bakım görevlerini önlemektir. BIT ile tespit edilebilen veya kullanıcı tarafından tanımlanabilen bir yazılım hatası demontaj sayısını ve donanımla ilişkili olmayacak hataları azaltacaktır (ekipmanın değiştirilmesi ile yazılım hatasının ortadan kaldırılamaması gibi).

Kullanım safhasındaki diğer bir konu ise yazılım mühendislerine spesifik bir hata hakkında bilgi vermek ve yazılım hatalarından kaynaklı gereksiz bakım görevlerini önlemektir. BIT ile tespit edilebilen veya kullanıcı tarafından tanımlanabilen bir yazılım hatası demontaj sayısını ve donanımla ilişkili olmayacak hataları azaltacaktır (ekipmanın değiştirilmesi ile yazılım hatasının ortadan kaldırılamaması gibi).

== 4.4.   YAZILIM İÇİN PLANLI BAKIM ANALİZİ (PBA) ==

== 4.4. YAZILIM İÇİN PLANLI BAKIM ANALİZİ (PBA) ==

GMB gibi PBA’lar donanımlar gibi yazılımlara uygulanabilir değildir. Yazılım hataları, yazılım tasarımının istenmeyen etkilerinin sonucu olduğundan PBA kapsamında tanımlanmış bir bakım görevi ile düzeltilemezler. PBA sonuçları yazılım içeren bir donanımda, planlı bakım görevlerini belirleyecek şekilde kullanılabilir ancak bu analiz yine de donanım için olacaktır.

GMB gibi PBA’lar donanımlar gibi yazılımlara uygulanabilir değildir. Yazılım hataları, yazılım tasarımının istenmeyen etkilerinin sonucu olduğundan PBA kapsamında tanımlanmış bir bakım görevi ile düzeltilemezler. PBA sonuçları yazılım içeren bir donanımda, planlı bakım görevlerini belirleyecek şekilde kullanılabilir ancak bu analiz yine de donanım için olacaktır.

Yazılımlar da küvet eğrisi davranışını izleyerek ilk kullanımda çokça hata yaparlar. Geliştirme safhası boyunca kararlı bir davranışa kadar kod hataları düzeltilerek tekrarlayan bir şekilde yazılım yayımlamaları yapılır. İlerleyen kullanımlarda hata oranları her ne kadar düşse de yazılımda ilk kapsamından farklı olarak modifikasyonlar olacağından hata oranları yine artacaktır.

Yazılımlar da küvet eğrisi davranışını izleyerek ilk kullanımda çokça hata yaparlar. Geliştirme safhası boyunca kararlı bir davranışa kadar kod hataları düzeltilerek tekrarlayan bir şekilde yazılım yayımlamaları yapılır. İlerleyen kullanımlarda hata oranları her ne kadar düşse de yazılımda ilk kapsamından farklı olarak modifikasyonlar olacağından hata oranları yine artacaktır.

== 4.5.   YAZILIM İÇİN OSA ==

== 4.5. YAZILIM İÇİN OSA ==

Yazılım için OSA donanımlarda olduğu gibi ya da oldukça benzer olacak şekilde ele alınmalıdır. OSA sonucunda ortaya çıkan görevler yeni yazılım yayını veya operasyonel bir yazılım ihtiyacının doğması veya veri yükleme gibi dışsal nedenlerden kaynaklanabilir. Eğer bu görevler çok sık gerçekleşirse OSA sonuçları donanımlara karşılık gelen görevlerden farklı olabilir.

Yazılım için OSA donanımlarda olduğu gibi ya da oldukça benzer olacak şekilde ele alınmalıdır. OSA sonucunda ortaya çıkan görevler yeni yazılım yayını veya operasyonel bir yazılım ihtiyacının doğması veya veri yükleme gibi dışsal nedenlerden kaynaklanabilir. Eğer bu görevler çok sık gerçekleşirse OSA sonuçları donanımlara karşılık gelen görevlerden farklı olabilir.

Yazılım değişikliği için ekipman hakkında detaylı bilgi (donanımla ilintili yazılım geliştirme ortamı ve yazılım geliştirme araçları) ve personel yetkinliği gereklidir.  Ayrıca, sözleşmeye bağlı durumlar, yazılım modifikasyon faaliyetlerinin hangi destek seviyesinde gerçekleştirileceğini etkileyebilir.

Yazılım değişikliği için ekipman hakkında detaylı bilgi (donanımla ilintili yazılım geliştirme ortamı ve yazılım geliştirme araçları) ve personel yetkinliği gereklidir.  Ayrıca, sözleşmeye bağlı durumlar, yazılım modifikasyon faaliyetlerinin hangi destek seviyesinde gerçekleştirileceğini etkileyebilir.

== 4.6.   YAZILIM İÇİN BGA ==

== 4.6. YAZILIM İÇİN BGA ==

İlgili yazılım destek başlatıcılarının (olaylar) belirlenmesinden sonra operasyonel/bakım veya modifikasyon görevleri belirlenmelidir. Amaç bunları tanımlamak ve bunlara gerekli kaynakları ve görev karakteristiklerini belirlemektir (süre, insan ihtiyacı, ön koşullar, güvenlik koşulları vb.).

İlgili yazılım destek başlatıcılarının (olaylar) belirlenmesinden sonra operasyonel/bakım veya modifikasyon görevleri belirlenmelidir. Amaç bunları tanımlamak ve bunlara gerekli kaynakları ve görev karakteristiklerini belirlemektir (süre, insan ihtiyacı, ön koşullar, güvenlik koşulları vb.).

SAE JA1005 referans alınarak farklı olaylar sonucunda hangi yazılım destek görevlerinin gerçekleştirileceğine ulaşılabilir.

SAE JA1005 referans alınarak farklı olaylar sonucunda hangi yazılım destek görevlerinin gerçekleştirileceğine ulaşılabilir.

== 5.        YAZILIM DESTEK KONSEPTİ ÇERÇEVESİ ==

== 5. YAZILIM DESTEK KONSEPTİ ÇERÇEVESİ ==

Yazılım destek konsepti yazılım tasarım sürecinin erken safhalarında başlamalıdır. Eğer değişiklik gereksinimleri farklı kaynaklardansa, yazılım değişikliği daha kolay olacaktır. Ayrıca, yükleme ve konfigürasyon prosedürleri de olabildiğince kolay olmalıdır.

Yazılım destek konsepti yazılım tasarım sürecinin erken safhalarında başlamalıdır. Eğer değişiklik gereksinimleri farklı kaynaklardansa, yazılım değişikliği daha kolay olacaktır. Ayrıca, yükleme ve konfigürasyon prosedürleri de olabildiğince kolay olmalıdır.

Yazılım desteğinin 3 farklı perspektifi vardır;

Yazılım desteğinin 3 farklı perspektifi vardır;

·          İlki; destek profili, seviyeler, aktörler ve aktivitelerden oluşur.

* İlki; destek profili, seviyeler, aktörler ve aktivitelerden oluşur.

 

* İkincisi; destek fonksiyonları olan operasyon, yönetim ve modifikasyonlardır.

·          İkincisi; destek fonksiyonları olan operasyon, yönetim ve modifikasyonlardır.

* Sonuncusu ise destek sınıfları olan süreçler, ürün ve çevredir.

 

·          Sonuncusu ise destek sınıfları olan süreçler, ürün ve çevredir.

Yazılım desteğinin LDA kapsamında olup olmayacağı proje kapsamında yapılması planlanan faaliyetler ile birlikte değerlendirilmeli ve yapılması gerektiği değerlendirilirse LDAP’a eklenmelidir. Büyük miktarda yazılım içeren büyük ve karmaşık sistemlerde yazılım desteklenebilirliği ayrı bir alan olarak değerlendirilmelidir. Yazılımlar donanımlara fonksiyonellik katmak için tasarlandıklarından donanım ile arasındaki arayüzler kurulana kadar süreçler birlikte işletilmeli, gözden geçirilmeli, pratiğe dökülmeli ve dokümante edilmelidir.

Yazılım desteğinin LDA kapsamında olup olmayacağı proje kapsamında yapılması planlanan faaliyetler ile birlikte değerlendirilmeli ve yapılması gerektiği değerlendirilirse LDAP’a eklenmelidir. Büyük miktarda yazılım içeren büyük ve karmaşık sistemlerde yazılım desteklenebilirliği ayrı bir alan olarak değerlendirilmelidir. Yazılımlar donanımlara fonksiyonellik katmak için tasarlandıklarından donanım ile arasındaki arayüzler kurulana kadar süreçler birlikte işletilmeli, gözden geçirilmeli, pratiğe dökülmeli ve dokümante edilmelidir.

== 5.1.   YAZILIM DESTEK PROFİLİ ==

== 5.1. YAZILIM DESTEK PROFİLİ ==

Yazılım destek profili kapsamında, yazılım desteğinin gerçekleştirileceği yer, organizasyon ve ilişkili personelin dikkate alınması gerekmektedir. Yazılım destek seviyeleri aşağıdaki gibi tanımlanabilir;

Yazılım destek profili kapsamında, yazılım desteğinin gerçekleştirileceği yer, organizasyon ve ilişkili personelin dikkate alınması gerekmektedir. Yazılım destek seviyeleri aşağıdaki gibi tanımlanabilir;

·          Operasyonel seviye (seviye 1); bu destek seviyesi, yazılımın operasyonel kullanımındaki yerini tanımlar. Bu seviyede, operasyonel servis desteği adı altında basit destek görevleri gerçekleştirilir.

* Operasyonel seviye (seviye 1); bu destek seviyesi, yazılımın operasyonel kullanımındaki yerini tanımlar. Bu seviyede, operasyonel servis desteği adı altında basit destek görevleri gerçekleştirilir.

 

* Orta seviye destek (seviye 2); hem operasyonel servis desteğiyle hem de yönetim desteği ile ilgili tüm destek faaliyetlerini içerir.

·          Orta seviye destek (seviye 2); hem operasyonel servis desteğiyle hem de yönetim desteği ile ilgili tüm destek faaliyetlerini içerir.

* Üst seviye destek (seviye 3); yönetim desteğine ek olarak modifikasyon desteği de burada sağlanır. Yapılacak faaliyetler, karışıklık, boyut, modülerlik, programlama teknikleri vs. gibi yazılım paketinin kendisine ve yazılım modifikasyonunu gerçekleştirecek ekipmana (araçlar, personel, tesisler) dayanır.

* Yazılım sağlayıcı ve/veya geliştirici (seviye 4); yazılım sağlayıcı normalde yazılım modifikasyonuyla ilişkili gerekli geliştirme araçları ve personel ile donatılmış en üst yetenekteki destek seviyesidir. Kullanıcılar çoğunlukla bu yetkinliğe sahip olmadıklarından yazılım modifikasyonları için genelde bu seviyede destek sağlanır.

 

·          Yazılım sağlayıcı ve/veya geliştirici (seviye 4); yazılım sağlayıcı normalde yazılım modifikasyonuyla ilişkili gerekli geliştirme araçları ve personel ile donatılmış en üst yetenekteki destek seviyesidir. Kullanıcılar çoğunlukla bu yetkinliğe sahip olmadıklarından yazılım modifikasyonları için genelde bu seviyede destek sağlanır.

Yazılım destek rollerinin belirlenmesinin ilk aşaması kullanıcı ve yüklenici firma rollerinin tanımlanmasıdır. İkinci aşaması ise, yazılım kullanım ve desteğiyle ilişkili personellerin rollerinin (yetkinlik, erişim, eğitim vb.) tanımlanmasıdır. Aşağıda destek rolleri ve bu kapsamda tanımlanan aktiviteler ve yetkilere ilişkin örnekler verilmiştir;

Yazılım destek rollerinin belirlenmesinin ilk aşaması kullanıcı ve yüklenici firma rollerinin tanımlanmasıdır. İkinci aşaması ise, yazılım kullanım ve desteğiyle ilişkili personellerin rollerinin (yetkinlik, erişim, eğitim vb.) tanımlanmasıdır. Aşağıda destek rolleri ve bu kapsamda tanımlanan aktiviteler ve yetkilere ilişkin örnekler verilmiştir;

·          Basit düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi veya modifikasyonuyla ilgili bir yetkisi yoktur. Ana görevleri yazılım içeren sistemi operasyonel olarak çalışır durumda tutmak ve sistem/yazılım hatalarını raporlamaktır.

* Basit düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi veya modifikasyonuyla ilgili bir yetkisi yoktur. Ana görevleri yazılım içeren sistemi operasyonel olarak çalışır durumda tutmak ve sistem/yazılım hatalarını raporlamaktır.

 

* Orta düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi ile ilgili yetenek ve bilgiye sahiptir. Yazılımı çalışır durumda tutmak için operasyonel destek aktivitelerini gerçekleştirirken, yazılım ve veri yükleme vb. yazılım güncelleme aktivitelerine ise destek vermezler.

·          Orta düzeyde kullanıcı; yazılım sistemlerinin düzeltilmesi ile ilgili yetenek ve bilgiye sahiptir. Yazılımı çalışır durumda tutmak için operasyonel destek aktivitelerini gerçekleştirirken, yazılım ve veri yükleme vb. yazılım güncelleme aktivitelerine ise destek vermezler.

*  Sistem yöneticileri; üst düzey kullanıcılarıdır. Operasyonel destekle ilgili tüm aktivitelerden ve yönetim desteğinden sorumludurlar. Yazılım modifikasyonu gerçekleştirmeseler de, tipik yönetim görevleri olan performans parametrelerinin değiştirilmesi gibi yazılım konfigürasyon işlerinden, ek yazılım paketi yüklemeleri vb. işlerden sorumludurlar.

 

·          Sistem yöneticileri; üst düzey kullanıcılarıdır. Operasyonel destekle ilgili tüm aktivitelerden ve yönetim desteğinden sorumludurlar. Yazılım modifikasyonu gerçekleştirmeseler de, tipik yönetim görevleri olan performans parametrelerinin değiştirilmesi gibi yazılım konfigürasyon işlerinden, ek yazılım paketi yüklemeleri vb. işlerden sorumludurlar.

 

·          Servis sağlayıcı; kalifiye operasyonel desteğinden ve yardım hattı gibi ek servislerden sorumludurlar. Müşteri veya yüklenici tarafında ikamet ederler ve modifikasyon desteği de sağlarlar.

·          Yüklenici/Yazılım geliştirici; en üst seviyeden yazılım modifikasyon desteği sağlarlar.

* Yüklenici/Yazılım geliştirici; en üst seviyeden yazılım modifikasyon desteği sağlarlar.

Farklı destek görevleri ve seviyeleri için farklı bölgelerde farklı kaynaklarla nasıl yapılacağını gösteren kullanım durumlarının tanımlanması gerekmektedir.

Farklı destek görevleri ve seviyeleri için farklı bölgelerde farklı kaynaklarla nasıl yapılacağını gösteren kullanım durumlarının tanımlanması gerekmektedir.

== 5.2.   DESTEK FONKSİYONLARI ==

== 5.2. DESTEK FONKSİYONLARI ==

Yazılımla ilişkili bakım görevleri aşağıda belirtilen hususlara göre farklı kategorilere ayrılabilir;

Yazılımla ilişkili bakım görevleri aşağıda belirtilen hususlara göre farklı kategorilere ayrılabilir;

·          Görev basit bir yükleme/kaldırma görevi mi yoksa yazılımın A cihazından B cihazına taşınma işlemi mi?

* Görev basit bir yükleme/kaldırma görevi mi yoksa yazılımın A cihazından B cihazına taşınma işlemi mi?

 

* Yazılım yüklemesi ya da kaldırılması için bir donanımı çıkarmak gerekli mi?

·          Yazılım yüklemesi ya da kaldırılması için bir donanımı çıkarmak gerekli mi?

* Yazılım modifikasyonu gerekli mi? Yazılım modifikasyonunun özel destek görevleri gerektiren geniş bir alan olması sebebiyle modifikasyonun kapsamı tam olarak belirlenebiliyor mu?

 

·          Yazılım modifikasyonu gerekli mi? Yazılım modifikasyonunun özel destek görevleri gerektiren geniş bir alan olması sebebiyle modifikasyonun kapsamı tam olarak belirlenebiliyor mu?

== 5.2.1.  OPERASYONEL SERVİS DESTEĞİ ==

=== 5.2.1. OPERASYONEL SERVİS DESTEĞİ ===

Operasyonel servis görevleri sistemin günlük operasyonel görevleriyle ilişkili tüm aktiviteleri tanımlar. Fakat bu görevler sistem kullanımı üzerinde farklı kalite ve derinlikte etkilere sebep olabilir (ör. sistem atıl zamanları, test gereksinimleri vb.). Bu görevler, destek seviyesi 1 ve 2’de kullanıcı tarafından yürütülen basit görevlerdir.

Operasyonel servis görevleri sistemin günlük operasyonel görevleriyle ilişkili tüm aktiviteleri tanımlar. Fakat bu görevler sistem kullanımı üzerinde farklı kalite ve derinlikte etkilere sebep olabilir (ör. sistem atıl zamanları, test gereksinimleri vb.). Bu görevler, destek seviyesi 1 ve 2’de kullanıcı tarafından yürütülen basit görevlerdir.

Gömülü yazılımların veya bellenimlerin yükleme görevleri BGA’da belirlenmelidir.

Gömülü yazılımların veya bellenimlerin yükleme görevleri BGA’da belirlenmelidir.

== 5.2.2.  YÖNETİM DESTEĞİ ==

=== 5.2.2. YÖNETİM DESTEĞİ ===

Operasyonel destek ile yazılım modifikasyon görevleri arasında bir yerdedir. Her seviyede kullanıcı tarafından gerçekleştirilebileceği gibi destek organizasyonları tarafından da gerçekleştirilebilir. Problem raporlaması, sistem konfigürasyon kontrolü, teslim ve yükleme ile kullanıcı desteği gibi görev tipleri mevcuttur.

Operasyonel destek ile yazılım modifikasyon görevleri arasında bir yerdedir. Her seviyede kullanıcı tarafından gerçekleştirilebileceği gibi destek organizasyonları tarafından da gerçekleştirilebilir. Problem raporlaması, sistem konfigürasyon kontrolü, teslim ve yükleme ile kullanıcı desteği gibi görev tipleri mevcuttur.

== 5.2.3.  YAZILIM MODİFİKASYON DESTEĞİ ==

=== 5.2.3.  YAZILIM MODİFİKASYON DESTEĞİ ===

Yazılım modifikasyonu, düzeltici, adaptif veya tamamlayıcı sebeplerden ötürü olabilir. Genellikle yüklenici tarafında yapılan bir aktivite olsa da kritikliği düşük değişiklikleri karşılayan ekipman ve yetenekli personel varsa kullanıcı da gerçekleştirebilir. Yazılım modifikasyonu, kodlama değişikliğinin uygulanması ve test gibi modifikasyonun direkt kendi aktivitelerini ve problemin araştırılması ve konfigürasyon kontrolü gibi ilişkili görevleri de içerir. Genellikle, yazılım değişikliği için en kritik sebep ürünün operasyonunda kabul edilemez bir duruma sebep olan gerçek bir hata yaşanmasıdır.  Adaptif değişiklikler de kritik bir durumdan kaynaklanabilir ancak daha tahmin edilebilir ve planlanabilir değişikliklerdir. Tamamlayıcı değişiklikler ise işlevselliği ve kullanıcı kolaylığını artırmak için yapılan değişikliklerdir. Genellikle bir sürüm yükseltme ile birlikte yapılırlar. Kullanıcı gereksinimleri bir süre boyunca toplanır ve yeni yazılım paketinin yayınlanmasıyla uygulamaya koyulurlar. Yazılım modifikasyon görevleri, problem araştırması, değişikliğin uygulanması, değişikliğin yayınlanması, konfigürasyon kontrolü faaliyetlerinden oluşur.

Yazılım modifikasyonu, düzeltici, adaptif veya tamamlayıcı sebeplerden ötürü olabilir. Genellikle yüklenici tarafında yapılan bir aktivite olsa da kritikliği düşük değişiklikleri karşılayan ekipman ve yetenekli personel varsa kullanıcı da gerçekleştirebilir. Yazılım modifikasyonu, kodlama değişikliğinin uygulanması ve test gibi modifikasyonun direkt kendi aktivitelerini ve problemin araştırılması ve konfigürasyon kontrolü gibi ilişkili görevleri de içerir. Genellikle, yazılım değişikliği için en kritik sebep ürünün operasyonunda kabul edilemez bir duruma sebep olan gerçek bir hata yaşanmasıdır.  Adaptif değişiklikler de kritik bir durumdan kaynaklanabilir ancak daha tahmin edilebilir ve planlanabilir değişikliklerdir. Tamamlayıcı değişiklikler ise işlevselliği ve kullanıcı kolaylığını artırmak için yapılan değişikliklerdir. Genellikle bir sürüm yükseltme ile birlikte yapılırlar. Kullanıcı gereksinimleri bir süre boyunca toplanır ve yeni yazılım paketinin yayınlanmasıyla uygulamaya koyulurlar. Yazılım modifikasyon görevleri, problem araştırması, değişikliğin uygulanması, değişikliğin yayınlanması, konfigürasyon kontrolü faaliyetlerinden oluşur.

== 6.        DESTEK SINIFLARI ==

== 6. DESTEK SINIFLARI ==

== 6.1.   SÜREÇLER ==

== 6.1. SÜREÇLER ==

Yazılım desteğine ilişkin süreçlerin nasıl uygulamaya konulacağı, girdiler, çıktılar, kontroller ve kaynakları da içerecek şekilde dokümante edilmelidir. Bu kapsamda, akış şemaları, tanımlar, gereksinim ve sorumluluklar verilebilir. Uluslararası veya şirket içi kabul görmüş bir standart ve kullanılabilir ölçülebilir performans parametreleri tanımlanabilir.

Yazılım desteğine ilişkin süreçlerin nasıl uygulamaya konulacağı, girdiler, çıktılar, kontroller ve kaynakları da içerecek şekilde dokümante edilmelidir. Bu kapsamda, akış şemaları, tanımlar, gereksinim ve sorumluluklar verilebilir. Uluslararası veya şirket içi kabul görmüş bir standart ve kullanılabilir ölçülebilir performans parametreleri tanımlanabilir.

== 6.2.   ÜRÜN ==

== 6.2. ÜRÜN ==

Yazılım ürün karakteristiğinde desteklenebilirlik mümkün olduğunca erken safhalarda adreslenmelidir. Yazılım kalitesi, yazılımın ne kadar iyi ya da kötü tasarlandığına bağlıdır. İyi bir yazılım tasarımı için gereksinimlerin net bir şekilde tanımlanması ve grafiksel kullanıcı arayüzü desteğinin sağlanması gerekmektedir. Modülerlik, değiştirilebilirlik, genişletilebilirlik, basitlik, kolay kullanım, kararlılık, tutarlılık, işlem süresi performansı gibi hususlar tipik yazılım kalite göstergerleri olarak verilebilir.

Yazılım ürün karakteristiğinde desteklenebilirlik mümkün olduğunca erken safhalarda adreslenmelidir. Yazılım kalitesi, yazılımın ne kadar iyi ya da kötü tasarlandığına bağlıdır. İyi bir yazılım tasarımı için gereksinimlerin net bir şekilde tanımlanması ve grafiksel kullanıcı arayüzü desteğinin sağlanması gerekmektedir. Modülerlik, değiştirilebilirlik, genişletilebilirlik, basitlik, kolay kullanım, kararlılık, tutarlılık, işlem süresi performansı gibi hususlar tipik yazılım kalite göstergerleri olarak verilebilir.

== 6.3.   ÇEVRE ==

== 6.3. ÇEVRE ==

Kaliteyi etkileyen çevresel durumlar yazılımı kullanacak ve destekleyecek personel ile başlar. Doğru bir yazılım desteği kapsamında personelin yazılım destek işi için doğru kişi olması, yetenek ve deneyiminin seviyesi, sorunsuz bir yazılım desteğini garanti etmek için kaç kişinin gerekeceği gibi konular önemlidir. Personele ek olarak, tesisler, ofislerin genişliği vb. konular da desteğin kalitesi açısından önemlidir. Bakım görevlerinin belirlenmesi kapsamında bu hususların mutlaka değerlendirilmesi gerekmektedir.

Kaliteyi etkileyen çevresel durumlar yazılımı kullanacak ve destekleyecek personel ile başlar. Doğru bir yazılım desteği kapsamında personelin yazılım destek işi için doğru kişi olması, yetenek ve deneyiminin seviyesi, sorunsuz bir yazılım desteğini garanti etmek için kaç kişinin gerekeceği gibi konular önemlidir. Personele ek olarak, tesisler, ofislerin genişliği vb. konular da desteğin kalitesi açısından önemlidir. Bakım görevlerinin belirlenmesi kapsamında bu hususların mutlaka değerlendirilmesi gerekmektedir.

== 7.        DESTEKLENEBİLİRLİK FAKTÖRLERİ ==

== 7. DESTEKLENEBİLİRLİK FAKTÖRLERİ ==

Yazılım için desteklenebilirlik faktörlerinin bazıları operasyonel destek ile ilişkiliyken, bazıları yazılım modifikasyon desteği ile ilgili olabilirler. Bu nedenle bu faktörlerin proje gereksinimleri dikkate alınarak ele alınması önemlidir. Yazılım desteklenebilirlik faktörleri ile ilgili açıklamalar ilerleyen bölümlerde verilmiştir.  Yazılım desteklenebilirlik faktörlerinin  geliştirme safhasında dikkate alınması (uygulanabilir olanlar için gereksinim tanımlanması, işlevsel akışa dahil edilmesi vb.) gerekmektedir.

Yazılım için desteklenebilirlik faktörlerinin bazıları operasyonel destek ile ilişkiliyken, bazıları yazılım modifikasyon desteği ile ilgili olabilirler. Bu nedenle bu faktörlerin proje gereksinimleri dikkate alınarak ele alınması önemlidir. Yazılım desteklenebilirlik faktörleri ile ilgili açıklamalar ilerleyen bölümlerde verilmiştir.  Yazılım desteklenebilirlik faktörlerinin  geliştirme safhasında dikkate alınması (uygulanabilir olanlar için gereksinim tanımlanması, işlevsel akışa dahil edilmesi vb.) gerekmektedir.

== 7.1.   UYUMLULUK MATRİSİ ==

== 7.1. UYUMLULUK MATRİSİ ==

Bir sistemde farklı donanımlar üzerindeki farklı yazılımların birlikte çalışabildiği ve yazılım kalemleri içeren fiziksel kırılım içerisinde yazılımların donanımlarla uyumluluğu doğrulanmalıdır. Yazılım paketi taşıyan birbiriyle konuşan ekipmanlarla ilişkili uyumluluk matrisi hazırlanmalıdır.

Bir sistemde farklı donanımlar üzerindeki farklı yazılımların birlikte çalışabildiği ve yazılım kalemleri içeren fiziksel kırılım içerisinde yazılımların donanımlarla uyumluluğu doğrulanmalıdır. Yazılım paketi taşıyan birbiriyle konuşan ekipmanlarla ilişkili uyumluluk matrisi hazırlanmalıdır.

|}

|}

== 7.2.   DOKÜMANTASYON ==

== 7.2. DOKÜMANTASYON ==

Tanımlanmış bakım seviyeleri kapsamında yazılım destek dokümantasyonunun hazırlanması gerekmektedir. Yüklenici tarafında gerekli yazılım destek dokümantasyonu veya kullanıcıya tanımlanan yetkiler dahilinde son kullanıcı el kitabı, yükleme, konfigürasyon gibi amaçları olan yönetim dokümantasyonları olabilir.  

Tanımlanmış bakım seviyeleri kapsamında yazılım destek dokümantasyonunun hazırlanması gerekmektedir. Yüklenici tarafında gerekli yazılım destek dokümantasyonu veya kullanıcıya tanımlanan yetkiler dahilinde son kullanıcı el kitabı, yükleme, konfigürasyon gibi amaçları olan yönetim dokümantasyonları olabilir.  

Operasyonel açıdan, orta ve üst düzey kullanıcılar açısından dokümantasyon önemlidir. Dokümantasyon; yükleme, konfigürasyon adımları ve sorun giderme ile ilgili taktikler içermelidir. Ciddi hatalar oluşması durumunda da yüklenici firma iletişime geçilecek kişinin iletişim bilgilerini de içermelidir.

Operasyonel açıdan, orta ve üst düzey kullanıcılar açısından dokümantasyon önemlidir. Dokümantasyon; yükleme, konfigürasyon adımları ve sorun giderme ile ilgili taktikler içermelidir. Ciddi hatalar oluşması durumunda da yüklenici firma iletişime geçilecek kişinin iletişim bilgilerini de içermelidir.

== 7.3.      YAZILIM YÜKLEME VE KALDIRMA ==

== 7.3. YAZILIM YÜKLEME VE KALDIRMA ==

Yazılımların güvenli bir şekilde sisteme yüklendiği, sistemin problemsiz çalıştığı ve yazılımın kaldırılması test prosedürleri ile doğrulanmış ve dokümante edilmiş olmalıdır.

Yazılımların güvenli bir şekilde sisteme yüklendiği, sistemin problemsiz çalıştığı ve yazılımın kaldırılması test prosedürleri ile doğrulanmış ve dokümante edilmiş olmalıdır.

== 7.4.   DONANIMLAR ÜZERİNDE TAŞINMA ==

== 7.4. DONANIMLAR ÜZERİNDE TAŞINMA ==

Eğer yazılımın bir donanım üzerinde taşınması gerekiyorsa yazılımın tipine, boyutuna ve güvenlik gereksinimlerine göre hangi donanımla taşınacağı belirlenir. Çipler veya usb belleklerle taşınıp taşınamayacağı, hard disk ya da DVD ihtiyacı olup olmadığı, donanımda taşımanının güvenli olup olmadığı değerlendirilmelidir.

Eğer yazılımın bir donanım üzerinde taşınması gerekiyorsa yazılımın tipine, boyutuna ve güvenlik gereksinimlerine göre hangi donanımla taşınacağı belirlenir. Çipler veya usb belleklerle taşınıp taşınamayacağı, hard disk ya da DVD ihtiyacı olup olmadığı, donanımda taşımanının güvenli olup olmadığı değerlendirilmelidir.

== 7.5.   GENİŞLEME KAPASİTESİ ==

== 7.5. GENİŞLEME KAPASİTESİ ==

Genişleme kapasitesi sistem tasarımının bir parçasıdır, yazılımla ilişkili olsa da genellikle tüm sistem tasarımı içerisinde ele alınması gereken bir donanım karakteristiğidir. Yazılımın hesaplama kaynakları üzerinde kısıtlamalarda (işlemci performansı, bellek, girdi/çıktı bant genişliği, veritabanı kapasitesi, network performansı vb.) limiti olmadan ne kadar değiştirilebildiği ile ilgilenir.  Genişleme kapasitesi yeterli detayda ele alınmazsa yazılım modifikasyonu limitli olacaktır. Modifikasyon maliyeti ciddi ölçüde artacak ve ek aktiviteler gerekebilecektir. Genişleme kapasitesi, sabit donanım konfigürasyonu olan sistemlerde ve gömülü sistem gerçek zaman uygulamalarında yüksek önem taşır. Bu nedenle tasarım safhasında genişleme kapasitesinin göz önünde bulundurulması önemlidir.

Genişleme kapasitesi sistem tasarımının bir parçasıdır, yazılımla ilişkili olsa da genellikle tüm sistem tasarımı içerisinde ele alınması gereken bir donanım karakteristiğidir. Yazılımın hesaplama kaynakları üzerinde kısıtlamalarda (işlemci performansı, bellek, girdi/çıktı bant genişliği, veritabanı kapasitesi, network performansı vb.) limiti olmadan ne kadar değiştirilebildiği ile ilgilenir.  Genişleme kapasitesi yeterli detayda ele alınmazsa yazılım modifikasyonu limitli olacaktır. Modifikasyon maliyeti ciddi ölçüde artacak ve ek aktiviteler gerekebilecektir. Genişleme kapasitesi, sabit donanım konfigürasyonu olan sistemlerde ve gömülü sistem gerçek zaman uygulamalarında yüksek önem taşır. Bu nedenle tasarım safhasında genişleme kapasitesinin göz önünde bulundurulması önemlidir.

== 7.6.   MODÜLER YAZILIM TASARIMI ==

== 7.6. MODÜLER YAZILIM TASARIMI ==

Modülerlik yazılım tasarım yapısının bir özelliğidir. Bir yazılım paketinin içindeki işlevselliğin farklı alanları modüller yardımıyla yapılandırılır. Bir yazılım tasarımına modülerlik kazandırma imkânı tasarım yöntemi, programlama araçları ve programlama dili seçimiyle belirlenir. Optimum modülerliğe, desteklenebilir tasarım karşısında işlevsel ve performans gereksinimlerinin dengelenmesi ile ulaşılır. Yetersiz modülerlik ilave modifikasyon eforuna ve maliyetine sebep olur. Bu nedenle tasarım safhasında modülerliğin göz önünde bulundurulması önemlidir.

Modülerlik yazılım tasarım yapısının bir özelliğidir. Bir yazılım paketinin içindeki işlevselliğin farklı alanları modüller yardımıyla yapılandırılır. Bir yazılım tasarımına modülerlik kazandırma imkânı tasarım yöntemi, programlama araçları ve programlama dili seçimiyle belirlenir. Optimum modülerliğe, desteklenebilir tasarım karşısında işlevsel ve performans gereksinimlerinin dengelenmesi ile ulaşılır. Yetersiz modülerlik ilave modifikasyon eforuna ve maliyetine sebep olur. Bu nedenle tasarım safhasında modülerliğin göz önünde bulundurulması önemlidir.

== 7.7.   MODİFİKASYON FREKANSI (DEĞİŞİKLİK TRAFİĞİ) ==

== 7.7. MODİFİKASYON FREKANSI (DEĞİŞİKLİK TRAFİĞİ) ==

Yazılımın modifikasyon ihtiyacının oranıdır. Yazılım kullanımından önce modifikasyon frekansı tahminleri benzer uygulamaların (kullanımdaki yazılımlar) yardımı ile yazılımın bazı karakteristikleriyle, test ve deneme fazındaki deneyimlerle yapılabilir. Modifikasyon frekansının kararlılığı yazılım entegrasyonunu ve sistem operasyonunu etkiler. Değişiklik trafiği, yazılım destek aktivitelerinin hacmini etkiler.  Yüksek değişiklik trafiği daha fazla yazılım modifikasyon aktivitesi demektir. Bu nedenle tasarım safhasında modifikasyon frekansının göz önünde bulundurulması önemlidir.

Yazılımın modifikasyon ihtiyacının oranıdır. Yazılım kullanımından önce modifikasyon frekansı tahminleri benzer uygulamaların (kullanımdaki yazılımlar) yardımı ile yazılımın bazı karakteristikleriyle, test ve deneme fazındaki deneyimlerle yapılabilir. Modifikasyon frekansının kararlılığı yazılım entegrasyonunu ve sistem operasyonunu etkiler. Değişiklik trafiği, yazılım destek aktivitelerinin hacmini etkiler.  Yüksek değişiklik trafiği daha fazla yazılım modifikasyon aktivitesi demektir. Bu nedenle tasarım safhasında modifikasyon frekansının göz önünde bulundurulması önemlidir.

== 7.8.   GERİYE DÖNDÜRME ==

== 7.8. GERİYE DÖNDÜRME ==

Bir yazılım hatasından kaynaklı sistem çalışmadığında, sistemi yeniden başlatmak veya en azından kabul edilebilir bir sürede azalmış ama kabul edilebilir işlevselliğe getirmek gereklidir. Geriye döndürme yazılımın erken tasarım safhalarında, sağlıklı izleme durumu, hataya toleranslı denetimciler, hata ayıklama (debug) özelliği için tasarım gibi konular da değerlendirilmelidir. Erişilebilir ekipmanla operasyonel gerçek zaman güncellemesi gerçekleştirebilecek bir geriye döndürme özelliği olması kritik önem taşımakta olup geliştirme safhasında dikkate alınmalıdır. Gerçek bir acil durum oluşmadan yazılımın geriye döndürülmesi test edilmiş olmalıdır.

Bir yazılım hatasından kaynaklı sistem çalışmadığında, sistemi yeniden başlatmak veya en azından kabul edilebilir bir sürede azalmış ama kabul edilebilir işlevselliğe getirmek gereklidir. Geriye döndürme yazılımın erken tasarım safhalarında, sağlıklı izleme durumu, hataya toleranslı denetimciler, hata ayıklama (debug) özelliği için tasarım gibi konular da değerlendirilmelidir. Erişilebilir ekipmanla operasyonel gerçek zaman güncellemesi gerçekleştirebilecek bir geriye döndürme özelliği olması kritik önem taşımakta olup geliştirme safhasında dikkate alınmalıdır. Gerçek bir acil durum oluşmadan yazılımın geriye döndürülmesi test edilmiş olmalıdır.

== 7.9.   EMNİYET ENTEGRASYONU ==

== 7.9. EMNİYET ENTEGRASYONU ==

Sistemin emniyet analizi yazılımlar da dikkate alınarak yapıldıktan sonra, sistem tasarımı kritik fonksiyonları olan yazılım kalemlerinin minimize edilmiş olduğunu ya da en azından kritik fonksiyonların yazılımın diğer kısımlarından ayrıştırıldığını garanti etmelidir. Emniyet entegrasyonu yalnızca yazılım tasarımıyla ilgili değildir. Yazılımın taşıma, yükleme ve kullanımında da (ör. yazılımlara kullanıcı erişimleri) belirli bir emniyet seviyesine ulaştığı garanti edilmelidir.

Sistemin emniyet analizi yazılımlar da dikkate alınarak yapıldıktan sonra, sistem tasarımı kritik fonksiyonları olan yazılım kalemlerinin minimize edilmiş olduğunu ya da en azından kritik fonksiyonların yazılımın diğer kısımlarından ayrıştırıldığını garanti etmelidir. Emniyet entegrasyonu yalnızca yazılım tasarımıyla ilgili değildir. Yazılımın taşıma, yükleme ve kullanımında da (ör. yazılımlara kullanıcı erişimleri) belirli bir emniyet seviyesine ulaştığı garanti edilmelidir.

'''1.        GENEL:'''

'''1.        GENEL:'''

·          Programın hem yüklenici hem de müşteri tarafındaki yönetim yapıları

* Programın hem yüklenici hem de müşteri tarafındaki yönetim yapıları

 

* LDA faaliyetlerinin proje takvimi ile entegrasyonu

·          LDA faaliyetlerinin proje takvimi ile entegrasyonu

 

* Değişiklik yönetimi

* Risk yönetimi

 

* İş paylaşımı anlaşmaları

·          Değişiklik yönetimi

 

·          Risk yönetimi

 

·          İş paylaşımı anlaşmaları

'''2.        SİSTEM TANIMI VE OPERASYONEL KONSEPT TANIMI (BKZ. BÖLÜM 5.1)'''

'''2.        SİSTEM TANIMI VE OPERASYONEL KONSEPT TANIMI (BKZ. BÖLÜM 5.1)'''