การพัฒนาโดยผู้ใช้ปลายทาง ( EUD ) หรือการเขียนโปรแกรมโดยผู้ใช้ปลายทาง ( EUP ) หมายถึงกิจกรรมและเครื่องมือที่อนุญาตให้ผู้ใช้ปลายทาง – บุคคลที่ไม่ใช่นักพัฒนาซอฟต์แวร์มืออาชีพ – สามารถ เขียนโปรแกรมคอมพิวเตอร์ได้ บุคคลที่ไม่ใช่นักพัฒนาซอฟต์แวร์มืออาชีพสามารถใช้เครื่องมือ EUD เพื่อสร้างหรือแก้ไขสิ่งประดิษฐ์ซอฟต์แวร์ (คำอธิบายพฤติกรรมอัตโนมัติ) และวัตถุข้อมูลที่ซับซ้อนโดยไม่ต้องมีความรู้เกี่ยวกับภาษาการเขียนโปรแกรม มากนัก ในปี 2548 มีการประมาณการ (โดยใช้สถิติจากสำนักงานสถิติแรงงานของ สหรัฐอเมริกา ) ว่าภายในปี 2555 จะมีนักพัฒนาซอฟต์แวร์โดยผู้ใช้ปลายทางมากกว่า 55 ล้านคนในสหรัฐอเมริกา เมื่อเทียบกับโปรแกรมเมอร์มืออาชีพน้อยกว่า 3 ล้านคน^{[ 1 ]}มีแนวทาง EUD ที่หลากหลาย และเป็นหัวข้อการวิจัย ที่กำลังดำเนิน อยู่ภายในสาขาวิทยาการคอมพิวเตอร์และ ปฏิสัมพันธ์ ^{ระหว่าง}มนุษย์กับคอมพิวเตอร์ตัวอย่างเช่นการเขียนโปรแกรมภาษาธรรมชาติ [ ^{2 ] [ 3 ]}สเปรดชีต^{[ 4 ]}ภาษาสคริปต์ (โดยเฉพาะในชุดโปรแกรมสำนักงานหรือแอปพลิเคชันศิลปะ) การเขียน โปรแกรมแบบภาพ การ เขียน โปรแกรมแบบทริกเกอร์-แอคชั่น และการเขียนโปรแกรมโดยใช้ตัวอย่าง

เครื่องมือ EUD ที่ได้รับความนิยมมากที่สุดคือสเปรดชีต^{[ 4 ] [ 5 ]}เนื่องจากลักษณะที่ไม่จำกัด สเปรดชีตจึงช่วยให้ผู้ใช้คอมพิวเตอร์ที่ไม่เชี่ยวชาญมากนักสามารถเขียนโปรแกรมที่แสดงแบบจำลองข้อมูลที่ซับซ้อนได้ ในขณะเดียวกันก็ป้องกันไม่ให้พวกเขาต้องเรียนรู้ภาษาการเขียนโปรแกรมระดับต่ำ[ ^{6 ] เนื่องจาก} การใช้งานทั่วไปในธุรกิจ ทักษะสเปรดชีตจึงเป็นหนึ่งในทักษะที่เป็นประโยชน์ที่สุดสำหรับพนักงานที่จบการศึกษา และด้วยเหตุนี้จึงเป็นที่ต้องการมากที่สุด^{[ 7 ]}ในสหรัฐอเมริกาเพียงประเทศเดียว มีนักพัฒนาผู้ใช้ปลายทางประมาณ 13 ล้านคนที่เขียนโปรแกรมด้วยสเปรดชีต^{[ 8 ]}

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

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

เมื่อไม่นานมานี้ ความสนใจในการใช้ EUD เพื่อสนับสนุนการพัฒนาแอปพลิเคชัน Internet of Things ได้เพิ่มมากขึ้น ในด้านนี้ การเขียนโปรแกรมแบบทริกเกอร์-แอคชั่นดูเหมือนจะเป็นแนวทางที่น่าสนใจ^{[ 10 ]}

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

ปัจจุบันมีผู้จำหน่ายประมาณ 40 รายที่นำเสนอโซลูชันที่มุ่งเป้าไปที่ผู้ใช้ปลายทางซึ่งออกแบบมาเพื่อลดความพยายามในการเขียนโปรแกรม โซลูชันเหล่านี้ไม่จำเป็นต้องใช้การเขียนโปรแกรมแบบดั้งเดิม และอาจมีฟังก์ชันการทำงานที่ค่อนข้างจำกัด เช่น การจัดการสัญญา การจัดการความสัมพันธ์กับลูกค้า การติดตามปัญหาและข้อบกพร่อง มักเรียกกันว่าแพลตฟอร์มการพัฒนาแบบ low code การโต้ตอบบนเว็บจะแนะนำผู้ใช้ให้พัฒนาแอปพลิเคชันได้ภายในเวลาเพียง 40–80 ชั่วโมง^{[ 11 ]}

Lieberman และคณะเสนอคำจำกัดความดังต่อไปนี้: ^{[ 12 ]}

การพัฒนาโดยผู้ใช้ปลายทาง (End-User Development) สามารถนิยามได้ว่าเป็นชุดของวิธีการ เทคนิค และเครื่องมือที่ช่วยให้ผู้ใช้ระบบซอฟต์แวร์ ซึ่งไม่ใช่ผู้พัฒนาซอฟต์แวร์มืออาชีพ สามารถสร้าง แก้ไข หรือต่อยอดซอฟต์แวร์ได้ในบางช่วงเวลา

Ko และคณะเสนอคำจำกัดความดังต่อไปนี้: ^{[ 13 ]}

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

สิ่งประดิษฐ์ที่กำหนดโดยผู้ใช้ปลายทางอาจเป็นวัตถุที่อธิบายพฤติกรรมอัตโนมัติหรือลำดับการควบคุมบางอย่าง เช่น การร้องขอฐานข้อมูลหรือกฎไวยากรณ์^{[ 14 ]}ซึ่งสามารถอธิบายได้ด้วยกระบวนทัศน์การเขียนโปรแกรม เช่นการเขียนโปรแกรมโดยการสาธิตการเขียนโปรแกรมด้วยตัวอย่างการเขียนโปรแกรมแบบภาพหรือการสร้างมาโคร^{[ 15 ]}นอกจากนี้ยังอาจเป็นพารามิเตอร์ที่เลือกระหว่างพฤติกรรมที่กำหนดไว้ล่วงหน้าทางเลือกของแอปพลิ เคชัน ^{[ 16 ]}สิ่งประดิษฐ์อื่นๆ ของการพัฒนาโดยผู้ใช้ปลายทางอาจหมายถึงการสร้างเนื้อหาที่ผู้ใช้สร้างขึ้น เช่น คำอธิบายประกอบ ซึ่งอาจตีความได้ด้วยคอมพิวเตอร์หรือไม่ก็ได้ (เช่น สามารถประมวลผลได้ด้วยฟังก์ชันอัตโนมัติที่เกี่ยวข้อง) ^{[ 17 ]}

ตัวอย่างของการพัฒนาโดยผู้ใช้ปลายทาง ได้แก่ การสร้างและการแก้ไข:

• สคริปต์ แอนิเมชั่นที่นักออกแบบกราฟิกใช้เพื่ออธิบายตัวละคร สภาพแวดล้อม และวิธีการเคลื่อนไหวของตัวละคร เพื่อสร้างแอนิเมชั่นตามที่ต้องการ
• ไฟล์การกำหนดค่าที่ทำให้เส้นแบ่งระหว่างโปรแกรมและข้อมูลไม่ชัดเจน (เช่นตัวกรองอีเมลเป็นรายการลำดับของเกณฑ์และขั้นตอนการดำเนินการ)
• เครื่องมือการเขียนโปรแกรมแบบเน้นตัวอย่าง^{[ 18 ]}
• การดัดแปลงเกมเพื่อให้ผู้ใช้สามารถเพิ่มตัวละคร สภาพแวดล้อม ฯลฯ ของตนเองได้ — เกมใหม่ๆ หลายเกมถูกจัดจำหน่ายโดยคำนึงถึงการดัดแปลงเกมเป็นหลัก
• สคริปต์การโต้ตอบที่ใช้ในศูนย์บริการลูกค้า CRM
• เครื่องมือพัฒนาแอปพลิเคชันบนมือถือ เช่นApp Inventor
• แบบจำลองกระบวนการที่ใช้ในแอปพลิเคชันเวิร์กโฟลว์
• ต้นแบบและโปรแกรมเฉพาะด้านที่เขียนขึ้นโดยนักธุรกิจ วิศวกร และนักวิทยาศาสตร์ เพื่อสาธิตหรือทดสอบทฤษฎีเฉพาะด้าน
• พฤติกรรมหุ่นยนต์^{[ 19 ]}
• แบบจำลองทางวิทยาศาสตร์ที่ใช้ในการจำลองด้วยคอมพิวเตอร์
• เพิ่มสคริปต์และมาโครเพื่อขยายหรือทำให้ชุดโปรแกรมสำนักงานและแอปพลิเคชันกราฟิกทำงาน โดยอัตโนมัติ
• การจำลองที่สร้างขึ้นโดยใช้ซอฟต์แวร์กำหนดแอปพลิเคชัน
• การแก้ไขรายการที่เกี่ยวข้องหลายรายการพร้อมกันได้ ทั้งผ่านกระบวนการแบบกลุ่มตามที่ผู้ใช้กำหนด หรือโดยการจัดการโดยตรงเช่นเดียวกับที่มีอยู่ในโปรแกรมแก้ไขข้อความและ การ แก้ไขหลายรายการ ของ Lapis
• แบบจำลอง สเปรดชีตเช่น ใช้สำหรับการจัดทำงบประมาณ การวิเคราะห์ความเสี่ยง การเรียนรู้ของเครื่องจักรแบบโต้ตอบ[ 20 ^{]หรือการ}ออกแบบวงจรอิเล็กทรอนิกส์^{[ 21 ]}
• การเขียนโปรแกรมด้วยภาพในรูปแบบของภาษาภาพ เช่นAgentSheets , LabVIEW , Scratch (ภาษาโปรแกรม)หรือLEGO Mindstorms
• หน้าเว็บ - HTML ธรรมดา หรือ HTML ผสมสคริปต์
• วิกิ - กระบวนการพัฒนาร่วมกันของผู้ใช้ปลายทาง^{[ 22 ]}
• เว็บ Mashupในรูปแบบของภาษาภาพ^{[ 23 ]}
• โมเดล 3 มิติที่สร้างขึ้นด้วยเครื่องมือและแอปพลิเคชันที่เน้นผู้ใช้เป็นหลัก เช่นSketchup

ตามที่Sutcliffe กล่าวไว้ [ ^{24 ] EUD โดยพื้นฐานแล้วจะ มอบหมาย}ความพยายามในการพัฒนาให้กับผู้ใช้ปลายทาง เนื่องจากต้องใช้ความพยายามในการเรียนรู้เครื่องมือ EUD เสมอ แรงจูงใจของผู้ใช้จึงขึ้นอยู่กับความมั่นใจว่าเครื่องมือดังกล่าวจะช่วยเพิ่มประสิทธิภาพการทำงาน ประหยัดเวลาในการทำงาน หรือเพิ่มผลผลิต ในแบบจำลองนี้ ประโยชน์ที่ผู้ใช้จะได้รับนั้นเริ่มต้นจากการตลาด การสาธิต และการบอกต่อ เมื่อนำเทคโนโลยีไปใช้งานแล้ว ประสบการณ์จากประโยชน์ที่แท้จริงจะกลายเป็นแรงจูงใจหลัก

การศึกษานี้กำหนดต้นทุนว่าเป็นผลรวมของ:

• ต้นทุนทางเทคนิค: ราคาของเทคโนโลยีและความพยายามในการติดตั้ง
• ต้นทุนการเรียนรู้: เวลาที่ใช้ในการทำความเข้าใจเทคโนโลยี
• ต้นทุนการพัฒนา: ความพยายามในการพัฒนาแอปพลิเคชันโดยใช้เทคโนโลยีนั้น
• ต้นทุนการทดสอบและการแก้ไขข้อผิดพลาด: เวลาที่ใช้ในการตรวจสอบระบบ

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

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

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

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

ในการทำงานร่วมกันนี้ มีการเสนอแนวทางต่างๆ เช่น Software Shaping Workshop ^{[ 28 ]}เพื่อเชื่อมช่องว่างการสื่อสารระหว่างนักพัฒนาซอฟต์แวร์มืออาชีพและนักพัฒนาซอฟต์แวร์ผู้ใช้ปลายทาง แนวทางเหล่านี้มักจะให้ความโปร่งใสตามแบบจำลองความโปร่งใสทางสังคม^{[ 29 ]}ทำให้ทุกคนในการทำงานร่วมกันสามารถรับรู้ถึงการเปลี่ยนแปลงที่ผู้อื่นทำและรับผิดชอบต่อการกระทำของตนเองได้เนื่องจากการรับรู้ดังกล่าว

นอกจากแพลตฟอร์มการทำงานร่วมกันในการเขียนโปรแกรม เช่น GitHub ซึ่งส่วนใหญ่ใช้โดยนักพัฒนาผู้เชี่ยวชาญเนื่องจากมีขั้นตอนการเรียนรู้ที่ค่อนข้างยาก การทำงานร่วมกันระหว่างนักพัฒนาผู้ใช้ปลายทางมักเกิดขึ้นบนแพลตฟอร์มวิกิซึ่งมีการแบ่งปันสิ่งประดิษฐ์ซอฟต์แวร์ที่สร้างขึ้น การพัฒนาโดยผู้ใช้ปลายทางยังมักใช้สำหรับการสร้างสคริปต์อัตโนมัติหรือบทช่วยสอนแบบโต้ตอบเพื่อแบ่งปันความรู้ "วิธีการ" ตัวอย่างของแอปพลิเคชันดังกล่าว ได้แก่ CoScripter ^{[ 30 ]}และ HILC ^{[ 31 ]}ในแอปพลิเคชันดังกล่าว ผู้ใช้สามารถสร้างสคริปต์สำหรับงานโดยใช้ภาษาเสมือนธรรมชาติหรือผ่านการเขียนโปรแกรมโดยการสาธิต ผู้ใช้สามารถเลือกที่จะอัปโหลดสคริปต์ไปยังที่เก็บสคริปต์แบบวิกิ ผู้ใช้ในวิกิดังกล่าวสามารถเรียกดูสคริปต์ที่มีอยู่และขยายสคริปต์ที่มีอยู่เพื่อรองรับพารามิเตอร์เพิ่มเติม จัดการเงื่อนไขเพิ่มเติม หรือดำเนินการกับวัตถุเพิ่มเติม

ชุมชนนักพัฒนาผู้ใช้ปลายทางทั้งแบบออนไลน์และออฟไลน์ได้ก่อตัวขึ้นแล้ว โดยนักพัฒนาผู้ใช้ปลายทางสามารถร่วมมือกันแก้ไขปัญหา EUD ที่มีความสนใจร่วมกันหรือเพื่อผลประโยชน์ร่วมกัน ในชุมชนดังกล่าว ผู้เชี่ยวชาญในท้องถิ่นจะเผยแพร่ความเชี่ยวชาญและคำแนะนำ สมาชิกในชุมชนยังให้การสนับสนุนทางสังคมซึ่งกันและกันเพื่อสนับสนุนการสร้างซอฟต์แวร์ร่วมกัน^{[ 32 ]}

ผู้แสดงความคิดเห็นต่างกังวลว่าผู้ใช้ปลายทางไม่เข้าใจวิธีการทดสอบและรักษาความปลอดภัยแอปพลิเคชันของตน วอร์เรน แฮร์ริสัน ศาสตราจารย์ด้านวิทยาการคอมพิวเตอร์แห่งมหาวิทยาลัยพอร์ตแลนด์สเตท เขียนไว้ว่า: ^{[ 33 ]}

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

มุมมองนี้ถือว่าผู้ใช้ปลายทางทุกคนไร้เดียงสาเท่ากันเมื่อพูดถึงการทำความเข้าใจซอฟต์แวร์ แม้ว่า Pliskin และ Shoval จะโต้แย้งว่าไม่ใช่เช่นนั้น ผู้ใช้ปลายทางที่มีความเชี่ยวชาญสามารถพัฒนาซอฟต์แวร์ได้^{[ 34 ]}อย่างไรก็ตาม เมื่อเปรียบเทียบกับโปรแกรมเมอร์ผู้เชี่ยวชาญ โปรแกรมเมอร์ผู้ใช้ปลายทางมักไม่มีเวลาหรือความสนใจในกิจกรรมด้านวิศวกรรมซอฟต์แวร์ที่เป็นระบบและมีระเบียบวินัย^{[ 35 ]}ซึ่งทำให้การรับรองคุณภาพของซอฟต์แวร์ที่สร้างขึ้นโดยการพัฒนาโดยผู้ใช้ปลายทางเป็นเรื่องที่ท้าทายอย่างยิ่ง

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

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

• การตั้งโปรแกรมอัตโนมัติ
• การประมวลผลของผู้ใช้ปลายทาง
• แพลตฟอร์มการพัฒนาแบบ Low-code
• การเขียนโปรแกรมภาษาธรรมชาติ
• การประยุกต์ใช้ตามสถานการณ์
• วิศวกรรมซอฟต์แวร์
• วิศวกรรมซอฟต์แวร์โดยใช้คอมพิวเตอร์ช่วย (CASE)

• ไซเฟอร์, อัลเลน (1993). ดูสิ่งที่ฉันทำ: การเขียนโปรแกรมโดยการสาธิต . ผู้ร่วมเขียน: แดเนียล ซี. ฮัลเบิร์ต. สำนักพิมพ์: MIT Press. ISBN 978-0-262-03213-1.{{cite book}}: CS1 maint: ตำแหน่งผู้เผยแพร่ ( ลิงก์ )
• ลีเบอร์แมน, เฮนรี (2001). ความปรารถนาของคุณคือคำสั่งของฉัน: การเขียนโปรแกรมโดยใช้ตัวอย่างผู้ร่วมเขียน: เบน ชไนเดอร์แมน สำนักพิมพ์: มอร์แกน คอฟแมนน์ISBN 978-1-55860-688-3.{{cite book}}: CS1 maint: ตำแหน่งผู้เผยแพร่ ( ลิงก์ )
• F. Paternò (2013) การพัฒนาผู้ใช้ปลายทาง: การสำรวจสาขาใหม่ที่กำลังเกิดขึ้นเพื่อเพิ่มศักยภาพให้กับผู้คน , ISRN Software Engineering, เล่มที่ 2013, บทความหมายเลข 532659, 11 หน้า, 2013. doi : 10.1155/2013/532659 , 2013
• B. Guo, D. Zhang, M. Imai. การเปิดใช้งานการจัดการที่มุ่งเน้นผู้ใช้สำหรับการประมวลผลแบบยูบิควิตัส: แนวทางการออกแบบเชิงเมตา, เครือข่ายคอมพิวเตอร์, Elsevier, เล่มที่ 54, ฉบับที่ 16, 2010.
• Burnett, Margaret M. และ Scaffidi, Christopher (2011): การพัฒนาผู้ใช้ปลายทางใน: Soegaard, Mads and Dam, Rikke Friis (บรรณาธิการ) "สารานุกรมปฏิสัมพันธ์ระหว่างมนุษย์กับคอมพิวเตอร์"
• Kierkegaard, Patrick (2011) Kierkegaard, Patrick ( 2011). "การเสริมสร้างการพัฒนาผู้ใช้ปลายทาง: การคุ้มครองทางกฎหมายและการปฏิบัติตามกฎระเบียบ" การพัฒนาผู้ ใช้ปลายทางบันทึกการบรรยายในวิทยาการคอมพิวเตอร์ เล่มที่ 6654/2011 หน้า  203–217 doi : 10.1007/978-3-642-21530-8_16 ISBN 978-3-642-21529-2.{{cite book}}: |journal=ละเลย ( ช่วยเหลือ )

• การประชุมวิชาการนานาชาติครั้งที่ 2 ว่าด้วยการพัฒนาโดยผู้ใช้งานปลายทาง
• EUSES Consortium คือกลุ่มความร่วมมือที่ทำการวิจัยเกี่ยวกับการประมวลผลสำหรับผู้ใช้ปลายทาง
• หนังสือการพัฒนาผู้ใช้ปลายทาง
• เครือข่ายความเป็นเลิศด้านการพัฒนาผู้ใช้ปลายทางของคณะกรรมาธิการยุโรปเก็บถาวรเมื่อวันที่ 3 มีนาคม 2016 ที่Wayback Machine
• งานประชุมวิชาการนานาชาติว่าด้วยการพัฒนาสำหรับผู้ใช้ปลายทาง