การสร้างเอกสารการออกแบบซอฟต์แวร์หลังจากการพัฒนานั้นเป็นธรรม

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

สำหรับโครงการนี้ฉันเลือกทำงานกับเอกสารมาตรฐาน IEEE: เอกสารข้อกำหนดซอฟต์แวร์ (SRS), เอกสารสถาปัตยกรรมซอฟต์แวร์ (SAD) และเอกสารออกแบบซอฟต์แวร์ (SDD) แม้ว่าจะสอนเป็นอย่างอื่นในโรงเรียนสำหรับโครงการนี้ฉันเลือกที่จะสร้าง SDD หลังการพัฒนา (แทนที่จะเป็นก่อนหน้านี้) เหตุผลของฉันคือ

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

นี่เป็นเหตุผลที่ดีในการสร้าง SDD หลังจากการพัฒนาหรือไม่? ถ้าไม่จะมีเหตุผลที่ดีสำหรับสิ่งนั้นหรือไม่?

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

ใน IEEE Std 1016 ส่วน 3.1 การออกแบบซอฟต์แวร์ในบริบทคุณสามารถค้นหาย่อหน้านี้:

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

ผู้เขียนมาตรฐาน IEEE Std 1016 ยอมรับว่าอาจไม่มีการสร้าง SDD ล่วงหน้า หนึ่งอาจถูกสร้างขึ้นหลังจากระบบซอฟต์แวร์ที่มีอยู่เพื่อเก็บข้อมูลสำหรับผู้มีส่วนได้เสีย

ส่วนที่ 1.1 ขอบเขตยังให้ข้อมูลที่น่าสนใจ:

มาตรฐานนี้ไม่ได้กำหนดวิธีการเฉพาะสำหรับการออกแบบการจัดการการกำหนดค่าหรือการประกันคุณภาพ

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

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

หากคุณปฏิบัติตามมาตรฐานเช่น IEEE Std 1016 คุณมีข้อกำหนดสำหรับ SDD โดยเฉพาะอย่างยิ่งส่วนที่ 4 ของมาตรฐานนี้จะกำหนดเนื้อหาที่คุณมี ในขณะที่คุณทำงานผ่านการตัดสินใจออกแบบให้เริ่มสร้างมุมมองมุมมองและภาพซ้อนทับที่แตกต่างกัน ในขณะที่คุณตัดสินใจเลือกเหตุผลการออกแบบสำหรับพวกเขา

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

หากสิ่งที่คุณกำลังมองหาจาก SDD คือการสื่อสารการออกแบบกับผู้อื่นใช่คุณสามารถสร้างมันได้หลังจากการพัฒนา สิ่งเดียวคือมันจะเรียกว่าเอกสาร

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

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

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

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

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

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

สำหรับฉันมันจะไม่เป็นข้อโต้แย้งที่ดี

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

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

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

หากมีสิ่งใดเปลี่ยนแปลงในภายหลังคุณอัปเดตเอกสาร

นี่มีข้อดีหลายประการเมื่อเทียบกับการเขียนหลังจากข้อเท็จจริง:

• คุณจะได้เรียนรู้ที่จะปรับปรุงเอกสารการออกแบบเมื่อความต้องการเปลี่ยนแปลงซึ่งเป็นนิสัยที่มีประโยชน์

• คุณจะได้เรียนรู้ที่จะคิดเกี่ยวกับการออกแบบก่อนนำไปใช้

• ไม่น่าเบื่ออย่างน่าเบื่อเหมือนกับการเขียนเอกสารการออกแบบหลังจากความจริงก็คือ

• หากคุณหมดเวลาคุณจะมีเอกสารการออกแบบอธิบายสิ่งที่คุณมีเพื่อให้คนอื่นสามารถทำงานต่อไปได้

• มันไม่ได้ทำงานพิเศษมากนักด้วยวิธีนี้

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

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