บทที่ 1 ระบบสารสนเทศ และบทบาทของนักวิเคราะห์ระบบสมัยใหม่ (Information Systems and The Role of the Modern Systems Analyst)

ความหมายของระบบ ระบบ (System) คือกลุ่มของ องค์ประกอบต่างๆ ที่มีความสัมพันธ์กัน แต่ละองค์ประกอบจะทำงานร่วมกัน เพื่อจุดประสงค์เดียวกัน

ความหมายของระบบ (ต่อ) P. 17 ความหมายของระบบ (ต่อ) ยกตัวอย่างระบบงานทางคอมพิวเตอร์ 1. ฮาร์ดแวร์ (Hardware) 2. ซอฟต์แวร์ (Software) 3. บุคลากร (Peopleware)

ภาพรวมของระบบ ระบบถูกกำหนดด้วยขอบเขต โดย ขอบเขตเหล่านี้จะประกอบด้วย องค์ประกอบต่างๆ ของระบบ ที่เรียกว่า “ระบบย่อย (Sub System)”

ภาพรวมของระบบ (ต่อ) ระบบย่อย ถือเป็นตัวแทนของระบบ โดยรวม นอกจากนี้สิ่งแวดล้อมภายนอก ก็ถือเป็นปัจจัยหนึ่งที่มีอิทธิพลและส่งผล กระทบต่อระบบได้

ภาพรวมของระบบ (ต่อ)

ภาพรวมของระบบ (ต่อ) ระบบที่ดี ต้องได้รับการออกแบบ ระบบย่อยต่างๆ ให้มีความเป็นอิสระต่อกัน มากที่สุด กล่าวคือ ควรลดจำนวนเส้นทางการ ไหลของข้อมูลระหว่างกันเท่าที่จะทำได้

ประเภทของระบบ 1. ระบบปิด (Closed System) 2. ระบบเปิด (Open System)

ระบบธุรกิจ ระบบธุรกิจส่วนใหญ่ประกอบด้วย ระบบย่อยพื้นฐานต่าง ๆ

ตัวอย่างไดอะแกรมระบบการผลิต ระบบธุรกิจ (ต่อ) ตัวอย่างไดอะแกรมระบบการผลิต

ระบบธุรกิจ (ต่อ) ภาพรวมของระบบธุรกิจจะดำเนินการ ไปได้ด้วยดี ต้องขึ้นอยู่กับระบบย่อยต่างๆ ภายในระบบดีเสียก่อน ดังนั้น เมื่อมีการศึกษาระบบงานใด จึง ควรมีการพิจารณาจากมุมมองทั้ง 4

ระบบธุรกิจ (ต่อ) มุมมองทั้ง 4 ประกอบด้วย 1. อะไร (What) P. 23 ระบบธุรกิจ (ต่อ) มุมมองทั้ง 4 ประกอบด้วย 1. อะไร (What) 2. อย่างไร (How) 3. เมื่อไร (When) 4. ใคร (Who)

องค์กรและระบบสารสนเทศ องค์กร จัดได้ว่าเป็นระบบหนึ่ง ทั้งนี้ องค์กรจะธำรงอยู่และมีผลสัมฤทธิ์ตาม เป้าหมายที่กำหนด จำเป็นอย่างยิ่งที่จะต้อง อาศัยกระบวนการบริหารที่มีประสิทธิภาพ

องค์กรและระบบสารสนเทศ (ต่อ) สภาวการณ์ในยุคปัจจุบัน ที่มีการเปิด กว้างสู่ภายนอกมากขึ้น ดังนั้น การบริหารองค์กรจึงเห็น ความสำคัญต่อ ระบบสารสนเทศ แทบ ทั้งสิ้น

ระบบสารสนเทศ ระบบสารสนเทศ เป็นกลไกชนิดหนึ่ง ที่นำเทคโนโลยีสารสนเทศมาประยุกต์ใช้ โดยเฉพาะเทคโนโลยีคอมพิวเตอร์ที่ นำมาใช้กับการจัดการข้อมูลในองค์กร

ชนิดของระบบสารสนเทศ 1. ระบบประมวลผลรายการประจำวัน P. 26 1. ระบบประมวลผลรายการประจำวัน (Transaction Processing Systems : TPS) 2. ระบบสารสนเทศเพื่อการจัดการ (Management Information Systems : MIS)

ชนิดของระบบสารสนเทศ (ต่อ) 3. ระบบสำนักงานอัตโนมัติ (Office Information Systems : OIS) 4. ระบบสนับสนุนการตัดสินใจ (Decision Support Systems : DSS)

ชนิดของระบบสารสนเทศ (ต่อ) 5. ระบบสนับสนุนผู้บริหารระดับสูง (Executive Support System : ESS) 6. ระบบผู้เชี่ยวชาญ (Expert Systems : ES)

การใช้สารสนเทศของผู้บริหารระดับต่าง ๆ ผู้บริหารแต่ละระดับ จะมีการนำ สารสนเทศไปใช้งานแตกต่างกัน โดย ระดับผู้บริหารสามารถแบ่งออกเป็น 3 ระดับด้วยกัน

1. ผู้บริหารระดับสูง เป็นระดับวางแผนระยะยาว ควบคุมนโยบาย และการวางแผนเชิงกลยุทธ์ 2. ผู้บริหารระดับกลาง เป็นระดับวางแผนระยะสั้น ด้วยการสั่งการเพื่อควบคุมจัดการตามข้อปฏิบัติตามเป้าหมายที่ผู้บริหารระดับสูงวางแผนไว้

3. ผู้บริหารระดับล่าง เป็นระดับปฏิบัติงาน ซึ่งถือเป็นเครื่องมือการทำงานของผู้บริหารระดับกลางและผู้บริหารระดับสูง และต่อมาก็คือ พนักงานปฏิบัติงาน ที่ปฏิบัติงานในหน้าที่ประจำวัน

P. 30

การตัดสินใจแบบมีโครงสร้าง =? การตัดสินใจแบบกึ่งโครงสร้าง =? การตัดสินใจแบบไม่มีโครงสร้าง =?

(System Analysis) การวิเคราะห์ระบบ การวิเคราะห์ระบบ เป็นการศึกษาถึง ปัญหาที่เกิดขึ้นในระบบงานปัจจุบัน เป้าหมายสำคัญคือ ต้องการปรับปรุงและ แก้ไขระบบงานเดิมให้มีทิศทางที่ดีขึ้น กว่าเดิม

การวิเคราะห์ระบบ (ต่อ) P. 33 การวิเคราะห์ระบบ (ต่อ) เหตุผลสำคัญที่ต้องมีการวิเคราะห์ระบบ 1. ปรับปรุงด้านการบริการ 2. เพิ่มประสิทธิภาพการทำงาน 3. เพิ่มกระบวนการควบคุมการทำงาน 4. ลดต้นทุนการดำเนินการ 5. ต้องการสารสนเทศมากขึ้น

การวิเคราะห์ระบบ (ต่อ) การวิเคราะห์ระบบ ใช่ว่าจะต้องลงท้าย ด้วยการพัฒนาระบบใหม่เสมอ นักวิเคราะห์ระบบจะต้องทำการศึกษา ถึงความเป็นไปได้ และตัดสินใจเลือก แนวทางที่เหมาะสม

การวิเคราะห์ระบบ (ต่อ) # แนวทางในการดำเนินงาน 1. ไม่ต้องดำเนินการใดๆ 2. ปรับปรุงระบบเดิมให้ดีขึ้น 3. พัฒนาระบบใหม่

นักวิเคราะห์ระบบ (System Analyst: SA) นักวิเคราะห์ระบบ เป็นผู้ที่ทำ หน้าที่ศึกษาปัญหาและความต้องการ ขององค์กร ด้วยการนำ IT เข้ามาช่วย แก้ไขปัญหา

นักวิเคราะห์ระบบ (ต่อ) การแก้ไขปัญหาในที่นี้หมายถึง การ มองปัญหาในรายละเอียดที่แท้จริง เข้าใจ รายละเอียดในทุกด้าน แล้วจึงสร้าง แนวทางต่างๆ ในการแก้ไขปัญหาเหล่านั้น ด้วยการเลือกแนวทางที่ดีและเหมาะสม ที่สุด (Best Solution)

วิเคราะห์ผิด = แก้ไขปัญหาไม่ตรงจุด นักวิเคราะห์ระบบ (ต่อ) วิเคราะห์ผิด = แก้ไขปัญหาไม่ตรงจุด สูญเสียงบประมาณ สูญเสียโอกาส สูญเสียเวลา

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

ขั้นตอนการแก้ไขปัญหา ของนักวิเคราะห์ระบบ 1. ศึกษาและทำความเข้าใจกับปัญหา 2.พิสูจน์ให้ได้ว่า แนวทางแก้ปัญหา สามารถสร้างประโยชน์และคุ้มค่า ที่จะลงทุน

ขั้นตอนการแก้ไขปัญหา ของนักวิเคราะห์ระบบ (ต่อ) 3. สร้างข้อกำหนดต่างๆ สำหรับการ แก้ไขปัญหา 4. สร้างแนวทางการแก้ไขปัญหาที่ เป็นไปได้หลายๆ แนวทาง

ขั้นตอนการแก้ไขปัญหา ของนักวิเคราะห์ระบบ (ต่อ) 5. ตัดสินใจเลือกแนวทางที่ดี และ เหมาะสมที่สุด 6. กำหนดรายละเอียดแนวทางที่เลือก 7. นำแนวทางนี้ไปใช้

ขั้นตอนการแก้ไขปัญหา ของนักวิเคราะห์ระบบ (ต่อ) 8. ติดตามผลเพื่อความมั่นใจว่าได้ ผลลัพธ์ตามที่ประสงค์

ลักษณะงานของนักวิเคราะห์ระบบ 1. วิเคราะห์ระบบเท่านั้น (Information Analysts) 2. วิเคราะห์และออกแบบระบบ (System Designers/Application Developers) 3. วิเคราะห์/ออกแบบ เขียนโปรแกรม (Programmer Analysts)

ความรู้และทักษะของ นักวิเคราะห์ระบบ 1. ทักษะและความรู้ทางเทคนิค P. 38 1. ทักษะและความรู้ทางเทคนิค 2. ทักษะและความรู้ทางธุรกิจ 3. ทักษะและความรู้ด้านคนและทีมงาน 4. ความซื่อสัตย์+จรรยาบรรณในอาชีพ

ผังโครงสร้างองค์กรกับตำแหน่งนักวิเคราะห์ระบบ P. 42 ===>

การพัฒนาระบบสารสนเทศ (Information System Development) บทที่ 2 การพัฒนาระบบสารสนเทศ (Information System Development)

วงจรการพัฒนาระบบ ระยะที่ 1: การวางแผนโครงการ ระยะที่ 2: การวิเคราะห์ (System Development Life Cycle: SDLC) ระยะที่ 1: การวางแผนโครงการ ระยะที่ 2: การวิเคราะห์ ระยะที่ 3: การออกแบบ ระยะที่ 4: การนำไปใช้ ระยะที่ 5: การบำรุงรักษา

วงจรการพัฒนาระบบ (ต่อ) ขั้นตอนตามแบบแผนของ SDLC จะ มีกรอบการทำงานที่เป็นโครงสร้างชัดเจน โดยมีลำดับกิจกรรมในแต่ละระยะที่เป็น ลำดับแน่นอน

วิธีการพัฒนาระบบ 1. การพัฒนาระบบแบบดั้งเดิม 2. การพัฒนาระบบเชิงวัตถุ

การพัฒนาระบบแบบดั้งเดิม 1. การโปรแกรมเชิงโครงสร้าง (Structured Programming) 2. การออกแบบเชิงโครงสร้าง (Structured Design)

การพัฒนาระบบเชิงวัตถุ 1. การวิเคราะห์ระบบเชิงวัตถุ (Object-Oriented Analysis : OOA) 2. การออกแบบระบบเชิงวัตถุ (Object-Oriented Design : OOD) 3. การเขียนโปรแกรมเชิงวัตถุ (Object-Oriented Programming : OOP)

(Software Engineering) วิศวกรรมซอฟต์แวร์ (Software Engineering) วิศวกรรมซอฟต์แวร์ได้เข้ามามี บทบาทสำคัญต่อกระบวนการพัฒนา ซอฟต์แวร์ เพื่อให้ซอฟต์แวร์มีมาตรฐาน และเป็นวิทยาศาสตร์มากขึ้น

กิจกรรมพื้นฐานของกระบวนการ วิศวกรรมซอฟต์แวร์ 1. ข้อกำหนดซอฟต์แวร์ (Software Specification) 2. การพัฒนาซอฟต์แวร์ (Software Development) 3. การตรวจสอบความถูกต้อง (Software Validation) 4. วิวัฒนาการของซอฟต์แวร์ (Software Evolution)

คุณสมบัติของซอฟต์แวร์ที่มีคุณภาพ P. 69 คุณสมบัติของซอฟต์แวร์ที่มีคุณภาพ 1. มีความถูกต้อง (Correctness) 2. มีความน่าเชื่อถือ (Reliability) 3. เป็นมิตรต่อผู้ใช้ (User Friendliness) 4. บำรุงรักษาง่าย (Maintainability)

คุณสมบัติของซอฟต์แวร์ที่มีคุณภาพ (ต่อ) 5. นำกลับมาใช้ใหม่ได้ (Reusability) 6. มีความคงทน (Robustness) 7. มีประสิทธิภาพ (Efficiency) 8. สะดวกในการเคลื่อนย้าย (Portability) 9. มีความปลอดภัย (Security/Safety)

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

โมเดลการพัฒนาซอฟต์แวร์ (Software Development Process Models) จัดเป็นกรรมวิธีการพัฒนาซอฟต์แวร์ (Methodology) ที่สามารถนำมา ประยุกต์ใช้เพื่อเป็นแนวทางการพัฒนา ซอฟต์แวร์ตั้งแต่เริ่มต้นจนกระทั่งสำเร็จ

โมเดลการพัฒนาซอฟต์แวร์ (ต่อ) SDLC = Methodology ?

โมเดลการพัฒนาซอฟต์แวร์ (ต่อ) โมเดลการพัฒนาซอฟต์แวร์สมัยใหม่ ตามหลักวิศวกรรมซอฟต์แวร์ มักจะผนวก ขั้นตอนหรือกระบวนการที่ทำงานใน ลักษณะ Iteration, Incremental และ Prototyping

โมเดลการพัฒนาซอฟต์แวร์ 1. Build-and-Fix Model 2. Water Fall Model 3. Incremental Model 4. Spiral Model 5. Rapid Application Development (RAD) 6. Joint Application Development (JAD) 7. Rational Unified Process (RUP)

Build and Fix Model พัฒนาแบบลองผิด ลองถูกไปเรื่อย ๆ จนกระทั่งคิดว่าพอใจ หรือว่าคิดว่าตรงกับ ความต้องการแล้ว

Water Fall Model หรือเรียกว่า โมเดลน้ำตก มีความ คล้ายคลึงกับ SDLC แต่เพิ่มคุณสมบัติ แบบ Iteration

Incremental Model เป็นโมเดลที่นำ Water Fall Model มา ปรับปรุงให้มี ประสิทธิภาพยิ่งขึ้น

Incremental Model (ต่อ)

Incremental Model (ต่อ) Verification คือตรวจสอบความถูกต้อง ตามข้อกำหนด (Specification) Validation คือการตรวจสอบผลิตภัณฑ์ ว่าตรงความต้องการของผู้ใช้งานหรือไม่

Spiral Model มีหลักการทำงานในลักษณะรอบวงกลม โดยวนจากวงในสู่วงนอก

Rapid Application Development (RAD) เป็นการพัฒนาแอปพลิเคชันแบบรวดเร็ว มีทีมงานขนาดเล็กที่มีความเชี่ยวชาญสูง

Joint Application Development (JAD) มีห้องปฏิบัติการที่ใช้ เป็นศูนย์การทำงาน เน้น การประชุม Workshop ทีมงานตระหนักใน หน้าที่ และพร้อมที่จะ ทำงานหนัก

Ration Unified Process (RUP) เป็นกรรมวิธีการพัฒนา S/W เชิงวัตถุ พื้นฐานสำคัญคือการสร้างโมเดล และการ จัดการด้วยภาษา UML

เครื่องมือสนับสนุนการพัฒนาระบบ CASE Tools เป็นเครื่องมือที่นำมาใช้ เพื่อสนับสนุนการพัฒนาระบบ ซึ่งจะช่วย ให้การพัฒนาระบบมีความรวดเร็ว มีมาตรฐาน และคุณภาพดียิ่งขึ้น

ประเภทของ CASE Tools 1. Upper CASE Tools เป็นเครื่องมือสนับสนุนการวิเคราะห์และออกแบบจำลอง (Model) 2. Lower CASE Tools เป็นเครื่องสนับสนุนการ Implement เช่น การ Generate แบบจำลองที่สร้างขึ้นมาเป็นโค้ด

Upper CASE Tools

Lower CASE Tools

Drawing Tools

(Project Planning Phase) ระยะที่ 1 การวางแผนโครงการ (Project Planning Phase)

การศึกษาความเป็นไปได้ (Problem Definition and Feasibility Study) บทที่ 3 การกำหนดปัญหาและ การศึกษาความเป็นไปได้ (Problem Definition and Feasibility Study)

ระยะที่ 1: การวางแผนโครงการ (Project Planning Phase) เป็นกระบวนการพื้นฐานบนความ เข้าใจอย่างถ่องแท้ว่า... ทำไม! ต้องสร้างระบบใหม่

ปัจจัย/แรงผลักดันที่ส่งผลต่อความ ต้องการเพื่อพัฒนาระบบใหม่ P. 94 ปัจจัย/แรงผลักดันที่ส่งผลต่อความ ต้องการเพื่อพัฒนาระบบใหม่ 1. ผู้ใช้งานร้องขอ 2. ผู้บริหารระดับสูงต้องการ 3. ปัญหา/ข้อผิดพลาดของระบบงานปัจจุบัน 4. แรงผลักดันจากภายนอก 5. ส่วนงานพัฒนาระบบแนะนำ

แบบฟอร์มคำร้องขอระบบ (System Request)

เมื่อมีความต้องการปรับปรุง ระบบงาน จึงถือเป็นจุดเริ่มต้นใน บทบาทของตัวนักวิเคราะห์ระบบ

การกำหนดปัญหา (Problem Definition) ปัญหาที่เกิดขึ้นจากการดำเนินงานทาง ธุรกิจถือว่าเป็นเรื่องราวปกติ ซึ่งมีทั้งปัญหา เล็กน้อย จนถึงปัญหาระดับใหญ่

การกำหนดปัญหา (ต่อ) ทั้งปัญหาเล็กน้อย กับปัญหาใหญ่ ล้วน ต้องได้รับการแก้ไข เพราะหากไม่ได้รับ การปรับปรุงแก้ไข ปัญหาดังกล่าวอาจ สะสมพอกพูนจนธุรกิจได้รับผลกระทบ หรือล่มสลายได้

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

การกำหนดปัญหา (ต่อ) แต่ทั้งนี้ ปัญหาจะลุล่วงไปได้ ต้องได้รับ ความร่วมมือจากพนักงานภายในองค์กร

การกำหนดปัญหา (ต่อ) P. 97 หลักการแก้ไขปัญหาที่ดี นักวิเคราะห์ ระบบควรมีการกำหนดหัวข้อของปัญหา และหาสาเหตุของปัญหาให้ได้ก่อน โดยสามารถใช้แผนภูมิก้างปลา หรือ Cause-and-Effect Diagram มาประยุกต์ใช้

แผนภูมิก้างปลาที่แสดงถึงปัญหาและสาเหตุของปัญหาในระบบศูนย์บริการรถเช่าแห่งหนึ่ง

Problem Statement: (ชื่อระบบงาน) ชื่อบริษัท Problem Statement: (ชื่อระบบงาน) รายละเอียดของปัญหา xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx วัตถุประสงค์ ขอบเขตของระบบ ประโยชน์ที่คาดว่าจะได้รับ ความสามารถของระบบ Problem Statement (ดูตัวอย่างหน้า 100)

การศึกษาความเป็นไปได้ (Feasibility Study) เป็นการค้นหาข้อสรุป และขอบเขตของ ปัญหา โดยมี 3 ประเด็นหลัก ๆ คือ 1. ความเป็นไปได้ทางด้านเทคนิค 2. ความเป็นไปได้ทางด้านเศรษฐศาสตร์ 3. ความเป็นไปได้ทางการปฏิบัติงาน

(Feasibility Study)

ความเป็นไปได้ทางด้านเทคนิค (Technical Feasibility) ต้องตอบคำถามตัวเองให้ได้ว่า “Can we build it”

ความเป็นไปได้ทางด้านเทคนิค (ต่อ) จะถูกพิจารณาในอันดับแรก ควร วิเคราะห์ความสามารถของทีมงานว่ามี ความเชี่ยวชาญพอที่จะนำเทคนิค และ เทคโนโลยีที่มีอยู่มาใช้งานได้หรือไม่

ความเป็นไปได้ทางด้านเทคนิค (ต่อ) P. 101 1. ต้องจัดหาอุปกรณ์ใหม่หรือไม่ 2. อุปกรณ์ที่จัดหามา รองรับงานในอนาคตได้ ? 3. อุปกรณ์มีความเข้ากันได้หรือไม่ 4. อุปกรณ์ H/W และ S/W มีประสิทธิภาพดี ? 5. ระบบรองรับการขยายตัวในอนาคตหรือไม่

ความเป็นไปได้ทางเศรษฐศาสตร์ (Economic Feasibility) เกี่ยวข้องกับการคำนวณต้นทุนและ ผลตอบแทนที่ได้จากโครงการ ด้วยการ กำหนดมูลค่า และวิเคราะห์กระแสเงินสด

ความเป็นไปได้ทางเศรษฐศาสตร์ (ต่อ) โดยสามารถประเมินจากผลกระทบทาง การเงิน 4 ประเภทด้วยกัน คือ 1. ต้นทุนการพัฒนาระบบ 2. ต้นทุนการปฏิบัติงาน 3. ผลตอบแทนที่สามารถประเมินค่าได้ 4. ผลตอบแทนที่ไม่สามารถประเมินค่าได้

ความเป็นไปได้ทางเศรษฐศาสตร์ (ต่อ) ตัวอย่างการกำหนดมูลค่าต้นทุน และผลตอบแทน หน้า 103 ตัวอย่างการวิเคราะห์กระแสเงินสด หน้า 105 ตัวอย่างการวิเคราะห์ระยะเวลาคืนทุน หน้า 106

ความเป็นไปได้ทางปฏิบัติงาน (Operational Feasibility) คือความเป็นไปได้ของระบบใหม่ที่สามารถนำเสนอสารสนเทศได้อย่างถูกต้อง และตรงตามความต้องการของผู้ใช้ การยอมรับระบบงานใหม่จากผู้ใช้งาน ที่เปลี่ยนแปลงไปจากระบบงานเดิม

ความเป็นไปได้ทางปฏิบัติงาน (Operational Feasibility) ระบบใหม่จะต้องสนับสนุนยุทธศาสตร์ องค์กร 3 ด้านด้วยกัน คือ 1. ด้านผลผลิต (Productivity) 2. ด้านความแตกต่าง (Differentiation) 3. ด้านการจัดการ (Management)

การจัดทำ Proposal หลังจากที่ SA ได้ศึกษาความเป็นไปได้แล้ว ขั้นตอนต่อไปก็คือ การจัดทำ Proposal เพื่อยืนยันผลการศึกษาความเป็นไปได้ของโครงการให้กับผู้บริหารระดับสูง

Proposal ไม่มีแบบฟอร์มชัดเจนตายตัว แต่ขอให้ประกอบด้วยสิ่งสำคัญต่าง ๆ ดังนี้ 1.หน้าปก 2. สารบัญ 3.บทสรุปถึงผู้บริหาร 4. สรุปปัญหา 5. แนวทางศึกษา 6. วิเคราะห์ 7. แนวทางแก้ปัญหา 8. ข้อเสนอแนะ 9. แผนงาน 10. ภาคผนวก

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

การวางแผนและควบคุมกิจกรรม การวางแผน (Planning) เป็นการวางแผนงานที่ประกอบด้วยกิจกรรมต่างๆ ที่ได้มอบหมายและแจกจ่ายงานให้กับทีมงาน การคาดคะเนเวลาที่ต้องใช้กับงานใดๆ เพื่อให้งานนั้นสำเร็จลุล่วงตามเวลาที่กำหนด

การวางแผนและควบคุมกิจกรรม (ต่อ) การควบคุม (Control) เป็นการตรวจสอบผลสะท้อนในโครงการที่ได้วางแผนไว้ กับการปฏิบัติงานจริงของทีมงาน โดยผู้จัดการโครงการจะต้องควบคุมให้ทีมงานทำงานตามแผน ที่ได้กำหนดไว้ ซึ่งรวมถึงการสร้างแรงจูงใจ

Gantt Charts

PERT ตัวอย่าง P.113 - 121

สรุปกิจกรรมของระยะ การวางแผนโครงการ 1. กำหนดปัญหา (Problem Definition) 2. ศึกษาความเป็นไปได้ (Feasibility Study) 3. กำหนดเวลาโครงการ (Project Scheduling) 4. จัดตั้งทีมงาน (Staff the Project) 5. ดำเนินการโครงการ (Launch the Project)

ระยะที่ 2 การวิเคราะห์ (Analysis Phase)

การรวบรวมความต้องการ (Requirements Gathering) บทที่ 4 การรวบรวมความต้องการ (Requirements Gathering)

การวิเคราะห์ (Analysis Phase) ระยะที่ 2: การวิเคราะห์ (Analysis Phase) ต้องตอบโจทย์ให้ได้ว่า... ใคร ? คือผู้ใช้ระบบ มีอะไรบ้าง ? ที่ระบบต้องดำเนินการ

ระยะที่ 2: การวิเคราะห์ (ต่อ) วัตถุประสงค์หลักของระยะการ วิเคราะห์ก็คือ จะต้องศึกษาและทำความ เข้าใจในความต้องการต่างๆ ที่ได้ รวบรวมมา

ระยะที่ 2: การวิเคราะห์ (ต่อ) P. 130 กิจกรรมสำคัญของระยะนี้คือ 1. ทำความเข้าใจกับระบบงานเดิม 2. กำหนดสิ่งที่ต้องการปรับปรุง/เพิ่มเติม 3. พัฒนาแนวความคิดของระบบใหม่

การรวบรวมความต้องการ (Requirements Gathering) SA. มีความจำเป็นต้องรู้ถึงสิ่งเหล่านี้ Who? When? Where? Why? How? What?

การรวบรวมความต้องการ (ต่อ) ยูสเซอร์ เป็นบุคคลที่ SA. จะต้องเข้าไป ขอข้อมูลเพื่อทราบถึงปัญหา เพื่อนำมา ประกอบการวิเคราะห์ระบบ

การรวบรวมความต้องการ (ต่อ) ดังนั้น จึงต้องทำความเข้าใจกับยูสเซอร์ เพื่อให้ทราบถึงเป้าหมายหลัก ที่ต้องการ ทราบถึงปัญหา เพื่อนำไปพัฒนาระบบให้ดี ยิ่งขึ้นกว่าเดิม

การรวบรวมความต้องการ (ต่อ) การได้รับความร่วมมือที่ดีจากยูสเซอร์ ย่อมส่งผลดี เนื่องจากยูสเซอร์เป็นผู้ที่ปฏิบัติ กับระบบโดยตรง ทำให้ทราบปัญหาต่าง ๆ ได้ดี

คุณสมบัติของยูสเซอร์ที่ดี 1. สามารถอธิบายขั้นตอนการทำงาน ของระบบปัจจุบันที่ดำเนินงานอยู่ได้ 2. สามารถชี้แจงปัญหาต่าง ๆ ที่เกิดขึ้น ในระบบได้

คุณสมบัติของยูสเซอร์ที่ดี (ต่อ) 3. สามารถระบุความต้องในระบบใหม่ได้ 4. ควรจัดเตรียมเอกสาร หรือรายงานที่ เกี่ยวข้องให้แก่นักวิเคราะห์ระบบ

คุณสมบัติของยูสเซอร์ที่ดี (ต่อ) 5. ควรให้ความร่วมมือกับ SA. รวมถึงมี ความปรารถนาดีต่อการปรับปรุงระบบ งานเดิมที่ดำเนินการอยู่ให้มีทิศทางที่ดี ยิ่งขึ้นกว่าเดิม โดยปราศจากอคติ

คุณสมบัติของยูสเซอร์ที่ดี (ต่อ) 6. ควรมีส่วนร่วมต่อโครงการพัฒนา ระบบใหม่ รวมถึงสามารถเสนอแนะ แนวทางการแก้ไขปัญหาแก่ SA. ได้

บุคคลที่มีส่วนร่วมต่อโครงการพัฒนาระบบใหม่ (Stakeholder)

ชนิดของความต้องการ 1. Functional Requirements P. 134 1. Functional Requirements เกี่ยวข้องกับขั้นตอนการทำงานที่ประกอบไปด้วยกิจกรรมต่าง ๆ ที่เกี่ยวข้องกับผู้ปฏิบัติงาน

เทคนิคการรวบรวมความต้องการ (ต่อ) 4. การแจกแบบสอบถาม 5. การวางแผนความต้องการร่วมกัน (JAD)

SA. จะนำความต้องการ(Requirements) ของยูสเซอร์มาวิเคราะห์ เพื่อสรุปเป็น ข้อกำหนดลงในเอกสารที่เรียกว่า Requirements Specification

ตัวอย่าง User Requirements หน้า 137 ตัวอย่าง Requirements Specification หน้า 139

แบบฟอร์มมาตรฐานของ Requirements Specification

ความสำคัญของระยะการวิเคราะห์ คือ ต้องวิเคราะห์ถึงความต้องการที่ แท้จริง เพื่อนำไปสู่การแก้ไขปัญหา ได้ตรงจุด

สรุปกิจกรรมของระยะการวิเคราะห์ 1. วิเคราะห์ระบบงานปัจจุบัน 2. รวบรวมความต้องการและนำมา วิเคราะห์สรุปเป็นข้อกำหนดที่ชัดเจน 3. นำข้อกำหนดมาพัฒนาเป็นความ ต้องการของระบบใหม่

สรุปกิจกรรมของระยะการวิเคราะห์ (ต่อ) 4. สร้างแบบจำลองกระบวนการ (บทที่ 5) (Data Flow Diagram: DFD) 5. สร้างแบบจำลองข้อมูล (บทที่ 6) (Entity Relationship Diagram: ERD)