29 Haziran 2022 de yayınlanan 31881 sayılı “Kamu Bilişim Hizmet Alimi Kapsaminda Katılımcıların Yetkilendirilmesi Hakkinda Yönetmelik” mevzuatı ile kamu kurumlarına hizmet veren tüm tedarikçi firmaları için ISO 15504 SPICE sertifikasyonu zorunlu hale gelmiştir. Bu yazı dizisinde hem ISO 15504 SPICE süreci hakkında bilinmesi gereken noktalar anlatılacak hem de ilerleyen bölümlerde standardın kurum bünyesinde uygulanması hakkında bilgi verilecektir.
Yazı dizisinin daha önceki bölümlerine aşağıdaki bağlantılardan erişebilirsiniz.
BÖLÜM-1:
BÖLÜM-2:
BÖLÜM-3:
BÖLÜM-4:
Müşteri gereksinim yönetimi süreci için ENG.1 ne ifade etmektedir?
ISO 15504 SPICE standardı en temelde yazılım ve sistem projelerinin geliştirmeleri için gerekli süreçlerin işletilmesinden ibarettir. Müşteri gereksinim yönetim süreci bu kapsamdaki temel süreçlerden biridir. Her süreç için standartta tanımlanmış bir etiket mevcuttur. “ENG.1”, risk yönetim sürecine ait etikettir.
ENG.1 sürecinin işletilmesi şart mıdır?
ENG.1 süreci ISO 15504 SPICE sertifikasyonunda başlangıç seviyesi olan Seviye-2 ve üzeri tüm süreçler için şarttır.
ENG.1 süreci kapsamında hangi dokümanların hazırlanması beklenmektedir?
Standart dokümanı süreçler için bazı doküman isimleri önerse de doğrudan dayatılmış bir doküman ismi söz konusu olamaz. Ancak bu süreç kapsamında en azından aşağıdaki dokümanların oluşturulması makul olur.
- Yeni başlayan projeler için hazırlanmış bir “Müşteri Gereksinim Doküman” veya buna muadil olacak bir teknik şartname
- Sahaya çıkmış projeler için; üründe yapılması istenen; geliştirme, hata ve değişiklikler için “müşteri gereksinim” kayıtları
- Projeye dair gerek sıfırdan başlama gerek sahaya çıkma sonrası ortaya çıkan “müşteri gereksinim” maddeleri için ön analiz, analiz onayı ve mutabakat kayıtları
“Müşteri gereksinimi” kavramı nedir? “Yazılım gereksinimi” ile nasıl bir fark gösterir?
Müşteri gereksinimleri doğrudan müşterinin (yada son kullanıcının) ağzından dökülebilecek şekilde üst seviyede projeye (ürüne) ait ister maddeleridir.
Yazılım gereksinimlerine göre detay seviyesi ve teknik içeriği düşüktür. Zaten yazılım gereksinimleri, müşteri gereksinimlerinin yazılım geliştirmesine input olacak şekilde detaylanmasından oluşmaktadır.
Yazılım gereksinimleri ve bunların detayına sonraki bölümlerde ayrıca değinilecektir.
“Müşteri gereksinimi” için kaynak kimdir? Ortada spesifik bir müşteri yoksa müşteri gereksinimlerinden nasıl söz edilebilir?
“Müşteri gereksinimi (Customer Requirement)” ifadesi ISO 15504 standardı içinde ENG.1 süreci için kullanılan başlıktır.
Aynı zamanda süreç içindeki gereksinimler için de bu ifade kullanılmaktadır.
Ancak konuya detaylı yaklaşıldığında burada geçen “müşteri gereksinimi” ile illaki bir müşteriden bahsedildiği, onun yerine “müşteri gibi bir son kullanıcı ifadesi ile gereksinimlerin tanımlanması” kastedildiği anlaşılmaktadır.
Bu bağlamda müşteri gereksinimlerinin illaki bir müşteri ya da müşteri grubundan alınması gerekmez.
Proje ekibinin literatür taraması, saha incelemeleri, uygulama tecrübeleri ile de müşteri gereksinimleri oluşabilir.
Veya kamu kurumu gibi düzenleyici bir kuruluşun yayınladığı şartnameler veya rehberler “müşteri gereksinimleri” yerine geçebilir.
“Müşteri Gereksinimi Yönetimi” hangi başlıkları içerir?
ISO 15504 SPICE standardına göre “Müşteri Gereksinimi Yönetimi” en temelde aşağıdaki başlıkları içerir.
- Müşteri gereksinimlerinin toplanması
- Müşteri gereksinimlerinin anlaşılması
- Müşteri gereksinimlerinin ön analizi
- Müşteri gereksinimlerinin kurum (proje) içinde onaylanması
- Müşteri gereksinimleri için müşteri mutabakatı ve baseline alınması
- Müşteri gereksinimlerinin tekil olarak takip edilmesi
- Müşteri gereksinimleri için yaşanan gelişmelerde müşterinin bilgilendirilmesi
- Müşteri gereksinimlerinde değişikliklerin yönetimi
Müşteri gereksinimleri toplama nasıl uygulanır?
Müşteri gereksinimlerinin ilk olarak çıkarılması veya alınması sürecidir. Bunu 2 kademede düşünmek makul olacaktır.
1- Sıfırdan Bir Proje Yaparken:
Bu aşamada gereksinimleri alırken mümkünse projeyi talep eden taraftan bir şartname veya gereksinim dokümanı talep edilir.
Eğer bu uygulanabilir değilse, proje ekibinde görevli bir personeller (genellikle analist) sahayı, literatürü veya benzer çalışmaları izleyerek bir “Müşteri Gereksinim Dokümanı” üretir.
2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:
Sahaya çıkmış ürün için isterler idealde bir “müşteri destek aracı” üzerinden alınır. Mail yada telefonla isterler gelirse bunlar proje personelleri tarafından “müşteri destek aracı” üzerine kaydedilir. Proje ekibi içinde ortaya çıkarılan ek gereksinimleri, yine “müşteri destek aracı” üzerinde kaydedilir. Her durumda yapılması gereken, alınan tüm gereksinimlerin sistematik bir şekilde kaydı ve takibidir. Bu bağlamda bu aşamada bir “müşteri destek aracı” kullanımı pratik olarak zorunludur.
Müşteri gereksinimlerinin anlaşılması nasıl uygulanır?
Müşteri gereksinimlerinin detaylı olarak anlaşılması sürecidir. Bunu da bir önceki süreçte olduğu gibi 2 kademede düşünmek makul olacaktır.
1- Sıfırdan Bir Proje Yaparken:
Bu aşamada gereksinimleri detaylı anlamak için proje personeli tarafından yapılan saha incelemeleri ile gerçekleşir. Gerekirse bu aşamada müşteri (varsa) veya gereksinimleri bildiren taraflarla toplantı yapılır.
2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:
Sahaya çıkmış ürün için de gereksinimleri detaylandırmada saha araştırmaları yapılabilir. Eğer mümkünse gereksinimi bildiren müşteri tarafından ekran görüntüleri gibi ek kanıtlar istenir.
Alınan tüm notlar ve kanıtlar “müşteri destek aracı” üzerinde kaydedilir.
Eğer gereksinimler detaylanmaya ihtiyaç duymayacak kadar netse (örneğin çok açık bir bug varsa) bu aşama da illaki bir çalışma zorlanmaz.
Müşteri gereksinimlerinin ön analizi nasıl uygulanır?
Burada kastedilen teknik bir analizden öte, iş süreci anlamında gereksinimlerin; yasal, makul ve uygulanabilir olduğunun değerlendirilmesidir.
Bunu da bir önceki süreçte olduğu gibi 2 kademede düşünmek makul olacaktır.
1- Sıfırdan Bir Proje Yaparken:
Bu aşamada ön analiz yine proje personeli tarafından yapılan saha incelemeleri ile gerçekleşir.
Gereksinimler için; yasal, çevresel ve uygulanabilirlik açısından bir problem olup olmadığı değerlendirilir.
Alınan notlar projenin onaylandığı bir sonraki aşamada üst yönetime sunulur.
2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:
Sahaya çıkmış ürün yapılan ön analizde proje personeli tarafından gereksinimin; yasal, çevresel ve uygulanabilirlik açısından bir problem olup olmadığı değerlendirilir.
Analiz sonucu “müşteri destek aracı” üzerinde kaydedilerek proje yöneticisi onayına sunulur.
Müşteri gereksinimlerinin kurum içinde onayı nasıl uygulanır?
Burada kastedilen projenin veya projeye dair müşteri gereksinimlerinin geliştirmeyi yapacak kurum/şirket içinde onaylanmasıdır.
Bunu da bir önceki süreçte olduğu gibi 2 kademede düşünmek makul olacaktır.
1- Sıfırdan Bir Proje Yaparken:
Yeni bir projeye başlanması ve bunlar ile ilgili gereksinimlerin onaylanması çok kritik bir safhadır. Bu bağlamda; bu aşamada üst yönetim temsilcilerinin de katıldığı bir toplantının yapılması ve akabinde “Müşteri Gereksinim Dokümanı” için üst yönetim tarafından onay yapılması beklenir.
Tabi ki bu aşamada üst yönetim yada tarafların talebi ile doküman ve gereksinimler üzerinde revizyonlar yapılır.
2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:
Sahaya çıkmış ürüne dair gelecek bir talebin devreye alınması (veya reddedilmesi) sıfırdan bir proje yapılması gibi kritik değildir.
Bu nedenle bir önceki aşamada yapılan ön analizin “müşteri destek aracı” üzerinden onaylanması ile bu aşama tamamlanmış olur.
Bu aşamada proje yöneticisi dilerse gerekçesi ile beraber talebi reddedebilir. Veya yapılmış ön analizin detaylanmasını veya tekrarını isteyebilir.
Müşteri mutabakatı ve baseline alınması nasıl uygulanır?
Bu aşamada ortaya çıkacak ürünün/projenin müşteri gereksinimleri için müşteriden onay alınmasıdır.
Bunu da bir önceki süreçlerde olduğu gibi 2 kademede düşünmek makul olacaktır.
1- Sıfırdan Bir Proje Yaparken:
Yeni bir projeye başlanması ve bunlar ile ilgili gereksinimlerin müşteri tarafından onaylanması çok kritiktir.
Bu nedenle proje başlangıç aşamasında hazırlanmış ve kurum/şirket içerisinde karara bağlanmış “Müşteri Gereksinimleri Dokümanı” üzerinden müşteri ile toplantılar yapılır. Süreç sonunda müşterinin ilgili gereksinimleri onaylaması sağlanır. Bu onay işlemi ıslak imza veya alternatif bir yöntemle olabilir. Burada önemli olan sonradan ispatlanabilir bir yöntem kullanılmasıdır. Müşteri tarafından yapılan onaya, müşteri üst yönetiminin veya onlar tarafından yetkilendirilmiş kişilerin dahil olması sağlanır.
2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:
Sahaya çıkmış ürüne dair gelecek bir talebe dair yapılacak işlem için müşteriden mutabakat devreye alınması sıfırdan bir projenin gereksinimleri için mutabakat sağlanması gibi kritik değildir.
Bu nedenle bu tarz gereksinimler için mutabakat “müşteri destek aracı” üzerinden bir müşteri yetilisinin onay vermesi ile sağlanmış olur.
Eğer projede spesifik bir müşteri olmayıp isterler kurum içinde geliştirilmişse, “Müşteri Mutabakatı ve Baseline Alınması” kurum/şirket içinde yapılan iç onay süreci ile tamamlanmış olur.
Müşteri gereksinimlerinin tekil olarak takip edilmesi nasıl uygulanır?
SPICE standardına uygun olarak proje geliştirilmesi sürecinde genel olarak “gereksinimlerin izlenebilirliği” beklenir.
Buna göre bir müşteri gereksinimin, ilgili yazılım gereksinimi, tasarım, kod ve testler ile eşleşmesi beklenir.
Bunun için her bir müşteri gereksinimine birer kod verilmesi makul olacaktır.
Gereksinime kod verilmesi önceki süreçlerde olduğu gibi 2 kademede düşünmek makul olacaktır.
1- Sıfırdan Bir Proje Yaparken:
Yeni proje başlanıldığında daha önceki bölümlerde belirtildiği gibi bir “Müşteri Gereksinim Dokümanı” hazırlanması beklenir.
Bu doküman hazırlanırken her bir gereksinim için bir kod verilmelidir. Bu kod için herhangi bir spesifik formata olmak zorunda değildir. Tutarlı bir kodlama yeterli olacaktır.
2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:
Sahaya çıkmış ürüne dair gelen gereksinimlerin yukarıda belirtildiği gibi bir “müşteri destek aracı” üzerine girilmesi beklenir.
Bu araçlar doğaları gereği, genellikle üzerlerine girilmiş kayıtlara tekil kodlar/numaralar atarlar. Araç tarafından atanmış bu numaralar “müşteri gereksinim kodu” olarak kabul edilebilir.
Müşteri gereksinimlerinin müşteri tarafından takip edilebilmesi nasıl uygulanır?
Müşteri gereksinimlerinin geliştirme süreçlerine alınmalarından sonra, ilgili oldukları müşteriler tarafından takip edilebilmeleri gerekir.
Bunun için geliştirmeyi yapan kurumlar/şirketler bir yöntem tanımlamalı ve uygulamalıdır.
Bu yöntem aşağıdakilerden biri olabilir.
- Projenin belli aşamalarında müşteri bilgilendirme toplantıları yapılması
- Müşteriye bilgi almak için bir destek hattı kurulması
- Gereksinimlerin geliştirildiği araç üzerinden müşteriye aşamaları izleme hakkı verilmesi
Müşteri gereksinimlerinin değişikliklerinin yönetilmesi nasıl uygulanır?
Gerek projenin ilk geliştirilmesi, gerekse de projenin sahaya çıkmasından sonra üründe ve müşteri gereksinimlerinden değişiklik talepleri ortaya çıkabilir.
SPICE süreçlerinde proje kapsamında yapılacak tüm değişikliklerin yönetimi için “SUP.10 : Değişiklik Yönetim Süreci” tanımlıdır.
Bu bağlamda “ENG.1: Müşteri Gereksinimlerini Yönetilmesi” sürecinde müşteri gereksinimleri değişikliklerindeki değişikliklerin yönetimini detaylı tartışmak yerine, “SUP.10” sürecine atıf yapmak ve orada bu metodolojiyi tanımlamak daha makul olacaktır.
Bu mantıkla bizim tarafımızdan da müşteri gereksinimlerinin yönetimi, yazı dizisinin sonraki adımlarında gelecek olan SUP.10 sürecinde ele alınacaktır.
“ENG.1: Müşteri Gereksinimleri Yönetimi” süreci için gerekleri bu şekilde özetlemiş olduk. Yazı dizisinin bir sonraki bölümünde görüşmek üzere.