Giáo trình Quản lý dự án phần mềm

g chính của công ty. Công ty đã quyết định phát triển một hệ thống vận hành sở hữu khiêm tốn cho máy vi tính mới. Hãy xét một hệ thống đơn giản chỉ một ng•ời dùng. Chuẩn bị một đề nghị về việc phân giải chức năng của hệ thống vận hành sử dụng tinh lọc từng b•ớc. Mô tả biểu đồ phân giải chức năng cho ba cấp đầu. 2. Với hệ thống vận hành mô tả ở bài tập 1 và căn cứ ở phân giải chức năng, chuẩn bị phân giải thiết kế. Mô tả biểu diễn phân giải thiết kế cho ba cấp đầu. Chọn thành phần cấp cao duy nhất và mô tả toàn bộ phân giải tới tận cấp môđun phần mềm. Giải thích bạn đã tính đến những h•ớng dẫn cho các môđun độc lập thế nào. Giải thích bạn đã thực hiện h•ớng dẫn che dấu thông tin thế nào. 3. Với hệ thống vận hành ở bài tập 1, chuẩn bị biểu đồ cơ cấu phân tích công việc cho ba cấp đầu và chuẩn bị danh mục nhiệm vụ WBS. Giải thích vì sao một số nhiệm vụ ở bảng 6.2 không áp dụng đ•ợc cho dự án này. 4. Xét phần mềm cho 1 dự án vệ tính kể cả việc phóng và theo dõi vệ tinh và vận hành của vệ tinh trong và sau khi phóng. Nhận biết những hệ phụ chính trong dự án và giải thích lợi điểm đạt đ•ợc khi xác định chúng là hệ phụ. Quản lý dự án phần mềm 114 Bây giờ xét hệ thống danh sách nhân viên kể cả nhân lực bảo trì hồ sơ,phát phiếu kiểm tra danh sách v.v... liệu đó có lợi điểm gì trong việc xác định các hệ phụ cho dự án đó ? Giải thích. Bảng 6.2. Nhiệm vụ cơ cấu phân tích công việc cấp cao. Phát triển phần mềm Phân tích yêu cầu Phát triển nguyên mẫu Đặc điểm nguyên mẫu Thiết kế nguyên mẫu Thực hiện nguyên mẫu Thử nghiệm Thử nghiệm Alpha Thử nghiệm bêta Nghiệm thu Lắp đặt Đào tạo Cung cấp Thu thập công cụ phát triển Thu thập các thành phần hệ thống Thiết kế Thiết kế cấp cao Thiết kế chi tiết Bảo trì Hiệu chỉnh sai lầm Tăng c•ờng phần mềm Chọn lựa thiệtbi Chọn lựa ng•ời bán Thủ tục đặt hàng Kiểm tra kiểm kê Thực hiện Lập mã Thử nghiệm đơn vị Quản lý Qui hoạch Tuyển nhân sự Quản trị và dịch vụ khác T• liệu Bài viết kỹ thuật Hoạt động xuất bản dự án T• liệu phát triển không giao đ•ợc. Hội nhập Hội nhập phần mềm Hội nhập phần cứng/ phần mềm. Quản trị ngân sách Quản lý nhân sự Bảo hiểm chất l•ợng Quản lý cấu hình T• liệu phát triển giao đ•ợc T• liệu về bảo trì T• liệu ng•ời dùng Bảng 6.3. Nhiệm vụ quản lý và hành chính ủy nhiệm Nhiệm vụ quản lý v v v v v v v v v v 1. Quy hoạch 2. Chuẩn bị dự án 3. Phân tích rủi ro và quản lý rủi ro 4. Lịch trình 5. Tuyển nhân sự 6. Phân tích ngân sách và quản trị ngân sách 7. Quản lý nhân sự 8. ủy thác nhiệm vụ 9. Giao thẩm quyền 10. ủy thác nguồn phát triển 11. Giám sát bảo trì thiết bị phát triển 12. Giám sát và kiểm tra phát triển 13. Tổ chức duyệt xét và các giới thiệu chính thức 14. Lập tiêu chuẩn và ph•ơng pháp Quản lý dự án phần mềm 115 v v v v 15. Bảo hiểm và kiểm tra chất l•ợng 16. Quản lý và kiểm tra cấu hình 17. Giám sát các chủ thầu phụ và ng•ời bán 18. Giao diện và phối hợp quản lý cao 19. Giao diện và phối hợp khách hàng 20. Báo cáo 21. Quản trị và dịch vụ Quản lý dự án phần mềm 116 Ch•ơng bảy Các chức năng hỗ trợ dự án Hỗ trợ quản lý dự án. Quản lý dự án phần mềm là quá trình qui hoạch, tổ chức, tuyển nhân sự, giám sát, kiểm tra và lãnh đạo dự án phần mềm24. Hiếm khi mọi nhiệm vụ đó lại có thể do quản lý dự án thực hiện mà trên thực tế về mặt lý t•ởng họ không thể. Nhiều hoạt động kiểm tra và giám sát có thể đ•ợc ủy thác cho các nhóm hỗ trợ dự án. Những nhóm hỗ trợ này không chỉ giám định nặng cho quản lý dự án và kỹ s• phát triển bằng những nhiệm vụ hỗ trợ: họ cũng thực hiện những nhiệm vụ đó tốt hơn bằng cách tập trung mọi cố gắng của họ vào những chức năng hỗ trợ đặc tr•ng. Có nhiều loại chức năng hỗ trợ dự án. Dịch vụ th• ký, hỗ trợ hành chính xuất bản và cung cấp tài liệu là những thí dụ về chức năng hỗ trợ không kỹ thuật; thử nghiệm, kiểm tra cấu hình, công nghệ hệ thống quản lý hội nhập và bảo hiểm chất l•ợng là những thí dụ về chức năng hỗ trợ kỹ thuật. Dự án càng lớn và càng phức tạp lại sẽ đòi hỏi chức năng hỗ trợ nhiều hơn. Chẳng hạn, một dự án lớn th•ờng có tổ chức kiểm tra chất l•ợng của nó trong khi một dự án nhỏ có thể chia xẻ chức năng đó với các dự án khác. T•ơng tự, nhiều tổ chức duy trì nhóm thử nghiệm độc lập mà vai trò là thử nghiệm một sản phẩm phần mềm tr•ớc khi đ•a ra. ở những dự án lớn, nhóm thử nghiệm độc lập là một bộ phận của đội dự án và tham gia trong thử nghiệm và qui hoạch thử nghiệm xuyên suốt chu trình phát triển. Ch•ơng này mô tả ba chức năng hỗ trợ dự án kỹ thuật chủ yếu: - Kiểm tra cấu hình - Bảo hiểm chất l•ợng phần mềm - Thử nghiệm. Ba chức năng cơ bản đó đ•ợc yêu cầu trong mỗi dự án phát triển phần mềm. Kiểm tra cấu hình quản lý thay đổi cho sản phẩm phần mềm đ•ợc phát triển, bảo hiểm chất l•ợng giám sát và kiểm tra chất l•ợng sản phẩm còn thử nghiệm thử lại đáp ứng với các yêu cầu của sản phẩm. Trách nhiệm của ng•ời quản lý dự án là tổ chức các nhóm hỗ trợ dự án và cung cấp t• liệu các hoạt động đã quy hoạch của các nhóm cho kế hoạch phát triển dự án (coi ch•ơng 9). Nếu những nhóm đó đã có trong tổ chức, thì hỗ trợ của các nhóm cần đ•ợc phối hợp và lên lịch cho dự án. Nếu các 24 nh• xác định trong IEEE (1987a) Quản lý dự án phần mềm 117 nhóm không tồn tại thì chúng phải đ•ợc thiết lập trong đội phát triển dự án. Qui mô của một nhóm hỗ trợ rõ ràng tùy thuộc ở qui mô dự án, chẳng hạn, một dự án lớn có thể yêu cầu một nhóm hai hay ba kỹ sự kiểm tra cấu hình và một dự án nhỏ có thể giao nhiệm vụ một phần thời gian cho kỹ s• phát triển. Các quyết định này phải do quản lý dự án đ•a ra trong những giai đoạn ban đầu của dự án. Các chức năng hỗ trợ dự án đã đ•ợc qui hoạch tốt lúc khởi đầu dự án sẽ đóng góp vào việc quản lý hiệu quả dự án suốt dự án. 7.1. Kiểm tra cấu hình phần mềm (SCC). Kiểm tra cấu hình là chức năng hỗ trợ quản lý hỗ trợ nhiều hoạt động khác nhau liên quan đến thay đổi cho sản phẩm phần mềm. Điều này bao gồm những thay đổi mã của ch•ơng trình, yêu cầu và thay đổi thiết kế cùng thay đổi trong việc đ•a ra phiên bản. Kiểm tra cấu hình th•ờng đ•ợc những nhà sản xuất coi là trở ngại hơn là lợi ích vì nó hạn chế sự tự do của đội phát triển và đặt ra những giới hạn về cái gì có thể và không thể làm. Kiểm tra cấu hình dù sao cũng tạo ra môi tr•ờng trong đó phần mềm có thể đ•ợc phát triển một cách trật tự. Từ cấu hình đ•ợc sử dụng ở đây để mô tả sự phối hợp các thành phần phần mềm tạo thành hệ hợp chất. Khi kết hợp với từ kiểm tra, từ đ•ợc sử dụng để mô tả một ph•ơng pháp trật tự và hiệu quả theo đó sự phối hợp đó của các thành phần có thể đ•ợc thực hiện, chẳng hạn, xây dựng các hệ phần mềm từ những thành phần cấp thấp không phải là nhiệm vụ đơn giản. Điều này đ•ợc minh họa tốt nhất ở giai đoạn sau. Một công ty ngân hàng lớn kết hợp làm dịch vụ thông tin tài chính quốc tế. Dịch vụ này có thể cung cấp cho ngân hàng truy nhập trực tuyến với cơ sở dữ liệu trung tâm chứa thông tin th•ờng xuyên cập nhật về những thị tr•ờng tài chính thế giới. Trong thế giới hiện đại thông tin điện tử nhanh, đây là một dịch vụ chủ yếu cho mọi tổ chức ngân hàng hiện đại. Dù sao, máy tính của ngân hàng đã không có đ•ợc khả năng giao diện với dịch vụ tài chính. Ngân hàng ủy thác ng•ời quản lý dự án phát triển phần mềm cần thiết có nhu cầu cho giao diện. Sau khi giai đoạn hội nhập bắt đầu, một trong những nhà sản xuất báo cáo là cột mốc chủ yếu đã hoàn thành liên túc với dịch vụ thông tin đã đ•ợc thiết lập thành công. Ng•ời quản lý dự án báo cáo điều này cho các cấp trên của anh ta và thông báo với họ là phát triển đã đ•ợc tiến hành theo lịch. Một tuần sau, các thành viên quản lý hàng đầu đến thăm dự án và yêu cầu chứng minh liên lạc với dịch vụ thông tin. Tuy nhiên, ng•ời quản lý dự án đã không thể cung cấp chứng minh. Nhà sản xuất đã báo cáo cột mốc không thể lặp lại thành công tr•ớc đây. Đây là do những đặc điểm phụ đã đ•ợc bổ sung cho phần mềm liên lạc và những liên lạc này lại Quản lý dự án phần mềm 118 ch•a hoạt động. Ngay cả những đặc điểm tr•ớc đây cũng không còn hoạt động nữa. Bắt đầu Có sửa không? Môđun yêu cầu kiểm tra cấu hình Sửa môđun Tiến trình kiểm tra cấu hình Thử nghiệm đơn vị Môđun phát triển Kết thúc Môđun do kiểm tra cấu hình phát ra Có nghiệm thu không? Quản lý dự án phần mềm 119 Hình 7.1 Dòng điều khiển cấu hình môđun phần mềm Rõ ràng, hẳn nhà sản xuất đã giữ một bản sao của phần mềm liên lạc không có những đặc điểm mới. Trong một dự án tổ chức tốt, nhiệm vụ phòng vệ, một phiên bản phần mềm tr•ớc đây hẳn đã đ•ợc ng•ời quản lý cấu hình thực hiện. Một cách lý thú để xem đến kiểm tra cấu hình là coi nh• một ph•ơng pháp đảm bảo là dự án tiến triển (hay ít ra không thụt lùi). Trong tr•ờng hợp xét trên hiện nay dự án tr•ợt lùi. Kiểm tra cấu hình là chủ yếu cho mọi hạng mục phát triển kể cả mã, t• liệu và hợp nhất thành phần hình 7, mô tả dòng kiểm tra cấu hình để phát triển môđun phần mềm. Một dòng t•ơng tự hẳn vận dụng đ•ợc cho t• liệu mà dự án phát sinh kiểm tra cấu hình cũng quan trọng trong giai đoạn bảo trì để đảm bảo khi việc phát hành mới một hệ thống đ•ợc gọi lại do những khuyết tật nghiêm trọng có thể bị thay thế trong đợt phát hành tr•ớc. 7.1.1. Thuật ngữ kiểm tra cấu hình. Có nhiều từ đ•ợc dùng liên quan đến kiểm tra cấu hình. Chẳng may, không có một sử dụng nào hay một ý nghĩa nào của chúng đ•ợc chuẩn hoá: rất nhiều từ khác nhau đã đ•ợc sử dụng để mô tả cùng chức năng; cùng ý t•ởng. Một trong những cố gắng tốt nhất nhằm tiêu chuẩn hóa có trong từ vựng IEEE thuật ngữ về công nghệ phần mềm (IEEE 1987b). Dù sao, ngay từ vựng đó cũng phản ảnh sự thiếu sót trong lý giải và sử dụng thống nhất các từ đó khi mà nhiều từ kiểm tra cấu hình xuất hiện với vô vàn định nghĩa. Sau đây là giải thích hơn là định nghĩa chính xác của một số những thuật ngữ cơ bản. Hạng mục kiểm tra cấu hình phần mềm (SCCI) là hạng mục dự án phần mềm đ•ợc coi là một đơn vị cho những mục đích của kiểm tra cấu hình. Điều này có thể bao gồm những điều nh• mô đun phần mềm (1) phiên bản hệ thống phần mềm hay t• nliệu. Kiểm tra thay đổi là quá trình kiểm tra các thay đổi. Điều này bao gồm đề nghị thay đổi, đánh giá thay đổi, chấp nhận hay bác bỏ, lên lịch và theo dõi thay đổi. Kiểm tra phiên bản nh• vận dụng cho phát triển phần mềm, là quá trình kiểm tra phát hành các phiên bản phần mềm.25 Điều này bao gồm l•u giữ và phòng ngừa mỗi đợt phát hành và chứng minh bằng t• liệu các khác biệt giữa các đợt phát hành. Kiểm tra cấu hình là quá trình đánh giá, chấp nhận hay bác bỏ, và quản lý thay đổi cho những hạng mục cấu hình. Kiểm tra cấu hình cũng bao gồm các chức năng kiểm tra phiên bản. 25 Nhiều giả thích từ hạng mục cấu hình không bao giờ hạng mục cấp thấp nh• mô đun phần mềm. Tiêu chuẩn (DOD 1988a) phát triển phần mềm US- DOD std.2167 vận dụng thuật ngữ cho những thành phần cấp cao nh• xác định trong tiêu chuẩn Std.480a kiểm tra cấu hình DOD. Giải thích này liên quan đến những hạng mục có thể đ•ợc phát triển độc lập hay sửa chữa và bảo trì độc lập. Quản lý dự án phần mềm 120 Quản lý cấu hình là ứng dụng kỹ thuật và hành chính kiểm tra cấu hình. Điều này cũng bao gồm việc duy trì tổ chức kiểm tra cấu hình, thay đổi và các tiêu chuẩn kiểm tra phiên bản và các ph•ơng tiện kiểm tra cấu hình. Các từ khác là chỉ định nhận biết cấu hình đ•ợc sử dụng để nhận biết các hạng mục cấu hình, ban kiểm tra cấu hình chấp nhận hay bác bỏ những thay đổi công nghệ và kiểm toán cấu hình kiểm tra thích ứng với các tiêu chuẩn kiểm tra cấu hình. Mục tiêu của quản lý cấu hình đ•ợc xác định tốt nhất không phải nh• những định nghĩa chính thức từ vựng IEEE những thực ra nhờ giải thích có tính chất mô tả hơn nh• đã nêu trong lời nói đến tiêu chuẩn IEEE 828 (1987b) cho những kế hoạch quản lý cấu hình phần mềm, khẳng định: Cung cấp cấu hình phần mềm (SCM) là ngành công nghệ chính thức cung cấp ph•ơng pháp và công cụ cho các nhà sản xuất và sử dụng phần mềm biết phần mềm đ•ợc phát triển, lập ra những đ•ờng mốc, thay đổi kiểm tra cho những đ•ờng gốc đó, l•u giữ và theo dõi tình hình và kiểm toán sản phẩm. SCM là ph•ơng tiện thông qua đó sự hợp nhất và liên tục của sản phẩm phần mềm đ•ợc l•u giữ, thông tin và kiểm tra. Một số những nhiệm vụ quản lý cấu hình chồng chéo với nhiệm vụ của hoạt động hỗ trợ khác, kiểm tra chất l•ợng phần mềm (bàn đến sau). Trong các dự án phần mềm mà kiểm tra chất l•ợng và kiểm tra cấu hình, do các nhóm riêng rẽ thực hiện, việc định nghĩa rõ trong phân chia trách nhiệm là cần thiết. 7.1.2. Nguồn lực kiểm tra cấu hình. Hình 7.2 Điều khiển cấu hình mạng Kiểm tra cấu hình là một trong những lĩnh vực đầu tiên của công nghệ phần mềm đ•ợc công nhận là dự tuyển tự động hóa, nhiều hoạt động kiểm tra cấu hình nh• kiểm tra phiên bản và kiểm tra thay đổi đã đ•ợc tự Cơ cở dữ liệu kiểm tra cấu hình Các máy tính đầu cuối phát triển dự án Máy tính kiểm tra cấu hình Quản lý dự án phần mềm 121 động hóa vào đầu những năm 1970 với những công cụ nh• đóng mạch và SCCS (coi Rochkind 1975)26. Một số những công cụ đó dịch chuyển từ các hệ vận hành UNIX nói chung đ•ợc sử dụng đầu tiên đến các môi tr•ờng khác nh• MS-DOS và VMS của Digital. Nhiều hoạt động kiểm tra cấu hình chính là những dự tuyển tự nhiên cho các công cụ tự động hóa CASE (Công nghệ phần mềm có hỗ trợ bằng máy tính) nh• đ•ợc xác định rõ, có đôi chút lặp lại và sẵn sàng hội nhập vào quá trình phát triển. Những công cụ đó có thể đ•ợc dễ dùng giao diện với các công cụ mã phần mềm (thí dụ các biên tập viên và s•u tập) và các bộ xử lý từ để sản sinh t• liệu. Kiểm tra cấu hình tự động là tốt nhất khi đ•ợc sử dụng trong môi tr•ờng phát triển nhiều ng•ời sử dụng nh• LAN với cách đó mọi nhân tố đ•ợc kiểm tra l•u giữ trong cơ sở dữ liệu trung tâm và việc truy nhập của mọi nhà sản xuất đ•ợc quản lý từ hệ thống kiểm tra cấu hình trung tâm (coi Hình.7.2). Việc kiểm tra cấu hình có hiệu quả đòi hỏi ở sự tổ chức hiệu quả và đ•ợc xác định rõ. Mọi ph•ơng pháp kiểm tra cấu hình phải căn cứ ở bốn quan niệm sau: 1. Phải thành lập cấp thẩm quyền quản lý cấu hình đ•ợc xác định rõ. 2. Phải sản xuất và phân phối các tiêu chuẩn kiểm tra cấu hình, các thủ tục và h•ớng dẫn kiểm tra cấu hình các nhà sản xuất. 3. Kiểm tra cấu hình không thể có hiệu quả nếu không có công cụ và ph•ơng tiện cần thiết. 4. Phải phát triển kế hoạch quản lý cấu hình ngay khởi đầu dự án. Đây là trách nhiệm của ng•ời quản lý dự án trong việc giao quyền quản lý cấu hình. Điều này có thể tiến hành từ đội kiểm tra cấu hình trong các dự án lớn đến kỹ s• kiểm tra cấu hình một phần thời gian trong các dự án nhỏ. Trong cả hai tr•ờng hợp, cả quyền hạn và trách nhiệm phải đ•ợc xác định rõ. Kỹ s• kiểm tra cấu hình phải đ•ợc tham gia trong mọi hoạt động phát triển và phải có quyền hạn đặc thù trong việc chấp nhận hay bác bỏ hạng mục cấu hình. Các thành viên đội phát triển phải làm quen với các tiêu chuẩn kiểm tra cấu hình, các thủ tục và h•ớng dẫn phải dễ hiểu và rõ ràng. Điều này có thể giảm bớt số phản bác trong kiểm tra cấu hình do không thích ứng với các tiêu chuẩn không quen thuộc. Môi tr•ờng quản lý cấu hình bao gồm những cần thiết cho việc thực hiện kế hoạch kiểm tra cấu hình. Điều này bao gồm: - Công cụ kiểm tra cấu hình, kể cả: + Kiểm tra phiên bản tự động và công cụ kiểm tra thay đổi. + Giám sát, kiểm toán và đăng ký các tiện ích hỗ trợ. 26 Sự tiến triển của quản lý cấu hình đ•ợc mô tả trong thảo luận của Ambriola và cộng sự (1990) cũng bàn đến tự động hóa các hoạt động kiểm tra cấu hình khác nhau. Quản lý dự án phần mềm 122 - Ph•ơng tiện l•u giữ: kho chứa an toàn cho mọi hạng mục cấu hình đ•ợc phê chuẩn, kể cả: - L•u giữ tại chỗ cho quá trình phát triển hàng ngày. - L•u giữ ngoài phạm vi để phục hồi tai họa. 7.1.3. Kế hoạch quản lý cấu hình phần mềm. Kế hoạch quản lý cấu hình phần mềm (SCMP) là một bộ phận của kế hoạch phát triển phần mềm cả dự án. SCMP có thể xuất hiện nh• một t• liệu riêng biệt hay một phần trong phạm vi kế hoạch phát triển dự án. SCMP cung cấp dự liệu cho các nguồn có nh• cầu, chúng đ•ợc sử dụng nh• thế nào, và có những tiêu chuẩn thủ tục gì sẽ đ•ợc vận dụng trong dự án. Theo thế SCMP trở thành đ•ợc ủy nhiệm cho nhóm kiểm tra cấu hình trong phát triển dự án. Việc đ•a ra kế hoạch đó là trách nhiệm của ng•ời quản lý dự án, mặc dù trong những dự án lớn nó có thể đ•ợc phó thác cho ng•ời quản lý kiểm tra cấu hình. Bảng 7.1. Có một danh mục các đề tài chính nằm trong SCMP. Nếu có một đề tài nào trong những đề tài đó nằm ở chỗ khác (thí dụ trong kế hoạch bảo hiểm chất l•ợng phần mềm) thì đề tài đó có thể đ•ợc bỏ qua ở SCMP và đ•ợc thay bằng con trỏ. Trong t• liệu mà nó đáng phải ở đó. Mặc dù phần lớn các đề tài trong bảng 7.1. là tự mô tả, sau đây là một số h•ơng dẫn:  Báo cáo tình hình cấu hình mô tả cách thông tin tình hình diễn triển: - Từ ng•ời sản xuất đến tổ chức quản lý cấu hình (kiểm toán và duyệt). - Từ tổ chức quản lý cấu hình tới quản lý dự án (thủ tục báo cáo tình hình).  Nhận biết cấu hình mô tả ph•ơng pháp chỉ định các hạng mục phát triển nh• SCCI. Đây là một bộ phận của phân giải hệ thống cấp cao thành những thành phần páht triển chủ yếu (coi ch•ơng 6). Phần về các ph•ơng pháp nhận biết mô tả cách mà mỗi thành phần phát sinh, từ dự án đ•ợc đánh dấu nhận biết duy nhất.  An toàn, truy nhập hạn chế và phân loại nhằm phát triển an toàn các sản phẩm nhạy cảm (nh• t• liệu phần mềm, bằng phát minh, thông tin quân sự xếp hạng v.v...). Th•ờng thuận lợi là ủy thác nhiều những nhiệm vụ đó cho kiểm tra cấu hình do nh• cầu phải tham gia vào việc duyệt và phân loại t• liệu và các hoạt động khác liên quan gắn với an toàn.  Các chủ thầu phụ, ng•ời bán hàng và ng•ời cung cấp có thể hay không thể thực hiện kế hoạch quản lý cấu hình của chính mình. Đây là trách nhiệm của ng•ời quản lý dự án phải đảm bảo là các chủ thầu phụ hay các nhà sản xuất bên ngoài phải trình duyệt CMP hay ng•ời quản lý cấu hình của dự án chịu trách nhiệm về công việc của họ. Quản lý dự án phần mềm 123 SCMP cũng có thể bao gồm những sơ đồ và biểu đồ để dòng chảy mô tả thủ tục đệ trình các yêu cầu thay đổi hay báo cáo vấn đề27. Hình 7.3. giới thiệu một thí dụ về biểu đồ dòng chảy tổng quát kiểm tra cấu hình mà tiêu chuẩn US DOD 2167A (DOD) 1988a gợi ý (so sánh với dòng kiểm tra cấu hình mô đun phần mềm trong h.7.1). Bảng 7.1. Thí dụ về nội dung kế hoạch quản lý cấu hình phần mềm. 1. Tổ chức và nguồn quản lý cấu hình phần mềm - Cơ cấu tổ chức - Khả năng về trình độ kỹ năng nhân sự - Nguồn 2. Tiêu chuẩn, thủ tục, chính sách và h•ớng dẫn. 3. Nhận biết cấu hình - Ph•ơng pháp xác định SCCI - Mô tả SCCI cho dự án này 4. Ph•ơng pháp nhận biết (định danh và đánh dấu t• liệu, cấu kiện phần mềm, duyệt phát hành v.v...). 5. Đệ trình hạng mục cấu hình thủ tục chấp nhận / bác bỏ. 6. Kiểm tra thay đổi. - Thủ tục kiểm tra thay đổi (ph•ơng pháp đệ trình duyệt, chấp nhận và bác bỏ). - Báo cáo t• liệu (yêu cầu thay đổi, báo cáo vấn đề) - Thủ tục duyệt thay đổi và ban xét duyệt 7. Kiểm tra phiên bản. - Chuẩn bị phiên bản phần mềm và t• liệu - Thủ tục chấp nhận phát hành. 8. L•u trữ, xử lý và cung cấp các kênh thông tin dự án - Yêu cầu l•u trữ. - Sao chép 9. Kiểm tra cấu hình của các chủ thầu phụ, ng•ời bán và ng•ời cung cấp 10. Kiểm tra bổ sung - Thủ tục kiểm tra linh tinh - Kiểm tra đặc biệt dự án (an toàn v.v...) 11. Báo cáo tình hình cấu hình - Kiểm toán và duyệt cấu hình - Thủ tục báo cáo tình hình cấu hình 12. Cột mốc chủ yếu quản lý cấu hình 13. Công cụ, kỹ thuật và ph•ơng pháp luận 27 về mô tả SCMP chi tiết hơn, coi IEEE (1987) Quản lý dự án phần mềm 124 7.1.4. Một số đ•ờng lối chung Hình 7.3 Thí dụ về l•ợc đồ một dòng điều khiển cấu hình. Danh mục hoạt động mà kiểm tra cấu hình tiến hành còn ch•a đạt tiêu chuẩn là chức năng hỗ trợ quản lý dự án, phạm vi kiểm tra cấu hình bao gồm nhiều hoạt động tùy chọn hay tuyển chọn. Do đó, với t• cách một h•ớng dẫn cơ bản, nó hoàn toàn có thể chấp nhận đ•ợc để gán cho quản lý cấu hình trong phạm vi dự án chuyên đề, bất kỳ hoạt động nào liên quan nh• phân bổ nguồn phát triển hay bố trí và tổ chức các trình diễn Không Nâng cấp phần mềm Thay đổi phần mềm Các vấn đề Phân tích và •ớc định ảnh h•ởng Chuẩn bị đề xuất thay đổi kỹ thuật Sáp nhập sự thay đổi Ban rà soát thiết kế phần mềm Ban điều khiển cấu hình phần mềm Có Đánh giá đề xuất thay đổi kỹ thuật Cung cấp liên hệ ng•ợc cho ng•ời khởi đầu Kiểm thử thay đổi Kết thúc Chấp thuận hay không? L•u trữ thay đổi Phân tích và truy cập ảnh h•ởng Quản lý dự án phần mềm 125 cho khách hàng. Cả hai thí dụ đó sử dụng thông tin có đ•ợc cho ng•ời quản lý cấu hình: cấu kiện sản phẩm nào đ•ợc sản xuất, khi nào và do ai. Đòi hỏi thay đổi phần mềm Số : Trang: Tên ng•ời khởi đầu: Điện thoại: Ngày: Dự án: Hệ thống/Sản phẩm: Version: Lý do thay đổi: Mô tả thay đổi: Ng•ời rà soát: Chữ ký: Ngày: Ước l•ợng số công: Lịch thời gian: Lập lịch ảnh h•ởng: Ng•ời chấp thuận dự toán: Chữ ký: Ngày: Có chấp thuận không (có/không): Tên ng•ời quyết định: Chữ ký: Ngày: Hình 7.4 Thí dụ biểu yêu cầu thay đổi phần mềm Việc l•u giữ hồ sơ là quan trọng trong mọi hoạt động hành chính của dự án nh•ng đặc biệt quan trọng trong kiểm tra cấu hình. Tai họa của Quản lý dự án phần mềm 126 quản lý dự án vẫn là tranh chấp vĩnh cửu về các thỏa thuận miệng lý giải sai hay hiểu sai... Kiểm tra thay đổi yếu là phổ biến trong việc gây nên tranh chấp giữa khách hàng và ng•ời sản xuất. T•ơng tự nh• vậy việc kiểm tra phiên bản yếu có thể là tai họa, đặc biệt khi không có hồ sơ về dị biệt giữa các phiên bản. Hình 7.4. cho 1 thí dụ về mẫu yêu cầu thay đổi. Mẫu này l•u giữ thay đổi phần mềm từ lần đệ trình ban đầu, qua chấp nhận hay bác bỏ và cuối cùng đến thực hiện và kiểm nghiệm (khi đ•ợc chấp nhận). Cần ghi nhớ nhu cầu chữ ký; những mẫu này không thể l•u giữ bằng điện tử - bản gốc có chữ ký phải đ•ợc l•u lại. Sau đây là một số h•ớng dẫn bổ sung để quản lý cấu hình hiệu quả. Một số những h•ớng dẫn này đồng thời áp dụng đ•ợc cho các chức năng hỗ trợ quản lý khác. - Quản lý cấu hình đòi hỏi quyền hạn để có hiệu lực. Quyền hạn này phải đ•ợc quản lý dự án giao cụ thể cho các kỹ s• có trách nhiệm. Bất cứ kế hoạch quản lý cấu hình nào sẽ trở nên vô nghĩa nếu kế hoạch không thể đ•ợc tôn trọng. Tốt nhất nên tránh, bất cứ khi nào có thể, việc c•ỡng bức tôn trọng bất cứ kế hoạch, chính sách hay tiêu chuẩn nào. Một trong những đức tính của ng•ời quản lý tốt là khả năng vận dụng chính sách với c•ỡng bức tối thiểu. Bất cứ khi nào các chính sách và tiêu chuẩn sẵn sàng đ•ợc ng•ời sản xuất chấp nhận thì chúng càng đ•ợc tự nguyện tuân thủ và rất ít có tr•ờng hợp bác bỏ vật liệu đệ trình. Điều này dẫn đến quá trình phát triển hiệu quả hơn. - Quản lý cấu hình phải đ•ợc thực hiện từ lúc khởi đầu dự án phần mềm. Nhiều t• liệu chính thức đề xuất trong giai đoạn quan niệm ban đầu là trọng yếu cho các giai đoạn yêu cầu và thiết kế và phải đ•ợc đặt trong sự kiểm tra cấu hình. Việc vận dụng sớm quản lý cấu hình là đặc biệt quan trọng trong các mô đen xoáy ốc, lấy nguyên mẫu nhanh hay các ph•ơng pháp luận phát triển lặp lại. Những tiếp cận phát triển này khởi đầu tạo ra vô vàn phiên bản của mỗi sản phẩm. Nhiều phiên bản khác nhau có thể trở thành ác mộng công nghệ nếu không có kiểm tra cấu hình có trật tự. - Đôi khi một số hoạt động kiểm tra cấu hình phần mềm có thể chồng chéo với các hoạt động bảo hiểm chất l•ợng phần mềm. Trong những dự án nhỏ, cả hai chức năng đó có thể giao cho một kỹ s• hỗ trợ duy hất. Ngay trong những dự án lớn, đôi khi chức năng đó có thể do một nhóm hỗ trợ duy nhất thực hiện. Về h•ớng dẫn chung cuối cùng, phải ghi nhận là quản lý cấu hình có thể đ•ợc đề cao thái quá. Các hoạt động kiểm tra cấu hình bản thân chúng không phải là đối t•ợng. Chúng là ph•ơng tiện. Một thí dụ điển hình về việc vận dụng sai quản lý cấu hình (và kiểm tra chất l•ợng lệch h•ớng) là yêu cầu sửa lại phần mềm đã đ•ợc dùng lại đáp ứng các tiêu chuẩn và thủ tục thông dụng. Phần mềm tái sử dụng là phần mềm phát Quản lý dự án phần mềm 127 triển tr•ớc đây trong dự án khác và đ•ợc thấy thích hợp để hòa nhập vào dự án thông th•ờng. Trong những tr•ờng hợp đó, hiếm khi lại có ý nghĩa trong việc sửa đổi một sản phẩm hoàn chỉnh và hoạt động nhằm cho nó đáp ứng với các tiêu chuẩn hành chính dự kiến để làm nó trở thành một sản phẩm hoàn chỉnh và hoạt động đ•ợc. 7.2. Bảo đảm chất l•ợng phần mềm (SQA). Chất l•ợng khó xác định đ•ợc đặc biệt khi vận dụng cho một hợp đồng phát triển sản phẩm. Mặc dù không phải mọi phần mềm đ•ợc phát triển theo hợp đồng, chất l•ợng vẫn là mối quan tâm đầu tiên của khách hàng (và mọi dự án cuối cùng đều có khách hàng). Cơ quan tiêu chuẩn Anh (1986) đã khẳng định "chất l•ợng nằm trong con mắt của ng•ời xem, một đề tài phán xử của khách hàng". Nếu đã có khó khăn trong việc tìm kiếm đ•ợc những định nghĩa chấp nhận rộng rãi về thuật ngữ kiểm tra cấu hình thì về thuật ngữ bảo đảm c