Şelale Proje Yönetimi için nTask Nasıl Kullanılır – İlk Zamanlayıcılar İçin Pratik Bir Kılavuz

Şelale proje yönetimini etkileyen çeşitli faktörlerin kapsamlı bir analizini yaptık. Bu, nTask proje yönetimi yazılımının bu tür sorunları çözmek için nasıl kullanılabileceğini basitleştirmemize yardımcı oldu. Şelale, popüler bir SDLC proje yönetim modelidir.

Ancak, çeşitli noktalarda karmaşıktır. Bu yazı, şelale odaklı tüm iş modellerinizle ilgili olarak maksimum üretkenlik ile geçinmek için nTask'ı nasıl kullanabileceğinizi detaylandırıyor. Çeşitli gerçek yaşam kullanım durumlarını ve şelalenin uygulandığı örnekleri ve bu süreci daha da basitleştirmek için nTask'ın nasıl kullanılabileceğini göstermek için fazladan bir yol kat ettik.

Şelale Proje Yönetimi Hakkında Bilmeniz Gerekenler?

Şelale metodolojisi, proje yönetimi için kullanılan geleneksel ve en yaygın metodolojidir. Sıralı, doğrusal bir süreci takip eder, bu nedenle sıklıkla “doğrusal-sıralı yaşam döngüsü modeli” olarak tanımlanır. Adından da anlaşılacağı gibi, Waterfall, projeyi farklı, ayrı ve özel bölümlere ayırarak projenin yaşam döngüsünü planlamaya odaklanır: Bir Şelale modelinde, bir sonraki aşamanın başlayabilmesi için her aşamanın tamamlanması gerekir.

Şelale metodolojisindeki her bir ayırt edici adımın tamamlanması, tıpkı gerçek bir şelale gibi projenin bir sonraki aşamasına yol açar. Projenin bir bölümü tamamlandığında, üzerinde başka hiçbir değişiklik yapılamaz ve bir sonrakini tamamlamak için hiçbir adım atlanamaz. Dolayısıyla her aşama, önceki aşamaların veya seviyelerin tamamlanmasına bağlıdır. Bu, Şelale Modelini iyi tanımlanmış gereksinimleri ve daha az belirsizliği olan daha küçük projeler için en kullanışlı hale getirir. Basitliği ve uygulama kolaylığı, onu yazılım mühendisliği ve BT projeleri için sistem geliştirme yaşam döngüsünün (SDLC) en popüler versiyonu haline getirdi.

Şelale Modelini kullanırken, geliştirmenin sonraki aşamalarına geçmeden önce gereksinimlerin ve tasarımın projenin gereksinimlerine uygun olduğundan emin olunmasına önem verilir.

Şelale proje yönetiminin arka planı

Kaynak – Codeacademy.com

Şelale Modelinin kökeni genellikle imalat ve inşaat sektörlerine atfedilir. Yüksek düzeyde yapılandırılmış bir üretim sürecini takip ettikleri için Şelale metodolojisi bu endüstriler için idealdi: sürecin ilk aşamasında gereksinimler açıkça belirtilir ve ana hatlarıyla belirtilir ve geri kalan aşamalar gereksinimlere göre tasarlanır. Tıpkı Şelale metodolojisinde olduğu gibi, proje yönetimi döngüsünün herhangi bir aşamasında sonradan yapılacak herhangi bir değişiklik sadece çok maliyetli olmakla kalmaz, bazı durumlarda imkansızdır.

Winston W. Royce sık sık fakat yanlışlıkla “Şelalenin babası” olarak anılır, 1970 yılında yazdığı bir makalede sürecin ilk resmi tanımıyla akredite edilmiştir. Dr. birden fazla yineleme veya çalıştırma içeren bir model için tartıştı. İlki bir prototip olmak üzere, projenin birden fazla yinelemesi olmadan, projenin çok riskli olacağını ve hatta başarısızlığa davetiye çıkaracağını savundu. Ona göre, projede yer alan gereksinimleri ve teknolojileri daha iyi anlamak ve nihai ürünün müşterinin istediğini teslim etmesini sağlamak için prototip yineleme çok önemliydi.

Ek Okuma:

Ücretsiz Proje Yönetim Araçlarınızda Aranacak En İyi 7 Özellik

Sürecin bilinen ilk tanımına Dr. Royce atfedilirken, bilinen ilk sunum Herbert D. Benington'a atfedilir. 29 Haziran 1956'da Herbert D. Benington, dijital bilgisayarlar için ileri programlama yöntemleri konulu Sempozyum'da SAGE için yazılım geliştirme hakkında bir sunum yaptı. Sunumunda bu tür aşamaların yazılım mühendisliğinde kullanımını anlattı. Yine de “Şelale” terimi süreci tanımlamak için kullanılmadı.

Wikipedia'ya göre, 1976 tarihli bir makalede “Şelale” terimini ilk kullananlar Bell ve Thayer oldu.

1980'lerde Şelale Modeli katı doğası nedeniyle yoğun eleştirilere maruz kaldı.

Yazılım geliştirme sektörünün değişen ihtiyaçları ve Şelale Modelinin doğrusallığının erken geri bildirim sağlamadaki başarısızlığı nedeniyle Şelale Modelinin birçok versiyonu ortaya çıkmıştır. Bu sürümler genellikle topluca Değiştirilmiş Şelale Modelleri olarak adlandırılır.

Daha modern Şelale Modeli, değişikliklere izin vermek için önceki aşamalara geri bildirim döngülerine sahiptir. Şelale modelinin diğer versiyonları, Peter DeGrace'in “sashimi modeli” (üst üste binen aşamalara sahip şelale), V-Model veya Bent Şelale Modeli vb.

Şelale Metodolojisi ve Evrimi – Geleneksel Şelale Modeli

1970'lerden beri, işletmeler ve projeler, proje yönetimi için Şelale metodolojisini kullandılar. A noktasından başlayan ve sonuna ulaşmak için ardışık adımlar izleyen basit bir akış şeması kullanmak, sadece anlaşılması kolay değil, aynı zamanda uygulanması da kolaydı. Şelale metodolojisinin aşamaları, proje geliştirme döngüsünün ikinci bölümünde maliyetli revizyonların önlenmesi amacıyla Dr. Royce tarafından geliştirilmiştir. Dr. Royce, kendi deneyiminde Şelale Modelinin başarısızlık riskleriyle nasıl bağlantılı olduğunu açıklamaya çalışıyordu.

Royce'un orijinal şelale modelinde, büyük ve karmaşık yazılım geliştirme projeleri için bu adımların önemini vurgulamak için bu aşamaları özetledi. Ayrıca, adımlar farklı şekilde planlanıp yürütüldüğünden, kaynakların en iyi şekilde kullanılması için ekibin bu adımları en iyi şekilde gerçekleştirebilecek kişileri içermesi gerektiğini belirtmek istedi.

Şelale Modelinin Tipik Aşamaları

Şelale Modelinin çeşitli aşamaları, proje çerçevesine ve gereksinimlerine bağlı olarak değiştirilebilir, ortadan kaldırılabilir veya artırılabilir.

Tipik bir Şelale modelindeki sıralı adımlar aşağıdaki gibidir:

1. Konsept : Bu aşama, proje fikrinin filizlendiği yerdir. Bu aşama, sürecin kaba bir değerlendirmesini içerir, örneğin proje faydalı mı, ilgili maliyetler ne olacak vb.
2. Başlatma : Konseptin ardından, bir proje ekibinin işe alınması, hedeflerin, kapsamın, amacın ve teslimatların tanımlanmasıyla proje başlatılır. Şelale Modeli, gereksinimlerin ve tasarımın projenin ihtiyaçlarına uygun olduğundan emin olmayı vurguladığı için bu aşama kritiktir.
3. Gereksinim Toplama ve Analizi : Projenin fizibilitesini görmek için olası tüm proje gereksinimleri ekip tarafından toplanır ve analiz edilir. Bu, ekibin müşterinin iş modelini anlamasını ve projeyle ilgili potansiyel riskleri analiz etmesini de gerektirebilir. Bu aşamada oluşturulan tüm bilgiler daha sonra bir gereksinim belirtimi belgesinde belgelenir.
4. Tasarım : Bu aşamada, gereksinim şartnamesi incelenir, değerlendirilir ve projenin tamamlanması için sistem tasarımı hazırlanır. Donanım ve yazılım gereksinimleri belirlenir ve genel sistem mimarisi tanımlanır. Bu aşamada yapılan tasarım özellikleri kodlama aşamasında kullanılır.
5. Uygulama/Kodlama : Tasarım şartnamesine göre geliştirme/kodlamanın fiilen başladığı aşamadır. Proje yöneticisi, derleyiciler, hata ayıklayıcılar, yorumlayıcılar ve medya editörleri gibi araçları kullanarak genellikle programcılar, arayüz tasarımcıları ve diğer uzmanlardan oluşan ekip üyeleri arasında görevleri devreder. Projenin doğasına ve ekip büyüklüğüne bağlı olarak ekip daha küçük birimlere ayrılır.
6. Çoğu durumda, sistem önce birim adı verilen küçük programlarda geliştirilir ve bir sonraki aşamaya entegre edilir. Her birim geliştikçe, Birim Testi olarak adlandırılan işlevselliği açısından test edilir. Bu adımın nihai çıktısı, önceden tanımlanmış bir kodlama standardına göre oluşturulmuş ve sistem mimarisi gereksinimlerini karşılamak için hata ayıklanmış, test edilmiş ve entegre edilmiş bir veya daha fazla ürün bileşeni olabilir. Ekip büyüklüğü ne olursa olsun, işbirliği ve koordinasyon, tüm gereksinimlerin karşılanmasını sağlamak için kritik öneme sahiptir.
7. Test Etme : Geliştirilen tüm birimler entegre edildikten sonra, geliştirilen tüm sistem herhangi bir hata için test edilir. Bu aşamada müşterinin beklentilerine uygunluğu da doğrulanır.
8. Dağıtım : Tüm testler tamamlandıktan sonra ürün veya süreç müşteriye teslim edilir, piyasaya sürülür veya uygulanır. Bu süreç sırasında, endüstriye özgü tüm yaygın yönergeler, düzenlemeler ve/veya kurumsal yönergelere kesinlikle uyulmalıdır. Ayrıca, nihai uygulamanın başarısını doğrulamak için uygulama sonrası doğrulama ve testler yapılmalıdır.
9. Bakım : Son kullanıcı tarafından herhangi bir sorun tespit edilmesi durumunda, geliştirme ekibinin etkinliğini sağlamak için ürünü çözmesi, değiştirmesi veya değiştirmesi gerekir. Bakım periyodu genellikle belirli ve önceden kararlaştırılan bir zaman periyodu içindir.

Şema 2: Yazılım Geliştirme İçin Tipik Bir Şelale Modelinin Temel Temsili

Şelale PM Modelinin Popülaritesi

Dr. Royce'un insanları modelin tuzakları konusunda uyarma girişimine rağmen Şelale Modeli neden bu kadar yaygın bir popülerlik kazandı?

Şelale metodolojisi, proje yönetimi için kullanılan en yaygın metodolojidir. Bu model, kendisine “şelale” adı verilmeden önce de çeşitli endüstrilerde kullanılıyordu. Şelale Modelinin popülaritesinin ve yaygın kullanımının başlıca nedenleri şunlardır:

• Anlaması, kullanması ve yönetmesi kolay

Çoğu proje yöneticisi, bir projenin yaşam döngüsünü takip ettiği için Şelale Modelinin yapısını anlaması ve uygulaması kolay bulur. Ayrıca ekibi eğitmeye ve onları Şelale metodolojisine alıştırmaya gerek yoktur. Tüm sürecin katılığı, sadece uygulamayı ve kontrol etmeyi kolaylaştırmakla kalmaz, aynı zamanda proje yönetiminin yükünü de azaltır.

• disiplinli

Şelale Modelinin açıkça yapılandırılmış yaklaşımı, izlemeyi kolaylaştırır ve her aşama bittiğinde proje yöneticisi ve müşteri gözle görülür ilerlemeyi görebilir. Gereksinim ve tasarım aşamasında maksimum zaman harcandığından, ekibin son teslim tarihini kaçırma olasılığı büyük ölçüde azalır.

• Kalite ve Detaylı Dokümantasyon

Dokümantasyon, ilk aşamalardan itibaren korunur ve güncellenir. Belgelerin titiz bir şekilde güncellenmesi, ekip ile müşteri arasında neyin teslim edileceği konusunda tam bir anlayış olmasını sağlar. Bu, yalnızca planlamayı ve tasarımı daha basit hale getirmekle kalmaz, aynı zamanda belirli bir aşama hakkında daha fazla ayrıntı görmeleri gerektiğinde paydaşlara da yardımcı olur.

• Minimum Müşteri Katılımı

Şelale Modeli, gereksinim açıkça tanımlandıktan ve anlaşıldıktan sonra, kesinlikle bir müşteri mevcudiyeti gerekmeyecek şekilde tasarlanmıştır. Bu, ekip üzerindeki ek yükü ortadan kaldırır ve projenin sonraki aşamalarında herhangi bir yeni değişikliğin yapılmasını engeller ve bu da projenin zamanında tamamlanmasını sağlar.

• bölümlendirme

Waterfall Model'in esnekliği, ekibin çeşitli üyelerinin projenin hangi aşamada olduğuna bağlı olarak diğer projelerde yer almasına veya çalışmaya devam etmesine izin verir. Geliştirmenin her aşaması için belirlenen zamanlanmış son tarihlerle proje, kaynakları sırayla serbest bırakarak geliştirme sürecinden geçer. .

• Kalite Sigortası

Bu model, gereksinimleri açık ve kesin olarak tanımlanmış ve gereksinimlerde sonradan herhangi bir değişiklik yapılmasının mümkün olmadığı projeler için idealdir. Ayrıca Şelale Modeli, ürün kalitesinin zaman veya maliyet kaygılarından daha fazla tercih edildiği projeler için idealdir.

Neden Daha Fazla Proje Şelale Proje Yönetim Modelini Kullanmıyor?

Şelale Modelinin en büyük avantajlarından bazıları, projenin niteliğine göre dezavantajlara dönüşmektedir.

Yazılım geliştirme projeleri için Şelale metodolojisinin en büyük sınırlaması, uzun veya büyük ölçekli projeler için pek uygun olmamasıdır. Diğer dezavantajlar şunlardır: (6)

• Çok Az Değişiklik veya Revizyon Yok:

Şelale Modelinin açık ve iyi tanımlanmış gereksinimlere vurgusu, bir kez sonuçlandırıldığında gereksinimlerdeki herhangi bir değişikliğin yalnızca zor değil, aynı zamanda maliyetli olacağı anlamına gelir. Bu nedenle Şelale Modeli, belirsiz gereksinimleri olan projeler için uygun değildir. Bu aynı zamanda, uzun vadeli projelerde yazılım ve donanımdaki herhangi bir değişikliğin ele alınmasının zor olacağı anlamına gelir. Bu aynı zamanda beklenmedik proje oluşumlarının bu yöntemle ele alınamayacağı anlamına gelir.

• Ürünün Geç Teslimi:

Modelin önceki aşamaları gereksinimleri anlamaya ayrıldığından, yazılım geliştirme daha sonra proje yaşam döngüsünde başlar. Bu, paydaşların yazılımı proje yaşam döngüsünde daha sonra göremeyecekleri anlamına gelir.

• Gereksinimleri Doğru ve Eksiksiz Toplamanın Elverişsizliği :

Başlangıç ​​aşamasında net, iyi tanımlanmış ve eksiksiz gereksinimleri toplamak sadece zor olmakla kalmaz, aynı zamanda bazı projeler için pratik olmayabilir. Genellikle müşteriler, proje yaşam döngüsünün başlarında tüm gereksinimlerin net bir resmine sahip olmazlar, bunun yerine proje ilerledikçe gereksinimleri öğrenir ve netleştirirler.

Şelale Modelinin Modern Tasviri

Çeşitli dezavantajlarına rağmen, modern Şelale Modeli, en yaygın yazılım geliştirme yaşam döngüsü (SDLC) modelleri arasındadır. Şelale Modelinin modern versiyonu, teslimat sonrası bakım da dahil olmak üzere proje yaşam döngüsü boyunca geri bildirim döngüleri içerir.

Bu modelde Test, ayrı bir aşama olmayıp yazılım süreci boyunca sürekli olarak gerçekleştirilir. Bu, yalnızca yazılımın gerektiği gibi çalışmasını sağlamakla kalmayıp, aynı zamanda herhangi bir ek gereksinimin de tasarıma dahil edilmesini sağlamak için bakım aşamasında özel bir önem verilir.

Modern Şelale Modeli, yazılımın kullanımdan kaldırılmasına kadar geliştirme ve bakım sırasında izlenecek rotayı net bir şekilde göstermektedir. Modern Şelale Modeli, geleneksel Şelale Modeli ile ilgili sorunların çoğunu ortadan kaldırır, ancak kendi sorunları ile birlikte gelir. Örneğin, her aşamanın tamamlanması, o aşamaların eksiksiz ve kaliteli dokümantasyonunu ve yazılım kalite güvence (SQA) grubu tarafından onaylanmasını içerir ve herhangi bir değişiklik olması durumunda bu da yapılmalıdır. Eksiksiz belgelerin korunmasında ısrar, gecikmelere ve gereksiz evrak işlerine neden olabilir.

Nakit Çekme için ACME Süper ATM Kullanım Örneği Modeli

Kısa açıklama:

Bu kullanım örneği, bir Banka Müşterisinin bir banka hesabından para çekmek için ATM'yi nasıl kullandığını açıklar.

Aktörler:

Aşağıdaki şekil, ACME Süper ATM kullanım senaryosu modelindeki tüm aktörleri göstermektedir.

Aktörler arasında müşteriler, banka sistemi, hizmet yöneticisi ve güvenlik yöneticisi yer almaktadır.

Ön koşullar:

• Banka Müşterisinin bir banka kartına sahip olması gerekir.
• Banka Sistemine ağ bağlantısı aktif olmalıdır.
• Sistemde en azından dağıtılabilecek bir miktar nakit olmalıdır.
• Nakit çekme hizmeti seçeneği mevcut olmalıdır.

Ayrıca Bakınız:

Bir Profesyonel Gibi Başa Çıkmak için 5 Ortak Proje Yönetimi Zorluğu ve Çözümü

Temel Akış:

• Kartı Takın
• Kartı Oku
• Müşterinin kimliğini doğrula
• Para Çekmeyi Seç
• Sistem, makinede mevcut olan farklı servis seçeneklerini görüntüler.
• Tutarı Seç
• Sistem, standart para çekme tutarlarının listesini görüntüleyerek çekilecek tutarı sorar.
• Para Çekmeyi Onayla
• Eldeki Fonları Değerlendirin
• Davranış İşlemini Gerçekleştirin
• Kartı Çıkar
• Müşteri banka kartını makineden alır
• Nakit Dağıt
• Sistem, talep edilen miktarı Müşteriye dağıtır.
• Sistem, para çekme işlemi için bir işlem günlüğü girişi kaydeder
• Vaka Sonunu Kullan

Alternatif Akışlar:

Alternatif Akışlar, aşağıdaki senaryolar için akışları içerir:

• Standart Olmayan Bir Tutarın Çekilmesini Yönetin
• Okunamayan Banka Kartını Kullanın
• Makbuz İşleme
• Hata yönetimi
• Banka Sisteminin Yanıt Vermeyi Durdurmasını Yönetin

İstisna Akışları:

İstisna Akışları, aşağıdaki senaryolar için akışları içerir:

• Eldeki Fonları Değerlendirin
• Para Çekme İşlemi
• Hizmet Kapatma
• İşlem Ayarlamalarını Yönetin

Posta Koşulları:

• ATM kartı iade etmiş ve parayı Müşteri'ye vermiş ve para çekme işlemi Müşteri'nin hesabına kaydedilmiştir.
• ATM, kartı Müşteri'ye iade etmiştir ve Müşteri'nin hesabına para çekme işlemi yapılmamıştır.
• ATM'nin kartı iade etmesi, ancak Müşteri'nin hesabından çekildiği üzere kayıtlı nakit miktarını sağlamaması; tutarsızlık ATM'nin günlüklerine kaydedilir.
• ATM kartı saklamış, Müşteri'nin hesabına herhangi bir para çekme işlemi kaydedilmemiş ve Müşteri'ye daha fazla bilgi için nereye başvuracağı bildirilmiştir.

Genel Yayın Noktaları:

Hiçbiri

Özel gereksinimler

• Güvenilir Nakit Verme

ACME Süper ATM Nakit Çekme Kullanım Örneği Modelinde, tüm gereksinimler sabittir ve açıkça tanımlanmıştır, dolayısıyla Şelale Modeli bu örnek için idealdir. Gereksinimler belirlendikten sonra, müşteriden çok az geri bildirim istendi ve geliştirme ve tasarım aşamaları, sıralı bir desen izlenerek tamamlanabildi. Proje, nTask gibi proje yönetim yazılımlarının yardımıyla, her aşaması açıkça tanımlanmış ve gereksinimlere göre ayrılmış olarak kolayca yönetilebilir.

Müşterinin Kimliğini Doğrulamak için ACME Süper ATM Kullanım Örneği Modeli

Kısa açıklama:

Bu kullanım örneği, ATM'yi kullanan kişinin (Müşteri) takılı banka kartını kullanmaya yetkili olduğunu ve banka kartıyla ilişkili hesabın aktif olduğunu doğrulamak için kullanılır.

Aktörler:

Aktörler arasında müşteri, banka sistemi, hizmet yöneticisi ve güvenlik yöneticisi yer almaktadır.

Ön koşullar:

• Banka kartı ATM'ye takıldı.
• Banka kartı bilgileri başarıyla okundu.
• Bir Müşteri, dahil edilen kullanım senaryosu ile diyalog halindedir.
• ATM Oturum Kimliği oluşturuldu.

Temel Akış

• Kart Bilgilerini Doğrula
• Sistem banka kartı bilgilerini Banka Sistemine gönderir.
• Sistem ayrıca ATM ID'sini ve ATM oturum tanımlayıcısını Banka Sistemine gönderir.
• Banka Sistemi, banka kartı bilgilerinin geçerli olduğunu ve kartın kullanılabileceğini kabul eder.
• Kullanıcı Kimliğini Doğrula
• Sistem Müşteriden PIN'i ister
• Müşteri PIN'i girer
• Sistem, girilen PIN'in banka kartından okunan PIN ile aynı olup olmadığını kontrol eder.
• PIN Doğrulandı
• Kullanım Vaka Sonları

Alternatif Akışlar:

Alternatif Akışlar, aşağıdaki senaryolar için akışları içerir:

• Banka Sistemi İle İletişimi Yönetme
• Müşterinin Bankasıyla Hiçbir İletişimi Yönetme
• Etkin Olmayan Kartı veya Hesabı Yönetin
• Çalınan Banka Kartını Kullanın
• Geçersiz Banka Kartı Bilgilerini Kullanın
• Doğru PIN Girilmedi
• Hata yönetimi
• Banka Sisteminin Yanıt Vermeyi Durdurmasını Yönetin

İstisna Akışları:

İstisna Akışları, aşağıdaki senaryolar için akışları içerir:

• Eldeki Fonları Değerlendirin
• Para Çekme İşlemi
• Hizmet Kapatma
• İşlem Ayarlamalarını Yönetin

Posta Koşulları:

• Müşteriye kartı kullanma yetkisi verilmiştir.
• Müşterinin kartı kullanması engellenmiş ve kartına el konmuştur.
• Müşterinin kartı kullanması engellenmiş ve kartına el konulmamıştır.

Genel Yayın Noktaları

Hiçbiri

Özel gereksinimler

Hiçbiri

Müşteriyi Doğrulamak için ACME Süper ATM Kullanım Örneği Modelinde tüm gereksinimler sabittir ve açıkça tanımlanmıştır. Proje boyutu küçüktür ve katı bir süreç yardımıyla kolayca tamamlanabilir. Gereksinimler not edildikten sonra geliştirme ve tasarım aşamaları doğrusal bir süreçte tamamlanabilir. Proje, nTask gibi proje yönetim yazılımlarının yardımıyla, her aşaması açıkça tanımlanmış ve gereksinimlere göre ayrılmış olarak kolayca yönetilebilir.

Endüstri Uygulaması – Amerika Birleşik Devletleri Savunma Bakanlığı

Şelale metodolojisinin kullanımına ilişkin yaygın olarak başvurulan örnek, Amerika Birleşik Devletleri Savunma Bakanlığı'nınkidir. 1985'te Amerika Birleşik Devletleri Savunma Bakanlığı, yazılım geliştirme müteahhitleriyle çalışma standartları olan DOD-STD-2167A'daki Şelale yaklaşımını kullandı. Metodolojilerini “şelale” olarak belirtmemiş olsalar da, Amerika Birleşik Devletleri Savunma Bakanlığı (DOD), Şelale Modeli'nin temel ilkelerini halen kullanmaktadır.

Amerika Birleşik Devletleri hükümeti, modelin avantajları gereksinimlerini mükemmel bir şekilde yerine getirdiği için Şelale Modeli'ne karar verdi. Federal hükümet, nihai ürün üzerinde büyük bir kontrol sağlarken mühendislik titizliği ve üstün kaliteli bir ürün üzerinde ısrar etti. Bu, altı aşamanın (Ön Tasarım, Ayrıntılı Tasarım, Kodlama ve Birim Testi, Entegrasyon ve Test) dahil edilmesiyle birlikte kapsamlı belgelerle birleştirilmiş, tek geçişli, sıralı geliştirme yöntemi ve ağır gözetim için güçlü bir tercih DOD'u yapar. -STD-2167 Şelale Metodu'nun en güzel örneğidir.

1986'da, yukarıdan aşağıya tasarım vurgusunu ortadan kaldıran ve şelaleye alternatif olarak hızlı prototiplemenin kullanılmasını öneren MIL-STD 2167'ye Revizyon A'nın bir taslak kopyası çıktı. Bunun nedeni, Şelale Modelinin zaman içinde ağır eleştirilere maruz kalmasıydı. DOD'un Şelale Metodolojisinden uzaklaşmasına rağmen, ABD Federal yazılım geliştirme ve satın alma, donanım odaklı ve şelale yaklaşımını hala korudu.

Ulusal Araştırma Konseyi'nin 2010 tarihli bir raporu, mühendislik ve üretim geliştirme aşamalarını tanımlamak için kullanılan terminolojinin kaçının, ön tasarım incelemeleri ve kritik tasarım incelemeleri gibi Şelale Modeli öğelerine odaklandığını vurguladı. Şelale Proje Yönetim Metodolojisine yapılan bu vurgu, kalite ve gizliliğe artan bir vurgu nedeniyle olabilir. Şelale Modelinin ayrı aşamaları, ekibin her üyesinin tüm projede yer almamasını sağlar.

2000 yılında, DOD Instruction (DODI) 5000.2, evrimsel edinimi, edinim için tercih edilen yaklaşım olarak tanımladı. Bununla birlikte, 5000 serisi yönetmeliklere Şelale Modeline özgü terminoloji hakim olmaya devam etmektedir. Waterfall Model'in ticari markaları olan ön tasarım incelemeleri (PDR'ler) ve kritik tasarım incelemeleri (CDR'ler) her program için öngörülmüştür.

Şelale Proje Yönetim Modeli size göre mi?

Birçok dezavantajı ve kısıtlamasına rağmen, Şelale Modeli bugün hala kullanılmaktadır. Ancak tek bir proje yönetimi yöntemi tüm işletmelerin ihtiyaçlarına, hatta aynı işletme tarafından yürütülen tüm projelere bile uymaz. Bu nedenle, proje ihtiyaçlarınız için ideal model olup olmadığı çeşitli faktörlere bağlıdır.

İş, türe, boyuta, sektöre ve diğer birçok faktöre göre değişiklik gösterdiğinden, projeler de değişir. İşletmeler en iyi metodolojiyi aramak yerine bu metodolojileri, kullanımlarını ve uygulamalarını öğrenmeli ve aşağıdaki değişkenlere göre en iyi metodolojiye karar vermelidir:

• Örgütsel hedefler
• Temel değerler
• Proje kısıtlamaları
• Proje paydaşları
• Proje boyutu
• Projenin maliyeti
• Risk alma yeteneği
• Esneklik ihtiyacı

Şelale Modeli, nihai ürün gereksinimleri sabit ancak zaman ve para değişken olan işletmeler tarafından kullanılır. Şelale Modeli, proje yöneticilerinin istenen sonuca ulaşılana kadar aynı projeyi birden çok kez başlatmasına izin verir. Pek çok işletme, arzu edilen optimum sonuca ulaşana kadar yaklaşımlarını ayarlamak ve yeniden düşünmek için Şelale metodolojisinin yerleşik mekanizmasını bulamaz.

Şelale metodolojisi, açıkça anlaşılmış, sabit ve belgelenmiş gereksinimler, iyi anlaşılmış teknik araçlar, mimariler ve altyapılar, gerekli uzmanlığa sahip geniş kaynaklara erişim, istikrarlı, iyi tanımlanmış bir ürün ve kısa bir yaşam döngüsü olan projeler için idealdir. Şelale Modelinin doğrusal yaklaşımı, keşif veya ilk ürün gereksinimlerinde herhangi bir değişiklik yapılmasına izin vermez. Gereksinimlerdeki herhangi bir değişiklik, projenin birinci aşamaya dönmesini ve tüm sürecin baştan başlamasını gerektirecektir. Bu, çoğu katı bir zaman çizelgesi üzerinde çalışan birçok sektörde ciddi bir sorun olabilir.

Aşağıdaki tablo oldukça faydalıdır. Bir göz at.

Tablo 1: Şelale Modeli Gereksinimleri

Proje yönetimi metodolojisi günümüz işletmeleri için hayati önem taşımaktadır. İşletmeniz için uygun bir stil kullanarak ekibinizin işbirliği yapma, görevler üzerinde çalışma ve proje kilometre taşlarını gerçekleştirme şeklini değiştirebilirsiniz.

Yazılım Endüstrisinde Uygulama

Şelale Modeli, ürün gereksinimlerinin net olarak tanımlandığı yazılım sektöründe yaygın olarak kullanılmaktadır. Royce'a göre en basit program sadece iki adımda tamamlanabilir: Analiz ve Kodlama. Ancak, daha karmaşık programlar için daha fazla planlama gerekebilir.

Herhangi bir yazılımın geliştirilmesi için ilk adım, işlevsel belirtimi oluşturmak olacaktır. Şelale Modelinin etkili olabilmesi için bu özelliklerin iyi planlanmış ve net bir şekilde tanımlanmış olması önemlidir. Bu, iş sürecini daha iyi anlamak için iş uzmanlarıyla konuşmayı ve şu anda manuel veya eski bilgisayar sistemleri tarafından sağlanan iş süreçlerini incelemeyi içerecektir.

Ayrıca Bakınız : JIRA Bugünün Pazarında Üretken Bir Proje Yönetim Yazılımı mı?

Gereksinimler belirtildiğinde, iş uzmanları ve müşteriler tarafından onaylanmalıdır. İşlevsel spesifikasyon tamamlandığında, gereksinimlerin son kopyası hazırlanır ve kilitlenir.

Bunu, kullanıcı arayüzü ile birlikte çalışmayan bir prototip uygulamasının üretimi takip eder. Bu, müşterinin ve geliştiricilerin ürünün nasıl çalışacağını anlamasına yardımcı olur. Bu aşama tamamlandıktan sonra yazılımın geliştirilmesi başlar.

Uygulama tamamlandığında ve test edildiğinde, bir beta sürümü yayınlanır ve test için sağlanır. Bulunan herhangi bir hata hızla onarılır. Önemli bir hata kalmadığında, uygulama sürüm 1.0 olarak yayına girebilir.

Otomobil Endüstrisi için Başvuru

İnşaat ve imalat gibi endüstriler, Dr. Royce'un 1970 yılında makalesini yayınlamasından bu yana Şelale Modelini kullanıyor. Otomobil endüstrisinin montaj ve üretim süreci katıdır ve tesis kurulduktan sonra çok az ayarlama gerektirir. Böylece, ana gereksinimler daha tesis kurulmadan tartışılır ve karara bağlanır ve gereksinimler göz önünde bulundurularak tasarım ve üretim süreci kurulur.

Montaj işleminin kendisi, gerçekleştirilmesi gereken bir dizi görevi takip eder, aksi takdirde tüm süreç çöker. Sadece bir aşama tamamlandığında süreç bir sonraki aşamaya geçebilir. Gereksinimlerdeki herhangi bir değişiklik, sürecin tamamen elden geçirilmesini gerektirebilir ve ekstra zaman ve para gerektirebilir.

SDLC'de nTask Vs Şelale

Şelale Modelinin ihtiyaçlarınıza en uygun model olduğuna karar verdikten sonra, nTask gibi bulut tabanlı bir işbirliğine dayalı proje yönetim sisteminin kullanımını düşünmelisiniz. nTask gibi ortak çalışma araçları, hangi proje yönetimi metodolojisini kullanırsanız kullanın, ekibinizin üretkenliğini ve verimliliğini artırmak için özel olarak tasarlanmıştır.

nTask'ın yardımıyla, farklı boyutlardaki projeleri kolayca yönetebilir, görevler atayabilir ve devredebilir, dosya ve bilgileri gerçek zamanlı olarak paylaşabilir ve tüm proje yönetimi ihtiyaçlarınızı karşılayabilirsiniz.

Şelale metodolojisini denemeye karar verdiniz mi? Artık bu yöntemde belgelendirmenin önemini anladığınıza göre, ilk adımın gerekli tüm görevleri izlemek ve bunları ekibinizle paylaşmak için bir platform bulmak olduğunu biliyorsunuz.

nTask, gereksinimleri topladığınız andan test aşamasına kadar size yardımcı olabilir:

• Her aşamanın süresini ve ilgili paydaşları yönetin ve açıkça belirtin.
• İlgili tüm paydaşlarla tüm gereksinimleri gerçek zamanlı olarak toplayın, tartışın ve belgeleyin. nTask ile bir sonraki aşama, yalnızca bir önceki aşamanın tamamlanmasıyla başlayacak ve ardından yalnızca eksiksiz dokümantasyon ve onay gelecektir.
• Kesinleşmiş gereksinimlere göre ekibiniz için bir iş akışı oluşturun. nTask, projenin ilerleyişini net bir şekilde görmenizi sağlar ve Şelale Modelinin her aşamasındaki her bir görev hakkında geri bildirimde bulunmanıza olanak tanır.
• nTask, tüm ekiple veya yalnızca ekibin bir kısmıyla işbirliği yapmayı ve iletişim kurmayı kolaylaştırır.
• Şelale Modelinin her aşaması için eksiksiz dokümantasyon yapmak, sürdürmek ve paylaşmak nTask'ın yardımıyla kolaydır. Ekip üyeleriyle yalnızca ilgili bilgilerin paylaşılması için belgeleri kimlerin görüntüleyebileceğini kontrol edebilirsiniz.

Bu noktada kesmekten nefret etsek de, bu iki bölümlük bir yazı. Daha fazla güncelleme için bu sayfayı yer imlerine ekleyin ve bir veya iki hafta sonra takip etmeyi unutmayın. Şimdiye kadar, paylaşacak bir şeyiniz varsa, bunu aşağıdaki yorumlar bölümünden yapabilirsiniz. Alternatif olarak, bize [email protected] adresinden bir e-posta gönderebilirsiniz. Size geri dönmeyi çok isteriz.

Ayrıca Okuyun:

• 2022'nin En İyi 21 Ücretsiz Verimlilik Uygulaması
• Kişisel Görev Yönetimi için 2022'nin En İyi 23 Yapılacak Listesi Uygulaması
• 2022'nin Proje Yöneticileri için 10 Temel Proje Yönetimi Becerisi
• İşleri Bitirme (GTD) Yöntemi ve 14 En İyi GTD Uygulaması ve Aracı
• Ekip Üretkenliğini Artırmak için En İyi 19 Zaman Takip Yazılımı
• 2022'de Yeni Başlayanlar İçin En İyi 27 Görev Yönetimi Yazılımı
• 2022'nin En İyi 36 Ücretsiz Verimlilik Uygulaması
• Kişisel Görev Yönetimi için 2022'nin En İyi 30 Yapılacak Listesi Uygulaması
• 2022'de Çevik Ekipler için En İyi 22 Ücretsiz Proje Yönetim Aracı
• Sanal Ekipleri Yönetme: Zorluklar, İpuçları ve Sanal Ekip Yönetim Araçları
• İşbirliği ve Motivasyonu Kutlamak İçin En İyi 47 Takım Çalışması Alıntısı