Mục lục bài họcĐang ở d09-b3
Software development and testing strategies
The stages
Analysis, design, coding, testing, implementation, maintenance and evaluation. The point examiners test is not the list but what happens when a stage is rushed: a fault introduced in analysis is far more expensive to fix after implementation than during design.
Waterfall
Each stage is completed before the next begins. Clear documentation and easy progress tracking, so it suits projects where requirements are known and stable — safety-critical systems, for example. Its weakness is that requirements are usually not fully known at the start, and going back is expensive.
Iterative and agile approaches
Iterative development builds a prototype, gets feedback and refines it, repeating the cycle. Agile works in short cycles delivering working software, with the customer involved throughout and requirements allowed to change. It handles uncertainty well and produces something usable early. Against it: less documentation, harder to fix a price or a deadline in advance, and it needs a customer who is actually available.
Rapid application development
Uses prototypes and user feedback to reach a working system quickly. Good where the interface matters and requirements are unclear; weaker where the system must be provably correct.
Testing strategies
White box testing looks at the code and checks every path is executed; black box testing checks inputs against expected outputs without looking inside. Alpha testing is in-house, beta uses real users, and acceptance testing checks the agreed requirements are met. Stub testing lets a module be tested before the modules it calls have been written.
Choosing between methodologies in an answer
Do not say agile is modern and therefore better. Ask: are the requirements stable, is the customer available, does the system need formal documentation, and what happens if it is wrong? A hospital drug dosage system and a marketing website deserve different answers.
Các giai đoạn
Phân tích, thiết kế, viết mã, kiểm thử, triển khai, bảo trì và đánh giá. Điều giám khảo kiểm không phải danh sách này mà là hệ quả khi một giai đoạn bị làm vội: một sai sót phát sinh ở khâu phân tích tốn kém hơn rất nhiều khi phải sửa sau triển khai so với khi sửa lúc thiết kế.
Mô hình thác nước
Mỗi giai đoạn hoàn tất rồi mới sang giai đoạn sau. Tài liệu rõ ràng và dễ theo dõi tiến độ, nên hợp với dự án mà yêu cầu đã biết và ổn định — ví dụ hệ thống liên quan tới an toàn. Điểm yếu là yêu cầu thường không được biết đầy đủ ngay từ đầu, và quay lại thì rất tốn kém.
Cách tiếp cận lặp và linh hoạt
Phát triển lặp dựng một bản mẫu, lấy phản hồi rồi tinh chỉnh, và lặp lại chu trình. Agile làm theo các chu kỳ ngắn, mỗi chu kỳ giao một phần mềm chạy được, với khách hàng tham gia suốt quá trình và yêu cầu được phép thay đổi. Nó xử lý sự bất định tốt và cho ra thứ dùng được sớm. Mặt trái: ít tài liệu hơn, khó chốt giá và hạn hoàn thành từ đầu, và nó đòi một khách hàng thực sự sẵn sàng tham gia.
Phát triển ứng dụng nhanh
Dùng bản mẫu và phản hồi người dùng để đi tới một hệ thống chạy được thật nhanh. Tốt khi giao diện là yếu tố quan trọng và yêu cầu chưa rõ; yếu hơn khi hệ thống phải chứng minh được là đúng.
Các chiến lược kiểm thử
Kiểm thử hộp trắng nhìn vào mã và kiểm mọi nhánh đều được chạy qua; kiểm thử hộp đen kiểm đầu vào so với đầu ra mong đợi mà không nhìn vào bên trong. Kiểm thử alpha làm nội bộ, beta dùng người dùng thật, và kiểm thử nghiệm thu kiểm xem các yêu cầu đã thoả thuận có được đáp ứng không. Mô-đun giả (stub) cho phép kiểm một mô-đun trước khi các mô-đun nó gọi được viết xong.
Chọn phương pháp luận trong bài
Đừng viết agile hiện đại nên tốt hơn. Hãy hỏi: yêu cầu có ổn định không, khách hàng có sẵn sàng tham gia không, hệ thống có cần tài liệu chính thức không, và chuyện gì xảy ra nếu nó sai? Một hệ thống tính liều thuốc trong bệnh viện và một website marketing xứng đáng có hai câu trả lời khác nhau.
Dự án A: phần mềm điều khiển liều thuốc cho máy truyền dịch trong bệnh viện. Yêu cầu kỹ thuật đã được cơ quan quản lý quy định chi tiết.
Dự án B: ứng dụng đặt sân thể thao cho một chuỗi trung tâm; ban giám đốc có ý tưởng chung nhưng chưa rõ người dùng muốn gì.
Chọn phương pháp luận cho từng dự án và giải thích.
Dự án A — mô hình thác nước.
Ba lý do gắn với chính đặc điểm của dự án:
$1.$ Yêu cầu đã ổn định và được quy định chi tiết — điều kiện tiên quyết để thác nước phát huy. Không có sự bất định nào cần thăm dò bằng bản mẫu.
$2.$ Hậu quả của lỗi là tính mạng. Hệ thống này cần tài liệu đầy đủ ở từng giai đoạn để cơ quan quản lý thẩm định và để truy vết trách nhiệm — đúng thứ thác nước tạo ra và agile hay thiếu.
$3.$ Cần kiểm thử hộp trắng đầy đủ, chứng minh mọi nhánh mã đều được chạy qua. Việc này đòi mã ổn định, không thay đổi liên tục qua từng chu kỳ.
Cái giá chấp nhận được ở đây: thác nước chậm và cứng nhắc, nhưng với hệ thống này thì tính đúng đắn quan trọng hơn tốc độ ra thị trường.
Dự án B — agile hoặc phát triển ứng dụng nhanh.
$1.$ Yêu cầu chưa rõ — chính là tình huống mà thác nước xử lý tệ nhất. Viết đặc tả đầy đủ cho một thứ chưa ai biết người dùng muốn gì là viết một tài liệu sẽ phải bỏ đi.
$2.$ Bản mẫu trả lời được câu hỏi nhanh hơn cuộc họp. Đưa một bản chạy được cho người dùng thử trong hai tuần cho biết nhiều hơn hai tháng thảo luận.
$3.$ Hậu quả của lỗi thấp: đặt nhầm sân là phiền toái, không phải thảm hoạ. Điều đó cho phép chấp nhận đánh đổi ít tài liệu lấy tốc độ.
Điều kiện phải nêu: agile chỉ chạy được nếu chuỗi trung tâm cử được người tham gia đều đặn suốt dự án. Nếu ban giám đốc chỉ họp mỗi quý một lần thì agile mất chính thứ làm nó hiệu quả, và lúc đó một mô hình lặp có mốc rõ ràng sẽ thực tế hơn.
Kết luận chung: không phương pháp luận nào tốt hơn về bản chất. Bốn câu hỏi quyết định là: yêu cầu có ổn định không, khách hàng có sẵn sàng không, có cần tài liệu chính thức không, và hậu quả nếu sai là gì.
Đọc xong rồi — làm thử ngay
Bài tập của chương Floating Point, Compression and Software Development gồm 14 câu trắc nghiệm và 3 đề tự luận. Đáp án hiện ngay khi chọn, miễn phí.