12.4.4.1 Kiểm thử:
Kiểm thử là một quá trình quan trọng, cần nhiều thời gian và đắt đỏ. Một kế
hoạch kiểm thử là một bản mơ tả chính thức chi tiết về các phản hồi của hệ thống đối
với các trường hợp sử dụng và lạm dụng. Trong quá trình này, các nhà phát triển xây dựng từng thành phần độc lập của hệ thống.
Cấp phép và cài đặt các chương trình có sẵn và sẽ thích ứng, tùy chỉnh các chương trình nếu cần thiết.
Tìm kiếm tài liệu, duyệt và kiểm tra các thủ tục và xây dựng các chương trình đào tạo.
Cuối cùng tổ chức sẽ thuê và đào tạo các nhân sự cần thiết.
Khi các thành phần đã được kiểm tra một cách độc lập, toàn bộ hệ thống sẽ được kiểm thử và tất cả sẽ được chuyển đổi sang hệ thống mới.
12.4.4.2 Sự chuyển đổi hệ thống:
Khi hệ thống đã vượt qua được quá trình thử nghiệm, tổ chức sẽ lắp đặt hệ thống mới này. Thuật ngữ “sự chuyển đổi hệ thống” thường được sử dụng nhằm ngụ ý rằng quá trình chuyển đổi quy trình kinh doanh từ hệ thống cũ sang hệ thống mới. Lưu ý rằng sự chuyển đổi chỉ dùng cho hệ thống mới hoặc trong một số trường hợp, bao gồm cả quy trình kinh doanh mới. Có 4 loại quy trình chuyển đổi là: Thí điểm, theo
từng giai đoạn, song song và “liều lĩnh”. 3 lựa chọn đầu thường được các công ty áp
dụng. Các công ty sẽ tránh sự liều lĩnh ở lựa chọn 4.
+ Về lắp đặt thí điểm: tổ chức sẽ thi hành tồn bộ hệ thống/quy trình kinh doanh
mới ở một một phịng ban nhất định. Ưu điểm của hình thức này là nếu hệ thống gặp thất bại, hậu quả sẽ chỉ giới hạn ở một số phần mà hệ thống được lắp đặt.
+ Lắp đặt từng giai đoạn: tồn bộ hệ thống/quy trình kinh doanh mới sẽ được lắp
đặt theo từng quy trình. Khi một thành phần hoạt động tốt, tổ chức sẽ lắp đặt và kiểm thử các thành phần khác cho đến khi toàn bộ hệ thống được lắp đặt. Với những hệ thống được tích hợp chặt chẽ, cần được lắp đặt với các công nghệ khác.
+ Lắp đặt song song, tồn bộ hệ thống/quy trình kinh doanh mới sẽ hoạt động
song song với các hệ thống/quy trình kinh doanh cũ cho đến khi tồn bộ hệ thống đã được thử nghiệm và vận hành hoàn toàn. Lắp đặt song song tốn rất nhiều chi phí, do vậy ta cần phải làm việc đáng kẻ để điều hòa hoạt động của hệ thống mới và hệ thống cũ.
+ Cuối cùng là lắp đặt “liều lĩnh” (Hay còn gọi là lắp đặt trực tiếp). Với phương án này, tổ chức ngưng hoạt động các hệ thống cũ và chuyển đổi sang hệ thống mới. Nếu hệ thống mới thất bại, tồn bộ cơng việc sẽ bị ngưng trệ. Do đó, tổ chức nên tránh chuyển đổi bằng phương án này. Có một ngoại lệ là hệ thống mới không làm gián đoạn hoạt động của tổ chức nếu nó khơng thành cơng.
Sau đây là bảng tóm tắt hoạt động thiết kế và thi hành 5 thành phần của hệ thống:
Thi hành
Bảng 12.2 - Hoạt động Thiết kế và Thi hành 5 thành phần của hệ thống (Giáo trình – Figure 12-14)
Bảo trì trong hệ thống thơng tin không phải là sửa chữa hệ thống hay điều chỉnh
hệ thống thay đổi theo yêu cầu. Bảng trên cho ta thấy các nhiệm vụ trong giai đoạn bảo trì này:
Đầu tiên, cần phải có một phương tiện để theo dõi cả lỗi và cải tiến để đáp ứng các yêu cầu. Với các hệ thống nhỏ, tổ chức sẽ sử dụng hệ thống xử lý văn bản để theo dõi các lỗi và nhu cầu cải tiến. Tuy nhiên nếu hệ thống trở nên lớn hơn, các lỗi và yêu cầu cải tiến cũng tăng lên, nhiều tổ chức thấy cần thiết để xây dựng một cơ sở dữ liệu để theo dõi các yêu cầu này. Cơ sở dữ liệu này còn ghi lại người báo cáo sự cố, người sẽ sửa chữa sự cố hay cải tiến, tình trạng cơng việc đó và liệu bản sửa lỗi hoặc cải tiễn đã được kiểm tra và xác minh bởi người khởi tạo hay chưa.
Thông thường, các nhân sự hệ thống thông tin sẽ sắp xếp mức độ ưu tiên của vấn đề theo tính nghiêm trọng của nó. Họ sẽ sữa chữa các vấn đề ưu tiên càng sớm càng tốt và họ sẽ sửa chữa các vấn đề ít nghiêm trọng hơn khi thời gian và nguồn lực cho phép.
Bởi vì sự cải tiến là sự thích ứng với các yêu cầu mới, nhà phát triển thường ưu tiên các yêu cầu cải tiến hơn và tách bạch với sửa chữa các lỗi. Quyết định cải tiến bao gồm các quyết định kinh doanh rằng liệu tỷ suất lợi nhuận sinh ra có chấp thuận được hay khơng.
Ví dụ về các giai đoạn trong SDLC
Case study lần này liên quan đến việc lựa chọn một gói phần mềm của một bệnh viện khu vực có quy mơ vừa (bệnh viện General Hospital) để sử dụng trong phân khúc Home Health. General sở hữu một Trung tâm chẩn đốn chỉnh hình, một bệnh viện phục hồi chức năng, bốn phịng khám chăm sóc ban đầu, một trung tâm sức khỏe và thể hình (một trong những trung tâm lớn nhất cả nước với hơn 70.000 mét vuông và 7.000 thành viên), một trung tâm phục hồi vết thương, khu Trung tâm Trị liệu và Chăm sóc Tại nhà – Home Health (tâm điểm của nghiên cứu này). Bên cạnh đó, Có hơn 120 bác sĩ trong đội ngũ nhân viên y tế đang hoạt động, hơn 1.400 nhân viên và hơn 100 tình nguyện viên (“General Hospital”, 2010).
Chăm sóc sức khỏe tại nhà (Home Health), là việc chăm sóc sức khỏe được thực hiện tại nhà. Thay vì phải đi đến bệnh viện, bệnh nhân tự đo huyết áp (hoặc nhịp tim, mức đường huyết, v.v.) bằng một thiết bị được nối gần giường của họ ở nhà. Kết quả được truyền đến bệnh viện (hoặc trong trường hợp này là Cơ sở Y tế Tại nhà gần General Hospital) theo phương thức điện tử và ngay lập tức được xử lý, kiểm tra và giám sát bởi nhân viên trực tiếp.
Ngồi ra, có một tính năng Lifeline có sẵn cho người cao tuổi hoặc những người ở nhà khác. Thiết bị này bao gồm một nút đeo trên vòng cổ hoặc vòng tay mà bệnh nhân có
thể ấn vào nếu họ cần hỗ trợ (“Home Health”, 2010). Định kỳ, bác sĩ lâm sàng (ví dụ: y tá, nhà vật lý trị liệu, v.v.) sẽ đến thăm bệnh nhân tại nhà của họ để theo dõi tiến trình của họ và thực hiện kiểm tra và bảo trì định kỳ đối với cơng nghệ.
Giờ đây, ban giám đốc bệnh viện cần một phần mềm để tạo điều kiện và giúp điều phối bộ phận Home Health tại nhà trong công việc kinh doanh của họ.
Xác định hệ thống
Thứ nhất, bộ phận Home Health của General Hospital đã được tổ chức lại thành một đơn vị trực thuộc riêng biệt nằm gần bệnh viện chính (có cơ sở độc lập).
Thứ hai, các phần mềm họ đang sử dụng đã có tuổi đời ít nhất là bảy năm và chỉ đơn giản là không thể theo kịp tất cả những thay đổi trong thực tiễn lập hóa đơn cũng như các yêu cầu và thanh tốn của Medicare. Do đó, ngồi các tiêu chí mong muốn cụ thể của phần mềm (được mơ tả trong phần sau), có 2 mục đích rõ ràng: 1) Hiện đại hóa hoạt động của họ với cơng nghệ hiện tại; và 2) Cung cấp dịch vụ chăm sóc bệnh nhân tốt nhất hiện có cho khách hàng của họ trong lĩnh vực Home Health.
Đánh giá mức độ khả thi:
Tính khả thi về cơng nghệ: Chúng ta có các nguồn lực và cơ sở hạ tầng cần thiết để hỗ trợ phần mềm nếu nó được mua lại khơng? => Cơ sở hạ tầng CNTT của General đã quá đầy đủ và cập nhật liên quan đến việc hỗ trợ phần mềm mới
Tính khả thi về chi phí: Chúng ta có đủ nguồn tài chính để trả cho nó, bao gồm cả hỗ trợ và bảo trì khơng? => Giám đốc cơng nghệ thơng tin Sẵn sàng chi 250000 USD Tính khả thi về hoạt động, tổ chức: Chúng ta có các cá nhân được đào tạo thích hợp để có thể vận hành và sử dụng phần mềm không? => Nhân viên hỗ trợ và người dùng cuối tiềm năng đã được đào tạo bài bản và nhiệt tình về việc áp dụng cơng nghệ mới
Phân tích yêu cầu:
Một trong những yêu cầu quan trọng nhất là tương thích với MEDITECH, kế đến là OASIS Analyzer và một số điều “Phải có” khác của phần mềm mới: Các mơ-đun lập hóa đơn và tài khoản phải thu đặc biệt được điều chỉnh cho phù hợp với Home Health;
cổng thơng tin bác sĩ; tối ưu hóa lịch trình; và cuối cùng khơng kém phần quan trọng, hệ thống phải thân thiện với người dùng.
Một số hạng mục khác cần quan tâm trong giai đoạn này là:
Có các mơ-đun khác có sẵn khơng (ví dụ: tài chính, y tế, bệnh viện tế bần; các ứng dụng để đồng bộ hóa hệ thống với PDA (Trợ lý kỹ thuật số cá nhân) hoặc điện thoại thơng minh)?
Có một bản trình diễn web có sẵn để xem trực tuyến; hoặc tốt hơn nữa là có cơ hội tham gia trình diễn trực tiếp phần mềm trong điều kiện thực tế hoặc mô phỏng không? Cuối cùng, là đánh giá từng nhà cung cấp như một người vào vịng chung kết tiềm năng. Ví dụ: Nhà cung cấp A có Nhóm triển khai / Cài đặt để hỗ trợ giai đoạn triển khai phần mềm. Nhà cung cấp C đã tài trợ một Hội nghị người dùng hàng năm, nơi người dùng có thể chia sẻ kinh nghiệm sử dụng sản phẩm, cũng như cung cấp phản hồi để đưa vào các bản phát hành trong tương lai. Để đạt được điều đó, Nhà cung cấp C cũng có đại diện người dùng trong Ban cố vấn sản phẩm của họ. Nhà cung cấp E đưa ra lựa chọn "điện toán đám mây", trong đó sản phẩm được lưu trữ trong trung tâm dữ liệu của họ. (Người mua tiềm năng không cần phải chọn giải pháp hỗ trợ web). Sản phẩm của nhà cung cấp E là một phần của giải pháp doanh nghiệp và có thể được đồng bộ hóa với PDA hoặc điện thoại thơng minh.
Thiết kế
Như đã lưu ý trước đây, đối với nghiên cứu điển hình cụ thể về lựa chọn phần mềm này, các nhà nghiên cứu không phải tiến hành từng bước của SDLC vì các sản phẩm phần mềm đã tồn tại, giai đoạn Thiết kế của SDLC đã được thực hiện bởi các nhà cung cấp. Do đó, sau khi cẩn thận phân tích tất cả các sản phẩm, tính năng, ưu và nhược điểm cũng như chi phí và lợi ích liên quan đến từng sản phẩm, giờ đây việc cần làm là đưa ra lựa chọn: phân tích danh sách năm nhà cung cấp tiềm năng thành hai nhà cung cấp có thể đáp ứng các nhu cầu được đưa và cho thấy sự quan tâm nhiều nhất.
Ban lãnh đạo điều tra đã sắp xếp một cuộc họp khác với các bên liên quan chính của bộ phận Home Health của General. Vì họ là những người sẽ sử dụng hệ thống trong tương lai gần, việc lựa chọn chỉ có ý nghĩa khi họ tham gia trong tồn bộ quá trình. Sau khi xem xét cẩn thận, quyết định được đưa ra đó là sẽ mời Nhà cung cấp B đến thăm địa điểm và buổi mô phỏng.
Nhà cung cấp B rất chuyên nghiệp, lịch sự, nhanh chóng và tận tâm trong chuyến thăm của họ. Một lợi thế rất lớn là mơ hình kinh doanh chính của họ tập trung vào phần mềm Home Health. Ngược lại, một nhà cung cấp khác (khơng có trong danh sách 5 người ban đầu của chúng tơi) đã đến và trình bày rất bóng bẩy, theo lời của Giám đốc. Tuy nhiên, cơng ty này có rất nhiều mối quan tâm hàng tỷ đơ, trong đó phần mềm Home Health chỉ là một phần nhỏ. Do đó, lựa chọn đã được thực hiện với Nhà cung cấp B.
Không may, sản phẩm của nhà cung cấp B khơng tương thích với Meditech, đây là một trong những tiêu chí quan trọng nhất để lựa chọn. Tuy nhiên, thông qua việc sử dụng một cơng ty phần mềm trung gian có kinh nghiệm đáng kể trong việc thiết kế giao diện để sử dụng trong môi trường Meditech, vấn đề đã được giải quyết và một giải pháp tùy chỉnh đã được phát triển và đưa vào sử dụng. Nhà cung cấp phần mềm trung gian đã kinh doanh với General trước đây và do đó, họ đã quen với nhu cầu của họ.
Thi hành
Bộ phận Home Health của General đã tiến hành Lắp đặt song song trong khoảng 60 ngày trước ngày “hoạt động”. Các bác sĩ lâm sàng sẽ “nhập hai lần” hồ sơ bệnh nhân và dữ liệu nhập viện vào cả hệ thống cũ và hệ thống mới để đảm bảo rằng cơ sở dữ liệu mới đã được điền vào, đồng thời duy trì việc chăm sóc bệnh nhân với sản phẩm cũ cho đến khi sử dụng được. Giám đốc của cơ sở Chăm sóc tại nhà lưu ý rằng quá trình này mất nhiều thời gian hơn dự kiến nhưng rất xứng đáng về lâu dài. Sau khi đến ngày "hoạt động", hệ thống mới hoạt động khá tốt, với một lượng gián đoạn tối thiểu. Việc đào tạo nhân viên được bắt đầu hai tuần trước ngày "hoạt động". Các bác sĩ lâm sàng đã phải thực hiện một cuộc thăm khám trực tiếp với một trong những bệnh nhân
của họ bằng cách sử dụng hệ thống mới. Vì vậy, họ đã có kinh nghiệm với nó trong mơi trường thực hành trước khi chuyển sang sản phẩm mới và cam kết tồn thời gian.
Bảo trì
Nâng cấp phần mềm (được nhà cung cấp gọi là “tải mã”) được thực hiện sáu tuần một lần. Giám đốc báo cáo rằng những tiến bộ này không làm gián đoạn hoạt động hàng ngày. Giám đốc cũng cho biết tất cả người dùng cuối, bao gồm y tá, nhà vật lý trị liệu, bác sĩ và các nhân viên khác, rất hài lòng với hệ thống mới và nhìn chung, khơng có bất kỳ phàn nàn nào về nó. General kỳ vọng sẽ sử dụng phần mềm này trong tương lai gần, khơng có kế hoạch bắt tay vào một dự án tầm cỡ khác trong một thời gian khá dài.
MỘT SỐ MƠ HÌNH CỦA SDLC Mơ hình thác nước - Waterfall
Thác nước là một mơ hình SDLC được chấp nhận rộng rãi. Trong mơ hình tuyến tính này, kết quả của một giai đoạn đóng vai trị là đầu vào cho giai đoạn tiếp theo.
Hình 12.9 - Mơ hình thác nước
Mơ hình chữ V trong SDLC
Mơ hình SDLC này địi hỏi nhiều tài liệu, với các giai đoạn trước đó ghi lại những gì cần được thực hiện trong các giai đoạn tiếp theo. Tuy nhiên, nó dễ bị trì hỗn và có thể dẫn đến các vấn đề lớn phát sinh cho các nhóm phát triển dù chỉ với các chi tiết nhỏ chưa hoàn thiện trong một giai đoạn nào đó.
Mơ hình này tương tự như mơ hình thác nước, nó thể hiện sự phụ thuộc của từng giai đoạn trong SDLC. Sự khác biệt ở đây là chúng được biểu diễn dưới dạng hình chữ V chứ khộng phải là mơ hình tuyến tính. Với mơ hình chữ V, tồn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau: phát triển và kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng.
Mơ hình này hoạt động tốt cho các dự án địi hỏi nhiều sự kiểm sốt và có các u cầu được xác định rõ ràng và không thay đổi.
Mơ hình Agile trong SDLC
Mơ hình Agile ưu tiên các chu kỳ phát hành nhanh và liên tục, sử dụng các thay đổi nhỏ nhưng gia tăng giữa các bản phát hành. Điều này dẫn đến nhiều lần lặp lại và nhiều thử nghiệm hơn so với các mơ hình khác. Về mặt lý thuyết, mơ hình này giúp các nhóm giải quyết các vấn đề nhỏ khi chúng phát sinh thay vì bỏ sót chúng cho đến các giai đoạn phức tạp hơn của một dự án.
Hạn chế của mơ hình này là quá chú trọng vào tương tác với khách hàng có thể dẫn dự án đi sai hướng trong một số trường hợp.
Mơ hình xoắn ốc
Mơ hình xoắn ốc là một mơ hình phức tạp nhất trong số các mơ hình SDLC những