บทที่ 5 แบบจำลองกระบวนการ (Process Modeling)
สาเหตุที่ต้องมีแบบจำลองหลาย ชนิดก็เพราะว่า ไม่มีแบบจำลอง ชนิดใดที่สามารถนำเสนอ มุมมองในความต้องการของ ระบบได้ครบทุกๆ ส่วน
ชนิดของแบบจำลอง 1. แบบจำลองคณิตศาสตร์ โดยมากใช้กับงานด้านการคำนวณ ทั่วไป งานด้านวิทยาศาสตร์ ซึ่งมักนำเสนอในรูปแบบของสูตรทางคณิตศาสตร์ หรือฟังก์ชัน
ชนิดของแบบจำลอง (ต่อ) ชนิดของแบบจำลอง (ต่อ) 2. แบบจำลองที่เป็นถ้อยคำอธิบาย ใช้สำหรับกล่าวนำถึงเรื่องราว ถ้อยคำบรรยาย และยังสามารถนำไปเขียนอยู่ใน รูปแบบของซูโดโค้ด เพื่อให้โปรแกรมเมอร์นำไปใช้เพื่อออกแบบโปรแกรม
ชนิดของแบบจำลอง (ต่อ) ชนิดของแบบจำลอง (ต่อ) 3. แบบจำลองแผนภาพ หรือเรียกว่าไดอะแกรม (Diagram) จัดเป็นแบบจำลองที่ใช้ประโยชน์มากที่สุด ซึ่งพัฒนาโดยนักวิเคราะห์ระบบ เพราะว่า Diagram ทำให้เข้าใจถึงความสัมพันธ์ของสิ่งต่าง ๆ ที่มีอยู่ในระบบ
(Data Flow Diagram: DFD) ตัวอย่างแบบจำลองกระบวนการ แผนภาพกระแสข้อมูล (Data Flow Diagram: DFD) แผนภาพอีอาร์ (ER-Diagram)
Data Flow Diagram (DFD) การสร้างบ้าน จำเป็นต้องมีแบบแปลน หรือแบบพิมพ์เขียว (Blueprint) DFD เปรียบเสมือนแบบพิมพ์เขียวเพื่อ นำไปใช้พัฒนาระบบสารสนเทศ
Data Flow Diagram (ต่อ)
Data Flow Diagram (ต่อ) Data Flow Diagram จะแสดง ความสัมพันธ์ระหว่างโปรเซส (Processes) กับ ข้อมูล (Data) ที่เกี่ยวข้อง
Data Flow Diagram (ต่อ) โดยข้อมูลในแผนภาพ จะทำให้ทราบถึง 1. ข้อมูลมาจากไหน 2. ข้อมูลไปที่ไหน 3. ข้อมูลเก็บไว้ที่ใด 4. เกิดเหตุการณ์ใดกับข้อมูลใน ระหว่างทาง
Data Flow Diagram (ต่อ) เนื่องจาก DFD แสดงภาพรวมของระบบ และรายละเอียดเกี่ยวกับโปรเซสกับข้อมูล ดังนั้น หากต้องการกำหนดรายละเอียด เพิ่มเติม SA.จำเป็นต้องใช้เครื่องมืออื่นช่วย เช่น อัลกอริทึม ตารางตัดสินใจ แบบจำลอง ข้อมูล และ Process Description
ขั้นตอนการวิเคราะห์เพื่อสร้าง DFD P. 164
DFD กับมุมมองการใช้งาน SA. ใช้ประโยชน์จาก DFD เพื่อแสดง ภาพรวมของระบบ และรายละเอียดของระบบ
วัตถุประสงค์ของ DFD 1. เป็นแผนภาพที่สรุปรวมข้อมูลทั้งหมดที่ ได้จากการวิเคราะห์ (Structured) 2. เป็นข้อตกลงร่วมกันระหว่าง นักวิเคราะห์ระบบกับยูสเซอร์ 3. สามารถนำไปใช้ประโยชน์ในขั้นตอนของ การออกแบบระบบ
วัตถุประสงค์ของ DFD (ต่อ) 4. ใช้อ้างอิง เพื่อนำไปปรับปรุง/พัฒนาต่อ ในอนาคต 5. ทราบที่มาที่ไปของข้อมูลที่ไหลไปยัง กระบวนการต่าง ๆ (Data and Processes)
สัญลักษณ์ที่ใช้ใน DFD P. 166
มาตรฐานสัญลักษณ์ของ DFD
Processes เป็นสัญลักษณ์แทนกิจกรรมที่เกิดขึ้นใน ระบบสารสนเทศ หรือกระบวนการที่ต้อง ทำในระบบ แผนภาพกระแสข้อมูลจะต้อง มีโปรเซสอย่างน้อยหนึ่งโปรเซสเสมอ
Processes (ต่อ)
Processes (ต่อ) โปรเซสต้องมีหมายเลขกำกับเสมอ ลำดับหมายเลขโปรเซส ไม่ได้ หมายความว่าต้องดำเนินกิจกรรมตามลำดับ ของโปรเซสแต่อย่างใด
Processes (ต่อ) หมายเลขโปรเซส ซ้ำกันไม่ได้ ชื่อที่ใช้กำกับโปรเซส ให้ใช้คำกริยา ซึ่ง หมายถึงการกระทำ จำนวนโปรเซส 7 บวกลบ 2
Processes (ต่อ) โปรเซสใน DFD จะไม่มีการแสดง รายละเอียดเกี่ยวกับวิธีการทำงาน แต่โปรเซสจะทำให้ทราบว่ามีอินพุต อะไรเข้าไป และเมื่อผ่านการประมวลผล ออกมาแล้ว ได้เอาต์พุตอะไรออกมา
Processes (ต่อ) ดังนั้น โปรเซสจึงเปรียบเสมือนกับ กล่องดำ (Black Box) ที่นำเสนอเพียงว่าทำ หน้าที่อะไร มีอะไรที่อินพุตเข้าไป และมี อะไรที่เอาต์พุตออกมา
Processes Description
Data Flows Data Flow หรือกระแสข้อมูล ใช้ สัญลักษณ์แทนด้วยเส้นลูกศรที่ไปพร้อมกับ ข้อมูล ทำให้ทราบถึงข้อมูลที่เคลื่อนไหวไป มาระหว่าง Process, Data Store และ External Entity
Data Flows (ต่อ) ทุกโปรเซสใน DFD เมื่อมีดาต้าโฟลว์ อินพุตเข้าไป ก็ย่อมมีดาต้าโฟลว์เอาต์พุต ออกมาเสมอ โดยอาจมีอินพุตหรือเอาต์พุต ของดาต้าโฟลว์มากกว่าหนึ่งจุดก็เป็นได้
Data Flows (ต่อ) แต่ถ้าหากโปรเซสมีเพียงดาต้าโฟลว์ที่ อินพุตเข้าไป โดยไม่มีเอาต์พุตออกมา หรือโปรเซสที่มีเพียงดาต้าโฟลว์ที่เอาต์พุต ออกมาโดยไม่มีข้อมูลอินพุต ถือว่า…ผิดธรรมชาติ
Data Flows (ต่อ)
Data Flows (ต่อ) แผนภาพ DFD จะมีดาต้าโฟลว์จำนวนมาก ในแผนภาพ ดังนั้น จึงอาจทำให้ดาต้าโฟลว์แต่ ละเส้นเกิดการทับซ้อนกัน หลักการเขียน DFD ที่ดี ไม่ควรมีเส้นดาต้า โฟลว์ทับซ้อนกัน เพราะจะทำให้แลดูยุ่งเหยิง ไม่มีระเบียบ
Data Flows (ต่อ)
External Entities แผนภาพ DFD จะมีดาต้าโฟลว์ที่อินพุต เข้ามาในระบบ และดาต้าโฟลว์ที่เอาต์พุต ออกจากระบบ โดยส่วนที่ทำหน้าที่ส่งและ รับข้อมูลนี้ เรียกว่า เอ็กซ์เทอร์นัลเอ็นติตี้ ซึ่งมีสัญลักษณ์เป็นรูปสี่เหลี่ยมผืนผ้า
External Entities (ต่อ) เอ็กซ์เทอร์นัลเอ็นติตี้ จะมีหน้าที่ในการส่ง หรือรับข้อมูลจากโปรเซสเท่านั้น ดาต้าโฟล์วที่ อินพุตเข้ามาในระบบถือเป็นแหล่งกำเนิดของ ข้อมูล (Data Source) ในขณะที่ดาต้าโฟล์วที่ เอาต์พุตออกมาจากโปรเซสก็จะถูกส่งไปยัง ปลายทาง (Destination)
External Entities (ต่อ) และด้วยเหตุนี้เอง สัญลักษณ์นี้ จึง สามารถเรียกได้หลายชื่อด้วยกัน เช่น Source Boundary Destination External Agent
External Entities (ต่อ) เอ็กซ์เทอร์นัลเอ็นติตี้ จะมีหน้าที่ในการส่ง หรือรับข้อมูลจากโปรเซสเท่านั้น ดาต้าโฟล์วที่ อินพุตเข้ามาในระบบถือเป็นแหล่งกำเนิดของ ข้อมูล (Data Source) ในขณะที่ดาต้าโฟล์วที่ เอาต์พุตออกมาจากโปรเซสก็จะถูกส่งไปยัง ปลายทาง (Destination)
External Entities (ต่อ) ข้อสำคัญประการหนึ่งคือ ดาต้าโฟลว์ที่ เข้าออกระหว่างเอ็กซ์เทอร์นัลเอ็นติตี้จะต้อง ผ่านโปรเซสเสมอ ไม่สามารถเชื่อมโยง กับดาต้า สโตร์ได้ เนื่องจากไม่สามารถสื่อ ความหมายใดๆ ได้เลย
External Entities (ต่อ) เอ็กซ์เทอร์นัลเอ็นติตี้สามารถเป็นได้ทั้ง บุคคล หน่วยงาน หรือระบบงาน การพิจารณาบุคคลที่จะมาเป็นเอ็กซ์เทอร์นัล เอ็นติตี้ได้นั้น ให้พิจารณาถึงบุคคลภายนอกที่ ระบบไม่สามารถควบคุมได้เป็นสำคัญ โดย บุคคลที่ปฏิบัติงานกับโปรเซสโดยตรงจะไม่ นำมาพิจารณา
External Entities (ต่อ) เอ็กซ์เทอร์นัลเอ็นติตี้มักจะถูกจัดให้อยู่ บริเวณด้านนอกหรือรอบ ๆ ของแผนภาพ เพื่อให้แผนภาพแลดูสวย ง่ายต่อการดู และ ที่สำคัญ เอ็กซ์เทอร์นัลเอ็นติตี้สามารถ กระทำซ้ำ (Duplicate) ได้
External Entities (ต่อ)
Data Stores ดาต้าสโตร์เป็นแหล่งที่ใช้เก็บข้อมูล ซึ่งไม่ สนใจว่าระบบจะใช้สื่อจัดเก็บข้อมูลเป็นชนิดใด ทุก ๆ ดาต้าสโตร์จะต้องมีชื่อข้อมูล และมี ลาเบลกำหนด เช่น D1 D2 D3 ตามลำดับ
Data Stores (ต่อ) ดาต้าสโตร์จะถูกใช้งานโดยโปรเซส และ ดาต้าสโตร์ยังสามารถ Duplicate ได้ สำหรับที่มาของดาต้าสโตร์ ก็จะได้มาจาก การสร้างแบบจำลองข้อมูล (Data Model)
Data Stores (ต่อ)
Data Stores (ต่อ) สำหรับ DFD ระดับที่ 1 โปรเซสส่วนใหญ่ ที่เชื่อมต่อกับดาต้าสโตร์มักเป็นแบบอินพุต/ เอาต์พุต เนื่องจากแผนภาพในระดับล่างลงไป โปรเซสการทำงานส่วนใหญ่มักจะมีทั้งการ เข้าถึงข้อมูลในดาต้าสโตร์แบบอินพุต และ เอาต์พุต
ขั้นตอนการเขียน DFD 1. วิเคราะห์ให้ได้ว่า ระบบควรประกอบ 1. วิเคราะห์ให้ได้ว่า ระบบควรประกอบ ด้วยเอ็กซ์เทอร์นัลเอ็นติตี้อะไรบ้าง 2. ดำเนินการเขียน Context Diagram 3. วิเคราะห์ข้อมูลในระบบว่า ควรมีข้อมูล อะไรบ้าง
ขั้นตอนการเขียน DFD (ต่อ) 4. วิเคราะห์โปรเซสในระบบว่า ควรมี โปรเซสหลัก ๆ อะไรบ้าง ประกอบด้วย โปรเซสย่อยอะไรบ้าง 5. ดำเนินการเขียน DFD-Level 1, 2
ขั้นตอนการเขียน DFD (ต่อ) 6. ทำการตรวจสอบความสมดุล (Balancing) ของแผนภาพ และทำการปรับแก้จนกระทั่งได้แผนภาพกระแสข้อมูลที่สมบูรณ์และถูกต้อง 7. อาจใช้โปรแกรม Visio หรือโปรแกรมเคสทูลส์ ในการสร้างไดอะแกรม
การตรวจสอบ Balancing
(Process Description) คำอธิบายการประมวลผล (Process Description) แผนภาพกระแสข้อมูล (DFD) เป็นไดอะแกรมที่นำเสนอให้เห็นภาพรวมของระบบได้เป็นอย่างดี แต่มีข้อเสียตรงที่ไม่ได้มีการแสดงรายละเอียดของแต่ละโปรเซส
คำอธิบายการประมวลผล (ต่อ) ดังนั้น หากต้องการรายละเอียดภายในของแต่ละโปรเซส ว่าโปรเซสมีกระบวนการทำงานอย่างไร จึงจำเป็นต้องใช้ Process Description
ระดับของ PD 1. ระดับการใช้งาน (Usage Level) เป็นคำอธิบายการประมวลผลในระดับที่มุ่งเน้นจับรายละเอียดด้านการปฏิบัติงานของผู้ใช้เป็นสำคัญ ด้วยถ้อยคำ เรียงความบรรยาย หรือเรียกว่า ภาษาธรรมชาติ
ระดับของ PD (ต่อ) 2. ระดับระบบ (System Level) เป็นคำอธิบายการประมวลผลในระดับที่มุ่งเน้นถึงความเที่ยงตรงในรายละเอียดเป็นสำคัญ เช่น Structured English, Decision Tree และ Decision Table
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
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
Decision Tree
Decision Table
บทที่ 6 แบบจำลองข้อมูล (Data Modeling)
แบบจำลองข้อมูล (Data Model) แบบจำลองข้อมุล ใช้อธิบายเกี่ยวกับ ข้อมูลต่าง ๆ ที่สนับสนุนกระบวนการทาง ธุรกิจในองค์กร
แบบจำลองข้อมูล (ต่อ) DFD เป็นแบบจำลองที่นำเสนอด้าน ความสัมพันธ์ระหว่างโปรเซสกับข้อมูล แต่ไม่ได้เน้นถึงความสัมพันธ์ระหว่าง ข้อมูลในระบบ
แบบจำลองข้อมูล (ต่อ) ดังนั้น แบบจำลองข้อมูล จึงจัดเป็น เครื่องมือสำคัญอย่างหนึ่งในการนำเสนอ ให้เห็นถึงความสัมพันธ์ระหว่างข้อมูล โดยนำเสนอในรูปแบบของไดอะแกรม ที่เรียกว่า ER-Diagram
ER-Diagram ในการวิเคราะห์เพื่อให้ได้มาซึ่ง แผนภาพอีอาร์ จะใช้พื้นฐานหลักๆ 3 ประการ ด้วยกัน คือ 1. Entities 2. Relationship 3. Attributes
ความสมดุลระหว่าง ER-Diagram กับ DFD P. 26 พิจารณาจากจำนวนดาต้าสโตร์ใน DFD ระดับที่ 1 ซึ่งจะต้องมีจำนวนเท่ากับ เอ็นติตี้ใน ER-Diagram
พจนานุกรมข้อมูล (Data Dictionary) พจนานุกรมข้อมูล คือเอกสารที่ใช้ อธิบายรายละเอียดโครงสร้างแฟ้มข้อมูล ซึ่งประกอบด้วย ชื่อรีเลชัน แอตตริบิวต์ รายละเอียด โดเมน ดัชนี คีย์หลัก คีย์นอก ชนิดข้อมูล
พจนานุกรมข้อมูล (ต่อ) รูปแบบการนำเสนอพจนานุกรมข้อมูล นั้น จะขึ้นอยู่กับว่าจะนำไปใช้ประโยชน์ อย่างไรเป็นสำคัญ แต่ DD ในรูปแบบของโครงสร้าง แฟ้มข้อมูล ก็เป็นรูปแบบหนึ่งที่นิยมใช้กัน
พจนานุกรมในรูปแบบของโครงสร้างแฟ้มข้อมูล
การนอร์มัลไลเซชัน (Normalization) เป็นกระบวนการนำโครงร่างรีเลชัน มา แตกเป็นตารางต่าง ๆ ให้อยู่ในรูปแบบที่ เรียกว่า Normal Form โดยมีจุดประสงค์เพื่อลดเนื้อที่ในการ จัดเก็บข้อมูล และลดปัญหาความไม่ถูกต้อง ของข้อมูล
Normal Form/Relational Data Analysis: RDA
ระยะที่ 3 การออกแบบ (Design Phase)
(System Design: Part I) บทที่ 7 การออกแบบระบบ ตอนที่ 1 (System Design: Part I)
ระยะที่ 3: การออกแบบ (Design Phase) จุดประสงค์ของระยะการวิเคราะห์ ก็คือ การค้นหาความจริงถึงความต้องการทาง ธุรกิจว่ามีอะไรบ้าง ในขณะที่ระยะของการออกแบบ จะ ดำเนินการว่าจะจัดการอย่างไรกับการพัฒนา ระบบ
ดังนั้น ในระยะการออกแบบ จุดเริ่มต้นของทีมงานพัฒนาระบบก็ คือ จะต้องนำเอกสารและไดอะแกรม ที่ได้จากระยะการวิเคราะห์มาเป็น ไดอะแกรมเชิงฟิสิคัล
กล่าวคือ ระยะการวิเคราะห์ จะ เป็นการกำหนดความสัมพันธ์ต่าง ๆ ว่าระบบมีอะไรบ้าง ในขณะที่ระยะ การออกแบบ จะนำไดอะแกรมมาเป็น อินพุตเพื่อออกแบบระบบให้อยู่ใน รูปแบบของการปฏิบัติงานได้จริง
ยุทธวิธีการออกแบบ (Design Strategy) พิจารณาว่าจะดำเนินการพัฒนา- ระบบด้วยแนวทางใด 1. พัฒนาโปรแกรมเอง (In-House Development) 2. ซื้อโปรแกรมสำเร็จรูป (Package Software) 3. ว่าจ้างบริษัทภายนอก (Outsourcing)
ยุทธวิธีการออกแบบ (ต่อ) แนวทางการพัฒนาระบบแต่ละ แนวทาง จะมีความคุ้มค่าต่อความ ต้องการ ก็ต่อเมื่อถูกนำไปใช้ได้อย่าง เหมาะสม ซึ่งขึ้นอยู่กับปัจจัยต่าง ๆ ประกอบรวมกัน
การพัฒนาโปรแกรมขึ้นเอง (In-House/Custom Development) หน่วยงานจะมีบุคลากรหรือส่วนงาน ระบบสารสนเทศที่ทำหน้าที่พัฒนา ระบบสารสนเทศเพื่อใช้งานภายใน องค์กรเอง
ข้อดี 1. ตอบสนองความต้องการแก่ผู้ใช้มาก ที่สุด ไม่ต้องกังวลกับการปรับปรุง โปรแกรมที่ต้องเสียค่าใช้จ่ายเพิ่ม 2. ลดค่าใช้จ่ายด้านอุปกรณ์ฮาร์ดแวร์
ข้อดี (ต่อ) 3. ทีมงานเป็นคนภายใน จึงรู้เรื่อง ข้อดี (ต่อ) 3. ทีมงานเป็นคนภายใน จึงรู้เรื่อง วัฒนธรรมภายในองค์กรเป็นอย่างดี 4. ระบบขัดข้อง เรียกใช้งานได้ทันที
ข้อเสีย 1. สิ้นเปลือง คชจ. ในการพัฒนาความรู้ 2. เอกสารประกอบโปรแกรม และ ไดอะแกรมต่างๆ อาจไม่ได้รับการ จัดทำ หรือมีรูปแบบไม่เป็นมาตรฐาน 3. ไม่เหมาะกับระบบที่มีความซับซ้อนสูง ซึ่งอาจได้ระบบไม่สำเร็จตามที่คาดหวัง
การซื้อโปรแกรมสำเร็จรูป (Package Software) เป็นวิธีที่รวดเร็ว ลดเวลาและค่าใช้จ่าย ด้านการพัฒนา
ข้อดี 1. สามารถนำมาใช้งานได้ทันที 2. คุณภาพโปรแกรมค่อนข้างดี มีเอกสารครบถ้วนและมีมาตรฐาน 3. สามารถอัปเกรดเวอร์ชันได้ 4. ได้บริการ/คำปรึกษาจากบริษัทตัวแทน
ข้อเสีย 1. อาจไม่ตรงใจแก่ผู้ใช้งานในบางส่วน รวมถึงต้องปรับกระบวนการทำงาน ให้เข้ากับโปรแกรมสำเร็จรูปที่ซื้อมา 2. ต้องคัดเลือกซื้อโปรแกรมจาก ตัวแทนจำหน่ายที่มีความน่าเชื่อถือสูง
ข้อเสีย (ต่อ) 3. ค่าใช้จ่ายสูง กรณีเป็นโปรแกรม สำเร็จรูปที่ใช้งานกับระบบงานขนาดใหญ่ 4. ต้องมีการฝึกอบรมจากบริษัทตัวแทน 5. ระบบขัดข้อง ต้องพึ่งพาบริษัทเท่านั้น
การว่าจ้างบริษัทภายนอก (Outsourcing) เป็นการว่าจ้างบริษัทภายนอกเข้ามา พัฒนาระบบและดูแลระบบให้ แทนที่ จะใช้บุคลากรภายในองค์กร
การว่าจ้างบริษัทภายนอก บริษัท Outsource จะมีกลุ่มบุคลกรที่ มีความรู้ เชี่ยวชาญ และมีประสบการณ์ ด้าน IT ที่ทันสมัย สามารถพัฒนา ดูแล ระบบที่มีความซับซ้อนได้เป็นอย่างดี
ข้อดี 1. เหมาะกับองค์กรที่ไม่มีความพร้อม ด้านการพัฒนาระบบงานด้วยตนเอง 2. หน่วยงานได้ใช้ระบบงานที่มี เทคโนโลยีทันสมัย 3. มั่นใจได้ว่าจะได้ระบบตามความ ต้องการ ส่งมอบระบบตรงเวลา
ข้อดี 4. ควบคุมค่าใช้จ่ายได้ 5. ปรับปรุงระบบให้มีความทันสมัย สามารถดำเนินการได้ง่าย 6. เอกสารเกี่ยวกับระบบงาน มี ครบถ้วน เป็นระบบ และมีมาตรฐาน
ข้อเสีย 1. บริษัทเอาต์ซอร์ส์ที่มีศักยภาพสูงใน ประเทศไทย ยังคงมีน้อย 2. ทำให้ต้องสูญเสียความลับในองค์กร 3. องค์กรจำเป็นต้องพึ่งพาบริษัทเอาต์ ซอร์สเพื่อดูแลระบบให้
ข้อเสีย (ต่อ) 4. อาจได้รับแรงต่อต้านจากพนักงาน ภายในองค์กร 5. ค่าใช้จ่ายสูง
วิธีพื้นฐานการพัฒนาระบบ 1. พัฒนาแบบเฉพาะเจาะจง (Ad Hoc) เป็นวิธีพัฒนาระบบที่มุ่งเน้นเพื่อแก้ไขปัญหาเฉพาะงาน หรือแก้ไขปัญหาเฉพาะหน้าไปก่อน
วิธีพื้นฐานการพัฒนาระบบ (ต่อ) 2. พัฒนาด้วยการสร้างฐานข้อมูล (Database) มุ่งเน้นพัฒนาด้วยการสร้างฐานข้อมูลเป็นหลัก ด้วยการออกแบบเพื่อการจัดเก็บข้อมูลอย่างมีระบบ เพื่อประโยชน์ต่อการพัฒนาระบบในอนาคต
วิธีพื้นฐานการพัฒนาระบบ (ต่อ) 3. พัฒนาระบบแบบล่างขึ้นบน (Bottom-Up) เน้นพัฒนาระบบตามหน่วยงานแต่ละส่วนก่อน เช่น พัฒนาระบบย่อย ตามหน่วยงานขององค์กร จากนั้นจึงค่อยนำระบบย่อยต่าง ๆ มารวมกัน
วิธีพื้นฐานการพัฒนาระบบ (ต่อ) 4. พัฒนาระบบแบบบนลงล่าง (Top-Down) จะทำการวิเคราะห์ระบบงาน ด้วยการมองภาพรวมของระบบก่อน จากนั้น จึงค่อยดำเนินการแตกเป็นระบบย่อย
การออกแบบสถาปัตยกรรมระบบ (Architecture Design) เกี่ยวข้องกับสภาพแวดล้อมทางเทคนิคของระบบงานใหม่ ซึ่งประกอบด้วยการวางแผนเกี่ยวกับ H/W, S/W, Network และ Security เพื่อสนับสนุนระบบงานใหม่
สถาปัตยกรรมระบบ 3 รูปแบบ 1. สถาปัตยกรรมเครือข่ายแบบ Centrailzed 2. สถาปัตยกรรมเครือข่ายแบบ File Servers 3. สถาปัตยกรรมเครือข่ายแบบ Client-Server
P.247 ภาระงาน ตกอยู่ที่ Host
ภาระงาน ตกอยู่ที่ Client
การกำหนด Spec ให้กับ H/W, S/W
การจัดหาอุปกรณ์ระบบ (System Acquisition) 1. การจัดซื้อ (Purchase) 2. การเช่า (Rental) 3. การเช่าซื้อ (Lease)
การวางแผนด้านความปลอดภัยให้กับระบบ 1. ความปลอดภัยด้านภายนอก 2. การควบคุมสิทธิ์ในการเข้าถึงระบบ 3. การใช้รหัสผ่าน/การแสดงตัวตน 4. การติดตั้งโปรแกรมป้องกันไวรัส
การออกแบบฐานข้อมูล ดำเนินการแปลงแบบจำลองข้อมูลเชิงลอจิคัลที่ได้มาจากระยะการวิเคราะห์มาเป็นรายละเอียดทางเทคนิค เพื่อใช้สำหรับจัดเก็บข้อมูลจริง พิจารณา OS และ DBMS ที่ Match กับสถาปัตยกรรมระบบ
การออกแบบเอาต์พุต (Output Design)
วัตถุประสงค์ของเอาต์พุต 1. ใช้ในการติดต่อข่าวสารระหว่างกิจกรรมต่างๆ 2. ใช้รายงานเหตุการณ์ต่าง ๆ ที่เกิดขึ้นในระบบ 3. แสดงกลไกในการทำงาน 4. เป็นการยืนยันหรือรับรองว่าเกิดการทำงานจริง
หลักการพิจารณาเอาต์พุต 1. ใครเป็นผู้ใช้รายงานนี้ 2. ใช้ประโยชน์จากรายงานนี้อย่างไร 3. รายละเอียดข้อมูลในรายงานมีอะไรบ้าง 4. รายงานนี้มีความต้องการใช้บ่อยแค่ไหน 5. รายงานแสดงผลออกทางสื่อใด
การจัดรูปแบบรายงาน 1. หัวรายงาน (Heading) 2. รายละเอียด (Details) 3. ผลสรุป (Summaries) 4. หมายเหตุ (Remarks)
P. 270
ประเภทของรายงาน 1. รายงานภายใน (Internal Report)
ประเภทของรายงาน (ต่อ) 2. รายงานภายนอก (External Report) คือรายงานที่ใช้กับบุคคลหรือหน่วยงานภายนอก เช่น ลูกค้า ร้านค้า หรือหน่วยงานราชการ ดังนั้น จึงจำเป็นต้องได้รับการออกแบบที่ดี เหมาะสม และสวยงาม ซึ่งสิ่งเหล่านี้จะสะท้อนถึงภาพลักษณ์ขององค์กรด้วย
การนำเสนอข้อมูลในรายงาน 1. การนำเสนอข้อมูลในรูปแบบตาราง 2. การนำเสนอข้อมูลในรูปแบบกราฟ 3. การนำเสนอข้อมูลในรูปแบบของ ภาพ/ไอคอน
รายงานทางจอภาพ และเครื่องพิมพ์ รายงานทางจอภาพ มีข้อจำกัดมากกว่า เนื่องจากมีพื่นที่จำกัดอยู่บนหน้าจอคอมพิวเตอร์ ดังนั้น ควรออกแบบผลลัพธ์ของรายงานที่สามารถแสดงได้ทีละหน้า
รายงานทางจอภาพ และเครื่องพิมพ์ ข้อดีของรายงานทางจอภาพ ก็คือ สามารถดูผลของรายงานทางจอภาพเพื่อยืนยันในสิ่งที่ต้องการ ก่อนที่จะสั่งพิมพ์ รวมถึงการประหยัดกระดาษ ในกรณีที่ขอดูแค่ข้อมูล แต่ไม่สั่งพิมพ์
เอกสาร/รายงานทางอิเล็กทรอนิกส์ ? รายงานทางจอภาพ และเครื่องพิมพ์ แต่ทั้งนี้ รายงานบางประเภทจำเป็นต้องนำเสนอออกมาทางกระดาษ เพื่อใช้อ้างอิงและใช้เป็นหลักฐาน เอกสาร/รายงานทางอิเล็กทรอนิกส์ ? (PDF File / Scan)
ชนิดกระดาษรายงานเพื่อสำเนา 1. กระดาษคาร์บอนในตัว 2. กระดาษคาร์บอนที่แทรกไว้ระหว่างแผ่น
การออกแบบอินพุต (Input Design) พึงจำไว้ว่า! คุณภาพของข้อมูลที่อินพุตเข้าสู่ระบบ ย่อมทำให้ได้มาซึ่งคุณภาพของเอาต์พุต Garbage in! Garbage out!
วัตถุประสงค์ของการออกแบบอินพุต P.278 1. กำหนดวิธีการประมวลผล และคัด เลือกอุปกรณ์อินพุตที่เหมาะสม 2. ควบคุมปริมาณอินพุต 3. ควบคุมข้อผิดพลาดจากการป้อนข้อมูล
วัตถุประสงค์ของการออกแบบอินพุต 4. ออกแบบแหล่งข้อมูลเบื้องต้นให้อยู่ในแบบฟอร์มที่เหมาะสม
วัตถุประสงค์ของการออกแบบอินพุต 5. ออกแบบจอภาพให้ถูกต้องตามหลักการ
การออกแบบหน้าจอแบบ GUI P. 286 1. Text Box
การออกแบบหน้าจอแบบ GUI 2. Radio Button
การออกแบบหน้าจอแบบ GUI 3. Check Box
การออกแบบหน้าจอแบบ GUI 4. Combo Box
การออกแบบหน้าจอแบบ GUI 5. List Box
การออกแบบหน้าจอแบบ GUI 6. Spin Box
การออกแบบหน้าจอแบบ GUI 7. Button
(System Design: Part II) บทที่ 8 การออกแบบระบบ ตอนที่ 2 (System Design: Part II)
การออกแบบ User Interface ระบบที่ดีควรมีอินเตอร์เฟซระหว่าง ผู้ใช้งานกับระบบที่ดีด้วย ควรออกแบบการโต้ตอบให้น่าสนใจ รวมถึงใช้สื่ออุปกรณ์ที่เหมาะสมสำหรับ การใช้โต้ตอบระหว่างกัน
ชนิดของ User Interface 1. การอินเตอร์เฟสด้วยภาษาธรรมชาติ 2. การอินเตอร์เฟสด้วยคำถามและคำตอบ 3. การอินเตอร์เฟสด้วยเมนู 4. การอินเตอร์เฟสด้วยชุดคำสั่ง 5. การอินเตอร์เฟสแบบ GUI
ข้อแนะนำในการออกแบบ UI ที่ดี 1. ผู้ใช้งานต้องรู้ว่า สิ่งที่ทำอยู่นี้คืออะไร และต้องดำเนินการอย่างไรต่อไป 2. สามารถซูมดูรายละเอียดเฉพาะที่ต้องการได้ 3. ข้อมูลที่แสดง ต้องมีความยาวเพียงพอต่อการ อ่าน แล้วทำให้เกิดความเข้าใจ
ข้อแนะนำในการออกแบบ UI ที่ดี 4. การนำเสนอข้อความบนจอภาพ ควรใช้ เฉดสีที่เหมาะสม อย่างเล่นสีสรรมาก เกินไปจนดูเลอะเทอะ 5. หากโปรแกรม จำเป็นต้องกำหนดตัวแปรต่าง ๆ ให้กับสภาพแวดล้อม ดังนั้น ควรกำหนดค่า Default และสามารถปรับได้ภายหลัง
ข้อแนะนำในการออกแบบ UI ที่ดี 6. ควรมีข้อความยืนยันการกระทำ สำหรับกรณี โปรเซสที่ส่งผลต่อข้อมูล เช่น การลบข้อมูล 7. ควรเอาใจใส่ต่อข้อผิดพลาด โดยไม่อนุญาต ให้มีการประมวลผลใด ๆ จนกว่าจะทำการแก้ไข ข้อผิดพลาดในข้อมูลให้ถูกต้องเสียก่อน
ข้อแนะนำในการออกแบบ UI ที่ดี 8. หากมีผู้ใช้งาน ได้พยายามกระทำในบางสิ่ง ที่ส่งผลต่อความหายนะต่อระบบ ควรล็อก คีย์บอร์ดเพื่อมิให้สามารถป้อนข้อมูลเข้าได้
การจัดทำต้นแบบ (Prototype) เป็นการจัดทำต้นแบบผลิตภัณฑ์ เพื่อให้ผู้ใช้งานได้เห็นภาพและแนวทางของระบบใหม่ เพื่อพิจารณาว่าตรงตามความต้องการหรือไม่
การจัดทำต้นแบบ (ต่อ) การจัดทำ Prototype ทำให้ลดความเสี่ยงต่อการไม่ตอบรับในระบบ กล่าวคือ สามารถนำไปใช้เป็นข้อมูลทางเทคนิคที่ใช้ป้องกันผู้ใช้หรือลูกค้าปฏิเสธระบบงานได้ เพราะทีมงานกับผู้ใช้ได้ออกแบบร่วมกัน
ประเภทของ Prototype 1. โปรโตไทป์แบบทำแล้วโยนทิ้ง 1. โปรโตไทป์แบบทำแล้วโยนทิ้ง 2. โปรโตไทป์แบบมีพัฒนาการ ในปัจจุบันมี S/W มากมายที่สามารถนำมาใช้เป็นเครื่องมือเพื่อสร้างโปรโตไทป์
Prototyping Life Cycle
การออกแบบโปรแกรม เป้าหมายหลักของการออกแบบโปรแกรมเชิงโครงสร้าง ก็คือการสร้างโปรแกรมที่ประกอบไปด้วยฟังก์ชันของโมดูลต่าง ๆ ว่ามีความสัมพันธ์กับโมดูลอื่น ๆ ที่เกี่ยวข้องอย่างไร
การออกแบบโปรแกรม เป้าหมายหลักของการออกแบบโปรแกรมเชิงโครงสร้าง ก็คือการสร้างโปรแกรมที่ประกอบไปด้วยฟังก์ชันของโมดูลต่าง ๆ ว่ามีความสัมพันธ์กับโมดูลอื่น ๆ ที่เกี่ยวข้องอย่างไร
การออกแบบผังโครงสร้างที่ดี 1. ควรออกแบบให้แต่ละโมดูลมีความเป็น หนึ่งเดียวสูง (High Cohesion) จะทำให้ง่ายต่อการปรับปรุงโปรแกรม โมดูลที่ปฏิบัติงานเพียงงานเดียว ถือว่ามี Cohesion สูง และเรียกซ้ำเพื่อใช้งานได้ตามความต้องการ
การออกแบบผังโครงสร้างที่ดี 2. ควรออกแบบให้แต่ละโมดูล มีความ สัมพันธ์แบบหลวมๆ (Loosely Coupled) โมดูลที่ดี ควรมีความเป็นอิสระ ไม่ขึ้นต่อกัน แต่ไม่ได้หมายความว่าแต่ละโมดูลนั้นจะไม่มีความสัมพันธ์กันเลย เนื่องจากแต่ละ โมดูลจำเป็นต้องมีคอนเน็กชันระหว่างกัน
การออกแบบผังโครงสร้างที่ดี โมดูลที่มีความสัมพันธ์กับโมดูลอื่นอย่างแน่นแฟ้น (Tightly Coupled) คือโมดูลที่ภายในมีตรรกะที่อ้างอิงตรรกะบนโมดูลอื่นจำนวนมาก การปรับปรุงแก้ไขตรรกะส่วนหนึ่ง จะกระทบต่อโมดูลอื่น ๆ
สรุปกิจกรรมของระยะการออกแบบ 1. พิจารณาแนวทางการพัฒนาระบบ 2. การออกแบบสถาปัตยกรรมระบบ 3. การออกแบบฐานข้อมูล 4. การออกแบบเอาต์พุต
สรุปกิจกรรมของระยะการออกแบบ 5. การออกแบบอินพุต 6. การออกแบบ User Interface 7. การจัดทำต้นแบบ (Prototype) 8. ออกแบบโปรแกรม
(Implementation Phase and Maintenance Phase) ระยะที่ 4 และ 5 การนำไปใช้ และการบำรุงรักษา (Implementation Phase and Maintenance Phase)
การสร้างระบบ การติดตั้ง (Construction, Installation and บทที่ 9 การสร้างระบบ การติดตั้ง และการบำรุงรักษา (Construction, Installation and Maintenance)
(Implementation Phase) ระยะที่ 4: การนำไปใช้ (Implementation Phase) เป็นระยะที่ดำเนินการให้ระบบเกิดผล ขึ้นมาด้วยการสร้างระบบ ทดสอบระบบ และติดตั้งระบบ
(Implementation Phase) ระยะที่ 4: การนำไปใช้ (Implementation Phase) ลำดับกิจกรรมต่าง ๆ ทุกกิจกรรม จะต้องเข้ามาดำเนินการร่วมกันในระยะนี้ เพื่อให้ระบบสามารถปฏิบัติได้อย่างลงเอย ที่สุด
ประกอบด้วยกิจกรรมดังนี้ การทำให้ระบบเกิดผล ประกอบด้วยกิจกรรมดังนี้ 1. การเขียนโปรแกรม 2. การทดสอบโปรแกรม 3. การติดตั้งระบบ 4. การจัดทำเอกสารคู่มือการใช้งาน 5. การฝึกอบรม 6. การประเมินผลระบบ
การเขียนโปรแกรม โปรแกรมเมอร์จะเป็นผู้เขียนโปรแกรม ให้เป็นไปตามมาตรฐานที่นักวิเคราะห์ ระบบได้กำหนดไว้
ขั้นตอนการเขียนโปรแกรม 1. ศึกษาจากเอกสาร 2. ออกแบบโปรแกรม 3. เขียนโปรแกรม 4. ทดสอบโปรแกรม 5. จัดทำเอกสารประกอบโปรแกรม
การทดสอบ (Testing) เป็นการทดสอบโปรแกรมที่ใช้งานใน ระบบว่าสามารถทำงานได้อย่างถูกต้อง หรือไม่ ก่อนที่จะดำเนินการติดตั้งระบบ เพื่อใช้งานจริงต่อไป
การทดสอบ (Testing) อาจมีการจำลองสถานการณ์ขึ้นมา เพื่อให้เกิดเหตุการณ์และมีการบันทึกข้อมูล เข้าสู่ระบบ การทดสอบระบบ จะมีการรับประกัน ถึงความถูกต้องทั้งในส่วน Verification และ Validation
เทคนิคการทดสอบ 1. Black Box Testing
เทคนิคการทดสอบ (ต่อ) 2. White Box Testing
ขั้นตอนการทดสอบ 1. การทดสอบหน่วยย่อย (Unit Testing) มุ่งเน้นการตรวจสอบความถูกต้องและ ข้อผิดพลาดที่เกิดขึ้นภายในโมดูล ซึ่งโดยปกติ โปรแกรมเมอร์จะดำเนินการทดสอบโค้ด โปรแกรมในระหว่างการพัฒนา จนกระทั่ง เชื่อว่าไม่พบข้อผิดพลาด
ขั้นตอนการทดสอบ (ต่อ) 2. การทดสอบด้วยการนำโปรแกรมมา ประกอบรวมกัน (Integration Testing) คือการทดสอบด้วยการนำกลุ่มโปรแกรม ต่าง ๆ มาประกอบรวมกัน และต้องมั่นใจว่าการ เชื่อมโยงและส่งผ่านข้อมูลไปมาระหว่างโมดูล จะต้องทำงานได้อย่างถูกต้องและครบถ้วน
ขั้นตอนการทดสอบ (ต่อ) 3. การทดสอบทั้งระบบ (System Testing) คือการทดสอบระบบทั้งหมด ก่อนที่จะ ส่งมอบแก่ลูกค้าหรือผู้ว่าจ้าง โดยจะทดสอบ ทั้งฟังก์ชันการทำงาน และทดสอบ ประสิทธิภาพของระบบ
ขั้นตอนการทดสอบ (ต่อ) 4. การทดสอบการยอมรับในระบบ (Acceptance Testing) เป็นขั้นตอนสุดท้ายของการทดสอบ เพื่อ ยืนยันถึงความสมบูรณ์ของระบบว่าสามารถ รองรับการกระบวนการทางธุรกิจได้ตรงตาม ความต้องการ ถูกต้อง และครบถ้วนหรือไม่
ขั้นตอนการทดสอบ (ต่อ) การทดสอบการยอมรับในระบบ ประกอบด้วย 2 ขั้นตอนด้วยกันคือ 1. Alpha Testing 2. Beta Testing
การติดตั้งระบบ (Installation) หลังจากระบบใหม่ได้พัฒนาขึ้น และผ่านการทดสอบเป็นที่เรียบร้อยแล้ว ขั้นตอนต่อไปก็คือ การติดตั้ง ซึ่งมีอยู่ 4 วิธีด้วยกัน
การติดตั้งระบบ (Installation) 1. การติดตั้งเพื่อใช้งานใหม่ทันที 2. การติดตั้งแบบคู่ขนาน 3. การติดตั้งแบบทีละระยะ 4. การติดตั้งแบบโครงการนำร่อง
การติดตั้งเพื่อใช้งานใหม่ทันที (Direct Installation) เป็นวิธีการติดตั้งด้วยการหยุดใช้งาน ระบบเดิม และเปลี่ยนมาใช้ระบบใหม่โดย ทันที
ข้อดี 1. ระบบใหม่สามารถดำเนินการได้ทันที 2. สถานการณ์บังคับให้ผู้ใช้งานต้องใช้ งานระบบใหม่ 3. ง่ายต่อการวางแผน 4. ค่าใช้จ่ายต่ำ ใช้เวลาน้อย
ข้อเสีย 1. อาจเกิดข้อผิดพลาดที่คาดไม่ถึงใน ขณะที่ใช้ระบบใหม่ 2. เป็นวิธีที่มีความเสี่ยงสูงที่สุด
การติดตั้งแบบคู่ขนาน (Parallel Installation) เป็นวิธีการติดตั้งที่มีการปฏิบัติงานทั้ง ระบบเดิมกับระบบใหม่คู่ขนานกันไป โดย จะยกเลิกระบบเดิมต่อเมื่อการดำเนินงาน ของระบบใหม่ไม่มีข้อผิดพลาดใดๆ
ข้อดี 1. มีความปลอดภัยสูง 2. สามารถเปรียบเทียบกระบวนการ ทำงานระหว่างระบบเดิมกับระบบใหม่
ข้อเสีย 1. ใช้ต้นทุนสูง 2. สิ้นเปลืองเวลา เพราะทำงานทั้ง 2 ระบบ 3. ผู้ใช้งานอาจมีทัศนคติที่ไม่ต่อระบบ ใหม่ หากระบบใหม่มีข้อผิดพลาดสูง 4. ยากต่อการวางแผน และการควบคุม
การติดตั้งแบบทีละเฟส (Phased Installation) เป็นวิธีการติดตั้งที่มีการกำหนดเป็น ระยะๆ แต่ละระยะจะมีการเพิ่มฟังก์ชันการ ทำงานของระบบ เช่น การติดตั้งระบบทีละ ระบบย่อย
ข้อดี 1. กรณีว่าจ้างพัฒนา เจ้าของระบบ 1. กรณีว่าจ้างพัฒนา เจ้าของระบบ สามารถชำระเงินค่าระบบเฉพาะระยะนั้นๆ 2. หากเกิดข้อผิดพลาด จะไม่ส่งผลกระทบ ต่อระบบโดยรวม ทำให้ลดความเสี่ยง 3. เหมาะกับระบบงานขนาดใหญ่ที่มี ความซับซ้อนสูง
ข้อเสีย 1. อาจใช้เวลามากเกินไปกับบาง ระบบงาน ซึ่งส่งผลกระทบต่อการ รอพัฒนาในเฟสต่อไป 2. ไม่เหมาะกับระบบงานที่ไม่สามารถ แบ่งระบบออกเป็นส่วนย่อยๆ ได้
การติดตั้งแบบโครงการนำร่อง (Pilot Project) เป็นวิธีการติดตั้งที่คล้ายกับวิธีการติดตั้ง แบบทีละเฟส โดยจะดำเนินการติดตั้ง ระบบเฉพาะส่วนงานใดส่วนงานหนึ่งก่อน เช่น ติดตั้งทีละแผนก
ข้อดี ข้อเสีย 1. ลดความเสี่ยงได้ดี 2. ค่าใช้จ่ายต่ำ 1. เหมาะกับระบบที่มีความสมบูรณ์ใน ตัวเอง ที่ไม่เกี่ยวข้องกับระบบงานอื่นๆ
การจัดทำเอกสารคู่มือใช้งาน 1. เอกสารคู่มือสำหรับผู้ใช้ (User Documentation) เป็นเอกสารคู่มือที่ช่วยให้ผู้ใช้ปฏิบัติงานกับระบบ โดยมุ่งหวังว่า เมื่อผู้ใช้อ่านแล้ว สามารถปฏิบัติตามขั้นตอนเพื่อทำงานได้
การจัดทำเอกสารคู่มือใช้งาน 2. เอกสารคู่มือระบบ (System Documentation) เป็นเอกสารที่ช่วยให้ผู้ปฏิบัติการหรือโอเปอเรเตอร์ได้เข้าใจเกี่ยวกับการจัดการกับระบบอย่างไรเมื่อระบบขัดข้อง ซึ่งรวมถึงวิธีการอัปเกรด และวิธีการบำรุงรักษาระบบที่ถูกต้อง
การฝึกอบรม (Training) ตามปกติแล้ว จะมีบุคคลอยู่ 2 กลุ่มด้วยกันที่ใช้งานระบบ คือ ผู้ใช้ (Users) และ ผู้ปฏิบัติการ (Operator)
User Operator
ชนิดของการฝึกอบรม 1. การฝึกอบรมผู้ใช้ 1. การฝึกอบรมผู้ใช้ จะตั้งอยู่บนพื้นฐานการทำงานของระบบ 2. การฝึกอบรมผู้ปฏิบัติการ มุ่งสนใจถึงหน้าที่การสนับสนุนระบบเป็นหลัก
วิธีการฝึกอบรม 1. การฝึกอบรมโดยใช้วิทยากร 2. การฝึกอบรมด้วยตนเอง
การประเมินผลระบบ จุดประสงค์หลักก็คือ ต้องการ ประเมินผลระบบว่า ระบบใหม่ที่ติดตั้งและ ใช้งานนั้น เป็นไปตามวัตถุประสงค์ของผู้ใช้ หรือไม่ มีข้อบกพร่องใดที่ต้องนำไป ปรับปรุงต่อไป
การประเมินผลระบบ (ต่อ) ช่วงเวลาที่เหมาะสมของการ ประเมินผลระบบ คือ ควรดำเนินการ ภายหลังการ ติดตั้งใช้งานไปแล้วประมาณ 6 - 9 เดือน ซึ่งสามารถใช้แบบสอบถามเพื่อ ประเมินความพึงพอใจ
ระยะที่ 5: การบำรุงรักษา (Maintenance Phase) หลังจากที่ระบบงานได้ติดตั้งและใช้ งานจริงในระยะเวลาหนึ่ง ผู้ใช้งานอาจพบ ปัญหาที่เกิดขึ้น หรืออาจมีความต้องการ เพิ่มเติมใหม่ๆ ได้
ประกอบด้วยกิจกรรมดังนี้ การบำรุงรักษา ประกอบด้วยกิจกรรมดังนี้ 1. การบำรุงรักษาระบบ 2. การเพิ่มเติมคุณสมบัติใหม่ๆ เข้าไปในระบบ 3. การสนับสนุนงานของผู้ใช้
ชนิดของการบำรุงรักษา 1. การบำรุงรักษาด้วยการแก้ไขให้ ถูกต้อง (Corrective Maintenance) 2. การบำรุงรักษาด้วยการปรับระบบให้ รองรับสภาพแวดล้อมที่เปลี่ยนแปลง ไป (Adaptive Maintenance)
วิธีการบำรุงรักษา 3. การบำรุงรักษาด้วยการปรับปรุงระบบ ให้มีประสิทธิภาพยิ่งขึ้น (Perfective Maintenance) 4. การบำรุงรักษาเชิงป้องกัน (Preventive Maintenance)