ข้อกำหนดในการอ้างอิง (TOR) - เอกสารต้นฉบับซึ่งเป็นพื้นฐานสำหรับการพัฒนาและทดสอบโปรแกรมหรือ ระบบอัตโนมัติ. ข้อกำหนดในการอ้างอิงสำหรับโปรแกรมและซอฟต์แวร์ได้รับการพัฒนาตามข้อกำหนด พื้นฐานสำหรับการพัฒนา TK ส่วนใหญ่เป็นสัญญา
TOR สำหรับโปรแกรมได้รับการพัฒนา ก่อนอื่น สำหรับคนที่จะพัฒนาผลิตภัณฑ์ซอฟต์แวร์ในภายหลัง เช่นเดียวกับ TOR อื่นๆ สำหรับโปรแกรม ควรมีความชัดเจนอย่างยิ่งและไม่มีถ้อยคำที่คลุมเครือ และควรอธิบายข้อกำหนดและความปรารถนาทั้งหมดของลูกค้าให้ครบถ้วนที่สุดสำหรับโปรแกรมที่จัดทำขึ้น แต่อย่าลืมว่าโปรแกรมเมอร์เป็นคนที่มีความคิดสร้างสรรค์ ไม่ใช่เรื่องง่ายเสมอไปสำหรับพวกเขาที่จะเชี่ยวชาญข้อความทางเทคนิค 150 แผ่น ภายใต้อำนาจ
ผู้ที่มอบหมายให้เขียนข้อกำหนดทางเทคนิคสำหรับโปรแกรม
ฉันต้องการเน้นที่ข้อผิดพลาดทั่วไป - เพื่อมอบหมายงานด้านเทคนิคสำหรับผลิตภัณฑ์ซอฟต์แวร์ให้กับโปรแกรมเมอร์โดยอ้างว่าโปรแกรมเมอร์จะใช้งานด้านเทคนิคของตนเองได้ง่ายขึ้นในภายหลัง
ข้อกำหนดในการอ้างอิงสำหรับโปรแกรมควรได้รับการพัฒนาโดยนักเขียนด้านเทคนิค! ประการแรก นอกเหนือจากความรู้เกี่ยวกับ GOST 19.201-78 แล้ว ความรู้เกี่ยวกับมาตรฐานอื่นๆ ก็จำเป็นเช่นกัน (เช่น GOST 19.106-78, GOST 19.104 - 78 เป็นต้น) โปรแกรมเมอร์จำนวนไม่มากที่รู้จัก GOST เหล่านี้ และแม้แต่น้อยก็จะเห็นด้วย ศึกษาพวกเขา ประการที่สอง จำเป็นต้องมีความรู้และประสบการณ์ในภาษาเขียนทางเทคนิค (เพื่อไม่ให้สับสนกับการเขียนโค้ดซอฟต์แวร์) ประการที่สาม เฉพาะทีมงานที่ทำงานร่วมกัน (นักเขียนด้านเทคนิค โปรแกรมเมอร์ ผู้จัดการโครงการ) เท่านั้นที่จะสามารถพัฒนาให้สมบูรณ์ได้ งานด้านเทคนิคสำหรับโปรแกรมและซอฟต์แวร์
โครงสร้างของเงื่อนไขการอ้างอิง
กระทรวงวิทยาศาสตร์และการศึกษา
สหพันธรัฐรัสเซีย
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" ซึ่งต่อไปนี้จะเรียกว่า "โปรแกรม" ชื่อย่อของโปรแกรมคือ "PC"
ในขณะนี้ไม่มีผลิตภัณฑ์ซอฟต์แวร์ที่คล้ายคลึงกัน
โปรแกรมที่พัฒนาขึ้นนี้ใช้กับองค์กรใด ๆ ที่มีพนักงานทำงานอยู่
ผู้พัฒนาผลิตภัณฑ์ซอฟต์แวร์นี้เป็นนักเรียนของกลุ่ม 4A1 Ivanov A.V. ซึ่งต่อไปนี้จะเรียกว่า "ผู้พัฒนา"
ลูกค้าของผลิตภัณฑ์ซอฟต์แวร์คือ OJSC RTS ซึ่งแสดงโดยผู้อำนวยการ A.M. กูเทนโก
1 พื้นฐานสำหรับการพัฒนา
1.1 เอกสารบนพื้นฐานของการพัฒนา
งานจะดำเนินการบนพื้นฐานของงานในวินัย " พื้นฐานทางทฤษฎี ระบบควบคุมอัตโนมัติ»
1.2 การอนุมัติองค์กรและวันที่อนุมัติเอกสารนี้
งานนี้ได้รับการอนุมัติและออกโดย A.V. Kozakov หัวหน้าแผนกเทคนิคของ RTS OJSC
โคซาคอฟ เอ.วี.
1.3 ชื่อหัวข้อการพัฒนา
ชื่อหัวข้อการพัฒนาคือ “การบัญชีสำหรับเวลาทำงาน”
2 วัตถุประสงค์ของการพัฒนา
การพัฒนานี้เป็นงานภาคการศึกษาในสาขาวิชา "พื้นฐานทางทฤษฎีของการควบคุมอัตโนมัติ"
2.1 เกณฑ์ประสิทธิภาพและคุณภาพของโปรแกรม
ปัจจัยทางสังคมการพัฒนาซอฟต์แวร์นี้เรียนรู้ได้ง่ายมาก และไม่ได้ออกแบบมาสำหรับมืออาชีพเท่านั้น แต่ยังสำหรับผู้ใช้ทั่วไปที่ทำงานใน Windows ด้วย อินเทอร์เฟซที่สะดวกและใช้งานง่าย รวมกับระบบรูปภาพเสริมและคำแนะนำเครื่องมืออันทรงพลัง ช่วยให้คุณทำงานกับโปรแกรมได้โดยไม่ต้องเตรียมการล่วงหน้า
การปฏิบัติตามสถานะปัจจุบันของตลาดซอฟต์แวร์ของโปรไฟล์นี้พีซีไม่เหมือนกับโปรแกรมราคาแพงและซับซ้อน พีซีเหมาะอย่างยิ่งสำหรับตัวแทนธุรกิจ เนื่องจากมีทุกสิ่งที่ต้องการ แต่ไม่มีฟีเจอร์ที่ไร้ประโยชน์และไม่จำเป็นมากเกินไป เทคโนโลยีการสร้างโปรแกรมในสภาพแวดล้อมการเขียนโปรแกรมด้วยภาพทำให้อินเทอร์เฟซเป็นสากลและเข้ากันได้กับ ระบบปฏิบัติการวินโดว์ 95/98/2000/XP
กองกำลังทางเศรษฐกิจโปรแกรมนี้แสดงถึงอัตราส่วนราคาและคุณสมบัติที่ดีที่สุดและจะนำช่องเฉพาะในตลาดของโปรแกรมราคาถูกมาใช้อย่างไม่ต้องสงสัย ผู้ใช้หลักจะเป็นตัวแทนของธุรกิจที่ไม่สามารถชำระค่าโปรแกรมราคาแพงจาก 1C และอื่น ๆ ได้
2.2 เป้าหมายของการออกแบบโปรแกรม
การสร้างโปรแกรมนี้มีเป้าหมายทางเทคนิคและเศรษฐกิจหลายประการ:
การสร้างผลิตภัณฑ์ซอฟต์แวร์ที่จำเป็นสำหรับการบันทึกเวลาทำงาน
การสร้างทางเลือกราคาถูกแทนโปรแกรมราคาแพงที่มีอยู่ในปัจจุบัน
สร้างโปรแกรมที่ใช้งานง่ายด้วย Windows ที่สะดวกและใช้งานได้หลากหลาย
เราได้ยินเกี่ยวกับงานด้านเทคนิค ความสำคัญ และการรวบรวมที่ถูกต้องอยู่เสมอ เงื่อนไขการอ้างอิงสำหรับการสร้างไซต์, เงื่อนไขการอ้างอิงสำหรับโครงการออกแบบ, เงื่อนไขการอ้างอิงสำหรับการพัฒนาซอฟต์แวร์, เงื่อนไขการอ้างอิงสำหรับสิ่งนี้, เงื่อนไขการอ้างอิงสำหรับสิ่งนี้ ... มันสำคัญจริงๆหรือ, เงื่อนไขการอ้างอิง, การอ้างอิงที่คุ้นเคย เป็น TK? แล้วมาดูกัน!
ตัวอย่างเช่น เรามาเน้นประเด็นที่พบบ่อยที่สุดอย่างหนึ่ง - การเตรียมเงื่อนไขอ้างอิงสำหรับการพัฒนาโปรแกรม และบางทีเราจะเริ่มตอบคำถามที่เกิดขึ้นทีละน้อย
ทำไมต้องเป็นงานด้านเทคนิค?
ตอบคำถาม "ทำไม" สิ่งสำคัญคือต้องเข้าใจสิ่งที่กำลังพูดจริงๆ ตามที่ระบุไว้ข้างต้นเป็นตัวอย่างของการจัดทำข้อกำหนดอ้างอิงการพัฒนาโปรแกรมได้รับการคัดเลือก และนี่หมายความว่าองค์กร บริษัท องค์กรมีงานที่มีอยู่จริงในปัจจุบันที่สามารถและควรแก้ไขได้อย่างมีประสิทธิภาพมากกว่าที่เป็นอยู่ในขณะนี้ กล่าวอีกนัยหนึ่ง จำเป็นต้องเปลี่ยนแรงงานมนุษย์ซึ่งมีราคาแพงและมีคุณภาพต่างกันด้วยงานซอฟต์แวร์ที่มีประสิทธิภาพและราคาไม่แพงมาก
อันที่จริง พนักงานต้องการวันหยุด พวกเขาทั้งหมดต้องการได้รับเงินตรงเวลา ค่าจ้าง, "ลาป่วย" เป็นระยะและตามกฎแล้วอย่าแสดงความปรารถนาที่จะทำงานในวันหยุดสุดสัปดาห์ ในทางกลับกัน การพัฒนาโปรแกรมไม่เพียงแต่ทำให้เกิดปัญหาที่ระบุ แทนที่กันและกันด้วยความสม่ำเสมอที่น่าอิจฉา แต่ในทางกลับกัน แก้ปัญหาเหล่านั้นได้!
มาดูวิธีแก้ปัญหากันดีกว่า เนื่องจากรายการปัญหาในปัจจุบันที่ต้องแก้ไขผ่านซอฟต์แวร์ได้เกิดขึ้นแล้ว จึงถึงเวลาที่ต้องคิดถึงกระบวนการแก้ไขด้วยตนเอง เรารวบรวม นั่ง โต้เถียง ค้นหา และในที่สุด นี่คือความคิดเห็นทั่วไปของผู้รับผิดชอบเกี่ยวกับสิ่งที่โปรแกรมในอนาคตจะทำไม่มากก็น้อย นี่เป็นสิ่งที่ข้อกำหนดเบื้องต้นสำหรับการเตรียมข้อกำหนดอ้างอิงสำหรับการพัฒนาโปรแกรมเกิดขึ้นอย่างช้าๆ แต่แน่นอน
แน่นอนว่าสิ่งต่าง ๆ อาจแตกต่างกันมาก เรามอบความไว้วางใจในการจัดเตรียมข้อกำหนดอ้างอิงให้กับผู้เชี่ยวชาญของบริษัทที่เสนอการพัฒนาโปรแกรม การประชุมสองสามครั้งในบรรยากาศเหมือนธุรกิจ แต่เป็นกันเอง, บรีฟสำเร็จรูป, แบบฟอร์ม, สัญญา, แบบฟอร์ม ทุกอย่างเสร็จสิ้นและทุกคนมีความสุข อย่างน้อยก็ตอนนี้.
เจ้าของเป็นสุภาพบุรุษและมีอิสระที่จะเลือกตัวเลือกที่ดีที่สุดทั้งในด้านราคาและคุณภาพ แน่นอนว่าทั้งคู่เหมาะสมกันดี แต่คุณต้องประนีประนอมเสมอ หากราคาต่ำเกินไป การแลกเปลี่ยนเพื่อการพัฒนาซอฟต์แวร์จะเปลี่ยนไปสู่คุณภาพของซอฟต์แวร์ที่เสื่อมลงอย่างรวดเร็ว อย่างไรก็ตาม ในทางตรงกันข้าม สิ่งเดียวกันก็เกิดขึ้นกับการร่างข้อกำหนดทางเทคนิคที่ไม่รู้หนังสือสำหรับการพัฒนาโปรแกรม จ่ายเงินแล้ว ได้รับสินค้าแล้ว ใช้งานได้จริง แต่ไม่ใช่แบบนั้น
ที่จริงแล้ว คำตอบสำหรับคำถามที่ว่าทำไมจึงจำเป็นต้องร่างงานด้านเทคนิคที่มีความสามารถสำหรับการพัฒนาโปรแกรมนั้นชัดเจน ก้าวไปข้างหน้า.
ข้อกำหนดสำหรับใคร?
เงื่อนไขอ้างอิงสำหรับการพัฒนาโปรแกรมนั้น ประการแรก สำหรับผู้ที่จะดำเนินการพัฒนานี้ ดังนั้น จึงควรมีความชัดเจนสำหรับผู้ที่ไม่รู้อะไรเกี่ยวกับลูกค้า และยิ่งไปกว่านั้น เกี่ยวกับงานและปัญหาของเขา อย่างน้อยเขาก็ยังไม่รู้
ดังนั้น เงื่อนไขอ้างอิงสำหรับการพัฒนาโปรแกรมควรบอกผู้รับเหมาเกี่ยวกับบริษัท เกี่ยวกับเป้าหมาย และเกี่ยวกับงาน ในเวลาเดียวกัน ยิ่งเรื่องราวเฉพาะเจาะจงมากเท่าไหร่ ก็ยิ่งดี - ทั้งสำหรับผู้บรรยาย นั่นคือ ลูกค้าสำหรับการพัฒนาโปรแกรม และสำหรับผู้ฟัง นั่นคือ สำหรับผู้ดำเนินโครงการ
โดยทั่วไป เงื่อนไขในการอ้างอิงมีหลายเป้าหมาย และถึงแม้อาจมีการกล่าวไว้ตั้งแต่เริ่มต้น แต่ก็ไม่เคยสายเกินไปที่จะแก้ไขการละเลย ดังนั้นเป้าหมาย:
- องค์กร
- ข้อมูล
- การสื่อสาร
- อำนาจศาล.
องค์กรควรมุ่งไปที่กระบวนการเอง กล่าวอีกนัยหนึ่ง เพื่อปรับปรุงความคิดสร้างสรรค์และการสร้างโปรแกรม หรือแพ็คเกจซอฟต์แวร์ โครงสร้างของข้อกำหนดอ้างอิงสำหรับการพัฒนาโปรแกรมควรมีความชัดเจนและรัดกุมในเวลาเดียวกัน ตั้งแต่อ่าน 120-150 หน้าของข้อความทางเทคนิคที่ย่อยไม่ได้ บุคลิกเชิงสร้างสรรค์ของโปรแกรมเมอร์ก็ไม่สามารถทำได้ ดังนั้น ความกะทัดรัดจึงเป็นน้องสาวของพรสวรรค์
องค์ประกอบข้อมูลของ TOR ควรสมบูรณ์ แต่กระชับ
และอีกครั้ง กฎง่ายๆ "จำเป็นและเพียงพอ" ตามปกติจะต้องปฏิบัติตามเสมอและทุกที่ แต่เมื่อร่างเงื่อนไขอ้างอิงสำหรับการพัฒนาโปรแกรม กฎนี้จะกลายเป็นอันดับหนึ่ง งานด้านเทคนิคที่มีความสามารถเป็นเอกสารแรกและสุดท้ายที่จะบอกความต้องการของลูกค้าในรูปแบบที่โปรแกรมเมอร์เข้าใจได้ง่าย คุณต้องการเปลี่ยนชีวิตของบริษัทหรือองค์กรของคุณไปสู่ระดับใหม่โดยพื้นฐานหรือไม่? จากนั้นเงื่อนไขอ้างอิงสำหรับการพัฒนาโปรแกรมเป็นจุดศูนย์กลางที่โลกจะพลิกกลับในทิศทางที่คุณระบุ และคุณเห็นว่าสิ่งนี้ไม่สามารถละเลยได้ไม่ว่าด้วยวิธีใด
การสื่อสารค่อนข้างยากขึ้น ทำไม ใช่ เพราะการสื่อสารและแม้แต่ในกระบวนการที่ค่อนข้างสร้างสรรค์นั้นยากเสมอ ยิ่งถ้าพูด ภาษาที่แตกต่างกัน. และสามารถมีได้หลายภาษาที่นี่ แม่นยำยิ่งขึ้น - ตามจำนวนผู้เข้าร่วมในโครงการ ที่มีชื่อรหัสว่า "การพัฒนาซอฟต์แวร์"
พูดง่ายๆ ว่า:
- ลูกค้าเขาเป็นลูกค้า
- ผู้จัดการโครงการ
- ผู้ดำเนินโครงการ พวกเขาหรือเขา: โปรแกรมเมอร์
- ผู้เข้าร่วมที่เป็นไปได้คนอื่นๆ ที่มีความคิดเห็น: ทำอย่างไร ทำอย่างไรให้ดีขึ้น และควรจบอย่างไร
สร้างสรรค์อย่างเป็นธรรมชาติ โครงการทั่วไปผู้เข้าร่วมเหล่านี้ถูกบังคับให้มองหาภาษาที่ทุกคนสามารถเข้าใจได้ ภาษานี้จัดทำขึ้นเพื่อใช้เป็นเงื่อนไขอ้างอิงสำหรับการพัฒนาโปรแกรม ตามหลักการแล้วสิ่งสำคัญคือการสร้างช่องทางการสื่อสารระหว่างลิงก์ที่หนึ่งและสามและยิ่งมีการรบกวนน้อยลงในลิงก์ที่สองและสี่ผลลัพธ์ก็จะดีขึ้นและการพัฒนาโปรแกรมจะนำผลลัพธ์ที่ต้องการโดยมีการสูญเสียเส้นประสาทน้อยที่สุด .
ดังนั้นเราจึงไปถึงเขตอำนาจศาลโดยบังเอิญสัมผัสกับปัญหาของ "การสูญเสียเส้นประสาท" ด้วยเงื่อนไขอ้างอิง จึงสามารถตัดสินความสอดคล้องของผลลัพธ์ของการพัฒนาโปรแกรมและเงื่อนไขเบื้องต้นที่กำหนดได้ ต้องบอกว่าหน่วยความจำอายุสั้นทนทุกข์ทั้งกับลูกค้าของโครงการและสำหรับผู้ดำเนินการ อย่างแรกลืมเกี่ยวกับค่าใช้จ่ายที่ตกลงกันไว้ จำนวนการแก้ไข ความเป็นไปได้ของการใช้งานและการดีบัก และประการที่สอง - โดยหลักการแล้ว เกี่ยวกับสิ่งที่ควรทำและเมื่อใด เพื่อลดความจำเสื่อมและผลที่ตามมาให้เหลือน้อยที่สุด จำเป็นต้องมี TOR ที่ชัดเจนและเฉพาะเจาะจงสำหรับการพัฒนาโปรแกรมอีกครั้ง!
จะเขียนงานด้านเทคนิคได้อย่างไร?
เมื่อมั่นใจถึงความจำเป็นและแม้แต่เงื่อนไขอ้างอิงที่ประเมินค่าไม่ได้ในการพัฒนาโปรแกรม เราก็สามารถสนทนาต่อไปได้ ตอนนี้เรามาถึงคำถามที่จริงจังที่สุดแล้ว: วิธีสร้าง TOR ให้มีความสามารถชัดเจนรัดกุม แต่เฉพาะเจาะจง! และเราไม่ต้องการอะไรอีกแล้ว
สิ่งนี้ได้รับการดูแลในสมัยโบราณของสหภาพโซเวียตโดยได้พัฒนาแนวคิดทั้งหมดของมาตรฐานที่เรียกว่า GOST น่าแปลกที่การพัฒนาโปรแกรม มาตรฐานเหล่านี้ยังระบุด้วยว่าคุณจะเห็นด้วย อดไม่ได้ที่จะชื่นชมยินดี
การพัฒนาโปรแกรมและการเตรียมข้อกำหนดในการอ้างอิงในพื้นที่นี้ถูกควบคุมโดย GOST 19.201-78 ระบบเดียวเอกสารประกอบซอฟต์แวร์ งานด้านเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
นอกจากนี้ มัคคุเทศก์อีกสองคนจะไม่ฟุ่มเฟือย:
- GOST 2.114-95 ระบบ Unified สำหรับเอกสารการออกแบบ ข้อมูลจำเพาะ;
- GOST 34.602-89 เทคโนโลยีสารสนเทศ ชุดมาตรฐานสำหรับระบบอัตโนมัติ เงื่อนไขการอ้างอิงสำหรับการสร้างระบบอัตโนมัติ แน่นอนว่าทรินิตี้นี้ถือได้ว่าเป็น "สิ่งศักดิ์สิทธิ์" ในการพัฒนาและเตรียมข้อกำหนดทางเทคนิคสำหรับเกือบทุกสาขาวิชา แน่นอนว่ายังมีมาตรฐานอื่นๆ ที่สามารถและควรปฏิบัติตาม แต่อย่าลืมว่า "จำเป็นและเพียงพอ"
เราลงเอยด้วยอะไร?
ตอบ โครงสร้างทั่วไปของเงื่อนไขอ้างอิง รวมถึงการพัฒนาโปรแกรม
- สิ่งที่ต้องทำภายในกรอบของโครงการ
- เหตุใดจึงจำเป็น และเพื่อวัตถุประสงค์เฉพาะอะไร
- จะใช้ผลลัพธ์ของโครงการที่ไหน (อ่าน, พัฒนาโปรแกรม) ในด้านของกิจกรรมและในระดับใด
- ข้อกำหนดใดที่ควรได้รับจากการพัฒนาโปรแกรม
- สิ่งที่ต้องทำในกระบวนการทำงานในโครงการ
- ผลลัพธ์จะถูกประเมินโดยลูกค้าอย่างไร
- เอกสารใดบ้างที่กำหนดขั้นตอนสำหรับการโต้ตอบในโครงการ
- อะไรคือพื้นฐานในการเริ่มงานในโครงการพัฒนาซอฟต์แวร์
ส่วนที่สองของ GOST 19.201-78 ที่ระบุซึ่งกำหนดเนื้อหาของส่วนนี้จะช่วยในการร่างเงื่อนไขการอ้างอิงสำหรับการพัฒนาโปรแกรมโดยละเอียดยิ่งขึ้น
ประเด็นเฉพาะเจาะจงของเราคือการพัฒนาซอฟต์แวร์ ฉันต้องการเน้นส่วนข้อกำหนดของซอฟต์แวร์ เมื่อรวบรวมส่วนนี้ ควรเข้าหาปัญหาอย่างเป็นทางการ กล่าวอีกนัยหนึ่ง "เปิดหน้าต่างใหม่" "แก้ไขไฟล์ปัจจุบันผ่านคำสั่งจากคอนโซลผู้ใช้" และ "บันทึกการเปลี่ยนแปลงเมื่อปิดหน้าต่างโปรแกรมหลัก" เป็นแนวทางที่ชัดเจนและเป็นทางการ
นอกจากนี้ การพัฒนาโปรแกรมต้องเป็นไปตามข้อกำหนดจำนวนหนึ่งซึ่งต้องระบุไว้ในเงื่อนไขการอ้างอิง นี่คือรายการข้อกำหนด:
- ไปยังชุดของฟังก์ชันที่ดำเนินการโดยโปรแกรม
- ในการจัดระเบียบข้อมูลเข้าและส่งออก
- เพื่อเพิ่มความเร็ว;
- เพื่อความน่าเชื่อถือของการทำงาน
- ถึงระยะเวลาการกู้คืนในกรณีที่เกิดความล้มเหลว
- เกี่ยวกับความล้มเหลวเนื่องจากการกระทำที่ไม่ถูกต้องของผู้ใช้
- กับประเภทของบริการ
- กับจำนวนและคุณสมบัติของบุคลากรที่มีปฏิสัมพันธ์กับโครงการ
- กับพารามิเตอร์ของวิธีการทางเทคนิคที่จะรับประกันประสิทธิภาพการทำงานปกติของโปรแกรม
- ไปจนถึงภาษาต้นทางและรหัสโปรแกรม โครงสร้างข้อมูล และเครื่องมือซอฟต์แวร์ของบริษัทอื่น
- เกี่ยวกับการป้องกันและความปลอดภัยของข้อมูล
- การติดฉลากและบรรจุภัณฑ์
- ตามเงื่อนไขการขนส่งและการเก็บรักษา
นอกจากนี้ รายการข้อกำหนดสำหรับการพัฒนาโปรแกรมสามารถเปลี่ยนแปลงได้: เพิ่มหรือลดตามเงื่อนไขเฉพาะของโครงการ
ใครเป็นผู้กำหนดเงื่อนไขการอ้างอิง?
ได้เวลาเก็บสต็อกแล้ว ใครควรแบกรับภาระหนัก ๆ เหล่านี้กับไหล่ที่เปราะบางของพวกเขา - การจัดเตรียมข้อกำหนดทางเทคนิคสำหรับการพัฒนาโปรแกรม แน่นอน ผู้จัดการโครงการ!เป็นบุคคลผู้นี้ที่ปูทางสู่ความสุข ความปรองดอง และความเข้าใจร่วมกันของผู้รับเหมาและลูกค้าด้วยการทำงานมากเกินไป
โดยธรรมชาติแล้ว งานของผู้จัดการนั้นไม่สร้างสรรค์น้อยกว่างานของโปรแกรมเมอร์ และเพื่อหลีกเลี่ยงความโกลาหลและความวุ่นวายเชิงสร้างสรรค์ งานนั้นก็ต้องการการออกแบบที่ชัดเจนเช่นกัน ให้ทุกอย่างที่เกี่ยวข้องกับหน้าที่ของผู้จัดการโครงการในระหว่างการพัฒนาในสถานที่ของพวกเขา:
- การกำหนดงานของโครงการ
- การจัดทำและข้อกำหนดสำหรับการดำเนินการทางเทคนิค
- การกำหนดข้อกำหนดสำหรับโปรแกรมที่พัฒนาขึ้น
- การประสานงานของขั้นตอน ระยะเวลา และการเตรียมเอกสาร
- บ่งชี้ภาษาโปรแกรมและรหัส
- ร่าง อัปเดต และอนุมัติข้อกำหนดทางเทคนิคโดยลูกค้า
แม้จะมีความเรียบง่ายของฟังก์ชันเหล่านี้ แต่ก็มีผู้จัดการเพียงไม่กี่เปอร์เซ็นต์เท่านั้นที่สามารถทำงานได้อย่างดี และเพื่อไม่ให้ใครถูกตัดสินว่ามีความผิด จำเป็นต้องอนุมัติข้อกำหนดในการอ้างอิงพร้อมลายเซ็นของตัวแทนของทั้งสองฝ่าย ซึ่งระบุโดยเงื่อนไขของข้อตกลงสำหรับการพัฒนาโปรแกรม
ฝ่ายเหล่านี้ต้องได้รับคำแนะนำจาก GOST 19.201-78 ซึ่งไม่มากก็น้อย แต่มีอายุเกือบ 30 ปี
กระทู้ที่เกี่ยวข้อง
แนวคิดของ "วิศวกรรมย้อนกลับ" เป็นสูตรที่ทันสมัยของแนวคิดเดิม - คัดลอกปรับปรุง ... ด้วยการพัฒนาเทคโนโลยีคอมพิวเตอร์ ...
โดยพื้นฐานแล้วด้วย เทคโนโลยีสารสนเทศมนุษยชาติได้เผชิญและเผชิญในทุกย่างก้าวของชีวิต แค่…
แนวคิดของการปรับรื้อระบบเกิดขึ้นในยุค 90 เป็นการตอบสนองต่อปัญหาที่เกิดขึ้นระหว่างระบบอัตโนมัติจำนวนมาก ...
17.11.2014
งานใด ๆ เริ่มต้นด้วยงาน และงานของนักเขียนด้านเทคนิคต้องเริ่มต้นด้วยงานด้านเทคนิค เหลือเพียงการค้นหาว่ามันคืออะไรและทำไมเราต้องการมัน อ่านบทความของ Kimberly Chan เพื่อที่คุณจะได้ไม่ต้องตกอยู่ในสถานการณ์เดียวกับผู้พัฒนาจากซีรีส์หนังสือการ์ตูนที่เรารักอยู่แล้ว
เงื่อนไขอ้างอิงสำหรับการพัฒนาซอฟต์แวร์คืออะไร?
นักพัฒนาส่วนใหญ่ชอบที่จะทำงานกับข้อกำหนดการพัฒนาซอฟต์แวร์ เนื่องจากเอกสารนี้มักจะประกอบด้วยสิ่งต่อไปนี้:
- คำอธิบายที่สมบูรณ์ของวัตถุประสงค์และการทำงานของซอฟต์แวร์
- รายละเอียดเกี่ยวกับวิธีการทำงานของโปรแกรมในแง่ของความเร็ว เวลาตอบสนอง ความพร้อมใช้งาน การพกพา ความน่าเชื่อถือ ความเร็วในการกู้คืน ฯลฯ
- ตัวเลือกสำหรับวิธีที่ผู้ใช้จะใช้ซอฟต์แวร์
- การพิจารณาว่าแอปพลิเคชันจะโต้ตอบกับฮาร์ดแวร์หรือโปรแกรมอื่นๆ อย่างไร
- ข้อกำหนดที่ไม่เป็นไปตามข้อกำหนด (เช่น ข้อกำหนดด้านประสิทธิภาพ มาตรฐานคุณภาพ หรือข้อจำกัดด้านการออกแบบ)
ทำไมมันถึงสำคัญ?
TOR ช่วยให้นักพัฒนาเข้าใจเป้าหมายของซอฟต์แวร์ได้อย่างชัดเจนและสิ่งที่ควรเน้น นอกจากนี้ มัน:
จะเขียน TOR สำหรับการพัฒนาซอฟต์แวร์ได้อย่างไร?
ไม่มีวิธีมาตรฐานในการเขียน TOR แต่เราสามารถให้คำแนะนำได้:
สร้างสคีมา
หากคุณยังไม่มีเทมเพลต สามารถค้นหาได้ทางออนไลน์ ใช้เทมเพลตเพื่อสร้างโครงร่างเอกสาร ปรับเปลี่ยนให้เหมาะสมกับความต้องการขององค์กรของคุณ
ข้อกำหนดของแผนอ้างอิงแตกต่างกันไปขึ้นอยู่กับองค์กรและกระบวนการ บางส่วนอาจเรียบง่าย อื่นๆ มีรายละเอียดและซับซ้อนกว่า
นี่คือตัวอย่างแผน TOR อย่างง่ายสำหรับซอฟต์แวร์:
- ขอบเขตการใช้งาน
- ภาพรวมของระบบ
- ลิงค์
- คำจำกัดความ
- ตัวอย่างการใช้
- ความต้องการการทำงาน
- ข้อกำหนดที่ไม่เป็นไปตามข้อกำหนด
หลังจากสร้างแผนแล้ว คุณสามารถเขียนข้อกำหนดได้ นี่คือเคล็ดลับบางประการ:
เลือกเขียนดีกว่า
ผู้เขียนต้องมีทักษะการสื่อสารที่ดีเยี่ยม จุดประสงค์ของข้อกำหนดคือทุกคนสามารถเข้าใจได้ สิ่งใดก็ตามที่ยังไม่ชัดเจนหรือเข้าใจผิดอาจนำไปสู่ผลลัพธ์ที่ไม่น่าพอใจนัก หลายคนคิดว่าการมีส่วนร่วมของนักเขียนด้านเทคนิคในกระบวนการนี้ช่วยป้องกันความเข้าใจผิด มีนักเขียนที่มีประสบการณ์มากกว่านักพัฒนา มีความสามารถด้านความแม่นยำและความชัดเจน นักเขียนด้านเทคนิครู้วิธีรวบรวมและประมวลผลข้อมูลที่ถูกต้อง พวกเขายังรู้วิธีสื่อสารความต้องการของลูกค้า
ทำให้ข้อมูลเป็นภาพ
รูปภาพสามารถบันทึกคำได้ 1,000 คำ รวมข้อมูลภาพ เช่น ตารางและกราฟ เพื่อถ่ายทอดความคิดได้ดียิ่งขึ้น
อย่าเอกสารมากเกินไป
พยายามอย่ารวมรายการในเอกสารที่ไม่จำเป็นต้องจัดทำเป็นเอกสาร TOR อาจยาวเกินไป ดังนั้นให้หลีกเลี่ยงข้อมูลที่ซ้ำซ้อน
สร้าง TOR เวอร์ชันออนไลน์และอัปเดตอยู่เสมอ
เมื่องานเสร็จสมบูรณ์หรือหากมีการเปลี่ยนแปลงในพนักงานหรือกระบวนการ TOR จะต้องได้รับการอัปเดต ด้วยเหตุผลนี้ โปรดเก็บเวอร์ชันเสมือนไว้ - ซึ่งจะช่วยให้มั่นใจว่าทั้งทีมจะได้รับเอกสารที่อัปเดตสำหรับการเปลี่ยนแปลงใดๆ
มาตรฐานนี้กำหนดขั้นตอนในการสร้างและดำเนินการตามข้อกำหนดทางเทคนิคสำหรับการพัฒนาโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์สำหรับคอมพิวเตอร์ คอมเพล็กซ์ และระบบ โดยไม่คำนึงถึงวัตถุประสงค์และขอบเขต
มาตรฐานสอดคล้องกับ ST SEV 1627-79 อย่างสมบูรณ์
กฎการออกแบบ
ข้อกำหนดในการอ้างอิงนั้นจัดทำขึ้นตาม GOST 19.106-78 บนแผ่นงานรูปแบบ 11 และ 12 ตาม GOST 2.301-68 ตามกฎโดยไม่ต้องกรอกข้อมูลในฟิลด์ของแผ่นงาน จำนวนแผ่นงาน (หน้า) จะถูกใส่ลงในส่วนบนของแผ่นงานเหนือข้อความ
ใบอนุมัติและหน้าชื่อเรื่อง
ใบอนุมัติและหน้าชื่อเรื่องถูกวาดขึ้นตาม GOST 19.104-78
ส่วนที่ให้ข้อมูล (นามธรรมและเนื้อหา) ใบจดทะเบียนการเปลี่ยนแปลงอาจไม่รวมอยู่ในเอกสาร
การเปลี่ยนแปลงและเพิ่มเติม
ในการเปลี่ยนแปลงหรือเพิ่มเติมข้อกำหนดในการอ้างอิงในขั้นต่อไปของการพัฒนาโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์ จะมีการออกภาคผนวก การประสานงานและการอนุมัติการเพิ่มข้อกำหนดในการอ้างอิงจะดำเนินการในลักษณะเดียวกับที่กำหนดไว้สำหรับข้อกำหนดในการอ้างอิง
เป็นไปไม่ได้ที่จะคำนึงถึงรายละเอียดทั้งหมดในระยะเริ่มต้นของการพัฒนา ในทางปฏิบัติ วิธีนี้ใช้ค่อนข้างบ่อย ในส่วน "ขั้นตอนและขั้นตอนของการพัฒนา" ควรระบุความเป็นไปได้ในการเปลี่ยนแปลงและเพิ่มเติมข้อกำหนดในการอ้างอิงอย่างชัดเจน: "เนื้อหาของส่วนต่างๆ ของข้อกำหนดในการอ้างอิงนี้สามารถเปลี่ยนแปลงและเพิ่มเติมได้ตามข้อตกลงกับลูกค้า "
องค์ประกอบของส่วนของเงื่อนไขการอ้างอิง
เงื่อนไขการอ้างอิงควรประกอบด้วยส่วนต่อไปนี้:
การแนะนำ;
เหตุผลในการพัฒนา
วัตถุประสงค์ของการพัฒนา
ข้อกำหนดสำหรับโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์
ข้อกำหนดสำหรับเอกสารประกอบซอฟต์แวร์
ตัวชี้วัดทางเทคนิคและเศรษฐกิจ
ขั้นตอนและขั้นตอนของการพัฒนา
ขั้นตอนการควบคุมและการยอมรับ
อนุญาตให้รวมแอปพลิเคชันไว้ในเงื่อนไขการอ้างอิง
ขึ้นอยู่กับคุณสมบัติของโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์ อนุญาตให้ชี้แจงเนื้อหาของส่วนต่างๆ แนะนำส่วนใหม่ หรือรวมบางส่วนเข้าด้วยกัน เห็นด้วยกับลูกค้าอย่างเคร่งครัด ความยินยอมของลูกค้าจะต้องสะท้อนให้เห็นในข้อความของข้อกำหนดในการอ้างอิง
ในฐานะโปรแกรมการฝึกอบรม เราจะใช้โปรแกรมจริงที่มีส่วนต่อประสานกราฟิกกับผู้ใช้ที่ให้ความสามารถในการใช้งานฟังก์ชันเทมเพลตต่างๆ (เช่น โปรแกรมแก้ไขข้อความอย่างง่าย)
บทนำ
ส่วนนี้ระบุชื่อ คำอธิบายสั้นๆ เกี่ยวกับขอบเขตของโปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์ และวัตถุที่ใช้โปรแกรมหรือผลิตภัณฑ์ซอฟต์แวร์
กฎพื้นฐานสำหรับการทำงานกับข้อความคือรายละเอียด การแยกข้อความออกเป็นหน่วยโครงสร้าง ส่วนย่อย ย่อหน้า และย่อหน้าย่อย สารบัญของข้อความจะมีโครงสร้างที่ชัดเจน ทำให้ง่ายต่อการค้นหาวัสดุที่ต้องการ ข้อความในเอกสารจะกลายเป็นโครงสร้างและอ่านง่าย สร้างส่วนย่อย:
ชื่อโปรแกรม
ชื่อ - "โปรแกรมแก้ไขข้อความสำหรับการทำงานกับไฟล์ rtf"
คำอธิบายโดยย่อของขอบเขต
โปรแกรมนี้มีไว้สำหรับใช้ในแผนกเฉพาะทางที่สถานประกอบการของลูกค้า
เนื้อหาของแต่ละรายการไม่ชัดเจนเสมอไป ในกรณีที่มีปัญหาควรติดต่ออย่างเป็นทางการ การแก้ไขสามารถทำได้ในขั้นตอนการยอมรับข้อกำหนดในการอ้างอิงกับลูกค้า
เหตุผลในการพัฒนา
ส่วนควรรวมถึง:
เอกสาร (เอกสาร) บนพื้นฐานของการพัฒนา;
องค์กรที่อนุมัติเอกสารนี้และวันที่อนุมัติ
ชื่อและ (หรือ) เครื่องหมายหัวข้อการพัฒนา
ส่วนย่อยควรมีข้อมูลที่มีอยู่ในข้อตกลง
พื้นฐานการพัฒนา
พื้นฐานสำหรับการพัฒนาคือข้อตกลง (จดหมาย ฯลฯ) ฉบับที่ 666 ลงวันที่ 15 มีนาคม 2547 (หมายเลขขาเข้าดังกล่าวและจากดังกล่าว) สัญญาดังกล่าวตกลงกับผู้อำนวยการของรัฐ Unitary Enterprise "Spetstyazhmontazhstroyselkhozavtomatika" Ivanov Petr Ivanovich ซึ่งต่อไปนี้จะเรียกว่าลูกค้า และได้รับการอนุมัติโดยผู้อำนวยการทั่วไปของ OAO Supersoft Blyumkins Ivan Aronovich ซึ่งต่อไปนี้จะเรียกว่าผู้รับเหมา มีนาคม 2551
สะดวกในการใช้ส่วน "ข้อมูลทั่วไป" ของ GOST 34.602-89 เนื่องจากผู้พัฒนามีสิทธิ์เต็มที่ในการเสริมและลบส่วนของข้อกำหนดในการอ้างอิงตามดุลยพินิจของเขา ในเวลาเดียวกัน ข้อมูลที่ระบุข้างต้นมีอยู่ในข้อตกลง ว่าควรให้ไว้ในข้อกำหนดในการอ้างอิงหรือไม่นั้นขึ้นอยู่กับกรณีเฉพาะ