บทที่ 2 ภาพรวมกระบวนการ (A Generic View of Process)

งานนำเสนอเรื่อง: "บทที่ 2 ภาพรวมกระบวนการ (A Generic View of Process)"— ใบสำเนางานนำเสนอ:

1 บทที่ 2 ภาพรวมกระบวนการ (A Generic View of Process)
เนื่องจากซอฟต์แวร์ซึ่งเหมือนกับทุน (Capital)ประเภทอื่นๆเป็น ความรู้ที่ได้รับการรวบนวมขึ้นมา ถึงแม้ว่าในตอนเริ่มแรกความรู้เหล้า นั้นจะอยู่กระจัดกระจายแฝงอยู่อย่างเงียบๆและไม่สมบูรณ์ตามมาตรวัด ขนาดใหญ่ จึงทำให้การพัฒนาซอฟต์แวร์เป็นเหมือนกับกระบวนการ เรียนรู้ทางสังคมแบบหนึ่ง การสร้างซอฟต์แวร์คอมพิวเตอร์เป้นกระบวนการที่ต้องทำซ้ำไป ซ้ำมาโดย Baetjer เรียกผลลัพธ์ที่ได้ว่า “ทุนซอฟต์แวร์หรือ ซอฟต์แวร์แคปปิตอล”ซึ่งเป็นการรวมกลั่นกรองและจัดการความรู้ที่ได้ จากการทำกระบวนการนี้

2 2.1 วิศวกรรมซอฟต์แวร์ : เทคโนโลยีแบบชั้น (Software Engineering A Layered Technology
แม้ว่าผู้เขียนนิยามคำว่าวิศวกรรมซอฟต์แวร์ไว้มากมาย แต่ นิยามที่ Fritz Bauer [NAU69] เสนอไว้ในงานประชุมทางการด้าน วิศวกรรมซอฟต์แวร์แห่งหนึ่ง ยังคงเป็นนิยามพื้นฐานที่ดีอยู่กล่าวคือ วิศวกรรมซอฟต์แวร์คือการสร้างและการใช้กลังทางวิศวกรรมที่ เหมาะสมเพื่อให้ได้มาซึ่งซอฟต์แวร์ที่มีราคาไม่แพง แต่เชื่อใจได้และ ทำงานได้อย่างมีประสิทธิภาพบนเครื่องจักรจริง นอกจากนี้นิยามนี้ไม่ได้กล่าวถึงความสำคัญของการวัดและตัววัด ประสิทธิภาพของกระบวนการอย่างไรก็ตามนิยามของ Bauer นี้นับ ได้ว่าเป็นจุดเริ่มต้นที่ดีคำถามต่างๆต่อไปนี้ยังคงเป็นสิ่งที่ท้าทายของนัก วิศวกรรมซอฟต์แวร์อยู่คือ หลักการที่เหมาสมทางวิศวกรรมที่สามารถนำมาใช้ได้กับการพัฒนา ซอฟต์แวร์คอมพิวเตอร์คืออะไร? เราจะสร้างซอฟต์แวร์ที่ไม่แพงแต่เป็นซอฟต์แวร์ที่เชื่อใจได้ไม่เสียง่าย ได้อย่างไร? เราจะต้องทำอย่างไร จึงจะทำให้โปรแกรมคอมพิวเตอร์ที่สร้างขึ้นมา สามารถใช้งานได้บนเครื่องคอมพิวเตอร์จริงที่แตกต่างกันได้ทุกเครื่อง?

3 วิศวกรรมเป็นเทคโนโลยีแบบชั้นตามรูป 2
วิศวกรรมเป็นเทคโนโลยีแบบชั้นตามรูป 2.1แนวทางวิศวกรรม ไม่ว่าจะสาขาใดก็ตาม(รวมถึงวิศวกรรมซอฟต์แวร์ด้วย)จะต้องพึ่งพากับ นโยบายด้านคุณภาพขององค์กรการบริหารคุณภาพเบ็ดเสร็จ(Total Quality Management)ซิกซ์ซิกมา(Six Sigma) และปรัชญาเชิง คุณภาพอื่นๆ ชั้นที่ช่วยสนับสนุนวิศวกรรมซอฟต์แวร์นี้คือชั้นที่มีชื่อว่า ศูนย์คุณภาพ(A Quality Focus ) ชั้นที่เป็นรากฐานของวิศวกรรมซอฟต์แวร์คือชั้น กระบวนการ (Process)กระบวนการทางวิศวกรรมซอฟต์แวร์เป็นเสมือนกาวที่เชื่อม ชั้นต่างๆที่เกี่ยวกับเทคโนโลยีเข้าด้วยกันและทำให้การพัฒนา ซอฟต์แวร์คอมพิวเตอร์อย่างมีเหตุมีผลและเหมาะสมกระบวนการเป็น ตัวกำหนดกรอบ (Pau93)ซึ่งได้รับการสร้างขึ้นเพื่อการได้มาอย่างมี ประสิทธิภาพของเทคโนโลยีที่ใช้ในวิศวกรรมซอฟต์แวร์กระบวนการ ซอฟต์แวร์นี้เป็นหลักสำคัญในการควบคุมของฝ่ายบริหารที่มีต่อ โครงงานซอฟต์แวร์และยังเป็นสิ่งที่ทำให้เกิดสภาวะที่ซึ่งสามารถนำวิธี เทคนิคต่างๆไปประยุกต์ใช้ผลผลิตของงาน

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

5 2.2 กรอบงานของกระบวนการ (A Process Framework)
กรอบงานของกระบวนการ เป็นพื้นฐานสำคัญของกระบวนการซอฟต์แวร์กรอบงานจะแยกออกได้เป็นกิจกรรมกรอบงาน (Framework Activity) จำนวนมาก ซึ่งสามารถใช้ได้กับทุกโครงงานทางซอฟต์แวร์ไม่ว่าโครงงานนั้นจะมีขนาดเท่าใด นอกจากนี้กรอบงานของกระบวนการยังครอบคลุมสิ่งที่เรียกว่า ชุดกิจกรรมร่ม (Umbrella Activitys) ซึ่งเป็นกิจกรรมที่ใช้ได้กับกระบวนการทางซอฟต์แวร์ที่กำลังพิจารณาทั้งกระบวนการ

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

7 การสื่อสาร(Communication)กิจกรรมของกรอบงานนี้เกี่ยวข้องกับ การติดต่อสื่อสารและการทำงานร่วมกันกับลูกค้าและผู้มีส่วนได้ส่วน เสียทางธุรกิจอื่นๆกิจกรรมนี้เป็นกิจกรรมที่รวบรวมข้อมูลด้านความ ต้องการเข้าไว้ด้วยกัน การวางแผน(Planning)กิจกรรมนี้เป็นตัวสร้างแผนการทำงานซึ่งจะ บอกถึงงานเชิงเทคนิคที่จะต้องทำความเสี่ยงที่อาจจะเกิดขึ้นทรัพยากร ต่างๆที่ต้องใช้ตัวผลงานที่ต้องการและตารางการทำงาน การสร้างแบบจำลอง(Modeling)กิจกรรมนี้เป็นตัวสร้างแบบจำลองซึ่ง ช่วยให้พัฒนาและลูกค้า เข้าใจถึงความต้องการทางซอฟต์แวร์ได้ดี ขึ้นและเข้าใจถึงการออกแบบซึ่งจะนำไปสู่ความต้องการเหล่านั้น การสร้าง(Construction)กิจกรรมนี้รวมการเขียนโปรแกรมและทอ สอบข้อผิดพลาดของโปรแกรม การใช้งาน(Deployment)เป็นกิจกรรมที่นำซอฟต์แวร์ที่ผลิตเสร็จแล้ว (ทั้งหมดหรือบางส่วน)ไปส่งมองให้แก่ลุกค้าโดยลูกค้าจะเป็นผู้ประเมิน และให้ความคิดเห็นเกี่ยวกับผลิตภัณฑ์ เราสามารคใช้กิจกรรมทั้ง 5 ข้างต้นกับการพัฒนาโปรแกรมขนาด เล็ก การสร้างเว็บแอพพลิเคชั่นขนาดใหญ่และงานวิศวกรรมระบบ คอมพิวเตอร์ที่ซับซ้อน

8 กรอบงานทั่วไปของกิจกรรมซอฟต์แวร์ได้รับการเสริมด้วย กิจกรรมร่ม (Umbrella Activities)กิจกรรมในกลุ่มนี้ได้แก่ การติดตามและควบคุมโครงการซอฟต์แวร์ (Software Project Tracking and Control) ทำให้ทีมงานซอฟต์แวร์ได้รับ ความก้าวหน้าของโครงการว่าเป็นไปตามแผนที่วางไว้หรือไม่ ทั้งนี้ อาจต้องลงมือกระทำบางอย่างเพื่อที่จะรักษาตาราเวลา การจัดความเสี่ยง (Risk Management) ประเมินความเสี่ยงซึ่งอาจ ส่งผลต่อผลลัพธ์ของโครงการหรือคุณภาพของผลิตภัณฑ์ การประกันคุณภาพซอฟต์แวร์ (Software Quality Assurance) กำหนดแล้ทำกิจกรรมที่จำเป็นเพื่อให้ได้ซอฟต์แวร์ที่มีคุณภาพ การพิจารณาด้านเทคนิค (Formal Technical Reviews)ประเมิน ชิ้นงานเพื่อหาและขจัดข้อบกพร่องก่อนที่จะไปทำกิจกรรมถัดไป การวัด (Measurement) บ่งบอกและรวบรวม การวัดผล กระบวนการ โครงการและผลิตภัณฑ์ ซึ่งช่วยทีมในการส่งมอบ ซอฟต์แวร์ที่เป็นไปตามความต้องการของลูกค้า เราสามารถใช้การ วัดร่วมกับกิจกรรมกรอบงานหรือกิจกรรมร่มอื่นๆ

9 การจัดการโครงแบบของซอฟต์แวร์ (Software Configuration Management) กำหนดกฎเกณฑ์สำหรับการใช้ใหม่ของชิ้นงาน (รวมถึงองค์ประกอบของซอฟต์แวร์) และสร้างกลไกเพื่อให้ได้ โพเนนท์ที่สามารถนำกลับมาใช้ได้ใหม่ การเตรียมและการผลิตชิ้นงาน (Work Product Preparation and Production) รวมหลายกิจกรรมที่ใช้ในการสร้างสรรค์สร้างชิ้นงาน เช่น แบบจำลอง เอกสาร บันทึก แบบฟอร์ม และรายการ

10 2.3แบบจำลองวุฒิภาวะและความสามารถเชิงบูรณาการหรือซีเอ็มเอ็มไอ (The Capability Maturity Model Integration CMMI) สถาบันวิศวกรรมซอฟต์แวร์ ได้พัฒนาอภิแบบจำลองกระบวนการเชิง บูรณาการซึ่งแสดงถึงชุดระบบและความสามารถทางวิศวกรรม ซอฟต์แวร์ที่ควรมีในขณะที่องค์กรกำลังดำเนินไปถึงความสามารถ และการเติมโตทางกระบวนการในระดับต่างๆเพื่อให้ได้ความสามารถ เหล่านี้ SEI ได้ยืนยันว่าองค์กรควรจะสร้างแบบจำลองกระบวนการที่ สอดคล้องกับแนวทางของแบบจำลองวุฒิภาวะและสามารถเชิงบูรณา การหรือ CMMI CMMI นำเสนออภิแบบจำลองกระบวนการได้ 2 แบบ แบบจำลองต่อเนื่อง (Continuous Model) แบบจำลองแบบขั้น (Staget Model)

11 รูปที่ 2.3 CMMI process area capability profile
ระดับ 0 แบบไม่บริบูรณ์ เมื่อสาขากระบวนการเช่น สาขา กระบวนการการจัดการความต้องการ ไม่ทำงานหรือไม่บรรลุ เป้าหมายทุกประการที่กำหนดไว้ในความสามารถระดับ I ของ CMMI ระดับ 1 แบบทำงานได้ ทุกเป้าหมายของสาขาการะบวนการได้รับ การตอบสนอง ภารกิจที่จำเป็นต่อการผลิตภัณฑ์ ที่กำหนดกำลัง ดำเนินไป

12 ระดับ 2 แบบจัดการได้ คือแบบที่ผ่านเกณฑ์ของทุกระดับ I และ ทุกงานที่เกี่ยวข้องกับสาขาการบวนการทำงานได้ตามที่กำหนดไว้ใน นโยบายขององค์กร ผู้ปฏิบัติงานทุกคนสามารถเข้าถึงทรัพยากรที่ เพียงพอต่อการปฏิบัติงานของตน ระดับ 3 แบบกำหนดได้ ผ่านทุกเกณฑ์ในระดับ 2 นอกจากนี้ กระบวนการยังสามารถปรับแต่งเฉพาะงานตามแนวทางมาตรฐานของ องค์กร และกระบวนการยังสามารถให้ข้อมูลเกี่ยวกับชิ้นงานข้อมูล ตัวจัด และข้อมูลการปรับปรุงกระบวนการอื่นๆ ระดับ 4 แบบจัดการได้เชิงปริมาณ นอกจากกดเกณฑ์ระดับ 3 แล้ว 4 นี้ต้องมีการควบคุมและปรับปรุงกระบวนการโดยใช้การ ประเมินการวัด และการประเมินเชิงปริมาณต้องมีการกำหนด วัตถุประสงค์เชิงปริมาณสำหรับคุณภาพและการทำงานของ กระบวนการ และใช้เป็นเกณฑ์ในการบริหารกระบวนการ ระดับ 5 แบบเหมาะสมที่สุด นอกตากทุกเกณฑ์ในระดับ 4 แล้ว จะต้องมีการใช้วิธีเชิงปริมาณกับส่วนกระบวนการ เพื่อให้ได้ตาม ความต้องการของลูกค้าที่เปลี่ยนแปลงไปตลอดเวลา และเพื่อเพิ่ม ประสิทธิภาพและประสิทธิผลของส่วนกระบวนการที่กำลังพิจารณา

13 CMMI นิยามแต่ละสาขากระบวนการในรูปแบบของ เป้าหมายเฉพาะ และวิธีปฏิบัติเฉพาะ ที่จำเป็นต่อการบรรลุเป้าหมายเหล่านี้ เป้าหมายเฉพาะระบุลักษณะที่ต้องมีหากต้องการให้กิจกรรมของสาขากระบวนการมีประสิทธิภาพ วิธีปฏิบัติเฉพาะจะช่วยปรับเปลี่ยนเป้าหมายไปสู่ชุดของกิจกรรมที่เกี่ยวข้องกับกระบวนการ

14 2.4 แบบรุปกระบวนการ (Process Patterns) แบบรูประบวนการเป็นการให้แม่แบบ (Template) ซึ่งก็คือวิธีการ บรรยายลักษณะสำคัญของกระบวนการซอฟต์แวร์ทีมงานซอฟต์แวร์ สามารถที่จะสร้างกระบวนการได้ตรงตามความต้องการของโครงการ กระบวนการจ่างๆที่เกี่ยวข้อง Ambler[AMB98] ได้นำเสนอแม่แบบเพื่อใช้อธิบายแบบรูป กระบวนการไว้ดังนี้ ชื่อแบบรูป (Intent): ซึ่งแบบรูปจะต้องสื่อถึงหน้าที่ภาย กระบวนการซอฟต์แวร์เช่น การสื่อสารกับลูกค้า ความจำนง (Intent): ต้องมีการระบุวัตถุประสงค์ไว้โดยย่อ ตัวอย่างเช่น ความจำนงของการสื่อสารกับลูกค้า คือ เพื่อสร้างความ ร่วมมือกับลูกค้าในการพยายามที่จะกำหนดขอบข่ายของโครงการความ ต้องการทางธุรกิจ และข้อจำกัดอื่นๆของโครงการเราอาจจะอธิบาน ความจำนงเพิ่มเติมด้วยข้อความที่ละเอียดขึ้นหรือใช้แผนภาพช่วยการ อธิบาย

15 ชนิด (Type): ชนิดของรูปแบบ อาจะแบ่งออกได้ 3 ชนิด [AMB98] คือ
แบบรูปงานย่อย (Task Pattern) เป็นตัวกำหนดการกระทำ ทางด้านวิศวกรรมซอฟต์แวร์ซึ่งเป็นส่วนหนึ่งของกระบวนการ ละ สัมพันธ์กับวิธีปฏิบัติทางด้านวิศวกรรมซอฟต์แวร์ที่ประสบความสำเร็จ ตัวอย่างของรูปแบบงานย่อยได้แก่ การรวบรวมความต้องการ แบบรูปขั้น (Stage Pattern) เป็นตัวกำหนดกิจกรรมของกรอบงาน เนื่องจากกิจกรรมกรอบงานประกอบด้วยตัวงานย่อยหลายงานดังนั้น แบบของขั้นจึงเป็นการรวบรวมของงานย่อยซึ่งสอดคล้องกับขั้นได้แก่ การสื่อสารแบบของชั้นนี้จะรวมแบบรูปงานย่อยการรวบรวมความ ต้องการและแบบรูปงานย่อยอื่นๆเข้าไว้ด้วยกัน แบบรูปเฟส (Phase Pattern) เป็นตัวกำหนดลำดับของกิจกรรมกรอบ งานซึ่งเกิดกับกระบวนการแม้แต่กรณีการไหลของกิจกรรมนั้นมีการวน ซ้ำ ตามธรรมชาติตัวอย่างหนึ่งของรูปแบบเฟสคือ แบบจำลองแบบ เกลียวหรือ การจัดทำต้นแบบโปรแกรม

16 บริบทตั้งต้น (Initial Context): กล่าวถึงสภาวะแวดล้อมของการที่จะนำ รูปแบบไปประยุกต์ใช้ก่อนการจะเกิดขึ้นของรูปแบบเราอยากจะทราบว่า 1. มีกิจกรรมที่เกิดขึ้นกับทีมหรือองค์กรอะไรบ้างที่เกิดขึ้นแล้ว 2. สถานะของ กระบวนการในตอนเริ่มต้นเป็นอย่างไรและ 3.สารสนเทศทางวิศวกรรมซอฟต์แวร์หรือสารสนเทศของโครงการอะไรบ้างที่มีอยู่ ปัญหา (Problem) เป็นการอธิบานวิธีแก้ปัญหาโดยใช้รูปแบบเช่น ปัญหา ที่จะแก้ไขโดยแบบรูปการสื่อสารกับลูกค้าอาจอธิบายได้ดังนี้ การสื่อสารระหว่างผู้พัฒนาและลูกค้าไม่เพียงพอเนื่องจากไม่มีรูปแบบที่มี ประสิทธิภาพในการดึงเอาข้อมูลที่จำเป็นจากลูกค้า ทางแก้ปัญหา (Solution) บรรยายถึงการนำเอารูปแบบไปใช้บอกเล่าว่า จะปรับปรุงกระบวนการอันเป็นตัวตั้งต้นแบบได้อย่างไร บริบทผล (Resulting Context) บรรยายถึงสภาวะที่เกิดขึ้นภายหลังจากที่ ได้มีการนำแบบรูปไปใช้อย่างประสบความสำเร็จแล้ว แบบอื่นที่เกี่ยวข้อง (Related Patterns) จะบอกถึงกระบวรการอื่นๆที่ สัมพันธ์ตรงกันแบบที่กล่าวถึง อาจเป็นลำดับขั้นหรือไดอาแกรมอื่นๆตัวอย่างเช่น รูปแบบการสื่อสาร รวมรูปแบบย่อยการรวมทีมโครงการ การกำหนดแนวทาง ร่วมกัน คำอธิบายข้อจำกัด

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

18 2.5 การประเมินการกระบวนการ (Process Assessment) กระบวนการประเมินเพื่อให้มั่นใจว่ามันตรงตามเกณฑ์เบื้องต้นได้รับการยอมรับในการจะเป็นนักวิศวกรรมซอฟต์แวร์ที่ประสบความสำเร็จดังรูป 2.5 แสดงความสัมพันธ์ ระหว่างกระบวรการซอฟต์แวร์ได้ถูกนำเสนอไว้หลายแนวทางดังนี้

19 วิธีประเมินมาตรฐาน CMMI สำหรับการปรับปรุงกระบวนการ อธิบายการจำลองการประเมินกระบวนการซึ่งรวมการเริ่มต้น การวินิจฉัย การลงมือทำ และการเรียนรู้วิธี SCAMPI นี้ใช้ CMMI เป็นพื้นฐานสำหรับการประเมิน การประเมินตามแบบ CMMI เพื่อปรับปรุงกระบวนการ ภายในบวกเทคนิคการวินิจฉัยเพื่อประเมินความสมบูรณ์ของซอฟต์แวร์หรือองค์กรโดยใช้ CMM เป็นตัวก่อนหน้า CMMI ที่กล่าวในหัวข้อ 2.3 เป็นฐานสำหรับการประเมิน สไปซ์ (SPICE หรือ ISO/IEC 15540) เป็นมาตรการกำหนดสิ่งที่ต้องทำในการประเมินกระบวนการซอฟต์แวร์ฏิบัติ ISO 9001:2000 เป็นมาตรฐานทั่วไปสำหรับองค์กรที่ต้องการปรับปรุงคุณภาพโดยรวมของผลิตภัณฑ์ระบบ องค์กรระหว่างประเทศว่าด้วยการมาตรฐานหรือไอโซ ได้พัฒนามาตรฐาน 9001:2000 เพื่อผลิตผลิตภัณฑ์ที่คุณภาพดีขึ้นซึ่งจะช่วยเพิ่มความพึงพอใจของลูกค้า ISO 9001/2000 ได้วางวัฏจักร วางแผน-ตรวจสอบ มาใช้ในเรื่องการจัดการคุณภาพของโครงการซอฟต์แวร์โดยอธิบายไว้ในแต่ละส่วนดังนี้ วางแผน (Plan) เป็นการวางวัตถุประสงค์ กิจกรรม และหน่วยงานย่อยของกรบวนการที่จำเป็นต่อการพัฒนาซอฟต์แวร์ที่มีคุณภาพสูงเพื่อให้ลูกค้าได้รับความพึงพอใจ

20 ทำ (Do) เป็นการนำกระบวนการซอฟต์แวร์ไปปฏิบัติ รวม กิจกรรมกรอบงานและกิจกรรมร่ม
ตรวจสอบ (Check) เป็นการตรวจสอบและวัดกระบวนการเพื่อให้ ได้คุณภาพคามต้องการ ปฏิบัติ (Act) เป็นหารทำกิจกรรมปรับปรุงกระบวนการซอฟต์แวร์ ซึ่งทำงานอย่างต่อเนื่อง เพื่อพัฒนากระบวนการให้ดีขึ้น

21 2.6 แบบจำลองกระบวนการส่วนบุคคลและแบบทีม (Personal and Team Process Model) กระบวนการซอฟต์แวร์ที่ดีที่สุดคือ กระบวนการที่เข้าถึงผู้คนที่จะปฏิบัติงานตรงตามความต้องการของทีมงานซึ่งทำงานวิศวกรรมซอฟต์แวร์ในเชิงอุดมคตินักวิศวกรรมซอฟต์แวร์แต่ละคนจะออกแบบกระบวนการที่เหมาะกับความต้องการของเขา แล้วในขณะเดียวกันตรงความต้องการของทีมองค์กรด้วยในทางกลับกัน ในฐานะทีม ทีมก็สร้างกระบวนการของทีมเองโดยต้องคำนึงถึงความต้องในระดับเล็กของแต่ละสมาชิกในทีมและความต้องการในระดับใหญ่คือองค์กรด้วย กระบวรการซอฟต์แวร์ส่วนบุคคล (Personal Software Process-PSP) นักพัฒนาซอฟต์แวร์ทุกคนต่างก็ใช้กระบวนการบางอย่างในการสร้างซอฟต์แวร์คอมพิวเตอร์ ถึงแม้ว่ากระบวนการนั้นอาจจะเป็นแบบส่งเดช ตามความพอใจอาจจะเปลี่ยนไปได้ทุกวัน อาจจะไม่มีประสิทธิภาพหรือประสิทธิผล หรือไม่แม้กระทั่งความสำเร็จ

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

23 2.6.2. กระบวนการซอฟต์แวร์แบบทีม (Team Software Process TSP)
เนื่องจากหลายๆโครงการซอฟต์แวร์ในระดับอุตสาหกรรมต้อง เกี่ยวข้องกับผู้ประกอบการหลายฝ่าย วัตต์ฮัมฟรีย์ (Watts Humphrey ) จึงได้ขยายแนวคิดของ PSP มาเป้นกระบวนการ ซอฟต์แวร์แบบทีม TSP โดยมีเป้าหมายเพื่อสร้างทีมโครงการแบบ อำนวยการด้วยตนเอง นั้นคือความสามารถจัดระเบียบและบริหาร เพื่อให้ได้ซอฟต์แวร์ที่คุณภาพสูงได้ด้วยตนเอง ฮัมฟรีย์กำหนด วัตถุประสงค์ของ TSP ไว้ดังนี้ สร้างทีมที่ อำนวยการด้วยตนเอง ซึ่งวางแผนและตรงงานสร้าง เป้าหมายและเป็นเจ้าของกระบวนการแผนต่างๆทีมเหล่านี้อาจเป็นทีม ด้านซอฟต์แวร์โดยเฉพาะหรือเป็นทีมผลิตภัณฑ์รวมโดยมีวิศวกรรม ประมาณ 3-2- คน แสดงให้ผู้จัดการเห็นว่าจะแนะนำและกระตุ้นทีมอย่างไรและจะช่วย ให้รักษาระดับการทำงานที่ดีไว้ได้อย่างไร เร่งการปรับปรุงกระบวนการซอฟต์แวร์โดยมุ่งทำให้ได้ CMMI ระดับ 5 ให้แนวทางในการปรับปรุงองค์กรที่มีความถ้วนสูง ช่วยให้เกิดการถ่ายทอดด้านทักษะของทีมระดับอุตสาหกรรม

24 2.7 เทคโนโลยีกระบวนการ (Process Technology) แบบจำลองกระบวนการทั่วไปที่กล่าวถึงในหัวข้อก่อนหน้า จึง ต้องได้รับการปรับใช้โดยทีมโครงการซอฟต์แวร์เครื่องมือเทคโนโลยี กระบวนการ ช่วยให้องค์กรซอฟต์แวร์สร้างแบบจำลองอัตโนมัติของ กรอบงานหรือกระบวนการทั่วๆไปชุดงานและกิจกรรมร่มที่กล่าวไว้ใน หัวข้อ 2.2 เราสามารถวิเคราะห์แบบจำลองเพื่อกำหนดการไหลของ งานและเพื่อศึกษาโครงสร้างกระบวนการแบบอื่นซึ่งอาจนำไปสู่เวลา หรือต้นทุนการพัฒนาซอฟต์แวร์ที่ลดลง 2.8 ผลิตภัณฑ์และกรบวนการ (Product and Process) ถ้ากระบวนการไม่ดีอาส่งผลต่อผลิตภัณฑ์สุดท้ายได้หากแต่การ วางใจกับกระบวนการมากเกินไปก่ออาจก่อให้เกิดอันตรายได้เช่นกัน ผลิตภัณฑ์และกระบวนการเป็นสิ่งที่ต้องไปด้วยกันศิลปินวาดภาพมี ความสุขในการวาดแต่ละลายเส้นพอๆกับภาพสำเร็จ นักเขียนมักมี ความสุขในการสร้างสรรค์คำใหม่ๆพอๆกับหนังสือที่เสร็จแล้วในทำนอง เดียวกัน นักพัฒนาซอฟต์แวร์จึงควรมีความสุขกับกระบวนการพัฒนา พอๆกับความสุขกับผลิตภัณฑ์ที่เป็นผลลัพธ์สุดท้าย

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