Niên luận 4 Quản lý khách hàng bảo hiểm

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân Functionality Khả năng của phần mềm cung cấp các chức năng thỏa mãn các yêu cầu được chức năng cũng như các yêu cầu phi chức năng kh

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

2

Bảng ghi nhận thay đổi tài liệu dự án

*T - Thêm mới S - Sửa đổi X - Xóa

Ngày

thay đổi Mục, bảng, sơ đồ được thay đổi Lý do T/S/X (*)

Miêu tả thay đổi

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

3

Mục lục

1 Tổng quan về dự án 5

1.1.Mô tả dự án 5

1.2.Sản phẩm dự án 5

1.3.Tài liệu tham khảo và liên quan 6

1.4.Khái niệm, định nghĩa, từ viết tắt 6

2 Tổ chức dự án 7

3 Quá trình quản lý rủi ro 8

3.1.Các yếu tố rủi ro và phương án phòng ngừa 8

3.2.Biện pháp khắc phục 9

4 Quá trình đảm bảo chất lượng 10

4.1.Các mục tiêu chất lượng 10

4.2.Thước đo chất lượng 11

4.3.Hồ sơ chất lượng 11

5 Kiểm soát cấu hình sản phẩm 12

5.1.Danh mục sản phẩm do khách hàng cung cấp 12

5.2.Định nghĩa các đơn vị cấu hình 12

5.3.Qui định quản lý mã nguồn và các thư viện (nếu có) Error! Bookmark not defined. 5.4.Cấu trúc thư mục dự án 12

5.5.Quy trình lưu trữ dự phòng 12

6 Tiến trình dự án 13

6.1.Phương pháp và cụng cụ 13

6.2.Lưu đồ (tham chiếu qui trỡnh thực hiện dự án) 14

6.3.Các giai đoạn thực hiện 14

6.4.Kế hoạch thực hiện 16

6.5 Kế hoạch kiểm tra xem xét 16

6.6.Yêu cầu về môi trường và điều kiện làm việc (áp dụng cho từng giai đoạn) 16

6.7.Các hệ thống liên quan: (nếu có) 17

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

4

DANH MỤC CÁC BẢNG

Bảng 1: Danh mục sản phẩm dự án 5

Bảng 2: Tài liệu tham khảo và liên quan 6

Bảng 3: Khái niệm, định nghĩa, từ viết tắt 6

Bảng 4: Tổ chức dự án Error! Bookmark not defined Bảng 5: Trách nhiệm của khách hàng Error! Bookmark not defined Bảng 6: Danh sách địa chỉ liên hệ Error! Bookmark not defined Bảng 7: Các yếu tố rủi ro 8

Bảng 8: Biện pháp khắc phục 9

Bảng 9: Mục tiêu chất lượng 10

Bảng 10: Thước đo chất lượng 11

Bảng 11: Hồ sơ chất lượng dự án 11

Bảng 12: Danh mục sản phẩm do khách hàng cung cấp Error! Bookmark not defined Bảng 13: Các đơn vị cấu hình 12

Bảng 14: Cấu trúc thư mục dự án 12

Bảng 15: Phương pháp lưu trữ dự phòng dữ liệu 12

Bảng 16: Danh mục công cụ 13

Bảng 17: Kế hoạch thực hiện 16

Bảng 18: Kế hoạch đánh giá, xem xét 16

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

5

1 TỔNG QUAN VỀ DỰ ÁN

1.1 Mô tả dự án

Giảng viên hướng dẫn: Hồ Quang Thái

Tên dự án: Quản lý khách hàng mua bảo hiểm

Ngày bắt đầu: 20/08/2012

Ngày dự kiến kết thúc: 20/11/2012

Mục tiêu dự án: Cải tiến việc nhập, lưu trữ, thống kê dữ liệu về khách hàng

Phạm vi dự án: Phần mềm desktop, quản lý khách hàng trong 1 công ty bảo hiểm

Người thực hiện: Huỳnh Thủy Ngân

Ngày bàn giao

1 Tài liệu kế hoạch quản

2 Tài liệu kế hoạch đảm

bảo chất lượng 1 1 Bộ môn KTPM 24/11/2012

3 Tài liệu kế hoạch quản

Bộ môn KTPM 24/11/2012

7 Tài liệu các trường hợp

Bộ môn KTPM 24/11/2012

8 Tài liệu báo cáo tiến độ

10 Phần mềm quản lý

Bộ môn KTPM 24/11/2012

11 Cơ sở dữ liệu

KTPM 24/11/2012

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

6

1.3 Tài liệu tham khảo và liên quan

Bảng 2: Tài liệu tham khảo và liên quan

1.4 Khái niệm, định nghĩa, từ viết tắt

Bảng 3: Khái niệm, định nghĩa, từ viết tắt

QLKH Quản lý khách hàng

GVHD Giáo viên hướng dẫn

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

7

2 TỔ CHỨC DỰ ÁN

Phương pháp theo dõi hoạt động dự án

- Báo cáo của sinh viên cho giảng viên

Sinh viên trao đổi với GVHD qua email để giải quyết các vướng mắc trong quá trình thực hiện NL (nếu có) hoặc GVHD sẽ hẹn gặp trực tiếp Lịch hẹn hướng dẫn : chiều thứ

7 các tuần 2, 4, 6, 8, 10, 12 (14h00-16h30) tại văn phòng Bộ môn CNPM

- Xem xét công việc quản lý dự án:

Xem xét tiến độ công việc hàng tuần

- Xem xét của giảng viên

Quyển báo cáo kết quả thực hiện niên luận và đĩa CD ghi source code chương trình demo sẽ được nộp cho GVHD vào thời điểm sinh viên báo cáo chương trình demo

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

8

3 QUÁ TRÌNH QUẢN LÍ RỦI RO

3.1 Các yếu tố rủi ro và phương án phòng ngừa

6 Thời gian thực

hiện quá gắt

4 Trễ tiến độ,

không hoàn thành dự án

Chia nhỏ, rút ngắn thời gian thực hiện dự án

2 Thiếu kiến

thức chuyên môn, kinh nghiệm

4 Phát sinh lỗi Bổ sung kiến thức cho thành

viên trong nhóm

Phân tích khả năng xuất hiện của rủi ro

Có 4 mức để đo lường khả năng xuất hiện của rủi ro, mỗi mức độ được gán với một giá trị số (tùy dự án) để có thể ước lượng sự quan trọng của nó

• 6 - Thường xuyên: Khả năng xuất hiện rủi ro rất cao, xuất hiện trong hầu hết dự án

• 4 - Hay xảy ra: Khả năng xuất hiện rủi ro cao, xuất hiện trong nhiều dự án

• 2 - Đôi khi: Khả năng xuất hiện rủi ro trung bình, chỉ xuất hiện ở một số ít dự án

• 1 - Hiếm khi: Khả năng xuất hiện thấp, chỉ xuất hiện trong những điều kiện nhất định Phân tích mức tác động của rủi ro

Có 4 mức để đo lường mức tác động của rủi ro, mỗi mức độ được gán với một giá trị số (tùy

dự án) để có thể ước lượng sự tác động của nó

• 8 - Trầm trọng: Có khả năng rất cao làm dự án thất bại

• 6 - Quan trọng: Gây khó khăn lớn và làm dự án không đạt được các mục tiêu

• 2 - Vừa phải: Gây khó khăn cho dự án, ảnh hưởng việc đạt các mục tiêu của dự án

• 1 - Không đáng kể: Gây khó khăn không đáng kể

1 Độ ưu tiên = khả năng xuất hiện* ảnh hưởng, và được sắp xếp theo thứ tự giảm dần

2 Khả năng xuất hiện được quy định bằng trọng số

3 ảnh hưởng được quy định bằng trọng số Mức độ ảnh hưởng phụ thuộc vào nơi nó gây tác động

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

9

3.2 Biện pháp khắc phục

Bảng 5: Biện pháp khắc phục

TT Yếu tố rủi ro Biện pháp khắc phục

1 Thiếu thời gian cho

kiểm định

Điều chỉnh thời gian kế hoạch kịp thời

2 Thời gian thực hiện

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

(Functionality) Khả năng của phần mềm cung cấp

các chức năng thỏa mãn các yêu cầu được chức năng cũng như các yêu cầu phi chức năng khi phần mềm được sử dụng trong những hoàn cảnh cụ thể

2 Độ ổn định (Reliability) Khả năng của phần mềm duy trì

mức hiệu năng được chỉ định rõ khi sử dụng dưới những điều kiện

cụ thể

3 Tính khả dụng

(Usability) Khả năng của phần mềm để có thể

hiểu được, học hỏi được, sử dụng được và hấp dẫn đối với người sử dụng

4 Tính hiệu quả

(Efficiency)

Khả năng của phần mềm cung cấp hiệu năng thích hợp nhằm tiết kiệm tối đa tài nguyên và tăng tối

đa hiệu suất công việc, dưới những điều kiện sử dụng nhất định

4 Khả năng bảo hành bảo

trì (Maintainability)

Khả năng của phần mềm cho phép sửa đổi, nâng cấp, bao gồm sửa chữa, cải tiến hoặc thích nghi của phần mềm thay đổi cho phù hợp với môi trường, các yêu cầu và chức năng mới

6 Tính khả chuyển

(Portability)

Khả năng của phần mềm có thể chuyển được từ môi trường này sang môi trường khác

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

11

4.2 Thước đo chất lượng

Bảng 7: Thước đo chất lượng Loại4 Thước đo chất

T

Tên sản phẩm Tên hồ sơ chất lượng Vị trí lưu hồ sơ

2 Tài liệu kế hoạch đảm

bảo chất lượng

3 Tài liệu kế hoạch quản

lý cấu hình

4 Tài liệu đặc tả

5 Tài liệu thiết kế

6 Tài liệu kế hoạch kiểm

4 Loại: Sản phẩm hoặc Quá trình

5 Có thể lựa chọn trong các thước đo sau với đơn vị đo tương ứng sau:

- Tính đúng hạn (% =  (SP bàn giao đúng hạn)/  (SP phải bàn giao))

- Thời gian thực hiện (MM)

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

12

10 Phần mềm quản lý

khách hàng bảo hiểm

11 Cơ sở dữ liệu

5 KIỂM SOÁT CẤU HÌNH SẢN PHẨM

5.1 Định nghĩa các đơn vị cấu hình

5.3 Quy trình lưu trữ dự phòng

Quản trị hệ thống chịu trách nhiệm trước trưởng đơn vị về việc lưu trữ dự phòng CSDL, các tài liệu, dữ liệu và hồ sơ liên quan của dự án định kỳ hàng ngày để đảm bảo ở trong tình trạng

an toàn

Bảng 11: Các phương pháp lưu trữ dự phòng dữ liệu

Nội dung cần lưu

trữ

Phương pháp lưu trữ

Phương pháp khôi phục

Thời gian bắt đầu và chu kỳ lưu trữ

Cơ sở dữ liệu Sao lưu dữ liệu Phục hồi dữ liệu Tuần 5, lưu trữ hàng

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

- Bám sát yêu cầu phần mềm để thực hiện đặc tả các chức năng của hệ thống

- Dựa vào đặc tả, thiết kế phần mềm theo đúng yêu cầu, chính xác, đầy đủ

- Dựa trên thiết kế, cài đặt và kiểm thử phần mềm

6.1.2 Các tiêu chuẩn và hướng dẫn

- Chuẩn tài liệu: Chuẩn IEEE

- Chuẩn code: Chuẩn code dành cho C#

6.1.3 Công cụ

Bảng 12: Danh mục công cụ Công cụ Nguồn cung cấp Giai đoạn/hoạt động Mục đích

dữ liệu

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

Điều kiện kết thúc: Vét cạn các trường hợp theo yêu cầu của người dùng

6.3.2 Giai đoạn thiết kế:

Điều kiện bắt đầu: Giai đoạn đặc tả kết thúc Phương pháp và công cụ thực hiện: Dựa trên tài liệu đặc tả vẽ sơ đồ CDM bằng

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

15

PowerDesign, thiết kế giao diện bằng VisualStudio, thiết kế từ điển dữ liệu bằng SQLServer

Phương pháp và công cụ kiểm tra và thử nghiệm: Dựa trên tài liệu đặc tả, vét hết

trường hợp, kiểm tra ràng buộc, giao diện đầy đủ chức năng, thân thiện với người dùng

Điều kiện kết thúc: Hoàn thành cơ sở dữ liệu đúng đắn, giao diện đầy đủ chức năng 6.3.3 Giai đoạn lập trình cài đặt:

Điều kiện bắt đầu Giai đoạn thiết kế kết thúc Phương pháp và công cụ thực hiện Lập trình dựa trên thiết kế, sử dụng Visual

Studio

Phương pháp và công cụ kiểm tra và hiệu chỉnh: Kiểm thử bằng quicktestpro Điều kiện kết thúc: Sản phẩm chạy được

6.3.4 Giai đoạn kiểm tra và hiệu chỉnh

Điều kiện bắt đầu: Sau khi giai đoạn lập trình kết thúc Phương pháp và công cụ thực hiện: Sử dụng quicktestpro để tạo kịch bản kiểm thử

cho từng loại người dùng

Phương pháp và công cụ kiểm tra và hiệu chỉnh: Kiểm tra xem các kịch bản kiểm

thử đã vét hết trường hợp hay chưa

Điều kiện kết thúc: Sản phẩm được bắt lỗi đầy đủ, vét hết trường hợp và được sửa lỗi

hoàn chỉnh

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

16

6.4 Kế hoạch thực hiện

Bảng 13: Kế hoạch thực hiện Stt Nhóm công việc/công việc Thời gian dự kiến thực hiện

1 Giai đoạn khởi động 1 tuần

1.1 - Lập kế hoạch khung dự án Tuần 3

2 Giai đoạn đặc tả 2 tuần

2.1 Đặc tả nhóm thành viên Tuần 4

2.2 Đặc tả chức năng Tuần 5

3 Giai đoạn thiết kế 3 tuần

3.2 Thiết kế từ điển dữ liệu Tuần 7

3.3 Thiết kế giao diện Tuần 8

4 Giai đoạn lập trình cài đặt 3 tuần

4.1 Cài đặt database Tuần 9

4.2 Cài đặt giao diện Tuần 10

4.3 Lập trình Controller Tuần 11

4.4 Kết nối các module Tuần 12

5 Giai đoạn kiểm thử 2 tuần

5.1 Kiểm thử chức năng Tuần 13

5.2 Kiểm thử hệ thống Tuần 14

7 Giai đoạn kết thúc dự án Tuần 16

6.5 Kế hoạch đánh giá xem xét

Bảng 14: Kế hoạch đánh giá xem xét Giai

Thời gian

dự kiến xem xét, đánh giá

Số lần và phương pháp đánh giá

Tiêu chí đánh giá

2 Tài liệu đặc tả Tuần 4 Tuần 6 2 Đúng với yêu

Phần mềm quản lý khách hàng bảo hiểm Huỳnh Thủy Ngân

17

ĐẠI HỌC CẦN THƠ

KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

QUẢN LÝ KHÁCH HÀNG

MUA BẢO HIỂM

Kế hoạch đảm bảo chất lượng

Ngày hoàn thành: 31/08/2012 Người viết: Huỳnh Thủy Ngân

MỤC LỤC

Mục lục

Theo dõi phiên bản tài liệu

1 Mục đích

2 Tài liệu tham khảo

3 Quản lý

3.1.Tổ chức

3.2.Công việc

3.3.Vai trò và trách nhiệm

3.4.Các nguồn tài nguyên được dự đoán để đảm bảo chất lượng

4 Tài liệu

4.1.Mục đích

4.2.Yêu cầu tài liệu tối thiểu

5 Các chuẩn, thực tiễn, quy ước và các phép đo

5.1.Mục đích

5.2.Nội dung

6 Xem lại phần mềm

6.1.Mục đích

6.2.Các yêu cầu tối thiểu

7 Kiểm thử

8 Hoạt động hiệu chỉnh và báo cáo vấn đề

9 Công cụ, kỹ thuật và phương pháp

10 Tập hợp hồ sơ, bảo trì và tiếp tục sử dụng

11 Quản lý rủi ro

12 Bảng chú giải thuật ngữ

13 Lịch sử và thủ tục thay đổi bản kế hoạch đảm bảo chất lượng phần mềm

Theo dõi phiên bản tài liệu

- Bảo mật: để đảm bảo nội dung dữ liệu,dữ liệu đang được chuyền (trên đường chuyền) không bị hư hại

- Quản lý rủi ro: tìm ra các biện pháp làm giảm và giải quyết khi rủi ro xảy ra

2 Tài liệu tham khảo

3 Quản lý

3.1.Công việc

- Thiết lập và bảo trì kho lưu trữ (repository) của dự án

- Phát triển và triển khai các quy trình thủ tục quản lý của dự án

- Giám sát các hoạt động SQA

- Kiểm tra chất lượng phần mềm với quan điểm khách hàng

+ Có đáp ứng được các nhân tố chất lượng không?

+ Có tuân theo các chuẩn dự định trước không?

+ Các thủ tục phương pháp kỹ thuật có thực sự đóng vai trò của chúng trong hoạt động SQA?

3.2.Vai trò và trách nhiệm

2 Đặc tả nhóm thành viên Tuần 5

3 Kiểm tra chất lượng đặc

tả chức năng Tuần 6

4 Kiểm tra chất lượng

CDM

Tuần 7

5 Kiểm tra chất lượng từ

điển dữ liệu Tuần 8

6 Kiểm thử chương trình Tuần 13

Trách nhiệm:

- Tuân thủ tất cả các quy trình thủ tục của bản kế hoạch QLCH (CMP)

3.3.Các nguồn tài nguyên được dự đoán để đảm bảo chất lượng

- Con người:

giám sát, kiểm tra chất lượng toàn bộ dự án

Có khả năng quản lý Kiến thức lập trình tốt

tốt.

Phần mềm dùng lại được

- Phần mềm được chia theo cấu trúc 3 lớp (giao diện, dữ liệu, và điều khiển),

được chỉnh sửa từ Phần mềm quản lý kho hàng

4 Tài liệu

4.1.Mục đích

4.2.Yêu cầu tài liệu tối thiểu

- Tài liệu đặc tả

- Tài liệu thiết kế

- Tài liệu kiểm thử

5 Các chuẩn, thực tiễn, quy ước và các phép đo

5.1.Mục đích

Xây dựng các tiêu chuẩn và các thủ tục cho quá trình phát triển phần mềm là rất

quan trọng, nó cung cấp một khuôn khổ mà ở đó quá trình phát triển sẽ được thực

hiện

Các tiêu chuẩn là các chuẩn được tạo ra làm cơ sở để đánh giá các sản phẩm phần mềm

Các thủ tục là các chuẩn được tạo ra làm cơ sở để đánh giá về quy trình phát triển

- Các quy ước về tài liệu: Tên tài liệu phải được ghi rõ ràng từng phần, tên tài liệu phải đúng với nội dung trình bày.Cách trình bày tài liệu: Sử dụng bộ mã tiếng Việt unicode để soạn thảo:

 Tiêu đề mục lớn (Heading 1): font Arial, Size 16, Bold, chữ thường; Ví dụ: mục lớn là “ 1. ”

 Tiêu đề mục nhỏ (Heading 2): font Arial, Size 14, Bold+ Italic, chữ thường; Ví dụ: mục nhỏ là “ 1.1. ”

 Tiêu đề mục con (Heading 3): font Arial, Size 13, Bold, chữ thường;

 Nội dung (normal): font Times New Roman, size 13, chữ thường

 Sử dụng format/style để định nghĩa các style trên

 Mục lục trình bày đến 3 cấp (heading 1, 2, 3) Sử dụng Insert/Index and Table/ Table of contents để làm mục lục tự động

 Quy cách đánh số mục theo kiểu Outline

Ví dụ 1.2.1 là mục 1 con trong mục 2 nhỏ của mục 1 lớn Sử dụng Format/Bullets and Numbering/Outline Numbered

 Đánh số trang ở trên cùng lề phải, cách đánh số kiểu “Page 1,2.3…”

 Header and Footer phải ghi bên lề trái, header ghi tên tài liệu, tên nhóm, tên đề tài; Footer ghi tên giáo viên hướng dẫn

- Các quy ước thiết kế: giao diện đặt ở góc trên, bên trái màn hình, label phải ghi rõ ràng, đầy đủ thông tin, button phải đặt ở phía dưới cùng của form, textbox phải bố trí phía trên, từ trái qua phải trong form

- Các quy ước về lập trình: đặt tên biến phải mang tính gợi nhớ viết bằng chữ thường Sử dụng ngôn ngữ lập trình C# phiên bản 20010; hệ quản trị cơ sở dữ liệu SQL server 2008

- Các chuẩn / quy ước viết chú thích: chú thích về tên module phải viết bằng chữ thường, rõ ràng, đúng với chức năng mà mô dule đó thực hiện

và đặt trên mỗi mô dule đó

- Các chuẩn và thực tiễn kiểm thử: người được quy định kiểm thử phải cho phần mềm chạy trên môi trường windows, phải kiểm thử đủ và lần lượt từng chức năng, khi có lỗi phải hiệu chỉnh lại

6 Xét duyệt

6.1.Mục đích

- Tìm lỗi từ các tài liệu viết (tài liệu đặc tả, tài liệu thiết kế, mã nguồn, )

- Tìm ra lỗi sau những bước ngoặc tạo lập phần mềm

6.2.Các yêu cầu tối thiểu

- Xét duyệt chuẩn kĩ thuật

- Xét duyệt chuẩn thiết kế

- Kiểm duyệt

7 Kiểm thử

- Kiểm thử chức năng

- Kiểm thử hệ thống

8 Hoạt động hiệu chỉnh và báo cáo vấn đề

- Hiệu chỉnh lỗi trong code ở các phần riêng biệt

- Tài liệu hóa các chỉnh sửa

9 Công cụ, kỹ thuật và phương pháp

Các công cụ, kỹ thuật quản lý chất lượng phần mềm:

- Công cụ bảo quản tài liệu phần mềm sử dụng mạng internet là mediafire: tài liệu phần mềm của bạn sẽ được bảo vệ khi được đưa vào công cụ này và thậm chí tài liệu của bạn có thể cho các thành viên trong nhóm của bạn có thể lấy

nó ra khi bạn muốn

10 Tập hợp hồ sơ, bảo trì và tiếp tục sử dụng

11 Quản lý rủi ro

STT Yếu tố rủi ro Mức độ

rủi ro Chiến lược làm giảm rủi ro

Hướng giải quyết khi xảy ra rủi ro Nhóm yếu tố rủi ro liên quan đến khách hàng và người sử dụng

1 Yêu cầu thay đổi

thường xuyên Thấp

Trao đổi thường xuyên với giảng viên để tìm hiểu kĩ yêu cầu và cho một khoảng thời gian để thay đổi yêu cầu

Sửa lại chức năng phần mềm theo yêu cầu của giảng viên

Nhóm yếu tố rủi ro liên quan đến phạm vi và các yêu cầu

2 Yêu cầu không

được hiểu đúng

Trung bình

Đi gặp giảng viên để lấy thông tin Gặp giảng viên để lấy

thông tin lại

Nhóm yếu tố rủi ro liên quan đến sự thực hiện

ĐẠI HỌC CẦN THƠ

KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

QUẢN LÝ KHÁCH HÀNG

MUA BẢO HIỂM

Kế hoạch quản lý cấu hình phần mềm

Ngày hoàn thành: 01/09/2012 Người viết: Huỳnh Thủy Ngân

Mục lục

Mục lục ii Theo dõi phiên bản tài liệu iii

1 Giới thiệu 1

2 Quản lý cấu hình phần mềm 2.1 Tổ chức 2.2 Các trách nhiệm của quản lý cấu hình phần mềm 2.3 Các chính sách, hướng dẫn và thủ tục có thể sử dụng được 2.4 Quản lý quy trình quản lý cấu hình phần mềm

3 Các hoạt động quản lý cấu hình 3.1 Nhận dạng cấu hình 3.2 Kiểm soát cấu hình 3.3 Báo cáo tình trạng cấu hình 3.4 Xem lại và đánh giá cấu hình 3.5 Kiểm soát giao diện 3.6 Kiểm soát nhà cung cấp / nhà thầu phụ 3.7 Quản lý phát hành và phân phối

4 Các lịch biểu quản lý cấu hình phần mềm

5 Các tài nguyên quản lý cấu hình phần mềm

6 Bảo trì kế hoạch quản lý cấu hình phần mềm

Theo dõi phiên bản tài liệu

1.4 Tài liệu tham khảo:

Tài liệu mẫu quản lý cấu hình : “Gryphon Configuration Management Plan/ Change Control Process”

Website tham khảo:

www.google.com

http://rup.hops-fp6.org/process/artifact/ar_cmpln.htm

Baseline Là phiên bản với một số tính năng được đáp ứng yêu cầu tại

một thời điểm nào đó

Mẫu cấu hình (CI) Là một work product, mô tả hay thực hiện yêu cầu của một

phiên bản

Work product Bao gồm tất cả các tài liệu, source code của dự án

Version Là một số hiệu duy nhất dùng đánh dấu cho mỗi phiên bản

của work product

một work product Nó được dùng để chi sự thay đổi của một version đặc biệt

Label Cũng là một dạng tag dùng để xác định một phiên bản của

một mẫu cấu hình Label được dùng để đánh dấu version của một baseline của một work product

2 Quản lý cấu hình phần mềm

2.1 Các trách nhiệm của quản lý cấu hình phần mềm:

- Quản lý chất lượng yêu cầu

- Quản lý kĩ thuật

- Quản lý test

2.2 Các chính sách, hướng dẫn và thủ tục có thể sử dụng được:

Dự án này cần quản lý cấu hình vì những lý do:

- Để hiểu được quá trình một work product được baseline.

- Đảm bảo rằng những requirement, design, hoặc việc thay đổi code không vi phạm các quy định đã để ra , nghĩa là chúng chỉ được thực hiện sau khi một baseline đã được thiết lập.

- Đảm bảo rằng không mẫu cấu hình không nào bị thay đổi bởi các kỹ sư tại bất

kỳ thời điểm nào.

- Đảm bảo sự tác động của một vài thay đổi lên một mẫu cấu hình được đánh giá, công nhận và quản lý.

- Nắm bắt được tình trạng hiện hành của sản phẩm tại mọi thời điểm

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.1 Nhận dạng các thành phần cấu hình:

Mục đích của việc lên baseline cho một sản phẩm là để chuyển tất cả các sản phẩm trong quá trình làm việc vào trong các mẫu cấu hình Để có thể được xem là một mẫu cấu hình, những tiêu chuẩn sau phải được đáp ứng:

 Sản phẩm của công việc phải được kiểm tra chính thức

 Tất cả các lỗi chính được tìm thấy trong quá trình làm việc khi được kiểm tra phải được sửa chữa

 Tất cả các bên liên quan phải có chữ ký trong tài liệu

 Sản phẩm của quá trình làm việc nằm trong thư mục đặc biệt của Google Code

 Đối với những tài liệu, tất cả các tập tin được liên kết vào tài liệu chính phải nằm trong cùng thư mục với tài liệu chính đó

3.1.2 Đặt tên cho các thành phần cấu hình:

Nhãn hiệu mẫu cấu hình đánh dấu một baseline.

Một tài liệu sẽ trải qua một vòng đời phát triển từ phiên bản Draft – là phác thảo cơ sở ban đầu đến mốc phiên bản cuối cùng được bàn giao (release) Để đảm bảo cho việc theo dõi các phiên bản trong quản lý cấu hình, việc đánh phiên bản cần có quy định

Thông thường các quy định đánh phiên bản được xác định như sau:

 Trong quá trình tạo mới lần đầu tiên (chưa được phê duyệt), Tài liệu có phiên bản là “Draft”

 Số phiên bản của tài liệu bao gồm 2 chữ số có dạng : a.b Phiên bản đầu tiên của tài liệu (sau khi được review, phê duyệt lần đầu) mang số 1.0 (Phiên bản 1.0)

 Tài liệu nếu được nâng cấp ở mức độ lớn sẽ có số a của phiên bản tăng lần lượt: 2, 3, 4, 5… (Phiên bản 2.b, Phiên bản 3.b, Phiên bản 4.b,…)

 Tài liệu nếu được nâng cấp ở mức độ vừa và nhỏ sẽ có số b của phiên bản tăng lần lượt: 1, 2, 3, 4, … (Phiên bản a.1, Phiên bản a.2, Phiên bản a.3,…)

3.1.3 Có được các thành phần cấu hình:

- Kế hoạch quản lý dự án

- Kế hoạch đảm bảo chất lượng

- Kế hoạch quản lý cấu hình

- Các trường hợp kiểm thử

- Báo cáo tiến độ

- Biên bản bàn giao sản phẩm

3.2 Kiểm soát cấu hình:

3.2.1 Yêu cầu các thay đổi:

Một yêu cầu thay đổi là một mẫu cấu hình, vì thế, yêu cầu thay đổi này phải được đăng

ký Gồm các bước sau:

 Điền vào những phần thích hợp (phần mong muốn thay đổi) trong bảng mẫu thay đổi

Nhà quản lý hỗ trợ phải:

thay đổi về yêu cầu thay đổi của thành viên đó

yêu cầu thay đổi

Nhà quản lý hỗ trợ:

 Quyết định xem yêu cầu thay đổi là nhỏ hay lớn

Nếu yêu cầu thay đổi là nhỏ, nhà quản lý hỗ trợ phải:

 Cho phép thành viên muốn thay đổi mẫu cấu hình sử

lý những thay đổi đó

Nếu yêu cầu thay đổi là lớn, nhà quản lý hỗ trợ phải:

 Lên lịch biểu để các thành viên trong hội đồng quản lý thay đổi xem xét yêu cầu thay đổi

Bản 1: Quá trình đăng ký một yêu cầu thay đổi

3.2.2 Đánh giá các thay đổi:

Xem xét yêu cầu thay đổi là xem xét và quyết định xem dự án này có nên hay không nên thay đổi mẫu cấu hình Gồm các bước sau:

STT Sự kiện Ghi chú

cầu thay đổi

Các thành viên của hội đồng quản lý thay đổi phải:

 Xem xét yêu cầu thay đổi

 Phân tích xem yêu cầu có quan trọng không

 Phân tích sự tác động của thay đổi đến toàn dự án

từ chối yêu cầu

thay đổi

Các thành viên của hội đồng quản lý thay đổi phải:

 Chấp nhận hoặc từ chối một yêu cầu thay đổi

 Đánh dấu những quyết định của họ trong bảng mẫu thay đổi

Nhà quản lý hỗ trợ phải:

 Ký tên vào bảng mẫu thay đổi để cho thấy rằng đây là quyết định cuối cùng

Bản 2: Quá trình xem xét một yêu cầu thay đổi

3.3 Báo cáo tình trạng cấu hình:

Liệt kê tất cả baseline và cấu hình thành phần hoặc có liên quan

Làm nổi bật các Cl đang được phát triển hoặc vừa bị thay đổi

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

3.4 Xem lại và đánh giá cấu hình:

Với mỗi xem lại và đánh giá cần trình bày các nội dung:

- Mục tiêu

- Các thành phần cấu hình dưới sự kiểm soát và xem lại

- Lịch biểu của công việc xem lại hay kiểm toán

- các thủ tục thực hiện kiểm toán hay xem lại

- Những người tham gia theo tên công việc

- Tài liệu cần cho việc xem lại hay hỗ trợ cho kiểm toán hay xem lại

3.5 Kiểm soát giao diện:

Trình bày giao diện cũ và mới

Trình bày các thành phần bị ảnh hưởng Lập bảng chức năng mới, chức năng chỉnh sửa

ĐẠI HỌC CẦN THƠ

KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

QUẢN LÝ KHÁCH HÀNG MUA BẢO HIỂM

Đặc tả yêu cầu phần mềm

Ngày hoàn thành: 15/09/2012 Người viết: Huỳnh Thủy Ngân

Mục lục

Mục lục Theo dõi phiên bản tài liệu

1 Giới thiệu 1.1 Mục đích 1.2 Nhóm người đọc 1.3 Phạm vi sản phẩm 1.4 Bảng chú giải thuật ngữ 1.5 Tài liệu tham khảo

2 Mô tả tổng quan 2.1 Mô hình hệ thống 2.2 Các chức năng của sản phẩm 2.3 Người sử dụng 2.4 Môi trường vận hành 2.5 Các ràng buộc về thực thi và thiết kế 2.6 Các giả định và phụ thuộc

3 Các yêu cầu giao tiếp 3.1 Giao tiếp người sử dụng 3.2 Giao tiếp phần cứng 3.3 Giao tiếp phần mềm 3.4 Giao tiếp truyền thông tin

4 Các tính năng của hệ thống 4.1 Tính năng 1 của hệ thống 4.2 Tính năng 2 của hệ thống 4.3

5 Các yêu cầu phi chức năng

5.1 Yêu cầu thực thi 5.2 Yêu cầu an toàn 5.3 Yêu cầu bảo mật 5.4 Các đặc điểm chất lượng phần mềm 5.5 Câc luật vận hành

6 Các yêu cầu khác Phụ lục A: Các mô hình phân tích Phụ lục B: TBD - Danh sách sẽ được xác định

Theo dõi phiên bản tài liệu:

- 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

1.5 Tài liệu tham khảo

- Giáo trình Phân Tích Và Thiết Kế Hệ Thống Thông Tin – 08/2008 – Đinh Khắc Quyền & ThS Phan Tấn Tài

- Giáo trình Hệ Quản Trị Cơ Sở Dữ Liệu SQL Sever – Trần Ngân Bình

- Giáo trình Chuyên Đề Ngôn Ngữ Lập trình 1(C#) – Hồ Quang Thái

2 Mô tả tổng quan

2.1 Mô hình hệ thống