आम्ही सर्व 80/20 च्या नियमांबद्दल ऐकले आहे, असे म्हटले आहे की आमचे 80% यश (परिणाम) केवळ 20% क्रियांद्वारे होते (कारणे). असो, हे सार्वत्रिक सत्य सॉफ्टवेअर विकासावर देखील परिणाम करते आणि या लेखात आम्ही या विधानाची थोडी मूलभूत माहिती काढून टाकणार आहोत.
बीपीएम
व्यवसाय प्रक्रिया व्यवस्थापन, इंग्रजीमध्ये परिवर्णी शब्द म्हणून, एक व्यवस्थापन शिस्त आहे (इतर गोष्टींबरोबरच) जे आपल्याला व्यवसायात (किंवा इतर बर्‍याच ठिकाणी) चालत असलेल्या प्रक्रियेस दृष्टिहीनपणे समजण्यास परवानगी देते. त्याच्या मुख्य गुणांपैकी एक म्हणजे ही जटिल प्रक्रियेचे विश्लेषण करू शकते आणि त्यांना "सोपे" बनवते.
बर्‍याच मुक्त स्त्रोत साधने आहेत जी आपल्याला बीपीएम डायग्राम विकसित करण्यास अनुमती देतात, मी या लेखासाठी वापरलेले एक म्हणजे बोनिटासॉफ्ट. प्रक्रिया व्यवस्थापनाबद्दल आपल्याला जर थोडे शिकायचे असेल तर इंटरनेटवर अनेक ट्यूटोरियल आणि या विषयावरील पुस्तके आहेत. आता केंद्रीय विषयाकडे परत जाऊया.
सॉफ्टवेअर प्रकल्प
आज प्रकल्प विकसित करण्यासाठी अनेक पद्धती आहेत, तेथे चपळ, पारंपारिक, मिश्रित इत्यादी आहेत. एक मुद्दा ज्या सर्वांमध्ये समान आहे तयारी. मी याचा अर्थ काय? या सॉफ्टवेअर प्रकल्पातील आपले 80% यश हे संपूर्ण प्रक्रियेच्या पहिल्या 20% वर आधारित असेल, तयारी.
प्रकल्प तयार करीत आहे
ही तार्किक गोष्ट आहे जी प्रत्यक्षात अगदी थोड्या प्रमाणात लागू केली जाते (व्यवहारात अतार्किक अशा अनेक तार्किक गोष्टींप्रमाणे). जेव्हा आपण तयारीबद्दल बोलतो तेव्हा आम्हाला समस्या समजून घेण्याची क्षमता समजून घेणे आवश्यक आहे, त्याचे निराकरण समजून घेणे आणि सर्वात महत्त्वाचे म्हणजे, प्रक्रिया समाधान लागू होते की. अव्यवसायिक सॉफ्टवेअर प्रकल्पांमध्ये आढळलेल्यांपैकी एक म्हणजे विषयावरील कागदपत्रांची कमतरता. हे सहसा खाजगी कंपन्यांमध्ये दिसून येते कारण विक्रीची इच्छा निर्मिती प्रक्रियेपेक्षा जास्त आहे.
हे लेख वाचणारे बरेचजण तंत्रज्ञानाशी संबंधित आहेत, हे लक्षात घेण्यासारखे आहे की जर त्यांच्या कामकाजाच्या जीवनात एखाद्या वेळेस एखादी कंपनी / पुरवठादार सापडला ज्या चांगल्या तयारीला भाग पडत नाहीत तर ते जवळजवळ 80०% निश्चित आहे - प्रकल्प हे कार्य करणार नाही.
अ‍ॅबस्ट्रॅक्शन ही गुरुकिल्ली आहे
जीएनयू / लिनक्स वापरुन मी हे माझ्या काळापासून शिकलो आहे आणि हे सॉफ्टवेअर तयार करण्याच्या प्रक्रियेत वेळोवेळी सिद्ध होते. ची क्षमता गोषवारा त्यांना अधिक "साध्या" गोष्टींमध्ये बदलण्यासाठी मोहक कोड तयार करण्यात सक्षम असणे आणि सर्वात महत्त्वाचे आहे टिकाऊ. आणि कदाचित नियंत्रणाबाहेर वाढणार्‍या मोठ्या व्यावसायिक प्रकल्प आणि प्रकल्पांमधील हा मुख्य फरक आहे. पूर्वीचे लोक विचार करतात, समजतात आणि रचना करतात प्रक्रिया सेकंद असताना ते ठेवतात हे समजून घेतल्याशिवाय कार्य करीत आहे.
चपळ
हे जेंटू इंस्टॉलर विकसित करणार्या प्रोजेक्टचे नाव आहे, जसे आपण कल्पना करू शकता की ही एक जटिल प्रक्रिया आहे, कारण ती मोठ्या संख्येने आर्किटेक्चर्सला आधार देते. खात्यात घेण्यासारखे आणखी एक घटक म्हणजे त्यास कर्नल स्तरावर, init प्रणाली इत्यादी समर्थन पुरवलेल्या संयोजनांची संख्या. आणि मी हे सर्व सांगत आहे कारण हा माझा थीसिस प्रोजेक्ट देखील आहे, जो अभ्यास पूर्ण करण्यापूर्वी मी पूर्ण करणे आवश्यक आहे. स्पष्टपणे मी असा कार्यक्रम बनवू शकत नाही जो इतक्या कमी वेळात (पुढील वर्षाच्या जुलैपर्यंत) सर्व संभाव्य पर्यायांचा विचार करेल, परंतु कमीतकमी मी असा एखादा व्युत्पन्न करू शकतो जो कार्यशील प्रणाली अगदी मूलभूत मार्गाने स्थापित केला जाऊ शकतो.
स्थापना प्रक्रिया समजून घेत आहे
बीपीएम टूल्सबद्दल धन्यवाद, एक प्रक्रिया आकृती तयार केली जाऊ शकते जी आम्हाला संगणकावर जेंटूच्या यशस्वी स्थापनेसाठी आवश्यक चरण समजण्यास परवानगी देते.
स्वतःचे. ख्रिस्तोफर डायझ रिव्हरोस
बर्‍याच प्रक्रिया आणि उप-प्रक्रिया असूनही, त्याचा स्पष्टपणे थोडक्यात सारांश काढला गेला आहे आणि असे दिसून येते की आपल्याकडे 18 रेषीय चरण आहेत. हे महत्वाचे आहे कारण एक arप्लिकेशन ज्याची रेखीय रचना असते ती अंमलात आणणे सोपे आहे आणि आवश्यकतेनुसार एक किंवा अनेक थ्रेडमध्ये समांतरता निर्माण केली जाऊ शकते.
आणखी एक महत्त्वाचा घटक म्हणजे तो आपल्याला परवानगी देतो गोषवारा प्रक्रियेचे प्रकार टाइप करा, उदाहरणार्थ, कर्नल थ्रेड निश्चित केल्याने त्यामध्ये काही विशिष्ट कार्ये आहेत ज्या कर्नल यशस्वीरित्या स्थापित करण्याच्या प्रक्रियेशी थेट संबंधित आहेत.
स्वतःचे. ख्रिस्तोफर डायझ रिव्हरोस
अशा प्रकारे प्रत्येक "जटिल" चरण आवश्यक तपशील न गमावता, जागतिक मार्गाने एक "साधे" बनते. प्रक्रिया यशस्वीरीत्या पार पाडण्यासाठी आवश्यक असणारी विशिष्टतेची पातळी कमी न करता विधानसभेची दृश्यमानता यामुळे सुलभ होते. आणि आम्ही हे नाकारू शकत नाही की संपूर्ण हँडबुक एकदाच वाचण्यापेक्षा प्रतिमा पाहणे सोपे आहे 🙂
वेळ वाचवा
आणखी एक स्पष्ट फायदा म्हणजे थेट कनेक्टिव्ह प्रोग्रामिंग भाषा नसल्यामुळे, भाषेची अंमलबजावणी करण्यात वेळ न घालवता तर्कशास्त्र विश्लेषण करणे शक्य आहे. अधिक कार्यक्षम तोडगा आहे म्हणूनच तो टाकून दिला जाईल हे शोधण्यासाठी केवळ वैशिष्ट्याची अंमलबजावणी करण्यात जितका वेळ खर्च केला जाऊ शकतो त्याच्या तुलनेत हा एक फायदा आहे. छद्म कोडमधील निराकरण काय असेल (जसे की बरेच "विकसक" देखील त्याकडे दुर्लक्ष करतात पण तसे नसावेत).
प्रोजेक्टचे दिग्दर्शन करणे सोपे झाले
या संकल्पना विचारात घेतल्यास प्रकल्प व्यवस्थापन (कोणत्याही प्रकारचे) सुलभ होते, कारण आम्ही खरोखर आपल्या प्रयत्नांवर लक्ष केंद्रित करतो जेथे त्यांना खरोखर आवश्यकता आहे आणि जर हा भाग योग्य प्रकारे केला असेल तर उर्वरित त्याच्या स्वत: च्या वजनाखाली येतात. मला आशा आहे की हे आपल्या कुतूहलास मदत करते आणि आपल्याला बीपीएम, अल्गोरिथमिक्स आणि कोणास ठाऊक याबद्दल संशोधन करण्यास प्रवृत्त करते, कदाचित ते मला माझ्या प्रबंधास मदत करण्यास प्रोत्साहित करेल here येथे येण्याबद्दल धन्यवाद, आणि आम्ही लवकरच एकमेकांना भेटू. चीअर्स
हाय. आपले ज्ञान सामायिक केल्याबद्दल धन्यवाद. मला वाटते की हा एक रोमांचक विषय आहे परंतु त्यासाठी बरेच संशोधन कार्य आवश्यक आहे आणि संकल्पना प्रत्यक्षात आणण्यासाठी त्या प्रत्यक्षात आणल्या पाहिजेत. प्रारंभी हा मुद्दा गोंधळात टाकणारा आहे कारण एखाद्यास सिस्टमची आवश्यकता ओळखण्यासाठी आणि कंपनीच्या कार्यप्रणालीशी संबंधित नसून कंपनीच्या कार्यप्रणालीशी संबंधित असणे अधिक आवश्यक आहे. शेवटी, मला वाटते की व्यवसायाचे कार्य अधिक कार्यक्षम आणि प्रभावी बनविण्यासाठी सॉफ्टवेअर डेव्हलपर कंपनीच्या व्यवसायाचे मॉडेलिंग बनवण्याच्या भूमिकेबद्दल अधिक आहे.
नमस्कार अलेक्झांडर, सामायिक केल्याबद्दल मनापासून धन्यवाद खरं सांगायचं तर, अशा छोट्या जागेत सर्व काही थोडक्यात सांगण्याचा प्रयत्न करणे हा एक जटिल विषय आहे, परंतु मी आपल्या टिप्पणीसह गोंधळापासून मुक्त होण्यासाठी जर थोडे योगदान देऊ शकले तर - हे खरे आहे की सिस्टमने आवश्यकतांचे निराकरण करण्याचा प्रयत्न केला पाहिजे, सर्वात शक्य मूलभूत कार्यक्षमता आहे आणि त्या वेळी हे खरे आहे की विकसकाने उच्च स्तरावर लक्ष केंद्रित केले पाहिजे.
प्रक्रियेचे ज्ञान विकसकांना पुरेशी प्रणालींपेक्षा अधिक सादर करण्याची परवानगी देते आणि किमान शक्य गरजा पूर्ण करणारे असे काहीतरी समजते.
संहिताची लालित्य संपूर्ण प्रक्रिया समजून घेण्यास सक्षम आहे आणि त्यास सखोल मार्गाने व्युत्पन्न करते, जिथे सर्वोत्तम शक्य समाधान लागू केले जाते आणि आवश्यकतेपेक्षा प्रक्रिया खरोखरच समजून घेतल्यामुळेच हे शक्य आहे, जसे आपण आपला उल्लेख केला आहे. 🙂
जर आपण त्याचे एफओएसएसच्या सभोवतालचे मॉडेल केले तर ते केवळ सॉफ्टवेअरची आवश्यकताच नाही तर त्यामागील तत्वज्ञान आणि हे कसे राखले जाईल हे कुणाद्वारे, आणि प्रक्रियेचे सर्व ज्ञान जे केवळ एक कार्यक्षम निराकरण तयार करते असे सूचित करते. ., परंतु वेळोवेळी देखरेख करणे शक्य होईल 🙂
पुन्हा खूप खूप धन्यवाद आणि शुभेच्छा.