Farklar

Bu sayfanın seçili sürümü ile mevcut sürümü arasındaki farkları gösterir.

--- hiz.muh.01 [2016/05/24 16:34]
metin silindi
+++ — (mevcut)
@@ Satır 1: / Satır 1: @@
-====== GEREKSİNİM YÖNETİMİ SÜRECİ ======
-=====Süreç Politikası ve Hedefleri =====
-Bu sürecin uygulanma nedeni, müşterinin ihtiyaçlarını anlamak, onları sistematik bir şekilde toplamak, müşteri ihtiyaçlarını analiz ederek teknik yazılım/sistem gereksinimlerine dönüştürmektir.  Yazılım geliştirme süreci boyunca gereksinimlere gelen değişiklik istekleri yönetilir ve müşteri ihtiyaçlarıyla çözüm arasında izlenebilirlik sağlanır.
-  * Müşteri ve kullanıcılarla iletişim mekanizması oluşturulur.
-  * Geliştirilecek çözümün kullanıcıları tanımlanır.
-  * Müşteri ihtiyaçları ve yazılım gereksinimlerinin durumlarının takip edilebildiği, değişikliklerin yönetilebildiği bir sistem oluşturulur.
-  * Müşteri ihtiyaçları analiz edilerek fonksiyonel ve mimari gereksinimler üretilir.
-  * Kısıtlar ve varsayımlar ortaya konur.
-  * İhtiyaçlar, gereksinimler ve diğer konfigürasyon öğeleri arasında izlenebilirliğin sağlanabileceği bir sistem kurulur.
-  * Sistem mimarisinin oluşturulabileceği analiz modeli ortaya çıkar.
-  * Müşteri ihtiyaçları ve gereksinimler için temel oluşturulur ve konfigürasyon yönetim süreci işletilir.
-Bu sürecin etkin olması durumunda, müşteri ihtiyaçları hedeflenen zamanda doğru bir şekilde anlaşılmış, müşteriyle ve kullanıcıyla iyi bir şekilde iletişim sağlanmış, ihtiyaçlarla ilgili riskler yönetilebilmiş, proje başında yeni gereksinimler ve değişiklik istekleri fazlayken proje sonunda gereksinimlere gelen değişiklikler ve yeni istekler azalmış olmalıdır. Testten gereksinim kaynaklı dönen hata sayısı sürecin iyileştirilmediği zamana göre azalmış olmalıdır.
-=====Tanımlar ve Kısaltmalar =====
-**Gereksinim:** Ürünün, sistemin, servisin özelliklerini tanımlar.
-** GTD:** Gereksinim Tanımları Dokümanı
-=====Referanslar =====
-  * ISO 9000:2008
-  * TS ISO/IEC 15504-1
-  * TS ISO/IEC 15504-2
-  * TS ISO/IEC 15504-3
-  * TS ISO/IEC 15504-4
-  * TS ISO/IEC 15504-5
-  * TS ISO/IEC 15504-6
-  * TS ISO/IEC 15504-7
-  * CMMI v1.2
-=====Uygulama Kapsamı ve Uyarlama Koşulları =====
-Bu süreç projenin başlangıç aşamasından sonuna kadar devam eder. Başlangıç aşamasında iş yükü diğer aşamalara göre daha fazla ilerleyen aşamalarda daha azdır.  Proje başlangıcıyla süreç başlar.
-Süreç projelerde aynen kullanılabilir veya kalite güvence uzmanının onayı alınarak Proje Yönetim Planı ile proje gerekliliklerine göre uyarlanabilir. Bu durumda Proje Yönetim Planı değiştirilecek/uygulanmayacak maddeleri tam olarak tarif etmelidir.
-•Müşteri gereksinimleri elde etme ve analiz teknikleri projeden projeye farklılık gösterebilir. Hangi yöntem kullanılırsa kullanılsın analiz modeli
-  * İş kuralları
-  * İş akışı
-  * Alternatifi kullanım senaryoları
-  * Modelin sağlama kriterlerini oluşturmalıdır.
-•İzlenebilirlik için otomasyon araçları kullanılabilir. Kullanılacak araçlar ve kullanma yöntemleri proje yönetim planlarında belirtilmelidir.
-•İzlenebilirlik matrisi formu proje ihtiyaçlarına göre detaylandırılabilir. En az
-  * Analiz
-  * Tasarım
-  * Test
-  * Gerçekleştirim
-Konfigürasyon maddeleri arasında izlenebilirliği içermelidir.
-===== Roller,Sorumluluklar ve Yetkiler =====
-**Sistem Analisti:** Müşteri ihtiyaçlarını almak ve analiz etmekten sorumludur. Proje yöneticisiyle birlikte müşteri ile olan iletişimi ve değişiklik mekanizmasını sağlar.
-**Test Uzmanı:** Gereksinimlerden test durumlarını ortaya çıkarır, gereksinimlerin doğrulanması aktivitelerine katılır. Yeni ve değişiklik isteklerinin test durumları üzerindeki etkisini yönetir.
-**Konfigürasyon Yöneticisi:**  Gereksinimlerin sürümlerini ve gelen değişiklik isteklerini yönetmek, sürüm planlarını çıkarmak ve izlenebilirliği sağlamaktan sorumludur.
-**Proje Yöneticisi:** Projedeki gereksinim yönetim aktivitelerini planlamak, müşteri ve proje ekibiyle iletişim sağlamak, müşteriye gereksinimlerin durumunu bildirmek, değişiklik isteklerinin ve yeni isteklerin etki analizlerin müşteriyle müzakere etmekten sorumludur.   Gereksinimlerin projeye maliyetine göre gereksinimlerin gerçekleştirilmesini onaylar ya da onaylamaz.
-**Tasarım ve Yazılım Geliştirme Uzmanı:** Gereksinimlerden sistem mimarisini ve tasarımı oluşturur. Gereksinimleri, çözüm açısından teknik yapılabilirlik açısından değerlendirir.  Yeni gereksinimlerin ve değişiklik isteklerinin tasarım ve sistem mimarisi üzerinde yarattığı riski analiz eder.
-**Müşteri:** Ortak teknik gözden geçirme toplantılarına katılmaktan, gereksinimleri belirleyip geçerliliğini kontrol etmekten ve kabul aşamasında müşteri kabul testlerini yapmaktan sorumludur.
-**Kalite Güvence Uzmanı:** Sürecin tanımına uygun yürütüldüğünü kontrol etmekten, müşteriye ve proje ekibine süreçle ilgili destek vermekten sorumludur. Metrikleri toplamak ve değerlendirmekten sorumludur.
-**Proje ekibi:** Gereksinim analizi aşamasına destek vermekten ve doğrulama aktivitelerini gerçekleştirmekten sorumludur.
-=====Sürecin Tedarikçi ve Müşteri Süreçleri=====
-==== Tedarikçi ====
-  * Proje Yönetimi Süreci (HIZ.DES.06)
-  * Tasarım Süreci (HIZ.MUH.02)
-  * Test Süreci (HIZ.MUH.05)
-  * Doğrulama Süreci (HIZ.DES.01)
-  * Geçerleme Süreci(HIZ.DES.02)
-  * Satış Süreci(HIZ.MUS.02)
-====Müşteri ====
-  * Tasarım süreci (HIZ.MUH.02)
-  * Proje Yönetim Süreci (HIZ.DES.06)
-  * Konfigürasyon Yönetim Süreci (HIZ.YON.02)
-  * Test Süreci (HIZ.MUH.05)
-  * Doğrulama Süreci (HIZ.DES.01)
-  * Geçerleme Süreci (HIZ.DES.02)
-===== Girdiler =====
-  * Şartname
-  * Müşteri ihtiyaçları
-  * Proje yönetim planı (HIZ.YON.02)
-  * Değişiklik İstekleri (FRM.06)
-  * Problem Raporları (FRM.07)
-  * Yazılım Tasarım Tanımları (RPR-30-YTT)
-======Uygulama ve İş Akışı ======
-=====Analiz Aşamasının Planlaması =====
-Projede analizle ilgili roller ve sorumluluklar, zaman planı, dönüm noktaları, kullanılacak yöntem ve araçlar planlanır. Bu planlama seçilen proje yaşam döngüsüne uyumlu olarak yapılır.  Analiz aşaması ile ilgili planlar proje yönetim planının teknik süreç planlama kısmında dokümante edilir. Bu aşamada analiz toplantıları, ilgili kullanıcılar, gereksinimlere onay verecek müşteri yetkilileri belirlenir.
-Geliştirilen yazılım projesi birden fazla alt projeden oluşuyorsa ya da eş zamanlı geliştirilen diğer projelerle entegre çalışacaksa, alt sistemlerin gereksinimleri diğer alt proje gruplarıyla paylaşılır. Bunun koordinasyonu planlama aşamasında proje yöneticisi ve diğer alt sistem yöneticileriyle birlikte yapılır. Proje gruplarının iletişimi ve bilginin paylaşımı sağlanır.
-Gereksinimler oluşmaya başladıkça proje kapsamı detaylanır. Proje yöneticisi gereksinimlerle var olan iş paketlerinin tutarlılığını kontrol eder. Değişiklik yönetiminde yapılan etki analizi kapsamı da göz önünde bulundurur
-=====Müşteri/Kullanıcı Gereksinimlerinin Alınması =====
-Bu aşamada, ilgili proje ekibi müşteri ihtiyaçlarıyla ilgili araştırma yapar. Sistem kullanıcıları, ortaya çıkacak sistemin kullanıcılara sunacağı hizmet ve var olan yapı incelenir. Müşteri gereksinimlerini şartnameyle belirtmiş olabilir. O zaman gereksinimlerin ve beklentilerin tespiti şartnamenin incelenmesiyle başlar. Şartname incelenerek belirlenen gereksinimler idarenin de onayıyla belirli bir plan dâhilinde gerçekleştirir. Müşteri şartlarının oluşmasında şartname göz önünde bulundurulur. (Bakınız RPR-023) Bunun dışında,
-  * Müşteri/kullanıcı toplantıları
-  * Var olan ürünlerin incelenmesi
-  * Yasa, yönetmelik, ilgili standartların incelenmesi
-  * Benzer ürünlerin incelenmesi
-  * Kullanıcı anketleri gibi teknikler de kullanılarak gereksinimler ve sonradan ortaya çıkabilecek ihtiyaçlar tespit edilmiş olur.
-Müşteri toplantılarında gereksinimlerin haricinde gerçekleştirilecek çözümü ilgilendiren kısıtlar ve kabul kriterleri de ortaya çıkar.
-Müşteri toplantılarına gidilmeden analiz edilecek konuyla ilgili araştırma yapılır. Toplantı zamanları ve katılımcıları ile ilgili planlama yapılır. Toplantılarda notlar toplantı tutanağıyla kaydedilir ve katılımcılara onaylatılır.
-Müşteri toplantılarından sonra notlar incelenir. Belirsizlikler ve çelişkili noktalar ile ilgili taraflara geri dönüş yapılır. Müşteri toplantısı sonuçları kesin hale getirilir.
-=====Gereksinimlerin Analiz Edilmesi ve Ürün Gereksinimlerinin Oluşturulması =====
-Müşteri gereksinimleri alındıktan sonra detaylandırılır. Gereksinimlerle ilgili kullanım senaryoları oluşturulur. Kullanım senaryolarında hata akışları da test edilir. Birbirini etkileyen gereksinimler belirlenir. İş kuralları ortaya çıkarılır. Proje ilerledikçe gereksinimlerle ilgili detaylar ortaya çıkar. Gereksinim analizi, tasarım ve gerçekleştirim aşamaları eş zamanlı yürütülebilir. Alınan tasarım kararları gereksinimleri etkileyebilir ya da yeni gereksinimler doğmasına sebep olabilir. Analiz aşamasında bunlar da belirlenir.
-Analiz aşamasında
-•İşlevsel
-•Mimari
-  * Güvenlik
-  * Güvenilirlik
-  * Performans
-  * Kullanım kolaylığı
-  * Bakım kolaylığı
-  * Arayüz
-Gereksinimler ile arayüz gereksinimleri ortaya çıkar. Analiz modeli oluşturulurken UML, BPML, SysML ya da diğer notasyonlardan faydalanılabilir. Hangi standart kullanılacaksa proje yönetim planında, analiz aşaması başlamadan karar verilmiş olmalıdır.
-Gereksinimler analiz edildikçe ortaya çıkan sistemin mantıksal bileşenleri ya da modülleri belirlenir. Sistemin genelinin analizi tamamlandıktan sonra her bir modülün gereksinim analizi ayrı ayrı devam edebilir. Bu durum analizin planlanması aşamasında belirtilmelidir.  Daha sonradan belirlenmişse plan güncellenir.
-Analizi tamamlanıp ürün gereksinimlerine dönüştükçe Gereksinim Tanımları Dokümanı oluşturulmaya başlanır. Bu doküman gereksinimler değiştikçe güncellenir.
-=====Arayüz Kısıtlarının ve Gereksinimlerinin Belirlenmesi =====
-Geliştirilecek yazılımın çalışacağı ortamın, birlikte çalışacağı diğer yazılımların, entegre olacağı diğer sistemlerin ihtiyaçları ve onlarla ilişkisi analiz ve tasarım aşamasında göz önünde bulundurulur. Analiz aşamasında ortaya konan arayüz gereksinimleri, tasarım aşamasında çözüm için modellenir.
-=====Gereksinimlerin Geçerleme ve Doğrulama İşlemlerinin Yapılması =====
-Geçerleme ve doğrulama işlemlerinin hepsi için gözden geçirme terimi kullanılacaktır. Müşterinin onayının alındığı, doğru ürünün yapıldığının onaylandığı işlemler doğrulama işlemidir. Doğrulama işlemi müşteriyle yapılan gözden geçirme şeklinde anlatılacaktır.
-Proje planında belirlenen yaşam döngüsüne uygun olarak gözden geçirme faaliyetleri planlanır. Mühendislik süreçleri ürünlerine yapılan gözden geçirmeler teknik gözden geçirmedir.
-Gereksinimler, proje ekibi ya da dışarıdan bağımsız bir analiz uzmanı tarafından Gözden Geçirme kriterlerine göre gözden geçirilirler. Bu kriterlerle alınan gereksinimlerin kaliteli ve doğru bir şekilde oluşturulduğu sınanır. Gereksinimler,
-  * Tutarlı
-  * Tam
-  * net
-  * Kullanılan notasyona uygun
-  * Test edilebilir olma gibi çeşitli kriterlere göre gözden geçirilirler. Gözden geçirme kayıtları oluşturulur. Doğrulama sürecinde gözden geçirme detaylandırılmıştır.
-Tasarım ve gerçekleştirim aşamasına geçilmeden doğru gereksinimlerin doğru şekilde alındığını doğrulamak için gereksinimler müşteri onayına sunulur. Müşteri onayı için prototiplemeden faydalanılır, ayrıca toplantı tutanaklarıyla oluşan müşteri gereksinimleri müşteriye de onaylatılır.
-Bunun haricinde gelen değişiklik istekleriyle güncellenen ya da yeni eklenen gereksinimlerin oluşturulan sistem mimariyle çelişkisiz olduğu ya da oluşabilecek riskler analiz edilir.
-Oluşan Gereksinim Tanımları Dokümanı projenin belirlenen aşamalarında güncellenerek müşteriye sunulur ve yazılı onayı alınır. Gereksinim Tanımları Dokümanı, projenin seçilen yaşam döngüsüne göre analize ayrılan sürenin sonu gelmeden parça parçada müşteriye sunulabilir. Bu durum teknik süreç planında açıklanır ve onay yöntemi müşteriye sunulur ve onayı alınır.
-=====Gereksinimlerin Ana Hatta Alınması ve Değişikliklerin Kontrolü =====
-Müşterinin onayını alan gereksinim tanımları konfigürasyon yönetimi kapsamında versiyonlanır ve ana hatta alınır. Ana hatta alınmış gereksinimler e gelen değişiklikler değişiklik isteği akışına göre yönetilir. Ana hatta alınan gereksinimler gereksinim yönetim aracında yönetilebilir. Aynı zamanda Gereksinim Tanımları dokümanı oluşturularak doküman halinde de saklanır. Temel alındıkça Gereksinim Tanımları dokümanı güncellenir.   Değişiklik isteği akışı ve kullanılacak araçlar proje yönetim planı ya da konfigürasyon yönetim planında proje ekibi ve müşteriyle paylaşılır. Değişiklik isteği ve konfigürasyon yönetimi ile ilgili detaylı bilgi Konfigürasyon Yönetimi sürecinde verilmiştir.
-=====İzlenebilirlik =====
-Projede proje yöneticisi ya da konfigürasyon sorumlusu tarafından izlenebilirlik matrisi (FRM.01) oluşturulur. FRM.01, gereksinimlerden, kod ve test sonuçlarına kadar takip mekanizmasını sağlar. Fakat bu form, projelerde pratiklik açısından otomasyona geçirilmeli, izlenebilirlik rapor şeklinde çekilebilmelidir. Form proje ihtiyaçları çerçevesinde uyarlanabilir. İzlenebilirlik matrisinden, konfigürasyon yönetimi sürecinde etki analizi yapılırken faydalanılır. Gereksinimlerin ne kadarının test edildiğini raporlamak ve yapılan değişikliklere bağlı olarak hangi testlerin tekrarlanması gerektiğini belirlemek için kullanılır. Şartname, gereksinimler, tasarım çıktıları, kod, dokümantasyon, test sonuçları ve test raporlarıyla çift taraflı izlenebilirlik kurulur. Analiz modelinin gereksinimleri sağladığı ve proje sonunda açıkta kalan şartname maddesi olmadığı kontrol edilir.
-Eğer proje birden fazla alt projenin entegrasyonundan oluşuyorsa ve bunların gereksinimleri ayrı ayrı analiz edilmişse o zaman izlenebilirlik yatay seviyede gereksinimler arasında da kurulur. Tüm gereksinimler şartname ya da müşteri ihtiyaçları dokümanıyla ilişkilendirilir. Dikey seviyedeyse tüm gereksinimler mimari ile tutarlılıkları açısından analiz edilir ve tasarım modeliyle izlenebilirlikleri sağlanır. Ayrıca değişiklik istekleriyle gereksinimler arasında izlenebilirlik kurulacaktır ve değişiklik istekleri değerlendirildikten sonra uygulamaya konulacaktır.
-İzlenebilirlik için kullanılacak araç ve ilgili versiyonlama sistemi proje dokümanlarında anlatılır.
-Gerçekleştirilen gereksinim toplantıları toplantı tutanaklarıyla kayıt altına alınır. Gereksinimler için yapılan gözden geçirme işlemleri kayıt altına alınır. Eğer işlemler mail, elektronik ortamda yapıldıysa mailler konfigürasyon yöneticisi sorumluluğunda kayıt altına alınır.
-İlgili aktivitelerin yapılma yöntemleri farklılık göstereceğinden proje yöneticisi proje yönetim planında ilgili yöntemleri, zaman, rol ve sorumluluk bilgilerini açıklar.
-=====Test Planının ve Test Durumlarının Oluşturulması  =====
-Test durumları için girdiler analiz modelinin oluşmaya başlamasıyla ortaya çıkar. Test durumları, analiz aşamasından entegrasyon aşamasının sonuna kadar güncellenerek oluşturulabilir. Kullanılan yazılım yaşam döngüsüne göre test durumlarının hazırlanmaya ne zaman başlanacağı proje yönetim planında ya da test planında belirtilir. Test durumları için girdiler çoğunlukla analiz modelinden kaynaklanır. Kullanım durumunda yer alan senaryolar test durumlarının da senaryosunu oluşturur. Analizde ortaya çıkan modelin tüm işlevselliklerinin ve diğer özelliklerinin kodlama aşaması sonucunda oluşan üründe bulunduğu bu şekilde sağlanmış olur.
-=====Sistem/Yazılım Mimarisinin Oluşturulması =====
-Gereksinim yönetimi süreci sonucunda ortaya çıkan gereksinim tanımları sistem/yazılım mimarisinin oluşturulması için girdidir. Sistem mimarisinin oluşturulmasıyla ilgili ayrıntılı bilgi HIZ.MUH.02 Tasarım sürecinde açıklanmıştır.
-======Çıktılar ======
-  * Gereksinim Tanımları Dokümanı (RPR-004-GTD)
-  * Analiz modeli
-  * Toplantı Tutanakları
-  * Yazılım Tasarım Tanımları (RPR-030-YTT)
-  * Müşteri ihtiyaçları
-  * Gereksinimlerin İzlenebilirlik Matrisi (FRM.01)
-  * Test Durumları (RPR-024-TDD)
-  * Test Planı (RPR-025-TP)
-======Eğitim, İnsan Kaynakları ve Altyapı İhtiyaçları ======
-Sistem analisti:
-  * Gereksinin Yönetimi
-  * Analiz teknikleri
-  * Prototipleme ve Gözden Geçirme Kriterleri
-  * UML, BPML ya da kullanılacak diğer modelleme notasyonlarını
-  * Yazılım Geliştirme Yaşam Döngüsü
-  * Konfigürasyon Yönetimi
-  * Proje Yönetimi
-  * Tasarım
-  * Araçlar
-Hakkında bilgi sahibi olmalıdır. Projenin diğer üyeleri de aynı konular hakkında bilgi sahibi olmalı ve süreçlerin birbirine ve projeye etkisini bilmelidir. Bunun için tüm proje ekibine proje başlangıcında projede kullanılacak yöntemler, araçlar ve iş akışı hakkında bilgilendirme eğitimi verilmelidir.
-Gereksinim yönetimi için gereksinim yönetimi araçlarından faydalanılabilir. Projeler hangi aracı kullanacaklarsa proje yönetim planı ya da ilişkili planlarında bunu belirtmelidirler. Proje başlangıç aşamasında altyapının hazır olması gerekir.
-======Kayıtların Kontrolü ve Saklanması ======
-Gereksinimlerin, gereksinim tanımları dokümanının, ilgili gözden geçirme ve toplantı kayıtlarının proje sitesinde yapılır. Bütün çıktılar sürüm kontrolüne alınır, gereksinim tanımları için temel oluşturulur. Proje yönetim planında aksi belirtilmedikçe proje kayıtları FTP sunucusunda saklanır.
-====== Süreç Performansının Kontrolü ve İyileştirilmesi  ======
-Gereksinim yönetim sürecinin kontrolü projelere yapılan iç denetimlerle yapılır. Ortaya çıkan düzeltici ve önleyici faaliyet istekleri incelenerek süreç performansı değerlendirilir. Eğer düzeltici faaliyetlerin oranı yapılan denetimlere ve soru sayılarına göre yüksekse projede süreç uygulanmıyor olabilir. Bu durumda projede gereksinim yönetim performansını değerlendirmek mümkün olmaz. Bu durumda sürecin neden uygulanmadığı araştırılır.
-Düzeltici faaliyetler az ve süreç uygulanıyorsa, bu durumda veri toplanarak sürecin performansı değerlendirilir. Süreç etkin uygulandığı durumda, gereksinimlerin değişkenliği azalmış, proje sonunda gelen değişiklik istekleri ve yeni istekler kalmamış, müşteri memnuniyeti yüksek, kullanıcı testlerinden gereksinimlerle ilgili dönen hata sayısının minimum olması gerekir.  Bu azlık, çokluk değerleri proje aşamalarında ya da geçmiş projelere bakılarak ya da projenin şartnamesine ve proje ekibinin kararına göre proje planlama aşamasında belirlenir ve ölçüm planına yansıtılır.
-Süreç performansı, veriler yıllık olarak tüm süreçlerden alınarak kalite grubu tarafından değerlendirilir ve kalite yönetim sistemi performans raporuna yansıtılır. Bu raporda süreçlerle ilgili iyileştirme önerileri sunulur. Yönetim kurulu, proje yöneticileri, kalite ekibi iyileştirme önerileri için önceliklendirme yapıp plan hazırlarlar. Öncelik verilen süreçler veya hedefler için süreç iyileştirme çalışması başlatılır ve takip edilir. Bu çalışmanın sonunda değerlendirme yapmak için sağlıklı veri bulunmadığı yorumu da çıkabilir. O zaman verilerin doğru değerlendirilebilmesi için metrik toplamaya devam edilmesine ve sürecin izlenmesine karar verilir.

Bilgi Merkezi

Kullanıcı Aletleri

Site Aletleri

Farklar

Sayfa Aletleri