Yazılım geliştirme maliyet tahmini

Yazılım geliştirme maliyetlerinin tahmini, bilgisayar projelerinin analizinde çok önemli bir faktördür, maliyetlerini ölçmek için göstergelere sahip olmak, verimliliği, mükemmelliği, kaliteyi ve rekabet gücünü garanti etmek stratejik bir konudur. Maliyet analizi, işi veya projeyi verimli bir şekilde yürütmek için gerekli kaynakları belirleme sürecidir.

Maliyet değerlendirmesi, para, çaba, kapasite, bilgi ve zaman açısından gerekli kaynakların niteliğini ve miktarını belirleyerek iş yönetimini etkiler. Şu anda kullanılmayan ve maliyetlerini hesaplamak için herhangi bir yazılım projesine uygulanabilen bir dizi metrik vardır.

Bu araştırma, yazılım geliştirme sürecindeki maliyeti hesaplamak için bir dizi metrik tasarım önermektedir. Metrikler mümkün olduğunca geneldir ve belirli bir yazılım metodolojisine bağlı değildir, ancak yazılımı ticari bir ürün olarak değerlendirir.

Metrikleri seçmek için, karar vermede sahip oldukları etki göz önünde bulundurularak, proje yöneticisinin teknoloji, idari beceriler, kişisel becerilerle ilgili yeterli yetenekleri gibi projelerin analizi için temel unsurlar sağlanmıştır. iletişim için. Karar verebilme, yararlanıcılar ile olumlu ilişkiler, proje ekibinin analize katılımı, yeterli kaynaklar. Gelir ve maliyetlerin değerlendirilmesi, idari ve idari destek ile proje üyeleri arasında bulunması gereken taahhüt.

Anahtar Kelimeler: metrikler, maliyetler, yazılım geliştirme, yazılım metodolojileri.

Öz

Yazılım geliştirme sürecindeki maliyetlerin tahmini, bilgi teknolojisi projelerinin analizinde çok önemli bir konudur. Yazılım geliştirme projelerinin maliyetini ölçmek ve bu sürecin verimliliğini ve rekabet gücünü korumak için göstergelere sahip stratejik bir tema oluşturun. Maliyet analizi, iş projesini verimli bir şekilde sürdürmek için gerekli kaynakların tanımlanması sürecidir.

Yazılım projelerinde maliyetin değerlendirilmesi, para, çaba, kapasite, bilgi ve kalan süre açısından gerekli kaynakların niteliğini ve miktarını belirler ve bu faktörlerin işletme etkinliği üzerinde doğrudan sonuçları olur.

Günümüzde çok kullanılmayan bir dizi metrik var ve bu projeler programlama araçları, metodolojiler, platformlar vb. Birçok durumda bile tahminde kullanılan noktalardan biri geliştiricinin deneyimidir.

Bu araştırma, yazılım ürünlerinin maliyetini ve uygulanabilirliğini ölçmek için bir dizi metrik tasarım ve bunu değerlendirmek için bir araç önermektedir. Bu metrikler mümkün olan en genel metindir ve yazılımı ticari bir ürün gibi değerlendirmek yerine belirli yöntem veya çerçevelerle bağlantılı değildir.

Anahtar sözcük: metrikler, maliyetler, yazılım geliştirme, yazılım yöntemleri.

Giriş

Yazılım geliştirmedeki maliyetlerin tahmini, projelerin analizi için gerçekten önemli bir faktördür; verimliliği, rekabetçiliği, etkililiği ve mükemmelliği garanti eden bir yazılım projesinin maliyetini ölçmek için metriklere sahip olmak stratejik bir konudur. Herhangi bir ekonomik sistemde vazgeçilmez bir unsur, yüksek derecede güvenilirlik sağlayan çevik mekanizmalar yoluyla, ülkenin planlanmasında maliyetin rolünü ve temelde şirketin doğru yönde olmasını sağlar.

Şu anda, rekabetçi bir seviyeye ulaşmak isteyen şirketlerin karar verme için temel teşkil eden iyi bir maliyet sistemine ihtiyacı vardır. Farklı maliyet türlerini sorumluluk alanlarına ve maliyet merkezlerine göre tanımlamak her kuruluş için büyük bir avantajdır.

Günümüz iş dünyasında, müşterilerin ve rekabetin beklediği verimlilik düzeylerine ulaşmak şarttır. Bunu başarmak için işletmenin maliyetleri bilinmelidir; işletmenin planlama, değerlendirme ve kontrol operasyonları için gerekli bilgileri sunarak bir kuruluşun amaçlarının yerine getirilmesine katkıda bulunacak stratejik, taktik ve operasyonel kararlar alınmasına izin verebilirler.

İşletme maliyetlerinin veya giderlerinin etkin bir şekilde ölçülmesini ve yönetilmesini sağlamak, kuruluşun tüm faaliyetlerinin masraflarını daha iyi değerlendirmesine, azaltmaya yönelik kararlar almasına ve böylece belirlenen hedefleri karşılamasına ve yerine getirmesine olanak tanıyacak bir rekabet avantajı anlamına gelir. potansiyel müşterilerinizin talebi.

Maliyet analizi, işi veya projeyi gerçekleştirmek için gerekli kaynakları belirleme sürecidir. Maliyet değerlendirmesi para, çaba, kapasite, bilgi ve zaman açısından gerekli kaynakların niteliğini ve miktarını belirler, farklı durumlarda tahmin edilmez veya diğer durumlarda olduğu gibi, maliyetin o kadar düşük olduğu değerlendirilir. analiz gerekli. Benzer şekilde, genellikle proje başladıktan sonra, geliştiriciler projeyi tamamlamak için gerekli ekipman, malzeme ve insan kaynaklarının mevcut olmadığını ve projenin başarısız olduğunu fark ederler (Jones, 2004).

Maliyet analizi sadece projenin maliyetinin ve bakımının belirlenmesine yardımcı olmakla kalmaz, aynı zamanda uygulanabilir olup olmadığının belirlenmesine de yardımcı olur. Yazılım, yeni yazılım mühendisliği yöntemleri ve araçlarının kullanımından elde edilen üretkenlik ve kalite açısından faydaları değerlendirmek için ölçülmeli ve tahmin için bir temel oluşturulmalıdır.

Yazılım geliştirme maliyetinin ve doğruluğunun hesaplanması, hem yazılım ürününü geliştiren işletme hem de yazılım maliyetinin tahmine uygun olmasını bekleyen müşteri için önemli bir faktör haline gelmiştir. Yeterince doğru bir tahmin, şirketin yönettiği projeleri daha iyi planlamasına ve her proje için gerekli kaynakların daha iyi bir şekilde tahsis edilmesine izin verirken, diğer taraftan, tahminlerdeki hatalar proje planlamasının daha fazla sorunla sonuçlandığı anlamına gelebilir. başlangıçta beklenen, kalitenin düşmesi, teslim tarihinde gecikmeler, proje için ayrılan fazla kaynaklar, bu da aşırı bir bütçeye yol açar.

Yazılım geliştirme maliyet hesaplama modelleri bir dizi değişkene dayanır, bunlara maliyet, çaba veya boyut gibi faktörler denir, her model tahminlerini kendi faktörlerine dayandırır.

Tahmin yöntemleri, ihtiyaç duyulan büyük miktarda veri ve bu veriyi elde etmenin zorluğundan etkilenir. Bilgi eksikliği projenin ilk aşamalarında vurgulanmaktadır çünkü geliştirilecek uygulama tam olarak tanımlanmamıştır.Projenin gelişimi ilerledikçe sistem hakkında daha fazla ayrıntı bilinir, faktörler arasındaki ilişkiler artar, izin verilir tahminlerde daha fazla doğruluk.

Yazılım geliştirme çok karmaşık bir faaliyettir, bu da onu gerçekleştiren insanların entelektüel çabalarına ve yaratıcılıklarına dayanan somut olmayan bir üründür. Bu tür bir projenin tüm aşamalarında insan hataları vardır ve düzeltilmesi çok pahalı olabilir. Mümkün olan en düşük maliyete sahip bir yazılım ürününün sonucu, çalışma felsefesinin aynı olmasını sağlayan yazılımın analizi, tasarımı, programlanması ve test edilmesi için metodolojilerin, prosedürlerin, metriklerin ve standartların kullanımını ima eder (Jones, 1996).

Tahmin faaliyeti projede bir kez yapılmaz, daha fazla veri elde edildikçe, projenin geri kalanının daha iyi planlanmasını sağlayan daha kesin tahminler yapılır.

Kestirmenin yapılabileceği tüm noktalardan, gerçekleştirilecek en az veri mevcut olduğunda, projenin fizibilitesinin hala değerlendirildiği ilk andadır. Üçüncü taraflar için belirli yazılımların geliştirilmesi ve satışı açısından, bu tahmin, erken bir aşamadan itibaren en önemlilerinden biridir.

Bir yazılım projesinin erken tahminini yapmak zor bir iştir. Bu durum bilinmektedir ve bu nedenle geliştirme şirketleri analiz ve tasarımı kodlamadan ayrı satmaya çalışmaktadır, böylece ikincisi daha sıkı bir şekilde tahmin edilebilir. Özellikle, Birleştirilmiş Yazılım Geliştirme Süreci, yalnızca geliştirme aşamasının sonunda, buna ulaşıldığında proje kaynaklarının% 25 ila% 30'unu tüketmiş olduğu anlamına gelen sağlam bir ekonomik teklif verme konumunda olduğunu savunur. (Ivar Jacabson, Birleşik Yazılım Geliştirme Süreci, 2000).

Daha doğru olana bakılmaksızın, gerçek şu ki, piyasa işe başlamadan önce bir fiyatın kapatılmasını gerektiriyor. Hem maddi hem de insan kaynaklarının maliyeti, hataları en aza indirmek ve sonucun kalitesini en üst düzeye çıkarmak için taraflar arasında uzlaştırılması gereken bir başka konudur, bu nedenle, ön aşamadan iyi maliyet planlaması yapmak büyük önem taşımaktadır. taslak.

Bu nedenle, ortaya çıkan problemi çözmek, bilimsel araştırma problemi olarak tanımlamak, yazılım geliştirmede bir bilgisayar ürününün toplam maliyetini nasıl hesaplamak gerekir?

Bu araştırmanın amacı, bir yazılım ürününün maliyetini hesaplamak için bir dizi ölçüm tasarlamaktır.

Sorun durumunu çözmek için bir dizi spesifik hedef yürütmek gerekiyordu :

Bir yazılım ürününün maliyeti ile ilgili güncel eğilimleri, metodolojileri ve en önemli kavramları bilgilendirmek.Yazılım maliyetini hesaplamak için temel modelleri belirlemek, bir yazılım ürününün oluşturulmasında kullanılan ölçütleri incelemek.

Yukarıdakilerden, aşağıdaki hipotez tanımlanır : Bir yazılım ürününün maliyetini hesaplamak için bir dizi metrik olsaydı, projenin fizibilitesinin belirlenmesine yardımcı olur.

Çalışma nesnesi: Yazılım mühendisliği.

Etki alanı: Yazılım geliştirmede maliyeti hesaplama yöntemleri.

Bu metriklerin geliştirilmesi için bir dizi araştırma sorusu dikkate alındı :

Bir yazılım ürününün maliyetini ölçmek için küresel olarak takip edilen mevcut metrikler nelerdir?

En son yazılım geliştirme yöntemlerini ve bunların nihai ürün maliyetlendirme sürecini nasıl etkilediğini anlayın?

Bir yazılımı geliştirmenin maliyetini erken aşamalardan dikkate alarak avantajları nelerdir?

Yazılım ürününün maliyeti verimli bir şekilde hesaplanarak kaç tane insan ve parasal kaynak tasarrufu sağlanacaktır?

Bu araştırma Bilimsel Yeniliklere sahiptir:

Tez, yazılım ürününün Şirket içindeki karmaşıklığını hesaplamak için metrikler kümesinin hazırlanmasını destekleyen teorik unsurları göstermektedir.Bu analiz, karar verme kapasitesini artıracak, şirket için doğru, ilerleme ve mükemmellik için yararlı olacaktır. üstün verimlilik ve rekabetçiliği teşvik eden iş ve ekonomik performans göstergeleri. Ülkede ve dünyada yeni olan yeni araçların geliştirilmesi, günümüzde kullanılan yöntemleri güçlendirmeye devam etmek için bir zorluk oluşturmaktadır.

Araştırma yöntemleri olarak araştırma bilgisinin çoğunu elde etmek için gözlem kullanılmıştır; teori ve mevcut belgelerin analiz edilmesine izin veren analitik-sentetik yöntem, daha sonra çalışma nesnesi ile ilgili en önemli unsurların çıkarılmasını gerçekleştirir. Bilgi toplama tekniği olarak mülakat, araştırmayla ilgili diğer verileri toplamak için kullanılmıştır.

Bu araştırmanın içeriği, kullanılan genel sonuçlar, öneriler ve kaynakça olmak üzere 3 bölüme ayrılmıştır, son olarak çalışmanın bedenini tamamlayan ve anlaşılması için gerekli olan ekler.

Bölüm 1 “Yönetim Muhasebesi ve Tahmin Teknikleri”, yazılım geliştirmedeki maliyetin nasıl hesaplanacağı konusundaki uluslararası ve ulusal düzeyde son teknoloji ürünü çalışmanın sonuçlarını; Çalışma boyunca ele alınacak ana kavramların yanı sıra, bir yazılım ürününün maliyetini hesaplamak için dünya çapında kullanılan ana tahmin tekniklerinin analizi ve bunun yapımında kullanımının faydalarını açıklamak kararlar.

Bölüm 1. Yönetim muhasebesi ve tahmin teknikleri.

Bu bölüm, araştırma boyunca analiz edilen temel yönleri ve ilgili kavramları açıklamaktadır. İncelenecek araç ve teknolojiler, bir bilgisayar ürününün fizibilitesinin analizine izin veren yazılım projelerinde maliyetleri tahmin etmek için kullanılan tekniklerle ilgili en son teknolojiyi göstermektedir. İş uygulamalarının çevik gelişimi için yöntemler ve yazılım geliştirmede en çok kullanılan metrikler analiz edilir.

1.1 Yönetim Muhasebesi

Maliyet Muhasebesi, üretim, eğitim hakkında karar vermek için bilgi sağlamak amacıyla şirket değerlerinin iç dolaşımını yakalamayı, ölçmeyi, kaydetmeyi, ölçmeyi ve kontrol etmeyi amaçlayan muhasebenin bir parçasıdır. maliyet fiyatı politikasına ve satış fiyatı politikasına ve sonuçların analizine, üretimin teknik yasalarına, organizasyonun sosyal yasalarına ve pazarın ekonomik yasalarına dayanarak, geri kalan alanlarla yakın işbirliği içindedir. icrasından sorumlu olanların yönetimle birlikte karar alma süreçlerine katılmalarına izin veren işlevsel ”(Fernández, 1993).

Belirlenen stratejik ve genel hedeflerin izlenmesi ve gerçekleştirilmesi, bunların planlanması, kontrolü ve ölçümü ile ilgili olarak kurumun farklı seviyelerinde karar almayı kolaylaştırmak için finansal ve finansal olmayan, nicel ve nitel bilgileri iletir. Kuruluşun (iç ve dış) faaliyetleri, işlevsel alanların geri kalanıyla yakın işbirliği içinde, yürütmelerinden sorumlu olanların yönetimle birlikte karar alma süreçlerine katılmalarına izin verir. Rutin operasyonların planlanması ve kontrolü, politika oluşturma ve uzun vadeli planlama ile kârın tespiti için veri sağlar (Maliyet Muhasebesi, 1991).

Maliyet muhasebesi, her bir kalemi üretme veya satma veya belirli bir hizmet sağlama maliyetleriyle ilgili verileri hızlı bir şekilde yöneten endüstriyel veya ticari bir işletmenin Genel Muhasebesinin genişletilmiş bir temelini oluşturur (Maldonado).

Maliyet muhasebesinin kavramsal temelini oluşturan en önemli terim maliyettir. Konuyu inceleyen kişiler tarafından birçok tanım yapılmıştır ve daha sonra farklı maliyet tanımları sunulacaktır:

″ Maliyet, satın alınan mal veya hizmetler karşılığında teslim edilen veya teslim edileceği vaat edilen kaynakların parasal değeridir. » (Colín, 2001) ″ Maliyet, bir şeyler üretmek için yatırılan çabaların ve kaynakların toplamıdır. » (González, 2001) ″ Maliyet, üretim, dağıtım ve finansman işlevleriyle ilgili olarak belirli bir döneme atfedilebilen ödemeler, taahhüt edilen yükümlülükler, tüketim, amortisman, itfa ve uygulamalardır. Ortega (Ortega, 2001) ″ Maliyet, mal veya hizmet elde etmek için feda edilen, varlıklar azaltılarak ve / veya faydalar elde edildiğinde yükümlülük doğdurularak dolar cinsinden ölçülen değer olarak tanımlanır. ″ (Ralp Polimeni, 1989)

Ürünün fiyatını belirlemek için gerekli ve vazgeçilmez bir unsur olan maliyetin önemi göz önüne alındığında, araştırma için yeni bir maliyet kavramı getirilmesine karar verildi.

"Bir bilgisayar ürünü elde etmek için gerekli maddi, maddi ve insan kaynakları tüketimidir."

Maliyetlerin yürütülmesinin analizi, karar vericilerin yönetim önlemleri almalarına izin verir, çünkü maliyetin belirlenmesi, bir dönem boyunca geçerli olacak fiyatları ve oranları tanımlamak için temel bir araçtır. Maliyet hesaplamasının, belirlenen normlara ve bütçelere uygun olarak daha büyük bir güvenilirlik titizliği temelinde gerçekleştirildiğini göz önünde bulundurarak, şirketin ekonomik faaliyetinin davranışını ölçmeyi sağlayan, yönetim için etkili bir araç olarak tanımlanmasına izin verir, dolayısıyla işletmenin maliyetlerini kontrol altında tutmak hayati önem taşımaktadır.

1.1.1 Maliyetlerin Önemi.

Maliyet, ekonomik verimliliği ölçen bir göstergedir. Emek verimliliği seviyelerini, fonların kullanıldığı verimlilik derecesini ve ayrıca malzeme, emek ve finansal kaynak tasarrufu sonuçlarını yansıtır.

Farklı dönemlerde elde edilen sonuçların karşılaştırılmasını sağlar ve böylece verimli kaynakların rasyonel ve optimal kullanımı için planlı bir şekilde ve yeniden üretimi garanti etmeyi amaçlayan yeni yollar bulmaya yardımcı olur. (Rumiantsev, 1975)

Bir yönetim aracı olarak maliyet, alınacak olası kararların değerlendirilmesini kolaylaştırır, maliyet, herhangi bir ekonomik süreçte mevcut kaynakların kullanımını ölçer, böylece programlarla ilgili olarak meydana gelen sapmaların etkisini bilmeyi kolaylaştırır ve sahip olunan malzeme ve insan kaynaklarının doğru planlanmasını ve kullanılmasını güvence altına alacaktır. Şirketin gerçek rekabet gücünü ve rekabete kıyasla başarı veya başarısızlık olasılıklarını gösterdiğinden stratejik karar almayı kolaylaştırır. (Cueto Ible ve Sánchez Batista, 2000)

Araştırma ve Geliştirme (R + D + i) giderleri de vardır, bunlar insan, kültür bilgisi dahil olmak üzere bilgi hacmini arttırmak için sistematik bir şekilde yürütülen yaratıcı çalışmalarda yapılan maliyetlerdir. ve toplum ve bu bilginin yeni uygulamalar yaratmak için kullanılması (Chang, 2013). Maliyetler için, özelliklerine göre gruplandırılmasına izin veren birkaç sınıflandırma vardır.

Maliyet, mal veya hizmet elde etmek için yatırılan değerdir. Amaçları vardır:

Kârı ölçmek ve envanteri değerlendirmek için maliyetle ilgili raporlar sunmak (gelir tablosu ve bilanço.) Şirket operasyonlarının ve faaliyetlerinin idari kontrolü için bilgi sunmak (kontrol raporları). planlama ve karar verme (analiz ve özel çalışmalar).

Maliyetler aşağıdaki amaçlarla karar vermede bir yönetim aracı olarak kullanılır: (Audirac, 1997)

Bir mal veya hizmetin fiyatını belirleyin. Ürün maliyetleri genellikle en büyük brüt kar veya zararı oluşturan ürünü ayırt etmek için kullanılır.İşin yürütülmesini ölçün, yani imalat veya hizmetin gerçek maliyetini önceden belirlenmiş bir maliyetle karşılaştırın. Envanter kontrolü, satış için gerekli oranlarda yeterli miktarda farklı ürünün stokta tutulması anlamına gelir.

1.1.2 Maliyet Sınıflamaları.

Faaliyet hacmi veya seviyesi ile ilişki:

Değişken maliyetler: Birim maliyet sabit kalırken, toplam maliyetin ilgili aralık dahilindeki hacim veya üretimdeki değişikliklerle doğru orantılı olarak değiştiği sabit giderler Sabit maliyetler: birim üretim sabit maliyeti, üretim başına ve hacim ile orantılı olarak değişirken, karışık maliyetler: Bunlar, ilgili çeşitli operasyon aralıklarında hem sabit hem de değişken özelliklere sahiptir. İki tür karışık maliyet vardır: yarı değişken maliyetler ve kademeli maliyetler Yarı değişken maliyetler: Sabit parça genellikle belirli bir ürün veya hizmeti kullanılabilir hale getirirken minimum ücreti temsil eder, değişken bölüm hizmeti gerçekten kullanmak için ücretlendirilir.Sabit kısım, farklı aktivite seviyelerinde aniden değişir, çünkü bunlar bireysel porsiyonlarda elde edilir. Katmanlı bir maliyet, çok küçük bir ilgili aralıktaki sabit bir maliyete benzer.

Onları ilişkilendirebilme:

Doğrudan maliyetler: Bunlar, yönetimin belirli kalemlerle veya alanlarla tanımlayabildiği, örneğin doğrudan malzemelerin maliyetleri ve belirli bir ürünün doğrudan işçiliği doğrudan maliyetlere örnektir. (Sáez, 1993) Dolaylı maliyetler: Birçok makale için ortaktır ve bu nedenle herhangi bir madde veya alanla doğrudan tanımlanamaz. Bunlar genellikle tahsis teknikleri kullanılarak makalelere veya alanlara yüklenir. (Gayle, Muhasebe ve Maliyet Yönetimi, 1999)

Üretim, dağıtım, yönetim ve finansman maliyetlerini kayıt altına almak, biriktirmek, dağıtmak, kontrol etmek, analiz etmek, yorumlamak ve raporlamak, ürün ve hizmetlerinin kalitesini garanti etmek için şirketlerde yapılması gereken görevlerden bazılarıdır. Her yazılım mühendisliği projesi, kaliteli bir ürün oluşturmak için mevcut kaynakların iyi bir şekilde planlanması ve incelenmesi ile başlaması gerektiğinden, yazılım şirketleri bu analizlerde geride bırakılmamaktadır.Bu nihai ürünü elde etmek için üst üste birkaç aşamadan geçmek gerekir. Yazılım geliştirmenin nelerden oluştuğunu açıklar.

1.2 Yazılım Geliştirme

Yazılım geliştirme, yazılım geliştirme, işletim ve bakım için sistematik, disiplinli ve ölçülebilir bir yaklaşımın uygulanması ve bu yaklaşımların incelenmesi, yani mühendisliğin yazılıma uygulanmasıdır. (Alain Abran, 2004)

IEEE Yazılımına göre, bir bilgisayar sisteminin işlemlerinin bir parçası olan bilgisayar programlarının, prosedürlerinin, kurallarının, belgelerinin ve ilişkili verilerin toplamı olarak tanımlanır. Bu tanım kapsamında, yazılım kavramı, bilgisayar programlarının ötesinde farklı biçimlerde geçer: belgelerine ek olarak kaynak kodu, ikili veya yürütülebilir kod.

Yazılım geliştirme, esas olarak insanların entelektüel çabalarına ve ayrıca geliştirildiği süreçlere ve teknolojiye bağlı karmaşık bir faaliyettir.

Bugün iletişimdeki patlama, daha önce sadece ütopya olan programlar oluşturabilen bilgisayar mühendislerinin sürekli istihdamını sağladı. Yazılım uzmanlarının yaratılmasında, bilimin farklı dallarından teknisyenler, mühendisler gruplandırılır, bunlar ekonomi ve topluma dayalı gerçek problemleri çözebilir, entelektüel sermaye yazılım geliştirmede hayati öneme sahiptir. Bu nedenle bu araştırma, bilgisayar uygulamalarının geliştirilmesi ile ilgili uzmanların sahip olduğu bilgileri dikkate almaktadır.

Yazılım geliştirme için yazılım metodolojileri dikkate alınmakta, bunlardan bazıları aşağıda belirtilmektedir.

1.2.1 Yazılım Geliştirme Metodolojileri

Şu anda, belirtilen gereksinimleri karşılayan verimli bir bilgisayar sisteminin inşasını amaçlayan yazılım geliştirme yöntemlerinden bahsetmeden yazılım geliştirmeden söz edilemez, gerçekten yoğun bir görevdir ve her şeyden önce yapılması zordur. uyun (Pressman, 1998).

Yazılım geliştirme metodolojileri, daha öngörülebilir ve verimli hale getirmek için yazılım geliştirme üzerine disiplinli bir süreç uygular. Bir yazılım geliştirme metodolojisinin temel amacı, yazılımın kalitesini artırmak ve her aşamadaki gereksinimleri değerlendirmektir.

Tüm metodolojilerin her bir projenin özelliklerine (geliştirme ekibi, kaynaklar vb.) Uyarlanması gerektiğinden evrensel bir yazılım metodolojisi yoktur, bu nedenle sürecin yapılandırılabilir olmasını gerektirir. Geliştirme metodolojileri, özelliklerine ve takip ettikleri hedeflere göre iki gruba ayrılabilir: çevik ve sağlam.

Geleneksel veya sağlam modellerin aşamaları tanımlanır ve bir sonraki aşamaya geçmeden önce bir fazı kapatmak için daha fazla gereksinim vardır. Bunlar, her aşama için daha fazla dokümantasyon ve her bir iş ürününün tamamlandığının doğrulanmasını gerektirir, uzun vadeli projeler için iyi çalışma eğilimindedir.

İyi tanımlanmış çıktıları olan yeni yazılımlar için, dinamik modeller doğal olarak artımlıdır, bu da küçük sürümlerin daha büyük bir üründen daha sağlam ürettiğini, belgelerin daha az olduğunu, temel fikir tüm çabalarınızı temel alarak kod odaklı olmasıdır ve belgeleme (Agile manifesto ilkeleri, 2005).

Her projeye, özel uygulaması, projenin büyüklüğü, ekibin deneyimi ve projenin zaman çizelgesi dikkate alınarak oluşturulacak projeye en uygun model tarafından karar verilmelidir. Bazı yazılım yöntemleri aşağıda belirtilmiştir.

1.2.2 Sağlam Metodolojiler

Sağlam veya geleneksel yöntemler güçlü planlama tarafından yönlendirilir. Tüm geliştirme sürecinin kapsamlı dokümantasyonuna ve ilk aşamasında tanımlanan bir proje planına uymaya dikkatlerini odaklamak. Sağlam yöntemler şunları içerir: Microsoft Solution Framework, METRIC 3 ve Rational Unified Process (RUP).

Bunlar teknolojik projelerin planlanmasını, geliştirilmesini ve yönetimini kontrol eder. Uyarlanabilir, ölçeklenebilir, 3 veya 4 kişilik küçük ekipler ve 50 veya daha fazla kişi gerektiren projeler organize edilebilir. Rol ve sorumluluklarının yanı sıra her birinin ihtiyaçlarını da dikkate alarak, projenin yaşam döngüsü boyunca yazılım üretimindeki farklı katılımcılar arasındaki iletişimi ve anlayışı kolaylaştırırlar. En çok tanınanlar arasında, projede kimin, nasıl, ne zaman ve ne yapılması gerektiğini açıkça tanımlayan Birleşik Kalkınma Süreci (RUP) bulunmaktadır.

RUP üç temel özelliğe sahiptir, kullanım senaryoları ile yönlendirilir, yani projede, ürünün ne yapması gerektiğinin kullanıcısı için önemine yönlendirilirler, bu, temelin mimarlık organize edilmiştir ve yinelemeli ve artımlıdır. (Ivar Jacabson, Birleşik Yazılım Geliştirme Süreci, 2000) Bu metodoloji genellikle teknik ve üniversite eğitiminde kullanılan yöntemdir.

Çevik yöntemlerde kavram farklıdır, aşağıdaki bölüm en çok kullanılanlardan bazılarını göstermektedir.

1.2.3 Çevik yöntemler

Çevik metodolojiler 1990'ların ortalarında, Carnegie Mellon'daki Yazılım Mühendisliği Enstitüsü'nde (SEI) başlıyor, bu yeni süreç modeli hafifti. Daha az dokümantasyon ve daha az proses kontrolü gerektiriyordu. Orta ölçekli yazılımlar için küçük parçalar halinde belirli sektörlere hedeflenmiş, daha küçük geliştirici ekipleri için öngörülmüştür. Yazılım geliştirilirken bu geliştirici ekiplerinin hızlı bir şekilde ayarlamalarına, gereksinimleri değiştirmelerine ve istemcilere talepte bulunmalarına izin verilmesi amaçlanmıştır (Martin, 2009).

Dinamik geliştirme, herhangi bir yazılım geliştirme projesinin hedefinin kod olduğu önermesinden geçer, bu nedenle geliştirme ekibi zamanlarının çoğunu kod yazmakla, doküman yazmakla geçirmemelidir (Shore, 2008).

Çevik metodolojilerin birkaç özelliği vardır, kod, sık ürün sürümleri, geliştirilmekte olan müşteri ile sürekli değişim, daha basit ve daha okunabilir hale getirmek için kodun yeniden kullanılmasını vurgulama eğilimindedirler.

Extreme Programming (XP), KANBAN, Agile Unified Process (AUP), Scrum gibi birçok çevik metodoloji vardır. Önerilen metriklerin tasarımı için, yazılım geliştirmedeki maliyetlerin bir analizinin yanı sıra, büyük kullanımı ve olumlu sonuçları nedeniyle Scrum metodolojisi kavramı da dikkate alınmıştır.

Dinamik Scrum metodolojisindeki fikir, tek bir hedef etrafında birleştirilen ve bu hedefe manevra yapmak için buluşan takım etrafında döner. (L Yükseliyor, 2007)

Scrum bu durumda gerçeğe olabildiğince yakın tahmin etmek için gerekli araçları sağlar. Birçok durumda sözleşmeler proje süresini ve maliyetlerini belirlemek için çok yararlı bir araçtır. Şirketler son yıllarda çevik teknolojilere değer vermiş ve son kullanıcılarına sağladığı olumlu yönleri ve faydalarını elde etmişlerdir Scrum kullanımı temel olarak zaman ve malzemelerin analizine dayanmaktadır, bu bir metodolojidir. Büyük ölçekli projelerde de kullanılabilir. (Zeitler, 2001)

Çevik araçlardan yararlanan varlıklar, zaman rasyonalizasyonunun dinamik metodolojileri uygulamak için ana motivasyon olmasını sağlar, bir başka avantaj artan üretkenliktir, daha da büyük bir avantaj, değişen gereksinimleri manipüle etme yeteneğidir. istemcinin ilerlemesini daha görünür hale getirir.

Scrum, maliyet, kapsam ve zaman değişkenleri arasında yazılım yönetimi ve geliştirme analizi için bir çerçevedir (Bkz. Ek 1). Aşağıdaki bölüm aralarındaki ilişkiyi göstermektedir.

1.2.4 Demir Üçgen

Her projede ilgili üç değişken vardır, sözde "demir üçgen" olarak adlandırılan gereklilikleri veya görevleri yansıtan kapsam, zaman veya planlama, projenin ne kadar süreceğini, ne kadar para, insan, kaynak olduğunu analiz eden maliyet veya kaynakları gösterir projeye ayrılacaktır. Belirli kalite hedeflerini sürdürmek için, üç değişkenden birinde yapılan herhangi bir değişiklik, diğer ikisinden birinin değiştirilmesini gerektirir. (Kniberg, 2012)

Demir Üçgen

Şekil 1 Demir üçgen. Kaynak: Kendi detaylandırma .

Belirli bir kalite göz önüne alındığında, projeye adanmış kişiler azaltılırsa, projenin kapsamını azaltmak ve / veya teslim tarihini arttırmak gerekecektir. Belirli bir kalite göz önüne alındığında, projenin teslim edilmesi gereken tarih azalırsa, projenin kapsamını azaltmak ve / veya kendisine tahsis edilecek kaynakları arttırmak gerekecektir. Projenin kapsamı artırılırsa, belirli bir kalite göz önüne alındığında, projenin teslim tarihinin artırılması ve / veya kendisine tahsis edilecek kaynakların artırılması gerekecektir.

İlk aşamalardan itibaren, zaman ve tahmini maliyetin sözleşmeli olana mümkün olduğu kadar doğru olduğu müşteri gereksinimlerini karşılayan bir ürün elde etmek için bu değişkenlerin davranışını planlamak gerekir. Zor olan, onları kesin olarak tanımlamaktır, böylece riskler tespit edilir ve ürünü teslim ederken sürprizler olmaz (Larman, 1999). Bunu başarmak için proje planlamasına katkıda bulunan tahmin teknikleri kullanılır.

1.3 Maliyetlerin hesaplanması.

Maliyetler genellikle ekonomik birimlerde ölçülebilir ve tahmin edilir. Bir maliyet-fayda analizinde, para, zaman, kaynaklar ve maddi olmayan duran varlıklar gibi değerlerle ölçülebilen, havuzlanabilir veya elle tutulur olmayan, ancak bir projenin maliyetlerini analiz etmek için gerekli olan somut yönleri göz önünde bulundurmak gerekir. Maddi olmayan faydaları ölçmek zor olsa da, yazılımla ilgilenen herkesin dahil olması gereken, bunların dikkate alınmamasına gerek yoktur (Sexton, 2009).

Araştırmada dikkate alınacak yazılım geliştirme için ekonomik göstergeler.

Fayda-Maliyet Analizi: Fayda- maliyet analizi tekniğinin temel amacı, bir projenin gerçekleştirilmesinde katlanılan maliyetlerin bir ölçüsünü sağlamak ve söz konusu maliyet tahminini, söz konusu projeyi gerçekleştirmenin beklenen faydaları ile karşılaştırmaktır.

Maliyetler hesaplanırken diğerleri arasında aşağıdakiler gibi unsurlar göz önünde bulundurulmalıdır: (MAP, 2001)

Donanım ve yazılım edinimi ve bakımı.İletişim giderleri (hatlar, telefon, posta, vb.) Kurulum giderleri (kablolama, oda iklimlendirme, insan ve malzeme kaynakları, seyahat giderleri, vb.) Sistem geliştirme maliyeti. Sistem bakım giderleri (yıllık maliyet) Danışmanlık giderleri: Projenin herhangi bir aşamasında harici bir danışman gerekiyorsa Eğitim giderleri: her türlü personel için (geliştiriciler, operatörler, implantörler, son kullanıcılar vb.) malzeme: Kağıt, toner, vb. İlgili personelin öğrenme eğrisinden elde edilen maliyetler Finansal maliyetler, reklam maliyetleri, vb.

Faydaların tahmini için aşağıdakiler gibi sorular dikkate alınmalıdır:

Artan üretkenlik: Tasarruf veya insan kaynaklarının daha iyi kullanımı Mevcut sistemin bakım maliyetlerinde tasarruf, Donanım ve yazılım satın alma ve bakımında veya değiştirilen platformların yeniden kullanımında tasarruflar Satış ve sonuçların artması ve yönetim iyileştirmesi (stok rotasyonu, “tam zamanında”, müşteri ilişkileri yönetimi, vb.) Her türlü malzeme tasarrufu: sistem tarafından sağlanan elektronik veriler ile değiştirilir, örneğin: kağıt, posta, Finansal faydalar Diğer somut faydalar: Dış kaynakların tasarrufu, danışmanlık, eğitim, vb. Maddi olmayan faydalar: Ürün veya hizmet kalitesinde artış, şirket imajının iyileştirilmesi, müşteri hizmetlerinde iyileşme, sömürü vb.

Verimlilik: Verimlilik, yazılım üretiminin ekonomik yönleriyle en güçlü ilişkili göstergelerden biridir. Sadece bu önleme adanmış standartlar vardır (IEEE, 1992) de en tartışmalı ve kesin olmayanlardan biridir. (Oded ve Mounford, 2008)

Metriklere göre bu ekonomik göstergeler, yazılımda beklenen kaliteye ulaşmanın yoludur.Bölüm 3, yazılım geliştiren işletmelerde gerçek maliyetlerin kaydedilmesinin ve uygun incelemenin yapılmasının önemine ilişkin bir çalışmayı göstermektedir.

Maliyet verimliliği, bir projenin yürütülmesinin uygunluğunun iki faktörün ortak gözlemiyle belirlendiğini ortaya çıkarır:

Maliyet: bilgisayar çözümünün uygulanmasını, donanım / yazılım sisteminin satın alınmasını ve işletmeye alınmasını ve ilgili işletme maliyetlerini içerir Verimlilik: nihai mal ve hizmetler (sonuçlar) ile bunun için gereken girdiler arasındaki ilişki olarak anlaşılır. (çaba). Bu nedenle, kaynak harcamalarının sonuçlarla ne ölçüde gerekçelendirildiğinin ölçülmesi, maliyetlerin en aza indirilmesi veya girdilerin optimize edilmesi meselesidir.

1.3.1 Yazılım Geliştirmede Maliyetlerin Hesaplanması

Yazılımı kullanma ihtiyacı herhangi bir insan etkinliğinde arttığında, uygulanması daha karmaşık ve zordur. Sistemlerin tasarımını ve geliştirilmesini kolaylaştıran daha fazla teknik olmasına rağmen, kullanıcıların yeni talepleri ve yeni uygulama alanları yeni sorunlar yaratıyor. Uygulamanın geliştirilmesine başlamadan önce, çeşitli yazılım parametrelerinin planlama, ölçüm ve tahmin süreçlerine giderek daha fazla dikkat etme ihtiyacının yaratılması.

Bu ihtiyaç, yazılım proje yönetimini hayati öneme sahip bir görev haline getirmekte ve çaba tahmini bu ürünlerin tamamlanması için gerekli olan kilit noktalardan, zamandan ve parasal maliyetlerden biridir. Bu parametreler hakkında iyi tahminler yapılmadan, nihai ürünün kararlaştırılan zaman dilimi içinde teslimini imkansız hale getiren öngörülemeyen olaylar ve sorunlar ortaya çıkmaya başlar ve bunun sonucunda giderler ve ekonomik kayıplar artar. (Alvarez, 2009)

Bir yazılım ürününün maliyetini tahmin etme işlemi, güvenilir bir tahminde bulunmak için kuruluşta kullanılan bir dizi teknik ve prosedürden oluşur. Bu, projenin tüm yaşam döngüsü boyunca kullanılması ve danışılması gereken sürekli bir süreçtir. Aşağıdaki adımlara ayrılmıştır (Agarwal ve Kumar, 2006):

Büyüklük tahmini, maliyet ve çaba tahmini, zaman programlama tahmini, hesaplamalı kaynak miktarının tahmini, risklerin yokluğu, denetim ve onay, tahmin raporlarının yazılması, sürecin ölçülmesi ve iyileştirilmesi (Agarwal ve Kumar, 2001)).

Yazılım tahmin sürecinin farklı aşamaları arasındaki etkileşim aşağıda gösterilmiştir.

Yazılım projesi tahmin faaliyetleri

Çizim 2 Yazılım projelerini tahmin etmeye yönelik faaliyetler. Kaynak: kendi kendine yapılan.

Bu tahminler, kontrolü zor olan dış faktörlerin etkisine bağlı olasılıklara dayanmaktadır. Bu olasılıklara ek olarak, kuruluş tarafından her zaman kolayca erişilebilir ve erişilebilir olması gereken tarihi bilgilere başvurmak gerekir. Gereksinimlerin iyi bir şekilde belirlenmesinin önemini vurgulamak önemlidir, bir proje, gereksinimlerin doğru ve kapsamlı bir spesifikasyonu olmadan başarılı olamaz (Larman, 1999).

Kestirime ayrılan çaba ve zaman miktarı, projenin büyüklüğüne, geliştirme ekibine ve gerçekleştirilecek hedefe bağlıdır. Projenin niteliği ve geliştirildiği ortam, bu görevdeki faktörleri belirler ve kullanılan tahmin yöntemini büyük ölçüde etkiler.

Bir yazılım projesi için bütçeyi ve zamanı tahmin etmenin iki farklı yolu vardır: maliyet modellerini kullanma ve benzerliğe dayalı muhakeme kullanma. Her iki seçenekte de daha önce veritabanlarında depolanmış olan önceki projelerin tarihsel bilgilerine ve bilgilerine başvurmak gerekir. Tahminin dayandığı dört temel nokta vardır:

Projenin tamamlanma süresini veya maliyetini tahmin etmek ve tahmin etmek zorunda kalacak olan proje yöneticilerinin deneyim ve olgunluğuna dayalı olarak konu profesyonellerinin düşünceleri ve görüşleri. uzmanlar kuruluşa ait olmadığı ve kuruluşun kendi uygulamalarına aşina olabileceği veya aşina olamayacağı için profesyonellerin ve proje yöneticilerinin üyeleri olarak düşünülmeli ve ele alınmalıdır Son olarak, varlığı ima eden formül ve işlevlerin kullanımı Tahminlere iyi bir yaklaşımı temsil eden nicel verilerin analizi Önceki projelerden hesaplanan ve oluşturulan standart zaman faktörlerinin kullanımı.

Tahmin teknikleri, çoğu durumda çözülmesi gereken sorunun tek parça olarak kabul edilemeyecek kadar karmaşık olduğu bir problem çözme şeklidir. Bu nedenle, sorunun yazılım geliştirme sürecinin her aşamasında ayrı ayrı tahmin edilen bir dizi küçük sorun olarak ortaya çıkması önerilmektedir.

Tahmin, toplam sistem tahminini oluşturacak her yazılım gereksinimini dikkate almalıdır. Çeşitli tahmin teknikleri analiz edilmeli ve bazı yazılım ölçülerinin kullanımı, proje hakkında daha çok şey bilindiği için tahminler iyileştirilmeli, nihai hedef, gerçeğe olabildiğince yakın bir tahmin yapmaktır. Aşağıda yazılım geliştirme sürecinde tahmin edilecek aşamalar bulunmaktadır.

Yazılım geliştirme süreci

Resim 1 Yazılım geliştirme süreci. Kaynak: kendi kendine yapılan.

Tahmin modelleri fikri, uygulama yazılımının yapımında maliyetlerin hesaplanması için sistemler ve yöntemler sağlamaktır, yazılımın maliyetinin çoğu bugün analiz saatlerinin maliyetindedir, elde etmek için kullanılması gereken tasarım, programlama ve testler. Bu nedenle, burada maliyet tahmini hakkında konuştuğumuzda, esasen gerekli olan insan çabasına, yani her aşama başlangıçtan itibaren bile hayati öneme sahip olmasına rağmen, yazılımı oluşturmak için gereken çalışma saatlerine atıfta bulunuyoruz. Daha sonra rafine edilmiş bir ön fikriniz olmalıdır.

İhtiyaç analizi aşamasında, asıl amacın gerçekten neyin gerekli olduğunu tanımlamak ve dokümante etmek, bunu geliştirme ekibinin müşterisine ve üyelerine açık bir şekilde iletmek olduğu belirtilmelidir (Larman, 1999).

Yazılım geliştirmedeki maliyetlerin hesaplanması yalnızca, boyutu, zamanı, kaynakları, geliştirmesi gereken insanları tanımayı veya tahmin etmeyi amaçlayan bir dizi metrik kullanılarak yapılabilir, bazıları aşağıda açıklanmıştır.

1.3.2 Yazılım Geliştirme Metrikleri

Yazılım mühendisliği alanında, “metrikler” ve “önlemler” genellikle birbirinin yerine geçmektedir, ancak yine de bu terimler arasında farklılıklar bulunmaktadır. Bir ölçü, işlem veya ürünün bazı niteliklerini (genişletme, miktar, boyutlar, kapasite, boyut vb.) Nicel olarak belirtir. Bir metrik, IEEE (Elektrik ve Elektronik Mühendisleri Enstitüsü) standartlarının sözlüğü (IEEE Yazılım Mühendisliği Terminolojisi Standart Sözlüğü, 1993) tarafından "bir sistemin, bileşenin veya sürecin belirli bir niteliğe sahip olduğunun niceliksel ölçüsü" olarak tanımlanır.. Bir bileşen içindeki hata sayısı gibi yalnızca bir tür veri toplanırsa, bir hesaplama oluşturulmuştur.

Bir yazılım ölçüsü bir şekilde bireysel ölçümlerle ilgilidir, her bir incelemede veya testte bulunan hata sayısı olabilir (Pressman, 1998).

Yazılım mühendisleri, ölçümlerden, süreci veya yazılım projesini kontrol etmeleri için onlara bilgi sağlayan metrikler geliştirir. Burada bu terimler arasındaki fark yatıyor.

Ölçüm, mühendislik dünyasında çok yaygındır. Tüketim gücü, ağırlıklar, fiziksel boyutlar, sıcaklıklar, voltajlar, gürültü sinyalleri birkaç yönü belirtmek için ölçülür. Ölçüm, yazılım mühendisliği dünyasında yaygın olmaktan, daha karmaşık olmaktan, ölçüm yaparken zorluklarla karşılaşmaktan ve önlemlerin nasıl değerlendirileceğinden çok uzaktır, bir ürünü ölçmek, ürünün kalitesini belirtmek için birkaç neden vardır., geliştiricilerin verimliliğini değerlendirmek, yazılım mühendisliğinin yeni yöntem ve araçlarının kullanımından elde edilen faydaları kalite açısından değerlendirmek, tahmin için bir temel oluşturmak, projenin maliyetini ölçmek, diğerleri arasında.

Fiziksel dünyanın ölçümleri iki kategoriye ayrılabilir: doğrudan önlemler ve dolaylı önlemler (Metrikler, tahmin ve yazılım planlaması, 2001):

Doğrudan Ölçümler. Mühendislik sürecinde maliyet ve uygulanan çaba, üretilen kod satırları, yürütme hızı, bellek boyutu ve belirli bir zaman diliminde gözlemlenen hatalar bulunur.

Dolaylı Önlemler. İşlevselliği, kaliteyi, karmaşıklığı, verimliliği, güvenilirliği, bakım kolaylığını vb. Bulacaksınız.

Bu araştırmada, ölçümlerin aşağıda mümkün olduğunca doğru bir şekilde hesaplanmasını sağlamak için bir dizi metrik incelenmiştir.

Yazılım metrikleri: İşlevsellik, karmaşıklık, verimlilik gibi yazılım geliştirme ile ilgili olanlardır.

Teknik metrikler: Yazılımın özelliklerine odaklanırlar, örneğin: mantıksal karmaşıklık, modülerlik derecesi. Sistemin yapısını, nasıl yapıldığını ölçer.

Verimlilik ölçümleri. Yazılım mühendisliği sürecinin performansına odaklanırlar. Başka bir deyişle, tasarlayacağım yazılım ne kadar verimli.

Kişi odaklı metrikler. İnsanların bilgisayar yazılımlarını geliştirme yöntemleri ve özellikle de araç ve yöntemlerin etkinliği konusundaki insan bakış açısı hakkında ölçümler ve bilgiler sağlarlar. Bunlar, sistemi gerçekleştirecek olan personelim için yapacağım ölçümlerdir.

Boyut odaklı metrikler. Yazılımı ne zaman bitireceğimi ve kaç kişiye ihtiyacım olacağını bilmek. Bir yazılım kuruluşu basit kayıtları tutuyorsa, yazılıma ve geliştirilme sürecine doğrudan yönelik tedbirlerdir.

Bu metrikler, bir çalışma aracı oluşturan tahmin teknikleri oluşturmak için birleştirilir. Hem projeleri planlayabilmek hem de kontrol edebilmek için boyut ölçüm kriterlerini birleştirmek ve süreç iyileştirme lehine projeler arasında çalışmalar ve analizler yapmak gerekmektedir (Park, 1992). En çok kullanılan teknikler aşağıda gösterilmiştir.

1.4 Yazılım geliştirmede maliyet tahmin teknikleri

Projenin kapsamını önceden belirleyerek, tahminler için yazılım metriklerini kullanarak ve projeyi bireysel olarak tahmin edilen daha küçük parçalara bölerek yazılım geliştirme için çeşitli tahmin teknikleri geliştirilmiştir (Angelis L & Stamelo, 2000).

Yazılım endüstrisindeki büyüme ve maliyet tahmininin karmaşık bir faaliyet olması nedeniyle, piyasada farklı maliyet tahmin araçları sunmaya kendini adamış şirketler artmıştır. 2005 itibariyle bu tahmin araçlarından bazıları şunlardır: COCOMO II, CoCots, CoStar, CostModeler, CostXpert, SoftCost.

Bu tahmin araçları farklı şirketler tarafından geliştirilmiş ve aynı olmasa da, aslında ortak işlevlerin bir çekirdeğini sağlama eğilimindedirler. Ticari yazılım tahmin araçlarının temel özellikleri şu nitelikleri içerir: güvenilirlik ve kalite tahmini, değer ve risk analizi, yatırım getirisi, proje yönetim araçlarıyla veri paylaşma imkanı, geçmiş verileri toplamak için ölçüm araçları, maliyet ve geçmiş verileri öngörülen verilerle birleştiren tahminleri tamamlama zamanı, yazılım süreci değerlendirme desteği, birden çok projenin istatistiksel analizi.

Bir projeyi planlarken, gereken insan çabası, projenin kronolojik süresi ve maliyet hakkında tahminler elde edilmelidir. Çoğu durumda, tahminler tek rehber olarak geçmiş deneyimler kullanılarak yapılır. İyi metriklere sahip olmak, projenin çabasıyla doğru bir korelasyon sağlar ve tahminini kolaylaştırır.

Her ne kadar “Taşınabilir maliyet modeli yoktur. Başka birinin kendi kurulumunuzda maliyeti tahmin etmek için kullanabileceğiniz bir dizi formül geliştirmesini bekliyorsanız, muhtemelen sonsuza kadar beklemeniz gerekecektir. ” (Marco, 1982)

Proje tahmininin amacı maliyetleri düşürmek, hizmet ve kalite seviyelerini arttırmaktır. Yazılım sürecinin belirli yönlerini ölçerek, geliştirme sırasında neler olacağına dair üst düzey bir görüşe sahip olabilirsiniz. Önceki süreçlerin ölçümleri, mevcut süreçlerin tahminlerinin yapılmasına izin verir. Süreç özelliklerinin gelişimin erken aşamalarındaki ölçümleri, sonraki aşamalarda tahminler yapılmasına olanak tanır.

Süreç değerlendirmesi, geliştirme başlamadan önce, geliştirme süreci sırasında, üründen müşteriye geçiş sırasında ve bakım aşaması boyunca karar almaya yol açar.

Maliyet tahmini, bir yazılım sistemi oluşturmak için gereken en olası çaba, zaman ve personel düzeyi hakkında tahminler yapmayı içerir. Bunlar yazılım ömrü boyunca gerçekleştirilir.

Bir projenin fizibilitesini teklif etmek veya belirlemek için ön tahminler gereklidir, bunlar en zor ve en az doğru olanıdır.

Maliyetleri tahmin etmenin yolları vardır, bunlar şunlar olabilir:

Uzman görüşü: Bir geliştirici veya yönetici projenin parametrelerini tanımlar ve uzmanlar deneyimlerine dayanarak tahminler yaparlar.

Delphi Tekniği: İstişarede bulunan uzmanların görüşlerini sistemleştirmeye ve geliştirmeye izin verir.

Analoji: Uzman görüşünden daha resmi bir yaklaşım. Uzmanlar, önerilen projeyi, özel benzerlikler ve farklılıklar bulmaya çalışan bir veya daha fazla önceki proje ile karşılaştırmaktadır.

Projelerin Tarihsel Tabanı.

Ayrıştırma teknikleri: Yazılımın ayrıştırıldığı her bileşen veya görevlerin ayrıştırıldığı düşük düzeyli görevler için tahminler yapılır. Düşük seviyeli tahminler, tüm proje için bir tahmin oluşturmak üzere birleştirilir. Başka bir deyişle, projenin toplam maliyeti, projenin bölündüğü tüm bileşenlerin tahminlerinin eklenmesinin sonucudur. İşte dünyada en çok kullanılan tekniklerden bazıları.

1.4.1 KOKOMO

1981 yılında Barry Boehm tarafından oluşturulan COCOMO Modeli, adı COnstructiveCOst MOdel (Yapıcı Maliyet Modeli) için yazılım için bir tahmin modelleri hiyerarşisi anlamına gelir. Hiyerarşi aşağıdaki modellerden oluşur (COCOMO Model tanım kılavuzu., 1990).

COCOMO temel. Ara LOC.COCOMO'daki tahmini program boyutuna göre geliştirme çabasını ve maliyetini hesaplayın. Programın büyüklüğüne ve ürün, donanım, personel ve proje özelliklerinin öznel değerlendirmesini içeren bir dizi maliyet sürücüsüne göre geliştirme çabasını hesaplayın . COCOMO detaylı. Ara versiyonun özelliklerini içerir ve sürecin her aşamasında maliyet analizlerinin (analiz, geliştirme, vb.) Etkisinin bir değerlendirmesini yapar.

COCOMO, kod satırlarını temel alan bir araç olup, maliyeti tahmin etmek için çok güçlü kılar ve yalnızca boyuta dayalı çabayı ölçen diğerleri gibi değil. Bir proje yöneticisi için bir maliyet tahmin aracı gereklidir; ve bu araç COCOMO ile ilgili olabilir, çünkü bu teknik yazılım tahmini için en eksiksiz ampirik modellerden birini temsil eder (Bumett, 1998).

COCOMO modelinde tespit edilen eksikliklerden biri, proje maliyetinin analizi için geliştiricinin maaşını, yazılım projesinin maliyetlerini etkileyen diğer masraf unsurlarını dikkate almadan analiz etmeleridir.

1.4.2 KOKOMO II

COCOMO II, yeni bir yazılım geliştirme etkinliği planlarken maliyet, çaba ve zamanın tahmin edilmesine izin veren ve modern yaşam döngüleriyle ilişkili bir modeldir. Yazılım mühendislerinin gereksinimlerine daha uygun güncellemeler ve yeni uzantılar dahil olmak üzere COCOMO'dan geliştirilmiştir (Heemstra, 1992).

Proje planlaması desteği, proje personeli tahmini, yeniden planlama, izleme, sözleşme görüşmeleri ve tasarım değerlendirmesi gibi yazılım tahmin edicileri tarafından ifade edilen bu ihtiyaçları karşılamak üzere oluşturulmuştur.

Maliyet faktörleri ürünün doğası, kullanılan donanım, ilgili personel ve projenin özellikleri ile ilgili hususları açıklar. Ölçek faktörleri kümesi, bir yazılım projesi boyut olarak arttıkça üretilen tasarruf ve kayıpları açıklar. Bir model ya da başka bir modelin kullanılması, projenin ayrıntı düzeyine, gereken tahminlerin uygunluğuna, gereksinimlerin tanımına ve mimarinin ayrıntılarına bağlıdır (Gause ve Weinberg, 1989).

1.4.3 Kod Satırları ve İşlev Noktaları

İşlev noktaları için metrikler, Uluslararası İşlev Noktası Kullanıcı Grubu tarafından sağlanan yönergelere dayanmaktadır (IEPUG, 1994). İşlev noktaları bir yazılım sisteminin işlevselliğini ölçmeye çalışır. Amaç, sistemi tam olarak karakterize eden bir sayı elde etmektir. Tahmin ediciler, yazılım geliştirme yaşam döngüsünün ilk aşamalarında mevcut olan bilgilere dayalı olduklarından faydalıdır.

Kod satırı verileri (LDC) ve işlev noktaları (PF), yazılım projesini tahmin ederken iki şekilde kullanılır:

Yazılımın her bir öğesini kalibre etmek için kullanılan tahmin değişkenleri Maliyet ve çaba projeksiyonlarını geliştirmek için tahmin değişkenleriyle birlikte kullanılan önceki projelerden toplanan temel metrikler.

Bu teknikler farklıdır ancak ortak özelliklere sahiptir. Proje planlayıcısı, yazılımın kapsamının kısıtlı bir ifadesiyle başlar ve bu ifadeden, yazılımı ayrı ayrı tahmin edilebilen küçük alt işlevlere ayırmaya çalışır. Ardından, her alt işlev için LDC veya PF'yi (tahmin değişkeni) tahmin edin. Ardından temel verimlilik metriklerini uygun tahmin değişkenine uygulayın ve alt işlev için maliyet ve çabadan yararlanın. Alt fonksiyon tahminlerini birleştirmek, tüm proje için toplam tahmini üretir.

Ayrışmanın gerektirdiği ayrıntı düzeyinde farklılık gösterirler, LDC tahmin değişkeni olarak kullanıldığında, fonksiyonel ayrışma kesinlikle gereklidir ve çoğu zaman önemli düzeyde ayrıntılara yol açar. Şu anda bu teknik, kod satırlarını analiz ederek bir projenin gerçek maliyetini yansıtmamaktadır, birkaç kod satırına sahip bir proje olabilir ve kendisine tahsis edilen çaba, zaman, insan ve malzeme kaynakları, başka bir projeden daha büyüktür. daha önce geliştirilmiş ve daha fazla kod satırına sahip.

1.4.4 Delphi Teknikleri

1940'larda ABD'de kuruldu. 1981 yılından itibaren Barry Boehm tarafından yazılım alanında kullanılmaya başlandı. İzlenecek adımlar şunlardır:

Bir koordinatör, her uzmana önerilen projenin spesifikasyonunu ve görüşlerini ifade edecek bir form sağlar. Uzmanlar formu isimsiz olarak dolduruyor. Koordinatör soruları sorabilirler ama kendi aralarında değil. Koordinatör, her uzmana toplanan görüşlerin ortalama değerini sunar. Olası değişikliklerin nedenlerini belirten yeni bir isimsiz tahmin istenmektedir (Boehm, 1981).

Fikir toplama süreci fikir birliğine varılana kadar tekrarlanır. Hiçbir zaman grup toplantısı yapılmaz.

Geniş Bant Delphi: Barry Boehm tarafından önerilen Delphi tekniğinin iyileştirilmesi. İzlenecek adımlar şunlardır:

Koordinatör, her bir uzmana önerilen projenin bir spesifikasyonunu ve görüşlerini belirtmek için bir form sağlar.Kordinatör, projeyle ilgili görüş alışverişinde bulunmak için uzmanları bir araya getirir ve uzmanlar formu anonim olarak doldurur. toplanan görüşlerin ortalama değeri. Olası değişikliklerin nedenlerini belirtmeksizin yeni bir anonim tahmin istenir Koordinatör, uzmanların tahminleri arasındaki farkların nedenlerini tartışmaları için bir toplantı çağırır Formlar isimsiz olarak doldurulur ve 4, 5 ve 6. maddeler tekrarlanır fikir birliğine varılana kadar.

Bu tekniğin ana avantajı, başka yollarla değerlendirilmesi zor olan önceki deneyimlere (personelin özel özellikleri, projenin özellikleri) dayanarak mevcut proje hakkında uzman görüşünü toplamasıdır.

Ana dezavantaj, konsültasyonda seçilen kişilerin öznelliği veya deneyimsizliğinde bulunur.

Bölüm Sonuçları

Bu bölüm karar vermede maliyet analizinin önemini göstermektedir. Avantajları ve dezavantajları dikkate alınarak yazılım projelerinin fizibilitesini tahmin etmek ve analiz etmek için ana modeller üzerinde bir çalışma yapılmıştır. Tahmin sistemleri tarafından sağlanan çözümlerin analizi, tam bir kesin tahmin olmadığını, ancak karar verme için yüksek düzeyde bilgi sağladıklarını gösteren bir analiz gerçekleştirmiştir. Bu araştırma sürecini gerçekleştirdikten sonra, COCOMO'da kullanılan ana metrikler ve maliyet-fayda ekonomik göstergeleri ile bağlantılı olarak güvenilirlik ve gelişme hızı sağlayan çevik Scrum metodolojisinin kullanımı tanımlandı,Üretkenlik ve çaba sorununu çözmek için araçlar olarak ortaya çıktı.

Önerilen metrikler, bir projede yer alan uzmanların bilgi düzeyini ölçen, bilgi yönetimini, yeni bilgilerin dahil edilmesiyle belirlenen katma değer süreçlerinin analiz ettiği bir seviyeye aktaran yeni bir unsur içermektedir. iş süreçleri. Bilgiyi yönetmek, yönetim sistemlerine kendi ve organizasyonel olmayan deneyimlere dayanarak öğrenmeleri için istihbarat kazandırmaktır. Zenginleştirmenin ve yeni bilginin ortaya çıkmasının know-how'ın yeniden kullanılmasıdır.

Ürünü yaratan kişilerin sahip olduğu bilgi düzeyinin belirlenmesi, kuruluşun sunduğu ürün ve hizmetleri kalıcı olarak zenginleştiren ve rekabetçi konumunu geliştiren kapasitelerin ve maddi olmayan kaynakların yönetimine dayanan sürekli iyileştirme dinamiğine dayanır.

Sürekli iyileştirme, optimum verimlilik düzeylerinin araştırılmasını ve aynı zamanda kalitenin artmasını gerektirir. Verimsizliklerin azaltılması ve önceki deneyimlerin dahil edilmesi ve diğer bağlamlarda başarılı olan uygulamaların yeniden kullanılması anlamında ilerleme ve optimizasyon anlamına gelir.

Ayrıca maliyet-fayda, program ve kalite arasında güçlü bir ilişki kurulur ve aralarında olması gereken sinerjiyi savunur. Kahramanlık Gerilla Ernesto Che Guevara'nın sözlerini bir öncül olarak alarak, "İnsandan kaybedilen son iş parçacıklarından bile yararlanmamızı sağlayan daha ayrıntılı maliyet analizi yapmalıyız" dedi.

Konunun uzmanları tarafından analiz edilen metrikler, aşağıda gösterilen üç gruba ayrıldı:

Ürün metrikleri: Yazılım ürününün, geliştirilmesinin herhangi bir aşamasında, gerekli güvenilirlik, veritabanının boyutu, ürünün karmaşıklığı gibi gereksinimlerden kuruluma kadar olan ölçüleridir.

Personel metrikleri: Analist kapasitesi, programcı kapasitesi, personel sürekliliği, uygulama deneyimi, platform deneyimi, dil ve araç deneyimi, geliştirme ekibi uyumu, çalışma ortamı, grubun organizasyonu ve kompozisyonu iş.

Proje metrikleri : Yazılım araçlarının kullanımı, çoklu site geliştirme, geliştirme için gerekli zaman çizelgesi, sürecin olgunluğu, projenin büyüklüğü, projenin kalitesi.

Süreç metrikleri: Bunlar toplam geliştirme süresi, gün / insan veya ay / insan ürün geliştirme çabası, kullanılan metodoloji türü veya programcıların ortalama deneyim seviyesi gibi yazılım geliştirme sürecinin ölçüleridir. ”

Bu metriklerin çoğu ilişkilendirildi ve diğerleri işletme için büyük önem taşıyordu ve dahil edildi. Bu seçimin temel amacı, oluşturulan projelere göre düzeltilmeleri, analizlerinin hantal olmaması, çalışmayı kolaylaştırmaları ve projenin maliyetini hesaplamaya yardımcı olmaları ve ekibin onu sürekli olarak geliştirmelerine izin vermesidir. Önerilen metrikler, değerlendirilebilmeleri, kolayca elde edilebilmeleri (makul bir maliyetle), geçerli, tam olarak ölçmek istediğiniz şeye göre ayarlanabilmeleri için ayarlanabilmeleri için tarafsız, basit, tam olarak tanımlanabilir olmalı, sağlam, küçük değişikliklere nispeten duyarsız olmalıdır süreçte veya üründe önemli.

Tasarlanan metrikler, ürün kalitesini, müşteri memnuniyeti düzeyini, bir yazılım ürününün paydaşları için değer derecesinde temsil edilen süreç değerini, nihai ürünü kaliteyle donatmayı, ayırt etmeyi sağlayan temel unsurları içerir. rekabet ortamı.

Seçilenler aşağıda açıklanmıştır, bunlar daha etkili ve objektif bir hesaplamayı garanti etmek için ölçülebilir, ölçülebilir hale getirmek için 0 ila 100 arasında bir değer aralığına sahiptir.

Seçilen metrikler:

Geliştirme ekibi uyumu: Bu faktör, proje katılımcıları arasındaki senkronizasyon zorluklarını dikkate alır: kullanıcılar, müşteri, geliştiriciler, bakım yöneticileri ve destek alanları. Bu zorluklar hedeflerin uzlaştırılmasında, deneyim eksikliğinde ve ekip çalışmasına aşinalıkta ortaya çıkabilir. Geliştirme ekibinde müşterileri ile yüksek uyumun sağlanması, projenin ilk aşamasında belirlenen gereksinimlerin, ani değişiklikler olmaksızın, ürünün kalitesini garanti ederek sonuna kadar yönlendirdiğini garanti eder.

Bu metrik, aşağıdaki özelliklerin tartılmasıyla hesaplanır:

karakteristikleri	Düşük (0-39)	Orta (40-79)	Yüksek (80-100)
Takım üyeleri arasında hedefleri uzlaştırma uyumluluk, yetenek ve isteklilik	küçük	Temel	Önemli
Takım çalışması deneyimi ve zorluklara tepki	küçük	Temel	Önemli
Ortak amaç ve hedeflerin ortak vizyonu	küçük	Temel	Önemli

Tablo 1 Takım uyum metriği.

Kullanılan teknoloji ile ilgili deneyim: Bu faktör, yeni ve güçlü tasarım araçlarını, veritabanı yöneticilerini, grafik arayüzleri, ağları, çerçeveyi vb. Bilmenin önemini kabul ederek ekip verimliliği üzerinde büyük bir etkiye sahiptir. Önemli tecrübeye sahip bir geliştirme grubuna sahip olmak, ürünün tahmini sürede hazır olmasını sağlar, proje yöneticisi çalıştıkları teknolojilere hakim olan uzmanlarla çalışırken güvende hisseder, bu da işe kalite katar başarılabilir.

karakteristikleri	Düşük (0-39)	Orta (40-79)	Yüksek (80-100)
Kullanılan teknoloji ile deneyim	küçük	Temel	Önemli

Tablo 2 Kullanılan teknoloji ile metrik deneyim.

Veri modelinin karmaşıklığı: veri modeli, belirli bir soruna müdahale eden gerçekliğin unsurlarını ve bu unsurların birbiriyle nasıl ilişkili olduğunu tanımlamamızı sağlar. Karmaşık bir veri modeline sahip olmak, geliştiricileri başlangıçtaki gereklilikleri karşılayarak çözümü tüm akıl, tasarım, modelleme ve programlamak için kullanmaya zorlar.

Karmaşıklık seviyesi	Düşük (0-39)	Orta (40-79)	Yüksek (80-100)
Veri modeli karmaşıklığı	1 ila 40 sınıf	41 ila 60 sınıf	60'tan fazla dersler

Tablo 3 Veri modelinin metrik karmaşıklığı.

İdari tesisler: ticari, ekonomik veya fiili proje yönetimini yürütmek için gerekli taşımacılığı, diğerlerinin yanı sıra depolama cihazları, sabit diskler, kağıt, yazıcılar, telefon, dizüstü bilgisayar, internet hesapları gibi iş araçları elde etmek için tesisleri içerir. Destek alanları, bitmiş bir ürünü zamanında elde etmede temel bir rol oynar, bu nedenle hem müşteriyle hem de ekip içinde çalışmayı sürdürmek için çalışmaları gereklidir.

karakteristikleri	Düşük (0-39)	Orta (40-79)	Yüksek (80-100)
Hedeflere ulaşma isteği, yeteneği ve yönetimi	küçük	Temel	Önemli
İş aleti edinme kolaylığı	küçük	Temel	Önemli
İdarenin ve çalışma ekibinin penetrasyonu.	küçük	Temel	Önemli

Tablo 4 İdari tesisler metriği.

Programlama diliyle ilgili deneyim: Programlama diline hakim olmak, bilgisayarlar tarafından gerçekleştirilebilen işlemleri ifade etmenizi sağlar. Programlama dilinin tam komutuna sahip bir ekibe sahip olmak önemli bir avantajdır, çünkü daha az geliştirme süresi sağlar, gereksinimlerin doğru programlandığından, hata olmadığından, ekibe parlaklık ve güvenlik katar. Eğitim daha azdır, çünkü kanıtlanmış bilginin görevi yerine getirmek için ideal olduğu düşünülmektedir.

karakteristikleri	Düşük (0-39)	Orta (40-79)	Yüksek (80-100)
Programlama dili ile deneyim	küçük	Yarım	Önemli

Tablo 5 Deneyim ölçümlerini programlama diliyle yapın.

Personelin sürekliliği: Bu faktör, bir yazılım projesinden etkilenen personelin yıllık kalıcılık derecesini ölçer, ekibin üyelerinde istikrarlı olması önemlidir, çünkü proje başladıktan sonra üyeleri işin tam kontrolüne sahip olanlardır. Onlarla dalgalanma olduğunda, nihai ürünün kalitesi etkilenir. Belirtilen hedeflere ulaşmak için bir lidere sahip olmak önemlidir: Olası değerler şunlardır:

karakteristikleri	Düşük (0-39)	Orta (40-79)	Yüksek (80-100)
Personelin sürekliliği	küçük	Temel	Önemli

Tablo 6 Personel sürekliliği metrikleri.

Gerekli geliştirme programı: Bu faktör, çalışma ekibine uygulanan zaman sınırlarındaki kısıtlamaları ölçer. Değerler, belirlenen terimlerin uzatılması veya hızlandırılması dikkate alınarak tanımlanır. Teslim sürelerinin hızlandırılması, daha sonraki kalkınma aşamalarında daha fazla çaba üretmekte ve burada daha kısa sürede çözülmesi gereken daha fazla sorun ortaya çıkmaktadır. Sözleşmede anlaşmayı sürdüren bir program, oluşturulan projeye kaliteye katkıda bulunur. Bu faktöre, müşterinin imzasının sözleşmede kararlaştırıldığı şekilde eklenmesi gerektiği, bu gerekliliklerin yerine getirilmesine katkıda bulunur. Bir yazılım projesinin etkin planlanması, ilerlemesinin ayrıntılı projeksiyonuna, ortaya çıkabilecek sorunları öngörmeye ve bunlara geçici çözümler hazırlamaya bağlıdır.Proje yöneticisi, uzmanlarla birlikte, gereksinimlerin tanımından bitmiş sistemin teslimine kadar projenin tasarımından sorumludur.

karakteristikleri	Düşük (0-39)	Orta (40-79)	Yüksek (80-100)
Geliştirme programı gerekli	küçük	Temel	Önemli

Tablo 7 Metrik gelişme programı gereklidir.

Bu analiz projenin karmaşıklığını gösterir, sürekli tablo değerleri gösterir. Projenin karmaşıklığı mevcut olduğunda, saatlik oranla tahmin edilen zamanı hesaplamaya devam ediyoruz, daha sonra elde edilen değer, projenin karmaşıklığını gösteren metriklerin toplamını temsil eden yüzdeye uygulanır. Bu toplam, 7 metriğin seçilmesi dikkate alınarak% 70'e kadar olabilir ve bu da önemli ürüne katma değer sağlar.

karakteristikleri	Düşük (0-29)	Orta (30-59)	Yüksek (60-70)
Proje karmaşıklığı	Düşük	Yarım	Önemli

Tablo 8 Projenin karmaşıklığı.

Metrikler kullanarak projenin karmaşıklığının hesaplanması, aşağıdaki özelliklere sahip tahmin parametrelerine ilişkin hesaplama yöntemine dayanacaktır: objektif, kolayca tanımlanabilir, sayısal değerlendirmeye uygun, geçerli, satış öncesi aşamada mevcut bilgilerle kolayca elde edilebilir, daha fazla bilgi elde edildikçe rafine edilmeye hazır, kullanılan metodolojinin unsurlarıyla uyumludur.

Misal:

Projenin karmaşıklığını hesaplamak için bir başvuru yapmaktan oluşan bir projenin tahmini süresi 40 adam-saat, 11,00 $ ve ortalama karmaşıklığı 48'dir.

Hesaplamalar:

Erkek saatlerini hesaplıyorum

40 x 11 = 44

Düşük proje karmaşıklığı

44'ün% 48'i = 21,12

Proje maliyeti:

44 + 21.12 = 65.12

Projenin maliyeti kişi başına 65,12 $ olurdu, karmaşıklığı düşüktür, Desoft Camagüey'de bugün kullanılan yöntemle başlangıçta tahmin edilenden daha yüksek bir fiyat gözlemlenebilir.

Bölüm Sonuçları

Tasarlanan metrikler, oluşturulan ürüne değer katmaya ve bugün sahip olmadığı uygun bir satış fiyatına izin vererek karar verme için gerekli hususları sunar.

Bu şekilde, geliştirilecek ürünün karmaşıklığının bir değerlendirmesini geliştirmek için koşullar yaratılır. Bir sonraki bölüm bu prosedürün uygulanmasına ayrılmıştır.

Genel Sonuçlar

Yazılım geliştirmedeki maliyetlerin hesaplanması, bilgisayar ürününün yönetiminde başarıyı garanti etmek ve planlamadan nihai teslimata kadar hizmete kaliteye katkıda bulunmak için gerekli bir araçtır.Önerilen metrikler, satış fiyatını hesaplamak için yeni bir araç oluşturur. yazılım ürünü, ölçen maliyetlerden başlayarak, maddi olmayan, bilgi, uzman ekibin iletişimi, çalışma ortamı, nihai ürüne değer katar.

tavsiyeler

Geliştirme faaliyetindeki maliyetin hesaplanmasını iyileştirmek için önerilen metriklerin uygulanması tavsiye edilir.Yeni yazılım tahmini tekniklerini derinleştirmek için konunun incelenmesine devam edilir.Projelerin proje planlamasından ölçülmesi ve sürekli iyileştirme sürecinin sürdürülmesi yazılım geliştirmenin tüm aşamaları.

kaynakça

Amat, JM (2001). Yönetim kontrolü: bir yönetim perspektifi. İspanya: Gestión 2000. Anthony, RN (1990). Yönetim kontrolü: çerçeve, çevre ve süreç. Meksika: Ediciones Deusto, Avram, DO ve Kühne, S. (2008). Sorumlu İşletme Davranışının Stratejik Yönetim Perspektifinden Uygulanması: Avusturya KOBİ'leri için bir Çerçeve Geliştirilmesi. Journal of Business Ethics, 82 (2), 463.Bass, L., Clements, P. ve Kazman, R. (1997). Uygulamada Yazılım Mimarisi. Boston: Addison-Wesley.Beck, K. (2000). Aşırı Programlama Açıklandı: Değişimi Kucaklayın. Boston: Addison-Wesley.Beck, K. (2004). Aşırı Programlama açıkladı: Değişimi kucaklayın. Okuma, Kitle. Boston: Addison-Wesley.Beck, K. (Şubat 2001, 2001). Çevik Manifesto. 25 Haziran 2011 tarihinde www.agilemani-festo.org adresinden alınmıştır. Biffl, S. Freimut, B. & Laitenberger, O.(2001). Yazılım Geliştirmede Yeniden Denetimlerin Maliyet Etkinliğinin Araştırılması. 23. Uluslararası Yazılım Mühendisliği Konferansı (ICSE'01). IEEE Computer Society, ABD Biffl, S. ve Gutjahr, W. (2001). Takım Büyüklüğü ve Kusur Tespit Tekniğinin Muayene Etkinliğine Etkisi. Yedinci Uluslararası Yazılım Metrikleri Sempozyumu (METRICS'01). IEEE Bilgisayar Topluluğu, ABD Boehm, BW (1981). Yazılım Mühendisliği Ekonomisi. NY: Prentice Hall.Booch, G., Jacobsen, I. ve Rumbaugh, J. (1999). UML Modelleme Dili Kullanıcı Kılavuzu. NY: Addison-Wesley.Booch, G., Jacobsen, I. ve Rumbaugh, J. (2000). Birleşik yazılım geliştirme süreci. NY: Prentice Hall. Camacho, IA (2012). Desoft şirketinde eğitim kursları için maliyet sayfası teklifi. Derece çalışması,Muhasebe Lisansı, Havana Üniversitesi, Havana, Küba, Canós, J., Penadés, MC ve Letelier, P. (2003). Yazılım Geliştirmede Çevik Metodolojiler. Yazılım Mühendisliği ve Veritabanları VIII Konferansı'nda sunulmuştur.. 16 Temmuz 2011 tarihinde http://201.249.238.203/portalopei/images/descargas/medesoft.pdf adresinden erişildi. Hükümet Teknoloji Merkezi. (1998). Sistem Geliştirme Süreci Modellerinin incelenmesi. 5 Mart 2011 tarihinde http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysde v.pdf.Chang, A. (2013) adresinden erişildi. Ulusal Yazılım Şirketi Desoft Maliyet El Kitabı. Camaguey, Küba:. 14 Ağustos 2014 tarihinde http: //cmw.desoft.cu.Colín, JG (2001) adresinden erişildi. Maliyet Muhasebesi. Madrid, İspanya: Mc Graw-Hill, Cueto Ible, E. ve Sánchez Batista, DA (2000).Lojistik operatörü için yeni maliyet sistemi. Yayımlanmamış Yüksek Lisans Tezi, Universidad de Camagüey, Camagüey, Cuba Fagan, ME (1976) Program Geliştirmedeki Hataları Azaltmak için Tasarım ve Kod İncelemeleri. IBM Systems Journal.15, (3), 182-211. García Sánchez, IM (2003). Stratejik yön, yönetim kontrolü ve dış kontrol: süreçlerin entegrasyonuna doğru. İspanya. Barselona Otonom Üniversitesi: Gestión 2000.Gayle, L. (1999). Muhasebe ve maliyet yönetimi (Altıncı baskı). Mexico City, Meksika: Mc Graw-Hill. Gilb, T. ve Graham, D. (1993). Yazılım Denetimleri. Boston: Addison-Wesley, González-Solán, O. ve Martín-Castilla, JI (2010). Küba Camagüey Üniversitesi Stratejik Bilim ve Teknoloji birimi için kontrol göstergelerinin tanımlanması. Yönetim zorlukları, 4 (2), 79. González, CD(2001). Maliyet Muhasebesi. Madrid, İspanya: Mc Graw-Hill. Gordon, G. ve James I. (1999). Yazılım Kalite Güvencesi El Kitabı.: Prentice Hall, Guerrero, MP (2011). Desoft Camagüey şirketinde Sales Management and Control System. Yayımlanmamış Yüksek Lisans Tezi, Camagüey Üniversitesi, Camagüey, Küba Hernández Hidalgo, D., Pérez Avila, JE ve Arias Hernández, JA (2005). Çağdaş iş sisteminde yönetim kontrolü ve yönetimsel rolü. Karar (8), 81-90. Highsmith, J. (2002). Tarihçe: Çevik Manifesto. 4 Ocak 2011 tarihinde http://agilemanifesto.org/history.html.Jones, C. (1996) adresinden erişildi. Uygulamalı Yazılım Ölçümü. Boston: Mc Graw-Hill Larman, C. (1999). UML ve Desenler. NY: Prentice Hall, Lazo, R. ve González, R. (2013). Yazılım ürün serilerine dayalı genel geliştirme modeli.3 Kasım 2013 tarihinde http: //cmw.desoft.cu.León, AP (2014) adresinden erişildi. Desoft Camagüey Proses Kılavuzu,. Camaguey, Küba:. 18 Ekim 2014 tarihinde http: //cmw.desoft.cu.Lorino, P. (1993) 'den erişildi. Stratejik yönetim kontrolü: faaliyet tabanlı yönetim. Barselona, İspanya.: Marcombo, DLM lorenz, JK (1994). Nesneye Yönelik Yazılım Metrikleri. Boston: Prentice Hall, Ortega, AD (2001). Maliyet Muhasebesi. Meksika: Mc Graw-Hill. Pressman, RS (1998). Yazılım Mühendisliği. Pratik bir yaklaşım. NY: Mc Graw-Hill. Ralp Polimeni, FF (1989). Maliyet Muhasebesi. Yönetsel karar verme ile ilgili kavramlar ve uygulamalar. NY: Mc Graw-HillRRHH, DN (2014). Şablon P4 Desoft Camagüey. Camaguey, Küba. 21 Şubat 2014 tarihinde http: //cmw.desoft.cu.Rumiantsev, A. (1975) adresinden erişildi.Komünist oluşumun ekonomi politiği kategorileri ve yasaları. Havana, Küba: Sosyal Bilimler Saez, A. (1993). Maliyet muhasebesi ve yönetim muhasebesi. Mexico City, Meksika: Mc Graw-Hill.Sánchez, A. Riesco, D. Montejano, G. ve Peralta, M. (2005). Kalite ölçütleri ve maliyet modeli. avantajı gerçek bir yazılım endüstrisine göre ayarlanmış Arjantin: Bilişim Bölümü Ulusal Üniversitesi San Luis. 16 Temmuz 2011 tarihinde http://www.costossoftware.com adresinden erişildi.avantajı gerçek bir yazılım endüstrisine göre ayarlanmış Arjantin: Bilişim Bölümü Ulusal Üniversitesi San Luis. 16 Temmuz 2011 tarihinde http://www.costossoftware.com adresinden erişildi.avantajı gerçek bir yazılım endüstrisine göre ayarlanmış Arjantin: Bilişim Bölümü Ulusal Üniversitesi San Luis. 16 Temmuz 2011 tarihinde http://www.costossoftware.com adresinden erişildi.

Bu maliyet ölçüsünün belirlenmesi, çalışma ekibinin görevlendirilmesi ve iletişim olmak üzere iki faktörün değerlendirilmesini ve ortalamasını içerir.

Orijinal dosyayı indirin