İçeriğe atla

Kullanıcı:Aydinlatan/deneme tahtası

Vikipedi, özgür ansiklopedi

Yazılım geliştirme süreci

[değiştir | kaynağı değiştir]

Yazılım mühendisliğinde, bir yazılım geliştirme süreci veya yazılım geliştirme yaşam döngüsü ( SDLC ), yazılım geliştirmeyi planlama ve yönetme sürecidir. Genellikle tasarım ve/veya ürün yönetimini iyileştirmek için yazılım geliştirmeyi daha küçük, paralel, ardışık adımlara veya alt süreçlere bölmeyi içerir. Proje ekibi tarafından bir uygulamanın geliştirilmesi veya bakımı için oluşturulan ve tamamlanan belirli çıktıların ve eserlerin önceden tanımlanmasını içerebilir. [1]

Modern geliştirme süreçlerinin çoğu kabaca çevik olarak tanımlanabilir. Diğer metodolojiler arasında şelale, prototipleme, yinelemeli ve artımlı geliştirme, spiral geliştirme, hızlı uygulama geliştirme ve aşırı programlama yer alır.

Yaşam döngüsü "modeli" bazen bir metodoloji kategorisi için daha genel bir terim olarak kabul edilirken, yazılım geliştirme "süreci" belirli bir organizasyon tarafından benimsenen özel bir uygulamadır.[kaynak belirtilmeli]</link>[ kaynak belirtilmeli ] Örneğin, pek çok özel yazılım geliştirme süreci spiral yaşam döngüsü modeline uymaktadır. Bu alan genellikle sistem geliştirme yaşam döngüsünün bir alt kümesi olarak kabul edilir.

Tarih

[değiştir | kaynağı değiştir]

Yazılım geliştirme metodolojisi çerçevesi 1960'lara kadar ortaya çıkmadı. Elliott' a (2004) göre sistem geliştirme yaşam döngüsü, bilgi sistemleri oluşturmak için en eski biçimselleştirilmiş metodoloji çerçevesi olarak kabul edilebilir. Uygulanan çerçeve kapsamında, yazılım geliştirme yaşam döngüsünün temel fikri şudur: "bilgi sistemlerinin gelişimini çok dikkatli, yapılandırılmış ve metodik bir şekilde sürdürmek, fikrin ortaya çıkışından nihai sistemin teslimine kadar yaşam döngüsünün her aşamasını, katı ve sıralı bir şekilde yürütmek gerekir" [2] . Bu metodoloji çerçevesinin 1960'lardaki temel hedefi "büyük ölçekli işletme konglomeralarının olduğu bir çağda büyük ölçekli işlevsel iş sistemleri geliştirmekti. Bilgi sistemleri faaliyetleri yoğun veri işleme ve sayısal hesaplama rutinleri etrafında dönüyordu." [2]

Gereksinimlerin toplanması ve analizi: Özel yazılım geliştirme sürecinin ilk aşaması, müşterinin gereksinimlerinin ve hedeflerinin anlaşılmasını içerir. Bu aşama, genellikle paydaşlarla kapsamlı tartışmalar ve görüşmeler yapmayı, böylece yazılımın istenen özelliklerini, işlevlerini ve genel kapsamını belirlemeyi içerir. Geliştirme ekibi, mevcut sistemleri ve iş akışlarını analiz etmek, teknik fizibiliteyi belirlemek ve proje kilometre taşlarını tanımlamak için müşteriyle yakın bir şekilde çalışır.

Planlama ve tasarım: Gereksinimler anlaşıldıktan sonra, özel yazılım geliştirme ekibi kapsamlı bir proje planı oluşturmaya başlar. Bu plan, zaman çizelgeleri, kaynak tahsisi ve teslimatlar dahil olmak üzere geliştirme yol haritasını ana hatlarıyla belirtir. Yazılım mimarisi ve tasarımı da bu aşamada oluşturulur. Yazılımın kullanılabilirliğini, sezgiselliğini ve görsel çekiciliğini sağlamak için kullanıcı arayüzü (UI) ve kullanıcı deneyimi (UX), tasarım öğeleri dikkate alınır.

Geliştirme: Planlama ve tasarım tamamlandıktan sonra, geliştirme ekibi kodlama sürecine başlar. Bu aşama yazılım kodunun yazılmasını, test edilmesini ve hata ayıklanmasını içerir. Esnekliği, iş birliğini ve yinelemeli geliştirmeyi teşvik etmek için sıklıkla Scrum veya Kanban gibi çevik metodolojiler kullanılır. Geliştirme ekibi ile müşteri arasındaki düzenli iletişim, şeffaflığı garanti altına alır ve hızlı geri bildirim ve ayarlamalara olanak tanır.

Test ve kalite güvencesi: Yazılımın güvenilirliğini, performansını ve güvenliğini sağlamak için titiz test ve kalite güvence (QA) süreçleri gerçekleştirilir. Herhangi bir sorun veya hatayı belirlemek ve düzeltmek için birim testi, entegrasyon testi, sistem testi ve kullanıcı kabul testi gibi farklı test teknikleri kullanılır. QA faaliyetleri, yazılımın önceden tanımlanmış gereksinimlere göre doğrulanmasını ve amaçlandığı gibi çalışmasını sağlamayı amaçlar.

Dağıtım ve uygulama: Yazılım test aşamasını geçtikten sonra dağıtım ve uygulamaya hazır hale gelir. Geliştirme ekibi, yazılım ortamının kurulması, gerektiğinde verilerin taşınması ve sistemin yapılandırılması konusunda müşteriye yardımcı olur. Ayrıca, sorunsuz bir geçiş sağlamak ve kullanıcıların yazılımın potansiyelinden en iyi şekilde yararlanmasını sağlamak için kullanıcı eğitimi ve dokümantasyonu da sağlanmaktadır.

Bakım ve destek: Yazılım dağıtıldıktan sonra, herhangi bir sorunu gidermek, performansı artırmak ve gelecekteki geliştirmeleri dahil etmek için sürekli bakım ve destek önemli hale gelir. Yazılımın güncel ve güvenli kalmasını sağlamak için düzenli güncellemeler, hata düzeltmeleri ve güvenlik yamaları yayınlanır. Bu aşama aynı zamanda son kullanıcılara teknik destek sağlamayı ve onların sorularını veya endişelerini gidermeyi de içerir. Metodolojiler, süreçler ve çerçeveler, bir organizasyonun günlük işlerinde doğrudan kullanabileceği belirli tanımlayıcı adımlardan, bir organizasyonun belirli bir projenin veya grubun ihtiyaçlarına göre uyarlanmış özel bir adım kümesi oluşturmak için kullandığı esnek çerçevelere kadar uzanır. Bazı durumlarda, bir "sponsor" veya "bakım" kuruluşu, süreci tanımlayan resmi bir belge seti dağıtır. Belirli örnekler şunlardır:

1970'ler

[değiştir | kaynağı değiştir]
  • 1969'dan beri Yapısal Programlama
  • Cap Gemini SDM, aslen PANDATA' dan olup, ilk İngilizce çevirisi 1974 yılında yayımlanmıştır. SDM Sistem Geliştirme Metodolojisi anlamına gelir

1980'ler

[değiştir | kaynağı değiştir]
  • Yapısal Sistemler Analizi ve Tasarım Yöntemi (SSADM) 1980'den itibaren
  • Bilgi Gereksinim Analizi

1990'lar

[değiştir | kaynağı değiştir]
  • Nesne yönelimli programlama (OOP), 1960'ların başında geliştirildi ve 1990'ların ortalarında baskın bir programlama yaklaşımı haline geldi
  • Hızlı uygulama geliştirme (RAD), 1991'den beri
  • Dinamik sistem geliştirme yöntemi (DSDM), 1994'ten beri
  • Scrum, 1995'ten beri
  • Takım yazılım süreci, 1998'den beri
  • IBM tarafından 1998'den beri sürdürülen Rasyonel Birleştirilmiş Süreç (RUP)
  • Aşırı programlama, 1999'dan beri

2000'ler

[değiştir | kaynağı değiştir]
  • Çevik Birleştirilmiş Süreç (AUP) 2005'ten beri Scott Ambler tarafından sürdürülüyor
  • Disiplinli çevik teslimat (DAD) AUP'nin yerini alıyor

2010'lar

[değiştir | kaynağı değiştir]

1994'teki DSDM'den bu yana, yukarıdaki listedeki metodolojilerin RUP hariç tümü çevik metodolojilerdir - ancak birçok kuruluş, özellikle hükümetler, hala ön çevik süreçleri (genellikle şelale veya benzeri) kullanmaktadır. Yazılım süreci ve yazılım kalitesi birbirleriyle yakından ilişkilidir; uygulamada bazı beklenmedik yönler ve etkiler gözlemlenmiştir. [3]

Bunlardan biri de açık kaynak kodlu olarak kurulan bir yazılım geliştirme sürecidir. Bir şirkette, bilinen ve yerleşmiş en iyi süreçlerin benimsenmesine iç kaynak denir.

Prototipleme

[değiştir | kaynağı değiştir]

Yazılım prototipleme, geliştirilen yazılım programının prototiplerini, yani tamamlanmamış versiyonlarını oluşturmakla ilgilidir.

Temel ilkeler şunlardır: [4]

  • Prototipleme, bağımsız, tamamlanmış bir geliştirme metodolojisi değil, belirli özellikleri tam bir metodolojinin (örneğin artımlı, sarmal veya hızlı uygulama geliştirme (RAD)) bağlamında denenmesi yaklaşımıdır.
  • Projeyi daha küçük parçalara bölerek ve geliştirme süreci boyunca değişiklik yapmayı kolaylaştırarak, projeye özgü riskleri azaltmaya çalışır.
  • Müşteri, geliştirme sürecinin tamamına dahil edilir ve bu da müşterinin nihai uygulamayı kabul etme olasılığını artırır.
  • Bazı prototipler çöpe atılacağı beklentisiyle geliştirilirken, bazı durumlarda ise prototipten çalışan bir sisteme evrilmek mümkündür.

Yanlış sorunları çözmekten kaçınmak için temel iş sorununun en basit düzeyde anlaşılması gerekir ancak bu tüm yazılım metodolojileri için geçerlidir.

Metodolojiler

[değiştir | kaynağı değiştir]

Çevik geliştirme

[değiştir | kaynağı değiştir]

Ana makale: Atik Yazılım Geliştirme

"Çevik yazılım geliştirme", gereksinimlerin ve çözümlerin kendini organize eden, çok işlevli takımlar arasında işbirliği ile evrildiği, yinelemeli geliştirmeye dayanan bir yazılım geliştirme grubunu ifade eder. Terim, Agile Manifesto'nun oluşturulduğu 2001 yılında ortaya çıkmıştır.

Çevik yazılım geliştirme, yinelemeli geliştirmeyi temel alır ancak geleneksel yaklaşımlara göre daha hafif ve daha insan merkezli bir bakış açısını savunur. Çevik süreçler, bir yazılım sistemini sürekli iyileştirmek ve teslim etmek için temel olarak yinelemeyi ve bunun sağladığı sürekli geri bildirimi içerir.

Çevik model ayrıca aşağıdaki yazılım geliştirme süreçlerini de içerir:

  • Dinamik sistem geliştirme yöntemi (DSDM)
  • Kanban
  • Scrum
  • Yalın yazılım geliştirme

Sürekli entegrasyon

[değiştir | kaynağı değiştir]

Ana makale: Continuous integration

Sürekli entegrasyon, tüm geliştirilen çalışma kopyalarının günde birkaç kez paylaşılan bir ana hatta birleştirilmesi uygulamasıdır. [5] Grady Booch, 1991'deki yönteminde; ilk olarak sürekli entegrasyonu adlandırmış ve önermiştir [6] ancak günde birkaç kez entegre etmeyi savunmamıştır. Aşırı programlama (XP), sürekli entegrasyon konseptini benimsemiş ve günde birden fazla, belki de onlarca kez entegrasyonu savunmuştur.

Artımlı geliştirme

[değiştir | kaynağı değiştir]

Ana makale: Iterative and incremental development

Doğrusal ve yinelemeli sistem geliştirme metodolojilerini birleştirmek için çeşitli yöntemler kabul edilebilir; her birinin temel amacı, bir projeyi daha küçük parçalara bölerek, geliştirme sürecinde değişiklik yapmayı daha kolay hale getirerek, projeye özgü riskleri azaltmaktır.

Artımlı geliştirmenin üç ana çeşidi vardır: [7]

  1. Bir dizi mini-şelale gerçekleştirilir; burada sistemin küçük bir bölümü için şelale metodolojisinin tüm aşamaları tamamlanır ve ardından bir sonraki artıma geçilir.
  2. Genel gereksinimler tanımlandıktan sonra, sistemin her bir artımı için evrimsel, mini-şelale geliştirmesi uygulanır.
  3. Başlangıçtaki yazılım konsepti, gereksinim analizi, mimari tasarım ve sistem çekirdeği şelale metodolojisi ile tanımlanır; ardından artımlı uygulama yapılır ve bu, nihai sürümün (çalışan bir sistemin) kurulumu ile sonuçlanır.

Hızlı uygulama geliştirme

[değiştir | kaynağı değiştir]

Ana Makale: Rapid application development

Hızlı Uygulama Geliştirme Modeli(RAD) [8]

Hızlı uygulama geliştirme (RAD), büyük miktarda ön planlama yerine, yinelemeli geliştirmeyi ve prototiplerin hızla oluşturulmasını destekleyen bir yazılım geliştirme metodolojisidir. RAD kullanılarak geliştirilen yazılımın "planlanması", yazılımın kendisinin yazılmasıyla iç içedir. Kapsamlı bir ön planlamanın olmaması genellikle yazılımların çok daha hızlı yazılmasına olanak tanır ve gereksinimlerin değiştirilmesini kolaylaştırır.

Hızlı geliştirme süreci; yapılandırılmış teknikler kullanılarak ön veri modelleri ve iş süreci modellerinin geliştirilmesiyle başlar. Bir sonraki aşamada prototipleme kullanılarak gereksinimler doğrulanır. En sonunda ise veriler ve süreç modelleri geliştirilir. Bu aşamalar yinelemeli olarak tekrarlanır. Geliştirme, "yeni sistemler oluşturmak için kullanılacak birleşik iş gereksinimleri ve teknik tasarım beyanı" ile sonuçlanır. [9]

Terim ilk olarak 1991 yılında James Martin tarafından ortaya atılan bir yazılımı geliştirme sürecini tanımlamak için kullanılmıştır. Whitten'a (2003) göre, yazılım sistemlerinin gelişimini hızlandırmak için prototipleme teknikleriyle, özellikle veri odaklı bilgi teknolojisi mühendisliği olmak üzere çeşitli yapılandırılmış tekniklerin birleştirilmesidir. [10]

Hızlı uygulama geliştirmenin temel prensipleri şunlardır: [11]

  • Ana hedefimiz, nispeten düşük yatırım maliyetiyle, yüksek kaliteli bir sistemin hızlı bir şekilde geliştirilmesi ve teslim edilmesidir.
  • Proje içindeki doğal riskleri azaltmak için projeyi daha küçük parçalara ayırmayı ve geliştirme sürecinde değişiklik yapmayı kolaylaştırmayı hedefler.
  • Yüksek kaliteli sistemlerin hızlı bir şekilde üretilmesini sağlamak için, esas olarak yinelemeli prototipleme (geliştirmenin herhangi bir aşamasında), aktif kullanıcı katılımı ve bilgisayarla desteklenen geliştirme araçlarını kullanır.. Bu araçlar arasında Grafiksel Kullanıcı Arayüzü (GUI) oluşturucuları, Bilgisayar Destekli Yazılım Mühendisliği (CASE) araçları, Veritabanı Yönetim Sistemleri (VTYS), dördüncü nesil programlama dilleri, kod üreteçleri ve nesne yönelimli teknikler yer alabilir.
  • Ana vurgusu, iş ihtiyaçlarını karşılamaya yöneliktir; teknolojik veya mühendislik mükemmeliyeti ise daha az önem taşır.
  • Proje kontrolü, geliştirme önceliklerini belirlemeyi ve teslim tarihlerinin ya da “zaman kutularının” tanımlanmasını içerir.. Eğer proje aksamaya başlarsa, zaman sınırlamasına uyması için gereksinimleri azaltmaya odaklanılır, son teslim tarihini artırmaya değil.
  • Genellikle, kullanıcıların sistem tasarımında yoğun bir şekilde yer aldığı ortak uygulama tasarımı (JAD) içerir. Bu, yapılandırılmış atölye çalışmaları veya elektronik olarak kolaylaştırılmış etkileşim aracılığıyla fikir birliği oluşturmayı sağlar.
  • Aktif kullanıcı katılımı zorunludur.
  • Tek kullanımlık bir prototipin aksine, tekrarlı bir şekilde üretim yazılımı üretir.
  • Gelecekteki geliştirme ve bakım işlemlerini kolaylaştırmak için gerekli dokümantasyonu üretir.
  • Standart sistem analizi ve tasarım yöntemleri bu çerçeveye entegre edilebilir.

Şelale gelişimi

[değiştir | kaynağı değiştir]

Ana Makale: Waterfall model

Şelale modeli ile temsil edilen yazılım geliştirme sürecinin faaliyetleri. Bu süreci temsil edecek başka modeller de vardır.[12]

Şelale modeli, gelişimin birkaç aşamadan geçerek (bir şelale gibi) sürekli olarak aşağıya doğru aktığı görülen sıralı bir gelişim yaklaşımıdır. Tipik olarak aşamalar şunlardır:

Bu yöntemle ilgili ilk resmi tanım, genellikle Winston W. Royce [13] 'un 1970 yılında yayınlanan bir makalesine atıfta bulunularak verilmektedir; ancak Royce bu makalede "şelale" terimini kullanmamıştır. Royce, bu modeli çalışmayan ve hatalı bir model örneği olarak sunmuştur.

Temel ilkeler şunlardır: [14]

  • Proje, ardışık aşamalara ayrılmıştır; aşamalar arasında bazı örtüşmeler ve geri dönüşler kabul edilebilir.
  • Planlamaya, zaman çizelgelerine, hedef tarihlere, bütçelere ve bir sistemin tamamının bir seferde uygulanmasına vurgu yapılır..
  • Projenin ömrü boyunca; çoğu aşamanın sonunda, bir sonraki aşamaya geçilmeden önce kapsamlı yazılı dokümantasyon, resmi incelemeler yapılır. Denetim sonuçları kullanıcı ve bilgi teknolojisi yönetimi tarafından onay/imza yoluyla sıkı şekilde kontrol edilir. Yazılı dokümantasyon her aşamanın açık bir çıktısıdır.

Şelale modeli, yazılım mühendisliğine uygulanan geleneksel bir mühendislik yaklaşımıdır. Katı bir şelale yaklaşımı, bir aşama tamamlandıktan sonra, herhangi bir önceki aşamaya geri dönülmesini ve revize edilmesini teşvik etmez. </link>[ kime göre? ] Saf şelale modelindeki bu "esneksizlik", diğer daha "esnek" modellerin destekçileri tarafından eleştiri kaynağı olmuştur. Birçok büyük ölçekli hükümet projesinin bütçeyi aşması, zaman aşımına uğraması ve bazen de büyük tasarım ön yaklaşımı nedeniyle gereksinimleri karşılayamaması nedeniyle yaygın olarak suçlanmıştır. </link>[ kime göre? ] Sözleşme gereksinimleri dışında şelale modeli; yazılım geliştirme için özel olarak geliştirilmiş daha esnek ve çok yönlü metodolojiler tarafından büyük ölçüde geçersiz kılınmıştır. </link>[ kime göre ? ] Şelale modelinin eleştirilerine bakınız.

Sarmal Gelişim

[değiştir | kaynağı değiştir]

Ana Makale: Spiral model

Spiral model (Boehm, 1988) [15]

1988'de Barry Boehm, spiral model olarak bilinen resmi bir yazılım sistem geliştirme modeli yayımladı. Bu model, üstten aşağı ve alttan yukarı yaklaşımların avantajlarını birleştirme çabasıyla şelale modeli ve hızlı prototipleme metodolojilerinin bazı temel yönlerini bir araya getirir. Spiral modeli, diğer metodolojilerde ihmal edildiği düşünülen bir alana – özellikle büyük ölçekli karmaşık sistemler için – bilinçli, iteratif risk analizi üzerinde vurgu yapar.

Temel ilkeler şunlardır: [16]

  • Odak noktası risk değerlendirmesi ve projeyi daha küçük parçalara bölerek proje riskini en aza indirmek ve geliştirme süreci boyunca daha fazla değişiklik kolaylığı sağlamaktır. Ayrıca yaşam döngüsü boyunca riskleri değerlendirir ve proje devamlılığını dikkate alır.
  • "Her döngü, ürünün tüm parçaları ve her ayrıntı seviyesinde aynı adımlar boyunca ilerlemeyi içerir; genel bir işletim konsepti dokümanından başlayarak, tüm programların kodlanmasına kadar devam eder."
  • Spiral etrafındaki her yolculuk dört temel kadranı geçer: (1) yinelemenin hedeflerini, alternatiflerini ve kısıtlamalarını belirlemek (2) alternatifleri değerlendirmek; Riskleri belirlemek ve çözmek (3) yinelemeden elde edilecek çıktıları geliştirmek ve doğrulamak (4) bir sonraki yinelemeyi planlamak. [17]
  • Tüm döngüleri paydaşların "kazanma koşullarının" belirlenmesiyle başlatın ve her döngüyü inceleme ve taahhütle sonlandırın. [18]

Şekillendir

[değiştir | kaynağı değiştir]

Shape Up, Basecamp tarafından 2018 yılında tanıtılan bir yazılım geliştirme yaklaşımıdır. Basecamp'in, projelerin belirli bir sonu olmadan uzaması sorununu aşmak için kendi bünyesinde geliştirdiği bir dizi ilke ve tekniktir. Öncelikli hedef kitlesi uzaktan çalışan ekiplerdir. Shape Up'ta şelale, çevik veya scrum'dan farklı olarak tahmin ve hız takibi, gecikmeler veya sprintler yoktur. Bunun yerine iştah, bahis ve döngü kavramları vardır. 2022 itibarıyla Basecamp'in yanı sıra Shape Up'ı benimseyen önemli kuruluşlar arasında UserVoice ve Block yer alıyor. [19] [20]

Gelişmiş metodolojiler

[değiştir | kaynağı değiştir]

Diğer üst düzey yazılım proje metodolojileri şunları içerir:

  • Davranış odaklı geliştirme ve iş süreci yönetimi. [21]
  • Kaos modeli - Ana kural her zaman en önemli sorunu önce çözmektir.
  • Artımlı finansman metodolojisi - yinelemeli bir yaklaşım
  • Hafif metodoloji - yalnızca birkaç kural ve uygulamaya sahip yöntemler için genel bir terim
  • Yapılandırılmış sistem analizi ve tasarım yöntemi - şelalenin özel bir versiyonu
  • Yavaş Hareket'in bir parçası olan yavaş programlama, zaman baskısı olmaksızın (veya asgari düzeyde) dikkatli ve kademeli çalışmayı vurgular. Yavaş programlamanın amacı hatalardan ve aşırı hızlı yayın takvimlerinden kaçınmaktır.
  • V-Model (yazılım geliştirme) - şelale modelinin bir uzantısı
  • Birleşik Süreç (UP), Birleşik Modelleme Dili'ne (UML) dayalı yinelemeli bir yazılım geliştirme metodolojisi çerçevesidir. UP, yazılım geliştirme sürecini dört aşamaya ayırır; her aşama, o geliştirme aşamasında yazılımın bir veya daha fazla çalıştırılabilir yinelemesini içerir: başlatma (inception), ayrıntılandırma (elaboration), inşa (construction) ve yönergeler (guidelines).

Bazı " süreç modelleri ", bir organizasyon tarafından benimsenen belirli bir süreci değerlendirmek, karşılaştırmak ve iyileştirmek için kullanılan soyut tanımlardır.

  • ISO/IEC 12207, yazılımların yaşam döngüsünün seçilmesi, uygulanması ve izlenmesi için yöntemi tanımlayan uluslararası standarttır.
  • Yetenek Olgunluk Modeli Entegrasyonu (CMMI), en iyi uygulamalara dayanan önde gelen modellerden biridir. Bağımsız değerlendirmeler, organizasyonları tanımlanmış süreçleri ne kadar iyi takip ettiklerine göre derecelendirir; bu değerlendirme süreçlerin kalitesine veya üretilen yazılımın kalitesine göre yapılmaz. CMMI, CMM'nin yerini almıştır.
  • ISO 9000, bir ürünün imalatı için resmi olarak organize edilmiş bir süreci ve ilerlemeyi yönetme ve izleme yöntemlerini tanımlayan standartları açıklar. Standart başlangıçta üretim sektörü için oluşturulmuş olsa da ISO 9000 standartları yazılım geliştirmeye de uygulanmıştır. CMMI gibi, ISO 9000 ile sertifikasyon da nihai sonucun kalitesini garantilemez, yalnızca resmi iş süreçlerinin takip edildiğini gösterir.
  • ISO/IEC 15504 Bilgi Teknolojileri - Süreç değerlendirmesi, Yazılım Süreci İyileştirme Yeteneği Belirleme (SPICE) olarak da bilinir, "yazılım süreçlerinin değerlendirilmesi için bir çerçevedir". Bu standardın amacı, süreç karşılaştırması için net bir model ortaya koymaktır. SPICE, CMMI'ye çok benzer şekilde kullanılır. Yazılım gelişimini yönetmek, kontrol etmek, yönlendirmek ve izlemek için süreçleri modeller. Bu model daha sonra yazılım geliştirme sırasında bir geliştirme organizasyonunun veya proje ekibinin gerçekte ne yaptığını ölçmek için kullanılır. Bu bilgiler zayıflıkları belirlemek ve iyileştirmeyi yönlendirmek için analiz edilir. Ayrıca, söz konusu organizasyon veya ekip için ortak uygulamaya entegre edilebilecek veya sürdürülebilecek güçlü yönleri de belirler.
  • ISO/IEC 24744 Yazılım Mühendisliği—Geliştirme Metodolojileri için metamodel, yazılım geliştirme metodolojileri için güç tipi tabanlı bir metamodeldir.
  • Yumuşak sistemler metodolojisi - yönetim süreçlerini iyileştirmek için genel bir yöntemdir.
  • Metot mühendisliği - bilgi sistemi süreçlerini iyileştirmek için kullanılan genel bir yöntemdir.

Uygulamada

[değiştir | kaynağı değiştir]
Yazılım geliştirme metodolojisi çerçevelerine uygulanan üç temel yaklaşım[22]

Yıllar geçtikçe bu türden birçok çerçeve geliştirildi ve her birinin kendine özgü güçlü ve zayıf yönleri bulunuyor. Tek bir yazılım geliştirme metodolojisi çerçevesi tüm projelerde kullanılmaya uygun olmayabilir. Mevcut metodoloji çerçevelerinin her biri, çeşitli teknik, organizasyonel, proje ve ekip hususlarına dayalı olarak belirli proje türlerine en uygun olanıdır. [23]

Ayrıca bakınız

[değiştir | kaynağı değiştir]

Referanslar

[değiştir | kaynağı değiştir]
  1. ^ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008. June 20, 2012 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: October 27, 2008. 
  2. ^ a b Geoffrey Elliott (2004). Global Business Information Technology: an integrated systems approach. Pearson Education. s. 87. 
  3. ^ Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE Software. 32 (4): 7–11. doi:10.1109/MS.2015.87.  Tarih değerini gözden geçirin: |erişimtarihi= (yardım);
  4. ^ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008. June 20, 2012 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: October 27, 2008. 
  5. ^ Paul M. Duvall; Steve Matyas; Andrew Glover (2007). Continuous Integration: Improving Software Quality and Reducing Risk. Addison-Wesley Professional. ISBN 978-0-321-33638-5. 
  6. ^ Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. s. 209. ISBN 9780805300918. Erişim tarihi: August 18, 2014. 
  7. ^ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008. June 20, 2012 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: October 27, 2008. 
  8. ^ Software development process (İngilizce), 2024-10-22, erişim tarihi: 2024-10-25 
  9. ^ Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003). Systems Analysis and Design Methods. 6th edition. 0-256-19906-X.
  10. ^ Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003). Systems Analysis and Design Methods. 6th edition. 0-256-19906-X.
  11. ^ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008. June 20, 2012 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: October 27, 2008. 
  12. ^ Software development process (İngilizce), 2024-10-22, erişim tarihi: 2024-10-25 
  13. ^ Markus Rerych. "Wasserfallmodell > Entstehungskontext". Institut für Gestaltungs- und Wirkungsforschung, TU-Wien (German). Erişim tarihi: November 28, 2007. 
  14. ^ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008. June 20, 2012 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: October 27, 2008. 
  15. ^ Software development process (İngilizce), 2024-10-22, erişim tarihi: 2024-10-25 
  16. ^ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008. June 20, 2012 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: October 27, 2008. 
  17. ^ Richard H. Thayer; Barry W. Boehm (1986). Tutorial: software engineering project management. Computer Society Press of the IEEE. s. 130. 
  18. ^ Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1. 
  19. ^ "Foreword by Jason Fried | Shape Up". basecamp.com. Erişim tarihi: September 11, 2022. 
  20. ^ "Is Shape Up just a nice theory?". Curious Lab (İngilizce). Erişim tarihi: September 12, 2022. 
  21. ^ Lübke, Daniel; van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". IEEE Software. 33 (5): 15–21. doi:10.1109/MS.2016.117. 
  22. ^ Software development process (İngilizce), 2024-10-22, erişim tarihi: 2024-10-25 
  23. ^ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008. June 20, 2012 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: October 27, 2008. 

Dış bağlantılar

[değiştir | kaynağı değiştir]
"https://tr.wikipedia.org/w/index.php?title=Kullanıcı:Aydinlatan/deneme_tahtası&oldid=34131114" sayfasından alınmıştır