(LUẬN VĂN THẠC SĨ) Mô hình trưởng thành khả năng, mô hình trưởng thành tái sử dụng và áp dụng thực tiễn trong hoạt động sản xuất phần mềm tại công ty CT IN

Tổ chức phần mềm chưa trưởng thành và trưởng thành

Đặt ra mục tiêu cải tiến quy trình yêu cầu hiểu biết về sự khác biệt giữa tổ chức phần mềm trưởng thành và chưa trưởng thành Trong tổ chức chưa trưởng thành, quy trình phần mềm thường bị tùy biến bởi người thực hiện và quản lý, dẫn đến việc không tuân thủ hiệu quả quy trình đã xác định Các hoạt động thường chỉ mang tính hình thức, với nhà quản lý tập trung vào giải quyết vấn đề tức thời mà không tìm cách khắc phục nguyên nhân gốc rễ Kế hoạch và tài chính thường bị vượt quá do thiếu ước lượng thực tế, và khi thời hạn gần kề, chức năng và chất lượng sản phẩm thường bị điều chỉnh để đáp ứng yêu cầu.

Trong các tổ chức phần mềm chưa phát triển, việc thiếu mục tiêu rõ ràng cho việc cải thiện chất lượng sản phẩm và xử lý vấn đề khiến chất lượng trở nên khó đoán Các hoạt động như xem xét và kiểm thử chất lượng thường bị xem nhẹ hoặc chỉ thực hiện khi dự án gặp áp lực.

Một tổ chức phần mềm trưởng thành có khả năng quản lý phát triển và bảo trì quy trình phần mềm hiệu quả Quy trình này thường xuyên được trao đổi giữa nhân viên hiện tại và nhân viên mới, với các hoạt động được thực hiện theo kế hoạch đã định Việc thực hiện quy trình phù hợp với thực tế công việc và được cập nhật khi cần thiết Cải tiến được thực hiện thông qua kiểm thử có kiểm soát và phân tích lợi ích tài chính Vai trò và trách nhiệm trong quy trình được xác định rõ ràng trong dự án và tổ chức.

Trong một tổ chức trưởng thành, các nhà quản lý giám sát chất lượng sản phẩm và tiến trình sản xuất, với mục tiêu rõ ràng và khả năng điều chỉnh chất lượng Lịch làm việc và ngân sách dựa trên năng lực quá khứ, giúp đạt được kết quả mong muốn về giá cả, khung thời gian, chức năng và chất lượng sản phẩm Quy trình được thực hiện nhất quán nhờ sự hiểu biết chung về giá trị của nó và hạ tầng hỗ trợ phù hợp.

Các khái niệm cơ bản trên khía cạnh trưởng thành tiến trình

Tiến trình phần mềm là tập hợp các hành động, phương thức và trải nghiệm mà con người áp dụng để phát triển và bảo trì phần mềm cùng các sản phẩm liên quan như kế hoạch dự án, tài liệu thiết kế, mã nguồn, ca kiểm thử và hướng dẫn sử dụng Khi tổ chức phát triển, tiến trình phần mềm trở nên rõ ràng hơn và được thực hiện một cách chính xác và nhất quán trong toàn bộ tổ chức.

Khả năng tiến trình phần mềm của tổ chức phản ánh một loạt các kết quả mong muốn có thể đạt được thông qua việc tuân thủ quy trình phần mềm Điều này cung cấp một công cụ dự đoán chính xác các công việc cần thực hiện và kết quả dự kiến cho dự án tiếp theo mà tổ chức đang chuẩn bị triển khai.

Hiệu năng tiến trình phần mềm phản ánh kết quả thực tế đạt được từ việc tuân thủ các quy trình phần mềm Trong khi đó, khả năng tiến trình phần mềm tập trung vào kết quả mong muốn và kế hoạch dự kiến Do đó, hiệu năng và khả năng tiến trình phần mềm đều đóng vai trò quan trọng trong việc đánh giá và cải thiện quy trình phát triển phần mềm.

Sự trưởng thành của tiến trình phần mềm phản ánh khả năng xác định, quản lý và đo lường hiệu quả của các quy trình này Điều này không chỉ cho thấy tiềm năng phát triển về năng lực tổ chức và quản lý mà còn khẳng định sự đầy đủ và thống nhất trong việc áp dụng các tiến trình phần mềm trong toàn bộ dự án của tổ chức.

Khi một tổ chức phần mềm đạt được sự trưởng thành trong quy trình phát triển, nó tích hợp quy trình của mình thông qua các chính sách, tiêu chuẩn và cấu trúc tổ chức Sự tích hợp này bao gồm việc xây dựng hạ tầng và văn hóa doanh nghiệp hỗ trợ các phương thức, thực hành và quy trình, đảm bảo rằng chúng vẫn tồn tại lâu dài ngay cả khi những người sáng lập đã rời bỏ tổ chức.

Năm mức trưởng thành tiến trình phần mềm

Đặc tính cư xử của các mức trưởng thành

Các mức trưởng thành từ 2 đến 5 có thể được phân biệt qua các hành động thực hiện của tổ chức nhằm cải tiến tiến trình phần mềm Những hành động này được thể hiện trong từng dự án và khả năng tiến trình đạt được thông qua các dự án Đặc tính cư xử của mỗi mức tạo cơ sở cho việc so sánh sự cải tiến tiến trình ở các mức độ trưởng thành cao hơn.

Ở mức khởi đầu, tổ chức thường thiếu môi trường ổn định cho phát triển và bảo trì phần mềm, dẫn đến khó khăn trong việc đáp ứng các quy trình kỹ nghệ Kết quả là hàng loạt khủng hoảng xảy ra, với các dự án không tuân thủ quy trình đã được lập kế hoạch và thường xuyên quay lại giai đoạn lập trình và kiểm thử Thành công của dự án phụ thuộc nhiều vào sự hiện diện của một người quản lý giỏi và nhóm phát triển có kinh nghiệm Tuy nhiên, khi người quản lý tài ba rời khỏi dự án, sự ổn định cũng thường mất đi Ngay cả khi có quy trình kỹ nghệ tốt, sự thiếu sót trong thực hành quản lý hợp lý vẫn có thể gây ra sự không ổn định nghiêm trọng.

Mặc dù quy trình ở mức 1 thường khó xác định và có thể hỗn loạn, các tổ chức tại mức này vẫn phát triển được các sản phẩm hoạt động, mặc dù có thể vượt ngân sách và thời gian dự kiến Sự thành công của những tổ chức này chủ yếu phụ thuộc vào năng lực và yếu tố cá nhân của từng thành viên, và không thể lặp lại nếu không có những cá nhân có năng lực tương tự tham gia vào các dự án tiếp theo Do đó, tại mức 1, năng lực được xem là đặc điểm của cá nhân chứ không phải của tổ chức.

Các chính sách quản lý dự án phần mềm và các thủ tục thực hiện chúng được thiết lập ở mức lặp lại được Việc lập kế hoạch và quản lý các dự án mới thường dựa vào kinh nghiệm từ các dự án tương tự trước đó Năng lực tiến trình được cải thiện thông qua việc thiết lập quy tắc quản lý tiến trình cơ bản, áp dụng từ dự án này sang dự án khác Một tiến trình hiệu quả được xác định bởi việc thực hành, tài liệu hóa, tuân thủ, đào tạo, đo lường và khả năng cải tiến liên tục.

Các tổ chức mức 2 thường thiết lập các điều khiển quản lý phần mềm cơ bản cho các dự án Cam kết dự án dựa trên kết quả từ các dự án trước và yêu cầu của dự án hiện tại Các nhà quản lý theo dõi chi phí, lịch trình và chức năng phần mềm, đồng thời xác định các vấn đề trong các cuộc họp cam kết Yêu cầu phần mềm và sản phẩm công việc được phát triển đúng mốc thời gian và được quản lý tích hợp Chuẩn dự án phần mềm được xác định và tổ chức đảm bảo tuân thủ Các dự án làm việc với nhà thầu phụ sẽ xây dựng mối quan hệ bền vững giữa khách hàng và nhà cung cấp.

Các tiến trình trong tổ chức có thể khác nhau giữa các dự án ở mức 2 Để đạt được mức 2, tổ chức cần có chính sách hướng dẫn cho các dự án nhằm xây dựng các tiến trình quản lý hợp lý.

Năng lực tiến trình phần mềm ở mức 2 trong các tổ chức được thể hiện qua việc lập kế hoạch và theo dõi dự án một cách ổn định, cho phép lặp lại những thành công từ sớm Dự án được kiểm soát hiệu quả nhờ vào hệ thống quản lý dự án, tuân thủ các kế hoạch thực tế dựa trên hiệu suất của các dự án trước đó.

2.1.3 Mức đã được xác định

Tại mức đã được xác định, tổ chức thực hiện một tiến trình chuẩn cho phát triển và bảo dưỡng phần mềm, bao gồm cả tiến trình kỹ nghệ phần mềm và quản lý, được tích hợp thành một hệ thống thống nhất Tiến trình chuẩn này tham chiếu đến CMM như là chuẩn phần mềm của tổ chức, sử dụng các tiến trình tại mức 3 để hỗ trợ nhà quản lý và nhân viên kỹ thuật làm việc hiệu quả hơn Tổ chức khám phá các thực hành kỹ nghệ phần mềm hiệu quả thông qua việc chuẩn hóa tiến trình Một nhóm chịu trách nhiệm về hoạt động tiến trình phần mềm, như nhóm tiến trình kỹ nghệ phần mềm (SEPG), được thành lập Đồng thời, chương trình đào tạo toàn diện được triển khai để đảm bảo tất cả nhân viên và quản lý có đủ kiến thức và kỹ năng cần thiết cho các vị trí được giao.

Các dự án phần mềm có thể thay đổi tiến trình chuẩn của tổ chức, tạo ra một tiến trình phần mềm xác định với các đặc tính riêng Trong mô hình CMM, tiến trình này được gọi là tiến trình phần mềm đã được xác định Một tiến trình phần mềm đã được xác định bao gồm các kỹ thuật phần mềm được định nghĩa rõ ràng và các quy trình quản lý được tích hợp chặt chẽ Một tiến trình được định nghĩa tốt sẽ có các chỉ tiêu sẵn sàng, đầu vào, tiêu chuẩn và thủ tục thực hiện công việc, cũng như cơ chế xác minh như xem xét ngang cấp, đầu ra và chỉ tiêu hoàn thành Nhờ vào việc định nghĩa tốt tiến trình phần mềm, cấp quản lý có cái nhìn thực tế về tiến trình kỹ thuật của tất cả các dự án.

Năng lực tiến trình phần mềm của tổ chức ở mức 3 được đặc trưng bởi sự chuẩn hóa và thống nhất, với các hoạt động kỹ nghệ phần mềm và quản lý ổn định, có thể lặp lại Các yếu tố như dải sản phẩm, giá cả, lịch hoàn thành và chức năng đều được kiểm soát chặt chẽ, đồng thời chất lượng phần mềm cũng được theo dõi kỹ lưỡng Sự hiểu biết chung về các hoạt động, vai trò và trách nhiệm trong tiến trình phần mềm đã được xác định, tạo nên một nền tảng vững chắc cho tổ chức.

Tại mức quản lý, tổ chức đặt ra các mục tiêu chất lượng phần mềm cụ thể cho sản phẩm và quy trình Năng suất và chất lượng được đo lường cho các hoạt động phần mềm quan trọng trong tất cả các dự án, là một phần của chương trình đánh giá tổ chức Một cơ sở dữ liệu quy trình phần mềm toàn tổ chức được sử dụng để thu thập và phân tích dữ liệu từ các quy trình đã xác định trong dự án Các quy trình phần mềm được trang bị công cụ đo lường được xác định rõ ràng và nhất quán tại mức 4, cung cấp cơ sở dữ liệu cho việc đánh giá quy trình phần mềm và sản phẩm.

Dự án đạt được hiệu quả thông qua sản phẩm và tiến trình của nó bằng cách kiểm soát sự thay đổi trong hiệu suất tiến trình để duy trì trong giới hạn cho phép Những thay đổi đáng kể trong hiệu suất có thể được phân biệt nhờ vào các yếu tố ngẫu nhiên, đặc biệt trong dòng sản phẩm đã được phát hành Các rủi ro liên quan đến việc điều chỉnh và nâng cao việc học trong các lĩnh vực ứng dụng mới cần được nhận diện và quản lý một cách chặt chẽ.

Năng lực tiến trình phần mềm của các tổ chức mức 4 cho phép đo đạc và dự đoán trước, nhờ vào việc các tiến trình hoạt động trong giới hạn lượng hóa Mức năng lực này giúp tổ chức dự đoán xu hướng và chất lượng sản phẩm trong các giới hạn đã xác định Khi tiến trình ổn định và đo đạc được, các "nguyên nhân đặc biệt" của sự biến đổi có thể dễ dàng xác định và xử lý Nếu giới hạn của tiến trình bị vượt qua, tổ chức sẽ thực hiện các hành động cần thiết để khắc phục Do đó, sản phẩm phần mềm được xem là có chất lượng cao và dễ dự đoán.

Tại mức tối ưu, tổ chức tập trung vào việc cải tiến quy trình liên tục, sử dụng công cụ để xác định điểm yếu và nâng cao quy trình một cách chủ động Mục tiêu là ngăn ngừa lỗi xuất hiện Dữ liệu về hiệu quả quy trình phần mềm được phân tích để đánh giá giá trị và lợi nhuận từ công nghệ mới, từ đó đưa ra đề xuất thay đổi quy trình phần mềm Sự năng động trong việc áp dụng các thực hành kỹ nghệ phần mềm tốt nhất được xác định và chuyển giao trên toàn tổ chức.

Nhóm dự án phần mềm tại các tổ chức ở mức 5 thực hiện phân tích lỗi để xác định nguyên nhân gốc rễ Họ đánh giá các quy trình phần mềm nhằm ngăn ngừa sự tái diễn của các lỗi đã biết, đồng thời chia sẻ bài học kinh nghiệm cho các dự án khác.

Năng lực tiến trình và dự báo hiệu năng

Sự trưởng thành của tiến trình phần mềm trong tổ chức đóng vai trò quan trọng trong việc dự báo khả năng của dự án đạt được các mục tiêu đề ra Các dự án ở cấp độ 1 thường phải đối mặt với nhiều thay đổi lớn liên quan đến giá cả, lịch trình, chức năng và chất lượng Như thể hiện trong hình 2.4, ba cải tiến trong việc đạt mục tiêu được kỳ vọng sẽ phản ánh sự trưởng thành của tiến trình phần mềm Những kỳ vọng này dựa trên kết quả định lượng từ các cải tiến đã được thực hiện trong các ngành công nghiệp khác và phù hợp với các kết quả ban đầu được báo cáo bởi các tổ chức phần mềm.

Khi độ trưởng thành của tổ chức tăng lên, sự chênh lệch giữa kết quả mục tiêu và kết quả thực tế trong các dự án giảm đáng kể Các tổ chức ở mức độ trưởng thành thấp thường gặp khó khăn trong việc hoàn thành đúng hạn, dẫn đến việc trễ hẹn lớn, trong khi những tổ chức có mức độ trưởng thành cao hơn có khả năng đạt được ngày giao hàng với độ chính xác cao hơn Điều này được minh họa rõ ràng qua hình 2.4, cho thấy sự giảm thiểu của vùng phía dưới đường cong ở bên phải của đường đích.

Khi mức độ trưởng thành của tổ chức tăng lên, khả năng thay đổi kết quả thực tế xung quanh mục tiêu giảm Cụ thể, trong các tổ chức cấp độ 1, thời gian giao hàng cho các dự án có kích cỡ tương tự thường rất khó đoán và có sự biến động lớn Ngược lại, trong các tổ chức có mức trưởng thành cao hơn, các dự án tương tự sẽ được giao hàng trong khoảng thời gian ổn định hơn, điều này được minh họa qua hình 2.4 với vùng phía dưới đường cong tập trung gần đường đích.

Khi mức độ trưởng thành của tổ chức phần mềm tăng lên, các kết quả đích được cải thiện rõ rệt Điều này có nghĩa là giá phần mềm giảm, thời gian phát triển rút ngắn, và năng suất cùng chất lượng được nâng cao Ở các tổ chức có mức trưởng thành thấp, thời gian phát triển có thể kéo dài do phải làm lại nhiều để khắc phục lỗi Ngược lại, các tổ chức có mức trưởng thành cao hơn đã tối ưu hóa quy trình, giảm thiểu công việc làm lại liên quan đến giá, từ đó rút ngắn thời gian phát triển Sự cải thiện này được minh họa trong hình 2.4 qua sự dịch chuyển của đường đích.

Sự cải tiến trong dự báo kết quả dự án phần mềm thể hiện qua việc đầu ra trở nên dễ đoán hơn và giảm thiểu nhiễu Các hệ thống chưa có tiền lệ có thể làm phức tạp bức tranh do công nghệ mới, nhưng tổ chức trưởng thành hơn có khả năng xác định và giải quyết vấn đề sớm trong vòng đời phát triển Điều này giúp phát hiện sớm các dự án “thất bại”, từ đó tối thiểu hóa tổn thất đầu tư.

Các nghiên cứu về cải tiến quy trình phần mềm cho thấy rằng nỗ lực này mang lại sự nâng cao rõ rệt về chất lượng và năng suất Tỷ lệ tái đầu tư cho các nỗ lực cải tiến quy trình thành công thường nằm trong khoảng từ 5:1 đến 8:1.

Bỏ qua các mức trưởng thành

Việc bỏ qua các mức trưởng thành trong mô hình CMM là không hiệu quả, vì mỗi mức tạo nền tảng cho mức tiếp theo Mô hình CMM hướng dẫn các tổ chức xây dựng văn hóa kỹ nghệ phần mềm hoàn hảo Các tổ chức có thể thực hiện cải tiến quy trình bất cứ lúc nào, nhưng cần nhận thức rằng sự ổn định của các cải tiến này có thể gặp rủi ro cao nếu chưa có nền tảng vững chắc Quy trình thiếu cơ sở sẽ không thành công trong những tình huống áp lực cao và không hỗ trợ cho sự cải tiến trong tương lai.

Một tiến trình phần mềm được định nghĩa tốt là đặc điểm của tổ chức ở mức 3, nhưng có thể gặp rủi ro lớn hơn nếu quản lý không cam kết với lịch trình được lên kế hoạch hoặc không kiểm soát được các thay đổi yêu cầu Nhiều tổ chức đã thu thập dữ liệu chi tiết ở mức 4, nhưng lại phát hiện rằng dữ liệu này không thể hiểu được do sự không thống nhất trong các tiến trình phát triển phần mềm.

Để cải tiến tiến trình, tổ chức cần tập trung vào nhu cầu của mình trong bối cảnh kinh doanh cụ thể Các thực hành nâng cao có thể đáp ứng nhu cầu hiện tại của tổ chức hoặc dự án Ví dụ, để chuyển từ mức 1 lên mức 2, một gợi ý phổ biến là thành lập nhóm kỹ nghệ tiến trình phần mềm (SEPG), điều này thường được xem là đặc điểm của tổ chức ở mức 3 Mặc dù SEPG không phải là yêu cầu bắt buộc ở mức 2, nhưng nó có thể đóng vai trò hữu ích trong việc mô tả lộ trình đạt được mức cao hơn.

Định nghĩa theo kiểu hoạt động của mô hình CMM

Cấu trúc bên trong của các mức trưởng thành

Mỗi mức trưởng thành được chia thành các phần nhỏ, trừ mức 1 Việc phân chia này diễn ra từ các tổng kết trừu tượng đến định nghĩa hoạt động trong các thực hành then chốt, như thể hiện trong hình 3.1 Mỗi mức trưởng thành bao gồm nhiều vùng tiến trình then chốt, và mỗi vùng này được tổ chức thành 5 phần gọi là các đặc điểm chung Những đặc điểm chung này xác định các thực hành then chốt, khi được giải quyết tập trung, sẽ giúp đạt được mục tiêu của vùng tiến trình then chốt.

Các mức trưởng thành

Mức trưởng thành là trạng thái ổn định trong tiến trình phần mềm, phản ánh khả năng của tổ chức Mỗi mức trưởng thành chỉ ra một giai đoạn phát triển khác nhau, như minh họa trong hình 2.1 Chẳng hạn, tại mức 2, năng lực tiến trình của tổ chức đã được cải thiện từ tình trạng hỗn loạn sang quy củ nhờ vào việc áp dụng các biện pháp quản lý dự án hợp lý.

Các vùng tiến trình then chốt

Ngoại trừ mức 1, mỗi mức trưởng thành đều được cấu thành từ các vùng tiến trình then chốt, giúp tổ chức xác định nơi cần tập trung để cải tiến quy trình phần mềm Các vùng tiến trình này xác định các vấn đề cần giải quyết để đạt được mức trưởng thành mong muốn.

Vùng tiến trình then chốt xác định chuỗi hoạt động liên quan, khi thực hiện tập trung sẽ đạt được các mục tiêu quan trọng nhằm cải thiện khả năng tiến trình Các vùng này được định nghĩa để tạo ra mức trưởng thành đơn, như thể hiện trong hình 3.2 Con đường đạt được mục tiêu của vùng tiến trình then chốt có thể khác nhau giữa các dự án do sự khác biệt trong lĩnh vực ứng dụng và môi trường Tuy nhiên, để thỏa mãn một vùng tiến trình then chốt, tổ chức cần đạt được tất cả các mục tiêu đã đặt ra.

Tính từ “then chốt” ám chỉ rằng có những vùng tiến trình không phải là yếu tố quyết định để đạt được mức trưởng thành trong phát triển phần mềm Mô hình CMM không đề cập chi tiết đến tất cả các vùng tiến trình liên quan, nhưng đã xác định một số vùng tiến trình quan trọng như những yếu tố quyết định chính cho khả năng tiến trình Những vùng này được mô tả rõ ràng trong CMM.

Các vùng tiến trình then chốt là yêu cầu cần thiết để đạt được mức trưởng thành Để hoàn thành mức trưởng thành, tất cả các vùng tiến trình then chốt của mức đó phải được thỏa mãn.

Các thực hành đặc biệt trong từng vùng tiến trình then chốt sẽ liên quan khi tổ chức đạt được mức độ trưởng thành cao hơn Chẳng hạn, khả năng ước tính phần mềm trong vùng tiến trình Lên kế hoạch dự án phần mềm cần phải được kết hợp để quản lý dữ liệu dự án hiệu quả hơn tại các mức độ trưởng thành.

3, như được miêu tả trong “Quản lý dự án tích hợp” (Integrated Software Management)

Các vùng tiến trình then chốt tại mức 2 tập trung vào việc giải quyết các vấn đề liên quan đến dự án phần mềm, đặc biệt là việc thiết lập các điều khiển quản lý dự án cơ sở.

Mục đích của Quản lý yêu cầu là xây dựng sự hiểu biết chung giữa khách hàng và dự án phần mềm về các yêu cầu cần giải quyết Sự đồng thuận này với khách hàng đóng vai trò quan trọng trong việc lập kế hoạch và quản lý dự án phần mềm hiệu quả.

Lên kế hoạch dự án phần mềm nhằm mục đích xây dựng một kế hoạch phù hợp cho việc thực hiện và quản lý các kỹ nghệ phần mềm Những kế hoạch này đóng vai trò là cơ sở thiết yếu cho việc quản lý hiệu quả dự án phần mềm.

Giám sát và trông trước dự án phần mềm nhằm cung cấp cái nhìn chính xác về tiến độ thực tế, giúp quản lý thực hiện các hành động hiệu quả khi tiến độ dự án bị thay đổi so với kế hoạch.

The goal of Software Subcontract Management is to select high-quality software subcontractors and manage them effectively.

Mục đích của Đảm bảo chất lượng phần mềm (Software Quality Assurance) là cung cấp cho cấp quản lý cái nhìn rõ ràng về quy trình dự án và các sản phẩm đang được phát triển.

Quản lý cấu hình phần mềm (Software Configuration Management) nhằm mục đích thiết lập và duy trì sự tích hợp liên tục của các sản phẩm trong dự án phần mềm trong suốt vòng đời của nó.

Các vùng tiến trình then chốt ở mức 3 tập trung vào việc giải quyết các vấn đề tại cấp độ dự án và tổ chức Tại đây, tổ chức xây dựng một hạ tầng kết hợp hiệu quả giữa kỹ nghệ phần mềm và các quy trình quản lý, đảm bảo tính liên tục và đồng bộ trong tất cả các dự án.

Điểm tập trung của tiến trình tổ chức là xác định trách nhiệm của tổ chức trong các hoạt động tiến trình phần mềm, nhằm nâng cao khả năng tiến trình phần mềm tổng thể của tổ chức.

Xác định nghĩa tiến trình tổ chức (Organization Process Definition) là việc phát triển và duy trì một bộ đánh giá tiến trình phần mềm nhằm cải thiện hiệu suất trong các dự án Nó cung cấp một nền tảng cho việc xác định dữ liệu có ý nghĩa trong quản lý tiến trình một cách định lượng Những đánh giá này tạo ra một cơ sở ổn định có thể tích hợp thông qua các cơ chế như đào tạo.

Các mục tiêu

Các mục tiêu tổng hợp các thực hành then chốt của một vùng tiến trình then chốt, giúp đánh giá hiệu quả thực hiện của tổ chức hoặc dự án Chúng cụ thể hóa phạm vi, ranh giới và mục đích của từng vùng tiến trình then chốt Sự thỏa mãn một vùng tiến trình then chốt (KPA) được xác định dựa trên việc đạt được các mục tiêu này.

Các đặc điểm chung

Để thuận tiện, các thực hành mô tả các vùng tiến trình then chốt được tổ chức thành các đặc tính chung, cho thấy hiệu quả, tính lặp lại và khả năng kéo dài của sự thi hành và kết hợp Có năm đặc điểm chung cần lưu ý.

Cam kết thực hiện các hành động cần thiết giúp tổ chức đảm bảo rằng tiến trình đã được thiết lập sẽ bền vững theo thời gian Điều này thường liên quan đến việc ban hành các chính sách ở cấp độ tổ chức và đạt được sự đồng thuận từ các cấp quản lý cao.

Để thực hiện sự cạnh tranh trong tiến trình phần mềm, tổ chức hoặc dự án cần đáp ứng các điều kiện ban đầu quan trọng Những điều kiện này bao gồm việc đảm bảo đủ nguồn lực, thiết lập cấu trúc tổ chức hợp lý và cung cấp đào tạo cần thiết cho nhân viên.

Các hoạt động được thực hiện

Các hoạt động trong quá trình thi hành vùng tiến trình then chốt bao gồm việc lập kế hoạch, thực hiện công việc, kiểm soát và thực hiện các biện pháp phòng ngừa khi cần thiết Đo đạc và phân tích là hai bước quan trọng, yêu cầu việc đo lường và phân tích số liệu để đánh giá tình trạng và hiệu quả của các hoạt động Những số liệu này cung cấp thông tin cần thiết để đưa ra quyết định chính xác về tiến trình.

Xác nhận là quá trình quan trọng nhằm đảm bảo các hành động thực hiện đúng theo tiến trình đã được thiết lập Điều này bao gồm việc xem xét và kiểm toán từ phía quản lý cũng như sự tham gia của nhóm đảm bảo chất lượng phần mềm.

Các thực hành trong đặc điểm chung “Các hoạt động được thực hiện” xác định những yêu cầu cần thiết để thiết lập khả năng tiến trình Những thực hành này, khi được thực hiện đồng bộ, tạo thành một nền tảng vững chắc giúp tổ chức kết hợp hiệu quả các hoạt động đã được mô tả.

Các thực hành then chốt

Mỗi vùng tiến trình then chốt được xác định qua các thực hành then chốt, góp phần đạt được các mục tiêu đề ra Các thực hành này không chỉ mô tả cấu trúc hạ tầng mà còn bao gồm các hoạt động thiết yếu, giúp thực hiện và kết hợp hiệu quả các vùng tiến trình then chốt.

Các thực hành then chốt bao gồm một câu đơn và giải thích chi tiết, thường kèm theo ví dụ Chúng chỉ ra các chính sách, thủ tục và hoạt động cho một vùng tiến trình then chốt, với các thành phần giải thích được gọi là thực hành con Mặc dù các thực hành then chốt mô tả những gì cần thực hiện, chúng không chỉ rõ cách đạt được mục tiêu Các thực hành thay thế cũng có thể phục vụ mục đích tương tự Thực hành then chốt có thể được đánh giá để xem xét hiệu quả của mục tiêu, mặc dù có thể đạt được bằng những cách khác Thông tin chi tiết về các thực hành then chốt có thể được tìm thấy trong cuốn sách “Các thực hành then chốt trong mô hình trưởng thành năng lực, phiên bản 1.1”.

Tương lai của CMM

Việc đạt được sự trưởng thành cao hơn trong quy trình phần mềm đòi hỏi sự phát triển liên tục và cam kết lâu dài cho cải tiến quy trình Các tổ chức phần mềm thường cần đến 10 năm hoặc lâu hơn để xây dựng nền tảng cho sự cải tiến quy trình theo hướng văn hóa Mặc dù chương trình cải tiến quy trình kéo dài một thập kỷ chủ yếu áp dụng cho các công ty Mỹ, nhưng nỗ lực này là cần thiết để hình thành các tổ chức phần mềm trưởng thành.

CMM không phải là giải pháp toàn diện cho mọi vấn đề trong dự án, vì nó không đề cập đến năng lực chuyên gia trong lĩnh vực ứng dụng cụ thể, hỗ trợ các công nghệ phần mềm đặc thù, hoặc cung cấp hướng dẫn về cách tuyển dụng, động viên và giữ chân nhân tài Mặc dù những yếu tố này rất quan trọng cho thành công của dự án, chúng vẫn chưa được tích hợp vào CMM.

Trong những năm tới, CMM sẽ tiếp tục được kiểm thử toàn diện để áp dụng trong đánh giá tiến trình phần mềm, năng lực phần mềm và các chương trình cải tiến Các sản phẩm và chương trình đào tạo phát triển từ CMM sẽ được điều chỉnh phù hợp CMM được coi là một tài liệu sống có khả năng cải tiến, nhưng dự kiến phiên bản 1.1 sẽ là nền tảng cho đến ít nhất năm 1996.

Cuốn sách về CMM đang được biên soạn cho loạt sách của SEI, được xuất bản bởi Addison – Wesley, cung cấp một sự cân bằng thực tế giữa nhu cầu ổn định và sự trưởng thành liên tục.

SEI đang hợp tác với tổ chức chuẩn hóa quốc tế ISO để xây dựng các chuẩn quốc tế cho việc đánh giá tiến trình phần mềm và cải thiện khả năng Nỗ lực này sẽ tích hợp nhiều khái niệm từ các phương thức cải tiến tiến trình khác nhau Sự phát triển của các chuẩn ISO và các đóng góp từ các phương thức khác sẽ ảnh hưởng đến phiên bản 2.0 của CMM, đồng thời các hoạt động của SEI cũng sẽ tác động đến các hoạt động của ISO.

Tiến trình sử dụng lại được và các mức tăng trưởng của nó trong một tổ chức (RMM) 30 1 Tổng quan

Khía cạnh hiện nay: Kỹ nghệ tiến trình

Hiện nay, "Khủng hoảng phần mềm" đang đặt ra thách thức lớn trong lĩnh vực kỹ nghệ phần mềm, với sự tập trung vào các tiến trình và việc áp dụng thủ tục, kỹ thuật cùng công cụ Mặc dù đã có nhiều nỗ lực để giải quyết các vấn đề này, nhưng kết quả vẫn chưa đạt được như mong đợi Đồng thời, sự phát triển nhanh chóng của công nghệ, công cụ phát triển phần mềm và phần cứng phức tạp yêu cầu một tổ chức hợp lý hơn trong các tiến trình phần mềm trong kỹ nghệ hệ thống.

Một tiến trình được định nghĩa là sự kết hợp giữa con người, các thủ tục, phương pháp, thiết bị và công cụ nhằm tạo ra kết quả mong muốn.

Tổ chức ISO vừa công bố chuẩn “Tiến trình vòng đời phần mềm”, định nghĩa tất cả các tiến trình liên quan trong vòng đời phần mềm Bên cạnh đó, ISO cũng giới thiệu chuẩn “Đánh giá tiến trình phần mềm” nhằm cung cấp cơ sở đánh giá các tiến trình này Mục tiêu của chuẩn này là khuyến khích văn hóa cải tiến liên tục thông qua kỹ nghệ tiến trình, giúp tổ chức đáp ứng tốt hơn các yêu cầu kinh doanh.

SEI đã phát triển mô hình CMM, một công cụ quan trọng trong việc đánh giá kỹ nghệ tiến trình Mô hình này giúp xác định mức trưởng thành của tổ chức, từ đó đánh giá chất lượng, năng suất và rủi ro, những yếu tố quyết định sự thành công của các dự án công nghệ thông tin.

Cộng đồng Châu Âu (EC) đã có những bước tiến đáng kể thông qua các dự án như ESPRIT và ACTS, nhằm nâng cao năng suất bằng cách tái sử dụng các thành phần phần mềm như EUROWARE, REBOOT, RECYCLE, SCALE và ROBUST.

Mặc dù có nhiều nghiên cứu về tái sử dụng trong lĩnh vực công nghệ, nhưng không có nghiên cứu nào từ Châu Âu (ngoại trừ REBOOT) hay các công việc của tổ chức quốc tế ISO trong kỹ nghệ tiến trình, cũng như mô hình CMM của SEI, xem tái sử dụng như một tiến trình chính thức.

Chúng tôi ủng hộ việc tái sử dụng tiến trình và các tác giả đã đề xuất nhiều mô hình khác nhau để mở rộng khả năng tái sử dụng trong tổ chức Đặc biệt, các đề xuất của Koltun và Hudson, trình bày tại Hội nghị nâng cao năng suất phần mềm, rất có giá trị và đã được áp dụng trong dự án UE mang tên REBOOT (Reuse Based on Object Oriented Techniques).

Mô hình chính xác nhất trong việc quyết định các hành động cần thực hiện là mô hình của Koltun và Hudson, mặc dù tất cả các mô hình đều mang tính chung chung Mô hình này định nghĩa 5 mức trưởng thành để tái sử dụng.

1 Khởi đầu lộn xộn (Initial Chaotic)

4 Được lên kế hoạch (Planned)

Các tiêu chí đánh giá mức trưởng thành trong tổ chức bao gồm động lực thúc đẩy, kế hoạch tái sử dụng, sự rộng rãi trong tái sử dụng, trách nhiệm trong việc thực hiện tái sử dụng, tiến trình phân cấp tái sử dụng, kiểm kê tái sử dụng, hoạt động phân lớp, hỗ trợ kỹ thuật, các ma trận đánh giá và các vấn đề pháp lý liên quan.

Mô hình tăng trưởng tái sử dụng (RMM)

Mô hình tăng trưởng tái sử dụng giúp xác định mức độ tăng trưởng mà tổ chức có thể đạt được thông qua tái sử dụng Mô hình này bao gồm ba yếu tố tái sử dụng, mỗi yếu tố được xác định bởi một tập hợp các hành động cụ thể Mỗi hành động này là một đơn vị đo lường quan trọng để đánh giá mức độ tái sử dụng hiện có của tổ chức.

Trong mô hình RMM, việc tái sử dụng trong tổ chức cần được xem xét độc lập với khả năng thực hiện dự án cụ thể Tuy nhiên, mức độ tái sử dụng qua các dự án có thể là tiêu chí quan trọng để đánh giá sự phát triển của tổ chức Để xác định mức độ trưởng thành của một tổ chức, các yếu tố như cấu trúc kỹ thuật, kiến trúc phần mềm và quản lý tổ chức thường được xem xét.

Các nhân tố tái sử dụng

Cấu trúc của mô hình này dựa trên việc giám sát ba nhân tố tái sử dụng khác nhau

-Cấu trúc kho lưu trữ

-Kiến trúc phát triển phần mềm

Mỗi một nhân tố bao gồm một phần nhất định của môi trường tái sử dụng, bao trùm các vùng điều khiển sau:

Một trong những yêu cầu quan trọng để tái sử dụng phần mềm là có một kho lưu trữ thông tin có thể tái sử dụng Để đạt được điều này, cần có một cấu trúc biểu diễn thông tin cho phép phân loại và khôi phục trong tương lai, bao gồm các lĩnh vực như Lập trình, Thiết kế, Phân tích, Kiểm thử, Lập tài liệu và Quản lý dự án Việc đánh giá cấu trúc lưu trữ hiện tại của tổ chức không có nghĩa là tất cả các thành phần có thể lưu trữ đều hoàn toàn tái sử dụng Do đó, cấu trúc lưu trữ cần được xem xét độc lập với kiến trúc phát triển.

 Sự phân lớp và kỹ thuật khôi phục

Phân lớp và kỹ thuật khôi phục là nền tảng quan trọng cho việc tái sử dụng thông tin Việc đánh chỉ số thông tin có thể thực hiện thủ công hoặc tự động, nhưng thường thiếu sự hỗ trợ chuyên nghiệp Đối với khôi phục, cần chú ý đến việc khôi phục thuộc tính trực tiếp và tài liệu hóa các khái niệm liên quan.

Quản lý và công cụ tự động đóng vai trò quan trọng trong việc cấp phép, loại bỏ và thay đổi các thành phần trong kho lưu Cần xem xét khả năng thực hiện các quy trình này để đảm bảo tính hiệu quả Đồng thời, việc áp dụng các kỹ thuật thông báo tự động giúp thông báo về sự hợp nhất hoặc thay đổi các thành phần mới, đặc biệt trong môi trường làm việc nhóm (Groupware).

2 Kiến trúc phát triển phần mềm

Ý tưởng đánh giá kiến trúc phần mềm dựa trên khả năng tái sử dụng Các phương pháp như hướng đối tượng, hướng sự kiện và các kỹ thuật cấu trúc như ống và lọc đều được áp dụng trong lĩnh vực này Tuy nhiên, với sự phát triển mạnh mẽ của phương pháp giao diện người dùng (GUI), khía cạnh tái sử dụng trong kiến trúc phần mềm cũng cần được xem xét kỹ lưỡng.

Tái sử dụng các yếu tố trong dự án phần mềm, như phân tích, thiết kế và mã nguồn, được thực hiện một cách hệ thống bởi tổ chức hoặc dự án cụ thể Mặc dù mối quan hệ giữa việc tái sử dụng và thông tin trong vùng lưu trữ có thể được đánh giá độc lập, việc tích hợp các thành phần tái sử dụng không nhất thiết phải phụ thuộc vào kho lưu trữ Điều này có thể xảy ra khi kỹ sư phần mềm áp dụng lại các yếu tố từ các dự án trước đó vì nhiều lý do khác nhau.

Kiểm thử thành phần là quá trình quan trọng trong phát triển phần mềm, đặc biệt khi phần mềm được thiết kế để tái sử dụng Để đảm bảo hiệu quả, cấu trúc kiểm thử cần được xác định phù hợp với các yêu cầu của phần mềm tái sử dụng, nhằm tối ưu hóa khả năng và tính linh hoạt trong việc áp dụng lại các thành phần phần mềm.

Có ba khía cạnh khác nhau được đề cập đến:

Các khía cạnh hành chính của tái sử dụng đóng vai trò quan trọng trong việc tối ưu hóa nguồn nhân lực, từ đó nâng cao hiệu quả của tiến trình hoàn thiện.

 Động cơ thúc đẩy và kế hoạch để đạt được tái sử dụng

Mức độ tái sử dụng trong các dự án trước đây phụ thuộc vào chiều dài và mức độ cải tiến đạt được từ nỗ lực của dự án.

Các hoạt động tái sử dụng

Mỗi nhân tố tái sử dụng bao gồm một tập hợp các hành động cần được quản lý Mức độ trưởng thành của tổ chức và mức độ tái sử dụng của dự án sẽ quyết định các hành động phù hợp được chấp nhận.

1-1 Cách thể hiện thông tin 3 điểm

1.1.1 Cấu trúc lưu trữ để lưu trữ các thành phần mã nguồn 0.5 1.1.2 Cấu trúc lưu trữ để lưu trữ các thành phần giao diện người dùng 0.5 1.1.3 Cấu trúc lưu trữ để lưu trữ các thành phần mã thực thi được 0.5 1.1.4 Cấu trúc lưu trữ để lưu trữ các thành phần phân tích & thiết kế 0.5 1.1.5 Cấu trúc lưu trữ để lưu trữ các thành phần tài liệu 0.5 1.1.6 Cấu trúc lưu trữ để lưu trữ các thành phần quản lý dự án 0.5

1-2 Các kỹ thuật phân lớp và khôi phục 3 điểm

1.2.1 Đánh chỉ số các thành phần bằng tay và nhóm phân lớp 0.5 1.2.2 Khôi phục các thành phần thông qua việc nhận biết các thuộc tính 0.5 1.2.3 Tự động đánh chỉ số các thành phần mà chấp nhận sửa mã 0.5 1.2.4 Tự động đánh chỉ số các thành phần nhị phân 0.5 1.2.5 Tự động đánh chỉ số các thành phần thiết kế, phân tích, lập tài liệu và quản lý dự án

1.2.6 Khôi phục các thành phần bằng việc hỏi có tài liệu 0.5

1-3 Các công cụ quản lý và tự động 3 điểm

1.3.1 Xác thực hệ thống, từ chối và thay đổi các thành phần 0.6 1.3.2 Sự tồn tại của môđun tính toán thống kê trên tái sử dụng thành phần

1.3.3 Tự động thông báo khi các thành phần được tích hợp hay thay đổi

1.3.4 Các kỹ thuật cho việc tạo tự động kho lưu từ các dự án trước 0.6 1.3.5 Các kỹ thuật tích hợp tự động các thành phần trong các dự án mới

Mô tả các hoạt động:

1.1.1 - Cấu trúc lưu trữ để lưu trữ các thành phần mã nguồn

Cấu trúc không chỉ lưu trữ thuộc tính mô tả qua mã nguồn mà còn chứa cả mã Sự kết hợp của các thành phần khác nhau trong kho lưu trữ cần được định nghĩa rõ ràng thông qua các quy tắc nhất định của phương pháp luận áp dụng.

1.1.2 - Cấu trúc lưu trữ để lưu trữ các thành phần giao diện người dùng

Kết luận

Tái sử dụng cần được tiếp cận bằng cách tập trung vào tiến trình thực hiện Một tổ chức muốn thực hiện tái sử dụng phải định nghĩa rõ ràng quy trình của mình, từ đó nâng cao năng suất và chất lượng sản phẩm Điều này sẽ giúp đạt được các mức tăng trưởng tái sử dụng liên tục trong tổ chức.

Tiến trình tái sử dụng không chỉ cần được định nghĩa rõ ràng mà còn phải có phương thức để đánh giá tình trạng của nó Điều này bao gồm việc sử dụng kết quả đánh giá như một phần thiết yếu trong việc cải tiến tiến trình một cách liên tục và hiệu quả.

Trong bài viết này, tiến trình tái sử dụng được xác định qua ba nhóm nhân tố tái sử dụng, dựa trên cách thực hiện và phương pháp tái sử dụng Mỗi nhóm hành động này giúp đánh giá mức độ trưởng thành của tổ chức trong việc áp dụng các giá trị tái sử dụng hiệu quả.

Phân tích các hành động tái sử dụng giúp xác định những điểm chưa đạt giá trị tối ưu và các mục tiêu của tổ chức Từ đó, tổ chức có thể quyết định những cải tiến cần thiết để nâng cao hiệu quả trong quá trình tái sử dụng.

Một khía cạnh quan trọng của mô hình tái sử dụng được đề xuất (RMM) là khả năng xác định mức độ tái sử dụng đạt được trong từng dự án Điều này diễn ra độc lập với mức độ trưởng thành tái sử dụng của tổ chức, giúp đánh giá hiệu quả tái sử dụng trong các dự án cụ thể.

Áp dụng CMM, RMM vào hoạt động thực tiễn sản xuất phần mềm tại công ty CT-IN 47 1 Giới thiệu

Chi tiết các vùng thực hành then chốt

Ngày: 12-Apr-04 Tình trạng: Static

THÔNG TIN VỀ TÀI LIỆU

Người xem xét Người phê duyệt

Danh sách phân bổ tài liệu:

Tài liệu này được gửi bằng Email tới những người sau đây vào ngày Quản lý dự án

STT Ngày Vị trí sửa đổi Nội dung sửa Người sửa Người xem xét

1 02-02-05 Tạo tiến trình Nguyen Hoai

4 Phân tích và xác định yêu cầu 51

5 Quản lý khả năng lần vết (traceability) 53

7 Các tài liệu liên quan 53

Chính sách quản lý yêu cầu của CT-IN như sau:

1 Các yêu cầu cho mỗi dự án phần mềm phải được lưu trữ dưới dạng tài liệu Yêu cầu phải được quản lý một cách chính thống trong vòng đời của dự án

2 Các yêu cầu phải được xem xét bởi người quản lý dự án (PM), trưởng nhóm kỹ thuật, trưởng nhóm kiểm tra và các nhóm khác liên quan

3 Khi có một sự thay đổi yêu cầu phần mềm được thông qua, các kế hoạch phát triển phần mềm, các sản phẩm công việc, các mục cấu hình và các hoạt động khác phải được thay đổi tương ứng

Quá trình quản lý yêu cầu là một phần quan trọng trong tất cả các dự án phần mềm tại CT-IN, bao gồm cả dự án cho khách hàng và dự án nội bộ Người quản lý dự án có quyền quyết định không áp dụng toàn bộ hoặc một phần của quá trình này, nhưng cần phải thông báo rõ ràng với bộ phận QA và COO để đảm bảo sự minh bạch và hiệu quả trong quản lý dự án.

SDP Software Development Plan (Kế hoạch phát triển phần mềm) SQAP Software Quality Assurance Plan (Kế hoạch đảm báo chất lượng phần mềm)

PM Project Manager (Người quản lý dự án) COO Chief Operating Officer (Giám đốc điều hành)

TP Test Plan (Kế hoạch kiểm thử)

TC Test Case (Ca kiểm thử)

TL Test Lead (Trưởng nhóm kiểm thử) QAO Quality Assurance Officer (Nhân viên đảm bảo chất lượng phần mềm)

UC Use Case (Ca sử dụng) SRS Software Requirement Specification (Đặc tả yêu cầu phần mềm)

BA Business Analyst (Phân tích yêu cầu kinh doanh)

4 Phân tích và xác định yêu cầu

Prepare Gather/elicit requirements Analyze

Prepare SRS and acceptance criteria

4.1.1 Chuẩn bị cho việc thu thập và phân tích yêu cầu

Bước này bao gồm các hoạt động sau đây:

 Chuẩn bị căn bản về kỹ thuật/các khái niệm thương mại và đào tạo

 Làm quen với phương pháp luận của khách hàng và các công cụ sử dụng

 Đưa ra phương pháp để lấy thông tin

 Chuẩn bị câu hỏi để lấy thông tin

 Xác định nhóm người để phỏng vấn

 Chuẩn bị kế hoạch tạo mẫu

 Định nghĩa các chuẩn xác định yêu cầu

 Đưa ra kế hoạch phỏng vấn và lấy phê duyệt từ khách hàng

Bước này bao gồm các hoạt động sau đây:

 Đưa ra mục đích và phạm vi của hệ thống

 Chuẩn bị danh sách các tính năng hệ thống

 Thu thập các yêu cầu chức năng

 Thu thập các thông tin về các giao diện tương tác

 Thu thập yêu cầu về môi trường hoạt động

 Thu thập yêu cầu về hiệu năng

 Thu thập các yêu cầu về chuẩn

 Thu thập các yêu cầu người dùng đặc biệt

Chuẩn bị danh sách các tính năng theo mẫu sau:

PM giao nhiệm vụ cho một cá nhân chịu trách nhiệm phân tích yêu cầu hệ thống, từ đó ánh xạ chúng sang các thành phần cấu hình phần cứng, phần mềm và các yếu tố hệ thống khác.

 PM phản ánh những thông tin trên trong tài liệu kế hoạch phát triển phần mềm

4.1.4 Chuẩn bị các tài liệu đặc tả yêu cầu và các yêu cầu về chấp thuận của người sử dụng

Trong hoạt động này CT-IN tuân theo Rational Unified Process trừ khi khách hàng yêu cầu một chuẩn khác

Chuyên viên phân tích thương mại được chỉ định sẽ phải:

 Quản lý và lập tài liệu các yêu cầu hệ thống và sự ánh xạ chúng (trong, ngoài phạm vi) xuyên suốt vòng đời của dự án

 Quản lý các thay đổi đối với các yêu cầu hệ thống và sự tương quan chúng

Sau đây là các mẫu tài liệu để chuẩn bị đặc tả yêu cầu phần mềm

Mỗi một UC yêu cầu cần có một số thứ tự đi kèm: UCxx trong đó xx là một số nằm giữa 01 và 999

4.1.5 Xem xét các đặc tả yêu cầu và các yêu cầu chấp thuận người dùng

Người quản lý dự án và trưởng nhóm kiểm tra sẽ đánh giá các yêu cầu và tiêu chuẩn chấp nhận, đồng thời điều chỉnh tài liệu đặc tả yêu cầu khi cần thiết.

PM sẽ xem xét tất cả các yêu cầu sử dụng (UC) trước khi chuyển giao cho đội phát triển, nhằm đảm bảo rằng tất cả các chi tiết cần thiết đã được chỉ ra Thông thường, quy trình này được thực hiện trong buổi họp dự án hàng tuần.

PM đảm bảo rằng TL và người thiết kế giao diện đã xem xét các yêu cầu và có khả năng thực hiện công việc dựa trên các Ucs.

4.1.6 Lấy chữ ký khách hàng cho yêu cầu

5 Quản lý khả năng lần vết (traceability)

Các thành phần yêu cầu cần được ánh xạ một cách rõ ràng sang các thành phần thiết kế, sau đó từ các thành phần thiết kế chuyển đổi thành mã lập trình, và cuối cùng từ mã lập trình đến các test cases.

Ánh xạ trong ma trận vết cần được duy trì và có thể được điều chỉnh để phù hợp với các yêu cầu đa dạng của dự án Người quản lý dự án có trách nhiệm trong việc quản lý và cập nhật ma trận này.

Lưu ý rằng nếu các Use Cases (UCs) không được sử dụng để mô tả hệ thống, tài liệu yêu cầu cần được tổ chức thành các chức năng riêng biệt, với mỗi chức năng được gán một số thứ tự cụ thể.

Mẫu ma trận vết được sử dụng tại CT-IN như sau: requirement_ traceability_matrix_template.doc

Tham khảo ctin_cmm_roles.doc

7 Các tài liệu liên quan

Các mẫu và tài liệu liên quan đối với tiến trình này:

 requirement_traceability_matrix_template.xls

Quy trình phát triển kế hoạch dự án phần mềm

THÔNG TIN TẦI LIỆU Bảng cập nhật:

Danh sách phân bổ tài liệu:

Phân bổ bằng Email đến những thành viên sau vào thời gian COO

STT Ngày Vị trí sửa đổi Nội dung sửa Người sửa Người xem xét

1 02-02-05 Tạo quy trình Nguyen Hoai

2 Quy trình lên kế hoạch cho dự án 57

3 Quản lý các dự trù nhân công 58

4.3 Hướng dẫn việc sắp xếp độ ưu tiên 60

5 Ban quản lý dự án 60

5.1 Ban quản lý dự án 60

5.2 Các hoạt động của ban quản lý dự án 61

7 Các tài liệu liên quan 61

Chính sách của CT-IN trong việc lên kế hoạch phát triển phần mềm như sau:

1 Các yêu cầu đối với phần mềm sẽ được sử dụng cơ bản cho việc lên kế hoạch dự án phần mềm

2 Các cam kết trong một dự án phần mềm phải được sự đồng thuận giữa: a Project manager b CTO / COO c Và các phòng ban khác (nếu có ảnh hưởng): Test Lead, QA Officer, Business Analyst and Designer

3 Sự liên quan của các nhóm kỹ thuật khác trong các hoạt động phần mềm phải được sự đồng thuận giữa các nhóm này và phải được lập tài liệu, ví dụ các nhóm kỹ thuật khác sau đây: d Nhóm phát triển phần mềm e Phòng IT f Phòng kiểm tra

4 Các nhóm liên quan sẽ xem xét các ước lượng cho dự án phần mềm, các kế hoạch và các cam kết khác như ước lượng kích cỡ, ước lượng về nhân công và về giá và các kế hoạch lên lịch

5 Bộ phận quản lý cấp cao sẽ xem xét các cam kết phần mềm chính yếu ảnh hưởng đến các cá nhân, các nhóm bên ngoài tổ chức của họ Bộ phận quản lý mức thấp hơn sẽ xem xét tất cả các cam kết dự án có liên quan đến các các nhân và các nhóm bên ngoài tổ chức

6 Mỗi bản kế hoạch phát triển phần mềm phải được quản lý chặt chẽ

2 Quy trình lên kế hoạch cho dự án

2.2 Xác định định nghĩa dự án Định nghĩa dự án được xác định bằng cách chỉ ra những mục sau trong kế hoạch phát triển phần mềm:

 Thông tin về khách hàng như những người liên quan, thông tin liên hệ

 Ban quản lý dự án

 Phạm vi của dự án

 Dự án trong ngữ cảnh tương tác với các hệ thống khác

 Các rủi ro – Rủi ro phát sinh theo một thủ tục được lập tài liệu Xem mục 4 Quản lý rủi ro

Tổng quan về mặt kỹ thuật bao gồm các phương pháp phát triển phần mềm, công cụ phát triển cần thiết, máy chủ sử dụng, nguồn lực máy tính có sẵn, yêu cầu về cơ sở hạ tầng và chiến lược triển khai hiệu quả.

2.3 Lên kế hoạch thực hiện dự án

Việc thực hiện dự án được lên kế hoạch dựa trên những mục sau đây:

 Các đầu ra bàn giao được cho khách hàng

 Phát triển kế hoạch dự án

 Xác định các mốc (milestones) – Chúng sẽ được sử dụng trong các báo cáo tuần

 Kế hoạch sử dụng nguồn nhân lực

Xây dựng công cụ trợ giúp quản lý tiến trình 87 1 Giới thiệu

Mô tả phần mềm

Dưới đây là màn hình chính của phần mềm được nhìn từ Notes Client và từ trình duyệt Web

Hình 4.1 Màn hình chương trình nhìn từ Notes Client

Hình 4.2 Giao diện chương trình nhìn từ Web Browser

Khi bắt đầu một dự án mới, người quản lý dự án phải xây dựng cấu trúc dự án như sau:

TIEU LUAN MOI download : skknchat@gmail.com

Giao diện mục “General Information” cung cấp thông tin tổng quan, trong khi mục “Contact Information” và “Account Configuration” cho phép nhập dữ liệu liên quan đến các thành phần tham gia dự án từ cả CT-IN và phía khách hàng.

Sau khi nhập thông tin chung về dự án, người quản lý dự án sẽ tiến hành xây dựng các giai đoạn thực hiện và xác định các tác vụ cần thiết trong từng giai đoạn.

Các thông tin trong mục “Schedule Information” cho phép cập nhật các thông tin liên quan đến kế hoạch thực hiện tác vụ

Mục “Assignment Information” cho phép cập nhật những cá nhân sẽ thực hiện tác vụ đó

Mục “Quality Assurance” cho phép quản lý các thông tin chất lượng của tác vụ

Mục “Output Document” giúp quản lý các tài liệu đầu ra từ các tác vụ, bao gồm các tài liệu kết quả của các giai đoạn trong mô hình CMM như yêu cầu, thiết kế và kiểm thử.

Trong quá trình thực hiện dự án, người quản lý dự án cần cập nhật thông tin chi tiết về các tác vụ, bao gồm trạng thái hiện tại, thời gian thực tế thực hiện (bắt đầu và kết thúc) và các tài liệu đầu ra liên quan đến từng tác vụ.

Khách hàng truy cập vào công cụ này qua Web Browser, và chọn dự án cần theo dõi

Tiến độ dự án được biểu thị qua màu sắc của các tác vụ: màu hồng cho biết tác vụ đang được thực hiện, màu vàng đại diện cho tác vụ mới, và màu trắng thể hiện tác vụ đã hoàn thành.

Khi vào chi tiết từng tác vụ, khách hàng có thể theo dõi các thông tin chi tiết cùng với các tài liệu đi kèm

Khách hàng có thể download các tài liệu hay những phần bàn giao của CT-IN cho khách hàng ở đây

Khách hàng cũng có thể nhập comment cho các tác vụ nếu có ý kiến gì thông qua liên kết “Add Comment”

Trong mục “Project Information”, khách hàng sẽ thấy được những thông tin tổng hợp của dự án.

Nhận xét

Phần mềm của CT-IN đã đáp ứng hiệu quả nhu cầu của khách hàng trong quản lý sản xuất Giao diện thân thiện, dễ sử dụng, cho phép khách hàng truy cập từ xa qua Internet một cách thuận tiện.

Trong thời gian tới, chúng tôi sẽ nâng cấp phần mềm bằng cách tích hợp các chức năng chuyên biệt như quản lý yêu cầu, quản lý defects, và quản lý thời gian làm việc Bên cạnh đó, chúng tôi cũng sẽ xây dựng các báo cáo tổng hợp về dự án nhằm phù hợp hơn với môi trường gia công phần mềm tại CT-IN.

Mô hình CMM cho phần mềm, được phát triển bởi Viện Kỹ nghệ Phần mềm (SEI) của Đại học Carnegie Mellon, đã nhận được sự hỗ trợ quốc tế và cung cấp chương trình tài trợ không hoàn lại cho các công ty muốn áp dụng Mô hình này mô tả các nguyên tắc và thực tiễn liên quan đến sự "thành thục" trong quy trình phát triển phần mềm, nhằm giúp các công ty cải thiện khả năng quản lý quy trình sản xuất phần mềm, từ trạng thái tự phát và hỗn độn đến các quy trình có kỷ luật và thành thục hơn.

Việc thực hiện CMM mang lại cho các công ty nhiều lợi ích, giúp giảm rủi ro trong phát triển phần mềm và tăng tính khả báo, từ đó trở thành đối tác hấp dẫn hơn với khách hàng toàn cầu Tuy nhiên, CMM yêu cầu đầu tư đáng kể về nguồn lực để đạt được các mức chứng nhận Mô hình này có năm mức độ thành thục, từ mức 1 thấp nhất đến mức 5 cao nhất Gần đây, SEI đã giới thiệu CMMi như một mô hình kế thừa, và nhiều công ty đang bắt đầu áp dụng nó Để triển khai hiệu quả mô hình SW-CMM, cần thiết phải nâng cao kiến thức về CMM và phát triển các công cụ hỗ trợ áp dụng từ mức thấp đến cao.

Trên thế giới, có nhiều công cụ hỗ trợ phát triển phần mềm, nhưng phần lớn chỉ tập trung vào một số lĩnh vực cụ thể như quản lý lỗi, quản lý kế hoạch dự án và quản lý yêu cầu Mỗi lĩnh vực này, khi được phân tích chi tiết, đều cho thấy sự phức tạp riêng của nó.

Hầu như không có phần mềm nào đáp ứng đầy đủ các yêu cầu của SW-CMM trong quá trình phát triển phần mềm Thêm vào đó, số lượng phần mềm hỗ trợ phân tích và đánh giá dữ liệu thực hiện dự án nhằm đảm bảo chất lượng và cải tiến quy trình tổ chức cũng rất hạn chế.

Trong luận văn này, tôi đã phân tích các vấn đề liên quan đến CMM và RMM, từ đó xác định các vùng tiến trình then chốt áp dụng tại công ty CT-IN Công ty đã phát triển một công cụ quản lý đáp ứng yêu cầu gia công phần mềm theo chuẩn CMM Tuy nhiên, để đạt được các mức trưởng thành cao hơn (Mức 4, Mức 5), CT-IN còn nhiều việc cần thực hiện.

Trong thời gian tới, tôi sẽ áp dụng chặt chẽ các quy trình đã xây dựng vào các dự án cụ thể tại CT-IN, nhằm rút ra kinh nghiệm cải tiến quy trình và hoàn thiện quy trình phát triển phần mềm Bên cạnh đó, công cụ quản lý sẽ được bổ sung các tính năng quản lý quy trình và xây dựng báo cáo để kiểm soát mức độ trưởng thành qua các dự án, hỗ trợ hiệu quả hơn cho hoạt động sản xuất phần mềm tại công ty.

[1] Mark C Paulk, Charles V Weber, Suzanne M Garcia, Mary Beth Chrissis, Marilyn Bush, Key Practices of the Capablity Maturity Model, Carnegie Mellon University, 1993

[2] J Llorens Morillo, A Amescua Seco and V Martinez Orga, The Reuse Process and its Maturity Level in an Organization: RMM, Carlos III University of Madrid, 2000

[3] Capability Maturity Model for Software, Version 1.1 – Mark C Paul, Bill Curtis, Mary Beth Chrissis, Charles V Weber – Software Engineering Institute, CMU/SEI-93-TR-24, Carnegie Mellon University February, pp 1-41, 1993

[4] Watts S Humphrey, Managing Software Process , Addison-Wesley, pp 3-14, 1989

[5] CMM in practice: Processes for Executing Software Projects at Infosys , Pankaj Jalote, Addison-Wesley, pp.2-28, 1999

PHỤ LỤC: CÁC MẪU TÀI LIỆU ĐI KÈM

 software_development_plan_template.doc

DOCUMENT HISTORY AND INFORMATION Document Control:

Section Summary of Change Author Reviewer

1.1 Actor description 1.2 UC relating to actors

Section Summary of Change Author

5.1 Basic Flow - 105

5.2 Alternative Flow - 105

Enter brief description of the UC The description must enable 1/3 rd parties to understand what process/functionality the uc describes For example:

This use case outlines how the Call Handler utilizes the protocol after selecting the most suitable Chief Complaint (CC) to facilitate the loading of all relevant protocol modules based on Homeland Alert levels and caller variables By adhering to the procedures detailed in this use case, the Call Handler can make informed decisions regarding dispatch recommendations, ultimately enhancing the safety of both callers and responders.

Define who the primary actor is based on the actor list document

Define constraint(s) on the system when the use case may start

Define constraint(s) on the system when the use case has terminated

A textual description of what the system does in regard to the use case (not how specific problems are solved by the system) The description is understandable by the customer

5.1 Basic Flow -

1 The actor issues the command to load a Chief Complaint

5.2 Alternative Flow -

1 The actor issues the command to edit a Chief Complaint

A comprehensive textual description should encompass all requirements, including non-functional ones, related to the use case These requirements, often overlooked in the use-case model, are crucial for consideration during the design and implementation phases to ensure a successful outcome.

A list of locations within the flow of events of the use case at which additional behavior can be inserted using the extend-relationship feature_list_template

1 Purpose Error! Bookmark not defined

Introduction

This document outlines the features of , providing a brief description of each idea while assessing their relevance to the project's scope It serves as a vital resource for effective scope management.

Definitions from the Rational Unified Process

 Feature – An externally observable service provided by the system which directly fulfills a stakeholder need

Scope management involves prioritizing and defining the requirements that can be achieved in a specific release cycle, taking into account available resources and time This ongoing process adapts to changes throughout the project's lifecycle.

 Stakeholder – An individual who is materially affected by the outcome of the system

 Stakeholder need – The business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use

The Feature list consists of columns of information with the following headings and meanings

 Feature – A brief textual description of the feature

 Scope In – A tick indicates the feature will be included in the current release

 Scope Out – A tick indicates the feature has been considered and is outside the scope of the project

The feature is currently not included in the existing scope but is being evaluated for potential inclusion in a future release A numerical indicator, ranging from 1 to 3, suggests the estimated number of release cycles before the feature may become available, serving as a guideline If no specific release cycle has been determined and the feature has been deferred, a tick will be used to signify its postponed status for future consideration.

 Who – Initials of who made the decision (and the date) if outside the project team For example if the client has decided a feature must be within the

TIEU LUAN MOI download : skknchat@gmail.com scope of the current release his/her initials are used to indicate that information

For long feature lists several tables can be used with a category header

Feature Description I n Ou t Futur e Who (date) risk_list_template

This risk list highlights the potential threats to the success of the project name, prioritizing them based on their likelihood of causing significant negative outcomes It acts as a central reference for project activities and serves as the foundation for organizing iterations effectively.

This risk list will be applied to the entire project name

The risks know at the publication date of this document are listed below, together with Mitigation Strategies or Contingency Plan for each risk

Risk Ranking / Magnitude Risk Description & Impact Mitigation Strategy and/or Contingency

9 The development team is rather inexperienced with the RUP and OO Techniques This could lead to lower efficiency and poorer product quality

Schedule training RUP and OO techniques

Schedule Nam time to assist the team in the process and the development activities

9 The development team members do not believe that the project will succeed This could lead them to work inefficiently

Open a frank meeting to convince them that this project will be successful

8 The Elaboration deliverables may slip and not be available at Jun 23, 2003 – the start of Construction phase

Monitor progress against the schedule and milestone Make sure that the all task are in schedule

The project scope will be adaptable to meet new client requirements, but this flexibility may result in the specification of use cases being unclear, potentially causing delays in meeting project deadlines during the early elaboration phase before June 20.

TIEU LUAN MOI download : skknchat@gmail.com software_development_plan_temp late

1.5 Interface with other systems (existing and future) 117

1.7.1 Development method 117 1.7.2 Development Tools 117 1.7.3 Server, computer resources 117 1.7.4 Infrastructure Requirements 117 1.7.5 Implementation Strategy 118

3.1 Progress Reports and project review 122

4.1.1 Project specific Configuration Items 122 4.1.2 SCM deviations 123

This article provides a concise overview of the proposed project, outlining its key objectives and deliverables It highlights the project team responsible for its execution, the timeline for completion, and identifies the project's sponsor, ensuring readers have a clear understanding of the project's scope and goals.

This section must clearly outline the responsibilities and accountability each individual assumes when approving this document, indicating their endorsement of both the work's appropriateness and its importance to the business.

This section should give a brief overview the customer, the involved people, contact details and their responsibilities for this project (budget, functionality etc.)

This paragraph defines the boundary of the project by identifying what is within the scope of the project in terms of:

This section outlines the anticipated user base for the application and highlights any existing processes that will be altered due to its implementation It categorizes the project type, which may include new development, replacing an existing system, ongoing development, or an audit.

This paragraph defines what is specifically out of scope of the project and is used to avoid ambiguity and misinterpretation

For instance, the following will generally be out of scope unless specified otherwise:

 Providing system software and licenses

 Installation of system software (like Windows NT or SQL server)

 Extensive and specific training to technical staff of BP

1.5 Interface with other systems (existing and future)

Add a high level context diagram here to illustrate the boundaries of the system or refer to the Software Requirement Specification document

See software_project_planning_process.doc section 4

Internal and external factors can significantly influence a project's quality, cost, and timeline To mitigate these risks, it's essential to identify and classify them based on their potential impact—high, medium, or low—and their likelihood of occurrence—high, medium, or low This ongoing assessment is crucial, as new risks may emerge during the development process, even if they are not present at the project's outset At this early stage, risks should be outlined at a high level to ensure a proactive approach to project management.

There are 2 types of risks:

 Client risks – monitored in the weekly progress report, usually clients need to solve them

 Project risks – monitored via the risk list and are usually solved by CT-IN

Indicate whether the project will be developed using the waterfall, iterative method etc

Describe any development tools which will be used or required and how they will benefit the development of the project

Describe all server and computer resources required

This article outlines the essential infrastructure requirements necessary for implementing the proposal, emphasizing its effects on existing systems, including hardware, software, network traffic, and backup solutions It also highlights the need for operator intervention and the implications for floor space within the data center Furthermore, the discussion covers the technical skills required for support and the specific requirements for thorough testing to ensure a seamless integration and optimal performance.

The level of detail included in this section can vary depending on the level of analysis already carried out by the project team

This section should address the following:

 Production hand-over requirements, e.g operational procedures, application manual, etc

The constraints may be: time, budget, resources, business, technical, dependencies on other systems, many groups of users involved, etc

This section should address the following requirements for the maintenance phase of the project, i.e post implementation:

 Service Level Agreements, when will they be defined, who will agree them,

 Infrastructure Production support (Skills, Resources, Timing, etc), including ownership & necessary signoffs

 Other production support costs, license agreements, support contracts, hardware, software, backups, etc

 User regime, e.g housekeeping, management of user accounts, standing data maintenance, etc

When creating a project plan, it is crucial to acknowledge that estimates for activity durations and resource availability may become less accurate over time Nonetheless, determining the overall project duration and associated costs for each product is essential for obtaining initial approval To address this challenge, two levels of planning are utilized.

At this stage, it is essential to create detailed phase plans and estimates for the upcoming phase of the project life-cycle The project plan should also provide approximations for the schedule, resource needs, and estimates for other phases Each detailed phase plan must be developed just before the phase starts, elaborating on the activities outlined in the project plan with increased specificity.

This section should list the major deliverables of the project These should be the management and quality deliverables as well as the technical deliverables

 Documentation, e.g functional specifications, test specifications, user guides, etc

 Software, e.g application software, operating systems, proprietary packages, etc

Use MS project to make a Gantt chart which contains:

 a list of activities(use comments to give extra information about the activity) that are required to build the deliverables defined for the project

 the dates on which those activities will occur

 the dependencies between the activities are clearly identified

 major events (Milestones) in the project that are used for project reporting

 Includes testing effort estimates and milestones

If the Gantt chart becomes to big, make it an Appendix and print it landscape!

This section should contain a list of high level milestones in business language, which will be used in progress reporting

 Milestones are checkpoints throughout a project which ensure it is on course and which provide direction to the final objective

 Milestones state what to achieve - not how

 Milestones must be measurable - it must be clear when they have been reached

 Milestones should describe a condition or state through which the project must pass to reach the final objective

 Milestones should be robust to changing circumstances; a change in activities should not affect the milestone

 Milestones should be expressed in terms of independent activities which make the plan understandable to people without detailed knowledge of the activities

 Each milestone should have a single person responsible for ensuring the milestone is achieved

 Each milestone should have a person or a group of people who decide that the milestone is completed This will be very often the project manage

 Milestone dependencies must be identified

For instance, some possible milestones:

 Acceptance of design/Use case

 Acceptance of beta version / prototype

 Finish development / start system test

 Deliver complete system and documentation

The acceptance of the system marks a crucial milestone in project completion, as it signifies the hours required for finalizing the project after the system delivery This phase involves collaboration between the client and the project team to ensure all aspects are addressed effectively.

Clearly identifying external milestones is crucial, particularly when project milestones rely on them External milestones refer to those elements outside the project manager's direct control, such as tasks performed by other project teams, infrastructure developments, or activities conducted by external vendors and suppliers.

The successful execution of a project relies on a diverse team of professionals, including a Project Manager (PM), Supply Chain Management (SCM) officer, Software Quality Assurance (SQA) officer, Business Analyst (BA), Team Leader (TL), developers, testers, risk officer, interface designer, and database designer, among others Each role plays a crucial part in ensuring the project's infrastructure and quality standards are met, contributing to a cohesive and efficient workflow.

 The effort required from the resources split into weekly intervals(input for the resource sheet)

 Total effort required for the project

Name Role Week x Week x+1 Total Peter Project manager 23 34 57

(Also used for company resource sheet) NOTE: 2.3, 2.5, 2.4.1 & weekly progress report must all balance back

The effort has to be related to milestones or tasks, to make tracking possible

Project manager SCM Manager SQA Manager Programmer Tester

Project Identification

No need to include it here as it is already in the SDP

Requirement for test

The listing below identifies those itemsuse cases, functional requirements, and non-functional requirementsthat have been identified as targets for testing This list represents what will be tested

Test Strategy

 Data and Database Integrity Testing Test Objective:

 Business Cycle Testing Test Objective:

 User Interface Testing Test Objective:

 Security and Access Control Testing Test Objective:

 Failover and Recovery Testing Test Objective:

Environment Requirements

Ensure that all environmental requirements are communicated to the Project Manager for inclusion in the Project Software Development Plan (SDP) Avoid duplicating this information here, as it complicates the maintenance of project artifacts and can lead to inconsistencies.

Time estimates

An essential component of the Software Project Management Plan is the schedule for all required testing activities This plan outlines the timeline for when test cases will be written and testing will be executed Below is the estimated timeframe for both writing test cases and conducting testing.

Please inform PM as soon as the estimates are available so he can enter them in his schedule

Use cases/Functional name Write test cases

Resources and Responsibilities

Specify the responsibilities of the concerned people for the successful completion of the testing process

Define the test team in person (people that will directly perform tests), which can contain:

PM Responsible for project schedule that integrate development plan & testing plan schedules

Serve as primary contact between development team & test team

Test Lead Ensures the overall success of the test cycles, prepare Test

Plan Participate in test case creation Review test cases

Assign/review testers’ works according to Test Plan Testers Perform actual testing and output Test Report & bug reports

Test Deliverables

Ensure that the Project Manager is informed about all Test deliverables, which should not be detailed in this communication but will be included in the Software Development Plan (SDP) It is essential to provide the PM with an overview of the Test deliverables to maintain clarity and alignment in the project.

Tools

Inform the Project Manager of the necessary test tools you will require, but refrain from listing them here, as they should be documented in the Software Development Plan (SDP) It is essential to communicate the specific test tools to the PM for proper planning and resource allocation.

Test Suspension/Resumption Criteria

If significant defects are discovered that adversely affect the testing process, the Test Lead and Project Manager may decide to suspend testing Justifiable criteria for this suspension include the severity of the defects and their impact on test progress.

- Hardware/software is not available at the times indicated in the project schedule

- Source code contains one or more critical bugs, which seriously prevents or limits testing progress

- Assigned test resources are not available when needed by the test team

Testing will only resume once the issues that led to its suspension have been addressed In cases where a critical defect caused the suspension, the Test Lead must confirm that the defect has been resolved before testing can continue.

The Test Case document for outlines a series of test inputs, execution conditions, and expected outcomes designed to achieve specific objectives, such as validating program paths or ensuring compliance with requirements Its primary purpose is to identify and communicate the necessary conditions for successfully verifying the project's implementation.

Test cases reflect the requirements that are to be tested in the application during test Test cases are classified into several categories based on the business need (s)

Total of cases Passed (How many cases?) Failed (How many cases?) Not done (How many cases?) Not done reason:

Cases

No Description Test Input Expected Result Actual Result Screen shots:

No Description Test Input Expected Result Actual Result

3.9 Security and Access Control Testing

Định dạng
Số trang	146
Dung lượng	1,57 MB