ปฏิสัมพันธ์ภายในกับลูกค้าระหว่างการออกแบบ ลูกค้าและผู้รับเหมา - ความสัมพันธ์ที่เป็นพื้นฐานสำหรับความสำเร็จของโครงการ

ขั้นตอนทั่วไปของการโต้ตอบกับลูกค้ามีดังต่อไปนี้:

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

รูปแบบที่สำคัญของการโต้ตอบกับลูกค้าคือเอกสารที่พัฒนาขึ้นในระหว่างการดำเนินโครงการตามข้อกำหนดของ GOST 34 และ RUP

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

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

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

• การวิเคราะห์หัวข้อและการสร้างข้อกำหนดทางเทคนิค (ปฏิสัมพันธ์กับลูกค้า)
• การออกแบบโครงสร้างโปรแกรม
• การเข้ารหัส (ชุดรหัสโปรแกรมตามเอกสารโครงการ)
• การทดสอบและการดีบัก
• การใช้งานโปรแกรม
• โปรแกรมสนับสนุน
• การกำจัด

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

UML เป็นภาษากราฟิกสำหรับการแสดงภาพ คำอธิบายพารามิเตอร์ การออกแบบและการจัดทำเอกสารของระบบต่างๆ (โดยเฉพาะโปรแกรม) ไดอะแกรมถูกสร้างขึ้นโดยใช้เครื่องมือพิเศษของ CASE เช่น Rational Rose (http://www-01.ibm.com/software/rational/) และ Enterprise Architect (http://www.sparxsystems.com.au/) โมเดลข้อมูลเดียวสร้างขึ้นบนพื้นฐานของเทคโนโลยี UML เครื่องมือ CASE ด้านบนนี้สามารถสร้างโค้ดในภาษาเชิงวัตถุได้หลากหลาย และยังมีคุณลักษณะวิศวกรรมย้อนกลับที่มีประโยชน์มาก (วิศวกรรมย้อนกลับช่วยให้คุณสร้างแบบจำลองกราฟิกจากรหัสโปรแกรมที่มีอยู่และแสดงความคิดเห็นได้)

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

ใช้กรณีแผนภาพ

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

ไดอะแกรมคลาส (ไดอะแกรมคลาส)

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

ไดอะแกรมสถานะ (ไดอะแกรม statechart)

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

แผนภาพลำดับ

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

แผนภาพการทำงานร่วมกัน

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

แผนภาพส่วนประกอบ

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

ไดอะแกรมการปรับใช้

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

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

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

1.1. ปฏิสัมพันธ์กับลูกค้า (หน้าที่หลัก)

1.1.1. สั่งซื้อค้นหา

7.2.3.1. สำหรับข้อมูลผลิตภัณฑ์

1.1.2. งานก่อนทำสัญญากับลูกค้า

เอกสารกำกับดูแล

2.2.1.2.1. งานก่อนทำสัญญากับลูกค้า STP-1-01

ข้อกำหนดระบบการจัดการคุณภาพ ISO9000:2000 ข้อ 7

7.2.1.1. ข้อกำหนดของลูกค้าสำหรับผลิตภัณฑ์ รวมถึงข้อกำหนดเกี่ยวกับความพร้อมจำหน่าย การจัดส่ง และการบำรุงรักษา

7.2.2.4. การกำหนดความสามารถในการบรรลุการปฏิบัติตามข้อกำหนดบางประการ

// การวิเคราะห์ข้อกำหนดของผลิตภัณฑ์ / กระบวนการที่เกี่ยวข้องกับผู้บริโภค / การขายผลิตภัณฑ์

1.1.3. การก่อตัวของข้อกำหนดในการอ้างอิง

เอกสารกำกับดูแล

2.2.1.2.2. ขั้นตอนการวิเคราะห์และสรุปสัญญา STP-2-01 // มาตรฐานของ Enterprise Enterprise Ellat (STP) / เอกสารระบบการจัดการคุณภาพ / เอกสารกำกับดูแลภายใน / ข้อบังคับ

ข้อกำหนดระบบการจัดการคุณภาพ ISO9000:2000 ข้อ 7

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

7.2.1.3. ภาระผูกพันที่เกี่ยวข้องกับผลิตภัณฑ์ รวมถึงข้อกำหนดบังคับและข้อกำหนดทางกฎหมาย // คำจำกัดความความต้องการของลูกค้า / กระบวนการที่เกี่ยวข้องกับลูกค้า / การขายผลิตภัณฑ์

// การวิเคราะห์ข้อกำหนดของผลิตภัณฑ์ / กระบวนการที่เกี่ยวข้องกับผู้บริโภค / การขายผลิตภัณฑ์

7.2.2.2. การยืนยันข้อกำหนดของผู้บริโภคก่อนการยอมรับ หากผู้บริโภคไม่ได้ระบุข้อกำหนดเป็นลายลักษณ์อักษร // การวิเคราะห์ข้อกำหนดของผลิตภัณฑ์ / กระบวนการที่เกี่ยวข้องกับผู้บริโภค / การขายผลิตภัณฑ์

7.2.2.3. ชี้แจงการเปลี่ยนแปลงข้อกำหนดของสัญญาหรือคำสั่งที่แตกต่างจากที่ส่งไปก่อนหน้านี้ (เช่น โดยการเสนอราคาหรือลิงก์) // การวิเคราะห์ข้อกำหนดของผลิตภัณฑ์ / กระบวนการที่เกี่ยวข้องกับผู้บริโภค / การขายผลิตภัณฑ์

7.3.1.1. การกำหนดขั้นตอนของกระบวนการออกแบบและ/หรือการพัฒนา

7.3.2.2. ข้อกำหนดทางกฎหมายและข้อบังคับที่บังคับใช้

7.3.2.3. ข้อมูลที่เกี่ยวข้องที่ได้มาจากการพัฒนาก่อนหน้านี้ที่คล้ายคลึงกัน // ป้อนข้อมูลเพื่อการออกแบบและพัฒนา / การออกแบบและพัฒนา / การขายผลิตภัณฑ์

7.3.2.4. ข้อกำหนดอื่นๆ ที่สำคัญสำหรับการออกแบบและพัฒนา // ป้อนข้อมูลเพื่อการออกแบบและพัฒนา / การออกแบบและพัฒนา / การขายผลิตภัณฑ์

7.3.4.1. การประเมินความสามารถในการตอบสนองความต้องการ

1.1.4. บทสรุปของข้อตกลง

เอกสารกำกับดูแล

2.2.1.2.3. ระเบียบการทำงานตามสัญญากับลูกค้า (STP-3-01) // Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

1.1.5. การติดตามการปฏิบัติตามภาระผูกพันตามสัญญา

เอกสารกำกับดูแล

2.2.1.2.3.2. ขั้นตอนการวิเคราะห์การเปลี่ยนแปลงและการเปลี่ยนแปลงเอกสารสัญญา // ข้อบังคับเกี่ยวกับงานตามสัญญากับลูกค้า (STP-3-01) / Enterprise Standards Ellat (STP) / เอกสารของระบบการจัดการคุณภาพ / เอกสารกำกับดูแลภายใน / ข้อบังคับ

2.2.1.2.4.1. ขั้นตอนการจัดการข้อร้องเรียนและข้อเรียกร้องของลูกค้า

2.2.1.2.4.2. ขั้นตอนการกำจัดความคิดเห็นของลูกค้า // ระเบียบว่าด้วยการดำเนินการแก้ไขและป้องกัน (STP-4-01) / Ellat Enterprise Standards (STP) / เอกสารระบบการจัดการคุณภาพ / เอกสารกำกับดูแลภายใน / ข้อบังคับ

ข้อกำหนดระบบการจัดการคุณภาพ ISO9000:2000 ข้อ 7

7.2.3.2. การประมวลผลคำขอ สัญญา คำสั่งซื้อ รวมถึงการเปลี่ยนแปลง // การสื่อสารกับผู้บริโภค / กระบวนการที่เกี่ยวข้องกับผู้บริโภค / การขายผลิตภัณฑ์

1.2. การจัดตารางงานโครงการ (หน้าที่หลัก)

1.2.1. ชี้แจงองค์ประกอบของความซับซ้อนและขอบเขตของการพัฒนา

เอกสารกำกับดูแล

// Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

ข้อกำหนดระบบการจัดการคุณภาพ ISO9000:2000 ข้อ 7

7.2.2.1. คำจำกัดความของข้อกำหนดของผลิตภัณฑ์ // การวิเคราะห์ข้อกำหนดของผลิตภัณฑ์ / กระบวนการที่เกี่ยวข้องกับผู้บริโภค / การขายผลิตภัณฑ์

1.2.2. การวางแผนประกันคุณภาพโครงการ

เอกสารกำกับดูแล

2.2.1.2.5. องค์ประกอบและขั้นตอนการพัฒนาโครงการประกันคุณภาพโครงการ (STP-5-01) // Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

ข้อกำหนดระบบการจัดการคุณภาพ ISO9000:2000 ข้อ 7

• 7.1.1. การกำหนดเป้าหมายคุณภาพสำหรับผลิตภัณฑ์ โครงการ หรือสัญญา

7.1.3. คำจำกัดความของกิจกรรมทบทวนและอนุมัติและเกณฑ์การยอมรับ // การวางแผนกระบวนการขาย / การขายผลิตภัณฑ์

7.2.2.5. แก้ไขผลการวิเคราะห์และการดำเนินการติดตามผลในภายหลัง (ดูข้อ 5.5.7) // การวิเคราะห์ข้อกำหนดของผลิตภัณฑ์ / กระบวนการที่เกี่ยวข้องกับผู้บริโภค / การขายผลิตภัณฑ์

7.3.1.2. นิยามของกิจกรรมการทบทวน ทวนสอบ และอนุมัติสำหรับแต่ละขั้นตอนการออกแบบและ/หรือการพัฒนา // การวางแผนการออกแบบและพัฒนา / การออกแบบและพัฒนา / การขายผลิตภัณฑ์

1.2.3. การก่อตัวของข้อกำหนดทางเทคนิคส่วนตัวสำหรับการพัฒนาส่วนประกอบของคอมเพล็กซ์

เอกสารกำกับดูแล

2.2.1.2.7. เทคโนโลยีการดำเนินโครงการ ขั้นตอนและลำดับการทำงาน (STP-7-01) // Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

1.2.4. การวางแผนโครงการ

เอกสารกำกับดูแล

// Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

ข้อกำหนดระบบการจัดการคุณภาพ ISO9000:2000 ข้อ 7

7.1.2. การกำหนดความจำเป็นในการจัดตั้งกระบวนการและเอกสาร การจัดหาทรัพยากรและโครงสร้างพื้นฐานเฉพาะสำหรับผลิตภัณฑ์ // การวางแผนกระบวนการขาย / การขายผลิตภัณฑ์

1.2.5. ประสานงานและควบคุมการปฏิบัติงาน

เอกสารกำกับดูแล

2.2.1.2.4.3. ขั้นตอนการดำเนินการแก้ไข // ระเบียบว่าด้วยการดำเนินการแก้ไขและป้องกัน (STP-4-01) / Ellat Enterprise Enterprise Standards (STP) / เอกสารระบบการจัดการคุณภาพ / เอกสารกำกับดูแลภายใน / ข้อบังคับ

2.2.1.2.6. ระเบียบว่าด้วยการวางแผนงาน (STP-6-01) // Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

ข้อกำหนดระบบการจัดการคุณภาพ ISO9000:2000 ข้อ 7

7.3.4.2. การระบุปัญหาและการพัฒนาข้อเสนอสำหรับการดำเนินการติดตามผล // การวิเคราะห์การออกแบบและการพัฒนา / การออกแบบและการพัฒนา / PRODUCT MAILING

7.3.7. การออกแบบและพัฒนาการจัดการการเปลี่ยนแปลง

1.3. การพัฒนาการออกแบบ ซอฟต์แวร์ และเอกสารการปฏิบัติงาน (หน้าที่หลัก)

1.3.1. การพัฒนาเอกสารสำหรับฮาร์ดแวร์ของคอมเพล็กซ์

เอกสารกำกับดูแล

2.2.1.2.7. เทคโนโลยีการดำเนินโครงการ ขั้นตอนและลำดับการทำงาน (STP-7-01) // Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

2.3.3.3. แผนงานฝ่ายพัฒนาและผลิตฮาร์ดแวร์

1.3.2. การพัฒนาส่วนซอฟต์แวร์ของคอมเพล็กซ์

เอกสารกำกับดูแล

2.2.1.2.7. เทคโนโลยีการดำเนินโครงการ ขั้นตอนและลำดับการทำงาน (STP-7-01) // Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

2.3.3.4. แผนงานฝ่ายพัฒนาและผลิตซอฟต์แวร์ // โปรแกรมและแผนปฏิบัติการ / เอกสารองค์กรและการบริหารของบริษัท / ระเบียบข้อบังคับ

1.3.4. การวิเคราะห์และการอนุมัติผลการออกแบบ

เอกสารกำกับดูแล

2.2.1.2.7. เทคโนโลยีการดำเนินโครงการ ขั้นตอนและลำดับการทำงาน (STP-7-01) // Enterprise Standards Ellat (STP) / เอกสารระบบบริหารคุณภาพ / เอกสารกำกับดูแลภายใน / Regulations

ข้อกำหนดระบบการจัดการคุณภาพ ISO9000:2000 ข้อ 7

7.3.3.1. สอดคล้องกับข้อกำหนดอินพุตของการออกแบบและพัฒนา

7.3.3.2. ให้ข้อมูลที่เหมาะสมสำหรับการดำเนินงานด้านการผลิตและการบริการ (ดู 7.5) // การออกแบบและพัฒนาผลลัพธ์ / การออกแบบและพัฒนา / การส่งผลิตภัณฑ์

7.3.3.4. กำหนดลักษณะของผลิตภัณฑ์ที่จำเป็นสำหรับการใช้งานอย่างปลอดภัยและเหมาะสม // การออกแบบและพัฒนาผลลัพธ์ / การออกแบบและพัฒนา / การส่งผลิตภัณฑ์

7.3.5.1. ความสอดคล้องของข้อมูลเอาต์พุตกับข้อกำหนดอินพุต // การตรวจสอบการออกแบบและการพัฒนา / การออกแบบและการพัฒนา / การขายผลิตภัณฑ์

7.3.6. อนุมัติผลการออกแบบและพัฒนา // การออกแบบและพัฒนา / การขายผลิตภัณฑ์

• การศึกษา การพัฒนา การฝึกอบรม

คำสำคัญ:

1 -1

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

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

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

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

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

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

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

*ขั้นตอนตั้งแต่โทรไปเซ็นสัญญามักใช้เวลาไม่เกิน 1-2 วัน

หลังจากลงนามในสัญญาและแลกเปลี่ยนสำเนาที่สแกนทางอิเล็กทรอนิกส์แล้ว ลูกค้าจะชำระเงินล่วงหน้า ซึ่งโดยปกติแล้วจะคิดเป็น 50% ของจำนวนเงินในสัญญาทั้งหมด

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

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

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

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

* การจัดหาวัสดุที่จำเป็นให้กับลูกค้าเป็นสิ่งสำคัญเนื่องจาก:

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

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

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

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

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

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

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

ทันทีที่งานเสร็จสิ้นและการทดสอบไซต์บนโดเมนทางเทคนิคเสร็จสิ้น ขั้นตอนการส่งมอบ. ในส่วนของลูกค้าจะมีการตรวจสอบการปฏิบัติตามข้อกำหนดของ TOR และกระบวนการทำงานทั้งหมดของโครงการอินเทอร์เน็ต
หลังจากที่ลูกค้าตัดสินใจเกี่ยวกับการปฏิบัติตามข้อกำหนดของ TOR อย่างสมบูรณ์แล้ว ไซต์จะถูกโอนไปยังลูกค้าและโครงการจะถูกเผยแพร่บนโฮสต์

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

หลังจากลงนามในใบรับรองการยอมรับลูกค้าตามสัญญาจะชำระค่าใช้จ่ายที่เหลือของงาน

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

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

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

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

โครงการ:	การกระจายข้อความค้นหาไปยังแคตตาล็อกอิเล็กทรอนิกส์ตามดัชนีการค้นหาและคำค้นหา
ขอบเขตโครงการ:	13.02.2006 - 05.06.2006
ลูกค้า:	ห้องสมุดวิทยาศาสตร์ของมหาวิทยาลัยแห่งรัฐ Petrozavodsk
รับผิดชอบ:	Gorshkova Galina Anatolyevna หัวหน้าแผนกการประมวลผลเอกสารคอมพิวเตอร์และการสร้างแคตตาล็อก อีเมล จดหมาย: . ทาส. โทร.: 719602. ห้องสมุด: แท็กซี่. 102. Guryev Dmitry Borisovich โปรแกรมเมอร์ชั้นนำของ RCNIT อีเมล จดหมาย: . ทาส. โทร.: 784775 ศูนย์อินเตอร์เน็ต.
ผู้สอน:	คูลาคอฟ คิริล อเล็กซานโดรวิช อีเมล: . โทรศัพท์สำนักงาน: 711015 ห้อง 215
ข้อมูลสำหรับผู้สอน:	กลุ่มหมายเลข 13
เอกสารที่เกี่ยวข้อง:	ภาพรวมโครงการ แผนโครงการ ตารางงาน (แผนภูมิแกนต์) ข้อกำหนด ข้อมูลจำเพาะ การออกแบบ การทดสอบการดำเนินการ เอกสารการทดสอบ เอกสาร การมีส่วนร่วมกับลูกค้า นักพัฒนาสัมพันธ์ รายงาน ความคืบหน้าการพัฒนา อภิธานศัพท์ คู่มือผู้ใช้

พบกับลูกค้าครั้งแรก

ในการประชุมครั้งแรก ได้มีการแนะนำทีมพัฒนาให้กับลูกค้า ในทางกลับกัน ลูกค้าก็พูดถึงห้องสมุดวิทยาศาสตร์ของ PetrSU

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

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

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

การประชุมครั้งที่สองกับลูกค้า

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

Guryev Dmitry Borisovich แนะนำให้เรารู้จักรายละเอียดเพิ่มเติมเกี่ยวกับงานในไคลเอนต์ Oracle SQL*Plus DBMS ทีมงานได้ทำความคุ้นเคยกับงานของแคตตาล็อกอิเล็กทรอนิกส์

ระบบ "Foliant" ทำงานตามมาตรฐาน RusMark ซึ่งมีประมาณ 99 ฟิลด์ แต่ละไลบรารีที่ทำงานกับ AIBS "Foliant" จะเลือกฟิลด์และฟิลด์ย่อยที่จะใช้ มี GOST พิเศษที่อธิบายกฎสำหรับการจัดเก็บข้อมูลไลบรารี เนื่องจากมีฟิลด์จำนวนมาก เราจึงสร้างระบบดัชนีการค้นหา มีบริการและดัชนีสาธารณะ

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

การประชุมครั้งที่สามกับลูกค้า

ลูกค้าได้ระบุข้อกำหนดที่ชัดเจนเป็นลายลักษณ์อักษรแก่เรา

ลูกค้ามีความสนใจในสถิติต่อไปนี้:

1. จำนวนคำขอไปยังแคตตาล็อกอิเล็กทรอนิกส์

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

รายการคำขอโดย ถึงแต่ละคนดัชนีการค้นหาที่ผลการค้นหาเป็นโมฆะ

รายการคำขอที่เกิดขึ้นบ่อยครั้ง

การวิเคราะห์การดำเนินการตามคำขอในช่วงเวลาหนึ่ง รายงานควรมีสถิติต่อไปนี้:

• จำนวนคำขอ
• จำนวนคำขอค้นหา
• จำนวนคำถามที่ซับซ้อน
• จำนวนการตอบกลับที่ประสบความสำเร็จ
• จำนวนการตอบสนองที่เป็นโมฆะ
ใช้ดัชนีการค้นหาต่อไปนี้:
• ผู้เขียน
• ผู้เขียน rev. แยง.
• ประเภทของเอกสาร
• ส่วนทางภูมิศาสตร์
• ป้อนวันที่
• วันที่ตีพิมพ์
• ชื่อ.

การพบปะกับลูกค้าครั้งที่สี่

ผู้เชี่ยวชาญจากลูกค้า Guryev D.B. อธิบายความซับซ้อนของการติดตั้งและกำหนดค่ายูทิลิตี้ SQL*Plus วิธีแก้ปัญหาของการเปิดตัวโปรแกรมคือการติดตั้งแพ็คเกจ SQL * Net รวมถึง Gryev D.B. ให้ชื่อที่แน่นอนของตารางสำหรับนักพัฒนา และยังเพิ่มตารางอื่นในการกำจัดของทีม ผู้เชี่ยวชาญได้ศึกษาเอกสารสถาปัตยกรรมและเสนอให้นำสถาปัตยกรรมทุกประเภทไปปฏิบัติจริง และเลือกสถาปัตยกรรมที่เหมาะสมที่สุด ในเวลาเดียวกัน เป็นที่พึงปรารถนาที่จะไม่สร้างตารางบันทึกขึ้นใหม่และแก้ปัญหาเฉพาะให้มากที่สุดเท่าที่จะทำได้ สรุปข้อมูลจากตารางบันทึกเพื่อใช้งานต่อไปในสถิติท้องถิ่นต่างๆ

ลูกค้า Gorshkova G.A. ทำความคุ้นเคยกับเอกสารข้อกำหนดโดยอนุมัติแล้ว

การพบปะกับลูกค้าครั้งที่ห้า

Guryev Dmitry Borisovich ผู้เชี่ยวชาญจากฝั่งลูกค้า ได้รับเชิญให้ติดตั้งซอฟต์แวร์ที่จำเป็นสำหรับการทำงานกับ "Oracle" DBMS บนเซิร์ฟเวอร์การฝึกอบรมของ PetrSU Vadim Anatolyevich Ponomarev ซึ่งมีสิทธิ์เข้าถึงระดับผู้ดูแลระบบในเซิร์ฟเวอร์ PetrSU ก็มีส่วนร่วมในกระบวนการนี้จากด้านข้างของมหาวิทยาลัยด้วย