วิชาการวิเคราะห์และออกแบบระบบ

1. Company
LOGO
Chapter 2
The System Analysis and Design
อ.ปัทมา เจริญพร
Email: popattama@hotmail.com
ภาควิชาวิทยาการคอมพิวเตอร์
คณะวิทยาศาสตร์และเทคโนโลยี
มหาวิทยาลัยเทคโนโลยีราชมงคลธัญบุรี

2. Describe the information
systems development life cycle
(SDLC)
Explain Rapid Application
Development (RAD) and its
constituent parts : Prototype ,
Joint Application Design (JAD) ,
and Computer-aided software
engineering (Case) tools.
Describe the Agile
Methodologies and extreme
Learning objectives

3. 33
ขั้นตอนของวงจรการพัฒนาขั้นตอนของวงจรการพัฒนา
ระบบระบบ
(Steps of the SDLC)(Steps of the SDLC)
ขั้นตอนที่เป็นทางการ
(official phases)
1. สำารวจข้อมูล
(Preliminary Investi
gation)
2. วิเคราะห์ระบบ
(Systems Analysis)
3. ออกแบบระบบ
(Systems Design)
4. พัฒนาระบบ (Systems
Development)
5. ติดตั้งระบบ (Systems
Implementation)
(general phases)
1. ศึกษาความเป็นไปได้
(Feasibility Study)
2. วิเคราะห์ (Analysis)
3. ออกแบบ (Design)
4. พัฒนาและติดตั้ง
(Implementation)
5. ทดสอบ (Testing)
6. ประเมินผล (Evaluation)
หรือ
1. ศึกษาความเป็นไปได้
(Feasibility Study)
2. วิเคราะห์ (Analysis)
3. ออกแบบ (Design)
4. พัฒนา (Development)
5. ติดตั้ง (Implementation)
6. บำารุงรักษา (Maintenance)
หรือ
1. ศึกษาความเป็นไปได้
(Feasibility Study)
2. วิเคราะห์ (Analysis)
3. ออกแบบ (Design)
4. พัฒนาและติดตั้ง
(Implementation)http://en.wikipedia.org/wiki/System_Development_Life_Cycle

4. 44
วงจรการพัฒนาระบบวงจรการพัฒนาระบบ
(Systems Development Life Cycle)(Systems Development Life Cycle)
Planning
Analysis
Development
Implementation
Testing
Design
Maintenance

5. 55
ขั้นที่ขั้นที่ 1:1: การวางแผนการวางแผน
((Planning)Planning)
เป็นขั้นตอนการทำาโครงร่างแผนการพัฒนาระบบ
สารสนเทศ โดยมีภารกิจหลัก 3 กิจกรรม คือ
1. กำาหนดระบบที่ต้องการพัฒนา (Define the system to
be developed)
 ปัจจัยแห่งความสำาเร็จ (Critical Success Factor:
CSF) – ปัจจัยสำาคัญ ๆ ที่ทำาให้องค์การประสบความ
สำาเร็จ
2. กำาหนดขอบเขตของโครงการ (Set the project scope)
 ขอบเขตของโครงการ (Project scope) – กำาหนด
ความต้องการ (requirements) ของระบบให้ชัดเจน
 เอกสารกำาหนดขอบเขตของโครงการ (Project
scope document) – เขียนรายละเอียดขอบเขตของ
โครงการให้ชัดเจน ซึ่งโดยปกติจะมีความยาวไม่เกิน
1 ย่อหน้า
3. พัฒนาแผนงานของโครงการให้มีภาระงาน (tasks)
ทรัพยากร (resources) และระยะเวลา (timeframes)
 แผนงานของโครงการ (Project plan) – กำาหนดว่า
อะไร (what) เมื่อใด (when) และใคร (who) ที่เป็นผู้
ตอบคำาถามในการพัฒนาระบบ

6. 66
ขั้นที่ขั้นที่ 2:2: การวิเคราะห์การวิเคราะห์
((Analysis)Analysis)
เป็นขั้นตอนที่ผู้ใช้งาน (end users) และผู้
เชี่ยวชาญด้านเทคโนโลยีสารสนเทศทำางาน
ร่วมกันในการเก็บรวบรวมข้อมูล (gather)
ทำาความเข้าใจ (understand) และจัดทำา
เอกสารกำาหนดความต้องการของระบบที่จะทำา
มาใช้งาน โดยมีกิจกรรมหลัก ดังนี้
1. การสำารวจความต้องการการใช้งาน
(Gather the business requirements)
 ความต้องการการใช้งาน (Business
requirements) – เป็นรายละเอียดที่ผู้
ปฏิบัติงานที่มีความรู้ (knowledge
worker) ให้ข้อเสนอหรือความคิดเห็นใน
การนำาเอาระบบมาใช้งานให้ประสบความ
สำาเร็จ
การพัฒนาระบบร่วมกัน (Joint application development :JAD) –
เป็นการพบกันหรือประชุมร่วมกันของผู้ปฏิบัติงานที่มีความรู้และผู้เชี่ยวชาญด้าน
เทคโนโลยีสารสนเทศในบางช่วงเวลาอย่างต่อเนื่องหลาย ๆ วัน เพื่อที่จะกำาหนด
และทบทวนความต้องการการทำางานของระบบ
การจัดทำาเอกสารข้อกำาหนด (Requirements definition document) –
เป็นข้อกำาหนดการทำางานของระบบเบื้องต้นพร้อมกับรายละเอียดที่เป็นข้อเสนอของ
ผู้ปฎิบัติงานในรูปของภาพรวมเป็นลายลักษณ์อักษร
ความเห็นชอบ (Sign-off)- ผู้ปฏิบัติงานที่ให้ข้อมูลหรือเสนอความต้องต้องลง

7. 77
ข้อแนะนำาในการวางแผนข้อแนะนำาในการวางแผน
1. บทบาทของท่านระหว่างการวิเคราะห์ (Your role
during analysis)
 ทำาการตรวจสอบรายละเอียดข้อกำาหนดการทำางาน
ของระบบ
2. กุญแจแห่งความสำาเร็จในการวิเคราะห์ (Key to
Success)
 ต้องค้นหาข้อผิดพลาดที่อาจเกิดขึ้นให้พบก่อน
 การค้นพบข้อผิดพลาดที่เกิดขึ้นหลังวงจรการพัฒนา
ระบบ (SDLC) จะทำาให้องค์การต้องเสียค่าใช้จ่าย
มากในการแก้ไข
ค่าใช้จ่ายในการค้นพบข้อผิดพลาด

8. 88
ขั้นที่ขั้นที่ 3:3: การออกแบบการออกแบบ
((Design)Design)
การทำาข้อเสนอหรือโครงร่างทางเทคนิค
(technical blueprint) การทำางานของระบบ โดยมี
กิจกรรมหลัก 2 กิจกรรม คือ
1. การออกแบบสถาปัตยกรรมทางเทคนิค เพื่อ
สนับสนุนระบบการทำางาน (Design the technical
architecture)
• สถาปัตยกรรมทางเทคนิค (Technical
Architecture) – กำาหนดฮาร์ดแวร์
(hardware) ซอฟต์แวร์ (software) และ
อุปกรณ์ด้านโทรคมนาคม
(telecommunications) เพื่อรองรับการทำางาน
ของระบบ (run the system)
2. การออกแบบแบบจำาลองของระบบ (Design
system models)
• แบบจำาลอง (Modeling) – การทำาภาพกราฟิก
สำาหรับนำาเสนอ (representation) การ
ออกแบบ

9. 99
1. บทบาทของท่านระหว่างการออกแบบ (Your
role during design)
 ลดกระบวนการความเชี่ยวชาญด้านการ
ทำางาน
 เพิ่มการวิเคราะห์ควบคุมคุณภาพ
2. กุญแจแห่งความสำาเร็จในการออกแบบ (Key
to Success)
 กำาหนดความต้องการสำาหรับอนาคต
(future requirements)
ข้อแนะนำาในการออกแบบข้อแนะนำาในการออกแบบ

10. 1010
ขั้นที่ขั้นที่ 4:4: การพัฒนาการพัฒนา
((Development)Development)
การนำาเอารายละเอียดทั้งหมดที่ออกแบบ
ไว้ในรูปของเอกสารในขั้นการออกแบบมา
แปลเปลี่ยนให้เป็นระบบจริง (actual
system) กิจกรรมหลักในการพัฒนามี 2
กิจกรรม คือ
1. สร้างสถาปัตยกรรมทางเทคนิค (Build
the technical architecture)
2. สร้างฐานข้อมูลและโปรแกรม (Build
the database and programs)

11. 1111
1. บทบาทของท่านระหว่างการพัฒนา
(Your role during development)
 รับรองหรือยอมรับการเปลี่ยนแปลงข้อ
เสนอการทำางานของระบบ
 ติดตามความก้าวหน้าของาน
2. กุญแจแห่งความสำาเร็จในการพัฒนา
(Key to Success)
 ฉกฉวยประโยชน์ (Take advantage)
จากการเปลี่ยนแปลงด้านเทคโนโลยี
ข้อแนะนำาในการพัฒนาข้อแนะนำาในการพัฒนา

12. 1212
ขั้นที่ขั้นที่ 5:5: การทดสอบการทดสอบ
((Testing)Testing)
ตรวจสอบ (verifies) ว่า ขบวนการ
ทำางานของระบบ (system works) มี
ความถูกต้องหรือไม่ และสามารถทำางาน
ได้ตามข้อกำาหนดการทำางาน (business
requirements) ของระบบในขั้นการ
วิเคราะห์หรือไม่ โดยมีกิจกรรมหลักใน
การทดสอบ คือ:
1. เขียนเงื่อนไขการทดสอบ (Write the
test conditions)
 เงื่อนไขการทดสอบ (Test
conditions) – ขั้นตอนและราย
ละเอียดของระบบจะต้องเป็นไปตาม
ผลลัพธ์ของแต่ละขั้น

13. 1. การทดสอบระบบ (Perform the testing of the
system)
 ทดสอบหน่วยย่อย (Unit testing) – ทดสอบรหัส
(code) ของหน่วยย่อยทีละหน่วยย่อย
 ทดสอบระบบ (System testing) – ตรวจสอบ
ความถูกต้องของการทำางานของรหัสหน่วยย่อย
เมื่อทำางานร่วมกับหน่วยย่อยอื่น ๆ
 ทดสอบการบูรณาการ (Integration testing) –
ตรวจสอบการทำางานร่วมกันของแต่ละระบบ
 ทดสอบการทำางาน (Functional testing) –
ทดสอบความสามารถในการทำางานตามข้อ
กำาหนด
 ทดสอบสมรรถนะ (Performance testing) -
ทดสอบประสิทธิภาพการทำางานภายใต้สภาพ
แวดล้อมที่แตกต่างกัน
ขั้นที่ขั้นที่ 5:5: การทดสอบการทดสอบ
((Testing)Testing)

14. 1414
1. บทบาทของท่านระหว่างการทดสอบ
(Your role during testing)
 มีความเชี่ยวชาญในการประกัน
คุณภาพ
2. กุญแจแห่งความสำาเร็จในการทดสอบ
(Key to Success)
 ทดสอบแต่ละขั้นตอนให้สมบูรณ์เสมอ
ข้อแนะนำาในการทดสอบข้อแนะนำาในการทดสอบ

15. 1515
ขั้นที่ขั้นที่ 6:6: การติดตั้งการติดตั้ง
((Implementation)Implementation)
ติดตั้งหรือมอบระบบทั้งหมดให้กับผู้ใช้
งานและเริ่มใช้ระบบในงานประจำาวัน โดย
มีกิจกรรมหลัก 2 กิจกรรม คือ:
1. เขียนรายละเอียดเป็นเอกสารสำาหรับผู้ใช้งาน
 เอกสารการใช้งาน (User
documentation) – วิธีการใช้งานระบบ
แต่ละขั้นตอน
2. จัดอบรมการใช้ระบบ
 การอบรมแบบออนไลน์ (Online
training) – ฝึกอบรมผ่านอินเทอร์เน็ต
หรือใช้ CD-ROM

16. 1616
ข้อแนะนำาในการดำาเนินการข้อแนะนำาในการดำาเนินการ
1. บทบาทของท่านระหว่างการดำาเนินการ (Your
role during implementation)
 ให้ความสนใจและเอาใจใส่กับการอบรม
 เน้นการอบรมเชิงปฏิบัติการ
2. กุญแจแห่งความสำาเร็จในการดำาเนินการ (Key to
Success)
 เลือกวิธีการดำาเนินการที่ถูกต้อง
o การดำาเนินการแบบคู่ขนาน (Parallel
implementation) – ใช้ทั้งระบบเก่าและระบบ
ใหม่พร้อมกัน
o การดำาเนินการแบบก้าวกระโดด (Plunge
implementation) – ยกเลิกระบบเก่าทั้งหมด
และใช้ระบบใหม่แทน

17. 1717
ขั้นที่ขั้นที่ 7:7: การบำารุงรักษาการบำารุงรักษา
((Maintenance)Maintenance)
ติดตามและสนับสนุนระบบใหม่อย่าง
ต่อเนื่อง เพื่อให้เป็นไปตามเป้าหมาย
การทำางานขององค์การ โดยมีกิจกรรม
หลัก 2 กิจกรรม คือ:
1. สร้างระบบให้คำาปรึกษา (help desk)
สนับสนุนผู้ใช้ระบบ
 ระบบให้คำาปรึกษา (Help desk)-
กลุ่มคนกลุ่มหนึ่งที่ทำาหน้าที่ตอบคำาถามผู้
ใช้งาน
2. ปรับสภาพแวดล้อมให้สนับสนุนการ

18. 1818
1. บทบาทของท่านระหว่างการดำาเนินการ
(Your role during maintenance)
 แน่ใจว่าผู้ใช้งานทั้งหมดได้รับการ
สนับสนุนตามที่พวกเขาต้องการในการ
ใช้ระบบ
2. กุญแจแห่งความสำาเร็จในการดำาเนินการ
(Key to Success)
 ผู้ใช้งานทั้งหมดและผู้เชี่ยวชาญด้าน
เทคโนโลยีสารสนเทศต้องทำางานร่วม
กัน
ข้อแนะนำาในการบำารุงรักษาข้อแนะนำาในการบำารุงรักษา

19. 1919
ตัวแบบนำ้าตกดั้งเดิมตัวแบบนำ้าตกดั้งเดิม
((Classic Waterfall Model)Classic Waterfall Model)
เริ่มพัฒนาโดย Royce ในปี 1970
การวิเคราะห์
(Analysis)
การออกแบบ
(Design)
การพัฒนา
(Development)
การทดสอบ
(Testing)
การติดตั้ง
(Implementation)
การบำารุงรักษา
(Maintenance)
การวางแผน
(Planning)

20. 2020
ลักษณะของตัวแบบนำ้ำตกลักษณะของตัวแบบนำ้ำตก
((Characteristics of Waterfall ModelCharacteristics of Waterfall Model ))
1. รูปแบบตำยตัว เปลี่ยนแปลงได้ยำกหรืออำจไม่
สำมำรถเปลี่ยนแปลงได้
2. ใช้กระบวนกำรพัฒนำจำกบนลงล่ำง
 ในควำมเป็นจริงเป็นเรื่องยำกที่กำรดำำเนิน
โครงกำรจะเป็นลำำดับขั้นตำมลำำดับ
3. ต้องทำำให้เสร็จในแต่ละขั้นก่อนที่จะเริ่มขั้นตอน
ต่อไป
 กำรเริ่มดำำเนินโครงกำรส่วนใหญ่ไม่มีควำม
แน่นอนในด้ำนข้อกำำหนดและเป้ำหมำย และ
เป็นเรื่องยำกที่ผู้ที่เกี่ยวข้องจะระบุควำม
ต้องกำรให้เสร็จสมบูรณ์ในครำวเดียว
4. มีกำรส่งมอบและนำำไปใช้งำนจะทำำตอนท้ำยสุด
ของแต่ละขั้น ก่อนที่จะเริ่มดำำเนินกำรขั้นต่อไป
ไม่ย้อนกลับไปทำำขั้นที่ผ่ำนมำแต่ละขั้นตอนไม่

21. 2121
ตัวแบบนำ้ำตกปรับปรุงตัวแบบนำ้ำตกปรับปรุง
((Adapted Waterfall Model)Adapted Waterfall Model)
กำรวิเครำะห์
(Analysis)
กำรออกแบบ
(Design)
กำรพัฒนำ
(Development)
กำรทดสอบ
(Testing)
กำรติดตั้ง
(Implementation)
กำรบำำรุงรักษำ
(Maintenance)
กำรวำงแผน
(Planning)

22. 2222
 พัฒนำและปรับปรุงมำจำกตัวแบบนำ้ำตกตัวแบบ
เก่ำ
 เมื่อดำำเนินกำรอยู่ในขั้นตอนหนึ่งสำมำรถย้อน
กลับหรือข้ำมขั้นไปยังขั้นตอนก่อนหน้ำหรือเพื่อ
แก้ไขข้อผิดพลำด
ลักษณะของตัวแบบนำ้ำตกตัวแบบปรับปรุงลักษณะของตัวแบบนำ้ำตกตัวแบบปรับปรุง
((Characteristics of Adapted Waterfall ModelCharacteristics of Adapted Waterfall Model ))

23. 2323
ตัวแบบวิวัฒนำกำรตัวแบบวิวัฒนำกำร
(Evolutionary Model)(Evolutionary Model)
รำยละเอียดโครงกำร
(Outline Description)
เวอร์ชั่นปรับปรุง
(Intermediate versions)
ตรวจสอบ
(Validation)
เวอร์ชั่นสุดท้ำย
(Final Version)
พัฒนำ
(Development)
รำยละเอียด
(Specification)
เวอร์ชั่นแรก
(Initial Version)
กระบวนกำรพัฒนำ
(Concurrent Activities)

24. 2424
ลักษณะของตัวแบบวิวัฒนำกำรลักษณะของตัวแบบวิวัฒนำกำร
((Evolutionary Model Characteristics)Evolutionary Model Characteristics)
 เป็นต้นแบบเบื้องต้น (Exploratory
prototyping) - เพื่อทำำกำรพัฒนำควบคู่ไปกับ
กำรปรับแก้ตำมควำมต้องกำรของผู้ใช้งำน
 เหมำะสมกับ
o ระบบปฏิสัมพันธ์ขนำดเล็กและขนำดกลำง
(small or medium-size interactive
systems)
o ระบบย่อยภำยในระบบใหญ่ (parts of large
systems) เช่น ระบบติดต่อกับผู้ใช้งำน
o ระบบที่มีข้อจำำกัดด้ำนเวลำ (for short-
lifetime systems)
 เน้นกำรพัฒนำระบบที่สนองตอบควำมต้องกำร

25. 2525
ตัวแบบส่วนเพิ่มตัวแบบส่วนเพิ่ม
((Incremental Model)Incremental Model)
วิเครำะห์ ออกแบบ พัฒนำ ทดสอบ ผลผลิต #1
วิเครำะห์ ออกแบบ พัฒนำ ทดสอบ ผลผลิต #2
วิเครำะห์ ออกแบบ พัฒนำ ทดสอบ ผลผลิต #3

26. 2626
1. สำมำรถเพิ่มส่วนเพิ่มหำกมีกำรสำำรวจหรือวิเครำะห์จำกเจ้ำของ
งำนไม่ครบถ้วน
2. แต่ละขั้นมีส่วนเพิ่มในระบบ
3. ส่วนเพิ่มต้องเป็นประโยชน์ต่อผู้ใช้งำน
4. ใช้เวลำในกำรพัฒนำมำก
5. ต้องเผชิญกับปัญหำสร้ำงแล้วแก้
(Incremental(Incremental ModelModel
Characteristics)Characteristics)

27. 2727
วำงแผน
(Planning) วิเครำะห์ควำมเสี่ยง
(Risk Analysis)
พัฒนำ
(Development)
ประเมินผล
(Evaluation)
ตัวแบบวงจรตัวแบบวงจร
((SpiralSpiral Model)Model)
ตัวแบบที่ 1..n

28. 2828
ลักษณะตัวแบบวงจรลักษณะตัวแบบวงจร
((Spiral Model Characteristics)Spiral Model Characteristics)
 พัฒนำโดย Barry Boehm
 เป็นวงจรพัฒนำระบบที่ให้ควำมสำำคัญกับควำม
เสี่ยง (risk-oriented)
 แต่ละวงจรมุ่งเน้นกำรวิเครำะห์หำควำมเสี่ยง
 เป็นวงจรวิเครำะห์-ออกแบบ-พัฒนำ-ทดสอบ
จนกว่ำจะได้ระบบที่สมบูรณ์
 เริ่มจำกจุดเล็ก ๆ ค้นหำควำมเสี่ยง และกำำจัด
ควำมเสี่ยง
 แต่ละวงจรมี 6 ขั้นตอน:
o กำำหนดวัตถุประสงค์ ทำงเลือก และกำร
ควบคุม
o ค้นหำและแก้ไขควำมเสี่ยง
o ประเมินทำงเลือก
o พัฒนำระบบและตรวจสอบควำมถูกต้อง

29. เครื่องมือในกำรพัฒนำระบบ (Tools ) คือ software
ที่ช่วยสร้ำงหรือวำด Model ชนิดต่ำงๆ ตรวจสอบควำม
ถูกต้องของ Model ช่วยสร้ำงรำยงำนและแบบฟอร์ม
รวมทั้งช่วยเขียนโปรแกรมให้อัตโนมัติ เช่น
 Project Management Application
 Drawing/Graphics Application
 Computer-Aided System Engineering (CASE) Tools
 Integrated Development Environment (IDE)
 Database Management Application
 Reverse-Engineering Tools
 Code Generator Tools
Case Tools

30. เทคนิควิธีและเครื่องมือในกำรพัฒนำ
ระบบงำน
• แบบจำำลอง (Modeling)
• ต้นแบบ (Prototyping)
• ระบบช่วยในกำรออกแบบ
(Computer-Aided Systems
Engineering- CASE)
• ควำมร่วมมือในกำรพัฒนำระบบงำน
(Joint Application
Development and Rapid
Application Development)

31. แบบจำำลอง (Modeling)
เป็นกำรนำำเสนอแนวควำมคิดหรือ
กระบวนกำรในรูปแบบของภำพ ตำมที่
นักวิเครำะห์ระบบทำำกำรวิเครำะห์และ
ออกแบบ เพื่อง่ำยต่อกำรทดสอบและกำร
แก้ไข
ต้นแบบ (Prototyping)
จะเกี่ยวกับกำรสร้ำงงำนในเบื้องต้น
ของระบบสำรสนเทศและองค์ประกอบที่
เกี่ยวข้อง
ระบบช่วยในกำรออกแบบ (Computer-
Aided Systems Engineering- CASE)
ระบบช่วยในกำรออกแบบ เป็น

32. ระบบช่วยในกำรออกแบบ (Computer-Aided
Systems Engineering- CASE)
ในอดีตที่ผ่ำนมำ แผนกไอทีจะเป็นหน่วย
งำนที่คิดพัฒนำระบบสำรสนเทศ ต่อมำหลำย ๆ
บริษัทได้ค้นพบว่ำ กำรสร้ำงเป็นทีมงำนพัฒนำ
ระบบงำนที่ประกอบด้วยบุคลำกรด้ำนไอที ผู้ใช้
งำนและผู้จัดกำร สำมำรถจะทำำงำนเสร็จสมบูรณ์
ได้เร็วและมีผลงำนที่ดีกว่ำ
โดยระเบียบวิธีที่ได้รับควำมนิยม มีอยู่ 2 วิธี
คือ
• Joint Application Development

33. เครื่องมืออื่นที่ใช้พัฒนำระบบงำน (Other
Systems Development Tools)
 เช่น เวิร์ดโพซีดเซอร์ ซเพร็ดชีส เครื่องมือช่วย
สร้ำงภำพและซอฟท์แวร์ที่ช่วยในกำรนำำเสนอ ที่ได้รับ
ควำมนิยมมำกคือ วิซิโอ (VISIO)

34. ภำพรวมของระเบียบวิธีในกำรพัฒนำ
ระบบ
ระเบียบวิธีแบบดั่งเดิมคือ กำรวิเครำะห์ระบบ
เชิงโครงสร้ำง แต่ระเบียบวิธีใหม่ที่นิยมกันอย่ำง
กว้ำงขวำงคือ กำรวิเครำะห์ระบบเชิงวัตถุ
 กำรวิเครำะห์เชิงโครงสร้ำง
(Structured Analysis)
เป็นเทคนิควิธีที่ใช้ในกำรพัฒนำระบบที่รวม
กำรจัดกำรข้อมูลและโครงสร้ำงข้อมูล กำร
ออกแบบฐำนข้อมูล กำรออกแบบส่วนต่อประสำน
ผู้ใช้ โดยแบ่งออกเป็นหลำยขั้นตอน เรียกว่ำ
วงจรกำรพัฒนำระบบ (Systems
Development Life Cycle – SDLC) ประกอบ

35. Case Tools
CASE tools are productivity tools for
systems analysts that have been
created explicitly to improve their
routine work through the use of
automated support
Reasons for using CASE tools
 Increasing Analyst Productivity
 Improving Analyst-User Communication
 Integrating Life Cycle Activities
 Accurately Assessing Maintenance Changes

36. Case Tool Classifications
Upper CASE tools perform analysis
and design
Lower CASE tools generate
programs from CASE design
Integrated CASE tools perform
both upper and lower CASE
functions

37. Upper CASE Tools
Create and modify the system
design
Help in modeling organizational
requirements and defining system
boundaries
Can also support prototyping of
screen and report designs

38. Lower CASE Tools
Lower CASE tools generate
computer source code from the
CASE design
Source code is usually generated
in several languages

39. การใช้โปรแกรมเคสในองค์กร
กิจกรรมในวงจรพัฒนาระบบ
การกำาหนดและ
เลือกโครงการ
เริ่มต้นและวาง
แผนโครงการ
วิเคราะห์ ออกแบบ ปรับใช้ บำารุงรักษา
ตารางการวางแผน
ตัวแบบข้อมูลวิสาหกิจ
เคสเวิร์คสเทชั่น
กำาหนดตารางการทำางาน
แผนภาพกระแสข้อมูล
ออกแบบฟอร์มและรายงาน
ตารางการติดตั้ง
การคุมควเวอร์ชั่น

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

41. ค่าใช้จ่ายของโปรแกรมเคส
ราคาของโปรแกรมเคสแบบเบ็ดเสร็จ
(Integrated CASE environment) อยู่ที่ $5000
- $50000
ถ้ารวมค่าซอฟต์แวร์ ฮาร์ดแวร์ การฝึกอบรม
และการบำารุงรักษา มีมูลค่าสูงกว่า $3,000,000
สำาหรับระยะเวลา 5 ปี

42. รูปแบบของโปรแกรมเคส
เครื่องมือถอดรหัสวิธีการทำางานทางธุรกิจ
(Reverse Engineering)
เครื่องมือปรับรื้อวิธีการทำางานทางธุรกิจ
(Reengineering Tools)

43. เครื่องมือถอดรหัสวิธีการทำางานทางธุรกิจ
(Reverse Engineering)
เครื่องมือที่ใช้สำาหรับออกแบบข้อกำาหนด
คุณลักษณะของระบบงานหรือมอดูลของ
โปรแกรมจากรหัสโปรแกรมและคำานิยามข้อมูล
ตัวอย่าง เคสทูลที่สนับสนุนกระบวนการถอดรหัส
จะอ่านข้อมูลนำาเข้าที่เป็นโปรแกรมคอมพิวเตอร์
ซึ่งเป็นรหัสต้นฉบับต่อจากนั้นจะวิเคราะห์และดึง
ข้อมูล เพื่อนำามาแสดงในระดับของการออกแบบ
ในรูปของกราฟและข้อความ

44. เครื่องมือปรับรื้อวิธีการทำางานทางธุรกิจ
(Reengineering Tools)
ประกอบด้วยเครื่องมือช่วยในการวิเคราะห์
อัตโนมัติ หรือติดต่อกับนักวิเคราะห์ระบบ
โดยตรง หรือเปลี่ยนแปลงระบบที่มีอยู่เดิมเพื่อ
ปรับปรุงคุณภาพ หรือผลปฏิบัติงาน

45. ผลกระทบโดยทั่วไปของโปรแกรมเคสต่อ
แต่ละบุคคลในองค์กร
แต่ละบุคคล ผลกระทบโดยทั่วไป
นักวิเคราะห์ระบบ งานเป็นอัตโนมัติ
โปรแกรมเมอร์ ทำาหน้าที่รวมโค๊ดเข้าด้วย
กัน, บำารุงรักษา
ผู้ใช้ มีทักษะการใช้เคสมากขึ้น
ผู้บริหารระดับสูง กำาหนดสิทธิพิเศษและ
ทิศทางของกลยุทธ์สำาหรับ
ระบบ IS โดยใช้เคส
ผู้บริหารหน้าที่งาน ชี้แนะแนวทางเพื่อพัฒนา
โครงการ
ผู้บริหารโครงการ ควบคุมการพัฒนาโครงการ
และทรัพยากร

46. แรงผลักดันต่อองค์กรในการยอมรับ
โปรแกรมเคส
จัดหาระบบใหม่โดยใช้เวลาในการพัฒนาน้อย
ปรับปรุงผลผลิตของกระบวนการพัฒนาระบบ
ปรับปรุงคุณภาพของกระบวนการพัฒนาระบบ
ปรับปรุงทักษะของคนทำางาน
ปรับปรุงให้สามารถนำาระบบใหม่ไปใช้งาน
ที่ไหนก็ได้
ปรับปรุงการบริหารกระบวนการพัฒนาระบบ

47. แรงต่อต้านขององค์กรในการยอมรับ
โปรแกรม
ค่าใช้จ่ายสูงมากในการซื้อโปรแกรมเคส
การฝึกอบรมพนักงานมีค่าใช้จ่ายสูง
ความเชื่อมั่นขององค์กร
ขาดมาตรฐานของวิธีการพัฒนาระบบในองค์กร
โปรแกรมเคสคุกคามความมั่นคงของงาน
ขาดความมั่นใจในผลผลิตของโปรแกรมเคส

48. องค์ประกอบของโปรแกรมเคส
อัพเปอร์เคสทูล
โลเวอร์เคสทูล
ครอสไลฟไซเคิลเคส

49. ความสัมพันธ์ระหว่างเคสทูลและกิจกรรมใน
วงจรการพัฒนาระบบงาน
การกำาหนดและเลือกโครงการ
การเริ่มต้นและวางแผนโครงการ
การวิเคราะห์
การกำาหนด การจัดโครงสร้าง การสร้างและเลือก
ความต้องการ ความต้องการ ทางเลือกการออกแบบ
การออกแบบ
การออกแบบเชิงตรรกะ การออกแบบเชิงกายภาพ
การปรับใช้
การลงรหัส เอกสาร การทดสอบ การฝึกอบรม การติดตั้ง
การบำารุงรักษาระบบ
ขอบเขตของ
อัพเปอร์เคสทูล
ขอบเขตของ
โลเวอร์เคสทูล

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

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

52. โปรแกรมสร้างฟอร์มและรายงานของโปรแกรมเคส
วัตถุประสงค์ในการนำามาใช้งาน
 สร้าง ปรับปรุง และทดสอบต้นแบบของหน้า
จอคอมพิวเตอร์ ฟอร์ม และรายงาน
 กำาหนดว่าหน่วยข้อมูลใดควรนำามาแสดงหรือ
จัดเก็บสำาหรับแต่ละฟอร์มหรือรายงาน

53. เครื่องมือวิสชวลและเครื่องมือพัฒนาอื่นๆ
เครื่องมือพัฒนาแบบวิสชวล
เครื่องมือพัฒนาระบบเชิงวัตถุ
วิวัฒนาการและอนาคตของเครื่องมือ
พัฒนาระบบ

54. Techniques
คือ วิธีการที่เป็นแนวทางเพื่อช่วยให้นักวิเคราะห์ระบบ
สามารถดำาเนินกิจกรรมขั้นตอนต่างๆ ของการพัฒนา
ระบบได้อย่างมีประสิทธิภาพ เช่น
 Strategic Planning Techniques
 Project Management Techniques
 User Interviewing Techniques
 Relational Database Design Techniques
 Structured Analysis Techniques
 Structure Design Techniques
 Software-Testing Techniques
 Object-Oriented Analysis and Design Techniques

55. Methodologies
 Structured System Analysis and Design
Methodology (SSADM)
 Rapid Application Development-Based
Methodology (RAD)
 Phased Development-Based Methodology
 Prototyping-Based Methodology
 Throw-Away Prototyping-Based Methodology
 Object-Oriented Analysis and Design
Methodology

56. Structured System Analysis
and Design Methodology
(SSADM)
SSADM เป็น Methodology ที่ใช้ในการพัฒนา
ระบบ มีวิธีการปฏิบัติเป็นลำาดับขั้น (Phase) จาก
ขั้นตนหนึ่งไปสู่ขั้นตอนต่อไปและมีการใช้
Model ที่เป็นแผนภาพเพื่ออธิบายชั้นตอนการ
ทำางานและข้อมูลทั้งหมดของระบบ
 Waterfall
 Adapted Waterfall
 Advantage ?
 Disadvantage?
A na ly sis
P la nning
D e sign
Im ple m e nta tion
S y ste m

57. Rapid Application
Development-Based
Methodology (RAD)
RAD เป็น Methodology ที่พัฒนาขึ้นเพื่อ
แก้ไขจุดอ่อนของ SSADM โดยการปรับระยะ
ในวงจรการพัฒนาระบบเพื่อให้มีขั้นตอนการ
ทำางานที่รวบรัดมากขึ้น
 Prototyping
 CASE Tools
ตัวอย่างเช่น
 Phased Development-Based Methodology
 Prototyping-Based Methodology
 Throw-Away Prototyping-Based Methodology

58. Phased Development-Based
Methodology
A n a ly sis
P la nn ing
D e sign
Im ple m e nta tion
S y ste m
V e rsio n 2
A na ly sis
D e sig n
Im ple m e n ta tion
S y ste m
V e rsion 1
A na ly sis
D e sign
Im ple m e nta tio n
S y ste m
V e rsion 3
A na ly sis
 Advantage ?
 Disadvantag
e?

59. Prototyping-Based
Methodology
System Prototype
 Advantage ?
 Disadvantage?
A n a ly sis
P la nning
D e sign
Im ple m e nta tio n
S y ste m
P ro to ty pe Im ple m e nta tio n
S y ste m

60. Throw-Away Prototyping-
Based Methodology
Design Prototype
 Advantage?
 Disadvantage? A na ly sis
D e sign
Im ple m e nta tio n
D e sign
P ro to ty pe Im ple m e n ta tio n
S y ste m
P la nnin g
A na ly sis
D e sign

61. Object-Oriented Analysis and
Design Methodology (OOAD)
 Systems development methodologies and techniques based
on objects rather then data and processes.
 combines data and processes (methods) into single entities
called Objects.
 The goal is to make system elements more reusable 
improving system quality and the productivity of systems
analysis and design.
 UML (Unified Modeling Language) – Use Case Diagram

62. หลักในการพัฒนาระบบ
สารสนเทศ
 คำานึงถึงเจ้าของระบบและผู้ใช้ระบบ
 พยายามเข้าถึงปัญหาให้ตรงจุด
 กำาหนดขั้นตอนหรือกิจกรรมในการทำางาน
 กำาหนดมาตรฐานในระหว่างการพัฒนาระบบและจัดทำา
เอกสารประกอบในทุกขั้นตอน
 การปฏิบัติงาน (Activities)
 หน้าที่ความรับผิดชอบ (Responsibility)
 การตรวจสอบคุณภาพ (Quality Checks)
 เอกสารและความต้องการ
(Documentation Guidelines/Requirements)

63. หลักในการพัฒนาระบบ
สารสนเทศ (ต่อ)
การพัฒนาระบบคือการลงทุน  Cost-
effectiveness
เตรียมความพร้อมหากแผนงานหรือระบบต้องถูก
ยกเลิกหรือทบทวนใหม่
แตกระบบให้เป็นระบบย่อยๆ
ออกแบบระบบเพื่อรองรับการเติบโตและการ
เปลี่ยนแปลงในอนาคต

64. Use Case Modeling
Describes what a system does without
describing how the system does it;
that is, it is a logical model of the
system

65. Use Case Diagram
 Actor
 Refers to a particular role of a user of the system
 Similar to external entities; they exist outside of the system
 Use case symbols
 An oval indicating the task of the use case
 Connecting lines
 Arrows and lines used to diagram behavioral relationships

66. Actor
Divided into two groups
 Primary actors
• Supply data or receive information from the system
• Provide details on what the use case should do
 Supporting actors
• Help to keep the system running or provide help
• The people who run the help desk, the analysts,
programmers, and so on

67. A Use Case Always Provides
Three Things
An actor that initiates an event
The event that triggers a use case
The use case that performs the actions
triggered by the event

68. Use Case Relations
Behavioral relationships
 Communicates
• Used to connect an actor to a use case
 Includes
• Describes the situation in which a use case
contains behavior that is common to more than
one use case

69. Use Case Relations
Behavioral relationships (Continued)
 Extends
• Describes the situation in which one use case
possesses the behavior that allows the new
case to handle a variation or exception from the
basic use case
 Generalizes
• Implies that one thing is more typical than the
other thing

70. Figure 2.13 Some components of use case diagrams showing actors,
use cases, and relationships for a student enrollment example

71. Figure 2.14 Examples of use cases and behavioral
relationships for student enrollment

72. Developing Use Case
Diagrams
 Review the business specifications and
identify the actors involved
 Identify the high-level events and develop
the primary use cases that describe those
events and how the actors initiate them
 Review each primary use case to determine
the possible variations of flow through the
use case
 The context-level data flow diagram could
act as a starting point for creating a use case

73. Figure 2.15 A use case diagram representing a system used to
plan a conference

74. Developing the Use Case
Scenarios
The description of the use case
Three main areas
 Use case identifiers and initiators
 Steps performed
 Conditions, assumptions, and questions

75. Figure 2.16 A use case scenario is divided into three sections:
identification and initiation; steps performed; and conditions,
assumptions, and questions

76. Why Use Case Diagrams
Are Helpful
Identify all the actors in the problem
domain
Actions that need to be completed are
also clearly shown on the use case
diagram
The use case scenario is also
worthwhile
Simplicity and lack of technical detail