क्या मुझे अपने नियोक्ता को सुनना चाहिए और CASE टूल का उपयोग करना चाहिए?

Question

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

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

क्या मैं सही हूँ? या क्या मुझे अपने नियोक्ता की बात सुननी चाहिए और एक उपयुक्त CASE टूल के लिए शोध शुरू करना चाहिए?

Comments

"मुझे वास्तव में लगता है कि CASE जनरेट कोड अच्छे डेवलपर द्वारा लिखे गए कोड के समान अच्छा नहीं होगा" - लोग कंपाइलरों द्वारा उत्पन्न कोड के बारे में भी यही कहते थे।

जवाब बहुत कुछ इस बात पर निर्भर करता है कि आप अपनी नौकरी रखना चाहते हैं या नहीं :)

— dasblinkenlight

1990 के दशक ने बुलाया, और वे अपनी सनक वापस चाहते हैं।

— Blrfl

@GrahamLee हालांकि दोनों के बीच बहुत बड़ा अंतर है - आप पढ़ते हैं (जब डिबगिंग करते हैं) और आंशिक समय (जैसे कि आंशिक कक्षाओं या इस तरह) के लिए जोड़ बनाते हैं, तो हर समय संकलित-उत्पन्न कोड की परवाह नहीं करते हैं। पठनीय।

— guillaume31

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

— ब्लरफुल

Answer 1

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

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

• आपकी कौन सी प्रक्रिया के लिए कौन से उपकरण उपलब्ध हैं,
• नए टूल (उपकरण) को अपनाने के लिए कितने व्यक्ति-घंटे की आवश्यकता होगी, इसका अनुमान
• नए उपकरण को अपनाने के साथ प्रक्रिया (तों) कैसे बदल जाएगी,
• या नए उपकरण को अपनाने से किस तरह का सकारात्मक (या नकारात्मक) प्रभाव औसत दर्जे का होगा

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

Comments

"इसे अपने विकास के वातावरण और प्रक्रियाओं को अपग्रेड करने के अवसर के रूप में सोचें।" - CASE टूल का उद्देश्य समस्या का समाधान करना है। A, B, और C. के कारण हमें समस्या X नहीं है। एक अधिक प्रासंगिक उपकरण है Y, जो संबंधित समस्या को हल करता है।

— ब्रायन

Answer 2

हां आपको CASE टूल पर शोध शुरू करना चाहिए।

1. क्योंकि आपको अपने दावे का समर्थन करने के लिए सबूत चाहिए कि वे मदद नहीं करेंगे। आप कभी नहीं जानते, आप पा सकते हैं कि वे मदद करेंगे।
2. क्योंकि आपके नियोक्ता ने आपको बताया था।

मैं डेविड कैक्ज़िनस्की द्वारा दिए गए बिंदुओं को अपने उत्कृष्ट उत्तर में नहीं दोहराऊंगा क्योंकि वे आपके द्वारा अनुसरण किए जाने वाले कदम हैं।

Comments

क्या आपको लगता है कि वे मदद नहीं करेंगे?

— .शरथ

@omsharp - मुझे नहीं पता कि वे आपकी मदद करेंगे या नहीं। मैं आपके द्वारा प्रस्तुत प्रश्न का उत्तर दे रहा था "क्या मुझे अपने नियोक्ता को सुनना चाहिए और [sic] उपयुक्त CASE टूल के लिए शोध करना शुरू करना चाहिए"।

— ChrisF

बिंदु # 1 के लिए +1। बहुत सारे लोग सोचते हैं कि वे अपना काम नहीं कर सकते क्योंकि "वे बेहतर जानते हैं"।

— TZHX

"क्योंकि आपके नियोक्ता ने आपको बताया था" कभी भी किसी भी कारण से नहीं होना चाहिए।

— पिकारस

@Picarus - हाँ यह चाहिए - भले ही यह आपके इस्तीफे में सौंप रहा हो जब उन्होंने आपको अनैतिक या अवैध कुछ करने के लिए कहा था।

— ChrisF

Answer 3

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

आप जो वर्णन करते हैं, उससे आपके नियोक्ता को क्या आसानी से समझ में आता है:

• एक डेवलपर को टीम छोड़ने के लिए ज्ञान हानि से बचने के लिए बेहतर प्रलेखन।
• एक तेज विकास प्रक्रिया।

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

यहाँ फुर्तीले वातावरण में CASE टूल और उनके संभावित लाभों / कमियों के बारे में एक दिलचस्प लेख है: http://www.agilemodeling.com/essays/simpleTools.htm

Comments

यह लेख

— डेविड

Answer 4

मेरा नियोक्ता (डेवलपर नहीं) सोचता है कि CASE उपकरण हमारी विकास प्रक्रिया और प्रलेखन को बेहतर बनाने में हमारी मदद करेंगे। "

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

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

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

विशेष रूप से CASE टूल के साथ, मैंने तीन अलग-अलग स्थानों पर काम किया है जो इन पैकेजों के मालिक हैं। हर एक में, यह इस तरह से गया:

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

संक्षेप में, यह प्रत्येक मामले में 100% कुल विफलता और धन की बर्बादी थी। जब मैंने अन्य लोगों से बात की है जिन्होंने अन्य संगठनों में CASE टूल का उपयोग किया है, तो कहानी हमेशा उसी के बारे में होती है। मैंने इन सभी साधनों का उपयोग नहीं किया है और यह संभव है कि कुछ लोगों ने इनका अच्छा उपयोग किया हो, लेकिन मुझे पूरा यकीन है कि जिन टीमों ने इनका उपयोग किया है, उनका उपयोग बहुत पहले ही बंद कर दिया है।

Answer 5

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

Answer 6

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

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

CASE टूल का विकल्प भी मदद कर सकता है। साइक्लोमैटिक या अन्य जटिलता उपायों जैसी चीजों को मापने से आपका डिज़ाइन अच्छी तरह से संरचित रहेगा और डेवलपर्स कोड पर ध्यान केंद्रित करेंगे। आपके कोड पर बेहतर टिप्पणियाँ, Javacode-like, प्रलेखन में सुधार करने में भी मदद कर सकता है।

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

Answer 7

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

Answer 8

अपने बॉस की मदद करें, खुद की मदद करें

आप इस अनुरोध पर प्रतिक्रिया या कार्रवाई कर सकते हैं।

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

प्रश्न को फिर से पढ़ना

यदि आप प्रश्न को कुछ इस तरह से फिर से लिखना चाहते थे,

"क्या मैं उपकरण का एक सूट खरीद या अन्यथा प्राप्त कर सकता हूं जो कि सॉफ्टवेयर से संबंधित कम उत्पादकता कार्यों में से कई को स्वचालित रूप से स्वचालित कर सकता है?"

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

CASE Revisited

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

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

बिक्री के लिए उपकरण

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

आईडीई एकीकरण वर्ष 2012 के मामले के बराबर होने का एक और अवसर है। यदि आप एक Microsoft डेवलपमेंट हाउस हैं, तो Visual Team Studio के पास ऐसे उपकरण हैं, जो इसी तरह के हैं जो Rational बनाए गए हैं। उनके पास कुछ राउंड ट्रिप सॉफ्टवेयर इंजीनियरिंग, कक्षाओं से यूनिट टेस्ट स्टब्स की पीढ़ी, स्रोत नियंत्रण प्रणालियों के साथ एकीकरण और टीम सहयोग के लिए उपकरणों का एक गुच्छा है।

ओपन सोर्स टूल्स

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

Iterative इंक्रीमेंटल टूल अडॉप्शन

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

क्लाउड टूल सॉल्यूशंस

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

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

Answer 9

एक बात जो मैं यहाँ उत्कृष्ट जवाबों से जोड़ूंगा, वह यह है कि आप यह समझने में लाभान्वित हो सकते हैं कि आप "अपनी विकास प्रक्रिया में सुधार" कैसे करना चाहते हैं।

पिछले 20 वर्षों में भारी रुझान बाजार के लिए समय के लिए सॉफ्टवेयर विकास का अनुकूलन करने के लिए किया गया है। "फुर्तीली", "दुबला", DevOps, TDD, BDD - वे सभी जल्द से जल्द दरवाजे से गुणवत्ता वाले सॉफ़्टवेयर प्राप्त करने के बारे में हैं।

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

तो, शायद अपने बॉस से पूछें कि वह क्या अनुकूलन करने की कोशिश कर रहा है।

अनुभव से, CASE टूल के साथ काम करना तेजी से कोड के साथ काम करने से अधिक कठिन हो जाता है - खासकर जब समस्या वाले डोमेन के साथ काम करना जो औसत से अधिक जटिल हैं। प्रोजेक्ट "बैंकिंग" प्रोजेक्ट होना बंद हो जाता है, और इसके बजाय "इन्सर्ट-ऑफ-केज़-टूल-यहाँ" प्रोजेक्ट बन जाता है।