j. Mô hình hoá CSDL
1.9.2. Quy trình thu thập vết yêu cầu
Việc thu thập thông tin vết không phải diễn ra sau khi hệ thống đã hoàn thành mà phải diễn ra liên tục và tuần tự trong quá trình phát triển phần mềm.
Có nhiều giai đoạn thu thập thông tin khác nhau nhưng trong một vòng lặp của RUP bao gồm trong 4 giai đoạn chính đưa ra thông tin vết yêu cầu:
- Thiết kế và thực thi - Kiểm thử
Hình 3-23 3-24: Quy trình vết yêu cầu
DP: điểm mô rả (Descision Point) MS: Giai đoạn (Milestone)
•Thu thập yêu cầu
Chúng ta không có một quy trình quản lý yêu cầu tách biệt nhưng trong thực tế các yêu cầu được quản lý ở mức trung tâm của quy trình phát triển dự án. Trong yêu cầu dự án phát triển thông qua 4 quy trình được đề cập sớm và thay đổi thủ tục quản lý. Quy trình đưa ra các yêu cầu bắt đầu từ kỹ thuật yêu cầu trong dự án phát triển bằng việc tập hợp các yêu cầu khách hàng đang được bắt đầu. Các yêu cầu kỹ thuật sẽ được tập hợp lại cùng với quy trình trọng tâm của hệ thống. Đầu ra của quy trình lưu lại yêu cầu được đưa ra trong cập hợp các yêu cầu và mô hình yêu cầu của dự án. Đầu ra khác của quy trình yêu cầu được tự động và sắp xếp đưa ra và giới thiệu như Pre-RT được tạo có sẵn bởi tập các yêu cầu.
Tập các yêu cầu bao gồm các trường thông tin như : nhóm, ID, mô tả, ngày, mã nguồn, giai đoạn, đặc tính, trạng thái của yêu cầu và các notes. Tập các yêu cầu được đưa ra tương tự như việc chi tiết và đặc tả yêu cầu phần mềm.[Leino K. 2000]
• Khỏi quát hệ thống
Khỏi quát hệ thống đượcđuợc bắt đầu trong suốt quy trình đưa ra yêu cầu. Mục đích của quy trình này để phân tích các đặc tính của sản phẩm phần mềm dựa trên các yêu cầu được đưa ra.
Mục đích của quy trình này là đưa ra kiến trúc thích hợp cho phần mềm và phân tích cả các giao tiếp của hệ thống đang tồn tại và đặc tính của các yêu cầu sử dụng các giải pháp kỹ thuật được chọn. Các yêu cầu chính được phân tích và văn bản đề xuất thực thi kỹ thuật là đầu ra của quy trình này. Văn bản phân tích yêu cầu ưu tiên các use-case và cỏc yờu cầu từ các kỹ thuật, kịch bản mô hình khái niệm, ánh xạ trực tiếp và các yêu cầu được thêm vào. Văn bản đề xuất thực thi kỹ thuật khái quát các yêu cầu phi chức năng như dung lượng, vấn đề kỹ thuật, vấn đề bảo mật… [12Kataikko 2000]
Trước khi kết thúc việc khái quát hệ thống sẽ bắt đầu thiết kế và thực thi. Việc thiết kế và thực thi chia thành 2 giai đoạn: giai đoạn thiết kế và giai đoạn thực thi.
Before ending the system concept process starts the design and implementation process. The design and implementation process is divided into two phases: the design phase and the implementation phase. The purpose of the design phase is to carry out previously defined requirements, to produce sufficient documentation for the implementation of software, and to define tools and methods used during implementation. The goal is to extend the architecture description from system level to software level and define detailed technical specifications (TS) for each software module. Sufficient documentation means TS documents,
Mục đích của giai đoạn thiết kế là để đưa ra các yêu cầu được định nghĩa trước đó và tạo văn bản cho việc thực thi phần mềm và để định nghĩa công cụ và phương thực được sử dụng trong suốt quá trình thực thi. Mục đích là để mở rộng mô tả kiến trúc từ mức hệ thống và định nghĩa đặc tả kỹ thuật chi tiết (Technical Specification- TS) cho mỗi module phần mềm. Việc tạo văn bản hoá có nghĩa là các văn bản TS, mô tả sản phẩm, kế hoạch bảo mật và văn bản giao tiếp người sử dụng.
Trong thực tế, các văn bản TS của dự án như sau : TS chính, TS module, TS lưu trữ dữ liệu, văn bản TS O&M ( thực thi và bảo trì), và TS xác định phương hướng. Trong suốt giai đoạn thực thi, phần mềm được thực hiện theo các đầu ra từ giai đoạn thiết kế. Sự thực thi bao gồm việc lập trình, kiểm thử module, tích hợp hệ thống theo kế hoạch dự án và các văn bản cần thiết. Quy trình này được đưa ra để tìm lỗi trong quá trình tích hợp và kiểm thử tích hợp. Thực tiễn của thiết kế được tiến hành sau trong suốt quá trình thực thi. Văn bản đặc tả được cập nhật trong suốt quy trình và những thay đổi lớn được đưa ra thông qua thủ túc quản lý thay đổi. Các đầu ra của giai đoạn thực thi được đưa vào dự án. Xây dựng các notes, các module kiểm thử, cập nhật văn bản TS và cập nhật mô tả sản phẩm [13]. [Ovaska 2000]
• Kiểm thử
Kiểm thử bắt đầu bằng việc định nghĩa chiến lược kiểm thử và viết test-case và việc kiểm thử được bắt đầu ngay sau khi thiết kế và thực thi cho ra những sản phẩm công việc để kiểm thử.
Trong EA, quy trình kiểm thử được đưa ra trong mô hình Test Model. Mô hình Test Model mô tả kịch bản test ứng với từng phần tử trong các mô hình khác nhau từ yêu cầu, các trường hợp sử dụng use-case, các lớp class.
Mục đích của quy trình kiểm thử là cải tiến các yêu cầu được chi tiết hoá và tạo văn bản. Việc kiểm thử dựa trên đầu vào khác nhau củaảu quy trình khỏc. Cỏc đầu vào này là kế hoạch dự án, các yêu cầu kỹ thuật, môo tả khái niệm dịch vụ, mẫu thử, các lưu ý và các cuộc thảo luận với các thành viên dự án. Đầu ra của kiểm thử là kế hoạchhợch kiểm thử (các đặc tả kiểm thử, test suites, mô tả môi trường kiểm thử) và báo cáo kiểm thử (báo cáo kết quả, báo cáo lỗi kiểm thử). Việc kiểm thử chứng nhận rằng tất cả các yêu cầu được thực thi như kế hoạch [14]. [Ylimäki 1999]