จุดกำเนิดของระบบงานโดยปกติจะกำเนิดขึ้นจากผู้ใช้ระบบ เนื่องจากผู้ใช้ระบบเป็นผู้ใกล้ชิดกับกิจกรรมของธุรกิจมากที่สุด ดังนั้นกิจกรรมทางธุรกิจได้ดำเนินไปอย่างต่อเนื่องนั้น ความต้องการที่จะพัฒนาปรับปรุงกิจการต่างๆย่อมเกิดขึ้น นักวิเคราะห์ระบบจึงเริ่มเข้ามามีบทบาทในการพัฒนาปรับปรุงแก้ไขระบบงาน
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)
ค่าใช้จ่าย | ปีที่ 0 | ปีที่ 1 | ปีที่ 2 | ปีที่ 3 | ปีที่ 4 | ปีที่ 5 |
ค่าใช้จ่ายในการพัฒนาระบบ | 200,000 | - | - | - | - | - |
ค่าใช้จ่ายเมื่อปฏิบัติงาน | - | 50,000 | 52,000 | 60,000 | 70,000 | 85,500 |
ค่าใช้จ่ายรวมตั้งแต่ต้น | 200,000 | 250,000 | 302,000 | 362,000 | 422,000 | 507,000 |
ผลประโยชน์ | - | 80,000 | 100,000 | 120,000 | 150,000 | 200,000 |
ผลประโยชน์ตั้งแต่ต้น | - | 80,000 | 180,000 | 300,000 | 450,000 | 650,000 |
จะเห็นว่าหลังจากปีที่ 3 บริษัทเริ่มมีกำไรเพิ่มขึ้น ดังนั้นปัญหามีอยู่ว่าเราจะยอมขาดทุนใน 3 ปีแรก และลงทุนเริ่มต้นเป็นเงิน 200,000 บาท หรือไม่
สรุปขั้นตอนที่ 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. เข้าใจปัญหา | 1. ตระหนักว่ามีปัญหาในระบบ |
2. ศึกษาความเป็นไปได้ | 1. รวบรวมข้อมูล 2. คาดคะเนค่าใช้จ่าย ผลประโยชน์และอื่น 3. ตัดสินใจว่าจะเปลี่ยนแปลงระบบหรือไม่ |
3. วิเคราะห์ | 1. ศึกษาระบบเดิม 2. กำหนดความต้องการของระบบ 3. แผนภาพระบบเก่าและระบบใหม่ 4. สร้างระบบทดลองของระบบใหม่ |
4. ออกแบบ | 1. เลือกซื้อคอมพิวเตอร์ฮาร์ดแวร์และซอฟต์แวร์ 2. เปลี่ยนแผนภาพจากการวิเคราะห์เป็นแผนภาพลำดับขั้น 3. คำนึงถึงความปลอดภัยของระบบ 4. ออกแบบ Input และ Output 5. ออกแบบไฟล์ฐานข้อมูล |
5. พัฒนา | 1. เตรียมสถานที่ 2. เขียนโปรแกรม 3. ทดสอบโปรแกรม 4. เตรียมคู่มือการใช้และฝึกอบรม |
6. นำมาใช้งานจริง | 1. ป้อนข้อมูล 2. เริ่มใช้งานระบบใหม่ |
7. บำรุงรักษา | 1. เข้าใจปัญหา 2. ศึกษาสิ่งที่จะต้องแก้ไข 3. ตัดสินใจว่าจะแก้ไขหรือไม่ 4. แก้ไขเอกสาร คู่มือ 5. แก้ไขโปรแกรม 6. ทดสอบโปรแกรม 7. ใช้งานระบบที่แก้ไขแล้ว |
การนำวงจรการพัฒนาระบบSDLCมาสู่ระบบงาน
ระบบเทคโนโลยีสารสนเทศ
IT Audit เป็นคำที่มีความหมายค่อนข้างกว้าง ครอบคลุมการตรวจสอบประเภทต่างๆ หลายประเภท เช่น
1. การตรวจสอบกระบวนการด้านเทคโนโลยีสารสนเทศ (IT Process Auditing) ซึ่งครอบคลุมตั้งแต่การวางแผนด้านเทคโนโลยีสารสนเทศ จนถึงการตรวจสอบและติดตามกิจกรรมต่างๆ ด้านเทคโนโลยีสารสนเทศ
2. การตรวจสอบด้านเทคนิคของระบบสารสนเทศ (Technical Information Systems Auditing) ได้แก่ การตรวจสอบความปลอดภัย และการควบคุมโครงสร้าง หรือองค์ประกอบพื้นฐานของระบบสารสนเทศ (Information Systems Infrastructure) เช่น
- ระบบสื่อสารข้อมูลและระบบโครงข่าย (Data Communications and Network Systems)
- ระบบปฏิบัติการ (Operating Systems)
- ระบบจัดการฐานข้อมูล (Database Management Systems)
3. การตรวจสอบระบบงาน (Application Information Systems Auditing)
4. การตรวจสอบการพัฒนาระบบ (Systems Development Auditing)
5. การตรวจสอบการนำระบบมาใช้งานจริง (Systems Implementation Auditing)
6. การตรวจสอบการปฏิบัติตามนโยบายรักษาความปลอดภัยระบบสารสนเทศของกิจการ กฎระเบียบ หรือมาตรฐานที่กำหนดไว้ (Compliance Information Systems Auditing)
ในการทำ IT Audit ใน “มุมของผู้สอบบัญชี” จะเน้นการทำ IT Audit เพื่อพิจารณาถึงความเพียงพอของการควบคุมด้านเทคโนโลยีสารสนเทศที่องค์กรกำหนดไว้ และการปฏิบัติตามการควบคุมนั้นเพื่อให้มั่นใจในความถูกต้อง น่าเชื่อถือของข้อมูลที่แสดงในงบการเงิน หรือหลักฐานที่ใช้ในการตรวจสอบ
สำหรับการทำ IT Audit ใน “มุมของผู้บริหาร” ไม่ควรเน้นเฉพาะการตรวจสอบการควบคุมสำหรับระบบเทคโนโลยีสารสนเทศที่องค์กรกำหนดไว้ เพื่อให้มั่นใจในความถูกต้อง น่าเชื่อถือของข้อมูลที่แสดงในงบการเงิน หรือหลักฐานที่ใช้ในการตรวจสอบเท่านั้น แต่ควรจะครอบคลุมการตรวจสอบความเพียงพอและเหมาะสมของการรักษาความปลอดภัย และการควบคุมสำหรับระบบเทคโนโลยีสารสนเทศที่องค์กรกำหนดไว้ เพื่อให้มั่นใจว่าองค์กรจะสามารถบรรลุวัตถุประสงค์ทางธุรกิจขององค์กรที่กำหนดไว้จากการใช้ระบบเทคโนโลยีสารสนเทศนั้นด้วย
การควบคุมภายในซึ่งถือเป็นปัจจัยที่สำคัญมากอย่างหนึ่งของการดำเนินธุรกิจ เป็นองค์ประกอบหนึ่งของการกำกับดูแลกิจการที่ดี (Good Corporate Governance) โดย “Best Practices” หรือมาตรฐานที่ควรนำมาเป็นแนวทางในการเตรียมระบบสารสนเทศขององค์กรให้พร้อมเข้าสู่ยุค IT Governance ที่นิยมใช้กันได้แก่ มาตรฐาน ISO / IEC17799, COBIT และ ITIL เป็นต้น
ดังนั้น เพื่อให้เกิดความเชื่อมั่นอย่างสมเหตุสมผล (Reasonable Assurance) ว่า องค์กรดำเนินงานอย่างมีประสิทธิภาพ และประสิทธิผล สามารถบรรลุเป้าหมายขององค์กร จึงมีความจำเป็นที่จะต้องนำมาตรฐานสากลด้านการรักษาความมั่นคงปลอดภัยในระบบเทคโนโลยีสารสนเทศมาประยุกต์ใช้เพื่อความปลอดภัยขององค์กรและเพื่อให้สอดคล้องกับยุคของไอทีภิบาล (IT Governance) มุ่งสู่การเป็นบรรษัทภิบาล (Good Corporate Governance)
มาตรฐาน COBIT (Control Objectives for Information and Related Technology) มีจุดประสงค์ในการสร้างความมั่นใจว่า การใช้ทรัพยากรด้านเทคโนโลยีสารสนเทศนั้นสอดคล้องกับวัตถุประสงค์เชิงธุรกิจขององค์กร (Business Objectives) เพื่อให้เกิดการใช้ทรัพยากรอย่างมีประสิทธิผลอันจะส่งประโยชน์สูงสุดแก่องค์กร ช่วยให้เกิดความสมดุลระหว่างความเสี่ยงด้านเทคโนโลยีสารสนเทศ (IT Risk) และผลตอบแทนของการลงทุนในระบบสารสนเทศ (IT Return on Investment : IT ROI)
มาตรฐาน COBIT นั้นมีพื้นฐานมาจาก Framework ชั้นนำต่างๆ มากมาย ได้แก่ The Software Engineering Institute’s Capability Maturity Model (CMM), ISO9000 และ The Information Technology Infrastructure Library (ITIL) ของประเทศอังกฤษ อย่างไรก็ตาม มาตรฐาน COBIT ก็ยังขาดในส่วนของ Guideline เพื่อใช้ในทางปฏิบัติ เนื่องจากมาตรฐาน COBIT เป็น Framework ที่เน้นในเรื่องของการควบคุม (Control) เป็นหลัก โดยมุ่งประเด็นในการบอกว่าองค์กรต้องการอะไรบ้าง (What) แต่ไม่มีรายละเอียดในแง่ของวิธีการที่นำไปสู่จุดนั้น (How) ซึ่งเหมาะกับผู้ตรวจสอบระบบสารสนเทศที่ต้องการนำมาตรฐาน COBIT มาใช้เพื่อทำเป็น Check Lists หรือ Audit Program
การทดสอบระบบงาน
ระบบงานจะต้องได้รับการทดสอบในทุกๆ ด้านที่จะสามารถทำการทดสอบได้ เพื่อให้เกิดความแน่ใจได้ว่าระบบงานจะทำงานได้ถูกต้องและเป็นไปตามที่ต้องการ ซึ่งการทดสอบระบบ งานแบ่งออกเป็น 3 ขั้นตอน คือ การทดสอบแต่ละส่วน การทดสอบทั้งระบบ และการทดสอบเพื่อการยอมรับ
การทดสอบแต่ละส่วน (Unit Testing) เป็นการทดสอบโปรแกรมทีละโปรแกรมแยกกันต่างหาก เพื่อให้แน่ใจได้ว่าถ้าโปรแกรมแต่ละโปรแกรมทำงานได้อย่างถูกต้องแล้วก็จะทำให้ระบบงานทั้งระบบทำงานได้อย่างถูกต้องด้วย อย่างไรก็ตามวัตถุประสงค์ของการทดสอบในลักษณะนี้มักจะไม่สามารถทำได้อย่างสมบูรณ์ ดังนั้น การทดสอบจึงควรจะมุ่งเน้นการค้นหาจุดผิดพลาดในโปรแกรม และพยายามค้นหาวิธีการที่จะทำให้โปรแกรมนั้นสามารถตอบสนองกับสิ่งแวดล้อมได้ในทุกรูปแบบ
การทดสอบระบบทั้งระบบ (System Testing) เป็นการทดสอบการทำงานของระบบในภาพรวม ซึ่งจะทดสอบการทำงานร่วมกันระหว่างโปรแกรมส่วนต่างๆ ของระบบงาน (ที่ได้รับการทดสอบแบบแยกส่วนมาก่อนหน้านี้แล้ว) นอกจากนั้นยังทำการประเมินค่าระยะเวลาที่ใช้ในการทำงาน ความสามารถในการตอบสนองเมื่อมีผู้ใช้งานเป็นจำนวนมากพร้อมกัน การฟื้นคืนสภาพเมื่อระบบเกิดความล้มเหลว ความสามารถในการใช้งานระบบหลังความล้มเหลว และเอกสารประกอบที่อธิบายการทำงานทุกส่วนของระบบงาน
การทดสอบเพื่อการยอมรับระบบ (Acceptance Testing) เป็นการทดสอบในขั้นตอนสุดท้ายเพื่อให้เกิดความมั่นใจว่าระบบงานพร้อมที่จะนำไปติดตั้งใช้งานได้ ผลจากการทดสอบระบบงานทั้งระบบจะถูกนำมาพิจารณาโดยพนักงานผู้ใช้ระบบงาน และผู้บริหาร เมื่อทุกฝ่ายมีความพอใจต่อผลที่เกิดขึ้นจากการทดสอบ รวมทั้งระบบงานสามารถทำงานได้ตามมาตรฐานที่ต้องการแล้ว จะถือว่าระบบงานได้รับการยอมรับอย่างเป็นทางการ และสามารถนำไปติดตั้งใช้งานได้
วิธีการที่ใช้ในการทดสอบระบบงาน
วิธีการที่ใช้ในการทดสอบประสิทธิภาพการทำงานของโปรแกรมระบบงาน สามารถจำแนกได้ ดังนี้
1. การทดสอบการทำงานสูงสุด (Peak Load Testing) เป็นการทดสอบประสิทธิภาพในการประมวลผลของโปรแกรมระบบงาน เมื่อมีการทำรายการมากที่สุด ณ ช่วงเวลาใดเวลาหนึ่ง เพื่อทดสอบว่าระบบจะสามารถรองรับการทำรายการมากที่สุดได้เพียงใด และนานเท่าไหร่เมื่อต้องประมวลผลจำนวนรายการที่มากที่สุดดังกล่าวในช่วงเวลาหนึ่ง
ตัวอย่างเช่น ระบบงานสามารถรองรับการทำรายการได้สูงสุด 1,000 รายการต่อวัน แต่ในการทดสอบสมมติให้มีการทำรายการ 1,200 รายการต่อวัน เป็นต้น การทดสอบลักษณะนี้จะทำให้ทราบได้ว่าระบบสามารถรองรับการทำรายการมากกว่าขีดสูงสุดที่กำหนดได้หรือไม่ และได้นานเพียงใด มีปัญหาอะไรเกิดขึ้นบ้าง
2. การทดสอบประสิทธิภาพของเวลา (Performance Testing) เป็นการทดสอบระบบ เพื่อพิจารณาถึงช่วงเวลาที่ใช้ในการประมวลผลรายการว่าใช้ระยะเวลานานเพียงใดในการทำรายการ ไม่ว่าจะเป็นการประมวลผลแบบกลุ่ม (Batch Processing) หรือการประมวลผลแบบออนไลน์ (Online Processing) รวมทั้งทดสอบช่วงเวลาที่ใช้ในการเข้าถึงข้อมูลแบบลำดับ (Sequential Access) และแบบสุ่ม (Random Access)
3.การทดสอบการกู้ระบบ (Recovery Testing) เป็นการทดสอบความสามารถในการกู้ระบบ รวมทั้งการกู้ข้อมูลให้สามารถกลับคืนสู่สภาวะปกติ กรณีเกิดเหตุการณ์ที่ทำให้ระบบงานไม่สามารถทำงานต่อไปได้
4. การทดสอบการเก็บข้อมูล (Storage Testing) เป็นการทดสอบความสามารถของระบบในการเก็บข้อมูล ว่าสามารถเก็บข้อมูลได้สูงสุดเป็นจำนวนเท่าใด เพื่อจะได้เตรียมการรองรับจำนวนข้อมูลที่อาจจะเพิ่มมากขึ้นในอนาคต
5. การทดสอบกระบวนการปฏิบัติงาน (Procedure Testing) เป็นการทดสอบการจัดทำเอกสารคู่มือการดำเนินงานของระบบ และคู่มือการปฏิบัติงานสำหรับผู้ใช้นั้น ว่าสามารถสร้างความเข้าใจให้กับผู้ใช้งานได้มากน้อยเพียงใด และเมื่อเกิดปัญหาในเบื้องต้นขึ้น ผู้ใช้งานสามารถอ่านคู่มือเพื่อแก้ไขปัญหานั้นได้หรือไม่
6. การทดสอบระบบงานรวม (System Integrated Testing) เป็นการทดสอบโปรแกรมระบบงานจากการเพิ่มโปรแกรมเข้าไปเรื่อยๆ จนกระทั่งครบทุกโปรแกรมของระบบงาน ว่าโปรแกรมระบบงานทุกโปรแกรมเมื่อทำงานร่วมกันแล้วจะให้ผลลัพธ์ที่ถูกต้องหรือไม่ และหลังจากนั้นจะทดสอบโดยใช้ระบบงานย่อยเพิ่มไปเรื่อยๆ จนกระทั่งครบทุกระบบงานย่อยของระบบงานรวม เพื่อทดสอบว่าระบบงานรวมสามารถทำงานให้ผลลัพธ์ที่มีประสิทธิภาพเป็นที่ยอมรับได้หรือไม่ และเพื่อทำให้มั่นใจได้ว่าระบบงานนั้นสามารถตอบสนองความต้องการของผู้ใช้งานได้ดีที่สุด
7. การทดสอบเพื่อยอมรับระบบงานโดยผู้ใช้งาน (User Acceptance Test) หลังจากที่ได้ทดสอบความสมบูรณ์และความถูกต้องของระบบงานรวมแล้ว ยังจะต้องทำการทดสอบเพื่อยอมรับระบบงานโดยผู้ใช้งานด้วย ซึ่งเป็นการทดสอบที่สำคัญเทียบเท่ากับการทดสอบระบบงานรวม เนื่องจากการพัฒนาระบบนั้นก็เพื่อตอบสนองความต้องการในการดำเนินงานของผู้ใช้ระบบงาน
โดยวิธีการทดสอบเพื่อยอมรับระบบงานนั้นสามารถแบ่งออกเป็น 2 ประเภท คือ
1) Alpha Testing คือ การทดสอบความสมบูรณ์ของระบบงานโดยใช้ข้อมูลที่สมมติขึ้นเพื่อทำการทดสอบ และ สมมติให้ระบบอยู่ในสถานการณ์ที่อาจจะเกิดขึ้นได้ มีการทดสอบ 4 ประการ ดังนี้
- Recovery Testing เป็นการทดสอบการกู้ระบบงาน เพื่อทดสอบว่าระบบมีประสิทธิภาพในการกู้ระบบและ ข้อมูลคืนสู่สภาวะปกติและดำเนินงานต่อไปได้ หากเกิดกรณีที่ระบบหยุดชะงักไม่สามารถทำงานได้
- Security Testing เป็นการทดสอบความปลอดภัยของระบบงานว่ามีเครื่องมือรักษาความปลอดภัยที่รัดกุม และมีประสิทธิภาพเพียงพอหรือไม่ จากสถานการณ์การลักลอบเข้าสู่ระบบหรือการลักลอบเรียกใช้ข้อมูล
- Stress Testing เป็นการทดสอบประสิทธิภาพการทำงานของระบบงานภายใต้สภาพความกดดัน เช่น จะเกิดอะไรขึ้นเมื่อผู้ใช้ป้อนข้อมูลไม่ครบทุก Field หรือจะเกิดอะไรขึ้นเมื่อมีการเข้าถึงข้อมูลในเวลาเดียวกันจากผู้ใช้หลายๆ คน เป็นต้น
- Performance Testing เป็นการทดสอบประสิทธิภาพการทำงานของระบบงานภายใต้สภาพแวดล้อมที่แตกต่างกันว่าระบบมี Response Time มากน้อยเพียงใด เช่น ระบบปฏิบัติการคอมพิวเตอร์ที่แตกต่างกัน หรือระบบเครือข่ายที่แตกต่างกัน เป็นต้น
2) Beta Testing คือ การทดสอบความสมบูรณ์ของระบบงานโดยใช้ข้อมูลจริงทำการทดสอบภายใต้สถานการณ์ที่เกิดขึ้นจริง การทดสอบประเภทนี้ถือว่าเป็นการซ้อมติดตั้งระบบเพื่อใช้งานจริง เนื่องจากเป็นการทดสอบระบบงานอย่างสมจริงไม่ว่าจะเป็นสถานการณ์ ข้อมูล ขั้นตอนการดำเนินงาน เอกสารคู่มือ การฝึกอบรม การสนับสนุนการทำงาน รวมทั้งยังเป็นการแก้ปัญหาที่พบจากการทดสอบแบบ Alpha Testing ด้วย
วงจรชีวิตของการพัฒนา Software(System Development Life Cycle)
วงจรการพัฒนาระบบ หรือ SDLC จะประกอบไปด้วย
- การกำหนดปัญหา(Problem Definition) หรือ การเลือกสิ่งที่จะนำมาพัฒนาระบบงาน(Project Identification and Selection) นับว่าเป็นขั้นตอนแรกในวงจรของการพัฒนา ขั้นตอนนี้มักจะเกิดขึ้นอย่างเป็นทางการ จากการประชุมของฝ่ายบริหาร เพื่อที่จะค้นหาวิธีการทำงานที่มีประสิทธิภาพ และ มุ่งหวังที่จะใช้แทนวิธีการทำงานแบบเดิม ปรับปรุงวิธีการทำงาน หรือ เพื่อสร้างรูปแบบบริการแบบใหม่ เป็นต้น
- การวิเคราะห์ปัญหา(Analysis) เมื่อผ่านขั้นตอนการการกำหนด หรือ เลือกโครงการที่จะทำการพัฒนาแล้ว ขั้นตอนต่อไปก็จะต้องนำเอาสิ่งที่ได้จากขั้นตอนแรกมาทำการวิเคราะห์ โดยนักวิเคราะห์ระบบจะต้องทำการ วิเคราะห์ระบบ ในขั้นตอนนี้เป็นขั้นตอนที่มีความสำคัญมาก และไม่ควรทำอย่างรีบเร่ง เนื่องจากโครงการพัฒนาจำนวนมากที่ประสบความล้มเหลวเพราะการวิเคราะห์ และออกแบบที่ไม่ถูกต้อง
- การออกแบบ(Design) จะเป็นการนำเอาสิ่งที่ได้จากการวิเคราะห์ มาออกแบบเป็นระบบงาน สำหรับการพัฒนาในขั้นตอนถัดไป เช่น การออกแบบ Form , Report, Dialoques, Interface, Files & Database, Program & Process design เป็นต้น
- การพัฒนาระบบงาน(Development) หรือ การสร้างระบบงานจริง ขั้นตอนนี้จะเป็นขั้นตอนที่นำเอาสิ่งที่ได้จากการออกแบบระบบมาทำการ Coding หรือ สร้างตัวระบบงานขึ้นมาใช้งานจริง ผู้ที่มีบทบาทสูงในขั้นตอนนี้คือ Programmer นั่นเอง
- การทดสอบ(Testing) การทดสอบระบบจะเป็นการตรวจสอบความถูกต้องของระบบงานที่ถูกสร้างขึ้นมาว่าตรงตามกับความต้องการจริงๆ หรือไม่ การ Test จะมีด้วยกัน หลายระดับ กล่าวคือ
1. การทดสอบในระดับ Module หรือ Unit test เป็นการทดสอบการทำงานโดยแยกเป็นส่วนย่อยๆ ในแต่ละ module
2.การทดสอบ Integrate test จะนำเอา module ย่อยๆ มาทำการทดสอบการทำงานเป็นกระบวนการร่วมกัน
3.System test การทดสอบโดยนำเอาโปรแกรมย่อยมาทดสอบการทำงานร่วมกันทั้งระบบ
4.Acceptance test เป็นการทดสอบขั้นสุดท้าย โดย user (มี 2 ระดับ Alfa testing using simulated data, Beta testing using real data)
- การติดตั้ง(Deployment) Direct installation, Pararell Installation, Single location installation, Phased installation
- การบำรุงรักษา(Maintenance) Obtain Maintenance Request, Transforming Request into Change, Designing Change, Implementing Change
กลยุทธ์ในการพัฒนาระบบ มีหลายกลยุทธ์ ได้แก่
SDLC ในรูปแบบ Waterfall
SDLC แบบ Wayerfall เป็นรูปแบบในการพัฒนาระบบงาน โดยแต่ละขั้นตอนเมื่อ
ดำเนินงานอยู่ ไม่สามารถย้อนกลับมายังขั้นตอนก่อนหน้าเพื่อแก้ไขข้อผิดพลาดได้
SDLC ในรูปแบบ Adapted Waterfall
SDLC แบบ Adapted Wayerfall เป็นรูปแบบในการพัฒนาระบบงานที่ปรับปรุงมาจากแบบ waterfall โดยในแต่ละขั้นตอนเมื่อดำเนินงานอยู่ สามารถย้อนกลับมายังขั้นตอนก่อนหน้าเพื่อแก้ไขข้อผิดพลาดหรือสามารถย้อนกลับข้ามขั้น โดยไม่จำเป็นต้องเป็นขั้นตอนที่ติดกันได้
SDLC ในรูปแบบ Evolutionnary
SDLC แบบ Evolutionary มีแนวความคิดที่เกิดมาจากทฤษฎีวิวัฒนาการ โดยจะพัฒนาระบบงานจนเสร็จสิ้นไน Version แรกก่อน จากนั้นจึงพิจารณาถึงข้อดีและข้อเสีย แล้วจึงเริ่มกระบวนการพัฒนาระบบงานใหม่จนได้ระบบ ใน Version ที่ 2 และ Version ต่อไปจนกว่าจะได้ระบบที่สมบูรณ์ที่สุด ซึ่งต้องการการวางแผนกำหนดเพื่อจำนวน Version ตั้งแต่เริ่มโครงการพัฒนา
หมายเหตุ การพัฒนาระบบใน Version ต่าง ๆ นั้น ไม่มีความสัมพันธ์กับระบบ ใน Version แรกแต่อย่างใด
SDLC ในรูปแบบ Incremental
SDLC แบบ Incremental มีลักษณะคล้ายคลึงกับแบบ Evolutionary แต่มีข้อแตกต่างกันตรงที่ ตัวระบบเนื่องจากระบบที่เกิดขึ้นในการพัฒนาครั้งแรกนั้นจะยังไม่ไช่ระบบที่สมบูรณ์ แต่เป็นระบบส่วนแรกเท่านั้น ( จากตัวระบบทั้งหมด )
จนเมื่อมีการพัฒนาในขั้นตอนที่ 2 จึงได้ระบบในส่วนที่ 2 เพิ่มเติมเข้าไป และจะมีการเพิ่มส่วนอื่น ๆ เข้าไปอีก จนกลายเป็นระบบที่สมบูรณ์ที่สุด แต่อย่างไรก็ตาม ยังไม่สามารถแน่ใจได้ว่าระบบที่ได้ นั้นจะเป็นระบบที่สมบูรณ์ ดังนั้นในบางครั้ง SDLC ในรูปแบบ Evolutionary อาจจะมีบทบาทในการทำให้ระบบที่พัฒนาขึ้นโดยใช้การพัฒนาในรูปแบบอื่น ๆ มีความสมบูรณ์มากยิ่งขึ้นจนได้ Version ใหม่ที่สมบูรณ์ในที่สุด
SDLC ในรูปแบบ Spiral
SDLC แบบ Spiral มีลักษณะเป็นวงจรวิเคราะห์ - ออกแบบ – พัฒนา – ทดสอบ (Analysis – Design – Implementation – Testing ) และจะวนกลับมาในแนวทางเดิม เช่นนี้เรื่อยไป จนกระทั่งได้ระบบที่สมบูรณ์
การพัฒนาระบบงานด้วย SDLC ในรูปแบบนี้มีความยืดหยุ่นมากที่สุด เนื่องจาก
1) การทำงานใน 1 วงรอบนั้น ไม่จำเป็นต้องได้ระบบ หรือส่วนของระบบที่แน่นอน
2) การทำ Analysis, Design, Implementation และ Testing ในแต่ละวงรอบนั้นจะสั้นหรือยาวเท่าใดก็ได้
3) หากไม่มีความจำเป็นใด ๆ บางขั้นตอนอาจจะถูกข้ามไปก็ได้
เมื่อมีกระบวนการทางความคิดในการพัฒนาระบบแล้ว จะต้องมีวิธีการหรือแนวทางที่จะนำกระบวนการนั้นลงมาลงมือปฏิบัติเพื่อการพัฒนาระบบนั้นเป็นผลสำเร็จจนกลายเป็นระบบที่สามารถใช้งานได้อย่างมีประสิทธิภาพ วิธีดังกล่าวเรียกว่า “Methodology “
Prototyping
ระบบต้นแบบคือระบบที่ประกอบด้วยระบบที่ถูกทดลองสร้างโดยใช้เวลาไม่นานและใช้มีค่าใช้จ่ายไม่มากนัก เพื่อให้ผู้ใช้ได้ทำการประเมินระบบ ทำให้ผู้ใช้ได้แนวคิดมากขึ้นเกี่ยวกับความต้องการของระบบของพวกเขา
• ข้อดี
– ต้นแบบมีประโยชน์สำหรับความต้องการหรือการออกแบบบางอย่างที่ไม่แน่นอนหรือยังไม่มีความชัดเจนพอ
– ต้นแบบสร้างได้เร็วและมีค่าใช้จ่ายไม่สูง
– เหมาะสำหรับงานที่ให้ความสำคัญกับ User Interface ค่อนข้างมาก
– ทำให้ User มีส่วนสำคัญในการสร้างระบบ
• ข้อเสีย
– ไม่เหมาะกับระบบใหญ่และมีความซับซ้อนมาก
– ข้ามขั้นตอนการทำการวิเคราะห์, การทำเอกสารและการทดสอบระบบ
ไม่มีความคิดเห็น:
แสดงความคิดเห็น