tiến trình phần mềm là gì?
Quy trình công nghệ phần mềm có liên quan với các hoạt động công việc hoàn thành bởi các kỹ sư phần mềm để phát triển, duy trì và vận hành phần mềm, chẳng hạn như yêu cầu, thiết kế, xây dựng, thử nghiệm, quản lý cấu hình, và các quy trình công nghệ phần mềm khác. Để dễ hiểu, "quy trình công nghệ phần mềm" sẽ được gọi là "quy trình phần mềm". Quy trình phần mềm là một cấu trúc, bao gồm tập hợp các hoạt động cần thiết và các kết quả tương ứng, sử dụng trong việc phát triển, sản xuất ra một sản phẩm phần mềm. Quy trình phần mềm được đặc tả vì một số lý do: để tạo điều kiện cho sự hiểu biết của con người, thông tin liên lạc và phối hợp; để hỗ trợ quản lý dự án phần mềm; để đo lường và nâng cao chất lượng sản phẩm phần mềm một cách hiệu quả; để hỗ trợ quá trình cải tiến; và để cung cấp một cơ sở cho việc hỗ trợ tự động thực hiện quy trình. Định nghĩa đầy đủ về quy trình phần mềm bao gồm việc hỗ trợ thực hiện quy trình phần mềm Môi trường làm việc hỗ trợ việc thực hiện quy trình phần mềm. Đặc tả vai trò và năng lực mỗi đơn vị trong tổ chức. Có biện pháp đánh giá hiệu quả việc thực hiện quy trình phần mềm. Ví dụ bằng chỉ số KPI Quy trình phần mềm có thể mô tả bằng ngôn ngữ tự nhiên, hoặc bằng các công cụ như UML, BPMN; IDEF0 hoặc sơ đồ. 1.1 Quản lý quy trình phần mềm Quản lý quy trình phần mềm nhằm nhận ra hai mục tiêu: Nhận ra năng suất và hiệu quả của việc áp dụng quy trình phần mềm vào trong dự án hoặc tổ chức. Việc thay đổi hoặc thêm mới một quy trình phần mềm nhằm mục đích cải tiến hiệu quả và năng suất hoạt động của quy trình, từ đó cải thiện kết quả của quá trình làm ra sản phẩm. Thay đổi hoặc cải tiến quy trình có liên quan chặt chẽ tới việc thay đổi mô hình tổ chức hoặc cơ sở hạ tầng của tổ chức. Mục tiêu của sự thay đổi này nhằm mục đích cả thiện giá thành sản phẩm, thời gian xây dựng sản phẩm hoặc chất lượng của sản phẩm phần mềm. Thay đổi quy trình của một tổ chức thường kéo theo thay đổi nhiều thứ, ví dụ như mô hình của tổ chức đó, và ngược lại. 1.2 Cơ sở hạ tầng quy trình phần mềm Thiết lập, thực hiện và quản lý các quá trình phần mềm và các mô hình vòng đời phần mềm thường xảy ra ở cấp độ các dự án phần mềm. Tuy nhiên, ứng dụng có hệ thống các quy trình phần mềm và các mô hình vòng đời phần mềm qua một tổ chức có thể đem lại lợi ích cho tất cả các phần mềm làm việc trong tổ chức. Một cơ sở hạ tầng quy trình phần mềm có thể cung cấp các định nghĩa quy trình, chính sách để giải thích và áp dụng các quy trình, và mô tả các thủ tục được sử dụng để thực hiện các quy trình. Ngoài ra, một cơ sở hạ tầng quy trình phần mềm có thể cung cấp kinh phí, công cụ, đào tạo, và các nhân viên đã được phân công trách nhiệm cho việc thiết lập và duy trì cơ sở hạ tầng quy trình phần mềm. Cơ sở hạ tầng quy trình phần mềm tùy thuộc vào kích thước và độ phức tạp của tổ chức và các dự án thực hiện trong tổ chức. Các tổ chức và các dự án nhỏ, đơn giản có nhu cầu cơ sở hạ tầng đơn giản. Các tổ chức và các dự án phức tạp có cơ sở hạ tầng quá trình phần mềm lớn hơn và phức tạp hơn. Trong trường hợp đó, đơn vị tổ chức khác nhau có thể được thiết lập (chẳng hạn như một quá trình nhóm kỹ sư phần mềm hoặc một ban chỉ đạo) để giám sát việc thực hiện và cải tiến các quy trình phần mềm. Một nhận thức sai lầm phổ biến là việc thiết lập một cơ sở hạ tầng quy trình phần mềm và thực hiện các quy trình phần mềm lặp lại sẽ thêm thời gian và chi phí để phát triển phần mềm và bảo trì. Có chi phí cần thiết liên quan đến việc giới thiệu hoặc cải thiện một quá trình phần mềm; Tuy nhiên, kinh nghiệm cho thấy rằng việc thực hiện cải cách hệ thống các quy trình phần mềm có xu hướng dẫn đến chi phí thấp hơn thông qua cải thiện hiệu quả, tránh làm lại, và phần mềm đáng tin cậy hơn và giá cả hợp lý hơn. Hiệu suất của quy trình do đó ảnh hưởng đến chất lượng sản phẩm phần mềm. Vòng đời phát triển phần mềm (SDLC) là những quy trình dùng để đặc tả và chuyển đổi các yêu cầu thành sản phẩm có thể chuyển giao. Vòng đời sản phẩm (SPLC) bao gồm vòng đời phát triển phần mềm cộng với: Những quy trình phần mềm cung cấp cho việc triển khai, hỗ trợ, bảo trì, nâng cấp và ngưng sử dụng. Các quy trình khác: Quản lý cài đặt phần mềm, quy trình quản lý chất lượng phần mềm. Mô hình vòng đời phát triển phần mềm Nhấn mạnh vào tính phụ thuộc và quan hệ lẫn nhau về thời gian (temporal) và logic của những quy trình trong một mô hình. Bao gồm các cơ chế kiểm soát đối với việc áp dụng tiêu chuẩn đầu vào và đầu ra. Đầu ra của một quy trình phần mềm thường cung cấp đầu vào cho quy trình phần mềm khác. 2.1 Phân loại quy trình phần mềm Quy trình cơ bản Những quy trình phần mềm dành cho việc phát triển, thi hành và bảo trì phần mềm Quy trình hỗ trợ Quy trình hỗ trợ được áp dụng liên tục trong suốt vòng đời sản phẩm phần mềm để hỗ trợ quy trình cơ bản. Bao gồm những quy trình như quản lý cấu hình phần mềm, đảm bảo chất lượng, kiểm tra và xác nhận. Quy trình tổ chức Quy trình đào tạo. Quy trình phân tích đo lường. Quy trình quản lý cơ sở hạ tầng, quản lý danh mục và tái sử dụng. Quy trình cho Cross-Project Reuse, product-line, domain engineering, liên quan đến nhiều dự án trong tổ chức. Quy trình phần mềm bổ sung cho những quy trình trên: Quy trình quản lý dự án bao gồm các quá trình lập kế hoạch và lập dự toán, quản lý tài nguyên, đo lường và kiểm soát, lãnh đạo, quản lý rủi ro, quản lý các bên liên quan, phối hợp chính, hỗ trợ, tổ chức, và các quy trình cross-project của các dự án phát triển phần mềm và bảo trì. Quy trình phần mềm có thể được phát triển cho một số nhu cầu đặc biệt: ví dụ một dự án cần bảo mật thông tin thì quy trình phần mềm cũng cần sửa đổi để tuân theo nhu cầu bảo mật thông tin. 2.2 Mô hình vòng đời phần mềm Mô hình tuyến tính: Các giai đoạn phát triển phần mềm được thực hiện tuần tự Mô hình lặp lại: Phần mềm được phát triển từng bước tăng chức năng trên chu kỳ lặp đi lặp lại Mô hình Agile Phát triển phần mềm linh hoạt là một cơ chế thực hiện các dự án phần mềm khuyến khích các thay đổi mang tính tiến hóa trong toàn bộ vòng đời của dự án. Thường xuyên thuyết minh phần mềm với một đại diện khách hàng hoặc người dùng. Trong ngắn hạn lặp đi lặp lại chu kỳ sản xuất các gia số nhỏ của phần mềm Mô hình phát triển tuyến tính thường phát triển một bộ hoàn chỉnh các yêu cầu phần mềm, đến mức có thể, trong thời gian bắt đầu và lập kế hoạch dự án. Các yêu cầu về phần mềm này sau đó được kiểm soát một cách nghiêm ngặt. Thay đổi các yêu cầu phần mềm được xử lý bởi một ban kiểm soát thay đổi. Mô hình gia tăng sản xuất gia tăng liên tiếp của bộ làm việc, phần mềm chuyển giao dựa trên phân vùng của các phần mềm yêu cầu phải được thực hiện trong mỗi gia số. Các yêu cầu về phần mềm có thể được kiểm soát một cách chặt chẽ, như trong một mô hình tuyến tính, hoặc có thể có một số linh hoạt trong việc sửa đổi các yêu cầu phần mềm. Mô hình Agile có thể xác định phạm vi sản phẩm và tính năng cao cấp ban đầu; Tuy nhiên, các mô hình Agile được thiết kế để tạo thuận lợi cho quá trình tiến hóa của các yêu cầu phần mềm trong dự án. 2.3 Điều chỉnh quy trình phần mềm Điều chỉnh (adaptation) quy trình sẽ tùy vào bối cảnh tổ chức, sự đổi mới công nghệ, kích thước dự án, yêu cầu quản lý, thực tế ngành công nghiệp phần mềm ở địa phương. Quá trình điều chỉnh mô hình vòng đời phần mềm có thể bao gồm: thêm thông tin vào quy trình phần mềm hoặc loại bỏ những quy trình không áp dụng được 2.4 Liên hệ với thực tế Những yếu tố được xem xét khi định nghĩa và thiết kế một mô hình vòng đời phần mềm bao gồm các yêu cầu phù hợp với các tiêu chuẩn, hướng dẫn và chính sách; nhu cầu của khách hàng; tầm quan trọng của các sản phẩm phần mềm. Những quy trình phần mềm (ví dụ như quản lý cấu hình, xây dựng và thử nghiệm) có thể được điều chỉnh để tạo thuận lợi cho hoạt động hỗ trợ, bảo trì, chuyển đổi và kết thúc của phần mềm.
Chủ đề này nói về đánh giá quy trình phần mềm, phương pháp đánh giá quy trình phần mềm, quá trình cải thiện mô hình phần mềm, và cách thức xếp hạng. Đánh giá quy trình phần mềm được sử dụng để đánh giá các hình thức và nội dung của một quy trình phần mềm, mà có thể được xác định bởi một bộ tiêu chuẩn hóa các tiêu chí. Trong một số trường hợp, các điều khoản "quy trình thẩm định" và "đánh giá khả năng" được sử dụng thay vì đánh giá quy trình Hiệu suất đánh giá thường được thực hiện trong một tổ chức để xác định các quy trình phần mềm cần cải thiện. Đánh giá quy trình được thực hiện ở các cấp độ của toàn bộ tổ chức, đơn vị tổ chức trong các tổ chức, và các dự án cá nhân. Đánh giá có thể liên quan đến các vấn đề như đánh giá liệu các tiêu chí quy trình phần mềm đầu vào, đầu ra được đáp ứng, để xem xét các yếu tố rủi ro và quản lý rủi ro, hoặc để rút ra các bài học kinh nghiệm. Đánh giá quy trình được thực hiện bằng cách sử dụng cả một mô hình đánh giá và phương pháp đánh giá. Mô hình này có thể cung cấp một chuẩn mực để so sánh điểm chuẩn giữa các dự án trong một tổ chức và giữa các tổ chức. Quy trình kiểm tra khác với quy trình đánh giá phần mềm. Việc đánh giá phần mềm sẽ xác định được tính khả thi và sự thay đổi của phần mềm để biết được phần mềm cải thiện như thế nào. Kiểm tra phần mềm để xác định rằng các tiêu chuẩn có hợp lý hay không. Đây là quá trình thu thập bằng chứng và đánh giá bằng chứng về các hoạt động của hệ thống thông tin đã được tổ chức. Việc đánh giá các bằng chứng phải đảm bảo rằng hoạt động của hệ thống ấy phải bảo mật, chính trực, hữu hiệu, và hiệu quả nhằm đạt được các mục tiêu của tổ chức đã đề ra. 3.1 Những mô hình đánh giá quy trình phần mềm Việc đánh giá mô hình quy trình phần mềm mang lại những kinh nghiệm thực tiễn tốt. Nó có thể áp dụng thêm trong những việc bảo trì phần mềm, quản lý dự án phần mềm, quản lý kỹ thuật hệ thống, hoặc quản lý nguồn nhân lực. 3.2 Những phương pháp đánh giá quy trình phần mềm 1 phương pháp đánh giá quy trình phần mềm có thể dựa vào việc định tính hoặc định lượng. Định tính được xác định qua các đánh giá của các chuyên gia có kinh nghiệm. Định lượng là dựa vào các chỉ số đo và tính toán được. Lấy ví dụ là dựa vào các thông số như số lỗi, số issue được tạo ra, thời gian trung bình cấn thiết để hiệu chỉnh 1 lỗi, vv. Một phương pháp điển hình của việc đánh giá quy trình phần mềm bao gồm lập kế hoạch, tìm hiểu thực tế (bằng cách thu thập dữ liệu thông qua bảng câu hỏi, phỏng vấn và quan sát thực tế công việc), phân tích và báo cáo. Chất lượng của các kết quả đánh giá phụ thuộc vào phương pháp đánh giá, tính toàn vẹn và chất lượng của dữ liệu thu được, khả năng của các nhóm đánh giá và tính khách quan của thông tin mà họ đánh giá được, và các thông số trong quá trình kiểm tra đánh giá. Kết quả mong muốn của việc đánh giá quá trình phần mềm là đạt được cái nhìn toàn vẹn rằng phần mềm đang ở trạng thái như thế nào và cung cấp cơ sở cho việc cải tiến quy trình (nếu có) 3.3 Những mô hình cải thiện quy trình phần mềm Cải thiện quy trình phần mềm nhấn mạnh sự cải thiện liên tục để phần mềm tiến tới trạng thái hoàn thiện. Việc cải tiến quy trình phần mềm có thể bao gồm các quy trình con về tính toán, phân tích, và thay đổi. Mô hình Plan-Do-Check-Act là một cách tiếp cận nổi tiếng để cải tiến quy trình phần mềm. Các hoạt động cải tiến bao gồm việc xác định và ưu tiên những điểm cần cải tiến trước; đề xuất các phương án để cải tiến, đánh giá sự cải thiện so với kết quả quá trình trước đó hoặc so với 1 mô hình mẫu nào đó. Mô hình Plan-Do-Check-Act có thể được áp dụng cho việc phòng ngừa các lỗi xảy ra 3.4 Xếp hạng quy trình phần mềm Để đánh giá khả năng và sự đổi mới ( tiến bộ, thay đổi tích cực) của 1 quy trình phần mềm thì sử dụng bảng đánh giá gồm 5 hoặc 6 cấp độ Bảng thể hiện các cấp độ đánh giá quy trình phần mềm Trong bảng 8.1, Mức 0 chỉ ra rằng một quy trình phần mềm được thực hiện không đầy đủ hoặc không thể thực hiện được. Cấp độ 1, một quy trình phần mềm đang được thực hiện. Ở cấp độ 2, một quy trình phần mềm đang được thực hiện và nó có khả năng cho ra các sản phẩm trung gian mà có thể hiển thị, thấy được Ở cấp độ 3, những quy trình đã hoàn thành ở cấp độ 2 được xác định rõ (xác định thông qua các chính sách và thủ tục của tổ chức ). Cấp độ 3 thì quy trình phần mềm tiếp tục được cải thiện và nó cung cấp một cơ sở cho việc cải tiến quy trình, vì ở cấp độ này các chuyên gia đã có thể đánh giá và đo đạc được các thông số chất lượng quy trình phần mềm Cấp độ 4, các biện pháp định lượng, phân tích thống kê có thể được áp dụng và được sử dụng để đánh giá quy trình Cấp độ 5, các cơ chế cho việc cải tiến quy trình phần mềm liên tục được áp dụng. Chủ đề này nói về quy trình phần mềm và đo lường sản phẩm, chất lượng của các kết quả đo lường, mô hình thông tin phần mềm, và kỹ thuật đo lường quy trình phần mềm. Trước khi một quy trình mới được thực hiện hoặc một quy trình hiện tại được sửa đổi, kết quả đo lường cho tình hình hiện nay nên được thu lại để cung cấp một đường cơ sở để so sánh giữa tình hình hiện tại và tình hình mới. 4.1 Cách đo lường quy trình phần mềm và sản phẩm Đo lường sản xuất phần mềm có liên quan với việc xác định hiệu quả và hiệu suất của một quy trình phần mềm, hoạt động, hoặc tác vụ. Hiệu quả của một quá trình phần mềm, hoạt động, hoặc tác vụ là tỷ lệ của các nguồn tài nguyên thực sự tiêu thụ / tài nguyên dự kiến trong hoàn thành một quy trình phần mềm, hoạt động, hoặc công việc. Chi phí tương đương là các biện pháp chính tính tài nguyên cho hầu hết các quy trình phần mềm , hoạt động và nhiệm vụ; nó được đo bằng đơn vị như person-hours, person-days, person-hours, person-days, staff- weeks, or staff-months effort hoặc tương đương đơn vị tiền tệ-chẳng hạn như Euro hoặc đô la. Hiệu quả là tỷ lệ các sản lượng thực tế của đầu ra dự kiến sản xuất bằng quy trình phần mềm, hoạt động hoặc nhiệm vụ; Ví dụ, số lượng thực tế của phát hiện lỗi và sửa chữa trong phần mềm thử nghiệm để dự kiến số lỗi được phát hiện và sửa chữa dựa trên các dữ liệu lịch sử cho dự án tương tự. Lưu ý rằng đo lường tính hiệu quả quy trình phần mềm yêu cầu đo lường của các thuộc tính của các sản phẩm có liên quan; Ví dụ, đo lường của lỗi phần mềm được phát hiện và sửa chữa trong thời gian kiểm thử phần mềm. Nguyên nhân của hiệu quả thấp một quy trình phần mềm, hoạt động, hoặc công việc được thực hiện có thể bao gồm một hoặc nhiều vấn đề sau: thiếu đầu vào công việc sản phẩm, nhân viên thiếu kinh nghiệm, không đầy đủ các công cụ và cơ sở hạ tầng, học một quy trình mới, một sản phẩm phức tạp, hoặc không quen sản phẩm. Hiệu quả và hiệu suất của quy trình phần mềm thực hiện cũng bị ảnh hưởng (tích cực hoặc tiêu cực) bởi yếu tố chẳng hạn như doanh thu trong nhân sự phần mềm, thay đổi lịch trình, một đại diện khách hàng mới, hoặc một chính sách mới tổ chức. Tiêu chuẩn hóa các định nghĩa và tính quy tắc cho các đo lường của quy trình phần mềm và các sản phẩm làm việc là cần thiết để cung cấp kết quả đo lường tiêu chuẩn qua các dự án trong một tổ chức, để có một kho lưu trữ của dữ liệu lịch sử có thể được phân tích để xác định quy trình phần mềm cần phải được cải thiện, và để xây dựng các mô hình tiên đoán dựa trên tích lũy dữ liệu. 4.2 Chất lượng của kết quả sự đo lường Chất lượng của các kết quả đo lường sản xuất chủ yếu được xác định bởi độ tin cậy và tính hợp lệ của các kết quả đo. Đo đạc không đáp ứng các tiêu chí chất lượng có thể dẫn đến không đúng cách diễn giải và sáng kiến cải thiện quá trình phần mềm bị lỗi. Các thuộc tính mong muốn của các phép đo phần mềm bao gồm một bộ sưu tập, phân tích, và trình bày cùng với một sự tương quan lớn giữa nguyên nhân và hiệu quả. 4.3 Những mô hình thông tin phần mềm Mô hình thông tin phần mềm cho phép mô hình hóa, phân tích và dự đoán của quy trình phần mềm và thuộc tính sản phẩm phần mềm để cung cấp câu trả lời cho câu hỏi có liên quan và đạt được mục tiêu cải thiện quá trình và sản phẩm. Dữ liệu cần thiết có thể được thu thập và giữ lại trong một kho lưu trữ; dữ liệu có thể được phân tích và mô hình có thể được xây dựng. Xác nhận và sàng lọc các mô hình thông tin phần mềm xảy ra trong thời gian dự án phần mềm và sau khi dự án được hoàn thành để đảm bảo mức độ chính xác. Mô hình thông tin phần mềm cũng có thể được phát triển cho các ngôn ngữ khác hơn so với dự án phần mềm. Ví dụ, một mô hình thông tin phần mềm có thể được phát triển cho quá trình áp dụng cho một tổ chức, chẳng hạn như quản lý cấu hình phần mềm hoặc đảm bảo chất lượng quy trình phần mềm ở cấp độ tổ chức. Một mô hình thông tin phần mềm được phát triển bằng cách thiết lập một biến đổi đưa ra giả thuyết của các biến đầu vào thành đầu ra mong muốn. Ví dụ, sản phẩm kích thước và độ phức tạp có thể được chuyển đổi thành ước tính effort cần thiết để phát triển một sản phẩm phần mềm bằng cách sử dụng một phương trình hồi quy phát triển từ các dữ liệu quan sát từ các dự án trong quá khứ. Một mô hình được kiểm định bằng cách điều chỉnh các tham số trong mô hình để phù hợp với các kết quả quan sát từ các dự án trong quá khứ. Một mô hình được đánh giá bằng cách so sánh các kết quả tính đến các kết quả thực tế cho một tập khác nhau của dữ liệu tương tự. Hiện có ba kết quả có thể đánh giá: 1. Kết quả tính toán cho một tập dữ liệu khác nhau rất khác nhau từ những kết quả thực tế cho bộ dữ liệu, trong trường hợp các mô hình có nguồn gốc không áp dụng cho thiết lập các dữ liệu mới và không nên áp dụng để phân tích hoặc đưa ra dự đoán cho các dự án trong tương lai; 2. Kết quả tính toán cho một tập dữ liệu mới đang gần kết quả thực tế cho bộ dữ liệu, trong đó trường hợp điều chỉnh nhỏ được thực hiện điều chỉnh các thông số của mô hình để cải thiện sự thỏa thuận (improve agreement). 3. Kết quả tính toán cho dữ liệu mới và thiết lập bộ dữ liệu tiếp theo là rất gần và không có điều chỉnh để các mô hình là cần thiết. Các đánh giá liên tục của các mô hình có thể chỉ ra một nhu cầu cho điều chỉnh theo thời gian vì bối cảnh trong đó các mô hình là ứng dụng thay đổi. Phương pháp mục tiêu/câu hỏi/số liệu, Goals/Questions/Metrics (GQM) ban đầu được dự định để thiết lập đo lường hoạt động, nhưng nó cũng có thể được sử dụng để hướng dẫn phân tích và cải thiện quy trình phần mềm. Nó có thể được sử dụng để hướng dẫn hướng phân tích xây dựng mô hình thông tin phần mềm; kết quả thu được từ phần mềm thông tin mẫu có thể được sử dụng để hướng dẫn quá trình cải tiến. Ví dụ sau minh hoạ các ứng dụng của phương pháp GQM: Goal: Reduce the average change request processing time by 10% within six months. Question 1-1: What is the baseline change request processing time? Metric 1-1-1: Average of change request processing times on starting date Metric 1-1-2: Standard deviation of change request processing times on starting date Question 1-2: What is the current change request processing time? Metric 1-2-1: Average of change request processing times currently Metric 1-2-2: Standard deviation of change request processing times currently 4.4 Những kỹ thuật đo lường quy trình phần mềm Kỹ thuật đo lường quy trình phần mềm được sử dụng để thu thập dữ liệu quy trình và dữ liệu sản phẩm, chuyển đổi dữ liệu vào thông tin hữu ích và phân tích thông tin để xác định các hoạt động quy trình là ứng cử viên cho việc cải thiện. Trong một số trường hợp, quy trình phần mềm mới có thể là cần thiết. Quá trình đo lường kỹ thuật cũng cung cấp thông tin cần thiết để đo lường tác động của quá trình cải tiến sáng kiến. Quá trình đo lường kỹ thuật có thể được sử dụng để thu thập dữ liệu định lượng và chất lượng. Các công cụ đơn giản để định lượng: check sheets, Pareto diagrams, histograms, scatter diagrams, run charts, control charts, and cause-and-effect diagrams Dữ liệu được thu thập bằng cách sử dụng định lượng quá trình đo lường kỹ thuật cũng có thể được sử dụng như đầu vào để mô phỏng các mô hình. Các mô hình này có thể được sử dụng để đánh giá tác động của phương pháp tiếp cận khác nhau để cải thiện quá trình phần mềm. Phân loại khiếm khuyết trực giao (ODC) có thể được sử dụng để phân tích định lượng quá trình đo lường dữ liệu. Định tính quá trình đo lường kỹ thuật bao gồm các cuộc phỏng vấn, câu hỏi, và ý kiến chuyên gia - có thể được sử dụng để làm tăng thêm kỹ thuật đo lường định lượng quy trình. Kỹ thuật sự đồng thuận nhóm, có thể được sử dụng để có được sự đồng thuận giữa các nhóm của các bên liên quan 5 Những công cụ quy trình kĩ thuật phần mềm BPMN, IDEF0 diagrams, Petri nets, and UML activity diagrams, spreadsheet. Computer-Assisted Software Engineering (CASE) tools |
