गुणवत्ता की निगरानी - डिजाइन अनुभव को बढ़ाना

साथियों, शुभ दोपहर!

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

सही दुनिया - झरना

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

ऐसा करने के लिए, आपको बस आवश्यकता है:

1. 5 साल के अनुभव और सफल परियोजनाओं के एक बड़े पोर्टफोलियो के साथ, PHP भाषा में विकास के लिए प्रमाणित एक प्रोग्रामर (ओं) को ढूंढें।
2. एक कोडर (एस) का पता लगाएं, जो नवीनतम संस्करणों के सभी लोकप्रिय ब्राउज़रों में HTML / CSS की पेचीदगियों को समझता है, पेशेवर मंचों पर सुबह से रात के खाने के लिए लटका (मैं लिखता हूं, और मेरी आँखों में आँसू दिखाई देते हैं :-))। लेकिन यह पर्याप्त नहीं है, क्योंकि टाइपसेट को जावास्क्रिप्ट के लिए प्रोग्राम करने में सक्षम होना चाहिए (और सभी लोकप्रिय ब्राउज़रों के लिए इस भाषा की बोलियों को जानना चाहिए), अर्थात। एक अनुभवी प्रोग्रामर बनने के लिए।
3. एक सिस्टम एडमिनिस्ट्रेटर (ओं) को खोजें, जो कम से कम एक ऑपरेटिंग सिस्टम में पारंगत हों और 10 साल या उससे अधिक के कार्य अनुभव के साथ हों।
4. एक परीक्षक का पता लगाएं जो इकाई परीक्षणों और कार्यात्मक परीक्षणों के साथ उत्पन्न वेब परियोजना कोड के 100% कवरेज के साथ एक प्रणाली को व्यवस्थित करने में सक्षम होगा। इस परीक्षक को किसी वेब प्रोजेक्ट के विषय क्षेत्र की पेचीदगियों को समझना होगा, ताकि क्लाइंट से बेहतर पता चल सके।
5. और, निश्चित रूप से, एक ग्राहक को खोजने के लिए जो a) पेचीदगियों में जानता है कि वह इस विषय क्षेत्र के किसी भी विश्लेषक से बेहतर चाहता है, b) वेब प्रोजेक्ट लॉन्च होने तक अपनी आवश्यकताओं को नहीं बदलता है।
6. एक बार जब टीम इकट्ठी हो जाती है, तो आप वेबसाइट को डिज़ाइन करना शुरू करते हैं, टाइप करते हैं, टाइप करते हैं और TOR में व्यवस्थापक पैनल और सार्वजनिक भाग दोनों में वर्णन करते हैं, जो उपयोगकर्ता के स्क्रीन रिज़ॉल्यूशन के आधार पर पिक्सेल और विभिन्न पेज विकल्पों के लिए सटीक होता है। नतीजा पृष्ठों का एक सचित्र टीके है, किसी तरह का 500, लगभग छह महीने में लिखा गया।
7. फिर आपको काम के बयान में प्रत्येक पृष्ठ का मूल्यांकन करने की आवश्यकता है, प्रत्येक दिन के लिए एक विस्तृत विकास योजना तैयार करें, वेब प्रोजेक्ट को ऑपरेशन में लगाने की तारीख निर्धारित करें।
8. बेशक, लॉन्च करने से पहले, टीओआर में पिक्सेल और पत्र के लिए सटीक, टीओआर और डिज़ाइन लेआउट के अनुपालन के लिए बनाई गई वेबसाइट के पूरी तरह से परीक्षण के लिए समय आवंटित किया जाता है। कई दृष्टिकोणों में लंबे समय तक परीक्षण करना आवश्यक है, लेकिन आप ग्राहकों के लिए त्रुटियों के साथ कार्यक्षमता को नहीं खोल सकते हैं - अधिक संभावना है कि मल्टीप्लेज़ परीक्षण में 2-3 महीने लगेंगे, यदि अधिक नहीं।

और फिर वेब परियोजना में सबसे अधिक संभावना है कि कोई त्रुटि नहीं होगी और सिस्टम को समय पर लॉन्च किया जाएगा! लेकिन साइट, सबसे अधिक संभावना है, अप्रचलित हो जाएगी, उपयोगकर्ताओं को अब इसकी आवश्यकता नहीं होगी, और क्लाइंट को वह नहीं मिलेगा जो वह चाहता है, लेकिन उसने काम के विवरण में क्या लिखा है :-)

दुर्भाग्य से, बहुत से लोग अब यह भूल जाते हैं कि एक वेब परियोजना एक सॉफ्टवेयर प्रणाली है जिसमें लागू गणित का एक कठोर "बुलियन" तर्क है और इसमें सौंदर्य की भावना नहीं है। किसी भी अन्य संरचना (पुल, घर, विमान) की तरह, इस इंजीनियरिंग संरचना को, एक अच्छे तरीके से, स्क्रू तक डिज़ाइन किया जाना चाहिए, स्क्रू तक का परीक्षण किया जाना चाहिए, और किसी भी बदलाव के लिए सभी डिज़ाइन प्रलेखन की समीक्षा की आवश्यकता होगी। और इसलिए, पूरी तरह से और वैज्ञानिक रूप से, पहले उन्होंने सॉफ्टवेयर सिस्टम किया - कैस्केड दृष्टिकोण (झरना) ।

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

स्काउटिंग - एक Iterative दृष्टिकोण

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

कई ग्राहकों के लिए इस तरह से काम करना अधिक सुविधाजनक है - आप परिणाम देखते हैं और योजना को समायोजित करते हैं। डेवलपर्स और परीक्षकों के लिए, यह, गंभीरता से परेशानी में जोड़ता है:

1. मैं परियोजना के सभी दस्तावेज, स्क्रीनशॉट, चित्र, टीके की तारीख तक नहीं रख सकता - क्योंकि थोड़े समय के बाद, परिवर्तन करने के लिए सबसे अधिक संभावना होगी। इसलिए, वे "चाल" में जाते हैं - वे सिस्टम के कम औपचारिक विवरण का नेतृत्व करते हैं, उदाहरण के लिए विकी में, घटकों के बीच निर्भरता को ट्रैक किए बिना, सहकर्मियों की स्मृति पर निर्भर होकर :-)
2. कार्यक्रम / लेआउट करना आवश्यक है ताकि अपेक्षित परिवर्तन करना एक सरल, थोड़ा जोखिम भरा प्रक्रिया हो। इसका मतलब है कि ए) आपको डिज़ाइन पैटर्न का उपयोग करने और सही तरीके से जानने की आवश्यकता है (और इस क्षेत्र को जानने वाले डेवलपर्स को खोजना आसान नहीं है), बी) आप प्रलोभन में नहीं दे सकते हैं और सभी जगहों पर एक सार्वभौमिक और विस्तार प्रणाली बना सकते हैं, क्योंकि यह विकास के समय में काफी वृद्धि करेगा
3. आपको समय-समय पर बदलती प्रणाली का परीक्षण करने में सक्षम होना चाहिए। जानें कि कहां और क्या बदल गया है, यह कहां प्रकट होगा। यानी परीक्षकों पर भार बढ़ता है - आपको परिवर्तनों का वर्णन करने की आवश्यकता है, इकाई और एकीकरण परीक्षणों आदि में परिवर्तन करना है।

हम देखते हैं कि पुनरावृत्त दृष्टिकोण में, एक ओर, यह क्लाइंट के लिए और अधिक सुविधाजनक हो गया और संभवतः, उसके साथ काम करने वाले परियोजना प्रबंधक, और दूसरी ओर, डेवलपर्स और गुणवत्ता विशेषज्ञों पर भार बढ़ गया, साथ ही साथ उनकी योग्यता के लिए आवश्यकताएं भी।



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

एरोबेटिक्स ... अराजकता की कगार पर - फुर्तीली लचीली प्रक्रिया

वर्तमान में, वेबसाइट विकास प्रक्रिया लोकप्रियता प्राप्त कर रही है। निम्नलिखित पोस्ट किया गया है:

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

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

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


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

ऐसी प्रणाली की गुणवत्ता का प्रबंधन करने के लिए (अक्सर औपचारिक तकनीकी दस्तावेज के बिना), प्रभावी तकनीकों का एक शस्त्रागार का उपयोग किया जाता है:

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

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

इस प्रक्रिया का स्वस्थ विकास आमतौर पर निम्नलिखित परिदृश्य के अनुसार होता है:

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

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

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

जाँचकर्ताओं के बारे में अधिक

हमने वेब परियोजनाओं को विकसित करने के तरीकों (और न केवल "वेब") के विकास को तेजी से दोहराया और देखा कि वर्तमान में कोई भी आमतौर पर सिस्टम के औपचारिक पद्धतिगत विकास के लिए पर्याप्त समय नहीं देता है (हालांकि, "झरना" और निर्भरता मैट्रिक्स का उपयोग जारी है। उद्योग जहां त्रुटि की लागत बहुत अधिक है - संयुक्त राज्य अमेरिका में स्वास्थ्य सेवा सॉफ्टवेयर के विकास में घरों, पुलों, हवाई जहाजों के निर्माण में), इसलिए टीमें अत्यधिक प्रभावी साधनों के सीमित सेट का उपयोग करके भय से बचती हैं, जिनमें से एक चेकलिस्ट।





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



प्रोग्रामर के लिए प्राथमिक चेकलिस्ट का एक उदाहरण:

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

प्रत्येक आइटम विकी में एक तकनीक का लिंक हो सकता है।

कुछ भी जटिल नहीं है, लेकिन इनमें से कितने बिंदुओं को अनदेखा किया जाता है।

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

क्वालिटी मॉनिटर - बिट्रिक्स प्लेटफॉर्म के 11 वें संस्करण में

बॉक्स प्लेटफ़ॉर्म 1C-Bitrix: साइट प्रबंधन पर एक वेब प्रोजेक्ट विकसित करते समय, आप उपरोक्त किसी भी प्रक्रिया का उपयोग कर सकते हैं। निम्नलिखित जोखिम कम हो गए हैं:

1. डेवलपर्स के पास "समर्पण का उच्चतम स्तर" होना जरूरी नहीं है : ZCE प्रमाणपत्र और OOP और डिजाइन पैटर्न को विस्तार से समझना। सभी सबसे कठिन मंच के मूल में है, इसे बिट्रिक्स कंपनी के अंदर विकसित और परीक्षण किया गया है। यह PHP प्रोग्रामर और लेआउट डिजाइनर के लिए बुनियादी कौशल, न्यूनतम अनुभव और प्रशिक्षण पाठ्यक्रम लेने के लिए पर्याप्त है (इसे कुछ दिनों में पूरा किया जा सकता है)।
2. सिस्टम के लिए दस्तावेज़ीकरण को अपडेट करने की आवश्यकता नहीं है, क्योंकि प्लेटफ़ॉर्म को ग्राहकों और डेवलपर्स दोनों के लिए आधिकारिक प्रलेखन में बहुत विस्तार से वर्णित किया गया है। केवल वेब परियोजना के एकीकरण के दौरान किए गए सुधार / कार्यात्मक परिवर्तनों का वर्णन करना आवश्यक है।
3. परीक्षकों को संपूर्ण वेब समाधान का परीक्षण करने की आवश्यकता नहीं है। मंच को आंतरिक रूप से अच्छी तरह से जांचा जाता है। केवल कार्यक्षमता में सुधार / बदलाव का परीक्षण करना आवश्यक है। यह समय और जोखिम को काफी कम करता है।

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

विकास टीमों को उपरोक्त जोखिमों से बचाने के लिए, संस्करण 11 से प्लेटफॉर्म में एक गुणवत्ता मॉनिटर बनाया गया है।

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



प्रत्येक परीक्षण कई राज्यों में हो सकता है, कुछ परीक्षण, विशेष रूप से नियमित वाले स्वचालित हैं:





परियोजना प्रबंधक या डेवलपर, वास्तव में, रिलीज / पुनरावृत्ति को पूरा करने के लिए परीक्षण पेड़ को "हरा" करना चाहिए - सभी परीक्षण और ऑटोटेस्ट प्रदर्शन करके:



जब रिलीज़ होती है, तो इसे डेस्कटॉप और परीक्षण रिपोर्ट की सूची पर देखा जा सकता है:



मैं विशेष रूप से "उन्नत" डेवलपर्स के लिए एक चेकलिस्ट को एकल करना चाहता हूं। ये आइटम विशेष रूप से एगले / एक्सपी टीमों में मांग में होंगे जो कोड की गुणवत्ता और वास्तुकला पर गंभीर ध्यान देते हैं:



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



कर्नेल और प्लेटफ़ॉर्म लाइब्रेरी को संशोधित करने के तथ्य को भी स्वचालित रूप से जांचा जाता है:

भविष्य के लिए विचार

रचनात्मक प्रक्रिया के रूप में विकास, मजेदार होना चाहिए। फिर वेब प्रोजेक्ट्स मृत और डरावने पैदा नहीं होंगे, और उन्हें समर्थन देना आसान और अधिक दिलचस्प होगा :-)

बिट्रिक्स प्लेटफॉर्म पर संपूर्ण विकास प्रक्रिया को कवर करने वाले चेकलिस्ट, आंतरिक टीम चेकलिस्ट द्वारा विस्तार योग्य - हमने किया। यह प्लेटफ़ॉर्म के ज्ञान और समझ की कमी और आम तौर पर "अच्छी प्रथाओं" से जुड़े जोखिमों को गंभीरता से कम करेगा और "गुणवत्ता मॉनीटर" में नई वस्तुओं को जोड़कर प्रक्रिया में सुधार करने की अनुमति देगा।

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

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

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