सॉफ्टवेयर विकास प्रक्रिया

Xnxx
सॉफ्टवेयर डेवलपमेंट प्रक्रिया किसी सॉफ्टवेयर उत्पाद के विकास में अधिरोपित एक संरचना है। इसके पर्यायवाची शब्द सॉफ्टवेयर जीवन चक्र और सॉफ्टवेयर प्रक्रिया हैं। ऐसी प्रक्रियाओं के लिए कई मॉडल हैं। इनमें से प्रत्येक प्रक्रिया के दौरान होने वाले विभिन्न प्रकार के कार्यों या गतिविधियों तक पहुंच का वर्णन करते हैं।

समीक्षा

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

योजना

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

डिजाईन

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

विनिर्देश

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

संरचना

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

कार्यान्वयन, परीक्षण और दस्तावेजीकरण

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

परिनियोजन और रखरखाव

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

पुनरावृत्तीय प्रक्रियाएं

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

XP: एक्सट्रीम प्रोग्रामिंग

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