सॉफ्टवेअर विकास करार मार्गदर्शिका: समाविष्ट करण्यासाठी 15 आवश्यक कलमे

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

सॉफ्टवेअर विकास करारामध्ये कोणत्या कलमांचा समावेश असावा?

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

१. प्रकल्पाची व्याप्ती आणि आवश्यकता

व्याप्ती कलम हे विकसकाने नेमके काय बांधायचे आहे, हे स्पष्टपणे परिभाषित करते. करारामध्ये खालील बाबींचा समावेश असावा:

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

२. अपेक्षित परिणाम आणि टप्पे

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

• प्रत्येक टप्प्यासाठी अपेक्षित परिणाम.
• पूर्ण होण्याची अपेक्षित तारीख.
• कागदपत्रे, डिझाइन्स, कोड, एपीआय, डेटाबेस आणि इतर आउटपुट पुरवावे लागतील.
• एखादा टप्पा पूर्ण झाला आहे की नाही हे ठरवण्यासाठी वस्तुनिष्ठ स्वीकृती मानके.

३. विकासाची कालमर्यादा

करारामध्ये विकास अधिकृतपणे केव्हा सुरू होतो आणि अपेक्षित पूर्ण होण्याची किंवा लॉन्चची तारीख केव्हा आहे, हे नमूद केलेले असावे. टाइमलाइनमध्ये अवलंबित्व (dependencies) देखील नमूद केलेले असावे. डेव्हलपर्सना क्लायंटकडून API क्रेडेंशियल्स, ब्रँडिंग साहित्य, तांत्रिक माहिती, विद्यमान सिस्टीममध्ये प्रवेश किंवा लेगसी डेटाची आवश्यकता असू शकते.

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

४. शुल्क आणि पेमेंटच्या अटी

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

किंमत ठरवण्याचे दोन सामान्य मॉडेल खालीलप्रमाणे आहेत:

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

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

५. चाचणी आणि स्वीकृती

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

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

६. बौद्धिक संपदा मालकी

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

• कस्टम कोड: ग्राहकासाठी खास विकसित केलेला कोड.
• पूर्व-अस्तित्वात असलेली बौद्धिक मालमत्ता: विकसकाच्या मालकीची असलेली साधने, लायब्ररी, फ्रेमवर्क किंवा कोड.
• थर्ड-पार्टी सॉफ्टवेअर: बाह्य विक्रेत्यांद्वारे नियंत्रित घटक.
• ओपन-सोर्स घटक: लागू असलेल्या ओपन-सोर्स परवान्याद्वारे नियंत्रित सॉफ्टवेअर.

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

हे सुद्धा वाचा: बौद्धिक संपदा अधिकारांचा दावा कसा करावा

७. सोर्स कोड आणि रिपॉझिटरी ऍक्सेस

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

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

८. ओपन-सोर्स आणि थर्ड-पार्टी सॉफ्टवेअर

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

करारामध्ये मालकी हक्काच्या सॉफ्टवेअरसाठी अवांछित जबाबदाऱ्या निर्माण करणाऱ्या परवान्यांच्या वापरावर निर्बंध असू शकतात. GPL किंवा AGPL सारख्या कॉपीलेफ्ट परवान्यांच्या बाबतीत विशेष लक्ष देण्याची आवश्यकता असू शकते. तृतीय-पक्ष सदस्यता, API, होस्टिंग, व्यावसायिक सॉफ्टवेअर आणि इतर बाह्य सेवांसाठी पैसे कोण देणार, हे देखील करारामध्ये स्पष्ट केले पाहिजे.

९. गोपनीयता आणि डेटा संरक्षण

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

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

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

१०. सुरक्षा आणि अनुपालन

सॉफ्टवेअर डेव्हलपमेंट प्रोजेक्टमध्ये सुरक्षेला दुय्यम बाब मानले जाऊ नये. करारानुसार डेव्हलपरला मान्यताप्राप्त सुरक्षा पद्धतींचे पालन करणे बंधनकारक असू शकते, ज्यामध्ये OWASP टॉप 10 द्वारे ओळखल्या गेलेल्या सामान्य धोक्यांना सामोरे जाणाऱ्या उपायांचा समावेश आहे.

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

११. वॉरंटी आणि देखभाल

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

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

१२. नुकसानभरपाई आणि दायित्वाची मर्यादा

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

त्याच वेळी, अनेक करारांमध्ये एकूण दायित्वाची कमाल मर्यादा समाविष्ट असते. ही मर्यादा, मागील ६ किंवा १२ महिन्यांसारख्या विशिष्ट कालावधीत भरलेल्या शुल्काशी जोडलेली असू शकते. गोपनीयतेचा भंग, बौद्धिक मालमत्तेचे उल्लंघन किंवा हेतुपुरस्सर गैरवर्तन यांसारख्या काही बाबी सामान्य करारात्मक दायित्वापेक्षा वेगळ्या पद्धतीने हाताळल्या जाऊ शकतात. दायित्वाचे नेमके वाटप वाटाघाटी करून निश्चित केले पाहिजे आणि त्याची नोंद केली पाहिजे.

१३. समाप्ती आणि संक्रमण

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

• जेव्हा एखादा पक्ष कराराचा गंभीर भंग करतो आणि १५ ते ३० दिवसांसारख्या विनिर्दिष्ट निवारण कालावधीत समस्या दुरुस्त करण्यात अयशस्वी ठरतो, तेव्हा भंगामुळे करार संपुष्टात आणण्याची परवानगी दिली जाऊ शकते.
• सोयीनुसार करार संपुष्टात आणण्याच्या कायद्यानुसार , पूर्व लेखी सूचना देऊन, कोणत्याही पक्षाला कराराचा भंग झाल्याचे सिद्ध न करता करार समाप्त करण्याची परवानगी असू शकते.

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

१४. कर्मचाऱ्यांची मागणी न करणे आणि त्यांचा वापर

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

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

१५. विवाद निराकरण आणि सामान्य अटी

अगदी चांगल्या प्रकारे तयार केलेल्या करारामुळेही मतभेद निर्माण होऊ शकतात. विवाद-निवारण प्रक्रिया त्यांना हाताळण्यासाठी एक संरचित मार्ग प्रदान करते. संबंधित पक्ष प्रथम प्रकल्प व्यवस्थापक किंवा वरिष्ठ प्रतिनिधींना सद्भावनेने विषयावर चर्चा करण्यास सांगू शकतात.

जर वाद मिटला नाही, तर न्यायालयीन कार्यवाहीपूर्वी मध्यस्थी किंवा लवादाची तरतूद करारामध्ये असू शकते. करारामध्ये हे देखील नमूद केले पाहिजे:

• लागू कायदा.
• अधिकारक्षेत्र.
• जेथे लागू असेल तेथे लवाद किंवा मध्यस्थी प्रक्रिया.
• औपचारिक सूचना आवश्यकता.
• दुरुस्ती प्रक्रिया.
• अनपेक्षित घटना.

सॉफ्टवेअर विकास करार तपासणी सूची

व्यवसायांनी कोणत्या सामान्य चुका टाळल्या पाहिजेत?

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

निष्कर्ष

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

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