Lehman Laws of Software Evolution

ช่วงนี้ต้องอ่าน Paper เตรียมนำเสนออาจารย์ แต่อ่านไปอ่านมา มันก็ไปอ้างอิง Paper อื่นๆด้วย เลยเอามาสรุปไว้ใน ฺBlog ดีกว่า

• กฎแห่งการเปลี่ยนแปลงอย่างต่อเนื่อง  (Law of Continuing Change:1974)
  • An E-type program that is used must be continually adapted else it becomes progressively less satisfactory.
  • Software ต้องมีการปรับเปลี่ยนแก้ไข ตลอดช่วงเวลาที่ใช้งาน (Software Life Cycle) จนกระทั่งเลิกใช้ อาจจะมีการเปลี่ยน Version ใหม่ หรือ รื้อปรับระบบใหม่ เพราะ คุ้มค่ามากกว่าที่จะยอมแก้ไข (เช่น การเปลี่ยนเทคโนโลยี จาก VB6 ไปเป็น ASP.Net)
• กฎแห่งความซับซ้อนที่เพิ่มขึ้น (Law of Increasing Complexity:1974)
  • As a program is evolved its complexity increases unless work is done to maintain or reduce it.
  • Software มองลงไปที่ Source Code ยิ่งเวลาผ่านไป มีการแก้ไขปรับปรุงอยู่ตลอด สิ่งที่ตามมา รูปแบบโครงสร้างของ Program จะลดลง (พูดง่ายๆ Code มันเน่าและ เป็น spaghetti) และความซับซ้อนเพิ่มขึ้น Software ควรมี Archtecture ที่ดี และมีการคิดอย่างถี่ถ้วนก่อนการแก้ไข เพื่อลดความซับซ้อน
• กฎแห่งการวางระเบียบตัวเอง (Law of Self-regulation:1974)
  • The program evolution process is self regulating with close to normal distribution of measures of product and process attributes.
  • การวิวัฒนาการของตัว Software (self-regulating process) ตัว System Attribute อย่างเช่น Size(ขนาด). เวลาระหว่างการ Release ในแต่ละรอบ เมื่อเทียบกับจำนวน Incident ที่ได้แจ้งมา มันเข้าใจกับ normal distribution of measures ของ product and process attributes.
• กฎแห่งการอนุรักษ์สภาพเสถียรเชิงการจัดระเบียบ (Law of Conservation of Organizational Stability:1978)
  • The average effective global activity rate on an evolving system is invariant over the product life time
  • อัตราการทำงานองค์รวมโดยเฉลี่ยในระบบแบบนี้ค่อนข้างคงที่ตลอดอายุการใช้งาน
• กฎการคงไว้ซึ่งความคุ้นเคย (Law of Conservation of Familiarity:1978)
  • During the active life of an evolving program, the content of successive releases is statistically invariant
  • ผู้ใช้งานทุกระดับมักคุ้นเคยกับซอฟต์แวร์ที่ตนเองรับผิดชอบอยู่ในองค์กร แต่เมื่อมีการเปลี่ยนแปลงเร็วเกินไปของซอฟต์แวร์อาจทำให้ความคุ้นเคยหายไป ดังนั้นการเติบโตควรเป็นไปอย่างพอดี
• กฎแห่งการเติบโตไปอย่างต่อเนื่อง (Law of Continuing Growth:1991)
  • Functional content of a program must be continually increased to maintain user satisfaction over its lifetime
  • Function การทำงานของ Program ต้องเพื่อขึ้นอย่างต่อเนื่อง เพื่อรักษาความพึงพอใจของ User ตอนการใช้งานของ Software
• กฎแห่งการลดลงซึ่งคุณภาพ (Law of Declining Quality:1996)
  • E-type programs will be perceived(รับรู้) as of declining quality unless rigorously maintained and adapted to a changing operational environment.
  • ระบบมีคุณภาพลดลง ยกเว้นแต่ว่ามีการดูแล และปรับปรุงให้เข้ากับสภาพแวดล้อมใหม่ๆได้ (ลองนึกถึงพวกรถยนต์ ที่ยังต้องมีการเช็คระยะ)
• กฎระบบย้อนกลับ (Feedback System Law:1996)
  • E-type Programming Processes constitute Multi-loop, Multi-level Feedback systems and must be treated as such to be successfully modified or improved
  • อ่านแล้วทำไมนึกถึงวิชา SPI ตัว Software ของเรา มันถูก Drive มาจากระบบ Feedback systems ตัว Multi-loop, Multi-level เรามองเป็นพวก Process Flow ตัวอย่างที่เราคิดว่าน่าจะใช้ คือ การที่ Software ที่อยู่บน Production มีการปรับปรุงจาก Feedback systems ซึ่งตัว Feedback ในที่นี้ คือ พวก Service Incident (สิ่งที่ User แจ้งว่า Software ของเรามีปัญหาแหละ) มองว่าใช้ measure break/fix ratio ก็ได้นะ