Bài giảng Thu nhận yêu cầu - Chương 8: Cải tiến yêu cầu phần mềm - Trần Thị Kim Chi

Chương 8:IMPROVING REQUIREMENT PROCESSESCẢI TIẾN YÊU CẦU PHẦN MỀMBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI1Cải tiến qui trình phần mềmCải tiến quy trình phần mềm có 3 mục tiêu chính:Giảm chi phí xây dựng và bảo trì phần mềmSửa chữa các vấn đề mà bạn đã gặp trong các dự án trước và hiện tại.Tiên liệu và ngăn ngừa các vấn đề mà bạn có thể sẽ gặp trong các dự án tương lai.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI2Cải tiến qui trình phần mềmCác cách để hoàn thành mục tiêu chính:Chỉnh sửa ngay các lỗi phát sinh do thiếu quy chuẩn trong dự án cũ và hiện hành.Dự đoán và tránh các vấn đề đang gặp phải trong các dự án tương laiThừa nhận các kinh nghiệm hiệu quả hơn các thực tiễn đang được áp dụngBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI3Thực tế quản lý dự ánCác công ty phần mềm thành công cũng sẽ phải đối mặt với các khó khăn to lớn khi thực hiện các dự án lớn hơn, khách hàng đa dạng hơn, khi lịch biểu được siết chặt hơn, hoặc khi làm việc trong một miền nghiệp vụ mới mẻ hơn... Vì vậy, bạn cũng nên biết những cách tiếp cận làm yêu cầu mới có giá trị đối với công việc của bạn. Ví dụ: các phương thức làm việc dành cho đội có 5 thành viên không thể mở rộng áp dụng cho 1 đội có 125 thành viên rải rác trong các chi nhánh cách xa nhau được.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI4Mối liên hệ giữa yêu cầu và các quy trình dự án khácBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI5Quy trình Lập kế hoạch dự án (Project planning process)Yêu cầu phải là cơsở của các quy trình lập kế hoạch dự án. Các ước lượng tài nguyên và lịch biểu cần dựa trên sự hiểu biết về cái gì sẽ được xây dựng và chuyển giao cho khách hàng. Thông thường, lập kế hoạch dự án nghĩa là tính toán sao cho tất cả các tính năng mong muốn sẽ được thực hiện trong một giới hạn ngân sách và thời gian nhất định. Các quy trình lập kế hoạch có thể dẫn tới việc thu hẹp phạm vi dự án hoặc lựa chọn một cách tiếp cận từng bước một - phát hành dần từng phiên bản của sản phẩm, mỗi phiên bản chỉ bao gồm một số tính năng.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI6Quy trình Giám sát và kiểm soát dự án (Project tracking and control Process))Giám sát (monitor) trạng thái của mỗi yêu cầu được coi là một phần của việc giám sát dự án (project tracking) sao cho các nhà quản lý dự án có thể biết liệu công việc có được tiến hành như mong muốn hay không. Nếu không, cấp quản lý có thể đề nghị thu hẹp phạm vi thông qua các quy trình kiểm soát thay đổi.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI7Quy trình Kiểm soát thay đổi (Change control Process)Quy trình kiểm soát thay đổi đảm bảo rằng: Hiểu rõ ảnh hưởng của một đề xuất thay đổi (proposed change) Tất cả những ai có liên quan đến thay đổi thì đều phải nhận biết được thay đổi này.Những người có thẩm quyền ra quyết định chính thức khi chấp nhận thay đổi.Tài nguyên và các thỏa thuận được điều chỉnh phù hợp.Các tài liệu yêu cầu được cất giữ.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI8Quy trình Kiểm thử hệ thống (System testing process)Các yêu cầu người dùng (user requirements) và các yêu cầu chức năng (functional requirements) là đầu vào chính để kiểm thử hệ thống. Nếu hành vi được mong đợi của phần mềm trong các điều kiện khác nhau không được đặc tả thì người kiểm thử rất khó biết hành vi nào của hệ thống là đúng, hành vi nào là sai. Ngược lại, kiểm thử hệ thống là một phương tiện để xác nhận rằng tất cả các chức năng đã được lập kế hoạch thì đều được thực hiện và các công việc (tasks) mà người dùng mong muốn đã hoạt động một cách đúng đắn.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI9Quy trình Làm tài liệu người dùng (User documentation process)Các yêu cầu là đầu vào chính của quy trình làm tài liệu, vì vậy chất lượng của yêu cầu sẽ quyết định chất lượng của tài liệu.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI10Quy trình Thi công hệ thống (Construction process)Các yêu cầu là cơsở để thiết kế và thi công phần mềm. Yêu cầu chức năng (functional requirements) dẫn tới các thiết kế components, chúng phục vụ như là các đặc tả cho các mã sẽ được viết. Thực hiện soát xét thiết kế để đảm bảo bản thiết kế đã chứa tất cả các yêu cầu. Kiểm thử đơn vị (unit testing) mã nguồn có thể xác định liệu nó có đáp ứng đặc tả thiết kế và yêu cầu tương ứng hay không.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI11Yêu cầu và các nhóm StakeholderBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI12Yêu cầu và các nhóm StakeholderNhóm marketing (Marketing or Product Management): đặc tả yêu cầu kinh doanh hoặc yêu cầu của thị trường cho nhóm phát triển; đề xuất các thay đổi đối với nhóm phát triển.Nhóm hỗ trợ kỹ thuật (Technical Support): hỗ trợ người dùng của khách hàng, cung cấp đầu vào cho nhóm phát triển từ việc phân tích các báo cáo lỗi của khách hàng, đề nghị các thay đổi nâng cấp phần mềm.Người phụ trách dùng (Users): mô tả các yêu cầu người dùng và thuộc tính chất lượng của các yêu cầu đó, soát xét các yêu cầu.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI13Yêu cầu và các nhóm StakeholderNhóm kỹ thuật phần cứng (Hardware Engineering): đặc tả các giao diện phần cứng mà phần mềm phải làm việc cùng.Nhóm kỹ thuật hệ thống (Systems Engineering): phân bổ các yêu cầu hệ thống cho phần mềm, đề xuất thay đổi.Nhóm mua sắm (Procuers): đặc tả các nhu cầu kinh doanh, chức năng và hiệu suất; đề xuất thay đổi.Nhóm pháp lý (Legal Department): xử lý các vấn đề pháp luật liên quan đến license của các tools và components.Cấp quản lý (Management): đề ra các ràng buộc của dự án, ràng buộc về tài nguyên và cam kết khác cho nhóm phát triển.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI14CƠ BẢN VỀ CẢI TIẾN QUY TRÌNH PHẦN MỀM(FUNDAMENTALS OF SOFTWARE PROCESS IMPROVEMENT)Cải tiến quy trình cần được thực hiện theo kiểu tiến hoá, liên tục và có chu trình (Process improvement should be evolutionary, continuous, and cyclical).Con người và các tổ chức chỉ thay đổi khi họ bị thúc ép phải thay đổi (People and organizations change only when they have an intence to do so).Các thay đổi quy trình cần phải được hướng đích (Process changes should be goal oriented).Xử lý các hoạt động cải tiến quy trình của bạn như là các tiểu dự án (Treat improvement activities as miniprojects).Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI15CHU TRÌNH CẢI TIẾN QUY TRÌNH (THE PROCESS IMPROVEMENT CYCLE)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI16Assess Current Practices = Đánh giá các practices hiện tạiPlan Improvement Actions = Lập kế hoạch cho các hoạt động cải tiếnCreate, Pilot and Implement New Processes = Thiết lập, thử nghiệm, cải tiếncác quy trình mớiEvaluate Results = Đánh giá kết quảCHU TRÌNH CẢI TIẾN QUY TRÌNH (THE PROCESS IMPROVEMENT CYCLE)Cải tiến quy trình cần được thực hiện theo kiểu tiến hoá, liên tục và có chu trình (Process improvement should be evolutionary, continuous, and cyclical).Con người và các tổ chức chỉ thay đổi khi họ bị thúc ép phải thay đổi (People and organizations change only when they have an intence to do so).Các thay đổi quy trình cần phải được hướng đích (Process changes should be goal oriented).Xử lý các hoạt động cải tiến quy trình của bạn nhưlà các tiểu dự án (Treat improvement activities as miniprojects).Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI17CÁC HOẠT ĐỘNG CỦA QUI TRÌNH CẢI TIẾNĐánh giá các practices hiện tại (assess current practices)Đánh giá các practices hiện tại đang được sử dụng trong tổ chức để xác định thế mạnh và hạn chế của nó.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI18CÁC HOẠT ĐỘNG CỦA QUI TRÌNH CẢI TIẾNLập kế hoạch cho các hoạt động cải tiến (plan improvement actions)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI19Ngày hoàn thành ước tính của dự án (Estimated completion date for all activites):CÁC HOẠT ĐỘNG CỦA QUI TRÌNH CẢI TIẾNBài giảng môn Thu nhận yêu cầu - BM HTTT - HUI20CÁC HOẠT ĐỘNG CỦA QUI TRÌNH CẢI TIẾNThiết lập, thử nghiệm, cải tiến các quy trình mới (create, pilot, and implement new processes)Đánh giá kết quả (evaluate results)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI21TÀI SẢN QUY TRÌNH PHÁT TRIỂN YÊU CẦU (REQUIREMENTS DEVELOPMENT PROCESS ASSETS)Template tầm nhìn và phạm vi của dự án (Project vision and Scope Template)Thủ tục phát triển yêu cầu (Requirements Development Procedure)Thủ tục phân bổ yêu cầu (Requirements Allocation Procedure)Template tình huống sử dụng (Use case template)Template đặc tả yêu cầu phần mềm (SRS template)Thủ tục xếp thứ tự ưu tiên các yêu cầu (Requirements Prioritization Procedure)Các checklists thanh tra SRS và use-case (SRS and use -case Inspection Checklists)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI22TÀI SẢN QUY TRÌNH QUẢN LÝ YÊU CẦU (REQUIREMENTS MANAGEMENT PROCESS ASSETS)Thủ tục kiểm soát thay đổi (Change control procedure)Thủ tục ban kiểm soát thay đổi (Change Control Board Procedure)Checklists và templates phân tích ảnh hưởng thay đổi yêu cầu (Requirements Change Impact Analysis Checklist and Template)Thủ tục giám sát tình trạng yêu cầu (Requirements Status Tracking Procedure)Template ma trận lần vết yêu cầu (Requirements Traceability Matrix Template)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI23LỘ TRÌNH CẢI TIẾN QUY TRÌNH YÊU CẦU (REQUIREMENTS PROCESS IMPROVEMENT ROADMAP)Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI24AssigmentHoàn thành các Bảng tự đánh giá Requirements Practices hiện tại trong Phụ lục. Xác định 3 cơhội cải tiến requirements practices cao nhất của bạn căn cứ trên các hạn chế của quy trình hiện tại.Xác định trong số các tài sản quy trình công nghệ yêu cầu ở Hình 4-6, tài sản quy trình nào chưa thực sự hữu ích trong tổ chức nhưng bạn lại nghĩ nó vẫn được sử dụng tốt.Dựa trên 2 bước trên, xây dựng một lộ trình cải tiến quy trình yêu cầu như template ở Hình 4-7. Giao cho mỗi ai đó thực hiện một mốc trên lộ trình.Yêu cầu mỗi người viết kế hoạch hành động để đạt được mốc đó, sử dụng template về kế hoạch hành động trong Hình 4-4. Giám sát tiến độ thực hiện kế hoạch cải tiến.Bài giảng môn Thu nhận yêu cầu - BM HTTT - HUI25