Vaka İncelemesi Örnekleri (2) – GATE BAĞLAMINDA YÜKSEK PROGRAMLAMAYA İLİŞKİN DURUM ÇALIŞMASI – Ücretli Vaka İncelemesi Yaptırma
On yılı aşkın süredir ödev yapma desteği veren Ödevcim Akademik, size Vaka incelemesi yapmakta yardımcı olacaktır. Vaka Analizi yaptırma konusunda sizde Ödevcim Akademik destek olsun istiyorsanız yapmanız gerekenler çok basit. Öncelikle vaka incelemesi ve ödevlerinizle ilgili belgelerinizi akademikodevcim@gmail.com sayfamızdan gönderebilir ödevleriniz, tezleriniz, makaleleriniz ve projeleriniz ile ilgili destek alabilirsiniz.
İLK AŞAMA – GATE BAĞLAMINDA YÜKSEK PROGRAMLAMAYA İLİŞKİN DURUM ÇALIŞMASI
GİRİŞ
Bu bölüm, plan odaklı uygulamalar ve proje yönetimine bir aşama kapısı yaklaşımı tarafından yönetilen bir bağlamda eXtreme Programlama uygulamalarının tanıtımı üzerine bir vaka çalışması yürüten ilk yazarın deneyimini bildirmektedir. ]. Çalışmadaki vakalar üç farklı uygulama alanından geliyor, otomasyon, savunma ve telekom ve şirket adları için sırasıyla ABB, Ericsson ve Vodafone olarak adlandırılıyor.
Metodolojik Durum
Çalışma sırasında (2003–2004), kalitatif araştırma yazılım mühendisliği alanında tam olarak kabul edilmedi ve deneysel çalışmaların genel payı düşüktü. Seaman’in yeni ufuklar açan makalesi nitel yöntemlerin kullanımına ilham verdi, ancak çoğunlukla sosyal bilimlerden alınan yönergeler kullanıldı.
ÖRNEK ÇALIŞMA TASARIMI
Gerekçe
2003 yılında düzenlenen eXtreme Programlama ve Çevik geliştirme yöntemleri üzerine bir endüstriyel seminerde ortaya çıkan sorulara yanıt olarak çalışmayı gerçekleştirdik. Lund Üniversitesi Yazılım Mühendisliği Araştırma Grubu, 20’den fazla farklı yazılımdan temsilcilerin yer aldığı seminere sponsor oldu.
Temsilciler çevik geliştirmeyle çok ilgileniyorlardı, ancak bunun mevcut proje yönetimi modelleriyle birlikte var olup olmayacağından veya nasıl bir arada bulunabileceğinden emin değillerdi. Onların ilgisi, bizi aşama kapısı proje yönetimi modellerini kullanarak büyük yazılım geliştirme projeleri bağlamında çevik yöntemlerin uygulanmasının fizibilitesini incelemeye sevk etti. Aşama kapısı modeli, proje yönetimi için bir şelale özelliğine sahiptir, ancak bu, geliştirme sürecinin şelale olduğu anlamına gelmez. Yine de son derece çevik bir geliştirme sürecinin şelale proje yönetimi süreciyle nasıl bir arada var olabileceği net değildi.
Hedefler
Bir doktora öğrencisi (Karlstro ̈m), küçük ölçekli bir yazılım geliştirme projesinde XP’nin tanıtımı üzerinde çalıştı ve bilgisini, büyük ölçekli bir yazılım geliştirmede XP kullanımına genişletmek istedi. Araştırma grubunun iletişim ağı aracılığıyla, iki farklı şirkette (ABB ve Ericsson şubeleri) XP uygulamalarını bir aşamalı proje yönetimi modellerinde pilot olarak belirleyen iki ekip belirledik.
Daha sonra, Vodafone’un Agile uygulamalarını başlatmakla ilgilenen bir şubesi olan çalışmaya üçüncü bir şirket daha ekledik. İlk iki şirket, geliştirme sürecinde oldukça yüksek derecede formalizm ve dokümantasyon gerektiren, yani otomasyon ve savunma alanlarında faaliyet gösteriyordu. Üçüncü şirket, oldukça plan odaklı olmasına rağmen daha az resmi olan telekom hizmetleri alanında faaliyet gösteriyordu. İlk iki vaka pratisyen ve alt düzey yönetime odaklanırken, üçüncü vaka yalnızca orta ve üst düzey yönetimi inceledi.
Soruşturmanın kapsamını daraltmak için, karar noktası kapısı 3’e (veya Şekil 10.1’de gösterildiği gibi G3) odaklanmaya, yani projelerde çok önemli bir nokta olduğu için tam ölçekli geliştirmeye başlayıp başlamayacağına karar vermeye karar verdik. . Bu noktada projenin tam ölçekli gelişime geçip geçmemesi kararlaştırılır ve kaynaklarda büyük bir artış tahsis edilir. Bununla birlikte, incelenen alt projeler G3’ün çok ötesindeydi ve bu nedenle, yalnızca geçmişe bakıldığında G3’te olanları, katılımcılar hatırladıkça açıklayabiliyordu. Dolayısıyla bir bütün olarak projelere odaklanmak zorundaydık.
Durumlar ve Analiz Birimleri
Vaka çalışmaları başladığında, ABB ve Ericsson şirketleri XP uygulamalarını iki alt projede yaklaşık bir yıl boyunca uyguladılar. Amaç, proje üyeleriyle aşama kapısı bağlamında XP kullanma deneyimleri hakkında röportaj yapmaktı. Vodafone davası sonradan eklendi ve daha çok Agile uygulamalarına geçiş sürecindeydi. ABB ve Ericsson vakaları, genel bağlamda benzer özelliklere sahip iki analiz birimi olarak kabul edilirken, Vodafone vakası Şekil 10.2’de gösterildiği gibi ayrı, bütünsel bir vaka çalışması olarak kabul edilir.
Bununla birlikte, ABB ve Ericsson da farklı özelliklere sahiptir. ABB durumunda, ürünler genel bir pazar için geliştirilir; Ericsson durumunda ise ürün, daha sonraki bir aşamada daha geniş bir pazara gitme niyetiyle belirli bir müşteri için geliştirildi. Ericsson vakasındaki müşteri arayüzü organizasyonel olarak projeden uzak olduğundan, bu fark iki şirketi aynı bağlamda farklı analiz birimleri olarak ele almak için bir engel olarak görülmedi; müşteri ile doğrudan etkileşimleri yoktur.
Soruşturma sırasında Ericsson ekibi uygulamalarını tamamlamış, daha sonra bölünmüş ve üyelerini çeşitli görevlere atamışlardı. ABB ekibi, ürünün uygulama aşamasında geç kaldı. Dahası, çalışmada, XP takımı ile çevredeki ortam arasındaki arabirim üzerine özel bir odak noktası oluşturuldu çünkü burası, ikisi arasındaki zıtlıkların en açık şekilde göründüğü düşünülüyordu; bu nedenle, analiz birimlerinin özellikle çevre ile etkileşimlerine odaklanarak XP projeleri olduğuna karar verdik. Bu, odak noktasının orijinal G3 kararından, proje yönetimi süreci ile genel olarak çevik projeler arasındaki arayüze doğru kaydığı anlamına geliyordu.
ŞEKİL 10.2 Bağlamlara, vakalara ve analiz birimlerine genel bakış.
Teorik Referans Çerçevesi
Çalışmanın teorik çerçevesi, XP kullanımıyla ilgili oldukça büyük miktarda deneyim raporundan oluşturuldu. Literatürü gözden geçirdiğimizde, mevcut bilgiler ile şirketlerin menfaatleri arasında bir uyumsuzluk olduğunu gördük. Firmalar, belirli bir müşteri yerine geniş bir pazarı hedefleyen ürünlerini üretmek için aşamalı geçit modelleri [33] ile çalışırlar. İlk olarak, çevik literatürün çoğu, bir pazar durumu yerine, genel bir pazar için ürünler veya bileşenler geliştiren, belirli müşteriler için ısmarlama ürünler veya bileşenler geliştiren bir sözleşme durumuna odaklanır. İkincisi, Wallin ve diğerleri tarafından gerçekleştirilen ön araştırma dışında, o zamanlar Agile’ı sahne kapısı modellerine entegre etme konusunda neredeyse hiçbir araştırma yoktu.
Araştırma Soruları
Araştırmanın niyetleri araştırma sorusu açısından değil, bir amaç olarak ifade edildi: “Çalışma, geleneksel bir aşama kapısı modeli tarzı proje yönetim sistemi içinde çevik bir yazılım geliştirme sürecini tanıtmanın etkilerini araştırmayı amaçlamaktadır. Çalışma, spesifik olarak, bu birleşik yaklaşımla ilgili temel sorunları ve bunun yanı sıra temel başarı faktörlerini tanımlamayı amaçlamaktadır ”.
Vodafone vakası için, halihazırda tanıtılan uygulamalardan edinilen deneyimlerden ziyade, gelecekteki giriş ve çevik uygulamalara yönelik tutumlar incelenmiştir. Dolayısıyla, Vodafone davasını ayrı bir bağlam olarak görüyoruz.
On yılı aşkın süredir ödev yapma desteği veren Ödevcim Akademik, size Vaka incelemesi yapmakta yardımcı olacaktır. Vaka Analizi yaptırma konusunda sizde Ödevcim Akademik destek olsun istiyorsanız yapmanız gerekenler çok basit. Öncelikle vaka incelemesi ve ödevlerinizle ilgili belgelerinizi akademikodevcim@gmail.com sayfamızdan gönderebilir ödevleriniz, tezleriniz, makaleleriniz ve projeleriniz ile ilgili destek alabilirsiniz.
Araştırma Soruları Durumlar ve Analiz Birimleri GİRİŞ Hedefler İLK AŞAMA – GATE BAĞLAMINDA YÜKSEK PROGRAMLAMAYA İLİŞKİN DURUM ÇALIŞMASI Metodolojik Durum ÖRNEK ÇALIŞMA TASARIMI Teorik Referans Çerçevesi