มันมีค่าใช้จ่ายมากในการแก้ไขจุดบกพร่องในตอนท้ายของโครงการหรือไม่?

21

ในการโพสต์บล็อกโดย Andrew Hayความจริงดังต่อไปนี้ถูกโพสต์ :

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

อย่างไรก็ตามสิ่งนี้ดูเหมือนจะไม่แน่นอนโดยเฉพาะหลังจากอ่านโพสต์บล็อกบน Less Wrong ที่ไม่ถูกต้องและข้อมูลที่ฉันเห็นเพื่อสำรองนั้นเก่ามาก

วันนี้ยังคงเป็นความจริงที่ถูกต้องหรือไม่

project-management debugging estimation

— Stefan Hendriks
แหล่งที่มา

@StefanHendriks ความคิดเห็นในลิงก์ของคุณกับบทความจาก Morendil ครอบคลุมทุกอย่างที่คุณสามารถถามได้ IMHO ข้อมูลที่ดีที่นั่น

— Aaron McIver

@AaronMc ฉันตั้งใจว่าจะมีคนรู้จักให้มากขึ้น เช่นกระจายคำและเพิ่มโอกาสในการรับข้อมูลจริง ฉันไม่ค้นหาการสนทนาที่แท้จริง บทความที่ดีถูกจัดขึ้นที่บทความ (ตามที่คุณค้นพบ :))

— Stefan Hendriks

2

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

แม้ว่าสิ่งนี้เกี่ยวข้องกับการเขียนโปรแกรมอย่างแน่นอน แต่ธรรมชาติของคำถามอาจทำให้เหมาะสมกว่าใน critics.stackexchange.com

— StriplingWarrior

16

ข้อมูลฮาร์ดเดียวที่ฉันเคยเห็นเป็นBoehm และ Papaccio ความเข้าใจและการควบคุมค่าใช้จ่ายซอฟต์แวร์

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

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

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

แก้ไข: Doc Brown ทำให้จุดดีในความคิดเห็นของเขา

งานวิจัยของ Boehm ทำในโครงการ COBOL และ FORTRAN ในช่วงเวลาที่คอมไพล์และเวลารันช้าอย่างน่าขัน ฉันเริ่มต้นอาชีพของฉันในช่วงต้น 90s ของ COBOL และวงจรการคอมไพล์และการทดสอบที่ใช้เวลานานจนคุ้มค่ากับความพยายามในการทดสอบโค้ดให้แห้งก่อนที่จะผ่านรอบ (หรืออย่างน้อยในช่วงระยะการสร้าง) คุณสามารถจับบางสิ่งบางอย่างและยกเลิกได้ แต่เช้าช่วยตัวเองสักชั่วโมงหรือมากกว่านั้น)

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

ดังนั้นมันจึงเป็นจริงมากขึ้นกว่าตอนนี้

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

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

— สาธารณรัฐประชาธิปไตยประชาชนลาว
แหล่งที่มา

3

+1 ฉันคิดว่าควรเพิ่มว่าการวิจัยของ Boehm เสร็จสิ้นในเวลาที่ค่าใช้จ่ายในการสร้างและการใช้งานการแก้ไขข้อผิดพลาดนั้นสูงกว่าในปัจจุบันมาก

— Doc Brown

@DocBrown: จุดดี ที่เพิ่ม พร้อมกับเดินเล่นต่อไป

— สาธารณรัฐประชาธิปไตยประชาชนลาว

+1 สำหรับการอ้างอิง +1 สำหรับการสร้างภาพ (แย่มากที่ฉันให้ได้แค่จุดเดียว) คำตอบที่ดีขอบคุณมาก!

— Stefan Hendriks

15

ในขณะที่ฉันไม่ได้รับรู้ข้อมูลที่ยากลำบากหรือหลักฐานอื่นใดเพื่อสนับสนุนการอ้างสิทธิ์นี้อย่างน้อยที่สุดฉันก็เข้าใจว่าเป็นเรื่องธรรมดา

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

นอกจากนี้หากคุณกำลังแก้ไขข้อบกพร่องในช่วงต้นการใช้งานยังคงสดในใจของนักพัฒนา ขึ้นอยู่กับความยาวของโปรเจ็กต์ใดก็ตามหากคุณกำลังแก้ไขบั๊กในตอนท้ายนักพัฒนาจะต้องใช้เวลาในการหาสิ่งที่พวกเขาเขียนและ (อาจ) ระบบย่อยที่โค้ดของพวกเขาขึ้นอยู่กับงาน เวลาที่ใช้ในการเรียนรู้สิ่งนี้ = $

— Demian Brecht
แหล่งที่มา

1

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

— Stefan Hendriks

@StefanHendriks: เรากำลังพูดถึงความพยายามทั้งจำนวนรวมถึงข้อผิดพลาดใหม่ ๆ ที่เกิดขึ้นจากการแก้ไขที่อ้างสิทธิ์ คุณอาจต้องขุดลงในโพสต์โครงการ (คนที่ใช้ทั้งสองวิธี) เพื่อรับข้อมูลจริง

— Demian Brecht

2

@AaronMcIver: เนื้อหาในบทความของฉันไม่ใช่วิธีการที่ดีกว่า แต่การวิจัยและข้อมูลที่ใช้ในการสำรองการอ้างสิทธิ์และการตีความที่ผิดในรายงานที่ตามมา ในขณะที่คำตอบของฉันไม่ได้ขึ้นอยู่กับข้อมูลสาธารณะ แต่ขึ้นอยู่กับประสบการณ์ระดับมืออาชีพกว่า 10 ปีในการจัดการกับระบบที่มีความซับซ้อนสูง

— Demian Brecht

1

BTW ฉันไม่เห็นด้วยที่การเปลี่ยนแปลง CSS จะไม่ได้รับผลกระทบจากสิ่งนี้ ลองแก้ไขปัญหาเลย์เอาต์เมื่อคุณมีพิกเซลของสิ่งอื่น ๆ ที่สมบูรณ์แบบและคุณจะพบว่าคุณอาจต้องแบ่งสิ่งต่าง ๆ มากมาย

— Andrea

1

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

— Aaron McIver

12

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

จำนวนรหัสทั้งหมดในโครงการมีแนวโน้มที่จะเติบโตไปยังจุดสิ้นสุด ยิ่งคุณรอการแก้ไขบั๊กนานเท่าไหร่ฐาน code ยิ่งใหญ่ที่คุณต้องสัมผัส
คุณภาพของรหัสใหม่ที่เพิ่มเข้าไปในโครงการจะลดลงไปจนสุดอย่างน้อยถ้ามีแรงกดดัน (ซึ่งมักจะเป็นเรื่องที่กำหนด): กำหนดเวลาที่ปรากฏทำให้ผู้คนต้องทิ้งแนวปฏิบัติที่ดีที่สุดลงไปเพื่อส่งตรงเวลา ซึ่งหมายความว่าในภายหลังคุณแก้ไขข้อผิดพลาดรหัสที่ไม่ดียิ่งคุณต้องร่อน
แม้ว่าการทำซ้ำรหัสโดยทั่วไปจะขมวดคิ้ว แต่ก็เกิดขึ้นตลอดเวลาและเนื่องจากง่ายต่อการคัดลอกวาง แต่ยากที่จะรวมส่วนรหัสซ้ำกันได้ยากจำนวนครั้งที่คัดลอกวางโดยทั่วไปจะเพิ่มขึ้นตลอดอายุการใช้งานของ โครงการ. รหัสที่คัดลอกวางมากขึ้นหมายถึงโอกาสที่ข้อผิดพลาดของคุณจะถูกทำซ้ำมากขึ้นและจำเป็นต้องพบและแก้ไขหลายครั้ง (และดังนั้นโอกาสที่เหตุการณ์บางอย่างจะไม่ถูกสังเกตเห็นก็จะสูงขึ้น)
แก้ไขข้อผิดพลาดคือการเปลี่ยนแปลง codebase; คุณหวังว่าจะทำให้ดีขึ้น แต่การเปลี่ยนแปลงจะมีความเสี่ยงอยู่เสมอ การเปลี่ยนแปลงที่ทำให้เกิดปัญหาร้ายแรงในโครงการที่ใช้เวลาหลายเดือนควรปล่อยให้มีพื้นที่ว่างเหลือเฟือสำหรับจัดการความเสียหาย แต่ก่อนการจัดส่งสองวันคุณกำลังประสบปัญหาร้ายแรง
ยิ่งบั๊กนานขึ้นก็ยิ่งมีโอกาสมากขึ้นที่ชิ้นส่วนอื่น ๆ ของแอปพลิเคชั่นจะเริ่มพึ่งพาความประพฤติที่ไม่เหมาะสม จากนั้นเมื่อคุณแก้ไขคุณจะปล่อยข้อบกพร่องรองจำนวนมากในรหัสที่ไม่คาดว่าฟังก์ชันของคุณจะให้ผลลัพธ์เอกสารที่ถูกต้อง

— tdammers
แหล่งที่มา

+1 คำตอบที่ดี คัดลอกและวางโค้ดที่มีข้อบกพร่องสร้างข้อบกพร่องมากขึ้นขึ้นอยู่กับโมดูลขึ้นอยู่กับมัน

— Karthik Sreenivasan

2

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

โดยพื้นฐานแล้วค่าใช้จ่ายจะเพิ่มขึ้นตามลำดับความสำคัญเมื่อคุณผ่านขั้นตอนการพัฒนา

บางสิ่งที่มีค่าใช้จ่าย $ 10 เพื่อแก้ไขเมื่อถึงจุดกำเนิดความคิด ...

จะมีค่าใช้จ่ายประมาณ $ 100 หากคุณต้องการอัปเดตข้อกำหนด ...

หรือเสียค่าใช้จ่ายประมาณ $ 1,000 หากมีการใช้งานบางอย่างและคุณต้องทำการเปลี่ยนแปลง ณ จุดนั้น (และอัปเดตข้อมูลจำเพาะและรับการอนุมัติเป็นต้น) แต่ไม่ได้ผ่านการทดสอบการยอมรับ / ขายแบบเป็นทางการบางประเภท

หรือเสียค่าใช้จ่ายประมาณ $ 10,000 หากมีการใช้งานบางอย่างและลูกค้ายอมรับและคุณต้องทำการเปลี่ยนแปลง ณ จุดนั้น (และอัปเดตข้อมูลจำเพาะและรับการอนุมัติและทำการทดสอบซ้ำและเรียกใช้การยอมรับและคุณสมบัติของลูกค้าอีกครั้งและอื่น ๆ )

และค่าใช้จ่ายหลังการใช้งาน / เปิดตัว / วางบริการอีกครั้ง

ตัวอย่างมากมายและง่ายต่อการเข้าใจ: ระบบธนาคารที่มีการเปลี่ยนแปลงขอบเขตอย่างจริงจังหลังจากที่คุณมีพนักงาน 25,000 คนจะใช้แพ็คเก็ตในการฝึกอบรมอีกครั้ง ... ก่อนที่คุณจะพิจารณากำหนดขอบเขตการเข้ารหัสการทดสอบการถดถอย ฯลฯ ฯลฯ

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

— quickly_now
แหล่งที่มา

1

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

— Doc Brown

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

— quick_now

1

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

— Doc Brown

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

— quick_now

2

ฉันไม่สามารถเข้าถึงข้อมูลหรือข้อเท็จจริงอย่างหนักดังนั้นฉันจึงสามารถเสนอข้อมูลที่คุณได้รับจากการรวบรวมข้อมูลทางไอทีในช่วง 20 ปีที่ผ่านมาเท่านั้น

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

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

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

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

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

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

— S.Robins
แหล่งที่มา

1

บั๊กเริ่มต้นจะแพร่กระจายไปยังส่วนอื่น ๆ ของระบบดังนั้นเมื่อคุณแก้ไขข้อผิดพลาดคุณอาจถูกบังคับให้เขียนบางส่วนของระบบที่อาศัยข้อผิดพลาดเอง

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

มันง่ายอย่างนั้นและไม่มีอะไรจะพิสูจน์

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

— Slawek
แหล่งที่มา

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

— Stefan Hendriks

2

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

— Slawek

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

— DaveE

1

ฉันอาจไม่สามารถให้หลักฐานที่ชัดเจนที่คุณขอ แต่ฉันสามารถเชื่อมโยงเหตุการณ์ที่เกิดขึ้นเมื่อไม่นานมานี้จากการทำงานของฉัน

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

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

ฉันเคยเห็นสิ่งที่คล้ายกันในงานก่อนหน้านี้เมื่อมีคนในสายการผลิตตั้งสมมติฐานที่แตกต่างจากข้อสมมติของผู้ใช้ ข้อบกพร่องในการเข้ารหัสแบบตรงขึ้นนั้นค่อนข้างง่ายต่อการจัดการหากถูกดักจับใกล้เมื่อเกิดขึ้น แต่ข้อบกพร่องในการออกแบบสามารถฆ่าทั้งระบบได้

— DaveE
แหล่งที่มา

1

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

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

— อาดัมฉ
แหล่งที่มา

1

ถาม Intel ว่า Pentium Bug มีราคาเท่าไร Ariane 5 Rocket เป็นอีกตัวอย่างที่ดี ข้อผิดพลาดเหล่านี้ได้รับการแก้ไขเมื่อสิ้นสุดโครงการ ฉันทำงานในระบบที่ "พยายาม" ในการเปิดตัวซอฟต์แวร์มีงบประมาณจำนวน 6 ตัวเลข ในกรณีที่รุนแรงเหล่านี้คุณสามารถดูค่าใช้จ่ายได้ง่าย ในกรณีอื่น ๆ (ส่วนใหญ่?) ค่าใช้จ่ายจะถูกซ่อนไว้โดยเสียงรบกวน แต่ก็ยังมีอยู่

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

หากข้อผิดพลาดหนีเข้าไปในป่าค่าใช้จ่ายมีขั้นตอนที่ชาญฉลาดกระโดด ...... เป็น "จุดสิ้นสุดของโครงการ" ก่อนหรือหลังการเปิดตัวซอฟต์แวร์หรือไม่

— mattnz
แหล่งที่มา

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

— tehnyit

ข้อผิดพลาดที่คุณพูดถึงไม่พบ แต่เนิ่นๆ

@ Thorbjørnคุณถูกต้องแน่นอน - ถึงแม้ว่าจะไม่พบข้อบกพร่อง แต่เนิ่นๆที่เราแทรกไว้ก่อนหน้านี้ (ในกรณีของ The Ariane Rocket ข้อผิดพลาดถูกแทรกก่อนที่โครงการจะเริ่มขึ้นแม้จะใช้รหัสที่มีอยู่แล้ว) ค่าใช้จ่ายเป็นสัดส่วนกับเวลาระหว่างการแทรกและการแก้ไขการปรับใช้ไม่มีอะไรจะทำเมื่อพบหรือแก้ไข (นักพัฒนาส่วนใหญ่พิจารณาว่าได้รับการแก้ไขเมื่อแพทช์อยู่ในฐานรหัสข้อบกพร่องไม่คงที่จนกว่าผู้ใช้จะทำการติดตั้ง ) ทั้งหมดนี้เป็นเพียง IMHO แม้ว่า - ฉันไม่มีหลักฐานที่จะสนับสนุน

— mattnz

1

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

จุดที่สองที่พวกเขามีคือสำหรับแต่ละขั้นตอนใน V-model ค่าใช้จ่ายเพิ่มขึ้น 10 เท่า ไม่ว่าปัจจัยนั้นจะถูกต้องหรือไม่ฉันพบว่าไม่เกี่ยวข้อง แต่ข้อผิดพลาดที่มีค่าใช้จ่ายมากที่สุดคือเมื่อการออกแบบของคุณตั้งอยู่บนสมมติฐานที่ไม่ถูกต้อง สิ่งนี้นำไปสู่การเขียนจำนวนมหาศาล รหัสทั้งหมดที่ใช้งานได้เนื่องจากข้อสันนิษฐานนั้น แต่ล้มเหลวเมื่อข้อสันนิษฐานที่ถูกต้องถูกนำไปใช้จะต้องมีการเขียนใหม่

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

— Rune FS
แหล่งที่มา

1

ไม่มีข้อมูลทางสถิติ แต่ประสบการณ์ส่วนตัว:

รหัสควบคุมมอเตอร์จรวดที่ฉันกำลังทำงานมีเหมือน powerCutoff = someCondition && debugOptions.cutoffIsAllowed;กัน ตัวเลือกเริ่มต้นไม่อนุญาตให้มีการตัดออก ว่า 'สุดท้าย' powerCutoff = someCondition;สร้างก็ควรที่จะเอาตัวเลือกทั้งหมดของการแก้ปัญหาเพื่อให้เส้นได้ปรับเปลี่ยนให้

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

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

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

— AShelly
แหล่งที่มา

0

น่าเสียดายที่มันขึ้นอยู่กับหลาย ๆ สิ่ง

หากมีการสะกดข้อความโต้ตอบอาจเป็น 'เรื่องเล็กน้อย' เพื่อแก้ไข (อัปเดตสตริงสร้าง / แพคเกจใหม่ปรับใช้) หรือถ้าเลย์เอาต์ต้องการอัปเดตการแก้ไขไฟล์. css อาจจะเพียงพอ

หากปัญหาคือว่าการส่งออกของวิธีการที่สำคัญที่มี spec 100 หน้าและการพิสูจน์ผิดแล้วการตรวจสอบตัวเองอาจใช้เวลาชั่วโมงหรือวัน นี่คือสิ่งที่ 'สัจพจน์' เก่าอ้างถึงและอะไรคือสิ่งที่ TDD และความคล่องตัวกำลังพยายามหลีกเลี่ยง (ล้มเหลว แต่เนิ่นๆและชัดเจนทำให้ความก้าวหน้าที่เพิ่มขึ้นอย่างปลอดภัยยาดา)

จากประสบการณ์ที่ผ่านมาของฉันกับทีมงานหลายฝ่ายในโครงการเดียวโดยปกติแล้ว 'บั๊ก' มักจะเป็นปัญหาการผสาน / การรวมที่ปรากฏเฉพาะตอนปิดตัวของการวางจำหน่ายเนื่องจากสาขาฟีเจอร์ได้รับการเลื่อนตำแหน่งให้มั่นคง สิ่งเหล่านี้เป็นสิ่งที่เลวร้ายที่สุดเนื่องจากความขัดแย้งมักต้องการการสนับสนุนจากทีมในขณะที่ทีมกำลังวุ่นวายเพื่อให้บรรลุวัตถุประสงค์ของตัวเอง แต่ฉันไม่ทราบว่าพวกเขามีราคาแพงกว่าแมลงตัวอื่น ๆ การเปิดตัว แต่ในเวลาเร็วที่สุดที่พวกเขาสามารถ นั่นคือสิ่งที่ทำให้พวกเขาเลวร้ายที่สุด

— Kristian H
แหล่งที่มา