जीवन चक्र और सॉफ्टवेयर विकास के चरण। सॉफ्टवेयर जीवन चक्र: अवधारणा, मानक, प्रक्रिया सॉफ्टवेयर जीवन चक्र

चित्र: 5.2।

ये पहलू हैं:

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

संगठनात्मक प्रक्रियाओं को संपूर्ण रूप से कॉर्पोरेट संगठन या संपूर्ण संगठन के स्तर पर किया जाता है, जो सॉफ्टवेयर जीवनचक्र प्रक्रियाओं के कार्यान्वयन और निरंतर सुधार के लिए एक आधार बनाता है।

5.6। सॉफ्टवेयर जीवनचक्र के मॉडल और चरण

जीवन चक्र मॉडल को एक संरचना के रूप में समझा जाता है जो सॉफ्टवेयर के जीवन चक्र के दौरान प्रक्रियाओं, क्रियाओं और कार्यों के निष्पादन और अंतर्संबंध का क्रम निर्धारित करता है। जीवन चक्र मॉडल परियोजना की बारीकियों, पैमाने और जटिलता और उन परिस्थितियों की बारीकियों पर निर्भर करता है जिनमें सिस्टम बनाया और संचालित होता है।

आईएसओ / आईईसी 12207 एक विशिष्ट जीवनचक्र मॉडल और सॉफ्टवेयर विकास के तरीकों की पेशकश नहीं करता है। इसके प्रावधान सॉफ्टवेयर विकास के किसी भी जीवन चक्र मॉडल, विधियों और प्रौद्योगिकियों के लिए आम हैं। मानक सॉफ़्टवेयर जीवन चक्र प्रक्रियाओं की संरचना का वर्णन करता है, लेकिन यह निर्दिष्ट नहीं करता है कि इन प्रक्रियाओं में शामिल कार्यों और कार्यों को कैसे लागू किया जाए या कैसे किया जाए।

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

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

1. सॉफ्टवेयर आवश्यकताओं का गठन;
2. डिजाइन (एक प्रणाली परियोजना का विकास);
3. कार्यान्वयन (उप-चरणों में टूट सकता है: विस्तृत डिजाइन, कोडिंग);
4. परीक्षण (स्टैंडअलोन और जटिल परीक्षण और एकीकरण में टूट सकता है);
5. कमीशन (कार्यान्वयन);
6. संचालन और अनुरक्षण;
7. decommissioning।

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

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

सॉफ्टवेयर आवश्यकताओं के गठन के चरण में निम्नलिखित चरण शामिल हैं।

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

संगठन की (ऑब्जेक्ट) गतिविधि का एक मॉडल बनाना, सर्वेक्षण सामग्री के प्रसंस्करण और दो प्रकार के मॉडल का निर्माण करना:

• एक "एएस-आईएस" ("जैसा है") मॉडल जो सर्वेक्षण के समय संगठन में मामलों की वर्तमान स्थिति को दर्शाता है और यह समझने की अनुमति देता है कि संगठन कैसे काम करता है, साथ ही बाधाओं को पहचानने और स्थिति में सुधार के लिए प्रस्ताव तैयार करता है;
• मॉडल "TO-BE" ("यह कैसा होना चाहिए"), संगठन में नई प्रौद्योगिकियों के विचार को दर्शाता है।

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

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

डिज़ाइन चरण में निम्न चरण शामिल हैं।

1. एक सॉफ्टवेयर सिस्टम परियोजना का विकास। इस स्तर पर, इस सवाल का जवाब दिया जाता है कि "भविष्य की प्रणाली को क्या करना चाहिए?" विकास, सॉफ्टवेयर डिबगिंग योजना और गुणवत्ता नियंत्रण।

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

2. एक विस्तृत (तकनीकी) परियोजना का विकास। इस स्तर पर, वास्तविक सॉफ्टवेयर डिजाइन किया जाता है, जिसमें सिस्टम आर्किटेक्चर और विस्तृत डिजाइन शामिल हैं। इस प्रकार, प्रश्न का उत्तर दिया जाता है: "एक प्रणाली का निर्माण कैसे करें ताकि यह आवश्यकताओं को पूरा करे?"

विस्तृत डिज़ाइन का परिणाम एक सत्यापित सॉफ़्टवेयर विनिर्देश का विकास है, जिसमें शामिल हैं:

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

विस्तृत डिजाइन चरण का समापन के माध्यम से है

सॉफ्टवेयर जीवन चक्र मानकों

• GOST 34.601-90
• आईएसओ / आईईसी 12207: 1995 (रूसी एनालॉग - GOST आर आईएसओ / आईईसी 12207-99)

मानक GOST 34 .601-90

Iterative मॉडल

अनुक्रमिक मॉडल का एक विकल्प तथाकथित पुनरावृत्ति और वृद्धिशील विकास मॉडल (eng) है। पुनरावृत्त और वृद्धिशील विकास, IID ), जो 70 के दशक में टी। गिल्ब से भी प्राप्त हुई थी। नाम विकासवादी मॉडल... इस मॉडल को भी कहा जाता है पुनरावृत्त मॉडल तथा वृद्धिशील मॉडल .

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

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

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

अधिकांश आधुनिक विकास विधियों (आरयूपी, एमएसएफ) में पुनरावृत्त दृष्टिकोण के विभिन्न संस्करण लागू किए गए हैं।

सर्पिल मॉडल

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

प्रत्येक पुनरावृत्ति पर, निम्नलिखित का मूल्यांकन किया जाता है:

• परियोजना की शर्तों और लागत को पार करने का जोखिम;
• एक और पुनरावृत्ति करने की आवश्यकता;
• सिस्टम के लिए आवश्यकताओं को समझने की पूर्णता और सटीकता की डिग्री;
• परियोजना को समाप्त करने की व्यवहार्यता।

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

सर्पिल मॉडल की एक विशिष्ट विशेषता जीवन चक्र और मील के पत्थर के संगठन को प्रभावित करने वाले जोखिमों पर विशेष ध्यान देना है। Boehm 10 सबसे आम (प्राथमिकता वाले) जोखिमों को सूचीबद्ध करता है:

1. विशेषज्ञों की कमी।
2. अवास्तविक समय और बजट।
3. अनुचित कार्यक्षमता का कार्यान्वयन।
4. गलत यूजर इंटरफेस डिजाइन करना।
5. पूर्णतावाद, अनावश्यक अनुकूलन और सम्मान विवरण।
6. परिवर्तन की एक सतत धारा।
7. बाहरी घटकों के बारे में जानकारी का अभाव जो सिस्टम के वातावरण को परिभाषित करता है या एकीकरण में शामिल होता है।
8. बाहरी (परियोजना के संबंध में) संसाधनों द्वारा किए गए कार्यों में कमी।
9. परिणामी प्रणाली का अपर्याप्त प्रदर्शन।
10. विभिन्न क्षेत्रों में विशेषज्ञों की योग्यता में अंतर।

वर्तमान सर्पिल मॉडल नियंत्रण बिंदुओं के सामान्य सेट को परिभाषित करता है:

1. संचालन की अवधारणा (सीओओ) - प्रणाली की अवधारणा (उपयोग);
2. जीवन चक्र उद्देश्य (LCO) - लक्ष्य और जीवन चक्र की सामग्री;
3. जीवन चक्र वास्तुकला (LCA) - जीवन चक्र वास्तुकला; यहाँ लक्ष्य सॉफ्टवेयर प्रणाली की वैचारिक वास्तुकला की तत्परता के बारे में बात करना संभव है;
4. प्रारंभिक परिचालन क्षमता (IOC) - उत्पाद का पहला संस्करण बनाया जा रहा है, परीक्षण ऑपरेशन के लिए उपयुक्त;
5. अंतिम परिचालन क्षमता (एफओसी) एक तैयार उत्पाद है, जो वास्तविक संचालन के लिए तैनात (स्थापित और कॉन्फ़िगर) है।

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

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

साहित्य

• ब्राटिचेंको वी.वी. सूचना प्रणाली डिजाइन। - इरकुत्स्क: बीएसयूईपी पब्लिशिंग हाउस, 2004 ।-- 84 पी।
• वेंद्रोव ए.एम. डिज़ाइन सॉफ्टवेयर आर्थिक सूचना प्रणाली। - एम ।: वित्त और सांख्यिकी, 2000।
• ग्रेकुल वी.आई., डेनिसचेनो जी.एन., कोरोवकिना एन.एल. सूचना प्रणाली डिजाइन। - एम ।: इंटरनेट विश्वविद्यालय सूचना प्रौद्योगिकी - INTUIT.ru, 2005।
• मिशिनिन ए.आई. आर्थिक सूचना प्रणाली का सिद्धांत। - एम ।: वित्त और सांख्यिकी, 2000 ।-- 240 पी।

टिप्पणियाँ

विकिमीडिया फाउंडेशन। 2010।

"जीवन चक्र" की अवधारणा का अर्थ कुछ ऐसा है जो पैदा हो रहा है, विकसित हो रहा है और मर रहा है। एक जीवित जीव की तरह, सॉफ्टवेयर उत्पाद समय के साथ निर्मित, संचालित और विकसित होते हैं।

जीवन चक्र सॉफ्टवेयर में इसके विकास के सभी चरण शामिल हैं: इसकी आवश्यकता के उद्भव से लेकर अप्रचलन के कारण इसके उपयोग की पूर्ण समाप्ति या संगत समस्याओं को हल करने की आवश्यकता का नुकसान।

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

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

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

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

लघु जीवन सॉफ्टवेयर उत्पादों

ऐसे कार्यक्रमों का रखरखाव और संशोधन वैकल्पिक है, और गणनाओं के परिणाम प्राप्त करने के बाद उनका जीवन चक्र समाप्त हो जाता है। इस तरह के कार्यक्रमों के जीवन चक्र में मुख्य लागत प्रणाली विश्लेषण और डिजाइन के चरणों पर आती है, जो एक महीने से 1 तक ... 2 साल, परिणामस्वरूप

एक सॉफ्टवेयर उत्पाद का जीवन चक्र शायद ही कभी 3 साल से अधिक हो।

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

लंबे समय से सेवा जीवन के साथ सॉफ्टवेयर उत्पाद

विशेषज्ञों की बड़ी टीम उनके डिजाइन और संचालन में लगी हुई है, जिसके लिए सॉफ्टवेयर सिस्टम के औपचारिककरण की आवश्यकता होती है, साथ ही अंतिम उत्पाद के प्राप्त गुणवत्ता संकेतकों के औपचारिक परीक्षण और निर्धारण की आवश्यकता होती है। उनका जीवन चक्र 10 ... 20 वर्ष है। 70 तक ... इस समय का 90% संचालन और रखरखाव पर खर्च किया जाता है। बड़े पैमाने पर प्रतिकृति और दीर्घकालिक रखरखाव के कारण, इस तरह के सॉफ्टवेयर उत्पादों के संचालन और रखरखाव की प्रक्रिया में कुल लागत प्रणाली विश्लेषण और डिजाइन की लागत से काफी अधिक है।

निम्नलिखित सभी प्रस्तुति बड़े (जटिल) के विकास पर केंद्रित है सॉफ्टवेयर उपकरण प्रबंधन और सूचना प्रसंस्करण।

सामान्यीकृत मॉडल जीवन चक्र एक सॉफ्टवेयर उत्पाद इस तरह दिख सकता है:

मैं। प्रणाली विश्लेषण:

एक शोध;

बी) व्यवहार्यता अध्ययन:

आपरेशनल;

आर्थिक;

व्यावसायिक।

द्वितीय। सॉफ्टवेर डिज़ाइन:

एक डिजाईन:

प्रणाली का कार्यात्मक अपघटन, इसकी वास्तुकला;

बाहरी सॉफ्टवेयर डिजाइन;

डेटाबेस डिजाइन;

सॉफ़्टवेयर वास्तुशिल्प;

बी) प्रोग्रामिंग:

आंतरिक सॉफ्टवेयर डिजाइन;

सॉफ्टवेयर मॉड्यूल के बाहरी डिजाइन;

सॉफ्टवेयर मॉड्यूल का आंतरिक डिजाइन;

कोडिंग;

डिबगिंग कार्यक्रम;

प्रोग्रामिंग;

c) सॉफ्टवेयर डिबगिंग।

तृतीय। सॉफ्टवेयर का मूल्यांकन (परीक्षण)।

चतुर्थ। सॉफ्टवेयर का उपयोग:

ए) ऑपरेशन;

b) संगत।

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

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

अनुसंधान शुरू होता है पल से विकास प्रबंधक सॉफ्टवेयर की आवश्यकता का एहसास करता है।

नौकरी में सॉफ्टवेयर उत्पाद के लिए आवश्यकताओं की एक औपचारिक हस्तलिखित सूची तैयार करने के लिए आवश्यक गतिविधियों का नियोजन और समन्वय करना शामिल है।

अनुसंधान समाप्त होता है जब आवश्यकताएं इस तरह से बनती हैं कि वे दृश्यमान हो जाती हैं और यदि आवश्यक हो, तो जिम्मेदार प्रबंधक द्वारा संशोधित और अनुमोदित किया जा सकता है।

व्यवहार्यता अध्ययन अनुसंधान का एक तकनीकी हिस्सा है और शुरू होता है जब नेतृत्व का इरादा पर्याप्त मजबूत होता है कि एक परियोजना प्रबंधक को संसाधनों (श्रम) के डिजाइन और आवंटन को व्यवस्थित करने के लिए नियुक्त किया जाता है।

कार्य में प्रस्तावित सॉफ्टवेयर उत्पाद के अध्ययन में परियोजना की व्यवहार्यता का व्यावहारिक मूल्यांकन प्राप्त करना शामिल है, विशेष रूप से, यह निर्धारित करता है:

- परिचालन व्यवहार्यता , क्या व्यावहारिक उपयोग के लिए उत्पाद पर्याप्त आरामदायक होगा?

- आर्थिक साध्यता , क्या उत्पाद की लागत स्वीकार्य रूप से विकसित हो रही है? यह लागत क्या है? क्या उत्पाद उपयोगकर्ता के हाथ में एक लागत प्रभावी उपकरण होगा?

- व्यावसायिक व्यवहार्यता, क्या उत्पाद आकर्षक, मांग में, स्थापित करने में आसान, सेवा के अनुकूल, सीखने में आसान होगा?

उपरोक्त आवश्यकताओं पर विचार करते समय इन और अन्य मुद्दों को मुख्य रूप से संबोधित किया जाना चाहिए।

व्यवहार्यता अध्ययन समाप्त हो जाता है जब सभी आवश्यकताओं को एकत्र किया गया है और अनुमोदित किया गया है।

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

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

अक्सर सिस्टम विश्लेषण की अवधि के दौरान, आगे के सॉफ़्टवेयर विकास को रोकने के लिए एक निर्णय लिया जाता है।

द्वितीय... सॉफ्टवेर डिज़ाइन। डिजाइन सॉफ्टवेयर जीवन चक्र का मुख्य और निर्णायक चरण है, जिसके दौरान एक सॉफ्टवेयर उत्पाद बनाया जाता है और 90% अपना अंतिम रूप लेता है।

जीवन का यह चरण परियोजना की विभिन्न गतिविधियों को कवर करता है और इसे तीन मुख्य चरणों में विभाजित किया जा सकता है: सॉफ्टवेयर उत्पाद का डिज़ाइन, प्रोग्रामिंग और डीबगिंग।

निर्माण सॉफ्टवेयर आमतौर पर प्रारंभिक अध्ययन चरण के रूप में शुरू होता है, एक बार कुछ प्रारंभिक लक्ष्यों और आवश्यकताओं को कागज पर तय किया जाता है।

जब तक आवश्यकताएं स्वीकृत हो जाती हैं, तब तक डिजाइन चरण में काम पूरे जोरों पर होगा।

सॉफ्टवेयर के जीवन के इस खंड में, वे बाहर ले जाते हैं:

समस्या के कार्यात्मक विघटन को हल किया जा रहा है, जिसके आधार पर इस समस्या का सिस्टम आर्किटेक्चर निर्धारित किया जाता है;

सॉफ्टवेयर का बाहरी डिजाइन, उपयोगकर्ता के साथ बाहरी बातचीत के रूप में व्यक्त किया गया;

डेटाबेस डिजाइन, यदि आवश्यक हो;

सॉफ्टवेयर वास्तुकला डिजाइन - वस्तुओं, मॉड्यूल और उनके इंटरफ़ेस को परिभाषित करना।

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

इस स्तर पर, सॉफ़्टवेयर उत्पाद को असेंबल करने से संबंधित कार्य किया जाता है। यह सिस्टम के प्रत्येक मॉड्यूल के आंतरिक तर्क के विकास में एक सॉफ्टवेयर उत्पाद के विस्तृत आंतरिक डिजाइन में शामिल होता है, जिसे तब एक विशिष्ट कार्यक्रम के पाठ में व्यक्त किया जाता है।

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

डिबगिंग सॉफ्टवेयर इसके सभी घटकों को अलग-अलग डीबग करने और एकल सॉफ़्टवेयर उत्पाद में इकट्ठा करने के बाद किया जाता है।

तृतीय... सॉफ्टवेयर का मूल्यांकन (परीक्षण)।इस चरण में, सॉफ्टवेयर उत्पाद को गैर-डेवलपर्स के समूह द्वारा कठोर प्रणाली परीक्षण के अधीन किया जाता है।

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

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

यह प्रोग्रामिंग के रूप में लंबे समय तक ले जाता है।

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

इस तरह की तुलना इस तथ्य के मद्देनजर उचित है कि एक सॉफ्टवेयर उत्पाद के उपयोग के दौरान, त्रुटियों को इसके डिजाइन की प्रक्रिया में ठीक किया गया है।

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

यह वह समय है जिसके दौरान उत्पाद कार्रवाई में है और प्रभावी ढंग से उपयोग किया जाता है।

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

उपयोग चरण तब समाप्त होता है जब उत्पाद उपयोग से बाहर हो जाता है और उपरोक्त गतिविधियों को समाप्त कर दिया जाता है। हालाँकि, ध्यान दें कि सॉफ़्टवेयर उत्पाद का उपयोग किसी और के द्वारा लंबे समय तक किया जा सकता है और उपयोग चरण के बाद जैसा कि यहाँ परिभाषित किया गया है। क्योंकि यह कोई भी डेवलपर की मदद के बिना भी घर पर सॉफ्टवेयर उत्पाद का उपयोग कर सकता है।

एक सॉफ्टवेयर उत्पाद का उपयोग इसके संचालन और रखरखाव से निर्धारित होता है।

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

सॉफ्टवेयर की रखरखाव रखरखाव, कार्यात्मक क्षमताओं का विकास और सॉफ्टवेयर उत्पाद के परिचालन विशेषताओं में सुधार, सॉफ़्टवेयर उत्पाद की प्रतिकृति और स्थानांतरण में विभिन्न प्रकार की कंप्यूटिंग सुविधाओं में शामिल हैं।

रखरखाव परिचालन चरण से आवश्यक प्रतिक्रिया की भूमिका निभाता है।

सॉफ्टवेयर के संचालन के दौरान, कार्यक्रमों में त्रुटियों का पता लगाना संभव है, और उन्हें संशोधित करना और उनके कार्यों का विस्तार करना आवश्यक हो जाता है।

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

सॉफ्टवेयर उत्पाद जीवनचक्र के चरणों के बीच ओवरलैप

सॉफ्टवेयर उत्पाद जीवन चक्र के विभिन्न चरणों के बीच ओवरलैप संभव और आम तौर पर वांछनीय हैं। हालांकि, आसन्न प्रक्रियाओं के बीच कोई ओवरलैप नहीं होना चाहिए।

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

कुछ बदलावों के साथ एक सॉफ्टवेयर उत्पाद के जीवन चक्र का माना जाने वाला मॉडल छोटी परियोजनाओं के लिए एक मॉडल के रूप में काम कर सकता है।

उदाहरण के लिए, जब किसी एकल कार्यक्रम को डिजाइन किया जा रहा होता है, तो सिस्टम आर्किटेक्चर के साथ अक्सर विवाद होता है और

डेटाबेस डिजाइन; मूल और विस्तृत बाहरी डिजाइन की प्रक्रियाएं अक्सर एक साथ विलय होती हैं, आदि।

सॉफ्टवेयर जीवन चक्र मानकों

• GOST 34.601-90
• आईएसओ / आईईसी 12207: 1995 (रूसी एनालॉग - GOST आर आईएसओ / आईईसी 12207-99)

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

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

स्टैंडर्ड GOST 34.601-90

GOST 34.601-90 मानक एक स्वचालित प्रणाली बनाने के निम्नलिखित चरणों और चरणों के लिए प्रदान करता है:

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

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

यह मानक वर्तमान समय में विकास के लिए बिल्कुल उपयुक्त नहीं है: कई प्रक्रियाएं पर्याप्त रूप से परिलक्षित नहीं होती हैं, और कुछ प्रावधान पुराने हैं।

आईएसओ / आईईसी 12207 / मानक और इसके आवेदन

आईएसओ / आईईसी 12207: 1995 "सूचना प्रौद्योगिकी - सॉफ्टवेयर जीवन चक्र प्रक्रियाएं" मुख्य आदर्श दस्तावेज है जो सॉफ्टवेयर जीवन चक्र प्रक्रियाओं की संरचना को नियंत्रित करता है। यह एक जीवन चक्र संरचना को परिभाषित करता है, जिसमें प्रक्रियाओं, गतिविधियों और कार्यों को शामिल किया जाता है जो सॉफ्टवेयर निर्माण के दौरान किया जाना चाहिए।

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

सॉफ्टवेयर जीवन चक्र प्रक्रियाओं

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

प्रत्येक प्रक्रिया में कार्यों की एक श्रृंखला शामिल है। उदाहरण के लिए, अधिग्रहण की प्रक्रिया में निम्नलिखित चरण शामिल हैं:

1. अधिग्रहण शुरू करना
2. आवेदन प्रस्तावों की तैयारी
3. अनुबंध की तैयारी और संशोधन
4. आपूर्तिकर्ता पर्यवेक्षण
5. कार्यों की स्वीकृति और पूर्णता

प्रत्येक क्रिया में कार्यों की एक श्रृंखला शामिल है। उदाहरण के लिए, बोली प्रस्तावों की तैयारी में शामिल होना चाहिए:

1. सिस्टम आवश्यकताओं का गठन
2. सॉफ्टवेयर उत्पादों की एक सूची का गठन
3. स्थितियां और समझौते तय करना
4. तकनीकी सीमाओं (सिस्टम के कामकाज का वातावरण, आदि) का विवरण

सॉफ्टवेयर जीवन चक्र के चरण, प्रक्रियाओं और चरणों के बीच संबंध

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

GOST R ISO / IEC 12207-99 एक विशिष्ट जीवन चक्र मॉडल की पेशकश नहीं करता है। इसके प्रावधान आईपी बनाने के लिए किसी भी जीवन चक्र मॉडल, विधियों और प्रौद्योगिकियों के लिए आम हैं। यह इन प्रक्रियाओं में शामिल गतिविधियों और कार्यों को लागू करने या निष्पादित करने के तरीके को निर्दिष्ट किए बिना जीवन चक्र प्रक्रियाओं की संरचना का वर्णन करता है।

सॉफ्टवेयर जीवनचक्र मॉडल में शामिल हैं:

1. चरणों;
2. प्रत्येक चरण में काम के परिणाम;
3. प्रमुख घटनाएं पूर्णता और निर्णय लेने के बिंदु हैं।

मंच - सॉफ्टवेयर विकास प्रक्रिया का एक हिस्सा, एक निश्चित समय सीमा तक सीमित और इस चरण के लिए निर्धारित आवश्यकताओं द्वारा निर्धारित एक विशिष्ट उत्पाद (मॉडल, सॉफ्टवेयर घटक, प्रलेखन) की रिहाई के साथ समाप्त होता है।

प्रत्येक चरण में, GOST R ISO / IEC 12207-99 मानक में परिभाषित कई प्रक्रियाएं की जा सकती हैं, और इसके विपरीत, एक ही प्रक्रिया को विभिन्न चरणों में किया जा सकता है। प्रक्रियाओं और चरणों के बीच संबंध भी सॉफ्टवेयर जीवन चक्र मॉडल द्वारा निर्धारित किया जाता है।

सॉफ्टवेयर जीवन चक्र मॉडल

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

आज तक, निम्नलिखित मुख्य जीवन चक्र मॉडल सबसे व्यापक रूप से उपयोग किए जाते हैं:

• समस्या मॉडल;

• कैस्केड मॉडल (या प्रणालीगत) (70-85 वर्ष);

• सर्पिल मॉडल (वर्तमान)।

समस्या मॉडल

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

• अत्यधिक आग्रह (आपको किसी तरह समस्याओं को हल करने की आवश्यकता है; फिर आपको फिर से सब कुछ करना होगा);

• प्रयोग और ग्राहक अनुकूलन (एल्गोरिदम स्पष्ट नहीं हैं, समाधान परीक्षण और त्रुटि से टकराने हैं)।

सामान्य निष्कर्ष: इस तरह से एक पर्याप्त बड़ी प्रभावी सूचना प्रणाली बनाना असंभव है।

कैस्केड मॉडल

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

झरना दृष्टिकोण का उपयोग करने के लाभ इस प्रकार हैं:

• प्रत्येक चरण में, परियोजना प्रलेखन का एक पूरा सेट बनता है जो पूर्णता और स्थिरता के मानदंडों को पूरा करता है;

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

झरना मॉडल के अनुसार परियोजना के चरण:

1. आवश्यकताओं का गठन;
2. डिज़ाइन;
3. कार्यान्वयन;
4. परिक्षण;
5. कार्यान्वयन;
6. संचालन और अनुरक्षण।

चित्र: 1. जलप्रपात विकास योजना

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

चित्र: 2. एक झरना योजना में सॉफ्टवेयर विकास की वास्तविक प्रक्रिया

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

सर्पिल मॉडल

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

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

प्रत्येक पुनरावृत्ति एक पूर्ण विकास चक्र का प्रतिनिधित्व करता है, जो किसी उत्पाद के आंतरिक या बाहरी संस्करण (या अंतिम उत्पाद का सबसेट) को जारी करता है, जो कि पूर्ण प्रणाली बनने के लिए पुनरावृति से पुनरावृत्ति में सुधार होता है।

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

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

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

अंजीर 3. जीवन चक्र का सर्पिल मॉडल आईएस है

सर्पिल जीवन चक्र मॉडल के ढांचे के भीतर सॉफ्टवेयर विकास के संभावित दृष्टिकोणों में से एक हाल ही में तेजी से अनुप्रयोग विकास आरएडी (रैपिड एप्लीकेशन डेवलपमेंट) की व्यापक पद्धति है। यह शब्द आमतौर पर एक सॉफ्टवेयर विकास प्रक्रिया को संदर्भित करता है जिसमें 3 तत्व होते हैं:

• प्रोग्रामर की एक छोटी टीम (2 से 10 लोगों से);

• लघु लेकिन अच्छी तरह से विकसित उत्पादन अनुसूची (2 से 6 महीने से);

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

राड सॉफ्टवेयर जीवन चक्र में चार चरण होते हैं:

• आवश्यकताएँ परिभाषा और विश्लेषण चरण;

• डिजाइन चरण;

• कार्यान्वयन चरण;

• कार्यान्वयन चरण।

प्रत्येक पुनरावृत्ति पर, निम्नलिखित का मूल्यांकन किया जाता है:

• परियोजना की शर्तों और लागत को पार करने का जोखिम;
• एक और पुनरावृत्ति करने की आवश्यकता;
• सिस्टम के लिए आवश्यकताओं को समझने की पूर्णता और सटीकता की डिग्री;
• परियोजना को समाप्त करने की व्यवहार्यता।

पुनरावृत्ति दृष्टिकोण के लाभ:

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

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

आईएसओ / आईईसी 12207 मानक के अनुसार, सभी जीवन चक्र प्रक्रियाओं को तीन समूहों (छवि 2.1) में विभाजित किया गया है।

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

1. सॉफ्टवेयर आवश्यकताओं का गठन।

2. डिजाइन।

3. कार्यान्वयन।

4. परीक्षण।

5. कमीशन।

6. संचालन और रखरखाव।

7. डिमोशनिंग।

वर्तमान में, सॉफ्टवेयर जीवनचक्र के निम्नलिखित मूल मॉडल सबसे अधिक व्यापक रूप से उपयोग किए जाते हैं:

क) कैस्केडिंग और

बी) सर्पिल (विकासवादी)।

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

झरना मॉडल का उपयोग करने के फायदे इस प्रकार हैं:

प्रत्येक चरण में, परियोजना प्रलेखन का एक पूरा सेट बनता है;

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

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

झरना दृष्टिकोण का मुख्य नुकसान परिणाम प्राप्त करने में एक महत्वपूर्ण देरी है और, परिणामस्वरूप, एक प्रणाली बनाने का एक उच्च जोखिम है जो उपयोगकर्ताओं की बदली हुई आवश्यकताओं को पूरा नहीं करता है।

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

जलप्रपात (विकासवादी) मॉडल को आरेख के रूप में दर्शाया जा सकता है, जिसे चित्र 2.5 में दिखाया गया है।

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

1) आवश्यकताओं का विश्लेषण और योजना;

2) डिजाइन;

3) कार्यान्वयन;

4) कार्यान्वयन।

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

1) रणनीति;

2) विश्लेषण;

3) डिजाइन;

4) कार्यान्वयन;

5) परीक्षण;

6) कार्यान्वयन;

7) ऑपरेशन और तकनीकी सहायता.

रणनीति

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

रणनीति परिभाषा चरण का परिणाम एक दस्तावेज है जिसमें निम्नलिखित स्पष्ट रूप से तैयार किया गया है:

यदि ग्राहक इस परियोजना को पूरा करने के लिए सहमत है तो ग्राहक के कारण वास्तव में क्या है;

वह तैयार उत्पाद (कार्य अनुसूची) कब प्राप्त कर सकेगा;

उसे कितना खर्च करना होगा (बड़ी परियोजनाओं के लिए काम के वित्तपोषण के चरणों की अनुसूची)।

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

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

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

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

विश्लेषक दो परस्पर संबंधित रूपों में जानकारी एकत्र और रिकॉर्ड करते हैं:

क) कार्य - व्यवसाय में होने वाली घटनाओं और प्रक्रियाओं के बारे में जानकारी;

ख) संस्थाएं - उन वस्तुओं के बारे में जानकारी जो संगठन के लिए प्रासंगिक हैं और जिनके बारे में कुछ ज्ञात है।

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

डिज़ाइन

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

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

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

डिजाइन कार्य हैं:

विश्लेषण के परिणामों पर विचार और उनकी पूर्णता का सत्यापन;

एक ग्राहक के साथ सेमिनार;

परियोजना के महत्वपूर्ण क्षेत्रों की पहचान और इसकी सीमाओं का आकलन;

सिस्टम आर्किटेक्चर का निर्धारण;

तृतीय-पक्ष उत्पादों के उपयोग के साथ-साथ इन उत्पादों के साथ सूचना के आदान-प्रदान के लिए एकीकरण और तंत्र के तरीकों पर निर्णय लेना;

डेटा वेयरहाउस डिज़ाइन: डेटाबेस मॉडल;

प्रक्रिया और कोड डिजाइन: विकास उपकरण का अंतिम चयन, कार्यक्रम इंटरफेस की परिभाषा, अपने मॉड्यूल के लिए सिस्टम कार्यों की मैपिंग और मॉड्यूल विनिर्देशों की परिभाषा;

परीक्षण प्रक्रिया के लिए आवश्यकताओं का निर्धारण;

सिस्टम सुरक्षा आवश्यकताओं का निर्धारण।

कार्यान्वयन

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

विकास के चरण के दौरान, डिजाइनरों, डेवलपर्स और परीक्षण टीमों के बीच घनिष्ठ संपर्क होता है। गहन विकास के मामले में, डेवलपर डेवलपर से शाब्दिक रूप से अविभाज्य है, प्रभावी रूप से विकास टीम का सदस्य बन जाता है।

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

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

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

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

परिक्षण

किसी परियोजना के विकास में शुरुआती सहयोग से टेस्ट टीम शामिल हो सकती है। आमतौर पर जटिल परीक्षण को एक अलग विकास चरण में विभाजित किया जाता है। परियोजना की जटिलता के आधार पर, परीक्षण और त्रुटियों को ठीक करने में कुल परियोजना समय का एक तिहाई, या उससे भी अधिक समय लग सकता है।

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

त्रुटि संदेश संग्रहीत करना (सिस्टम का कौन सा घटक त्रुटि का है, किसने इसे पाया, इसे कैसे पुन: उत्पन्न किया जाए, इसे ठीक करने के लिए कौन जिम्मेदार है, जब इसे ठीक किया जाना चाहिए);

नई त्रुटियों की उपस्थिति के बारे में अधिसूचना प्रणाली, सिस्टम में ज्ञात त्रुटियों की स्थिति में बदलाव (अधिसूचना द्वारा) ईमेल);

सिस्टम घटकों द्वारा वास्तविक त्रुटियों पर रिपोर्ट;

त्रुटि और उसके इतिहास के बारे में जानकारी;

कुछ श्रेणियों की त्रुटियों तक पहुँचने के लिए नियम;

अंतिम उपयोगकर्ता के लिए बग ट्रैकिंग सिस्टम सीमित पहुंच इंटरफ़ेस।

ऐसी प्रणालियाँ कई संगठनात्मक समस्याओं को लेती हैं, विशेष रूप से स्वचालित त्रुटि अधिसूचना के मुद्दे

वास्तविक प्रणाली परीक्षणों को आमतौर पर कई श्रेणियों में विभाजित किया जाता है:

ए) ऑफ़लाइन परीक्षण मॉड्यूल; वे सिस्टम घटकों के विकास के चरण में पहले से ही उपयोग किए जाते हैं और आपको व्यक्तिगत घटकों की त्रुटियों को ट्रैक करने की अनुमति देते हैं;

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

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

घ) स्वीकृति परीक्षण; इसका मुख्य उद्देश्य ग्राहक को सिस्टम सौंपना है;

इ) प्रदर्शन और लोड परीक्षण; परीक्षणों का यह समूह प्रणाली में शामिल है, यह वह है जो सिस्टम की विश्वसनीयता का आकलन करने के लिए मुख्य है।

प्रत्येक समूह में आवश्यक रूप से मॉडलिंग विफलताओं के लिए परीक्षण शामिल हैं। वे एक घटक, घटकों के एक समूह और निम्नलिखित विफलताओं के लिए एक पूरे के रूप में सिस्टम की प्रतिक्रिया की जांच करते हैं:

सूचना प्रणाली का एक अलग घटक;

सिस्टम घटकों के समूह;

सिस्टम के मुख्य मॉड्यूल;

ऑपरेटिंग सिस्टम;

हार्ड विफलता (बिजली की विफलता, हार्ड ड्राइव)।

ये परीक्षण सूचना प्रणाली की सही स्थिति को बहाल करने के लिए उपतंत्र की गुणवत्ता का आकलन करना और औद्योगिक संचालन के दौरान विफलताओं के नकारात्मक परिणामों को रोकने के लिए रणनीति विकसित करने के लिए सूचना के मुख्य स्रोत के रूप में काम करना संभव बनाते हैं।

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

कार्यान्वयन

परीक्षण प्रक्रिया परीक्षण प्रक्रिया को ओवरलैप करती है। प्रणाली को शायद ही कभी पूरी तरह से लागू किया जाता है। आमतौर पर, यह एक क्रमिक या पुनरावृत्त प्रक्रिया है (एक चक्रीय जीवन चक्र के मामले में)।

कमीशन कम से कम तीन चरणों से गुजरता है:

2) जानकारी का संचय;

3) डिजाइन क्षमता तक पहुंचना (यानी, परिचालन चरण के लिए वास्तविक संक्रमण)।

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

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

प्रणाली डिजाइन क्षमता तक पहुँचने एक अच्छे संस्करण में, यह छोटी त्रुटियों और दुर्लभ गंभीर त्रुटियों का ठीक-ठीक समाधान है।

संचालन और तकनीकी सहायता

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