Chương 7: Quản lý công nghệ phần mềm

Danh sách thành viên:

- Lê Thị Bích Liên

- Trần Văn Tiến

- Vũ Thị Thanh

Tổng quan

Quản lý công nghệ phần mềm có thể được định nghĩa là việc áp dụng các kế hoạch hoạt động quản lý, điều phối, đo lường, giám sát, kiểm soát và báo cáo để đảm bảo rằng các sản phẩm phần mềm và dịch vụ công nghệ phần mềm được phân phối hiệu quả, và đảm bảo lợi ích của các bên liên quan. Có những khía cạnh đặc trưng trong dự án phần mềm và chu trình phát triển của phần mềm, nó làm quá trình quản lý trở nên phức tạp bao gồm:

• Khách hàng thường là người không biết những gì là cần thiết, những gì là khả thi.
• Khách hàng thường thiếu sự đánh giá cao cho sự phức tạp vốn có trong công nghệ phần mềm, đặc biệt là về tác động của việc thay đổi.
• Sự hiểu biết và điều kiện thay đổi sẽ tạo ra các yêu cầu phần mềm mới hoặc thay đổi những yêu cầu của phần mềm.
• Phần mềm thường được xây dựng sử dụng một quá trình lặp đi lặp lại chứ không phải là một chuỗi các nhiệm vụ khép kín.
• Phần mềm kỹ thuật nhất thiết phải kết hợp sáng tạo và tính kỷ luật trong quá trình phát triển phần mềm. Duy trì một sự cân bằng thích hợp giữa hai bên là đôi khi là khó khăn.
• Mức độ của sự mới mẻ và phức tạp thường cao.
• Thường có sự thay đổi công nghệ rất nhanh chóng.

Hoạt động quản lý công nghệ phần mềm xảy ra ở ba cấp độ: tổ chức và quản lý cơ sở hạ tầng, quản lý dự án và quản lý các hệ thống đo lường. Trong chương này, sẽ tìm hiểu chi tiết về quản lý dự án và quản lý các hệ thống đo lường. Các vấn đề được trình bày trong chương này bao gồm:

1.Khởi tạo và định nghĩa phạm vi

Mục tiêu của các hoạt động này là xác định hiệu quả các yêu cầu của phần mềm sử dụng các phương pháp khác nhau, và đánh giá tính khả thi của dự án từ nhiều quan điểm. Một khi tính khả thi của dự án đã được xác định, thì nhiệm vụ tiếp theo là đặc tả yêu cầu và lựa chọn quy trình xử lý cho việc ra soát và xem lại các yêu cầu.
Quá trình khởi tạo và định nghĩa phạm vi sẽ theo tuần tự như sau: Xác định và điều chỉnh yêu cầu. Nếu khả thi thì xem xét và sửa đổi các yêu cầu.

• Xác định và điều chỉnh yêu cầu dựa vào:

  • Những yêu cầu được đưa ra.
  • Điều chỉnh yêu cầu với các bên liên quan
  • Dựa vào bản đặc tả yêu cầu SRS.
  • Phần mềm làm ra đáp ứng được nhu cầu của người sử dụng.

• Để đánh giá phần mềm có tính khả thi hay không, dựa vào các tiêu chí sau:

  • Được sử dụng trong thời gian dài mà hầu hết các lỗi ban đầu của nó đã được loại bỏ.
  • Giải pháp phân tích hoạt động của quá trình phát triển phần mềm.
  • Phân tích tài chính trên chu trình phát triển phần mềm.
  • Tác động xã hội, chính trị
• Xem xét và sửa đổi yêu cầu bao gồm như:
  • Thay đổi cách quản lý trong việc xem xét và sửa đổi các yêu cầu.
  • Đánh giá khả năng thành công với những yêu cầu thay đổi.

1.1 Đàm phán và xác định các yêu cầu

Đàm phán và xác định các yêu cầu, xác định các công việc định làm. Các hoạt động bao gồm các yêu cầu về sự khám phá, phân tích, đặc điểm kỹ thuật và xác nhận. Các phương pháp và kỹ thuật cần được lựa chọn và áp dụng, xét đến các quan điểm của các bên liên quan. Điều này dẫn đến việc xác định phạm vi dự án trong đơn đặt hàng để đáp ứng mục tiêu và đảm bảo ràng buộc.

1.2 Phân tích tính khả thi

Mục đích của việc phân tích tính khả thi là để phát triển một mô tả rõ ràng về mục tiêu dự án và đánh giá các phương án khác nhau để xác định xem dự án này là một lựa chọn tốt cho những hạn chế của công nghệ, nguồn lực, tài chính, và xã hội / chính trị. Một dự án ban đầu và việc trình bày phạm vi sản phẩm, phân phối dự án, hạn chế thời gian dự án, và ước tính nguồn lực cần thiết phải được chuẩn bị. Tài nguyên bao gồm một số lượng đủ của những người có những kỹ năng cần thiết, cơ sở vật chất, cơ sở hạ tầng, và hỗ trợ (bên trong hoặc bên ngoài). Phân tích tính khả thi thường đòi hỏi ước tính gần đúng của nỗ lực và chi phí dựa trên các phương pháp thích hợp.

1.3 Quy trình về việc xem xét và sửa đổi yêu cầu

Các bên liên quan phải thống nhất về cách thức mà các yêu cầu và phạm vi cần được xem xét và sửa đổi. Phạm vi và yêu cầu sẽ không được “ấn định chính thức” nhưng có thể và nên được xem xét lại. Nếu thay đổi được chấp nhận, sau đó một số hình thức phân tích truy xuất nguồn gốc và phân tích rủi ro nên được sử dụng để xác định tác động của những thay đổi. Có nghĩa là phạm vi yêu cầu không phải luôn luôn được ấn định mà nó có thể thay đổi. Ví dụ, có thể thêm chức năng của phần mềm dựa vào việc phân tích các yêu cầu hoặc yêu cầu của khách hàng hoặc là tại thời điểm này thì ưu tiên công việc nào trước, nó thể thay đổi không cố định. Và nếu như những thay đổi đó được chấp nhận thì phải có phương pháp phân tích rủi ro để đánh giá mức độ rủi ro của việc thay đổi, xem xét xem việc thay đổi đó có hợp lý không.

2 Kế hoạch dự án phần mềm

Giai đ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 đó.
Bước đầu tiên trong việc lập kế hoạch dự án phần mềm phải được lựa chọn mô hình chu trình phát triển phần mềm, và có thể thiết kế nó dựa trên phạm vi dự án, yêu cầu dự án, và đánh giá rủi ro.
Trong tất cả các chu trình phát triển phần mềm (SDLC), đánh giá rủi ro phải được lên kế hoạch từ ban đầu dự án. Và danh sách rủi ro phải được đem thảo luận và chấp nhận bởi các bên liên quan. Quy trình và chịu trách nhiệm về việc xem xét và sửa đổi liên tục các kế hoạch dự án và các kế hoạch có liên quan cũng nên được quy định rõ ràng và thống nhất.

2.1 Quá trình lập kế hoạch

Chu trình phát triển phần mềm: Các giai đoạn trong chu trình phát triển phần mềm:

Các mô hình chu trình phát triển phần mềm: waterfall (mô hình thác nước, incremental (mô hình gia tăng), and spiral models (mô hình xoắn ốc)….

• Waterfall model: Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau như sau:
  • Phân tích yêu cầu(Requirement Analysis): là giai đoạn xác định những Yêu cầu liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” .Tài liệu Đặc tả yêu cầu chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án.
  • Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra làm thế nào để hệ thống phần mềm đáp ứng những yêu cầu mà khách hàng yêu cầu trong tài liệu SRS.

=> Nhược điểm của mô hình waterfall: Thực tế cho thấy đến những giai đoạn cuối của dự án mới có khả năng nhận ra sai sót trong những giai đoạn trước và phải quay lại để sửa chữa.

• Mô hình gia tăng: Ưu điểm.

    -    Có thể sớm tạo ra nguyên mẫu của sản phẩm trong vòng đời phát triển của nó.
    -    Độ linh hoạt cao hơn và khi thay đổi yêu cầu dự án thì chi phí sẽ ít hơn nhiều, vì những thay đổi thuộc về module nào thì module đó sẽ thay đổi mà các module khác không hề bị ảnh hưởng.
    -    Việc phân chia thành các module cũng sẽ làm cho việc test nhẹ nhàng hơn, những module đơn giản thì test cũng đơn giản, sớm kết thúc.
    -    Giảm chi phí cho lần đầu giao sản phẩm.
    -    Dễ dàng quản lý các rủi ro có thể phát sinh.
  

  Nhược điểm.

    -    Cần phải có những khả năng thiết kế tốt và phương pháp tốt, để có thể hiểu rõ được yêu cầu và biết cách phân chia nó ra như thế nào cho hợp lý.
    -    Chi phí để phát triển theo phương pháp này là rất cao, cao hơn hẳn waterfall. Quá trình lập kế hoạch chỉ ra cách làm như thế nào để phần mềm hoạt động được và đạt được các yêu cầu.
  

  Khi nào áp dụng mô hình này:

    -    Áp dụng mô hình này khi yêu cầu của dự án là rõ ràng, đầy đủ, và nắm rõ được các yêu cầu của dự án. 
    -    Khi sớm cần có một nguyên mẫu phần mềm để quáng bá, giới thiệu hoặc thử nghiệm. 
    -    Sử dụng mô hình này khi một công nghệ mới được áp dụng.
    -    Tài nguyên và kỹ năng chuyên môn luôn sẵn sàng. 
    -    Khi có một tính năng hay các mục tiêu có nguy cơ lỗi cao.
  

• Mô hình xoắn ốc:
  • Trong mô hình xoắn ốc, quy trình phát triển phần mềm được thực hiện như một vòng xoáy ốc. Mỗi vòng xoắn ốc biểu diễn một hoạt động trong tiến trình phát triển phần mềm.
  • Nó dựa trên ý tưởng là tối thiểu hóa rủi ro, bằng việc phân tích yếu tố rủi ro ở mỗi bước lặp và sử dụng phương pháp làm bản mẫu.
  • Quá trình phát triển được chia thành nhiều bước lặp lại, mỗi bước bắt đầu bằng việc lập kế hoạch, phân tích rủi ro, rồi tạo bản mẫu, hoàn thiện và phát triển hệ thống, duyệt lại, và cứ thế tiếp tục.
  • Quy trình 4 bước:
    1. Lập kế hoạch: xác định mục tiêu, giải pháp và ràng buộc;
    2. Phân tích rủi ro: phân tích các phương án, xác định và giải quyết rủi ro;
    3. Phát triển và kiểm định: phát triển sản phẩm “mức tiếp theo”. Xây dựng một hay một số biểu diễn của ứng dụng
    4. Lên kế hoạch cho chu kỳ lặp tiếp theo: kiểm duyệt tất cả các kết quả của các giai đoạn con xảy ra trước đó và lập kế hoạch cho chu kỳ lặp tiếp theo.
       • Tại mỗi vòng phát triển, nếu rủi ro lớn thì có thể dừng việc phát triển lại. Mô hình này thích hợp cho việc xây dựng những hệ thống lớn.
       • Theo IEEE / EIA Std. 12.207,0-1996, các yếu tố lập kế hoạch dự án bao gồm: Nguồn lực cần thiết thể thực hiện các nhiệm vụ; Giao nhiệm vụ, phân công trách nghiệm; Biện pháp kiểm soát chất lượng trong suốt quá trình sử dụng; Cung cấp môi trường và cơ sở hạ tầng.

2.2 Quyết định phân phối

Kế hoạch dự án xác định các phân phối dự án mà có thể bao gồm, không bị giới hạn:

• Các phần mềm hoạt động
• Yêu cầu của khách hàng
• Đặc điểm chức năng
• Thiết kế kỹ thuật
• Tài liệu hướng dẫn thiết kế
• Mã nguồn
• Hướng dẫn sử dụng tài
• Nguyên tắc hoạt động
• Hướng dẫn cài đặt
• Thủ tục bảo trì
• Tài liệu đào tạo

2.3 Ước tính công sức, thời gian và chi phí

Phạm vi ước lượng đòi hỏi sự nỗ lực cần thiết cho một dự án, hoặc các bộ phận của một dự án, có thể được xác định bằng cách sử dụng một mô hình dự toán được hiệu chỉnh dựa trên kích thước và nỗ lực lịch sử dữ liệu (nếu có) và các phương pháp khác có liên quan như phán đoán của chuyên gia và tương tự. Để hoàn thành nhiệm vụ đồng thời và liên tục, các nhiệm vụ có thể được xác định và ghi chép bằng cách sử dụng một biểu đồ ví dụ như biểu đồ Gantt. Đối với dự án dự đoán chu trình phát triển phần mềm, đã cho rằng những công việc với thời gian bắt đầu dự án, khoảng thời gian triển khai dự án, và thời gian kết thúc là thường được đưa ra trong suốt quá trình lập kế hoạch. Đối với dự án chu trình phát triển phần mềm thích ứng, tỷ lệ chung của nỗ lực và tiến độ thường được phát triển từ những hiểu biết ban đầu về các yêu cầu, hoặc nói cách khác, những hạn chế về nỗ lực chung và tiến độ có thể được xác định và được sử dụng để xác định một ước tính ban đầu về số lượng các chu kỳ lặp đi lặp lại và ước tính của nỗ lực và các nguồn lực khác được giao cho mỗi chu kỳ.

Yêu cầu nguồn tài nguyên (ví dụ, con người và những công cụ) có thể được coi là sự ước lượng chi phí. Dự kiến ban đầu của nỗ lực, tiến độ, chi phí và là một hoạt động lặp đi lặp lại rằng nên được đàm phán và điều chỉnh các bên liên quan bị ảnh hưởng cho đến khi đạt được sự đồng thuận về tài nguyên và thời gian dành cho dự án hoàn thành.

2.4 Phân phối nguồn lực tài nguyên

Công cụ, con người, cơ sở vật chất cần được giao cho nhiệm vụ cụ thể. Phân bổ đòi hỏi phải cân bằng, chuyên môn, có đạo đức nghề nghiệp.
Điều chỉnh lịch trình/ chi phí là cần thiết nếu như các nguồn lực trở nên không có sẵn.

Quản lý dự án có thể cần phải thay đổi kích thước nhóm và cơ cấu để hoạt động đồng thời có thể thực thi một cách hiệu quả.

2.5 Quản lý rủi ro

Rủi ro và tính không chắc chắn là những khái niệm có liên quan nhưng khác biệt. Kết quả của tính không chắc chắn từ sự thiếu thông tin. Còn Rủi ro được đặc trưng bởi xác suất của một kết quả sẽ dẫn đến một tác động tiêu cực cộng với một mô tả đặc điểm của các tác động tiêu cực trên một dự án. Rủi ro thường là kết quả của sự không chắc chắn. Trái ngược với rủi ro là cơ hội, được đặc trưng bởi xác suất mà một sự kiện có một kết quả tích cực có thể xảy ra.

Quản lý rủi ro đòi hỏi phải xác định các yếu tố rủi ro và phân tích các khả năng và tác động tiềm năng của mỗi yếu tố rủi ro, ưu tiên các yếu tố nguy cơ, và phát triển các chiến lược giảm thiểu rủi ro để giảm xác suất và giảm thiểu các tác động tiêu cực nếu một yếu tố nguy cơ trở thành một vấn đề. Phương pháp đánh giá rủi ro đôi khi có thể được sử dụng để xác định và đánh giá các yếu tố nguy cơ.

Quản lý rủi ro cần phải được thực hiện không chỉ ở đầu của một dự án, mà còn thực hiện định kỳ trong suốt vòng đời dự án.

Tất cả các hoạt động quản lý dự án có thể được xem như là quản lý rủi ro. Ví dụ, dự toán chi phí giảm thiểu các nguy cơ mất tiền. Các tiêu chuẩn ISO / IEC định nghĩa quản lý rủi ro như:

1. một quá trình có tổ chức để xác định và xử lý các yếu tố nguy cơ.
2. một phương tiện tổ chức xác định và đo lường rủi ro (đánh giá rủi ro) và phát triển, lựa chọn, và các tùy chọn quản lý (phân tích rủi ro) cho giải quyết (xử lý rủi ro) những rủi ro này.
3. tổ chức, quá trình phân tích để xác định những gì có thể gây tổn hại hoặc mất mát (xác định rủi ro); để đánh giá và định lượng các rủi ro được xác định; và để phát triển. Nếu cần thiết, thực hiện một phương pháp thích hợp để ngăn chặn hoặc xử lý gây ra các rủi ro có thể dẫn đến thiệt hại đáng kể hoặc mất mát.

Quá trình xử lý rủi ro bao gồm:

• Plan and implement risk management (lập kế hoạch và thực hiện quản lý rủi ro)
• Manage project risk profile (quản lý hồ sơ dự án rủi ro)
• Perform risk analysis (Thực hiện phân tích rủi ro)
• Perform risk treatment (Thực hiện xử lý rủi ro)
• Perform risk monitoringe (Thực hiện giám sát rủi ro)
• Evaluate risk management process (Đánh giá quá trình quản lý rủi ro)

2.6 Quản lý chất lượng

Yêu cầu chất lượng phần mềm nên được thống nhất, có lẽ cả về số lượng và chất lượng cho một dự án phần mềm và các sản phẩm liên quan. Ngưỡng cho phép đo chất lượng chấp nhận được nên được thiết lập cho từng yêu cầu chất lượng phần mềm dựa trên nhu cầu và kỳ vọng của các bên liên quan. Những thủ tục liên quan đến phần mềm liên tục đảm bảo chất lượng (SQA) và cải tiến chất lượng trong suốt quá trình phát triển, xác minh và xác nhận của các sản phẩm phần mềm chuyển giao, cũng nên được chỉ rõ trong hoạch định chất lượng.
Theo IEEE / EIA Std. 12.207,0-1996, một kế hoạch quản lý bảo đảm chất lượng nên bao gồm:

• Tiêu chuẩn chất lượng, phương pháp, quy trình, và các công cụ để thực hiện chất lượng đảm bảo hoạt động (hoặc tài liệu tham khảo trong các tài liệu chính thức của tổ chức).
• Thủ tục xem xét hợp đồng và phối hợp của chúng.
• Thủ tục xác định, thu thập, lập hồ sơ, bảo trì, và định đoạt chất lượng ghi chép.
• Tài nguyên, lịch trình, và trách nhiệm tiến hành các hoạt động đảm bảo chất lượng.
• Các hoạt động và nhiệm vụ được lựa chọn từ các quá trình hỗ trợ như xác minh, kiểm định, đánh giá chung, kiểm toán và giải quyết vấn đề.

2.7 Quản lý kế hoạch

Kế hoạch và quy trình lựa chọn phát triển phần mềm cần được theo dõi một cách hệ thống, được xem xét, báo cáo, và sửa đổi khi thích hợp. Kế hoạch kết hợp với quy trình hỗ trợ (ví dụ, tài liệu, quản lý cấu hình phần mềm, và giải quyết vấn đề) cũng cần được quản lý. Báo cáo, giám sát và kiểm soát một dự án nên được lựa chọn sao cho phù hợp với chu trình phát triển phần mềm và những thực tế của dự án; các kế hoạch nên giả lập giải thích các sản phẩm khác nhau sử dụng để quản lý dự án.

Khi dự án tiến triển, kế hoạch phải được cập nhật để phản ánh:

• Yêu cầu sửa đổi.
• Lịch trình mở rộng
• Những thay đổi trong thủ tục kiểm tra.
• Chức năng phần mềm thay đổi.

Việc tuân thủ kế hoạch phải được hướng dẫn một cách hệ thống, theo dõi, xem xét, báo cáo, và sửa đổi. Kế hoạch quản lý dự án là các mục cấu hình và là một phần của quá trình phát triển phần mềm.

3 Thực hiện dự án phần mềm

Trong suốt quá trình thực hiện dự án phần mềm, kế hoạch được thực hiện và các quy trình trong kế hoạch cũng được thực hiện. Trong quá trình thực hiện phần mềm không nên tập trung vào việc tuân thủ các quy trình được lựa chọn với một kỳ vọng là nếu tuân thủ theo quy trình này thì sẽ dẫn đến sự hài lòng về yêu cầu của khách hàng và đạt được mục tiêu dự án. Các hoạt động cơ bản của việc thực hiện phần mềm bao gồm các hoạt động để kiểm soát, điều hành và báo cáo.

3.1 Sự thực hiện kế hoạch

Các hoạt động của dự án cần được thực hiện phù hợp với kế hoạch dự án và các kế hoạch hỗ trợ.

Tài nguyên của dự án ví dụ như con người, công nghệ và nhà tài trợ được sử dụng để tạo ra sản phẩm. Sản phẩm của dự án có thể biết đến như thiết kế hệ thống, mã nguồn phần mềm và các ca kiểm thử sẽ được tạo ra trong quá trình thực hiện kế hoạch.

3.2 Thu nhận phần mềm và quản lý hợp đồng nhà cung cấp

Thu nhận phần mềm và quản lý hợp đồng nhà cung cấp là khái niệm có liên quan với các vấn đề về ký kết hợp đồng. Hợp đồng này bao gồm khách hàng của các tổ chức phần mềm với tổ chức cung cấp phần mềm.

Các vấn đề về ký kết hợp đồng bao gồm việc lựa chọn loại hợp đồng thích hợp. Có các loại hợp đồng như hợp đồng fix price, time and materials, … Hợp đồng fix price là loại hợp đồng mà khách hàng trả cho nhà cung cấp giá và thời gian bàn giao là không đổi. Nhà cung cấp có thể quyết định sử dụng bao nhiêu người để hoàn thành sản phẩm. Ví dụ khách hàng thuê nhà cung cấp làm một phần mềm trong thời gian là 6 tháng với số tiền là 100000000 đồng thì đây là dạng hợp đồng fix price. Trong khi đó hợp đồng time and materials là loại hợp đồng mà khách hàng sẽ trả cho nhà cung cấp với số người là cố định còn số tiền sẽ trả theo thời gian làm không cố định giá trước và thời gian làm xong. Ví dụ khách hàng thuê nhà cung cấp làm một phần mềm với 5 người và số tiền trả cho 1 người trong một ngày là 100 USD thì đây là một loại hợp đồng time and materials

Thỏa thuận giữa khách hàng và nhà cung cấp thường phải định rõ phạm vi công việc và các sản phẩm bàn giao, các hình phạt cho việc bàn giao muộn và không giao được sản phẩm và sở hữu trí tuệ. Đối với các phần mềm được phát triển bới chính nhà cung cấp, các thỏa thuận thường chỉ ra yêu cầu chất lượng phần mềm và điều kiện chấp nhận được của sản phẩm được bàn giao.

Sau khi thỏa thuận được đưa ra, cần quản lý việc thực hiện dự án sao cho phù hợp với các điều khoản của các thỏa thuận.

3.3 Thực hiện quy trình đo lường

Quy trình đo lường nên được thực hiện trong các dự án phần mềm để đảm bảo dữ liệu hữu ích có liên quan được thu thập. Xem thêm trong mục 6.

3.4 Quy trình giám sát

Việc thực hiện các kế hoạch dự án và các kế hoạch liên quan đến dự án cần được đánh giá liên tục tại các khoảng thời gian được định trước. Ngoài ra kết quả đầu ra và tiêu chuẩn hoàn thiện cho mỗi công việc cũng cần được đánh giá.

Nên phân chia việc đánh giá theo các điều khoản và yêu cầu trong các điều khoản. Các tiêu chuẩn cần được đánh giá:

• Hiệu suất làm việc
• Tuân thủ lịch trình
• Chi phí đã dùng cho đến hiện tại
• Kiểm tra việc sử dụng tài nguyên.
• Rủi ro của dự án cũng nên được xem xét lại
• Đánh giá xem các yêu cầu chất lượng phần mềm đã được đáp ứng hay chưa

Dữ liệu đo lường nên được phân tích và đánh giá. Làm rõ sự sai biệt giữa dự kiến và thực tế sai biệt này có thể xấu hoặc tốt. Một số sai biệt có thể kể đến đó là sai biệt về lịch biểu, sai biệt về chi phí, sai biệt về phạm vi phần mềm. Các hoạt động đánh giá này có thể phát hiện ra vấn đề và các rủi ro có thể xảy ra. Kết quả của các hoạt động này nên được ghi lại.

3.5 Quy trình kiểm soát

Các kết quả của hoạt động giám sát dự án cung cấp cơ sở để đưa ra các quyết định có thể được thực hiện. Khi thấy được rủi ro có thể xảy ra và tác động của các rủi ro đó thì cần thực hiện các thay đổi, điều chỉnh cho dự án. Các hoạt động điều chỉnh diễn ra khi tiến độ dự án không đúng lịch biểu, khi chi phí dự án có nguy cơ tăng, khi chất lượng công việc hoặc chất lượng sản phẩm có nguy cơ giảm. Ứng với mỗi nguyên nhân thì hoạt động cũng phải khác nhau ví dụ như:

Khi dự án diễn ra không đúng lịch biểu thì cần phải điều chỉnh lại lịch biểu, thêm người vào dự án hoặc mua hay thuê thêm thiết bị hoặc phần mềm tốt hơn, cải tiến cách làm việc, tập trung vào các việc chủ chốt và làm thêm giờ.
Khi kinh phí dự án có nguy cơ tăng lên thì nên có các hoạt động sau:

• Hạ thấp yêu cầu chất lượng sản phẩm
• Thuê lao động giá rẻ
• Rút ngắn thời gian huấn luyện
  Khi chất lượng công việc hoặc sản phẩm có nguy cơ giảm
• Tăng cường kiểm tra chất lượng
• Thuê thêm tư vấn
• Tập trung vào những khâu trọng yếu ảnh hưởng đến chất lượng
• Kiểm tra chéo
  Trong một số trường hợp quy trình kiểm soát có thể bị bỏ quên trong dự án. Điều này là không tốt. Vì vậy trong mọi trường hợp cần thực hiện đầy đủ việc kiểm soát. Các quyết định đưa ra nên được ghi chép lại và thông báo cho các bên liên quan được biết. Kế hoạch cũng nên được xem xét lại và sửa đổi khi cần thiết, dữ liệu liên quan cũng cần được ghi chép lại.

3.6 Báo cáo

Báo cáo là việc cần thiết cho việc giám sát và kiểm soát dự án. Người quản lý dự án có trách nhiệm lập báo cáo cho dự án. Tại thời điểm cụ thể đã được thỏa thuận trước thì các nội dung về thời gian, tiến độ cần được báo cáo cho cả hai trong dự án và các bên liên quan bên ngoài như khách hàng hoặc người sử dụng. Báo cáo cần tập trung vào các thông tin cần thiết, tình trạng dự án và các mục tiêu có thể chưa đạt được.

4 Xem xét và đánh giá

Tại các lần được định trước và khi cần thiết, tiến độ tổng thể hướng tới việc đạt được các mục tiêu đề ra và sự hài lòng về yêu cầu của các bên liên quan như người dùng và khách hàng cần được đánh giá. Tương tự như vậy việc đánh giá về hiệu quả, chất lượng phần mềm, các nhân viên tham gia và các công cụ và phương pháp làm việc cũng cần được thực hiện thường xuyên và xác định bởi hoàn cảnh.

4.1 Xác định sự hài lòng của yêu cầu

Bởi vì đạt được sự hài lòng của các bên liên quan là mục tiêu chính của việc quản lý dự án phần mềm, tiến độ đạt được các mục tiêu này nên được đánh giá theo định kỳ. Tiến độ và kết quả của các mốc chính của dự án cần được đánh giá ( ví dụ khi hoàn thành thiết kế kiến trúc cho dự án thì cần đánh giá xem thiết kế kiến trúc đó đã đạt yêu cầu hay chưa) hoặc sau khi hoàn thành một chu kỳ phát triển lặp lại mà kết quả một sản phẩm tăng.

Chênh lệnh từ phần mềm so với yêu cần cần được xác định và cần thực hiện các hành động phù hợp.

Như trong các hoạt động kiểm soát ở phần 3.5 thì quản lý phần mềm và cấu trúc phần mềm cần được theo sát. Khi có cần phải sửa đổi kế hoạch thì phải báo cho các bên liên quan được biết, viết thành tài liệu.

4.2 Xem xét và đánh giá hiệu suất

Đánh giá hiệu suất định kỳ cho cán bộ dự án có thể cung cấp các thông tin như khả năng tuân thủ kế hoạch và quy trình cũng như lĩnh vực mạnh yếu của từng nhân viên, khả năng làm việc trong nhóm. Cần sử dụng các phương pháp khác nhau, các công cụ kỹ thuật được áp dụng để đánh giá chính xác hiệu quả làm việc và sự phù hợp của nhân viên. Nên có hệ thống đánh giá định kỳ, tiện ích trong từng bối cảnh dự án. Khi thích hợp, thay đổi phải được thực hiện và quản lý.

5 Kết thúc dự án

Tổng thể dự án hoặc các pha nhỏ hơn của dự án hoặc quá trình phát triển đi tới đích khi tất cả các kế hoạch hoặc tiến trình đều đã được thực hiện và hoàn thành. Các tiêu chuẩn để đánh giá cũng nên được xem xét. Chỉ khi dự án đã kết thúc thì các hoạt động lưu trữ, cải thiện, đánh giá lại mới được thực hiện

5.1 Quyết định kết thúc dự án

Sự khép lại dự án xảy ra khi các nhiệm vụ cụ thể cho từng pha, vòng lặp hoặc dự án được hoàn thành và các kết quả đạt được cũng phải thỏa mãn các tiêu chuẩn hoàn thành được xác nhận từ trước. Các yêu cầu phần mềm có thể được xác nhận là thỏa mãn hay không và mức độ đạt được các mục tiêu có thể được xác định. Tiến trình kết thúc phải bao gồm các bên liên quan và phải có sự xác nhận hoàn thành bằng văn bản của các bên liên quan đó. Mọi vấn đề còn tồn tại cũng phải được đưa vào văn bản.

5.2 Các hoạt động kết thúc dự án

Sau khi việc kết thúc dự án được xác nhận, việc lưu trữ các tài liệu dự án cần được thực hiện theo sự thỏa thuận với các bên liên quan về phương thức, địa điểm, thời gian . Nó có thể bao gồm cả việc hủy các thông tin nhạy cảm, phần mềm và các phương tiện đang lưu trữ. Cơ sở dữ liệu đánh giá của tổ chức cũng nên được cập nhật với các dữ liệu liên quan tới dự án. Việc phân tích lại các pha của dự án cũng nên được xem lại sao cho các vấn đề, rủi ro, cơ hội gặp phải có thể được phân tích kỹ càng. Các bài học được rút ra từ việc phân tích dự án nên được đưa vào tri thức của tổ chức.

6 Đo lường công nghệ phần mềm

Sự quan trọng của đo lường và vai trò của nó trong việc quản trị và phát triển phần mềm đã được công nhận rộng rãi. Sự đánh giá hiệu quả phần mềm đã trở thành một trong những nền tảng để đo sự trưởng thành của của tổ chức. Đo lường có thể được áp dụng cho tổ chức, dự án, tiến trình và các sản phẩm trong quá trình làm việc. Ở đây chỉ đề cập đến áp dụng của đo lường ở mức độ dự án, tiến trình và các sản phẩm tạo ra. Mô hình đo lường phần mềm cơ bản:

6.1 Cam kết thiết lập và duy trì sự đo lường

• Yêu cầu đo lường: Sự đo lường phải được thiết lập tuân theo các mục tiêu của tổ chức và được định hướng bởi các yêu cầu của tổ chức và dự án (ví dụ một yêu cầu của tổ chức là “sản phẩm tạo ra đầu tiên trên thị trường”)
• Phạm vi đo lường: Các đơn vị thuộc tổ chức mà mỗi yêu cầu đo lường được áp dụng nên được xác định rõ ràng. Nó có thể bao gồm một lĩnh vực chức năng, một dự án, một địa điểm hoặc toàn bộ doanh nghiệp. Ràng buộc thời gian của sự đo lường cũng nên được xem xét cẩn thận vì một số đo lường cần một khoảng thời gian dài ví dụ như để điều chỉnh mô hình dự báo (dự báo nguồn lực, chi phí…)
• Sự cam kết có một nhóm để đo lường phải được thiết lập và phải được hỗ trợ bởi các tài nguyên sẵn có
• Tài nguyên để đo lường: Sự cam kết của tổ chức cho việc đo lường rõ ràng là một yếu tổ cơ bản nhất của sự thành công trong việc đo lường. Đầu tiên là việc phân bổ tài nguyên cho tiến trình đo lường. Các tài nguyên bao gồm con người, công cụ, tiền bạc, sự huấn luyện…

6.2 Lập kế hoạch cho tiến trình đo lường

• Đặc tả đơn vị tổ chức: Đơn vị tổ chức cung cấp bối cảnh để đo lường vì vậy bối cảnh tổ chức cần phải làm rõ ràng bao gồm cả những điều phát hiện ra trong quá trình đo lường. Đặc điểm của tổ chức có thể được ví dụ như các hoạt động doanh nghiệp, công nghệ, cấu trúc doanh nghiệp
• Xác định các thông tin cần thiết: Các thông tin cần thiết dựa vào các mục tiêu, ràng buộc, rủi ro và các vấn đề của tổ chức. Nó có thể được rút ra từ các mục tiêu kinh doanh, mục tiêu doanh nghiệp, mục tiêu luật pháp hoặc mục tiêu sản phẩm. Nó cần phải được xác định và ưu tiên. Sau đó các mục tiêu nhỏ hơn có thể được lựa chọn, làm tài liệu và kiểm tra bởi các bên liên quan.
• Lựa chọn các độ đo: Các độ đo có thể nên được lựa chọn với những liên kết tới các thông tin cần thiết kể trên. Độ đo nên được lựa chọn dựa trên độ ưu tiên của các thông tin cần thiết kết hợp với các tiêu chí khác như chi phí thu thập dữ liệu, khả năng tiến trình bị hủy bỏ trong quá trình thu thập, sự dễ dàng đạt được độ chính xác…
• Định nghĩa quy trình thu thập dữ liệu, phân tích và báo cáo: Việc này bao gồm quy trình thu thập dữ liệu, lưu trữ, kiểm định, phân tích, báo cáo và quản lý dữ liệu
• Lựa chọn các tiêu chuẩn để đánh giá các sản phẩm thông tin: Các tiêu chuẩn để đánh giá bị ảnh hưởng bởi các mục tiêu kinh doanh cũng như kỹ thuật của tổ chức. Các sản phẩm thông tin bao gồm những cái liên quan đến sản phẩm đang được làm cũng như những cái liên quan tới các tiến trình đang được sử dụng để quản lý và đo lường dự án
• Cung cấp tài nguyên cho công việc đánh giá: Kế hoạch đánh giá phải được xem xét và chấp thuận bởi các bên liên quan bao gồm tất cả các thủ tục thu thập dữ liệu, lưu trữ, phân tích và báo cáo; các tiêu chuẩn đánh giá, lập lịch và các trách nhiệm liên đới. Các tiêu chuẩn để đánh giá các sản phẩm trên phải được thiết lập ở mức độ tổ chức hoặc cao hơn để có thể làm nền tảng cho những công việc việc xem xét này. Những tiêu chuẩn đó nên được tham khảo từ những kinh nghiệm của các dự án trước, sự sẵn sàng của các nguồn lực hiện tại. Sự thông qua biểu thị cho sự đồng thuận tiến trình đánh giá
• Xác định tài nguyên để thực hiện các tác vụ đã được chấp thuận và lên kế hoạch: Các tài nguyên sẵn có có thể được cấp dần dần vì có thể sẽ phải thử nghiệm trước khi được áp dụng rộng rãi. Đặc biệt chú ý tới yêu cầu tài nguyên cần thiết để triển khai một tiến trình hoặc độ đo mới.
• Mua và triển khai các công nghệ hỗ trợ: Việc này bao gồm sự đánh giá các công nghệ hỗ trợ hiện có, lựa chọn công nghệ phù hợp nhất, mua lại nó và triển khai để sẵn sàng sử dụng

Danh sách các nhóm độ đo dùng để đo lường ví dụ: Sau khi có danh sách những độ đo, chọn những độ đo tốt nhất phù hợp tổ chức Một ví dụ về biểu đồ dự đoán nhân lực trong bước lập kế hoạch

6.3 Thực hiện tiến trình đo lường

• Tích hợp thủ tục đo lường với các tiến trình phần mềm liên quan: Thủ tục đo lường như thu thập dữ liệu, phải được tích hợp vào tiến trình phần mềm nó đang đo lường. Việc này có thể bao gồm thay đổi tiến trình phần mềm hiện tại cho phù hợp với việc thu thập dữ liệu. Nó cũng có thể bao gồm việc phần tích tiến trình phần mềm hiện tại để giảm tối đa công sức và ảnh hưởng tới người sử dụng sao cho tiến trình này được chấp nhận. Việc huấn luyện và hỗ trợ cũng cần phải được cung cấp. Tiến trình phân tích dữ liệu và báo cáo thường được tích hợp vào tiến trình dự án theo một cách tương tự.
• Thu thập dữ liệu: Dữ liệu phải được thu thập, kiểm định và lưu trữ. Việc thu thập dữ liệu nhiều khi cũng được tự động hóa bằng các công cụ phần mềm hỗ trợ. Dữ liệu sau đó có thể được tổng hợp, chuyển đổi và lưu trữ như một phần của tiến trình phân tích. Kêt quả của quá trình phân tích thường được thể hiện bằng biểu đồ, số hoặc những thứ tương tự, từ đó có thể được gửi tới các bên liên quan. Các kết quả và kết luận thường được xem xét lại bằng một tiến trình định nghĩa bởi tổ chức (hình thức hoặc không hình thức). Người cung cấp dữ liệu và người thực hiện đánh giá nên tham gia vào quá trình xem xét lại này nhằm đảm bảo tính chính xác và có ý nghĩa của dữ liệu thu được.

Ví dụ về biểu đồ sau khi phân tích dữ liệu

• Truyền đạt kết quả: Những sản phẩm thông tin phải được làm tài liệu và truyền đạt lại cho người dùng và các bên liên quan

6.4 Đánh giá sự đo lường

• Đánh giá sản phẩm thông tin và các tiến trình đánh giá với các tiêu chuẩn đánh giá đồng thời xem xét độ mạnh yếu của sản phẩm thông tin tương ứng. Sự đánh giá này có thể được thực hiện bởi các tiến trình nội bộ hoặc các tổ chức bên ngoài. Nó thường bao gồm các thông tin phản hồi từ phía người dùng tham gia đánh giá. Những bài học thu được nên được ghi lại vào cơ sở dữ liệu thích hợp
• Xác định sự cải tiến trong tương lai: Sự cải thiện này có thể trong cách biểu thị, đơn vị đo hoặc phân loại lại các danh mục đánh giá. Chi phí và lợi ích của sự cải thiện này nên được xác định và các hành động cải tiến thích hợp nên được báo cáo lại
• Truyền đạt các cải tiến đề xuất cho người chủ tiến trình và các bên liên quan để xem xét và thông qua nó.

Ví dụ về biểu đồ đánh giá

7 Các công cụ quản lý công nghệ phần mềm

Các công cụ quản lý công nghệ phần mềm thường được sử dụng để cung cấp tầm nhìn xa và quản lý tiến trình quản lý công nghệ phần mềm. Một số công cụ tự động và một số công cụ phải viết bằng tay. Các công cụ phục vụ quản lý công nghệ phần mềm có thể được chia thành một số loại như sau:

• Công cụ lập kế hoạch và lần vết: Công cụ này dùng để ước lượng nhân công dự án, chi phí và để chuẩn bị việc lập kế hoạch dự án. Công cụ lập kế hoạch cũng có thể bao gồm công cụ lập lịch tự động, các công cụ này phân tích các tác vụ trong bảng phân rã công việc, thời gian dự kiến, mối quan hệ trước sau… để đưa ra một lịch trình công việc dưới dạng biểu đồ Gantt. Công cụ lần vết có thể được sử dụng để theo dõi các mốc dự án, lên lịch họp và các hành động

Một ví dụ về công cụ lập kế hoạch Microsoft Visio

• Công cụ quản lý rủi ro: Công cụ này dùng để lần vết sự xuất hiện lỗi, dự đoán lỗi hoặc theo dõi lỗi. Nó sử dụng một trong các phương pháp như mô phỏng hoặc cây quyết định Công cụ RiskNav là một công cụ khá phổ biến để quản lý rủi ro. Nó mô tả không gian lỗi theo hai dạng bảng và đồ họa như hình dưới
• Công cụ tương tác: Công cụ này giúp việc cung cấp thông tin kịp thời, thống nhất đến các đối tượng liên quan tới dự án. Những công cụ này có thể bao gồm những việc như thông báo email và quảng bá đến tất cả thành viên dự án cũng như những người có liên quan. Nó cũng bao gồm việc thông tin về thời gian của kế hoạch dự án, họp đứng, backlog…

Một ví dụ về công cụ tương tác Skype

• Công cụ đánh giá: Công cụ này hỗ trợ hoạt động liên quan tới chương trình đánh giá phần mềm. Nó có rất ít công cụ tự động hỗ trợ việc này. Các công cụ đánh giá được sử dụng để thu thập, phân tích và báo cáo dữ liệu đánh giá dự án có thể dựa trên các bảng tính của các thành viên dự án hoặc của các nhân viên trong tổ chức Công cụ phổ biến đùng để hỗ trợ việc đánh giá dự án có thể kể tới là PSM Insight. Đây là một công cụ được tài trợ bởi bộ Tư Pháp Mỹ và vẫn đang tiếp tục được phát triển