Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 6+7: Vẫn đề quản lí và tổ chức quản lí cấu hình và kiểm soát thay đổi - Nguyễn Thị Thanh Trúc

Nội dung text: Bài giảng Phát triển vận hành bảo trì phần mềm - Chương 6+7: Vẫn đề quản lí và tổ chức quản lí cấu hình và kiểm soát thay đổi - Nguyễn Thị Thanh Trúc

1. TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN KHOA CÔNG NGHỆ PHẦN MỀM PHÁT TRIỂN VẬN HÀNH BẢO TRÌ PHẦN MỀM ThS. NGUYỄN THỊ THANH TRÚC UIT-VNUHCM 2009 1
2. Nội dung (Chương 6 & 7) VẤN ĐỀ QuẢN LÝ VÀ TỔ CHỨC QUẢN LÝ CẤU HÌNH KiỂM SOÁT THAY ĐỔI SEMINAR Thảo luận và làm bài tập UIT-VNUHCM 2009 Company Logo 2
3. Chương 6 & 7: VẤN ĐỀ QuẢN LÝ VÀ TỔ CHỨC QUẢN LÝ CẤU HÌNH & KiỂM SOÁT THAY ĐỔI 6.1 VẤN ĐỀ QuẢN LÝ VÀ TỔ CHỨC 7.1 QuẢN LÝ CẤU HÌNH 7.2 KiỂM SOÁT THAY ĐỔI UIT-VNUHCM 2009 3
4. 6.1 VẤN ĐỀ QuẢN LÝ VÀ TỔ CHỨC qGiới thiệu qĐịnh nghĩa qTrách nhiệm quản lý qCải thiện năng suất bảo trì q Nhóm bảo trì q Huấn luyện và đào tạo nhân sự q Chế độ tổ chức UIT-VNUHCM 2009 4
5. Cải thiện năng suất bảo trì qChọn người phù hợp qĐộng lực nhân sự bảo trì qMột số cách để thúc đẩy nhâ sự thông qua, khen thưởng, giám sát phù hợp, mẫu phân công việc và công nhận : o Khen thưởng: o Cấp trên giám sát: o Mẫu phân công việc : o Công nhận: o Cấu trúc nghề nghiệp : qTruyền thông o Người tài nguyên tương xứng thích hợp o Kiến thức phạm vi UIT-VNUHCM 2009 5
6. Nhóm bảo trì qNhóm tạm thời qNhóm cố định o Lãnh đạo nhóm bảo trì o The coleader o user-liaison o maintenance administrator o maintenance programmers UIT-VNUHCM 2009 6
7. Huấn luyện và đào tạo nhân sự qMục tiêu o Nâng cao mức nhận thức üHiểu nhu cầu cụ thể üNhân sự ít kinh nghiệm (e.g. mới tuyển dụng) được gán công việc bảo trì, o Cải thiện sự công nhận qChiến lược đào tạo và huấn luyện o Đào tạo đại học : o Hội nghị và hội thảo : o Kinh nghiệm truyền nhau : UIT-VNUHCM 2009 7
8. Bài tập qExercise 10.1 Bạn là quản lý bảo trì với nhiệm vụ thuyết cấp trên tăng ngân sách cho bộ phận bảo trì. Trong báo cáo trình bày, những quan điểm gì bạn cần nhấn mạnh trong nỗ lực đạt được mục tiêu đề ra /? qExercise 10.2 Năng lực nhân sự làm phát triển phần mềm khá cao hơn công việc của bảo trì phần mềm. Giải thích tại sao nói vậy. Và nếu bạn là người quản lý bảo trì phần mềm bạn thử thu hút người năng lực cao để làm cho bộ phận của bạn như thế nào. UIT-VNUHCM 2009 8
9. Chế độ tổ chức qKết hợp phát triển và bảo trì o Module Ownership o Change Ownership o Work-Type o Application-Type qBộ phận bảo trì riêng biệt qExercise 10.3 Bảo trì phần mềm là truyền thống phần bỏ qua giữa các khoá học khoa học máy tính và công nghệ phần mềm. Nói tai sao có khác biệt môi trường mức đại học và bộ phận bảo trì công nghiệp có thể là nguyên nhân chính cho những bỏ qua này. UIT-VNUHCM 2009 9
10. 7. QuẢN LÝ CẤU HÌNH VÀ KiỂM SOÁT THAY ĐỔI q 7.1 QUẢN LÝ CẤU HÌNH o Định nghĩa o Quản lý cấu hình o Gốc nhìn cụ thể của quản lý cấu hình o Kiểm soát phiên bản (Version Control) o Building o Quản lý môi trường o Kiểm soát qui trình q 7.2 KIỂM SOÁT THAY ĐỔI o Trách nhiệm của quản lý trong kiểm soát thay đổi o Sưu liệu o Phân loại tài liệu phần mềm o Vai trò của sưu liệu phần mềm o Tạo và bảo trì sưu liệu có chất lượng UIT-VNUHCM 2009 10
11. 7.1 QUẢN LÝ CẤU HÌNH qĐịnh nghĩa qQuản lý cấu hình qGốc nhìn cụ thể của quản lý cấu hình qKiểm soát phiên bản (Version Control) qBuilding qQuản lý môi trường qKiểm soát qui trình UIT-VNUHCM 2009 11
12. Giới thiệu qNếu không quản lý cấu hình tốt: o Một module được xây dựng và kiểm chứng tốt bất ngờ không hoạt động o Một chức năng vừa được thêm vào phần mềm không tồn tại o Một lỗi đã được sửa xuất hiện trở lại UIT-VNUHCM 2009 12
13. q Quản lý cấu hình tốt sẽ giúp khắc phục các tình trạng: o Cập nhật đồng thời: Một nhóm nhiều người cùng làm việc trong cùng một chương trình, những thay đổi của người cuối cùng có thể xóa đi phần làm của người khác. o Chia sẻ mã nguồn: Trong các hệ thống lớn, khi những chức năng chung được thay đổi, tất cả nhân viên đều cần biết Nếu không có cách quản lý code hiệu quả, sẽ rất khó khăn trong việc tìm kiếm và thông báo cho mọi người. o Phát hành các phiên bản: Các phần mềm lớn đều được phát hành nhiều phiên bản. Khi một phiên bản được phát hành, phiên bản khác đang được test, phiên bản khác đang được phát triển. Nếu có khách hàng phát hiện lỗi, lỗi phải được sửa trong tất cả các phiên bản UIT-VNUHCM 2009 13
14. Định nghĩa q“Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team.” Wayne Babich Software Configuration Management: Coordination for Team Productivity Addison-Wesley, 1986 q“Configuration management is unique identification, controlled storage, change control, and status reporting of selected intermediate work products, product components, and products during the life of a system” Anne Mette Jonassen Hass Configuration management Principles and Practice Addison-Wesley, 2002 UIT-VNUHCM 2009 14
15. Định nghĩa (tt) qIEEE Definition ( IEEE Std. 610.12.1990 ) o CM is a discipline applying technical and administrative surveillance to üIdentify and document the functional and physical characteristics of Configuration Items üControl changes to these characteristics üRecord and report change processing & implementation status üVerify compliance with specified requirements UIT-VNUHCM 2009 15
16. Một số lưu ý qQuản lý cấu hình liên quan đến cả công cụ và tiến trình qTất cả các dự án đều cần một mức độ quản lý nhất định qTất cả các thành viên đều có trách nhiệm trong quản lý cấu hình UIT-VNUHCM 2009 16
17. What Are These Changes? changes in business requirements changes in technical requirements changes in user requirements other documents software models Project Plan data Test code UIT-VNUHCM 2009 17
18. The Software Configuration programs documents The pieces data UIT-VNUHCM 2009 18
19. Baselines – what are they? qThe IEEE (IEEE Std. No. 610.12-1990) defines a baseline as: üA specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. qa baseline is a milestone in the development of software that is marked by the delivery of one or more software configuration items (SCI) and the approval of these software configuration items that is obtained through a formal technical review. o SCI is information that is created as part of the software engineering process. UIT-VNUHCM 2009 19
20. Software Configuration Objects Name Attributes Compositional Relation Interrelationship UIT-VNUHCM 2009 20
21. SCM Repository q The Software Configuration Management (SCM) repository is the set of mechanisms and data structures that allow a software team to manage change in an effective manner q The repository performs or precipitates the following functions [FOR89]: o Data integrity o Information sharing o Tool integration o Data integration o Methodology enforcement o Document standardization UIT-VNUHCM 2009 21
22. Repository Content UIT-VNUHCM 2009 22
23. Repository Features (i.e. tools to support the following) q Versioning. o saves all of these versions to enable effective management of product releases and to permit developers to go back to previous versions q Dependency tracking and change management. o The repository manages a wide variety of relationships among the data elements stored in it. q Requirements tracing. o Provides the ability to track all the design and construction components and deliverables that result from a specific requirement specification q Configuration management. o Keeps track of a series of configurations representing specific project milestones or production releases. Version management provides the needed versions, and link management keeps track of interdependencies. q Audit trails. o establishes additional information about when, why, and by whom changes are made. UIT-VNUHCM 2009 23
24. SCM Elements q Component elements -a set of tools coupled within a file management system (e.g., a database) that enables access to and management of each software configuration item. q Process elements- a collection of procedures and tasks that define an effective approach to change management (and related activities) for all constituencies involved in the management, engineering and use of computer software. q Construction elements - a set of tools that automate the construction of software by ensuring that the proper set of validated components (i.e., the correct version) have been assembled. q Human elements - to implement effective SCM, the software team uses a set of tools and process features (encompassing other CM elements) UIT-VNUHCM 2009 24
25. The SCM Process Addresses the following questions q How does a software team identify the discrete elements of a software configuration? q How does an organization manage the many existing versions of a program (and its documentation) in a manner that will enable change to be accommodated efficiently? q How does an organization control changes before and after software is released to a customer? q Who has responsibility for approving and ranking changes? q How can we ensure that changes have been made properly? q What mechanism is used to appraise others of changes that are made? UIT-VNUHCM 2009 25
26. Layers of the SCM Process SCM Tasks: • Identification • Change Control • Version Control • Configuration Auditing • Reporting Identification of Basic Objects and aggregate Objects. UIT-VNUHCM 2009 26
27. Version Control q Version control combines procedures and tools to manage different versions of configuration objects that are created during the software process q A version control system implements or is directly integrated with four major capabilities: o a project database (repository) that stores all relevant configuration objects o a version management capability that stores all versions of a configuration object (or enables any version to be constructed using differences from past versions); o a make facility that enables the software engineer to collect all relevant configuration objects and construct a specific version of the software. o an issues tracking (also called bug tracking) capability that enables the team to record and track the status of all outstanding issues associated with each configuration object. UIT-VNUHCM 2009 27
28. Version Control qCác version có thể được đánh dấu để thể hiện o Các mốc phát triển o Việc chấp nhận một thành phần o Hoàn thành baseline qVersion control tool : Rational® ClearCase®, Microsoft® Visual Source Safe™, CVS, SubVersion, UIT-VNUHCM 2009 28
29. Configuration Audit q A software configuration audit complements the formal technical review by addressing the following questions: 1. Has the change specified in the Engineering Change Order (ECO) been made? Have any additional modifications been incorporated? 2. Has a formal technical review been conducted to assess technical correctness? 3. Has the software process been followed, and have software engineering standards been properly applied? 4. Has the change been "highlighted" in the SCI? Have the change date and change author been specified? Do the attributes of the configuration object reflect the change? 5. Have SCM procedures for noting the change, recording it, and reporting it been followed? 6. Have all related SCIs been properly updated? UIT-VNUHCM 2009 29
30. Auditing Change Requests SQA Plan SCIs SCM Audit UIT-VNUHCM 2009 30
31. Configuration Status Reporting (Status Accounting) Answers the following question: 1. What happened ? 2. Who did it ? 3. When did it happen ? 4. What else will be affected? UIT-VNUHCM 2009 31
32. Configuration Status Reporting (Status Accounting) Change Change Reports Requests ECOs SCIs Status Accounting Reporting UIT-VNUHCM 2009 32
33. Các hoạt động liên quan đến quản lý cấu hình qĐịnh danh qTổ chức, lưu trữ qQuản lý thay đổi qBáo cáo tình trạng UIT-VNUHCM 2009 33
34. Định danh các thành phần cấu hình qMục đích của việc định danh các thành phần cần quản lý cấu hình là để có thể xác định duy nhất chúng, xác định được mối quan hệ với thế giới bên ngoài và với những thành phần khác. qCần có một cơ chế định danh chung tất cả các thành phần cấu hình UIT-VNUHCM 2009 34
35. Tổ chức, lưu trữ qMục đích của lưu trữ o là nhằm đảm bảo các thành phần cấu hình không bị thất lạc hoặc bị hư hỏng. o Đảm bảo các thành phần cấu hình có thể được tìm thấy bất cứ khi nào cần. o Đảm bảo phát hành nó đúng với những gì mong đợi o Giúp biết được ai tạo ra, ai cập nhật và ai copy, sử dụng UIT-VNUHCM 2009 35
36. Quản lý thay đổi qTrong quá trình phát triển và bảo trì sản phẩm, việc thay đổi là không thể tránh khỏi o Khách hàng thay đổi o Developer sửa lỗi o Môi trường thay đổi qĐảm bảo việc thay đổi các thành phần cấu hình o Được tiến hành có giám sát o Tất cả các nhóm hoặc cá nhân liên quan đến thành phần cấu hình được thông báo về việc thay đổi UIT-VNUHCM 2009 36
37. Báo cáo tình trạng qBáo cáo tình trạng cung cấp thông tin cần thiết để quản lý hiệu quả quá trình phát triển và bảo trì qTất cả mọi thành phần đưa vào quản lý cấu hình đều có thể cung cấp thông tin để báo cáo tình trạng UIT-VNUHCM 2009 37
38. 7.2 KIỂM SOÁT THAY ĐỔI qTrách nhiệm của quản lý trong kiểm soát thay đổi qSưu liệu qPhân loại tài liệu phần mềm qVai trò của sưu liệu phần mềm qTạo và bảo trì sưu liệu có chất lượng UIT-VNUHCM 2009 38
39. Change Control STOP UIT-VNUHCM 2009 39
40. Change Control Process—I need for change is recognized change request from user developer evaluates change report is generated change control authority decides request is queued for action change request is denied user is informed change control process—II UIT-VNUHCM 2009 40
41. Change Control Process-II assign people to SCIs check-out SCIs make the change review/audit the change establish a “baseline” for testing change control process—III UIT-VNUHCM 2009 41
42. Change Control Process-III perform SQA and testing activities check-in the changed SCIs promote SCI for inclusion in next release rebuild appropriate version review/audit the change include all changes in release UIT-VNUHCM 2009 42
43. Các hoạt động kiểm soát thay đổi qChọn từ danh sách ưu tiên hàng đầu. qTái tạo vấn đề (nếu có một). qPhân tích mã nguồn (và đặc tả nếu có sẵn). qHợp nhất thay đổi. qThiết kê những thay đổi và kiểm thử. qĐảm bảo chất lượng. UIT-VNUHCM 2009 43
44. Trách nhiệm của quản lý trong kiểm soát thay đổi qRa quyết định nếu thay đổi nên được làm : Nó là công việc của Ban kiểm soát thay đổi -Change Control Board (CCB) để quyết định có chấp nhận hay không những yêu cầu thay đổi. qQuản lý và thực hiện những thay đổi : qThẩm định chất lượng : UIT-VNUHCM 2009 44
45. Mẫu yêu cầu thay đổi (Change Request Form) qName of system qVersion qRevision qNgày (Date) qYêu cầu bởi (Requested by) qTóm tắt thay đổi (Summary of change) qNguyên nhân (Reasons for change) qThành phần phần mềm yêu cầu thay đổi qTài liệu yêu cầu thay đổi qChi phí ước tính UIT-VNUHCM 2009 45
46. qExercise 11.4 Điều tra khái niệm mẫu kiểm soát thay đổi và thiết kế mẫu thay đổi chi tiết trong một tổ chức mà hỗ trợ nhiều phiên bản khác nhau của những sản phẩm phần mềm khác nhau đối với cơ sở người dùng rất lớn. Cho nguyên nhân bao gồm mỗi trường trên mẫu. Xem chi tiết ở [255] UIT-VNUHCM 2009 46
47. Phân loại sưu liệu qSưu liệu người dùng :Mô tả chức năng của hệ thống mà không tham chiếu đến những chức năng được thực thi như thế nào qSưu liệu hệ thống: bao gồm tài liệu mà mô tả tất cả các mặt của hệ thống bao gồm phân tích, đặc tả, thiết kế, thực thi, kiểm thử, bảo mật, triệu chứng lỗi và khắc phục. UIT-VNUHCM 2009 47
48. Sưu liệu người dùng qSystem overview qInstallation guide qBeginner's guide / tutorial qReference guide qEnhancement booklet qQuick reference card qSystem administration UIT-VNUHCM 2009 48
49. Sưu liệu hệ thống q Các nhân tố cơ bản của hệ thống q Phân tích đặc tả yêu cầu q Đặc tả /Thiết kế : o (i) Những yêu cầu hệ thống được thực thi thế nào o (ii) Hệ thống phân rà thành những đơn vị chương trình tương tác thế nào o (iii) Chức năng của mỗi đơn vị chương trình q Thực thi : o (i) Thiết kế chi tiết được diễn giải thế nào trong ngôn ngữa lập trình hình thức o (ii) program actions in the form of intraprogram comments q System test plan: Cung cấp mô tả đơn vị chương trình được kiểm thử cá nhân và toàn bộ hệ thống được kiểm thử sau khi tích hợp q Acceptance test plan: Mô tả kiểm thử mà hệ thống phải thông qua trước khi người dùng chấp nhận nó q Tự điển dữ liệu UIT-VNUHCM 2009 49
50. Cách phân loại khác qPhương pháp luận phát triển : qPhân loại khách hàng : qVersion of the system: UIT-VNUHCM 2009 50
51. Vai trò của sưu liệu qTiện nghi nắm bắt chương trình : qThao tác hướng dẫn người dùng: o Cung cấp khởi động và mô tả chính xác hệ thống là gì o Cung cấp thông tin cho phép người dùng cài đặt hệ thống o Cung cấp thông tin kỹ thuật và làm thế nào để quản lý sai sót. qBổ sung hệ thống : qExercise 11.5 Liệt kê loại chính của tài liệu hệ thống và giải thích mỗi loại có thuận lợi việc bảo trì. UIT-VNUHCM 2009 51
52. Tính hiệu quả tài liệu qua những mô tả hệ thống nên được làm bởi: qVăn phong viết : qGắn kết chuẩn tài liệu : qChuẩn và đánh giá chất lượng: qKỹ thuật sưu liệu : qCông cụ hỗ trợ sưu liệu: Công cụ hỗ trợ giúp phân loại và cập nhật sưu liệu. UIT-VNUHCM 2009 52
53. Configuration Management & CMM , CMMI qCapability Maturity Model (CMM) dùng để đo mức độ trưởng thành của tiến trình phát triển phần mềm. qCapability Maturity Model Integration được phát triển dành cho các tổ chức muốn theo đuổi việc cải tiến tiến trình ở cấp độ tổng thể. UIT-VNUHCM 2009 53
54. 5 mức độ trưởng thành Optimising (5) Continuously improving process Managed (4) Predictable process Defined (3) Standard, consistent process Repeatable (2) Disciplined process Initial (1) qCapability Maturity Model (CMM) dùng để đo mức độ trưởng thành của tiến trình phát triển phần mềm. UIT-VNUHCM 2009 54
55. •Process change management •Technology change management •Defect prevention 5 •Software quality management •Quantitative process management 4 •Peer reviews •Training program •Intergroup coordination •Organisation process definition •Software product engineering •Organisation process focus •Integrated software management 3 •Software project tracking and oversight •Software configuration •Software project planning management •Requirements management •Software quality assurance 2 •Software subcontract management Initial 1 UIT-VNUHCM 2009 55
56. qConfiguration Management Goal o Goal 1: Software configuration management activities are planned. o Goal 2: Selected software work products are identified, controlled, and made available. o Goal 3: Changes to identified software work products are controlled. o Goal 4: Affected groups and individuals are informed of the status and content of software baselines. UIT-VNUHCM 2009 56
57. q CMMI Process Areas o Process Management ü Organizational Process Focus ü Organizational Process Definition ü Organizational Training ü Organizational Process Performance ü Organizational Innovation and Deployment o Project Management ü Project Planning ü Project Monitoring and Control ü Supplier Agreement Management ü Integrated Product and Process Development (IPPD) Management ü Risk Management ü Integrated Teaming ü Quantitative Project Management o Engineering ü Requirements Management ü Requirements Development ü Technical Solution ü Product Integration ü Verification ü Validation o Support ü Configuration Management ü Process and Product Quality Assurance ü Measurement and Analysis ü Decision Analysis and Resolution ü Organizational Environment for Integration ü Causal Analysis and Resolution UIT-VNUHCM 2009 57
58. qThe goals for configuration management o Goal 1 Establish Baselines. Baselines of identified work products are established and maintained. o Goal 2 Track and Control Changes. Changes to the work products under configuration management are tracked and controlled. o Goal 3 Establish Integrity. Integrity of baselines is established and maintained. UIT-VNUHCM 2009 58
59. qExercise 11.6 Nghiên cứu Source Code Control System (SCCS) có sẵn trên hệ thống của bạn và giải thích bạn sử dụng chúng như phần của dự án phần mềm lớn. qExercise 11.7 Tạo danh sách toàn diện công cụ hỗ trợ quản lý cấu hình có sẵn trên hệ thống. Viết ghi chú chính xác tóm tắt cho mỗi loại. Dùng trợ giúp trực tuyến hay hệ thống thủ công là điểm bắt đầu tốt. qExercise 11.8 Giải thích giới hạn của SCCS khi xem xét dùng song song trong môi trường phát triển/bảo trì và giải thích giới hạn ở mỗi công cụ hỗ trợ. UIT-VNUHCM 2009 59
60. Yêu cầu thực hiện tuần tiếp theo q Seminar các nhóm 1-5 q Seminar các nhóm 6-10 q Seminar các nhóm 11-15 q Seminar các nhóm 15-20. q Các nhóm hoàn tất chương trình demo, code, document upload và thực hiện như sau: q Download ctr : chạy thử kiểm tra đánh giá.Tiêu chí:? q Tuần 12 thực hiện đấu giá các nhóm 1-5(1), 5-10 (2), 11- 15(3), 15-20 (4). Mỗi cụm nhóm chọn ra 1 nhóm có điểm cao nhất (+1 point) sẽ thực hiện đấu giá tuần 14. 1 vé vớt để vào vòng trong q Tuần 13, thực hiện đấu giá các 5 nhóm cao nhất 1 nhóm nhất (+2), 1 nhóm nhì (+1), 1 nhóm 3,4 (0.5-0.25) UIT-VNUHCM 2009 60
61. Tài liệu tham khảo q Configuration Management Yellow Pages : tml q q CM Community : www.cmcrossroads.com q Configuration Management Principles and Practice, Anne Mette Jonassen Hass, Addison Wesley. q Configuration Management with CVS and Open Source Tools, Derek Clifford UIT-VNUHCM 2009 61