ระบบเบรค ABS ใช้ CPU 8 bit 4 ตัวใช้ควบคุมตัวละล้อ
Anti-Lock Break System - ระบบเบรกป้องกันล้อล็อก
ระบบเบรกป้องกันล้อล็อก (อังกฤษ: anti-lock braking system; ตัวย่อ: ABS) เป็นระบบความปลอดภัยซึ่งป้องกันปัญหาการลื่นไถลในขณะเบรก โดยมิให้ล้อของยานยนต์เกิดการล็อกหรือหยุดหมุนระหว่างการเบรก
ล้อสำหรับแล่นบนถนนมีประโยชน์ช่วยให้ผู้ขับยังคงสามารถบังคับพวงมาลัยของรถได้ภายใต้การเบรกอย่างแรง โดยการป้องกันการลื่นไถลและทำให้ล้อรถลากไปกับพื้นถนนตามการบังคับของผู้ขับ ในขณะที่ระบบเบรกเอบีเอสช่วยเพิ่มการควบคุมยานพาหนะ และอาจช่วยลดระยะการเบรกได้บนพื้นผิวที่แห้งและมีความลื่นอย่างมาก แต่มันก็อาจส่งผลเพิ่มระยะการเบรกในพื้นผิวที่ร่วนซุย เช่น พื้นหิมะหรือกรวด[1]
นับตั้งแต่การใช้งานอย่างแพร่หลายในช่วงแรกในรถยนต์ ระบบเบรกป้องกันล้อล็อกได้มีการพัฒนาอย่างมาก รุ่นของระบบเบรกสมัยใหม่ไม่เพียงแต่ป้องกันล้อล็อกระหว่างการเบรกเท่านั้น แต่ยังรวมไปถึงการควบคุมแบบอิเล็กทรอนิกส์ของเบรกเอียงจากหน้าไปหลัง ฟังก์ชันดังกล่าว ขึ้นอยู่กับขีดความสามารถและการพัฒนา เป็นที่รู้จักกันว่า ระบบกระจายแรงเบรกอิเล็กทรอนิกส์ (EDB)
What is Embedded System?
ระบบฝังตัว หรือ สมองกลฝังตัว (embedded system) คือระบบประมวลผล ที่ใช้ชิปหรือไมโครโพรเซสเซอร์ที่ออกแบบมาโดยเฉพาะ เป็นระบบคอมพิวเตอร์ขนาดจิ๋วที่ฝังไว้ในอุปกรณ์ เครื่องใช้ไฟฟ้า และเครื่องเล่นอิเล็กทรอนิกส์ต่างๆ เพื่อเพิ่มความฉลาด ความสามารถให้กับอุปกรณ์เหล่านั้นผ่านซอฟต์แวร์ซึ่งต่างจากระบบประมวลผลที่เครื่องคอมพิวเตอร์ทั่วไป ระบบฝังตัวถูกนำมาใช้กันอย่างแพร่หลายในยานพาหนะ เครื่องใช้ไฟฟ้าในบ้านและสำนักงาน อุปกรณ์อิเล็กทรอนิกส์ เทคโนโลยีซอฟต์แวร์ เทคโนโลยีฮาร์ดแวร์ เทคโนโลยีเครือข่ายเน็ตเวิร์ก เทคโนโลยีด้านการสื่อสาร เทคโนโลยีเครื่องกลและของเล่นต่าง ๆ คำว่าระบบฝังตัวเกิดจาก การที่ระบบนี้เป็นระบบประมวลผลเช่นเดียวกับระบบคอมพิวเตอร์ แต่ว่าระบบนี้จะฝังตัวลงในอุปกรณ์อื่น ๆ ที่ไม่ใช่เครื่องคอมพิวเตอร์ ในปัจจุบันระบบสมองกลฝังตัวได้มีการพัฒนามากขึ้น โดยในระบบสมองกลฝังตัวอาจจะประกอบไปด้วยไมโครคอนโทรลเลอร์ หรือ ไมโครโปรเซสเซอร์ อุปกรณ์ที่ใช้ระบบสมองกลฝังตัวที่เห็นได้ชัดเช่นโทรศัพท์มือถือ และในระบบสมองกลฝังตัวยังมีการใส่ระบบปฏิบัติการต่างๆแตกต่างกันไปอีกด้วย ดังนั้น ระบบสมองกลฝังตัวอาจจะทำงานได้ตั้งแต่ควบคุมหลอดไฟจนไปถึงใช้ในยานอวกาศ
Product Life Cycle
- Product Definition : ข้อสรุปในการทำโปรดัค การผลิตจำนวนมากเพื่อลดต้นทุนต่างๆ และมีมาตรฐานของผลิตที่เท่ากันทั้งหมด หรือเกือบทั้งหมด
- Design : การออกแบบ การทำตัวต้นแบบ
- Initial Production : การตรวจงาน
- Sustained Production : ทบทวนโปเจ็คเก่าอาจจะลดการผลิตลง เพื่อเตรียมการทำโปรเจ็คใหม่
- End of Life : เลิกการผลิตงานเก่า
System Development Life Cycle
จุดกำเนิดของระบบงาน
จุดกำเนิดของระบบงานโดยปกติจะกำเนิดขึ้นจากผู้ใช้ระบบ เนื่องจากผู้ใช้ระบบเป็นผู้ใกล้ชิดกับกิจกรรมของธุรกิจมากที่สุด ดังนั้นกิจกรรมทางธุรกิจได้ดำเนินไปอย่างต่อเนื่องนั้น ความต้องการที่จะพัฒนาปรับปรุงกิจการต่างๆย่อมเกิดขึ้น นักวิเคราะห์ระบบจึงเริ่มเข้ามามีบทบาทในการพัฒนาปรับปรุงแก้ไขระบบงาน
James Wetherbe ได้แต่งหนังสือออกมาเล่มหนึ่งในปี 2527 โดยใช้ชื่อว่า “System Analysis and Design: Traditional, Structured and Advanced Concepts and Techniques.”โดยให้แนวความคิดในการแจกแจงกลุ่มของปัญหาออกเป็น 6 หัวข้อตามความต้องการของผู้ใช้ ซึ่งแทนด้วยอักษร 6 ตัวคือ PIECES อ่านว่า “พีซ-เซส” โดยมีรายละเอียดดังนี้คือ
1. Performance หมายถึงความต้องการที่จะให้มีการปรับปรุงทางด้านการปฎิบัติงาน
2. Information หมายถึงความต้องการที่จะให้มีการปรับปรุงและควบคุมทางด้านข้อมูล
3. Economics หมายถึงความต้องการที่จะให้มีการปรับปรุงและควบคุมทางด้านต้นทุน
4. Control หมายถึงความต้องการที่จะให้มีการปรับปรุงระบบงานข้อมูล เพื่อให้มีการควบคุมและระบบรักษาความปลอดภัยที่ดียิ่งขึ้น
5. Efficiency หมายถึงความต้องการที่จะให้มีการปรับปรุงประสิทธิภาพของคนและเครื่องจักร
6. service หมายถึงความต้องการที่จะให้มีการปรับปรุงการบริการต่างๆ ให้ดีขึ้น เช่น การบริการลูกค้าหรือการให้บริการต่อพนักงานภายในธุรกิจเองเป็นต้น
ในแต่ละโครงการของระบบงานข้อมูลนั้น จะมีลักษณะที่จะตอบสนองความต้องการที่ได้ระบุอยู่ในพีซเซสอันใดอันหนึ่งหรือมากกว่าหนึ่งก็ได้ ดังนั้นพีซเซสจึงมีความสำคัญต่อนักวิเคราะห์ระบบในการใช้ เพื่อพิจารณาถึงปัญหาและความต้องการของผู้ใช้อย่างมีหลักเกณฑ์
วงจรการพัฒนาระบบ (System Development Life Cycle :SDLC)
ระบบสารสนเทศทั้งหลายมีวงจรชีวิตที่เหมือนกันตั้งแต่เกิดจนตายวงจรนี้จะเป็นขั้นตอน ที่เป็นลำดับตั้งแต่ต้นจนเสร็จเรียบร้อย เป็นระบบที่ใช้งานได้ ซึ่งนักวิเคราะห์ระบบต้องทำความเข้าใจให้ดีว่าในแต่ละขั้นตอนจะต้องทำอะไร และทำอย่างไร ขั้นตอนการพัฒนาระบบมีอยู่ด้วยกัน 7 ขั้น ด้วยกัน คือ
1. เข้าใจปัญหา (Problem Recognition)
2. ศึกษาความเป็นไปได้ (Feasibility Study)
3. วิเคราะห์ (Analysis)
4. ออกแบบ (Design)
5. สร้างหรือพัฒนาระบบ (Construction)
6. การปรับเปลี่ยน (Conversion)
7. บำรุงรักษา (Maintenance)
ขั้นที่ 1 : เข้าใจปัญหา (Problem Recognition)
ระบบสารสนเทศจะเกิดขึ้นได้ก็ต่อเมื่อผู้บริหารหรือผู้ใช้ตระหนักว่า ต้องการระบบสารสนเทศหรือระบบจัดการเดิม ได้แก่ระบบเอกสารในตู้เอกสาร ไม่มีประสิทธิภาพเพียงพอที่ตอบสนองความต้องการในปัจจุบัน
ปัจจุบันผู้บริหารตื่นตัวกันมากที่จะให้มีการพัฒนาระบบสารสนเทศมาใช้ในหน่วยงานของตน ในงานธุรกิจ อุตสาหกรรม หรือใช้ในการผลิต ตัวอย่างเช่น บริษัทของเรา จำกัด ติดต่อซื้อสินค้าจากผู้ขายหลายบริษัท ซึ่งบริษัทของเราจะมีระบบ MIS ที่เก็บข้อมูลเกี่ยวกับหนี้สินที่บริษัทขอเราติดค้างผู้ขายอยู่ แต่ระบบเก็บข้อมูลผู้ขายได้เพียง 1,000 รายเท่านั้น แต่ปัจจุบันผู้ขายมีระบบเก็บข้อมูลถึง 900 ราย และอนาคตอันใกล้นี้จะเกิน 1,000 ราย ดังนั้นฝ่ายบริหารจึงเรียกนักวิเคราะห์ระบบเข้ามาศึกษา แก้ไขระบบงาน
ปัญหาที่สำคัญของระบบสารสนเทศในปัจจุบัน คือ ระบบเขียนมานานแล้ว ส่วนใหญ่เขียนมาเพื่อติดตามเรื่องการเงิน ไม่ได้มีจุดประสงค์เพื่อให้ข้อมูลข่าวสารในการตัดสินใจ แต่ปัจจุบันฝ่าย บริหารต้องการดูสถิติการขายเพื่อใช้ในการคาดคะเนในอนาคต หรือความต้องการอื่นๆ เช่น สินค้าที่มียอดขายสูง หรือสินค้าที่ลูกค้าต้องการสูง หรือการแยกประเภทสินค้าต่างๆที่ทำได้ไม่ง่ายนัก
การที่จะแก้ไขระบบเดิมที่มีอยู่แล้วไม่ใช่เรื่องที่ง่ายนัก หรือแม้แต่การสร้างระบบใหม่ ดังนั้นควรจะมีการศึกษาเสียก่อนว่า ความต้องการของเราเพียงพอที่เป็นไปได้หรือไม่ ได้แก่ "การศึกษาความเป็นไปได้" (Feasibility Study)
สรุป ขั้นตอนที่ 1: เข้าใจปัญหา
หน้าที่ : ตระหนักว่ามีปัญหาในระบบ
ผลลัพธ์ : อนุมัติการศึกษาความเป็นไปได้
เครื่องมือ : ไม่มี
บุคลากรและหน้าที่ความรับผิดชอบ : ผู้ใช้หรือผู้บริหารชี้แจงปัญหาต่อนักวิเคราะห์ระบบ
ขั้นตอนที่ 2 : ศึกษาความเป็นไปได้ (Feasibility Study)
จุดประสงค์ของการศึกษาความเป็นไปได้ก็คือ การกำหนดว่าปัญหาคืออะไรและตัดสินใจว่าการพัฒนาสร้างระบบสารสนเทศ หรือการแก้ไขระบบสารสนเทศเดิมมีความเป็นไปได้หรือไม่โดยเสียค่าใช้จ่ายและเวลาน้อยที่สุด และได้ผลเป็นที่น่าพอใจ
ปัญหาต่อไปคือ นักวิเคราะห์ระบบจะต้องกำหนดให้ได้ว่าการแก้ไขปัญหาดังกล่าวมีความเป็นไปได้ทางเทคนิคและบุคลากร ปัญหาทางเทคนิคก็จะเกี่ยวข้องกับเรื่องคอมพิวเตอร์ และเครื่องมือเก่าๆถ้ามี รวมทั้งเครื่องคอมพิวเตอร์ซอฟต์แวร์ด้วย ตัวอย่างคือ คอมพิวเตอร์ที่ใช้อยู่ในบริษัทเพียงพอหรือไม่ คอมพิวเตอร์อาจจะมีเนื้อที่ของฮาร์ดดิสก์ไม่เพียงพอ รวมทั้งซอฟต์แวร์ ว่าอาจจะต้องซื้อใหม่ หรือพัฒนาขึ้นใหม่ เป็นต้น ความเป็นไปได้ทางด้านบุคลากร คือ บริษัทมีบุคคลที่เหมาะสมที่จะพัฒนาและติดตั้งระบบเพียงพอหรือไม่ ถ้าไม่มีจะหาได้หรือไม่ จากที่ใด เป็นต้น นอกจากนั้นควรจะให้ความสนใจว่าผู้ใช้ระบบมีความคิดเห็นอย่างไรกับการเปลี่ยนแปลง รวมทั้งความเห็นของผู้บริหารด้วย
สุดท้ายนักวิเคราะห์ระบบต้องวิเคราะห์ได้ว่า ความเป็นไปได้เรื่องค่าใช้จ่าย รวมทั้งเวลาที่ ใช้ในการพัฒนาระบบ และที่สำคัญคือ ผลประโยชน์ที่จะได้รับ เรื่องเวลาเป็นสิ่งสำคัญ เช่น การเปลี่ยนแปลงระบบเพื่อรองรับผู้ขายให้ได้มากกว่า 1,000 บริษัทนั้น ควรใช้เวลาไม่เกิน 1 ปี ตั้งแต่เริ่มต้นจนใช้งานได้ ค่าใช้จ่ายเริ่มตั้งแต่พัฒนาจนถึงใช้งานได้จริงได้แก่ เงินเดือน เครื่องมือ อุปกรณ์ ต่างๆ เป็นต้น พูดถึงเรื่องผลประโยชน์ที่ได้รับอาจมองเห็นได้ไม่ง่ายนัก แต่นักวิเคราะห์ระบบควรมองและตีออกมาในรูปเงินให้ได้ เช่น เมื่อนำระบบใหม่เข้ามาใช้อาจจะทำให้ ค่าใช้จ่ายบุคลากรลดลง หรือกำไรเพิ่มมากขึ้น เช่น ทำให้ยอดขายเพิ่มมากขึ้น เนื่องจากผู้บริหารมีข้อมูลพร้อมที่จะช่วยในการตัดสินใจที่ดีขึ้น
การคาดคะเนทั้งหลายเป็นไปอย่างหยาบๆ เราไม่สามารถหาตัวเลขที่แน่นอนตายตัวได้เนื่องจากทั้งหมดยังไม่ได้เกิดขึ้นจริง หลังจากเตรียมตัวเลขเรียบร้อยแล้ว นักวิเคราะห์ระบบก็นำตัวเลข ค่าใช้จ่ายและผลประโยชน์ (Cost-Benefit) มาเปรียบเทียบกัน
สรุปขั้นตอนที่ 2 : การศึกษาความเป็นไปได้ (Feasibility Study)
หน้าที่ : กำหนดปัญหา และศึกษาว่าเป็นไปได้หรือไม่ที่จะเปลี่ยนแปลงระบบ
ผลลัพธ์ : รายงานความเป็นไปได้
เครื่องมือ : เก็บรวบรวมข้อมูลของระบบและคาดคะเนความต้องการของระบบ
บุคลากรและหน้าที่ความรับผิดชอบ : ผู้ใช้จะมีบทบาทสำคัญในการศึกษา
1. นักวิเคราะห์ระบบจะเก็บรวบรวมข้อมูลทั้งหมดที่จำเป็นทั้งหมดเกี่ยวกับปัญหา
2. นักวิเคราะห์ระบบคาดคะเนความต้องการของระบบและแนวทางการแก้ปัญหา
3. นักวิเคราะห์ระบบ กำหนดความต้องการที่แน่ชัดซึ่งจะใช้สำหรับขั้นตอนการวิเคราะห์ต่อไป
4. ผู้บริหารตัดสินใจว่าจะดำเนินโครงการต่อไปหรือไม่
ขั้นตอนที่ 3 การวิเคราะห์ (Analysis)
เริ่มเข้าสู่การวิเคราะห์ระบบ การวิเคราะห์ระบบเริ่มตั้งแต่การศึกษาระบบการทำงานของธุรกิจนั้น ในกรณีที่ระบบเราศึกษานั้นเป็นระบบสารสนเทศอยู่แล้วจะต้องศึกษาว่าทำงานอย่างไร เพราะเป็นการยากที่จะออกแบบระบบใหม่โดยที่ไม่ทราบว่าระบบเดิมทำงานอย่างไร หรือธุรกิจดำเนินการอย่างไร หลังจากนั้นกำหนดความต้องการของระบบใหม่ ซึ่งนักวิเคราะห์ระบบจะต้องใช้เทคนิคในการเก็บข้อมูล (Fact-Gathering Techniques) ดังรูป ได้แก่ ศึกษาเอกสารที่มีอยู่ ตรวจสอบวิธีการทำงานในปัจจุบัน สัมภาษณ์ผู้ใช้และผู้จัดการที่มีส่วนเกี่ยวข้องกับระบบ เอกสารที่มีอยู่ได้แก่ คู่มือการใช้งาน แผนผังใช้งานขององค์กร รายงานต่างๆที่หมุนเวียนใน ระบบการศึกษาวิธีการทำงานในปัจจุบันจะทำให้นักวิเคราะห์ระบบรู้ว่าระบบจริงๆทำงานอย่างไร ซึ่งบางครั้งค้นพบข้อผิดพลาดได้ ตัวอย่าง เช่น เมื่อบริษัทได้รับใบเรียกเก็บเงินจะมีขั้นตอนอย่างไรในการจ่ายเงิน ขั้นตอนที่เสมียนป้อนใบเรียกเก็บเงินอย่างไร เฝ้าสังเกตการทำงานของผู้เกี่ยวข้อง เพื่อให้เข้าใจและเห็นจริงๆ ว่าขั้นตอนการทำงานเป็นอย่างไร ซึ่งจะทำให้นักวิเคราะห์ระบบค้นพบจุดสำคัญของระบบว่าอยู่ที่ใด
การสัมภาษณ์เป็นศิลปะอย่างหนึ่งที่นักวิเคราะห์ระบบควรจะต้องมีเพื่อเข้ากับผู้ใช้ได้ง่าย และสามารถดึงสิ่งที่ต้องการจากผู้ใช้ได้ เพราะว่าความต้องการของระบบคือ สิ่งสำคัญที่จะใช้ในการออกแบบต่อไป ถ้าเราสามารถกำหนดความต้องการได้ถูกต้อง การพัฒนาระบบในขั้นตอนต่อไปก็จะง่ายขึ้น เมื่อเก็บรวบรวมข้อมูลแล้วจะนำมาเขียนรวมเป็นรายงานการทำงานของ ระบบซึ่งควรแสดงหรือเขียนออกมาเป็นรูปแทนที่จะร่ายยาวออกมาเป็นตัวหนังสือ การแสดงแผนภาพจะทำให้เราเข้าใจได้ดีและง่ายขึ้น หลังจากนั้นนักวิเคราะห์ระบบ อาจจะนำข้อมูลที่รวบรวมได้นำมาเขียนเป็น "แบบทดลอง" (Prototype) หรือตัวต้นแบบ แบบทดลองจะเขียนขึ้นด้วยภาษาคอมพิวเตอร์ต่างๆ และที่ช่วยให้ง่ายขึ้นได้แก่ ภาษายุคที่ 4 (Fourth Generation Language) เป็นการสร้างโปรแกรมคอมพิวเตอร์ขึ้นมาเพื่อใช้งานตามที่เราต้องการได้ ดังนั้นแบบทดลองจึงช่วยลดข้อผิดพลาดที่อาจจะเกิดขึ้นได้
เมื่อจบขั้นตอนการวิเคราะห์แล้ว นักวิเคราะห์ระบบจะต้องเขียนรายงานสรุปออกมาเป็น ข้อมูลเฉพาะของปัญหา (Problem Specification) ซึ่งมีรายละเอียดดังนี้
รายละเอียดของระบบเดิม ซึ่งควรจะเขียนมาเป็นรูปภาพแสดงการทำงานของระบบ พร้อมคำบรรยาย, กำหนดความต้องการของระบบใหม่รวมทั้งรูปภาพแสดงการทำงานพร้อมคำบรรยาย, ข้อมูลและไฟล์ที่จำเป็น, คำอธิบายวิธีการทำงาน และสิ่งที่จะต้องแก้ไข. รายงานข้อมูลเฉพาะของปัญหาของระบบขนาดกลางควรจะมีขนาดไม่เกิน 100-200 หน้ากระดาษ
สรุป ขั้นตอนที่3 : การวิเคราะห์ (Analysis)
หน้าที่ : กำหนดความต้องการของระบบใหม่ (ระบบใหม่ทั้งหมดหรือแก้ไขระบบเดิม)
ผลลัพธ์ : รายงานข้อมูลเฉพาะของปัญหา
เครื่องมือ : เทคนิคการเก็บรวบรวมข้อมูล, Data Dictionary, Data Flow Diagram, Process Specification, Data Model, System Model, Prototype, system Flowcharts
บุคลากรและหน้าที่รับผิดชอบ : ผู้ใช้จะต้องให้ความร่วมมือเป็นอย่างดี
1. วิเคราะห์ระบบ ศึกษาเอกสารที่มีอยู่ และศึกษาระบบเดิมเพื่อให้เข้าใจถึงขั้นตอนการทำงานและทราบว่าจุดสำคัญของระบบอยู่ที่ไหน
2. นักวิเคราะห์ระบบ เตรียมรายงานความต้องการของระบบใหม่
3. นักวิเคราะห์ระบบ เขียนแผนภาพการทำงาน (Diagram) ของระบบใหม่โดยไม่ต้องบอกว่าหน้ามที่ใหม่ในระบบจะพัฒนาขึ้นมาได้อย่างไร
4. นักวิเคราะห์ระบบ เขียนสรุปรายงานข้อมูลเฉพาะของปัญหา
5. ถ้าเป็นไปได้นักวิเคราะห์ระบบอาจจะเตรียมแบบทดลองด้วย
ขั้นตอนที่4 : การออกแบบ (Design)
ในระยะแรกของการออกแบบ นักวิเคราะห์ระบบจะนำการตัดสินใจ ของฝ่ายบริหารที่ได้จากขั้นตอนการวิเคราะห์การเลือกซื้อคอมพิวเตอร์ ฮาร์ดแวร์และซอฟต์แวร์ด้วย (ถ้ามีหรือเป็นไปได้) หลังจากนั้นนักวิเคราะห์ระบบจะนำแผนภาพต่างๆ ที่เขียนขึ้นในขั้นตอนการวิเคราะห์มาแปลงเป็นแผนภาพลำดับขั้น (แบบต้นไม้) ดังรูปข้างล่าง เพื่อให้มองเห็นภาพลักษณ์ที่แน่นอนของโปรแกรมว่ามีความสัมพันธ์กันอย่างไร และโปรแกรมอะไรบ้างที่จะต้องเขียนในระบบ หลังจากนั้นก็เริ่มตัดสินใจว่าควรจะจัดโครงสร้างจากโปรแกรมอย่างไร การเชื่อมระหว่างโปรแกรมควรจะทำอย่างไร ในขั้นตอนการวิเคราะห์นักวิเคราะห์ระบบต้องหาว่า "จะต้องทำอะไร (What)" แต่ในขั้นตอนการออกแบบต้องรู้ว่า " จะต้องทำอย่างไร(How)"
ในการออกแบบโปรแกรมต้องคำนึงถึงความปลอดภัย (Security) ของระบบด้วย เพื่อป้องกันการผิดพลาดที่อาจจะเกิดขึ้น เช่น "รหัส" สำหรับผู้ใช้ที่มีสิทธิ์สำรองไฟล์ข้อมูลทั้งหมด เป็นต้น
นักวิเคราะห์ระบบจะต้องออกแบบฟอร์มสำหรับข้อมูลขาเข้า (Input Format) ออกแบบรายงาน (Report Format) และการแสดงผลบนจอภาพ (Screen Fromat) หลักการการออกแบบฟอร์มข้อมูลขาเข้าคือ ง่ายต่อการใช้งาน และป้องกันข้อผิดพลาดที่อาจจะเกิดขึ้น
ถัดมาระบบจะต้องออกแบบวิธีการใช้งาน เช่น กำหนดว่าการป้อนข้อมูลจะต้องทำอย่างไร จำนวนบุคลากรที่ต้องการในหน้าที่ต่างๆ แต่ถ้านักวิเคราะห์ระบบตัดสินใจว่าการซื้อซอฟต์แวร์ดีกว่าการเขียนโปรแกรม ขั้นตอนการออกแบบก็ไม่จำเป็นเลย เพราะสามารถนำซอฟต์แวร์สำเร็จรูปมาใช้งานได้ทันที สิ่งที่นักวิเคราะห์ระบบออกแบบมาทั้งหมดในขั้นตอนที่กล่าวมาทั้งหมดจะนำมาเขียนรวมเป็นเอกสารชุดหนึ่งเรียกว่า "ข้อมูลเฉพาะของการออกแบบระบบ " (System Design Specification) เมื่อสำเร็จแล้วโปรแกรมเมอร์สามารถใช้เป็นแบบในการเขียนโปรแกรม ได้ทันที่สำคัญก่อนที่จะส่งถึงมือโปรแกรมเมอร์เราควรจะตรวจสอบกับผู้ใช้ว่าพอใจหรือไม่ และตรวจสอบกับทุกคนในทีมว่าถูกต้องสมบูรณ์หรือไม่ และแน่นอนที่สุดต้องส่งให้ฝ่ายบริหารเพื่อตัดสินใจว่าจะดำเนินการ ต่อไปหรือไม่ ถ้าอนุมัติก็ผ่านเข้าสู่ขั้นตอนการสร้างหรือพัฒนาระบบ (Construction)
สรุปขั้นตอนที่ 4 : การออกแบบ (Design)
หน้าที : ออกแบบระบบใหม่เพื่อให้สอดคล้องกับความต้องการของผู้ใช้และฝ่ายบริหาร
ผลลัพธ์ : ข้อมูลเฉพาะของการออกแบบ(System Design Specification)
เครื่องมือ : พจนานุกรมข้อมูล Data Dictionary, แผนภาพการไหลของข้อมูล (Data Flow Diagram), ข้อมูลเฉพาะการประมวลผล (Process Specification ), รูปแบบข้อมูล (Data Model), รูปแบบระบบ (System Model), ผังงานระบบ (System Flow Charts), ผังงานโครงสร้าง (Structure Charts), ผังงาน HIPO (HIPO Chart), แบบฟอร์มข้อมูลขาเข้าและรายงาน
บุคลากรและหน้าที่ :
1. นักวิเคราะห์ระบบ ตัดสินใจเลือกคอมพิวเตอร์ฮาร์ดแวร์และซอฟต์แวร์ (ถ้าใช้)
2. นักวิเคราะห์ระบบ เปลี่ยนแผนภาพทั้งหลายที่ได้จากขั้นตอนการวิเคราะห์มาเป็นแผนภาพลำดับขั้น
3. นักวิเคราะห์ระบบ ออกแบบความปลอดภัยของระบบ
4. นักวิเคราะห์ระบบ ออกแบบฟอร์มข้อมูลขาเข้า รายงาน และการแสดงภาพบนจอ
5. นักวิเคราะห์ระบบ กำหนดจำนวนบุคลากรในหน้าที่ต่างๆและการทำงานของระบบ
6. ผู้ใช้ ฝ่ายบริหาร และนักวิเคราะห์ระบบ ทบทวน เอกสารข้อมูลเฉพาะของการออกแบบเพื่อความถูกต้องและสมบูรณ์แบบของระบบ
ขั้นตอนที่ 5 : การพัฒนาระบบ (Construction)
ในขั้นตอนนี้โปรแกรมเมอร์จะเริ่มเขียนและทดสอบโปรแกรมว่า ทำงานถูกต้องหรือไม่ ต้องมีการทดสอบกับข้อมูลจริงที่เลือกแล้ว ถ้าทุกอย่างเรียบร้อย เราจะได้โปรแกรมที่พร้อมที่จะนำไปใช้งานจริงต่อไป หลังจากนั้นต้องเตรียมคู่มือการใช้และการฝึกอบรมผู้ใช้งานจริงของระบบ
ระยะแรกในขั้นตอนนี้นักวิเคราะห์ระบบต้องเตรียมสถานที่สำหรับ เครื่องคอมพิวเตอร์แล้วจะต้องตรวจสอบว่าคอมพิวเตอร์ทำงานเรียบร้อยดี
โปรแกรมเมอร์เขียนโปรแกรมตามข้อมูลที่ได้จากเอกสารข้อมูลเฉพาะของการออกแบบ (Design Specification) ปกติแล้วนักวิเคราะห์ระบบไม่มีหน้าที่เกี่ยวข้องในการเขียนโปรแกรม แต่ถ้าโปรแกรมเมอร์คิดว่าการเขียนอย่างอื่นดีกว่าจะต้องปรึกษานักวิเคราะห์ระบบเสียก่อน เพื่อที่ว่านักวิเคราะห์จะบอกได้ว่าโปรแกรมที่จะแก้ไขนั้นมีผลกระทบกับระบบทั้งหมดหรือไม่ โปรแกรมเมอร์เขียนเสร็จแล้วต้องมีการทบทวนกับนักวิเคราะห์ระบบและผู้ใช้งาน เพื่อค้นหาข้อผิดพลาด วิธีการนี้เรียกว่า "Structure Walkthrough " การทดสอบโปรแกรมจะต้องทดสอบกับข้อมูลที่เลือกแล้วชุดหนึ่ง ซึ่งอาจจะเลือกโดยผู้ใช้ การทดสอบเป็นหน้าที่ของโปรแกรมเมอร์ แต่นักวิเคราะห์ระบบต้องแน่ใจว่า โปรแกรมทั้งหมดจะต้องไม่มีข้อผิดพลาด
หลังจากนั้นต้องควบคุมดูแลการเขียนคู่มือซึ่งประกอบด้วยข้อมูลการใช้งานสารบัญการอ้างอิง "Help" บนจอภาพ เป็นต้น นอกจากข้อมูลการใช้งานแล้ว ต้องมีการฝึกอบรมพนักงานที่จะเป็นผู้ใช้งานจริงของระบบเพื่อให้เข้าใจ และทำงานได้โดยไม่มีปัญหาอาจจะอบรมตัวต่อตัวหรือเป็นกลุ่มก็ได้
สรุปขั้นตอนที่ 5 : การพัฒนาระบบ (Construction)
หน้าที่ : เขียนและทดสอบโปรแกรม
ผลลัพธ์ : โปรแกรมที่ทดสอบเรียบร้อยแล้ว เอกสารคู่มือการใช้ และการฝึกอบรม
เครื่องมือ : เครื่องมือของโปรแกรมเมอร์ทั้งหลาย Editor, compiler,Structure Walkthrough, วิธีการทดสอบโปรแกรม การเขียนเอกสารประกอบการใช้งาน
บุคลากรและหน้าที่ :
1. นักวิเคราะห์ระบบ ดูแลการเตรียมสถานที่และติดตั้งเครื่องคอมพิวเตอร์ (ถ้าซื้อใหม่)
2. นักวิเคราะห์ระบบ วางแผนและดูแลการเขียนโปรแกรม ทดสอบโปรแกรม
3. โปรแกรมเมอร์เขียนและทดสอบโปรแกรม หรือแก้ไขโปรแกรม ถ้าซื้อโปรแกรมสำเร็จรูป
4. นักวิเคราะห์ระบบ วางแผนทดสอบโปรแกรม
5. ทีมที่ทำงานร่วมกันทดสอบโปรแกรม
6. ผู้ใช้ตรวจสอบให้แน่ใจว่า โปรแกรมทำงานตามต้องการ
7. นักวิเคราะห์ระบบ ดูแลการเขียนคู่มือการใช้งานและการฝึกอบรม
ขั้นตอนที่ 6 : การปรับเปลี่ยน (Construction)
ขั้นตอนนี้บริษัทนำระบบใหม่มาใช้แทนของเก่าภายใต้การดูแลของนักวิเคราะห์ระบบ การป้อนข้อมูลต้องทำให้เรียบร้อย และในที่สุดบริษัทเริ่มต้นใช้งานระบบใหม่นี้ได้
การนำระบบเข้ามาควรจะทำอย่างค่อยเป็นค่อยไปทีละน้อย ที่ดีที่สุดคือ ใช้ระบบใหม่ควบคู่ไปกับระบบเก่าไปสักระยะหนึ่ง โดยใช้ข้อมูลชุดเดียวกันแล้วเปรียบเทียบผลลัพธ์ว่าตรงกันหรือไม่ ถ้าเรียบร้อยก็เอาระบบเก่าออกได้ แล้วใช้ระบบใหม่ต่อไป
ขั้นตอนที่ 7 : บำรุงรักษา (Maintenance)
การบำรุงรักษาได้แก่ การแก้ไขโปรแกรมหลังจากการใช้งานแล้ว สาเหตุที่ต้องแก้ไขโปรแกรมหลังจากใช้งานแล้ว สาเหตุที่ต้องแก้ไขระบบส่วนใหญ่มี 2 ข้อ คือ 1. มีปัญหาในโปรแกรม (Bug) และ 2. การดำเนินงานในองค์กรหรือธุรกิจเปลี่ยนไป จากสถิติของระบบที่พัฒนาแล้วทั้งหมดประมาณ 40% ของค่าใช้จ่ายในการแก้ไขโปรแกรม เนื่องจากมี "Bug" ดังนั้นนักวิเคราะห์ระบบควรให้ความสำคัญกับการบำรุงรักษา ซึ่งปกติจะคิดว่าไม่มีความสำคัญมากนัก
เมื่อธุรกิจขยายตัวมากขึ้น ความต้องการของระบบอาจจะเพิ่มมากขึ้น เช่น ต้องการรายงานเพิ่มขึ้น ระบบที่ดีควรจะแก้ไขเพิ่มเติมสิ่งที่ต้องการได้
การบำรุงรักษาระบบ ควรจะอยู่ภายใต้การดูแลของนักวิเคราะห์ระบบ เมื่อผู้บริหารต้องการแก้ไขส่วนใดนักวิเคราะห์ระบบต้องเตรียมแผนภาพต่าง ๆ และศึกษาผลกระทบต่อระบบ และให้ผู้บริหารตัดสินใจต่อไปว่าควรจะแก้ไขหรือไม่
สรุปวงจรการพัฒนาระบบ
1.เข้าใจปัญหา
- ตระหนักว่ามีปัญหาในระบบ
2.ศึกษาความเป็นไปได้
- รวบรวมข้อมูล
- คาดคะเนค่าใช้จ่าย ผลประโยชน์และอื่น
- ตัดสินใจว่าจะเปลี่ยนแปลงระบบหรือไม่
3.วิเคราะห์
- ศึกษาระบบเดิม
- กำหนดความต้องการของระบบ
- แผนภาพระบบเก่าและระบบใหม่
- สร้างระบบทดลองของระบบใหม่
4.ออกแบบ
- เลือกซื้อคอมพิวเตอร์ฮาร์ดแวร์และซอฟต์แวร์
- เปลี่ยนแผนภาพจากการวิเคราะห์เป็นแผนภาพลำดับขั้น
- คำนึงถึงความปลอดภัยของระบบ
- ออกแบบ Input และ Output
- ออกแบบไฟล์ฐานข้อมูล
5.พัฒนา
- เตรียมสถานที่
- เขียนโปรแกรม
- ทดสอบโปรแกรม
- เตรียมคู่มือการใช้และฝึกอบรม
6.มาใช้งานจริง
- ป้อนข้อมูล
- เริ่มใช้งานระบบใหม่
7.บำรุงรักษา
- เข้าใจปัญหา
- ศึกษาสิ่งที่จะต้องแก้ไข
- ตัดสินใจว่าจะแก้ไขหรือไม่
- แก้ไขเอกสาร คู่มือ
- แก้ไขโปรแกรม
- ทดสอบโปรแกรม
- ใช้งานระบบที่แก้ไขแล้ว
หลักความสำเร็จของการพัฒนาระบบงาน
หลักการที่ 1 : ระบบเป็นของผู้ใช้
นักวิเคราะห์ระบบและโปรแกรมเมอร์ควรจะระลึกเสมอว่า ระบบเป็นของผู้ใช้ระบบซึ่งจะเป็นผู้นำเอาผลของระบบดังกล่าวมาก่อให้เกิดประโยชน์ต่อธุรกิจของเขา แม้ว่านักวิเคราะห์ระบบและโปรแกรมเมอร์จะทำงานอย่างหนักเพื่อที่จะนำเอาเทคโนโลยีคอมพิวเตอร์มาสร้าง เป็นระบบงานคอมพิวเตอร์ก็ตาม แต่ไม่ลืมว่าระบบงานคอมพิวเตอร์มีจุดยืนจุดเดียวกัน คือ เกิดขึ้นมาเพื่อแก้ไขปัญหาให้กับผู้ใช้หรือธุรกิจ ดังนั้น ผู้ใช้ระบบจึงมีส่วนสำคัญที่จะผลักดันให้การพัฒนาระบบงานเป็นไปอย่างถูกต้อง และ เพื่อตอบสนองกับความต้องการ นักวิเคราะห์ระบบจะต้องจะต้องนำเอาความเห็นของผู้ใช้ระบบมาเกี่ยวข้อง ในทุกขั้นตอนของการพัฒนาหรืออีกนัยหนึ่งคือ ในวงจรการพัฒนาระบบงานและโครงการ (SDLC) จะต้องมีบทบาทของผู้ใช้ระบบอยู่เสมอทุกขั้นตอน
หลักการที่ 2 : ทำการจัดตั้งและแบ่งกลุ่มของระบบหรือโครงการออกเป็นกลุ่มงานย่อย
โดยทั่วไป วงจรการพัฒนาระบบงานและโครงการ (SDLC) ได้จัดแบ่งขั้นตอนของการทำงานเป็นหลักอยู่แล้วดังนี้
1. ขั้นตอนการวิเคราะห์ระบบงาน (System Analysis)
2. ขั้นตอนการดีไซน์และวางระบบงาน (System Design)
3. ขั้นตอนการนำระบบงานเข้าสู่ธุรกิจเพื่อใช้ปฏิบัติงานจริง (System imple- mentation)
4. ขั้นตอนการติดตามและดำเนินการภายหลังการติดตั้งระบบงาน (System support)
สาเหตุที่มีการจัดแบ่งกลุ่มงานให้เล็กลงและเป็นลำดับขั้น ก็เพื่อที่จะให้นักบริหารโครงการหรือผู้พัฒนาระบบงานสามารถที่จะควบคุมความคืบหน้าของ การพัฒนาระบบได้อย่างใกล้ชิดและสามารถที่จะกำหนดและควบคุมระยะเวลาที่ใช้ในการพัฒนาระบบได้ดีขึ้นอีกด้วย
หลักการที่ 3 : ขั้นตอนการพัฒนาระบบงานไม่ใช่แบบอนุกรม (sequential process)
ความหมายของหลักการนี้คือ เมื่อเราเข้าสู่วงจรการพัฒนาระบบ SDLC แล้ว เราไม่จำเป็นที่จะทำขั้นที่ 1 คือ system analysis ให้เสร็จเรียบร้อยเสียก่อน แล้วจึงค่อยทำขั้นที่ 2 คือ system design หรือต้องทำขั้นที่ 2 เสร็จค่อยทำขั้นที่ 3 เรื่อยไป การทำแบบนี้จะทำให้เราใช้ระยะเวลามากขึ้นในการพัฒนาระบบงานหนึ่งๆ
ขั้นตอนการพัฒนาระบบงานสามารถที่จะทำซ้อน (overlap) กันได้ เช่น เมื่อได้ทำการวิเคราะห์ระบบงานไปได้ระยะหนึ่ง นักวิเคราะห์ระบบก็สามารถที่จะนำเอาผลการวิเคราะห์นั้นไปดีไซน์หรือวางระบบงานได้ก่อนโดยไม่ต้องรอให้ขั้นตอน การวิเคราะห์เสร็จสมบูรณ์จึงค่อยดีไซน์ ดังตัวอย่างในรูปที่ 1 ซึ่งแสดงให้เป็นว่าขณะที่กิจกรรมในขั้นตอนการวิเคราะห์ซึ่งใช้เวลาประมาณ 2 สัปดาห์ครึ่งยังไม่เสร็จสิ้น ในสัปดาห์ที่ 2 ก็สามารถจะเริ่มขั้นตอนการดีไซน์ระบบได้ อย่างไรก็ตาม การทำเช่นนี้จะต้องตั้งอยู่ในความเหมาะสมด้วย โดยในบางครั้งบางขั้นตอนอาจจำเป็นที่จะต้องรอให้เสร็จสมบูรณ์ก่อนแล้วจึงค่อยดำเนินในขั้นถัดไป จากรูปที่ 1 จะแสดงให้เห้นว่าการติดตั้งระบบอาจจำเป็น ต้องรอให้ขั้นตอนการดีไซน์ระบบเสร็จสิ้นลงเสียก่อนแล้วจึงค่อยดำเนินการต่อไป
หลักการที่ 4 : ระบบงานข้อมูลถือเป็นการลงทุนอย่างหนึ่ง
การพัฒนาระบบงานหนึ่งๆก็ถือว่าเป็นการลงทุนอย่างหนึ่ง ซึ่งไม่แตกต่างจากที่เราลงทุนซื้อรถ เพื่อมาขนส่งสินค้าหรือซื้อเครื่องจักรมาเพื่อทำการผลิต
เมื่อระบบงานถือว่าเป็นการลงทุนชนิดหนึ่ง สิ่งที่นักวิเคราะห็ระบบจะต้องคำนึงก็คือทางเลือกต่างๆที่จะนำเงินไปลงทุน ซึ่งหมายถึงว่านักวิเคราะห์ระบบควรคิดถึงทางเลือก ของการพัฒนาระบบงานในหลายๆงานและพิจารณาถึงความเป็นไปได้ต่างๆ รวมถึงการเปรียบเทียบต้นทุนและผลกำไรที่จะเกิดจากระบบงาน ว่าระบบนั้นๆ คุ้มค่าหรือไม่อย่างไร ยกตัวอย่าง เช่น นักวิเคราะห์กำลังรับทำระบบงานสำหรับร้านให้เช่าวิดีโอร้านหนึ่งซึ่งเป็นร้านเล็กๆ มีรายได้ประมาณ 10,000 บาทต่อเดือน เขาตัดสินใจแนะนำให้ร้านนั้นซื้อคอมพิวเตอร์ราคา 2 ล้านบาท ซึ่งเขาจะพัฒนาระบบงานให้ โดยจะเสียค่าใช้จ่ายอีกประมาณ 3 แสนบาท ลักษณะแบบนี้ท่านจะเห็นได้ชัดว่า การตัดสินใจลงทุนแบบนี้ไม่คุ้มค่าแน่ นักวิเคราะห์ควรจะทำการวิเคราะห์หาทางเลือกที่เหมาะสมและนำเสนอต่อผู้ใช้โดยให้มีข้อมูล ในการเปรียบเทียบถึงข้อดีข้อเสียต่างๆ เพื่อผู้ใช้ระบบสามารถที่จะออกความเห็นหรือปรึกษาหารือเพื่อหาข้อยุติที่เหมาะสมต่อไป
หลักการที่ 5 : อย่ากลัวที่จะต้องยกเลิก
ในทุกขั้นตอนของการพัฒนาระบบงานจะมีการศึกษาถึงความเป็นไปได้ (feasibility study) ของระบบงาน ดังนั้นในทุกขั้นตอน นักวิเคราะห์ระบบจะมีโอกาสเสมอที่จะตัดสินใจว่าจะให้ระบบงานนั้นดำเนินต่อไปหรือยกเลิก
แน่นอนที่ว่า ความรู้สึกที่จะต้องยกเลิกงานที่ทำมาอย่างยากเย็นนั้น จะต้องไม่ดีแน่ และคงไม่มีใครอยากสัมผัสเหตุการณ์เช่นนี้ แต่อย่างไรก็ดี เมื่อการพัฒนาระบบงานไม่สามารถจะทำให้เป็นไปตามความต้องการของผู้ใช้ระบบ การเริ่มต้นทำใหม่หรือยกเลิกโครงการนั้นอาจเป็นสิ่งจำเป็น จากประสบการณ์ที่เคยได้เห็นได้ยินมา มีอยู่หลายโครงการในสหรัฐอเมริกาที่ต้องยกเลิกไป และอีกหลายโครงการที่ยังดันทุรังที่จะให้อยู่แต่ไม่สามารถจะทำได้ ข้อเสียที่เห็นได้ชัดในความกลัวที่จะต้องยกเลิกก็คือ โครงการหรือระบบงานนั้นสุดท้ายก็ต้องพังลง และดันทุรังที่จะให้ฟื้นคืนชีพ มักจะใช้เงินลงทุนเพิ่มขึ้น ใช้เวลาเพิ่มขึ้นและใช้คนเพิ่มขึ้น ทำให้งบประมาณเกิดบานปลาย และไม่สามารถควบคุมได้
หลักการที่ 6 : ในทุกขั้นตอนของการพัฒนาจะต้องมีการจัดทำเอกสารเพื่อใช้อ้างอิงเสมอ
การขาดการจัดทำเอกสารมักจะส่งผลให้เกิดข้อผิดพลาดต่อระบบงานและต่อนักวิเคราะห์ระบบด้วย การจัดทำเอกสารมักจะถูกมองข้ามไป และเห็นว่าเป็นสิ่งที่ทำให้เสียเวลาแม้กระทั่งการเขียนโปรแกรมซึ่ง สามารถจะแทรกคำอธิบายเล็กๆน้อยๆว่าโปรแกรมในส่วนนั้นๆทำอะไร ก็ยังไม่มีใครทำสักเท่าไรซึ่งการขาดการทำเอกสารเช่นนี้ จะทำให้การบำรุงรักษาหรือติดตามระบบเป็นไปได้ยาก ทำให้ยากต่อการแก้ไข
การจัดทำเอกสาร จะหมายรวมถึงการบันทึกเหตุการณ์ต่างๆ และแนวความคิด รวมทั้งข้อสรุปที่เกิดขึ้นในแต่ละขั้นตอนของการพัฒนาระบบงานและโครงการ ไม่ใช่จะเอาแค่รหัสต้นกำเนิด (source code) ของแต่ระบบเท่านั้น
Software Developement Model
1. Big Bang Model
2. Code & fix Model
• The code-and-fix model contains two steps
1. Write some code
2. Fix the problems in the code
• The basic model used in earliest days of software
development
– It is not really a model, it is more “lack of a model”
– Probably the model you used in most of your
programming assignments
– It is only suitable for short programs which do not
require maintenance, unsatisfactory for large projects
Basic problems with the code-and-fix model:
1.After several fixes the code becomes poorly structured
• a design phase is necessary
2. Frequently, well-designed code is a poor match to the
customers needs
• a requirements phase is necessary
3. Code is expensive to fix because of poor preparation for
testing and modification
• testing and maintenance phases have to be planned
3. Waterfall Model
Anti-Lock Break System - ระบบเบรกป้องกันล้อล็อก
ระบบเบรกป้องกันล้อล็อก (อังกฤษ: anti-lock braking system; ตัวย่อ: ABS) เป็นระบบความปลอดภัยซึ่งป้องกันปัญหาการลื่นไถลในขณะเบรก โดยมิให้ล้อของยานยนต์เกิดการล็อกหรือหยุดหมุนระหว่างการเบรก
ล้อสำหรับแล่นบนถนนมีประโยชน์ช่วยให้ผู้ขับยังคงสามารถบังคับพวงมาลัยของรถได้ภายใต้การเบรกอย่างแรง โดยการป้องกันการลื่นไถลและทำให้ล้อรถลากไปกับพื้นถนนตามการบังคับของผู้ขับ ในขณะที่ระบบเบรกเอบีเอสช่วยเพิ่มการควบคุมยานพาหนะ และอาจช่วยลดระยะการเบรกได้บนพื้นผิวที่แห้งและมีความลื่นอย่างมาก แต่มันก็อาจส่งผลเพิ่มระยะการเบรกในพื้นผิวที่ร่วนซุย เช่น พื้นหิมะหรือกรวด[1]
นับตั้งแต่การใช้งานอย่างแพร่หลายในช่วงแรกในรถยนต์ ระบบเบรกป้องกันล้อล็อกได้มีการพัฒนาอย่างมาก รุ่นของระบบเบรกสมัยใหม่ไม่เพียงแต่ป้องกันล้อล็อกระหว่างการเบรกเท่านั้น แต่ยังรวมไปถึงการควบคุมแบบอิเล็กทรอนิกส์ของเบรกเอียงจากหน้าไปหลัง ฟังก์ชันดังกล่าว ขึ้นอยู่กับขีดความสามารถและการพัฒนา เป็นที่รู้จักกันว่า ระบบกระจายแรงเบรกอิเล็กทรอนิกส์ (EDB)
What is Embedded System?
ระบบฝังตัว หรือ สมองกลฝังตัว (embedded system) คือระบบประมวลผล ที่ใช้ชิปหรือไมโครโพรเซสเซอร์ที่ออกแบบมาโดยเฉพาะ เป็นระบบคอมพิวเตอร์ขนาดจิ๋วที่ฝังไว้ในอุปกรณ์ เครื่องใช้ไฟฟ้า และเครื่องเล่นอิเล็กทรอนิกส์ต่างๆ เพื่อเพิ่มความฉลาด ความสามารถให้กับอุปกรณ์เหล่านั้นผ่านซอฟต์แวร์ซึ่งต่างจากระบบประมวลผลที่เครื่องคอมพิวเตอร์ทั่วไป ระบบฝังตัวถูกนำมาใช้กันอย่างแพร่หลายในยานพาหนะ เครื่องใช้ไฟฟ้าในบ้านและสำนักงาน อุปกรณ์อิเล็กทรอนิกส์ เทคโนโลยีซอฟต์แวร์ เทคโนโลยีฮาร์ดแวร์ เทคโนโลยีเครือข่ายเน็ตเวิร์ก เทคโนโลยีด้านการสื่อสาร เทคโนโลยีเครื่องกลและของเล่นต่าง ๆ คำว่าระบบฝังตัวเกิดจาก การที่ระบบนี้เป็นระบบประมวลผลเช่นเดียวกับระบบคอมพิวเตอร์ แต่ว่าระบบนี้จะฝังตัวลงในอุปกรณ์อื่น ๆ ที่ไม่ใช่เครื่องคอมพิวเตอร์ ในปัจจุบันระบบสมองกลฝังตัวได้มีการพัฒนามากขึ้น โดยในระบบสมองกลฝังตัวอาจจะประกอบไปด้วยไมโครคอนโทรลเลอร์ หรือ ไมโครโปรเซสเซอร์ อุปกรณ์ที่ใช้ระบบสมองกลฝังตัวที่เห็นได้ชัดเช่นโทรศัพท์มือถือ และในระบบสมองกลฝังตัวยังมีการใส่ระบบปฏิบัติการต่างๆแตกต่างกันไปอีกด้วย ดังนั้น ระบบสมองกลฝังตัวอาจจะทำงานได้ตั้งแต่ควบคุมหลอดไฟจนไปถึงใช้ในยานอวกาศ
Product Life Cycle
- Product Definition : ข้อสรุปในการทำโปรดัค การผลิตจำนวนมากเพื่อลดต้นทุนต่างๆ และมีมาตรฐานของผลิตที่เท่ากันทั้งหมด หรือเกือบทั้งหมด
- Design : การออกแบบ การทำตัวต้นแบบ
- Initial Production : การตรวจงาน
- Sustained Production : ทบทวนโปเจ็คเก่าอาจจะลดการผลิตลง เพื่อเตรียมการทำโปรเจ็คใหม่
- End of Life : เลิกการผลิตงานเก่า
System Development Life Cycle
จุดกำเนิดของระบบงาน
จุดกำเนิดของระบบงานโดยปกติจะกำเนิดขึ้นจากผู้ใช้ระบบ เนื่องจากผู้ใช้ระบบเป็นผู้ใกล้ชิดกับกิจกรรมของธุรกิจมากที่สุด ดังนั้นกิจกรรมทางธุรกิจได้ดำเนินไปอย่างต่อเนื่องนั้น ความต้องการที่จะพัฒนาปรับปรุงกิจการต่างๆย่อมเกิดขึ้น นักวิเคราะห์ระบบจึงเริ่มเข้ามามีบทบาทในการพัฒนาปรับปรุงแก้ไขระบบงาน
James Wetherbe ได้แต่งหนังสือออกมาเล่มหนึ่งในปี 2527 โดยใช้ชื่อว่า “System Analysis and Design: Traditional, Structured and Advanced Concepts and Techniques.”โดยให้แนวความคิดในการแจกแจงกลุ่มของปัญหาออกเป็น 6 หัวข้อตามความต้องการของผู้ใช้ ซึ่งแทนด้วยอักษร 6 ตัวคือ PIECES อ่านว่า “พีซ-เซส” โดยมีรายละเอียดดังนี้คือ
1. Performance หมายถึงความต้องการที่จะให้มีการปรับปรุงทางด้านการปฎิบัติงาน
2. Information หมายถึงความต้องการที่จะให้มีการปรับปรุงและควบคุมทางด้านข้อมูล
3. Economics หมายถึงความต้องการที่จะให้มีการปรับปรุงและควบคุมทางด้านต้นทุน
4. Control หมายถึงความต้องการที่จะให้มีการปรับปรุงระบบงานข้อมูล เพื่อให้มีการควบคุมและระบบรักษาความปลอดภัยที่ดียิ่งขึ้น
5. Efficiency หมายถึงความต้องการที่จะให้มีการปรับปรุงประสิทธิภาพของคนและเครื่องจักร
6. service หมายถึงความต้องการที่จะให้มีการปรับปรุงการบริการต่างๆ ให้ดีขึ้น เช่น การบริการลูกค้าหรือการให้บริการต่อพนักงานภายในธุรกิจเองเป็นต้น
ในแต่ละโครงการของระบบงานข้อมูลนั้น จะมีลักษณะที่จะตอบสนองความต้องการที่ได้ระบุอยู่ในพีซเซสอันใดอันหนึ่งหรือมากกว่าหนึ่งก็ได้ ดังนั้นพีซเซสจึงมีความสำคัญต่อนักวิเคราะห์ระบบในการใช้ เพื่อพิจารณาถึงปัญหาและความต้องการของผู้ใช้อย่างมีหลักเกณฑ์
วงจรการพัฒนาระบบ (System Development Life Cycle :SDLC)
ระบบสารสนเทศทั้งหลายมีวงจรชีวิตที่เหมือนกันตั้งแต่เกิดจนตายวงจรนี้จะเป็นขั้นตอน ที่เป็นลำดับตั้งแต่ต้นจนเสร็จเรียบร้อย เป็นระบบที่ใช้งานได้ ซึ่งนักวิเคราะห์ระบบต้องทำความเข้าใจให้ดีว่าในแต่ละขั้นตอนจะต้องทำอะไร และทำอย่างไร ขั้นตอนการพัฒนาระบบมีอยู่ด้วยกัน 7 ขั้น ด้วยกัน คือ
1. เข้าใจปัญหา (Problem Recognition)
2. ศึกษาความเป็นไปได้ (Feasibility Study)
3. วิเคราะห์ (Analysis)
4. ออกแบบ (Design)
5. สร้างหรือพัฒนาระบบ (Construction)
6. การปรับเปลี่ยน (Conversion)
7. บำรุงรักษา (Maintenance)
ขั้นที่ 1 : เข้าใจปัญหา (Problem Recognition)
ระบบสารสนเทศจะเกิดขึ้นได้ก็ต่อเมื่อผู้บริหารหรือผู้ใช้ตระหนักว่า ต้องการระบบสารสนเทศหรือระบบจัดการเดิม ได้แก่ระบบเอกสารในตู้เอกสาร ไม่มีประสิทธิภาพเพียงพอที่ตอบสนองความต้องการในปัจจุบัน
ปัจจุบันผู้บริหารตื่นตัวกันมากที่จะให้มีการพัฒนาระบบสารสนเทศมาใช้ในหน่วยงานของตน ในงานธุรกิจ อุตสาหกรรม หรือใช้ในการผลิต ตัวอย่างเช่น บริษัทของเรา จำกัด ติดต่อซื้อสินค้าจากผู้ขายหลายบริษัท ซึ่งบริษัทของเราจะมีระบบ MIS ที่เก็บข้อมูลเกี่ยวกับหนี้สินที่บริษัทขอเราติดค้างผู้ขายอยู่ แต่ระบบเก็บข้อมูลผู้ขายได้เพียง 1,000 รายเท่านั้น แต่ปัจจุบันผู้ขายมีระบบเก็บข้อมูลถึง 900 ราย และอนาคตอันใกล้นี้จะเกิน 1,000 ราย ดังนั้นฝ่ายบริหารจึงเรียกนักวิเคราะห์ระบบเข้ามาศึกษา แก้ไขระบบงาน
ปัญหาที่สำคัญของระบบสารสนเทศในปัจจุบัน คือ ระบบเขียนมานานแล้ว ส่วนใหญ่เขียนมาเพื่อติดตามเรื่องการเงิน ไม่ได้มีจุดประสงค์เพื่อให้ข้อมูลข่าวสารในการตัดสินใจ แต่ปัจจุบันฝ่าย บริหารต้องการดูสถิติการขายเพื่อใช้ในการคาดคะเนในอนาคต หรือความต้องการอื่นๆ เช่น สินค้าที่มียอดขายสูง หรือสินค้าที่ลูกค้าต้องการสูง หรือการแยกประเภทสินค้าต่างๆที่ทำได้ไม่ง่ายนัก
การที่จะแก้ไขระบบเดิมที่มีอยู่แล้วไม่ใช่เรื่องที่ง่ายนัก หรือแม้แต่การสร้างระบบใหม่ ดังนั้นควรจะมีการศึกษาเสียก่อนว่า ความต้องการของเราเพียงพอที่เป็นไปได้หรือไม่ ได้แก่ "การศึกษาความเป็นไปได้" (Feasibility Study)
สรุป ขั้นตอนที่ 1: เข้าใจปัญหา
หน้าที่ : ตระหนักว่ามีปัญหาในระบบ
ผลลัพธ์ : อนุมัติการศึกษาความเป็นไปได้
เครื่องมือ : ไม่มี
บุคลากรและหน้าที่ความรับผิดชอบ : ผู้ใช้หรือผู้บริหารชี้แจงปัญหาต่อนักวิเคราะห์ระบบ
ขั้นตอนที่ 2 : ศึกษาความเป็นไปได้ (Feasibility Study)
จุดประสงค์ของการศึกษาความเป็นไปได้ก็คือ การกำหนดว่าปัญหาคืออะไรและตัดสินใจว่าการพัฒนาสร้างระบบสารสนเทศ หรือการแก้ไขระบบสารสนเทศเดิมมีความเป็นไปได้หรือไม่โดยเสียค่าใช้จ่ายและเวลาน้อยที่สุด และได้ผลเป็นที่น่าพอใจ
ปัญหาต่อไปคือ นักวิเคราะห์ระบบจะต้องกำหนดให้ได้ว่าการแก้ไขปัญหาดังกล่าวมีความเป็นไปได้ทางเทคนิคและบุคลากร ปัญหาทางเทคนิคก็จะเกี่ยวข้องกับเรื่องคอมพิวเตอร์ และเครื่องมือเก่าๆถ้ามี รวมทั้งเครื่องคอมพิวเตอร์ซอฟต์แวร์ด้วย ตัวอย่างคือ คอมพิวเตอร์ที่ใช้อยู่ในบริษัทเพียงพอหรือไม่ คอมพิวเตอร์อาจจะมีเนื้อที่ของฮาร์ดดิสก์ไม่เพียงพอ รวมทั้งซอฟต์แวร์ ว่าอาจจะต้องซื้อใหม่ หรือพัฒนาขึ้นใหม่ เป็นต้น ความเป็นไปได้ทางด้านบุคลากร คือ บริษัทมีบุคคลที่เหมาะสมที่จะพัฒนาและติดตั้งระบบเพียงพอหรือไม่ ถ้าไม่มีจะหาได้หรือไม่ จากที่ใด เป็นต้น นอกจากนั้นควรจะให้ความสนใจว่าผู้ใช้ระบบมีความคิดเห็นอย่างไรกับการเปลี่ยนแปลง รวมทั้งความเห็นของผู้บริหารด้วย
สุดท้ายนักวิเคราะห์ระบบต้องวิเคราะห์ได้ว่า ความเป็นไปได้เรื่องค่าใช้จ่าย รวมทั้งเวลาที่ ใช้ในการพัฒนาระบบ และที่สำคัญคือ ผลประโยชน์ที่จะได้รับ เรื่องเวลาเป็นสิ่งสำคัญ เช่น การเปลี่ยนแปลงระบบเพื่อรองรับผู้ขายให้ได้มากกว่า 1,000 บริษัทนั้น ควรใช้เวลาไม่เกิน 1 ปี ตั้งแต่เริ่มต้นจนใช้งานได้ ค่าใช้จ่ายเริ่มตั้งแต่พัฒนาจนถึงใช้งานได้จริงได้แก่ เงินเดือน เครื่องมือ อุปกรณ์ ต่างๆ เป็นต้น พูดถึงเรื่องผลประโยชน์ที่ได้รับอาจมองเห็นได้ไม่ง่ายนัก แต่นักวิเคราะห์ระบบควรมองและตีออกมาในรูปเงินให้ได้ เช่น เมื่อนำระบบใหม่เข้ามาใช้อาจจะทำให้ ค่าใช้จ่ายบุคลากรลดลง หรือกำไรเพิ่มมากขึ้น เช่น ทำให้ยอดขายเพิ่มมากขึ้น เนื่องจากผู้บริหารมีข้อมูลพร้อมที่จะช่วยในการตัดสินใจที่ดีขึ้น
การคาดคะเนทั้งหลายเป็นไปอย่างหยาบๆ เราไม่สามารถหาตัวเลขที่แน่นอนตายตัวได้เนื่องจากทั้งหมดยังไม่ได้เกิดขึ้นจริง หลังจากเตรียมตัวเลขเรียบร้อยแล้ว นักวิเคราะห์ระบบก็นำตัวเลข ค่าใช้จ่ายและผลประโยชน์ (Cost-Benefit) มาเปรียบเทียบกัน
สรุปขั้นตอนที่ 2 : การศึกษาความเป็นไปได้ (Feasibility Study)
หน้าที่ : กำหนดปัญหา และศึกษาว่าเป็นไปได้หรือไม่ที่จะเปลี่ยนแปลงระบบ
ผลลัพธ์ : รายงานความเป็นไปได้
เครื่องมือ : เก็บรวบรวมข้อมูลของระบบและคาดคะเนความต้องการของระบบ
บุคลากรและหน้าที่ความรับผิดชอบ : ผู้ใช้จะมีบทบาทสำคัญในการศึกษา
1. นักวิเคราะห์ระบบจะเก็บรวบรวมข้อมูลทั้งหมดที่จำเป็นทั้งหมดเกี่ยวกับปัญหา
2. นักวิเคราะห์ระบบคาดคะเนความต้องการของระบบและแนวทางการแก้ปัญหา
3. นักวิเคราะห์ระบบ กำหนดความต้องการที่แน่ชัดซึ่งจะใช้สำหรับขั้นตอนการวิเคราะห์ต่อไป
4. ผู้บริหารตัดสินใจว่าจะดำเนินโครงการต่อไปหรือไม่
ขั้นตอนที่ 3 การวิเคราะห์ (Analysis)
เริ่มเข้าสู่การวิเคราะห์ระบบ การวิเคราะห์ระบบเริ่มตั้งแต่การศึกษาระบบการทำงานของธุรกิจนั้น ในกรณีที่ระบบเราศึกษานั้นเป็นระบบสารสนเทศอยู่แล้วจะต้องศึกษาว่าทำงานอย่างไร เพราะเป็นการยากที่จะออกแบบระบบใหม่โดยที่ไม่ทราบว่าระบบเดิมทำงานอย่างไร หรือธุรกิจดำเนินการอย่างไร หลังจากนั้นกำหนดความต้องการของระบบใหม่ ซึ่งนักวิเคราะห์ระบบจะต้องใช้เทคนิคในการเก็บข้อมูล (Fact-Gathering Techniques) ดังรูป ได้แก่ ศึกษาเอกสารที่มีอยู่ ตรวจสอบวิธีการทำงานในปัจจุบัน สัมภาษณ์ผู้ใช้และผู้จัดการที่มีส่วนเกี่ยวข้องกับระบบ เอกสารที่มีอยู่ได้แก่ คู่มือการใช้งาน แผนผังใช้งานขององค์กร รายงานต่างๆที่หมุนเวียนใน ระบบการศึกษาวิธีการทำงานในปัจจุบันจะทำให้นักวิเคราะห์ระบบรู้ว่าระบบจริงๆทำงานอย่างไร ซึ่งบางครั้งค้นพบข้อผิดพลาดได้ ตัวอย่าง เช่น เมื่อบริษัทได้รับใบเรียกเก็บเงินจะมีขั้นตอนอย่างไรในการจ่ายเงิน ขั้นตอนที่เสมียนป้อนใบเรียกเก็บเงินอย่างไร เฝ้าสังเกตการทำงานของผู้เกี่ยวข้อง เพื่อให้เข้าใจและเห็นจริงๆ ว่าขั้นตอนการทำงานเป็นอย่างไร ซึ่งจะทำให้นักวิเคราะห์ระบบค้นพบจุดสำคัญของระบบว่าอยู่ที่ใด
การสัมภาษณ์เป็นศิลปะอย่างหนึ่งที่นักวิเคราะห์ระบบควรจะต้องมีเพื่อเข้ากับผู้ใช้ได้ง่าย และสามารถดึงสิ่งที่ต้องการจากผู้ใช้ได้ เพราะว่าความต้องการของระบบคือ สิ่งสำคัญที่จะใช้ในการออกแบบต่อไป ถ้าเราสามารถกำหนดความต้องการได้ถูกต้อง การพัฒนาระบบในขั้นตอนต่อไปก็จะง่ายขึ้น เมื่อเก็บรวบรวมข้อมูลแล้วจะนำมาเขียนรวมเป็นรายงานการทำงานของ ระบบซึ่งควรแสดงหรือเขียนออกมาเป็นรูปแทนที่จะร่ายยาวออกมาเป็นตัวหนังสือ การแสดงแผนภาพจะทำให้เราเข้าใจได้ดีและง่ายขึ้น หลังจากนั้นนักวิเคราะห์ระบบ อาจจะนำข้อมูลที่รวบรวมได้นำมาเขียนเป็น "แบบทดลอง" (Prototype) หรือตัวต้นแบบ แบบทดลองจะเขียนขึ้นด้วยภาษาคอมพิวเตอร์ต่างๆ และที่ช่วยให้ง่ายขึ้นได้แก่ ภาษายุคที่ 4 (Fourth Generation Language) เป็นการสร้างโปรแกรมคอมพิวเตอร์ขึ้นมาเพื่อใช้งานตามที่เราต้องการได้ ดังนั้นแบบทดลองจึงช่วยลดข้อผิดพลาดที่อาจจะเกิดขึ้นได้
เมื่อจบขั้นตอนการวิเคราะห์แล้ว นักวิเคราะห์ระบบจะต้องเขียนรายงานสรุปออกมาเป็น ข้อมูลเฉพาะของปัญหา (Problem Specification) ซึ่งมีรายละเอียดดังนี้
รายละเอียดของระบบเดิม ซึ่งควรจะเขียนมาเป็นรูปภาพแสดงการทำงานของระบบ พร้อมคำบรรยาย, กำหนดความต้องการของระบบใหม่รวมทั้งรูปภาพแสดงการทำงานพร้อมคำบรรยาย, ข้อมูลและไฟล์ที่จำเป็น, คำอธิบายวิธีการทำงาน และสิ่งที่จะต้องแก้ไข. รายงานข้อมูลเฉพาะของปัญหาของระบบขนาดกลางควรจะมีขนาดไม่เกิน 100-200 หน้ากระดาษ
สรุป ขั้นตอนที่3 : การวิเคราะห์ (Analysis)
หน้าที่ : กำหนดความต้องการของระบบใหม่ (ระบบใหม่ทั้งหมดหรือแก้ไขระบบเดิม)
ผลลัพธ์ : รายงานข้อมูลเฉพาะของปัญหา
เครื่องมือ : เทคนิคการเก็บรวบรวมข้อมูล, Data Dictionary, Data Flow Diagram, Process Specification, Data Model, System Model, Prototype, system Flowcharts
บุคลากรและหน้าที่รับผิดชอบ : ผู้ใช้จะต้องให้ความร่วมมือเป็นอย่างดี
1. วิเคราะห์ระบบ ศึกษาเอกสารที่มีอยู่ และศึกษาระบบเดิมเพื่อให้เข้าใจถึงขั้นตอนการทำงานและทราบว่าจุดสำคัญของระบบอยู่ที่ไหน
2. นักวิเคราะห์ระบบ เตรียมรายงานความต้องการของระบบใหม่
3. นักวิเคราะห์ระบบ เขียนแผนภาพการทำงาน (Diagram) ของระบบใหม่โดยไม่ต้องบอกว่าหน้ามที่ใหม่ในระบบจะพัฒนาขึ้นมาได้อย่างไร
4. นักวิเคราะห์ระบบ เขียนสรุปรายงานข้อมูลเฉพาะของปัญหา
5. ถ้าเป็นไปได้นักวิเคราะห์ระบบอาจจะเตรียมแบบทดลองด้วย
ขั้นตอนที่4 : การออกแบบ (Design)
ในระยะแรกของการออกแบบ นักวิเคราะห์ระบบจะนำการตัดสินใจ ของฝ่ายบริหารที่ได้จากขั้นตอนการวิเคราะห์การเลือกซื้อคอมพิวเตอร์ ฮาร์ดแวร์และซอฟต์แวร์ด้วย (ถ้ามีหรือเป็นไปได้) หลังจากนั้นนักวิเคราะห์ระบบจะนำแผนภาพต่างๆ ที่เขียนขึ้นในขั้นตอนการวิเคราะห์มาแปลงเป็นแผนภาพลำดับขั้น (แบบต้นไม้) ดังรูปข้างล่าง เพื่อให้มองเห็นภาพลักษณ์ที่แน่นอนของโปรแกรมว่ามีความสัมพันธ์กันอย่างไร และโปรแกรมอะไรบ้างที่จะต้องเขียนในระบบ หลังจากนั้นก็เริ่มตัดสินใจว่าควรจะจัดโครงสร้างจากโปรแกรมอย่างไร การเชื่อมระหว่างโปรแกรมควรจะทำอย่างไร ในขั้นตอนการวิเคราะห์นักวิเคราะห์ระบบต้องหาว่า "จะต้องทำอะไร (What)" แต่ในขั้นตอนการออกแบบต้องรู้ว่า " จะต้องทำอย่างไร(How)"
ในการออกแบบโปรแกรมต้องคำนึงถึงความปลอดภัย (Security) ของระบบด้วย เพื่อป้องกันการผิดพลาดที่อาจจะเกิดขึ้น เช่น "รหัส" สำหรับผู้ใช้ที่มีสิทธิ์สำรองไฟล์ข้อมูลทั้งหมด เป็นต้น
นักวิเคราะห์ระบบจะต้องออกแบบฟอร์มสำหรับข้อมูลขาเข้า (Input Format) ออกแบบรายงาน (Report Format) และการแสดงผลบนจอภาพ (Screen Fromat) หลักการการออกแบบฟอร์มข้อมูลขาเข้าคือ ง่ายต่อการใช้งาน และป้องกันข้อผิดพลาดที่อาจจะเกิดขึ้น
ถัดมาระบบจะต้องออกแบบวิธีการใช้งาน เช่น กำหนดว่าการป้อนข้อมูลจะต้องทำอย่างไร จำนวนบุคลากรที่ต้องการในหน้าที่ต่างๆ แต่ถ้านักวิเคราะห์ระบบตัดสินใจว่าการซื้อซอฟต์แวร์ดีกว่าการเขียนโปรแกรม ขั้นตอนการออกแบบก็ไม่จำเป็นเลย เพราะสามารถนำซอฟต์แวร์สำเร็จรูปมาใช้งานได้ทันที สิ่งที่นักวิเคราะห์ระบบออกแบบมาทั้งหมดในขั้นตอนที่กล่าวมาทั้งหมดจะนำมาเขียนรวมเป็นเอกสารชุดหนึ่งเรียกว่า "ข้อมูลเฉพาะของการออกแบบระบบ " (System Design Specification) เมื่อสำเร็จแล้วโปรแกรมเมอร์สามารถใช้เป็นแบบในการเขียนโปรแกรม ได้ทันที่สำคัญก่อนที่จะส่งถึงมือโปรแกรมเมอร์เราควรจะตรวจสอบกับผู้ใช้ว่าพอใจหรือไม่ และตรวจสอบกับทุกคนในทีมว่าถูกต้องสมบูรณ์หรือไม่ และแน่นอนที่สุดต้องส่งให้ฝ่ายบริหารเพื่อตัดสินใจว่าจะดำเนินการ ต่อไปหรือไม่ ถ้าอนุมัติก็ผ่านเข้าสู่ขั้นตอนการสร้างหรือพัฒนาระบบ (Construction)
สรุปขั้นตอนที่ 4 : การออกแบบ (Design)
หน้าที : ออกแบบระบบใหม่เพื่อให้สอดคล้องกับความต้องการของผู้ใช้และฝ่ายบริหาร
ผลลัพธ์ : ข้อมูลเฉพาะของการออกแบบ(System Design Specification)
เครื่องมือ : พจนานุกรมข้อมูล Data Dictionary, แผนภาพการไหลของข้อมูล (Data Flow Diagram), ข้อมูลเฉพาะการประมวลผล (Process Specification ), รูปแบบข้อมูล (Data Model), รูปแบบระบบ (System Model), ผังงานระบบ (System Flow Charts), ผังงานโครงสร้าง (Structure Charts), ผังงาน HIPO (HIPO Chart), แบบฟอร์มข้อมูลขาเข้าและรายงาน
บุคลากรและหน้าที่ :
1. นักวิเคราะห์ระบบ ตัดสินใจเลือกคอมพิวเตอร์ฮาร์ดแวร์และซอฟต์แวร์ (ถ้าใช้)
2. นักวิเคราะห์ระบบ เปลี่ยนแผนภาพทั้งหลายที่ได้จากขั้นตอนการวิเคราะห์มาเป็นแผนภาพลำดับขั้น
3. นักวิเคราะห์ระบบ ออกแบบความปลอดภัยของระบบ
4. นักวิเคราะห์ระบบ ออกแบบฟอร์มข้อมูลขาเข้า รายงาน และการแสดงภาพบนจอ
5. นักวิเคราะห์ระบบ กำหนดจำนวนบุคลากรในหน้าที่ต่างๆและการทำงานของระบบ
6. ผู้ใช้ ฝ่ายบริหาร และนักวิเคราะห์ระบบ ทบทวน เอกสารข้อมูลเฉพาะของการออกแบบเพื่อความถูกต้องและสมบูรณ์แบบของระบบ
ขั้นตอนที่ 5 : การพัฒนาระบบ (Construction)
ในขั้นตอนนี้โปรแกรมเมอร์จะเริ่มเขียนและทดสอบโปรแกรมว่า ทำงานถูกต้องหรือไม่ ต้องมีการทดสอบกับข้อมูลจริงที่เลือกแล้ว ถ้าทุกอย่างเรียบร้อย เราจะได้โปรแกรมที่พร้อมที่จะนำไปใช้งานจริงต่อไป หลังจากนั้นต้องเตรียมคู่มือการใช้และการฝึกอบรมผู้ใช้งานจริงของระบบ
ระยะแรกในขั้นตอนนี้นักวิเคราะห์ระบบต้องเตรียมสถานที่สำหรับ เครื่องคอมพิวเตอร์แล้วจะต้องตรวจสอบว่าคอมพิวเตอร์ทำงานเรียบร้อยดี
โปรแกรมเมอร์เขียนโปรแกรมตามข้อมูลที่ได้จากเอกสารข้อมูลเฉพาะของการออกแบบ (Design Specification) ปกติแล้วนักวิเคราะห์ระบบไม่มีหน้าที่เกี่ยวข้องในการเขียนโปรแกรม แต่ถ้าโปรแกรมเมอร์คิดว่าการเขียนอย่างอื่นดีกว่าจะต้องปรึกษานักวิเคราะห์ระบบเสียก่อน เพื่อที่ว่านักวิเคราะห์จะบอกได้ว่าโปรแกรมที่จะแก้ไขนั้นมีผลกระทบกับระบบทั้งหมดหรือไม่ โปรแกรมเมอร์เขียนเสร็จแล้วต้องมีการทบทวนกับนักวิเคราะห์ระบบและผู้ใช้งาน เพื่อค้นหาข้อผิดพลาด วิธีการนี้เรียกว่า "Structure Walkthrough " การทดสอบโปรแกรมจะต้องทดสอบกับข้อมูลที่เลือกแล้วชุดหนึ่ง ซึ่งอาจจะเลือกโดยผู้ใช้ การทดสอบเป็นหน้าที่ของโปรแกรมเมอร์ แต่นักวิเคราะห์ระบบต้องแน่ใจว่า โปรแกรมทั้งหมดจะต้องไม่มีข้อผิดพลาด
หลังจากนั้นต้องควบคุมดูแลการเขียนคู่มือซึ่งประกอบด้วยข้อมูลการใช้งานสารบัญการอ้างอิง "Help" บนจอภาพ เป็นต้น นอกจากข้อมูลการใช้งานแล้ว ต้องมีการฝึกอบรมพนักงานที่จะเป็นผู้ใช้งานจริงของระบบเพื่อให้เข้าใจ และทำงานได้โดยไม่มีปัญหาอาจจะอบรมตัวต่อตัวหรือเป็นกลุ่มก็ได้
สรุปขั้นตอนที่ 5 : การพัฒนาระบบ (Construction)
หน้าที่ : เขียนและทดสอบโปรแกรม
ผลลัพธ์ : โปรแกรมที่ทดสอบเรียบร้อยแล้ว เอกสารคู่มือการใช้ และการฝึกอบรม
เครื่องมือ : เครื่องมือของโปรแกรมเมอร์ทั้งหลาย Editor, compiler,Structure Walkthrough, วิธีการทดสอบโปรแกรม การเขียนเอกสารประกอบการใช้งาน
บุคลากรและหน้าที่ :
1. นักวิเคราะห์ระบบ ดูแลการเตรียมสถานที่และติดตั้งเครื่องคอมพิวเตอร์ (ถ้าซื้อใหม่)
2. นักวิเคราะห์ระบบ วางแผนและดูแลการเขียนโปรแกรม ทดสอบโปรแกรม
3. โปรแกรมเมอร์เขียนและทดสอบโปรแกรม หรือแก้ไขโปรแกรม ถ้าซื้อโปรแกรมสำเร็จรูป
4. นักวิเคราะห์ระบบ วางแผนทดสอบโปรแกรม
5. ทีมที่ทำงานร่วมกันทดสอบโปรแกรม
6. ผู้ใช้ตรวจสอบให้แน่ใจว่า โปรแกรมทำงานตามต้องการ
7. นักวิเคราะห์ระบบ ดูแลการเขียนคู่มือการใช้งานและการฝึกอบรม
ขั้นตอนที่ 6 : การปรับเปลี่ยน (Construction)
ขั้นตอนนี้บริษัทนำระบบใหม่มาใช้แทนของเก่าภายใต้การดูแลของนักวิเคราะห์ระบบ การป้อนข้อมูลต้องทำให้เรียบร้อย และในที่สุดบริษัทเริ่มต้นใช้งานระบบใหม่นี้ได้
การนำระบบเข้ามาควรจะทำอย่างค่อยเป็นค่อยไปทีละน้อย ที่ดีที่สุดคือ ใช้ระบบใหม่ควบคู่ไปกับระบบเก่าไปสักระยะหนึ่ง โดยใช้ข้อมูลชุดเดียวกันแล้วเปรียบเทียบผลลัพธ์ว่าตรงกันหรือไม่ ถ้าเรียบร้อยก็เอาระบบเก่าออกได้ แล้วใช้ระบบใหม่ต่อไป
ขั้นตอนที่ 7 : บำรุงรักษา (Maintenance)
การบำรุงรักษาได้แก่ การแก้ไขโปรแกรมหลังจากการใช้งานแล้ว สาเหตุที่ต้องแก้ไขโปรแกรมหลังจากใช้งานแล้ว สาเหตุที่ต้องแก้ไขระบบส่วนใหญ่มี 2 ข้อ คือ 1. มีปัญหาในโปรแกรม (Bug) และ 2. การดำเนินงานในองค์กรหรือธุรกิจเปลี่ยนไป จากสถิติของระบบที่พัฒนาแล้วทั้งหมดประมาณ 40% ของค่าใช้จ่ายในการแก้ไขโปรแกรม เนื่องจากมี "Bug" ดังนั้นนักวิเคราะห์ระบบควรให้ความสำคัญกับการบำรุงรักษา ซึ่งปกติจะคิดว่าไม่มีความสำคัญมากนัก
เมื่อธุรกิจขยายตัวมากขึ้น ความต้องการของระบบอาจจะเพิ่มมากขึ้น เช่น ต้องการรายงานเพิ่มขึ้น ระบบที่ดีควรจะแก้ไขเพิ่มเติมสิ่งที่ต้องการได้
การบำรุงรักษาระบบ ควรจะอยู่ภายใต้การดูแลของนักวิเคราะห์ระบบ เมื่อผู้บริหารต้องการแก้ไขส่วนใดนักวิเคราะห์ระบบต้องเตรียมแผนภาพต่าง ๆ และศึกษาผลกระทบต่อระบบ และให้ผู้บริหารตัดสินใจต่อไปว่าควรจะแก้ไขหรือไม่
สรุปวงจรการพัฒนาระบบ
1.เข้าใจปัญหา
- ตระหนักว่ามีปัญหาในระบบ
2.ศึกษาความเป็นไปได้
- รวบรวมข้อมูล
- คาดคะเนค่าใช้จ่าย ผลประโยชน์และอื่น
- ตัดสินใจว่าจะเปลี่ยนแปลงระบบหรือไม่
3.วิเคราะห์
- ศึกษาระบบเดิม
- กำหนดความต้องการของระบบ
- แผนภาพระบบเก่าและระบบใหม่
- สร้างระบบทดลองของระบบใหม่
4.ออกแบบ
- เลือกซื้อคอมพิวเตอร์ฮาร์ดแวร์และซอฟต์แวร์
- เปลี่ยนแผนภาพจากการวิเคราะห์เป็นแผนภาพลำดับขั้น
- คำนึงถึงความปลอดภัยของระบบ
- ออกแบบ Input และ Output
- ออกแบบไฟล์ฐานข้อมูล
5.พัฒนา
- เตรียมสถานที่
- เขียนโปรแกรม
- ทดสอบโปรแกรม
- เตรียมคู่มือการใช้และฝึกอบรม
6.มาใช้งานจริง
- ป้อนข้อมูล
- เริ่มใช้งานระบบใหม่
7.บำรุงรักษา
- เข้าใจปัญหา
- ศึกษาสิ่งที่จะต้องแก้ไข
- ตัดสินใจว่าจะแก้ไขหรือไม่
- แก้ไขเอกสาร คู่มือ
- แก้ไขโปรแกรม
- ทดสอบโปรแกรม
- ใช้งานระบบที่แก้ไขแล้ว
หลักความสำเร็จของการพัฒนาระบบงาน
หลักการที่ 1 : ระบบเป็นของผู้ใช้
นักวิเคราะห์ระบบและโปรแกรมเมอร์ควรจะระลึกเสมอว่า ระบบเป็นของผู้ใช้ระบบซึ่งจะเป็นผู้นำเอาผลของระบบดังกล่าวมาก่อให้เกิดประโยชน์ต่อธุรกิจของเขา แม้ว่านักวิเคราะห์ระบบและโปรแกรมเมอร์จะทำงานอย่างหนักเพื่อที่จะนำเอาเทคโนโลยีคอมพิวเตอร์มาสร้าง เป็นระบบงานคอมพิวเตอร์ก็ตาม แต่ไม่ลืมว่าระบบงานคอมพิวเตอร์มีจุดยืนจุดเดียวกัน คือ เกิดขึ้นมาเพื่อแก้ไขปัญหาให้กับผู้ใช้หรือธุรกิจ ดังนั้น ผู้ใช้ระบบจึงมีส่วนสำคัญที่จะผลักดันให้การพัฒนาระบบงานเป็นไปอย่างถูกต้อง และ เพื่อตอบสนองกับความต้องการ นักวิเคราะห์ระบบจะต้องจะต้องนำเอาความเห็นของผู้ใช้ระบบมาเกี่ยวข้อง ในทุกขั้นตอนของการพัฒนาหรืออีกนัยหนึ่งคือ ในวงจรการพัฒนาระบบงานและโครงการ (SDLC) จะต้องมีบทบาทของผู้ใช้ระบบอยู่เสมอทุกขั้นตอน
หลักการที่ 2 : ทำการจัดตั้งและแบ่งกลุ่มของระบบหรือโครงการออกเป็นกลุ่มงานย่อย
โดยทั่วไป วงจรการพัฒนาระบบงานและโครงการ (SDLC) ได้จัดแบ่งขั้นตอนของการทำงานเป็นหลักอยู่แล้วดังนี้
1. ขั้นตอนการวิเคราะห์ระบบงาน (System Analysis)
2. ขั้นตอนการดีไซน์และวางระบบงาน (System Design)
3. ขั้นตอนการนำระบบงานเข้าสู่ธุรกิจเพื่อใช้ปฏิบัติงานจริง (System imple- mentation)
4. ขั้นตอนการติดตามและดำเนินการภายหลังการติดตั้งระบบงาน (System support)
สาเหตุที่มีการจัดแบ่งกลุ่มงานให้เล็กลงและเป็นลำดับขั้น ก็เพื่อที่จะให้นักบริหารโครงการหรือผู้พัฒนาระบบงานสามารถที่จะควบคุมความคืบหน้าของ การพัฒนาระบบได้อย่างใกล้ชิดและสามารถที่จะกำหนดและควบคุมระยะเวลาที่ใช้ในการพัฒนาระบบได้ดีขึ้นอีกด้วย
หลักการที่ 3 : ขั้นตอนการพัฒนาระบบงานไม่ใช่แบบอนุกรม (sequential process)
ความหมายของหลักการนี้คือ เมื่อเราเข้าสู่วงจรการพัฒนาระบบ SDLC แล้ว เราไม่จำเป็นที่จะทำขั้นที่ 1 คือ system analysis ให้เสร็จเรียบร้อยเสียก่อน แล้วจึงค่อยทำขั้นที่ 2 คือ system design หรือต้องทำขั้นที่ 2 เสร็จค่อยทำขั้นที่ 3 เรื่อยไป การทำแบบนี้จะทำให้เราใช้ระยะเวลามากขึ้นในการพัฒนาระบบงานหนึ่งๆ
ขั้นตอนการพัฒนาระบบงานสามารถที่จะทำซ้อน (overlap) กันได้ เช่น เมื่อได้ทำการวิเคราะห์ระบบงานไปได้ระยะหนึ่ง นักวิเคราะห์ระบบก็สามารถที่จะนำเอาผลการวิเคราะห์นั้นไปดีไซน์หรือวางระบบงานได้ก่อนโดยไม่ต้องรอให้ขั้นตอน การวิเคราะห์เสร็จสมบูรณ์จึงค่อยดีไซน์ ดังตัวอย่างในรูปที่ 1 ซึ่งแสดงให้เป็นว่าขณะที่กิจกรรมในขั้นตอนการวิเคราะห์ซึ่งใช้เวลาประมาณ 2 สัปดาห์ครึ่งยังไม่เสร็จสิ้น ในสัปดาห์ที่ 2 ก็สามารถจะเริ่มขั้นตอนการดีไซน์ระบบได้ อย่างไรก็ตาม การทำเช่นนี้จะต้องตั้งอยู่ในความเหมาะสมด้วย โดยในบางครั้งบางขั้นตอนอาจจำเป็นที่จะต้องรอให้เสร็จสมบูรณ์ก่อนแล้วจึงค่อยดำเนินในขั้นถัดไป จากรูปที่ 1 จะแสดงให้เห้นว่าการติดตั้งระบบอาจจำเป็น ต้องรอให้ขั้นตอนการดีไซน์ระบบเสร็จสิ้นลงเสียก่อนแล้วจึงค่อยดำเนินการต่อไป
หลักการที่ 4 : ระบบงานข้อมูลถือเป็นการลงทุนอย่างหนึ่ง
การพัฒนาระบบงานหนึ่งๆก็ถือว่าเป็นการลงทุนอย่างหนึ่ง ซึ่งไม่แตกต่างจากที่เราลงทุนซื้อรถ เพื่อมาขนส่งสินค้าหรือซื้อเครื่องจักรมาเพื่อทำการผลิต
เมื่อระบบงานถือว่าเป็นการลงทุนชนิดหนึ่ง สิ่งที่นักวิเคราะห็ระบบจะต้องคำนึงก็คือทางเลือกต่างๆที่จะนำเงินไปลงทุน ซึ่งหมายถึงว่านักวิเคราะห์ระบบควรคิดถึงทางเลือก ของการพัฒนาระบบงานในหลายๆงานและพิจารณาถึงความเป็นไปได้ต่างๆ รวมถึงการเปรียบเทียบต้นทุนและผลกำไรที่จะเกิดจากระบบงาน ว่าระบบนั้นๆ คุ้มค่าหรือไม่อย่างไร ยกตัวอย่าง เช่น นักวิเคราะห์กำลังรับทำระบบงานสำหรับร้านให้เช่าวิดีโอร้านหนึ่งซึ่งเป็นร้านเล็กๆ มีรายได้ประมาณ 10,000 บาทต่อเดือน เขาตัดสินใจแนะนำให้ร้านนั้นซื้อคอมพิวเตอร์ราคา 2 ล้านบาท ซึ่งเขาจะพัฒนาระบบงานให้ โดยจะเสียค่าใช้จ่ายอีกประมาณ 3 แสนบาท ลักษณะแบบนี้ท่านจะเห็นได้ชัดว่า การตัดสินใจลงทุนแบบนี้ไม่คุ้มค่าแน่ นักวิเคราะห์ควรจะทำการวิเคราะห์หาทางเลือกที่เหมาะสมและนำเสนอต่อผู้ใช้โดยให้มีข้อมูล ในการเปรียบเทียบถึงข้อดีข้อเสียต่างๆ เพื่อผู้ใช้ระบบสามารถที่จะออกความเห็นหรือปรึกษาหารือเพื่อหาข้อยุติที่เหมาะสมต่อไป
หลักการที่ 5 : อย่ากลัวที่จะต้องยกเลิก
ในทุกขั้นตอนของการพัฒนาระบบงานจะมีการศึกษาถึงความเป็นไปได้ (feasibility study) ของระบบงาน ดังนั้นในทุกขั้นตอน นักวิเคราะห์ระบบจะมีโอกาสเสมอที่จะตัดสินใจว่าจะให้ระบบงานนั้นดำเนินต่อไปหรือยกเลิก
แน่นอนที่ว่า ความรู้สึกที่จะต้องยกเลิกงานที่ทำมาอย่างยากเย็นนั้น จะต้องไม่ดีแน่ และคงไม่มีใครอยากสัมผัสเหตุการณ์เช่นนี้ แต่อย่างไรก็ดี เมื่อการพัฒนาระบบงานไม่สามารถจะทำให้เป็นไปตามความต้องการของผู้ใช้ระบบ การเริ่มต้นทำใหม่หรือยกเลิกโครงการนั้นอาจเป็นสิ่งจำเป็น จากประสบการณ์ที่เคยได้เห็นได้ยินมา มีอยู่หลายโครงการในสหรัฐอเมริกาที่ต้องยกเลิกไป และอีกหลายโครงการที่ยังดันทุรังที่จะให้อยู่แต่ไม่สามารถจะทำได้ ข้อเสียที่เห็นได้ชัดในความกลัวที่จะต้องยกเลิกก็คือ โครงการหรือระบบงานนั้นสุดท้ายก็ต้องพังลง และดันทุรังที่จะให้ฟื้นคืนชีพ มักจะใช้เงินลงทุนเพิ่มขึ้น ใช้เวลาเพิ่มขึ้นและใช้คนเพิ่มขึ้น ทำให้งบประมาณเกิดบานปลาย และไม่สามารถควบคุมได้
หลักการที่ 6 : ในทุกขั้นตอนของการพัฒนาจะต้องมีการจัดทำเอกสารเพื่อใช้อ้างอิงเสมอ
การขาดการจัดทำเอกสารมักจะส่งผลให้เกิดข้อผิดพลาดต่อระบบงานและต่อนักวิเคราะห์ระบบด้วย การจัดทำเอกสารมักจะถูกมองข้ามไป และเห็นว่าเป็นสิ่งที่ทำให้เสียเวลาแม้กระทั่งการเขียนโปรแกรมซึ่ง สามารถจะแทรกคำอธิบายเล็กๆน้อยๆว่าโปรแกรมในส่วนนั้นๆทำอะไร ก็ยังไม่มีใครทำสักเท่าไรซึ่งการขาดการทำเอกสารเช่นนี้ จะทำให้การบำรุงรักษาหรือติดตามระบบเป็นไปได้ยาก ทำให้ยากต่อการแก้ไข
การจัดทำเอกสาร จะหมายรวมถึงการบันทึกเหตุการณ์ต่างๆ และแนวความคิด รวมทั้งข้อสรุปที่เกิดขึ้นในแต่ละขั้นตอนของการพัฒนาระบบงานและโครงการ ไม่ใช่จะเอาแค่รหัสต้นกำเนิด (source code) ของแต่ระบบเท่านั้น
Software Developement Model
1. Big Bang Model
2. Code & fix Model
• The code-and-fix model contains two steps
1. Write some code
2. Fix the problems in the code
• The basic model used in earliest days of software
development
– It is not really a model, it is more “lack of a model”
– Probably the model you used in most of your
programming assignments
– It is only suitable for short programs which do not
require maintenance, unsatisfactory for large projects
Basic problems with the code-and-fix model:
1.After several fixes the code becomes poorly structured
• a design phase is necessary
2. Frequently, well-designed code is a poor match to the
customers needs
• a requirements phase is necessary
3. Code is expensive to fix because of poor preparation for
testing and modification
• testing and maintenance phases have to be planned
3. Waterfall Model
ทฤษฎีแบบจำลองน้ำตก (อังกฤษ: Waterfall Model) เป็นการศึกษาถึงความเหมาะสม กำหนดปัญหา หรือการศึกษาความเป็นไปได้ (Feasibility Study) เป็นหน้าที่ของนักวิเคราะห์ระบบ ในการพัฒนาซอฟต์แวร์ จะเน้นศึกษาใน 5 ประการ คือ
1.ความเหมาะสมทางด้านเทคนิค (Technical Feasibility) - ศึกษาด้านฮาร์ดแวร์ ซอฟต์แวร์ เหมาะสมหรือไม่
2.ความเหมาะสมทางด้านการปฏิบัติงาน (Operational Feasibility) - การปฏิบัติงานซ้ำซ้อนหรือไม่ ตรงหรือไม่
3.ความเหมาะสมทางด้านการเงิน (Financial Feasibility) - เปรียบเทียบความคุ้มค่า ผลตอบแทน ค่าใช้จ่าย
4.ความเหมาะสมทางด้านเวลา (Schedule Feasibility) - พิจารณาเวลาในการสร้างระบบงาน การใช้เวลา
5.ความเหมาะสมทางด้านบุคลากร (Human Feasibility) - ดูความพร้อมของบุคลากร การพัฒนาบุคลากร
คุณลักษณะของ Waterfall Model
- เป็น Seriesของขั้นตอนการทำงาน คล้ายสายงานการผลิต (Product Line)
- แต่ละขั้น หน้าที่และProduct ถูกกำหนดอย่างชัดเจน
- Product ส่วนใหญ่เป็นเอกสาร (Document)
- Productที่ผลิตในแต่ละขั้นจะเป็นพื้นฐานสำหรับงานขั้นต่อไป
- สามารถตรวจสอบความถูกต้องของงานในแต่ละขั้นได้
ข้อดีของ Waterfall Model
- แบ่งงานยากให้เป็นงานที่เล็ก ง่ายต่อการจัดการ
- มีการกำหนดProductที่ต้องส่งมอบในแต่ละงาน อย่างชัดเจน
ข้อจำกัดของ Waterfall Model
- ถ้า ค้นพบข้อผิดพลาดของขั้นที่เสร็จสิ้นแล้ว ไม่สามารถแก้ไขได้ การแก้ไขจำเป็นต้องเริ่มรอบ (Iteration) ใหม่
ระหว่างการทำCoding เจอข้อผิดพลาดในงานออกแบบ
ในความเป็นจริง หลังการทำงานในแต่ละขั้นควรสามารถย้อนไปแก้ไขความผิดพลาดในขั้นใดใดก็ได้ก่อนหน้า
ดังนั้นในทางปฏิบัติ ขั้นตอนการทำงานใน Waterfall จึงไม่เป็นเชิงเส้น (Linear)
- ข้อเสียหลักคือ ลูกค้าเห็นและทดลองใช้Software ก็ต่อเมื่อถึงขั้นตอนสุดท้าย หากมีบางอย่างที่ไม่ตรงกับความต้องการของลูกค้า การแก้ไขยาก แพง เสียเวลา
4. Spiral Model
- ปัญหาของการใช้แบบจำลองบันไดเวียน ในการพัฒนาซอฟต์แวร์ คือการโน้มน้าวให้ผู้ใช้ระบบเห็นชอบกับวิธีการที่เป็นกระบวนทำซ้ำแบบมีวิวัฒนาการ
- ความสำเร็จของการใช้ แบบจำลองบันไดเวียน ผู้พัฒนาจะต้องมีความเชี่ยวชาญในด้านการประเมินผลความเสี่ยง
- เป็น model ที่ใช้ความเสี่ยงเป็นเครื่องตัดสินใจว่าจะกระทำอะไรต่อไป (risk-driven)
ขั้นตอนในแต่ละรอบ
- วิเคราะห์เป้าหมาย แนวทางเลือกต่างๆ เงื่อนไขต่างๆ
- วิเคราะห์ความเสี่ยง
- พยายามลดความเสี่ยงนั้น เช่น ทำ Prototype เพื่อทดสอบ
- พัฒนา product
- นำ product ให้ลูกค้าทดสอบ
อ้างอิงจาก
http://th.wikipedia.org
http://www.youtube.com
http://www.tutor-tan.com
http://th.wikipedia.org
http://th.wikipedia.org
ไม่มีความคิดเห็น:
แสดงความคิดเห็น