वेब अनुप्रयोग विकास के लिए डिज़ाइन/योजना कैसे बनाएं?

Question

मुझे एक डेवलपर टीम परिदृश्य में, वेब अनुप्रयोग विकास के लिए डिज़ाइन/योजना बनाने के तरीके सीखने में रूचि है।

"परियोजना प्रबंधक/लीड" की भूमिका मान लिया जाये:

1. क्या "दस्तावेज़" सफल वेब अनुप्रयोग विकास के लिए आवश्यक हैं?
2. क्या यूएमएल आरेखों की आवश्यकता है और किस डिग्री के लिए?
3. डिजाइन/योजना चरण में प्रत्येक - प्रत्येक मामले के अनुसार - कक्षा को चित्रित करने की आवश्यकता है?
4. कक्षा आरेखों को कितना विस्तृत (गहराई और चौड़ाई) होना चाहिए?

आप किसी भी उपयोगी पुस्तक/वेबसाइट सिफारिशों है, तो साझा करें।

---

का पालन-अप (जोड़ा 11/18/09): क्या कोडर/डेवलपर्स वर्गों में से अर्थात निर्माण कोडिंग के दौरान एक गाइड के रूप में प्रयोग करते हैं, और उनके संबंधित तरीकों & गुण?

यदि उनके तरीकों और गुणों के साथ कक्षाओं की पूरी (अभी तक परिवर्तनीय) सूची नहीं है, तो क्या अस्पष्टता प्रत्येक कोडर के ज्ञान/अनुभव पर भारी निर्भरता नहीं देती है, जिसके परिणामस्वरूप कोड गुणवत्ता/उपयोगिता/रखरखाव में विचलन होता है ?

Answer 1

1. सभी मामलों में आपके पास सटीक आवश्यकताओं का एक व्यापक और अद्यतित रिकॉर्ड होना चाहिए। इसमें functional और nonfunctional दोनों आवश्यकताएं शामिल हैं। यह एक शब्द दस्तावेज़, एक स्प्रेडशीट, या एक विशेष आवश्यकताओं प्रणाली हो सकता है। आपको बस कुछ ऐसी चीज चाहिए जो आपको सभी आवश्यकताओं का ट्रैक रखने और समय के साथ बदलने की अनुमति देती है। Agile आवश्यकता दस्तावेज़ों के बारे में Here's a good source of info and discussion।
2. मेरे अनुभव में, केस आरेखों का उपयोग महत्वपूर्ण साबित हुआ है, घटक और तैनाती आरेख भी उपयोगी हैं। कक्षा और अनुक्रम आरेख भी उपयोगी हो सकते हैं, लेकिन ज्यादातर मामलों में मुझे लगता है कि उन लोगों को अपरिवर्तनीय विकास आवश्यकताओं की तुलना में बुनियादी उत्परिवर्तनीय दिशानिर्देशों के रूप में अधिक उपयोग किया जाना चाहिए। कक्षाएं और विधियां आमतौर पर परिवर्तन के अधीन होती हैं (विशेष रूप से यदि आप टीडीडी का उपयोग कर रहे हैं), और यदि आप वास्तव में एक आरेख चाहते हैं तो कोड विकसित होने के बाद इसे अपडेट करना सबसे अच्छा है, बल्कि आपके कोड को चित्रों को फिट करने के लिए shoehorning।
3. मुझे नहीं लगता कि प्रत्येक वर्ग को आरेखण की आवश्यकता है। मुझे लगता है कि मॉडल क्लास आरेखों का पता लगाने के लिए उपयोगी हो सकता है कि डेटा कहां स्थित है, और कभी-कभी कुछ नियंत्रक और कक्षा आरेखों को भी उपयोगी होते हैं। लेकिन मेरे अधिकांश अनुभवों में, आवश्यकताओं और परीक्षण के मामले दिशाओं का मुख्य स्रोत हैं कि कक्षाओं को कैसे डिजाइन किया गया है, और सिस्टम को बढ़ने और बदलने के रूप में उन्हें दोबारा प्रतिक्रिया दी जाती है।
4. मॉडल कक्षाओं में, मुझे नहीं लगता कि विशेषताओं से अधिक कुछ आवश्यक है। यदि आप नियंत्रक वर्ग मॉडलिंग कर रहे हैं, तो आमतौर पर दोनों प्रमुख विशेषताओं और विधियों को शामिल करना बुद्धिमान होता है।

Answer 2

प्रकार और वेब अनुप्रयोग के आकार पर निर्भर करता है। यदि आप एक शॉपिंग कार्ट के साथ एक छोटी ई-कॉमर्स वेबसाइट कर रहे हैं तो आप शायद चीजों के डिजाइन पक्ष पर और "ऐप" कार्यक्षमता पर कम प्रयास करेंगे। इसके विपरीत, यदि आप कई डेटा इनपुट स्क्रीन के साथ एक बड़ी आंतरिक वेबसाइट बना रहे हैं तो आपका अधिकांश समय व्यवसाय तर्क और डेटा नियमों पर खर्च किया जाएगा।

व्यक्तिगत रूप से, मैं कठोर कल्पना स्वरूपों या प्रक्रियाओं में विश्वास नहीं कर रहा हूँ।मैं स्पष्ट रूप से संवाद करने के लिए परियोजना और ग्राहक के अनुरूप अनुकूलित करने के लिए अनुकूलित करूंगा।

आवश्यकताओं मान लिया जाये कि पहले से ही लिखित हैं, दस्तावेजों के दो प्रकार मैं हमेशा कार्यप्रवाह आधारित डेटा गहन वेब ऐप्लिकेशन के लिए एक न्यूनतम के रूप में निर्माण करने के लिए की तलाश कर रहे हैं:

1. उच्च स्तर कार्यप्रवाह स्क्रीन प्रवाह का संकेत आरेख, स्थिति परिवर्तन, और प्रमुख कार्यवाही। मुझे एप्लिकेशन के भीतर प्रमुख आंदोलनों को दूर करने में पहला कदम के रूप में यह बहुत उपयोगी लगता है। वर्कफ़्लो आमतौर पर विभिन्न उपयोग मामलों से संबंधित होते हैं।

2. प्रत्येक इनपुट स्क्रीन के लिए स्क्रीन चश्मा प्रत्येक फ़ील्ड के प्रारूप और व्यवहार का विवरण देते हैं। आमतौर पर फ़ील्ड प्रकार, डिफ़ॉल्ट मान, सूची मूल्य, डेटा सत्यापन, दृश्यता नियम, और क्रियाएं जो ट्रिगर किए जा सकते हैं, आदि शामिल हैं। असल में एक बड़ी तालिका यह सुनिश्चित करती है कि डेवलपर्स स्क्रीन को कैसे बनाएं।

मैं भी हाल ही में इस परियोजना में Balsamiq Mockups का उपयोग किया है वेब ऐप्लिकेशन स्क्रीन और स्क्रीन मॉक-अप एक साथ कोड़ा को परियोजना चश्मा का एक महत्वपूर्ण हिस्सा गठन किया है - बहुत निर्माण करने के लिए त्वरित, और वे के बारे में जानकारी का एक बहुत व्यक्त स्क्रीन को कैसे काम करना चाहिए जो टेक्स्ट दस्तावेज़ में व्यक्त करना मुश्किल है।

आखिरकार, जोएल का series on functional specs उपयोगी पढ़ना उपयोगी है।

Answer 3

सभी उपयोग मामले अच्छी तरह से विस्तृत होना चाहिए, ग्राहक से सहयोग जारी रखा हमेशा एक से अधिक हो जाएगा, अभी भी यह अप्रत्याशित मामलों अंकुर सकता है।

यदि विभिन्न सर्वरों के बीच बातचीत विकसित करना अलग-अलग समय पर मतदान/पुश करेगा, तो आपको निश्चित रूप से Sequence Diagrams की आवश्यकता होगी।

से बचें यह overdesigning, वर्ग चित्र अनावश्यक कक्षाएं मशरूम के लिए करते हैं, में उन्हें काट नीचे है, और अधिक तरीकों का उपयोग, क्या पर्यावरण प्रत्येक वर्ग वास्तव में (कुछ सर्वर साइड चलेगा, कुछ ग्राहक के पक्ष चल रहा है खत्म हो जाएगा का ट्रैक रखने - जावास्क्रिप्ट - कुछ को नौकरियों को निर्धारित किया जाएगा और वास्तविक सर्वर पर चलाया जाएगा, कुछ वेल्जर (या मॉड्यूल) को वेबसर्वर द्वारा encapsuled और मांग पर चलाएंगे, कुछ डेटाबेस के साथ इंटरफेस करेंगे।

सीमाओं को परिभाषित करें, उन्हें स्पष्ट करें। सर्वर साइड/क्लाइंट साइड/डेटाबेस काम अलग-अलग जानवर हैं और अलग-अलग समय और लोग ले सकते हैं।

Answer 4

इसे जितना आसान हो ble।

कोर सुविधा आवश्यकताओं को निर्दिष्ट करने वाला एक दस्तावेज़ पहला कदम है।

व्यक्तिगत रूप से बोलते हुए, क्योंकि वेब ऐप्स लगभग हमेशा डेटाबेस-आधारित होते हैं, मैं कार्यक्षमता आवश्यकताओं के आधार पर डेटाबेस मॉडलिंग शुरू करता हूं। ईआरएम आरेख मानचित्र में इकाइयां आम तौर पर यूएमएल आरेख में कक्षाओं के साथ 1-1 होती हैं, और पहले ही मूल संबंध दिखाती हैं।

एक एमवीसी आर्किटेक्चर और अच्छी तरह से प्रलेखित कोड मानते हुए, मॉडल कक्षाएं स्वयं दस्तावेज़ (जैसे ऑक्सीजन phpdocumenter) विकसित हो जाएंगी।

मुझे कुछ आसान लगता है जैसे विकी औपचारिक दस्तावेजों के बजाय दस्तावेज़ लिखने के लिए सबसे अच्छा काम करता है जो विशेष रूप से एक चुस्त वातावरण में संबंधित कोड से लिखने में अधिक समय ले सकता है।

Answer 5

1. आवश्यकताएँ दस्तावेजों का एक सेट है, जिसमें ग्राफिक्स, वर्ड दस्तावेज़, ई-मेल संदेश और चीजों को रिकॉर्ड करने के अन्य तरीकों को शामिल किया जा सकता है। विकास पर्यावरण में क्या है (आईडीई, स्रोत नियंत्रण, बग ट्रैकिंग), कोडिंग शैली और दिशानिर्देशों की एक सूची दस्तावेजों का एक और सेट है जो एक सफल अनुप्रयोग विकास टीम में उपयोगी हो सकती है। एक परियोजना योजना है जो एक बड़ा गैंट चार्ट है और रिलीज नोट्स है जो हमारे द्वारा बनाए गए कुछ और दस्तावेज़ हैं।
2. मैंने कुछ डिज़ाइन पैटर्न समझाए जाने के लिए गैंग ऑफ़ चार की साइट के अलावा कई यूएमएल आरेखों को नहीं देखा है।
3. हमारे पास आइटमों का बैकलॉग पूरा करने और अनुमान लगाने के लिए है कि प्रत्येक कहानी कितनी जटिल है। यह आपके द्वारा उपयोग किए जा रहे दृष्टिकोण से अलग हो सकता है। हमारे Agile दृष्टिकोण के साथ, आपकी स्थिति के रूप में उतना ही डिजाइन/योजना नहीं हो सकती है।
4. हमारे पास शायद ही कभी क्लास आरेख हैं, हालांकि विजुअल स्टूडियो में ऑब्जेक्ट ब्राउज़र है जो पहले से ही बनाया गया है यह देखने के लिए आसान है।

मैं कहाँ काम हम डोमेन वस्तुओं और उनके सदस्यों, तरीके और गुण पैदा करने के लिए जोड़े में काम करते हैं। कक्षाओं को कहानियों के लिए जरूरी बनाया गया है या यदि हम कक्षाओं के एक समूह की सफाई या पुनर्विक्रय कर रहे हैं।

वहाँ वर्गों की एक पूरी सूची नहीं है, लेकिन एमवीपी की तरह उपयोग में कुछ डिजाइन पैटर्न और विश्वास है कि एक जोड़ी कुछ पैदा कर रही है के बाद से, कोड वर्तमान शैली और दिशा निर्देशों के भीतर फिट होगा रहे हैं। चूंकि आवश्यकताएं विकसित होती हैं, कक्षाओं में नियमित रूप से परिवर्तन होंगे लेकिन यह मेरे लिए चीजों को करने का एक प्राकृतिक तरीका है। वातावरण जहां मैं सिर्फ मामले किसी में हूँ पर

पृष्ठभूमि जानना चाहता है:

मैं कहाँ काम हम 5 डेवलपर्स, एक क्यूए सीसा, एक व्यापार विश्लेषक, एक टीम का नेतृत्व, एक वास्तुकार और एक परियोजना प्रबंधक के रूप में है इस समय परियोजना में मुख्य लोग। हम स्क्रम, जोड़ी प्रोग्रामिंग और हमारे काम में कुछ टीडीडी विचारों का उपयोग करते हैं।

हम विजुअल स्टूडियो 2008, सबवर्सन, हिमाचल प्रदेश गुणवत्ता केंद्र, ASP.Net 3.5, Sitecore 6.0, और MS-एसक्यूएल सर्वर का उपयोग कर रहे 2005