ดาวน์โหลดงานนำเสนอ
งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ
1
Software Evolution แบบจำลองกระบวนการพัฒนา/ผลิตซอฟต์แวร์ (Process Model) แบบจำลองใช้สำหรับชี้นำถึงกิจกรรมหลัก (key Activities) ในการพัฒนาซอฟต์แวร์ ด้วยการกำหนดรายละเอียดหรือข้อบัญญัติไว้ในแต่ละกิจกรรมในแต่ละขั้นตอนที่มีลำดับขั้นตอนการพัฒนาที่ชัดเจน เพื่อต้องการให้การพัฒนาซอฟต์แวร์ดำเนินต่อไปโดยเกิดปัญหาน้อยที่สุด ปัจจุบันมีการคิดค้นแบบจำลองต่าง ๆ ให้เลือกใช้งานมากมาย ส่วนการตัดสินใจว่าจะเลือกใช้แบบจำลองใดขึ้นอยู่กับปัจจัยหลายอย่าง เช่น ขนาดของโครงการ ความเหมาะสม และระดับความเสี่ยง เป็นต้น สาเหตุสำคัญที่จำเป็นต้องใช้แบบจำลองการพัฒนาซอฟต์แวร์ เพราะ แบบจำลองพัฒนาซอฟต์แวร์จะมีการแตกขั้นตอนของกระบวนการพัฒนาในแต่ละเฟส (phase) ซอฟต์แวร์ที่พัฒนามีความซับซ้อน การแบ่งเป็นกระบวนการพัฒนาเป็นเฟสหรือระยะ จะทำให้ง่ายต่อการจัดการ แต่ละเฟสมีแนวทางต่าง ๆ ให้เลือกปฏิบัติ
2
Process Model แบบจำลองพัฒนาซอฟต์แวร์ที่สำคัญ
แบบจำลองมักผนวกกระบวนการในลักษณะ การทวนซ้ำเป็นรอบ (Iteration) การพัฒนาแบบก้าวหน้า (Incremental) และการจัดทำต้นแบบ (Prototyping) ซึ่งเป็นกระบวนการลดความเสี่ยงในกรณีซอฟต์แวร์มีการเปลี่ยนแปลงในความต้องการอยู่ตลอดเวลา แบบจำลองที่สำคัญและนิยมนำมาใช้ในการพัฒนาได้แก่ - Waterfall Model : แบบจำลองน้ำตก - Incremental Model : แบบจำลองค่อยๆ สร้างเพิ่ม - RAD Model : แบบจำลองอาร์เอดี - Prototype Model : แบบจำลองต้นแบบ - Spiral Model : แบบจำลองวนก้นหอย/เวียนวน - Agile Model
3
Waterfall Model
4
Incremental Model
5
RAD Model
6
Software Evolution แบบจำลองกระบวนการเชิงวิวัฒน์
(Evolutionary Process Model) ซอฟต์แวร์จะมีวิวัฒนาการตามกาลเวลาที่ผ่านไป ความต้องการผลิตภัณฑ์และธุรกิจมักเปลี่ยนแปลงไปเพื่อพัฒนาก้าวหน้าขึ้น ดังนั้นเมื่อการพัฒนาไม่สอดคล้องกับการตลาดจึงทำให้เกิดซอฟต์แวร์ที่ไม่สมบูรณ์ 100% แต่มักจะออกเวอร์ชั่นที่ทำงานอย่างจำกัดออกมาก่อน และขยายการทำงานต่อไปเรื่อย ๆ ซอฟต์แวร์เวอร์ชั่นหลัง ๆ จะมีความสมบูรณ์เพิ่มมากขิ้น แบบจำลองต้นแบบ (Prototyping Model) แบบจำลองสไปรัล (Spiral Model)
7
Software Evolution แบบจำลองต้นแบบ (Prototyping Model)
Communi- cation Quick plan Deployment delivery & Feedback Modeling Quick design Construction of prototype - step 1: Requirements gathering step 2: A “quick design” -> focuses on visible functions and behaviors of the product - step 3: Prototype construction - step 4: Customer evaluation of the prototype loop back step 1. บ่อยครั้งที่ลูกค้ามักบอกเป้าหมายทั่วไปของซอฟต์แวร์โดยไม่ระบุรายละเอียดด้าน Input-Process-Output ที่ต้องการ ซึ่งทำให้ผู้พัฒนาไม่มั่นใจในการเลือกใช้อัลกอริทึ่มหรือโครงการ ดังนั้นวิธีการที่ดีที่สุดคือการสร้างต้นแบบเพื่อช่วยให้นักวิศวกรและลูกค้าได้เข้าใจกันดียิ่งขึ้น
8
Software Evolution แบบจำลองสไปรัล (Spiral Model)
แบบจำลองสไปรัลเกิดจากการวิจัยของ Barry Boehm (1988) เป็นแบบจำลองที่รวมลักษณะการ วนซ้ำของการสร้างต้นแบบกับการทำงานอย่างเป็นขั้นตอน และมีการควบคุมของแบบจำลองน้ำตก เข้าด้วยกัน วิธีการพัฒนาแบบ "วนเวียน" (spiral model) นี้จะวนเวียนอยู่ระหว่างงาน 4 ขั้นตอน 1. การวิเคราะห์ความต้องการ (Requirement Analysis) 2. การวิเคราะห์ความเสี่ยง (Risk Analysis) 3. การออกแบบต้นแบบ (Design Prototype) 4. การพัฒนาต้นแบบและนำมาประกอบรวมกัน (Develop and Integrate Prototype) วิธีนี้จะเน้นเรื่องการวิเคราะห์ความเสี่ยงในช่วงที่ 2 ซึ่งการวิเคราะห์ความเสี่ยง (risk-analysis) เป็นการวิเคราะห์ว่า ในการพัฒนาซอฟต์แวร์มีปัญหาอะไรบ้าง แต่ละปัญหาอาจส่งผลกระทบรุนแรงในระดับใด และมีโอกาสเกิดขึ้นได้มากเพียงใด แล้วรีบจัดการกับปัญหาที่มีโอกาสเกิดขึ้น และมีผลกระทบสูงก่อน ปัญหาดังกล่าวไม่จำเป็นว่าจะต้องเป็นปัญหาทางด้านเทคนิค แต่อาจจะเป็นปัญหาในการบริหารงานโครงการ ปัญหาเรื่องคน ฯลฯ เพื่อให้โครงการประสบความสำเร็จได้มากขึ้น ตัวอย่างเช่น หัวหน้าโครงการกำลังคิดจะลาอออก ซึ่งถ้าลาออกจริง โครงการก็จะล้มเหลว การเจรจากับหัวหน้าโครงการจึงเป็นเรื่องเร่งด่วนกว่าเรื่องเทคนิคทั้งหมด
9
Software Evolution แบบจำลองสไปรัล (Spiral Model) Liaison : การติดต่อ
10
Software Evolution สรุปแบบจำลองกระบวนการเชิงวิวัฒน์
จุดอ่อนของแบบจำลองกลุ่มนี้ การพัฒนาซอฟต์แวร์ตามแบบกระบวนการนี้ สร้างปัญหาในการวางแผนโครงการ เพราะความไม่แน่นอนของจำนวนการทำซ้ำ เพราะผู้บริหารที่วางแผนโครงการมักมองเวลาในลักษณะเชิงเส้น เริ่มเมื่อไหร่ สิ้นสุดเมื่อไหร่ จึงมักขัดแย้งกัน กระบวนการนี้ไม่ได้กำหนดความเร็วของวิวัฒนาการซอฟต์แวร์ ถ้าวิวัฒนาการของซอฟต์แวร์เกิดขึ้นเร็วโดยไม่มีช่วงพัก กระบวนการจะยุ่งเหยิง สับสน โดยเฉพาะผู้ใช้งาน แต่ถ้าเกิดขึ้นช้าก็จะกระทบกับความสามารถในการผลิต โดยเฉพาะทีมพัฒนา กระบวนการนี้ควรเน้นที่ความยืดหยุ่น และความสามารถในการขยายตัวมากกว่าคุณภาพที่สูง ดังคำกล่าวที่ว่า “เราควรให้ความสำคัญกับการพัฒนาให้เสร็จทันเวลาก่อนที่โอกาสทางการตลาดจะหมดไป มากกว่า ไปพัฒนาซอฟต์แวร์ที่ไม่มีจุดบกพร่องเลย”
11
Software Evolution แนวคิดใหม่เกิดจากแนวคิดที่ว่าในระหว่างทำการพัฒนาระบบอยู่นั้น ความต้องการ ของซอฟต์แวร์มักจะปรับเปลี่ยนอยู่เสมอ ดังนั้นแบบจำลองแบบน้ำตกที่มองว่าการกำหนดความต้องการระบบเป็นจุดเริ่มต้นการทำงาน การพัฒนาซอฟต์แวร์ในขั้นตอนต่อไปอาจไม่สามารถทำได้ เนื่องจากความต้องการที่เปลี่ยนแปลงไป อีกทั้งปัญหาที่เกิดจากการสื่อสารที่ไม่ครบถ้วนหรือปัจจัยภายนอก เช่นเทคโนโลยีที่เปลี่ยนไป ปัจจัยทางธุรกิจ ดังนั้นกระบวนการพัฒนาหรือวงจรชีวิตซอฟต์แวร์ที่ดีควรมีแนวคิดของการเปลี่ยนแปลงความต้องการ มาเป็นส่วนหนึ่งในการกำหนดขั้นตอนกระบวนการในการพัฒนาซอฟต์แวร์
12
Software Evolution Agile คืออะไร
หลักการทางวิศวกรรมซอฟต์แวร์ที่รวมเอาแนวทางพัฒนาเข้าด้วยกัน เพื่อมุ่งสร้างความพึงพอใจให้กับลูกค้าและสามารถส่งมอบซอฟต์แวร์แบบค่อยเพิ่มขึ้นแก่ลูกค้า โดยใช้ทีมงานขนาดเล็กที่กระตือรือร้น ใช้วิธีการแบบไม่เป็นทางการผลิตงานด้านวิศวกรรมซอฟต์แวร์ถ้าจำเป็น และใช้วิธีการแบบเรียบง่าย ส่วนแนวทางการพัฒนาเน้น การส่งมอบมากกว่าการวิเคราะห์ออกแบบ และการสื่อสารอย่างต่อเนื่องกับลูกค้า
13
Software Evolution แนวคิดสำคัญของ Agile
ไม่เน้นกระบวนการและเอกสาร ให้เน้นไปที่การพัฒนาให้ดีที่สุดมากกว่าจะยึดติดกับเอกสารต่างๆ (ไม่ใช่ว่าไม่จำเป็นแต่ให้ความสำคัญน้อยกว่า) คือต่อให้มีเอกสารยืนยันแล้วว่าจะทำอะไร แต่มีอีกทางที่ส่งมอบ Value ให้กับลุกค้าได้ดีกว่า Agile จะเลือกทางนั้น ไม่ใช่ทางเอกสาร ยอมรับความเปลี่ยนแปลง เพราะ requirement อาจเปลี่ยนแปลงได้ตลอด แนวคิดแบบ Agile จะไม่ฟูมฟายกับการเปลี่ยนแปลง ไม่มีการทำงานหรือยึดติดกับ Gantt Chart แต่จะทำงานแบบ ค่อนข้าง Flexible ตามสิ่งที่เกิดขึ้นจริงเป็นหลัก สามารถเปลี่ยนแปลงได้ตลอดเวลา ทำทีละนิดแต่ทำบ่อยๆ คือมีการส่งมอบงานอะไรบางอย่างให้ทีมหรือลูกค้าอย่าต่อเนื่องทีละเล็กทีละน้อย เช่นส่งมอบอะไรใหม่ทุกๆ 2 อาทิตย์หรือทุกๆ เดือน จะไม่ให้ลูกค้ามีการรอ 3-6 เดือนเพื่อรอโปรเจ็คต์ใหญ่เสร็จแล้วค่อยส่งมอบทีเดียว
14
Software Evolution แนวคิดสำคัญ (ต่อ)
ผิดพลาดให้เร็ว คือไม่กลัวที่จะลงมือทำเพื่อที่จะเจอกับความผิดพลาดและแก้ไขไปทีละนิด จะไม่ใช่การวางแผนโดยละเอียดเพื่อป้องกันความผิดพลาด แต่พอเจอสิ่งที่ผิดไปจากแผนจริงๆ (เพราะอย่างที่รู้ว่าน้อยครั้งนักที่เราจะทำตามแผนได้ทั้งหมด) ก็อยู่ในภาวะที่เป็น Point of No Return ไปแล้ว ทำงานเป็นทีมมากกว่าที่จะสนใจกระบวนการ คือเน้นที่การมีปฏิสัมพันธ์ระหว่างบุคคลมากกว่าที่บอกว่าต้องเป็นไปตามกระบวนการ มีปัญหาอะไรให้พูดคุยกับทีมเลยทันที บางครั้งอาจถึงขั้นเอา Programmer ไปเจอลูกค้าเพื่อให้เข้าใจ requirement ที่แท้จริงด้วย ให้ลูกค้าเข้ามามีส่วนร่วมตั้งแต่เริ่มกระบวนการ ซึ่งทีมมักจะประกอบด้วยหลายๆ ตำแหน่ง และมีอำนาจมากพอที่จะตัดสินใจทำหรือไม่ทำอะไรเพื่อ Drive ให้งานที่ทีมรับผิดชอบสำเร็จตามเป้าหมาย
15
Software Evolution ข้อดีที่เห็นได้ชัด ข้อดีของการทำงานในแนวคิด Agile หลักๆ คือการไม่มีกำแพงระหว่างฝ่าย เพราะเอาทุกฝ่ายมาอยู่ในทีมเดียวกัน เน้นที่การสื่อสารระหว่างบุคคล ทำให้ลดความไม่เข้าใจลงไป และสามารถแก้ปัญหาได้รวดเร็วๆ (สมมติว่า Test แล้วมีปัญหา ก็สามารถบอกกับ Designer หรือ Programmer ให้แก้ไขได้ทันที โดยไม่ต้องส่งเรื่องข้ามฝ่าย) รวมถึงการที่ค่อยๆ ส่งมอบงานทีละนิดทำให้มีความยืดหยุ่นในการทำงานสูง
16
Software Evolution
17
Software Evolution
18
เทคนิคการพัฒนาแบบ Agile
Agile model driven development (AMDD) Code Refactor : เป็นการ redesign code คือให้แก้ code เพื่อให้มีโครงสร้างที่ เข้าใจได้ง่ายขึ้น Pair Programming : จับทีมทำงานเป็นคู่ 2 คนทำงานร่วมกัน ทำที่เดียวกัน ให้เครื่อง เดียว 2 คน,แชร์กันใช้,คนนึงทำ-คนนึงดู (มีการตรวจสอบกันไปด้วย) Test Driven Development(TDD) : เป็นเทคนิคในการเขียน Test case เขียน test case ก่อนและค่อยทำการ implement code ตัวอย่างการเขียน
19
Methodologies Agile Scrum
20
Scrum สครัมมาจากกิจกรรมในการแข่งขันรักบี้ เป็นกระบวนการอาไจลที่พัฒนาโดย Jeff Sutherland และทีมงาน เมื่อต้นทศวรรษ 1990 หลักการของสครัมมีดังต่อไปนี้ (1) จัดตั้งทีมทำงานขนาดเล็กที่ “เกิดการสื่อสาร การแบ่งปันเทคนิค และข่าวสารที่ไม่เป็นทางการให้มากที่สุด ขณะที่ลดค่าใช้จ่ายส่วนเกินให้น้อยที่สุด” (2) กระบวนการต้องสามารถปรับเข้ากับการเปลี่ยนแปลงทางธุรกิจและเทคนิคได้ เพื่อผลิตผลงานให้ดีที่สุด (3) กระบวนการต้องผลิตรุ่นซอฟต์แวร์ออกมาบ่อย ๆ เพื่อตรวจสอบ ปรับแต่ง ทดสอบ บันทึกและต่อยอดได้ (4) งานที่พัฒนาและนักพัฒนาจะแบ่งออกเป็นแพ็คเก็ตหรือพาร์ติดชั่นที่สุดและขึ้นแก่กันน้อยที่สุด (5) มีการทดสอบและบันทึกเอกสารอย่างสม่ำเสมอขณะสร้างผลิตภัณฑ์ (6) กระบวนการสครัมจะต้อง “สามารถแจ้งว่า พัฒนาผลิตภัณฑ์เสร็จแล้ว” เมื่อใดก็ตามที่ต้องการ (มีการแข่งขันสูง/บ.ต้องการเงิน/ลูกค้าต้องการใช้งาน)
21
Scrum หลักการสครัมใช้นำทางกิจกรรมพัฒนา ภายใต้กระบวนการที่รวมเอากิจกรรมกรอบงานต่อไปนี้ คือ ความต้องการ การวิเคราะห์ การออกแบบ การวิวัฒน์ และการส่งมอบ ที่พิสูจน์แล้วว่าได้รับผลดี สำหรับโครงการที่มีเวลาจำกัด มีการเปลี่ยนแปลงความต้องการ และมีความสำคัญอย่างยิ่งยวดต่อธุรกิจ แบบรูปกระบวนการแต่ละแบบนิยามชุดกิจกรรมพัฒนาระบบต่อไปนี้ - แบ็คล๊อก (Backlog) รายการความต้องการหรือลักษณะที่ให้คุณค่าทางธุรกิจแก่ ลูกค้าที่เรียงลำดับความสำคัญแล้ว รายการอาจเพิ่มเข้ามาใหม่ได้ โดยผู้จัดการต้อง ประเมินและปรับปรุงลำดับความสำคัญตามความเหมาะสม - สปริ้น (Sprints) ประกอบด้วยหน่วยของงาน ต้องทำให้เสร็จตามความต้องการที่ นิยามโดยแบ็คล๊อก โดยหน่วยของงานหนึ่ง ๆ ต้องทำให้เสร็จได้จริงตามกรอบ เวลาที่กำหนดไว้แล้วล่วงหน้า (ปกติ 30 วัน) ระหว่างสปริ้น รายการแบ็คล็อกใดที่ กำหนดสปริ้นอยู่จะถูกหยุดการเปลี่ยนแปลงไว้ก่อน
22
Scrum - การพบปะของสครัม (Scrum meeting) การประชุมสั้น ๆ ประมาณ 15 นาที
ของทีมสครัมจะมีทุก ๆ วัน เพื่อถามและตอบคำถามสามข้อ คือ (1) คุณได้ทำอะไรไปแล้วหลังจากการประชุมครั้งที่แล้ว (2) มีอุปสรรคอะไรหรือไม่ที่พบ (3) คุณวางแผนจะทำอะไรให้เสร็จก่อนการประชุมคราวหน้า หัวหน้าทีมสครัม (Scrum Master) จะนำการประชุมและประเมินการตอบสนอง ของแต่ละบุคคล การประชุมสครัมช่วยให้ทีมค้นพบปัญหาเร็วที่สุดเท่าที่จะทำได้ นอกจากนี้ยังเป็นการสังสรรค์เชิงความรู้ และช่วยก่อให้เกิดโครงสร้างทีมจัด ระเบียบตนเองได้ด้วย - สาธิต (Demos) และตรวจสอบ (Review) ส่งมอบรุ่นซอฟต์แวร์แก่ลูกค้าเพื่อ สาธิตและประเมินหน้าที่การทำงานที่ได้พัฒนาแล้ว การสาธิตไม่จำเป็นต้องมี หน้าที่ครบถ้วนตามแผนที่วางไว้ แต่ต้องมีหน้าที่ที่ส่งมอบได้ภายในกรอบเวลาที่ กำหนด
23
Software Evolution
24
Software Evolution ตำแหน่งที่สำคัญ
Product Owner : มีหน้าที่ประเมิน Values และจัด Priorities ของ Tasks ต่างๆ ให้กับทีม Scrum Master : เป็นผู้ทำให้การทำงานเป็นไปอย่างลื่นไหล ซึ่งไม่ได้หมายถึงการเป็นผู้นำทีม แต่จะคอยกำจัดอุปสรรคที่ขัดขวางไม่ให้ทีมบรรลุเป้าหมาย Team : จะทำงานแบบ Self-Management ซึ่งในหนึ่งทีมจะประกอบด้วยคนประมาณ 3-9 คน และรวมทุกตำแหน่งทั้ง Designer, Programmer, UI/UX, Testing เข้าด้วยกัน เพื่อให้ทีมหนึ่งทีมสามารถทำงานตั้งแต่ต้นจนจบได้ด้วยตัวเอง โดยไม่ต้องข้ามแผนก
25
Product Owner ลูกค้า ผู้กำหนดขอบเขตการทำงานของระบบที่ทีมจะพัฒนา คิด รวบรวม เผยแพร่ให้ทุกคนได้เห็น ผู้เขียนรายละเอียดและความต้องการของผู้ใช้ ที่สำคัญ เป็นผู้ที่ต้องการผลลัพธ์ที่มีประสิทธิภาพ บางครั้งยังถือเป็นสมาชิกคนหนึ่งใน Scrum Team
26
Scrum Master ผู้อำนวยความสะดวกให้สมาชิกในทีม ดูแลทีม เป็นโค้ชของทีม ก็เปรียบเป็นหัวหน้าทีม (แต่สกัมทีมมักมีความเท่าเทียมกัน เลยไม่นิยมเรียกว่าหัวหน้า แต่เรียกว่า Scrum master) ผู้ทำหน้าที่ประสานงานระหว่างสมาชิกในทีม และ Product owner โดยScrum master ต้องคอยแก้ไขปัญหา อุปสรรค ที่เกิดขึ้นระหว่างการทำงานด้วย เป็นบุคคลสำคัญในทีม
27
Scrum Team กลุ่มนักพัฒนามีสมาชิกก็จะประมาณ 5 – 9 คน สามารถทดแทนกันได้เสมอ สมาชิกในทีมมีตำแหน่งงานทางด้านการพัฒนาซอฟต์แวร์ ตั้งแต่นักวิเคราะห์และออกแบบระบบ นักพัฒนา นักออกแบบเว็บ นักทดสอบระบบ ทุกตำแหน่งในสกรัมทีมมีบทบาทและความสำคัญเท่ากัน คนในทีมต้องช่วยกันทำงานทุกเรื่องให้ลุล่วงตามเป้าหมายและเวลาที่กำหนด
28
Software Evolution
29
Scrum
งานนำเสนอที่คล้ายกัน
