Açık kaynaklı yazılım projelerinde gereksinimler nasıl belirlenir?

Şirket içi yazılım geliştirmede, gereksinimlerin bir dizi gereksinim belgesinin yaratılmasıyla sonuçlanan resmi bir süreçle belirlenmesi yaygındır. Açık kaynak yazılım geliştirmede, bu genellikle yoktur. Dolayısıyla sorum şu: açık kaynaklı yazılım projelerinde gereksinimler nasıl belirlenir?

"Gereksinimleri belirleme" ile basitçe "belirli bir yazılımın parçası olarak hangi özelliklerin vb. Geliştirilmesi gerektiğini anlamak" derim.

Açık kaynak projeleri bazen yoğun kullanıcı geri bildirimi akışlarına sahip olabilir ve bazen şirketler planlanan ve uygulanan belirli özellikleri (kendi geliştiricilerini veya orijinal geliştiricilerini işe alarak) yapmak için ödeme yaparlar.

Projenizde 100 kullanıcı varsa, muhtemelen kodlaması en eğlenceli olanı geliştirebilirsiniz.

Projenizde 100 bin kullanıcı varsa, büyük olasılıkla çoğu kullanıcının bir sonraki sürümde düzeltilmesini istediği acı noktalarının bir listesi ve kullanıcıların sorun izleyicinizde istediği ve forumlarda sormaya devam ettikleri en iyi N özelliklerinin bir listesi var.

Bu geri bildirimle, çekirdek ekibiniz için gereksinim belgeleri yazabilir, bağımsız katılımcıların vizyonunuzu anlamasına yardımcı olacak yol haritaları oluşturabilir ve 100 bin kullanıcıdan bazılarının yamalar halinde göndereceğini umabilirsiniz.

1995'te linux'u ilk duyduğumdan beri açık kaynak takip ediyorum ve bu bağlamda kullanılan 'gereksinimler' kelimesini duyduğumu hatırlayamıyorum.

Eric Raymond'un iyi bir makalesi var, Katedral ve Çarşı , içinde 'kendi kaşını çizmek' hakkında konuşuyor. Kişisel olarak karşılaştığınız bir sorunu çözmeye çalışıyorsanız, çözüp çözmediğinizi anlamak için gereksinim belgelerine başvurmanız gerekmez.

Aynı makale, kullanıcılarınızı dinlemekten de bahsediyor, bu da sadece açık kaynaklı projeler için değil, herkes için iyi bir tavsiye. Açık kaynak projeleri meritokrat olma eğilimindedir, bu yüzden 'kodu yazan, kuralları yapan kişi', az çok.

Şirket içi yazılım geliştirmede, gereksinimlerin bir dizi gereksinim belgesinin yaratılmasıyla sonuçlanan resmi bir süreçle belirlenmesi yaygındır.

Benim tecrübelerime göre bu, sözleşmeye dayalı geliştirme yaparken, özellikle şirketiniz için geliştirme yapan harici bir şirkete sahipken çok daha yaygındır ve bir sözleşmeye yasal ihtiyaç vardır. Ancak diğer pek çok şirket kurum içi gelişimlerini kendi insanları tarafından farklı bir şekilde kontrol ediyor:

• resmi olmayan iletişim

• öncelikli gereksinimler / hatalar / sorunlar / bilet listeleri (ve bu kesinlikle "çevik" topluluğun bir buluşu değildir)

Bu, çoğu açık kaynak projesinin çalışmasıyla aynıdır - resmi bir sözleşmeye gerek olmadığından, hiç kimse büyük, ayrıntılı, resmi gereksinim belgelerini, sadece küçük, ağrısız eksik özellikler listelerini veya bir sayıda toplanan biletleri çözülecek izci.

Sorun, derleyici veya tarayıcı yazmak gibi yaygın bir sorunsa, gereksinimler hemen hemen dil standartları, hedef işletim sistemleri ve hedef donanım vb. Şeklinde verilir.

Bir metin editörü olma hedefini mükemmel bir şekilde yerine getirmenin yanı sıra, birçok şey için GNU Emacs gibi şeyler için, gereksinimleri genişletmek için büyük kapsam nedeniyle mantıklı olduğunu düşünüyorum. Sohbetler, e-postalar, haber grupları, kod düzenleme, sürüm kontrolü akla geliyor. Emacspeak üzerinde çalışan bir araştırma bilimcisi var. Tarayıcılar ve uzantılara izin veren diğer şeyler için de benzer şeyler söylenebilir.

Yazılım yalnızca açık kaynaklı olmayan yazılımlarda kullanılabilen bir işlevi yakalarsa, gereksinim hemen hemen tekrar verilir.

DÜZENLE:

Açık kaynaklı yazılım bakıma devam ettiğinde ve daha az orijinal gereksinim karşılanmadığında, gereksinimlerin çoğu hatalardan gelebilir, çok çekirdekli CPU'lar ve istismar edildiğinde daha iyi performans sunan diğer donanımlar gibi yeni platformlara uyum sağlaması gerekir.

GNU Hurd gibi tamamen araştırmaya dayalı bir projede, gereksinimlerin araştırma sonuçlarından ve belgelerden geldiğini düşünüyorum.

Sonuç olarak,

• başlangıçta, ortak sorunları çözmeye çalışan yazılım gereksinimleri standart belgelerden gelebilir

• diğer mevcut yazılımlara yetişen yazılımlar için, gereksinimlerin mevcut yazılımın özellik setinin tamamını veya çoğunu ve geliştiricilerin / kullanıcıların sahip oldukları ilginç buldukları diğer bazı özellikleri üretmesi muhtemeldir.

• araştırma projeleri, makaleler ve diğer yayınlar için

• bakımdayken, hatalar, daha yeni ortamlara uyum sağlaması gereklilikler

Emin değilim, ama bir kez öneri, JIRA gibi bir şey kullanarak, her bilet bir özelliği veya gereksinimi temsil eden, gereksinimlerin bilet (veya "kart") olarak yükseltildiği Agile benzeri bir metodoloji kullanmaktır. Her bilet daha sonra daha küçük iş birimlerini temsil eden diğer biletlere ayrılabilir.

Bir uygulamanın veya yazılımın ne yapması gerektiğini gerçekten anlamaya gelince, basit cevap "diğer geliştiricilerle konuşmak" tır. :) Bu durumda "konuşmak", farklı zaman dilimlerindeki ve coğrafi konumlardaki kişilerin sohbet etmesine olanak tanıyan bir e-posta dağıtım listesi, forum veya hatta IRC anlamına gelebilir.