การพัฒนาระบบห้องสมุดอัตโนมัติ : รูปแบบ ทิศทาง

1. การพัฒนาระบบห้องสมุดอัตโนมัติ: รูปแบบ ทิศทาง ทรงฤทธิ์ มณีวงศ์วัฒนา ภาควิชาวิศวกรรมคอมพิวเตอร์ มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าธนบุรี

2. ความเป็นมา • สำนักหอสมุดของมหาวิทยาลัยได้จัดซื้อ software สำหรับจัดการห้องสมุดอัตโนมัติ ระบบ Innopac เมื่อปี 2538 และได้ใช้ต่อเนื่องมาตลอด • ระบบ Innopac แบ่งเป็น module ในแต่ละ module สามารถแบ่งย่อยๆ อีกหลายส่วน • Module หลักๆ ประกอบด้วย cataloguing, circulation, OPAC, acquisitions, serial control • ส่วนย่อยๆ ใน module หลัก เช่น advanced search (AltaVista), URL checker, Telephone Renewal เป็นต้น • ค่า license จะขึ้นอยู่กับส่วนต่างๆ ที่ทางห้องสมุดเลือกซื้อ

3. ระบบ Innopac โดยย่อ • พัฒนาโดย Innovative Interfaces Inc. โดยมีการพัฒนาปรับปรุงต่อเนื่องมานาน • มีการปรับปรุงครั้งใหญ่ จาก text-based system เป็น GUI ในส่วนของเจ้าหน้าที่ผู้ใช้งาน โดยเปลี่ยนชื่อเป็น Millennium • ในบางส่วนยังเปลี่ยนแปลงเป็น GUI ไม่สมบูรณ์ โดยทาง III ทำการปรับปรุงอย่างต่อเนื่อง: Release 2002, Silver, 2005, etc. • ข้อดี: ใช้กันอย่างกว้างขวาง, เสถียร, feature ค่อนข้างครบ, กลุ่มผู้ใช้ขนาดใหญ่, มีการดูแลโดย III • ข้อเสีย: แพง, แก้ไขเองไม่ได้, ต้องเสียค่าบำรุงทุกปี

4. สาเหตุของการเริ่มพัฒนาสาเหตุของการเริ่มพัฒนา • ค่า upgrade version ให้เป็น Millennium สูงมาก • ระบบ Innopac มีข้อจำกัดในการเชื่อมต่อกับระบบอื่นในมหาวิทยาลัย • ผู้ใช้ต้องการคุณลักษณะบางประการที่ไม่มีอยู่ในระบบ Innopac • ทางมหาวิทยาลัยให้ภาควิชาวิศวกรรมคอมพิวเตอร์เป็นผู้พัฒนาระบบใหม่ให้สำนักหอสมุด เมื่อปี 2547

5. การสนับสนุนจาก สกอ. • สำนักงานบริหารเทคโนโลยีสารสนเทศเพื่อพัฒนาการศึกษา สกอ. ต้องการให้มีการพัฒนาระบบการจัดการห้องสมุดอัตโนมัติขึ้นมา โดยได้ร่วมกับ 3 มหาวิทยาลัยที่ได้มีการพัฒนาระบบห้องสมุดอัตโนมัติ • มหาวิทยาลัยสงขลานครินทร์ • มหาวิทยาลัยวลัยลักษณ์ • มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าธนบุรี (มจธ.) • นอกจากนั้น สกอ. ได้สนับสนุน มหาวิทยาลัยเกษตรศาสตร์ ในการศึกษาความเป็นไปได้ในการพัฒนาระบบเพิ่มเติมจากระบบห้องสมุดอัตโนมัติซึ่งเป็น Opensource

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

7. ข้อดีของการที่มีการพัฒนาระบบมากกว่าหนึ่งระบบข้อดีของการที่มีการพัฒนาระบบมากกว่าหนึ่งระบบ • เพื่อเป็นทางเลือกให้กับผู้ใช้ • จากพื้นฐานการใช้งาน software ห้องสมุดของผู้พัฒนา มีการใช้ software ที่แตกต่างกันไป (Dynix, VTLS, Innopac) ทำให้ได้ 3 ระบบที่หลากหลาย • รูปแบบการดำเนินงานด้านห้องสมุดที่แตกต่าง ระหว่างกลุ่มผู้พัฒนา เช่น การมีวิทยาเขต ห้องสมุดสาขา ที่มีความต้องการในการจัดการห้องสมุดที่แตกต่าง • ทำให้เกิดการแข่งขันแบบสร้างสรรค์ เพื่อให้พัฒนาระบบได้ดีขึ้น • มีการประสานงานกัน และทำให้เกิดมาตรฐานการเชื่อมต่อ

8. ข้อเสียของการพัฒนาระบบฯ เอง • เสียค่าใช้จ่ายในการพัฒนา • ระบบที่พัฒนาเสร็จอาจจะมีความไม่เสถียรในช่วงแรก ซึ่งต้องใช้เวลาปรับปรุงต่อไป • คุณลักษณะของระบบจะยังไม่ครบถ้วน แต่จะเน้นส่วนที่จำเป็นในการใช้งานก่อน

9. แนวทางในการพัฒนาและดูแลระบบห้องสมุดอัตโนมัติแนวทางในการพัฒนาและดูแลระบบห้องสมุดอัตโนมัติ ผู้ใช้ระบบ ผู้พัฒนาระบบ เก็บข้อมูลด้านความต้องการ ออกแบบ พัฒนา ทดสอบระบบ ระบบห้องสมุด ทดสอบระบบห้องสมุด ใช้ระบบห้องสมุด แก้ไข ปรับปรุง

10. สถานะของการพัฒนาระบบฯ ของ มจธ • แบ่งออกเป็น การพัฒนาสำหรับใช้ภายใน มจธ และการพัฒนาให้มหาวิทยาลัยในประเทศ • Requirements แตกต่างกัน • ระบบ hardware และ software ที่ใช้อาจแตกต่างกัน • หลายๆ ส่วนสามารถใช้ code ร่วมกันได้ • สถานะของการพัฒนาระบบภายใน • พัฒนา OPAC เสร็จ, กำลังพัฒนา cataloguing • สถานะของการพัฒนาระบบในกับมหาวิทยาลัยอื่นๆ • ตรวจสอบความพร้อมของ resource และความต้องการอื่นๆ ที่อยู่นอกเหนือจากระบบภายใน

11. Platform ของระบบที่พัฒนา สำหรับ มจธ. • OPAC: Web-based client • Module อื่นๆ: Java apps (อาจมี web interface บ้าง) • Servers: • Front-end: Intel based, running on Linux • Back-end: DB2 running on AIX • ส่วนที่เชื่อมต่อกับระบบอื่นๆ ภายในมหาวิทยาลัย • LMS, E-learning • งานทะเบียน, งานบุคคล,LDAP

12. Platform ของระบบที่พัฒนา สำหรับ สกอ. • รองรับ DBMS เพิ่มอีกหนึ่งทางเลือก Oracle/MySQL/Postgress • Front-end: Linux/Windows • Back-end: Windows/Linux/Unix • Front-end และ back-end สามารถอยู่ในเครื่องเดียวกันได้

13. มาตรฐานที่ระบบสนับสนุนมาตรฐานที่ระบบสนับสนุน • MARC21 • All MARC record types : Bibliographic, Authority, Holding. • ISO2709 Exchange format • UTF-8 encoding • Z39.50 retrieval protocol • ISO 10160/10161 ILL • ISSN/ISBN • LCSH

14. สถาปัตยกรรมโครงสร้างของระบบสถาปัตยกรรมโครงสร้างของระบบ • โครงสร้างของระบบ LM จะมีลักษณะเป็น multi-tier architecture • มีการแบ่งส่วนของ software เป็น module เพื่อแบ่งภาระงานและแยกส่วนต่างๆออกจากกันเพื่อให้ง่ายในการดูแลและปรับปรุงระบบ

15. โครงสร้างระบบโดยรวม

16. คุณลักษณะหลักของส่วน OPAC • Basic search: Search using indice (title, author, …), Multi level browsing, Limit Search, MARC/non-MARC display format • Mark desired records for exporting to file, e-mail • Advanced search: Multiple search terms with boolean operators, Limit by certain fields • Any position search option. • Broadcast search, Universal search • Search statistics

17. Basic Search Example

18. Any Position Search

19. Broadcast Search

20. Statistics Example

21. คุณลักษณะหลักของส่วน Cataloguing • Record editor: Both in template and detail (MARC) mode. • Display bibliographic record as well as its attached records. • Separate holding record • Support authority record and authority control • Global update + rapid update • Reporting on list of records, statistics; barcode printing • Concurrent sessions • Support list of records: create, use, print • Import/Export records

22. Global Update Screen

23. Create Review File Screen

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

25. ปัญหาที่อาจเกิดขึ้นในการใช้ระบบปัญหาที่อาจเกิดขึ้นในการใช้ระบบ • การถ่ายโอนข้อมูลระหว่างระบบปัจจุบันกับระบบใหม่ • การฝึกอบรมเจ้าหน้าที่ห้องสมุด • ขีดความสามารถในการสนับสนุนของผู้พัฒนาระบบ

26. ระบบที่พัฒนาเสร็จแล้วระบบที่พัฒนาเสร็จแล้ว คาดหวังอะไรจาก Version 1? • ใช้งานพื้นฐานของแต่ละ module ได้ • มีมาตรฐานในการเชื่อมต่อกับระบบอื่นๆ ที่ สกอ. สนับสนุน และระบบสำคัญๆ ของ ThaiLIS • เน้นคุณลักษณะที่จำเป็นต้องใช้ก่อน • มีความไม่เสถียรอยู่บ้าง

27. ระบบในอนาคต Version 2 ปรับปรุงอะไรบ้าง • แก้ bug ต่างๆ ที่พบใน version 1 Version ต่อๆ ไป • เพิ่มคุณลักษณะต่างๆที่ขาดเข้าไป • รองรับแนวทางห้องสมุดในอนาคต:Union Circulation, RF ID, Electronic resource management, life long learning, information commons, E-learning, etc.