Kullanışlı arayüzü ile online olarak Visio tarzında diyagramlar hazırlayıp web tabanlı olarak yayınlayabileceğiniz, birçok dosya formatına export edebileceğiniz, diğer kullanıcılar ile paylaşabileceğiniz çok yararlı bir web sitesi. Akışlarınıza ve çizimlerinize istediğiniz yerden ulaşmak için ideal bir site. Ücretsiz hesap seçeneğinde, 25 adet diyagram oluşturmanıza izin veriyor.

screencast-o-matic.com

Online bir screen capturing uygulaması. Bilgisayarınıza yalnızca bir java applet kurarak, ekran hareketlerinizi video olarak kaydetmenize olanak veriyor. Kayıtlarınızı avi, mp4 veya flv olarak export edebilir veya direkt olarak Youtube’da yayınlayabilirsiniz. Hayat kurtaran uygulamalardan biri olarak sık kullanılan siteleriniz arasına eklemenizde fayda var.

ITIL Versiyon2 ile bilinirliği ülkemizdede ciddi oranda artan Bilişim standardizasyonu malesef güncelleme konusunda sıkıntılar yaşamıştır. Bu yazımızda ITIL Versiyon3 üzerinde duruyor ve süreçlerini ana hatları ile inceleyerek devam ediyor olacağız. Veriyon 2 içeriğine yazımızın içerisinde zaman zaman atıfta bulunurken, Versiyon 3 ile arasındaki farkları ve neden versiyon 3 ihtiyacının olduğu konusunu, Ana hatları ile bahsedeceğimiz süreçlerin herbirini, V-Model, ARCI Model yapısını ve uygulama yapısını, ISO 20000 ile arasındaki ilişkiyi ve risk analizleri ile birlikte bizler için çok önem taşıyacak olan bir takım checklister gibi ITIL spesifik tüm konuları makale dizisinde sizlere aktarıyor ve paylaşıyor olacağım.

İlk yazımızda isterseniz ITIL hakkında genel bir giriş yaparak süreç haritasına ve tasarımlara göz atıyor olalım.

ITIL – Bölüm(1)

ITIL kısaltmasını “Bilişim teknolojileri altyapı kütüphanesi” olarak açıklayabiliriz. Peki nedir bu altyapı kütüphanesi. ITIL aslında tam olarak BT Servis Yönetimi framework’ünün(Çatı-iskelet) uygulanmasını sağlamak ve kolaylaştırmak için kullanılan belgeler dizisidir. Bu özelleştirilebilir iskelet, bir Organizasyon içerisine servis yönetiminin nasıl uygulanacağını tanımlar.

İngiliz hükümetinin bir birimi olan CCTA (Central Computer and Telecomunications Agency) tarafından geliştirilmiştir ancak bu çalışma dünya üzerinde birçok özel ve yerel kurum ile birlikte akademisyenlerin de katıldığı bir çalışma ile meydana gelmiştir .

Uygulamaya dayalı bir yaklaşımı yansıtmak için Hizmet Yönetimi uygulamaları olarak bilinen ITIL v3 temel olarak birbiri ile bağlantılı 5 faz’dan oluşmaktadır; (İlerleyen makalelerimizde her bir fazı detaylı olarak açıklıyor olacağız..)

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

Şekil-1: ITIL V3 Mimarisi

Birazdan bu 5 kısımdan bahsediyor olucaz ancak isterseniz biraz daha yukardan bakarak durumu yorumlamaya çalışalım.

ITIL oluşumunu sağlayan 5 başlık aslında Sevis yaşam döngümüzün oluşmasını sağlayan süreçler ile bunların dışında bu süreçleri etkileyen ve BT organizasyonumuzun dışında bulunan iç müşteri ve dış tedarikçi süreçleri servis yaşam döngümüzü etkileyen süreçlerden meydana geliyor. İsterseniz bir örnek vererek açıklamaya çalışalım; Bir Telekomunikasyon firmasının içerisindeki IT Organizasyonu olduğumuzu düşünelim ve vermiş olduğumuz hizmet çerçevesi içerisinde servis yaşam döngüsünü oluşturmuş durumdayız. Hatta bu durumu biraz daha ilerletip iç müşterimiz ile SLA(Service Level Aggrement) imzalamış olalım ve bu anlaşma içerisinde müşterimize oluşan herhangi bir problemi çözme zamanı taahhüt etmiş olalım. Diyelimki sorumlu olduğumuz yapı içerisindeki bileşenlerden biri olan mail sunucumuz herhangi bir sebepten dolayı çalışmıyor ve iç müşterimize destek veremiyoruz. Bu noktada problemi gidermek için dış kaynak kullanıyor yada herhangi bir donanım problemi ise tedarikçi üzerinden parça sağlıyoruz. Tedarikçi üzerinden gerekli olan hizmeti almak için izlemiş olduğumuz prosedürler, geçen zaman ve bu süre içerisinde mail hizmetini veremiyor olmamız yada taahhüt etmiş olduğumuz zaman diliminde problemi çözemiyor olmak nedeni ile oluşan diğer zincir reaksiyonlar aslında çerçevesi çizilmesi gereken ve yaşam döngümüzü etkileyen süreçler haline geliyor.

Yani aslında Sadece kendi IT organizasyonumuz içerisinde yer alan süreçler bizim Servis yaşam döngümüzü tamamlamamıza yeterli olmuyor. Bunların dışında kalan diğer süreçler ile entegrasyon sağlıyor olmakla ancak döngüyü tamamlayabiliyor olduğumuz sonucu oluşuyor.

Yazımızın başındada tanımını vermiş olduğumuz gibi Bir Organizasyon içerisinde Servis Yönetiminin nasıl uygulanacağını, belirlenmiş olan 5 faz ve bunların altında yeralan akış süreçleri ile az önce bahsetmiş olduğumuz dış süreçleri teker teker tanımlayarak Servis yaşam döngümüzü tamamlayabiliriz.

Şekil-1′de görmüş olduğunuz gibi mimari birbiri ile grift bir ilişiki içerisinde yer alıyor. Bir BT Organizasyonu içerisindeki BT stratejilerinin belirlenerek tasarımının yapılması sonrasında servis geçiş süreçlerinin tanımlanması ve operayon süreçlerinin tanımlanması ile servis yaşam döngüsünün büyük bir kısmını tamamlamış oluyoruz. En son fazda ise Servis kalitesinin artırılabilmesi için gereken raporlama, ölçümleme ve iyileştirme işlemlerinin yapılacağı süreçlerin diğer süreçler ile entegre edilmesi ile süreç haritamızı tamamlamış oluyoruz.

Süreçlerin tasarlanabilmesi, uygulanabilmesi,entegre edilebilmesi ve yönetilebilmesi noktasında birtakım ana roller’e ihtiyaç duyulmuş ve ilgili roller tanımlanmıştır. Bu roller organizasyon süreçlerinin analiz edilmesinden sonra deploy edilmelidir. Kısaca bu görevlere bakacak olursak;

• Service Owner : Bir servisin tasarımı, entegrasyonu, performansı, iyileştirilmesi ve yönetilmesini kapsar.
• Process Owner : Bir servisin tasarımı, entegrasyonu, performansı, iyileştirilmesi ve yönetilmesini kapsar.
• Product Manager : İlgili servis gruplarının performansı, iyileştirilmesi ve yönetilmesini kapsar.
• Service Manager : Oluşum içerisinde yeralan tüm servislerin performansı, iyileştirilmesi ve yönetilmesini kapsar.

Buna paralel olarak iş Modellemesi üzerinden sorumluluk ve rol tanımlarına yukardan baktığımızda Şekil-2 de görünün sorumluluk yapısı hiyerarşik olarak görülüyor.

Resim-2

Süreçlerin tasarımı, iyileştirilmesi, geliştirilmesi ve yönetilmesi için kullanılmakta olan rollerimizin dışında özellikle servis geçişi ve operasyon süreçleri esnasında tanımlanması gereken bir takım rollerimiz olucak. ARCI Model diye adlandırılan bir matrix yardımı ile görev tanımları yerleştiriliyor olucağız ki bu modelleme yapısı üzerinde ayrı bir yazımızda duracağız.

Resim-3

• Service Strategy (Hizmet Strateji)
  

Servis Yönetiminin uygulanması,geliştirilmesi ve tasarlanması konusunda rehber niteliğindedir. Bu konuda BT Organizasyonlarının müşterilerine farklı hizmetler sunmasını ve operasyonel etkinliğini artırmasını amaçlar.

Süreçler;

• Service Portfolio Management : Hizmet Portföy Yönetimi süreci, Hizmet Portföyü hizmetlerine ilişkin bilgi yönetimi ile ilgilenir
• Demand Mamagement : Talep süreçleri Yönetimi, müşteri taleplerini anlama ve etkileme ile ilgilenir.
• IT Financial Management : BT Finans yönetimi, “Maliyetleri yönetmeyi ve anlamayı ” ve Mali anlamda hizmetler ile ilgili fırsatlarla ilgilenir.

Roller ve Sorumluluklar;

• Business Relationship Manager (BRM): Müşterisinin iş gerekliliklerini ve onların müşterisinin ihtiyaçlarının belirlenmesi noktasında güçlü ilişkiler kurar. Müşterisi adına verimli sonuçlar çıkarabilme noktasında PM ile yakın çalışır.
• Product Manager (PM) : Servis Yaşam Döngüsündeki servislerin yönetilmesi ve geliştirilmesinden sorumludur.
• Chief Sourcing Officier (CSO) : CIO(Chief Information Officier) ile yakın işbirliği içerisinde kaynak stratejisinin geliştirilmesi ve kaynakların yönlendirilmesi ve yönetilmesinden sorumludur.

• Service Design (Hizmet Tasarım)
  

Servis Tasarımı, iş gereksinimleri değişimi sürecinde önemli bir eleman ve Genel servis yaşam döngüsü içerisinde önemli bir katmandır.

Özelleştirilebilir ve Yenilikçi BT Hizmetleri tasarımı, süreçler, politikalar ve belgeler de dahil olmak üzere mevcutta kabul edilmiş ve gelecekteki iş gereksinimlerini karşılamak için oluşturulan mimarilerdir.

Başarılı bir tasarımın yapılabilmesi için 4P (People,Product,Processes, Partners) tasarımının doğru yapılmasına bağlıdır.

Service Design Package (SDP); Servis Yaşam döngüsünün her bir aşamasındaki gereklilikleri ve bir BT Servisinin bütün yönlerini tanımlar. Bir SDP, her yeni servis, major değişiklik yada bir servisin kaldırılması durumunda yeniden üretilir.

Süreçler;

• Service Catalogue Management (SCM): Hizmet kataloğu,
  Servis Destek sağlayıcısı tarafından BT servisleri hakkındaki bilgilerin merkezi bilgi kaynağı üzerinden iletiminden sorumludur.
• Service Level Management (SLM): Spesifik hizmetler ile ilişikilendirilmiş garanti seviyeleri, Hizmet sağlayıcı ile ilgili performans seviyeleri, müşteri ile yapılan anlaşmanın yönetilmesi ve güvenliği,fiyatlandırılması konularından sorumludur.

SLM süreçleri içerisinde SLA(Service Level Aggrement), OLA(Operational Level Aggrement) bulunur ve SIP (Service Improvement Plan) ile Service Quality Plan’ın üretilmesini sağlar.

• Capacity Management : Kapasite Yönetimi servis ömrü boyunca iş, hizmet ve bileşen kapasite yönetimi içerir. Kapasite yönetiminin temel başarı faktörü, tasarım aşamasında göz önünde bulundurulmasıdır.

Tüm Kapasite ve performans tabanlı sorunların yönetimine ve hizmet ve kaynaklara ilişkin iş taleplerinin uyuşmasına odaklanır.

3 Ana faaliyet sözkonusudur;

• Business Capacity Management
• Service Capacity Management
• Component Capacity Management

• Availability Management : Kullanılabilirlik Yönetimi, kurgulanan SLA(Servis seviyesi Anlaşması) içerisindeki kullanılabilirlik gereksinimlerinin ve yönetiminin başarısı ile ilgilidir.

Kullanılabilirlik, Gerektiğinde sistem, hizmet yada Configuration-Item fonksiyonu gerçekleştirme yeteneği olarak tanımlanır.

• IT Service Continuity Management (ITSCM) : Herhangi bir felaket olayı esnasında BT hizmet ve servisleri için planlama ve risk yönetimi ile ilgilenir.

BIA (Business Impact Analysis) ve MOR(Management of Risk) tekniklerini kullanarak iş sürekliliği yönetiminde büyük çaba harcar.

• Information Security Management (ISM) : Servisler de dahil olmak üzere tüm BT envanterlerini gelebilecek tehditlere karşı korumak ile ilgilenen süreçtir.

5 temel niteliğin korunması üzerinde duruluyor;

• Confidentiality
• Integrity
• Availability
• Authenticity
• Non-Repudiation

• Supplier Management : Tedarikçi Yönetimi aslında Service Level Management((SLM)- Hizmet seviyesi yönetimi))’ne çok benzer bir rol oynar ve Hizmet tasarımı içerisinde kritik bir rol alır. İç tedarikçi ve müşterilerden daha çok dış tedarikçiler ile ilgilenir.

Özellikle son yıllarda oranı artan dış tedarikçi ile yapılan anlaşmalardan da anlaşılabileceği üzere kendi müşterilerine daha iyi hizmet verebilme noktasında dış tedarikçilere olan bağımlılık artmıştır.

Roller ve Sorumluluklar;

• Service Design Manager : Hizmetler ve süreçler noktasında oluşturulan tasarım ve genel koordinasyon dan sorumludur.
• IT Designer /Mimar : Planlama, tasarım, strateji, mimari, tasarım için gereken teknolojiler ve genel koordinasyondan sorumludur.
• Service Catalogue Manager : Doğru bir Hizmet kataloğunun oluşması noktasındaki üretim, geliştirme ve bakımdan sorumludur.
• Service Level Manager : Hizmet Seviyesi kalitesinin karşılanabilmesi ve kabul edilebilir olmasından sorumludur.
• Availability Manager : Tüm Servislerin kabul edilebilir hedeflerine ulaşmasından sorumludur.
• IT Service Continuity Manager : İş ihtiyaçları, gereklilikleri ve zaman çizelgelerine uygun olarak tüm servislerin iyileştirilmesinden sorumludur.
• Capacity Manager : BT Kapasitesinin bügünkü ve gelecekteki iş talepleri ile uyumlu olmasından sorumludur.
• Security Manager : Belirlenmiş iş güvenliği politika riskleri, etkileri ve gereksinimleri ile BT güvenliğinin uyumlu olmasından sorumludur.
• Supplier Manager : BT Tedarikçileri,sözleşmeleri ve anlaşmaların iş ihtiyaçlarına uyumlu olması ve değerinden sorumludur.

• Service Transition (Hizmet Geçiş)
  

Hizmet geçiş rolü, Operasyonel süreçte kullanılmak üzere iş gerekliliklerini iletir.

Hizmet geçişi, Servis tasarım aşamasından Hizmet tasarım paketini alması ile başlar ve Operasyonel aşamaya devam eden operasyon ve hizmet desteği için gerekli tüm bilgileri ve elemanaları teslim eder.

İş Koşulları, gereksinimleri yada varsayımlar tasarım sürecinden sonra değişime uğradıysa, Hizmet geçiş aşamasında gerekli hizmeti sunmak için bir takım değişiklikler gerekebilir. Unutulmaması gereken en önemli nokta Hizmet Geçişi sadece uygulamalarla ve/veya normal şartlar altında nasıl kullanıldığı ile değil hizmetlerin tüm yönleri ile uygulanmasından sorumludur.

Süreç içerisinde bilinmesi gereken V-Model yapısını ve RFC,CI,CMS,CAB,ECAB gibi tanımları ve içeriği hakkındaki detayları, süreci daha derin incelediğimiz makalenin içinde bulabilirsiniz..

Süreçler;

• Change Management : Değişiklik Yönetimi, ilgili değişikliklerin değerlendirilmesi, kayıt edilmesi, önceliklendirilmesi, planlanması, test edilmesi, uygulanması, dökümante edilmesi ve düzenli şekilde gözden geçirilmesini sağlar.
  

Bir Hizmet değişikliği, ek, yetki , planlama yada desteklenen hizmet yada hizmet bileşeni gibi üzerinde olabilecek değişiklik ve ilgili dökümanlarla ilişkilendirilmesidir.

• Service Asset and Configuration Management (SACM) : Bir Organizasyonun altyapısını oluşturan ilişkileri, tüm varlıkların kontrolünü ve bilgilerin doğruluğunu sağlar. Yapılandırma öğeleri (Configuration Item(CI)) ve hizmet varlıkları’nın belirlenmesi, kontrol edilmesi ve hesaplanması ile birlikte Servis yaşam döngüsü boyunca kendi bütünlüğünü sağlamayı ve korumayı amaç edinir.
  
• Knowledge Management : Bilgi Yönetimi, işin gerektirdiği hizmet desteğini, doğru kişiye doğru bilgi ile doğru zamanda iletmekten sorumludur.
  

Roller ve Sorumluluklar;

Bir Organizasyon içerisinde hizmete geçiş sunan personel; etkin, verimli ve va olan çeşitli seçenekleri sunmak için organize edilmelidir.

Tipik bir organizasyon içerisinde bu roller tahmin ile değil ayrı bir grup olarak düşünülür. Bu Daha fazla beceriye ve deneyime sahip Aynı insanlar Birden fazla yaşam döngüsü aşamalarına dahil olabilir anlamına gelir.

• Service Operation (Hizmet Operasyon)
  

Hizmet Operasyonu, Kullanıcılarına ve Müşterilerine belirlenmiş hizmet seviyesini sağlayacak olan uygulama yönetimi, teknoloji ve altyapı hizmet desteği sunar.

Bu hizmetler sadece servis yaşam döngüsünün bu aşamasında işe gerçek değerini verir. Hizmet yaşam döngüsü, Hizmet operasyonu aşamasında, kabul edilen parametreler dahilinde faaliyet sağlamakla ilgilenir. Herhangi bir hizmet kesintisi meydana geldiğinde, Servis operasyonu olabildiğince çabuk şekilde servisleri geri yüklüyerek iş etkisini en aza indirgiyor.

Bu sürecin fokus olduğu birtakım parametreler olan “Reactive-Proactive”, “Internal-External”, “Cost-Quality”, “Stability- Flexibility” arasında denge sağlamak durumundadır. Eğer bu dengeyi kuramazsa Hizmet Operasyonu kötü olarak görünüyor olucaktır.

En önemli kısımlardan biri ise operasyon esnasında olan iletişim dir ver her ne olursa olsun iletişimin doğru algılanması kurulması gerekir. Bu ilişkiler;

• BT Hizmet sağlayıcı ile kullanıcı arasındaki iletişim..
• BT Hizmet sağlayıcı ile Müşteri arasındaki iletişim..
• BT Hizmet sağlayıcı içerisinde yer alan farklı süreçler, fonksiyonlar ve takımlar arasındaki iletişim..
• BT Hizmet sağlayıcı ile tedarikçileri arasındaki iletişim..

Süreçler;

• Incident Management : Sorun Yönetimi, olası herhangi bir sorunun bildirilmesi ile gelen isteğin işe etkisinin en aza indirgenmesi noktasında Çoğunlukla servislerin hızlı şekilde restorasyonu sağlar. Fakat bazı vakalardan durum sorun yönetiminden çıkarak yardım masası tarafından sahiplenilir ve uygulanır.

Temel aktiviteler;

• Detection
• Logging
• Classification
• Prioritization
• Investigation and Initial Diagnosis
• Escalation
• Resolution and Recovery
• Closure

• Problem Management : Problem yönetimi,Vaka’ya sebep olan oluşumun içerisindeki hata yada kusuru düzeltmek ve tanımlamak ile ilgilenir. Sorunların azalmasına ve engellenmesini yardımcı olur ve iki alt süreçten oluşur;
  • Reactive Problem Management : Genellikle Sorun yönetimi süreci tarafından yönlendirilen problemlerin aşılması sürecidir.
  • Proactive Problem Management : Hata-Sorun isteği gelmeden önce servisler ve altyapı üzerinde Proaktif olarak iyileştirme aramaları yapan süreçtir.
    
• Event Management : Olay Yönetimi, Altyapı üzerinde oluşan olayların tespiti ve uygun müdahale eylemlerinin seçimi ile ilgilenir. Olayların erken tespit ediliyor olması, etkilenen kullanıcılar tarafından gelecek hata sayılarının düşmesine neden olacağı gibi, Sorun yönetimi sürecinin performansını artırarak olayların azalıtması sağlanmış olur. 3 Tip olay vardır;
  • Informational
  • Warning
  • Exception
• Access Management : Erişim Yönetimi kimlik ve haklar ile ilgilenir. Bu süreç kimlik ve yetki doğrulama, hizmetlere erişim verme, işlem günlüğü, erişim izleme-kaldırma yada durum veya rollerin haklarını değiştirmeyi içerir.

Erişim Yönetimi, gizlilik, kullanılabilirlik ve veri bütünlüğünü yönetmenize yardımcı olur. Yetkili olmayan kullanıcıların erişimlerini engellerken, erişim yetkisi olan kullanıcıların bir servise yada servis grubuna erişimini sağlar.

• Service Request Fulfillment : Hata yönetimine ddahil edilemiyecek ortak kullanıcı istekleri olarak adlandırılmaktadır. Yeni bir ekipman yada bir eğitim isteği bu başlığın altında değerlendirilir. Özellikle belirli periyotlarda kullanıcılar tarafından yapılmakta olan bir isteğin cevaplandırılması için idealdir.

Bütün istekler kayıt edilmeli ve izlenilmelidir. Bu süreç içerisinde aynı zamanda dikkat edilmesi gereken en önemli konu ise isteğin cevaplanmadan önce onay sürecine sokulmasıdır.

• Continual Service Improvement (Hizmet İyileştirme Sürekliliği)
  

Değişen iş ihtiyaçlarına göre fonksiyonların, süreçlerin ve hizmetlerin yeniden uyumlu hale getirilmesi sürecidir. Aynı zamanda Genel Hizmet yönetimi içerisindeki kalite yönetim yöntemleri uygulama tutarlığı ile ilgilenir.

ITIL içerisinde “Ölçü (Measurement)” kritik bir rol almaktadır. Hizmet iyileştirme sürekliliğinin bi parçası, aynı zamanda Hizmet seviyesi Yönetiminin ve tüm süreçlerin önemli bir parçasıdır. Ölçümleri burada 4 temel amaç için kullanılabilir;

• Doğrulamak (Justify)
• Direkt (Direct)
• Müdahale (Intervenne)
• Onaylamak (Validate)

(Bir sonraki makalemiz içerisinde metodlarından bahesediyor ve ölçümlemedeki kritik noktalardan bahsediyor olacağız.)

7 adımda iyileştirme süreci ölçümleme ile Hizmet performansının düzeltilmesi ve iyileştirilmesini sağlıyor. İsterseniz kısaca bu adımların ne olduğuna bakıyor olalım;

• Karar à Ne Ölçülmelidir
• Karar à Ne Ölçülebilir
• Veri Toplama
• Veri İşleme
• Veri Analizi
• Veri Kullanma ve sunma
• Düzeltici Eylem (Aksiyon) uygulama

Hizmet Seviyesi Yönetimi (SLM) aynı zamanda Servis Tasarım yaşam döngüsü aşamasının içerisindeki süreçlerden birisidir. Bir çok aktivite ve nesne Hizmet iyileştirme sürekliliği ile ortaktır. Özellikle her iki Hizmet seviyesi yönetimi ve iyileştirme sürekliliği düzenli ölçüm, servislerin gözden geçirilmesini ve servis yönetim başarımının diğer yönlerini vurgulamaktadır.

Service Improvement Program (SIP); Hizmet İyileştirme Planı yada Hizmet İyileştirme Programı, Hizmet iyileştirme sürekliliğinin bir parçası olarak yada Hizmet seviyesi yönetimi sürecinin bir parçası olarak yürütülen periyodik hizmet değerlendirmesinin birincil çıktısıdır.

ITIL yapısını oluşturan herbir parça birbiri ile grift ilişki halindedir ve süreçlerin iç içe geçtiği birçok noktada genel yorum kullanmamız gerekir. Bu yazımızda olabildiğince detaylara girmeden Ana hatları ile bir resim çizmeye çalıştım. Bundan sonraki yazılarımız içerisinde spesifik bir konu ve detayları üzerinde durarak ilerliyor olacağız. Bilgilerin yararlı olduğunu umut ediyorum.

Bu konuyla ilgili sorularınızı http://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

http://www.best-management-practice.com

http://wiki.en.it-processmaps.com

An SRS is written in precise, clear and plain language so that it can be reviewed by a business analyst or customer representative with minimal technical expertise. However it also contains analytical models (use case diagrams, entity relationship diagrams, data dictionary etc.) which can be used for the detailed design and the development of the software system. SRS is one of the most critical pieces of software development since it acts as the bridge betweens the software developers and business analysts. An incomplete or incorrect SRS can have disastrous effects on a software project.

In this article I explain the major sections of a typical Software Requirement Specification document. I also provide a generic SRS template which can be customized for your project needs.

What is the need for an SRS document?

Software Requirements Specification is usually the first deliverable for any software project. As they say, first impression is the best impression!, and you should ensure that even the first draft of an SRS is of high quality.

The benefits of a good SRS are,

• A contract between the customer and the software vendor – A good SRS document specifies all the features required in the final system including technical requirements and interface requirements. SRS document is used by the customer to determine whether the software vendor has provided all the features in the delivered software system. To the Software vendor it provides a solid foundation to fix the scope of the software system.
• Enables costing and pricing of the project – A well defined SRS enables software developers to accurately estimate the amount of effort required to build the software product. Function point analysis and SMC are some the techniques adopted for estimating effort.
• Input for detailed design – A good SRS enables experienced developers to convert the requirements directly to a technical design. For example, a well defined data dictionary can be easily converted to a database specification.
• Management of customer expectations – Since SRS precisely defines project scope, it ensures that customer expectations don’t change during software development. If they do, SRS can be modified and costing/pricing can be done again on the changes required.

What are the contents of an effective SRS document?

There is no single precise template for writing good Software Requirement Specifications. The contents of an SRS document depends on the software product being developed and also on the expertise of the people doing the requirement elicitation. Different business/technology domains in a company usually have their own customized version of SRS template. Still a good Software Requirement Specification (SRS) usually contains project scope section, functional requirements, requirement analysis models, external interface requirements and non functional requirements. Each of these are explained below.

Scope of the project/ Product vision

One of the most important items in the requirements specification is the precise scope definition of the project. Accuracy of this is important since SRS is also used for estimation and costing. This section should include a brief overview of the project and should also indicate the goals of the project including its benefits. Sometimes it is better to separate the project scope into a separate document.

If the project is for the development of a product, product vision defines the scope and the target user base of the product.

Functional Requirements

Functional requirements specify the business requirements of the project in detail. Usually business requirements are specified in terms of the actions that user performs on the software system. This is known as the use case model. But not all requirements need to be specified as use cases. Functional requirements should contain a combination of use cases and plain textual description of system features. System features are specified at a higher level and use cases attempt to translate into user actions.

Again there is no fixed format for use case description, but it usually contains the following information,

• Use case diagram – For a small systems, a single diagram can be used to depict all the use cases in the system.
• List of actors and their details – This identifies the various types of users interacting with the software system.
• Use case description – Purpose of the use case and how and when it is invoked by the user. This should also include an identifier for easy reference.
• Preconditions – List of system states/conditions that must be true for the successful execution of the use case. This section is optional and could be easily incorporated into the basic steps section.
• Basic steps – These indicates the various fine grained steps required for the execution of the use case.
• Alternate steps – These indicate alternate events of the use case being described.
• Business validations/rules – These indicates various types of input validations or business rules required in the use case being described.
• Post conditions – Indicates the results of the use case. Please note that this section is optional and could be incorporated into the basic steps section.

To ensure that all the business requirements are addressed in the final software product, a traceability matrix document is used. Traceability matrix tracks each requirement through various phases of software development (detailed design, unit test plans, system testing plans, user acceptance test plans and code components). This requires that every requirement in the SRS should be identifiable by a unique number or tag.

For software projects where majority of features are available as user interfaces, it is better to complement this section with screen prototypes. These user interfaces can change during detailed design, but having a draft version of user interface in the requirements document helps a lot in communicating business requirements. However some customers insist on having finalized user interfaces in the requirements specification document.

Requirement Analysis Models

Once the overall use cases in the system are identified in requirements elicitation, requirement analysis models can be developed to drill down to specifics of each requirement. For example, a use case such as “Add customer” may not specify all the customer details that needs to be captured by the system. This is usually specified in the data dictionary model and also in the screen prototype.

Requirement Analysis models act as the bridge between functional requirements and the detailed design of the software system. For example, Use cases lead to user interface design, data dictionary and entity relationship diagrams are used for designing database schema and class diagrams.

Following are some of the widely used requirement analysis models,

Entity Relationship Diagrams

Entity relationship model diagram (ERD) is a conceptual representation of the data in a software system. During detail design this model is mapped in to the physical database model. There are different diagramming conventions available for creating ER diagrams. Following is a sample ERD in Crow’s foot notation (this is taken from the ERD of a course registration Web application requirements),

This diagram indicates that there is one and only one instructor for a course and an instructor can have one or more courses. The relationship is captured as instructor “teaches” course.

Data Dictionary

Data dictionary in a requirements document is an extension of the entity relationship diagrams. Which ER diagrams specify system entities and their relationships, a data dictionary lists all the attributes pertaining to each of those entities.

In a data dictionary, each attribute of the entity data in system is analyzed in detail including type of attribute, whether it is optional and a brief description of the attribute. Please see the sample SRS template section for more details.

In addition to the above models, sometimes it is useful to develop state transition diagrams and data flow diagrams. To describe a complex process flow or a workflow in the application, process flow diagrams or flowcharts can be used.

External Interface Requirements

It is very rare that we have a standalone software system. Usually a software system interacts with a number of external applications for data input and output. For example, an e-business application usually needs to be integrated to an external payment gateway. All the external interface requirements are detailed in this section. The important thing to document here are the entities that are passed across the external interfaces.

Non Functional Requirements

Non functional or technical requirements specify how the software system should operate. In contrast functional requirements specify what a software system should do. Some of the non functional requirements are derived from the functional requirements. Non functional requirements captured include performance requirements, application scalability, application security, maintainability, usability, availability, logging and auditing, data migration requirements, multi lingual support etc. Please note that only a subset of the list are applicable for a specific project.

Importance of a good SRS template

A good SRS template ensures that all important information required in a Software Requirement Specification is captured during requirement elicitation. Following is the table of contents taken from the SRS template linked below.

Contents of Software Requirements Specification (SRS) Template

Download Sample SRS template

Click here to download a generic software requirement specification template. Please note that this SRS template is written in open office RTF format(A PDF version is available here). Not all sections are mandatory and you can easily customize this template for your project requirements.

• Download SRS template in Open Office format
• Download SRS template in PDF format
• Download SRS template in Microsoft Office format

Further Reading / References

• Crow’s foot notation for ER diagrams

Recommended Books

• Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle. – This is an excellent book on requirements gathering. It also covers all the major requirements modeling techniques. Appendix of this book contains a number of good requirements document samples including vision and scope document, use cases and business rules. Highly recommended.
• Writing Effective Use Cases – This is an excellent book that can help you in mastering the art of writing effective use cases. Written by Alistair Cockburn almost a decade ago this is a must have book for a business analyst. It will help you in steering clear of a lot of mistakes during use case preparation.

Final Thought

Always remember that the primary purpose of an SRS document is to ensure proper communication between people involved in the development of a software product. So the SRS template acts just as a guideline and you can add any additional information that helps this communication.

Source : www.jaysonjc.com

There is a better way, the secure version of HTTP — HTTPS. That extra “S” in the URL means your connection is secure, and it’s much harder for anyone else to see what you’re doing. But if HTTPS is more secure, why doesn’t the entire web use it?

HTTPS has been around nearly as long as the web, but it’s primarily used by sites that handle money — your bank’s website or shopping carts that capture credit card data. Even many sites that do use HTTPS use it only for the portions of their websites that need it — like shopping carts or account pages.

Web security got a shot in the arm last year when the FireSheep network-sniffing tool made it easy for anyone to detect your login info over insecure networks — your local coffeeshop’s hotspot or public Wi-Fi at the library. That prompted a number of large sites to begin offering encrypted versions of their services on HTTPS connections.

Lately even sites like Twitter (which has almost entirely public data anyway) are nevertheless offering HTTPS connections. You might not mind anyone sniffing and reading your Twitter messages en route to the server, but most people don’t want someone also reading their username and password info. That’s why Twitter recently announced a new option to force HTTPS connections (note that Twitter’s HTTPS option only works with a desktop browser, not the mobile site, which still requires manually entering the HTTPS address).

Google has even announced it will add HTTPS to many of the company’s APIs. Firefox users can go a step further and use the HTTPS Everywhere add-on to force HTTPS connections to several dozen websites that offer HTTPS, but don’t use it by default.

So, with the web clearly moving toward more HTTPS connections, why not just make everything HTTPS?

That’s the question I put to Yves Lafon, one of the resident experts on HTTP(s) at the W3C. There are some practical issues most web developers are probably aware of, such as the high cost of secure certificates, but obviously that’s not as much of an issue with large web services that have millions of dollars.

The real problem, according to Lafon, is that with HTTPS you lose the ability to cache. “Not really an issue when servers and clients are in the same region (meaning continent),” writes Lafon in an e-mail to Webmonkey, “but people in Australia (for example) love when something can be cached and served without a huge response time.”

Lafon also notes that there’s another small performance hit when using HTTPS, since “the SSL initial key exchange adds to the latency.” In other words, a purely security-focused, HTTPS-only web would, with today’s technology, be slower.

For sites that don’t have any reason to encrypt anything — in other words, you never log in, so there’s nothing to protect — the overhead and loss of caching that comes with HTTPS just doesn’t make sense. However, for big sites like Facebook, Google Apps or Twitter, many users might be willing to take the slight performance hit in exchange for a more-secure connection. And the fact that more and more websites are adding support of HTTPS shows that users do value security over speed, so long as the speed difference is minimal.

Another problem with running an HTTPS site is the cost of operations. “Although servers are faster, and implementations of SSL more optimized, it still costs more than doing plain HTTP,” writes Lafon. While less of a concern for smaller sites with little traffic, HTTPS can add up, if your site suddenly becomes popular.

Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn’t work with virtual hosts. Virtual hosts, which are what the most common cheap web-hosting providers offer, allow the web host to serve multiple websites from the same physical server — hundreds of websites all with the same IP address. That works just fine with regular HTTP connections, but it doesn’t work at all with HTTPS.

There is a way to make virtual hosting and HTTPS work together — the TLS Extensions protocol — but Lafon notes that, so far, it’s only partially implemented. Of course that’s not an issue for big sites, which often have entire server farms behind them. But until that spec — or something similar — is widely used, HTTPS isn’t going to work for small, virtually hosted websites.

In the end there is no real reason the whole web couldn’t use HTTPS. There are practical reasons why it isn’t happening today, but eventually the practical hurdles will fall away. Broadband speeds will improve, which will make caching less of a concern, and improved servers will be further optimized for secure connections.

In the web of the future the main concern won’t just be how fast a site loads, but how well it safeguards you and protects your data once it does load.

TOGAF has been developed and continuously evolved since the mid-90’s by representatives of some of the world’s leading IT customer and vendor organizations, working in The Open Group’s Architecture Forum. Details of the Forum, and its plans for evolving TOGAF in the current year, are given on the Architecture Forum web site.

About TOGAF Version 9 Enterprise Edition

TOGAF Version 9 Enterprise Edition (“TOGAF 9″ for short) is a detailed method and set of supporting resources for developing an Enterprise Architecture. Developed and endorsed by the membership of The Open Group’s Architecture Forum, TOGAF 9 represents an industry consensus framework and method for Enterprise Architecture that is available for use internally by any organization around the world – members and non-members of The Open Group alike – subject to license conditions – see Downloading TOGAF 9

As a comprehensive, open method for Enterprise Architecture, TOGAF 9 complements, and can be used in conjunction with, other frameworks that are more focused on specific aspects of architecture or for vertical sectors such as Government, Defense, and Finance.

http://www.bestoldgames.net/eng

Oyunlar Dos tabanlı olduğu için Windows 98 harici işletim sistemlerinde çalıştırabilmek için DosBox kullanmanız gerekiyor.

Kısaca SOA, bileşenlerin iletişim ve yönetimine odaklanır. Fakat POA bu bileşenlerin nasıl kullanılacağına ve nasıl kullanışlı hale geleceğine odaklanır.

SÜREÇ ODAKLI MİMARİ’NİN FAYDALARI

1. POA, SOA’nın üzerine kurulmuştur. Dolayısıyla, yüksek düzeyde entegrasyon, modülarizasyon, yüksek tekrar kullanılabilirlik oranı ve esnek uzantılar gibi SOA’nın faydalarına da sahiptir.
2. Bakımı kolaydır, esnekliği arttırır: Süreçler, diyagramlar kullanılarak ifade edilebildiği için, değişiklikler sadece sürükle-bırak özelliği ile yapılabilmektedir.
3. Hızlı oluşturma: BPM(Business Process Management) sisteminin desteğine sahip POA, sadece bir kavram ve protokollerden ibaret olan SOA’dan farklıdır. Mevcut BPM sistemi kullanılarak, bir POA sistemi kolaylıkla kurulabilir.

Yazılım sistem geliştirme tarihçesine bakıldığında, sistemler karmaşıklaştıkça, insanlar temel bileşenleri arttırmanın yollarını aramaya başladılar. Böylece, yazılımdaki satırlar prosedürlere ve nesnelere dönüştü. Bugün, servisler sistem tasarımını basitleştirecek temel bileşenler olarak görülüyor. Servise bağlı protokoller standartlaştıkça,  “İnternet Etkisi” ile daha çok servis ortaya çıktı ve sistem oluşturma süreci her seferinde sıfırdan başlatılmadı. Daha çok, mevcut olan servislerin üzerine yenileri inşa edilerek, artı yönde bir döngü başladı.

21. yüzyıl BPM sistemi, işletmelere daha hızlı olma imkanı vermeli, insanları, süreçleri ve bilgiyi etkili bir biçimde birbirine bağlamalı ve sürekli değişen iş çevresine karşı firmanın daha hızlı aksiyon alabilmesine imkan vermelidir.

Dolayısıyla, yakın gelecekte sistem geliştirme birçok farklı servisin entegrasyonuna odaklanacak; bu nedenle de POA (Süreç Odaklı Mimari) en iyi çözüm olacaktır.

Kaynak: ABAS Türkiye

Dipnot

Pierre Loti Tepesi, İstanbul‘un Eyüp ilçesinde Haliç‘e nazır bir tepedir. Tepe adını, 1876 yılında İstanbul‘a gelerek buraya yerleşen ve sık sık bu tepedeki bir kıraathaneye gelmesiyle tanınan Fransız roman yazarı ve doğubilimci Julien Viaud‘dan almıştır. Tepenin adını Eyüpsultan Tepesi olarak değiştirmek amacıyla belediye meclisine sunulan öneri pek çok çevreden büyük itirazlar görmüş ve belediye meclisince reddedilmiştir. Tepe ve burada bulunan aynı adlı çay bahçesi İstanbul’a gelen turistlerin de sık sık ziyaret ettiği bir yerdir.

Bu yaklaşım doğrudur; çünkü birincisi CRM yazılımını satın alma kararını üst yönetim verir. İkincisi firmanın satış, pazarlama ve servis faaliyetlerinin nasıl olması gerektiğini yani CRM stratejisini yine üst yönetim belirler. Ancak üst yönetim satış, pazarlama ve servis elemanlarından bağımsız olarak bir CRM yazılımına karar verip bu yazılımı çalışanlarının kullanacağını düşünüyorsa, yanılıyordur. Çalışanlar, CRM yazılımına bilgi girmeyi bir angarya gibi görmeye başlayabilirler. Özellikle Türkiye’de çalışanlar CRM yazılımını kullanmamak, bilgi girmemek için bahaneler bulabiliyorlar. Satış elemanınıza müşteri ziyaretlerini, gönderilen e-mailleri, telefon konuşmalarını, verdiği fiyat tekliflerini, satış tahminlerini CRM yazılımına kayıt etmesini istediğinizde “Onca işimi gücümü bırakıp bir de CRM’e bilgi mi gireceğim? ” yanıtını alabilirsiniz. Yönetici olarak onun bu tavrını hoş karşılıyorsanız CRM yazılımını çöpe atabilirsiniz. Başka bir çözüm de o satış elemanınızı işten çıkarmanız olabilir! Aslında çalışanların bu direncinin mantıklı bir sebebi vardır. Eğer yaptığınız işleri CRM yazılımına tam anlamıyla kayıt ederseniz ne kadar az iş yaptığınız ortaya çıkacağından bunu da yönetimin bilmesini istemediğinizden bu doğaldır. Bu nedenlerden dolayı şirket üst yönetiminin sadece CRM yazılımı satın alınma kararında değil, uygulanması, sürekliliği ve kontrolü için CRM yazılımı kullanımının her bölümde bir alışkanlık haline gelene dek kontrol etmesi bir gerekliliktir.

Müşteri Kraldır

Asıl kral benim! Yani CRM çözümünü tüm birimlerinde uygulayan ve CRM yazılımı satın alıp kullanan firma. Müşteri kraldır yaklaşımının olabilmesi için benim ona sunduğum ürün ve hizmet kalitesinin de öyle olması gerekir. Ben kendi satış ekibimin hangi müşteriyle ne zaman konuştuğunu, hangi teklifleri verdiğini, rakip firmaların benim karşımdaki durumunu takip edemez isem, geleceğe yönelik planlama yapamam ve  stratejileri oluşturamam demektir. Yine servis verdiğim müşterilerde servis verdiğim ürünlerle ilgili olarak ne zaman hangi problem çıkmış, nasıl çözülmüş, çözüm süresi müşterimin işleyişini durduracak kritik bir duruma neden olmuş mu, bir daha aynı problemin yaşanmaması için neler yapılmış göremiyor, servis elemanımı, ürünümü ve ürünü kullanan müşteriyi değerlendiremiyor isem, müşteriye iyi hizmet sunmam mümkün değildir. Satış veya servis hizmetini ölçemeyen, değerlendiremeyen ve raporlayamayan bir firmanın müşterisini memnun edebilmesi ve kral konumuna yerleştirmesi ve müşteriyle uzun süreli ilişki kurarak yeni ürün veya servis satabilmesi mümkün değildir.

CRM Bir Ürün Değil Felsefedir

CRM bir felsefedir yaklaşımı, CRM satın almayı düşünen firmalar için fantezi olarak algılanabilir. Bana felsefe değil satış gerek diyerek bu işin içinden sıyrılabilirsiniz. Ancak CRM bir felsefedir yaklaşımı kesinlikle doğru bir yaklaşımdır. Hangi CRM yazılımını satın almış olursanız olun sattığınız veya hizmet verdiğiniz ürün ya da hizmetinizle ilgili bir satış, pazarlama ve servis anlayışınız yoksa, bir gün öyle bir gün böyle davranma eğiliminiz varsa, CRM yazılımını bazen kullanıp bazen kullanmıyorsanız CRM uygulamasında başarılı olma şansınız yoktur.

Firmalar şunu bilmelidirler; CRM yazılımı CRM gerçekleştirmeniz için bir araçtır. O aracı nasıl kullanacağınız tamamen size kalmıştır. Eğer CRM yazılımına karar vermeden önce bir çalışma anlayışınız yoksa ve bu belli kurallara, prosedürlere bağlanmamışsa CRM yazılımı almanıza ve paranızı boşa harcamanıza gerek yoktur.

Ben işimi CRM yazılımına entegre mi edeceğim, yoksa yazılım mı benim işime göre düzenlenecek? Bu soru önemlidir. Üst yönetim, CRM kullanacak birimler ve Bilgi Teknoloji uzmanlarının birlikte karar vermesi gerekir. Kendi iş yapış biçiminiz ve kurallarınız belirliyse, geriye sadece bu iş yapış biçiminize uygun CRM çözümünü entegre etmek kalır.

Sonuç

CRM bir felsefedir. CRM yazılımı ise CRM felsefesini uygulamamız için bir araçtır. CRM uygulaması satın almadan önce yaptığınız iş ile ilgili olarak satış, pazarlama ve servis hizmetlerinizin nasıl çalışması gerektiğini ve onlardan neler beklediğinize dair bir anlayışınız, prosedürünüz ve yazılı kurallarınız olmalıdır.

CRM çözümü ve yazılımı sayesinde firmalar yaptığı işi; satış, servis ve destek hizmetlerini birbirine entegre, kontrol edilebilir, izlenebilir standart ve raporlanabilir bir hale getirebilirler. CRM çözümünü uygulayarak öncelikli olarak yaptıkları işi doğru yapıp yapamadıklarını, elemanlarını ve birimlerinin doğru çalışıp çalışmadığını anlayabilirler.

Bu sayede aksayan bölüm, birim ya da kişileri belirleyerek, aksamaması için tedbir alabilir, müşterilere verdikleri ürün ve hizmeti daha iyi hale getirebilirler.

CRM , müşterilerime verdiğim ürün ve hizmet kalitesini arttırıp uzun süreli, verimli ilişkiler kurarak var olan müşterilerimi korumayı, yeni müşteriler bulmayı ve şirket karlılığımı arttırmamı sağlayacaktır.

Kaynak: ABAS Türkiye