Các thành phần trong hệ thống BI của doanh nghiệp

Hệ thống Business intelligence (kinh doanh thông minh) trong các doanh nghiệp là hệ thống giúp doanh nghiệp sử dụng thông tin một cách hữu ích cho sự vận hành và kinh doanh của tổ chức. Một hệ thống BI thường có các thành phần chính như sau:

Source ERP

Nguồn thông tin chính được sử dụng trong các hệ thống BI thường lấy từ hệ thống Enterprise Resource Planning (ERP), đây là hệ thống được sử dụng để điều khiển các hoạt động diễn ra trong một doanh nghiệp. Dựa trên các tính năng được sử dụng trong hệ thống ERP có thể lấy các thông tin về việc kinh doanh, tài chính, điều hành, nhân sự, thuế … để đưa vào hệ thống BI. Để lấy các thông tin này có thể tạo ra các API hoặc truy vấn trực tiếp trong hệ thống CSDL của ERP. Việc sử dụng API thường được sử dụng nhiều hơn vì nó sẽ không phụ thuộc vào cấu trúc các bảng trong CSDL, nhưng sẽ phải đầu tư vào vấn đề hiệu năng của hệ thống và việc trích xuất dữ liệu hàng ngày.

Databases

Hệ thống CSDL để lưu trữ dữ liệu. CSDL dùng  trong hệ thống BI gọi là Datawarehouse. Hệ thống này sẽ lấy dữ liệu từ các nguồn khác nhau và thực hiện lọc các thông tin cần thiết cho các BI tool sử dụng. Lưu ý :

  • Các tham số thiết lập trong datawarehouses khác với trong hệ thống transactional database.
  • Phải xác định khả năng sẵn sàng đáp ứng của hệ thống
  • Phải xác định khả năng tải dữ liệu và làm mới thông tin
  • Phải xây dựng hệ thống ODS (Operational Data Storage) giữa datawarehouse và transaction database làm trung gian chuyển tải dữ liệu.
  • Phải xây dựng chiến lược sao lưu dự phòng dữ liệu, căn cứ theo mức độ tải của hệ thống và sự cập nhật dữ liệu thực tế.

ETL

ETL là Extraction, Transformation, Load là quá trình trích xuất, chuyển đổi, truyền tải vào datawarehouse. Thông thường dữ liệu được trích xuất từ cơ sở dữ liệu OLTP, được chuyển đổi để phù hợp với lược đồ kho dữ liệu và được nạp vào cơ sở dữ liệu kho dữ liệu.

Front-End Tool
Front-end là thành phần cho người sử dụng tương tác với dữ liệu trong datawarehouse, là kênh truyền thông tin giữa người dùng và dữ liệu cần thiết, được yêu cầu phải thiết kế thân thiện cho người sử dụng hệ thống.

Chính quyền điện tử: lý thuyết và thực tế

Theo BBC Future, Estonia – một đất nước nhỏ bé chỉ với 1,3 triệu dân nằm lọt thỏm ở một góc đông bắc châu Âu, quốc gia đã sinh ra Skype đang theo đuổi mục tiêu xã hội kỹ thuật số 100% kể từ những năm 1990. Các chuyên gia từ những nơi khác đều đồng ý rằng ý tưởng về chính phủ trực tuyến của nước này – được gọi là dự án e-Estonia – là mô hình mẫu mực trên thế giới về việc làm thế nào để một chính phủ có thể chuyển phần lớn các dịch vụ của mình lên một cơ sở trực tuyến duy nhất một cách tiện lợi và thành công.

Từ 1997, dự án này cho phép các công dân Estonia khai hồ sơ thuế trực tuyến kể từ năm 2000 cũng như cho phép người dân được kê đơn thuốc, lấy kết quả xét nghiệm, ký giấy tờ và thậm chí là bầu cử và cho phép người nước ngoài trở thành công dân điện tử, tất cả đều qua mạng. Các nước Phần Lan, Nhật Bản và Cyprus đều học kinh nghiệm từ Estonia – họ hoặc là làm việc với các công ty Estonia để xây dựng chương trình thuế điện tử ở quốc gia của họ, hoặc là mượn hệ thống thẻ nhận dạng công dân của Estonia mà mỗi công dân đều có một mã số được sử dụng cho tất cả các mục đích: từ an sinh xã hội cho đến bầu cử và cứu nạn trong thảm họa.  E-Estonia còn có hệ thống bỏ phiếu trực tuyến, mà họ nói rằng có chế độ an toàn để đảm bảo tính trung thực của các lá phiếu bầu, chẳng hạn như những thẻ căn cước của mỗi công nhân do Nhà nước cấp cho phép họ sử dụng các tiện ích trực tuyến như mua sắm và bầu cử điện tử. Họ cho rằng công nghệ khóa chùm của họ có thể đảm bảo rằng “không có ai – kể cả các tin tặc, các quản trị viên hệ thống và thậm chí là cả chính phủ – có thể lợi dụng và bóp méo dữ liệu mà không bị trừng phạt.”

Tuy nhiên, ngoài các vấn đề về an ninh mạng, ở các quốc gia càng lớn thì càng khó xây dựng xã hội điện tử một cửa như ở Estonia. Ở một quốc gia lớn, có thể có rất nhiều người nói nhiều ngôn ngữ khác nhau – làm mọi chuyện thêm phức tạp – sẽ dễ dàng hơn để mọi việc diễn ra suôn sẻ ở một nước nhỏ và tương đối đồng nhất.

(Trích từ BBC Future)

Issue Type trong Jira

JIRA cung cấp nhiều Issue Types khác nhau, tuỳ theo từng dự án mà người quản trị có thể hiệu chỉnh cho phù hợp. Các Issue Type mặc đinh là:

 Bug — một lỗi ảnh hưởng tới chức năng hoặc toàn bộ sản phẩm
 Improvement — nâng cấp của chức năng đã có
 New Feature — chức năng mới cho sản phẩm
 Task — một nhiệm vụ cần hoàn thành
 Custom Issue — loại được định nghĩa bởi người dùng

Thực hiện bảo mật khi phát triển phần mềm (Security in Software Developement)

seceĐể xây đựng được một ứng dụng an toàn là vấn đề quan trọng nhưng cũng vô cùng khó khăn. Microsoft cung cấp các hướng dẫn giúp các nhà phát triển giải quyết vấn đề này. Các nguyên tắc cần tuân thủ được liệt kê bên dưới:

Development Phase Core Security
Planning    
Requirements and Analysis Functional Requirements

Non Functional Requirements

Technology Requirements

Security Objectives: Định nghĩa các mục tiêu và các yêu cầu bảo mật chung, các mục tiêu này liên quan chặt chẽ tới tính an toàn, toàn vẹn và tính sẵn sàng của ứng dụng và dữ liệu.

 

Architecture and Design Design Guidelines

Architecture and Design Review

Security Design Guidelines: sử dụng các nguyên lý  các mẫu chung để thiết kế các hạng mục thường xuyên gặp lỗi bảo mật.

Threat Modelling: Mô hình hóa để hiểu về các nguy cơ và yếu điểm có thể xuất hiện trong ứng dụng

Security Architecture and Design Review: Phân tích lại thiết kế ứng dụng dưới góc độ bảo mật.

 

Development Unit Tests

Code Review

Daily Builds

Security Code Review: xem lại code để kiểm tra có mắc lỗi bảo mật không

 

Testing Integration Testing

System Testing

Security Testing: Sử dụng các nguy cơ được định nghĩa trong phần modelling để xác định phạm vi và kế hoạch kiểm thử chi tiết
Deployment Deployment Review Security Deployment Review: Xem xet cấu hình của ứng dụng, đảm bảo các điểm yếu hoặc những thiết lập không phù hợp bị loại bỏ để đảm bảo an toàn

 

Maintenance  

Quy trình nghiên cứu phát triển phần mềm

1. Mục đích
Quy trình nghiên cứu phát triển sản phẩm thực hiện trong quá trình sản xuất và kinh doanh dịch vụ, sản phẩm và giải pháp CNTT.
2. Định nghĩa, thuật ngữ và viết tắt
Product owner: Quản lý các yêu cầu của sản phẩm, định nghĩa các hạng mục trong Product backlog. Là người chấp nhận hoặc từ chối kết quả công việc
Scrum team: Đội phát triển đa chức năng, mỗi người có 1 chuyên môn sâu và các chuyên môn hỗ trợ.
Scrum master: Người hướng dẫn đội scrum, hướng dẫn cách làm và giải quyết các vấn đề phát sinh.
Product backlog: Danh sách các tính năng của sản phẩm cần đạt được.
Story: Các tính năng, yêu cầu của sản phẩm.
Sprint: Một chu kỳ lặp đi lặp lại công việc tương tự nhằm tạo ra các phần tăng trưởng cho hệ thống. Sprint thường kéo dài từ một tuần tới một tháng.Trong suốt dự án, thời gian cho một Sprint là cố định. Từ “sprint” có nghĩa là giai đoạn nước rút, ám chỉ sự gấp gáp và tập trung cao độ trong khoảng thời gian ngắn để làm việc
Sprint backlog: Danh sách các công việc thực hiện trong Sprint
Burndown Chart: là biểu đồ thể hiện xu hướng của công việc còn lại theo thời gian trong một Sprint, một bản phát hành (Release), hoặc sản phẩm. Dữ liệu cho Biểu đồ Burndown được lấy từ Sprint Backlog và Product Backlog, với công việc còn lại được theo dõi trên trục tung và khoảng thời gian (các ngày trong một Sprint, hoặc nhiều Sprint) theo dõi trên trục hoành. Biểu đồ Burndown được dùng cho Bản phát hành (khi đó gọi là Release Burndown) hoặc cho Sprint (gọi là Sprint Burndown).
KH: Khách hàng
PTYC: Phân tích yêu cầu
TKTT: Thiết kế tổng thể
TKCT: Thiết kế chi tiết
KBKT: Kịch bản kiểm thử
KTNT: Kiểm thử nghiệm thu
BBBG: Biên bản bàn giao sản phẩm
HDSD: Tài liệu hướng dẫn sử dụng
3. Trình tự thực hiện

3.1 Giai đoạn tiền khởi động dự án

  • Product Owner thực hiện xin cấp mã dự án, gửi yêu cầu tới các bộ phận để yêu cầu/ xác định đội dự án
  • Product owner cùng các thành viên đội dự án ( nếu cần ) tiến hành lập kế hoạch và thực hiện khảo sát sơ bộ

3.2 Lập Product backlog

  • Product Owner sẽ tiến hành tạo Product Backlog theo biểu mẫu BM_ProductBacklog bao gồm các thông tin:
    • ID ( Số định danh) : Một định danh duy nhất, là một con số thứ tự tăng. Điều này nhằm tránh việc nhầm lẫn các story khi đổi tên.
    • Name (Tên) : Một cái tên ngắn, có tính mô tả cho Story.
    • Important ( Độ quan trọng): Mức độ quan trọng của Story mà Product Owner đánh giá.
    • Initial Estimate (Ước tính ban đầu (MD)): Ước tính ban đầu cho Scrum team về nỗ lực cần thiết để thực hiện story này so với story khác.
    • How to demo (Cách thức demo): Mô tả về cách thức demo các tính năng thực hiện trong buổi họp demo ở cuối Sprint.
    • Notes (Lưu ý): Bất kỳ các thông tin nào khác, dùng để phân loại, tham chiếu đến các nguồn tài nguyên khác,…
  • Product Owner có trách nhiệm đảm bảo Product Backlog được ký xem xét/ phê duyệt bởi các bộ phận:
    • Xem xét: QA, Scrum master.
    • Phê duyệt: Trưởng phòng sản phẩm
  • Thời gian ký phê duyệt: tối đa sau 5 ngày làm việc kể từ thời điểm cấp mã dự án.
  • Cách thức thực hiện Product backlog.

3.3 Lập kế hoạch chi tiết Sprint

Product Owner chủ trì thực hiện họp lập kế hoạch chi tiết Sprint, phối hợp với Scrum master đóng vai trò người hướng dẫn. Thời gian họp ≤ số tuần trong một sprint * 2 giờ.

Lưu ý: Scrum team cần xác định chu kỳ lặp của dự án ( thời gian thực hiện 1 Sprint) với chu kỳ 2 – 3 tuần (khuyến cáo không lớn hơn 1 tháng)

Product Owner sẽ đưa ra mục đích đối với Sprint, từ đó Scrumteam sẽ thực hiện ước lượng thời gian cho mỗi story, bắt đầu với story quan trọng nhất. Sau đó nhóm sẽ chọn Story phù hợp đảm bảo tính khả thi để đưa vào SprintBacklog . Chia nhỏ Story thành các task công việc thực hiện.

Xác định rõ các sản phẩm đầu ra của Sprint

Scrum team đưa ra kế hoạch thực hiện các tài liệu (TKCT, TKTT ..) phục vụ cho việc nâng cấp và bảo trì hệ thống. Các tài liệu này bắt buộc phải có trước khi kết thúc dự án, tuy nhiên Scrum team nên thực hiện các tài liệu này song song từng phần trong các vòng lặp để các tài liệu mang tính chính xác cao hơn.

Chú ý: Tài liệu phải mô tả đầy đủ các yêu cầu về chức năng và phi chức năng

Sau khi Sprint backlog hoàn tất, từng thành viên scrum team nhận công việc thực hiện trong Sprint

3.4 Thực hiện Sprint

  • Scrum team thực hiện các đầu việc đã nhận theo Sprint backlog
  • Scrum master chịu trách nhiệm về tình hình dự án, hiệu suất làm việc của các thành viên trong nhóm phát triển và sự phối hợp giữa họ, và loại bỏ những trở ngại ảnh hưởng đến quá trình thực hiện Sprint
  • Scrum team thực hiện họp định kỳ ngắn hàng ngày trong vòng 15 phút mang tính đồng bộ hóa công việc của đội:
    • Scrum Master tóm tắt lại vòng lặp đã thực hiện được những gì và cần làm những gì.
    • Các thành viên xác định 3 vấn đề:
      • Đã làm được gì kể từ buổi họp trước?
      • Hôm nay sẽ thực hiện các công việc gì?
      • Có gặp vấn đề/ khó khăn gì trong công việc không?
    • Các thành viên trong nhóm sẽ báo cáo tiến độ và tình hình chung cho nhau, đưa ra những thay đổi nếu cần thiết để đảm bảo mục đích của Sprint.
    • Sau buổi họp Sprint hàng ngày, scrum team sẽ thực hiện cập nhật tình hình thực hiện vào file Story và Scrum master cập nhật lại biểu đồ Burndown ( Biểu đồ giúp Scrum team nhìn thấy tiến độ thực hiện hiện tại đang nhanh hay trễ so với kế hoạch).
  • Nếu tới cuối Sprint mà vẫn còn những task công việc chưa được thực hiện thì vẫn dừng Sprint và để task công việc đó vào Sprint sau.
  • Trong các Sprint, Scrumteam nên hoàn thiện các tài liệu thiết kế theo từng chức năng.

Chú ý: Khi lập trình và kiểm thử phải tuân thủ theo đúng các hướng dẫn lập trình, guideline về lập trình web an toàn, bảo đảm các tiêu chí chất lượng phần mềm.

3.5 Sơ kết Sprint (Sprint Demo):

Buổi họp này được tiến hành tại giai đoạn cuối của một sprint sau khi Scrum Team đã hoàn thành căn bản sản phẩm.

  • Mục đích: để xác nhận kết quả làm việc của Team trong sprint vừa rồi. Khẳng định họ đã làm đúng theo những gì đã được yêu cầu và đề ra trong cuộc họp kế hoạch sprint chưa.
  • Thành phần tham gia: Product Owner, Scrum Team, Scrum Master.
  • Đầu vào: Print Backlog, sản phẩm sprint.
  • Đầu ra: Là kết quả đánh giá của Product Owner về sản phẩm của Sprint, bản Product backlog đã được update các thông tin về mức độ ưu tiên mới.
  • Cách thức thực hiện:
    • Scrum Team demo sản phẩm sprint cho Product Owner và tất cả mọi người tham dự. Các nội dung cần trình bày sau buổi Sprint Review như sau:
      • Scrum Team trình bày rõ lại mục tiêu của Sprint một cách ngắn gọn (dựa vào Sprint backlog)
      • Scrum Team demo kết quả đã làm được trong sprint (chú ý nói về các mục đã làm được chứ không phải nói về công nghệ đã sử dụng). Tập trung demo vào các luồng nghiệp vụ chính.
      • Chỉ cần nêu ra các lỗi nhỏ, không cần demo chúng, giao diện có thể chỉnh sửa sau.
    • Product owner đánh giá kết quả thực hiện được của Scrum Team ( Done/fail) . Khi đánh giá Product Owner cần chú ý như sau:
      • Đánh giá trên mục đích tổng quan của sprint chứ không tập trung vào những thứ nhỏ lẻ, các trường thông tin hay giao diện.
      • Quá trình demo, đánh giá chia thành các trường hợp có thể gặp phải như sau:
        • Nếu gặp phải lỗi Crash làm đứt luồng chạy chính: Product owner đánh giá story chưa được hoàn thành -> đội phát triển phải trả story đó về sprint backlog, đưa về sprint tiếp theo. Đồng thời, vấn đề cần được đưa ra phân tích tại buổi họp cải tiến sprint.
        • Nếu gặp các lỗi ở mức độ nhỏ, có thể hoàn thành trong khoảng thời gian còn lại của sprint -> Scrum Team cùng thống nhất chỉnh sửa ngay sau đó. Nếu lỗi mà theo ước lượng không thể hoàn thành trong khoảng thời gian còn lại của sprint thì đánh giá đó là lỗi lớn và đưa về product backlog tương tự trường hợp gặp lỗi crash.
    • Scrum team trình bày về các vấn đề gặp phải trong sprint (về mặt kỹ thuật, về chức năng chương trình), và đưa ra những đề xuất để tránh, giải quyết các vấn đề cho sprint tiếp theo.

3.6 Cải tiến Sprint

Sau buổi demo, Product Owner sẽ họp với Scrum Master và team Scrum đưa ra những thất bại, khó khăn trong Sprint vừa thực hiện để rút ra kinh nghiệm và đưa ra những đề xuất cải thiện trong Sprint tiếp theo.

Scrum master chủ trì họp cùng Product Owner, team Scrum để đánh giá lại các hoạt động của team để hoàn thiện team. Bao gồm các mặt sau được ghi nhận lại trong báo cáo tổng kết Sprint

Quy trình thực hiện của Sprint.

Cách thức phối hợp nội bộ trong team.

Cách viết tài liệu thiết kế trong có được đảm bảo không.

Phương pháp lên kế hoạch cho từng Sprint.

Các kinh nghiệm, các bài học rút ra.

Nếu còn yêu cầu thì tiếp tục lặp lại Sprint tiếp theo.

3.7 Hoàn thiện sản phẩm

Trước khi nghiệm thu nội bộ Scrum team tiến hành:

  • Tối ưu lại sản phẩm theo tiêu chí chất lượng sản phẩm phần mềm của cty;
  • Hoàn thiện tài liệu sản phẩm ( tài liệu yêu cầu, thiết kế, kịch bản kiểm thử, HDSD..)

3.8 Nghiệm thu, triển khai, bàn giao phần mềm

  • Các bước thực hiện tuân thủ hướng dẫn triển khai của công ty.

3.9 Kết thúc

  • Các bước thực hiện tuân thủ hướng dẫn kết thúc dự án của công ty.

3.10 Lưu hồ sơ

(Các bước 3.8 – 3.10 tùy thuộc quy định của cty và đặc trưng dự án, tôi sẽ đưa ra một số khuyến nghị trong bài tiếp)