Kullanıcı Aletleri
hiz.muh.01
Farklar
Bu sayfanın seçili sürümü ile mevcut sürümü arasındaki farkları gösterir.
| Sonraki sürüm | Önceki sürüm | ||
|
hiz.muh.01 [2016/04/14 14:41] root oluşturuldu |
— (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. | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
hiz.muh.01.1460634088.txt.gz · Son değiştirilme: 2018/11/28 19:47 (Dışarıdan düzenle)
Sayfa Aletleri
