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

ดังนั้นฉันแค่สงสัยว่า ... อะไรคือเอกสารด้านเทคนิคและไม่ใช่ด้านเทคนิคที่บังคับที่ฉันสามารถมอบให้กับลูกค้าของฉันนอกเหนือจากรหัสและเอกสารทางสถาปัตยกรรม?

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

ฉันคิดว่ารายการควรมี:

• ข้อกำหนดที่ไม่ใช่ด้านเทคนิค (มีเอกสารดังกล่าวใช่มั้ย)
• ข้อกำหนดทางเทคนิค
• เอกสาร "การตัดสินใจ" (ถ้ามี) อธิบายว่าทำไมการตัดสินใจบางอย่างจึงทำกับคนอื่น สิ่งนี้อาจอยู่ในข้อกำหนดที่แตกต่างกันหรือเอกสารสถาปัตยกรรม แต่เรามักจะทำสิ่งนี้แยกต่างหากสำหรับการตัดสินใจครั้งใหญ่
• รหัสและทรัพยากรอื่น ๆ (ไฟล์รูปภาพ, CSS, ฯลฯ ... )
• โมเดลฐานข้อมูล (เป็นไดอะแกรมเอกสารอะไรก็ได้)
• DDL เพื่อสร้างฐานข้อมูล
• DML เพื่อ seed ฐานข้อมูล
• เอกสารอธิบายการตั้งค่าแอปพลิเคชันและการแก้ไขปัญหาเบื้องต้น
• รายการชื่อผู้ใช้ที่สำคัญและรหัสผ่าน (สำหรับบัญชีผู้ดูแลระบบ) รวมถึงคำแนะนำเกี่ยวกับวิธีการเปลี่ยนรหัสผ่าน โดยหลักแล้วเมื่อพวกเขาตั้งค่าเว็บไซต์เป็นครั้งแรกพวกเขาควรได้รับแจ้งให้ป้อนรหัสผ่านของผู้ดูแลระบบใหม่ แต่นี่เป็นสิ่งที่มากกว่าสถาปัตยกรรม
• ข้อกำหนดของระบบและสำหรับเว็บแอปความต้องการโฮสติ้งขั้นต่ำเช่นกัน (แอพนี้ต้องการ MySQL หรือ PostgreSQL เท่าไหร่ RAM เท่าไหร่ ฯลฯ .. )

สิ่งเหล่านี้อาจไม่พร้อมใช้งาน (หรือจำเป็น) สำหรับทุกโครงการ แต่ฉันคิดว่านี่เป็นแนวทางทั่วไปที่ดี

นอกจากคำตอบที่ดีจริงๆของ FrustratedWithFormsDesigner ฉันต้องการจะบอกว่าเอกสารทางเทคนิคที่ไม่ใช่นั้นมีอะไรบ้าง (เช่นที่เราทำ)

• ข้อมูลการวิเคราะห์: ลูกค้าบอกอะไรคุณเมื่อพูดถึงข้อกำหนดครั้งแรก

• ข้อเสนอที่คุณทำ:

  • เอกสารความต้องการผลิตภัณฑ์
  • และเอกสารข้อกำหนดการทำงาน

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

• ข้อมูลจำเพาะรวมถึงโปรโตคอลตรวจสอบ usecases และ testplans, testresults

• การออกแบบใน UML และเอกสารที่เกี่ยวข้องทั้งหมด

• เอกสารของ sourcecode (doxygen หรืออะไรก็ตาม)

• คู่มือและแนวทางการติดตั้ง

• จำนวนเงินจริงสุดท้ายของทรัพยากร (เวลาและเงิน) ที่ใช้สำหรับโครงการเพื่อให้คุณสามารถเขียนใบแจ้งหนี้

• ลูกค้าบางคนต้องการโปรโตคอลการประชุมเช่นกันซึ่งเป็นส่วนเสริมของ "เอกสารการตัดสินใจ" ที่กล่าวถึงข้างต้น

หวังว่าเป็นสิ่งที่คุณกำลังมองหา

ทำตามเอกสารที่เกี่ยวข้องกับโครงการของคุณจากสิ่งต่อไปนี้คุณอาจมีเอกสารบางส่วนอยู่แล้ว

เอกสารทางเทคนิค:

• รายละเอียดเกี่ยวกับ PHP และข้อมูลเกี่ยวกับประโยชน์ของโครงการ
• รายละเอียดเกี่ยวกับส่วนหลังและข้อมูลเกี่ยวกับประโยชน์ของโครงการ
• ข้อมูลเกี่ยวกับการเชื่อมต่อฐานข้อมูลพร้อมรูปภาพที่เหมาะสมแสดงการไหลของข้อมูล
• ข้อมูลเกี่ยวกับภาษาโปรแกรมอื่น ๆ หรือแอพพลิเคชั่นที่เกี่ยวข้องในโครงการเช่น XML, HTML เป็นต้น
• ไฟล์ช่วยเหลือ FAQ

เตรียมเอกสารด้วยภาพหน้าจอและเน้นรหัสที่เกี่ยวข้อง (ถ้าจำเป็น) สำหรับสิ่งต่อไปนี้:

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

• ป้อนข้อมูลที่ไม่ถูกต้องและแสดงว่าเป็นไปไม่ได้ที่จะทำเช่นนั้นเนื่องจากคุณได้ทำการตรวจสอบความถูกต้องของข้อมูลที่ส่วนหน้าและส่วนหลัง
  /* This step is not applicable if you have not used any object for getting direct input from the user like Text Field as it is obvious that you cannot get invalid data through indirect input. */

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

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

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

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

  
  เอกสารที่ไม่ใช่ด้านเทคนิค:

• รายละเอียดใบอนุญาตของโครงการหากมี
• แง่มุมเชิงพาณิชย์ของโครงการถ้ามี

ระวังตัวด้วย

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

ทำไมลูกค้าถึงต้องการเอกสารนี้ (รหัสแหล่งที่มาด้านบน) จะทำอย่างไรกับมัน? สำหรับใคร

คำตอบสำหรับคำถามเหล่านี้จะช่วย จำกัด ขอบเขตของสิ่งที่จะส่งมอบ

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

อย่าเล่นเกมทายผล เอกสารทางเทคนิคส่วนใหญ่จะไร้ประโยชน์กับลูกค้าทั่วไป (ที่ไม่ใช่ด้านเทคนิค)

ฉันอาจแบ่งเอกสารออกเป็นสองสามหมวดหมู่:

คำแนะนำ:

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

สนับสนุน:

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

จุดรวม:

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