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

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) ควบคูก
่ น
ั ไป
 การทดสอบของผลิตภัณฑ์
กระทาขนานกันไปกับการ
วางแผนในการพัฒนา
10
V-Shaped model
 Project and Requirements
Planning – การจัดสรร
ทรัพยากร
 Product Requirements and
Specification Analysis –
กาหนด spec ทีส
่ มบูรณ์ของ
Software
 Architecture or High-Level
Design – กาหนดวิธก
ี าร
ทางานทีต
่ อบสนองต่อการ
ออกแบบ Software
 Detailed Design – การ
พัฒนาอัลกอริทม
ึ สาหรับ
องค์ประกอบต่าง ๆ
 Production, operation and
maintenance – การเพิม
่
ิ ธิภาพและการแก ้ไข
ประสท
 System and acceptance
testing – ตรวจสอบ
สภาพแวดล ้อมของ Software
 Integration and Testing –
ื่ มต่อแต่ละ
ตรวจสอบการเชอ
Module ว่าถูกต ้องหรือไม่
 Unit testing – ตรวจสอบการ
ทางานของแต่ 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
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 กระบวนการผลิตซอฟต ์แวร ์มี
้
ลักษณะเชิงบังค ับให้ทาตามลาด ับขันตอน
อย่างต่อเนื่อง
23
Agile Process
่ องคานึ งเมือ
่
 Agile มีบทบัญญัต ิ 4 ประการทีต้
ต้องพัฒนาซอฟต ์แวร ์ ด ังนี ้ [Agile Alliance
2001]
1. ทีมงานทุกคนมีคณ
ุ ค่าในตัวเองมาก
่
พอทีจะท
างานอย่างอิสระได้
่
2. ทีมงานพอใจทีจะใช้
เวลาส่วนใหญ่ใน
่
การเขียนโปรแกรมเพือสร
้างซอฟต ์แวร ์
่
มากกว่าการใช้เวลาเพือจัดท
าเอกสาร
3. ทีมงานมุ่งเน้นการทางานร่วมกับลู กค้า
โดยตรง แทนการเจรจาอย่างเป็ นทางการ
ตามสัญญาว่าจ้าง
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
Release
Software
Increment
วางแผน
(Planning
)
ทดสอบ
(Testing)
Unit Test
Continuous
integration
Acceptance
Test
Simple Design
Spike Solution :
Prototype
ออกแบบ
(Design)
เขียน
โปรแกรม
(Coding)
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
Release
Speculati
on
Software increment
adjustments for subsequent
cycles
Collabora
tion
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)
 คือ การจู งใจบุคคลให้ทางานร่วมกันในทางที่
่
่
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)
ริน
่ าภายใต้สป รินจะปร
้
่
 งานทีท
ับตวั ตามปั ญหาทีพบ
้ และถู กนิ ยามและปร ับเปลียนให้
่
ขณะนัน
ทน
ั ต่อ
เหตุการณ์เฉพาะหน้าโดยทีมงานสคร ัม
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)
ใช้งานรุน
่ ของซอฟต ์แวร ์ล่าสุดภายใต้สงแวดล้
ิ่
อม
การทางานจริง
 รุน
่ ของซอฟต ์แวร ์อาจไม่ตอ
้ งสมบู รณ์ร ้อย
เปอร ์เซ็นต ์
่
้
 การร ้องขอการเปลียนแปลงอาจเกิ
ดขึนได้
ขณะ
38
ใช้งานอยู ่
Crystal
 พัฒนาโดย Alistair Cockburn และ Jim
Highsmith
 Crystal มีความสามารถในการนาร่อง คือ
 มีทร ัพยากรจาก ัด ทีมงานต้องร่วมมือก ัน ในการ
่
ประดิษฐ ์และการสือสาร
่
 โดยมีเป้ าหมายหลักคือ ส่งมอบซอฟต ์แวร ์ทีมี
ประโยชน์ทางานได้
 เป้ าหมายรองคือ จัดเตรียมความพร ้อมสาหร ับงาน
ถ ัดไป
่
 เพือให้
บรรลุความสามารถในการนาร่อง Cockburn
และ Highsmith ได้นิยามชุดของกรรมวิธ ี และ
กรรมวิธม
ี ช
ี นส่
ิ ้ วนหลัก ๆ เหมือน ๆ ก ัน และมีบทบาท 39
Crystal
่
 วิธก
ี ารพัฒนาแบบ Crystal เน้นทีการแบ่
งแยก
งานออกตามคุณลักษณะ
ของตัว
โครงงาน
 แบ่งตามขนาดของทีมงานพัฒนา หรือแบ่ง
ตามความสาคัญของระบบ
และ
ความสาคัญตามลาดับก่อนหลังของตัว
โครงงาน
 โดยการแบ่งจะแยกออกเป็ นสีเช่น Crystal
Yellow, Crystal Orange เป็ นต้น
 ทุกแบบจะมีชอเรี
ื่ ยกรวมกันว่า Crystal Family
 สาเหตุทต้
ี่ องมีการแบ่งตามลักษณะดังกล่าวก็
40
Crystal
Crystal จะประกอบด้วย 3 ส่วน
่ าคัญ คือ
ทีส
“Human-powered”
o “Ultralight”
o “Stretch-to-fit”
o
41
Development (FDD)
่ บเคลือนด้
่
 การพัฒนาทีขั
วยคุณลักษณะของ
ซอฟต ์แวร ์
 คิดค้น โดย Peter Coad และคณะ
่
 เพือใช้
เป็ นแบบจาลองกระบวนการเชิง
ปฏิบต
ั ก
ิ ารของวิศวกรรมซอฟต ์แวร ์เชิงวัตถุ
 Stephen Palmer และ John Felsing ได้
่
ขยายและเพิมเติ
มงานของ Coad
่ ลู
่ กค้าเห็นว่ามีคณ
 คุณลักษณะ หน้าทีที
ุ ค่า ที่
สามารถอิมพลีเมนต ์ได้ภายเวลาสองสัปดาห ์
หรือน้อยว่า
42
Feature Driven
Development (FDD)
 นิ ยามของคุณลักษณะให้ประโยชน์ตอ
่ ไปนี ้
 เนื่ องจากคุณลักษณะเป็ นส่วนเล็ก ๆ ของซอฟต ์แวร ์ที่




ทางานได้ ผู ใ้ ช้จงึ สามารถอธิบายได้ง่าย เข้าใจ
ความสัมพันธ ์ระหว่างกันได้ง่ายกว่า และสามารถทบทวนได้
่ ความคลุมเครือ ข้อผิดพลาด หรือการหลงลืม
ดีกว่าเมือมี
้ั มี
่
คุณลักษณะอาจถู กจ ัดระเบียบ เป็ นกลุ่มลาดบ
ั ชนที
ความสัมพันธ ์ทางธุรกิจได้
เนื่องจากลักษณะเป็ นรุน
่ ๆ ของคุณลักษณะของซอฟต ์แวร ์
่ องส่งมอบได้ในการพัฒนาแบบ FDD ทีมงานจะมุ่ง
ทีต้
่ างานได้ทุก ๆ
พัฒนาซอฟต ์แวร ์ให้มค
ี ุณลักษณะใหม่ ๆ ทีท
สองสัปดาห ์
เนื่องจากคุณลักษณะมีขนาดเล็ก ตวั แบบและตวั โค้ดของ
คุณลักษณะจึงง่ ายต่อการตรวจทานอย่างละเอียด
การวางแผนโครงการ การจัดตารางงาน และติดตามจะ
43
Agile Modeling (AM)
่
 การสร ้างแบบจาลองเพือ
่
้
่ าเป็ นต้องทา
 เพือเข้
าใจส่วนประกอบทังหมดว่
ามีอะไรทีจ
่
 เพือแบ่
งปั ญหาออกเป็ นส่วน ๆ ให้เหมาะสมกับผู ท
้ จะท
ี่
างาน
นี ้
่
้
่
 เพือให้
สามารถประเมินคุณภาพได้ทุก ๆ ขันตอนเมื
อระบบ
้
กาลังถู กประกอบขึนมา
 Scott Amble อธิบายการสร ้างแบบจาลอง
ของ Agile
 การสร ้างแบบจาลอง Agile เป็ นวิธก
ี ารเชิงปฏิบต
ั ก
ิ าร
สาหร ับการสร ้างแบบจาลอง และการบันทึกเอกสารของ
่ ผล กล่าวอย่างง่ าย การสร ้าง
ระบบซอฟต ์แวร ์ทีได้
แบบจาลอง Agile เป็ นการรวบรวมคุณค่า หลักการ และ
หลักปฏิบต
ั ิ สาหร ับการสร ้างแบบจาลองซอฟต ์แวร ์ที่
44
Agile Modeling (AM)
 AM มีเอกลักษณ์ด ังนี ้
 สร ้างแบบจาลองอย่างมีเป้ าหมาย (Model
with a purpose)
 ใช้แบบจาลองหลาย ๆ ต ัว (Use multiple
models)
 เดินทางอย่างเบาตัว (Travel light)
้
 เนื อหาส
าค ัญกว่ารู ปแบบ (Content is
more important than representation)
่
่ อกใช้ให้ด ี
 รู ้จักแบบจาลองและเครืองมื
อทีเลื
45
CMM (ปร ับปรุงกระบวนการผลิตซอฟต ์แวร ์ด้วย
แบบจาลองวุฒภ
ิ าวะความสามารถ)
วิศวกรรมซอฟต ์แวร ์ เป้ าหมายสาคัญคือ การผลิตซอฟต ์แวร ์ให้ม ี
คุณภาพ
 คุณภาพ
 ผลิตภัณฑ ์
่ อกใช้
 กระบวนการ ผลิตซอฟต ์แวร ์ทีเลื
 จาเป็ นต้องมีการปร ับกระบวนการให้สอดคล้องกับเทคนิ ค ระเบียบวิธ ี
่
หรือเครืองมื
อชนิ ดใหม่เข้ามา
ประยุกต ์ใช้
 การปร ับปรุงกระบวนการ (Process Improvement)
 กลยุทธ ์ในการปร ับปรุงกระบวนการ
 Total Quality Management (TQM)
 Business Process Redesign (BPR)
 Continuous Process Improvement (CPI)
 Six Sigma

46
CMM(ปร ับปรุงกระบวนการผลิตซอฟต ์แวร ์ด้วย
แบบจาลองวุฒภ
ิ าวะความสามารถ)

แ บ บ จ า ล อ ง วุ ฒิ ภ า ว ะ ค ว า ม ส า ม า ร ถ ( Capability
Maturity Model : CMM)

SW-CMM
(Software
Capability
Maturity
Model)

คิด ค้นโดย สถาบัน วิศ วกรรมซอฟต แ์ วร ์ (Software
Engineering Institute : SEI) แห่งมหาวิทยาลัยคาร ์
เนกีเมลอน ประเทศสหร ัฐอเมริกา
 มีว ต
ั ถุ ป ระสงค เ์ พื่อช่ ว ยเหลือ องค ก
์ รหรือ หน่ วยงาน
ผลิต ซอฟต แ์ วร ์ให้ส ามารถปร บ
ั ปรุ ง การด าเนิ น งานได้
47
ปร ับปรุงกระบวนการผลิตซอฟต ์แวร ์ด้วยแบบจาลอง
วุฒภ
ิ าวะความสามารถ

แ บ บ จ า ล อ ง วุ ฒิ ภ า ว ะ ค ว า ม ส า ม า ร ถ ( Capability
Maturity Model
: CMM)
มีการปร
ับปรุง
ระดับที่ 5 ดุลย
กระบวนการอย่าง
ภาพ
ต่อเนื่อง
(Optimizing)
การบริหารการ
ระดับที่ 4 การ
่
มีการควบคุม
เปลียนแปลง
จ ัดการ
กระบวนการ
(Managed)
การบริหารเชิง
่
ระดับที 3 การ
ปริมาณ
กาหนดนิ ยาม
มีการพัฒนา
(Defined)
กระบวนการ
การบริหาร
ระดับที่ 2 การ
วิศวกรรม
้
กระทาซาได้
มีสภาพแวดล้อมที่
(Repeatable)
การบริหาร
่
มันคง
่
ระดับที 1 การ
โครงการ
่ น
เริมต้
(Initial)
48
ปร ับปรุงกระบวนการผลิตซอฟต ์แวร ์ด้วยแบบจาลอง
วุฒภ
ิ าวะความสามารถ

แ บ บ จ า ล อ ง วุ ฒิ ภ า ว ะ ค ว า ม ส า ม า ร ถ ( Capability
Maturity Model : CMM)
่ น (The
 วุฒภ
ิ าวะระดับที่ 1 ระดับการเริมต้
initial
Level)

องค ก
์ รไม่ ม ีค วามแน่ นอนในการพัฒ นาและการ
บารุงร ักษาซอฟต ์แวร ์
่
่ อง
 ปั ญ หาทีพบ
การไม่บรรลุ ถงึ ข้อตกลงต่าง ๆ ทีต้
้
่ กาหนด
ปฏิบต
ั ต
ิ ามกระบวนการอย่างเป็ นขันตอนที
ได้
ไว้
49
ปร ับปรุงกระบวนการผลิตซอฟต ์แวร ์ด้วยแบบจาลอง
วุฒภ
ิ าวะความสามารถ
แ บ บ จ า ล อ ง วุ ฒิ ภ า ว ะ ค ว า ม ส า ม า ร ถ ( Capability
Maturity Model : CMM)
้
 วุ ฒ ิภ าวะระดับ ที่ 2
ระดับ การกระท าซ าได้
(The
Repeatable Level)
้ มงาน
 องค ์กรจะมีก ารกาหนดนโยบาย การจัด ตังที
และการบริหารโครงการซอฟต ์แวร ์ เป็ นไปอย่างมีแบบ
แผนและช ัดเจน
 การผลิ ต ซอฟต แ
์ วร ใ์ นวุ ฒ ิ ภ าวะระดับ นี ้ จะต้อ ง
คานึ งถึงนโยบายและความมีระเบียบวินย
ั เป็ นสาคัญ
 มีการติดตามผลการทางานตลอดเวลา โดยเฉพาะ
50

ปร ับปรุงกระบวนการผลิตซอฟต ์แวร ์ด้วยแบบจาลอง
วุฒภ
ิ าวะความสามารถ

แ บ บ จ า ล อ ง วุ ฒิ ภ า ว ะ ค ว า ม ส า ม า ร ถ ( Capability
Maturity Model : CMM)
 วุฒภ
ิ าวะระดับที่ 3
ระดับการกาหนดนิ ยาม (The
Defined Level)
 ผลต่อเนื่ องจากวุฒภ
ิ าวะระดับที่ 2
มุ่งเน้นการกาก ับ ติดตาม และควบคุมกระบวนการ
่ กาหนดนิ ยามไว้ในทุก ๆ
ต่าง ๆ ผ่านทางเอกสารทีได้

้
ขันตอน
(Documented and Integrated Process)

คานึ งถึงการจัดการด้านเอกสารประกอบการ
51
ปร ับปรุงกระบวนการผลิตซอฟต ์แวร ์ด้วยแบบจาลอง
วุฒภ
ิ าวะความสามารถ

แ บ บ จ า ล อ ง วุ ฒิ ภ า ว ะ ค ว า ม ส า ม า ร ถ ( Capability
Maturity Model : CMM)
 วุฒภ
ิ าวะระดับที่ 4 ระดับการจัดการ (The Managed
Level)

่
องค ์กรมีการกาหนดมาตรฐาน (Standard) เพือใช้
เป็ นบรรทัดฐานในการประเมินกระบวนการ

กระบวนการผลิ ต ซอฟต แ
์ วร ์ในวุ ฒ ิ ภ าวะระดับ นี ้
จะต้อ งค านึ งถึ ง มาตรฐานและการปร บ
ั ปรุ ง อย่ า ง
ต่อเนื่ องเป็ นสาคัญ
52
ปร ับปรุงกระบวนการผลิตซอฟต ์แวร ์ด้วยแบบจาลอง
วุฒภ
ิ าวะความสามารถ

แ บ บ จ า ล อ ง วุ ฒิ ภ า ว ะ ค ว า ม ส า ม า ร ถ ( Capability
Maturity Model : CMM)
 วุฒภ
ิ าวะระดับที่ 5 ระดับดุลยภาพ (The Optimizing
Level)

เ ป็ น อ ง ค ์ ก ร แ ห่ ง ก า ร เ รี ย น รู ้ ( Learning
Organization)
มีค วามสามารถในการจัด สรรทร พ
ั ยากรได้อ ย่ า ง
่ ด
คุม
้ ค่า และเหมาะสมทีสุ


มีเ ทคโนโลยี (Technology) และฐานองค ค
์ วามรู ้
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,
59
่ อทีใช
่ ้ในการวิศวกรรมซอฟต ์แวร ์
เครืองมื

CASE Tools
CASE (Computer-Aided Software Engineering)
ห ม า ย ถึ ง ซ อ ฟ ต แ
์ วรท
์ ี่ เ ป็ น เ ค รื่อ ง มื อ ที่ มี ส่ ว น ช่ ว ย
ส นั บ ส นุ น ก า ร ท า ง า นใ น กิ จ ก ร ร ม ต่ า ง ๆ ข อ ง ง า น
วิศวกรรมซอฟต ์แวร ์
่ น CASE Tool จะต้องมีฟังก ์ช ันต่าง ๆ
 ซอฟต ์แวร ์ทีเป็
ให้ทม
ี งานได้เลือกใช้ เช่น
 หน้าต่างออกแบบโปรแกรม (Design Editor)
 พจนานุ กรมข้อมู ล (Data Dictionary)
 คอมไพเลอร ์ (Compiler)
60
 ดีบก
ั เกอร ์ (Debugger)

่ อทีใช
่ ้ในการวิศวกรรมซอฟต ์แวร ์
เครืองมื

CASE Tools
CASE
ถือ ว่ า เป็ นเทคโนโลยีช นิ ดหนึ่ งที่เพิ่ม
ความสามารถให้ก ับซอฟต ์แวร ์
่
 องค ์ประกอบสาคัญของ CASE คือ Repository ซึงมี
่ จด
ลักษณะเหมือนฐานข้อมู ลทีใช้
ั เก็บรายละเอียดต่าง ๆ
่ กพัฒนาได้จด
้
ทีนั
ั ทาขึน
 ในยุคแรกของเทคโนโลยี CASE
มีขอ
้ จากด
ั คือ ระบบ
การทางานของ CASE
มีลาดับกิจกรรมต่อเนื่ องกน
ั
อต
ั โนมัต ิ แต่ ง านในทางวิ ศ วกรรมซอฟต แ
์ วร ์เป็ นไป
ในทางความคิดสร ้างสรรค ์
61 ่
 CASE ในยุคแรก ๆ ยังมีความสามารถไม่เพียงพอทีจะ

่ อทีใช
่ ้ในการวิศวกรรมซอฟต ์แวร ์
เครืองมื

ชนิ ดของ CASE
 CASE Tool สามารถจาแนกได้หลายประเภท
่
 จ าแนกตามหน้ า ทีของ
CASE
Tools
(Functional Perspective)
 จาแนกตามกระบวนการทางาน
(Process Perspective)
 จ าแนกตามการประสานเข้า กับ CASE
่ ๆ (Integration Perspective)
Tools อืน
62
่ อทีใช
่ ้ในการวิศวกรรมซอฟต ์แวร ์
เครืองมื

ชนิ ดของ CASE
้
 จ าแนกตามกระบวนการท างาน ขันตอนต่
า ง ๆ แล้ว
สามารถแบ่ง CASE Tools ออกเป็ น 8 กลุ่ม ดังนี ้
1.
2.
3.
4.
5.
6.
7.
เ ค รื่อ ง มื อ ส า ห ร บ
ั ก าร วิ เ ค ร า ะห ค
์ ว า ม ต้อ ง ก า ร ( Software
Requirement Tool)
่
เครืองมื
อออกแบบซอฟต ์แวร ์ (Software Design Tools)
่
เครืองมื
อสร ้างซอฟต ์แวร ์ (Software Construction Tools)
่
เครืองมื
อทดสอบซอฟต ์แวร ์ (Software Testing Tools)
่
เครืองมื
อบ ารุ งร ักษาซอฟต ์แวร ์ (Software
Maintenance
Tools)
่
เครืองมื
อ จัด การโครงแบบ (Software
Configuration
Management Tools)
63
เ ค รื่ อ ง มื อ บ ริ ห า ร ง า น วิ ศ ว ก ร ร ม ซ อ ฟ ต ์แ ว ร ์ ( Software
่ อทีใช
่ ้ในการวิศวกรรมซอฟต ์แวร ์
เครืองมื

ชนิ ดของ CASE
่
เครืองมื
อ ส าหร บ
ั การวิเ คราะห ค
์ วามต้อ งการ
(Software Requirement Tool)
แบ่งออกเป็ น 2 กลุ่ม ได้แก่
่
เครืองมื
อในการสรา้ งแบบจ าลองความต้อ ง
่
่ ใน
(Requirement Modeling Tools) เป็ นเครืองมื
อทีใช้
การดึง ความต้อ งการ วิเ คราะห ์ ก าหนด และตรวจสอบ
ความต้องการด้านซอฟต ์แวร ์
่
- เครืองมื
อการติดตามความต้องการ (Requirement
่
่ ตด
Traceability
Tools) เป็ นเครืองมื
อทีใช้
ิ ตามความ
่
่
ต้องการทีเปลี
ยนแปลงอยู
่ตลอดเวลา
64
1.
่ อทีใช
่ ้ในการวิศวกรรมซอฟต ์แวร ์
เครืองมื

ชนิ ดของ 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
66
่ อทีใช
่ ้ในการวิศวกรรมซอฟต ์แวร ์
เครืองมื

ชนิ ดของ CASE
่
5.
เครืองมื
อ บ ารุ ง ร ก
ั ษาซอฟต แ
์ วร ์ (Software
Maintenance Tools)
่
่ บารุงร ักษาซอฟต ์แวร ์ทีมี
่ อยู ่แล้ว ให้คง
เป็ นเครืองมื
อทีใช้
่ การได้อย่างดี แบ่งเป็ น 2 กลุ่ม ได้แก่
สภาพทีใช้
่
1. เครืองมื
อสร ้างความเข้าใจ (Comprehension Tools)
่
เป็ นเครืองมื
อ ที่ช่ ว ยให้ท ี ม ซ่ อ มบ ารุ ง ท าความเข้า ใจกับ
้
โปรแกรมของซอฟต ์แวร ์ได้ง่ายขึน
่
้
2. เครืองมื
อรือปร
ับระบบใหม่ (Reengineering Tools)
้
เ ป็ นเ ค รื่อ งมื อ ที่ ช่ ว ยในกระบวนการรือโค
รงส ร า
้ งขอ ง
ซอฟต แ
์ วร ์ทีล ะส่ ว น เพื่อน ามาปร บ
ั หรือ แก้ไ ขให้ม ีส ภาพ
สมบู รณ์เหมือนเดิม
67
่
่ ในการวิศวกรรมซอฟต ์แวร ์
เครืองมื
อทีใช้

ชนิ ดของ CASE
7.
่
เครืองมื
อบริหารงานวิศวกรรมซอฟต ์แวร ์ (Software
Engineering Management Tools) ได้แก่
่
เครืองมื
อวางแผนและติดตามโครงการ (Project Planning
่ ในการประมาณการแรงงาน
and Tracking) ได้แก่ ซอฟต ์แวร ์ทีใช้
้ ดตารางงาน
และต้นทุน พร ้อมทังจั
่
่ (Risk Management) ได้แก่
เครืองมื
อจัดการความเสียง
่ ระบุปัจจัยเสียง
่ ประมาณการผลกระทบ และติดตาม
ซอฟต ์แวร ์ทีใช้
่
ความเสียง
่
- เครืองมื
อวัดผลโครงการ (Measurement) ได้แก่ ซอฟต ์แวร ์ที่
ใช้ในการวัดผลทุกกิจกรรมของโครงการ
่
8. เครืองมื
อคุณภาพซอฟต ์แวร ์ (Software Quality Tools)
-
่
เครืองมื
อตรวจสอบคุณภาพ (Inspection
Tools) ได้แก่
่
เครืองมื
อและระเบียบวิธท
ี ใช้
ี่ ในการวิศวกรรม
ซอฟต ์แวร ์
่
่ ยวข้
่ ๆ ทีเกี
องก ับ 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: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
ระเบียบวิธป
ี ฏิบต
ั ข
ิ องวิศวกรรมซอฟต์แวร์
ตัวอย่างอ็อบเจ็กต ์
objec
ID Invoice
No.
Address
t
A/C No.
Amount
Attrib
Computer value
utes
of goods
Computer
discount
Meth
Computer Ad.
Charge
Computer
ods
Invoice Amount
แสดงต ัวอย่างอ็อบเจ็กต ์
76
ระเบียบวิธป
ี ฏิบัตข
ิ องวิศวกรรม
ซอฟต์แวร์
3. Heuristic Methodology
- เป็ นระเบียบวิธท
ี ไม่
ี่ เป็ นแบบแผน (Informal
Method)
- ไม่มก
ี ารนาวิธก
ี ารทางคณิ ตศาสตร ์เข้าไปใช้
้
ในขันตอนต่
าง ๆ
- Methodology
- Structured Methodology/Approach
่ าทีการท
่
มุ่งเน้นทีหน้
างานของ
โปรแกรม
- Object-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
84
สรุป
่ เป็
่ นหน้าทีส
่ าคัญของวิศวกรซอฟต ์แวร ์ คือ การ
- สิงที
ปร ับปรุงกระบวนการผลิต (Process Improvement)
่
เพือตอบสนองต่
อแนวคิดประสิทธิภาพของกระบวนการ
- สถาบันวิศวกรรมแห่งสหร ัฐอเมริกา (SEI) ได้
พัฒนา แบบจาลองวุฒภ
ิ าวะความสามารถ (Capability
่
Maturity Model : CMM) เพือใช้
ว ัดระดับวุฒภ
ิ าวะ
ความสามารถของกระบวนการผลิตของแต่ละองค ์กร
่
้
เพือปร
ับปรุงไปสู ่วฒ
ุ ภ
ิ าวะในระดบ
ั สู งขึน
85