การพัฒนาระบบงานสารสนเทศ

1. วงจรชีวิตของการพัฒนาระบบงานสารสนเทศ (System Development Life Cycle)
การพัฒนาระบบงานสารสนเทศ โดยทั่วไป จะดำเนินตามขั้นตอนต่างๆ ที่กำหนดไว้ใน System Development Life Cycle (SDLC) แต่เนื่องจาก SDLC มีอยู่ด้วยกันหลายแนวทาง ดังนั้น จำนวนและรายละเอียดของขั้นตอนต่างๆ จึงแตกต่างกันไปตามแนวทางของ SDLC ที่จะเลือกใช้ ขั้นตอนของ SDLC ซึ่งประกอบด้วยขั้นตอนต่างๆ ดังนี้
1.1 Feasibility Study เป็นขั้นตอนที่เกี่ยวข้องกับการประเมินต้นทุนของทางเลือกต่างๆ ในการพัฒนาระบบงานสารสนเทศ เพื่อพิจารณาเลือกในการพัฒนาระบบงานสารสนเทศที่มีความคุ้มค่ามากที่สุด
1.2 Requirement Collection and Analysis ในขั้นตอนนี้ จะเป็นการเก็บรวบรวมความต้องการต่างๆ จากผู้ใช้ (User’s Requirement) มาวิเคราะห์ เพื่อจำแนกถึงปัญหาและความต้องการออกเป็นกลุ่ม ซึ่งจะใช้กำหนดขอบเขตให้กับระบบงานสารสนเทศที่จะพัฒนาขึ้น
1.3 Design ในขั้นตอนนี้ นักพัฒนาระบบงานสารสนเทศจะนำเอาปัญหาและความต้องการทางด้านต่างๆ มาใช้ในการออกแบบระบบงานสารสนเทศ ซึ่งแบ่งเป็น 2 ส่วนคือ การออกแบบในส่วนของโปรแกรม (Application Design) และการออกแบบในส่วนของฐานข้อมูล (Database Design) โดยที่การออกแบบใน 2 ส่วนนี้จะทำพร้อมกัน
1.4 Prototyping ในขั้นตอนนี้ ส่วนต่างๆ ที่ได้ออกแบบไว้ จะถูกนำมาพัฒนาต้นแบบของระบบงาน (Prototype) ซึ่งในปัจจุบัน จะมี Tool จำนวนมากที่ช่วยในการพัฒนา เพื่อนำต้นแบบนี้ไปใช้ตรวจสอบความถูกต้องของระบบงาน ก่อนนำไปใช้งานจริง ซึ่งถ้ามีข้อผิดพลาดเกิดขึ้น ก็สามารถนำไปเป็นข้อมูลสำหรับขั้นตอน Requirement Collection and Analysis ได้ใหม่
1.5 Implementation เป็นขั้นตอนที่นำเอาระบบงานสารสนเทศที่พัฒนาเสร็จเรียบร้อยบไปทดลองใช้งาน
1.6 Validation และ Testing เป็นขั้นตอนการตรวจสอบความถูกต้องของระบบงานสารสนเทศที่พัฒนาขึ้น
1.7 Operation เป็นขั้นตอนสุดท้าย ซึ่งแน่ใจแล้วว่า ระบบงานสารสนเทศที่พัฒนาขึ้น สามารถทำงานได้อย่างถูกต้อง จึงเริ่มนำข้อมูลต่างๆ มาใช้งานจริง

สำหรับทั้ง 7 ขั้นตอนนี้ สามารถแสดงด้วยแผนภาพได้ ดังรูป

การทำงานในแต่ละขั้นตอนขอการพัฒนาระบบงานสารสนเทศ จะไม่ได้แยกออกจากกันอย่างชัดเจน แต่ผลของการทำงานในขั้นตอนหนึ่ง สามารถส่งผลต่อการทำงานในขั้นตอนที่ผ่านมาได้

2. วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle)
วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle) หรือที่เรียกอย่างย่อว่า DBLC เป็นขั้นตอนที่กำหนดขึ้น เพื่อใช้เป็นแนวทางในการพัฒนาระบบฐานข้อมูลขึ้นใช้งาน ซึ่งประกอบด้วยขั้นตอนต่างๆ ดังนี้
2.1 Database Initial Study เป็นขั้นตอนแรกของการพัฒนาระบบฐานข้อมูลขึ้นใช้งาน ในขั้นตอนนี้ จะต้องวิเคราะห์ความต้องการต่างๆ ของผู้ใช้ เพื่อกำหนดจุดมุ่งหมาย ปัญหา ขอบเขต และกฎระเบียบต่างๆ ของระบบฐานข้อมูลที่จะพัฒนาขึ้น เพื่อใช้เป็นแนวทางในการออกแบบฐานข้อมูลในขึ้นตอนต่อไป
2.2 Database Design ในขั้นตอนนี้ จะนำเอารายละเอียดต่างๆ ที่ได้จากการวิเคราะห์ในขั้นตอนแรก มาใช้เป็นแนวทางในการออกแบบฐานข้อมูลขึ้นใช้งาน สำหรับแนวทางที่นิยมใช้ในการออกแบบฐานข้อมูลได้แก่ แนวทางแบบ Data-driven และแนวทางแบบ Joint data and Function-driven
2.3 Implementation and Loading ขั้นตอนนี้เป็นขั้นตอนที่นำเอาโครงร่างต่างๆ ของระบบฐานข้อมูลที่ได้จากการออกแบบในขั้นตอน Database Design มาสร้างตัวฐานข้อมูลที่จะใช้เก็บข้อมูลจริง รวมทั้งทำการแปลงข้อมูลของระบบงานเดิม ให้สามารถนำมาใช้งานในระบบฐานข้อมูลที่พัฒนาขึ้นใหม่ ในกรณีที่ระบบเดิมมีการใช้คอมพิวเตอร์ในการประมวลผล
2.4 Testing and Evaluation เป็นขั้นตอนของการทดสอบระบบฐานข้อมูลที่พัฒนาขึ้น เพื่อหาข้อผิดพลาดต่างๆ รวมทั้งทำการประเมินความสามารถของระบบฐานข้อมูลนั้น เพื่อนำไปใช้เป็นแวทางในการปรับปรุงให้ระบบฐานข้อมูลที่พัฒนาขึ้นนั้น สามารถรองรับความต้องการของผู้ใช้ในด้านต่างๆ ได้อย่างถูกต้อง และครบถ้วน
2.5 Operation เป็นขั้นตอนที่นำเอาระบบฐานข้อมูลที่พัฒนาขึ้นเสร็จเรียบร้อยแล้ว ไปใช้งานจริง
2.6 Maintenance and Evolution เป็นขั้นตอนที่เกิดขึ้นระหว่างการใช้งานระบบฐานข้อมูลจริง เพื่อบำรุงรักษาให้ระบบฐานข้อมูลทำงานได้อย่างมีประสิทธิภาพ รวมทั้งเป็นขั้นตอนของการแก้ไข และปรับปรุงระบบฐานข้อมูล ในกรณีที่มีการเพิ่ม หรือเปลี่ยนแปลงความต้องการของผู้ใช้ ที่ส่งผลกระทบต่อระบบฐานข้อมูล

ซึ่งทั้ง 6 ขั้นตอนนี้ สามารถแสดงด้วยแผนภาพได้ดังนี้

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

3 ความต้องการของผู้ใช้ (User’s Requirement)
ขั้นตอนในการวิเคราะห์ความต้องการของผู้ใช้ โดยปกติจะมีรายละเอียดค่อนข้างมาก จึงมีความจำเป็น ที่จะต้องแบ่งความต้องการของผู้ใช้ออกเป็น 2 กลุ่ม
3.1 ความต้องการทางด้านโปรแกรม (Application Requirement) ได้แก่ความต้องการของผู้ใช้ด้านต่างๆ ที่เกี่ยวข้องกับการทำงานของระบบงาน ทั้งเป็นของระบบงานปัจจุบัน และของระบบงานสารสนเทศที่ต้องการพัฒนาขึ้น เช่น ขั้นตอนการทำงานของระบบงานปัจจุบัน รายละเอียดของแต่ละขั้นตอนของการทำงาน ความสามารถ ที่ผู้ใช้ต้องการให้ปรากฏอยู่ในแต่ละขั้นตอนการทำงานของระบบงานใหม่ ฯลฯ
3.2 ความต้องการทางด้านข้อมูล (Data Requirement) ได้แก่ ความต้องการของผู้ใช้ด้านที่เกี่ยวข้องกับตัวข้อมูลของระบบงาน ซึ่งจะแฝงอยู่ในรายละเอียดของขั้นตอนการทำงานต่างๆ เช่น ขั้นตอนในการจ่ายเงินเดือนให้แก่พนักงาน จะใช้สลิปเงินเดือนเพื่อแจ้งรายได้ให้แก่พนักงานแต่ละคนทราบ ซึ่งภายในสลิปเงินเดือน ประกอบด้วย รหัสพนักงาน ซื่อสกุล เดือน ประเภทรายได้ จำนวนเงินตามแต่ละประเภทรายได้ จำนวนเงินประกันสังคมที่หัก จำนวนเงินภาษีที่หัก ฯลฯ เป็นต้น ซึ่งความต้องการทางด้านข้อมูลของตัวอย่างนี้ ก็คือรายละเอียดของข้อมูลต่างๆ ที่ปรากฏอยู่ในสลิปเงินเดือน

4. Data-driven Approach
ดังที่กล่าวมาแล้วว่า ขั้นตอนการออกแบบระบบงานสารสนเทศของ SDLC จะแบ่งการออกแบบเป็น 2 ส่วน คือ การออแบบในส่วนของโปรแกรม และการออกแบบในส่วนของฐานข้อมูล ซึ่งทั้ง 2 ส่วนนี้จะอยู่หลายแนวทางด้วยกัน ที่สามารถนำมาใช้กำหนดขั้นตอนและวิธีการในการออกแบบได้ แต่สำหรับแนวทางหนึ่งที่นิยมนำมาใช้ในการออกแบบฐานข้อมูล ได้แก่ แนวทาง Data-driven ซึ่งเป็นแนวทางที่ให้ความสำคัญกับตัวข้อมูลมากกว่าตัวโปรแกรม คือ ทำการออกแบบตัวข้อมูลจนมีความสมบูรณ์ก่อนที่จะทำการออกแบบตัวโปรแกรมเป็นลำดับต่อไป ซึ่งจะแบ่งออกเป็น 3 ขั้นตอนดังนี้
4.1 Conceptual Design เป็นขั้นตอนที่นำเอาความต้องการทางด้านข้อมูล (Data Requirement) มาวิเคราะห์ และใช้ออกแบบฐานข้อมูล โดยมีจุดมุ่งหมายเพื่ออธิบายโครงสร้างหลักๆ ของฐานข้อมูล โดยไม่สนใจว่าจะใช้โครงสร้างข้อมูล หน่วยสำรองข้อมูล และตัว DBMS ใด
4.2 Logical Design ขั้นตอนนี้จะนำเอา Conceptual Schema มาแปลงให้อยู่ในรูปแบบที่ถูกกำหนดโดย Database Model ที่เลือกใช้ ซึ่งอาจเป็น Hierarchical, Relational, Object-Oriented หรือ Network Model โดยไม่สนใจตัว DBMS ใด
4.3 Physical Design ขั้นตอนนี้จะนำเอา Logical Schema มาแปลงให้อยู่ในรูปแบบที่ถูกกำหนดโดย DBMS ซึ่งจะกำหนดถึงโครงสร้างในการจัดเก็บ และวิธีในการเข้าถึงข้อมูล

ซึ่งทั้ง 3 ขั้นตอนนี้ สามารถแสดงด้วยแผนภาพได้ดังนี้

5 Function-Driven Approach
เป็นแนวทางหนึ่งที่นิยมนำมาใช้ในการออกแบบส่วนของโปรแกรม (Application Design) ซึ่งเป็นแนวทางที่ต่างจากแนวทางแบบ Data-Driven คือ แนวทางแบบ Function-Driven จะให้ความสำคัญกับตัวโปรแกรมมากกว่าตัวข้อมูล โดยแบ่งออกเป็น 3 ขั้นตอนดังนี้
5.1 Function Analysis เป็นการนำเอาความต้องการต่างๆ ที่เกี่ยวข้องกับการประมวลผลมาวิเคราะห์ เพื่อกำหนดถึงขั้นตอนการทำงานและข้อมูลต่างๆ ที่จำเป็น ผลลัพธ์ที่ได้จากขั้นตอนนี้ ได้แก่ Function Schema ซึ่งจะอธิบายถึงขั้นตอนการประมวลผล และการไหลของข้อมูลระหว่างแต่ละขั้นตอนการประมวลผลนั้น
5.2 High-level Application Design เป็นการนำเอา Function Schema มาเขียนให้อยู่ในรูปของ Application Specification ซึ่งแสดงถึงพฤติกรรมของแต่ละฟังก์ชันการทำงาน รวมทั้งการเข้าถึงข้อมูลของแต่ละฟังก์ชันการทำงานนั้น
5.3 Application Program Design จะเป็นการนำเอา Application Specification มาขยายความ เพื่อกำหนดรายละเอียดในรูปของโปรแกรม ซึ่งจะนำไปพัฒนาโปรแกรมต่อไป

ซึ่งทั้ง 3 ขั้นตอนนี้ สามารถแสดงด้วยแผนภาพได้ดังรูป
6. Joint data- and Function – driven Approach
การทำงานแบบ Function –driven และ Data –driven จะมีความแตกต่างกัน แต่ในแง่ความเป็นจริงแล้ว เมื่อนำทั้ง 2 แนวทางนี้ไปใช้ในการออกแบบระบบงานสารสนเทศ ทั้ง 2 แนวทางกลับมีความสัมพันธ์ซึ่งกันและกัน และสามารถทำงานไปพร้อมๆ กันได้ ซึ่งส่งผลให้ผู้ออกแบบสามารถนำผลลัพธ์ที่ได้จากแต่ละขั้นตอนของทั้ง 2 แนวทาง มาใช้ตรวจสอบซึ่งกันและกัน คือ สามารถตรวจสอบความสมบูรณ์ของข้อมูลว่ามีความครบถ้วนตามความต้องการที่แต่ละฟังก์ชันการทำงานต้องการหรือไม่ และในขณะเดียวกันก็สามารถใช้ข้อมูลตรวจสอบว่า ฟังก์ชั่นการทำงานที่ออกแบบมีจำนวนครบถ้วนตามข้อมูลหรือไม่ได้เช่นเดียวกัน สำหรับการนำเอาทั้ง 2 แนวทาง มาใช้ร่วมกันในการออกแบบระบบสารสนเทศ จะเรียกแนวทางนี้ว่า แนวทางแบบ Joint Data- and Function-driven ซึ่งสามารถแสดงด้วยภาพได้ดังนี้
7. Data Model และ Functional Model
ในการนำเสนอผลที่ได้จากการออกแบบทั้งแนวทางแบบ Function-driven และ Data-driven จะใช้แบบจำลองในการนำเสนอเช่นเดียวกัน เนื่องจากแบบจำลองเป็นเครื่องมือใช้รูปภาพและคำอธิบายต่างๆ เพื่อใช้แสดงข้อเท็จจริงของข้อมูล รวมทั้งการกระทำต่างๆ ที่จะเกิดขึ้นกับข้อมูลนั้นๆ ในระดับแนวความคิดรูปภาพที่ใช้แทนข้อมูล
สำหรับแบบจำลองที่ใช้แนวทางของ Function-driven จะเรียกว่า “Functional Model” จะเป็นแบบจำลองแสดงถึงความสัมพันธ์ระหว่างข้อมูล และฟังก์ชันการทำง่านต่างๆ ภายในระบบ สำหรับแบบจำลองที่ใช้แนวทางของ Data-driven จะเรียกว่า “Data Model” จะเป็นการแสดงความสัมพันธ์ระหว่างข้อมูลต่างๆ ภายในระบบ ซึ่งมีอยู่ด้วยกันหลายแบบ
1.8 Abstraction ที่ใช้ใน Data Model
Abstraction เป็นกระบวนการทางความคิดในการอธิบายถึงคุณลักษณะเฉพาะของสิ่งใดสิ่งหนึ่งที่เราให้ความสนใจ เช่น เมื่อเรากล่าวถึงจักรยานในแนวคิดของ Abstraction เราจะมองจักรยานในแง่ของคุณลักษณะเฉพาะของจักรยานว่าประกอบไปด้วย โซ่ เบรค อาน บันไดถีบ ฯลฯ
Abstraction ที่ใช้ใน Data Model มี 3 ประเภท คือ Classification, Aggregation และ Generalization
1.8.1 Classification Abstraction
เป็นการจัดกลุ่มของสิ่งที่สนใจตามคุณสมบัติที่มีร่วมกัน ซึ่งกลุ่มที่จัดขึ้นนี้จะเรียกว่า Class เช่น Class "เดือน" จะประกอบด้วยสมาชิกซึ่งได้แก่เดือนต่างๆ ในรอบปี เช่น "มกราคม" "กุมภาพันธ์" " มีนาคม"...."ธันวาคม" หรือ Class "ชื่อพนักงาน" จะประกอบด้วยสมาชิกได้แก่ชื่อของพนักงานภายในบริษัท เช่น "สมบัติ" "ชาญวิทย์" "จำลอง" เป็นต้น
1.8.2 Aggregation Abstraction
เป็นการจัด Class ขึ้นใหม่จาก Class เดิม โดยที่ Class เดิม จะถูกนำมาใช้เป็นส่วนประกอบของ Class ใหม่ เช่น Class "พนักงาน" เป็น Class ใหม่ที่เกิดจาก Class เดิม ดังนี้
- Class "ชือพนักงาน" ประกอบด้วย "สมบัติ" "ชาญวิทย์" "จำลอง"
- Class "เพศ" ประกอบด้วย "ชาย" "หญิง"
- Class "ตำแหน่ง" ประกอบด้วย "ผู้จัดการ" "พนักงานธุรการ" "เจ้าหน้าที่เทคนิค"
1.8.3 Generalizatioon Abstraction
เป็นการนำเอา Class ที่มีความสัมพันธ์กันมาจัดเป็นกลุ่มของ Class ขึ้นมาใหม่ ซึ่งจะเรียก Class ที่จัดขึ้นใหม่นี้ว่า "Superset" ส่วน "Class" เดิมที่นำมารวมกันจะเรียกว่า "Subset" เช่น Class "รถยนต์" เกิดจาก Class "รถบรรทุก" "รถเก๋ง "รถแทรคเตอร์" มารวมกัน หรือ Class "พนักงาน" เกิดจาก Class "พนักงานชาย" หรือ "พนักงานหญิง"
1.9 ประเภทของความสัมพันธ์ภายใต้ Abstraction แบบ Aggregation
ความสัมพันธ์ระหว่าง Minimal และ Maximal Cardinality นี้สามารถนำมาจัด Abstraction แบบ Aggregation ออกเป็นประเภทต่างๆ ได้ดังนี้
1. One-to-One สมาชิกของ Class "B" และ "C" จะมีความสัมพันธ์กันภายใต้ Abstraction แบบ Aggregation "A" ในแบบ One-to-One ได้ก็ต่อเมื่อ Max-Card (B,A) และ max-card(C,A) มีค่าเท่ากับ 1
2. One-to-Many สมาชิกของ Class "B" และ "C" จะมีความสัมพันธ์กันภายใต้ Abstraction แบบ Aggregation "A" ในแบบ One-to-Many ได้ก็ต่อเมื่อ max-card(B,A) มีค่าเท่ากับ n และ max-card(C,A) มีค่าเท่ากับ 1
3. Many-to-One สมาชิกของ Class "B" และ "C" จะมีความสัมพันธ์กันภายใต้ Abstraction แบบ Aggregation "A" ในแบบ Many-to-One ได้ก็ต่อเมื่อ max-card(B,A) มีค่าเท่ากับ 1 และ max-card(C,A) มีค่าเท่ากับ n
4. Many-to-Many สมาชิกของ Class "B" และ "C" จะมีความสัมพันธ์กันภายใต้ Abstraction แบบ Aggregation "A" ในแบบ Many-to-Many ได้ก็ต่อเมื่อ Max-card(B,A) มีค่าเท่ากับ m และ max-card(C,A) มีค่าเท่ากับ n (สำหรับการกำหนดให้เป็นค่า m ก็เพื่อแสดงให้เห็นว่า Maximal Cardinality ของ Class "B" และ "C" ไม่จำเป็นที่จะต้องมีจำนวนที่เท่ากัน)