Mục lục bài họcĐang ở d01-b1
Systems in Organisations and Requirements Analysis
Why systems are planned, not just built. A new information system is introduced into an organisation that already works in some way, so the decisive constraints are organisational rather than technical. The first question is always the context: what problem the system must solve, who uses it, what already exists. A legacy system is an older system still in use because it works, holds critical data and would be expensive or risky to replace; the reason organisations keep them is rarely ignorance, and an answer that treats replacement as obviously correct will lose marks.
Requirements analysis. Four standard techniques, each with a distinct weakness. Interviews give depth and allow follow-up questions, but they are slow, and what people say they do often differs from what they do. Questionnaires reach many users cheaply and give quantifiable answers, but they cannot probe and response rates are low. Direct observation reveals the actual workflow including the informal workarounds nobody mentions, but it is time-consuming and people behave differently when watched. Examining current documentation shows the official process and the real data formats, but documents are often out of date. A good analysis triangulates: it uses at least two techniques so that the gaps in one are covered by another.
Modelling the system. Analysts model the intended system before building it. A data flow diagram shows what the system does — external entities, processes, data stores and named flows — without saying how it is coded. Structure charts show how a program decomposes into modules. UML class diagrams show the data and operations of each class and the relationships between them. Prototyping is the most effective single technique for reducing risk, because it puts something concrete in front of the user early, when a misunderstanding is still cheap to fix.
Why cost rises with time. The cost of correcting a fault rises roughly exponentially through the life cycle. A coding error costs hours; a design error costs weeks because several modules must be rewritten; a misunderstood requirement costs the project, because the software runs perfectly and is useless. This single fact is what justifies spending heavily on analysis and prototyping, and it is the point an examiner is looking for.
Vì sao hệ thống phải được hoạch định chứ không chỉ được xây. Một hệ thống thông tin mới luôn được đưa vào một tổ chức vốn đã đang vận hành theo một cách nào đó, nên các ràng buộc quyết định thường mang tính tổ chức chứ không mang tính kỹ thuật. Câu hỏi đầu tiên luôn là bối cảnh: hệ thống phải giải quyết vấn đề gì, ai sẽ dùng, và cái gì đã tồn tại sẵn. Hệ thống kế thừa là hệ thống cũ vẫn đang được dùng vì nó chạy được, nó chứa dữ liệu trọng yếu, và việc thay thế vừa tốn kém vừa rủi ro; lý do các tổ chức giữ lại chúng hiếm khi là do thiếu hiểu biết, nên bài coi việc thay thế là hiển nhiên đúng sẽ mất điểm.
Phân tích yêu cầu. Bốn kỹ thuật chuẩn, mỗi kỹ thuật có một điểm yếu riêng. Phỏng vấn cho chiều sâu và cho phép hỏi tiếp, nhưng chậm, và điều người ta NÓI mình làm thường khác điều họ thực sự làm. Bảng hỏi tiếp cận được nhiều người với chi phí thấp và cho câu trả lời định lượng được, nhưng không thể hỏi sâu và tỷ lệ phản hồi thường thấp. Quan sát trực tiếp cho thấy quy trình thực tế, kể cả những cách làm tắt không chính thức mà không ai nhắc tới, nhưng tốn thời gian và người bị quan sát có xu hướng làm khác thường ngày. Nghiên cứu tài liệu hiện có cho thấy quy trình chính thức cùng định dạng dữ liệu thật, nhưng tài liệu thường đã lỗi thời. Một phân tích tốt luôn đối chiếu chéo: dùng ít nhất hai kỹ thuật để điểm yếu của cái này được cái kia bù lại.
Mô hình hoá hệ thống. Người phân tích mô hình hoá hệ thống dự kiến trước khi xây. Sơ đồ luồng dữ liệu cho thấy hệ thống LÀM GÌ — thực thể ngoài, quá trình, kho dữ liệu và các luồng có tên — mà không nói nó được lập trình ra sao. Sơ đồ cấu trúc cho thấy chương trình được phân rã thành các mô-đun như thế nào. Sơ đồ lớp UML cho thấy dữ liệu và thao tác của từng lớp cùng quan hệ giữa chúng. Làm nguyên mẫu là kỹ thuật đơn lẻ hiệu quả nhất để giảm rủi ro, vì nó đặt một thứ cụ thể trước mặt người dùng từ sớm, khi một hiểu lầm còn rẻ để sửa.
Vì sao chi phí tăng theo thời gian. Chi phí sửa một lỗi tăng gần như theo cấp số nhân qua các giai đoạn của vòng đời. Lỗi lập trình tốn vài giờ; lỗi thiết kế tốn vài tuần vì phải viết lại nhiều mô-đun; còn một yêu cầu bị hiểu sai thì tốn cả dự án, vì phần mềm chạy hoàn hảo mà vô dụng. Chính sự thật này biện minh cho việc đầu tư mạnh vào phân tích và làm nguyên mẫu, và đó là ý mà giám khảo tìm.
Một bệnh viện muốn thay hệ thống ghi bệnh án giấy bằng hệ thống điện tử. Người dùng gồm 400 điều dưỡng, 90 bác sĩ và 20 nhân viên tiếp nhận. Hãy chọn tổ hợp kỹ thuật thu thập yêu cầu và biện minh cho lựa chọn.
Nguyên tắc chọn: ghép kỹ thuật theo QUY MÔ nhóm người dùng và theo LOẠI thông tin cần lấy.
Bảng hỏi cho 400 điều dưỡng. Nhóm này quá đông để phỏng vấn từng người, và điều cần biết ở họ chủ yếu là định lượng: mỗi ca ghi bao nhiêu loại biểu mẫu, mất bao nhiêu phút, khâu nào bị coi là mất thời gian nhất. Bảng hỏi cho dữ liệu so sánh được giữa các khoa và giữa các ca trực. Phải nêu điểm yếu: tỷ lệ phản hồi thường thấp và không thể hỏi tiếp, nên cần kết hợp với kỹ thuật khác.
Phỏng vấn sâu với một mẫu bác sĩ và trưởng khoa. Ở đây cái cần lấy là các quy tắc nghiệp vụ phức tạp và các trường hợp ngoại lệ: bệnh án chuyển khoa xử lý ra sao, ai được phép sửa một chẩn đoán đã ghi, quy trình khi bệnh nhân cấp cứu chưa có hồ sơ. Những quy tắc này không thể hỏi bằng bảng hỏi vì chính người trả lời cũng không biết trước câu hỏi nào là quan trọng — chỉ khi hỏi tiếp mới lộ ra.
Quan sát trực tiếp tại quầy tiếp nhận và tại một khoa vào giờ cao điểm. Đây là kỹ thuật duy nhất phát hiện được những cách làm tắt không chính thức: mảnh giấy dán tạm, sổ tay riêng của điều dưỡng, quy ước viết tắt không có trong tài liệu nào. Nếu hệ thống mới không hỗ trợ được những nhu cầu thật đằng sau các cách làm tắt đó, nhân viên sẽ tạo ra cách làm tắt mới bên ngoài hệ thống, và dữ liệu sẽ không đầy đủ.
Nghiên cứu tài liệu hiện có. Bộ biểu mẫu giấy đang dùng cho biết chính xác các trường dữ liệu, kiểu dữ liệu, ràng buộc bắt buộc và các mã nội bộ. Đây là nguồn rẻ nhất để dựng mô hình dữ liệu ban đầu. Điểm yếu: biểu mẫu có thể đã lỗi thời so với thực hành hiện tại, nên phải kiểm chứng lại bằng quan sát.
Vì sao phải dùng ít nhất hai kỹ thuật. Mỗi kỹ thuật có một điểm mù có hệ thống. Bảng hỏi không thấy ngoại lệ; phỏng vấn thu được điều người ta nghĩ mình làm; quan sát bị nhiễu vì người bị quan sát làm khác thường ngày; tài liệu thì lỗi thời. Đối chiếu chéo giữa chúng chính là cách phát hiện mâu thuẫn, và mỗi mâu thuẫn phát hiện được ở giai đoạn này tiết kiệm rất nhiều so với việc phát hiện nó sau khi hệ thống đã chạy.
Một chuỗi bán lẻ triển khai hệ thống quản lý kho mới. Phần mềm vượt qua toàn bộ kiểm thử. Sáu tháng sau, số liệu tồn kho sai lệch nghiêm trọng và nhiều cửa hàng quay lại dùng bảng tính riêng. Giải thích và nêu cách đáng lẽ phải làm.
Chẩn đoán — vấn đề nằm ở khâu đưa vào sử dụng chứ không nằm ở phần mềm. Kiểm thử chứng minh hệ thống làm đúng điều nó được thiết kế để làm; nó không chứng minh rằng con người sẽ dùng nó, rằng dữ liệu cũ được chuyển sang đúng, hay rằng nó khớp với quy trình thực tế của cửa hàng.
Nguyên nhân 1 — chuyển đổi dữ liệu bị coi nhẹ. Dữ liệu từ hệ thống cũ hầu như luôn có vấn đề: định dạng khác, mã sản phẩm trùng hoặc thiếu, trường bỏ trống, ký tự đặc biệt, và các quy ước riêng của từng cửa hàng. Nếu chuyển sang mà không làm sạch và không đối soát, hệ thống mới khởi động với dữ liệu sai ngay từ ngày đầu, và mọi con số sau đó đều sai theo dù phần mềm hoàn toàn đúng.
Nguyên nhân 2 — chọn sai phương pháp chuyển đổi. Có bốn phương pháp và mỗi phương pháp có một hồ sơ rủi ro riêng. Chuyển thẳng tắt hệ thống cũ và bật hệ thống mới cùng lúc — rẻ và nhanh nhất nhưng không có đường lui nếu hỏng. Chạy song song vận hành cả hai một thời gian và đối chiếu kết quả — an toàn nhất và phát hiện được sai lệch dữ liệu, nhưng tốn gấp đôi công nhập liệu. Chuyển theo giai đoạn đưa từng phân hệ vào lần lượt. Chuyển thí điểm triển khai đủ mọi phân hệ nhưng chỉ ở vài cửa hàng trước. Với một chuỗi bán lẻ nhiều điểm bán, thí điểm là lựa chọn hợp lý nhất vì nó giới hạn thiệt hại và cho phép rút kinh nghiệm trước khi mở rộng.
Nguyên nhân 3 — đào tạo và quản lý thay đổi bị bỏ qua. Nhân viên cửa hàng quay lại bảng tính riêng là dấu hiệu kinh điển: họ làm vậy khi hệ thống mới chậm hơn cách cũ ở một thao tác họ phải làm hàng chục lần mỗi ngày, hoặc khi nó không cho phép một trường hợp mà thực tế vẫn xảy ra. Đào tạo phải gắn với đúng công việc của từng vai trò, và phải có kênh để nhân viên báo lại chỗ hệ thống cản trở họ.
Đáng lẽ phải làm. Làm sạch và đối soát dữ liệu trước khi chuyển, có báo cáo đối chiếu tổng số lượng và tổng giá trị giữa hai hệ thống; chọn triển khai thí điểm ở một nhóm cửa hàng đại diện đủ khác nhau; chạy song song trong giai đoạn thí điểm để phát hiện sai lệch; đào tạo theo vai trò kèm tài liệu ngắn tại chỗ; và duy trì một kênh tiếp nhận phản hồi để sửa các điểm cản trở trong vài tuần đầu, vì đó là giai đoạn quyết định người dùng có chấp nhận hệ thống hay không.
Bẫy 2 — nêu tên kỹ thuật thu thập yêu cầu mà không nêu điểm yếu. Câu hỏi dạng này luôn chấm theo cặp ưu điểm và hạn chế, và ý mạnh nhất là mỗi kỹ thuật có một điểm mù có hệ thống nên phải đối chiếu chéo ít nhất hai kỹ thuật.
Bẫy 3 — đưa vòng lặp và câu lệnh điều kiện vào sơ đồ luồng dữ liệu. Sơ đồ này mô tả hệ thống LÀM GÌ, không mô tả cách hiện thực. Logic điều khiển thuộc về lưu đồ và mã giả.
Đọc xong rồi — làm thử ngay
Bài tập của chương System Fundamentals gồm 14 câu trắc nghiệm và 5 đề tự luận. Đáp án hiện ngay khi chọn, miễn phí.