Yazılımda Kalite

Yazılımın Kalite Etkenleri

Yazılımın kalitesinin garanti altına alınması ve iyileşme sağlanabilmesi , sürekli ölçümleme ve iyileştirme ile olabilir. Gerekli iyileştirmeler ölçümleme sonucu elde edilen bilgilere dayanılarak yapılabilir. Ölçümleme yapılmadan hazırlanan eylem planları kesinlikle gerekçesiz ve gelişigüzel olacaktır.

Yazılımda Kalite 

Yazılım endüstrisindeki gelişmeler, yazılım geliştirme sürecini etkileyerek bu süreci proje yönetimi çerçevesinde geliştirilen faaliyetler haline getirmiştir. Günümüzde artık küçük ölçekli yazılımlar bile sadece bir kişinin değil, iyi yönetilen bir yazılım ekibinin birlikte gerçekleştirdiği, binlerce kod satırından meydana gelen projelerdir. Yazılım projelerinin gittikçe büyümesi, karmaşıklaşması ve boyutlarının sürekli artması yazılımın kalitesini de etkilemekte, bakım maliyetlerinin zaman ve çaba olarak artması problemlerini de beraberinde getirmektedir. 

• Doğruluk 
• Güvenilirlik 
• Verimlilik 
• Güvenlik(Bütünlük) 
• Kullanılabilirlik
•  Hata bulma kolaylığı
•  Esneklik 
• Test kolaylığı 
• Taşınabilirlilik
•  Tekrar kullanılabilirlik
•  Birlikte çalışabilirlik

Yazılım Kalite Metrikleri

Code Coverage

Yazılan testlerin kodun ne kadarını kapsadığını ölçer. Code coverage için %80 gibi bir oran oldukça iyi görünse de aslında az sayıda basit test yazarak dahi bu orana ulaşılabildiği gözlemlendiği için hedeflenen oranın %100 olması önerilir.

Cohesion

Bu ölçüm sınıfın sorumlu olduğu işlerin kendi içindeki uyumluluğunu ölçer. Her sınıfın tek bir sorumluluğu olmalıdır.Uyumluluk LCOM (Lack of Cohesionin Methods) adı verilen ölçüt ile bulunur. Değişik türleri bulunan LCOM sınıfta yer alan alanlara metodların ortak erişim sayısını temel alan bir ölçümdür. LCOM3 için bu değer 0 ile 2 arasında değişir ve 1'in üzerindeyse sınıf bölünmelidir.

Specialization Index (SIX)

Kod karmaşıklığını ve bakım maliyetlerini arttırmasından dolayı overload edilmiş fonksiyon sayısının mümkün olduğunca az olması istenir. Bundan dolayı SIX = (Overload Edilmiş Metot Sayısı * DIT) / NOM şeklinde hesaplanır. 1.2 (veya %120)'ye kadar normal kabul edilir.

Sınıfın Methot Sayısı 

İdeal değerler 6 ile 20 arasında değişse de 40'ın üzerinde sınıf kesinlikle bölünmelidir. Ancak tek başına bir gösterge olmaktan çok LCOM ile birlikte değerlendirilmelidir.

Sınıfın Tetiklediği Metot Sayısı ( RFC )

       Bir sınıftan bir nesnenin metotları çağrılması durumunda, bu nesnenin tetikleyebileceği tüm metotların sayısı RFC değerini verir.Kısaca bir sınıfta yazılan ve çağrılan toplam metot sayısıdır. Bu metrik kullanılarak yazılımın anlaşılabilirlik, dayanıklılık, karmaşıklık, test edilebilirlik gibi özelliklerini ölçmek söz konusudur.

Alt Sınıf Sayısı ( NOC )

       Bir sınfıtan direk olarak türetilmiş alt sınıfların sayısını gösteren metriktir. Eğer alt sınıf sayısı fazla ise yeniden kullanım yüksek, hata riski fazladır. Bu metrik ile yazılımın verimlilik,yeniden kullanılabilirlik, test edilebilirlik gibi  özelliklerini ölçmek mümkündür.

Verimlilik

Yazılımın ihtiyaç duyulan ölçüde yeterli performansla çalışabilme becerisi olarak tanımlanmaktadır. Zaman ve kaynak kullanımı konuları bu sınıf altında incelenmektedir.

Taşınabilirlik

Yazılımın çalıştığı ortam değişikliklerine uyum sağlayabilme yeteneği olarak tanımlanmaktadır. Adaptasyon yeteneği, yüklenebilirlik özellikleri, ortam değiştirme imkânı ve diğer yazılımlarla uyum konuları bu sınıf altında incelenmektedir.

Güvenilirlik

Yazılımın düzgün çalışma halini muhafaza edebilme becerisi olarak tanımlanmaktadır. Olgunluk, hata toleransı ve geri kurtarma konuları bu sınıf altında incelenmektedir.

8.Kullanılabilirlik

Yazılımın kullanım kolaylığı sağlayan yetenekleri olarak tanımlanmaktadır. Öğrenebilme, anlaşılabilirlik, işletilebilirlik ve kullanıcı etkileşimi konuları bu sınıf altında incelenmektedir.

1-) What is ITIL?

                              

            

                                                                  What is ITIL? 

The objective of the IT Infrastructure Library was to develop effective and efficient methods for the provision of IT services - in other words a catalogue of best practices for the IT organization, which today is known as ITIL®. 

How did ITIL start? 

The IT Infrastructure Library ITIL® [1] was developed at the end of the 1980's by the Central Computing and Telecommunications Agency (CCTA), a government agency in Great Britain. The reason for commissioning the CCTA was a lack of quality of the IT services procured by the British Government, so that a method had to be found to achieve better quality and simultaneously decrease their costs. 

The ITIL Service Lifecycle 

In 2007 the OGC published a completely revised version of ITIL, known as "ITIL Version 3 (ITIL V3)". 

ITIL V3 reflects the experiences gained with the earlier versions and puts a greater emphasis on creating business value. 

In comparison to ITIL V2 - which consisted of nine books - ITIL V3 is more streamlined around a set of five new core publications which together form the "ITIL Service Lifecycle": 

• Service Strategy 
• Service Design 
• Service Transition 
• Service Operation 
• Continual Service Improvement 

The rationale for organizing the ITIL books in this way was to establish a Deming-like Plan-Do-Check-Act cycle focused on continual improvement. 

Overall, ITIL V3 complements the processes known from ITIL V2 with a number of new processes and puts more emphasis on producing value for the business. The underlying principles of ITIL are largely unchanged. 

ITIL Service Operation 

Objective: The objective of ITIL Service Operation is to make sure that IT services are delivered effectively and efficiently. The Service Operation lifecycle stage includes the fulfilling of user requests, resolving service failures, fixing problems, as well as carrying out routine operational tasks. 

 Event Management 

Process Objective: To make sure CIs and services are constantly monitored, and to filter and categorize Events in order to decide on appropriate actions. 

Incident Management 

Process Objective: To manage the lifecycle of all Incidents. The primary objective of Incident Management is to return the IT service to users as quickly as possible. 

Request Fulfilment 

Process Objective: To fulfill Service Requests, which in most cases are minor (standard) Changes (e.g. requests to change a password) or requests for information. 

Access Management 

Process Objective: To grant authorized users the right to use a service, while preventing access to non-authorized users. The Access Management processes essentially execute policies defined in Information Security Management. Access Management is sometimes also referred to as Rights Management or Identity Management. 

Problem Management 

Process Objective: To manage the lifecycle of all Problems. The primary objectives of Problem Management are to prevent Incidents from happening, and to minimize the impact of incidents that cannot be prevented. Proactive Problem Management analyzes Incident Records, and uses data collected by other IT Service Management processes to identify trends or significant Problems. 

IT Operations Control 

Process Objective: To monitor and control the IT services and their underlying infrastructure. The process IT Operations Control executes day-to-day routine tasks related to the operation of infrastructure components and applications. This includes job scheduling, backup and restore activities, print and output management, and routine maintenance. 

Facilities Management 

Process Objective: To manage the physical environment where the IT infrastructure is located. Facilities Management includes all aspects of managing the physical environment, for example power and cooling, building access management, and environmental monitoring. 

Application Management 

Application Management is responsible for managing applications throughout their lifecycle. 

Technical Management 

Technical Management provides technical expertise and support for the management of the IT infrastructure. 

Part -2-