Software Engineering Process

2,334 views

Published on

Lecture #3 20111227

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,334
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
57
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Software Engineering Process

  1. 1. การพัฒนาและปรับปรุงกระบวนการ ทางด ้ านวิศวกรรมซอฟต์แวร์ วรวุฒิ รามจันทร์ เทคโนโลยีสารสนเทศและการจัดการ
  2. 2. AGENDAS 2  ภาพรวมของกระบวนการผลิตซอฟต์แวร์  แบบจําลองกระบวนการผลิตซอฟต์แวร์  รายละเอียดของแบบจําลองกระบวนการมาตรฐาน CMMI  เครืองมือและระเบียบวิธีทีใช ้ ในวิศวกรรมซอฟต์แวร์
  3. 3. กระบวนการ (Process)  กระบวนการ (Process) คือ กลุ่มของขันตอนการทํางาน ที ประกอบด ้ วยชุดกิจกรรม ข ้ อจํากัด และทรัพยากรทีจะได ้ ผลิต เป็นผลลัพธ์บางชนิดตามต ้ องการ กระบวนการโดยทัวไปจะมี ลักษณะ ดังนี 1. กระบวนการจะต ้ องระบุกิจกรรมทังหมดอย่างชัดเจน 2. กระบวนการจะใช ้ ทรัพยากรภายใต ้ ข ้ อจํากัดต่างๆ เพือผลิต เป็นผลิตภัณฑ์ทีแล ้ วเสร็จ 3. กระบวนการหนึง อาจประกอบขึนจากกระบวนการย่อยอืนๆ ทีมีความสัมพันธ์กัน 3
  4. 4. กระบวนการ (Process) -2 4. ทุกกิจกรรมของกระบวนการจะมีเงือนไขในการเริมต ้ นและ สินสุดกิจกรรม 5. ทุกขันตอนและทุกกิจกรรมของกระบวนการจะต ้ องมีเป้าหมาย อย่างชัดเจน และต ้ องมีหลักการหรือแนวทางในการปฏิบัติเพือให ้ บรรลุเป้าหมายนัน 6. ข ้ อจํากัดหรือเงือนไขสามารถนํามาใช ้ ควบคุมการดําเนิน กิจกรรม การใช ้ ทรัพยากร หรือแม ้ กระทังตัวผลิตภัณฑ์เองได ้ 4
  5. 5. กระบวนการซอฟต์แวร์ (Software Process)  กระบวนการซอฟต์แวร์ หมายถึงกลุ่มของกิจกรรม วิธีการ วิธีการ ปฏิบัติ และการเปลียนแปลงทีใช ้ ในการพัฒนาและบํารุงรักษา ซอฟต์แวร์ ตลอดจนผลิตภัณฑ์ทีเกียวเนือง  กระบวนการซอฟต์แวร์ประกอบด ้ วย คน วิธีการ และเครืองมือ 5
  6. 6.  กิจกรรมพืนฐานทังหมด4 กิจกรรม ทีใช ้ กับกระบวนการผลิต ซอฟต์แวร์ – การกําหนดคุณสมบัติซอฟต์แวร์(Software Specification) – การออกแบบและสร ้างซอฟต์แวร์(Software Design and Implementation) – การทวนสอบซอฟต์แวร์ (Software Validation) – การวิวัฒนาการของซอฟต์แวร์(Software Evolution) 6 กระบวนการซอฟต์แวร์ (Software Process) -2
  7. 7. 1. software specification นิยามหน้าทีต่างๆทีต ้ องมีในซอฟต์แวร์ และระบุข ้ อจํากัดต่างๆ ทีเกียวข ้ อง กับกระบวนพัฒนาซอฟต์แวร์ เช่น กฎหมาย, อัตราภาษี , กฎระเบียบต่างๆที เกียวในการพัฒนาซอฟต์แวร์ 2. Software Design and Implementation กิจกรรมนีทําการสร้าง/ พัฒนาซอฟต์แวร์ให ้ ตรงกับข ้ อกําหนด (specification) 3. software validation กิจกรรมนีทําการตรวจสอบความถูกต ้ องของซอฟต์แวร์ เพือให ้ เกิดความมันใจ ว่าซอฟต์แวร์ทีผลิตขึนได ้ ตรงกับความต ้ องการของลูกค ้ า 4. software evolution ในทางปฎิบัติ เมือซอฟต์แวร์ใช ้ งานได ้ ระยะหนึงแล ้ ว ผู้ ใช ้ หรือลูกค ้ าอาจมี ความต ้ องการเพิมเติมหรือเปลียนแปลงความต ้ องการบางอย่าง ดังนันขันตอน การพัฒนาซอฟต์แวร์ ต ้ องมีการเตรียมการบางอย่างเพือจัดการกับเหตุการณ์ ทีคาดหมายว่าจะเกิดขึนในอนาคต 7 กระบวนการซอฟต์แวร์ (Software Process) -3
  8. 8.  กระบวนการทางซอฟต์แวร์ คือกรอบงานของการสร้างซอฟต์แวร์ ทีมีคุณภาพสูง กระบวนการทางซอฟต์แวร์เป็นตัวกําหนด แนวทางทีซอฟต์แวร์จะถูกสร้างขึน ในขณะทีวิศวกรรม ซอฟต์แวร์จะรวมไปถึงเทคโนโลยีในกระบวนการ ได ้ แก่ วิธีเชิง เทคนิค และเครืองมือทันสมัยต่างๆ 8 กระบวนการซอฟต์แวร์ (Software Process) -4
  9. 9.  หากกล่าวถึงวิศวกรรมซอฟต์แวร์ ในแง่ของการเป็นเทคโนโลยี ของการผลิตซอฟต์แวร์แล ้ ว วิศวกรรมซอฟต์แวร์จะเป็น เทคโนโลยีชนิดทีเรียกว่า“เทคโนโลยีแบบชัน” (Layered Technology)  การดําเนินงานวิศวกรรมซอฟต์แวร์ จะประกอบไปด ้ วยระดับชัน ดังนี คุณภาพ (Quality) กระบวนการ (Process) ระเบียบวิธี(Methods) เครืองมือ(Tools) 9 กระบวนการซอฟต์แวร์ (Software Process) -5
  10. 10. กิจกรรมทัวไปภายในกระบวนการ  การสือสาร (Communication)  การวางแผน (Planning)  การสร ้างแบบจําลอง(Modeling)  การสร ้าง(Construction)  การติดตัง/ใช ้ งาน(Deployment) 10
  11. 11.  การติดตามและควบคุมโครงการซอฟต์แวร์(Software Project Tracking and Control)  การจัดการความเสียง (Risk Management)  การประกันคุณภาพของซอฟต์แวร์ (Software Quality Assurance)  การพิจารณาด ้ านเทคนิค(Formal Technical Reviews)  การวัด (Measurement)  การจัดการโครงแบบของซอฟต์แวร์ (Software Configuration Management)  การเตรียมและการผลิตชินงาน(Work Product Preparation and Production) 11 กิจกรรมในกระบวนการซอฟต์แวร์
  12. 12. แบบจําลองกระบวนการพัฒนาระบบ (Process Model)  หมายถึง การจําลองภาพของกระบวนการ เพือให ้ เห็นถึงการจัด โครงสร ้างลําดับขันตอนของกระบวนการในรูปแบบทีแตกต่าง กันออกไป  แบบจําลองกระบวนการ (Software Process Model) – Linear Process Model – Incremental Process Model – Evolutionary Process Model – Specialize Process Model 12
  13. 13. Linear Process Model  The Linear Model หรือ Classic Life Cycle, Waterfall Model The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. 13
  14. 14. Waterfall Model  Waterfall Model เรียกได ้ ว่าเป็นClassic Life Cycle ซึง หมายถึง แบบระเบียบวิธีเรียงลําดับเป็นระบบในการพัฒนา ซอฟต์แวร์ 14
  15. 15.  ข ้ อเสียของWaterfall Model 15 Waterfall Model -2
  16. 16. Incremental Process Model  แบบจําลองค่อยเพิมขึน(The Incremental Model) The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. 16
  17. 17. Incremental Process Model -2  แบบจําลองแบบเร่งรัด (RAD Model) 17
  18. 18. Evolution Process Model  เป็นแบบจําลองทีมีการทํากิจกรรมในลักษณะซํา(Iteration) การสร ้างต ้ นแบบ(Prototyping)  ผู้ ใช ้ ไม่สามารถบอกความต ้ องการได ้  สร้างแบบจําลองให ้ The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. 18
  19. 19. การสร ้ างต ้ นแบบ(Prototyping)  ขันตอนการทํา Prototype 1. ตังเป้าหมาย (Objective) 2. เลือก Function ที Meet Objective 3. สร ้าง 4. ให ้ ผู้ ใช ้ ดูแล ้ วขอFeedback 19
  20. 20.  การสร ้างต ้ นแบบ มี3 ลักษณะ 1. เพือวิเคราะห์ความต ้ องการของผู้ ใช ้ 2. เพือขยายให ้ เป็นระบบทีปฏิบัติงานจริง 3. เพือหาทางแก ้ ปัญหาทีดีทีสุด เพือใช ้ เป็นเครืองมือในการ ทดลอง 20 การสร ้ างต ้ นแบบ(Prototyping) -2
  21. 21. Evolution Process Model  ตัวอย่างแบบจําลองสไปรัล (The Spiral Model) The image cannot be displayed. Your computer may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the image and then insert it again. 21
  22. 22. The Unified Process - Inception (เริมต ้ น) - Elaboration (วางแผน) - Construction (สร้าง) - Transition (ปรับแต่ง) - Production (ผลิตภัณฑ์) 22
  23. 23. แบบ จําลอง ความต้องการ การสนอง ต่อผู้ใช้ ระดับ ความเสียง เทคนิค การใช้งาน ขอบเขต องค์ความรู้ จุดมุ่งเน้น Waterfall  เรียบง่าย ครั งคราว ไม่มี/ น้อยหากใช้ กับระบบเล็ก  การทดลอง  พืนฐาน  แก้ปัญหา  ใช้กับงาน เล็กๆ Prototype  เรียบง่าย  ต้องการทดสอบและยืนยัน เทคโนโลยีทีจะนําไปใช้ บ่อยครั ง จนกว่าจะ อนุมัติต้นแบบ น้อยมาก  การทดลอง  การพิสูจน์  สร้างต้นแบบ  ทัวไป  เทคโนโลยี  แก้ปัญหา  สร้าง ต้นแบบ RAD  เรียบง่าย, รวดเร็ว  มีการแยกชินส่วน เพือทีจะ กระจายแผนงาน แล้วนําส่วนที แยกชินมาประกอบเป็นชินใหม่ อีกครั ง บางครั ง แต่ ขอบเขตต้อง ชัดเจน ปานกลาง  การทดลอง  การ บริหารงานเป็น ทีม  เชียวชาญ  สร้าง ระเบียบวิธี ปฏิบัติและ สถาปัตยกรรม Incremental  มีข้อกําหนดคุณสมบัติทัวไป ฟังก์ชัน และการนําไปใช้งาน บ่อยครั งมาก จนกว่าข้อกําหนด ทังหมดจะชัดเจน ปานกลาง  การจัดการ สภาพแวดล้อม  ทําเพิมทีละ ส่วน  เชียวชาญ สูง  สร้างยุทธวิธี เพือแก้ปัญหา ในการ นําไปใช้งาน Spiral  มีความสลับซับซ้อน  มีข้อกําหนดขนาดใหญ่  มีกระบวนการหลายขันตอน  มีการทดสอบเทคโนโลยี บ่อยจนกว่าจะได้ ระบบงานที ต้องการ สูง  การ ผสมผสาน  การจัดการ เทคโนโลยีแบบ หลากหลายมิติ  เชียวชาญ สูงมาก  สร้าง เครืองมือและ เทคโนโลยี ใหม่ๆ เพือใช้ แก้ปัญหาแบบ มีส่วนร่วมกับ ลูกค้า23
  24. 24. ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด ้ วยแบบจําลองมาตรฐาน กระบวนการผลิตซอฟต์แวร์ (Software Process) มีให ้เลือกมากมาย หลายรูปแบบ แต่ละรูปแบบยังสามารถเลือกระเบียบวิธีปฏิบัติและเครืองมือทีจะ นํามาใช ้ ได ้ อีกหลายชนิด แต่งานของวิศวกรรมซอฟต์แวร์ไม่ได ้ มีเพียงการผลิต ซอฟต์แวร์เท่านัน เป้าหมายสําคัญ คือการผลิตซอฟต์แวร์ให ้มีคุณภาพ และคํา ว่างไม่ได ้เกิดขึนทีตัวผลิตภัณฑ์ซอฟต์แวร์เพียงอย่างเดียว แต่ยังต ้องเกิด ขึนกับกระบวนการผลิตซอฟต์แวร์ทีเลือกใช ้ด ้วย จึงจะส่งผลให ้ผลิตภัณฑ์ ซอฟต์แวร์มีคุณภาพสูงสุด 24
  25. 25. Capability Maturity Model Integration เป็ นแบบจําลองทีนํามาใช ้เพือการปรับปรุงกระบวนการพัฒนา ซอฟต์แวร์ไปสู่คุณภาพ แบบจําลอง CMMI มีลักษณะเป็ นระดับชันเพือใช ้ วัดความสามารถ ขององค์กรหรือบริษัทพัฒนาซอฟต์แวร์ ทําให ้ทราบว่าองค์กรจะต ้ องปรับปรุง กระบวนการให ้เติบโตขึนในระดับต่อไป โดยระดับสูงสุดของแบบจําลองนันจะ หมายถึงมีวุฒิภาวะหรือมีความสามารถสูงสุด(Optimizing) ทําให ้เกิดคุณภาพ แก่องค์กรเอง และสร้างความเชือมันต่อลูกค ้ าให ้ เป็นอย่างดี 25
  26. 26. ระดับที 5 ดุลยภาพ (Optimizing) ระดับที 4 สถิติและการ จัดการ (Quantitatively Managed) ระดับที 3 การจัดองค์กร (Defined) ระดับที 2 การบริหาร โครงการ (Managed) ระดับที 1 การเริมต ้ น (Initial) มีการปรับปรุงกระบวนการอย่างต่อเนือง มีการควบคุมกระบวนการ มีการพัฒนากระบวนการ มีสภาพแวดล้อมทีมันคง การบริหารการเปลียนแปลง การบริหารเชิงปริมาณ การบริหารวิศวกรรม การบริหารโครงการ Capability Maturity Model Integration -2 26
  27. 27. วุฒิภาวะระดับที1 ระดับการเริมต ้ น(Initial Level) วุฒิภาวะในระดับนี องค์กรไม่มีความแน่นอนในการพัฒนาและการ บํารุงรักษาซอฟต์แวร์ ปัญหาทีพบคือ การไม่บรรลุถึงข ้อตกลงต่างๆ ทีต ้อง ปฏิบัติตามกระบวนการอย่างเป็ นขันตอนทีได ้ กําหนดไว ้ กล่าวคือ วิศวกรขาด ความสนใจหรือละเลยในการดําเนินงานตามแผนงาน หรือไม่มีการวางแผน งานใดๆ ไว ้ ล่วงหน้าเลย ซอฟต์แวร์จึงถูกผลิตขึนมาตามความต ้ องการของตน เสียเป็นส่วนใหญ่ ดังนันการผลิตซอฟต์แวร์ในระดับนีต ้ องคํานึงถึงประสบการณ์ และความสามารถของหัวหน้างานและทีมงาน หากหัวหน้างานและทีมงานมี ศักยภาพสูง การผลิตซอฟต์แวร์ก็จะมีคุณภาพสูงตามไปด ้วย ซึงความรู้และ ประสบการณ์อยู่ทีตัวบุคคลหากบุคคลเหล่านีลาออกก็จะส่งผลกระทบกับการ ดําเนินงาน ซึงหากองค์กรใดอยู่ในระดับนีนับว่าเป็นการดําเนินงานทีไม่มีเครือง นําทางไปสู่คุณภาพ 27
  28. 28. วุฒิภาวะระดับที2 ระดับการบริหารโครงการ (Managed Level) วุฒิภาวะในระดับนี องค์กรจะมีการกําหนดนโยบาย การจัดตังทีมงาน และการบริหารโครงการซอฟต์แวร์ เป็ นไปอย่างมีแบบแผนชัดเจน การผลิต ซอฟต์แวร์ในระดับนีต ้องคํานึงถึงนโยบายและความมีระเบียบวินัยเป็ นสําคัญ ทังยังมีการติดตามผลการทํางานตลอดเวลา โดยเฉพาะทางด ้านต ้นทุนและ ระยะเวลาในการทังนี เพือให ้การดําเนินงานบังเกิดผลในทางปฏิบัติ การ ดําเนินงานในลักษณะนี เริมมีการวัดผลการทํางานตังแต่ในระดับที2 นี โดย พิจารณาจากต ้นทุนและระยะเวลาทีใช ้และการวัดในด ้านอืน ๆ ทีเกียวข ้อง ทังหมด 28
  29. 29. วุฒิภาวะระดับที3 ระดับการจัดองค์กร (Defined Level) วุฒิภาวะในระดับนี เป็ นผลต่อเนืองจากวุฒิภาวะระดับที 2 โดย มุ่งเน้นการกํากับ ติดตาม และควบคุมกระบวนการต่างๆ ผ่านทางเอกสารที ได ้กําหนดนิยามไว ้ในทุกๆ ขันตอน(Documented and Integrated Process) ไม่ว่าจะเป็ นการพิสูจน์ การตรวจสอบ หรือแม ้แต่การปรับเปลียน ใดๆ ให ้เกิดความเหมาะสมก็ตาม ดังนัน การผลิตซอฟต์แวร์ในระดับนีต ้อง คํานึงถึงการจัดการด ้านเอกสารประกอบการปฏิบัติงาน (Document Management) เป็นสําคัญ 29
  30. 30. วุฒิภาวะระดับที4 สถิติการจัดการ(Quantitatively Managed Level) วุฒิภาวะในระดับนี องค์กรมีการกําหนดมาตรฐาน(Standard) เพือ ใช ้ เป็นบรรทัดฐานในการประเมินกระบวนการรวมไปถึงคุณภาพของซอฟต์แวร์ ไม่ว่าจะเป็ นการวางแผน การพยากรณ์ การควบคุม หรือแม ้แต่การวัดคุณภาพ โดยจะต ้ องได ้ รับการปรับปรุงอย่างต่อเนืองภายในขอบเขตทีกําหนดไว ้ ดังนัน การผลิตซอฟต์แวร์ในระดับนีต ้องคํานึงถึงมาตรฐานและการปรับปรุงอย่าง ต่อเนืองเป็นสําคัญ 30
  31. 31. วุฒิภาวะระดับที5 ระดับดุลยภาพ (Optimizing Level) วุฒิภาวะในระดับนี ถือได ้ว่าเป็ นองค์กรแห่งการเรียนรู้(Learning Organization) นอกจากจะมีประสบการณ์อันยาวนานในการปรับปรุง กระบวนการต่างๆ ได ้อย่างมีประสิทธิภาพแล ้ว ยังมีขีดความสามารถในการ จัดสรรทรัพยากรได ้อย่างคุ้มค่าและเหมาะสมทีสุด ตลอดจนมีเทคโนโลยี (Technology) และฐานองค์ความรู้ (Knowledge Based) สําคัญๆ ทีจะช่วย ส่งเสริมศักยภาพในการสร้างสรรค์นวัตกรรม(Innovation) ใหม่ๆ ได ้อีกด ้ วย ดังนันการผลิตซอฟต์แวร์ในระดับนีต ้องคํานึงถึงความคิดสร้างสรรค์ในแง่ของ นวัตกรรมและการจัดสรรทรัพยากรได ้ อย่างเหมาะสม 31
  32. 32. คุณลักษณะและกระบวนการสําคัญของ CMMI ระดับCMMI คุณลักษณะ กระบวนการในแต่ละด้าน PA 1. Initial • ไม่เป็ นระเบียบ • ไม่สามารถกระทําซําได ้ • มีความเสียงสูงมาก • ไม่มีการกําหนด 2. Managed • มีนโยบายชัดเจน • สามารถกระทําซําได ้ • ไม่มีการปรับปรุง • การวิเคราะห์ความต ้ องการ • การวางแผนโครงการ • การประกันคุณภาพซอฟต์แวร์ • การจัดหารผู้ รับช่วงหรือผู้ รับจ้ าง • การจัดสภาพแวดล ้ อมซอฟต์แวร์ 3. Defined • มีการปรับปรุงประสิทธิภาพในด ้ านต ้ างๆ ได ้แก่ ต ้ นทุน กําหนดการ คุณภาพ และความเสียง • การจัดการกระบวนการด ้ วยเอกสาร • การบูรณาการองค์กร • การฝึกอบรม • การจัดการด ้ านทรัพยากรบุคคล • การสนับสนุนการผลิตซอฟต์แวร์ 4.Quantitatively Managed • มีประสบการณ์ • มีการปรับปรุงประสิทธิภาพอย่างต่อเนือง • การจัดการกระบวนการเชิงปริมาณ • การจัดการคุณภาพซอฟต์แวร์ 5. Optimizing • มีประสิทธิภาพในทุกๆ ด ้ าน • มีการปรับปรุงการเรียนรู้ • มีการสังสมประสบการณ์ • มีฐานองค์ความรู้(ผู้ เชียวชาญ) • มีคุณภาพสูงและมีความเสียงน้อย • การสร ้ างสรรค์นวัตกรรม • การบริหารความเปลียนแปลง • การจัดสรรทรัพยากร 32
  33. 33. เครืองมือและระเบียบวิธีทีใช ้ ในการวิศวกรรมซอฟต์แวร์ เครืองมือ (Tools) สําหรับการผลิตซอฟต์แวร์ คือซอฟต์แวร์ คอมพิวเตอร์ทีมีวัตถุประสงค์เพือช่วยให ้การทํางานในกระบวนการผลิต ซอฟต์แวร์สะดวกขึน เครืองมือสําหรับงานวิศวกรรมซอฟต์แวร์ก็ เช่นเดียวกัน คือ ช่วยให ้ ทีมงานสามารถทํางานซําๆ เดิมได ้ ง่ายและรวดเร็ว ลดภาระการเรียนรู้ของวิศวกรซอฟต์แวร์ลงได ้มากวิศวกรซอฟต์แวร์จึงมี เวลาในการสร้างสรรค์การทํางานในกระบวนการได ้มากขึน โดยทัวไป เครืองมือต่างๆ ทีนํามาใช ้ ในกระบวนการวิศวกรรมซอฟต์แวร์ ถูกออกแบบ มาให ้เหมาะสมกับ ระเบียบวิธี(Method / Methodology) ปฏิบัติงาน วิศวกรรมซอฟต์แวร์ทีแตกต่างกันไป เพือช่วยให ้วิศวกรซอฟต์แวร์มีสิง อํานวยความสะดวกในการจัดการงานทีหลากหลายแต่อยู่ภายใต ้ ระเบียบวิธี เดียวกันได ้ง่ายขึน โดยจะทําให ้การทํางานของทีมงานเป็ นระบบและมี ระเบียบมากขึน 33
  34. 34. • Project Management Application ( เช่น Microsoft Project) • Word Processor / Text Editor • Integrated Development Environment (IDE) • Drawing / Graphics Application(เช่น Rational Rose, Visible Analyst, Visual Paradigm, SmartDraw, Visio) • Computer-Aided System Engineering (CASE) • Database Management Application • Code Generator Tool เครืองมือและระเบียบวิธีทีใช ้ ในการวิศวกรรมซอฟต์แวร์-2 34
  35. 35. CASE Tools CASE (Computer-Aided Software Engineering) หมายถึง ซอฟต์แวร์ทีเป็ นเครืองมือทีมีส่วนช่วยสนับสนุนการทํางานในกิจกรรมต่างๆ ของงานวิศวกรรมซอฟต์แวร์ ไม่ว่าจะเป็ นการวิศวกรรมความต ้องการ การ ออกแบบ การเขียนโปรแกรม และการทดสอบโปรแกรม ดังนันซอฟต์แวร์ที เป็ น CASE Tool ต ้องมีฟังก์ชันต่างๆ ให ้ทีมงานได ้เลือกใช ้ เช่น หน้าต่าง ออกแบบโปรแกรม (Design Editor) พจนานุกรมข ้ อมูล(Data Dictionary) คอมไพเลอร์ (Compiler) และดีบักเกอร์ (Debugger) เป็นต ้ น 35
  36. 36. CASE Tools สามารถจําแนกได ้หลายประเภท โดยมีหลักการ จําแนกหลายอย่าง ไม่ว่าจะเป็ นการจําแนกตามหน้าทีของCASE Tools เหล่านัน (Functional Perspective) จําแนกตามกระบวนการทํางาน (Process Perspective) และจําแนกตามการประสานเข ้ ากันCASE Tools อืนๆ (Integration Perspective) โดยหากจําแนกตามกระบวนการทํางาน ขันตอนต่างๆ แล ้ ว สามารถแบ่งCASE Tools ออกเป็น 8 กลุ่ม ดังนี ชนิดของ CASE 36
  37. 37. ชนิดของ CASE -2  เ ค รื อ ง มือ สํ า ห รั บ ก า ร วิเ ค ร า ะ ห์ค ว า ม ต ้อ ง ก า ร (Software Requirement Tools)  เครืองมือออกแบบซอฟต์แวร์ (Software Design Tools)  เครืองมือสร้างซอฟต์แวร์(Software Construction Tools)  เครืองมือทดสอบซอฟต์แวร์(Software Testing Tools)  เครืองมือบํารุงรักษาซอฟต์แวร์(Software Maintenance Tools)  เครืองมือจัดการโครงแบบ (Software Configuration Management Tools)  เครืองมือบริหารงานวิศวกรรมซอฟต์แวร์ (Software Engineering Management Tools)  เครืองมือคุณภาพซอฟต์แวร์(Software Quality Tools) 37
  38. 38. ระเบียบวิธี หรือ กรรมวิธี ในการปฏิบัติงานวิศวกรรมซอฟต์แวร์ จะกําหนดนิยาม ของกิจกรรมต่างๆ ขันตอนการดําเนินกิจกรรม และข ้ อแนะนําการตรวจสอบการทํางาน • Heuristic Methodology เป็ นระเบียบวิธีทีไม่เป็ นแบบแผน (Informal Method) กล่าวคือ ไม่มีการนํา วิธีการทางคณิตศาสตร์เข ้ามาใช ้ ในขันตอนต่างๆMethodology ทีอยู่ในกลุ่ม Heuristic ประกอบด ้วยStructured Methodology/Approach, Object – Oriented Methodology และ Data-oriented Methodology โดย Data-oriented Methodology เป็ นวิธีการที มุ่งเน้นทีข ้อมูลทีโปรแกรมจะต ้องเข ้าไปดําเนินการ ซึงต่างจากStructure ทีมุ่งเน้นที หน้าทีการทํางานของโปรแกรม และObject-oriented ทีพิจารณาทังข ้อมูลและหน้าทีการ ทํางานไปพร ้ อมๆ กัน เครืองมือและระเบียบวิธีทีใช ้ ในการวิศวกรรมซอฟต์แวร์-3 38
  39. 39. Formal Methodology เป็ นระเบียบวิธีทีอาศัยวิธีการทางคณิตศาสตร์เป็ นพืนฐานการทํางาน2 ชนิด ได ้ แก่ - การระบุข ้อกําหนดอย่างมีแบบแผน(Formal Specification) เป็ น วิธีการอธิบายข ้ อกําหนดด ้ วยภาษาชนิดใดชนิดหนึง - การทวนสอบอย่างมีแบบแผน (Formal Verification) เป็ นวิธีการ ทวนสอบโดยใช ้การพิสูจน์ทางตรรกะ ช่วยให ้การทวนสอบซอฟต์แวร์มี ประสิทธิภาพมากขึน เครืองมือและระเบียบวิธีทีใช ้ ในการวิศวกรรมซอฟต์แวร์-4 39
  40. 40. Assignment -1  จากการแบ่งกลุ่มของนักศึกษา ให ้ มีการเลือกหัวข ้ อและทํารายงานเรือง ดังต่อไปนี (ส่งภายใน 9 ธันวาคม 2553 ก่อนเทียงคืน) – CMM – ITIL – ISO 12207 – ISO 29110 – TQS สอนเสริม 11 ธ.ค. 2553 14.00-16.30 40
  41. 41. THE END  นักศึกษาสามารถดาวน์โหลด เอกสารประกอบการเรียน ได้ที http://www.rabbitthailand.com 41
  42. 42. Q & A 42

×