Transcript แบบจำลองวุฒิภาวะความสามารถ - Faculty of Information Technology

กระบวนการผลิตซอฟต์ แวร์
Software Development Methodology
อ.ดร.มหศักดิ์ เกตุฉ่ ำ
Faculty of Information
Technology
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
maintenance – การเพิ่ม
ประสิทธิภาพและการแก้ ไข
 System and acceptance
testing – ตรวจสอบสภาพแวดล้ อมของ
Software
 Architecture or High-Level
 Integration and Testing –
 Detailed Design – การพัฒนา
 Unit testing – ตรวจสอบการทางาน
Specification Analysis – กาหนด
spec ที่สมบูร์์ของ Software
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 ส่ วนที่สาคัญ คือ
o“Human-powered”
o“Ultralight”
o“Stretch-to-fit”
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
เครื่องมือทีใ่ ช้ ในการวิศวกรรมซอฟต์ แวร์
• เครื่องมือ (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
58
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
•
CASE Tools
• CASE (Computer-Aided Software Engineering) หมายถึง ซอฟต์ แวร์ ที่เป็ น
เครื่ อ งมื อ ที่ มี ส่ วนช่ ว ยสนั บ สนุ น การท างานในกิ จ กรรมต่ า ง ๆ ของงานวิ ศ วกรรม
ซอฟต์ แวร์
• ซอฟต์ แวร์ ทเี่ ป็ น CASE Tool จะต้ องมีฟังก์ชันต่ าง ๆ ให้ ทมี งานได้ เลือกใช้ เช่ น
• หน้ าต่ างออกแบบโปรแกรม (Design Editor)
• พจนานุกรมข้ อมูล (Data Dictionary)
• คอมไพเลอร์ (Compiler)
• ดีบักเกอร์ (Debugger)
59
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
•
CASE Tools
• CASE ถือว่ าเป็ นเทคโนโลยีชนิดหนึ่งทีเ่ พิม่ ความสามารถให้ กบั ซอฟต์ แวร์
• องค์ ประกอบสาคัญของ CASE คือ Repository ซึ่ งมีลกั ษณะเหมือนฐานข้ อมูลที่ใช้
จัดเก็บรายละเอียดต่ าง ๆ ที่นักพัฒนาได้ จัดทาขึน้
• ในยุคแรกของเทคโนโลยี CASE มีข้อจากัดคือ ระบบการทางานของ CASE มีลาดับ
กิจกรรมต่ อเนื่องกันอัตโนมัติ แต่ งานในทางวิศวกรรมซอฟต์ แวร์ เป็ นไปในทางความคิด
สร้ างสรรค์
• CASE ในยุคแรก ๆ ยังมีความสามารถไม่ เพียงพอที่จะสนับสนุนการติดต่ อระหว่ าง
ทีมงาน
60
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
• ชนิดของ CASE
• CASE Tool สามารถจาแนกได้ หลายประเภท
• จาแนกตามหน้ าทีข่ อง CASE Tools (Functional Perspective)
• จาแนกตามกระบวนการทางาน (Process Perspective)
• จาแนกตามการประสานเข้ ากับ CASE Tools อืน่ ๆ (Integration
Perspective)
61
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
• ชนิดของ CASE
• จาแนกตามกระบวนการทางาน ขั้นตอนต่ าง ๆ แล้ ว สามารถแบ่ ง CASE Tools ออกเป็ น 8
กลุ่ม ดังนี้
1.
2.
3.
4.
5.
6.
7.
8.
เครื่องมือสาหรับการวิเคราะห์ ความต้ องการ (Software Requirement Tool)
เครื่องมือออกแบบซอฟต์ แวร์ (Software Design Tools)
เครื่องมือสร้ างซอฟต์ แวร์ (Software Construction Tools)
เครื่องมือทดสอบซอฟต์ แวร์ (Software Testing Tools)
เครื่องมือบารุงรักษาซอฟต์ แวร์ (Software Maintenance Tools)
เครื่องมือจัดการโครงแบบ (Software Configuration Management Tools)
เครื่องมือบริหารงานวิศวกรรมซอฟต์ แวร์ (Software Engineering Management Tools)
เครื่องมือคุณภาพซอฟต์ แวร์ (Software Quality Tools)
62
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
• ชนิดของ CASE
1. เครื่องมือสาหรับการวิเคราะห์ ความต้ องการ (Software Requirement Tool)
แบ่ งออกเป็ น 2 กลุ่ม ได้ แก่
- เครื่องมือในการสร้ างแบบจาลองความต้ อง (Requirement Modeling Tools) เป็ น
เครื่องมือที่ใช้ ในการดึงความต้ องการ วิเคราะห์ กาหนด และตรวจสอบความต้ องการด้ าน
ซอฟต์ แวร์
- เครื่องมือการติดตามความต้ องการ (Requirement Traceability Tools) เป็ นเครื่องมือที่
ใช้ ติดตามความต้ องการทีเ่ ปลีย่ นแปลงอยู่ตลอดเวลา
63
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
• ชนิดของ CASE
2. เครื่องมือออกแบบซอฟต์ แวร์ (Software Design Tools)
- เป็ นเครื่องมือที่ใช้ สร้ างและตรวจสอบงานออกแบบซอฟต์ แวร์
- ทาหน้ าที่สนับสนุนการวิเคราะห์ ความต้ องการด้ านซอฟต์ แวร์ เช่ น Rational Rose, EA เป็ นต้ น
3. เครื่องมือสร้ างซอฟต์ แวร์ (Software Construction Tools)
- เป็ นกลุ่มเครื่องมือที่สนับสนุนงานในการสร้ างซอฟแวร์ ท้งั หมด ได้ แก่
- เครื่องมือแก้ ไขโปรแกรม (Program Editor)
- คอมไพเลอร์ (Compiler)
- อินเตอร์ พรีเตอร์ (Interpreter)
- ดีบักเกอร์ (Debugger)
ตัวอย่ างเช่ น Eclipse, EditPlus, Windev, .NET Studio
64
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
• ชนิดของ CASE
4. เครื่องมือทดสอบซอฟต์ แวร์ (Software Testing Tools) ได้ แก่
- เครื่องสร้ างกรณีทดสอบ (Testing Generation) ใช้ สร้ างกรณีทดสอบซอฟต์ แวร์
- กรอบการปฏิบัติการทดสอบ (Test Execution Framework) ใช้ ทดสอบซอฟต์ แวร์ ภายใต้
สภาพแวดล้ อมทีม่ กี ารกาหนดไว้ ล่วงหน้ า
- เครื่องมือประเมินผลการทดสอบ (Test Evaluation Tools) ใช้ สนับสนุนการประเมินผล
การทดสอบ ว่ าผลการทดสอบเป็ นตามคาดหวังหรือไม่
- เครื่องมือบริหารงานทดสอบ (Test Management Tools) เป็ นเครื่องมือที่สนับสนุนทุก
กิจกรรมการทดสอบ
- เครื่องมือวิเคราะห์ ประสิ ทธิภาพซอฟต์ แวร์ (Performance Analysis Tool) เป็ นเครื่ องมือ
ทีใ่ ช้ วดั ผลและวิเคราะห์ ประสิ ทธิภาพการทางานของซอฟต์ แวร์
65
เครื่ องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
• ชนิดของ CASE
5. เครื่องมือบารุงรักษาซอฟต์ แวร์ (Software Maintenance Tools)
เป็ นเครื่องมือทีใ่ ช้ บารุ งรักษาซอฟต์ แวร์ ที่มีอยู่แล้ ว ให้ คงสภาพที่ใช้ การได้ อย่ างดี แบ่ งเป็ น 2
กลุ่ม ได้ แก่
1. เครื่องมือสร้ างความเข้ าใจ (Comprehension Tools) เป็ นเครื่องมือที่ช่วยให้ ทีมซ่ อม
บารุ งทาความเข้ าใจกับโปรแกรมของซอฟต์ แวร์ ได้ ง่ายขึน้
2. เครื่องมือรื้อปรับระบบใหม่ (Reengineering Tools) เป็ นเครื่องมือทีช่ ่ วยในกระบวนการ
รื้อโครงสร้ างของซอฟต์ แวร์ ทลี ะส่ วน เพือ่ นามาปรับหรือแก้ ไขให้ มสี ภาพสมบูรณ์ เหมือนเดิม
6. เครื่องมือจัดการโครงแบบ (Software Configuration Management Tools)
เป็ นเครื่องมือทีใ่ ช้ ติดตามการเปลีย่ นแปลงของทุกองค์ ประกอบของซอฟต์ แวร์
จัดการรุ่นของซอฟแวร์ และการวางจาหน่ ายของซอฟต์ แวร์
66
เครื่องมือทีใ่ ช้ ในการวิศวกรรมซอฟต์ แวร์
• ชนิดของ CASE
7. เครื่องมือบริหารงานวิศวกรรมซอฟต์ แวร์ (Software Engineering Management Tools) ได้ แก่
- เครื่องมือวางแผนและติดตามโครงการ (Project Planning and Tracking) ได้ แก่ ซอฟต์ แวร์ ที่ใช้ ใน
การประมาณการแรงงาน และต้ นทุน พร้ อมทั้งจัดตารางงาน
- เครื่องมือจัดการความเสี่ ยง (Risk Management) ได้ แก่ ซอฟต์ แวร์ ที่ใช้ ระบุปัจจัยเสี่ ยง ประมาณการ
ผลกระทบ และติดตามความเสี่ ยง
-
เครื่ องมือวัดผลโครงการ (Measurement) ได้ แก่ ซอฟต์ แวร์ ที่ใช้ ในการวัดผลทุกกิจกรรมของ
โครงการ
8. เครื่องมือคุณภาพซอฟต์ แวร์ (Software Quality Tools)
- เครื่องมือตรวจสอบคุณภาพ (Inspection Tools) ได้ แก่ เครื่องมือที่ใช้ ทบทวนและตรวจสอบคุณภาพ
ของซอฟต์ แวร์
- เครื่องมือวิเคราะห์ คุณภาพ (Static Analysis Tools) ได้ แก่ เครื่องมือที่ใช้ วเิ คราะห์ คุณลักษณะด้ าน
ต่ าง ๆ ของ ซอฟต์ แวร์ เช่ น วิเคราะห์ Control Flow และโครงสร้ างข้ อมูล เป็ นต้ น
67
เครื่องมือและระเบียบวิธีที่ใช้ ในการวิศวกรรมซอฟต์ แวร์
ประเด็นอืน่ ๆ ทีเ่ กีย่ วข้ องกับ CASE Tools
Integrated CASE Environment
- เป็ น CASE Tool ทีป่ ระกอบไปด้ วยฟังก์ ชันการทางานทีค่ รอบคลุมงานทุกด้ าน
ของวิศวกรรมซอฟต์ แวร์
- ประสานการทางานเข้ ากับ CASE Tool สาหรับขั้นตอนพืน้ ฐานของการพัฒนา
ซอฟต์ แวร์
Meta Tools
เป็ นเครื่ องมือที่ใช้ สร้ างเครื่ องมือ เช่ น Editor ใช้ สร้ างโปรแกรมที่ เป็ น
คอมไพเลอร์ เป็ นต้ น
68
ระเบียบวิธีที่ใช้ในการวิศวกรรมซอฟต์แวร์
ระเบียบวิธี (Methodologies)
- ระเบียบวิธี หรือ กรรมวิธี ในการปฏิบัติงานวิศวกรรมซอฟต์ แวร์ จะกาหนด
นิยามของกิจกรรมต่ าง ๆ ขั้นตอนการดาเนินกิจกรรม และข้ อแนะนาการตรวจสอบการ
ทางาน
- ระเบียบวิธีปฏิบัติงานวิศวกรรมซอฟต์ แวร์ ได้ แก่
1. วิธีเชิงโครงสร้ าง (Structured Approach)
2. วิธีเชิงวัตถุ (Object – oriented Approach)
3. Heuristic Methodology
4. Formal Methodology
69
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
1. แนวทางเชิงโครงสร้ าง (Structured Approach)
• แบ่ งระบบและความต้ องการออกเป็ นระบบย่ อย (Sub-System)
• ลักษณะของระบบจึงเป็ นโครงสร้ างแบบลาดับชั้น
• ระเบียบวิธีปฏิบัติชนิดหนึ่งทีน่ ิยมนามาใช้ ในขั้นตอนการวิเคราะห์ และ
ออกแบบระบบ คือ “การวิเคราะห์ และออกแบบระบบเชิงโครงสร้ าง
(Structured System Analysis and Design: SSAD)” คิดค้ นโดย Yourdan
& Demarco ปี ค.ศ. 1978
70
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
1. แนวทางเชิงโครงสร้ าง (Structured Approach)
• ข้ อเสี ย
• ต้ องวิเคราะห์ และออกแบบข้ อมูลรวมถึงพฤติกรรมของระบบแยกกันคน
ละส่ วน ทาให้ ต้องใช้ เวลานาน
• ใช้ ต้นทุนมากเกินไป
• เสี่ ยงต่ อการเปลีย่ นแปลงความต้ องการของผู้ใช้
71
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
ตัวอย่ างการวิเคราะห์ และออกแบบระบบเชิงโครงสร้ าง
ระบบวางบิล
ตรวจสอบการจัดส่ งสิ นค้ า
จัดทาใบส่ งสิ นค้ า
ตรวจสอบสถานะการสั่ งซื้อ
ปรับปรุงสถานะคลังสิ นค้ า
จัดทารายการยอดขาย
ปรับปรุงยอดสั่ งซื้อ
จัดทาภาษีซื้อ - ขาย
แก้ไขสถานะวิเคราะห์ การขาย
แสดงตัวอย่ างการวิ
และออกแบบระบบเชิ
งโครงสร้ าง
จัดเคราะห์
ทาใบวางบิ
ล
72
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
2. แนวทางเชิงวัตถุ (Object – Oriented Approach)
• คิดค้ นโดย Grady Booch, James Rumbaugh และ Ivar Jacobson
• การวิเคราะห์ และออกแบบระบบเชิงวัตถุ (Object-Oriented System
Analysis and Design)
• เป็ นการวิเคราะห์ ระบบโดยการมองทุกอย่ างในระบบเป็ นอ็อบเจ็กต์
(Object)
73
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
2. แนวทางเชิงวัตถุ (Object – Oriented Approach)
• ข้ อดี
• การวิเคราะห์ และออกแบบระบบรวดเร็ว
• รองรับกับระบบงานทีม่ ีความซับซ้ อนสู ง
• ทันต่ อการเปลีย่ นแปลงความต้ องการของผู้ใช้
74
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
ตัวอย่ างอ็อบเจ็กต์
Invoice
ID
No.
Address
A/C No.
Amount
Computer value of goods
Computer discount
Computer Ad. Charge
Computer Invoice Amount
object
Attributes
Methods
แสดงตัวอย่ างอ็อบเจ็กต์
75
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
3. Heuristic Methodology
- เป็ นระเบียบวิธีทไี่ ม่ เป็ นแบบแผน (Informal Method)
- ไม่ มีการนาวิธีการทางคณิตศาสตร์ เข้ าไปใช้ ในขั้นตอนต่ าง ๆ
- Methodology
- Structured Methodology/Approach มุ่งเน้ นทีห่ น้ าทีก่ ารทางานของ
โปรแกรม
- Object-oriented Methodology พิจารณาทั้งข้ อมูลและหน้ าทีก่ าร
ทางานไป พร้ อม ๆ กัน
- Data-oriented Methodology เป็ นวิธีการทีม่ ่ ุงเน้ นทีข่ ้ อมูลทีโ่ ปรแกรม
จะต้ องเข้ าไปดาเนินการ
76
ระเบียบวิธีปฏิบตั ิของวิศวกรรมซอฟต์แวร์
4. Formal Methodology
- เป็ นระเบียบวิธีอาศัยวิธีการทางคณิตศาสตร์ เป็ นพืน้ ฐานการทางาน 2 ชนิดได้
1. การระบุข้อกาหนดอย่ างมีแบบแผน (Formal Specification) เป็ นวิธีการ
อธิบายข้ อกาหนดด้ วยภาษาชนิดใดชนิดหนึ่ง เช่ น พีชคณิต และแบบจาลองทาง
คณิตศาสตร์
2. การทวนสอบอย่างมีแบบแผน (Formal Verification) เป็ นวิธีการทวนสอบ
โดยใช้ การพิสูจน์ ทางตรรกะ ช่ วยให้ การทวนสอบซอฟต์ แวร์ มปี ระสิ ทธิภาพมากขึน้
77
สรุ ป
- Agile เน้ น 4 เรื่อง หลัก ๆ คือ ความสาคัญของทีมจัดระเบียบตนเองที่ควบคุมงานที่
ตนทาอยู่ การสื่ อสารและความร่ วมมือระหว่ างสมาชิกในทีม ผู้ปฏิบัตงิ านและลูกค้ า การ
ระลึกไว้ ว่าการเปลีย่ นแปลงเป็ นตัวแทนของโอกาสดี ๆ และการเน้ นการส่ งมอบ
ซอฟต์ แวร์ ทที่ าให้ ลูกค้ าพอใจอย่ างรวดเร็ว
- Extreme Programming (XP) เป็ นกระบวนการ Agile ทีใ่ ช้ กนั มากทีส่ ุ ด ได้ จดั
ระเบียบกิจกรรมกรอบงานไว้ 4 อย่าง คือ
- การวางแผน
- การออกแบบ
- การเขียนโค้ ด
- การทดสอบ
78
สรุป
-Adaptive Software Development (ASD)
- เน้ นความร่ วมมือของมนุษย์ และทีมจัดระเบียบตนเอง
- กาหนดกรอบงาน 3 อย่ าง คือ การคาดเดา การร่ วมมือ การเรียนรู้
- ASD ใช้ กระบวนการวนซ้าที่รวมหลักการวางแผนวงจรการปรับตัว วิธีรวบรวม
ความต้ องการอย่ างกระตือรือร้ น และวงจรการพัฒนาแบบทาวนซ้าที่มีการประชุ ม
ร่ วมกับกลุ่มลูกค้ าเป้ าหมาย และใช้ การตรวจทานด้ านเทคนิคอย่ างเป็ นทางการ
- เป็ นกลไกในการตอบสนองย้ อนกลับในเวลาจริง
79
สรุ ป
- Dynamic Systems Development Method (DSDM)
-นิยามวงจรวนซ้า
-การวนซ้าการจาลองเชิงหน้ าที่ การวนซ้าการออกแบบและการสร้ าง และการ
อินพีลเม้ นต์
- นาหน้ าด้ วยวงจรเพิม่ เติมสองกิจกรรม คือการศึกษาความเป็ นไปได้ และ
การศึกษาด้ านธุรกิจ
- DSDM จัดตารางงานโดยใช้ กล่องเวลา และแนะนาให้ ทางานเพียงแค่ พอเท่ าที่
จาเป็ นสาหรับแต่ ละรุ่ นของซอฟต์ แวร์ เพือ่ ให้ ความสะดวกแก่ การเคลือ่ นไปสู่
รุ่ นถัดไป
80
สรุป
- Scrum (สครัม)
- เน้ นการใช้ ชุดแบบรู ปกระบวนการซอฟต์ แวร์ ทไี่ ด้ ผลมาแล้ ว สาหรับโครงการทีม่ ี
เวลาจากัด มีการเปลีย่ นแปลงความต้ องการ และมีความสาคัญยิง่ ยวดทางธุรกิจ
- Crystal (คริสตัล)
- เป็ นกลุ่มครอบครัวของแบบจาลองกระบวนการ Agile ทีส่ ามารถปรับตัวเข้ ากัน
ลักษณะเฉพาะตัวโครงการต่ าง ๆ
- คริสตัลใช้ กลยุทธ์ การทาวนซ้า แต่ ปรับความเข้ มข้ นของกระบวนการ ให้ รองรับ
โครงการที่มขี นาดและความซับซ้ อนระดับต่ าง ๆ กัน
81
สรุ ป
- Feature Driven Development (FDD)
- เป็ นวิธี Agile ทีค่ ่ อนข้ างเป็ นทางการกว่ าวิธีการอืน่ ๆ
- แต่ ยงั คงความคล่ องตัว
- เน้ นความสนใจของทีมพัฒนาไปทีค่ ุณลักษณะของซอฟต์ แวร์ ทีน่ ิยามไว้ เป็ นหน้ าทีก่ ารทางาน
อันมีคุณค่ าแก่ ลูกค้ า ทีส่ ามารถอินพลีเม้ นต์ ให้ เสร็จได้ ภายในเวลาสองสั ปดาห์ หรือน้ อยกว่ า
- FDD ให้ ความสาคัญแก่ การบริหารโครงการมากว่ าวิธีอนื่ ๆ
- Agile Modeling (AM)
- แบบจาลองจาเป็ นสาหรับทุกระบบ
- แต่ ขนาด ประเภท และความซับซ้ อนของแบบจาลอง ต้ องปรับเข้ ากับซอฟต์ แวร์ ทจี่ ะสร้ าง
82
สรุ ป
- การผลิตซอฟต์ แวร์ จาเป็ นต้ องดาเนินการในรู ปแบบของ กระบวนการ (Process)
- กระบวนการทีป่ ระกอบไปด้ วยกลุ่มกิจกรรมทีส่ ั มพันธ์ กนั ในการผลิตซอฟต์ แวร์ ให้
ได้ คุณภาพ เรียกว่ า Software Process หรือ Software Development Process
- เพือ่ ให้ ผลิตภัณฑ์ ซอฟต์ แวร์ มีคุณภาพ ต้ องนาหลักการวิศวกรรมซอฟต์ แวร์ เข้ ามา
ดูแลกระบวนการผลิตซอฟต์ แวร์
- กระบวนการวิศวกรรมซอฟต์ แวร์ (Software Engineering Process) มี
กระบวนการผลิตซอฟต์ แวร์ เป็ นพืน้ ฐานสาคัญ
- แบบจาลองกระบวนการผลิตซอฟต์ แวร์ (Software Process Model) เป็ นสิ่ งที่ช่วย
ให้ เห็นภาพของการกระบวนการผลิตซอฟต์ แวร์ ได้ ชัดเจนทีส่ ุ ด
83
สรุป
- สิ่ งทีเ่ ป็ นหน้ าที่สาคัญของวิศวกรซอฟต์ แวร์ คือ การปรับปรุ งกระบวนการผลิต
(Process Improvement) เพือ่ ตอบสนองต่ อแนวคิดประสิ ทธิภาพของกระบวนการ
- สถาบันวิศวกรรมแห่ งสหรัฐอเมริกา (SEI) ได้ พฒ
ั นา แบบจาลองวุฒิภาวะ
ความสามารถ (Capability Maturity Model : CMM) เพือ่ ใช้ วดั ระดับวุฒิภาวะ
ความสามารถของกระบวนการผลิตของแต่ ละองค์ กร เพือ่ ปรับปรุ งไปสู่ วุฒิภาวะใน
ระดับสู งขึน้
84