บทที่ 4 การวิเคราะห์ระบบ

บทที่ 4การวิเคราะห์ระบบ System Analysis

การวิเคราะห์ระบบ • ความต้องการของระบบ • การกำหนดความต้องการของระบบ • ผู้ให้ข้อมูลความต้องการ • วิธีเก็บรวบรวมข้อมูล • การทบทวนข้อกำหนดความต้องการ

ความต้องการของระบบ (System Requirements) • สิ่งที่ระบบใหม่ต้องสามารถทำได้ และสิ่งที่ระบบใหม่ไม่ควรทำ • ความต้องการที่เป็นหน้าที่หลัก (Functional Requirements) • ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-functional Requirements)

ความต้องการที่เป็นหน้าที่หลัก (Functional Requirements) • ความต้องการให้ระบบทำหน้าที่ใดๆ ตามที่กำหนดไว้ได้ • สิ่งที่ระบบควรทำหน้าที่หลักในการทำงาน • บริการที่ระบบควรมี

ตัวอย่าง ระบบทะเบียน • ผู้เกี่ยวข้อง  นักศึกษา , อาจารย์ , เจ้าหน้าที่ฝ่ายทะเบียน • ความต้องการ • นักศึกษาสามารถตรวจสอบผลการเรียนและสภาพนักศึกษาได้ • นักศึกษาสามารถลงทะเบียนและทำการเพิกถอนรายวิชาได้ • อาจารย์สามารถตรวจสอบผลการเรียนของนักศึกษาในรายวิชาของตน หลังจากส่งผลการเรียนไปยังฝ่ายทะเบียนแล้ว เพื่อดูความถูกต้องได้ • อาจารย์และนักศึกษาสามารถติดตามเอกสารคำร้องต่างๆ ที่ยื่นต่อฝ่ายทะเบียนได้ • เจ้าหน้าที่ฝ่ายทะเบียนสามารถเพิ่ม ลบ และแก้ไขข้อมูลต่างๆ ในระบบตามหน้าที่ได้

ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-functional Requirements) • ไม่เกี่ยวข้องโดยตรงกับหน้าที่หลักของระบบ • อาจเป็นเงื่อนไขการทำงานของฟังก์ชันหรือบริการ • เงื่อนไขด้านเวลาที่ใช้ในการพัฒนาระบบ • เงื่อนไขในการดำเนินงาน หรือมาตรฐานที่ใช้

ความต้องการที่ไม่ใช่หน้าที่หลักความต้องการที่ไม่ใช่หน้าที่หลัก • ความต้องการด้านผลิตภัณฑ์ • สมรรถนะของระบบ • ความน่าเชื่อถือของระบบ • ความต้องการด้านการทำงานข้ามแพลตฟอร์มได้ และใช้งานง่าย • ความต้องการขององค์กร จากนโยบายและแผนปฏิบัติงาน • ความต้องการจากปัจจัยภายนอก • การทำงานร่วมกันกับระบบอื่นจากภายนอก • ระบบทำงานอยู่ภายใต้กรอบของกฎหมาย • ระบบต้องอยู่ในระดับที่ผู้ใช้และสาธารณชนยอมรับได้

การกำหนดความต้องการของระบบการกำหนดความต้องการของระบบ • System Requirement Determination • การวิเคราะห์การทำงานของระบบเดิมเพื่อหาปัญหาที่แท้จริง • นำผลการวิเคราะห์มากกำหนดเป็นความต้องการของระบบใหม่ • นำไปสร้างเป็นแบบจำลองชนิดต่างๆ เพื่อนำเสนอความต้องการ

การกำหนดความต้องการของระบบการกำหนดความต้องการของระบบ • ต้องมีการเก็บรวบรวมข้อมูลและข้อเท็จจริงของระบบเดิม • อาจใช้วิธีพบและพูดคุยกับผู้ใช้ระบบในองค์กรเพื่อให้ได้ข้อมูลที่ถูกต้อง • สิ่งที่ได้ คือ แบบฟอร์ม รายงาน รายละเอียดการทำงาน และเอกสารอื่นๆ ที่เป็นแหล่งข้อมูลขององค์กร

ประโยชน์ของการเก็บรวบรวมข้อมูล ทำให้เราทราบ • เป้าหมายขององค์กร และการดำเนินธุรกิจขององค์กร • สารสนเทศที่องค์กรต้องการ • ประเภทของข้อมูล ขนาด และจำนวนข้อมูลที่เกิดระหว่างทำงาน • ข้อมูลเกิดเมื่อใด ขั้นตอนใด ต้องส่งข้อมูลต่อไปยังขั้นตอนใด • ลำดับขั้นตอนการทำงาน • เงื่อนไขที่เกิดขึ้นระหว่างการประมวลผล • นโยบายในการปฏิบัติงาน • เหตุการณ์สำคัญที่มีผลกระทบต่อข้อมูล เกิดขึ้นเมื่อใด

ผู้ให้ข้อมูลความต้องการผู้ให้ข้อมูลความต้องการ • ผู้ใช้งานระบบ (Users) • ผู้ใช้ที่ต้องดำเนินการกับข้อมูลโดยตรง • ผู้ใช้ที่เป็นหัวหน้าฝ่ายปฏิบัติการ • ผู้ใช้ในระบบจัดการ • ผู้ใช้ในระดับผู้บริหาร • ผู้ใช้นอกองค์กร • ทีมงานด้านเทคนิค (Technical Stakeholders) ทำหน้าที่ติดตั้งและบำรุงรักษาระบบสารสนเทศ ให้ข้อมูลด้านภาษาคอมพิวเตอร์ platform ของระบบ อุปกรณ์เครือข่าย

วิธีเก็บรวบรวมข้อมูล • Information Gathering Method • กระบวนการ หรือกรรมวิธีในการเก็บรวบรวมข้อเท็จจริงทั้งหมดของระบบงานที่ต้องการพัฒนา • ความสัมพันธ์ของข้อมูลในระบบงาน • ขั้นตอนการทำงานของระบบงาน • ความต้องการของเจ้าของระบบ • ส่วนประกอบต่างๆ ที่มีความสัมพันธ์และมีผลกระทบต่อระบบงาน

วิธีการเก็บรวบรวมข้อมูลวิธีดั้งเดิมวิธีการเก็บรวบรวมข้อมูลวิธีดั้งเดิม • การศึกษาจากเอกสารเดิม (Existing Document) • แผนผังโครงสร้างขององค์กร (Organization Chart) • บันทึกภายใน (Memo) • แบบแสดงความคิดเห็นของลูกค้า • เอกสารทางบัญชี • คู่มือและเอกสารต่างๆ ของระบบสารสนเทศเดิม • รายงานสรุปแต่ละประเภท • แผนงานชนิดต่างๆ และนโยบายขององค์กร • แบบฟอร์มต่างๆ ที่มีการใช้งานจริงในแต่ละวัน • ใบเตือน

วิธีการเก็บรวบรวมข้อมูลวิธีดั้งเดิมวิธีการเก็บรวบรวมข้อมูลวิธีดั้งเดิม • การค้นคว้าข้อมูล (Research) • หน่วยงาน หรือองค์กรอื่น ที่ประสบปัญหาการดำเนินงานเช่นเดียวกัน หรือมีความต้องการตรงกัน เพื่อให้ทราบแนวทางการแก้ไข นำมาวิเคราะห์ เปรียบเทียบกับปัญหา หรือความต้องการขององค์กร เพื่อนำมาประยุกต์ใช้ • การสังเกตการณ์ (Observation) • ศึกษาดูงานจริงที่เกิดขึ้นในแต่ละวันขององค์กร • ต้องได้รับการยินยอมจากหัวหน้าหน่วยงาน • จดบันทึกข้อมูลระหว่างสังเกต • ไม่ขัดจังหวะการดำเนินงานใดๆ ของพนักงาน • ไม่สรุปข้อสันนิษฐานด้วยตนเอง

วิธีการเก็บรวบรวมข้อมูลวิธีดั้งเดิมวิธีการเก็บรวบรวมข้อมูลวิธีดั้งเดิม • การจัดทำแบบสอบถาม (Questionare) • เป็นเอกสารที่สร้างขึ้นโดยมีวัตถุประสงค์เพื่อรวบรวมข้อเท็จจริงและสารสนเทศของระบบจากผู้ตอบแบบสอบถาม • คำถามปลายเปิด (Open-end Questions) • คำถามปลายปิด (Closed-end Questions) • Multiple Choices, Multiple Chooses • Rating Questions • Ranking Questions

วิธีการเก็บรวบรวมข้อมูลวิธีดั้งเดิมวิธีการเก็บรวบรวมข้อมูลวิธีดั้งเดิม • การสัมภาษณ์ (Interview) • เก็บรวบรวมข้อมูลแบบตัวต่อตัว • นักวิเคราะห์ระบบเป็นผู้สัมภาษณ์ ผู้ใช้ระบบเป็นผู้ให้สัมภาษณ์ • การสัมภาษณ์แบบไม่มีโครงสร้าง • การสัมภาษณ์แบบมีโครงสร้าง • เทคนิคการสัมภาษณ์ • เลือกบุคคล • เตรียมการสัมภาษณ์ • ดำเนินการสัมภาษณ์

สิ่งที่ควรทำในการสัมภาษณ์สิ่งที่ควรทำในการสัมภาษณ์ • คำถามควรกระชับ เข้าใจง่าย • สุภาพและมีมารยาท • ตั้งใจฟังและควบคุมสถานการณ์ มีความอดทน • สังเกตกิริยาท่าทาง ตรวจสอบข้อมูล • ใช้ศัพท์ที่เข้าใจง่าย

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

การเก็บรวบรวมข้อมูลด้วยวิธีแบบใหม่การเก็บรวบรวมข้อมูลด้วยวิธีแบบใหม่ • Joint Application Design (JAD) • Business Process Reengineering (BPR) • Agile Methodology

Joint Application Design (JAD) • เป็นเทคนิคในการกำหนดความต้องการ – ออกแบบระบบ • เป็นการจัดการประชุมโดยมีองค์ประชุม คือ ผู้ที่มีส่วนเกี่ยวข้องโดยตรงกับระบบ • ผู้ใช้ระบบ • เจ้าข้องระบบ (ผู้จ่ายเงิน) • ผู้บริหาร • นักวิเคราะห์ระบบ • นักออกแบบ • โปรแกรมเมอร์

Joint Application Design (JAD) • JAD ช่วยในขั้นตอนการกำหนดความต้องการของระบบ • เพื่อให้การเก็บรวบรวมข้อเท็จจริงและข้อมูลต่างๆ จากหลายๆ ฝ่ายสามารถดำเนินการได้ในคราวเดียว • หากมีการใช้ CASE Tools ระหว่างการประชุม จะช่วยให้เห็นภาพของระบบได้รวดเร็ว และชัดเจน สามารถสร้าง prototype ได้หลังจากประชุมเสร็จ ทำให้ผู้เข้าร่วมประชุมเห็นภาพของระบบได้ชัดเจนขึ้น

ผู้เกี่ยวข้องกับการประชุมแบบ JAD • JAD Session Leader ผู้ดำเนินการประชุม • Users ผู้ใช้ระบบ • Manager ผู้บริหารองค์กร (ผู้ใช้ระบบ) • Sponsor ผู้สนับสนุนการเงิน • System Analyst นักวิเคราะห์ระบบและทีมงาน • Scribe ผู้จดบันทึกการประชุม (เลขานุการ) • IS Staff ทีมพัฒนาระบบในโครงการ (ด้านเทคโนโลยี)

Business Process Reengineering (BPR) • การปรับกระบวนการทางธุรกิจ เป็น การศึกษากระบวนการทางธุรกิจ เพื่อค้นหาว่ากระบวนการใดที่ต้องได้รับการปรับปรุง • การค้นหา การสร้างความเปลี่ยนแปลงแบบสุดขั้วในกระบวนการทางธุรกิจ เพื่อปรับปรุงการพัฒนาสินค้าและบริการ • รื้อธุรกิจเดิม เพื่อปรับปรุงขั้นตอนการทำงานใหม่ • เป้าหมาย คือ บรรลุวัตถุประสงค์สำคัญ ได้แก่ ลดต้นทุน เพิ่มความเร็วในการทำงาน เพิ่มคุณภาพ และได้เปรียบคู่แข่งขัน

Business Process Reengineering (BPR) • วิธีการ • ค้นหากระบวนการที่จำเป็นต้องปรับปรุง • หาวิธีนำเทคโนโลยีเข้าไปใช้

Agile Methodology • กรรมวิธีในการพัฒนาระบบที่เน้นความคล่องตัว และการมีส่วนร่วมของผู้ใช้ระบบ • ผู้ใช้ระบบตรวจสอบความถูกต้องอยู่ตลอดเวลา • มั่นใจได้ว่าระบบจะพัฒนาได้ตรงตามความต้องการของผู้ใช้จริงๆ

เทคนิคของ Agile Methodology • ให้ผู้ใช้มีส่วนร่วมอย่างต่อเนื่อง ในแต่ละรอบของการทำงาน ไม่ว่าจะเป็น ขั้น Analysis, Design, Coding, Test เพื่อให้ได้ข้อมูลที่ถูกต้องทันที (ใช้กับระบบขนาดเล็ก) • Agile Usage-centered Design เป็นเทคนิคกำหนดความต้องการคล้าย JAD คือ การให้ผู้ใช้ระบบและทีมงานมาทำงานร่วมกันในห้องประชุมเดียวกัน โดยมีผู้ควบคุมการดำเนินงาน 1 คน ซึ่งต้องเป็นผู้ที่เข้าใจในกระบวนการพัฒนาระบบเป็นอย่างดี • ใช้เทคนิค Planning Game จาก eXtreme Programming แบ่งผู้มีส่วนร่วมเป็น 2 ฝ่าย คือ ฝ่ายธุรกิจ (ผู้ใช้ระบบ) และฝ่ายพัฒนาระบบ โดยแบ่งออกเป็น 3 ระยะ คือ Exploration (สำรวจ), Commitment (มอบหมาย) , Steering (ดำเนินการ)

การทบทวนข้อกำหนดความต้องการการทบทวนข้อกำหนดความต้องการ • Walkthrough เป็นวิธีการทบทวนข้อกำหนดความต้องการ เพื่อ • ค้นหาข้อผิดพลาด • ความไม่สอดคล้อง • สิ่งที่ขาดหายไป • ปัญหาที่เกิดขึ้นในข้อกำหนดความต้องการ • Structured Walkthrough • ไม่ใช่การตรวจสอบสมรรถนะของงาน แต่ทบทวนความต้องการ

การทบทวนงานแบบ Walkthrough • การทวนสอบ (Verification) ตรวจสอบว่า ข้อกำหนดความต้องการนั้นสอดคล้องและถูกต้องหรือไม่ • การตรวจรับ (Validation) ตรวจสอบว่า ข้อกำหนดความต้องการนั้นตอบสนองความต้องการของผู้ใช้ได้อย่างครบถ้วนหรือไม่

ทีมงาน Walkthrough • นักวิเคราะห์ระบบ (Analyst) นำเสนอหรืออธิบายงานให้แก่ผู้ทบทวนงาน • ผู้ทบทวนงาน (Reviewer) ผู้บริหารหรือผู้ใช้ระบบที่ได้รับมอบหมาย • ผู้จดบันทึก (Librarian) ช่วยนักวิเคราะห์ระบบ จดบันทึกข้อผิดพลาด ความไม่สอดคล้อง สิ่งที่ขาดหายไป ปัญหาที่เกิดขึ้น และข้อแนะนำต่างๆ

ขั้นตอนการทบทวนงานแบบ Walkthrough • เตรียมตัวก่อนการ Walkthrough โดยนักวิเคราะห์ระบบกำหนดผู้ที่จะเข้าร่วมทบทวนงาน จัดเตรียมเอกสารข้อกำหนดความต้องการ และแบบจำลองต่างๆ • ดำเนินการ Walkthrough นักวิเคราะห์ระบบอธิบายงานแต่ละส่วนให้กับสมาชิกในทีมทบทวน เพื่อหาปัญหาต่างๆ โดยมี Librarian เป็นผู้จดบันทึกปัญหา และคำแนะนำต่างๆ • ติดตามผล โดยแก้ไขข้อกำหนดความต้องการที่ผิดพลาดหรือขาดหายไป หากมีความสำคัญ อาจต้องมีการ Walkthrough ซ้ำอีกครั้ง

บทที่ 4 การวิเคราะห์ระบบ