विषय
- सॉफ्टवेयर विकास जीवन चक्र पर एक संक्षिप्त
- क्यों फुर्तीली विकास अलग
- चंचल आचरण
- चंचल क्यों?
- नो बग्स, नो स्ट्रेस - योर स्टेप बाय स्टेप गाइड बाय स्टेप गाइड टू लाइफ-चेंजिंग सॉफ्टवेर विदाउट योर लाइफ
ले जाओ:
यह सॉफ़्टवेयर डेवलपमेंट विधि उच्च-गुणवत्ता वाले उत्पाद को वितरित करने में सहयोग और लचीलेपन को प्रोत्साहित करती है।
सॉफ्टवेयर इंजीनियरिंग और अनुप्रयोग विकास की दुनिया में एजाइल के आसपास बहुत चर्चा हुई है। चंचलता एक अवधारणा नहीं है, बल्कि एक मानसिकता है। जैसा कि नाम से पता चलता है, यह लचीला और गतिशील होने पर ध्यान केंद्रित करता है। यह कार्यप्रणाली सॉफ्टवेयर विकास के चरणों के बीच के अलगाव को भी दूर करती है, और विकास टीम को गुणवत्ता विश्लेषक (ओं) के साथ सहयोग करने के लिए प्रोत्साहित करती है। यह उच्च गुणवत्ता वाले उत्पाद को विकसित करने, बनाने और वितरित करने के लिए ग्राहकों की भागीदारी पर भी जोर देता है। यहाँ अच्छी तरह से चंचल पर एक नज़र डालें, यह कैसे काम करता है और इस लोकप्रिय सॉफ्टवेयर विकास पद्धति के लिए कुछ सर्वोत्तम अभ्यास।
सॉफ्टवेयर विकास जीवन चक्र पर एक संक्षिप्त
सॉफ्टवेयर डेवलपमेंट लाइफ साइकल (SDLC) एक विशेष समस्या को पूरा करने के लिए सॉफ़्टवेयर समाधान बनाने या मौजूदा संरचनाओं को संशोधित करने की प्रक्रिया है। इसमें विभिन्न चरणों को शामिल किया गया है, जिनका तार्किक क्रम में पालन किया जाता है। पारंपरिक SDLC मॉडल में, ये चरण एक के बाद एक होते हैं, और आमतौर पर अलगाव में किए जाते हैं:
- ग्राहकों से जरूरतें पूरी करना
- प्रणाली और व्यवहार्यता विश्लेषण
- डिजाइन और मॉडलिंग
- कोडिंग या कार्यान्वयन
- परिक्षण
- परिनियोजन और वितरण
- रखरखाव और परिवर्तन अनुरोध
एक विशिष्ट सॉफ्टवेयर डेवलपमेंट साइकल में, वास्तविक उपयोगकर्ता या क्लाइंट, आवश्यकताओं की प्रक्रिया में जुट जाते हैं और फिर बीटा परीक्षण के दौरान शामिल होते हैं। हालांकि, इस पारंपरिक मॉडल के साथ समस्या यह है कि चक्र का रखरखाव हिस्सा एक कठिन और महंगा मामला बन जाता है। कई बार, सिस्टम के भीतर एन्हांसमेंट या बदलाव की कोई गुंजाइश नहीं होती है। सबसे खराब स्थिति में, जो सॉफ्टवेयर इंजीनियर या विकसित किया गया है, वह वास्तविक ग्राहक विनिर्देशों और अपेक्षाओं के अनुरूप नहीं है, जिसका अर्थ है कि विकास टीम को फिर से पूरी प्रक्रिया शुरू करने की आवश्यकता हो सकती है।
क्यों फुर्तीली विकास अलग
एसडीएलसी के सबसे आम पारंपरिक मॉडल - झरना मॉडल, रैपिड एप्लिकेशन मॉडल, पुनरावृत्ति मॉडल, सर्पिल मॉडल, आदि - के पेशेवरों और विपक्षों का अपना सेट है। इससे पहले कि यह लोग वास्तव में विश्लेषण कर सकें कि ये मॉडल कितने यथार्थवादी थे। वे आदर्श परिदृश्यों में पूरी तरह से फिट होते हैं, लेकिन वास्तविक दुनिया के अनुप्रयोगों के लिए वे हमेशा व्यावहारिक थे। परिणामस्वरूप, सॉफ्टवेयर विकास टीमों को बहुत सारी चुनौतियों का सामना करना पड़ा। पारंपरिक SDLC मॉडल की कुछ सीमाओं में शामिल हैं:
- वे बाद के चरणों में आवश्यकताओं को बदलने की अनुमति नहीं देते हैं क्योंकि ये सॉफ़्टवेयर आवश्यकताओं विनिर्देश दस्तावेज़ में जमे हुए हैं। कुछ मामलों में, उपयोगकर्ताओं की उम्मीदें अस्थिर या गलत समझी जाती हैं।
- अंतिम उपयोगकर्ता सिस्टम को तब तक नहीं देखते जब तक कि यह पूरा न हो जाए। यह सुझाव और बदलाव करने की बहुत कम गुंजाइश प्रदान करता है।
- पारंपरिक एसडीएलसी डेवलपर्स और परीक्षकों के बीच एक विशाल संचार अंतराल बना सकते हैं, क्योंकि वे अलग-अलग चरण हैं, और दोनों पक्षों के बीच कोई सहयोग नहीं है।
- सफेद बॉक्स परीक्षण प्रभावी ढंग से नहीं किया जा सकता है।
एजाइल का उपयोग इन समस्याओं में से कई को हल करता है क्योंकि एक कदम-दर-चरण प्रक्रिया के बजाय, यह एक दर्शन और रूपरेखा के रूप में कार्य करता है जिसका उद्देश्य टीमों को सहयोग करने, प्रतिक्रिया करने और तैयार उत्पाद बनाने में मदद करना है जिसमें सभी से अधिक इनपुट शामिल हैं। उपयोगकर्ताओं सहित पार्टियां।
चंचल आचरण
एजाइल कार्यप्रणाली का उद्भव सॉफ्टवेयर विकास पद्धति में एक क्रांतिकारी सुधार से कम नहीं है, क्योंकि यह उत्पाद के प्रत्येक चरण के सामूहिक स्वामित्व को लेते हुए प्रोजेक्ट टीमों को रचनात्मक और बहुमुखी बनाने के लिए पर्याप्त जगह प्रदान करता है। फुर्तीली पथ का अनुसरण करके, सॉफ़्टवेयर डेवलपमेंट टीम में व्यक्तिगत प्रतिभागी अनिश्चितता को गले लगाने, परिवर्तनों का सामना करने और असतत अनासक्त चरणों के बजाय एक प्रक्रिया के रूप में एक बेहतर उत्पाद का निर्माण करने के लिए अपने मन की स्थिति करने में सक्षम हैं।
हालांकि एजाइल सिद्धांतों की कोई व्यापक सूची नहीं है, फिर भी कुछ प्रथाएं हैं जो एजाइल प्रचार करती हैं। इसमें शामिल है:
- टेस्ट ड्रिवेन डेवलपमेंट (TDD)
आदर्श रूप से, डेवलपर्स को पहले उन कार्यक्षमता के टुकड़े के लिए परीक्षण मामलों को लिखना चाहिए जिनके लिए वे कोड करने जा रहे हैं। यह अच्छी गुणवत्ता वाला कोड सुनिश्चित करेगा, जो असाधारण स्थितियों में टूटने की संभावना कम है। यह प्रक्रिया यह सुनिश्चित करने में भी मदद करती है कि उपयोगकर्ता विनिर्देशों को संबोधित किया गया है। - जोड़ा प्रोग्राम तैयार करना
फुर्तीली विकास में, प्रोग्रामर आमतौर पर जोड़े में एक ही समस्या पर काम करते हैं, जहां एक व्यक्ति कोड (ड्राइवर) लिख रहा है और दूसरा एक कोड की समीक्षा कर रहा है और विचार और सुझाव (नाविक) प्रदान कर रहा है। यह उत्पादकता बढ़ाता है और कोड की समीक्षा करने के लिए आवश्यक समय को कम करता है। - कोड रिफैक्टिंग
कोड रिफैक्टिंग में कोड को छोटे और सरल मॉड्यूल में तोड़ना शामिल है जो आदर्श परिदृश्य में स्वतंत्र रूप से मौजूद हो सकता है (और होना चाहिए)। इससे कोड की पठनीयता, परीक्षणशीलता और स्थिरता में काफी हद तक सुधार होता है। - वास्तविक हितधारकों से सक्रिय भागीदारी
एक निश्चित समयावधि के नियमित अंतराल के बाद ("ss" के रूप में संदर्भित), क्लाइंट को सॉफ़्टवेयर का एक महत्वपूर्ण कार्य प्रोटोटाइप प्राप्त करना चाहिए। यह डेवलपर्स को इस बात पर प्रतिक्रिया देने की अनुमति देता है कि वे किस भवन में जाते हैं। - आवश्यकताओं को प्राथमिकता वाले स्टैक के रूप में समझें
चंचलता में, उनके महत्व के आधार पर आवश्यकताओं को वर्गीकृत करना आवश्यक है। इसमें सॉफ्टवेयर उत्पाद के विकसित होने के साथ-साथ स्पष्ट ग्राहक अपेक्षाएं दोनों शामिल हो सकते हैं। सॉफ़्टवेयर डेवलपमेंट टीम को सामूहिक रूप से उस समय और संसाधनों का अनुमान लगाना चाहिए, जो वे उस सुविधा को लागू करने के लिए निवेश करने जा रहे हैं, और जो उपयोगकर्ता की आवश्यकताओं और उस क्रम के आधार पर मैप करता है जिसमें वे प्रोजेक्ट के प्रत्येक भाग से निपटेंगे। - प्रतिगमन परीक्षण
प्रतिगमन परीक्षण में एक नई सुविधा जोड़ने या कोड में मौजूदा कार्यक्षमता को संशोधित करने के बाद एक संपूर्ण एप्लिकेशन की कार्यक्षमता का परीक्षण करना शामिल है। इससे यह सुनिश्चित करने में मदद मिलती है कि परिवर्तनों ने मौजूदा कोड को तोड़ा नहीं है।
चंचल क्यों?
एजाइल कुछ प्रथाओं को निर्धारित करता है, लेकिन यह उन्हें सॉफ्टवेयर डेवलपमेंट टीम पर लागू नहीं करता है। आखिरकार, अगर समायोजन और विचलन की कोई गुंजाइश नहीं है, तो एजाइल का उद्देश्य काफी हद तक पराजित होता है। एक परियोजना में चंचल विकास के कुछ पहलुओं को शामिल करने से सॉफ्टवेयर विकास टीमों को अप्रत्याशित चुनौतियों का सामना करने में मदद मिल सकती है और अंततः, एक अधिक कुशल तरीके से एक बेहतर उत्पाद का निर्माण होता है।
नो बग्स, नो स्ट्रेस - योर स्टेप बाय स्टेप गाइड बाय स्टेप गाइड टू लाइफ-चेंजिंग सॉफ्टवेर विदाउट योर लाइफ
जब कोई भी सॉफ़्टवेयर गुणवत्ता की परवाह नहीं करता है तो आप अपने प्रोग्रामिंग कौशल में सुधार नहीं कर सकते हैं।