Ne zaman yeni bir yazılım geliştirme projesine başlarsam, müşterilerin ilk sorduğu sorular şudur: bu ne alacak? ve ne kadara mal olacak? Bunlar çok büyük iki sorudur ve normalde türetilmesi çok fazla sistem analizi çalışması gerektirir. Bu çeşitli şekillerde yapılabilir ve herkesin kendi tercihi vardır. Normalde, geliştirme çabasının birçok temel parçasını ortaya koyan bir proje kapsam belgesi hazırlarım.
Şimdiye kadar en büyük proje kapsam belgem 14 sayfaydı, ancak e-postalara güzel bir şekilde uyan küçük sayfalar da yaptım. Belgenin uzunluğu, büyük ölçüde uyguladığınız sistemin boyutuna ve karmaşıklığına bağlıdır. Gerekli bilgileri toplamak genellikle 3 saat ile 2 gün arasında sürer ve analiz için herhangi bir ücret talep etmiyorum. Bu, gereksinimlerin toplanması gibidir, ancak o kadar ayrıntılı değildir. Genelde kapsamı büyük ölçüde etkileyecek birkaç temel gereksinimi not ederim.
Bu analizi yaparken, şirkete en uygun mimarinin ne tür olduğunu toplamanız gerekir. Şirketin hızlı büyüme planları varsa, Nesneye Yönelik veya Hizmet Odaklı Mimari muhtemelen en iyisi olacaktır. Ayrıca geliştirme çabasını doğru bir şekilde tahmin etmek için birçok işlevsel gereksinimi toplayın. Ayrıca satış, sipariş, ürün, müşteri, vb. Gibi mümkün olduğunca çok ticari varlığı not alın. İşletme varlıkları, uygulama zamanında veritabanı tabloları ve sınıfları olarak kullanılacaktır. Projenin bu aşamasında bir teknoloji platformunun tanımlanması da sınırlandırılmıştır. Bu sağduyu olabilir, ancak bir Windows Forms uygulaması bir Linux işletim sisteminde iyi çalışmayacaktır. Tüm bu faktörler büyük ölçüde projenin kapsamını etkileyecektir.
Bir proje kapsam belgesinin temel amacı, müşterilerin projeye ilişkin görüşlerinin, danışmanlık şirketlerinin proje görüşü ile uyumlu olmasını sağlamaktır. Normalde, nihai belgeyi oluşturmadan önce müşteriyle iki veya üç taslak gözden geçiririm. Proje kapsam belgesi şunları yapmalıdır:
1. Seviye belirleyen proje beklentileri.
2. Zaman ve maliyetleri ele alın.
3. Üst yönetim ve diğer paydaşlara projenin neleri içerdiğine dair net bir anlayış sağlayın.
4. Yeni sistemin yerleşim riskleri ve faydaları.
İşte kullandığım genel format:
I. Proje Şartı
Proje adını ve amacını belirtir. Bu, projenin açıklamasını ve beklenen sonucu açıkça düzenlemelidir. Mevcut sistemler yeni sistemden etkilenecekse, etkilenen sistemleri bu blokta listeleyin. Ayrıca bu proje için seçilen teknoloji platformunu da belirtin. Son olarak, bu projeyi başarılı kılmak için ne gerektiğini sıralayın.
II. Proje Bağlamı
Bu bölümde mevcut sistemle ilgili problemleri belirtin. Ve yeni sistemin sorunları nasıl çözeceğini açıklayın.
III. Proje Beklentileri
Bu bölüm kapsamlı iş bilgisi gerektirir ve uygulamadan etkilenen tüm tarafların katılımını içerir. Organizasyon içindeki her departmandan tüm beklentileri listeleyin.
IV. Proje yaklaşımı
Başarılı bir uygulama sağlamak için kullanılacak metodolojileri ve yaklaşımları listeleyin. Ayrıca, her aşamada standart geliştirme yaşam döngüsünün nasıl kullanılacağını tanıtın.
V. Proje Riskleri / Ödüller
Burada proje uygulamasının risklerini ve ödüllerini listeleyin. Her riske veya ödüllendirmeye yüksek, orta veya düşük etki derecesi verin.
VI. Kaynak İhtiyaçları
Her rol için kısa bir açıklama ile birlikte ihtiyaç duyulacak rolleri tanımlayın.
VII. Maliyet
Her rol, geliştirme ortamı ve donanım için bir maliyet belirleyin.
VIII. Kilit Paydaş İmzası
Kilit paydaşları tanımlayın ve onayı alın.
Proje kapsam belgesinin projenin giriş kapısı olduğunu unutmayın, bu nedenle beklentilerin önceden belirlendiğinden ve sürpriz olmadığından emin olun. Lütfen benimle iletişime geçin ve bana ne düşündüğünüzü bildirin. Ayrıca şirketimin web sitesi sharpsoftwaresoltuions.com’u ziyaret edin.
GIPHY App Key not set. Please check settings