Bir projede geliştirmeye başlamadan önce ne planlanmalıdır? [kapalı]


17

Diyelim ki bir müşteriden bir proje için spesifikasyonlar aldım ve şimdi onu geliştirmeye başlama zamanı. Normalde, sadece ilk modülle (genellikle kullanıcı kaydı) başlarım ve sonra bir modülden diğerine geçerim. Sadece nasıl çalışacağını bir modüle başlamak üzereyken kafamda planlıyorum, ama bundan önce bir plan yok.

Ancak, teknik özelliklerin üzerinden geçip sistemin kodlamadan önce nasıl çalışacağını planlamam daha iyi olurdu, örneğin ana bileşenler nelerdir, nasıl etkileşime girecekler, vb. tam olarak ne planlamam gerektiğinden emin değilim.

Ne istediğimle ilgili daha iyi bir fikir vermek için nasıl-

a) Projeyi bileşenlere ayırmak,

b) Etkileşimlerini planlayın, örneğin sınıf diyagramları, yazma birimi testleri vb. yapmalı mıyım?

Herhangi bir fikir?


"Tam olarak ne planlamam gerektiğinden emin değilim"? Neden olmasın? Belirli konuları listelediniz. Listelediğiniz konularla ilgili sorun nedir. "Ana bileşenler nedir, nasıl etkileşime girecekler" ile ilgili sorun nedir? Bunlar endişelendiğiniz şeyler olduğundan, neden oradan başlamıyorsunuz?
S.Lott

4
Müşteriniz er ya da geç özellikleri değiştirecektir. Modül etkileşimlerini, değişikliklerin tüm kod tabanınızı bozmayacak şekilde planlayın.
Reno

Yanıtlar:


24

Yeni bir projeye başlama ayrıcalığına sahip olduğunuzda, aynı zamanda hem heyecan verici hem de göz korkutucu olan boş bir tuvaliniz var. Yinelemelerde çalışıyorum ve işi şu şekilde bölüyorum:

  • Projenin hedefleri ile başlayın. Hedefler mutlaka en belirsiz olanıdır, ancak istemcinin veya kullanıcının yazılımla ne yapmak istediğine odaklanmanıza yardımcı olur. Günün sonunda, bu hedeflere ulaşmak istiyorsunuz - bu gerçekten harika özellikler bırakmak anlamına gelse bile.
  • Sonra uygulamayı alt alanlarına ayırmaya başladım. Muhtemelen bunu yapmanın yüz farklı yolu var, bu yüzden proje hedefleriyle başlıyoruz. Uygulamayı, bu hedefleri destekleyen ilgili alt sistemlere ayırmak istiyoruz. Bu, bir sonraki göreve odaklanmamıza yardımcı olur.
  • Alt sistemlerin nasıl ve ne zaman etkileşim kurması gerektiğini belirleyin. Entegre bir alt sistem sistemine sahip olduğumuzdan emin olmak için ayrıntıları, sadece üst düzey bilgileri ele almıyoruz. Projenin genel hedeflerini destekleyen detayları ortaya çıkarabilmeniz için bunun genel bir fikrine ihtiyacınız var.
  • Yalnızca şu anda üzerinde çalıştığım alt sistem için ayrıntıları sağlayın (mevcut stratejinize benzer). Bu alt sistemin diğer alt sistemlerle nasıl etkileşime girmesi gerektiğini zaten biliyorum, ancak en mantıklı olması için birkaç alternatif bulmam gerekebilir. Her alt sistem bir arayüzle ayrılmıştır, bu yüzden sistemi bir bütün olarak bozmadan uygulamayı mümkün olduğunca ayarlayabilirim.
  • Mevcut alt sistemime işlerin nasıl uygulandığına, diğer alt sistemlere nasıl uygulandığına bakın. Tutarlı olmayan her yaklaşım, kullanıcının öğrenmesi gereken bir şeydir. Yepyeni bir konseptten bahsedersek sorun olmaz. Kullanılabilirlik uğruna, tembel olduğumuz için mevcut olan bilgileri silmek için 5 farklı yol istemiyoruz. Aynı kullanıcı arabirimi öğelerini yeniden kullanmak, uygulamayı daha sezgisel hale getirmenin en hızlı yoludur. Üç kavramı öğrenmek 20 öğrenmekten çok daha kolaydır.

Esasen, bir projeyi çok yüksek seviyeden daha detaylı tasarıma aşamalı olarak tanımlama yaklaşımı bana iyi hizmet etti. Alt sistemleri arasındaki etkileşimler bile, gerçekte onları uygulamaya çalıştıkça rafine edilir. Bu iyi birşey.


"Muhtemelen bunu yapmanın yüz farklı yolu var, bu yüzden proje hedefleriyle başlıyoruz." Hedeflere uygun tasarım desenleri ile başlayacağınızı düşünüyorum. 'Hedefler' düşündüğünü sanmıyorum.
S.Lott

1
Karşılaştığım çoğu müşteri hedeflerini oldukça iyi ifade edebilir, ancak diğer her şeyle zor zamanlar geçirir. Esasen, tasarımımın ihtiyaç duyduklarını karşıladığından emin olmak istiyorum. Proje hedefleri ve müşteri hedefleri aynı hizaya geldiğinde, işlere gerçekten yardımcı oluyor. Daha somut olmak için, evet tasarımımı geliştiriyorum ve problemi çözme şeklimi seçiyorum, böylece her şey sıraya girecek.
Berin Loritsch

8

Teknik özellikleri aşmamın daha iyi olacağını düşünüyorum

Sağ. İyi bir fikir.

kodlamadan önce sistemin nasıl çalışacağını planladı.

İyi. Bundan daha fazlasını yapın.

ana bileşenler nelerdir,

Mükemmel.

nasıl etkileşime girecekleri,

Doğru.

Tam olarak ne planlamam gerektiğinden emin değilim.

Bir sürü şeyi listelediğinizde nasıl emin olamazsınız ? Bunlar sizi ilgilendiren şeylerse, neden sadece bu şeylere odaklanmıyorsunuz?

4 + 1 görünüm modelinde okuyun: http://en.wikipedia.org/wiki/4%2B1_Architecture_View_Model

Zachman çerçevesini okuyun: http://en.wikipedia.org/wiki/Zachman_Framework

Planlamanız gereken bu.

a) projeyi bileşenlere ayırmalıyım,

Diğer benzer projeler için yaygın olarak benimsenen tasarım kalıplarını kullanın.

Şüphe duyduğunuzda, fikirler için J2EE planlarını okuyun.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

b) Etkileşimlerini nasıl planlamalıyım, örneğin sınıf diyagramları, yazma birimi testleri vb. yapmalıyım?

Evet. İyi fikirler, hepsi.


4

Yapılacak en önemli şey: spesifikasyonları gözden geçirin, daha rafine spesifikasyonlar elde etmek için müşteri ile etkileşime geçin

Gereksinimler şüphesiz eksik, belirsiz veya yanlış. En büyük zaman kaybı yanlış olanı yapmaktır. Müşteriler profesyonel yazılım mühendisleri değildir ve iyi bir gereksinim seti geliştirmede iyi olmaları beklenemez.

Bu nedenle, özellikleri gözden geçirmeli, müşteriyle röportaj yapmalı ve gerçekten ihtiyaç duyduğu ve istediği ve karşılayabileceği şey olup olmadığını öğrenmelisiniz.

Test / kullanım senaryoları geliştirin ve müşteri ile gözden geçirin. Bir gereksinim test edilemezse, atın.

Tasarımı geliştirin ve tüm parçaların teorik olarak ihtiyacınız olanı yapacağından emin olun.

Her katmanda kullanılacak tüm teknolojileri test eden ancak işlevselliği göz ardı eden bir mimari prototip geliştirin. Fonksiyonel özellikleri değil mimariyi test ediyorsunuz. Yanlış mimariye sahip olmak, her şeyi yeniden yazmanız gerektiği anlamına gelir, bu nedenle doğru mimariyi elde etmek önemlidir. Hız, verimlilik, güvenlik vb.İçin ihtiyaçlarınızı karşılayabildiğinden emin olun.


3

Kodlamaya başlamadan önce kesinlikle bir tasarıma sahip olmak istiyorsunuz.

Bunu yaptıktan sonra, uygulama katmanlarınızın birbirine nasıl uyacağını tanımlamak için genellikle ilk olarak bir mimari aşama yapmayı tercih ederim. Bu güvenlik ve günlüğe kaydetme gibi omurga malzemelerini de içerir.

Sonra bir şeyi tamamen uygulamanız için yukarıdan aşağıya 1 özellik oluşturuyorum.

Sonra oradan gidin.


0

her şey

Her şeyi planlayın, kağıt üzerinde değiştirmenin bir kısmı zaten kodlanmış olandan daha kolaydır, dokümantasyon ve diğer birçok avantaj için mükemmel bir temel elde edersiniz.


4
-1 Cevabın yararlı olduğunu düşünmüyorum ve çoğu durumda 'her şey' kesinlikle gitmenin yolu değil.
KeesDijk
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.