Quy trình phát triển phần mềmCác hoạt động và các bước Các yêu cầu · Chi tiết hóa Kiến trúc · Thiết kế Thực thi · Kiểm thử Triển khai · Bảo trì Các hệ phương pháp Agile · Cleanroom · Lặp
Trang 1Quy trình phát triển phần mềm
Các hoạt động và các bước
Các yêu cầu · Chi tiết hóa
Kiến trúc · Thiết kế
Thực thi · Kiểm thử
Triển khai · Bảo trì
Các hệ phương pháp
Agile · Cleanroom · Lặp
RAD · RUP · Xoắn ốc
Thác nước · XP · Lean
Scrum · V-Model · TDD
Các ngành hỗ trợ
Quản lí cấu hình
Tài liệu Bảo đảm chất lượng
Quản lí dự án
User experience design
Các công cụ
Trình biên dịch · Trình gỡ rối · Profiler
Người thiết kế GUI · IDE
phân tích yêu cầu là công việc bao gồm các tác vụ xác định các yêu cầu cho một hệ thống mới hoặc được thay đổi, dựa trên cơ sở là các yêu cầu (có thể mâu thuẫn) mà những người có vai trò quan trọng đối với hệ thống, chẳng hạn người sử dụng, đưa ra Việc phân tích yêu cầu có ý nghĩa quan trọng đối với thành công của một dự án.[1]
Việc phân tích yêu cầu một cách có hệ thống còn được gọi là kỹ nghệ yêu cầu (requirements engineering) Đôi khi nó còn được gọi một cách không thật chính xác bằng những cái tên như thu thập yêu cầu (requirements gathering, requirements capture), hoặc đặc tả yêu cầu (requirements specification) Thuật ngữ "phân tích yêu cầu" còn được áp dụng cụ thể cho
công việc thuần túy phân tích (thay vì các việc khác chẳng hạn như làm rõ yêu cầu hay viết tài liệu yêu cầu)
Các yêu cầu phải có tính đo được, kiểm thử được, có liên quan đến các nhu cầu hoặc cơ hội doanh nghiệp đã được xác định, và các yêu cầu phải được định nghĩa ở một mức độ chi tiết đủ cho việc thiết kế hệ thống
Về khái niệm, việc phân tích yêu cầu bao gồm ba loại hoạt động sau:
• Làm rõ yêu cầu (Eliciting requirements): giao tiếp với khách hàng
và người sử dụng để xác định các yêu cầu của họ
• Xem xét yêu cầu (Analyzing requirements): xác định xem các yêu
cầu được đặt ra có ở tình trạng không rõ ràng, không hoàn chỉnh, đa nghĩa, hoặc mâu thuẫn hay không, và giải quyết các vấn đề đó
• Làm tài liệu yêu cầu (Recording requirements): các yêu cầu có thể
được ghi lại theo nhiều hình thức, chẳng hạn các tài liệu ngôn ngữ tự nhiên, các tình huống sử dụng (use case), câu chuyện sử dụng (user story), hoặc các đặc tả tiến trình.
Pha phân tích yêu cầu có thể là một quá trình dài và khó khăn, cần đến nhiều kĩ năng tâm lý khéo léo Các hệ thống mới làm thay đổi môi trường và các mối quan hệ giữa con người, do đó điều quan trọng là phải xác định được tất cả những người có vai trò quan trọng, xem xét tất cả các nhu cầu của họ và đảm bảo rằng họ hiểu được các hàm ý của hệ thống mới Các nhà phân tích có thể sử dụng một số kĩ thuật để làm rõ các yêu cầu của khách hàng Trong lịch sử, các kỹ thuật này bao gồm các cuộc phỏng vấn, thành lập các nhóm trọng tâm (focus group) với các cuộc họp bàn về yêu cầu (requirements workshops), và tạo ra các danh sách yêu cầu Các kỹ
thuật hiện đại hơn gồm có tạo nguyên mẫu(prototyping), và tình huống sử dụng Khi cần thiết, nhà phân tích sẽ kết hợp các phương pháp này để thiết lập các yêu cầu chính xác của những người có vai trò quan trọng, nhằm mục đích xây dựng một hệ thống thỏa mãn các yêu cầu doanh nghiệp
Trang 2Một số nguyên nhân dẫn đến sự thất bại trong việc quản lý dự án như sau:
1 Dự án không có tính thực tế và không khớp
2 Ước tính không chính xác nguồn lực cần thiết cho dự án
3 Xác định yêu cầu hệ thống không đúng
4 Báo cáo tình trạng dự án sơ sài
5 Không quản lý độ rủi ro
6 Việc giao tiếp khách hàng, người sử dụng và người phát triển dự án không tốt
7 Sử dụng công nghệ chưa phát triển
8 Không có khả năng xử lý độ phức tạp của dự án
9 Phát triển thực hành không có hệ thống
10 Thiếu kinh nghiệm trong việc quản lý dự án
11 Các bên liên quan mang tính chính trị
12 Các áp lực mang tính thương mại
Quản lý dự án phần mềm là tập hợp các công việc được thực hiện bởi một tập thể (có thể có chuyên môn khác nhau, thực hiện công việc khác nhau, thời gian tham gia dự án khác nhau) nhằm đạt được một kết quả như dự kiến, trong thời gian dự kiến, với một kinh phí dự kiến Trong thuật ngữ của chuyên ngành Công nghệ phần mềm, Quản lý dự án phần mềm là các
hoạt động trong lập kế hoạch, giám sát và điều khiển tài nguyên dự án (ví dụ như kinh phí, con người), thời gian thực hiện, các
Vấn đề về người dùng và khách hàng
Trong cuốn Rapid Development, Steve McConnell đã liệt kê một loạt các khả năng người dùng có thể cản trở quá trình thu
thập yêu cầu:
• Người dùng không hiểu họ muốn gì
• Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa
• Người dùng nhất định đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển đã được hoạch định xong
• Mức độ giao tiếp với người dùng là thấp
• người dùng thường không tham gia các đợt thẩm định hoặc không thể tham gia
• Người dùng không hiểu kỹ thuật
• Người dùng không hiểu quy trình phát triển
Những điều này có thể dẫn tới tình huống khi yêu cầu người dùng liên tục thay đổi ngay cả khi việc phát triển hệ thống hay sản phẩm đã được bắt đầu
Vấn đề về kỹ sư/nhà phát triển
Trong quá trình phân tích yêu cầu, các vấn đề sau có thể nảy sinh từ phía các kỹ sư và nhà phát triển:
• Nhân viên kỹ thuật và người dùng cuối có thể có ngôn từ khác nhau Kết quả là họ có thể tin rằng họ hoàn toàn đồng thuận cho đến khi sản phẩm hoàn thiện được đưa ra
• Các kỹ sư và nhà phát triển có thể cố lái cho các yêu cầu khớp với một hệ thống hay mô hình sẵn có, thay vì phát triển một hệ thống theo sát nhu cầu của khách hàng
• Việc phân tích có thể do các kỹ sư hoặc lập trình viên thực hiện, thay vì các nhân viên có kỹ năng và kiến thức miền ứng dụng để có thể hiểu các nhu cầu của khách hàng một cách đúng đắn
Giải pháp đã được thực hiện
Một giải pháp đối với các vấn đề về giao tiếp là thuê các chuyên gia về doanh nghiệp hoặc chuyên gia phân tích hệ thống Các kỹ thuật được đưa ra trong thập kỷ 1990 như tạo nguyên mẫu, UML, tình huống sử dụng và phát triển phần mềm linh hoạt (Agile software development) cũng đã được dùng làm giải pháp cho các vấn đề trên.
Trang 3rủi ro và quy trình thực hiện dự án nhằm đảm bảo thành công cho dự án Quản lý dự án phần mềm cần đảm bảo cân bằng giữa ba yếu tố: thời gian, tài nguyên và chất lượng Ba yếu tố này được gọi là tam giác dự án
Quy trình quản lý dự án trong phần mềm
Quy trình quản lý dự án phần mềm là quy trình vận dụng những kiến thức, kỹ năng và kỹ thuật công nghệ vào hoạt động của
dự án để đạt được mục tiêu của dự án đặt ra Những ứng dụng này được đưa vào phần mềm theo một tiêu chuẩn hóa của quản lý dự án theo tiêu chuẩn PMI
Để đảm bảo dự án thành công, các thành viên dự án phải đảm bảo:
• Lựa chọn quy trình phù hợp để đạt được mục tiêu của dự án
• Tuân theo các yêu cầu để đáp ứng được nhu cầu và mong đợi của các bên liên quan
• Cân bằng được các yêu cầu (nhân tố) cạnh tranh trong dự án như: phạm vi công việc, ngân sách, tiến độ, chất lượng, rủi ro, thay đổi Tùy theo quy mô của từng dự án mà các mỗi giai đoạn lại có thể gồm những quy trình nhỏ hơn
Ngoài các lợi ích chiến lược nêu trên phần mềm còn cung cấp đầy đủ các tính năng hệ thống Việc bảo mật được tiến hành một cách tuyệt đối nghiêm ngặt Việc phân quyền được cụ thể đến từng vai trò của người sử dụng
Quy trình kiểm tra và giám sát dự án quản lý phần mềm bao gồm 5 giai đoạn.
1 Khởi tạo dự án (Initiating): Giai đoạn này thực hiện việc định nghĩa một dự án mới hoặc một phát sinh (hoặc trộn lẫn) mới
của một dự áncó sẵn như: Xác định yêu cầu của dự án, mức độ ưu tiên của dự án, phân tích các yêu cầu đầu tư, phân công trách nhiệm cho các bộ phận triển khai
2 Lập kế hoạch dự án (Planning): Giao đoạn này yêu cầu thiết lập phạm vi công viêc của dự án, điều chỉnh lại mục tiêu và
xác định đường đi tới mục tiêu đó
3 Triển khai (Executing): Giai đoạn này thực hiện hoàn thành các công việc được xác định trong phần lập kế hoạch để đảm
bảo các yêu cầu của dự án
4 Giám sát và kiểm soát (Monitoring & Control): Giai đoạn này yêu cầu việc theo dõi, rà soát và điều chỉnh lại tiến độ và khả
năng thực hiện của dự án Theo dõi các rủi ro, thay đổi, phát sinh trong quá trình thực hiện và có những đề xuất điều chỉnh kịp thời
5 Kết thúc (Closing): Giai đoạn này thực hiện để kết thúc tất cả các hoạt động của dự án để chính thức đóng lại dự án.
Các hoạt động chính trong quản lý dự án phần mềm
Xác định yêu cầu chung
Trước tiên, cần xác định các yêu cầu chức năng (công việc phần mềm thực hiện) cũng như phi chức năng (công nghệ dùng để phát triển phần mềm, sử dụng trong hệ điều hành) của phần mềm Tiếp theo cần xác định rõ tài nguyên cần thiết để xây dựng phần mềm Tài nguyên ở đây có thể gồm có nhân tố con người, các thành phần, phần mềm có thể sử dụng lại, các phần cứng hoặc công cụ có sẵn cần dùng đến; trong đó nhân tố con người là quan trọng nhất Điều cuối cùng là xác định thời gian cần thiết để thực hiện dự án Trong quá trình này cần phải nắm bắt được bài toán thực tế cần giải quyết cũng như các hoạt
Trang 4động mang tính nghiệp vụ của khách hàng để có thể xác định rõ ràng yêu cầu chung của đề án, xem xét dự án có khả thi hay không
Viết đề án
Viết đề án là quá trình xây dựng tài liệu mô tả đề án để xác định phạm vi của dự án, trách nhiệm của những người tham gia dự án; là cam kết giữa người quản lý dự án, người tài trợ dự án và khách hàng Nội dung của tài liệu mô tả đề án thường có những nội dung sau: [cần dẫn nguồn]
• Bối cảnh thực hiện dự án: Căn cứ pháp lý để thực hiện dự án, hiện trạng công nghệ thông tin của khách hàng trước khi có dự án, nhu cầu ứng dụng phần mềm của khách hàng, đặc điểm và phạm vi của phần mềm sẽ xây dựng
• Mục đích và mục tiêu của dự án: xác định mục đích tổng thể, tin học hóa hoạt động nào trong quy trình nghiệp vụ của khách hành, xác định mục tiêu của phần mềm gồm lượng dữ liệu xử lý, lợi ích phần mềm đem lại
• Phạm vi dự án: Những người liên quan tới dự án, các hoạt động nghiệp vụ cần tin học hóa
• Nguồn nhân lực tham gia dự án: Cán bộ nghiệp vụ, người phân tích, người thiết kế, người lập trình, người kiểm thử, người cài đặt triển khai dự án cho khách hàng, người hướng dẫn khách hàng sử dụng phần mềm, người bảo trì dự
ánphần mềm
• Ràng buộc thời gian thực hiện dự án: Ngày nghiệm thu dự án, ngày bàn giao dự án
• Ràng buộc kinh phí: Kinh phí trong từng giai đoạn thực hiện dự án
• Ràng buộc công nghệ phát triển: Công nghệ nào được phép sử dụng để thực hiện dự án
• Chữ kí các bên liên quan tới dự án
Lập kế hoạch thực hiện dự án
Lập kế hoạch thực hiện dự án là hoạt động diễn ra trong suốt quá trình từ khi bắt đầu thực hiện dự án đến khi bàn giao sản phẩm với nhiều loại kế hoạch khác nhau nhằm hỗ trợ kế hoạch chính của dự án phần mềm về lịch trình và ngân sách
Các loại kế hoạch thực hiện dự án
• Kế hoạch đảm bảo chất lượng: Mô tả các chuẩn, các qui trình được sử dụng trong dự án
• Kế hoạch thẩm định: Mô tả các phương pháp, nguồn lực, lịch trình thẩm định hệ thống
• Kế hoạch quản lý cấu hình: Mô tả các thủ tục, cấu trúc quản lý cấu hình được sử dụng
• Kế hoạch bảo trì: Dự tính các yêu cầu về hệ thống, chi phí, nỗ lực cần thiết cho bảo trì
• Kế hoạch phát triển đội ngũ: Mô tả kĩ năng và kinh nghiệm của các thành viên trong nhóm dự án sẽ phát triển như thế nào
Quy trình lập kế hoạch thực hiện dự án
• Thiết lập các ràng buộc của dự án: thời gian, nhân lực, ngân sách
• Đánh giá bước đầu về các "tham số" của dự án: quy mô, độ phức tạp, nguồn lực
• Xác định các mốc thời gian trong thực hiện dự án và sản phẩm thu được ứng với mỗi mốc thời gian
• Trong khi dự án chưa hoàn thành hoặc chưa bị hủy bỏ thì thực hiện lặp đi lặp lại các công việc sau:
1 Lập lịch thực hiện dự án
2 Thực hiện các hoạt động theo lịch trình
3 Theo dõi sự tiến triển của dự án, so sánh với lịch trình
4 Đánh giá lại các tham số của dự án
5 Lập lại lịch thực hiện dự án cho các tham số mới
6 Thỏa thuận lại các ràng buộc và sản phẩm bàn giao của mỗi mốc thời gian
7 Nếu có vấn đề nảy sinh thì xem xét lại các kĩ thuật khởi đầu đưa ra các biện pháp cần thiết
Cấu trúc kế hoạch thực hiện dự án
• Tổ chức dự án
Trang 5• Phân tích các rủi ro [3]
• Yêu cầu về tài nguyên phần cứng, phần mềm
• Phân công công việc
• Lập lịch dự án
• Cơ chế kiểm soát và báo cáo
Hướng dẫn về những kiến thức cốt lõi trong Quản lý dự án (tên tiếng Anh là A Guide to the Project Management Body of Knowledge, hoặc viết tắt là PMBOK, PMBOK Guide, hay PMBOK ® Guide), là một cuốn sách hướng dẫn về quản lý dự án, được công nhận đạt tiêu chuẩnquốc tế, cung cấp các kiến thức căn bản của quản lý dự án cho các nhà quản lý dự án chuyên nghiệp, mà dường như những kiến thức đó có hiệu quả với hàng loạt các dự án, trong các ngành xây dựng, phần mềm, cơ khí, ô tô, Cuốn sách này thường dùng làm sách học để chuẩn bị cho các bài kiểm tra (test, examination) của PMI để có thể lấy được chứng nhận (Certification) của PMI về quản lý dự án
PMBOK là một tập hợp các tiến trình (process) và phạm vi kiến thức (knowledge) áp dụng chung cho mọi dự án Tiến trình được mô tả theo các thuật ngữ:[1]Project Management Body of Knowledge
• Dữ liệu đầu vào (văn bản, kế hoạch, bản thiết kế, các thông tin liên quan )
• Công cụ và kỹ thuật quản lý (xử lý các thông tin đầu vào)
• Đưa ra kết quả, quyết định (văn bản, sản phẩm, điều chỉnh quá trình, )
PMBOK đưa ra 5 nhóm tiến trình cơ bản và 10 phạm vi kiến thức điển hình cho mọi dự án:[1]
• 5 nhóm tiến trình là:
1 Khởi động/chuẩn bị dự án
2 Lập kế hoạch
3 Triển khai, thực hiện
4 Giám sát và quản lý
5 Kết thúc dự án
• 10 phạm vi kiến thức là:
1 Quản lý tổng hợp dự án
2 Quản lý phạm vi dự án
3 Quản lý thời gian dự án
4 Quản lý chi phí dự án
5 Quản lý chất lượng dự án
6 Quản lý nhân lực dự án
7 Quản lý thông tin dự án
8 Quản lý rủi ro dự án
9 Quản lý hồ sơ dự án
10.Quản lý các bên liên quan (được thêm vào trong ấn bản 5)
Quản lý tổng hợp dự án, tạm dịch từ project integration management là một 10 lĩnh vực kiến thức (knowledge area) trong
Project Management Body of Knowledge 5th edition (PMBOK 5) được Viện Quản Lý Dự Án PMI ban hành vào tháng 1 năm
2013 Quản lý tích hợp dự án gồm 6 quy trình:
· Xây dựng điều lệ dự án (Develop Project Charter) · Xây dựng kế hoạch quản lý dự án (Develop Project Management Plan) · Chỉ đạo và quản lý công việc dự án (Direct and Manage Project Work) · Theo dõi và kiểm soát công việc dự án (Monitor and
Trang 6Control Project Work) · Thực hiện kiểm soát thay đổi tích hợp (Perform Integrated Change Control) · Kết thúc dự án hay giai đoạn (Close Project or Phase)
1 Xây dựng điều lệ dự án (Develop Project Charter): là quy trình xây dựng tài liệu chính thức cho phép sự tồn tại của dự án và cho phép nhà quản lý dự án có quyền sử dụng các nguồn lực của tổ chức vào các hoạt động của dự án Lợi ích của quy trình này là xác nhận rõ ràng ngày bắt đầu dự án và các ranh giới dự án, tạo ra hồ sơ dự án và có được sự thừa nhận cũng như cam kết chính thức của quản lý cấp cao với dự án
2 Xây dựng kế hoạch quản lý dự án (Develop Project Management Plan): là quy trình xác định, chuẩn bị và phối hợp tất cả các
kế hoạch con của 9 lĩnh vực kiến thức (phạm vi, thời gian, chi phí, chất lượng, giao tiếp, nhân sự, rủi ro, mua sắm, các bên liên quan) và tích hợp chúng vào một kế hoạch quản lý dự án toàn diện Lợi ích của quy trình này là cung cấp một tài liệu tập trung làm cơ sở cho tất cả các công việc dự án
3 Chỉ đạo và quản lý công việc dự án (Direct and Manage Project Work): là quy trình lãnh đạo và thực hiện công việc được xác định trong kế hoạch quản lý dự án và thực hiện các thay đổi đã được phê duyệt để đạt được mục tiêu của dự án Lợi ích của quy trình này là quản lý toàn bộ công việc của dự án
4 Theo dõi và kiểm soát công việc dự án (Monitor and Control Project Work): là quy trình theo dõi, rà soát và báo cáo tiến độ
để đáp ứng các mục tiêu được xác định trong kế hoạch quản lý dự án Lợi ích của quy trình này là cho phép các bên liên quan hiểu được trạng thái hiện tại của dự án, các bước thực hiện, và dự báo về ngân sách, lịch trình và phạm vi dự án
5 Thực hiện kiểm soát thay đổi tích hợp (Perform Integrated Change Control): là quy trình xem xét tất cả các yêu cầu thay đổi; phê duyệt những thay đổi và quản lý thay đổi liên quan đến sản phẩm bàn giao, tài sản quy trình tổ chức, tài liệu dự án và kế hoạch quản lý dự án; và truyền thông quyết định cuối cùng đối với các yêu cầu thay đổi Quy trình này xem xét tất cả các yêu cầu liên quan đến thay đổi hay sửa đổi tài liệu dự án, sản phẩm bàn giao, đường cơ sở dự án, hay kế hoạch dự án, và phê duyệt hoặc từ chối các yêu cầu đó Lợi ích của quy trình này là cho phép lập tài liệu các thay đổi trong dự án, xem xét ở 1 các nhìn tích hợp tất cả các lĩnh vực kiến thức, giảm thiểu rủi ro dự án do thay đổi gây ra
6 Kết thúc dự án hay giai đoạn (Close Project or Phase): là quy trình hoàn thiện tất cả các hoạt động của tất cả các nhóm quy trình quản lý dự án nhằm chính thức hoàn thành dự án hoặc giai đoạn Lợi ích của quy trình này là cung cấp bài học kinh nghiệm, kết thúc chính thức của công việc dự án, và trả các nguồn lực dự án về cho tổ chức để phục vụ các dự án hay công việc khác
Quản lý chất lượng là các hoạt động có phối hợp để định hướng và kiểm soát một tổ chức về chất lượng Việc định hướng và kiểm soát về chất lượng nói chung bao gồm lập chính sách chất lượng và mục tiêu chất lượng, hoạch định chất lượng, kiểm soát chất lượng, đảm bảo chất lượng và cải tiến chất lượng
Quản lý chất lượng hiện đã được áp dụng trong mọi ngành công nghiệp, không chỉ trong sản xuất mà trong mọi lĩnh vực, trong mọi loại hình tổ chức, từ quy mô lớn đến quy mô nhỏ, cho dù có tham gia vào thị trường quốc tế hay không Quản lý chất lượng đảm bảo cho tổ chức làm đúng những việc phải làm và những việc quan trọng, theo triết lý "làm việc đúng" và "làm đúng việc",
"làm đúng ngay từ đầu" và "làm đúng tại mọi thời điểm"
1
Các định nghĩa về quản lý chất lượng
2
Lịch sử phát triển của quản lý chất lượng
3
Các nguyên tắc quản lý chất lượng
4
Các quá trình của quản lý chất lượng
4.1
Lập kế hoạch chất lượng
4.2
Kiểm soát chất lượng
4.3
Đảm bảo chất lượng
4.4
Cải tiến chất lượng
Trang 7Quản lý chất lượng theo phương pháp truyền thống
6
Quản lý chất lượng toàn diện
Quản lý rủi ro dự án là nghệ thuật và khoa học của việc nhận biết, phân tích và phản hồi rủi ro thông qua vòng đời dự ánvà trong các lợi ích tốt nhất để đạt được các mục tiêu của dự án.[1] Quản lý rủi ro dự án được xem là khía cạnh quan trọng trong việc quản lý dự án và là một trong chín lĩnh vực kiến thức được định nghĩa trong PMBOK.[2] Quản lý rủi ro có thể xem như là một sự kiện hay một hoạt động không thể dự đoán được có thể tác động đến quy trình dự án, kết quả có thể là tích cực hoặc tiêu cực Nó có thể tác động tích cực trong việc lựa chọn dự án, định nghĩa quy mô dự án và phát triển lịch trình thực tế và đánh giá được đúng chi phí bỏ ra.[1]
Rủi ro có thể được đánh giá theo 2 nhân tố: tác động và khả năng xảy ra
Nếu khả năng xảy ra là 1, nó là vấn đề Điều này có nghĩa rủi ro được tài liệu hóa Nếu khả năng xảy ra là 0, điều này có nghĩa rủi ro không xảy ra và có thể loại bỏ trong công cụ đăng ký rủi ro
Lợi ích của quản lý rủi ro [ sửa | sửa mã nguồn ]
Quản lý rủi ro giúp giảm thiểu, giám sát và điều khiển tính khả thi hoặc tác động của các sự kiện không dự đoán được hoặc tối
đa hóa sự nhân dạng các cơ hội Theo đó, một số lợi ích chính trong việc quản lý rủi ro phần mềm như sau:[3]
• Dự đoán và phòng tránh được vấn đề
• Ngăn chặn sự bất ngờ xảy ra với các bên liên quan tham gia dự án
• Nâng cao khả năng dàn xếp
• Đạt được các cam kết của khách hàng
• Giảm thiểu sự kéo dài lịch trình phát triển dự án
• Giảm sự tăng chi phí dự án quá mức
Công cụ
Cấu trúc chia nhỏ rủi ro (risk breakdown structure) được xem là một công cụ hữu ích để nhận biết các rủi ro xảy ra đến dự án trong các danh mục khác nhau
Sơ đồ mẫu về cấu trúc chia nhỏ rủi ro của dự án công nghệ thông tin
Mô hình thác nước (tiếng Anh: waterfall model) là một mô hình của quy trình phát triển phần mềm, trong đó quy trình phát triển trông giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt
Trang 8pha là: phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm thử, liên kết và bảo trì Người ta thường dẫn bài báo đượcWinston
W Royce xuất bản vào năm 1970 để giải thích nguồn gốc cho tên gọi "thác nước"; nhưng có điều thú vị là chính Royce đã dùng mô hình phát triển lặp chứ không hề dùng thuật ngữ "mô hình thác nước"
Nội dung mô hình thác nước
Vào năm 1990 trong bài báo của mình, Royce đã mô tả ở dạng khái niệm cái mà ngày nay được công nhận với tên gọi "mô hình thác nước", đã bàn luận về những nhược điểm của mô hình này Trong đó ông cũng chỉ ra rằng mô hình này có thể sẽ được tu sửa thành mô hình lặp
Mô hình Royce nguyên gốc có các pha theo đúng thứ tự sau:
1 Xác định yêu cầu
2 Thiết kế
3 Xây dựng (hay "triển khai", "mã hóa", "viết mã")
4 Liên kết
5 Kiểm thử và Chỉnh sửa (hay «kiểm nghiệm»)
6 Cài đặt
7 Bảo trì
Theo mô hình thác nước, người phát triển phải thực hiện từng giai đoạn theo thứ tự nghiêm ngặt Trước hết, giai đoạn "xác định yêu cầu" phải được hoàn tất, kết quả nhận được sẽ là danh sách các yêu cầu đối với phần mềm Sau khi các yêu cầu đã hoàn toàn được xác định, sẽ chuyển sang pha thiết kế, ở pha này người ta sẽ tạo ra các tài liệu dành cho lập trình viên, trong
đó mô tả chi tiết các phương pháp và kế hoạch thực hiện các yêu cầu đã được làm rõ ở pha trước Sau khi pha thiết kế hoàn tất, lập trình viên sẽ triển khai thực hiện (mã hóa, viết mã) đồ án họ nhận được Giai đoạn tiếp theo là liên kết các thành phần riêng lẻ đã được những đội lập trình viên khác nhau thực hiện thành một sản phẩm hoàn chỉnh Sau khi pha triển khai và pha liên kết hoàn tất, sẽ diễn ra pha kiểm thử và chỉnh sửa sản phẩm; ở giai đoạn này những khiếm khuyết ở các giai đoạn trước
đó sẽ bị loại bỏ Sau đó, sản phẩm phần mềm sẽ được đưa vào sử dụng; phần bảo trì phần mềm cũng sẽ được bảo đảm bằng cách bổ sung chức năng mới và loại trừ các lỗi
Như vậy, mô hình thác nước ngụ ý rằng, việc chuyển từ pha phát triển này sang pha khác sẽ diễn ra chỉ sau khi các pha trước
đó đã kết thúc hoàn toàn thành công, và không thể quay lui về pha trước đó hay nhảy vượt pha
Tuy nhiên, tồn tại một số mô hình thác nước biến thể (bao gồm cả mô hình của Royce), trong đó quy trình phát triển đã được
mô tả ở trên bị biến đổi không nhiều hoặc cũng có thể bị biến đổi đáng kể