Bài giảng Phân tích thiết kế hệ thống - Chương 4: Triển khai ứng dụng - Nguyễn Anh Hào

PHÂN TÍCH THIẾT KẾ HỆ THỐNGTriễn khai ứng dụngTháng 9-2007ThS. Nguyễn Anh Hào1(1)Xây dựng phần mềm: Lập trình	1. Sử dụng ngôn ngữ lập trình, hàm thư viện và trình biên dịch / thông dịch (C++, Java ,)	2. Sử dụng công cụ phát triển phần mềm và thư viện các components chuẩn (.NET, Developer Suit)	3. Sử dụng các công nghệ hổ trợ lập trình (RPC, COM+, WebServer)	4. Sử dụng các services từ HĐHPROGRAM(Machine Instructions)FunctionsOperating System(s)ResourcesDBMSPheripheralSupportsServicesDriversPhần mềm được xây dựng bằng kiến thức và công nghệ hiện tại để sử dụng trong tương lai.Hiện thực tất cả những ý tưởng thiết kế chức năng xử lý của hệ thống thành mã lệnh điều khiển CPU2(1) Xây dựng phần mềm: Tạo CSDL	Hiện thực tất cả những ý tưởng thiết kế CSDL của hệ thống thành cấu trúc lưu trữ vật lý trên một hệ CSDLData Definition Language : là ngôn ngữ để định nghĩa / thay đổi cấu trúc các bảng quan hệ (CREATE, DROP)Data Manipulation Language : là ngôn ngữ để lấy hoặc cập nhật dữ liệu lưu trữ trong các bảng (INSERT, UPDATE, SELECT, )Data Control Language : Để phân quyền sử dụng (GRANT,ADD,...)3(2) Kiểm tra chất lượngPhát sinh & định nghĩa yêu cầu cho hệ thống.Thiết lập và thực hiện giải pháp để thỏa mãn các yêu cầu(1) Tất cả các tiến trình phải được kiểm soát để ngăn ngừa hoặc điều chỉnh các hành động và nhận thức không đúng về giải pháp(2) Hiện thực của hệ thống phải thỏa mãn toàn bộ yêu cầu nêu trong các mức thiết kế(1) Các thay đổi phải tương thích hoàn toàn với những gì được giữ lại (không thay đổi)(2) Các bài toán của tổ chức đã được giải quyết (có giải pháp)(3) Các yêu cầu của tổ chức được thể hiện đầy đủ, liên kết và kiểm chứng được.Khảo sát, phân tíchThiết kế luận lýThiết kế vật lýPhầnMềmHệ thống4(2) Các bước kiểm traHoạch định những gì cần phải kiểm tra, và đánh giá mức độ quan trọng của từng trường hợpBrainstorming phân tích các rủi ro khi vận hànhReview tài liệu khảo sát, thiết kế để tìm điểm yếuThiết lập các tiêu chuẩn kiểm tra. Mỗi tiêu chuẩn có mức độ quan trọng tương ứng với từng trường hợp kiểm tra.Thực hiện kiểm tra theo thứ tự ưu tiênLập kịch bản kiểm tra Kiểm tra, và ghi vếtPhân tích kết quả để khắc phục khuyết điểmSửa lổi chương trìnhThay đổi thiết kếKế hoạch hổ trợ: huấn luyện, thay thế thiết bị,5(2) Kiểm tra chức năngD0aD1aSoftware Process AD0bD1bSoftware Process BLogicaldesign PhysicalimplementationTest Designed Function 1D0D1D2I0I1I2Software Process 1Software Process 2Designed Function 2TestTest data Scenario (kịch bản)1. Mỗi chức năng của phần mềm phải hoạt động đúng theo thiết kế2. Các xử lý trong phần mềm không xung khắc lẫn nhauB phủ nhận kết quả của A6(2) Kiểm tra phi chức năngRecovery: khả năng chịu đựng hư hỏng và phục hồi các hoạt động của hệ thống sau khi sự cố xãy raSecurity: khả năng bảo vệ an toàn hệ thống trước các tác nhân gây hại đến dữ liệu hoặc xử lý trong hệ thốngPerformance: khả năng thực thi theo thời gian thực của hệ thốngReliability: khả năng chịu đựng lổi nhập liệuMaintainable: khả năng duy trì và phát triển hệ thốngEasy use/operation: khả năng hổ trợ sử dụng / vận hành hệ thống.Portable: phần mềm có thể hoạt động một cách độc lập hoặc ít phụ thuộc vào môi trường thực thi (phần cứng, hệ điều hành)7(2) Kỹ thuật kiểm traDataInputData OutputFunction Black box test: dựa trên chức năng đã thiết kế cho unit và dữ liệu được tạo ra để kiểm traDataInputData OutputCode walk-throughWhite box test: Đọc từng lệnh trong unit để khẳng định unit hoạt động đúng theo thiết kếRegression test: Kiểm tra tất cả những xử lý và dữ liệu đang tồn tại nhưng không bị thay đổi khi unit được thực thi, để bảo đảm chúng vẫn đúng.DataInputData OutputScope of change8(3) Cài đặt (installation)Cài đặt phần mềm ứng dụngGiải quyết xung khắc giữa các phần mềmGiải quyết sự không tương thích giữa phần mềm và lớp nềnThiết lập thông số của hệ thống, trongCác phần mềm,Cơ sở dữ liệu,Hệ điều hành và drivers,Máy tính, mạng máy tính và các thiết bị ngoại vi.Thiết lập quyền sử dụng cho usersQuản lý cấu hình hệ thốngVị trí cài đặt, settings, versions và người sử dụngThiết lập môi trường vận hành cho hệ thống để người sử dụng khai thác được các chức năng của hệ thống9(4) Chuyển đổi hệ thốngNội dung chuyển đổiQuy trình nghiệp vụ: thay quy trình củ bằng q.trình mớiCó quy định lại vai trò, trách nhiệm của từng userCó phân biệt sự khác nhau giữa công việc củ và mớiBiểu mẫu : ban hành biểu mẫu mới thay thế biểu củChuyển đổi dữ liệu từ CSDL củ sang CSDL mớiThay đổi phần mềm và hệ điều hànhThay thế hoặc bổ sung thiết bịChuyển các tác nghiệp (business transactions) đang thực hiện trên hệ thống củ sang khai thác trên hệ thống mới, có xác định nội dung cần chuyển đổi và phương pháp chuyển đổi.10(4) Chuyển đổi hệ thốngPhương pháp chuyển đổi11(4) Chuyển đổi hệ thốngDirect conversion: Nhanh, ít tốn kém nhưng có nhiều rủi ro nếu hệ thống mới hư hỏngParallel conversion: An toàn khi chuyển đổi, nhưng tốn nhiều chi phí để vận hành song song 2 hệ thống (khối lượng công việc của người nhân viên tăng 2 lần)Phased conversion: An toàn khi chuyển đổi và ít tốn kém hơn parallel conversion, nhưng nếu giữa hệ thống củ và hệ thống mới có dùng chung dữ liệu thì độ phức tạp của việc chuyển đổi sẽ tăng cao do phải đồng bộ dữ liệu trên cả 2 hệ thống.Pilot conversion: Các sự cố của hệ thống mới chỉ tập trung vào một nơi được chọn làm thí điểm; khi đó công việc tại nơi này được chuyển sang các nơi khác thực hiện.12(5) Lập tài liệuTài liệu hệ thống: Là chương trình nguồn, cấu trúc dữ liệu và hồ sơ đặc tả hệ thống (URD, DFD, ERD,..).Hướng dẫn sử dụng: là tài liệu mô tả cách khai thác, vận hành và quản lý hệ thống cho người sử dụng.	Tất cả các loại tài liệu đều phải đúng với thực tế - Các thay đổi được kiểm soát trên từng phiên bản của tài liệu.Role 1Role 2Function 1Function 2Function 3Function 4Hệ thống phần mềm, mạng, thiết bịQuy trình nghiệp vụ 1Quy trình nghiệp vụ 213(6) Huấn luyệnPhương phápHướng dẫn sử dụng tại chổTổ chức lớp huấn luyệnSử dụng phần mềm huấn luyệnSử dụng User Guide / HelpBổ sung kiến thức và kỹ năng cần thiết để vận hành, khai thác và quản lý hệ thống cho người sử dụng.** Nội dung và khối lượng huấn luyện phải được thiết kế phù hợp với người được huấn luyện.14(7) Hổ trợ sử dụngPhương phápHổ trợ vận hành, khai thácBằng phần mềm, vd: “Office Assistant”Bằng Website (Online helps, forum, chat)Bằng điện thoại hoặc tiếp xúc trực tiếpKhắc phục sự cốBằng phần mềm cài đặt sẵn (error-recovery)Điều khiển từ xa qua mạngThực hiện nhân côngTrợ giúp người sử dụng giải quyết những tình huống khó khăn trong khi đang sử dụng hệ thống.15(8) Bảo trìPhương phápXác định vai trò của các yêu cầu thay đổiSửa lổi (ưu tiên cao nhất)Thay đổi trong môi trường vận hànhCải tiến hệ thống để giải quyết thêm các vấn đề mớiPhân tích ảnh hưởng của thay đổi đối với hệ thốngMức độ thay đổi (chi phí) vs tầm quan trọng (lợi ích)Xác định giải pháp cho các thay đổiThành lập dự án mới hoặc sử dụng nhóm bảo trìThiết kế, cài đặt các thay đổi cho hệ thốngQuản lý cấu hình của hệ thống (vd: version/release)Duy trì hoạt động của hệ thống cho phù hợp với yêu cầu từ môi trường vận hành của tổ chức16Những thách thức của httt quản lýHoạch định chính xác những gì hệ thống cần phải làm để nó hổ trợ đắc lực cho (mục đích của) tổ chức. Why ?MIS được thiết kế bởi chuyên viên CNTT, và khai thác bởi nhà quản lý. Hai đối tượng này có kiến thức chuyên môn và vai trò khác nhau đối với HTTTQL.Giảm khoảng cách kiến thức giữa hai đối tượng để hoạch định ra mục tiêu thiết thực và khả thi.Mức độ hiểu biết về CNTT của nhà quản lý ở các cấpMức độ hiểu biết về quản lý của phân tích &lập trình viên"khoảng cách" kiến thức giữa 2 đối tượngHướng quản lýHướng CNTT17Những thách thức của httt quản lýHệ thống cần phải được thiết kế mềm dẻo để nó có thể thích nghi với những thay đổi cần thiết từ phía tổ chức.Thiết kế hợp chuẩn và áp dụng công nghệ phù hợp để hệ thống dể phát triển và giảm rủi ro.Chuẩn hóa để áp dụng kinh nghiệm của thế giới.Công nghệ quá mới và quá củ đều tiềm ẩn nhiều rủi ro.Tài liệu mô tả hệ thống cần phải được duy trì cùng với hệ thống để làm cơ sở cho các cải tiến & nâng cấp.Để hướng dẫn cho những người tiếp nhận hệ thống biết cần phải làm gì và làm như thế nào để cải tiến hệ thống.Lập sưu liệu bằng CASE tools để giảm bớt gánh nặng lập sưu liệu.18Những thách thức của httt quản lýQuản lý kỹ các yêu cầu và các thay đổi để bảo đảm chất lượng của hệ thống.Các yêu cầu phải có tính thống nhất, không chứa mâu thuẩn, tối ưu cục bộ hoặc hiểu sai.Ng.sử dụngNg.quản lý, vận hànhNg.thiết kếNg.lập trìnhNêu yêu cầu dựa trên tiện ích cá nhânHướng đến tối ưu về kỹ thuật xử lýNêu yêu cầu dựa trên chức năng quản lýHiểu yêu cầu theo q.điểm công nghệYêu cầu cho hệ thống 19Những thách thức của httt quản lýCác thay đổi cần phải được kiểm soát kỹ để bảo đảm cho hệ thống được tạo ra đúng như mong muốn.Thay đổi trên yêu cầu. Thay đổi trên yêu cầu càng nhiều thì càng làm tăng xác suất phát sinh lổi (Failure rate).IdealchangetimeFailure rate20Những thách thức của httt quản lýThay đổi trên quá trình tạo sản phẩm. Sự tích lũy các sai sót trong chuổi các bước chuyển giao tri thức cũng là yếu tố làm hiểu sai yêu cầu, làm cho sản phẩm không đáp ứng đúng như mong đợi.P.tíchT.kếCodeK.sát100 %80 %90 %90 %Correctness = 0.8 * 0.9 * 0.9 * 0.9= 0.5832  60 %90 %Yêu cầuSản phẩm21Những thách thức của httt quản lýHệ thống cần phải được chuyển giao trọn vẹn cho vận hành & khai thác => giải quyết các khó khăn sau:Nhận thức về hệ thống (mới) của người sử dụng. "Sử dụng hệ thống cũng khó như xây dựng hệ thống".Bỏ hệ thống củ, lại còn tốn công thiết lập hệ thống mớiPhải học để làm việc trong hệ thống mớiNgười sử dụng cần thay đổi thói quen để tiếp cận hệ thống mớiCBIS: Quản lý theo tiêu chuẩn, loại bỏ “ngẫu hứng”(Bị) thay đổi công việc cho phù hợp với hệ thống mớiCần làm nhiều hơn trong giai đoạn đầu triển khai ứng dụngKhi tái bố trí lại cơ cấu (re-engineering), nhiều người phải chuyển công tác => họ không muốn thay đổi22