Công nghệ phần mềm - Chương 4; Quy trình xác định yêu cầu

Nội dung text: Công nghệ phần mềm - Chương 4; Quy trình xác định yêu cầu

1. Chươ ng 4 Quy trình xác định yêu cầu
2. Giới thiệu Mục tiêu của quy trình xác định yêu cầu là đưa ra các tài liệu yêu cầu của hệ thống. Quy trình xác định yêu cầu biến đổi phụ thuộc vào miền ứng dụng, con người và tổ chức xây dựng yêu cầu. Tuy nhiên, những quy trình này vẫn có chung một số hoạt động sau: phát hiện yêu cầu, phân tích yêu cầu, đánh giá yêu cầu và quản lý yêu cầu.
3. Giới thiệu Trong thực tế, các yêu cầu luôn luôn thay đổi, thậm chí ngay cả khi đang xây dựng hệ thống. Vì vậy, người ta thường sử dụng mô hình xoắn ốc để xác định các yêu cầu. Mô hình này cho phép việc xác định yêu cầu và cài đặt hệ thống được thực hiện cùng lúc.
4. Giới thiệu (tt)
5. Phân tích khả thi Đối với tất cả các hệ thống mới, quy trình xác định yêu cầu thường bắt đầu bằng việc phân tích khả thi. Thông tin đầu vào để phân tích khả thi là các yêu cầu nghiệp vụ, mô tả sơ bộ về hệ thống, cách thức hệ thống hỗ trợ các yêu cầu nghiệp vụ. Kết quả của việc phân tích khả thi là một báo cáo để quyết định có nên xây dựng hệ thống đề xuất hay không.
6. Phân tích khả thi Phân tích khả thi thường tập trung vào: - Xác định hệ thống có đóng góp vào mục tiêu của tổ chức hay không - Kiểm tra xem hệ thống có thể được xây dựng bằng cách sử dụng công nghệ hiện tại và ngân sách cho phép. - Kiểm tra xem liệu hệ thống có được tích hợp với các hệ thống khác đang sử dụng hay không.
7. Phân tích khả thi (tt) ￿ Thực hiện phân tích khả thi dựa trên việc đánh giá thông tin, lựa chọn thông tin và viết báo cáo. Những câu hỏi thường được đặt ra để phân tích khả thi: - Nếu hệ thống không được cài đặt thì sao? - Vấn đề xử lý hiện tại như thế nào? - Hệ thống đề xuất giúp đỡ được gì? - Vấn đề về tích hợp là gì? - Công nghệ mới cần dùng là gì? - Cần có những kỹ năng gì? - Những lợi ích mà hệ thống mang lại?
8. Phát hiện và phân tích yêu cầu Trong pha phát hiện và phân tích yêu cầu, nhân viên kỹ thuật và khách hàng cùng hợp tác để xác định miền ứng dụng, các dịch vụ mà hệ thống cung cấp, hiệu năng của hệ thống, các ràng buộc vận hành của hệ thống Stakeholder là những người tham dự vào dự án xây dựng hệ thống: người sử dụng cuối, người quản lý, kỹ sư, chuyên gia lĩnh vực,
9. Phát hiện và phân tích yêu cầu - Ví dụ, trong hệ thống ATM gồm các Stakeholder sau: khách hàng của ngân hàng, đại diện của các ngân hàng khác, người quản lý ngân hàng, nhân viên ngân hàng, quản trị CSDL, quản lý bảo mật, phòng marketing, kỹ sư bảo trì phần cứng và phần mềm, người điều hành ngân hàng.
10. Phát hiện và phân tích (tt) Tuy nhiên, việc phát hiện và tìm hiểu yêu cầu của stakeholder, chúng ta thường gặp khó khăn vì những nguyên nhân sau: - Stakeholder không biết những gì mà họ thật sự mong muốn. - Stakeholder mô tả các yêu cầu theo thuật ngữ của họ. - Những stakeholder khác nhau có thể có các yêu cầu xung đột nhau
11. Phát hiện và phân tích (tt) - Những yếu tố tổ chức và quyền lực có thể ảnh hưởng tới các yêu cầu hệ thống. - Các yêu cầu có thể thay đổi trong suốt quá trình phân tích. Những stakeholder mới có thể xuất hiện và môi trường nghiệp vụ có thể thay đổi.
12. Phát hiện và phân tích (tt) Trong quy trình này bao gồm các hoạt động sau: - Phát hiện yêu cầu: Phát hiện yêu cầu là quy trình thu thập những thông tin về hệ thống được đề xuất và hệ thống đang tồn tại để xác định các yêu cầu hệ thống và yêu cầu của người sử dụng. - Phân loại và sắp xếp yêu cầu: nhóm các yêu cầu có liên quan lẫn nhau và tổ chức chúng thành những nhóm gắn kết với nhau.
13. Phát hiện và phân tích (tt) - Sắp thứ tự ưu tiên và điều chỉnh các yêu cầu xung đột: khi có nhiều stakeholder thì các yêu cầu của họ càng có nhiều xung đột. Hoạt động này nhằm đánh thứ tự ưu tiên của các yêu cầu, phát hiện và giải quyết xung đột giữa các yêu cầu. - Tư liệu hóa yêu cầu: yêu cầu được ghi chép lại để trở thành tài liệu tham khảo cho các bước tiếp theo.
14. Phát hiện và phân tích (tt) - Các cách để phát hiện yêu cầu: -Khung nhìn -Phỏng vấn -Kịch bản -Case
15. Phát hiện và phân tích (tt) Khung nhìn (Viewpoint) - Khung nhìn là cách xây dựng yêu cầu để trình bày với từng stakeholder khác nhau. Ta có thể phân loại Stakeholder theo nhiều khung nhìn khác nhau. - Phân tích dựa trên khung nhìn cho phép phát hiện nhiều khía cạnh khác nhau của một vấn đề và giúp phát hiện ra sự xung đột giữa các yêu cầu.
16. Phát hiện và phân tích (tt) - Khung nhìn được chia thành 3 loại chính và mỗi loại sẽ cung cấp các yêu cầu khác nhau. Khung nhìn tương tác: là những người hoặc hệ thống khác tương tác với hệ thống. Trong hệ thống ATM, khách hàng và CSDL tài khoản là những khung nhìn tương tác ￿ Khung nhìn gián tiếp: là những stakeholder không sử dụng hệ thống trực tiếp nhưng có ảnh hưởng tới hệ thống. Trong hệ thống ATM, nhân viên quản lý và bảo mật là những khung nhìn gián tiếp.
17. Phát hiện và phân tích (tt) ￿ Khung nhìn miền ứng dụng: là những đặc điểm và ràng buộc của miền ứng dụng, có ảnh hưởng tới các yêu cầu. Trong hệ thống ATM, các chuẩn để giao tiếp giữa nhiều ngân hàng là một ví dụ.
18. Phát hiện và phân tích (tt) Phỏng vấn - Phỏng vấn hình thức hoặc phi hình thức là một trong những phần quan trọng nhất của quy trình xác định yêu cầu. Trong quá trình phỏng vấn, những người xác định yêu cầu sẽ đặt ra các câu hỏi cho stakeholder về hệ thống hiện tại họ đang sử dụng và hệ thống sẽ được xây dựng. Và các yêu cầu sẽ được lấy ra từ những câu trả lời của stakeholder. - Phỏng vấn được chia thành hai loại:
19. Phát hiện và phân tích (tt) ￿ Phỏng vấn đóng: tập các câu hỏi đã được định nghĩa trước và có nhiều đáp án để stakeholder lựa chọn trả lời. ￿ Phỏng vấn mở: tất cả các vấn đề không được xác định trước và stakeholder phải tự giải thích và phát biểu theo quan điểm của mình. - Trong thực tế, chúng ta thường trộn lẫn phỏng vấn đóng và mở.
20. Phát hiện và phân tích (tt) - Một phỏng vấn tốt có nghĩa là sẽ thu thập được tất cả các hiểu biết về công việc phải làm của stakehoder và cách họ tương tác với hệ thống như thế nào. - Tuy nhiên, khi phỏng vấn những vấn đề có liên quan tới miền ứng dụng hoặc nghiệp vụ của người sử dụng, chúng ta thường gặp khó khăn vì khó hiểu những từ ngữ chuyên ngành
21. Phát hiện và phân tích (tt) - Để phỏng vấn thành công, người phỏng vấn nên: ￿Cởi mở, sẵn sàng lắng nghe stakeholder và không nên có những ý tưởng đã được định hình sẵn về các yêu cầu. ￿Đưa ra những câu hỏi gợi mở, không nên hỏi những câu như “Anh muốn gì?”
22. Phát hiện và phân tích (tt) Kịch bản - Chúng ta thường hiểu một vấn đề thông qua các ví dụ thực tế dễ dàng hơn là thông qua những mô tả trừu tượng về nó. - Do đó, chúng ta có thể sử dụng kịch bản để phát hiện ra các yêu cầu hệ thống. Kịch bản là những ví dụ thực tế về cách sử dụng hệ thống. Chúng bao gồm:
23. Phát hiện và phân tích (tt) ￿Mô tả trạng thái khởi động ￿ ￿Mô tả luồng sự kiện thông thường ￿Mô tả những gì có thể đi tới lỗi ￿Thông tin về các hành động đồng thời khác ￿Mô tả trạng thái khi kịch bản hoàn thành
24. Phát hiện và phân tích (tt) Ca sử dụng - Ca sử dụng là kịch bản được xây dựng dựa trên kỹ thuật của UML để xác định các tác nhân trong một tương tác và mô tả chính tương tác đó. Một tập hợp các ca sử dụng sẽ mô tả tất cả các tương tác có thể trong hệ thống. - Ngoài ra, chúng ta có thể sử dụng biểu đồ trình tự để bổ sung các thông tin chi tiết cho ca sử dụng bằng cách biểu diễn trình tự các sự kiện được xử lý trong hệ thống.
25. Đánh giá yêu cầu Đánh giá yêu cầu có liên quan đến việc giải thích các yêu cầu đã được định nghĩa trong hệ thống. Vì chi phí cho việc giải quyết các lỗi có liên quan tới yêu cầu sẽ rất cao cho nên việc đánh giá yêu cầu là vô cùng quan trọng. Trong quá trình đánh giá yêu cầu, chúng ta phải kiểm tra các yêu cầu ở những khía cạnh sau:
26. Đánh giá yêu cầu -Hợp lệ: Hệ thống có cung cấp các chức năng hỗ trợ tốt nhất cho các yêu cầu của người sử dụng hay không? - Nhất quán: có yêu cầu nào xung đột nhau hay không? - Hoàn thiện: tất cả các yêu cầu của khách hàng đã được xác định đầy đủ chưa? - Hiện thực: các yêu cầu có thể được cài đặt với một ngân sách và công nghệ cho trước? - Xác thực: các yêu cầu có thể được kiểm tra hay không?
27. Đánh giá yêu cầu (tt1) Các kỹ thuật đánh giá yêu cầu sau đây có thể được sử dụng đơn lẻ hoặc hỗn hợp: - Xem xét lại các yêu cầu: phân tích các yêu cầu một cách hệ thống. - Mẫu thử: Sử dụng các mô hình hệ thống để kiểm tra các yêu cầu - Tạo ra các trường hợp kiểm thử
28. Lập kế hoạch quản lý yêu cầu Quản lý yêu cầu là quy trình quản lý sự thay đổi của các yêu cầu trong quá trình phát hiện yêu cầu và phát triển hệ thống. Các yêu cầu thường không đầy đủ và không đồng nhất. Đó là do một số nguyên nhân sau:
29. Lập kế hoạch quản lý yêu cầu - Những yêu cầu mới xuất hiện trong quy trình khi các yêu cầu nghiệp vụ thay đổi và khi chúng ta có hiểu biết sâu hơn về hệ thống sẽ xây dựng. - Ở các khung nhìn khác nhau sẽ có các yêu cầu khác nhau và do đó thường xuất hiện các mâu thuẫn. - Thứ tự ưu tiên từ các khung nhìn khác nhau cũng thay đổi trong suốt quá trình phát triển hệ thống.
30. Lập kế hoạch quản lý (tt) Các yêu cầu lâu dài là những yêu cầu ổn định kế thừa từ những hành động chính của khách hàng. Và nó có thể kế thừa từ nhiều mô hình miền ứng dụng khác. Các yêu cầu thay đổi là những yêu cầu dễ bị thay đổi trong quá trình xây dựng hoặc khi hệ thống được đưa vào sử dụng.
31. Lập kế hoạch quản lý (tt) Quy trình lập kế hoạch quản lý yêu cầu: - Xác định yêu cầu. - Quản lý thay đổi: xác định các hoạt động tiếp theo khi yêu cầu thay đổi. - Các chính sách tìm vết: lượng thông tin về mối quan hệ giữa các yêu cầu cần phải được lưu giữ. Thông thường, nó đề cập tới quan hệ giữa tài nguyên và bản thiết kế hệ thống.
32. Lập kế hoạch quản lý (tt) Tìm vết nguồn: là những liên kết từ các yêu cầu tới stakeholder đưa ra những yêu cầu đó. Tìm vết yêu cầu: là mối liên hệ giữa các yêu cầu độc lập nhau. Tìm vết thiết kế: là những liên kết từ yêu cầu cho tới thiết kế.
33. Lập kế hoạch quản lý (tt) Quy trình lập kế hoạch quản lý yêu cầu (tt1): - Hỗ trợ CASE tool: sử dụng các công cụ để hỗ trợ quản lý yêu cầu thay đổi. CASE tool thường hỗ trợ những chức năng như: ￿ Lưu trữ yêu cầu: các yêu cầu được quản lý một cách bảo mật và được lưu trong kho dữ liệu. ￿ Quản lý thay đổi: quy trình quản lý thay đổi là quy trình luồng công việc mà các trạng thái có thể được định nghĩa và luồng thông tin giữa các trạng thái là tự động. ￿ ￿ Quản lý vết tự động tìm kiếm mối liên kết giữa các yêu cầu.
34. Lập kế hoạch quản lý (tt) Nên áp dụng tất cả các khả năng thay đổi có thể cho tất cả các yêu cầu. Các pha chính của hoạt động này bao gồm: - Phân tích vấn đề và đặc tả thay đổi: thảo luận về các vấn đề yêu cầu và những thay đổi có thể xảy ra. - Phân tích thay đổi và chi phí: đánh giá ảnh hưởng của sự thay đổi trên các yêu cầu khác. - Cài đặt thay đổi: Điều chỉnh tài liệu của các yêu cầu và những tài liệu khác để phản ánh sự thay đổi đó.