ตอบคำถาม Chapter 3-4

คำถามบทเรียนที่ 3-4

1. จงสร้างปผนภูมิแกนต์ (Gantt Chart)

2. จงสร้างเครือข่าย PERT

3. โครงการนี้ใช้เวลาในการดำเนินงานกี่วัน

จากการพิจารณเครือข่าย PERT ในข้อที่ 2 สามารถนำมาคำนวณเป็นสายงานได้ 3 สายดังนี้

สายงานที่ 1 คือ P-Q-R-S = 31 วัน
สายงานที่ 2 คือ P-T-Z-S = 32 วัน
สายงานที่ 3 คือ X-Y-Z-S = 34 วัน
เนื่องจากโจทย์ไม่ได้กำหนดการเร่งระยะเวลาการดำเนินโครงการ ทำให้โครงการนี้มีระยะเวลา
การดำเนินงาน 34 วัน

4. จงหาเส้นทางวิกฤตพร้อมระบุกิจกรรมวิกฤต

จากข้อที่ 3 สายงานวิกฤตคือ สายงานที่ 3 ใช้ระยะเวลาดำเนินงานสูงสุด 34 วัน

ตอบคำถาม Chapter 2

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

- เป็นวิธีการวิเคราะห์ออกแบบเชิงโครงสร้าง
- มีการแบ่งระบบออกเป็นส่วนย่อยๆ
- มีลักษณะเป็นลำดับชั้น

 จุดด้อย 

- การวิเคราะห์และรวบรวมข้อมูลมีการแยกออกเป็นส่วนๆ ทำให้ใช้เวลานาน
- ต้นทุนสูง
- เนื่องจากใช้เวลานาน ทำให้เสี่ยงต่อการเปลี่ยนแปลงความต้องการของผู้ใช้
วิธีเชิงวัตถุ

วิธีเชิงวัตถุ (Object-Oriented Approach)

จุดเด่น

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

จุดด้อย 

- ต้องใช้ผู้ที่มีความสามารถความเชี่ยวชาญในการเขียนโปรแกรมสูง

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

Spiral Model ถูกพัฒนามากจากโครงสร้างพื้นฐานของ Waterfall Model ที่มีการแบ่งแยกขั้นตอน เช่น Concept OfOperation phase, Software Requirements phase, Design phase, Coding phase, Integrationphase, Implement phase เป็นต้น เนื่องจากใน Waterfall model สามารถ ส่งผลลัพธ์ที่ได้ป้อมกลับไปยังขั้นตอนก่อนหน้านั้นโดยที่ไม่ต้องมีการแก้ไขทุกขั้นตอนใหม่หมด แต่ Waterfall Model ยังไม่มีส่วนไปจะมีความสำเร็จที่เป็นไปได้มาน้อยขนาดไหน ฉะนั้น การใช้ Waterfall Model ในแต่ละขั้นตอนจะเกิดการ Feedback บ่อยครั้ง Spiral Model จึงถูกพันกับความเสี่ยงและความเป็นไปได้ที่เกิดขึ้นตลอดจนหาแนวทางแก้ไขเมื่อเกิดข้อผิดพลาด

3. ในฐานะที่นักศึกษาเป็นนักวิศวกรรมซอฟต์แวร์ ควรจะเลือกพิจารณาใช้แบบจำลองกระบวนการผลิตซอฟต์แวร์ (Software Process Model) แบบใด เพราะเหตูใด จงให้เหตุผลประกอบการเลือก

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

เหตุผล

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

ตอบคำถาม Chapter 1

1.1) จงยกตัวอย่างของผลกระทบของซอฟแวร์ ทั้งด้านบวกและด้านลบที่มีผลต่อสังคม

ผลในทางบวก
1.ช่วยส่งเสริมความสะดวกสบายของมนุษย์

2.ช่วยทำให้การผลิตในอุตสาหกรรมดีขึ้น มีคุณภาพมีมาตรฐานซึ่งในปัจจุบันใช้เครื่องจักรทำงานอย่างอัตโนมัติ สามารถทำงานได้ตลอด 24ชั่วโม

3.ช่วยส่งเสริมให้เกิดการค้นคว้าวิจัยสิ่งใหม่

4.ช่วยส่งเสริมสุขภาพและความเป็นอยู่ให้ดีขึ้นด้านการแพทย์เจริญก้าวหน้าขึ้นมาก 

5.ช่วยส่งเสริมสติปัญญาของมนุษย์ คอมพิวเตอร์มีจุดเด่นที่สามารถทำงานได้รวดเร็ว มีความแม่นยำ สามารถเก็บข้อมูลต่าง ๆ ได้มาก การแก้ปัญหาที่ ซับซ้อนบางอย่างกระทำได้ดี และรวดเร็ว

6.เทคโนโลยีสารสนเทศช่วยให้เศรษฐกิจเจริญรุ่งเรือง เทคโนโลยีจำเป็นต่ออุตสาหกรรม กิจการค้า ธุรกิจต่าง ๆ กิจการทางด้านธนาคาร ช่วยส่งเสริมงานทางด้านเศรษฐกิจ

7.ช่วยให้เกิดความเข้าใจอันดีระหว่างกัน การสื่อสารโทรคมนาคมสมัยใหม่ช่วยย่นย่อโลกให้เล็กลง โลกมีสภาพไร้พรมแดน มีการเรียนรู้วัฒนธรรมซึ่งกันและกันมากขึ้น

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

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

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

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

5.ทำให้การพัฒนาอาวุธมีอำนาจทำลายสูงมากขึ้น ประเทศที่เป็นต้นตำรับของเทคโนโลยี สามารถนำเอาเทคโนโลยีไปใช้ ในการสร้างอาวุธที่มีอานุภาพการทำลายสูง ทำให้หมิ่นเหม่ต่อสงครามที่มี การทำลายสูงเกิดขึ้น

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

1.2) จงอธิบายเกี่ยวกับ Software Crisis 

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

1.3)จงยกตัวอย่างซอฟต์แวร์ที่นักศึกษาว่าเป็นซอฟตแวร์ที่มีคุณภาพ แล้วนำมาวิเคาะห์หาคุณลักษณะของซอฟต์แวร์ที่ดี ว่าตรงตามคุณลักษณะใดบ้าง

ยกตัวอย่างซอฟต์แวร์ Microsoft Office

1.ด้านความน่าเชื่อถือ(Dependability) 

มีการอัปเดตเวอร์ชั่นที่ดีขึ้นเรื่อยๆ เป็นที่ใช้งานกันอย่างวแพร่หลาย การทำงานซอฟต์แวร์เป็นไปตามหลักการ

2.ด้านประสิทธิภาพ(Efficiency)

ซึ่งการทำงานที่มีมาตรฐานการทำงานที่สูงและมีประสิทธิภาพ ความผิดพลาดน้อยมาก การตอบสนอง และสิ้นเปลืองทรัพยากรน้อยมาก คุ้มค่า
3.ด้านการใช้งานที่ง่ายต่อผู้ใช้(Usability)

ออกแบบส่วนติดต่อกับผู้ใช้อย่างง่ายต่อการใช้งานมี icon ที่สื่อความหมายอย่างชัดเจนทำให้ใช้งานได้ง่ายขึ้น

3.ด้านการบำรุงรักษา(Maintainability)

การปรับปรุงการอัพเกรดเวอร์ชั่น ไฟล์ข้อมูลเก่ายังสามารถใช้ในเวอร์ชั่รใหม่ๆได้ ไม่ส่งผลต่อข้อมูลที่มีอยู่เดิม

4.ความแข็งแรง(Robustness)

กระบวนการสามารถทำงานต่อได้แม้นว่ามีปัญหาที่ไม่คาดการณ์เกิดขึ้น

1.4) นักศึกษาคิดว่า "นักวิศวกรซอฟต์แวร์" ควรมีทักษะความรู้ ความเชี่ยวชาญในด้านใดบ้าง จงอธิบาย

1.มีความรู้ ความสามารถในการเขียนและอ่านแบบจำลองของโครงสร้างโปรแกรม มีทักษะการเขียนโปรแกรมทางด้านคอมพิวเตอร์
2.ความซื่อสัตย์สุจริต การรักษาความลับของลูกค้าและนายจ้าง  

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

Chapter 5 Software Requirements

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

กระบวนการของวิศวกรรม Software เข้าใจถึงความต้องการของลูกค้า

1.ค้นหาความต้องการ

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

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

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

Type of Requirements  ประเภทของความต้องการ

1. User Requirement - เป็นความต้องการที่รวบรวมจากผู้ใช้ระบบโดยตรง เช่น ลำดับของช่องที่จะให้กรอกข้อมูล, จะกรอกอย่างไร, เรียงลำดับอย่างไร, ขนาดตัวอักษร, สีอะไร เป็นต้น
2. System Requirement – ความต้องการของระบบ เช่น ระบบต้องสามารถส่งข้อมูลผ่านระบบเครือข่ายได้, ข้อมูลต้องเก็บได้ทั้งที่ Server และ Work Station เป็นต้น

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

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

Software Specification 

รายละเอียดทางด้านเทคนิคของซอฟต์แวร์ว่าต้องทำอะไรได้บ้าง
ความต้องการแบ่งออกได้เป็น 3 กลุ่มใหญ่ ๆ

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

2. Non-functional Requirement คือ Requirement อื่นๆที่ไม่ใช่หน้าที่หลักๆที่ต้องทำ แต่เป็นคุณสมบัติอื่นๆที่เราอยากได้จากระบบ เช่น ความปลอดภัยของระบบ, ความเชื่อถือได้ของระบบ, เวลาตอบสนอง, มีความสามารถทางด้าน I/O, ความสามารถในการเชื่อมต่อกับระบบอื่นๆ ตัวอย่างเช่น ระบบบัญชี โดยที่หน้าที่หลักของระบบบัญชีคือ บันทึกข้อมูล Transaction รายวัน, จะต้องมีการทำสรุปยอดบัญชีได้ สิ่งเหล่านี้คือสิ่งที่ระบบบัญชีควรทำคือ Functional Requirement แต่ถ้าบอกว่าต้องมีการใส่รหัสผ่าน, สามารถเชื่อมโยงอินเทอร์เน็ตได้ , เชื่อมโยงกับระบบบัญชีของบริษัทอื่นได้ อันนี้ไม่ใช่หน้าที่หลัก ของระบบบัญชี แต่มันคือ Non-functional Requirement

3. Domain Requirement คือ เป็นเงื่อนไขอื่นจากสภาวะแวดล้อมที่ทำให้ระบบทำงานได้ หรือ เป็นการมองที่ว่าระบบที่พัฒนามานี้จะไปทำงานร่วมกับระบบอื่นๆหรือสภาวะแวดล้อมอื่นๆในองค์กร มันจะต้องมีความต้องการอื่นๆภายนอกมากระทบบ้างหรือไม่ เช่น เราออกแบบระบบบัญชี เมื่อนำไปใช้ จะไปทำงานร่วมกับระบบอื่นๆเช่นไปทำงานร่วมกับระบบการสมัครสมาชิกของ ชมรมคอมพิวเตอร์ ของ ม.นเรศวร โดยนำระบบบัญชีไปใช้ในส่วนการรับสมัคร เป็นต้น

Sequence Diagram

•Sequence Diagram เป็นแผนภาพที่ใช้อธิบายการทำงานของ Use Case เพื่อแสดงถึงขั้นตอนการทำงานและลำดับของการสื่อสาร (Message) ระหว่าง Object ที่ตอบโต้กัน
•Sequence Diagram จะแสดงอยู่ในรูปแบบ 2 มิติ โดยเส้นประแนวตั้ง (Lifeline) จะนำเสนอในด้านเวลา ส่วนเส้นแนวนอน (Message) จะนำเสนอเกี่ยวกับการโต้ตอบกันระหว่าง Object หรือ Class ต่างๆ

sequence diagram แสดงการทำงานของระบบ ATM

Chapter 4 Software Project Management

กิจกรรมที่ผู้จัดการโครงการต้องทำ คือ

• เขียนแบบเสนอโครงการ
• วางแผนและการตารางการทำงาน
• ประเมินต้นทุน ของการพัฒนาระบบ
• ติดตามและประเมินผล
• จัดสรรบุคลากรและประเมิน
• รายงานนำเสนอทุกๆช่วงรายงาน

Project Planning

 การวางแผนโปรเจคต้องจัดการบริหารตลอดทั้งโครงการ สำคัญที่สุดคือ เวลา และเครื่องมือที่นิยมนำมาวางแผน คือ Microsoft Project

• Quality Plan แผนคุณภาพของโครงการได้ตามที่วางแผนหรือไม่
• Validation Plan แผนใช้ในการตรวจสอบของความสมบูรณ์ของความต้องการและขั้นตอนการทำงาน
• Configuration Management Plan แผนการจัดการขั้นตอนโครงการ และสภาพแวดล้อม
• Maintenance Plan แผนบำรุงรักษาโครงการ วางแผนการบำรุงรักษาในอนาคต
• Staff Development Plan แผนการอบรมและประเมินบุคลากร

Project Plan Structure 

โครงสร้างสำคัญของโครงการ ประกอบด้วย

• บทนำ
• ลักษณะโครงสร้างองค์กร
• วิเคราะห์ความเสี่ยง
• ความต้องการของฮาร์ดแวร์ และซอฟต์แวร์
• แบ่งงานเป็นขั้นย่อยๆ
• ตารางการทำงานของโครงการ
• ติดตามและรายงาน

Chapter 3 Systems Engineering

Topics Covered

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

คุณสมบัติของระบบ

 คือน้ำหนักความสำคัญของระบบ ดูความผิดพลาด ลำดับความสำคัญก่อนหลัง วัดความน่าเชื่อถือของระบบ ความสามารถในการใช้งาน มี 2 ประเภท ดังนี้

1. คุณสมบัติที่เกี่ยวข้องกับการทำงานโดยตรง เช่น คีย์บอร์ด เป็นต้น
2. คุณสมบัติที่ไม่เกี่ยวข้องกับการทำงาน เช่น ความน่าเชื่อถือ ความปลอดภัย เป็นต้น

Intruder Alarm System

 ระบบสัญญาณเตือนภัย มีComponent ประกอบด้วย

1. Sensor รับขข้อมูลจากภายนอก เข้าสู่ระบบ ได้แก่ Movement Sensor
2. Actuator เปลี่ยนสภาพแวดล้อม เปลี่ยนสัญญาณ ได้แก่ Siren
3. Communication การติดต่อสื่อสาร ได้แก่ Telephone
4. Co-ordination โปรแกรมหลักในการทำงาน และประสานงานให้ระบบอื่นทำงาน ได้แก่ Alarm Controller
5. Interface การติดต่อผู้ใช้ รับและเสนอข้อมูล ได้แก่ Voice Synthesizer

The System Engineering Process 

กระบวนการวิศวกรรมระบบ นิยมใช้ Waterfall V-Model พัฒนาแบบคู่ขนานกันไป

Requirement Definition เก็บความต้องการของระบบจากผู้ใช้

-Functional Requirement มีฟังก์ชั่นการทำงานอะไรบ้างที่เกี่ยวข้องกับระบบ เช่น ตรวจสอบสิทธิ์
-Non-Functional Requirement มีฟังก์ชั่นการทำงานที่ไม่เกี่ยวข้องกับระบบ
-Unacceptable System การไม่ต้องการให้สิ่งนั้นเกิดขึ้นกับระบบ ถ้าเกิดข้อผิดพลาดจะแก้ไขอย่างไร เช่น การล้มของระบบ
ปัญหา ความต้องการเปลี่ยนโดยที่ระบบยังพัฒนาไม่เสร็จ เทคโนโลยีเปลียนทั้งซอฟต์แวร์และฮาร์ดแวร์ การเกิดปัญหาหลังการติดตั้ง

System Design การออกแบบระบบโดยรวมทั้งหมด

• Partition Requirement การแบ่งความต้องการ วิเคราะห์และแบ่งโครงสร้างด้วยวิธีที่เหมาะสม
• Identify sub-system กำหนดระบบย่อย นำระบบใหญ่มาแบ่งเป็นระบบย่อยๆที่เหมาะสม
• Assign requirement to sub-systems กำหนดความต้องการในแต่ล่ะระบบย่อย ต้องสอดคล้องกับความต้องการของระบบทั้งหมด กำหนดส่วนประสานของระบบย่อย ให้สามารถผสานกันได้
• Specify sub-systems functionality กำนหดหน้าที่การทำงานของระบบย่อย
• Define sub-systems interfaces การทำให้แต่ละระบบย่อยให้สามารถสื่อสารกับระบบย่อยๆกันอย่างไร

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

Sub-System Development การพัฒนาระบบย่อยๆ 

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

System Integration นำระบบย่อยๆมารวมกัน และพัฒนาร่วมกัน 

โดยนำระบบที่มีความสำคัญมาผสมผสานกันก่อน เพื่อป้องกันการล้มของระบบ

System Installation ติดตั้งระบบการใช้งานาน

ปัญหา สภาพแวดล้อมและทางกายภาพไม่ตรงกับที่คิดไว้ การต่อต้านจากผู้ใช้ การวางแผนฝึกอบรมให้ผู้ใช้ ไม่ใช้ระบบตามที่ออกแบบมา การเริ่มใช้งานของะบบใหม่กับระบบอื่น
System Evolution ปรับปรุงระบบหลังการใช้งานไประยะหนึ่ง หรือUpdate Version
ปัญหา เกิดความต้องการใหม่ ความต้องการเปลี่ยน เกิดต้นทุนเพิ่มขึ้นในการพัฒนา
System Decommissioning การปลดระวางหรืเลิกใช้งาน ระบบเดิมต้องทำการเชื่อมต่อกับระะบใหม่ให้ได้ก่อนที่จะปลดละวาง โดยมีการสำรองข้อมูลไว้เพื่อป้องกันการผิดพลาด

Chapter 2 Software Process

กระบวนการซอฟต์แวร์ (Software Process)

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

กิจกรรมพื้นฐานทั้งหมด 4 กิจกรรม ที่ใช้กับกระบวนการผลิตซอฟต์แวร์

1. software specification

นิยามหน้าที่ต่างๆที่ต้องมีในซอฟต์แวร์ และระบุข้อจำกัดต่างๆ ที่เกี่ยวข้องกับกระบวนพัฒนาซอฟต์แวร์ เช่น กฎหมาย , อัตราภาษี , กฎระเบียบต่างๆที่เกี่ยวในการพัฒนาซอฟต์แวร์ 

2. Software Design and Implementation

กิจกรรมนี้ทำการสร้าง / พัฒนาซอฟต์แวร์ให้ตรงกับข้อกำหนด (specification) 

3. software validation

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

4. software evolution

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

Waterfall model

ขั้นตอนแบบน้ำตก

• การวิเคราะห์ความต้องการและความหมาย
• ออกแบบระบบซอฟแวร์
• การดำเนินงานและการทดสอบ
• บูรณาการและการทดสอบระบบ
• การดำเนินงานและการบำรุงรักษา

ข้อเสียเปรียบหลักของน้ำตกจำลองเป็นความยากลำบากของการเปลี่ยนแปลงรองรับหลังจากกระบวนการเป็นชิ้น ระยะหนึ่งจะต้องมีสมบูรณ์ก่อนที่จะย้ายไปยังขั้นตอนต่อไป

Evolutionary development

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


ปัญหา

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

Spiral model of the software process

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

Chapter 1 Introducation to Software Engineering

วิศวกรรมซอฟต์แวร์ คืออะไร

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

ความแตกต่างระหว่างวิทยาการคอมพิวเตอร์และวิศวกรรมซอฟต์แวร์

วิทยาการคอมพิวเตอร์ (Computer Science)
อยู่บนรากฐานของวิทยาศาสตร์ ซึ่งเน้นการทำความเข้าใจและค้นหาความจริงเกี่ยวกับความรู้ทางคอมพิวเตอร์ เพื่อสร้างแนวคิด/ทฤษฎีใหม่ หรือ ปฏิเสธแนวคิด/ทฤษฎีเดิม และขยายวงความรู้ให้กว้างขึ้นจากแนวคิด/ทฤษฎีที่มีอยู่

วิศวกรรมซอฟต์แวร์ (Software Engineering)

อยู่บนรากฐานของวิธีการทางวิศวกรรมศาสตร์ ซึ่งประยุกต์แนวคิด/ทฤษฎีทางวิทยาศาสตร์ คณิตศาสตร์และเทคโนโลยีขณะนั้นในการสร้างผลิตภัณฑ์ที่เป็นประโยชน์และปลอดภัยต่อสาธารณะ

ประเด็นความรับผิดชอบอย่างมืออาชีพ

1.วิศวกรรมซอฟต์แวร์จะต้องรักษาความลับของลูกค้าหรือนายจ้าง
2.วิศวกรรมซอฟต์แวร์ไม่ควรอวดวามสามารถที่ไม่เป็นจริง และไม่ควรรับงานที่ไม่ถนัด
3.วิศวกรรมซอฟต์แวร์ควรใช้ความถนัดทางด้านเทคนิก
4.วิศวกรรมซอฟต์แวร์ควรระมัดระวังไม่ให้ละเมิดกฎหมายท้องถิ่น

หน่วยงานที่กำหนดประมวลจริยธรรม Code of Ethics คือ ACM/IEEE ให้กับวิศวกรรมซอฟต์แวร์ มีข้กำหนด 8 ข้อดังนี้

1.PUBLIC วิศวกรรมซอฟต์แวร์จะต้องปฎิบัติหน้าที่โดยคำนึงถึงผลประโยชน์ส่วนรวมด้วย
2.CLIENT AND EMPLOYER วิศวกรรมซอฟต์แวร์จะต้องคำนึงถึงความต้องการของลูกค้าและนายจ้าง
3.PRODUCT วิศวกรรมซอฟต์แวร์จะต้องผลิตผลงานตามหลักสูงสุดของหลักวิชาการ
4.JUDGMENT วิศวกรรมซอฟต์แวร์จะต้องตัดสินใจอย่างอิสระ เป็นตัวของตัวของตัวเอง โดยยึดมั่นในหลักวิชาการ
5.MANAGEMENT วิศวกรรมซอฟต์แวร์จะต้องเผยแพร่การรักษาจริยธรรมนี้ ในฐานะผู้บริหาร หรือหัวหน้า
6.PROFESSION วิศวกรรมซอฟต์แวร์จะต้องยึดมั่นในคุณธรรม และรักษาชื่อเสียงในวิชาชีพโดยคำนึงถึงผลปรโยชน์ส่วนรวม
7.COLLEAGUES วิศวกรรมซอฟต์แวร์จะต้องให้ความเป็นธรรม และสนับสนุนเพื่อนร่วมงาน
8.SELF วิศวกรรมซอฟต์แวร์จะต้องพัฒนาตัวเองอยู่เสมอ

ความรับผิดชอบทางจริยธรรมของนักวิศวกรรมซอฟต์แวร์

1. ความลับ นักวิศวกรรมซอฟต์แวร์ จะต้องรักษาความลับของลูกค้าและนายจ้างแม้จะไม่มีการลง
นามเป็นรายลักษณ์อักษร
2. ความสามารถ ไม่อวดความสามารถที่ไม่เป้นจริงและไม่ควรรับงานที่ไม่ถนัด
3. เคารพสิทธิทางปัญญา จะต้องระมัดระวังไม่ละเมิดกฎหมาย
4. ไม่ควรใช้ความถนัดทางด้านเทคนิคการใช้งานคอมพิวเตอร์ ผิดวัตถุประสงค์ เช่น ปล่อยไวรัส

คุณสมบัติของซอฟต์แวร์ที่ดี

1.Maintainability ต้องมีความสามารถในการบำรุงรักษา จะต้องมีการเปลี่ยนแปลงเพื่อตอบสนองต่อความต้องการของผู้ใช้ที่เปลี่ยนแปลงไป การเปลี่ยนแปลงจะต้องไม่ส่งผลกระทบต่อการทำงานของระบบ
2.Dependability ความสามารถในการพึ่งพา ความน่าเชื่อถือ ต้องผ่านการตรวจสอบในทุกฟังก์ชัน
3.Efficiency ความสามารถในด้านประสิทธิภาพ เช่น ประหยัดทรัพยากรของเครื่อง
4.Usability ความสามารภในการใช้งาน เช่น ความสะดวก ความปลอดภัย สามารถเรียนรู้การใช้งานได้เร็ว

Chapter 11 User Interface Design

กระบวนการออกแบบหน้าจอ UI (User Interface)

ตัวอย่าง เทคนิคการประเมิน User Interface

-แบบสอบถาม user feedback

-บันทึกวีดีโอ user เมื่อใช้ระบบ ว่ามีความรู้สึกอย่างไรบ้าง

-เขียนโปรแกรมทำหน้าที่แอบเก็บข้อมูลการใช้งานของ user ว่า user ทำอะไรบ้าง

-เพิ่มช่องทาง comment ในโปรแกรม

การนำเสนอข้อมูล

1. แบบ Static Information – จะถูกกำหนดไว้ในตอนเริ่มต้น และไม่มีการเปลี่ยนแปลงอีก 
2. แบบ Dynamic Information จะมีการเปลี่ยนแปลงข้อมูลระหว่างการทำงานกับ user
2.1 แบบ Digital จะเน้นเป็นแบบตัวเลข เป็นการ Sampling ค่าขึ้นมา
2.2 แบบ Analogue เน้นการแสดงผลเป็นแบบรูปภาพ ค่าต่อเนื่องกันไป 

ปัจจัยที่จะดูว่าเมื่อไรควรจะใช้การนำเสนอแบบใด

1. ดูว่าต้องการข้อมูลขัดเจนแค่ไหน 
2. ต้องการความเร็วในการแสดงข้อมูลหรือไม่
3. ต้องการที่จะให้มีการทำอะไรด้วยหรือเปล่า 
4. ถ้าเป็นการแสดงผลแบบ Direct manipulation จะต้องเป็นการนำเสนอข้อมูลแบบ Dynamic
5. ต้องการข้อมูลเป็นตัวเลขหรือไม่ 
6. การเปรียบเทียบข้อมูลสำคัญแค่ไหน 

การใช้สี

- อย่าใช้สีมากเกินไป 
- อนุญาตให้ user ปรับแต่งการใช้สีได้
- พยายามใช้สีที่คงเส้นคงวา สอดคล้องกัน เช่น ฟอร์มรับข้อมูลควรจะมีสีโทนเดียวกัน
- หลีกเลี่ยงสีที่ตัดกัน 
- เปลี่ยนสีถ้าสถานะมีการเปลี่ยนแปลงไป
- ระวังเรื่องสีที่ไม่สามารถแสดงได้ในบาง Resoltion อย่างในเว็บเพจ สีที่แสดงออกมาได้จริง ( ประมาณ 255 สี ) ในเครื่องทั่วไปส่วนใหญ่เราจะเรียกว่า Safe Color Pallette 

Chapter 8 Architectural Design

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

8.2 กระบวนการออกแบบซอฟต์แวร์
        กระบวนการออกแบบซอฟต์แวร์ (Software Design Process) จะมีลักษณะการทำงานแบบซ้ำๆ เนื่องจากต้องนำความต้องการของระบบที่ผ่านมาวิเคราะห์แล้วในแต่ละด้าน ทั้งด้านข้อมูล ฟังก์ชัน และส่วนประกอบ มาแปลงเป็นข้อกำหนดของการออกแบบ ดังนั้น ข้อกำหนดการออกแบบจึงสอดคล้องกับข้อกำหนดความต้องการและสามารถใช้สื่อสารกับโปรแกรมเมอร์ได้ กระบวนการออกแบบนั้นจะประกอบไปด้วยการออกแบบใน 2 ระดับ ได้แก่ การออกแบบเชิงสถาปัตยกรรม และการออกแบบในรายละเอียด
        การออกแบบเชิงสถาปัตยกรรม (Architectural Design) เรียกอีกอย่างหนึ่งว่า Top-Level Design เป็นการกำหนดลักษณะโครงสร้างของระบบหรือซอฟต์แวร์ในมุมมองระดับบน กล่าวคือ เป็นการแสดงให้เห็นส่วนประกอบต่างๆ ของซอฟต์แวร์ภายใต้โครงสร้างสถาปัตยกรรมรูปแบบใดๆ
        การออกแบบในรายละเอียด (Detail Design) เรียกอีกอย่างหนึ่งว่า Implementation Design เป็นการอธิบายรายละเอียดของแต่ละส่วนประกอบของซอฟต์แวร์ เพื่อเอื้ออำนวยต่อการเขียนโปรแกรมให้มากที่สุด

8.3 สถาปัตยกรรมและโครงสร้างสถาปัตยกรรมซอฟต์แวร์ 
        สิ่งสำคัญที่ควรทราบสำหรับการออกแบบซอฟต์แวร์คือ สถาปัตยกรรม และโครงสร้างสถาปัตยกรรมซอฟต์แวร์ (Software Architecture and Architecture Structure)
        สถาปัตยกรรมซอฟต์แวร์ (Software Architecture) หมายถึง การแสดงความสำพันธ์ระหว่างระบบย่อยและส่วนประกอบ (คอมโพเน้นท์) เพื่อกำหนดโครงสร้างหรือระบบภายในซอฟต์แวร์
      
        8.3.1 โครงสร้างสถาปัตยกรรมและมุมมอง
                โครงสร้างสถาปัตยกรรมนั้น เกิดขึ้นจากมุมมองและแนวคิดในการออกแบบที่มีความหลากหลายในปัจจุบัน เนื่องจากการออกแบบซอฟต์แวร์ ก็คือการกำหนดรายละเอียดในแต่ละมุมมองของซอฟต์แวร์ แล้วนำมาประกอบกันเป็นซอฟต์แวร์ ลักษณะของโครงสร้างเมื่อรวมส่วนประกอบย่อยต่างๆ ของซอฟต์แวร์เข้าด้วยกันแล้ว ก็คือ สถาปัตยกรรมซอฟต์แวร์ ชนิดต่างๆ ที่มีการทำงานแตกต่างกันออกไป แต่ละชนิดมีวัตถุประสงค์เพื่อให้ซอฟต์แวร์ที่งานในลักษณะเฉพาะที่แตกต่างกัน บางชนิดมีลักษณะโครงสร้างของการประกอบรวมซอฟต์แวร์เหมือนกันแต่ทำงานได้ต่างกัน โครงสร้างสถาปัตยกรรมซอฟต์แวร์ จึงถูกกำหนดขึ้น เพื่อควบคุมสถาปัตยกรรมซอฟต์แวร์ที่หลากหลายดังกล่าวนั่นเอง
                รูปแบบสถาปัตยกรรม หมายถึง ข้อบังคับหรือกฏเกณฑ์ทางด้านสถาปัตยกรรม ที่จัดตั้งขึ้นมา เพื่อจำแนกกลุ่มหรือหมวดหมู่ของสถาปัตยกรรมซอฟต์แวร์ ปัจจุบันมีการกำหนดรูปแบบสถาปัตยกรรมขึ้นมาหลากหลาย สามารถแบ่งออกเป็น 5 กลุ่ม ดังนี้
                1. กลุ่มสถาปัตยกรรมแบบโครงสร้างทั่วไป (General Structure) เช่น สถาปัตยกรรมแบบ Layer, Pipe and Filter และ Blackboard เป็นต้น
                2. กลุ่มสถาปัตยกรรมแบบกระจาย (Distributed System) เช่น สถาปัตยกรรมแบบ Client/Server, Three Tiers และ Broker เป็นต้น
                3. กลุ่มสถาปัตยกรรมระบบแบบโต้ตอบ (Interactive System) เช่น สถาปัตยกรรมแบบ Model-View-Controller และ Presentation-Abstraction-Control เป็นต้น
                4. กลุ่มสถาปัตยกรรมระบบที่สามารถดัดแปลงได้ (Adaptable System) เช่น สถาปัตยกรรมแบบ Micro-Kernel และ Reflection เป็นต้น
                5. กลุ่มสถาปัตยกรรมระบบแบบอื่นๆ เช่นสถาปัตยกรรมแบบ Batch, Interpreter, Process Control และ Rule based เป็นต้น
        8.3.2 แบบแผนการออกแบบ
                แบบแผน (Patten) หมายถึง วิธีแก้ปัญหาที่มีรูปแบบเป็นกลาง เพื่อใช้กับปัญหาทั่วไปตามลักษณะของปัญหาที่ระบุในวิธีแก้ปัญหา แบบแผนการออกแบบในระดับจุลภาค ถูกกำหนดขึ้นเนื่องจากรูปแบบสถาปัตยกรรมแสดงถึงโครงสร้างในระดับบนของสถาปัตยกรรมเท่านั้น ไม่สามารถแสดงให้เห็นถึงระดับรายละเอียดปลีกย่อยอื่นๆ ที่ประกอบอยู่ภายในสถาปัตยกรรมรูปแบบนั้นได้ โดย Design Pattern ในระดับจุลภาคถูกแบ่งออกเป็น 3 กลุ่ม ดังนี้
        1. แบบแผนในกลุ่มการสร้าง (Creational Pattern) เช่น Builder, Factory, Prototype และ Singleton เป็นต้น
        2. แบบแผนในกลุ่มโครงสร้าง (Structural Pattern) เช่น Adapter, Bridge, Composite, Decorator, Fa?ade, Flyweight และ Proxy เป็นต้น
        3. แบบแผนในกลุ่มพฤติกรรม (Behavioral Pattern) เช่น Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, และ Visitor เป็นต้น
        8.3.3 กลุ่มของซอฟต์แวร์และ Framework
                วิธีการอย่างหนึ่งที่ช่วยสนับสนุนการออกแบบซอฟต์แวร์และคอมโพเน้นของซอฟต์แวร์ ให้สามารถนำกลับมาใช้ใหม่ได้ก็คือ การกำหนดเป็นกลุ่มของซอฟต์แวร์ (Families of Software) ขึ้น ซึ่งรู้จักกันในชื่อ Software Product Line

8.4 คุณภาพและการประเมินคุณภาพงานออกแบบซอฟต์แวร์
        8.4.1 เกณฑ์คุณภาพ (Quality Attribute)
                1. การทำงานของโปรแกรม (Functionality) จะประเมินจากลักษณะ (Feature Set) และความสามารถ (Capability) ของโปรแกรม นอกจากนี้ ยังประเมินจากหน้าที่ทั่วไปของโปรแกรม และความปลอดภัยเมื่อต้องทำงานรวมเป็นระบบ
                2. ความสามารถในการใช้งาน (Usability) พิจารณาจากผลตอบกลับจากการใช้งานของผู้ใช้ ไม่ว่าจะเป็นการใช้งานง่าย และเรียนรู้ง่าย
                3. ความน่าเชื่อถือ (Reliability) วัดจากความถี่และความรุนแรงของความผิดพลาดที่เกิดขึ้น ความถูกต้องของผลลัพธ์ที่ได้ เวลาเฉลี่ยของความล้มเหลว (Mean-Time-To-Failure:MTTF) ความสามารถในการกู้คืนระบบ และความสามารถในการคาดการณ์ได้ของโปรแกรม
                4. ประสิทธิภาพ (Performance) วัดจากความเร็วของการประมวลผล ระยะเวลาตอบสนอง ทรัพยากรที่ใช้ ปริมาณที่ทำได้ในช่วงเวลาหนึ่ง และประสิทธิผลในการทำงาน
                5. ความสามารถในการสนับสนุนการใช้งาน (Supportability) และความสามารถในการบำรุงรักษา (Maintainability) พิจารณาจากความสามารถในการเพิ่มเติมส่วนกรทำงาน ความสามารถในการแปลงการทำงาน และการบริการ ยังพิจารณาจากความสามารถในการทดสอบ การทำงานข้ามระบบได้ และการจัดสภาพแวดล้อมของระบบด้วย
        8.4.2 การวิเคราะห์และประเมินคุณภาพ (Quality Analysis and Evaluation)
                การวิเคราะห์และการประเมินคุณภาพเป็นกิจกรรมที่ช่วยให้มั่นใจว่าซอฟต์แวร์ที่ถูกออกแบบไว้จะต้องมีคุณภาพโดยทีมงานสามารถใช้เครื่องมือและเทคนิคต่างๆ ในการวิเคราะห์และประเมิน ซึ่งแบ่งตามกิจกรรมได้ดังนี้
                1. ทบทวนงานออกแบบซอฟต์แวร์ (Software Design Review) เทคนิคที่ช่วยให้การทบทวนงานออกแบบมีประสิทธิภาพ ได้แก่ Group-Based Technique เป็นเทคนิคในการตรวจสอบและปรับปรุงคุณภาพของงานออกแบบ เช่น การทบทวนสถาปัตยกรรมซอฟต์แวร์ และการตรวจสอบอย่างละเอียด เป็นต้น
                2. วิเคราะห์งานออกแบบ (Static Analysis)  ผลที่ได้จากการวิเคราะห์จะนำไปประเมินคุณภาพของงานออกแบบ เทคนิคที่ช่วยใช้การวิเคราะห์มีประสิทธิภาพ เช่น Fault-tree Analysis, Auto-cross Checking เป็นต้น
                3. การจำลองสถานการณ์และการสร้างต้นแบบ (Simulation and Prototyping) เช่น การจำลองเหตุการณ์ประสิทธิภาพของซอฟต์แวร์ และการสร้างต้นแบบซอฟต์แวร์เพื่อทดสอบความเป็นไปได้ เป็นต้น
        8.4.3 การวัด (Measure)
                การวัดสามารถใช้กับการประเมินหรือการประมาณการคุณลักษณะบางอย่าง เช่น ขนาด โครงสร้าง หรือคุณภาพ ของซอฟต์แวร์ได้ แต่การวัดคุณภาพของการออกแบบซอฟต์แวร์จะแบ่งออกเป็น 2 ประเภท ดังนี้
                1. การวัดการออกแบบเชิงฟังก์ชัน (Function-Oriented Measure) ใช้กับซอฟต์แวร์ที่ออกแบบด้วย แนวคิดเชิงโครงสร้าง ที่มีการแบ่งระบบใหญ่ออกเป็นระบบย่อยตามหน้าที่ เรียกว่า โมดูล และนำเสนอด้วยแผนภาพเชิงโครงสร้าง การวัดคุณภาพประเภทนี้จึงสามารถวัดได้จากคุณลักษณะของโมดูล เช่น Coupling Cohesion
                2. การวัดการออกแบบเชิงวัตถุ (Object-Oriented Design Measure) ใช้กับซอฟต์แวร์ที่ถูกออกแบบด้วยแนวทางเชิงวัตถุ ที่มีการจัดให้ทุกสิ่งของระบบเป็นวัตถุ และนำเสนอโครงสร้างของซอฟต์แวร์ด้วย Class Diagram การวัดคุณภาพประเภทนี้ จึงสามารถวัดได้จากลักษณะภายในคลาส เช่น การวัดความสัมพันธ์ระหว่าคลาส การนับจำนวนการโต้ตอบกันระหว่างเมธอดของคลาส
      
          8.4.4 หลักการออกแบบซอฟต์แวร์
        เนื่องจากการออกแบบซอฟต์แวร์ต้องคำนึงถึงคุณภาพของซอฟต์แวร์ที่จะผลิตด้วย ดังนั้น ทีมงานจึงควรใช้แนวทางการออกแบบบางประการ เพื่อนำไปสู่การออกแบบที่ดี ดังนี้
        1. การออกแบบควรแสดงให้เห็นถึงรูปแบบสถาปัตยกรรมที่เลือกใช้อย่างชัดเจนและมีแบบแผน        2. การออกแบบควรมิลักษณะเป็นโมดูล
        3. การออกแบบควรนำเสนอด้านข้อมูล สถาปัตยกรรม ส่วนประสาน และคอมโพเน้นท์ที่ชัดเจน
        4. ควรออกแบบคอมโพเน้นท์ให้มีอิสระต่อกัน
        5. ควรออกแบบให้ส่วนประสานระหว่างคอมโพเน้นท์กับสภาพแวดล้อมภายนอกมีความซับซ้อนน้อยที่สุด
        6. การออกแบบควรนำข้อมูลมาจากการวิเคราะห์ระบบ และใช้ระเบียบวิธีปฏิบัติเดียวกัน
        7. สัญลักษณ์ที่ใช้ในการออกแบบควรสื่อความหมายได้ชัดเจน และเป็นมาตรฐาน
        8. งานออกแบบควรมีโครงสร้างที่ดี เพื่อการแก้ไขที่ง่ายและใช้ต้นทุนน้อย
        9. การออกแบบในระดับคอมโพเน้นท์มีลักษณะแบบ Functional Independence คือ ฟังก์ชันงานมีความเป็นอิสระต่อกัน ไม่ขึ้นต่อกัน
        10 คอมโพเน้นท์ของซอฟต์แวร์จะต้องมีลักษณะการขึ้นต่อกันน้อยที่สุด (Loosely Coupled)

8.5 แนวคิดในการออกแบบซอฟต์แวร์
        การคิดแบบนามธรรม (Abstraction)
                เป็นพื้นฐานทางความคิดในการออกแบบอย่างหนึ่ง ที่ช่วยลดความซับซ้อนของระบบลงได้ เมื่อมีการพิจารณาถึงแนวทางแก้ไข ของแต่ละปัญหา จะเกิดการคิดแบบเป็นนามธรรมขึ้นเป็นระดับ ได้แก่ Procedural Abstraction เป็นการสร้างลำดับขั้นตอนของชุดคำสั่งของฟังก์ชันใดฟังก์ชันหนึ่งขึ้นมา โดยจะไม่ระบุถึงรายละเอียดภายในฟังก์ชั่น  และ Data Abstraction คือชื่อ็อบเจ็กต์ข้อมูลที่อยู่ใน Procedural Abstraction

        สถาปัตยกรรม (Architecture)
                เป้าหมายของการออกแบบสถาปัตยกรรม ก็เพื่อเป็นกรอบให้กับการออกแบบส่วนประกอบที่เหลือของระบบ ให้เป็นไปในทิศทางเดียวกัน และอยู่บนสถาปัตยกรรมเดียวกันนั่นเอง การออกแบบโครงสร้างหรือสถาปัตยกรรมสามารถนำเสนอออกมาในรูปแบบจำลอง 4 ชนิด ได้แก่ Structural Model, Framework Model, Dynamic Model, Process Model, และ Functional Model

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

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

        ความเป็นอิสระต่อกันในการทำงาน (Functional Independence)
                Coupling เป็นการวัดความสัมพันธ์ระหว่างโมดูล 2 โมดูลว่ามีความซับซ้อนหรือมีระดับการขึ้นต่อกันของโมดูลมากน้อยเพียงใด
                Cohesion เป็นการวัดระดับการยึดเกาะกันของหน้าที่หรือกิจกรรมในโมดูล เพื่อประมวลข้อมูลเป็นผลลัพธ์ที่ต้องการ ลักษณะโครงสร้างที่ดีจะต้องมีระดับการยึดเกะกันของหน้าที่ในโมดูลสูง

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

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

        Design Class
                สำหรับการวิเคราะห์ระบบด้วยแนวทางเชิงวัตถุ เมื่อจบขั้นตอนการวิเคราะห์ระบบแล้ว สิ่งที่ได้คือ แบบจำลองคลาส ที่แสดงเพียงมุมมองของระบบในระดับบนเท่านั้น เมื่อมาถึงขั้นตอนการออกแบบ วิศวกรซอฟต์แวร์จะต้องนำแบบจำลองคลาสเหล่านั้น มากลั่นกรองเพื่อกำหนดรายละเอียดเชิงลึกของแต่ละคลาสอีกครั้ง เพื่อให้เขียนโค้ดได้ง่ายขึ้น และต้องสร้างแบบจำลองคลาสที่แสดงให้เห็นถึงโครงสร้างภายในที่สนับสนุนกระบวนการทางธุรกิจด้วย และสิ่งที่ได้คือ Design Class ซึ่งประกอบไปด้วย Design Class 5 ชนิด แบ่งตาม Layer ของสถาปัตยกรรมระบบ ได้แก่ User Interface Class, Business Domain Class, Process Class, Persistent Class และ System Class

8.6 กลยุทธ์และระเบียบวิธีของกาสรออกแบบซอฟต์แวร์
        กลยุทธ์ในการอกแบบซอฟต์แวร์ เป็นเพียงหลักและแนวทางในการปฏิบัติงานแบบซอฟต์แวร์เท่านั้น ไม่ได้ระบุถึงวิธีทำงานอย่างชัดเจน แต่สำหรับระเบียบวิธี ในการออกแบบซอฟต์แวร์จะระบุถึงรายละเอียดของวิธีการทำงานอย่างชัดเจน พร้อมกับเตรียมสัญลักษณ์ต่างๆ ของแบบจำลองเฉพาะระเบียบวิธีนั้นไว้ให้ใช้งานด้วย ทำให้ทีมวิศวกรซอฟต์แวร์ทำงานได้ง่ายขึ้น ปัจจุบัน กลยุทธ์และระเบียบวิธีในการออกแบบซอฟต์แวร์มีหลายวิธี สรุปได้ดังนี้
        กลยุทธ์ทั่วไปในการออกแบบซอฟต์แวร์ (General Strategy)
                กลยุทธ์ทั่วไปในการออกแบบซอฟต์แวร์ได้แก่ Divide-and Conquer, Stepwise Refinement, Top-down and Bottom-up Strategy, Data Abstraction and Information Hiding, Heuristic และ Design Pattern เป็นต้น

        การออกแบบเชิงฟังก์ชัน (Function-Oriented Design)
                คือ การออกแบบเชิงโครงสร้าง ซึ่งเป็นระเบียบวิธีที่ได้รับความนิยมมาตั้งแต่อดีตจนถึงปัจจุบันเป็นวิธีในการพิจารณาถึงฟังก์ชันของซอฟต์แวร์เป็นเกณฑ์ในการแบ่งส่วนซอฟต์แวร์ออกเป็นส่วนย่อย จากนั้นจะกำหนดรายละเอียดในแต่ละส่วนย่อยของซอฟต์แวร์และปรับปรุงในลักษณะโครงสร้างลำดับขั้นจากบนลงล่าง

        การออกแบบเชิงวัตถุ (Object-oriented Dsign)
                ระเบียบวิธีเชิงวัตถุในปัจจุบันมีหลากหลายวิธี ในยุคแรกของระเบียบวิธีการออกแบบเชิงวัตถุ จะพิจารณาหาวัตถุในโดเมนที่สนใจจากคำอธิบายความต้องการของลูกค้า และจัดโครงสร้างของอ็อบเจ็กต์แบบ Inheritance และ Polymorphism ต่อมา ได้มีระเบียบวิธีการออกแบบซอฟต์แวร์แบบคอมโพเน้นท์ (Component-base Design) ขึ้นมา เพื่อช่วยให้การผลิตซอฟต์แวร์รวดเร็วขึ้น

        การออกแบบโดยใช้ข้อมูลเป็นศูนย์กลาง (Data-structure Centered Design)
                เป็นวิธีการออกแบบโดยใช้ข้อมูลที่ฟังก์ชันจะนำมาประมวลผลเป็นหลัก เริ่มต้นจากการแสดงโครงสร้างข้อมูล ทั้งที่เป็นข้อมูลนำเข้าและผลลัพธ์ (Input and Output Data) โดยสร้างเป็นแผนภาพเพื่อจำลองโครงสร้างของข้อมูลเหล่านั้น ยกตัวอย่างแผนภาพเช่น Jackson Diagram เป็นต้น จากนั้น ทีมงานจะนำแผนภาพดังกล่าวไปออกแบบโครงสร้างควบคุมการทำงานของโปรแกรมต่อไป

        การออกแบบคอมโพเน้นท์ (Component-base Design: CBD)
                เป็นวิธีการออกแบบซอฟต์แวร์ด้วยการแบ่งเป็นส่วนประกอบย่อยที่เรียกว่า คอมโพเน้นท์ จะทำงานเป็นอิสระต่อกัน ทำงานได้ด้วยตนเอง และสามารถประกอบกับคอมโพเน้นท์อื่นเพื่อเติมเต็มการทำงานให้กับซอฟต์แวร์ได้ ดังนั้น จึงต้องมีการสื่อสารระหว่างคอมโพเน้นท์ผ่านทาง Interface ได้ถูกพัฒนาขึ้นพื่อตอบสนองความต้องการผลิตซอฟต์แวร์ที่สามารถนำกลับมาใช้ใหม่ได้

8.7 แบบจำลองที่ใช้ในการออกแบบ 
        จำแนกได้เป็น 2 กลุ่ม ดังนี้
        กลุ่ม Structural Description (Static View) เป็นแบบจำลองที่ใช้อธิบายมุมมองด้านโครงสร้างของซอฟต์แวร์โดยแสดงให้เห็นรายละเอียดของแต่ละคอมโพเน้นท์และความสัมพันธ์ระหว่างคอมโพเน้นท์ด้วย แบบจำลองในกลุ่มนี้ อาจอธิบายโครงสร้างด้วยแผนภาพหรือข้อความ ได้แก่
        Architecture Description Language ADU ใช้อธิบายสถาปัตยกรรมซอฟต์แวร์แบบคอมโพเน้นท์และการเชื่อมต่อคอมโพเน้นท์
        Class And Object Diagram แผนภาพแสดงโครงสร้างของคลาส (อ็อบเจ็กต์) และความสัมพันธ์ระหว่างคลาส
        Component Diagram แผนภาพแสดงคอมโพเน้นท์ที่เป็นส่วนประกอบของระบบ และแสดงความสัมพันธ์ระหว่างคอมโพเน้นท์ นอกจากนี้ยังแสดงให้เห็น Interface ของคอมโพเน้นท์ด้วย
        Collaboration Responsibility Card CRC ใช้บันทึกชื่อคอมโพเน้นท์ (คลาส)  พร้อมกับคอมโพเน้นท์ที่มีความสัมพันธ์กันและหน้าที่ของคอมโพเน้นท์ด้วย
        Deployment Diagram แผนภาพแสดงโครงสร้างทางด้านฮาร์ดแวร์ (โหนด) ของระบบและความสัมพันธ์ระหว่างโหนดชนิดต่างๆ
        Entity Relationship Diagram ERD แผนภาพแสดงความสัมพันธ์ระหว่าง Entity ใช้แสดงโครงร่างของฐานข้อมูล
        Interface Description Language IDL มีลักษณะคล้ายกับการเขียนคำสั่งในโปรแกรม ใช้กำหนดรายละเอียดของ Interface
        Jackson Structure Diagram แผนภาพแสดงโครงสร้างควบคุมการประมวลผลข้อมูลแบบเรียงลำดับแบบเลือกทำ
        Structure Chart แผนภาพแสดงโครงสร้างของโปรแกรม แสดงให้เห็นการเรียกใช้โมดูล
        กลุ่ม Behavioral Description (Dynamic View)
        เป็นแบบจำลองที่ใช้อธิบายมุมมองด้านพฤติกรรมการทำงานของซอฟต์แวร์และคอมโพเน้นท์แสดงให้เห็นพฤติกรรม การทำงานที่เปลี่ยนแปลงไปเมื่อเกิดเหตุการณ์ใดเหตุการณ์หนึ่ง
        Activity Diagram แผนภาพแสดงลำดับการดำเนินกิจกรรมของระบบที่เกิดจากการทำงานของอ็อบเจ็กต์
        Collaborative Diagram แผนภาพแสดงให้เห็นถึงการปฏิสัมพันธ์ระหว่างอ็อบเจ็กต์ (เมื่อไม่เป็นไปตามลำดับเวลา)
        Data Flow Diagram แผนภาพแสดงการไหลของข้อมูล จากกระบวนการหนึ่งไปอีกกระบวนการหนึ่ง
        Decision Table and Diagram ตารางการตัดสินใจใช้แสดงให้เห็นการตัดสินใจดำเนินกิจกรรมอย่างใดอย่างหนึ่งของระบบภายใต้เงื่อนไขที่ซับซ้อน
        Flowchart and Structure Flowchart แผนภาพแสดงลำดับการดำเนินกิจกรรม
        Sequence Diagram แผนภาพแสดงปฏิสัมพันธ์ระหว่างอ็อบเจ็กต์โดยแสดงถึงสถานะและการเปลี่ยนแปลงสถานะของอ็อบเจ็กต์ที่มีต่อเหตุการณ์ใดเหตุการณ์หนึ่ง
        Formal Specification Language ใช้กำหนดรายละเอียดของ Interface และพฤติกรรมของคอมโพเน้นท์
        Pseudo-code and Program Design Language PDL มีลักษณะคล้ายกับการเขียนคำสั่งในโปรแกรม เรียกว่า รหัสเทียม จำลองการทำงานของฟังก์ชัน โพรซีเดอร์ หรือเมธอด