Vizör Çözümleri


Destek
Kaydol
Giriş Yap
Ücretsiz Deneme başlat

Gereksinim Kalitesi Nasıl Ölçülür?

Projenin başarılı olması için gereksinimler kaliteye sahip olmalıdır. Ekipler, standartlar ve koşullar belirleyerek bu hedeflere ulaşma yolundaki ilerlemelerini değerlendirebilir. Kullanılan metrikler, yapılan işe bağlı olarak farklılık gösterecektir; ancak, izleme gereklilikleri için bazı genel göstergeler şunları içerir:

  • Test Kapsamı – Her sistemin işlevlerinden kaç tanesi test edildi?
  • Değerlendirme Doğruluğu – Spesifikasyonlarda yüksek derecede doğruluk var mı?
  • İşlevsellik Tamlığı – Tüm işlevsellik alanları yeterli ayrıntıda belirtilmiş mi?
  • Kabul Kriterleri Netlik – Kullanıcı kabul kriterleri belgelerden kolayca belirlenebilir mi?
  • Değişiklik İstekleri – Şartname yazıldığından bu yana kaç değişiklik talebi yapıldı?

Bu niteliksel faktörleri düzenli olarak ölçerek, ekibinizin çabalarını nereye odaklaması gerektiğini belirleyebilecek ve projelerinizin kalitesini iyileştirebileceksiniz.

Gereksinim Kalitesi Nasıl Ölçülür?

İçindekiler

Gereksinimlerin Kalitesini Değerlendirmek Neden Önemli?

  • Yetersiz kaynaklarımızı tatmin edici kaynaklara dönüştürmek için gereken çaba miktarını doğru bir şekilde hesaplamak için öncelikle bir ihtiyaç sorunumuz olup olmadığını ve bunun ne kadar büyük bir sorun olduğunu belirlememiz gerekir.
  • Gözetmenler olarak, bir gereksinim spesifikasyonu oluştururken veya bir gereksinim analizi yürütürken ekibimizin verimli bir şekilde çalışmasını sağlamaya çalışıyoruz. Amaçlarına ulaşıyorlar mı?
  • Çeşitli senaryoları göz önünde bulundurarak, bir kriter kalite metriğinin değeri açısından gereksinim spesifikasyonlarımız için bir kıyaslama noktası oluşturduk. Sırasıyla her bir durumu yansıtmak için dört değer belirledik:
    • Zor bir ortamda özgün bir roman yaratmak kolay bir iş değil.
    • Herhangi bir baskı veya sınırlama olmaksızın yenilikçi bir anlatı hazırlamak.
    • Sıradan gelişme
    • Gelişimsel olmayan öğelerin edinimi
  • Projelerimizde en yüksek kaliteyi sağlamak için, Sistem Gereksinimleri İncelemeleri ve Yazılım Gereksinimleri İncelemeleri girişleri için bir kıyaslama noktası oluşturuyoruz.

Mühendislik ölçütleri söz konusu olduğunda, gereksinim kalite ölçütü mevcut en güçlü araçlardan biridir. Sonuçta, tarihsel olarak konuşursak, başlangıçta amaçlanandan farklı bir şey geliştirmek, mühendisler için ortak bir sorun olmuştur. Objektif bir standart kullanmak her seferinde mükemmel sonuçları garanti etmese de nihai üründeki potansiyel riskleri ve kusurları büyük ölçüde azaltabilir.

Ürün boyutu

Bir projedeki gereksinimlerin sayısını anlamak çok önemlidir. Bu, kullanım senaryoları, işlevsel gereksinimler, kullanıcı hikayeleri, özellik açıklamaları, olay-yanıt tabloları veya analiz modelleri aracılığıyla gerçekleştirilebilir. Bununla birlikte, ekibinizin bu gereksinimleri temsil etme seçimi, hiçbir şekilde birincil işlevlerini etkilemez - belirli koşullara ve işlevsel gerekliliklere dayalı sistem davranışlarını uygulama.

Gereksinim değerlendirme sürecinize, bir ürün sürümüne veya geliştirme yinelemesine tahsis edilen bireysel işlevsel gereksinimleri sayarak başlayın. Farklı kişiler saydıklarında benzer sonuçlar alamıyorlarsa, gelecekte ortaya çıkabilecek diğer yanlış anlamaları ve belirsizlikleri hesaba katmak önemlidir. Ekibinizin ilerleyişini doğru bir şekilde izlemek için bir sürümü oluşturan gereksinimlerin sayısının farkında olmanız gerekir. Bu bilgi olmadan, projeyi ne zaman bitireceğinizi ölçmenin hiçbir yolu olmayacak! Birikmiş iş listenizde hala ne kadar iş kaldığına dikkat etmek, herkesin tamamlanmadan önce ne olması gerektiğini anlamasını sağlar.

İşlevsel gereksinimlerinizin sistem boyutunun doğru bir ölçüsü olduğundan emin olmak için analistlerin bunları tutarlı bir ayrıntı düzeyinde oluşturması çok önemlidir. Bunu yapmanın harika bir yolu, üst düzey gereksinimleri tek tek test edilebilecek daha küçük alt bileşenlere ayırmaktır. Başka bir deyişle, test uzmanları, her gereksinimin doğru bir şekilde uygulanıp uygulanmadığını tespit edecek basit testler tasarlamalıdır. Bu, tüm görevlerin karmaşıklığına bakılmaksızın aynı miktarda uygulama ve test çabası gerektirmesini sağlar. Geliştiricilerin ve test edicilerin her gereksinimi uygun şekilde uygulayabilmelerini ve test edebilmelerini sağlamak için kaç tane alt gereksinim olduğunu takip etmek önemlidir. Diğer alternatif boyutlandırma yöntemleri arasında, tümü özellikle tanımlanmış bir işlevsellik parçası için gereken tahmini çabayı ölçen kullanım senaryosu noktaları ve hikaye noktaları yer alır.

İşlevsel gereksinimler temel olmakla birlikte, işlevsel olmayan gereksinimler de göz ardı edilemez. Bu özel talepler, etkili bir şekilde tasarlamak ve uygulamak için artan miktarda çaba gerektirir. Bazı işlevler, işlevsel özellikler için tahmini boyutta temsil edilmesi gereken güvenlik endişeleri gibi listelenen işlevsel olmayan ihtiyaçlara bağlıdır. Ancak, işlevsel olmayan tüm arzular burada görünmeyecek—onların tahmininiz üzerindeki etkilerini dikkate aldığınızdan emin olmak çok önemlidir! Aşağıdaki durumları göz önünde bulundurun:

  • Belirli bir özelliği kullanmak için birden fazla yol sağlamak, kullanıcı deneyimini geliştirir; ancak böyle bir girişim, geliştiriciler için yalnızca tek bir erişim yönteminin mevcut olduğu duruma göre daha fazla zaman ve enerji gerektirir.
  • Yeni ürün özelliklerini uygulamıyor olsanız bile, mevcut bir işletim ortamına uyması için harici arabirimler gibi zorunlu tasarım ve uygulama kısıtlamaları, gereken arabirim işi miktarını önemli ölçüde artırabilir.
  • Maksimum performansı sağlamak için, hızlı yanıtları garanti etmek için titiz algoritma ve veritabanı tasarım çalışması gerekebilir.
  • Sıkı kullanılabilirlik ve güvenilirlik gereksinimlerini karşılamak için, zaman alıcı olabilecek yük devretme ve veri kurtarma mekanizmaları oluşturmak gerekir. Ayrıca seçtiğiniz sistem mimarisi de bu taleplerden etkilenebilir.

Kullanılan boyut metriğinden bağımsız olarak, zaman içinde gereksinimlerdeki artışı takip ederek yararlı bilgiler edineceksiniz. Müşterim, projelerinin teslimden önce genellikle yaklaşık yüzde yirmi beş oranında arttığını fark etti. Ek olarak, projelerinin çoğu beklenenden en az yüzde yirmi beş daha uzun sürdü! Burada tesadüf yok - bu iki trend arasında bir bağlantı olduğu açık.

Gereksinimler Kalite

Gereksinimlerinizi denetlemek suretiyle kalitelerini ölçmek için biraz zaman ayırın. Bulduğunuz tüm kusurları belgeleyin ve bunları eksik gereksinimler, yanlış olanlar, gereksiz olanlar, belirsizlikler vb. İhtiyaç sürecinizin verimliliğini artırmak için bu verileri bir iyileştirme fırsatı olarak kullanın! Örneğin, eksik gereksinimlerin genellikle yinelenen bir sorun olduğunu belirlerseniz, ortaya çıkarma yöntemlerinizin değiştirilmesi gerekir. İş analistleriniz yeterince veya doğru sorgular sormuyor olabilir veya belki de ihtiyaçları geliştirme sürecine daha uygun kullanıcı temsilcilerini dahil etmeniz gerekebilir.

Ekip, tüm gereksinim belgelerini incelerken zaman sıkıntısı hissediyorsa, daha verimli bir seçenek birkaç sayfayı incelemek ve ardından ortalama hata yoğunluğunu, yani spesifikasyon sayfası başına kusur sayısını hesaplamaktır. Bu örneğin tüm belgeyi doğru bir şekilde yansıttığını varsayarsak (ki bu oldukça varsayım olabilir), onu incelenmemiş sayfalarla çarpmak, belirtimlerimizde kaç tane gizli hatanın kalabileceğine dair bir tahmin verebilir. Deneyimsiz müfettişler tüm kusurları tespit edemeyebilir, bu nedenle tespit edilmemiş kusurların tahmini sayısını minimum bir tahmin olarak kullanın. İnceleme örneklemesini kullanarak, belgenin kalitesini değerlendirebilir ve gereksinim spesifikasyonunun geri kalanını incelemenin mali açıdan mümkün olup olmadığına karar verebilirsiniz – ki bu şüphesiz evet olacaktır!

Ek olarak, temel oluşturulduktan sonra keşfedilen kayıt gereksinimleri kusurları. Gereksinimler geliştirilirken kalite kontrol sırasında bu sorunlar gözden kaçabilirdi. Ekibinizin bu hataları bu erken aşamada bulmadaki başarı oranını hesaplayın - bu, tasarım ve kodlama zaten tamamlandığında hataları düzeltmeye çalışmaktan çok daha uygun maliyetli olacaktır!

Muayene verileri size son derece değerli iki ölçüm sağlayabilir: verimlilik ve etkinlik. Verimlilik, çalışma saati başına tespit edilen ortalama kusur sayısını ölçerken, Etkililik, mevcut tüm kusurların ne kadarının denetim yoluyla tanımlandığını gösterir; bu, denetimlerinizin (veya diğer kalite güvence uygulamalarınızın) ne kadar başarılı olduğuna dair bir gösterge veren bir ölçüdür. Verimlilik, inceleme yoluyla bir kusuru keşfetmenin maliyetini tahmin etmenizi sağlar. Bu maliyeti, daha sonra geliştirme aşamasında veya teslimattan sonra bulunan gereksinimlerdeki kusurları işlemek için harcanan miktara karşı değerlendirerek, gereksinimlerinizin kalitesini iyileştirmenin mali açıdan değerli olup olmadığını belirlemenize olanak tanır.

Tıbbi Cihaz Risk Yönetimi

Gereksinim Durumu

Projenin zirvesinde kalmak için, kullanım ömrü boyunca her gereksinimi takip edin. Ekstra güvenlik ve doğruluk için bu bilgileri depolamak üzere bir öznitelik değeri bile atayabilirsiniz. Bu tür durum izleme, yazılım projeleri ile ilgili yaygın ikilemi azaltmaya yardımcı olacaktır - yanlış bir şekilde "yüzde doksan tamamlandı" iddiası. Her gereksinim, herhangi bir zaman aralığında şu durumlardan birine sahip olmalıdır:

  • Savunuldu (biri şiddetle destekledi)
  • Onay süreci başarılı oldu ve tahsis bir temele yerleştirildi.
  • Kodu dikkatlice oluşturduktan, komut dosyası oluşturduktan ve test ettikten sonra uyguladık.
  • Gereksinim testlerinden geçip geçtikten sonra, ürüne başarılı bir şekilde entegre olduğu doğrulandı.
  • Bu gereklilik daha sonra yerine getirilecektir.
  • Silmeye ve uygulamamaya karar verdiniz.
  • Görevden alındı ​​(konsepte hiçbir zaman yeşil ışık yakılmadı)

Yukarıda belirtilen durum seçeneklerinin yanı sıra başka durumlar da düşünülebilir. Bazıları, temel yapılandırmalara eklemeden önce gereksinimlerini doğrulamak için "Gözden Geçirildi" durumunu seçebilir. Alternatif olarak kuruluşlar, gereksinimi eksiksiz ve doğru bir şekilde yayınladıklarını doğrulamak için "Müşteriye Teslim Edildi" ifadesini kullanabilir.

Bir geliştiricinin ilerleyişini sorarsanız, bu özel proje için 87 gereksinim olduğunu söyleyebilir. 61'i zaten doğrulandı ve 9'u yürürlükte ancak hala doğrulama bekliyor, 17'si ise kesinleşmeyi bekliyor. Ancak, bu isteklerin büyüklük veya müşteri memnuniyeti üzerindeki etkisi söz konusu olduğunda hepsinin eşleşmediğini belirtmek önemlidir; farklı miktarlarda çaba da gerektirebilirler. Bir proje yöneticisi olarak, alt sistem boyutunu ve tamamlanmaya ne kadar yakın olduğunu doğru bir şekilde anladığımızdan hiç şüphem yok. Bu, “Yüzde doksanı bitirdim” demekten çok daha etkilidir. Genel bir ilerleme tablosuyla, güvenle "harika görünüyor!" diyebilirim.

İstekleri Değiştir

Başarılı gereksinim yönetimi elde etmek için kuruluşunuzun her gereksinim ekleme, silme ve değiştirme işlemine katılması gerekir. Bu, tüm değişiklik taleplerinin durumunu ve sonuçlarını izlemenizi sağlayacaktır. Bu verileri, aşağıdakiler gibi çeşitli sorgulama sorularını yanıtlamak için de kullanabilirsiniz:

  • Belirlenen süre içinde kaç tane değişiklik talebinde bulunuldu?
  • Taleplerin kaç tanesi cevaplandı ve kaç tanesi çözümsüz kaldı?
  • İsteklerin onaylanma oranı neydi ve yüzde kaçı reddedildi?
  • Ekip, izin verilen her bir değişikliği gerçekleştirmek için ne ölçüde enerji harcadı?
  • İsteklerin açık kaldığı tipik süre nedir?
  • Gönderilen her değişiklik talebinden ortalama olarak kaç öğe (örn. gereksinimler veya yapılar) etkilenir?

İhtiyaç Yönetim Sistemi

Her sürüm için bir temel ayarladıktan sonra, geliştirme sürecinde yapılan tüm değişiklikleri takip ettiğinizden emin olun. Unutmayın, bir değişiklik talebi, farklı türden (kullanıcı odaklı, işlevsel ve işlevsel olmayan) çok sayıda gereksinim üzerinde etkili olabilir. Belirli bir zaman diliminde kaç değişikliğin yapıldığını değerlendirmek için, değişiklik sayısını bu dönemden önceki toplam gereksinim miktarına bölün (temelinizi tanımlarken olduğu gibi).

Gereksinimlerin değişkenliğini tamamen ortadan kaldırmak istemiyoruz. Ne de olsa, onları değiştirmek için genellikle meşru bir gerekçe vardır. Ancak aynı zamanda, projemizin değişiklikleri kaldırabilmesini ve yine de yükümlülüklerini yerine getirebilmesini sağlamalıyız. Değişiklikler sık ​​sık yapıldığında tamamlanmaya yaklaşmak ek maliyetler doğurur; bu, ürününüzü dünyaya ne zaman piyasaya süreceğinizi belirlemeyi zorlaştırıyor! Geliştirme ilerledikçe, çoğu proje değişikliklere karşı daha dayanıklı hale gelmelidir; başka bir deyişle, değişiklik kabul oranı, sürüm bittiğinde sıfıra ulaşana kadar kademeli olarak azalmalıdır. Yinelemeli bir yaklaşım, ekiplere, her döngünün zaman çizelgesiyle yolunda ilerlemeye devam ederken sonraki yinelemelerde iyileştirmeleri dahil etmeleri için birçok şans verir.

Ekibiniz değişiklik talepleriyle dolup taştıysa, ortaya çıkarma süreci kapsamlı olmayabilir veya proje ilerledikçe fikirler ortaya çıkmaya devam edebilir. Bu nedenle, bu değişikliklerin pazarlamadan, kullanıcılardan, satış görevlilerinden, yönetim ekiplerinden vb. nereden geldiğini takip etmek çok önemlidir. Bu bilgileri takip etmek, gözden kaçan gereksinimleri en aza indirmek ve yanlış iletişimi önlemek için kimin ve neyin dikkat etmesi gerektiğini belirlemenize yardımcı olacaktır.

Değişiklik taleplerinin uzun bir süre çözümsüz kalması, değişiklik yönetimi sürecinizin biraz dikkat gerektirdiğinin açık bir göstergesidir. Birden fazla yıl öncesine dayanan ve halen beklemede olan geliştirme talepleri olan bir kuruluşa şahsen tanık oldum. Proje yöneticisinin enerjisini birikmiş iş listesindeki en önemli öğelere önceliklendirmesini sağlamak için, bu ekibin belirli açık istekleri planlı bakım sürümlerine ataması ve diğer uzun vadeli ertelenmiş değişiklikleri reddedilmiş değişiklikler olarak dönüştürmesi gerekir. Bu şekilde, daha az acil meselelerle uğraşmadan önce esas ve acil olan şeyleri daha kolay ele alabilirler.

Zaman ve çaba

En iyi performansı sağlamak için, ekibinizin gereksinim mühendisliği görevlerine harcadığı süreyi kaydetmenizi önemle tavsiye ederiz. Bu, kalite gereksinimlerinin oluşturulmasını ve değişikliğin yönetilmesini, ilerlemenin izlenmesini, izlenebilirlik verilerinin oluşturulmasını ve bu süreçle ilgili diğer faaliyetleri içerir.

İnsanlar bana sık sık bir projenin gerekliliklerine ne kadar zaman ve enerji ayrılması gerektiğini soruyor. Bu cevap büyük ölçüde boyutuna, ekibine, onu oluşturan organizasyona ve amacına bağlıdır. Bunun gibi projeler için kritik görevlere yatırdığınız çabaları takip etmek, doğru tahminlerle geleceği daha iyi planlamanıza yardımcı olabilir.

Ekibiniz daha önce bir projeyi tamamladıysa ve zamanının %10'unu gereksinimlere ayırdıysa, üzerine düşündüğünüzde bu gereksinimlerin kalitesinin çok daha iyi olabileceğini fark etmişsinizdir. Başka bir benzer projeyle karşı karşıya kalınırsa, Proje Yöneticisinin kapsamlı spesifikasyonlar oluşturmak için daha fazla çaba göstermesini sağlaması akıllıca olacaktır – toplam mevcut kaynakların yüzde onundan fazlası yeterli olmalıdır!

Zaman ve çaba

Verileri toplayıp analiz ederken, proje geliştirme çabasını bir ürün boyutu ölçüsüyle karşılaştırın. Belgelenmiş gereksinimleriniz, genel boyutu hakkında bir fikir verecektir. Daha kesin olmak gerekirse, ürününüzün ölçümleriyle orantılı olan her ne olursa olsun, test edilebilir bireysel özellikleri, kullanım senaryosu noktalarını veya işlev noktalarını sayma çabasını ilişkilendirebilirsiniz. Bu bağlamda Şekil 1'e atıfta bulunulması, geliştirme ekibinizin yeteneklerini değerlendirmek için bir ölçüm çubuğu sağlar ve bu da sürüm içeriklerini tahmin etmenin yanı sıra doğru bir şekilde kapsam belirlemeye yardımcı olur! Ürününüz için boyutla ilgili verileri toplayarak ve ilgili uygulama çabasını not ederek, gelecekteki benzer projelere hazırlanırken doğru tahminler formüle edebilirsiniz.

Korku birçok kişinin zihninde oyalanabilir; Bir yazılım ölçüm programı geliştirmenin, önemli görevlerden değerli zamanı çalacağından korkmak. Aksine, verimli ve hedefe yönelik bir metrik sistem uygulamak çok fazla çaba veya enerji gerektirmez. Tek yapmanız gereken veri toplamak ve analiz etmek için temel bir altyapı oluşturmak ve ekip üyelerinizi iş faaliyetleriyle ilgili bazı ayrıntıları günlüğe kaydetmeye teşvik etmektir. Şirketinizde metriklere dayalı bir kültür oluşturduğunuzda, bu yöntemle öğrenilebilecek şeyler inanılmaz!

Sonuç

Gereksinimlerin ortaya çıkarılması ve analizi, yazılım geliştirmenin temel bileşenleridir. Bunlar olmadan, bir proje eksik veya yanlış spesifikasyonlar nedeniyle başarısız olabilir, bu da masraflı yeniden işleme ve potansiyel olarak tatmin edici olmayan sonuçlara yol açar. Bu nedenle, proje zaman çizelgesi boyunca gereksinimleri toplamak ve doğruluğu doğrulamak için etkin bir sürece sahip olduğunuzdan emin olmanız önemlidir. Uygun yönetim ile ekipler, istenen tüm işlevleri doğru bir şekilde tanımlayan ayrıntılı gereksinimler oluşturarak ve hiçbir şeyin gözden kaçırılmamasını sağlayarak başarıya ulaşabilir. Ekipler, her girişimde mevcut süreçleri ve ölçümleri düzenli olarak değerlendirerek, geliştirme döngüleri sırasında kullanıcı geri bildirimi ararken kendileri için en iyi olanı daha iyi anlayabilecek. Bu, projelerin yolunda gitmesine yardımcı olacak ve daha yüksek kaliteli sonuçlara katkıda bulunacaktır.

Bu gönderiyi paylaşmayı unutmayın!

Iyi