Menü

Örnek Olay: Şelale ve Çevik Geliştirme Süreçlerinin Kusurlarını Hibrit Model Kullanarak Nasıl Ortadan Kaldırılır

  • Ana
  • Çevik Test
  • Örnek Olay: Şelale ve Çevik Geliştirme Süreçlerinin Kusurlarını Hibrit Model Kullanarak Nasıl Ortadan Kaldırılır

case study how eliminate flaws waterfall

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Çevik Şelale Hibrit Modeli

Şelale Modeli, yazılım geliştirme için ideal seçim olmuştur. Bu modelde bir fikir, Başlatma, Analiz, Uygulama, Test ve Bakım aşamalarından geçen sıralı bir süreçte kullanılabilir bir yazılım haline gelir.

Ancak Şelale modelinin bazı dezavantajları vardır.

Çevik yazılım geliştirme, Waterfall modelinin sahip olduğu sorunları ortadan kaldırmak için gelişti. Tamamen yeni bir çerçeveye sahip. Waterfall modeli sıralı bir tasarıma sahipken, Agile modeli artımlı bir yaklaşım izledi.

Şelale modelini takip eden müşteriler Çevik'e geçtiğinde, geçiş birçok sorunu beraberinde getirdi. Yazılım geliştirmede farklı bir yaklaşıma uyumsuzluk olmasının nedeni. Son ürünün bir felaket olduğu ortaya çıktı.

Çevik Şelale Hibrit Modeli

Hem Agile hem de Waterfall modellerinin artılarını seçerek sağlam bir son ürün sağlamak için 'Hibrit' olarak adlandırılabilecek yeni bir metodoloji geliştirildi.

Önce Şelale ve Çevik geliştirme modellerini öğrenelim ve ardından her birinin artıları ve eksileri ile 'Çevik Şelale Hibrit Modeli' ne geçelim.

Ne öğreneceksin:

Şelale Modeli

Şelale modeli, bir projeyi sonlu aşamalara ayıran bir yazılım geliştirme yaklaşımıdır. Kişi, yalnızca önceki aşaması gözden geçirilip doğrulandığında sonraki aşamaya geçmelidir.

Şelale modelinde aşamalar çakışmaz.

=> Şelale Modeli hakkında daha fazla bilgiyi buradan okuyun.

Şekil 1, Şelale modelini göstermektedir:

Şelale Modeli

Şelale Modelinin Avantajları:

  • Basit ve anlaşılması ve kullanılması kolay.
  • Katı model - Her aşamanın belirli çıktıları ve inceleme süreçleri vardır.
  • Belgeler ve eserler titizlikle muhafaza edilir.
  • Gereksinimlerin iyi anlaşıldığı projeler için uygundur.

Şelale modelinin dezavantajları:

  • Gereksinimlerin değişme riski altında olduğu projeler için uygun değildir.
  • Daha sonraki bir aşamada tespit edildiğinde kusurları düzeltme maliyeti çok yüksektir.
  • Karmaşık ve uzun projeler için iyi bir model değil.
  • Yaşam döngüsü boyunca hiçbir çalışan yazılım üretilmez.

Çevik Model

Wikipedia, Çevik Modeli 'gereksinimlerin ve çözümlerin kendi kendini organize eden, işlevler arası ekipler arasındaki işbirliği yoluyla geliştiği yinelemeli ve artımlı geliştirmeye dayalı bir yazılım geliştirme yöntemleri grubu' olarak tanımlar.

Modelin, süreçleri arka koltuğa taşıma eğiliminde olan kendi ilkeleri vardır.

=> Agile metodolojisi hakkında daha fazla makaleyi buradan okuyun.

(Büyütülmüş görmek için resme tıklayın)

Çevik model

3 yıllık deneyim için pl sql mülakat soruları

Çevik modelin avantajları:

  • Sürece müşteri katılımı.
  • Çalışan bir yazılım sıklıkla sunulduğundan yüksek yatırım getirisi.
  • Gereksinimlerdeki geç değişiklikler bile kolaylıkla karşılanabilir.
  • Hem üründe hem de süreçte sürekli iyileştirme.

Çevik Modelin Dezavantajları:

  • Tasarım ve dokümantasyona vurgu eksikliği.
  • Ekip istikrarlı ve yetenekli olmalıdır.

İşbirlikçi (Hibrit) Model

İşbirlikçi Model, her iki modeli de birleştirmeyi amaçlamaktadır - Şelale ve Çevik. Hem Şelale hem de Çevik yaklaşımdan yararlanmak, projenin başarısını garanti eder. Her iki modelin dezavantajlarını ortadan kaldırır; ikisinin de avantajlarını bir araya getirirken.

İşbirlikçi Model, bir projede aşağıdakileri yürüterek uygulanabilir:

İşbirlikçi (Hibrit) Model

Dolayısıyla, İşbirlikçi model şematik olarak aşağıdaki gibi temsil edilebilir:

İşbirlikçi (Hibrit) Model 2

Hibrit modelin avantajları

  • Çevik ve Şelale süreçlerinin faydalarını birleştirir.
  • Şelale ilkelerini uygulamak için üst düzey tasarım hazırlanmıştır.
  • Kodlama ve testler, çevik metodoloji kullanılarak yapılır.

Çevik Şelale Hibrit Modeli - Örneklerle Öğrenin -Bir vaka çalışması

Yazılım firması 'ABC Software Service', yazılımlarını geliştirmek, test etmek ve sürdürmek için bir müşteriye, 'XYZ Üniversitesi' adlı bir Üniversiteye hizmetler sağlar (canlı üretim desteği).

Hesabın temel özellikleri şunlardır:

  1. ABC Yazılım Hizmetleri, XYZ Üniversitesi uygulamalarını yükseltmelidir. Veritabanının yükseltilmesi ve tüm uygulamaların piyasadaki en son teknolojiye göre yeniden geliştirilmesi gerekir.
  2. Şimdiye kadar ABC Software'in yürüttüğü tüm projeler Waterfall modelinde yürütüldü.
  3. Yoğun trafik ve yüksek öncelikli uygulamalardan ikisinin şimdi yeniden geliştirilmesi planlandı. İlki 'Çevrimiçi kayıtlar', ikincisi 'Çevrimiçi sınavlar' dır.
  4. İstemci XYZ Üniversitesi artık bu uygulamaların Çevik Yazılım geliştirme modelini kullanarak üzerinde çalışılmasını istiyordu.

ABC Yazılımı için Agile modelindeki ilk proje Çevrimiçi kayıtlardı. Bu projenin gerçekleştirilmesinden sonra, izlenen süreçlerde bir çok kusurun olduğu bir dizi retrospektifte fark edildi.

Bu kusurlar, ikinci proje olan 'çevrimiçi sınavlar' yürütülürken giderildi ve bu nedenle Hibrit modelde yürütüldü.

Hibrit bir model kullanarak Şelale ve Çevik Geliştirme Süreçlerinin Kusurları Nasıl Ortadan Kaldırılır:

Bunları tek tek ayrıntılı olarak tartışalım.

# 1. Belge Yok:

Agile manifestosundaki çevik ilkelerden biri şunu belirtir: Çevik, 'Kapsamlı Belgeleme yerine Çalışan Yazılım' a daha fazla değer verir. Çevik metodoloji, dokümantasyonun 'zar zor yeterince iyi' olması gerektiğine inanır ve çalışan bir yazılımı göndermek için daha fazla vurgu yapılır. Dokümantasyon konusunda fazla çaba sarf edilmiyor, ancak XYZ Üniversitesi gibi hesaplar için canlı projelerde bulunan kusurlar üzerinde çalışmak üzere özel bir destek ekibi için, bu alışkanlık uzun vadeli olarak analiz edersek bir engel oluşturabilir.

Şelale modelinde projelerin yürütüldüğü yıllar boyunca, destek ekibinin anlaması ve buna göre çalışması için belgeler tutuldu ve güncellendi. Çözüm tasarımı, teknik tasarım, gözden geçirme belgeleri vb. Hazırlanan belgelerden bazılarıydı. Proje bittikten sonra aynısı destek ekibine geçti.

Ancak, 'çevrimiçi kayıtlar' projesi durumunda, bu tür belgeler hazırlanmadı ve bu maliyetli oldu. Proje hayata geçtiğinde, son kullanıcılar tarafından çok sayıda bilet toplandı ve destek ekibinin bunlar üzerinde nasıl çalışılacağı hakkında hiçbir fikri yoktu. Ekibin referans gösterecek bir belgesi yoktu.

Bu, öğrenilen önemli bir dersti ve bir sonraki proje için 'çevrimiçi sınavlar' dokümanları etkili bir şekilde yazılmış ve değiştirilmiştir.

=> Dokümantasyonun neden önemli olduğunu buradan okuyun.

#iki. UAT / Uçtan uca test yok:

Çevik yazılım geliştirme modunda, test uzmanları yapıların aşamalı olarak test edilmesini sağlar. Bu yapılar, son yapı tamamen inşa edilene kadar bütünleşmeye devam eder. Test uzmanları, her sprintte kapsanan gereksinimleri test eder ve toplamaya devam eden yapının regresyon testini yapmaya devam eder.

Ancak tüm sprintler tamamlandıktan ve son yapı hazır ve tümüyle entegre olduktan sonra, test uzmanı tüm sistemi test etmeli ve uçtan uca test yapmalıdır. Bu tamamen yeni bir ortamda yapılmalıdır.

=> Canlı bir projede uçtan uca test.

Bunun kendi avantajları vardır:

  • Tüm sistem yeni bir ortama dağıtılır ve test cihazı tüm akışı test eder.
  • Güven oluşturur çünkü nihayetinde yapının canlı bir ortamda bir bütün olarak konuşlandırılması gerekir.

Online Kayıtlar projesi test edildiğinde test ortamında yapılmıştır. Sistem testinden ve tüm kusurları yeniden test ettikten sonra, imzalanmak üzere beyan edildi. İdeal olarak, bu, başka bir sistem testi döngüsü için başka bir ortama yükseltilmemiştir. (İdeal olarak, UAT, sistem testinden sonra gerçekleşir , ancak bu durumda, UAT ekip üyeleri testin ilk döngüsüne dahil edildi, bu nedenle ikinci döngü planlanmadı)

Çevrimiçi sınavlar projesi başladığında, SIT (Sistem Entegrasyon Testi) yapıldı ve kod, ikinci test döngüsünün yapıldığı bir UAT ortamına yükseltildi. Sonuç: Tüm yüksek öncelikli kusurlar tespit edildi ve çözüldü. Yayına alınmadan önce yapı kararlıydı.

xml dosyalarını nasıl açarsınız

# 3. Scrum Master yok:

Saldırı ustası bir takımın Scrum'ın değerleri ve uygulamaları ile yaşamasını sağlamaktan sorumludur. Scrum Master, takımın yapabileceği en iyi işi yapmasına yardımcı olarak takım için bir koç olarak kabul edilir. Scrum Master aynı zamanda bir süreç sahibi takım için.

Çevrimiçi kayıtlar ekibi, Scrum Master olmadan oluşturuldu. Özel bir Scrum Master'a sahip olmanın önemi önemli görülmedi. Bu, birçok sorunun zamanında çözülmemesine neden oldu ve sonuçta, projeyi bitirme zamanı genellikle son teslim tarihini geçti.

Ancak, Çevrimiçi Sınavlar projesine özel bir Scrum Master dahil edildi. Proje sorunları ve zorlukları Scrum Master tarafından halledildi. Proje / sprint raporları hazırlandı ve ekip ilerlemelerini görebildi.

Ayrıca, takımın performansını artıran her sprint için uygun sprint planlama toplantıları ve sprint retrospektif toplantıları yapıldı. Takım sadece işlerine konsantre oluyor ve bu sprint için verilen görevleri tamamlıyordu. Tüm ek temizlik Scrum Master tarafından gerçekleştirildi.

# 4. Proje belgelerini Ürün biriktirme listesine dönüştürme:

Bir şelale modelinde hazırlanan ilk proje belgeleri, İş gereksinimleri spesifikasyonu (BRS), Üst düzey tasarım, İşlevsel tasarım vb. Dir. Kodlama, test ve uygulama aşamalarını yürütmek için bu belgelerin bir ürün birikimine dönüştürülmesi gerekir. çevik modda. Bu çok önemli bir adım.

Ürün biriktirme listesi, çevik bir projenin başlangıç ​​noktasıdır. Ürün biriktirme listesi, bir ürün için tutulan öncelikli gereksinimler listesidir. Özellikler, hata düzeltmeleri, işlevsel olmayan gereksinimler vb. İçerir. Müşteri geri bildirimlerine, değişen gereksinimlere vb. Dayalı olarak büyüyen ve daha iyi hale gelen büyüyen bir belgedir.

Herhangi bir projenin ilk eseri olarak, gereksinimleri listelemek ve onlara öncelikler atamak çok önemlidir. Şelale proje belgelerinin ürün birikimine dönüştürülmesi başlı başına büyük bir görevdir ve müşteri / paydaş ile birlikte tüm ekibin beyin fırtınası yapmasını gerektirir.

Tüm gereksinimler listelendikten ve müşteri tarafından kabul edildikten sonra, bir sonraki görev, bunları sprintlerde almak için önceliklendirmektir.

# 5. İzlenebilirlik matrisi:

Şelale modelinde genellikle tutulan bir diğer önemli yapı, izlenebilirlik matrisidir. Bu nedenle, hiçbir şartın atlanmamasını sağlamak için; bir izlenebilirlik matrisi de tasarlanmalı ve muhafaza edilmelidir . Genellikle, çevik ortamda böyle bir matris tasarlanmamıştır.

Bu, herhangi bir projede en iyi uygulamadır. Ürün birikimine paralel olarak bir izlenebilirlik matrisi hazırlanmalıdır. Ve kullanıcı kabul testi / uçtan-uca test sırasında gerçekleştirilen test senaryolarına karşı kontrol edilmelidir (bu aşama bir sonraki noktada açıklanmaktadır). Herhangi bir gereksinim gözden kaçırılsa bile, Agile ekstra esneklik ve uyarlanabilirlik sağladığından, geliştirmenin son aşamalarında bile kolayca dahil edilebilir.

Online kayıtlar projesinin hayata geçirilmesinin ardından son kullanıcılar (kayıt olmak isteyen öğrenciler) tarafından uygulamaya erişildi. Uygulamada birçok sorunla karşılaştılar. Bu, üretim destek ekibine çok sayıda çağrı gönderilmesine neden oldu. Toplanan biletler olay, sorun veya değişiklik olarak sınıflandırılabilir. Uygulamanın kararlı hale geleceği beklentisiyle birçok sorun çözüldü. Ancak o zaman bile, sonraki sürümlerde bir düzineden fazla değişiklik talebi / geliştirme planlandı. Bu geliştirmeler, uygulamayı stabilize etme ve son kullanıcı deneyimini iyileştirme amaçlıydı.

Sonuç olarak, projenin maliyeti birçok kat arttı. Bu nedenle, bir proje uygun şekilde Agile'a geçirilmezse, bütçenin aşılmasına neden olabilir. Bu, bir projenin Agile'a kapsamlı bir geçişini planlamak için çok gereklidir. Ayrıca çevik modda yürütülebilmesi için projenin ihtiyaç duyduğu ölçüde planlama yapılmalıdır. Belirli bir proje için uygun hibrit modeller tasarlanmalıdır.

Sınav Giriş projesinin başlamasından önce, bu konuya iyi bakıldı. Hibrit bir model düşünüldü ve ihtiyaç analizi aşamasının ve üst düzey tasarım aşamasının şelale modelinde ve diğer aşamalarda çevik bir modelde yürütülmesine karar verildi.

Kabul edilen hibrit model aşağıdaki gibi resimsel olarak temsil edilebilir:

İşbirlikçi (Hibrit) Model 3

Sonuç:

Hem Waterfall modelinin hem de Agile modelinin kendi dezavantajları olduğu açıktır. Bu nedenle, Hybrid modelini tercih etmek oldukça gerçekçidir. her iki dünyanın en iyisinden yararlanarak.

Herhangi bir projenin başlamasının en önemli yönü, ekibin benimseyeceği modele karar vermektir. Bu, kapsamlı bir planlama gerektirir. Bir yazılım modelini benimserken bütçe, zaman, kaynak kullanımı, gereksinimlerin karmaşıklığı vb. Faktörler dikkate alınmalıdır.

Hibrit model hala yeni bir aşamadadır. Daha fazla şirket bunu benimsedikçe, bu konsept hakkında daha çok şey öğreneceğiz.

Çevik manifesto bizden şunlara değer vermemizi istiyor:

  • Bireyler ve etkileşimler süreçler ve araçlar üzerinde
  • Çalışan yazılım kapsamlı dokümantasyon
  • Müşteri işbirliği fazla sözleşme müzakeresi
  • Değişime yanıt vermek bir planı takip etmek

Oysa hibrit model bu% 100'e uymuyor. Tüm yönlerin eşit derecede önemli olduğunu öne sürüyor. Hangi yönlere daha fazla değer verileceğine ve hangi yönlerin değersiz olacağına karar vermek müşterilere / proje yöneticilerine bağlıdır.

Yazar hakkında: Bu Harshpal Singh'in konuk makalesi. 7 yıldan fazla manuel, veritabanı, otomasyon ve performans testi deneyimine sahip ve şu anda lider bir çokuluslu şirkette Takım lideri olarak çalışıyor. Waterfall, Agile ve hibrit geliştirme modellerini takip eden birçok QA projesinde çalıştı.

Bu hibrit geliştirme ve test modeli üzerinde çalışma deneyiminiz var mı? Yorumlarda tartışalım.

Önerilen Kaynaklar

^