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