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

युनिफाइड सॉफ्टवेअर डेव्हलपमेंट प्रोसेस (USDP) वापर केस मॉडेल अनुप्रयोग ज्या प्रकरणांमध्ये वापरला जाईल त्याचे वर्णन करते. विश्लेषणात्मक मॉडेल अनुप्रयोगासाठी आधारभूत वर्गांचे वर्णन करते. डिझाइन मॉडेल वर्ग आणि समर्पित वस्तूंमधील कनेक्शन आणि संबंधांचे वर्णन करते. उपयोजन मॉडेल संगणकावर सॉफ्टवेअरच्या वितरणाचे वर्णन करते. अंमलबजावणी मॉडेल प्रोग्राम कोडच्या अंतर्गत संस्थेचे वर्णन करते. चाचणी मॉडेलमध्ये चाचणी घटक, चाचणी प्रक्रिया आणि विविध चाचणी प्रकरणे असतात.

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

सॉफ्टवेअर उत्पादन आर्किटेक्चरचे वैशिष्ट्यपूर्ण घटक आणि विशिष्ट सॉफ्टवेअर आवश्यकता फॉल्ट टॉलरन्स हा सिस्टम गुणधर्मांचा एक संच आहे जो त्रुटी शोधून, पुनर्प्राप्त करून आणि सिस्टमसाठी वाईट परिणामांचे स्थानिकीकरण करून त्याची विश्वसनीयता वाढवतो. दोष सहिष्णुता सुनिश्चित करण्यासाठी कोणतीही वास्तविक प्रणाली डिझाइन करताना, सर्व संभाव्य परिस्थिती प्रदान करणे आवश्यक आहे ज्यामुळे सिस्टम अयशस्वी होऊ शकते आणि अपयश हाताळण्यासाठी यंत्रणा विकसित करणे आवश्यक आहे. विश्वासार्हता ही विविध अपयश आणि अपयशांना तोंड देण्याची प्रणालीची क्षमता आहे. अपयश म्हणजे एखाद्या त्रुटीच्या परिणामी प्रणालीचे पूर्णपणे अक्षम स्थितीत संक्रमण. अयशस्वी ही सिस्टमच्या ऑपरेशनमध्ये एक त्रुटी आहे ज्यामुळे सिस्टम अयशस्वी होत नाही. ठराविक कालावधीत कमी अपयश आणि अपयश, प्रणाली अधिक विश्वासार्ह मानली जाते.

सॉफ्टवेअर उत्पादन आर्किटेक्चरचे विशिष्ट घटक आणि विशिष्ट सॉफ्टवेअर आवश्यकता. विकसित आर्किटेक्चरची अंमलबजावणी करण्याच्या शक्यता. विकसित आर्किटेक्चरची अंमलबजावणी करण्याची शक्यता. अनावश्यक कार्यक्षमता. अनावश्यक कार्यक्षमता. तयार सॉफ्टवेअर घटक खरेदी करण्याचा निर्णय घेणे. तयार सॉफ्टवेअर घटक खरेदी करण्याचा निर्णय घेणे. रणनीती बदला. रणनीती बदला.

कार्यक्रमाची संपूर्ण संस्था स्पष्टपणे वर्णन केलेली आहे; स्पेसिफिकेशनमध्ये आर्किटेक्चरचे विहंगावलोकन आणि त्याचे तर्क समाविष्ट आहे का. कार्यक्रमाची संपूर्ण संस्था स्पष्टपणे वर्णन केलेली आहे; स्पेसिफिकेशनमध्ये आर्किटेक्चरचे विहंगावलोकन आणि त्याचे तर्क समाविष्ट आहे का. कार्यक्रमाचे प्रमुख घटक, त्यांच्या जबाबदाऱ्या आणि इतर घटकांसह परस्परसंवाद पुरेशी परिभाषित आहेत का? कार्यक्रमाचे प्रमुख घटक, त्यांच्या जबाबदाऱ्या आणि इतर घटकांसह परस्परसंवाद पुरेशी परिभाषित आहेत का? आवश्यकता तपशीलामध्ये निर्दिष्ट केलेली सर्व कार्ये वाजवी संख्येने सिस्टम घटकांद्वारे लागू केली जातात की नाही. आवश्यकता तपशीलामध्ये निर्दिष्ट केलेली सर्व कार्ये वाजवी संख्येने सिस्टम घटकांद्वारे लागू केली जातात की नाही. सर्वात महत्वाचे वर्ग आणि त्यांचे तर्क यांचे वर्णन आहे का? सर्वात महत्वाचे वर्ग आणि त्यांचे तर्क यांचे वर्णन आहे का? डेटाबेसच्या संस्थेचे वर्णन दिले आहे का? डेटाबेसच्या संस्थेचे वर्णन दिले आहे का? सर्व व्यवसाय नियम परिभाषित आहेत? सर्व व्यवसाय नियम परिभाषित आहेत? वर्णन केलेल्या प्रणालीवर त्यांचा प्रभाव आहे का? वर्णन केलेल्या प्रणालीवर त्यांचा प्रभाव आहे का? प्रश्नांची एक चेकलिस्ट जी तुम्हाला आर्किटेक्चरच्या गुणवत्तेबद्दल निष्कर्ष काढू देते:

प्रश्नांची चेकलिस्ट जी तुम्हाला आर्किटेक्चरच्या गुणवत्तेचा न्याय करू देते: वापरकर्ता इंटरफेस डिझाइन धोरण वर्णन केले आहे का? वापरकर्ता इंटरफेस डिझाइन धोरण वर्णन केले आहे? वापरकर्ता इंटरफेस मॉड्युलर बनविला गेला आहे जेणेकरुन त्यातील बदलांचा उर्वरित सिस्टमवर परिणाम होणार नाही. वापरकर्ता इंटरफेस मॉड्युलर बनविला गेला आहे जेणेकरुन त्यातील बदलांचा उर्वरित सिस्टमवर परिणाम होणार नाही. डेटा इनपुट/आउटपुट धोरणाचे वर्णन आहे का? डेटा इनपुट/आउटपुट धोरणाचे वर्णन आहे का? या आर्किटेक्चरचा वापर करून जी यंत्रणा कार्यान्वित केली जाईल त्याच्या कामगिरीचे विश्लेषण केले गेले आहे का? या आर्किटेक्चरचा वापर करून जी यंत्रणा कार्यान्वित केली जाईल त्याच्या कामगिरीचे विश्लेषण केले गेले आहे का? डिझाइन केलेल्या प्रणालीचे विश्वासार्हतेचे विश्लेषण केले गेले आहे का? डिझाइन केलेल्या प्रणालीचे विश्वासार्हतेचे विश्लेषण केले गेले आहे का? प्रणालीच्या स्केलेबिलिटी आणि विस्तारिततेचे विश्लेषण केले गेले आहे का? प्रणालीच्या स्केलेबिलिटी आणि विस्तारिततेचे विश्लेषण केले गेले आहे का?

सॉफ्टवेअर रिफॅक्टरिंग कोडची पुनरावृत्ती केली जाते; पद्धत अंमलबजावणी खूप मोठी आहे; लूपचे खूप घरटे आहेत किंवा लूप स्वतःच खूप मोठा आहे; वर्गात खराब कनेक्टिव्हिटी आहे (वर्गाच्या गुणधर्म आणि पद्धतींनी फक्त 1 ऑब्जेक्टचे वर्णन केले पाहिजे); वर्ग इंटरफेस एक सुसंगत अमूर्तता तयार करत नाही; पद्धत खूप पॅरामीटर्स घेते. मापदंडांची संख्या वाजवीपणे कमीतकमी ठेवण्याचा प्रयत्न करणे आवश्यक आहे; वर्गाचे वैयक्तिक भाग वर्गाच्या इतर भागांपेक्षा स्वतंत्रपणे बदलतात; रिफॅक्टरिंगमध्ये सॉफ्टवेअरला नवीन हार्डवेअर आणि नवीन ऑपरेटिंग सिस्टीम, नवीन विकास साधने, नवीन आवश्यकता तसेच सॉफ्टवेअर आर्किटेक्चर आणि कार्यक्षमता यांचा समावेश होतो. हे सॉफ्टवेअरच्या बाह्य वर्तनात बदल न करता त्याच्या अंतर्गत संरचनेत बदल आहे, सॉफ्टवेअरमध्ये सुधारणा सुनिश्चित करण्यासाठी डिझाइन केलेले आहे. रिफॅक्टरिंगची वाजवी कारणे:

सॉफ्टवेअर रिफॅक्टरिंग: प्रोग्राम बदलताना, समांतरपणे अनेक वर्ग बदलणे आवश्यक आहे. अशी परिस्थिती उद्भवल्यास, भविष्यात संभाव्य बदलांची ठिकाणे कमी करण्यासाठी वर्गांची पुनर्रचना करणे आवश्यक आहे; तुम्हाला समांतर अनेक वारसा पदानुक्रम बदलावे लागतील; तुम्हाला अनेक केस ब्लॉक्स बदलावे लागतील. केस ब्लॉक लागू करण्यासाठी प्रोग्राममध्ये अशा प्रकारे बदल करणे आवश्यक आहे, आणि प्रोग्राममध्ये आवश्यक वेळा कॉल करा; एकत्र वापरलेले संबंधित डेटा घटक वर्गांमध्ये आयोजित केलेले नाहीत. जर तुम्ही डेटा घटकांचा समान संच वारंवार वापरत असाल, तर हा डेटा एकत्रित करण्याचा आणि त्यावर केलेल्या ऑपरेशन्स वेगळ्या वर्गात ठेवण्याचा विचार करणे उपयुक्त आहे;

सॉफ्टवेअर रिफॅक्टरिंग पद्धत त्याच्या स्वतःच्या पेक्षा दुसऱ्या वर्गाचे अधिक घटक वापरते. याचा अर्थ असा की पद्धत दुसऱ्या वर्गात हलविली जाणे आवश्यक आहे आणि जुन्या वर्गातून कॉल करणे आवश्यक आहे; आदिम डेटा प्रकार ओव्हरलोड आहे. वास्तविक-जगातील अस्तित्वाचे वर्णन करण्यासाठी, विद्यमान डेटा प्रकार ओव्हरलोड करण्यापेक्षा वर्ग वापरणे चांगले आहे; वर्गाची कार्यक्षमता खूप मर्यादित आहे. या वर्गाची कार्यक्षमता दुसऱ्या वर्गात हलवून या वर्गापासून मुक्त होणे चांगले आहे; "स्ट्रे" डेटा पद्धतींच्या साखळीसह प्रसारित केला जातो. डेटा जो फक्त एका पद्धतीत पास केला जातो तो दुसऱ्या पद्धतीत पाठवला जातो त्याला "स्ट्रे" म्हणतात. अशा परिस्थिती उद्भवल्यास, त्यापासून मुक्त होण्यासाठी वर्ग आणि पद्धतींचे आर्किटेक्चर बदलण्याचा प्रयत्न करा.

सॉफ्टवेअर प्रॉक्सी ऑब्जेक्ट रिफॅक्टर केल्याने काहीही होत नाही. जर वर्गाची भूमिका इतर वर्गांना मेथड कॉल्स पुनर्निर्देशित करणे असेल, तर अशा मध्यस्थ ऑब्जेक्टला दूर करणे आणि इतर वर्गांना थेट कॉल करणे चांगले आहे; एका वर्गाला दुसऱ्या वर्गाबद्दल खूप माहिती असते. या परिस्थितीत, वारसाला त्याच्या पालकांबद्दल किमान ज्ञान आहे याची खात्री करण्यासाठी एन्कॅप्सुलेशन अधिक कठोर करणे आवश्यक आहे; पद्धतीला दुर्दैवी नाव आहे; डेटा सदस्य सार्वजनिक आहेत. हे इंटरफेस आणि अंमलबजावणीमधील रेषा अस्पष्ट करते, अपरिहार्यपणे एन्कॅप्सुलेशन खंडित करते आणि प्रोग्रामची लवचिकता मर्यादित करते; स्त्रोत कोडमध्ये टिप्पण्या द्या;

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

आता सॉफ्टवेअर अभियांत्रिकीमध्ये IS सॉफ्टवेअरच्या विकासासाठी दोन मुख्य दृष्टीकोन आहेत, त्यातील मूलभूत फरक सिस्टमच्या विघटनाच्या विविध पद्धतींमुळे आहे: एक फंक्शनल-मॉड्युलर (स्ट्रक्चरल) दृष्टीकोन, जो कार्यात्मक विघटनाच्या तत्त्वावर आधारित आहे, ज्यामध्ये प्रणालीच्या संरचनेचे वर्णन त्याच्या कार्यांच्या श्रेणीक्रमानुसार आणि वैयक्तिक कार्यात्मक घटकांमधील माहितीचे हस्तांतरण, आणि ऑब्जेक्ट ओरिएंटेड दृष्टीकोन, जे ऑब्जेक्ट विघटन वापरते, IS च्या संरचनेचे ऑब्जेक्ट्स आणि त्यांच्यामधील कनेक्शनच्या संदर्भात आणि ऑब्जेक्ट्समधील संदेशांच्या देवाणघेवाणीच्या संदर्भात सिस्टमच्या वर्तनाचे वर्णन करते.

तर, IS सॉफ्टवेअर डेव्हलपमेंटच्या स्ट्रक्चरल पध्दतीचे सार स्वयंचलित फंक्शन्समध्ये त्याचे विघटन करण्यामध्ये आहे: सिस्टम फंक्शनल सबसिस्टममध्ये विभागली गेली आहे, जी यामधून सबफंक्शन्समध्ये विभागली गेली आहे, जी टास्कमध्ये विभागली गेली आहे आणि त्याचप्रमाणे विशिष्ट प्रक्रियांमध्ये विभागली गेली आहे. त्याच वेळी, IS सादरीकरणाची अखंडता राखते, जिथे सर्व घटक एकमेकांशी जोडलेले असतात. "तळाशी पासून" प्रणाली विकसित करताना, वैयक्तिक कार्यांपासून संपूर्ण प्रणालीपर्यंत, अखंडता गमावली जाते आणि वैयक्तिक घटकांच्या माहितीच्या परस्परसंवादाचे वर्णन करताना समस्या उद्भवतात.

संरचनात्मक दृष्टिकोनाची मूलभूत तत्त्वे आहेत:

o तत्त्व" विभाजित करा आणि राज्य करा";

o तत्त्व श्रेणीबद्ध क्रम - प्रत्येक स्तरावर नवीन तपशील जोडून श्रेणीबद्ध वृक्ष रचनांमध्ये घटक प्रणालींचे आयोजन करण्याचे तत्त्व. दोन मूलभूत तत्त्वे हायलाइट करण्याचा अर्थ असा नाही की उर्वरित तत्त्वे दुय्यम आहेत, कारण त्यापैकी कोणत्याहीकडे दुर्लक्ष केल्याने अप्रत्याशित परिणाम होऊ शकतात.

या तत्त्वांपैकी मुख्य आहेत:

o अमूर्तता - सिस्टमच्या आवश्यक पैलूंवर प्रकाश टाकणे;

o सुसंगतता - सिस्टम घटकांची वैधता आणि सुसंगतता;

o डेटा स्ट्रक्चरिंग - डेटा संरचित आणि पदानुक्रमाने आयोजित करणे आवश्यक आहे.

सॉफ्टवेअर निर्मिती तंत्रज्ञानाचा पद्धतशीर पाया

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

ग्राफिकल (व्हिज्युअल) मॉडेल्स सिस्टम आर्किटेक्चरचे व्हिज्युअलायझिंग, वर्णन, डिझाइन आणि दस्तऐवजीकरण करण्यासाठी साधने आहेत. प्रत्येक विशिष्ट प्रकल्पात वापरल्या जाणाऱ्या मॉडेल्सची रचना आणि त्यांच्या तपशीलाची डिग्री सामान्यत: खालील घटकांवर अवलंबून असते:

o डिझाइन केलेल्या प्रणालीच्या अडचणी;

o त्याच्या वर्णनाची आवश्यक पूर्णता;

o प्रकल्पातील सहभागींचे ज्ञान आणि कौशल्ये;

o डिझाईनसाठी दिलेला वेळ.

विशेषत: CASE साधनांच्या विकासावर व्हिज्युअल मॉडेलिंगचा खूप प्रभाव पडला. CASE (Computer Aided Software Engineering) ही संकल्पना व्यापक अर्थाने वापरली जाते. या संकल्पनेचा मूळ अर्थ, केवळ स्वयंचलित सॉफ्टवेअर डेव्हलपमेंटच्या कार्यांपुरता मर्यादित, आता नवीन अर्थ प्राप्त झाला आहे, ज्यामध्ये सॉफ्टवेअर जीवन चक्रातील बहुतेक प्रक्रिया समाविष्ट आहेत.

CASE तंत्रज्ञान हा सॉफ्टवेअर डिझाइन पद्धतींचा एक संच आहे, तसेच साधनांचा एक संच आहे जो तुम्हाला एखाद्या विषय क्षेत्राचे दृश्यमानपणे मॉडेल बनवू देतो, सॉफ्टवेअर विकास आणि देखभालीच्या सर्व टप्प्यांवर या मॉडेलचे विश्लेषण करू देतो आणि माहितीच्या गरजेनुसार अनुप्रयोग विकसित करतो. वापरकर्ते. बहुतेक विद्यमान CASE साधने बाह्य आवश्यकता, सिस्टम मॉडेलमधील संबंध, सिस्टम वर्तन गतिशीलता आणि सॉफ्टवेअर आर्किटेक्चर यांचे वर्णन करण्यासाठी आकृती किंवा मजकूराच्या रूपात वैशिष्ट्यांचा वापर करून संरचनात्मक किंवा ऑब्जेक्ट-देणारं विश्लेषण आणि डिझाइन पद्धतींवर आधारित आहेत.

1. कॅस्केड (eng. धबधबा) - मानक विकास मॉडेल

कॅस्केड डेव्हलपमेंट मॉडेल हे एक मॉडेल आहे ज्यामध्ये विकासाचे सर्व टप्पे अनुक्रमे चालवले जातात - मागील पूर्ण पूर्ण झाल्यानंतर पुढील टप्पा सुरू होतो.

या मॉडेलमध्ये सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेचे खालील टप्पे समाविष्ट आहेत:

सर्व प्रथम, भविष्यातील प्रोग्रामचे तांत्रिक मापदंड निर्धारित केले जातात आणि परिणामी, सॉफ्टवेअर आवश्यकतांची सूची मंजूर केली जाते. पुढे डिझाइनमध्ये संक्रमण होते, ज्या दरम्यान दस्तऐवजीकरण तयार केले जाते जे प्रोग्रामरसाठी आवश्यकता लागू करण्यासाठी योजना आणि पद्धतीचे वर्णन करते.

डिझाइन पूर्ण झाल्यानंतर, प्रोग्रामर प्रकल्पाची अंमलबजावणी (बांधकाम) करतात. अंमलबजावणीच्या टप्प्यावर, प्रकल्पाच्या सर्व घटकांचे एकत्रीकरण होते. हे टप्पे पूर्णपणे पूर्ण झाल्यानंतरच तयार उत्पादनाची चाचणी आणि डीबग केले जाते. पुढे, सॉफ्टवेअर उत्पादन लागू केले जाऊ शकते आणि, अंमलबजावणीनंतर, समर्थन प्रदान केले जाऊ शकते - नवीन कार्यक्षमता सादर करणे आणि त्रुटी दूर करणे.

धबधब्याच्या विकासाचे मुख्य फायदे:

2. चपळ सॉफ्टवेअर विकास पद्धत

सॉफ्टवेअर डेव्हलपमेंट पद्धतींची एक श्रेणी ज्यामध्ये ग्राहक प्रतिनिधी आणि विकासक यांच्यातील सहयोगाचा समावेश आहे. लवचिक विकास पद्धतीचा आधार एक पुनरावृत्तीचा दृष्टीकोन आहे, आवश्यकतांची गतिशील निर्मिती आणि लहान टप्प्यात त्यांची अंमलबजावणी.

पुनरावृत्तीच्या चक्रासह अशा प्रत्येक टप्प्याचा परिणाम हा एक विशिष्ट लघु सॉफ्टवेअर प्रकल्प आहे,

अनेक चपळ विकास पद्धती आहेत, सर्वात सुप्रसिद्ध आहेत Scrum, अत्यंत प्रोग्रामिंग, DSDM.

चपळ विकासाचे मुख्य फायदे:

चपळ विकासाची तत्त्वे:

तर, ईआयएस सॉफ्टवेअर डेव्हलपमेंटच्या स्ट्रक्चरल पध्दतीचे सार स्वयंचलित फंक्शन्समध्ये त्याचे विघटन (विघटन) मध्ये आहे: सिस्टम फंक्शनल सबसिस्टममध्ये विभागली गेली आहे, जी यामधून, सबफंक्शन्समध्ये विभागली गेली आहे, ती कार्यांमध्ये विभागली गेली आहे आणि पुढे विशिष्ट प्रक्रिया. त्याच वेळी, सिस्टम एक समग्र दृश्य राखते ज्यामध्ये सर्व घटक एकमेकांशी जोडलेले असतात. सिस्टम “बॉटम-अप” विकसित करताना, वैयक्तिक कार्यांपासून संपूर्ण सिस्टमपर्यंत, अखंडता गमावली जाते आणि वैयक्तिक घटकांच्या माहितीच्या परस्परसंवादाचे वर्णन करताना समस्या उद्भवतात.

संरचनात्मक दृष्टिकोनाच्या सर्व सामान्य पद्धती अनेक सामान्य तत्त्वांवर आधारित आहेत:

1. "विभाजित करा आणि जिंका" हे तत्त्व;

2. श्रेणीबद्ध क्रमाचे तत्त्व म्हणजे प्रत्येक स्तरावर नवीन तपशील जोडून श्रेणीबद्ध वृक्ष रचनांमध्ये प्रणालीचे घटक आयोजित करण्याचे तत्त्व.

दोन मूलभूत तत्त्वे वेगळे करणे याचा अर्थ असा नाही की उर्वरित तत्त्वे दुय्यम आहेत, कारण त्यापैकी कोणत्याहीकडे दुर्लक्ष केल्याने अप्रत्याशित परिणाम होऊ शकतात (संपूर्ण प्रकल्पाच्या अपयशासह"). या तत्त्वांपैकी मुख्य आहेत:

1. अमूर्ततेचे तत्त्व - प्रणालीच्या आवश्यक पैलूंवर प्रकाश टाकणे आणि बिनमहत्त्वाच्या गोष्टींपासून अमूर्त काढणे.

2. सिस्टम घटकांची सुसंगतता, वैधता आणि सुसंगततेचे सिद्धांत.

3. डेटा स्ट्रक्चरिंगचे तत्त्व - डेटा संरचित आणि श्रेणीबद्धपणे व्यवस्थित असणे आवश्यक आहे.

स्ट्रक्चरल पध्दतीमध्ये, साधनांचे मुख्यतः दोन गट आहेत जे सिस्टमची कार्यात्मक रचना आणि डेटामधील संबंधांचे वर्णन करतात. साधनांचा प्रत्येक गट विशिष्ट प्रकारच्या मॉडेल्स (आकृती) शी संबंधित आहे, त्यापैकी सर्वात सामान्य आहेत:

· DFD (डेटा फ्लो डायग्राम) - डेटा फ्लो डायग्राम;

· SADT (संरचित विश्लेषण आणि डिझाइन तंत्र - संरचनात्मक विश्लेषण आणि डिझाइनची कार्यपद्धती) - मॉडेल आणि संबंधित कार्यात्मक आकृत्या: नोटेशन्स IDEF0 (प्रणालींचे कार्यात्मक मॉडेलिंग), IDEF1х (डेटाबेसचे संकल्पनात्मक मॉडेलिंग), IDEF3х (गुणवत्तेच्या मूल्यांकनासाठी सिस्टमचे बांधकाम ऑब्जेक्टचे कार्य; प्रवाह प्रक्रियेचे ग्राफिकल वर्णन, प्रक्रिया आणि या प्रक्रियेद्वारे बदललेल्या वस्तूंचा परस्परसंवाद);

· ईआरडी (एंटिटी - रिलेशनशिप डायग्राम्स) - एंटिटी-रिलेशनशिप डायग्राम्स.

सॉफ्टवेअर आवश्यकता तयार करण्याच्या टप्प्यावर संरचनात्मक दृष्टिकोन (स्ट्रक्चरल विश्लेषण) च्या जवळजवळ सर्व पद्धती मॉडेलिंग साधनांचे दोन गट वापरतात:

1. प्रणालीने केलेली कार्ये आणि या फंक्शन्स - DFD किंवा SADT (IDEF0) मधील संबंध स्पष्ट करणारे आकृती.

2. आकृत्या जे मॉडेल डेटा आणि त्यांचे संबंध (ERD).

सूचीबद्ध आकृत्यांचे विशिष्ट स्वरूप आणि त्यांच्या डिझाइनचे स्पष्टीकरण सॉफ्टवेअर जीवन चक्राच्या टप्प्यावर अवलंबून असते.

सॉफ्टवेअर आवश्यकता तयार करण्याच्या टप्प्यावर, SADT मॉडेल आणि DFD चा वापर “AS-IS” मॉडेल आणि “TO-BE” मॉडेल तयार करण्यासाठी केला जातो, अशा प्रकारे संस्थेच्या व्यवसाय प्रक्रियेची विद्यमान आणि प्रस्तावित रचना आणि त्यांच्यातील परस्परसंवाद प्रतिबिंबित करते ( एसएडीटी मॉडेल्सचा वापर सामान्यतः या स्टेजपुरताच मर्यादित असतो, कारण ते मूळत: सॉफ्टवेअर डिझाइनसाठी नव्हते). ERD च्या मदतीने, डेटाबेस अंमलबजावणी साधने (DBMS) विचारात न घेता, संस्थेमध्ये वापरल्या जाणाऱ्या डेटाचे वर्णन संकल्पनात्मक स्तरावर केले जाते.

1.कोडिंग

सॉफ्टवेअर डेव्हलपमेंट स्टेजवर, खालील मुख्य क्रिया केल्या जातात: कोडिंग; चाचणी पीपी मदत प्रणालीचा विकास; वापरकर्ता दस्तऐवजीकरण तयार करणे; सॉफ्टवेअरची आवृत्ती तयार करणे आणि स्थापित करणे,

कोडिंग ही उच्च-स्तरीय आणि निम्न-स्तरीय डिझाइन परिणामांना तयार सॉफ्टवेअर उत्पादनामध्ये रूपांतरित करण्याची प्रक्रिया आहे. दुसऱ्या शब्दांत, कोडिंग करताना, संकलित सॉफ्टवेअर मॉडेलचे वर्णन निवडलेल्या प्रोग्रामिंग भाषा वापरून केले जाते, जी विद्यमान भाषांपैकी कोणतीही असू शकते. भाषेची निवड एकतर ग्राहकाच्या विनंतीनुसार केली जाते किंवा समस्या सोडवली जात आहे आणि विकसकांचा वैयक्तिक अनुभव लक्षात घेऊन केला जातो.

कोडिंग करताना, तुम्ही निवडलेल्या भाषेसाठी मानकांचे पालन केले पाहिजे, उदाहरणार्थ, C भाषेसाठी ते ANSI C आहे आणि C++ साठी ते ISO/IEC 14882 “C++ Programming Language साठी मानक” आहे.

प्रोग्रामिंग भाषेसाठी सामान्यतः स्वीकारल्या जाणाऱ्या मानकांव्यतिरिक्त, कंपनी प्रोग्राम लिहिण्याच्या नियमांसाठी स्वतःच्या अतिरिक्त आवश्यकता देखील विकसित करू शकते. ते प्रामुख्याने प्रोग्राम मजकूर स्वरूपित करण्याच्या नियमांशी संबंधित आहेत.

मानक आणि कंपनीच्या नियमांचे पालन केल्याने तुम्हाला योग्यरीत्या काम करणारा, वाचायला सोपा आणि इतर विकासकांना समजेल असा प्रोग्राम तयार करता येतो, ज्यामध्ये डेव्हलपरची माहिती, निर्मितीची तारीख, नाव आणि उद्देश तसेच कॉन्फिगरेशन व्यवस्थापनासाठी आवश्यक डेटा असतो.

कोडिंग टप्प्यावर, प्रोग्रामर प्रोग्राम लिहितो आणि त्यांची स्वतः चाचणी करतो. या प्रकारच्या चाचणीला युनिट चाचणी म्हणतात. सॉफ्टवेअर चाचणीशी संबंधित सर्व मुद्द्यांची चर्चा प्रकरणामध्ये केली आहे. 10, सॉफ्टवेअर डेव्हलपमेंट स्टेजवर वापरले जाणारे चाचणी तंत्रज्ञान देखील येथे वर्णन केले आहे. या तंत्रज्ञानाला चाचणी म्हणतात "ग्लास बॉक्स" (ग्लासबॉक्स);कधीकधी याला चाचणी देखील म्हणतात "व्हाइट बॉक्स" (व्हाइटबॉक्स)"ब्लॅक बॉक्स" च्या शास्त्रीय संकल्पनेच्या विरोधात.

ब्लॅक बॉक्स चाचणीमध्ये, प्रोग्रामला एक ऑब्जेक्ट मानले जाते ज्याची अंतर्गत रचना अज्ञात आहे. परीक्षक डेटा प्रविष्ट करतो आणि निकालाचे विश्लेषण करतो, परंतु प्रोग्राम कसा कार्य करतो हे त्याला माहित नसते. चाचण्या निवडताना, एक विशेषज्ञ त्याच्या दृष्टिकोनातून मनोरंजक इनपुट डेटा आणि परिस्थिती शोधतो, ज्यामुळे गैर-मानक परिणाम होऊ शकतात. त्याला प्रामुख्याने इनपुट डेटाच्या प्रत्येक वर्गाच्या त्या प्रतिनिधींमध्ये स्वारस्य आहे ज्यामध्ये चाचणी अंतर्गत प्रोग्राममध्ये त्रुटी होण्याची शक्यता असते.

“ग्लास बॉक्स” ची चाचणी करताना परिस्थिती पूर्णपणे वेगळी असते. परीक्षक (या प्रकरणात प्रोग्रामर स्वतः) स्त्रोत कोडच्या ज्ञानावर आधारित चाचण्या विकसित करतो, ज्यामध्ये त्याला पूर्ण प्रवेश असतो. परिणामी, त्याला खालील फायदे मिळतात.

1. चाचणीची दिशा. प्रोग्रामर प्रोग्रामची भागांमध्ये चाचणी करू शकतो, विशेष चाचणी सबरूटीन विकसित करू शकतो जे चाचणी अंतर्गत मॉड्यूल कॉल करतात आणि प्रोग्रामरला स्वारस्य असलेला डेटा प्रसारित करतात. “ग्लास बॉक्स” म्हणून वेगळ्या मॉड्यूलची चाचणी करणे खूप सोपे आहे.

2.संपूर्ण कोड कव्हरेज. प्रत्येक चाचणीमध्ये कोणते कोडचे तुकडे काम करतात हे प्रोग्रामर नेहमी ठरवू शकतो. कोडच्या इतर कोणत्या शाखा तपासल्या गेल्या नाहीत हे तो पाहतो आणि कोणत्या परिस्थितीत त्यांची चाचणी केली जाईल ते निवडू शकतो. केलेल्या चाचण्यांच्या कोड कव्हरेजच्या डिग्रीचा मागोवा कसा घ्यावा हे आम्ही खाली वर्णन करतो.

3. आदेशांचा प्रवाह नियंत्रित करण्याची क्षमता. प्रोग्रामरला नेहमी माहित असते की प्रोग्राममध्ये पुढे कोणते फंक्शन कार्यान्वित केले पाहिजे आणि त्याची वर्तमान स्थिती काय असावी. एखादा प्रोग्राम त्याच्या विचारानुसार कार्य करतो की नाही हे शोधण्यासाठी, प्रोग्रामर त्याच्या प्रगतीबद्दल माहिती प्रदर्शित करणाऱ्या डीबगिंग कमांड समाविष्ट करू शकतो किंवा हे करण्यासाठी डीबगर नावाचे विशेष सॉफ्टवेअर टूल वापरू शकतो. डीबगर बऱ्याच उपयुक्त गोष्टी करू शकतो: प्रोग्राम कमांड्सच्या अंमलबजावणीचा क्रम निरीक्षण आणि बदलणे, त्याच्या व्हेरिएबल्सची सामग्री आणि मेमरीमधील त्यांचे पत्ते इ.

4. डेटा अखंडतेचे निरीक्षण करण्याची क्षमता. प्रोग्रामरला माहित असते की प्रोग्रामचा कोणता भाग प्रत्येक डेटा घटक बदलला पाहिजे. डेटाच्या स्थितीचे निरीक्षण करून (त्याच डीबगरचा वापर करून), तो चुकीच्या मॉड्यूल्सद्वारे डेटा बदलला जाणे, त्यांची चुकीची व्याख्या किंवा अयशस्वी संस्था यासारख्या त्रुटी ओळखू शकतो. प्रोग्रामर स्वतः चाचणी स्वयंचलित करू शकतो.

5. अंतर्गत सीमा बिंदूंची दृष्टी. स्त्रोत कोडमध्ये, प्रोग्रामचे ते सीमा बिंदू जे बाहेरील दृश्यापासून लपलेले आहेत ते दृश्यमान आहेत. उदाहरणार्थ, विशिष्ट क्रिया करण्यासाठी अनेक पूर्णपणे भिन्न अल्गोरिदम वापरले जाऊ शकतात आणि कोड न पाहता, प्रोग्रामरने कोणता निवडला हे निर्धारित करणे अशक्य आहे. दुसरे सामान्य उदाहरण म्हणजे तात्पुरते इनपुट डेटा संचयित करण्यासाठी वापरल्या जाणाऱ्या बफरमधील ओव्हरफ्लो समस्या. प्रोग्रामर लगेच सांगू शकतो की बफर किती प्रमाणात डेटा ओव्हरफ्लो करेल आणि त्याला हजारो चाचण्या घेण्याची आवश्यकता नाही.

6. निवडलेल्या अल्गोरिदमद्वारे निर्धारित चाचणीची शक्यता. अत्यंत क्लिष्ट संगणकीय अल्गोरिदम वापरणाऱ्या डेटा प्रोसेसिंगच्या चाचणीसाठी विशेष तंत्रज्ञानाची आवश्यकता असू शकते. उत्कृष्ट उदाहरणांमध्ये मॅट्रिक्स ट्रान्सफॉर्मेशन आणि डेटा सॉर्टिंग समाविष्ट आहे. परीक्षक, प्रोग्रामरच्या विपरीत, कोणते अल्गोरिदम वापरले जातात हे माहित असणे आवश्यक आहे, म्हणून त्याला विशेष साहित्याकडे वळावे लागेल.

ग्लास बॉक्स चाचणी हा प्रोग्रामिंग प्रक्रियेचा एक भाग आहे. प्रोग्रामर हे काम सतत करतात, ते लिहिल्यानंतर प्रत्येक मॉड्यूलची चाचणी घेतात आणि नंतर पुन्हा सिस्टममध्ये समाकलित केल्यानंतर.

युनिट चाचणी करत असताना, तुम्ही स्ट्रक्चरल किंवा फंक्शनल टेस्टिंग टेक्नॉलॉजी किंवा दोन्ही वापरू शकता.

स्ट्रक्चरलचाचणी हा एक प्रकारचा ग्लास बॉक्स चाचणी आहे. चाचणीसाठी सॉफ्टवेअर मार्गाची योग्य निवड ही त्याची मुख्य कल्पना आहे. त्याच्या विरुद्ध कार्यशीलचाचणी ब्लॅक बॉक्स चाचणीच्या श्रेणीत येते. प्रत्येक प्रोग्राम फंक्शनचा इनपुट डेटा प्रविष्ट करून आणि त्याच्या आउटपुटचे विश्लेषण करून चाचणी केली जाते. त्याच वेळी, प्रोग्रामची अंतर्गत रचना फारच क्वचितच विचारात घेतली जाते.

जरी स्ट्रक्चरल चाचणीचा सैद्धांतिक आधार अधिक मजबूत असला तरी, बहुतेक परीक्षक कार्यात्मक चाचणीला प्राधान्य देतात. स्ट्रक्चरल चाचणी स्वतःला गणितीय मॉडेलिंगसाठी अधिक चांगले देते, परंतु याचा अर्थ असा नाही की ते अधिक प्रभावी आहे. प्रत्येक तंत्रज्ञान आपल्याला इतर वापरताना चुकलेल्या त्रुटी ओळखण्याची परवानगी देते. या दृष्टिकोनातून, त्यांना तितकेच प्रभावी म्हटले जाऊ शकते.

चाचणीचा उद्देश केवळ प्रोग्रामचा संपूर्ण मार्गच नाही तर (सुरुवातीपासून शेवटपर्यंत कार्यान्वित केलेल्या आदेशांचा क्रम), परंतु त्याचे वैयक्तिक विभाग देखील असू शकतात. प्रोग्राम कार्यान्वित करण्याच्या सर्व संभाव्य मार्गांची चाचणी घेणे पूर्णपणे अवास्तव आहे. म्हणून, चाचणी विशेषज्ञ सर्व संभाव्य मार्गांमधून ते गट ओळखतात ज्यांची पूर्णपणे चाचणी करणे आवश्यक आहे. निवडीसाठी ते म्हणतात विशेष निकष वापरतात कव्हरेज निकष (कव्हरेज निकष),जे खूप खऱ्या (अगदी मोठ्या प्रमाणात) चाचण्या ठरवतात. हे निकष कधीकधी म्हणतात तार्किक कव्हरेज निकष,किंवा पूर्णता निकष.

3. सॉफ्टवेअर उत्पादनासाठी मदत प्रणालीचा विकास. वापरकर्ता दस्तऐवजीकरण तयार करणे

प्रकल्प कर्मचाऱ्यांपैकी एकाला कागदपत्रांचे तांत्रिक संपादक म्हणून नियुक्त करणे उचित आहे. हा कर्मचारी इतर काम देखील करू शकतो, परंतु त्याचे मुख्य कार्य कागदपत्रांचे विश्लेषण असले पाहिजे, जरी इतर कर्मचारी देखील ते विकसित करत असले तरीही.

असे बऱ्याचदा घडते की बरेच लोक सॉफ्टवेअरच्या निर्मितीवर काम करतात, परंतु त्यापैकी कोणीही त्याच्या गुणवत्तेची संपूर्ण जबाबदारी घेत नाही. परिणामी, सॉफ्टवेअरला केवळ अधिक लोकांद्वारे विकसित केल्याचा फायदा होत नाही तर तोटा देखील होतो, कारण प्रत्येक अवचेतनपणे जबाबदारी दुसऱ्यावर हलवतो आणि अपेक्षा करतो की त्याचे सहकारी हे किंवा ते काम करतील. तांत्रिक दस्तऐवजाच्या गुणवत्तेची आणि अचूकतेची संपूर्ण जबाबदारी असलेल्या संपादकाची नियुक्ती करून ही समस्या सोडवली जाते.

पीपी मदत प्रणाली वापरकर्त्याच्या मॅन्युअलसाठी विकसित केलेल्या सामग्रीच्या आधारे तयार केली जाते. हे कार्य करण्यासाठी जबाबदार असलेल्या व्यक्तीद्वारे ते तयार आणि तयार केले जाते. हे एकतर तांत्रिक संपादक किंवा तांत्रिक संपादकासह विकसकांपैकी एक असू शकते.

चांगल्या-दस्तऐवजीकरण केलेल्या पीपीचे खालील फायदे आहेत.

1. वापरणी सोपी. जर सॉफ्टवेअर चांगले दस्तऐवजीकरण केले असेल तर ते लागू करणे खूप सोपे आहे. वापरकर्ते ते जलद शिकतात, कमी चुका करतात आणि परिणामी त्यांचे काम जलद आणि अधिक कार्यक्षमतेने करतात.

2. तांत्रिक समर्थनाची कमी किंमत. जेव्हा वापरकर्ता त्याला आवश्यक असलेल्या क्रिया कशा करायच्या हे समजू शकत नाही, तेव्हा तो PCB निर्मात्याच्या तांत्रिक समर्थन सेवेला कॉल करतो. अशी सेवा चालवणे खूप महाग आहे. एक चांगली मॅन्युअल वापरकर्त्यांना त्यांच्या स्वतःच्या समस्या सोडवण्यास आणि तांत्रिक समर्थन कार्यसंघाशी संपर्क साधण्याची आवश्यकता कमी करण्यात मदत करते.

3. उच्च विश्वसनीयता. न समजण्याजोगे किंवा ढिसाळ दस्तऐवजीकरण सॉफ्टवेअरला कमी विश्वासार्ह बनवते, कारण त्याच्या वापरकर्त्यांना चुका होण्याची अधिक शक्यता असते आणि त्या कशामुळे झाल्या आणि त्यांच्या परिणामांना कसे सामोरे जावे हे समजणे कठीण जाते.

देखभाल सोपी. वापरकर्त्याच्या त्रुटींमुळे उद्भवलेल्या समस्यांचे विश्लेषण करण्यासाठी मोठ्या प्रमाणात पैसा आणि वेळ खर्च केला जातो. नवीन सॉफ्टवेअर रिलीझमध्ये केलेले बदल हे सहसा जुन्या फंक्शन्सच्या इंटरफेसमध्ये बदल असतात. ते सादर केले जातात जेणेकरून वापरकर्त्यांना शेवटी सॉफ्टवेअर कसे वापरायचे आणि तांत्रिक समर्थनावर कॉल करणे थांबवायचे. बऱ्याच प्रमाणात चांगले व्यवस्थापन