Bài giảng Quản lý dự án - Chương 3: Chu trình sống của một dự án phần mềm

nh chức năng được xác định cùng với giao diện người dùng và giao diện giữa các moules. 
Chu trình sống của dự án phần mềm 
Giai đoạn hiện thực (Implementation phase): 
Lập trình để thực thi việc thiết kế phần mềm. 
Giai đoạn kiểm định (Testing phase): 
Phần mềm được kiểm định về chức năng và mức độ thỏa mãn các yêu cầu. 
Thông thường được chia làm 3 giai đoạn: 
Kiểm định đơn vị (Unit Testing) 
Kiểm định kết hợp (Integration Testing) 
Kiểm định khả năng chấp nhận (Acceptance Testing). 
Hai giai đoạn Unit testing và Integration testing có thể là bộ phận của chu trình lặp coding và testing 
Chu trình sống của dự án phần mềm 
Giai đoạn triển khai (Deployment Phase): 
Phần mềm được cài đặt trong hệ thống theo dự kiến, và huấn luyện người dùng. 
Đây là giai đoạn phần mềm được phát triển và xem xét một cách hoàn chỉnh. 
Giai đoạn bảo trì (Maintenance Phase): 
Sửa lỗi và hiệu chỉnh hoặc cập nhật phần mềm cung cấp thêm một số chức năng. 
Chi phí của giai đoạn này nhiều hơn so với giai đoạn phát triển ban đầu. 
Chu trình sống của dự án phần mềm 
Giai đoạn bảo trì phần mềm cần phải xem lại mã của phầm mềm gốc để hiểu những gì đã được làm trước đó và tạo ra những thay đổi cho những module được chỉ định. 
Các mô hình của chu trình sống 
Có nhiều mô hình chu trình sống, h ầu hết đều là những sự biến đổi của ba mô hình phát triển phần mềm cổ điển . 
Mô hình thác nước (Waterfall) 
Mô hình tăng trưởng (Incremental) 
Mô hình tăng trưởng 
Mô hình RAD (Rapid Application Development) 
Mô hình tiến hóa (Evolutionary Process) 
Mô hình bản mẫu (Prototyping models) 
Mô hình xoắn ốc (Spiral models ) 
Mô hình thác nước (Waterfall ) 
Mô hình thác nước (Waterfall) 
Gồm các giai đoạn: 
Xác định yêu cầu 
Thiết kế 
Xây dựng (hay "triển khai", "mã hóa", "viết mã") 
Liên kết 
Kiểm thử và Chỉnh sửa (hay «kiểm nghiệm») 
Cài đặt 
Bảo trì 
Mô hình thác nước (Waterfall) 
Đây là mô hình cũ nhất nhưng ngày nay vẫn được sử dụng rộng rãi trong việc phát triển các ứng dụng. 
Mô hình bao gồm một dãy các giai đoạn, mỗi giai đoạn phải được hoàn tất trước khi bắt đầu giai đoạn kế tiếp. 
Những giai đoạn được xem là t uần tự, với sự phản hồi chỉ được xác định trong thời gian chuyển tiếp giữa các giai đoạn. 
Mô hình thác nước (Waterfall) 
Những trở ngại hoặc những hiệu chỉnh thường chờ đến giai đoạn bảo trì. Điều này có thể sẽ rất tốn kém . 
Mô hình thác nước (Waterfall) 
Thuận lợi: 
Hệ thống được ghi chép cẩn thận 
Các giai đoạn tương ứng với các giai đoạn trong quản lý dự án. 
Chi phí và những ước lượng chương trình có thể thấp hơn và chính xác hơn . 
Những chi tiết có thể quan tâm với nhiều nỗ lực kỹ thuật hơn nếu phần mềm lớn hay phức tạp. 
Mô hình thác nước (Waterfall) 
Hạn chế: 
Quá trình xây dựng phần mềm được chia thành các pha độc lập tạo nên nhiều khó khăn khi có thay đổi về yêu cầu từ khách hàng. 
Do chỉ tiếp xúc với khách hàng trong giai đoạn đầu tiên nên phần mềm khó đáp ứng tất cả nhu cầu của khách hàng. 
Mô hình chỉ thích hợp khi các yêu cầu phần mềm được rõ ràng và không bị thay đổi ( hoặc chỉ giới hạn ở pha thiết kế) 
Mô hình thác nước (Waterfall) 
Việc quay lui để chỉnh sửa hoặc thay đổi một công việc đã hoàn tất rất tốn thời gian và chi phí. 
Khả năng thất bại cao. 
Ứng dụng 
Mô hình này chỉ thích hợp với những dự án đã biết rõ yêu cầu của khách hàng. 
Mô hình tăng trưởng ( Incremental model) 
Thực chất là một loạt của những chu trình thác nước. 
Mô hình tăng trưởng ( Incremental model) 
Một dãy các chu trình con, sau mỗi chu trình con có thể chuyển giao cho khách hàng 
Mô hình tăng trưởng ( Incremental model) 
Những yêu cầu của phần mềm được biết tại giai đoạn bắt đầu của dự án và được chia ra những nhóm cho sự phát triển mô hình gia tăng . 
Vòng đầu tạo sản phẩm lõi 
Các vòng sau bổ sung dần chức năng 
Mô hình tăng trưởng ( Incremental model) 
Thuận lợi: 
Cung cấp các phản hồi, cho phép những chu kỳ phát triển sau rút ra bài học từ những chu trình trước đ ó. 
Các yêu cầu của phần mềm tương đối ổn định và và hoàn chỉnh hơn trong mỗi giai đoạn sau. 
Cho phép hiệu chỉnh các yêu cầu và cho phép thêm những yêu cầu mới. 
Mô hình này đáp ứng yêu cầu người dùng tốt hơn mô hình thác nước. 
Chức năng chính, chức năng có độ rũi ro cao sẽ được thực hiện trước 
Sau mỗi vòng đều có thể chuyển giao cho khách hàng 
Giảm rũi ro cho thất bại toàn dự án 
Mô hình tăng trưởng ( Incremental model) 
Bất lợi: 
Phần lớn những yêu cầu phải được biết trong thời điểm bắt đầu. 
Phải xác định chức năng đầy đủ và hoàn chỉnh trước khi qua vòng sau. 
Dự án có thể được dừng lại bất kỳ thời gian nào sau chu trình đầu tiên . 
Rủi ro có thể xảy ra ở các chu trình con. 
Những tổng quan h ình thức có thể khó hiện thực trên những phiên bản gia tăng hơn trên một hệ thống đầy đủ. 
Mô hình tăng trưởng ( Incremental model) 
S ự phát triển phần mềm trải qua nhiều giai đoạn lặp đi lặp lại, nhưng giao diện giữa những module phải được định nghĩa kỹ trong giai đoạn đầu . 
Những thao tác được tác động m ỗi khi phiên bản mới được triển khai . 
Những người sử dụng được yêu cầu học cách sử dụng khi một hệ thống mới được triển khai . 
Mô hình tăng trưởng ( Incremental model) 
Ứng dụng: 
Mô hình này thường được thực hiện với những dự án có số người ít hơn so với mô hình thác nước 
Kiểm thử có thể thực hiện dễ dàng trên những phần nhỏ của hệ thống. 
Khi cần nhanh chóng đưa ra chức năng cơ bản của hệ thống. 
Áp dụng cho sản phẩm có thời gian hoàn thiện > 1 năm. 
Khi các yêu cầu đã hiểu rõ nhưng mong muốn có sự tiến hóa dần của sản phẩm 
Mô hình RAD ( Rapid Application Development ) 
Mô hình này được đưa ra bởi IBM vào những năm 1980 , qua sách của James Martin . 
RAD là một mô hình quy trình phần mềm gia tăng mà nhấn mạnh tới chu kỳ phát triển ngắn (60-90 ngày) 
„ R AD là sự ráp nối tốc độ cao của mô hình t hác nước, xây dựng dựa vào thành phần và sử dụng các ứng dụng tạo mã tự động 
Mô hình RAD ( Rapid Application Development ) 
Xây dựng dựa trên hướng thành phần ( Component-based ) với khả năng tái sử dụng. 
Gồm một số nhóm (teams), mỗi nhóm làm 1 RAD theo các pha 
Mô hình nghiệp vụ 
Mô hình dữ liệu 
Mô hình xử lý 
Tạo ứng dụng 
Kiểm thử và đánh giá 
Mô hình RAD ( Rapid Application Development ) 
Mô hình RAD ( Rapid Application Development ) 
Ưu điểm: 
Thời gian phát triển giảm nhờ dùng công cụ 
„Chỉ cần ít người phát triển hơn, do họ thân thiện với vấn đề 
„Nhanh chóng cho phép hình dung ra sản phẩm 
Dùng hiệu quả các framework và công cụ đóng gói ( off-the-shelf tools and frameworks) 
„Giảm rủi ro nhờ có sự tham gia của khách hàng . 
Mô hình RAD ( Rapid Application Development ) 
Nhược điểm: 
Thiếu sự tham gia tốt của người dùng trong chu kỳ sống của phần mềm 
„Người phát triển phải có kỹ năng và được huấn luyện tốt cho việc sử dụng công cụ và thời gian phát triển nhanh 
„Hệ thống có khả năng phân tách module 
„Cần có đáp ứng về thành phần sử dụng lại 
„Người phát triển và khách hàng phải nỗ lực 
„ N gười quản lý phải làm việc tận tụy với nhóm phát triển và khách hàng để nhanh chóng đạt được các thỏa thuận 
Mô hình RAD ( Rapid Application Development ) 
Ứng dụng: Mô hình áp dụng cho những trường hợp: 
„ H ệ thống dễ dàng phân chia module và có thể mở rộng 
„Hệ thống mà những yêu cầu được biết rõ và hợp lý 
„Người dùng có thể tham gia tốt qua toàn bộ chu kỳ sống của phần mềm. 
„Dự án có thời gian phát triển ngắn, dưới 60 ngày 
„Những thành phần sử dụng lại có sẵn trong kho phần mềm . 
Mô hình tiến hóa (Evolution model) 
Mô hình tiến hóa được đưa ra nhằm giải quyết những khó khăn gây ra do yêu cầu của khách hàng không rõ ràng hoặc hay thay đổi. 
Ý tưởng của mô hình này là phát triển phần mềm qua nhiều phiên bản, mỗi phiên bản được đưa ra lấy ý kiến khách hàng, được sửa chữa, làm mịn cho đến khi đạt được phiên bản hoàn chỉnh. 
Mô hình tiến hóa (Evolution model) 
Sơ đồ mô hình tiến hóa 
Mô hình tiến hóa (Evolution model) 
Những hoạt động đ ặc tả yêu cầu , phát triển và kiểm tra đ ược thực hiện đồng thời, với sự phản hồi nhanh . 
Mô hình tiến hóa tin cậy vào sự phản hồi người sử dụng sau khi mỗi sự thi hành để tinh lọc những yêu cầu cho bước tiến hóa tiếp theo . 
Mô hình này được phát triển với mục tiêu là giảm rủi ro trong chu trình phát triển phần mềm . 
Mô hình tiến hóa (Evolution model) 
Hai kiểu mô hình tiến hóa cơ bản là: 
Khám phá và phát triển (exploratory development): 
Đội dự án sẽ làm việc cùng khách hàng để khám phá các yêu cầu của họ. 
Dự án sẽ bắt đầu trước tiên với những yêu cầu đã rõ ràng . 
Các đặc tính khác sẽ được thêm vào dần dần dựa trên đề nghị của khách hàng. 
Làm bản mẫu (throwaway prototyping): 
Mô hình này được áp dụng cho giai đoạn phân tích yêu cầu . 
Đ ội dự án sẽ làm các bản mẫu (prototype) để lấy ý kiến khách hàng nhằm kiểm chứng và làm rõ các yêu cầu chưa rõ ràng. 
Khi đã có một bản yêu cầu hoàn chỉnh, giai đoạn phát triển tiếp theo có thể sử dụng mô hình thác nước. 
Mô hình tiến hóa (Evolution model) 
Ưu điểm: 
Chú trọng việc tái sử dụng mẫu. Một phần của hệ thống có thể được phát triển ngay trong các giai đoạn phân tích phát triển yêu cầu và thiết kế. 
Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ của dự án, nhờ đó sản phẩm cuối cùng thường phản ánh chính xác mong muốn của khách hàng. 
Mô hình tiến hóa (Evolution model) 
Nhược điểm: 
Mô hình này cho phép khách hàng tham gia sâu hơn vào quá trình phát triển nên có các nhược điểm là : 
Khó khăn trong việc thiết kế: việc phát triển qua nhiều phiên bản có thể phá vỡ kiến trúc tổng thể của phần mềm. 
Khó khăn trong việc quản lý: các nhà quản lý thích nhìn thấy sản phẩm làm ra trong từng giai đoạn để tiện cho việc quản lý tiến độ. Ngoài ra các tài liệu mô tả cho từng phiên bản thường không được lập đầy đủ 	 
Khó khăn do khách hàng gây ra: Khách hàng có thể nhầm tưởng rằng một bản mẫu có thể tốt gần như sản phẩm thật. Trong thực tế từ bản mẫu đến sản phẩm cuối cùng là một khảng cách xa. Ngoài ra khách hàng có xu hướng đưa thêm vào những yêu cầu không cần thiết. 
	Thường thì với mô hình này, tính chặt chẽ, minh bạch của qui trình kém. 
Mô hình tiến hóa (Evolution model) 
Ứng dụng: 
Mô hình tiến hóa thường được áp dụng trong những dự án có độ rủi ro cao. 
Mô hình tiến hóa được xem xét với những hệ thống mà chưa xác định hết tất cả các yêu cầu nhưng mong muốn được tiến triển, nó thường áp dụng cho những hệ thống mới hơn là cập nhật những hệ thống đang tồn tại . 
Được dùng để phát triển các loại phần mềm tương đối nhỏ (dưới 500 000 dòng code ), có vòng đời tương đối ngắn 
Đội ngũ phát triển không quen thuộc với lĩnh vực của dự án. 
Mô hình tiến hóa (Evolution model) 
Các dự án lớn và phức tạp nên sử dựng một mô hình kết hợp giữa mô hình thác nước và tiến hóa. Trong đó, các bản mẫu được dùng để làm rõ các yêu cầu của khách hàng. Các yêu cầu đã rõ ràng được tiếp tục phát triển theo mô hình thác nước. Các yêu cầu chưa rõ ràng có thể sử dụng mô hình khám phá và phát triển. 
Mô hình bản mẫu (Prototype model ) 
Mô hình bản mẫu dựa trên ý tưởng xây dựng một mẫu thử ban đầu ( Prototype – nguyên mẫu) và đưa cho người sử dụng xem xét; sau đó , tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thỏa mãn yêu cầu của người sử dụng thì dừng lại. 
Mẫu thử ban đầu như là một cơ chế để nhận diện chính xác yêu cầu của khách hàng (Throwaway Prototyping ) 
Mô hình bản mẫu (Prototype model ) 
Mẫu thử ban đầu có thể trở thành sản phẩm. Khi các yêu cầu của người sử dụng được thỏa mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống (Evolutionary Prototyping) 
Mẫu thử ban đầu có thể loại bỏ, mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng. 
Mô hình bản mẫu (Prototype model ) 
Mô hình bản mẫu (Prototype model ) 
Mô hình bản mẫu (Prototype model) 
Ưu điểm: 
Khách hàng tương tác sớm với hệ thống 
„Khách hàng và người phát triển làm việc với nhau 
Người phát triển có thể xác định chính xác được yêu cầu , phát hiện những yêu cầu mới . 
Mô hình cho phép thiết kế và phát triển mếm dẽo qua nhiều vòng lặp 
Mô hình bản mẫu (Prototype model ) 
Nhược điểm: 
Là phương pháp Quick-and-dirty . Những nguyên mẫu Quick-and-dirty thường gây ra khó khăn trong việc thiếu tư liệu hay tư liệu không phù hợp . 
Hệ thống được xây dựng có thể mang cấu trúc một cách nghèo nàn với những lựa không tốt. Hệ thống sẽ có chất lượng thấp và khó bảo trì sau một thời gian dài . 
„Khách hàng hối thúc nhà phát triển hoàn thành sản phẩm một khi thấy được các prototype đầu tiên„ 
Người phát triển có thể rơi vào chu kỳ code-and-fix 
Mô hình bản mẫu (Prototype model) 
Ứng dụng: 
Khi yêu cầu không được biết rõ, không ổn định , thông tin không đáp ứng tốt cho việc phân tích dự án. 
„Một vài phần của hệ thống lớn có thể được tạo theo mô hình bản mẫu 
Khi người phát triển không chắc chắn việc dùng giải thuật hay kiến trúc là tối ưu 
„Trên những hệ thống dựa vào phần mềm kỹ thuật cao mà những yêu cầu không được xác định rõ 
Mô hình bản mẫu (Prototype model) 
Phù hợp với những hệ thống 
U ser-interface intensive systems 
I nteractive online systems 
„ F irst-of-a-kind products 
„ D ecision support systems 
Mô hình xoắn ốc (Spiral model) 
Mô hình xoắn ốc được Boehm đưa ra năm 1988. Mô hình này đưa thêm vào việc phân tích yếu tố rủi ro. 
Quá trình phát triển được chia thành nhiều bước lặp lại, mỗi bước bắt đầu bằng việc phân tích rủi ro rồi tạo bản mẫu, cải tạo và phát triển bản mẫu, duyệt lại, và cứ thế tiếp tục 
Mô hình xoắn ốc (Spiral model) 
Mô hình xoắn ốc (Spiral model) 
Mỗi chu trình có 4 phạm vi hoạt động: 
Xác định mục tiêu, ràng buộc và các chọn lựa. 
 Uớc lượng các chọn lựa, xác định rũi ro và giải pháp . 
Phát triển sản phẩm ở mức tiếp theo. 
Lập kế hoạch cho giai đoạn tiếp theo. 
Với mỗi lần lặp xoắn ốc (bắt đầu từ tâm), các phiên bản được hoàn thiện dần. 
Tại một vòng xoắn ốc, phân tích rủi ro phải đi đến quyết định “tiến hành tiếp hay dừng”. Nếu rủi ro quá lớn thì có thể đình chỉ dự án. 
Mô hình xoắn ốc (Spiral model) 
Thuận lợi: 
Quản lý rủi ro tốt hơn các mô hình khác 
Các yêu cầu phần mềm được xác định chính xác hơn 
Hệ thống đáp ứng tốt hơn yêu cầu của khách hàng 
Nhược điểm: 
K hó thuyết phục những khách hàng lớn rằng cách tiếp cận tiến hóa là kiểm soát được. 
Nó đòi hỏi tri thức chuyên gia đánh giá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạt được thành công. 
Mô hình xoắn ốc (Spiral model) 
Mô hình xoắn ốc đòi hỏi năng lực quản lý cao, nếu không quản lý tốt thì rất dễ rơi vào trạng thái sửa đổi cục bộ không có kế hoạch của mô hình làm bản mẫu 
M ô hình này còn tương đối mới và còn chưa được sử dụng rộng rãi. 
Cần phải có thêm một số năm nữa trước kh ingười ta có thể xác định được tính hiệu quả của mô hình này với sự chắc chắn hoàn toàn . 
Chi phí cho cách tiếp cận này thường là cao 
Mô hình xoắn ốc (Spiral model) 
Ứng dụng: 
Mô hình xoắn ốc được áp dụng cho những dự án có độ rủi ro cao, các yêu cầu của phần mềm cần được xác định trước và yêu cầu của khách hàng là rất quan trọng.