แบบจำลองวุฒิภาวะความสามารถ

Report
1
SDLC (Software Development Life
Cycle)
 วงจรการพัฒนาระบบ คือ กระบวนการทางความคิด ( Logical
Process)ในการพัฒนาระบบสารสนเทศเพือ่ แก้ปญั หาทางธุรกิจ
และตอบสนองความต้องการของผูใ้ ช้ได้ โดยภายในวงจรนัน้ แบ่ง
กระบวนการพัฒนาออกเป็ นระยะ ( Phase ) ได้แก่ ระยะการวางแผน
( Planning Phase) ระยะการวิเคราะห์ ( Analysis Phase) ระยะ
การออกแบบ ( Design Phase) และระยะการสร้างและพัฒนา
( Implementation Phase )โดยแต่ละระยะจะประกอบไปด้วย
ขัน้ ตอน ( Steps ) ต่าง ๆ ซึง่ แต่ละโครงการพัฒนาระบบจะมีการแบ่ง
ระยะและขัน้ ตอนในแต่ละระยะแตกต่างกัน ทาให้ปจั จุบนั มีรปู แบบของวงจรการ
พัฒนาระบบแตกแขนงออกไปมาก
2
ประเภทของ SDLC
 Waterfall
 V-Shaped
 Spiral
 Increment
 Agile
3
Waterfall model
• SDLC แบบ Waterfall มี
หลักการเปรียบเสมือนกับน้าตก ซึง่ ไหลจาก
ทีส่ งู ลงทีต่ ่า และไม่สามารถไหลกลับมา
ในทางตรงกันข้ามได้อกี
• การพัฒนาระบบงานด้วยหลักการนี้
เมือ่ ทาขัน้ ตอนหนึ่งแล้วจะไม่สามารถ
ย้อนกลับมาทีข่ นตอนก่
ั้
อนหน้าได้อกี
• ซึง่ จะมองเห็นจุดอ่อนของหลักการนี้วา่
หากมีขอ้ ผิดพลาดเกิดขึน้ ทีข่ นั ้ ตอนก่อน
หน้านี้แล้ว จะไม่สามารถย้อนกลับมาแก้ไข
ได้ ดังนัน้ การพัฒนาระบบด้วยหลักการนี้
จาเป็ นต้องมีการวางแผนทีด่ ี เพือ่ ให้
สามารถป้องกันการผิดพลาดได้มากทีส่ ดุ
ซึง่ ทาได้ยากมาก ยกเว้นระบบงานนัน้ มี
รูปแบบการพัฒนาทีด่ ี และตายตัวอยู่แล้ว 4
…………………………………………………………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………………………………………………………
Waterfall model
 Waterfall Model เป็ นแบบจาลองกระบวนการพัฒนาระบบแบบดัง้ เดิม โดยมีแนวคิด




ว่ากิจกรรมหนึ่งจะเริม่ ต้นดาเนินการได้กต็ ่อเมือ่ กิจกรรมก่อนหน้าได้ทาเสร็จสิน้ สมบูรณ์แล้ว
ในปจั จุบนั นักพัฒนาระบบได้ตระหนักแล้วว่า Waterfall Model ไม่เหมาะสมกับการ
นามาใช้เป็ นแบบแผนของการพัฒนาระบบอีกต่อไป
เนื่องจากระบบในปจั จุบนั มีความซับซ้อน นักพัฒนาระบบเองไม่สามารถตอบได้อย่างแน่นอน
ว่ากิจกรรมทีไ่ ด้ดาเนินการนัน้ ได้ทาเสร็จสิน้ สมบูรณ์แล้วหรือยัง
ถ้านา Product ทีย่ งั ไม่สมบูรณ์ไปพัฒนาต่อในขัน้ ตอนกิจกรรมต่อไปก็จะทาให้
Product ทีจ่ ะได้จากขันตอนต่
้
อไปไม่สมบูรณ์เช่นกัน เปรียบเสมือนการส่งมอบความ
เสี่ยงให้กนั เป็ นทอดๆ
ตัวอย่างเช่น การวิเคราะห์ความต้องการเราไม่อาจบอกได้วา่ ความต้องการทีว่ เิ คราะห์มานัน้
เป็ นความต้องการทีถ่ กู ต้องแน่นอนและครบถ้วนสมบูรณ์ ซึง่ ในความเป็ นจริงความต้องการมี
การเปลีย่ นแปลงได้ตลอดเวลาและสามารถเกิดความต้องการใหม่ๆได้เสมอ ถ้าเรานาความ
ต้องการทัง้ หมดมาพัฒนาในครัง้ เดียวเราจะทราบอีกครัง้ ว่า ความต้องการใดทีไ่ ม่ถกู ต้องก็
ต่อเมือ่ ระบบได้พฒ
ั นาเสร็จและได้รบั การประเมินจากผูใ้ ช้แล้ว ซึง่ ใช้เวลานานกว่าจะทราบได้
5
ข้ อดีของ Waterfall
 ง่ายต่อการทาความเข้าใจ, ง่ายต่อการใช้งาน
 มีโครงสร้างทีช่ ดั เจน เหมาะสาหรับผูเ้ ริม่ ต้นในการออกแบบ
 มี Milestones ทีเ่ ข้าใจได้งา่ ย
 Sets requirements stability (ความต้องการของระบบหรือ
ความต้องการของ user ไม่เปลีย่ นแปลง หรือ เปลีย่ นแปลงน้อยมาก)
 มีการจัดการและการควบคุมทีด่ ี (plan, staff, track)
 ทางานได้ดี เพือ่ เน้นประสิทธิภาพ มากกว่าเน้นค่าใช้จา่ ยและตารางเวลาที่
จากัด
ไมล์สโตน (Milestone) หมายถึง การระบุผลผลิตของ
งาน (output) ทีต่ อ้ งการจะให้เกิดขึน้ ในแผน เพือ่ ใช้เป็ นเครือ่ งมือในการ
ตรวจสอบและติดตามผลงานทีเ่ กิดขึน้
ข้ อด้ อยของ Waterfall
 ความต้องการทัง้ หมดจะต้องถูกวิเคราะห์อย่างถูกต้องมาก่อน
 เมือ่ ส่งมอบงานแล้ว การแก้ไขแต่ละขัน้ ตอนมีความยืดหยุน่ น้อย
 อาจมีความผิดพลาดบ้างในแต่ละขัน้ ตอน
 แก้ปญั หาการพัฒนาซอฟต์แวร์ไม่ได้ทงั ้ หมด
 อาจมีปญั หาในตอนท้ายหากต้องทาการรวมกับ Module อื่น
 ลูกค้ามีโอกาสน้อยทีจ่ ะมองภาพระบบโดยรวมก่อนใช้งาน
จะใช้ Waterfall Model เมื่อไร
 ความต้องการของ User มีความแน่นอนไม่เปลีย่ นแปลง
 ระบบมีความเสถียร
 User ยอมรับเทคโนโลยีใหม่ ๆ
 การถ่ายโอนซอฟต์แวร์จาก platform เดิมไป platform ใหม่
Adapted Waterfall model
SDLC แบบ Adapted Waterfall เป็ นรูปแบบในการพัฒนา
ระบบงานทีป่ รับปรุงมาจากแบบ waterfall โดยในแต่ละขัน้ ตอนเมือ่
ดาเนินงานอยู่ สามารถย้อนกลับมายังขัน้ ตอนก่อนหน้าเพือ่ แก้ไขข้อผิดพลาด
หรือสามารถย้อนกลับข้ามขัน้ โดยไม่จาเป็ นต้องเป็ นขัน้ ตอนทีต่ ดิ กันได้
9
V-Shaped model
 เป็ น Model ทีเ่ น้นการตรวจสอบ
(verification) และการรับรอง
ความถูกต้อง(validation) ควบคู่
กันไป
 การทดสอบของผลิตภัณฑ์กระทาขนาน
กันไปกับการวางแผนในการพัฒนา
Software
10
V-Shaped model
 Project and Requirements
Planning – การจัดสรรทรัพยากร
 Production, operation and
 Product Requirements and
Specification Analysis –
กาหนด spec ทีส่ มบูรณ์ของ
Software
maintenance – การเพิม่
ประสิทธิภาพและการแก้ไข
 System and acceptance
testing – ตรวจสอบสภาพแวดล้อม
ของ Software
 Architecture or High-Level
 Integration and Testing –
 Detailed Design – การพัฒนา
 Unit testing – ตรวจสอบการ
Design – กาหนดวิธกี ารทางานที่
ตอบสนองต่อการออกแบบ Software
อัลกอริทมึ สาหรับองค์ประกอบต่าง ๆ
ตรวจสอบการเชือ่ มต่อแต่ละ Module
ว่าถูกต้องหรือไม่
ทางานของแต่ module ว่าทางาน
ถูกต้องตามเป้าหมาย
 Coding – เปลีย่ น Algorithm
เป็ น Software
11
ข้ อดีของ V-Shaped model
 เน้นการวางแผนสาหรับการ Verification และ Validation
ของผลิตภัณฑ์ในขัน้ เริม่ ต้นของการพัฒนาผลิตภัณฑ์
 งานทีส่ ง่ มอบต้องสามารถทดสอบได้ทุกขัน้ ตอน
 สามารถติดตามความก้าวหน้าได้ทุกขัน้ ตอน
 เข้าใจง่ายและใช้งานได้งา่ ย
12
ข้ อด้ อยของ V-Shaped Model
 ยากต่อการจัดการเหตุการณ์ทเ่ี กิดขึน้ พร้อมกัน
 ยากต่อการจัดการกับ Requirement ทีม่ กี าร
เปลีย่ นแปลงบ่อยๆ
 ไม่มรี ะบบการจัดการความเสีย่ ง (Risk
Management)
13
จะใช้ V-shaped Model เมื่อไร
 ใช้ในระบบทีต่ อ้ งการความเสถียรสูง (high reliability) เช่น
ระบบเกีย่ วการจัดการภายในโรงพยาบาล (hospital patient
control applications)
 ระบบทีม่ ี Requirement ทีพ
่ ร้อมและค่อนข้างครบถ้วน
14
Spiral model
15
Spiral model
แบบจาลอง spiral แบ่งออกได้เป็ นส่วนย่อยๆ โดย
ปกติจะแบ่งเป็ น 3 ส่วน หรือ 6 ส่วนงานเช่น
การติดต่อสือ่ สารกันระหว่างผูใ้ ช้ และผูพ
้ ฒ
ั นาระบบ
การวางแผน
การวิเคราะห์ความเสีย่ ง
วิศวกรรม
การสร้างและนาไปใช้
การประเมินผลจากผูใ้ ช้
16
Spiral model
แต่ละรอบของการทาซ้า
วิเคราะห์ความเสีย่ ง
พัฒนาต้นแบบสาหรับตรวจสอบความเป็ นไปได้
และความต้องการ
เมือ่ พบความเสีย่ งผูจ้ ดั การโครงการจะต้อง
ตัดสินใจทีจะกาจัดหรือลดความเสีย่ ง
17
Spiral model
แต่ละรอบของการทาซ้า
วิเคราะห์ความเสีย่ ง
พัฒนาต้นแบบสาหรับตรวจสอบความเป็ นไปได้
และความต้องการ
เมือ่ พบความเสีย่ งผูจ้ ดั การโครงการจะต้อง
ตัดสินใจทีจะกาจัดหรือลดความเสีย่ ง
18
Spiral model
ปญั หาของการใช้แบบจาลองบันไดเวียน ในการ
พัฒนาซอฟต์แวร์ คือการโน้มน้าวให้ผใู้ ช้ระบบ
เห็นชอบกับวิธกี ารทีเ่ ป็ นกระบวนทาซ้าแบบมี
วิวฒ
ั นาการ
 ความสาเร็จของการใช้ แบบจาลองบันไดเวียน
ผูพ้ ฒ
ั นาจะต้องมีความเชีย่ วชาญในด้านการ
ประเมินผลความเสีย่ ง
19
Spiral model
เป็ น model ทีใ่ ช้ความเสีย่ งเป็ นเครือ่ งตัดสินใจว่าจะ
กระทาอะไรต่อไป (risk-driven)
ขัน้ ตอนในแต่ละรอบ
 วิเคราะห์เป้าหมาย แนวทางเลือกต่างๆ เงือ่ นไขต่างๆ
 วิเคราะห์ความเสีย่ ง
 พยายามลดความเสีย่ งนัน้ เช่น ทา Prototype เพือ่ ทดสอบ
 พัฒนา product
 นา product ให้ลกู ค้าทดสอบ
20
Iterative and Incremental Model
Iteration1
Iteration2
Iteration3
Requirement1
Requirement2
Requirement3
SA
SA
SA
SD
SD
SD
Imp
Imp
Imp
Op
Op
Op
Built1
Built1
Built2
Built1
Built2 Built3
21
Iterative and Incremental Model
 เป็ นแบบจาลองกระบวนการซึง่ รองรับความไม่แน่นอนต่างๆ ที่
จะเกิดขึน้ ในการพัฒนาระบบโดยมีแนวคิดว่า การค่อยๆพัฒนา
ระบบจากเล็กไปใหญ่เป็ นการลดความเสีย่ งของการพัฒนา
 การพัฒนานัน้ ประกอบด้วยหลายรอบของ SDLC
 แต่ละรอบจะพัฒนาเฉพาะส่วน (ไม่ใช่ทเี ดียวทัง้ หมด) แล้ว
ค่อยๆ เพิม่ เติมให้ระบบใหญ่ขน้ึ จนกว่าจะเสร็จสมบูรณ์ (ผูใ้ ช้
ยอมรับ)
 ไม่อาจคาดการณ์อย่างแน่นอนได้วา่ จะต้องใช้รอบในการ
พัฒนากีร่ อบ
22
Agile Process
 Agile แปลว่ า คล่ องแคล่ ว ฉลาด ฉับไว
 Agile Process เป็ นกระบวนการผลิตซอฟต์ แวร์ รูปแบบใหม่ ทถี่ ูกกาหนด
ขึน้ ตามระเบียบวิธีปฏิบัติแบบ Agile
 เป็ นระเบียบวิธีที่แตกแขนงจาก RAD (Rapid Application
Development) ที่เน้ นการผลิตซอฟต์ แวร์ แบบเร่ งด่ วน
 ปี ค.ศ. 1970 กระบวนการผลิตซอฟต์ แวร์ มีลกั ษณะเชิงบังคับให้ ทา
ตามลาดับขั้นตอนอย่ างต่ อเนื่อง
 ปี ค.ศ. 1990 นักพัฒนาซอฟต์ แวร์ ได้ คดิ ค้ นวิธีการพัฒนาซอฟต์ แวร์ แบบ
ใหม่ ทมี่ ีอสิ ระ ทาให้ มีความคล่องตัวสู งในการทางาน วิธีนีเ้ รียกว่ า “Agile
Method”
23
Agile Process
 Agile มีบทบัญญัติ 4 ประการทีต่ ้ องคานึงเมื่อต้ องพัฒนาซอฟต์ แวร์ ดังนี้
[Agile Alliance 2001]
1. ทีมงานทุกคนมีคุณค่ าในตัวเองมากพอทีจ่ ะทางานอย่ างอิสระ
ได้
2. ทีมงานพอใจที่จะใช้ เวลาส่ วนใหญ่ ในการเขียนโปรแกรมเพือ่
สร้ างซอฟต์ แวร์ มากกว่ าการใช้ เวลาเพือ่ จัดทาเอกสาร
3. ทีมงานมุ่งเน้ นการทางานร่ วมกับลูกค้ าโดยตรง แทนการเจรจา
อย่ างเป็ นทางการตามสั ญญาว่ าจ้ าง
4. ทีมงานให้ ความสาคัญกับการแก้ไขงานทันทีที่มีการ
เปลีย่ นแปลง มากกว่ าการวางแผนก่อนลงมือทางานเมื่อมีการ
เปลีย่ นแปลง
24
Agile Process
Agile
 XP
 ASD
 Scrum
 DSDM
 Crystal
 FDD
 AM
25
Extreme Programming (XP)
 คิดค้ นโดย Kent Beck
 ค.ศ. 1999
 พัฒนาตามแบบ Iteration and Incremental
 เป็ นแบบจาลองกระบวนการผลิตซอฟต์ แวร์ ที่ใช้ แนวทางเชิง
วัตถุเป็ นหลัก
 มี 4 ขั้นตอน ได้ แก่ การวางแผน ออกแบบ เขียนโปรแกรม และ
การทดสอบ
26
Extreme Programming (XP)
User Story
Iteration Plan
Simple Design
Spike Solution : Prototype
วางแผน
(Planning)
ออกแบบ
(Design)
ทดสอบ
(Testing)
เขียนโปรแกรม
(Coding)
Release
Software Increment
Unit Test
Continuous integration
Acceptance Test
Pair Programming
Unit Test
Continuous Integrations
27
Adaptive Software Development (ASD)
 การพัฒนาซอฟต์ แวร์ แบบปรับตัว-เอเอสดีนาเสนอ โดย Jim
Highsmith
 ให้ เป็ นเทคนิคสาหรับสร้ างระบบทีซ่ ับซ้ อน
 เน้ นการทางานร่ วมกันระหว่ างบุคคล และการจัดระเบียบทีมงาน
ด้ วยตนเอง
 การเรียนรู้ ของทีมงานทีด่ ี และแบ่ งงานอย่ างเป็ นระบบและ
ชัดเจน
28
Adaptive Software Development (ASD)
Adaptive cycle planning
Mission statement
Project constraints
Basic requirements
Time-boxed release plan
Speculation
Release
Software increment
adjustments for subsequent
cycles
Collaboration
Requirements gathering
JAD
Mini-specs
Learning
Components implemented/tested
Focus groups for feedback
Formal technical reviews
postmortems
29
Adaptive Software Development (ASD)
 การคาดเดา (Speculation)
 โครงการเริ่มต้ นขึน
้ และมีการทาแผนวงจรการปรับตัว
 ใช้ ข้อมูลเบือ้ งต้ น ได้ แก่ ข้ อความแสดงภารกิจของลูกค้ า เงื่อนไขต่ าง ๆ
ของโครงการและความต้ องการพืน้ ฐาน เพือ่ กาหนดชุ ดของวงจรรีลสิ
(release) คือ รุ่นต่ าง ๆ ของซอฟต์ แวร์ ทโี่ ครงการต้ องผลิต
 การร่ วมมือ (Collaboration)
 คือ การจูงใจบุคคลให้ ทางานร่ วมกันในทางทีเ่ พิม
่ พูนผลลัพธ์ ที่
สร้ างสรรค์ และเฉลียวฉลาด
 การร่ วมมือเป็ นวิธีทใี่ ช้ ในทุก ๆ วิธีการแบบ Agile
 การร่ วมมือมักไม่ ใช่ เรื่องง่ าย
30
Adaptive Software Development (ASD)
 การร่ วมมือ (Collaboration)
 บุคคลทีท
่ างานร่ วมกันต้ องมีความไว้ วางใจกัน เพือ่
 การวิพากษ์ วจ
ิ ารณ์ โดยปราศจากความข่ มชื่น
 การช่ วยเหลือกันโดยปราศจากความเสี ยใจ
 การทางานอย่ างหนักเท่ าเทียมกัน
 มีความชานาญเฉพาะที่จะเป็ นประโยชน์ ต่องานที่ทา
 มีการพูดคุยถึงปัญหาหรื อข้ อกังวลสงสั ยในทางทีน
่ าไปสู่ การ
กระทาที่ได้ ประสิ ทธิผล
31
Adaptive Software Development (ASD)
 การเรียนรู้ (Learning)
 เมือ่ ทีมงานเริ่มพัฒนาชิ้นส่ วนทีเ่ ป็ นส่ วนหนึ่งของวงจรปรับตัว ทีมงานจะเรียนรู้ ไปพร้ อม ๆ
กับความก้ าวหน้ าไปสู่ การเสร็จสิ้นวงจร
 ทีมเอเอสดี เรียนรู้ ได้ 3 วิธีคอื
 กลุ่มเฉพาะทาง (Focus Groups) เมือ
่ ลูกค้ า/ผู้ใช้ งานให้ ผลตอบกลับในการใช้ งาน โดยแต่ ละ
รุ่นของซอฟต์ แวร์ ทสี่ ่ งมอบไป สิ่ งนีจ้ ะเป็ นตัวบ่ งชี้ว่าผลิตภัณฑ์ ได้ ตอบสนองความจาเป็ น
ทางธุรกิจหรือไม่
 การทบทวนเทคนิคอย่ างเป็ นทางการ (Formal Technical Review) ทีมเอเอสดีมก
ี าร
ทบทวนชิ้นส่ วนซอฟต์ แวร์ ทกี่ าหนดพัฒนาอยู่ ขณะเดียวกับมีกาปรังปรุ งคุณภาพและ
เรียนรู้ไปพร้ อม ๆ กัน
 การตรวจสอบภายหลัง (Postmortems) เมือ
่ งานเสร็จสิ้นแล้ ว ทีมงานกลายเป็ นผู้วจิ ารณ์
งานและคุณภาพของตนเอง ซึ่งเป็ นเป้ าหมายของการเรียนรู้เพือ่ ปรับปรุ งวิธีการทางาน
32
Scrum
Scrum พัฒนาโดย Jeff Sutherland
พัฒนาเมื่อต้ นทศวรรษ 1990
พัฒนาต่ อโดย Schwaber และ Beedle
33
Scrum
 หลักการของ Scrum คือ
 จัดตั้งทีมทางานขนาดเล็กที่ เกิดการสื่ อสาร การแบ่ งปันเทคนิค และข่ าวสารที่
ไม่ เป็ นทางการให้ มากทีส่ ุ ด ขณะทีล่ ดค่ าใช้ จ่ายส่ วนเกินให้ น้อยทีส่ ุ ด
 กระบวนการต้ องสามารถปรับเข้ ากับการเปลีย่ นแปลงทางธุรกิจและเทคนิคได้
เพือ่ ผลิตผลงานให้ ดที สี่ ุ ด
 กระบวนการต้ องผลิตรุ่ นซอฟต์ แวร์ ออกมาบ่ อย ๆ เพือ่ ตรวจสอบ ปรับแต่ ง
ทดสอบ บันทึกและต่ อยอดได้
 งานทีพ
่ ฒ
ั นาและนักพัฒนาจะแบ่ งออกเป็ น แพ็กเก็ตหรือพาร์ ติชั่นทีส่ ะอาดและ
ขึน้ แก่ กนั น้ อยทีส่ ุ ด
 มีการทดสอบและบันทึกเอกสารอย่ างสม่าเสมอขณะทีส่ ร้ างผลิตภัณฑ์ ขึน
้ มา
 กระบวนการสครัมจะต้ อง สามารถแจ้ งว่ า พัฒนาผลิตภัณฑ์ เสร็จแล้ ว เมื่อใดก็
ตามทีต่ ้ องการ อันเนื่องมาจากคู่แข่ งออกผลิตภัณฑ์ ทเี่ หมือนกัน หรือบริษัท
ต้ องการเงิน หรือลูกค้ าต้ องการงาน เป็ นต้ น
34
Scrum
 หลักการของ Scrum อยู่ภายใต้ กจิ กรรมกรอบงานต่ อไปนี้
 ความต้ องการ
 การวิเคราะห์
 การออกแบบ
 การวิวฒ
ั น์
 และการส่ งมอบ
 แต่ ละกิจกรรมกรอบงาน จะประกอบด้ วยงานย่ อย ๆ เกิดขึน้ ภายใน เป็ นแบบรู ป
กระบวนการ เรียกว่ า สปริ้น (Sprint)
 งานทีท่ าภายใต้ สปริ้นจะปรับตัวตามปัญหาที่พบขณะนั้น และถูกนิยามและ
ปรับเปลีย่ นให้ ทนั ต่ อเหตุการณ์ เฉพาะหน้ าโดยทีมงานสครัม
 Scrum สนับสนุนให้ ใช้ รูปแบบกระกวนการซอฟต์ แวร์ (Software process
pattern)
35
Dynamic System Development Method (DSDM)
 DSDM หรือวิธีการพัฒนาระบบไม่ หยุดนิ่ง เป็ นวิธีการพัฒนาซอฟต์ แวร์ ทมี่ ีการ
กาหนดกรอบงานสาหรับสร้ างและบารุ งรักษาระบบทีม่ ขี ้ อจากัดด้ านเวลา
 โดยใช้ การสร้ างต้ นแบบอย่ างค่ อยเพิม่ ขึน้
 DSDM => 80% ของแอพพลิเคชัน จะเสร็จภายในเวลา 20% ของเวลาทั้งหมดที่ใช้
พัฒนา
 DSDM เป็ นกระบวนการทาวนซ้า แต่ ละรอบของวงจรจะเป็ นไปตามกฎ 80% คือ
ทางานให้ เพียงพอเท่ าทีจ่ าเป็ นในแต่ ละรุ่ น เพือ่ ให้ เคลือ่ นไปสู่ ร่ ุ นทีเ่ พิม่ ขึน้ ถัดไป
ส่ วนรายละเอียดทีเ่ หลือสามารถทาให้ เสร็จภายหลัง เมือ่ ได้ ร้ ู ความต้ องการทาง
ธุรกิจเพิม่ เติม หรือเมือ่ ได้ รับการร้ องขอให้ เปลีย่ นแปลง
36
Dynamic System Development Method (DSDM)
 กระบวนการ DSDM
 การศึกษาความเป็ นไปได้ (Feasibility Study) จัดทาความต้ องการและข้ อจากัด
ทางธุรกิจพืน้ ฐานของแอพพลิเคชั่นทีจ่ ะสร้ าง ประเมินความเป็ นไปได้
 การศึกษาด้ านธุรกิจ (Business Study) จัดสร้ างความต้ องการเชิงข่ าวสาร และ
เชิงหน้ าทีข่ องแอพพลิเคชั่น นิยามสถาปัตยกรรมและระบุความต้ องการในการ
บารุ งรักษาแอพพลิเคชั่น
 การทาวนซ้าแบบจาลองเชิงหน้ าที่ (Functional Model Iteration) ผลิตชุ ดของ
ต้ นแบบค่ อยเพิม่ ขึน้ ทีม่ หี น้ าทีก่ ารทางานตามที่ลูกค้ าต้ องการ ต้ นแบบจะค่ อย ๆ
วิวฒ
ั นาการไปเป็ นแอพพลิเคชั่นที่ส่งมอบได้ การทาวนซ้าเป็ นการรวบรวมความ
ต้ องการเพิม่ เติมจากการตอบสนองกลับมาของผู้ใช้
37
Dynamic System Development Method (DSDM)
 กระบวนการ DSDM
 การทาวนซ้าการออกแบบและการสร้ าง (Design and Build Iteration) นา
ต้ นแบบที่สร้ างขึน้ ระหว่ างการทาวนซ้าการสร้ างแบบจาลองเชิงหน้ าทีม่ าดูใหม่
 การอิมพลีเม้ นต์ (Implementation หรือ coding) ใช้ งานรุ่ นของซอฟต์ แวร์ ล่าสุ ด
ภายใต้ สิ่งแวดล้อมการทางานจริง
 รุ่ นของซอฟต์ แวร์ อาจไม่ ต้องสมบูรณ์ ร้อยเปอร์ เซ็ นต์
 การร้ องขอการเปลีย
่ นแปลงอาจเกิดขึน้ ได้ ขณะใช้ งานอยู่
 กระบวนการ DSDM อาจใช้ ร่วมกับกระบวนการ XP เพือ่ กาหนดแบบจาลอง
กระบวนการ
38
Crystal
 พัฒนาโดย Alistair Cockburn และ Jim Highsmith
 Crystal มีความสามารถในการนาร่ อง คือ
 มีทรัพยากรจากัด ทีมงานต้ องร่ วมมือกัน ในการประดิษฐ์ และการสื่ อสาร
 โดยมีเป้ าหมายหลักคือ ส่ งมอบซอฟต์ แวร์ ทม
ี่ ีประโยชน์ ทางานได้
 เป้ าหมายรองคือ จัดเตรียมความพร้ อมสาหรับงานถัดไป
 เพือ่ ให้ บรรลุความสามารถในการนาร่ อง Cockburn และ Highsmith ได้ นิยามชุ ด
ของกรรมวิธี และกรรมวิธีมีชิ้นส่ วนหลัก ๆ เหมือน ๆ กัน และมีบทบาท
กระบวนการผลิตผลงาน และวิธีปฏิบัติที่แตกต่ างกันเฉพาะตัว
 ครอบครัวคริสตัล ก็คอื ชุ ดกระบวนการ Agile ทีไ่ ด้ พสิ ู จน์ แล้ วว่ าได้ ผลดีสาหรับ
โครงการชนิดต่ าง ๆ
39
Crystal
 วิธีการพัฒนาแบบ Crystal เน้ นทีก่ ารแบ่ งแยกงานออกตามคุณลักษณะ
ของตัวโครงงาน
 แบ่ งตามขนาดของทีมงานพัฒนา หรือแบ่ งตามความสาคัญของระบบ
และความสาคัญตามลาดับก่ อนหลังของตัวโครงงาน
 โดยการแบ่ งจะแยกออกเป็ นสี เช่ น Crystal Yellow, Crystal Orange เป็ น
ต้ น
 ทุกแบบจะมีชื่อเรียกรวมกันว่ า Crystal Family
 สาเหตุทตี่ ้ องมีการแบ่ งตามลักษณะดังกล่ าวก็เพราะว่ ามีการตระหนักถึง
ความต้ องการรู ปแบบการพัฒนาทีแ่ ตกต่ างกันไปตามแต่ ละโครงงาน
40
Crystal
Crystal จะประกอบด้ วย 3 ส่ วนที่สาคัญ คือ
“Human-powered”
o “Ultralight”
o “Stretch-to-fit”
o
41
Feature Driven Development (FDD)
 การพัฒนาทีข่ ับเคลือ่ นด้ วยคุณลักษณะของซอฟต์ แวร์
 คิดค้ น โดย Peter Coad และคณะ
 เพือ่ ใช้ เป็ นแบบจาลองกระบวนการเชิงปฏิบัติการของวิศวกรรม
ซอฟต์ แวร์ เชิงวัตถุ
 Stephen Palmer และ John Felsing ได้ ขยายและเพิม่ เติมงานของ Coad
 คุณลักษณะ หน้ าทีท่ ลี่ ูกค้ าเห็นว่ ามีคุณค่ า ทีส่ ามารถอิมพลีเมนต์ ได้ ภาย
เวลาสองสั ปดาห์ หรือน้ อยว่ า
42
Feature Driven Development (FDD)
 นิยามของคุณลักษณะให้ ประโยชน์ ต่อไปนี้
 เนื่องจากคุณลักษณะเป็ นส่ วนเล็ก ๆ ของซอฟต์ แวร์ ทท
ี่ างานได้ ผู้ใช้ จึงสามารถอธิบายได้ ง่าย




เข้ าใจความสั มพันธ์ ระหว่ างกันได้ ง่ายกว่ า และสามารถทบทวนได้ ดกี ว่ าเมือ่ มีความ
คลุมเครือ ข้ อผิดพลาด หรือการหลงลืม
คุณลักษณะอาจถูกจัดระเบียบ เป็ นกลุ่มลาดับชั้นทีม่ คี วามสั มพันธ์ ทางธุรกิจได้
เนื่องจากลักษณะเป็ นรุ่น ๆ ของคุณลักษณะของซอฟต์ แวร์ ทตี่ ้ องส่ งมอบได้ ในการพัฒนา
แบบ FDD ทีมงานจะมุ่งพัฒนาซอฟต์ แวร์ ให้ มคี ุณลักษณะใหม่ ๆ ทีท่ างานได้ ทุก ๆ สอง
สั ปดาห์
เนื่องจากคุณลักษณะมีขนาดเล็ก ตัวแบบและตัวโค้ ดของคุณลักษณะจึงง่ ายต่ อการตรวจทาน
อย่ างละเอียด
การวางแผนโครงการ การจัดตารางงาน และติดตามจะขับเคลือ่ นด้ วยคุณลักษณะตามลาดับ
ชั้น ซึ่งดีกว่ าการใช้ ชุดงานย่ อยทีเ่ ลือกมาแบบสุ่ ม
43
Agile Modeling (AM)
 การสร้ างแบบจาลองเพือ่
 เพือ่ เข้ าใจส่ วนประกอบทั้งหมดว่ ามีอะไรทีจ่ าเป็ นต้ องทา
 เพือ่ แบ่ งปัญหาออกเป็ นส่ วน ๆ ให้ เหมาะสมกับผู้ทจี่ ะทางานนี้
 เพือ่ ให้ สามารถประเมินคุณภาพได้ ทุก ๆ ขั้นตอนเมือ่ ระบบกาลังถูกประกอบขึน
้ มา
 Scott Amble อธิบายการสร้ างแบบจาลองของ Agile
 การสร้ างแบบจาลอง Agile เป็ นวิธีการเชิงปฏิบตั กิ ารสาหรับการสร้ างแบบจาลอง และการ
บันทึกเอกสารของระบบซอฟต์ แวร์ ทไี่ ด้ ผล กล่ าวอย่ างง่ าย การสร้ างแบบจาลอง Agile เป็ น
การรวบรวมคุณค่ า หลักการ และหลักปฏิบตั ิ สาหรับการสร้ างแบบจาลองซอฟต์ แวร์ ที่
สามารถประยุกต์ กบั โครงการพัฒนาซอฟต์ แวร์ อย่ างได้ ผล ในลักษณะทีม่ นี า้ หนักเบา
แบบจาลอง Agile ได้ ผลดีกว่ าแบบจาลองแบบดั้งเดิม เพราะเพียงพอแก่ การใช้ งานโดยไม่
จาเป็ นต้ องสมบูรณ์ แบบ
44
Agile Modeling (AM)
 AM มีเอกลักษณ์ ดังนี้
 สร้ างแบบจาลองอย่ างมีเป้าหมาย (Model with a purpose)
 ใช้ แบบจาลองหลาย ๆ ตัว (Use multiple models)
 เดินทางอย่ างเบาตัว (Travel light)
 เนือ้ หาสาคัญกว่ ารู ปแบบ (Content is more important than
representation)
 รู้ จักแบบจาลองและเครื่องมือทีเ่ ลือกใช้ ให้ ดี (Know the models and
the tools you use to create them)
 ปรับตัวตามสถานการณ์ (Adapt locally)
45
CMM (ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะ
ความสามารถ)
วิศวกรรมซอฟต์ แวร์ เป้ าหมายสาคัญคือ การผลิตซอฟต์ แวร์ ให้ มคี ุณภาพ
 คุณภาพ
 ผลิตภัณฑ์
 กระบวนการ ผลิตซอฟต์ แวร์ ทเี่ ลือกใช้
 จาเป็ นต้ องมีการปรับกระบวนการให้ สอดคล้ องกับเทคนิค ระเบียบวิธี หรือเครื่องมือชนิดใหม่ เข้ ามา
ประยุกต์ ใช้
 การปรั บปรุ งกระบวนการ (Process Improvement)
 กลยุทธ์ ในการปรับปรุ งกระบวนการ
 Total Quality Management (TQM)
 Business Process Redesign (BPR)
 Continuous Process Improvement (CPI)
 Six Sigma
 CMM

46
CMM(ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ)
 แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)

SW-CMM (Software Capability Maturity Model)

คิดค้ นโดย สถาบันวิศวกรรมซอฟต์ แวร์ (Software Engineering Institute : SEI)
แห่ งมหาวิทยาลัยคาร์ เนกีเมลอน ประเทศสหรัฐอเมริกา

มี วั ต ถุ ป ระสงค์ เ พื่ อ ช่ ว ยเหลื อ องค์ ก รหรื อ หน่ ว ยงานผลิ ต ซอฟต์ แ วร์ ใ ห้ ส ามารถ
ปรับปรุ งการดาเนินงานได้ อย่ างมีระบบ มีความต่ อเนื่อง
 แบบจาลอง
CMM มีลักษณะเป็ นระดับชั้ น เพื่อให้ ทราบว่ าองค์ กรมีวุฒิภาวะของ
ความสามารถเติบโตเต็มที่ (Capability Maturity)
47
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
 แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
มีการปรับปรุง
กระบวนการอย่างต่อเนื่ อง
มีการควบคุมกระบวนการ
มีการพัฒนากระบวนการ
มีสภาพแวดล้อมที่มนคง
ั่
ระดับที่ 5 ดุลยภาพ
(Optimizing)
ระดับที่ 3 การกาหนดนิยาม
(Defined)
ระดับที่ 2 การกระทาซ้าได้
(Repeatable)
ระดับที่ 1 การเริ่มต้ น
(Initial)
การบริ หารการ
เปลี่ยนแปลง
ระดับที่ 4 การจัดการ
(Managed)
การบริ หารเชิ งปริ มาณ
การบริ หารวิ ศวกรรม
การบริ หารโครงการ
48
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
 แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)

วุฒิภาวะระดับที่ 1 ระดับการเริ่มต้ น (The initial Level)

องค์ กรไม่ มคี วามแน่ นอนในการพัฒนาและการบารุ งรักษาซอฟต์ แวร์

ปัญหาที่พบ การไม่ บรรลุถึงข้ อตกลงต่ าง ๆ ที่ต้องปฏิบัติตามกระบวนการอย่ าง
เป็ นขั้นตอนที่ได้ กาหนดไว้

การผลิ ต ซอฟต์ แ วร์ ในวุ ฒิ ภ าวะระดั บ นี้ จ ะต้ อ งค านึ ง ถึ ง ประสบการณ์ แ ละ
ความสามารถของหัวหน้ าและทีมงาน
49
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
 แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)

วุฒิภาวะระดับที่ 2 ระดับการกระทาซ้าได้ (The Repeatable Level)
 องค์ ก รจะมี ก ารก าหนดนโยบาย การจั ด ตั้ ง ที ม งาน และการบริ ห ารโครงการ
ซอฟต์ แวร์ เป็ นไปอย่างมีแบบแผนและชัดเจน
 การผลิ ต ซอฟต์ แ วร์ ใ นวุ ฒิ ภ าวะระดั บ นี้จ ะต้ อ งค านึ ง ถึ ง นโยบายและความมี
ระเบียบวินัยเป็ นสาคัญ
 มีการติดตามผลการทางานตลอดเวลา โดยเฉพาะด้ านต้ นทุนและระยะเวลา
 ความสาเร็ จทีไ่ ด้ จากการพัฒนาซอฟต์ แวร์ ของโครงการหนึ่ง จึงสามารถนาไปใช้
ได้ กบั โครงการต่ อไปในอนาคต (Repeatable)
50
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
 แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)

วุฒิภาวะระดับที่ 3 ระดับการกาหนดนิยาม (The Defined Level)

ผลต่ อเนื่องจากวุฒิภาวะระดับที่ 2

มุ่งเน้ นการกากับ ติดตาม และควบคุมกระบวนการต่ าง ๆ ผ่ านทางเอกสารทีไ่ ด้
กาหนดนิยามไว้ ในทุก ๆ ขั้นตอน (Documented and Integrated Process)

คานึงถึงการจัดการด้ านเอกสารประกอบการปฏิบัติงาน (Document
Management) เป็ นสาคัญ
51
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
 แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)

วุฒิภาวะระดับที่ 4 ระดับการจัดการ (The Managed Level)
 องค์ ก รมี ก ารก าหนดมาตรฐาน
(Standard) เพื่ อ ใช้ เป็ นบรรทั ด ฐานในการ
ประเมินกระบวนการ
 กระบวนการผลิตซอฟต์ แวร์ ในวุฒิภาวะระดับนี้ จะต้ องคานึงถึงมาตรฐานและ
การปรับปรุ งอย่ างต่ อเนื่องเป็ นสาคัญ
52
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
 แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)

วุฒิภาวะระดับที่ 5 ระดับดุลยภาพ (The Optimizing Level)

เป็ นองค์ กรแห่ งการเรียนรู้ (Learning Organization)

มีความสามารถในการจัดสรรทรัพยากรได้ อย่ างคุ้มค่ า และเหมาะสมทีส่ ุ ด

มีเทคโนโลยี (Technology) และฐานองค์ ความรู้ (Knowledge Based)

มีศักยภาพในการสร้ างสรรค์ นวัตกรรม (Innovation)

การผลิตซอฟต์ แวร์ ในวุฒิภาวะระดับนีจ้ ะต้ องคานึงถึงความคิดสร้ างสรรค์ ในแง่
ของนวัตกรรม และการจัดสรรทรัพยากรได้ อย่างเหมาะสม
53
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
 แบบจาลองวุฒิภาวะความสามารถ (Capability
Maturity
Model : CMM)
 ในแต่ ละระดับชั้ นยังระบุถงึ Key Process Area (KPA)
 KPA หมายถึง กระบวนการสาคัญที่องค์ กรจะต้ องมีเ มื่อ
ด าเนิ น งานปรั บ ปรุ ง คุ ณ ภาพของกระบวนการพั ฒ นา
ซอฟต์ แวร์
54
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
ตาราง แสดงคุณลักษณะและกระบวนการสาคัญของวุฒิภาวะความสามารถแต่ ละระดับชั้นตามแบบจาลอง CMM
ระดับ CMM
คุณลักษณะ
กระบวนการในแต่ ละด้ าน (KPA)
1 (Initial)
ไม่ เป็ นระเบียบ
ไม่ สามารถกระทาซ้าได้
มีความเสี่ ยงสู งมาก
ไม่ มกี ารกาหนด
2 (Repeatable)
มีนโยบายชัดเจน
สามารถกระทาซ้าได้
ไม่ มกี ารปรับปรุง
การวิเคราะห์ ความต้ องการ
การวางแผนโครงการ
การประกันคุณภาพซอฟต์ แวร์
การจัดหาผู้รับช่ วงหรือผู้รับจ้ าง
การจัดสภาพแวดล้อมซอฟต์ แวร์
3 (Defined)
มีการปรับปรุงประสิ ทธิภาพในด้ านต่ าง ๆ ได้ แก่ ต้ นทุน
กาหนดการ คุณภาพ และความเสี่ ยง
การจัดการกระบวนการด้ วยเอกสาร
การบูรณาการ
การฝึ กอบรม
การจัดการด้ านทรัพยากรบุคคล
การจัดการคุณภาพเบือ้ งต้ น
การสนับสนุนการผลิตซอฟต์ แวร์
55
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
ตาราง แสดงคุณลักษณะและกระบวนการสาคัญของวุฒิภาวะความสามารถแต่ ละระดับชั้นตามแบบจาลอง CMM
ระดับ CMM
คุณลักษณะ
กระบวนการในแต่ ละด้ าน (KPA)
4 (Managed)
มีประสบการณ์
มีการปรับปรุงประสิ ทธิภาพอย่ างต่ อเนื่อง
การจัดการกระบวนการเชิงปริมาณ
การจัดการคุณภาพซอฟต์ แวร์
5 (Optimizing)
มีประสิ ทธิภาพในทุก ๆ ด้ าน
มีการปรับปรุงการเรียนรู้
มีการสั่ งสมประสบการณ์
มีฐานองค์ ความรู้ (ผู้เชี่ยวชาญ)
มีคุณภาพสู ง และมีความเสี่ ยงน้ อย
การสร้ างสรรค์ นวัตกรรม
การบริหารความเปลีย่ นแปลง
การจัดสรรทรัพยากร
56
ปรับปรุงกระบวนการผลิตซอฟต์ แวร์ ด้วยแบบจาลองวุฒิภาวะความสามารถ
 แบบจาลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)

กระบวนการหลักทุ กด้ าน (KPA) ของ CMM
จะประกอบไปด้ วยแนวทางเชิ ง
ปฏิบัติการ ได้ แก่


เป้ าหมาย
การยอมรับถึงความต้ องการ

ขีดความสามารถ
กิจกรรม
วิธีการเฝ้ าติดตาม

วิธีการตรวจสอบความถูกต้ อง


57
ไปที่ Slide CMM ……..
58
เครื่องมือทีใ่ ช้ ในการวิศวกรรมซอฟต์ แวร์

เครื่องมือ (Tool)

เครื่ องมือ สาหรับการผลิตซอฟต์ แวร์ คือ ซอฟต์ แวร์ คอมพิวเตอร์ ที่มีวัตถุประสงค์ เพื่อช่ วยให้ การทางานใน
กระบวนการผลิตซอฟต์ แวร์ สะดวกขึน้

เครื่องมือสาหรั บงานวิศวกรรมซอฟต์ แวร์ จะช่ วยให้ ทีมงานสามารถทางานซ้า ๆ เดิมได้ ง่ายและรวดเร็ ว ลด
ภาระการเรียนรู้ ของวิศวกรซอฟต์ แวร์

เครื่องมือที่นามาใช้ ในกระบวนการวิศวกรรมซอฟต์ แวร์ ต้ องเหมาะสมกับ ระเบียบวิธี

เครื่องมือที่ใช้ เช่ น

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) Tool

Database Management Application

Code Generator Tool
59
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์

CASE Tools
 CASE
(Computer-Aided Software Engineering) หมายถึง ซอฟต์ แวร์ ที่เป็ น
เครื่ อ งมื อ ที่ มี ส่ วนช่ ว ยสนั บ สนุ น การท างานในกิ จ กรรมต่ า ง ๆ ของงานวิ ศ วกรรม
ซอฟต์ แวร์
 ซอฟต์ แวร์ ทเี่ ป็ น CASE Tool จะต้ องมีฟังก์ ชันต่ าง ๆ ให้ ทม
ี งานได้ เลือกใช้ เช่ น
 หน้ าต่ างออกแบบโปรแกรม (Design Editor)
 พจนานุกรมข้ อมูล (Data Dictionary)
 คอมไพเลอร์ (Compiler)
 ดีบักเกอร์ (Debugger)
60
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์

CASE Tools
 CASE ถือว่ าเป็ นเทคโนโลยีชนิดหนึ่งทีเ่ พิม
่ ความสามารถให้ กบั ซอฟต์ แวร์
 องค์ ประกอบสาคัญของ CASE
คือ Repository ซึ่งมีลักษณะเหมือนฐานข้ อมูลที่ใช้
จัดเก็บรายละเอียดต่ าง ๆ ที่นักพัฒนาได้ จัดทาขึน้
 ในยุคแรกของเทคโนโลยี CASE มีข้อจากัดคือ ระบบการทางานของ CASE มีลาดับ
กิจกรรมต่ อเนื่องกันอัตโนมัติ แต่ งานในทางวิศวกรรมซอฟต์ แวร์ เป็ นไปในทางความคิด
สร้ างสรรค์
 CASE ในยุคแรก ๆ ยังมีความสามารถไม่ เพียงพอที่จะสนับสนุ นการติดต่ อระหว่ าง
ทีมงาน
61
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์

ชนิดของ CASE
 CASE Tool สามารถจาแนกได้ หลายประเภท
 จาแนกตามหน้ าที่ของ CASE Tools (Functional Perspective)
 จาแนกตามกระบวนการทางาน (Process Perspective)
 จาแนกตามการประสานเข้ ากับ CASE Tools อืน
่ ๆ (Integration
Perspective)
62
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์

ชนิดของ CASE
 จาแนกตามกระบวนการทางาน ขั้นตอนต่ าง ๆ แล้ ว สามารถแบ่ ง CASE Tools ออกเป็ น 8
กลุ่ม ดังนี้
เครื่องมือสาหรับการวิเคราะห์ ความต้ องการ (Software Requirement Tool)
2. เครื่ องมือออกแบบซอฟต์ แวร์ (Software Design Tools)
3. เครื่ องมือสร้ างซอฟต์ แวร์ (Software Construction Tools)
4. เครื่ องมือทดสอบซอฟต์ แวร์ (Software Testing Tools)
5. เครื่ องมือบารุ งรั กษาซอฟต์ แวร์ (Software Maintenance Tools)
6. เครื่ องมือจัดการโครงแบบ (Software Configuration Management Tools)
7. เครื่ องมือบริ หารงานวิศวกรรมซอฟต์ แวร์ (Software Engineering Management Tools)
8. เครื่องมือคุณภาพซอฟต์ แวร์ (Software Quality Tools)
1.
63
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์

ชนิดของ CASE
1. เครื่องมือสาหรับการวิเคราะห์ ความต้ องการ (Software Requirement Tool)
แบ่ งออกเป็ น 2 กลุ่ม ได้ แก่
- เครื่องมือในการสร้ างแบบจาลองความต้ อง (Requirement Modeling Tools) เป็ น
เครื่องมือที่ใช้ ในการดึงความต้ องการ วิเคราะห์ กาหนด และตรวจสอบความต้ องการด้ าน
ซอฟต์ แวร์
- เครื่องมือการติดตามความต้ องการ (Requirement Traceability Tools) เป็ น
เครื่องมือทีใ่ ช้ ติดตามความต้ องการทีเ่ ปลีย่ นแปลงอยู่ตลอดเวลา
64
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์

ชนิดของ CASE
2. เครื่องมือออกแบบซอฟต์ แวร์ (Software Design Tools)
- เป็ นเครื่องมือที่ใช้ สร้ างและตรวจสอบงานออกแบบซอฟต์ แวร์
- ทาหน้ าที่สนับสนุนการวิเคราะห์ ความต้ องการด้ านซอฟต์ แวร์ เช่ น Rational Rose, EA เป็ นต้ น
3. เครื่องมือสร้ างซอฟต์ แวร์ (Software Construction Tools)
- เป็ นกลุ่มเครื่องมือที่สนับสนุนงานในการสร้ างซอฟแวร์ ท้งั หมด ได้ แก่
- เครื่องมือแก้ ไขโปรแกรม (Program Editor)
- คอมไพเลอร์ (Compiler)
- อินเตอร์ พรีเตอร์ (Interpreter)
- ดีบักเกอร์ (Debugger)
ตัวอย่ างเช่ น Eclipse, EditPlus, Windev, .NET Studio
65
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์

ชนิดของ CASE
4. เครื่องมือทดสอบซอฟต์ แวร์ (Software Testing Tools) ได้ แก่
- เครื่องสร้ างกรณีทดสอบ (Testing Generation) ใช้ สร้ างกรณีทดสอบซอฟต์ แวร์
- กรอบการปฏิบัติการทดสอบ (Test Execution Framework) ใช้ ทดสอบซอฟต์ แวร์ ภายใต้
สภาพแวดล้ อมทีม่ กี ารกาหนดไว้ ล่วงหน้ า
- เครื่องมือประเมินผลการทดสอบ (Test Evaluation Tools) ใช้ สนับสนุนการประเมินผล
การทดสอบ ว่ าผลการทดสอบเป็ นตามคาดหวังหรือไม่
- เครื่องมือบริหารงานทดสอบ (Test Management Tools) เป็ นเครื่องมือที่สนับสนุนทุก
กิจกรรมการทดสอบ
- เครื่องมือวิเคราะห์ ประสิ ทธิภาพซอฟต์ แวร์ (Performance Analysis Tool) เป็ นเครื่องมือ
ทีใ่ ช้ วดั ผลและวิเคราะห์ ประสิ ทธิภาพการทางานของซอฟต์ แวร์
66
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์

ชนิดของ CASE
5. เครื่องมือบารุงรักษาซอฟต์ แวร์ (Software Maintenance Tools)
เป็ นเครื่องมือทีใ่ ช้ บารุงรักษาซอฟต์ แวร์ ที่มีอยู่แล้ ว ให้ คงสภาพที่ใช้ การได้ อย่ างดี แบ่ งเป็ น 2
กลุ่ม ได้ แก่
1. เครื่องมือสร้ างความเข้ าใจ (Comprehension Tools) เป็ นเครื่องมือที่ช่วยให้ ทีมซ่ อม
บารุ งทาความเข้ าใจกับโปรแกรมของซอฟต์ แวร์ ได้ ง่ายขึน้
2. เครื่องมือรื้อปรับระบบใหม่ (Reengineering Tools) เป็ นเครื่องมือทีช่ ่ วยในกระบวนการ
รื้อโครงสร้ างของซอฟต์ แวร์ ทลี ะส่ วน เพือ่ นามาปรับหรือแก้ ไขให้ มสี ภาพสมบูรณ์ เหมือนเดิม
6. เครื่องมือจัดการโครงแบบ (Software Configuration Management Tools)
เป็ นเครื่องมือทีใ่ ช้ ติดตามการเปลีย่ นแปลงของทุกองค์ ประกอบของซอฟต์ แวร์
จัดการรุ่นของซอฟแวร์ และการวางจาหน่ ายของซอฟต์ แวร์
67
เครื่องมือที่ใช้ ในการวิศวกรรมซอฟต์ แวร์

ชนิดของ CASE
7. เครื่องมือบริหารงานวิศวกรรมซอฟต์ แวร์ (Software Engineering Management Tools) ได้ แก่
- เครื่องมือวางแผนและติดตามโครงการ (Project Planning and Tracking) ได้ แก่ ซอฟต์ แวร์ ที่ใช้ ใน
การประมาณการแรงงาน และต้ นทุน พร้ อมทั้งจัดตารางงาน
- เครื่องมือจัดการความเสี่ ยง (Risk Management) ได้ แก่ ซอฟต์ แวร์ ที่ใช้ ระบุปัจจัยเสี่ ยง ประมาณการ
ผลกระทบ และติดตามความเสี่ ยง
-
เครื่ องมือวัดผลโครงการ (Measurement) ได้ แก่ ซอฟต์ แวร์ ที่ใช้ ในการวัดผลทุกกิจกรรมของ
โครงการ
8. เครื่องมือคุณภาพซอฟต์ แวร์ (Software Quality Tools)
- เครื่องมือตรวจสอบคุณภาพ (Inspection Tools) ได้ แก่ เครื่องมือที่ใช้ ทบทวนและตรวจสอบคุณภาพ
ของซอฟต์ แวร์
- เครื่องมือวิเคราะห์ คุณภาพ (Static Analysis Tools) ได้ แก่ เครื่องมือที่ใช้ วเิ คราะห์ คุณลักษณะด้ าน
ต่ าง ๆ ของ ซอฟต์ แวร์ เช่ น วิเคราะห์ Control Flow และโครงสร้ างข้ อมูล เป็ นต้ น
เครื่องมือและระเบียบวิธีที่ใช้ ในการวิศวกรรมซอฟต์ แวร์
ประเด็นอืน่ ๆ ทีเ่ กีย่ วข้ องกับ CASE Tools
Integrated CASE Environment
- เป็ น CASE Tool ทีป่ ระกอบไปด้ วยฟังก์ ชันการทางานทีค่ รอบคลุมงานทุกด้ าน
ของวิศวกรรมซอฟต์ แวร์
- ประสานการทางานเข้ ากับ CASE Tool สาหรับขั้นตอนพืน้ ฐานของการพัฒนา
ซอฟต์ แวร์
Meta Tools
เป็ นเครื่ องมือที่ใช้ สร้ างเครื่ องมือ เช่ น Editor ใช้ สร้ างโปรแกรมที่ เป็ น
คอมไพเลอร์ เป็ นต้ น
ระเบียบวิธีที่ใช้ในการวิศวกรรมซอฟต์แวร์
ระเบียบวิธี (Methodologies)
- ระเบียบวิธี หรือ กรรมวิธี ในการปฏิบัติงานวิศวกรรมซอฟต์ แวร์ จะกาหนดนิยาม
ของกิจกรรมต่ าง ๆ ขั้นตอนการดาเนินกิจกรรม และข้ อแนะนาการตรวจสอบการทางาน
- ระเบียบวิธีปฏิบัติงานวิศวกรรมซอฟต์ แวร์ ได้ แก่
1. วิธีเชิงโครงสร้ าง (Structured Approach)
2. วิธีเชิงวัตถุ (Object – oriented Approach)
3. Heuristic Methodology
4. Formal Methodology
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
1. แนวทางเชิงโครงสร้ าง (Structured Approach)
 แบ่ งระบบและความต้ องการออกเป็ นระบบย่ อย (Sub-System)
 ลักษณะของระบบจึงเป็ นโครงสร้ างแบบลาดับชั้ น
 ระเบียบวิธีปฏิบัติชนิดหนึ่งทีน
่ ิยมนามาใช้ ในขั้นตอนการวิเคราะห์ และ
ออกแบบระบบ คือ “การวิเคราะห์ และออกแบบระบบเชิงโครงสร้ าง
(Structured System Analysis and Design: SSAD)” คิดค้ นโดย Yourdan
& Demarco ปี ค.ศ. 1978
71
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
1. แนวทางเชิงโครงสร้ าง (Structured Approach)
 ข้ อเสี ย
 ต้ องวิเคราะห์ และออกแบบข้ อมูลรวมถึงพฤติกรรมของระบบแยกกันคน
ละส่ วน ทาให้ ต้องใช้ เวลานาน
 ใช้ ต้นทุนมากเกินไป
 เสี่ ยงต่ อการเปลีย
่ นแปลงความต้ องการของผู้ใช้
72
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
ตัวอย่ างการวิเคราะห์ และออกแบบระบบเชิงโครงสร้ าง
ระบบวางบิล
ตรวจสอบการจัดส่ งสิ นค้ า
จัดทาใบส่ งสิ นค้ า
ตรวจสอบสถานะการสั่ งซื้อ
ปรับปรุงสถานะคลังสิ นค้ า
จัดทารายการยอดขาย
ปรับปรุงยอดสั่ งซื้อ
จัดทาภาษีซื้อ - ขาย
แก้ไขสถานะวิเคราะห์ การขาย
จัดทาใบวางบิล
แสดงตัวอย่ างการวิเคราะห์ และออกแบบระบบเชิงโครงสร้ าง
73
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
2. แนวทางเชิงวัตถุ (Object – Oriented Approach)
คิดค้ นโดย Grady Booch, James Rumbaugh และ Ivar Jacobson
 การวิเคราะห์ และออกแบบระบบเชิ งวัตถุ (Object-Oriented System
Analysis and Design)
 เป็ นการวิเคราะห์ ระบบโดยการมองทุกอย่ างในระบบเป็ นอ็อบเจ็กต์
(Object)

74
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
2. แนวทางเชิงวัตถุ (Object – Oriented Approach)
 ข้ อดี
 การวิเคราะห์ และออกแบบระบบรวดเร็ ว
 รองรั บกับระบบงานทีม
่ ีความซับซ้ อนสู ง
 ทันต่ อการเปลีย
่ นแปลงความต้ องการของผู้ใช้
75
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
ตัวอย่ างอ็อบเจ็กต์
Invoice
ID
No.
Address
A/C No.
Amount
Computer value of goods
Computer discount
Computer Ad. Charge
Computer Invoice Amount
object
Attribute
s
Methods
แสดงตัวอย่ างอ็อบเจ็กต์
76
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
3. Heuristic Methodology
- เป็ นระเบียบวิธีทไี่ ม่ เป็ นแบบแผน (Informal Method)
- ไม่ มีการนาวิธีการทางคณิตศาสตร์ เข้ าไปใช้ ในขั้นตอนต่ าง ๆ
- Methodology
- Structured Methodology/Approach มุ่งเน้ นทีห่ น้ าทีก่ ารทางานของ
โปรแกรม
- Object-oriented Methodology พิจารณาทั้งข้ อมูลและหน้ าทีก่ าร
ทางานไป พร้ อม ๆ กัน
- Data-oriented Methodology เป็ นวิธีการทีม่ ่ ุงเน้ นทีข่ ้ อมูลทีโ่ ปรแกรม
จะต้ องเข้ าไปดาเนินการ
77
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
4. Formal Methodology
- เป็ นระเบียบวิธีอาศัยวิธีการทางคณิตศาสตร์ เป็ นพืน้ ฐานการทางาน 2 ชนิดได้
1. การระบุข้อกาหนดอย่ างมีแบบแผน (Formal Specification) เป็ นวิธีการ
อธิบายข้ อกาหนดด้ วยภาษาชนิดใดชนิดหนึ่ง เช่ น พีชคณิต และแบบจาลองทาง
คณิตศาสตร์
2. การทวนสอบอย่างมีแบบแผน (Formal Verification) เป็ นวิธีการทวนสอบ
โดยใช้ การพิสูจน์ ทางตรรกะ ช่ วยให้ การทวนสอบซอฟต์ แวร์ มปี ระสิ ทธิภาพมากขึน้
78
สรุป
- Agile เน้ น 4 เรื่อง หลัก ๆ คือ ความสาคัญของทีมจัดระเบียบตนเองที่ควบคุมงานที่
ตนทาอยู่ การสื่ อสารและความร่ วมมือระหว่ างสมาชิกในทีม ผู้ปฏิบัตงิ านและลูกค้ า การ
ระลึกไว้ ว่าการเปลีย่ นแปลงเป็ นตัวแทนของโอกาสดี ๆ และการเน้ นการส่ งมอบ
ซอฟต์ แวร์ ทที่ าให้ ลูกค้ าพอใจอย่ างรวดเร็ว
- Extreme Programming (XP) เป็ นกระบวนการ Agile ทีใ่ ช้ กนั มากทีส่ ุ ด ได้ จัด
ระเบียบกิจกรรมกรอบงานไว้ 4 อย่าง คือ
- การวางแผน
- การออกแบบ
- การเขียนโค้ ด
- การทดสอบ
79
สรุ ป
-Adaptive Software Development (ASD)
- เน้ นความร่ วมมือของมนุษย์ และทีมจัดระเบียบตนเอง
- กาหนดกรอบงาน 3 อย่ าง คือ การคาดเดา การร่ วมมือ การเรียนรู้
- ASD ใช้ กระบวนการวนซ้าที่รวมหลักการวางแผนวงจรการปรับตัว วิธีรวบรวม
ความต้ องการอย่ างกระตือรือร้ น และวงจรการพัฒนาแบบทาวนซ้าที่มีการประชุ ม
ร่ วมกับกลุ่มลูกค้ าเป้ าหมาย และใช้ การตรวจทานด้ านเทคนิคอย่ างเป็ นทางการ
-
เป็ นกลไกในการตอบสนองย้ อนกลับในเวลาจริง
80
สรุป
- Dynamic Systems Development Method (DSDM)
-นิยามวงจรวนซ้า
-การวนซ้าการจาลองเชิ งหน้ าที่ การวนซ้าการออกแบบและการสร้ าง และการ
อินพีลเม้ นต์
- นาหน้ าด้ วยวงจรเพิม
่ เติมสองกิจกรรม คือการศึกษาความเป็ นไปได้ และ
การศึกษาด้ านธุรกิจ
- DSDM จัดตารางงานโดยใช้ กล่ องเวลา และแนะนาให้ ทางานเพียงแค่ พอเท่ าที่
จาเป็ นสาหรับแต่ ละรุ่ นของซอฟต์ แวร์ เพือ่ ให้ ความสะดวกแก่ การเคลือ่ นไปสู่
รุ่ นถัดไป
81
สรุป
- Scrum (สครั ม)
- เน้ นการใช้ ชุดแบบรู ปกระบวนการซอฟต์ แวร์ ทไี่ ด้ ผลมาแล้ ว สาหรับโครงการทีม
่ ี
เวลาจากัด มีการเปลีย่ นแปลงความต้ องการ และมีความสาคัญยิง่ ยวดทางธุรกิจ
- Crystal (คริ สตัล)
- เป็ นกลุ่มครอบครัวของแบบจาลองกระบวนการ Agile ทีส
่ ามารถปรับตัวเข้ ากัน
ลักษณะเฉพาะตัวโครงการต่ าง ๆ
- คริสตัลใช้ กลยุทธ์ การทาวนซ้า แต่ ปรับความเข้ มข้ นของกระบวนการ ให้ รองรับ
โครงการที่มขี นาดและความซับซ้ อนระดับต่ าง ๆ กัน
82
สรุ ป
- Feature Driven Development (FDD)
- เป็ นวิธี Agile ที่ค่อนข้ างเป็ นทางการกว่ าวิธีการอืน่ ๆ
- แต่ ยงั คงความคล่ องตัว
- เน้ นความสนใจของทีมพัฒนาไปทีค่ ุณลักษณะของซอฟต์ แวร์ ทีน
่ ิยามไว้ เป็ นหน้ าทีก่ ารทางาน
อันมีคุณค่ าแก่ ลูกค้ า ทีส่ ามารถอินพลีเม้ นต์ ให้ เสร็จได้ ภายในเวลาสองสั ปดาห์ หรือน้ อยกว่ า
- FDD ให้ ความสาคัญแก่ การบริหารโครงการมากว่ าวิธีอน
ื่ ๆ
- Agile Modeling (AM)
-
แบบจาลองจาเป็ นสาหรับทุกระบบ
- แต่ ขนาด ประเภท และความซับซ้ อนของแบบจาลอง ต้ องปรับเข้ ากับซอฟต์ แวร์ ทจี่ ะสร้ าง
83
สรุป
- การผลิตซอฟต์ แวร์ จาเป็ นต้ องดาเนินการในรู ปแบบของ กระบวนการ (Process)
- กระบวนการทีป่ ระกอบไปด้ วยกลุ่มกิจกรรมทีส่ ั มพันธ์ กนั ในการผลิตซอฟต์ แวร์ ให้
ได้ คุณภาพ เรียกว่ า Software Process หรือ Software Development Process
- เพือ่ ให้ ผลิตภัณฑ์ ซอฟต์ แวร์ มีคุณภาพ ต้ องนาหลักการวิศวกรรมซอฟต์ แวร์ เข้ ามา
ดูแลกระบวนการผลิตซอฟต์ แวร์
- กระบวนการวิศวกรรมซอฟต์ แวร์ (Software Engineering Process) มี
กระบวนการผลิตซอฟต์ แวร์ เป็ นพืน้ ฐานสาคัญ
- แบบจาลองกระบวนการผลิตซอฟต์ แวร์ (Software Process Model) เป็ นสิ่ งที่ช่วย
ให้ เห็นภาพของการกระบวนการผลิตซอฟต์ แวร์ ได้ ชัดเจนทีส่ ุ ด
84
สรุ ป
- สิ่ งที่เป็ นหน้ าที่สาคัญของวิศวกรซอฟต์ แวร์ คือ การปรับปรุ งกระบวนการผลิต
(Process Improvement) เพือ่ ตอบสนองต่ อแนวคิดประสิ ทธิภาพของกระบวนการ
- สถาบันวิศวกรรมแห่ งสหรัฐอเมริกา (SEI) ได้ พฒ
ั นา แบบจาลองวุฒิภาวะ
ความสามารถ (Capability Maturity Model : CMM) เพือ่ ใช้ วดั ระดับวุฒิภาวะ
ความสามารถของกระบวนการผลิตของแต่ ละองค์ กร เพือ่ ปรับปรุ งไปสู่ วุฒิภาวะใน
ระดับสู งขึน้
85

similar documents