T I ê uchu ẩ n q u ố c g I a


Các quá trình phần mềm đặc thù



tải về 1.07 Mb.
trang10/16
Chuyển đổi dữ liệu01.10.2016
Kích1.07 Mb.
#32543
1   ...   6   7   8   9   10   11   12   13   ...   16

7 Các quá trình phần mềm đặc thù

7.1 Các quá trình triển khai phần mềm

7.1.1 Quá trình triển khai phần mềm


CHÚ THÍCH: Quá trình triển khai phần mềm là một trường hợp tuân thủ quá trình triển khai trong tiêu chuẩn ISO/IEC 15288, cụ thể hóa các nhu cầu cụ thể từ việc triển khai một sản phẩm phần mềm hoặc dịch vụ.

7.1.1.1 Mục đích

Mục đích của quá trình triển khai phần mềm là để tạo ra một thành phần hệ thống xác định được triển khai như một sản phẩm phần mềm hoặc dịch vụ phần mềm.

Quá trình này chuyển đổi các giao diện, tính năng xác định và các ràng buộc triển khai thành các hoạt động tạo ra một thành phần hệ thống triển khai như một sản phẩm hoặc dịch vụ phần mềm, còn được biết đến như là “thành phần phần mềm”. Quá trình này tạo ra một thành phần phần mềm mà thỏa mãn các yêu cầu thiết kế kiến trúc thông qua việc xác minh và các yêu cầu của bên liên quan thông qua việc xác nhận.

7.1.1.2 Kết quả

Kết quả triển khai thành công của quá trình triển khai phần mềm gồm:



  1. Chiến lược triển khai được định nghĩa;

  2. Các ràng buộc công nghệ triển khai đối với thiết kế được nhận biết;

  3. Thành phần phần mềm được thực hiện;

  4. Thành phần phần mềm được đóng gói và lưu trữ theo sự thỏa thuận về việc cung cấp của nó.

Ngoài các hoạt động của nó, quá trình triển khai phần mềm có các quá trình mức độ thấp hơn như sau:

  • Quá trình phân tích các yêu cầu phần mềm*;

  • Quá trình thiết kế kiến trúc phần mềm*;

  • Quá trình thiết kế chi tiết phần mềm;

  • Quá trình xây dựng phần mềm;

  • Quá trình tích hợp phần mềm*;

  • Quá trình kiểm tra chất lượng phần mềm*.

CHÚ THÍCH: Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng các quá trình đánh dấu bằng dấu sao (*) trong danh sách liệt kê trên được cung cấp bởi việc áp dụng đệ quy của tiêu chuẩn ISO/IEC 15288 ngay cả đối với các thành phần phần mềm của hệ thống.

7.1.1.3 Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình triển khai phần mềm.



7.1.1.3.1 Chiến lược triển khai phần mềm

Hoạt động này bao gồm các nhiệm vụ sau:



7.1.1.3.1.1 Nếu không được quy định trong hợp đồng, bên phát triển phải định nghĩa hoặc lựa chọn một mô hình vòng đời phù hợp với phạm vi, tầm quan trọng và độ phức tạp của dự án. Mô hình vòng đời phải bao gồm các giai đoạn, mục đích và kết quả của mỗi giai đoạn. Các hoạt động và nhiệm vụ của quá trình triển khai phải được lựa chọn và ánh xạ lên trên mô hình vòng đời.

CHÚ THÍCH: Các hoạt động và nhiệm vụ này có thể chồng lên nhau hoặc tác động lẫn nhau và có thể được thực hiện một cách lặp đi lặp lại hoặc một cách đệ quy.

CHÚ THÍCH: Một cách lý tưởng, điều này được thực hiện bằng cách sử dụng một mô hình vòng đời xác định một cách có tổ chức.

7.1.1.3.1.2 Bên triển khai phải:


  1. Tài liệu hóa kết quả phù hợp với quá trình quản lý tài liệu hướng dẫn phần mềm (mục 7.2.1);

  2. Đặt kết quả dưới quá trình quản lý cấu hình phần mềm (mục 7.2.2) và thực hiện kiểm soát thay đổi phù hợp với nó;

  3. Tài liệu hóa và giải quyết các vấn đề và các điều không phù hợp được phát hiện trong các các nhiệm vụ và sản phẩm phần mềm phù hợp với quá trình giải quyết vấn đề phần mềm (mục 7.2.8);

  4. Thực hiện việc hỗ trợ các quá trình như chỉ định trong hợp đồng;

  5. Thiết lập các giới hạn cơ bản và bổ sung thêm các thành phần cấu hình tại các thời điểm thích hợp, như đã định nghĩa bởi bên mua sản phẩm và nhà cung cấp.

7.1.1.3.1.3 Bên triển khai phải lựa chọn, sửa đổi và sử dụng các tiêu chuẩn, các công cụ, các phương pháp và ngôn ngữ lập trình máy tính này (nếu không được quy định trong hợp đồng) mà đã được tài liệu hóa, phù hợp và được tổ chức thiết lập cho việc thực hiện các hoạt động của quá trình triển khai phần mềm và hỗ trợ các quá trình.

CHÚ THÍCH: Các ràng buộc công nghệ triển khai vào bản thiết kế nên được nhận biết như một phần của chiến lược triển khai phần mềm.



7.1.1.3.1.4 Bên triển khai phải phát triển các kế hoạch cho việc tiến hành các hoạt động của quá trình triển khai phần mềm. Các kế hoạch nên bao gồm trách nhiệm, các hoạt động, các công cụ, các phương pháp và các tiêu chuẩn cụ thể có liên quan tới việc phát triển và chất lượng của tất cả các yêu cầu bao gồm cả độ tin cậy và tính an toàn. Nếu cần thiết, các kế hoạch riêng rẽ có thể được phát triển. Các kế hoạch này phải được tài liệu hóa và thực thi.

7.1.1.3.1.5 Các thành phần không thể chuyển giao có thể được sử dụng trong việc phát triển hoặc bảo trì sản phẩm phần mềm. Tuy nhiên, phải được đảm bảo rằng việc vận hành và bảo trì sản phẩm phần mềm có thể chuyển giao sau khi chuyển giao tới bên mua sản phẩm là độc lập với các thành phần đó; nếu không thì, các thành phần đó nên được xem như là có thể chuyển giao.

7.1.2 Quá trình phân tích các yêu cầu phần mềm


CHÚ THÍCH: Quá trình phần tích các yêu cầu phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn quá trình triển khai phần mềm. Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng quá trình này được cung cấp bởi quá trình phân tích các yêu cầu của tiêu chuẩn ISO/IEC 15288 trong việc áp dụng đệ quy tiêu chuẩn đó.

7.1.2.1 Mục đích

Mục đích của quá trình phân tích các yêu cầu phần mềm là để thiết lập các yêu cầu của các thành phần phần mềm hệ thống.



7.1.2.2 Kết quả

Kết quả triển khai thành công của quá trình phân tích các yêu cầu phần mềm gồm:



  1. Các yêu cầu được phân phối tới các thành phần phần mềm của hệ thống và các giao diện của nó được định nghĩa;

  2. Các yêu cầu phần mềm được phân tích về tính đúng đắn và khả năng kiểm tra;

  3. Ảnh hưởng của các yêu cầu phần mềm vào môi trường vận hành được hiểu rõ;

  4. Tính kiên định và khả năng theo dõi được thiết lập giữa các yêu cầu phần mềm và các yêu cầu hệ thống;

  5. Sự ưu tiên trong việc thực thi các yêu cầu phần mềm được định nghĩa;

  6. Các yêu cầu phần mềm được chấp thuận và cập nhật khi cần thiết;

  7. Các thay đổi tới các yêu cầu phần mềm được đánh giá về tác động kỹ thuật, thời hạn và chi phí;

  8. Các yêu cầu phần mềm được giới hạn cơ bản và thông báo tới tất cả các bên tham gia chịu ảnh hưởng.

7.1.2.3 Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động và nhiệm vụ sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng với sự lien quan tới quá trình phân tích các yêu cầu phần mềm.



7.1.2.3.1 Phân tích các yêu cầu phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:



7.1.2.3.1.1 Bên triển khai phải thiết lập và tài liệu hóa các yêu cầu phần mềm (bao gồm các đặc tả các đặc tính chất lượng) được mô tả dưới đây:

  1. Các đặc tả khả năng và chức năng, bao gồm hiệu năng, các đặc tính vật lý và các điều kiện môi trường trong đó thành phần phần mềm được thực hiện;

  2. Các giao diện ngoài thành phần phần mềm;

  3. Các yêu cầu chất lượng;

  4. Các đặc tả độ tin cậy, bao gồm những việc liên quan tới các phương pháp vận hành và bảo trì, các tác động của môi trường và tổn hại tới con người;

  5. Các đặc tả tính an toàn, bao gồm những việc liên quan tới sự thỏa hiệp thông tin nhạy cảm;

  6. Các đặc tả kỹ thuật có tính đến nhân tố con người (tối ưu yếu tố con người), bao gồm những việc liên quan đến các vận hành thủ công, các sự tương tác giữa người-thiết bị, các ràng buộc về nhân sự và các phạm vi cần tập trung chú ý nhân lực, chịu ảnh hưởng bởi việc đào tạo và các sai sót do nhân sự;

  7. Các yêu cầu cơ sở dữ liệu và việc định nghĩa dữ liệu;

  8. Các yêu cầu tiếp nhận và cài đặt sản phẩm phần mềm được chuyển giao tại bên vận hành và bảo trì;

  9. Các yêu cầu tài liệu hướng dẫn người sử dụng;

  10. Các yêu cầu thực thi và vận hành từ người sử dụng;

  11. Các yêu cầu bảo trì từ người sử dụng.

CHÚ THÍCH 1: Sự hướng dẫn về việc xác định các đặc tính chất lượng có thể được tìm trong tiêu chuẩn ISO/IEC 9126-1.

CHÚ THÍCH 2: Việc ưu thực thi các yêu cầu phần mềm nên được xác định.

CHÚ THÍCH 3: Nếu tính khả dụng là một yêu cầu quan trọng, các khuyến nghị để đạt được mức mong muốn về tính khả dụng có thể tìm trong tiêu chuẩn ISO TR 18529. Phụ lục E bao gồm một quá trình tổng quan tập trung vào tính khả dụng.

7.1.2.3.1.2 Bên triển khai phải đánh giá các yêu cầu phần mềm bằng cách xem xét tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.


  1. Khả năng theo dõi các yêu cầu của hệ thống và thiết kế của hệ thống;

  2. Tính kiên định ngoài với các yêu cầu của hệ thống;

  3. Tính kiên định trong;

  4. Khả năng kiểm tra;

  5. Tính khả thi của thiết kế phần mềm;

  6. Tính khả thi của việc vận hành và bảo trì.

7.1.2.3.1.3 Bên triển khai phải tiến hành soát xét phù hợp với mục 7.2.6.

CHÚ THÍCH: Tiếp sau quá trình soát xét và đánh giá thành công, các yêu cầu phần mềm nên được chấp thuận, giới hạn cơ bản và thông báo tới tất cả bên tham gia chịu ảnh hưởng. Các thay đổi sau đó tới giới hạn cơ bản các yêu cầu phần mềm nên được đánh giá về ảnh hưởng kỹ thuật, thời hạn và chi phí.


7.1.3 Quá trình thiết kế kiến trúc phần mềm


CHÚ THÍCH: Quá trình thiết kế kiến trúc phần mềm trong tiêu chuẩn này là quá trình mức độ thấp hơn của quá trình triển khai phần mềm. Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng quá trình này được thực hiện bởi quá trình thiết kế kiến trúc của tiêu chuẩn ISO/IEC 15288 trong việc áp dụng đệ quy của tiêu chuẩn đó.

7.1.3.1 Mục đích

Mục đích của quá trình thiết kế kiến trúc phần mềm là để cung cấp bản thiết kế phần mềm mà triển khai và có thể được xác minh dựa vào các yêu cầu.



7.1.3.2 Kết quả

Kết quả triển khai thành công của quá trình thiết kế kiến trúc phần mềm gồm:



  1. Bản thiết kế kiến trúc phần mềm được phát triển và được giới hạn cơ bản để mô tả các thành phần phần mềm thực thi các yêu cầu phần mềm;

  2. Các giao diện ngoài và trong mỗi thành phần phần mềm được định nghĩa;

  3. Tính kiên định và khả năng theo dõi được thiết lập giữa các yêu cầu phần mềm và thiết kế phần mềm.

7.1.3.3 Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động sau đây phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình thiết kế kiến trúc phần mềm.

CHÚ THÍCH: Hoạt động này được triển khai đối với mỗi thành phần phần mềm, thống nhất với thiết kế kiến trúc hệ thống.

7.1.3.3.1 Thiết kế kiến trúc phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:



7.1.3.3.1.1 Bên triển khai phải chuyển đổi các yêu cầu đối với thành phần phần mềm thành kiến trúc mô tả cơ cấu hoàn chỉnh của nó và nhận biết các thành phần phần mềm. Nó phải được đảm bảo rằng tất cả các yêu cầu đối với thành phần phần mềm được phân phối tới các thành phần phần mềm của nó và tinh giản hơn nữa để thuận tiện thiết kế chi tiết. Kiến trúc thành phần phần mềm phải được tài liệu hóa.

CHÚ THÍCH: Thiết kế kiến trúc phần mềm cũng cung cấp cơ cở cho việc xác minh các thành phần phần mềm, tích hợp các thành phần phần mềm với mỗi thành phần khác và tích hợp các thành phần phần mềm với phần còn lại của các thành phần hệ thống.



7.1.3.3.1.2 Bên triển khai phải phát triển và tài liệu hóa thiết kế chỉnh về các giao diện ngoài đối với thành phần phần mềm và giữa các phần tử phần mềm của thành phần phần mềm đó.

7.1.3.3.1.3 Bên triển khai phải phát triển và tài liệu hóa thiết kế hoàn chỉnh về cơ sở dữ liệu.

7.1.3.3.1.4 Bên triển khai phải phát triển và tài liệu hóa các phiên bản sơ bộ của tài liệu hướng dẫn người sử dụng.

7.1.3.3.1.5 Bên triển khai phải định nghĩa và tài liệu hóa lịch trình và các yêu cầu kiểm tra sơ bộ đối với việc tích hợp phần mềm.

7.1.3.3.1.6 Bên triển khai phải đánh giá kiến trúc thành phần phần mềm, giao diện và các thiết kế cơ sở dữ liệu bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

  1. Khả năng theo dõi các yêu cầu thành phần phần mềm;

  2. Tính kiên định ngoài với các yêu cầu của thành phần phần mềm;

  3. Tính kiên định trong giữa các thành phần phần mềm;

  4. Sự phù hợp của các tiêu chuẩn và các phương pháp thiết kế được sử dụng;

  5. Tính khả thi của thiết kế chi tiết;

  6. Tính khả thi của việc vận hành và bảo trì.

7.1.3.3.1.7 Bên triển khai phải tiến hành soát xét phù hợp với mục 7.2.6

7.1.4 Quá trình thiết kế chi tiết phần mềm


CHÚ THÍCH: Quá trình thiết kế chi tiết phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn của quá trình triển khai phần mềm.

7.1.4.1 Mục đích

Mục đích của quá trình thiết kế chi tiết phần mềm là để cung cấp bản thiết kế phần mềm mà phải triển khai và có thể được xác minh dựa vào các yêu cầu và kiến trúc phần mềm và được trình bày chi tiết một cách đầy đủ để cho phép mã hóa và kiểm tra.



7.1.4.2 Kết quả

Kết quả triển khai thành công của quá trình thiết kế chi tiết phần mềm gồm:



  1. Bản thiết kế chi tiết của mỗi phần tử phần mềm, bằng cách mô tả các đơn vị phần mềm được xây dựng lên, được phát triển;

  2. Các giao diện ngoài của mỗi đơn vị phần mềm được định nghĩa;

  3. Tính kiên định và khả năng theo dõi được thiết lập giữa các yêu cầu, thiết kế chi tiết và thiết kế kiến trúc.

7.1.4.3 Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình thiết kế chi tiết phần mềm.



7.1.4.3.1 Thiết kế chi tiết phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:



7.1.4.3.1.1 Bên triển khai phải phát triển thiết kế chi tiết đối với mỗi phần tử phần mềm của thành phần phần mềm. Các phần tử phần mềm phải được tinh giản thành các mức độ thấp hơn bao gồm các đơn vị phần mềm mà có thể được mã hóa, biên dịch và kiểm tra. Nó phải được đảm bảo rằng tất cả các yêu cầu phần mềm được phân phối từ các phần tử phần mềm tới các đơn vị phần mềm. Thiết kế chi tiết phần mềm phải được tài liệu hóa.

7.1.4.3.1.2 Bên triển khai phải phát triển và tài liệu hóa thiết kế chi tiết đối với các giao diện ngoài thành phần phần mềm, giữa các phần tử phần mềm và giữa các đơn vị phần mềm. Thiết kế chi tiết các giao diện phải cho phép mã hóa mà không yêu cầu thông tin bổ sung nào.

7.1.4.3.1.3 Bên triển khai phải phát triển và tài liệu hóa thiết kết chi tiết về cơ sở dữ liệu.

7.1.4.3.1.4 Bên triển khai phải cập nhật tài liệu hướng dẫn người sử dụng khi cần thiết.

7.1.4.3.1.5 Bên triển khai phải định nghĩa và tài liệu hóa lịch trình và các yêu cầu kiểm tra để kiểm tra các đơn vị phần mềm. Các yêu cầu kiểm tra nên bao gồm việc nhấn mạnh đơn vị phần mềm tại các giới hạn các yêu cầu của nó.

7.1.4.3.1.6 Bên triển khai phải cập nhật lịch trình và các yêu cầu kiểm tra đối với việc tích hợp phần mềm.

7.1.4.3.1.7 Bên triển khai phải đánh giá thiết kế chi tiết phần mềm và các yêu cầu kiểm tra bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa:

  1. Khả năng theo dõi các yêu cầu thành phần phần mềm;

  2. Tính kiên định ngoài đối với thiết kế kiến trúc;

  3. Tính kiên định trong giữa các thành phần phần mềm và các đơn vị phần mềm;

  4. Sự phù hợp của các tiêu chuẩn và các phương pháp thiết kế được sử dụng;

  5. Tính khả thi của việc kiểm tra;

  6. Tính khả thi của việc vận hành và bảo trì.

7.1.4.3.1.8 Bên triển khai phải tiến hành soát xét phù hợp với mục 7.2.6.

7.1.5 Quá trình xây dựng phần mềm


CHÚ THÍCH: Quá trình xây dựng phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn của quá trình triển khai phần mềm.

7.1.5.1 Mục đích

Mục đích của quá trình xây dựng phần mềm là để đưa ra các đơn vị phần mềm có thể thực thi mà phản ánh một cách chính xác bản thiết kế phần mềm đó.



7.1.5.2 Kết quả

Kết quả triển khai thành công của quá trình xây dựng phần mềm gồm:



  1. Các tiêu chí xác minh được định nghĩa đối với tất cả đơn vị phần mềm dựa vào các yêu cầu của chúng;

  2. Các đơn vị phần mềm được định nghĩa bằng bản thiết kế được đưa ra;

  3. Tính kiên định và khả năng theo dõi được thiết lập giữa các yêu cầu, các đơn vị phần mềm và thiết kế;

  4. Việc xác minh các đơn vị phần mềm dựa vào các yêu cầu và thiết kế được hoàn thiện.

7.1.5.3 Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động và nhiệm vụ sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình xây dựng phần mềm.



7.1.5.3.1 Xây dựng phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:



7.1.5.3.1.1 Bên triển khai phải phát triển và tài liệu hóa các điều sau:

  1. Mỗi cơ sở dữ liệu và đơn vị phần mềm;

  2. Dữ liệu và các thủ tục kiểm tra để kiểm tra mỗi cơ sở dữ liệu và đơn vị phần mềm.

7.1.5.3.1.2 Bên triển khai phải kiểm tra mỗi cơ sở dữ liệu và đơn vị phần mềm để đảm bảo rằng nó đáp ứng các yêu cầu. Kết quả kiểm tra phải được tài liệu hóa.

7.1.5.3.1.3 Bên triển khai phải cập nhật tài liệu hướng dẫn người sử dụng khi cần thiết.

7.1.5.3.1.4 Bên triển khai phải cập nhật lịch trình và các yêu cầu kiểm tra đối với việc tích hợp phần mềm.

7.1.5.3.1.5 Bên triển khai phải đánh giá việc mã hóa phần mềm và kết quả kiểm tra bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

  1. Khả năng theo dõi các yêu cầu và thiết kế thành phần phần mềm;

  2. Tính kiên định ngoài đối với các yêu cầu và thiết kế thành phần phần mềm;

  3. Tính kiên định trong giữa các yêu cầu đơn vị;

  4. Phạm vi kiểm tra các đơn vị;

  5. Sự phù hợp của các tiêu chuẩn và các phương pháp mã hóa được sử dụng;

  6. Tính khả thi của việc kiểm tra và tích hợp phần mềm;

  7. Tính khả thi của việc vận hành và bảo trì.

7.1.6 Quá trình tích hợp phần mềm


CHÚ THÍCH: Quá trình tích hợp phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn của quá trình triển khai phần mềm. Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng quá trình này được thực hiện bởi quá trình tích hợp của tiêu chuẩn ISO/IEC 15288 trong việc áp dụng đệ quy của tiêu chuẩn đó.

7.1.6.1 Mục đích

Mục đích của quá trình tích hợp phần mềm là để kết hợp các đơn vị phần mềm và các phần tử phần mềm, tạo ra các thành phần phần mềm tích hợp, phù hợp với thiết kế phần mềm, thỏa mãn các yêu cầu phần mềm thuộc chức năng hoặc không thuộc chức năng dựa vào nền tảng hoạt động hoàn chỉnh hoặc tương đương



7.1.6.2 Kết quả

Kết quả triển khai thành công của quá trình tích hợp phần mềm gồm:



  1. Chiến lược tích hợp được phát triển đối với các đơn vị phần mềm thống nhất với bản thiết kế phần mềm và các yêu cầu phần mềm ưu tiên;

  2. Các tiêu chí xác minh đối với các thành phần phần mềm được phát triển để đảm bảo phù hợp với các yêu cầu phần mềm được phân phối tới các thành phần phần mềm;

  3. Các thành phần phần mềm được xác minh sử dụng các tiêu chí xác định;

  4. Các thành phần phần mềm được định nghĩa bằng chiến lược tích hợp được đưa ra;

  5. Kết quả của việc kiểm tra tích hợp được ghi lại;

  6. Tính kiên định và khả năng theo dõi được thiết lập giữa thiết kế phần mềm và các thành phần phần mềm;

  7. Chiến lược hồi quy được phát triển và áp dụng để xác minh lại các thành phần phần mềm khi xảy ra thay đổi trong các đơn vị phần mềm (bao gồm mã hóa, thiết kế và các yêu cầu liên kết).

7.1.6.3 Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động và nhiệm vụ sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình tích hợp phần mềm.



7.1.6.3.1 Tích hợp phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:



7.1.6.3.1.1 Bên triển khai phải phát triển kế hoạch tích hợp để tích hợp các đơn vị phần mềm và các phần tử phần mềm vào trong thành phần phần mềm. Kế hoạch phải bao gồm các yêu cầu kiểm tra, các thủ tục, dữ liệu, các trách nhiệm và lịch trình. Kế hoạch này phải được tài liệu hóa.

7.1.6.3.1.2 Bên triển khai phải tích hợp các đơn vị phần mềm, các phần tử phần mềm và kiểm tra khi toàn bộ các phần tử được thực hiện phù hợp với kế hoạch tích hợp. Nó phải được đảm bảo rằng mỗi tổng thể đáp ứng các yêu cầu thành phần phần mềm và thành phần phần mềm đó được tích hợp tại thời điểm cuối của hoạt động tích hợp. Kết quả kiểm tra và tích hợp phải được tài liệu hóa.

CHÚ THÍCH: Chiến lược hồi quy nên được phát triển nhằm áp dụng để xác minh lại các thành phần phần mềm khi thay đổi được thực hiện trong các thành phần phần mềm (bao gồm mã hóa, thiết kế và các yêu cầu liên kết).



7.1.6.3.1.3 Bên triển khai phải cập nhật tài liệu hướng dẫn người sử dụng khi cần thiết.

7.1.6.3.1.4 Bên triển khai phải phát triển và tài liệu hóa đối với mỗi yêu cầu chất lượng của thành phần phần mềm, một bộ các bài kiểm tra, các trường hợp kiểm tra (các đầu vào, đầu ra, tiêu chí kiểm tra) và các thủ tục kiểm tra để tiến hành kiểm tra chất lượng phần mềm. Bên phát triển phải đảm bảo rằng thành phần phần mềm tích hợp là sẵn sàng đối với việc kiểm tra chất lượng phần mềm.

7.1.6.3.1.5 Bên triển khai phải đánh giá kế hoạch tích hợp, thiết kế, mã hóa, các bài đo, kết quả kiểm tra và tài liệu hướng dẫn người sử dụng bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

  1. Khả năng theo dõi các yêu cầu hệ thống;

  2. Tính kiên định ngoài đối với các yêu cầu hệ thống;

  3. Tính kiên định trong;

  4. Phạm vi kiểm tra các yêu cầu thành phần phần mềm;

  5. Sự phù hợp của các tiêu chuẩn và các phương pháp kiểm tra được sử dụng;

  6. Sự tuân thủ theo kết quả được kỳ vọng;

  7. Tính khả thi của việc kiểm tra chất lượng phần mềm;

  8. Tính khả thi của việc vận hành và bảo trì.

CHÚ THÍCH: Các tiêu chí đánh giá nên bao gồm Tính kiên định và khả năng theo dõi giữa thiết kế phần mềm và các thành phần phần mềm.

7.1.6.3.1.6 Bên triển khai phải tiến hành soát xét phù hợp với mục 7.2.6.

7.1.7 Quá trình kiểm tra chất lượng phần mềm


CHÚ THÍCH: Quá trình kiểm tra chất lượng phần mềm trong tiêu chuẩn này là một quá trình mức độ thấp hơn của quá trình triển khai phần mềm. Người sử dụng tiêu chuẩn ISO/IEC 15288 có thể quyết định rằng quá trình này được thực hiện bởi quá trình xác minh của tiêu chuẩn ISO/IEC 15288 trong việc áp dụng đệ quy của tiêu chuẩn đó.

7.1.7.1 Mục đích

Mục đích của quá trình kiểm tra chất lượng phần mềm là để xác nhận rằng sản phẩm phần mềm được tích hợp đáp ứng các yêu cầu xác định của nó.



7.1.7.2 Kết quả

Kết quả triển khai thành công của quá trình kiểm tra chất lượng phần mềm gồm:



  1. Tiêu chí đối với phần mềm tích hợp được phát triển cho thấy sự tuân thủ đúng với các yêu cầu phần mềm;

  2. Phần mềm tích hợp được xác minh bằng cách sử dụng các tiêu chí xác định;

  3. Kết quả kiểm tra được ghi lại;

  4. Chiến lược hồi quy được phát triển và áp dụng để kiểm tra lại phần mềm tích hợp khi sự thay đổi trong các thành phần phần mềm được thực hiện.

CHÚ THÍCH: Chiến lược hồi quy nên được phát triển, nhằm áp dụng để kiểm tra lại phần mềm tích hợp khi sự thay đổi được thực hiện trong các thành phần phần mềm.

7.1.7.3 Hoạt động và nhiệm vụ

Dự án phải triển khai các hoạt động sau phù hợp với các thủ tục và chính sách có tổ chức có khả năng áp dụng trong quá trình kiểm tra chất lượng phần mềm.



7.1.7.3.1 Kiểm tra chất lượng phần mềm

Đối với mỗi thành phần phần mềm (hoặc thành phần cấu hình, nếu được định nghĩa) hoạt động này bao gồm các nhiệm vụ sau:



7.1.7.3.1.1 Bên triển khai phải tiến hành kiểm tra chất lượng phù hợp với các yêu cầu chất lượng đối với thành phần phần mềm. Nó phải được đảm bảo rằng việc triển khai mỗi yêu cầu phần mềm được kiểm tra phù hợp. Kết quả kiểm tra chất lượng phải được tài liệu hóa.

7.1.7.3.1.2 Bên triển khai phải cập nhật tài liệu hướng dẫn người sử dụng khi cần thiết.

7.1.7.3.1.3 Bên triển khai phải đánh giá thiết kế, mã hóa, các bài kiểm tra, kết quả kiểm tra và tài liệu hướng dẫn người sử dụng bằng cách xem xét các tiêu chí được liệt kê dưới đây. Kết quả của các đánh giá phải được tài liệu hóa.

  1. Phạm vi kiểm tra các yêu cầu của thành phần phần mềm;

  2. Sự tuân thủ theo kết quả được kỳ vọng;

  3. Tính khả thi của việc kiểm tra và tích hợp phần mềm, nếu được tiến hành;

  4. Tính khả thi của việc vận hành và bảo trì.

7.1.7.3.1.4 Bên triển khai phải hỗ trợ kiểm tra phù hợp với mục 7.2.7. Kết quả của việc kiểm tra phải được tài liệu hóa. Nếu cả phần cứng và phần mềm đang phát triển hoặc tích hợp, việc kiểm tra có thể được đình chỉ lại cho đến khi kiểm tra chất lượng hệ thống.

7.1.7.3.1.5 Khi hoàn thiện thành công các việc kiểm tra, nếu được tiến hành, bên triển khai phải cập nhật và chuẩn bị sản phẩm phần mềm chuyển giao đối với việc tích hợp hệ thống, kiểm tra chất lượng hệ thống, cài đặt phần mềm hoặc hỗ trợ tiếp nhận phần mềm khi có thể áp dụng.

CHÚ THÍCH: Quá trình kiểm tra chất lượng phần mềm có thể được sử dụng trong quá trình xác minh phần mềm (mục 7.2.4) hoặc quá trình xác nhận phần mềm (mục 7.2.5).



Каталог: Upload -> Store -> tintuc -> vietnam
vietnam -> BỘ thông tin truyềN thông thuyết minh đỀ TÀi xây dựng quy chuẩn kỹ thuật thiết bị giải mã truyền hình số MẶT ĐẤt set – top box (stb)
vietnam -> Kết luận số 57-kl/tw ngày 8/3/2013 của Ban Bí thư về tiếp tục đẩy mạnh công tác đào tạo, bồi dưỡng lý luận chính trị cho cán bộ lãnh đạo, quản lý các cấp
vietnam -> BỘ thông tin và truyềN thôNG
vietnam -> Quyết định số 46-QĐ/tw ngày 1/11/2011 của Ban Chấp hành Trung ương do đồng chí Nguyễn Phú Trọng ký về Hướng dẫn thực hiện các quy định về công tác kiểm tra, giám sát và kỷ luật của Đảng trong Chương VII và Chương VIII điều lệ Đảng khoá XI
vietnam -> Lời nói đầu 6 quy đỊnh chung 7
vietnam -> Mẫu số: 31 (Ban hành kèm theo Quyết định số 1131/2008/QĐ ttcp ngày 18 tháng 6 năm 2008 của Tổng thanh tra)
vietnam -> BỘ thông tin và truyềN thông học viện công nghệ BƯu chính viễN thông việt nam viện khoa học kỹ thuật bưU ĐIỆN
vietnam -> Quy định số 173- qđ/TW, ngày 11/3/2013 của Ban Bí thư về kết nạp lại đối với đảng viên bị đưa ra khỏi Đảng, kết nạp quần chúng VI phạm chính sách dân số và kế hoạch hóa gia đình vào Đảng
vietnam -> RÀ soáT, chuyểN ĐỔi nhóm các tiêu chuẩn ngành phao vô tuyến chỉ VỊ trí khẩn cấp hàng hảI (epirb) sang qui chuẩn kỹ thuậT
vietnam -> HÀ NỘI 2012 MỤc lục mở ĐẦU 2 chưƠng tổng quan về DỊch vụ truy nhập internet cố ĐỊnh băng rộng tại việt nam 3

tải về 1.07 Mb.

Chia sẻ với bạn bè của bạn:
1   ...   6   7   8   9   10   11   12   13   ...   16




Cơ sở dữ liệu được bảo vệ bởi bản quyền ©hocday.com 2024
được sử dụng cho việc quản lý

    Quê hương