Phát triển hệ thống và công nghệ mới

Mô hình thác nước tiến hành các công đoạn theo trình tự từ thượng nguồn xuống hạ nguồn như dòng thác, xác định xong sản phẩm đầu ra của mỗi công đoạn rồi mới chuyển sang công đoạn tiếp theo. Xây dựng dần qua các chu kỳ lặp ngắn là phát triển linh hoạt (agile), chốt yêu cầu bằng bản mẫu là mô hình prototype, kết hợp dịch vụ sẵn có là mashup.

Mô hình prototype nhằm giải quyết sớm sự mơ hồ trong yêu cầu và sự lệch pha nhận thức giữa bên đặt hàng và bên phát triển, bằng cách tạo bản mẫu (prototype) từ giai đoạn đầu phát triển để người dùng trải nghiệm. Đây không nhằm giảm số dòng lệnh, không bỏ qua kiểm thử và cũng không loại bỏ được nhu cầu bảo trì sau vận hành.

Phát triển linh hoạt là tư tưởng phát triển trong đó phần mềm hoạt động được tích lũy dần qua mỗi chu kỳ lặp ngắn, linh hoạt đối ứng với thay đổi yêu cầu; Scrum, XP là các phương pháp tiêu biểu. Chốt toàn bộ yêu cầu rồi mới phát triển một lần, hoàn thiện tài liệu rồi mới bắt tay vào, hay người dùng chỉ tham gia ở cuối cùng, đều gần với cách làm của mô hình thác nước, không phải đặc điểm của agile.

Sprint là khoảng thời gian cố định ngắn làm đơn vị phát triển trong Scrum; trong mỗi sprint, lập kế hoạch rồi phát triển, tạo ra phần mềm hoạt động và nhìn lại (retrospective), lặp lại chu trình này. Đây không phải công đoạn định nghĩa yêu cầu hay khoảng thời gian kiểm thử nghiệm thu, cũng không phải khoảng thời gian chỉ để sửa lỗi.

Vì mô hình thác nước tiến hành với tiền đề không quay lại, nên nếu ở công đoạn hạ nguồn như kiểm thử phát hiện sai sót về yêu cầu hoặc thiết kế, chi phí quay lại thượng nguồn để làm lại là rất lớn. Do mỗi công đoạn đều xác định tài liệu đặc tả - thiết kế nên việc nắm bắt tiến độ lại là điểm mạnh, và đây là mô hình phù hợp với phát triển quy mô lớn. Việc văn bản hóa yêu cầu cũng hoàn toàn có thể thực hiện.

Mô hình tăng dần chia hệ thống thành các đơn vị chức năng và tích lũy dần việc phát triển - triển khai theo từng giai đoạn; cùng với mô hình phát triển lặp, mô hình này có ưu điểm là có thể sử dụng một phần chức năng từ sớm. Mô hình thác nước phát triển toàn bộ một lần theo trình tự, phương pháp phân tích có cấu trúc là phương pháp phân tích dùng DFD v.v., mashup là kết hợp các dịch vụ sẵn có; đều không phù hợp.

Phát triển bắt đầu từ phân tích yêu cầu — sắp xếp lại yêu cầu của người dùng — rồi tiến đến thiết kế ngoài (phần người dùng nhìn thấy), thiết kế trong (cách thực hiện bên trong), lập trình, kiểm thử theo trình tự cơ bản này. Trình tự thiết kế trước khi phân tích yêu cầu, hay kiểm thử trước khi lập trình, không phù hợp với mối quan hệ phụ thuộc của các sản phẩm đầu ra.

Thiết kế ngoài thiết kế phần người dùng và bên ngoài nhìn thấy như đặc tả màn hình, đặc tả biểu mẫu in, giao diện với hệ thống khác. Quyết định thuật toán bên trong hay cách lưu trữ vật lý là công việc của thiết kế trong - thiết kế chương trình; kiểm tra hoạt động từng mô-đun là công việc của kiểm thử đơn vị.

Kiểm thử đơn vị là công đoạn đầu tiên của kiểm thử, xác nhận từng mô-đun hoạt động đúng theo thiết kế chi tiết hay không. Ghép mô-đun để kiểm tra giao diện là kiểm thử tích hợp (kiểm thử kết hợp), nghiệm thu do bên đặt hàng thực hiện là kiểm thử nghiệm thu, xác nhận hiệu năng dưới tải cao là kiểm thử tải - kiểm thử hiệu năng.

Kiểm thử được tích lũy từ đơn vị nhỏ: đầu tiên kiểm thử đơn vị theo từng mô-đun, tiếp đến kiểm thử tích hợp ghép các mô-đun, kiểm thử hệ thống xác nhận toàn bộ hệ thống, và cuối cùng kiểm thử nghiệm thu do bên đặt hàng - người dùng thực hiện. Nếu xác nhận toàn thể hay nghiệm thu trước, thì sẽ tiến hành kiểm thử ở cấp cao hơn trong khi còn lẫn lỗi ở các bộ phận, không hợp lý.

Kiểm thử nghiệm thu là công đoạn kiểm thử cuối cùng, trong đó bên đặt hàng - người dùng xác nhận theo góc độ nghiệp vụ xem hệ thống được giao có thể sử dụng thực tế hay không, để quyết định nghiệm thu. Xác nhận logic bên trong là kiểm thử đơn vị (kiểm thử hộp trắng) do bên phát triển thực hiện, xác nhận mà không chạy chương trình là kiểm thử tĩnh, xác nhận kết nối giữa các mô-đun là kiểm thử tích hợp; đều không phải kiểm thử nghiệm thu.

Kiểm thử hộp đen coi chương trình bên trong như một "hộp đen", chỉ xác nhận mối quan hệ giữa đầu vào và đầu ra có đúng đặc tả hay không. Kiểm thử hộp trắng là kỹ thuật chú trọng bao phủ các nhánh, đường đi bên trong; kiểm thử tĩnh là phương pháp xác nhận bằng review v.v. mà không chạy chương trình; kiểm thử hồi quy là kiểm thử xác nhận phần khác không bị ảnh hưởng bởi việc sửa đổi.

Kiểm thử tải áp đặt tải cao như truy cập đồng thời nhiều thiết bị hoặc dữ liệu lớn để xác nhận hệ thống có chịu được và hiệu năng có được duy trì hay không; được thực hiện ở công đoạn kiểm thử hệ thống cùng với kiểm thử hiệu năng xác nhận thời gian phản hồi. Kiểm thử đơn vị xác nhận theo từng mô-đun, kiểm thử tĩnh xác nhận mà không chạy chương trình, kiểm thử hộp trắng là kỹ thuật chú trọng cấu trúc bên trong.

Tài liệu định nghĩa yêu cầu là thành quả của phân tích yêu cầu, tổng hợp các chức năng, hiệu năng, ràng buộc mà hệ thống cần đạt được, được bên đặt hàng và bên phát triển thống nhất, trở thành căn cứ cho thiết kế, kiểm thử, nghiệm thu sau này. Sổ tay hướng dẫn thao tác là tài liệu cách sử dụng cho người dùng, báo cáo kết quả kiểm thử đơn vị là ghi chép kết quả kiểm thử, sơ đồ cấu hình mạng là sơ đồ thiết kế thể hiện cấu hình; không phải tài liệu làm căn cứ thống nhất.

WBS là phương pháp phân rã theo tầng bậc các sản phẩm đầu ra của dự án và các công việc cần thiết để tạo ra chúng, giúp cấu trúc hóa; nhờ đó ngăn ngừa việc bỏ sót công việc và làm rõ đơn vị ước tính, phân công. Thể hiện lịch trình bằng thanh ngang là biểu đồ Gantt, quản lý theo giá trị hoàn thành là EVM, đánh giá rủi ro là phân tích rủi ro.

Biểu đồ Gantt thể hiện thời điểm dự kiến bắt đầu - kết thúc của từng hạng mục công việc bằng thanh ngang, được sử dụng rộng rãi để trực quan hóa tiến độ và lịch trình. Sơ đồ luồng dữ liệu thể hiện luồng dữ liệu, sơ đồ E-R thể hiện quan hệ giữa các thực thể, sơ đồ use case thể hiện tương tác giữa hệ thống và người dùng; không phải là sơ đồ quản lý lịch trình.

Có hai đường đi là A→B→D→F (3+5+4+2=14 ngày) và A→C→E→F (3+4+6+2=15 ngày); vì F phải chờ cả hai đường hoàn thành nên số ngày ngắn nhất của toàn bộ dự án là số dài hơn: 15 ngày. Đường dài nhất A→C→E→F chính là đường găng. 14 ngày chỉ là giá trị của riêng nhánh A→B→D→F; 12 ngày và 13 ngày không khớp với tổng của bất kỳ đường nào.

Có ba đường đi: A→B→D→F (2+4+3+1=10 ngày), A→C→D→F (2+6+3+1=12 ngày), A→C→E→F (2+6+4+1=13 ngày); đường dài nhất A→C→E→F = 13 ngày là đường găng. 10 ngày và 12 ngày là tổng của các đường khác, 14 ngày không khớp với đường nào. Sự chậm trễ của các công việc trên đường găng (A, C, E, F) sẽ trực tiếp làm chậm toàn bộ dự án.

Phương pháp điểm chức năng chấm điểm số lượng và độ phức tạp của các chức năng như đầu vào, đầu ra, truy vấn, tệp nội bộ để ước tính quy mô phần mềm; có thể ước tính từ giai đoạn sớm của phát triển mà không phụ thuộc vào số dòng lệnh. LOC là thước đo ước tính dựa trên số dòng, phương pháp Delphi là phương pháp hội tụ ý kiến chuyên gia qua khảo sát lặp lại, phương pháp KJ là phương pháp sắp xếp - nhóm thông tin bằng thẻ giấy.

Quản lý rủi ro được tiến hành theo trình tự: đầu tiên liệt kê rủi ro (nhận diện rủi ro), tiếp theo đánh giá xác suất xảy ra và mức độ ảnh hưởng (phân tích rủi ro định tính - định lượng), lập kế hoạch đối ứng, và trong quá trình thực hiện thì giám sát và kiểm soát tình hình. Việc lập kế hoạch đối ứng hay giám sát trước khi nhận diện là không hợp lý vì rủi ro đối tượng chưa được xác định.

Thay đổi đặc tả cần tuân theo quy trình quản lý thay đổi, đánh giá ảnh hưởng đến lịch trình, chi phí, chất lượng, rồi để Hội đồng quản lý thay đổi (CCB) quyết định phê duyệt hoặc từ chối. Việc chấp nhận vô điều kiện gây trễ tiến độ và giảm chất lượng, từ chối toàn bộ làm mất cả những thay đổi cần thiết. Việc để người phụ trách tự sửa tại chỗ gây ra sự không nhất quán với cấu hình và tài liệu, làm mất khả năng kiểm soát.

Stakeholder là tên gọi chung cho các cá nhân hoặc tổ chức có lợi ích liên quan đến kết quả của dự án như bên đặt hàng, người dùng, bên phát triển, ban lãnh đạo; việc nắm bắt và điều phối kỳ vọng của họ là hoạt động quan trọng trong quản lý dự án. Biểu đồ lịch trình là biểu đồ Gantt, phân rã công việc theo tầng bậc là WBS, danh sách rủi ro là sổ đăng ký rủi ro.

SLA là thỏa thuận giữa bên cung cấp dịch vụ và bên sử dụng về mức chất lượng dịch vụ như tỷ lệ hoạt động, thời gian khắc phục sự cố, khung giờ hỗ trợ, trở thành tiêu chí đánh giá dịch vụ vận hành. Bảo vệ bản quyền là hợp đồng cấp phép (license), sơ đồ phân rã công việc là WBS, thuê thiết bị là hợp đồng thuê (lease); đều không phải là SLA.

ITIL (Information Technology Infrastructure Library) là tập hợp tài liệu hệ thống hóa các thực hành tốt nhất về quản lý vận hành dịch vụ CNTT, được tham khảo rộng rãi như khuôn khổ quản lý dịch vụ bao gồm quản lý sự cố, quản lý thay đổi, bàn hỗ trợ dịch vụ. Tiêu chuẩn ngôn ngữ lập trình, lý thuyết chuẩn hóa, tiêu chuẩn mạng không dây đều thuộc lĩnh vực khác.

Tỷ lệ hoạt động được tính bằng MTBF ÷ (MTBF + MTTR). 570 ÷ (570 + 30) = 570 ÷ 600 = 0,95. MTBF là thời gian hoạt động bình quân từ sự cố này đến sự cố kế tiếp, MTTR là thời gian bình quân cần để sửa chữa. 0,90 và 0,98 không khớp dù đảo ngược tử số - mẫu số, 0,93 cũng không khớp với phép tính.

Quản lý năng lực là hoạt động dự đoán nhu cầu sử dụng tương lai như khối lượng dữ liệu, số lượt truy cập, và chủ động đảm bảo - tăng cường dung lượng máy chủ, thiết bị lưu trữ, mạng để ngăn ngừa trước tình trạng giảm hiệu năng hoặc thiếu dung lượng. Hệ thống liên lạc khi sự cố là quản lý sự cố - ứng phó khẩn cấp, quản lý mật khẩu là quản lý người dùng, quản lý giấy phép là quản lý tài nguyên phần mềm.

Ảo hóa máy chủ là công nghệ dùng phần mềm ảo hóa để chạy nhiều máy ảo trên một máy chủ vật lý, mang lại hiệu quả sử dụng tài nguyên cao hơn nhờ tập trung máy chủ, và tính linh hoạt trong thay đổi cấu hình - phục hồi. Việc lắp đặt phân tán vật lý hay thu nhỏ vỏ máy là vấn đề phần cứng, còn lưu trữ bằng giấy không liên quan đến ảo hóa.

SaaS (Software as a Service) là hình thức cung cấp bản thân ứng dụng dưới dạng dịch vụ qua mạng, người dùng có thể sử dụng mà không cần cài đặt phần mềm. IaaS cung cấp nền tảng hạ tầng như máy chủ, PaaS cung cấp cả môi trường thực thi ứng dụng; on-premise là hình thức tự sở hữu thiết bị và vận hành trong tổ chức, không phải hình thức cung cấp của đám mây.

Society 5.0 là ý tưởng thu thập dữ liệu thế giới thực vào không gian mạng bằng IoT v.v., phân tích rồi phản hồi kết quả về thế giới thực, hướng tới một xã hội hợp nhất cao độ không gian mạng và không gian vật lý, vừa phát triển kinh tế vừa giải quyết các vấn đề xã hội. Công nghệ chồng thông tin lên thực tế là AR, chia sẻ phép tính là xử lý phân tán, hệ thống tri thức về quản lý dự án là PMBOK.

Học có giám sát là phương pháp dùng dữ liệu có gán nhãn (đáp án đúng) để huấn luyện mô hình dự đoán đáp án từ đầu vào, được dùng cho phân loại hình ảnh, dự đoán giá trị số. Việc không cho đáp án mà để máy tính tự tìm cấu trúc, phân nhóm là học không giám sát. Đào tạo người dùng cho con người không phải là học máy, và việc tạo đầu ra ngẫu nhiên bằng số ngẫu nhiên cũng không liên quan đến việc học.