วิธีเขียนงานด้านเทคนิคสำหรับการพัฒนาแอปพลิเคชัน เราเขียนงานด้านเทคนิค

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

มาตรฐานเป็นไปตาม ST SEV 1627-79 อย่างสมบูรณ์

กฎการออกแบบ

งานด้านเทคนิควาดขึ้นตาม GOST 19.106-78 บนแผ่นงานรูปแบบ 11 และ 12 ตามกฎ GOST 2.301-68 โดยไม่ต้องกรอกข้อมูลในฟิลด์ของแผ่นงาน จำนวนแผ่นงาน (หน้า) จะใส่ลงในส่วนบนของแผ่นงานเหนือข้อความ

ใบอนุมัติและหน้าชื่อเรื่อง

แผ่นอนุมัติและหน้าชื่อเรื่องจัดทำขึ้นตาม GOST 19.104-78

ส่วนที่ให้ข้อมูล (บทคัดย่อและเนื้อหา) ใบลงทะเบียนการเปลี่ยนแปลงอาจไม่รวมอยู่ในเอกสาร

การเปลี่ยนแปลงและเพิ่มเติม

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

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

องค์ประกอบของส่วนต่างๆ ของข้อกำหนดในการอ้างอิง

ข้อกำหนดในการอ้างอิงควรมีส่วนต่อไปนี้:

การแนะนำ;

เหตุผลในการพัฒนา

วัตถุประสงค์ของการพัฒนา

ข้อกำหนดสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์

ข้อกำหนดสำหรับเอกสารซอฟต์แวร์

ตัวชี้วัดทางเทคนิคและเศรษฐกิจ

ขั้นตอนและขั้นตอนของการพัฒนา

ขั้นตอนการควบคุมและการยอมรับ

อนุญาตให้รวมแอปพลิเคชันในเงื่อนไขการอ้างอิง

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

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

การแนะนำ

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

กฎพื้นฐานสำหรับการทำงานกับข้อความคือการลงรายละเอียด การแยกข้อความออกเป็นหน่วยโครงสร้าง ส่วนย่อย ย่อหน้า และย่อหน้าย่อย สารบัญของข้อความจะมีโครงสร้างที่ชัดเจนทำให้ง่ายต่อการค้นหาเนื้อหาที่ต้องการ ข้อความของเอกสารจะมีโครงสร้างและอ่านง่าย สร้างส่วนย่อย:

ชื่อโปรแกรม

ชื่อ - "ตัวแก้ไขข้อความสำหรับการทำงานกับไฟล์ rtf"

คำอธิบายสั้น ๆ ของขอบเขต

โปรแกรมนี้มีไว้สำหรับใช้ในแผนกพิเศษที่สถานที่ของลูกค้า

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

เหตุผลในการพัฒนา

ส่วนนี้ควรรวมถึง:

เอกสาร (เอกสาร) บนพื้นฐานของการพัฒนาที่ดำเนินการ

องค์กรที่อนุมัติเอกสารนี้และวันที่อนุมัติ

ชื่อ และ (หรือ) เครื่องหมายหัวข้อการพัฒนา

ส่วนย่อยควรมีข้อมูลที่อยู่ในข้อตกลง

พื้นฐานสำหรับการพัฒนา

พื้นฐานสำหรับการพัฒนาคือข้อตกลง (จดหมาย ฯลฯ ) หมายเลข 666 ลงวันที่ 15 มีนาคม 2547 (หมายเลขรับเข้าดังกล่าวและดังกล่าวจากดังกล่าวและดังกล่าว) สัญญาตกลงกับผู้อำนวยการของ State Unitary Enterprise "Spetstyazhmontazhstroyselkhozavtomatika" Ivanov Petr Ivanovich ซึ่งต่อไปนี้จะเรียกว่าลูกค้า และได้รับอนุมัติจากผู้อำนวยการทั่วไปของ OAO Supersoft Blyumkins Ivan Aronovich ซึ่งต่อไปนี้จะเรียกว่าผู้รับเหมาในเดือนมีนาคม 2551 ดังกล่าว

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

ครามสคอย โรมัน IT-09-2

หมายเลขห้องปฏิบัติการ3

การกำหนดข้อกำหนดสำหรับระบบซอฟต์แวร์อย่างเป็นทางการโดยใช้ Use Case Diagram

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

ความก้าวหน้าของงาน

ศึกษาข้อมูลเชิงทฤษฎี

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

พัฒนาแผนภาพกรณีการใช้งานและกรอกคำอธิบายกรณีการใช้งาน

วางแผนการทำงานสำหรับการสร้างผลิตภัณฑ์ซอฟต์แวร์

พัฒนาข้อกำหนดในการอ้างอิงสำหรับการสร้างผลิตภัณฑ์ซอฟต์แวร์

หาข้อสรุปเกี่ยวกับการเลือกแบบจำลองสำหรับการสร้างผลิตภัณฑ์ซอฟต์แวร์

ข้อกำหนดสำหรับเนื้อหาของงาน

1. ชื่องาน.

   เป้าหมายของงาน.

   การกำหนดงานแต่ละอย่าง

   แผนผังกรณีการใช้งานพร้อมคำอธิบาย (ให้ความสนใจเป็นพิเศษกับความสมบูรณ์ของคำอธิบายกรณีการใช้งานและบทบาทของผู้ใช้ระบบซอฟต์แวร์)

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

   ข้อสรุปเกี่ยวกับการเลือกแบบจำลองสำหรับการสร้างผลิตภัณฑ์ซอฟต์แวร์

งานด้านเทคนิคเพื่อการพัฒนา“พี.เอ็ม.ซีกระบบอัตโนมัติของการประมวลผลและการประมาณข้อมูลการทดลอง»

เหตุผลในการพัฒนา

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

ตอนพิเศษ: การพัฒนาซอฟต์แวร์สำหรับการจดจำเส้นแบ่งและการประมาณ

วัตถุประสงค์ของการพัฒนา

ชุดซอฟต์แวร์ได้รับการออกแบบสำหรับการประมวลผลและการประมาณข้อมูลการทดลอง และต้องทำหน้าที่ต่อไปนี้:

จดจำภาพ

ทำการปรับภาพให้เรียบ

เลือกโหนดการหาร

ข้อกำหนดของผลิตภัณฑ์ซอฟต์แวร์

เมื่อปรับใช้และใช้ระบบสารสนเทศ ควรคำนึงถึงข้อกำหนดสำหรับลักษณะการทำงาน ความน่าเชื่อถือของโครงการ พารามิเตอร์ของฮาร์ดแวร์ ข้อมูลและความเข้ากันได้ของซอฟต์แวร์

ต้องการประสิทธิภาพการทำงาน

ชุดซอฟต์แวร์ต้องทำหน้าที่ดังต่อไปนี้:

การจดจำภาพ (ความละเอียดไม่น้อยกว่า 600×300 DPI)

การเลือกโหนดหาร (ไม่เกิน 1,000 โหนด) ;

การคำนวณพิกัดของโหนดหาร (ด้วยความแม่นยำ 0.01 มม.)

การก่อตัวของอาร์เรย์ข้อมูล (ไม่เกิน 30 วินาที)

การปรับภาพให้เรียบ (2 วิธีขึ้นไปสำหรับการประมาณขึ้นอยู่กับส่วนโค้งหรือพื้นผิว)

บันทึกผลลัพธ์ (มากกว่า 3 รูปแบบ)

ข้อกำหนดด้านความน่าเชื่อถือ

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

ผลิตภัณฑ์ซอฟต์แวร์ต้องมีการควบคุมข้อมูลอินพุตและเอาต์พุตเพื่อให้สอดคล้องกับรูปแบบข้อมูลที่ระบุ

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

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

ควรสำรองตารางเพื่อให้สามารถกู้คืนได้หากจำเป็น

ข้อกำหนดการใช้งาน

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

ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค

ข้อกำหนดขั้นต่ำสำหรับซอฟต์แวร์และฮาร์ดแวร์สำหรับการทำงานปกติของแอปพลิเคชัน:

หน่วยประมวลผล: AMD หรือ Intel ที่มีความถี่ 1 GHz หรือสูงกว่า

RAM: 256 Mb ขึ้นไป;

ระบบปฏิบัติการ: Windows XP ขึ้นไป;

จอภาพ: จอภาพ SVGA;

ความจุ HDD: พื้นที่ว่างไม่น้อยกว่า 500 Mb;

ข้อกำหนดอื่นๆ: การ์ดเครือข่าย แป้นพิมพ์ เมาส์

ข้อกำหนดสำหรับข้อมูลและความเข้ากันได้ของซอฟต์แวร์

ระบบซอฟต์แวร์ทำงานภายใต้ Windows XP ขึ้นไป ผลิตภัณฑ์ซอฟต์แวร์สร้างขึ้นโดยใช้เครื่องมือพัฒนาแอปพลิเคชัน Sharp C

ข้อกำหนดโปรแกรมเอกสาร

องค์ประกอบเบื้องต้นของเอกสารโปรแกรมถูกกำหนดตาม GOST 19.101-77 ด้านล่างนี้เป็นรายการเอกสารโปรแกรมและเนื้อหา

ข้อความของโปรแกรมเป็นบันทึกของโปรแกรมพร้อมคำอธิบายและความคิดเห็นที่จำเป็น

คำอธิบายของโปรแกรม - ข้อมูลเกี่ยวกับโครงสร้างเชิงตรรกะและการทำงานของโปรแกรม

โปรแกรมทดสอบและวิธีการเป็นข้อกำหนดที่ต้องตรวจสอบเมื่อทำการทดสอบโปรแกรม ตลอดจนขั้นตอนและวิธีการควบคุม

ข้อกำหนดในการอ้างอิง - เอกสารนี้

หมายเหตุอธิบาย - โครงร่างของอัลกอริทึมคำอธิบายทั่วไปของอัลกอริทึมหรือการทำงานของโปรแกรมรวมถึงเหตุผลสำหรับการแก้ปัญหาทางเทคนิคและทางเทคนิคและเศรษฐกิจ

เอกสารการปฏิบัติงาน - คำอธิบายของแอปพลิเคชัน คู่มือผู้ใช้

ขั้นตอนและขั้นตอนของการพัฒนา

การพัฒนาดำเนินการในหลายขั้นตอนตาม GOST 19.101-77 และรวมถึงขั้นตอนที่แสดงในตาราง 1.5

ตาราง - ขั้นตอนการพัฒนา

	วันกำหนดส่ง
	งานด้านเทคนิค	การวิเคราะห์และกำหนดข้อกำหนดของซอฟต์แวร์อย่างเป็นทางการ การวางแผนงาน
	การออกแบบเบื้องต้น	การออกแบบซอฟต์แวร์ การออกแบบล่วงหน้าโดยใช้ UML: Use-Case Diagrams, Class Diagrams และ Sequence Diagrams
	โครงการทางเทคนิค	การใช้งานซอฟต์แวร์เวอร์ชันที่ใช้งานได้พร้อมฟังก์ชันหลัก การทดสอบ
	ร่างการทำงาน	การแก้ไขและเสร็จสิ้นซอฟต์แวร์ การพัฒนาเอกสาร
	การดำเนินการ	การพัฒนามาตรการสำหรับการใช้งานและการบำรุงรักษาซอฟต์แวร์

ขั้นตอนการควบคุมและการยอมรับ

PMC สำหรับการทำงานอัตโนมัติของการประมวลผลและข้อมูลการทดลองโดยประมาณต้องเป็นไปตามข้อกำหนดของลูกค้าและเป็นไปตามข้อกำหนดด้านการทำงานที่ตั้งไว้ทั้งหมด

การควบคุมผลิตภัณฑ์ซอฟต์แวร์ดำเนินการตามลำดับต่อไปนี้

– ตรวจสอบการทำงานของซอฟต์แวร์ที่พัฒนาขึ้น

– ตรวจสอบปฏิกิริยาของโปรแกรมต่อการกระทำของผู้ใช้ต่างๆ

– การตรวจสอบข้อมูลเอาต์พุต

– หลังจากออกจากโปรแกรม ระบบปฏิบัติการควรทำงานต่อไปอย่างถูกต้อง

การยอมรับระบบที่สร้างขึ้นประกอบด้วยการทดสอบในที่ทำงานหลังจากตั้งค่าผลิตภัณฑ์ซอฟต์แวร์

เรามักจะได้ยินเกี่ยวกับงานด้านเทคนิค ความสำคัญ และการรวบรวมที่ถูกต้อง เงื่อนไขการอ้างอิงสำหรับการสร้างไซต์, เงื่อนไขการอ้างอิงสำหรับโครงการออกแบบ, เงื่อนไขการอ้างอิงสำหรับการพัฒนาซอฟต์แวร์, เงื่อนไขการอ้างอิงสำหรับสิ่งนี้, เงื่อนไขการอ้างอิงสำหรับสิ่งนี้ ... มันสำคัญจริง ๆ หรือไม่, เงื่อนไขการอ้างอิง, คุ้นเคยเรียกว่า TK? แล้วมาหาคำตอบกัน!

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

ทำไมต้องเป็นงานด้านเทคนิค?

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

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

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

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

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

อันที่จริงแล้วคำตอบสำหรับคำถามที่ว่าทำไมจึงจำเป็นต้องร่างงานด้านเทคนิคที่มีความสามารถสำหรับการพัฒนาโปรแกรมนั้นชัดเจน ไปข้างหน้า

สเปคใครบ้าง?

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

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

โดยทั่วไป เงื่อนไขการอ้างอิงมีเป้าหมายหลายประการ และแม้ว่าอาจมีการกล่าวถึงสิ่งนี้ในตอนต้น แต่ก็ไม่สายเกินไปที่จะแก้ไขการละเว้น ดังนั้นเป้าหมาย:

• องค์กร
• ข้อมูล
• การสื่อสาร
• อำนาจศาล.

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

องค์ประกอบข้อมูลของ TOR ควรครบถ้วนแต่กระชับ

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

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

ใส่เพียงแค่:

• ลูกค้าเขาคือลูกค้า
• ผู้จัดการโครงการ
• ผู้ดำเนินการโครงการ พวกเขาหรือเขา: โปรแกรมเมอร์
• ผู้เข้าร่วมอื่น ๆ ที่เป็นไปได้ที่มีความคิดเห็น: ทำอย่างไร ทำอย่างไรให้ดีขึ้น และควรจบอย่างไร

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

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

จะเขียนงานด้านเทคนิคได้อย่างไร?

เมื่อเชื่อมั่นในความจำเป็นและแม้แต่ความไร้ค่าของเงื่อนไขอ้างอิงในการพัฒนาโปรแกรม เราสามารถดำเนินการสนทนาต่อไปได้ ตอนนี้เรามาถึงคำถามที่จริงจังที่สุดแล้ว: จะจัดทำ TOR อย่างไรให้มีประสิทธิภาพ ชัดเจน รัดกุม แต่เฉพาะเจาะจง! และเราไม่ต้องการอะไรอีก

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

การพัฒนาโปรแกรมและการจัดทำข้อกำหนดการอ้างอิงในพื้นที่นี้ควบคุมโดย GOST 19.201-78 ระบบหนึ่งเอกสารประกอบซอฟต์แวร์ งานด้านเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ

นอกจากนี้ คำแนะนำอีกสองข้อจะไม่ฟุ่มเฟือย:

• GOST 2.114-95 ระบบแบบครบวงจรสำหรับเอกสารการออกแบบ ข้อมูลจำเพาะ;
• GOST 34.602-89 เทคโนโลยีสารสนเทศ กำหนดมาตรฐานสำหรับระบบอัตโนมัติ เงื่อนไขการอ้างอิงสำหรับการสร้าง ระบบอัตโนมัติ. แน่นอนว่าทรินิตี้นี้ถือได้ว่าเป็น "สิ่งศักดิ์สิทธิ์" ในการพัฒนาและจัดทำข้อกำหนดทางเทคนิคสำหรับเกือบทุกสาขาวิชา แน่นอนว่ามีมาตรฐานอื่น ๆ ที่สามารถและควรปฏิบัติตาม แต่อย่าลืมว่า "จำเป็นและเพียงพอ"

เราจบอะไรมา?

คำตอบ: โครงสร้างทั่วไปของข้อกำหนดในการอ้างอิง รวมถึงการพัฒนาโปรแกรม

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

ส่วนที่สองของ GOST 19.201-78 ที่ระบุซึ่งกำหนดเนื้อหาของส่วนต่าง ๆ จะช่วยในการร่างเงื่อนไขการอ้างอิงสำหรับการพัฒนาโปรแกรมโดยละเอียดยิ่งขึ้น

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

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

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

นอกจากนี้ยังสามารถเปลี่ยนแปลงรายการข้อกำหนดสำหรับการพัฒนาโปรแกรม: เสริมหรือลดขึ้นอยู่กับเงื่อนไขเฉพาะของโครงการ

ใครเป็นผู้ร่างเงื่อนไขการอ้างอิง

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

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

1. การตั้งค่างานของโครงการ
2. การก่อตัวและการกำหนดข้อกำหนดสำหรับการดำเนินการทางเทคนิค
3. การกำหนดข้อกำหนดสำหรับโปรแกรมที่พัฒนาขึ้น
4. การประสานงานของขั้นตอน ระยะเวลา และการเตรียมเอกสาร
5. การระบุภาษาและรหัสโปรแกรม
6. การร่าง การปรับปรุง และการอนุมัติข้อกำหนดทางเทคนิคโดยลูกค้า

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

ปาร์ตี้เหล่านี้ต้องได้รับคำแนะนำจาก GOST 19.201-78 ซึ่งไม่มากก็น้อย แต่มีอายุเกือบ 30 ปี

กระทู้ที่เกี่ยวข้อง

แนวคิดของ "วิศวกรรมย้อนกลับ" เป็นการกำหนดที่ทันสมัยของแนวคิดเดิม - การคัดลอก การปรับปรุง ... ด้วยการพัฒนาเทคโนโลยีคอมพิวเตอร์ ...

โดยเนื้อแท้แล้วด้วย เทคโนโลยีสารสนเทศมนุษยชาติได้เผชิญและเผชิญกับทุกย่างก้าวของชีวิต แค่…

แนวคิดของการรื้อปรับระบบเกิดขึ้นในยุค 90 เพื่อตอบสนองต่อปัญหาที่เกิดขึ้นระหว่างระบบอัตโนมัติจำนวนมาก ...

กระทรวงวิทยาศาสตร์และการศึกษา

สหพันธรัฐรัสเซีย

SEI HPE "มหาวิทยาลัยแห่งรัฐ ADYGE"

คณะฟิสิกส์

หน่วยงาน อ.ส.ม.ท

ข้อกำหนดในการอ้างอิงสำหรับการสร้างซอฟต์แวร์

ผลิตภัณฑ์

การแนะนำ…………………………………………………………………………. ... 3

1. พื้นฐานการพัฒนา……………………………………….. ......4

1.1. เอกสารบนพื้นฐานของการพัฒนาที่ดำเนินการ……………………....4

1.2. องค์กรที่อนุมัติพื้นฐานสำหรับการพัฒนา และวันที่อนุมัติ4

1.3. ชื่อหัวข้อการพัฒนา…………....………………………………….4

2. วัตถุประสงค์ของการพัฒนา………………....…………………………………..5

2.1 เกณฑ์ประสิทธิภาพและคุณภาพของโปรแกรม……....………………………..5

5

3. ข้อกำหนดสำหรับโปรแกรม…………………………....…………………...6

3.1 ข้อกำหนดด้านประสิทธิภาพ………....………………….6

3.1.1 องค์ประกอบของฟังก์ชันที่ดำเนินการ………………………….....……………….6

3.1.2 การจัดระเบียบข้อมูลเข้าและออก…………………………....…………….6

3.1.3 ลักษณะเวลาและขนาดหน่วยความจำ…………………………6

3.2 ข้อกำหนดด้านความน่าเชื่อถือ………………………………………………....……….…6

3.2.1 ข้อกำหนดสำหรับการทำงานที่เชื่อถือได้……………………....………6

3.2.2 การควบคุมข้อมูลเข้าและออก………………………….....…..7

3.2.3 เวลากู้คืนหลังจากล้มเหลว…………………………………….......….7

3.3 สภาพการใช้งาน………………………………………7

3.4 ข้อกำหนดสำหรับองค์ประกอบและพารามิเตอร์ของวิธีการทางเทคนิค…………………...7

3.5 ข้อกำหนดสำหรับภาษาโปรแกรม…………………………………….......8

3.6 ข้อกำหนดสำหรับซอฟต์แวร์ที่ใช้โดยโปรแกรม……......8

3.7 ข้อกำหนดสำหรับเอกสารซอฟต์แวร์……………………………………..... 8

4. ตัวบ่งชี้ทางเทคนิคและเศรษฐกิจ………………………… ..... 9

5. ขั้นตอนและขั้นตอนของการพัฒนา……………………………………….........9

6. วิธีการควบคุมและยอมรับ……………………………………….........9

6.1 ประเภทของการทดสอบ…………………………………………………………………….......9

6.2 ข้อกำหนดทั่วไปสู่การยอมรับ……………………………………………….....10

7. ขั้นตอนการดำเนินการ…………………………......10

การแนะนำ

ชื่อเต็มของการพัฒนาซอฟต์แวร์: "โปรแกรม K" ซึ่งต่อไปนี้จะเรียกว่า "โปรแกรม" ชื่อย่อของโปรแกรมคือ "พีซี"

ในขณะนี้ไม่มีผลิตภัณฑ์ซอฟต์แวร์ที่คล้ายคลึงกัน

โปรแกรมที่พัฒนาขึ้นถูกนำไปใช้กับองค์กรใด ๆ ที่มีพนักงานทำงานอยู่

ผู้พัฒนาผลิตภัณฑ์ซอฟต์แวร์นี้เป็นนักเรียนของกลุ่ม 4A1 Ivanov A.V. ซึ่งต่อไปนี้จะเรียกว่า "ผู้พัฒนา"

ลูกค้าของผลิตภัณฑ์ซอฟต์แวร์คือ OJSC RTS ซึ่งเป็นตัวแทนโดยผู้อำนวยการ A.M. กูเตนโก.

1 พื้นฐานสำหรับการพัฒนา

1.1 เอกสารบนพื้นฐานของการพัฒนาที่ดำเนินการ

งานจะดำเนินการบนพื้นฐานของงานในระเบียบวินัย " พื้นฐานทางทฤษฎี การควบคุมอัตโนมัติ»

1.2 องค์กรที่อนุมัติและวันที่อนุมัติเอกสารนี้

การมอบหมายได้รับการอนุมัติและออกโดย A.V. Kozakov หัวหน้าฝ่ายเทคนิคของ RTS OJSC

Kozakov A.V.

1.3 ชื่อหัวข้อการพัฒนา

ชื่อหัวข้อการพัฒนาคือ “การบัญชี เวลาทำงาน”

2 วัตถุประสงค์ของการพัฒนา

การพัฒนานี้เป็นภาคการศึกษาเกี่ยวกับระเบียบวินัย "รากฐานทางทฤษฎีของการควบคุมอัตโนมัติ"

2.1 เกณฑ์สำหรับประสิทธิภาพและคุณภาพของโปรแกรม

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

การปฏิบัติตามสถานะปัจจุบันของตลาดซอฟต์แวร์ของโปรไฟล์นี้แตกต่างจากโปรแกรมราคาแพงและซับซ้อน พีซีเหมาะสำหรับตัวแทนธุรกิจ เนื่องจากมีทุกสิ่งที่ต้องการ แต่ก็ไม่ได้ใช้งานมากเกินไปด้วยคุณสมบัติที่ไร้ประโยชน์และไม่จำเป็น เทคโนโลยีในการสร้างโปรแกรมในสภาพแวดล้อมการเขียนโปรแกรมด้วยภาพทำให้อินเทอร์เฟซเป็นสากลและเข้ากันได้กับ ระบบปฏิบัติการวินโดว์ 95/98/2000/XP.

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

2.2 เป้าหมายของการออกแบบโปรแกรม

การสร้างโปรแกรมนี้เป็นไปตามเป้าหมายทางเทคนิคและเศรษฐกิจหลายประการ:

การสร้างผลิตภัณฑ์ซอฟต์แวร์ที่จำเป็นสำหรับการบันทึกชั่วโมงทำงาน

การสร้างทางเลือกราคาถูกแทนโปรแกรมราคาแพงที่มีอยู่ในปัจจุบัน

สร้างโปรแกรมที่ใช้งานง่ายด้วย Windows ที่สะดวกและหลากหลาย