Luận văn Nghiên cứu phát triển cổng thông tin điện tử cho doanh nghiệp

hệ thống đảm bảo yêu cầu của ngƣời sử dụng, đáp ứng trong hệ thống. Ngoài ra 22 họ còn tập trung đến những yếu tố khác dƣới góc độ của nhà phát triển. Đó là các vấn đề chất lƣợng của bản thiết kế, nó đƣợc biết đến nhƣ các yêu cầu phi chức năng của hệ thống. Dƣới đây đề cập tới các tiêu chí mà các nhà thiết kế luôn hƣớng tới để đảm bảo một thiết kế đƣợc coi là tốt, đảm bảo yêu cầu: Vấn đề hiệu năng Vấn đề hiệu năng cho thấy một đơn vị xác định các công việc một ứng dụng cần phải làm trong khoảng thời gian nhất định. Bình thƣờng các hệ thống phải có khả năng xử lí hàng nghìn, đặc biết với hệ thống phức tạp xử lý vạn giao dịch (transactions) trên mỗi giây, các yêu cầu này thƣờng xảy ra trong các hệ thống ứng dụng lớn của các tổ chức doanh nghiệp lớn, chủ yếu trong các công ty tài chính, viễn thông và cơ quan quản lý nhà nƣớc. Yêu cầu về khả năng xử lý Throughput là việc đo lƣờng lƣợng khối lƣợng công việc mà một ứng dụng phải xử lý và thực hiện trong một đơn vị thời gian. Thông thƣờng, nó đƣợc tính bằng tổng số giao dịch mỗi giây (pts) hoặc tổng số thông điệp đƣợc xử lí mỗi giây (mps). Trong thực tế, một ứng dụng trực tuyến của ngân hàng A (tên ngân hàng) cần phải đảm bảo có thể thực hiện đƣợc tối thiểu một nghìn giao dịch trực tuyến mỗi giây (1000pts), một hệ thống quản lí bán hàng B (tên nhà hàng) phải xử lý năm mƣơi yêu cầu cầu mua hàng của khách hàng mỗi giây (50mps). Yêu cầu về thời gian phản hồi Là thời gian đáp ứng của một yêu cầu, nó chỉ ra độ trễ về thời gian khi hệ thống xử lý thành công một giao dịch. Thời gian phản hồi thƣờng đƣợc gắn liền với thời gian hệ thống sử dụng để phản hồi lại một yêu cầu nào đó. Khoảng thời gian này càng ngắn chứng tỏ hiệu quả làm việc của hệ thống càng cao. Trong thực tế, hệ thống quản lý bán hàng đƣợc áp dụng phổ biến ở các cửa hàng ngày nay, nhân viên bán hàng thực hiện quét mã tra thông tin của sản phẩm tại quầy thanh toán, hệ thống xử lý và hiển thị giá kèm thông tin của sản phẩm. Thời gian đáp ứng càng ngắn thì chứng tỏ hệ thống đƣợc thiết kế tốt và giúp cho nhân viên phục vụ khách hàng đƣợc tốt hơn. Đó cũng là mong muốn của cả cửa hàng và bản thân ngƣời thiết kế phần mềm. Yêu cầu về thời hạn hoàn thành 23 Các ứng dụng yêu cầu nghiêm ngặt về thời gian hoàn thành một yêu cầu ngƣời dùng thƣờng là các ứng dụng phục vụ các công việc liên quan tới phân phối sản phẩm hàng hóa, thƣ tín, thực hiện các giao dịch tài chính. Hệ thống ngân hàng, thƣ tín, tài chính thƣờng có những yêu cầu nghiêm về khoảng thời gian hoàn thành yêu cầu xử lý của ngƣời dùng. Hệ thống thanh toán trực tuyến nhƣ Samsung Pay, ví điện tử Momo là một ví dụ. Khách hàng gửi tiền vào ví điện tử, thực hiện giao dịch thanh toán tiêu dùng thƣờng phải hoàn thành trong một thời gian nhất định. Nó ảnh hƣởng trực tiếp đến trải nghiệm ngƣời dùng và ảnh hƣởng trực tiếp đến doanh nghiệp. Nếu thời gian xử lý quá lâu khách hàng sẽ chuyển sang một hệ thống khác. Yêu cầu khả năng mở rộng hệ thống Nói đơn giản, nhu cầu của khách hàng ngày càng tăng thêm theo thời gian, do đó thiết kế kiến trúc tạo điều kiện cho mở rộng về sau là cực kỳ quan trọng. Nếu thiết kế không tốt, chúng ta bắt buộc phải thiết kế lại hệ thống gây lãng phí về cả thời gian và tiền bạc. Các phía cạnh sau sẽ thể hiện điều này: Yêu cầu chịu tải Trong thực tế, một hệ thống máy chủ đƣợc thiết kế cho phép cung cấp 100 giao dịch trên 1 giây (100pts) với một kiến trúc nhất định, nhƣng trong trƣờng hợp khi hệ thống cần phát triển để nó có thể xử lí số lƣợng yêu cầu giao dịch tăng gấp 10 lần hay 100 lần thì kiến trúc này có thể xử lý đƣợc không. Cùng xem xét hai giải pháp cho vấn đề này, nó đƣợc dùng để nâng cao khả năng xử lý của ứng dụng khi yêu cầu tải tăng lên nhiều lần: hệ thống đƣợc thiết kế sao cho xử lý đa luồng, đơn luồng trên cùng máy trạm (scale up works), tuy nhiên yêu cầu về phần cứng sẽ tăng lên (bộ nhớ, tài nguyên) làm cho tốc độ xử lý tăng lên đáp ứng đƣợc yêu cầu thiết kế. Cấu hình tải đồng đều tại các máy trạm (scale out works): giúp các máy trạm làm việc hiệu quả nhƣ nhau nhƣng sẽ xảy ra trong trƣờng hợp có máy trạm làm việc quá tải trong khi những máy khác lại hoạt động chƣa hết công suất. Điều này dẫn đến lãng phí tài nguyên phần cứng. Hình dƣới đây mô tả quá trình mở rộng theo chiều dọc và chiều ngang (scale up -scale out) [2] 24 Hình 2.8. Quá trình mở rộng theo chiều dọc- ngang (Scale out -Scale up) Yêu cầu đáp ứng dữ liệu lớn Kiến trúc tốt đi liền với khả năng mở rộng thiết kế về sau cũng nhƣ yêu cầu về việc xử lý hệ thống khi dữ liệu ngày càng tăng lên. Một ví dụ của hệ thống gửi tin nhắn, bình thƣờng hệ thống đƣợc thiết kế để gửi và nhận tin nhắn của ngƣời dùng với giới hạn số lƣợng ký tự nhất định. Tuy vậy, có khách hàng gửi đi tin nhắn vƣợt quá giới hạn tin nhắn cho phép thì hệ thống sẽ xử lý nhƣ thế nào ? Trong trƣờng hợp này hệ thống sẽ chia tin nhắn ra làm nhiều tin nhắn nhỏ và gửi đi. Đó là cách giải quyết tốt và đơn giản. Tuy nhiên với trƣờng hợp chúng ta không đƣợc chia tin nhắn thành nhiều tin nhắn nhỏ ? những file có dung lƣợng lớn cần gửi đi thì kiến trúc hệ thống thiết kế khi đó có cho phép xử lý hay không. Yêu cầu xử lý lượng lớn kết nối đồng thời Một tiêu chí quan trọng khác để một kiến trúc là khả năng đáp ứng số lƣợng lớn yêu cầu cùng lúc. Ban đầu nó đƣợc thiết kế để xử lý hàng nghìn lƣợt yêu cầu trong cùng thời điểm, hệ thống xử lý rất tốt. Nhƣng khi số lƣợng truy cập bất ngờ thăng lên hàng trăm nghìn (điều này nằm ngoài khả năng tƣởng tƣợng cầu của khách hàng lúc yêu cầu), thậm trí hàng triệu yêu cầu thì làm sao để giải quyết nó trong thời gian sớm nhất. Kiến trúc đã thiết kế có cho phép làm điều này hay không ? Nếu thiết kế không tốt có thể ta phải thiết kế lại hệ thống gây lãng phí thời gian và công sức. Để ví dụ cho trƣờng hợp này, ta có thể lấy ví dụ hệ thống mua vé bóng đá trực tuyến. Hệ thống đƣợc thiết kế nhƣng không chịu đƣợc hàng trăm nghìn yêu cầu gửi đến cùng một thời điểm, máy chủ luôn ở trong tình trạng quá tải. Tuy vậy 25 do thiết kế chƣa thực sự tốt, họ cũng không thể xử lý thay đổi để nâng cấp cho hệ thống có thể chịu đƣợc. Triển khai, cài đặt ứng dụng Yếu tố đánh giá ở đâu là kiểm tra xem hệ thống có thể đƣợc triển khai hiệu quả (dù không cần phải thay đổi mã nguồn) khi số lƣợng tài khoản sử dụng tăng lên (số lƣợng ngƣời dùng). Khi đó hệ thống có thể cài đặt dễ dàng trên nhiều thiết bị khác nhau, kể cả việc cấu hình, hoặc các thay đổi nhƣ cập nhật các phiên bản mới. Giải pháp đƣa ra cho vấn đề này là thiết lập tự động cài và cập nhật cho ngƣời sử dụng dựa trên những thông tin cấu hình của họ. Ý tƣởng này đƣợc áp dụng phổ biến rộng rãi cho các ứng dụng triển khai trên mạng trực tuyến. Khả năng sửa đổi Yêu cầu sửa đổi phần mềm là điểm tất yếu của phần mềm vì yêu cầu nghiệp vụ của ngƣời dùng cũng thay đổi theo thực tế công việc. Nó là một trong những đặc điểm đánh giá phần mềm có đƣợc thiết kế tốt để dễ dàng sửa đổi đƣợc không trong trƣờng hợp các yêu cầu phi chức năng và yêu cầu chức năng thay đổi. Tính bảo mật Yếu tốt bảo mật liên quan tới nhiều khía cạnh phức tạp của hệ thống, kiến trúc phần mềm chỉ là một trong những những khía cạnh của nó. Ta xét các đặc điểm chủ yếu sau đây: Cơ chế xác thực: ứng dụng cần xác định xem thực thể mà nó đang làm việc có hợp lệ hay không, thƣờng các ứng dụng làm điều này bằng cơ chế đăng nhập. Các phiên của quá trình làm việc đƣợc lƣu trong phiên của hệ thống. Cơ chế phân quyền: những tác nhân đƣợc xác định khi giao tiếp với hệ thống, tuy nhiên các tác nhân này có thể làm những gì trên hệ thống, truy cập tài nguyên nào, quyền hạn (đọc, ghi) đến đâu thì đó lại là hành động phần quyền của ứng dụng. Yêu cầu về mã hóa: các thông tin nhạy cảm của hệ thống phải đƣợc mã hóa khi lƣu trữ (thông tin mật khẩu, thậm chỉ là tên đăng nhập), mã hóa trong quá trình gửi và nhận giữa các hệ thống, giữa hệ thống và con ngƣời ( ngày nay phần lớn các hệ thống điều đƣợc thiết lập mã hóa tầng giao vận). Yêu cầu toàn vẹn: các thông tin gửi đi không bị sửa đổi ở phía biên nhận. Tính không thoái thác: Một yếu tố thể hiện rằng ngƣời nhận và ngƣời gửi không thể thoái thác trách nhiệm với gói tin đã 26 trao đổi trên hệ thống. Gói tin đƣợc xác định bởi ngƣời gửi và đích đến (ngƣời nhận). Yêu cầu này đƣợc thể hiện cụ thể trong bài toán chữ ký số điện tử. Yêu cầu khả năng sẵn sàng Khả năng làm việc liên tục không bị ngắt quãng thể hiện độ tin cậy của hệ thống. Vì lý do nào đó hệ thống không hoạt động khi ngƣời dùng yêu cầu thì nó chƣa đáp ứng đƣợc tính sẵn sàng của hệ thống. Trong thực tế yêu cầu này đƣợc thể hiện bởi khả năng sử dụng 24/24 h của hệ thống. Khả năng tích hợp Các ứng dụng phải đƣợc thiết kế kiến trúc sao cho dễ dàng tích hợp lại với nhau vì trong nhiều trƣờng hợp hệ thống có xu hƣớng hoạt động rộng hơn. Nó không chỉ có giá trị về mặt kỹ thuật, nó cũng làm hệ thống có giá trị cao hơn khi có thể tích hợp và có thể hoạt động tốt với các hệ thống bên ngoài nó. Một giải pháp đơn giản là cung cấp API trực tiếp để các hệ thống khác truy cập vào. Tuy nhiên theo kinh nghiệm ngƣời ta thƣờng sử dụng mô hình dƣới đây để phát triển các API: Hình 2..9. Mô tả kiểu tích hợp Giải pháp duy nhất trong trƣờng hợp này là hỗ trợ giao tiếp truy cập tài nguyên hệ thống thông qua các giao diện lập trình ứng dụng (API). Các API đƣợc cung cấp bởi các dịch vụ web. Việc tích hợp hệ thống cần phải thực hiện một cách linh hoạt và đơn giản, các ứng dụng đƣợc viết bằng nhiều ngôn ngữ khác nhau, truy cập các hệ quản trị dữ liệu khác nhau. Nên việc thiết kế các API chi tiết và đầy đủ sẽ tạo nền tảng cho việc kiểm soát hệ thống tốt hơn, nâng cao hiệu quả, an toàn khi các hệ thống giao tiếp với nhau. Ngoài ra ngƣời ta còn xem xét đến các yếu tố khác nhƣ 27 tính dễ cài đặt trên các nền tảng phần mềm, phần cứng, tính dễ dùng dễ hỗ trợ khi vận hành thực tế, tính dễ dàng trong quá trình kiểm thử. 2.2.3 Quy trình thiết kế kiến trúc phần mềm Giai đoạn phác thảo quy trình thiết kế Kiến trúc sƣ phần mềm ngoài việc đƣa ra thiết kế kỹ thuật họ còn cần phải tham gia các công việc khác để bổ hoàn thiện cho bản thiết kế đƣợc hoạt động tốt nhất. Đấy là các công việc một kiến trúc sƣ phần mềm phải làm: Hợp tác với nhóm phân tích yêu cầu, nhóm phân tích khảo sát yêu cầu ngƣời dùng lấy thông tin từ khách hàng và tổng hợp lại thành tài liệu yêu cầu đặc tả, từ đó mô tả chi tiết hệ thống cần những gì từ đó đƣa ra thiết kế cao nhất đảm bảo yêu cầu đề ra. Cái khó của kiến trúc sƣ phần mềm là tầm nhìn đảm bảo cho hệ thống đáp ứng tốt cho tƣơng lai nhƣng lại phải cần đáp ứng đƣợc phạm vi tài chính và thời gian hoàn thành của khách hàng. Kết quả thu đƣợc là bản thiết kế phù hợp nhất với khách hàng. Trao đổi với các bên liên quan, đảm bảo bản thiết kế đƣợc hiểu đúng, hiểu đủ yêu cầu khách hàng và đảm bảo nó đã tồn tại trong thiết kế. Những gì kiến trúc sƣ nghĩ là đúng và cần thiết có khi lại không phải những gì khách hàng mong muốn. Quản lý đội thiết kế: việc xác định kiến trúc cũng là một phần trong quá trình thiết kế. Kiến trúc sƣ phần mềm cần lãnh đạo đội ngũ nhỏ hơn trong nhóm, những dự án lớn đòi hỏi sự tham gia của nhiều kỹ sƣ chƣa có nhiều kinh nghiệm. Sản phẩm cuối cùng là bản thiết kế chi tiết (tạm dịch là architecture blueprint), nó đƣợc dùng để thực thi kiến trúc khi triển khai. Trao đổi với đội quản trị dự án, họ cần phải làm việc với PM (ngƣời quản lý dự án) để hỗ trợ đƣa ra kế hoạch, các khối lƣợng công việc cần thực hiện và kế hoạch triển khai thực tế của dự án. Dựa vào kinh nghiệm của thiết kế, thiết kế kiến trúc chia làm ba bƣớc sau: xác định yêu cầu kiến trúc, thiết kế kiến trúc và thẩm định kiến trúc. 28 Hình 2.10. Quy trình thiết kế kiến trúc Tìm hiểu yêu cầu của kiến trúc: tạo ra một bản vẽ yêu cầu tầm cao, dựa trên yêu cầu của hệ thống. Nó là tiền đề, định hƣớng cho bản thảo kiến trúc. Thiết kế kiến trúc: thực hiện việc làm rõ các thành phần có trong bản thiết kế, vai trò cũng nhƣ mối liên hệ giữa các thành phần nhỏ. Quá trình đƣợc thực hiện từ bản thảo thiết kế đến bản thiết kế chi tiết. Thẩm định: đảm bảo kiến trúc đƣa ra là đáp ứng yêu cầu hệ thống, các yêu cầu chức năng, phi chức năng Giai đoạn xác định yêu cầu kiến trúc Để áp dụng một bản kiến trúc thiết kế, ta phải thực hiện đánh giá chi tiết các yêu cầu kiến trúc mà hệ thống đòi hỏi. Từ hình dƣới đây ta thấy tồn tại hai yêu cầu quan trọng đó là yêu cầu về chức năng hệ thống và yêu cầu từ các ngƣời liên quan tới hệ thống [2]: Hình 2.11. Đầu vào và đầu ra khi xác định kiến trúc Hai yếu tố này ảnh hƣởng tới việc xác định yêu cầu kiến trúc. Trong thời gian tìm hiểu yêu cầu kiến trúc sẽ thu đƣợc một danh sách các yêu cầu cụ thể về kiến trúc của hệ thống. Tuy vậy, những yêu cầu này vẫn ở dạng thô, chƣa đƣợc chƣa đƣợc đặc tả chi tiết trong tài liệu ở mức này. Do đó các kỹ sƣ kiến trúc phải làm việc trực tiếp với các stackeholder (ngƣời yêu cầu liên quan tới hệ thống). Điều đó dẫn đến mỗi kiến trúc sƣ phần mềm đều có kinh nghiệm thiết kế trong một số lĩnh vực nhất định, thật khó khăn để triển khai một dự án mà chƣa từng làm việc với nghiệp vụ ở lĩnh vực này. Các bản yêu cầu kiến trúc đƣợc chia làm các mức độ ƣu tiên khác nhau. Nhiều trƣờng hợp các yêu cầu chỉ dừng lại ở mức độ ƣu tiên thấp 29 hoặc ít quan trọng. Dựa trên mức độ ƣu tiên, ta phân loại chúng thành ba mức sau đây: mức độ cao: hệ thống đƣợc thiết kế phải hỗ trợ các yêu cầu này, đó là những yêu cầu quan trọng bậc nhất của hệ thống. Kiến trúc sƣ không thể bỏ qua yêu cầu này. Mức độ trung bình: những yêu cầu cần thiết ở một trạng thái nào đó của hệ thống nhƣng tùy từng thời điểm nó có ảnh hƣởng tới hệ thống. Mức độ thấp: chúng là những yêu cầu nhƣng ở dạng mong đợi của khách hàng và mong đợi của nhà phát triển, nó không ảnh hƣởng nhiều tới việc thiết kế hệ thống. Giai đoạn thiết kế kiến trúc Vai trò của kiến trúc sƣ phần mềm là vô cùng cần thiết, chất lƣợng của bản thiết kế sẽ quyết định thành bại của cả hệ thống. Việc xây dựng các tài liệu chi tiết, quá trình làm việc giữa các bên liên quan để lấy đƣợc bản yêu cầu đặc tả sẽ là vô ích nếu kiến trúc sƣ đƣa ra một bản thiết kế kém chất lƣợng [2] . Hình sau đây cho thấy đầu vào và đầu ra của quy trình thiết kế kiến trúc: Hình 2.12. Đầu vào và đầu ra của quá trình thiết kế kiến trúc Bƣớc đầu tiên của việc thiết kế là chọn ra một kiến trúc tổng thể cho kiến trúc dựa trên những bộ khung (framework) đã tồn tại. Sau đó là việc xác định các thành phần con phù hợp với bộ khung đã chọn để tạo lên một hệ thống phù hợp. Kết quả của bản thiết kế bao gồm khung nhìn kiến trúc và tài liệu giải thích kiến trúc. Khung nhìn bao gồm các bản vẽ, sơ đồ dƣới góc nhìn tổng quan dành cho đội thiết kế, bản tài liệu kiến trúc mô tả chi tiết bản khung nhìn kiến trúc. 30 Giai đoạn chuẩn hóa Sau khi thiết kế kiến trúc, việc đánh giá lại kiến trúc xem xét hiệu quả đánh giá xem kiến trúc đã thiết kế có đảm bảo mục tiêu ban đầu của hệ thống hay không. Quá trình chuẩn hóa luôn khó khăn và phức tạp với ngay cả những ngƣời có nhiều kinh nghiệm trong lĩnh vực thiết kế, nó không thể đánh giá cụ thể, kiểm tra chất lƣợng, kiểm thử để kiểm tra các tiêu chí đặt ra. Kiến trúc thiết kế có thể bao gồm các thành phần mới hoặc các thành phần đã đƣợc tồn tại sẵn nhƣ các thƣ viện, ứng dụng con. [2] 31 Chương 3 Phân tích giải pháp tích hợp hệ thống cho doanh nghiệp 3.1 Tổng quan vấn đề và giải pháp cho doanh nghiệp Một doanh nghiệp khi hoạt động ngoài việc quản lý mảng kinh doanh chính của doanh nghiệp, các mảng kỹ thuật, các bộ phận, phòng ban đều có những phần mềm quản lý nghiệp vụ riêng. Những phần mềm này mang tính đặc thù: đặc thù kế toán, kiểm toán, hệ thống SAP (hệ thống quản lý quy trình sản xuất, mua, bán), MES (Hệ thống quản lý nhà máy). Cổng thông tin doanh nghiệp chú trọng đến đảm bảo các vấn đề an ninh, hành chính, đào tạo cho doanh nghiệp Hình 3.1. Mô hình tổng quan doanh nghiệp Các vấn đề về hành chính tổng hợp bao gồm: quản lý nhân viên vào ra, quản lý khách vào ra, quản lý tài sản, quản lý xe xe ra vào cổng, quản lý bãi đỗ xe, quản lý đào tạo, ngoài ra còn các vấn đề về hành chính gồm có: quản lý bảng thông tin, quản lý làm thêm giờ, quản lý nhà ăn. Các vấn đề về đào tạo gồm quản lý đào tạo, quản lý các khóa học, môn học cho nhân viên, quản lý điểm, tiêu chuẩn đào tạo. Sơ đồ doanh nghiệp sản xuất trong các khu công nghiệp và chế xuất nhƣ sau: 32 Hình 3.2 Sơ đồ ví dụ về doanh nghiệp Các phòng bảo vệ B1, B2 (đƣợc đặt bên bên ngoài, trƣớc cửa an ninh, để đảm bảo ngƣời chƣa đăng ký thông tin, chƣa có thẻ thì không thể vào công ty). Với những công ty lớn thƣờng có nhiều hơn một phòng bảo vệ đăng ký thông tin để tạo điều kiện cho nhân viên và khách đến làm việc. Nhiệm vụ của phòng bảo vệ là kierm tra, đăng ký, cấp phát thẻ cho khách đến làm việc, cấp thẻ tam cho nhân viên công ty quên thẻ. Sau khi đƣợc cấp thẻ, ngƣời sẽ di chuyển tới khu vực các của an ninh để vào công ty. Các bãi đỗ xe P2, P3, P4, P5 (bãi ô tô, xe máy, xe đạp) ở Việt Nam chủ yếu là bãi gửi xe máy, bãi ô tô chỉ chiếm một diện tích nhỏ. Các cửa an ninh: Cửa an ninh A1, A2, A3, A4 đƣợc bố trí bên trái và bên phải của cổng C1, C2 để đảm bảo an ninh vòng ngoài. Cổng chính C1: phục vụ cho các xe con (xe bốn chỗ, xe chở ngƣời) di chuyển ra vào công ty, xe chở khách VIP, các lãnh đạo quản lý cấp cao, các phái đoàn. Cổng phụ dành cho các xe chở hàng, vật liệu, xe tải, xe 33 công phục vụ sản xuất, cấp dỡ hàng hóa. Tại đây thông tin xe, lái xe, sẽ đƣợc kiểm tra và xác nhận thời gian vào ra công ty. Các nhà ăn R1, R2, R3 phục vụ các suất ăn sáng, trƣa tối cho nhân viên và khách đến làm việc. Tại nhà ăn, thông tin các món ăn đã đƣợc đƣa lên hệ thống trƣớc đó để nhân viên có thể xem trƣớc giờ ăn, nhân viên tiết hành xếp hàng đợi xuất ăn và quẹt thẻ để lấy xuất ăn. Dữ liệu sẽ đƣợc hệ thống thu thập và tiến hành phân tích báo cáo sau này. Trung tâm y tế H1: giám sát sức khỏe nghề nghiệp cho nhân viên, thực hiện khám sức khỏe định kỳ, chăm sóc nhân viên khi đau ốm. Thông tin nhân viên tham gia khám chữa bệnh đƣợc cập nhật lên hệ thống. Nhà kho K1, K2: các kho lƣu trữ hàng hóa và các vật liệu, kho hàng đƣợc lƣu tại K1, K2 chủ yếu đƣợc sử dụng cho các kho sản phẩm chờ xuất đi. Trung tâm đào tạo: thực hiện đào tạo cho nhân viên, hàng năm công ty sẽ có khóa đào tạo định kỳ, các khóa đào tạo cho nhà thầu, đào tạo chuyên môn. Trung tâm nghiên cứu CN1: gồm trung tâm nghiên cứu và xƣởng thử nghiệm sản phẩm, những mẫu sản phẩm mới, thử nghiệm đều đƣợc xử lý tại đây. Tòa xƣởng F1,F2, F3, F4, F5, F6, F7: các xƣởng sản xuất của công ty, tại các xƣởng làm việc đều đƣợc quẹt thẻ từ để mở cửa, trong xƣởng sản xuất các quy định về an ninh đƣợc thắt chặt hơn cả. 34 3.1.1 Quản lý khách Quản lý vào ra Việc quản lý đƣợc chia ra thành quản lý nhân viên (đổi tƣợng thƣờng xuyên ra vào công ty, có thẻ nhân viên) và khách/nhà thầu (đến làm việc tạm thời hoặc thƣờng xuyên). Nhân viên không cần thực hiện đăng ký tại phòng bảo vệ, việc đăng ký chỉ thực hiện dành cho đối tƣợng khách. Trong trƣờng hợp nhân viên quên thẻ, cần đến phòng bảo vệ để đƣợc mƣợn thẻ tạm và kích hoạt thẻ, cuối ngày làm việc nhân viên phải quay lại phòng bảo vệ để trả thẻ. Để khách vào công ty nhân viên cần đăng ký khách trên hệ thống trƣớc đó. Nhân viên phòng bảo vệ dựa vào thông tin đăng ký để thực hiện thủ tục: kiểm tra thông tin, cấp thẻ, chụp ảnh thẻ (nếu là lần đầu đến công ty). Tại cửa an ninh, dữ liệu đƣợc liên kết với hệ thống để mở cửa và hiện thị ảnh. Cũng tại đây, dữ liệu kích hoạt các cửa ra vào, thẻ nhà ăn và các quyền khác phục vụ cho công việc cũng đƣợc xử lý. Hình 3.3 Quy trình ra khỏi công ty của nhân viên-khách Tại phòng bảo vệ nhân viên sẽ xác nhận hành động trả thẻ và thu lại thẻ trên hệ thống quản lý. Dữ liệu của khách sẽ đƣợc sử dụng để lƣu trữ, báo cáo trên hệ thống. Thẻ khách dành cho khách/nhà thầu vào công ty làm việc, thẻ này chỉ đƣợc giới hạn về quyền hạn, phần lớn chỉ dành để xác thực khi đi qua cửa an ninh của công ty. 35 Hình 3.4 Cửa an ninh Mô tả hình ảnh cửa an ninh bao gồm vị trí quet thẻ (số 1) và thanh chắn (2). Khi thẻ đƣợc kích hoạt và quẹt vào đầu đọc thẻ, hệ thống của sẽ gọi hàm kiểm tra tính hợp lệ trên CTTĐT và có hành động cụ thể. Nếu thẻ đã đƣợc kích hoạt quyền thì thanh chắn có thể mở ra và ngƣời đó di chuyển qua thanh chắn. Dƣới đây là API mô tả phƣơng thức gọi yêu cầu kiểm tra tính hợp lệ của thẻ: Url: /checkPersonCardId? cardId =100000122311 Parameter: cardId( string) Type: GET { "result": "ok", "msg": "success", "record": { "title": "Playsam Streamliner", "user_id":"key226654786", "id_no":"12365423", "avata": { "fileName": "quwowooybuqbl6ntboz3.jpg", "contentType": "image/jpg", "details": { "image": { "width": 600, "height": 446 }, 36 "size": 27187 }, "url": "//dbn.net/images/visitor/quwowooybuqbl6ntboz3.jpg" } } } Quản lý tài sản khách Những tài sản của công ty sẽ đƣợc dán tem để phân biệt với tài sản cá nhân. Ngoài những tài sản quan trọng khác nhƣ thẻ nhớ, thiết bị lƣu trữ, usb cần phải quản lý chặt chẽ, đảm bảo an ninh thông tin. Hình 3.5 Hình ảnh tem, thiết bị lưu trữ Quy trình xử tài sản: Kiểm tra thông tin khách, thiết bị  Xử dụng hệ thống  Thực hiện thao tác dán tem  Lưu trên hệ thống Kết thúc. Dƣới đây là mẫu dữ liệu kiểm tra thông tin đăng ký khác trên CTTĐT, từ đó thực hiện kiểm soát tài sản của khách mang đến công ty. Url: dbnVisitor/checkInfo?p_id_no=12313123111 Parameter: p_id_no (string) Type: GET { result: "ok", msg: "success", record: { user_id: "key226654786" id_no: "122365469", full_name: "Nguyen Van Nam", email: "nv.nam@dbn.com", grade: "S1", phone: "0966012522" } } 37 Tiếp đó là hành cộng lƣu thông tin kiểm soát tài sản khách lên CTTĐT, máy khách gửi tới máy chủ ứng dụng các thông tin bao gồm: mã khách, số CMTND, tên thiết bị, hãng, số serial, ngày đăng ký. Url: dbnStempDevice/ajaxSaveReq Parameter type: Object { user_id: "key226654786" id_no: "122365469", full_name: "Nguyen Van Nam", device_name: "IPHONE 6", branch: "Apple", serial: "1254SE23644", device_type: "Phone", date_req: "2019/01/03" } Type: POST Result: Json Type Content { result: "OK", msg: "" } 3.1.2 Quản lý cổng xe Quản lý xe ra vào cổng luôn là một trong những vấn đề của doanh nghiệp, xe VIP là những xe quan trọng, nó đƣợc hiểu chung là những xe có thể đi qua cổng ngƣời (Cổng C1, C2) mà ngƣời đi trên xe không cần xuống xe. Các loại xe nhƣ: xe con, xe khách, xe cứu thƣơng, xe cứu hỏa. Xe con chuyên chở ban lãnh đạo công ty, các xe crở lãnh đạo đối tác, công chức nhà nƣớc (tùy theo chức danh và khu vực). Các xe khách trong những trƣờng hợp đặc biệt đƣợc phòng hành chính thông qua, xe khách thƣờng có số lƣợng ngƣời lớn nên việc đăng ký xe VIP cho xe này đòi hỏi thủ tục khắt khe và phức tạp hơn. Các xe cứu thƣơng, cứu hỏa theo sự cấp phát của công ty, những trƣờng hợp khẩn cấp thì chỉ cần đƣợc chấp thuận bởi nhân viên phòng hành chính. Quy trình quản lý xe: Nhân viên đăng ký  Cấp trên bộ phận phê duyệt Phê duyệt bởi phòng hành chính  Kết quả, thông báo tới nhân viên khác Thực hiện vào ra Cổng. Xe vào/ra cổng  Biển số xe được nhận dạng bởi máy quay  Đối chiếu với dữ liệu trên hệ thống  Tự động mở thanh chắn. Sau khi nhân viên đăng ký và nhận đƣợc phê duyệt dữ liệu sẽ đƣợc ghi nhận trạng thái hoàn thành, khi xe thực hiện ra vào cổng hệ thống sẽ ghi nhận biển số xe thông 38 qua máy quay gắn trên đầu cổng. Thông tin đăng ký bao gồm: Biển số xe, thông tin lái xe, hãng xe, phân loại xe VIP, thời gian bắt đầu và thời gian kết thúc. Máy quay này sẽ quét và nhận dạng xe và biển xe, chuyển biển số xe sang dạng chữ rồi so sánh với dữ liệu trên hệ thống. Với trƣờng hợp đặc biệt khẩn cấp nhân viên an ninh có thể xử lý mở cổng bằng chức năng khẩn cấp. Hệ thống sẽ lƣu lại với trạng thái khẩn cấp. Camerea (vị trí 1) (phân tích biển xe và chuyển sang dạng text)  Kiểm tra dữ liệu xe bởi API cung cấp  Thực hiện báo đèn (vị trí 2)  Mở thanh chắn hoặc không (vị trí 3). Dƣới dây là hình ảnh triển khai thực tế: Hình 3.6 Quản lý cổng xe VIP ra vào công ty Để giải quyết vấn đề này CTTĐT cung cấp API để kiểm tra xe vào ra có hợp lệ hay không, nó đã đƣợc đăng ký và cấp phép vào ra tại cổng chính chƣa. Thông tin yêu cầu từ thiết bị gửi tới máy chủ gồm thông tin biển số xe và nhận lại trạng thái đƣợc phép hay không: Url: dbnGateControl/checkCarNo?car_no=99D12345 Parameter type: String Example para: car_no=99D12345 Type: GET Result: Json Type Content