คำถามติดแท็ก measurement

บริบท: ฉันเป็นนักพัฒนาองค์กรในร้าน MS ทั้งหมด ใครช่วยแนะนำวิธีที่ดีในการวัดความสามารถในการบำรุงรักษาโค้ดหรือแอพพลิเคชั่นอย่างเป็นกลาง ? ทำไมการบำรุงรักษา : ฉันเบื่อกับการวัด "คุณภาพ" ในกลุ่มของฉันหมุนรอบจำนวนข้อบกพร่องและความครอบคลุมรหัสเท่านั้น ตัวชี้วัดทั้งสองเป็นเกมที่เล่นง่ายโดยเฉพาะเมื่อคุณไม่ได้วัดการบำรุงรักษา ความสั้นและกำหนดเวลาส่งผลให้เกิดหนี้สินทางเทคนิคจำนวนมหาศาลซึ่งไม่เคยได้รับการแก้ไข ทำไมความสามารถในการวัดอย่างเป็นกลาง : ฉันทำงานในกลุ่มองค์กรขนาดใหญ่ หากคุณไม่สามารถวัดได้อย่างเป็นกลางคุณจะไม่สามารถทำให้ผู้คนรับผิดชอบได้หรือทำให้ดีขึ้น การวัดอัตนัยไม่ได้เกิดขึ้นหรือไม่เกิดขึ้นอย่างสม่ำเสมอ ฉันกำลังดูการวัดโค้ด VS2010แต่ฉันสงสัยว่าใครมีคำแนะนำอื่น ๆ

23 c#  visual-studio-2010  metrics  maintainability  measurement 

ในปี 1977 Maurice Howard Halstead ได้แนะนำมาตรการความซับซ้อนของระบบซอฟต์แวร์ซึ่งรวมถึงการวัดคำศัพท์ของโปรแกรมความยาวของโปรแกรมปริมาตรความยากความพยายามและจำนวนข้อผิดพลาดโดยประมาณในโมดูล ตามวิกิพีเดียความยากลำบากเกี่ยวข้องกับความยากลำบากในการทำความเข้าใจโปรแกรมเมื่ออ่านหรือเขียนและความพยายามสามารถแปลเป็นเวลาที่ใช้ในการเขียนโปรแกรมประยุกต์ที่เวลา = (ความพยายาม / 18) วินาที การวัดไม่มีประโยชน์เว้นแต่ว่าข้อมูลและการคำนวณจะเกี่ยวข้องกับการพัฒนาซอฟต์แวร์ อย่างไรก็ตามฉันไม่พบงานใด ๆ ที่ระบุว่าความยากลำบากของค่าบางค่าหรือสูงกว่ามีแนวโน้มเพิ่มขึ้นอย่างมีนัยสำคัญทางสถิติในข้อบกพร่องหรือความสัมพันธ์ระหว่างความยากลำบากและเวลาในการอ่านรหัส (ความยากลำบากของ N การทำความเข้าใจฐานรหัส) หรือการวิเคราะห์ใด ๆ ที่สามารถคำนวณเวลาหลังจากข้อเท็จจริงที่เป็นประโยชน์ในการกำหนดคุณภาพ (โดยเฉพาะตั้งแต่เวลาที่จะเขียนควรได้รับการบันทึกเป็นการวัดแล้ว) ฉันสนใจโดยเฉพาะอย่างยิ่งในการประเมินข้อผิดพลาดของ Halstead (ซึ่งไม่ได้กล่าวถึงใน Wikipedia) - จำนวนข้อบกพร่องในแอปพลิเคชันสามารถประมาณได้โดย Volume / 3000 หรือ Effort ^ (2/3) / 3000 ฉันกำลังมองหาสองสิ่ง: มีใครบ้างที่ใช้มาตรการความซับซ้อนของซอฟต์แวร์ของ Halstead ในแอปพลิเคชันที่ใช้งานจริงเพื่อประเมินคุณภาพซอฟต์แวร์ ถ้าเป็นเช่นนั้นคุณใช้พวกเขาอย่างไรและพวกเขากลายเป็นการวัดที่มีประโยชน์ถูกต้องและ / หรือเชื่อถือได้หรือไม่ มีงานวิจัยเชิงวิชาการในรูปแบบของการสำรวจวิเคราะห์หรือกรณีศึกษาที่กล่าวถึงความถูกต้อง (หรือความไม่ถูกต้อง) ของมาตรการความซับซ้อนของ Halstead เมื่อนำไปใช้กับคุณภาพของซอฟต์แวร์หรือไม่ …

14 quality  metrics  measurement 

เราได้แนะนำกระบวนการตรวจสอบโค้ดภายในองค์กรของเราและดูเหมือนว่าจะทำงานได้ดี อย่างไรก็ตามฉันต้องการที่จะสามารถวัดประสิทธิภาพของกระบวนการเมื่อเวลาผ่านไปเช่นว่าเราไม่พบข้อบกพร่องเพราะรหัสนั้นสะอาดหรือเป็นคนที่ไม่ได้รับข้อบกพร่อง? ในปัจจุบันเรายังไม่มีกระบวนการทดสอบอัตโนมัติเต็มรูปแบบที่มีประสิทธิภาพ เราใช้การทดสอบด้วยตนเองเป็นหลักดังนั้นเราจึงไม่สามารถพึ่งพาข้อบกพร่องที่พบในขั้นตอนนี้เพื่อให้แน่ใจว่ากระบวนการตรวจสอบโค้ดทำงาน มีใครบ้างที่เคยเจอปัญหานี้มาก่อนหรือคิดว่าอะไรดีในการวัดความคิดเห็นโค้ด

14 code-reviews  quality  metrics  measurement 

ฉันกำลังมองหาข้อโต้แย้งเพื่อโน้มน้าวให้ฝ่ายบริหารลงทุนในความพยายามในการปรับโครงสร้างใหม่ เราบันทึกการทำงานโดยใช้ Jira และเชื่อมโยงทุก svn-commit กับการเรียก jira ความคิดของฉันคือการทำต่อไปนี้: ตรวจดูพื้นที่ของรหัสด้วยตนเองซึ่งมีการใช้งานที่แย่มาก แต่มักจะใช้: ทั้งจาก User-POV และ Developer-POV (แก้ไขข้อผิดพลาด) รับ svn-commits ซึ่งมี JIRA-Issues กรองปัญหาตามเกณฑ์บางอย่าง (ประเภทปัญหารุ่น prio ฯลฯ ... ) คำนวณเวลา / ความพยายามที่ใช้กับข้อบกพร่องเหล่านี้ ประเมินความพยายามและความเสี่ยงของการปรับโครงสร้างใหม่ แสดงตัวเลขและขอความพยายามแก้ไข คุณคิดยังไงกับสิ่งนี้? การวัดเช่นนี้จะมีประโยชน์และ / หรือน่าเชื่อถือไหม ข้อดีข้อเสียคืออะไร

13 svn  project-management  jira  measurement 

นี่คือใบเสนอราคาจากคู่มือการฝึกอบรมที่ทำงานเกี่ยวกับ SLIM และการประเมินซอฟต์แวร์: โปรดสังเกตว่ามีความสัมพันธ์ระหว่างความพยายามกับข้อบกพร่อง ซึ่งหมายความว่ายิ่งมีคนได้รับมอบหมายให้โครงการขนาดที่กำหนดมากเท่าไหร่ก็จะยิ่งมีข้อบกพร่องมากขึ้นเท่านั้น ความพยายามคือบุคคลเวลา (คนปีบุคคลเดือน) สำหรับโครงการ ข้อบกพร่องคือจำนวนของข้อบกพร่องที่ตรวจพบ ณ จุดใด ๆ ในวงจรชีวิต ขนาดถูกกำหนดให้เป็นกรณีการใช้งานจุดทำงานหรือ SLOC ที่ประกอบโครงการ ดูเหมือนว่าจะเป็นเรื่องที่เข้าใจง่ายโดยถือว่าเป็นกระบวนการที่ดีและวิศวกรที่มีความสามารถ ตัวอย่างเช่นการมีคนมากขึ้นหมายถึงการมองสิ่งประดิษฐ์ทั้งหมด (ข้อกำหนดรายละเอียดการออกแบบรหัสการทดสอบ) นอกเหนือจากการมีดวงตามากขึ้นสัญชาตญาณของฉันแสดงให้เห็นว่ามีความสัมพันธ์ระหว่างความพยายามและข้อบกพร่องเล็กน้อยในโครงการที่ใช้เทคนิคคุณภาพที่เหมาะสม ฉันไม่สามารถค้นหาเอกสารใด ๆ นอกเหนือจากเอกสารเกี่ยวกับแบบจำลองพัทนัม (ซึ่งใช้โดย SLIM) ที่แนะนำความสัมพันธ์แบบใดก็ได้ที่รู้จักระหว่างข้อบกพร่องกับความพยายามหรือข้อบกพร่องและจำนวนคนในโครงการ นี่เป็นความสัมพันธ์ที่รู้จักกันดีและเป็นการยืนยันว่า "มีคนมากกว่า = ข้อบกพร่องมากขึ้น" ถูกต้องหรือไม่?

12 estimation  quality  metrics  measurement 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว มีคุณภาพหลายประเภทที่สามารถวัดได้ในผลิตภัณฑ์ซอฟต์แวร์เช่นความเหมาะสมสำหรับวัตถุประสงค์ (เช่นการใช้งานปลายทาง) การบำรุงรักษาประสิทธิภาพ บางส่วนเป็นแบบอัตนัยหรือเฉพาะโดเมน (เช่นหลักการออกแบบ GUI ที่ดีอาจแตกต่างกันในแต่ละวัฒนธรรมหรือขึ้นอยู่กับบริบทการใช้งานคิดว่าการทหารกับการใช้งานของผู้บริโภค) สิ่งที่ฉันสนใจคือรูปแบบที่ลึกกว่าของคุณภาพที่เกี่ยวข้องกับเครือข่าย (หรือกราฟ) ของประเภทและความสัมพันธ์ระหว่างกันของพวกเขานั่นคือประเภทใดที่อ้างถึงแต่ละประเภทจะมีกลุ่มของการเชื่อมต่อระหว่างกันอย่างชัดเจน สถาปัตยกรรมแบบฉัตรหรือตรงกันข้ามมี 'ball' ขนาดใหญ่ของการอ้างอิงประเภท (รหัส 'เสาหิน') นอกจากนี้ขนาดของแต่ละประเภทและ / หรือวิธีการ (เช่นวัดในปริมาณของรหัสไบต์ Java หรือ. Net IL) ควรให้ข้อบ่งชี้ว่ามีการใช้อัลกอริธึมที่ซับซ้อนขนาดใหญ่เป็นบล็อกก้อนใหญ่ของรหัสแทนที่จะถูกย่อยสลายได้ง่าย ชิ้น การวิเคราะห์ตามแนวคิดดังกล่าวอาจสามารถคำนวณตัวชี้วัดที่มีพร็อกซีเพื่อคุณภาพอย่างน้อย เกณฑ์ที่แน่นอน / คะแนนการตัดสินใจระหว่างคุณภาพสูงและต่ำฉันจะสงสัยว่าเป็นอัตนัยเช่นเนื่องจากการบำรุงรักษาเราหมายถึงการบำรุงรักษาโดยโปรแกรมเมอร์ของมนุษย์และดังนั้นการสลายตัวของการทำงานจะต้องสอดคล้องกับวิธีการทำงานของจิตใจมนุษย์ ด้วยเหตุนี้ฉันจึงสงสัยว่าจะมีคำจำกัดความที่บริสุทธิ์ทางคณิตศาสตร์ของคุณภาพของซอฟต์แวร์ที่เหนือกว่าซอฟต์แวร์ที่เป็นไปได้ทั้งหมดในทุกสถานการณ์ที่เป็นไปได้หรือไม่ ฉันยังสงสัยว่านี่เป็นความคิดที่อันตรายหรือไม่ถ้าหากผู้รับมอบฉันทะที่มีคุณภาพเป็นที่นิยมนั้นความกดดันทางธุรกิจจะทำให้นักพัฒนาต้องติดตามตัวชี้วัดเหล่านี้ด้วยค่าใช้จ่ายของคุณภาพโดยรวม (ด้านคุณภาพของพวกเขา วิธีคิดอีกอย่างคือคุณภาพจากมุมมองของเอนโทรปี เอนโทรปีคือแนวโน้มของระบบที่จะเปลี่ยนจากการสั่งซื้อเป็นรัฐที่ไม่เป็นระเบียบ ทุกคนที่เคยทำงานในโลกแห่งความเป็นจริงโครงการซอฟต์แวร์ขนาดกลางถึงขนาดใหญ่จะขอบคุณในระดับที่คุณภาพของรหัสฐานมีแนวโน้มที่จะลดลงเมื่อเวลาผ่านไป โดยทั่วไปความกดดันทางธุรกิจส่งผลให้เกิดการเปลี่ยนแปลงที่มุ่งเน้นไปที่ฟังก์ชั่นใหม่ (ยกเว้นในกรณีที่คุณภาพเป็นจุดขายหลักเช่นในซอฟต์แวร์ avionics) และการกัดเซาะของคุณภาพผ่านปัญหาการถดถอยและฟังก์ชั่น 'รองเท้า horning' มุมมองด้านคุณภาพและการบำรุงรักษา ดังนั้นเราสามารถวัดเอนโทรปีของซอฟต์แวร์ได้หรือไม่? …

12 quality  metrics  measurement