![1. Predictive, Waterfall-Like
Processes
Thất bại:
Kết quả thống kê(Standish Group’s Chaos report
survey [Standish 1994]):
31% bị hủy trước khi hoàn thành.
53% dự án có chỉ phí > 189% các ước lượng của chúng.
Chỉ 16% dự án được hoàn thành đúng thời hạn và trong
kinh phí.
Với các công ty lớn, chỉ 42% đặc trưng/chức năng của
p.mềm được phát hành một cách đầy đủ.](https://image.slidesharecdn.com/topic1sdlcoverview-240814044726-41ea15bd/85/Topic1_SDLC-Software-Development-Life-Cycle-_Overview-pdf-13-320.jpg)
Topic1_SDLC(Software Development Life Cycle)_Overview.pdf
- 1. Software Development Life Cycle (SDLC) - Overview Topic 1: TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN & TRUYỀN THÔNG KHOA CÔNG NGHỆ THÔNG TIN - BỘ MÔN CÔNG NGHỆ PHẦN MỀM --------------- Giảng viên: Phạm Thị Thương – Bộ môn CNPM – Khoa CNTT Email: ptthuong@ictu.edu.vn
- 2. Nội dung chính 1. Vòng đời phát triển phần mềm - Software Development Life Cycle (SDLC) 2. Sơ lược lịch sử phát triển của các tiến trình phần mềm 3. Hợp nhất Phát triển (Dev) & Vận hành (Ops) phần mềm - DevOps
- 3. 1. Development Life Cycle (SDLC) SDLC (also called Software process): Is a set of processes is used to develop and deliver high quality software Is structured in different stages (what-how-build-use) Can be accomplished using different models (SDLC models) SDLC models: descripte phased of the software cycle & the order in which those phases are executed Ex., Water fall model, V-model, RUP, …
- 4. Nội dung chính 1. Vòng đời phát triển phần mềm - Software Development Life Cycle (SDLC) 2. Sơ lược lịch sử ↑ các tiến trình p.mềm 3. Hợp nhất Phát triển (Dev) & Vận hành (Ops) phần mềm - DevOps
- 5. 2. Lịch sử ↑ các tiến trình p.mềm Xem hình (dưới)
- 7. 1. Predictive, Waterfall-Like Processes Figure 1-2. Simplified “waterfall” model. Also called Linear – Sequential Life Cycle Model Progress flows top to bottom, like a waterfall.
- 8. 1. Predictive, Waterfall-Like Processes => Các vấn đề nảy sinh?
- 9. 1. Predictive, Waterfall-Like Processes • Các vấn đề nảy sinh: Vấn đề 1: Test chỉ bắt đầu sau khi việc phát triển hoàn thành. => V – model là một biến thể của Waterfall model Test được lập kế hoạch // với từng giai đoạn tương ứng. Xem hình:
- 10. 1. Predictive, Waterfall-Like Processes Các vấn đề nảy sinh: Vấn đề 2: Xử lý không hiệu quả các yêu cầu: Yêu cầu: Fixed Yêu cầu: là cơ sở để ước lượng lịch biểu và ngân quỹ của dự án => Xem Hình (dưới)
- 11. 1. Predictive, Waterfall-Like Processes Figure 1-2: Yêu cầu cơ sở ước lượng cost + schedule
- 12. 1. Predictive, Waterfall-Like Processes Yêu cầu: fixed schedule và budget cũng bị fixed: Dẫn chúng ta đến cạm bẫy “tam giác thép” (“iron triangle” trap) như hình Figure 1-4: Trật hẹp, ràng buộc Không thể thích nghi, mở rộng, thay đổi, … Nguyên nhân thất bại các dự án:
- 13. 1. Predictive, Waterfall-Like Processes Thất bại: Kết quả thống kê(Standish Group’s Chaos report survey [Standish 1994]): 31% bị hủy trước khi hoàn thành. 53% dự án có chỉ phí > 189% các ước lượng của chúng. Chỉ 16% dự án được hoàn thành đúng thời hạn và trong kinh phí. Với các công ty lớn, chỉ 42% đặc trưng/chức năng của p.mềm được phát hành một cách đầy đủ.
- 14. 1. Predictive, Waterfall-Like Processes Tuy nhiên, mô hình vẫn được sử dụng rộng rãi đến ngày nay: Xem: Hình 1-5
- 15. 2. Iterative & Incremental Processes Lý do ra đời: Các thất bại của mô hình thác nước Sức ép thị trường ngày càng tăng Sự phát triển nhanh chóng, vượt bậc của các kỹ thuật, công cụ. => Dẫn đến iterative processes: Ra đời: 1980s và 1990s Xem hình (dưới)
- 17. 2. Iterative & Incremental Processes Does not attempt to start with a full specification of requirements. Instead, development begins by specify and implementing just part of software, which can then be review to identify further requirements This process is then repeat (Incremental), producing a new version/each cycle of the model The lifecycle ~ a multiple-waterfall cycle
- 18. 2. Iterative and Incremental Processes Ex., RUP RUP – lặp 2 chiều
- 19. 3. Agile (Adaptive Processes) Gần đây hơn, Một số thể hiện của RUP, nhưng linh động hơn, nhẹ hơn: Agile.
- 21. 3. Agile (Adaptive Processes) Cách ↑ lặp lại qua các chu kỳ nước rút liên tiếp (successive sprint cycles). ~ Chu kỳ phát triển phần mềm được chia thành các sprint cycles khoảng từ 2 đến 4 weeks Dựa trên ý tưởng: "các chu kỳ nhỏ hơn có thể được phát triển và quản lý nhanh hơn/team (developers & testers cùng cộng tác làm việc) Bugs được xác định và fixed sớm tại mỗi sprint Khách hàng có thể nhìn thấy các đặc trưng sản phẩm sớm và tạo các thay đổi cần thiết nếu cần.
- 23. 3. Agile (Adaptive Processes) Quản lý yêu cầu ≠ cách tiếp cận truyền thống: Dựa trên các nguyên tắc cốt lõi: Tuyên ngôn #1—Ưu tiên cao nhất là sự thỏa mãn của khách hàng qua việc phát hành sớm và liên tục phần mềm có giá trị. Tuyên ngôn #2—Chào đón các yêu cầu thay đổi, thậm chí các thay đổi sau phát triển. Khai thác thay đổi tạo lợi thế cạnh tranh khách hàng. => Thay vì mất hàng thàng để xây dựng các đặc tả yêu cầu chi tiết ….teams tập trung vào việc phát hành sớm sản phẩm đến khách hàng.
- 24. 3. Agile (Adaptive Processes) Loại bỏ tam giác thép đã ngăn chặn chúng ta đạt được các mục tiêu chất lượng & độ tin cậy. Agile fixes the date and resources and varies the scope Quality is also fixed. So, now we have a truly virtuous software cycle: Fix quality—deliver a small increment in a timebox— repeat. Xem hình (dưới)
- 25. 3. Agile (Adaptive Processes)
- 26. 3. Agile (Adaptive Processes) Tối ưu ROI (return on investment – hoàn vốn) qua việc phát hành giá trị tăng dần Agile cũng dựa trên nguyên tắc kinh tế: “the sooner we deliver a feature, the sooner our customers will pay us for it”. Figure 1-9: Value delivery and ROI in waterfall versus agile
- 27. 3. Agile (Adaptive Processes)
- 28. 3. Agile (Adaptive Processes) Tối ưu ROI Nếu giả định vốn đầu tư là hằng số (vốn đầu tư thực tế sẽ thấp hơn nhiều trong agile ~ hoàn vốn (ROI) sẽ cao), thì đây là sự thật: ROI $$ (agile) > ROI $ (waterfall) Agile ROI tăng, do giá trị đặc trưng tăng theo (t) Xem hình (dưới)
- 29. 3. Agile (Adaptive Processes) Tối ưu ROI: Tỷ xuất lợi nhuận gộp => ROI $$$ (agile) >> ROI $ (waterfall)
- 30. 3. Agile (Adaptive Processes) Một số phương pháp Agile: Dynamic Systems Development Method (DSDM), Feature-Driven Development (FDD), Adaptive Software Development, Scrum, Extreme Programming (XP), Open Unified Process (Open UP), Agile RUP, Kanban, Lean, Crystal Methods …
- 31. 3. Agile (Adaptive Processes) Hình 1-7. Khảo sát các phương pháp Agile được sử dụng rộng rãi nhất1 1Source: VersionOne’s 2009 Agile Methodology Survey
- 32. Scrum
- 33. Scrum Được sử dụng rộng rãi Vì sự nhẹ nhàng của nó, teams tập trung ↑ các đặc trưng tăng dần. Mỗi đội (team) gồm các vai trò: Scrum master: Thiết lập nhóm, xây dựng các sprint meetings, loại bỏ các khó khăn trở ngại trong quá trình phát triển. Product owner: tạo và ưu tiên các product backlog (~danh sách các features và các yêu cầu chức năng cần phát triển), phát hành các chức năng của sản phẩm sau mỗi sprint iteration cycle Developers & testers: quản lý và tổ chức công việc cho ra kết quả của sprint cycle
- 34. Scrum
- 36. Extreme Programming (XP) XP: được sử dụng rộng rãi Team gồm 5 → 10 programmers: ngồi làm việc cùng với đại diện của khách hàng (on-site). Phát triển tập trung vào việc phát hành các đặc trưng tăng dần (builds or iterations thường xuyên/liên tục). Các yêu cầu được đặc tả như các user stories mỗi story ~ chức năng mới người dùng yêu cầu. Programmers làm việc theo cặp Phải tuân theo strict coding standards, và thực hiện unit test code của họ. Customers tham gia vào acceptance testing.
- 37. Extreme Programming (XP) XP thường áp dụng với small teams (< 10 developers) Chữ P trong XP chỉ programming => Đối lập với các phương pháp khác, XP tập trung vào code: code phải tuân theo các chuẩn nghiêm ngặt và tạo ra kết quả với chất lượng cực cao.
- 38. 4. Enterprise – Scale Adaptive (Lean & Agile) Processes Có đầy đủ lợi thế của Agile: ~ Agile + Tinh gọn + Áp dụng mức doanh nghiệp. Phát triển & Vận hành phần mềm liên tục.
- 40. 4. Enterprise – Scale Adaptive (Lean & Agile) Processes DevOps ~ Lean & Agile Hợp nhất Dev & Ops theo đường ống tích hợp và phát hành liên tục Giải quyết những vấn đề/thách thức đang tồn tại với tiến trình phần mềm trước đó Vấn đề/thách thức?
- 41. 1) Vấn đề, thách thức Cách tiếp cận truyền thống Vấn đề nẩy sinh 1: Mỗi giai đoạn/SDLC bị phân mảnh&được quản lý, triển khai bởi teams, departments, processes, & tools độc lập =>Rủi ro khi bàn giao kết quả giữa các giai đoạn (lỗi phát sinh do không tương thích, p.mềm không vận hành được do không nhất quán giữa các môi trường cộng tác ↑: Dev, QA, Product). Mất thời gian: chờ đợi, bàn giao thủ công, xử lý quá Nhiều vấn đề tồn đọng nẩy sinh do tương tác giữa các team không hiệu quả, không thường xuyên => Hình (dưới)
- 42. 1) Vấn đề, thách thức Chu kỳ phát hành truyền thống – bị phân mảnh Ví dụ: xem hình (dưới)
- 43. Teams work trầm lặng: -Tồn đọng vấn đề -Phải chờ đợi nhau -Xử lý quá Bàn giao thủ công: mã nguồn + tài liệu => Lost time Tích hợp hàng tuần Phân phối p.mềm thủ công đến QA Bàn giao p.mềm hàng quý Phát hành p.mềm thủ công đến Product Bàn giao thủ công: - apps, - tài liệu, - cấu hình. => Lost time Thiết lập và bảo trì hệ thống thủ công => Lost time+ defects Static test Unit tests Function tests
- 44. 1) Vấn đề, thách thức Cách tiếp cận truyền thống Vấn đề nảy sinh 2: Xem nhẹ giai đoạn vận hành => Nhiều vấn đề nẩy sinh sau đó Ví dụ: xem hình (dưới)
- 45. Cách tiếp cận truyền thống: Vấn đề 2: xem nhẹ giai đoạn vận hành Nhiều vấn đề nẩy sinh! See: Figures 1) Vấn đề, thách thức
- 46. Cách tiếp cận truyền thống Vấn đề 3: ? for achievements Thị trường thế giới: kinh doanh đồ thủ công, mỹ nghệ (đồ cổ) Giải pháp của họ gì??? 1) Vấn đề, thách thức
- 47. DevOps – Giải pháp cho các vấn đề nêu trên => DevOps? 1) Vấn đề, thách thức
- 48. Nội dung chính 1. Vòng đời phát triển phần mềm - Software Development Life Cycle (SDLC) 2. Sơ lược lịch sử ↑ các tiến trình p.mềm 3. Hợp nhất Phát triển (Dev) & Vận hành (Ops) phần mềm - DevOps
- 49. 3. Giải pháp - DevOps DevOps: Put simple … ↓ thời gian ngưng nghỉ/trì hoãn ↑ tính cạnh tranh
- 50. 3. Giải pháp - DevOps DevOps – The solution Combine: Dev, QA & Ops by pipeline tích hợp và phát hành liên tục
- 51. 3. Giải pháp - DevOps DevOps: Tích hợp tất cả các giai đoạn của SDLC vào một đơn vị hợp nhất. ~ Hệ tư tưởng hoàn toàn mới quét qua các tổ chức CNTT trên toàn thế giới: thúc đẩy tối ưu SDLC, thúc đẩy hợp tác giữa các kỹ sư phát triển và bộ phận operation, gia tăng lợi nhuận, sự t.mãn của khách hàng. Xóa k.c giữa các bên liên quan (Dev, Ops) “Dev”: ~ tất cả các nhà phát triển phần mềm “Ops”: gồm các kỹ sư hệ thống, quản trị hệ thống, nhân viên operation, kỹ sư phát hành, DBA, kỹ sư mạng, chuyên gia bảo mật, và nhiều công việc phụ khác.
- 52. 3. Giải pháp - DevOps DevOps: combine Dev and Ops…
- 53. 3. Giải pháp - DevOps
- 54. 3. DevOps DevOps - Pipeline tích hợp & phát hành trên một đường ống liên tục => Hợp nhất các môi trường cộng tác ↑: (Dev, QA, Ops)
- 55. 3. DevOps DevOps – toolchain Chưa từng được đề cập bởi các software processes trước đó ???
- 56. 3. DevOps Faster, better, chapter, happier
- 57. 3. DevOps DevOps – Xây dựng team phong phú
- 58. 3. DevOps DevOps quan hệ với Cloud => Cloud computing và DevOps đang dần chuyển hóa CNTT từ nền kinh tế sản xuất sang nền kinh tế dịch vụ
- 59. 3. DevOps – Xu hướng ↑ • Phát triển ổn định qua nhiều năm:
- 60. 3. DevOps – Áp dụng Sự xâm nhập của DevOps vào các doanh nghiệp => cho thấy xu hướng phát triển tiềm năng của nó.
- 61. 3. DevOps – Áp dụng
- 62. 3. DevOps – Áp dụng
- 63. Tổng kết 1. Vòng đời phát triển phần mềm - Software Development Life Cycle (SDLC) 2. Sơ lược lịch sử phát triển của các tiến trình phần mềm 3. Hợp nhất Phát triển (Dev) & Vận hành (Ops) phần mềm - DevOps
- 64. Discussion
- 65. Preparing for next lesson Topic 2: DevOps Frameworks