ĐẠ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. Giới thiệu 1.1. Mục đích:
Định nghĩa các bước , các pha , mô tả cách quản lí cấu hình và quản lí những thay đổi như thế nào trong quá trình phát triển dự án.
1.2. Phạm vi:
Áp dụng cho những thành viên tham gia dự án phải thực hiện đúng theo yêu cầu của bản kế hoạch đề ra.
1.3. Thuật ngữ:
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
Thuật ngữ Định nghĩa
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.
Tag Là một ghi chú được kết hợp với một phiên bản đặt biệt của 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. - Tài liệu đặc tả.
- Tài liệu thiết kế. - Cơ sở dữ liệu. - Mã nguồn.
- 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:
STT Sự kiện Ghi chú
1 Điền vào mẫu Thành viên nào muốn thay đổi mẫu cấu hình cần:
Đ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.
2 Đăng ký mẫu Thành viên nào muốn thay đổi mẫu cấu hình cần:
Đăng ký bảng mẫu thay đổi cho nhà quản lý hỗ trợ. Nhà quản lý hỗ trợ phải:
Thông báo đến tất cả thành viên của hội đồng quản lý thay đổi về yêu cầu thay đổi của thành viên đó.
3 Xem xét nếu 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ú
1 Xem xét yêu 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. 2 Chấp nhận hoặc
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.
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:
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.
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. 1.3. Phạm vi sản phẩm
- Nhằm tin học hóa hệ thống quản lý khách hàng mua bảo hiểm trong một công ty bảo hiểm, 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 tích hợp vào hệ thống vốn có. Quản lý trong phạm vi khách hàng của công ty.
- Chương trình có các chức năng cơ bản như sau: tìm kiếm, thống kê, cập nhật và báo cáo…
1.4. Bảng chú giải thuật 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
- Đây là hệ thống độc lập tích hợp vào hệ thống vốn có. Quản lý trong phạm vi khách hàng của công ty bảo hiểm.
- Sau đây là lưu đồ chỉ ra các thành phần chính của hệ thống:
2.2. Các chức năng của sản phẩm - Quản lý Đại lý:
+ Thêm mới Đại lý
+ Xóa Đại lý
+ Chỉnh sửa thông tin Đại lý
+ Xem danh sách Đại lý
+ Tra cứu danh sách Đại lý
- Quản lý thông tin nhân viên quản lý:
+ Thêm mới nhân viên
+ Xóa nhân viên
+ Chỉnh sửa thông tin nhân viên
+ Xem danh sách nhân viên
+ Tra cứu danh sách nhân viên
+ Thống kê nhân viên - Quản lý Ấn chỉ : + Ấn chỉ xuất + Ấn chỉ thu. - Quản lý hợp đồng: + Thêm mới hợp đồng + Xóa hợp đồng + Sửa hợp đồng. + Xem danh sách hợp đồng. + Tra cứu hợp đồng. + Thống kê hợp đồng. - Quản lý Khách hàng: + Thêm mới Khách hàng. + Xóa Khách hàng. + Sửa Khách hàng. + Xem danh sách Khách hàng. + Tra cứu Khách hàng. + Thống kê Khách hàng. - Quản lý quyển số.
+ Thêm mới quyển số. + Xóa quyển số. + Sửa quyển số.
+ Xem danh sách quyển số - Thống kê doanh thu Đại lý
- Thống kê giấy chứng nhận bảo hiểm hết hạn. 2.3. Người sử dụng:
Nhóm nhân viên: Chỉ được xem và tra cứu thông tin của Khách hàng, Đại lý, Ấn chỉ, hợp đồng.
Nhóm giám đốc: Được toàn quyền sử dụng hệ thống nhưng chủ yếu là xem với tra cứu, nếu có việc liên quan đến chỉnh sửa hệ thống thì giám đốc tác động đến Nhân viên quản lý. 2.4. Môi trường vận hành:
- Chương trình phải chạy được trên nền tảng windows mọi phiên bản. - Máy phải cài chương trình .Net Framework 3.5
- Sử dụng hệ quản trị cơ sở dữ liệu SQL server 2008. - Ngôn ngữ lập trình C#.
- Máy sử dụng chip Pentium III 600 MHZ trở lên, RAM tối thiểu 256 MB(cấu hình đề nghị 512 MB RAM). Ổ cứng còn trống tối thiểu 2.5GB.
2.5. Các ràng buộc về thực thi và thiết kế - Ngôn ngữ lập trình C# phiên bản 2010. - Hệ quản trị cơ sở dữ liệu SQL sever 2008. - Giao diện hiện toàn màn hình
2.6. Các giả định và phụ thuộc
- Các yếu tố có thể làm ảnh hưởng đến quá trình phát triển phần mềm:
- Nhóm phát triển phần thu thập thông tin của giảng viên không đến nơi đến chốn, dẫn đến chương trình thiếu chức năng.
- Cá nhân thực hiện, chương trình mang tính chủ quan. 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
Các thiết bị hỗ trợ trong việc xuất báo cáo ra giấy là máy in. 3.3. Giao tiếp phần mềm
- Phần mềm sử dụng ngôn ngữ lập trình C# phiên bản 2010. - Hệ quản trị cơ sở dữ liệu SQL Sever 2008.
- Hệ điều hành Windows mọi phiên bản. 3.4. Giao tiếp truyền thông tin
Phần mềm desktop, không sử dụng mạng. 4. Các tính năng của hệ thống
4.1. Tính năng quản lý đại lý 4.1.1. Thêm mới Đại lý
4.1.1.1. Mô tả và mức ưu tiên:
Tính năng này có độ ưu tiên cao. Người sử dụng phải nhập vào sau mỗi đợt thêm đại lý mới.
4.1.1.2. Tác nhân/Chuỗi đáp ứng
Người dùng phải vào phần quản lý đại lý, nhập đầy đủ thông tin trên chương trình để lưu vào cơ sở dữ liệu.
Mã yêu cầu: TTTĐL1
Tên yêu cầu: Tính năng thêm đại lý Đối tượng sử dụng: Giám đốc
Tiền điều kiện: Phải đăng nhập thành công vào hệ thống người dùng admin. Cách xử lý:
Bước 1:
Nhập thông tin của đại lý. Không để trống ô mã đại lý. Bước 2:
Nhấn nút lưu. Chương trình sẽ kiểm tra xem bạn có nhập đầy đủ các thông tin bắt buộc như: mã đại lý, họ tên giám đốc đại lý, CMND chưa. Nếu rồi thì lưu vào hệ thống. Nếu