software process n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
กระบวนการผลิตซอฟต์แวร์ ( Software Process) PowerPoint Presentation
Download Presentation
กระบวนการผลิตซอฟต์แวร์ ( Software Process)

Loading in 2 Seconds...

play fullscreen
1 / 85

กระบวนการผลิตซอฟต์แวร์ ( Software Process) - PowerPoint PPT Presentation


  • 338 Views
  • Uploaded on

กระบวนการผลิตซอฟต์แวร์ ( Software Process). SDLC (Software Development Life Cycle).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'กระบวนการผลิตซอฟต์แวร์ ( Software Process)' - taran


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
sdlc software development life cycle
SDLC (Software Development Life Cycle)
  • วงจรการพัฒนาระบบ คือ กระบวนการทางความคิด ( Logical Process)ในการพัฒนาระบบสารสนเทศเพื่อแก้ปัญหาทางธุรกิจและตอบสนองความต้องการของผู้ใช้ได้ โดยภายในวงจรนั้นแบ่งกระบวนการพัฒนาออกเป็นระยะ ( Phase ) ได้แก่ ระยะการวางแผน( Planning Phase) ระยะการวิเคราะห์ ( Analysis Phase) ระยะการออกแบบ ( Design Phase) และระยะการสร้างและพัฒนา( Implementation Phase )โดยแต่ละระยะจะประกอบไปด้วยขั้นตอน ( Steps ) ต่าง ๆ ซึ่งแต่ละโครงการพัฒนาระบบจะมีการแบ่งระยะและขั้นตอนในแต่ละระยะแตกต่างกัน ทำให้ปัจจุบันมีรูปแบบของวงจรการพัฒนาระบบแตกแขนงออกไปมาก
slide3
ประเภทของ SDLC
  • Waterfall
  • V-Shaped
  • Spiral
  • Increment
  • Agile
waterfall model
Waterfall model
  • SDLC แบบ Waterfall มีหลักการเปรียบเสมือนกับน้ำตก ซึ่งไหลจากที่สูงลงที่ต่ำ และไม่สามารถไหลกลับมาในทางตรงกันข้ามได้อีก
  • การพัฒนาระบบงานด้วยหลักการนี้ เมื่อทำขั้นตอนหนึ่งแล้วจะไม่สามารถย้อนกลับมาที่ขั้นตอนก่อนหน้าได้อีก
  • ซึ่งจะมองเห็นจุดอ่อนของหลักการนี้ว่า หากมีข้อผิดพลาดเกิดขึ้นที่ขั้นตอนก่อนหน้านี้แล้ว จะไม่สามารถย้อนกลับมาแก้ไขได้ ดังนั้น การพัฒนาระบบด้วยหลักการนี้ จำเป็นต้องมีการวางแผนที่ดี เพื่อให้สามารถป้องกันการผิดพลาดได้มากที่สุด ซึ่งทำได้ยากมาก ยกเว้นระบบงานนั้นมีรูปแบบการพัฒนาที่ดี และตายตัวอยู่แล้ว
waterfall model1

…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

Waterfall model
  • Waterfall Model เป็นแบบจำลองกระบวนการพัฒนาระบบแบบดั้งเดิม โดยมีแนวคิดว่ากิจกรรมหนึ่งจะเริ่มต้นดำเนินการได้ก็ต่อเมื่อกิจกรรมก่อนหน้าได้ทำเสร็จสิ้นสมบูรณ์แล้ว
  • ในปัจจุบันนักพัฒนาระบบได้ตระหนักแล้วว่า Waterfall Model ไม่เหมาะสมกับการนำมาใช้เป็นแบบแผนของการพัฒนาระบบอีกต่อไป
  • เนื่องจากระบบในปัจจุบันมีความซับซ้อน นักพัฒนาระบบเองไม่สามารถตอบได้อย่างแน่นอนว่ากิจกรรมที่ได้ดำเนินการนั้นได้ทำเสร็จสิ้นสมบูรณ์แล้วหรือยัง
  • ถ้านำ Product ที่ยังไม่สมบูรณ์ไปพัฒนาต่อในขั้นตอนกิจกรรมต่อไปก็จะทำให้ Product ที่จะได้จากขั้นตอนต่อไปไม่สมบูรณ์เช่นกัน เปรียบเสมือนการส่งมอบความเสี่ยงให้กันเป็นทอดๆ
  • ตัวอย่างเช่น การวิเคราะห์ความต้องการเราไม่อาจบอกได้ว่าความต้องการที่วิเคราะห์มานั้นเป็นความต้องการที่ถูกต้องแน่นอนและครบถ้วนสมบูรณ์ ซึ่งในความเป็นจริงความต้องการมีการเปลี่ยนแปลงได้ตลอดเวลาและสามารถเกิดความต้องการใหม่ๆได้เสมอ ถ้าเรานำความต้องการทั้งหมดมาพัฒนาในครั้งเดียวเราจะทราบอีกครั้งว่า ความต้องการใดที่ไม่ถูกต้องก็ต่อเมื่อระบบได้พัฒนาเสร็จและได้รับการประเมินจากผู้ใช้แล้ว ซึ่งใช้เวลานานกว่าจะทราบได้
waterfall
ข้อดีของ Waterfall
  • ง่ายต่อการทำความเข้าใจ, ง่ายต่อการใช้งาน
  • มีโครงสร้างที่ชัดเจนเหมาะสำหรับผู้เริ่มต้นในการออกแบบ
  • มี Milestones ที่เข้าใจได้ง่าย
  • Sets requirements stability (ความต้องการของระบบหรือความต้องการของ user ไม่เปลี่ยนแปลง หรือ เปลี่ยนแปลงน้อยมาก)
  • มีการจัดการและการควบคุมที่ดี(plan, staff, track)
  • ทำงานได้ดีเพื่อเน้นประสิทธิภาพ มากกว่าเน้นค่าใช้จ่ายและตารางเวลาที่จำกัด

ไมล์สโตน (Milestone) หมายถึง การระบุผลผลิตของงาน (output) ที่ต้องการจะให้เกิดขึ้นในแผน เพื่อใช้เป็นเครื่องมือในการตรวจสอบและติดตามผลงานที่เกิดขึ้น

waterfall1
ข้อด้อยของ Waterfall
  • ความต้องการทั้งหมดจะต้องถูกวิเคราะห์อย่างถูกต้องมาก่อน
  • เมื่อส่งมอบงานแล้ว การแก้ไขแต่ละขั้นตอนมีความยืดหยุ่นน้อย
  • อาจมีความผิดพลาดบ้างในแต่ละขั้นตอน
  • แก้ปัญหาการพัฒนาซอฟต์แวร์ไม่ได้ทั้งหมด
  • อาจมีปัญหาในตอนท้ายหากต้องทำการรวมกับ Module อื่น
  • ลูกค้ามีโอกาสน้อยที่จะมองภาพระบบโดยรวมก่อนใช้งาน
waterfall model2
จะใช้Waterfall Model เมื่อไร
  • ความต้องการของ User มีความแน่นอนไม่เปลี่ยนแปลง
  • ระบบมีความเสถียร
  • User ยอมรับเทคโนโลยีใหม่ ๆ
  • การถ่ายโอนซอฟต์แวร์จาก platform เดิมไป platform ใหม่
adapted waterfall model
Adapted Waterfall model

SDLC แบบ Adapted Waterfall เป็นรูปแบบในการพัฒนาระบบงานที่ปรับปรุงมาจากแบบ waterfall โดยในแต่ละขั้นตอนเมื่อดำเนินงานอยู่ สามารถย้อนกลับมายังขั้นตอนก่อนหน้าเพื่อแก้ไขข้อผิดพลาดหรือสามารถย้อนกลับข้ามขั้น โดยไม่จำเป็นต้องเป็นขั้นตอนที่ติดกันได้

v shaped model
V-Shaped model
  • เป็น Model ที่เน้นการตรวจสอบ(verification) และการรับรองความถูกต้อง(validation) ควบคู่กันไป
  • การทดสอบของผลิตภัณฑ์กระทำขนานกันไปกับการวางแผนในการพัฒนา Software
v shaped model1
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
v shaped model2
ข้อดีของ V-Shaped model
  • เน้นการวางแผนสำหรับการ Verification และ Validation ของผลิตภัณฑ์ในขั้นเริ่มต้นของการพัฒนาผลิตภัณฑ์
  • งานที่ส่งมอบต้องสามารถทดสอบได้ทุกขั้นตอน
  • สามารถติดตามความก้าวหน้าได้ทุกขั้นตอน
  • เข้าใจง่ายและใช้งานได้ง่าย
v shaped model3
ข้อด้อยของ V-Shaped Model
  • ยากต่อการจัดการเหตุการณ์ที่เกิดขึ้นพร้อมกัน
  • ยากต่อการจัดการกับ Requirement ที่มีการเปลี่ยนแปลงบ่อยๆ
  • ไม่มีระบบการจัดการความเสี่ยง (Risk Management)
v shaped model4
จะใช้ V-shaped Model เมื่อไร
  • ใช้ในระบบที่ต้องการความเสถียรสูง (high reliability) เช่น ระบบเกี่ยวการจัดการภายในโรงพยาบาล (hospital patient control applications)
  • ระบบที่มี Requirement ที่พร้อมและค่อนข้างครบถ้วน
spiral model1
Spiral model
  • แบบจำลองspiral แบ่งออกได้เป็นส่วนย่อยๆ โดยปกติจะแบ่งเป็น 3 ส่วน หรือ 6 ส่วนงานเช่น
    • การติดต่อสื่อสารกันระหว่างผู้ใช้ และผู้พัฒนาระบบ
    • การวางแผน
    • การวิเคราะห์ความเสี่ยง
    • วิศวกรรม
    • การสร้างและนำไปใช้
    • การประเมินผลจากผู้ใช้
spiral model2
Spiral model
  • แต่ละรอบของการทำซ้ำ
    • วิเคราะห์ความเสี่ยง
    • พัฒนาต้นแบบสำหรับตรวจสอบความเป็นไปได้และความต้องการ
    • เมื่อพบความเสี่ยงผู้จัดการโครงการจะต้องตัดสินใจทีจะกำจัดหรือลดความเสี่ยง
spiral model3
Spiral model
  • แต่ละรอบของการทำซ้ำ
    • วิเคราะห์ความเสี่ยง
    • พัฒนาต้นแบบสำหรับตรวจสอบความเป็นไปได้และความต้องการ
    • เมื่อพบความเสี่ยงผู้จัดการโครงการจะต้องตัดสินใจทีจะกำจัดหรือลดความเสี่ยง
spiral model4
Spiral model
  • ปัญหาของการใช้แบบจำลองบันไดเวียน ในการพัฒนาซอฟต์แวร์ คือการโน้มน้าวให้ผู้ใช้ระบบเห็นชอบกับวิธีการที่เป็นกระบวนทำซ้ำแบบมีวิวัฒนาการ
  • ความสำเร็จของการใช้ แบบจำลองบันไดเวียน ผู้พัฒนาจะต้องมีความเชี่ยวชาญในด้านการประเมินผลความเสี่ยง
spiral model5
Spiral model
  • เป็น model ที่ใช้ความเสี่ยงเป็นเครื่องตัดสินใจว่าจะกระทำอะไรต่อไป (risk-driven)
  • ขั้นตอนในแต่ละรอบ
    • วิเคราะห์เป้าหมาย แนวทางเลือกต่างๆ เงื่อนไขต่างๆ
    • วิเคราะห์ความเสี่ยง
    • พยายามลดความเสี่ยงนั้น เช่น ทำ Prototype เพื่อทดสอบ
    • พัฒนา product
    • นำ product ให้ลูกค้าทดสอบ
iterative and incremental model
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

iterative and incremental model1
Iterative and Incremental Model
  • เป็นแบบจำลองกระบวนการซึ่งรองรับความไม่แน่นอนต่างๆ ที่จะเกิดขึ้นในการพัฒนาระบบโดยมีแนวคิดว่า การค่อยๆพัฒนาระบบจากเล็กไปใหญ่เป็นการลดความเสี่ยงของการพัฒนา
  • การพัฒนานั้นประกอบด้วยหลายรอบของ SDLC
  • แต่ละรอบจะพัฒนาเฉพาะส่วน (ไม่ใช่ทีเดียวทั้งหมด) แล้วค่อยๆ เพิ่มเติมให้ระบบใหญ่ขึ้นจนกว่าจะเสร็จสมบูรณ์ (ผู้ใช้ยอมรับ)
  • ไม่อาจคาดการณ์อย่างแน่นอนได้ว่าจะต้องใช้รอบในการพัฒนากี่รอบ
agile process
Agile Process
  • Agile แปลว่า คล่องแคล่ว ฉลาด ฉับไว
  • Agile Process เป็นกระบวนการผลิตซอฟต์แวร์รูปแบบใหม่ที่ถูกกำหนดขึ้นตามระเบียบวิธีปฏิบัติแบบ Agile
  • เป็นระเบียบวิธีที่แตกแขนงจาก RAD (Rapid Application Development) ที่เน้นการผลิตซอฟต์แวร์แบบเร่งด่วน
  • ปี ค.ศ. 1970 กระบวนการผลิตซอฟต์แวร์มีลักษณะเชิงบังคับให้ทำตามลำดับขั้นตอนอย่างต่อเนื่อง
  • ปี ค.ศ. 1990 นักพัฒนาซอฟต์แวร์ได้คิดค้นวิธีการพัฒนาซอฟต์แวร์แบบใหม่ที่มีอิสระ ทำให้มีความคล่องตัวสูงในการทำงาน วิธีนี้เรียกว่า “Agile Method”
agile process1
Agile Process
  • Agile มีบทบัญญัติ 4 ประการที่ต้องคำนึงเมื่อต้องพัฒนาซอฟต์แวร์ ดังนี้ [Agile Alliance 2001]

1. ทีมงานทุกคนมีคุณค่าในตัวเองมากพอที่จะทำงานอย่างอิสระได้

2. ทีมงานพอใจที่จะใช้เวลาส่วนใหญ่ในการเขียนโปรแกรมเพื่อสร้างซอฟต์แวร์มากกว่าการใช้เวลาเพื่อจัดทำเอกสาร

3. ทีมงานมุ่งเน้นการทำงานร่วมกับลูกค้าโดยตรง แทนการเจรจาอย่างเป็นทางการตามสัญญาว่าจ้าง

4. ทีมงานให้ความสำคัญกับการแก้ไขงานทันทีที่มีการเปลี่ยนแปลง มากกว่าการวางแผนก่อนลงมือทำงานเมื่อมีการเปลี่ยนแปลง

agile process2
Agile Process
  • Agile
    • XP
    • ASD
    • Scrum
    • DSDM
    • Crystal
    • FDD
    • AM
extreme programming xp
Extreme Programming (XP)
  • คิดค้นโดย Kent Beck
  • ค.ศ. 1999
  • พัฒนาตามแบบ Iteration and Incremental
  • เป็นแบบจำลองกระบวนการผลิตซอฟต์แวร์ที่ใช้แนวทางเชิงวัตถุเป็นหลัก
  • มี 4 ขั้นตอน ได้แก่ การวางแผน ออกแบบ เขียนโปรแกรม และการทดสอบ
extreme programming xp1
Extreme Programming (XP)

User Story

Iteration Plan

Simple Design

Spike Solution : Prototype

วางแผน

(Planning)

ออกแบบ

(Design)

Release

Software Increment

ทดสอบ

(Testing)

เขียนโปรแกรม

(Coding)

Unit Test

Continuous integration

Acceptance Test

Pair Programming

Unit Test

Continuous Integrations

adaptive software development asd
Adaptive Software Development (ASD)
  • การพัฒนาซอฟต์แวร์แบบปรับตัว-เอเอสดีนำเสนอ โดย Jim Highsmith
  • ให้เป็นเทคนิคสำหรับสร้างระบบที่ซับซ้อน
  • เน้นการทำงานร่วมกันระหว่างบุคคล และการจัดระเบียบทีมงานด้วยตนเอง
  • การเรียนรู้ของทีมงานที่ดี และแบ่งงานอย่างเป็นระบบและชัดเจน
adaptive software development asd1
Adaptive Software Development (ASD)

Adaptive cycle planning

Mission statement

Project constraints

Basic requirements

Time-boxed release plan

Requirements gathering

JAD

Mini-specs

Speculation

Collaboration

Release

Learning

Software increment

adjustments for subsequent cycles

Components implemented/tested

Focus groups for feedback

Formal technical reviews postmortems

adaptive software development asd2
Adaptive Software Development (ASD)
  • การคาดเดา (Speculation)
    • โครงการเริ่มต้นขึ้นและมีการทำแผนวงจรการปรับตัว
    • ใช้ข้อมูลเบื้องต้น ได้แก่ ข้อความแสดงภารกิจของลูกค้า เงื่อนไขต่าง ๆ ของโครงการและความต้องการพื้นฐาน เพื่อกำหนดชุดของวงจรรีลิส(release) คือ รุ่นต่าง ๆ ของซอฟต์แวร์ที่โครงการต้องผลิต
  • การร่วมมือ (Collaboration)
    • คือ การจูงใจบุคคลให้ทำงานร่วมกันในทางที่เพิ่มพูนผลลัพธ์ที่สร้างสรรค์และเฉลียวฉลาด
    • การร่วมมือเป็นวิธีที่ใช้ในทุก ๆ วิธีการแบบ Agile
    • การร่วมมือมักไม่ใช่เรื่องง่าย
adaptive software development asd3
Adaptive Software Development (ASD)
  • การร่วมมือ (Collaboration)
    • บุคคลที่ทำงานร่วมกันต้องมีความไว้วางใจกัน เพื่อ
      • การวิพากษ์วิจารณ์โดยปราศจากความข่มชื่น
      • การช่วยเหลือกันโดยปราศจากความเสียใจ
      • การทำงานอย่างหนักเท่าเทียมกัน
      • มีความชำนาญเฉพาะที่จะเป็นประโยชน์ต่องานที่ทำ
      • มีการพูดคุยถึงปัญหาหรือข้อกังวลสงสัยในทางที่นำไปสู่การกระทำที่ได้ประสิทธิผล
adaptive software development asd4
Adaptive Software Development (ASD)
  • การเรียนรู้ (Learning)
    • เมื่อทีมงานเริ่มพัฒนาชิ้นส่วนที่เป็นส่วนหนึ่งของวงจรปรับตัว ทีมงานจะเรียนรู้ไปพร้อม ๆ กับความก้าวหน้าไปสู่การเสร็จสิ้นวงจร
    • ทีมเอเอสดี เรียนรู้ได้ 3 วิธีคือ
      • กลุ่มเฉพาะทาง (Focus Groups) เมื่อลูกค้า/ผู้ใช้งานให้ผลตอบกลับในการใช้งาน โดยแต่ละรุ่นของซอฟต์แวร์ที่ส่งมอบไป สิ่งนี้จะเป็นตัวบ่งชี้ว่าผลิตภัณฑ์ได้ตอบสนองความจำเป็นทางธุรกิจหรือไม่
      • การทบทวนเทคนิคอย่างเป็นทางการ (Formal Technical Review) ทีมเอเอสดีมีการทบทวนชิ้นส่วนซอฟต์แวร์ที่กำหนดพัฒนาอยู่ ขณะเดียวกับมีกาปรังปรุงคุณภาพและเรียนรู้ไปพร้อม ๆ กัน
      • การตรวจสอบภายหลัง (Postmortems) เมื่องานเสร็จสิ้นแล้ว ทีมงานกลายเป็นผู้วิจารณ์งานและคุณภาพของตนเอง ซึ่งเป็นเป้าหมายของการเรียนรู้เพื่อปรับปรุงวิธีการทำงาน
scrum
Scrum
  • Scrum พัฒนาโดย Jeff Sutherland
  • พัฒนาเมื่อต้นทศวรรษ 1990
  • พัฒนาต่อโดย Schwaberและ Beedle
scrum1
Scrum
  • หลักการของ Scrum คือ
    • จัดตั้งทีมทำงานขนาดเล็กที่ เกิดการสื่อสาร การแบ่งปันเทคนิค และข่าวสารที่ไม่เป็นทางการให้มากที่สุด ขณะที่ลดค่าใช้จ่ายส่วนเกินให้น้อยที่สุด
    • กระบวนการต้องสามารถปรับเข้ากับการเปลี่ยนแปลงทางธุรกิจและเทคนิคได้ เพื่อผลิตผลงานให้ดีที่สุด
    • กระบวนการต้องผลิตรุ่นซอฟต์แวร์ออกมาบ่อย ๆ เพื่อตรวจสอบ ปรับแต่ง ทดสอบ บันทึกและต่อยอดได้
    • งานที่พัฒนาและนักพัฒนาจะแบ่งออกเป็น แพ็กเก็ตหรือพาร์ติชั่นที่สะอาดและขึ้นแก่กันน้อยที่สุด
    • มีการทดสอบและบันทึกเอกสารอย่างสม่ำเสมอขณะที่สร้างผลิตภัณฑ์ขึ้นมา
    • กระบวนการสครัมจะต้อง สามารถแจ้งว่า พัฒนาผลิตภัณฑ์เสร็จแล้ว เมื่อใดก็ตามที่ต้องการ อันเนื่องมาจากคู่แข่งออกผลิตภัณฑ์ที่เหมือนกัน หรือบริษัทต้องการเงิน หรือลูกค้าต้องการงาน เป็นต้น
scrum2
Scrum
  • หลักการของ Scrum อยู่ภายใต้กิจกรรมกรอบงานต่อไปนี้
    • ความต้องการ
    • การวิเคราะห์
    • การออกแบบ
    • การวิวัฒน์
    • และการส่งมอบ
  • แต่ละกิจกรรมกรอบงาน จะประกอบด้วยงานย่อย ๆ เกิดขึ้นภายใน เป็นแบบรูปกระบวนการ เรียกว่า สปริ้น (Sprint)
  • งานที่ทำภายใต้สปริ้นจะปรับตัวตามปัญหาที่พบขณะนั้น และถูกนิยามและปรับเปลี่ยนให้ทันต่อเหตุการณ์เฉพาะหน้าโดยทีมงานสครัม
  • Scrum สนับสนุนให้ใช้รูปแบบกระกวนการซอฟต์แวร์ (Software process pattern)
dynamic system development method dsdm
Dynamic System Development Method (DSDM)
  • DSDM หรือวิธีการพัฒนาระบบไม่หยุดนิ่ง เป็นวิธีการพัฒนาซอฟต์แวร์ที่มีการกำหนดกรอบงานสำหรับสร้างและบำรุงรักษาระบบที่มีข้อจำกัดด้านเวลา
  • โดยใช้การสร้างต้นแบบอย่างค่อยเพิ่มขึ้น
  • DSDM => 80% ของแอพพลิเคชัน จะเสร็จภายในเวลา 20% ของเวลาทั้งหมดที่ใช้พัฒนา
  • DSDM เป็นกระบวนการทำวนซ้ำ แต่ละรอบของวงจรจะเป็นไปตามกฎ 80% คือ ทำงานให้เพียงพอเท่าที่จำเป็นในแต่ละรุ่น เพื่อให้เคลื่อนไปสู่รุ่นที่เพิ่มขึ้นถัดไป ส่วนรายละเอียดที่เหลือสามารถทำให้เสร็จภายหลัง เมื่อได้รู้ความต้องการทางธุรกิจเพิ่มเติม หรือเมื่อได้รับการร้องขอให้เปลี่ยนแปลง
dynamic system development method dsdm1
Dynamic System Development Method (DSDM)
  • กระบวนการ DSDM
    • การศึกษาความเป็นไปได้ (Feasibility Study) จัดทำความต้องการและข้อจำกัดทางธุรกิจพื้นฐานของแอพพลิเคชั่นที่จะสร้าง ประเมินความเป็นไปได้
    • การศึกษาด้านธุรกิจ (Business Study) จัดสร้างความต้องการเชิงข่าวสาร และเชิงหน้าที่ของแอพพลิเคชั่น นิยามสถาปัตยกรรมและระบุความต้องการในการบำรุงรักษาแอพพลิเคชั่น
    • การทำวนซ้ำแบบจำลองเชิงหน้าที่ (Functional Model Iteration) ผลิตชุดของต้นแบบค่อยเพิ่มขึ้น ที่มีหน้าที่การทำงานตามที่ลูกค้าต้องการ ต้นแบบจะค่อย ๆ วิวัฒนาการไปเป็นแอพพลิเคชั่นที่ส่งมอบได้ การทำวนซ้ำเป็นการรวบรวมความต้องการเพิ่มเติมจากการตอบสนองกลับมาของผู้ใช้
dynamic system development method dsdm2
Dynamic System Development Method (DSDM)
  • กระบวนการ DSDM
    • การทำวนซ้ำการออกแบบและการสร้าง (Design and Build Iteration) นำต้นแบบที่สร้างขึ้นระหว่างการทำวนซ้ำการสร้างแบบจำลองเชิงหน้าที่มาดูใหม่
    • การอิมพลีเม้นต์ (Implementation หรือ coding) ใช้งานรุ่นของซอฟต์แวร์ล่าสุดภายใต้สิ่งแวดล้อมการทำงานจริง
      • รุ่นของซอฟต์แวร์อาจไม่ต้องสมบูรณ์ร้อยเปอร์เซ็นต์
      • การร้องขอการเปลี่ยนแปลงอาจเกิดขึ้นได้ขณะใช้งานอยู่
  • กระบวนการ DSDM อาจใช้ร่วมกับกระบวนการ XP เพื่อกำหนดแบบจำลองกระบวนการ
crystal
Crystal
  • พัฒนาโดย Alistair Cockburn และ Jim Highsmith
  • Crystal มีความสามารถในการนำร่อง คือ
    • มีทรัพยากรจำกัด ทีมงานต้องร่วมมือกัน ในการประดิษฐ์และการสื่อสาร
    • โดยมีเป้าหมายหลักคือ ส่งมอบซอฟต์แวร์ที่มีประโยชน์ทำงานได้
    • เป้าหมายรองคือ จัดเตรียมความพร้อมสำหรับงานถัดไป
  • เพื่อให้บรรลุความสามารถในการนำร่อง Cockburn และ Highsmithได้นิยามชุดของกรรมวิธี และกรรมวิธีมีชิ้นส่วนหลัก ๆ เหมือน ๆ กัน และมีบทบาท กระบวนการผลิตผลงาน และวิธีปฏิบัติที่แตกต่างกันเฉพาะตัว
  • ครอบครัวคริสตัล ก็คือ ชุดกระบวนการ Agile ที่ได้พิสูจน์แล้วว่าได้ผลดีสำหรับโครงการชนิดต่าง ๆ
crystal1
Crystal
  • วิธีการพัฒนาแบบ Crystal เน้นที่การแบ่งแยกงานออกตามคุณลักษณะ ของตัวโครงงาน
    • แบ่งตามขนาดของทีมงานพัฒนา หรือแบ่งตามความสำคัญของระบบ และความสำคัญตามลำดับก่อนหลังของตัวโครงงาน
    • โดยการแบ่งจะแยกออกเป็นสีเช่น Crystal Yellow, Crystal Orange เป็นต้น
    • ทุกแบบจะมีชื่อเรียกรวมกันว่า Crystal Family
    • สาเหตุที่ต้องมีการแบ่งตามลักษณะดังกล่าวก็เพราะว่ามีการตระหนักถึงความต้องการรูปแบบการพัฒนาที่แตกต่างกันไปตามแต่ละโครงงาน
crystal2
Crystal

Crystal จะประกอบด้วย 3 ส่วนที่สำคัญ คือ

  • “Human-powered”
  • “Ultralight”
  • “Stretch-to-fit”
feature driven development fdd
Feature Driven Development (FDD)
  • การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะของซอฟต์แวร์
  • คิดค้น โดย Peter Coad และคณะ
  • เพื่อใช้เป็นแบบจำลองกระบวนการเชิงปฏิบัติการของวิศวกรรมซอฟต์แวร์เชิงวัตถุ
  • Stephen Palmer และ John Felsingได้ขยายและเพิ่มเติมงานของ Coad
  • คุณลักษณะ หน้าที่ที่ลูกค้าเห็นว่ามีคุณค่า ที่สามารถอิมพลีเมนต์ได้ภายเวลาสองสัปดาห์หรือน้อยว่า
feature driven development fdd1
Feature Driven Development (FDD)
  • นิยามของคุณลักษณะให้ประโยชน์ต่อไปนี้
    • เนื่องจากคุณลักษณะเป็นส่วนเล็ก ๆ ของซอฟต์แวร์ที่ทำงานได้ ผู้ใช้จึงสามารถอธิบายได้ง่าย เข้าใจความสัมพันธ์ระหว่างกันได้ง่ายกว่า และสามารถทบทวนได้ดีกว่าเมื่อมีความคลุมเครือ ข้อผิดพลาด หรือการหลงลืม
    • คุณลักษณะอาจถูกจัดระเบียบ เป็นกลุ่มลำดับชั้นที่มีความสัมพันธ์ทางธุรกิจได้
    • เนื่องจากลักษณะเป็นรุ่น ๆ ของคุณลักษณะของซอฟต์แวร์ที่ต้องส่งมอบได้ในการพัฒนาแบบ FDD ทีมงานจะมุ่งพัฒนาซอฟต์แวร์ให้มีคุณลักษณะใหม่ ๆ ที่ทำงานได้ทุก ๆ สองสัปดาห์
    • เนื่องจากคุณลักษณะมีขนาดเล็ก ตัวแบบและตัวโค้ดของคุณลักษณะจึงง่ายต่อการตรวจทานอย่างละเอียด
    • การวางแผนโครงการ การจัดตารางงาน และติดตามจะขับเคลื่อนด้วยคุณลักษณะตามลำดับชั้น ซึ่งดีกว่าการใช้ชุดงานย่อยที่เลือกมาแบบสุ่ม
agile modeling am
Agile Modeling (AM)
  • การสร้างแบบจำลองเพื่อ
    • เพื่อเข้าใจส่วนประกอบทั้งหมดว่ามีอะไรที่จำเป็นต้องทำ
    • เพื่อแบ่งปัญหาออกเป็นส่วน ๆ ให้เหมาะสมกับผู้ที่จะทำงานนี้
    • เพื่อให้สามารถประเมินคุณภาพได้ทุก ๆ ขั้นตอนเมื่อระบบกำลังถูกประกอบขึ้นมา
  • Scott Amble อธิบายการสร้างแบบจำลองของ Agile
    • การสร้างแบบจำลอง Agile เป็นวิธีการเชิงปฏิบัติการสำหรับการสร้างแบบจำลอง และการบันทึกเอกสารของระบบซอฟต์แวร์ที่ได้ผล กล่าวอย่างง่าย การสร้างแบบจำลอง Agile เป็นการรวบรวมคุณค่า หลักการ และหลักปฏิบัติ สำหรับการสร้างแบบจำลองซอฟต์แวร์ที่สามารถประยุกต์กับโครงการพัฒนาซอฟต์แวร์อย่างได้ผล ในลักษณะที่มีน้ำหนักเบา แบบจำลอง Agile ได้ผลดีกว่าแบบจำลองแบบดั้งเดิม เพราะเพียงพอแก่การใช้งานโดยไม่จำเป็นต้องสมบูรณ์แบบ
agile modeling am1
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)
slide46
CMM (ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ)
  • วิศวกรรมซอฟต์แวร์ เป้าหมายสำคัญคือ การผลิตซอฟต์แวร์ให้มีคุณภาพ
  • คุณภาพ
    • ผลิตภัณฑ์
    • กระบวนการ ผลิตซอฟต์แวร์ที่เลือกใช้
  • จำเป็นต้องมีการปรับกระบวนการให้สอดคล้องกับเทคนิค ระเบียบวิธี หรือเครื่องมือชนิดใหม่เข้ามา

ประยุกต์ใช้

    • การปรับปรุงกระบวนการ (Process Improvement)
  • กลยุทธ์ในการปรับปรุงกระบวนการ
    • Total Quality Management (TQM)
    • Business Process Redesign (BPR)
    • Continuous Process Improvement (CPI)
    • Six Sigma
    • CMM
slide47
CMM(ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ)CMM(ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ)
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
    • SW-CMM (Software Capability Maturity Model)
    • คิดค้นโดย สถาบันวิศวกรรมซอฟต์แวร์ (Software EngineeringInstitute : SEI) แห่งมหาวิทยาลัยคาร์เนกีเมลอน ประเทศสหรัฐอเมริกา
    • มีวัตถุประสงค์เพื่อช่วยเหลือองค์กรหรือหน่วยงานผลิตซอฟต์แวร์ให้สามารถปรับปรุงการดำเนินงานได้อย่างมีระบบ มีความต่อเนื่อง
    • แบบจำลอง CMM มีลักษณะเป็นระดับชั้น เพื่อให้ทราบว่าองค์กรมีวุฒิภาวะของความสามารถเติบโตเต็มที่ (Capability Maturity)
slide48
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)

มีการปรับปรุงกระบวนการอย่างต่อเนื่อง

ระดับที่ 5 ดุลยภาพ

(Optimizing)

การบริหารการเปลี่ยนแปลง

ระดับที่ 4 การจัดการ

(Managed)

มีการควบคุมกระบวนการ

การบริหารเชิงปริมาณ

ระดับที่ 3 การกำหนดนิยาม

(Defined)

มีการพัฒนากระบวนการ

การบริหารวิศวกรรม

ระดับที่ 2 การกระทำซ้ำได้

(Repeatable)

มีสภาพแวดล้อมที่มั่นคง

การบริหารโครงการ

ระดับที่ 1 การเริ่มต้น

(Initial)

slide49
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
    • วุฒิภาวะระดับที่ 1 ระดับการเริ่มต้น (The initial Level)
      • องค์กรไม่มีความแน่นอนในการพัฒนาและการบำรุงรักษาซอฟต์แวร์
      • ปัญหาที่พบ การไม่บรรลุถึงข้อตกลงต่าง ๆ ที่ต้องปฏิบัติตามกระบวนการอย่างเป็นขั้นตอนที่ได้กำหนดไว้
      • การผลิตซอฟต์แวร์ในวุฒิภาวะระดับนี้จะต้องคำนึงถึงประสบการณ์และความสามารถของหัวหน้าและทีมงาน
slide50
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
    • วุฒิภาวะระดับที่ 2 ระดับการกระทำซ้ำได้ (The Repeatable Level)
      • องค์กรจะมีการกำหนดนโยบาย การจัดตั้งทีมงาน และการบริหารโครงการซอฟต์แวร์ เป็นไปอย่างมีแบบแผนและชัดเจน
      • การผลิตซอฟต์แวร์ในวุฒิภาวะระดับนี้จะต้องคำนึงถึงนโยบายและความมีระเบียบวินัยเป็นสำคัญ
      • มีการติดตามผลการทำงานตลอดเวลา โดยเฉพาะด้านต้นทุนและระยะเวลา
      • ความสำเร็จที่ได้จากการพัฒนาซอฟต์แวร์ของโครงการหนึ่ง จึงสามารถนำไปใช้ได้กับโครงการต่อไปในอนาคต (Repeatable)
slide51
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
    • วุฒิภาวะระดับที่ 3 ระดับการกำหนดนิยาม (The Defined Level)
      • ผลต่อเนื่องจากวุฒิภาวะระดับที่ 2
      • มุ่งเน้นการกำกับ ติดตาม และควบคุมกระบวนการต่าง ๆ ผ่านทางเอกสารที่ได้กำหนดนิยามไว้ในทุก ๆ ขั้นตอน (Documented and Integrated Process)
      • คำนึงถึงการจัดการด้านเอกสารประกอบการปฏิบัติงาน (Document Management) เป็นสำคัญ
slide52
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
    • วุฒิภาวะระดับที่ 4 ระดับการจัดการ (The Managed Level)
      • องค์กรมีการกำหนดมาตรฐาน (Standard) เพื่อใช้เป็นบรรทัดฐานในการประเมินกระบวนการ
      • กระบวนการผลิตซอฟต์แวร์ในวุฒิภาวะระดับนี้ จะต้องคำนึงถึงมาตรฐานและการปรับปรุงอย่างต่อเนื่องเป็นสำคัญ
slide53
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
    • วุฒิภาวะระดับที่ 5 ระดับดุลยภาพ (The Optimizing Level)
      • เป็นองค์กรแห่งการเรียนรู้ (Learning Organization)
      • มีความสามารถในการจัดสรรทรัพยากรได้อย่างคุ้มค่า และเหมาะสมที่สุด
      • มีเทคโนโลยี (Technology) และฐานองค์ความรู้ (Knowledge Based)
      • มีศักยภาพในการสร้างสรรค์นวัตกรรม (Innovation)
      • การผลิตซอฟต์แวร์ในวุฒิภาวะระดับนี้จะต้องคำนึงถึงความคิดสร้างสรรค์ในแง่ของนวัตกรรม และการจัดสรรทรัพยากรได้อย่างเหมาะสม
slide54
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
    • ในแต่ละระดับชั้นยังระบุถึง Key Process Area (KPA)
    • KPAหมายถึง กระบวนการสำคัญที่องค์กรจะต้องมีเมื่อดำเนินงานปรับปรุงคุณภาพของกระบวนการพัฒนาซอฟต์แวร์
slide55
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ

ตาราง แสดงคุณลักษณะและกระบวนการสำคัญของวุฒิภาวะความสามารถแต่ละระดับชั้นตามแบบจำลอง CMM

slide56
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ

ตาราง แสดงคุณลักษณะและกระบวนการสำคัญของวุฒิภาวะความสามารถแต่ละระดับชั้นตามแบบจำลอง CMM

slide57
ปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถปรับปรุงกระบวนการผลิตซอฟต์แวร์ด้วยแบบจำลองวุฒิภาวะความสามารถ
  • แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM)
    • กระบวนการหลักทุกด้าน (KPA) ของ CMM จะประกอบไปด้วยแนวทางเชิงปฏิบัติการ ได้แก่
      • เป้าหมาย
      • การยอมรับถึงความต้องการ
      • ขีดความสามารถ
      • กิจกรรม
      • วิธีการเฝ้าติดตาม
      • วิธีการตรวจสอบความถูกต้อง
slide59
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • เครื่องมือ (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
slide60
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • CASE Tools
    • CASE (Computer-Aided Software Engineering) หมายถึง ซอฟต์แวร์ที่เป็นเครื่องมือที่มีส่วนช่วยสนับสนุนการทำงานในกิจกรรมต่าง ๆ ของงานวิศวกรรมซอฟต์แวร์
    • ซอฟต์แวร์ที่เป็น CASE Tool จะต้องมีฟังก์ชันต่าง ๆ ให้ทีมงานได้เลือกใช้ เช่น
      • หน้าต่างออกแบบโปรแกรม (Design Editor)
      • พจนานุกรมข้อมูล (Data Dictionary)
      • คอมไพเลอร์ (Compiler)
      • ดีบักเกอร์ (Debugger)
slide61
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • CASE Tools
    • CASE ถือว่าเป็นเทคโนโลยีชนิดหนึ่งที่เพิ่มความสามารถให้กับซอฟต์แวร์
    • องค์ประกอบสำคัญของ CASE คือ Repository ซึ่งมีลักษณะเหมือนฐานข้อมูลที่ใช้จัดเก็บรายละเอียดต่าง ๆ ที่นักพัฒนาได้จัดทำขึ้น
    • ในยุคแรกของเทคโนโลยี CASE มีข้อจำกัดคือ ระบบการทำงานของ CASE มีลำดับกิจกรรมต่อเนื่องกันอัตโนมัติ แต่งานในทางวิศวกรรมซอฟต์แวร์เป็นไปในทางความคิดสร้างสรรค์
    • CASE ในยุคแรก ๆ ยังมีความสามารถไม่เพียงพอที่จะสนับสนุนการติดต่อระหว่างทีมงาน
slide62
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • ชนิดของ CASE
    • CASE Tool สามารถจำแนกได้หลายประเภท
      • จำแนกตามหน้าที่ของ CASE Tools (Functional Perspective)
      • จำแนกตามกระบวนการทำงาน (Process Perspective)
      • จำแนกตามการประสานเข้ากับ CASE Tools อื่น ๆ (Integration Perspective)
slide63
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • ชนิดของ CASE
    • จำแนกตามกระบวนการทำงาน ขั้นตอนต่าง ๆ แล้ว สามารถแบ่ง CASE Tools ออกเป็น 8 กลุ่ม ดังนี้
      • เครื่องมือสำหรับการวิเคราะห์ความต้องการ (Software Requirement Tool)
      • เครื่องมือออกแบบซอฟต์แวร์ (Software Design Tools)
      • เครื่องมือสร้างซอฟต์แวร์ (Software Construction Tools)
      • เครื่องมือทดสอบซอฟต์แวร์ (Software Testing Tools)
      • เครื่องมือบำรุงรักษาซอฟต์แวร์ (Software Maintenance Tools)
      • เครื่องมือจัดการโครงแบบ (Software Configuration Management Tools)
      • เครื่องมือบริหารงานวิศวกรรมซอฟต์แวร์ (Software Engineering Management Tools)

8. เครื่องมือคุณภาพซอฟต์แวร์ (Software Quality Tools)

slide64
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • ชนิดของ CASE

1. เครื่องมือสำหรับการวิเคราะห์ความต้องการ (Software Requirement Tool)

แบ่งออกเป็น 2 กลุ่ม ได้แก่

- เครื่องมือในการสร้างแบบจำลองความต้อง (Requirement Modeling Tools) เป็นเครื่องมือที่ใช้ในการดึงความต้องการ วิเคราะห์ กำหนด และตรวจสอบความต้องการด้านซอฟต์แวร์

- เครื่องมือการติดตามความต้องการ (Requirement Traceability Tools) เป็นเครื่องมือที่ใช้ติดตามความต้องการที่เปลี่ยนแปลงอยู่ตลอดเวลา

slide65
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • ชนิดของ CASE

2. เครื่องมือออกแบบซอฟต์แวร์ (Software Design Tools)

- เป็นเครื่องมือที่ใช้สร้างและตรวจสอบงานออกแบบซอฟต์แวร์

- ทำหน้าที่สนับสนุนการวิเคราะห์ความต้องการด้านซอฟต์แวร์ เช่น Rational Rose, EA เป็นต้น

3. เครื่องมือสร้างซอฟต์แวร์ (Software Construction Tools)

- เป็นกลุ่มเครื่องมือที่สนับสนุนงานในการสร้างซอฟแวร์ทั้งหมด ได้แก่

- เครื่องมือแก้ไขโปรแกรม (Program Editor)

- คอมไพเลอร์ (Compiler)

- อินเตอร์พรีเตอร์ (Interpreter)

- ดีบักเกอร์ (Debugger)

ตัวอย่างเช่น Eclipse, EditPlus, Windev, .NET Studio

slide66
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • ชนิดของ CASE

4. เครื่องมือทดสอบซอฟต์แวร์ (Software Testing Tools) ได้แก่

- เครื่องสร้างกรณีทดสอบ (Testing Generation) ใช้สร้างกรณีทดสอบซอฟต์แวร์

- กรอบการปฏิบัติการทดสอบ (Test Execution Framework) ใช้ทดสอบซอฟต์แวร์ภายใต้สภาพแวดล้อมที่มีการกำหนดไว้ล่วงหน้า

- เครื่องมือประเมินผลการทดสอบ (Test Evaluation Tools) ใช้สนับสนุนการประเมินผลการทดสอบ ว่าผลการทดสอบเป็นตามคาดหวังหรือไม่

- เครื่องมือบริหารงานทดสอบ (Test Management Tools) เป็นเครื่องมือที่สนับสนุนทุกกิจกรรมการทดสอบ

- เครื่องมือวิเคราะห์ประสิทธิภาพซอฟต์แวร์ (Performance Analysis Tool) เป็นเครื่องมือที่ใช้วัดผลและวิเคราะห์ประสิทธิภาพการทำงานของซอฟต์แวร์

slide67
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • ชนิดของ CASE

5. เครื่องมือบำรุงรักษาซอฟต์แวร์ (Software Maintenance Tools)

เป็นเครื่องมือที่ใช้บำรุงรักษาซอฟต์แวร์ที่มีอยู่แล้ว ให้คงสภาพที่ใช้การได้อย่างดี แบ่งเป็น 2 กลุ่ม ได้แก่

1. เครื่องมือสร้างความเข้าใจ (Comprehension Tools) เป็นเครื่องมือที่ช่วยให้ทีมซ่อมบำรุงทำความเข้าใจกับโปรแกรมของซอฟต์แวร์ได้ง่ายขึ้น

2. เครื่องมือรื้อปรับระบบใหม่ (Reengineering Tools) เป็นเครื่องมือที่ช่วยในกระบวนการรื้อโครงสร้างของซอฟต์แวร์ทีละส่วน เพื่อนำมาปรับหรือแก้ไขให้มีสภาพสมบูรณ์เหมือนเดิม

6. เครื่องมือจัดการโครงแบบ (Software Configuration Management Tools)

เป็นเครื่องมือที่ใช้ติดตามการเปลี่ยนแปลงของทุกองค์ประกอบของซอฟต์แวร์

จัดการรุ่นของซอฟแวร์ และการวางจำหน่ายของซอฟต์แวร์

slide68
เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือที่ใช้ในการวิศวกรรมซอฟต์แวร์
  • ชนิดของ CASE

7. เครื่องมือบริหารงานวิศวกรรมซอฟต์แวร์ (Software Engineering Management Tools) ได้แก่

- เครื่องมือวางแผนและติดตามโครงการ (Project Planning and Tracking) ได้แก่ ซอฟต์แวร์ที่ใช้ในการประมาณการแรงงาน และต้นทุน พร้อมทั้งจัดตารางงาน

- เครื่องมือจัดการความเสี่ยง (Risk Management) ได้แก่ ซอฟต์แวร์ที่ใช้ระบุปัจจัยเสี่ยง ประมาณการผลกระทบ และติดตามความเสี่ยง

- เครื่องมือวัดผลโครงการ (Measurement) ได้แก่ ซอฟต์แวร์ที่ใช้ในการวัดผลทุกกิจกรรมของโครงการ

8. เครื่องมือคุณภาพซอฟต์แวร์ (Software Quality Tools)

- เครื่องมือตรวจสอบคุณภาพ (Inspection Tools) ได้แก่ เครื่องมือที่ใช้ทบทวนและตรวจสอบคุณภาพของซอฟต์แวร์

- เครื่องมือวิเคราะห์คุณภาพ (Static Analysis Tools) ได้แก่ เครื่องมือที่ใช้วิเคราะห์คุณลักษณะด้านต่าง ๆ ของ ซอฟต์แวร์ เช่น วิเคราะห์ Control Flow และโครงสร้างข้อมูล เป็นต้น

slide69
เครื่องมือและระเบียบวิธีที่ใช้ในการวิศวกรรมซอฟต์แวร์เครื่องมือและระเบียบวิธีที่ใช้ในการวิศวกรรมซอฟต์แวร์

ประเด็นอื่น ๆ ที่เกี่ยวข้องกับ CASE Tools

Integrated CASE Environment

- เป็น CASE Tool ที่ประกอบไปด้วยฟังก์ชันการทำงานที่ครอบคลุมงานทุกด้านของวิศวกรรมซอฟต์แวร์

- ประสานการทำงานเข้ากับ CASE Tool สำหรับขั้นตอนพื้นฐานของการพัฒนาซอฟต์แวร์

Meta Tools

- เป็นเครื่องมือที่ใช้สร้างเครื่องมือ เช่น Editor ใช้สร้างโปรแกรมที่เป็นคอมไพเลอร์ เป็นต้น

slide70
ระเบียบวิธีที่ใช้ในการวิศวกรรมซอฟต์แวร์ระเบียบวิธีที่ใช้ในการวิศวกรรมซอฟต์แวร์

ระเบียบวิธี (Methodologies)

- ระเบียบวิธี หรือ กรรมวิธี ในการปฏิบัติงานวิศวกรรมซอฟต์แวร์ จะกำหนดนิยามของกิจกรรมต่าง ๆ ขั้นตอนการดำเนินกิจกรรม และข้อแนะนำการตรวจสอบการทำงาน

- ระเบียบวิธีปฏิบัติงานวิศวกรรมซอฟต์แวร์ ได้แก่

1. วิธีเชิงโครงสร้าง (Structured Approach)

2. วิธีเชิงวัตถุ (Object – oriented Approach)

3. Heuristic Methodology

4. Formal Methodology

slide71
ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์

1. แนวทางเชิงโครงสร้าง (Structured Approach)

  • แบ่งระบบและความต้องการออกเป็นระบบย่อย (Sub-System)
  • ลักษณะของระบบจึงเป็นโครงสร้างแบบลำดับชั้น
  • ระเบียบวิธีปฏิบัติชนิดหนึ่งที่นิยมนำมาใช้ในขั้นตอนการวิเคราะห์และออกแบบระบบ คือ “การวิเคราะห์และออกแบบระบบเชิงโครงสร้าง (Structured System Analysis and Design: SSAD)” คิดค้นโดย Yourdan & Demarco ปี ค.ศ. 1978
slide72
ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์

1. แนวทางเชิงโครงสร้าง (Structured Approach)

  • ข้อเสีย
    • ต้องวิเคราะห์และออกแบบข้อมูลรวมถึงพฤติกรรมของระบบแยกกันคนละส่วน ทำให้ต้องใช้เวลานาน
    • ใช้ต้นทุนมากเกินไป
    • เสี่ยงต่อการเปลี่ยนแปลงความต้องการของผู้ใช้
slide73
ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์

ตัวอย่างการวิเคราะห์และออกแบบระบบเชิงโครงสร้าง

แสดงตัวอย่างการวิเคราะห์และออกแบบระบบเชิงโครงสร้าง

ระบบวางบิล

ตรวจสอบการจัดส่งสินค้า

จัดทำใบส่งสินค้า

ตรวจสอบสถานะการสั่งซื้อ

ปรับปรุงสถานะคลังสินค้า

จัดทำรายการยอดขาย

ปรับปรุงยอดสั่งซื้อ

จัดทำภาษีซื้อ - ขาย

แก้ไขสถานะวิเคราะห์การขาย

จัดทำใบวางบิล

slide74
ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์

2. แนวทางเชิงวัตถุ (Object – Oriented Approach)

  • คิดค้นโดย Grady Booch, James Rumbaughและ Ivar Jacobson
  • การวิเคราะห์และออกแบบระบบเชิงวัตถุ (Object-Oriented System

Analysis and Design)

  • เป็นการวิเคราะห์ระบบโดยการมองทุกอย่างในระบบเป็นอ็อบเจ็กต์ (Object)
slide75
ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์

2. แนวทางเชิงวัตถุ (Object – Oriented Approach)

  • ข้อดี
    • การวิเคราะห์และออกแบบระบบรวดเร็ว
    • รองรับกับระบบงานที่มีความซับซ้อนสูง
    • ทันต่อการเปลี่ยนแปลงความต้องการของผู้ใช้
slide76
ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์

ตัวอย่างอ็อบเจ็กต์

แสดงตัวอย่างอ็อบเจ็กต์

object

Invoice

ID

No.

Address

A/C No.

Amount

Computer value of goods

Computer discount

Computer Ad. Charge

Computer Invoice Amount

Attributes

Methods

slide77
ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์

3. Heuristic Methodology

- เป็นระเบียบวิธีที่ไม่เป็นแบบแผน (Informal Method)

- ไม่มีการนำวิธีการทางคณิตศาสตร์เข้าไปใช้ในขั้นตอนต่าง ๆ

- Methodology

- Structured Methodology/Approach มุ่งเน้นที่หน้าที่การทำงานของ

โปรแกรม

- Object-oriented Methodology พิจารณาทั้งข้อมูลและหน้าที่การทำงานไป พร้อม ๆ กัน

- Data-oriented Methodology เป็นวิธีการที่มุ่งเน้นที่ข้อมูลที่โปรแกรมจะต้องเข้าไปดำเนินการ

slide78
ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์ระเบียบวิธีปฏิบัติของวิศวกรรมซอฟต์แวร์

4. Formal Methodology

- เป็นระเบียบวิธีอาศัยวิธีการทางคณิตศาสตร์เป็นพื้นฐานการทำงาน 2 ชนิดได้

1. การระบุข้อกำหนดอย่างมีแบบแผน (Formal Specification) เป็นวิธีการอธิบายข้อกำหนดด้วยภาษาชนิดใดชนิดหนึ่ง เช่น พีชคณิต และแบบจำลองทางคณิตศาสตร์

2. การทวนสอบอย่างมีแบบแผน (Formal Verification) เป็นวิธีการทวนสอบโดยใช้การพิสูจน์ทางตรรกะ ช่วยให้การทวนสอบซอฟต์แวร์มีประสิทธิภาพมากขึ้น

slide79
สรุป

- Agileเน้น 4 เรื่อง หลัก ๆ คือ ความสำคัญของทีมจัดระเบียบตนเองที่ควบคุมงานที่ตนทำอยู่ การสื่อสารและความร่วมมือระหว่างสมาชิกในทีม ผู้ปฏิบัติงานและลูกค้า การระลึกไว้ว่าการเปลี่ยนแปลงเป็นตัวแทนของโอกาสดี ๆ และการเน้นการส่งมอบซอฟต์แวร์ที่ทำให้ลูกค้าพอใจอย่างรวดเร็ว

- Extreme Programming (XP) เป็นกระบวนการ Agile ที่ใช้กันมากที่สุด ได้จัดระเบียบกิจกรรมกรอบงานไว้ 4 อย่าง คือ

- การวางแผน

- การออกแบบ

- การเขียนโค้ด

- การทดสอบ

slide80
สรุป
  • Adaptive Software Development (ASD)
    • เน้นความร่วมมือของมนุษย์และทีมจัดระเบียบตนเอง
    • กำหนดกรอบงาน 3 อย่าง คือ การคาดเดา การร่วมมือ การเรียนรู้
    • ASD ใช้กระบวนการวนซ้ำที่รวมหลักการวางแผนวงจรการปรับตัว วิธีรวบรวมความต้องการอย่างกระตือรือร้น และวงจรการพัฒนาแบบทำวนซ้ำที่มีการประชุมร่วมกับกลุ่มลูกค้าเป้าหมาย และใช้การตรวจทานด้านเทคนิคอย่างเป็นทางการ
    • เป็นกลไกในการตอบสนองย้อนกลับในเวลาจริง
slide81
สรุป
  • Dynamic Systems Development Method (DSDM)
    • นิยามวงจรวนซ้ำ
      • การวนซ้ำการจำลองเชิงหน้าที่ การวนซ้ำการออกแบบและการสร้าง และการอินพีลเม้นต์
      • นำหน้าด้วยวงจรเพิ่มเติมสองกิจกรรม คือการศึกษาความเป็นไปได้ และการศึกษาด้านธุรกิจ
      • DSDM จัดตารางงานโดยใช้กล่องเวลา และแนะนำให้ทำงานเพียงแค่พอเท่าที่จำเป็นสำหรับแต่ละรุ่นของซอฟต์แวร์ เพื่อให้ความสะดวกแก่การเคลื่อนไปสู่รุ่นถัดไป
slide82
สรุป
  • Scrum (สครัม)
    • เน้นการใช้ชุดแบบรูปกระบวนการซอฟต์แวร์ที่ได้ผลมาแล้ว สำหรับโครงการที่มีเวลาจำกัด มีการเปลี่ยนแปลงความต้องการ และมีความสำคัญยิ่งยวดทางธุรกิจ
  • Crystal (คริสตัล)
    • เป็นกลุ่มครอบครัวของแบบจำลองกระบวนการ Agile ที่สามารถปรับตัวเข้ากัน ลักษณะเฉพาะตัวโครงการต่าง ๆ
    • คริสตัลใช้กลยุทธ์การทำวนซ้ำ แต่ปรับความเข้มข้นของกระบวนการ ให้รองรับโครงการที่มีขนาดและความซับซ้อนระดับต่าง ๆ กัน
slide83
สรุป
  • Feature Driven Development (FDD)

- เป็นวิธี Agile ที่ค่อนข้างเป็นทางการกว่าวิธีการอื่น ๆ

- แต่ยังคงความคล่องตัว

    • เน้นความสนใจของทีมพัฒนาไปที่คุณลักษณะของซอฟต์แวร์ ที่นิยามไว้เป็นหน้าที่การทำงานอันมีคุณค่าแก่ลูกค้า ที่สามารถอินพลีเม้นต์ให้เสร็จได้ภายในเวลาสองสัปดาห์หรือน้อยกว่า
    • FDD ให้ความสำคัญแก่การบริหารโครงการมากว่าวิธีอื่น ๆ
  • Agile Modeling (AM)
    • แบบจำลองจำเป็นสำหรับทุกระบบ
    • แต่ขนาด ประเภท และความซับซ้อนของแบบจำลอง ต้องปรับเข้ากับซอฟต์แวร์ที่จะสร้าง
slide84
สรุป

- การผลิตซอฟต์แวร์จำเป็นต้องดำเนินการในรูปแบบของ กระบวนการ (Process)

- กระบวนการที่ประกอบไปด้วยกลุ่มกิจกรรมที่สัมพันธ์กันในการผลิตซอฟต์แวร์ให้ได้คุณภาพ เรียกว่า Software Process หรือ Software Development Process

- เพื่อให้ผลิตภัณฑ์ซอฟต์แวร์มีคุณภาพ ต้องนำหลักการวิศวกรรมซอฟต์แวร์เข้ามาดูแลกระบวนการผลิตซอฟต์แวร์

- กระบวนการวิศวกรรมซอฟต์แวร์ (Software Engineering Process) มีกระบวนการผลิตซอฟต์แวร์เป็นพื้นฐานสำคัญ

- แบบจำลองกระบวนการผลิตซอฟต์แวร์ (Software Process Model) เป็นสิ่งที่ช่วยให้เห็นภาพของการกระบวนการผลิตซอฟต์แวร์ได้ชัดเจนที่สุด

slide85
สรุป

- สิ่งที่เป็นหน้าที่สำคัญของวิศวกรซอฟต์แวร์ คือ การปรับปรุงกระบวนการผลิต (Process Improvement) เพื่อตอบสนองต่อแนวคิดประสิทธิภาพของกระบวนการ

- สถาบันวิศวกรรมแห่งสหรัฐอเมริกา (SEI) ได้พัฒนา แบบจำลองวุฒิภาวะความสามารถ (Capability Maturity Model : CMM) เพื่อใช้วัดระดับวุฒิภาวะความสามารถของกระบวนการผลิตของแต่ละองค์กร เพื่อปรับปรุงไปสู่วุฒิภาวะในระดับสูงขึ้น