บทที่ 12 การเขียนโปรแกรม
สำหรับโปรแกรมเมอร์แล้ว การเขียนโปรแกรมอาจไม่ใช่เรื่องยาก แต่สิ่งที่ยากกว่าคือการที่โปรแกรมเมอร์จะต้องคำนึงถึงหลักการต่างๆ ที่จะทำให้ผลิตภัณฑ์ซอฟต์แวร์มีคุณภาพคามหลักของวิศวกรรมซอฟต์แวร์
12.1 มาตรฐานการเขียนโปรแกรม
ปัจจุบันความซับซ้อนของงานแต่และส่วนประสานของซอฟต์แวร์ โปรแกรมเมอร์ต้องาสร้างซอฟต์แวร์ในลักษณะเป็นชิ้นส่วน แล้วจึงนำแต่ละชิ้นส่วนมาประกอบกันซึ่งต้องอาศัยโปรแกรมเมอร์จำนวนมาก ทั้งเครื่องมือและเทคนิคต่างๆ มากมาย
เพื่อให้การประกอบซอฟต์แวร์ การจัดทำเอกสาร และการบำรุงรักษาโปรแกรมที่ถูกเขียนขึ้นมาโดยโปรแกรมเมอร์จำนวนมากมายนั้นง่ายขึ้น จำเป็นต้องกำหนดมาตรฐาน และกระบวนการทำงาน เพื่อควบคุมการดำเนินงานของโปรแกรมเมอร์ ให้สอดคล้อง มีระเบียบ และเป็นไปในทิศทางเดียวกัน เพื่อให้ทราบและเข้าใจในมาตรฐานเดียวกัน ซึ่งมีประโยชน์ดังนี้
1. ประโยชน์ต่อโปรแกรมเมอร์
มาตรฐานและกระบวนการ จะช่วยให้โปรแกรมเมอร์จัดลำดับความคิดได้อย่างเป็นระบบขึ้น หลีกเลื่องข้อผิดพลาดในเบื้องต้นได้ เช่น การกำหนดชื่อตัวแปร ชื่อฐานข้อมูล ที่ไม่สอดคล้องกับทีมงานอื่น
2. ประโยชน์ต่อบุคคลอื่น
โปรแกรมที่เขียนเสร็จเรียบร้อยแล้ว จะถูกนำไปทดสอบ ประเมิน และประกอบให้บุคคลอื่น ซึ่งอาจเป็นโปรแกรมเมอร์ทีมอื่นที่ทำหน้าที่ทดสอบและประกอบซอฟต์แวร์ ดังนั้น โปรแกรมเมอร์จะต้องจัดโครงสร้าง รูปแบบ และจัดทำเอกสารของโปรแกรมให้โปรแกรมเมอร์คนอื่นเข้าใจได้ง่าย ว่าแต่ละส่วนของโปรแกรมนั้นมีหน้าที่อะไรและทำงานอย่างไร โดยอาจเขียนบันทึกย่อในตัวโปรแกรม เพื่อบอกรายละเอียดอื่นที่เกี่ยวข้อง
12.2 หลักปฏิบัติในการเขียนโปรแกรม
12.2.1 โครงสร้างควบคุมการทำงานของโปรแกรม ( Control Structure )
การควบคุมการทำงานของโปรแกรม ล้วนมีความสำคัญต่อการเขียนโปรแกรมทั้งสิ้น เนื่องจากการควบคุมการทำงานเป็นส่วนสะท้อนให้เห็นถึงโครงสร้างควบคุมการทำงานของโปรแกรม เพื่อความสะดวกในการอ่านโค้ด ให้เข้าใจในการทำงานของโปรแกรม แบ่งออกเป็น 2 ทางคือ
1. เขียนโค้ดจากบนลงล่าง การเขียนโค้ดให้อ่านจากบนลงล่าง คือ การเขียนในลักษณะที่เป็นไปตามคำสั่งควบคุมของโปรแกรม คือ จะไม่มีการเขียนแบบกระโดดไปมา
ตัวอย่างที่ 12.2
2. แบ่งส่วนการทำงานออกเป็นโมดูล แต่ละโมดูลรับผิดชอบการประมวลผลข้อมูลตามหน้าที่ที่แตกต่างกันออกไปโมดูลละ 1 หน้าที่
12.2.2 อัลกอลิธึม (Algorithm)
อัลกอลิธึม เป็นลำดับขั้นตอนการทำงานหรือการแก้ปัญหางานใดๆ จะแสดงให้เห็นกรแก้ไขปัญหาแต่ละงานอย่างเป็นลำดับขั้นตอน หน้าที่ของโปรแกรมเมอร์ในขั้นตอนนี้คือ นำอัลกอลิธึมที่ได้จากการออกแบบมาเขียนเป็นโค้ดโปรแกรม ภายใต้โปรแกรมมิ่ง แพลตฟอร์ม และฮาร์ดแวร์ที่กำหนด หลักที่ต้องคำนึงเมื่อแปลงอัลกอลิธึมคือ ต้องเขียนโค้ดให้มีประสิทธิภาพ และ ประสิทธิผล ซึ่งหมายถึง คุณภาพของโค้ด
12.2.3 โครงสร้างข้อมูล (Data Structure)
โครงสร้างข้อมูลในที่นี้หมายถึง ลักษณะของข้อมูลที่จะถูกประมวลผลในโปรแกรม เนื่องจากพบว่าบ่อยครั้งที่พบว่าข้อมูลที่รับเข้ามาเป็นตัวกำหนดโครงสร้างการทำงานของโปรแกรม ดังนั้น จึงมีข้อแนะนำในกรเขียนโปรแกรมตามโครงสร้างข้อมูล
1. เขียนโปรแกรมให้เรียบง่ายที่สุด กล่าวคือ ไม่ว่าในขั้นตอนออกแบบจะกำหนดข้อมูลมาในลักษณะใด ให้นำมาปรับใหม่เพื่อที่ให้สมารถเขียนโปรแกรมได้ง่ายขึ้น
ตารางหน้า 215
จากข้อมูลดังกล่าว หากต้องเขียนโปรแกรมเพื่อคำนวณหาภาษีเงินได้บุคคลธรรมดา โดยให้รับข้อมูลเงินได้สุทธิต่อปีเข้ามาเปรียบเทียบ สมมติ เงินได้สิทธิ 650,000 บาท/ปี สำหรับ 100,000 บาทแรกจะได้รับการยกเว้น (เหลือ 550,000) ให้คิดที่เงินได้ขั้นถัดมาคือขั้นที่ 2 (100,001 ? 500,000) ซึ่งก็คือ 400,000 ต้องเสียภาษีร้อยละ 10 คือ 40,000 บาท รวมกับภาษีอีกร้อยละ 20 สำหรับส่วนที่เหลือ 150,000 บาท ซึ่งคิดเป็นภาษได้ 30,000 บาท รวมภาษีทั้งสิ้น 40,000 + 30,000 = 70,000 บาท เมื่อเข้าใจการคำนวณแล้ว เพื่อให้การเขียนโปรแกรมง่ายขึ้น สามารถจัดโครงสร้างข้อมูลในตารางใหม่ได้ดังนี้
ตารางหน้า 215
จากตารางข้างต้น ข้อมูลที่เพิ่มเข้ามา ได้แก่ เงินได้สูงสุดในแต่ละขั้น ภาษีในแต่ละขั้น และเงินภาษีสะสมจะทำให้การเขียนเงื่อนไขในโปรแกรมง่ายขึ้น โดยสามารถนำค่าดังกล่าวมาใช้คำนวณได้เลย ดังตัวอย่างที่นำค่าภาษาในแต่ละขั้นมาใช้ อย่างไรก็ตาม ผู้อ่านสามารถเขียนเงื่อนไขได้อีกหลายรูปแบบ โดยอาจนำค่าเงินได้สูงสุดในแต่ละขั้น มาใช้ร่วมกันกับเงินภาษีสะสมก็ได้
ตัวอย่างที่ 12.3
2. ใช้โครงสร้างข้อมูลเป็นตัวกำหนดโครงสร้างโปรแกรม จากหลักปฏิบัติในข้อ 1 เป็นการกำหนดโครงสร้างข้อมูลใหม่เพื่อให้การเขียนโปรแกรมเรียบง่ายขึ้น ซึ่งจะเห็นว่าโครงสร้างข้อมูลนั้นมีอิทธิพลต่อการกำหนดโครงสร้างโปรแกรม นอกจากนี้โครงสร้างข้อมูลยังเป็นตัวกำหนดภาษาโปรแกรมมิ่งที่จะใช้งาน
12.2.4 หลักปฏิบัติอื่นๆ
นอกจากหลักปฏิบัติที่เกี่ยวข้องกับองค์ประกอบทั้ง 3 ส่วนของโปรแกรมตามที่กล่าวมาข้างต้นแล้ว ยังมีหลักปฏิบัติอื่นๆ ที่จะช่วยให้การเขียนโปรแกรมมีคุณภาพขึ้น ดังนี้
1. แยกฟังก์ชันหรือโมดูลและแสดงผลข้อมูลออกมาต่างหากจากโค้ดส่วนอื่นของโปรแกรม ทั้งนี้เพื่อง่ายต่อการแก้ไขปรับปรุง และลดความซ้ำซ้อนในกรเขียนโค้ด
2. ใช้วิธีการเขียนรหัสเทียมเพื่อทดลองออกแบบอัลกอลิธึมของโปรแกรมก่อนลงมือเขียนจริง เพื่อลดความผิดพลาดในการเขียนโค้ด
3. โดยทั่วไป เมื่อเริ่มต้นเขียนโค้ดโปรแกรม โปรแกรมเมอร์บางส่วนจะใช้วิธีเขียนโค้ดเพื่อให้ใช้งานได้คร่าวๆ แล้วจึงมาเก็บรายละเอียดเพิ่มเติมหลังจากทดสอบผลลัพธ์แล้วว่าถูกต้อง หากพบข้อผิดพลาดก็จะแก้ไขก่อน จะช่วยให้แก้ไขข้อผิดพลาดได้ตรงจุดมากขึ้น
4. สำเร็จประเด็นเรื่องการนำโปรแกรมกลับมาใช้ซ้ำ หรือ Reuse นั้น หากกล่าวในแง่ของผู้ที่เกี่ยวข้อง จะมี 2 ฝ่ายคือ ผู้ผลิตคอมโพเน้นท์ให้สามารถใช้ซ้ำได้ และลูกค้าผู้นำคอมโพเน้นท์มาใช้ซ้ำ
Consumer Reuse กรณีลูกค้าที่กำลังพิจารณาเลือกคอมโพเน้นท์มาใช้ซ้ำ มีหลักการพิจารณาดังนี้
1. คอมโพเน้นท์ที่กำลังพิจารณามีฟังก์ชันหรือข้อมูลตามที่เราต้องการหรือไม่
2. หากต้องการดัดแปลงคอมโพเน้นท์ การดัดแปลงนั้นจะคุ้มค่าหรือไม่เมื่อเทียบกับการสร้างขึ้นมาใหม่
3. คอมโพเน้นท์ดังกล่าวมีเอกสารประกอบมาให้อย่างครบถ้วนสมบูรณ์หรือไม่ หากมีจะช่วยให้โปรแกรมเมอร์ทำความเข้าใจในโค้ดของคอมโพเน้นท์ได้ง่ายขึ้น
4. คอมโพเน้นท์มีข้อมูลชุดทดสอบที่สมบูรณ์มาให้ด้วยหรือไม่ หากมีจะทำให้มั่นใจว่าคอมโพเน้นท์มีข้อผิดพลาดน้อย
Producer Reuse
กรณีที่เป็นผู้ผลิตคอมโพเน้น มีหลักการผลิตที่ต้องคำนึงถึง ดังนี้
1. สร้างคอมโพเน้นท์ให้เป็นกลางมากที่สุด โดยกำหนดชื่อตัวแปรหรือเงื่อนไขให้สอดคล้องกับระบบงานที่คอมโพเน้นต้องรับผิดชอบ
2. กำหนด Interface ของคอมโพเน้นท์ให้ชัดเจนและสมบูรณ์ที่สุด (Well-defined Interface)
3. ควรระบุข้อผิดพลาดที่อาจเกิดขึ้นและวิธีแก้ไขไว้ด้วย
4. ชื่อตัวแปรควรสื่อความหมายชัดเจน และสามารถจำแนกความแตกต่างได้ง่าย
5. ควรจัดทำเอกสารแสดงโครงสร้างของข้อมูลและอัลกอริธึม
6. จัดเก็บส่วนติดต่อระหว่างคอมโพเน้นท์กับส่วนตอบสนองต่อความผิดพลาดไว้ต่างหาก เพื่อให้แก้ไขง่ายขึ้น
12.3 การจัดทำเอกสารโปรแกรม
การจัดทำเอกสารประกอบโปรแกรม เป็นส่วนที่จะช่วยให้บุคคลอื่นสามารถเข้าใจหน้าที่ วัตถุประสงค์ และการทำงานของโปรแกรมได้ง่ายขึ้น เนื่องจากความจำเป็นในการทดสอบ ประเมิน และประกอบรวมโปรแกรมเข้ากับซอฟต์แวร์ โปรแกรมเมอร์จึงต้องจัดทำเอกสารประกอบโปรแกรมให้มีรายละเอียดที่ชัดเจนและสมบูรณ์ โดยแบ่งออกเป็น 2 ประเภทคือ
12.3.1 การจัดทำเอกสารภายใน (Internal Documentation)
คือเอกสารที่แสดงรายละเอียดโค้ดทั้งหมดของซอฟต์แวร์ ซึ่งนอกจากส่วนที่เป็นโค้ดแล้ว ยังรวมถึงหมายเหตุโปรแกรมด้วย ในที่นี้จะกล่าวถึงหลักในการเขียนหมายเหตุโปรแกรมและส่วนอื่นๆ ที่จำเป็นดังนี้
1. Header Comment Block คือการเขียนหมายเหตุไว้ที่ส่วนหัวของโปรแกรมหรือคอมโพเน้นท์ลงบนเอกสารประกอบโปรแกรม เป็นส่วนแสดงที่มา หน้าที่ และการใช้งานโปรแกรม
2. หมายเหตุส่วนอื่นๆของโปรแกรม คือ การเขียนหมายเหตุกำกับในแต่ละส่วนการทำงานของโปรแกรม โดยต้องเขียนรายละเอียดเพิ่มเติมที่จะช่วยให้บุคคลอื่นสามารถเข้าใจง่ายขึ้น
3. ตั้งชื่อตัวแปรให้สื่อความหมายที่ชัดเจน ชื่อ Label และชื่อตัวแปรควรกำหนดให้สื่อความหมายได้อย่างชัดเจนสามารถจำแนกความแตกต่างๆได้ และไม่ควรตั้งชื่อซ้ำ
4. จัดรูปแบบโค้ดและหมายเหตุให้ง่ายขึ้น การจัดรูปแบบหรือตกแต่งข้อความโค้ดจะช่วยให้อ่านหมายเหตุได้ง่ายขึ้น ไม่ปะปนกับประโยคคำสั่งของโค้ด
5. จัดทำเอกสารประกอบการใช้งานข้อมูล นอกจากรายละเอียดต่างๆแล้ว ส่วนการกำหนดชนิดข้อมูลให้กับตัวแปรหรือการจัดโครงสร้างข้อมูล และเรียกใช้ข้อมูล ก็เป็นอีกส่วนหนึ่งที่ต้องให้ความสำคัญ ดังนั้น โปรแกรมเมอร์จึงควรเพิ่มเติมรายละเอียดดังกล่าวในเอกสารด้วย
12.3.2 การจัดทำเอกสารภายนอก (External Documentation)
คือเอกสารที่แสดงรายละเอียดส่วนอื่นๆ นอกเหนือจากโค้ดของโปรแกรมเป็นเอกสารที่โปรแกรมเมอร์สามารถอธิบายรายละเอียดอื่นๆ เพิ่มเติมจากส่วนหมายเหตุโปรแกรมได้ นอกจากในส่วน Header comment Block ของเอกสารภายในนั้น
นอกจากนี้ ในเอกสารภายนอกควรแนบแผนภาพหรือแบบจำลองที่จะแสดงให้เห็นโครงสร้างของโปรแกรมหรือคอมโพเน้นท์ การรับ-ส่งข้อมูลระหว่างคอมโพเน้นท์ ความสัมพันธ์ของคอมโพเน้นท์ทั้งหมด ตลอดจนการสืบทอดคลาสของระบบด้วย สรุปส่วนประกอบของเอกสารภายนอก มีดังนี้
1. อธิบายปัญหา ส่วนแรกของเอกสารควรอธิบายปัญหา ซึ่งเป็นที่มาที่ต้องทำให้เขียนโปรแกรม หรือคอมโพเน้นท์เพื่อแก้ไขปัญหานั้น โดยกรอธิบายปัญหาคร่าวๆ
2. อธิบายอัลกอริธึม เป็นการอธิบายอัลกอริธึมที่ใช้แก้ปัญหางานที่คอมโพเน้นท์รับผิดชอบ รวมถึงสูตรคำนวณที่ใช้ เงื่อนไขและขอบเขตในการแก้ปัญหา ตลอดจนแหล่งที่มาของข้อมูล
3. อธิบายข้อมูล เป็นการอธิบายให้เห็นทิศทางการรับ ? ส่งข้อมูลระหว่างคอมโพเน้นท์หรือระหว่างกระบวนการ ดังนั้นเอกสารในการควบคุมควรแนบภาพกระแสข้อมูล DFD และพจนานุกรมข้อมูล ไว้ด้วย สำหรับระบบที่ใช้แนวทางเชิงวัตถุ ให้แนบแผนภาพ Class Diagram ที่แสดงความสัมพันธ์ระหว่างคลาสด้วย
12.4 กระบวนการเขียนโปรแกรม
โปรแกรมที่มีคุณภาพ ไม่ได้มาจากการออกแบบที่มีคุณภาพเพียงปัจจัยเดียว หากแต่ยังมีปัจจัยอื่นเข้ามาเกี่ยวข้องด้วย นั่นคือ ทักษะ ประสบการณ์ และความเฉลียวฉลาด ที่เกิดจากการมีจินตนาการและกระบวนการแก้ปัญหาที่ดีของโปรแกรมเมอร์ โดยแบ่งเป็น 4 ขั้นตอนดังนี้
1. ทำความเข้าใจปัญหา เป็นการแบ่งปัญหาออกเป็นส่วนย่อย แล้ววิเคราะห์ในแต่ละส่วนเพื่อให้เกิดความเข้าใจในสิ่งที่เกิดขึ้น
2. วางแผนแก้ปัญหา เป็นการออกแบบวิธีแก้ไขปัญหาที่ผ่านการวิเคราะห์มาแล้ว โดยอธิบายพิจารณาส่วนที่เกี่ยวข้อง กับปัญหา
3. ดำเนินการตามแผน เมื่อวางแผนแก้ปัญหาเรียบร้อยแล้ว ขั้นต่อมาคือ การดำเนินงานตามแผนที่กำหนดไว้
4. ทบทวน เป็นการย้อนกลับไปพิจารณาถึงสิ่งที่ดำเนินการแก้ไขปัญหาในแต่ละส่วน ในขณะเดียวกันจะต้องประเมินวิธีแก้ไขปัญหานั้นด้วยว่าเหมาะสม หรือถูกต้องที่สุดหรือไม่
วันจันทร์ที่ 22 ตุลาคม พ.ศ. 2555
บทที่ 11 การออกแบบส่วนประสารกับผู้ใช้
บทที่ 11 การออกแบบส่วนประสารกับผู้ใช้
การออกแบบส่วนประสานกับผู้ใช้ (User Inter) เป็นกระบวนการสำคัญอีกระบวนการหนึ่งสำหรับการผลิตซอฟต์แวร์ โดยจัดว่าเป็นส่วนที่มีอิทธิพลต่อการตัดสินใจเลือกใช้ซอฟต์แวร์ของลูกค้าเป็นอย่างมาก เนื่องจากเป็นส่วนที่คอยประสานการทำงานระหว่างผู้ใช้กับระบบ โดยแสดงออกมาบนจอภาพคอมพิวเตอร์ด้วยรูปลักษณ์ต่างๆ เพื่อสื่อความหมายให้ผู้ใช้ทราบว่าจะต้องโต้ตอบกับระบบอย่างไรเพื่อให้เกิดการทำงาน นับว่าเป็นปราการด่านแรกที่ผู้ใช้จะได้สัมผัสกับระบบ ซึ่งหากสามารถสร้างความประทับใจแรกให้เกิดขึ้นกับผู้ใช้ได้ ก็จะช่วยจูงใจลูกค้าให้ตัดสินใจซื้อซอฟต์แวร์ได้ง่ายขึ้นด้วย แต่การออกแบบส่วนประสานกับผู้ใช้ไม่ใช่การนำเสนอรูปลักษณ์ต่างๆ ให้สวยงามน่าสนใจเพียงอย่างเดียวเท่านั้น วิศวกรออกแบบซอฟต์แวร์ยังต้องคำนึงถึงการใช้งานส่วนประสานเหล่านั้น ให้เรียนรู้ง่าย ไม่สร้างความสับสน และเหมาะกับผู้ใช้ในทางที่จะทำให้เกิดประโยชน์จากการทำงานให้มากที่สุดอีกด้วย
1 ส่วนประสานกับผู้ใช้และกฏเหล็กในการออกแบบ
ส่วนประสานกับผู้ใช้ (User Interface) ในที่นี้ หมายถึง ส่วนติดต่อระหว่างผู้ใช้กับระบบ เพื่อการเตรียมสารสนเทศการทำงาน และการสำสารสนเทศนั้นไปใช้ด้วยการโต้ตอบกับคอมพิวเตอร์ โดยสื่อที่ใช้แสดงส่วนประสานกับผู้ใช้ก็คือจอภาพคอมพิวเตอร์ ดังนั้น จึงเรียกการออกแบบส่วนประสานอีกอย่างหนึ่งว่า ?การออกแบบจอภาพ? นอกจากนี้ ส่วนประสานกับผู้ใช้ยังรวมถึงลักษณะของการโต้ตอบระหว่างผู้ใช้กับคอมพิวเตอร์ โดยผ่านอุปกรณ์ต่างๆ ด้วย
ส่วนประสานกับผู้ใช้ เป็นส่วนที่ช่วยให้ผู้ใช้สามารถโต้ตอบกับระบบ เพื่อเกิดการตามที่ต้องการได้ตามวัตถุประสงค์ของระบบ ส่วนประสานจึงเป็นเสมือนเครื่องบ่งชี้ว่าการใช้งานซอฟต์แวร์นั้นยาก ง่าย หรือซับซ้อนมากน้อยเพียงใด ซึ่งแน่นอนว่าหากการใช้งานซอฟต์แวร์มีลำดับขึ้นตอนหรือมีลักษณะยุ่งยาก จะสร้างความสับสนแก่ผู้ใช้จนเกิดความรู้สึกไม่พึงพอใจในซอฟต์แวร์นั้นได้แม้ว่าภายในซอฟต์แวร์นั้นจะมีการประมวลผลที่ดีเพียงใดก็ตาม การบบอกแบบส่วนประสานกับผู้ใช้ จึงเป็นกระบวนการที่สำคัญไม่น้อยไปกว่าส่วนอื่นของซอฟต์แวร โดยเนื้อหาจะกล่าวถึงในบนนี้จะเน้นที่ส่วนประสานแบบกราฟฟิก (Graphic User Interface: GUI) ที่ได้รับความนิยมในปัจจุบัน
ถึงแล้วว่าปัจจุบันจะมีส่วนประสานแบบการฟฟิกจำนวนมากที่สามารถสื่อความหมายการทำงานได้อย่างชัดเจ และแม้วย่าผู้ใช้งานส่วนใหญ่จะคุ้นเคยกับส่วนประสานเหล่านั้นแล้วก็ตาม แต่ยังพลว่าส่วนประสวนเหล่านั้นยังมีข้อจำกัดจนทำให้ผู้ใช้ไม่พอใจได้ ทั้งนี้ เนื้องจากในการออกแบบส่วนประสานเหล่านั้น ทีมงานไม่ได้คำนึงถึงการใช้งานส่วนประสานที่ควรจะต้องสอดคล้องกัน และไม่ได้คำนึงถึงความแตกต่างกันของผู้ใช้ทั้งด้านพฤติกรรมและประสบการณ์การใช้งานส่วนประสานแต่ละรูปแบบ ดังนั้น ระหว่างการออกแบบส่วนประสานกับผู้ใช้ ทีมงานควรคำนึงถึงหลักของการบบอแบบ โดยปัจจุบันมีหน่วยงานต่างๆ ได้กำหนดไว้จำนวนมาก ในที่นี้ขอยกตัวอย่างกฏเหล็กการออกแบบที่เสนอโดย Theo Mandel [MAN, 97] 3 ประการ ได้แก่
1. ให้ผู้ใช้ควบคุมการทำงานบางอย่างได้
ทีมงานควรตระหนักอยู่เสมอว่า ตนไม่ใช่ผู้ใช้ระบบ แต่ลูกค้าคือผู้ใช้ระบบอย่างแท้จริง ดังนั้น ในระหว่างการออกแบบส่วนประสาน จึงควรคำนึงถึงความต้องการของผู้ใช้ให้มากที่สุด ไม่ควรให้ส่วนประสานควบคุมการทำงานของผู้ใช้ทั้งหมด ควรปล่อยให้ผู้ใช้มีอิสระในการเลือกใช้งานหรือโต้ตอบกับระบบ และสามารถควบคุมการใช้งานบางส่วนได้ โดยสามารถยึดหลัการ ดังนี้
1. ไม่ควรบังคับให้ผู้ใช้ต้องโต้ตอบกับระบบในส่วนที่ไม่จำเป็น
2. อนุญาตให้ผู้ใช้โต้ตอบกับระบบได้มากกว่า 1 ทาง
3. อนุญาตให้ผู้ใช้สลับการทำงานและยกเลิกผลการทำงานบางอย่างได้
4. เตรียมเครื่องมือสร้างการทำงานแบบอัตโนมัติให้กับผู้ใช้
5. ไม่ควรให้ผู้ใช้ติดต่อกับระบบปฏิบัติการโดยการพิมพ์คำสั่งโดยตรง
6. ผู้ใช้ควรทำงานกับอ็อบเจ็กต์ได้โดยตรง
2. ลดปริมาณของสิ่งที่ผู้ใช้ต้องจดจำลง
ซอฟต์แวร์ที่ผุ้ใช้ต้องจดจำรายบะเอียดการทำงานเองมากจนเกินไป ย่อมเสี่ยงต่อการเกิดความผิดพลาดในการใช้งานสุง หลักการออกแบบส่วนประสานกับผู้ใช้ที่ดี ไม่ควรให้ผู้ใช้ต้องจดจำมากจนเกินไป ซอฟต์แวร์หรือระบบควรจัดเก็บรายบะเอียดเกี่ยวกับการโต้ตอบบางอย่างของผู้ใช้ไว้ เพื่อช่วยเตือนความจำของผู้ใช้เมื่อต้องกลับมาใช้งานงานในภายหลังทีมงานสามารถยึดหลักการออกแบบ ดังนี้
1. ลดการจดจำการใช้งานที่ผ่านไปขณะที่ใช้โปรแกรมนั้นอยู่
2. ควรกำหนดค่าเริ่มต้นการใช้งานที่เหมาะสมกับผู้ใช้ทั่วไป
3. คีย์ลัดหรือ Shortcut Key ควรสื่อความหมารยของงานได้ชัดเจนและจดจำง่าย
4. ควรแสดงสถานะการทำงานของผู้ใช้ในกระบวนการใดๆ
5. ควรแสดงรายละเอียดการใช้งานพอสังเขปในเบื้องต้น
3. ส่วนประสานต้องสอดคล้องกัน
ส่วนประสานที่สอดคล้องกัน หมายถึง ส่วนประสานเหล่านั้นจะต้องเชื่อมโดยกันอย่างเป็นลำดับขั้นตอน ซึ่งจะต้องผ่านการออกแบบเชื่อมโดยมาเป็นอย่างดี ตลอดจนต้องมีส่วนนำทางการใช้งานแก่ผู้ใช้ และต้องสอดคล้องกับปัจจัยแวดล้อมอย่างอื่นด้วย โดยมีหลักการออกแบบ ดังนั้
1. ส่วนประกอบทุกอย่างบนจอภาพของการทำงานอย่างใดอย่างหนึ่งต้องสอดคล้องกัน
2. โปรแกรมที่อยู่ในกลุ่มผลิตภัณฑ์เดียวกัน (Program Families) จะต้องมีส่วนประสานเหมือนหรือสอดคล้องกัน
3. ไม่ควรเปลี่ยนลักษณะการโต้ตอบกับรระบที่โปรแรมส่วนใหญ่ใช้เหมือนกัน
11.2 ชนิดของส่วนประสานกับผู้ใช้
เนื่องจากส่วนประสานกับผู้ใช้เป็นส่วนหนึ่งของระบบที่ช่วยให้ผู้ใช้นำเข้าข้อมูล สั่งให้ระบทำงาน และได้รับผลลัพธ์จากการทำงานของระบบ ดังนั้น ชนิดของส่วนประสานกับผู้ใช้ในที่นี้จึงหมายถึง รายงาน เอกสาร การป้อนข้อมูล และการโต้ตอบกับระบบ ในที่นี้จะกล่าวถึงรูปแบบการโต้ตอบระหว่างผู้ใช้กับระบบ และรูปแบบการนำเสนอ เนื่องจากการป้อยข้อมูลถือว่าเป็นการโต้ตอบกับระบบประเภทหนึ่ง ส่วนรายงาน และเอกสารจัดเป็นการนำเสนอสารสนเทศแก้ผู้ใช้ระบบ
11.2.1 รูปแบบการโต้ตอบระหว่างผู้ใช้กับระบบ
1. การโต้ตอบกับระบบโดยตรง (Direct Manipulation) คือ ลักษณะที่ผู้ใช้ดำเนินการรับอ็อบเจ็กต์บนจอภาพคอมพิวเตอร์ผ่านอุปการ์นำเข้าข้อมูล ที่สามารถชึ้ไปที่อ็อบเจ็กต์นั้นได้โดยตรง เช่น การเลื่อนเมาส์ไปคลิกที่ไอคอนของไฟล์ที่ต้องการลบ เป็นต้น
รูปที่ 11.1 แสดงตัวอย่างการโต้ตอบกับระบบโดยตรง
2. การเลือกเมนูคำสั่ง (Menu Selection) คือ ลักษณะที่ผู้ใช้ต้องเลือกคำสั่งจากรายการที่โปรแกรมเตรียมไว้ให้ โดยจะมี 2 ลักษณะคือ Pull-down Menu และ Pop-up Menu
3. การป้อนข้อมูลลงในฟอร์ม (Form Fill-in) คือ ลักษณะที่ผู้ใช้ต้องป้อนข้อมูลลงในช่องว่างต่างๆ ตามหัวข้อของข้อมูล ในแบบฟอร์มป้อนข้อมูลอาจมีปุ่มคำสั่งให้ผู้ให้คลิกเพื่อให้เกิดการทำงานใดๆ ขึ้น เช่น ปุ่มเพิ่ม ลบ และแก้ไข เป็นต้น
4. การโต้ตอบด้วยภาษาธรรมชาติ (Natural Language) คือ ลักษณะที่ผู้ใช้งานคอมพิวเตอร์ด้วยเสียงในภาษาต่างๆ เช่น ภาษาอังกฤษ เป็นต้น เครื่องคอมพิวเตอร์จะต้องมีระบบแปลภาษาอยู่ภายใน และเสียงหรือคำพูดที่ใช้จะต้องเป็นไปตามรู้แบบที่ตัวแปลภาษารู้จัก
รูปที่ 11.2 แสดงตัวอย่างการโต้ตอบด้วยเมนูคำสั่ง
รูปที่ 11.3 แสดงตัวอย่างการโตตอบด้วยแบบฟอร์มป้อนข้อมูล
ตารางที่ 11.1 เปรียบเทียบข้อดีข้อเสียของการโต้ตอบระหว่างผู้ใช้กับระบบแต่ละรูปแบบ
11.2.2 การนำเสนอสารสนเทศต่อผู้ใช้
สิ่งหนึ่งที่ควรคำนึงถึง ก็คือ ต้องไม่นำส่วนข้อมุล และส่วนแสดงผลอยู่ด้วยกัน เนื่องจากหากต้องเปลี่ยนแลหงรูปลักษณ์การนำเสนอหรือแสดงผลข้อมูลจะทำได้ยาก การแยกส่วนทั้งสองจะช่วยให้การแก้ไขทำได้ง่ายขึ้น เพราสามารถแก้ไขเฉพราส่วนแสดงผลเท่านั้น โดยที่ไม่ส่งผลกระทบกับข้อมูลเลย แสดงการแยส่วนข้อมูลและแยกส่วนแสดงผลข้อมูลดังรูปที่ 11.4
รูปที่ 11.4 แสดงการแยกส่วนข้อมูลและส่วนแสดงผลข้อมูลออกจากกัน
รูปแบบการนำเสนอสารสนเทศ
1. Alphanumeric Information คือ สารสนเทศที่ไม่เปลี่ยนแปลงตามวันหรือเวลา เป็นข้อมูลการดำเนนงานทางธุรกิจ เช่น ข้อมูลยอดขาย ผลกำไร-ขาดทุน เป็นต้น สารสนเทศประเภทนี้นำเสอนด้วยตาราง หรือกราฟ และหากเป็นสารสนเทศที่มีความสัมพันธ์กัน (Relative Information) ควรนำเสนอด้วยกราฟ ดังตัวอย่างในรูปที่ 11.5
รูปที่ 11.5 ตัวอย่างการนำเสนอสารสนเทศแบบ Alphanumeric Information
2. Dynamically Varying Information คือ สารสนเทศที่มีการเปลี่ยนแปลงขึ้น-ลงตามวันหรือเวลา เช่น อุณหภูมิ ระดับน้ำทะเล หรือดัชนีหุ้น เป็นต้น สารสนเทศประเภทนี้ควรนำเสนอในรูปแบบกราฟฟิก เช่น กราฟ ควรเลือก ประเภทกราฟเส้น หรือกราฟวงกลม หรือสมารถแสดงในลักษณะของแผงหน้าปัด เป็นต้น
รูปที่ 11.6 ตัวอย่างการนำเสนอสารสนเทศแบบ Dynamic Varying Information
นอกจากรูปแบบการนำเสนอสารสนเทศแล้ว ทีมงานยังต้องออกแบบ ?สี (Color)? ที่จะใช้กับการนำเสนอที่เป็นข้อความและรูปภาพที่ใช้จะช่วยเพิ่มความเข้าใจให้แก่ผู้ใช้และลดความซับซ้อนลงได้ ในกทางกลับกัน หากใช้สีไม่เหมาะสมอาจละความน่าสนใจ และสร้างความสับสนให้แก่ผู้ใช้ได้ โดยหลัการใช้สีเบื้องต้น มีดังนี้
1. กำหนดจำนวนสีที่ใช้ไม่ให้มากเกินไป โดยทั่วไป ไม่ควรใช้สีมากว่า 4-5 สีในแต่ละหน้าต่าง และไม่ควรเกิน 7 สี ในแต่ละระบบ
2. ใช้สีที่แตกต่างเมื่อสถานะของระบบเปลี่ยนไป การใช้สีที่แตกต่างจากปกติ จะทำให้ผู้ใช้เข้าใจได้ทันทีว่ามีสิ่งผิดปกติเกิดขึ้นกับระบบ เช่น เมื่อสมรรถนะการทำงานของระบบต่ำกว่ามาตรฐานฐาน ตัวเลขแสดงสมรรถนะจต้องเปลี่ยนจากเดิม เป็นต้น
3. ใช้สีเป็นสัญญลักษณ์ เช่น หากผู้ใช้กำลังหาข้อมูลที่ผิดพลาด ควรกำหนดให้ข้อมูลที่ผิดพลาดมีสีเดนกว่าข้อมูลธรรมดา เป็นต้น
4. ใช้สีให้สอดคล้องกันทั้งระบบ เช่น เมื่อใช้ ?สีแดง? แสดงข้อมูลที่ผิดพลาดในระบบย่อยใด ข้อมูลที่ผิดพลาดในระบบย่อยอื่อนก็ควรจะป็นสีแดงเหมือนกัน เป็นต้น
5. ไม่ควรใช้สีเปรียบเทียบข้อมูล เนื้องจากสายตามนุษย์มีข้อจำกัดเรื่องการมองเห็นสีที่แตกต่างกันในเวลาเดียวกันซึ่งอาจทำให้สายตาของผู้ใช้เหนื่อยล้าได้ง่าย จึงไม่ควรใช้สีเป็นจุดเปรียบเทียบข้อมูล ควรใช้วิธีแสดงตัวเลข หรือแสดงความแตกต่างด้วยขนาดของรูปภาพ
รูปที่ 11.7 แสดงตัวอย่างข้อความแจ้งเตือนเมื่อป้อน Username/Password ผิด
11.3 กระบวนการออกแบบส่วนประสานกับผู้ใช้
กระบวนการออกแบบส่วนประสานกับผุ้ใช้ มีลักษณะการทำงานแบบวนซ้ำเพ่อให้ได้เป็นส่วนประสานที่ผุ้ใช้พึงพอใจมากที่สุด โดยทีงานจะนำต้นแบบของส่วนประสานไปนำเสนอแก่ผู้ใช้เป็นระยะๆ เพื่อให้ผู้ใช้ประเมฯว่าถูกต้องและใช้งานได้หรือไม่ หากไม่ถูกต้องหรือมีข้อบกพร่องใด ทีงานจะนำต้นแบบกลับมาแก้ไข ทำซ้ำเช่นนี้จนกว่าส่วนประสานจะสมบูรณ์ที่สุด โดยทั่วไป การสร้างต้นแบบของส่วนประสานกับผู้ใช้จะเป็นกิจกรรมที่แยกออกจากกิจกรรมอื่นในการะบวนการวิศวกรรมซอฟต์แวร์จะดำเนินการควบคู่กันไป อย่างไรก็ตาม ขึ้นอยู่กับแบบจำลองกระบวนการผลิตซอฟต์แวร์ที่แตละองค์กรเลือกใช้ โดยส่งที่ต้องคำนึงถึงเสมอก่อนการเริ่มเขียนโปรแกรม ก็คือ ต้นแบบส่วนประสานกับผู้ใช้ทุกส่วนจะต้องผ่านการทดสอบจากผู้ใช้ และต้องจัดทำเป็ฯเอกสารขึ้นเพื่อให้เรียบร้อย
รูปที่ 11.8 แสดงกระบวนการออกแบบส่วนประสานกับผู้ใช้
11.3.1 การวิเคราะห์ผู้ใช้
การศึกษาปัญหาก่อนการออกแบบส่วนประสานกับผู้ใช้เป็นสิ่งที่ดีที่สุด และเพื่อให้ส่วนประสานนั้นสร้างความพึงพอใจแก่ผู้ใช้ได้ จึงต้องเริ่มต้นด้วย ?การวิเคราะห์ผุ้ใช้ (User Analysis)? ซึ่งในที่นี้จะหมายถึง การทำความเข้าใจเกี่ยวกับผู้ใช้ระบบทั้ง 3 ด้านได้แก่
1. ทำความเข้าใจผุ้ใช้ที่ต้องใช้ระบบโดยตรง
2. งานที่ผู้ใช้ต้องดำเนินการในแต่ละวัน
3. ข้อมูลหรือสารสนเทศที่ต้องนำเสนอทางหน้าจอคอมพิวเตอร์หรือทางกระดาษ
4. สภาพแวดล้อมในการทำงานของผู้ใช้
การทำความเข้าใจผู้ใช้
ทีมงานสามารถใช้การตั้งคำถามต่างๆ เป็นแนวทางในการออกแบบส่วนประสานได้ ดังตัวอย่างต่อไปนี้
1. ผู้ใช้แต่ละกลุ่มีทักษะและประสบการณ์ใช้งานคอมพิวเตอร์ในระดับใดบ้าง
2. ระดับการศึกษาโดยเฉลี่ยของผู้ใช้ทั้งหมด
3. ผู้ใช้สามารถเรียนรู้เนื้อหาการฝึกอบรมในชั้นเรียนได้มากน้อยเพียงใด
4. ผู้ใช้มีความชำนาญในการพิมพ์ดีดมากน้อยเพียงใด
5. อายุโดยเฉลี่ยของผู้ใช้ทั้งหมด
6. ผู้ใช้มีลักษณะการถูกครอบงำได้ง่ายหรือไม่
7. ค่าตอบแทนที่ผู้ใช้ได้รับจากการทำงาน
8. ผู้ใช้ทำงานตามเวลางาน หรือทำงานจนกว่างานจะแล้วเสร็จ
9. ซอฟต์แวร์ที่จะนำมาใช้นั้นเป็นส่วนหนึ่งของงานที่ผู้ใช้ต้องทำในแต่ละวัน หรือนำมาใช้เพียงบางโอกาส
10. ภาษาหลักที่ผู้ใช้ใช้สื่อสารกันในองค์กรศึกษาใด
11. เมื่อผู้ใช้ทำงานผิดพลาด
การวิเคราะห์งานที่ผู้ใช้ต้องดำเนนการในแต่ละวัน
วัตถุประสงค์ของการวิเคราะห์งานที่ผู้ใช้ต้องดำเนนการในแต่ละวัน มีดังนี้
1. เพื่อให้ทราบถึงลักษณะของการปฏิบัติงานในแต่ละสถานการณ์
2. เพื่อให้ทราบถึงงานหลักและงานย่อยที่ต้องปฏิบัติ
3. เพื่อให้ทราบถึงระบบงานและส่วนอื่น ที่เกี่ยวข้องที่ผู้ใช้ต้องดำเนินการ
4. เพื่อให้ทราบถึงลำดับของงาน (Workflow) ที่ทำ
5. เพื่อให้ทราบถึงลำดับของการปฏิบัติงาน (ลำดับการใช้ระบบในงานใดงานหนึ่ง)
รูปที่ 11.9 แสดงตัวอย่างแผนภาพการวิเคราะห์งานแบบลำดับชั้น
จากรูปสัญลักษณ์สี่เหลี่ยมผืนผ้าจะให้แทนงานที่ผุ้ใช้ปฏิบัติ หากรูปสี่เหลี่ยมใดที่มีขีดเส้นใต้ หมายถึงงานนั้นไม่สามารถแบ่งย่อยลงได้อีก การสร้างแผนภาพเริ่มต้นจาก กำหนดสถานการณ์การทำงานอย่างใดอย่างหนึ่งขึ้นมาก่อนในที่นี้ กำหนดให้เป็นสถานการณ์ ?การประเมินใบสั่งซื้อ (Assess Customer Order)? จากนั้น ในระดับบนสุดของแผ่นภาพให้วางรูปสี่เหลี่ยมที่แทนเปป้าหมายของสถานการณ์ ซึ่งในที่นี้ก็คือ ?เพื่อประเมินใบสั่งซื้อสินค้า? จากนั้น ให้กำหนดสิ่งต้องปฏิบัติเมื่อต้องทำงานประเมินใบสั่งซื้อ ในที่นี้มีงานหลักทั้งหมด 4 งาน ประกอบด้วย ?รับใบสั่งซื้อ? ?ส่งใบสั่งซื้อให้ระบบ OPS? ?ค้นหาข้อมูลลูกค้า? และ ?ดูเงื่อนไขการขาย? ซึ่งมีเพียงงาน ?ค้นหาข้อมูลลูกค้า? เท่านั้นที่ต้องแบ่งย่อยออกไป
การวิเคราะห์สารสนเทศที่ต้องนำเสนอ
การวิเคราะห์ผู้ใช้นับว่าเป็นการรวบรวมข้อมูลเพื่อนำไปสู่การวิเคราะห์สารสนเทศที่จะต้องนำเสนอ เนื่องจากเมื่อทราบถึงรายละเอียดของงานที่ทำ จะทำให้ทราบถึงเอกสารที่ต้องการและการแสดงผลสารสนเทศที่ต้องการในเบื้องต้น แต่ทีงานจะต้องสอบถามผู้ใช้เพิ่มเติมเพื่อเก็บรายละเอียดของการนำเสนอสารสนเทศ
การนำเสอนสารสนเทศในปัจจะบันมีหลายรูปแบบ เช่น แบบกราฟฟิก แบบกระดาษคำนวณอิเล็กทรอนิกส์ แผ่นภูมิแบบจำลอง 3 มิติ หรือการแสดงผลเป็ฯเสียงและวีดีโอ เป็นต้น
การวิเคราะห์สภาพแวดล้อมการทำงานของผู้ใช้
ทีมงานจำเป็ฯต้องศึกษาสภาพแวดล้อมทางกายภาพในการใช้งานระบบของผุ้ใช้ควบคู่กันไปในระหว่างออกแบส่วนประสานด้วย เพื่อป้องกันไม่ให้มีปัญหาต่างๆ เกิดขั้นในภายหลังการติดตั้องซอฟต์แวร์ เช่น หากเป็นระบบสารสนเทศที่ใช้งานในอาคารสำนักงานทั่วไป การใช้คีย์บอร์ด เมาส์ ลำโพง และหน้าจอคอมพิวเตอร์เพื่อแสดงผล จัดว่าเป็นส่วนประสานที่สามารถใช้การได้โดยไม่มีปัญหา แต่หากเป็นระบบสารสนเทศที่ต้องใช้ในโรงงาน การใช้ลำโพงขนาดเล็กอาจไม่เหมาะสมเนื่องจากในโรงงานมีเสียงดัง หรือการใช้เมาส์กับคีย์บอร์ดบนพื้นที่คับแคบ อาจทำให้การใช้งานลำบากมากขึ้น เป็นต้น นอกจากสภาพแวดล้อมทางกายภาพในการทำงานแล้ว ยังรวมถึงวัฒนธรรมการทำงานขององค์กรด้วย เช่น หากมีการตรวจสอบข้อมูลร่วมกนระหว่างผู้ใช้หลายฝ่ายก่อนนำข้อมูลเข้าสู่ระบบ ทีมงานควรเพิ่มส่วนประสานที่จะอำนวยความสะดวกในการตรวจสอบข้อมูลดังกล่าวด้วย เป็นต้น
11.3.2 การสร้างต้นแบบส่วนประสาน (Interface Prototyping)
ขั้นตอนการสร้างต้นแบบส่วนประสาน มี 2 ขั้นตอน คือ
1. สร้างต้นแบบลงกระดาษ แล้วให้ผู้ประเมินต้นแบบนั้น
2. ปรับปรุงงานออกแบบส่วนประสาน และสร้างต้นแบบที่ทำงานได้จริง เพื่อนำไปให้ผู้ใช้ทดสอบและประเมินผลอีกครั้ง
อย่างไรก็ตาม เนื่องจากการสร้างต้นแบบต้องให้ต้นทุนสูง ทำให้บางองค์กรไม่สามารถใช้วิธีการดังกล่าวนี้ได้ จึงหันกลับไปใช้วิธีการเดิมซึ่งใช้ต้นทุนต่ำกว่า คือ สร้างต้นแบบส่วนประสานลงบนกระดาษ วิธีจะทำให้ต้นแบบบนกระดาษได้ผลดีเช่นเดียวกันคือ ?การสร้างจอภาพจำลองเป็นลำดับเหตุการณ์ (Scenarios)? เป็นวิธีที่ทีมงานจะสร้างหน้าจอการทำงานจำลองขึ้นมาตามลำดับการโต้ตอบระหว่างระบบกับผู้ใช้ ซึ่งปัจจะบันมีซอฟต์แวร์ช่วยสร้างส่วนประสานจำลองได้หลายผลิตภัณฑ์ เช่น Microsoft Visio, SmartDraw, Rational Rose และ BX for Java เป็นต้น แสดตัวอย่างต้นแบบส่วนประสานของระบบลงทะเบียน ในเหตุการณ์ ?เข้าสู่ระบบ? ดังรูป
รูปที่ 11.10 แสดงตัวอย่างต้นแบบส่วนประสาน
เมื่อต้นแบบที่สร้างลงบนกระดาษผ่านการประเมิณจากผู้ใช้แล้ว ทีมงานจะต้องนำรายบะเอียดดังกล่าวมาสร้างเป็นต้นแบบที่สร้างเป็นต้นแบบที่สามารถใช้งานได้จริงบางฟังก์ชัน เพื่อให้ผู้ใช้ได้ทดลองใช้ และประเมินผลอีกครั้ง แต่หากโครงการใดสร้างต้นแบบส่วนประสานในช่วงแรกๆ ขอบกระบวนการผลิต มักพบกับปัญหา คือ ทีมงานจะยังไม่สามารถสร้างต้นแบบที่สมารถใช้ฟังก์ชันงานของระบบได้จริง อย่างไรก็ตาม มีแนวทางการสร้างต้นแบบส่วนประสานแนวทางหนึ่งที่สามารถลดปัญได้ นั่คือ ?Wizard of Oz?
ด้วยวิธี ?Wizard of Oz? ทีมงานไม่จำเป็นต้องสร้างการโต้ตอบจากระบบจริง แต่ทีงานเพียงจำลองการโต้ตอบมาเท่านั้น สิ่งสำคัญคือ ทีมงานมีซอฟต์แวร์ที่ใช้เป็นเครื่องมือสร้างต้นแบบทดสอบที่สนับสนุนแนวทาง ?Wizard of Oz? จะช่วยให้การออแบบส่วนประสานกับผู้ใช้มีประสิทธภามากขึ้น
สำหรับแนวทางการสร้างต้นแบบนั้นมีหลายแนวทาง บางโครงการอาจเลือกแบบ ?Throw-away Approach คือ เมื่อประเมินต้นแบบผ่านแล้ว จะไม่นำต้นแบบนั้นมาใช้พัฒนาต่อ แต่บางโครงการเลือกแบบ RAD (Rapid Application Development) ซึ่งทีมงานสามารถเลือกสร้างต้นแบบได้หลายวิธี เช่น
1. Scriptdriven Approach เป็นการสร้างต้นแบบโดยใช้ซอฟต์แวร์ที่มีเครื่องมือสร้างองค์ประกอบต่างๆ ของหน้าจอการทำงานบนระบบคอมพิวเตอร์ โดยภายใต้องค์ประกอบเหล่านี้ ซอฟต์แวร์จะสร้างสคริปต์การทำงานให้อัตโนมัติ เมื่อผู้ใช้ทดลองใช้งาน จะมีการโต้ตอบกับผู้ใช้ตามลักษณะการทำงานของแต่ละองค์ประกอบนั้น ยกตัวอย่างเตรื่องมือประเภทนี้ เช่น Macromedia Director เป็นต้น
2. Visual Programming Language คือ การใช้ภาษาโปรแกรมมิ่งประเภทวิชวลสร้างองค์ประกอบต่างๆ ที่จะแสดงบนหน้าจอการทำงาน โดยให้ผู้ใช้คลิกที่อ็อบเจ็กต์องค์ประกอบเหล่านั้นแล้วลากมาวางบนตำแหน่งที่ต้องการภายใต้อ็อกเจ็กต์จะมีสคริปต์การทำงานให้ต้วยเช่นกัน ยกตัวอย่างภาษาโปรแกรมมิ่งชนิดดังกล่าง เช่น Visual Basic และ Visual Studio .NET เป็นต้น
11.3.3 การประเมินส่วนประสาน (Interface Evaluation)
หลังจากทีมงานสร้างต้นแบบเสร็จเรียบร้อยแล้ว ผู้ใช้จะมีหน้าที่ประเมินผลต้นแบบส่วนประสานกับผู้ใช้ดังกล่าวว่าถูต้องตรงความต้องการ หรือมีข้อผิดพลาดประการใดหรือไม่ โดยทีมงานจะต้องเก็บข้อมูลความคิดเห็นของผู้ใช้ในขณะประเมินให้ใด้มากที่สุด เพื่อนำไปปรับปรุงต้นแบบให้สมบูรณ์ที่สุด โยสามารถให้เทคนิคเดียวกับการเก็บรวบรวมข้อมูลของการวิศวกรรมความต้องการ นั่นคือ การสัมภาณ์ การสอบถาม แต่ทีงานจะต้องนำข้อมูลเหล่านั้นมาวิเคราะห์อีกครั้ง
สมัครสมาชิก:
บทความ (Atom)