วิศวกรรมซอฟต์แวร์หลักการพื้นฐานของเจ็ด

1 ใช้ชีวิตรอบแบ่งวางแผนการจัดการที่เข้มงวด

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

2 ยืนยันในระยะการประเมิน

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

3 การดำเนินการควบคุมสินค้าที่เข้มงวด

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

4 โดยใช้เทคนิคการเขียนโปรแกรมสมัยใหม่

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

5 ผลควรตรวจสอบอย่างชัดเจน

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

6 ทีมพัฒนาของเจ้าหน้าที่มีน้อย

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

7 ต่อการรับรู้ต้องปรับปรุงการปฏิบัติงานวิศวกรรมซอฟต์แวร์

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