สรุปบทเรียนที่ 12 Software Engineering Test

สรุปบทเรียนที่ 12

Software Engineering Test

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

คำศัพท์ในการแก้ไขข้อผิดพลาด

<!--[if !supportLists]-->1. <!--[endif]-->Error การกระทำผิด คือค่าจริงที่ได้จากการทำงานที่ไม่ถูกต้อง

<!--[if !supportLists]-->2. Fault ความผิดพลาดหรือข้อบกพร่อง คือกระบวนการทำงานของระบบประมวลผลที่ผิดปกติ

<!--[if !supportLists]-->3. Failure ล้มเหลว คือ SW ไม่สามารถทำงานหรือรันโปรแกรมต่อไปได้ รวมถึงไม่สามารถแสดงข้อมูลแจ้งเตือนข้อผิดพลาดที่เกิดขึ้นได้

การทดสอบแบบกล่องดำ Black box testing

เป็นการทดสอบการทำงานของ SW ในเชิงพฤติกรรม 8nv การทดสอบผลของการทำงานของ SW ในแต่ละหน้าที่ ตามข้อกำหนดความต้องการ ทดสอบโดยมองให้เห็นกระบวนการทำงาน สนใจเฉพาะผลลัพธ์ที่ได้เท่านั้น

การทดสอบแบบกล่องขาว White box testing

เป็นการทดสอบการทำงานของระบบโดยมองลึกลงไปถึง Code คำสั่งต่างๆ ที่อยู่ภายในระบบ

<!--[if !supportLists]-->- ทดสอบทุกเส้นทางในกระบวนการ จะต้องสามารถทำงานได้อย่างถูกต้อง

<!--[if !supportLists]-->- <!--[endif]-->ทดสอบการทำงานวนซ้ำ Loop

<!--[if !supportLists]-->- ทดสอบกระบวนการตัดสินใจในทุกตรรกะ

<!--[if !supportLists]-->- ทดสอบโครงสร้างข้อมูลภายในระบบ

Integration testing มี 2 วิธี

<!--[if !supportLists]-->1. Top Down Approach ทดสอบการทำงานของระบบแบบบนลงล่าง เป็นการทำสอบการทดงานในฟังก์ชั่นใหญ่ด้านบนก่อนแล้วค่อยๆ ทดสอบฟังก์ชั่นย่อยต่างๆ ที่อยู่ภายใน

<!--[if !supportLists]-->2. <!--[endif]-->Button up Approach ทดสอบการทำงานของระบบแบบล่างขึ้นบน เป็นการทดสอบการทำงานในฟังก์ชั่นการทำงานย่อยภายในฟังก์ชั่นใหญ่ก่อนแล้วค่อยนำฟังก์ชั่นย่อยมาทดสอบรวมกับฟังก์ชั่นใหญ่ด้านบน

ตัวอย่างการทดสอบแบบกล่องขาว White box testing

โดยการทดสอบแบบกล่องขาวมีสูตรการทดสอบดังนี้ V(G) = e-n+2

V= จำนวนเส้นทาง (Path)

e (edges) = จำนวนเส้นเชื่อมของแต่ละโนด

n (node) = จำนวนโนด

โจทย์

<!--[if !vml]--><!--[endif]-->

จากสูตร V(G) = e-n+2

ตอบ V(G) = 10 – 7 + 2

Path 1 = A, B, E, F, G

Path 2 = A, D, E, F, G

Path 3 = A, D, F, G

Path 4 = A, B, C, G

Path 5 = A, B, C, B, C, G

สรุปบทเรียนที่ 11 User Interface Design

สรุปบทเรียนที่ 11

User Interface Design

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

The Design Process (กระบวนการออกแบบส่วนติดต่อกับผู้ใช้ User Interface)

จากภาพกระบวนการทำงานมีทั้งหมด 6 ขั้นตอน ดังนี้

<!--[if !supportLists]-->1. ขั้นตอนการเก็บรวบรวมความและวิเคราะห์ความต้องการจาก User ว่า User มีกิจกรรมใดที่ต้องทำบ้าง มีความต้องการอย่างไรบ้าง

<!--[if !supportLists]-->2. สร้างตัวต้นแบบใน Prototype Paper แล้วนำตัวต้นแบบที่สร้างขึ้นไปตรวจสอบกับ User อีกครั้ง ว่าตรงกับความต้องการหรือไม่ (ในขั้นตอนนี้ Output ที่ได้ คือได้การออกแยยตัวต้นแบบ Design prototype) กรณีที่ไม่ตรงตามความต้องการหรือผู้ใช้มีความต้องการเพิ่มเติมจะต้องมีการวนกลับไปแก้ไขตัวตนแบบ

<!--[if !supportLists]-->3. นำตัวต้นแบบที่ได้จากขั้นตอนที่ 2 ไปตรวจสอบกับ end user ว่าตรงตามความต้องการหรือไม่ กรณีที่ไม่ตรงตามความต้องการหรือผู้ใช้มีความต้องการเพิ่มเติมจะต้องมีการวนกลับไปแก้ไขตัวตนแบบ

<!--[if !supportLists]-->4. <!--[endif]-->เมื่อตัวตนแบบที่สร้างขึ้นบนกระดาษผ่านการตรวจสอบความต้องการจาก User และ End User แล้ว นำมาสร้างตัวตนแบบจริงๆ บนคอมพิวเตอร์ที่สามารถกดคลิกปุ่ม หรือกรอกข้อมูลต่างๆ ได้จริงๆ

<!--[if !supportLists]-->5. นำตัวต้นแบบทีสร้างขึ้นไปประเมินกับ end user ในกรณีที่ Prototype ที่สร้างขึ้นไม่ตรงกับความต้องการหรือมีความต้องการบางอย่างที่ end user จะต้องมีการวนกลับไปแก้ไขตัวตนแบบจนกว่า end user พอใจ ในขั้นตอนนี้ผลลัพธ์ที่ได้คือ Prototype จริงๆ ที่สามารถใช้งานได้จริงๆ ในสถานการณ์จริง กับลูกค้าจริง

<!--[if !supportLists]-->6. นำ Prototype มาสร้างเป็น User Interface

Usability attributes หลักในการประเมิน User interface

<!--[if !supportLists]-->1. Learnability สามารถเรียนรู้ได้ง่าย เช่น User ที่ไม่เคยรู้จักการใช้งานระบบมาก่อนสามารถเรียนรู้การใช้งานได้ง่าย

<!--[if !supportLists]-->2. Speed of operation ความรวดเร็วในการทำงานของระบบ เช่น ระบบที่สร้างขึ้นมีความรวดเร็วมีความรวดเร็วในการประมวลผล ในการตอบสนองต่อการใช้งานของผู้ใช้

<!--[if !supportLists]-->3. Robustness ความทนทานในการใช้งาน เช่นความทนทานของระบบเมื่อผู้ใช้งานกรอกข้อมูลผิดพลาด ระบบจะมีการแจ้งเตือนอย่างไร

<!--[if !supportLists]-->4. Recoverability ความสามารถในการกู้คืน เช่น เมื่อระบบเกิดความล้มเหลวในการทำงาน ระบบสามารถกู้คืนการทำงานที่เป็นสถานะปกติโยใช้เวลาเท่าไร

<!--[if !supportLists]-->5. Adaptability ความสามารถในการใช้งาน คือ ในเรื่องของประสิทธิภาพการใช้งานระบบ

Simple evaluation techniques (เทคนิคในการประเมิน User interface)

<!--[if !supportLists]-->1. สร้างแบบสอบถามให้ User กรอกข้อมูลแล้วนำมาประมวลผล

<!--[if !supportLists]-->2. ใช้การบันทึก Video บันทึกภาพขณะที่ผู้ใช้งาน ทดลองใช้งานระบบ แล้วดูปฏิกิริยาตอบสนองตอนใช้งาน

<!--[if !supportLists]-->3. เขียนโปรแกรมให้ทำหน้าที่เก็บข้อมูลว่า User ได้ทำอะไรกับระบบบ้าง เพื่อดูการกระทำของ User เพื่อใช้ในการประเมิน

<!--[if !supportLists]-->4. เพิ่มปุ่มให้ User กรอกข้อมูลในหน้านั้นเลยว่า User มีความรู้สึกอย่างไรกับระบบ

สรุปบทเรียนที่ 4 Software Project Management

สรุปบทเรียนที่ 4

Project Manager

สิ่งที่ Project Manager ต้องทำมี 6 อย่าง

1. เขียน Proposal ว่าระบบที่จะพัฒนาจะมีคุณสมบัติอย่างไร ทำประโยชน์อะไรให้องค์กรได้บ้าง เอามาใช้แก้ไขปัญหาอะไรและศึกษาความคุ่มค่าในการพัฒนา

2. เขียนแผนในการพัฒนา

3. ประเมินต้นทุนในการพัฒนา

4. ติดตามดูการพัฒนา ว่าตรงตามที่กำหนดไว้หรือไม่ ตรงกับความต้องการไหน

5. คัดเลือกบุคลากร เข้าทีมพัฒนา จัดสรรตำแหน่งและประเมินความสามารถ

6. นำเสนอรายงานในทุกๆ ช่วงของ Milestone

2 เรื่องสำคัญที่ Project manager ต้องดูแล

<!--[if !supportLists]--> 1. Project staffing เรื่องของการบริหารจัดการบุคลากร

<!--[if !supportLists]-->1.1 จัดหาบุคลากรที่เหมาะสม

<!--[if !supportLists]-->1.2 หมอบหมายงานที่เหมาะสม

<!--[if !supportLists]-->1.3 พัฒนาบุคลากร

<!--[if !supportLists]--> 2. <!--[endif]-->Project planning สำคัญที่สุดและใช้เวลามากที่สุด จะต้องมีการวางแผนตั้งแต่เริ่มจนจบ มักจะมีการเปลี่ยนแปลงตลอด

โครงสร้างการวางแผนโครงการ
1. Project organization กำหนดลักษณะโครงสร้างของโครงการ

2.Risk analysis มีการวิเคราะห์ความเสี่ยง

3. Hardware and software requirement วิเคราะห์ความต้องการทั้งหมดในแง่ของ hardware software

4. Work breakdown แตกงานออกเป็นงานย่อยๆ

5. Monitoring and reporting machines ติดตามดูการพัฒนา

Risk management process

1. Risk Identification บอกให้ได้ว่าอะไรบ้างคือความเสี่ยง

2. Risk Analysis วิเคราะห์ความเสี่ยง ความเป็นไปได้ที่จะเกิดขึ้น

3. Risk Planning วางแผนควบคุมความเสี่ยง

4. Risk Monitoring ติดตามดูความเสี่ยง

ตอบคำถามบทเรียนที่ 6

แบบฝึกหัดบทที่ 6

ระบบการจองตั๋วหนังเพื่อเข้าชมการแสดง ให้นักศึกษา ศึกษาเอกสารกำหนดความต้องการที่กำหนดให้ และให้วิเคราะห์ว่าข้อความใดที่บ่งบอกถึง ความต้องการที่เป็นหน้าที่หลักของระบบ (Functional Requirement) และข้อความใดบ่งบอกถึง ความต้องการที่ไม่ใช่หน้าที่หลักของระบบ (Non-Functional Requirement) บริษัท KBU Ticket Master ต้องการสร้างระบบให้ลูกค้าสามารถจองตั๋วชมการแสดง ผ่านทางระบบ Internet โดยกำหนดความต้องการของระบบดังนี้

<!--[if !supportLists]--> - การแสดงหนึ่งๆ อาจจะมีรอบการแสดง ได้มากกว่าหนึ่งรอบได้

<!--[if !supportLists]--> - การแสดงแต่ละรอบจะจัดแสดงอยู่ในโรงละคร ซึ่งแต่ละโรงละครจะมีจำนวนที่นั่งแตกต่างกัน

<!--[if !supportLists]--> - ในการจองที่นั่งแต่ละรอบจะมีการกำหนดว่าลูกค้าหนึ่งคนจะสามารถจองตั๋วได้มากที่สุดจำนวนกี่ที่นั่ง

<!--[if !supportLists]--> - ลูกค้าสามารถคืนตั๋วได้(โดยได้รับเงินคืน) แต่ต้องคืนภายในเวลาที่กำหนด ซึ่งเวลาที่กำหนดนั้นจะไม่เท่ากัน ขึ้นอยู่

กับการแสดงในแต่ละรอบ

<!--[if !supportLists]--> - <!--[endif]-->การบริหารจัดการตารางการแสดงแต่ละรอบ และแต่ละโรงละคร จะต้องไม่ยุ่งยากใช้พนักงานให้น้อยที่สุด

<!--[if !supportLists]--> - ระบบใช้งานได้ง่าย ลูกค้าสามารถเรียนรู้ขั้นตอนวิธีการจองตั๋วชมการแสดง ได้อย่างรวดเร็ว

<!--[if !supportLists]--> - ระบบจะต้องตอบสนองการใช้งานของลูกค้าได้อย่างรวดเร็วและถูกต้อง

Functional Requirement	Non-Functional Requirement
<!--[if !supportLists]--> - <!--[endif]-->การแสดงหนึ่งๆ อาจจะมีรอบการแสดง ได้มากกว่า หนึ่งรอบได้	<!--[if !supportLists]--> - <!--[endif]-->การบริหารจัดการตารางการแสดงแต่ละรอบ และแต่ละโรงละคร จะต้องไม่ยุ่งยากใช้พนักงานให้น้อยที่สุด
<!--[if !supportLists]--> - <!--[endif]-->การแสดงแต่ละรอบจะจัดแสดงอยู่ในโรงละคร ซึ่งแต่ละโรงละครจะมีจำนวนที่นั่งแตกต่างกัน	<!--[if !supportLists]--> - ระบบใช้งานได้ง่าย ลูกค้าสามารถเรียนรู้ขั้นตอนวิธีการจองตั๋วชมการแสดง ได้อย่างรวดเร็ว
<!--[if !supportLists]--> - <!--[endif]-->การจองที่นั่งแต่ละรอบจะมีการกำหนดว่าลูกค้าหนึ่งคนจะสามารถจองตั๋วได้มากที่สุดจำนวนกี่ที่นั่ง	<!--[if !supportLists]--> - ลูกค้าสามารถคืนตั๋วได้(โดยได้รับเงินคืน) แต่ต้องคืนภายในเวลาที่กำหนด ซึ่งเวลาที่กำหนดนั้นจะไม่เท่ากัน ขึ้นอยู่กับการแสดงในแต่ละรอบ
<!--[if !supportLists]--> - ระบบจะต้องตอบสนองการใช้งานของลูกค้าได้อย่างรวดเร็วและถูกต้อง

สรุปบทเรียนที่ 6 Requirements Engineering

สรุปบทเรียนที่ 6

System Requirement  วิศวกรรมความต้องการ

กระบวนการวิศวกรรมความต้องการ แบ่งออกเป็น 4 ขั้นตอน คือ

<!--[if !supportLists]--> 1. ศึกษาความเป็นไปได้

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

<!--[if !supportLists]-->- ตรงกับวัตถุประสงค์ขององค์กรหรือไม่

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

<!--[if !supportLists]-->- ระบบใหม่สามารถทำงานร่วมกับระบบเก่าได้หรือไม่

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

<!--[if !supportLists]-->1. ถ้าไม่พัฒนาระบบจะเกิดอะไรขึ้น

<!--[if !supportLists]-->2. ปัญหาที่พบมีอะไรบ้าง

<!--[if !supportLists]-->3. ระบบใหม่สามารถช่วยในการแก้ไขปัญหาได้อย่างไร

<!--[if !supportLists]-->4. ต้องใช้เทคโนโลยีอะไรและใช้ความสามารถพิเศษอะไรบ้าง

<!--[if !supportLists]--> 2. ค้นหาและวิเคราะห์ความต้องการ

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

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

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

<!--[if !supportLists]--> 3. กำหนดความต้องการ

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

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

<!--[if !supportLists]--> 4. ตรวจสอบความต้องการ

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

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

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

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

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

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

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

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

<!--[if !supportLists]--> 1. Stakeholder ไม่มีความรู้ความเข้าใจ

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

<!--[if !supportLists]--> 3. Stakeholder มีความต้องการที่แตกต่างกัน เราต้องแบ่งกลุ่มความต้องการเพื่อไม่ให้ขัดแย้งกัน

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

<!--[if !supportLists]--> 5. <!--[endif]-->มีการเปลี่ยนแปลงความต้องการระหว่างการพัฒนา เช่น SK คนใหม่เข้ามา ธุรกิจเปลี่ยน เปลี่ยนเทคโนโลยี

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

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

<!--[if !supportLists]-->2. งบประมาณไม่เพียงพอ

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