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

บทที่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

บทที่ 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.  สภาพแวดล้อม และ เทคโนโลยี เมื่อเกิดการเปลี่ยนแปลง ก็จะต้องมีการเปลี่ยนแปลงความต้องการให้มีความสอดคล้อง และ เหมาะสม

บทที่ 5

บทที่ 5  ความต้องการด้านซอฟต์แวร์

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

5.1 ทำความรู้จักกับความต้องการด้านซอฟต์แวร์ 
     ความต้องการของลูกค้าหรือผู้ใช้เป็นตัวกำหนดฟังก์ชันการทำงาน รูปลักษณ์ ความสามารถ และรายละเอียดอื่นๆ ของระบบหรือซอฟต์แวร์ ความต้องการในแวดวงซอฟต์แวร์จำแนกเป็น 2 ระดับดังนี้ 
           1. ความต้องการของลูกค้า (User Requirement) เป็นความต้องการของลูกค้า หรือผู้ที่เกี่ยวข้องกับระบบ โดยแสดงออกมาในรูปแบบของภาษาธรรมชาติ ที่แสดงถึงความคาดหวังในการบริการ หรือการทำงานที่จะได้รับจากระบบและเงื่อนไขที่ต้องทำตาม
         2. ความต้องการด้านระบบ (System Requirement) เป็นการกำหนดความต้องการของการทำงาน ฟังก์ชันและบริการต่างๆ ของระบบในระดับรายละเอียด เรียกว่าข้อกำหนดของระบบ (Functional Specification)

     นอกจากความต้องการทั้ง 2 ระดับข้างต้นแล้ว ยังมีความต้องการอีกระดับหนึ่งที่คุ้นเคยกันดี นั่นคือ ความต้องการด้านซอฟต์แวร์ (Software Requirement) ซึ่งมีความสัมพันธ์อย่างมากกับความต้องการด้านระบบ เนื่องจากซอฟต์แวร์ก็เป็นความต้องการหนึ่งของระบบเช่นกัน 

5.2 ประเภทความต้องการด้านซอฟต์แวร์ 
        ความต้องการด้านซอฟต์แวร์ แบ่งออกเป็น 3 ประเภท คือ
           1. ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) คือความต้องการให้ซอฟต์แวร์ทำหน้าที่ใดๆ ตามที่กำหนดไว้      ได้ ซึ่งเป็นสิ่งที่ซอฟต์แวร์ควรจะทำเป็นหน้าที่หลักในการทำงาน หรือเป็นบริการที่ซอฟต์แวร์ควรมี ยกตัวอย่างเช่นระบบทะเบียน

- นักศึกษาสามารถตรวจสอบผลการเรียนและสภาพนักศึกษาได้
- นักศึกษาสามารถลงทะเบียนและทำการเพิกถอนรายวิชาได้ 
         - อาจารย์สามารถตรวจสอลกลุ่มนักศึกษาในรายวิชาที่เป็นผู้สอนได้ 
         - อาจารย์สามารถตรวจสอบผลการเรียนของนักศึกษาในรายวิชาของตน หลังจากส่งผลการเรียนไป
   ยังผ่ายทะเบียนแล้ว เพื่อดูความถูกต้อง 
         - อาจารย์และนักศึกษาสามารถติดตามเอกสารคำร้องต่างๆ ที่ยื่นต่อฝ่ายทะเบียนได้
         - เจ้าหน้าที่ฝ่ายทะเบียนสามารถ เพิ่ม ลบ และแก้ไข ข้อมูลต่างๆ ในระบบตามหน้าที่ได้
        2. ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-Functional Requirement) เป็นความต้องการที่ไม่เกี่ยวข้องโดยตรงกับฟังก์ชันหลักของระบบ แต่เกี่ยวข้องทางอ้อมในลักษณะที่เป็นเงื่อนไขการทำงานหรือฟังก์ชันหรือบริการ 
        ความต้องการที่ไม่ใช่หน้าที่หลักของระบบ อาจมาจากความต้องการของผู้ใช้หลายๆ ด้านที่ไม่เกี่ยวข้องกับซอฟต์แวร์เพียงอย่างเดียว ดังนี้
           1. ความต้องการด้านผลิตภัณฑ์ (Product Requirement) แบ่งออกเป็น 3 ส่วน ได้แก่
          - ความต้องการด้านประสิทธิภาพของผลิตภัณฑ์ (Performance Requirement)
          - ความต้องการด้านความน่าเชื่อถือ (Reliability Requirement)
          - ความต้องการด้านการทำงานข้ามแพลตฟอร์มได้ (Portability Requirement) และใช้งานง่าย 
            (Usability Requirement)
        2. ความต้องการขององค์กร (Organizational Requirement) เป็นความต้องการที่มาจากนโยบายและระเบียบปฏิบัติของลูกค้า และผู้พัฒนา โดยกำหนดข้อตกลงระหว่างองค์กร ไว้เพื่อเป็นแนวทางในการพัฒนาที่ตรงตามความต้องการของทั่งสองฝ่าย 
      3. ความต้องการจากปัจจัยภายนอก (External Requirement) เป็นความต้องการที่เกิดจากปัจจัยภายนอก ซึ่งส่งผลต่อซอฟต์แวร์และกระบวนการพัฒนา แบ่งเป็น 3 ส่วน ดังนี้ 
         - ความต้องการการทำงานร่วมกัน (Interoperability Requirement)
         - ความต้องการในทางกฎหมาย (Legislative Requirement) 
         - ความต้องการในด้านหลักจริยธรรม (Ethical Requirement)
        3. ความต้องการทางด้านงานธุรกิจ (Domain Requirement) เป็นความต้องการที่เกี่ยวข้องกับงานหลักของระบบที่ต้องการซอฟต์แวร์มาสนับสนุนโดยเฉพาะ ส่วนใหญ่ก็จะเป็นศัพท์เฉพาะงานธุรกิจด้านนั้น 

5.3 ความต้องการของผู้ใช้ 
        ความต้องการของผู้ใช้ (User Requirement) เป็นความต้องการที่มีต่อระบบซึ่งระบุโดยผู้ใช้ระบบ โดยจะอธิบายทั้งส่วนที่เป็นหน้าที่หลัก และส่วนที่ไม่ใช้หน้าที่หลักของระบบ ด้วยภาษาที่ผู้ใช้อ่านแล้วเข้าใจง่าย ไม่ควรใช้คำศัพท์เทคนิคมากเกินไป ดังนั้น การเขียนข้อกำหนดความต้องการของผู้ใช้ จะต้องใช้ภาษาที่เข้าใจง่าย อาจใช้แผนภาพเพื่อแสดงรายละเอียด ในระดับที่ผู้ใช้พอจะเข้าใจได้ หรืออธิบายในลักษณะของตารางหรือแบบฟอร์มง่ายๆ อย่างไรก็ตามอาจเกิดปัญหาดังนี้ 
        1. ขาดความชัดเจน
        2. ไม่สามารถจำแนกประเภทของความต้องการได้อย่างชัดเจน
        3. บางครั้งความต้องการมีจุดประสงค์เดียวกัน แต่เขียนออกมาในประโยคที่ต่างกัน
        จากปัญหาที่เกิดขึ้น การจัดทำเอกสารความต้องการต้องมีการแยกรายละเอียด ความต้องการของระบบออกจากผู้ใช้ เพื่อหลีกเลี่ยงความรู้สึกต่อต้าน ควรมีหลักปฏิบัติดังนี้
        1. กำหนดมาตรฐานของรูปแบบเอกสาร 
        2. จำแนกความจำเป็นของความต้องการ โดยจำแนกเป็น ความต้องการที่จำเป็น (Mandatory Requirement)  (ต้อง) และความต้องการที่ปรารถนา (Desirable Requirement) (ควร)

5.4 ความต้องการด้านระบบ 
        ความต้องการด้านระบบ (System Requirement) เป็นการกำหนดความต้องการการทำงาน ฟังก์ชัน และบริการต่างๆ ที่ระบบจะต้องมีเพื่อตอบสนองความต้องการของผู้ใช้ ความต้องการด้านระบบเป็นความต้องการที่ได้จากการวิเคราะห์ข้อมูลความต้องการของผู้ใช้มาแล้ว เป็นข้อมูลที่มีความสำคัญ การเขียนข้อกำหนดความต้องการด้านระบบ (System Requirement Specification) ควรภาษาธรรมชาติหรือภาษาที่เข้าใจง่าย โดยกำหนดมาตรฐานในการใช้ภาษาธรรมชาติมาอธิบายถึงความต้องการด้านระบบใบรูปแบบต่างๆ ดังนี้ 
ข้อกำหนดการใช้ภาษาโครงสร้าง (Structure Language Specification)
        1. From-Base Specification เป็นการสร้างฟอร์มมาตรฐานเพื่อใช้เป็นรูปแบบในการกำหนดความต้องการ ของระบบ โดยสามารถกำหนดได้ว่าต้องการรายละเอียดใดบ้าง เช่น 

        2. Tabular Specification กรณีต้องการคำนวณหาค่าต่างๆ สามารถใช้ตารางการคำนวณแสดงการตัดสินใจและทางเลือกต่างๆ ในการทำงานของระบบได้ด้วย เช่น 


เงื่อนไข        การกระทำ

Member=yes        Discount=5% then

Net price = total price-(total price*discount)

Member=no        Discount=0% then

Net price = total 

        3. Graphical Model เป็นการนำภาพหรือแบบจำลอง มาใช้อธิบายข้อมูลหรือความต้องการเพิ่มเติมจากการอธิบายด้วยรูปอื่น เนื่องจากรูปภาพช่วยลดความกำกวมและแสดงแทนข้อความจำนวนมากได้ เช่น

5.5 เอกสารความต้องการด้านซอฟต์แวร์ 

        เอกสารความต้องการด้านซอฟต์แวร์ (Software Requirement Document) เรียกได้อีกอย่างหนึ่งว่า ข้อกำหนดความต้องการด้านซอฟต์แวร์ (Software Requirement Specification : SRS) เป็นเอกสารข้อกำหนดความต้องการอย่างเป็นทางการ ที่จะบอกใช้ทีมพัฒนาทราบว่าต้องพัฒนาอะไรบ้าง ควรระบบข้อมูลความต้องการของผู้ใช้ และความต้องการด้านระบบ 

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

        1. บทนำ (Introducation)

                1. 1 วัตถุประสงค์ของเอกสาร

                1.2 ขอบเขตของผลิตภัณฑ์
                1.3 นิยาม คำย่อ และตัวอักษรย่อต่างๆ 
                1.4 เอกสารอ้างอิง
                1.5 สรุปส่วนอื่นๆ ของเอกสาร        
        2. รายละเอียดทั่วไป (General Description)
                2.1 มุมมองเกี่ยวกับผลิตภัณฑ์
                2.2 ฟังก์ชันของผลิตภัณฑ์
                2.3 คุณสมบัติของผู้ใช้
                2.4 ข้อบังคับทั่วไป 
                2.5 สมมติฐานและส่วนเพิ่มเติม
        3. ข้อกำหนดความต้องการ (Specification Requirement) 
        4. ภาคผนวก (Appendices)
        5. ดัชนี (Index)