SPICE denetime hazırlanmak için zorlu bir süreçten geçtiniz ve hazırlık yaptınız. SPICE denetiminden daha rahat geçebilmek için bu kontrol listesini kullanarak ön değerlendirme yapabilirsiniz. Doğaldır ki burada denetimde karşınıza çıkacak tüm soruları yazmak mümkün değildir sadece denetim konusunda bir fikir oluşturması açısından hazırlanmıştır.
SPICE Belgesi Denetim Hazırlığı
- Projelerde bir işi yapan ile gözden geçiren/onaylayan farklı kişiler olmalıdır. Örneğin, bir dokümanı hazırlayan ile o dokümanı onaylayan ya da yazılım geliştirici ile testi yapan kişiler mutlaka farklı olmalıdır.
- Kalite Yönetim Uzmanın süreçlerin denetimini yapmaktadır. Ancak kendi süreçlerinin denetimini kendisi yapamayacağı için Kalite Güvence sürecinin denetimini bir başkasının yapması gereklidir. Bunun için SUP.1 Süreci İç Tetkik Planında kalite uzmanının iş süreçlerine yer verilmesi ve bunun farklı bir kişi tarafından yapıldığının belirtilmesi gerekir. Benzer durum SUP.2 Doğrulama süreci içinde yapılmalıdır.
- Tüm süreçlerde müşterilerden onay alındığı ispatlanmalıdır.
- Tüm süreçler ispatlanabilir olmalıdır. (E-posta, toplantı tutanağı, proje yönetim aracı vb.)
- Mühendislik süreçlerinin tamamı (ENG.1, ENG.4, vb.) log kayıtlarından süreçlerin SPICE süreçlerine uygun işletildiğinin gösterilebilmelidir.
- Proje yönetim araçları üzerindeki (TFS, JIRA vb.) tüm iş akışlarının proje yöneticisinin onayından geçirilmelidir.
- MAN.3 Proje Yönetim Sürecinde görev tanımlarının her biri farklı dosyalar (doküman) olarak yer almalıdır.
- Proje başlanırken yapılan proje başlangıç toplantısına ait tutanak olmalıdır. Eğer toplantı online yapılıyor ise bunun bir tutanağa bağlanması (e-posta, toplantı linki vs.) tutanakta yer almalıdır.
- MAN.3 Proje Yönetim Sürecinde en az iki adet proje durum raporu olması tercih edilir.
- MAN.3 Proje Yönetim Sürecinde performans ölçümünün en az 2-3 kez yapılmış olmalıdır.
- Ölçümlerin proje ortasında yoğunlaşması daha uygun olacaktır. (Bkz. SUP.1- Süreç Performans Raporu)
- Proje Yönetim Planında (PYP) proje ekibinin rol ve niteliklerin yanına sorumlu olduğu süreç bilgisi de yazılmalıdır.
- Proje Yönetim Planında proje ekibinde yer alan her kişinin isim, rol ve görevlerinin tek bir tabloda gösterilmelidir.
- Proje Yönetim Aracında (TFS, JIRA vb.) yer alan iş akışının proje yönetim planında yer almalıdır. Akış çizimi ya da akışı gösteren bir ekran görüntüsü olabilir.
- Performans ölçüm tarihleri ile proje değerlendirme toplantı tarihlerinin birbiri ile uyumlu olmalıdır.
- Proje takviminde yer alan “Proje değerlendirme/durum toplantısı” başlığına Fizibilite, Performans, Risk değerlendirmesi yazılmalıdır.
- Her prosedürün altında o sürecin performansının nasıl ölçüleceği belirtilmelidir. Eğer süreç performansına ait bilgiler farklı bir dosya/form/şablon üzerinden takip ediliyor ise “Bu sürecin performansı Performans Değerlendirme Raporundaki Hedef ve Tarihlere göre ölçülür.” gibi bir ifade eklenmesi ve ilgili dosyaya referans verilmesi gerekir.
- SUP.1 Kalite Güvence Sürecinde, süreç performans raporunda her süreç için en az 2 adet ölçüm kriteri/hedef olmalıdır.
- SUP.1 Kalite Güvence Sürecinde, süreç performansı değerlendirilirken zorunlu olan hususlar performansa yazılmamalıdır. Örneğin, tüm maddelerin test edilmesi gibi zaten zorunlu olan şeyler performans değeri olamaz.
- SUP.1 Kalite Güvence Sürecinde, süreç performans kriterleri ölçülebilir değerler olmalıdır.
- Proje değerlendirme toplantısında her ne kadar yazılsa da her süreçle ilgili plan içerisine hangi tarihlerde gözden geçirileceği yazılmalıdır. (Riskler için risk yönetim planı, Doğrulama için doğrulama planına vb.)
- ENG.1 Gereksinim Toplama sürecinde, müşteri isterleri toplanırken yapılan toplantılara ait toplantı tutanakları, kanıt olması açısından, bulunmalıdır.
- Müşteri İster Dokümanının proje yönetim aracında (TFS, JIRA vb.) nasıl yer aldığı gösterilmelidir.
- Süreçlerde üretilen gereksinimler arasından bir izlenebilirlik kurulmalı ve gösterilmelidir.
- Müşteri gereksinimlerinden başlayarak birbirinin karşılığı olduğu detaylı olarak eşleştirilmelidir. (ENG.1 → ENG.4 → ENG.5 → ENG.6 gibi)
- Mühendislik süreçlerinde (ENG.x) sonuçların mutlaka her aşamada paydaşlarla paylaşılmalıdır. (Gereksinim dokümanı, tasarım dokümanı vb.)
- ENG.5 Yazılım Tasarımı ile ENG.6 Kodlama arasındaki ilişkiler gösterilebilmelidir. Bu ilişki bir tablo ile gösterilebilir. Tasarım ile versiyon kontrol aracı (Git, Svn, Cvs vs.) COMMIT numaraları eşleştirilmelidir. Proje yönetim aracı üzerinden de eşleşen numaralar gösterilebilir.
- Proje yönetim aracında (TFS, JIRA vb.) ye alan ilgili iş akışları gösterilebilmelidir. Ayrıca yazılım kodlarının versiyon kontrol aracına (Git, Svn, Cvs vb.) bağlanılarak COMMIT’ler gösterilebilmelidir.
- Regresyon testi yapıldığına dair örnekler gösterilebilmelidir.
- Proje yönetim aracında (TFS, JIRA vb.) yer alan iş akışında entegrasyon testleri, birim testleri ve regresyon testlerinin ayrı akışları olmalıdır.
- Proje yönetim aracında (TFS, JIRA vb.) sürüm yayınlama onayının olmalıdır.
- Konfigürasyon (yapılandırma) yönetim planında kodların ve doküman versiyonlarının doğrudan versiyon kontrol aracı (Git, Svn, Cvs vb.) üzerinden gösterilebilmelidir. Bunların proje planında öngörülen tarihlerle ve anahat (baseline) tarihleri (SUP.8- Konfigürasyon yönetimi planı) ile uyumlu olmalıdır.
- Tüm konfigürasyon öğeleri anahat (baseline) tarihleri itibariyle gösterilebilmelidir. Önceki anahat (baseline) öğeleri yedek (backup) üzerinden gösterilebilir.
- Konfigürasyon (yapılandırma) ve doğrulama ile ilgili en az birer adet toplantı tutanağı olmalıdır.
- Proje yönetim aracında (TFS, JIRA vb.) SUP.9 Problem Çözüm Prosedürüne göre oluşturulmuş problem kayıtları ve değişiklik kayıtları gösterilebilmelidir. Yazılım hatalarında bu kayıtların da iş akışından geçmiş olmaları gerekir. Yazılımlarda iş tipi “hata”, değişikliklerde iş tipi “değişiklik” olarak belirtilmelidir. Ayrıca her bir hatanın türü de (yazılım hatası vb.) belirtilmelidir.
- Problem yönetiminde açılan problemler için varsa DÖF kaydı gösterilebilmelidir.
- Problem ve değişiklik taleplerinin hangi gereksinim ile ilişkili olduğu gösterilebilmelidir
- Risk yönetim planında riskler için belirlenen renkler ile risk takip formunda yer alan risklerin renklerinin aynı olmalıdır.
- Risk yönetim planında yüksek riskler için ayrıca DÖF açılması gerektiği belirtilmelidir. Orta seviye riskler için gerekli durumlarda DÖF açılabilir şeklinde bir ifade eklenebilir.
- SPICE süreçleri için Kalite Güvence Uzmanı ve Genel Müdürün iç tetkik eğitimi almalıdır. İç tetkik eğitimine katılanların eğitim katılım formu iç tetkik klasöründe bulunmalıdır.
- İç tetkik formunda süreç sorumlusu, kontrol eden / denetimi yapan belirtilmelidir.
- İç tetkik sayısı birden fazla olmalıdır.