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

แนวคิดของอาร์นี ลินด์ คือ แทนที่จะให้ผู้พัฒนาแอปพลิเคชันเรียนรู้เกี่ยวกับงานของคนอื่น ควรสอนให้คนที่ทำงานนั้นรู้วิธีเขียนแอปพลิเคชัน อาร์นีเสนอแนวคิดนี้ให้กับคาร์ล คอร์โคแรน รองประธานของ IBM แคนาดา (ซึ่งต่อมาเป็นประธานของ IBM แคนาดา) และคาร์ลก็อนุมัติโครงการนำร่อง อาร์นีและคาร์ลร่วมกันตั้งชื่อวิธีการนี้ว่า JAD ซึ่งเป็นตัวย่อของ joint application design หลังจากที่คาร์ล คอร์โคแรนปฏิเสธตัวย่อ JAL หรือ joint application logistics เมื่อรู้ว่าอักษรย่อของอาร์นี ลินด์ คือ JAL (จอห์น อาร์โนลด์ ลินด์)

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

อาร์นี ลินด์ ใช้เวลา 13 ปีต่อมาที่ IBM แคนาดา พัฒนาวิธีการ JAD อย่างต่อเนื่อง และเดินทางไปทั่วโลกเพื่อจัดสัมมนา JAD และฝึกอบรมพนักงาน IBM ในวิธีการและเทคนิคของ JAD การใช้ JAD แพร่หลายไปทั่ว IBM แคนาดา และเทคนิคนี้ยังแพร่กระจายไปยัง IBM ในสหรัฐอเมริกาด้วย อาร์นี ลินด์ ฝึกอบรมบุคคลหลายคนใน IBM แคนาดาให้สามารถใช้ JAD ได้ รวมถึง โทนี่ ครอว์ฟอร์ด และ ชัค มอร์ริส อาร์นี ลินด์ เกษียณจาก IBM ในปี 1987 และยังคงสอนและใช้ JAD ในฐานะที่ปรึกษาต่อไปทั่วแคนาดา สหรัฐอเมริกา และเอเชีย

กระบวนการ JAD ได้รับการกำหนดรูปแบบอย่างเป็นทางการโดย Tony Crawford และ Chuck Morris จาก IBM ในช่วงปลายทศวรรษ 1970 จากนั้นจึงนำไปใช้ที่ Canadian International Paper JAD ถูกใช้ใน IBM แคนาดาอยู่ระยะหนึ่งก่อนที่จะนำกลับมาใช้ในสหรัฐอเมริกา ในตอนแรก IBM ใช้ JAD เพื่อช่วยในการขายและใช้งานโปรแกรมซอฟต์แวร์ที่พวกเขาขาย ซึ่งเรียกว่า COPICS มันถูกปรับใช้ในวงกว้างเพื่อการใช้งานหลายอย่าง (ข้อกำหนดของระบบ การออกแบบ ลิฟต์ขนส่งเมล็ดพืชการแก้ปัญหา ฯลฯ) ต่อมา Tony Crawford ได้พัฒนา JAD-Plan และ JAR (ข้อกำหนดแอปพลิเคชันร่วม) ในปี 1985 Gary Rush ได้เขียนเกี่ยวกับ JAD และอนุพันธ์ของมัน – เทคนิคการกำหนดคุณสมบัติแอปพลิเคชันแบบอำนวยความสะดวก (FAST) – ^ใน Computerworld [ ^{1 ]}

เดิมที JAD ได้รับการออกแบบมาเพื่อรวบรวมนักพัฒนาระบบและผู้ใช้จากภูมิหลังและความคิดเห็นที่แตกต่างกันเข้าด้วยกันในสภาพแวดล้อมที่สร้างสรรค์และมีประสิทธิภาพ การประชุมเป็นวิธีหนึ่งในการรวบรวมข้อกำหนดและรายละเอียดที่มีคุณภาพ แนวทางที่มีโครงสร้างนี้เป็นทางเลือกที่ดีสำหรับการสัมภาษณ์แบบอนุกรมแบบดั้งเดิมโดยนักวิเคราะห์ระบบ JAD ได้ขยายขอบเขตไปครอบคลุมงานด้านไอทีที่กว้างขึ้น รวมถึงงานที่ไม่ใช่ไอทีด้วย (อ่านเกี่ยวกับเทคนิคการกำหนดรายละเอียดแอปพลิเคชันแบบอำนวยความสะดวก – FAST – ที่สร้างโดย Gary Rush ในปี 1985 เพื่อขยายขอบเขตการใช้งานของ JAD ^{[ 2 ]}

ผู้สนับสนุนระดับบริหาร

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

ผู้เชี่ยวชาญเฉพาะด้าน

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

ผู้ประสานงาน/ผู้นำการอบรม

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

นักเขียน/นักสร้างแบบจำลอง/ผู้บันทึก/ผู้เชี่ยวชาญด้านเอกสาร

บันทึกและเผยแพร่รายงานการประชุม และไม่ให้ข้อมูลใดๆ แก่การประชุม

ผู้สังเกตการณ์

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

1. ระบุวัตถุประสงค์และข้อจำกัดของโครงการ : การมีวัตถุประสงค์ที่ชัดเจนสำหรับเวิร์กช็อปและสำหรับโครงการโดยรวมนั้นมีความสำคัญอย่างยิ่ง กิจกรรมก่อนเวิร์กช็อป การวางแผนและการกำหนดขอบเขต จะกำหนดความคาดหวังของผู้สนับสนุนและผู้เข้าร่วมเวิร์กช็อป การกำหนดขอบเขตจะระบุฟังก์ชันทางธุรกิจที่อยู่ในขอบเขตของโครงการ นอกจากนี้ยังพยายามประเมินความซับซ้อนของการออกแบบและการดำเนินการโครงการด้วย ควรประเมินความอ่อนไหวทางการเมืองของโครงการ เคยมีการดำเนินการเช่นนี้มาก่อนหรือไม่ มีการเริ่มต้นที่ไม่ประสบความสำเร็จกี่ครั้ง มีความล้มเหลวในการดำเนินการกี่ครั้ง การกำหนดขนาดมีความสำคัญ สำหรับผลลัพธ์ที่ดีที่สุด โครงการระบบควรมีขนาดที่เหมาะสมเพื่อให้สามารถออกแบบระบบทั้งหมด ตั้งแต่หน้าจอไปจนถึงเมนู ได้ภายใน 8 ถึง 10 วันทำการของเวิร์กช็อป
2. ระบุปัจจัยแห่งความสำเร็จที่สำคัญ : การระบุปัจจัยแห่งความสำเร็จที่สำคัญสำหรับทั้งโครงการพัฒนาและฟังก์ชันทางธุรกิจที่กำลังศึกษาเป็นสิ่งสำคัญ เราจะรู้ได้อย่างไรว่าการเปลี่ยนแปลงที่วางแผนไว้ได้ผล? จะวัดความสำเร็จได้อย่างไร? การวางแผนการประเมินผลลัพธ์จะช่วยให้สามารถตัดสินประสิทธิภาพและคุณภาพของระบบที่นำไปใช้ตลอดอายุการใช้งานได้
3. กำหนดผลลัพธ์ของโครงการ : โดยทั่วไปแล้ว ผลลัพธ์จากเวิร์กช็อปคือเอกสารและแบบร่าง สิ่งสำคัญคือต้องกำหนดรูปแบบและระดับรายละเอียดของเอกสารเวิร์กช็อป จะต้องมีแผนภาพประเภทใดบ้าง? จะต้องมีคำอธิบายในรูปแบบใด? ควรเริ่มใช้ เครื่องมือ CASEสำหรับช่วยสร้างแผนภาพตั้งแต่เริ่มต้น เครื่องมือส่วนใหญ่ที่มีอยู่มีความสามารถในการสร้างแผนภาพที่ดีถึงดีมาก แต่การสนับสนุนด้านคำอธิบายมักจะอ่อนแอ การสร้างคำอธิบายที่ดีที่สุดนั้นทำได้ด้วยโปรแกรมประมวลผลคำมาตรฐานของคุณ
4. กำหนดตารางกิจกรรมการประชุมเชิงปฏิบัติการ : การประชุมเชิงปฏิบัติการมีระยะเวลาตั้งแต่หนึ่งถึงห้าวัน การประชุมเชิงปฏิบัติการครั้งแรกสำหรับโครงการไม่ควรน้อยกว่าสามวัน ผู้เข้าร่วมจะใช้เวลาส่วนใหญ่ในวันแรกเพื่อทำความคุ้นเคยกับบทบาทของตนเอง เพื่อนร่วมงาน และสภาพแวดล้อม วันที่สองจะใช้เวลาในการเรียนรู้ที่จะเข้าใจซึ่งกันและกันและพัฒนารูปแบบการสื่อสารร่วมกันเกี่ยวกับปัญหาและข้อกังวลต่างๆ ในวันที่สาม ทุกคนจะทำงานร่วมกันเพื่อแก้ไขปัญหาและบรรลุผลผลิตที่แท้จริง หลังจากการประชุมเชิงปฏิบัติการครั้งแรก การสร้างทีมก็เสร็จสิ้นลงแล้ว สามารถกำหนดการประชุมเชิงปฏิบัติการที่สั้นกว่าได้สำหรับขั้นตอนต่อๆ ไปของโครงการ เช่น เพื่อตรวจสอบต้นแบบ อย่างไรก็ตาม ผู้เข้าร่วมจะต้องใช้เวลาหนึ่งถึงสามชั่วโมงในการสร้างความสัมพันธ์ในทีมขึ้นมาใหม่เหมือนการประชุมเชิงปฏิบัติการครั้งแรก
5. คัดเลือกผู้เข้าร่วม : บุคคลเหล่านี้คือผู้ใช้งานทางธุรกิจ ผู้เชี่ยวชาญด้านไอที และผู้เชี่ยวชาญภายนอกที่จำเป็นต่อความสำเร็จของการจัดเวิร์คช็อป พวกเขาคือ "แกนหลัก" ที่แท้จริงของการประชุม ซึ่งจะเป็นผู้ขับเคลื่อนการเปลี่ยนแปลง
6. เตรียมเอกสารสำหรับเวิร์คช็อป : ก่อนเริ่มเวิร์คช็อป ผู้จัดการโครงการและผู้ดำเนินงานจะทำการวิเคราะห์และสร้างแบบร่างเบื้องต้นหรือแบบจำลองคร่าวๆ เพื่อเป็นจุดเน้นของเวิร์คช็อป เอกสารประกอบเวิร์คช็อปประกอบด้วยเอกสาร ใบงาน แผนภาพ และแม้แต่สื่อประกอบฉากที่จะช่วยให้ผู้เข้าร่วมเข้าใจฟังก์ชันทางธุรกิจที่กำลังศึกษา
7. จัดกิจกรรมและแบบฝึกหัดในเวิร์กช็อป : ผู้ดำเนินงานต้องออกแบบแบบฝึกหัดและกิจกรรมในเวิร์กช็อปเพื่อให้ได้ผลลัพธ์ระหว่างทางที่นำไปสู่ผลลัพธ์สุดท้ายของเวิร์กช็อป กิจกรรมก่อนเวิร์กช็อปช่วยในการออกแบบแบบฝึกหัดเหล่านั้น ตัวอย่างเช่น สำหรับการวิเคราะห์พื้นที่ธุรกิจ จะมีอะไรบ้าง? แผนภาพการแยกส่วน? แผนภาพความสัมพันธ์ระหว่างเอนทิตีระดับสูง? แบบจำลองข้อมูลแบบนอร์มาไลซ์? แผนภาพการเปลี่ยนสถานะ? แผนภาพการพึ่งพา? ทั้งหมดข้างต้น? ไม่มีข้อใดข้างต้น? สิ่งสำคัญคือต้องกำหนดระดับของแผนภาพทางเทคนิคที่เหมาะสมกับสภาพแวดล้อม สิ่งที่สำคัญที่สุดเกี่ยวกับแผนภาพคือผู้ใช้ต้องเข้าใจได้ เมื่อเลือกแผนภาพแล้ว ผู้ดำเนินงานจะออกแบบแบบฝึกหัดลงในวาระการประชุมเวิร์กช็อปเพื่อให้กลุ่มพัฒนาแผนภาพเหล่านั้น เวิร์กช็อปจะรวมแบบฝึกหัดที่มุ่งเน้นตามลำดับเพื่อสร้างต่อยอดซึ่งกันและกัน และแบบฝึกหัดแบบคู่ขนาน โดยแต่ละทีมย่อยทำงานในส่วนหนึ่งของปัญหาหรือทำงานในเรื่องเดียวกันสำหรับพื้นที่การทำงานที่แตกต่างกัน แบบฝึกหัดที่มีความเข้มข้นสูงซึ่งนำโดยผู้ดำเนินงานจะช่วยกระตุ้นกลุ่มและชี้นำไปสู่เป้าหมายที่เฉพาะเจาะจง แบบฝึกหัดที่มีความเข้มข้นต่ำช่วยให้มีการอภิปรายอย่างละเอียดก่อนตัดสินใจ การอภิปรายอาจเกี่ยวข้องกับกลุ่มทั้งหมด หรือทีมต่างๆ อาจร่วมกันแก้ไขปัญหาและนำเสนอข้อเสนอแนะจำนวนจำกัดเพื่อให้กลุ่มทั้งหมดพิจารณา เพื่อให้ผู้เข้าร่วมทำงานร่วมกัน ผู้ดำเนินงานสามารถจับคู่ผู้ที่มีความเชี่ยวชาญคล้ายกันจากแผนกต่างๆ ได้ เพื่อช่วยให้ผู้เข้าร่วมเรียนรู้ซึ่งกันและกัน ผู้ดำเนินงานสามารถผสมผสานความเชี่ยวชาญได้ ขึ้นอยู่กับผู้ดำเนินงานที่จะผสมผสานและจับคู่สมาชิกในทีมย่อยเพื่อให้บรรลุวัตถุประสงค์ด้านองค์กร วัฒนธรรม และการเมืองของเวิร์กช็อป เวิร์กช็อปดำเนินการทั้งในระดับเทคนิคและระดับการเมือง หน้าที่ของผู้ดำเนินงานคือการสร้างฉันทามติและการสื่อสาร เพื่อผลักดันประเด็นปัญหาออกมาตั้งแต่เนิ่นๆ ในกระบวนการ ไม่จำเป็นต้องกังวลเกี่ยวกับการนำระบบไปใช้ในทางเทคนิคหากไม่สามารถแก้ไขปัญหาทางธุรกิจพื้นฐานได้
8. เตรียมความพร้อม แจ้งข้อมูล และให้ความรู้แก่ผู้เข้าร่วมการอบรม : ผู้เข้าร่วมการอบรมทุกคนต้องรับทราบถึงวัตถุประสงค์และข้อจำกัดของโครงการ รวมถึงผลลัพธ์ที่คาดหวังจากการอบรม การบรรยายสรุปควรจัดขึ้น 1-5 วันก่อนการอบรม การบรรยายสรุปนี้อาจทำผ่านการประชุมทางไกลหากผู้เข้าร่วมกระจายตัวอยู่หลายแห่ง เอกสารการบรรยายสรุปอาจเรียกว่า คู่มือการทำความคุ้นเคย คู่มือการบรรยายสรุป คำจำกัดความขอบเขตโครงการ หรือคู่มือการกำหนดขอบเขตการจัดการ หรือชื่ออื่นใดที่เหมาะสม เอกสารนี้มีความยาวแปดถึงสิบสองหน้า และให้คำจำกัดความที่ชัดเจนเกี่ยวกับขอบเขตของโครงการแก่ผู้เข้าร่วม การบรรยายสรุปใช้เวลาสองถึงสี่ชั่วโมง เพื่อเตรียมความพร้อมทางจิตใจที่ทุกคนต้องการก่อนที่จะเข้าร่วมการอบรม
9. วางแผนและจัดเตรียมอุปกรณ์สำหรับการจัดเวิร์คช็อป : ควรจัดเวิร์คช็อปนอกสถานที่เพื่อหลีกเลี่ยงการรบกวน ควรเตรียมโปรเจ็กเตอร์ จอฉาย คอมพิวเตอร์ โต๊ะ ปากกาไวท์บอร์ด เทปกาว โพสต์อิท และอุปกรณ์ประกอบฉากอื่นๆ ให้พร้อม ผู้จัดเวิร์คช็อปจะเลือกอุปกรณ์และเครื่องมือที่จำเป็นอย่างไรนั้นขึ้นอยู่กับดุลยพินิจ อาจแตกต่างกันไปตั้งแต่กระดานพลิกธรรมดาไปจนถึงกระดานไวท์บอร์ดอิเล็กทรอนิกส์ อย่างไรก็ตาม การจัดวางห้องต้องส่งเสริมการสื่อสารและการมีปฏิสัมพันธ์ของผู้เข้าร่วม

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

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

• Yatco, Mei C. (1999). "การออกแบบ/พัฒนาแอปพลิเคชันร่วมกัน" . มหาวิทยาลัยมิสซูรี-เซนต์หลุยส์. สืบค้นเมื่อ2009-02-06 .
• Soltys, Roman; Anthony Crawford (1999). "JAD สำหรับแผนธุรกิจและการออกแบบ" . เก็บถาวรจากต้นฉบับเมื่อ 2009-03-13 . สืบค้นเมื่อ2009-02-06 .
• Dennis, Alan R.; Hayes, Glenda S.; Daniels, Robert M. Jr. (ฤดูใบไม้ผลิ 1999). "การสร้างแบบจำลองกระบวนการทางธุรกิจด้วยระบบสนับสนุนกลุ่ม"วารสารระบบสารสนเทศการจัดการ 15 ( 4): 115– 142. doi : 10.1080/07421222.1999.11518224 สืบค้นเมื่อ2015-05-14
• บอตกิน, จอห์น ซี. "การมีส่วนร่วมของลูกค้าในกระบวนการพัฒนาแอปพลิเคชัน" . เก็บถาวรจากต้นฉบับเมื่อ 1 ธันวาคม 1998
• Moeller, Walter E. "การอำนวยความสะดวกในการรวบรวมข้อมูล: เทคนิคทางวิศวกรรมสารสนเทศ" สืบค้นเมื่อ22 มีนาคม 2553
• Bill Jennerich "การออกแบบแอปพลิเคชันร่วมกัน -- การวิเคราะห์ข้อกำหนดทางธุรกิจเพื่อการปรับโครงสร้างใหม่ที่ประสบความสำเร็จ" 18:50, 26 มิถุนายน 2549 (UTC) [2]ไม่ทราบเวลาอัปเดตล่าสุด เข้าถึงเมื่อวันที่ 14 พฤศจิกายน 2542
• Gary Rush "JAD - ประวัติและวิวัฒนาการ -- จดหมายข่าว MGR Consulting" กรกฎาคม 2549 [3]
• Gary Rush, "JAD Project Aids Design", Computerworld, Volume 18 Number 52, หน้า 31 และ 38, 24 ธันวาคม 1984. [4]
• Davidson, EJ (1999). "การออกแบบแอปพลิเคชันร่วม (JAD) ในทางปฏิบัติ". วารสารระบบและซอฟต์แวร์ 45 ( 3). Elsevier BV: 215– 223. doi : 10.1016/s0164-1212(98)10080-8 . ISSN  0164-1212 .
• ก็อตเทสดีเนอร์, เอลเลน; ข้อกำหนดโดยความร่วมมือ: การประชุมเชิงปฏิบัติการเพื่อกำหนดความต้องการ , แอดดิสัน-เวสลีย์, 2002, ISBN 0-201-78606-0.
• วูด, เจน และ ซิลเวอร์, เดนิส; การพัฒนาแอปพลิเคชันร่วมกัน , จอห์น ไวลีย์ แอนด์ ซันส์ อิงค์, ISBN 0-471-04299-4