บ้าน บล็อกธุรกิจ คำอธิบายถึงร่างทางเทคนิคของมาตรฐานของรัฐ คำอธิบายเกี่ยวกับโครงการทางเทคนิคตาม GOST

คำอธิบายถึงร่างทางเทคนิคของมาตรฐานของรัฐ คำอธิบายเกี่ยวกับโครงการทางเทคนิคตาม GOST

บันทึกอธิบาย (EP) เป็นหนึ่งในประเด็นที่สำคัญที่สุดของโครงการด้านเทคนิค ซึ่งมีคำอธิบายและคุณลักษณะที่สมบูรณ์ของเทคโนโลยีที่เลือกซึ่งกำหนดประเภทและการออกแบบระบบภายใต้การศึกษา

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

องค์ประกอบของบันทึกอธิบาย

หมายเหตุอธิบายโครงการของ OKS ใด ๆ มีส่วนย่อย:

การแนะนำ. ส่วนนี้ระบุชื่อของวัตถุหรือระบบ หัวข้อการพัฒนา และรายการเอกสาร - รากฐานสำหรับการเริ่มงาน เอกสารพื้นฐานที่ให้ไว้ในบทนำ:

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

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

ตัวชี้วัดทางเทคนิคและเศรษฐกิจ - ข้อมูลสะท้อนถึงความสามารถในการออกแบบของ OKS ความสำคัญต่อประชากร จำนวนพนักงานในอนาคต จำนวนงาน ฯลฯ

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

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

อ้างอิง. ส่วนนี้ประกอบด้วยแหล่งที่มา เอกสาร บทความ หนังสือ ลิงก์ซึ่งระบุไว้ในส่วนข้อความของโครงการ

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

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

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

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

มาตรฐานเอกสารคืออะไร?

ในซีรี่ส์ 34 ที่เป็นปัญหา มีเพียง 3 มาตรฐานเอกสารหลักเท่านั้น:

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

นี่เป็นเอกสารพื้นฐานที่แสดงรายการเอกสาร GOST 34 ทั้งหมด คำแนะนำสำหรับเอกสารการเข้ารหัส ขั้นตอนของโครงการที่เป็นของเอกสาร (ขั้นตอนต่างๆ อธิบายไว้ใน GOST 34.601-90) รวมถึงวิธีการรวมเข้าด้วยกัน กันและกัน.

ที่จริงแล้วมาตรฐานนี้เป็นตารางขนาดใหญ่พร้อมความคิดเห็น สามารถใส่ลงใน Excel ได้เพื่อความสะดวกในการใช้งาน

มาตรฐานมากมายที่อธิบายเนื้อหาของเอกสารโครงการด้วยรายละเอียดที่แตกต่างกัน GOST 34.201-89 ที่กล่าวถึงข้างต้นใช้เป็นดัชนี

มีคำถามและการตีความมากมายเกี่ยวกับมาตรฐาน RD 50-34.698-90 ซึ่งเนื่องจากความคลุมเครือ ลูกค้าและผู้รับเหมา หรือแม้แต่สมาชิกของทีมงานโครงการมักเข้าใจต่างกันออกไป แต่น่าเสียดายที่เราไม่มีอะไรที่เป็นรูปธรรมมากขึ้น

ให้เราพิจารณาข้อดีและข้อเสียของมาตรฐาน โดยเริ่มแรกด้วยข้อเสีย

ข้อเสียของมาตรฐาน

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

ดังนั้น มาตรฐานจึงมีอาร์ติแฟกต์ดังต่อไปนี้:

5.8. การเขียนแบบแบบฟอร์มเอกสาร (กรอบวีดีโอ)
เอกสารจะต้องมีรูปภาพของรูปแบบของเอกสารหรือกรอบวิดีโอตามข้อกำหนดของมาตรฐานของรัฐของระบบเอกสารรวม R 50-77 และคำอธิบายที่จำเป็น

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

“เฟรมวิดีโอ” ยังเป็นเอกสารที่แสดงบนการแสดงข้อความ จอแสดงผลไม่รองรับอักขระที่จำเป็นและจำนวนอักขระแนวนอนและเส้นแนวตั้งที่ต้องการเสมอไป (และไม่รองรับกราฟิกเลย) ดังนั้นที่นี่จึงจำเป็นต้องประสานแบบฟอร์มของเอกสารหน้าจอทั้งหมดเพิ่มเติมด้วย

ตอนนี้คำว่า "แมชชีนแกรม", "เฟรมวิดีโอ", "ADC" ไม่ได้บอกอะไรเราอีกต่อไป ฉันไม่พบมันใช้งานเลยแม้ว่าฉันจะสำเร็จการศึกษาจากสถาบันเฉพาะทางในช่วงทศวรรษ 90 ก็ตาม นี่เป็นช่วงเวลาของการปรากฏตัวของ Windows 3.1, จอแสดงผล VGA, ฟล็อปปี้ดิสก์ขนาด 3 นิ้วและเว็บไซต์อินเทอร์เน็ตในประเทศแห่งแรก แต่คำเหล่านี้อยู่ในมาตรฐานและบางครั้งลูกค้าก็เรียกร้องให้เราจัดเตรียมเอกสารชุดสมบูรณ์ให้เขาตาม GOST 34.201-89 ยิ่งกว่านั้น ถ้อยคำดังกล่าวใน ToR ย้ายจากกระทรวงหนึ่งไปยังอีกกระทรวงหนึ่ง และกลายเป็นเทมเพลตที่ไม่ได้พูดซึ่งเนื้อหาถูกแทรกเข้าไป

ดังนั้นเอกสารที่มีชื่อโง่ ๆ ว่า "การวาดแบบฟอร์มเอกสาร (เฟรมวิดีโอ)" ในโครงการจึงควรและไม่ควรว่างเปล่า

มีอะไรดีอยู่ในมาตรฐาน

มาตรฐานใดๆ ก็ตามที่ดีคือช่วยให้ลูกค้าและผู้รับเหมาสามารถพูดภาษาเดียวกันได้ และรับประกันว่า อย่างน้อย ลูกค้าจะไม่มีการร้องเรียนใดๆ "ในรูปแบบ" ต่อผลลัพธ์ที่ส่ง

และมาตรฐาน GOST 34 ก็ดีเช่นกันเพราะรวบรวมโดยคนฉลาดผ่านการทดสอบมาหลายปีและมีเป้าหมายที่ชัดเจน - เพื่ออธิบายบนกระดาษให้ครบถ้วนที่สุดเกี่ยวกับสาระสำคัญเชิงนามธรรมที่ซับซ้อนซึ่งระบบควบคุมอัตโนมัติเป็นตัวแทน

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

คุณสามารถหัวเราะกับความจริงที่ว่าผู้สร้างมาตรฐานไม่รู้อะไรเลยเกี่ยวกับ java หรือ .NET เกี่ยวกับจอภาพ HD และอินเทอร์เน็ต แต่ฉันจะไม่แนะนำให้ดูถูกดูแคลนขนาดของงานที่พวกเขาทำและคุณค่าของงานที่มีต่อชุมชนมืออาชีพของเรา

วิธีอ่านและทำความเข้าใจมาตรฐานเอกสารตามมาตรฐาน GOST series 34

มาตรฐานแบ่งเอกสารทั้งหมดออกเป็นสองแกน - เวลาและสาขาวิชา หากคุณดูตารางที่ 2 ใน GOST 34.201-89 คุณจะเห็นส่วนนี้อย่างชัดเจน (คอลัมน์ "ขั้นตอนการสร้าง" และ "ส่วนหนึ่งของโครงการ"

ขั้นตอนของการสร้างระบบควบคุมอัตโนมัติ

ขั้นตอนของการสร้างสรรค์กำหนดไว้ใน GOST 34.601-90 สามข้อเกี่ยวข้องกับเอกสาร:

การออกแบบร่าง (ED)
การออกแบบทางเทคนิค (TP)
การพัฒนาเอกสารการทำงาน (DD)

การออกแบบร่างติดตามหลังจากขั้นตอนข้อกำหนดทางเทคนิคและทำหน้าที่พัฒนาโซลูชันการออกแบบเบื้องต้น

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

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

ส่วน (ส่วน) ของเอกสารโครงการสำหรับการสร้างระบบควบคุมอัตโนมัติ

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

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

เพื่ออธิบาย "เครื่องจักร" นี้โดยสมบูรณ์ จึงได้มีการจัดทำส่วนต่อไปนี้ (ตามรูปวาด):

ซอฟต์แวร์ (MS)ตอบคำถาม: ตรรกะอะไรเดินสายอยู่ภายใน “กล่องดำ”? เหตุใดอัลกอริธึมเฉพาะเหล่านี้ สูตรเฉพาะเหล่านี้ และค่าสัมประสิทธิ์เฉพาะเหล่านี้จึงถูกเลือก

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

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

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

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

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

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

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

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

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

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

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

ในขั้นตอน RD มีเอกสารอื่นที่น่าสนใจกว่าปรากฏขึ้น ซึ่งฉันต้องการพิจารณาแยกกัน

คู่มือการใช้งาน- ฉันคิดว่าความคิดเห็นไม่จำเป็น

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

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

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

คำแนะนำทางเทคโนโลยีเป็นชั้นระหว่างคู่มือการใช้งานและคู่มือผู้ใช้ RP อธิบายอย่างละเอียด ยังไงคุณต้องดำเนินการบางอย่างในระบบ การเรียนการสอนทางเทคโนโลยีบอกว่า ที่จะต้องดำเนินการในบางกรณีที่เกี่ยวข้องกับการทำงานของระบบ โดยคร่าวแล้ว การสอนทางเทคโนโลยีเป็นเพียงการสรุปสั้นๆ ของ RP สำหรับตำแหน่งหรือบทบาทที่เฉพาะเจาะจง หากลูกค้าไม่มีการกำหนดบทบาทหรือต้องการให้คุณสร้างบทบาทและข้อกำหนดของงานด้วยตนเอง ให้รวมบทบาทพื้นฐานที่สุดในเอกสาร เช่น ผู้ปฏิบัติงาน ผู้ปฏิบัติงานอาวุโส ผู้ดูแลระบบ ความคิดเห็นของลูกค้าในหัวข้อ “แต่เราไม่ชอบ” หรือ “เราไม่ชอบ” ควรมีรายการบทบาทและคำอธิบายความรับผิดชอบในงานด้วย เพราะกระบวนการทางธุรกิจของเรา เราไม่ใส่มัน- เราคือกระบวนการทางธุรกิจเหล่านี้ อัตโนมัติ.

ฉันจะเขียนเกี่ยวกับคราดที่อธิบายแยกกันพร้อมตัวอย่างที่มีสีสัน เนื่องจากนี่ไม่ใช่ครั้งแรกที่มีการทำซ้ำในภาคส่วนต่างๆ ของ "เศรษฐกิจของประเทศ"

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

โซลูชันทั้งระบบ (WSO)- มาตรฐานนี้จัดทำเอกสาร 17 ฉบับในส่วน OP ประการแรก นี่เป็นเอกสารเกือบทั้งหมดของขั้นตอนเบื้องต้นของการออกแบบแผนผัง ประการที่สอง สิ่งเหล่านี้คือการประมาณ การคำนวณ และคำอธิบายโดยย่อของฟังก์ชันอัตโนมัติทุกประเภท นั่นคือข้อมูลสำหรับผู้ที่ไม่ได้มาจากการผลิตไอทีหลัก แต่สำหรับเจ้าหน้าที่สนับสนุน - ผู้จัดการ, นักประมาณการ, ผู้เชี่ยวชาญด้านการจัดซื้อ, นักเศรษฐศาสตร์ ฯลฯ

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

ตัวเลือกสำหรับการใช้ GOST 34

บทสรุป

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

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

ตามกฎแล้ว Explanatory Note เป็นเอกสารที่ซับซ้อนที่สุดเกี่ยวกับซอฟต์แวร์ ซึ่งบางครั้งก็ก่อให้เกิดข้อโต้แย้งและการถกเถียงกันมากมายเกี่ยวกับเนื้อหาในซอฟต์แวร์ ทำไมสิ่งนี้ถึงเกิดขึ้น?

วัตถุประสงค์ของบันทึกอธิบาย

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

องค์ประกอบของบันทึกอธิบายมาตรฐาน

ข้อความอธิบายสำหรับโครงการด้านเทคนิคประกอบด้วยส่วนต่างๆ เช่น:

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

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

– ข้อมูลจำเพาะ- โดยปกติส่วนนี้จะถูกแบ่งออกเป็นส่วนย่อยที่อธิบาย: การตั้งค่างานสำหรับการสร้างโปรแกรม; เครื่องมือทางคณิตศาสตร์ที่ใช้ อัลกอริธึมการทำงานของซอฟต์แวร์ โครงสร้างของข้อมูลเข้าและออก องค์ประกอบของฮาร์ดแวร์และซอฟต์แวร์ นอกจากนี้ยังจำเป็นต้องจัดเตรียมผลการคำนวณและการวิเคราะห์เพื่อยืนยันการเลือกโซลูชันที่กล่าวถึงในเอกสาร

– ตัวชี้วัดทางเทคนิคและเศรษฐกิจที่คาดหวัง- ส่วนนี้เกี่ยวข้องกับเหตุผลทางเศรษฐกิจสำหรับการพัฒนา โดยคำนึงถึงตัวชี้วัดทางเทคนิค

– แหล่งที่ใช้ในการพัฒนา- ส่วนนี้เป็นรายการเอกสาร บทความ และสิ่งพิมพ์ที่มีการอ้างอิงในข้อความ

มาตรฐานสำหรับหมายเหตุอธิบาย

องค์ประกอบของส่วนต่างๆ ถูกกำหนดโดย GOST 19.404 อย่างไรก็ตาม มาตรฐานอนุญาตให้รวมส่วนเหล่านี้เข้าด้วยกันหากจำเป็น และยังเพิ่มส่วนใหม่ได้ด้วย ในกรณีของการใช้ GOST series 34 ควรพัฒนาเอกสารตาม RD 50-34.698 อย่างไรก็ตาม เอกสารจะต้องเป็นไปตามข้อกำหนดของมาตรฐานทั่วไป เช่น GOST 19.105

ต้นทุนในการพัฒนาบันทึกอธิบาย

คุณจะสร้างเอกสารโปรแกรมด้วยต้นทุนต่ำสุดที่มีประโยชน์มากที่สุดสำหรับโครงการของคุณได้อย่างไร ซึ่ง:

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

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

โครงสร้างและการออกแบบ

บันทึกอธิบายจัดทำขึ้นตามมาตรฐานระหว่างรัฐ GOST 2.106-96 ซึ่งอธิบายข้อกำหนดทั่วไปสำหรับการจัดทำข้อความและเอกสารการออกแบบ เนื้อหาของส่วนต่างๆ ได้อธิบายไว้ในเอกสารคำแนะนำ RD 50-34.698-90 ซึ่ง ควบคุมข้อกำหนดสำหรับเนื้อหาของเอกสารสำหรับระบบควบคุมอัตโนมัติ

เอกสารนี้ตามมาตรฐานและเอกสารคำแนะนำควรประกอบด้วยหลายส่วน:

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

“คำอธิบายขั้นตอนกิจกรรม”
หมายเหตุอธิบายโครงการด้านเทคนิคประกอบด้วยข้อมูลทั่วไปเกี่ยวกับการทำงานของระบบที่กำลังพัฒนา

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

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

ข้อความอธิบายสำหรับโครงการด้านเทคนิค

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

- ระบบปฏิบัติการตระกูล Windows;
- 1C: องค์กร 8;

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

ระบบดำเนินงานหลักสามประการ:

- การบำรุงรักษาไดเร็กทอรี;
- การบำรุงรักษาคลังสินค้า
- การลงทะเบียนการขาย
- การส่งออกรายงาน

แอปพลิเคชัน DB สำหรับ IS ได้รับการพัฒนาโดยใช้สภาพแวดล้อมซอฟต์แวร์ 1C: Enterprise 8 คอมพิวเตอร์ส่วนบุคคลที่มีให้สำหรับผู้ประกอบการแต่ละรายที่ระบบกำลังได้รับการพัฒนานั้นใช้เพื่อโฮสต์ระบบ

โครงการ ใช้งานได้ โครงสร้าง

ข้อกำหนดทั่วไปสำหรับการทำงานของระบบที่ออกแบบนั้นแสดงไว้โดยใช้แผนภาพ VI ในรูปที่ 1

ตาราง -2 ส่วนหลักของสคริปต์การดำเนินการ VI “เพิ่มข้อมูลไดเรกทอรี”

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

ตาราง -3 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์การดำเนินการ VI “เพิ่มข้อมูลไดเรกทอรี”

ตารางที่ -4 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการ VI “เพิ่มข้อมูลไดเรกทอรี”

ตารางที่ -5 ส่วนหลักของสถานการณ์การดำเนินการ VI “กำหนดราคาสินค้า”

ตาราง - 6 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์จำลองการดำเนินการ VI “กำหนดราคาสินค้า”

ตารางที่ -7 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการ VI “กำหนดราคาสินค้า”

ตารางที่ -8 ส่วนหลักของสถานการณ์การดำเนินการ VI “ลงทะเบียนการรับสินค้า”

ตาราง -9 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์การดำเนินการของ VI "ลงทะเบียนการรับสินค้า"

การกระทำของนักแสดง	การตอบสนองของระบบ

1. เจ้าของร้านดำเนินการคำสั่งเพื่อสร้างเอกสารใหม่ “การรับสินค้า”	2. ระบบแสดงแบบฟอร์มเอกสาร
3. เจ้าของร้านกรอกรายละเอียดส่วนหัว ข้อยกเว้นหมายเลข 1: เจ้าของร้านกรอกข้อมูลในช่องตัวเลขด้วยตนเอง
4. เจ้าของร้านเพิ่มแถวใหม่ในส่วนตารางในหน้าสินค้า	5. ระบบจะแสดงบรรทัดใหม่
6. เจ้าของร้านกรอกคอลัมน์ระบบการตั้งชื่อ	7. ระบบจะทดแทนค่าคอลัมน์
8. เจ้าของร้านกรอกข้อมูลลงในคอลัมน์ปริมาณ	9. ระบบจะคำนวณค่าของคอลัมน์จำนวน
10. ระบบจะแสดงค่ารวมของคอลัมน์ Total ในส่วนท้ายของส่วนตาราง
11. เจ้าของร้านเข้าสู่ผลิตภัณฑ์ใหม่ (กลับไปที่ขั้นตอนที่ 4) หรือดำเนินการคำสั่ง Write ข้อยกเว้น #2: ค่าของฟิลด์ Number ไม่ซ้ำกัน	12. ระบบบันทึกเอกสาร “การรับสินค้า” ใหม่ในฐานข้อมูล
13. เจ้าของร้านดำเนินการคำสั่งพิมพ์ -	14. ระบบแสดงแบบฟอร์มใบสั่งใบเสร็จที่พิมพ์เสร็จแล้ว
15. เจ้าของร้านดำเนินการคำสั่งพิมพ์	16. ระบบพิมพ์ใบรับสินค้า
17. เจ้าของร้านดำเนินการคำสั่งปิดแบบฟอร์มการพิมพ์	18. ระบบปิดแบบฟอร์มการพิมพ์
19. เจ้าของร้านดำเนินการตามคำสั่ง ปิดเอกสาร “การรับสินค้า”	20. ระบบปิดแบบฟอร์มเอกสาร “การรับสินค้า”

ตารางที่ -10 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการ VI “ลงทะเบียนการรับสินค้า”

ค่าของผลรวมและคอลัมน์ทั้งหมดคำนวณโดยใช้สูตร:

จำนวน = จำนวน * ราคา

ตารางที่ -11 ส่วนของสถานการณ์การดำเนินการ VI "การสร้างยอดขาย"

ตารางที่ -12 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์การดำเนินการของ VI "การสร้างยอดขาย"

การกระทำของนักแสดง	การตอบสนองของระบบ

การชำระเงินสำหรับเอกสาร "การขาย" หนึ่งฉบับ
1. ผู้จัดการดำเนินการคำสั่งเพื่อสร้างเอกสารการขายใหม่	2. ระบบแสดงแบบฟอร์มเอกสาร “การขาย”

4. ผู้จัดการดำเนินการจัดทำเอกสาร
5. ระบบประมวลผลเอกสาร



9. ระบบจะพิมพ์

ตาราง - 13 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการของ VI "เอกสารการลงทะเบียน"

ตาราง -14 ส่วนของสถานการณ์การดำเนินการ VI "การจอง"

ตารางที่ -15 หลักสูตรทั่วไปของเหตุการณ์สำหรับสถานการณ์การดำเนินการของ VI "การสร้างยอดขาย"

การกระทำของนักแสดง	การตอบสนองของระบบ

สำรองสินค้า
1. ผู้จัดการดำเนินการคำสั่งเพื่อสร้างเอกสารการจองใหม่	2. ระบบแสดงแบบฟอร์มเอกสาร “การจอง”
3. ผู้จัดการป้อนข้อมูลเกี่ยวกับลูกค้า ผลิตภัณฑ์ที่ซื้อ และบริการที่ซื้อ
4. ผู้จัดการดำเนินการจัดทำเอกสาร ข้อยกเว้นหมายเลข 1: ไม่ได้กรอกข้อมูลทุกช่อง	5. ระบบประมวลผลเอกสาร
6. ผู้จัดการดำเนินการคำสั่งพิมพ์	7. ระบบแสดงแบบฟอร์มที่พิมพ์เสร็จแล้ว
8. ผู้จัดการดำเนินการคำสั่งพิมพ์	9. ระบบจะพิมพ์
10. ผู้จัดการดำเนินการคำสั่งปิดแบบฟอร์มที่พิมพ์ออกมา	11. ระบบปิดแบบฟอร์มการพิมพ์
11. ผู้จัดการดำเนินการคำสั่ง ปิดเอกสาร “การให้บริการ”	12. ระบบปิดแบบฟอร์มเอกสาร

ตาราง - 16 ข้อยกเว้นสำหรับสถานการณ์การดำเนินการของ VI "เอกสารการลงทะเบียน"

ตาราง -17 VI “สร้างรายงาน”

การพัฒนาโครงสร้างไดเร็กทอรี

ไดเรกทอรี "คู่สัญญา"ออกแบบมาเพื่อจัดเก็บข้อมูลเกี่ยวกับลูกค้าและซัพพลายเออร์

ตาราง -15 รายละเอียดไดเร็กทอรีไคลเอ็นต์

สถานะทางกฎหมายเป็นประเภทการแจงนับ ซึ่งหมายความว่าเมื่อคุณเลือกฟิลด์นี้ รายการสถานะสามสถานะจะปรากฏขึ้น: ผู้ประกอบการรายบุคคล รายบุคคล บุคคล, องค์กร.

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

ตารางที่ -16 รายละเอียดไดเรกทอรี พนักงาน

การสร้าง ไดเรกทอรี "โกดัง"- ออกแบบมาเพื่อกำหนดสถานที่จัดเก็บสินค้า ผู้ประกอบการแต่ละรายจะมีคลังสินค้าสองแห่ง: จุดซื้อขาย 1 และจุดซื้อขาย 2

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

การสร้าง ไดเรกทอรี "ระบบการตั้งชื่อ"- เพื่อพิจารณาสินค้าที่ซื้อจากซัพพลายเออร์ เราจะสร้างไดเร็กทอรี "ระบบการตั้งชื่อ"

ผลิตภัณฑ์ในไดเร็กทอรี Nomenclature จะถูกรวมเป็นกลุ่มต่างๆ ตามวัตถุประสงค์การใช้งาน ดังนั้นไดเร็กทอรีจะมีรูปแบบของลำดับชั้น "ลำดับชั้นของกลุ่มและองค์ประกอบ"

ตารางที่ -17 รายละเอียดไดเร็กทอรีระบบการตั้งชื่อ

การพัฒนาโครงสร้างทะเบียนข้อมูล “ราคาสินค้า”

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

ตารางที่ -18 โครงสร้างของข้อมูลการลงทะเบียนราคา

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

การพัฒนาโครงสร้างเอกสาร “การรับสินค้า”

เอกสาร "การรับสินค้า" มีวัตถุประสงค์เพื่อสะท้อนถึงความจริงที่ว่าองค์กรได้รับสินค้าที่ซื้อแล้ว

ตารางที่ 19 รายละเอียดเอกสาร “การรับสินค้า (ใบรับสินค้า)”

ตาราง -19 รายละเอียดของส่วนตารางของเอกสาร "การรับสินค้า"

มีการเขียนโค้ดเพื่อคำนวณค่าของคอลัมน์จำนวนโดยอัตโนมัติเมื่อค่าของคอลัมน์ปริมาณและราคาเปลี่ยนแปลง

รูปแบบของเอกสารจะมีลักษณะดังแสดงในรูปที่ 2

รูปที่ 2- แบบฟอร์มเอกสารการรับสินค้า

การพัฒนาโครงสร้างเอกสาร “การขาย”

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

ตาราง -20 รายละเอียดของเอกสาร "การขาย"

ตาราง -21 รายละเอียดของส่วนตารางของเอกสารการขาย

การพัฒนาโครงสร้างเอกสาร “การจอง”

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

ตารางที่ -20 รายละเอียดเอกสาร “การจอง”

ตาราง -21 รายละเอียดของส่วนตารางของเอกสารการจอง

การพัฒนา โครงสร้าง เอกสาร "ป้อนข้อมูล อักษรย่อ ของเหลือ"

เอกสารนี้จำเป็นในการป้อนยอดคงเหลือยกมาลงในฐานข้อมูล

โดยมีรายละเอียดคล้ายกับเอกสาร “ใบเสร็จรับเงิน”

การสร้าง รายงาน "สินค้า"

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

ในสภาพแวดล้อม 1C Enterprise 8 มีตัวสร้างรายงานที่ช่วยให้คุณพัฒนารายงานได้อย่างรวดเร็วสร้างแบบสอบถามและการออกแบบตามตาราง

การสร้าง รายงาน “ทะเบียนเอกสารการขาย”

รายงานนี้มีจุดมุ่งหมายเพื่อสร้างทะเบียนเอกสาร "การขาย" ระบบจะใช้รายงานต่างๆ ซึ่งจะคล้ายกันในโครงสร้างการสร้าง

การสร้าง บทบาท และ การนัดหมาย ของพวกเขา ผู้ใช้

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

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

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

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

- ผู้ดูแลระบบ - ระบบ 1C:Enterprise ต้องมีบทบาทที่มีสิทธิ์เต็มที่ในการทำงานกับข้อมูลความปลอดภัยของข้อมูล
- เจ้าของร้าน;
- ผู้จัดการ;
- ไอพี.

การกำหนดบทบาทให้กับผู้ใช้จะดำเนินการผ่านรายการเมนูหลัก การดูแลระบบ -> ผู้ใช้

รูปที่ 3 - การสร้างผู้ใช้ “ผู้ดูแลระบบ” ที่มีบทบาท “ผู้ดูแลระบบ”

รูปที่ 4 - รายชื่อผู้ใช้ระบบ

สิทธิ์ในการลบแบบโต้ตอบได้ถูกเอาออกสำหรับวัตถุฐานข้อมูลทั้งหมดสำหรับทุกบทบาท

การแก้ไข สั่งการ อินเตอร์เฟซ ส่วนต่างๆ และ คนงาน โต๊ะ

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

ลองเรียงลำดับคำสั่งตามลำดับความสำคัญและความถี่ในการใช้งานเป็นกลุ่มต่างๆ ดังต่อไปนี้:

- แผงนำทาง สำคัญ;
- แถบนำทาง ปกติ;
- แถบนำทาง ดู อีกด้วย;
- แผงการดำเนินการสร้างและ
- แผงการดำเนินการ

รูปที่ 5 - อินเทอร์เฟซคำสั่งของส่วน "การบัญชีวัสดุ" สำหรับผู้ใช้ที่มีบทบาท "ผู้จัดเก็บ"

รูปที่ 6 - อินเทอร์เฟซคำสั่งของส่วน "การให้บริการ" สำหรับผู้ใช้ที่มีบทบาท "ผู้จัดการ"

รูปที่ 7 - อินเทอร์เฟซคำสั่งของส่วน "องค์กร" สำหรับผู้ใช้ที่มีบทบาท "ผู้อำนวยการ"

รูปที่ 8 - อินเทอร์เฟซคำสั่งของส่วน "Retail.Electronics" สำหรับผู้ใช้ที่มีบทบาท "ผู้ดูแลระบบ"

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

รูปที่ 9 - เดสก์ท็อปสำหรับผู้ใช้ที่มีบทบาท "ผู้ดูแลร้าน"

รูปที่ 10 - เดสก์ท็อปสำหรับผู้ใช้ที่มีบทบาท "ผู้จัดการ"

เอกสารซอฟต์แวร์การค้าขายส่งอัตโนมัติ