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
Dự án phần mềm
Dự án phần mềm là một loại dự án tập trung đặc biệt vào việc tạo ra hoặc cập nhật phần mềm.
Sản phẩm của dự án phần mềm có thể được thực thi, kiểm thử và chỉnh sửa.
Phải có tài liệu hướng dẫn cho người dùng và bảo trì.
Thuộc tính phân biệt so với dự án kỹ thuật
Sản phẩm là vô hình
Người làm không có nhiều kinh nghiệm về lĩnh vực chuyên môn
Dự án phần mềm lớn thường là sản phẩm đặt trước
Kỹ thuật thay đổi rất nhanh
Trang 1
Trang 2
Trang 3
Trang 4
Trang 5
Trang 6
Trang 7
Trang 8
Trang 9
Trang 10
Tải về để xem bản đầy đủ
Bạn đang xem 10 trang mẫu của tài liệu "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", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
Tóm tắt nội dung tài liệu: 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.
File đính kèm:
- bai_giang_quan_ly_du_an_chuong_3_chu_trinh_song_cua_mot_du_a.pptx