Quản trị hệ thống thông tin là một lĩnh vực được sử dụng để quản lý các hệ thống thông tin của một doanh nghiệp.. Phầm mèm chia thành 2 phần: Phần mềm hệ thống: o Hệ điều hành o Phần m
TỔNG QUAN VỀ QUẢN TRỊ HỆ THỐNG THÔNG TIN
Quản trị hệ thống thông tin là gì?
Hệ thống là tập hợp gồm các phần tử, có những mối quan hệ ràng buộc với nhau và chúng cùng hoạt động để hướng tới một mục đích chung Trong một hệ thống, tập hợp các phần tử rất đa dạng, trừu tượng, có thể là các hệ thống phức tạp, Các quan hệ ràng buộc với nhau có thể là các quan hệ ổn định lâu dài hoặc là các quan hệ tạm thời
Hệ thống thông tin là một hệ thống bao gồm các yếu tố có quan hệ với nhau cùng làm nhiệm vụ thu thập, xử lý, lưu trữ và phân phối thông tin và dữ liệu và cung cấp một cơ chế phản hồi để đạt được một mục tiêu định trước
Các tổ chức có thể sử dụng các hệ thống thông tin với nhiều mục đích khác nhau Trong việc quản trị nội bộ, hệ thống thông tin sẽ giúp đạt được sự thông hiểu nội bộ, thống nhất hành động, duy trì sức mạnh của tổ chức, đạt được lợi thế cạnh tranh Với bên ngoài, hệ thống thông tin giúp nắm bắt được nhiều thông tin về khách hàng hơn hoặc cải tiến dịch vụ, nâng cao sức cạnh tranh, tạo đà cho sự phát triển
Quản trị là quá trình thực hiện các tác động của chủ thể quản lý lên đối tượng quản lý để phối hợp hoạt động của các cá nhân và tập thể nhằm đạt các mục tiêu đã đề ra của tổ chức, là quá trình làm việc với người khác và thông qua người khác để thực hiện các mục tiêu của tổ chức trong một môi trường luôn biến động
Quản trị hệ thống thông tin là một lĩnh vực được sử dụng để quản lý các hệ thống thông tin của một doanh nghiệp Nó bao gồm việc quản lý các hệ thống phần cứng, phần mềm, dữ liệu và các quy trình liên quan đến hệ thống Nó cũng bao gồm việc giám sát, bảo trì, bảo vệ và cải thiện các hệ thống thông tin Quản trị hệ thống thông tin còn được hiểu là việc con người trực tiếp cài đặt hệ điều hành, phần mềm cho máy tính nhằm mục đích đảm bảo hệ thống luôn được vận hành một cách tốt nhất và phải lưu trữ được các bản backup dự phòng khi gặp các tình huống khẩn cấp hoặc thực hiện các biện pháp bảo mật cũng
6 như sửa lỗi khi có vấn đề cấp bách xảy ra
Công việc này đặc biệt chú trọng đến vai trò của việc ứng dụng công nghệ thông tin vào quá trình hoạt động quản trị, sản xuất và kinh doanh trong các doanh nghiệp
Phân loại hệ thống thông tin:
- Transaction Processing Systems: Hệ thống xử lý giao dịch đảm bảo rằng tất cả dữ liệu hợp đồng, giao dịch và dữ liệu khách hàng được lưu trữ ở một vị trí an toàn và có thể truy cập được cho tất cả những ai cần nếu có quyền Nó cũng hỗ trợ xử lý các mục liên quan đến các giao dịch
- Office Automation Systems: Hệ thống tự động hóa văn phòng là một mạng lưới các công cụ, công nghệ khác nhau để những người cần thiết thực hiện các công việc quản lý và văn thư
- Knowledge Management Systems: Hệ thống quản lý tri thức lưu trữ và trích xuất thông tin để giúp người dùng nâng cao kiến thức của họ và tối ưu hóa thời gian để hoàn thành công việc
- Management Information Systems: Hệ thống thông tin quản lý sử dụng nhiều dữ liệu khác nhau để giúp cấp quản lý tối ưu hóa việc lập kế hoạch và ra quyết định
- Decision Support Systems (DSS): Hệ thống hỗ trợ quyết định xử lý dữ liệu để hỗ trợ việc ra quyết định của cấp quản lý Nó lưu trữ và thu thập thông tin cần thiết để quản lý, hỗ trợ đưa ra các hành động thích hợp đúng thời điểm
- Executive Support System: Hệ thống hỗ trợ điều hành chủ yếu được sử dụng bởi các nhà lãnh đạo điều hành và chủ sở hữu để tối ưu hóa việc ra quyết định.
Các thành phần cơ bản của quản trị hệ thống thông tin
- Phần cứng bao gồm máy tính và tất cả những thiết bị hỗ trợ nó
Thiết bị hỗ trợ bao gồm thiết bị đầu vào và đầu ra, thiết bị lưu trữ, bộ xử lý, tất cả đều hoạt động cùng nhau để nhận, xử lý, hiển thị dữ liệu và thông tin
Hình 1 Các thành phần của phần cứng trong quản trị HTTT
- Phần mềm là các chương trình máy tính và hướng dẫn sử dụng (nếu có) Các chương trình máy tính là các hướng dẫn mà máy tính có thể đọc hiểu được, hướng dẫn mạch trong các bộ phận phần cứng của hệ thống hoạt động theo những cách tạo ra thông tin hữu ích từ dữ liệu Phầm mèm chia thành 2 phần:
Phần mềm hệ thống: o Hệ điều hành o Phần mềm biên dịch ngôn ngữ và phần mềm tiện ích
Phần mềm ứng dụng: o Phần mềm xử lý đa năng: Phần mềm xử lý văn bản, bảng tính điện tử, phần mềm quản lý CSDL, phần mềm trình diễn văn bản (Power Point), phần mềm quản lý thông tin cá nhân… o Phần mềm ứng dụng chuyên biệt: bao gồm các phần mềm sử dụng cho các công việc chuyên biệt VD: phần mềm xử lý số liệu, quản lý chất lượng công việc…
- Cơ sở dữ liệu là tập hợp các tập tin hoặc bảng lưu trữ các dữ liệu liên quan Các tổ chức dựa vào dữ liệu để đưa ra quyết định Bao gồm: Hệ quản trị CSDL và mô hình CSDL
- Con người: Có thể là người dùng, những người vận hành và bảo dưỡng, những người duy trì dữ liệu,
Một số yêu cầu cần có của nhân lực:
─ Sự hiểu biết về công nghệ thông tin
─ Trách nhiệm đạo đức đôi với xã hội
Một bộ máy nhân lực quản trị hệ thống thông tin thường gồm:
- Hệ thống truyền thông là một hệ thống cho phép tạo, truyền và nhận tin tức, hay còn được gọi là hệ thống viễn thông, mạng viễn thông Cac thiết bị có thể gửi tín hiệu, nhận tín hiệu hoặc vừa gửi vừa nhận tín hiệu Để thực hiện được nhiệm vụ đó, mỗi hệ thống truyền thông gồm có ít nhất 3 yếu tố: thiết bị phát tin, kênh truyền và thiết bị nhận tin
Một vài phương thức truyền thông: truyền thông kỹ thuật số, truyền thông không đồng bộ và truyền thông đồng bộ
- Kênh truyền thông hữu tuyến: dây dẫn xoắn đôi, cáp đồng trục, cáp quang
- Kênh truyền thông vô tuyết: sóng viba, vệ tinh, tia hồng ngoài,
Các cấu hình mạng: mạng bus, mạng hình sao, mạng vòng
Mạng theo phạm vi: Mạng LAN, mạng WAN, mạng MAN, mạng Internet
Vai trò
Vai trò chiến lược của hệ thống thông tin là nâng cao dịch vụ thông tin trong một tổ chức Hệ thống thông tin được phát triển để đáp ứng với những sáng kiến kinh doanh của công ty và chúng nhằm mục đích mang lại lợi thế cạnh tranh cho tổ chức đó Hệ thống thông tin kinh doanh thường thực hiện các chức năng cụ thể để hỗ trợ các hoạt động như: tính lương, lưu trữ hồ sơ nhân viên, chuẩn bị, lưu trữ các tài liệu của công ty, báo cáo, Trong hoạt động hỗ trợ, hệ thống thông tin có thể tăng hiệu quả và cải thiện năng suất làm việc của nhân viên
Lợi ích chính của hệ thống thông tin là khả năng cung cấp cho người dùng thông tin cần thiết để thực hiện bất kỳ nhiệm vụ nào một cách dễ dàng và hiệu quả Hệ thống thông tin cung cấp dữ liệu thích hợp với định dạng phù hợp nhất cho nhiệm vụ của người dùng Các nhà nghiên cứu của Huawei phát hiện ra rằng vào năm 2016, nền kinh tế kỹ thuật số trên toàn thế giới trị giá 11,5 nghìn tỷ đô la hoặc 15,5% GDP toàn cầu [PDF, 22,8 MB]
Quản trị hệ thống thông tin có nhiều lợi ích, bao gồm: giúp các công ty cải thiện hiệu suất, năng suất công việc; giảm chi phí; giảm rủi ro; kiểm soát, quản lý dữ liệu một cách hiệu quả; tuân thủ các quy định; dễ dàng áp dụng công nghệ mới và đảm bảo an toàn các thông tin, dữ liệu độc quyền của doanh nghiệp
Cải thiện năng suất công việc: Một hệ thống quản trị thông tin tốt sẽ hỗ trợ và giúp đỡ rất nhiều cho lực lượng nhân sự của doanh nghiệp Họ có thể cải thiện cách lưu trữ, truy xuất những thứ cần thiết để phục vụ công việc Chúng cũng giúp truyền tải thông điệp đến đa dạng người nhận qua các kênh Thông tin chính là trợ thủ đắc lực của các nhà quản trị và góp phần giúp tăng hiệu suất làm
Giảm chi phí: Doanh nghiệp cần phải có cách quản lý hệ thống thông tin hiệu quả để giảm thiểu chi phí lưu trữ hồ sơ Một số những hoạt động khiến tiêu tốn ngân sách nội bộ thường thấy có thể kể đến như là: Thu thập; Phân tích; Lưu trữ; Chia sẻ; Tiêu hủy thông tin…Ở các công ty, tập đoàn có quy mô lớn, chúng ta càng có thể dễ dàng nhận ra tác động này Chính vì vậy, quy tắc thực hiện ở đây chính là phải ưu tiên các nguồn dữ liệu quan trọng nhất và thường xuyên thực hiện sàng lọc để rút ngắn vòng đời của thông tin một cách tối đa
Giảm rủi ro: Một trong số những chức năng quan trọng khác của quản trị hệ thống thông tin là giảm thiểu rủi ro bị xử phạt Nó liên quan trực tiếp đến mặt pháp lý và tài chính của doanh nghiệp Có thể đạt được điều này bằng việc vận hành giao thức rõ ràng dùng để ghi, lưu trữ cũng như xoá bỏ và hủy dữ liệu Nhờ chức năng này mà doanh nghiệp có thể yên tâm vận hành tổ chức của mình, mà không cần lo lắng về nguy cơ vi phạm pháp lý Bởi vì, mọi thông tin đến và đi đều được định hướng, kiểm duyệt một cách cẩn thận trong từng khâu
Kiểm soát, quản lý dữ liệu một cách hiệu quả: Xây dựng một hệ thống quản trị thông tin hiệu quả giúp doanh nghiệp kiểm soát và quản lý mọi loại dữ liệu một cách hiệu quả Nếu thiếu đi chiến lược này sẽ dẫn tới việc doanh nghiệp bị tồn đọng quá nhiều giấy tờ, hồ sơ Chúng sẽ không được sắp xếp theo quy tắc và dẫn đến rất khó tìm thấy khi cần Xây dựng một hệ thống quản trị thông tin giúp cho các luồng thông tin được kiểm soát một cách dễ dàng
Tuân thủ quy định: Có không ít các doanh nghiệp phải thường xuyên làm việc với dữ liệu bảo mật cá nhân của khách hàng Chính
11 vì thế mà quản lý thông tin hiệu quả đã giúp cho doanh nghiệp tuân thủ các quy định đã đề ra Mà mục đích cuối cùng mà doanh nghiệp hướng tới chính là thực thi theo quy định và yêu cầu của pháp luật Qua đó, mà công ty sẽ tránh được các hình phạt có liên quan đến pháp lý hoặc tài chính Nhờ vậy mà uy tín cũng như danh tiếng của doanh nghiệp sẽ không bị ảnh hưởng bởi việc rò rỉ, lạm dụng thông tin
Dễ dàng áp dụng các công nghệ mới: Quá trình quản lý hệ thống thông tin chính là cơ hội để doanh nghiệp có thể áp dụng công nghệ có hiệu quả hơn Chúng sẽ thường liên quan tới các tính năng như tự động hóa hay là các giải pháp dành doanh nghiệp Sự kết hợp giữa cách thức quản lý cũng như công nghệ hiện đại sẽ giúp doanh nghiệp khai thác một cách triệt đề các tài nguyên sẵn có Từ đó, doanh nghiệp sẽ dễ dàng phát hiện, sáng tạo ra nhiều ý tưởng mới, độc lạ mà chỉ có họ mới sở hữu
Bảo vệ và đảm bảo an toàn các thông tin, dữ liệu độc quyền: Quản trị hệ thống thông tin phản ánh một cách chính xác cách mà doanh nghiệp bảo vệ các dữ liệu các thông tin quan trọng của mình Hệ thống có thể giúp doanh nghiệp ngăn chặn các tác động xấu từ đối thủ cạnh tranh và đồng thời phòng được các lượt truy cập trái phép Nhờ có việc Quản trị hệ thống thông tin mà các chủ doanh nghiệp có thể thực hiện việc quản trị dữ liệu tới từng người dùng trong doanh nghiệp một cách dễ dàng Nhờ đó mà nhà quản trị có thể dễ dàng hoạch định được các chiến lược, đưa ra các chính sách phát triển đúng đắn cho doanh nghiệp để có thể tổ chức các hoạt động sản xuất kinh doanh một cách chuyên nghiệp và có hiệu quả Đầu tư vào các hoạt động quản trị trong doanh nghiệp là một khoản đầu tư rất thông minh bởi vì trong thời đại kỷ nguyên số khi mà công nghệ thông tin đang ngày một phát triển như hiện nay thì sự cạnh tranh giữa các doanh nghiệp
12 luôn là vấn đề quan trọng, mang tính chất sống còn đối với các doanh nghiệp lớn nhỏ Quản trị hệ thống thông tin cho thấy hiệu quả trong quản lý dữ liệu cũng như quản lý người dùng trong doanh nghiệp của bạn, đồng thời tối ưu hóa quá trình quản trị hệ thống thông tin trong doanh nghiệp
Bên cạnh đó, Quản trị hệ thống thông tin còn giúp các doanh nghiệp dự báo một cách chính xác hơn nhờ việc sắp xeép và quản lý các thông tin, dữ liệu một cách khoa học, từ đó có thể đưa ra những ước đoán trên thực tế và dự báo hiệu quả hơn
Ngoài ra, Quản trị hệ thống thông tin còn giúp các bộ phận trong doanh nghiệp tương tác với nhau một cách dễ dàng hơn Không chỉ giúp cho việc quản lý nhân viên thuận lợi, mà các bộ phận, nhân viên và người dùng dữ liệu trong doanh nghiệp có thể dễ dàng trao đổi cũng như làm việc cùng nhau và nâng cao hiệu quả, chất lượng làm việc.
Một số phương pháp tiếp cận
Thiết kế hướng chức năng (Functional Oriented): Trong thiết kế hướng chức năng, hệ thống bao gồm nhiều hệ thống con nhỏ được gọi là chức năng Các chức năng này có khả năng thực hiện nhiệm vụ trọng trong hệ thống Hệ thống được coi là cái nhìn từ trên xuống của tất cả các chức năng Cơ chế thiết kế này chia toàn bộ hệ thống thành các chức năng nhỏ hơn, cung cấp các phương thức trừu tượng hóa để che giấu thông tin và hoạt động của chúng Các mô-đun chức năng này có thể chia sẻ thông tin với nhau bằng cách truyền và sử dụng thông tin toàn cục Thiết kế hướng chức năng hoạt động tốt khi trạng thái của hệ thống là không quan trọng và chức năng hoạt động dựa trên đầu vào Bị ảnh hưởng bởi các ngôn ngữ lập trình Chỉ tập trung vào thông tin, ít quan tâm đến đối tượng thực hiện với thông tin hay hành vi hệ thống
Thiết kế hướng đối tượng (Object Oriented): Thiết kế hướng đối tượng là quá trình sử dụng phương pháp luận hướng đối tượng để thiết kế một hệ thống
Kỹ thuật này cho phép thực hiện một giải pháp phần mềm dựa trên các khái
13 niệm về đối tượng Trong thiết kế và phát triển hệ thống hướng đối tượng, Object Oriented Design giúp thiết kế kiến trúc hoặc bố cục hệ thống sau khi hoàn thành phân tích hướng đối tượng (Object Oriented analysis) Hệ thống được thiết kế sau này được tạo ra, lập trình bằng các kỹ thuật dựa trên hướng đối tượng và ngôn ngữ lập trình hướng đối tượng (Object oriented programming) Mục tiêu tạo ra những sản phẩm phần mềm tin cậy, dễ mở rộng, thích nghi, phù hợp với yêu cầu của khách hàng Một số đặc trưng của thiết kế hướng đối tượng: đặt trọng tâm vào dữ liệu (thực thể), xem hệ thống như là một tập các thực thể, các lớp đối tượng trao đổi với nhau qua các thông điệp, hỗ trợ kế thừa và sử dụng lại Các bước phát triển của một hệ thống thông tin:
Khảo sát hiện trạng là tìm hiểu, thu thập các thông tin cần thiết để chuẩn bị cho việc giải quyết các yêu cầu, bài toán được đặt ra của dự án Từ đó, sẽ chọn lọc những thông tin, yếu tố cần thiết để xây dựng hệ thống thông tin
Mục tiêu là xác định các thông tin và chức năng xử lý của hệ thống thông tin như: o Xác định yêu cầu của hệ thống thông tin như: các chức năng chính, chức năng phụ, các nghiệp vụ của hệ thống, o Phân tích bảng dữ liệu, biểu mẫu, các hóa đơn chứng từ, xác định những dữ liệu hệ thống cần xử lý, mối quan hệ giữa chúng o Ở giai đoạn này, các đặc tả sơ bộ sẽ giúp các chuyên gia có cái nhìn khách quan Từ đó, xác định được những giải pháp tốt nhất cho hệ thống đảm bảo đúng các yêu cầu đã khảo sát trước đó
Thiết kế hệ thống: Thiết kế hệ thống thông tin là việc sử dụng các
14 công cụ, phương pháp để tạo ra các mô hình cho hệ thống cần xây dựng
Thực hiện xây dựng hệ thống: Xây dựng hệ thống thông tin theo thiết kế
Lựa chọn các công cụ, nền tảng, để xây dựng hệ thống thông tin Xây dựng tài liệu hướng dẫn sử dụng, các tài liệu kỹ thuật
Kiểm thử hệ thống: Lựa chọn công cụ kiểm thử, viết test case Thử nghiệm các modules chức năng, thử nghiệm hệ thống thông tin Khắc phục các lỗi nếu có Đảm bảo một hệ thống thông tin đạt những yêu cầu đã đặt ra
Triển khai và bảo trì: Triển khai lắp đặt phần cứng, cài đặt phần mềm, chuyển đổi hoạt động của hệ thống cũ sang hệ thống mới nếu có
CÁC PHƯƠNG PHÁP PHÁT TRIỂN HỆ THỐNG THÔNG TIN
Phương pháp Agile
Việc sử dụng các phương pháp Agile đã tăng lên nhanh chóng trong lĩnh vực ISD, một sự tiến hóa nhanh chóng hầu như được xác định bởi các nhà thực hành hơn là các nhà nghiên cứu (Conboy 2009) Mặc dù các nguyên tắc cơ bản của nó đã xuất hiện từ những năm 1970, nhưng phương pháp luận Agile đã thực sự đạt được động lực trong suốt 15 năm qua (Abbas et al 2008) Khi các phương pháp Agile ngày càng trở nên phổ biến, các nhà nghiên cứu ngày càng quan tâm nhiều hơn đến việc nghiên cứu và hệ thống hóa chúng (Conboy 2009) Các phương pháp luận Agile đã phát triển xung quanh khái niệm rằng sự phát triển của IS là một công việc sáng tạo, nơi các hoạt động thiết kế chiếm một vị trí quan trọng (Tumbas and Matkovic 2006) Mặt khác, chúng cũng dựa trên tiền đề là quá trình phát triển thường kéo theo những thay đổi và thích ứng liên tục làm phát sinh nhu cầu về các cách tiếp cận và phương pháp linh hoạt
Do đó, có thể khẳng định rằng việc tăng cường sử dụng các phương pháp agile có liên quan đến sự không ổn định của môi trường công nghệ Không phải lúc nào khách hàng cũng có thể mô tả nhu cầu cần thiết của họ một cách toàn diện khi bắt đầu một dự án cụ thể Do đó, các nhà phát triển nhận thấy cần phải tạo ra các phương pháp có khả năng thích ứng với các hoàn cảnh và thông số kỹ thuật thay đổi trong quá trình thiết kế và phát triển Theo Tumbas và Matkovic (2006), việc phát triển các quy trình IS cần phải linh hoạt để cho phép người dùng phân tích và điều chỉnh các nhu cầu và yêu cầu của họ thường xuyên mà không gây nguy hiểm đến hiệu quả của toàn bộ quy trình
Tập trung vào việc phát triển theo giai đoạn và sự phản hồi của khách hàng Các giai đoạn phát triển được gọi là sprint ( kéo dài từ 1 đến 4 tuần)
Hình 2 Giai đoạn phát triển trong Agile
Ngoài ra, có ý kiến cho rằng các phương pháp agile đã xuất hiện như một phản ứng đối với sự bất lực của các phương pháp trước đó để chống chọi nhanh chóng và hiệu quả với các bối cảnh năng động và thay đổi (Abrahamsson et al
2009 citing Highsmith 2002), đây là điểm phổ biến trong bối cảnh của IS và xã hội thông tin
Như vậy, có thể tóm tắt rằng các phương pháp agile chủ yếu mang tính thích nghi hơn là dự đoán, đồng thời hướng đến thời gian phát triển nhanh hơn và tích hợp nhiều hơn với nhu cầu của khách hàng Ưu điểm chính của các phương pháp này là chúng có thể dễ dàng điều chỉnh theo các bước khác nhau của dự án (Aydin et al 2004), làm cho chúng dễ dàng thích ứng với nhiều thông số kỹ thuật mà các dự án khác nhau có thể đưa ra Đây là một lời giải thích tại sao phương pháp nhanh chóng lại trở nên phổ biến như vậy
Một ví dụ về phương pháp agile là lập trình cực đoan (XP), một phương pháp phát triển phần mềm lặp đi lặp lại đòi hỏi sự tương tác tối đa của khách hàng Chu kỳ phát triển được chia thành các chu kỳ ngắn hơn Mỗi chu kỳ bắt đầu với việc thu thập các yêu cầu của người dùng, tiếp theo là lập kế hoạch lặp lại, trong đó số lượng chu kỳ và khung thời gian tương ứng được thiết lập Sản phẩm sau đó được phát triển, thường thông qua lập trình cặp Phiên bản kết quảcủa sản phẩm được kiểm tra, cả về mặt kỹ thuật cũng như để người dùng chấp nhận Phản hồi thu được từ quá trình thử nghiệm này và sự can thiệp của khách hàng được tính đến để phát triển phiên bản tiếp theo, do đó bắt đầu chu
17 kỳ tiếp theo Phương pháp này được lặp lại cho đến khi một phiên bản được tạo ra có thể chấp nhận được đối với đa số người dùng, người quản lý và nhà phát triển (Sharma et al 2012)
Trong một cuộc khảo sát năm 2013 đối với các công ty ở Bắc Mỹ và Châu Âu, phương pháp Scrum được kết luận là phương pháp nhanh được áp dụng phổ biến nhất trong năm đó, tiếp theo là phương pháp kết hợp Scrum / XP, chiếm 73% tổng số phương pháp agile được sử dụng trong cuộc khảo sát (VersionOne 2013) Đâylà dấu hiệu cho thấy phương pháp Scrum linh hoạt như thế nào
Ưu điểm: o Agile là sự lựa chọn rất tốt cho những dự án nhỏ bởi những dự án nhỏ thường có những yêu cầu không được xác định rõ ràng và có thể thay đổi thường xuyên o Với Agile khách hàng có thể được xem trước từng phần dự án trong suốt quá trình phát triển vì Agile phát triển phần mềm theo hướng tăng dần, có thể đưa cho khách hàng xem từng phần đã thực hiện hoàn thành Từ đó có thể bám sát dự án và luôn sẵn sàng cho bất kỳ thay đổi nào từ phía khách hàng yêu cầu về dự án o Agile chia dự án thành những phần nhỏ và giao cho mỗi người, hàng ngày tất cả mọi người phải họp với nhau trong khoảng thời gian ngắn để thảo luận về tiến độ và giải quyết những vấn đề nảy sinh nếu có nhằm đảm bảo đúng quy trình phát triển dự án o Tỉ lệ thành công của các dự án sử dụng Agile thường cao hơn các quy trình khác
18 o Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết o Quy mô nhân lực thường giới hạn từ 7 đến 10 người, sẽ có trở ngại lớn nếu nguồn nhân lực yêu cầu vượt quá con số này ví dụ trong các cuộc họp trao đổi o Số lượng yêu cầu có thể nhiều và khó quản lý nếu như nó bao gồm nhiều khía cạnh khác nhau về dự án o Số lượng nhân lực càng tăng, chất lượng càng khó kiểm soát hơn Việc kiểm tra mã thường xuyên và thiết lập các chỉ tiêu đánh giá năng lực của lập trình viên cho phép giảm thiểu nhược điểm này.
Phương pháp Waterfall
Waterfall là một trong những phương pháp phát triển phần mềm có từ lâu đời Nó được sử dụng rộng rãi trong ngành công nghệ phần mềm Trong mô hình này, quá trình phát triển phần mềm được chia thành các giai đoạn khác nhau tương ứng với các nội dung và nhiệm vụ khác nhau Mô hình thác nước giúp cho dự án phát triển phần mềm được diễn ra trình tự, giai đoạn mới chỉ được bắt đầu khi giai đoạn trước đã hoàn thành
Các giai đoạn của mô hình thác nước (waterfall model)
Trong mô hình thác nước (waterfall model), một dự án phát triển phần mềm sẽ được chia thành các giai đoạn khác nhau:
• Phân tích yêu cầu: Thảo luận để nắm rõ được các yêu cầu, thử nghiệm tất cả yêu cầu để đảm bảo chúng có thể kiểm chứng được hay không
• Thiết kế hệ thống: Theo yêu cầu để tạo ra thiết kế, thảo luận về phần cứng, phần mềm, tạo văn bản về chúng
• Thực hiện: Từ thiết kế tạo ra các chương trình
• Thử nghiệm hệ thống: Chắc chắn hệ thống đang hoạt động và
19 chạy được trong môi trường tương ứng Đảm bảo không có sự cố gì xảy ra khi hệ thống được triển khai
• Bảo trì hệ thống: Trong trường hợp người dùng gặp lỗi phải chắc chắn có thể khắc phục được Hệ thống luôn được cập nhật các tính năng mới để nâng cao hiệu quả hóa
Hình 3 Mô hình phát triển ứng dụng waterfall
Mô hình Thác nước SDLC được sử dụng khi:
• Yêu cầu ổn định và không thay đổi thường xuyên
• Không có yêu cầu mà không hiểu hoặc không rõ ràng
• Các công cụ và công nghệ được sử dụng là ổn định
• Nguồn lực được đào tạo và sẵn sàng
• Ưu điểm o Đơn giản, dễ hiểu và sử dụng o Đối với các dự án nhỏ hơn, mô hình thác nước hoạt
20 động tốt và mang lại kết quả phù hợp o Vì các giai đoạn của mô hình thác nước cứng nhắc và chính xác, một pha được thực hiện một lần, nó rất dễ dàng để maintain o Các tiêu chí đầu vào và đầu ra được xác định rõ ràng, do đó nó dễ dàng và có hệ thống để tiến hành chất lượng o Kết quả được ghi chép tốt.
• Nhược điểm o Không thể chấp nhận thay đổi yêu cầu o Nó trở nên rất khó khăn để di chuyển trở lại giai đoạn Ví dụ, nếu ứng dụng đã chuyển sang giai đoạn thử nghiệm và có thay đổi về yêu cầu, gặp khó khăn để quay lại và thay đổi nó o Việc giao hàng của sản phẩm cuối cùng là muộn vì không có mẫu thử nghiệm được chứng minh trung gian o Đối với các dự án lớn và phức tạp, mô hình này không tốt vì yếu tố rủi ro cao hơn o Không thích hợp cho các dự án mà yêu cầu được thay đổi thường xuyên o Không làm việc cho các dự án dài và đang diễn ra o Kể từ khi thử nghiệm được thực hiện ở giai đoạn sau, nó không cho phép xác định những thách thức và rủi ro trong giai đoạn trước đó nên chiến lược giảm thiểu rủi ro rất khó để chuẩn bị.
Phưong pháp Rapid Application Development
Phát triển ứng dụng nhanh (RAD) là một phương pháp tập trung vào - như tên gọi - phát triển nhanh chóng thông qua các lần lặp lại thường xuyên và phản hồi liên tục Khi nhu cầu về phần mềm và tính năng mới tăng vọt trong kỷ
21 nguyên công nghệ hiện đại của chúng ta, RAD đã trở thành một phương pháp phát triển ngày càng phổ biến trong kinh doanh trên toàn cầu
Phát triển ứng dụng nhanh (RAD) là một phương pháp tập trung vào phát triển ứng dụng nhanh chóng thông qua các lần lặp lại thường xuyên và phản hồi liên tục Khi thị trường phần mềm ngày càng cạnh tranh nhấn mạnh nhu cầu mạnh mẽ hơn đối với các ứng dụng mới, ngành CNTT đang cảm thấy áp lực phải cung cấp các sản phẩm hoạt động nhanh hơn và RAD đang trở thành một điều cần thiết
Khung RAD được giới thiệu bởi nhà tư vấn công nghệ và tác giả James Martin vào năm 1991, người đã nhận ra và tận dụng tính linh hoạt vô hạn của phần mềm để thiết kế các mô hình phát triển RAD là tiền thân của quản lý dự án linh hoạt, ngày càng trở nên phổ biến với các doanh nghiệp linh hoạt đang tìm kiếm các phương pháp bắt kịp với nhu cầu khách hàng và doanh nghiệp đang phát triển của họ Tập trung vào tạo mẫu nhanh, chu kỳ phát hành và lặp lại thay vì lập kế hoạch tốn kém, quá trình phát triển ứng dụng nhanh chóng được thúc đẩy bởi phản hồi của người dùng, thay vì lập kế hoạch nghiêm ngặt Nhu cầu phát triển ứng dụng nhanh chóng đã chứng kiến sự xuất hiện của rất nhiều nền tảng mã thấp và không có mã Nhu cầu này là điều mà Codebots cực kỳ đam mê và chủ động đáp ứng Sử dụng các bot viết mã của chúng tôi, bạn có thể nhanh chóng phát triển các ứng dụng và xây dựng nhanh hơn 8,3 lần so với tốc độ phát triển phần mềm tiêu chuẩn
Các phương pháp phát triển phần mềm truyền thống, như thác nước, tuân theo các mô hình quy trình cứng nhắc gây áp lực buộc khách hàng phải ký vào các yêu cầu trước khi dự án bắt đầu Khách hàng thường không thấy bản dựng hoạt động trong vài tháng, điều này làm phức tạp quá trình thay đổi đối với các yêu cầu mới và điều chỉnh tính khả thi
Một chu kỳ phát triển ứng dụng nhanh bao gồm bốn bước:
1 Xác định các yêu cầu của dự án;
3 Xây dựng nhanh & thu thập thông tin phản hồi; Và
4 Hoàn thiện sản phẩm/thực hiện
Hình 4 Minh họa mô hình RAD
Nguyên tắc chính của quy trình RAD là giảm bớt việc lập kế hoạch để tập trung vào quy trình xây dựng và thiết kế có tính lặp lại cao, cho phép các nhóm hoàn thành nhiều việc hơn trong thời gian ngắn hơn mà không ảnh hưởng đến sự hài lòng của khách hàng Các giai đoạn tạo mẫu và xây dựng nhanh có thể được lặp lại cho đến khi chủ sở hữu sản phẩm và người dùng hài lòng rằng nguyên mẫu và bản dựng đáp ứng các yêu cầu của dự án
RAD là một phương pháp tốt cho các môi trường có nhịp độ nhanh với các nhóm giàu kinh nghiệm có ngân sách cho các công cụ phát triển ứng dụng nhanh, như nền tảng mã thấp và trình tạo mã RAD đặc biệt hữu ích cho các doanh nghiệp nhỏ cung cấp các sản phẩm sáng tạo trong một thị trường cạnh tranh đòi hỏi mức độ tham gia kinh doanh cao Cách tiếp cận nhanh chóng thích ứng với sự thay đổi bất ngờ của các yêu cầu Khi các dự án có thời hạn chặt chẽ, các phương pháp phát triển ứng dụng nhanh giúp các nhóm chịu trách nhiệm cung cấp một sản phẩm hoạt động nhanh nhất có thể
RAD chỉ nên được sử dụng khi một hệ thống có thể được điều biến để phân phối dần dần Nếu bạn cần xây dựng công cụ kinh doanh nội bộ hoặc cổng thông tin dành cho khách hàng, RAD có thể hỗ trợ bạn mang lại trải nghiệm tốt hơn cho người dùng cuối của bạn Tuy nhiên, nếu phần mềm là nhiệm vụ quan
23 trọng và rủi ro kỹ thuật cao, tức là kết quả ảnh hưởng đến cuộc sống của mọi người, thì cách tiếp cận RAD là không phù hợp
• Ưu điểm o Tích hợp hệ thống sớm & giảm thiểu rủi ro: Các nhóm RAD nhanh chóng tạo và chia sẻ các nguyên mẫu đang hoạt động, cho phép doanh nghiệp xem xét chức năng sớm hơn trong vòng đời phần mềm Việc lặp lại thường xuyên và bản chất của phản hồi cho phép dễ dàng đánh giá tất cả các khía cạnh, cho phép tiến độ có thể đo lường được nhằm xác định xem lịch trình và ngân sách có đang đi đúng hướng hay không Việc tích hợp với các hệ thống và dịch vụ khác theo truyền thống xảy ra vào cuối vòng đời phát triển, nhưng các ứng dụng phát triển nhanh chóng được tích hợp gần như ngay lập tức Thử nghiệm diễn ra trong mỗi lần lặp lại, cho phép các bên liên quan nhanh chóng xác định và thảo luận về lỗi, lỗ hổng mã hoặc sự phức tạp và giải quyết chúng ngay lập tức mà không ảnh hưởng đến tiến độ phát triển Giảm rủi ro có nghĩa là giảm chi phí o Khả năng thích ứng và ngăn cách của các thành phần hệ thống Trong quá trình phát triển, phần mềm có thể uốn nắn được Việc thay đổi mã có thể thay đổi đáng kể toàn bộ hệ thống và các nhà phát triển có thể tận dụng tính linh hoạt này bằng cách lặp lại và tạo nguyên mẫu các khái niệm tiềm năng trong suốt quá trình phát triển Bản chất lặp đi lặp lại này khuyến khích các nhà thiết kế và nhà phát triển tạo ra các thành phần có chức năng và độc lập Mỗi phần tử được chia ngăn, giúp tăng khả năng sử dụng lại của các thành
24 phần và giúp việc sửa đổi dễ dàng thích ứng với nhu cầu phát triển phần mềm o Bản phát hành lặp đi lặp lại và thời gian đưa sản phẩm ra thị trường nhanh hơn: Việc sử dụng các công cụ phát triển mã thấp và RAD giúp các doanh nghiệp và nhóm CNTT cộng tác hiệu quả và cung cấp các ứng dụng mới, sẵn sàng sản xuất nhanh hơn, bằng cách giảm thời gian dành cho viết mã thủ công Các thành viên lành nghề trong nhóm có thể nhanh chóng tạo ra các nguyên mẫu và mã làm việc mà nếu không thì có thể mất hàng tuần hoặc hàng tháng Cần ít thành viên nhóm hơn, giúp tăng năng suất Việc lặp lại thường xuyên khuyến khích chia dự án thành các nhiệm vụ nhỏ hơn, dễ quản lý, được giao cho các thành viên trong nhóm dựa trên chuyên môn và kinh nghiệm Các doanh nghiệp nhận được một sản phẩm hoạt động được phân phối trong khung thời gian ngắn hơn và có thể hưởng lợi từ tính khả dụng sớm trong khi chức năng mới tiếp tục được phát hành o Phản hồi của người dùng liên tục: Bản chất của RAD là dễ dàng và thường xuyên thu thập phản hồi có liên quan từ những người dùng tương tác trực tiếp với các ứng dụng trong quá trình phát triển và tạo mẫu là vô giá Giao tiếp thường xuyên và phản hồi liên tục làm tăng hiệu quả và chất lượng tổng thể Thiết kế lặp lại và quyền truy cập vào các thành phần UI/UX của một hệ thống đặt phản hồi lên hàng đầu trong quy trình Theo truyền thống, các nhà phát triển làm việc trong các silo không có phản hồi, do đó, việc nhận phản hồi có thể khó khăn, tốn thời gian và chi phí, bao gồm các cuộc họp và cuộc gọi điện thoại kéo dài RAD tăng mức
25 độ hài lòng của khách hàng thông qua cam kết hợp tác và phối hợp ở mức độ cao Khách hàng hợp tác với các nhà phát triển, những người có cơ hội thường xuyên trình bày công việc và tin tưởng rằng họ đang đi đúng hướng để làm hài lòng khách hàng khi sản phẩm cuối cùng được giao
• Nhược điểm o Yêu cầu một đội mạnh về kỹ thuật o RAD phụ thuộc nhiều vào kỹ năng mô hình hóa và yêu cầu kinh nghiệm thích ứng nhanh dựa trên sự phát triển của thành phần Một nhóm mạnh về kỹ thuật là điều cần thiết để xác định và cung cấp đầy đủ các yêu cầu kinh doanh Các nhóm nhỏ hơn có thể kết hợp RAD dễ dàng hơn vì họ có quyền truy cập trực tiếp vào nhau và giao tiếp đơn giản Khi các dự án yêu cầu giao tiếp giữa các nhóm, chu kỳ phát triển luôn chậm Phải mất nhiều thời gian hơn để sắp xếp tất cả các bên liên quan theo các yêu cầu kinh doanh, điều này càng phức tạp hơn do RAD cho phép phát triển liên tục o Yêu cầu tập trung vào giao diện: Khách hàng đánh giá chất lượng của giải pháp dựa trên những gì họ có thể tương tác trong nguyên mẫu RAD yêu cầu lặp lại và tạo nguyên mẫu thường xuyên, đồng thời khách hàng kỳ vọng sẽ đạt được tiến bộ đáng kể với mỗi bản phát hành mới, nhưng nguyên mẫu thường chỉ là vẻ bề ngoài Mặc dù các nhà phát triển được thúc đẩy để tìm ra giải pháp tốt nhất, nhưng đôi khi họ phải từ bỏ phương pháp hay nhất trên phần phụ trợ để tăng tốc độ phát triển trong nguyên mẫu phần đầu Điều này làm phát sinh nợ kỹ thuật, có thể khiến nhiều góc bị cắt giảm khi đến lúc phân phối một ứng dụng đang hoạt động khi các nhóm chạy đua để đáp ứng thời hạn và tránh phải tái cấu
26 trúc o Yêu cầu mức độ cam kết cao từ tất cả các bên liên quan: Với hầu hết các phương pháp phát triển phần mềm truyền thống, như thác nước, khách hàng và nhóm phát triển dành phần lớn thời gian cho nhau Mô hình RAD yêu cầu một chu kỳ nguyên mẫu thường xuyên và do đó, tất cả các bên liên quan phải sẵn sàng và có thể cam kết tham gia các cuộc họp thường xuyên để liên lạc và cung cấp phản hồi thường xuyên o Yêu cầu hệ thống mô-đun và khó khăn cho các dự án quy mô lớn: Các phương pháp phát triển ứng dụng nhanh chóng làm giảm sự kiểm soát và hạn chế, mang lại sự linh hoạt hơn trong quá trình tạo mẫu và phát triển Quản lý đầy đủ tính linh hoạt và biến động trong phạm vi dự án có thể gây ra sự phức tạp cho các ứng dụng lớn hơn Quyền anh thời gian có thể khiến một số tính năng bị trì hoãn để hoàn thành các chu kỳ phát hành ngắn Mỗi thành phần phải là mô-đun để cho phép dễ dàng nhập và tùy chỉnh các thành phần RAD đặc biệt hữu ích cho các hệ thống dựa trên thành phần và có thể mở rộng, nhưng phù hợp với các dự án giàu tính năng hơn đòi hỏi thời gian phát triển lâu hơn.
Phương pháp Spiral
Mô hình xoắn ốc kết hợp ý tưởng phát triển lặp đi lặp lại với các khía cạnh có hệ thống, được kiểm soát của mô hình thác nước Mô hình Xoắn ốc này là sự kết hợp giữa mô hình quy trình phát triển lặp và mô hình phát triển tuyến tính tuần tự tức là mô hình thác nước với sự nhấn mạnh rất cao vào phân tích rủi ro Nó cho phép phát hành sản phẩm gia tăng hoặc sàng lọc gia tăng qua
27 mỗi lần lặp xung quanh hình xoắn ốc
Mô hình xoắn ốc có bốn giai đoạn Một dự án phần mềm lặp đi lặp lại các giai đoạn này trong các lần lặp được gọi là Xoắn ốc
Hình 5 Mô hình soắn ốc
Giai đoạn này bắt đầu với việc thu thập các yêu cầu kinh doanh theo đường xoắn ốc cơ bản Trong các vòng xoắn ốc tiếp theo khi sản phẩm trưởng thành, việc xác định các yêu cầu hệ thống, yêu cầu hệ thống con và yêu cầu đơn vị đều được thực hiện trong giai đoạn này
Giai đoạn này cũng bao gồm việc hiểu các yêu cầu hệ thống bằng cách liên lạc liên tục giữa khách hàng và nhà phân tích hệ thống Khi kết thúc vòng xoáy, sản phẩm được triển khai tại thị trường đã xác định
Giai đoạn Thiết kế bắt đầu với thiết kế khái niệm trong đường xoắn ốc cơ sở và liên quan đến thiết kế kiến trúc, thiết kế logic của các mô- đun, thiết kế sản phẩm vật lý và thiết kế cuối cùng trong các đường xoắn ốc tiếp theo
• Xây dựng hoặc xây dựng
Giai đoạn Xây dựng đề cập đến việc sản xuất sản phẩm phần mềm thực tế ở mọi vòng xoắn ốc Trong vòng xoáy cơ sở, khi sản phẩm mới được nghĩ ra và thiết kế đang được phát triển, POC (Proof of Concept) được phát triển trong giai đoạn này để lấy phản hồi của khách hàng Sau đó, trong các vòng xoắn ốc tiếp theo với độ rõ ràng cao hơn về các yêu cầu và chi tiết thiết kế, một mô hình hoạt động của phần mềm được gọi là bản dựng được tạo ra với một số phiên bản Những bản dựng này được gửi cho khách hàng để lấy ý kiến phản hồi
• Đánh giá và phân tích rủi ro
Phân tích rủi ro bao gồm xác định, ước tính và giám sát tính khả thi về mặt kỹ thuật và rủi ro quản lý, chẳng hạn như trượt lịch trình và vượt chi phí Sau khi thử nghiệm bản dựng, ở cuối lần lặp đầu tiên, khách hàng sẽ đánh giá phần mềm và đưa ra phản hồi
Mô hình Xoắn ốc được sử dụng rộng rãi trong ngành công nghiệp phần mềm vì nó đồng bộ với quy trình phát triển tự nhiên của bất kỳ sản phẩm nào, tức là học hỏi với sự trưởng thành bao gồm rủi ro tối thiểu cho khách hàng cũng như các công ty phát triển
Phương pháp này phù hợp với các phương pháp có nhiều bản dựng và bản phát hành phần mềm cho phép thực hiện quá trình chuyển đổi có trật tự sang hoạt động bảo trì Một khía cạnh tích cực khác của phương pháp này là mô hình xoắn ốc buộc người dùng sớm tham gia vào nỗ lực phát triển hệ thống
Mặt khác, để hoàn thành những sản phẩm như vậy cần phải có sự quản lý rất chặt chẽ và có nguy cơ chạy theo vòng xoáy không xác định Vì vậy, nguyên tắc thay đổi và mức độ chấp nhận các yêu cầu thay đổi là rất quan trọng để phát triển và triển khai sản phẩm thành công
Các gợi ý sau đây giải thích cách sử dụng điển hình của Mô hình Xoắn ốc:
• Khi có hạn chế về ngân sách và việc đánh giá rủi ro là rất quan trọng
• Đối với các dự án có rủi ro từ trung bình đến cao
• Cam kết dự án dài hạn vì những thay đổi tiềm năng đối với các ưu tiên
29 kinh tế khi các yêu cầu thay đổi theo thời gian
• Khách hàng không chắc chắn về các yêu cầu của họ, điều này thường xảy ra
• Các yêu cầu rất phức tạp và cần đánh giá để có được sự rõ ràng
• Dòng sản phẩm mới nên được tung ra theo từng giai đoạn để có đủ phản hồi của khách hàng
• Những thay đổi đáng kể được mong đợi trong sản phẩm trong chu kỳ phát triển
Ưu điểm o Cho phép các yếu tố của sản phẩm được thêm vào khi chúng có sẵn hoặc được biết đến Điều này đảm bảo rằng không có xung đột với các yêu cầu và thiết kế trước đó o Thay đổi yêu cầu có thể được cung cấp o Cho phép sử dụng rộng rãi các nguyên mẫu o Yêu cầu có thể được nắm bắt chính xác hơn o Người dùng thấy hệ thống sớm o Quá trình phát triển có thể được chia thành các phần nhỏ hơn và các phần rủi ro có thể được phát triển sớm hơn giúp quản lý rủi ro tốt hơn
Nhược điểm o Quản lý phức tạp hơn o Kết thúc dự án có thể không được biết sớm o Không thích hợp cho các dự án nhỏ hoặc rủi ro thấp và có thể tốn kém cho các dự án nhỏ o Quy trình phức tạp o Xoắn ốc có thể tiếp tục vô thời hạn o Số lượng lớn các giai đoạn trung gian đòi hỏi quá nhiều tài
TRIỂN KHAI ÁP DỤNG VÀO BÀI TOÁN ĐIỀU PHỐI BỆNH NHÂN
Tìm hiểu bài toán, lựa chọn mô hình
Nhu cầu thực tế của các cơ sở y tế: Một hệ thống với vai trò là công cụ giúp quản lý khách hàng, quản lý thu chi, quản lý công tác khám chữa bệnh, điều phối vật tư và nhân lực và tài chính trong phòng khám Đây là nhu cầu thiết yếu đối với các cơ sở y tế Hệ thống Home & Clinic triển khai trên nền tảng SaaS cung cấp một công cụ hỗ trợ quản lý cơ sở y tế giúp tiết kiệm thời gian, chi phí, nâng cao chất lượng dịch vụ và trải nghiệm khách hàng, giảm thiểu rủi ro trong điều trị để các cơ sở y tế có thể chăm sóc bệnh nhân một cách tốt nhất, tăng lòng tin và sự hài lòng của bệnh nhân đối với cơ sở y tế Đặc biệt, tại các CSYT vừa và nhỏ với lực lượng nhân sự hạn chế, phần mềm càng thể hiện rõ vai trò là 1 trợ lý thiết thực hỗ trợ cho bác sĩ, nhân viên y tế trong công việc Để xây dựng được sản phẩm đáp ứng nhu cầu của thị trường, phù hợp với nguồn lực, khả năng tài chính và mang lại doanh thu tốt đòi hỏi quản trị hệ thống thông tin cần thực hiện khảo sát thị trường, xây dựng Chiến lược sản phẩm
Chiến lược sản phẩm cần chỉ rõ các nội dung sau:
─ Đối tượng khách hàng là gì, phân tích nhu cầu khách hàng
─ Xác định mục tiêu của sản phẩm, mục tiêu về khách hàng
─ Đánh giá thị trường: ngành y tế, cơ chế chính sách liên quan, đánh giá phân tích các đối thủ trên thị trường
─ Dự kiến thị phần, doanh thu
─ Dự kiến chi phí, nguồn lực
─ Lựa chọn mô hình kinh doanh, các kênh bán hàng
─ Xây dựng lộ trình của sản phẩm
Sau khi xây dựng chiến lược sản phẩm, dự án xác định được danh sách tính năng của sản phẩm như sau:
Bước tiếp theo, chúng ta cần xác định mô hình quản lý hệ thống Đối với sản phẩm ứng dụng, đòi hỏi phát triển và đưa ra thị trường nhanh, đáp ứng số lượng khách hàng lớn có thể áp dụng mô hình quản trị dự án Agile Scrum trong giai đoạn đầu Sau khi hình thái sản phẩm ổn định có thể thay đổi và lựa chọn quản trị theo mô hình RAD
Hình 6 Quy trình quản lý Agile
Tính toán chi phí, nguồn lực
Chi phí nhân sự phát triển sản phẩm
Hình 7 Nhân sự phát triển phầm mềm
Chi phí nhân sự hỗ trợ, triển khai sản phẩm
Hình 8 Chi phí nhân sự hỗ trợ, triển khai sản phẩm
Danh sách chi phí hạ tầng
ST T Nội dung chi phí Thông số kỹ thuật
1 Chi phí chỗ đặt thiết bị vật lý
2 Chi phí thuê tài nguyên ảo hóa sử dung nội bộ
Cụm máy chủ vận hành
2 Tài nguyên khởi tạo, triển khai cho một phòng khám
3 Tài nguyên tăng trưởng dữ liệu:
Dữ liệu phát sinh theo số lượt khám/CSYT/tháng (
Bình quân 9000 lượt/CSYT/Tháng)
4 Tài nguyên lưu trữ bản
Backup theo dữ liệu phát sinh
Cụm máy chủ phát triển sản phẩm
11 Chi phí tài nguyên tên miền
12 Chi phí tài nguyên SSL
ST T Nội dung chi phí Thông số kỹ thuật
1 Chi phí chỗ đặt thiết bị vật lý
2 Chi phí thuê tài nguyên ảo hóa sử dung nội bộ
Cụm máy chủ vận hành
2 Tài nguyên khởi tạo, triển khai cho một phòng khám
Tài nguyên lưu trữ các bản Backup ( Server
Tài nguyên lưu trữ các bản Backup ( Server
Bảng 1 Danh sách chi phí hạ tầng
Dự trù chi phí hạ tầng
Hình 9 Dự trì kinh phí hạ tầng
Dự kiến số lượng khách hàng
Hình 10 Dự kiến số lượng khách hàng
Tính toán giá thành sản phẩm
Hình 11 Tính toán giá thành sản phẩm
Phân tích yêu cầu nghiệp vụ
Danh sách các tài liệu đầu ra của quá trình phân tích yêu cầu
1 Tài liệu đặc tả chi tiết yêu cầu người sử dụng (URD)
2 Đặc tả yêu cầu phần mềm (SRS)
Bảng 2 Danh sách các tài liệu đầu ra của quá trình phân tích yêu cầu
URD viết tắt của User Requirement Document, là Tài liệu mô tả yêu cầu người sử dụng và quy trình nghiệp vụ URD được sử dụng trong quá trình triển khai phần mềm ERP nhằm:
Xác định những mong muốn người dùng về một phần mềm, giải pháp công nghệ;
Chứng minh cho các bên quan tâm thấy rằng dự án được kiểm soát tốt và đạt được thành công về tài chính và kỹ thuật;
Cho phép kiểm soát dự án hiệu quả, thực hiện thành công dựa trên các thông số được xác định rõ ràng vể yêu cầu của người dùng
Là cơ sở để nghiệm thu dự án
Không thể phủ nhận vai trò của tài liệu URD trong quá trình mà doanh nghiệp triển khai hệ thống ERP Tài liệu URD được ví như bản vẽ của một ngôi nhà, và hệ thống sẽ được lập trình trên chính bản vẽ đó Do đó, toàn bộ quy trình hoạt động của doanh nghiệp nhất thiết phải được mô tả rõ ràng, đồng thời các chức năng mà phần mềm sẽ cần để đáp ứng tất cả các bên liên quan (khách hàng, người dùng và doanh nghiệp) cũng cần được làm sáng tỏ
Theo đó, bản mô tả URD càng chính xác thì việc chỉnh sửa cấu trúc phần mềm về sau sẽ được hạn chế đến mức tối thiểu nhất Nó cũng cho phép doanh nghiệp triển khai hiệu quả hơn, hạn chế các sai sót gây lãng phí nhân lực, vật
Các thành phần của tài liệu URD
1 Các mục tiêu của dự án
Mô tả các mục tiêu mà dự án cần đạt được
2 Mô tả chức năng và yêu cầu về hiệu suất
– Mô tả rõ nét các chức năng, phân hệ cần triển khai cho phần mềm Nó bao gồm các nghiệp vụ lõi và các nghiệp vụ mở rộng của doanh nghiệp nhằm đảm bảo yêu cầu kinh doanh tại từng đơn vị
– Tổ chức hệ thống bao gồm các phân quyền trên phần mềm Tùy theo từng đơn vị sẽ có những tổ chức khác nhau Song, cần mô tả chi tiết để đảm bảo công việc xây dựng phần mềm sau này
3 Nguồn lực và yêu cầu về lịch trình
Chỉ định các tài nguyên tối đa mà việc phát triển và vận hành hệ thống có thể tiêu tốn, cũng như số lượng nhân sự tham gia, thời gian tối đa triển khai hay ngân sách phát triển và các ràng buộc khác
4 Yêu cầu dữ liệu Đây là phần thiết lập các yêu cầu về xử lý và lưu trữ dữ liệu hệ thống Các chi tiết như loại dữ liệu được nhập, khối lượng dữ liệu, nguồn thu thập sẽ được minh họa rõ nét và minh bạch
5 Yêu cầu về giao diện
Phần này chỉ định các giao diện cho hệ thống Ở cấp độ URD, giao diện bao gồm hệ thống hiển thị tổng thể phải xử lý, gồm các thiết bị đầu cuối của người dùng và giao diện điện tử với các hệ thống máy tính khác
Phần này quy định các yêu cầu đặt ra đối với thử nghiệm hệ thống, bao gồm thông tin về khả năng truy nguyên các thử nghiệm trở lại các yêu cầu Cũng bao gồm các yêu cầu về thử nghiệm trong điều kiện ứng suất (tải tối đa, hoặc thậm chí tải vượt quá mức tối đa, như được định nghĩa trong các phần trước của tài liệu này) và thử nghiệm hồi quy
Việc kiểm tra này nhằm đảm bảo rằng không có tác động bất ngờ nào khi đưa phần mềm vào sử dụng
Bảng 3 Các thành phần của tài liệu URD
Tài liệu SRS là từ viết tắt của Software Requirement Specification, được dịch ra tiếng việt là tài liệu đặc tả yêu cầu SRS là tài liệu được sử dụng để mô tả chi tiết các yêu cầu chức năng và phi chức năng của hệ thống Tài liệu này sẽ hỗ trợ đưa ra các tính năng của hệ thống hay dùng cho việc đọc hiểu hệ thống của bên thứ ba liên quan đến công ty Đây là một tài liệu quan trọng cho đội phát triển (system analyst, business analyst, code) và kiểm thử (tester) Nội dung của SRS là mô tả các chức năng và cấu trúc của hệ thống là FR và NFR Tài liệu đặc tả yêu cầu SRS còn đóng vai trò là cầu nối liên kết giữa người dùng và nhà sáng tạo và từ đó hệ thống có thể đáp ứng được đúng mục đích và yêu cầu của người sử dụng.Ngoài ra, dựa vào các yêu cầu mà SRS thống kê, ta có thể đánh giá được số lượng scope, thời gian hoàn thành hay những chi phí cần đáp ứng giúp hoàn thành sản phẩm một cách nhanh chóng và dễ dàng hơn
SRS là tài liệu đặc tả vô cùng quan trọng trong quá trình phát triển phần mềm, nó có vai trò:
Giúp cho các bên thứ ba - stakeholders đều hiểu được hệ thống theo cùng một hướng, tránh trường hợp mỗi người một ý
Giúp cho đội phát triển xây dựng hệ thống một cách chính xác, đặc tả được các tính năng, không đi lạc hướng so với yêu cầu của khách hàng
SRS giúp nhà kiểm thử hệ thống đọc hiểu từ đó xây dựng nên kịch bản kiểm thử chi tiết nhất
Giúp cho việc bảo trì hệ thống và cải tiến những chức năng của hệ thống một cách nhanh chóng và dễ dàng
Thành phần chính của tài liệu đặc tả yêu cầu SRS
Phần này bao gồm các nội dung:
Purpose: mô tả chi tiết về mục đích và ý nghĩa của tài liệu đặc tả yêu cầu, giúp người đọc hiểu được khái niệm và tầm quan trọng của nó
Application Overview: mô tả hệ thống một cách tổng quan Nhìn chung, hệ thống phải đảm bảo dduocj các yếu tố như khái quát hệ thống, tính năng, quyền sử dụng, mục đích của hệ thống sinh ra để làm gì,
Intended Audience and Reading Suggestions: mô tả các đối tượng sở hữu tài liệu SRS và mục đích sử dụng
Abbreviations: danh sách các từ viết tắt và ý nghĩa giúp người đọc nắm rõ hơn
References: mục đính kèm mô tả các tài liệu liên quan
Yêu cầu mức tổng thể (High Level Requirement)
Những thông tin chi tiết trong phần này gồm có:
Object Relationship Diagram: mô hình thể hiện mối quan hệ tĩnh giữa các đối tượng của hệ thống Một đối tượng được xem là một thực thể trong hệ thống
Workflow Diagram: là phần đảm nhiệm hiển thị chuỗi công việc hoặc các bước người dùng thực hiện Mỗi hành động của người dùng hệ thống sẽ được hiển thị ở từng giai đoạn của hệ thống
Thiết kế, phát triển hệ thống
Lựa chọn Mô hình kiến trúc
Hình 16 Mô hình kiến trúc
API gateway: Netflix Eureka, Ribbon, Zuul
Proxy và cân bằng tải: Ingress(K8s), F5 (Hardware)
Loging & Tracing: ElasticSearch Fluent Kibana
Các tài liệu cần xâu dựng để thiết kế tổng thể và thiết kế chi tiết:
Tài liệu thiết kế tổng thể (SAD)
Tài liệu thiết kế chi tiết (LLD)
Giao diện của dự án được đội ngũ thiết kế dựa trên tài liệu SRS và sử dụng công cụ Figma Đối với các dự án áp dụng quy trình Scrums, việc tạo ra các Prototype để cung cấp cho khách hàng là vô cùng quan trọng prototype của một giao diện được dùng để thực hiện các thử nghiệm với người dùng trước khi chúng ta chuyển bản thiết kế thành code, tạo ra sản phẩm được sử dụng chính thức Prototype của giao diện sẽ thể hiện các giải pháp mà chúng ta giả định rằng có thể giải quyết các vấn đề cụ thể của người dùng Và để biết được giải pháp đó có phù hợp hay không thì cách đơn giản nhất là chúng ta sẽ quan sát hành động và phản ứng của người dùng khi tương tác, trải nghiệm với prototype đó Khi làm prototype chúng ta sẽ cố gắng mô phỏng sao cho giao diện của prototype mang lại cảm nhận gần giống nhất có thể với sản phẩm hoàn chỉnh đã được code trong khi bản beta là bản đầy đủ chức năng và tính năng của một sản phẩm (có code front-end và back-end)
Một số hình ảnh thiết kế giao diện sản phẩm trên Figma
Bảng 4 Một số hình ảnh thiết kế giao diện sản phẩm trên Figma
Mô hình CSDL quan hệ
Danh sách bảng và mô tả tóm tắt
- Schema : KHAMCHUABENH benh_nhan Thông tin bệnh nhân dan_toc Danh mục dân tộc của bệnh nhân nghe_nghiep Danh mục nghề nghiệp của bệnh nhân tinh_thanh_pho Danh mục các tỉnh, thành phố trực thuộc trung ương quan_huyen Danh mục các quận, huyện, thành phố trực thuộc tỉnh phuong_xa Danh mục các phường, xã, thị trấn don_vi Danh mục các y tế cơ sở thong_tin_khoa Thông tin khoa điều trị của bệnh nhân phong Danh mục các phòng của y tế cơ sở nhan_vien Thông tin nhân viên của y tế cơ sở benh_an_kham_benh Thông tin bệnh án của bệnh nhân dot_dieu_tri Thông tin đợt điều trị của bệnh nhân
52 huong_dieu_tri Danh mục các hướng điều trị và giải quyết cho lần khám bệnh của bệnh nhân thong_tin_kham_benh Thông tin khám bệnh của bệnh nhân loai_benh_ly Danh mục loại bệnh lý nhom_benh_ly Danh mục nhóm bệnh lý benh_ly Danh mục bệnh lý benh_yhct Danh mục bệnh y học cổ truyền chan_doan_hinh_anh Danh mục các dịch vụ CĐHA của y tế cơ sở chan_doan_hinh_anh_ap_dung Danh mục các dịch vụ CĐHA đang được sử dụng của y tế cơ sở, bao gồm các dịch vụ BHYT và các dịch vụ của y tế cơ sở chi_dinh_chan_doan_hinh_anh Thông tin dịch vụ CĐHA được chỉ định cho bệnh nhân chi_dinh_dvk Thông tin dịch vụ khám được chỉ định cho bệnh nhân chi_dinh_thu_thuat_phau_thuat Thông tin dịch vụ TTPT được chỉ định cho bệnh nhân chi_dinh_xet_nghiem Thông tin dịch vụ xét nghiệm được chỉ định cho bệnh nhân xet_nghiem _ap_dung Danh mục các dịch vụ xét nghiệm đang được sử dụng của y tế cơ sở, bao gồm các dịch vụ BHYT và các dịch vụ của y tế cơ sở
-Schema: BSGD_VIENPHI bangke Bảng kê chi phí khám chữa bệnh của bệnh nhân kcb_dichvuchidinh Các dịch vụ khám, thuốc, vật tư, cận lâm sàng, v.v đã được chỉ định cho bệnh nhân kcb_dulieubenhnhan Thông tin hành chính, đợt điều trị, bhyt, v.v của bệnh nhân transaction_log Ghi log khi giao tiếp với các services khác vienphi_chitietlantt Chi tiết các dịch vụ đã thanh toán vienphi_lantt Thông tin về lần thanh toán
53 vienphi_lantamung Thông tin về lần tạm ứng vienphi_quyenbienlai Danh mục các quyển biên lai viện phí
-Schema: HIS_DUOCV2 dc_tb_loai_vattu Danh mục loại vật tư dc_tb_nhomvattu Danh mục nhóm vật tư nhapkhotunhacc_nvkiemnhap Thông tin nhân viên kiểm nhập phiếu nhập kho dc_tb_nhapkhotunhacc_chitiet Chi tiết nhập kho từ nhà cung cấp dc_tb_nhapkhotunhacc_hd_chitiet Chi tiết hóa đơn nhập kho từ nhà cung cấp dc_tb_chuyenkhovattu Thông tin chuyển kho vật tư dc_tb_chuyenkhovattu_chitiet Chi tiết chuyển kho vật tư dc_tb_duyet_chuyen_kho Thông tin duyệt phiếu chuyển kho baocao_xuatnhapton_ct Thông tin chi tiết xuất nhập tồn baocao_xnt_dauky Thông tin xuất nhập tồn đầu kỳ
Bảng 5 Danh sách bảng và mô tả tóm tắt
Hệ thống được phát triển trên mô hình Microservice
Microservice được biết đến là một mô hình kiến trúc, phân chia dự án phần mềm thành nhiều service (dịch vụ) nhỏ tồn tại độc lập Điều này đồng nghĩa với việc mọi hoạt động xử lý, lưu trữ và yêu cầu dữ liệu đều riêng biệt
Mô hình này mang lại cho hệ thống các đặc tính như:
Hoạt động độc lập, linh hoạt, có tính chuyên biệt cao: Do không bị ràng buộc bởi những yêu cầu chung, nên mỗi service nhỏ có thể tự do lựa chọn công nghệ, nền tảng phù hợp
Nâng cao khả năng xử lý lỗi: Với mô hình này, một service bất kỳ nào gặp lỗi sẽ không gây ra ảnh hưởng đối với những bộ phận còn lại Việc khắc phục lỗi trên quy mô hẹp cũng sẽ được tiến hành một cách dễ dàng
Thuận tiện trong nâng cấp, mở rộng: Tương tự như trường hợp xử lý lỗi, việc nâng cấp, bảo trì service hoàn toàn độc lập sẽ không làm gián đoạn quá trình vận hành của cả phần mềm Nhờ vậy, những phiên bản mới có thể được cập nhật thường xuyên Đơn giản hóa trong quản lý và kiểm thử: Với từng service nhỏ, các bước quản lý, tính toán và kiểm soát, xử lý lỗi sẽ trở nên đơn giản và nhanh chóng hơn so với cả phần mềm
Tuy nhiên, nó cũng đối mặt với các vấn đề như việc liên tục di chuyển qua các database khác nhau sẽ khiến dữ liệu bị đảo lộn, không còn nguyên vẹn, thậm chí phải đối mặt với nguy cơ an ninh, bị đánh cắp Cùng với đó, nó đòi
55 hỏi lập trình viên cần đảm bảo một số yếu tố chính như sau:
Xây dựng hệ cơ sở dữ liệu (database) độc lập
Xác định kích thước service phù hợp
Đề ra vai trò, chức năng cụ thể, riêng biệt cho từng service
Khi áp dụng mô hình này, đội ngũ lập trình viên cần chia rõ các công việc
─ Dựng Services, chia các database riêng biệt
Việc quản lý mã nguồn và phiên bản của sản phẩm được sử dụng trên công cụ GitHub GitHub là một hệ thống quản lý dự án và phiên bản code, hoạt động giống như một mạng xã hội cho lập trình viên Các lập trình viên có thể clone lại mã nguồn từ một repository và Github chính là một dịch vụ máy chủ repository công cộng, mỗi người có thể tạo tài khoản trên đó để tạo ra các kho chứa của riêng mình để có thể làm việc
GitHub là một dịch vụ nổi tiếng cung cấp kho lưu trữ mã nguồn Git cho các dự án phần mềm Github có đầy đủ những tính năng của Git, ngoài ra nó còn bổ sung những tính năng về social để các developer tương tác với nhau
Vài thông tin về GIT:
Là công cụ giúp quản lý source code tổ chức theo dạng dữ liệu phân tán Giúp đồng bộ source code của team lên 1 server
Hỗ trợ các thao tác kiểm tra source code trong quá trình làm việc (diff, check modifications, show history, merge source, …)
GitHub có 2 phiên bản: miễn phí và trả phí Với phiên bản có phí thường được các doanh nghiệp sử dụng để tăng khả năng quản lý team cũng như phân quyền bảo mật dự án Phần lớn chúng ta đều sử dụng Github với tài khoản miễn phí để lưu trữ source code
Github cung cấp các tính năng social networking như feeds, followers, và network graph để các developer học hỏi kinh nghiệm của nhau thông qua lịch sử commit
Các tính năng cốt lõi như:
Wiki, issue, thống kê, đổi tên project, project được đặt vào namespace là user
Watch project: theo dõi hoạt động của project của người khác Xem quá trình người ta phát triển phầm mềm thế nào, project phát triển ra sao
Follow user: theo dõi hoạt động của người khác
Có 2 cách tiếp cận GitHub: Tạo project của riêng mình Contribute cho project có sẵn: fork project có sẵn của người khác, sửa đổi, sau đó đề nghị họ cập nhật sửa đổi của mình (tạo pull request)
Bảng 6 Dự án thực tế quản lý với GitHub
Kiểm thử
Khi code hoàn tất, quá trình kiểm tra bắt đầu và các mô-đun được đánh giá và kiểm tra để tránh bất kỳ lỗi nào Phần mềm đã xây dựng được xem xét toàn diện trong quá trình này và bất kỳ vấn đề nào được tìm thấy đều được giao cho các developers sửa chữa, thay đổi
Kiểm tra lại và kiểm tra hồi quy được tiến hành cho đến khi phần mềm đúng
59 như kế hoạch của người sử dụng Tester thường tham khảo tài liệu SRS để đảm bảo phần mềm phù hợp với tiêu chuẩn của khách hàng hay yêu cầu
Kết quả của giai đoạn kiểm thử:
Sản phẩm hoàn thiện hơn sau các lỗi được chỉnh sửa hoặc các yêu cầu còn thiếu được phát triển
Triển khai, bảo trì
Mô hình vòng đời phát hành phần mềm được thể hiện qua hình sau:
Hình 18 Vòng đời phát triển của phần mềm
Quá trình triển khai phần mềm thường được bắt đầu từ khi bản Beta được phát hành Đây là phiên bản với đầy đủ code frontend, backend và có thể hoạt động thông suốt được đầy đủ quy trình cơ bản của khách hàng Đối với bản Beta, dự án cần tìm kiếm các đối tượng khách hàng đồng hành để POC (dùng thử) sản phẩm để phát hiện lỗi và hoàn chỉnh chức năng
Sau khi POC hoàn thành sẽ phát hành bản Release Candidate, tại phiên bản này đã có tương đối đầy đủ các tính năng, tài liệu sản phẩm Dự án thực hiện tìm kiếm các khách hàng sử dụng chính thức cho phiên bản này
Sau khi thực hiện trải nghiệm trên 1 số lượng khách hàng nhất định, dự án đưa ra bản Release to manufacturing Đây được coi là bản phát hành chính thức, công bố hoàn thiện sản phẩm và hoàn thiện các quy trình GTM cho sản phẩm đó Phiên bản này sẽ được đưa vào thương mại hoá và mở rộng thị trường
LIÊN HỆ DỰ ÁN CÁ NHÂN
Quy trình
Dự án tự e-commerce tìm hiểu về quy trình bán hàng trực tuyến trên hệ thống nhật bản, yêu cầu những trình tự, bảo mật khác biệt so với trong nước, phù hợp với đối tượng sử dụng
•Sử dụng template sheet API, BD mới nhất
•Lưu ý sử dụng sheet API khi create API document để tránh lack sheet
•BAL: flie review, file pattern test, sheet FUT create base on requirement
•BA: API docs, sheetAPI, ticket review
•Hiểu rõ output issues confirm ý hiểu
•Đưa ra nhận định phán đoán và confirm phương pháp đối ứng
•Tạo checklist để tránh lack quan điểm
•BAL: coding file review, create merge request
•BA: create file source code review, merge source code
•Sử dụng file FUT teamplate & checklist mới nhất
•Phải tạo checklist trong quá trình create FUT để tránh lack quan điểm
•BAL: coding file review, create merge request
•BA: create file source code review, merge source code
Trong phase này, khách hàng sẽ cung cấp các tài liệu:
Clickup: Tập hợp các hình ảnh mô tả các màn hình sẽ phát triển cùng mô tả chi tiết nghiệp vụ cho từng item được thay đổi trong lần phát triển này
Knowledge: Đây là tài liệu mô tả tổng quan nghiệp vụ sẽ phát triển theo dạng overview cho từng Sprint, bao gồm hiện trạng sử dụng, mục tiêu hướng đến…
Tiếp theo đó, dựa vào các tài liệu được cung cấp, team leader sẽ tổng hợp nên các file thông tin để tập trung vào phạm vi cần chỉnh sửa rồi phổ biến lại cho team phát triển Nếu có thông tin nào chưa nắm rõ hoặc nhận thấy chưa hợp tý, TL (BAL) sẽ tạo thành các Q&A để gửi cho khách hàng nhằm làm rõ và hiểu nhất về nghiệp vụ
4.1.2 BE, FE Đây là phase phát triển chính của dự án, bao gồm phát triển phần Backend và Frontend cho các Sprint được khách hàng gửi sang Phase này dựa trên chính các tài liệu được tạo ra từ các phase trên Trong phase này, vẫn có thể phát sinh các vấn đề mà các phase trước đó chưa cover được, TL vẫn có thể tạo ra các Q&A và gửi sang khách hàng nhằm confirm để nghiệp vụ được chuẩn xác nhất
Sau khi họp planning cho sprint, team sẽ nhận task từ phía khách hàng, sau khi được tranfer bug, tính năng, các quan điểm cần đối ứng,… member bắt bắt đầu nghiên cứu, estimate thời gian hoàn thành công việc báo cáo lại khách hàng Khi đã thống nhát quan điểm, cách đối ứng và thời gian đối ứng thì bắt đầu coding
Trong quá trình coding phát hiện QA cần nhanh chóng phán định và báo cáo lại với khách hàng để chỉnh sửa estimae time và cách đối ứng mới
Sau khi coding, tự giác self-review, review chéo tránh trường hợp gặp degrate
Trong phase này, member sẽ viết các FUT testcases hoặc nhận testcases từ khách hàng rồi thực hiện test trên các quan điểm đó, các tính năng mà mình đã phát triển, có thể viết test chéo để đảm bảo khả năng khách quan
Việc đảm bảo tính đúng và phù hợp đầy đủ hết sức quan trọng, nó góp phần giúp giảm thiểu tối đa việc lack bug, giúp cho phần mềm đạt hiệu quả tốt Ngoài ra, có thể thực hiện free-test, thực hiện những kịch bản mới chưa có sẵn để kiểm tra hệ thống.
Theo dõi, vận hành và quản lý tại redmine
Dự án quản lý tất cả task bằng redmine, bao gồm tất cả các thông tin về dự án: Q&A, review request, bug, …
Hình 20 Quản trị dự án với redmine
Mỗi vấn đề đều được tạo dưới dạng task, issues, defect,…rên redmine dùng để thống kê, trao đổi thông tin, lưu trữ thông tin các vấn đề Trong mỗi task sẽ cần log theo đúng chuẩn dự án đã đặt ra, bao gồm tiêu đề, tiến độ,…
Dựa vào các thông tin được log trên redmine, người được assign sẽ cần thực hiện tuân thủ theo đúng các rule của dự án, chẳng hạn như phải thực hiện trước duedate, note lại các vấn đề vào task nếu không thực hiện được hoặc có vấn đề phát sinh dẫn đến làm chậm duedate
Quản lý mã nguồn với Gitlab
Để quản trị mã nguồn, khách hàng cung cấp cho dự án 1 repository Gitlab, toàn bộ mã nguồn dự án sẽ được quản lý tại đây
Hình 21 Quản lý mã nguồn với Gitlab
Khi có 1 tính năng được phát triển xong, member sẽ tiến hành commit và push code lên trên Gitlab repository Sau đó tiến hành tạo 1 task review source trên redmine và assign đến team lead của mình để yêu cầu thực hiện review source code TL sẽ review và comment code (nếu cần), sau đó tiến hành merge source vào các branch để thực hiện FUT
Ngoài ra, với các bug phát sinh trong quá trình test, cũng cần tạo ra các branch fix bug trên Gitlab và tạo ra các merge request để lưu trữ lịch sử fix bug