वेब अनुप्रयोग (डिज़ाइन सॉफ़्टवेयर, ग्राफिक्स नहीं) को डिजाइन करने का सही दृष्टिकोण

Question

हाल ही में मुझे संभावित ग्राहकों से बहुत ही जटिल वेब अनुप्रयोगों के लिए अनुरोध प्राप्त हुए।
वे चाहते थे कि मैं "असली" काम शुरू होने से पहले एक स्पेक लिखूं।
spec, जैसा कि वे देखते हैं, यह केवल ऐप और डीबी का वर्णन करने वाले शब्द होना चाहिए।
जहां मुझे सबसे अच्छा तरीका मिला है, स्क्रीन के प्रोटोटाइप को "पेंट" या "बिल्ड" करना है (एचटीएमएल एक किताब लिखना आसान है, खासकर अगर आप इस चरण के लिए WYSIWYG का उपयोग करते हैं ... मानकों को नहीं है इस बिंदु पर महत्वपूर्ण)।

आप अपनी आंखों के सामने एक स्क्रीन है, तो यह तुरंत स्पष्ट क्या तत्वों चाहिए (कैलेंडर/फोटो दीर्घाओं/क्या प्रमुख लिंक, खोज बॉक्स आदि)

तो, मैं अपने दृष्टिकोण में गलत हूँ हो जाता है? या क्या ग्राहक चीजों को करने के सही तरीके से खराब जानकारी देते हैं?

Answer 1

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

अक्सर, आपको वास्तविक उत्पाद को ग्राहक के हाथों में प्राप्त करने की आवश्यकता होती है ताकि काम पर अनिवार्य प्रतिक्रिया प्राप्त हो और क्या नहीं। आप बाद में ऐसा करने से पहले बेहतर कर रहे हैं क्योंकि विकास में देर से होने वाले बदलाव कम से कम पारंपरिक तरीकों से अधिक कठिन और महंगे होते हैं। एक अजीब विधि का उपयोग करना जो कामकाजी सॉफ़्टवेयर को जल्दी और अक्सर प्रदान करता है, केवल पर्याप्त नियोजन और दस्तावेज़ीकरण के साथ-साथ उस उत्पाद के विनिर्देशों के पुनर्मूल्यांकन की तुलना में बेहतर ग्राहक प्रतिक्रिया प्राप्त करता है जिसे ग्राहक ढूंढ सकता है कि वे नहीं चाहते हैं (या कम से कम वे चाहते हैं जिस तरह से उन्होंने कहा)।

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

Answer 2

प्रत्येक व्यक्ति के पास सॉफ्टवेयर विकास के लिए एक अलग दृष्टिकोण है। आपकी विधि आपके क्लाइंट के जितना व्यवहार्य है। हालांकि, चूंकि आपका ग्राहक आपको भुगतान कर रहा है, मेरा सुझाव है कि आप उनके मानकों के अनुरूप हों या अपनी विधि का सुझाव दें और देखें कि वे कैसे प्रतिक्रिया करते हैं।

Answer 3

spec परियोजना का सबसे महत्वपूर्ण हिस्सा (सबसे लंबा करने वाला) है। यह आपको (और आपके क्लाइंट) को बताता है कि आप क्या बना रहे हैं और वे के लिए आपको क्या दे रहे हैं।

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

नीचे की रेखा है, आप और ग्राहक दोनों को यह जानने की जरूरत है कि काम शुरू होने से पहले क्या उम्मीद करनी है। आपकी स्क्रीन और नकली-अप व्यापक विनिर्देश का हिस्सा होना चाहिए

आपका दृष्टिकोण एक बड़े एप्लिकेशन के लिए थोड़ा टूटा हुआ लगता है। उनकी उम्मीदें मेरे लिए सही लगती हैं।

Answer 4

मैं Balsamiq में स्क्रीन मैक अप का उपयोग करता हूं। यह सामान्य रूप और उपयोगकर्ता अनुभव को दर्शाता है, डिजाइन के सौंदर्यशास्त्र के साथ ट्रैक की ओर हो रही बिना

Answer 5

आप अपने संचार में उपयोगी निम्नलिखित लेख मिल सकता है:

• The Iceberg Secret, Revealed
• Painless Functional Specifications - Part 2: What's a Spec?
• Painless Functional Specifications - Part 3: But... How?

याद रखें कि आप अभी भी अपने लिए HTML बना सकते हैं यदि यह आपको इसके बारे में सोचने में मदद करता है बाकी। काफी हद तक, HTML डिज़ाइन तब आपका निर्णय होगा।

व्यक्तिगत रूप से, मैं विनिर्देशों के लिए FIT और Fitnesse का प्रशंसक हूं। वे इसे अद्यतित रखने में दोनों आसान बनाते हैं, और यह सत्यापित करने के लिए कुछ परीक्षण शामिल करते हैं कि कोड विनिर्देशों को पूरा करता है।

याद रखने की दूसरी बात यह है कि एक नियम के रूप में ग्राहक पूरी तरह से नहीं जानता कि वे क्या चाहते हैं, इसलिए एक पूर्ण कल्पना के साथ भी इसे पूरी तरह से तय नहीं किया जाता है।

Answer 6

उपयोगकर्ता इंटरफ़ेस ऐप का सबसे महत्वपूर्ण हिस्सा नहीं है, इस भाग पर ध्यान केंद्रित करने से बहुत जल्दी झूठी धारणाएं हो सकती हैं और कार्यक्षमता पर नहीं, इंटरफ़ेस के आधार पर विकल्प लगा सकते हैं।

मैं पहले कार्यक्षमता पर ध्यान केंद्रित करने का सुझाव देता हूं, यह स्वीकार करने के लिए कि ऐप को क्या करने की उम्मीद है, यह स्क्रीन पर कैसा दिखाई देगा। इंटरफ़ेस समय में बदल जाएगा, क्लाइंट बाएं को दाएं, रंगीन नीले, पीले रंग के नहीं, यह टेक्स्ट बॉक्स बड़ा और एक अलग फ़ॉन्ट चाहेगा, ये बाद में विवरण हैं, यदि आप चश्मे के साथ इंटरफ़ेस प्रदान करते हैं आप महत्वपूर्ण कार्यक्षमताओं के बजाय उन मामूली विवरणों पर चर्चा करने का जोखिम उठाते हैं।

Applying UML and Patterns पर एक नज़र डालें, मुझे लगता है कि यह उपयोगी हो सकता है। "चरम प्रोग्रामिंग" श्रृंखला की किताबों में से एक भी अच्छा था, मैं बाद में जांच करूँगा कि कौन सा बिल्कुल।

Answer 7

आप निम्नलिखित प्रश्न के जवाब पर एक नज़र लेने के लिए हालांकि सवाल मध्यम आकार के लिए है चाहते हो सकता है, यह अभी भी नहीं बल्कि जटिल हो सकता है:

What are the basic questions to ask a person who wants his Medium sized website done?

आप ग्राहक से पूछा है क्यों चित्र या प्रोटोटाइप स्क्रीन शॉट्स निराश हो रहे हैं? उनके पास इसके लिए स्वयं के कारण हो सकते हैं, जैसे कि "वास्तविक" कार्य शुरू होने से पहले किए गए कार्यों की मात्रा को सीमित करने का प्रयास करना। एक विचार के रूप में, यह इतना बुरा नहीं माना जाता है कि वे पहले दूसरों के साथ एक spec बनाने के माध्यम से चला गया है और उस प्रक्रिया के साथ सहज हैं। यदि यह उनके लिए नया है, तो यह चर्चा करने योग्य हो सकता है कि आप उन प्रोटोटाइप क्यों चाहते हैं, उदा। कभी-कभी शब्द व्याख्या के लिए खुले होते हैं और यह चित्र आसानी से दिखाए गए हजारों शब्दों की तुलना में एक तस्वीर के साथ आसानी से हल किया जाता है।

Answer 8

सबसे पहले, आपके पास शब्दावली गलत है। आपके प्रश्न के शीर्षक में आप पूछते हैं "डिज़ाइन एक वेब अनुप्रयोग का सही दृष्टिकोण" - लेकिन ध्यान दें: आपके क्लाइंट ने आपको विनिर्देश एप्लिकेशन के लिए लिखने के लिए कहा था।

विशिष्टता डिजाइन के बराबर नहीं है। कोशिश करना और उन्हें समान बनाना खतरनाक है।

जैसा कि एक और प्रतिलिपि ने कहा, एक कल्पना यह है कि आप और आपके ग्राहक दोनों जानते हैं कि आप बना रहे हैं। डिजाइन की कला है जो इसे बनाने के लिए है।

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

मेरा सुझाव है कि आप विकिपीडिया पर this article पर एक विनिर्देश के बारे में अधिक जानकारी के लिए देखें।

संपादित करें: जबकि मैं क्या कहा है तकनीकी रूप से सही है, के रूप में tvanfosson बताते हैं, यह मुश्किल पूरी तरह से विकास की शुरुआत से पहले एक प्रणाली बाहर विशिष्ट जानकारी के अनुसार है। मैं आपको his answer के माध्यम से पढ़ने की सलाह देता हूं और अपने ग्राहकों से अधिक यथार्थवादी दृष्टिकोण को अपनाने के बारे में बात करता हूं।