Transcript Chapter 8 Constructing a Decision Support System and DSS

Decision Support Systems Development
1
Topic
1 วัฎจักรการพัฒนาระบบ (System development life cycle
:SDLC)
2 CASE Tools
3 แนวทางเลือกอืน่ ในการพัฒนาระบบ
(Alternative Development Methodologies)
4 เหตุผลในการเลือกใช้ Prototyping
5 ระดับของเทคโนโลยีและเครื่องมือในการพัฒนาระบบ DSS
(DSS Technology levels and Tools)
6 การสร้ างทีมงานในการพัฒนา DSS
(Forming the development team)
2
Learning Objective
1. อธิบายขั้นตอนย่ อยของ SDLC ได้
2. ให้ เหตุผลในการเลือกใช้ Prototyping ได้
3. เปรียบเทียบความแตกต่ างระเหว่ างแนวทางของ SDLC กับแนวทางอืน่ ในการ
ออกแบบระบบเพือ่ พัฒนา DSS ได้
4. ยกตัวอย่ างเทคโนโลยีและเครื่องมือในทีใ่ ช้ ในการพัฒนาระบบ DSS ได้
5. บอกข้ อดีและข้ อเสี ยของการพัฒนา DSS ด้ วยสร้ างทีมงาน และ User ได้
3
คาถาม : เราจะพัฒนาระบบ DSS อย่ างไร? เพราะระบบ DSS มักจะเป็ นระบบที่ทันสมัย ?
- การพัฒนา DSS จะต้องคานึงถึง IT และอุปกรณ์ดา้ น Hardware, Software ที่
เหมาะสม ความสามารถในการทางานร่ วมกันได้กบั ระบบเดิม พัฒนาระบบ
ด้วยความประหยัดสุ ด และอีกประการหนึ่งซึ่ งจะต้องคานึงถึงก็คือ เมื่อ
พัฒนาระบบ DSS แล้ว ระบบนั้นมีความยืดหยุน่ ในการปรับใช้งานมากน้อย
เพียงใด
4
Methodology ?
Methodology :วิธีการที่เป็ นขั้นตอนในการแก้ปัญหานั้น ๆ
(ในการพัฒนาระบบ) อย่างเป็ นขั้นตอน (Step) และมีหลักการ
SA: เป็ นบุคคลที่ทาหน้าที่ในการวิเคราะห์ ปรับปรุ ง เปลี่ยนแปลง เพื่อนา
ระบบมาปรับปรุ งพัฒนา วิเคราะห์เนื้อหาของงาน
คาถาม : ทาไมไม่ให้ programmer เป็ นผูว้ ิเคราะห์ เพราะ
programmer บางครั้งคุยกับคนอื่นไม่รู้เรื่ อง และมักสร้างระบบ
แบบสวยหรู แต่ขาด Rule, ขาด Model ฉะนั้น SA จะเป็ นคน
กลางที่จะสร้างความเข้าใจว่าระบบใหม่คืออะไร
5
Project ?
โครงการ (Project) : project เป็ นสิ่ งชัว่ คราว (Temporary) มีการกาหนดวัน
เริ่ มต้นและสิ้ นสุ ดโครงการที่ชดั เจน
Time
Cost
Scope
3 องค์ประกอบนี้ตอ้ ง Balance กัน
6
Traditional Systems Development Life Cycle (SDLC) (Waterfall)
Need
Planning
ใช้ระยะเวลา 15%
Analysis
ใช้ระยะเวลา 20%
Design
ใช้ระยะเวลา 35%
Implementation
ใช้ระยะเวลา
30%
System
7
Waterfall :จะทางานลงมาเป็ น step ไม่ ข้ามขั้นตอน
ข้ อดี : สามารถเจาะจงหรือกาหนดสิ่ งทีร่ ะบบต้ องการก่ อนทีจ่ ะเริ่ม programming
ข้ อเสี ย : 1. การออกแบบจะถูกระบุลงใน paper ก่ อนทีจ่ ะเริ่ม programming
2. ใช้ ระยะเวลานานระหว่ าง project proposal และ delivery of
new system
8
ขั้นตอนแต่ ละ Phases ของ SDLC




Planning
Analysis
Design
Implementation
แต่ ละ Steps จะส่ งมอบ (deliverables) งานต่ อไปนี้
9
Planning
Why Build the System?
10
Planning
Why Build the System?
11
Analysis
Who, What, When, Where?
ขั้นตอนย่อย (Step)
1. Analyze problem: วิเคราะห์ปัญหา
นามาซึ่งผลลัพธ์ (Deliverable)
Analysis plan : แผนการวิเคราะห์
2. Gather information :รวบรวมข้อมูลสาหรับ Information : ข้อมูล ข่าวสารที่จะใช้ในการ
ใช้แก้ปัญหา
พัฒนาระบบ
3. Model process : กระบวนการทางานของ
แบบจาลอง
Process model: แบบจาลองกระบวนการ
4. Model data : ข้อมูลแบบจาลอง
Data model : แบบจาลองข้อมูล
12
Design
How Will the System Work?
13
Implementation
System Delivery
14
CASE Tools
Computer-aided System Engineering Tool : CASE Tools
เป็ นเครื่ องมือที่ช่วยในการวิเคราะห์และออกแบบระบบ ซึ่งมีความสามารถหลัก ๆ ดังนี้
1.เป็ นเครื่ องมือที่ช่วยวิเคราะห์ระบบ ใช้ออกแบบระบบข่าวสารต่าง ๆ เช่น Context,
Diagram, Data flow diagram(DFD)
2. ใช้ในการจัดการและพัฒนาระบบ
3. ช่วยทางานในขั้นตอน Planning, Analysis, Design ของกระบวนการ
SDLC
4. Lower CASE : จะช่วยทางานในขั้นตอน Design ,Implementation
ของกระบวนการ SDLC
5. Integrated CASE (both) : เป็ นทั้งแบบ Upper CASE รวมกับ
Lower CASE
*งานวิเคราะห์และออกแบบเป็ นงานที่น่าเบื่อ Case tool เป็ นเครื่ องมือช่วยในการพัฒนา
ระบบทัว่ ๆ ไป จัดเป็ นเครื่ องมือด้าน IT และมี Function การใช้งานพร้อม
15
ตัวอย่ างของ SW :CASE Tools








Oracle Enterprise Development Suite
Rational Rose
Paradigm Plus
Visible Analyst
Logic Works Suite
AxiomSys and AxiomDsn
V32 & X32
Visual Studio
16
17
Rational
Rose
Web
site สอนการใช้ งาน Rational Rose
18
Rational
Rose
ตัวอย่ างหน้ าจอของการเริ่มสร้ าง Use-Case
19
Visible Analyst
Courtesy of Visible System Corporation
20
Project Management (PM)

การบริหารโครงการ ถ้ าผู้บริหารหรือผู้นามีความชานาญด้ านบริหารจัดการโครงการ ก็จะ
เป็ นผลดีแก่ ทมี งาน

สาเหตุหลักในการพัฒนาระบบ IS มักจะล้ มเหลวหรือทาให้ โครงการนั้นแย่ ส่ วนใหญ่ มี
ผลมาจากความชานาญในการบริหารโครงการ (PM skills) จากการสารวจในปี
1998 พบว่ า มีโครงการเพียง 26% ทีป่ ระสบความสาเร็จ (จาก 23,000 โครงการ) ล้ มเหลว
28% และ 46% มีความขัดแย้ ง และพบว่ าโครงการประสบความสาเร็จในอัตราทีต่ ่ามาก
สาหรับบริษัทขนาดใหญ่
Note : สรุปได้ ว่าการมีผู้ชานาญในการบริหารโครงการจะเป็ นการดีกว่ า และลดความเสี่ ยง
อีกระดับหนึ่ง (Better PM skills needed)
21
Skills for Project Managers
ความชานาญในการบริ หารโครงการได้แก่
1. Technology and business knowledge: มีความชานาญในเทคโนโลยี และองค์
ความรู ้ทางด้านธุรกิจ
2. Judgment : เลือกใช้ IT ที่เหมาะสมกับระบบ แล้วปรับศาสตร์ ความรู ้ดา้ นIT
ผนวกเข้ากับศาสตร์ ดา้ นการบริ หาร
3. Negotiation : จัดการเจรจา ประชุมเพื่อมอบหมายงาน
4. Good communication : มีทกั ษะด้านการสื่ อสารที่ดี
5. Organization : มีความรู ้เกี่ยวกับองค์กร
22
แนวทางเลือกอืน่ ในการพัฒนาระบบ
(Alternative Development Methodologies)


Parallel development
Rapid application development (RAD)
methodologies: ทาแบบเร็ว ๆ ให้ทดลองใช้ก่อน และรับฟัง comment ทีหลัง
– Phased development : แบ่งออกมาเป็ นส่วน ๆ เหมือนเสี้ยวพระจันทร์
– Prototyping : ทาเป็ น model เล็ก ๆ แล้วค่อยนาไปขยาย ทาเป็ นระบบต้นแบบ เช่น
เครื่ องบินลาเล็ก เรื อลาเล็ก
– Throwaway prototyping : เป็ นเหมือนหน้ากาก ไม่มีใส้ใน เป็ นการทา
ต้นแบบที่ใช้จริ งไม่ได้ แต่พอให้รู้สดั ส่วน
23
Parallel Development
1. แบ่งระบบงานในการพัฒนาออกเป็ นระบบย่อย ๆ หลายส่ วน ได้แก่
- Data Management Subsystem
- Model Management Subsystem
- Knowledge Management Subsystem
- User Interface Management
Subsystem
แล้วทาการออกแบบตามระบบย่อยเหล่านี้
2. เริ่ มพัฒนาระบบงานของทุก ๆ ส่ วน (Subsystem) ไปพร้อม ๆ กัน
3. นาระบบมารวมกันเป็ นระบบเดียว
* การพัฒนาแบบ Parallel development อาจทาให้ระบบงานไม่มีความสอดคล้อง
กัน
24
Rapid application development (RAD) methodologies

RAD: เป็ นการพัฒนาระบบงานที่เน้นความเร็วและลดระยะเวลาการทางาน โดยการนา
JAD Tool และเทคนิคต่าง ๆ เข้ามาช่วย

JAD Tool : Joint application development method/ Joint Application
Design/Development เป็ นเครื่ องมือสาหรับดึงเอา User มานัง่ ออกแบบและสะท้อนผล
ออกทางจอภาพ ให้รู้วา่ สิ่ งที่ออกแบบนั้นสิ่ งใดที่ User ต้องการและไม่ตอ้ งการ ในขณะ
ออกแบบนั้นนักวิเคราะห์ควรเก็บหลักฐานไว้ดว้ ย เพื่อป้ องกัน User ปฏิเสธการรับผิด

JAD Tool จะอาศัยความร่ วมมือของทุกฝ่ ายที่เกี่ยวข้องในการพัฒนาระบบงาน เช่น ความ
ร่ วมมือจาก SA, Programmer, User, Executive เพื่อร่ วมออกแบบระบบด้วยกัน เพื่อให้
ระบบที่จะพัฒนาออกมานั้นได้รับการยอมรับ
25
Decision Support Systems and Intelligent Systems, Efraim Turban and Jay E. Aronson, 6th edition
Copyright 2001, Prentice Hall, Upper Saddle River, NJ
Joint Application Design (JAD)
Illustration of the typical room layout for a JAD:
•CASE tools during JAD: planning tools, diagramming tools, prototyping tools
(such as computer form and report generators).
•Supporting JAD with group support systems (GSS):
•Using prototyping during requirements determination
26
Joint Application Design (JAD
This sample screen mapping page was used in a JAD (Joint Application Development)
process to change a data form to allow for the inputting of enhanced data codes.
This mapping was done using the Visio Database tool.
27
Rapid application development (RAD) methodologies
ข้อดีของ RAD methodologies
พัฒนาระบบได้อย่างรวดเร็ว
ข้อเสี ยของ RAD methodologies
- ระบบมีความรี บเร่ งในการพัฒนา รายละเอียดปลีกย่อยอาจผิดพลาดได้
- User สามารถเปลี่ยน requirement ได้บ่อย เนื่องจากมี program ต้นแบบให้
ทดลองใช้
และแก้ไขได้ง่าย
วิธีการของ RAD methodologies สามารถแบ่งได้ 3 วิธี
1. Phased development
2. Prototyping
3. Throwaway prototyping
28
Rapid application development (RAD)
1. Phased Development
1. แบ่งระบบออกเป็ น Version และพัฒนาตามลาดับ
2. ทางานในขั้นตอน Plannig Analysis ,กาหนดจานวน Version ในการพัฒนา
3. พัฒนา Version ที่ 1 (ซึ่ งขั้นตอนในแต่ละ Version ประกอบด้วย Analysis  Design
Implementation) เมื่อ Version ที่ 1 ทาสาเร็ จ ก็นาออกไปให้ User ทดลองใช้
3. รับ Feedback ในการใช้งาน Version ที่ 1 กลับมาปรับปรุ งพัฒนาระบบใหม่
4. สร้าง Version ถัดไป ทาซ้ าขั้นตอนที่ 3-4 จนกว่าระบบจะเป็ นที่ยอมรับของ User
ข้อดี : มัน่ ใจได้วา่ ระบบที่พฒั นาเป็ น version ที่สมบูรณ์แล้วนั้นจะตรงกับความ
ต้องการของผูใ้ ช้
ข้อเสี ย : กว่าจะทางานได้ถึง version ที่สมบูรณ์ ต้องพัฒนา version ก่อนหน้า ไม่รู้
จานวนกี่ version ทาให้ตอ้ งใช้เวลานานกว่าที่จะได้ version ที่สมบูรณ์
29
Prototyping
1. ทางานในขั้นตอน analysis, design, และ implementation ไปพร้อม ๆ กัน, และ
2. นาระบบออกไปให้ User ใช้ เพื่อที่ Users จะได้เห็น function การทางานของระบบหาก
ระบบยังไม่ตรงความต้องการก็จะ feedback กลับไป
3. กลับไปทาซ้ าในขั้นตอนที่ 1-2 ใหม่ (repeatedly)
*ผูท้ าการตัดสิ นใจ (Decision maker) เรี ยนรู ้เกี่ยวกับปั ญหา จะช่วยลดเวลาในการพัฒนา
Prototyping แบบซ้ า ๆ ได้
ข้ อดี : เป็ นการพัฒนาระบบที่ใช้เวลาน้อย เนื่องจากขั้นตอน analysis, design, และ
implementation ถูกทาไปพร้อม ๆ กัน
ข้ อเสี ย: เนื่องจาก ขั้นตอน analysis, design, และ implementation ถูกทาไปพร้อม ๆ กัน การ
วิเคราะห์และออกแบบระบบอาจจะยังไม่ดีพอ ส่ งผลต่อการ implementation
30
Prototyping
Need
Planning
Analysis
Design
Implementation
Prototype
Prototype Not OK
Prototype OK
System
31
Throwaway Prototyping
1. คล้ายกับวิธีของ prototyping และ SDLC
2. ให้ความสาคัญในขั้นตอนการวิเคราะห์ (Analysis phase is thorough) ซึ่งจะใช้เวลานานมาก
สาหรับขั้นตอนนี้
3. พัฒนาต้นแบบ (prototypes) ซึ่งเป็ น prototypes แบบใช้แล้วทิ้ง คือ จะเป็ น prototypes ที่เป็ น
เพียงแค่การออกแบบหน้าจอให้ user ดู ว่ามีหน้าตาอย่างไร ป้ อนข้อมูลอย่างไร หาก User
เห็นด้วยกับที่ได้ออกแบบมา ก็จะนาเอา prototypes นั้นไปพัฒนาระบบ prototypes
ปัจจุบนั ก็ทิ้งไปไม่จาเป็ นต้องใช้แล้ว อาจใช้โปรแกรม Excel หรื อ Visual Basic ช่วยในการ
ออกแบบ
ข้อดี : มัน่ ใจได้วา่ User จะยอมรับระบบ เพราะระบบมีความละเอียดถี่ถว้ นการการ
วิเคราะห์ อีกทั้ง user มีการยอมรับระบบก่อนให้เริ่ มพัฒนาโปรแกรม
ข้อเสี ย : ระบบไม่ได้ทดลองใช้กบั ระบบงานจริ ง เมือนาไปใช้อาจจะไม่ดีจริ ง
32
Throwaway Prototyping
Need
Planning
Analysis
Design
Design
Design Prototype
Not OK
Implementation
Implementation
System
Design
Prototype
33
Decision Support Systems and Intelligent Systems, Efraim Turban and Jay E. Aronson, 6th edition
Copyright 2001, Prentice Hall, Upper Saddle River, NJ
Prototyping for DSS Development
แนวทางของ “Prototyping” จะเป็ นแนวทางที่เราเลือกใช้ในการพัฒนาระบบ DSS
เหตุผลเนื่องจาก
1. ใช้กบั ปั ญหาที่เป็ นแบบกึ่งโครงสร้าง (semi-structured) หรื อ ไม่มีโครงสร้าง
(un-structured)
2. ผูจ้ ดั การและผูพ้ ฒั นาไม่จาเป็ นต้องเข้าใจปั ญหาทั้งหมด
3. ใช้ตน้ แบบ (Use prototyping)
34
เหตุผลในการเลือกใช้ Prototyping (Why Prototyping?)
1. ผูใ้ ช้และผูจ้ ดั การจะอยูใ่ นทุก ๆ ขั้นตอนของการพัฒนาระบบและการทาซ้ า
Prototyping
2. ได้มีส่วนร่ วมในการออกแบบ
3. Prototyping จะเป็ นตัวกาหนดความต้องการข่าวสารของผูใ้ ช้ทางอ้อมไปในตัว
4. ระยะเวลาในการทาซ้ า Prototyping นั้นใช้เวลาสั้น
5. การเริ่ มต้นทา prototype มักจะใช้ตน้ ทุนต่า
* เป็ นการเรี ยนรู ้ความต้องการข่าวสารจาก User อย่างชัดเจน
35
ข้ อดีของ Prototyping (Advantages of Prototyping)
1. ใช้เวลาพัฒนาสั้น (Short development time)
2. User โต้ตอบกับระบบได้ในระยะเวลาอันสั้น (Short user reaction time)
3. สามารถปรับปรุ งระบบได้ตรงกับความต้องการของ User และ User สามารถทาความเข้าใจ
ระบบได้ดีข้ ึน (user Improved user understanding)
4. ต้นทุนต่า (Low cost)
ข้ อเสี ยของ Prototyping (Disadvantages of Prototyping)
1. อาจขาดความเข้าใจเกี่ยวกับเป้ าหมายในการใช้ระบบ IS และค่าใช้จ่ายโดยรวมในการ
พัฒนาระบบ เนื่องจากเป็ นการพัฒนาจากระบบย่อย ๆ
2. ในการทา prototyping จะสนใจเฉพาะข่าวสารที่จะนามาทา ฉะนั้นผูพ้ ฒั นาระบบอาจขาด
ความเข้าใจในรายละเอียดและข่าวสารที่จาเป็ นขององค์กร
3. ยากต่อการบารุ งรักษา เนื่องจากระบบมีการเปลี่ยนแปลงอยูต่ ลอดเวลา
4. จะต้องมีการทดสอบระบบอย่างดี เนื่องจากระบบจะมีการพัฒนา Prototyping ซ้ า ๆ อยู่
ตลอดเวลา
5. จะต้องมีการเตรี ยมการ กับ User เป็ นอย่างดีและบ่อยครั้ง อาจต้องฝึ กอบรมผูใ้ ช้ตามการ
ใช้งาน Prototyping แต่ละครั้งที่พฒั นาออกไป
36
ระดับของเทคโนโลยีและเครื่องมือในการพัฒนาระบบ DSS
(DSS Technology Levels and Tools)
เทคโนโลยีและเครื่ องมือสาหรับพัฒนาระบบ DSS แบ่งออกเป็ น 3 ระดับ ดังนี้
1. Specific DSS [the application] : เป็ นโปรแกรม ที่ได้จากการพัฒนาระบบ
DSS ตามกระบวนการ System Development เรี ยกโปรแกรมนี้วา่
“DSS Application”
2. DSS integrated tools (generators) [Excel] : เป็ น Software สาเร็ จรู ป ที่ใช้
พัฒนา DSS ให้ทุกอย่างดูง่ายขึ้น อาทิเช่น MS-Excel, Cognos, Lingo, Lindo,
PowerHouse4 GL Quick, OLAP System เป็ นต้น
3. DSS primary tools [programming languages] : เป็ นเครื่ องแรกเริ่ มในการ
พัฒนา DSS ได้แก่ภาษาในการเขียนโปรแกรม เช่น Java, Visual Basic,
C++, Delphi เป็ นต้น
37
DSS Technology Levels
(Figure 6.5)
Specific DSS
DSS Generators
(Spreadsheets, …)
DSS Tools (Languages, …)
38
Decision Support Systems and Intelligent Systems, Efraim Turban and Jay E. Aronson, 6th edition
Copyright 2001, Prentice Hall, Upper Saddle River, NJ
การเลือก Hardware (Hardware Selection)





PCs เหมาะสาหรับ DSS ขนาดเล็ก ที่พฒั นาจาก Spreadsheet
Unix workstations เหมาะกับ DSS ขนาดองค์กรที่มีการใช้งานเครื อข่าย
Network of Unix workstations เหมาะกับ DSS ขนาดองค์กรที่มีการใช้งาน
เครื อข่าย
Web servers เหมาะกับ DSS ที่ใช้งานบน Web site
Mainframes เหมาะกับ DSS สาหรับองค์กรขนาดใหญ่ ที่ตอ้ งวิเคราะห์
ข้อมูลจานวนมหาศาล เช่น Bank
* การเลือกใช้ Hardware กับ Software สาหรับ DSS นั้น จะต้ องมีความ
สอดคล้ องกัน
39
การเลือก Software (Software Selection)
ในการเลือก Software สาหรับพัฒนา DSS มีความซับซ้อน คือ





programmer ยังขาดข้อมูลเกี่ยวกับ information requirements และ Output ที่ user
ต้องการ ส่ งผลต่อการพิจาณาเลือก Software ที่เหมาะสม
มีจานวน Software สาเร็จรู ปมีขายนับร้อย (Hundreds of packages) ทาให้ตดั สิ นใจเลือก
ลาบาก
Software เปลี่ยนแปลงเร็ว ทาให้ตามไม่ทนั (Software updated rapidly)
การเปลี่ยนแปลงด้านราคา (Price Changes) ราคา Software ที่เปลี่ยนแปลง ทาให้
คัดเลือกได้ยาก
บุคคลหรื อทีมงานที่เกี่ยวข้องกับการตัดสิ นใจ มีหลายคน อาจมีความคิดเห็นขัดแย้ง ไม่
ตรงกันในเรื่ องของการเลือก Software
40






ปัญหาในด้านประสิ ทธิภาพของภาษา (Language capability
problem)
จาเป็ นต้องใช้เครื่ องมือที่มีความแตกต่างกัน ทาให้ลาบากในการ link ระบบ
(Different Tools)
มีเงื่อนไขมากมาย (Many Criteria)
ด้านเทคนิค, function, end-user และด้านการจัดการ
ความไม่ถูกต้องในการตีพิมพ์โฆษณา Software , อาจทาให้เลือก Software
ผิดพลาด
ความโอนเอียงไปกับผูข้ าย Software ฝ่ ายใดฝ่ ายหนึ่งมากไป, ทาให้มองข้าม
ประสิ ทธิภาพและความเหมาะสมของ Software กับประเภทงานของตน
* หรือบางทีอาจจะใช้ AHP ซึ่งเป็ น Software ให้ เช่ า เขาจะมีการ update
software และ Maintenance
41
AHP
42
การสร้ างทีมงานพัฒนาระบบ DSS
(Forming the development team)
ระบบงานที่ตอ้ งใช้ทีมงาน ในการพัฒนานั้น มักจะเป็ นระบบงานขนาดใหญ่ DSS ที่
พัฒนาขึ้นนั้นส่ วนใหญ่จะ Support ปั ญหาทั้งหมดขององค์กร DSS ควรมีความ
ยืดหยุน่ support ปัญหากึ่งโครงสร้างและแบบไม่มีก่ ึงโครงสร้างได้
ลักษณะการพัฒนา DSS โดยใช้ ทมี งาน เป็ นดังนี้
1. ต้องใช้ความพยายามอย่างมากในการพัฒนาระบบ
2. ต้องวางแผนอย่างดีให้ครอบคลุมทั้งองค์กร
3. บางกิจกรรมเกี่ยวกับการค้า มีเรื่ องของกฎหมายเข้ามาเกี่ยวข้อง
4. กลุ่มของคนที่จะพัฒนาและจัดการกับระบบขึ้นอยูก่ บั ขนาดของระบบ (Size)
5. อาจต้องใช้ Tools มากมาย
43
ทีมงานในการพัฒนา DSS ประกอบด้ วย








User
System Analyst :SA
System Design : SD
Programmer
Expert / นักวิเคราะห์สถิติ
Tester
Technicial / System Engineer :SE
Project Manager
44
การพัฒนาระบบ DSS โดยใช้ End-User
(End-User-Developed Systems)
1. ใช้ PC (Personal computers)
2. เชื่อมต่อ networks ได้ (Computer communication networks)
3. เชื่อมการสื่ อสารระหว่างเครื่ อง PC เข้ากับ mainframe ได้
(PC-mainframe communication)
4. โปรแกรมมีความสะดวก และง่ายต่อการใช้งาน (Friendly development software)
เนื่องจากผูใ้ ช้เป็ นผูเ้ ขียนโปรแกรมขึ้นใช้งานเอง
5. ประหยัดต้นทุนในเรื่ อง Software และ Hardware (Reduced cost of software and
hardware)
6. เพิ่มประสิ ทธิภาพให้กบั เครื่ อง PC (Increased capabilities of personal computer)
7. ใช้ได้อย่างกว้างกับคอมพิวเตอร์ในองค์กร ไม่จากัด (Enterprise-wide computing)
8. เข้าถึงข้อมูลและแบบจาลองได้ง่าย (Easy accessibility to data and models )
9. ใช้สถาปัตยกรรม Client/server ได้ (Client/server architecture)
10. ปัจจุบนั พัฒนาโดยใช้ OLAP ได้ (Now OLAP)
45
ข้ อดีของการพัฒนาระบบโดยผู้ใช้
(User-Developed DSS Advantages)
1. ส่ งมอบระบบในเวลาอันรวดเร็ ว (Short delivery time)
2. ไม่กาหนดความต้องการของระบบอย่างตายตัว ทาให้ระบบมีความยืดหยุน่
ผูใ้ ช้สามารถปรับและเปลี่ยนแปลงระบบ ได้ตามความต้องการ
(Eliminate extensive and formal user requirements specifications)
3. ลดปัญหาเมื่อนาระบบ DSS ไปใช้
(Reduce some DSS implementation problems)
4. ต้นทุนต่า (Low cost)
46
ความเสี่ ยงของการพัฒนาระบบโดยผู้ใช้
(User-Developed DSS Risks)
1. ประสิ ทธิ ภาพต่า (Poor Quality)
2. มีความเสี่ ยงสู ง (Quality Risks) เมื่อนาไปวิเคราะห์และนาผลลัพธ์ที่ได้น้ นั ไปประกอบการตัดสิ นใจ
หากระบบยังขาดประสิ ทธิ ภาพและมาตรฐาน อาจส่ งผลต่อธุรกิจขององค์กร
- Substandard or inappropriate tools and facilities : ความยืดหยุน่ และเครื่ องมือที่ไม่เหมาะสมหรื อ
ขาดมาตรฐาน
- Development process risks : ความเสี่ ยงในกระบวนการพัฒนา เช่น กระบวนการ System
Develop ไม่ดีพอ ส่ งผลต่อผลลัพธ์ที่ได้ เมื่อเรานาโปรแกรมมาใช้งานจริ ง
- Data management risks : ความเสี่ ยงในการจัดการข้อมูล ข้อมูลที่นาเข้ามาใช้ในระบบอาจมีความ
ไม่ถกู ต้อง ไม่เหมาะสม ขาดการ Update ให้เป็ นปั จจุบนั
3.ไม่มีระบบรักษาความปลอดภัย (Increased Security Risks) User ที่พฒั นาระบบงานอาจยังไมคุน้ เคย
กับการทาระบบรักษาความปลอดภัยและยังไม่เป็ น Professional พอ
4. ปั ญหาจากการขาดแคลนเอกสารและคู่มือในการบารุ งรักษาระบบ (Problems from Lack of
Documentation and Maintenance Procedures) User เป็ นผูพ้ ฒั นาระบบเอง ฉะนั้นจะเป็ นผูร้ ู ้
ระบบงานทุกอย่าง เราจึงมักจะคิดว่าไม่มีความจาเป็ นที่จะต้องทาคู่มือ ซึ่ งจะก่อให้เกิดปั ญหา
ขึ้นกับคนอื่นที่มาใช้ระบบในภายหลัง
47
ทิศทางของระบบ DSS และ DSS ในอนาคต
1. เป็ นมากกว่า AI (More AI)
2. ช่วยในการวิเคราะห์ได้อย่างรวดเร็ว และเป็ นมากกว่าการเพิ่มประสิ ทธิภาพให้กบั เครื่ อง
คอมพิวเตอร์ (Faster, more powerful computers)
3. ใช้บนระบบ Web site (The Web - interfaces and DB and model access)
4. เป็ นมากกว่าและดีกว่า Group support system (More and better GSS)
6. เป็ นระบบจัดการองค์ความรู้ (Knowledge management)
7. มีระบบ GUI ที่ดีกว่าปัจจุบนั (Better GUI)
48