องค์ประกอบรองรับมาตรฐาน IEEE 90 กระบวนการวงจรชีวิตของซอฟต์แวร์ คำอธิบายของสัญญาณเพื่อความถูกต้องของข้อมูลที่ส่ง

ในสาขาไอที มีการเผยแพร่มาตรฐานที่ใช้งานได้จริงที่สุดโดยองค์กรต่อไปนี้:

• สถาบันวิศวกรไฟฟ้าและอิเล็กทรอนิกส์(IEEE, www.ieee.org) เป็นองค์กรทางวิทยาศาสตร์และเทคนิคชั้นนำมาหลายปี รวมถึงในการสร้างมาตรฐานเอกสารประกอบ ซอฟต์แวร์- มาตรฐานส่วนใหญ่ได้รับการพัฒนาโดยคณะกรรมการต่างๆ ซึ่งประกอบด้วยวิศวกรมืออาชีพที่มีประสบการณ์และมีความรับผิดชอบ มาตรฐาน IEEE บางมาตรฐานยังกลายเป็นมาตรฐาน ANSI (American National Standards Institute) อีกด้วย มาตรฐาน IEEE ส่วนใหญ่เป็นพื้นฐานในการจัดทำ MU สำหรับ CP Schmidt M. การนำมาตรฐานวิศวกรรมซอฟต์แวร์ IEEE ไปใช้
• องค์กรระหว่างประเทศเรื่องการมาตรฐาน (ISO)มีอิทธิพลมหาศาลทั่วโลก โดยเฉพาะในกลุ่มผู้ผลิตที่เกี่ยวข้องกับสหภาพยุโรป (EU) ปัจจุบันมาตรฐานไอทีสมัยใหม่เกือบทั้งหมดที่แปลและนำไปใช้ในสหพันธรัฐรัสเซียเป็นมาตรฐานที่จัดทำโดย ISO ร่วมกับ International Electrotechnical Commission - IEC คุณทราบดีว่ามีการเอาใจใส่เป็นพิเศษเพื่อรับรองคุณภาพของผลิตภัณฑ์ที่ ระดับนานาชาติดังนั้นตามพระราชกฤษฎีกาของรัฐบาลสหพันธรัฐรัสเซียหมายเลข 113 เมื่อวันที่ 02/02/1998 การปฏิบัติตามข้อกำหนดของ ISO 9000 (ชุดมาตรฐานที่ควบคุมการจัดการคุณภาพ (การจัดการคุณภาพ) ในสถานประกอบการ) - ข้อกำหนดเบื้องต้นเพื่อรับคำสั่งจากทางราชการ
• สถาบันเทคโนโลยีวิศวกรรมซอฟต์แวร์(Software Engineering Institute - SEI, sei.cmu.edu - มากกว่า 1,000 บทความ) ก่อตั้งขึ้นโดยกระทรวงกลาโหมสหรัฐอเมริกาที่ Carnegie Mellon University เพื่อยกระดับเทคโนโลยีซอฟต์แวร์ในหมู่ผู้รับเหมาของกระทรวงกลาโหม งานของ SEI ยังได้รับการยอมรับจากบริษัทเชิงพาณิชย์หลายแห่งที่พิจารณาว่าการปรับปรุงกระบวนการพัฒนาซอฟต์แวร์เป็นเป้าหมายเชิงกลยุทธ์ งานขององค์กร- เราจะดูหนึ่งในมาตรฐานที่พัฒนาโดย SEI ที่เรียกว่า Capability Maturity Model (CMM)
• สมาคมเทคโนโลยีการจัดการวัตถุ(กลุ่มการจัดการวัตถุ, www.omg.org) คือ องค์กรที่ไม่แสวงหาผลกำไรซึ่งมีบริษัทเป็นสมาชิกประมาณ 700 แห่ง OMG กำหนดมาตรฐานสำหรับการคำนวณเชิงวัตถุแบบกระจาย ควรสังเกตว่า OMG ใช้ภาษาการสร้างแบบจำลองแบบรวม UML เป็นมาตรฐานในการอธิบายโครงการ เราจะศึกษา UML อย่างละเอียด เพราะ... การใช้ภาษานี้ร่วมกับกระบวนการรวมศูนย์จาก Rational เป็นพื้นฐานสำหรับการพัฒนาแกนหลักของโครงงานหลักสูตร

แนวคิดเกี่ยวกับวงจรชีวิตของระบบ

ความจำเป็นในการสร้างมาตรฐานการพัฒนาซอฟต์แวร์อธิบายไว้ในบทนำของมาตรฐานได้ดีที่สุด GOST R ISO/IEC 12207-99 " เทคโนโลยีสารสนเทศ- กระบวนการ วงจรชีวิต ซอฟต์แวร์» : “ซอฟต์แวร์เป็นส่วนสำคัญของเทคโนโลยีสารสนเทศและระบบดั้งเดิม เช่น การขนส่ง การทหาร การแพทย์ และการเงิน มีมาตรฐาน ขั้นตอน วิธีการ เครื่องมือ และประเภทของสภาพแวดล้อมการทำงานที่แตกต่างกันมากมายสำหรับการพัฒนาและการจัดการซอฟต์แวร์ ความหลากหลายนี้สร้างความท้าทายในการออกแบบและการจัดการซอฟต์แวร์ โดยเฉพาะอย่างยิ่งเมื่อรวมผลิตภัณฑ์ซอฟต์แวร์และ โปรแกรมบริการ- กลยุทธ์การพัฒนาซอฟต์แวร์จำเป็นต้องย้ายจากกลุ่มคนจำนวนมากไปสู่ลำดับทั่วไปที่จะช่วยให้ผู้ปฏิบัติงานซอฟต์แวร์ “พูดภาษาเดียวกัน” เมื่อพัฒนาและจัดการซอฟต์แวร์ มาตรฐานสากลนี้ให้คำสั่งทั่วไปเช่นนั้น”

มาตรฐาน GOST R ISO/IEC 12207-99กำหนดแนวคิดพื้นฐานของระบบซอฟต์แวร์ - “วงจรชีวิต” (GOST R ISO/IEC TO 15271-2002 “เทคโนโลยีสารสนเทศ แนวทางการประยุกต์ใช้ GOST R ISO/IEC 12207”)

GOST R ISO/IEC 12207-99แนะนำแนวคิดของแบบจำลองวงจรชีวิตเป็นโครงสร้างที่ประกอบด้วยกระบวนการและครอบคลุมอายุการใช้งานของระบบตั้งแต่การสร้างข้อกำหนดจนถึงสิ้นสุดการใช้งาน เสนอให้แก้ไขคำจำกัดความนี้และแบ่งออกเป็นสองคำจำกัดความ:

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

กระบวนการวงจรชีวิตแบ่งออกเป็นสามกลุ่ม:หลัก เสริม และองค์กร

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

รูปภาพ - กระบวนการหลักของวงจรชีวิตของ IS

กลุ่มของกระบวนการเสริมประกอบด้วยกระบวนการที่รับรองการดำเนินการของกระบวนการหลัก:

• เอกสาร;
• การจัดการการกำหนดค่า
• การประกันคุณภาพ
• การตรวจสอบ;
• การรับรอง;
• ระดับ;
• การตรวจสอบ;
• การแก้ปัญหา

กลุ่ม กระบวนการขององค์กรรวมถึงกระบวนการ:

• การจัดการโครงการ
• การสร้างโครงสร้างพื้นฐานของโครงการ
• การกำหนด การประเมิน และปรับปรุงวงจรชีวิต
• การศึกษา.

ในข้อความของ GOST 12207-99งานที่รวมอยู่ในกระบวนการหลัก เสริม และกระบวนการขององค์กรนั้นมีลักษณะโดยทั่วไป โดยทั่วไปแล้วมีเพียงทิศทางเท่านั้นที่สรุปไว้ ดังนั้นเพื่อเริ่มการออกแบบ จำเป็นต้องมีมาตรฐานและวรรณกรรมเพิ่มเติมที่เปิดเผยเนื้อหาของแต่ละกระบวนการ กระบวนการที่แยกจากกันหรือดีกว่านั้นคือแยกงานกัน
ในกลุ่มกระบวนการหลัก กระบวนการพัฒนาเป็นที่สนใจมากที่สุด
ควรสังเกตว่า GOST 34.601-90 “ ระบบอัตโนมัติ. ขั้นตอนของการสร้าง" กระบวนการสร้างระบบอัตโนมัติแบ่งออกเป็นขั้นตอนต่างๆ ดังนี้

• การสร้างข้อกำหนดสำหรับผู้พูด
• การพัฒนาแนวคิด AC
• เงื่อนไขการอ้างอิง
• การออกแบบเบื้องต้น
• โครงการด้านเทคนิค
• เอกสารการทำงาน,
• การว่าจ้าง,
• คลอ

ขั้นตอนแบ่งออกเป็นขั้นตอนซึ่งมีเนื้อหาซ้อนทับกับเนื้อหาของงานจำนวนหนึ่งที่อธิบายไว้ใน GOST 12207-99

กระบวนการพัฒนา

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

รูป - โครงสร้างกระบวนการพัฒนา

งานเตรียมการ

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

การวิเคราะห์ความต้องการ

การวิเคราะห์ข้อกำหนดซอฟต์แวร์เกี่ยวข้องกับการกำหนดคุณลักษณะต่อไปนี้สำหรับแต่ละองค์ประกอบของซอฟต์แวร์:

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

การออกแบบสถาปัตยกรรม

ระบบในระดับสูงคือการกำหนดส่วนประกอบของอุปกรณ์ ซอฟต์แวร์ และการปฏิบัติการของบุคลากรที่ปฏิบัติการระบบ สถาปัตยกรรมระบบจะต้องเป็นไปตามข้อกำหนดของระบบและมาตรฐานและแนวปฏิบัติการออกแบบที่เป็นที่ยอมรับ
การออกแบบสถาปัตยกรรมซอฟต์แวร์ประกอบด้วยงานต่อไปนี้ (สำหรับแต่ละองค์ประกอบของซอฟต์แวร์):

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

การออกแบบโดยละเอียด

PS รวมถึงงานต่อไปนี้:

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

การเข้ารหัสและการทดสอบ

PS ครอบคลุมงานต่อไปนี้:

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

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

GOST R ISO/IEC 12119-2000 “เทคโนโลยีสารสนเทศ แพ็คเกจซอฟต์แวร์ ข้อกำหนดด้านคุณภาพและการทดสอบ"มีคำแนะนำที่กำหนดขั้นตอนการทดสอบผลิตภัณฑ์เพื่อให้สอดคล้องกับข้อกำหนดด้านคุณภาพ การทดสอบเป็นกระบวนการที่ใช้แรงงานเข้มข้น ตามที่ผู้เชี่ยวชาญบางคนร้อยละ
การกระจายเวลาระหว่างกระบวนการออกแบบ-พัฒนา-ทดสอบอยู่ในอัตราส่วน 40-20-40 ในเรื่องนี้ระบบทดสอบอัตโนมัติกำลังแพร่หลาย มาตรฐาน IEEE 1209-1992 “แนวทางปฏิบัติที่แนะนำสำหรับการประเมินและการเลือกเครื่องมือ CASE” กำหนดข้อกำหนดทั่วไปสำหรับการทำงานของเครื่องมือทดสอบอัตโนมัติ

บูรณาการระบบ

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

การติดตั้งระบบ

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

การยอมรับของระบบ

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

แบบจำลองวงจรชีวิตของซอฟต์แวร์

แบบจำลองวงจรชีวิต– โครงสร้างที่กำหนดลำดับของกระบวนการ งาน และงานที่ดำเนินการตลอดวงจรชีวิตของระบบสารสนเทศ ตลอดจนความสัมพันธ์ระหว่างสิ่งเหล่านั้น

จนถึงปัจจุบัน โมเดลวงจรชีวิตหลัก 2 รูปแบบได้กลายเป็นที่แพร่หลายมากที่สุด:

• แบบจำลองน้ำตก (น้ำตก);
• รุ่นเกลียว

โมเดลน้ำตก

โมเดลน้ำตกแสดงให้เห็นถึงแนวทางการพัฒนาแบบคลาสสิก ระบบต่างๆในด้านการใช้งานต่างๆ เพื่อการพัฒนา ระบบสารสนเทศรุ่นนี้ใช้กันอย่างแพร่หลายในยุค 70 และครึ่งแรกของยุค 80 เป็นโมเดลแบบเรียงซ้อนที่สร้างพื้นฐานของ GOST ซีรีส์ 34.xxx และมาตรฐานกระทรวงกลาโหมสหรัฐอเมริกา DOD-STD-2167A ประมวลผล GOST 12207-99 ใน GOST 34.601-90 “ระบบอัตโนมัติ ขั้นตอนของการสร้างสรรค์”เรียกว่าขั้นและมีองค์ประกอบต่างกันเล็กน้อย
โมเดลแบบเรียงซ้อนจัดให้มีการจัดระเบียบกระบวนการตามลำดับ นอกจากนี้การเปลี่ยนไปใช้กระบวนการถัดไปจะเกิดขึ้นเฉพาะหลังจากที่งานก่อนหน้านี้เสร็จสมบูรณ์แล้วเท่านั้น แต่ละกระบวนการจบลงด้วยการเผยแพร่เอกสารครบชุด ซึ่งเพียงพอเพื่อให้ทีมพัฒนาอื่นสามารถดำเนินการต่อไปได้

ข้อเสียเปรียบหลักของแบบจำลองน้ำตกคือข้อผิดพลาดและข้อบกพร่องในขั้นตอนใด ๆ จะปรากฏขึ้นตามกฎในขั้นตอนต่อ ๆ ไปของการทำงานซึ่งนำไปสู่ความจำเป็นในการย้อนกลับ ตามข้อมูล บริษัทที่ปรึกษา Standish Group ในปี 1998 ในสหรัฐอเมริกา โครงการระบบสารสนเทศองค์กร (IT) มากกว่า 28% สิ้นสุดลงด้วยความล้มเหลว โครงการไอทีเกือบ 46% เสร็จสมบูรณ์เกินงบประมาณ (โดยเฉลี่ย 189%) และมีเพียง 26% ของโครงการเท่านั้นที่เหมาะกับทั้งกรอบเวลาและงบประมาณที่จัดสรร

นอกจากนี้ข้อเสียของแบบจำลองน้ำตก ได้แก่ :

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

รุ่นเกลียว

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

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

การพัฒนาแอปพลิเคชั่นอย่างรวดเร็ว

ในช่วงทศวรรษที่ 90 ของศตวรรษที่ 20 เทคโนโลยีเชิงปฏิบัติที่เรียกว่า "การพัฒนาแอปพลิเคชันอย่างรวดเร็ว" - RAD (การพัฒนาแอปพลิเคชันอย่างรวดเร็ว) ก่อตั้งขึ้นบนพื้นฐานของแบบจำลองเกลียว ในกรณีนี้ วงจรชีวิตประกอบด้วยสี่ขั้นตอน:

• การวิเคราะห์และการวางแผนความต้องการ
• ออกแบบ,
• การดำเนินการ
• การดำเนินการ

หลักการพื้นฐานของ RAD:

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

ในต้นปี 2544 ผู้เชี่ยวชาญชั้นนำจำนวนหนึ่งในสาขาวิศวกรรมซอฟต์แวร์ (Martin Fowler, Kent Beck ฯลฯ ) ได้ก่อตั้งกลุ่มชื่อ Agile Alliance เพื่อสนับสนุนและพัฒนาแนวทางใหม่ในการออกแบบ - "การพัฒนาซอฟต์แวร์อย่างรวดเร็ว" (Agile Software การพัฒนา). การใช้แนวทางนี้อย่างหนึ่งคือ Extreme Programming (XP)

หลักการของ Extreme Programming มีดังนี้:

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

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

• C - ข้อบกพร่องทำให้สูญเสียความสะดวก
• D – ข้อบกพร่องทำให้เกิดการสูญเสียเงินทุนที่เรียกคืนได้ (วัสดุหรือการเงิน)
• E – ข้อบกพร่องทำให้เกิดการสูญเสียเงินทุนที่ไม่สามารถถูกทดแทนได้
• L - ข้อบกพร่องก่อให้เกิดภัยคุกคามต่อชีวิตมนุษย์

ขนาดจะพิจารณาจากจำนวนนักพัฒนาที่เข้าร่วมในโครงการ:

• ตั้งแต่ 1 ถึง 6 คน - ขนาดเล็ก
• จาก 6 ถึง 20 คน – ขนาดกลาง
• มากกว่า 20 คน – ขนาดใหญ่

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

กระบวนการพัฒนาซอฟต์แวร์แบบครบวงจร

ปัจจุบันงานยังคงสร้างกระบวนการพัฒนา IS สากลบางประเภทต่อไป ในปี 1999 พนักงานที่มีเหตุผล Ivar Jacobson, Gradi Booch และ James Rumbaugh ตีพิมพ์หนังสือ Unified Software Development Process ซึ่งได้รับการแปลเป็นภาษารัสเซียและจัดพิมพ์โดย Peter Publishing House ในปี 2002 The Unified Process เป็นความพยายามที่จะรวม Waterfall และแบบจำลองวนซ้ำ Life Cycle

ในขณะเดียวกัน วงจรชีวิตก็แบ่งออกเป็น 4 ระยะ คือ

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

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

• คำจำกัดความของข้อกำหนด (RD);
• การวิเคราะห์ (ก);
• การออกแบบ (ป);
• การนำไปปฏิบัติ (P);
• การทดสอบ (T)

หัวข้องานเพิ่มเติมอาจรวมถึง:

• งานประกันคุณภาพ (K)
• เอกสารประกอบ (D)
• การจัดการโครงการ (P)
• การจัดการการกำหนดค่า (CM)
• การสร้างและการจัดการโครงสร้างพื้นฐาน (I)
• และอื่น ๆ

รูปภาพ - แบบจำลองวงจรชีวิตตามกระบวนการพัฒนาซอฟต์แวร์แบบครบวงจร

การเลือกแบบจำลองวงจรชีวิตส่วนใหญ่ขึ้นอยู่กับประเภทและขนาดของระบบที่กำลังพัฒนา สำหรับการพัฒนาระบบควบคุมอัตโนมัติส่วนใหญ่ที่มีเวลาว่าง แบบจำลองวงจรชีวิตซ้ำจะถูกนำมาใช้ ในขณะที่แบบจำลองน้ำตกเหมาะสำหรับระบบเรียลไทม์มากกว่า ในระหว่างการบรรยาย เมื่อศึกษาประเด็นการออกแบบ IS เราจะให้ความสนใจเป็นพิเศษกับการใช้ Unified Modeling Language (UML) และเนื่องจากผู้สร้างคือ Grady Booch และ James Rumbaugh เราจึงจะหันมาใช้อุดมการณ์ Unified Development Process ด้วย

การวาดภาพ - เอกสารกำกับดูแลควบคู่ไปกับกระบวนการพัฒนา

สนับสนุนกระบวนการวงจรชีวิต

กระบวนการประกันคุณภาพ

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

รูปที่ - โครงสร้างของกระบวนการวงจรชีวิตเสริม

ในบริบทของ GOST R ISO/IEC 9126-93 “เทคโนโลยีสารสนเทศ การประเมินผลิตภัณฑ์ซอฟต์แวร์ ลักษณะคุณภาพและแนวทางสำหรับการใช้งาน "ลักษณะคุณภาพ" เป็นที่เข้าใจกันว่าเป็น "ชุดของคุณสมบัติ (คุณลักษณะ) ของผลิตภัณฑ์ซอฟต์แวร์ที่ใช้อธิบายและประเมินคุณภาพ"

มาตรฐานกำหนดคุณลักษณะที่ครอบคลุมหกประการซึ่งอธิบายคุณภาพของซอฟต์แวร์โดยมีการทำซ้ำน้อยที่สุด:

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

GOST 28195-89 “การประเมินคุณภาพของซอฟต์แวร์ บทบัญญัติทั่วไป» ที่ด้านบน ระดับแรก ระบุตัวบ่งชี้ 6 ประการ ได้แก่ ปัจจัยด้านคุณภาพ: ความน่าเชื่อถือ ความถูกต้อง ความง่ายในการใช้งาน ประสิทธิภาพ ความคล่องตัว และการบำรุงรักษา ปัจจัยเหล่านี้มีรายละเอียดรวมกันตามเกณฑ์คุณภาพ 19 ข้อในระดับที่สอง รายละเอียดเพิ่มเติมของตัวบ่งชี้คุณภาพจะแสดงโดยตัวชี้วัดและองค์ประกอบการประเมินซึ่งมีประมาณ 240 รายการ แนะนำให้ประเมินแต่ละรายการอย่างเชี่ยวชาญตั้งแต่ 0 ถึง 1 องค์ประกอบของปัจจัยเกณฑ์และตัวชี้วัดที่ใช้เสนอให้เลือก ขึ้นอยู่กับวัตถุประสงค์ ฟังก์ชัน และขั้นตอนของวงจรชีวิตของซอฟต์แวร์

มาตรฐาน GOST 28806-90 “คุณภาพของซอฟต์แวร์ ข้อกำหนดและคำจำกัดความ”เป็นทางการ แนวคิดทั่วไปโปรแกรม เครื่องมือซอฟต์แวร์ ผลิตภัณฑ์ซอฟต์แวร์ และคุณภาพ คำจำกัดความจะได้รับจากคำศัพท์ที่ใช้บ่อยที่สุด 18 คำที่เกี่ยวข้องกับการประเมินคุณลักษณะของโปรแกรม แนวคิดของตัวบ่งชี้คุณภาพพื้นฐานที่กำหนดใน GOST 28195-89 ได้รับการชี้แจงแล้ว
ประเด็นเรื่องการรับรองคุณภาพ PS จำเป็นต้องมี ความสนใจเป็นพิเศษเนื่องจากตามพระราชกฤษฎีกาของรัฐบาลรัสเซียฉบับที่ 113 เมื่อวันที่ 02/02/1998 การปฏิบัติตามข้อกำหนดของการประกันคุณภาพและมาตรฐานการจัดการระดับสากล ISO 9000 จึงเป็นข้อกำหนดเบื้องต้นในการรับคำสั่งจากรัฐบาล
บน เวทีที่ทันสมัยการมีเพียงวิธีการประเมินคุณภาพของซอฟต์แวร์ที่ผลิตและใช้แล้วนั้นไม่เพียงพอ (การควบคุมเอาต์พุต) จำเป็นต้องสามารถวางแผนคุณภาพ วัดผลในทุกขั้นตอนของวงจรชีวิตซอฟต์แวร์ และปรับกระบวนการผลิตซอฟต์แวร์ให้เหมาะสม ปรับปรุงคุณภาพ

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

• เอกสารประกอบ,
• ความต้องการ,
• ผลการวิเคราะห์
• ออกแบบ,
• รายการ ฯลฯ

ความเกี่ยวข้องของการตรวจสอบแสดงโดยการเปรียบเทียบต้นทุนและการตรวจจับและการแก้ไขข้อบกพร่องระหว่างการตรวจสอบและระหว่างการรวมตาม Fagin, M., “การออกแบบและการตรวจสอบโค้ดเพื่อลดข้อผิดพลาดในการพัฒนาโปรแกรม” IBM Systems Journal ผู้เขียนบางคนถือว่าข้อมูลเหล่านี้ถูกประเมินต่ำไปมาก

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

ในการดำเนินการตรวจสอบ จำเป็นต้องมีขั้นตอนต่อไปนี้:

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

บริษัทเก็บรักษาบันทึกเวลาที่ใช้ในการตรวจสอบและปริมาณงานที่ตรวจสอบเพื่อใช้ในการประเมินการตรวจสอบในอนาคตต่อไป ภายใต้เงื่อนไขของการจำกัดเวลาที่เข้มงวดที่เรียกว่า ระบบ "การสอนพิเศษ" ที่สมาชิกในทีมแต่ละคนได้รับการดูแลโดยเพื่อนร่วมงานของเขา
หากต้องการคำนึงถึงปัจจัยการควบคุมคุณภาพทั้งหมด จึงสะดวกในการใช้รายการ คำถามทดสอบ- รายการดังกล่าวประกอบด้วยรายการที่ต้องตรวจสอบตามลำดับ
ตัวอย่างเช่น Software Quality Assurance Plan (SQAP) ตามมาตรฐาน IEEE 739-1989 ระบุ:

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

ความน่าเชื่อถือและความปลอดภัย

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

มาตรฐานในสนาม ความปลอดภัยของข้อมูลแบ่งออกเป็นสองกลุ่ม:

• มาตรฐานการประเมินที่ออกแบบมาเพื่อประเมินและจำแนก IP และผลิตภัณฑ์ความปลอดภัยตามข้อกำหนดด้านความปลอดภัย - มาตรฐานกระทรวงกลาโหมสหรัฐอเมริกา “เกณฑ์การประเมินที่เชื่อถือได้ ระบบคอมพิวเตอร์", "เกณฑ์ที่สอดคล้องกันของประเทศในยุโรป", มาตรฐานสากล "เกณฑ์ในการประเมินความปลอดภัยของเทคโนโลยีสารสนเทศ", เอกสารแนวทางของคณะกรรมการเทคนิคแห่งรัฐของรัสเซีย;
• ข้อกำหนดที่ควบคุม ด้านต่างๆการใช้งานและการใช้เครื่องมือและวิธีการรักษาความปลอดภัยที่เผยแพร่โดย Internet Engineering Task Force (IETF) และแผนกย่อย - คณะทำงานเกี่ยวกับความปลอดภัย

มาตรฐานการประเมินที่สำคัญที่สุด ได้แก่ :

• คณะกรรมการเทคนิคแห่งรัฐรัสเซีย เอกสารคำแนะนำ- สิ่งอำนวยความสะดวกด้านคอมพิวเตอร์ ไฟร์วอลล์ การป้องกันการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต ตัวชี้วัดความปลอดภัยจากการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต – มอสโก, 1997 – แบ่งประเภทไฟร์วอลล์ตามระดับการกรองกระแสข้อมูลของแบบจำลองอ้างอิงเจ็ดระดับ
• ISO/IEC 15408:1999 เกณฑ์การประเมินความปลอดภัยของเทคโนโลยีสารสนเทศ

กลุ่มที่สองประกอบด้วยเอกสารดังต่อไปนี้:

• สถาปัตยกรรมความปลอดภัย X.800 สำหรับการทำงานร่วมกัน ระบบเปิด- บริการรักษาความปลอดภัยเครือข่ายหลักถูกเน้น: การรับรองความถูกต้อง การควบคุมการเข้าถึง การรับรองการรักษาความลับ และ/หรือความสมบูรณ์ของข้อมูล ในการใช้บริการจะมีการจัดเตรียมกลไกความปลอดภัยเครือข่ายต่อไปนี้และชุดค่าผสม: การเข้ารหัส อิเล็กทรอนิกส์ ลายเซ็นดิจิทัล, การควบคุมการเข้าถึง, การควบคุมความสมบูรณ์ของข้อมูล, การรับรองความถูกต้อง, การขยายการรับส่งข้อมูล, การควบคุมเส้นทาง, การรับรองเอกสาร
• ข้อกำหนดชุมชนอินเทอร์เน็ต RFC 1510, Kerberos Network Authentication Service (V5) แก้ไขปัญหาการตรวจสอบความถูกต้องในสภาพแวดล้อมแบบกระจายที่แตกต่างกันพร้อมการสนับสนุนแนวคิดของการลงชื่อเข้าระบบครั้งเดียวในเครือข่าย
• X.500 “บริการไดเรกทอรี: ภาพรวมของแนวคิด โมเดล และบริการ”, X.509 “บริการไดเรกทอรี: กรอบงานใบรับรอง” กุญแจสาธารณะและคุณลักษณะ"

กระบวนการตรวจสอบ การรับรอง และการตรวจสอบ

การตรวจสอบรับรองและการตรวจสอบมี ส่วนสำคัญแผนควบคุมคุณภาพ IEEE 739-1989 SQAP
การยืนยันจะตอบคำถาม: “เรากำลังทำสิ่งที่เราวางแผนไว้ในขั้นตอนนี้หรือไม่” การรับรองและการตรวจสอบตอบคำถาม: “สิ่งอำนวยความสะดวกที่อยู่ระหว่างการก่อสร้างตรงตามความต้องการของลูกค้าหรือไม่”
มาตรฐาน IEEE 1012-1986 Software Verification and Validation Plan (SVVP) เป็นการรวมกระบวนการรับรองและการตรวจสอบที่เรียกว่าการตรวจสอบความถูกต้อง และกำหนดวิธีดำเนินการ

ในระหว่างกระบวนการตรวจสอบ จะมีการตรวจสอบเงื่อนไขต่อไปนี้:

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

กระบวนการทบทวนร่วมกัน

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

กระบวนการแก้ไขปัญหา

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

สาเหตุของความเสี่ยงอาจเป็นดังต่อไปนี้:

1. การกำหนดข้อกำหนดที่ไม่ชัดเจนและ/หรือไม่สมบูรณ์
2. การมีส่วนร่วมของผู้มีส่วนได้ส่วนเสียในโครงการไม่เพียงพอ
3. การวางแผนไม่ดี - ขาดการจัดการโครงการที่มีความสามารถ
4. การเปลี่ยนแปลงข้อกำหนดบ่อยครั้งที่เกิดจากการเปลี่ยนแปลงขอบเขต เป้าหมายโครงการ และเหตุผลอื่น ๆ
5. ความไม่สมบูรณ์ของเทคโนโลยีการออกแบบที่ใช้
6. ขาดความรู้หรือทักษะในหมู่นักแสดง

มีสองวิธีในการป้องกันความเสี่ยง:

1. การเปลี่ยนแปลงข้อกำหนดของโครงการเพื่อขจัดสาเหตุของความเสี่ยง
2. การพัฒนาเทคโนโลยี การแก้ปัญหาที่เกี่ยวข้องกับการเกิดความเสี่ยง

ในระหว่างกระบวนการบริหารโครงการ ผู้จัดการจะต้องเริ่มกระบวนการระบุความเสี่ยงในส่วนต่างๆ ของโครงการเป็นระยะๆ เพื่อรวบรวมรายการความเสี่ยงที่รอการแก้ไข สำหรับแต่ละความเสี่ยงจะมีการกำหนดค่าสามค่า: ความน่าจะเป็นของความเสี่ยงที่เกิดขึ้น; ความเสียหายที่เกิดกับโครงการจากความเสี่ยงนี้หากเกิดขึ้น การประมาณต้นทุนในการขจัดความเสี่ยง ค่าทั้งหมดใช้สเกลเดียวกัน เช่น 1 – 10

กระบวนการจัดการเอกสารและการกำหนดค่า

“การจัดการเอกสารโครงการซอฟต์แวร์ต้องใช้ความพยายามขององค์กรอย่างมาก เนื่องจาก... เอกสารคือ ระบบที่ซับซ้อนขึ้นอยู่กับการเปลี่ยนแปลงอย่างต่อเนื่องซึ่งหลายคนสามารถทำได้พร้อมๆ กัน" (อี. โบรด์)

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

GOST R ISO/IEC 9294-93 “เทคโนโลยีสารสนเทศ แนวทางการจัดการเอกสารซอฟต์แวร์" กำหนดแนวทางสำหรับ การจัดการที่มีประสิทธิภาพจัดทำเอกสาร PS วัตถุประสงค์ของมาตรฐานคือการช่วยในการกำหนดกลยุทธ์สำหรับการจัดทำเอกสารซอฟต์แวร์ การเลือกมาตรฐานเอกสาร การเลือกขั้นตอนเอกสาร การกำหนดทรัพยากรที่จำเป็น จัดทำแผนเอกสาร

การจัดการเอกสารเกี่ยวข้องกับการทำให้มันสมบูรณ์และสม่ำเสมอ (ผู้เขียนบางคนรวมการจัดการการกำหนดค่าไว้ที่นี่)

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

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

• // ข้อกำหนด 4.3
• // ผู้เขียน
• // รุ่น
• // ข้อโต้แย้ง
• ...รายการวิธีการ...

ส่วนของโครงการไม่เพียงแต่รวมถึงซอร์สโค้ดของโปรแกรมเท่านั้น แต่ยังรวมไปถึงเอกสารประกอบทั้งหมด รวมถึงแผนโครงการด้วย ในช่วงชีวิตของพวกเขา โครงการต่างๆ มีการเปลี่ยนแปลงในสองทิศทาง:

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

เพื่อติดตามส่วนของโครงการ คุณต้องกำหนดขอบเขตและระบุรายการการกำหนดค่า (CI)
มีเครื่องมือซอฟต์แวร์พิเศษสำหรับการจัดการการกำหนดค่า (เช่น Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion เป็นต้น)

โดยทั่วไป ระบบการจัดการการกำหนดค่าจะเป็นไปตามข้อกำหนดขั้นต่ำต่อไปนี้:

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

IEEE พัฒนามาตรฐาน IEEE 828-1990“แผนการจัดการการกำหนดค่าซอฟต์แวร์ (SCMP)” ชื่อของมาตรฐานและตัวอย่างของแผนการจัดการการกำหนดค่ามีให้ไว้ในหนังสือโดย Eric Braude

รูป - เอกสารข้อบังคับของกระบวนการวงจรชีวิตเสริม

กระบวนการวงจรชีวิตขององค์กร

กระบวนการขององค์กรในวงจรชีวิตประกอบด้วย กระบวนการสร้างโครงสร้างพื้นฐาน กระบวนการปรับปรุง กระบวนการฝึกอบรม กระบวนการบริหารจัดการ

รูปที่ - โครงสร้างของกระบวนการวงจรชีวิตขององค์กร

กระบวนการสร้างโครงสร้างพื้นฐาน

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

1. มีการระบุตัวบ่งชี้พื้นฐานของระบบที่เลือก ซึ่งมีความสำคัญเมื่อออกแบบ ACS ที่กำหนด โดยคำนึงถึงคุณลักษณะ ข้อจำกัด ทรัพยากร ฯลฯ
2. ตัวบ่งชี้ทั้งหมดสรุปไว้ในตาราง (ดูตารางที่ 5) ซึ่งตามการประเมินของผู้เชี่ยวชาญ ตัวบ่งชี้แต่ละตัวจะได้รับการกำหนดค่าสัมประสิทธิ์น้ำหนัก Vi (เช่น ตั้งแต่ 1 ถึง 10) ซึ่งแสดงลักษณะความสำคัญของตัวบ่งชี้นี้เมื่อเปรียบเทียบกับตัวบ่งชี้อื่นๆ ผลรวมของค่าสัมประสิทธิ์การถ่วงน้ำหนักทั้งหมดจะต้องเท่ากับขีดจำกัดบนของสัมประสิทธิ์การถ่วงน้ำหนัก (เช่น 10)
3. การใช้ข้อมูลที่ได้รับจากแหล่งวรรณกรรมและ/หรือจากผู้เชี่ยวชาญ สำหรับแต่ละตัวบ่งชี้ที่ i สำหรับแต่ละระบบ j-th ระดับของอรรถประโยชน์ Ui,j จะถูกกำหนด (จาก 1 - ขั้นต่ำ ถึง 10 - สูงสุด) ตัวอย่างเช่น ระบบการจัดการการกำหนดค่าที่ค่อนข้างแพงอาจมีระดับยูทิลิตี้อยู่ที่ 1 ในขณะที่ระบบที่ใช้งานได้อย่างอิสระจะมีระดับยูทิลิตี้อยู่ที่ 10
4. สำหรับระบบ j แต่ละระบบที่ถูกเปรียบเทียบ ค่าของฟังก์ชันการประเมินจะถูกคำนวณโดยใช้สูตร: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. ขึ้นอยู่กับค่าของฟังก์ชันการประเมิน มีการสรุปเกี่ยวกับความเหมาะสมในการใช้ระบบเฉพาะในโครงการที่กำหนด โดยคำนึงถึงเกณฑ์ที่เลือกและข้อจำกัดที่ระบุ ระบบที่มีค่าฟังก์ชันการประเมินมากกว่าจะเป็นระบบที่ดีที่สุดในแง่ของการเลือกจากทางเลือกอื่นๆ ที่เปรียบเทียบกัน

กระบวนการเรียนรู้

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

กระบวนการปรับปรุง

เป็นกระบวนการสร้าง ประเมิน วัด ควบคุม และปรับปรุงกระบวนการวงจรชีวิตของซอฟต์แวร์ ในการปฏิบัติงานด้านวิศวกรรม เมื่อพัฒนา IS จะใช้เมตริก - คุณลักษณะเชิงปริมาณของตัวบ่งชี้บางตัว

ตัวชี้วัดที่ใช้บ่อยที่สุดคือ:

• ปริมาณงานที่ทำ วัดเป็นหน่วยทางกายภาพ (เช่น จำนวนบรรทัดของโค้ด)
• เวลาที่ใช้ในการทำงาน
• อัตราข้อบกพร่อง (เช่น จำนวนข้อบกพร่องต่อโค้ด 1,000 บรรทัด จำนวนข้อบกพร่องต่อหน้าเอกสาร ฯลฯ)

คาดการณ์ค่าเมตริกเบื้องต้นหรือที่ต้องการล่วงหน้าแล้วเปรียบเทียบกับผลลัพธ์ที่ได้รับ
เนื่องจากตัวชี้วัดที่เกี่ยวข้องกับการเล่นบกพร่อง บทบาทพิเศษเราแสดงรายการบางส่วนไว้:

1. จำนวนข้อบกพร่องต่อโค้ดซอฟต์แวร์พันบรรทัดที่ระบุภายใน 12 สัปดาห์หลังการส่งมอบโครงการ
2. การเบี่ยงเบนในกำหนดการในแต่ละระยะ: (ระยะเวลาจริง - ระยะเวลาที่วางแผนไว้) / ระยะเวลาที่วางแผนไว้
3. การเบี่ยงเบนของต้นทุน: (ต้นทุนจริง - ต้นทุนที่วางแผนไว้) / ต้นทุนที่วางแผนไว้
4. เวลาออกแบบทั้งหมด / เวลาการเขียนโปรแกรมทั้งหมด (ตามการประมาณการบางอย่างควรมีอย่างน้อย 50%)
5. ระดับของข้อบกพร่องที่ปรากฏและตรวจพบในบางขั้นตอนถือเป็นหนึ่งในตัวชี้วัดที่ง่ายที่สุด

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

ขั้นตอนที่พบข้อบกพร่อง (ในโครงการ / มาตรฐานนี้)	ขั้นตอนที่มีข้อบกพร่อง
	การก่อตัวของข้อกำหนด	เงื่อนไขการอ้างอิง	การออกแบบร่าง
การก่อตัวของข้อกำหนด	2/5
เงื่อนไขการอ้างอิง	0,5/1,5	3/1
การออกแบบร่าง	0,1/0,3	1/3	2/2

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

ลำดับของการดำเนินการที่ต้องดำเนินการตลอดวงจรชีวิตของโครงการเพื่อปรับปรุงให้ดีขึ้น อาจเป็นดังนี้:

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

โมเดลการเจริญเติบโตของความสามารถขององค์กร

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

กระบวนการบริหารจัดการ

การจัดการโครงการคือการบรรลุความสมดุลระหว่างต้นทุน ความสามารถ คุณภาพ และกำหนดการ มีหลายแง่มุมที่เกี่ยวข้องกับกระบวนการบริหารโครงการ: การบริหารงานบุคคล การจัดกำหนดการ การประมาณต้นทุนโครงการ

การบริหารงานบุคคล

ข้อมูลเชิงประจักษ์เป็นที่ทราบกันดีว่ากำหนดจำนวนสมาชิกในทีมที่เหมาะสมที่สุด

รูปที่ - การพึ่งพาประสิทธิภาพของทีมพัฒนาต่อองค์ประกอบ

การพึ่งพาอาศัยกันนี้นำไปสู่ความจำเป็นในการใช้โครงสร้างการจัดการแบบลำดับชั้น

รูปที่ - โครงสร้างการจัดการแบบลำดับชั้น

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

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

กำลังเตรียมกำหนดการ

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

รูปภาพ - มุมมองโดยประมาณของแผนภูมิแกนต์

ขอแนะนำให้แผนรวมช่วงบัฟเฟอร์เมื่อไม่มีการกำหนดกระบวนการให้รัน กำหนดการในรูปแบบของแผนภูมิแกนต์ ในกรณีส่วนใหญ่ สร้างขึ้นโดยใช้ Microsoft Office Project
กระบวนการวางแผนงานเพื่อดำเนินโครงการโดยเฉพาะและการจัดการโครงการโดยทั่วไปเกี่ยวข้องกับการประมาณต้นทุนและระยะเวลาของโครงการ ข้อมูลนี้มีให้ไว้ในส่วนที่ 5.4 “การจัดสรรงบประมาณและทรัพยากร” SPMP และนอกจากนี้ การประเมินเบื้องต้นของต้นทุนของโครงการอาจส่งผลกระทบต่อสัญญาขั้นสุดท้ายระหว่างลูกค้าและผู้รับเหมา ดังนั้นจึงต้องดำเนินการก่อนที่จะลงนามในเงื่อนไขการอ้างอิง

การประมาณต้นทุนสำหรับการสร้าง PS

ตามกฎแล้วกระบวนการประมาณความเข้มของแรงงานเริ่มต้นพร้อมกันกับจุดเริ่มต้นของโครงการและดำเนินต่อไปแม้ในขั้นตอนของการเขียนโค้ดโปรแกรม

วิธีทั่วไปในการประเมินความเข้มข้นของแรงงานมีดังต่อไปนี้:

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

วิธีการประเมินแต่ละวิธีก็มีจุดอ่อนและ จุดแข็งจึงมีการนำแนวทางที่ผสมผสานวิธีการต่างๆ มาใช้ในปัจจุบัน

ขั้นตอนการประเมินความเข้มข้นของแรงงานในการพัฒนาซอฟต์แวร์ประกอบด้วยขั้นตอนต่อไปนี้:

1. การประมาณขนาดของผลิตภัณฑ์ที่กำลังพัฒนา
2. การประเมินความเข้มข้นของแรงงานเป็นเดือนหรือชั่วโมงทำงาน
3. การประมาณระยะเวลาของโครงการในเดือนปฏิทิน
4. การประมาณต้นทุนโครงการ

หน่วยการวัดขนาดซอฟต์แวร์หลักคือ:

• จำนวนบรรทัดของรหัส (LOC – บรรทัดของรหัส);
• จุดฟังก์ชัน (FP – จุดฟังก์ชัน)

ระเบียบวิธีในการประเมินขนาดการทำงาน

ระเบียบวิธีในการประเมินขนาดการทำงาน (FP – จุดการทำงาน)คือการวัดความสามารถทั้งหมดของแอปพลิเคชันอย่างสม่ำเสมอและแสดงขนาดของแอปพลิเคชันเป็นตัวเลขตัวเดียว หมายเลขนี้สามารถใช้เพื่อประมาณจำนวนบรรทัดของโค้ด ต้นทุน และไทม์ไลน์ของโครงการ
ในการคำนวณขนาดการทำงาน จะมีการกำหนดอันดับและความซับซ้อนสำหรับคุณลักษณะข้อมูลแต่ละอย่างของระบบ กลุ่มผู้ใช้จุดฟังก์ชันระหว่างประเทศ (IFPUG, www.ifpug.org) ได้เผยแพร่เกณฑ์สำหรับการระบุลักษณะข้อมูล ซึ่งแบ่งออกเป็นห้ากลุ่ม:

• – กลุ่มข้อมูลที่เกี่ยวข้องเชิงตรรกะที่ผู้ใช้รู้จักซึ่งอยู่ภายในแอปพลิเคชันและให้บริการผ่านอินพุตภายนอก

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

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

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

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

บารีชนิโควา มารีน่า ยูริเยฟนา
ฉัน N.E. บาวแมน
คาเฟ่ ไอยู-7

การบรรยายครั้งที่ 3

วงจรชีวิตของซอฟต์แวร์
บทบัญญัติ

วงจรชีวิตของซอฟต์แวร์

เป็นช่วงเวลาที่เริ่มต้นด้วย
ช่วงเวลาแห่งการตัดสินใจ
ความจำเป็นในการสร้างซอฟต์แวร์
บทบัญญัติและสิ้นสุดในขณะนั้น
เป็นการถอนตัวจากการให้บริการโดยสมบูรณ์
(IEEE Std. 610.12 – 19990 อภิธานศัพท์มาตรฐานของซอฟต์แวร์
คำศัพท์ทางวิศวกรรม)

แนวคิดพื้นฐานที่เกี่ยวข้องกับการกำหนดวงจรชีวิต

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

วงจรชีวิตของซอฟต์แวร์ตามมาตรฐาน ISO/IEC 12207: 1995
"เทคโนโลยีระหว่างประเทศ - กระบวนการวงจรชีวิตของซอฟต์แวร์"
(GOST ISO IEC 12207-99 เทคโนโลยีสารสนเทศ
วงจรชีวิตของซอฟต์แวร์)
วงจรชีวิต
องค์กร
กระบวนการ
ควบคุม
โครงการ
การสร้าง
โครงสร้างพื้นฐาน
การประเมินผลและการปรับปรุง
วงจรชีวิต
การศึกษา
ขั้นพื้นฐาน
กระบวนการ
การได้มา
เสริม
กระบวนการ
เอกสารประกอบ
จัดหา
ควบคุม
การกำหนดค่า
การพัฒนา
ความปลอดภัย
คุณภาพ
การดำเนินการ
การยืนยัน
คุ้มกัน
การรับรอง
ข้อต่อ
ระดับ
การตรวจสอบ
การอนุญาต
ปัญหา

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

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

กระบวนการพัฒนา

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

กระบวนการพัฒนา

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

10. การวิเคราะห์ความต้องการของระบบ

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

11. การวิเคราะห์ข้อกำหนดซอฟต์แวร์

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

12. การออกแบบสถาปัตยกรรมซอฟต์แวร์

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

13. การออกแบบซอฟต์แวร์โดยละเอียด (แผนงานพัฒนาซอฟต์แวร์)

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

14. การเข้ารหัสและการทดสอบซอฟต์แวร์เกี่ยวข้องกับการแก้ไขงานต่อไปนี้:

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

15. บูรณาการระบบ

ประกอบด้วยการประกอบทั้งหมด
ส่วนประกอบต่างๆ รวมถึงซอฟต์แวร์และ
อุปกรณ์และการทดสอบ
ส่วนประกอบรวม
กระบวนการบูรณาการยังก่อให้เกิด
การลงทะเบียนและการตรวจสอบชุดที่สมบูรณ์
เอกสารระบบ

16. การทดสอบคุณสมบัติซอฟต์แวร์

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

17. การติดตั้งและการยอมรับซอฟต์แวร์

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

18. การทำงานของซอฟต์แวร์

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

19. การบำรุงรักษาซอฟต์แวร์ (ตามมาตรฐาน IEEE – 90)

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

20. สนับสนุนกระบวนการของวงจรชีวิตซอฟต์แวร์

เอกสารประกอบ
การจัดการการกำหนดค่า
การประกันคุณภาพ
การยืนยัน
การรับรอง
การประเมินแบบมีส่วนร่วม
การตรวจสอบ
การแก้ไขปัญหา

21. กระบวนการจัดทำเอกสาร

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

22. การจัดการการกำหนดค่า

การกำหนดค่าซอฟต์แวร์คือ
จำนวนทั้งสิ้นของการทำงานและทางกายภาพของมัน
ลักษณะที่กำหนดไว้ในด้านเทคนิค
เอกสารประกอบและนำไปใช้ในโปรแกรม
กระบวนการนี้ทำให้คุณสามารถจัดระเบียบได้อย่างเป็นระบบ
คำนึงถึงและควบคุมการเปลี่ยนแปลงให้
ซอฟต์แวร์ในทุกขั้นตอนของวงจรชีวิต
หลักการทั่วไปและคำแนะนำสำหรับการจัดการการกำหนดค่าสะท้อนให้เห็น
ในมาตรฐาน ISO/IEC CD 12207 – 2:1995 “เทคโนโลยีสารสนเทศ – ซอฟต์แวร์”
กระบวนการวงจร ส่วนที่ 2 การจัดการการกำหนดค่าสำหรับซอฟต์แวร์”

23. กระบวนการประกันคุณภาพ

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

24. การตรวจสอบ

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

25. การรับรอง

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

26. กระบวนการองค์กรของวงจรชีวิตซอฟต์แวร์

ควบคุม
การสร้างโครงสร้างพื้นฐาน (infrastructure
โครงการซอฟต์แวร์ประกอบด้วยเทคโนโลยีและ
มาตรฐานตลอดจนชุดฮาร์ดแวร์
ซอฟต์แวร์และเครื่องมือสำหรับ
การพัฒนา การดำเนินงาน หรือการบำรุงรักษาซอฟต์แวร์)
การปรับปรุง
การฝึกอบรม (การฝึกอบรมเบื้องต้นและ
เพิ่มขึ้นอย่างถาวรตามมา
คุณสมบัติบุคลากรรวมทั้งการพัฒนา
สื่อการสอน)

27. กลุ่มมาตรฐาน ESPD

รหัสกลุ่ม
0
1
2
3
4
5
6
7
8
9
ชื่อกลุ่ม
บทบัญญัติทั่วไป
มาตรฐานพื้นฐาน
กฎการดำเนินการเอกสารการพัฒนา
กฎสำหรับการกรอกเอกสารการผลิต
กฎการดำเนินการเอกสารสนับสนุน
กฎสำหรับการดำเนินการตามเอกสารการปฏิบัติงาน
กฎสำหรับการเผยแพร่เอกสารซอฟต์แวร์
กลุ่มสำรอง
มาตรฐานอื่นๆ
การกำหนดมาตรฐาน ESPD ประกอบด้วย:
หมายเลข 19 (กำหนดให้กับคลาสมาตรฐาน ESPD)
หนึ่งหลัก (หลังจุด) ระบุรหัสของกลุ่มการจำแนกมาตรฐาน
ระบุไว้ในตาราง
ตัวเลขสองหลัก (หลังขีดกลาง) ระบุปีที่จดทะเบียนมาตรฐาน

28. รายการเอกสาร ESPD

GOST 19.001-77 อีเอสพีดี บทบัญญัติทั่วไป
GOST 19.101-77 ESPD ประเภทของโปรแกรมและเอกสารโปรแกรม
GOST 19.102-77 ESPD ขั้นตอนการพัฒนา
GOST 19.103-77 ESPD การกำหนดโปรแกรมและเอกสารโปรแกรม
GOST 19.104-78 อีเอสพีดี จารึกพื้นฐาน
GOST 19.105-78 อีเอสพีดี ข้อกำหนดทั่วไปเพื่อโปรแกรมเอกสาร
GOST 19.106-78 อีเอสพีดี ข้อกำหนดสำหรับเอกสารโปรแกรมที่พิมพ์
GOST 19.201-78 อีเอสพีดี ข้อกำหนดทางเทคนิค ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.202-78 อีเอสพีดี ข้อมูลจำเพาะ ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.301-79 ESPD ขั้นตอนและวิธีการทดสอบ
GOST 19.401-78 อีเอสพีดี ข้อความโปรแกรม ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.402-78 อีเอสพีดี คำอธิบายของโปรแกรม
GOST 19.404-79 อีเอสพีดี หมายเหตุอธิบาย- ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.501-78 อีเอสพีดี รูปร่าง. ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.502-78 อีเอสพีดี คำอธิบายของแอปพลิเคชัน ข้อกำหนดสำหรับเนื้อหาและการออกแบบ
GOST 19.503-79 อีเอสพีดี คู่มือโปรแกรมเมอร์ระบบ ข้อกำหนดด้านเนื้อหาและ
การลงทะเบียน
GOST 19.504-79 อีเอสพีดี คู่มือโปรแกรมเมอร์
GOST 19.505-79 อีเอสพีดี คู่มือการใช้งาน
GOST 19.506-79 อีเอสพีดี คำอธิบายภาษา
GOST 19.508-79 อีเอสพีดี นำทางไป การซ่อมบำรุง- ข้อกำหนดด้านเนื้อหาและ
การลงทะเบียน
GOST 19.604-78 อีเอสพีดี กฎสำหรับการเปลี่ยนแปลงเอกสารโปรแกรมที่ดำเนินการ
ในรูปแบบสิ่งพิมพ์
GOST 19.701-90 ESPD แผนผังของอัลกอริธึม โปรแกรม ข้อมูล และระบบ ตำนานและ
กฎการดำเนินการ
GOST 19.781-90 ให้บริการระบบประมวลผลข้อมูล

29. ข้อดีของการใช้มาตรฐาน ESPD

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

30. ข้อเสียของมาตรฐาน ESPD

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

31. มาตรฐาน GOST 34.601-90: ขั้นตอนและขั้นตอนของการสร้างระบบอัตโนมัติ

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

32.

มาตรฐาน GOST 34.601-90: ขั้นตอนและขั้นตอน
การสร้างระบบอัตโนมัติ
5.
โครงการด้านเทคนิค
6.
เอกสารการทำงาน
7.
การพัฒนาเอกสารการทำงานสำหรับ NPP และส่วนต่างๆ
การพัฒนาและดัดแปลงโปรแกรม
การว่าจ้าง
8.
การพัฒนาโซลูชั่นการออกแบบสำหรับระบบและชิ้นส่วน
การพัฒนาเอกสารสำหรับระบบลำโพงและส่วนประกอบต่างๆ
การพัฒนาและการดำเนินการเอกสารสำหรับการจัดหาส่วนประกอบ
การพัฒนางานออกแบบในส่วนที่อยู่ติดกันของโครงการ
กำลังเตรียมวัตถุอัตโนมัติ
การฝึกอบรมบุคลากร
ชุดลำโพงครบชุดพร้อมผลิตภัณฑ์ที่ให้มา (ซอฟต์แวร์และฮาร์ดแวร์
ระบบซอฟต์แวร์และฮาร์ดแวร์ ผลิตภัณฑ์สารสนเทศ)
งานก่อสร้างและติดตั้ง
การว่าจ้างงาน
ดำเนินการทดสอบเบื้องต้น
การดำเนินการทดลอง
ดำเนินการทดสอบการยอมรับ
รองรับระบบไฟฟ้ากระแสสลับ
ดำเนินงานตามภาระผูกพันในการรับประกัน
บริการหลังการรับประกัน

เป้าหมายและวัตถุประสงค์ของวิธีการออกแบบโดย- พื้นที่การออกแบบหลักโดย- ขั้นตอนของการสร้างสรรค์โดย.

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

เครื่องมือซอฟต์แวร์ (ผลิตภัณฑ์ซอฟต์แวร์) - ชุดโปรแกรมคอมพิวเตอร์ ขั้นตอน และอาจรวมถึงเอกสารและข้อมูลที่เกี่ยวข้อง

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

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

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

การเขียนโปรแกรม - เป็นหนึ่งในกิจกรรมที่รวมอยู่ในวงจรการพัฒนาซอฟต์แวร์

ขั้นตอนของการสร้างซอฟต์แวร์

1. ทำความเข้าใจลักษณะและขอบเขตของผลิตภัณฑ์ที่นำเสนอ

2. เลือกกระบวนการพัฒนาและสร้างแผน

3. รวบรวมข้อกำหนด

4. ออกแบบและประกอบผลิตภัณฑ์

5. ทำการทดสอบผลิตภัณฑ์

6. ปล่อยผลิตภัณฑ์และให้การสนับสนุน

ตามวงจรชีวิตของโปรแกรม เราหมายถึงชุดของขั้นตอน:

การวิเคราะห์สาขาวิชาและการสร้างข้อกำหนดทางเทคนิค (การโต้ตอบกับลูกค้า)

การออกแบบโครงสร้างของโปรแกรม

การเข้ารหัส (ชุดโค้ดโปรแกรมตามเอกสารประกอบโครงการ)

การทดสอบและการดีบัก

การนำโปรแกรมไปใช้

การสนับสนุนโปรแกรม

การกำจัด

แนวคิดเกี่ยวกับวงจรชีวิตซอฟต์แวร์ (LC) คำจำกัดความของวงจรชีวิตตามมาตรฐานสากล ISO/IEC 12207:1995 กระบวนการวงจรชีวิตซอฟต์แวร์ขั้นพื้นฐาน

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

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

เอกสารกำกับดูแลหลักที่ควบคุมองค์ประกอบของกระบวนการวงจรชีวิตของซอฟต์แวร์คือมาตรฐานสากล ISO/IEC 12207: 1995 “เทคโนโลยีสารสนเทศ - กระบวนการวงจรชีวิตของซอฟต์แวร์” (ISO - International Organisation for Standardization, IEC - International Electrotechnical Commission - International Commission for Standardization) . วิศวกรรมไฟฟ้า กำหนดโครงสร้างวงจรชีวิตที่มีกระบวนการ การดำเนินการ และงานที่ต้องทำระหว่างการสร้างซอฟต์แวร์

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

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

ทั้งหมด กระบวนการแบ่งออกเป็นชุดของการกระทำแต่ละอย่าง การกระทำ– ต่อชุด งาน- แต่ละกระบวนการ การดำเนินการ หรืองานจะถูกเริ่มต้นและดำเนินการโดยกระบวนการอื่นตามความจำเป็น และไม่มีลำดับการดำเนินการที่กำหนดไว้ล่วงหน้า (แน่นอนว่า ในขณะที่ยังคงรักษาการเชื่อมต่อระหว่างข้อมูลอินพุต)

กระบวนการวงจรชีวิตขั้นพื้นฐาน :

สั่งซื้อ (ซื้อ);

การดำเนินการ - การเริ่มต้นการได้มา

การดำเนินการ – การเตรียมข้อเสนอการประมูล

การดำเนินการ - การจัดเตรียมและการปรับปรุงสัญญา

การดำเนินการ - การกำกับดูแลกิจกรรมของซัพพลายเออร์

อยู่ระหว่างดำเนินการ การยอมรับ มีการเตรียมและดำเนินการการทดสอบที่จำเป็น เสร็จสิ้นการทำงาน ภายใต้สัญญาจะดำเนินการหากตรงตามเงื่อนไขการยอมรับทั้งหมด

จัดหา;

การเริ่มต้นการส่งมอบ

การวางแผน

การพัฒนา;

กระบวนการพัฒนาเกี่ยวข้องกับกิจกรรมและงานที่ดำเนินการโดยนักพัฒนาและรวมถึงสิ่งต่อไปนี้:

งานเตรียมการ

การวิเคราะห์ความต้องการของระบบ

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

การวิเคราะห์ความต้องการซอฟต์แวร์

การออกแบบสถาปัตยกรรมซอฟต์แวร์

การเข้ารหัสและการทดสอบซอฟต์แวร์

บูรณาการซอฟต์แวร์

การทดสอบคุณสมบัติซอฟต์แวร์

บูรณาการระบบ

การติดตั้งซอฟต์แวร์

การยอมรับซอฟต์แวร์

การดำเนินการ; ครอบคลุมการดำเนินการและภารกิจของผู้ปฏิบัติงาน - องค์กรที่ปฏิบัติการระบบ และรวมถึงการดำเนินการ:

งานเตรียมการ รวมถึงผู้ปฏิบัติงานที่ปฏิบัติงานดังต่อไปนี้:

การวางแผนกิจกรรมและงานที่ดำเนินการระหว่างการปฏิบัติงานและการกำหนดมาตรฐานการปฏิบัติงาน

การกำหนดขั้นตอนในการแปลและแก้ไขปัญหาที่เกิดขึ้นระหว่างการดำเนินการ

การทดสอบประสิทธิภาพ จะดำเนินการกับผลิตภัณฑ์ซอฟต์แวร์รุ่นถัดไปแต่ละรุ่น หลังจากนั้นจึงนำไปใช้งาน

การทำงานของระบบ

การสนับสนุนผู้ใช้

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

งานเตรียมการ บริการสนับสนุนรวมถึงงานต่อไปนี้:

การวางแผนการดำเนินการและงานที่ดำเนินการระหว่างกระบวนการสนับสนุน

การกำหนดขั้นตอนสำหรับการแปลและแก้ไขปัญหาที่เกิดขึ้นระหว่างกระบวนการบำรุงรักษา

การวิเคราะห์ปัญหาและการร้องขอการแก้ไขซอฟต์แวร์

การปรับเปลี่ยนซอฟต์แวร์

การตรวจสอบและการยอมรับ

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

แนวคิดเกี่ยวกับวงจรชีวิตซอฟต์แวร์ (LC) คำจำกัดความของวงจรชีวิตตามมาตรฐานสากล ISO/IEC 12207:1995 กระบวนการเสริมของวงจรชีวิตซอฟต์แวร์

ดูจุดที่ 2

กระบวนการวงจรชีวิตเสริม :

เอกสารประกอบ- คำอธิบายอย่างเป็นทางการของข้อมูลที่สร้างขึ้นระหว่างวงจรชีวิตของซอฟต์แวร์

กระบวนการจัดทำเอกสารประกอบด้วยขั้นตอนต่อไปนี้:

งานเตรียมการ

การออกแบบและพัฒนา

การออกเอกสาร;

คลอ

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

และนำมาใช้ในซอฟต์แวร์

งานเตรียมการ การระบุการกำหนดค่า

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

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

(หมายถึงการลงทะเบียนสถานะของส่วนประกอบซอฟต์แวร์ การจัดทำรายงานเกี่ยวกับการแก้ไขเวอร์ชันของส่วนประกอบซอฟต์แวร์ที่นำไปใช้และถูกปฏิเสธทั้งหมด) + ประวัติการแก้ไข การประเมินการกำหนดค่า

(ประกอบด้วยการประเมินความสมบูรณ์ของการทำงานของส่วนประกอบซอฟต์แวร์ตลอดจนความสอดคล้องของสถานะทางกายภาพกับคำอธิบายทางเทคนิคในปัจจุบัน) การจัดการการปล่อยและการจัดหา

(ครอบคลุมถึงการผลิตสำเนาอ้างอิงของโปรแกรมและเอกสารประกอบ การจัดเก็บและการส่งมอบให้กับผู้ใช้ตามขั้นตอนที่นำมาใช้ในองค์กร)

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

เป็นที่เข้าใจกันว่าเป็นชุดของคุณสมบัติที่แสดงถึงความสามารถของซอฟต์แวร์ในการตอบสนองข้อกำหนดที่ระบุ

กระบวนการประกันคุณภาพประกอบด้วยกิจกรรมต่อไปนี้:

งานเตรียมการ

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

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

งานเตรียมการ

การตรวจสอบ;

มีการตรวจสอบเงื่อนไขต่อไปนี้ในระหว่างกระบวนการตรวจสอบ:

ความสอดคล้องของข้อกำหนดสำหรับระบบและระดับที่คำนึงถึงความต้องการของผู้ใช้

ความสามารถของซัพพลายเออร์ในการปฏิบัติตามข้อกำหนดที่ระบุ

การปฏิบัติตามกระบวนการวงจรชีวิตที่เลือกตามเงื่อนไขของสัญญา

ความเพียงพอของมาตรฐาน ขั้นตอน และสภาพแวดล้อมการพัฒนาสำหรับกระบวนการวงจรชีวิตของซอฟต์แวร์

การปฏิบัติตามข้อกำหนดการออกแบบซอฟต์แวร์ตามข้อกำหนดที่ระบุ

ความถูกต้องของคำอธิบายในข้อกำหนดการออกแบบข้อมูลเข้าและออก ลำดับเหตุการณ์ ส่วนต่อประสาน ตรรกะ

การปฏิบัติตามรหัสตามข้อกำหนดและข้อกำหนดการออกแบบ

ความสามารถในการทดสอบและความถูกต้องของรหัสการปฏิบัติตามมาตรฐานการเข้ารหัสที่ยอมรับ

การรวมส่วนประกอบซอฟต์แวร์เข้ากับระบบอย่างถูกต้อง

ความเพียงพอ ครบถ้วน และสม่ำเสมอของเอกสาร

การรับรอง;

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

การประเมินแบบมีส่วนร่วม(การวิเคราะห์แบบมีส่วนร่วม); เพื่อประเมินสถานะการทำงานในโครงการและซอฟต์แวร์

การประเมินจะใช้ทั้งในระดับการจัดการโครงการและระดับการดำเนินงานทางเทคนิคของโครงการ และดำเนินการตลอดระยะเวลาทั้งหมดของสัญญา กระบวนการนี้สามารถดำเนินการโดยทั้งสองฝ่ายที่เกี่ยวข้องกับสัญญา โดยฝ่ายหนึ่งจะตรวจสอบอีกฝ่ายหนึ่ง

กระบวนการประเมินแบบมีส่วนร่วมประกอบด้วยกิจกรรมดังต่อไปนี้:

งานเตรียมการ

การประเมิน (การวิเคราะห์) การบริหารโครงการ

การประเมินทางเทคนิค

การตรวจสอบ;

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

การอนุญาต(สารละลาย) ปัญหา.

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

แนวคิดเกี่ยวกับวงจรชีวิตซอฟต์แวร์ (LC) คำจำกัดความของวงจรชีวิตตามมาตรฐานสากล ISO/IEC 12207:1995 กระบวนการองค์กรของวงจรชีวิตซอฟต์แวร์ ความสัมพันธ์ระหว่างกระบวนการวงจรชีวิตของซอฟต์แวร์

ดูจุดที่ 2

กระบวนการวงจรชีวิตขององค์กร :

ควบคุม;

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

กระบวนการจัดการประกอบด้วยการดำเนินการต่อไปนี้:

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

การวางแผน เกี่ยวข้องกับการปฏิบัติงานอย่างน้อยดังต่อไปนี้:

จัดทำตารางการทำงาน

การประมาณต้นทุน

การจัดสรรทรัพยากรที่จำเป็น

การกระจายความรับผิดชอบ

การประเมินความเสี่ยงที่เกี่ยวข้องกับงานเฉพาะ

การสร้างโครงสร้างพื้นฐานการจัดการ

การดำเนินการและการควบคุม

การทวนสอบและประเมินผล

เสร็จสิ้น

การสร้างโครงสร้างพื้นฐาน

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

การปรับปรุง;

จัดให้มีการประเมิน การวัด ควบคุม และปรับปรุงกระบวนการวงจรชีวิตของซอฟต์แวร์

การศึกษา.

ครอบคลุมการฝึกอบรมเบื้องต้นและการพัฒนาพนักงานอย่างต่อเนื่องในภายหลัง

ความสัมพันธ์ระหว่างกระบวนการวงจรชีวิตของซอฟต์แวร์

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

ด้านสัญญา

ด้านการจัดการ

ด้านการดำเนินงาน

ด้านวิศวกรรม

ด้านการสนับสนุน

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

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

แนวคิดของแบบจำลองและระยะวงจรการใช้งานซอฟต์แวร์ ลักษณะของขั้นตอนการสร้างซอฟต์แวร์.

1) มาตรฐานสากล ไอเอสโอ/ ไออีซี 12207: 1995 นี่คือวิธีที่แบบจำลองวงจรชีวิตกำหนด:

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

2) GOST R ISO/IEC 12207-99นี่คือวิธีที่แบบจำลองวงจรชีวิตกำหนด:

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

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

วงจรชีวิตของซอฟต์แวร์มักจะประกอบด้วยสถานีต่อไปนี้:

การก่อตัวของข้อกำหนดซอฟต์แวร์

ออกแบบ.

การนำไปปฏิบัติ

การทดสอบ

การว่าจ้าง

การดำเนินงานและการบำรุงรักษา

กำลังรื้อถอน.

แนวคิดของแบบจำลองวงจรชีวิตซอฟต์แวร์ แบบจำลองน้ำตก (น้ำตก) ของวงจรชีวิตซอฟต์แวร์

ดูจุดที่ 5

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

ข้อดีของการใช้วิธีเรียงซ้อน :

ในแต่ละขั้นตอนจะมีการสร้างชุดเอกสารการออกแบบที่สมบูรณ์ซึ่งตรงตามข้อกำหนดของความครบถ้วนและความสม่ำเสมอ

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

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

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

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

แนวคิดของแบบจำลองวงจรชีวิตซอฟต์แวร์รูปแบบการพัฒนาแอปพลิเคชันที่รวดเร็ว ดูย่อหน้าที่ 5

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

นักพัฒนากลุ่มเล็ก (3-7 คน) ที่ทำงานเกี่ยวกับการออกแบบระบบย่อยซอฟต์แวร์แต่ละรายการ นี่เป็นเพราะข้อกำหนดสำหรับการควบคุมสูงสุดของทีม

ตารางการผลิตสั้น แต่จัดทำอย่างรอบคอบ (สูงสุด 3 เดือน)

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

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

มีความโดดเด่นดังต่อไปนี้: ขั้นตอนของกระบวนการพัฒนา RAD :

การสร้างแบบจำลองธุรกิจ - มีการสร้างแบบจำลองการไหลของข้อมูลระหว่างฟังก์ชันทางธุรกิจ

การสร้างแบบจำลองข้อมูล . การไหลของข้อมูลแมปกับชุดของวัตถุข้อมูล

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

การสร้างแอปพลิเคชัน - ภาษาโปรแกรมรุ่นที่ 4 และส่วนประกอบสำเร็จรูปใช้เพื่อสร้างยูทิลิตี้ระบบอัตโนมัติ

การทดสอบและการรวม - การใช้ส่วนประกอบที่นำกลับมาใช้ใหม่ได้จะช่วยลดเวลาในการทดสอบ

แต่ละฟังก์ชันหลักได้รับการพัฒนาโดยกลุ่มนักพัฒนาที่แยกจากกันพร้อมกันเป็นเวลาไม่เกิน 3 เดือน จากนั้นจึงรวมเข้ากับระบบทั้งหมด

ข้อเสียของการใช้งาน ราด :

โครงการขนาดใหญ่ต้องใช้ทรัพยากรบุคคลจำนวนมากในการสร้างทีม

แบบจำลองนี้ใช้ได้กับระบบที่สามารถแยกย่อยเป็นโมดูลแยกกันเท่านั้น และประสิทธิภาพไม่ใช่ค่าวิกฤต

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

แนวคิดของแบบจำลองวงจรชีวิตซอฟต์แวร์ แบบจำลองวงจรชีวิตซอฟต์แวร์รูปตัว V

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

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

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

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

ข้าว. - แบบจำลองวงจรชีวิตวี

ให้ไว้ด้านล่าง คำอธิบายสั้น ๆแต่ละขั้นตอนของโมเดล V ตั้งแต่การวางแผนโครงการและข้อกำหนดไปจนถึงการทดสอบการยอมรับ:

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

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

สถาปัตยกรรมหรือการออกแบบในระดับสูงสุด – กำหนดวิธีการใช้ฟังก์ชันซอฟต์แวร์ในการดำเนินโครงการ

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

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

การทดสอบหน่วย – แต่ละโมดูลที่เข้ารหัสจะถูกตรวจสอบหาข้อผิดพลาด

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

การทดสอบระบบและการยอมรับ – มีการตรวจสอบการทำงานของระบบซอฟต์แวร์โดยรวม (ระบบบูรณาการเต็มรูปแบบ) หลังจากวางในสภาพแวดล้อมฮาร์ดแวร์ตามข้อกำหนดข้อกำหนดซอฟต์แวร์

การผลิต การดำเนินงาน และการสนับสนุน – ซอฟต์แวร์ถูกนำไปผลิต ขั้นตอนนี้ยังรวมถึงการปรับปรุงและแก้ไขให้ทันสมัย

การทดสอบการยอมรับ (ไม่แสดงในรูป) – ให้ผู้ใช้สามารถทดสอบการทำงานของระบบเพื่อให้เป็นไปตามข้อกำหนดเบื้องต้น หลังจากการทดสอบขั้นสุดท้าย ซอฟต์แวร์และฮาร์ดแวร์โดยรอบก็สามารถทำงานได้ หลังจากนั้นจะมีการบำรุงรักษาระบบ

ข้อดี:

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

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

ในรุ่น V จะมีการนิยามข้อกำหนดก่อนการออกแบบระบบ และออกแบบซอฟต์แวร์ก่อนการพัฒนาส่วนประกอบ

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

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

โมเดลนี้ใช้งานง่าย (สัมพันธ์กับโครงการที่เหมาะสม)

ข้อบกพร่อง:

ด้วยความช่วยเหลือมันไม่ง่ายเลยที่จะรับมือกับเหตุการณ์คู่ขนาน

มันไม่ได้คำนึงถึงการวนซ้ำระหว่างเฟส

แบบจำลองไม่ได้จัดให้มีการแนะนำข้อกำหนดสำหรับการเปลี่ยนแปลงแบบไดนามิกในระยะต่าง ๆ ของวงจรชีวิต

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

แบบจำลองไม่รวมการดำเนินการที่มุ่งเป้าไปที่การวิเคราะห์ความเสี่ยง

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

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

การใช้แบบจำลองจะมีประสิทธิภาพเมื่อมีข้อมูลเกี่ยวกับวิธีการนำโซลูชันและเทคโนโลยีไปใช้ และพนักงานมีทักษะและประสบการณ์ที่จำเป็นในการทำงานกับเทคโนโลยีนี้

รุ่นรูปตัว V เป็นตัวเลือกที่ยอดเยี่ยมสำหรับระบบที่ต้องการความน่าเชื่อถือสูง เช่น แอปพลิเคชันการติดตามผู้ป่วยทางคลินิก และซอฟต์แวร์แบบฝังสำหรับการควบคุมถุงลมนิรภัยในรถยนต์

แนวคิดของแบบจำลองวงจรชีวิตซอฟต์แวร์ แบบจำลองวงจรชีวิตของซอฟต์แวร์แบบก้นหอยของ Boehm

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

ดังแสดงในรูป 3 โมเดลกำหนดการกระทำสี่ประการ ซึ่งแสดงโดยสี่ควอแดรนท์ของเกลียว:

การวางแผน - การกำหนดเป้าหมาย ทางเลือก และข้อจำกัด

การวิเคราะห์ความเสี่ยง - การวิเคราะห์ตัวเลือกและการรับรู้/การเลือกความเสี่ยง

การออกแบบ-การพัฒนาผลิตภัณฑ์ขั้นต่อไป

การประเมิน - การประเมินของลูกค้าเกี่ยวกับผลการออกแบบในปัจจุบัน

ลักษณะการบูรณาการของแบบจำลองก้นหอยจะเห็นได้ชัดเจนเมื่อคำนึงถึงมิติรัศมีของเกลียวด้วย เมื่อมีการวนซ้ำแต่ละครั้งเป็นเกลียว (ย้ายจากศูนย์กลางไปยังรอบนอก) มากขึ้นเรื่อยๆ เวอร์ชันเต็มโดย.

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

ตามมาตรฐาน IEEE-90 การกำหนดค่าซอฟต์แวร์เป็นที่เข้าใจกันว่าเป็นผลรวมของคุณสมบัติการทำงานและทางกายภาพที่กำหนดไว้ในเอกสารทางเทคนิคและนำไปใช้ในซอฟต์แวร์ การจัดการการกำหนดค่าช่วยให้คุณสามารถจัดระเบียบ พิจารณาอย่างเป็นระบบ และควบคุมการแนะนำการเปลี่ยนแปลงซอฟต์แวร์ในทุกขั้นตอนของวงจรชีวิต หลักการทั่วไปและคำแนะนำสำหรับการจัดการการกำหนดค่าซอฟต์แวร์สะท้อนให้เห็นในมาตรฐาน ISO/IEC 15288 "เทคโนโลยีสารสนเทศ กระบวนการวงจรชีวิตของซอฟต์แวร์ การจัดการการกำหนดค่าสำหรับซอฟต์แวร์"

กระบวนการบริหารจัดการการกำหนดค่าประกอบด้วยขั้นตอนต่อไปนี้:

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

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

กระบวนการจัดเตรียมคุณภาพรวมถึงการดำเนินการต่อไปนี้:

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

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

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

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

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

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

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

การประเมินจะใช้ทั้งในระดับการจัดการโครงการและระดับการดำเนินงานทางเทคนิคของโครงการ และดำเนินการตลอดระยะเวลาทั้งหมดของสัญญา กระบวนการนี้สามารถดำเนินการโดยสองฝ่ายที่เกี่ยวข้องกับสัญญา โดยฝ่ายหนึ่งจะตรวจสอบอีกฝ่ายหนึ่ง

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

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

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

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

5.4. กระบวนการองค์กรของวงจรชีวิตซอฟต์แวร์

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

โครงสร้างของวงจรชีวิตซอฟต์แวร์ตามมาตรฐาน ISO/IEC 12207 ขึ้นอยู่กับกระบวนการสามกลุ่ม (รูปที่ 1):

· กระบวนการหลักของวงจรชีวิตของซอฟต์แวร์ (การซื้อ การส่งมอบ การพัฒนา การดำเนินการ การสนับสนุน)

· กระบวนการเสริมที่รับรองการดำเนินการตามกระบวนการหลัก (การจัดทำเอกสาร การจัดการการกำหนดค่า การประกันคุณภาพ การทวนสอบ การรับรอง การประเมิน การตรวจสอบ การแก้ปัญหา)

· กระบวนการขององค์กร (การจัดการโครงการ การสร้างโครงสร้างพื้นฐานของโครงการ คำจำกัดความ การประเมินและการปรับปรุงวงจรชีวิต การฝึกอบรม)

ข้าว. 1. กระบวนการวงจรชีวิตของซอฟต์แวร์

กระบวนการได้มา(ขั้นตอนการได้มา) ประกอบด้วยการกระทำ

และงานของลูกค้าที่ซื้อซอฟต์แวร์ กระบวนการนี้ครอบคลุมขั้นตอนต่อไปนี้:

1) การเริ่มต้นการซื้อกิจการ;

2) การจัดทำข้อเสนอการประมูล

3) การจัดเตรียมและการปรับปรุงสัญญา

4) การกำกับดูแลกิจกรรมของซัพพลายเออร์;

5) การยอมรับและความสำเร็จของงาน

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

1) การเริ่มต้นการส่งมอบ

2) การเตรียมการตอบรับข้อเสนอการประมูล;

3) การจัดทำสัญญา

4) การวางแผน;

5) การดำเนินการและการควบคุม;

6) การตรวจสอบและประเมินผล;

7) การส่งมอบและความสำเร็จของงาน

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

กระบวนการพัฒนาประกอบด้วยขั้นตอนต่อไปนี้:

1) การวิเคราะห์ความต้องการของระบบ

2) การออกแบบสถาปัตยกรรมระบบ

3) การวิเคราะห์ข้อกำหนดซอฟต์แวร์

4) การออกแบบสถาปัตยกรรมซอฟต์แวร์

5) การออกแบบซอฟต์แวร์โดยละเอียด

6) การเข้ารหัสและการทดสอบซอฟต์แวร์

7) การรวมซอฟต์แวร์

8) การทดสอบคุณสมบัติซอฟต์แวร์

9) การรวมระบบ

10) การทดสอบคุณสมบัติของระบบ

11) การติดตั้งซอฟต์แวร์

12) การยอมรับซอฟต์แวร์

ขั้นตอนการดำเนินงาน(ขั้นตอนการดำเนินงาน) ครอบคลุมถึงการกระทำและภารกิจของผู้ปฏิบัติงาน - องค์กรที่ปฏิบัติการระบบ กระบวนการนี้รวมถึงขั้นตอนต่อไปนี้:

1) การทดสอบการปฏิบัติงาน

2) การทำงานของระบบ

3) การสนับสนุนผู้ใช้

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

ความต้องการ. การเปลี่ยนแปลงที่ทำกับซอฟต์แวร์ที่มีอยู่จะต้องไม่ละเมิด

ความสมบูรณ์ของมัน กระบวนการบำรุงรักษารวมถึงการถ่ายโอนซอฟต์แวร์ไปยังสภาพแวดล้อมอื่น (การย้าย) และสิ้นสุดด้วยการเลิกใช้งานซอฟต์แวร์

กระบวนการบำรุงรักษาครอบคลุมการดำเนินการต่อไปนี้:

1) การวิเคราะห์ปัญหาและการร้องขอการแก้ไขซอฟต์แวร์

2) การดัดแปลงซอฟต์แวร์

3) การตรวจสอบและการยอมรับ

4) การถ่ายโอนซอฟต์แวร์ไปยังสภาพแวดล้อมอื่น

5) การเลิกใช้งานซอฟต์แวร์

กลุ่มกระบวนการเสริมประกอบด้วย:

เอกสาร;

การจัดการการกำหนดค่า การประกันคุณภาพ

การตรวจสอบ; การรับรอง;

การประเมินแบบมีส่วนร่วม

การแก้ไขปัญหา

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

1) การออกแบบและพัฒนา

2) การออกเอกสาร;

3) การสนับสนุนด้านเอกสาร

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

คุณลักษณะที่กำหนดไว้ในเอกสารทางเทคนิคและนำไปใช้ในซอฟต์แวร์

การจัดการการกำหนดค่าช่วยให้คุณสามารถจัดระเบียบ คำนึงถึงและควบคุมการเปลี่ยนแปลงซอฟต์แวร์อย่างเป็นระบบในทุกขั้นตอนของวงจรชีวิต หลักการทั่วไปและคำแนะนำสำหรับการจัดการการกำหนดค่าซอฟต์แวร์สะท้อนให้เห็นในร่างมาตรฐาน ISO/I EC CD 12207-2: 1995 "เทคโนโลยีสารสนเทศ - กระบวนการวงจรชีวิตของซอฟต์แวร์ ส่วนที่ 2

การจัดการการกำหนดค่าสำหรับซอฟต์แวร์" กระบวนการจัดการการกำหนดค่าประกอบด้วยการดำเนินการต่อไปนี้:

1) การระบุการกำหนดค่า

2) การควบคุมการกำหนดค่า;

3) การบัญชีสถานะการกำหนดค่า

4) การประเมินการกำหนดค่า

5) การจัดการการปล่อยและการส่งมอบ

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

1) รับประกันคุณภาพของผลิตภัณฑ์

2) สร้างความมั่นใจในคุณภาพของกระบวนการ

3) สร้างความมั่นใจในตัวบ่งชี้คุณภาพระบบอื่น ๆ

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

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

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

กระบวนการตรวจสอบ(กระบวนการตรวจสอบ) เป็นการกำหนดการปฏิบัติตามข้อกำหนด แผน และเงื่อนไขของสัญญา

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

กลุ่มกระบวนการองค์กรของวงจรชีวิตซอฟต์แวร์ประกอบด้วย:

ควบคุม;

การสร้างโครงสร้างพื้นฐาน

การปรับปรุง;

การเปิดตัวเวอร์ชันใหม่

การศึกษา.

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

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

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

บุคลากร

กระบวนการเรียนรู้(กระบวนการฝึกอบรม) โดยครอบคลุมถึงการฝึกอบรมเบื้องต้นและการพัฒนาพนักงานอย่างต่อเนื่องในภายหลัง