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

บทที่ 3

สรุปบทที่3

วิศวกรรมระบบ(System Engineering)

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

        1. กำหนดวัตถุประสงค์ของระบบ

        2. กำหนดขอบเขตระบบ

        3. แบ่งระบบออกเป็นส่วนๆ ตามฟังก์ชันการทำงานหรือคุณสมบัติของระบบ

        4. พิจารณาความสัมพันธ์ของส่วนประกอบต่างๆ ที่เกี่ยวข้องทั้งหมด

        5. กำหนดความสัมพันธ์ของปัจจัยนำเข้า ประมวลผล และผลลัพธ์

        6. พิจารณาปัจจัยที่มีส่วนเกี่ยวข้องในระบบ ไม่ว่าจะเป็นฮาร์ดแวร์ ซอฟต์แวร์ ฐานข้อมูล หรือแม้แต่ผลิตภัณฑ์ซอฟต์แวร์อื่นๆ เป็นต้อ

        7. กำหนดความต้องการในส่วนของการดำเนินการและฟังก์ชันทั้งระบบ

        8. สร้างแบบจำลองระบบ เพื่อใช้วิเคราะห์และพัฒนาให้สอดคล้องกับแบบจำลองซอฟต์แวร์ที่สร้างขึ้น

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

กระบวนการวิศวกรรมระบบ

        กระบวนการวิศวกรรมระบบ ประกอบไปด้วยขั้นตอนการทำงานทั้งหมด 7 เฟส ได้แก่

                1. การกำหนดความต้องการ (Requirement Definition)

กระบวนการของวิศวกรรมระบบ เริ่มต้นด้วยการวิเคราะห์ภาพรวมของทั้งองค์กร เพื่อกำหนดนิยามความต้องการของระบบให้ชัดเจน ด้วยการกำหนดหน้าที่ว่าระบบควรทำอะไรได้บ้าง

                2. การออกแบบระบบ (System Design)

                                เป็นการกำหนดรายละเอียดของฟังก์ชั่นในแต่ละส่วนประกอบของระบบ โดยมีกระบวนการย่อยดังนี้

                1. แบ่งส่วนความต้องการ (Partition Requirement) วิเคราะห์ความต้องการและจัดโครงสร้างด้วยการแบ่งกลุ่มความต้องการด้วยวิธีที่เหมาะสม

                2. กำหนดระบบย่อย (Identify Sub-System) นำระบบใหญ่มาแบ่งส่วนออกเป็นระบบย่อย ด้วยวิธีการหรือแนวทางที่เหมาะสม

                3. กำหนดความต้องการในแต่ละระบบย่อย (Assign Requirement) กำหนดความต้องการของแต่ละระบบย่อย ซึ่งต้องสอดคล้องกับความต้องการทั้งหมดของระบบ และจะซับซ้อนขึ้นเมื่อความต้องการมีการเปลี่ยนแปลง

                4. กำหนดฟังก์ชันของแต่ละระบบย่อย (Specify Sub-system Functionality) ซึ่งต้องสอดคล้องกับความต้องการของแต่ละระบบย่อยด้วย

                5. กำหนดส่วนประสานของระบบย่อย แต่ละระบบย่อยจะต้องเตรียมส่วนประสานไว้บริการระบบย่อยอื่นๆ เพื่อการผนวกรวมระบบ

        3. การพัฒนาระบบย่อย (Sub-system Development)

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

        4. การผนวกรวมระบบ (System Integration)

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

5. การติดตั้งระบบ (System Installation)

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

        6. การเปลี่ยนแปลงระบบ (System Evolution)

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

        7. การปลดระวางระบบ (System Decommission)

การปลดระวางระวางระบบ หมายถึง การเลิกใช้ระบบหลังพบว่าระบบไม่สามารถใช้งานได้อีกต่อไป

ข้อแตกต่างและความสัมพันธ์ระหว่างกระบวนการวิศวกรรมระบบกับกระบวนการวิศวกรรมซอฟต์แวร์ มีดังนี้

        1. ขอบเขตของการแก้ไขงานในระหว่างการพัฒนาระบบ

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

        2. ความสัมพันธ์ของงานด้านวิศวกรรม

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

                                                                                                                               นายอดุลวิทย์  อาหมัด 510702473611

บทที่ 2

บทที่ 2

1.             จงเปรียบเทียบจุดเด่น จุนด้อยของระเบียบวิธีปฎิษัติของวิศวกรซอฟต์แวร์ ระหว่างวิธีเชิงโครงสร้าง(Structured Approach) และวิธีเชิงวัตถุ (Object-Oriented Approach )

ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟแวร์ จึงเป็นไปตามแนวทางการพัฒนาซอฟแวร์ ซึ่งมีสองแนวทางที่รู้จักกันอย่างกว้างขวางคือ 1. แนวทางเชิงโครงสร้าง (Structured Approach) เป็นแนวทางแบบตั้งเดิม มีการแบ่งระบบและความต้องการออกเป็นระบบย่อย ตามลักษณะฟังก์ชันงานและแต่ละระบบย่อยสามารถแบ่งออกเป็นส่วนย่อยลงไปได้อีก หากยังมีความสลับซับซ้อนอยู่ จึงเป็นโครงสร้างแบบสำดับชั้น ระเบียบวิธีการปฏิบัติชนิดหนึ่งที่นิยมนำมาใช้ในขั้นตอนการวิเคราะห์ออกแบบ ระบบ คือ การวิเคราะห์และโดย Yourdan& Demarco 2. แนวทางเชิงวัตถุ (Object-Oriented Approach) เป็นแนวทางใหม่ที่คิดค้นโดย Grady Booch, James Rubaughและ Ivar Jacobson ด้วยวิธีการวิเคราะห์และอกแบบระบบเชิงวัตถุ เป็นการวิเคราะห์ระบบโดยหารมองทุกย่างในระบบเป็นอ็อบเจ็กต์ ซึ่งภายในอ็อบเจ็กต์นั้น จะมีทั้งส่วนข้อมูลและพฤติกรรมของระบบรวมอยู่ด้วย ทำให้การวิเคราะห์และออกแบบระบบเร็วขึ้นด้วย ซึ่งปัจจุบันได้รับความนิยมย่างสูงและกำลังเพิ่มขึ้นในอนาคตด้วย

2.             Waterfall Model แตกต่างจาก Spiral Model อย่างไร จงอธิบายตามความเข้าใจของนักศึกษา

Waterfall Model ข้อดีของ Waterfall Model

1.แบ่งงานยากให้เป็นงานที่เล็ก ง่ายต่อการจัดการ

2.มีการกำหนดProductที่ต้องส่งมอบในแต่ละงานอย่างชัดเจน

ข้อเสียของ Waterfall Model

1.ลูกค้าเห็นและทดลองใช้Software ก็ต่อเมื่อถึงขั้นตอนสุดท้าย หากมีบางอย่างที่ไม่ตรงกับความต้องการของลูกค้า การแก้ไขยาก แพง เสียเวลา

 2.ถ้า ค้นพบข้อผิดพลาดของขั้นที่เสร็จสิ้นแล้ว ไม่สามารถแก้ไขได้ การแก้ไขจำเป็นต้องเริ่มรอบ (Iteration) ใหม่

Spiral Model ข้อดีของ Spiral Model

1.โมเดลผ่านการใช้งานเพื่อพัฒนาซอฟต์แวร์หลายประเภทอย่างประสบความสำเร็จ จากการสำรวจ 25 โครงการพบว่าทุกโครงการมีความสามารถในการผลิต (Product tivity) สูงขึ้นอย่างน้อย 50 %

 ข้อเสียของ Spiral Model

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

2. เหมาะกับงานที่มีโอกาสเปลี่ยนแปลงบ่อย หรือมีความต้องการใหม่เรื่อย ๆ

3.             ในฐานะที่นักศึกษาเป็นวิศวกซอฟตแวร์ ควรจะเลือกพิจารณาใช้แบบจำลองกระบวนการผลิต

ซอฟตแวร์(Software Parocess Model) แบบใด เพราะเหตุใด จงให้เหตุผล

                Incremental Model ข้อดี Incremental model

1. เราสามารถส่งมอบงานได้เร็ว

2. ลดอัตราเสี่ยงการเลิกจ้าง

3. เราและ Customer สามารถมองเห็นความก้าวหน้าของโครงการได้

สรุปบทที่ 2

The software process คือกระบวนการที่ทำการพัฒนา Software ให้ประสบผลสำเร็จ แบ่งเป็น 4Process ใหญ่ๆคือ

- Specification – เป็นกระบวนการกำหนดคุณสมบัติของ software ที่พัฒนา

- Development – เป็นขั้นตอนการพัฒนา software

- Validation – เป็นขั้นตอนการตรวจสอบความถูกต้องของ software ให้ตรงกับความต้องการ

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

Waterfall Model ประกอบด้วย 5 ขั้นตอน

- Requirement Definition : การกำหนดหรือระบุความต้องการของระบบและคุณสมบัติของความต้องการ

- System and Software Design : ออกแบบระบบ

- Implementation and Unit testing : ลงมือพัฒนาและทำการทดสอบ

- Integration and System testing : เอาแต่ละส่วนย่อยๆมาประกอบรวมกัน

- Operation and Maintenance : ติดตั้งใช้งานจริงและขั้นตอนการบำรุงรักษา โดยที่สามารถย้อนกลับไปทำขั้นตอนเดิมๆได้เมื่อเกิดปัญหา

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

ข้อเสีย : เมื่อผ่านขั้น Requirement ไปแล้ว และเราไปทำขั้นตอนอื่นๆ จะมายุ่งกับ Requirement อีกไม่ได้แล้วจนกว่าจะจบกระบวนการถึงจะกลับไปทำ Requirement อีกทีได้ ทำให้เสียเวลาสิ้นเปลืองทรัพยากร

Evolutionary Development

-                   การพัฒนาซอฟต์แวร์ในลักษณะพัฒนาเป็นวิวัฒนาการไปเรื่อยๆ

-                   เป็นการพัฒนาคุณสมบัติที่ต้องพัฒนาเพิ่มขึ้นเรื่อยๆ

Reuse-Oriented Development

1. พัฒนา ซอฟต์แวร์ใหม่ล้วนๆเลย โดยพัฒนาเป็นลักษณะ Object เพื่อเอากลับมาใช้ได้ใหม่อีก

2. พัฒนา ซอฟต์แวร์ไม่ทั้งหมด 100% แต่เราหา ซอฟต์แวร์อื่นๆที่พัฒนาแล้วมาเชื่อมกับของเรา                          

Process Iteration

การวนรูปพัฒนาซ้ำๆโดยที่วิธีการพัฒนาที่ทำซ้ำมี 2 ลักษณะใหญ่ๆคือ

- Incremental Development

- Spiral Development

Incremental Development

จะสอดคล้องกับ Model ต่างๆที่กล่าวไว้เป็นส่วนใหญ่ จะทำเป็นทีละส่วนย่อยๆแล้วนำไปทำการทดสอบหรือไม่ก็ส่งงานไปเหมือนกับเป็น Milestone ย่อยๆไป

ข้อดี :

- ถ้า Requirement เปลี่ยนแปลงก็สามารถนำรวมเข้าไปได้เรื่อยๆ

Spiral modal

แบ่งการพัฒนาเป็น 4 โซน

1. เป็นโซนของการวางแผนสำหรับ Phase ถัดๆไป

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

3. เป็นการวิเคราะห์ว่าจะมีความเสี่ยงอะไรบ้าง และสามารถสร้างทางเลือกเพื่อแก้ปัญหาอะไรได้บ้าง

4. ลงมือพัฒนาและทดสอบระบบ

ขั้นตอนที่เกี่ยวข้องกับ Requirement

1. ศึกษาความเป็นไปได้ - เป็นสิ่งแรกที่ควรจะทำในการพัฒนาระบบหรือ SW ใดๆ ซึ่งจะเป็นการศึกษาว่าคุ้มทุนหรือเปล่าที่จะสร้างหรือสร้างแล้วจะพบกับปัญหาอะไรมากน้อยแค่ไหน

2. เก็บรวบรวมและวิเคราะห์ Requirement - เกิดจากการสัมภาษณ์ผู้บริหารและผู้ปฏิบัติ ,ดูเอกสารและแบบฟอร์มต่างๆ , สังเกตจากการทำงานจริง และนำมาวิเคราะห์ได้ออกมาเป็น System model

3. กำหนด Specification – ซึ่งก็จะมีการวนกลับไปมาระหว่างการกำหนด Spec. และเก็บ Req.เพิ่มเติม ได้ออกมาเป็น User Requirement กับ System Requirement เขียนมาเป็นข้อๆชัดเจนว่าต้องการให้ระบบทำอะไรบ้าง

4. ตรวจสอบ Requirement ว่าถูกต้อง, ไม่คลุมเครือ และนำไปให้ผู้บริหารหรือผู้ใช้อ่านอีกครั้งว่าใช่หรือไม่ ซึ่งจะได้ออกมาเป็น Requirement document

กระบวนการออกแบบ

1.             Software specification

2.             Software design

3.             Software validation

4.             Software evolution

                                                                                                           นายอดุลวิทย์  อาหมัด 510702473611