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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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