บทที่ 5 แบบจำลองกระบวนการ

งานนำเสนอเรื่อง: "บทที่ 5 แบบจำลองกระบวนการ"— ใบสำเนางานนำเสนอ:

1 บทที่ 5 แบบจำลองกระบวนการ
(Process Modeling)

2 สาเหตุที่ต้องมีแบบจำลองหลาย ชนิดก็เพราะว่า ไม่มีแบบจำลอง ชนิดใดที่สามารถนำเสนอ มุมมองในความต้องการของ ระบบได้ครบทุกๆ ส่วน

3 ชนิดของแบบจำลอง 1. แบบจำลองคณิตศาสตร์ โดยมากใช้กับงานด้านการคำนวณ
ทั่วไป งานด้านวิทยาศาสตร์ ซึ่งมักนำเสนอในรูปแบบของสูตรทางคณิตศาสตร์ หรือฟังก์ชัน

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

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

6 (Data Flow Diagram: DFD)
ตัวอย่างแบบจำลองกระบวนการ แผนภาพกระแสข้อมูล (Data Flow Diagram: DFD) แผนภาพอีอาร์ (ER-Diagram)

7 Data Flow Diagram (DFD)
การสร้างบ้าน จำเป็นต้องมีแบบแปลน หรือแบบพิมพ์เขียว (Blueprint) DFD เปรียบเสมือนแบบพิมพ์เขียวเพื่อ นำไปใช้พัฒนาระบบสารสนเทศ

8

9 Data Flow Diagram (ต่อ)

10 Data Flow Diagram (ต่อ)
Data Flow Diagram จะแสดง ความสัมพันธ์ระหว่างโปรเซส (Processes) กับ ข้อมูล (Data) ที่เกี่ยวข้อง

11 Data Flow Diagram (ต่อ)
โดยข้อมูลในแผนภาพ จะทำให้ทราบถึง 1. ข้อมูลมาจากไหน 2. ข้อมูลไปที่ไหน 3. ข้อมูลเก็บไว้ที่ใด 4. เกิดเหตุการณ์ใดกับข้อมูลใน ระหว่างทาง

12 Data Flow Diagram (ต่อ)
เนื่องจาก DFD แสดงภาพรวมของระบบ และรายละเอียดเกี่ยวกับโปรเซสกับข้อมูล ดังนั้น หากต้องการกำหนดรายละเอียด เพิ่มเติม SA.จำเป็นต้องใช้เครื่องมืออื่นช่วย เช่น อัลกอริทึม ตารางตัดสินใจ แบบจำลอง ข้อมูล และ Process Description

13 ขั้นตอนการวิเคราะห์เพื่อสร้าง DFD
P. 164

14 DFD กับมุมมองการใช้งาน
SA. ใช้ประโยชน์จาก DFD เพื่อแสดง ภาพรวมของระบบ และรายละเอียดของระบบ

15 วัตถุประสงค์ของ DFD 1. เป็นแผนภาพที่สรุปรวมข้อมูลทั้งหมดที่
ได้จากการวิเคราะห์ (Structured) 2. เป็นข้อตกลงร่วมกันระหว่าง นักวิเคราะห์ระบบกับยูสเซอร์ 3. สามารถนำไปใช้ประโยชน์ในขั้นตอนของ การออกแบบระบบ

16 วัตถุประสงค์ของ DFD (ต่อ)
4. ใช้อ้างอิง เพื่อนำไปปรับปรุง/พัฒนาต่อ ในอนาคต 5. ทราบที่มาที่ไปของข้อมูลที่ไหลไปยัง กระบวนการต่าง ๆ (Data and Processes)

17 สัญลักษณ์ที่ใช้ใน DFD
P. 166

18 มาตรฐานสัญลักษณ์ของ DFD

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

20 Processes (ต่อ)

21 Processes (ต่อ) โปรเซสต้องมีหมายเลขกำกับเสมอ
ลำดับหมายเลขโปรเซส ไม่ได้ หมายความว่าต้องดำเนินกิจกรรมตามลำดับ ของโปรเซสแต่อย่างใด

22 Processes (ต่อ) หมายเลขโปรเซส ซ้ำกันไม่ได้
ชื่อที่ใช้กำกับโปรเซส ให้ใช้คำกริยา ซึ่ง หมายถึงการกระทำ จำนวนโปรเซส 7 บวกลบ 2

23 Processes (ต่อ) โปรเซสใน DFD จะไม่มีการแสดง รายละเอียดเกี่ยวกับวิธีการทำงาน แต่โปรเซสจะทำให้ทราบว่ามีอินพุต อะไรเข้าไป และเมื่อผ่านการประมวลผล ออกมาแล้ว ได้เอาต์พุตอะไรออกมา

24 Processes (ต่อ) ดังนั้น โปรเซสจึงเปรียบเสมือนกับ กล่องดำ (Black Box) ที่นำเสนอเพียงว่าทำ หน้าที่อะไร มีอะไรที่อินพุตเข้าไป และมี อะไรที่เอาต์พุตออกมา

25 Processes Description

26 Data Flows Data Flow หรือกระแสข้อมูล ใช้ สัญลักษณ์แทนด้วยเส้นลูกศรที่ไปพร้อมกับ ข้อมูล ทำให้ทราบถึงข้อมูลที่เคลื่อนไหวไป มาระหว่าง Process, Data Store และ External Entity

27 Data Flows (ต่อ) ทุกโปรเซสใน DFD เมื่อมีดาต้าโฟลว์ อินพุตเข้าไป ก็ย่อมมีดาต้าโฟลว์เอาต์พุต ออกมาเสมอ โดยอาจมีอินพุตหรือเอาต์พุต ของดาต้าโฟลว์มากกว่าหนึ่งจุดก็เป็นได้

28 Data Flows (ต่อ) แต่ถ้าหากโปรเซสมีเพียงดาต้าโฟลว์ที่ อินพุตเข้าไป โดยไม่มีเอาต์พุตออกมา หรือโปรเซสที่มีเพียงดาต้าโฟลว์ที่เอาต์พุต ออกมาโดยไม่มีข้อมูลอินพุต ถือว่า…ผิดธรรมชาติ

29 Data Flows (ต่อ)

30 Data Flows (ต่อ) แผนภาพ DFD จะมีดาต้าโฟลว์จำนวนมาก ในแผนภาพ ดังนั้น จึงอาจทำให้ดาต้าโฟลว์แต่ ละเส้นเกิดการทับซ้อนกัน หลักการเขียน DFD ที่ดี ไม่ควรมีเส้นดาต้า โฟลว์ทับซ้อนกัน เพราะจะทำให้แลดูยุ่งเหยิง ไม่มีระเบียบ

31 Data Flows (ต่อ)

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

33 External Entities (ต่อ)
เอ็กซ์เทอร์นัลเอ็นติตี้ จะมีหน้าที่ในการส่ง หรือรับข้อมูลจากโปรเซสเท่านั้น ดาต้าโฟล์วที่ อินพุตเข้ามาในระบบถือเป็นแหล่งกำเนิดของ ข้อมูล (Data Source) ในขณะที่ดาต้าโฟล์วที่ เอาต์พุตออกมาจากโปรเซสก็จะถูกส่งไปยัง ปลายทาง (Destination)

34 External Entities (ต่อ)
และด้วยเหตุนี้เอง สัญลักษณ์นี้ จึง สามารถเรียกได้หลายชื่อด้วยกัน เช่น Source Boundary Destination External Agent

35 External Entities (ต่อ)
เอ็กซ์เทอร์นัลเอ็นติตี้ จะมีหน้าที่ในการส่ง หรือรับข้อมูลจากโปรเซสเท่านั้น ดาต้าโฟล์วที่ อินพุตเข้ามาในระบบถือเป็นแหล่งกำเนิดของ ข้อมูล (Data Source) ในขณะที่ดาต้าโฟล์วที่ เอาต์พุตออกมาจากโปรเซสก็จะถูกส่งไปยัง ปลายทาง (Destination)

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

37 External Entities (ต่อ)
เอ็กซ์เทอร์นัลเอ็นติตี้สามารถเป็นได้ทั้ง บุคคล หน่วยงาน หรือระบบงาน การพิจารณาบุคคลที่จะมาเป็นเอ็กซ์เทอร์นัล เอ็นติตี้ได้นั้น ให้พิจารณาถึงบุคคลภายนอกที่ ระบบไม่สามารถควบคุมได้เป็นสำคัญ โดย บุคคลที่ปฏิบัติงานกับโปรเซสโดยตรงจะไม่ นำมาพิจารณา

38 External Entities (ต่อ)
เอ็กซ์เทอร์นัลเอ็นติตี้มักจะถูกจัดให้อยู่ บริเวณด้านนอกหรือรอบ ๆ ของแผนภาพ เพื่อให้แผนภาพแลดูสวย ง่ายต่อการดู และ ที่สำคัญ เอ็กซ์เทอร์นัลเอ็นติตี้สามารถ กระทำซ้ำ (Duplicate) ได้

39 External Entities (ต่อ)

40 Data Stores ดาต้าสโตร์เป็นแหล่งที่ใช้เก็บข้อมูล ซึ่งไม่ สนใจว่าระบบจะใช้สื่อจัดเก็บข้อมูลเป็นชนิดใด ทุก ๆ ดาต้าสโตร์จะต้องมีชื่อข้อมูล และมี ลาเบลกำหนด เช่น D1 D2 D3 ตามลำดับ

41 Data Stores (ต่อ) ดาต้าสโตร์จะถูกใช้งานโดยโปรเซส และ ดาต้าสโตร์ยังสามารถ Duplicate ได้ สำหรับที่มาของดาต้าสโตร์ ก็จะได้มาจาก การสร้างแบบจำลองข้อมูล (Data Model)

42 Data Stores (ต่อ)

43 Data Stores (ต่อ) สำหรับ DFD ระดับที่ 1 โปรเซสส่วนใหญ่ ที่เชื่อมต่อกับดาต้าสโตร์มักเป็นแบบอินพุต/ เอาต์พุต เนื่องจากแผนภาพในระดับล่างลงไป โปรเซสการทำงานส่วนใหญ่มักจะมีทั้งการ เข้าถึงข้อมูลในดาต้าสโตร์แบบอินพุต และ เอาต์พุต

44 ขั้นตอนการเขียน DFD 1. วิเคราะห์ให้ได้ว่า ระบบควรประกอบ
1. วิเคราะห์ให้ได้ว่า ระบบควรประกอบ ด้วยเอ็กซ์เทอร์นัลเอ็นติตี้อะไรบ้าง 2. ดำเนินการเขียน Context Diagram 3. วิเคราะห์ข้อมูลในระบบว่า ควรมีข้อมูล อะไรบ้าง

45 ขั้นตอนการเขียน DFD (ต่อ)
4. วิเคราะห์โปรเซสในระบบว่า ควรมี โปรเซสหลัก ๆ อะไรบ้าง ประกอบด้วย โปรเซสย่อยอะไรบ้าง 5. ดำเนินการเขียน DFD-Level 1, 2

46 ขั้นตอนการเขียน DFD (ต่อ)
6. ทำการตรวจสอบความสมดุล (Balancing) ของแผนภาพ และทำการปรับแก้จนกระทั่งได้แผนภาพกระแสข้อมูลที่สมบูรณ์และถูกต้อง 7. อาจใช้โปรแกรม Visio หรือโปรแกรมเคสทูลส์ ในการสร้างไดอะแกรม

47

48

49

50

51

52

53

54 การตรวจสอบ Balancing

55 (Process Description)
คำอธิบายการประมวลผล (Process Description) แผนภาพกระแสข้อมูล (DFD) เป็นไดอะแกรมที่นำเสนอให้เห็นภาพรวมของระบบได้เป็นอย่างดี แต่มีข้อเสียตรงที่ไม่ได้มีการแสดงรายละเอียดของแต่ละโปรเซส

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

57 ระดับของ PD 1. ระดับการใช้งาน (Usage Level)
เป็นคำอธิบายการประมวลผลในระดับที่มุ่งเน้นจับรายละเอียดด้านการปฏิบัติงานของผู้ใช้เป็นสำคัญ ด้วยถ้อยคำ เรียงความบรรยาย หรือเรียกว่า ภาษาธรรมชาติ

58 ระดับของ PD (ต่อ) 2. ระดับระบบ (System Level)
เป็นคำอธิบายการประมวลผลในระดับที่มุ่งเน้นถึงความเที่ยงตรงในรายละเอียดเป็นสำคัญ เช่น Structured English, Decision Tree และ Decision Table

59 Natural Language Specifications
System: ระบบเช่ารถ DFD number: 2.3 Process name: บันทึกรายการเช่ารถ Input data flows: รหัส/ข้อมูลลูกค้า, ใบขับขี่/พาสปอร์ต Output data flows: - Data stored used: ข้อมูลลูกค้า, ข้อมูลรถ, ข้อมูลประเภทรถ, ข้อมูลสัญญาเช่า, ข้อมูลรายการเช่ารถ Description: เป็นขั้นตอนบันทึกรายการเช่ารถ โดยจะมีการ ตรวจสอบว่าลูกค้ารายนี้เคยเป็นลูกค้าเก่ามาก่อนหรือไม่ ถ้า หากเคย ก็จะทำการดึงข้อมูลลูกค้าขึ้นมา แต่หากเป็นลูกค้าราย ใหม่ ก็จะดำเนินการสร้างข้อมูลลูกค้าใหม่และบันทึกลงในแฟ้ม ข้อมูลลูกค้าต่อไป จากนั้นก็ดำเนินการบันทึกสัญญาเช่ารถลงไน แฟ้มข้อมูลสัญญาเช่า และบันทึกรายละเอียดการเช่ารถลงใน แฟ้มรายการเช่ารถ Process Description Natural Language Specifications

60 Structured English Process 2.3 : บันทึกรายการเช่ารถ
Ask if customer has an account (or has made a previous contract) If customer has and account then Ask for identification information Query database with identifying information Copy query response data to Contract details Else Create an empty Customer record in the database Ask customer for Customer attributes Update empty Customer record with Customer attributes Endif Ask customer for contract information and Update contract file with contract information While more car rent items Do Update car rent item file with car rent information Endwhile Structured English

61 Decision Tree

62 Decision Table

63 บทที่ 6 แบบจำลองข้อมูล (Data Modeling)

64 แบบจำลองข้อมูล (Data Model)
แบบจำลองข้อมุล ใช้อธิบายเกี่ยวกับ ข้อมูลต่าง ๆ ที่สนับสนุนกระบวนการทาง ธุรกิจในองค์กร

65 แบบจำลองข้อมูล (ต่อ) DFD เป็นแบบจำลองที่นำเสนอด้าน ความสัมพันธ์ระหว่างโปรเซสกับข้อมูล แต่ไม่ได้เน้นถึงความสัมพันธ์ระหว่าง ข้อมูลในระบบ

66 แบบจำลองข้อมูล (ต่อ) ดังนั้น แบบจำลองข้อมูล จึงจัดเป็น เครื่องมือสำคัญอย่างหนึ่งในการนำเสนอ ให้เห็นถึงความสัมพันธ์ระหว่างข้อมูล โดยนำเสนอในรูปแบบของไดอะแกรม ที่เรียกว่า ER-Diagram

67 ER-Diagram ในการวิเคราะห์เพื่อให้ได้มาซึ่ง แผนภาพอีอาร์ จะใช้พื้นฐานหลักๆ 3 ประการ ด้วยกัน คือ 1. Entities 2. Relationship 3. Attributes

68

69 ความสมดุลระหว่าง ER-Diagram กับ DFD
P. 26 พิจารณาจากจำนวนดาต้าสโตร์ใน DFD ระดับที่ 1 ซึ่งจะต้องมีจำนวนเท่ากับ เอ็นติตี้ใน ER-Diagram

70 พจนานุกรมข้อมูล (Data Dictionary)
พจนานุกรมข้อมูล คือเอกสารที่ใช้ อธิบายรายละเอียดโครงสร้างแฟ้มข้อมูล ซึ่งประกอบด้วย ชื่อรีเลชัน แอตตริบิวต์ รายละเอียด โดเมน ดัชนี คีย์หลัก คีย์นอก ชนิดข้อมูล

71 พจนานุกรมข้อมูล (ต่อ)
รูปแบบการนำเสนอพจนานุกรมข้อมูล นั้น จะขึ้นอยู่กับว่าจะนำไปใช้ประโยชน์ อย่างไรเป็นสำคัญ แต่ DD ในรูปแบบของโครงสร้าง แฟ้มข้อมูล ก็เป็นรูปแบบหนึ่งที่นิยมใช้กัน

72 พจนานุกรมในรูปแบบของโครงสร้างแฟ้มข้อมูล

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

74 Normal Form/Relational Data Analysis: RDA

75 ระยะที่ 3 การออกแบบ (Design Phase)

76 (System Design: Part I)
บทที่ 7 การออกแบบระบบ ตอนที่ 1 (System Design: Part I)

77 ระยะที่ 3: การออกแบบ (Design Phase)
จุดประสงค์ของระยะการวิเคราะห์ ก็คือ การค้นหาความจริงถึงความต้องการทาง ธุรกิจว่ามีอะไรบ้าง ในขณะที่ระยะของการออกแบบ จะ ดำเนินการว่าจะจัดการอย่างไรกับการพัฒนา ระบบ

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

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

80

81 ยุทธวิธีการออกแบบ (Design Strategy)
พิจารณาว่าจะดำเนินการพัฒนา- ระบบด้วยแนวทางใด 1. พัฒนาโปรแกรมเอง (In-House Development) 2. ซื้อโปรแกรมสำเร็จรูป (Package Software) 3. ว่าจ้างบริษัทภายนอก (Outsourcing)

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

83 การพัฒนาโปรแกรมขึ้นเอง (In-House/Custom Development)
หน่วยงานจะมีบุคลากรหรือส่วนงาน ระบบสารสนเทศที่ทำหน้าที่พัฒนา ระบบสารสนเทศเพื่อใช้งานภายใน องค์กรเอง

84 ข้อดี 1. ตอบสนองความต้องการแก่ผู้ใช้มาก ที่สุด ไม่ต้องกังวลกับการปรับปรุง โปรแกรมที่ต้องเสียค่าใช้จ่ายเพิ่ม 2. ลดค่าใช้จ่ายด้านอุปกรณ์ฮาร์ดแวร์

85 ข้อดี (ต่อ) 3. ทีมงานเป็นคนภายใน จึงรู้เรื่อง
ข้อดี (ต่อ) 3. ทีมงานเป็นคนภายใน จึงรู้เรื่อง วัฒนธรรมภายในองค์กรเป็นอย่างดี 4. ระบบขัดข้อง เรียกใช้งานได้ทันที

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

87 การซื้อโปรแกรมสำเร็จรูป (Package Software)
เป็นวิธีที่รวดเร็ว ลดเวลาและค่าใช้จ่าย ด้านการพัฒนา

88 ข้อดี 1. สามารถนำมาใช้งานได้ทันที 2. คุณภาพโปรแกรมค่อนข้างดี
มีเอกสารครบถ้วนและมีมาตรฐาน 3. สามารถอัปเกรดเวอร์ชันได้ 4. ได้บริการ/คำปรึกษาจากบริษัทตัวแทน

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

90 ข้อเสีย (ต่อ) 3. ค่าใช้จ่ายสูง กรณีเป็นโปรแกรม
สำเร็จรูปที่ใช้งานกับระบบงานขนาดใหญ่ 4. ต้องมีการฝึกอบรมจากบริษัทตัวแทน 5. ระบบขัดข้อง ต้องพึ่งพาบริษัทเท่านั้น

91 การว่าจ้างบริษัทภายนอก (Outsourcing)
เป็นการว่าจ้างบริษัทภายนอกเข้ามา พัฒนาระบบและดูแลระบบให้ แทนที่ จะใช้บุคลากรภายในองค์กร

92 การว่าจ้างบริษัทภายนอก
บริษัท Outsource จะมีกลุ่มบุคลกรที่ มีความรู้ เชี่ยวชาญ และมีประสบการณ์ ด้าน IT ที่ทันสมัย สามารถพัฒนา ดูแล ระบบที่มีความซับซ้อนได้เป็นอย่างดี

93 ข้อดี 1. เหมาะกับองค์กรที่ไม่มีความพร้อม ด้านการพัฒนาระบบงานด้วยตนเอง
2. หน่วยงานได้ใช้ระบบงานที่มี เทคโนโลยีทันสมัย 3. มั่นใจได้ว่าจะได้ระบบตามความ ต้องการ ส่งมอบระบบตรงเวลา

94 ข้อดี 4. ควบคุมค่าใช้จ่ายได้ 5. ปรับปรุงระบบให้มีความทันสมัย
สามารถดำเนินการได้ง่าย 6. เอกสารเกี่ยวกับระบบงาน มี ครบถ้วน เป็นระบบ และมีมาตรฐาน

95 ข้อเสีย 1. บริษัทเอาต์ซอร์ส์ที่มีศักยภาพสูงใน ประเทศไทย ยังคงมีน้อย
2. ทำให้ต้องสูญเสียความลับในองค์กร 3. องค์กรจำเป็นต้องพึ่งพาบริษัทเอาต์ ซอร์สเพื่อดูแลระบบให้

96 ข้อเสีย (ต่อ) 4. อาจได้รับแรงต่อต้านจากพนักงาน ภายในองค์กร
5. ค่าใช้จ่ายสูง

97 วิธีพื้นฐานการพัฒนาระบบ
1. พัฒนาแบบเฉพาะเจาะจง (Ad Hoc) เป็นวิธีพัฒนาระบบที่มุ่งเน้นเพื่อแก้ไขปัญหาเฉพาะงาน หรือแก้ไขปัญหาเฉพาะหน้าไปก่อน

98 วิธีพื้นฐานการพัฒนาระบบ (ต่อ)
2. พัฒนาด้วยการสร้างฐานข้อมูล (Database) มุ่งเน้นพัฒนาด้วยการสร้างฐานข้อมูลเป็นหลัก ด้วยการออกแบบเพื่อการจัดเก็บข้อมูลอย่างมีระบบ เพื่อประโยชน์ต่อการพัฒนาระบบในอนาคต

99 วิธีพื้นฐานการพัฒนาระบบ (ต่อ)
3. พัฒนาระบบแบบล่างขึ้นบน (Bottom-Up) เน้นพัฒนาระบบตามหน่วยงานแต่ละส่วนก่อน เช่น พัฒนาระบบย่อย ตามหน่วยงานขององค์กร จากนั้นจึงค่อยนำระบบย่อยต่าง ๆ มารวมกัน

100 วิธีพื้นฐานการพัฒนาระบบ (ต่อ)
4. พัฒนาระบบแบบบนลงล่าง (Top-Down) จะทำการวิเคราะห์ระบบงาน ด้วยการมองภาพรวมของระบบก่อน จากนั้น จึงค่อยดำเนินการแตกเป็นระบบย่อย

101 การออกแบบสถาปัตยกรรมระบบ (Architecture Design)
เกี่ยวข้องกับสภาพแวดล้อมทางเทคนิคของระบบงานใหม่ ซึ่งประกอบด้วยการวางแผนเกี่ยวกับ H/W, S/W, Network และ Security เพื่อสนับสนุนระบบงานใหม่

102 สถาปัตยกรรมระบบ 3 รูปแบบ
1. สถาปัตยกรรมเครือข่ายแบบ Centrailzed 2. สถาปัตยกรรมเครือข่ายแบบ File Servers 3. สถาปัตยกรรมเครือข่ายแบบ Client-Server

103 P.247 ภาระงาน ตกอยู่ที่ Host

104 ภาระงาน ตกอยู่ที่ Client

105

106 การกำหนด Spec ให้กับ H/W, S/W

107 การจัดหาอุปกรณ์ระบบ (System Acquisition) 1. การจัดซื้อ (Purchase)
2. การเช่า (Rental) 3. การเช่าซื้อ (Lease)

108

109 การวางแผนด้านความปลอดภัยให้กับระบบ
1. ความปลอดภัยด้านภายนอก 2. การควบคุมสิทธิ์ในการเข้าถึงระบบ 3. การใช้รหัสผ่าน/การแสดงตัวตน 4. การติดตั้งโปรแกรมป้องกันไวรัส

110 การออกแบบฐานข้อมูล ดำเนินการแปลงแบบจำลองข้อมูลเชิงลอจิคัลที่ได้มาจากระยะการวิเคราะห์มาเป็นรายละเอียดทางเทคนิค เพื่อใช้สำหรับจัดเก็บข้อมูลจริง พิจารณา OS และ DBMS ที่ Match กับสถาปัตยกรรมระบบ

111 การออกแบบเอาต์พุต (Output Design)

112 วัตถุประสงค์ของเอาต์พุต
1. ใช้ในการติดต่อข่าวสารระหว่างกิจกรรมต่างๆ 2. ใช้รายงานเหตุการณ์ต่าง ๆ ที่เกิดขึ้นในระบบ 3. แสดงกลไกในการทำงาน 4. เป็นการยืนยันหรือรับรองว่าเกิดการทำงานจริง

113 หลักการพิจารณาเอาต์พุต
1. ใครเป็นผู้ใช้รายงานนี้ 2. ใช้ประโยชน์จากรายงานนี้อย่างไร 3. รายละเอียดข้อมูลในรายงานมีอะไรบ้าง 4. รายงานนี้มีความต้องการใช้บ่อยแค่ไหน 5. รายงานแสดงผลออกทางสื่อใด

114 การจัดรูปแบบรายงาน 1. หัวรายงาน (Heading) 2. รายละเอียด (Details)
3. ผลสรุป (Summaries) 4. หมายเหตุ (Remarks)

115 P. 270

116

117 ประเภทของรายงาน 1. รายงานภายใน (Internal Report)

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

119 การนำเสนอข้อมูลในรายงาน
1. การนำเสนอข้อมูลในรูปแบบตาราง 2. การนำเสนอข้อมูลในรูปแบบกราฟ 3. การนำเสนอข้อมูลในรูปแบบของ ภาพ/ไอคอน

120

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

122 รายงานทางจอภาพ และเครื่องพิมพ์
ข้อดีของรายงานทางจอภาพ ก็คือ สามารถดูผลของรายงานทางจอภาพเพื่อยืนยันในสิ่งที่ต้องการ ก่อนที่จะสั่งพิมพ์ รวมถึงการประหยัดกระดาษ ในกรณีที่ขอดูแค่ข้อมูล แต่ไม่สั่งพิมพ์

123 เอกสาร/รายงานทางอิเล็กทรอนิกส์ ?
รายงานทางจอภาพ และเครื่องพิมพ์ แต่ทั้งนี้ รายงานบางประเภทจำเป็นต้องนำเสนอออกมาทางกระดาษ เพื่อใช้อ้างอิงและใช้เป็นหลักฐาน เอกสาร/รายงานทางอิเล็กทรอนิกส์ ? (PDF File / Scan)

124 ชนิดกระดาษรายงานเพื่อสำเนา
1. กระดาษคาร์บอนในตัว 2. กระดาษคาร์บอนที่แทรกไว้ระหว่างแผ่น

125 การออกแบบอินพุต (Input Design)
พึงจำไว้ว่า! คุณภาพของข้อมูลที่อินพุตเข้าสู่ระบบ ย่อมทำให้ได้มาซึ่งคุณภาพของเอาต์พุต Garbage in! Garbage out!

126 วัตถุประสงค์ของการออกแบบอินพุต
P.278 1. กำหนดวิธีการประมวลผล และคัด เลือกอุปกรณ์อินพุตที่เหมาะสม 2. ควบคุมปริมาณอินพุต 3. ควบคุมข้อผิดพลาดจากการป้อนข้อมูล

127 วัตถุประสงค์ของการออกแบบอินพุต
4. ออกแบบแหล่งข้อมูลเบื้องต้นให้อยู่ในแบบฟอร์มที่เหมาะสม

128

129 วัตถุประสงค์ของการออกแบบอินพุต
5. ออกแบบจอภาพให้ถูกต้องตามหลักการ

130 การออกแบบหน้าจอแบบ GUI
P. 286 1. Text Box

131 การออกแบบหน้าจอแบบ GUI
2. Radio Button

132 การออกแบบหน้าจอแบบ GUI
3. Check Box

133 การออกแบบหน้าจอแบบ GUI
4. Combo Box

134 การออกแบบหน้าจอแบบ GUI
5. List Box

135 การออกแบบหน้าจอแบบ GUI
6. Spin Box

136 การออกแบบหน้าจอแบบ GUI
7. Button

137 (System Design: Part II)
บทที่ 8 การออกแบบระบบ ตอนที่ 2 (System Design: Part II)

138 การออกแบบ User Interface
ระบบที่ดีควรมีอินเตอร์เฟซระหว่าง ผู้ใช้งานกับระบบที่ดีด้วย ควรออกแบบการโต้ตอบให้น่าสนใจ รวมถึงใช้สื่ออุปกรณ์ที่เหมาะสมสำหรับ การใช้โต้ตอบระหว่างกัน

139 ชนิดของ User Interface
1. การอินเตอร์เฟสด้วยภาษาธรรมชาติ 2. การอินเตอร์เฟสด้วยคำถามและคำตอบ 3. การอินเตอร์เฟสด้วยเมนู 4. การอินเตอร์เฟสด้วยชุดคำสั่ง 5. การอินเตอร์เฟสแบบ GUI

140 ข้อแนะนำในการออกแบบ UI ที่ดี
1. ผู้ใช้งานต้องรู้ว่า สิ่งที่ทำอยู่นี้คืออะไร และต้องดำเนินการอย่างไรต่อไป 2. สามารถซูมดูรายละเอียดเฉพาะที่ต้องการได้ 3. ข้อมูลที่แสดง ต้องมีความยาวเพียงพอต่อการ อ่าน แล้วทำให้เกิดความเข้าใจ

141 ข้อแนะนำในการออกแบบ UI ที่ดี
4. การนำเสนอข้อความบนจอภาพ ควรใช้ เฉดสีที่เหมาะสม อย่างเล่นสีสรรมาก เกินไปจนดูเลอะเทอะ 5. หากโปรแกรม จำเป็นต้องกำหนดตัวแปรต่าง ๆ ให้กับสภาพแวดล้อม ดังนั้น ควรกำหนดค่า Default และสามารถปรับได้ภายหลัง

142 ข้อแนะนำในการออกแบบ UI ที่ดี
6. ควรมีข้อความยืนยันการกระทำ สำหรับกรณี โปรเซสที่ส่งผลต่อข้อมูล เช่น การลบข้อมูล 7. ควรเอาใจใส่ต่อข้อผิดพลาด โดยไม่อนุญาต ให้มีการประมวลผลใด ๆ จนกว่าจะทำการแก้ไข ข้อผิดพลาดในข้อมูลให้ถูกต้องเสียก่อน

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

144 การจัดทำต้นแบบ (Prototype)
เป็นการจัดทำต้นแบบผลิตภัณฑ์ เพื่อให้ผู้ใช้งานได้เห็นภาพและแนวทางของระบบใหม่ เพื่อพิจารณาว่าตรงตามความต้องการหรือไม่

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

146 ประเภทของ Prototype 1. โปรโตไทป์แบบทำแล้วโยนทิ้ง
1. โปรโตไทป์แบบทำแล้วโยนทิ้ง 2. โปรโตไทป์แบบมีพัฒนาการ ในปัจจุบันมี S/W มากมายที่สามารถนำมาใช้เป็นเครื่องมือเพื่อสร้างโปรโตไทป์

147 Prototyping Life Cycle

148 การออกแบบโปรแกรม เป้าหมายหลักของการออกแบบโปรแกรมเชิงโครงสร้าง ก็คือการสร้างโปรแกรมที่ประกอบไปด้วยฟังก์ชันของโมดูลต่าง ๆ ว่ามีความสัมพันธ์กับโมดูลอื่น ๆ ที่เกี่ยวข้องอย่างไร

149 การออกแบบโปรแกรม เป้าหมายหลักของการออกแบบโปรแกรมเชิงโครงสร้าง ก็คือการสร้างโปรแกรมที่ประกอบไปด้วยฟังก์ชันของโมดูลต่าง ๆ ว่ามีความสัมพันธ์กับโมดูลอื่น ๆ ที่เกี่ยวข้องอย่างไร

150

151 การออกแบบผังโครงสร้างที่ดี
1. ควรออกแบบให้แต่ละโมดูลมีความเป็น หนึ่งเดียวสูง (High Cohesion) จะทำให้ง่ายต่อการปรับปรุงโปรแกรม โมดูลที่ปฏิบัติงานเพียงงานเดียว ถือว่ามี Cohesion สูง และเรียกซ้ำเพื่อใช้งานได้ตามความต้องการ

152 การออกแบบผังโครงสร้างที่ดี
2. ควรออกแบบให้แต่ละโมดูล มีความ สัมพันธ์แบบหลวมๆ (Loosely Coupled) โมดูลที่ดี ควรมีความเป็นอิสระ ไม่ขึ้นต่อกัน แต่ไม่ได้หมายความว่าแต่ละโมดูลนั้นจะไม่มีความสัมพันธ์กันเลย เนื่องจากแต่ละ โมดูลจำเป็นต้องมีคอนเน็กชันระหว่างกัน

153 การออกแบบผังโครงสร้างที่ดี
โมดูลที่มีความสัมพันธ์กับโมดูลอื่นอย่างแน่นแฟ้น (Tightly Coupled) คือโมดูลที่ภายในมีตรรกะที่อ้างอิงตรรกะบนโมดูลอื่นจำนวนมาก การปรับปรุงแก้ไขตรรกะส่วนหนึ่ง จะกระทบต่อโมดูลอื่น ๆ

154 สรุปกิจกรรมของระยะการออกแบบ
1. พิจารณาแนวทางการพัฒนาระบบ 2. การออกแบบสถาปัตยกรรมระบบ 3. การออกแบบฐานข้อมูล 4. การออกแบบเอาต์พุต

155 สรุปกิจกรรมของระยะการออกแบบ
5. การออกแบบอินพุต 6. การออกแบบ User Interface 7. การจัดทำต้นแบบ (Prototype) 8. ออกแบบโปรแกรม

156 (Implementation Phase and Maintenance Phase)
ระยะที่ 4 และ 5 การนำไปใช้ และการบำรุงรักษา (Implementation Phase and Maintenance Phase)

157 การสร้างระบบ การติดตั้ง (Construction, Installation and
บทที่ 9 การสร้างระบบ การติดตั้ง และการบำรุงรักษา (Construction, Installation and Maintenance)

158 (Implementation Phase)
ระยะที่ 4: การนำไปใช้ (Implementation Phase) เป็นระยะที่ดำเนินการให้ระบบเกิดผล ขึ้นมาด้วยการสร้างระบบ ทดสอบระบบ และติดตั้งระบบ

159 (Implementation Phase)
ระยะที่ 4: การนำไปใช้ (Implementation Phase) ลำดับกิจกรรมต่าง ๆ ทุกกิจกรรม จะต้องเข้ามาดำเนินการร่วมกันในระยะนี้ เพื่อให้ระบบสามารถปฏิบัติได้อย่างลงเอย ที่สุด

160

161 ประกอบด้วยกิจกรรมดังนี้
การทำให้ระบบเกิดผล ประกอบด้วยกิจกรรมดังนี้ 1. การเขียนโปรแกรม 2. การทดสอบโปรแกรม 3. การติดตั้งระบบ 4. การจัดทำเอกสารคู่มือการใช้งาน 5. การฝึกอบรม 6. การประเมินผลระบบ

162 การเขียนโปรแกรม โปรแกรมเมอร์จะเป็นผู้เขียนโปรแกรม ให้เป็นไปตามมาตรฐานที่นักวิเคราะห์ ระบบได้กำหนดไว้

163 ขั้นตอนการเขียนโปรแกรม
1. ศึกษาจากเอกสาร 2. ออกแบบโปรแกรม 3. เขียนโปรแกรม 4. ทดสอบโปรแกรม 5. จัดทำเอกสารประกอบโปรแกรม

164 การทดสอบ (Testing) เป็นการทดสอบโปรแกรมที่ใช้งานใน ระบบว่าสามารถทำงานได้อย่างถูกต้อง หรือไม่ ก่อนที่จะดำเนินการติดตั้งระบบ เพื่อใช้งานจริงต่อไป

165 การทดสอบ (Testing) อาจมีการจำลองสถานการณ์ขึ้นมา เพื่อให้เกิดเหตุการณ์และมีการบันทึกข้อมูล เข้าสู่ระบบ การทดสอบระบบ จะมีการรับประกัน ถึงความถูกต้องทั้งในส่วน Verification และ Validation

166 เทคนิคการทดสอบ 1. Black Box Testing

167 เทคนิคการทดสอบ (ต่อ) 2. White Box Testing

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

169 ขั้นตอนการทดสอบ (ต่อ)
2. การทดสอบด้วยการนำโปรแกรมมา ประกอบรวมกัน (Integration Testing) คือการทดสอบด้วยการนำกลุ่มโปรแกรม ต่าง ๆ มาประกอบรวมกัน และต้องมั่นใจว่าการ เชื่อมโยงและส่งผ่านข้อมูลไปมาระหว่างโมดูล จะต้องทำงานได้อย่างถูกต้องและครบถ้วน

170 ขั้นตอนการทดสอบ (ต่อ)
3. การทดสอบทั้งระบบ (System Testing) คือการทดสอบระบบทั้งหมด ก่อนที่จะ ส่งมอบแก่ลูกค้าหรือผู้ว่าจ้าง โดยจะทดสอบ ทั้งฟังก์ชันการทำงาน และทดสอบ ประสิทธิภาพของระบบ

171 ขั้นตอนการทดสอบ (ต่อ)
4. การทดสอบการยอมรับในระบบ (Acceptance Testing) เป็นขั้นตอนสุดท้ายของการทดสอบ เพื่อ ยืนยันถึงความสมบูรณ์ของระบบว่าสามารถ รองรับการกระบวนการทางธุรกิจได้ตรงตาม ความต้องการ ถูกต้อง และครบถ้วนหรือไม่

172 ขั้นตอนการทดสอบ (ต่อ)
การทดสอบการยอมรับในระบบ ประกอบด้วย 2 ขั้นตอนด้วยกันคือ 1. Alpha Testing 2. Beta Testing

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

174 การติดตั้งระบบ (Installation)
1. การติดตั้งเพื่อใช้งานใหม่ทันที 2. การติดตั้งแบบคู่ขนาน 3. การติดตั้งแบบทีละระยะ 4. การติดตั้งแบบโครงการนำร่อง

175 การติดตั้งเพื่อใช้งานใหม่ทันที (Direct Installation)
เป็นวิธีการติดตั้งด้วยการหยุดใช้งาน ระบบเดิม และเปลี่ยนมาใช้ระบบใหม่โดย ทันที

176 ข้อดี 1. ระบบใหม่สามารถดำเนินการได้ทันที
2. สถานการณ์บังคับให้ผู้ใช้งานต้องใช้ งานระบบใหม่ 3. ง่ายต่อการวางแผน 4. ค่าใช้จ่ายต่ำ ใช้เวลาน้อย

177 ข้อเสีย 1. อาจเกิดข้อผิดพลาดที่คาดไม่ถึงใน ขณะที่ใช้ระบบใหม่
2. เป็นวิธีที่มีความเสี่ยงสูงที่สุด

178 การติดตั้งแบบคู่ขนาน (Parallel Installation)
เป็นวิธีการติดตั้งที่มีการปฏิบัติงานทั้ง ระบบเดิมกับระบบใหม่คู่ขนานกันไป โดย จะยกเลิกระบบเดิมต่อเมื่อการดำเนินงาน ของระบบใหม่ไม่มีข้อผิดพลาดใดๆ

179 ข้อดี 1. มีความปลอดภัยสูง 2. สามารถเปรียบเทียบกระบวนการ
ทำงานระหว่างระบบเดิมกับระบบใหม่

180 ข้อเสีย 1. ใช้ต้นทุนสูง 2. สิ้นเปลืองเวลา เพราะทำงานทั้ง 2 ระบบ
3. ผู้ใช้งานอาจมีทัศนคติที่ไม่ต่อระบบ ใหม่ หากระบบใหม่มีข้อผิดพลาดสูง 4. ยากต่อการวางแผน และการควบคุม

181 การติดตั้งแบบทีละเฟส (Phased Installation)
เป็นวิธีการติดตั้งที่มีการกำหนดเป็น ระยะๆ แต่ละระยะจะมีการเพิ่มฟังก์ชันการ ทำงานของระบบ เช่น การติดตั้งระบบทีละ ระบบย่อย

182 ข้อดี 1. กรณีว่าจ้างพัฒนา เจ้าของระบบ
1. กรณีว่าจ้างพัฒนา เจ้าของระบบ สามารถชำระเงินค่าระบบเฉพาะระยะนั้นๆ 2. หากเกิดข้อผิดพลาด จะไม่ส่งผลกระทบ ต่อระบบโดยรวม ทำให้ลดความเสี่ยง 3. เหมาะกับระบบงานขนาดใหญ่ที่มี ความซับซ้อนสูง

183 ข้อเสีย 1. อาจใช้เวลามากเกินไปกับบาง ระบบงาน ซึ่งส่งผลกระทบต่อการ
รอพัฒนาในเฟสต่อไป 2. ไม่เหมาะกับระบบงานที่ไม่สามารถ แบ่งระบบออกเป็นส่วนย่อยๆ ได้

184 การติดตั้งแบบโครงการนำร่อง (Pilot Project)
เป็นวิธีการติดตั้งที่คล้ายกับวิธีการติดตั้ง แบบทีละเฟส โดยจะดำเนินการติดตั้ง ระบบเฉพาะส่วนงานใดส่วนงานหนึ่งก่อน เช่น ติดตั้งทีละแผนก

185 ข้อดี ข้อเสีย 1. ลดความเสี่ยงได้ดี 2. ค่าใช้จ่ายต่ำ
1. เหมาะกับระบบที่มีความสมบูรณ์ใน ตัวเอง ที่ไม่เกี่ยวข้องกับระบบงานอื่นๆ

186 การจัดทำเอกสารคู่มือใช้งาน
1. เอกสารคู่มือสำหรับผู้ใช้ (User Documentation) เป็นเอกสารคู่มือที่ช่วยให้ผู้ใช้ปฏิบัติงานกับระบบ โดยมุ่งหวังว่า เมื่อผู้ใช้อ่านแล้ว สามารถปฏิบัติตามขั้นตอนเพื่อทำงานได้

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

188 การฝึกอบรม (Training)
ตามปกติแล้ว จะมีบุคคลอยู่ 2 กลุ่มด้วยกันที่ใช้งานระบบ คือ ผู้ใช้ (Users) และ ผู้ปฏิบัติการ (Operator)

189 User Operator

190 ชนิดของการฝึกอบรม 1. การฝึกอบรมผู้ใช้
1. การฝึกอบรมผู้ใช้ จะตั้งอยู่บนพื้นฐานการทำงานของระบบ 2. การฝึกอบรมผู้ปฏิบัติการ มุ่งสนใจถึงหน้าที่การสนับสนุนระบบเป็นหลัก

191 วิธีการฝึกอบรม 1. การฝึกอบรมโดยใช้วิทยากร 2. การฝึกอบรมด้วยตนเอง

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

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

194 ระยะที่ 5: การบำรุงรักษา (Maintenance Phase)
หลังจากที่ระบบงานได้ติดตั้งและใช้ งานจริงในระยะเวลาหนึ่ง ผู้ใช้งานอาจพบ ปัญหาที่เกิดขึ้น หรืออาจมีความต้องการ เพิ่มเติมใหม่ๆ ได้

195 ประกอบด้วยกิจกรรมดังนี้
การบำรุงรักษา ประกอบด้วยกิจกรรมดังนี้ 1. การบำรุงรักษาระบบ 2. การเพิ่มเติมคุณสมบัติใหม่ๆ เข้าไปในระบบ 3. การสนับสนุนงานของผู้ใช้

196 ชนิดของการบำรุงรักษา
1. การบำรุงรักษาด้วยการแก้ไขให้ ถูกต้อง (Corrective Maintenance) 2. การบำรุงรักษาด้วยการปรับระบบให้ รองรับสภาพแวดล้อมที่เปลี่ยนแปลง ไป (Adaptive Maintenance)

197 วิธีการบำรุงรักษา 3. การบำรุงรักษาด้วยการปรับปรุงระบบ
ให้มีประสิทธิภาพยิ่งขึ้น (Perfective Maintenance) 4. การบำรุงรักษาเชิงป้องกัน (Preventive Maintenance)

198