फंक्शन पॉइंट पद्धत गणना उदाहरण. फंक्शन पॉइंट पद्धत. प्रत्येक गट सदस्य आणि इतरांमधील कनेक्शन

चेरचर 12.04.2019

संगणकावर व्हायबर

सॉफ्टवेअर सीमा परिभाषित करणे

विकसित केलेले सॉफ्टवेअर पूर्णपणे स्थानिक आहे आणि ते स्थानिक किंवा जागतिक नेटवर्कद्वारे इतर सॉफ्टवेअरसह डेटा एक्सचेंजसाठी प्रदान करत नाही.

डेटा कार्यक्षमतेची ओळख आणि मूल्यांकन (ILF, EIF)

सॉफ्टवेअर एका अंतर्गत लॉजिकल फाइल (ILF) सह कार्य प्रदान करते. IN ही फाइलसॉफ्टवेअरसाठी आवश्यक असलेली सर्व माहिती संग्रहित केली आहे: मॅट्रिक्सचा आकार, त्याचे गुणांक, गणनेची अचूकता आणि प्रारंभिक अंदाजे.

अंतर्गत लॉजिकल फाइलच्या डेटा एलिमेंट प्रकारांची (डीईटी) संख्या सहा आहे:

1. n - मॅट्रिक्समधील पंक्तींची संख्या. पंक्तींची संख्या स्तंभांच्या संख्येइतकी आहे, कारण गणना तथाकथित चौरस मॅट्रिक्ससाठी केली जाते.

2. मास - दिलेला मॅट्रिक्स.

3. - निर्दिष्ट अचूकता.

4. x 0 - प्रारंभिक अंदाजे.

5. - गणना परिणाम - कमाल eigenvalueदिलेले मॅट्रिक्स.

6. k - दिलेल्या अचूकतेसह मॅट्रिक्सच्या कमाल इजेनव्हॅल्यूची गणना करण्यासाठी आवश्यक पुनरावृत्तीची संख्या.

अंतर्गत लॉजिकल फाइलसाठी रेकॉर्ड घटक प्रकारांची (RETs) संख्या चार आहे:

1. मास - मॅट्रिक्स.

2. x 0 - सदिश.

3. n, k - पूर्णांक.

4. , - वास्तविक संख्या.

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

या सॉफ्टवेअरमध्ये बाह्य इंटरफेस फाइल्स (ELF) नाहीत.

व्यवहार कार्यक्षमतेची ओळख आणि मूल्यमापन (EI, EO, EQ)

हे सॉफ्टवेअर दोन बाह्य इनपुट (EI): कीबोर्ड इनपुट आणि फाइल इनपुट प्रदान करते.

कीबोर्ड इनपुटसाठी, डेटा घटक प्रकारांची संख्या (DETs) पाच आहे: Mas, x 0 , n आणि "कीबोर्डवरील डेटा प्रविष्ट करा" बटण. वापरलेल्या प्रकारांची संख्या (FTR) पाच आहे.

साठी अडचण पातळी या प्रकारच्याइनपुट उच्च म्हणून परिभाषित केले आहे.

फाइल इनपुटसाठी, परिणाम वापरण्याशिवाय कीबोर्ड इनपुटसाठी सारखेच असतात वर्ण स्ट्रिंगडेटा लोड करण्यासाठी फाइल नाव आणि संबंधित बटणासह. म्हणजे, DET = 6, FTR = 5. या प्रकारच्या इनपुटसाठी अडचण पातळी उच्च म्हणून परिभाषित केली जाते.

या सॉफ्टवेअरमध्ये फक्त एक बाह्य विनंती (EQ) आहे - प्रविष्ट केलेल्या डेटाच्या अचूकतेसाठी विनंती. यासाठी, व्हेरिएबल्स Mas, x 0 , n आवश्यक आहेत, त्यांची मूल्ये त्यानुसार तपासली जातात: मॅट्रिक्ससाठी - अवैध चिन्हे प्रविष्ट करण्यासाठी तपासा - चिन्हे किंवा अक्षरे, प्रारंभिक अंदाजासाठी - शून्य समानतेसाठी, अवैध वर्ण प्रविष्ट करणे, मॅट्रिक्सच्या आकारासाठी - निर्दिष्ट मर्यादेशी संबंधित, अचूकतेसाठी - ऑर्डर मर्यादा. अशा प्रकारे, DET=4, FTR=3. आउटपुट माहिती या विनंतीचे- “प्रविष्ट केलेली माहिती बरोबर आहे” किंवा “प्रविष्ट केलेली माहिती चुकीची आहे.” म्हणजे, DET=FTR=1. अशा प्रकारे, बाह्य विनंतीची जटिलता पातळी मध्यम म्हणून परिभाषित केली जाते.

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

फाईलमध्ये डेटा लिहिण्यासाठी, DET डेटा घटक प्रकारांची संख्या पाच आहे: कमाल eigenvalue, निर्दिष्ट अचूकता, पुनरावृत्तीची संख्या, फाइलचे नाव आणि "फाइलवर परिणाम लिहा" बटण. वापरलेल्या FTR प्रकारांची संख्या चार आहे. अशा प्रकारे, फाईलच्या आउटपुटच्या जटिलतेची पातळी मध्यम म्हणून परिभाषित केली जाते.

सामान्यीकरण घटकाचे निर्धारण (VAF)

फंक्शन पॉइंट्सच्या अप्रमाणित संख्येची गणना करूया.

टेबल 1. UFPC गणना

सिस्टमची मुख्य वैशिष्ट्ये:

· सॉफ्टवेअर स्वायत्त वैयक्तिक संगणकावर एकल पॅकेज म्हणून कार्यान्वित केले जाते - 0.

· सॉफ्टवेअर आणि सिस्टम घटकांमध्ये डेटा हस्तांतरित केला जात नाही - 0.

· सॉफ्टवेअर कार्यप्रदर्शन आणि डिझाइन आवश्यकता स्थापित आणि पुनरावलोकन केले गेले आहेत, परंतु त्यांना पूर्ण करण्यासाठी कोणत्याही विशेष उपायांची आवश्यकता नाही - 1.

· संसाधनांच्या वापरावर कोणतेही स्पष्ट किंवा अस्पष्ट निर्बंध नाहीत - 0.

· पीक व्यवहार कालावधी अपेक्षित नाही - 0.

· परस्पर व्यवहारांची जटिलता - 30% पेक्षा जास्त परस्परसंवादीपणे प्रक्रिया केली जाते - 5.

· साठी सॉफ्टवेअरची कार्यक्षमता अंतिम वापरकर्ता - 2.

· थेट अद्यतनअनुपस्थित - 0.

· डेटा प्रोसेसिंगची जटिलता - 3.

· सॉफ्टवेअरमध्ये डिझाइन केलेला कोड नाही पुन्हा वापर - 0.

· नाही विशेष आवश्यकतावापरकर्ता आणि विशेष आवश्यकता नाही स्थापना कार्यक्रम - 0.

· वापरणी सोपी - १.

· डिझाइन दरम्यान, सॉफ्टवेअर स्थापित करण्याच्या आवश्यकता विचारात घेतल्या गेल्या, आणि सॉफ्टवेअर फक्त तत्सम (सुसंगत) हार्डवेअर आणि/किंवा सॉफ्टवेअरवर कार्यान्वित केले जाऊ शकते - 2.

· सॉफ्टवेअर बदलणे प्रदान केलेले नाही - 0.

सामान्यीकरण घटकाची गणना करा (VAF) खालीलप्रमाणे:

VAF=0.65+0.01*TDI=0.65+0.01*(1+5+2+3+2)=0.78

फंक्शन पॉइंट्सच्या सामान्यीकृत संख्येची गणना

फंक्शन पॉइंट्सची सामान्यीकृत संख्या अशी परिभाषित केली आहे:

APFC=UPFC*VAF=35*0.78=26.3

पंक्तींच्या संख्येचा अंदाज लावत आहे स्रोत कोडबॅकफायर पद्धत वापरणे

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

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

माहितीचे मापदंड खालीलप्रमाणे परिभाषित केले आहेत:

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

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

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

फाइल्सची संख्या.पुरेशा मोठ्या डेटाबेसचा भाग असलेल्या मुख्य लॉजिकल फाइल्सची (डेटाचे तार्किक गट) संख्या मोजली जाते.

क्रमांक बाह्य इंटरफेस. सर्व मशीन-वाचनीय इंटरफेस मोजले जातात (उदाहरणार्थ, डेटा फाइल्समध्ये प्रवेश बाह्य मीडिया, ज्याचा वापर इतर प्रणालींमध्ये माहिती प्रसारित करण्यासाठी केला जातो).

प्रत्येकाला संख्यात्मक मूल्यपॅरामीटरला एक योग्य वेटिंग फॅक्टर नियुक्त केला जातो जो विचारात असलेल्या पॅरामीटरची अंमलबजावणी करणे किती कठीण किंवा सोपे आहे हे लक्षात घेतो. स्पष्टपणे, जटिलतेचे असे मूल्यांकन एक तज्ञ आणि त्याऐवजी व्यक्तिनिष्ठ आहे.

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

कोणताही प्रभाव नाही - 0.

यादृच्छिक प्रभाव -1.

मध्यम प्रभाव - 2.

सरासरी प्रभाव - 3.

लक्षणीय प्रभाव - 4.

लक्षणीय प्रभाव - 5.

या स्केलचा वापर करून, उत्पादनाच्या कार्याची वैशिष्ट्ये निर्धारित करणाऱ्या खालील घटकांपैकी प्रत्येकाच्या प्रभावाच्या पातळीचे देखील कुशलतेने मूल्यांकन केले जाते:

1. अयशस्वी झाल्यानंतर सिस्टमला विश्वसनीय बॅकअप आणि त्यानंतरच्या पुनर्प्राप्तीची आवश्यकता आहे का?

2. डेटा ट्रान्सफर आवश्यक आहे का?

3. वितरित प्रक्रिया कार्ये आहेत का?

4. सॉफ्टवेअर उत्पादनाची कामगिरी गंभीर आहे का?

5. प्रणाली विद्यमान किंवा अधिक जटिल ऑपरेटिंग वातावरणात कार्य करेल?

6. प्रणालीला ऑनलाइन डेटा एंट्री आवश्यक आहे का?

7. ऑनलाइन व्यवहार प्रविष्ट करणे आवश्यक आहे जे तयार करण्यास अनुमती देईल विविध स्क्रीनअनेक ऑपरेशन्ससाठी लागू केले?

8. मास्टर फाइल ऑनलाइन अपडेट केली आहे का?

9. आहेत जटिल प्रवेशद्वार, आउटपुट, फाइल्स किंवा विनंत्या?

10. आहेत जटिल अल्गोरिदमडेटा प्रक्रिया

वजन गुणांक तक्त्यामध्ये दिले आहेत.

गणना प्रक्रिया

1. सिस्टम पॅरामीटर्स निश्चित करा (इनपुट/आउटपुट)

2. पॅरामीटर अंमलबजावणीची जटिलता लक्षात घेऊन प्रत्येक पॅरामीटरला त्याचे स्वतःचे वजन घटक नियुक्त केले जातात.

3. सर्व पॅरामीटर्ससाठी एकूण परिणाम निश्चित करा

4. FT ची संख्या सूत्र FT=भव्य एकूण (0.65+0.01 गुणांकांची बेरीज) द्वारे निर्धारित केली जाते

श्रम उत्पादकता, एका बिंदूच्या विकासाची किंमत, प्रति बिंदू कागदपत्रांच्या पृष्ठांची संख्या इत्यादी निर्धारित करण्यासाठी FT चा वापर केला जाऊ शकतो.

प्रयोगशाळा कार्य क्रमांक 4

आकार आणि जटिलता अंदाज सॉफ्टवेअरकॉसमॉस पॅकेज वापरून फंक्शन पॉइंट पद्धत

कामाचा उद्देश

फंक्शन पॉइंट मेथड वापरून सॉफ्टवेअर सिस्टीमच्या आकारमानाचा आणि जटिलतेचा अंदाज घेण्याच्या संकल्पनांशी परिचित व्हा आणि COSMOS प्रोग्रामसह काम करताना व्यावहारिक कौशल्ये मिळवा.

फंक्शन पॉइंट पद्धत वापरून गणना

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

वर वर्णन केल्याप्रमाणे पाच चरणांमध्ये फंक्शन पॉइंट्सची संख्या मोजू.

1. या PS च्या सीमा स्थापित करण्यात अडचणी येत नाहीत, कारण ते पूर्णपणे स्थानिक आहे आणि ते इतर PS सह डेटा एक्सचेंजसाठी प्रदान करत नाही.

2. निर्देशिका माहिती संचयित करण्यासाठी PS मध्ये एक अंतर्गत लॉजिकल फाइल (ILF) असते. शिवाय, डेटा एकतर मध्ये संग्रहित केला जाऊ शकतो नियमित फाइल, आणि DBMS टेबलमध्ये.

तांदूळ. 1. टेलिफोन निर्देशिकेचा स्क्रीन फॉर्म

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

टेलिफोन नंबरचे स्वरूप (“फोन”, “आडनाव”, “पत्ता”) विचारात न घेता अंतर्गत लॉजिकल फाइलच्या डेटा एलिमेंट प्रकारांची संख्या (डीईटी) तीन इतकी असेल. अशा प्रकारे, अंतर्गत लॉजिकल फाइलची जटिलता पातळी कमी आहे.

या सॉफ्टवेअरमध्ये बाह्य इंटरफेस फाइल्स (EIF) नाहीत.

3. PS मध्ये दोन बाह्य इनपुट (EI): “एड एंट्री” आणि “रेकॉर्ड हटवा”, कारण ही दोन PS फंक्शन्स अंतर्गत लॉजिकल फाइलमधील डेटा बदलतात. बाह्य इनपुट "रेकॉर्ड जोडा" हे एका अंतर्गत तार्किक फाइलचा संदर्भ देते आणि त्यात पाच डेटा घटक असतात (फील्ड "फोन", "आडनाव", "पत्ता", "जोडा" बटण आणि रेकॉर्ड जोडण्याच्या वस्तुस्थितीची पुष्टी करणारा संदेश), या इनपुटच्या जटिलतेची पातळी कमी आहे (तक्ता 4.2 पहा). त्याचप्रमाणे, एक FTR आणि पाच DETs (फील्ड “फोन”, “आडनाव”, “पत्ता”, “हटवा” बटण आणि पुष्टी करणारा संदेश असल्यामुळे “एंट्री हटवा” या बाह्य इनपुटच्या जटिलतेची पातळी देखील कमी आहे. रेकॉर्ड हटविण्याची वस्तुस्थिती).

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

PS मध्ये एक बाह्य आउटपुट (EO) देखील आहे: विद्यमान फोन नंबरसह एंट्री जोडण्याचा प्रयत्न करताना सूचना संदेशाचे आउटपुट. याची अडचण पातळी बाह्य आउटपुट- कमी, कारण त्यात एक FTR आणि दोन DET आहेत: फोन नंबर आणि संदेश स्वतः.

आम्ही टेबलमध्ये प्राप्त डेटाचा सारांश देतो. 1. आणि फॉर्म्युला 1 वापरून UFPC फंक्शन पॉइंट्सच्या मानक नसलेल्या संख्येची गणना करा.

तक्ता 1. UFPC टेलिफोन डिरेक्टरींची संख्या मोजण्यासाठी डेटा

4. आता टेबल वापरून गणना करू. 2. आणि सूत्रे (2) एकूण प्रभावाची डिग्री (TDI) सामान्य वैशिष्ट्येप्रणाली आणि सामान्यीकरण घटक (VAF).

परिणामी, आम्हाला कळेल की टेलिफोन निर्देशिकेसाठी ते महत्त्वाचे आहे खालील वैशिष्ट्ये:

· “संवाद डेटा एंट्री”, ज्याचे मूल्यमापन 5 च्या वजनाने केले जाते, कारण PS मधील सर्व 100% व्यवहार परस्परसंवादी असतात;

· “अंतिम वापरकर्त्यासाठी कार्यक्षमता”, ज्याचे मूल्यांकन 1 च्या वजनाने केले जाते, कारण सॉफ्टवेअरमध्ये कार्ये असतात स्वयंचलित स्थापनाकर्सर, स्क्रोलिंग आणि माउस इंटरफेस;

· “वापरण्याची सुलभता”, ज्याला 5 वजनाने रेट केले जाते, कारण PS मध्ये लोडिंग/शटडाउन वगळता सर्व फंक्शन्स स्वयंचलित आहेत आणि तेथे आहे स्वयंचलित पुनर्प्राप्तीचुका नंतर;

· “व्यापकता”, ज्याचे मूल्यांकन 2 वजनाने केले जाते, कारण सॉफ्टवेअर सुसंगत हार्डवेअर/सॉफ्टवेअरवर काम करण्यासाठी डिझाइन केलेले आहे;

· “बदलाची सुलभता”, ज्याचे मूल्यमापन 2 च्या वजनाने केले जाते, कारण सॉफ्टवेअर वापरकर्त्याद्वारे ऑनलाइन राखलेल्या टेबलमध्ये माहिती संग्रहित करते.

उर्वरित वैशिष्ट्ये एकतर उपस्थित नाहीत किंवा दिलेल्या PS साठी काही फरक पडत नाहीत आणि म्हणून त्यांचे वजन 0 च्या बरोबरीचे आहे.

सामान्यीकरण घटक (VAF) म्हणून निर्धारित केले जाते

5. अशाप्रकारे, टेलिफोन निर्देशिकेसाठी फंक्शन पॉइंट्सची सामान्यीकृत संख्या सूत्रानुसार मोजली जाते:

शेवटी, C++ प्रोग्रामिंग भाषा वापरून प्रोग्राम विकसित करणे आवश्यक आहे या वस्तुस्थितीवर आधारित, बॅकफायर पद्धत वापरून स्त्रोत कोडच्या ओळींच्या संख्येचा अंदाज लावूया:

अशा प्रकारे, पूर्ण झालेल्या टेलिफोन डिरेक्ट्री प्रोग्राममध्ये C++ प्रोग्रामिंग भाषेतील स्रोत कोडच्या अंदाजे 975 ओळी असतील.

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

अतिरिक्त कार्ये

1. सामान्य प्रकारच्या प्रणालींसाठी मूलभूत SOSOMO च्या समीकरणांवर आधारित, विकासाच्या श्रम तीव्रतेचे अवलंबन तयार करा सॉफ्टवेअर प्रकल्पजेव्हा कोड व्हॉल्यूम 10 ते 120 TSIC बदलते तेव्हा त्याच्या आकारावरून.

2. सामान्य प्रकारच्या सिस्टीमसाठी मूलभूत SOSOMO च्या समीकरणांवर आधारित, जेव्हा कोड व्हॉल्यूम 10 ते 120 TSIC पर्यंत बदलतो तेव्हा सॉफ्टवेअर प्रोजेक्टच्या विकासाच्या वेळेचे अवलंबन त्याच्या आकारावर तयार करा.

3. सामान्य प्रकारच्या प्रणालींसाठी मूलभूत SOSOMO च्या समीकरणांच्या आधारे, जेव्हा त्याची मूल्ये 10 ते 200 FM पर्यंत बदलतात तेव्हा कामगार खर्चावर सॉफ्टवेअर प्रकल्पाच्या विकासाच्या वेळेचे अवलंबन तयार करा.

4. सामान्य प्रकारच्या प्रणालींसाठी मूलभूत SOSOMO च्या समीकरणांवर आधारित, सॉफ्टवेअरच्या आकारावर सरासरी श्रम उत्पादकतेचे अवलंबित्व तयार करा जेव्हा त्याच्या कोडची मात्रा 10 ते 120 TSIC पर्यंत बदलते.

5. सामान्य प्रकारच्या प्रणालींसाठी मूलभूत SOSOMO च्या समीकरणांच्या आधारावर, जेव्हा कोड व्हॉल्यूम 10 ते 120 TSIC वरून बदलतो तेव्हा त्याच्या आकारावर सरासरी स्टाफिंग पातळीचे अवलंबन तयार करा.

6. सॉफ्टवेअर उत्पादनाच्या वैयक्तिक कार्यात्मक ब्लॉक्सच्या विकासासाठी प्रयत्नांच्या वितरणाचे मॅट्रिक्स आहे. प्रत्येक ब्लॉक विकसित करण्याची जटिलता, प्रत्येक काम (सर्व ब्लॉकसाठी) विकसित करण्याची जटिलता आणि संपूर्ण सॉफ्टवेअर उत्पादन निश्चित करा. प्राप्त परिणाम आणि मूलभूत SOSOMO च्या समीकरणांवर आधारित, उत्पादनाच्या विकासाचा कालावधी, स्त्रोत कोडच्या ओळींमध्ये त्याचा आकार आणि कलाकारांची आवश्यक कर्मचारी संख्या निर्धारित करा. क्रियाकलापाच्या प्रकारानुसार आणि संपूर्ण प्रणालीसाठी कामाची किंमत निश्चित करा.

१२.३.४. फंक्शन पॉइंट पद्धत

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

सॉफ्टवेअर उत्पादनासाठी फंक्शनल पॉइंट्स (FP) च्या संख्येचा अंदाज सॉफ्टवेअर उत्पादनाच्या माहिती क्षेत्राचे विश्लेषण आणि त्याच्या भविष्यातील कार्याच्या वैशिष्ट्यांचा अभ्यास करण्याच्या परिणामी निर्धारित केलेल्या डेटाच्या आधारे काढला जातो.

सॉफ्टवेअर डेव्हलपमेंटच्या श्रम तीव्रतेची गणना करण्याची प्रक्रिया:

प्रमाण आणि जटिलतेचे निर्धारण कार्यात्मक प्रकारअनुप्रयोग;

प्रत्येक कार्यात्मक प्रकाराशी संबंधित प्राथमिक डेटा (DET), प्राथमिक रेकॉर्ड (RET) आणि फाइल प्रकार लिंक्स (FTR) ची संख्या निश्चित करणे;

जटिलतेचे निर्धारण (डीईटी, आरईटी आणि एफटीआरच्या संख्येवर अवलंबून);

अनुप्रयोग कार्यात्मक बिंदूंची संख्या मोजणे;

सिस्टमची सामान्य वैशिष्ट्ये लक्षात घेऊन फंक्शन पॉइंट्सची संख्या मोजणे

विकास श्रम तीव्रतेचे मूल्यांकन (विविध सांख्यिकीय डेटा वापरुन).

फंक्शन प्रकारांचा समावेश आहे खालील घटकविकसित प्रणालीचे अनुप्रयोग:

इंटर्नल लॉजिकल फाइल (ILF) - प्राथमिक प्रक्रियेद्वारे ॲप्लिकेशनमध्ये ठेवलेल्या तार्किकदृष्ट्या परस्परसंबंधित डेटा रेकॉर्डचा एक ओळखण्यायोग्य संग्रह;

बाह्य इंटरफेस फाइल (बाह्य इंटरफेस फाइल, EIF) - तार्किकदृष्ट्या परस्परसंबंधित डेटा रेकॉर्डचा एक ओळखण्यायोग्य संग्रह जो दुसऱ्या ऍप्लिकेशनला प्रसारित केला जातो किंवा प्राप्त होतो आणि या ऍप्लिकेशनच्या बाहेर ठेवला जातो;

ऍप्लिकेशन इनपुट घटक (बाह्य इनपुट, एल) - ऍप्लिकेशन इनपुट माहितीच्या प्रक्रियेशी संबंधित एक प्राथमिक प्रक्रिया - इनपुट दस्तऐवजकिंवा स्क्रीन फॉर्म. प्रक्रिया केलेला डेटा एक किंवा अधिक ILF शी संबंधित असू शकतो;

ऍप्लिकेशन आउटपुट घटक (बाह्य आउटपुट, ईओ) - ऍप्लिकेशनच्या आउटपुट माहितीवर प्रक्रिया करण्याशी संबंधित एक प्राथमिक प्रक्रिया - आउटपुट अहवाल, दस्तऐवज, स्क्रीन फॉर्म;

बाह्य क्वेरी (EQ) - विनंती/प्रतिसाद संयोजन असलेली प्राथमिक प्रक्रिया जी प्राप्त केलेल्या डेटाच्या गणनेशी किंवा ILF (डेटाबेस) अद्यतनित करण्याशी संबंधित नाही.

माहितीचे मापदंड खालीलप्रमाणे परिभाषित केले आहेत.

· वापरकर्ता लॉगिनची संख्या.भिन्न, अनुप्रयोग-विशिष्ट डेटा तयार करणाऱ्या प्रत्येक वापरकर्ता इनपुटची गणना केली जाते. इनपुट वापरकर्त्याच्या विनंत्यांपेक्षा वेगळे असले पाहिजेत, ज्याची स्वतंत्रपणे गणना केली जाते.

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

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

· फाइल्सची संख्या.मुख्य लॉजिकल फाइल्सची संख्या मोजली जाते
कॅच (डेटाचे तार्किक गट), जे बऱ्यापैकी मोठ्या डेटाबेसचा भाग असू शकतात.

· बाह्य इंटरफेसची संख्या.सर्व मशीन-वाचनीय इंटरफेस मोजले जातात (उदाहरणार्थ, बाह्य मीडियावरील डेटा फाइल्समध्ये प्रवेश करणे ज्याचा वापर इतर सिस्टममध्ये माहिती हस्तांतरित करण्यासाठी केला जातो).

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

· कोणताही प्रभाव नाही - 0.

· यादृच्छिक प्रभाव -1.

· मध्यम प्रभाव - 2.

· सरासरी प्रभाव - 3.

· लक्षणीय प्रभाव - 4.

· लक्षणीय प्रभाव - 5.

1. प्रणालीला विश्वसनीय बॅकअप आणि त्यानंतरची आवश्यकता आहे का
अपयशानंतर पुनर्प्राप्ती?

2. डेटा ट्रान्सफर आवश्यक आहे का?

3. वितरित प्रक्रिया कार्ये आहेत का?

4. सॉफ्टवेअर उत्पादनाची कामगिरी गंभीर आहे का?

5. प्रणाली विद्यमान किंवा अधिक जटिल ऑपरेटिंग वातावरणात कार्य करेल?

6. प्रणालीला ऑनलाइन डेटा एंट्री आवश्यक आहे का?

7. अनेक व्यवहारांसाठी वेगवेगळ्या स्क्रीन तयार करता येतील अशा ऑनलाइन व्यवहार नोंदीची आवश्यकता आहे का?

8. मास्टर फाइल ऑनलाइन अपडेट केली आहे का?

9. इनपुट, आउटपुट, फाइल्स किंवा क्वेरी क्लिष्ट आहेत का?

10. डेटा प्रोसेसिंग अल्गोरिदम जटिल आहेत का?

11. तयार केलेले प्रोग्राम पुन्हा वापरायचे आहेत का?

12. प्रकल्पामध्ये प्रणालीचे कार्यान्वित करणे आणि त्याचे रुपांतर करणे समाविष्ट आहे का?

13. सिस्टम कॉन्फिगरेशन वेगवेगळ्या संस्थांमध्ये त्याच्या स्थापनेसाठी परवानगी देते का?

14. प्रकल्प वापरकर्त्याच्या सोयीसाठी आणि बदल करण्यास सुलभतेसाठी प्रदान करतो का?

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

उदाहरण ४. सॉफ्टवेअर उत्पादनासाठी फंक्शन पॉइंट्सची संख्या निश्चित करणे

उदाहरण 4 लागू करण्यासाठी मार्गदर्शक तत्त्वे.

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

कार्यात्मक दृष्टिकोनाचा विकास.

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

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

हे लक्षात घेतले पाहिजे की दोन्ही पद्धती (FT आणि XT) सॉफ्टवेअर उत्पादनाची समान बाजू प्रतिबिंबित करतात - त्याची "कार्यक्षमता" आणि "उपयुक्तता". दोन्ही दृष्टिकोन सामान्य अभियांत्रिकी संगणकीय समस्या आणि माहिती प्रणालीसाठी समान परिणाम देतात. अधिक साठी जटिल प्रणालीविशेषतः रिअल टाइममध्ये, XT चे एकूण मूल्य FT वापरून निर्धारित केलेल्या एकूण मूल्यापेक्षा 20-35% जास्त आहे.

सॉफ्टवेअर प्रकल्प मूल्यांकनासाठी आकार-आधारित आणि कार्य-आधारित दृष्टिकोन संरेखित करणे.

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

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

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

तक्ता 12.3.10 – फंक्शन पॉइंट मेट्रिक्स आणि कोडच्या रेषा यांच्यातील सहसंबंध

प्रोग्रामिंग भाषा

असेंबलर

ऑब्जेक्ट ओरिएंटेड भाषा

चौथ्या पिढीच्या भाषा

कोड जनरेटर

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

12.3.5 विकास संघाच्या उत्पादकतेचे मूल्यांकन करण्यासाठी दृष्टीकोन

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

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

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

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

सर्वात सोपा दृष्टीकोन या गृहीतावर आधारित आहे की कामाच्या प्रक्रियेदरम्यान उद्भवलेल्या समस्यांचे निराकरण करण्यासाठी कलाकारांच्या गटातील कर्मचार्यांना काम करताना एकमेकांशी संवाद साधण्यास भाग पाडले जाते. या संप्रेषणामुळे कामगारांचा उत्पादक वेळ कमी होतो आणि उत्पादक वेळेतील सापेक्ष घट च्या गुणांक k द्वारे मोजले जाऊ शकते. क्रमांक माहिती लिंक्स, या प्रकरणात उद्भवणारे, एकतर संभाव्य म्युच्युअल कनेक्शनची संख्या म्हणून अंदाज लावला जाऊ शकतो, n बाय 2 च्या संयोजनांच्या संख्येइतका, किंवा असे मानले जाऊ शकते की प्रत्येकजण स्वतःचे निराकरण करतो वैयक्तिक समस्याउर्वरित n - 1 विकास सहभागींसह. म्हणून, कलाकारांच्या गटाच्या श्रम उत्पादकतेचे मूल्यांकन करताना, दोन्ही परस्परसंवाद पर्यायांचा विचार करणे उचित आहे.

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

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

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

गटातील लोकांचे संबंध लक्षात घेऊन (दोन बदल);

कामगार उत्पादकतेचे मूल्यांकन करताना फिलिपचा कायदा विचारात घेणे;

इष्टतम विकास कालावधीपासून विचलन झाल्यास प्रकल्प मापदंडांचा अंदाज घेण्यासाठी पुतनाम मॉडेलचा वापर.

विकास कार्यसंघाच्या उत्पादकतेचे अधिक तपशीलवार मूल्यांकन करण्यासाठी या पद्धतींचा विचार करूया.

१२.३.५.१. गटातील विकासकांमधील संबंधांची संख्या लक्षात घेऊन

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

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

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

गटाची इष्टतम रचना निश्चित करणे, गटाची उत्पादकता जास्तीत जास्त कधी असेल, तसेच परफॉर्मर्सची संख्या निश्चित करणे, ज्यावर गटाची श्रम उत्पादकता 0 पर्यंत घसरेल हे निश्चित करणे स्वारस्यपूर्ण आहे. अर्थात, ही मूल्ये असतील पॅरामीटर k च्या मूल्याद्वारे निर्धारित केले जाते.

उदाहरण 5.1. संवाद साधणाऱ्या कलाकारांच्या गटाची श्रम उत्पादकता निश्चित करणे

उदाहरण 5.1 अंमलबजावणीसाठी मार्गदर्शक तत्त्वे.

आम्ही असे गृहीत धरतो की गटाचा समावेश आहे दिलेला क्रमांक n विकासक, ज्यांच्यामध्ये संबंध आहेत. अशा पेअरवाइज कनेक्शनची संख्या n बाय 2 च्या संयोगांची संख्या म्हणून परिभाषित केली जाते आणि ती n*(n-1)/2 च्या समान असते. एका नातेसंबंधावर खर्च केलेल्या वेळेचा (एकूण कामाच्या वेळेच्या संबंधात) k ला सापेक्ष वाटा म्हणून घेऊन, एका कर्मचाऱ्याची सरासरी श्रम उत्पादकता आणि गटाची एकूण उत्पादकता, प्रकल्प विकासाचा कालावधी आणि श्रम तीव्रता यावर अवलंबून राहणे निर्धारित करा. गट n मधील कामगारांची संख्या. तसेच कामगारांच्या संख्येचे इष्टतम मूल्य निश्चित करा जे गटाची कमाल एकूण उत्पादकता सुनिश्चित करते. k पॅरामीटरच्या अनेक मूल्यांसाठी गणना केली जाते. पहिल्या कार्यापासून एका परफॉर्मरची श्रम उत्पादकता आणि सॉफ्टवेअर उत्पादनाच्या आकाराचा डेटा घ्या.

कार्य अंमलबजावणी क्रम

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

आणि गटाच्या कामाचा उपयुक्त वेळ

2. मागील परिच्छेदात दिलेली सूत्रे आम्हाला गटाच्या आकारानुसार एका कलाकाराच्या श्रम उत्पादकतेतील बदल निर्धारित करण्यास अनुमती देतात. साहजिकच, समूहाचा आकार जसजसा वाढत जाईल, तसतसे वैयक्तिक PT1 कलाकाराची श्रम उत्पादकता सूत्रानुसार कमी होईल.

या सूत्राच्या आधारे, k पॅरामीटरच्या अनेक मूल्यांसाठी n वर PT1 चे अवलंबन तयार करा. पॅरामीटर k च्या प्रत्येक निवडलेल्या मूल्यासाठी, वैयक्तिक कामगाराची उत्पादकता 0 होईल असा गट आकार निश्चित करा.

3.एका कर्मचाऱ्याची श्रम उत्पादकता जाणून, PTS=n*T1T1 म्हणून PTS गटाची एकूण श्रम उत्पादकता निर्धारित करा.

k या पॅरामीटरच्या समान मूल्यांसाठी गटातील कामगारांच्या संख्येवर एकूण श्रम उत्पादकतेचे अवलंबित्व प्लॉट करा.

4. पॅरामीटर k च्या स्वीकृत मूल्यांसाठी गट आकारातील बदलांवर सॉफ्टवेअर उत्पादन विकासाच्या कालावधीचे अवलंबन तयार करा.

5. व्याख्या इष्टतम आकारगट, गटाची सर्वोच्च एकूण श्रम उत्पादकता सुनिश्चित करणे आणि किमान वेळपॅरामीटर k च्या स्वीकृत मूल्यांसाठी विकास.

१२.३.५.२. प्रत्येक गट सदस्य आणि इतरांमधील कनेक्शन

कार्यप्रदर्शन मूल्यमापन पद्धतीचे सामान्य वर्णन.

हा दृष्टीकोन थोडासा बदल करून मागील सारखाच आहे. गटातील प्रत्येक सदस्याने इतर कर्मचाऱ्यांशी संवाद साधणे आवश्यक असल्याने, माहिती संबंधांची संख्या n*(n-1) च्या समान आहे, म्हणजे, मागील मूल्याच्या 2 पट.

उदाहरण 5.2 . इतरांसह प्रत्येकाच्या परस्परसंवादात कलाकारांच्या गटाची श्रम उत्पादकता निश्चित करणे

उदाहरण 5.2 अंमलबजावणीसाठी मार्गदर्शक तत्त्वे

मागील कार्य पूर्ण करा, असे गृहीत धरून की प्रत्येक गट सदस्याने त्यांच्या वैयक्तिक समस्यांबद्दल इतर विकास सहभागींशी समन्वय साधला पाहिजे आणि चर्चा केली पाहिजे.

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

१२.३.५.३. फिलिपच्या मॉडेलचा वापर

पद्धतीचे सामान्य वर्णन.

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

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

1) गटात काम करणाऱ्या एका कलाकाराची श्रम उत्पादकता

2) समूहाची एकूण श्रम उत्पादकता, जसे

3) प्रकल्प विकासाची जटिलता म्हणून

4) प्रकल्प विकासाचा कालावधी म्हणून

उदाहरण 5.3 . टीम परफॉर्मन्स मॉडेल वापरून सॉफ्टवेअर प्रोजेक्ट पॅरामीटर्स परिभाषित करणे

उदाहरण 5.3 अंमलबजावणीसाठी मार्गदर्शक तत्त्वे.

सॉफ्टवेअर उत्पादनाचा आकार आरपी (कोडच्या ओळी) आणि वैयक्तिक विकासकाच्या एसपीटी (प्रति व्यक्ती-महिना कोडच्या ओळी) ची सरासरी श्रम उत्पादकता दिली आहे. गटातील विकासकांच्या संख्येवर एकूण श्रम उत्पादकता, श्रम तीव्रता आणि सॉफ्टवेअर उत्पादन विकासाचा कालावधी निश्चित करा.

कार्य अंमलबजावणीचा क्रम.

1. गट PT1 मधील एका व्यक्तीची उत्पादकता वैयक्तिक विकासकाच्या सरासरी श्रम उत्पादकतेच्या तुलनेत n च्या घनमूळाने कमी होते असे गृहीत धरून n लोकांच्या गटाची एकूण श्रम उत्पादकता निश्चित करा. PT1 आणि PTS चे अवलंबन n वर तयार करा.

2. सॉफ्टवेअर उत्पादन विकसित करण्याच्या जटिलतेचे निर्धारण करा

आणि विकासकांच्या संख्येवर विकास श्रम तीव्रतेचे अवलंबित्व प्लॉट करा एन.

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

आणि गटातील विकासकांच्या संख्येचे कार्य म्हणून विकास कालावधी प्लॉट करा.

अतिरिक्त कार्ये.

1. विकास सहभागींच्या संख्येवर अवलंबून गटाच्या एकूण श्रम उत्पादकतेमध्ये सापेक्षाचे कार्य (एका कलाकाराच्या तुलनेत) वाढीचा आलेखच्या स्वरूपात प्लॉट करा.

2. विकास सहभागींच्या संख्येवर अवलंबून विकासकांच्या गटाद्वारे सॉफ्टवेअर उत्पादन विकसित करण्याच्या श्रम तीव्रतेत सापेक्ष (एका परफॉर्मरच्या तुलनेत) वाढीचे कार्य ग्राफच्या स्वरूपात प्लॉट करा.

3. विकास सहभागींच्या संख्येवर अवलंबून विकासकांच्या गटाद्वारे सॉफ्टवेअर उत्पादनाच्या विकासाच्या कालावधीत सापेक्ष (एका परफॉर्मरच्या तुलनेत) कपात करण्याचे कार्य ग्राफच्या स्वरूपात प्लॉट करा.

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

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

6. एका SPT कर्मचाऱ्याची सरासरी श्रम उत्पादकता, ShCh गटाचा आकार आणि विकसित सॉफ्टवेअर उत्पादन RP चा आकार यावर डेटा आहे. अर्ध्या विकासाच्या वेळेनंतर, कर्मचारी पातळी 1.5 पट वाढल्यास AR प्रकल्पाच्या विकासाचा कालावधी कसा बदलेल हे ठरवा.

१२.३.५.४. पुतनाम मॉडेलचा वापर

पद्धतीचे सामान्य वर्णन.

Putnam मॉडेल, किंवा Rayleigh-Norden मॉडेल साठी मोठे प्रकल्पडेव्हलपरची संख्या आणि प्रकल्प पूर्ण करण्यासाठी कालक्रमानुसार वेळ यांच्यातील संबंधाचा लक्षणीय नॉनलाइनर अंदाज देतो.

पुतनाम मॉडेल खालील सूत्रासह मजूर खर्च (TR) प्रकल्प विकास कालावधी (PD) आणि सॉफ्टवेअर उत्पादन आकार (SP) शी संबंधित आहे:

टीपी - प्रकल्प विकसित करण्याचा प्रयत्न (मनुष्य-वर्षे);

आरपी - कोडच्या ओळींची संख्या;

DR - प्रकल्प विकासाचा कालक्रमानुसार वेळ (वर्षे);

C हा एक तांत्रिक स्थिरांक आहे जो प्रकल्पाच्या विकासामध्ये तांत्रिक पातळी प्रतिबिंबित करतो (सराव मध्ये C = 2000 साठी कमी पातळीविकास, चांगल्या पद्धती आणि विकास साधनांसाठी C=8000 आणि अपवादात्मक उच्च स्तरासाठी C=11000 वर).

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

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

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

उदाहरणाच्या अंमलबजावणीसाठी मार्गदर्शक तत्त्वे 5.4.

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

कार्य अंमलबजावणीचा क्रम.

1. श्रम तीव्रता आणि सॉफ्टवेअर उत्पादनाच्या इतर पॅरामीटर्सवर विकास कालावधीच्या प्रभावाचे मूल्यांकन करण्यासाठी प्रारंभिक डेटा निर्धारित करण्यासाठी, आपण RP उत्पादनाच्या आकाराचे तज्ञ मूल्यांकन वापरू शकता. कोडच्या ओळींच्या संख्येवरील डेटावर आधारित, COMOST संसाधन मॉडेल वापरून, इष्टतम परिस्थितीसाठी DR ची श्रम तीव्रता (मनुष्य-वर्षांमध्ये) आणि प्रकल्पाच्या (वर्षांमध्ये) DR विकासाचा कालावधी निर्धारित करा. . त्याच वेळी, विकास संघातील कर्मचाऱ्यांची संख्या आणि त्यांची उत्पादकता निश्चित केली पाहिजे.

2. पुतनाम फॉर्म्युला वापरून TR आणि DR वरील डेटाच्या आधारे, स्थिरांक A बरोबर ठरवा.

3. प्रारंभिक अंदाजानुसार DR सॉफ्टवेअर प्रकल्पाच्या विकास कालावधीचे मूल्य बदलून, DR च्या श्रम तीव्रतेतील सापेक्ष बदल निश्चित करा (SOSOMO नुसार गणना केलेल्या प्रारंभिक डेटाच्या सापेक्ष संबंधित मापदंड निर्धारित केले जातात). प्रकल्प विकासाच्या कालावधीतील बदलांची श्रेणी कार्याशी संबंधित म्हणून स्वीकारली पाहिजे.

4. सुरुवातीच्या तुलनेत AR सॉफ्टवेअर प्रकल्पाच्या विकास कालावधीचे मूल्य बदलून, SC विकासकांच्या कर्मचारी संख्येतील सापेक्ष बदल निश्चित करा. प्रकल्प विकासाच्या कालावधीतील बदलांची श्रेणी कार्य 8 नुसार घेतली पाहिजे.

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

१२.४. पद्धत निवडण्याची आणि कार्यक्षमतेच्या अंदाजांची गणना करण्याची उदाहरणे

१२.४.१. नाविन्यपूर्ण शैक्षणिक संस्था व्यवस्थापित करण्यासाठी माहिती प्रणाली

नवोपक्रम व्यवस्थापित करण्यासाठी माहिती प्रणाली विकसित करणे आवश्यक आहे शैक्षणिक संस्था. विकासाच्या प्रभावीतेचे मूल्यांकन करण्यासाठी, FSA चे कार्यात्मक-खर्च विश्लेषण ( इंग्रजी ABC - क्रियाकलाप आधारित खर्च).

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

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

FM च्या विकासादरम्यान अनावश्यक कार्ये निर्धारित केली जातात आणि विचारात घेतलेल्या FSA वस्तूंचे मुख्य कारण-आणि-प्रभाव संबंध ओळखले जातात.

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

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

आकृती 12.4.1.1 - कार्यात्मक मॉडेल

फंक्शन्सचे महत्त्व निर्धारित करण्यासाठी, जोडीनुसार तुलना मॅट्रिक्स तयार केले जातात (सारणी 12.4.1.1 - 12.4.1.5).

पेअर कंपेरिझन मॅट्रिक्स (पीसीएम) ही तज्ञ मूल्यांकन पद्धतींपैकी एक आहे जी तुम्हाला मिळवू देते परिमाणगुणात्मक वैशिष्ट्य किंवा फंक्शन्सच्या सूचीमधील प्रत्येक विश्लेषित फंक्शन्सचा वाटा (महत्त्व, महत्त्व) निश्चित करा.

फंक्शन्सचे महत्त्व आणि महत्त्व यांचे मूल्यांकन प्रथमपासून (वरपासून खालपर्यंत) फंक्शनल मॉडेलच्या स्तरांवर अनुक्रमे केले जाते. महत्त्व (प्राधान्ये) तज्ञांद्वारे निर्धारित केले जातात.

टेबलच्या प्रत्येक पंक्तीसाठी फंक्शन्सची एकमेकांशी तुलना केली जाते. फंक्शनची इतरांशी तुलना केली जाते आणि महत्त्वानुसार (किंवा इतर काही निकष) प्राधान्य दिलेल्या फंक्शनचा ओळखकर्ता टेबल सेलमध्ये प्रविष्ट केला जातो.

तक्ता 12.4.1.1 - 1ल्या स्तराच्या फंक्शन्सच्या जोडीने तुलना करण्याचे मॅट्रिक्स

कार्य निर्देशांक

प्रमाण

प्राधान्ये

महत्त्व

एकूण

तक्ता 12.4.1.2 - द्वितीय स्तर फंक्शन्सच्या जोडीनुसार तुलनाचे मॅट्रिक्स (F1)

मूल्यांकन पद्धतीचे सामान्य वर्णन

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

टेबल वापरून फंक्शन पॉइंट्सची संख्या मोजणे उचित आहे. ७.

तक्ता 7

फंक्शन पॉइंट मेट्रिकची गणना करण्यासाठी सॉफ्टवेअर उत्पादन पॅरामीटर्स

मोजलेले पॅरामीटर		वजन घटक

वापरकर्ता लॉगिन

वापरकर्ता बाहेर पडतो

वापरकर्ता विनंत्या


बाह्य इंटरफेस

एकूण

माहितीचे मापदंड खालीलप्रमाणे परिभाषित केले आहेत.

वापरकर्ता लॉगिनची संख्या.भिन्न, अनुप्रयोग-विशिष्ट डेटा तयार करणाऱ्या प्रत्येक वापरकर्ता इनपुटची गणना केली जाते. इनपुट वापरकर्त्याच्या विनंत्यांपेक्षा वेगळे असले पाहिजेत, ज्याची स्वतंत्रपणे गणना केली जाते.

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

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

बाह्य इंटरफेसची संख्या.सर्व मशीन-वाचण्यायोग्य इंटरफेस मोजले जातात (उदाहरणार्थ, इतर सिस्टममध्ये माहिती हस्तांतरित करण्यासाठी वापरल्या जाणाऱ्या बाह्य मीडियावरील डेटा फाइल्समध्ये प्रवेश).

कोणताही प्रभाव नाही - 0.

यादृच्छिक प्रभाव -1.

मध्यम प्रभाव - 2.

सरासरी प्रभाव - 3.

लक्षणीय प्रभाव - 4.

लक्षणीय प्रभाव - 5.

अयशस्वी झाल्यानंतर सिस्टमला विश्वसनीय बॅकअप आणि त्यानंतरच्या पुनर्प्राप्तीची आवश्यकता आहे का?

डेटा ट्रान्सफर आवश्यक आहे का?

तेथे वितरित प्रक्रिया वैशिष्ट्ये आहेत?

सॉफ्टवेअर उत्पादनाची कामगिरी गंभीर आहे का?

5. प्रणाली विद्यमान किंवा अधिक जटिल ऑपरेटिंग वातावरणात कार्य करेल?

6. प्रणालीला ऑनलाइन डेटा एंट्री आवश्यक आहे का?

अनेक व्यवहारांसाठी विविध स्क्रीन तयार करण्याची परवानगी देणारी ऑनलाइन व्यवहार नोंद करण्याची आवश्यकता आहे का?

मास्टर फाइल ऑनलाइन अपडेट केली आहे का?

इनपुट, आउटपुट, फाइल्स किंवा क्वेरी क्लिष्ट आहेत का?

10. डेटा प्रोसेसिंग अल्गोरिदम जटिल आहेत का?

तयार केलेले प्रोग्राम पुन्हा वापरायचे आहेत का?

प्रकल्पामध्ये प्रणालीचे कार्यान्वित करणे आणि त्याचे रुपांतर करण्याचे काम समाविष्ट आहे का?

प्रणाली वेगवेगळ्या संस्थांमध्ये स्थापित करण्यासाठी कॉन्फिगर केलेली आहे का?

डिझाइन वापरकर्त्यासाठी अनुकूल अनुभव आणि बदल सुलभ करते का?

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

कार्य 4. सॉफ्टवेअर उत्पादनासाठी फंक्शन पॉइंट्सची संख्या निश्चित करणे

कार्य 4 पूर्ण करण्यासाठी मार्गदर्शक तत्त्वे

भविष्यातील सॉफ्टवेअर सिस्टमच्या वापरकर्त्याच्या आवश्यकता आणि डेटा प्रवाह आकृत्यांच्या आधारावर, FT कार्यात्मक बिंदूंची संख्या मोजा. यासाठी, डिझाइन केलेल्या सॉफ्टवेअर उत्पादनाच्या माहिती क्षेत्राचे विश्लेषण करा आणि त्यातील 5 माहिती पॅरामीटर्स निश्चित करा (तक्ता 7 पहा), प्रत्येकाच्या महत्त्वाचे मूल्यांकन करा. वर सूचीबद्ध केलेल्या 14 घटकांपैकी प्रत्येकाचे विश्लेषण आणि मूल्यमापन करा जे विकसित होत असलेल्या माहिती प्रणालीच्या कार्याची वैशिष्ट्ये दर्शवतात.

नोंद. विशेष "माहिती व्यवस्थापन" च्या विद्यार्थ्यांद्वारे माहिती प्रणालीच्या कोर्स डिझाइन दरम्यान असाइनमेंट केले जाते.

कार्य अंमलबजावणीचा क्रम.

1. एक टेबल बनवा. 7 तज्ञांचे मूल्यांकन भरण्यासाठी आणि सॉफ्टवेअर उत्पादनाच्या मुख्य पॅरामीटर्सचे त्यानंतरचे निर्धारण.

वापरकर्त्याच्या आवश्यकतांचे विश्लेषण करण्याच्या परिणामी आणि भविष्यातील सिस्टमच्या डेटा फ्लो आकृत्यांच्या आधारे, माहिती क्षेत्राच्या पाच वैशिष्ट्यांची (पॅरामीटर्स) मूल्ये निश्चित करा आणि सारणीचा दुसरा स्तंभ भरा.

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

शेवटच्या स्तंभातील सर्व पंक्तींच्या मूल्यांची बेरीज करून माहिती क्षेत्राच्या पाच पॅरामीटर्सची एकूण संख्या निश्चित करा.

सॉफ्टवेअर उत्पादनाच्या कार्यावर त्या प्रत्येकाच्या प्रभावाची डिग्री प्रतिबिंबित करणाऱ्या स्केलनुसार 14 गुणांकांच्या मूल्यांचे तज्ञपणे मूल्यांकन करा.

सूचीबद्ध गुणांकांचे विश्लेषण आणि तज्ञांच्या निर्धारानंतर, सूत्र वापरून फंक्शन पॉइंट्सच्या अंतिम मूल्याची गणना करा:

FT = एकूण*(0.65+ 0.01* शक्यतांची बेरीज),

जिथे एकूण एकूण सारणीच्या शेवटच्या स्तंभातील सर्व पंक्तींची बेरीज आहे. ७.

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

कार्यात्मक दृष्टिकोनाचा विकास.

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

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

हे लक्षात घेतले पाहिजे की दोन्ही पद्धती (FT आणि XT) सॉफ्टवेअर उत्पादनाची समान बाजू प्रतिबिंबित करतात - त्याची "कार्यक्षमता" आणि "उपयुक्तता". दोन्ही दृष्टिकोन सामान्य अभियांत्रिकी संगणकीय समस्या आणि माहिती प्रणालीसाठी समान परिणाम देतात. अधिक जटिल प्रणालींसाठी, विशेषतः रीअल-टाइम, XT चे एकूण मूल्य FT वापरून निर्धारित केलेल्या एकूण मूल्यापेक्षा 20-35% जास्त आहे.

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

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

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

तक्ता 8.

फंक्शन पॉइंट मेट्रिक्स आणि कोडच्या ओळींमधील संबंध

प्रोग्रामिंग भाषा
असेंबलर




ऑब्जेक्ट ओरिएंटेड भाषा
चौथ्या पिढीच्या भाषा
कोड जनरेटर

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