2009-07-07 14 views
16

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

हमारे निर्माण के लिए स्थिर कोड विश्लेषण जोड़ने के बाद, दोषों की संख्या आधा हो गई। तो हम लगभग बचाया। बग फिक्सिंग पर प्रति पुनरावृत्ति के 10 डेवलपर दिन प्रयास। विश्लेषण खरीदने और स्थापित करके अतिरिक्त लागत x $ थी। विश्लेषण परिणामों का पालन करके विकास 0.1% धीमा हो गया था, कुल विकास प्रयास प्रति दिन 5 दिनों तक बढ़ रहा था। पहले छमाही वर्ष के दौरान प्रारंभिक लागत वापस कर दी गई थी। आदि अब हम लगभग बचाओ। y $ प्रति पुनरावृत्ति।

मुझे केवल कोड पूर्ण 2 एड में दी गई ऐसी एक कहानी पता है। यह बोइंग के बारे में बात कर रहा है कि क्यूए प्रक्रिया (AFAIK) के दौरान समीक्षा जोड़ने के बाद दोष कम हो गए। दुर्भाग्य से ज्यादातर दुकानें बोइंग के साथ तुलना नहीं करेंगे, इसलिए बोइंग से अध्ययन की गणना नहीं होती है।

क्या आप ऐसे अध्ययन जानते हैं या आपके पास अपनी दुकान से कोई कठिन डेटा है?

संपादित करें:
एक related question नहीं है, लेकिन किसी भी कठिन डेटा नहीं देता है।

+1

और प्रत्येक SO उपयोगकर्ता 'सितारों' प्रश्न, प्रबंधन के साथ अगली बैठक में लाने के लिए सवाल ... :) –

+0

@ कोरोनैटस - लॉल –

उत्तर

3

यहाँ परम गाइड है - http://www.scribd.com/doc/7758538/Capers-Jones-Software-Quality-in-2008 केपर्स जोन्स सॉफ्टवेयर क्वालिटी में 2008

मैंने कुछ सम्मेलनों/प्रस्तुतियों पर केपर्स जोन्स को देखा है, वह वर्षों से आंकड़े एकत्र कर रहा है (इसमें कुछ पुस्तकें समर्पित हैं) और ठोस जानकारी प्रस्तुत करती है .... और सलाह।

+0

हाँ स्लाइड में संख्याओं की संख्या प्रभावशाली है। हालांकि मैं सिर्फ एक तथ्य निकालने में सक्षम हूं: आरओआई कारक = 15. उचित रूप से अपनी किताबों को देखना होगा ... –

2

यहाँ TDD पर कुछ अच्छा डेटा आईबीएम और माइक्रोसॉफ्ट में लगभग चार परियोजनाओं है: http://blog.typemock.com/2009/03/cost-of-test-driven-development.html

+0

हां, यह दिखाता है कि टीडीडी कोड में बग की मात्रा को कम करता है लेकिन अधिक लेता है तब टीडीडी का उपयोग नहीं कर रहा है। फिर भी यह नहीं दिखाता है कि यह $ में भुगतान करता है या नहीं। फिक्सिंग दोष सस्ता हो सकता है (संभवतः नहीं, लेकिन कोई सबूत नहीं है)। –

+1

दूसरा ग्राफ देखें - हरी रेखा एसडीएलसी के विभिन्न चरणों में दोषों को ठीक करने की लागत का प्रतिनिधित्व करती है। समर्थन के दौरान दोषों को ठीक करने की लागत पर ध्यान दें। –

4

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

यदि आप पुस्तक का ऑर्डर करते हैं, तो इसे लगभग 2-3 सप्ताह में दिखाना चाहिए, कम से कम यह मेरी प्रति प्राप्त करने में कितना समय लगा। अगर मेरे पास यह मेरे पास था तो मैं उनके द्वारा दिए गए उदाहरण टाइप करूंगा लेकिन मैंने इसे काम पर छोड़ दिया।

http://smartbear.com/codecollab-code-review-book.php

+0

आह, आरओआई कैलक्यूलेटर के साथ भी, अच्छा। वे अपने उत्पाद को बेचना चाहते हैं। क्या यह भरोसा किया जा सकता है? –

+0

मैंने अपने उत्पाद का उपयोग नहीं किया है, बस पुस्तक पढ़ें। मुझे यह देखने में दिलचस्पी होगी कि उनका उत्पाद Rietveld (Google कोड समीक्षा टूल) से अलग कैसे है। – Jared

2

"सबसे मुश्किल निरपेक्ष संख्या" मैं टी सिस्टम से कर रहे हैं सुना: (? जर्मन केवल; Google अनुवाद) Wartungskosten im Visier। कोड गुणवत्ता प्रबंधन उपायों (मीट्रिक और निगरानी) को शुरू करने और एकीकृत करने से उन्होंने अपनी लागत 10% (आंशिक रूप से यहां तक ​​कि 20% तक भी कम कर दी है) का दावा किया है। वे 20% रखरखाव का समय बचाने के लिए पुष्टि करते हैं जैसे कि (गुणवत्ता उपायों के लिए समय की आवश्यकता के साथ) वे अभी भी अपने समय का लगभग 10% बचाते हैं। मुझे नहीं पता कि यह सही है, लेकिन यह सराहनीय लगता है और टी-सिस्टम्स की कुछ प्रतिष्ठा है।

इन "संख्याओं" के अलावा सामान्य रूप से आंतरिक गुणवत्ता के आंतरिक प्रभाव के बारे में कई अध्ययन और कागजात हैं। आम तौर पर वे इसके बारे में काफी आशावादी हैं, लेकिन एक बड़ी समस्या वास्तविक व्यापारिक आंकड़ों की कमी है। वास्तव में गणना काफी आसान है। लेकिन यह एक ROI का मूल्यांकन करना मुश्किल है, तो एक है जो एक गुणवत्ता प्रक्रिया की स्थापना के लिए इस विश्वास की जरूरत है उसके रखरखाव की लागत के बारे में कुछ भी पता नहीं है ... ;-)

+0

जर्मन मेरे साथ ठीक है ;-) –

1

किताबें Code Complete 2 और Rapid Development में वास्तविक जीवन केस अध्ययन और प्रयोगों से बहुत सारे उदाहरण हैं।लगभग हर चीज का तर्क है कि वह कठिन तथ्यों का समर्थन करता है।

+0

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

+0

मैं समझता हूं। फिर आप रैपिड डेवलपमेंट की जांच कर सकते हैं। अगर मुझे सही याद है, तो स्रोत बहुत अधिक फैल गए हैं और विविध हैं। –

संबंधित मुद्दे

 संबंधित मुद्दे