... trạng mất vốn ngày càng lớn.Một yếu điểm nữa của thị trường tài chính nước ta là, cơ cấu hệ thống tài chính còn mất cân đối, hệ thống ngân hàng vẫn là kênh cung cấp vốn trung và dài hạn cho ... đại hoá công nghệ ngân hàng và hệ thống thanh toán. Theo TS. Đinh Xuân Hạng, Học viện Tài chính, các ngân hàng thương mại cần tăng mức vốn đầu tư để trang bị kỹ thuật và công nghệ tiên tiến. ... Những điểm yếu của hệ thống ngân hàng ! Việc gia nhập WTO đã mở ra những cơ hội phát triển mới cho thị trường tài chính Việt Nam. Tuy nhiên, bên cạnh đó, đầu tư trong lĩnh vực tài chính - ngân... Show
Yêu cầu sản phẩm là xây dựng trang Web trường học điện tử với các tính năng như Giáo viên quản lý câu hỏi, đề thi; Học sinh tham gia làm bài; Admin duyệt câu hỏi của giáo viên trước khi đăng,... Yêu cầu tiến trình: Phải thực hiện theo mô hình Agile. Sản phẩm cuối cùng bao gồm cả sản phẩm và backlog cho từng Sprint.
1.2. Tiến trình yêu cầu phần mềmVị trí trong mô hình tiến trình
Các nhân tố tham gia
Quản lý và Hỗ trợ quy trình
Chất lượng và cải tiến
1.3. Thu thập yêu cầuLà giai đoạn đầu tiên trong việc xây dựng sự hiểu biết về sản phẩm phần mềm và các vấn đề cần thiết phải giải quyết (ví dụ cần hiểu biết về các chức năng của phần mềm). Đây cũng là giai đoạn mà các bên liên quan (stakeholders) được xác định. Thiết lập các mối quan hệ giữa các nhóm phát triển và khách hàng.
1.3.1. Nguồn yêu cầu - Requirements SourcesCác yêu cầu có rất nhiều nguồn trong đặc thù phần mềm và điều quan trọng là tất cả các nguồn tiềm năng cần được xác minh và đánh giá. Phần này nhằm nâng cao nhận thức của các nguồn khác nhau của yêu cầu phần mềm và những framework để quản lý chúng.
1.3.2. Kỹ thuật thu thập- Elicitation TechniquesMột khi các nguồn yêu cầu được xác định, các kỹ sư phần mềm có thể bắt đầu thu thập thông tin yêu cầu từ chúng. Phần này tập trung vào các kỹ thuật để thu thập các thông tin cần thiết từ các bên liên quan. Các kỹ sư phần mềm cần phải linh hoạt với các sự việc xảy ra ví dụ: người dùng gặp khó khăn trong việc mô tả yêu cầu của họ, có thể thông tin quan trọng không được nói ra hoặc có thể không muốn hoặc không thể hợp tác. Thu thập không phải là hoạt động thụ động, ngay cả khi các bên liên quan sẵn sàng hợp tác các kỹ sư phần mềm phải cố gắng để thu thập thông tin chính xác nhất. Một số kỹ thuật thu thập yêu cầu như:
1.4. Phân tích yêu cầuNhằm mục đích:
1.4.1. Mô hình hóa khái niệmXây dựng các mô hình trong một vấn đề thực tế là chìa khóa của phân tích yêu cầu phần mềm.
1.4.2. Thiết kế kiến trúc và phân bổ yêu cầuThiết kế kiến trúc là điểm mà tại đó quá trình yêu cầu trùng lặp với phần mềm hoặc các hệ thống thiết kế. Trong nhiều trường hợp, các hành vi kỹ sư phần mềm như là kiến trúc sư phần mềm bởi vì quá trình phân tích và xây dựng các yêu cầu đòi hỏi rằng các thành phần kiến trúc / thiết kế đó sẽ chịu trách nhiệm đáp ứng các yêu cầu được xác định. 1.4.3. Đàm phán, giải quyết các xung đột giữa các yêu cầuĐiều này liên quan đến việc giải quyết vấn đề giữa hai yêu cầu của các bên liên quan cùng các tính năng không tương thích, giữa các yêu cầu và nhân lực hoặc giữa yêu cầu chức năng và yêu cầu phi chức năng. Tuy nhiên, thường rất khó khăn để có được thông tin thực. Ngoài ra, các yêu cầu thường phụ thuộc vào nhau, và có ưu tiên tương đối. Trong thực tế, các kỹ sư phần mềm thực hiện các yêu cầu ưu tiên thường xuyên mà không biết về tất cả các yêu cầu. Nó cũng bao gồm một phân tích từ các kỹ sư phần mềm ước tính chi phí thực hiện từng yêu cầu hoặc liên quan đến các yêu cầu khác. 1.4.4. Phân tích hình thức - Formal AnalysisFormal Analysis đã có một tác động trên một số lĩnh vực ứng dụng, đặc biệt là các hệ thống toàn vẹn cao. Các hình thức thể hiện của các yêu cầu đòi hỏi một ngôn ngữ với ngữ nghĩa định nghĩa chính thức (ví dụ: Ngôn ngữ Z). 1.5. Đặc tả yêu cầuĐặc tả yêu cầu là một mô tả của hệ thống phần mềm được phát triển, đưa ra các yêu cầu chức năng và phi chức năng, và có thể bao gồm một tập hợp các ca sử dụng (use cases) để mô tả tương tác giữa người dùng với phần mềm. 1.5.1. Tài liệu đặc tả hệ thống.Còn được biết như là tài liệu yêu cầu người dùng hay là tài liệu vận hành ghi lại những yêu cầu hệ thống. Nó xác định yêu cầu hệ thống ở mức cao với cách nhìn từ domain. Độc giả của tài liệu bao gồm hệ thống người dùng hoặc khác hàng. Vì vậy nội dung của nó phải được diễn đạt bằng những từ ngữ của những lĩnh vực riêng. Tài liệu sẽ liệt kê các yêu cầu hệ thống cùng với các thông tin cơ bản về đối tượng hệ thống, môi trường mục tiêu của nó, giả định và các yêu cầu phi chức năng. 1.5.2. Đặc tả yêu cầu hệ thốngNgười phát triển những dự án phần mềm có những thành phần thuần túy là software và những phần non-software. Ví dụ như máy bay hiện đại thường tách biệt yêu cầu hệ thống với yêu cầu phần mềm. Theo quan điểm này, yêu cầu hệ thống được quy định, các yêu cầu phần mềm có nguồn gốc từ các yêu cầu hệ thống, và sau đó các yêu cầu đối với các thành phần phần mềm được xác định. 1.5.3. Đặc tả yêu cầu phần mềmĐặc tả yêu cầu phần mềm tạo cơ sở cho việc thỏa thuận giữa khách hàng và nhà thầu hoặc các nhà cung cấp về những gì sản phẩm phần mềm có làm việc đúng như mong muốn không. Nó cho phép một đánh giá nghiêm ngặt các yêu cầu trước khi có thể bắt đầu vào việc thiết kế và làm giảm việc thiết kế lại. Nó cũng cần cung cấp một cơ sở thực tế để ước tính giá thành sản phẩm, rủi ro, và lịch trình. 1.6. Thẩm định yêu cầu Tất cả tài liệu yêu cầu cần được thông qua quá trình thẩm định và kiểm duyệt. Vậy Thẩm định yêu cầu là gì? Khái niệm
Các kĩ thuật thẩm định yêu cầu
1.6.1. Xem lại yêu cầuCó lẽ phương tiện phổ biến nhất của việc thẩm định là sự kiểm tra hoặc xem lại các tài liệu yêu cầu. Một nhóm người được giao nhiệm vụ tìm các lỗi, sai sót, thiếu sự rõ ràng, và độ lệch so với tiêu chuẩn. Thành phần của nhóm này đặc biệt quan trọng (ít nhất cần có đại diện khách hàng để có được định hướng đúng đắn), và họ có thể cung cấp sự hướng dẫn trong việc tìm kiếm thông tin chuẩn xác. Việc nhận xét có thể được thành lập sau khi hoàn thành các tài liệu định nghĩa hệ thống, các tài liệu đặc tả hệ thống, đặc tả cơ bản cho 1 phiên bản mới sắp phát hành, hoặc bất kì bước nào khác trong quá trình làm yêu cầu. Ví dụ. Công ty đưa ra 1 tiêu chuẩn chung khi làm tài liệu, các kí hiệu, mô hình đối tượng, cần phải được thống nhất, Nhưng một nhân viên mới vào chưa nắm rõ được các tiêu chuẩn này nên làm sai một số chỗ. Phương pháp xem lại yêu cầu sẽ giúp tìm ra sai sót này giúp đồng nhất trong quá trình viết tài liệu. 1.6.2. Sử dụng phiên bản mẫu, thử nghiệmSử dụng phiên bản mẫu, thử nghiệm là dùng một mô hình chạy được của hệ thống để kiểm tra các yêu cầu. Ưu điểm của phương pháp này nhằm giúp dễ dàng trong việc giải thích những yêu cầu của phần mềm, giúp khách hàng có những phản hồi kịp thời để làm rõ hệ thống đang sai ở đâu, cũng như phát hiện ra những yêu cầu mới. Ví dụ Việc sử dụng mô hình giao diện người dùng (Mockup,..) giúp nguời lập trình cũng như khách hàng dẽ hiểu, tiết kiệm hon việc miêu tả đơn thuần dùng văn bản hoặc mô hình đồ họa. Sự biến động hay sự thay đổi yêu cầu sau khi dùng bản thử nghiệm là rất thấp bởi vì có sự thống nhất giữa người lập trình, khách hàng và các bên liên quan. Bên cạnh những ưu điểm đó, phương pháp dùng phiên bản mẫu cũng có một số nhược điểm như sau. Dùng phiên bản thử nghiệm làm phân tán sự tập trung của người dùng. Ví dụ, Phiên bản mẫu là phiên bản chưa hoàn thiện về mặt thẩm mĩ cũng như chức năng. Điều đó khiến người dùng nhầm tưởng rằng chất lượng sản phẩm có chất lượng không tốt. Dùng phiên bản mẫu có thể tốn kém hơn cho việc phát triển. Ví dụ, khách hàng quá tập trung vào chức năng của phiên bản mẫu sẽ dẫn đến lỗi phát sinh, người làm yêu cầu lại phải sửa lỗi đó. Do đó việc giải thích đây chỉ là bản mẫu, thử nghiệm là đặc biệt quan trọng. vì vậy sẽ tránh lãng phí nguồn nhân lực. 1.6.3. Thẩm định mô hìnhThẩm định model là thẩm định lại chất lượng các model information model, behavior model, structure model) đã được phát triển trong suốt quá trình phân tích. Ví dụ trong mô hình đối tượng, chúng ta phải kiểm tra xem liên kết giữa các đối tượng, giữa sự trao đổi dữ liệu giữa các đối tượng có chuẩn xác không. Các model phải đủ các tiêu chí: Hoàn thiện, nhất quán và chuẩn xác. 1.6.4. Kiểm thử chấp thuậnMột đặc điểm quan trọng của yêu cầu phần mềm là nó có thể kiểm định rằng sản phẩm cuối cùng phải thỏa mãn các yêu cầu. Viết các Test Case dành cho các yêu cầu để kiểm tra khả năng đáp ứng được các yêu cầu end-user. Sản phẩm cuối cùng phải thỏa mãn các Test Case. 1.7. Khảo sát hiện trạngThực trạng có rất nhiều thay đổi, do đó quản lí những thay đổi và duy trì những yêu cầu là chìa khóa quyết định sự thành công của phần mềm. Ví dụ : không phải tổ chức nào cũng có thói quen làm tài liệu cũng như quản lý yêu cầu đặc biệt với những công ty mới thành lập hoặc những công ty có nguồn nhân lực hạn chế. Khi những công ty này mở rộng, số lượng khách hàng trở lên lớn hơn, sản phẩm của họ bắt đầu phát triển, thì lúc này việc tìm lại những yêu cầu và thúc đẩy thêm nhiều tính năng để đáp ứng nhu cầu thị trường và sự thay đổi của môi trường là rất cần thiết. Do đó, tài liệu yêu cầu và quản lí những thay đổi là chìa khóa cho sự thành công của bất kì quá trình yêu cầu nào. 1.7.1. Quản lý thay đổiQuản lý thay đổi là trung tâm của quản lý yêu cầu. Yêu cầu phần mềm luôn luôn thay đổi: Môi trường doanh nghiệp và kĩ thuật thay đổi. Phần cứng mới => giao diện mới. Ví dụ: Màn hình thay đổi, sắc nét hơn nên giao diện cũng phải chăm chút hơn. Luật thay đổi, nhu cầu doanh nghiệp thay đổi => thay đổi chức năng. Ví dụ: Luật doanh nghiệp không cho tiết lộ thông tin người dùng. Do đó hệ thống quản lí user cần phải bảo mật hơn Tài liệu đặc tả chức năng là là gì?SRS là tài liệu được sử dụng để mô tả chi tiết các yêu cầu chức năng và phi chức năng của hệ thống. Tài liệu này sẽ hỗ trợ đưa ra các tính năng của hệ thống hay dùng cho việc đọc hiểu hệ thống của bên thứ ba liên quan đến công ty.
Đặc ta chương trình là gì?Đặc tả là gì
Đặc tả phần mềm là một tài liệu quan trọng, mô tả các chức năng mà phần mềm cần có cũng như các ràng buộc mà phần mềm cần thoả mãn. Tài liệu này được tạo ra từ nhiều nguồn khác nhau như: thông qua các nghiên cứu về nhu cầu sử dụng của người dùng, về các biêủ mẫu, thị trường,....
Trọng phần mềm thì có những loại tài liệu yêu cầu gì?Định nghĩa yêu cầu phần mềm là tất cả những nhu cầu tính năng sản phẩm mà người dùng muốn, bao gồm chức năng, hiệu năng, giao diện,… Các yêu cầu thường xoay quanh 4 nhóm sau: yêu cầu về phần cứng; yêu cầu về phần mềm, yêu cầu về data (dữ liệu) và cuối cùng là những yêu cầu về con người.
Trọng tài liệu đặc ta yêu cầu cần chỉ rõ được những vấn đề gì?Đặc tả yêu cầu phải chỉ rõ được phạm vi của sản phẩm, các chức năng cần có, đối tượng người sử dụng và các ràng buộc khi vận hành sản phẩm. Có nhiều chuẩn khác nhau trong xây dựng tài liệu, dưới đây là một định dạng RSR thông dụng (theo chuẩn IEEE 830-1984).
|