1. Thử nghiệm công nghệ ICR với phiếu điều tra BĐDS năm 2006 của tỉnh
1.1. Nghiên cứu phần mềm, thiết lập hệ thống ứng dụng đối với phiếu điều
tỉnh Bắc Ninh bắt đầu từ đầu tháng 1 và hoàn thành vào cuối tháng 4 năm 2007 với kết quả là hệ thống được thiết lập và chương trình hồn chỉnh được chạy thử nghiệm tốt với một số địa bàn của tỉnh Bắc Ninh.
Các công việc cụ thể đã tiến hành với việc thử nghiệm công nghệ ICR với cho phiếu điều tra BĐDS 2006 như sau:
1.1. Nghiên cứu phần mềm, thiết lập hệ thống ứng dụng đối với phiếu điều tra BĐDS 2006 BĐDS 2006
Việc nghiên cứu phần mềm dựa chủ yếu vào các tài liệu hướng dẫn sử dụng của ReadSoft được cung cấp cùng với phần mềm.
Đối với mỗi phiếu điều tra để áp dụng công nghệ ICR của ReadSoft, cần phải xây dựng một ứng dụng riêng cho mẫu phiếu bao gồm xác định đầu vào, đầu ra và các tùy biến cho các chức năng xử lý để chuyển đầu vào thành đầu ra theo yêu cầu. Trong đó, xác định đầu vào là quan trọng và tốn nhiều thời gian nhất. Đấy chính là những mơ tả, khai báo để hệ thống nhận ra một mẫu phiếu, xác định các trường cần nhận dạng và các thuộc tính đặc thù của chúng. Nhiều tùy biến của trường hoặc của Form tạo ra những ảnh hưởng không nhỏ đối với chất lượng nhận dạng và do vậy cần phải được chạy thử để kiểm tra với các lựa chọn khác nhau, nhất là đối với những người mới bắt đầu, chưa có kinh nghiệm như chúng ta.
Ứng dụng được xây dựng bằng cách sử dụng các công cụ trong phần mềm ReadSoft FORMS 5.2. Đầu tiên, nhóm nghiên cứu đã thiết kế một ứng dụng với một mẫu phiếu được in ra máy tính. Tờ phiếu in được photocopy thành mấy chục bản và được cán bộ phịng CSDL tự điền thơng tin bằng cách chép lại số liệu từ phiếu điều tra chính thức. Mục đích của thử nghiệm đầu tiên này là tiếp tục với mẫu form đã định dạng cùng với chuyên gia trong những ngày đào tạo,
xác định chất lượng nhận dạng với các cách điền phiếu với mức độ cẩn thận
khác nhau, với các loại bút và cách viết khác nhau. Tuy nhiên, thử nghiệm đầu tiên này có kết quả rất thấp vì rất nhiều tờ phiếu bị loại do hệ thống không xác định được (tỷ lệ có thể lên tới 20%). Có thể rút ra kết luận rằng, các tờ phiếu photocopy, và tương tự là với các phiếu có chất lượng in thấp thì khơng thể áp dụng công nghệ ICR được.
Mẫu phiếu thứ hai được thử là mẫu phiếu chính thức điều tra BĐDS 2006 của tỉnh Bắc Ninh (năm 2006 phiếu điều tra BĐDS của tỉnh Bắc Ninh được
thiết kế riêng và in riêng khác biệt so với các tỉnh còn lại). Ứng dụng với mẫu phiếu này đã được xây dựng một cách hoàn chỉnh hơn, với đầy đủ các thuộc tính, lựa chọn và được chạy thử với nhiều thay đổi lựa chọn khác nhau. Với việc chạy thử được qua tồn bộ quy trình các địa bàn điều tra tỉnh Bắc Ninh, có thể coi việc xây dựng ứng dụng ICR với điều tra này đã hoàn thành.
Một ứng dụng được xây dựng với chỉ các công cụ của phần mềm ReadSoft FORMS 5.2 là cũng đã có thể thực hiện việc xử lý phiếu điều tra. Tuy nhiên trong phần lớn trường hợp những ứng dụng như vậy bị hạn chế rất nhiều.
Hạn chế rõ ràng nhất là trong việc kiểm tra số liệu nhận dạng được. Những công cụ của ReadSoft FORMS 5.2 chỉ cho phép thiết lập những kiểm tra đơn giản như loại trường, loại chữ số, khoảng xác định, cộng tổng,...Nhưng việc kiểm tra tổng thiết lập bằng phần mềm cũng không áp dụng được cho phần lớn những điều tra thống kê vì số liệu điều tra thường có những giá trị đặc biệt như khơng biết, khơng xác định. Đối với những nước điều tra viên có trình độ cao, tuân thủ nghiêm các quy định ghi phiếu họ có thể thỏa mãn với những kiểm tra của phần mềm, và do vậy họ không cần lập trình bằng các ngơn ngữ khác để bổ sung thêm các kiểm tra logic. Ví dụ như trong tổng điều tra dân số của Lào khơng có các kiểm tra viết thêm, nhiều nước khác các kiểm tra lập trình bổ sung rất tối thiểu. Nếu cịn có những lỗi logic sót lại sau nhận dạng và kiểm tra, số liệu sẽ được làm sạch bằng các chương trình hiệu chỉnh tự động.
Đối với số liệu điều tra thống kê của Việt Nam, do các lỗi logic để lại khá lớn, việc hiệu chỉnh tự động sẽ không đảm bảo chất lượng, có thể làm sai lệch số liệu. Do vậy việc phải kiểm tra và sửa chữa trực tiếp là rất cần thiết. Nếu chương trình kiểm tra logic viết cho số liệu đầu ra của hệ thống ICR thì sẽ là một chương trình viết theo kiểu truyền thống của các chương trình kiểm tra logic lâu nay chúng ta vẫn viết và việc lập trình khá đơn giản. Tuy nhiên nếu làm như vậy, sẽ phát sinh thêm một công đoạn kiểm tra trực tiếp các tờ phiếu (dạng hình ảnh), tốn kém thời gian, nhân cơng. Đó là lý do tại sao phải viết các chương trình kiểm tra logic nhúng được vào bên trong và chạy đồng thời với các module của hệ thống ReadSoft FORMS. Các chương trình viết kiểu “nhúng” này làm cho trong quy trình xử lý chỉ có một công đoạn kiểm tra, mỗi tờ phiếu được kiểm tra cùng lúc theo mọi khía cạnh: những trường khơng nhận dạng được, nhận dạng sai, sai các thuộc tính/các thiết lập đã xác định bởi phần mềm FORMS cũng như những kiểm tra logic viết bằng các ngôn ngữ lập trình bên ngồi.
Chương trình kiểm tra logic số liệu điều tra BĐDS trong hệ thống ICR FORMS được viết bằng Visual Basic. Chương trình kiểm tra logic viết trong hệ thống này đã đưa vào tất cả những kiểm tra cần thiết tương đương với những quy định kiểm tra đã viết trong chương trình nhập tin và chương trình kiểm tra logic trong hệ thống nhập tin truyền thống. Ngồi ra, chương trình kiểm tra logic viết cho hệ thống ICR còn phải bổ sung thêm rất nhiều kiểm tra để đảm
trong các phần mềm thiết kế chương trình nhập tin, hệ thống có những cơ chế đơn giản để đảm bảo những vấn đề này, còn trong dữ liệu trong hệ thống ICR trước khi chuyển đổi ra ngồi là những ơ điền dữ liệu rời rạc.
Sau những lúng túng ban đầu, đến nay các cán bộ trong nhóm đã khá có kinh nghiệm trong việc viết các kiểm tra “nhúng” vào hệ thống ICR. Tuy vậy, vẫn còn những vấn đề chưa nghiên cứu được (hoặc có thể có cả những vấn đề khơng thể giải quyết được do đặc thù của hệ thống phần mềm ICR). Đó là những vấn đề sau:
- Chưa nghiên cứu được cách dịch các chương trình “nhúng” ra các dạng file thực hiện (EXE, DLL,...) mà vẫn đang chạy bằng chương trình nguồn;
- Các kiểm tra logic đều viết ở dạng lỗi (bắt buộc phải sửa), chưa viết được theo kiểu dạng cảnh báo;
- Mới chỉ viết được các chương trình kiểm tra logic tích hợp với module VERIFY, với các module khác chưa tìm được cách “nhúng” các chương trình viết thêm để quản lý luồng dữ liệu mềm dẻo theo yêu cầu riêng.