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

Chu trình sống của dự án phần mềm • Chu trình sống của dự án phần mềm Software project life cycle: Toàn bộ khung làm việc mà trong đó phần mềm được hình thành, phát triển và duy trì Sof

CHƯƠNG 3: CHU TRÌNH SỐNG CỦA MỘT DỰ ÁN PHẦN MỀM

CHƯƠNG 3: CHU TRÌNH SỐNG CỦA MỘT DỰ ÁN PHẦN MỀM

Quản lý dự án phần mềm

• Quản lý dự án phần mềm: Đảm bảo dự án tạo

ra sản phẩm phần mềm được thực hiện theo đúng kế hoạch.

–Quản lý dự án phần mềm là quá trình lập kế hoạch, tổ chức đội dự án, giám sát, kiểm soát

–Mỗi dự án phần mềm phải có người quản lý, nhà cung cấp và quản lý cấp cao

–Quản lý dự án tốt không thể đảm bảo thành công, nhưng quản lý kém luôn luôn dẫn đến thất bại

Quản lý dự án phần mềm

• Dự án phần mềm có hai hướng hoạt động:

–Phát triển phần mềm: tập trung vào việc phân tích, thiết kế, lập trình và kiểm thử

–Hướng quản trị dự án: thực hiện các công việc lên kế hoạch, phân phối tài nguyên, giám sát và điều chỉnh công việc để đạt được mục tiêu, chi phí, thời gian và chất lượng

Chu trình sống của dự án phần mềm

• Chu trình sống của dự án phần mềm (Software project life cycle): Toàn bộ khung làm việc mà trong đó phần mềm được hình thành, phát triển

và duy trì (Software Development Life SDLC)

Cycle-• Chu trình sống thường liên quan đến các mô hình và các giai đoạn phát triển phần mềm.

Chu trình sống của dự án phần mềm

• Chu trình sống của phần mềm gồm các giai đoạn:

–Thường được chia thành 2 giai đoạn con:

• Giai đoạn thiết kế sơ bộ: Kiến trúc phần mềm ban đầu được phát triển.

• Giai đoạn thiết kế chi tiết: mô hì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

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)

• Đâ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à tuầ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)

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)

Mô hình tăng trưởng ( Incremental model)

–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

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)

• „RAD là sự ráp nối tốc độ cao của mô hình thá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 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)

–„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

–„Ngườ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)

• 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)

• Ư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)

Mô hình bản mẫu (Prototype model)

–Phù hợp với những hệ thống

• User-interface intensive systems

• Interactive online systems

• „First-of-a-kind products

• „Decision 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ỗ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:

–Khó 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