TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ──────── * ─────── BÀI TẬP LỚN MÔN: QUẢN LÝ CẤU HÌNH PHẦN MỀM ĐỀ TÀI: TIÊU CHUẨN CÔNG NGHIỆP & CÁC KHUNG QUẢN LÝ CẤU HÌNH Nhóm 13: Nguyễn Thế Anh 20080070 Trần Anh Thơ 20082569 Nguyễn Ngọc Toàn 20082704 Nguyễn Vương Quyền 20082142 Trần Đức Hải 20080886 Nguyễn Văn Võ 20083190 Ngô Duy Hiển 20086091 Lớp: Công nghệ phần mềm K53 GVHD: ThS Thạc Bình Cường Hà Nội - 11/2012 MỤC LỤC Chương 14 Tiêu chuẩn công nghiệp khung quản lý cấu hình Tổng quan Các mục tiêu việc sử dụng tiêu chuẩn khung quản lý 14.1 Tại tiêu chuẩn khung quản lý lại quan trọng 14.2 Ta bắt đầu (để xác định tiêu chuẩn khung quản lí cấu hình) ? 14.3 Thuật ngữ yêu cầu 1.4.3.1 Thành phần cấu hình cấu hình 14.3.2 Định danh cấu hình 14.3.3 Kiểm soát cấu hình 14.3.4 Kiểm soát giao diện 14.3.5 Báo cáo tình trạng cấu hình 14.3.6 Kiểm toán cấu hình 14.3.7 Kiểm soát nhà cung cấp nhà thầu phụ 14.3.8 Tuân thủ không tuân thủ 14.4 Áp dụng điều khoản tiêu chuẩn khung quản lý cấu hình 14.5 Tiêu chuẩn công nghiệp 14.5.1 IEEE 828-Tiêu chuẩn cho kế hoạch quản lý cấu hình phần mềm 14.15.1.1 Sự tuân thủ tiêu chuẩn 10 14.5.2 ISO 10007-Hệ thống quản lý chất lượng-Hướng dẫn Quản lý Cấu hình 10 14.5.2.1 ISO 10007 Là tài liệu Hướng dẫn 11 14.5.2.2 Tim hiểu ISO 10007 11 14.5.3 ANSI/ITAA EIA-649-A—Tiêu chuẩn quốc gia Quản lý Cấu hình 11 14.5.4 ISO/IEC/IEEE 12207 15288 11 14.6 Khung quản lý cấu hình 11 14.6.1 ISACA Cobit 12 14.6.1.1 Vấn đề với Cobit 12 14.6.1.2 Hành trình với cobit 13 14.6.1.3 Thực cấu hình thay đổi toàn diện chức điều khiển 15 14.6.1.4 Cải tiến qui trình liên tục 18 14.6.1.5 Quản lý phát hành bị phá vỡ 20 14.6.1.6 Kết luận 21 14.6.2 CMM/CMMI 21 14.6.2.1 Quản lý nhà thầu phụ 22 14.6.3 Nền tảng itSMF ITIL 22 14.6.3.1 Quản lý thay đổi 23 14.6.3.2 Hội đồng cố vấn thay đổi 23 14.6.3.3 Quản lý cấu hình tài sản dịch vụ 24 14.6.3.4 Quản lý tài sản 24 14.6.3.5 Hệ thống quản lý cấu hình 24 14.6.3.6 Thư viện phương tiện truyền thông chung (DML) 24 14.6.3.7 Phát hành quản lý triển khai 25 14.6.3.8 Tích hợp CMS, DML, CMDBs, SCM 25 14.6.3.9 Quản lý sở liệu cấu hình 26 14.6.3.10 Quy trình cải tiến cho CMDBs 26 14.6.3.11 Đơn giản môi trường giám sát 26 14.6.3.12 Đưa CMDB bạn 27 14.6.3.13 Xác nhận thử nghiệm 27 14.6.3.14 Kết luận 27 14.6.4 SWEBOK 28 14.6.4.1 Cấu hình phần mềm quản lý SWEBOK 28 14.6.5 Open Unified Process (openUp) 29 14.6.6 Agile/SCRUM 30 14.6.6.1 Sự linh động hỗ trợ triển khai xây dựng 30 14.6.6.2 Sự tích hợp liên tục 30 Chương 14 Tiêu chuẩn công nghiệp khung quản lý cấu hình Tổng quan 14.1 Tại tiêu chuẩn khung quản lý cấu hình lại quan trọng 14.2 Cách thức tiến hành 14.3 Thành phần bắt buộc 14.4 Áp dụng điều khoản vào tiêu chuẩn khung qun lý cấu hình 14.5 Tiêu chuẩn công nghiệp 14.6 Khung quản lý công nghiệp Trong chương này, bắt đầu cách xem xét lại thành phần thiết yếu bắt buộc, bao gồm thành phần cấu hình (CI), xác định cấu hình, quản lý cấu hình, quản lý giao diện, hạch toán tình trạng cấu hình, quản lý nhà thầu, nhà cung cấp, đánh giá phù hợp so với không phù hợp Chúng ta bàn cách áp dụng điều thành tiêu chuẩn khung cho quản lý cấu hình Tiếp theo, bàn tiêu chuẩn đặc trực, bao gồm IEEE 828 – Chuẩn cho lập kế hoạch quản lý cấu hình; ISO 10007 – Hệ thống quản lý chất lượng – Nguyên tắc quản lý cấu hình; tiêu chuẩn vòng đời toàn diện ISO/IEC/IEEE 12207 15288 Tiếp theo, bàn khung quản lý công nghiệp, ISACA Cobit, tập trung vào kiểm soát thực tiễn Vấn đề việc áp dụng cấu hình toàn diện, thay đổi chức điều khiển, tìm việc cải tiển hoạt động liên tục thường mang tới nhiều vấn đề thách thức Tiếp đó, liên hệ kinh nghiệm thân với khung CMM/CMMI ITIL, bao gồm quản lý thay đổi, quản lý dịch vụ cấu hình, quản lý dịch vụ, cấu hình (SACM), thiết lập hệ thống quản lý cấu hình (CMDB), tích hợp CMS, DML, CMDB, hệ thống quản lý mã nguồn Chúng đề cập tới phương án tốt ứng dụng quản lý phát hành, triển khai môi trường Cuối cùng, kết thúc phần với việc tóm tắt SWEBOK, Tiến trình thống mở (OpenUP), Agile/SCRUM, vàtích hợp liên tục (CI) Các mục tiêu việc sử dụng tiêu chuẩn khung quản lý Mục đích số để xúc tiến tập phương án chấp nhận rộng rãi kết hợp kiến thức thực tế quy trình phát triển công nghiệp Điều giúp hoàn thành nhanh công việc cải thiện chất lượng, số lượng quy trình sản xuất Một mục đích khác để áp dụng cải tiến quy trình liên tục, nhằm đạt kết tốt Điều chứng minh thực tế tương đối dễ áp dụng giúp ích cho nhiều tiêu chuẩn hay khung quản lý khác Đối với quản lý cấu hình, trải nghiệm cho biết cần làm để trình sản xuất có hiệu cho suất cao 14.1 Tại tiêu chuẩn khung quản lý lại quan trọng Các tiêu chuẩn khung quản lý phát triển, đưa chuyên gia Chúng giúp ta khởi đầu nhanh làm công việc tốt Với nhiều trường hợp, chúng đòi hỏi tuân thủ nghiêm ngặt Chúng trình đúc kết, kiểm chứng, kiểm thử nhiều người tình nguyện bớt thời gian để chia sẻ tri thức kinh nghiệm họ Hãy liên lạc với bạn muốn trực tiếp tham gia với nỗ lực 14.2 Ta bắt đầu (để xác định tiêu chuẩn khung quản lí cấu hình) ? Nếu bạn có yêu cầu để thiết lập kiểm soát tuân thủ IT, phận kiểm tra /tuân thủ cho bạn biết xác nơi bạn cần để bắt đầu Nếu bạn đangchỉ sử dụng tiêu chuẩn khung cách để thực hành tốt cho vấn đề bắt đầu cách xem xét cácmục tiêu ưu tiên riêng bạn Tôi thường cho cách tiếp cận dựa rủi rolà thực dụng,điều có nghĩa bạn xem xét quan tâm đến rủi riêng bạn mà xảy sau tập trung vào giải yêu cầu, rủi ro Hãy chắn bạn bắt đầucông việc với tập trung vào nâng cao chất lượng suất! 14.3 Thuật ngữ yêu cầu Các thuật ngữ sử dụng chuyên gia Quản lý cấu hình phức tạp Bạn thấy số thuật ngữ sử dụng khác tiêu chuẩn thông thường (chẳng hạn ISO 10007, IEEE 828) framework (chẳng hạn Cobit, CMMI, ITIL) Tôi khuyên bạn nên sử dụng SEVOCAB IEEE: Từ vựng công nghệ phần mềm hệ thống, đó, thời điểm viết này, tìm thấy www.computer.org/sevocab Trong phần này, thảo luận thuật ngữ kỹ thuật quan trọng mà bạn cần phải biết để hiểu rõ tiêu chuẩn framework Thuật ngữ như: kế toán tình trạng cấu hình kiểm toán cấu hình thường bị hiểu lầm,và thấy chúng sử dụng không xác kế hoạch cấu hình sử dụng tập đoàn lớn Kiểm soát thay đổi cấu hình thuật ngữ thường hiểu lầm thực có hai ý nghĩa khác nhau! Cấu hình chắn quy tắc với thuật ngữ chuyên ngành, tin cải thiện tình hình cách cập nhật thuật ngữ cho phù hợp với quy ước công nghệ Điều nói dễ làm có khó khăn để đạt đồng thuận ý nghĩa thuật ngữ riêng Ví dụ, thành phần cấu hình xác định mức độ cao (ví dụ, thành phần) mức độ thấp (ví dụ, tập tin cấu hình) Điều xác bao gồm thành phần cấu hình? 1.4.3.1 Thành phần cấu hình cấu hình Thành phần mà bạn cần phải hiểu thành phần cấu hình (CI).Thật không may, thuật ngữ lúc sử dụng cách quán Câu hỏi đặt là:Chính xác tạo thành CI? Các thành phần cấu hình chắn bao gồm tất thành phần tạo trình xây dựng trình đóng gói Tuy nhiên, xem xét file cấu hình, tài liệu Word, XML thành phần cấu hình Rõ ràng, tất thành phần phần cứng thành phần cấu hình Trong khó khăn xác định xác thành phần cấu hình Một file header biên dịch thành nhiều thành phần nên coi thành phần cấu hình? Tôi nghĩ vậy, thực tế, thường xem xét cần thiết phát hành mục cấu hình Trong thực tế, tất thành phần cấu hình lựa chọn, định danh, sau theo dõi chặt chẽ Chúng ta thảo luận vấn đề sau phần 14.3.2 Định danh cấu hình Định danh cấu hình liên quan đến việc sử dụng phương pháp tin cậy để lựa chọn định danh thành phần cấu hình xác Thông thường, điều có nghĩa bạn nhúng ID phiên bất biến vào mục cấu hình, chẳng hạn thành phần, file cấu hình, tài liệu Word, XML, với thủ tục đáng tin cậy để lấy ID phiên Định danh cấu hình liên quan đến việc tạo quy ước đặt tên đáng tin cậy cho phiên sở, gói thành phần… Trong thực tế, bạn thực điều dựa công cụ kiểm soát phiên công cụ quản lý mã nguồn Định danh cấu hình cho phép bạn xác định xác phiên mục cấu hình, không quan tâm xem có nằm hệ thống quản lý mã nguồn hay không Nhiều chuyên gia quản lý cấu hình phần mềm dành nhiều thời gian họ cho việc lựa chọn, cài đặt, hỗ trợ công cụ tạo phục vụ cho định danh cấu hình hiệu quả, bao gồm cung cấp khả dò vết để xác định yêu cầu thay đổi Điều tiếp tục thảo luận mục 14.3.5, kế toán trạng thái cấu hình 14.3.3 Kiểm soát cấu hình Kiểm soát cấu hình sử dụng để kiểm soát tất thay đổi thành phần cấu hình, bao gồm xác định xác thay đổi xảy ?, người thực thay đổi, quyền hạn cho thay đổi Kiểm soát cấu hình bao gồm khả phục hồi thay đổi trở lại, cần thiết Kiểm soát cấu hình liên quan đến việc kiểm soát để chắn thay đổi trái phép không xảy Kiểm soát cấu hình sử dụng để kiểm soát phiên xác thành phần cấu hình phần phiên sở Trong kiểm soát thay đổi ưu tiên, cần có quyền thực thay đổi trước thay đổi thực xảy Nhiều đội phát triển phần mềm không thực kiểm soát thay đổi lên phía trước Người quản lý dự án, chí nhà phát triển ngầm định thay đổi cần thực chúng cần xảy Nhiều nhóm phát triển thực hành kiểm soát thay đổi lỏng lẻo lúc bắt đầu dự án sau chặt chẽ ứng dụng phát hành bảo trì 14.3.4 Kiểm soát giao diện Các thành phần thường có phụ thuộc giao diện mà đơn giản để sở liệu xác (chẳng hạn bảo đảm chất lượng, sản xuất) phức tạp Tôi làm việc với ứng dụng có yêu cầu giao diện bao gồm cấu trúc phức tạp để hỗ trợ persistence object tượng hành vi poxy tường lửa phức tạp Nhiều tổ chức xử lý kiểm soát giao diện phần chức kiểm soát cấu hình mà mở rộng tất nhóm bị ảnh hưởng Ví dụ, kiểm soát giao diện yêu cầu đội ngũ an ninh phân quyền cổng mở tường lửa quản trị hệ thống cấu hình hệ thống giao tiếp cổng cụ thể Trong thực tế kiểm soát cấu hình,và kiểm soát giao diện phải quản lý chặt chẽ với 14.3.5 Báo cáo tình trạng cấu hình Báo cáo tình trạng cấu hình (CSA) liên quan đến việc theo dõi thành phần cấu hình thông qua vòng đời hoàn chỉnh Điều bao gồm theo dõi yêu cầu từ bắt đầu phát triển ứng dụng xuyên suốt trình phát triển cuối triển khai phần việc phát hành CSA bao gồm tình trạng cung cấp thành phần cấu hình thời điểm Theo quan sát thống kê trạng thái cấu hình thường bị hiểu nhầm không theo dõi trình phát triển Trong thực tế, kế toán trạng thái thường thực thông qua công cụ liên kết với thành phần công việc(như lỗi, nhiệm vụ, yêu cầu thay đổi) kiểm soát với thay đổi lưu trữ hệ thống quản lý mã nguồn 14.3.6 Kiểm toán cấu hình Thực kiểm toán cấu hình liên quan đến việc để xác minh đặc tính vật lý chức thành phần cấu hình (CI) Một sai lầm phổ biến nhà lập trình viên tin đủ để theo dõi thành phần cấu hình với hệ thống quản lý mã nguồn CI nên xác định mã phát hành thành sản phẩm (hoặc QA) Nhiều tổ chức dựa vào lưu trữ họ để theo dõi phiên sơ sử dụng vào sản xuất Sau đó, họ nhầm lẫn cho họ biết xác phiên chạy sản phẩm Tôi thấy mã, môi trường sản xuất bảo mật cao, vô tình sửa đổi (đôi với kết tai hại) Khi thành phẩn cấu hình nhúng ID phiên bất biến, kiểm toán cấu hình thực cách đáng tin cậy hiệu Tôi thường viết kịch nhỏ để hiển thị phiên ID thành phần cấu hình mang danh sách thành phần cấu hình (và ID phiên tương ứng chúng) Tôi gọi danh sách release map Một kiểm toán cấu hình sau thực cách sinh lại release map so sánh với mang phát hành lần triển khai Có nhiều cách xử lý vấn đề phức tạp bao gồm cryptography key, phần mà bàn luận chương “Quản lý phát hành” 14.3.7 Kiểm soát nhà cung cấp nhà thầu phụ Các nhà thầu phụ cần thực công việc quản lý cấu hình phần mềm gồm có kiểm soát phiên thay đổi Các nhà thầu phụ nguồn lực bên ngày coi thành viên nhóm phát triển Điều trở nên thực tế nhiều hệ có nhiều hệ thống quản lý mã nguồn tốt sử dụng đội nằm vị trí khác Điều có nghĩa cần có thêm kiểm soát an toàn nguồn lực bên nên xem lại chấp nhận công việc hoàn thành Thêm vào đó, nhà thầu phụ tạo sản phẩm hoàn chỉnh nơi khác phiên baselined hoàn chỉnh cần kiểm soát phiên Và nhiều quan quản lý nhà thầu cần xác minh nhà thầu phụ có kiểm soát IT phù hợp bao gồm quản lý cấu hình phát hành Đôi bạn quản lý tùy biến phát hành nhà thầu phụ Tối thiểu, bạn cần thực thi kiểm toán cấu hình phát hành baselined phát hành Tôi gặp dự án mã nguồn mở kiểm soát phát hành nhà cung cấp/bên thứ Trong trường hợp đội phát triển phải có trách nhiệm kiểm soát phát hành sản phẩm đặc biệt xử lý giống sản phẩm bên thứ Cũng có khi, người phát triển cung cấp code đến đội khác chí công ty xử lý phát hành sản phẩm bên thứ Trong thực tế, vấn đề quan trọng thường gặp xác nhận tất yêu cầu quyền thỏa mãn Trong vài trường hợp, nhúng sản phẩm mã nguồn mở vào sản phẩm thương mại phải chịu hậu không lường trước Khi đó, dễ dàng để xử lý tình code quản lý kho mã nguồn Nó minh chứng để khẳng định nhóm bạn tuân thủ tiêu chuẩn chuẩn quản lý đề 14.3.8 Tuân thủ không tuân thủ Một số tiêu chuẩn xác định tiêu chí cụ thể yêu cầu cần tuân thủ tiêu chuẩn Điều có nghĩa bạn làm theo hướng dẫn theo quy định, bạn có quyền khẳng định kế hoạch quản lý cấu hình bạn theo chuẩn xác định Tuy nhiên, bạn không thực tất thực hành cần thiết, bạn yêu cầu kế hoạch quản lý cấu hình bạn thực theo tiêu chuẩn Các bước cần phải tuân thủ thường thị “quy định”, đề nghị biểu thị từ “nên” Một số tiêu chuẩn đưa với dự định dẫn chúng không cần phải tuân thủ theo Phụ thuộc vào môi trường phát triển mà bạn xây dựng, bạn yêu cầu bạn tuân thủ với chuẩn đặc biệt Trong vài trường hợp, bạn nhận lợi ích từ việc thực thi thực hành tốt chứng minh kiểm toán cấu hình bạn bạn thực kiểm soát chuẩn IT 14.4 Áp dụng điều khoản tiêu chuẩn khung quản lý cấu hình Từng mục số điều khoản thường trích dẫn số tiêu chuẩn framework khác Tôi giải thích điều bản, bạn cần phải đọc toàn tiêu chuẩn để xác nhận hiểu biết bạn thuật ngữ bối cảnh tiêu chuẩn cụ thể Sau nhìn tổng quan quản lý cấu hình liên quan đến tiêu chuẩn framework mà bạn cần biết để xác nhận thực tiễn tốt thân bạn thực theo nguyên tắc công nghiệp có sẵn Trong số trường hợp, phép trích dẫn phần nhỏ theo nguyên văn tiêu chuẩn, phải khuyên bạn nên mặt pháp lý có thực tế tiêu chuẩn khung để có tranh hoàn chỉnh thực thành công thực hành tốt Sau nhìn tổng quan mà hy vọng giúp bạn bắt đầu 14.5 Tiêu chuẩn công nghiệp Nhiều tiêu chuẩn xuất sắc viết để hỗ trợ quản lý cấu hình Chúng thảo luận số tiêu chuẩn phổ biến phần này, bạn nên nhớ tiêu chuẩn thực hành tốt viết xem xét nhóm chuyên gia ngành Tôi lướt nhanh chóng nói tiêu chuẩn khôn ngoan, theo thời gian, bạn định không theo chúng thiết kế riêng cho chúng với nhu cầu riêng bạn Tuy nhiên, muốn chắn mà bắt đầu thảo luận cách lưu ý nhiều công việc vào việc tạo tiêu chuẩn công nghiệp cho hầu hết phần bạn làm theo chúng lợi ích từ bạn đồng nghiệp dành thời gian để tạo chúng Ngẫu nhiên, muốn đề cập đến nhiều tiêu chuẩn nhóm làm việc bao gồm người tình nguyện không nhận lợi ích từ tham gia họ chia sẻ họ đáng kể kiến thức kinh nghiệm Chúng nợ họ nợ lòng biết ơn đối công ty họ, hy vọng bạn liên hệ với để có tham gia với nỗ lực 14.5.1 IEEE 828-Tiêu chuẩn cho kế hoạch quản lý cấu hình phần mềm Tiêu chuẩn IEEE 828 kế hoạch cấu hình hướng dẫn sử dụng rộng rãi cho quản lý cấu hình phần mềm Các quy định IEEE không cho phép tiết lộ 10% tiêu chuẩn sách này, cung cấp cho bạn ý tưởng làm tiêu chuẩn giúp bạn khuyến khích bạn mua quyền từ IEEE Dưới phần lập kế hoạch quản lý cấu hình:  Giới thiệu mô tả mục đích kế hoạch, phạm vi ứng dụng, thành phần tài liệu tham khảo  Quản lý cấu hình xác định trách nhiệm có quyền hạn để hoàn thành hoạt động kế hoạch  Hoạt động quản lý cấu hình xác định tất hoạt động thực dự án  Lịch trình quản lý cấu hình xác định phối hợp hoạt động quản lý cấu hình với hoạt động khác dự án  Các tài nguyên cấu hình xác định công cụ nguồn lực vật chất người cần thiết để thực kế hoạch  Bảo trì kế hoạch quản lý cấu hình xác định cách mà kế hoạch giữ có hiệu lực Các hoạt động bao gồm xác định cấu hình, kiểm soát cấu hình, báo cáo tình trạng cấu hình, kiểm toán cấu hình đánh giá, kiểm soát giao diện, kiểm soát nhà cung cấp nhà thầu phụ Quản lý phát hành cung cấp mô tả cách xây dựng, phát hành phân phối sản phẩm phần mềm tài liệu kiểm soát thức 14.15.1.1 Sự tuân thủ tiêu chuẩn Tôi làm việc nhiều tổ chức, bao gồm công ty tư nhân, quan nhà nước, nhà thầu quốc phòng mà có hợp đồng thực theo yêu cầu quy định tiêu chuẩn IEEE 828 Kế hoạch quản lý cấu hình phù hợp với tiêu chuẩn, Muốn "kế hoạch cấu hình có phù hợp với yêu cầu IEEE Std 828 ", có nghĩa kế hoạch bao gồm việc giới thiệu, quản lý, hoạt động, lịch trình, nguồn lực, kế hoạch bảo trì mô tả Ngoài ra, tất hoạt động phải có nguồn lực giao để thực hoạt động quy định kế hoạch Nó yêu cầu xác định trình để tạo phiên sở kiểm soát thay đổi cho tất thành phần cấu hình(CI) Khi bạn đọc thông qua tiêu chuẩn, bạn nhận thấy số hoạt động mô tả theo yêu cầu Điều đề cập đến hoạt động tối thiểu cần thiết cho phù hợp với tiêu chuẩn Các hoạt động khác mô tả cách sử dụng công việc, điều có nghĩa họ tùy chọn, thực hành tốt mà bạn nên sử dụng để cải thiện bạn chất lượng suất IEEE 828 tiêu chuẩn cho cấu hình phần mềm Kế hoạch quản lý tiêu chuẩn liên quan đến cấu hình -được sử dụng phổ biến coi "tiêu chuẩn quốc gia", tiêu chuẩn khác hướng dẫn tài liệu sử dụng rộng rãi 14.5.2 ISO 10007-Hệ thống quản lý chất lượng-Hướng dẫn Quản lý Cấu hình ISO 10007 phần họ tiêu chuẩn ISO 9001, thiết kế để hỗ trợ hệ thống quản lý chất lượng (QMS) Nó cung cấp hướng dẫn việc sử dụng cấu hình quản lý việc phác thảo trình quản lý cấu hình, bao gồm cấu hình quản lý quy hoạch, xác định cấu hình, thay đổi kiểm soát, kế toán tình trạng cấu hình kiểm toán cấu hình 10 Cobit danh sách mục tiêu quan trọng cần xem xét thiết kế cấu hình chức kiểm soát thay đổi Tôi thường khuyên bạn nên bắt đầu với danh sách Dưới cắt giảm tôi: Xác định lập kế hoạch cho thay đổi cần thiết để hỗ trợ doanh nghiệp Đánh giá giảm thiểu rủi ro liên quan đến thay đổi đề xuất Thực thay đổi xác hiệu Cung cấp truy xuất nguồn gốc thay đổi, bao gồm người có thẩm quyền Kiểm tra xác minh thay đổi thực thành công Cung cấp thủ tục đáng tin cậy để trở lại thay đổi cần thiết Tiếp tục cải thiện cấu hình bạn thủ tục kiểm soát thay đổi Sau tạo danh sách riêng tôi, xem lại mục tiêu liệt kê Cobit, với khuôn khổ, cập nhật danh sách với mục tiêu mà giúp có công việc làm tốt Rõ ràng, bạn cần phải thiết lập ưu tiên vì, số chức tốt đẹp để có, trước tiên bạn nên giải nhu cầu 14.6.1.3.2 Xem xét liệu Dưới số số liệu cấu hình xấu không tồn thay đổi thủ tục kiểm soát: Số lượng sai lầm, lỗi kết từ vấn đề thay đổi cấu hình kết vấn đề bất ngờ nguy cao cho doanh nghiệp Số vấn đề hợp lệ xác định kiểm toán, đánh giá tuân thủ Số yêu cầu cho thay đổi cần thiết để từ chối không xác không đầy đủ thông số kỹ thuật Thiếu thông tin hạng mục cấu hình, bao gồm cấu hình vấn đề chẳng hạn phiên vá lỗi Số tiền trung tâm thành phố dịch vụ bị gián đoạn gây thay đổi không xác chi tiết kỹ thuật bỏ qua đánh giá tác động Số lượng yêu cầu thay đổi khẩn cấp cố gắng để bỏ qua tiêu chuẩn thay đổi quy trình quản lý Số lượng thời gian nhân viên cần thiết để thực hỗ trợ thay đổi Dưới số số liệu cần bạn có cấu hình tuyệt vời kiểm soát thay đổi chức năng: Sự hài lòng khách hàng đo lường khảo sát thông tin Số yêu cầu cho thay đổi hoàn thành thời hạn mà cố bất ngờ, vấn đề Thay đổi xử lý bên thứ ba mà không yêu cầu phát triển can thiệp 16 Số thay đổi hoàn tất vòng cửa sổ Số thay đổi xác định rõ kiểm soát thay đổi lặp lại trình (bao gồm tự động hóa) Số lượng thay đổi dễ dàng hỗ trợ cần thiết Số thay đổi hoàn thành bao gồm xét nghiệm cụ thể để xác nhận kiểm tra chức hệ thống sau thay đổi hoàn thành 16.4.1.3.3 Chỉ số mềm Tôi có cá nhân tìm thấy hai số mềm khác dấu hiệu rõ ràng quản lý thay đổi hiệu hiệu Đầu tiên khả để làm cho nhiều thay đổi nhỏ hoàn hảo mà nguy đáng kể, trái ngược với tiết kiệm tất thay đổi cho cửa sổ "Big Bang" bạn cần phát triển theo yêu cầu để đối phó với sai lầm vấn đề Các số mềm khác khả tự tin để làm cho thay đổi cửa sổ ngắn, trái ngược với yêu cầu thời gian dài cửa sổ với số lượng lớn nhân viên gọi để giải vấn đề Điều khó chịu vài người, thấy tổ chức có nhiều vấn đề mà họ đơn giản bỏ quản lý phát hành hiệu yêu cầu tất thay đổi thực vào tối thứ sáu với toàn nhân viên kêu gọi ngày cuối tuần tổ chức giả định việc thúc đẩy phát hành luôn có vấn đề yêu cầu tất người chia sẻ nỗi đau Trong số ngành công nghiệp khác văn hóa làm việc, hiệu suất subpar chấp nhận định mức Ví dụ,ở số nơi, giả định xe lửa xe buýt lịch trình 16.4.1.3.4 Đưa Cùng cấu hình Khuôn khổ Quản lý thay đổi Các tổ chức cần phải bắt đầu cách nhận nỗ lực liên quan đến việc tạo thực khuôn khổ quản lý thay đổi toàn diện, bao gồm trình xác định thủ tục để hỗ trợ vòng đời yêu cầu thay đổi nhiều để mô tả phần khuôn khổ quản lý thay đổi bạn Bạn chắn muốn có cách rõ ràng phù hợp để trình yêu câu thay đổi (CRS), mà sau xem xét Ban kiểm soát thay đổi (CCB) đánh giá tác động ưu tiên Quá trình xem xét phải dựa đánh giá giảm thiểu rủi ro 14.6.1.3.5 Thay đổi cấu hình cần xử lý Quy trình kiểm soát thay đổi? Mọi người thường hỏi liệu thay đổi cấu hình cần phải xử lý cách thức phát hành Đối với hầu hết phần, câu trả lời có, đặc biệt thay đổi có tiềm để đóng cửa hệ thống sản xuất Thậm chí dường "nhỏ" thay đổi cấu hình có 17 tác động tàn phá Vì vậy, tất cấu hình thay đổi lý tưởng nên xử lý cách kiểm soát thay đổi Kiểm soát bạn thay đổi trình cần phải đánh giá xem có thực "nhỏ" thay đổi chịu rủi ro đáng kể 14.6.1.4 Cải tiến qui trình liên tục Bất kỳ trình kiểm soát thay đổi cấu hình cần xây dựng chế để đánh giá thân không ngừng nâng cao Theo kinh nghiệm tôi, thường để thiết kế trình thay đổi kiểm soát toàn diện cho công nghệ quy mô lớn nỗ lực Thường có phận chuyển động nhiều, dẫn đến mức độ phức tạp mà làm cho gần xác định kiểm soát trình thay đổi hoàn hảo từ đầu Tuy nhiên, thường xác yêu cầu làm Có thường lý tốt cho lý nhóm sai lầm, không dễ dàng để xác định nguyên nhân gốc rễ vấn đề Là ý kiến Cách tốt để xử lý để tiếp tục xem xét cải thiện quy trình bạn với trọng tâm đặc biệt thay đổi thực cải tiến để giải thách thức vấn đề xảy môi trường bạn Trong phần tiếp theo, thảo luận cấu hình chức quản lý thay đổi 14.6.1.4.1 Căn Cấu hình chức Quản lý thay đổi Hình 14.1 cho thấy nên bao gồm cấu hình thay đổi bạn chức quản lý 18 Hình 14.1 14.6.1.4.2 Hỗ trợ cấu hình thiết yếu chức Quản lý thay đổi Nhiều chức mô tả khuôn khổ cobit cần thiết cho bạn bao gồm cấu hình quản lý thay đổi chức năng.bạn nhận thảo luận trước sách.xác định cấu hình phải gắn vào phiên ID tất thành phần cấu hình để thành công bạn kiểm toán phát hành mã sản xuất.ngoài để kiểm soát phiên hiệu quản lý mã nguồn bạn.mã nguồn tốt thực tiễn quản lý phát hành bao gồm việc tạo phiên sở để biết xác tất phiên mã nguồn thành phần cấu hình bao gồm thông báo đặc biệt.thực hành gọi mã phiên sở đóng gói phát hành lưu trữ thư viện phát hành trung tâm 14.6.1.4.3 Thách thức việc quản lý tài sản Dõi theo phiên sở thành phần cấu tài sản phần mềm điều cần thiết thực hành phức tạp để thực môi trường có quy mô lớn cấu hình chức quản lý thay đổi bao gồm thủ tục xác định tất phần mềm (phần cứng) thay đổi yêu cầu (và, tất nhiên, hiệu đính trình kiểm soát thay đổi) Quản lý môi trường phụ thuộc môi trường (cả biên dịch thời gian chạy) chức thường bị bỏ qua quan trọng cho thành công bạn Đào tạo thường bị bỏ qua cần phải chức quan trọng bao gồm việc xác định thay đổi theo yêu cầu phiên phần mềm Xác minh xác nhận phần trình bất kỳ, quá.Như đề cập trước, xác minh có nghĩa trình bạn có kết dự kiến Xác nhận có nghĩa trình mang lại kết xác! Trong phần tiếp theo, thảo luận cách lập kế hoạch thực trình mô tả mô hình Cobit 14.6.1.4.4 Thay đổi cần thiết chức hỗ trợ quản lý cấu hình Hình 14,2 cho thấy chức hỗ trợ mà bạn cần phải thực để hỗ trợ chức cốt lõi (các chức cốt lõi hiển thị hình 14.1) 14.6.1.4.5 Lập kế hoạch triển khai Kế hoạch cho việc thực Cobit khó khăn.Tôi thấy tổ chức cố gắng thông qua Cobit sở quy mô rộng để hỗ trợ nhu cầu việc tuân thủ (SOX) Đạo luật Sarbanes-Oxley Đây khó khăn thường kết ít-hơn-thành công ngoạn mục Hãy nhớ bạn không muốn bạn tổ chức "giả vờ" để theo Cobit Việc thông qua tiêu chuẩn 19 Khuôn khổ hội để đánh giá thực tiễn bạn tốt sau cải thiện quy trình bạn cách áp dụng thực hành ngành công nghiệp xác định tốt bạn thực cần phải cách bắt đầu xác định mục tiêu riêng bạn đặc biệt rủi ro mà bạn cần phải giảm thiểu Hãy chắn bạn có kế hoạch hỗ trợ hai đào tạo tất nhân viên tham gia Trong thực tế, tìm kết thấp, cải tiến hiển thị cách dễ dàng Bắt số thành công làm cho dễ dàng nhiều cho bạn để giải vấn đề khó khăn Ví dụ, nhiều tổ chức bắt đầu cách thực chức Kiểm soát thay đổi đơn giản để hành động người gác cổng để xem xét phát hành đẩy mạnh vào sản xuất.Thông thường, bạn xem xét thay đổi cấu hình.Điều đủ để giúp bạn bắt đầu với thay đổi chức điều khiển Sau bạn cần định chức thêm để cải thiện quy trình bạn Tôi thường nhìn vào sai lầm cách tuyệt vời để đánh giá Hình 14.2 14.6.1.5 Quản lý phát hành bị phá vỡ Mọi người thường gọi trình quản lý phát hành bị phá vỡ.Điều luôn hội tuyệt vời để tìm cách để cải thiện quy trình có Tôi thường tìm thấy nhiều điều thực tốt, luôn có lý lý nhóm nghiên cứu làm cho sai lầm Rà soát lại chức mô tả Cobit mô hình, yêu cầu xem xét 20 việc thử nghiệm thực phát hành đẩy mạnh vào sản xuất Tôi yêu cầu thủ tục phát hành chi tiết, bao gồm kịch để tự động hóa việc triển khai Tôi yêu cầu xem thủ tục cho việc lưu phát hành cần thiết Sai lầm phát hành mà không thường hội hoàn hảo để làm điều tốt chút Lời khuyên xem xét thực hành tốt mô tả tiêu chuẩn khuôn khổ (bao gồm Cobit) sau thí điểm cải tiến quy trình bạn cách thực thay đổi địa vấn đề mà bạn cần để giải mục tiêu mà bạn cần để đạt Đó phổ biến cho sai lầm thất bại để kích hoạt yêu cầu cho đánh giá đầy đủ thực hành có 14.6.1.6 Kết luận Cobit khuôn khổ tốt để sử dụng bạn muốn cải thiện CNTT bạn quy trình Thực hành tốt cấu hình quản lý thay đổi giúp bạn thiết lập thực hành liên quan đến CM-của riêng bạn Xuất sắc khuôn khổ khác cung cấp hướng dẫn, bao gồm CMMI ITIL 14.6.2 CMM/CMMI Mô hình thục khả gốc (CMM) tích hợp mô hình thục khả (CMMI) cung cấp hướng dẫn quy trình hiệu quả, bao gồm quản lý cấu hình Viện Công Nghệ Phần Mềm (SEI) Carnegie Mellon CMMI phương pháp tiếp cận trình cải thiện sử dụng để hướng dẫn cải tiến quy trình qua dự án, chia, toàn tổ chức CMMI giúp tích hợp truyền thống riêng biệt tổ chức chức năng, thiết lập mục tiêu cải thiện trình ưu tiên, cung cấp hướng dẫn quy trình chất lượng, cung cấp điểm tham chiếu cho thẩm định quy trình CMMI giúp tích hợp truyền thống riêng biệt tổ chức chức năng, thiết lập mục tiêu cải thiện trình ưu tiên, cung cấp hướng dẫn quy trình chất lượng, cung cấp điểm tham chiếu cho thẩm định quy trình CMMI thực trình cải tiến liên tục linh hoạt cách tổ chức cách thức hơn, tương tự gốc CMM Tôi làm việc nhiều tổ chức bao hàm cải tiến quy trình, đặc biệt với CMM / CMMI khuôn khổ Một cân nhắc khó chịu quan điểm truyền thống trình khu vực thực theo thứ tự cụ thể Trong thực tế, điều có nghĩa bạn bắt đầu đánh giá mã trước bạn thực nhà thầu phụ quản lý Điều ngớ ngẩn điểm đau không thực tập trung vào việc bảo trì nhà thầu phụ nhận xét mã cho trở lại đầu tư Đây ví dụ hoàn hảo thực cần thiết chỉnh khuôn khổ để đáp ứng nhu cầu tổ chức Hôm nay, thường nghe công ty tham khảo để thực CMMI cấp độ / 3, có nghĩa họ chọn khu vực trình từ cấp độ có liên quan đến họ tổ chức 21 Quản lý Cấu hình CMMI khu vực trình nói "một mục đích quản lý cấu hình thiết lập trì tính toàn vẹn sản phẩm làm việc cách sử dụng xác định cấu hình, kiểm soát cấu hình, kế toán tình trạng kiểm toán cấu hình "Chúng thảo luận từ ngữ có nghĩa trước chương này, công việc thực quản lý cấu hình liên quan đến việc tạo phương tiện để xác định tất thứ từ thành phần tài liệu mà vào việc tạo thông cáo mã bạn Bạn cần phải mã bạn (đôi gọi thiết lập điểm kiểm soát) để bạn trở lại xác phiên mã nguồn bạn tất cấu hình khác mục bạn cần Bạn cần phải kiểm soát thay đổi, cung cấp tình trạng tất thành phần cấu hình tạo trì quản lý cấu hình hệ thống bao gồm mã nguồn bạn hồ sơ xác tất thay đổi 14.6.2.1 Quản lý nhà thầu phụ CMM CMMI đặt giá trị mạnh mẽ quản lý nhà thầu Đây khuôn khổ Cobit nhiều tiêu chuẩn IEEE Đối với cấu hình quản lý, giám sát đặc biệt quan trọng Đó phổ biến cho công ty để mua hệ thống mà họ sau sửa đổi mở rộng cần thiết Mua sản phẩm từ nhà cung cấp nghĩa bạn không cần thành lập kiểm soát quản lý cấu hình Trong thực tế, nhiều lần, có hỏi nhà cung cấp để cung cấp cho khả hiển thị vào quản lý cấu hình riêng họ thực hành, đặc biệt thủ tục họ để xác định cấu hình mà bạn cần phải biết để tiến hành kiểm toán cấu hình Bạn cần phải thiết lập thay đổi kiểm soát để xử lý vấn đề thay đổi cấu hình, bao gồm mở cổng tường lửa , quản lý phụ thuộc giao diện với hệ thống khác Các khả hoàn thành mô hình luôn khuôn khổ tuyệt vời để bạn sử dụng đánh giá trình xác định cần phải thay đổi cải thiện Tôi tìm thấy hầu hết tổ chức cần giúp đỡ khác để thiết lập thực hành Một phương pháp tuyệt vời để sử dụng CMMI liên quan IEEE tiêu chuẩn để cung cấp thông tin việc làm để thực thiết lập thực điều mà bạn sử dụng để đánh giá tiến bạn xác định khu vực cải thiện cách sử dụng công cụ đánh phương pháp thẩm định CMMI Cải tiến qui trình (SCAMPI) Trong CMM sử dụng nhiều thập kỷ khuôn khổ cho việc thiết lập hiệu quy trình CNTT, mô hình gần ITIL itSMF khuôn khổ, tập trung chủ yếu vào quản lý cấu hình xác định thực hành tốt cho quản lý dịch vụ CNTT 14.6.3 Nền tảng itSMF ITIL ItSMF phát triển khuôn khổ đầy đủ mô tả thực hành tốt quản lý dịch vụ CNTT ITIL nhấn mạnh quản lý cấu hình thực hành tốt nhất, theo tôi, mô tả toàn diện CM thực hành mà nhìn thấy ITIL đáng sợ giải đòi hỏi năm lớn văn để thể tất thông tin cần thiết Khối lượng tập trung hầu 22 hết vào CM gọi trình chuyển đổi dịch vụ bao gồm hướng dẫn quản lý thay đổi, phát hành quản lý triển khai, dịch vụ tài sản quản lý cấu hình (SACM) ITIL có mạnh mẽ tập trung vào quản lý tài sản xử lý phần cứng phần mềm tài sản cần phải đặt kiểm soát Trong suốt khuôn khổ, có nhiều tập trung vào kế hoạch hoạt động quản lý trình thực Trong thực tế, tiêu đề khối lượng đề cập đến chuyển dịch vụ IT cấu hình khác mục từ tình trạng vòng đời Tôi thảo luận số khái niệm cốt lõi ITIL đây, đề nghị bạn có khuôn khổ trực tiếp từ itSMF để bạn đọc tất thông tin cần thiết mô tả khuôn khổ 14.6.3.1 Quản lý thay đổi Quản lý thay đổi liên quan đến việc xem xét, đánh giá tác động, phê duyệt, từ chối yêu cầu cho thay đổi ITIL mô tả thay đổi quản lý trình lặp lại chức cụ thể c tổ chức Tất thay đổi quản lý thông qua yêu cầu thay đổi, có dòng chảy công việc cụ thể đề nghị sửa đổi để nhu cầu tổ chức bạn ITIL chi tiết mà cho thấy dòng chảy trình cụ thể cho hành động thay đổi yêu cầu, triển khai, thay đổi hoạt động tiêu chuẩn Ngoài có danh sách các mục mà bạn nên bao gồm tài liệu bạn thay đổi Tôi thấy điều mức độ chi tiết khuôn khổ vô hữu ích cung cấp cho bạn điểm khởi đầu để tạo quy trình bạn Một số tổ chức áp dụng khuôn khổ toàn nghĩa vụ hợp đồng mong muốn thấy họ phù hợp ITIL Lý tưởng nhất, tổ chức bạn chọn thực hành làm cho ý nghĩa cắt giảm nạc tốt 14.6.3.2 Hội đồng cố vấn thay đổi ITIL tiêu chuẩn khung mà thấy khác biệt người chịu trách nhiệm cho trình kiểm soát thay đổi người Các chuyên gia công nghệ người thực hiểu tác động thay đổi cụ thể Hội đồng quản trị thay đổi tư vấn nhóm chuyên gia vấn đề (các doanh nghiệp vừa nhỏ) cung cấp hướng dẫn xảy thay đổi cụ thể ủy quyền Trong thực tế, điều quan trọng, thấy nhiều tình Ban kiểm soát thay đổi xem xét yêu cầu cho thay đổi thực không.Hiện có đủ tư vấn cho họ xảy đặc biệt thay đổi xảy Điều âm tuyệt vời, phổ biến cho trình "guru" tất chi tiết kỹ thuật (vì thông tin thường chuyên môn cao, với vài chuyên gia thực hiểu biết tất cần thiết chi tiết) Hội đồng quản trị thay đổi tư vấn giúp để xác định chuyên gia kỹ thuật người cần tư vấn mà không cần cố gắng để làm cho họ tham dự tất CCB họp Trong thực tế, điều làm cho nhiều ý nghĩa dẫn đến sai lầm kiểm soát tốt thay đổi 23 14.6.3.3 Quản lý cấu hình tài sản dịch vụ Quản lý cấu hình (SACM) ITIL tài sản dịch vụ cung cấp cách toàn diện cách tiếp cận để quản lý cấu hình, bao gồm quản lý tất thành phần cấu lần nghe nói phần mềm "tài sản." quản lý tài sản IT, ngạc nhiên bối rối quản lý tài sản làm cho có ý nghĩa nói đến máy tính máy tính để bàn tính máy in, Tôi có số vấn đề điều chỉnh với ý tưởng ứng dụng phần mềm coi tài sản Theo thời gian, nhận điều xác cách thức nên Về vấn đề ứng dụng phần mềm 14.6.3.4 Quản lý tài sản Quản lý tài sản cần phải xử lý phần vòng đời hoàn chỉnh.trong nhiều cách, bao gồm nhiều điểm dự định tình trạng kế toán mô tả tiêu chuẩn IEEE CMMI Tình trạng kế toán nhằm mục đích để theo dõi tình trạng mặt hàng guration confi suốt vòng đời họ ITIL khuôn khổ mô tả việc sử dụng hệ thống quản lý cấu hình (CMS) theo dõi tình trạng tất tài sản liên quan 14.6.3.5 Hệ thống quản lý cấu hình cấu hình Quản lý hệ thống sử dụng để theo dõi tất tài sản liên quan họ thay đổi Trong thực tế, thách thức để giữ cho CMS up-to-date sở thường xuyên Nếu điều đòi hỏi người tự cập nhật sở liệu, bạn tìm thấy CMS cập nhật nhanh chóng Đó tốt để tự động hóa quy trình bạn nhiều tốt để cập nhật CMS (hoặc tương đương) phần trình quản lý phát hành 14.6.3.6 Thư viện phương tiện truyền thông chung (DML) DML la kho lưu trữ tất phiên Đó điều cần thiết mà DML giữ an toàn truy cập cách ủy quyềnphát hành nhân viên quản lý Trong Chương 1, "Quản lý Mã nguồn", chúng tôithảo luận việc sử dụng mã nguồn quản lý để quản lý tất mã nguồn phần việc phát hành ITIL không mô tả phần mềm trình phát triển chủ yếu tập trung vào quản lý dịch vụ CNTT Đối với mô tả ITIL, cần phải bao gồm quản lý mã nguồn vì, thực tế, hệ thống mã nguồn quản lý cần phải tích hợp với DML Phát triển tương tác hàng ngày với công cụ SCM quản lý phát hành Nhóm nghiên cứu xây dựng triển khai việc phát hành sở thức xếp hàng 24 14.6.3.7 Phát hành quản lý triển khai ITIL Khuôn khổ tập trung vào nỗ lực lập kế hoạch cần thiết để thực việc phát hành quản lý triển khai Ngoài có tập trung vào giảm thiểu tác động dịch vụ bị ảnh hưởng phát hành ITIL hy vọng phiên đóng gói cách thích hợp, theo dõi, cài đặt, thử nghiệm, cần thiết, hỗ trợ thông qua trình gỡ bỏ cài đặt xác định 14.6.3.8 Tích hợp CMS, DML, CMDBs, SCM Hình 14,3 cho thấy mối quan hệ hệ thống cấu hình quản lý (CMS), cấu hình quản lý sở liệu (CMDBs), phương tiện truyền thông thư viện dứt khoát (DML), mã nguồn hệ thống quản lý (SCM) Lưu ý kho lưu trữ mã nguồn giống cấu hình hệ thống quản lý; sau thường sở liệu theo dõi tình trạng cấu hình suốt vòng đời họ Đường sở thường lưu giữ DML, mà số trường hợp trường hợp riêng biệt hệ thống quản lý mã nguồn dự định sử dụng cho tài sản quản lý bắt đầu với việc xác định mục tiêu quan trọng với bạn tổ chức bạn Quá nhiều người tập trung vào nhận thức CMDBs nhiều mùa thu ngắn mong đợi họ, thay 25 nhận giá trị mà họ cung cấp tiến tới làm cho tốt tốt Dưới làm để tiếp cận thực CMDB phần nỗ lực cải thiện trình bạn 14.6.3.9 Quản lý sở liệu cấu hình Có nhiều loại khác quản lý sở liệu cấu hình CMDBs dành riêng cho thiết bị giám sát môi trường đầy đủ chức sở liệu nhận đầu vào từ nhiều nguồn khác (chẳng hạn CMDBs khác) Trong trường hợp thứ hai, thường tham khảo CMDB liên, thường nhiều chuyên ngành CMDBs nguồn cấp liệu thông tin gốc CMDB hợp thông tin cung cấp giao diện điều khiển thông tin Một số loại CMDBs khoảng thời gian dài Tuy nhiên, số đồng nghiệp trích khái niệm ITIL CMDB không thực tế không thực đầy đủ Theo tôi, người trích ITIL tích điểm quan trọng mà ITIL hướng dẫn có giá trị, trình cải tiến thúc đẩy từ bên tổ chức Một khuôn khổ tiêu chuẩn thực hướng dẫn.Rõ ràng, doanh nghiệp bạn hợp đồng yêu cầu bạn tuân theo tiêu chuẩn khung, trình cải tiến bắt đầu với việc xác định mục tiêu quan trọng với bạn tổ chức bạn.Quá nhiều người tập trung vào nhận thức nhiều CMDBs rơi ngắn kỳ vọng họ, thay nhận giá trị mà họ cung cấp làm việc hướng tới làm cho tốt tốt hơn.Dưới làm để tiếp cận thực CMDB phần nỗ lực cải thiện trình 14.6.3.10 Quy trình cải tiến cho CMDBs Theo kinh nghiệm tôi, luôn tốt để Defi ne mục tiêu cải tiến trình nỗ lực điều kiện hẹp 14.6.3.11 Đơn giản môi trường giám sát Tôi làm việc tổ chức mã nguồn quản lý kho sở liệu sản xuất đầy đủ tính Tổ chức có giá trị tài sản kho SCM, mã có viết tắt thảm họa lớn Để bảo vệ mã chúng tôi, thường xuyên chạy kiểm tra toàn vẹn kho lưu trữ SCM Trong trường hợp, thiết bị lưu trữ sai kết kho mã nguồn trở thành bị hỏng.May mắn thay, không dòng mã có kịch kiểm tra tính toàn vẹn kho sở hàng đêm Phải hai nhà cung cấp tháng tham gia để tìm vấn đề sửa chữa nó, mà hóa lại lỗi cấu hình tầm thường Trong đó, không số mã bị phát vấn đề thực biện pháp để giải vấn đề Nếu giám sát chỗ, có khả nhiều năm làm việc công ty mã nguồn tài sản có nguy 26 14.6.3.12 Đưa CMDB bạn Tôi khuyên bạn nên bạn xem xét rủi ro mục tiêu bạn bạn định làm để thực CMDB bạn Những tài sản làm bạn cần theo dõi? Những kiện cần thiết để xem xét giải lập tức? Có lẽ bạn cần phải theo dõi môi trường bạn không gian đĩa nguồn lực sẵn có, bao gồm kết nối nguồn lực cần thiết Quá trình cá nhân cần phải giám sát để thấy họ lại trực tuyến có sẵn Một số CMDBs bạn dành riêng cho thiết bị với trọng tâm thu hẹp, người khác có tập trung rộng (thường tiếp nhận đầu vào từ thiết bị chuyên ngành) Hãy chắn sai lầm, vấn đề xảy bạn xem xét liệu thêm CMDB (hoặc chức cải thiện với có CMDB) giúp tránh vấn đề tương lai Trong thực tế, bạn khả ngăn chặn cố xảy ra, bạn nên tình nơi mà vấn đề tương tự xảy CMDBs cung cấp tuyệt vời, chi phí-hiệu để xử lý giám sát môi trường bạn Liên quan chặt chẽ chủ đề kiểm tra tự động Trong thực tế, phổ biến để sử dụng thử nghiệm phần cách tiếp cận bạn để theo dõi kiểm soát môi trường bạn 14.6.3.13 Xác nhận thử nghiệm Cấu hình quản lý thử nghiệm liên quan chặt chẽ theo nhiều cách.các ITIL khuôn khổ làm công việc tuyệt vời việc quản lý cấu hình quy trình cần bao gồm chức thử nghiệm Thử nghiệm tiềm ẩn tất thứ mà làm, cải tiến quy trình kiểm tra tự động hướng dẫn sử dụng bạn tác động đáng kể chất lượng suất bạn Ví dụ, triển khai phát hành không coi hoàn thành kiểm tra khói thực thành công Nếu kiểm tra khói không, bạn cần quay trở lại việc phát hành Cấu hình thực hành quản lý tốt làm cho ủng hộ thay đổi (không có vấn đề đột xuất) giúp đỡ để cải thiện bạn chất lượng suất Ngay thay đổi nhỏ nên luôn kiểm tra Việc phát hành sở cần xác nhận cách thực kiểm toán cấu hình, mô tả trước sách Quá trình xác nhận phải tự động hóa; không, không thực tế để thực cách thường xuyên Một số công cụ tốt tự động hóa trình này, bạn nên xem xét xác nhận thử nghiệm phần CM yêu cầu thực hành tốt bạn 14.6.3.14 Kết luận Theo tôi, khuôn khổ itSMF ITIL đưa thông tin theo nhiều cách đề xuất hoạt động CM xuất sắc tốt Bạn thấy đòi hỏi hành trình để thực tất thực hành tốt Bạn hoàn toàn nên sử dụng ITIL phối hợp với khuôn khổ khác Cobit CMMI bạn nên làm cho việc sử dụng tiêu chuẩn có từ tổ chức tiêu 27 chuẩn IEEE để cung cấp hướng dẫn chi tiết để hỗ trợ tất trình bạn (đặc biệt phát triển nơi ITIL không tập trung) Đó chắn thời gian tuyệt vời để ngành công nghiệp trình cải thiện, trình tốt quan trọng tổ chức sản xuất có nhiều nguồn tuyệt vời CM tốt thực hành Một nguồn tuyệt vời IEEE Công Nghệ Phần Mềm phần Kiến thức (SWEBOK) 14.6.4 SWEBOK Mục đích hướng dẫn cho quan Công Nghệ Phần Mềm Kiến thức (SWEBOK) cung cấp đặc tính thống xác nhận giới hạn kỷ luật công nghệ phần mềm cung cấp truy cập chỗ để thể kiến thức hỗ trợ kỷ luật Cơ thể kiến thức chia thành mười phần mềm kiến thức kỹ thuật khu vực (Kas) cộng với chương thêm cung cấp nhìn tổng quan Kas ngành liên quan chặt chẽ Những mô tả Kas thiết kế để phân biệt đối xử khái niệm quan trọng khác nhau, cho phép người đọc để tìm cách họ cách nhanh chóng cho đối tượng quan tâm vào việc tìm kiếm chủ đề, độc giả gọi giấy tờ quan trọng chương sách lựa chọn ngắn gọn trình bày kiến thức Các lĩnh vực kiến thức SWEBOK ● Yêu cầu ● Thiết kế ● Xây dựng ● Kiểm tra ● Bảo trì ● cấu hình quản lý ● Quản Lý Cơ Khí ● Kỹ thuật trình ● Kỹ thuật công cụ phương pháp ● Chất Lượng Phần Mềm 14.6.4.1 Cấu hình phần mềm quản lý SWEBOK Đối với SWEBOK, phần mềm quản lý cấu hình (SCM) kỷ luật xác định cấu hình phần mềm điểm khác biệt thời gian cho mục đích hệ thống kiểm soát thay đổi cấu hình trì tính toàn vẹn truy xuất nguồn gốc cấu hình phần mềm suốt vòng đời hệ thống KA CM bao gồm sáu phần:  Quản lý trình SCM Quản lý trình SCM bao gồm chủ đề bối cảnh tổ chức cho SCM, hạn chế hướng dẫn cho SCM, lập kế hoạch cho SCM, kế hoạch SCM, giám sát SCM  Xác định cấu hình phần mềm Nhận dạng phần mềm cấu hình xác định mục kiểm soát, thiết lập chương trình nhận dạng cho mục phiên họ, thiết lập công cụ kỹ thuật sử dụng việc mua quản lý mặt hàng 28     kiểm soát Các chủ đề nhiều vùng phụ xác định mục cần kiểm soát phần mềm thư viện Kiểm soát cấu hình phần mềm quản lý thay đổi vòng đời phần mềm Các chủ đề (đầu tiên) yêu cầu, thẩm định, phê duyệt thay đổi phần mềm, (thứ hai), thực phần mềm thay đổi, (thứ ba), độ lệch miễn trừ Kế toán Tình trạng cấu hình phần mềm kế toán Tình trạng cấu hình phần mềm bao gồm chủ đề tình trạng thông tin phần mềm cấu hình báo cáo tình trạng cấu hình phần mềm kiểm toán Cấu hình phần mềm Điều bao gồm phần mềm cấu hình chức kiểm toán, kiểm toán cấu hình phần mềm vật lý, trình kiểm toán đường sở phần mềm quản lý Phiên phần mềm giao hàng Nhiều vùng phụ bao gồm phần mềm xây dựng quản lý phát hành phần mềm SWEBOK có sẵn miễn phí dạng HTML hài hoà với tất IEEE tiêu chuẩn sở liên tục Đó dự kiến mà SWEBOK trưởng thành phát triển thành khuôn khổ toàn diện 14.6.5 Open Unified Process (openUp) Open Unified Process (OpenUP), phần trình Eclipse Framework, lặp lặp lại mô hình trình phấn đấu để hai nhanh nhẹn sơ sài Mở rộng Quy trình thống áp dụng lặp lặp lại gia tăng phương pháp tiếp cận cấu trúc vòng đời hình thức sáng cung cấp phát triển toàn diện khuôn khổ OpenUP bao trùm triết lý thực dụng, nhanh nhẹn, tập trung vào tính chất hợp tác phát triển phần mềm Nó công cụ thuyết bất khả tri, thấp lễ trình mở rộng để giải loạt rộng rãi dự án loại Quá trình thống có nhiều hình thức năm qua phát triển theo thời gian Tôi chống lại vào lịch sử trình thống (và thực mã nguồn mở gọi OpenUp) sách này, thay vào thảo luận tiến hóa trang web hỗ trợ Unified Process lặp lặp lại tò mò hỗ trợ nhiều văn (được gọi vật) Thông thường, người tin họ yêu cầu phải bao gồm vật nhiều thực cần thiết (làm cho phương pháp chi tiết cần thiết) Một số thiết yếu Các vật kế hoạch quản lý cấu hình, thay đổi yêu cầu quản lý,hỗ trợ cho hội nhập liên tục, quy hoạch tổng thể dự án có cá nhân tìm thấy cấu trúc liên kết để tổ chức thử nghiệm để thể đặc biệt hữu ích Nhìn chung, tổ chức cấu trúc liên kết tài liệu OpenUP tuyệt vời, nhiều tổ chức phụ thuộc nhiều vào trình thống moät nhiều hình thức Người ta thường nói chìa khóa để thành công với Quy trình Unified sử dụng đồ tạo tác hoàn toàn cần thiết hướng dẫn giới hạn lựa chọn bạn cách liên tục tự hỏi câu hỏi này: điều xấu xảy không bao gồm tạo tác này? 29 14.6.6 Agile/SCRUM Sự nhanh nhẹn hoạt động Nếu bạn chưa làm việc trở nên nhanh nhẹn hơn, bạn cần để bắt đầu ngày hôm Agile Tập chung vào thực quan trọng việc nỗ lực phát triển phần mềm Có sách tốt phát triển nhanh nhẹn, trọng tâm sách Tuy nhiên, không muốn để bao gồm vài điểm quan trọng chương có liên quan đến thực hành CM tốt Tập chung nhanh nhẹn vào thực tất yêu cầu lên phía trước Trung thực biết chưa hiểu điều cần thiết trình nỗ lực cải thiện Thêm vào đó, bạn cần phải nhận tài liệu yêu cầu bạn cần thiết Nhiều lần, tài liệu truy xuất nguồn gốc yêu cầu tuyệt đối cho mục đích quy định Tôi tin bạn trở thành nhanh vượt qua kiểm toán bạn Cung cấp tiêu chuẩn để hỗ trợ Agile quan trọng phần nỗ lực Tôi làm việc với chuyên gia công nghệ khác cung cấp tiêu chuẩn công nghiệp bổ sung để hỗ trợ nhanh để bạn thấy lợi ích nhanh nhẹn thông qua kiểm toán bạn 14.6.6.1 Sự linh động hỗ trợ triển khai xây dựng Cấu hình thực hành quản lý tốt giúp hỗ trợ phát triển Agile cung cấp nhanh chóng (tự động) thủ tục để xây dựng, đóng gói, ứng dụng triển khai lặp lặp lại sở Theo tôi, Agile phát triển mà không thực hành CM xuất sắc tốt Một CM có uy tín thực hành liên tục tích hợp 14.6.6.2 Sự tích hợp liên tục Martin Fowler người khác làm công việc tuyệt vời việc thúc đẩy liên tục hội nhập (CI) thực hành tốt tiềm ẩn phát triển Agile CI thường thực tự động xây dựng (và triển khai môi trường thử nghiệm) có nghĩa kích hoạt mã kiểm tra (hoặc cam kết) để quản lý mã nguồn kho Đây phương pháp cổ điển đến CI, thấy tổ chức xây dựng hàng đêm thích hợp để xây dựng kích hoạt mã sốkiểm tra (hoặc cam kết) Tuy nhiên, tích hợp mã bạn sớm thường xuyên tiềm ẩn ngày trở nên nhanh nhẹn thực hành cốt lõi CM tốt nhất, Agile CM phát triểnnhanh chóng dễ dàng chủ đề sách đầy đủ 30