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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14 2.3แบบจำลองวุฒิภาวะและความสามารถเชิงบูรณาการซีเอ็มเอ็มไอ
( The Capability Maturity Model Integration CMMI) ระดับ 1 แบบทำงานได้ ทุกเป้าหมายของสาขาการะบวนการได้รับการ ตอบสนอง ภารกิจที่จำเป็นต่อการผลิตภัณฑ์ ที่กำหนดกำลังดำเนินไป ระดับ 2 แบบจัดการได้ คือแบบที่ผ่านเกณฑ์ของทุกระดับ I และทุก งานที่เกี่ยวข้องกับสาขาการบวนการทำงานได้ตามที่กำหนดไว้ในนโยบาย ขององค์กร ผู้ปฏิบัติงานทุกคนสามารถเข้าถึงทรัพยากรที่เพียงพอต่อการ ปฏิบัติงานของตน ระดับ 3 แบบกำหนดได้ ผ่านทุกเกณฑ์ในระดับ 2 นอกจากนี้ กระบวนการยังสามารถปรับแต่งเฉพาะงานตามแนวทางมาตรฐานของ องค์กร และกระบวนการยังสามารถให้ข้อมูลเกี่ยวกับชิ้นงานข้อมูลตัวจัด และข้อมูลการปรับปรุงกระบวนการอื่นๆ ระดับ 4 แบบจัดการได้เชิงปริมาณ นอกจากกดเกณฑ์ระดับ 3 แล้ว 4 นี้ต้องมีการควบคุมและปรับปรุงกระบวนการโดยใช้การประเมินการวัด และการประเมินเชิงปริมาณต้องมีการกำหนดวัตถุประสงค์เชิงปริมาณ สำหรับคุณภาพและการทำงานของกระบวนการ และใช้เป็นเกณฑ์ในการ บริหารกระบวนการ ระดับ 5 แบบเหมาะสมที่สุด นอกตากทุกเกณฑ์ในระดับ 4 แล้ว จะต้องมีการใช้วิธีเชิงปริมาณกับส่วนกระบวนการ เพื่อให้ได้ตามความ ต้องการของลูกค้าที่เปลี่ยนแปลงไปตลอดเวลา และเพื่อเพิ่มประสิทธิภาพ และประสิทธิผลของส่วนกระบวนการที่กำลังพิจารณา

15 2.3แบบจำลองวุฒิภาวะและความสามารถเชิงบูรณาการซีเอ็มเอ็มไอ
( The Capability Maturity Model Integration CMMI) CMMI นิยามแต่ละสาขากระบวนการในรูปแบบของ เป้าหมายเฉพาะ และวิธีปฏิบัติเฉพาะ ที่จำเป็นต่อการบรรลุเป้าหมายเหล่านี้ เป้าหมายเฉพาะระบุลักษณะที่ต้องมีหากต้องการให้กิจกรรมของสาขากระบวนการมีประสิทธิภาพ วิธีปฏิบัติเฉพาะจะช่วยปรับเปลี่ยนเป้าหมายไปสู่ชุดของกิจกรรมที่เกี่ยวข้องกับกระบวนการ

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

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

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

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

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

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

22 การประเมินการกระบวนการ Process Assessment)
วิธีประเมินมาตรฐาน CMMI สำหรับการปรับปรุง กระบวนการ อธิบายการจำลองการประเมินกระบวนการซึ่ง รวมการเริ่มต้น การวินิจฉัย การลงมือทำ และการเรียนรู้วิธี SCAMPI นี้ใช้ CMMI เป็นพื้นฐานสำหรับการประเมิน การประเมินตามแบบ CMMI เพื่อปรับปรุงกระบวนการ ภายในบวกเทคนิคการวินิจฉัยเพื่อประเมินความสมบูรณ์ของ ซอฟต์แวร์หรือองค์กรโดยใช้ CMM เป็นตัวก่อนหน้า CMMI ที่กล่าวในหัวข้อ การประเมินกระบวนการ เป็นฐาน สำหรับการประเมิน สไปซ์ (SPICE หรือ ISO/IEC 15540) เป็น มาตรการกำหนดสิ่งที่ต้องทำในการประเมินกระบวนการ ซอฟต์แวร์ฏิบัติ

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

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

25 กระบวรการซอฟต์แวร์ส่วนบุคคล (Personal Software Process-PSP)
นักพัฒนาซอฟต์แวร์ทุกคนต่างก็ใช้กระบวนการบางอย่างในการสร้างซอฟต์แวร์คอมพิวเตอร์ ถึงแม้ว่ากระบวนการนั้นอาจจะเป็นแบบส่งเดช ตามความพอใจอาจจะเปลี่ยนไปได้ทุกวัน อาจจะไม่มีประสิทธิภาพหรือประสิทธิผล หรือไม่แม้กระทั่งความสำเร็จ

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

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

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

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

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