การบำรุงรักษาซอฟต์แวร์คือ การปรับเปลี่ยนซอฟต์แวร์หลังจากส่งมอบแล้ว

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

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

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

ในช่วงต้นทศวรรษ 1970 บริษัทต่างๆ เริ่มแยกการบำรุงรักษาซอฟต์แวร์ออกไปโดยมีทีมวิศวกรของตนเอง เพื่อปลดปล่อยทีมพัฒนาซอฟต์แวร์ จากงานสนับสนุน ^{[ 1 ]}ในปี 1972 RG Canning ได้ตีพิมพ์ "The Maintenance 'Iceberg ' " ซึ่งเขาโต้แย้งว่าการบำรุงรักษาซอฟต์แวร์เป็นส่วนขยายของการพัฒนาซอฟต์แวร์โดยมีปัจจัยนำเข้าเพิ่มเติมคือระบบที่มีอยู่^{[ 1 ]}ระเบียบวินัยของการบำรุงรักษาซอฟต์แวร์เปลี่ยนแปลงไปเพียงเล็กน้อยนับตั้งแต่นั้นมา^{[ 2 ]}นวัตกรรมหนึ่งในศตวรรษที่ 21 คือบริษัทต่างๆ จงใจปล่อยซอฟต์แวร์ที่ไม่สมบูรณ์ออกมาและวางแผนที่จะทำให้เสร็จสมบูรณ์หลังจากการปล่อย การเปลี่ยนแปลงประเภทนี้และอื่นๆ ที่ขยายฟังก์ชันการทำงาน มักเรียกว่าวิวัฒนาการซอฟต์แวร์แทนที่จะเป็นการบำรุงรักษา^{[ 2 ]}

แม้ว่าจะมีการทดสอบและการตรวจสอบคุณภาพแล้วก็ตาม ซอฟต์แวร์เกือบทั้งหมดก็ยังมีบั๊กที่ทำให้ระบบทำงานไม่เป็นไปตามที่ตั้งใจไว้ การบำรุงรักษาหลังการวางจำหน่ายจึงจำเป็นเพื่อแก้ไขบั๊กเหล่านี้เมื่อพบเจอ^{[ 3 ]}ซอฟต์แวร์ส่วนใหญ่เป็นการผสมผสานระหว่าง ส่วนประกอบซอฟต์แวร์ สำเร็จรูปเชิงพาณิชย์ (COTS) และซอฟต์แวร์โอเพนซอร์ส ที่มีอยู่แล้ว กับโค้ดที่เขียนขึ้นเอง ซอฟต์แวร์ COTS และโอเพนซอร์สมักจะได้รับการอัปเดตเมื่อเวลาผ่านไป ซึ่งสามารถลดภาระการบำรุงรักษาได้ แต่การแก้ไขส่วนประกอบซอฟต์แวร์เหล่านี้จะต้องได้รับการปรับเปลี่ยนในผลิตภัณฑ์ขั้นสุดท้าย^{[ 4 ​​]}แตกต่างจากการพัฒนาซอฟต์แวร์ซึ่งมุ่งเน้นไปที่การตอบสนองความต้องการที่ระบุไว้ การบำรุงรักษาซอฟต์แวร์นั้นขับเคลื่อนด้วยเหตุการณ์ต่างๆ เช่น คำขอของผู้ใช้หรือการตรวจพบบั๊ก^{[ 5 ]}จุดประสงค์หลักคือการรักษาประโยชน์ของซอฟต์แวร์ โดยปกติแล้วเมื่อเผชิญกับความต้องการที่เปลี่ยนแปลงไป^{[ 6 ]}

หากมองว่าการบำรุงรักษาเป็นส่วนหนึ่งของวงจรชีวิตการพัฒนาซอฟต์แวร์การบำรุงรักษาจะเป็นขั้นตอนสุดท้ายและโดยทั่วไปแล้วเป็นขั้นตอนที่ยาวนานที่สุดของวงจร^{[ 7 ] [ 8 ]}ซึ่งคิดเป็น 80 ถึง 90 เปอร์เซ็นต์ของต้นทุนตลอดวงจรชีวิต^{[ 9 ]}โมเดลอื่นๆ พิจารณาการบำรุงรักษาแยกต่างหากจากการพัฒนาซอฟต์แวร์ โดยถือเป็นส่วนหนึ่งของวงจรชีวิตการบำรุงรักษาซอฟต์แวร์ (SMLC) ^{[ 8 ]}โมเดล SMLC โดยทั่วไปจะรวมถึงการทำความเข้าใจโค้ด การแก้ไข และการตรวจสอบความถูกต้องอีกครั้ง^{[ 8 ]}

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

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

ขั้นตอนแรกในวงจรการเปลี่ยนแปลงคือการรับคำขอเปลี่ยนแปลงจากลูกค้าและวิเคราะห์เพื่อยืนยันปัญหาและตัดสินใจว่าจะดำเนินการเปลี่ยนแปลงหรือไม่^{[ 13 ]}ซึ่งอาจต้องอาศัยข้อมูลจากหลายแผนก ตัวอย่างเช่น ทีมการตลาดสามารถช่วยประเมินว่าการเปลี่ยนแปลงนั้นคาดว่าจะนำมาซึ่งธุรกิจมากขึ้นหรือไม่^{[ 14 ]}การประมาณการความพยายามในการพัฒนาซอฟต์แวร์เป็นปัญหาที่ยาก รวมถึงคำขอเปลี่ยนแปลงเพื่อการบำรุงรักษา^{[ 15 ]}แต่คำขออาจถูกปฏิเสธหากมีค่าใช้จ่ายสูงเกินไปหรือเป็นไปไม่ได้^{[ 16 ]} หากตัดสินใจที่จะดำเนินการตามคำขอ ก็สามารถกำหนดให้กับการปล่อยเวอร์ชันตามกำหนดการและดำเนินการได้^{[ 16 ]}แม้ว่าวิธีการแบบ Agileจะไม่มีขั้นตอนการบำรุงรักษา^{[ 17 ]} แต่วงจรการเปลี่ยนแปลงสามารถดำเนินการได้ในรูปแบบScrum Sprint ^{[ 18 ]}

การทำความเข้าใจโค้ดที่มีอยู่เป็นขั้นตอนสำคัญก่อนที่จะทำการแก้ไข^{[ 2 ]}อัตราการทำความเข้าใจขึ้นอยู่กับทั้งฐานโค้ดและทักษะของโปรแกรมเมอร์^{[ 19 ]}การปฏิบัติตามข้อกำหนดการเขียนโค้ด เช่น การใช้ชื่อฟังก์ชันและตัวแปรที่ชัดเจนซึ่งสอดคล้องกับวัตถุประสงค์ จะทำให้เข้าใจได้ง่ายขึ้น^{[ 20 ]}การใช้ คำสั่ง ลูปแบบมีเงื่อนไขเฉพาะในกรณีที่โค้ดสามารถทำงานได้มากกว่าหนึ่งครั้ง และการกำจัดโค้ดที่ไม่เคยทำงานเลย ก็สามารถเพิ่มความเข้าใจได้เช่นกัน^{[ 21 ]}โปรแกรมเมอร์ที่มีประสบการณ์จะเข้าใจสิ่งที่โค้ดทำในระดับสูงได้ง่ายกว่า^{[ 22 ]} บางครั้งมีการใช้ การแสดงภาพซอฟต์แวร์เพื่อเร่งกระบวนการนี้^{[ 23 ]}

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

ปัญหาเพิ่มเติมเกี่ยวกับการบำรุงรักษาคือ การเปลี่ยนแปลงโค้ดเกือบทุกครั้งจะทำให้เกิดบั๊กใหม่หรือผลกระทบ ที่ไม่คาดคิด ซึ่งต้องมีการแก้ไขอีกรอบ^{[ 2 ]}การทดสอบอาจใช้ทรัพยากรการบำรุงรักษาส่วนใหญ่สำหรับโค้ดที่สำคัญต่อความปลอดภัย เนื่องจากจำเป็นต้องตรวจสอบความถูกต้องของซอฟต์แวร์ทั้งหมดอีกครั้งหากมีการเปลี่ยนแปลงใดๆ^{[ 28 ]} การตรวจสอบความถูกต้องอีกครั้งอาจรวมถึง การตรวจ สอบโค้ดการทดสอบการถดถอยด้วยชุดย่อยของการทดสอบหน่วยการทดสอบการบูรณาการและ การ ทดสอบระบบ^{[ 26 ]}เป้าหมายของการทดสอบคือการตรวจสอบว่าฟังก์ชันการทำงานก่อนหน้านี้ยังคงอยู่ และฟังก์ชันการทำงานใหม่ได้ถูกเพิ่มเข้ามาแล้ว^{[ 29 ]}

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

ตาม ข้อกำหนด ISO / IEC 14764 การบำรุงรักษาซอฟต์แวร์สามารถจำแนกได้เป็นสี่ประเภท: ^{[ 31 ]}

• การบำรุงรักษาเชิงแก้ไข : การปรับเปลี่ยนซอฟต์แวร์เพื่อแก้ไขข้อบกพร่องหรือความล้มเหลวอื่นๆ ที่ไม่ตรงตามข้อกำหนด ซึ่งโดยทั่วไปแล้วจะได้รับการรายงานจากผู้ใช้ปลายทาง^{[ 31 ] [ 32 ]}
• การบำรุงรักษาเชิงป้องกัน : การปรับเปลี่ยนซอฟต์แวร์ในอนาคตหลังจากการส่งมอบเพื่อให้แน่ใจว่าซอฟต์แวร์ยังคงตรงตามข้อกำหนดหรือแก้ไขปัญหาที่ยังไม่ปรากฏ^{[ 33 ] [ 31 ]}การบำรุงรักษาประเภทนี้จะดำเนินการโดยเฉพาะกับระบบที่ต้องการความปลอดภัยหรือความพร้อมใช้งานสูง^{[ 33 ]}การฟื้นฟูซอฟต์แวร์เป็นรูปแบบหนึ่งของการบำรุงรักษาเชิงป้องกันเพื่อทำความสะอาดสถานะและป้องกันปัญหาในอนาคต^{[ 33 ]}
• การบำรุงรักษาเชิงปรับตัว: การปรับเปลี่ยนซอฟต์แวร์ที่ดำเนินการหลังการส่งมอบเพื่อให้มั่นใจว่ายังคงใช้งานได้ในสภาพแวดล้อมที่เปลี่ยนแปลงไป^{[ 31 ] [ 33 ]}
• การบำรุงรักษาเพื่อพัฒนาให้สมบูรณ์: การปรับปรุงซอฟต์แวร์หลังการส่งมอบเพื่อปรับปรุงคุณภาพ เช่นประสบการณ์ผู้ใช้ประสิทธิภาพการประมวลผล และความสามารถในการบำรุงรักษา [ ^{33 ] [ 34 ] การ}บำรุงรักษาเพื่อพัฒนาให้สมบูรณ์มีความจำเป็นหากมีการบำรุงรักษาประเภทอื่น เนื่องจากการแก้ไขฐานรหัสที่มีอยู่จะทำให้ความซับซ้อนเพิ่มขึ้นและทำให้โครงสร้างที่มีอยู่เสื่อมโทรมลง^{[ 34 ]}การบำรุงรักษาเพื่อพัฒนาให้สมบูรณ์อาจรวมถึงการเขียนเอกสารใหม่การปรับโครงสร้างรหัสและการปรับแต่งประสิทธิภาพ^{[ 33 ]}

ตามการประมาณการบางส่วน การปรับปรุง (สองประเภทหลัง) คิดเป็นประมาณร้อยละ 80 ของการบำรุงรักษาซอฟต์แวร์^{[ 35 ]}

ความสามารถในการบำรุงรักษาคือคุณสมบัติของซอฟต์แวร์ที่ทำให้สามารถแก้ไขได้ง่ายโดยไม่ทำให้ฟังก์ชันการทำงานที่มีอยู่เสียหาย^{[ 31 ]}ตามข้อกำหนด ISO/IEC 14764 กิจกรรมเพื่อให้มั่นใจว่าซอฟต์แวร์สามารถบำรุงรักษาได้ก่อนการเผยแพร่ถือเป็นส่วนหนึ่งของการบำรุงรักษาซอฟต์แวร์^{[ 5 ]}องค์กรพัฒนาซอฟต์แวร์หลายแห่งละเลยความสามารถในการบำรุงรักษา แม้ว่าการทำเช่นนั้นจะเพิ่มต้นทุนในระยะยาวก็ตาม^{[ 36 ]}หนี้ทางเทคนิคเกิดขึ้นเมื่อโปรแกรมเมอร์ มักเกิดจากความเกียจคร้านหรือความเร่งรีบเพื่อให้ทันกำหนดเวลา เลือกวิธีแก้ปัญหาที่รวดเร็วและไม่ละเอียดแทนที่จะสร้างความสามารถในการบำรุงรักษาไว้ในโค้ดของพวกเขา^{[ 37 ]}สาเหตุทั่วไปคือการประเมินความพยายามในการพัฒนาซอฟต์แวร์ต่ำเกินไป ทำให้ทรัพยากรที่จัดสรรให้กับการพัฒนาไม่เพียงพอ^{[ 38 ]} แง่มุมที่สำคัญอย่างหนึ่งคือการมี ชุดทดสอบซอฟต์แวร์อัตโนมัติจำนวนมากที่สามารถตรวจจับได้ว่าฟังก์ชันการทำงานที่มีอยู่ได้รับผลกระทบจากการเปลี่ยนแปลงหรือไม่^{[ 31 ]}

ดัชนีความสามารถในการบำรุงรักษาสามารถคำนวณได้โดยใช้สูตรบางอย่างจากมาตรวัดจำนวนบรรทัดโค้ด มาตรวัดของ McCabe และ มาตรวัดความซับซ้อนของ Halstead

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

ความท้าทายอย่างหนึ่งเกี่ยวกับการบำรุงรักษาคือหลักสูตรวิศวกรรมซอฟต์แวร์หลายหลักสูตรไม่ได้เน้นเรื่องนี้ และมอบหมายงานแบบครั้งเดียวจบที่มีข้อกำหนดที่ชัดเจนและไม่เปลี่ยนแปลง^{[ 39 ]} หลักสูตร วิศวกรรมซอฟต์แวร์ไม่ได้ครอบคลุมระบบที่ซับซ้อนเท่ากับที่เกิดขึ้นในโลกแห่งความเป็นจริง^{[ 40 ]}วิศวกรพัฒนาที่รู้ว่าตนเองจะไม่ต้องรับผิดชอบในการบำรุงรักษาซอฟต์แวร์จึงไม่มีแรงจูงใจที่จะสร้างระบบบำรุงรักษา^{[ 2 ]}

งานบำรุงรักษามักถูกมองว่าเป็นงานที่ไม่คุ้มค่าสำหรับวิศวกรซอฟต์แวร์ซึ่งหากได้รับมอบหมายให้ทำงานบำรุงรักษา พวกเขามักจะลาออก^{[ 41 ] [ 42 ]} งาน นี้มักได้รับค่าตอบแทนน้อยกว่างานที่เทียบเคียงได้ในด้านการพัฒนาซอฟต์แวร์^{[ 42 ]}งานนี้มักถูกมอบหมายให้แก่พนักงานชั่วคราวหรือพนักงานที่มีทักษะน้อยกว่า^{[ 2 ] [ 43 ]}แม้ว่าวิศวกรบำรุงรักษามักจะมีอายุมากกว่านักพัฒนาซอฟต์แวร์ ส่วนหนึ่งเป็นเพราะพวกเขาต้องคุ้นเคยกับเทคโนโลยีที่ล้าสมัย^{[ 43 ]}ในปี 2551 วิศวกรซอฟต์แวร์และโปรแกรมเมอร์ประมาณ 900,000 คนจากทั้งหมด 1.3 ล้านคนที่ทำงานในสหรัฐอเมริกา ทำงานด้านการบำรุงรักษา^{[ 44 ]}

บริษัทต่างๆ เริ่มจัดตั้งทีมแยกต่างหากสำหรับการบำรุงรักษา ซึ่งนำไปสู่การว่าจ้างบริษัทภายนอกให้ทำงานนี้ และเมื่อเข้าสู่ศตวรรษที่ 21 บางครั้งก็มีการย้ายงานไปยังประเทศอื่น ไม่ว่าจะเป็นส่วนหนึ่งของบริษัทเดิมหรือเป็นหน่วยงานแยกต่างหาก^{[ 45 ] [ 9 ]}แหล่งที่มาของการว่าจ้างภายนอกโดยทั่วไปคือประเทศที่พัฒนาแล้ว เช่น สหรัฐอเมริกา สหราชอาณาจักร ญี่ปุ่น และออสเตรเลีย ในขณะที่ปลายทางมักจะเป็นประเทศที่มีต้นทุนต่ำกว่า เช่น จีน อินเดีย รัสเซีย และไอร์แลนด์^{[ 46 ]}เหตุผลในการย้ายงานไปต่างประเทศ ได้แก่ การใช้ประโยชน์จากต้นทุนแรงงานที่ต่ำกว่า การสนับสนุนตลอด 24 ชั่วโมง การลดแรงกดดันด้านเวลาของนักพัฒนา และการย้ายการสนับสนุนให้ใกล้กับตลาดสำหรับผลิตภัณฑ์มากขึ้น^{[ 47 ]}ข้อเสียของการย้ายงานไปต่างประเทศ ได้แก่ อุปสรรคในการสื่อสารในรูปแบบของปัจจัยต่างๆ เช่นเขตเวลาความไม่สอดคล้องกันขององค์กร และความแตกต่างทางวัฒนธรรม^{[ 9 ]} แม้ว่านายจ้างหลายรายจะมองว่างานบำรุงรักษาเป็นงานที่ใช้ทักษะต่ำและเป็นขั้นตอนการพัฒนาซอฟต์แวร์ที่เหมาะสมที่สุดสำหรับการจ้างงานจากต่างประเทศ^{[ 9 ] [ 48 ]}แต่จำเป็นต้องมีการสื่อสารอย่างใกล้ชิดกับลูกค้าและการตอบสนองที่รวดเร็ว ซึ่งทั้งสองอย่างนี้ถูกขัดขวางโดยปัญหาการสื่อสารเหล่านี้^{[ 9 ]}

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

• การหยุดการทำงาน—ไม่ต้องทำงานเพิ่มเติมในระบบเดิมอีกต่อไป^{[ 50 ]}ตัวเลือกนี้อาจถูกเลือกหากผู้ขายต้องการสร้างรายได้ต่อไปให้นานที่สุดเท่าที่จะเป็นไปได้ในขณะที่หลีกเลี่ยงค่าใช้จ่ายในการบำรุงรักษา^{[ 12 ]}
• การว่าจ้างบริษัทอื่นให้ดำเนินการฟังก์ชันของระบบเดิม โดยเฉพาะอย่างยิ่งหากไม่ถือว่าเป็นฟังก์ชันธุรกิจหลัก^{[ 50 ]}
• การทิ้งระบบเดิมที่มีอยู่และพัฒนาระบบใหม่ตั้งแต่เริ่มต้นเพื่อให้บรรลุเป้าหมายเดียวกันกับระบบเดิม^{[ 50 ]}อย่างไรก็ตาม วิธีการนี้ไม่มีประสิทธิภาพเนื่องจากการทิ้งระบบที่ใช้งานได้ และด้วยวิธีการนี้มีความเสี่ยงที่ระบบใหม่จะไม่สามารถตอบสนองความต้องการทางธุรกิจที่เปลี่ยนแปลงไปได้^{[ 50 ]}
• การห่อหุ้มแอปพลิเคชันเดิมด้วยเลเยอร์นามธรรมเพื่อลดความซับซ้อนของอินเทอร์เฟซที่ล้าสมัย^{[ 50 ]}โค้ดต้นฉบับไม่ได้ถูกแก้ไข แต่อินเทอร์เฟซใหม่ช่วยให้แอปพลิเคชันใหม่สามารถเข้าถึงส่วนประกอบที่ได้รับการทดสอบแล้วได้ วิธีนี้ไม่ได้แก้ไขปัญหาใดๆ เกี่ยวกับการบำรุงรักษาระบบเดิม^{[ 51 ]}ฐานข้อมูล ฟังก์ชัน และแอปพลิเคชันทั้งหมดอาจถูกห่อหุ้มด้วยวิธีนี้^{[ 52 ]}
• การย้ายระบบเดิมไปยังแพลตฟอร์มใหม่สามารถลดค่าใช้จ่ายในการพัฒนาซอฟต์แวร์ใหม่ได้โดยการนำการใช้งาน การออกแบบ ข้อกำหนด และความต้องการของระบบเดิมมาใช้ซ้ำ^{[ 53 ]}การย้ายระบบอาจใช้เวลา 5 ถึง 10 ปี แต่จะส่งผลให้มีความยืดหยุ่นมากขึ้นและประหยัดค่าใช้จ่ายในการบำรุงรักษาซอฟต์แวร์ในระยะยาว^{[ 54 ]}ค่าใช้จ่ายมากถึง 80 เปอร์เซ็นต์อยู่ที่การทดสอบ กล่าวคือ การตรวจสอบให้แน่ใจว่าระบบใหม่มีผลลัพธ์เหมือนกับระบบเดิม^{[ 55 ]}หลังจากที่ระบบใหม่เสร็จสมบูรณ์แล้ว จำเป็นต้องมีการเปลี่ยนผ่านจากระบบเดิมไปสู่ระบบใหม่โดยมีการหยุดชะงักของฟังก์ชันทางธุรกิจให้น้อยที่สุด^{[ 55 ]}

แม้ว่าการบำรุงรักษาจะใช้ทรัพยากรการพัฒนาซอฟต์แวร์ส่วนใหญ่ แต่ก็เป็นขั้นตอนการพัฒนาซอฟต์แวร์ที่ได้รับการศึกษาน้อยที่สุด^{[ 56 ] [ 57 ]}วรรณกรรมส่วนใหญ่มุ่งเน้นไปที่วิธีการพัฒนาโค้ดที่บำรุงรักษาได้ตั้งแต่เริ่มต้น โดยให้ความสำคัญน้อยลงกับการกระตุ้นให้วิศวกรให้ความสำคัญกับการบำรุงรักษา^{[ 58 ]}ณ ปี 2020 โซลูชันอัตโนมัติสำหรับการปรับโครงสร้างโค้ดเพื่อลดความพยายามในการบำรุงรักษาเป็นหัวข้อการวิจัยที่กำลังดำเนินอยู่^{[ 59 ]}เช่นเดียวกับการประเมินความสามารถในการบำรุงรักษาที่ได้รับการปรับปรุงด้วยการเรียนรู้ของเครื่อง^{[ 60 ]}

• การประมาณต้นทุนในวิศวกรรมซอฟต์แวร์
• ต้นทุนรวมในการเป็นเจ้าของคือ ต้นทุนของผลิตภัณฑ์ ซึ่งรวมถึงต้นทุนการบำรุงรักษาและต้นทุนทางอ้อมอื่นๆ