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

แนวคิดเรื่องการเชื่อมโยงความซับซ้อนของซอฟต์แวร์กับความสามารถในการบำรุงรักษา ซอฟต์แวร์ ได้รับการสำรวจอย่างกว้างขวางโดยศาสตราจารย์ Manny Lehmanผู้พัฒนาLaws of Software Evolution ของเขา เขาและผู้ร่วมเขียนLes Beladyได้สำรวจตัวชี้วัดซอฟต์แวร์ จำนวนมาก ที่สามารถใช้ในการวัดสถานะของซอฟต์แวร์ และในที่สุดก็สรุปได้ว่าวิธีแก้ปัญหาที่ใช้งานได้จริงเพียงอย่างเดียวคือการใช้แบบจำลองความซับซ้อนแบบกำหนดได้^{[ 1 ]}

ความซับซ้อนของโปรแกรมที่มีอยู่จะกำหนดความซับซ้อนของการเปลี่ยนแปลงโปรแกรม ความซับซ้อนของปัญหาสามารถแบ่งออกเป็นสองประเภท: ^{[ 2 ]}

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

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

• เมตริกความซับซ้อนเชิงวัฏจักรของ McCabe
• ตัวชี้วัดวิทยาศาสตร์ซอฟต์แวร์ของ Halstead
• เฮนรีและคาฟูราได้นำเสนอ "เมตริกโครงสร้างซอฟต์แวร์ตามการไหลของข้อมูล" ในปี 1981 ^{[ 3 ]}ซึ่งวัดความซับซ้อนเป็นฟังก์ชันของ " fan-in " และ "fan-out" พวกเขากำหนด fan-in ของขั้นตอนเป็นจำนวนการไหลภายในไปยังขั้นตอนนั้นบวกกับจำนวนโครงสร้างข้อมูลที่ขั้นตอนนั้นดึงข้อมูลออกมา fan-out ถูกกำหนดเป็นจำนวนการไหลภายในออกจากขั้นตอนนั้นบวกกับจำนวนโครงสร้างข้อมูลที่ขั้นตอนนั้นอัปเดต การไหลภายในเกี่ยวข้องกับข้อมูลที่ส่งผ่านไปยังและจากขั้นตอนที่เรียกหรือถูกเรียกโดยขั้นตอนที่เกี่ยวข้อง ค่าความซับซ้อนของเฮนรีและคาฟูราถูกกำหนดเป็น "ความยาวของขั้นตอนคูณด้วยกำลังสองของ fan-in คูณด้วย fan-out" (ความยาว × (fan-in × fan-out)²)
• Chidamber และ Kemerer ได้นำเสนอ "ชุดเมตริกสำหรับการออกแบบเชิงวัตถุ" ในปี 1994 ^{[ 4 ]}โดยเน้นที่เมตริกสำหรับโค้ดเชิงวัตถุ พวกเขานำเสนอเมตริกความซับซ้อนเชิงวัตถุ 6 รายการ ได้แก่ (1) เมธอดที่มีน้ำหนักต่อคลาส (2) การเชื่อมโยงระหว่างคลาสวัตถุ (3) การตอบสนองสำหรับคลาส (4) จำนวนลูก (5) ความลึกของต้นไม้การสืบทอด และ (6) การขาดความสอดคล้องของเมธอด

นอกจากนี้ ยังมีตัวชี้วัดอื่นๆ อีกหลายอย่างที่สามารถใช้ในการวัดความซับซ้อนของการเขียนโปรแกรมได้:

• ความซับซ้อนของการแตกแขนง (เมตริก Sneed)
• ความซับซ้อนในการเข้าถึงข้อมูล (Card Metric)
• ความซับซ้อนของข้อมูล (เมตริกชาปิน)
• ความซับซ้อนของการไหลของข้อมูล (เมตริกเอลชอฟ)
• ความซับซ้อนในการตัดสินใจ (ตัวชี้วัดของ McClure)
• ความซับซ้อนของเส้นทาง (เมตริก Bang)

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

Chidamber และ Kemerer ^{[ 4 ]}เสนอชุดเมตริกความซับซ้อนของการเขียนโปรแกรมที่ใช้กันอย่างแพร่หลายในการวัดและบทความทางวิชาการ ได้แก่ วิธีการถ่วงน้ำหนักต่อคลาส การเชื่อมโยงระหว่างคลาสวัตถุ การตอบสนองสำหรับคลาส จำนวนลูก ความลึกของต้นไม้การสืบทอด และการขาดความสอดคล้องของวิธีการ ซึ่งอธิบายไว้ด้านล่าง:

• วิธีการถ่วงน้ำหนักต่อคลาส ("WMC")
  • ${\displaystyle WMC=\sum _{i=1}^{n}c_{i}}$
  • n คือจำนวนเมธอดในคลาส
  • ${\displaystyle c_{i}}$ความซับซ้อนของวิธีการ
• การเชื่อมโยงระหว่างคลาสของวัตถุ ("CBO")
  • จำนวนของคลาสอื่นที่เชื่อมโยงกัน (ใช้งานหรือถูกใช้งาน)
• การตอบสนองสำหรับคลาส ("RFC")
  • ${\displaystyle RFC=|RS|}$ที่ไหน
  • ${\displaystyle RS=\{M\}\cup _{all\ i}\{R_{i}\}}$
  • ${\displaystyle R_{i}}$คือชุดของเมธอดที่ถูกเรียกโดยเมธอด i
  • ${\displaystyle M}$คือชุดของเมธอดในคลาส
• จำนวนเด็ก ("NOC")
  • ผลรวมของคลาสทั้งหมดที่สืบทอดมาจากคลาสนี้หรือคลาสที่เป็นลูกหลานของมัน
• ความลึกของแผนผังการสืบทอด ("DIT")
  • ความลึกสูงสุดของแผนผังการสืบทอดสำหรับคลาสนี้
• การขาดความสอดคล้องกันของวิธีการ ("LCOM")
  • วัดส่วนที่ทับซ้อนกันของแอตทริบิวต์ที่ใช้ร่วมกันโดยเมธอดของคลาส
  • ${\displaystyle LCOM={\begin{cases}|P|-|Q|,&{\text{ถ้า }}|P|>|Q|\\0,&{\text{มิฉะนั้น }}\end{cases}}}$
  • ที่ไหน${\displaystyle P=\{(I_{i},I_{j})|I_{i}\cap I_{j}=\emptyset \}}$
  • และ${\displaystyle Q=\{(I_{i},I_{j})|I_{i}\cap I_{j}\neq \emptyset \}}$
  • `with` คือชุดของแอตทริบิวต์ (ตัวแปรอินสแตนซ์) ที่เข้าถึง (อ่านหรือเขียน) โดยเมธอดที่ `-th` ของคลาส${\displaystyle I_{i}}$${\displaystyle i}$

• กระบวนทัศน์การเขียนโปรแกรม
• วิกฤตซอฟต์แวร์