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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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