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

Wikipedia บอกว่า Agile เป็น "RAD" ประเภทหนึ่งซึ่งฉันเดาว่าไม่ถูกต้อง จากสิ่งที่ฉันรู้ Agile ได้รับการพัฒนาเนื่องจาก RAD เองนั้นไม่เพียงพอใน 90'S (เข้มงวดเกินไปสำหรับการเปลี่ยนแปลง) หรือฉันผิด (หมายเหตุ: เห็นได้ชัดว่าบทความ Wikipedia เกี่ยวกับการพัฒนาซอฟต์แวร์ Agileได้รับการปรับปรุงในระหว่างนั้นเพียงแค่ระบุว่าRADเป็นผู้บุกเบิกของ Agile ไม่ใช่เป็น superset) การอ้างอิงจากหนังสือ Radical Project Management (Thomsett) ".. แฟชั่นใหม่ของการพัฒนาเช่น RAD, Agile, Object oriented ... " ผู้สอบบัญชีระบบข้อมูลรับรอง CISA: .. ตระหนักถึงซอฟต์แวร์ตัวเลือกสองตัว วิธีการ: การพัฒนาแอพพลิเคชั่นที่คล่องตัวและรวดเร็ว การจัดการแบบว่องไวสำหรับซอฟต์แวร์: วิธีการแบบว่องไวส่วนใหญ่มาจากวิธี RAD ที่มีน้ำหนักเบา แนวทางปฏิบัติที่ดีที่สุดในการประเมินซอฟต์แวร์: วิธีการหลักของ sw dev สามารถสรุปได้ดังนี้: …

16 agile  development-process  rad 

พื้นหลังเล็กน้อยที่นี่ - เราเป็นทีมเล็ก ๆ (จาก 5) ของนักพัฒนา RAD ที่รับผิดชอบการพัฒนาซอฟต์แวร์ภายใน บริษัท ที่ไม่ใช่ซอฟต์แวร์ขนาดใหญ่ "ซอฟต์แวร์ภายใน" แตกต่างจากแอพพลิเคชันเดสก์ท็อป. NET ที่ใช้เซิร์ฟเวอร์ MSSQL เป็นแบ็กเอนด์ไปยังสคริปต์ Python ที่ทำงานบนพื้นหลังไปยังเอกสารและแม่แบบ MS Word - สวนสัตว์ของเทคโนโลยี ทีมงานทั้งหมดประกอบด้วยผู้รอบรู้ทุกคนสามารถรับข้อกำหนดจากผู้ใช้รหัสมันทดสอบและปรับใช้ในการผลิต เมื่อซอฟแวร์ในการผลิตมันถูกดูแลโดยทีมอื่น แต่มันมักจะง่ายสำหรับเราที่จะเข้าไปแทรกแซงหากมีอะไรผิดพลาด ทุกอย่างฟังดูดี แต่มีปัญหา - การเป็นทีม RAD ที่เราต้องปล่อยออกมาบ่อยครั้งและไม่มีวันที่เราจะไม่ปล่อยรุ่นใหม่ของแอปพลิเคชั่นหนึ่งหรือสอง (หรืออาจเป็นสคริปต์เอกสารเวิร์ดที่ได้รับการปรับปรุง แอพคอนโซล C ++ ฯลฯ ) ในการผลิต เราทำการทดสอบการพัฒนาและเกี่ยวข้องกับผู้ใช้ปลายทางโดยให้พวกเขาเรียกใช้ซอฟต์แวร์ในสภาพแวดล้อมของเอือด ... ... แต่ข้อบกพร่องกำลังคืบคลานเข้าสู่การผลิตอยู่ดี ผู้ใช้เข้าใจว่าข้อบกพร่องเหล่านี้และความไม่แน่นอนเป็นครั้งคราวคือราคาที่พวกเขาจ่ายเพื่อให้ได้สิ่งที่พวกเขาต้องการได้อย่างรวดเร็ว แต่ในขณะเดียวกันก็ทำให้เราคิด - บางทีเราอาจปรับปรุงการพัฒนาของเราหรือแนวทางปฏิบัติเพื่อปรับปรุงเสถียรภาพของ ซอฟต์แวร์และลดจำนวนข้อบกพร่องที่เราแนะนำเมื่อเพิ่มฟังก์ชันการทำงานใหม่ สิ่งที่ดี - …

15 development-process  release-management  rad 

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

10 unit-testing  rad