ข้อกำหนดต่างๆถูกกำหนดไว้ในโครงการซอฟต์แวร์โอเพ่นซอร์สหรือไม่


11

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

โดย "การกำหนดความต้องการ" ฉันหมายถึง "การหาว่าคุณสมบัติอื่น ๆ ควรได้รับการพัฒนาเป็นส่วนหนึ่งของซอฟต์แวร์เฉพาะ" หรือไม่


12
ฉันคิดว่ามันแสดงให้เห็นว่าโครงการโอเพ่นซอร์สมากมายได้รับการพัฒนาโดยองค์กร (บริษัท และสถาบันการศึกษา) มากกว่ากลุ่มผู้มีส่วนร่วมที่หลวม และเป็นเช่นนั้นอาจมีฟังก์ชั่น PM / ความต้องการอย่างเป็นทางการ
MaximR

นี่เป็นส่วนสำคัญของวิทยานิพนธ์ที่รอการอนุมัติของฉัน ขอบคุณสำหรับการถาม!
R Claven

คำตอบ:


8

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

หากโครงการของคุณมีผู้ใช้ 100 คนคุณอาจพัฒนารหัสที่สนุกที่สุด

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

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


7

ฉันติดตามโอเพ่นซอร์สมาตั้งแต่ครั้งแรกที่ฉันได้ยินเกี่ยวกับ linux ในปี 1995 และฉันจำไม่ได้ว่าเคยได้ยินคำว่า 'ข้อกำหนด' ที่ใช้ในบริบทนั้น

Eric Raymond มีเรียงความที่ดีThe Cathedral และ Bazaarซึ่งเขาพูดถึง 'เกาของคุณเอง' หากคุณกำลังพยายามที่จะแก้ไขปัญหาที่คุณเผชิญอยู่เป็นการส่วนตัวคุณไม่จำเป็นต้องอ้างถึงเอกสารข้อกำหนดเพื่อหาว่าคุณได้แก้ไขแล้วหรือยัง

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


6

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

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

  • การสื่อสารนอกระบบ

  • รายการข้อกำหนด / ข้อบกพร่อง / ปัญหา / ตั๋วที่ได้รับการจัดลำดับความสำคัญ (และนั่นไม่ใช่การประดิษฐ์จากชุมชน "ว่องไว")

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


5

หากปัญหาเป็นปัญหาทั่วไปเช่นการพูดการเขียนคอมไพเลอร์หรือเบราว์เซอร์ความต้องการนั้นได้รับการกำหนดในรูปแบบของมาตรฐานภาษาระบบปฏิบัติการเป้าหมายและฮาร์ดแวร์เป้าหมายเป็นต้น

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

หากซอฟต์แวร์กำลังติดตามฟังก์ชั่นที่มีเฉพาะในซอฟต์แวร์โอเพนซอร์ซเท่านั้นความต้องการจะได้รับอีกครั้ง

แก้ไข:

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

ในโครงการวิจัยอย่างเต็มรูปแบบเช่น GNU Hurd ฉันคิดว่าข้อกำหนดมาจากผลการวิจัยและเอกสาร

เพื่อสรุป

  • เมื่อเริ่มต้นข้อกำหนดของซอฟต์แวร์ที่พยายามแก้ไขปัญหาทั่วไปอาจมาจากเอกสารมาตรฐาน

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

  • สำหรับโครงการวิจัยเอกสารและสิ่งพิมพ์อื่น ๆ สามารถกำหนดข้อกำหนดได้

  • เมื่ออยู่ในการบำรุงรักษาข้อบกพร่องจำเป็นต้องปรับตัวเข้ากับสภาพแวดล้อมที่ใหม่กว่าสามารถเป็นแหล่งสำคัญสำหรับความต้องการ


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

4

ฉันไม่ทราบแน่ชัด แต่เมื่อมีข้อเสนอแนะคือใช้วิธีการแบบ Agile ซึ่งมีการยกระดับความต้องการเป็นตั๋ว (หรือ "บัตร") โดยใช้ JIRA ด้วยตั๋วแต่ละใบที่แสดงคุณสมบัติหรือข้อกำหนด ตั๋วแต่ละใบสามารถแยกย่อยเป็นตั๋วอื่น ๆ ที่แสดงถึงหน่วยงานขนาดเล็ก

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.