Ch_02_Information System Development

1 2 14/01/55 อ.กรรณิการ์ แกว้ เช้ ือ 1 การวเิ คราะหแ์ ละออกแบบระบบ อ.ธนาวิทย์ รตั นเกียรติขจร 2 3 การวเิ คราะหแ์ ละออกแบบระบบ 43 4 5  การพฒั นาระบบสารสนเทศ ใหม้ ีประสิทธภิ าพและประสบความสาํ เรจ็ 6 ตามความตอ้ งการของผูใ้ ช้ ภายใตก้ รอบงบประมาณและภายใน 7 ระยะเวลาท่ีกาํ หนดน้นั นอกจากจะตอ้ งไดร้ บั ความเห็นชอบและส่งเสรมิ จากผบู้ รหิ ารองคก์ ารแลว้ ผเู้ กี่ยวขอ้ งตอ้ งมีความเขา้ ใจและจะตอ้ งมี กระบวนการหรอื ข้นั ตอนในการพฒั นาระบบท่ตี อ่ เน่ืองสอดคลอ้ งกนั การวเิ คราะหแ์ ละออกแบบระบบ 1

14/01/555 6  การพฒั นาระบบสารสนเทศเป็ นกระบวนการในการสรา้ งระบบสารสนเทศ วงจรชีวิต ข้ ึนมาเพื่อ (Life Cycle) - ใชส้ าํ หรบั แกป้ ัญหา - สรา้ งมลู คา่ เพิ่มใหก้ บั ธุรกิจ ส่ิงมีชีวิตบนโลก ซอฟตแ์ วร์ ปัจจุบนั ระบบสารสนเทศนับวนั จะทวคี วามซบั ซอ้ นยงิ่ ข้ ึนและมีขนาดใหญ่ ว ง จ ร ชี วิ ต ข อ ง ใชส้ าํ หรบั ดงั น้ัน โครงการพฒั นาระบบสารสนเทศจึงจาํ เป็ นตอ้ งไดร้ บั การวางแผนท่ีดี มนุษย์ สตั ว์ หรือพืช การพฒั นาระบบใหม่ การวเิ คราะหแ์ ละออกแบบระบบ หรือ แกไ้ ขระบบงานเดิม7 การวเิ คราะหแ์ ละออกแบบระบบ วงจรการพฒั นาระบบ (System Development Life Cycle) หรือ เรียกส้นั ๆ วา่ SDLC 8 การวเิ คราะหแ์ ละออกแบบระบบ 1. การสาํ รวจเบ้ อื งตน้ (Preliminary Investigation) 6. การบาํ รุงรกั ษา 2. การวเิ คราะห์ (Maintenance) (Analysis) 5. การทาํ ใหเ้ กิดผล 3. การออกแบบทางตรรกะ (Implementation) (Logical Design) 4. การออกแบบทาง กายภาพ (Physical Design) การวเิ คราะหแ์ ละออกแบบระบบ 2

9 14/01/55 สาํ หรบั การพฒั นาซอฟตแ์ วรข์ นาดเล็ก ประกอบไปดว้ ยกลุ่มกิจกรรม 3 10 ส่วนหลกั ๆ ดว้ ยกนั คือ สาํ หรบั การพฒั นาซอฟตแ์ วรข์ นาดใหญ่ จาํ เป็ นใชแ้ บบแผนการ สว่ นท่ี 1 การวิเคราะห์ (Analysis) พฒั นาซอฟตแ์ วรต์ ามแนวของ SDLC จนครบทุกกิจกรรม สว่ นท่ี 2 การออกแบบ (Design) ส่วนท่ี 3 การนาํ ไปใช้ (Implementation) การวเิ คราะหแ์ ละออกแบบระบบ การวเิ คราะหแ์ ละออกแบบระบบ 1211 ระยะท่ี 1 การวางแผนโครงการ การวเิ คราะหแ์ ละออกแบบระบบ  เป็ นกระบวนการพ้ ืนฐานบนความเขา้ ใจว่า ทาํ ไม (Why) ตอ้ งสรา้ งระบบงานใหม่ ทีมงานตอ้ งพิจารณาวา่ จะตอ้ งดาํ เนินการอยา่ งไรเก่ียวกบั กระบวนการสรา้ งระบบใหม่ ซ่ึงข้นั ตอนแรกคือ ตอ้ งมีจุดกาํ เนิดของระบบงาน (Project Initiate)  Project Initiate จะเกิดข้ นึ จากผใู้ ชร้ ะบบ ที่มีความตอ้ งการปรบั ปรุงระบบงาน  จุดเริ่มตน้ คือตอ้ งทําการศึกษาขอบเขตปัญหาที่ผูใ้ ชร้ ะบบกาํ ลังประสบปัญหาอยู่ และจะดําเนินการแกไ้ ขอย่างไร ศึกษาความเป็ นไปไดข้ องระบบใหม่ ว่าคุม้ ค่าท่ีจะ ลงทุนหรือไม่  ระยะน้ ีมีระยะเวลาคอ่ นขา้ งส้นั แต่เป็ นระยะที่สาํ คญั เกี่ยวกบั ภาพรวมของระบบที่จะ กอ่ ใหเ้ กิดผลสาํ เร็จ  จาํ เป็ นตอ้ งมีนักวิเคราะหร์ ะบบท่ีมีความรแู้ ละประสบการณส์ งู การวเิ คราะหแ์ ละออกแบบระบบ 3

14/01/5513 14ระยะที่ 1 การวางแผนโครงการ 16 การวางแผนโครงการ หรือการสาํ รวจเบ้ ืองตน้ เป็ นข้ันตอน  การหาปัญหา โอกาส และเป้ าหมาย เป็ นกิจกรรมแรกที่สาํ คญั มาก เม่ือ แรกของวงจรการพฒั นาระบบที่ทีมงานตอ้ งพฒั นาระบบซ่ึงถูกต้งั ข้ ึน เห็นถึงปัญหา โอกาส หรือเป้ าหมายที่สามารถนําระบบคอมพิวเตอรเ์ ขา้ ไป และไดร้ บั อนุมตั ใิ หท้ าํ การศึกษาและพฒั นาระบบ แกไ้ ขได้ จะถือเป็ นจุดเร่ิมตน้ ในการสรา้ งระบบคอมพิวเตอร์ โดยนักวิเคราะห์ ระบบจะตอ้ งพยายามหาโอกาสในการปรบั ปรุงโดยใชร้ ะบบคอมพิวเตอรเ์ ขา้ ไป การวเิ คราะหแ์ ละออกแบบระบบ ใชใ้ นดา้ นต่าง ๆ จะตอ้ งมองปัญหาใหถ้ กู ตอ้ ง มองเป้ าหมายท่ีชดั เจนเพ่ือจะได้ รทู้ ิศทางของการกระทาํ ระบบเพ่ือใหเ้ ป็ นไปตามเป้ าหมาย15 การวเิ คราะหแ์ ละออกแบบระบบ ระยะที่ 1 การวางแผนโครงการ ระยะของการวางแผนโครงการประกอบดว้ ยกิจกรรมต่างๆ ต่อไปน้ ี  กาํ หนดปัญหา (Problem Definition)  ศึกษาความเป็ นไปไดข้ องโครงการ (Feasibility)  ศึกษาดา้ นเทคนิค  ศึกษาดา้ นเศรษฐศาสตร์ (ตน้ ทุน คา่ ใชจ้ า่ ย)  ดา้ นการดาํ เนินงาน  จดั ทาํ ตารางกาํ หนดเวลาโครงการ (Project scheduling)  จดั ตง้ั ทีมงานโครงการ (Staff the project)  ดาํ เนินการโครงการ (Launch the project) การวเิ คราะหแ์ ละออกแบบระบบ 4

17 14/01/55 เชน่ ตอ้ งการแขง่ ขนั กบั ค่แู ข่งในเรื่องการลดตน้ ทุนการผลิตสินคา้ โดยลด ตวั อยา่ งการเขา้ ใจปัญหา จาํ นวนการสต็อกวตั ถุดิบ ดงั น้ันนักวเิ คราะหร์ ะบบเห็นถึงปัญหา โอกาส และเป้ าหมาย ในการนําระบบคอมพิวเตอรเ์ ขา้ ไปใชใ้ นการเก็บขอ้ มลู สต็อก 18 วตั ถุดิบ และประมวลผลการสงั่ วตั ถุดิบ เป็ นตน้ บริษทั ใจดี จาํ กดั ติดต่อซ้ ือสินคา้ จากผขู้ ายหลายบริษทั ดว้ ยกนั การวเิ คราะหแ์ ละออกแบบระบบ ซึ่งบริษัทใจดี มีระบบ MIS ท่ีเก็บขอ้ มลู เกี่ยวกบั หน้ ีสินท่ีบริษัทใจดีได้ ติดคา้ งผขู้ ายอยู่ แต่ระบบสามารถเก็บขอ้ มลู ผขู้ ายไดเ้ พียง 1,000 ราย การสืบคน้ ความตอ้ งการของผใู้ ช้ เท่าน้ัน แต่ปัจจุบนั ระบบน้ ีมขี อ้ มลู ผขู้ ายเก็บอยถู่ ึง 900 รายและในอนาคต19 อนั ใกลน้ ้ ีจะเกิน 1,000 รายแน่นอน ดงั น้ันก่อนท่ีจะเกิดปัญหาข้ ึนจงึ ตอ้ งมีการพฒั นาระบบใหเ้ ปล่ียนขนาด  ใชก้ ารสุ่มตวั อยา่ ง การสอบถามหาขอ้ มลู การสมั ภาษณ์ การ จาํ นวนผขู้ ายไดม้ ากข้ ึน ออกแบบสอบถาม การสงั เกตพฤติกรรมของผใู้ ชแ้ ละส่ิงแวดลอ้ ม เพ่ือ สืบคน้ เก็บรวมรวมขอ้ มลู ที่เป็ นความตอ้ งการของผใู้ ชร้ ะบบ การวเิ คราะหแ์ ละออกแบบระบบ ในขณะเดียวกนั ก็นําความตอ้ งการของผใู้ ชร้ ะบบไปศึกษาหาช่องทางใน การพฒั นาระบบต่อไป ตวั อยา่ งการสืบคน้ ความตอ้ งการของผใู้ ช้ การวเิ คราะหแ์ ละออกแบบระบบ 20 จากปัญหาของ บรษิ ัทใจดี ความตอ้ งการของผบู้ ริหารตอ้ งการใหส้ ามารถ เก็บขอ้ มลู ผขู้ ายไดถ้ ึง 4,000 รายและจะใชร้ ะบบน้ ีตอ่ ไปถึงอยา่ งนอ้ ย 5 ปี นอกจากน้ ีก็หาความตอ้ งการของผใู้ ชเ้ พิม่ เติมอีกวา่ ตอ้ งการใหม้ ีรายงานอ่ืน ๆ เพิ่มเติมอีกหรอื ไม่ จากน้ันก็ทาํ การศกึ ษาล่ทู างในการพฒั นาไมว่ า่ จะเป็ นลทู่ างดา้ นวธิ ีการ, งบประมาณ, บุคลากร หรือ ดา้ นเทคโนโลยที ี่เก่ยี วขอ้ งต่าง ๆ วา่ เพียงพอและ เหมาะสมตอ่ การพฒั นาหรอื ไม่ เป็ นตน้ ซ่ึงการศึกษาความเป็ นไปไดเ้ หลา่ น้ ีจะ เป็ นไปอยา่ งหยาบ ๆ เพื่อ เปรียบเทียบใหเ้ ห็นภาพการพฒั นา วา่ จะคุม้ กบั การ ปรบั ปรุงเปลี่ยนแปลงมากนอ้ ยเพียงใด การวเิ คราะหแ์ ละออกแบบระบบ 5

ตวั อยา่ งการสืบคน้ ความตอ้ งการของผใู้ ช้ 14/01/5521 22 Executive ??? ???? ? ???? สมั ภาษณ์ ความตอ้ งการ นกั วิเคราะหร์ ะบบ User User User การวเิ คราะหแ์ ละออกแบบระบบ การวเิ คราะหแ์ ละออกแบบระบบ23 24 การวิเคราะห์ หรือการวิเคราะหค์ วามตอ้ งการ เป็ นข้ันตอนท่ี  ระยะการวเิ คราะหจ์ ะมคี าํ ตอบเกี่ยวกบั คาํ ถามวา่ ใคร (Who) เป็ นผใู้ ชร้ ะบบ และ สาํ คัญในการดาํ เนินการหลังจากการสาํ รวจเบ้ ืองตน้ ถึงปัญหาและ มอี ะไรบา้ ง (What) ที่ระบบตอ้ งทาํ ความเป็ นไปไดใ้ นการพฒั นาระบบ  ระยะน้ ีตอ้ งดาํ เนินการวเิ คราะหร์ ะบบงานปัจจบุ นั เพ่ือพฒั นาแนวความคดิ สาํ หรบั การวเิ คราะหแ์ ละออกแบบระบบ ระบบใหม่  วตั ถุประสงคห์ ลกั คือ ศึกษาทาํ ความเขา้ ใจความตอ้ งการต่างๆที่ไดร้ วบรวมมา  ดงั น้ัน การรวบรวมความตอ้ งการ (Requirements Gathering) จึงเป็ นงานสว่ น พ้ ืนฐานของการวเิ คราะห์ ซ่ึงนักวเิ คราะหร์ ะบบจะประเมนิ วา่ ควรมีอะไรบา้ งท่ี ระบบใหมต่ อ้ งดาํ เนินการ  ดงั น้ันการกาํ หนดรายละเอียดเก่ียวกบั ความตอ้ งการของผใู้ ช้ (User Requirements) จะมคี วามสาํ คญั มาก การวเิ คราะหแ์ ละออกแบบระบบ 6

25 14/01/55  นักวเิ คราะหร์ ะบบรวบรวมความตอ้ งการไดจ้ ากการสงั เกต การสมั ภาษณ์ การ 26 ทาํ แบบสอบถาม การอ่านเอกสารเก่ยี วกบั การปฏิบตั ิงานของระบบ ระเบียบ กฎเกณฑ์ ภาพ การรวบรวมขอ้ มูลหรือความตอ้ งการเพื่อสรุปเป็ นขอ้ กาํ หนด  จากน้ันจงึ สรุปออกมาเป็ นขอ้ กาํ หนด (Requirement Specification) ท่ีชดั เจน การวเิ คราะหแ์ ละออกแบบระบบ อ่านแลว้ ตีความหมายไดต้ รงกนั 28 การวเิ คราะหแ์ ละออกแบบระบบ ภาพข้นั ตอนการนาํ ขอ้ กาํ หนดมาวิเคราะหเ์ พื่อสรา้ งแบบจาํ ลองกระบวนการของระบบใหม่27 การวเิ คราะหแ์ ละออกแบบระบบ  หลงั จากน้ันนักวิเคราะหร์ ะบบตอ้ งนําขอ้ กาํ หนดไปพฒั นาออกมาเป็ น ความตอ้ งการของระบบใหม่ เทคนิคที่ใชค้ ือ การพฒั นาแบบจาํ ลอง กระบวนการ (Process Model) เพื่ออธิบายกระบวนการที่ตอ้ งทาํ ใน ระบบ ต่อไปก็ดาํ เนินการพฒั นาแบบจาํ ลองขอ้ มลู (Data Model) เพ่ือ อธิบายสารสนเทศที่ตอ้ งจดั เก็บไวส้ าํ หรบั สนับสนุนกระบวนการ ต่างๆ การวเิ คราะหแ์ ละออกแบบระบบ 7

29 30 การวเิ คราะหแ์ ละออกแบบระบบ 14/01/55 32 การวเิ คราะหแ์ ละออกแบบระบบ 8 1 • วิเคราะหร์ ะบบงานปัจจุบนั 2 • รวบรวมความตอ้ งการในดา้ นต่าง ๆ และนํามาวเิ คราะหเ์ พ่อื สรุปเป็ นขอ้ กาํ หนดที่ชดั เจน 3 • นําขอ้ กาํ หนดมาพฒั นาออกมาเป็ นความตอ้ งการของระบบใหม่ • สรา้ งแบบจาํ ลองกระบวนการของระบบใหมด่ ว้ ยการวาดแผนภาพกระแสขอ้ มลู (Data 4 Flow Diagram : DFD) 5 • สรา้ งแบบจาํ ลองขอ้ มลู ดว้ ยการวาด Entity Relationship Diagram การวเิ คราะหแ์ ละออกแบบระบบ31 ทมี งานพฒั นาระบบจะนาํ ขอ้ มูลจากการศึกษามาใชอ้ อกแบบ รายละเอียดในสว่ นตา่ งๆ ของระบบสารสนเทศใหม่ ต้งั แตก่ ารแสดงผลลพั ธ์ การป้ อนขอ้ มูล กระบวนการเก็บรกั ษา การปฏิบตั งิ าน และบุคลากรทจ่ี ะตอ้ ง เก่ียวขอ้ งกบั ระบบใหม่ เพื่อที่จะทาํ การจดั หาอปุ กรณต์ า่ งๆ สาํ หรบั นาํ มาพฒั นา เป็ นระบบใหม่ตอ่ ไป การออกแบบแบ่งออกเป็ น 2 ส่วน คือ 1. การออกแบบเชิงตรรกะ (Logical Design) เป็ นกระบวนการออกแบบโดยไมไ่ ดค้ าํ นึงถึง ฮารด์ แวรแ์ พลตฟอรม์ 2. การออกแบบเชิงกายภาพ (Physical Design) เป็ นการแปลงขอ้ กาํ หนดคณุ ลกั ษณะให้ เป็ นขอ้ กาํ หนดคณุ ลกั ษณะเชิงกายภาพ โดยการออกแบบสว่ นตา่ งๆ ของระบบท่ีสามารถใชป้ ฏิบตั ิงานไดจ้ ริง การวเิ คราะหแ์ ละออกแบบระบบ

33 34 การวเิ คราะหแ์ ละออกแบบระบบ 14/01/55 36 การวเิ คราะหแ์ ละออกแบบระบบ 9  การวิเคราะห์ มุ่งเนน้ การแกป้ ัญหาอะไร (What)  การออกแบบ มุ่งเนน้ การแกป้ ัญหาอยา่ งไร (How) การวเิ คราะหแ์ ละออกแบบระบบ35 อุปกรณ์ Hardware Architecture Design Software Network การวเิ คราะหแ์ ละออกแบบระบบ

14/01/5537 38 การนาํ ไปใช้ หรือการจดั หาระบบ ประกอบดว้ ย 3 ข้ันตอน Coding/Testing หลกั คือ Implement 1. การพฒั นาระบบ การวเิ คราะหแ์ ละออกแบบระบบ 2. การทดสอบ 3. การตดิ ตง้ั 40 การวเิ คราะหแ์ ละออกแบบระบบ สาํ หรบั การสรา้ งระบบหรือการเขียนโปรแกรมน้ัน สามารถใช้ ดว้ ยภาษาคอมพิวเตอร์ เช่น การใชภ้ าษา VB, Delphi หรือ Java39 นอกจากน้ ีก็ยังมีเทคนิคอ่ืนๆ เช่น การใช้เครื่องมือในการพัฒนา แอพพลิเคชนั ่ (Application Development Environment สรา้ งระบบข้ ึนมาดว้ ยการเขียนโปรแกรม : ADE Tools) ซึ่งเป็ นแหลง่ รวมเคร่ืองตา่ งๆ มากมายท่ีใชเ้ พื่อการ ตรวจสอบความถกู ตอ้ งทง้ั ทางดา้ น Verification และ Validation พฒั นาแอพพลเิ คชนั ่ และดาํ เนินการทดสอบระบบ การวเิ คราะหแ์ ละออกแบบระบบ แปลงขอ้ มูล ตดิ ตง้ั ระบบ และจดั ทาํ เอกสารคมู่ ือ ฝึ กอบรมผใู้ ช้ และประเมินผลระบบใหม่ การวเิ คราะหแ์ ละออกแบบระบบ 10

41 14/01/55 Programming Language 42 Interface Construction Tools Middleware การวเิ คราะหแ์ ละออกแบบระบบ Testing Tools Help Authoring Tools 44 Repository Links การบาํ รุง การเพม่ิ เติม การสนับสนุนงาน ADE Tools ซึ่งเป็ นซอฟตแ์ วรท์ ร่ี วมเครื่องมือในการพฒั นาแอพพลเิ คชนั ่ รกั ษาระบบ คุณสมบตั ิใหมๆ่ ของผใู้ ช้ เขา้ ไปในระบบ การวเิ คราะหแ์ ละออกแบบระบบ System Maintenance Enhance the System Support the Users43 การวเิ คราะหแ์ ละออกแบบระบบ การบาํ รุงรักษา เม่ือระบบใหม่ไดถ้ ูกใชง้ านแลว้ ก็ย่ิงจาํ เป็ น อย่างย่ิงที่จะตอ้ งมีการวางแผนและกาํ หนดกฎเกณฑ์ในการท่ีจะ บาํ รุงรักษาระบบอย่างสมาํ่ เสมอ มีการแกไ้ ขขอ้ ผิดพลาด รวมท้ังมี การปรบั เปล่ียนแปลงตามส่ิงแวดลอ้ ม และเพิ่มลกั ษณะเฉพาะใหม่ๆ ในส่ิงท่ีเป็ นประโยชนก์ ับระบบ เพ่ือใหร้ ะบบใหม่สามารถปฏิบตั ิงาน ไดอ้ ยา่ งมีประสิทธิภาพ การวเิ คราะหแ์ ละออกแบบระบบ 11

14/01/5545 46 ระยะ Phase คือ กลมุ่ ของกิจกรรมท่ีเก่ยี วขอ้ งกนั ระยะการวางแผนโครงการ กิจกรรม Activity คือ กล่มุ ของงานทเี่ ก่ียวขอ้ งกนั • งานเขา้ พบผใู้ ชง้ านระดบั ต่างๆ Task คือ ช้ นิ งานท่ีดาํ เนินการ ซึ่งถอื • งานกาํ หนดขอบเขตปัญหา • งานจดั ทาํ เอกสารแสดงขอบเขตของระบบ งาน เป็ นช้ ินงานที่เล็กท่ีสุด • งานศึกษาความเป็ นไปไดท้ างดา้ นเทคนิค การวเิ คราะหแ์ ละออกแบบระบบ • งานศึกษาความเป็ นไปไดท้ างดา้ นเศรษฐศาสตร์ • งานศึกษาความเป็ นไปไดท้ างดา้ นการปฏบิ ตั ิงาน การวเิ คราะหแ์ ละออกแบบระบบ47 48ความตอ้ งการระบบ นักวเิ คราะหร์ ะบบ สามารถนําเครื่องมือต่างๆมา ประยุกตใ์ ชก้ บั การวเิ คราะหแ์ ละออกแบบ เรียกวา่ Methodologyขน้ั ที่ 1 การวางแผน ซ่ึงเป็ นแนวทางที่มีการนําโมเดล เคร่ืองมอื และเทคนิคต่างๆมา ใชก้ บั การพฒั นาซอฟตแ์ วรซ์ ึ่งเป็ นแนวทางในการพฒั นารายงานการศกึ ษา ข้นั ที่ 2 การวิเคราะห์ ซอฟตแ์ วรน์ ัน่ เอง เบ้ ืองตน้ การวเิ คราะหแ์ ละออกแบบระบบ เอกสารความตอ้ งการ ข้นั ท่ี 3 การออกแบบ ของระบบ การออกแบบและระบุ คุณลกั ษณะของระบบ ขน้ั ที่ 4 การพฒั นา สรา้ งระบบท่ีสมบรู ณ์ ขน้ั ที่ 5 การดาํ เนินการ ระบบสารสนเทศ 12

49 50 14/01/55 13 การวเิ คราะหแ์ ละออกแบบระบบ  โมเดล (Model)51 การวเิ คราะหแ์ ละออกแบบระบบ  โมเดล (Model) 52 ตวั อยา่ ง 1. Flowchart  เคร่อื งมือ (tools) 2. Data Flow Diagram 3. ER Diagram การวเิ คราะหแ์ ละออกแบบระบบ 4. Structure Chart 5. Use Case Diagram 6. Class Diagram 7. Sequence Diagram 8. Gantt Chart/PERT 9. โปรแกรมวิเคราะหท์ างการเงนิ NPV, ROI การวเิ คราะหแ์ ละออกแบบระบบ

14/01/5553 54  ตวั อยา่ งเคร่อื งมือ ไดแ้ ก่  เทคนิค (tools) โปรแกรมจดั การโครงการ โปรแกรมเครื่องมือช่วยวาด การวเิ คราะหแ์ ละออกแบบระบบ โปรแกรมประมวลผลคาํ เคสทูลส์ (CASE Tool) 56 โปรแกรมจดั การฐานขอ้ มลู โปรแกรมแปลงไดอะแกรมเป็ นรหสั คาํ สงั่ วิธีการพฒั นาระบบแบบด้งั เดมิ (The Traditional Approach) การวเิ คราะหแ์ ละออกแบบระบบ • เทคนิควิธีการพฒั นาระบบแบบด้งั เดิมน้ันมีเทคนิคที่หลากหลาย ซ่ึงต้งั อยบู่ น พ้ นื ฐานของการพฒั นาระบบสารสนเทศดว้ ยวธิ ีโครงสรา้ งและการโปรแกรมแบบ55 โมดลู โดยมกั เรียกวธิ ีน้ ีวา่ การพฒั นาระบบเชิงโครงสรา้ ง (Structured System Development)  ตวั อยา่ งเทคนิค ไดแ้ ก่  เทคนิคการบริหารโครงการ วิธีการพฒั นาระบบเชิงวตั ถุ (The Object-Oriented Approach)  เทคนิคการสมั ภาษณ์  เทคนิคกาสรา้ งแบบจาํ ลองขอ้ มลู • การวิเคราะหแ์ ละออกแบบระบบเชิงวตั ถุ จดั เก็บวธิ ีใหมข่ องการพฒั นาระบบ  เทคนิคการออกแบบฐานขอ้ มลู เชิงสมั พนั ธ์  เทคนิคการวเิ คราะหเ์ ชิงโครงสรา้ ง  เทคนิคการออกแบบเชิงโครงสรา้ ง  เทคนิคการเขียนโปรแกรมเชิงโครงสรา้ ง  เทคนิคการทดสอบซอฟตแ์ วร์  เทคนิคการวเิ คราะหแ์ ละออกแบบระบบเชิงวตั ถุ การวเิ คราะหแ์ ละออกแบบระบบ 14

14/01/5557 Process 1 Input Sex Calculate Grade การพฒั นาระบบเชิงโครงสรา้ ง (Structured System Development) Process 2 sex = “M” N เป็ นการพฒั นาระบบดว้ ยวธิ ีโครงสรา้ งและการโปรแกรมแบบโมดลู f=f+1 N Process 3 เทคนิคการวเิ คราะหแ์ ละออกแบบเชิงโครงสรา้ ง (Structured Analysis ก. Sequence Y End of file and Design Technique: SADT) m=m+1 Y • การวเิ คราะหเ์ ชิงโครงสรา้ ง ข. Decision Stop • การออกแบบเชิงโครงสรา้ ง ค. Repetition • การเขยี นโปรแกรมเชิงโครงสรา้ ง ตวั อยา่ งการโปรแกรมเชิงโครงสรา้ ง 58 60Module 1 Control Module Module 3 begin start begin do 1 do 2 call module 1 if x then y do 3 call module 2 else z return call module 3 do abc return stop 59 Module 2 begin do x do y do z return 15

14/01/5561 คอร์สวิชาเรียน ตารางเรียน  การกาํ หนดความตอ้ งการของระบบ ฝ่ ายวชิ าการ นักศกึ ษา  การวเิ คราะหเ์ ชิงโครงสรา้ ง ชว่ ยใหส้ ามารถกาํ หนดไดว้ า่ ระบบตอ้ งดาํ เนินการ 1 2 ใบลงทะเบียน อะไร มีขอ้ มลู ใดที่ตอ้ งจดั เก็บ มีอินพุต เอาทพ์ ุตอะไร และตอ้ งดาํ เนินการ กําหนดคอร์ส ลงทะเบียน วชิ าเรียน อยา่ งไร สามารถจาํ ลองไดด้ ว้ ยแผนภาพที่เรียกวา่ แผนภาพกระแสขอ้ มลู (Data Flow Diagram : DFD) จะแสดงใหเ้ หน็ ขอ้ มลู ท่ีไหลไป D1 ขอ้ มลู คอรส์ วชิ า กระบวนการต่างๆ D2 รายการลงทะเบยี น  นอกจากน้ ียงั มี แผนภาพอีอาร์ (Entity Relationship Diagram : ERD) จะแสดงความสมั พนั ธร์ ะหวา่ งขอ้ มลู D3 ขอ้ มลู นกั ศกึ ษา คณะวิชา รายงานการลงทะเบยี นแต่ละวชิ า 3 พิมพ์รายงาน การลงทะเบียน 62คอร์สวชิ าทเ่ี ปิ ดสอน รายการลงทะเบยี น นกั ศกึ ษา 64 course_no * std_no * std_no * name name  เป็ นการรวมขอ้ มลู และกระบวนการเขา้ ดว้ ยกนั โดยเรียกเป็ น วตั ถุ credit course_no * faculty_code (Object) เพ่ือจาํ ลองสภาพที่แทจ้ ริงของกระบวนการและการปฏิบตั ิงาน grade major_code  ผลที่ไดค้ ือ ซอฟตแ์ วรเ์ ชิงวตั ถุ สาขา คณะ faculty_code * faculty_code *  โปรแกรมเมอรส์ ามารถเขยี นโปรแกรมเชิงวตั ถุ โดยใชห้ ลกั การเชิงวตั ถุ เช่น major_code * description การสืบทอดคุณสมบตั ิ การพอ้ งรปู เป็ นตน้ description 63 16

14/01/5565 66  OOA คือวธิ ีการวิเคราะหค์ วามตอ้ งการของระบบจากรายละเอียดของ SimpleWatch คลาสและวตั ถุ ท่ีคน้ พบไดจ้ ากปัญหาที่เราสนใจ เพื่อทาํ ความเขา้ ใจ Actor รายละเอียด  OOD คือ วิธีการออกแบบกระบวนการดว้ ยการสรา้ งแบบจาํ ลองเชิงวตั ถุ ReadTime  OOI คือ การสรา้ งโปรแกรมเพื่อนําไปใชง้ านใหเ้ กิดผลดว้ ยการจดั การกลุ่ม WatchUser SetTime WatchRepairPerson ของวตั ถุต่างๆใหท้ าํ งานร่วมกนั อาจเรียกวา่ OOP ChangeBattery  ใช้ UML เป็ น Methodology Use case67 Class 68 Multiplicity Object 2 Association :WatchUser :SimpleWatch :LCDDisplay :Time PushButton SimpleWatch state push() 1 1 11 pressButton1() blinkHours() release() pressButton1() blinkMinutes() 1 21 LCDDisplay Battery Time pressButton2() blinkIdx load() now() pressButtons1And2() blinkSeconds() stopBlinking() incrementMinutes() refresh() blinkMinutes() Attributes blinkHours() commitNewTime() stopBlinking() referesh() Operations Message Activation 17

69 14/01/55  ระเบียบแบบแผนที่นํามาประยุกตใ์ ชก้ บั การซอฟตแ์ วรเ์ พื่อก่อใหเ้ กิด 70 ประสิทธิภาพต่อการพฒั นา มีกระบวนการพฒั นาซอฟตแ์ วรท์ ่ีชดั เจน และ สามารถตรวจสอบได้ นอกจากน้ ียงั มีการนําเครื่องมือสนับสนุนการพฒั นา  ขอ้ กาํ หนดซอฟตแ์ วร์ (Software Specification) ระบบมาใช้ เพื่อใหเ้ กิดมาตรฐานเดียวกนั และทาํ ใหซ้ อฟตแ์ วรม์ ีคุณภาพ  การพฒั นาซอฟตแ์ วร์ (Software Development)  การตรวจสอบความถกู ตอ้ งของซอฟตแ์ วร์ (Software Validation)  วิวฒั นาการซอฟตแ์ วร์ (Software Evolution)71 72  ถกู ตอ้ ง (Correctness)  คือ กรรมวธิ ีการพฒั นาซอฟตแ์ วรท์ ี่สามารถนํามาประยุกตใ์ ชเ้ พื่อเป็ นแนว  น่าเช่ือถือ (Reliability) ทางการพฒั นาซอฟตแ์ วรต์ ้งั แต่เริ่มตน้ โครงการจนกระทงั่ สาํ เร็จ สาํ หรบั  ใชง้ านงา่ ย (User Friendliness) โมเดลการพฒั นาซอฟตแ์ วรใ์ นปัจจุบนั ท่ีนิยมใช้ ไดแ้ ก่  บาํ รุงรกั ษางา่ ย (Maintainability)  นํากลบั มาใชใ้ หม่ได้ (Reusability) 18  คงทน (Robustness)  มีประสิทธิภาพ (Efficiency)  สะดวกในการเคล่ือนยา้ ย (Portability)  ปลอดภยั (Security/Safety)

73 14/01/55  Build-and-fix model 74  Waterfall Model  Incremental model Build  Spiral model first version  Rapid prototype model  Joint Application Development (JAD) Modify until  Relational Unified Process (RUP) client is satisfied75 Operation mode Retirement  ไม่มีกระบวนการที่แน่นอน  ผลิตภณั ฑถ์ ูกแกไ้ ขตลอดเวลา 76  ข้อดี  สรา้ งข้ นึ โดย Royce ในปี 1970 เหมาะสาํ หรับโปรแกรมขนาดเลก็  ทาํ งานทีละข้นั ตอนแต่ละข้นั ตอ้ งทาํ ใหเ้ สร็จกอ่ นจงึ จะทาํ ขน้ั ต่อไป ลกู คา้ มองเห็นและนาํ ไปใชไ้ ดเ้ ลย  แต่ละขน้ั มีการทาํ document หากไมเ่ สร็จจะไม่สามารถทาํ ขน้ั ต่อไปได้  ข้อเสีย  ผใู้ ชจ้ ะไมเ่ หน็ product จนกวา่ จะส่งมอบ คา่ ใชจ้ ่ายเพิ่มข้ึน การดูแลรักษายาก การดแู ลรักษายาก 19

77 14/01/55 Requirement Change 78 Requirement Specification/Analysis  ในระหวา่ งการพฒั นาหากพบขอ้ ผิดพลาดใด สามารถยอ้ นกลบั ไปทาํ งานใน ข้นั กอ่ นหนา้ ได้ (feedback loop) Design Implementation  การทาํ งานทุกข้นั ตอนจะสาํ เร็จตอ้ งมีเอกสารที่เสร็จสมบรู ณ์ ผ่านการ ตรวจสอบและไดร้ บั การยอมรบั Testing Operation mode มขี น้ั ตอนการทาํ งานท่ีชดั เจน และสามารถยอ้ นกลบั Retirement ไปดขู น้ั ตอนก่อนหนา้ น้ ีได้79 Requirement Incremental model  ขอ้ ดี Specification แบ่งเป็ น phase  ทุกขน้ั ตอนมีเอกสาร Design พฒั นาทีละสว่ น คอ่ ยๆเพ่ิมฟังกช์ นั ใหมเ่ ขา้ ไป  เอกสารท้งั หมดตอ้ งดแู ลรกั ษา เพ่ือใหก้ ารบาํ รุงรกั ษาระบบทาํ ไดง้ ่าย Implementation  ขอ้ เสยี - detail design  มีกระบวนการทดสอบอยทู่ า้ ยๆ - Implementation  requirement ที่ไดม้ าอาจไมใ่ ช่สิ่งท่ีลกู คา้ ตอ้ งการจริงๆ เพราะลกู คา้ ไม่เขา้ ใจ - Integration ระบบ - test  ผใู้ ชจ้ ะไมเ่ ห็น Product จนกวา่ จะส่งมอบ - สง่ มอบ  Product อาจไมใ่ ชส่ ิ่งท่ีลกู คา้ ตอ้ งการจริงๆ Operation mode 80 Retirement 20

14/01/5581 82  ขอ้ ดี  นําเสนอโดย Barry Boehm 1988  เหมาะกบั การพฒั นาซอฟตแ์ วรท์ ่ีมีขนาดใหญ่  ส่งมอบงานไดเ้ ร็ว ตรงตามความตอ้ งการของลกู คา้  ทาํ แต่ละขน้ั ตอนหลายรอบตามความตอ้ งการของผใู้ ช้  การท่ีลกู คา้ ค่อยๆไดร้ บั ผลงาน จะเป็ นการสรา้ งความคุน้ เคยกบั งานมากข้ ึน  แต่ละขน้ั ตอนตอ้ งทาํ ตน้ แบบ  การแบ่งเป็ น phase ต่างๆ จะสามารถหยุดไดโ้ ดยไมม่ ีผลกระทบอ่ืน  มีการวเิ คราะหค์ วามเส่ียงทุกขน้ั ตอน  ขอ้ เสยี  การแบง่ งานเป็ นหลายส่วนจะยากในการนํามารวมกนั  ถา้ แบง่ นอ้ ยๆส่วนจะเป็ น build and fix  ตอ้ งมีบุคคลที่มีทกั ษะท่ีสามารถมองงานท้งั หมดไดแ้ ละแบง่ เป็ นส่วนได้  มีความเสี่ยงในการนํามารวมกนั83การวเิ คราะหแ์ ละออกแบบระบบ 84 21

85 14/01/55  กาํ หนดวตั ถุประสงค์ ทางเลือก กฎ 86  วเิ คราะหค์ วามเส่ียงหาทางแกไ้ ข ทาํ ตน้ แบบ  กระบวนการเหมือน waterfall  จุดเด่น  วางแผน  มีการกาํ หนดวตั ถุประสงค์ ทางเลือก เง่ือนไขทุกขน้ั ตอน87  มีการวิเคราะหค์ วามเสี่ยงในแต่ละขน้ั ตอน  ประยุกตใ์ ชใ้ นซอฟตแ์ วรท์ ่ีมีขนาดใหญ่  ใชใ้ นกรณีที่ Requirement ไม่ชดั เจน  สรา้ ง Rapid prototype เพื่อหา Requirement ที่ตอ้ งการจริงๆ  จุดดอ้ ย เพื่อสรา้ งความมนั่ ใจระหวา่ งลกู คา้ และผพู้ ฒั นา  ในการตดั สินใจวา่ ตวั เลขเท่าไรคือความเสี่ยง แลว้ วิเคราะห์ หาทางแกไ้ ขไม่ใช่เรื่อง  ลกั ษณะ prototype ง่าย  นําขอ้ มลู ท่ีเก็บไดม้ าสรา้ งซอฟตแ์ วรแ์ บบไม่ละเอียด  ใชซ้ อฟตแ์ วรส์ เกลท่ีขนาดใหญ่ ทีมพฒั นาตอ้ งมีศกั ยภาพเพียงพอ  มีการสรา้ งหน้าจอผใู้ ช้ การป้ อนขอ้ มลู เขา้ การแสดงผลขอ้ มลู Rapid Prototype  Prototype เป็ นเทคนิคในการหา Specification Requirement Rapid prototype Change Requirement Specification Design Implementation Integration Operation mode 88 Retirement 22

89 14/01/55  ขอ้ ดี 90  ลกู คา้ เห็น Product เร็ว  การพฒั นาแอพลิเคชนั่ อยา่ งรวดเร็วโดยรวบกระบวนการท่ีสาํ คญั และใช้  ได้ Requirement ท่ีดีท่ีสุด เคร่ืองมือสนับสนุน เชน่ CASE Tools  ขอ้ เสยี  เน้นการลดตน้ ทุนและเวลา  ใชใ้ นระยะเวลาจาํ กดั  ตอ้ งมีเวลาในการสรา้ ง Prototype  ไมใ่ ชร่ ะบบสมบรู ณแ์ บบ  algorithm ไมด่ ี91 92  JAD เป็ นการพฒั นาแอพลิเคชนั่ รว่ มกนั โดยกลุ่มคนในองคก์ ร ผเู้ ช่ียวชาญ  เป็ นกระบวนการทางวิศวกรรมซอฟตแ์ วร์ ดา้ น IT เขา้ รว่ มประชุมเชิงปฏิบตั ิการ  เป็ นกรรมวธิ ีการพฒั นาซอฟตแ์ วรเ์ ชิงวตั ถุ  จุดประสงค์ คือ พฒั นาระบบงานท่ีใชเ้ วลาส้นั และมีความสมบรู ณใ์ นโครงการ  จุดประสงคเ์ พ่ือตอ้ งการสรา้ งซอฟตแ์ วรค์ ุณภาพสงู ตรงตามความตอ้ งการ ภายใตง้ บประมาณและระยะเวลาที่กาํ หนด เครื่องมือการจดั การ  เน้นกระบวนการสรา้ งโมเดลและจดั การโมเดลดว้ ยภาษา UML  RUP มี 4 ระยะ  Inception กาํ หนดขอบเขตดว้ ย Use case  Elaboration สรา้ งขอ้ กาํ หนดและแผนงานดว้ ย use case diagram, class diagram, sequence diagram  Construction พฒั นาระบบ เขียนโปรแกรม  Transition วางแผนนําไปใช้ 23

93 14/01/55 แบบจาํ ลอง (Modeling) เป็ นการนาํ เสนอแนวความคดิ หรือ 94 กระบวนการในรูปแบบของภาพ ตามท่นี กั วิเคราะหร์ ะบบทาํ การ  ระบบช่วยในการออกแบบ (Computer-Aided Systems Engineering- CASE) วิเคราะหแ์ ละออกแบบ เพอ่ื ง่ายตอ่ การทดสอบและการแกไ้ ข  เป็ นเทคนิควิธีที่ใชโ้ ปรแกรมทมี่ ีความสามารถสูงเป็ นเคร่ืองมือ ทเ่ี รยี ก ตน้ แบบ (Prototyping) จะเกี่ยวกบั การสรา้ งงานในเบ้ ืองตน้ เคสทูล (CASE Tools) เพื่อช่วยนกั วิเคราะหร์ ะบบในการพฒั นาและ บาํ รุงรกั ษาระบบสารสนเทศ ของระบบสารสนเทศและองคป์ ระกอบท่ีเกี่ยวขอ้ ง95 96  เคสทลู ส์ (Computer Aided Software Engineering: CASE Tools) เป็ น ประเภทของเคสทูลส์ ซอฟตแ์ วรท์ ่ีใชเ้ ป็ นเคร่ืองมือในการพฒั นาระบบ  Upper CASE Tools มกั จะถกู ใชใ้ นขน้ั ตอนการพฒั นาในช่วงแรกๆ  เช่น การสรา้ งโมเดล ไดอะแกรม การตรวจสอบขอ้ ผิดพลาด เช่น เก็บ requirement , การวเิ คราะห์ , การออกแบบ, การเก็บ  นอกจากน้ ีเคสทลู สย์ งั เป็ น Repository ที่เป็ นแหล่งรวมสารสนเทศที่ สารสนเทศลงในรีโพซิทอรี เช่น Visible Analyst  Lower CASE Tools มกั ถกู ใชใ้ นข้นั ตอนชว่ งหลงั เช่น การเขียน เกี่ยวขอ้ งกบั ระบบ ซึ่งทีมงานสามารถนําสารสนเทศที่เก่ียวขอ้ งมาใชง้ านได้ โปรแกรม , การตรวจสอบความถูกตอ้ ง การแปลงโมเดลเป็ นรหสั และหากมีการปรบั ปรุงแกไ้ ข จะมีการแกไ้ ขส่วนงานที่เกี่ยวขอ้ งอตั โนมตั ิ โปรแกรม เชน่ Rational Rose, TogetherSoft 24

เทคนิควิธีและเครื่องมือในการพฒั นาระบบงาน 14/01/55 เคร่ืองมืออ่ืนท่ีใชพ้ ฒั นาระบบงาน (Other Systems แบบฝึ กหดั Development Tools) • เช่น เวิรด์ โพซีดเซอร์ สเพร็ดชีส 98 • เคร่ืองมือช่วยสรา้ งภาพและซอฟทแ์ วรท์ ี่ช่วยใน การนาํ เสนอ ที่ไดร้ บั ความนิยมมากคือ วิซิโอ 1. วงจรการพฒั นาระบบคอื อะไร ประกอบด้วยระยะใดบ้าง จงอธิบาย (VISIO) 2. สรุปรายละเอยี ดของกจิ กรรมต่างๆแต่ละระยะมาพอเข้าใจ 3. การเสียเวลาจาํ นวนมากกบั การบาํ รุงรักษา ท่านคดิ ว่าเกดิ จากสาเหตใุ ด มีแนวทางแก้ปัญหานี้97 อย่างไร99 4. จงอธิบายการวเิ คราะห์ระบบ แบบเชิงวตั ถุ-เชิงโครงสร้าง 5. หากนักศึกษาต้องดาํ เนินการพฒั นาระบบสารสนเทศ นักศึกษาจะใช้วธิ ีการพฒั นาระบบแบบ 9. โมเดลใดเหมาะกบั การนาํ ไปประยกุ ตเ์ พ่ือพฒั นาระบบทีม่ ีความเส่ียงสูง 10. RAD เหมาะกบั ระบบงานแบบใด ใด ทําไม 11. อธิบายหลกั การพฒั นาซอฟตแ์ วรด์ ว้ ย JAD 6. วศิ วกรรมซอฟต์แวร์คอื อะไร 12. CASE Tools คืออะไร มีประโยชนต์ อ่ การพฒั นาระบบอยา่ งไร 7. ทําไมปัจจุบนั จงึ ใส่ใจกบั กรรมวธิ ีพฒั นาซอฟต์แวร์เพอ่ื ให้มีคณุ ภาพมากขนึ้ จงบอกคุณสมบตั ิ 13. ระบบงานหอ้ งสมดุ แห่งหนึ่งยงั คงดาํ เนินการดว้ ยมือ (Manual system) ของซอฟต์แวร์ทม่ี คี ณุ ภาพ และตอ่ มาผูบ้ ริหารมีความตอ้ งการพฒั นาระบบใหม่ดว้ ยการนาํ ระบบ 8. นักศึกษาคดิ ว่า ซอฟต์แวร์ทีม่ คี ุณภาพในโครงการซอฟต์แวร์ขนาดใหญ่ เกดิ จากความสามารถ สารสนเทศเขา้ มาใชแ้ ทนระบบงานเดมิ อยา่ งเรง่ ดว่ น เน่ืองจากมีเวลาจาํ กดั สมมตวิ ่านกั ศึกษาเป็ นหนึ่งในทีมงานพฒั นาระบบงานหอ้ งสมุด นกั ศึกษา เฉพาะตวั ของโปรแกรมเมอร์หรือเกดิ จากกระบวนการจดั การที่ดมี ากกว่าเพราะอะไร จะใชโ้ มเดลการพฒั นาซอฟตแ์ วรแ์ บบใดมาประยกุ ตใ์ ช้ เพราะเหตใุ ด การวเิ คราะหแ์ ละออกแบบระบบ 100 www.themegallery.com 25