Chapter 5

Chapter 5 

1.ความต้องการของผู้ใช้ (User)

2. ความต้องการด้านระบบ (System Requirement)

ความต้องการด้านซอฟต์แวร์ แบ่งออกเป็ น 3 ประเภท ได้แก่

1. ความต้องการทีเป็ นหน้าทีหลัก(Functional Requirement)

เป็นความต้องการทีเป็นหน้าทีหลัก ซึ่งทําหน้าทีใดๆตามทีกําหนดไว้ในส่วนการทํางานหรือบริการทีซอฟต์แวร์นันควรมี

2. ความต้องการทีไม่ใช่หน้าทีหลัก (Non-Functional Requirement)

เป็ นความต้องการทีไม่เกียวข้องโดยตรงกับหน้าทีหรือฟังก์ชันหลักของระบบ เช่นความต้องการด้านผลิตภัณฑ์ความต้องการขององค์กร และความต้องการจากปั จจัยภายนอก

3. ความต้องการด้านธุรกิจ (Domain Requirement)

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

วิศวกรรมความต้องการ (Requirement Engineering) 

หมายถึง กระบวนการทีจะทําให้วิศวกรรมซอฟต์แวร์เข้าใจและเข้าถึงความ้องการของลูกค้าได้อย่างแท้จริง

ด้วยการสกัดความต้องการ ตรวจสอบและนิยามความต้องการเพื่อนําไปสร้างเป็นข้อกําหนดความต้องการด้านระบบหรือซอฟต์แวร์

เป้าหมายของวิศวกรรมความต้องการ ก็คือ

การสร้างและบํารุงเอกสารข้อกําหนดความต้องการทั้งทางด้านระบบและด้านซอฟต์แวร์ให้เป็นเอกสารทีมีคุณภาพทีสุด

ข้อแนะนำในการเขียนความต้องการ

1. เขียนเป็นลักษณะโครงสร้างที่เป็นมาตรฐานนำไปใช้ได้ทุก RQ

2. ใช้ภาษาคงเส้นคงวา และมีศัพท์ 2 คำ คือจะต้อง และควรจะ

3. การใช้ตัวบางตัวหนา

4. หลีกเลี่ยงการใช้ศัพท์เทคนนิคเพราะมีคนหลายกลุ่ม

Sequence Diagram ใช้จําลองภาพเชิงกิจกรรม (Dynamic Model หรือ Behavioral Model)

- การจําลองกระบวนการที่ทําให้เกิดกิจกรรมรวมของระบบ

- กิจกรรมรวมของระบบ เกิดจาก ชุดของกิจกรรม (หลายๆ กิจกรรม)

- 1 กิจกรรม เกิดจาก Object หนึ่งมีการโต้ตอบกับอีก Object หนึ่ง

ประโยชน์ของ Sequence Diagram

- ช่วยให้รู้ว่า มี Function ขาดหายไปจาก Class Diagram หรือไม่

- ช่วยให้พิจาณาได้ว่าควรเพิ่มเติม Function ใน Class Diagram อีกหรือไม่

- ช่วยให้ปรับปรุง Class Diagram ได้สมบูรณ์ยิ่งขึ้น

ตัวอย่าง 

Sequence Diagram

Chapter 3-4

สรุปบทที่ 3-4

Systems Engineering

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

Emergent properties *ความน่าเชื่อถือ เป็นคุณสมบัติของระบบ

สามารถวัดได้จาก

1. วัดน้ำหนักความสำคัญของระบบ

2. วัดความเชื่อถือของระบบ

3. วัดความสามารถในการใช้งานจริง

System Engineering Process *โปรเซส วิศวกรรมระบบ มีอยู่ 7 โปรเซส

1. System requirement definition ขั้นตอนการเก็บรวบรวมความต้องการของระบบ 

มี 3 ลักษณะ คือ

1 Functional requirement ฟังก์ชันการทำงานของระบบมีอะไรบ้าง

2 Non-Functional requirement คุณสมบัติที่ไม่เกี่ยวข้อกับการทำงานของระบบ

ที่แท้จริง

3 Unacceptable สิ่งที่ไม่ต้องการให้เกิดขึ้นกับระบบ เช่น ไฟดับ Server down เป็นต้น

ปัญหาที่พบในการเก็บความต้องการ

1. ความต้องการเปลี่ยนโดยที่ระบบยังพัฒนาไม่เสร็จ อาจเกิดจากเวลาเปลี่ยนความ

ต้องการของคนเปลี่ยนตามเวลา เพราะเทคโนโลยีเปลี่ยน

2. ระยะเวลาในการพัฒนานาน ฮาร์ดแวร์เปลี่ยน ซอฟต์แวร์เปลี่ยน เทคโนโลยีเปลี่ยน

3. กำหนด Non-functional ได้ยาก เพราะสามารถมองเห้นได้เมื่อใช้งานไปแล้วเท่านั้น

2. System design ขั้นตอนการออกแบบระบบ มี 5 ขั้นตอน

1. รวบรวมความต้องการมาแบ่งกลุ่มเป็นส่วนๆ

2. กำหนดว่าระบบใหญ่ควรมีระบบย่อยอะไรบ้าง

3. จับคู่ความต้องการเข้ากับระบบย่อย

4. กำหนดหน้าที่ของระบบย่อย

5. กำหนดส่วนติดต่อระหว่างระบบย่อยว่ามีการเชื่อมต่อ สื่อสารกันอย่างไร

ปัญหาของการออกแบบระบบ

1. ไม่รู้ว่าใครเป็นผู้รับผิดชอบ

2. ปัญหาที่ยาก จะถูกผลักดันให้เป็นหน้าที่ของซอฟต์แวร์ ทำให้ซอฟต์แวร์มีขนาดใหญ่และ

ต้นทุนที่สูง

3. ฮาร์ดแวร์ ซอฟต์แวร์และ Platform ไม่เหมาะกัน เช่น Windown, Max, Linux

3. Sub system development ขั้นตอนการพัฒนาระบบ

- การพัฒนามักจะพัฒนาแบบคู่ขนานระหว่างฮาร์ดแวร์ ซอฟต์แวร์ และ Communication 

- การพัฒนามักใช้ซอฟต์แวร์สำเร็จรูปมาใช้

- ระหว่างทีมพัฒนาในองค์กรอาจเกิดอุปสรรคได้

4. System integration ขั้นตอนการนำระบบย่อยมารวมกัน

เริ่มจากการนำ Sub system ที่สำคัญที่สุดก่อน นำมาทำงานร่วมกัน เมื่อทำงานได้ก็นำ Sub 

system ต่อไป ทำไปเลื่อยๆ การรวมระบบในรูปแบบนี้จะทำให้ระบบล้ม หรือ เกิดความผิดพลาด

น้อยลง

5. System installation ขั้นตอนการติดตั้งและนำไปใช้

ปัญหาการติดตั้ง

1. สภาพแวดล้อมไม่เหมาะสม ไม่อำนวย

2. คนต่อต้านการนำระบบใหม่ไปใช้งาน เช่น กลัวหมดความสำคัญ

3. ระบบใหม่ที่พัฒนาขึ้นต้องทำงานคู่ขนานกับระบบเก่า ระบบอาจเข้ากันได้ลำบาก

4. พื้นที่การติดตั้งไม่เพียงพอ

5. การวางแผนอบรมการใช้งานระบบ

ปัญหาการนำไปใช้งาน

1. ความต้องการที่ไม่คาดคิดจะโผล่ออกมา เมื่อพัฒนาเสร็จสิ้นแล้ว

2. ผู้ใช้งาน ไม่ใช้ระบบที่เราออกแบบ กรอกข้อมูลผิดตำแหน่ง

3. เวลาทำงานร่วมกับระบบอื่นอาจมีปัญหาได้

- ปัญหาทางกายภาพ

- ปัญหาการแปลงข้อมูล

6. System evolution ขั้นตอนการปรับปรุงระบบ

เมื่อใช้งานไปแล้วต้องมีการพัฒนาโปรแกรมรุ่นใหม่ออกมา เพื่อให้มีการพัฒนาตาม 

ฮาร์ดแวร์ ซอฟต์แวร์ และ Technology ใหม่ๆ เมื่อปรับปรุงจะเกิดค่าใช้จ่าย

7. System decommissioning ขั้นตอนการปลดละวาง เลิกใช้งาน

ปัญหาการเชื่อมโยงระหว่าง Database ตัวใหม่กับตัวเก่า

Chapter 2

นายธีรภัทร์ มังคลาด ID: 520702477896

สรุปบทที่ 2

The Software Process

ขั้นตอนการพัฒนาระบบ สามารถแบ่งออกได้เป็น 4 ขั้นตอน

1. Specification กำหนดความต้องการ เป็นขั้นตอนที่กำหนดว่า Program ทำอะไรได้บ้าง ต้องการอะไรบ้าง

2. Design เป็นขั้นตอนการออกแบบระบบ ตามความต้องการที่ได้กำหนดเอาไว้ในข้อที่ 1

3. Validation การทดสอบ ทวนสอบ การทำงานหรือฟังก์ชันของระบบว่าตรงกับความต้องการของลูกค้าหรือไม่

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

แบบจำลองที่ใช้ในการพัฒนาระบบมี 4 แบบจำลอง

1. Waterfall Model (แบบน้ำตก)

2. Evolutionary Development (ปรังปรุง Version ไปเรื่อยๆ จนลูกค้าพอใจจึงจะเสร็จ)

3. Component-based software engineering (การนำ Component ที่มีอยู่แล้วกลับมาใช้ใหม่)

4. Process iteration (การพัฒนาซ้ำๆ)

1. Waterfall Model

Waterfall Model

เป็นแบบจำลองที่ประกอบขึ้นด้วยขั้นตอนที่ต่อเนื่องเป็นลำดับ ตั้งแต่ลำดับแรกจนถึงลำดับสุดท้ายว่ามีอะไรบ้าง ไหลจากที่สูงลงสู่ที่ต่ำ สามารถย้อนกลับไปแก้ไขในขั้นตอนก่อนหน้าได้ (ข้อเสีย)แต่จะมีความยุ่งยากในการในการปรับเปลี่ยน เช่น ต้องการในขั้นตอนที่ 3 ก็ต้องย้อนกลับไปขั้นตอนที่ 1, 2 ด้วย

2. Evolutionary development

Evolutionary Model

การพัฒนาแบบนี้ทำให้เกิดการปรับปรุง ปรับเปลี่ยนความต้องการให้อยู่ในรูปแบบของ Version มี 4 ขั้นตอน

1. Requirement วิเคราะห์ความต้องการ

2. System Design ออกแบบระบบ

3. Coding and Testing ขั้นตอนการเขียนและทดสอบระบบ

4. Assignment การประเมินผล

ปัญหา

1. ขาดความชัดเจนในการทำงาน

2. ระบบที่สร้างขึ้นมาไม่ค่อยเป็นระบบเท่าไร

3. ผู้ใช้ระบบ ต้องมีความชำนาญสุูง

ข้อเสีย

1. อาจจะรบกวนเวลาทำงานของลูกค้า ทำให้เกิดความลำคาญใจ

2. บอกความคืบหน้าในการทำงานลำบาก

การนำแบบจำลองไปใช้

1. ใช้กับระบบเล็กหรือขนาดกลาง

2. นำไปใช้ในส่วนของระบบงานขนาดใหญ่

3. นำไปใช้ในโครงงานที่มีอายุการดำเนินงานสั้นๆ

3. CBSE (Component-Based Software Engineering)

ข้อดี

1. รวดเร็วขึ้น

2. ประหยัดต้นทุน

3. ระบบมีความเชื่อมั่นเพิ่มมากขึ้น

4. ความเสี่ยงที่จะเกิดความล้มเหลวลดลง

ข้อเสีย

1. หา Component ที่ตรงตามความต้องการได้ยาก

2. ยากในการปรับปรุง Component ให้ตรงตามความต้องการ

4. Process Iteration

การพัฒนาแบบวนซ้ำๆ (loop) มี 2 วิธี

1. Increment delivery การส่งระบบเพิ่มเติมไปเรื่อยๆ ทีละชุดจนเสร็จ

2. Spiral delivery พัฒนาแบบก้หอย

4.1 Increment delivery

ประโยชน์

1. ลูกค้าได้รับประโยชน์ในการส่งมอบเร็วขึ้น คือการที่ลูกค้าสามารถนำระบบบางส่วนไปใช้งานได้

2. ลดความเสี่ยงที่โครงการจะล่ม

3. ฟังก์ชันที่มีความเสี่ยงจะถูกทดสอบมากที่สุด ทำให้เกิดความผิดพลาดได้น้อย

4.2 Spiral delivery

เป็นการพัฒนาหนุมเป็นรอบๆ เป็นเกียววนคล้ายก้นหอย แบ่งออกเป็น 4 ส่วน

1. กำหนดวัตถุประสงค์และความสำคัญ

2. ประเมินความเสี่ยง

3. พัฒนา และตรวจสอบความต้องการ

4. วางแผน

Process Activity

Process Activity คือ กิจกรรมขั้นตอนการจัดทำ Software

1. Software Specification

2. Software Design and implementation

3. Software validation

4. Software evolution

ขั้นตอนที่ 1 Software Specification กระบวนกำหนดความต้องการ

คือ กระบวนการวิศวกรรมความต้องการ ซึ่งก็คือการกำหนดความเป็นไปได้ให้กับระบบ

Requirements engineering process

1. Feasibility Study ศึกษาความเป็นไปได้ เช่น งบประมาณ เวลา Software Hardware

2. Requirement elicitation and analysis สกัดความต้องการ เพื่อให้รู้ว่าความต้องการของระบบ

มีอะไรบ้าง

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

4. Requirement validation ขั้นการตรวจสอบว่าตรงจามความต้องการหรือไม่

ขั้นตอนที่ 2 Software design and implementation

Design เป็นขั้นตอนการออกแบบและเขียนโปรแกรม

Implementation การนำไปใช้งาน

Debugging process แบบจำลองการแก้่ไขโปรแกรม

1. หาตำแหน่งที่ผิดพลาดของโปรแกรม

2. ออกแบบว่าจะแก้ไข ข้อผิดพลาดที่เกิดขึ้นอย่างไร

3. ซ่อมบำรุง ทำการแก้ไข

4. ทดสอบการแก้ไข ว่าถูกต้องและผ่านหรือไม่

ขั้นตอนที่ 3 Software validation การทดสอบซอฟต์แวร์

Verification ทดสอบว่าซอฟต์แวร์ที่พัฒนาขึ้นตรงกัยความต้องการหรือไม่ โปรแกรมเมอร์ทดสอบ

Validation ทดสอบว่าตรงกับความต้องการของลูกค้าหรือไม่

Testing Process

1. Component or unit testing การทดสอบทีละส่วน ทีละระบบ

2. System testing การทดสอบทั้งระบบรวมกัน

3. Acceptance testing การทดสอบเพื่อการยอมรับ จากผู้ใช้งานจริง และใช้ข้อมูลจริง

ขั้นตอนที่ 4 Software evolution ขั้นตอนในการเปลี่ยนแปลงโปรแกรมตามความต้องการของ User

เป็นขั้นตอนการปรับปรุงโปรแกรมให้ทันยุคทันสมัย

The Rational Unified Process คือ คอมพิวเตอร์ที่ช่วยในการสร้างซอฟต์แวร์ RUP เขียนอยู่บน UML

การเขียนโปรแกรมแบบ UML มี 3 มุมมอง

1. แสดงขั้นตอนการทำงานให้เห็นเป็นขั้นๆ

2. แสดงให้เห็นกิจกรรมว่ามีอะไรบ้าง

3. แสดงให้เห็นถึงการปฎิบัติงานที่ดี

RUP phase model แบ่งออกเป็น 4 ขั้นตอน ***แต่ละขั้นมีการทำซ้ำบ่อยครั้ง

***สถาปัตยกรรม มีจุดเด่น คือ การค้นหาความเสี่ยงและวิเคราะความเสี่ยง

1. Inception ระยะเริ่มต้นของการดำเนินงาน กำหนดขอบเขตหน้าที่หลักของระบบ

2. Elaboration ทำความเข้าใจระบบ

3. Construction ออกแบบ เขียน ทดสอบ โดยแบ่งออกเป็นส่วนๆ โดยให้ Programmer ช่วยกัน

เขียน แล้วค่อยนำมารวมกัน หลังจากนั้นจะได้ ซอฟต์แวร์ และ เอกสารของซอฟต์แวร์

ข้อปฎิบัติการใช้ RUP

1. พัฒนาโปรแกรมแบบซ้ำๆ หากไม่สมบรูณ์ให้กลับไปทำใหม่

2. บริหารความต้องการให้ดีว่า ความต้องการไหนมีความสำคัญกว่า

3. ควรใช้งาน Component ที่มีอยู่แล้ว

4. ยึด Model RUP มาช่วยในการออกแบบ

5. ตรวจสอบคุณภาพของซอฟต์แวร์ให้ดีอยู่เสมอ

6. ควบคุมการเปลี่ยนแปลงของซอฟต์แวร์ให้น้อยที่สุด