คุณจะรู้ได้อย่างไรว่าซอฟต์แวร์ดีหรือไม่ดีตามตัวชี้วัดเชิงประจักษ์?

ฉันถูกขอให้ดูโครงการที่เสร็จสิ้นการพัฒนาหลักเมื่อห้าเดือนที่แล้ว แต่ก็ยังมีข้อบกพร่องในระดับสูง มีการแก้ไขข้อผิดพลาดอะไรบ้างประมาณ 10 ข้อเราเพิ่มอย่างน้อย 4 ข้อและในบางกรณี 8 ข้อบกพร่อง

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

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

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

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

ดังนั้นเมื่อคุณยอมรับผลิตภัณฑ์จากบุคคลที่สามและถูกขอให้สนับสนุนผลิตภัณฑ์คุณจะใช้เกณฑ์การยอมรับใดในการกำหนดมาตรฐาน

นอกเหนือจากการทำให้ผู้พัฒนานำของเราทำการตรวจทานโค้ดต่อรุ่นแล้วไม่แน่ใจว่าสามารถทำอะไรได้บ้าง

คุณทำไม่ได้

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

การใช้เหตุผลตามสภาพที่เป็นอยู่

ดังที่ Kilian Foth ชี้ให้เห็นหากมีการวัดอย่างง่ายสำหรับซอฟต์แวร์ "ดี" เราทุกคนต่างก็ใช้มันและทุกคนก็ต้องการมัน

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

การใช้เหตุผลโดยการตอบโต้

ยังบอกใบ้โดย Kilian อยู่แล้วและโดยทั่วไปมักใช้ถ้อยคำว่า "ทุกเมตริกสามารถเล่นได้"

การเล่นเมตริกหมายความว่าอย่างไร มันเป็นเกมที่สนุกสำหรับนักพัฒนา: คุณมั่นใจว่าค่าการวัดดูดีจริงๆในขณะที่ทำสิ่งที่น่ารังเกียจ

สมมติว่าคุณวัดข้อบกพร่องต่อ LOC ฉันจะเล่นยังไงดี ง่าย - เพียงเพิ่มรหัสเพิ่มเติม! สร้างรหัสโง่ที่ทำให้ไม่มีการใช้งานเกิน 100 บรรทัดและทันใดนั้นคุณก็มีข้อบกพร่องน้อยกว่าต่อ LOC ดีที่สุด: คุณลดคุณภาพของซอฟต์แวร์ลง

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

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

เหตุผลโดยการกำหนดเป้าหมายผิด

สิ่งที่คุณต้องการวัดคือคุณภาพซอฟต์แวร์ สิ่งที่คุณทำวัดคือหนึ่งหรือมากกว่าหนึ่งตัวชี้วัด

มีช่องว่างระหว่างสิ่งที่คุณวัดกับสิ่งที่คุณเชื่อว่ามันจะบอกคุณ ช่องว่างนี้มีขนาดใหญ่มาก

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

การใช้เหตุผลเชิงปริมาณ

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

การตัดสินคุณภาพของซอฟต์แวร์โดยการวัดและการมองข้ามไปยังส่วนต่าง ๆ ของคุณภาพที่คุณไม่สามารถหาปริมาณได้แน่นอนว่าจะไม่ได้ผลดี

แก้ไข:

สรุป

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

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

คุณวัดซอฟต์แวร์ A และตัวชี้วัดนั้นเลวร้ายมาก จากนั้นคุณสามารถมั่นใจได้ว่าคุณภาพของรหัสไม่ดี คุณวัดซอฟต์แวร์ B และตัวชี้วัดก็โอเคแล้วคุณก็ไม่รู้เลยเลยว่าคุณภาพของรหัสนั้นเป็นอย่างไร อย่าหลงกลโดยคิดว่า "metrics good = code good" เมื่อเป็นเพียง "code good => metrics ดี"

โดยพื้นฐานแล้วคุณสามารถใช้เมตริกเพื่อค้นหาปัญหาคุณภาพ แต่ไม่ใช่คุณภาพ

ใช่คุณสามารถบอกได้ว่ารหัสนั้นมีปัญหาด้านคุณภาพโดยดูจากการวัดในระดับหนึ่ง

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

ตัวอย่างเช่นคุณสามารถเรียกใช้การตรวจสอบแหล่งที่มา

สิ่งนี้จะบอกคุณว่ารหัสซับซ้อนแค่ไหน ฉันสามารถบอกคุณได้ว่าทุกระบบมีปัญหาที่ฉันพบมีจำนวนไม่ดี ความซับซ้อนของวิธีการ 10s ถึง 100s เกินขีด จำกัด ที่ยอมรับได้ ตัวเลขแย่มาก ความซับซ้อนที่ยอดเยี่ยมการทำรังความลึก ฯลฯ ซึ่งจะนำไปสู่ปัญหามากมายอัตราข้อบกพร่องคงที่สูงยากที่จะทำการเปลี่ยนแปลงโดยไม่ทำลายอย่างอื่น ฯลฯ

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

เนื้อเรื่องควรมีลักษณะดังนี้:

ข้อบกพร่องเมื่อเวลาผ่านไป

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

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

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

ในที่สุดคุณเพียงแค่ต้องประเมินรหัสไม่มีตัวชี้วัดจะช่วยให้ outthere ทุกโครงการรหัสที่มีปัญหามีคุณสมบัติเหล่านี้:

• โครงสร้างข้อมูลไม่ดี ทุกอย่างเป็นสตริงหรือ XML ถูกส่งผ่านไปทุกหนทุกแห่งและแยกวิเคราะห์ได้ทุกที่วัตถุเทพเจ้าหรือโครงสร้างข้อมูลที่ซับซ้อนหรือไม่จำเป็นโดยทั่วไปไม่มีโมเดลโดเมน
• การขาดองค์กรหรือโครงสร้างโครงการที่ไม่สำคัญควรมีการแบ่งหรือชั้นที่แยกออกจากตรรกะ ดูที่นี่ ... หากคุณไม่เห็นองค์กรประเภทนี้หรือการแยก (การผสมตรรกะทุกแห่ง) ระบบจะยากที่จะรักษาและเข้าใจ
• กว่า abstractions บางครั้งการย้อนกลับเป็นจริงระบบจะข้ามไป หากทุกอย่างเป็นอินเทอร์เฟซและคลาสนามธรรมหรือคุณต้องเลื่อนผ่านคลาสชนิด "wrapper" คลาสคุณภาพจะไม่ดีเนื่องจากนักพัฒนาใหม่จะไม่สามารถนำทางผ่านวัตถุขยายตัวได้
• รหัสยากที่จะเข้าใจ หากคุณเป็นนักพัฒนาที่มีประสบการณ์และหากคุณกำลังมองหารหัสที่เข้าใจยากจะมีปัญหาด้านคุณภาพ ตัวชี้วัดส่วนบุคคลของฉันคือถ้าฉันดูรหัสและมันยากที่จะติดตามหรือทำให้ฉันรู้สึกงี่เง่าหรือฉันรู้สึกว่าฉันกำลังสูญเสียวงจรสมองจำนวนมากในการหาตรรกะแล้วมันเป็นรหัสที่ไม่ดี หากนักพัฒนาที่มีประสบการณ์มีความยากลำบากในการติดตามโปรดลองจินตนาการว่ามันจะเป็นอย่างไรสำหรับนักพัฒนามือใหม่ พวกเขาจะแนะนำปัญหา

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

สิ่งที่น่าเศร้ากับการวัดคือคุณอาจได้รับการปรับปรุงค่าผลลัพธ์ที่ได้จากการวัดของคุณ แต่ไม่ใช่คุณภาพที่ตั้งใจจะวัดโดย ...

ใน Visual Studio มีการตั้งค่าสำหรับการปฏิบัติต่อคำเตือนของคอมไพเลอร์ว่าเป็นข้อผิดพลาด ตอนนี้บางคนไม่เข้าใจคำเตือนและเพื่อให้ได้รับรหัสที่รวบรวมจะใช้เทคนิคง่าย ๆ (เช่น´pragma ปิดการใช้งานคำเตือน ´หรือเพิ่มคำสำคัญ´ ใหม่ไปยังฟังก์ชั่น / คุณสมบัติซ่อนสมาชิกที่ไม่ใช่เสมือนของฐาน class)

หากคุณมีสิทธิ์เข้าถึงซอร์สโค้ดคุณสามารถรันการวิเคราะห์โค้ดแบบสแตติก สำหรับโครงการ. Net คุณสามารถใช้เช่น FxCop หรือ ReSharper InspectCode เมื่อทีมพัฒนาใช้อย่างถูกต้องเครื่องมือจะช่วยปรับปรุงคุณภาพ แต่แน่นอนว่า "การแก้ไข" บางอย่างสำหรับการลบคำเตือนโดยไม่เข้าใจอาจเป็นไปได้

คุณสามารถดูการทดสอบอัตโนมัติ / การทดสอบหน่วย: การครอบคลุมโค้ดนั้นดีแค่ไหน? แต่ความครอบคลุมเพียงอย่างเดียวจะไม่บอกคุณว่าการทดสอบจริงตรวจสอบรหัสหรือเพียงแค่มีการดำเนินการเพียงครั้งเดียว

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

สิ่งหนึ่งที่คุณควรดูเพิ่มเติมจากการรวบรวมตัวชี้วัดเช่นการฉีดข้อบกพร่องคือการหาแหล่งที่มาของข้อบกพร่อง บ่อยครั้งที่มันเกี่ยวข้องกับข้อกำหนด

โดยทั่วไปคือข้อผิดพลาดในสเปคเป็นความคลุมเครือในการพูดที่เหลือสำหรับการปลูกถ่ายเพื่อตัดสินใจหรือมันเป็นข้อผิดพลาดในการดำเนินงาน

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

ด้านล่างไม่มีทางรู้

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

ข้อสันนิษฐานที่ฉันทำกับคำถามนี้: มีความแตกต่างระหว่างรหัสและซอฟต์แวร์ ฉันกำหนดซอฟต์แวร์เป็นสิ่งที่ลูกค้า / ผู้ใช้ใช้เพื่อแก้ปัญหาในขณะที่รหัสเป็นวัสดุก่อสร้างของซอฟต์แวร์

ซอฟต์แวร์สามารถวัดได้เฉพาะผู้กระทำ นั่นคือตัวชี้วัดที่สำคัญสำหรับซอฟต์แวร์คือคนใช้เพื่อแก้ไขปัญหาหรือไม่ ตัวชี้วัดนี้ขึ้นอยู่กับพฤติกรรมของผู้อื่น หมายเหตุ: สำหรับปัญหาบางอย่างซอฟต์แวร์บางชิ้นอาจมีประโยชน์และถือว่ามีคุณภาพสูง (Excel สำหรับการคำนวณ) แต่ไม่ใช่ซอฟต์แวร์ที่มีคุณภาพสำหรับปัญหาอื่น (Excel สำหรับการเล่นไฟล์ MP3)

รหัสสามารถ (ปกติ) วัดได้ด้วยตัวชี้วัดเชิงประจักษ์ แต่การตีความไม่ใช่ 'ใช่ / ไม่ใช่' เพื่อคุณภาพหรือแม้กระทั่งในระดับ '0 ถึง N' ตัวชี้วัดที่วัดกับมาตรฐาน ดังนั้นตัวชี้วัดสามารถค้นหาพื้นที่ของความกังวลที่กำหนดโดยมาตรฐาน แต่การขาดพื้นที่ของความกังวลไม่ได้พิสูจน์ว่านี่คือรหัสคุณภาพ ตัวอย่างเช่นตัวชี้วัดที่มีประโยชน์: มันรวบรวมหรือไม่ ไม่ -> ไม่มีคุณภาพ ใช่ -> ??? ผ่านการทดสอบหน่วยหรือไม่ ไม่มี? อาจจะ? (เพราะเป็นรหัสคุณภาพการทดสอบหน่วยใช่หรือไม่) ใช่ -> ???

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

อีกวิธีหนึ่งในการโต้แย้งนี้คือการก้าวเข้าสู่ภาษาธรรมชาติ William Shakespeare, Lewis Carroll และ Mark Twain ล้วน แต่เป็นนักเขียนที่ประสบความสำเร็จและเป็นที่รักของนักเขียนหลายคนในเรื่องคุณภาพงานเขียนของพวกเขา แต่เราสามารถนำมาตรฐานของไวยากรณ์คำศัพท์รูปแบบหรือเสียงมาใช้ซึ่งจะให้คะแนนพวกเขาสูงกว่านักเรียนเกรด 12 แบบสุ่มอย่างสม่ำเสมอหรือไม่ และในขณะที่อาจเป็นไปได้ที่จะสร้างตัววัดแบบสังเคราะห์สำหรับสามตัวนั้นมันจะให้คะแนน Book of John (KJV), JRR Tolkien, Homer, Cervantes อย่างไร? จากนั้นโยนใน Burroughs, Faulkner, Hemingway, Sylvia Plath และอื่น ๆ การวัดจะไม่ทำงาน

ฉันจะวัดสิ่งนี้โดยการตรวจสอบ (และกำลังมองหาการเบี่ยงเบนใน) กระบวนการของพวกเขา

ฉันจะมองหาหลักฐานของกระบวนการในการส่งมอบที่เกี่ยวข้องกับการควบคุมแหล่งกลางระบบสร้างส่วนกลางและกระบวนการที่รหัสมั่นใจได้รับการทดสอบก่อนที่จะรวมเข้ากับสาขาที่ออก

ฉันจะมองหาหลักฐานว่าพวกเขาได้ปรับเปลี่ยนกระบวนการของพวกเขาอย่างไรเพื่อตอบสนองต่อสถานการณ์ที่ข้อบกพร่องได้ผ่านกระบวนการเปิดตัว

หากพวกเขาไม่สามารถผ่านระดับการตรวจสอบนี้คุณไม่สามารถคาดหวังให้พวกเขาส่งมอบการเผยแพร่ที่เชื่อถือได้อย่างสม่ำเสมอ

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

หากวิธีนี้ไม่สามารถแก้ไขได้แสดงว่ามีปัญหาเกี่ยวกับสถาปัตยกรรมโค้ดซึ่งทำให้การขยายและทดสอบปัญหาพื้นฐานของรหัสปัจจุบันซึ่งในกรณีนี้ไม่มีตัวเลือกที่ดี

หากคุณกำลังมองหาการวัดแบบอัตโนมัติทั้งหมดฉันแนะนำคนเหล่านี้: Software Improvement Group

โดยพื้นฐานแล้วเป็นการรวมตัวชี้วัดต่าง ๆ ที่สามารถแยกได้โดยอัตโนมัติจากซอร์สโค้ด (เช่นการครอบคลุมการทดสอบหน่วยขนาดฟังก์ชั่นการพัวพันของคลาสการทำซ้ำ LOC และอื่น ๆ ) ค่าเหล่านั้นจะถูกแปลงเป็นระดับ 1-5 ดาว

พวกเขายังมีหนังสือที่ดีอธิบายตัวชี้วัดทั้งหมดของพวกเขาในทางปฏิบัติที่มีมูลค่าการอ่าน: 'ซอฟต์แวร์อาคาร Maintainable'