Çaba Aralığı

 Çaba Aralığı

Konu Alanı Çaba Aralığı, projeye göre tamamlanması için gereken kısa, uzun ve ortalama eforlu günlerin uzunluğuna sahiptir. Kısa, uzun ve ortalama, esas olarak veri modelleyiciye ne kadar yüksek kaliteli bilgi sağlandığı ve veri modelleyici dahil tüm proje ekibinin ne kadar deneyimli olduğu ile belirlenir.

Genel olarak, güvenli oynamak için ortalama veya yüksek aralıklı miktarı seçin. Süre miktarları konu alanına göre verilir. Konu alanları, proje planındaki erken görevlere karşılık gelir.

Ne yazık ki, geçerli bir tahminde bulunmak için konu alanlarının tam listesine ihtiyaç duyduğunuz, ancak konu alanlarını elde etmek için projeye başlamanız ve görevlerin konu alanı analiz bölümünü tamamlamanız gereken bir Catch-22 durumu olabilir. En azından plandaki konu alanı görevlerini yerine getirmeleri için genellikle bazı başlangıç fonlarını tavsiye ederim; bu, tahminin doğruluğuna yardımcı olabilir ve sonuçta ortaya çıkan proje planından biraz zaman alabilir.

Üzerinde çalıştığımız tüm uygulamalar şu proje türlerinden birine uymalıdır: yeni bir operasyonel uygulama, yeni paket yazılım, yeni data mart, operasyonel geliştirme veya data mart geliştirme. Yeni bir operasyonel uygulama, sıfırdan inşa edilen uygulamadır. Örnekler arasında yeni bir sipariş işleme veya iletişim yönetimi uygulaması yer alır.

Yeni operasyonel uygulamalar genellikle tüm yeni uygulamalar arasında en az zamanı alır, çünkü tasarım açısından, fiziksel modeliniz mantıksal yüksek düzeyde normalleştirilmiş modelinize çok benzer olacaktır.

Tasarımınızı 5NF’ye aldıktan sonra, fiziksel veri modelini ve müteakip veritabanı tablolarını oluşturmak için yalnızca küçük değişiklikler olacaktır. Son zamanlarda şirketlerdeki eğilim, diğer şirketlerden büyük operasyonel uygulamaları satın almak ve yalnızca küçük ölçekli (belki departman düzeyinde) uygulamalar oluşturmak olmuştur.

Eksiksiz geliştirme ve uygulama açısından bakıldığında, bu paketler konu alanı başına özelleştirilmiş bir çabadan daha az zaman alabilir. Bununla birlikte, veri modelleme açısından bakıldığında, paket yazılımın analizi çok daha fazla zaman alabilir.

Bunun nedeni, paket yazılım içindeki jenerik yapıları anlamanız ve şirketinizin veri gereksinimlerini bu jenerik yapıya eşleme ek görevine sahip olmanız gerekmesidir. Bu nedenle, sıfırdan veri modelleri oluşturmak zorunda olmamanıza rağmen, yine de tutarlı ve doğru olması gereken devasa haritalama göreviniz var. Bu nedenle, veri modelleme görevlerini tahmin ederken paket yazılım genellikle biraz daha uzun sürer.

Yeni bir data mart tasarlamak, yeni bir operasyonel uygulama tasarlamaktan biraz daha fazla çaba gerektirir çünkü veri modelleyicinin raporlama gereksinimlerini analiz etme gibi ekstra görevleri vardır. Tasarımdaki her olgu veya ölçüm için, veri modelleyicinin referans verisi veya boyutluluk raporlaması düzeylerini yakalaması gerekir. Bu ekstra gereksinimler, plana zaman ekler.

Operasyonel ve data mart geliştirmeleri, geliştirmelerin kapsamına bağlı olarak oldukça geniş bir zaman aralığına sahiptir. Örneğin, mevcut bir tabloya yeni bir veri öğesi eklemek, bir modele birkaç yeni varlık eklemekten daha az veri modelleme çabası gerektirecektir. Data mart geliştirmeleri, veri modelleyici için gereken ek raporlama görevleri nedeniyle operasyonel olanlardan biraz daha uzun sürebilir.

En az çaba yasası Örnekleri
En az çaba yasası Türkçe
Dilde en az çaba yasası
Çabaçam nedir
ÇABAÇAM Çanakkale
ÇABAÇAM adres
ÇABAÇAM Başvuru

Görev Çaba Aracı

Görev Çaba Aracı, bulduğumuz görevlerin her birini alır ve onlara bir yüzde atar. Projenizi seçtiyseniz, görevlerin her biri için ne kadar zaman gerektiğini bulmak için bu sayıyı yüzde ile çarparsınız.

Bu araçta raporlama ve operasyonel faaliyetler için ayrı sütunlar bulunmaktadır. Raporlama sütunlarının, raporlama düzeylerinin belirlenmesini içeren iki analiz görevine yüzdeler atadığını fark edeceksiniz: Konu alanına göre raporlama düzeylerini belirleyin ve raporlamanın olgu düzeylerini belirleyin.

Bu analizi önceden yapmak, fiziksel veri modelleme aşamasında daha az zaman harcanmasını sağlar çünkü rapor tasarımının nasıl görünebileceği konusunda zaten çok iyi bir fikriniz vardır. Bir yıldız şeması veya bir yıldız şemasının bir varyasyonu olacaktır. Bu nedenle raporlama uygulamalarında fiziksel veri modelleme aşaması daha kısa sürer.

Operasyonel sütun, daha önce bahsedilen iki raporlama görevi için açıkça zaman gerektirmez. Nihai tasarımın nasıl görünebileceği konusunda henüz iyi bir fikir sahibi olmadığımız için, fiziksel veri modellemesi sırasında uygun olan yerlerde normallikten çıkmak için daha fazla zaman gerekecektir. Mantıksal tasarıma çok yakın olabilir; ancak muhtemelen modelin katlanır masalar için dikkatle incelenmesi gereken bölümleri olacaktır.

Fiziksel olan mantıksal olanla hemen hemen eşleşecekse, çalışmanızı kontrol etmek için ekstra zamanı kullanın ve modelin daha sonra geliştirme aşamasında sıcak noktalar haline gelebilecek alanlarını arayın. Başka bir deyişle, ekstra zaman proaktif olmak ve gelecekte tasarımın yeniden yapılmasını önlemek için kullanılabilir. Bu nedenle, operasyonel uygulama için normalleştirilmiş bir veri modeli oluşturmak için ekstra çaba harcanır.

Unutmayın, projeniz yeni bir uygulama ile bir geliştirmenin bir kombinasyonunu içeriyorsa, işgücünü bu iki parçaya ayırmanız, her birine tahmin yaklaşımını uygulamanız ve ardından toplam işgücü için bunları bir araya getirmeniz gerekir. Bu durum, yeni bir data mart oluşturduğumuzda ve veri ambarı mimarisine yeni bir kaynak sistemi eklediğimizde veri ambarı alanımızda yaygındır.

Uygulamada Tahmin Aracı

Bu parçaları bir araya getirmek için, yeni bir uygulama ve geliştirmeyi tahmin etme örneğini inceleyelim. Yeni uygulamalar için, özel yapım yeni operasyonel uygulamalarımız veya data mart’larımız veya yeni paketlenmiş operasyonel uygulamalarımız veya veri ambarlarımız var. Mevcut uygulamalardaki geliştirmeler için, yeni bir paketlenmiş yazılım parçasına özelleştirme dahil olmak üzere mevcut bir operasyonel uygulamaya veya veri pazarına yönelik yeni işlevlere sahibiz.

Ayrıca mevcut veri ambarı mimarisinde geliştirmelerimiz var. Bu tahmin yaklaşımını göstermek için, yeni bir uygulama için mevcut bir mimari içinde yeni bir veri pazarı oluşturmayı seçeceğiz. Bu bize hem yeni uygulama hem de geliştirme tahmini yaklaşımı hakkında bir fikir verecektir.

Mevcut bir operasyonel uygulama için bir geliştirme seçeceğiz. Her proje türünden bir örnek üzerinden gidebiliriz; ancak, bu iki örneği inceleyerek, bu araçları herhangi bir proje türü için rahatça kullanabilirsiniz.

akademi222 takımı

Biyografinin Tamamını Gör