Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 3: Qui trình và mô hình bảo trì phần mềm - Nguyễn Thị Thanh Trúc

fall Model 
 Feasibility study Requirements 
 Requirements Design 
 System design 
 Program design Implementation 
 Implementation (coding) 
 Testing 
 Acceptance & release 
 Operation & maintenance 
 9 
UIT-VNUHCM 2009 
 Thảo luận Waterfall Model 
 Thuận lợi: 
 • qui trình rõ ràng 
 • cộng việc tách biệt 
 • kiểm soát chất lượng mỗi bước 
 • Kiểm soát chi phí ở mỗi bước 
 Không thuận lợi: 
 Mỗi giai đoạn trong qui trình thể hiện hiếu biết mới của giai 
 đoạn trước đó mà thường đòi hỏi giai đoạn sớm hơn được xét 
 duyệt lại. 
 The Waterfall Model is not enough! 
 10 
UIT-VNUHCM 2009 
 Tính tuần tự của các qui trình 
 Mô hình thuần tuần tự thì không thể 
 Ví dụ: 
 • Nghiên cứu khả thi không thể tạo ngân sách dự trù và lịch biểu 
 mà không có nghiên cứu sơ bộ những yêu cầu và thiết kế thăm 
 dò 
 • Thiết kế chi tiết hay thực thi thường bộc lộ kẽ hơ trong đặc tả 
 yêu cầu. 
 Kế hoạch phải được cho phép cho những hình thành từ bước 
 lặp. 
 11 
UIT-VNUHCM 2009 
 Modified Waterfall Model-1 
 Feasibility study Waterfall model 
 with feedback 
 Requirements 
 This is better 
 System design 
 Program design 
 Implementation (coding) 
 Testing 
 Acceptance & release 
 Operation & maintenance 
 12 
UIT-VNUHCM 2009 
 Modified Waterfall Model-2 
 Feasibility study 
 Test 
 Software 
 Requirements Test 
 System design 
 Design Test 
 Program design 
 Design Test 
 Implementation 
 Test 
 Experimentation 
 Debugging Test 
 Acceptance 
 Maintenance Test 
 13 
UIT-VNUHCM 2009 
 Iterative/spiral Refinement 
 Concept: Initial implementation for client and 
 user comment, followed by refinement until 
 system is complete 
 Evaluation Requirements 
 Implementation Design 
 14 
UIT-VNUHCM 2009 
 The Spiral Process 
 M I L E S T O N E S time 
 Intermediate version 
 Intermediate version (2nd prototype) X Product released X 
 (prototype) X 
Iteration # 1 2 3 
Requirements 
analysis 1 2 3 
Design 1 2 3 
Implementation 1 2 3 
Evaluation 1 2 3 15 
 UIT-VNUHCM 2009 
 Mô hình Life-Cycle khác 
 Build-and-fix model 
 Rapid prototyping model 
 Incremental model 
 Extreme programming 
 Component-based software engineering 
 Mô hình đồng bộ hoá và ổn định 
 (Synchronize-and-stabilize) model 
 Object-oriented life-cycle models 
 16 
UIT-VNUHCM 2009 
 1-Build and Fix Model 
 17 
UIT-VNUHCM 2009 
Lưu ý 
 Hầu hết phần mềm được phát triển dùng 
 mô hình build-and-fix model. Cơ bản là 
 không có mô hình. 
 oKhông đặc tả 
 oKhông thiết kế 
 Mô hình này hoàn toàn không thoả mãn và 
 không nên được chấp nhận. 
 18 
UIT-VNUHCM 2009 
 2-Rapid Prototyping Process 
 19 
UIT-VNUHCM 2009 
 2-Rapid Prototyping Process 
 • Sau khi chọn công cụ và hình thành nhóm, có bắt đầu qui trình 
 bản mẫu nhanh 
 • Phân tích hệ thống đề nghị - Trước tiên, nhận diện thị trường 
 và kế hoạch nhu cầu khách hàng và xác định những gì công ty 
 phát triển phẩn đạt đến nhu cầu lợi nhuận 
 • Nhận diện những yêu cầu khởi động của khách hàng – Tìm 
 hiểu thị trường & kế hoạch nhận diện yêu cầu tổng thể cho sản 
 phẩm 
 20 
UIT-VNUHCM 2009 
 2-Rapid Prototyping Process 
  Tại sao: 
 21 
UIT-VNUHCM 2009 
 2-Rapid Prototyping Process 
 Disadvantages 
 22 
UIT-VNUHCM 2009 
 2-Rapid Prototyping Process 
 23 
UIT-VNUHCM 2009 
 2-Rapid Prototyping Process 
 24 
UIT-VNUHCM 2009 
 2-Rapid Prototyping Process 
 • Cải tiến code thực sự - Dựa trên phản hồi khách hàng, người 
 lập trình viết lại code làm cho sản phẩm dễ học và sử dụng 
 • Lặp – Lặp lại “code thật sự- phản hồi – cải tiến code” nhanh và 
 liên tục có thể. Nhớ, phần mềm tốt là dễ dùng và khó để thiết 
 kế 
 • Phiên bản sản phẩm – Cuối cùng, khi khách hàng hài lòng với 
 giao diện người dùng thực sự, phiên bản mới cho sản phầm 
 25 
UIT-VNUHCM 2009 
 3-Incremental development advantages 
 Customer value can be delivered with each 
 increment so system functionality is available earlier. 
Early increments act as a prototype to help elicit 
 requirements for later increments. 
Lower risk of overall project failure. 
The highest priority system services tend to receive 
 the most testing. 
 26 
UIT-VNUHCM 2009 
 MÔ HÌNH PHÁT TRIỂN TĂNG TRƯỞNG 
 Sy s t e m /i n f or ma t i on Bản tăng 1 
 e ng i n ee ri n g 
 a n a ly s i s d e s ig n c o d e t e s t Chuyền giao 
 bản tăng 1 
 Chuyền giao 
 Bản tăng 2 a n a ly s i s d e s ig n c o d e t e s t 
 bản tăng 2 
 Chuyền giao 
 Bản tăng 3 a n a ly s i s d e s ig n c o d e t e s t 
 bản tăng 3 
 Bản tăng 4 a n a ly s i s d e s ig n c o d e t e s t Chuyền giao 
 bản tăng 4 
 Thêi gian 
 27 
UIT-VNUHCM 2009 
HOẠT ĐỘNG PHÁT TRIỂN TĂNG TRƯỞNG 
Xác định yêu cầu Gán yêu cầu cho Thiết kế 
 tổng thể các bản tăng kiến trúc 
 Phát triển Tích hợp Kiểm thử Hệ thống 
 bản tăng bản tăng hệ thống cuối cùng 
 Hệ thống chưa hoàn thành 
 28 
UIT-VNUHCM 2009 
 4-Extreme Programming (XP) 
Là một điển hình qui trình Agile 
Phù hợp với môi trường: 
 o Nhóm nhỏ 
 o Yêu cầu thay đổi nhanh 
 Một số nguyên lý XP đặc nền tảng trên: 
 o Small Releases – Phần mềm đã phát triển trong những giai đoạn 
 đã được cập nhật thường xuyên 
 o Simple Design – Hiện thực code cần đạt kết quả khách hàng 
 mong đợi khôg nhấn mạnh đến version tương lai 
 o Testing – Hoàn tất qua toàn bộ qui trình phát triển. Kiểm thử là 
 thiết kế đầu tiên trước khi viết phần mềm 
 29 
UIT-VNUHCM 2009 
5-Component-based software engineering 
 Dựa vào tái dụng có hệ thống khi những hệ thống 
 này được tích hợp từ cấu phần có sẵn hay COTS 
 (Commercial-off-the-shelf) systems. 
 Các giai đoan qui trình 
 o Phân tích thành phần (Component) 
 o Cập nhật yêu cầu 
 o Thiết kế hệ thống với tái sự dụng 
 o Phát triển và tích hợp. 
 Tiếp cận này ngày càng tăng được dùng khi tiêu 
 chuẩn cấu phần hợp trội. 
 30 
UIT-VNUHCM 2009 
6-Mô hình đồng bộ hoá và ổn định 
(Synchronize-and-stabilize) model 
 Microsoft’s life-cycle model 
 Phân tích yêu cầu – phỏng vấn khách hàng tiềm 
 năng 
  Viết đặc tả 
 Phân chia project (dự án) thành 3-4 builds 
 Mỗi build thực hiện bởi nhóm nhỏ làm việc song 
 song 
 Cuối mỗi ngày –synchronize (test và debug 
 Cuối mỗi build – stablize (freeze the build) 
 Thành phần luôn làm việc cùng nhau: sớm tham 
 gia quá trình vận hành sản phẩm 
 31 
UIT-VNUHCM 2009 
 Water fall + Phân tích Rủi ro 
  Water Fall + 
 phân tích rủi ro 
 trước mỗi giai 
 đoạn 
  Trước khi vào 
 giai đoạn cố 
 gắng kiểm soát 
 rủi ro 
 32 
UIT-VNUHCM 2009 
7-Object-oriented life-cycle models 
  Fountain Model 
 . by Henderson-Sellers 
 and Edward, 
 Communications of the 
 ACM, Sept. 1990 
 . Vòng tròn thể hiện giai 
 đoạn khác trùng lắp 
 . Mũi tên thể hiện bước 
 lặp của mỗi giai đoạn 
 . Vòng tròn bảo trì nhỏ 
 hơn, để biể trưng giảm 
 nỗ lực bảo trì khi thành 
 phần hướng đối tượng 
 được sử dụng 
 33 
 UIT-VNUHCM 2009 
 Các tiếp cận để phát triển phần mềm 
  Traditional systems development life cycle 
  Prototyping 
  Packaged software 
  End-user development 
  Outsourcing 
  Open source 
 Thảo luận Thuận lợi và Bất lợi các tiếp cận trên 
 34 
UIT-VNUHCM 2009 
 Traditional systems development life cycle 
 35 
UIT-VNUHCM 2009 
 Prototyping 
 36 
UIT-VNUHCM 2009 
 Packaged software 
 37 
UIT-VNUHCM 2009 
 End-User Development 
 38 
UIT-VNUHCM 2009 
 Open-source 
 39 
UIT-VNUHCM 2009 
 Điểm mạnh & yếu Life-Cycle Model 
 40 
UIT-VNUHCM 2009 
 Tổng kết life cycle’s model 
 Mỗi life-cycle model khác nhau có thế mạnh và 
 điểm yếu 
 Điều kiện để quyết định chọn model bao gồm: 
 o Tổ chức 
 o Cách quản lý của tổ chức 
 o Kỹ năng của nhân viên 
 o Bản chất của sản phẩm 
 Giải pháp tốt nhất: 
 o “Mix-and-match” life cycle model 
 o Nhưng, phải lên kế hoạch 
 41 
UIT-VNUHCM 2009 
 Maintenance Process (extended to real life) 
  Processing requests before starting to work on them, 
 like: 
  Capturing maintenance requests 
  Investigating those requests – like testing to verify a bug and 
 decide how hard to fix it 
  Deciding the time / cost to do, getting customer ok 
  Prioritizing requests – versus other requests! 
  Assigning to a sub-team to do 
  Coding and documenting (as per standards) 
  Testing with various configurations, other legacy code 
 issues 
  Deciding to send it out (special, or in which sub-release) 
 42 
UIT-VNUHCM 2009 
 Ngữ cảnh người bảo trì phần mềm 
1: Customers & Users 2:Operation Department 3: Developers 4: Suppliers 
5: Help Desk 
 43 
UIT-VNUHCM 2009 
 Một ví dụ  
  Chú ý đến số lượng “pre-
 fixing” và những hoạt động 
 truyền thông khác! 
 From 
 .com/CustomerSupport/mainte
 nance_process.asp. 
 44 
UIT-VNUHCM 2009 
 Ví dụ khác  
 Như trên 
 From  
 45 
UIT-VNUHCM 2009 
Phân lớp qui trình then chốt (KEY) bảo trì phần mềm 
 46 
 UIT-VNUHCM 2009 
Basic Strategies for Software Enhancement 
(one more review topic) 
  New versions coming out at regular intervals 
  Ongoing (technical) support – between or instead of releases 
 47 
UIT-VNUHCM 2009 
 3.2 CÁC MÔ HÌNH BẢO TRÌ PHẦN MỀM 
 Mô hình Quick-Fix 
 Mô hình Boehm 
 Mô hình Osborne 
 Iterative Enhancement Model 
 Mô hình hướng sử dụng lại (Reuse-Oriented) 
 48 
UIT-VNUHCM 2009 
 Quick-Fix Model 
 Thuận lợi 
 o Nhanh 
 o Có thể hữu ích cho dự án nhỏ 
 Không thuận lợi 
 o Nhỏ hay không sưu liệu 
 o Bất kỳ thiết kế trở nên ít hiệu 
 quả vượt quá thời gian 
 It is a 'firefighting' approach, chờ cho vấn đề xảy 
 ra và sau đó cố gắng fix nó nhanh như có thể 
 Việc sửa lỗi có thể được hoàn tất mà không có 
 phân tích chi tiết những tác động về lâu dài 
 Tại sao nó vẫn được sử dụng? 
UIT-VNUHCM 2009 49 
 Quick-fix model 
 Trong môi trường phù hợp nó có thể làm việc hiệu 
 quả 
 Ví dụ: 
 o Một hệ thống được phát triển và bảo trì bởi 1 người. 
 Người này có thể hiểu hệ thống đủ để quản lý mà không 
 cần sưu liệu 
 o Áp lực về hạn cuối và nguồn lực 
  chiến lược để thích ứng là gắn kết kỹ thuật quick-
 fix với kỹ thuật khác 
 50 
UIT-VNUHCM 2009 
 Boehm’s model 
  Thuận lợi 
 o Qui trình được kiểm soát 
 o Nhấn mạnh vào phản hồi 
  Không thuận lợi 
 o Thấp hơn quick-fix 
  Dựa trên mô hình kinh tế 
 và nguyên tắc. 
  Qui trình bảo trì dẫn xuất 
 từ quyết định của người 
 quản lý dựa trên cân bằng 
 mục tiêu và ràng buộc 
 51 
UIT-VNUHCM 2009 
 Osborne’s 
  Thuận lợi 
 o Liên quan đến tất cả 
 giai đoạn chu trình sống 
 o Sưu liệu được cập nhật 
  Không thuận lợi 
 o Phức tạp 
 o Nhiều công sức chi phí 
 đối phó trực tiếp với thực 
 tế của môi trường bảo trì. 
 Mô hình khác hướng đến 
 giả định khía cạnh của 
 tình hướng lý tưởng 
 Mô hình bảo trì được xử 
 lý như lặp tiếp diễn của 
 vòng đời phần mềm 
 52 
 UIT-VNUHCM 2009 
 Iterative Enhancement Model 
  Thuận lợi 
 o Khá đơn giản 
 o Cho phép phân tích 
  Không thuận lợi 
 o Những quyết định bao gồm không rõ 
 ràng 
 o Appears informally to be on a tilt! 
  Thực hiện thay đổi đối với hệ thống phần 
 mềm qua thời gian sống của nó là qui 
 trình lặp và liên quan đến cải thiện hệ 
 thống theo bước lặp. 
 53 
UIT-VNUHCM 2009 
 Reuse Model 
 Thuận lợi 
 o Có thể dùng các thành 
 phần từ các dự án khác 
 o Code is modular 
 Không thuận lợi 
 o Overhead in designing for 
 reuse 
 Nhận diện phần của hệ thống cũ là những ứng viên 
 có thể tái sử dụng, 
  Hiểu phần hệ thống này, 
  Thay đổi phần hệ thống cũ phù hợp với yêu cầu, 
 Tích hợp những phần được thay đổi vào trong hệ 
 thống mới. 
 UIT-VNUHCM 2009 54 
 Reuse-oriented development 
 55 
UIT-VNUHCM 2009 
 3.3 KHI THỰC HiỆN THAY ĐỔI 
 Tăng trưởng qui trình 
 Mô hình tăng trưởng CMM (Capability Maturity 
 Model) cho phần mềm 
 Cơ sở kinh nghiệm phần mềm 
 56 
UIT-VNUHCM 2009 
 So sánh nỗ lực bảo trì & phát triển 
 57 
UIT-VNUHCM 2009 
 QUI TRÌNH – Cải tiến nâng cao chất lượng 
  Quy trình khung là cơ sở để cải tiến tiến trình nâng cao 
 chất lượng, năng suất 
  Quy trình khung phổ biến (Các chuẩn) 
  ISO 
  CMM (Capability Maturity Model) 
  CMMI (Capability Maturity Model Integration): 5 
 level 
  Initial (chaotic, ad hoc, heroic) the starting point for use of a new 
 process. 
  Repeatable (project management, process discipline) the process is 
 used repeatedly. 
  Defined (institutionalized) the process is defined/confirmed as a 
 standard business process. 
  Managed (quantified) process management and measurement takes 
 place. 
  Optimising (process improvement) process management includes 
 deliberate process optimization/improvement. 
 58 
UIT-VNUHCM 2009 
 Cơ sở tri thức kinh nghiệm 
 Tri thức được hình thành từ hướng dẫn 
 (guidleline),mô hình hay thể hiện rõ ràng kỹ năng 
 nhân sự. 
 Tổ chức tạo ra hệ thống để hỗ trợ và chia sẽ kinh 
 nghiệm. 4 yếu tổ đòi hỏi thực thi thành công cơ sở 
 tri thức kinh nghiệm: 
 o Thay đổi văn hoá 
 o Tính ổn định 
 o Giá tri nghiệp vụ (business value) 
 o Thực thi tăng cường 
 59 
UIT-VNUHCM 2009 
 Các khía cạnh cơ bản của bảo trì – kiến thức  
Các khía cạnh cơ bản của kỹ sư bảo trì khi thực hiện thay đổi, va tri thức hỗ trợ trong bảo trì 
 60 
 UIT-VNUHCM 2009 
 Vận dụng Công cụ KM Agent hỗ trợ Bảo trì 
 61 
UIT-VNUHCM 2009 
 Vấn đề tham dự trong quá trình bảo trì ? 
  Hiểu hệ thống hiện hành 
 o Hệ thống thực sự làm được gì? 
 o Ở đâu cần thay đổi? 
 o Các phần của phần mềm liên quan với nhau như thế nào? 
  Thực thi sự thay đổi 
  Kiểm thử 
  Nhận diện nhu cầu thay đổi 
  Thảo luận 
 o Hiểu chương trình ? 
 o Tác động thay đổi? 
 o Kiểm thử ? 
 o Vấn đề Quản lý? 
 62 
UIT-VNUHCM 2009 
 Bài tập & thảo luận 
Exercise 5.6: Bạn thực hiện gì ở dự án phần mềm 
 vừa qua? Đó là dự án thương mại & dự án cấp đại 
 học hay dự án nhân sự. Hãy viết đánh giá mô hình 
 chu trình sống mà bạn đã làm. Nó có đảm bảo có cấu 
 trúc hay không dự định. Bạn có thực hiện mô hình 
 khác nếu như bạn bắt đầu dự án này một lần nữa 
Exercise 5.7: Bạn là IT manager phải có trách nhiệm 
 với hệ thống thư viện lớn bị lỗi không mong đợi vào 
 sáng thứ hai. Bạn đã trải qua các bước để thực hiện 
 nó như thế nào: 
 o 1. Nó cấp bách phải mất 2 giờ để thực hiện 
 o 2. Nếu thư viện có chức năng tương đương cho vài ngày mà 
 không có hệ thống phần mềm 
 63 
UIT-VNUHCM 2009 
 Yêu cầu thực hiện tuần tiếp theo 
Viết lại các báo cáo cho các thảo luận trên lớp 
Bài tập 1: Tìm hiểu qui trình nâng cao đảm bảo chất 
 lượng (slide 58) 
Bài tập 2: Tìm hiểu Knowledge Management Agent hỗ 
 trợ qui trình bảo trì (software maintenance process) 
Deadline tối hôm trước của buổi học kế tiếp 
Chuẩn bị báo cáo khả thi cho đồ án của nhóm, kết 
 hợp thảo luận với nhóm khách hàng. Sẽ dành thời 
 gian cho các nhóm luân phiên lên trình bày với các 
 khách hàng thứ  (Trên lớp) 
 64 
UIT-VNUHCM 2009