วี. อิลลิน.

หัวหน้าฝ่ายบริการคุณภาพที่ TopSBI

“ถ้าเจ้าทำสิ่งใด

ผิด - ไม่จำเป็น
คาดหวังผลลัพธ์ที่ถูกต้อง"

ภูมิปัญญาจีนพื้นบ้าน

โซลูชันที่ครอบคลุมสำหรับงานประกันคุณภาพ เครื่องมือซอฟต์แวร์เกี่ยวข้องกับการพัฒนาและดำเนินการตามระบบการจัดการคุณภาพโดยเฉพาะ (ระบบการจัดการคุณภาพ - QMS). ในทางปฏิบัติของโลกนั้นเป็นระบบที่ยึดตามข้อกำหนดของมาตรฐานสากลที่แพร่หลายมากที่สุด ซีรี่ส์ ISO 9000 เนื่องจากกำหนดข้อกำหนดทั่วไปส่วนใหญ่ได้อย่างแม่นยำ รวมถึงข้อกำหนดสำหรับ PS และโดยทั่วไปแล้ว ได้กำหนดความสมบูรณ์เริ่มต้นของกระบวนการซึ่งจำเป็นต่อการปฏิบัติตามรูปแบบและมาตรฐานอุตสาหกรรมจำนวนมากในด้านไอที .

แต่สำหรับคำถามที่ว่าการแนะนำระบบคุณภาพและการรับรองที่ประสบความสำเร็จรับประกันการเปิดตัวผลิตภัณฑ์ที่มีคุณภาพหรือไม่ จำเป็นต้องตอบอย่างตรงไปตรงมาว่า "ไม่"

โดยเน้นว่า ISO 9000 เป็น "แนวคิดที่ดี" Gartner Group ขอแนะนำว่าการรับรอง ISO 9001 ถือเป็นจุดเริ่มต้นบนเส้นทางสู่คุณภาพเท่านั้น (1)

มันวาง "โครงกระดูก" ของระบบคุณภาพอย่างที่เป็นอยู่ และเติมระบบนี้ด้วย "กล้ามเนื้อ" (เนื้อหาระดับมืออาชีพที่อิงจากมาตรฐานและวิธีการที่พิเศษอยู่แล้วของอุตสาหกรรม เช่น CMM) สามารถให้ระดับคุณภาพที่ตรงกับการเติบโต ความต้องการของตลาด

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

ขั้นแรก พัฒนาและดำเนินการ QMS ตามแบบจำลอง ISO 9001:2000 (ท้ายที่สุดแล้ว บริษัทส่วนใหญ่ที่ตอนนี้อยู่ที่ระดับ 4 และ 5 ของ SW-CMM ได้ดำเนินการผ่านกระบวนการต่างๆ ให้สอดคล้องกับแบบจำลอง ISO ก่อน ตามแนวทางปฏิบัติ สิ่งนี้แสดงให้เห็น ตัวเลือกที่ดีที่สุดในแง่ของการจัดการการพัฒนา QMS และการลดความเสี่ยง)

จากนั้นจึงเริ่มพัฒนาและนำกระบวนการสำคัญของโมเดล SW-CMM และโมเดล CMMI ไปใช้หากจำเป็น

เพื่อให้เข้าใจว่าสิ่งนี้ถูกต้องอย่างไร เรามาเปรียบเทียบโมเดลเหล่านี้กัน

1. ทบทวนผู้สมัคร

ใช้จ่ายกันเถอะ รีวิวสั้นๆมาตรฐานยอดนิยมที่บริษัทไอทีใช้เพื่อเพิ่มประสิทธิภาพกระบวนการทางธุรกิจของตน

ISO9001.ที่นิยมมากที่สุดและโดยเฉพาะอย่างยิ่งในยุโรปคือ ISO 9001(2)

พร้อมกันอย่างมีระเบียบวินัยครบถ้วนตามระเบียบวินัยอาคาร ระบบที่ซับซ้อนด้านหนึ่งมาตรฐาน ISO 9001 ให้การก่อสร้าง ระบบองค์กร"จากบนลงล่าง": จากเป้าหมายขององค์กรและนโยบายขององค์กร - โครงสร้างองค์กรและการก่อตัวของกระบวนการทางธุรกิจและอื่น ๆ - การพัฒนาซ้ำ ๆ ของระบบองค์กรผ่านกลไกการวัดและปรับปรุง

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

องค์กรพัฒนาซอฟต์แวร์หลายแห่งประสบความสำเร็จในการใช้ชุดมาตรฐาน ISO 9000 ที่เป็นที่รู้จักนี้ รุ่นใหม่มาตรฐานของชุดนี้เปิดตัวในปี 2543 และมีแนวคิดอยู่แล้วเช่นแนวทางกระบวนการ การวิเคราะห์และการวัด การปรับปรุงกระบวนการ ยืมจากแบบจำลอง CMM และก่อนหน้านี้ไม่มีใน ISO 9000 เวอร์ชันก่อนหน้า จริงควรสังเกตว่ามาตรฐานของ ซีรีย์นี้เป็นสากล - พวกเขาไม่ได้เน้นที่อุตสาหกรรมเฉพาะใด ๆ ไม่คำนึงถึงลักษณะเฉพาะของทรงกลมไอทีและในแง่นี้แน่นอนว่าในแง่ของระดับคุณสมบัติพวกเขาจะด้อยกว่า CMM อย่างเห็นได้ชัด นอกจากนี้ ISO 9000 ไม่ได้หมายความถึงการไล่ระดับ (ระดับ) ของการปฏิบัติตามข้อกำหนดใดๆ และทำให้ยากต่อการพิจารณาความสามารถ "ที่แท้จริง" ขององค์กรและแนวทางการพัฒนาต่อไป

CMM(Capability Maturity Model) ได้รับการพัฒนาโดย Software Engineering Institute ที่ Carnegie Mellon University (USA) และอธิบายถึงกระบวนการพัฒนารูปแบบวุฒิภาวะ ซอฟต์แวร์ในสถานประกอบการ (3). ภายในกรอบของโมเดลนี้ สำหรับแต่ละบริษัท สามารถเปรียบเทียบระดับหนึ่ง (หนึ่งในห้าที่เป็นไปได้) ซึ่งบ่งชี้ถึงคุณภาพที่บรรลุได้ของกระบวนการพัฒนาซอฟต์แวร์ เนื่องจากมาตรฐานเหล่านี้ได้รับการพัฒนาเป็นหลักเพื่อปรับปรุงกระบวนการคัดเลือกผู้รับเหมาสำหรับกระทรวงกลาโหมสหรัฐฯ จึงมุ่งเน้นไปที่กระบวนการจัดการโครงการซอฟต์แวร์ ในขณะที่แง่มุมทางเทคนิคของการพัฒนาจะไม่ค่อยครอบคลุม

มีหลักปฏิบัติสำคัญ 316 ข้อใน SW-CMM v.1.1 (แบบจำลองความสามารถครบกำหนดสำหรับซอฟต์แวร์) แนวทางปฏิบัติที่สำคัญคือสิ่งที่ควรนำไปใช้ในองค์กรและสิ่งที่ทีมประเมินผลกระบวนการจะต้องใส่ใจ รวมเป็นพื้นที่ - Key Practices Areas (KPA) - เหล่านี้เป็นชุดของกระบวนการที่สัมพันธ์กันซึ่งเมื่อดำเนินการร่วมกันจะนำไปสู่ความสำเร็จของเป้าหมายบางชุด

CMMI(Capability Maturity Model Integration) - การพัฒนาเพิ่มเติมของโมเดล CMM ใน CMMI-SE / SW เวอร์ชัน 1.02 (CMMI สำหรับวิศวกรรมระบบ / วิศวกรรมซอฟต์แวร์) อาจเหมาะสมที่สุดสำหรับนักพัฒนา ระบบซอฟต์แวร์, - จำนวนแนวทางปฏิบัติหลักถึง 417 ครั้ง

แนวทางปฏิบัติหลักที่เพิ่มขึ้นนั้นเกี่ยวข้องกับจุดประสงค์ของการพัฒนา CMMI โดยแบบจำลองนี้ควรช่วยหลีกเลี่ยงปัญหาที่เกี่ยวข้องกับการใช้แบบจำลอง CMM เฉพาะอุตสาหกรรมต่างๆ

(ตั้งแต่ปี 1991 CMM ได้รับการพัฒนาสำหรับการใช้งานที่หลากหลาย ที่สำคัญที่สุดคือ:

แบบจำลองวุฒิภาวะของกระบวนการพัฒนาซอฟต์แวร์ (Capability Maturity Model for Software - SW-CMM)
- แบบจำลองกระบวนการครบกำหนดสำหรับการปรับรื้อระบบ (Electronic Industries Alliance Interim Standard - EIA/IS 731)
- แบบจำลองวุฒิภาวะของกระบวนการพัฒนาผลิตภัณฑ์แบบบูรณาการ Integrated Product Development Capability Maturity Model - IPD-CMM)

CMMI ถูกสร้างขึ้นจากโมเดลเหล่านี้ โดยได้ซึมซับสิ่งที่ดีที่สุดของโมเดลเหล่านี้ ขจัดความคลุมเครือในการตีความแนวคิดบางอย่างเนื่องจากการมีอยู่ของโมเดลต่างๆ มากมาย ดังนั้นจำนวนของแนวทางปฏิบัติหลักจึงเพิ่มขึ้นอย่างมาก)

เห็นได้ชัดว่านี่เป็นโมเดลที่ "หนัก" มากกว่าอย่างเห็นได้ชัด - ดูรูปที่ ข้าว. หนึ่งซึ่งยังไม่ได้รับการทดสอบอย่างเพียงพอในทางปฏิบัติ (เปิดตัวในปี 2545 เท่านั้น) ในแง่นี้ ในความคิดของฉัน เมื่อนำแบบจำลองไปใช้ อาจมีความเสี่ยงสูง ซึ่งเกี่ยวข้องกับการสูญเสียความเร็วของการพัฒนาซอฟต์แวร์อย่างไม่ยุติธรรม และการเพิ่มขึ้นของค่าแรงสำหรับการดำเนินงาน (และการสนับสนุน) ของ KPA ที่ดำเนินการพร้อมกันอย่างชัดเจน - ดู. รูปที่ 1 ในฐานะผู้ปฏิบัติงานที่สร้าง QMS ในบริษัทไอทีต่างๆ สามแห่งแล้ว สำหรับฉันดูเหมือนว่าในรูปแบบ CMMI ความสมดุลของสิ่งที่จำเป็นและเพียงพอนั้นถูกละเมิดอย่างชัดเจน - พนักงานของบริษัทไอที (และสิ่งนี้ในฐานะ กฎส่วนใหญ่เป็น "ศิลปินโค้ด" ง่ายๆ "จะไม่ยอมรับ" กฎข้อบังคับที่ควบคุมจำนวนดังกล่าว (มีความเสี่ยงสูงที่จะสร้าง "หมู่บ้าน Potemkin")!

ข้าว. 1 การเปรียบเทียบองค์ประกอบ KPA ในแบบจำลอง CMM และ CMMI

นอกจากนี้ การประเมิน CMMI จะมีราคาแพงกว่ามาก เนื่องจากได้รับอนุญาต SEI หัวหน้าประเมิน”จะมีจำนวนน้อยมาก และบริการเหล่านี้จะมีราคาแพงกว่าเมื่อประเมินความสอดคล้องกับรูปแบบ CMM

นอกจากนี้ ผู้เชี่ยวชาญจากต่างประเทศจำนวนมากในด้านการจัดการคุณภาพ (ซึ่งฉันเห็นด้วยอย่างยิ่งในขณะนี้) ค่อนข้างจะสงสัยเกี่ยวกับ CMMI ในบริบทของประโยชน์ที่จะนำไปใช้ในองค์กรขนาดเล็กและขนาดกลาง สำหรับรัสเซีย). ) มีความเห็นว่าหลังจากผ่านไประยะหนึ่ง SEI จะต้องปล่อย SW-CMM v.2 ที่ดัดแปลงแล้ว หรือดำเนินการขั้นตอนที่คล้ายกัน เหล่านั้น. หากตลาดไม่ยอมรับแบบจำลองและข้อกำหนดเบื้องต้นดังกล่าวมีอยู่แล้วในขณะที่เขียนบทความนี้ SEI จะต้องปรับให้เข้ากับความต้องการของตลาด

ในการเชื่อมต่อกับสิ่งที่กล่าวมา ดูเหมือนว่าเหมาะสมที่จะวิเคราะห์ความสมดุลที่กล่าวถึงแล้วของสิ่งที่จำเป็นและเพียงพอในแบบจำลอง QMS พื้นฐานทั้งหมดเหล่านี้

ลองวาดมันในพิกัดต่อไปนี้ (ดูรูปที่. ข้าว. 2) :

ระดับของการควบคุมกระบวนการพัฒนา - ให้แนวคิดนี้ - RP,

ความน่าจะเป็นที่จะบรรลุผลตามแผน - แสดงถึงแนวคิดนี้ - PQ.

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

ในทางคณิตศาสตร์ ค่าของอนุพันธ์: F(Q) = dPQ \ dRQ(เพิ่มประสิทธิภาพในการบรรลุคุณภาพ dPQด้วยการเพิ่มขึ้นของค่าชั่วโมงทำงานเพื่อรองรับการเติมเต็มความต้องการ dRQ) ลดลงตามลำดับในลำดับต่อไปนี้ : ISO 9000, CMM, CMMI.

ดังนั้น รูปที่ 2 อธิบายอย่างชัดเจนและเรียบง่าย:

ความนิยมของรุ่น ISO 9000,

ความถูกต้องของวิธีการ: ISO แรกและถ้าจำเป็น CMM

ความสงสัยบางประการเกี่ยวกับประสิทธิภาพของแบบจำลอง CMMI

ข้าว. 2 การวิเคราะห์ความสมดุลระหว่างระดับของกฎระเบียบและความน่าจะเป็นที่จะบรรลุผลตามแผน (ตามการประเมินของผู้เชี่ยวชาญของผู้เขียน)

ให้เราพิจารณาแนวทางอื่นที่ใช้กันอย่างแพร่หลายในบริษัทไอที และจะกล่าวถึงด้านล่างเมื่อวิเคราะห์ประเด็นของแนวทางปฏิบัติในการนำระบบ QMS ไปใช้

นี่คือ PMBoK(คู่มือการ การจัดการโครงการองค์ความรู้) คือ โครงการสถาบันการจัดการซึ่งได้ซึมซับความรู้ที่สั่งสมมาในด้านการบริหารโครงการ เอกสารเวอร์ชันล่าสุดเผยแพร่ในปี 2543 และในขณะเดียวกันก็ได้รับสถานะมาตรฐานของ American Standards Institute ANSI (แม้ว่ามาตรฐาน ANSI และ IEEE จะถือว่าเป็นทางการของอเมริกา แต่ส่วนใหญ่เป็นแบบสากลโดยพฤตินัย) คุณลักษณะที่สำคัญของ PMBoK คือการพิจารณาการจัดการโครงการในความหมายทั่วไป โดยไม่ต้องเชื่อมโยงกับสาขาวิชาเฉพาะ เช่น ไอที ดังนั้นจึงไม่สามารถนำไปใช้ด้วยตนเองได้ ด้านล่างนี้ เราจะพิจารณาว่าสิ่งนี้มีผลกระทบอย่างไรเมื่อใช้ร่วมกับ ISO 9000.

ให้เราพิจารณาว่าข้อกำหนดของมาตรฐาน ISO 9001:2000 ที่ได้รับความนิยมอยู่แล้วนั้นสัมพันธ์กับคุณสมบัติทั่วไปของแบบจำลอง HMM ที่ได้รับความนิยมเพิ่มขึ้นอย่างไร {3}- ซม. ข้าว. 3.

ข้าว. 3. ความสอดคล้องระหว่างคุณสมบัติทั่วไปของ CMM กับองค์ประกอบของ ISO 9001:2000

แต่ละระดับของ HMM ตามที่กล่าวไว้ข้างต้น มีลักษณะเป็นชุดของ พื้นที่ของกระบวนการหลัก - KPA (พื้นที่กระบวนการหลัก) -ซม. รูปที่ 3ความสำเร็จของเป้าหมายทั้งหมดภายใน KPAสำหรับระดับหนึ่ง CMM จะกำหนดความสอดคล้องขององค์กรในระดับนี้ ถ้าอย่างน้อยหนึ่งเป้าหมายอย่างน้อยหนึ่ง KPAสำหรับระดับ CMM ไม่สำเร็จ องค์กรก็ไม่สามารถบรรลุระดับ CMM นี้ได้ KPAสามารถแบ่งออกเป็นสามประเภท: ผู้จัดการ , องค์กร และ ให้ (ซม. ข้าว. 4).

CMM ไม่ได้กำหนดกระบวนการทั้งหมดที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ มันเน้นเฉพาะที่จำเป็นเพื่อให้บรรลุระดับของ SMM และรวมอยู่ใน KPA. แต่ละ KPAแบ่งออกเป็น 5 ลักษณะทั่วไป: มุ่งมั่นที่จะดำเนินการ (แสดงความคิดเห็นที่จะดำเนินการ); ความสามารถในการดำเนินการ; กิจกรรมที่ทำ; การวัดและการวิเคราะห์ (การวัดและการวิเคราะห์); กำลังตรวจสอบการใช้งาน

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

การดำเนินการตามลำดับของคุณสมบัติทั่วไปจะนำวงจรการปรับปรุงกระบวนการทางธุรกิจไปใช้จริง (การปรับปรุงกระบวนการทางธุรกิจ - BPI-ซม. ข้าว. 5.), เช่น. การปรับปรุงกระบวนการทางธุรกิจอย่างต่อเนื่อง (BP)

ข้าว. 5. วัฏจักรของการปรับปรุงกระบวนการทางธุรกิจอย่างต่อเนื่องตามแบบจำลอง CMM และ ISO 9000:2000

ความปรารถนาที่จะได้รับใบรับรองความสอดคล้องในเวลาที่สั้นที่สุดทำให้บริษัทที่ปรึกษาและผู้เชี่ยวชาญที่เกี่ยวข้องในการจัดการคุณภาพต้องใช้ความยืดหยุ่นและข้อกำหนดของกรอบงานของแบบจำลองระดับสูงทั้งหมดข้างต้นเพื่อจุดประสงค์ "เห็นแก่ตัว" ของตนเอง
จากการบังคับใช้เหตุการณ์นี้ องค์กร เช่น ที่ได้รับใบรับรอง ISO 9000:2000 มีชุดกระบวนการขั้นต่ำที่จำเป็นสำหรับการปฏิบัติตาม ISO 9001 เท่านั้น และไม่ใช่กระบวนการทั้งหมดที่บริษัทจำเป็นต้องดำเนินการ อย่างมีประสิทธิภาพ - ดูด้านล่าง ข้าว. 2. นอกจากนี้ ระดับรายละเอียดของกระบวนการอาจไม่เพียงพอสำหรับความเข้าใจที่ชัดเจนว่าเกิดอะไรขึ้นภายในกระบวนการ และใครเป็นผู้รับผิดชอบงานใดภายในกระบวนการ
ที่ กรณีที่ดีที่สุดมีโครงการทดสอบเพียงไม่กี่โครงการเท่านั้นที่ผ่านขั้นตอนใหม่ และหลังจากผ่านไประยะหนึ่งก็เห็นได้ชัดว่าต้องแก้ไขและเพิ่มเติม บ่อยครั้งทันทีหลังจากการรับรอง QMS กระบวนการต่างๆ จะถูกลืมไปจนกระทั่งการตรวจสอบเชิงสังเกตครั้งต่อไป โดยลืมเกี่ยวกับการใช้จ่าย ทรัพยากรทางการเงินและความกระตือรือร้นของพนักงาน
แท้จริงแล้ว เมื่อคุณทำหน้าที่เป็นผู้ตรวจสอบอิสระ เป็นการยากมากที่จะพิสูจน์ว่าระดับรายละเอียดกระบวนการที่ยอมรับนั้นไม่เพียงพอสำหรับการทำงานที่มีประสิทธิภาพของ QMS ของบริษัทอย่างชัดเจน แต่เป็นการยากมากที่จะพิสูจน์สิ่งที่ตรงกันข้ามในเวลาที่กำหนดสำหรับการตรวจสอบ ISO 9000 (ซึ่งสามารถนำมาใช้ได้สำเร็จเมื่อคัดค้านผู้ตรวจสอบ) การปฏิบัติแสดงให้เห็นว่าเป็นไปไม่ได้ที่จะสร้างกระบวนการที่มีประสิทธิภาพอย่างรวดเร็วแม้ในระดับที่ 3 ของวุฒิภาวะ (เช่นเดียวกับกระบวนการที่ยึดตาม ISO 9000)
เพื่อให้บรรลุสิ่งนี้ ไม่เพียงพอที่จะอธิบายกระบวนการโดยคำนึงถึงข้อกำหนดของแบบจำลองที่เลือก ปัญหาหลักอยู่ที่ว่า ออกแบบวัฒนธรรมการผลิตใหม่ภายในองค์กร .

และเป็นไปไม่ได้ที่จะทำเช่นนี้ด้วยการตัดสินใจอย่างแน่วแน่ของผู้นำ นั่นคือเหตุผลที่แนวทางที่กำหนดไว้ใน CMM นั้นทำได้จริงและสมจริงกว่าในรุ่น ISO 9000 - ดู ข้าว. 5.

ให้เราพิจารณาว่าในทางปฏิบัติแล้วจะสร้าง QMS ที่เข้ากันได้กับทั้งสองรุ่นได้อย่างไร

การประเมินโดยผู้เชี่ยวชาญเกี่ยวกับระดับความครอบคลุมของกระบวนการ CMM ที่สำคัญตามข้อกำหนดของ ISO 9000:2000 ตามการประเมินของผู้เขียน CMM (4) แสดงไว้ใน รูปที่ 6.

การประเมินนั้นดำเนินการตามสองพิกัด:

ระดับความพร้อมใช้งาน (เป็น%) ของการปฏิบัติตามกระบวนการพัฒนา (SWP) ที่มีระดับวุฒิภาวะภายใน CMM - " ความพอเพียง";

ระดับความเป็นไปได้ (เป็น%) ของความพอเพียง ซึ่งให้ ISO 9000:2000 - " ความเป็นไปได้".

ตามที่เห็นจาก ข้าว. 6,ข้อกำหนด ISO 9000:2000 สร้าง โอกาสที่แท้จริงเพื่อให้ถึงระดับวุฒิภาวะของ SWP ที่สูงกว่า (CMM ระดับ 5)

อย่างไรก็ตาม ในแง่ของการรับรองความสมบูรณ์ของ SWP อย่างน้อยระดับที่สาม (CMM ระดับ 3) นั้น QMS ตามแบบจำลอง ISO 9000:2000 จำเป็นต้องได้รับการปรับปรุงเล็กน้อย กล่าวคือ เพื่อพัฒนาและดำเนินการตามขั้นตอนขององค์กรอีกสองขั้นตอน ( นิยามกระบวนการขององค์กรและเน้น) และขั้นตอน การจัดการทั่วไป (การจัดการซอฟต์แวร์แบบบูรณาการ ), เนื้อหาที่ไม่ยากสำหรับบริษัทไอทีใดๆ

แต่เป็นไปได้และจำเป็นต้องดำเนินการต่อไป (CMM ระดับ 4) - ตัวอย่างเช่นในวงเล็บคือการประเมินของผู้เขียนบทความนี้ (ในพิกัดเดียวกัน - ความพร้อมใช้งานและความสามารถ) ซึ่งสอดคล้องกับ QMS ตามมาตรฐาน ISO 9000 :แบบจำลอง 2000 ซึ่งภูมิทัศน์กระบวนการ QMS เสริมด้วยกระบวนการจัดการโครงการตามข้อกำหนดของมาตรฐานอื่นที่กล่าวถึงข้างต้นแล้ว พีเอ็มโบก- สิ่งนี้จะช่วยให้คุณเพิ่มความเป็นผู้ใหญ่ได้อย่างมาก SWP, เช่น:

การตรวจสอบความคืบหน้าของโครงการ (การติดตามและกำกับดูแลโครงการซอฟต์แวร์)

• การวางแผนโครงการ (การวางแผนโครงการซอฟต์แวร์);

การจัดการซอฟต์แวร์ทั่วไป (การจัดการซอฟต์แวร์แบบรวม);

การจัดการกระบวนการผ่านการประเมินเชิงปริมาณ (การจัดการกระบวนการเชิงปริมาณ)

ข้าว. 6. การประเมินโดยผู้เชี่ยวชาญเกี่ยวกับระดับความครอบคลุมของกระบวนการ CMM ที่สำคัญตามข้อกำหนดของ ISO 9000:2000

ตามที่เห็นจาก รูปที่ 6., โมเดล CMM ตามหลักการนั้นใกล้เคียงกับ QMS ที่สร้างขึ้นตามมาตรฐาน ISO 9001:2000 และเสริมด้วยกระบวนการจัดการโครงการตาม PM BoK..

เพราะไม่ได้ทำ งานพิเศษด้วยการรับรองพร้อมกันตาม ISO 9000 และการประเมินที่ตามมาตาม CMM ฉันขอแนะนำว่าเมื่อกำหนดกระบวนการผลิตของคุณ ให้รวม (หรืออาจจำกัดตัวคุณเองไว้สำหรับพวกเขา - เพราะสิ่งเหล่านี้คือกระบวนการผลิตสำหรับบริษัทไอที!) ทั้งหมดนี้มีความจำเป็น ในรูปแบบ CMM KPA ดังนั้นบริษัทพร้อมกัน:

ตรงตามความต้องการ ISO 9001:2000การดำเนินการตามแนวทางกระบวนการ

เอกสารที่จำเป็นทั้งหมด CMMกระบวนการ ( KPA);

ตรงตามข้อกำหนดที่สำคัญหลายประการ ISO 9001:2000เช่น:

การจัดการกระบวนการตามเมตริก (การจัดการกระบวนการเชิงปริมาณ);

การจัดการซัพพลายเออร์ตามการจัดการผู้รับเหมาช่วง ( ซอฟต์แวร์การจัดการผู้รับเหมาช่วง );

การวิเคราะห์ความต้องการของผู้บริโภคตาม การจัดการความต้องการ (การจัดการความต้องการ );

การจัดการทรัพยากรมนุษย์ตาม โปรแกรมการฝึกอบรมพนักงาน (โปรแกรมการฝึกอบรม );

การจัดการการสื่อสารขึ้นอยู่กับ การสร้างแบบจำลองทางการ กระบวนการขององค์กร (นิยามกระบวนการขององค์กร );

เปิดตัวกลไกการปรับปรุง (วางแผน-ทำ-ตรวจสอบ-ดำเนินการ)กระบวนการที่อธิบายไว้ทั้งหมด (SWP)ผ่านการดำเนินการอย่างต่อเนื่องของทั้งห้า คุณสมบัติทั่วไป-ซม. ข้าว. 5.

ดังนั้น หากเราใช้ KPA CMM เป็น BP และใช้ข้อกำหนดสำหรับขั้นตอนการจัดการโครงการพัฒนา PS ป.ป.ช.จากนั้น QMS ที่สร้างขึ้นในลักษณะนี้สามารถประเมินได้อย่างเต็มที่บน CMM ระดับ 4 - ดู. ข้าว. 7.

ข้าว. 7. โครงการบรรลุ CMM ระดับ 4 เมื่อใช้แบบจำลอง QMS ตาม ISO 9000 และคู่มือ PM BoK 2000

โดยสรุป ด้วยเหตุผลของความชัดเจน (ในสไตล์ของผู้เขียน) ฉันขอนำเสนอโครงร่างสำหรับการทำงานของ QMS ของบริษัทไอทีที่มีการใช้งานแบบจำลอง ISO 9000 และ CMM ที่สอดคล้องกัน - ดูรูปที่ ข้าว. แปด.

ข้าว. 8. แบบแผนของการทำงานของ QMS ด้วยการใช้งานที่สอดคล้องกันของแบบจำลอง ISO 9000 และ CMM (การกำหนดสไตล์ของผู้เขียน)

สิ่งสำคัญคือต้องเข้าใจว่าทั้ง CMM และ ISO 9001:2000 เป็นเพียงเครื่องมือสำหรับการปรับปรุงอย่างต่อเนื่อง

ดังนั้น การรับรองตามมาตรฐาน ISO 9001:2000 และการยืนยันใบรับรองควรมีส่วนช่วยในการเติบโตของคุณภาพของกระบวนการของบริษัท ซึ่งเกณฑ์ในการประเมินการเติบโตของคุณภาพของกระบวนการคือการออกจากบริษัทไปสู่ระดับใหม่ บีพี,นั่นคือการประเมินของพวกเขาเป็นไปตามรูปแบบอย่างแน่นอน CMM {3}.

วรรณกรรม

"การประเมินคุณภาพซอฟต์แวร์", V. Lipaev, Sinteg, 2001

ISO 9001:2000. ระบบการจัดการคุณภาพ ความต้องการ.

Paulk M.C. , Curtis B. , Chrissis M.B. , Weber C.V. รุ่นความสามารถครบกำหนดสำหรับซอฟต์แวร์ (SW-CMM) เวอร์ชัน 1.1 // CMU/SEI-93-TR-024, กุมภาพันธ์ 2536

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

เครื่องมือที่ใช้งานได้จริงที่ยอดเยี่ยมที่สร้างขึ้นภายในกรอบของ แนวทางกระบวนการไปที่คำอธิบายกิจกรรม องค์กรออกแบบ โดยเฉพาะองค์กรที่พัฒนา ระบบข้อมูลสาธิตวิธีการ HMM CMM ย่อมาจาก Capability Maturity Model ซึ่งหมายถึง "แบบจำลองความสมบูรณ์ของระบบการจัดการ" คร่าวๆ ในวรรณคดี CMM มักถูกเรียกว่าแบบจำลองวุฒิภาวะขององค์กร และฉันจะปฏิบัติตามประเพณีนั้นเช่นกัน

ประวัติความเป็นมาของ SMM มีดังนี้ ในช่วงปลายยุค 80 ศตวรรษที่ผ่านมากระทรวงกลาโหมสหรัฐสั่งให้สถาบันวิศวกรรมซอฟต์แวร์ 1Eng SEI - สถาบันวิศวกรรมซอฟต์แวร์มหาวิทยาลัย Carnegie Mellon กำลังทำงานเกี่ยวกับระบบเกณฑ์การคัดเลือกผู้รับเหมาช่วงในโครงการพัฒนาซอฟต์แวร์ งานเสร็จสมบูรณ์ในปี 2534 และผลที่ได้คือ CMM เราต้องจองทันทีว่าโมเดลไม่มีการเงิน เศรษฐกิจ การเมือง องค์กร เกณฑ์การคัดเลือกผู้รับเหมาช่วงรวมถึงเกณฑ์สำหรับความเป็นไปได้ในการเข้าทำงานลับ (อาจไม่ได้กำหนดงานดังกล่าว) เรากำลังพูดถึงแต่เกณฑ์ที่อธิบายความสามารถของผู้รับเหมาช่วงที่มีศักยภาพในแง่ของการพัฒนาระบบซอฟต์แวร์

โครงสร้าง CMM

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

อัสสัมชัญ 1. มีวุฒิภาวะที่แตกต่างกันในเชิงคุณภาพ องค์กรออกแบบกำลังพัฒนา ระบบข้อมูล(มีห้าระดับดังกล่าวในแบบจำลอง HMM)

อัสสัมชัญ 2. องค์กรพัฒนาใดสนใจที่จะก้าวไปสู่ระดับวุฒิภาวะที่สูงขึ้น (ไม่เพียงเพื่อเพิ่มโอกาสในการต่อสู้เพื่อสัญญาของกระทรวงกลาโหมเท่านั้น แต่ยังเพื่อจุดประสงค์ในการปรับปรุงของตนเองด้วย)

อัสสัมชัญ 3. การเปลี่ยนแปลงเป็นไปได้เฉพาะในระดับถัดไปตามลำดับ เป็นไปไม่ได้ที่จะ "กระโดด" ข้ามระดับ (แม่นยำยิ่งขึ้นความเสี่ยงสำหรับองค์กรเพิ่มขึ้นอย่างรวดเร็วในเวลาเดียวกัน)

ดังนั้น ระดับต่างๆ จึงก่อตัวเป็น "บันได" ซึ่งองค์กรจะเพิ่มขึ้นเป็น การพัฒนาตนเอง. แต่ละระดับมีลักษณะเฉพาะด้วยองค์ประกอบและคุณสมบัติบางอย่างของกระบวนการขององค์กร SMM "Level Ladder" ได้รับการยอมรับและเผยแพร่อย่างกว้างขวาง นี่คือสิ่งที่เธอดูเหมือน

ระดับ 1 "ระดับเริ่มต้น". กระบวนการผลิตโดยรวมมีลักษณะเฉพาะว่าถูกสร้างขึ้นทุกครั้งสำหรับโครงการใดโครงการหนึ่งโดยเฉพาะ และบางครั้งก็ดูวุ่นวาย มีการกำหนดกระบวนการเพียงไม่กี่ขั้นตอนเท่านั้น และความสำเร็จของโครงการขึ้นอยู่กับความพยายามของแต่ละบุคคล

ระดับ 2 "ทำซ้ำได้". กระบวนการจัดการโครงการหลักได้รับการจัดตั้งขึ้น ช่วยให้คุณสามารถติดตามต้นทุน ตรวจสอบตารางงาน และฟังก์ชันการทำงานของโครงการที่สร้างขึ้น ซอฟต์แวร์โซลูชั่น. กำหนดระเบียบวินัยกระบวนการที่จำเป็นในการทำซ้ำความสำเร็จที่ผ่านมาในโครงการพัฒนาแอปพลิเคชันที่คล้ายคลึงกัน

ระดับ 3 "แน่นอน". กระบวนการผลิตได้รับการจัดทำเป็นเอกสารและเป็นมาตรฐานสำหรับทั้งการจัดการและวิศวกรรม กระบวนการนี้ถูกรวมเข้ากับกระบวนการผลิตมาตรฐานขององค์กร โครงการทั้งหมดใช้เวอร์ชันที่กำหนดเองที่ได้รับอนุมัติของกระบวนการปฏิบัติงานมาตรฐานขององค์กร

ระดับ 4 "จัดการ". มีการรวบรวมตัวบ่งชี้เชิงปริมาณโดยละเอียดของกระบวนการผลิตและคุณภาพของผลิตภัณฑ์ที่สร้างขึ้น ทั้งกระบวนการผลิตและผลิตภัณฑ์ได้รับการประเมินและควบคุมจากมุมมองเชิงปริมาณ

ระดับ 5 "การเพิ่มประสิทธิภาพ". การปรับปรุงกระบวนการอย่างต่อเนื่องทำได้โดยผ่านเชิงปริมาณ ข้อเสนอแนะด้วยกระบวนการและการนำความคิดและเทคโนโลยีขั้นสูงไปปฏิบัติ

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

ยิ่งกว่านั้นก็คือเรื่องของเทคโนโลยี มีการกำหนดโครงสร้างของแบบจำลอง (รูปที่ 7.1) ให้คำจำกัดความ และความเพียรพยายามเริ่มอธิบายแต่ละกระบวนการในแต่ละระดับอย่างแม่นยำ เพื่อประเมินคุณค่าในทางปฏิบัติของสิ่งที่ได้ทำไปแล้ว เรามาดูส่วนหนึ่งของเส้นทางนี้กัน

ข้าว. 7.1.

ในรูป 7.1 มีแนวคิดดังต่อไปนี้

กลุ่มกระบวนการสำคัญ. ตามที่ระบุไว้ใน (Paulk, et al., 1995) "กระบวนการหลักแต่ละกลุ่มกำหนดกลุ่มของกิจกรรมที่เกี่ยวข้อง ซึ่งเป็นผลมาจากการบรรลุเป้าหมายชุดหนึ่งซึ่งมีนัยสำคัญในการเพิ่มผลผลิตของกระบวนการผลิต สำหรับ ตัวอย่างสำหรับกลุ่มของกระบวนการที่สำคัญ " การจัดการความต้องการ"(ดูรูปที่ 7.2) เป้าหมายคือการกระทบยอดความต้องการของโครงการพัฒนาซอฟต์แวร์ระหว่างลูกค้าและนักพัฒนา"

ไม่อยู่ใน CMM กระบวนการส่วนบุคคล. แต่มีงานแยกต่างหากที่เรียกว่าหลักปฏิบัติ (ดูด้านล่าง) ซึ่งเชื่อมต่อกันด้วยอินพุตและเอาต์พุตระหว่างกันและทำหน้าที่เป็นแหล่งข้อมูลสำหรับกระบวนการสร้าง CMM ไม่ได้ให้คำแนะนำเกี่ยวกับวิธีการจัดโครงสร้างกระบวนการ เช่น การเชื่อมโยงแนวทางปฏิบัติที่สำคัญเข้ากับลำดับเชิงตรรกะ ชุดของหลักปฏิบัติเรียกว่ากลุ่มกระบวนการหลัก

ข้าว. 7.2.

กลุ่มของกระบวนการหลักใน CMM จะถูกจับคู่กับระดับวุฒิภาวะ (รูปที่ 7.2) กล่าวคือ การปฏิบัติทั้งหมดในระดับหนึ่งจะโต้ตอบกันเท่านั้น และไม่โต้ตอบกับการปฏิบัติในระดับอื่น สิ่งนี้ช่วยให้คุณรับประกันประสิทธิภาพการทำงานของกระบวนการทั้งหมดในระดับเฉพาะ ดังนั้น สัมพันธ์ระดับกับขั้นตอนที่สมบูรณ์ของการพัฒนาองค์กร

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

เป้าหมาย. เป้าหมายใน CMM ไม่เกี่ยวข้องกับกระบวนการ แต่เกี่ยวข้องกับกลุ่มของกระบวนการหลัก ดังที่กล่าวไว้ข้างต้น บรรลุเป้าหมายโดยการดำเนินการตามหลักปฏิบัติที่สำคัญ ใน CMM การบรรลุเป้าหมายหมายความว่า ประการแรก หลังจากดำเนินการตามหลักปฏิบัติแล้ว จะได้รับผลลัพธ์ที่ต้องการ และประการที่สอง จะได้รับค่อนข้างสม่ำเสมอ วิธีการบรรลุวัตถุประสงค์ของกลุ่มกระบวนการหลักอาจแตกต่างกันไปในแต่ละโครงการเนื่องจากความแตกต่างใน สาขาวิชาหรือสิ่งแวดล้อม

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

บท. ส่วนต่างๆ (มีห้าส่วนในแต่ละระดับและเหมือนกันเสมอ) แสดงถึงคุณสมบัติของกลุ่มของกระบวนการหลักที่ต้องดำเนินการในระดับที่สอดคล้องกัน คุณสมบัติเหล่านี้อธิบายวิธีการดำเนินการตามกระบวนการและขอบเขตที่กระบวนการเหล่านั้นถูกกฎหมายในองค์กร กล่าวคือ ได้รับการอนุมัติอย่างเป็นทางการและประสานงานกับขั้นตอน นโยบาย และกระบวนการอื่นๆ ขององค์กร นี่คือห้าส่วน

ภาระผูกพันในการปฏิบัติงาน

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

ข้อกำหนดเบื้องต้น

อธิบายข้อกำหนดเบื้องต้นที่ต้องปฏิบัติตามในโครงการหรือองค์กรสำหรับการดำเนินการตามขั้นตอนการผลิตที่มีความสามารถ มักจะเกี่ยวข้องกับทรัพยากร โครงสร้างองค์กรและการฝึกอบรมที่จำเป็น

อยู่ระหว่างดำเนินการ

ส่วนการดำเนินการที่อยู่ระหว่างดำเนินการจะอธิบายถึงงานสำคัญที่ต้องดำเนินการในระดับนี้ การดำเนินการที่ดำเนินการโดยทั่วไปรวมถึงการสร้างแผนและการดำเนินการเฉพาะ การดำเนินการและการติดตามงาน และการดำเนินการแก้ไขตามความจำเป็น

การวัดและการวิเคราะห์

ส่วน "การวัดและ

“กระบวนการหลักแต่ละกลุ่มแสดงออกโดยแนวปฏิบัติหลักซึ่งการดำเนินการดังกล่าวมีส่วนทำให้บรรลุเป้าหมายของกลุ่มแนวทางปฏิบัติที่สำคัญจะอธิบายถึงโครงสร้างพื้นฐานและการดำเนินงานที่มีส่วนร่วมมากที่สุดในการนำไปปฏิบัติอย่างมีประสิทธิผลและการจัดตั้งกลุ่มกระบวนการหลัก

หลักปฏิบัติแต่ละข้อประกอบด้วยประโยคเดียว มักตามด้วยคำอธิบายโดยละเอียดที่อาจรวมถึงตัวอย่างและคำอธิบาย แนวปฏิบัติหลัก บางครั้งเรียกว่าหลักปฏิบัติหลัก ระดับสูงกำหนดนโยบาย ขั้นตอน และการดำเนินงานขั้นพื้นฐานสำหรับกลุ่มกระบวนการหลัก ส่วนประกอบ คำอธิบายโดยละเอียดมักเรียกว่าการปฏิบัติย่อย”

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

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

ในคำจำกัดความของระดับ (ดูรูปที่ 7.2) สิ่งเช่น "กระบวนการผลิต" ปรากฏขึ้น นอกจากนี้ยังมีอยู่ในคำจำกัดความของกลุ่มกระบวนการสำคัญ และนี่ไม่ใช่เรื่องบังเอิญ กระบวนการผลิตหรือที่เรียกว่า CMM อย่างเหมาะเจาะ Standard กระบวนการผลิตองค์กร (OSS) เป็นหนึ่งในแนวคิดหลักของโมเดลทั้งหมด

ในเดือนพฤศจิกายน พ.ศ. 2529 American Software Engineering Institute (SEI) ร่วมกับ Mitre Corporation ได้เริ่มพัฒนาแบบสำรวจความสมบูรณ์ของกระบวนการพัฒนาซอฟต์แวร์ซึ่งมีจุดมุ่งหมายเพื่อช่วยปรับปรุงกระบวนการภายใน

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

ในเดือนกันยายน พ.ศ. 2530 SEI ได้เผยแพร่บทสรุปของกระบวนการพัฒนาซอฟต์แวร์ที่อธิบายระดับวุฒิภาวะ ตลอดจนแบบสอบถามที่ออกแบบมาเพื่อระบุส่วนต่างๆ ในบริษัทที่ต้องการการปรับปรุง อย่างไรก็ตาม บริษัทส่วนใหญ่ถือว่าแบบสอบถามนี้เป็น แบบสำเร็จรูปด้วยเหตุนี้ หลังจาก 4 ปี แบบสอบถามได้เปลี่ยนเป็นแบบจำลองจริง นั่นคือ Capability Maturity Model for Software (CMM) CMM เวอร์ชันแรก (เวอร์ชัน 1.0) ซึ่งเผยแพร่ในปี 1991 ได้รับการแก้ไขในปี 1992 โดยผู้เข้าร่วมการประชุมเชิงปฏิบัติการ ซึ่งมีผู้เชี่ยวชาญด้านซอฟต์แวร์ประมาณ 200 คน และสมาชิกของชุมชนนักพัฒนาเข้าร่วม

ส่งผลให้ มาตรฐาน CMM, เวอร์ชัน 1.1 ซึ่งยังคงใช้งานอยู่ทั่วโลก

ข้าว. 1. ผลกระทบระดับโลกจากการใช้ SMM

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

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

ข้าว. 2. หลักการก้าวหน้าในระดับวุฒิภาวะ: โอกาสในการพัฒนาองค์กร

นี่คือลักษณะสำคัญของแต่ละระดับ:

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

บทนำสู่ SW-CMM

(การปรับปรุงวุฒิภาวะของกระบวนการพัฒนาซอฟต์แวร์โดยอิงตาม Software Engineering Institute Capability Maturity Model for Software)

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

การปรับปรุงความโปร่งใสของกระบวนการผลิตที่มีอยู่

การเพิ่มผลผลิตของกระบวนการและบริษัทโดยรวม

ลดต้นทุนการผลิตและปริมาณการผลิตที่ "ซ่อนเร้น" ที่มีอยู่

ปรับปรุงชื่อเสียงของบริษัทในสภาพแวดล้อมแบบมืออาชีพ

การเปิดตลาดใหม่สำหรับผลิตภัณฑ์

2.1 ต้นทุน ระยะเวลา และผลลัพธ์ สถิติอุตสาหกรรม
2.2 ผลตอบแทนจากการลงทุนใน CMM

3.1 TQM (การจัดการคุณภาพโดยรวม), SPI (การปรับปรุงกระบวนการซอฟต์แวร์) และแนวทางปฏิบัติทางธุรกิจที่ดีที่สุดซึ่งเป็นพื้นฐานของ CMM
3.2 แนวคิดพื้นฐานทีคิวเอ็ม การประยุกต์ใช้แนวทาง TQM ในการผลิตผลิตภัณฑ์ซอฟต์แวร์
3.3 ประโยชน์และความเสี่ยงของแบบจำลองการปรับปรุงกระบวนการ CMM
3.4 แนวคิดของกระบวนการ องค์ประกอบหลักของแนวทางกระบวนการ
3.5 ระดับวุฒิภาวะของกระบวนการ

9.1 ระบบมาตรฐานอุตสาหกรรมไอที (Roadmap)
9.2 ความสัมพันธ์ของ ISO กับ CMM, กระบวนการที่เป็นหนึ่งเดียวที่มีเหตุผล, การจัดการโครงการ
แอปพลิเคชัน 9.3 CMM สำหรับองค์กรขนาดเล็ก
9.4 สิ่งที่ไม่อยู่ใน SMM
9.5 เอกสารและกระบวนการ

10.1 การตรวจสอบขั้นสุดท้ายของ SW-CMM จำหน่ายในโลก. ปัญหาหลัก
10.2 CMMI (การรวมโมเดลความสามารถครบกำหนด) - การพัฒนาเพิ่มเติมของโมเดล CMM

ชุดสไลด์ เอกสารการฝึกปฏิบัติ วัสดุเพิ่มเติมสำหรับการศึกษาด้วยตนเอง

ชุดเอกสารที่สมบูรณ์เกี่ยวกับ SW-CMM (ข้อความของมาตรฐาน วิธีการประเมิน สถิติอุตสาหกรรม ตัวอย่างเอกสาร)

หลักสูตรภาคปฏิบัติเกี่ยวกับเทคโนโลยีการนำแบบจำลอง SW-CMM ไปใช้ในบริษัทไอที

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

หลักสูตรนี้มีไว้สำหรับ:
หลักสูตรนี้จัดทำขึ้นสำหรับผู้จัดการขององค์กรและแผนกที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ ผู้จัดการโครงการ ผู้จัดการคุณภาพ และอื่นๆ ที่สนใจในการปรับปรุงคุณภาพของการพัฒนาและรับรองกระบวนการสำหรับ CMM

ภาพรวมของมาตรฐานที่เป็นที่ยอมรับในด้านการจัดการคุณภาพสำหรับไอที (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)

17. ถึง CMM ผ่าน ISO?

5 ขั้นตอนวิวัฒนาการในการจัดการกระบวนการขององค์กร คำอธิบายของแบบจำลองวุฒิภาวะความสามารถ ฟังก์ชั่น). CMM

ความสามารถครบกำหนดรุ่น CM-CEI รูปแบบองค์กรซึ่งอธิบาย 5 ขั้นตอนวิวัฒนาการ (ระดับ) ที่กระบวนการในองค์กรได้รับการจัดการ

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

5 ขั้นตอนของแบบจำลองวุฒิภาวะความสามารถ

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

รูปแบบการพัฒนาซอฟต์แวร์

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

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

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

โครงสร้างของแบบจำลองการพัฒนาคุณลักษณะ

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

เกณฑ์ในการกำหนดกระบวนการ

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

บทนำ

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

ในปัจจุบัน การกำหนดมาตรฐานทางวิศวกรรมซอฟต์แวร์และการประกันคุณภาพผลิตภัณฑ์ซอฟต์แวร์มีอยู่เกือบสองส่วน ซึ่งสามารถเรียกได้ว่าเป็นโปรไฟล์มาตรฐาน ISO แบบมีเงื่อนไข ( องค์การระหว่างประเทศมาตรฐาน) และ SEI (US Software Engineering Institute) รุ่นครบกำหนด อันแรกแสดงค่อนข้างสมบูรณ์ใน [ , ] และอันที่สอง - ใน [ , ] เนื้อหาหลักของบทความมีเนื้อหาเกี่ยวกับแบบจำลองวุฒิภาวะ

เพื่อให้มั่นใจในความสามารถในการแข่งขันในโลกของผลิตภัณฑ์ซอฟต์แวร์ที่ซับซ้อนและความเป็นไปได้ของการส่งออกที่ประสบความสำเร็จ ผลิตภัณฑ์เหล่านั้นต้องได้รับการพัฒนาและรับรองตามข้อกำหนด โปรไฟล์ของมาตรฐานสากลบนฐาน ISO 9000:2000หรือ รุ่นครบกำหนด - CMMI:2003(Capability Maturity Model Integration - แบบบูรณาการการประเมินวุฒิภาวะทางวิศวกรรมซอฟต์แวร์) ทิศทางทั้งสองนี้มีความใกล้เคียงกันมากตามระเบียบวิธีและบางส่วนตัดกันผ่านการอ้างอิงร่วมกัน

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

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

พื้นฐานสำหรับการรับรองควรเป็นโปรแกรมและวิธีการที่มีรายละเอียดและมีประสิทธิภาพสำหรับการทดสอบแพ็คเกจซอฟต์แวร์เพื่อให้สอดคล้องกับข้อกำหนดของลูกค้าที่เป็นมาตรฐาน ปัญหาในการทดสอบที่ออกแบบมาเป็นพิเศษและตัวสร้างสำหรับการพัฒนา รวมถึงคุณสมบัติและอำนาจหน้าที่ของผู้ทดสอบ แอปพลิเคชันที่องค์กร-ผู้พัฒนาผลิตภัณฑ์ซอฟต์แวร์ ระบบคุณภาพที่ผ่านการรับรองเพื่อให้มั่นใจว่าวงจรชีวิตของ PS เป็นไปตามข้อกำหนด ISO 9000:2000หรือ CMMI:2003รับประกันการจัดการกระบวนการและผลิตภัณฑ์ที่มีคุณภาพอย่างยั่งยืนในระดับสูง และยังช่วยให้ในหลายกรณีสามารถอำนวยความสะดวกในการรับรองผลิตภัณฑ์ซอฟต์แวร์ขั้นสุดท้าย ดังนั้น ลูกค้าของโครงการซอฟต์แวร์ที่ซับซ้อนจึงมักจะเลือกใช้ผู้รับเหมาที่มีใบรับรองที่รับรองการใช้งานระบบประกันคุณภาพตามโปรไฟล์มาตรฐานสากลที่ดัดแปลงหรือแบบจำลองวุฒิภาวะ

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

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

แบบจำลองวุฒิภาวะ CMMI - 1.1ปรับปรุงและปรับปรุงรุ่นก่อนหน้า CMM(ดู ) และยังคำนึงถึงข้อกำหนดพื้นฐานของมาตรฐานสากลที่มีอยู่บางส่วนในด้านการจัดการซอฟต์แวร์ด้วย ความสนใจใน CMMIมอบให้กับกระบวนการพัฒนาและการบัญชีสำหรับการทำซ้ำเมื่อเปลี่ยนแปลงความต้องการของลูกค้า ความสามารถในการตรวจสอบย้อนกลับไปยังฟังก์ชัน ส่วนประกอบ การทดสอบ และเอกสารโครงการ ที่ ครั้งล่าสุดมีข้อมูลเกี่ยวกับความทันสมัยของรุ่น SEI ของรุ่น 2003 CMMI-1.1จากประสบการณ์ที่สั่งสมและผลตอบรับจากองค์กรต่างๆ คาดว่าจะออกในปี 2549 รุ่นใหม่ที่ได้รับการอัพเกรดอย่างมีนัยสำคัญของรุ่น CMMI-1.2หลังจากนั้นควรเลิกใช้เวอร์ชัน 1.1 จนถึงสิ้นปี 2550 ผู้ใช้ควรเปลี่ยนไปใช้เวอร์ชัน CMMI-1.2และในอนาคตจะกลายเป็นข้อบังคับสำหรับการประเมินคุณภาพ (การรับรอง) อย่างเป็นทางการของเทคโนโลยีระดับองค์กรในด้านวิศวกรรมซอฟต์แวร์ ระยะเวลาที่ถูกต้องของใบรับรองจะถูก จำกัด ไว้ที่สามปี ลูกค้าและผู้พัฒนาระบบซอฟต์แวร์ขนาดใหญ่ควรเตรียมพร้อมสำหรับการเปลี่ยนแปลงเหล่านี้ก่อนที่จะเผยแพร่เวอร์ชัน 1.2 อย่างเป็นทางการโดย SEI

โครงสร้างและเนื้อหาของแบบจำลองวุฒิภาวะ CMMI - 1.1

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

ตัวเลือกคำอธิบายแบบจำลองถูกสร้างขึ้นตามแบบแผนเดียว ซึ่งรวมถึงส่วนทั่วไป:

• คำนำ;
• 1 ส่วน - บทนำ;
• ส่วนที่ 2 - แบบจำลองส่วนประกอบ
• ส่วนที่ 3 - คำศัพท์;
• ส่วนที่ 4 - เนื้อหาของระดับและองค์ประกอบหลักของแต่ละรุ่นของแบบจำลอง (การพัฒนาเป้าหมายและขั้นตอน)
• ส่วนที่ 5 - โครงสร้างของปฏิสัมพันธ์ของกระบวนการ สี่ประเภทของกระบวนการในส่วนที่ 7 มีคำอธิบายประกอบ ภาพรวมทั่วไปและรูปแบบการโต้ตอบของกระบวนการ CMMI:
  • การจัดการกระบวนการ
  • การจัดการ - การจัดการโครงการ
  • วิศวกรรม (เทคโนโลยี);
  • สนับสนุน;
• ส่วนที่ 6 - การใช้แบบจำลอง CMMI- คำแนะนำสั้น ๆ สำหรับผู้ใช้เกี่ยวกับการใช้แบบจำลองและการฝึกอบรม ความเข้ากันได้และการปฏิบัติตามข้อกำหนดของกระบวนการแบบจำลองกับกระบวนการควบคุมของรุ่น CMM ก่อนหน้าในส่วนที่ 2 และ 3 ของมาตรฐาน ISO 15504.
• ส่วนที่ 7 เป็นข้อสุดท้าย ใหญ่ที่สุดในแต่ละมาตรฐาน ใช้เอกสารทั้งหมดประมาณ 500 หน้า ซึ่งมากกว่า 700 หน้า ส่วนนี้ให้คำแนะนำโดยละเอียดสำหรับการใช้งานของแต่ละกระบวนการที่ระบุไว้ในนั้น ซึ่งคำนึงถึงลักษณะของแบบจำลองเฉพาะ

ตัวเลือกแรก(ต่อเนื่อง) รุ่นสะท้อนถึงเอกสาร: Capability Maturity Model Integration (CMMI) for Systems Engineering/ Software Engineering/Integrated Product and Process Development, เวอร์ชัน 1.1, การเป็นตัวแทนอย่างต่อเนื่อง (CMMI-SE/SW/IPPD, V1.1, ต่อเนื่อง). แบบบูรณาการวิศวกรรมระบบ/วิศวกรรมซอฟต์แวร์/ผลิตภัณฑ์แบบบูรณาการและกระบวนการพัฒนา แบบจำลองการประเมินวุฒิภาวะ - มุมมองต่อเนื่อง. ในแบบจำลองนี้ ส่วนที่เจ็ดประกอบด้วยกระบวนการ:

• การจัดการกระบวนการ:
  • การจัดฝึกอบรม
  • องค์กรของการเปลี่ยนแปลง (การเปลี่ยนแปลง) ของกระบวนการ
  • การจัดนวัตกรรมและการขยาย;
• การจัดการโครงการ:
  • การวางแผนโครงการ;
  • การติดตามและควบคุมกระบวนการของโครงการ
  • การจัดการความเสี่ยง
  • การจัดการโครงการเชิงปริมาณ
• วิศวกรรม (เทคโนโลยี):
  • การจัดการความต้องการ
  • การพัฒนาความต้องการ
  • โซลูชั่นทางเทคนิค
  • การรวมผลิตภัณฑ์
  • การตรวจสอบ;
  • การตรวจสอบ (รับรอง, อนุมัติ);
• สนับสนุน:
  • การจัดการการตั้งค่า;
  • การวิเคราะห์และการตัดสินใจเกี่ยวกับการเปลี่ยนแปลง
  • การวิเคราะห์สาเหตุและการแก้ปัญหา (การกำจัดข้อบกพร่อง)

ภาคผนวกห้าให้:

แต่- องค์ประกอบของแหล่งวรรณกรรมและเอกสารที่ใช้แล้วซึ่งไม่ได้กล่าวถึงมาตรฐาน ISO;

ที่- ตัวย่อ;

กับ- คำศัพท์ตามอภิธานศัพท์ ISOใช้ในสี่มาตรฐานเท่านั้น ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288;

D - คำอธิบายของข้อกำหนดและข้อเสนอสำหรับการก่อตัวของส่วนประกอบแบบจำลองตามระดับวุฒิภาวะ

E - รายชื่อผู้เข้าร่วมการพัฒนา CMMI- โครงการ.

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

การวางแผนโครงการในรุ่นนี้และในรุ่นที่สองประกอบด้วย:

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

กระบวนการพัฒนาความต้องการเพื่อผลิตภัณฑ์ซอฟต์แวร์จะคล้ายกับกระบวนการในทั้งสองรุ่นและรวมถึง:

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

การจัดการความต้องการทั้งสองรุ่นรวมถึง:

• บรรลุความเข้าใจที่ชัดเจนเกี่ยวกับข้อกำหนดสำหรับโครงการ PS โดยลูกค้าและนักพัฒนา
• การได้มาซึ่งลูกค้าจากผู้พัฒนาภาระผูกพันในการปฏิบัติตามข้อกำหนดทั้งหมดสำหรับผลิตภัณฑ์ซอฟต์แวร์
• การจัดการการเปลี่ยนแปลงข้อกำหนดสำหรับโครงการ PS ที่ตกลงกันระหว่างลูกค้าและผู้พัฒนา
• ตรวจสอบความถูกต้องของการเปลี่ยนแปลงจากข้อกำหนดทั่วไปสำหรับโครงการ PS ไปจนถึงข้อกำหนดสำหรับส่วนประกอบและกระบวนการเฉพาะ
• การระบุและระบุความแตกต่างระหว่างกระบวนการพัฒนาโครงการและความต้องการของลูกค้า

ตัวเลือกที่สองนำเสนอเอกสาร: Capability Maturity Model Integration (CMMI) for Systems Engineering/Software Engineering/Integrated Product and Process Development, เวอร์ชัน 1.1, Staged Representation (CMMI-SE/SW/IPPD, V1.1, แบบฉาก). แบบบูรณาการวิศวกรรมระบบ/วิศวกรรมซอฟต์แวร์/ผลิตภัณฑ์แบบบูรณาการและกระบวนการพัฒนา แบบจำลองการประเมินวุฒิภาวะ - การแนะนำแบบค่อยเป็นค่อยไป. โมเดลนี้ยึดตามแนวคิดของวุฒิภาวะห้าระดับ CMM[ , ]. องค์ประกอบของกระบวนการจะทำซ้ำตามที่ระบุไว้ข้างต้นสำหรับรุ่นแรกของโมเดล แต่ในลำดับที่แตกต่างกันเล็กน้อยและมีการเพิ่มเติมที่ค่อนข้างเล็ก

ระดับแรกมีลักษณะที่ไม่แน่นอนอย่างมีนัยสำคัญในองค์ประกอบและเนื้อหาของกระบวนการในโครงการที่ค่อนข้างง่ายต่าง ๆ ดังนั้นจึงไม่ได้แสดงความคิดเห็นในเอกสาร ดังนั้นเมื่อชี้แจงและให้รายละเอียดเนื้อหาของกระบวนการในเวอร์ชันที่ค่อยเป็นค่อยไป CMMIแนะนำให้จำกัด สี่ระดับหลัก:

• ระดับที่สอง- ทำให้เป็นทางการ การจัดการขั้นพื้นฐานโครงการ:
  • การจัดการความต้องการ
  • การวางแผนโครงการ;
  • การติดตามและควบคุมโครงการ
  • การจัดการข้อตกลงกับซัพพลายเออร์
  • การวัดและวิเคราะห์กระบวนการและผลิตภัณฑ์
  • รับรองคุณภาพของกระบวนการและผลิตภัณฑ์
  • การจัดการการตั้งค่า;
• ระดับที่สาม- มีมาตรฐานของกระบวนการหลัก:
  • การพัฒนาความต้องการ
  • โซลูชั่นทางเทคนิค
  • การรวมผลิตภัณฑ์
  • การตรวจสอบ;
  • การตรวจสอบ (รับรอง);
  • เนื้อหาของกระบวนการขององค์กร
  • คำจำกัดความของกระบวนการในองค์กร
  • การจัดฝึกอบรม
  • การจัดการกระบวนการและผลิตภัณฑ์ของโครงการแบบบูรณาการ
  • การจัดการความเสี่ยง
  • การรวมทีมพัฒนา
  • การจัดการซัพพลายเออร์แบบบูรณาการ
  • การวิเคราะห์และแก้ไขปัญหา (การกำจัดข้อบกพร่อง)
  • การจัดระเบียบสิ่งแวดล้อมเพื่อการบูรณาการ
• ระดับที่สี่- กำหนดการจัดการเชิงปริมาณ:
  • องค์กรเพื่อเป็นตัวแทนของคุณภาพของกระบวนการ
  • การจัดการเชิงปริมาณของทั้งโครงการและทรัพยากร
• ระดับที่ห้า- การเพิ่มประสิทธิภาพ การปรับปรุงอย่างต่อเนื่อง:
  • องค์กร นวัตกรรม การจัดการเชิงปริมาณของกระบวนการและการจัดหาทรัพยากร
  • การวิเคราะห์สาเหตุของข้อบกพร่อง การปรับปรุงคุณภาพ และการจัดการกระบวนการและผลิตภัณฑ์

แอปพลิเคชันในรุ่นที่สองมีองค์ประกอบคล้ายกับแอปพลิเคชันด้านบนสำหรับรุ่นแรก ขอแนะนำในแต่ละระดับที่สูงขึ้นในการสมัคร ทุกกระบวนการระดับล่างก่อนหน้า ในแบบจำลองทั้งสองเวอร์ชัน แต่ละกระบวนการพื้นฐานที่เน้นด้านบนจะได้รับการแสดงความคิดเห็นพร้อมคำแนะนำโดยละเอียดสำหรับการนำไปใช้จริง ซึ่งมีคำอธิบายประมาณ 20–30 หน้าที่รวมกันเป็นโครงสร้าง:

• วัตถุประสงค์โดยรวมของกระบวนการที่จะบรรลุ
• ข้อสังเกตเบื้องต้นและ คำอธิบายทั่วไปฟังก์ชั่นกระบวนการ
• วัตถุประสงค์ของกระบวนการเฉพาะ
• การจัดการกระบวนการ
• การพัฒนาข้อกำหนดของกระบวนการ
• ปฏิสัมพันธ์และการติดต่อกับกระบวนการอื่น
• เป้าหมายในทางปฏิบัติ - ผลลัพธ์ที่ต้องการของกิจกรรมกระบวนการ
• การวางแผนการดำเนินการในกระบวนการเฉพาะ
• การวิเคราะห์และตรวจสอบ (การอนุมัติ) ของผลลัพธ์ของการดำเนินการตามกระบวนการ
• การติดตามและควบคุมกระบวนการ

คำแนะนำเหล่านี้ในแง่ของขอบเขต เนื้อหา และความสมบูรณ์ของคำอธิบายของกระบวนการพื้นฐานนั้นคล้ายคลึงกับมาตรฐานต่างๆ สำหรับ PS Life Cycle Profile ที่นำเสนอ การสั่งซื้อและประเมินความสมบูรณ์ของกระบวนการที่ใช้ตามระดับของวุฒิภาวะช่วยให้คุณสร้างศักยภาพการผลิตขององค์กร - ผู้พัฒนาผลิตภัณฑ์ซอฟต์แวร์ในแง่ของคุณภาพที่คาดการณ์ของกระบวนการและผลลัพธ์ของกิจกรรมและความพร้อมสำหรับการรับรอง สอดคล้องกับระดับวุฒิภาวะที่แน่นอนของแบบจำลอง CMMI - 1.1.

เน้นรุ่น CMMIให้กับกระบวนการจัดการของโครงการ PS ข้อกำหนดและกระบวนการของแบบจำลองเหล่านี้สอดคล้องกับคำแนะนำที่มีการควบคุมและมีรายละเอียดในมาตรฐาน ISO 9001:2000และองค์ประกอบหลักของโปรไฟล์ของมาตรฐานวงจรชีวิต PS ที่ซับซ้อน [ , ] ข้อกำหนดสำหรับกระบวนการในส่วนการทำงาน 4-8 ของมาตรฐาน ISO 9001, ISO 9004, ISO90003เปรียบเทียบเนื้อหาได้หลายส่วนในแบบจำลอง CMMI(ในรูปที่ 1 โซนเนื้อหาทับซ้อน) ความคล้ายคลึงกันของกระบวนการและข้อกำหนดประกอบด้วยความคล้ายคลึงกัน: องค์ประกอบ คำศัพท์ โครงสร้าง รายการกระบวนการจัดการที่แนะนำ การวางแผน การบัญชีสำหรับทรัพยากรที่มีอยู่ การใช้กระบวนการวิศวกรรมซอฟต์แวร์ การประเมินและการจัดองค์กรของผู้เชี่ยวชาญ

รูปที่ 1 ความธรรมดาของกระบวนการและข้อกำหนดของมาตรฐานและแบบจำลองวุฒิภาวะ

จากมุมมองของการสนับสนุนและควบคุมวงจรชีวิตที่สมบูรณ์ของโครงการซอฟต์แวร์ขนาดใหญ่ ข้อบกพร่องของรุ่นต่างๆ CMMIเกี่ยวกับรายละเอียดของมาตรฐานที่มีอยู่ ISOสามารถรวมสิ่งต่อไปนี้:

รายงานทางเทคนิคฉบับสมบูรณ์ได้รับการพัฒนาและได้รับการอนุมัติในขั้นต้นในปี 2541 เพื่อกำหนดระดับวุฒิภาวะของกระบวนการเพื่อให้แน่ใจว่าวงจรชีวิตของ PS ที่นำเสนอข้างต้น ISO 15504ซึ่งประกอบด้วยเก้าส่วนและการใช้งานมากมาย มันร่างรูปแบบวุฒิภาวะ CMMและหลักการพื้นฐานแปดประการของวิศวกรรมซอฟต์แวร์ตามมาตรฐาน ISO 9000:2000. จากนั้นใน ISOเอกสารนี้ผ่านการแก้ไข การลดทอน การทำให้โครงสร้างและเนื้อหาง่ายขึ้น ในขณะที่ยังคงรักษาเป้าหมายและแนวคิดไว้อย่างเต็มที่ และได้รับการอนุมัติ ตามมาตรฐานในห้าส่วน

มาตรฐาน ISO 15504:1-5:2003-2006ควบคุมการประเมินและการรับรองความสมบูรณ์ของกระบวนการสร้าง บำรุงรักษา และปรับปรุงเครื่องมือซอฟต์แวร์และระบบที่ดำเนินการโดยองค์กร:

• เพื่อสร้างสถานะของกระบวนการทางเทคโนโลยีของตนเองและการปรับปรุง
• เพื่อกำหนดความเหมาะสมของกระบวนการของตนเองเพื่อตอบสนองความต้องการเฉพาะหรือระดับความต้องการของลูกค้า
• เพื่อวัตถุประสงค์ของความเหมาะสมสำหรับการปฏิบัติตามสัญญาบางอย่างกับลูกค้าของ PS และระบบ

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

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

การอนุมัติในมาตรฐานจะได้รับการจัดการใน สองด้าน: เพื่อปรับปรุงกระบวนการวงจรชีวิตของ PS และระบบขององค์กรใดองค์กรหนึ่ง และเพื่อตรวจสอบว่าครบกำหนดที่ประกาศของโครงการหรือกระบวนการสนับสนุนองค์กรสอดคล้องกับกระบวนการจริงที่ใช้หรือไม่ สิ่งนี้สะท้อนให้เห็นในห้าส่วนต่อไปนี้ของมาตรฐาน ISO 15504:1-5:2003-2006.

ส่วนที่ 1 - แนวคิดและคำศัพท์ประกอบด้วย ข้อมูลทั่วไปเกี่ยวกับกระบวนการรับรองความสมบูรณ์ของซอฟต์แวร์และระบบและคำแนะนำเกี่ยวกับการใช้ชิ้นส่วนของมาตรฐาน ข้อกำหนดทั่วไปสำหรับการรับรองคำศัพท์โครงสร้างกำหนดขอบเขตของส่วนที่เหลือของมาตรฐาน

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

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

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

ส่วนที่ 5 - ตัวอย่างรูปแบบกระบวนการรับรองการปฏิบัติตามข้อกำหนดที่แสดงในส่วนที่ 2เอกสารที่ครอบคลุม (162 หน้า) ให้ตัวอย่างเชิงปฏิบัติของส่วนก่อนหน้าของมาตรฐานสำหรับการจัดระเบียบ การประเมิน และปรับปรุงการประเมินความสมบูรณ์ของกระบวนการวงจรชีวิตสำหรับขอบเขตการใช้งานต่างๆ โครงการซอฟต์แวร์ และองค์กรต่างๆ

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

องค์กรการรับรองผลิตภัณฑ์ซอฟต์แวร์

การรับรองประกอบด้วยชุดกระบวนการขององค์กรที่ประกอบขึ้นเป็น ระบบการรับรองกระบวนการเหล่านี้ได้รับการสนับสนุนโดยขั้นตอนและเอกสารที่มีการควบคุม และต้องดำเนินการโดยผู้เชี่ยวชาญที่ผ่านการรับรองและผ่านการรับรอง - ผู้ตรวจสอบ สำหรับการรับรองผู้พัฒนาองค์กรและผลลัพธ์ของกิจกรรม - ผลิตภัณฑ์ซอฟต์แวร์, รุ่น CMMIหรือโปรไฟล์มาตรฐาน ISO[ , ] ขอแนะนำวินัยบางอย่างซึ่งควรปรับให้เข้ากับลักษณะเฉพาะของวัตถุและสภาพแวดล้อมของวงจรชีวิตของ PS กระบวนการและเอกสารที่แสดงด้านล่างได้รับการออกแบบสำหรับโครงการขนาดใหญ่ และอาจลดลงได้ตามข้อตกลงระหว่างผู้พัฒนา ลูกค้า และผู้รับรองในกรณีที่ง่ายกว่า

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

ระเบียบว่าด้วยหน่วยรับรองหรือห้องปฏิบัติการเป็นเอกสารหลักที่กำหนดหัวข้อของการรับรอง สถานะทางกฎหมาย หน้าที่ โครงสร้าง สิทธิและหน้าที่ วิธีการ วิธีการและการจัดการทดสอบ หนังสือเดินทางของห้องปฏิบัติการรับรอง (ศูนย์) จะต้องมีข้อมูลเกี่ยวกับอุปกรณ์พร้อมอุปกรณ์คอมพิวเตอร์ที่จำเป็นสำหรับการทดสอบ เกี่ยวกับบุคลากรและเจ้าหน้าที่ อุปกรณ์สำหรับเครื่องมือทดสอบ การจัดหาเอกสารกำกับดูแล เทคนิค และระเบียบวิธี ตลอดจนทรัพยากรอื่น ๆ ที่จำเป็นสำหรับ การทดสอบ

ค่าคุณภาพมีคำแถลงหลักการ คำอธิบายของวิธีการและขั้นตอนที่เกี่ยวข้องกับการปฏิบัติงานของหน้าที่หลักและภารกิจของหน่วยรับรองหรือห้องปฏิบัติการ เพื่อให้มั่นใจในคุณภาพของการทดสอบและความมั่นใจในผลการประเมิน การทดสอบและการทดสอบ คู่มือคุณภาพมักจะมีส่วนต่างๆ [ TWLSC$

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

สำหรับการประเมินผลิตภัณฑ์หรือกระบวนการที่อยู่ภายใต้การรับรอง ผู้สมัครส่งใบสมัครไปยังหน่วยรับรองในรูปแบบที่นำมาใช้ในระบบการรับรอง หน่วยรับรองทำงานเกี่ยวกับการเตรียมการและการจัดการรับรองผลิตภัณฑ์เมื่อสมัคร งานนี้รวมถึง:

• การเลือกรูปแบบการรับรองโดยคำนึงถึงลักษณะเฉพาะของผลิตภัณฑ์ (ปริมาณ เทคโนโลยี ข้อกำหนดของเอกสารกำกับดูแล ฯลฯ) และข้อเสนอของนักพัฒนา
• การกำหนดจำนวนและลำดับของการสุ่มตัวอย่างและส่วนประกอบที่จะทดสอบ หากไม่ระบุไว้ในมาตรฐาน
• การคัดเลือกและระบุห้องปฏิบัติการทดสอบที่ได้รับการรับรองเพื่อดำเนินการทดสอบ
• การจัดทำร่างสัญญาเพื่อการปฏิบัติงาน

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

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

การทดสอบดำเนินการโดยห้องปฏิบัติการทดสอบที่ได้รับการรับรองให้ดำเนินการเฉพาะการทดสอบที่ระบุไว้ในเอกสารด้านกฎระเบียบและการรับรอง หากไม่สามารถทำการทดสอบที่ห้องทดสอบของห้องปฏิบัติการที่ได้รับการรับรอง บุคลากรของห้องปฏิบัติการนี้สามารถทำการทดสอบได้ที่ผู้ผลิตหรือผู้บริโภคของผลิตภัณฑ์นี้โดยใช้สิ่งอำนวยความสะดวกของห้องปฏิบัติการทดสอบเองหรือสิ่งอำนวยความสะดวกในการทดสอบที่มีให้จากซัพพลายเออร์ .

กระบวนการรับรองผลิตภัณฑ์ซอฟต์แวร์และระบบคุณภาพองค์กรประกอบด้วย:

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

เมื่อตรวจสอบความรับผิดชอบของฝ่ายบริหารของผู้พัฒนาสำหรับคุณภาพของผลิตภัณฑ์ ควรพิจารณาว่าองค์กรหรือโครงการมีนโยบายด้านคุณภาพ เป้าหมายและข้อผูกมัดที่จัดทำเป็นเอกสาร ตลอดจนระดับที่เข้าใจนโยบายนี้ นำไปปฏิบัติ และรักษาสภาพการทำงานที่ ทุกระดับขององค์กร ควรจัดตั้งขึ้นว่าองค์กรมีตัวแทนฝ่ายบริหารที่มีอำนาจและความรับผิดชอบในการดำเนินการตามข้อกำหนดของมาตรฐานและเอกสารกำกับดูแลของระบบคุณภาพโดยไม่คำนึงถึงหน้าที่อื่น ๆ ความพร้อมใช้งานของข้อกำหนด ขั้นตอน เครื่องมือ และบุคลากรที่ได้รับการฝึกอบรมสำหรับการนำกระบวนการระบบคุณภาพไปปฏิบัติจริง รวมถึงการจัดทำเอกสารที่เกี่ยวข้องและเป็นระบบของส่วนประกอบ ข้อกำหนด และข้อกำหนดทั้งหมดของระบบคุณภาพ ซึ่งเป็นกระบวนการที่บูรณาการตลอดอายุการใช้งาน วงจรของ PS ควรตรวจสอบ การตรวจสอบระบบคุณภาพควรมีคำจำกัดความ:

• ความพร้อมใช้งานและความสมบูรณ์ของเอกสารทางเทคโนโลยีและการปฏิบัติตามข้อกำหนดในทางปฏิบัติ
• สถานะของอุปกรณ์เทคโนโลยีและความพร้อมใช้งานของระบบสำหรับการบำรุงรักษา
• การมีอยู่และประสิทธิภาพของระบบควบคุมและทดสอบ
• สถานะของเครื่องมือวัดและทดสอบ
• ความพร้อมใช้งานของระบบสำหรับการระบุและขจัดข้อบกพร่องที่ระบุในผลิตภัณฑ์หรือเทคโนโลยี

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

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

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

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

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

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

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

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

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

• การเปลี่ยนแปลงขั้นพื้นฐานในแบบจำลองวุฒิภาวะ โปรไฟล์มาตรฐาน ข้อบังคับผลิตภัณฑ์ หรือวิธีการทดสอบ
• การเปลี่ยนแปลงในการออกแบบ (องค์ประกอบ) ความสมบูรณ์ของผลิตภัณฑ์
• การเปลี่ยนแปลงในองค์กรหรือเทคโนโลยีการพัฒนาและการผลิต
• การไม่ปฏิบัติตามข้อกำหนดของเทคโนโลยี วิธีการควบคุมและทดสอบ ระบบคุณภาพ หากการเปลี่ยนแปลงในรายการอาจทำให้ผลิตภัณฑ์ไม่เป็นไปตามข้อกำหนดที่ควบคุมระหว่างการรับรอง

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

• ระบุสาเหตุของการไม่ปฏิบัติตามและกำจัด
• ส่งไปยังหน่วยรับรองของรายงานเกี่ยวกับงานที่ทำเพื่อปรับปรุงและรับรองคุณภาพของผลิตภัณฑ์
• ดำเนินการทดสอบผลิตภัณฑ์เพิ่มเติมตามวิธีการและอยู่ภายใต้การควบคุมของหน่วยรับรองและได้ผลลัพธ์ที่เป็นบวก

เอกสารกระบวนการและผลการรับรองผลิตภัณฑ์ซอฟต์แวร์

องค์ประกอบและเนื้อหาของเอกสารประกอบการรับรองระบบคุณภาพวิสาหกิจขึ้นอยู่กับลักษณะของการออกแบบ การพัฒนาและการปรับเปลี่ยนซอฟต์แวร์ตลอดจนข้อกำหนดสำหรับคุณภาพและลักษณะของสภาพแวดล้อมทางเทคโนโลยี ดังนั้นควรเลือกและปรับเปลี่ยนชุดเอกสารที่จำเป็นสำหรับแต่ละองค์กรหรือโครงการให้สัมพันธ์กับลักษณะเหล่านี้ ตัวชี้วัดของระบบคุณภาพที่ประเมินระหว่างการรับรองคือความพร้อมของเอกสารที่เกี่ยวข้องและการปฏิบัติตามข้อกำหนดของแบบจำลองวุฒิภาวะในระดับหนึ่ง SMMIหรือโปรไฟล์มาตรฐานดัดแปลงตาม ISO 9000:2000รวมถึงคำอธิบายลักษณะงานที่สร้างขึ้นบนพื้นฐานของพวกเขาโดยผู้เชี่ยวชาญของผู้พัฒนาองค์กร ผู้สมัครต้องจัดเตรียมและส่งชุดเอกสารที่ตกลงกันระหว่างลูกค้าและผู้พัฒนาให้กับห้องปฏิบัติการทดสอบ และได้รับการอนุมัติให้ตรวจสอบความน่าเชื่อถือ ความเพียงพอขององค์ประกอบและฝีมือการผลิตตามเอกสารกำกับดูแล

ชุดเอกสารพื้นฐานสำหรับการรับรองประกอบด้วยสามกลุ่ม:

• ขั้นพื้นฐาน กฎระเบียบระบบคุณภาพตามระบบการตั้งชื่อและเนื้อหาของโปรไฟล์ของมาตรฐานตาม ISO 9000:2000หรือรุ่นที่มีวุฒิภาวะ SMMIเช่นเดียวกับโปรแกรม คู่มือและคำแนะนำที่จัดทำโดยนักพัฒนาบนพื้นฐานของพวกเขา นำเสนอต่อผู้ทดสอบ (ผู้เชี่ยวชาญ) ของระบบคุณภาพหรือผลิตภัณฑ์ขององค์กรที่ได้รับการตรวจสอบ
• เอกสารต้นทางที่แสดงถึงองค์กรหรือโครงการเฉพาะ ตลอดจนวงจรชีวิตของเครื่องมือซอฟต์แวร์ ซึ่งจัดทำโดยการจัดการโครงการเพื่อรับรองคุณภาพ
• เอกสารการรายงานของผู้ทดสอบที่สะท้อนถึงผลการตรวจสอบ (การรับรอง) ของระบบคุณภาพขององค์กรและ / หรือผลิตภัณฑ์ซอฟต์แวร์ที่ส่งไปยังหน่วยรับรอง ผู้สมัคร และผู้บริหารขององค์กรที่ได้รับการตรวจสอบ

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

เอกสารพื้นฐานของระบบคุณภาพองค์กรและวงจรชีวิตซอฟต์แวร์

1. แนวคิด คำศัพท์ ข้อกำหนด และคำแนะนำสำหรับการปรับปรุงประสิทธิภาพ - ระบบการจัดการคุณภาพ - ISO 9000:2000หรือรุ่นของรูปแบบการครบกำหนดของ CMMI
2. รุ่นดัดแปลงหรือรายการส่วนและข้อเสนอแนะของมาตรฐาน ISO 12207, ISO 15504การเปลี่ยนแปลงและแนวทางการใช้งานซึ่งได้รับการคัดเลือกระหว่างการปรับและบังคับสำหรับการใช้งานในระบบคุณภาพขององค์กรหรือโครงการผลิตภัณฑ์ซอฟต์แวร์โดยเฉพาะ
3. รุ่นดัดแปลงหรือรายการส่วนและคำแนะนำของมาตรฐาน ISO 900003เลือกระหว่างการปรับและบังคับสำหรับใช้ในระบบคุณภาพขององค์กรที่ผลิตผลิตภัณฑ์ซอฟต์แวร์
4. ลักษณะพื้นฐานและคุณลักษณะคุณภาพของโครงการ PS ระบุ ดัดแปลง และระบุบนพื้นฐานของมาตรฐาน ISO 12182, ISO 9126, ISO 14598, ISO 25000.
5. เวอร์ชันดัดแปลงและคู่มือการจัดการการบำรุงรักษาและการกำหนดค่าที่ได้รับอนุมัติตามคำแนะนำของมาตรฐาน ISO 14764, ISO 10007, ISO 15846.
6. ชุดคำอธิบายงานที่กำหนดความรับผิดชอบ อำนาจ และขั้นตอนสำหรับการโต้ตอบของฝ่ายบริหารทั้งหมด การปฏิบัติงานและการตรวจสอบงานของบุคลากรที่เกี่ยวข้องกับขั้นตอนของระบบคุณภาพองค์กรสำหรับโครงการ PS เฉพาะ

เอกสารต้นฉบับที่แสดงถึงคุณลักษณะของวงจรชีวิตของเครื่องมือซอฟต์แวร์โดยเฉพาะ

1. คำอธิบายคุณลักษณะของผลิตภัณฑ์ซอฟต์แวร์ที่สร้างขึ้นในองค์กร ระบบและสภาพแวดล้อมภายนอกของวงจรชีวิต จำเป็นสำหรับการปรับและเตรียมเวอร์ชันการทำงานตามมาตรฐานและข้อกำหนดของโครงการ PS และระบบคุณภาพองค์กรตาม คำแนะนำของมาตรฐาน ISO 12207, ISO 15504, ISO90003และ ISO 9126.
2. คำอธิบายของเป้าหมาย ข้อกำหนด และภาระผูกพันของผู้พัฒนาองค์กรในด้านระบบคุณภาพ เกณฑ์คุณภาพสำหรับกระบวนการและผลิตภัณฑ์ของการพัฒนา การส่งมอบ และการสนับสนุนตลอดวงจรชีวิตทั้งหมดของซอฟต์แวร์
3. ชุดเอกสารการปฏิบัติงานที่จัดส่งให้แก่ลูกค้าและผู้ใช้เพื่อให้มั่นใจถึงวงจรชีวิตและการใช้ผลิตภัณฑ์ซอฟต์แวร์เวอร์ชันเฉพาะตามมาตรฐานที่ดัดแปลง ISO 9294, ISO 15910, ISO 18019.
4. เครื่องมือจัดทำเอกสารและระบบอัตโนมัติสำหรับการออกแบบ การพัฒนา การปรับเปลี่ยน การควบคุม และการทดสอบที่ใช้เพื่อให้แน่ใจว่าวงจรชีวิตของผลิตภัณฑ์ซอฟต์แวร์
5. แผนและวิธีการทดสอบแอปพลิเคชันและประเมินประสิทธิภาพของกระบวนการของระบบคุณภาพระดับองค์กรและผลิตภัณฑ์ซอฟต์แวร์
6. วิธีการบำรุงรักษา การระบุส่วนประกอบและเอกสารของผลิตภัณฑ์ซอฟต์แวร์ การวิเคราะห์และการอนุมัติเวอร์ชันของซอฟต์แวร์และคอมเพล็กซ์ข้อมูล
7. วิธีการสำหรับการจัดการการกำหนดค่า การอนุมัติ การจัดเก็บ การป้องกัน การคัดลอกเวอร์ชันผลิตภัณฑ์ซอฟต์แวร์และเอกสารประกอบ ตลอดจนการรวบรวมและจัดเก็บข้อมูลเกี่ยวกับคุณลักษณะด้านคุณภาพที่ลงทะเบียนในไฟล์เก็บถาวรขององค์กรในช่วงวงจรชีวิตของเวอร์ชันผลิตภัณฑ์ซอฟต์แวร์

ผลการทดสอบเอกสาร - การรับรองระบบคุณภาพขององค์กรและ / หรือผลิตภัณฑ์ซอฟต์แวร์

1. รายงานเกี่ยวกับความพร้อมใช้งาน ความเกี่ยวข้อง และการดำเนินการเอกสารอย่างเป็นระบบซึ่งปรับให้เข้ากับข้อกำหนดและข้อกำหนดของระบบคุณภาพระดับองค์กร ซึ่งให้กระบวนการประกันคุณภาพแบบบูรณาการตลอดวงจรชีวิตทั้งหมดของผลิตภัณฑ์ซอฟต์แวร์
2. ผลการเฝ้าติดตามและทดสอบสภาพและการประยุกต์ใช้ระบบคุณภาพ ดำเนินการเป็นระยะๆ เพื่อกำหนดความเหมาะสมและประสิทธิผล
3. รายงานความพร้อมใช้งานและการบำรุงรักษาวิธีการตรวจสอบและรายงานที่เป็นเอกสารเกี่ยวกับผลลัพธ์ของคุณภาพที่บรรลุตามข้อกำหนดของข้อตกลงการรับรองกับลูกค้า
4. ผลลัพธ์ของการลงทะเบียนคุณสมบัติคุณภาพที่ได้รับของแพ็คเกจซอฟต์แวร์: การระบุ การสะสม การจัดเก็บข้อมูลที่ลงทะเบียนเกี่ยวกับคุณสมบัติและคุณลักษณะของคุณภาพของผลิตภัณฑ์ซอฟต์แวร์และส่วนประกอบ
5. ผลลัพธ์ของการดำเนินการตามแผนพัฒนา เอกสารข้อมูลอินพุตและเอาต์พุตของขั้นตอนการพัฒนาและโปรโตคอลสำหรับตรวจสอบการดำเนินการตามวงจรชีวิตของ PS
6. ผลลัพธ์ของการดำเนินการตามโปรแกรมคุณภาพในทางปฏิบัติและการดำเนินกิจกรรมที่ได้รับการควบคุมในด้านคุณภาพในทุกขั้นตอนของวงจรชีวิตของ PS
7. ผลลัพธ์ของการรับรองเครื่องจำลองสภาพแวดล้อมและเครื่องกำเนิดการทดสอบ ตลอดจนการประเมินความเพียงพอสำหรับการทดสอบผลิตภัณฑ์ซอฟต์แวร์
8. ผลการวิเคราะห์การดำเนินการตามแผนและวิธีการทดสอบ รายงานการทดสอบ การประเมินการปฏิบัติตามผลการทดสอบตามข้อกำหนด ตลอดจนผลการทดสอบที่ได้รับอนุมัติจากตัวแทนของผู้สมัคร ลูกค้า และซัพพลายเออร์
9. การกระทำของผลการตรวจสอบลักษณะที่แท้จริงของวงจรชีวิตของระบบซอฟต์แวร์และระบบคุณภาพขององค์กร สรุปเกี่ยวกับการปฏิบัติตามข้อกำหนดสำหรับการรับรองการผลิตผลิตภัณฑ์ซอฟต์แวร์
10. ใบรับรองระบบคุณภาพขององค์กรและ / หรือผลิตภัณฑ์ซอฟต์แวร์และการรับประกันวงจรชีวิต ใบอนุญาตสำหรับการใช้เครื่องหมายความสอดคล้อง

วรรณกรรม

วี.วี. ลิปาเยฟ -- โปรไฟล์มาตรฐานวงจรชีวิตซอฟต์แวร์ -- Jet Info, จดหมายข่าว, N 12 , 2005

เค. มิลแมน, เอส. มิลแมน -- SMMI เป็นก้าวสู่อนาคต -- ระบบเปิด, N 5-6. (2005), N2. (2006) , 2005, 2006

การประเมินและรับรองความสมบูรณ์ของกระบวนการในการสร้างและบำรุงรักษาเครื่องมือซอฟต์แวร์และระบบสารสนเทศ ISO IEC TR 15504-CMMI ต่อ. จากอังกฤษ -- ม.: หนังสือและธุรกิจ, 2001

วี.วี. ลิปาเยฟ -- กระบวนการและมาตรฐานของวงจรชีวิตของซอฟต์แวร์ที่ซับซ้อน ไดเรกทอรี-- ม.: SINTEG, 2006

วี.วี. ลิปาเยฟ -- วิธีการสร้างความมั่นใจในคุณภาพของซอฟต์แวร์ขนาดใหญ่-- ม.: RFBR. SINTEG ปี 2546

antisource: "ตอนนี้ผลิตภัณฑ์ซอฟต์แวร์ถูกใช้เพื่อแก้ปัญหาการจัดการในเกือบทุกด้านของกิจกรรมของมนุษย์: ในด้านเศรษฐกิจ สังคม การทหาร และด้านอื่นๆ การดูแลให้ผลิตภัณฑ์ซอฟต์แวร์ในประเทศมีคุณภาพสูงในระหว่างการพัฒนาและการส่งมอบจำนวนมากสำหรับแอปพลิเคชันต่างๆ ในประเทศและในตลาดโลกได้กลายเป็นงานเชิงกลยุทธ์"; เงื่อนไข: 1]$