การวัดการวัดซอฟต์แวร์โครงการเป็นที่นิยมในอุตสาหกรรมปัจจุบันหรือไม่?


9

ฉันพบนักพัฒนาที่ต้องการคำแนะนำจากภายนอกเกี่ยวกับโครงการทีมของพวกเขา ฉันพบว่าพวกเขากำลังพัฒนาชุดซอฟต์แวร์ขนาดใหญ่สำหรับผู้บริหาร บริษัท ผู้จัดการโครงการและนักพัฒนาที่สามารถคำนวณตัวชี้วัดโดยอัตโนมัติและสร้างกราฟต่อการทำซ้ำ

ในฐานะนักเรียนจากพื้นหลังวิทยาศาสตร์คอมพิวเตอร์ฉันรู้น้อยมากเกี่ยวกับการวัดและความสำคัญของพวกเขา แต่คำถามของฉันคือ:

  1. บริษัท ส่วนใหญ่มีวิธีการบางอย่างไม่จำเป็นต้องเป็นโปรแกรมที่สง่างามในการวัดตัวชี้วัดที่มีความหมายหรือไม่?
  2. ตัวชี้วัดเดียวหรือรวมกันช่วยให้คุณ จำกัด ขอบเขตและประมาณการโครงการให้แคบลงได้บ้าง
  3. ในฐานะคนที่วิเคราะห์ตัวชี้วัดคุณมักจะตัดสินใจออกมาบ่อยแค่ไหน? IE การทดสอบล้มเหลวต่อสัปดาห์กำลังเพิ่มขึ้นอย่างมาก
  4. คุณรู้สึกว่าการแนะนำตัวชี้วัดการศึกษาช่วยให้คุณเข้าใจโครงงานดีขึ้นหรือไม่?

ไม่แน่ใจว่าทำไม แต่นักพัฒนาโครงการสนใจฉันและฉันต้องรู้เพิ่มเติม ถ้า y

คำตอบ:


6

หนังสือบางเล่มในตัวชี้วัดที่ห้องสมุดวิทยาลัยของคุณอาจจะได้รวมถึงซอฟแวร์ตัวชี้วัดและตัวชี้วัดและโมเดลวิศวกรรมซอฟต์แวร์คุณภาพ ทั้งสองควรให้คุณเป็นจุดเริ่มต้น ในโลกอุตสาหกรรม บริษัท น้อยมากที่มีโปรแกรมการวัดแบบใด ๆ เลย

บริษัท ส่วนใหญ่มีวิธีการบางอย่างไม่จำเป็นต้องเป็นโปรแกรมที่สง่างามในการวัดตัวชี้วัดที่มีความหมายหรือไม่?

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

ตัวชี้วัดเดียวหรือรวมกันช่วยให้คุณ จำกัด ขอบเขตและประมาณการโครงการให้แคบลงได้บ้าง

ฉันพบว่าความสลับซับซ้อนและการมีเพศสัมพันธ์เป็นตัวบ่งชี้ที่แข็งแกร่งว่าจะบั๊กหรือยากที่จะรักษารหัสจะเป็นอย่างไร หากความซับซ้อนของวงจรมีค่าประมาณ 20 ฉันพบว่าแทบเป็นไปไม่ได้ที่จะทำการทดสอบ (เนื่องจากจะมีเส้นทางมากถึง 2 ^ 20 เส้นทางผ่านรหัส) และควรจะย่อยเป็นชิ้นเล็ก ๆ คุณไม่สามารถกำจัดความซับซ้อน แต่คุณสามารถแบ่งมันเป็นส่วนที่จัดการได้มากขึ้น

หากคุณกำลังมองหาการประมาณค่าคุณอาจต้องการตรวจสอบการทำงานของ จุด

รหัสความครอบคลุม% กำลังลดลงอย่างมากในแต่ละรอบซ้ำคุณแจ้งเตือนผู้พัฒนาปัญหาของคุณหรือไม่

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

อาร์กิวเมนต์มาตรฐานที่นักพัฒนาซอฟต์แวร์ใช้คือถ้าคุณวัดบางอย่างคุณจะได้รับสิ่งนั้นเท่านั้น อาร์กิวเมนต์นี้มาจากแนวคิดที่ว่าตัวชี้วัดเดียวเท่านั้นคือบรรทัดของโค้ด


ขอบคุณสำหรับคำตอบโดยละเอียดและลิงก์ที่เกี่ยวข้อง ดังต่อไปนี้ 1. ทำไมผู้จัดการจะสนใจจำนวนเช็คอิน? บางทีคำนิยามของการเช็คอินของเราอาจแตกต่างกัน 2. คุณหมายถึงอะไรโดยบรรทัดของรหัสที่เป็นตัวชี้วัดที่เลวร้ายที่สุด? เลวร้ายที่สุดในขณะที่มันไม่ได้บ่งบอกที่ดีเกี่ยวกับโครงการ?
Russ K

@Russ ผู้พัฒนาที่ไม่ได้ตรวจสอบรหัสจะถูกมองว่าไม่ทำงาน LOC นั้นแย่ที่สุดในเกม ลองดูที่ความแตกต่างระหว่าง K & R และสไตล์ Allman รหัสเยื้องไปนี้: en.wikipedia.org/wiki/Indent_style สไตล์ Allman จะให้ค่า LOC ที่สูงขึ้นเพียงแค่ใส่ {open ในบรรทัดแยกต่างหาก คำเตือน: ฉันเกลียดสไตล์ K&R เนื่องจากฉันไม่ค่อยพบการจับคู่ที่เปิด {โดยไม่ต้องใช้เวลามากเกินไปในการเล่น Where's Waldo
Tangurena

In the industrial world, very few companies have any sort of metric measurement program at all.บริษัท ใด ๆ ที่มีคะแนน CMMI ตั้งแต่ 2 ขึ้นไปจะมีโปรแกรมวิเคราะห์การวัด / ชี้วัด การรวบรวมการวัดและตัวชี้วัดเป็นข้อกำหนดระดับ Maturity ระดับ 2 CMMI Maturity Level 4 ต้องการการจัดการโครงการเชิงปริมาณขึ้นอยู่กับการวัดและตัวชี้วัดเหล่านั้นพร้อมกับสิ่งต่าง ๆ เช่นการวิเคราะห์สาเหตุที่แท้จริงเพื่อดำเนินการกับปัญหาที่ระบุ มีองค์กรจำนวนมากที่ได้รับการจัดอันดับที่ CMMI ระดับ 4 (หรือ 5)
โธมัสโอเวนส์

2

ฉันกำลังพูดคุยเกี่ยวกับการวัดซอฟต์แวร์ที่ผู้พูดทำบาง IMHO ซึ่งเป็นจุดที่น่าสนใจ ด้วยประสบการณ์เพียงเล็กน้อยกับสิ่งเหล่านี้ฉันยังคงสนใจและเป็นแรงบันดาลใจ แต่ฉันไม่สามารถพูดได้ว่ามันผิดหรือถูก

แนวคิดหลักคือ:

  • ไม่มีตัวชี้วัดเอกพจน์มีประโยชน์ในสิทธิของตนเอง
  • การตั้งเป้าหมายที่แน่นอน (เช่นการครอบคลุมรหัส XX%) นั้นไม่มีความหมาย
  • การวัดที่ไม่มีประวัติจะมีประโยชน์

ดังนั้นเพื่อแก้ปัญหานี้:

  • แสดงตัวชี้วัดหลายอย่างเช่น:
    • # บรรทัดทั้งหมด / เปลี่ยน
    • # จากการกระทำ
    • ความครอบคลุมรหัส%
    • # ของการทดสอบ
    • ความซับซ้อนของวัฏจักร
    • การพึ่งพาไฟล์ / แพ็คเกจ / ...
    • ...
  • แสดงข้อมูลจาก QA / CI:
    • # ของข้อบกพร่อง / การปรับปรุง / การเปลี่ยนแปลง (โดยส่วนตัวแล้วฉันคิดว่าการจัดหมวดหมู่นี้มีความสำคัญ)
    • # total / เพิ่ม / คงที่
  • แสดงการวัดเหล่านี้ในกราฟที่แสดงแนวโน้มเมื่อเวลาผ่านไป

วิธีนี้เมื่อตั๋วถูกแก้ไขอย่างรวดเร็วเราสามารถดูว่าคุณภาพของรหัสลดลงหรือไม่ นอกจากนี้เมื่อดูเหมือนว่าจะไม่เกิดขึ้นกับฐานข้อมูลบั๊กมากนักคุณภาพของโค้ดอาจเพิ่มขึ้นเนื่องจากการปรับโครงสร้างเสร็จสิ้น

ข้อสรุป:มันเป็นพฤติกรรมแบบไดนามิกที่สำคัญและสิ่งที่ให้ข้อมูลแก่คุณมากกว่าข้อมูลดิบ (ซึ่งจะเป็นค่าของการวัดเดียว)

ฉันวางแผนที่จะวางกราฟตามโครงการนี้ในทีวีจอกว้างถัดจากโคมลาวาที่เชื่อมต่อ CI ของเรา ;)


ใส่กัน ฉันอ่านบทความจำนวนมากเกี่ยวกับการวัดเพียงอย่างเดียวไร้ประโยชน์ดังที่คุณพูดถึงและประวัติเป็นสิ่งสำคัญ ขอบคุณที่สละเวลาตอบ
Russ K
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.