Định nghĩa di chuyển dữ liệu Phương pháp tổ chức di chuyển dữ liệu. Các vấn đề được xác định khi xây dựng kế hoạch làm việc và liên lạc ở giai đoạn di chuyển dữ liệu

Gửi công việc tốt của bạn trong cơ sở kiến ​​thức thật đơn giản. Sử dụng mẫu dưới đây

Các sinh viên, nghiên cứu sinh, các nhà khoa học trẻ sử dụng nền tảng kiến ​​thức trong học tập và công việc sẽ rất biết ơn các bạn.

Đăng trên http:// www. mọi điều tốt đẹp nhất. ru/

Giới thiệu

1. Di chuyển dữ liệu trong các dự án triển khai CIS

1.1 Mục tiêu và chiến lược của quá trình di chuyển dữ liệu trong các dự án triển khai IS

1.2 Các giai đoạn của quá trình di chuyển dữ liệu trong các dự án triển khai IS

1.3 Các tính năng của việc phát triển các yêu cầu kinh doanh để di chuyển dữ liệu

1.4 Đặt nhiệm vụ phát triển phương pháp di chuyển dữ liệu

2. Phân tích kinh nghiệm dự án trong việc di chuyển dữ liệu

2.1 Mô tả ngắn gọn về dự án triển khai IP

2.2 Các vấn đề được xác định khi xây dựng kế hoạch làm việc và liên lạc ở giai đoạn di chuyển dữ liệu

2.3 Các vấn đề được xác định khi phát triển các yêu cầu dỡ hàng khỏi hệ thống nguồn

2.4 Các vấn đề được xác định trong việc ghi lại các yêu cầu di chuyển dữ liệu

2.5 Các vấn đề được xác định khi kiểm tra dữ liệu được tải vào hệ thống nhận

3. Phương pháp tổ chức di chuyển dữ liệu

3.1 Trình tự các bước tổ chức di chuyển dữ liệu

3.2 Đánh giá việc áp dụng phương pháp đã xây dựng để tổ chức và thực hiện di chuyển dữ liệu

Phần kết luận

Danh sách các nguồn được sử dụng

Các ứng dụng

Giới thiệu

Nghiên cứu về các vấn đề trong việc triển khai các dự án triển khai hệ thống thông tin doanh nghiệp có liên quan đến nghiên cứu khả thi do sự quan tâm ngày càng tăng của khách hàng đối với các dự án triển khai CIS, mục đích của dự án này là thay thế các hệ thống thông tin hiện có, điều này đã được CNews Analytics xác nhận. Các nhà phân tích của CNews lưu ý các đặc điểm và xu hướng sau trong hành vi của khách hàng:

· Quan tâm đến chất lượng kết quả dự án;

· Tập trung vào các dự án tối ưu hóa quy trình kinh doanh hiện có, bao gồm thông qua cải tiến các công cụ tự động hóa hiện có;

· Tăng cường sự quan tâm của khách hàng đến chất lượng quản lý dự án triển khai IS.

Một lý do khác để nghiên cứu là các chỉ số chất lượng của các dự án đã hoàn thành. Theo ấn phẩm phân tích PCWeek, có tới 75% dự án CNTT thất bại.

Hiện nay, khá nhiều khách hàng đã triển khai hệ thống thông tin nên việc di chuyển dữ liệu là một phần không thể thiếu trong các dự án như vậy. Kết quả của giai đoạn di chuyển dữ liệu có tác động đến các giai đoạn tiếp theo của dự án và theo quy định, chúng là điều kiện để hệ thống được chấp nhận vận hành thương mại.

Di chuyển dữ liệu là một phần bắt buộc của hầu hết các dự án. Đặc biệt, theo luật pháp của Liên bang Nga, việc phân tích chi tiết về lĩnh vực này sẽ được thực hiện sau, các tổ chức khu vực công không có cơ hội từ chối một phần dữ liệu lịch sử và được yêu cầu chuyển giao lưu trữ điện tử sang hệ thống thông tin mới. Trong trường hợp các tổ chức phi chính phủ, quá trình làm việc với dữ liệu lịch sử có thể được điều chỉnh bởi các chính sách và quy định nội bộ của công ty cũng như chính sách của khách hàng của các tổ chức này. Vì vậy, các vấn đề nảy sinh ở giai đoạn di chuyển dữ liệu lịch sử là có liên quan và có thể trở thành tài liệu cho các nghiên cứu sâu hơn về chủ đề này.

Khi xem xét các tài liệu phân tích về các vấn đề di chuyển dữ liệu, mâu thuẫn hiện có sau đây trở nên rõ ràng: các giải pháp phần mềm tư nhân và tài liệu phương pháp luận trong lĩnh vực di chuyển dữ liệu đang được phát triển, nhưng đồng thời không có cách tiếp cận chung để phát triển các yêu cầu cho quá trình di chuyển. Có một số phát triển thực tế từ các nhà cung cấp phần mềm hàng đầu thế giới, chẳng hạn như IBM Best Practices hoặc Oracle White paper, nhưng không có cách tiếp cận tổng quát nào để tổ chức di chuyển dữ liệu có tính đến sự đa dạng về đặc điểm của khách hàng và dự án. Theo đó, chúng ta có thể giả định rằng vấn đề nghiên cứu đề xuất chưa được nghiên cứu đầy đủ.

Đối tượng của nghiên cứu này là các dự án hiện đại hóa hoặc thay thế các hệ thống thông tin đã được triển khai.

Đối tượng của nghiên cứu là giai đoạn di chuyển dữ liệu trong các dự án nhằm thay thế các hệ thống thông tin hiện có và các phương pháp tổ chức công việc ở giai đoạn này của dự án.

Mục tiêu của công việc là phát triển phương pháp tổ chức quá trình di chuyển dữ liệu từ hệ thống thông tin vận hành sang hệ thống thông tin đang được triển khai. Mục tiêu chung của công việc có thể được trình bày chi tiết có tính đến các giai đoạn di chuyển dữ liệu, cụ thể là: đề xuất các phương pháp lập kế hoạch cho giai đoạn di chuyển dữ liệu, mô tả phương pháp phát triển các yêu cầu di chuyển dữ liệu, phát triển các phương pháp thử nghiệm và đánh giá kết quả của quá trình di chuyển dữ liệu. giai đoạn di chuyển dữ liệu.

Luận án sau đây được coi là giả thuyết nghiên cứu: có thể phát triển phương pháp tổ chức giai đoạn di chuyển dữ liệu, điều này sẽ nâng cao chất lượng phát triển các yêu cầu nghiệp vụ cho quá trình di chuyển và giảm khả năng “kích hoạt” rủi ro của giai đoạn này.

Để đạt được mục tiêu nghiên cứu, cần giải quyết thống nhất các vấn đề nghiên cứu sau:

1. Xác định những điểm nghẽn nhất trong quá trình di chuyển gây rủi ro cho doanh nghiệp.

2. Phân tích các phương pháp hiện có để di chuyển dữ liệu, các phương pháp hay nhất của các nhà cung cấp phần mềm để di chuyển dữ liệu.

3. Xác định các đặc điểm của khách hàng ảnh hưởng đến việc tổ chức di chuyển dữ liệu và hình thành gói yêu cầu về di chuyển dữ liệu.

4. Xác định các vấn đề kinh doanh phát sinh trong quá trình di chuyển dữ liệu mà các công cụ tự động hóa hiện có không thể giải quyết được;

5. Phát triển phương pháp tổ chức quá trình di chuyển dữ liệu sẽ loại bỏ các vấn đề kinh doanh đã xác định ở tất cả các giai đoạn di chuyển (lập kế hoạch, thu thập yêu cầu, thiết kế, triển khai, thử nghiệm);

6. Đánh giá các phương pháp và phương pháp tổ chức và tiến hành di chuyển dữ liệu đã phát triển.

Là điều kiện tiên quyết để tiến hành nghiên cứu, nhu cầu di chuyển dữ liệu tích lũy trong hệ thống hiện có sang hệ thống mới được chấp nhận. Việc thực hiện giai đoạn công việc này không bắt buộc trong tất cả các dự án, nhưng vì mục đích của nghiên cứu này, cần giả định rằng khách hàng có nhu cầu như vậy.

Làm cơ sở lý thuyết cho nghiên cứu, chúng tôi sử dụng phương pháp phát triển yêu cầu do K. Wiegers xây dựng trong cuốn sách “Phát triển yêu cầu phần mềm”, cũng như các nguyên tắc cơ bản của phương pháp MSF, phương pháp giải quyết các vấn đề thiết kế ở giai đoạn di chuyển dữ liệu , được nêu trong Sách Trắng của các hãng phần mềm IBM, Oracle, Microsoft.

Kết quả của công việc phải là một phương pháp tổ chức quá trình di chuyển dữ liệu. Kết quả mong đợi của công việc là mới, vì mỗi dự án di chuyển dữ liệu có những đặc điểm riêng, đồng thời, phương pháp được phát triển sẽ cho phép tính đến các đặc điểm đó của dự án và san bằng các rủi ro tiềm ẩn của dự án.

Đặc biệt, một bộ công cụ để lập kế hoạch và cấu trúc công việc của giai đoạn di chuyển dữ liệu sẽ được đề xuất, cũng như một số phương pháp phát triển các yêu cầu phần mềm cụ thể cho giai đoạn di chuyển dữ liệu. Một bộ công cụ như vậy sẽ được cung cấp cho từng giai đoạn di chuyển dữ liệu.

Kết quả mong đợi của công việc là một phương pháp tổ chức di chuyển dữ liệu, sẽ được thử nghiệm trong một tổ chức khách hàng thuộc một loại hình nhất định (doanh nghiệp nhà nước).

Kết quả thu được có thể được sử dụng khi tổ chức các dự án bao gồm di chuyển dữ liệu.

Các cách tiếp cận và phương pháp do tác giả đề xuất để giải quyết các vấn đề thiết kế có thể là một cách để giảm thiểu rủi ro cho khách hàng doanh nghiệp phát sinh từ các lỗi xảy ra trong quá trình di chuyển dữ liệu từ IS đang vận hành sang IS đã triển khai.

Cấu trúc của công việc bao gồm việc mô tả tuần tự các giai đoạn giải quyết các nhiệm vụ nghiên cứu. Phần đầu tiên của công việc sẽ cung cấp cái nhìn tổng quan về các phương pháp di chuyển dữ liệu hiện có. Phần thứ hai của công việc sẽ được dành để phân tích lĩnh vực chủ đề của dự án, cũng như xác định các vấn đề điển hình ở giai đoạn di chuyển dữ liệu không thể giải quyết bằng các công cụ và phương pháp hiện có được phân tích trong phần đầu tiên của công việc. Phần thứ ba của nghiên cứu sẽ mô tả trình tự các bước nhằm tối ưu hóa quá trình di chuyển dữ liệu và giải quyết các vấn đề kinh doanh được xác định trong phần thứ hai của công việc. Trong phần thứ ba của công việc, việc đánh giá phương pháp tổ chức và tiến hành di chuyển dữ liệu được đề xuất sẽ được thực hiện, dựa trên việc thử nghiệm phương pháp này trong khuôn khổ một dự án thực tế.

1. Di chuyển dữ liệu trong các dự án triển khai CIS

1.1 Mục tiêu và chiến lược của quá trình di chuyển dữ liệu trong các dự án triển khai IS

Di chuyển dữ liệu là quá trình truyền thông tin khi thay đổi hệ thống thông tin, lưu trữ hoặc thay đổi phiên bản ứng dụng. Quá trình di chuyển dữ liệu thường là một phần của một trong các giai đoạn của dự án triển khai hệ thống thông tin doanh nghiệp, nhưng việc thực hiện quá trình này có thể là mục tiêu của một dự án riêng biệt.

Hệ thống thông tin đang triển khai phải thay thế hệ thống hoặc các hệ thống đang vận hành. Theo quy định, sau khi hoàn thành dự án triển khai CIS, hoạt động tiếp theo của các hệ thống hiện có trong tổ chức khách hàng sẽ không được lên kế hoạch. Xét về quá trình di chuyển dữ liệu, hệ điều hành hoặc các hệ thống là hệ thống nguồn. Hệ thống được triển khai là một hệ thống thu. Hệ thống được triển khai sẽ thay thế các chức năng tự động của hệ thống nguồn; theo đó, hệ thống được triển khai sẽ sử dụng dữ liệu lịch sử được tích lũy trong hai hệ điều hành.

Sự hiện diện của giai đoạn di chuyển dữ liệu trong các dự án triển khai CIS được xác định bởi các yêu cầu kinh doanh liên quan. Nhu cầu di chuyển dữ liệu phát sinh khi giải quyết một trong các trường hợp sau:

- Tạo ra một hệ thống mới do sự thay đổi cơ bản trong yêu cầu của khách hàng. Tình huống này có thể phát sinh khi có những yêu cầu quan trọng về thay đổi yêu cầu chức năng, thay đổi các yếu tố bên ngoài ảnh hưởng đến doanh nghiệp và giải pháp được sử dụng không đủ linh hoạt.

- Việc sáp nhập các đơn vị kinh doanh (phòng ban, phòng ban hoặc tổ chức) đòi hỏi phải sử dụng một hệ thống thông tin duy nhất thay vì nhiều hệ thống mà nhân viên của khách hàng đã làm việc trước đây.

- Thay đổi hạ tầng CNTT khi sử dụng CIS hiện hành. Ở đây chúng ta đang nói về nhu cầu di chuyển dữ liệu từ các hệ thống khác nhau khi tạo kho dữ liệu chung của công ty để lưu trữ dữ liệu từ các ứng dụng của công ty.

Khi giải quyết các vấn đề trên, cần xác định chiến lược di chuyển, được hướng dẫn bởi các nguyên tắc trong đó, công việc di chuyển dữ liệu sẽ được thực hiện. Các chuyên gia của Oracle xác định hai loại chiến lược: chiến lược vụ nổ lớn và chiến lược di chuyển nhỏ giọt.

Trong trường hợp đầu tiên, việc di chuyển được thực hiện đồng thời; trong quá trình di chuyển, hoạt động của hệ thống nguồn và hệ thống đích bị dừng lại. Cách tiếp cận này có vẻ hấp dẫn vì nó làm giảm thời gian cần thiết để thực hiện quá trình di chuyển, nhưng thực hiện một cuộc di chuyển “vụ nổ lớn” thường là một quyết định mạo hiểm. Trước hết, rủi ro gắn liền với những khó khăn trong hoạt động của tổ chức khi hệ thống ngừng hoạt động. Theo quy định, khách hàng doanh nghiệp từ chối dừng hệ thống thông tin. Để thực hiện quá trình di chuyển hiệu quả, bạn phải thực hiện ít nhất một lần thử nghiệm trước khi di chuyển dữ liệu thực tế. Ngoài thời gian thử nghiệm, cần phải tính đến khi lập kế hoạch về ngày di chuyển bổ sung có thể có - ngày dự trữ - cần thiết cho việc tái di chuyển trong trường hợp xảy ra lỗi đầu tiên. Rất khó để lập kế hoạch cho một quy trình như vậy mà không làm giảm đáng kể hiệu quả kinh doanh tại thời điểm di chuyển, do đó, chất lượng của dữ liệu được di chuyển theo phương pháp này thường bị ảnh hưởng do không đủ thử nghiệm và thiếu thời gian để xác thực kết quả di chuyển.

Khi sử dụng chiến lược di chuyển dữ liệu trơn tru, hệ thống nguồn và đích hoạt động song song, ứng dụng không bị treo, điều này thường được khách hàng đánh giá tích cực. Việc thực hiện phương pháp này có thể sẽ làm tăng thêm độ phức tạp cho các công cụ di chuyển, vì bạn sẽ cần theo dõi các tập dữ liệu đã được di chuyển trong thời gian thực, cũng như giám sát các thay đổi đối với dữ liệu do người dùng hệ thống nguồn thực hiện. Với quá trình di chuyển suôn sẻ, quá trình truyền dữ liệu có thể được đồng bộ hóa với quá trình chuyển đổi nhóm người dùng để làm việc với hệ thống mới. Khi các nhóm người dùng dần dần chuyển sang làm việc với hệ thống đích, hoạt động song song của cả hai hệ thống sẽ diễn ra, điều này có thể ảnh hưởng đến sự an toàn của dữ liệu được di chuyển. Những thay đổi đối với dữ liệu đã di chuyển có thể được thực hiện trong khi hai hệ thống đang chạy song song, điều này sẽ dẫn đến việc di chuyển dữ liệu này nhiều lần.

Khi xây dựng chiến lược di chuyển dữ liệu, có một số rủi ro điển hình cần được đánh giá bổ sung và có thể dẫn đến các vấn đề trong quá trình thực hiện quá trình di chuyển. Theo các chuyên gia của Oracle, các vấn đề điển hình phát sinh khi xây dựng chiến lược di chuyển dữ liệu có thể được chia thành nhiều nhóm:

1. Rủi ro khi lập quy chuẩn kỹ thuật

Đặc tả kỹ thuật cho việc di chuyển dữ liệu bao gồm mô tả về tập hợp dữ liệu, loại và định dạng cũng như các thuật toán di chuyển. Khi biên soạn tài liệu kỹ thuật cho giai đoạn di chuyển, người ta thường ít chú ý đến việc nghiên cứu tài liệu về chức năng và hỗ trợ thông tin của hệ thống nguồn. Khi xây dựng các thông số kỹ thuật, mẫu dữ liệu không mang tính đại diện hoặc không đầy đủ từ hệ thống cũ có thể được sử dụng và do đó có thể bỏ sót các chi tiết. Trọng tâm được chuyển sang các yêu cầu kỹ thuật thay vì kinh doanh cho hệ thống mới; tình huống này dẫn đến ánh xạ dữ liệu không chính xác và lỗi trong quá trình di chuyển.

2. Rủi ro khi thử nghiệm

Rủi ro của giai đoạn thử nghiệm thường liên quan đến việc thiếu thời gian; tình trạng này không chỉ phát sinh trong quá trình di chuyển dữ liệu mà còn có thể là đặc điểm của toàn bộ dự án. Giai đoạn di chuyển yêu cầu kiểm tra cẩn thận trên lượng lớn dữ liệu; kiểm tra đơn vị thường được sử dụng, kết quả của chúng có thể không đủ trong trường hợp này.

3. Rủi ro trong quá trình lấy và tải dữ liệu

Thông thường, khi di chuyển dữ liệu, bước xác thực dữ liệu nhận được từ hệ thống nguồn có thể bị bỏ sót. Sự thiếu sót này có thể dẫn đến những diễn biến không mong muốn khi tải thông tin vào hệ thống mới. Tình huống này có thể phát sinh khi có lỗi khớp nội dung và thông tin meta trong hệ thống nguồn và thuật toán di chuyển được thiết kế dựa trên siêu dữ liệu nội dung.

4. Rủi ro khi đưa dữ liệu vào hệ thống đích

Việc tải dữ liệu không chính xác trong quá trình di chuyển có thể dẫn đến những hậu quả tiêu cực sau: hoạt động không chính xác chức năng của hệ thống đích do xung đột và lỗi do dữ liệu được tải gây ra. Để giải quyết vấn đề, cần có thêm thời gian để phát triển các giải pháp thay thế nhằm giải quyết vấn đề bằng cách cải thiện chức năng của hệ thống đích, dọn dẹp hoặc chuyển đổi bổ sung dữ liệu đã tải xuống. Kết quả của những thất bại và lỗi được mô tả là làm giảm hiệu quả của IS mới, sự không hài lòng của người dùng hệ thống và tổn thất kinh doanh.

5. Rủi ro liên quan đến công việc của nhóm dự án

Giai đoạn di chuyển dữ liệu, giống như bất kỳ giai đoạn nào khác của dự án triển khai hệ thống thông tin, đòi hỏi sự phân bổ rõ ràng các vai trò trong nhóm dự án và sự tham gia của tất cả các bên quan tâm. Việc thiếu sự tham gia của người dùng doanh nghiệp đối với hệ thống mới trong quá trình di chuyển dẫn đến thiếu sót trong việc thu thập yêu cầu và làm tăng nguy cơ xảy ra lỗi. Khi phát triển các thuật toán truyền dữ liệu, cần có sự tham gia của các chuyên gia có kiến ​​thức về cấu trúc và mục đích của dữ liệu để di chuyển. Như vậy, chuyển trách nhiệm cho các kỹ thuật viên chỉ làm việc đúng mục tiêu, hệ thống mới là giải pháp phổ biến nhưng chưa hợp lý.

Xây dựng chiến lược và đánh giá rủi ro của giai đoạn di chuyển là một trong những bước quan trọng nhất khi thực hiện di chuyển dữ liệu. Kết quả của hoạt động đánh giá rủi ro và lựa chọn chiến lược là đầu vào cho giai đoạn lập kế hoạch của quá trình di chuyển.

1.2 Các giai đoạn của quá trình di chuyển dữ liệu trong các dự án triển khai IS

Quá trình di chuyển dữ liệu có thể là một trong những giai đoạn của dự án triển khai IS hoặc có thể được tổ chức thành một dự án riêng biệt. Khi nói đến quá trình di chuyển dữ liệu trong khuôn khổ công việc này, chúng tôi muốn nói đến công việc thiết kế bao gồm toàn bộ chu trình nhiệm vụ liên quan đến di chuyển dữ liệu: từ lập kế hoạch di chuyển dữ liệu đến đánh giá kết quả của giai đoạn di chuyển dữ liệu.

Trong mọi trường hợp, quá trình di chuyển dữ liệu được chia thành nhiều giai đoạn tuần tự liên kết với nhau; nghiên cứu này sẽ kiểm tra tuần tự tất cả các bước của quá trình di chuyển theo phương pháp của Oracle và IBM.

Vòng đời của quá trình di chuyển bắt đầu sau khi chiến lược được hình thành và các rủi ro của giai đoạn di chuyển dữ liệu được đánh giá. Một phác thảo về quá trình di chuyển được trình bày trong sơ đồ quy trình.

Mục tiêu của bất kỳ quá trình di chuyển dữ liệu nào là ánh xạ thông tin, kiểu dữ liệu và định dạng của hệ thống cũ với các kiểu và định dạng dữ liệu của hệ thống mới. Khi di chuyển dữ liệu, giai đoạn “Trích xuất dữ liệu” tương ứng với việc lựa chọn và dỡ bỏ dữ liệu từ hệ thống cũ và giai đoạn “Tải dữ liệu” tương ứng với việc chuyển dữ liệu nhận được từ hệ thống cũ và tải chúng vào hệ thống mới. Dưới đây, quá trình di chuyển sẽ được thảo luận chi tiết hơn.

Sau khi hoàn thành giai đoạn lập kế hoạch di chuyển dữ liệu, giai đoạn xác định các yêu cầu đối với dữ liệu được di chuyển sẽ bắt đầu. Giai đoạn này bao gồm việc phát triển các yêu cầu của khách hàng và mô tả chúng trong các tài liệu thiết kế có liên quan. Ở giai đoạn thu thập yêu cầu, vai trò chịu trách nhiệm trong nhóm dự án về kết quả của giai đoạn này là nhà phân tích kinh doanh hoặc nhà phân tích hệ thống. Giai đoạn di cư này sẽ được đề cập chi tiết hơn trong chương thứ ba của tác phẩm này. Đầu ra của giai đoạn xác định các yêu cầu dữ liệu để di chuyển là mô tả cấu trúc và thành phần của dữ liệu để di chuyển.

Theo quy luật, giai đoạn thu thập các yêu cầu dữ liệu để di chuyển có mối liên hệ rất chặt chẽ với giai đoạn tiếp theo - phát triển các thuật toán để truyền dữ liệu từ hệ thống nguồn sang hệ thống đích. Trong giai đoạn thiết kế, các nhà phân tích tạo ra các thông số kỹ thuật chi tiết mô tả các kiểu dữ liệu của hệ thống nguồn và mối quan hệ của chúng với các kiểu dữ liệu của hệ thống đích. Các thông số kỹ thuật như vậy mô tả cấu trúc dữ liệu để di chuyển, khối lượng, nguồn và mục đích của nó. Thông số kỹ thuật là nguồn để thiết lập nhiệm vụ cho nhà phát triển, người sẽ thiết kế và phát triển phần mềm chuyên dụng để truyền dữ liệu. Ở giai đoạn thiết kế, việc phân tích kiến ​​trúc dữ liệu hiện có trong hệ thống nguồn được thực hiện - phân tích “nguyên trạng” và phát triển kiến ​​trúc dữ liệu trong hệ thống đích - “to be”. Khi phân tích kiến ​​trúc dữ liệu hiện có, tất cả các hạn chế trong cơ sở hạ tầng CNTT đều được xác định và tính đến, cũng như tác động của chúng đối với hoạt động của hệ thống mục tiêu với dữ liệu được di chuyển. Sản phẩm đầu ra của phân tích kiến ​​trúc dữ liệu có thể là các tài liệu như mô hình dữ liệu logic (sơ đồ ER, mô hình cơ sở dữ liệu), từ điển và sách tham khảo có mô tả chi tiết từng thành phần và thuộc tính của nó, mô tả các quy tắc nghiệp vụ để làm việc với dữ liệu, thông tin về hệ thống. tương tác với hệ thống nguồn để trao đổi và tích hợp thông tin.

Kết quả thu thập và thiết kế yêu cầu là cơ sở để lựa chọn phương pháp và xác định công nghệ di chuyển dữ liệu. Việc di chuyển có thể được thực hiện ngoại tuyến hoặc trực tuyến và việc phân loại các phương pháp phụ thuộc vào việc ứng dụng có được duy trì trong quá trình di chuyển hay không. Việc lựa chọn phương pháp và phương tiện di chuyển được xác định bởi sự kết hợp của nhiều yếu tố, bao gồm thời gian ngừng hoạt động của hệ thống sẵn có, sự phụ thuộc kinh doanh vào đối tác, khối lượng dữ liệu, vị trí vật lý lưu trữ dữ liệu của hệ thống nguồn, chính sách bảo mật thông tin của hệ thống nguồn và hệ thống đích.

Các giai đoạn phân tích và lập kế hoạch được mô tả ở trên có thể được kết hợp thành giai đoạn chuẩn bị chung. Các quy trình và cơ chế di chuyển được phát triển quy định các giai đoạn trích xuất, truyền và tải dữ liệu vào hệ thống mới, nghĩa là tất cả các bước của quy trình ETL đều được thực hiện tuần tự. Sau khi nhận được dữ liệu cần thiết cho quá trình di chuyển, giai đoạn tải dữ liệu này vào hệ thống đích sẽ bắt đầu, trước đó cần làm nổi bật một giai đoạn riêng - xác minh nội dung được di chuyển.

Việc kiểm tra tính tuân thủ của dữ liệu đã tải xuống với các yêu cầu có thể diễn ra trực tuyến - trực tiếp tại lối vào hệ thống thông tin mục tiêu hoặc ngoại tuyến - như một bước trung gian trong quá trình di chuyển. Sau khi hoàn tất việc tải dữ liệu vào hệ thống đích, một cuộc kiểm tra bổ sung sẽ được thực hiện, thường thì cả hai hệ thống đều được khởi chạy để hoạt động song song. Các hoạt động kiểm thử cho công việc song song được lên kế hoạch khi thiết kế các quy tắc và thủ tục của quá trình di chuyển. Là một phần của quá trình di chuyển, hoạt động song song của hai hệ thống có thể được coi là hoạt động thử nghiệm. Kết quả của hoạt động thử nghiệm có thể là sự xác nhận về chức năng đầy đủ của hệ thống mới với dữ liệu được di chuyển. Nếu phát hiện thấy lỗi lớn trong quá trình hoạt động song song của hệ thống nguồn và đích, quyết định có thể được đưa ra là di chuyển lại dữ liệu và tải lại nội dung. Các kết quả di chuyển đã thống nhất được ghi lại trong nhật ký vận hành thử nghiệm của hệ thống đích với dữ liệu được tải, các trường hợp thử nghiệm đã hoàn thành và bảng câu hỏi có thể được biên soạn để kiểm tra xem dữ liệu được di chuyển có đáp ứng các yêu cầu của hệ thống đích hay không.

Hoạt động thử nghiệm không giới hạn ở hoạt động song song của hệ thống nguồn và hệ thống đích. Các thử nghiệm có thể được thực hiện trên các mẫu từ dữ liệu được di chuyển để sớm xác định lỗi và sửa chúng trước khi bắt đầu phát triển phần mềm di chuyển. Việc loại bỏ lỗi trước đó cho phép bạn tiết kiệm ngân sách và tránh phải tải xuống dữ liệu nhiều lần. Hoạt động kiểm tra có thể bao gồm các hoạt động kiểm tra dữ liệu trong quá trình di chuyển. Kiểm tra dữ liệu cho phép bạn theo dõi trạng thái của dữ liệu và tránh các lỗi do những thay đổi về nội dung có thể được thực hiện bởi người dùng trong quá trình di chuyển.

Sau khi thống nhất về kết quả di chuyển, giai đoạn công việc sau di chuyển bắt đầu, bao gồm kiểm tra, làm sạch và kiểm tra hiệu suất của hệ thống đích nói chung sau khi di chuyển dữ liệu. Việc làm sạch có thể được thực hiện thủ công hoặc sử dụng phần mềm. Làm sạch dữ liệu được thực hiện để loại bỏ những thông tin lỗi thời và đáp ứng các yêu cầu hỗ trợ thông tin của hệ thống mới.

Phương pháp di chuyển dữ liệu nêu trên giả định rằng nút thắt lớn nhất trong việc tổ chức giai đoạn này của dự án là giai đoạn lập kế hoạch và làm việc với các yêu cầu kinh doanh của khách hàng, tức là thu thập yêu cầu và thiết kế, vì vậy chúng tôi sẽ xem xét các cách tiếp cận để giải quyết các vấn đề của các giai đoạn này chi tiết hơn trong các phần sau của tác phẩm. Ngoài các giai đoạn lập kế hoạch và phát triển yêu cầu nghiệp vụ, cần đặc biệt chú ý đến giai đoạn đánh giá kết quả công việc ở giai đoạn di chuyển dữ liệu, vì theo chu trình Deming (PDCA), đó là việc thực hiện đánh giá công việc. hoạt động là điều kiện thành công khi thực hiện công việc tương tự trong các dự án tương tự.

1.1. Đặc điểm của lập kế hoạch di chuyển dữ liệu

Lập kế hoạch di chuyển dữ liệu là giai đoạn đầu tiên của vòng đời quy trình và được thực hiện có tính đến sự hiểu biết về các rủi ro chính của quy trình và chiến lược di chuyển. Ngoài chiến lược di chuyển, thông tin đầu vào có thể là một phần của đặc tả kỹ thuật hoặc tài liệu về toàn bộ khung dự án dành riêng cho việc di chuyển dữ liệu. Ở giai đoạn lập kế hoạch, khuôn khổ của quy trình di chuyển dữ liệu được xác định và các mục tiêu của quy trình di chuyển dữ liệu có thể đạt được theo các ràng buộc thiết kế (nguồn dữ liệu, yêu cầu cấp cao nhất) được thiết lập. Để xác định phạm vi của quá trình di chuyển, nên thu hút người dùng doanh nghiệp hiểu biết về cách hệ thống đã hoạt động với dữ liệu trong quá khứ và cách hệ thống sẽ hoạt động với dữ liệu đó trong tương lai. Tiếp theo, tùy thuộc vào phương pháp di chuyển, thời hạn được đặt ra và các nguồn lực cần thiết được phân bổ trong ngân sách nhất định. Khi lập kế hoạch di chuyển dữ liệu, một điểm quan trọng là xác định những người tham gia quy trình từ phía khách hàng, tức là những người dùng doanh nghiệp và chuyên gia kỹ thuật của khách hàng chịu trách nhiệm quản lý dữ liệu. Ở đầu ra của quá trình lập kế hoạch quá trình di chuyển dữ liệu, có thể tạo ra các tạo phẩm thiết kế sau:

Tài liệu khung di chuyển dữ liệu;

Kế hoạch di chuyển dữ liệu chỉ rõ các thành viên chịu trách nhiệm của nhóm dự án;

Kế hoạch liên lạc trong giai đoạn di chuyển.

Việc tổ chức giai đoạn di chuyển trong các dự án triển khai IS bắt đầu từ giai đoạn lập kế hoạch, trong đó cần lập kế hoạch làm việc, tính toán các nguồn lực và thời hạn cần thiết.

Các gói công việc ở giai đoạn di chuyển phải tương ứng với các giai đoạn của vòng đời quy trình; cấu trúc gần đúng của lịch trình công việc có thể như sau:

Lập kế hoạch và xác định phạm vi di chuyển dữ liệu;

Phân tích kinh doanh và tài liệu về các yêu cầu;

Lựa chọn, cấu hình hoặc thiết kế và phát triển phần mềm chuyên dụng;

Truyền dữ liệu;

Xác thực dữ liệu di chuyển;

Vận hành thử;

Hoạt động kiểm tra và làm sạch sau di chuyển;

Điều phối kết quả di chuyển, đánh giá và kết thúc giai đoạn thực hiện dự án.

Việc bổ nhiệm các thành viên chịu trách nhiệm của nhóm dự án để thực hiện các gói công việc của giai đoạn di chuyển dữ liệu diễn ra ở giai đoạn lập kế hoạch sau khi lập kế hoạch làm việc.

Các vai trò dự án đã chọn được khớp với các cụm - lĩnh vực trách nhiệm được xác định trong phương pháp MSF. Điều đáng lưu ý riêng là bằng cách quản lý sản phẩm trong bối cảnh di chuyển, chúng ta sẽ hiểu việc quản lý chất lượng của dữ liệu được di chuyển và hiệu suất của hệ thống mục tiêu sau khi di chuyển. Quản lý phát hành về mặt quy trình di chuyển - thực hiện các bước lặp của quá trình di chuyển, nhận và tải dữ liệu di chuyển.

Theo mô hình MSF, giả định phân bổ các lĩnh vực trách nhiệm sau đây giữa các cụm vai trò:

System Analyst - quản lý chương trình, sự hài lòng của khách hàng;

Giám đốc phát triển - quản lý chương trình, quản lý sản phẩm, quản lý phát hành;

Nhà phát triển - phát triển các thuật toán hoặc phần mềm chuyên dụng để truyền dữ liệu đến Hệ thống đích, phần mềm chuyên dụng (nếu cần);

Người kiểm tra - kiểm tra, quản lý phát hành.

Để thể hiện rõ sự tham gia của các nguồn nhân lực liên quan vào các hoạt động của quá trình di chuyển dữ liệu, chúng tôi sẽ xây dựng ma trận RACI - được nêu tại Phụ lục 1 của công trình (xem Phụ lục 1 - Ma trận RACI cho công việc di chuyển dữ liệu).

Cần lưu ý rằng người quản lý phát triển (giám đốc kỹ thuật) được coi là người đứng đầu nhóm tham gia di chuyển dữ liệu nên chịu trách nhiệm thực hiện toàn bộ quá trình. Tuy nhiên, nếu việc di chuyển dữ liệu được thực hiện như một phần của dự án triển khai IS quy mô lớn, trong đó người quản lý toàn bộ dự án được chỉ định thì người quản lý kỹ thuật của giai đoạn di chuyển sẽ chỉ là người thực hiện các nhiệm vụ liên quan đến xác định thời hạn và tuyển dụng. nhân viên. Trong trường hợp này, các quyết định về nhân sự, nguồn lực và thời hạn đều do ban quản lý dự án đưa ra.

1.3 Đặc điểm của việc phát triển các yêu cầu kinh doanh đối với việc di chuyển dữ liệu

Giai đoạn phát triển các yêu cầu kinh doanh trong quá trình di chuyển dữ liệu là chìa khóa trong việc chuẩn bị các công cụ truyền dữ liệu và chất lượng của toàn bộ quá trình di chuyển sẽ phụ thuộc vào mức độ thu thập và phân tích các yêu cầu của người dùng doanh nghiệp.

Các yêu cầu di chuyển dữ liệu có thể được nắm bắt trong các tạo phẩm thiết kế khác nhau và hướng dẫn phát triển các tạo phẩm thiết kế đó sẽ được cung cấp trong Chương 3.

Các tiêu chuẩn khác nhau có thể dùng làm cơ sở phương pháp luận để tổ chức công việc dự án nhằm xác định và phát triển các yêu cầu kinh doanh cho việc di chuyển dữ liệu. Trong nghiên cứu này, cơ sở lý thuyết cho phân tích kinh doanh là cách tiếp cận của Karl Wiegers.

Trước tiên, hãy xem xét việc sử dụng các công cụ do Wiegers đề xuất để lập mô hình yêu cầu kinh doanh trong bối cảnh phát triển các yêu cầu về di chuyển dữ liệu.

Hãy xem việc áp dụng phương pháp tiếp cận của Wiegers để phát triển các yêu cầu di chuyển dữ liệu dưới đây. Các yêu cầu di chuyển dữ liệu được xác định song song với việc phát triển các yêu cầu chức năng cho hệ thống đã triển khai. Trong quá trình phát triển các yêu cầu chức năng, các bộ dữ liệu đầu vào cho quy trình kinh doanh tự động được chỉ định, do đó, các yêu cầu kinh doanh cấp cao nhất về thành phần dữ liệu được di chuyển có thể được chỉ định.

Wigers đề xuất sử dụng sơ đồ ER (sơ đồ mối quan hệ thực thể) để xác định cấu trúc logic của một lĩnh vực chủ đề. Sơ đồ mối quan hệ thực thể được sử dụng để xây dựng mô hình dữ liệu miền. Cấu trúc dữ liệu logic (mô hình dữ liệu khái niệm - CDM) cho phép mô tả vùng chủ đề của hệ thống dưới dạng các đối tượng dữ liệu (thực thể).

Theo Wiegers, việc sử dụng mô hình dữ liệu dưới dạng sơ đồ ER giúp tạo điều kiện thuận lợi cho quá trình xác định các yêu cầu tổ chức cấu trúc dữ liệu trong hệ thống được thiết kế do cách trình bày mô hình rõ ràng và tương đối đơn giản. Bằng cách làm việc với sơ đồ ER “nguyên trạng”, người dùng doanh nghiệp chính sẽ có thể xác định danh sách các đối tượng dữ liệu cần được chuyển từ hệ thống nguồn sang hệ thống thu đích.

Ngoài sơ đồ mối quan hệ thực thể, một công cụ mô hình hóa khác có thể được sử dụng trong quá trình xác định các yêu cầu di chuyển dữ liệu - sơ đồ chuyển đổi trạng thái hoặc sơ đồ chuyển đổi trạng thái. Sơ đồ chuyển trạng thái cung cấp cái nhìn chính xác, đầy đủ và rõ ràng về cơ chế trạng thái hữu hạn. Sơ đồ chuyển trạng thái là một phần của phương pháp mô hình hóa - UML (ngôn ngữ mô hình hóa thống nhất) và cho phép bạn hình dung vòng đời của các đối tượng dữ liệu. Việc chuyển đổi sang từng giai đoạn tiếp theo của vòng đời được xác định bởi một bộ quy tắc kinh doanh cụ thể. Khi phát triển mô hình như vậy trong quá trình xây dựng các yêu cầu chức năng cho hệ thống thông tin đang được thiết kế, cần tiến hành phân tích so sánh mô hình đó với mô hình tương tự cho hệ điều hành. Khi nâng cấp IS, một số trạng thái của đối tượng dữ liệu có thể được thay đổi hoặc loại trừ và các quy tắc thay đổi trạng thái có thể được thay đổi. Những trường hợp như vậy phải được tính đến khi phát triển các yêu cầu di chuyển để xác định chính xác trạng thái nào các đối tượng dữ liệu sẽ được chuyển sang hệ thống nhận. Ngoài ra, các yêu cầu di chuyển dữ liệu phải tính đến sự không nhất quán về mặt logic có thể phát sinh do hiện đại hóa các quy tắc chuyển đổi trạng thái. Ví dụ: việc chuyển đổi một đối tượng dữ liệu sang trạng thái tiếp theo có thể phụ thuộc vào sự hoàn thành hoặc giá trị của một số thuộc tính thực thể. Khi phát triển các yêu cầu cho hệ thống tiếp nhận, thành phần thuộc tính của các thực thể có thể được thay đổi theo cách loại trừ thuộc tính này. Trong trường hợp này, việc thay đổi trạng thái của thực thể được di chuyển sẽ không thể thực hiện được. Theo đó, những trục trặc, sai sót sẽ xảy ra trong chức năng của hệ thống tiếp nhận. Để tránh những lỗi như vậy, mỗi trường hợp thay đổi trong thành phần thuộc tính phải được xác định và các yêu cầu di chuyển dữ liệu phải phản ánh quy tắc hoặc kiểm tra logic để xử lý tình huống đó. Ví dụ về sơ đồ trạng thái được phát triển cho một trong các thực thể trong hệ thống tiếp nhận được đưa ra trong Phụ lục 3 của tác phẩm (xem Phụ lục 3 - Ví dụ về sơ đồ vòng đời của các thực thể trong hệ thống nguồn).

Ở trên đã thảo luận về việc sử dụng các công cụ phân tích kinh doanh để xác định các yêu cầu cấp cao cho việc di chuyển dữ liệu. Bây giờ chúng tôi sẽ phân tích chi tiết hơn cơ sở phương pháp luận cho một nghiên cứu chi tiết về nhu cầu kinh doanh: đặc biệt là phát triển các yêu cầu đối với hồ sơ dữ liệu được di chuyển.

Khi tương tác với khách hàng về việc lập hồ sơ dữ liệu để di chuyển yêu cầu, nhà phân tích cần thu thập thông tin về các vấn đề sau:

1. Nguồn dữ liệu là gì: ứng dụng doanh nghiệp, hệ thống hoặc nguồn bên ngoài tổ chức khách hàng?

2. Dữ liệu được di chuyển có phải là đầu vào cho bất kỳ quy trình kinh doanh nào không?

3. Các yêu cầu về dữ liệu của hệ thống mục tiêu là gì? Những quy trình nào trong hệ thống mới sẽ sử dụng dữ liệu này? Cấu trúc dữ liệu có cho phép bạn làm việc với nó một cách chính xác trong IS mục tiêu không (có thể tương quan giữa cấu trúc của dữ liệu đã di chuyển và mô hình dữ liệu đích) không? Có trường và loại nào trong cấu trúc dữ liệu không thể điền vào cấu trúc đích và ngược lại không?

4. Chất lượng của dữ liệu là gì? Mức độ chất lượng dữ liệu hiện tại có đáp ứng được mức độ cần thiết cho hoạt động của hệ thống mục tiêu không? Có bất kỳ lỗi nghiêm trọng nào không (ví dụ: các trường bắt buộc bị bỏ trống, kiểu dữ liệu không khớp giữa hệ thống nguồn và hệ thống đích). Có cần xây dựng các quy trình để cải thiện chất lượng dữ liệu trước khi quá trình di chuyển dữ liệu bắt đầu không?

5. Thông tin meta của nội dung được di chuyển có cho phép chúng tôi phát triển các thuật toán di chuyển không? Có thể phân tích cấu trúc dữ liệu dựa trên siêu thông tin hay cần phải phân tích chính nội dung dự định di chuyển?

6. Đánh giá mức độ nghiêm trọng của lỗi khi truyền dữ liệu về hệ thống đích. Dữ liệu này sẽ được sử dụng trong giao diện người dùng hay nó có đủ để xác thực nó ở cấp cơ sở dữ liệu không?

7. Dữ liệu được chọn có liên quan đến dữ liệu lịch sử không? Trong một khoảng thời gian đã chọn (ví dụ: một năm hoặc 5 năm), có những thay đổi đáng kể nào trong quy trình kinh doanh có thể dẫn đến những thay đổi về cấu trúc hoặc hình thức lưu trữ của thành phần mô hình dữ liệu đã chọn không?

8. Các quy tắc kinh doanh để làm việc với dữ liệu đã chọn là gì?

9. Ai là chủ sở hữu dữ liệu (nội dung, tài liệu, hình ảnh) và ai chịu trách nhiệm về tính an toàn, chất lượng của dữ liệu được lựa chọn?

10. Những hạn chế nào của hệ thống nguồn được thể hiện ở cấu trúc dữ liệu, hình thức lưu trữ và thao tác với dữ liệu? Những hạn chế này có được áp dụng khi làm việc với dữ liệu trên hệ thống đích không?

11. Có cần hỗ trợ di chuyển dữ liệu trực tuyến không?

12. Dữ liệu được di chuyển có bị thay đổi trong quá trình di chuyển không? Có cần thực hiện quá trình tải lên và tải dữ liệu lặp đi lặp lại không?

Các nhu cầu kinh doanh đã xác định phải được ghi lại và mô tả dưới dạng một gói yêu cầu di chuyển. Mối quan hệ giữa nhu cầu kinh doanh và yêu cầu chức năng được quan sát thấy khi các yêu cầu chức năng có thể theo dõi được.

Ngoài các công cụ để mô hình hóa miền và quy trình kinh doanh, Wiegers còn chú ý đáng kể đến khái niệm như vậy khi làm việc với các yêu cầu kinh doanh như “khả năng truy xuất nguồn gốc” của các yêu cầu. Truy xuất nguồn gốc yêu cầu cũng có nghĩa là có thể theo dõi mối quan hệ của các yêu cầu cấp cao nhất được ghi trong khái niệm dự án hoặc thông số kỹ thuật với các yêu cầu chi tiết hơn cho các hệ thống con và mô-đun được ghi trong thông số kỹ thuật và chức năng.

Khi phát triển các yêu cầu về di chuyển dữ liệu, khả năng truy xuất nguồn gốc của các yêu cầu cũng phải được tôn trọng. Các yêu cầu cấp cao nhất, phản ánh nhu cầu và chiến lược di chuyển, được ghi lại trong tài liệu về phạm vi dự án triển khai IS hoặc các điều khoản tham chiếu. Nhu cầu di chuyển dữ liệu từ hệ điều hành sang hệ thống được thiết kế của doanh nghiệp được bắt nguồn từ gói yêu cầu di chuyển: thành phần của dữ liệu được di chuyển, phương pháp di chuyển, các quy tắc cụ thể và kịch bản di chuyển, được mô tả trong điều khoản tham chiếu dành cho việc triển khai IS hoặc thông số kỹ thuật của quá trình di chuyển.

Một công cụ để theo dõi khả năng truy xuất nguồn gốc của các yêu cầu theo Wiegers có thể là ma trận truy xuất nguồn gốc các yêu cầu. Sử dụng ma trận truy xuất nguồn gốc, bạn có thể hình dung mối quan hệ giữa các yêu cầu đối với phần mềm đang được phát triển.

Phụ lục 2 của tác phẩm (Phụ lục 2 - Ví dụ về các yêu cầu theo dõi đối với việc di chuyển dữ liệu) trình bày một ví dụ - một đoạn của ma trận được biên soạn về khả năng truy xuất nguồn gốc của các yêu cầu đối với việc di chuyển dữ liệu.

Đoạn ma trận sau đây thể hiện các loại nhu cầu khác nhau của người dùng:

· Yêu cầu phi chức năng đối với phương pháp di chuyển;

· Yêu cầu trực tiếp về chức năng của tiện ích di chuyển dữ liệu;

· Yêu cầu nghiệp vụ đối với chức năng của hệ thống được thiết kế, liên quan đến các yêu cầu chức năng đối với tiện ích di chuyển.

Không có trường hợp thử nghiệm nào trong dòng đầu tiên của ví dụ, vì nhu cầu của người dùng này được bắt nguồn từ kế hoạch làm việc di chuyển dữ liệu chứ không phải đến một thành phần cụ thể của tiện ích di chuyển. Wiegers cho phép những trường hợp ngoại lệ như vậy khi biên soạn các ma trận truy xuất nguồn gốc yêu cầu. Yêu cầu cấp cao là thông tin đầu vào khi lập kế hoạch cho công việc của giai đoạn di chuyển. Khi lập kế hoạch truyền thông dự án, nhà phân tích hệ thống và người quản lý kỹ thuật không chỉ nên chọn các chuyên gia kỹ thuật mà còn cả người dùng doanh nghiệp, cả hệ thống nguồn và hệ thống đích, để tiến hành khảo sát.

Các nhu cầu khác của người dùng và yêu cầu chức năng được liệt kê trong ma trận truy xuất nguồn gốc là những ví dụ chung về các yêu cầu kinh doanh được phát triển như một phần của dự án di chuyển cụ thể. Các đặc điểm của dự án này cũng như phân tích chi tiết về trải nghiệm dự án di chuyển dữ liệu sẽ được thực hiện trong Chương 2.

1.4 Đặt nhiệm vụ phát triển phương pháp di chuyển dữ liệu

Kết quả mong đợi của công việc phải là một phương pháp tổ chức và tiến hành di chuyển dữ liệu. Phương pháp như vậy phải bao gồm một chuỗi các bước có liên quan với nhau, việc thực hiện các bước này sẽ cho phép bạn lập kế hoạch, thực hiện và kiểm tra kết quả di chuyển dữ liệu.

Mỗi phần của phương pháp luận phải chứa mô tả về trình tự các hoạt động cho một giai đoạn di chuyển riêng biệt, cụ thể là: lập kế hoạch, phát triển yêu cầu, tiến hành di chuyển (tải lên và tải), kiểm tra kết quả. Do đó, phương pháp được đề xuất trong công việc phải bao gồm các khuyến nghị để hoàn thành nhiệm vụ của từng giai đoạn được trình bày trong sơ đồ vòng đời di chuyển dữ liệu (Hình 1).

Phần đầu tiên của phương pháp luận sẽ cung cấp và mô tả các cách phát triển các yêu cầu chung về di chuyển dữ liệu. Đặc biệt, phần phương pháp này sẽ mô tả cách giải quyết các rủi ro tiềm ẩn của giai đoạn di chuyển dữ liệu. Phần phương pháp này cũng mô tả cách tương tác với những người dùng chính để xác định các yêu cầu về chiến lược di chuyển và các yêu cầu kinh doanh cấp cao khác.

Phần thứ hai của phương pháp luận nên được dành cho các công cụ lập kế hoạch và tổ chức quá trình di chuyển. Dựa trên phân tích kinh nghiệm của dự án, những điểm nghẽn nhất của quy trình được xác định và phương pháp này đưa ra giải pháp.

Phần tiếp theo của phương pháp luận sẽ đề cập đến giai đoạn khảo sát và phát triển các yêu cầu về di chuyển dữ liệu. Phần phương pháp này phải có hướng dẫn thực hiện các hoạt động khảo sát (các cuộc họp, các hình thức liên lạc khác), cũng như ghi lại kết quả của giai đoạn - các mẫu tài liệu và ví dụ hoàn thành.

Phần cuối cùng của phương pháp di chuyển phải chứa các đề xuất để tiến hành di chuyển và thử nghiệm trong giai đoạn di chuyển. Kiểm tra ở giai đoạn di chuyển được chia thành kiểm tra phần mềm được di chuyển, cũng như kiểm tra hoạt động của hệ thống nhận sau khi đặt dữ liệu đã di chuyển vào đó. Phần phương pháp này phải mô tả các cách kiểm soát quá trình di chuyển, xác định các khiếm khuyết có thể xảy ra và nguyên nhân của chúng.

2. Phân tích kinh nghiệm dự án trong việc di chuyển dữ liệu

2.1 Mô tả tóm tắt dự án triển khai IS

Kinh nghiệm dự án sẽ được xem xét trong công việc là một số dự án di chuyển dữ liệu được thực hiện như một phần của danh mục dự án triển khai hệ thống thông tin bộ phận. Là một phần của việc phân tích trải nghiệm dự án, một mô tả ngắn gọn về dự án sẽ được đưa ra và một số đặc điểm của tổ chức khách hàng sẽ được xem xét.

Là một phần của công việc này, kinh nghiệm của dự án về triển khai hệ thống thông tin trong một tổ chức nhà nước là một phần của hệ thống cơ quan điều hành ở cấp khu vực sẽ được phân tích. Dự án chính được chia thành nhiều dự án phụ, mỗi dự án liên quan đến việc tự động hóa một nhóm quy trình kinh doanh của khách hàng. Theo đó, mỗi dự án đều liên quan đến việc chuyển một số bộ phận đơn vị kinh doanh của khách hàng sang làm việc với hệ thống mới. Mỗi dự án đều cung cấp khả năng di chuyển dữ liệu được tích lũy trong hệ thống nguồn mà đơn vị kinh doanh tương ứng làm việc. Hoạt động chính của tổ chức kiểu này liên quan đến việc cung cấp các dịch vụ công cho người dân. Là một phần của phân tích này, chúng tôi sẽ xem xét giai đoạn di chuyển dữ liệu trong các dự án triển khai hệ thống thông tin tự động hóa chính xác loại hoạt động này của tổ chức khách hàng. Trong các phần sau của công việc, để tiến hành phân tích kinh doanh chuyên sâu hơn và chứng minh kết quả thực tế của công việc, một phần hẹp hơn của lĩnh vực chủ đề sẽ được mô tả - ở cấp độ cung cấp một dịch vụ công cụ thể.

Để mô tả chi tiết hơn về hồ sơ của tổ chức khách hàng, cần đưa ra một số khái niệm. “Người nộp đơn” hoặc “người sử dụng IP công cộng” là người nộp đơn xin cung cấp dịch vụ công. “Đối tượng dữ liệu” sẽ là một trong những thực thể hoặc tạo phẩm thuộc lĩnh vực hoạt động chủ đề của tổ chức khách hàng. Chúng tôi sẽ gọi “hệ thống thu” là hệ thống thông tin doanh nghiệp được triển khai thuộc lớp ECM. Khách hàng vận hành hai hệ thống thông tin riêng biệt, không tích hợp với nhau để lưu trữ nội dung và tự động hóa quy trình nghiệp vụ chính. Các hệ thống này sẽ là nguồn dữ liệu - “hệ thống nguồn” cho quá trình di chuyển dữ liệu vào hệ thống được triển khai. Hệ thống đầu tiên trong số hai hệ thống hiện có được phát triển trên nền tảng IBM Lotus Notes và nhằm mục đích tự động hóa quy trình kinh doanh tại một trong các bộ phận chức năng của khách hàng. Hệ thống thứ hai được nhân viên của khách hàng phát triển một cách độc lập và nhằm mục đích tự động hóa quy trình kinh doanh trong các đơn vị kinh doanh khác và lưu trữ tài liệu dưới dạng điện tử, thu thập và lưu trữ thông tin báo cáo về quy trình kinh doanh của tổ chức.

Đặc điểm tổ chức của dự án là việc sử dụng mô hình sau để phân bổ trách nhiệm về kết quả của dự án giữa những người tham gia chính sau đây về phía Khách hàng:

Khách hàng chức năng chịu trách nhiệm về kết quả chất lượng của dự án;

Khách hàng không có chức năng chịu trách nhiệm về kết quả tài chính của dự án.

Tổ chức - khách hàng chức năng là chủ sở hữu của các quy trình kinh doanh tự động. Các nhân viên của tổ chức này có kiến ​​thức về các chi tiết cụ thể của lĩnh vực chủ đề. Nhân viên của khách hàng chức năng sẽ là người dùng cuối của hệ thống thông tin được triển khai.

Nhân viên của một khách hàng không có chức năng có thể không có kiến ​​thức và chuyên môn sâu trong một lĩnh vực hoạt động hẹp. Trách nhiệm của họ bao gồm giám sát việc thực hiện dự án triển khai IS từ quan điểm tổ chức, tổ chức hỗ trợ kỹ thuật sau dự án cho hệ thống đã triển khai từ phía khách hàng. Cũng cần lưu ý rằng lĩnh vực trách nhiệm của khách hàng phi chức năng có thể bao gồm chức năng giám sát các hoạt động vận hành của tổ chức - khách hàng chức năng.

Việc phân bổ trách nhiệm cụ thể đã dẫn đến xung đột lợi ích giữa khách hàng chức năng và khách hàng không chức năng trong dự án. Cơ cấu tổ chức này là nguồn rủi ro khi tiến hành di chuyển dữ liệu.

2.2 Các vấn đề đã được xác định khi xây dựng kế hoạch làm việc và truyền thông ở giai đoạn di chuyển dữ liệu

Khi xây dựng kế hoạch làm việc cho giai đoạn di chuyển dữ liệu, ban quản lý dự án đã dựa vào mô hình nhóm dự án MSF, đồng thời sử dụng ma trận RACI làm công cụ phân bổ trách nhiệm. Cách tiếp cận này đã được phân tích ở trên trong Chương 1.

Ở bước tương tự, chiến lược di chuyển dữ liệu trong dự án đã được xây dựng. Chiến lược được lựa chọn dựa trên các yêu cầu cấp cao của khách hàng chức năng, những người đã từ chối tạm dừng quy trình kinh doanh để thực hiện công việc di chuyển. Do đó, chiến lược “vụ nổ lớn” đã được chọn, di chuyển dữ liệu một lần từ hai nguồn sang hệ thống tiếp nhận.

Cấu trúc phân cấp ban đầu của công việc ở giai đoạn di chuyển dữ liệu trông như được hiển thị.

Theo kế hoạch dự án ban đầu, công việc trực tiếp tải dữ liệu từ hệ thống nguồn và tải dữ liệu vào hệ thống tiếp nhận sẽ mất 4 ngày dương lịch. 3 ngày được phân bổ để nhận dữ liệu và tải tệp vào hệ thống đã triển khai và 1 ngày được dành để giảm nguy cơ gián đoạn công việc tải dữ liệu. Tuy nhiên, công việc đã không được hoàn thành đúng thời hạn: trong quá trình thực hiện dự án, một số rủi ro đã xuất hiện đã được xác định trong quá trình phân tích lý thuyết ở Chương 1.

Việc không đáp ứng được thời hạn trong dự án di chuyển dữ liệu đầu tiên xảy ra do lập kế hoạch liên lạc không chính xác với các bên liên quan từ phía khách hàng. Như đã đề cập ở trên, tổ chức khách hàng có cơ cấu tổ chức phức tạp. Khi lập kế hoạch cho công việc khảo sát và lựa chọn người dùng để thu thập yêu cầu kinh doanh, cần phải có sự tham gia của các nhân viên khách hàng không có chức năng trong cuộc khảo sát khách hàng. Chính những nhân viên khách hàng này là người có kiến ​​thức để giám sát hoạt động của khách hàng chức năng. Do đó, nhân viên của khách hàng không có chức năng đã biết về các yêu cầu về khoảng thời gian tải xuống dữ liệu từ hệ thống nguồn. Các yêu cầu về khoảng thời gian dỡ hàng có thể được phát triển dựa trên phân tích khung pháp lý và được thống nhất với nhân viên của khách hàng không có chức năng, nhưng những công việc này không được lên kế hoạch và thực hiện. Vì vậy, chúng ta có thể nói về hai vấn đề của giai đoạn di cư cùng một lúc:

1) Lập kế hoạch liên lạc với nhân viên của khách hàng không chính xác;

2) Lập kế hoạch công việc trong WBS không chính xác;

3) Các yêu cầu kinh doanh về di chuyển dữ liệu chưa đầy đủ, do vấn đề đầu tiên. Đặc biệt, các lượt tải xuống từ hệ thống nguồn chỉ được nhận trong 2 năm hoạt động gần đây nhất của khách hàng chức năng. Đồng thời, việc tải lên dữ liệu phải mất một khoảng thời gian dài hơn nhiều.

Các cơ quan hành pháp của các khu vực thuộc Liên bang Nga có nghĩa vụ lưu trữ dữ liệu lịch sử (lưu trữ) trong các khoảng thời gian do Luật Liên bang quy định. Do đó, các yêu cầu về thành phần tải xuống dữ liệu từ hệ thống nguồn được xác định theo các quy định lưu trữ dữ liệu, do đó, quy định này đề cập đến luật liên bang. Ngoài các yêu cầu về thành phần tải lên dữ liệu từ hệ thống nguồn, các yêu cầu về khoảng thời gian lưu trữ dữ liệu sẽ quyết định phần lớn khối lượng lưu trữ dữ liệu cần thiết trong hệ thống nhận.

Một lĩnh vực chủ đề hẹp hơn mà khách hàng chức năng hoạt động là cung cấp dịch vụ công cho các tổ chức thiết kế và xây dựng trong lĩnh vực giám sát môi trường.

Theo Luật Liên bang, tổ chức khách hàng có nghĩa vụ lưu trữ:

Hồ sơ dự án xây dựng cơ bản 20 năm;

Tài liệu công nghệ và thiết kế trong 20 năm.

Tổ chức ký hợp đồng đã vận hành các hệ thống thông tin hiện có lần lượt vào năm 2005 và 2000. Do đó, phạm vi tải lên để truyền dữ liệu đến hệ thống nhận bao gồm tất cả tài liệu được lưu trữ trong hệ thống nguồn, cũng như tất cả các đối tượng được tham chiếu bởi các tài liệu đó.

Tương tự như ví dụ được mô tả ở trên, việc phân tích các quy phạm pháp luật đối với các tổ chức khu vực công hoặc tổ chức thương mại khác có thể được thực hiện nếu các quy định nội bộ của các tổ chức đó được xây dựng trên cơ sở luật liên bang.

Ngoài khoảng thời gian tải xuống từ hệ thống nguồn, luật liên bang cũng xác định các yêu cầu về thành phần tải xuống từ hệ thống nguồn: danh sách tên tài liệu, nhu cầu chuyển phiên bản của chúng và các tài liệu bổ sung - phụ lục, phần bổ sung cho mỗi tài liệu - sang hệ thống mới.

Pháp luật liên bang xác định các loại và thành phần tài liệu mà tổ chức khách hàng phải lưu giữ. Theo đó, các quy định của Luật Liên bang phải được phân tích có tính đến đặc điểm hoạt động của một khách hàng cụ thể và thành phần tài liệu cần thiết để cung cấp một loại dịch vụ công nhất định. Các tạo phẩm thuộc lĩnh vực chủ đề của khách hàng phải được so sánh với các quy phạm pháp luật và đối tượng mô hình dữ liệu của hệ thống nguồn đang được vận hành. Kết quả phân tích như vậy sẽ giúp xác định thành phần của bản tải xuống từ hệ thống nguồn và xác định các yêu cầu đối với bộ thu cũng như đối với phần mềm truyền dữ liệu.

Quay lại ví dụ về một tổ chức là một phần của Sở Xây dựng khu vực, các đối tượng sau có thể được xác định là một phần của dữ liệu để truyền từ hệ thống nguồn đến hệ thống đích:

Hình ảnh điện tử các bộ tài liệu công nghệ, thiết kế, xây dựng công trình xây dựng cơ bản và các đối tượng dữ liệu lưu trữ thông tin về các tài liệu liên quan;

Hình ảnh điện tử các tài liệu công nghệ, tổ chức - hành chính của cơ sở xử lý, tiêu hủy CTNH và các đối tượng dữ liệu lưu trữ thông tin về các tài liệu liên quan;

Hình ảnh điện tử của các tài liệu cho phép, cũng như lịch sử cấp bản sao của các tài liệu đó, cũng như các đối tượng dữ liệu lưu trữ thông tin về các tài liệu liên quan;

Lịch sử công việc với tất cả các loại tài liệu liệt kê ở trên, được lưu trữ trong hệ thống nguồn.

Do đó, nguy cơ lập kế hoạch không chính xác đã xảy ra và do đó, nguy cơ phát triển các yêu cầu tải xuống dữ liệu không đầy đủ đã được kích hoạt một phần. Khả năng gây ra rủi ro do yêu cầu dỡ hàng từ hệ thống nguồn không đầy đủ sẽ được xem xét chi tiết hơn trong phần tiếp theo của công việc.

2.3 Các vấn đề được xác định khi xây dựng các yêu cầu dỡ hàng từ hệ thống nguồn

Là một phần trong kế hoạch di chuyển dữ liệu, dự án không bao gồm công việc kiểm tra dữ liệu được tải xuống từ hệ thống nguồn. Giả định rằng toàn bộ khối lượng dữ liệu ở đầu vào hệ thống nhận sẽ được xác thực theo mô hình dữ liệu của hệ thống đang được triển khai. Phần phân tích về chất lượng của các thuật toán kiểm tra logic và xác thực dữ liệu sẽ được đưa ra trong phần tiếp theo của tác phẩm. Phần công việc này phân tích các hoạt động chuẩn bị để lấy dữ liệu từ hệ thống nguồn và phân tích trạng thái dữ liệu trong các hệ thống này. Để kiểm tra trạng thái của dữ liệu và xác định các vấn đề tiềm ẩn khi sắp xếp dữ liệu trong hệ thống nhận, bản tải xuống thử nghiệm từ hệ thống nguồn sẽ được hình thành. Mục tiêu của bước này là đặt thành công quá trình tải lên thử nghiệm trên hệ thống đích, xác định mọi sự cố tiềm ẩn khi tải dữ liệu và do đó giảm nguy cơ di chuyển không thành công do lỗi tải dữ liệu không hợp lệ vào hệ thống đích.

...

Tài liệu tương tự

Thiết kế hệ thống thông tin “Kế toán công việc của phòng khám”: phân tích sản phẩm phần mềm, mô tả sơ đồ quy trình nghiệp vụ, mô tả sơ đồ luồng dữ liệu IDEF0, DFD, IDEF3 và ghi chép các quy trình bằng AllFusion Process Modeler r7.3.

bài tập khóa học, được thêm vào ngày 20/08/2012


Hệ thống quản lý cơ sở dữ liệu cho các nhiệm vụ và quy trình doanh nghiệp cấu thành của chúng. Yêu cầu về hệ thống thông tin. Thành phần của các truy vấn tới cơ sở dữ liệu. Các kết nối và mối quan hệ giữa các đối tượng thông tin. Các thuật toán hoạt động và kiến ​​trúc của hệ thống thông tin.

bài tập khóa học, được thêm vào ngày 02/02/2014


Chi tiết các chức năng hệ thống và các yêu cầu đối với hệ thống thông tin. Phân tích danh mục người dùng. Các giai đoạn triển khai hệ thống thông tin tự động tại doanh nghiệp. Mô tả các bảng cơ sở dữ liệu. Bảo vệ dữ liệu khỏi sự truy cập trái phép.

luận văn, bổ sung 22/07/2015


Đặc điểm của đối tượng tự động hóa hệ thống thông tin. Yêu cầu về tài liệu. Thủ tục kiểm soát và chấp nhận hệ thống. Mô tả luồng dữ liệu và quy trình kinh doanh. Cấu trúc của hệ thống thông tin, thành phần của các hệ thống con chức năng và hỗ trợ.

bài tập khóa học, được thêm vào ngày 18/09/2013


Lựa chọn phương pháp thiết kế và phát triển hệ thống thông tin "Tính lương" cho doanh nghiệp OJSC RTP "Avtoremontnik". Thiết kế kiến ​​trúc cơ sở dữ liệu hệ thống thông tin và phát triển giao diện của nó. Kiểm tra mô-đun phần mềm.

luận văn, bổ sung 25/05/2014


Phát triển hệ thống thông tin nhà hàng, xác định ranh giới của nó để triển khai cơ sở dữ liệu. Danh sách các yêu cầu, báo cáo và thao tác nhập thông tin vào hệ thống thông tin “Nhà hàng”. Thiết kế cơ sở dữ liệu, lựa chọn phương tiện để thực hiện nó.

bài tập khóa học, được thêm vào ngày 27/04/2011


bài tập khóa học, được thêm vào ngày 10/07/2014


Xây dựng các yêu cầu phần mềm cho Cục đăng ký quân sự, phương pháp thiết kế hệ thống thông tin. Triển khai và chứng nhận hệ thống thông tin, sự tương tác của ứng dụng với các nguồn dữ liệu, hiệu quả kinh tế của nó.

luận văn, bổ sung 30/11/2010


Mục đích của việc tạo ra hệ thống thông tin “Tạp chí điện tử” là để tự động hóa việc kiểm soát quá trình giáo dục. Xây dựng các mô hình dữ liệu logic và quan hệ. Phát triển ứng dụng client-server để làm việc với cơ sở dữ liệu; triển khai phần mềm.

luận văn, bổ sung 19/01/2017


Phân tích thông tin đầu vào và quy trình, mức độ tự động hóa tại doanh nghiệp. Xác định đối tượng và nhiệm vụ của tự động hóa. Phát triển khái niệm xây dựng mô hình thông tin của hệ thống thông tin. Phát triển cấu trúc cơ sở dữ liệu và ứng dụng khách.

cách triển khai phần mềm miễn phí

Di chuyển sang phần mềm miễn phí cũng tương tự như di chuyển sang hệ điều hành mới hơn. Ví dụ có thể kể đến sự xuất hiện của những phiên bản Windows đầu tiên ở nước ta. Một ví dụ nổi bật không kém là việc chuyển sang Windows NT, hệ tư tưởng của nó hoàn toàn khác với Windows 9x. Có thể đưa ra một ví dụ nữa - mỗi phiên bản mới của gói MS Office khác với phiên bản trước không chỉ ở sự khác biệt về giao diện mà còn ở định dạng tệp. Vì vậy, nhiệm vụ di chuyển có liên quan ngay cả trong trường hợp sử dụng phần mềm từ một nhà sản xuất.

Bài viết này cung cấp mô tả chung về phương pháp di chuyển, nêu bật những điểm thiết yếu. Nguyên tắc chung của việc di cư là thực hiện quá trình này một cách chu đáo và cẩn thận thông qua những thay đổi dần dần. Quá trình di chuyển bao gồm một số phần và giai đoạn tích hợp một cách hợp lý.

thành lập một nhóm làm việc (ai làm việc đó)

Khi thực hiện di chuyển, cần phải cung cấp giải pháp cho các vấn đề mang tính chất kỹ thuật và phi kỹ thuật.

Điều quan trọng là phải xem xét các vấn đề pháp lý gần đây đã trở nên cực kỳ phù hợp đối với một số quốc gia CIS, đặc biệt là Ukraine. Trong một số trường hợp, việc thảo luận về các nhiệm vụ quản trị của mối quan hệ chủ lao động-người dùng-quản trị viên là điều hợp lý. Trong lịch sử, những mối quan hệ này chưa được điều chỉnh đầy đủ bởi các quy tắc và quy định nội bộ của công ty.

Trong quá trình chuẩn bị tài liệu, các cuộc trò chuyện đã được tổ chức với các chuyên gia trong lĩnh vực bảo mật, luật máy tính và quản trị viên hệ thống. Đại đa số cho biết sự cần thiết phải ghi lại các quy tắc về cách người dùng làm việc với hệ thống thông tin của tổ chức.

Lập kế hoạch phù hợp cũng bao gồm việc giải quyết các vấn đề tài chính. Cần đánh giá chi phí hợp pháp hóa hệ thống thông tin hiện có, chi phí triển khai hệ thống mới và ước tính chi phí sở hữu trong tương lai gần.

Bất kỳ dự án nào, bao gồm cả dự án di cư, đều có thể phải đối mặt với việc đánh giá thấp yếu tố con người. Đương nhiên sẽ cần phải áp dụng các phương pháp quản lý nhân sự. Hầu hết các quản trị viên hệ thống và quản lý CNTT mà tác giả biết đến đều không phải là chuyên gia trong lĩnh vực quản lý nhân sự hoặc tài chính. Một nhiệm vụ phức tạp như vậy không thể chỉ một mình bộ phận CNTT giải quyết được.

Nhiệm vụ đầu tiên trên con đường di chuyển sang hệ thống mục tiêu mới là tạo một nhóm làm việc lập kế hoạch di chuyển. Nhóm này chịu trách nhiệm tiến hành di cư và do đó có quyền hạn khá rộng.

Mục tiêu của dự án là xây dựng cơ sở hạ tầng CNTT khả thi về mặt kinh tế. Một ứng cử viên sáng giá cho vị trí trưởng nhóm làm việc sẽ là người quản lý cấp cao của một doanh nghiệp hoặc tổ chức, ví dụ như giám đốc tài chính. Đương nhiên, nhóm này bao gồm trưởng bộ phận CNTT, người có tầm nhìn về toàn bộ cơ sở hạ tầng CNTT, cả ở hiện tại và tương lai. Nhóm phải bao gồm một quản trị viên hệ thống có kinh nghiệm, tốt nhất là có kinh nghiệm vận hành phần mềm miễn phí. Không thể ước tính quy mô của nhóm - trong một số trường hợp, các nhân viên khác của công ty cũng có thể tham gia nếu cần thiết. Có thể thu hút một nhà tư vấn bên thứ ba có kinh nghiệm hoặc một công ty chuyên về các giải pháp như vậy. Kết quả công việc của nhóm này là một kế hoạch di cư chi tiết kèm theo ước tính chi phí di chuyển. Hoặc – giải thích về tính kém hiệu quả của việc chuyển sang các giải pháp miễn phí cho tổ chức.

nghiên cứu (cái gì)

Giai đoạn đầu tiên phải là kiểm tra - mô tả hệ thống (kế thừa) hiện có.

Không có gì bí mật rằng, với nhiều năm áp dụng tin học “khẩn cấp” mà không tính đến lợi tức thu được từ số tiền chi cho phần mềm, kết quả, theo quy luật, không chỉ là các hệ thống mất cân bằng về mặt kinh tế mà còn về mặt công nghệ. Kiểm tra phần mềm doanh nghiệp là việc sửa đổi các chương trình đã cài đặt, xác định sự tuân thủ của chúng với các yêu cầu kinh doanh.

Kết quả của quá trình kiểm toán là:

Mô tả các đặc tính kỹ thuật của phần mềm được cài đặt;

Danh sách các rủi ro được xác định liên quan đến việc sử dụng phần mềm không có giấy phép;

Tính toán chi phí mua bản quyền phần mềm cài đặt;

Tính toán chi phí gỡ bỏ và cài đặt phần mềm không bản quyền;

Xác định tính khả thi của việc tiếp tục sử dụng phần mềm;

Danh sách các rủi ro được xác định liên quan đến việc sử dụng phần mềm;

kiểm kê phần mềm

Một số nghiên cứu cho thấy hầu hết các nhà lãnh đạo tổ chức đều chú ý nhiều hơn đến chức năng của phần mềm họ sử dụng và ít quan tâm đến việc tôn trọng quyền đối với sản phẩm họ sử dụng.

Thật không may, hầu hết các tổ chức đều thiếu văn hóa CNTT. Đôi khi, ngay cả đại diện của dịch vụ CNTT cũng không thực sự biết những gì và ở đâu được cài đặt trên máy tính của nhân viên và các nhân viên bình thường quyết định và cài đặt độc lập các sản phẩm phần mềm lấy từ các nguồn không rõ ràng.

Kiểm kê phần mềm cho phép bạn xác định phần mềm không được cấp phép trong một tổ chức. Cần nhấn mạnh rằng sự kiện này luôn có lợi. Kết quả kiểm kê có thể được sử dụng để ước tính chi phí hợp pháp hóa phần mềm bằng cả phần mềm miễn phí và phần mềm độc quyền.

Các nhà quản lý tổ chức thường quan tâm đến việc lập kế hoạch tài chính rõ ràng về chi phí sử dụng và phát triển phần mềm. Sự quan tâm của các nhà quản lý cấp cao đến chi tiết như vậy là khá dễ hiểu - ban lãnh đạo cấp cao của các công ty quan tâm đến việc biến phần mềm thành tài sản của công ty được hạch toán, kiểm soát và phát triển giống như các loại tài sản khác.

Kiểm toán phần mềm là một thủ tục, theo quy luật, mất khá nhiều thời gian, đòi hỏi nhân sự có trình độ cao và kiến ​​​​thức về nhiều thông tin cụ thể khác nhau ở giai đoạn phân tích thông tin. Một khuyến nghị có thể là liên hệ với một công ty chuyên về các dịch vụ này. Tuy nhiên, việc bộ phận CNTT tiến hành kiểm tra là hoàn toàn có thể.

Ở một số tổ chức, việc tiến hành kiểm kê phần mềm quy mô lớn cùng một lúc là điều bất tiện (thường là không thể). Lý do có thể là quy mô của tổ chức hoặc chính sách bảo mật. Cần phải tìm ra sự dung hòa giữa hiệu quả của hàng tồn kho và các yếu tố làm phức tạp quá trình đó.

Có hai lựa chọn kiểm toán để xem xét. Tùy chọn đầu tiên là kiểm tra toàn diện, bao gồm việc kiểm tra tất cả các cơ sở máy tính, mạng cục bộ và thiết bị ngoại vi. Ưu điểm của phương pháp này là độ chính xác cao, nhược điểm là giá thành cao, tốn nhiều thời gian và bất tiện cho người sử dụng. Ưu điểm bổ sung của phương pháp này là khả năng xác định phần mềm do chính người dùng cài đặt và nghiên cứu các yêu cầu của người dùng đối với phần mềm tại nơi làm việc của họ bằng cách sử dụng bảng câu hỏi được chuẩn bị đặc biệt. Tùy chọn thứ hai là kiểm tra một số cơ sở tính toán, mạng cục bộ và thiết bị ngoại vi điển hình. Trong trường hợp này, việc lựa chọn đối tượng kiểm tra thường được quyết định bởi trách nhiệm chức năng của người dùng. Phương pháp gần đúng này giúp giảm đáng kể chi phí tồn kho nhưng lại có sai số lớn.

Các tổ chức nhỏ có thể tiến hành kiểm tra thủ công và nhập thông tin về máy tính và máy chủ cũng như phần mềm được cài đặt trên chúng vào một bảng tính đơn giản. Trong trường hợp này, bạn nên chỉ ra sự hiện diện hay vắng mặt của các giấy phép, chứng chỉ xác thực và thỏa thuận bản quyền cần thiết cho từng sản phẩm phần mềm được tìm thấy.

Đối với những doanh nghiệp vừa và lớn, bạn có thể khuyến nghị sử dụng phần mềm chuyên dụng hoặc mời tổ chức bên thứ ba chuyên về các dịch vụ đó. Trong quá trình tạo tài liệu, công việc đã được thực hiện để xem xét các công cụ kiểm kê phần mềm và phần cứng tự động (đã biết GASP, kiểm kê PC, các chương trình MSIA). Đề xuất sẽ là eXpont Navigator (http://www.e-x.ru/pages/expnav.html), do eXpont sản xuất.

Điều hướng số mũ

Sản phẩm này được thiết kế để kiểm tra thiết bị và phần mềm qua mạng. Thông tin về máy tính bao gồm dữ liệu về các thành phần (bộ xử lý, bo mạch chủ, ổ cứng, mô-đun bộ nhớ, card màn hình, card mạng, máy in và các thiết bị khác), hệ điều hành, trình điều khiển và phần mềm.

Theo những người tạo ra chương trình, sau khi tổ chức thu thập thông tin tự động về máy tính, có thể xem và sắp xếp thông tin này, chuẩn bị báo cáo in và ấn phẩm web, đồng thời tải dữ liệu lên Microsoft Excel, XML và các định dạng khác. Khả năng:

Tự động chẩn đoán cấu hình máy tính;

Tự động thu thập thông tin về máy tính qua mạng;

Xác định thiết bị lắp đặt;

Xác định các chương trình đã cài đặt;

Xác định đặc điểm của tập tin;

Khả năng nâng cao để sắp xếp, tìm kiếm và chọn dữ liệu;

Chuẩn bị các báo cáo in;

Xuất dữ liệu sang MS Excel;

Tự động tạo các ấn phẩm web.

Trong phiên bản miễn phí của chương trình có một hạn chế - chiếm tối đa 25 máy tính; Chi phí giấy phép là 1$ cho mỗi 1 máy tính.

chúng tôi thiết kế (những gì chúng tôi muốn)

Các kết quả được xử lý của nghiên cứu hệ thống hiện có là cơ sở để mô hình hóa một hệ thống mục tiêu mới. Câu hỏi này cực kỳ quan trọng và phức tạp. Việc xem xét vấn đề này cũng trở nên phức tạp do lịch sử thiếu hiểu biết về phần mềm miễn phí, đặc biệt là Linux, của hầu hết các nhà quản lý CNTT và quản trị viên hệ thống.

Có rất nhiều tài liệu, bao gồm cả tiếng Nga, về Linux, mô tả những ưu điểm của nền tảng này từ quan điểm công nghệ. Tuy nhiên, tất cả những ưu điểm này đều quan trọng cùng với vấn đề chính - sự tồn tại của nhiều loại phần mềm ứng dụng theo các hướng khác nhau. Có một huyền thoại lâu đời và phổ biến rằng có một số lượng hạn chế phần mềm ứng dụng dành cho doanh nghiệp sử dụng, bao gồm cả tự động hóa văn phòng, dành cho nền tảng Linux. Phần lớn những huyền thoại này được tạo ra và thúc đẩy bởi những người sáng tạo và bán phần mềm độc quyền và ít liên quan đến thực tế. Việc vạch trần huyền thoại này không phải là mục đích chính của cuốn sách này. Tuy nhiên, điều đáng chú ý là, chẳng hạn, độ rộng của phần mềm ứng dụng là một điều tuyệt đối ảo tưởng, có tính đến các tiêu chuẩn đã được thiết lập trong lịch sử để trao đổi tài liệu. Vì vậy, ví dụ, trình soạn thảo văn phòng tiêu chuẩn trên thực tế là Microsoft Office, trình soạn thảo đồ họa raster là Adobe Photosop và Corel Draw cực kỳ phổ biến dưới dạng đồ họa vector.

Một vấn đề khác là chức năng quá mức của các sản phẩm độc quyền, không phải do nhu cầu của thị trường quyết định mà do ý kiến ​​của các nhà tiếp thị. Và đối với chức năng dư thừa này, người dùng phải trả khá nhiều tiền: chi phí cấp phép cho quyền sử dụng chương trình, tăng độ phức tạp của hoạt động và tăng yêu cầu về phần cứng.

Gần đây, tình hình đã thay đổi - rất nhiều thông tin xuất hiện trên ứng dụng Linux. Có lẽ tài liệu tốt nhất sẽ là tài liệu này :-), trong đó nó dự định đề cập đến nhiều vấn đề hành chính và kỹ thuật.

Tuy nhiên, hiện tại tài liệu này mới đang được tạo và thông tin có thể được tìm thấy từ nhiều nguồn khác nhau. Không thể bỏ qua tài liệu của Valery V. Kachurov, Artem Nesov “Tương tự các chương trình Windows trong Linux - bảng tương ứng”. (http://linuxshop.ru/linuxbegin/win-lin-soft/). Tài nguyên này chứa rất nhiều thông tin có giá trị. Thật không may, các tác giả dường như đã từ bỏ công việc này. Phần này của trang web không thể truy cập thường xuyên nhưng có thể tìm thấy bản sao của bảng tại http://www.blif.net/modules.php?name=LinWin. Tôi có thể giới thiệu các tài nguyên của Quỹ ứng dụng nguồn mở
(http://www.osafoundation.org/), đặc biệt là http://www.osafoundation.org/desktop-linux-overview.pdf.

Kết quả là:

Tạo các máy trạm nguyên mẫu;

Tính toán chi phí giấy phép cho phần mềm được đề xuất;

Đào tạo người dùng;

Lập kế hoạch lịch thực hiện gần đúng;

Danh sách rủi ro khi triển khai phần mềm miễn phí;

Hỗ trợ các giải pháp miễn phí;

Tính toán hiệu quả kinh tế của hệ thống mới trong tối đa 5 năm.

dự án thí điểm (thử nghiệm thực tế)

Do có nhiều yếu tố trong hệ thống cũ và số lượng lớn người dùng có khả năng bị ảnh hưởng bởi việc di chuyển, nên việc di chuyển nên được thử nghiệm ở quy mô nhỏ - một dự án thí điểm. Giai đoạn này là cần thiết để kiểm tra và điều chỉnh kế hoạch di chuyển và nguyên mẫu của hệ thống mới. Dự án thí điểm là cơ sở để đưa ra quyết định triển khai hệ thống thông tin mới dựa trên phần mềm nguồn mở. Giá trị thứ hai của dự án thí điểm là cơ hội thông báo cho người dùng về hệ thống mới và nhận phản hồi từ người dùng. Lập luận thứ ba ủng hộ một dự án thí điểm sẽ là cơ hội xác định chi phí của dự án một cách chính xác hơn bằng thực nghiệm.

Khi chọn đối tượng thử nghiệm, cần tìm giá trị trung bình vàng. Đầu tiên, đối tượng được chọn phải cung cấp dữ liệu đáng tin cậy cho việc đánh giá. Thứ hai, dự án thí điểm sẽ không có tác động nghiêm trọng đến hoạt động kinh doanh.

Ở giai đoạn này, quản trị viên hệ thống và người dùng cuối cũng được đào tạo: nguyên mẫu của tài liệu giảng dạy, tài liệu và tài nguyên Internet được cung cấp. Chúng tôi khuyến nghị những người dùng tham gia dự án thí điểm nên “dỡ hàng” và có cơ hội sử dụng một phần thời gian của mình để làm chủ hệ thống mới.

Giai đoạn thử nghiệm đặc biệt có nhu cầu:

Nếu khả năng di chuyển người dùng từ hệ thống cũ sang hệ thống mới chưa được chứng minh;

Nếu có sự hoài nghi của người dùng thì điều đó có thể làm chậm quá trình di chuyển;

Tổ chức thiếu văn hóa doanh nghiệp (không may là điều này lại phổ biến ở CIS);

Nếu có nguồn lực hạn chế cho việc di cư quy mô lớn;

Tổ chức có quy mô lớn và dự án thí điểm không có nhiều người dùng;

Nếu các hệ thống độc quyền kế thừa đã phát triển nhanh chóng cả về mặt kỹ thuật và giảm chi phí;

Hiệu quả kinh tế của việc di cư chưa được hiểu đầy đủ.

Để thành công, một dự án thí điểm:

Không nên liên quan đến một lĩnh vực quan trọng của doanh nghiệp;

Phải đủ quan trọng đối với doanh nghiệp;

Không nên đòi hỏi quá nhiều nguồn lực từ những người vốn đã có hạn về thời gian;

Phải có một nhóm hỗ trợ đáng kể;

Phải cung cấp phản hồi từ người dùng (hệ thống Bộ phận trợ giúp);

Nó không nên nằm trong một khu vực hạn chế (ví dụ: giai đoạn quan trọng đối với hoạt động kinh doanh).

Tùy thuộc vào quy mô của tổ chức, có thể có một hoặc nhiều giai đoạn thử nghiệm để xác định chính xác hơn các dòng và chi phí di chuyển sang tự do. Điều quan trọng là phải đánh giá kết quả của nó và xác định xem tầm nhìn và mục tiêu có thực tế hay không hoặc liệu chúng có nên thay đổi hoặc thậm chí có thể bị từ bỏ hay không. Dữ liệu từ các dự án thí điểm này nên được sử dụng để điều chỉnh kế hoạch và tính toán chi phí cuối cùng. Trong quá trình thí nghiệm cần làm rõ các câu hỏi sau:

Mô tả nguyên mẫu máy trạm;

Mô tả cài đặt cụ thể của người dùng:

Chi phí triển khai trung bình cho các loại trạm;

Chuyển dữ liệu từ hệ thống cũ sang hệ thống mới;

Đào tạo người dùng;

Tính toán chi phí triển khai phần mềm;

Hỗ trợ các giải pháp miễn phí.

lập kế hoạch (cái gì và như thế nào)

1. Tạo kế hoạch di chuyển. Kế hoạch di chuyển phải trả lời các câu hỏi:

Mô tả các giai đoạn xây dựng hệ thống;

Xác định nhu cầu hỗ trợ;

Mô tả quá trình di chuyển hoàn tất.

Trên thực tế, lựa chọn cuối cùng được đưa ra về cách thức di chuyển sẽ diễn ra. Dự toán chi phí cho việc di chuyển đã được phê duyệt.

2. Mô tả các giai đoạn xây dựng hệ thống. Phải thực hiện đánh giá về các giai đoạn xây dựng hệ thống hỗ trợ tốt nhất cho nhu cầu ưu tiên của người dùng.

Kế hoạch cần trả lời các câu hỏi sau:

Hệ thống nên được cài đặt, triển khai ở mức độ nào và ở giai đoạn nào để đáp ứng tốt nhất nhu cầu của người dùng?

Điều gì cần thiết cho mỗi giai đoạn di chuyển sang hệ thống mới từ khách hàng và người dùng hệ thống của tổ chức?

Tác động và rủi ro của việc sử dụng hệ thống ở từng giai đoạn tăng dần là gì?

Các giai đoạn triển khai hệ thống cần được nêu rõ ràng trong kế hoạch di chuyển; khách hàng, nhà phát triển và người dùng nên biết. Đánh giá rủi ro phải được hoàn thành trước khi hoàn thiện kế hoạch xây dựng hệ thống. Cần phải đảm bảo rằng các ước tính lập kế hoạch là hợp lý, cách tiếp cận được thiết kế tốt phù hợp với các ưu tiên của tổ chức và tác động tiềm ẩn đối với khách hàng và người dùng là có thể chấp nhận được.

3. Xác định nhu cầu hỗ trợ. Mức hỗ trợ tối ưu phải được cung cấp để giúp người dùng sử dụng hệ thống mới. Ngoài ra, người dùng thường yêu cầu hỗ trợ để giúp họ hiểu được khả năng chung của hệ thống mục tiêu.

Các vấn đề cần giải quyết bao gồm:

Người dùng sẽ yêu cầu loại hình đào tạo và hỗ trợ vận hành nào?

Mức độ hỗ trợ di chuyển tổng thể mà người dùng sẽ yêu cầu để đảm bảo di chuyển thành công là gì?

Làm thế nào để đạt được sự chấp nhận của người dùng đối với hệ thống mục tiêu và tránh sự phản đối của người dùng đối với việc triển khai hệ thống mới?

Những thay đổi tất yếu về tính năng và dịch vụ của hệ thống sẽ được truyền đạt tới khách hàng và người dùng như thế nào?

Giải pháp miễn phí có thể được bộ phận CNTT của tổ chức hỗ trợ hay thuê ngoài là lựa chọn tốt nhất?

Kế hoạch di chuyển nên tập trung vào việc giải quyết những vấn đề này, lập kế hoạch hỗ trợ người dùng trong các lĩnh vực:

Hệ thống báo cáo sự cố;

Dịch vụ hỗ trợ kỹ thuật cho hệ thống mới;

Hỗ trợ kỹ thuật cho người dùng chuyển sang hệ thống mới;

Hướng dẫn sử dụng cho các giai đoạn chuyển tiếp và các giai đoạn tiếp theo;

Đào tạo người dùng học hỏi và thích ứng với hệ thống mới, thực hiện các loại nhiệm vụ tương tự;

Khả năng thử nghiệm việc sử dụng các hệ thống mới;

Minh họa việc sử dụng các hệ thống mới để cho người dùng hiện tại của các hệ thống cũ thấy cách hệ thống mới hoạt động và cách họ có thể thực hiện các nhiệm vụ tương đương;

Khắc phục các vấn đề vận hành hiện tại.

Trong giai đoạn giáo dục người dùng, đặc biệt chú ý đến những người ủng hộ hệ thống cũ và/hoặc phản đối hệ thống mới.

4. Mô tả việc hoàn thành quá trình di chuyển. Vào cuối mỗi giai đoạn triển khai và đào tạo mới, nhà phát triển và người triển khai phải đảm bảo rằng người dùng di chuyển sang hệ thống mục tiêu mới một cách suôn sẻ nhất có thể. Kế hoạch di chuyển nên đưa ra các điều khoản để đẩy nhanh nỗ lực di chuyển và loại bỏ hệ thống cũ càng sớm càng tốt.

Phải cân nhắc nỗ lực bổ sung có thể cần thiết cho những người chấp nhận muộn và những người dùng khác gặp phải sự cố không mong muốn. Một khía cạnh khác của hoạt động này là đánh giá thời gian và chi phí để hoàn thành việc di chuyển tất cả người dùng sang hệ thống mới và loại bỏ các hệ thống cũ hơn được xây dựng trên phần mềm độc quyền không được cấp phép.

Lãnh đạo tổ chức, nhà phát triển và người triển khai nên cân nhắc việc kết hợp một số phương pháp tiếp cận để giúp di chuyển người dùng của các hệ thống cũ:

Trao đổi với từng nhóm người dùng về cách thức và thời điểm họ nên di chuyển nhiệm vụ của mình sang hệ thống mới cũng như khối lượng công việc sẽ thay đổi như thế nào trong giai đoạn di chuyển từ các hệ thống cũ;

Thiết lập các biện pháp khuyến khích để chuyển đổi hoàn toàn sang hệ thống miễn phí mới và loại bỏ sự phụ thuộc vào các hệ thống cũ;

Cung cấp hỗ trợ (phần mềm và nhân sự bổ sung) để chuyển đổi dữ liệu cũ sang hệ thống mới; - quy trình ngừng hoạt động các hệ thống cũ;

Lưu trữ dữ liệu từ các hệ thống cũ và lưu trữ chúng.

di cư (chúng tôi làm)

Tất cả những gì còn lại ở giai đoạn cuối là làm việc theo kế hoạch.

Chủ động quản lý và kiểm soát quá trình di chuyển:

Thiết lập các tiêu chí đo lường và theo dõi các giai đoạn di chuyển cũng như chi phí tài nguyên di chuyển;

Tiến hành đánh giá định kỳ tình hình và truyền đạt chúng, phù hợp với thẩm quyền và chính sách của tổ chức, tới những người quan tâm (quản lý, quản lý dự án và nhà tài trợ);

Thiết lập hệ thống theo dõi để quản lý tiến độ quy trình, các vấn đề, giải pháp và các vấn đề kinh doanh khác liên quan đến việc lập kế hoạch và thực hiện di chuyển.

Vadim Mashkov, UA-FOSS, [email được bảo vệ]

Các vấn đề về kiểm soát phiên bản cơ sở dữ liệu và di chuyển giữa các phiên bản đã hơn một lần được nêu ra cả trên Habré (, , v.v.) và trên Internet (chủ yếu bằng tiếng Anh).

Trong phần đầu tiên của bài viết này, tôi thảo luận về các vấn đề chính phát sinh trong các nhóm lập trình khi thực hiện bất kỳ thay đổi nào đối với cấu trúc cơ sở dữ liệu. Trong phần thứ hai, tôi đã cố gắng nêu bật các cách tiếp cận chung chính về cách lưu trữ và duy trì các thay đổi đối với cấu trúc cơ sở dữ liệu trong quá trình phát triển.

Thuật ngữ

Cơ sở dữ liệu - tập hợp tất cả các đối tượng cơ sở dữ liệu (bảng, thủ tục, trình kích hoạt, v.v.), dữ liệu tĩnh (dữ liệu bất biến được lưu trữ trong bảng tra cứu) và dữ liệu người dùng (thay đổi khi làm việc với ứng dụng).

Cấu trúc cơ sở dữ liệu - một tập hợp tất cả các đối tượng cơ sở dữ liệu và dữ liệu tĩnh. Dữ liệu người dùng không được bao gồm trong khái niệm cấu trúc cơ sở dữ liệu.

Phiên bản cơ sở dữ liệu - một trạng thái nhất định của cấu trúc cơ sở dữ liệu. Thông thường, một phiên bản có một số liên quan đến số phiên bản của ứng dụng.

Di chuyển , trong ngữ cảnh này, là bản cập nhật cấu trúc cơ sở dữ liệu từ phiên bản này sang phiên bản khác (thường là phiên bản mới hơn).

Theo nghĩa này, thuật ngữ di chuyển dường như được sử dụng trong nhiều nguồn (đặc biệt là các di chuyển từ gem Active Record có trong Ruby on Rails). Tuy nhiên, có một sự mơ hồ khi sử dụng thuật ngữ này: một người không biết ngữ cảnh là nhiều khả năng nghĩ rằng chúng ta đang nói về việc chuyển cơ sở dữ liệu từ DBMS này sang DBMS khác (MySQL => Oracle) hoặc thậm chí về việc di chuyển các quy trình/dữ liệu giữa các nút cụm. Do đó, tôi đề nghị, trong trường hợp bối cảnh không rõ ràng, hãy dùng từ chính xác hơn: đã được phiên bản di cư cơ sở dữ liệu.

Tại sao điều này là cần thiết?

Các nhà phát triển đã gặp phải sự cố cơ sở dữ liệu và phiên bản ứng dụng không đồng bộ có thể bỏ qua phần này. Ở đây tôi sẽ nhắc bạn lý do tại sao bạn cần duy trì tính chẵn lẻ giữa các phiên bản ứng dụng và cơ sở dữ liệu cũng như vấn đề phổ biến mà điều này tạo ra.

Phiên bản cơ sở dữ liệu phải khớp với phiên bản ứng dụng

Vì vậy, hãy tưởng tượng tình huống sau: một nhóm gồm nhiều lập trình viên đang phát triển một ứng dụng sử dụng cơ sở dữ liệu một cách tích cực. Đôi khi, một ứng dụng được đưa vào sản xuất - ví dụ: đó là một trang web được triển khai trên máy chủ web.
Bất kỳ lập trình viên nào trong quá trình viết mã ứng dụng đều có thể cần thay đổi cấu trúc của cơ sở dữ liệu, cũng như chính dữ liệu được lưu trữ trong đó. Hãy để tôi cho bạn một ví dụ đơn giản: giả sử có một trường chuỗi không thể rỗng ở một trong các bảng. Trường này không phải lúc nào cũng chứa dữ liệu, trong trường hợp đó một chuỗi trống được lưu trữ ở đó. Tại một thời điểm nào đó, bạn đã quyết định rằng việc lưu trữ các chuỗi trống là không chính xác về mặt ngữ nghĩa trong một số trường hợp (xem, ) và việc lưu trữ các giá trị NULL là đúng. Để thực hiện điều này, bạn sẽ cần thực hiện các bước sau:

1. Thay đổi loại trường thành nullable:

THAY ĐỔI myTable THAY ĐỔI CỘT myField myField VARCHAR (255) NULL DEFAULT NULL ;

2. Vì bảng này trong cơ sở dữ liệu sản xuất có thể đã có hàng trống nên bạn đưa ra quyết định có chủ ý và hiểu chúng là thiếu thông tin. Vì vậy, bạn sẽ cần thay thế chúng bằng NULL:

CẬP NHẬT myTable SET myField = NULL WHERE myField = "" ;

3. Thay đổi mã ứng dụng để khi nhận dữ liệu được lưu trữ trong trường này từ cơ sở dữ liệu, nó sẽ phản hồi đầy đủ với các giá trị NULL.Bây giờ bạn cũng cần ghi các giá trị NULL vào trường này thay vì các chuỗi trống.

Từ điểm 3, bạn có thể thấy rằng ứng dụng và cơ sở dữ liệu là những phần không thể tách rời của một tổng thể. Điều này có nghĩa là khi một phiên bản mới của ứng dụng được đưa vào sản xuất, cần phải cập nhật phiên bản cơ sở dữ liệu, nếu không ứng dụng sẽ không thể hoạt động chính xác. Trong ví dụ này, nếu chỉ ứng dụng được cập nhật lên phiên bản mới thì tại một thời điểm nào đó, NULL sẽ được chèn vào trường không thể rỗng và đây là một lỗi rõ ràng.

Như vậy, cập nhật phiên bản ứng dụng yêu cầu di chuyển phiên bản cơ sở dữ liệu chính xác.

Nó có đơn giản vậy không?

Sau khi nhận thấy rằng tính chẵn lẻ của phiên bản giữa cơ sở dữ liệu và ứng dụng là cần thiết, bạn cần đảm bảo rằng việc di chuyển cơ sở dữ liệu sang đúng phiên bản sẽ luôn được thực hiện chính xác. Nhưng vấn đề ở đây là gì? Rốt cuộc, thoạt nhìn, không có gì phức tạp ở đây cả!

Ở đây một lần nữa chúng ta chuyển sang một ví dụ sống động. Giả sử các lập trình viên trong quá trình phát triển ghi lại các thay đổi của họ đối với cấu trúc và dữ liệu của cơ sở dữ liệu trong một tệp riêng dưới dạng truy vấn SQL (cả truy vấn DDL và DML). Và với mỗi lần triển khai phiên bản mới nhất của ứng dụng, bạn đồng thời cập nhật cơ sở dữ liệu lên phiên bản mới nhất, chạy các truy vấn từ cùng một tệp SQL đó... Nhưng chờ đã, từ phiên bản nào bạn có đang cập nhật cơ sở dữ liệu lên phiên bản mới nhất không? "Tư qua khư"? Nhưng bạn có nhớ chính xác phiên bản trước đó là gì không (nó đã được phát hành cách đây 2 tháng)? Nếu không, bạn sẽ cập nhật nó như thế nào? Xét cho cùng, nếu không có thông tin chính xác về trạng thái của cấu trúc và dữ liệu thì không thể thực hiện di chuyển chính xác: nếu bạn vô tình thực hiện các truy vấn đã được thực thi, điều này có thể dẫn đến mất dữ liệu hoặc vi phạm tính toàn vẹn của nó.
Một ví dụ đơn giản là thay thế mật khẩu bằng tổng MD5 của chúng. Nếu bạn chạy lại yêu cầu như vậy, dữ liệu chỉ có thể được khôi phục từ bản sao lưu. Và nói chung, bất kỳ UPDATE, DELETE và thậm chí INSERT nào được thực hiện lặp đi lặp lại đều có thể dẫn đến những hậu quả cực kỳ không mong muốn, chưa kể đến việc TRUNCATE và DROP không kịp thời (mặc dù những trường hợp như vậy ít xảy ra hơn nhiều).
Nhân tiện, từ quan điểm này, việc thực hiện không đầy đủ cũng không kém phần nguy hiểm đối với hiệu suất của ứng dụng so với việc thực hiện quá mức.

Như vậy, chúng ta có thể kết luận rằng trong quá trình di chuyển phiên bản, tất cả các yêu cầu phải được thực thi chỉ một lần thôi và sau đó, theo đúng trình tự. Tính nhất quán rất quan trọng vì một số thay đổi có thể phụ thuộc vào những thay đổi khác (như trong ví dụ về trường có thể rỗng).

Nguyên tắc chung về di chuyển phiên bản

Trong phần trước, chúng tôi đã nêu bật các tiêu chí quan trọng hiển thị những gì được yêu cầu trong quá trình di chuyển phiên bản. Cái này:

• thực hiện một lần cho mỗi thay đổi (truy vấn SQL);
• thứ tự thay đổi được xác định trước một cách chặt chẽ.

Bây giờ, hãy nêu bật các tiêu chí thực tế hơn để hiểu những gì cần yêu cầu từ quá trình tạo và lưu trữ di chuyển. Theo tôi, đối với hầu hết các nhóm phát triển, điều quan trọng là:

• để bất kỳ phiên bản nào của cơ sở dữ liệu đều có thể được cập nhật lên bất kỳ phiên bản nào (thường là phiên bản mới nhất);
• sao cho có thể nhận được một tập hợp các truy vấn SQL thực hiện di chuyển giữa hai phiên bản bất kỳ một cách nhanh chóng và dễ dàng nhất có thể;
• để bạn luôn có thể tạo cơ sở dữ liệu từ đầu với cấu trúc của phiên bản mới nhất. Điều này rất hữu ích cả trong quá trình phát triển và thử nghiệm cũng như khi triển khai máy chủ sản xuất mới;
• do đó, trong trường hợp làm việc trên các nhánh khác nhau, trong quá trình hợp nhất tiếp theo của chúng, việc chỉnh sửa thủ công các tệp cơ sở dữ liệu được giảm thiểu;
• do đó việc khôi phục cơ sở dữ liệu về phiên bản cũ cũng dễ dàng như cập nhật lên phiên bản mới hơn.

Lý do di cư

Hóa ra, hầu hết các phương pháp tiếp cận đều có một nguyên tắc chung: chúng cần căn cứ (đường cơ sở) - một số trạng thái tham chiếu của cơ sở dữ liệu mà bạn có thể xây dựng từ đó. Khái niệm này được mô tả khá rõ trong bài viết “Versioning Databases - The Baseline” của Scott Allen.

Nói một cách đơn giản, nền tảng là kết cấu của cấu trúc cơ sở dữ liệu cho một phiên bản được coi là phiên bản cơ sở. Có trong tay căn cứ, bạn luôn có thể tạo cơ sở dữ liệu từ đầu sau này. Sau khi áp dụng tất cả các di chuyển được tạo trong quá trình phát triển vào cơ sở dữ liệu này, chúng ta sẽ có được cơ sở dữ liệu có cấu trúc của phiên bản mới nhất.

Phương pháp thay đổi gia tăng

Phương pháp này được mô tả rõ ràng trong bài viết “Xây dựng phiên bản cơ sở dữ liệu – Thay đổi tập lệnh” của Scott Allen. Một cách tiếp cận tương tự cũng được mô tả trong bài viết “Quản lý tập lệnh SQL và tích hợp liên tục” của Michael Balon.

Cấu trúc tập tin

Một ví dụ về thư mục chứa các tệp di chuyển có thể trông như thế nào trong trường hợp này:

Cơ sở dữ liệu
|- Baseline.sql
|- 0001.03 .01.sql
|- 0002.03 .01.sql
|- 0003.03 .01.sql
|- 0004.03 .02.sql
|- 0005.03 .02.sql
|- 0006.03 .02.sql
"- 0007.03 .02.sql

Trong ví dụ này, thư mục lưu trữ tất cả các tệp được tạo trong quá trình phát triển phiên bản 03 . Tuy nhiên, thư mục này có thể dùng chung cho tất cả các phiên bản của ứng dụng.

Trong mọi trường hợp, tệp đầu tiên sẽ xuất hiện trong thư mục đó là căn cứ(Baseline.sql). Sau đó, mọi thay đổi trong cơ sở dữ liệu sẽ được gửi tới kho lưu trữ dưới dạng tệp di chuyển mới có tên như [số tệp].[version].[subversion].sql .

Thực tế, trong ví dụ này, tên tệp chứa số phiên bản đầy đủ của cơ sở dữ liệu. Nghĩa là, sau khi thực hiện một tệp di chuyển có tên 0006 Cơ sở dữ liệu .03.02.sql sẽ được cập nhật từ trạng thái tương ứng với phiên bản 03.02. 0005 , lên tới phiên bản 03.02. 0006 .

Lưu trữ lịch sử phiên bản

Bước tiếp theo là thêm một bảng đặc biệt vào cơ sở dữ liệu, bảng này sẽ lưu trữ lịch sử của tất cả các thay đổi trong cơ sở dữ liệu.

TẠO Lịch sử di chuyển bảng
ID INT,
Phiên bản chính VARCHAR (2),
Phiên bản nhỏVARCHAR(2),
Số tệp VARCHAR(4),
Bình luận VARCHAR (255),
Ngày áp dụng DATETIME

KHÓA CHÍNH (Id)
)

Đây chỉ là một ví dụ về hình thức của bảng. Nếu cần thiết, nó có thể được đơn giản hóa và bổ sung.

Trong tệp Baseline.sql, bạn sẽ cần thêm bản ghi đầu tiên vào bảng này:

CHÈN VÀO
Lịch sử di chuyển (MajorVersion, MinorVersion, FileNumber, Comment, DateApplied)
GIÁ TRỊ ("03", "01", "0000", "Đường cơ sở", NOW())

Sau khi hoàn thành mỗi tệp di chuyển, một bản ghi chứa tất cả dữ liệu di chuyển sẽ được nhập vào bảng này.
Phiên bản cơ sở dữ liệu hiện tại có thể được lấy từ bản ghi có ngày tối đa.

Tự động thực hiện di chuyển

Bước cuối cùng của phương pháp này là một chương trình/tập lệnh sẽ cập nhật cơ sở dữ liệu từ phiên bản hiện tại lên phiên bản mới nhất.

Việc thực hiện di chuyển cơ sở dữ liệu tự động khá đơn giản, bởi vì... Bạn có thể lấy số lần di chuyển hoàn thành cuối cùng từ bảng MigrationHistory và sau đó tất cả những gì còn lại là áp dụng tất cả các tệp có số cao hơn. Bạn có thể sắp xếp các tệp theo số lượng, do đó sẽ không có vấn đề gì với thứ tự thực hiện di chuyển.

Tập lệnh như vậy cũng chịu trách nhiệm thêm các bản ghi về các lần di chuyển đã hoàn thành vào bảng MigrationHistory.

Để thuận tiện hơn, tập lệnh như vậy có thể tạo phiên bản hiện tại của cơ sở dữ liệu từ đầu, trước tiên là đưa vào cơ sở dữ liệu căn cứ rồi thực hiện thao tác di chuyển tiêu chuẩn sang phiên bản mới nhất.

Ưu, nhược điểm, kết luận

Di chuyển nhanh chóng và dễ dàng sang phiên bản mới nhất;
Cơ chế đánh số phiên bản Số phiên bản hiện tại được lưu trữ trực tiếp trong cơ sở dữ liệu;
Để thuận tiện tối đa, cần có các công cụ tự động hóa di chuyển;
Thật bất tiện khi thêm nhận xét vào cấu trúc cơ sở dữ liệu. Nếu bạn thêm chúng vào Baseline.sql thì chúng sẽ biến mất trong phiên bản tiếp theo, bởi vì phần đế sẽ được tạo lại từ đầu, dưới dạng kết xuất của phiên bản mới của cấu trúc. Ngoài ra, những nhận xét như vậy sẽ nhanh chóng trở nên lỗi thời;
Các vấn đề phát sinh trong quá trình phát triển song song ở một số nhánh của kho lưu trữ. Vì việc đánh số các tệp di chuyển là tuần tự nên các tệp có truy vấn DDL/DML khác nhau có thể xuất hiện dưới cùng một số trong các nhánh khác nhau. Do đó, khi hợp nhất các nhánh, bạn sẽ phải chỉnh sửa thủ công các tệp và trình tự của chúng hoặc trong một nhánh mới, “đã hợp nhất”, bắt đầu với Baseline.sql mới có tính đến các thay đổi từ cả hai nhánh.

Phương pháp này khá phổ biến dưới nhiều hình thức khác nhau. Ngoài ra, nó có thể dễ dàng đơn giản hóa và sửa đổi để phù hợp với nhu cầu của dự án.
Trên Internet, bạn có thể tìm thấy các tập lệnh được tạo sẵn để di chuyển gia tăng và nhúng chúng vào dự án của mình.

Phương pháp thay đổi bình thường

Phương pháp này được mô tả trong bài viết “Tập lệnh thay đổi Sql chống đạn bằng cách sử dụng INFORMATION_SCHEMA Views” của Phil Hack. Cách tiếp cận tương tự cũng được mô tả trong câu trả lời cho câu hỏi này trên StackOverflow.

Tính bình thường đề cập đến thuộc tính của một đối tượng không thay đổi khi một nỗ lực khác được thực hiện để thay đổi nó.
Tôi nhớ một chủ đề vui nhộn bối cảnh của bạn bè":)

Ý tưởng chính của phương pháp này là ghi các tệp di chuyển theo cách mà chúng có thể được thực thi nhiều lần trên cơ sở dữ liệu. Lần đầu tiên bạn thử thực thi bất kỳ lệnh SQL nào, các thay đổi sẽ được áp dụng; Sẽ không có gì xảy ra ở tất cả những lần thử tiếp theo.

Cách dễ nhất để hiểu ý tưởng này là bằng một ví dụ. Giả sử bạn cần thêm một bảng mới vào cơ sở dữ liệu. Nếu bạn muốn đảm bảo rằng truy vấn không gây ra lỗi nếu nó đã tồn tại, MySQL có một cú pháp ngắn cho mục đích này:

TẠO BẢNG NẾU KHÔNG TỒN TẠI bảng của tôi
id INT (10) KHÔNG NULL,

KHÓA CHÍNH (id)
);

Nhờ từ khóa IF NOT EXISTS, MySQL sẽ chỉ cố gắng tạo bảng nếu bảng có tên đó chưa tồn tại. Tuy nhiên, cú pháp này không có sẵn trong tất cả các DBMS; Hơn nữa, ngay cả trong MySQL nó cũng không thể được sử dụng cho tất cả các lệnh. Vì vậy, hãy xem xét một phương pháp phổ quát hơn:

NẾU KHÔNG TỒN TẠI
LỰA CHỌN *
TỪ information_schema.tables
Ở ĐÂU tên_bảng = "myTable"
VÀ bảng_schema = "myDb"
SAU ĐÓ
TẠO BẢNG myTable
id INT (10) KHÔNG NULL,
myField VARCHAR (255) NULL ,
KHÓA CHÍNH (id)
);
KẾT THÚC NẾU ;

Trong ví dụ trước, tham số biểu thức điều kiện là một truy vấn kiểm tra xem bảng myTable có tồn tại trong cơ sở dữ liệu có tên myDb hay không. Và chỉ khi bảng bị thiếu thì nó mới thực sự được tạo. Vì vậy, truy vấn trên là bình thường.

Điều đáng lưu ý là vì lý do nào đó MySQL không cho phép chạy các truy vấn DDL bên trong các câu lệnh có điều kiện. Nhưng lệnh cấm này rất dễ bị bỏ qua - chỉ cần đưa tất cả các yêu cầu đó vào phần nội dung của thủ tục được lưu trữ:

DẤU HIỆU $$

TẠO THỦ TỤC sp_tmp() BẮT ĐẦU

NẾU KHÔNG TỒN TẠI
--
-- Tình trạng.
--
SAU ĐÓ
--
-- Một truy vấn làm thay đổi cấu trúc của cơ sở dữ liệu.
--
KẾT THÚC NẾU ;

KẾT THÚC ;
$$

GỌI sp_tmp();

THỦ TỤC THẢ sp_tmp;

information_schema là loại chim gì?

Thông tin đầy đủ về cấu trúc cơ sở dữ liệu có thể được lấy từ các bảng hệ thống đặc biệt nằm trong cơ sở dữ liệu có tên information_schema. Cơ sở dữ liệu này và các bảng của nó là một phần của tiêu chuẩn SQL-92, vì vậy phương pháp này có thể được sử dụng trên bất kỳ DBMS hiện đại nào. Ví dụ trước sử dụng bảng information_schema.tables để lưu trữ thông tin về tất cả các bảng. Theo cách tương tự, bạn có thể kiểm tra sự tồn tại và siêu dữ liệu của các trường bảng, thủ tục được lưu trữ, trình kích hoạt, lược đồ và trên thực tế là bất kỳ đối tượng nào khác trong cấu trúc cơ sở dữ liệu.

Danh sách đầy đủ các bảng với thông tin chi tiết về mục đích của chúng có thể được tìm thấy trong nội dung của tiêu chuẩn. Bạn có thể xem danh sách ngắn trong bài viết nêu trên của Phil Hack. Nhưng tất nhiên, cách dễ nhất là chỉ cần mở cơ sở dữ liệu này trên bất kỳ máy chủ cơ sở dữ liệu đang hoạt động nào và xem nó hoạt động như thế nào.

Ví dụ sử dụng

Như vậy, bạn đã biết cách tạo các truy vấn SQL bình thường. Bây giờ hãy xem cách tiếp cận này có thể được áp dụng như thế nào trong thực tế.

Một ví dụ về thư mục chứa các tệp sql có thể trông như thế nào trong trường hợp này:

Cơ sở dữ liệu
|- 3.01
| |- Baseline.sql
| "-Changes.sql
"- 3.02
|- Baseline.sql
"-Changes.sql

Ví dụ này tạo một thư mục riêng cho từng phiên bản nhỏ của cơ sở dữ liệu. Bất cứ khi nào một thư mục mới được tạo, một cơ sở sẽ được tạo và ghi vào Baseline.sql. Sau đó, trong quá trình phát triển, tất cả các thay đổi cần thiết sẽ được ghi vào tệp Changes.sql dưới dạng truy vấn bình thường.

Giả sử rằng trong quá trình phát triển, tại các thời điểm khác nhau, các lập trình viên cần những thay đổi sau đối với cơ sở dữ liệu:
a) tạo bảng myTable;
b) thêm trường mới vào nó;
c) thêm một số dữ liệu vào bảng myTable.

Tất cả ba thay đổi đều được viết để không lặp lại. Kết quả là, bất kể cơ sở dữ liệu đang ở trạng thái trung gian nào, việc thực thi tệp Changes.sql sẽ luôn di chuyển sang phiên bản mới nhất.

Ví dụ: một trong những nhà phát triển đã tạo bảng myTable trên bản sao cơ sở dữ liệu cục bộ của mình, viết thay đổi a) vào tệp Changes.sql được lưu trữ trong kho lưu trữ mã chung và đã quên mất nó trong một thời gian. Bây giờ nếu anh ta thực thi tệp này trên DB cục bộ của mình, thay đổi a) sẽ bị bỏ qua và những thay đổi b) và c) sẽ được áp dụng.

Ưu, nhược điểm, kết luận

Việc triển khai di chuyển từ bất kỳ phiên bản trung gian nào sang phiên bản mới nhất rất thuận tiện - bạn chỉ cần thực thi một tệp trên cơ sở dữ liệu (Changes.sql);
Có những tình huống có khả năng dữ liệu sẽ bị mất; điều này sẽ phải được theo dõi. Một ví dụ là bỏ một bảng rồi tạo một bảng khác có cùng tên. Nếu chỉ chọn tên khi xóa, thì cả hai thao tác (xóa và tạo) sẽ xảy ra mỗi khi tập lệnh được thực thi, mặc dù thực tế là chúng đã được thực hiện;
Để các thay đổi trở nên bình thường, bạn cần dành nhiều thời gian (và viết mã) hơn để viết chúng.

Do việc cập nhật cơ sở dữ liệu lên phiên bản mới nhất rất đơn giản và có thể được thực hiện thủ công nên phương pháp này hoạt động tốt nếu bạn có nhiều máy chủ sản xuất và cần cập nhật chúng thường xuyên.

Phương pháp đồng hóa cấu trúc cơ sở dữ liệu với mã nguồn

Thật không may, tôi không tìm thấy bất kỳ bài viết riêng biệt nào dành cho phương pháp này. Tôi sẽ biết ơn các liên kết đến các bài viết hiện có, nếu có. CẬP NHẬT: Trong bài viết của mình, Absent nói về kinh nghiệm thực hiện một cách tiếp cận tương tự bằng cách sử dụng tiện ích tìm khác biệt được viết tại nhà.

Ý tưởng chính của phương pháp này được phản ánh trong tiêu đề: cấu trúc cơ sở dữ liệu có cùng mã nguồn với mã PHP, C# hoặc HTML. Do đó, thay vì lưu trữ các file di chuyển (với các truy vấn làm thay đổi cấu trúc cơ sở dữ liệu) trong kho mã, bạn chỉ cần lưu trữ cấu trúc cơ sở dữ liệu thực tế - ở dạng khai báo.

Ví dụ triển khai

Để đơn giản cho ví dụ, chúng tôi sẽ giả định rằng trong mỗi bản sửa đổi của kho lưu trữ sẽ luôn chỉ có một tệp SQL: CreateDatabase.sql. Trong dấu ngoặc đơn, tôi lưu ý rằng tương tự như mã nguồn, bạn có thể tiến xa hơn nữa và lưu trữ cấu trúc của từng đối tượng cơ sở dữ liệu trong một tệp riêng biệt. Ngoài ra, cấu trúc có thể được lưu trữ dưới dạng XML hoặc các định dạng khác được DBMS của bạn hỗ trợ.

Tệp CreateDatabase.sql sẽ lưu trữ các lệnh CREATE TABLE , CREATE PROCEDURE , v.v. để tạo toàn bộ cơ sở dữ liệu từ đầu. Nếu cần thay đổi cấu trúc bảng, những thay đổi này sẽ được thực hiện trực tiếp đối với các truy vấn DDL hiện có để tạo bảng. Điều tương tự cũng xảy ra với những thay đổi đối với các thủ tục được lưu trữ, trình kích hoạt, v.v.

Ví dụ: phiên bản hiện tại của kho lưu trữ đã có bảng myTable và trong tệp CreateDatabase.sql, nó trông như thế này:

TẠO BẢNG myTable
id INT (10) KHÔNG NULL,
myField VARCHAR (255) NULL ,
KHÓA CHÍNH (id)
);

Nếu cần thêm trường mới vào bảng này, bạn chỉ cần thêm trường đó vào truy vấn DDL hiện có:

TẠO BẢNG myTable
id INT (10) KHÔNG NULL,
myField VARCHAR (255) NULL ,
trường mới INT(4) KHÔNG NULL,
KHÓA CHÍNH (id)
);

Sau đó, tệp sql đã sửa đổi sẽ được gửi đến kho lưu trữ mã.

Thực hiện di chuyển giữa các phiên bản

Trong phương pháp này, quy trình cập nhật cơ sở dữ liệu lên phiên bản mới hơn không đơn giản như các phương pháp khác. Vì chỉ có mô tả khai báo về cấu trúc được lưu trữ cho mỗi phiên bản, nên đối với mỗi lần di chuyển, bạn sẽ phải tạo ra sự khác biệt ở dạng truy vấn ALTER -, DROP - và CREATE -. Các tiện ích tìm khác biệt tự động sẽ giúp bạn điều này, chẳng hạn như Công cụ đồng bộ hóa lược đồ, có trong SQLyog, TOAD, có sẵn cho nhiều DBMS,

Phát triển các yêu cầu chung cho việc di chuyển dữ liệu

Là một phần của việc phát triển các yêu cầu di chuyển dữ liệu tổng thể, nhà phân tích kinh doanh nên xác định chiến lược di chuyển dữ liệu. Căn cứ vào nhu cầu của doanh nghiệp và phương thức hoạt động của tổ chức khách hàng nên lựa chọn di chuyển “bùng nổ” hay di chuyển suôn sẻ.

Khi chọn chiến lược “vụ nổ lớn”, phải xác định khoảng thời gian mà doanh nghiệp có thể gặp phải thời gian ngừng hoạt động trong quá trình di chuyển dữ liệu. Sau khi xác định lượng thời gian doanh nghiệp có thể ngừng hoạt động trong quá trình di chuyển dữ liệu, có thể tạo lịch di chuyển dữ liệu. Khi lên lịch di chuyển dữ liệu, nên phân bổ một hoặc nhiều ngày dự trữ để di chuyển lại trong trường hợp có lỗi nghiêm trọng.

Khi chọn chiến lược di chuyển suôn sẻ, tất cả người dùng doanh nghiệp của hệ thống đích phải được chia thành các nhóm để lập lịch trình chuyển sang làm việc với hệ thống đích. Khi người dùng doanh nghiệp được chia thành các nhóm, các tập dữ liệu và thực thể tương ứng của họ phải được xác định. Khi phân chia người dùng doanh nghiệp thành các nhóm, mối quan hệ của các nhóm này trong quy trình kinh doanh được tự động hóa trong hệ thống đích phải được tính đến.

Song song với việc lựa chọn chiến lược di chuyển dữ liệu, người quản lý dự án và/hoặc nhà phân tích kinh doanh nên xác định các rủi ro di chuyển dữ liệu điển hình. Đối với mỗi rủi ro được xác định, phải lựa chọn một chiến lược (phương pháp) để xử lý rủi ro và xây dựng một loạt các biện pháp ngăn ngừa rủi ro. Chiến lược phòng ngừa rủi ro có thể là một trong những chiến lược sau:

• Từ chối các hoạt động quá rủi ro (phương pháp từ chối),
• · phòng ngừa hoặc đa dạng hóa (phương pháp giảm thiểu),
• · Gia công các chức năng rủi ro tốn kém (phương pháp chuyển giao),
• · hình thành dự trữ hoặc tồn kho (phương pháp chấp nhận).

Bảng 1 cho thấy ma trận các rủi ro di chuyển dữ liệu điển hình và cách giải quyết từng rủi ro này. Các ô ma trận cung cấp ví dụ về các hoạt động xử lý từng rủi ro trong từng phương pháp phòng ngừa rủi ro.

Khi biên soạn bảng, người ta cho rằng chiến lược "Từ chối" không được nhóm dự án chấp nhận vì điều kiện tiên quyết cho nghiên cứu là nhu cầu thực hiện công việc di chuyển. Vì vậy, không có khả năng loại trừ hoàn toàn hoặc một phần công việc đó khỏi phạm vi dự án.

Bảng 1 Ma trận rủi ro và chiến lược khả thi để xử lý rủi ro trong giai đoạn di cư

Chiến lược quản lý rủi ro		Sự suy sụp	Phát tin	Nhận con nuôi
Rủi ro khi viết đặc tả kỹ thuật		Xây dựng các yêu cầu di chuyển cùng với doanh nghiệp, chủ sở hữu và người tiêu dùng dữ liệu được di chuyển	Sự tham gia của tư vấn trong việc chuẩn bị các thông số kỹ thuật	Hình thành ngân sách và thời gian dự trữ để dự án hoạt động với các yêu cầu thay đổi tiềm năng
Rủi ro thử nghiệm		Phát triển các kế hoạch và kịch bản thử nghiệm với sự tham gia của người dùng doanh nghiệp	Chuyển gói công việc thử nghiệm cho một nhóm riêng biệt với các điều kiện được xác định trước để chấp nhận kết quả của họ	Hình thành quỹ dự trữ thời gian và ngân sách cho công việc bổ sung tiềm năng do việc kiểm tra phần mềm di chuyển và dữ liệu được lưu trữ chưa hoàn chỉnh
Rủi ro trong quá trình lấy và tải dữ liệu		Xây dựng các yêu cầu đối với việc dỡ tải thử nghiệm. Thực hiện di chuyển "thử nghiệm" bằng cách tải lên thử nghiệm		Hình thành ngân sách và thời gian dự trữ cho các lần tải xuống lặp lại và tải xuống lặp lại
Chiến lược quản lý rủi ro		Sự suy sụp	Phát tin	Nhận con nuôi
Rủi ro liên quan đến công việc của nhóm dự án
Rủi ro khi đặt dữ liệu vào hệ thống mục tiêu		Phát triển song song mô hình dữ liệu “nguyên trạng” và “tồn tại” để loại bỏ sự khác biệt về định dạng và phương pháp làm việc với dữ liệu trong nguồn và bộ thu		Lập quỹ dự trữ thời gian và ngân sách để cải thiện chức năng của hệ thống tiếp nhận

Tổ chức lập kế hoạch công tác di chuyển dữ liệu

Đầu vào của kế hoạch di chuyển dữ liệu là chiến lược di chuyển dữ liệu được xây dựng như một phần của việc phát triển các yêu cầu di chuyển dữ liệu chung.

Kết quả của công việc lập kế hoạch di chuyển dữ liệu phải là một tập hợp các tạo phẩm thiết kế ghi lại trình tự các bước để thực hiện di chuyển dữ liệu. Đầu ra của giai đoạn lập kế hoạch là các thành phần sau của dự án: kế hoạch công việc di chuyển và kế hoạch truyền thông cho giai đoạn di chuyển dữ liệu.

Kế hoạch công việc di chuyển xác định một tập hợp các nhiệm vụ và những người chịu trách nhiệm thực hiện chúng, được phân bổ bằng ma trận RACI. Kế hoạch dự án cho công việc di cư phải bao gồm các gói nhiệm vụ và công việc cho từng giai đoạn di chuyển: từ giai đoạn chuẩn bị đến giai đoạn sau di chuyển. Có tính đến kết quả phân tích kinh nghiệm dự án, một WBS đã được phát triển để tránh rủi ro và tương ứng với các phương pháp tiếp cận lý thuyết “tham khảo” để tổ chức di chuyển dữ liệu.

Hiển thị trong hình. 3, cấu trúc công việc bao gồm tất cả các giai đoạn di chuyển và có thể được truy tìm theo các dòng của kế hoạch làm việc của dự án. Là một phần của kế hoạch làm việc của dự án, phải xác định thời hạn hoàn thành từng nhiệm vụ và phải nêu rõ kết quả đầu ra của từng nhiệm vụ. Khi lập kế hoạch làm việc cho từng nhiệm vụ phải xác định một điều kiện, việc thực hiện điều kiện đó sẽ quyết định rõ ràng rằng nhiệm vụ đã hoàn thành.

Một yếu tố thiết kế quan trọng không kém của giai đoạn di chuyển dữ liệu là kế hoạch truyền thông. Kế hoạch truyền thông ở giai đoạn di chuyển xác định mục tiêu và loại hình tương tác giữa các thành viên trong nhóm dự án, cũng như giữa các thành viên trong nhóm dự án và nhân viên khách hàng - người dùng doanh nghiệp.

Việc chuẩn bị kế hoạch truyền thông cho giai đoạn di chuyển phải dựa trên kế hoạch làm việc đã được lập trước đó. Đối với mỗi nhiệm vụ trong kế hoạch dự án, các thuộc tính sau phải được xác định:

• 1. Chủ đề (chủ đề) giao tiếp.
• 2. Nhu cầu tương tác giữa các nhóm vai trò trong nhóm;

Ai nên tham gia giao tiếp? Những nhóm vai trò nào?

• 3. Loại tương tác nào được chấp nhận?
• 4. Đầu ra của giao tiếp nên là gì?
• 5. Nhu cầu tương tác với nhóm dự án và người dùng doanh nghiệp;
• 6. Ai nên tham gia trao đổi thông tin từ nhóm dự án và từ phía doanh nghiệp?
• 7. Loại tương tác nào có thể chấp nhận được với người dùng doanh nghiệp?
• 8. Kết quả của giao tiếp với người dùng doanh nghiệp là gì?
• 9. Ai nên biết kết quả giao tiếp?

Mẫu kế hoạch truyền thông cho giai đoạn di chuyển dữ liệu được hiển thị trong Bảng 2 bên dưới (Bảng 2).

Bảng 2 Mẫu kế hoạch truyền thông trong giai đoạn di chuyển dữ liệu

Chủ đề truyền thông	cho biết vấn đề hoặc nhiệm vụ chính cần liên lạc này, một phần yêu cầu di chuyển, đối tượng dữ liệu
Thành phần tham gia nhóm dự án	nhóm vai trò và vai trò được chỉ định
Sự cần thiết phải tương tác với doanh nghiệp	dấu hiệu được chỉ định: có hoặc không
Người tham gia kinh doanh	đơn vị chức năng và nhân viên chịu trách nhiệm được chỉ định
Kiểu tương tác	loại tương tác được chỉ định, ví dụ: bằng văn bản, cuộc họp, hội thảo

Phát triển và ghi lại các yêu cầu kinh doanh để di chuyển dữ liệu

Việc phát triển và ghi lại các yêu cầu di chuyển dữ liệu nên được thực hiện theo nhiều giai đoạn. Là một phần của phương pháp đã phát triển, giai đoạn phát triển các yêu cầu kinh doanh về di chuyển dữ liệu cũng sẽ bao gồm bước tiến hành và ghi lại kết quả khảo sát tổ chức khách hàng. Mục đích của giai đoạn phát triển các yêu cầu kinh doanh về di chuyển dữ liệu là phát triển gói yêu cầu hoàn chỉnh đối với phần mềm chuyên dụng để di chuyển dữ liệu, cũng như thành phần dữ liệu được di chuyển sang hệ thống đích.

1. Kiểm tra hệ thống thông tin vận hành

Việc kiểm tra theo trình tự thời gian của hệ thống thông tin vận hành phải là giai đoạn đầu tiên của công việc như một phần của việc xây dựng các yêu cầu về di chuyển dữ liệu.

Một cuộc khảo sát về hệ thống thông tin hiện có như một phần của việc phát triển các yêu cầu di chuyển dữ liệu có thể được thực hiện như một phần của cuộc khảo sát kinh doanh của toàn bộ dự án triển khai IS. Cuộc khảo sát như một phần của việc phát triển các yêu cầu về di chuyển dữ liệu nên nhằm mục đích tạo ra một mô hình dữ liệu "nguyên trạng". Mô hình dữ liệu "nguyên trạng" sẽ giúp chuẩn bị các yêu cầu về thành phần của dữ liệu được di chuyển từ hệ thống nguồn sang hệ thống đích.

Mô hình dữ liệu `as is' mô tả tất cả các đối tượng dữ liệu được sử dụng trong hệ điều hành. Sau khi biên dịch mô hình như vậy, khách hàng sẽ dễ dàng hơn trong việc lựa chọn danh sách các đối tượng dữ liệu để truyền sang hệ thống nhận. Mô hình như vậy nên chỉ ra tên của các thực thể, cũng như mô tả thành phần thuộc tính của chúng và mối quan hệ giữa các thực thể biểu thị số lượng của chúng.

Ngoài mô hình dữ liệu của hệ điều hành, ở giai đoạn khảo sát phải vẽ sơ đồ quy trình nghiệp vụ sử dụng các đối tượng dữ liệu được chọn để chuyển sang hệ thống đích. Các mô hình quy trình nghiệp vụ sẽ cho phép bạn xác định các đối tượng dữ liệu bị thiếu nếu chúng bị bỏ sót khi phân tích mô hình dữ liệu.

Ngoài việc biên soạn mô hình dữ liệu “nguyên trạng”, ở giai đoạn khảo sát phải mô tả các quy tắc làm việc với từ điển, sách tham khảo trong hệ điều hành, cụ thể đối với từng từ điển phải mô tả các điểm sau:

• - Tên từ điển hoặc sách tham khảo;
• - Đơn vị chức năng chịu trách nhiệm quản lý từ điển;
• - Tính sẵn có của việc kiểm tra tính duy nhất đối với mã và giá trị của các mục từ điển;
• - Có sẵn các quy tắc cập nhật thường xuyên các mục trong từ điển;
• - Mô tả các quy tắc làm việc với các mục từ điển đã mất đi tính liên quan của chúng;
• - Nếu việc di chuyển dữ liệu được thực hiện từ nhiều nguồn thì cần mô tả xem có sự trùng lặp từ điển trong một số hệ thống nguồn hay không. Nếu có các từ điển trùng lặp trong một số hệ thống nguồn thì cần phải có mô tả về các quy tắc chống trùng lặp và ánh xạ các bản ghi cho mỗi từ điển;

Định dạng của đặc tả các yêu cầu để di chuyển từ điển từ hệ thống nguồn sang hệ thống đích được đưa ra trong bảng và một ví dụ về việc điền vào đặc tả đó được đưa ra.

2. Xây dựng các yêu cầu hồ sơ dữ liệu cho việc di chuyển

Việc phát triển các yêu cầu về hồ sơ dữ liệu cho việc di chuyển phải có sự tham gia của các nhóm người dùng doanh nghiệp chính phù hợp với kế hoạch truyền thông được phát triển trong quá trình lập kế hoạch di chuyển dữ liệu. Mẫu văn bản và ví dụ điền để ghi kết quả khảo sát được nêu trong Bảng 4 (Bảng 4).

Người dùng doanh nghiệp là nguồn trả lời các câu hỏi về hồ sơ dữ liệu sau đây để di chuyển dữ liệu:

• 1) Dữ liệu được di chuyển có phải là đầu vào cho quy trình kinh doanh được tự động hóa trong hệ thống được thiết kế không? Câu trả lời cho câu hỏi này phải là một bảng mô tả sự tương ứng giữa các đối tượng dữ liệu của hệ thống nguồn và các quy trình kinh doanh được tự động hóa trong hệ thống đích.
• 2) Cần xác định khoảng thời gian nào để di chuyển dữ liệu? Trong trường hợp này, phải tính đến các quy định của các văn bản quy định và tổ chức và hành chính. Câu trả lời cho câu hỏi này phải là một bảng tương ứng giữa đối tượng dữ liệu và khoảng thời gian để tải xuống dữ liệu từ hệ thống nguồn.
• 3) Đối tượng dữ liệu nào của hệ thống đích tương ứng với từng đối tượng dữ liệu của hệ thống nguồn được chọn để di chuyển? Câu trả lời cho câu hỏi này phải là một bảng ánh xạ các đối tượng dữ liệu của hệ thống nguồn và hệ thống đích.
• 4) Có trường hoặc nhóm thuộc tính nào trong thành phần thuộc tính của đối tượng dữ liệu của hệ thống nguồn sẽ không được sử dụng trong hệ thống đích không? Câu trả lời cho câu hỏi này phải là một bảng mô tả thành phần thuộc tính của các đối tượng dữ liệu với cờ sau: được sử dụng/không được sử dụng trong hệ thống đích.
• 5) Có trường hoặc nhóm thuộc tính nào trong thành phần thuộc tính của đối tượng dữ liệu của hệ thống nguồn không tương ứng về kiểu dữ liệu với các trường trong hệ thống đích không? Câu trả lời cho câu hỏi này phải là một bảng mô tả thành phần thuộc tính của các đối tượng dữ liệu có gắn cờ và mô tả về sự không nhất quán.
• 6) Có nâng cấp hệ thống nguồn dẫn đến thay đổi đáng kể về cấu trúc dữ liệu cần di chuyển không? Ví dụ về những thay đổi:
  • - Thay đổi thành phần các thuộc tính bắt buộc;
  • - Thay đổi quy tắc lưu trữ đối tượng dữ liệu;
  • - Thay đổi đáng kể về cấu trúc của đối tượng dữ liệu, dẫn đến thay đổi về khối lượng dữ liệu.

Câu trả lời cho câu hỏi này phải là mô tả về các đối tượng dữ liệu của hệ thống nguồn cùng với mô tả các tính năng làm việc với đối tượng dữ liệu trong khoảng thời gian mà dữ liệu được di chuyển.

7) Đơn vị chức năng hoặc người dùng cụ thể nào là chủ sở hữu dữ liệu? Câu trả lời cho câu hỏi này phải là một bảng tương ứng giữa các đối tượng dữ liệu và nhân viên của khách hàng.

Nhân viên bộ phận CNTT là nguồn lực để trả lời các câu hỏi sau về hồ sơ dữ liệu cần di chuyển:

• 1) Dữ liệu được người dùng doanh nghiệp lựa chọn để di chuyển sang hệ thống đích được lưu trữ vật lý ở đâu? Nguồn dữ liệu là gì: ứng dụng doanh nghiệp, hệ thống hoặc nguồn bên ngoài tổ chức khách hàng? Câu trả lời cho câu hỏi này phải là một bảng tương ứng giữa các đối tượng dữ liệu và bộ lưu trữ của chúng (tên và loại cơ sở dữ liệu, tên bảng/bảng trong cơ sở dữ liệu).
• 2) Thông tin meta của nội dung được di chuyển có cho phép chúng tôi phát triển các thuật toán di chuyển không? Có thể phân tích cấu trúc dữ liệu dựa trên siêu thông tin?
• 3) Có hạn chế về mặt công nghệ của hệ thống nguồn ảnh hưởng đến cấu trúc dữ liệu, hình thức lưu trữ và làm việc với dữ liệu không? Câu trả lời cho câu hỏi này phải là một mô tả đầy đủ về những hạn chế về công nghệ của hệ thống nguồn trong bối cảnh các đối tượng dữ liệu cần di chuyển.

Nhân viên CNTT và người dùng doanh nghiệp phải cùng nhau đánh giá mức độ nghiêm trọng của các lỗi tiềm ẩn khi di chuyển dữ liệu từ hệ thống nguồn sang hệ thống đích. Đặc biệt, người dùng doanh nghiệp và nhân viên bộ phận CNTT nên phân tích mối quan hệ của các đối tượng dữ liệu ở cấp độ cơ sở dữ liệu đang được sử dụng để xác định danh sách các kiểm tra tính toàn vẹn dữ liệu có thể có khi được chuyển sang hệ thống đích.

Việc phát triển các yêu cầu đối với hồ sơ dữ liệu để di chuyển phải được hoàn thành bằng cách nhận bản tải xuống thử nghiệm dữ liệu từ (các) hệ thống nguồn theo hồ sơ dữ liệu đã phát triển. Kết quả tải xuống thử nghiệm sẽ được sử dụng để gỡ lỗi phần mềm di chuyển và đánh giá chất lượng dữ liệu được cung cấp.

• 3. Phát triển các yêu cầu cho một tiện ích di chuyển
• 1) Yêu cầu làm sạch dữ liệu và kiểm tra logic

Sau khi phát triển các yêu cầu đối với hồ sơ dữ liệu để di chuyển, cần phát triển các quy tắc làm sạch hoặc chuyển đổi dữ liệu được tải xuống từ hệ thống nguồn để chúng được đặt chính xác trong hệ thống đích. Với mục đích này, cần phải liên hệ các yêu cầu nghiệp vụ đối với mô hình dữ liệu của hệ thống đang được thiết kế và mô tả mô hình dữ liệu của hệ điều hành.

Với mục đích xác định mức chất lượng dữ liệu, các loại kiểm tra logic sau đây phải được áp dụng trong từng đối tượng dữ liệu đang được di chuyển:

• - Đã điền đầy đủ các thuộc tính bắt buộc chưa?
• - Kiểu dữ liệu vật lý của từng thuộc tính trong hệ thống nguồn và đích có giống nhau không?
• - Độ dài giá trị thuộc tính trong đối tượng dữ liệu có thỏa mãn yêu cầu trong hệ thống đích không?
• - Định dạng lưu trữ dữ liệu (ngày tháng, số thập phân) có đáp ứng yêu cầu trong hệ thống đích không?
• - Việc định danh các đối tượng dữ liệu trong hệ thống nguồn có cho phép phân biệt rõ ràng không?

Các yêu cầu kiểm tra logic phải được ghi lại trong đặc tả chức năng cho tiện ích di chuyển dữ liệu.

Những mâu thuẫn được xác định trong dữ liệu tải xuống có thể được giải quyết theo một trong các cách sau: Dữ liệu có thể bị xóa khỏi quá trình tải xuống nếu nó không có giá trị kinh doanh hoặc được chuyển đổi bằng các thuật toán cụ thể.

Để đặt dữ liệu chính xác vào hệ thống đích, các loại thuật toán chuyển đổi sau có thể được phát triển cho các đối tượng dữ liệu:

• - Các thuộc tính bắt buộc bị thiếu có thể được điền bằng các giá trị được xác định trước - “sơ khai”.
• - Các giá trị thuộc tính có độ dài không đáp ứng yêu cầu của hệ thống đích phải bị cắt bớt.
• - Định dạng ngày tháng của hệ thống nguồn phải được chuyển đổi sang định dạng lưu trữ ngày tháng của hệ thống đích.
• - Định dạng lưu trữ dữ liệu số thập phân phải phù hợp với định dạng lưu trữ dữ liệu số thập phân trong hệ thống đích.
• - Các thuộc tính có kiểu dữ liệu vật lý không phù hợp với yêu cầu của hệ thống đích phải được chuyển đổi. Ví dụ: giá trị văn bản có thể được chuyển thành giá trị số nguyên.

Các yêu cầu về thuật toán làm sạch và chuyển đổi dữ liệu, cũng như các loại đối tượng dữ liệu mà chúng sẽ được áp dụng, phải được ghi lại trong đặc tả chức năng cho tiện ích di chuyển dữ liệu.

2) Yêu cầu đặt tên thực thể trong hệ thống tiếp nhận

Yêu cầu phát triển thuật toán đặt tên thực thể trong hệ thống đích cần được phát triển trong trường hợp không thể áp dụng trong hệ thống đích các thuật toán được sử dụng để đặt tên thực thể trong (các) hệ thống nguồn.

Thuật toán đặt tên, đánh số đối tượng dữ liệu cần được phát triển trong các trường hợp sau:

• - Nếu các đối tượng dữ liệu có cùng ý nghĩa nghiệp vụ được di chuyển từ hai hệ thống nguồn thì hệ thống đích phải sử dụng một thuật toán chung để tạo ra tên và số của chúng.
• - Nếu hệ thống nguồn sử dụng thuật toán để tạo ra các mã số thực thể không còn phù hợp do các văn bản quy định hoặc tổ chức đã thay đổi.
• - Nếu hệ thống nguồn sử dụng thuật toán sinh ra số thực thể không đáp ứng quy tắc nghiệp vụ khi làm việc với các thực thể trong hệ thống được thiết kế.

Yêu cầu về thuật toán tạo tên và số lượng thực thể được di chuyển phải được ghi lại trong đặc tả chức năng của tiện ích di chuyển dữ liệu.

3) Yêu cầu di chuyển dữ liệu ghi nhật ký

Để theo dõi trạng thái của quá trình di chuyển dữ liệu, tiện ích di chuyển phải hỗ trợ ghi nhật ký tải dữ liệu vào hệ thống đích. Trong trường hợp này, nhật ký của tiện ích di chuyển sẽ phản ánh thông tin về tất cả các kiểm tra logic được thực hiện và việc xóa dữ liệu khỏi tập dữ liệu để tải vào hệ thống đích.

Các yêu cầu đối với nhật ký tiện ích di chuyển phải được ghi lại trong đặc tả chức năng cho tiện ích di chuyển.

Nhật ký tiện ích di chuyển sẽ cho phép bạn theo dõi từng thao tác như một phần của quá trình tải dữ liệu vào hệ thống đích.

Mỗi mục nhập nhật ký di chuyển dữ liệu phải có ít nhất bộ thuộc tính sau:

• · Loại đối tượng dữ liệu đang được di chuyển;
• · Hệ thống nguồn;
• · Mã định danh duy nhất của đối tượng dữ liệu trong hệ thống nguồn;
• · Mã định danh duy nhất của đối tượng dữ liệu trong hệ thống tiếp nhận;
• · Ngày và giờ tải đối tượng dữ liệu này;
• · Tên/số được tạo bởi tiện ích di chuyển cho đối tượng dữ liệu này, nếu thuật toán tạo tên/số thực thể được áp dụng cho đối tượng dữ liệu này;
• · Cờ: đối tượng dữ liệu đã được di chuyển sang hệ thống nhận hay đã bị loại khỏi dữ liệu được tải;
• · Lý do tại sao đối tượng bị loại khỏi dữ liệu được tải là do thành phần của các quy tắc và kiểm tra logic;
• · Mô tả lỗi xảy ra trong quá trình di chuyển đối tượng dữ liệu, nếu có.

Thuộc tính Mô tả Lỗi hiển thị thông báo được tham số hóa từ tiện ích di chuyển dữ liệu nếu tiện ích di chuyển không thể tải đối tượng dữ liệu vào hệ thống đích.

Nếu cờ được đặt cho một đối tượng dữ liệu - đối tượng bị xóa khỏi dữ liệu đã di chuyển, thì thuộc tính “Lý do loại trừ việc xóa đối tượng dữ liệu” sẽ hiển thị một thông báo được tham số hóa mô tả thuật toán làm sạch dữ liệu, theo đó đối tượng này đã bị xóa khỏi dữ liệu được di chuyển.

Một đoạn nhật ký tiện ích di chuyển được đưa ra trong Phụ lục 4 (Phụ lục 4 - Đoạn nhật ký tiện ích di chuyển).

Tiến hành thử nghiệm như một phần của công việc di chuyển dữ liệu

Công việc kiểm thử bao gồm các gói công việc sau:

• 1. Thử nghiệm ban đầu phần mềm di chuyển về việc tuân thủ các thông số kỹ thuật;
• 2. Thử nghiệm kinh doanh phần mềm di chuyển để đảm bảo tuân thủ các yêu cầu kinh doanh đối với các thuật toán chuyển đổi dữ liệu trong quá trình di chuyển;
• 4. Kiểm tra chức năng của hệ thống tiếp nhận sau khi đặt dữ liệu đã di chuyển;

Dưới đây là trình tự các bước mà nhóm dự án phải thực hiện để tiến hành từng giai đoạn thử nghiệm.

Thử nghiệm chính của phần mềm di chuyển phải xác định và loại bỏ các lỗi kỹ thuật và khiếm khuyết của tiện ích di chuyển đã phát triển. Việc kiểm tra như vậy phải được thực hiện bởi một nhóm người kiểm tra theo các trường hợp kiểm thử đã phát triển. Đồng thời, sau khi sửa đổi phần mềm, trường hợp xác định được lỗi thì bắt buộc phải tiến hành kiểm thử hồi quy của tiện ích.

Việc kiểm tra nghiệp vụ của phần mềm di chuyển để đảm bảo tuân thủ các yêu cầu nghiệp vụ và thuật toán chuyển đổi dữ liệu phải được thực hiện bằng cách sử dụng nhật ký tiện ích di chuyển để đảm bảo tính đầy đủ của các hoạt động kiểm tra và thử nghiệm. Quy trình kiểm thử doanh nghiệp có thể như sau:

• 1. Xác định các đối tượng dữ liệu bị bỏ qua trong quá trình tải từ nhật ký tiện ích di chuyển.
• 2. Đảm bảo rằng các đối tượng này trong hệ thống nguồn thỏa mãn các điều kiện áp dụng cơ chế kiểm tra logic hoặc chuyển đổi.
• 3. Nếu phát hiện thấy sự khác biệt, hãy ghi lại lỗi trong tiện ích di chuyển.

Các lỗi được ghi lại trong quá trình kiểm tra phải được ghi lại theo cách có thể xác định rõ ràng nguồn gốc xuất hiện của chúng - một thuật toán hoặc quy tắc hoạt động không chính xác.

Các công cụ kiểm tra tự động có thể được sử dụng để kiểm tra doanh nghiệp tiện ích di chuyển. Nếu chúng không có sẵn, bộ kiểm thử đơn vị sẽ bao gồm tất cả các loại đối tượng dữ liệu có thể đã được di chuyển sang hệ thống đích, cũng như tất cả các cơ chế kiểm tra và chuyển đổi được thiết kế cho từng loại.

Kiểm tra việc làm sạch và tải dữ liệu liên quan đến việc làm việc với dữ liệu thu được sau khi phát triển gói yêu cầu đối với hồ sơ dữ liệu được di chuyển. Tải lên thử nghiệm phải là một công cụ để kiểm tra các đặc điểm sau của phần mềm di chuyển:

• - Công tác giải thuật nghiệp vụ, kiểm tra logic và cơ chế chuyển đổi trên dữ liệu thực;
• - Hiệu suất của phần mềm di chuyển trên khối lượng dữ liệu gần đạt hiệu quả.

Làm việc với quá trình dỡ tải thử nghiệm là giai đoạn cuối cùng của quá trình di chuyển thử nghiệm phần mềm. Sau khi tiện ích di chuyển xử lý tải lên thử nghiệm, có thể ước tính thời gian dự kiến ​​cần thiết để tải toàn bộ mảng dữ liệu được di chuyển. Việc tải lên thử nghiệm thành công trên hệ thống nhận phải có nghĩa là sự chấp nhận nội bộ đối với tiện ích di chuyển và khả năng tiếp tục tải bản tải xuống sản xuất - dỡ bỏ hoàn toàn từ hệ thống nguồn sang hệ thống đích.

Kiểm tra việc làm sạch và tải dữ liệu vào hệ thống nhận bao gồm việc thực hiện tất cả các hoạt động cần thiết để di chuyển dữ liệu sang hệ thống đích, bao gồm kiểm tra chức năng của hệ thống nhận. Giai đoạn thử nghiệm này được mô tả chi tiết hơn dưới đây.

Việc kiểm tra chức năng của hệ thống nhận phải đảm bảo rằng tất cả các chức năng hệ thống sử dụng nội dung được di chuyển đều hoạt động bình thường. Trong trường hợp này, việc kiểm tra như vậy có thể được thực hiện theo hai giai đoạn:

• 1. Kiểm tra hoạt động của hệ thống tiếp nhận;
• 2. Kiểm tra chi tiết chức năng của hệ thống tiếp nhận.

Để kiểm tra chức năng của hệ thống nhận, ngay sau khi quá trình tải xuống hoàn tất, một tập lệnh kiểm tra ngắn phải được soạn thảo, trong đó nêu rõ chính xác những gì cần kiểm tra chức năng, ví dụ:

• - danh sách các biểu mẫu màn hình cần được mở,
• - số lượng đối tượng trong thư mục (từ điển) mà người dùng có thể nhìn thấy;
• - số lượng đối tượng trong sổ đăng ký hệ thống mà người dùng sẽ hiển thị,
• - danh sách các chức năng hệ thống phải được khởi chạy (tạo báo cáo, công cụ tìm kiếm, truy cập vào các đối tượng dữ liệu đã di chuyển).

Kiểm tra chi tiết chức năng của hệ thống tiếp nhận bao gồm việc khởi chạy tất cả các quy trình kinh doanh tự động mà dữ liệu đầu vào là dữ liệu được di chuyển. Nếu dữ liệu được tải bao gồm nhiều loại đối tượng dữ liệu thì phải cung cấp tập lệnh kiểm tra cho từng loại dữ liệu được di chuyển. Kết quả kiểm tra chức năng của hệ thống tiếp nhận phải được ghi lại vào nhật ký kiểm tra.

Theo tiêu chuẩn ANSI, nhật ký kiểm tra di chuyển dữ liệu phải có cấu trúc sau:

• 1. ID ca kiểm thử;
• 2. Mô tả hoạt động trong test case;
• 3. Mô tả lỗi trong quá trình thực hiện thao tác trong trường hợp kiểm thử;
• 4. Ảnh hưởng của lỗi đến chức năng của hệ thống;
• 5. Ảnh hưởng của lỗi đến hoạt động kiểm tra liên quan.

Mô tả hoạt động trong trường hợp thử nghiệm nhất thiết phải bao gồm:

a) Dữ liệu đầu vào phục vụ hoạt động;

b) Kết quả dự kiến;

c) Kết quả đạt được;

d) Ngày, giờ thực hiện hoạt động;

e) Số lần thực hiện thao tác;

f) Các thành viên trong nhóm dự án chịu trách nhiệm thử nghiệm;

g) Môi trường hoạt động trong trường hợp thử nghiệm.

Một đoạn nhật ký kiểm tra chức năng của hệ thống tiếp nhận được đưa ra trong Phụ lục 5 (Phụ lục 5 - Nhật ký kiểm tra kết quả di chuyển).

Leif Poulsen cho InTech

Các hệ thống tự động hóa sản xuất và thu thập thông tin về quy trình sản xuất có thời gian tồn tại tương đối ngắn. Chúng thường phải được nâng cấp hoặc thay thế trước khi thiết bị xử lý hết tuổi thọ. Đối với nhiều công ty, việc quản lý việc thay thế hoặc nâng cấp các hệ thống tự động hóa như vậy mà không ngừng sản xuất là một thách thức thực sự. Vì vậy, nhu cầu khách quan về hiện đại hóa hoặc thay thế sẽ bị bỏ qua cho đến khi có điều gì đó xảy ra. Bài viết này nói về cách bạn có thể hoàn thành thành công nhiệm vụ này thông qua việc lập kế hoạch và tổ chức cẩn thận.

Hai yếu tố chính dẫn đến nhu cầu hiện đại hóa và thay thế các hệ thống tự động hóa công nghiệp và hệ thống CNTT công nghiệp: sự xuống cấp về mặt kỹ thuật của các hệ thống này cũng như những thay đổi về yêu cầu của quy trình kinh doanh mà các hệ thống này hỗ trợ.

Độ tin cậy của hệ thống kỹ thuật sẽ giảm theo thời gian nếu các công ty bỏ qua nhu cầu hiện đại hóa hệ điều hành, cơ sở dữ liệu và phần mềm ứng dụng. Rủi ro vận hành do lỗi thiết bị cũng tăng theo.

Thông qua việc lập kế hoạch cẩn thận, rủi ro hoạt động có thể được giữ ở mức chấp nhận được, đồng thời bảo vệ các khoản đầu tư và giảm thiểu chi phí vòng đời. Đối với một hệ thống CNTT hoặc tự động hóa điển hình, chỉ 20-40% khoản đầu tư được dùng để mua hệ thống. 60-80% còn lại dùng để duy trì tính sẵn sàng cao và thích ứng với các yêu cầu thay đổi định kỳ.

Ngoài việc đánh giá các hoạt động cần thiết để ngăn ngừa suy thoái kỹ thuật, cần xem xét những thách thức mới cũng như các cơ hội kinh doanh tiềm năng. Môi trường kinh doanh luôn thay đổi và mọi cơ hội cải tiến công nghệ hiện có hoặc giới thiệu công nghệ mới luôn phải được xem xét. Các cơ hội kinh doanh điển hình có thể thúc đẩy sự di chuyển của các hệ thống tự động hóa chi phí cao là tốc độ tiếp cận thị trường, khả năng cạnh tranh, tăng trưởng, chất lượng và tuân thủ quy định.

Kế hoạch di cư dài hạn

Việc phát triển kế hoạch di chuyển hệ thống dài hạn cho phép các công ty duy trì rủi ro vận hành hệ thống ở mức chấp nhận được. Ngoài ra, nó còn đảm bảo quản lý rủi ro và hỗ trợ kịp thời các mục tiêu kinh doanh. Kế hoạch di chuyển phải tính đến các hạn chế như “phương pháp sản xuất tốt nhất”, chức năng công nghệ và thời gian ngừng sản xuất không thể tránh khỏi.

Nhìn chung, cách tiếp cận quy hoạch dài hạn được mô tả trong Hình 1. Một kế hoạch di chuyển được phát triển để xác định nơi công ty muốn đạt được trong 5 năm tới, những hành động cần thực hiện để đạt được điều đó và liệu các nguồn lực cần thiết để đạt được điều đó có sẵn hay không. Cách tiếp cận này dựa trên các nguyên tắc thiết kế kiến ​​trúc được nêu trong tiêu chuẩn TOGAF, được sử dụng rộng rãi trong việc phát triển kiến ​​trúc hệ thống cho các doanh nghiệp công nghiệp.

Hình 1. Cách tiếp cận chung để lập kế hoạch di cư dài hạn.

Cần phải phân biệt giữa kiến ​​trúc hiện tại và kiến ​​trúc mục tiêu mong muốn. Sự khác biệt giữa chúng phản ánh sự khác biệt giữa vị thế hiện tại của công ty và vị trí mà công ty muốn chiếm giữ trong tương lai. Kế hoạch di chuyển vạch ra đường đi từ kiến ​​trúc hiện tại đến kiến ​​trúc đích - có thể thông qua một số giai đoạn chuyển tiếp.

Mỗi kiến ​​trúc có thể được mô tả như một loạt các "lớp" thu hẹp khoảng cách giữa hoạt động kinh doanh và công nghệ - như trong Hình 1. 1. Phải chú ý đến các “lớp” sau:

• Mục tiêu kinh doanh nó là một phần của nỗ lực hoạch định chiến lược tổng thể. Chúng cho phép bạn chọn đúng hướng của quá trình.
• Mô hình kinh doanh cung cấp bối cảnh trong đó các quy trình sản xuất và kinh doanh được hiểu rõ. Thông thường, nó bao gồm mô tả cấp cao về dòng nguyên liệu và quy trình.
• Sự miêu tả quá trình sản xuất kinh doanh rất quan trọng để ứng dụng thành công công nghệ và đánh giá chính xác giá trị của chúng theo quan điểm kinh doanh.
• Thông tin, dữ liệu và tài liệu quan trọng để kết nối các tiến trình và ứng dụng. Khả năng tương tác và quản lý luồng thông tin giữa các ứng dụng đặc biệt quan trọng.
• Mô tả các ứng dụng cho phép bạn xây dựng các yêu cầu cấp cao và xác định giao diện.
• Sự định nghĩa Cơ sở hạ tầng, máy tính và mạng yêu cầu (phần cứng, khả năng chịu lỗi, hiệu suất).
• Cung cấp dịch vụ xác định các yêu cầu để đảm bảo quản lý hoạt động hiệu quả và hỗ trợ quyết định.

Xây dựng kế hoạch di cư

Phát triển kế hoạch di chuyển cho toàn bộ tổ chức, hoặc thậm chí cho một cơ sở sản xuất duy nhất, có thể là một nhiệm vụ thực sự phức tạp với sự tham gia của nhiều người. Nên chia quá trình phát triển thành nhiều giai đoạn, được mô tả dưới đây.

Phần II

Giai đoạn 1: Huy động

Mục tiêu cơ bản:

• đạt được sự hiểu biết chung về nhiệm vụ và mục tiêu
• huy động tổ chức nơi dự án được lên kế hoạch
• chi tiết hóa kế hoạch bằng cách mô tả các mốc quan trọng và kết quả của các giai đoạn dự án
• thu thập tất cả thông tin cần thiết/có sẵn
• cung cấp sự hiểu biết đúng đắn về các khái niệm, thực tiễn và lý thuyết

• những cuộc họp đã được lên kế hoạch
• hội thảo dành riêng cho việc bắt đầu dự án

Kết quả:

• kế hoạch tư vấn chi tiết
• Những mục đích chung
• tổng quan về quy trình

Giai đoạn 2: Phân tích

Mục tiêu của giai đoạn phân tích là:

• phân tích quá trình sản xuất kinh doanh nhằm:

Đánh giá mức độ sẵn sàng của nhân sự phục vụ hệ thống CNTT và tự động hóa

Hiểu nhu cầu về dữ liệu và chức năng cho kiến ​​trúc trong tương lai

Xác định các lợi ích chính của kiến ​​trúc tương lai để đặt mục tiêu và triển khai đề án kinh doanh

• phân tích kiến ​​trúc hiện có

Xác định các quy trình sản xuất hiện có trong mối liên hệ của chúng với các hệ thống tự động hóa, thu thập dữ liệu, hệ thống quản lý sản xuất

Xác định các quy trình kinh doanh hiện có và mối liên hệ của chúng với các hệ thống tự động hóa sản xuất

Xác định các ứng dụng, dữ liệu, cơ sở hạ tầng vật lý và logic hiện có cũng như các dịch vụ hỗ trợ kỹ thuật

Trong giai đoạn này, các hoạt động sau được thực hiện:

• hội thảo và thảo luận về các quy trình khác nhau
• thăm trang web để có được thông tin theo ngữ cảnh
• hội thảo và thảo luận về các hệ thống hiện có
• đánh giá các dịch vụ để xác định mức độ trưởng thành và tuân thủ các yêu cầu quy định

Kết quả:

• xác định cơ sở hạ tầng hiện có
• tài liệu phân tích
• danh sách ý tưởng về những thách thức và cơ hội của kiến ​​trúc mới danh sách ý tưởng về những thách thức và cơ hội của kiến ​​trúc mới

Giai đoạn 3: Mục tiêu

Mục đích của giai đoạn này là xác định và mô tả các nhu cầu được hình thành trong giai đoạn phân tích.

Giải pháp hoặc kiến ​​trúc mục tiêu sẽ mô tả:

• quy trình và chức năng kinh doanh trong tương lai
• các loại ứng dụng mục tiêu, với chức năng, người dùng, thông tin và giao diện của chúng
• nhu cầu cơ sở hạ tầng và các tiêu chuẩn hỗ trợ sửa đổi

Trong giai đoạn này, các hoạt động sau được thực hiện:

• hội thảo và thảo luận về cải tiến quy trình
• hội thảo và thảo luận về cải tiến kiến ​​trúc

Kết quả:

• Kiến trúc tương lai (trình bày)
• Mô tả ngắn gọn về các loại ứng dụng

Giai đoạn 4: Biện minh

Mục đích của giai đoạn chứng minh là cung cấp một trường hợp kinh doanh ban đầu dựa trên ước tính sơ bộ về chi phí và lợi ích của dự án.

Khoảng cách giữa tình trạng hiện tại và tình trạng mong muốn thường dẫn đến sự xuất hiện của một số ý tưởng. Việc biện minh cho các ý tưởng sẽ cho phép bạn phân biệt “cần thiết” với “mong muốn”, sau đó, trình bày và phát triển các ý tưởng cho ban lãnh đạo cấp cao.

Trong giai đoạn này, các hoạt động sau được thực hiện:

• ước tính sơ bộ chi phí và lợi ích
• phiên bản đầu tiên của bài thuyết trình

Kết quả:

• Những mục đích chung
• ưu tiên ý tưởng kinh doanh
• đánh giá các nguồn lực cần thiết

Giai đoạn 5: Lập kế hoạch

Mục đích của giai đoạn này là lập kế hoạch dự án dựa trên các ưu tiên, nguồn lực và sự phụ thuộc:

• lập kế hoạch trình tự thực hiện các giai đoạn của dự án hợp nhất
• cung cấp các nguồn lực và năng lực cần thiết cho các bước tiếp theo
• bắt đầu các hoạt động quản lý dự án
• hoàn thiện việc tư vấn và chuyển giao kết quả các công đoạn cho khách hàng

Trong giai đoạn này, các hoạt động sau được thực hiện:

• xây dựng kế hoạch thực hiện
• xây dựng kế hoạch đầu tư
• đánh giá rủi ro

Kết quả:

• kế hoạch thực hiện
• đánh giá khối lượng công việc của nhân sự tham gia dự án
• đánh giá rủi ro dự án
• kế hoạch đầu tư (như ước tính đầu tiên)
• phiên bản cuối cùng của bài thuyết trình dự án

Nghiên cứu điển hình

Ví dụ sau đây minh họa việc áp dụng phương pháp được mô tả trong điều kiện thực tế. Để tuân thủ các điều kiện bảo mật, tính ẩn danh được duy trì trong mô tả. Chúng ta đang nói về một doanh nghiệp khá lớn chuyên sản xuất hoạt chất cho dược phẩm. Các cơ sở sản xuất đã được đưa vào hoạt động cách đây hơn 20 năm và mặc dù một số công việc hiện đại hóa đã được thực hiện kể từ đó nhưng một số hệ thống lỗi thời vẫn cần được thay thế. Hệ thống tự động hóa tòa nhà và DCS được ưu tiên hàng đầu vì chúng dựa trên các công nghệ lỗi thời, khó bảo trì. Ngoài ra, sản xuất phải thích ứng với nhu cầu kinh doanh mới, bao gồm cả việc ngừng sản xuất một số sản phẩm và tung ra các sản phẩm khác. Nhìn chung, cần phải xây dựng một kế hoạch di chuyển đáp ứng cả yêu cầu kỹ thuật và kinh doanh.

Trước tiên, bạn cần tạo danh sách tổng thể các thiết bị hiện đang được sử dụng trong toàn doanh nghiệp. Thông tin này thường được “giấu” trong nhiều tài liệu khác nhau (và cả ký ức của nhân viên). Nó phải được trích xuất và trực quan hóa để trở thành cơ sở cho việc lập kế hoạch di cư. Với mục đích này, chúng tôi thường tạo Sơ đồ mô-đun quy trình hiển thị các chuyển động của thiết bị và nguyên liệu thô chính trong mỗi đơn vị sản xuất. Là các lớp riêng biệt "ở trên" của phần cứng, chúng tôi hiển thị hệ thống nào hỗ trợ phần cứng nào.

Một ví dụ được hiển thị trong hình. 2. Dữ liệu về các hệ thống đã cài đặt cũng được chứa trong bộ lưu trữ hệ thống (hoặc đơn giản là trong tệp Excel) và có thể được sử dụng để phân tích và lập kế hoạch thêm.

Hình 2. “Lớp” tự động hóa cho phép bạn đánh giá các hệ thống hiện có

Trước khi thảo luận về kế hoạch di chuyển, cần xác định những lý do kinh doanh chính dẫn đến những thay đổi trong sản xuất. Trong trường hợp này, ban quản lý xác định các động cơ sau:

1. Tuân thủ nhất quán và không có lỗi với các yêu cầu quy định

2. Thời gian tham gia thị trường tối thiểu, linh hoạt

3. Thành công, khả năng cạnh tranh, hoạt động xuất sắc

4. Chất lượng không khoan nhượng

5. Tăng trưởng về khối lượng sản xuất

Những mục tiêu này cần được chuyển thành các nhiệm vụ cụ thể hơn, việc thực hiện chúng có thể được lượng hóa.

Tiếp theo, chúng ta phải tìm hiểu xem các hệ thống hiện tại hỗ trợ các quy trình kinh doanh hiện tại và tương lai tốt như thế nào. Để thực hiện việc này, chúng tôi sử dụng mô hình tham chiếu tiêu chuẩn (dựa trên loạt tiêu chuẩn ANSI/ISA-95). Nó bao gồm 19 quy trình kinh doanh cấp cao, chi tiết đến mức cho phép bạn nhìn thấy những điểm yếu trong quá trình triển khai thực tế và nhu cầu thay đổi vì mục đích kinh doanh hiệu quả.

Ngoài ra, chúng ta cũng cần đánh giá khả năng kỹ thuật của các hệ thống hiện có để hỗ trợ các quy trình kinh doanh trong tương lai. Việc này được thực hiện một cách có hệ thống, sử dụng thông tin được mô tả ở trên từ bộ lưu trữ hệ thống. Đối với mỗi hệ thống có thông tin trong kho lưu trữ (trong trường hợp của chúng tôi là khoảng 70 hệ thống), cần đánh giá các khía cạnh sau:

• Tình trạng thiết bị (lịch sử lỗi, thời gian trung bình giữa các lần hỏng hóc, tuổi thiết bị, tính sẵn có của phụ tùng thay thế)
• Trạng thái của phần mềm (hỗ trợ của nhà cung cấp, tính sẵn có của tài liệu, nhân sự có năng lực cần thiết)
• Khả năng phục hồi hệ thống (dự phòng, tuổi thọ trung bình trước khi sửa chữa)
• Đánh giá tác động kinh doanh (cung cấp thông tin, lỗi dữ liệu, không có sẵn)
• Các chỉ số chỉ báo (độ tin cậy của hệ thống, mức độ quan trọng của hệ thống, v.v.)

Đánh giá kỹ thuật xác định nhu cầu hiện đại hóa và thay thế một số hệ thống:

• Các hệ thống điều khiển quy trình dựa trên DCS thông thường, lỗi thời và nhiều PLC khác nhau, một số trong đó đã “chín muồi” để thay thế.
• Hệ thống tự động hóa tòa nhà dựa trên nền tảng mới hơn nhưng cũng yêu cầu nâng cấp để đáp ứng các yêu cầu mới.
• Một số hệ thống thứ cấp cũng yêu cầu hiện đại hóa hoặc thậm chí thay thế.
• Cơ sở hạ tầng phục vụ tất cả các hệ thống yêu cầu phân khúc và bảo vệ tốt hơn để đáp ứng yêu cầu bảo mật ngày nay.

Phần III

Sau khi phân tích các mục tiêu kinh doanh trong tương lai, rõ ràng là không có hệ thống hiện tại nào đáp ứng đầy đủ nhu cầu trong tương lai. Sự hiểu biết này đã làm nảy sinh một số ý tưởng liên quan đến việc áp dụng các công nghệ mới cũng như hệ thống thực hiện sản xuất. Theo kết quả phân tích, 16 dự án khác nhau đã được đề xuất rằng, nếu được triển khai nhất quán, sẽ giúp công ty đáp ứng các yêu cầu kỹ thuật và thương mại trong tương lai.

Nội dung công việc kỹ thuật và kinh phí của từng dự án được thẩm định; Đối với mỗi dự án, một bản tóm tắt ngắn một trang được chuẩn bị để ban quản lý thảo luận. (Xem Hình 3).

Cơm. 3. Mô tả một trang về dự án di chuyển tiềm năng

Để lựa chọn các dự án ưu tiên, kết quả tiềm năng của từng dự án sẽ được đánh giá. Kết quả được đánh giá về mặt mục tiêu kinh doanh, cũng như độ tin cậy của hệ thống kiểm soát quá trình.

Thông thường, bạn sẽ cần đánh giá nhiều kịch bản triển khai để ước tính tổng thể các yêu cầu về nguồn lực và kinh phí cho từng kế hoạch (Hình 7). Một trong những hạn chế chính cần xem xét là các khoảng thời gian trong quá trình sản xuất mà trong đó hệ thống có thể được thay thế hoặc sửa đổi. Theo quy định, những “cửa sổ” này diễn ra vào cuối tuần - và đây là một điểm nghẽn nghiêm trọng.

Cơm. 7. Tổng quan tổng hợp về lịch trình di chuyển

Vì luôn có ít thời gian để thay thế và thiết lập hệ thống nên việc chuẩn bị phải thật kỹ lưỡng. Mọi thứ đều phải được lên kế hoạch chi tiết. Một khía cạnh quan trọng của việc lập kế hoạch là thử nghiệm các hệ thống đã triển khai.

Trong trường hợp chúng tôi mô tả, việc thực hiện kế hoạch di cư dài hạn được thực hiện theo sáu luồng khác nhau, xem Hình 2. số 8.

Cơm. 8. Tổ chức các dự án di cư theo sáu luồng khác nhau

Một phần của quá trình chuẩn bị là đánh giá kỹ lưỡng và phòng ngừa rủi ro của dự án. Trong bộ lễ phục. Hình 9 cho thấy những rủi ro điển hình liên quan đến các dự án di cư.

Cơm. 9. Đánh giá rủi ro điển hình của các dự án di cư

Quy trình hỗ trợ kinh doanh

Phương pháp lập kế hoạch di chuyển dài hạn và quản lý vòng đời được mô tả trong bài viết này được thúc đẩy bởi nhu cầu kinh doanh. Nó bao gồm việc đánh giá các mục tiêu kinh doanh hiện tại và tương lai, cũng như phân tích kỹ lưỡng về cách bảo trì hoặc thay thế các hệ thống kỹ thuật để hỗ trợ tốt nhất cho các mục tiêu đó. Cách tiếp cận này dựa trên các nguyên tắc TOGAF, trong đó quy định việc thực hiện dự án tuần tự tùy thuộc vào nguồn ngân sách sẵn có và nhân sự có trình độ. Đánh giá kiến ​​trúc hệ thống hiện tại và tương lai là yếu tố then chốt trong việc xác định các dự án di chuyển trong tương lai. Cuối cùng, cần tuân thủ các nguyên tắc quản lý thay đổi của tổ chức để đảm bảo sự tham gia kịp thời của các bên liên quan chính của dự án, điều này rất quan trọng đối với sự thành công của các dự án di chuyển. Hiệu quả của phương pháp này đã được chứng minh nhiều lần trong thực tế.

Leif PoulseN) ( ), chuyên gia CNTT và tự động hóa hàng đầu tại NNE Pharmaplan. Ông có bằng thạc sĩ về quản lý quy trình. Tại NNE Pharmaplan, Poulsen chịu trách nhiệm phát triển công nghệ, phương pháp và năng lực trong lĩnh vực tự động hóa công nghiệp và CNTT, đồng thời làm cố vấn kinh doanh cấp cao.