सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया (eng. सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया, सॉफ्टवेअर प्रक्रिया) - रचना ज्यानुसार सॉफ्टवेअर विकास तयार केला जातो.
अशा प्रक्रियेची अनेक मॉडेल्स आहेत (सॉफ्टवेअर डेव्हलपमेंट पद्धती), ज्यापैकी प्रत्येक प्रक्रियेदरम्यान होणार्‍या कार्ये आणि / किंवा क्रियाकलापांच्या रूपात स्वतःच्या दृष्टिकोनाचे वर्णन करते.

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

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

  DPGgroup द्वारे वापरलेल्या पुनरावृत्ती सॉफ्टवेअर विकास पद्धती:

  • तर्कसंगत युनिफाइड प्रक्रिया(RUP) ही रॅशनल सॉफ्टवेअरद्वारे तयार केलेली सॉफ्टवेअर डेव्हलपमेंट पद्धत आहे.
    

    RUP खालील मूलभूत तत्त्वांवर आधारित आहे:

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

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

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

सॉफ्टवेअर अभियांत्रिकीच्या विकासाच्या 50 वर्षांपेक्षा जास्त, मोठ्या संख्येने सॉफ्टवेअर विकास मॉडेल. विमानांसाठी स्वयंचलित नियंत्रण प्रणालींमध्ये वापरल्या जाणार्‍या पद्धतींच्या विकासाचा इतिहास आणि सॉफ्टवेअर प्रकल्प व्यवस्थापित करण्याच्या दृष्टीकोनांची उत्क्रांती यांच्यात एक साधर्म्य काढणे मनोरंजक आहे.

"ते कसे होते ते आपण पाहू".ओपन लूप कंट्रोल सिस्टम. तांत्रिक नेत्यांवर पूर्ण विश्वास. व्यवसाय प्रतिनिधी व्यावहारिकरित्या प्रकल्पात भाग घेत नाहीत. नियोजन, ते अस्तित्वात असल्यास, अनौपचारिक आणि मौखिक आहे. वेळ आणि बजेट हे सहसा नियंत्रित नसते. सादृश्य: अभिप्रायाशिवाय बॅलिस्टिक फ्लाइट. हे शक्य आहे, परंतु बंद आणि चुकीचे आहे.

"धबधबा"किंवा धबधबा मॉडेल. कठोर अभिप्राय नियंत्रण. संदर्भ मार्गाची गणना (प्रकल्प योजना), विचलनांचे मोजमाप, दुरुस्ती आणि संदर्भ मार्गावर परत जा. चांगले, परंतु कार्यक्षम नाही.

"लवचिक व्यवस्थापन".संदर्भ मार्गाची गणना, विचलनांचे मोजमाप, नवीन येणार्‍या मार्गाची गणना आणि त्यापर्यंत पोहोचण्यासाठी सुधारणा. "योजना काहीही नाही, नियोजन सर्वकाही आहे" (आयझेनहॉवर, ड्वाइट डेव्हिड)

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

शास्त्रीय नियंत्रण पद्धती अशा प्रकरणांमध्ये कार्य करणे थांबवतात जेथे व्यवस्थापित ऑब्जेक्टची रचना आणि गुणधर्म आपल्याला माहित नसतात आणि / किंवा कालांतराने बदलतात. जर ऑब्जेक्टचे वर्तमान गुणधर्म आवश्यक वैशिष्ट्यांसह हलवू देत नसतील तर हे दृष्टिकोन देखील मदत करणार नाहीत. उदाहरणार्थ, विमान आवश्यक प्रवेग विकसित करू शकत नाही किंवा अस्वीकार्य ओव्हरलोडमुळे नष्ट होते. त्याचप्रमाणे, जर प्रकल्प कार्यसंघ आवश्यक कार्यक्षमता प्रदान करू शकत नाही आणि म्हणूनच आपत्कालीन स्थितीत सतत कार्य करत असेल, तर यामुळे उत्पादकता वाढू शकत नाही, परंतु प्रकल्पातून व्यावसायिकांना दूर जावे लागेल.

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

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

हे ज्ञात आहे की वेगवेगळ्या प्रोग्रामरची कामगिरी डझनभर वेळा भिन्न असू शकते. मी पुष्टी करतो की समान प्रोग्रामरचे कार्यप्रदर्शन देखील डझनभर वेळा भिन्न असू शकते. जगातील सर्वोत्तम धावपटूला गोत्यात टाका आणि तो 10 पट वाईट होईल. सर्वोत्कृष्ट प्रोग्रामरला "सिसिफियन लेबर" करण्यास भाग पाडा: "पद्धती" (म्हणजे भांडवल एम सह) साठी दस्तऐवज तयार करणे (जे नियमानुसार, कोणीही वाचत नाही) आणि त्याची उत्पादकता 10 पट कमी होईल.

म्हणूनच, पूर्णपणे व्यवस्थापकीय कार्यांव्यतिरिक्त, नेता, जर तो कार्य गटाची सर्वोच्च उत्पादकता प्राप्त करू इच्छित असेल, तर त्याने व्यवस्थापनाच्या उद्देशाचा अभ्यास आणि बदल करण्यासाठी सतत प्रयत्न केले पाहिजेत: लोक आणि त्यांचे परस्परसंवाद.

मॉडेल्स(किंवा, जसे त्यांना म्हणायचे आहे, पद्धत) सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया सामान्यतः "वजन" द्वारे वर्गीकृत केल्या जातात - औपचारिक प्रक्रियांची संख्या (बहुतेक प्रक्रिया किंवा फक्त मुख्य) आणि त्यांच्या नियमनाचे तपशील. जितक्या अधिक प्रक्रियांचे दस्तऐवजीकरण केले जाईल, त्यांचे अधिक तपशीलवार वर्णन केले जाईल, मॉडेलचे "वजन" जास्त असेल.

सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेचे सर्वात सामान्य आधुनिक मॉडेल अंजीर मध्ये दर्शविले आहेत. २.३.

तांदूळ. २.३. सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेचे वेगवेगळे मॉडेल

GOSTs

GOST 19 "युनिफाइड सिस्टम ऑफ सॉफ्टवेअर डॉक्युमेंटेशन" आणि GOST 34 "स्वयंचलित प्रणालींच्या विकासासाठी आणि देखभालीसाठी मानके" सॉफ्टवेअर विकासासाठी सातत्यपूर्ण दृष्टिकोनावर केंद्रित आहेत. या मानकांनुसार विकास टप्प्याटप्प्याने केला जातो, ज्यापैकी प्रत्येकामध्ये काटेकोरपणे परिभाषित केलेल्या कार्याचा समावेश असतो आणि बर्‍याच प्रमाणात औपचारिक आणि विस्तृत दस्तऐवजांच्या प्रकाशनासह समाप्त होते. अशाप्रकारे, या पाहुण्यांचे कठोर पालन केल्याने केवळ धबधब्याचा दृष्टीकोनच उद्भवत नाही, तर विकासाच्या औपचारिकतेची उच्च पातळी देखील आवश्यक आहे. या मानकांच्या आधारे, रशियामधील सरकारी आदेशांसाठी सॉफ्टवेअर प्रणाली विकसित केली जात आहे.

1980 च्या दशकाच्या मध्यात, यूएस डिपार्टमेंट ऑफ डिपार्टमेंटने मोठ्या प्रमाणावर सॉफ्टवेअर प्रकल्प राबवताना सॉफ्टवेअर डेव्हलपर कसे निवडायचे याबद्दल कठोर विचार करण्यास सुरुवात केली. लष्कराने कमिशन केलेल्या, कार्नेगी मेलॉन विद्यापीठाचा भाग असलेल्या सॉफ्टवेअर इंजिनिअरिंग इन्स्टिट्यूटने सॉफ्टवेअर डेव्हलपमेंट संस्थांसाठी संदर्भ मॉडेल म्हणून SW-CMM, सॉफ्टवेअरसाठी क्षमता परिपक्वता मॉडेल विकसित केले.

हे मॉडेल सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेच्या परिपक्वतेचे पाच स्तर परिभाषित करते.

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

2) पुनरावृत्ती करण्यायोग्य - मूलभूत प्रकल्प व्यवस्थापन प्रक्रिया स्थापित केल्या आहेत: ट्रॅकिंग खर्च, अंतिम मुदत आणि कार्यक्षमता. तत्सम प्रकल्पांवरील मागील यशांची प्रतिकृती तयार करण्यासाठी आवश्यक असलेल्या काही प्रक्रिया सुव्यवस्थित केल्या गेल्या आहेत.

3) परिभाषित - सॉफ्टवेअर डेव्हलपमेंट आणि प्रोजेक्ट मॅनेजमेंटच्या प्रक्रियांचे वर्णन आणि कंपनी प्रक्रियेच्या एकाच प्रणालीमध्ये अंमलबजावणी केली जाते. सर्व प्रकल्प विशिष्ट प्रकल्पासाठी तयार केलेल्या संस्थेच्या मानक सॉफ्टवेअर विकास आणि समर्थन प्रक्रियेचा वापर करतात.

4) व्यवस्थापित - विकास प्रक्रियांचे कार्य आणि अंतिम उत्पादनाच्या गुणवत्तेवर तपशीलवार परिमाणवाचक डेटा गोळा केला जातो. या डेटाचे महत्त्व आणि गतिशीलतेचे विश्लेषण केले जाते.

5) ऑप्टिमाइझ करण्यायोग्य - प्रक्रियांची सतत सुधारणा प्रक्रियांवरील परिमाणात्मक डेटा आणि नवीन कल्पना आणि तंत्रज्ञानाच्या चाचणी अंमलबजावणीवर आधारित आहे.

SW-CMM चे संपूर्ण दस्तऐवजीकरण सुमारे 500 पृष्ठांचे आहे आणि 312 आवश्यकतांचा संच परिभाषित करते ज्या एखाद्या संस्थेने परिपक्वता स्तर 5 वर या मानकासाठी पात्र ठरण्याची योजना आखल्यास ती पूर्ण करणे आवश्यक आहे.

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

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

इन्स्टिट्यूट ऑफ सॉफ्टवेअर इंजिनीअरिंग वैयक्तिक सॉफ्टवेअर प्रक्रिया / टीम सॉफ्टवेअर प्रक्रियेच्या नवीनतम विकासांपैकी एक. वैयक्तिक सॉफ्टवेअर प्रक्रिया विकसक सक्षमता आवश्यकता परिभाषित करते. या मॉडेलनुसार, प्रत्येक प्रोग्रामर सक्षम असावा:

प्रकल्पावर घालवलेला वेळ विचारात घ्या;

आढळलेले दोष विचारात घ्या;

दोषांचे प्रकार वर्गीकृत करा;

कार्याच्या आकाराचा अंदाज लावा;

· चाचणी परिणामांच्या वर्णनासाठी पद्धतशीर दृष्टीकोन अमलात आणणे;

योजना कार्यक्रम कार्ये;

त्यांना वेळेनुसार वितरित करा आणि कामाचे वेळापत्रक तयार करा.

वैयक्तिक डिझाइन आणि आर्किटेक्चर पुनरावलोकने करा;

वैयक्तिक कोड तपासणी करा;

रीग्रेशन चाचणी करा.

टीम सॉफ्टवेअर प्रक्रिया 3-20 विकासकांच्या स्वयं-व्यवस्थापित संघांवर अवलंबून असते. संघांनी हे करणे आवश्यक आहे:

आपले स्वतःचे ध्येय सेट करा;

· तुमची स्वतःची प्रक्रिया आणि योजना बनवा;

ट्रॅक काम;

प्रेरणा आणि शिखर कामगिरी कायम ठेवा.

पीएसपी/टीएसपी मॉडेलचा सातत्यपूर्ण वापर तुम्हाला संस्थेमध्ये सीएमएमचा पाचवा स्तर आदर्श बनविण्याची परवानगी देतो.

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

प्रक्रिया मॉडेल निवड

उत्पादन प्रक्रियेच्या जड आणि हलक्या मॉडेल्समध्ये त्यांचे फायदे आणि तोटे आहेत, जे टेबलमध्ये सादर केले आहेत. २.१.

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

तक्ता 2.1

सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेच्या जड आणि हलक्या मॉडेल्सचे फायदे आणि तोटे

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

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

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

प्रत्येक प्रकल्पाचे स्वतःचे विकास प्रक्रिया मॉडेल असावे.

प्रत्येक मॉडेलची वेळ असते.

याचा अर्थ असा आहे की कोणतीही एकच योग्य सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया नाही, प्रत्येक नवीन प्रकल्पामध्ये "4 Ps च्या कायद्या" (चित्र 2.4) नुसार, प्रकल्प, उत्पादन आणि कर्मचारी यांच्या आधारावर प्रक्रिया प्रत्येक वेळी नवीनपणे परिभाषित करणे आवश्यक आहे. 5 लोकांसह प्रकल्प आणि 500 ​​लोक असलेल्या प्रकल्पांमध्ये पूर्णपणे भिन्न प्रक्रिया लागू केल्या पाहिजेत. जर प्रकल्प उत्पादन गंभीर सॉफ्टवेअर असेल, उदाहरणार्थ, अणुऊर्जा प्रकल्प नियंत्रण प्रणाली, तर विकास प्रक्रिया साइटच्या विकासापेक्षा खूप वेगळी असावी, उदाहरणार्थ, साइट “otdokhni.ru”. आणि, शेवटी, कालच्या विद्यार्थ्यांच्या टीममध्ये आणि कुशल व्यावसायिकांच्या टीममध्ये विकास प्रक्रिया वेगळ्या पद्धतीने आयोजित केली पाहिजे.

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

तांदूळ. २.४. "4 Ps चा कायदा". प्रकल्पातील प्रक्रिया प्रकल्प, उत्पादन आणि कर्मचारी यांच्या आधारावर परिभाषित केली पाहिजे

अलिकडच्या वर्षांत अनुभवाच्या संचयनामुळे विकसित झालेल्या विकास प्रक्रियेचे विहंगावलोकन देण्याआधी, मी काही सामान्य स्पष्टीकरण देऊ इच्छितो जे मला आवश्यक वाटतात.

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

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

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

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

फर्मवेअर हार्डवेअरसह येते आणि ढोबळपणे बोलायचे तर, अप्रत्याशित आहे, कारण निर्मात्याकडून डिव्हाइसेसची बॅच परत मागवणे खूप महाग आहे आणि म्हणून अपवादात्मक आहे.

गेम हिट्सच्या विकासामध्ये देखील व्यावहारिकरित्या सोबतचा टप्पा नसतो. याव्यतिरिक्त, गेमिंग प्रोग्रामचे वापरकर्ते, गेममध्ये त्रुटी असतानाही, अगदी क्वचितच अद्यतनित आवृत्ती डाउनलोड करतात. म्हणून, गेम डेव्हलपमेंट, एक नियम म्हणून, स्वतःची अर्थव्यवस्था आणि स्वतःची विकास प्रक्रिया आहे.

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

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

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

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

हे समजून घेणे महत्त्वाचे आहे की प्रक्रियेच्या एका टप्प्यातून दुसर्या टप्प्यात संक्रमणास स्पष्ट सीमा नाही. नियमानुसार, मागील टप्प्यावरील 80-90% काम पूर्ण झाल्यामुळे पुढील टप्प्याचे काम सुरू होते. हे विशेषतः आवश्यकतांच्या विकासासाठी सत्य आहे, जेव्हा काही प्रकरणांमध्ये अनिश्चितता काढून टाकणे केवळ प्रकल्पाच्या शेवटी होते. अर्थात, प्रकल्पामध्ये अशा अनिश्चिततेची उपस्थिती हा एक महत्त्वपूर्ण धोका आहे आणि तो सतत नियंत्रणात असावा.

सानुकूल सॉफ्टवेअर विकास प्रक्रिया

सर्वात सामान्य प्रकरणासह विकास प्रक्रियेचे पुनरावलोकन सुरू करूया - सानुकूल सॉफ्टवेअरचा विकास. प्रक्रिया आकृती आकृती 1 मध्ये दर्शविली आहे.

आकृती 1. सानुकूल सॉफ्टवेअर विकास प्रक्रिया.

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

ज्याची संकल्पना दावा न केलेली किंवा अवास्तव म्हणून ओळखली जाते अशा प्रकल्पावर वेळ आणि संसाधने वाया घालवण्याची गरज नाही. हा प्रकल्प पूर्ण झाला पाहिजे. काही प्रकरणांमध्ये, प्रकल्पाची संकल्पना दुरुस्त करण्यासाठी ग्राहकासोबत काही पुनरावृत्तीचे काम करणे आवश्यक आहे, जोपर्यंत ग्राहकाच्या गरजा आणि कंत्राटदाराच्या खर्चाचा स्वीकार्य समतोल गाठला जात नाही किंवा काम कमी करण्याचा निर्णय घेतला जात नाही.

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

कधीकधी आवश्यकतांचे स्पष्टीकरण प्रकल्प संकल्पनेचे पुनरावृत्ती होते. जर, सर्व आवश्यकता स्पष्ट केल्यानंतर, स्वीकार्य तांत्रिक उपाय शोधणे शक्य नसेल, तर अधिक स्वीकारार्ह परिस्थितीच्या अपेक्षेने प्रकल्प कमी करावा किंवा काही काळ पुढे ढकलावा लागेल.

तांत्रिक उपाय सापडल्यास, कलाकार भविष्यातील प्रणालीचे आर्किटेक्चर विकसित करण्यासाठी पुढे जातो. स्टेजचा उद्देश उच्च-स्तरीय तार्किक आणि भौतिक आर्किटेक्चर परिभाषित करणे आहे जे ग्राहकांच्या सर्व आवश्यकता पूर्णतः कव्हर करते. आर्किटेक्चर विकसित करताना, संकल्पना, आवश्यकता आणि प्राथमिक तांत्रिक उपायांचे पुनरावलोकन केले जाते आणि परिष्कृत केले जाते, ज्यामुळे सर्वात धोकादायक धोके टाळणे शक्य होते.

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

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

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

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

कोणताही प्रकल्प शेवटी संपतो. प्रकल्प संपुष्टात येण्याच्या टप्प्याचे उद्दिष्ट आहे परिणामांचे विश्लेषण करणे, मिळालेल्या अनुभवाच्या आधारे विकास प्रक्रियेत बदल करणे आणि विकासक ज्ञानाचा आधार नवीन प्रभावी उपाय आणि सावधांसह भरून काढणे, तसेच नवीन ऑफ-द-शेल्फ घटक ज्यांचा वापर केला जाऊ शकतो. भविष्यातील प्रकल्प.

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

गुंतवणूक सॉफ्टवेअर विकास प्रक्रिया

गुंतवणूक सॉफ्टवेअर विकसित करण्याची प्रक्रिया भिन्न आहे कारण एकाच वेळी उत्पादनाच्या अनेक आवृत्त्यांवर कार्य एकाच वेळी चालू शकते: पहिल्या आवृत्तीची देखभाल केली जात असताना, दुसरी आधीपासूनच लागू केली जात आहे आणि तिसऱ्यासाठी आवश्यकता तयार केल्या जात आहेत. प्रक्रिया आकृती 2 मध्ये दर्शविली आहे.

आकृती 2. गुंतवणूक सॉफ्टवेअर विकास प्रक्रिया.

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

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

याव्यतिरिक्त, आर्किटेक्चरच्या विकासानंतर, नियमानुसार, प्रकल्पाच्या विश्लेषक आणि आर्किटेक्ट्सना काही कृती स्वातंत्र्य असते, कारण वितरण टप्प्यात मुख्य भार प्रोग्रामरवर पडतो. हे स्वातंत्र्य पुढील आवृत्तीसाठी संकल्पना आणि आवश्यकता पूर्ण करण्यासाठी वापरले जाऊ शकते.

तत्वतः, आपण पुढील आवृत्तीवर कामाची सुरूवात नंतरच्या तारखेपर्यंत पुढे ढकलू शकता. उदाहरणार्थ, प्रायोगिक किंवा अगदी व्यावसायिक ऑपरेशनमध्ये प्रथम वर्तमान आवृत्ती प्रविष्ट करणे अगदी स्वीकार्य आहे आणि त्यानंतरच पुढील आवृत्तीवर कार्य सुरू करा. परंतु आपल्याला हे लक्षात ठेवणे आवश्यक आहे की उच्च स्पर्धेच्या बाबतीत असा उपाय लागू होत नाही: ते फक्त तुमच्या पुढे येतील आणि तुम्हाला बाजारातून बाहेर काढतील. तुमच्‍या व्‍यवसायावर परिणाम करणार्‍या परिस्थितीच्‍या संपूर्ण श्रेणीच्‍या आधारावर निर्णय घेणे आवश्‍यक आहे.

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

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

दुसरे म्हणजे, अनेक आवृत्त्यांवर समांतर कामासाठी, कोड आणि दस्तऐवजीकरण आवृत्ती नियंत्रण, नोकरी आणि विसंगती नियंत्रण, स्वयंचलित बिल्ड आणि चाचणी उपयुक्तता इत्यादीसह एक विशेष प्रकल्प पायाभूत सुविधा आवश्यक आहे. उत्पादनाच्या एका आवृत्तीवर काम करताना इतर आवृत्त्यांवर कार्यांची अंमलबजावणी अवरोधित करण्याची परवानगी दिली जाऊ नये कारण प्रकल्प पायाभूत सुविधा उत्पादनाच्या भिन्न आवृत्त्यांसाठी एकाच वेळी दोन बिल्ड प्रक्रिया चालविण्यास परवानगी देत ​​​​नाही.

चाचणी बेंचवर विशेष लक्ष दिले पाहिजे: त्यांनी उत्पादनाच्या सर्व आवृत्त्या तैनात केल्या पाहिजेत ज्या आधी रिलीझ केल्या गेल्या होत्या (किमान त्या आवृत्त्या ज्या समर्थित आहेत), आणि सध्या विकसित केल्या जात असलेल्या सर्व आवृत्त्या.

तिसरे म्हणजे, समान सहभागी एकाच वेळी अनेक आवृत्त्यांवर कामात सहभागी होऊ शकतात. कार्यक्रमाच्या एका आवृत्तीमध्ये एखादी महत्त्वाची व्यक्ती अडकून पडण्याचा आणि दुसर्‍या आवृत्तीशी संबंधित कामांमध्ये जास्त वेळ जाण्याचा धोका जास्त असतो.

चौथे, उलट परिस्थिती आहे, जेव्हा एका आवृत्तीवर काम करणार्‍या कर्मचार्‍यांना दुसर्‍या आवृत्तीवरील कामाचा भाग म्हणून कोणते निर्णय घेतले जातात याबद्दल काहीही माहिती नसते. मी वर नमूद केल्याप्रमाणे, सर्व दस्तऐवज आणि कोडमधील सुधारणा ताबडतोब नंतरच्या सर्व आवृत्त्यांमध्ये वितरीत केल्या गेल्यास समस्येचा काही भाग काढून टाकला जातो. पण हे प्रकरण केवळ दुरुस्त्यांपुरते मर्यादित नसावे. एका आवृत्तीवर काम करणाऱ्या संघाला दुसऱ्या आवृत्तीवर काम करताना काही निर्णय का घेतले गेले हे समजणे आवश्यक आहे. यासाठी विकासकांसाठी ज्ञान आधार आवश्यक आहे - एक विशेष माहिती प्रणाली जी उत्पादनाच्या विशिष्ट आवृत्तीवर काम करताना विकसकांना आलेल्या सर्व समस्या आणि या समस्यांचे निराकरण कसे करावे याचे वर्णन केले पाहिजे. नवीन नोंदी आल्यावर सर्व प्रकल्पातील सहभागींना नॉलेज बेसने सूचना पाठवल्या पाहिजेत. एकाच उत्पादनाच्या वेगवेगळ्या आवृत्त्यांवर काम करणार्‍या दोन संघांचा परस्परसंवाद होऊ देणे अशक्य आहे.

एम्बेडेड सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया

वर नमूद केल्याप्रमाणे, एम्बेड केलेले सॉफ्टवेअर सानुकूल सॉफ्टवेअरपेक्षा वेगळे आहे कारण ते राखणे अत्यंत कठीण आहे.

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

अशा प्रकारे, एम्बेडेड सॉफ्टवेअर विकसित करताना, एकाच वेळी अनेक महत्त्वाच्या मर्यादा उद्भवतात.

प्रथम, वितरण केवळ एका टप्प्याच्या चौकटीत केले जाते: कोणीही डिव्हाइसमध्ये अर्ध-कार्यरत प्रोग्राम तयार करणार नाही.

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

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

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

फर्मवेअर विकास प्रक्रिया आकृती 3 मध्ये दर्शविली आहे.

आकृती 3 एम्बेडेड सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया.

खेळ विकास प्रक्रिया

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

गेमचे उत्पादन वेगळे बनवणारा आणखी एक घटक म्हणजे गेम वापरकर्त्यासाठी एकतर तो शेवटचा स्तर पार करेपर्यंत किंवा त्याला घातक त्रुटी येईपर्यंत तो मनोरंजक असतो. याचा अर्थ असा आहे की तो गेमची दुसरी आवृत्ती विकत घेणार नाही किंवा काही बगचे निराकरण करण्यासाठी ते विनामूल्य डाउनलोड देखील करणार नाही.

हे घटक गेमिंग सॉफ्टवेअरच्या विकास प्रक्रियेवर परिणाम करतात. प्रक्रिया आकृती 4 मध्ये दर्शविली आहे.

आकृती 4. गेम सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया.

गेमिंग सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेची खालील वैशिष्ट्ये लक्षात घेतली पाहिजेत.

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

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

गेमिंग सॉफ्टवेअरचे वितरण एकाच टप्प्यात होते. जरी एक विशिष्ट कोर, गेम सिस्टमचे "इंजिन" प्रथम तयार केले गेले असले तरीही, सिस्टमच्या संपूर्ण कार्यक्षमतेच्या अंमलबजावणीशिवाय त्याचे ऑपरेशन सत्यापित केले जाऊ शकत नाही.

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

निष्कर्ष

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

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

सॉफ्टवेअर व्यवस्थापन

सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया ही सॉफ्टवेअर आणि संबंधित उत्पादने (प्रकल्प योजना, दस्तऐवजीकरण, कोड, चाचण्या, वापरकर्ता दस्तऐवजीकरण) विकसित करण्यासाठी आणि विकसित करण्यासाठी वापरल्या जाणार्‍या विविध क्रियाकलाप, पद्धती, तंत्रे आणि पायऱ्या आहेत.

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

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

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

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

आकृती 1 - सुधारित वॉटरफॉल सॉफ्टवेअर डेव्हलपमेंट मॉडेल

सुधारित कॅस्केड मॉडेलने मागील टप्प्यावर परत येण्याची शक्यता प्रदान केली आहे.

दिसल्यानंतर लवकरच, विन्स्ट रॉयसने धबधब्याचे मॉडेल अंतिम केले, टप्प्यांचे परस्परावलंबन आणि मागील टप्प्यांवर परत जाण्याची गरज लक्षात घेऊन, जे उद्भवू शकते, उदाहरणार्थ, अपूर्ण आवश्यकता किंवा रचनेतील त्रुटींमुळे. कार्य या "उलटता येण्याजोग्या" स्वरूपात, धबधबा मॉडेल बर्याच काळापासून अस्तित्वात होता आणि अनेक प्रकल्पांसाठी आधार होता (आकृती 1).

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

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

आकृती 2 - सॉफ्टवेअर डेव्हलपमेंटचे व्ही-आकाराचे मॉडेल

व्ही-आकाराचे मॉडेल त्याच्या अपेक्षांच्या पूर्ततेच्या दृष्टीने परिणामांवर अधिक नियंत्रण ठेवण्यास अनुमती देते, कारण ते चाचणीवर केंद्रित आहे.

व्ही-आकाराच्या मॉडेलने चाचणीवर लक्ष केंद्रित केल्यामुळे सॉफ्टवेअरच्या गुणवत्तेत लक्षणीय सुधारणा करणे शक्य झाले आणि सुरुवातीच्या टप्प्यावर पडताळणी आणि प्रमाणन प्रक्रियेमुळे पुढे ठेवलेल्या आवश्यकतांसह तयार केलेल्या उत्पादनाच्या अनुपालनाची समस्या देखील मोठ्या प्रमाणात सोडवली. विकासाचे (आकृतीमधील डॅश केलेल्या रेषा नियोजन / सेटिंग टप्पे कार्य आणि चाचणी/स्वीकृती यांचे अवलंबित्व दर्शवितात).

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

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

हे मॉडेल ग्राहक आणि प्रणालीचा निर्माता या दोघांसाठीही फायदेशीर आहे, कारण ते तुम्हाला दोन्ही पक्षांच्या हिताचा आदर करून पुढे जाण्याची परवानगी देते.

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

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

तांदूळ. 3.

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

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

फिलिप क्रॅचटेन यांनी 1995 मध्ये प्रथम प्रस्तावित केलेले, पुनरावृत्ती मॉडेल सर्पिल, वाढीव, धबधबा मॉडेलचे मुख्य फायदे, तसेच प्रोटोटाइपिंग आणि ऑब्जेक्ट-ओरिएंटेड दृष्टिकोनावर आधारित विकास पद्धती (आकृती 4) एकत्र करते. त्याला खूप लोकप्रियता मिळाली आहे आणि बर्याच आधुनिक प्रकल्पांमध्ये एक किंवा दुसर्या स्वरूपात वापरली जाते.

आकृती 4 - पुनरावृत्ती सॉफ्टवेअर विकास मॉडेल

पुनरावृत्ती मॉडेलनुसार, सॉफ्टवेअर डेव्हलपमेंट लाइफ सायकलचे चार मुख्य टप्पे आहेत (प्रारंभ, संशोधन, तयार करणे आणि उपयोजित करणे). प्रत्येक टप्प्यावर, प्रकल्प अनेक पुनरावृत्तींमधून जातो ज्यामुळे कार्यक्षम आवृत्त्या तयार होतात: सुरुवातीच्या टप्प्यावर, प्रोटोटाइप तयार केले जातात, आवश्यकता निर्दिष्ट केल्या जातात आणि सर्वात जटिल समस्यांचे निराकरण केले जाते; अंतिम उत्पादनाची निर्मिती, त्याची सुधारणा आणि कार्यक्षमतेचा विस्तार होतो.

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

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

सर्वात प्रसिद्ध आणि अधिकृत गुणवत्ता मानक हे कॅपॅबिलिटी मॅच्युरिटी मॉडेल (सीएमएम) मानले जावे - डेरिव्हेटिव्ह्जसह विकास प्रक्रियेच्या परिपक्वता पातळीचे मूल्यांकन करण्यासाठी एक मॉडेल. हे SEI (सॉफ्टवेअर इंजिनिअरिंग इन्स्टिट्यूट) द्वारे तयार केले गेले आहे, ज्याला यूएस डिपार्टमेंट ऑफ डिफेन्स द्वारे निधी दिला जातो आणि कार्नेगी मेलॉन युनिव्हर्सिटीचे संरचनात्मक एकक आहे. मानकाची पहिली अधिकृत आवृत्ती 1993 मध्ये प्रसिद्ध झाली होती, जरी त्यावर काम खूप पूर्वी सुरू झाले होते - त्याच्या मुख्य तरतुदी 1986 च्या सुरुवातीस प्रकाशित झाल्या होत्या. CMM चे यश अनेक घटकांद्वारे पूर्वनिर्धारित होते. हे मानक अगदी सुरुवातीपासूनच सॉफ्टवेअर डेव्हलपमेंटची वैशिष्ट्ये विचारात घेणारे पहिले होते. हे समजण्यासाठी आणि वापरण्यासाठी दोन्हीसाठी अगदी सोपे आणि पारदर्शक असल्याचे दिसून आले आणि "काय", आणि "कसे" नाही याचे नियमन केले गेले आणि म्हणूनच विविध जीवन चक्र मॉडेल्स, विकास पद्धतींसाठी योग्य होते आणि दस्तऐवजीकरणावर कोणतेही निर्बंध लादले नाहीत. प्रकल्पांमध्ये वापरलेली मानके, साधने, पर्यावरण आणि भाषा. आणि, कदाचित, सीएमएमची लोकप्रियता पूर्वनिर्धारित करणारा मुख्य घटक म्हणजे यूएस डिपार्टमेंट ऑफ डिफेन्ससह एसईआयचे सहकार्य, ज्याचा वास्तविक अर्थ या विभागाद्वारे सुरू केलेल्या प्रकल्पांच्या अंमलबजावणीमध्ये मानकांचा वापर होता.

CMM मॉडेल (टेबल 1) परिपक्वतेच्या पाच स्तरांसाठी प्रदान करते, ज्यापैकी प्रत्येक विशिष्ट मुख्य प्रक्रिया क्षेत्रांशी संबंधित आहे (मुख्य प्रक्रिया क्षेत्रे, KPA).

तक्ता 1 - HMM मॉडेल

स्तराचे नाव	मुख्य प्रक्रिया क्षेत्रे
1 - आरंभिक	जर संस्था या स्तरावर असेल, तर त्यासाठी कोणतीही प्रमुख प्रक्रिया क्षेत्रे नाहीत
2 - आवर्ती	सॉफ्टवेअर कॉन्फिगरेशन व्यवस्थापन. सॉफ्टवेअर उत्पादनांची गुणवत्ता सुनिश्चित करणे. कंत्राटदारांचे कंत्राट व्यवस्थापन. प्रकल्प प्रगती नियंत्रण. सॉफ्टवेअर प्रकल्पांचे नियोजन. आवश्यकता व्यवस्थापन
3 - परिभाषित	तज्ञांचे मूल्यांकन. प्रकल्प कार्यसंघांमधील परस्परसंवादाचे समन्वय. सॉफ्टवेअर उत्पादन अभियांत्रिकी. एकात्मिक सॉफ्टवेअर व्यवस्थापन. कर्मचारी प्रशिक्षण कार्यक्रम. संस्थात्मक प्रक्रियेची व्याख्या. संस्थात्मक प्रक्रियेची व्याप्ती
4 - व्यवस्थापित	सॉफ्टवेअर गुणवत्ता व्यवस्थापन. परिमाणवाचक पद्धतींवर आधारित प्रक्रिया नियंत्रण
5 - ऑप्टिमाइझ केलेले	प्रक्रिया बदल व्यवस्थापन. तांत्रिक बदलांचे व्यवस्थापन. दोष प्रतिबंध

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

सीएमएम मानक खूप यशस्वी ठरले आणि त्यानंतर त्याच्या आधारावर मानकांची संपूर्ण मालिका तयार केली गेली आणि त्याला एक नवीन नाव प्राप्त झाले - एसडब्ल्यू-सीएमएम (सॉफ्टवेअरसाठी क्षमता परिपक्वता मॉडेल), त्याचे स्थान अधिक अचूकपणे प्रतिबिंबित करते. मानकांचे कुटुंब.

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

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

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

प्रमाणीकरण प्रक्रियेतील त्रुटींमुळे ही परिस्थिती शक्य झाली आहे. संपूर्ण संस्था प्रमाणीकरणाच्या अधीन नाही, परंतु केवळ एक विशिष्ट प्रकल्प आहे. CMM मानकांच्या उच्च पातळीच्या सर्व गरजा पूर्ण करणारा, योग्य पातळीचे प्रमाणीकरण मिळवणारा आणि सर्व उत्पादने अशा आणि अशा दर्जाच्या मानकांची पूर्तता करत असल्याचे घोषित करणारा "प्रदर्शनात्मक" प्रकल्प तयार करण्यापासून संस्थेला रोखण्यासाठी काहीही नाही.

नवीन मानक SEI - कॅपेबिलिटी मॅच्युरिटी मॉडेल इंटिग्रेटेड (CMMI) - हे विकास प्रक्रियेच्या परिपक्वता पातळीचे मूल्यांकन करण्यासाठी एक एकीकृत मॉडेल आहे. सीएमएमआय मानक मूळतः अशा प्रकारे तयार केले गेले होते की विद्यमान सीएमएम पर्याय एकत्र केले जातील आणि उच्च-टेक कंपन्यांच्या क्रियाकलापांच्या विविध क्षेत्रांमध्ये त्याच्या व्यावहारिक अनुप्रयोगातील कोणतेही विरोधाभास दूर केले जातील.

संस्थेच्या प्रक्रियेस "संरेखित" करण्याची गरज दूर करण्यासाठी आणि त्याच्या व्यावसायिक गरजांशी अधिक जुळवून घेण्यासाठी, आणि उलट नाही, CMMI मानकात सादरीकरणाचे दोन प्रकार आहेत - क्लासिक, बहु-स्तरीय, सीएमएमशी संबंधित, आणि नवीन, सतत. सादरीकरणाचे सतत स्वरूप परिपक्वता पातळी (परिपक्वता पातळी) विचारात घेत नाही, परंतु क्षमता पातळी, ज्याचे वैयक्तिक प्रक्रिया क्षेत्रांसाठी (प्रक्रिया क्षेत्र, PA) मूल्यांकन केले जाते.

तक्ता 2 सीएमएम मानकांच्या परिपक्वता स्तरांचे मॅपिंग देते, तसेच स्तरित CMMI सादरीकरणाची परिपक्वता पातळी आणि सतत CMMI सादरीकरणाची क्षमता पातळी.

तक्ता 2 - CMM, CMMI मानकांच्या परिपक्वता पातळीचे अनुपालन

SEI CMM पासून दूर जात आहे आणि त्या बदल्यात CMMI चा सक्रियपणे प्रचार करत आहे, प्रमाणन प्रक्रियेवर नियंत्रण घट्ट करण्याचे, खर्च कमी करण्याचे आणि छोट्या संस्थांना ते अधिक आकर्षक बनविण्याचे आश्वासन देत आहे; ISO मानकांशी सुसंगतता सुनिश्चित करणे.

आधुनिक परिस्थितीत, सीएमएम / सीएमएमआयच्या विशिष्ट पातळीच्या प्रमाणपत्राची उपस्थिती हा इतका महत्त्वपूर्ण घटक नाही कारण तो अनेक वर्षांपूर्वी होता आणि कदाचित सरकारी आदेशानुसार चालविलेल्या प्रकल्पांशिवाय अतिरिक्त प्रश्नांशिवाय स्वीकारला जातो.

ISO/IEC 15504 मानक हे विशिष्ट सॉफ्टवेअरमध्ये माहिती प्रणाली विकसित करण्याच्या प्रक्रियेचे मूल्यांकन करण्यासाठी आहे. हे मूलतः सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेचे मूल्यमापन करण्यासाठी उद्योग मानकांशी सुसंगत असण्यासाठी डिझाइन केले होते. या आवश्यकतेने सीएमएम / सीएमएमआयच्या मूलभूत तत्त्वांसह मानकांची समानता निश्चित केली.

कार्नेगी मेलॉन विद्यापीठातील सॉफ्टवेअर अभियांत्रिकी संस्थेने विकसित केलेले सॉफ्टवेअर डेव्हलपमेंट प्रोसेस मॅच्युरिटी मॉडेल (सीएमएम) परिपक्वतेचे पाच स्तर सुचवते (तक्ता 3). हे संस्थांना त्यांच्या सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेची परिपक्वता वाढवण्यास मदत करते आणि संस्थांचे मूल्यांकन केले जाऊ शकते आणि या स्तरांवर मान्यता दिली जाऊ शकते.

तक्ता 3 - सॉफ्टवेअर विकास परिपक्वता पातळी

स्तर 1 - प्रवेश पातळी	सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया उत्स्फूर्त आहे आणि फक्त काही प्रक्रियांचे नियमन केले जाते. विकासाचे यश वैयक्तिक कर्मचाऱ्यांवर अवलंबून असू शकते.
स्तर 2 - पुनरावृत्तीक्षमता पातळी	खर्च, वेळापत्रक आणि कार्यक्षमतेचा मागोवा घेण्यासाठी मुख्य प्रकल्प व्यवस्थापन प्रक्रिया तयार केल्या.
स्तर 3 - नियमन पातळी	सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया दस्तऐवजीकरण, प्रमाणित आणि संस्थेच्या मानक सॉफ्टवेअर विकास प्रक्रियेसह व्यवस्थापन आणि विकास ऑपरेशन्स दोन्हीसाठी एकत्रित केली जाते. सर्व प्रकल्प प्रमाणित प्रक्रिया वापरतात.
स्तर 4 - व्यवस्थापन पातळी	प्रक्रिया आणि उत्पादने समजून घेण्यासाठी आणि व्यवस्थापित करण्यात मदत करण्यासाठी सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेचे तपशीलवार मेट्रिक्स आणि उत्पादनाच्या गुणवत्तेचे संकलन केले जाते.
स्तर 5 - ऑप्टिमायझेशन स्तर	प्रक्रियेतील परिमाणात्मक अभिप्राय आणि प्रायोगिक नाविन्यपूर्ण कल्पना आणि तंत्रज्ञानाद्वारे निरंतर प्रक्रिया ऑप्टिमायझेशन सुनिश्चित केले जाते.

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

एस आर्चिपेन्कोव्ह

सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेचे मॉडेल (किंवा, जसे त्यांना म्हणायचे आहे, पद्धती) सामान्यतः "वजन" द्वारे वर्गीकृत केले जातात - औपचारिक प्रक्रियांची संख्या (बहुतेक प्रक्रिया किंवा फक्त मुख्य) आणि त्यांच्या नियमनचे तपशील. जितक्या अधिक प्रक्रियांचे दस्तऐवजीकरण केले जाते, अधिक तपशीलवार वर्णन केले जाते, मॉडेलचे "वजन" जास्त असते.

सर्वात सामान्य आधुनिक सॉफ्टवेअर विकास प्रक्रिया मॉडेल आकृती 3 मध्ये दर्शविले आहेत.

आकृती 3 सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेचे वेगवेगळे मॉडेल आणि "वजन" नुसार त्यांचे वितरण

GOSTs

GOST 19 "युनिफाइड सिस्टम ऑफ सॉफ्टवेअर डॉक्युमेंटेशन" आणि GOST 34 "स्वयंचलित प्रणालींच्या विकासासाठी आणि देखभालीसाठी मानके" सॉफ्टवेअर विकासासाठी सातत्यपूर्ण दृष्टिकोनावर केंद्रित आहेत. या मानकांनुसार विकास टप्प्याटप्प्याने केला जातो, ज्यापैकी प्रत्येकामध्ये काटेकोरपणे परिभाषित केलेल्या कार्याचा समावेश असतो आणि बर्‍याच प्रमाणात औपचारिक आणि विस्तृत दस्तऐवजांच्या प्रकाशनासह समाप्त होते. अशाप्रकारे, या पाहुण्यांचे कठोर पालन केल्याने केवळ धबधब्याचा दृष्टीकोनच उद्भवत नाही, तर विकासाच्या औपचारिकतेची उच्च पातळी देखील आवश्यक आहे. या मानकांच्या आधारे, रशियामधील सरकारी आदेशांसाठी सॉफ्टवेअर प्रणाली विकसित केली जात आहे.

SW-CMM

1980 च्या दशकाच्या मध्यात, यूएस डिपार्टमेंट ऑफ डिपार्टमेंटने मोठ्या प्रमाणावर सॉफ्टवेअर प्रकल्प राबवताना सॉफ्टवेअर डेव्हलपर कसे निवडायचे याबद्दल कठोर विचार करण्यास सुरुवात केली. लष्कराने कमिशन केलेल्या, कार्नेगी मेलॉन विद्यापीठाचा भाग असलेल्या सॉफ्टवेअर इंजिनिअरिंग इन्स्टिट्यूटने सॉफ्टवेअर डेव्हलपमेंट संस्थांसाठी संदर्भ मॉडेल म्हणून SW-CMM, सॉफ्टवेअरसाठी क्षमता परिपक्वता मॉडेल विकसित केले.

हे मॉडेल सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेच्या परिपक्वतेचे पाच स्तर परिभाषित करते.

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

SW-CMM चे संपूर्ण दस्तऐवजीकरण सुमारे 500 पृष्ठांचे आहे आणि 312 आवश्यकतांचा संच परिभाषित करते ज्या एखाद्या संस्थेने परिपक्वता स्तर 5 वर या मानकासाठी पात्र ठरण्याची योजना आखल्यास ती पूर्ण करणे आवश्यक आहे.

RUP

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

एमएसएफ

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

PSP/TSP

इन्स्टिट्यूट ऑफ सॉफ्टवेअर इंजिनिअरिंग वैयक्तिक सॉफ्टवेअर प्रक्रिया / टीम सॉफ्टवेअर प्रक्रिया [ , ] च्या नवीनतम विकासांपैकी एक. वैयक्तिक सॉफ्टवेअर प्रक्रिया विकसक सक्षमता आवश्यकता परिभाषित करते. या मॉडेलनुसार, प्रत्येक प्रोग्रामर सक्षम असावा:

• प्रकल्पावर घालवलेला वेळ विचारात घ्या;
• आढळलेले दोष विचारात घ्या;
• दोषांचे प्रकार वर्गीकृत करा;
• कार्याच्या आकाराचा अंदाज लावा;
• चाचणी परिणामांचे वर्णन करण्यासाठी पद्धतशीर दृष्टीकोन लागू करा;
• योजना कार्यक्रम कार्ये;
• त्यांना कालांतराने वितरित करा आणि कामाचे वेळापत्रक तयार करा.
• वैयक्तिक डिझाइन आणि आर्किटेक्चर पुनरावलोकने करा;
• कोडची वैयक्तिक पडताळणी करा;
• प्रतिगमन चाचणी करा.

टीम सॉफ्टवेअर प्रक्रिया 3-20 विकासकांच्या स्वयं-व्यवस्थापित संघांवर अवलंबून असते. संघांनी हे करणे आवश्यक आहे:

• आपले स्वतःचे ध्येय सेट करा;
• आपली प्रक्रिया आणि योजना विकसित करा;
• ट्रॅक काम;
• प्रेरणा आणि शिखर कामगिरी राखणे.

पीएसपी/टीएसपी मॉडेलचा सातत्यपूर्ण वापर तुम्हाला संस्थेमध्ये सीएमएमचा पाचवा स्तर आदर्श बनविण्याची परवानगी देतो.

चपळ

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

प्रक्रिया मॉडेल निवड

उत्पादन प्रक्रियेच्या जड आणि हलक्या मॉडेल्समध्ये त्यांचे फायदे आणि तोटे आहेत (तक्ता 1).

तक्ता 1. सॉफ्टवेअर डेव्हलपमेंट प्रक्रियेच्या जड आणि हलक्या मॉडेल्सचे फायदे आणि तोटे

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

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

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

• प्रत्येक प्रकल्पाचे स्वतःचे विकास प्रक्रिया मॉडेल असावे.
• प्रत्येक मॉडेलची वेळ असते.

याचा अर्थ असा आहे की कोणतीही एकच योग्य सॉफ्टवेअर डेव्हलपमेंट प्रक्रिया नाही, प्रत्येक नवीन प्रकल्पामध्ये "4 Ps च्या कायद्या" (आकृती 4) नुसार, प्रकल्प, उत्पादन आणि कर्मचारी यांच्या आधारावर प्रक्रिया प्रत्येक वेळी नव्याने परिभाषित करणे आवश्यक आहे. 5 लोकांसह प्रकल्प आणि 500 ​​लोक असलेल्या प्रकल्पांमध्ये पूर्णपणे भिन्न प्रक्रिया लागू केल्या पाहिजेत. जर प्रकल्पाचे उत्पादन गंभीर सॉफ्टवेअर असेल, उदाहरणार्थ, अणुऊर्जा प्रकल्पासाठी नियंत्रण प्रणाली, तर विकास प्रक्रिया, उदाहरणार्थ, साइट "otdokhni.ru" च्या विकासापेक्षा खूप वेगळी असावी. आणि, शेवटी, कालच्या विद्यार्थ्यांच्या टीममध्ये आणि कुशल व्यावसायिकांच्या टीममध्ये विकास प्रक्रिया वेगळ्या पद्धतीने आयोजित केली पाहिजे.

आकृती 4. "4 Ps चा कायदा". प्रकल्पातील प्रक्रिया प्रकल्प, उत्पादन आणि कर्मचारी यांच्या आधारावर परिभाषित केली पाहिजे

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

सॉफ्टवेअर प्रकल्पाच्या यशस्वीतेसाठी काय करावे लागेल

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

सॉफ्टवेअर प्रकल्प यशस्वी होण्यासाठी, तुम्ही हे करणे आवश्यक आहे:

1. स्पष्टपणे ध्येय निश्चित करा.
2. ध्येय कसे साध्य करायचे ते ठरवा.
3. अंमलबजावणी नियंत्रित आणि व्यवस्थापित करा.
4. धमक्यांचे विश्लेषण करा आणि त्यांचा प्रतिकार करा.
5. एक संघ तयार करा.

1. आम्ही ध्येये निश्चित केली

   १.१. संकल्पना स्पष्ट, अस्पष्ट उद्दिष्टे परिभाषित करते.
   १.२. सर्व कार्यसंघ सदस्य संकल्पना वास्तववादी मानतात.
   १.३. या प्रकल्पाला आर्थिक कार्यक्षमतेसाठी एक तर्क आहे.
   १.४. एक प्रोटोटाइप यूजर इंटरफेस विकसित करण्यात आला आहे.
   1.5. सॉफ्टवेअर उत्पादनाच्या लक्ष्य कार्यांचे तपशील विकसित केले गेले आहेत.
   १.६. उत्पादनाच्या अंतिम वापरकर्त्यांसह द्वि-मार्ग संप्रेषण स्थापित केले गेले आहे

2. ध्येय कसे साध्य करायचे ते ठरवा

   २.१. उत्पादन विकासासाठी तपशीलवार लेखी योजना आहे.
   २.२. प्रकल्प कार्यांच्या सूचीमध्ये "किरकोळ" कार्ये (कॉन्फिगरेशन व्यवस्थापन, डेटा रूपांतरण, इतर सिस्टमसह एकत्रीकरण) समाविष्ट आहेत.
   २.३. प्रकल्पाच्या प्रत्येक टप्प्यानंतर, वेळापत्रक आणि बजेट अद्यतनित केले जाते.
   २.४. आर्किटेक्चर आणि डिझाइन निर्णय दस्तऐवजीकरण आहेत.
   2.5. एक गुणवत्ता हमी योजना आहे जी चाचणी आणि पुनरावलोकन परिभाषित करते.
   २.६. उत्पादनाच्या मल्टी-स्टेज डिलिव्हरीसाठी एक योजना परिभाषित केली गेली आहे.
   २.७. योजना प्रशिक्षण, शनिवार व रविवार, सुट्ट्या, आजारी दिवस विचारात घेते.
   २.८. प्रकल्प योजना आणि वेळापत्रक सर्व कार्यसंघ सदस्यांनी मंजूर केले आहे.

3. आम्ही अंमलबजावणी नियंत्रित आणि व्यवस्थापित करतो

   ३.१. प्रकल्पाला क्युरेटर आहे. या प्रकल्पाच्या यशामध्ये वैयक्तिकरित्या स्वारस्य असलेल्या कामगिरी करणार्‍या कंपनीचा हा एक उच्च व्यवस्थापक आहे.
   ३.२. प्रकल्पात एक व्यवस्थापक आहे, आणि फक्त एक!
   ३.३. प्रकल्प योजना "बायनरी" टप्पे परिभाषित करते.
   ३.४. सर्व इच्छुक पक्ष प्रकल्पाच्या प्रगतीबद्दल आवश्यक माहिती प्राप्त करू शकतात.
   ३.५. व्यवस्थापन आणि विकासक यांच्यात विश्वासार्ह संबंध प्रस्थापित झाला आहे.
   ३.६. प्रकल्पासाठी बदल व्यवस्थापन प्रक्रिया स्थापन केली.
   ३.७. प्रकल्पातील बदल स्वीकारण्याच्या निर्णयासाठी जबाबदार व्यक्ती ओळखल्या गेल्या आहेत.
   ३.८. प्रकल्पाची योजना, वेळापत्रक आणि स्थितीची माहिती प्रत्येक सहभागीसाठी उपलब्ध आहे.
   ३.९. सिस्टम कोडचे स्वयंचलितपणे पुनरावलोकन केले जाते.
   ३.१०. दोष व्यवस्थापन प्रणाली लागू केली आहे.

4. आम्ही धमक्यांचे विश्लेषण करतो

   ४.१. प्रकल्पाच्या जोखमींची यादी आहे. हे नियमितपणे पुनरावलोकन आणि अद्यतनित केले जाते.
   ४.२. प्रकल्प व्यवस्थापक नवीन जोखमीच्या उदयाचे निरीक्षण करतो.
   ४.३. प्रत्येक कंत्राटदारासाठी, त्याच्याबरोबर काम करण्यासाठी जबाबदार व्यक्ती निश्चित केली जाते.

5. संघ तयार करण्यावर काम करत आहे

   ५.१. प्रकल्प पूर्ण करण्यासाठी संघाचा अनुभव पुरेसा आहे.
   ५.२. संघाकडे अर्ज क्षेत्रात पुरेशी क्षमता आहे.
   ५.३. प्रकल्पाला एक तांत्रिक नेता आहे.
   ५.४. कर्मचाऱ्यांची संख्या पुरेशी आहे.
   ५.५. संघात पुरेशी सुसूत्रता आहे.
   ५.६. सर्व सहभागी प्रकल्पासाठी वचनबद्ध आहेत.

चाचणीचे मूल्यांकन आणि व्याख्या

स्कोअर: गुणांची बेरीज, प्रत्येक आयटमला 0 ते 3 रेट केले आहे:

• 0 - हे कधीही ऐकले नाही;
• 1 - ऐकले, परंतु अद्याप लागू केले नाही;
• 2 - अंशतः लागू;
• 3 - पूर्णपणे लागू.

सुधारणा घटक:

• लहान प्रकल्पांसाठी (5 लोकांपर्यंत) - 1.5;
• मध्यम (5 ते 20 लोकांपर्यंत) - 1.25.

परिणाम:

• <40 - завершение проекта сомнительно.
• 40-59 - सरासरी निकाल. प्रकल्पादरम्यान गंभीर समस्या अपेक्षित आहेत.
• 60-79 एक चांगला परिणाम आहे. प्रकल्प यशस्वी होण्याची शक्यता आहे.
• 80-89 एक उत्कृष्ट परिणाम आहे. यशाची शक्यता जास्त आहे.
• >90 हा एक चांगला परिणाम आहे. यशाची १००% शक्यता.

ही चेकलिस्ट सॉफ्टवेअर प्रकल्पाच्या यशासाठी काय करणे आवश्यक आहे याची सूची देते, परंतु ते कसे करावे या प्रश्नाचे उत्तर देत नाही. बाकी लेक्चर्स ह्याबद्दलच असतील.