Software Evolution แบบจำลองกระบวนการพัฒนา/ผลิตซอฟต์แวร์ (Process Model) แบบจำลองใช้สำหรับชี้นำถึงกิจกรรมหลัก (key Activities) ในการพัฒนาซอฟต์แวร์ ด้วยการกำหนดรายละเอียดหรือข้อบัญญัติไว้ในแต่ละกิจกรรมในแต่ละขั้นตอนที่มีลำดับขั้นตอนการพัฒนาที่ชัดเจน เพื่อต้องการให้การพัฒนาซอฟต์แวร์ดำเนินต่อไปโดยเกิดปัญหาน้อยที่สุด ปัจจุบันมีการคิดค้นแบบจำลองต่าง ๆ ให้เลือกใช้งานมากมาย ส่วนการตัดสินใจว่าจะเลือกใช้แบบจำลองใดขึ้นอยู่กับปัจจัยหลายอย่าง เช่น ขนาดของโครงการ ความเหมาะสม และระดับความเสี่ยง เป็นต้น สาเหตุสำคัญที่จำเป็นต้องใช้แบบจำลองการพัฒนาซอฟต์แวร์ เพราะ แบบจำลองพัฒนาซอฟต์แวร์จะมีการแตกขั้นตอนของกระบวนการพัฒนาในแต่ละเฟส (phase) ซอฟต์แวร์ที่พัฒนามีความซับซ้อน การแบ่งเป็นกระบวนการพัฒนาเป็นเฟสหรือระยะ จะทำให้ง่ายต่อการจัดการ แต่ละเฟสมีแนวทางต่าง ๆ ให้เลือกปฏิบัติ

Software Evolution แบบจำลองกระบวนการเชิงวิวัฒน์
(Evolutionary Process Model) ซอฟต์แวร์จะมีวิวัฒนาการตามกาลเวลาที่ผ่านไป ความต้องการผลิตภัณฑ์และธุรกิจมักเปลี่ยนแปลงไปเพื่อพัฒนาก้าวหน้าขึ้น ดังนั้นเมื่อการพัฒนาไม่สอดคล้องกับการตลาดจึงทำให้เกิดซอฟต์แวร์ที่ไม่สมบูรณ์ 100% แต่มักจะออกเวอร์ชั่นที่ทำงานอย่างจำกัดออกมาก่อน และขยายการทำงานต่อไปเรื่อย ๆ ซอฟต์แวร์เวอร์ชั่นหลัง ๆ จะมีความสมบูรณ์เพิ่มมากขิ้น แบบจำลองต้นแบบ (Prototyping Model) แบบจำลองสไปรัล (Spiral Model)

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 ที่ต้องการ ซึ่งทำให้ผู้พัฒนาไม่มั่นใจในการเลือกใช้อัลกอริทึ่มหรือโครงการ ดังนั้นวิธีการที่ดีที่สุดคือการสร้างต้นแบบเพื่อช่วยให้นักวิศวกรและลูกค้าได้เข้าใจกันดียิ่งขึ้น

Software Evolution แบบจำลองต้นแบบ (Prototyping Model) ข้อดี
ง่ายและรวดเร็วตามความต้องการของลูกค้า ลูกค้าสามารถตรวจสอบต้นแบบแต่ละขั้นและจัดหาข้อมูลเพิ่มเติมพร้อมผลตอบรับ เป็นแนวคิดที่ดี ถ้าพบกรณีดังนี้ ลูกค้าไม่สามารถหากำหนดความต้องการโดยละเอียดได้ มีความยุ่งยากในการสื่อสารเรื่องระบบกับลูกค้า มีการใช้เทคโนโลยี, ฮาร์ดแวร์ และอัลกอริทึ่มใหม่ ๆ เป็นการพัฒนาจุดหลักของแอพพลิชั่นระบบ ข้อเสีย ลูกค้าสัมผัสกับต้นแบบโดยไม่ทราบว่าสร้างมาอย่างหยาบ ๆ และหากมีการปรับปรุงบำรุงรักษาให้เกิดความสมบูรณ์ลูกค้าอาจไม่เข้าใจ ลูกค้าบางครั้งอาจกังวลว่าต้นแบบไม่ใช่ซอฟต์แวร์ที่ใช้งานได้จริง ผู้พัฒนาต้องระลึกอยู่เสมอว่าต้นแบบ คือ ระบบเบื้องต้น เครื่องมือหรืออัลกอรึทิ่มที่ใช้นำมาอย่างง่าย ๆ เพื่อนำเสนอ ห้ามยึดติดเพราะเครื่องมือเหล่านี้อาจไม่เหมาะสมกันสถานการณ์จริง

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) เป็นการวิเคราะห์ว่า ในการพัฒนาซอฟต์แวร์มีปัญหาอะไรบ้าง แต่ละปัญหาอาจส่งผลกระทบรุนแรงในระดับใด และมีโอกาสเกิดขึ้นได้มากเพียงใด แล้วรีบจัดการกับปัญหาที่มีโอกาสเกิดขึ้น และมีผลกระทบสูงก่อน ปัญหาดังกล่าวไม่จำเป็นว่าจะต้องเป็นปัญหาทางด้านเทคนิค แต่อาจจะเป็นปัญหาในการบริหารงานโครงการ ปัญหาเรื่องคน ฯลฯ เพื่อให้โครงการประสบความสำเร็จได้มากขึ้น ตัวอย่างเช่น หัวหน้าโครงการกำลังคิดจะลาอออก ซึ่งถ้าลาออกจริง โครงการก็จะล้มเหลว การเจรจากับหัวหน้าโครงการจึงเป็นเรื่องเร่งด่วนกว่าเรื่องเทคนิคทั้งหมด

Software Evolution แบบจำลองสไปรัล (Spiral Model) Liaison : การติดต่อ

Software Evolution แบบจำลองสไปรัล (Spiral Model) ขอบเขตการทำงาน:
The customer communication task เพื่อให้การปฏิสัมพันธ์ที่ดีและให้ผลลัพธ์ที่ตรงตามความต้องการระหว่างลูกค้าและผู้พัฒนา The planning task เพื่อวางแผนและกำหนดทรัพยากร เวลา และข้อมูลสารสนเทศอื่น ๆ ที่เกี่ยวข้องกับโครงงาน The risk analysis task เพื่อประกันคุณภาพความเสี่ยงเชิงเทคนิคและการจัดการ The engineering task เพื่อผลิตงานนำเสนอตัวแอพพลิเคชั่นของระบบให้แก่ลูกค้าหรือผู้พัฒนาเพื่อให้เกิดความเข้าใจร่วมกัน The construction and release task เพื่อสร้าง ทดสอบ ติดตั้ง และ จัดหาเครื่องสนับสนุนการใช้งานแก่ลูกค้า หรือผู้ใช้งาน อาทิ เอกสารคู่มือ และฝึกการอบรม เป็นต้น The customer evaluation task เพื่อให้ได้ผลตอบรับของลูกค้าที่จะนำมาทำให้เกิดวิวัฒนาการของสร้างผลิตภัณฑ์ขณะที่อยู่ใน สถานะดำเนินงาน และได้ผลตอบรับด้านพัฒนาขณะที่กำลังอยู่ในสถานะติดตั้ง

Software Evolution แบบจำลองสไปรัล (Spiral Model) ข้อดี
ใช้การวิเคราะห์ความเสี่ยงจำนวนมากสูง ดีต่อโครงการที่มีขนาดใหญ่และมีความเสี่ยงสูง ซอฟต์แวร์จะถูกผลิตภายในช่วงวงจรการพัฒนา ข้อเสีย เสียค่าใช้จ่ายสูงในการทำแบบจำลอง การวิเคราะห์ความเสี่ยงต้องการบุคลากรที่มีความเชี่ยวชาญ ความสำเร็จของผลิตภัณฑ์ขึ้นอยู่กับช่วงการวิเคราะห์ความเสี่ยง หากความเสี่ยงสำคัญไม่ถูกค้นพบ อาจเกิดปัญหาขึ้นในภายหลังได้ ไม่เหมาะในการนำไปใช้กับโครงการที่มีขนาดเล็ก

Software Evolution สรุปแบบจำลองกระบวนการเชิงวิวัฒน์
จุดอ่อนของแบบจำลองกลุ่มนี้ การพัฒนาซอฟต์แวร์ตามแบบกระบวนการนี้ สร้างปัญหาในการวางแผนโครงการ เพราะความไม่แน่นอนของจำนวนการทำซ้ำ เพราะผู้บริหารที่วางแผนโครงการมักมองเวลาในลักษณะเชิงเส้น เริ่มเมื่อไหร่ สิ้นสุดเมื่อไหร่ จึงมักขัดแย้งกัน กระบวนการนี้ไม่ได้กำหนดความเร็วของวิวัฒนาการซอฟต์แวร์ ถ้าวิวัฒนาการของซอฟต์แวร์เกิดขึ้นเร็วโดยไม่มีช่วงพัก กระบวนการจะยุ่งเหยิง สับสน โดยเฉพาะผู้ใช้งาน แต่ถ้าเกิดขึ้นช้าก็จะกระทบกับความสามารถในการผลิต โดยเฉพาะทีมพัฒนา กระบวนการนี้ควรเน้นที่ความยืดหยุ่น และความสามารถในการขยายตัวมากกว่าคุณภาพที่สูง ดังคำกล่าวที่ว่า “เราควรให้ความสำคัญกับการพัฒนาให้เสร็จทันเวลาก่อนที่โอกาสทางการตลาดจะหมดไป มากกว่า ไปพัฒนาซอฟต์แวร์ที่ไม่มีจุดบกพร่องเลย”

Software Evolution แนวคิดใหม่เกิดจากแนวคิดที่ว่าในระหว่างทำการพัฒนาระบบอยู่นั้น ความต้องการ ของซอฟต์แวร์มักจะปรับเปลี่ยนอยู่เสมอ ดังนั้นแบบจำลองแบบน้ำตกที่มองว่าการกำหนดความต้องการระบบเป็นจุดเริ่มต้นการทำงาน การพัฒนาซอฟต์แวร์ในขั้นตอนต่อไปอาจไม่สามารถทำได้ เนื่องจากความต้องการที่เปลี่ยนแปลงไป อีกทั้งปัญหาที่เกิดจากการสื่อสารที่ไม่ครบถ้วนหรือปัจจัยภายนอก เช่นเทคโนโลยีที่เปลี่ยนไป ปัจจัยทางธุรกิจ ดังนั้นกระบวนการพัฒนาหรือวงจรชีวิตซอฟต์แวร์ที่ดีควรมีแนวคิดของการเปลี่ยนแปลงความต้องการ มาเป็นส่วนหนึ่งในการกำหนดขั้นตอนกระบวนการในการพัฒนาซอฟต์แวร์

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

Software Evolution วัตถุประสงค์ของ Agile
เน้นว่าใครถนัดอะไร และการพูดคุยสื่อสารกัน มากกว่า การยึดติดที่เครื่องมือและกระบวนการ เช่นเปลี่ยนให้โปรแกรมเมอร์ไปคุยกับลูกค้าแทน ลูกค้าบอกอะไรมาก็ทำตามนั้นได้เลย ให้ทำงานโดยยึดที่ผลผลิต หรือ Software เป็นหลัก เช่น เดิมเน้นเอกสารแต่ Agile ไม่สนมากนัก แต่สนที่ว่าเรามี Software หรือของส่งให้ลูกค้าหรือยัง ให้ความสำคัญเรื่องของการติดต่อสื่อสาร เช่น เดิมมีสัญญาหรือ contact กันแต่ Agile ไม่สนใจ ให้มองที่ความสัมพันธ์ระหว่างผู้พัฒนากับลูกค้า ยอมรับความเปลี่ยนแปลง เช่น เดิมต้องวางแผนให้ครบเป็นอย่างดี และทำตามแผน (gantt chart) ให้ได้ แต่ Agile ไม่ต้องทำตามแผนแต่เน้นการสนองความเปลี่ยนแปลงที่เกิดขึ้นได้

Software Evolution หลักการของ Agile บัญญัติเอาไว้ 12 ข้อชัดเจนดังนี้
เป้าหมายที่สำคัญที่สุดคือการสร้างความพึงพอใจให้กับลูกค้าด้วยการส่งมอบผลิตภัณฑ์คุณภาพอย่างรวดเร็วและต่อเนื่อง ต้อนรับการเปลี่ยนแปลงความต้องการแม้ว่าจะอยู่ในช่วงปลายของการพัฒนา กระบวนการควบคุมการเปลี่ยนแปลงเพื่อให้ได้มาซึ่งข้อได้เปรียบทางการแข่งขันสำหรับลูกค้า ส่งมอบซอฟต์แวร์ที่ทำงานได้อย่างต่อเนื่อง จากจำนวน 2-3 สัปดาห์ไปจนถึง 2-3 เดือน โดยมุ่งหวังจะลดช่วงเวลาเหล่านี้ลง ผู้ที่ทำงานเชิงธุรกิจและทีนมพัฒนาจะต้องทำงานด้วยกันเป็นรายวันตลอดโครงการ สร้างความกระตือรือร้นให้กับบุคคล จัดสภาพแวดล้อมและการสนับสนุนที่ต้องการและไว้ใจว่าจะทำงานสำเร็จ วิธีการที่มีประสิทธิภาพและประสิทธิผลสูงสุด คือ การแลกเปลี่ยนข้อมูลกันภายในทีมพัฒนาด้วยการสนทนาโดยตรง ซอฟต์แวร์ที่ทำงานได้คือข้อมูลหลักที่ใช้บ่งบอกความก้าวหน้า

Software Evolution หลักการของ Agile (ต่อ)
กระบวนการส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุน ผู้พัฒนา และผู้ใช้ควรสามารถดำรงไว้ซึ่งก้าวไปข้างหน้าอันสม่ำเสมอไปด้วยกันอย่างไม่มีที่สิ้นสุด การให้ความสนใจอย่างต่อเนื่องต่อความสามารถทางเทคนิคและการออกแบบที่ดีช่วยเพิ่มความคล่องตัว ศิลปะของการเพิ่มปริมาณงานที่ไม่ต้องทำให้มากที่สุดเป็นสิ่งจำเป็น สถาปัตยกรรม ความต้องการ และการออกแบบที่ดีที่สุด มาจากทีมที่บริหารตนเองได้ ในช่วงเวลาที่เหมาะสม ทีมจะสะท้อนว่าทำอย่างไรจึงจะมีประสิทธิผลยิ่งขึ้น ต่อจากนั้นจึงปรับพฤติกรรมให้เหมาะสม หมายเหตุ : การทำงานในขั้นแรก ก็อาจมีการส่งมอบของได้เป็น หน้าจอ, Prototype, infrastructure โดยขั้นแรกอาจมองว่า Progress เราเท่ากับ 0 เปอร์เซ็นต์ (เพราะยังไม่มีซอฟต์แวร์เกิดขั้น)

โมเดลของ Agile เลือกบางหลักการมาทำ
ที่มีอยู่ได้ Agile ประกอบด้วย 1) value ผลลัพธ์ 2) principle หลักการ 3) pradctices วิธีปฏิบัติ ทั้งสามอย่างนี้เป็นส่วนหนึ่งในโมเดล Agile ที่สามารถนำมาพัฒนาซอฟต์แวร์ ให้มีประสิทธิภาพและเกิด overhead น้อย ให้มอง Agile เป็นส่วนขยายของกระบวนการพัฒนาซอฟต์แวร์แบบเดิมได้ นำ Agile เข้าไปกำกับ ดูว่าของเดิมที่มีอยู่อันไหนสำคัญก็ทำ ไม่สำคัญก็ไม่ทำ นำ Agile มาจัดลำดับความสำคัญ ดูว่ากิจกรรมไหน ควรทำก่อนหลัง

โมเดลของ Agile 1) Agile Model value 2) Agile Model Core principle
ได้ความต่อเนื่องในการติดต่อสื่อสาร ได้แนวทางปฏิบัติที่ง่าย ไม่ซับซ้อน ได้ feedback จากลูกค้า ได้ความกล้าตัดสินใจ ได้ความเคารพกันและกัน AM Supplement Principle ทำให้เป็นมาตรฐาน ค่อย ๆ สร้างให้มีรูปแบบ เมื่อถึงเวลาค่อยใช้ โมเดลไม่ใช้ ให้โยนทิ้งไปเลย เพราะจะได้ไม่เสียเวลามาดูแล เน้น contract (สัญญาระหว่างระบบที่สัมพันธ์กันอยู่) พยายามจัด contract ให้เป็นทางการ เช่น web service การ update code เฉพาะตอนที่มีปัญหา ดำเนินงานแบบง่าย ไม่ทำมากกว่าที่กำหนดไว้ พร้อมรับความต้องการ และพร้อมเปลี่ยนแปลงได้ตลอดเวลา เน้นงานที่ปัจจุบันเป็นหลัก ไม่คิดเผื่อ เวลาทำ Model ทำตามความจำเป็นเท่านั้น และพยายามใช้ multiple model มองหลายๆมุมมอง รับงานแล้วควรตอบกลับเร็ว คิดเสมอว่า SW ถือเป็นจุดมุ่งหมายหลัก เน้นเนื้อหาที่ควรจัดการมากกว่าการ representation (ที่ใช้ UML เขียน) ไม่เน้นเครื่องมือ (เน้นที่เนื้อหาข้างใน) การติดต่อกันอย่างเปิดเผย และตรงไปตรงมา

โมเดลของ Agile 3) Agile Model Core Practice
จัดประชุม รวบรวม Active stakeholder เท่านั้น บางมีอาจมี none-stakeholder เข้ามาฟังได้ แต่ห้ามออกความคิดเห็น ห้ามถาม ห้ามติดต่อ ห้ามแสดงไอเดีย นำ Artifact มาใช้ให้ถูกต้อง Note : Artifact คือชิ้นส่วนของงานที่เราทำระหว่างการพัฒนาระบบเช่น อีเมลล์, source code,จดหมาย,ใบเชิญประชุม ถ้า Artifact ใดถูกเลือกมาใช้ในการทำงาน เรียกว่า "work products" และถ้า work products นี้ ถูกส่งมอบให้ลูกค้าเรียกว่า "Deliverable" พยายามให้ทุกคนเป็นเจ้าของงาน สามารถทำงานแทนกันและกันได้ พยายามใช้โมเดลแบบคู่ขนาน จะได้มองต่างมุม เพื่อเก็บรายละเอียดของระบบให้ครบ และควรทำให้โมเดลเข้าถึงได้ทุกคน และให้ผู้อื่นมีส่วนร่วมในการทำโมเดล ลองเขียน code ดู (จาก code เริ่มต้นตั้งแต่แรก) ใช้เครื่องมือง่ายๆในการทำงาน เช่น กระดาษ,กระดานดำ

เทคนิคการพัฒนาแบบ 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 ตัวอย่างการเขียน

Agile UP (Unified Process) 2) XP (eXtream Programming)
Methodologies Agile Agile UP (Unified Process) 2) XP (eXtream Programming) 3) FDD (Feature Driven Development) 4) Scrum

Methodologies Agile Agile UP (Unified Process)
เป็นกระบวนการความพยายามที่จะดึงเอาลักษณะที่ดีที่สุดของกระบวนการดั้งเดิมออกมา แต่ปรับใช้ในลักษณะ Implement ให้ความสำคัญกับการสื่อสารกับลูกค้า และ Use case มาสร้างระบบ เพื่อให้มองเห็นเป้าหมายที่ถูกต้อง สามารถทำความเข้าใจ ปรับเปลี่ยนได้ในอนาคต และนำกลับมาใช้ใหม่ได้ กระแสของกระบวนการเป็นแบบทำวนซ้ำ และค่อยเพิ่มขึ้น อันเป็นลักษณะของเชิงวิวัฒน์ที่พบในการพัฒนาซอฟต์แวร์สมัยใหม่ กิจกรรมกรอบงานประกอบด้วย 5 เฟส และโยงเข้ากับกิจกรรมทั่วไป (1) Inception Phase (2) Elaboration Phase (3) Construction Phase (4) The Transition Phase (5) The Production Phase

วิธีการเชิงวัตถุและภาษาเชิงวัตถุได้รับความนิยมในหมู่วิศวกรซอฟต์แวร์ และนำแบบจำลองและการพัฒนาระบบเชิงวัตถุที่เรียกว่า UML (Unified Modeling Languages) เป็นกระบวนการความพยายามที่จะดึงเอาลักษณะที่ดีที่สุดของกระบวนการดั้งเดิมออกมา แต่ปรับใช้ในลักษณะ Implement ให้ความสำคัญกับการสื่อสารกับลูกค้า และ Use case มาสร้างระบบ เพื่อให้มองเห็นเป้าหมายที่ถูกต้อง สามารถทำความเข้าใจ ปรับเปลี่ยนได้ในอนาคต และนำกลับมาใช้ใหม่ได้ กระแสของกระบวนการเป็นแบบทำวนซ้ำ และค่อยเพิ่มขึ้น อันเป็นลักษณะของเชิงวิวัฒน์ที่พบในการพัฒนาซอฟต์แวร์สมัยใหม่ กิจกรรมกรอบงานประกอบด้วย 5 เฟส และโยงเข้ากับกิจกรรมทั่วไป

Methodologies Agile Agile UP (Unified Process) 2 1 3 5 4

ระยะเริ่มต้น (Inception Phase) - การสื่อสารกับลูกค้า และกิจกรรมการวางแผนงาน ซึ่งการพูดคุยจะทำให้สามารถ (1) ระบุความต้องการทางธุรกิจ (2) นำเสนอสถาปัตยกรรมอย่างคร่าว ๆ (3) วางแผนโครงงานในลักษณะทำวนซ้ำ หรือ ค่อยเพิ่มขึ้นได้ - การนำเสนอด้วย Use Case รุ่นแรก เสมือนสถาปัตยกรรมที่บ่งบอก (1) บุคคล เครื่องจักร หรือระบบอื่น ๆ ที่เข้ามามีปฏิสัมพันธ์กับระบบ (2) หน้าที่ ที่ระบบต้องทำ เป็นสิ่งที่อยู่ในระบบ สามารถถูกเพิ่มเติมในภายหลัง (3) ขอบเขตระหว่างระบบกับผู้กระทำต่อระบบ (4) ความสัมพันธ์ของวัตถุ กิจกรรมที่เกิดขึ้นในระบบ - การวางแผน ต้องระบุทรัพยากรที่ต้องใช้ ประเมินความเสี่ยงหลัก ๆ กำหนด ตารางเวลา และสร้างพื้นฐานสำหรับเฟสต่าง ๆ พัฒนาแบบค่อยเพิ่มขึ้น Actor Use Case Boundary Relationship

Inception Phase : Use case Library <<include>> Check Library Card Borrow books <<extends>> <<include>> Interlibrary loan <<include>> Return books Circulation Clerk Do research Member Read books, newspaper Purchase supplies Supplier

ระยะขยายรายละเอียด (Elaboration Phase) - ประกอบด้วยการสื่อสารกับลูกค้า และกิจกรรมสร้างแบบจำลอง การขยาย รายละเอียด - ปรับปรุง Use case ในระยะเบื้องต้น ให้ครอบคลุมสถาปัตยกรรมทั้ง 5 ของ ซอฟต์แวร์ ได้แก่ (1) แบบจำลอง Use case (2) แบบจำลองการวิเคราะห์ (3) แบบจำลองการออกแบบ (4) แบบจำลองการพัฒนา (5) แบบจำลองการนำไปใช้งาน - ทบทวนการสร้างแผนงานอย่างละเอียดในตอนท้าย เพื่อให้มั่นใจในขอบเขตงาน ความเสี่ยง และกำหนดวันส่งมอบ ว่ายังทำได้ตามกำหนด

ระยะก่อสร้าง (Construction Phase) - มีการพัฒนาหรือจัดหาคอมโพเนนท์ที่ทำงานตาม Use case - แบบจำลองการวิเคราะห์และออกแบบจะเสร็จสมบูรณ์ในเฟสนี้ - มีการพัฒนาลักษณะและหน้าที่ของซอฟต์แวร์ด้วย Source code - มีการทดสอบระดับหน่วยสำหรับแต่ละคอมโพเนนท์ - และอาจมีการประกอบคอมโพเนนท์และทดสอบการเชื่อมต่อกัน - การทดสอบมักสร้างชุดทดสอบ เพื่อให้เกิดการยอมรับก่อนถึงเฟสระดับถัดไป ระยะการส่งมอบ (The Transitive Phase) - เป็นระยะท้าย ๆ ของกิจกรมการก่อสร้าง และระยะต้นของกิจกรรมการใช้งาน - ผู้ใช้งานจะได้รับซอฟต์แวร์เพื่อทดสอบ และรายงานจุดบกพร่อง และส่วนที่ จำเป็นต้องเปลี่ยนแปลง - ทีมงานจะสร้างข้อมูลสนับสนุนที่จำเป็น ได้แก่ คู่มือการใช้งาน คู่มือการติดตั้ง ก่อนซอฟต์แวร์จะถูกส่งมอบ หรือวางตลาด

Methodologies Agile Agile UP (Unified Process) ระยะการทำงาน (The Production Phase) - กิจกรรมการใช้งานทั่วไป มีการเฝ้าดูการใช้งาน การสนับสนุนช่วยเหลือ และการ รายงานจุดบกพร่อง เฟสก่อสร้าง เฟสการส่งมอบ และเฟสการทำงาน อาจเกิดขึ้นได้ในเวลาเดียวกัน เนื่องจากมีการเริ่มงานสำหรับซอฟต์แวร์รุ่นถัดไป เพราะกระบวนการนี้ไม่ได้เรียงลำดับขั้น แต่เกิดขึ้นพร้อมกันเป็นชั้นช้อน ๆ กัน

Methodologies Agile I n c e p t i o h a s E l b r C u T V d m - j g y k . P , B f O U S q A w D x R v G These courseware materials are to be used in conjunction with software Engineering: A Pracitioner’s Approach, 6/e and are provinced with permission by R.S.Pressman & Associates, Inc.,copyright © 1996,2001,2005

Methodologies Agile 2) XP (eXtream Programming)
แนวคิดและวิธีการเอ็กซ์ทรีมโปรแกรมมิ่งเกิดขึ้นระหว่างปลายทศวรรษที่ 1980 ใช้แนวทางเชิงวัตถุในการพัฒนาระบบ โดยมีชุดของกฏและข้อปฏิบัติที่ต้องทำระหว่างกิจกรรมกรอบงาน 4 อย่าง (หัวใจหลัก) คือ (1) การวางแผน (Planning) (2) การออกแบบ (Design) (3) การเขียนโค้ด (Coding) (4) การทดสอบ (Test) ปัจจัยพื้นฐาน communication : เน้นเรื่องการพบปะพูดคุย (หลักการ Agile) Simplicity : ออกแบบและเขียนโปรแกรมให้ง่าย ไม่เน้น performance มากนัก เน้นเรื่องแก้ไขให้ถูกต้อง Feedback : เน้นเรื่องลูกค้า feedback เราเปลี่ยนได้เรื่อยๆ โดยใช้ refactor Courage : เราต้องสามารถตัดสินใจเองได้ โปรแกรมเมอร์มีความ กล้าในการตัดสิน

(1) การวางแผน (Planning) - ทีมพัฒนาจะเป็นผู้ทำหน้าที่เก็บรวบรวมข้อมูลความต้องการและวิเคราะห์ ความต้องการของผู้ใช้เอง แล้วจัดทำเป็น User Stories - โดยแต่ละเรื่องเล่าจะถูกจัดลำดับความสำคัญ และถูกนำมาพิจารณาว่าแต่ละเรื่อง ต้องใช้ระยะเวลาและต้นทุนเท่าใด - จากนั้นทีมพัฒนาจะให้ผู้ใช้เลือกเรื่องเล่าที่ต้องการให้พัฒนามากที่สุด - จัดเป็นข้อดี เนื่องจากเป็นการเลือกโดยผู้ใช้ภายใต้ระยะเวลาที่ผู้ใช้ย่อมต้องเป็นผู้ กำหนดเอง ทำให้สามารถตัดทอนส่วนที่ไม่จำเป็นลงไปได้ - จากนั้นทีมงานนำมาวิเคราะห์ต้นทุนและผลตอบแทน (Cost-benefit Analysis) ตามระยะเวลาที่กำหนด พร้อมทั้งจัดแบ่งกิจกรรมต่าง ๆ ออกเป็นรอบตามจำนวน รอบที่เหมาะสม

Methodologies Agile 2) XP (eXtream Programming) (2) การออกแบบ (Design)
- หลักการออกแบบจะยึดหลัก KIS (Keep it Simple) คือ ทำให้ง่ายที่สุด แม้ว่า ระบบจะซ้ำซ้อนมากก็ตาม โดยการจัดทำต้นแบบ - นอกจากนี้ การออกแบบยังได้กำหนดรายละเอียดที่เอื้อประโยชน์ในการเขียน โปรแกรมอีกด้วย โดยเพิ่มฟังก์ชั่นที่คาดว่าผู้ใช้ต้องการไว้ให้ - ไม่สนับสนุนให้มีการออกแบบหน้าที่อื่น ๆ นอกเหนือจากเรื่องเล่า - ถ้ามีปัญหาในการออกแบบที่ยากลำบากสำหรับเรื่องเล่าใด แนะนำให้สร้างต้นแบบ ที่ทำงานไดจริง เรียกว่า คำตอบสไปค์ (Spike Solution) เพื่อลดความเสี่ยงเมื่อมี การพัฒนาจริง

(3) การเขียนโค้ด (Coding) - เมื่ออกแบบขั้นต้นแล้ว ไม่ควรเริ่มเขียนโค้ดในทันที แต่ควรพัฒนาชุดทดสอบ ระดับหน่วย ที่จะทำงานกับเรื่องเล่าแต่ละเรื่องที่สร้างขึ้นก่อน จึงเริ่มเขียนโค้ด ให้ทำงานผ่านการทดสอบ (ควรทดสอบโดยทันทีเมื่อเขียนโค้ดเสร็จ) - แนวคิดที่สำคัญในการทำงานแบบเอ็กซ์พี เรียนกว่า โปรแกรมเป็นคู่ (Pair Programming) คือการแนะให้คนสองคนทำงานร่วมกัน สำหรับเรื่องเล่าเรื่อง หนึ่ง เครื่องคอมพิวเตอร์เดียวกัน เป็นกลไกที่ช่วยกันแก้ปัญหาและควบคุม คุณภาพเฉพาะหน้า - เมื่อคู่โปรแกรมเมอร์ทำงานเสร็จ โค้ดจะถูกร่วมเข้ากับโค้ดของโปรแกรมอื่น ซึ่ง บางครั้งเกิดขึ้นเป็นประจำ เรียกว่า รวมกันอย่างต่อเนื่อง (Continuous Integration) เป็นกลยุทธ์ที่ช่วยป้องกันการทำงานเข้ากันไม่ได้ของแต่ละส่วน

Methodologies Agile 2) XP (eXtream Programming) (4) การทดสอบ (Test)
- การทดสอบแบบ Unit Test โดยมีการสร้าง Unit Test Case ไว้ก่อนการเขียน โปรแกรมภายใต้กรอบการสร้างงานทดสอบ - ทำให้สามารถทดสอบโปรแกรมได้โดยอัตโนมัติ และทำให้ง่ายต่อการทดสอบซ้ำ เมื่อต้องแก้ไขโปรแกรม - จากนั้น จะนำไปให้ลูกค้าทดสอบ เรียกว่า Customer Test ซึ่งก็คือ การทดสอบ การยอมรับ (Acceptance Test) นั่นเอง

Methodologies Agile 3) FDD (Feature Driven Development)
เริ่มจากการค้นค้นของ Peter Cord และคณะ ในปี 1999 จากหนังสือ “Java model in color with UML” เพื่อใช้เป็นกระบวนการเชิงปฏิบัติของวิศวกรรมซอฟต์แวร์เชิงวัตถุ จากนั้นจึงมีขยายและเพิ่มงานที่สามารถประยุกต์ใช้กับโครงการขนาดกลางและขนาดใหญ่ขึ้น ปกติเวลาเริ่มต้นโครงการเราต้องกำหนด stakeholder ว่ามีใครบ้าง จากนั้นก็เก็บ business goals (BG) กับ stakeholder เหล่านั้น ซึ่ง BG ปัญหาและเป้าหมายของเขา ซึ่งทางทีมพัฒนาฯ ต้องทำความเข้าใจ และที่สำคัญควรมีอีกทีมที่ทำหน้าที่ทำความเข้าใจและตีความ BG เหล่านั้น เพราะหลายครั้งมักพบว่าทีมพัฒนาฯ ขาดทักษะด้านธุรกิจหรือมีไม่พอทำให้ตีความผิดและเข้าใจคลาดเคลื่อน สมัยนี้หลายองค์กรจึงมีคนที่รับบทบาท เช่น solution architect, business IT strategist, ฝ่ายการตลาด เป็นต้น เพื่อทำความเข้าใจกับ BG เหล่านั้น

เมื่อระบุ feature เรียบร้อยแล้วก็เสนอลูกค้าหรือผู้บริหารครับ เมื่อตกลงยืนยันกันตามนี้ feature ก็ถือเป็น commitment ระหว่างทีมพัฒนาฯ และผู้บริหาร (หรือลูกค้า) การบริหารโครงการก็ต้อง base on feature จากนั้นก็เริ่มเก็บ requirements กัน ไม่ว่าจะเป็นด้าน functional requirements, non-functional requirements ซึ่งแต่ละความต้องการต้องระบุด้วยว่าสัมพันธ์กับ feature ใด (requirements traceability) โดย software artifact ทุกประเภทต้องระบุว่าสัมพันธ์กับความต้องการใดและ feature ใด ไม่ว่าจะโมเดล diagram เอกสาร ซอร์สโค้ด test case ฯ ต้องระบุให้หมด เพราะทุกอย่างต้องสอดคล้องกับ feature ซึ่งในขณะเดียวกัน feature เองก็ต้องระบุด้วยว่าสัมพันธ์กับ BG ใดบ้าง เพื่อประโยชน์ต่อการตรวจสอบย้อนกลับหรือไปข้างหน้า (Traceability) Traceability : ติดตาม หาร่องรอย ลากเส้น และเดินตามทาง หรือสืบ

คุณลักษณะ “หน้าที่ที่ลูกค้าเห็นว่ามีคุณค่า ที่สามารถพัฒนาได้ภายในเวลา 2 – 4 สัปดาห์” ดังนี้ (1) เนื่องจากคุณลักษณะเป็นส่วนเล็ก ๆ ของซอฟต์แวร์ที่ทำงานได้ จึงสามารถ อธิบายและเข้าใจความสัมพันธ์ระหว่างกันได้ง่ายกว่า และสามารถทบทวนได้ ดีกว่า หากคลุมเครือข้อผิดลาด หรือหลงลืม (2) คุณลักษณะอาจถูกจัดระเบียบ เป็นกลุ่มลำดับชั้นที่มีความสัมพันธ์ทางธุรกิจ (3) คุณลักษณะซอฟต์แวร์ที่ต้องส่งมอบได้ในการพัฒนาแบบ FDD ทีมงานจะมุ่ง พัฒนาซอฟต์แวร์ให้มีคุณลักษณะใหม่ ๆ ที่ทำงานได้ทุก ๆ 2 สัปดาห์ (4) คุณลักษณะมีขนาดเล็ก ตัวแบบและโค้ดจึงง่ายต่อการตรวจทานอย่างละเอียด (5) การวางแผน จัดตารางงาน ติดตามการขับเคลื่อนด้วยคุณลักษณะตามลำดับ ซึ่งดีกว่าการใช้ชุดง่ายย่อยที่เลือกมาแบบสุ่ม

บทบาทและหน้าที่ที่จำเป็นต้องมีเพื่อสนับสนุนให้เกิดความกระบวนการที่ถูกต้อง 1. Domain Manager 2. Release Manager 3. Language Guru 4. Build Engineer 5. Toolsmith 6. System Administrator 7. Tester 8. Deployer 9. Technical Writer

Methodologies Agile 4) Scrum
สครัมมาจากกิจกรรมในการแข่งขันรักบี้ เป็นกระบวนการอาไจลที่พัฒนาโดย Jeff Sutherland และทีมงาน เมื่อต้นทศวรรษ 1990 หลักการของสครัมมีดังต่อไปนี้ (1) จัดตั้งทีมทำงานขนาดเล็กที่ “เกิดการสื่อสาร การแบ่งปันเทคนิค และข่าวสารที่ ไม่เป็นทางการให้มากที่สุด ขณะที่ลดค่าใช้จ่ายส่วนเกินให้น้อยที่สุด” (2) กระบวนการต้องสามารถปรับเข้ากับการเปลี่ยนแปลงทางธุรกิจและเทคนิคได้ เพื่อผลิตผลงานให้ดีที่สุด (3) กระบวนการต้องผลิตรุ่นซอฟต์แวร์ออกมาบ่อย ๆ เพื่อตรวจสอบ ปรับแต่ง ทดสอบ บันทึกและต่อยอดได้ (4) งานที่พัฒนาและนักพัฒนาจะแบ่งออกเป็นแพ็คเก็ตหรือพาร์ติดชั่นที่สุดและ ขึ้นแก่กันน้อยที่สุด (5) มีการทดสอบและบันทึกเอกสารอย่างสม่ำเสมอขณะสร้างผลิตภัณฑ์ (6) กระบวนการสครัมจะต้อง “สามารถแจ้งว่า พัฒนาผลิตภัณฑ์เสร็จแล้ว” เมื่อใดก็ตามที่ต้องการ (มีการแข่งขันสูง/บ.ต้องการเงิน/ลค.ต้องการใช้งาน)

หลักการสครัมใช้นำทางกิจกรรมพัฒนา ภายใต้กระบวนการที่รวมเอากิจกรรมกรอบงานต่อไปนี้ คือ ความต้องการ การวิเคราะห์ การออกแบบ การวิวัฒน์ และการส่งมอบ ที่พิสูจน์แล้วว่าได้รับผลดี สำหรับโครงการที่มีเวลาจำกัด มีการเปลี่ยนแปลงความต้องการ และมีความสำคัญอย่างยิ่งยวดต่อธุรกิจ แบบรูปกระบวนการแต่ละแบบนิยามชุดกิจกรรมพัฒนาระบบต่อไปนี้ - แบ็คล๊อก (Backlog) รายการความต้องการหรือลักษณะที่ให้คุณค่าทางธุรกิจแก่ ลูกค้าที่เรียงลำดับความสำคัญแล้ว รายการอาจเพิ่มเข้ามาใหม่ได้ โดยผู้จัดการต้อง ประเมินและปรับปรุงลำดับความสำคัญตามความเหมาะสม - สปริ้น (Sprints) ประกอบด้วยหน่วยของงาน ต้องทำให้เสร็จตามความต้องการที่ นิยามโดยแบ็คล๊อก โดยหน่วยของงานหนึ่ง ๆ ต้องทำให้เสร็จได้จริงตามกรอบ เวลาที่กำหนดไว้แล้วล่วงหน้า (ปกติ 30 วัน) ระหว่างสปริ้น รายการแบ็คล็อกใดที่ กำหนดสปริ้นอยู่จะถูกหยุดการเปลี่ยนแปลงไว้ก่อน

- การพบปะของสครัม (Scrum meeting) การประชุมสั้น ๆ ประมาณ 15 นาที ของทีมสครัมจะมีทุก ๆ วัน เพื่อถามและตอบคำถามสามข้อ คือ (1) คุณได้ทำอะไรไปแล้วหลังจากการประชุมครั้งที่แล้ว (2) มีอุปสรรคอะไรหรือไม่ที่พบ (3) คุณวางแผนจะทำอะไรให้เสร็จก่อนการประชุมคราวหน้า หัวหน้าทีมสครัม (Scrum Master) จะนำการประชุมและประเมินการตอบสนอง ของแต่ละบุคคล การประชุมสครัมช่วยให้ทีมค้นพบปัญหาเร็วที่สุดเท่าที่จะทำได้ นอกจากนี้ยังเป็นการสังสรรค์เชิงความรู้ และช่วยก่อให้เกิดโครงสร้างทีมจัด ระเบียบตนเองได้ด้วย - สาธิต (Demos) ส่งมอบรุ่นซอฟต์แวร์แก่ลูกค้าเพื่อสาธิตและประเมินหน้าที่การ ทำงานที่ได้พัฒนาแล้ว การสาธิตไม่จำเป็นต้องมีหน้าที่ครบถ้วนตามแผนที่วางไว้ แต่ต้องมีหน้าที่ที่ส่งมอบได้ภายในกรอบเวลาที่กำหนด

สครัมทีมจะถูกปลูกจิตสำนึกว่า “We’re all in this together” A typical Scrum team is 6-10 people but Jeff Sutherland has scaled Scrum up to over 500 people

Methodologies Agile บทสรุป
Agile ถือเป็นเรื่องใหม่ ขณะนี้จะมองว่าเป็นไปตามสมัยนิยม (fashion) หรืออนาคตก็ได้ทั้งสองอย่าง แนวคิดอย่าง Agile กำลังเริ่มต้นเท่านั้น ยังรอคอยการลองผิดลองถูก รูปแบบแอพพลิเคชั่นในปัจจุบันก็แตกต่างกันมากขึ้นทุกวัน เครื่องมือการพัฒนาซอฟต์แวร์ก็พัฒนาไปมาก เพียงรูปแบบแอพพลิเคชั่นในอนาคตยังคาดการณ์ไม่ได้ วิธีการพัฒนาก็คงจะเป็นเช่นเดียวกัน และเป็นการยากที่จะบอกว่า Agile ดีกว่าแบบอื่น ๆ เพราะขึ้นอยู่กับสถานการณ์ที่จะนำไปประยุกต์ใช้และวัฒนธรรมขององค์กรเป็นสำคัญ

งานนำเสนอที่คล้ายกัน

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

งานนำเสนอที่คล้ายกัน

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ