वेब एप्लिकेशन के लिए क्लाइंट को देने के लिए डिलिवरेबल्स क्या हैं? [बन्द है]


11

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

तो मैं सोच रहा हूँ ... क्या अनिवार्य तकनीकी और गैर तकनीकी डॉक्स हैं जो मैं अपने क्लाइंट को कोड और आर्किटेक्चर के दस्तावेज़ों के अलावा दे सकता हूं?

(यह परियोजना के बारे में विभिन्न आँकड़ों और डेटा के बारे में ग्राहक को हिट करने के लिए थोड़े शांत होगा ताकि वह वास्तव में शामिल काम की मात्रा और उत्पाद वास्तव में कितना शांत हो।)


8
ग्राहक को किन अनिवार्य वस्तुओं को पूरी तरह से अनुबंध और आपके देश के कानून पर निर्भर करता है।
फाल्कन

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

क्लाइंट को कौन सा चाहिए ? क्या आप एक ग्राहक के तकनीकी प्रबंधक से प्रतिक्रिया प्राप्त कर सकते हैं? इसके अलावा: आपके उत्पाद "शांत" किस अर्थ में हैं? क्या आप स्पष्ट कर सकते हैं?
ZJR

जवाबों:


9

मुझे लगता है कि सूची में शामिल होना चाहिए:

  • गैर-तकनीकी आवश्यकताएं (इस तरह का एक दस्तावेज था, है ना?)
  • तकनीकी आवश्यकताओं
  • एक "निर्णय" दस्तावेज़ (अगर वहाँ एक था) यह समझाते हुए कि कुछ निर्णय दूसरों पर क्यों किए गए थे। यह पहले से ही एक अलग आवश्यकताओं या वास्तुकला दस्तावेज़ में हो सकता है, लेकिन हम आम तौर पर बड़े निर्णयों के लिए अलग से ऐसा करते हैं।
  • कोड और अन्य संसाधन (छवि फ़ाइलें, CSS, आदि ...)
  • डेटाबेस मॉडल (आरेख, दस्तावेज़ के रूप में, जो भी हो)
  • डेटाबेस बनाने के लिए डीडीएल।
  • डेटाबेस को सीड करने के लिए डी.एम.एल.
  • एप्लिकेशन सेटअप और बुनियादी मुसीबत शूटिंग की व्याख्या करने वाला एक दस्तावेज़।
  • किसी भी महत्वपूर्ण उपयोगकर्ता नाम और उनके पासवर्ड की सूची (व्यवस्थापक खातों के लिए), साथ ही साथ पासवर्ड बदलने के निर्देश भी। आदर्श रूप से, जब वे पहली बार वेबसाइट की स्थापना करते हैं, तो उन्हें एक नया व्यवस्थापक पासवर्ड दर्ज करने के लिए कहा जाना चाहिए, लेकिन यह एक वास्तुकला की बात है।
  • सिस्टम आवश्यकताएँ, और वेब ऐप्स के लिए, न्यूनतम होस्टिंग आवश्यकताएं भी (क्या ऐप को MySQL या PostgreSQL की आवश्यकता है? कितनी रैम? आदि ...)

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


"किसी भी महत्वपूर्ण उपयोगकर्ता नाम और उनके पासवर्ड की सूची (व्यवस्थापक खातों के लिए)" : वास्तव में? वेबसाइट जारी होने के बाद डेवलपर को कभी भी पासवर्ड नहीं पता होना चाहिए , विशेष रूप से प्रशासकों को। यदि आप ग्राहक को विकास के दौरान आपके द्वारा उपयोग किए गए पासवर्डों की सूची देते हैं, तो आप यह सुनिश्चित कर सकते हैं कि ग्राहक उन्हें कभी नहीं बदलेगा।
आर्सेनी मूरज़ेंको

4
@ मेनमा: मेरा मानना ​​है कि क्लाइंट के पास पासवर्ड बदलने की क्षमता है, और यह कि पहले निर्देशों में से एक है "अपने पासवर्ड बदलें!"
FrustratedWithFormsDesigner

क्या आप नौसिखिए के लिए स्पष्ट कर सकते हैं कि "गैर-तकनीकी आवश्यकताएं" क्या हैं?
अबे

1
@ आबे: गैर-तकनीकी आवश्यकताएं कुछ इस तरह कहेंगी जैसे "यह एप्लिकेशन को उपयोगकर्ता को अपने खातों का प्रबंधन करने देना चाहिए" और तकनीकी व्यक्ति कह सकता है "SOAP- आधारित वेब सेवाएं एक इंटरफ़ेस को उजागर करेंगी जो क्लाइंट एप्लिकेशन को उपयोगकर्ता खातों का प्रबंधन करने की अनुमति देता है। "।
FrustratedWithFormsDesigner

4

FrustratedWithFormsDesigner के वास्तव में अच्छे उत्तर के अलावा मैं कहना चाहूंगा कि गैर तकनीकी दस्तावेजों में क्या शामिल है (जैसा कि हमने किया):

  • विश्लेषण डेटा: जब आपने पहली बार आवश्यकताओं के बारे में बात की थी तो ग्राहक ने आपको क्या बताया था?
  • आपके द्वारा दिया गया प्रस्ताव:

    • उत्पाद की आवश्यकता दस्तावेज़
    • और कार्यात्मक विनिर्देश दस्तावेज़

    जो एक साथ अनुबंध के एक प्रकार के रूप में कार्य करते हैं कि आपको क्या करना चाहिए और आप
    ग्राहक से विकास के दौरान अनुमानित समय और लागत के रूप में क्या वितरित करने की अपेक्षा करते हैं।

  • समीक्षा प्रोटोकॉल, usecases और testplans, testresults सहित विनिर्देश

  • यूएमएल और सभी संबंधित दस्तावेजों में डिजाइन

  • सोर्सकोड के दस्तावेज (डॉक्सीजन या जो भी हो)

  • मैनुअल और स्थापना दिशानिर्देश

  • परियोजना के लिए उपयोग किए जाने वाले अंतिम वास्तविक संसाधन (समय और धन), इसलिए आप एक चालान लिख सकते हैं

  • कुछ ग्राहक मीटिंग प्रोटोकॉल चाहते हैं, वह भी ऊपर वर्णित "निर्णय दस्तावेज़" का विस्तार है

आशा है कि आप क्या देख रहे थे।


3

निम्नलिखित में से जो भी आपके प्रोजेक्ट के लिए लागू हो, उसका पालन करें। आपके पास पहले से ही कुछ हो सकता है।

तकनीकी दस्तावेज:

  • PHP और विवरण के बारे में विवरण कि यह परियोजना के लिए कैसे उपयोगी है
  • बैक एंड के बारे में विवरण और परियोजना के लिए यह कैसे उपयोगी है, इसके बारे में जानकारी दी गई है
  • डेटा के प्रवाह को दर्शाती उपयुक्त तस्वीरों के साथ डेटाबेस कनेक्टिविटी पर जानकारी
  • प्रोजेक्ट में शामिल अन्य प्रोग्रामिंग भाषाओं या अनुप्रयोगों के बारे में जानकारी जैसे XML, HTML आदि।
  • मदद फ़ाइल

स्क्रीनशॉट के साथ दस्तावेज तैयार करें और निम्नलिखित के लिए प्रासंगिक कोड (यदि आवश्यक हो) को उजागर करें:

  • ऑब्जेक्ट या नियंत्रण, ऑब्जेक्ट गुण आदि जैसे फ्रंट एंड एप्लिकेशन पर जानकारी
  • डेटाबेस प्रश्नों पर जानकारी (यदि पहले से मौजूद नहीं है)
  • डेटाबेस गुण जैसे प्राथमिक कुंजी, विदेशी कुंजी आदि पर जानकारी और वे डेटा स्थिरता और सटीकता कैसे सुनिश्चित करते हैं।
  • एक तार्किक क्रम में इसी तरह के डेटा या स्क्रीन की पुनरावृत्ति के बिना, नमूना डेटा के साथ इसे चलाने के बाद बैक एंड के साथ-साथ बैक एंड का उपयोग करके स्क्रीन के सभी संभव प्रकार के स्क्रीनशॉट का उपयोग करके परियोजना भर में विस्तृत गाइड।
  • अमान्य डेटा इनपुट करें और दिखाएं कि ऐसा करना असंभव है क्योंकि आपने फ्रंट एंड बैक एंड पर डेटा सत्यापन किया है।
    /* This step is not applicable if you have not used any object for getting direct input from the user like Text Field as it is obvious that you cannot get invalid data through indirect input. */

  • दिखाएँ कि प्रासंगिक कोड की व्याख्या करके सर्वर या क्लाइंट सिस्टम में अचानक विफलता होने पर प्रोग्राम में कोई त्रुटि या डेटा में असंगति नहीं है।

  • सामने के अंत के माध्यम से नमूना डेटा देने के बाद, आप सर्वर से डेटा की प्रत्यक्ष पुनर्प्राप्ति के लिए बैक एंड में नमूना प्रश्नों को शामिल कर सकते हैं और नमूना डीएमएल प्रश्नों को भी शामिल कर सकते हैं जो आपके डेटा के महत्वपूर्ण आंकड़ों को तैयार करने में मदद कर सकते हैं।

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

  • अंत में कोड की कुल संख्या, परियोजना की ओर बिताए गए दिनों की कुल संख्या, आपने कितनी बार परियोजना की जाँच की है, उपयोग किए गए सभी आवेदनों की सूची और अन्य तकनीकी और गैर-तकनीकी जानकारी जैसे आँकड़ों के साथ निष्कर्ष निकालना।


    गैर-तकनीकी दस्तावेज:

  • लागू होने पर परियोजना का लाइसेंस विवरण।
  • यदि लागू हो तो परियोजना के व्यावसायिक पहलू।

2

सावधान रहने की जरूरत

संभावित दस्तावेज जो आप क्लाइंट को दे सकते हैं, वह वस्तुतः अंतहीन है। आपके पास पहले से मौजूद डॉक्यूमेंट जनरेट करने के लिए अतिरिक्त समय की आवश्यकता नहीं है।

ग्राहक इस प्रलेखन (स्रोत कोड के ऊपर और ऊपर) को क्यों चाहता है? इसके साथ क्या किया जाएगा? यह किसके लिए है?

इन सवालों के जवाब देने के दायरे को कम करने में मदद करेंगे।

यह महत्वपूर्ण है कि आप और ग्राहक वास्तव में क्या दस्तावेज देने के लिए सहमत हैं, और क्या किसी भी अतिरिक्त प्रयास की भरपाई की जाएगी।

अनुमान लगाने का खेल मत खेलो। अधिकांश तकनीकी दस्तावेज विशिष्ट (गैर-तकनीकी) ग्राहक के लिए बेकार होंगे।


1

मैं शायद इसे कुछ दस्तावेज़ श्रेणियों में तोड़ दूंगा:

गाइड:

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

सहयोग:

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

एकीकरण अंक:

  • क्या इस एप्लिकेशन के लिए 3 पार्टी एकीकरण बिंदु हैं जो इसे आपके कोड के अलावा अन्य विक्रेताओं पर निर्भर करते हैं?
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.