2 Analiz ve Kavram Kanıtlama¶
Her ÖY/AKK göç projesinin ikinci basamağı Analiz aşamasıdır. Analiz aşamasında genel olarak;
- Kurumsal envanterin oluşturulması
- Sunucu envanteri,
- Yazılım envanteri,
- Donanım envanteri.
- Kullanıcı gruplarının ve iş ihtiyaçlarının değerlendirilmesi,
- Personel rol matrisinin oluşturulması,
- İşlevsel eşdeğerlik çalışması aşamaları bulunmaktadır.
- Güncel Pardus işletim sistemi üzerinde kullanılacak hizmetlerin belirlenmesi,
- Kavram kanıtlama çalışmasına esas servislerin/uygulamaların belirlenmesi,
- Kavramsal topolojinin oluşturulması
faaliyetleri yapılır. Analiz aşaması için kullanılabilecek doküman şablonu EK - A ‘da sunulmaktadır.
Analiz aşaması, kurumun kullandığı bilgi işlem altyapısının bir özetidir. Bu aşamada yapılacak hatalı değerlendirmelerin projenin ileri aşamalarında ek maliyet, işgücü getireceği dolayısıyla da proje sürelerinin uzamasına hatta dönüşüm projesinin başarısız olmasına yol açabilecektir. Bu yüzden analiz aşamasında yapılacak değerlendirmeler objektif olmalıdır.
Kavram Kanıtlama, analiz aşamasında belirlenen iş ihtiyaçlarına yönelik olarak sadece ilgili özelliklerin ÖY/ AKKY ile yapılabilirliğinin gösterilmesidir. Bu kısım sonraki bölümlerde ayrıntılı olarak açıklanmaktadır.
2.1 Analiz¶
Analiz çalışması, dönüşüm projesinin en önemli aşamasıdır. Bu aşama, kurumsal dönüşüm sürecini belirleyeceği gibi, kurumsal bilgi varlıkları envanterini değerlendirerek, gelecek planlamalarının yapılmasına yardımcı olmaktadır. Analiz aşamasında kurumsal bilgi işlem varlıklarının o anki durumunun tespiti yapılır. Analiz aşamasının temel girdileri aşağıdaki gibidir:
- Sunucu, yazılım ve donanım envanterleri,
- Kurumsal ağ ve sistem topolojileridir.
Örnek kurumsal sistem topolojisi aşağıda gösterilmiştir:
Şekil: Örnek Kurumsal Sistem Topolojisi
Analiz aşamasının temel çıktıları aşağıdaki gibidir:
- Donanım envanteri ve uyumluluk tabloları
- Kullanıcı grupları ve iş ihtiyaçları
- İşlevsel eşdeğerlik uygulama tablosu
- Masaüstü programları analizi
- Hizmet ve uygulama analizi
- Dönüşüm başarı kriterleri
Analiz çalışması, ÖY/AKK dönüşüm projesinin en önemli kısmıdır. Bu aşamadaki hatalar tüm projenin başarısızlığa uğramasına yol açabilir. Gerçekçi bir analiz ve iyi bir planlama ile imkânsız gibi görünen dönüşüm projeleri, başarıyla gerçekleştirilebilir. Analiz aşamasının başarılı olmasında en önemli kriter, yapılacak çalışmanın hedefini analiz çalışmasına katılan kişilere doğru anlatılmasından geçmektedir. Çalışanlar, genellikle değişimden yana değillerdir. Yeni bir yapıya geçmek, onu öğrenmek zorunda olmak onlara yük olarak görülebilir. Ancak hedefe inanırlarsa, o zaman çok destekleyici olurlar ve olası problem çözümü için çaba gösterirler. Bu sinerji, projeyi başarıya götürür.
2.1.1 Donanım Envanterinin Belirlenmesi¶
Kurumsal olarak kullanılan donanım varlıklarının, ÖY/AKK işletim sistemlerine uyumluluğu en çok sorulan ve korkulan konuların başında gelmektedir. Bugün geldiğimiz noktada, Linux işletim sistemi kullanıcılarının sayısının artması, donanım üreticilerini Linux uyumlu sürücü yazmaya yöneltmiştir. Ayrıca topluluk içerisindeki gönüllü geliştiricilerin çalışmaları ve oluşturdukları kütüphaneler sayesinde de çalışmalar ilerlemiştir. Yine de, özel amaçla geliştirilmiş ve yaygın kullanımı olmayan bazı donanımların ya da ekonomik ömrünü doldurmuş olan eski donanımların sürücüleri olmayabilir. Bu donanımlar için sürücü geliştirme maliyetleri ya da destekleniyorsa yeni donanım maliyeti hesaplanmalı ve fiyat/performans olarak en uygun çözüm değerlendirilmelidir.
Donanım envanteri; kurumda kullanılan masaüstü, dizüstü, yazıcı, tarayıcı, barkod okuyucu vb. dönüşüm kapsamındaki tüm cihazları kapsamalıdır. Bunların tam listesi belirlendikten sonra, kurum içerisindeki proje ekibi ile, bu donanımların hangilerinin ekonomik ömrünün doldurduğuna karar verilmelidir. Belirli bir donanım, sadece kısıtlı sayıdaki kullanıcı için belirli dönemlerde kullanılıyor olabileceğinden, donanım envanteri çıkarılırken kurum içerisindeki kullanım yaygınlığı ve sıklığı belirlenmelidir.
Dönüşüm teknik ekibinin, bu donanımların Linux üzerinde desteğinin olup olmadığına karar vermesi, desteği varsa hangi sürümdeki sürücülerle bunun mümkün olduğunu çıkartması ve varsa ürünlerin teknik dokümanlarının adreslerini de envanter listesine eklemesi uygun olacaktır. İstemciler ve çevre birimleri için yararlanılabilecek örnek formlar EK - B ’de bulunabilir
2.1.2 Sunucu Envanterinin Belirlenmesi¶
Kurum içerisinde, kurumsal işin yapılabilmesi amacıyla kullanılan sunucu sistemlerin listesinin çıkarılması işlemidir. Listede sunucular üzerindeki hizmetler de ayrıca belirtilmelidir. Örnek sunucu envanteri aşağıdaki şekilde olabilir.
| Birim | Sunucu Adı | Rolü | İşletim Sistemi | Sürüm | Uygulama Adı | Etki Alanı Bilgisi |
|---|---|---|---|---|---|---|
| Bilgi İşlem | Ankara | DNS,DHCP | Windows | 2012 | DNS DHCP | aaa.org |
| A Birimi | İzmir | VTYS | Windows | 2008 | SQL Server | bbb.org |
2.1.3 Yazılım Envanterinin Belirlenmesi¶
Yazılım envanter yönetiminin yapılabilmesi için öncelikle kurumsal işin sürdürülebilmesi amacıyla kullanılan yazılımlar belirlenmeli, bu yazılımlara ait sürüm numaraları, kullanıcı sayıları ve ne zaman envantere girdiği gibi bilgiler toplanmalıdır. Yazılım envanterinin oluşturulması ile yazılımların uyumluluğunu takip etmek ve lisanslama vb. gibi süreçlerinin yönetilmesi daha etkin şekilde gerçekleştirilebilecektir. Örnek yazılım envanteri aşağıda sunulmuştur:
| Birim | Üretici Firma | Uygulama Adı | Sürüm | Kullanıcı Sayısı | Envanter Tarihi | Linux Uyumu | Lisans Türü / Bitiş Tarihi |
|---|---|---|---|---|---|---|---|
| Bilgi İşlem | AutoDesk | AutoCAD Architecture | 0.1.1 | 20 | dd.mm.yy | Yok | Ticari 2 Kullanıcı |
| A Birimi | Skype | Microsoft | 3.1.1 | 80 | dd.mm.yy | Var | Ücretsiz |
Donanım, sunucu ve yazılım envanterleri tamamlandığında kurumdaki masaüstü bilgisayarlardaki işletim sistemleri ile ilgili değerlendirmelere geçilir.
2.1.4 Kullanılan Masaüstü Ortamının Değerlendirilmesi¶
Bir ÖY/AKKY’a ve masaüstü ortamına geçiş süreci başlamadan önce, kurumsal olarak kullanılan yazılım/donanım ve diğer bilgi işlem varlıklarının tespit edilmesi gerekmektedir. Bir kere donanım ve yazılım envanteri çıkarıldığında, kurumsal olarak işin yapılması amacı ile kullanıcıların bu varlıkları nasıl ve hangi özelliklerinin kullanıldığı belirlenmelidir.
2.1.5 Kullanıcı Gruplarının Belirlenmesi¶
Kullanıcı bölümlendirmesi, genel olarak birebir görüşmeler veya anket metodları ile ortaya çıkarılabileceği gibi; görev tanım formları, iş akış süreçleri analiz formları gibi kalite belgelerinden de çıkarılabilir. Burada amaç, kullanıcıların görev tanımında yazan işi yapabilmesi için gerekli uygulamaları tanımak ve buna göre kategorilere ayırmaktır. Kullanıcı grupları belirlenirken gerek duyulması halinde aşağıda verilen gruplamaların dışına da çıkılabilir.
2.1.5.1 Genel Kullanıcı Tipleri¶
Kurumsal masaüstü kullanıcıları, genel olarak iyi bilinen belirli kategorilere ayrıştırılabilir. Küçük organizasyonlarda, kullanıcılar genel bir kategoriye atanabildiğinden kullanıcı bölümlendirmeye çok ihtiyaç duyulmayabilir. Buna karşılık, büyük organizasyonlarda yüksek derecede uzmanlaşmış personel bulunmakta ve bu kullanıcıların programları da çeşitlilik gösterebilmektedir.
2.1.5.2 Kiosk kullanıcıları¶
Kiosklar, belirli uygulamaları çalıştırabilen basit istemcilerdir. Kiosklarda, bilgi sunumları yapılır, POS cihazları, web tarama ve isteğe göre uyarlanmış uygulamalar çalıştırılır.
2.1.5.3 Temel çalışanlar¶
Temel çalışan profili genel olarak; metin işleme, hesap tablosu, sunum hazırlama gibi ofis uygulamaları, basit e-posta alma gönderme ve web tarayıcısı ile işlemlerini yapar. Temel çalışan profilindeki kullanıcılar özellikli uygulamaları kullanmaz fakat bir takım işlemsel fonksiyonlar yoğunlukla kullanılabilir. Bu kategoriye giren çalışanlar, genel olarak veri kontrol ve hazırlama işletmenleri ile yönetici sekreteryalarıdır.
2.1.5.4 İşlemsel Çalışanlar¶
Genellikle daha önceden belirlenmiş görevleri yapan ve bu görevleri yapmak için belirli yazılım uygulamalarını kullanan kullanıcılardır. Sipariş takibi memurları, yardım masası temsilcileri, sevkiyat ve mal kabul hizmetleri temsilcileri, yardım masası gibi görevdeki personel bu kategoriye girebilir.
2.1.5.5 Teknik Çalışanlar¶
Teknik çalışanlar; yazılım geliştiricileri, CAD/CAM/CAE donanım geliştiriciler, sistem ve ağ yöneticileri özellikli bir takım programlar kullanmaktadır. Aynı zamanda teknik çalışanlar e-posta, web tarayıcısı ve ofis programları da kullanmaktadır.
2.1.5.6 İleri Seviye Bilişim Çalışanları (Teknolojik Liderler)¶
Ofis uygulamalarının özelleştirilmesi gibi programların özelliklerini uzman seviyesinde kullanmaktadır. Bu çalışanların çalıştıkları yerler çeşitlilik göstermekle birlikte, çalıştıkları birimlerde bilgi işlem personeline destek olur ve yerel olarak da birçok problemi giderirler.
2.1.6 İş İhtiyaçları Değerlendirmesi¶
Kurumda tüm çalışanlar aynı işi yapmadığından, iş ihtiyaçları da farklılık gösterecektir. Bu nedenle kurumlarda özellikle ayrı birimleri kendi içerisinde değerlendirmek gerekir.
Seçilen Pardus güncel sürümünde, ihtiyaçlara göre özelleştirme yapmak, kurumsal açıdan bazı avantajları getirir. Bilgi güvenliği kriterleri, kullanıcı ihtiyaçlarının eksiksiz ve hızlı karşılanması, kullanıcı desteğinin daha rahat verilebilmesi için özelleştirmeler önemlidir. Debian Linux tabanlı geliştirilen Pardus İşletim sistemi kurumsal kullanıcıların ihtiyaç duyabilecekleri gerekli yazılım ve donanım desteği ile birlikte sunulmaktadır. İş ihtiyaçları, her birimle ayrı ayrı çalışılarak görev tanımlarına ve kullanılan uygulama setine göre değerlendirilmelidir.
2.1.6.1 Görev Tanımlarına Göre Gruplama¶
Kurum içerisinde, her ne kadar görev tanımları farklı olsa da kullanılan temel programların büyük bir kısmı aynı olacaktır. Ne kadar az özelleştirme ihtiyacı çıkarsa dönüşüm o kadar rahat olacağından dönüşüm süreci o kadar hızlandırılmış olur. Örnek gruplama tablosu aşağıdaki gibi olabilir:
| Görevi | Kullandığı Programlar | Düşünceler |
|---|---|---|
| Veri Hazırlama Kontrol İşletmeni |
|
|
| Sistem Yöneticisi |
|
|
| Şube Müdürü |
|
|
| Santral Memuru |
|
|
| Depo görevlisi |
|
|
2.1.6.2 Kullanılan Kaynaklara Göre Gruplama¶
Kullanıcılar bir takım özel donanımları ya da sunucular üzerinde çalıştırılan özel yazılımları kullanıyor olabilirler. Bu donanım ve/veya yazılım gereksinimleri öncelikli olarak analiz edilmelidir. Analiz sonucunda herhangi bir nedenden bu kullanıcılar için dönüşüm mümkün olamaz ise, ilgili kullanıcıları çalışma dışında bırakmak ve onlara sadece ihtiyaçları oranında kaynak ayırmak makul bir çözüm olacaktır. Bu çalışma sonunda kaynak ve kullanıcı tablosunun hazırlanması tüm yapının görülmesinde kolaylık sağlayacaktır. Örnek tablo aşağıdaki gibi olabilir:
| Kullanılan Programlar | Kullanıcı Grubu |
|---|---|
| Ofis programları |
|
| E-posta istemci |
|
| PDF Okuyucu |
|
| A web Uygulaması |
|
| B VTYS bağlantı aracı |
|
| C kurumsal masaüstü Uygulaması |
|
2.1.7 İşlevsel Eşdeğerlik Değerlendirme Çalışması¶
Kullanıcı grupları değerlendirme ve iş ihtiyaçları çalışmasının önemli çıktılarının başında kurumda kullanılan hizmet ve kullanıcı yazılım envanteri vardır. Yazılım envanteri içerisindeki ürünlerin Linux uyumlu sürümü olup olmadığı dönüşüm teknik ekibi tarafından kontrol edilmelidir. Bu kontrolün ardından Linux sürümü olmayan yazılımlar için eşdeğer yazılım olup olmadığına bakılmalıdır. Bu aşamada, kurumun yüklü yazılımların hangi bileşenlerini ve/veya özelliklerini kullandıkları, canlı ortamda incelenmeli ve eşdeğer yazılım yetenekleri ile bu özelliklerin karşılanıp karşılanmadığı, varsa ek özellikleri bir tablo olarak sunulmalıdır.
Kurumda kullanılan yazılımların birden fazla ÖY/AKK alternatifi bulunuyorsa bunların arasındaki seçim kullanıcı programları olgunluk değerlendirme metoduna göre yapılır. Bununla beraber, kullanılan hizmetler ve masaüstü programları kullanıcı ve kullanılan işlevler açısından incelenmelidir. Analiz raporunda, hem kullanıcı programları hem de kullanılan hizmetler açısından, risklerin de değerlendirilebileceği işlevsel eşdeğerlik çalışmasının aşağıdaki şekilde yapılması uygun olacaktır.
| Açık Kaynaklı Çözümler | Riskler | Sonuç | ||
| Alternatif A | Alternatif B | Riskler A | Riskler B | |
| A’nın temel özellikleri, olgunluk kriterleri açısından incelenmesi ve mevcut sisteme uyarlama senaryoları | B’nin temel özellikleri, olgunluk kriterleri açısından incelenmesi ve mevcut sisteme uyarlama senaryoları | A seçeneği ile oluşacak riskler, riskleri azaltma yöntemleri | B seçeneği ile oluşacak riskler, riskleri azaltma yöntemleri | Önerilen sistemin alternatifler ve bu alternatifin oluşturduğu risklerin göz önüne alınarak belirlenmesi |
| Maliyet Analizi | Maliyet Analizi | |||
| Mimari Özellikler | Mimari Özellikler | |||
| Olgunluk Puanları | Olgunluk Puanları | |||
| Genel Durum: | Kullanılan uygulama, program, yazılım genel özellikleri ve mimarinin incelenmesidir. |
| Mevcut Durum: | Sunucuların yapısı ve kullanıma yönelik özellikleri, özelleştirmeler vb. diğer sunucular ile etkileşimleri;yetkilendirme, güvenlik vb. açısından incelenmesi beklenmektedir. |
2.1.8 Hizmet ve Uygulama Analizi¶
Sunucu sistemlerin eşdeğerliği kapsamında, işlevsel eşdeğerlik çalışmasını da içeren birlikte çalışabilirlik, mimari tasarım gibi konular dikkate alınarak analiz gerçekleştirilir. Hizmet yazılımları (DNS, E-Posta, Veritabanı, Web, Engerek, Lider/Ahenk vb.), kullanıcı yazılımlarından farklı olarak merkezi ve çok kullanıcıya hizmet veren yazılımlardır. Bunların bir kısmının geçici süre ile kapanması çok büyük sorunlara neden olmazken, DNS, E-posta gibi temel hizmetleri veren sunucularının belirli bir süreden fazla kapanması kabul edilmeyecektir. E-posta ve veritabanı gibi hizmetlerin içerisinde barındırdığı verilerin değerli olduğu ve olası bir dönüşüm çalışması sırasında taşınması gerektiği unutulmamalıdır.
Hizmet yazılımlarının, sunduğu olanakların tamamı kurum tarafından kullanılmıyor olabilir. Bu bileşenler eşdeğer yazılım ihtiyaçlarına bakılırken göz önünde bulundurulur. Gereksiz bileşenlerin; güvenlik, sistem yönetimi, yedekleme, iş sürekliliği gibi alanlarda gereksiz yük ve risk getirdiğini unutmamak gerekir. Bu nedenle dönüşüm çalışması esnasında ihtiyaçların doğru belirlenmesi gereksiz yüklerden kurtulma yönünde iyi bir fırsattır ve değerlendirilmelidir. Örneğin, dosya sunucusu açısından işlevsel karşılaştırmalar aşağıdaki tabloda gösterilmiştir.
| S/N | İşlev | Alternatif A | Alternatif B | Varolan Sistem |
|---|---|---|---|---|
| 1 | Dosya Depolama | Var | Var | Var |
| 2 | Dosya Paylaşımı | Var | Var | Var |
| 3 | Tüm Metinde Arama | Var | Var | Yok |
| 4 | Dizin Paylaşımı | Var | Var | Var |
| 5 | PDF gösterici | Var | Var | Yok |
Sık kullanılan hizmet yazılımlarının eşdeğerlilik tablosu aşağıdaki gibidir:
| Hizmet Açıklaması | Mevcut Sistem | Eşdeğer Sistem |
|---|---|---|
| E-Posta Sunucusu | Microsoft Exchange | Zimbra, OpenExchange, Postfix + Dovecot + Caldav + Carddav + Webmail |
| İnternet Sayfası Sunucusu | IIS | Apache, Nginx, Lighthttpd |
| Veritabanı Yönetim Sistemleri | Oracle, MS SQL | PostgreSQL |
| Alan Adı Sunucusu | Microsoft DNS | Bind |
Her bir hizmet servisi için yapılacak faaliyetler kurum ihtiyaçlarına göre çeşitlilik gösterebileceği için, analiz aşamasında hizmete göre toplanması gereken bilgiler dönüşüm yapılacak kurumun proje ekibi tarafından koordine edilmelidir.Örnek olması bakımından, E-posta, VTYS, DHCP ve Aktif Dizin hizmetleri için dönüşüm öncesi toplanması gereken temel bilgiler Sunucu Dönüşümü Bölümü’nde sunulmuştur. Ayrıca, dönüşüm kapsamında değerlendirilmeyen ancak kurumların ileride kullanabileceği ÖY/AKK’lu yazılım eşdeğerlerinin bulunduğu sanallaştırma altyapısı ve güvenlik bileşenleri için de ÖY/AKKY mevcuttur. Bu konu ilgili bölümlerde ele alınmıştır.
2.1.9 Masaüstü Programların Analizi¶
Kurumsal kullanımda masaüstü bilgisayarlar (istemciler), günlük çalışmaların yapılması için çok büyük rol oynamaktadır. Kullanıcıya uygun masaüstü işletim sistemi, aslında personelin kurum içerisindeki görevlerine ve bu görevleri başarabilmesi için kullanması gereken uygulamalara bağlıdır. Günümüzde birçok iş uygulaması, web teknolojisi gibi işletim sistemi bağımsız platformlarda geliştirilmektedir. Ekonomik nedenlerden dolayı birçok kurum hizmet yönelimli mimari’ ye (SOA) geçmektedir. Web hizmetleri, Genişletilebilir İşaretleme Dili (XML), Basit Nesne Erişim Protokolü (SOAP), Bağlantılı Metin Aktarım Protokolü (HTTP) gibi yaygın teknolojileri kullanarak birlikte çalışabilirliği sağlayan standartlar kümesi olarak tanımlanabilir.
Şekil: İstemci Programları
İstemci uygulamaları için Web hizmetlerine dayalı uygulamalar genellikle Java Programlama dili kullanılarak geliştirilmektedir. Kullanıcı bir web tarayıcısı aracılığıyla ilgili uygulama portalına erişebilmektedir. Bu durum, kullanıcının işletim sistemini uygulamaya göre şeffaf hale getirmekte ve platform seçim özgürlüğü, uygun maliyet, hızlı destek, esneklik ve açık standartlara destek gibi avantajlarla birlikte birçok yenilikçi teknolojiyi de beraberinde getirmektedir.
Bu bağlamda, karar vericiler tarafından, teknolojinin yönü ve kurumsal mimari içerisinde işletim sisteminin hangi işlevleri yerine getirdiğinin anlaşılması önemlidir. Bu durum, bugün kullanıcı ihtiyaçlarını karşılamak için verilen kararların gelecekteki mimari gereksinimlerini desteklemesine de yardımcı olacaktır. İşletim sistemi dönüşümü için bileşenler tek tek ele alınmalı, üzerinde ciddiyetle düşünülerek stratejiler belirlenmelidir.
Kullanıcı yazılımlarındaki ihtiyaçlar kullanıcı gruplarına göre farklılık gösterebilir. Örneğin bir grup ofis yazılımlarında hesap tablolarını basit işler için kullanırken, başka bir grup makro vb. araçlarla karışık hesaplamalar yapabilir. Bu nedenle yazılım eşdeğerliklerinde grup ihtiyaçları ön planda tutulmalıdır. Bu kapsamda ofis programları dönüşümü ayrı bir başlık altında değerlendirilmiştir.
Yazılımlar ve yardımcı araçların tamamı belirlendiğinde eşdeğer ürünlerin ihtiyaçları karşılayıp karşılamadığını görmek için bir kavram kanıtlama çalışması yapılması yararlı olacaktır. Kavram kanıtlama çalışmasına girdi oluşturması açısından kabul edilebilirlik kriterleri ilgili yazılımın kullanıcıları ile birlikte değerlendirilip bu aşamada bir tablo halinde getirilerek paylaşılabilir.Bir Outlook uygulaması için örnek tablo şu şekilde olabilir;
| S/N | İşlev | Alternatif A | Alternatif B | Varolan Sistem |
|---|---|---|---|---|
| 1 | Ortak adres defteri uygulaması | Var | Var | Var |
| 2 | Ortak takvim uygulaması | Var | Var | Var |
| 3 | Akıllı telefon ve tabletlere, Microsoft Outlook ve Mozilla Thunderbird vb. farklı istemcilerle temel e-posta hizmeti | Var | Var | Var |
| 4 | Başka bir kişi ya da grup adına e-posta gönderme | Var | Var | Yok |
2.1.10 Başarı Kriterleri¶
Yapılan analiz çalışmaları sonunda Kurum ile birlikte başarı beklentilerinin yer aldığı Teknik Başarı Kriterleri belgesi doldurulmalıdır. Belgede uygulama/program ve yazılımların hangi kriterlere göre değerlendirilmesi gerektiği, bu kriterlerin öncelikleri konusunda bir çizelge hazırlanmalıdır. Bu çizelge bir sonraki aşama olan kavram kanıtlama çalışmasında kullanılacaktır. Örnek Teknik Başarı Kriterleri tablosu aşağıda sunulmuştur.
| # | Uygulama Adı | Test Başarı Kriteri | Test Sorumlu Birimi |
|---|---|---|---|
| 1 | A portalı |
|
Z Birimi |
| 2 | B Web Uygulaması |
|
H Birimi |
| 3 | C Web Uygulaması |
|
C Birimi |
| 4 | EBYS Uygulaması |
|
A Birimi |
| # | Uygulama Adı | Test Başarı Kriteri | Test Sorumlu Birimi |
|---|---|---|---|
| 1 | E-posta İstemcisi | A Birimi | |
| 2 | E-imza | B Birimi | |
| 3 | MATLAB | C Birimi |
2.1.11 Analiz Çalışması Sonrası Değerlendirme¶
Analiz çalışması sonucunda, ÖY/AKKY’a dönüşüm için yapısal bir engel yoksa Kavram Kanıtlama çalışmalarına başlanır. Bu aşamada karşılaşılan sorunlar varsa gruplandırılır. Bu sorunların çözümü olup olmadığına ilişkin cevaplar aşağıdaki şekilde verilebilmektedir.
- Bu sorunun çözümü teknik olarak imkansızdır.
- Bu sorunun çözümü teknik olarak mümkündür ancak makul bir sürede tamamlanamaz.
- Bu sorunun çözümü teknik olarak mümkündür ancak ilgili ÖY/AKK’lu uygulamaya ek yazılım gereklidir.
- Yapılandırma ayarları ile sorunların giderilmesi mümkündür.
Dönüşüme engel oluşturan sorunlar teknik olarak çözülmesi mümkün olmayan sorunlar ya da bu sorunların giderilmesi sırasında harcanacak süre ile maliyet etkin olmaktan uzak ise Dönüşüm Teknik Ekibi ve Kurum ile alınacak ortak karar sonucunda analiz çalışması; kavram kanıtlama aşamasına geçilmeden önce sonlandırılır. ÖY/AKKY’a ek yazılım gerekli ise; proje buna göre uyarlanarak devam eder.
2.2 Kavram Kanıtlama Çalışması¶
Kavram Kanıtlama Çalışması, dönüşüm ile ilgili soru işaretlerini ortadan kaldırmak ve ön yargıları yıkmak için önemlidir. Bu nedenle titizlikle ele alınması gereken bir konudur. Bu hassasiyet genelde bu çalışmanın amacını aşılmasına ve beklentilerin farklılaşmasına sebep olur. Kavram kanıtlama çalışmasının çıktısı, dönüşümü düşünülen uygulamanın mevcut ihtiyaçları karşılayıp karşılamadığını göstermektedir.
2.2.1 Kavram Kanıtlama Çalışması Nedir? Ne Değildir?¶
Kavram kanıtı (Proof of Concept), yöntem ya da fikrin fizibilitesini göstermek, bazı kavramların ya da teorinin pratik potansiyele sahip olduğunu doğrulamak amacıyla yapılan bir gösterimdir. Kavram kanıtlama çalışması genellikle daha sınırlı bir ortamda yapılır. Gösterimi yapılan ürün/yazılım son ürün olmayabilir.
Prototipleme ise, yenilikçi teknolojinin veya ürünün nasıl işleyeceğinin görselleştirilmesini sağlayan bir çalışmadır. Tasarım, navigasyon ve düzen hakkında fikir veren son ürünün kullanıcı etkileşimli bir modelidir. Bir Kavram Kanıtlama bir ürün veya özelliğin geliştirilebileceğini gösterirken, bir prototip nasıl geliştirileceğini gösterir [Singaram2018]
Dolayısıyla, kavram kanıtlama çalışması “Analiz” aşamasında tespit edilen yazılım özelliklerinin, göçe konu ÖY/AKK’lu bir yazılım üzerinde gösterilmesi işidir. Prototipleme adı verilen kavram ise, gerekiyorsa pilot aşamasından önce kullanıcı istekleri dikkate alınarak yazılıma ek entegrasyon özelliklerini kazandırma veya kurum ihtiyaçlarına göre yazılımı özelleştirme çalışması olarak tanımlanabilir. Prototipleme aşaması öncesinde kurum tarafından, kavram kanıtlama çalışmasında sunulan ÖY/AKKY’ın özelliklerinin kabul edilip geliştirme veya yazılıma eklenmesi gereken fonksiyonlar için onay verilmesi gerekmektedir.
Sonuç olarak, Kavram Kanıtlama Çalışması kontrollü ortamda, sınırlı kapasite ile yapılan bir ispat çalışmasıdır. Nihai kullanım ürünü değildir. Sadece yetenek kanıtlamak için yapılan kısıtlı bir çalışmadır. Bu nedenle pilot ve üretim ortamı kurulumu ile kavram kanıtlama kurulumları birbirine karıştırılmamalıdır. Üretim ortamı için kurulacak sistemlerde öncelikle bir kapasite gereksinim çalışması yapılması gerekir. Kavram kanıtlama aşamasında özel olarak ihtiyaç duyulmadıkça öntanımlı kurulumlar üzerinden çalışmalar yapılır veya sadece kavramı kanıtlamaya yönelik özelleştirmeler yapılır.
Kavram Kanıtlama Çalışması bu nedenle kullanıma hazır ürün değildir. Prototipleme ya da Pilot kurulum değildir. Tercihen kurum altyapısından yalıtımlı ortamda yapılır ve kurum ortamına entegre edilmez.Kavram kanıtlama çalışmasının iki temel girdisi vardır.
- Analiz Çalışması
- Başarı Kriterleri
Analiz çalışmasını daha önceki bölümlerde detaylı olarak irdelemiştik. Bu çalışmanın en önemli girdisi, başarı kriterleridir. Başarı kriterlerini belirlerken, sistemin genişlemesi de hesaba katılmalı ancak ulaşılamaz hedeflerden kaçınılmalıdır.
Göç sürecinde, kavram kanıtlama çalışmasına alınan uygulamanın, aslında var olan sistemlerin yerine geçeceği unutulmamalıdır. Bu nedenle mevcut ortamda kullanılan uygulama yeteneklerinin karşılanmasının, temel başarı kriteri olarak alınması tercih edilmelidir. Kavram kanıtlama çalışması kısmen zaman alsa da bu çalışmanın sonucunda durum tespiti yapılmış olacaktır.
Kavram Kanıtlama Çalışması sonucunda önerilen yazılımların, mevcut sistemlerin yerini alabilecek yeteneklere sahip olup olmadığı, son kullanıcılar açısından yeni programların verimli olup olmayacağı ve çözümün uygulanabilirliği açısından bir sonuca varılmalıdır.
2.2.2 Kavram Kanıtlama Çalışması Yapılacak Uygulamaların Seçilmesi¶
Kurumda geçişi yapılacak uygulamalar dönüşüm önceliklerine göre belirlenir, bu kapsam dışında kalan uygulamaların, kavram kanıtlama aşamasında test edilmesine gerek yoktur. Kurum özelinde kullanılan, öncelikli ve önemli olduğu değerlendirilen uygulamaların, yine belirli olgunluk düzeyine erişmiş ÖY/AKK eşdeğerleri ile karşılaştırılması yapılmalıdır. Karşılaştırılması yapılan uygulamalara arayüz, kullanım kolaylıkları gibi bir takım görsel nedenlerden dolayı kullanıcılar direnç gösterebilecektir. Bu sorun, her yeni uygulamada olduğu gibi biraz eğitim ve pratik yaparak aşılabilecektir.
Ofis uygulamalarından LibreOffice uygulaması, Microsoft Office uygulamasının açık kaynak dünyasındaki en çok tercih edilen alternatifidir. Bir çok kullanıcı, yıllardır Microsoft Office uygulaması kullandığı için arayüzüne alışmıştır ve LibreOffice kullanmaya başladığında tepki verebilecektir. Aynı kullanıcılar, mevcut kullanılan işletim sisteminde versiyon değişikliğinde de zorlanabilecektir. Kullanıcı eğitimi sonrası karşılaşılan direnç de azalacaktır. Dolayısı ile, çoğu durumda işin yapılmasına yönelik fonksiyonların sistem yöneticilerine gösterilmesi bu aşamada yeterli olmaktadır.
Benzer yaklaşım dönüşüm çalışmaları için de geçerlidir. Kullanıcılar arasında bu yeni uygulamaları özendirmek için kullanım kolaylıklarını göstermek çok önemlidir. Kurumsal yapıda en çok kullanılan uygulamaların yaygın olarak kullanılan alternatifleri aşağıdaki tablodadır.
| Uygulama Türleri | Ticari Uygulamalar | ÖY/AKK Eşdeğer Uygulama |
|---|---|---|
| Ofis Uygulamaları | Microsoft Office | LibreOffice |
| Web Tarayıcı | Internet Explorer | Google Chrome, Mozilla Firefox |
| Uzaktan Yönetim | Team Viewer | TigerVNC |
| Görüntü İşleme | Adobe Photoshop | Gimp |
| Masaüstü Sanallaştırma | VMware, Workstation, Parallels Desktop | VirtualBox |
| E-Posta İstemcisi | Outlook | Thunderbird |
| Anlık Mesajlaşma | MSN Messenger | Pidgin |
| Medya Oynatma | Media Player | VLC |
| Antivirüs | Symantec, Sophos, McAfee, Kaspersky | ClamAV |
| Kod Geliştirme Platformu | Visual Studio | Kdevelop |
| Çizelge Şema Çizimi | Microsoft Visio | Dia |
| Vektörel Grafik İşleme | Adobe Illustrator, CorelDraw | Inkscape |
| Raporlama | SAP Crystal Reports | Jmagallanes |
| Video İşleme | Adobe Premiere Pro | Cinelerra |
2.2.3 Kavram Kanıtlama Test Formları¶
Kavram Kanıtlama çalışmalarında kullanılacak test formu, çalışma öncesinde dikkatle hazırlanmalıdır. Bu form dört bölümden oluşmalıdır. Bunlar;
2.2.3.1 Amaç¶
Amaç kısmı testten beklentileri net bir şekilde tanımlamalıdır. Özellikle, kontrol maddelerini yazacak ve bu maddeleri kontrol edecek kişiler tarafından testin neden yapıldığı, kontrol edilen uygulamanın mevcutta hangi sisteme karşılık geldiği açıklıkla belirtilmelidir.
2.2.3.2 Test Maddeleri¶
Kontrol maddeleri, analiz raporunda belirtilen temel özellikler ve denenmesi istenen maddelerden oluşmalıdır. Analizde olmayan maddeler bir nedenle burada yer alıyorsa mutlaka belirtilmelidir. Kavram kanıtlama çalışması sonucunda beklenen mevcut ihtiyaçların ÖY/AKKY ile karşılanıp karşılanamayacağını ortaya çıkarmaktır. Göç projelerinin ilk hedefi ise belirlenen ÖY/AKKY ile bu güçlü yapıyı kurmaktır. Sisteme eklenmesi istenen ek nitelikler için göç sonrası geliştirme faaliyetleri ayrıca planlanmalıdır. Test maddeleri Kurumun gerçekçi istekleri göz önüne alınarak hazırlanmalıdır. Yazılıma mevcut sistemde olandan daha fazla fonksiyon eklenmesi için yapılan istekler, kavram kanıtlama faaliyetlerinin gereksiz yere uzamasına ve bitmeyen bir iş olarak görülmesine yol açabilecektir.
2.2.3.3 Değerlendirme¶
Kontrol maddeleri sütununun yanında, karar verilecek değerlendirme kriterlerine göre oluşturulmuş bir tablo parçasıdır. Duruma göre başarılı / başarısız, evet / hayır, kabul / red vb. ifadeler kullanılıyor olabilir. Bu ifadelerin ne anlama geldiği formun altında mutlaka belirtilmelidir.
Bu alanda belirtilen cevap test edilen özelliğin, beklendiği şekilde çalışıp çalışmadığını gösterir bir ifadedir. İfade sadece o madde ile ilgilidir. Üretim ortamı için ya da bir ihale şartnamesindeki kabul kontrolü gibi hem tekil hem bütünsel değerlendirilmemelidir. Bu alanlar için özel notlar varsa yorumlar bölümünde yazılmalıdır. Testte beklenen tüm özellikler karşılansa bile, göç kararının alınıp alınmaması bu aşama kapsamında değildir.
2.2.3.4 Yorumlar¶
Test esnasında karşılaşılan özel durumları veya varsa maddelere ilişkin özel notlar bu alanda yer almaktadır. Yorumlarda performans ve/veya kullanım zorlukları gibi konulara değinilebilir. Ancak değerlendiricinin kavram kanıtlama çalışması sırasında performansa yönelik ya da kullanım kolaylığı getirecek bazı geliştirmeler/ayarlamalar yapılmadığını bilerek testleri yapması gerekir.
2.2.4 Kavram Kanıtlama Çalışmaları Sonrası İşlemler¶
Kavram Kanıtlama Çalışmaları sonucu, Kurum tarafından hangi servislerin ve hangi Masaüstü bileşenlerinin göçe konu olacağı konusunda karar verilir ve bu karar proje teknik ekibine bildirilir. Bu karar içerisinde, kullanıcıların da istekleri dikkate alınır ve geliştirme ihtiyacı olan sistemler belirlenir.
Kavram kanıtlama çalışmaları sonunda proje teknik ekibi tarafından, pilot göç çalışmasına yönelik Kurum içinde yapılması gereken faaliyetlerin bir listesi hazırlanır.
Yazılım geliştirme işlemleri, Kurumsal işin yapılması açısından önceliklendirilir. Bu önceliğe göre ilgili geliştirme ekibi tarafından yazılıma ek işlevler geliştirilir.
İstendiğinde, ÖY/AKK işletim sistemine geçiş için, Pilot çalışma öncesi kullanıcılar çok düşük bir eğitim maliyeti ile eski sistemde kullandıkları bazı yazılımların işlevsel eşdeğeri olanlarını yine eski işletim sistemlerinde kullanabilirler. Kullanıcılar kendilerini bu uygulamalarda rahat hissettiklerinde, ÖY/AKK işletim sistemine göç daha az kesinti ve maliyetle yapılabilmektedir.
Özellikle web uygulamalarının işlevsel olarak düzgün çalışmaması durumunda, yazılımın kodları üzerindeki bazı değişikliklerin yazılım ekibi tarafından yapılması gerekebilir. Bu tip kod değişikliği gereksinimlerinde, web uygulamaları ÖY/AKK alternatifinde hangi özelliklerin düzgün çalışıp çalışmadığı detaylı test edilmeli, yazılım güncellemesi ardından testler tekrarlanmalıdır.
Pilot çalışma öncesi, hem sunucular hem de işletim sistemi testleri için bir test ortamı hazırlanması, yapılan geliştirmelerin sistemler üzerinde çalışabilirliğinin gösterilmesi ve denemelerin yapılması açısından faydalı olacaktır. Test ortamında, bilgi işlem altyapısının tüm bileşenleri olması beklenmez ancak test edilecek yazılımın etkileşim içerisinde bulunduğu diğer bileşenlerin bulunması, Kavram Kanıtlama sonrası aşamalar için istenen bir durumdur. Test ortamı, mutlaka üretim ortamından izole şekilde yaratılmalı ve gerçeğe uygun veriler barındırmalıdır.
| [Singaram2018] |
|