บทที่ 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) คือ ลักษณะที่ผู้ใช้ดำเนินการรับอ็อบเจ็กต์บนจอภาพคอมพิวเตอร์ผ่านอุปการ์นำเข้าข้อมูล ที่สามารถชึ้ไปที่อ็อบเจ็กต์นั้นได้โดยตรง เช่น การเลื่อนเมาส์ไปคลิกที่ไอคอนของไฟล์ที่ต้องการลบ เป็นต้น

        2.  การเลือกเมนูคำสั่ง (Menu Selection) คือ ลักษณะที่ผู้ใช้ต้องเลือกคำสั่งจากรายการที่โปรแกรมเตรียมไว้ให้ โดยจะมี 2 ลักษณะคือ Pull-down Menu และ Pop-up Menu

        3.  การป้อนข้อมูลลงในฟอร์ม (Form Fill-in) คือ ลักษณะที่ผู้ใช้ต้องป้อนข้อมูลลงในช่องว่างต่างๆ ตามหัวข้อของข้อมูล ในแบบฟอร์มป้อนข้อมูลอาจมีปุ่มคำสั่งให้ผู้ให้คลิกเพื่อให้เกิดการทำงานใดๆ ขึ้น เช่น ปุ่มเพิ่ม ลบ และแก้ไข เป็นต้น

        4.  การโต้ตอบด้วยภาษาธรรมชาติ (Natural Language) คือ ลักษณะที่ผู้ใช้งานคอมพิวเตอร์ด้วยเสียงในภาษาต่างๆ เช่น ภาษาอังกฤษ เป็นต้น เครื่องคอมพิวเตอร์จะต้องมีระบบแปลภาษาอยู่ภายใน และเสียงหรือคำพูดที่ใช้จะต้องเป็นไปตามรู้แบบที่ตัวแปลภาษารู้จัก

11.2.2  การนำเสนอสารสนเทศต่อผู้ใช้

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

รูปแบบการนำเสนอสารสนเทศ

1.  Alphanumeric Information คือ สารสนเทศที่ไม่เปลี่ยนแปลงตามวันหรือเวลา เป็นข้อมูลการดำเนนงานทางธุรกิจ เช่น ข้อมูลยอดขาย ผลกำไร-ขาดทุน เป็นต้น สารสนเทศประเภทนี้นำเสอนด้วยตาราง หรือกราฟ และหากเป็นสารสนเทศที่มีความสัมพันธ์กัน (Relative Information) ควรนำเสนอด้วยกราฟ ดังตัวอย่างในรูปที่ 11.5

2.  Dynamically Varying Information คือ สารสนเทศที่มีการเปลี่ยนแปลงขึ้น-ลงตามวันหรือเวลา เช่น อุณหภูมิ ระดับน้ำทะเล หรือดัชนีหุ้น เป็นต้น สารสนเทศประเภทนี้ควรนำเสนอในรูปแบบกราฟฟิก เช่น กราฟ ควรเลือก ประเภทกราฟเส้น หรือกราฟวงกลม หรือสมารถแสดงในลักษณะของแผงหน้าปัด เป็นต้น

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

        1.  กำหนดจำนวนสีที่ใช้ไม่ให้มากเกินไป  โดยทั่วไป ไม่ควรใช้สีมากว่า 4-5 สีในแต่ละหน้าต่าง และไม่ควรเกิน 7 สี ในแต่ละระบบ

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

        3.  ใช้สีเป็นสัญญลักษณ์  เช่น  หากผู้ใช้กำลังหาข้อมูลที่ผิดพลาด ควรกำหนดให้ข้อมูลที่ผิดพลาดมีสีเดนกว่าข้อมูลธรรมดา เป็นต้น

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

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

11.3  กระบวนการออกแบบส่วนประสานกับผู้ใช้

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

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)

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

บทที่ 12

บทที่ 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. ทบทวน เป็นการย้อนกลับไปพิจารณาถึงสิ่งที่ดำเนินการแก้ไขปัญหาในแต่ละส่วน ในขณะเดียวกันจะต้องประเมินวิธีแก้ไขปัญหานั้นด้วยว่าเหมาะสม หรือถูกต้องที่สุดหรือไม่

บรรหาญ  ทองถนอม  510702473989

บทที่ 7

การสร้างต้นแบบจำลองของ Software

System Modeling การสร้างตัวต้นแบบ

    การสร้างตัวต้นแบบมีวัตถุประสงค์

1. เพื่อให้เข้าใจว่าหน้าที่หลักของระบบทำงานอย่างไร ผู้ที่ควรจะต้องเข้าใจถึงกระบวนการคือ SAเจ้าของระบบ User Programmer
2. เพื่อให้สามารถอธิบายได้ว่าระบบเก่าและระบบใหม่มีความแตกต่างกันอย่างไร โดยแบ่งออกเป็น 

          3 มุมมองได้แก่

1. มุมมองภาพรวมของระบบ
2. มุมมองพฤติกรรมของระบบ
3. มุมมองโครงสร้างของระบบ 

Model Types ประเภทของตัวต้นแบบ

1. DATE PROCESSING MODEL แบบจำลองแสดงการประมวลผลข้อมูล จะอธิบายพฤติกรรมของระบบ
2. COMPOSITION MODEL แบบจำลองอธิบายองค์ประกอบของ ENTITIES
3. ARCHITECTURAL MODEL อธิบายสถาปัตยกรรมของระบบ โดยจะแสดงให้เห็นถึงระบบย่อยภายในด้วย
4. CLASSIFICATION MODEL อธิบายการจัดแบ่งประเภทของ ENTITIES
5. STIMULUS/RESPONSE MODEL อธิบายตัวกระตุ่นหรือสิ่งกระตุ้น

Context Model

            แสดงขอบเขตของระบบ ว่ามีการเชื่อมโยงกับระบบอื่นๆ อย่างไร context models จะเน้นขอบเขตของระบบ ไม่เน้นรายระเอียดของระบบ

     ตัวอย่าง Context model ของระบบ ATM

จาก Context Model ของระบบ ATM สามารถอธิบายได้ดังนี้ Model นี้ใช้แสดงขอบเขตการทำงานของระบบ ATM ซึ่งมีแต่ส่วนตรงกลางเท่านั้นที่เป็น Context ซึ่งระบบนี้มีขอบเขตการทำงานที่เชื่อมต่อกับระบบย่อยอื่นๆ อีก 6 ระบบดังรูป

Behavioral models แบบจำลองพฤติกรรม แบ่งเป็น 2 รูปแบบ

1. Data processing เน้น DFD เน้นแสดงกระบวนการทำงานของระบบ

ตัวอย่าง Order Processing DFD มีทั้งหมด 5 ขั้นตอน สามารถอธิบายได้ดังรูป

2. State machine models เน้นสถานการณ์เปลี่ยนแปลงสถานะของอุปกรณ์ทางด้านวิศวกรรมที่สร้างขึ้น

             ตัวอย่าง Microwave oven model มีทั้งหมด 8 State สามารถอธิบายได้ดังรูป

Object behavior modeling

      ใช้อธิบายพฤติกรรมของระบบโดยใช้แบบจำลอง Sequence diagram หรือ collaboration diagram

 

 

 

บรรหาญ  ทองถนอม  510702473989

บทที่ 6

บทที่ 6 กระบวนการวิศวกรรมความต้องการ  

 

แบ่งออกเป็น 4 ขั้นตอน คือ

           1. ศึกษาความเป็นไปได้

เป็นขั้นตอนการศึกษาเพื่อตัดสินใจว่ามีความคุ้มค่าในการลงทุนหรือไม่

- ตรงกับวัตถุประสงค์ขององค์กรหรือไม่

- เทคโนโลยีในปัจจุบันสามารถนำมาพัฒนาระบบได้หรือไม่ สามารถทำได้ไหม

- ระบบใหม่สามารถทำงานร่วมกับระบบเก่าได้หรือไม่

ในการศึกษาความเป็นไปได้จะทำให้

1. ถ้าไม่พัฒนาระบบจะเกิดอะไรขึ้น

2. ปัญหาที่พบมีอะไรบ้าง

3. ระบบใหม่สามารถช่วยในการแก้ไขปัญหาได้อย่างไร

4. ต้องใช้เทคโนโลยีอะไรและใช้ความสามารถพิเศษอะไรบ้าง

           2. ค้นหาและวิเคราะห์ความต้องการ

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

                  เจ้าหน้าที่เข้าไปทำงานร่วมกับลูกค้าเพื่อค้นหาว่าในการทำงานของ User มีความต้องการอย่างไร มีขั้นตอนอย่างไร 

                  นอกจากนี้เรายังต้องสอบถามความต้องการจากผู้เกี่ยวข้องคนอื่นๆด้วย

           3. กำหนดความต้องการ

                  นำความต้องการที่ได้มาทำการวิเคราะห์แล้วทำการกำหนดเป็นความต้องการของ Userและ System ทำให้ในขั้น

                  ตอนนี้เราได้ความต้องการของ user และ system

           4. ตรวจสอบความต้องการ

                  ตรวจสอบความต้องการที่ได้ เพื่อลดความผิดพลาดหรือปัญหาที่จะเกิดขึ้น ความต้องการที่ทับซ้อนกัน ความต้องการ

                  ที่มากเกินต้นทุนที่กำหนดไว้ เมื่อสิ้นสุดการตรวจสอบเราจะได้เอกสารความต้องการที่ถูกต้อง

รูปแบบในการตรวจสอบ

         1. ตรวจสอบความเที่ยงตรงจากตัวแทนผู้ใช้

         2. ความสมบูรณ์ของความต้องการ

         3. ความเป็นไปได้ของความต้องการทางด้าน เทคโนโลยี

         4. สามารถพิสูจน์ได้ เช่น ทำให้ลูกค้าเห็นได้ Prototype

ปัญหาในการวิเคราะห์ความต้องการ

                1. Stakeholder ไม่มีความรู้ความเข้าใจ

                2. Stakeholder อธิบายความต้องการด้วยศัพท์ทางเทคนิคที่เขาเข้าใจ และเราไม่เข้าใจ อาจทำให้เกิดการเข้าใจผิดได้

                3. Stakeholder มีความต้องการที่แตกต่างกัน เราต้องแบ่งกลุ่มความต้องการเพื่อไม่ให้ขัดแย้งกัน

                4. การเมืองและความขัดแย้งในองค์กร ส่งผลต่อระบบ อาจทำให้เกิดความผิดพลาดล้มเหลวในการพัฒนาได้

                5. มีการเปลี่ยนแปลงความต้องการระหว่างการพัฒนา เช่น SK คนใหม่เข้ามา ธุรกิจเปลี่ยน เปลี่ยนเทคโนโลยี

ทำไมต้องมีการปรับเปลี่ยนความต้องการ

1. ในระบบมีผู้ใช้หลายกลุ่ม เราต้องจัดลำดับความสำคัญของความต้องการ เพื่อไม่ให้เกิดความขัดแย้งใน SK

2.  งบประมาณไม่เพียงพอ

        3.  สภาพแวดล้อม และ เทคโนโลยี เมื่อเกิดการเปลี่ยนแปลง ก็จะต้องมีการเปลี่ยนแปลงความต้องการให้มีความสอดคล้อง และ เหมาะสม

บรรหาญ ทองถนอม 510702473989