2. QUẢN LÝ CẤU HÌNH PHẦN MỀM
2.4. Quản lý quy trình quản lý cấu hình phần mềm
Sự nhận dạng, đánh giá và các kế hoạch làm giảm rủi ro có liên quan tới sự thực hiện các hoạt động QLCHPM. Có nhiều loại cũng như cách xếp các loại rủi ro khác nhau, tuy nhiên nhìn chung có các loại sau:
- Về kỹ thuật: Chủ yếu xoay quanh việc có hiểu đúng và đủ các yêu cầu đặt ra cho dự án hay không, cũng như có giải pháp đúng để giải quyết chúng hay không. Việc hiểu sai yêu cầu cũng như đưa ra giải pháp sai là nguyên nhân hàng đầu làm dự án thất bại.
- Về quản lý: Xoay quanh các vấn liên quan về mặt quản lý. Chúng cũng rất đa dạng, gồm các loại rủi ro sau: kế hoạch, tài chính, con người, thay đổi yêu cầu... - Về thao tác - vận hành: Liên quan đến việc vận hành hệ thống, bao gồm:
2.5. Quy trình cơ bản quản lý rủi ro gồm 4 bƣớc:
- Nhận biết các rủi ro.
- Khảo sát mức tác động nếu chúng xảy ra.
- Xác định các giải pháp đối phó.
- Giám sát các rủi ro và thực thi các giải pháp đối phó.
- Có rất nhiều giải pháp khác nhau để đối phó hay giảm thiểu tác động của rủi ro. Trong thực tế, các giải pháp thường gồm các loại:
Loại bỏ: Khi chi phí loại bỏ rủi ro thấp, hoặc rủi ro nếu xảy ra sẽ gây ảnh hưởng cực kỳ nghiêm trọng.
Phòng tránh.
Giảm thiểu thiệt hại: Khi không thể phòng tránh hay loại bỏ rủi ro, ta có thể thực thi các biện pháp để giảm thiểu khả năng xảy ra hoặc giảm thiểu chi phí khắc phục rủi ro nếu nó xảy ra.
Chấp nhận: Đành chấp nhận "sống chung với rủi ro" trong trường hợp chi phí loại bỏ, phòng tránh, làm nhẹ rủi ro là quá lớn, hoặc mức độ tác hại của rủi ro nếu xảy ra là không đáng kể, hoặc khả năng xảy ra của nó là cực thấp.
3. CÁC HOẠT ĐỘNG QUẢN LÝ CẤU HÌNH 3.1. Nhận dạng cấu hình 3.1. Nhận dạng cấu hình
3.1.1. Nhận dạng các thành phần cấu hình
- Các thành phần cần kiểm soát của dự án là baseline, cấu hình. Các thành phần và cấu trúc được duy trì trong dự án: bảng đặc tả yêu cầu, bảng đặc tả thiết kế, bảng đặc tả phân quyền, cơ sở dữ liệu của phần mềm, mã nguồn, giao diện thực thi, tài liệu quản lý cấu hình, kiểm thử…
- Cách thức các baseline được tạo ra:
- Sự kiện tạo ra baseline: khi đến một giai đoạn hoàn thành một công việc tạo ra phần mềm nhưng vẫn chưa hoàn chỉnh như: kế hoạch hoàn
- Các thủ tục được sử dụng để thiết lập và thay đổi baseline: những thay đổi được đề ra cần được xem xét kĩ lưỡng, thành viên đề ra yêu cầu thay đổi cần phải có tài liệu chứng minh sự hợp lý về sự thay đổi.
- Quyền cần để phê chuẩn các thay đổi cho các tài liệu baseline: các thành viên trong nhóm cùng xem xét việc thay đổi các baseline không được làm việc theo cá nhân, sự thay đổi là có lợi cho phần mềm, nhóm trưởng là người quyết định cuối cùng xem việc thay đổi có ảnh hưởng đến các phần khácc của phần mềm hay tiến độ làm việc của nhóm hay không.
- Phương tiện nhận dạng các thay đổi và liên kết chúng với các thành phần cấu hình bị ảnh hưởng và baseline liên quan.
3.1.2. Đặt tên cho các thành phần cấu hình
Các mã lệnh, tài liệu, dữ liệu của baseline được xác định và lưu trữ vật lý dưới sự kiểm soát của trưởng nhóm sau khi đã được xây dựng hoàn chỉnh tránh việc tổn thất thông tin, dữ liệu,…Khi sử dụng các thành phần tài liệu đã hoàn tất của nhóm phải giữ bí mật, việc truy vấn dữ liệu phải được ghi chép, kiểm soát rõ ràng nhằm đảm bảo thông tin được bảo mật và độc quyền.
3.1.3. Yêu cầu các thay đổi
Các yêu cầu thay đổi của người dùng sẽ được ghi nhận tại đây, nhóm thiết kế phần mềm sẽ ghi nhân sự thay đổi thông qua các mục sau:
- Tên và phiên bản của các thành phần được yêu cầu thay đổi.
- Tên cấu trúc ban đầu.
- Ngày yêu cầu.
Tính quan trọng và ảnh hưởng của sự thay đổi cấu hình.
Nhu cầu của người dùng khi yêu cầu thay đổi cấu hình phần mềm.
Nhóm cần có được sự mô tả chi tiết về sự thay đổi do người dùng cung cấp từ đây có thể giúp lập trình viên dễ dàng kiểm soát sự thay đổi mà không bị bối rối
Sự thay đổi từ phía người dùng ảnh hưởng trực tiếp đến cấu hình, trạng thái và cách bố trí lưu trữ sẵn có từ trước, tác động đến tiến độ hoàn thành phần mềm nên cần có
3.1.4.1. Phê chuẩn và không phê chuẩn các thay đổi
Nhóm sẽ đánh giá lại yêu cầu thay đổi, xem nó đã có sẵn từ trước thông qua sự kết nối giữa các chức năng hay chưa, đánh giá lại hoạt động của phần mềm có thay đổi gì sau khi yêu cầu được thực thi nếu không ảnh hưởng đến chức năng phần mềm thì yêu cầu sẽ không được thực hiện, nếu yêu cầu thay đổi quan trọng thì dựa vào mức ưu tiên và trách nhiệm của từng thành viên được phân công sẽ hoàn thành nhiệm vụ.
3.1.4.2. Thực thi các thay đổi
Khi các thay đổi được phê chuẩn để đảm bảo sự đầy đủ thông tin thay đổi sẽ được lưu trữ lại theo các nội dung:
- Các thay đổi có liên quan đến yêu cầu thay đổi ban đầu từ người dùng. - Tên, phiên bản bị ảnh hưởng.
- Ngày kiểm tra và người chịu trách nhiệm về các thay đổi. - Ngày cài đặt và người có trách nhiệm liên quan.
- Định danh cho phiên bản được yêu cầu thay đổi.
3.2. Báo cáo tình trạng cấu hình
- Mỗi khi một khoản mục cấu hình phần mềm được ấn định mới hoặc được cập nhật trở lại thì một nội dung (entry) được tạo ra trong CSDL. Mỗi khi một khoản mục cấu hình phần mềm được chấp thuận quyền thay đổi cấu hình thì một nội dung cũng được tạo ra, mỗi khi một kiểm toán cấu hình được tiến hành thì các kết quả của nó được báo cáo như là một phần của nhiệm vụ báo cáo hiện trạng cấu hình
- Báo cáo hiện trạng cấu hình có thể được đặt trên một CSDL trực tuyến để người phát triển hay bảo trì có thể truy cập ngay các thông tin đổi thay. Báo cáo hiện trạng cấu hình đóng một vai trò quan trọng cho thắng lợi của một dự án phát triển phần mềm lớn, loại trừ vần đề bất cập liên quan đến nhiều người bằng cách cải thiện giao tiếp giữa tất cả họ.
- Những vấn đề bất cập thiếu báo cáo hiện trạng: Xây dựng phần mềm đặc tả mà phần cứng tương ứng đã không còn dùng được nữa.Tiến hành 1 thay đổi đề xuất mà nó đã được thực hiện.Sử dụng một thành phần đang sửa đổi vì có lỗi. Cải biên cùng 1 khoản mục cấu hình với những ý định khác nhau, thậm chí là mâu thuẫn nhau.Công việc này bao gồm việc ghi nhận và báo cáo tình
Liệt kê các thay đổi còn đang dang dở hay đang hoàn thành, và các baseline bị ảnh hưởng (bởi sự thay đổi đó).
Việc báo cáo này được làm thường xuyên và định kỳ, xuyên suốt dự án.
CSAR Audit: Thường được làm sau mỗi lần một CSAR được tạo ra, việc kiểm tra bao gồm:
Bảo đảm các baseline mới nhất được liệt kê trong CSA.
Bảo đảm tất cả CI tạo nên một baseline được liệt kê
Kiểm tra các CI đã bị thay đổi từ lần baseline trước đó, so sánh chúng với các yêu cầu thay đổi để khẳng định rằng sự thay đổi trên CI là hợp lý.
Physical configuration audit (PCA): nhằm mục đích khẳng định xem những gì khách hàng yêu cầu có được hiện thực hay không. Gồm 2 việc:
- Kiểm tra vết để phản ánh tính 2 chiều (traceability) giữa yêu cầu khách hàng và việc hiện thực code trong dự án.
- Xác định những gì sẽ được phân phối cho khách hàng (các file thực thi, source code, tài liệu đi kèm…) có đáp ứng yêu cầu khách hàng hay không.- Functional configuration audit (FCA): nhằm mục đích khẳng định những gì khách hàng yêu cầu có được kiểm tra chặt chẽ trên sản phẩm tạo ra trước khi giao cho khách hàng hay không. Gồm: Kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu khách hàng và việc kiểm tra sản phẩm.
3.3. Xem lại và đánh giá cấu hình
- Mục tiêu:
Để đánh giá baseline.
Phản ánh các đặc điểm chức năng và yêu cầu vật lí đối với thành phần cấu hình thực tế.
- Các thành phần cấu hình dưới sự kiểm soát và xem lại:
- Bao gồm các baseline, cấu hình: kiểm soát kết quả các baseline được tạo ra, xác định thời gian ghim chết baseline sau khi thay đổi được chấp nhận và phê chuẩn.Đảm bảo thay đổi theo hướng có lợi và chứng thực sự thay đổi đã được phê chuẩn.
- Lịch biểu công việc xem lại và kiểm toán: Các thủ tục thực hiện:
code, giao diện thực thi, tài liệu quản lý cấu hình, test…đã được phê chuẩn.
Báo cáo hoạt động hiệu chỉnh: báo cáo kết quả sau khi thay đổi baseline (đã được phê chuẩn) , lợi ích của sự thay đổi đó.
Tiêu chí phê chuẩn:
o Có sự thống nhất của tất cả các thành viên trong nhóm.
o Được sự chấp thuận và phê chuẩn của nhóm trưởng.
o Sự thay đổi phải đảm bảo đem lại lợi ích cho phần mềm. Các hoạt động cụ thể xuất hiện theo phê chuẩn:
Sự thay đổi theo hướng có lợi của phần mềm.
Kiểm soát và xem lại kết quả sau thay đổi.
3.4. Kiểm soát giao diện
- Đăng nhập:
Chi tiết mật khẩu được ẩn đi.
- Hiển thị kết quả:
Mỗi giao diện xuất thông tin thể hiện đầy đủ các tính năng riêng biệt.
- Tài liệu và dữ liệu được kiểm soát: đặc tả và thiết kế giao diện.
3.5. Quản lý phát hành và phân phối
Kế hoạch QLCHPM mô tả cách thức xây dựng, phát hành và phân phối sản phẩm phần mềm và tài liệu được kiểm soát một cách hình thức. Các baseline được tạo ra và nếu thay đổi phải có sự phê chuẩn, thông qua kiểm soát và xem lại đảm bảo lợi ích cho phần mềm. Mã lệnh và tài liệu phải được bảo mật và bảo đảm an toàn, cần được đóng gói, lưu trữ, xử lí và phát hành theo đúng qui định.
4. CÁC LỊCH BIỂU QUẢN LÝ CẤU HÌNH PHẦN MỀM
- Trình tự tiến hành thực hiện các giai đoạn của dự án phần mềm quản lý mua bán dược phẩm:
Hình III.3 Trình tự tiến hành các giai đoạn dự án
Giai đoạn Giai đoạn Giai đoạn
lập kế Giai đoạn lập kế
Bảng III.16 Giai đoạn lập kế hoạch đảm bảo chất lƣợng phần mềm
Bảng III.17 Giai đoạn lập kế hoạch quản lý cấu hình phần mềm
Bảng III.18 Giai đoạn đặc tả
DỰ ÁN PHẦN MỀM QUẢN LÝ MUA BÁN DƯỢC PHẨM
Giai Đoạn Lập Kế Hoạch Đảm Bảo Chất Lƣợng Phần Mềm Phiên
bản Thành phần tham gia
Ngày bắt
đầu Ngày hoàn thành
Nội dung thay
đổi
Lý do thay đổi
1.0 Huỳnh Thủy Ngân 01/01/2013 04/01/2013 Không Không
DỰ ÁN PHẦN MỀM QUẢN LÝ MUA BÁN DƯỢC PHẨM
Giai Đoạn Lập Kế Hoạch Quản Lý Cấu Hình Phần Mềm Phiên
bản
Thành phần tham gia
Ngày bắt
đầu Ngày hoàn thành
Nội dung thay
đổi Lý do thay đổi
1.0 Ngô Thị Thủy
Huyền Sa 05/01/2013 06/01/2013 Không Không
DỰ ÁN PHẦN MỀM QUẢN LÝ MUA BÁN DƯỢC PHẨM
Giai Đoạn Đặc Tả Phiên bản Thành phần tham gia Ngày bắt
đầu Ngày hoàn thành
Nội dung thay
đổi
Lý do thay đổi
1.0 Huỳnh Thủy Ngân Ngô Thị Thủy Huyền Sa
05/01/2013 10/01/2013 Không Không
Bảng III.19 Giai đoạn thiết kế
Bảng III.20 Giai đoạn kiểm thử
5. CÁC TÀI NGUYÊN QUẢN LÝ CẤU HÌNH PHẦN MỀM
DỰ ÁN PHẦN MỀM QUẢN LÝ MUA BÁN DƯỢC PHẨM
Giai Đoạn Thiết Kế Phiê n bản Thành phần tham gia Ngày bắt
đầu Ngày hoàn thành
Nội dung thay
đổi
Lý do thay đổi
1.0 Ngô Thị Thủy Huyền Sa,
Huỳnh Thủy Ngân 10/01/2013 20/03/2013 Không Không 1.1 Ngô Thị Thủy Huyền Sa 10/01/2013 29/02/2013 Giao diện hệ
thống
Đặc tả thay đổi
1.2 Ngô Thị Thủy Huyền Sa 01/02/2013 20/03/2013 Giao diện chức năng Admin
Đặc tả thay đổi
1.3 Ngô Thị Thủy Huyền Sa 01/02/2013 20/03/2013 Giao diện chức năng quản lý, thủ kho
Đăc tả thay đổi
DỰ ÁN PHẦN MỀM QUẢN LÝ MUA BÁN DƯỢC PHẨM
Giai Đoạn Kiểm Thử
Phiên bản
Thành phần tham gia
Ngày bắt
đầu Ngày hoàn thành
Nội dung thay
đổi Lý do thay đổi
1.0 Ngô Thị Thủy Huyền Sa, Huỳnh Thủy Ngân
6. BẢO TRÌ KẾ HOẠCH QUẢN LÝ CẤU HÌNH PHẦN MỀM
Nhân sự giám sát kế hoạch: Huỳnh Thủy Ngân.
- Cách thức cập nhật: cập nhật mỗi khi có sự thay đổi trong từng giai đoạn, trong cả dự án. Ghi rõ thời gian bắt đầu, thời gian hoàn thành, phiên bản, thành viên tham gia, nôi dung thay đổi, lý do…
- Cách đánh giá và phê chuẩn: mỗi phiên bản của từng giai đoạn hoàn thành sẽ được kiểm tra cẩn thận và đánh giá lại nếu chưa hợp lý sẽ được sửa lại trong khoảng thời gian ngắn nhất. để đảm bảo đúng đắn cần kiểm tra đánh giá trước khi đưa ra phiên bản mới.
PHẦN 4: ĐẶC TẢ YÊU CẦU PHẦN MỀM
1. GIỚI THIỆU
1.1. Mục đích
Tài liệu này làm ra để những người phát triển phần mềm dùng: Thiết kế viên, kiểm thử viên, người quản lý, lập trình viên, người dùng.
1.2. Nhóm ngƣời đọc
Tài liệu đặc tả này gồm 5 phần cơ bản: Giới thiệu – Mô tả tổng quan – Các yêu cầu giao tiếp – Các tính năng của hệ thống – Các yêu cầu phi chức năng.
- Nhóm 1: Lập trình viên nên đọc cả 5 phần.
- Nhóm 2: Thiết kế viên cần đọc phần mô tả chức năng và các yêu cầu giao tiếp.
- Nhóm 3: Kiểm thử viên đọc về phần các tính năng của hệ thống và các yêu cầu phi chức năng.
- Nhóm 4: Người quản lý cần đọc các yêu cầu của người sử dụng.
- Nhóm 5: Người dùng đọc phần các tính năng của hệ thống.
1.3. Phạm vi sản phẩm
- Nhằm tin học hóa hệ thống quản lý dược phẩm, chúng tôi đưa ra phần mềm, giúp cho việc quản lý của công ty ngày một tốt hơn.
- Đây là hệ thống độc lập. Quản lý trong phạm vi nhà thuốc, các kho hàng thuộc hệ thống nhà thuốc.
- Chương trình có các chức năng cơ bản như sau: nhập dữ liệu, truy cập dữ liệu, tìm kiếm, trích xuất thông tin, tính toán hóa đơn, thống kê dữ liệu, ...
2. MÔ TẢ TỔNG QUAN
2.1. Mô hình hệ thống
- Đây là hệ thống độc lập. Quản lý trong phạm vi nhà thuốc và các kho thuộc hệ thống nhà thuốc.
2.2. Các chức năng của sản phẩm
Hình III.5 Sơ đồ chức năng
2.3. Ngƣời sử dụng:
Nhóm dược sĩ: Chỉ được sử dụng phần mềm bán lẻ để bán hàng.
Nhóm thủ kho: Chỉ được sử dụng các chức năng liên quan đến quản lý xuất nhập kho trong phần mềm quản lý nhà thuốc.
Nhóm quản lý: Được sử dụng phần mềm quản lý nhà thuốc để quản lý việc mua bán, chi phí, báo cáo.... và quản lý nhân viên.
Nhóm Admin: Được sử dụng phần mềm quản trị người dùng, quản trị các tài khoản và quyền của các tài khoản khi đăng nhập vào hệ thống. Được sử dụng phần mềm quản lý cấu hình để tùy chỉnh các chức năng trong hệ thống và chi tiết