2.3.Coping with change.md

Coping with change

• ในโครงการซอฟต์แวร์ขนาดใหญ่ การเปลี่ยนแปลง เป็นสิ่งที่ไม่สามารถหลีกเลี่ยงได้
  • system requirements เปลี่ยนตาม business changes
  • เทคโนโลยีใหม่ๆ ช่วยให้เราสามารถพัฒนาซอฟต์แวร์ได้ง่ายขึ้น
  • platforms ที่ออกมาใหม่ๆ ต้องการ application ที่ต่างออกไปจากเดิม เช่น mobile phone
• ในการเปลี่ยนแปลง จะมีงานสองส่วนคือ
  • rework (เช่น re-analysing requirements)
  • implementing new functionality

Reducing the costs of rework

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

Coping with changing requirements

• ทำต้นแบบระบบ
  • ออกแบบและพัฒนาในส่วนสำคัญและพัฒนาได้เร็ว เพื่อตรวจสอบว่าตรงตามความต้องการของผู้ใช้หรือไม่
• ทยอยส่งมอบงาน
  • เหมาะกับการพัฒนาแบบ Incremental เพื่อรับคำแนะนำติชม และให้ลูกค้าได้ทดลองใช้ระบบในระยะเวลาหนึ่ง

Software prototyping

• ต้นแบบ (prototype) ถือเป็น initial version ของ system
  • ใช้เพื่อสาธิต หรือนำเสนอแนวคิดของระบบ และให้ผู้ใช้ได้ทดลองใช้ นำไปสู่ทางเลือกในการพัฒนาระบบ
• ต้นแบบ สามารถนำมาใช้เมื่อใด?

  • ในขั้นตอน requirements เพื่อช่วยในการซักถามและเก็บ requirements ซึ่งสามารถนำไปใช้ได้ในกระบวนการ validation

  • ในขั้นตอน design เพื่อหาทางเลือกในการพัฒนาและออกแบบ User Interface

  • ในขั้นตอน testing เพื่อรัน back-to-back tests

  • back-to-back tests คืออะไร?

Benefits of prototyping

• เพิ่มความเชื่อถือได้ของระบบ
• ตรงตามความต้องการของผู้ใช้
• เพิ่มคุณภาพในขั้นตอนการออกแบบ
• บำรุงรักษาง่าย
• ลดความยุ่งยากในการพัฒนา

The process of prototype development

Prototype development

• อาจพัฒนาด้วย tools หรือภาษาที่เหมาะกับการทำ rapid prototyping
• อาจจะตัด functionality บางอย่างออกไป
  • ต้นแบบ ควรมีเฉพาะสิ่งที่เข้าใจได้ยากหรืออาจจะนำไปสู่ความเข้าใจที่คลาดเคลื่อนระหว่าง user กับ developer
  • อะไรที่คุยกันเข้าใจง่ายๆ ไม่ต้องเสียเวลาทำต้นแบบ
  • ยังไม่ต้องเสียเวลากับการทำ Error checking หรือ recovery
  • เน้นที่ functional แทนที่จะทำ non-functional requirements
    • non-functional requirements เช่น reliability และ security

Throw-away prototypes

• เมื่อพัฒนาเสร็จ ควรเก็บ prototype ไว้ในที่ที่อยู่นอกพื้นที่การพัฒนา เนื่องจากมันอาจจะไม่สอดคล้องกับกระบวนการพัฒนาระบบ
  • เนื่องจากออกแบบอย่างลวกๆ (เพื่อทำความเข้าใจของทุกฝ่ายให้ตรงกัน) มันอาจจะไม่รองรับการพัฒนาเพื่อให้ตรงตาม requirement อื่น ๆ เช่น non-functional requirements
  • โดยปกติ การทำ prototypes มักจะไม่มีเอกสารต่างๆ ประกอบ
  • โดยทั่วไป prototype structure มักจะไปลดคุณภาพของกระบวนการพัฒนาซอฟต์แวร์
  • prototype โดยส่วนใหญ่มักจะไม่เข้ากับ quality standards เนื่องจากพัฒนาโดยภาษาหรือเครื่องมือที่เรียกว่า rapid prototype จึงมักจะขาดส่วนที่ควบคุมคุณภาพ

Incremental delivery

• แทนที่จะนำส่งระบบในรอบเดียว (single delivery) เราอาจจะแบ่งการพัฒนาและนำส่งออกเป็นหลาย ๆ รุ่น
  • แต่ละรุ่นอาจจะนำส่งตาม required functionality ที่แตกต่างกันไป
• ถ้ามีการนำส่งชนิดหลายรุ่น ให้ส่งซอฟต์แวร์ที่ตรงตาม USER REQUIREMENTS ก่อนเสมอ
  • ให้จัดลำดับความสำคัญให้ดี จัดตามความต้องการของผู้ใช้ ไม่ใช่จัดตามความชอบหรือถนัดของผู้พัฒนา
• เมื่อเริ่มพัฒนาในส่วน increment เราก็สามารถนำ requirement อื่น ๆ มาเริ่มพัฒนาได้

Incremental development and delivery

• Incremental development
  • พัฒนาระบบใน increment นั้นและทำการ evaluate แต่ละ increment ให้เสร็จก่อนที่จะขยับไปทำincrement ถัดไป
  • เป็นวิธีการปกติที่ใช้ใน agile methods (จะเรียนในหัวข้อที่ 3)
  • การทำ evaluation จะทำผ่าน user/customer proxy
• Incremental delivery
  • ส่งมอบ (deploy) increment ที่จะใช้โดย end-users
  • เป็นการ evaluation ซอฟต์แวร์ที่ตรงกับความเป็นจริงมากที่สุด;
  • สร้างระบบจำลองหรือทดแทนได้ยาก เนื่องจากแต่ละ increments จะมีความสามารถที่น้อยมาก เมื่อเทียบกับซอฟต์แวร์ที่สมบูรณ์

Incremental delivery

Incremental delivery advantages

• ส่งมอบสิ่งที่ลูกค้าต้องการมากที่สุดให้ก่อน ดังนั้นลูกค้าสามารถใช้งานได้ก่อน และได้ผลตอบแทนก่อน
• increments แรกๆ จะเป็นเสมือน prototype ให้กับลูกค้า ที่จะประเมินความต้องการ เพื่อที่จะนำไปสู่การพัฒนา increments ถัดไป
• มีความเสี่ยงน้อย ที่จะล้มเหลวทั้งโครงการ
• ส่วนที่ตรงกับ requirement มากที่สุด จะถูกนำไปใช้ก่อนและถูกทดสอบมากที่สุด

Incremental delivery problems

• ส่วนใหญ่แล้ว ความต้องการหลักของลูกค้า มักจะเป็นระบบพื้นฐานทีกระจัดกระจายไปตามส่วนต่างๆ ของทั้งระบบ
  • requirements ที่ชัดเจน มักจะยังไม่ออกมา จนกว่าจะถึงรอบการพัฒนา increment
  • ยากที่จะรู้ถึงความต้องการพื้นฐานที่แท้จริง ที่จำเป็นสำหรับทุก ๆ increments
• ปัญหาที่สำคัญคือ specification ใหม่ๆ มักจะเกิดคู่ขนานไปกับการพัฒนาทุก ๆ increment
  • ทำอย่างไร พัฒนาเท่าไร ก็ไม่จบสักที…
  • แต่ไม่ต้องกังวล เพราะโครงการซอฟต์แวร์ มักจะมี complete system specification เป็นส่วนประกอบของสัญญาจ้างพัฒนาซอฟต์แวร์ เราสามารถใช้สิ่งนั้นเป็นกรอบและข้อยุติในโครงการซอฟต์แวร์ได้