Bài giảng Xây dựng và chuyển đổi hệ thống

Xây dựng và chuyển đổi hệ thống Xây dựng và chuyển đổi HT Mở đầu  Quản lý lập trình Thiết kế kiểm thử Xây dựng tài liệu hệ thống Chuyển đổi hệ thống Bảo trì hệ thống 1. Mở đầu Xây dựng là sự triển khai tất cả các phần của hệ thống, trong đó chủ yếu bao gồm: Bản thân phần mềm HTTT.- Lập tài liệu hệ thống.- Thủ tục qui trình xử lý công việc mới. Trọng tâm của giai đoạn này là lập trình, theo sau là kiểm thử (test) kết quả lập trình. Một sai lầm thường thấy là nhiều lập trình viên xem thường việc kiểm thử và lập tài liệu hệ thống. Các tổ chức chuyên nghiệp sẳn sàng mất thời gian và tốn tiền cho việc kiểm thử và lập tài liệu HT nhằm ngăn chận những sai lầm có thể xảy ra sau khi HT được cài đặt. Lập trình được đề cập nhiều ở các môn học lập trình. Do đó ở đây nhấn mạnh đến: - Quản lý việc lập trình. - Kiểm thử chương trình. - Lập tài liệu hệ thống. Xây dựng và chuyển đổi HT Mở đầu Quản lý lập trình  Thiết kế kiểm thử Xây dựng tài liệu hệ thống Chuyển đổi hệ thống Bảo trì hệ thống 2. Quản lý lập trình Thông thường thì PTV không phải lập trình, các lập trình viên (LTV) sẽ lập trình. PTV sẽ quản lý việc lập trình của các LTV. Quản lý việc lập trình liên quan đến: Gán các môđun cho LTV. Phối hợp các hoạt động. Quản lý lịch trình. Gán các môđun cho LTV. PTV nhóm các môđun liên quan với nhau và giao cho LTV. Trong nhiều công việc, nhiều người làm tốt hơn ít người làm và công việc sẽ xong nhanh. Đối với phát triển hệ thống (lập trình), nhiều LTV tham gia có thể làm chậm dự án. Tại sao? Nhiều LTV sẽ làm tăng các hoạt động phối hợp và còn ít thời gian lập trình. Dự án phức tạp đòi hỏi nhóm lớn LTV nên chia thành nhiều phần nhỏ độc lập. Phối hợp các hoạt động. Họp đều đặn, hiệu quả. Khuyến khích các LTV trao đổi các vấn đề trước khi chúng có thể trở thành những khó khăn, rủi ro. Trao đổi về những vấn đề phát sinh, những thay đổi về yêu cầu, các chuẩn và qui ước chung liên quan lập trình. Nhiều dự án tổ chức việc lập trình thành ba khu vực gồm khu vực phát triển (lập trình), khu vực kiểm thử và khu vực sản phẩm. Các khu vực hoạt động phối hợp như sau: - Khu vực phát triển chịu trách nhiệm lập trình. Các chương trình hoàn thành được copy và chuyển đến khu vực kiểm thử. Khu vực kiểm thử chịu trách nhiệm test chương trình. Nếu không đạt sẽ được chuyển trở lại khu vực phát triển. Khi tất cả chương trình được test và sẳn sàng hỗ trợ HT mới thì sẽ được copy chuyển đến khu vực sản phẩm. Tại đây HT cuối cùng được hình thành. Ba khu vực này có thể ở ba thư mục khác nhau trên đĩa cứng server, ở ba server khác nhau, hoặc ở ba chỗ làm việc khác nhau. Việc sao chép để giữ các files và chương trình ứng với tình trạng hoàn thành sẽ giúp PTV kiểm soát được sự thay đổi. Một kỹ thuật quản lý khác là PTV có thể dùng program log. Đây là một form trên đó PTV ký nhận CT để viết, và ký xác nhận CT hoàn thành. Khu vực lập trình và program log giúp PTV biết được sự làm việc của LTV và tình trạng các CT. Quản lý lịch trình. Luôn đối chiếu với thời gian được hoạch định trong dự án. Điều chỉnh thời gian thích hợp khi việc xây dựng HT bắt đầu tiến hành. Coi chừng vấn đề “scope creep” do sự phát sinh yêu cầu mới. Cần chống lại khuynh hướng giảm chất lượng lập trình để đúng với lịch trình dự kiến. Một trong những vấn đề gây khó khăn nhất cho việc quản lý lịch trình là yêu cầu HT thay đổi hoặc bổ sung trong quá trình xây dựng HT. Tránh những lỗi “cổ điển” sau đây khi phát triển hệ thống: Phát triển HT chạy theo nghiên cứu. Dùng lập trình viên “lương thấp”. Mất đi sự kiểm soát mã lập trình. Tổ chức kiểm thử không phù hợp. Xây dựng và chuyển đổi HT Mở đầu Quản lý lập trình Thiết kế kiểm thử  Xây dựng tài liệu hệ thống Chuyển đổi hệ thống Bảo trì hệ thống 3. Thiết kế kiểm thử Nguyên tắc kiểm thử. Sẽ nguy hiểm nếu như test các môđun quá sớm trong khi chưa có kế hoạch kiểm thử. Việc kiểm thử không có kế hoạch sẽ làm cho các test quan trọng có thể được xem xét không chi tiết và rất khó để tạo lại chuỗi biến cố gây nên lỗi sai. Việc kiểm thử phải được thực hiện một cách có hệ thống và các kết quả kiểm thử phải được lập tài liệu cẩn thận. Việc kiểm thử phải được bắt đầu bằng việc lên kế hoạch kiểm thử cho các tester. Kế hoạch kiểm thử xác định dãy các test cần được tiến hành. Mỗi một test trong kế hoạch kiểm thử phải có mục tiêu cụ thể, tập các test cases phải được mô tả rõ ràng và chính xác, phải dự đoán kết quả test, và ghi rõ kết quả test thực sự thu được. Trong thực tế các test cases không thể vét cạn các tổ hợp có thể có. Do vậy cần phải chọn các test cases điển hình. Khi test không phải tất cả các môđun đều xong cùng lúc để có thể kết hợp khi test. Do vậy cần viết các stub đối với các môđun chưa hoàn thành để có thể tiến hành test. Stub là nơi giữ chỗ cho môđun chưa hoàn thành. Một stub đơn giản có thể chỉ là một thông báo cho biết môđun làm công việc gì. Ví dụ test môđun thực đơn, có thể các môđun công việc chưa viết xong. Khi test thực đơn thì lúc chọn công việc chỉ cần xuất ra màn hình thông báo công việc đó là gì. Ví dụ kế hoạch kiểm thử. Phân loại các test. Test từng phần: Test các cấu trúc điều khiển trước khi môđun hoàn thành. Test đơn vị: Test từng môđun để bảo đảm nó thực hiện đúng chức năng. Test tổng hợp: Test sự tương tác giữa các môđun để bảo đảm chúng phối hợp được. Test hệ thống: Test nhằm bảo đảm phần mềm làm việc tốt (as part of overall system). Test chấp nhận: Test nhằm bảo đảm hệ thống đáp ứng nhu cầu của tổ chức. Test từng phần (Stub Tests). Có thể tạo các stub giữ chỗ cho các môđun để có thể test menu. Test đơn vị (Unit Tests). Kiểm tra xem đơn vị có thực hiện đúng chức năng đã xác định trong đặc tả CT không. Đơn vị có thể là môđun hoặc CT. Có hai cách tiếp cận để test gọi là hộp đen (black-box) và hộp trắng (white-box). Test kiểu hộp đen tức là xem chương trình như là hộp đen, vào input và test các output. Test kiểu hộp trắng tức là xem chi tiết các đoạn mã lập trình. Có thể không cần xem hết, chỉ xem các đoạn mã quan trọng. Test tổng hợp (Integration Tests). Đánh giá xem các môđun hoặc chương trình cần làm việc với nhau có thể kết hợp với nhau mà không có sai sót. Bao gồm: User interface testing. User scenario testing. Data flow testing. System interface testing. Test hệ thống (System Tests). Đánh giá xem toàn bộ các môđun và các chương trình làm việc kết hợp cùng với nhau mà không có sai sót. Test hệ thống tương tự như test tổng hợp nhưng ở phạm vi rộng hơn, bao quát hơn. Test tổng hợp nhấn mạnh đến các môđun hoặc chương trình kết hợp với nhau được không. Còn test hệ thống tập trung đánh giá HT đáp ứng các nhu cầu công việc của tổ chức đến mức nào. Các loại test hệ thống. Requirements testing: Test xem các yêu cầu đặt ra ban đầu có đáp ứng được không. Usability testing: Test xem HT có sử dụng thuận tiện đối với NSD không. Security testing: Test khả năng phục hồi hư hỏng và ngăn chận các truy cập trái phép. Performance testing: Khảo sát khả năng thi hành của HT trong tình trạng tải cao. Documentation testing: Test sự chính xác của các tài liệu (sưu liệu) HT. Test chấp nhận (Acceptance Test). Các test trên thực hiện bởi các testor, LTV, PTV và NSD (ít). Test chấp nhận thực hiện chủ yếu bởi tổ chức và nhóm dự án. Test nhằm xác nhận HT đã được hoàn thành, đáp ứng các yêu cầu của tổ chức, và được nhấp nhận bởi tổ chức. Alpha testing: NSD test HT dùng các made-up data, có thể lặp lại các test trước. Beta testing: NSD test HT dùng các real data, có sự giám sát cẩn thận. Mức độ khám phá lỗi sai qua các giai đoạn test. Xây dựng và chuyển đổi HT Mở đầu Quản lý lập trình Thiết kế kiểm thử Xây dựng tài liệu hệ thống  Chuyển đổi hệ thống Bảo trì hệ thống 4. Xây dựng tài liệu hệ thống Có hai loại tài liệu quan trọng và căn bản đối với một HTTT tin học hóa là: Tài liệu hệ thống (System documentation).- Tài liệu cho NSD (User documentation). Tài liệu HT nhằm giúp cho các LTV và PTV bảo trì và mở rộng HT sau khi nó được cài đặt. Tài liệu dành cho NSD nhằm giúp NSD sử dụng, thao tác, vận hành HT. Biên soạn các tài liệu. Để có được một tài liệu tốt mất nhiều thời gian hơn chúng ta tưởng. Đừng bao giờ dời việc biên soạn tài liệu đến giai đoạn cuối của dự án. Thời gian dành cho việc biên soạn và test tài liệu cho NSD cần được đưa vào kế hoạch DA. Các tài liệu on-line ngày càng đóng vai trò quan trọng, cần được chú ý phát triển. Ưu điểm của tài liệu on-line. Tìm kiếm đơn giản. Chi phí rẻ hơn giấy. Thông tin có thể được trình bày dưới nhiều dạng, hình thức khác nhau. Phát triển nhiều phương pháp tương tác mới với tài liệu (tool tips, index, keywords). Qui trình biên soạn một tài liệu on-line cũng giống như qui trình thiết kế giao diện. Tổ chức tài liệu tham khảo on-line. Các loại tài liệu. Tài liệu tham khảo (Reference documents) giúp NSD tham khảo khi cần (thuật ngữ, mô tả hệ thống, cách thực hiện, …). Sổ tay hướng dẫn (Procedures manuals) mô tả cách thực hiện một tác vụ. Cách viết theo kiểu step-by-step. Tài liệu hướng dẫn sử dụng (Tutorials) mô tả cách thực hiện những chức năng căn bản và thường dùng của HT. Một số hướng dẫn thực hành viết tài liệu. Dùng thể chủ động. Tránh dùng nhiều các từ thì, mà, là. Dùng thuật ngữ một cách phù hợp. Dùng ngôn ngữ đơn giản, thân thiện. Mô tả các bước chính xác, rõ ràng. Dùng các đoạn văn ngắn. Xây dựng và chuyển đổi HT Mở đầu Quản lý lập trình Thiết kế kiểm thử Xây dựng tài liệu hệ thống Chuyển đổi hệ thống  Bảo trì hệ thống 5. Chuyển đổi hệ thống Quản lý việc thay đổi chuyển sang một HT mới là công việc khó khăn nhất trong tổ chức bất kỳ. Qui trình thay đổi ba bước: Unfreeze: Nới lỏng các thói quen, các chuẩn mực (trong HT hiện thời) của NSD. Chuyển đổi: Chuyển tiếp từ HT hiện thời sang HT mới. HT mới được cài đặt. Refreeze: Hỗ trợ để HT mới được vận hành và khai thác đúng cách, hiệu quả. Qui trình chuyển đổi hệ thống. Hai cách tiếp cận chuyển đổi hệ thống. Chuyển đổi tức thời: HT mới thay đổi tức thời HT cũ. Chuyển đổi mang tính thời điểm. Chuyển đổi song song: HT mới cùng làm việc với HT cũ. HT cũ rút lui từ từ. Đặc điểm các cách tiếp cận: Chuyển đổi tức thời: Ít tốn chi phí, nhiều rủi ro khi thực hiện. Chuyển đổi song song: Tốn chi phí và thời gian, ít rủi ro khi thực hiện. Kế hoạch chuyển đổi. Xác định cách tiếp cận chuyển đổi. Các hoạt động về kỹ thuật. Lắp đặt phần cứng, cài đặt phần mềm. Chuyển đổi dữ liệu. Các hoạt động về tổ chức. Huấn luyện NSD. Thúc đẩy và động viên NSD dùng HT  mới và hỗ trợ NSD. Các thành phần trong kế hoạch chuyển đổi HT. Tổng quát, kế hoạch chuyển đổi muốn tốt cần được xem xét theo nhiều khía cạnh: Cách tiếp cận (style): Tức thời, song song. Phạm vi chuyển đổi (location): Thử nghiệm tại một hoặc vài nơi (pilot), chuyển đổi ở các nơi một cách tuần tự (phased), chuyển đổi các nơi cùng thời gian (simultaneous). Khối lượng chuyển đổi (modules): Chuyển đổi toàn bộ HT hay từng phần HT. Khi lập kế hoạch chuyển đổi cần cân nhắc ba yếu tố mức độ rủi ro, chi phí và thời gian. Các khía cạnh của việc chuyển đổi. Huấn luyện NSD. HT mới đòi hỏi NSD có những kỹ năng mới. Kỹ năng mới có thể liên quan đến khía cạnh kỹ thuật (dùng máy tính, dùng mạng). Kỹ năng mới có thể liên quan đến qui trình xử lý công việc (qui trình có thể cần thay đổi để thích hợp với HT dùng máy tính). Các hình thức huấn luyện. - Một-một.- Lớp học lớn, nhóm nhỏ.- Dựa trên máy tính. Xây dựng và chuyển đổi HT Mở đầu Quản lý lập trình Thiết kế kiểm thử Xây dựng tài liệu hệ thống Chuyển đổi hệ thống Bảo trì hệ thống  6. Bảo trì hệ thống Các công việc cần làm sau khi chuyển đổi HT. Hỗ trợ NSD: Đường dây nóng, trang Web giúp đỡ, bàn hướng dẫn, bổ sung các khóa huấn luyện. Bảo trì hệ thống: Sửa lỗi HT và cung cấp các cải tiến. Những lỗi và cải tiến này xuất hiện khi HT mới đi vào sử dụng. Đánh giá dự án: Học được những bài học gì, rút ra được những kinh nghiệm gì từ việc thực hiện dự án. Các tài liệu hệ thống (System documentation) được biên soạn tốt sẽ giúp ích rất nhiều cho việc bảo trì hệ thống. Bảo trì hệ thống đến từ đâu: Báo cáo lỗi sai, vấn đề do NSD phát hiện khi thao tác với HT. NSD yêu cầu thay đổi hoặc bổ sung HT do thay đổi qui trình, chính sách trong tổ chức. Do yêu cầu từ việc phát triển các dự án hệ thống khác. Những bài học sau khi hoàn thành HTTT mới cho tổ chức. Bài học về quản lý: Quản lý dự án (lập kế hoạch, thực hiện, đánh giá). Bài học về kỹ thuật: Mạng máy tính, các thiết bị ngoại vi, các thiết bị mạng, lập trình (ngôn ngữ, môi trường phát triển). Bài học về phân tích và thiết kế: Lập kế hoạch, phân tích, thiết kế, xây dựng, chuyển đổi. Tóm lại, chúng ta đã nói về … Mở đầu  Quản lý lập trình  Thiết kế kiểm thử  Xây dựng tài liệu hệ thống  Chuyển đổi hệ thống  Bảo trì hệ thống 