« Home « Kết quả tìm kiếm

Công nghệ phần mềm hướng giá trị. Bài toán kiểm định chất lượng phần mềm sử dụng phương pháp hướng giá trị.


Tóm tắt Xem thử

- Các lý thuyết về hệ thống phần mềm.
- 8 1.1 Mô hình lập trình và sửa lỗi (Code and Fix Model.
- 8 1.2 Mô hình thác nƣớc (The Waterfall Model.
- 9 1.3 Mô hình xoắn ốc (The Spiral Model.
- 11 1.4 Mô hình tạo mẫu nhanh (The Rapid ProtoTyping Model.
- Công nghệ phần mềm hƣớng giá trị.
- 16 2.4 Công nghệ phần mềm hƣớng giá trị.
- 17 2.5 Mô hình lý thuyết W.
- Mô hình chất lƣợng.
- 30 3.2 Mô hình phần mềm đáng tin cậy.
- 34 3.3 Chi phí chất lƣợng phần mềm.
- Phƣơng pháp phân tích chất lƣợng theo mô hình hƣớng giá trị.
- 39 1.1.1 Điểm lại chi phí về chất lƣợng phần mềm.
- Mô hình phân tích.
- 44 1.2.2 Mô hình Thành phần.
- 47 1.3 Mô hình thực nghiệm.
- 52 1.4 FrameWork cụ thể ứng dụng mô hình lý thuyết W.
- Đề xuất Mô hình đánh giá chất lƣợng phần mềm, ứng dụng cho Phòng CoreBanking – Trung tâm Công nghệ thông tin Agribank.
- Các bƣớc tiến hành triển khai mô hình đề xuất tại Phòng CoreBanking – Trung tâm CNTT – Agribank.
- Xây dựng module mẫu: Hệ thống thu phí tự động cho các tài khoản trên IPCAS.
- Các ứng dụng sau hệ thống mẫu.
- 66 1.2.1 Hệ thống in phiếu khuyến mại tự động.
- 66 1.2.2 Hệ thống VAMC.
- Hệ thống in phiếu dự thƣởng trong hệ thống IPCAS.
- 57 Bảng 4 : Các trƣờng hợp ví dụ áp dụng cho mô hình đề xuất.
- 69 Bảng 13 : Lợi ích hệ thống in phiếu tự động.
- 74 4 DANH MỤC HÌNH VẼ Hình 1 : Mô hình Code and fix[1.
- 8 Hình 2 : Mô hình thác nƣớc[1.
- 10 Hình 3 : Mô hình xoắn ốc[1.
- 12 Hình 4 : Mô hình tạo mẫu nhanh[1.
- 13 Hình 5: Chuỗi lợi ích theo mô tả của hệ ngữ cảnh hệ thống phần mềm[1.
- 18 Hình 7: Hiệu quả của phần mềm và sự biến động cổ phiếu trong rủi ro[1.
- 24 Hình 10 : Mô hình kết hợp sự phụ thuộc[1.
- 27 Hình 12 : Các lớp mô hình chất lƣợng [2.
- 71 Hình 20 : Mô hình công việc của ngƣời làm trực tiếp.
- Trong quá trình xem xét các tài liệu liên quan đến hệ thống phần mềm có nhiều giả thuyết khác nhau đƣợc sử dụng trong quá trình phát triển hệ thống phần mềm.
- Tuy nhiên một số lý thuyết này còn hạn chế đối với dự toán chi phí, thiếu quan tâm về lợi ích của những bên liên quan trong quá trình phát triển phần mềm.
- Hiện tại, phƣơng pháp mà đề tài nghiên cứu trong phát triển phần mềm là hƣớng trên giá trị.
- Để tài cũng đƣa ra mô hình phần tích lợi ích của các bên liên quan đối với phần mềm, kết nối ngữ cảnh và kết nối giá trị với các bên liên quan, cũng nhƣ đƣa ra một số mô hình về chi phí lợi ích và đánh giá phần mềm dựa trên kết quả lợi ích thu về.
- Mục đích của đề tài (các kết quả cần đạt đƣợc): Mục đích nghiên cứu chính của đề tài nhằm hiểu đƣợc công nghệ phần mềm hƣớng giá trị, tìm hiểu một số mô hình công nghệ phần mềm hƣớng giá trị cũng nhƣ những trƣờng hợp thực hiện thực tiễn của những mô hình trên.
- CÁC LÝ THUYẾT VỀ HỆ THỐNG PHẦN MỀM Xem xét các tài liệu liên quan đến hệ thống phần mềm cho thấy, có nhiều giả thuyết khác nhau đƣợc sử dụng trong quá trình phát triển hệ thống phần mềm.
- Tuy nhiên, những nhận xét này có đƣợc giới hạn trong mô hình lý thuyết vòng đời cung cấp hỗ trợ trong (a) hƣớng dẫn các hoạt động cốt lõi của phát triển và (b) cố gắng một cách rõ ràng để trả lời "làm thế nào tốt nhất để phát triển một hệ thống phần mềm".
- Trong phần tiếp theo chúng ta sẽ xem xét các mô hình vòng đời khác nhau đã tăng lên nhanh chóng trong lĩnh vực hệ thống phần mềm.
- 1.1 Mô hình lập trình và sửa lỗi (Code and Fix Model) Mô hình lập trình và sửa lỗi (thƣờng đƣợc gọi là cách tiếp cận xâm nhập) có lẽ là mô hình bị chỉ trích nhiều nhất trong việc phát triển hệ thống phần mềm do thiếu kỷ luật.
- HÌNH 1 : MÔ HÌNH CODE AND FIX[1] 9 Lập trình và sửa lỗi là: “mô hình cơ bản đƣợc sử dụng trong những ngày đầu của phát triển phần mềm , nó gồm có hai bƣớc sau: (a) Viết một số mã, (b) Sửa chữa các vấn đề trong các mã.
- Sau đó, mô hình 2 bƣớc (lập trình và sửa lỗi) lặp đi lặp lại cho đến khi dự án đƣợc công bố hoàn thành hoặc hủy bỏ.
- Có hai lợi thế quan trọng của việc sử dụng các mô hình lập trình và sửa lỗi.
- Thứ hai, nó đòi hỏi chuyên môn rất ít vì nó không có bất kỳ yêu cầu chính thức cho ứng dụng - bất cứ ai viết phần mềm (mà không sử dụng bất kỳ lý thuyết chính thức khác) là sử dụng lập trình và sửa lỗi theo mặc định.
- Tuy nhiên, mô hình này có phần khó khăn quá.
- Đầu tiên, vì nó không đòi hỏi các giá trị các bên liên quan đƣợc xác định và lý giải rõ ràng, phần mềm kết quả kém có thể không đúng với nhu cầu của các bên liên quan, do đó kết quả là hoàn toàn có thẻ bị bác bỏ phải làm lại.
- Thứ ba, khi không có bất kỳ kế hoạch xác minh và xác nhận, các phần mềm trở nên rất tốn kém để sửa chữa trong các giai đoạn sau .Trong quá trình các lý thuyết của hệ thống phần mềm, lập trình và sửa lỗi có lẽ là lý thuyết đầu tiên, mặc dù tính lý thuyết có thể là ít, nhƣng nó chắc chắn là một thực hành quan sát.
- So với nghiên cứu này, các mô hình lập trình và sửa lỗi là cả giá trị các bên liên quan và các ngữ cảnh bị ngắt kết nối với nhau trong quá trình tiếp cận 1.2 Mô hình thác nƣớc (The Waterfall Model) Mô hình thác nƣớc là một mô hình phát triển phần mềm chuỗi, trong đó phát triển đƣợc xem là chảy dần xuống dƣới (nhƣ một thác nƣớc) thông qua các giai đoạn của phân tích yêu cầu, thiết kế, thực hiện, kiểm tra (xác nhận), tích hợp và bảo trì (Wikipedia.com).
- Mô hình thác nƣớc thƣờng đƣợc gọi là mô hình cổ điển cho việc phát triển hệ thống phần mềm.
- Royce vào năm 1970, nó có lẽ vẫn là quá trình phát triển phần mềm sử dụng rộng rãi nhất, trong dạng này hay dạng khác.
- Mô hình này bắt đầu bằng việc thiết lập các yêu cầu hệ thống và yêu cầu phần mềm và tiếp tục với thiết kế kiến trúc, thiết kế chi tiết, mã hóa, kiểm tra và bảo trì.
- Mô hình thác nƣớc hôm nay tiếp tục phục vụ nhƣ một cơ sở cho nhiều mô hình vòng đời khác .
- HÌNH 2 : MÔ HÌNH THÁC NƯỚC [1] Mô hình thác nƣớc làm việc tốt nhất cho các dự án có một định nghĩa sản phẩm ổn định và các phƣơng pháp kỹ thuật đƣợc tìm hiểu, và nó có hiệu quả nếu các cán bộ dự án là thiếu kinh nghiệm vì nó cung cấp cho dự án với một cấu trúc giúp trong việc giảm thiểu làm lại.
- Tuy nhiên bất lợi cơ bản của mô hình thác nƣớc là nó nhấn mạnh trên các tài liệu xây dựng đầy đủ nhƣ tiêu chuẩn hoàn thiện cho các yêu cầu và giai đoạn thiết kế vào đầu của dự án.
- Cuối cùng là mô hình thác nƣớc đòi hỏi yêu cầu một hệ thống phần mềm đƣợc xác định trƣớc tuy nhiên, khi việc kinh doanh vẫn chỉ xuất hiện trong ý tƣởng sản phẩm đƣợc sử dụng, yêu cầu hệ thống thƣờng xuất hiện trƣớc các chỉ dẫn.
- 11 Để giải quyết một số vấn đề trong mô hình thác nƣớc cổ điển, một số "thác nƣớc sửa đổi" mô hình đã đƣợc đề xuất trong các năm tiếp theo, những sửa đổi đã tập trung vào việc cho phép một số giai đoạn chồng lên nhau, do đó làm giảm các yêu cầu tài liệu và các chi phí quay trở lại giai đoạn trƣớc đó để sửa lại chúng.
- Mặc dù mô hình thác nƣớc nói chung đã bị chỉ trích vì bất lợi của nó, song nó vẫn đƣợc ƣa thích trong giới quản lý nhất định.
- Lý do là mô hình thác nƣớc có đơn giản giải thích và thu hồi, và nó mang lại cho cảm giác kiểm soát, một "trật tự, dự đoán, trách nhiệm, và quá trình, với cột mốc đơn giản tài liệu điều khiển, chẳng hạn nhƣ yêu cầu hoàn thành".
- So với nghiên cứu này, mô hình thác nƣớc ở một mức độ nắm bắt đƣợc giá trị các bên liên quan trong hình thức của một tài liệu yêu cầu.
- Ngoài ra, mô hình thác nƣớc không thực hiện kết nối rõ ràng giữa các giá trị các bên liên quan và các hoạt động phát triển, chẳng hạn nhƣ trong kiến trúc hoặc thử nghiệm.
- Cuối cùng, mô hình thác nƣớc cũng bị ngắt kết nối với ngữ cảnh của nó.
- 1.3 Mô hình xoắn ốc (The Spiral Model) Việc giải quyết những bất cập của mô hình thác nƣớc, đề xuất các mô hình xoắn ốc.
- Ý tƣởng cơ bản của mô hình xoắn ốc là bắt đầu trên một quy mô nhỏ ở giữa cột sống, khám phá những rủi ro, lập kế hoạch để xử lý các rủi ro, và cam kết một cách tiếp cận cho phiên bản kế tiếp, sau khi các rủi ro chính có tất cả đƣợc giải quyết, các mô hình xoắn ốc chấm dứt nhƣ một mô hình vòng đời thác nƣớc.
- Giá trị cốt lõi của mô hình xoắn ốc là quản lý rủi ro, vấn đề lớn có thể đƣợc tìm thấy sớm hơn nhiều trong chu kỳ phát triển.
- Ví dụ, trong mô hình thác nƣớc, thiết kế phần mềm phải đƣợc hoàn tất trƣớc khi xây dựng.
- Với mô hình xoắn ốc, một dự án đƣợc chia thành một tập hợp các rủi ro có hƣớng dẫn quá trình phát triển.
- Mô hình xoắn ốc làm tăng chi phí nhƣng rủi ro giảm, và nếu rủi ro là không thể vƣợt qua, mô hình sẽ cung cấp cho dự án là một dấu hiệu sớm, mà sẽ tiết kiệm thời gian và tiền bạc.
- Tuy nhiên, mô hình này cũng có hai nhƣợc điểm.
- Đầu tiên, nó là phức tạp, đòi hỏi phải có lƣơng tâm, chu đáo, và có kiến thức quản lý, thứ hai, trong nhiều trƣờng hợp, các mô hình xoắn ốc là không dễ phân huỷ thành các cấp độ dần dần tốt hơn các chi tiết trong dự án phát triển phần mềm trong thế giới thực.
- HÌNH 3 : MÔ HÌNH XOẮN ỐC[1] So với nghiên cứu này, mô hình xoắn ốc lặp đi lặp lại cố gắng để nắm bắt giá trị các bên liên quan trong các hình thức của mục tiêu, hạn chế và ƣu tiên, và rủi ro tuy nhiên, nó làm cho không có kết nối rõ ràng với bối cảnh tổ chức.
- 1.4 Mô hình tạo mẫu nhanh (The Rapid ProtoTyping Model) Mô hình tạo mẫu nhanh nhƣ các loại quy trình nhằm giảm sự không chắc chắn yêu cầu thông qua các yêu cầu thay đổi của các khía cạnh của hành vi hệ thống.
- Mô hình tạo mẫu nhanh cho phép các nhà phát triển hệ thống để tạo ra các phần nổi bật nhất của một chƣơng trình nhƣ một mẫu thử nghiệm và sau đó làm việc với ngƣời sử dụng để tinh chỉnh nó cho đến khi các mẫu thử nghiệm là tốt.
- HÌNH 4 : MÔ HÌNH TẠO MẪU NHANH[1] Nhƣ đã đề cập, một trong những vấn đề chính với mô hình thác nƣớc là yêu cầu thƣờng xuyên không đƣợc hiểu rõ trong các giai đoạn phát triển ban đầu.
- Mô hình nguyên mẫu nhanh thay vì phục vụ nhƣ một công cụ hiệu quả để chứng minh rằng một giải pháp đáp ứng một loạt các yêu cầu.
- Ngoài việc làm rõ các yêu cầu, một mô hình nguyên mẫu cũng xác định nhiều lĩnh vực thiết kế cùng một lúc.
- Vì nó có thể làm các bên liên quan thấy rằng có tồn tại một hệ thống làm việc, họ có thể mong đợi một hệ thống hoàn chỉnh sớm hơn là có thể.
- Ngoài ra, sử dụng một mô hình mẫu thƣờng có thể trở thành một ngụy trang cho một chu kỳ phát triển mã và sửa chữa.
- Cuối cùng, nó làm cho nó theo nghĩa đen không thể thực hiện bất kỳ ƣớc tính về chi phí, tiến độ các dự án phát triển hệ thống phần mềm.
- So với nghiên cứu này, các mô hình tạo mẫu nhanh trong khi cố gắng để nắm bắt một số giá trị các bên liên quan thông qua mẫu lặp đi lặp lại, nó làm nhƣ vậy với chi phí từ phụ thuộc nhiều thuộc tính mong muốn khác của một hệ thống phần mềm.
- Ngoài ra, mô hình tạo mẫu nhanh cũng bị ngắt kết nối từ ngữ cảnh của nó.
- CÔNG NGHỆ PHẦN MỀM HƢỚNG GIÁ TRỊ 2.1 Tổng quan các vấn đề Những thiếu sót của thực tiễn hiện tại là gì? Có rất nhiều lý do có thể và giải thích cho một trạng thái ảm đạm của các vấn đề trong phát triển hệ thống phần mềm.
- Thứ hai, thực tiễn hiện tại đang bị ngắt kết nối từ các giá trị liên quan - đó là, có hƣớng dẫn quá trình nhỏ về cách tốt nhất để giải quyết vấn đề giá trị các bên liên quan trong việc cân bằng khi các đặc tính mong muốn (bộ tính năng, bảo mật, dễ sử dụng) của một hệ thống là một trong hai mâu thuẫn, cạnh tranh hoặc phụ thuộc vào nhau cho nguồn lực hạn chế.
- 2.2 Ngắt kết nối ngữ cảnh Phát triển hệ thống phần mềm dựa trên một tập hợp các đặc điểm kỹ thuật chính thức không đảm bảo rằng hệ thống sẽ tạo ra các giá trị dự kiến phù hợp cho các bên liên quan.
- Kết nối rõ ràng giữa hệ thống phần mềm và bối cảnh tổ chức phải thực sự đƣợc xem xét.
- Phƣơng pháp tiếp cận lợi ích thực (Benefits Realization Approach - BRA) là phƣơng pháp để hiển thị nhƣ thế nào các sáng kiến phần mềm phải đƣợc kết nối với bối cảnh tổ chức để thành công trong việc thực hiện các lợi ích mong đợi.
- 15 Hình dƣới cho thấy bối cảnh tổ chức của một hệ thống để xử lý mà công ty đã đặt ra để phát triển đáp ứng những thiếu sót của hệ thống hiện có của nó.
- Sơ đồ này cho thấy một chuỗi lợi ích kết nối một hệ thống phần mềm với bối cảnh của nó bằng cách liên kết các sáng kiến phần mềm hệ thống (ví dụ, thực hiện một hệ thống đơn hàng mới cho bán hàng) để đóng góp (không có hệ thống phân phối, nhƣng nó tác động về hoạt động tồn tại hiện có) và kết quả, mà có thể dẫn đến là tiếp tục đóng góp hoặc gia tăng giá trị (ví dụ, tăng việc bán hàng).
- Nó cũng giúp phát hiện ra các giả định thƣờng ẩn trong bối cảnh tổ chức mà thành công của hệ thống phần mềm phụ thuộc.
- HÌNH 5: CHUỖI LỢI ÍCH THEO MÔ TẢ CỦA HỆ NGỮ CẢNH HỆ THỐNG PHẦN MỀM[1] Bằng cách bao gồm bối cảnh tổ chức, các thành viên dự án một hệ thống phần mềm có thể làm việc với các bên liên quan để xác định hoạt động không phải về phần mềm để bổ sung có thể là cần thiết để nhận ra giá trị của các bên liên quan có liên quan đến các sáng 16 kiến phần mềm hệ thống.
- Ví dụ, các sáng kiến để thực hiện một hệ thống đơn hàng mới có thể làm giảm thời gian cần thiết để xử lý đơn đặt hàng chỉ khi một sáng kiến khác để thuyết phục các nhân viên bán hàng rằng hệ thống mới sẽ tốt cho sự nghiệp của họ và đào tạo họ làm thế nào để sử dụng hệ thống hiệu quả.
- Nếu hệ thống đơn hàng là rất hiệu quả tối ƣu hóa nhƣng nó không theo dõi các khoản tín dụng bán hàng, nhân viên bán hàng sẽ đấu tranh không sử dụng phần mềm đó, để bán hàng để tăng cũng có thể yêu cầu thêm một tính năng để theo dõi các khoản tín dụng bán hàng để ngƣời bán hàng sẽ muốn sử dụng hệ thống mới.
- Hơn nữa, giảm chu trình xử lý đơn hàng sẽ làm giảm thời gian để cung cấp sản phẩm chỉ khi các sáng kiến bổ sung đƣợc đƣa ra kịp thời để phối hợp các hệ thống đơn hàng với hệ thống thực hiện đơn hàng.
- Chuỗi lợi ích là một trong nhiều cách để kết nối với một hệ thống phần mềm với ngữ cảnh của nó.
- 2.3 Ngắt kết nối giá trị các bên liên quan Quyết định về hệ thống phần mềm thƣờng đƣợc thực hiện trong các điều kiện khác nhau về chi phí, tiến độ, chất lƣợng, tính năng, thực hành tốt so với thực tế xấu, kỹ thuật, hoặc phƣơng pháp điều khiển.
- Ví dụ, chấp nhận thử nghiệm thƣờng là bƣớc cuối cùng trong vòng đời phát triển của hệ thống.
- Tuy nhiên, trong một hệ thống phần mềm, chẳng hạn nhƣ một hệ thống xử lý đơn hàng đã đƣợc phát triển để giảm chi phí hoạt động, tăng thị phần, tăng sự hài lòng của khách hàng và sự hài lòng của nhân viên, một thử nghiệm nhƣ vậy sẽ chỉ có nghĩa là phần mềm tuân thủ một số hành vi

Xem thử không khả dụng, vui lòng xem tại trang nguồn
hoặc xem Tóm tắt