Yazılım geliştirme metodolojilerinin süreç tanımları için iyi kaynaklar?

Question

Yazılım organizasyonlarında uygulanan gerçek yazılım geliştirme süreçlerini paylaşmak ve bunlara erişmek için özel bir web sitesi var mı?

Bu işlemlerin uygulanması için öneriler ve açıklamalar veren birçok kaynak vardır. Çok faydalılar. Ama gerçek örnek süreç tanımlarına sahip olmanın da çok yararlı olacağını düşünüyorum. Özellikle, CMMI'de örnek bir süreç tanımı arıyorum. Birkaç kitaba genel bakış yaptım, ancak hiçbiri belirli bir örnek uygulama sunmuyor.

Yazarların büyük olasılıkla okuyucuların, bu süreç tanımlarını kendilerinde özel uyarlama kararlarını anlamadan kopyalayabileceklerinden endişe duyuyorlar. Bu konuda çok haklılar. Ama yine de, bu genel yazılım topluluğu için önemli bir ihtiyaç olduğunu düşünüyorum. Örnek bir belgeyi doğru anlamak ve yorumlamak, okuyucunun sorumluluğunda olmalıdır.

Süreçlerin belirli uygulamalarını paylaşan iyi bir kaynak bilmiyorsanız, bu ihtiyaç hakkında ne düşünüyorsunuz? Yazılım mühendisleri ve geliştiricileri kodumuzu paylaştığımızda süreç tanımlarımızı paylaşmamız gerektiğini düşünmüyor musunuz?

Answer 1

Böyle bir "süreç deposu" bilmiyorum. Sadece this one gibi genel açıklamayı görüyorum.

Not: Geldiğim CMMI uygulamaları belirli bir kuruluş/ortam için oldukça uygun olsa da, bunları değerlendirirken/meydan okurken gerçekten etkili buldum. Bu bağlamda

, çalışma Six Sigma and CMMI ilginç, CMM pratik bir örneği olarak bu kadar, daha ziyade perspektiften CMM koymak için bir yol olarak değil.

Answer 2

Çok fazla kaynağa sahip iyi bir wikipedia article var. IBM Rational web'de "UCM İş Akışları" nın da aranması iyi örneklere yol açacak, sayfalarına derin bir bağlantı vermekteyim. Soru, sürecin içine girmek istediğiniz detayın ne kadar olduğu. Mevcut olan çoğu kaynak sadece temel geliştirme süreçleri hakkında genel bir fikir verecektir.

Örneklerle kastettiğiniz şey muhtemelen bu tür geliştirme sürecinin özel uygulama ayrıntılarına giriyor. Daha büyük ve köklü yazılım geliştirme şirketleri için, geliştirme süreçleri büyük olasılıkla yeniden kullanılabilir olmayacaktır çünkü birçok özel yapım araçları ve konfigürasyonları içerecektir ve sürecin kendisi bazı durumlarda özel olarak kabul edilebilir ve şirkete başkalarına karşı rekabet avantajı sağlayabilir. Süreçle ilgili ayrıntılara girilmesi de bir güvenlik riski oluşturabilir çünkü şirket altyapısı hakkında çok şey ortaya koyacaktır. Bu yüzden, başarılı yazılım geliştirme şirketlerinden örnekler şeklinde çok şey bulacağınızı sanmıyorum. Bulduğun şey ya çok genel ya da teori hazırlayıcılar tarafından yazılıyor.

Bu, neredeyse on yıldan beri benim için özel bir ilgi alanıdır ve sadece büyük yazılım şirketlerinin kullandığı özel süreçler hakkında yayınlanmış parçalar ve parçalar buldum. Bu alandaki diğer profesyonellerle deneyimlerini paylaşmak için bir konferansı kesinlikle memnuniyetle karşılarım.

Answer 3

EPFC - Eclipse Process Composing Framework'e bakmayı deneyin, bunları geliştirmek için bazı örnek işlemler, araçlar ve en iyi uygulamalar vardır.

Answer 4

Başlamanıza yardımcı olacak örnek şablonların sağlanmasında yarar vardır. Sınırlama, kullanıcının uygulamayı düşünmeden şablonları kabul etmeye zorlayabilmesidir.

Çoğu metodoloji, bir takım terzilikle 'kılavuz' yaklaşımı benimser. Örneğin, Rational (şimdiki IBM) tarafından desteklenen RUP sistemi geleneksel olarak sadece büyük ölçekli projelere uygulanabilir olduğu varsayımından muzdaripti. Bu, RUP'un bir kişi projesine nasıl uygulanabileceği üzerine tartışma başlattı. Elbette iş ve çaba gerektirir ve eğer küçük bir proje takımsanız, bazen metodolojiyi uyarlamak projeyi gölgeleyebilir; yani bir metodoloji veya ürün oluşturmaya mı çalışıyorsunuz? süreci iyi hem sürecin örnekler, eserler ve ayrıca bir yorum sağlar ve

Open Unified Process, yani uygulama - -

Agile Unified Process tekrar numuneler, eserler ve kolay navigasyon sistemi:

numuneler gelince bazı örneklerdir.

Answer 5

OPEN Process Framework Repository Organization Web sitesinde 1100'den fazla yöntem bileşeni bulunan çevrimiçi bir depo bulunur.

Son yöntem yoktur, çünkü yöntem mühendisliği ilkelerine göre, ürününüze, projenize ve kuruluş gereksinimlerine bağlı olarak yöntemlerinizi bu bileşenlerden oluşturmalısınız.