User Tag List

+ Trả lời chủ đề
Trang 1/2 12 CuốiCuối
Hiện kết quả từ 1 tới 10 của 11

Chủ đề: Tổng quan các mô hình phát triển phần mềm

  1. #1
    Quân Nhân Danh Dự
    Tham gia ngày
    Jan 2004
    Bài gửi
    1.404

    Mặc định Tổng quan các mô hình phát triển phần mềm

    Đây là một bài viết khá thú vị dành cho những người muốn tìm hiểu xem phần mềm được phát triển như thế nào. Chỉ tiếc là PCWorld không có nhiều bài như thế này

    -----------------------------------------------------------------------------------------------------
    Nguồn: Thế Giới Vi Tính A số tháng 8/2005, trang 106
    Thực hiện: Cao Đại Ân, Global CyberSoft Vietnam
    www.pcworld.com.vn
    -----------------------------------------------------------------------------------------------------

    Cũng như mọi ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án.

    Có thể nói qui trình phát triển/xây dựng phần mềm (Software Development/Engineering Process - SEP) có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất cao, điều này có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần mềm củng cố và phát triển cùng với nền công nghiệp phần mềm đầy cạnh tranh.

    Bài viết phần nào giúp bạn quyết định lựa chọn mô hình thích hợp khi xây dựng qui trình phát triển phần mềm chung cho cấp tổ chức hay cấp dự án.

    Qui trình là gì?


    Qui trình có thể hiểu là phương pháp thực hiện hoặc sản xuất ra sản phẩm. Tương tự như vậy, SEP chính là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm.



    Thông thường một qui trình bao gồm những yếu tố cơ bản sau:

    • Thủ tục (Procedures)

    • Hướng dẫn công việc (Activity Guidelines)

    • Biểu mẫu (Forms/templates)

    • Danh sách kiểm định (Checklists)

    • Công cụ hỗ trợ (Tools)

    Với các nhóm công việc chính:

    • Đặc tả yêu cầu (Requirements Specification): chỉ ra những “đòi hỏi” cho cả các yêu cầu chức năng và phi chức năng.

    • Phát triển phần mềm (Development): tạo ra phần mềm thỏa mãn các yêu cầu được chỉ ra trong “Đặc tả yêu cầu”.

    • Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất ra đáp ứng những “đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”.

    • Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của khách hàng.

    Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình khác nhau. Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng.
    Lần sửa cuối bởi Nistelrooy; 07-12-2005 lúc 01:13 AM

  2. #2
    Quân Nhân Danh Dự
    Tham gia ngày
    Jan 2004
    Bài gửi
    1.404

    Mặc định

    Các mô hình SEP

    Mô hình SEP còn được gọi là chu trình hay vòng đời phần mềm (SLC - Software Life Cycle). SLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm. Có khá nhiều mô hình SLC khác nhau, trong đó một số được ứng dụng khá phổ biến trên thế giới:

    Các mô hình một phiên bản (Single-version models)

    • Mô hình Waterfall (Waterfall model)

    • Mô hình chữ V (V-model)

    • Các mô hình nhiều phiên bản (Multi-version models)

    • Mô hình mẫu (Prototype)

    • Mô hình tiến hóa (Evolutionary)

    • Mô hình lặp và tăng dần (Iterative and Incremental)

    • Mô hình phát triển ứng dụng nhanh (RAD)

    • Mô hình xoắn (Spiral)

    Mô hình Waterfall


    Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau như được mô tả trong Hình 1.



    Hình 1: Mô hình water fall

    Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án.

    Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây là chính là cầu nối giữa “đòi hỏi” (“What”) và mã (Code) được hiện thực để đáp ứng yêu cầu đó.

    Hiện thực và kiểm thử từng thành phần (Coding and Unit Test): là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”.

    Kiểm thử (Test): giai đoạn này sẽ tiến hành kiểm thử mã (code) đã được hiện thực, bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.

    Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt, cấu hình và huấn luyện khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống).

    Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những giai đoạn trước và phải quay lại để sửa chữa. Đây chính là kiểu waterfall dạng lặp (Iterative Waterfall) và được minh hoạ trong Hình 1.

    Mô hình chữ V

    Trong mô hình Waterfall, kiểm thử được thực hiện trong một giai đoạn riêng biệt. Còn với mô hình chữ V, toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau: phát triển và kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng như được minh họa trong Hình 2.




    Hình 2: V model


    Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song với các hoạt động phân tích và thiết kế hệ thống.

    Mô hình mẫu

    Mô hình mẫu (prototype) được minh hoạ trong Hình 3. Trong đó, qui trình được bắt đầu bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả phía phát triển lẫn khách hàng nhằm định ra mục tiêu tổng thể của hệ thống phần mềm sau này, đồng thời ghi nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ.



    Hình 3: Mô hình mẫu

    Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống phần mềm. Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội ngũ phát triển thông hiểu hơn những gì cần được phát triển. Tiếp theo sau giai đoạn làm prototype này có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác.

    Chú ý, prototype thường được làm thật nhanh trong thời gian ngắn nên không được xây dựng trên cùng môi trường và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự sau này. Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó.
    Lần sửa cuối bởi Nistelrooy; 07-12-2005 lúc 01:14 AM

  3. #3
    Quân Nhân Danh Dự
    Tham gia ngày
    Jan 2004
    Bài gửi
    1.404

    Mặc định

    Mô hình tiến hóa

    Mô hình này thực sự cũng là một dạng dựa trên mô hình mẫu, tuy nhiên có sự khác biệt:

    • mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau.

    • những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng trong những phiên bản sau.

    Hình 4 minh họa mô hình tiến hóa, cho thấy một số phần của hệ thống phần mềm có thể đuợc xây dựng sớm ngay từ giai đoạn thực hiện phân tích yêu cầu và thiết kế.



    Hình 4: Mô hình tiến hóa

    Mô hình lặp và tăng dần


    Mô hình lặp và tăng dần có lúc được hiểu là một. Tuy nhiên, trong bài viết này, ta có thể phân biệt ít nhiều sự khác biệt.

    Trước tiên, hai mô hình này đều có điểm giống nhau là đều dựa trên tinh thần của mô hình tiến hóa, và có thêm đặc điểm nhắm đến việc cung cấp một phần hệ thống để khách hàng có thể đưa vào sử dụng trong môi trường hoạt động sản xuất thực sự mà không cần chờ cho đến khi toàn bộ hệ thống được hoàn thành (trong mô hình mẫu hay tiến hóa, các phiên bản mẫu hay trung gian đều không nhắm đến đưa vào vận hành thực sự cho khách hàng, trừ phiên bản cuối cùng). Để khách hàng có thể sử dụng, mỗi phiên bản đều phải được thực hiện như một qui trình đầy đủ các công việc từ phân tích yêu cầu với khả năng bổ sung hay thay đổi, thiết kế, hiện thực cho đến kiểm nghiệm và có thể xem như một qui trình (chu trình) con. Các chu trình con có thể sử dụng các mô hình khác nhau (thông thường là waterfall). Hình 5 minh họa hai mô hình này, trong đó mỗi chu trình con là một waterfall nhỏ.



    Hình 5

    Mục tiêu của phiên bản đầu tiên là phát triển phần lõi và nhóm các chức năng quan trọng. Sau mỗi phiên bản được đưa vào sử dụng, các kết quả đánh giá sẽ được phản hồi và lập kế hoạch cho chu trình con của phiên bản tiếp theo để thực hiện:

    • Những thay đổi cho phiên bản trước đó nhằm đáp ứng nhu cầu khách hàng tốt hơn

    • Có thể thêm những chức năng hoặc đặc điểm bổ sung

    • Sự khác nhau giữa hai mô hình tăng dần và lặp có thể được hiểu đơn giản như sau (so với sản phẩm được hoàn thành trong chu trình con trước):

    • Mô hình tăng dần (Incremental): thêm chức năng vào sản phẩm (xem minh hoạ Hình 6).

    • Mô hình lặp (Iterative): thay đổi sản phẩm (xem minh họa Hình 6)

    • Một SEP có thể kết hợp cả hai mô hình lặp lẫn tăng dần, chẳng hạn RUP (Rational Unified Process).



    Hình 6: 2 Mô hình phát triển
    Lần sửa cuối bởi Nistelrooy; 07-12-2005 lúc 01:33 AM

  4. #4
    Quân Nhân Danh Dự
    Tham gia ngày
    Jan 2004
    Bài gửi
    1.404

    Mặc định

    Mô hình phát triển nhanh

    Mô hình phát triển nhanh (RAD - Rapid Application Development) chính là mô hình tăng dần với chu kỳ phát triển cực ngắn. Để đạt được mục tiêu này, RAD dựa trên phương pháp phát triển trên cơ sở thành phần hóa hệ thống cùng với việc tái sử dụng các thành phần thích hợp. RAD thích hợp cho những hệ thống quản lý thông tin.

    Mô hình xoắn


    Mô hình này được xây dựng bởi Barry Boehm, đặt trọng tâm phân tích rủi ro và xem xét kế hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên bản chất của mô hình lặp.

    Trong mô hình này, việc phân tích và giải quyết những vấn đề có rủi ro cao tập trung vào thiết kế từng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung chung.

    Hình 7 minh họa mô hình này với các giai đoạn lặp theo chu kỳ xoay vòng, trong đó mỗi chu kỳ bao gồm 4 giai đoạn con như sau:

    1. Xác định mục tiêu chất lượng cho sản phẩm được thực hiện, đồng thời xác định sự lựa chọn mua, tái sử dụng hay tự thiết kế và hiện thực các thành phần của hệ thống.

    2. Phân tích sự lựa chọn và các rủi ro có thể xảy ra. Việc này được thực hiện bởi nhiều hoạt động khác nhau thông qua làm mẫu hay mô phỏng.

    3. Phát triển và kiểm định sản phẩm ở mức tiếp theo dựa trên kết quả định hướng được chỉ ra trong giai đoạn con số 2 (phân tích rủi ro)

    4. Kiểm duyệt tất cả các kết quả của các giai đoạn con xảy ra trước đó và lập kế hoạch cho chu kỳ lặp tiếp theo.



    Hình 7: Mô hình xoắn
    Lần sửa cuối bởi Nistelrooy; 07-12-2005 lúc 01:16 AM

  5. #5
    Quân Nhân Danh Dự
    Tham gia ngày
    Jan 2004
    Bài gửi
    1.404

    Mặc định

    SO SÁNH CÁC MÔ HÌNH

    Bài này xin được tiếp tục nêu lên những ưu và nhược điểm của mỗi mô hình để giúp bạn có thể lựa chọn mô hình phù hợp cho dự án phần mềm của mình.

    Mô hình Waterfall


    Ưu điểm:

    Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng. Mô hình này cơ bản dựa trên tài liệu nhất là trong các giai đoạn đầu, đầu vào và đầu ra đều là tài liệu.

    Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động xây dựng phần mềm theo trình tự rõ ràng.

    Nhược điểm:

    Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án. Nhưng đa số dự án thực tế cho thấy yêu cầu phần mềm thường ẩn chứa không nhiều thì ít những điểm không chắc chắn.

    Một thực tế là các dự án hiếm khi được thực hiện đầy đủ các bước trong suốt chu kỳ dự án. Đặc biệt là giai đoạn kiểm thử khi gần đến ngày giao hàng chẳng hạn, nếu có trục trặc xảy ra do yêu cầu phần mềm không rõ ràng hay thiết kế có lỗi, xu hướng là mã nguồn được sửa đổi trực tiếp mà không qua các bước bổ sung theo đúng mô hình, nên dẫn đến bản đặc tả phần mềm cũng như một số sản phẩm trung gian khác như bản thiết kế, cho dù có được cập nhật sau này cũng có thể không phản ánh đầy đủ những gì đã được sửa đổi trong mã nguồn.

    Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn trung gian từ thiết kế cho đến kiểm thử. Đặc biệt với những dự án lớn, người sử dụng chỉ có thể nhận ra rằng hệ thống phần mềm không phù hợp cho nhu cầu của họ vào thời điểm cuối dự án.

    Nói chung, mô hình này thường ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng (được minh họa trong hình 1) và chi phí để sửa chữa có thể rất cao.

    Ứng dụng:


    Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi, thường xuất phát từ sản phẩm đã đạt mức ổn định.

    Yêu cầu mới bổ sung (nếu có) cũng sớm được xác định rõ ràng, đầy đủ từ đầu dự án.

    Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có nhiều kinh nghiệm với các công nghệ được dùng để phát triển sản phẩm.

    Dự án được xác định hầu như không có rủi ro.

    Mô hình chữ V

    Ưu điểm:

    Các hoạt động kiểm thử được chú trọng và thực hiện song song với các hoạt động liên quan đến đặc tả yêu cầu và thiết kế. Hay nói cách khác, mô hình này khuyến khích các hoạt động liên quan đến kế hoạch kiểm thử được tiến hành sớm trong chu kỳ phát triển, không phải đợi đến lúc kết thúc giai đoạn hiện thực.

    Nhược điểm:

    Giống mô hình waterfall

    Ứng dụng:

    Tham khảo mô hình waterfall.

    Mô hình mẫu


    Ưu điểm:

    Người sử dụng sớm hình dung ra chức năng và đặc điểm của hệ thống.

    Cải thiện sự liên lạc giữa nhà phát triển và người sử dụng.

    Nhược điểm:

    Khi mẫu (prototype) không chuyển tải hết các chức năng, đặc điểm của hệ thống phần mềm thì người sử dụng có thể thất vọng và mất đi sự quan tâm đến hệ thống sẽ được phát triển.

    Prototype thường được làm nhanh, thậm chí vội vàng, theo kiểu "hiện thực - sửa" và có thể thiếu sự phân tích đánh giá một cách cẩn thận tất cả khía cạnh liên quan đến hệ thống cuối cùng.

    Nói chung mô hình này vẫn chưa thể cải thiện được việc loại trừ khoảng cách giữa yêu cầu và ứng dụng cuối cùng.

    Ứng dụng:

    Hệ thống chủ yếu dựa trên giao diện người dùng (GUI)

    Khách hàng, nhất là người sử dụng cuối, không thể xác định rõ ràng yêu cầu.

    Mô hình tiến hóa


    Ưu điểm:

    Chú trọng việc tái sử dụng mẫu. Một phần của hệ thống có thể được phát triển ngay trong các giai đoạn phân tích phát triển yêu cầu và thiết kế.

    Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ của dự án.

    Nhược điểm:

    Làm chậm quá trình phát triển yêu cầu và có thể ảnh hưởng sự chú ý đến các công việc trung gian như kiểm tra mã nguồn, thực hiện kiểm thử cấp thấp...

    Dễ dẫn đến kết cấu của hệ thống kém.

    Thường thì với mô hình này, tính chặt chẽ, minh bạch của qui trình kém.

    Ứng dụng:


    Hệ thống tương tác nhỏ và vừa; phần GUI của những hệ thống lớn; những hệ thống cần chu kỳ phát triển ngắn.

    Đội ngũ phát triển không quen thuộc với lĩnh vực của dự án.
    Lần sửa cuối bởi Nistelrooy; 07-12-2005 lúc 01:18 AM

  6. #6
    Quân Nhân Danh Dự
    Tham gia ngày
    Jan 2004
    Bài gửi
    1.404

    Mặc định

    Mô hình lặp và tăng dần

    Ưu điểm:

    Giảm rủi ro sớm trong chu kỳ phát triển phần mềm. Những yêu cầu quan trọng thường được phát triển và chuyển đến người sử dụng sớm.

    Phản hồi của nguời sử dụng về những vấn đề phát sinh trong phiên bản trước được dùng để cải tiến và ngăn ngừa những vấn đề tương tự xảy ra trong những phiên bản tiếp theo.

    Nhược điểm:

    Tổng chi phí lập kế hoạch phát triển cho toàn hệ thống có thể cao hơn. Lưu ý, ở đây chỉ đề cập chi phí lập kế hoạch ban đầu, không bao gồm tất cả chi phí phát sinh. Trong thực tế, nếu ứng dụng hợp lý, toàn bộ chi phí và thời gian cho đến khi sản phẩm được nghiệm thu có thể thấp hơn so với mô hình khác.

    Các yêu cầu về kế hoạch và hoạt động trong qui trình cụ thể sẽ phức tạp hơn.

    Ứng dụng:

    Mô hình lặp:

    Đội ngũ phát triển quen thuộc với lĩnh vực dự án nhưng không có nhiều kinh nghiệm, nhất là về công nghệ được dùng phát triển dự án.

    Có nhiều rủi ro về mặt kỹ thuật

    Mô hình tăng dần:


    Rủi ro được phân tích và xác định ngay từ đầu.

    Giao tiếp giữa các module cũng được xác định rõ ràng từ đầu.

    Đội ngũ phát triển quen thuộc với lĩnh vực của dự án và có nhiều kinh nghiệm.

    Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khai sớm một số phần của hệ thống.

    Mô hình phát triển nhanh

    Ưu điểm:

    Cho phép giảm thời gian phát triển các ứng dụng CSDL và có nhiều giao diện người dùng hay tích hợp các thành phần có sẵn.

    Người sử dụng sẽ tham gia vào các hoạt động kiểm thử.

    Nhược điểm:

    Khó có sự nhất quán giữa những thành phần được phát triển bởi các nhóm khác nhau.

    Không phù hợp cho những ứng dụng đòi hỏi hiệu suất vì thường phụ thuộc vào sự hỗ trợ của môi trường phát triển và ngôn ngữ cấp cao.

    Ứng dụng:

    Hệ thống quản lý thông tin kiểu những ứng dụng dựa trên GUI và CSDL.

    Có sự hỗ trợ của công cụ hay sử dụng ngôn ngữ cấp cao.

    Hệ thống không yêu cầu khắt khe về hiệu suất.

    Mô hình xoắn

    Ưu điểm:


    Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi “spiral” để tăng mức độ tin cậy của dự án.

    Kết hợp những tính chất tốt nhất của mô hình waterfall và tiến hóa.

    Cho phép thay đổi tùy theo điều kiện thực tế dự án tại mỗi “spiral”.

    Đây chính là mô hình tổng quát nhất, tất cả các mô hình khác đều có thể xem là một hiện thực của mô hình tổng quát này, hay cũng có thể xem nó là mô hình tổng hợp các mô hình khác. Đặc biệt, nó được ứng dụng không chỉ trong phát triển phần mềm mà còn trong phát triển phần cứng.

    Nhược điểm:

    Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro.

    Cần có kỹ năng tốt về phân tích rủi ro.

    Ứng dụng:

    Dự án lớn có nhiều rủi ro hay sự thành công của dự án không có được sự đảm bảo nhất định; những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống hỗ trợ
    quyết định.

    Đội ngũ thực hiện dự án có khả năng phân tích rủi ro.

    Trên đây là một số so sánh giữa các mô hình, thực sự việc lựa chọn cụ thể mô hình nào không phải dễ dàng và trên thực tế người ta thường dùng mô hình lai, kết hợp một số mô hình với nhau sao cho phù hợp với dự án.

    Việc cải tiến các mô hình phát triển phần mềm luôn là đề tài nghiên cứu hấp dẫn, với sự tham gia tích cực không những từ các nhà sản xuất phần mềm mà còn từ các viện đại học khắp thế giới. Riêng với các nhà phát triển phần mềm, họ luôn cố gắng cải tiến liên tục qui trình phát triển của mình nhằm không ngừng đổi mới, nâng cao năng suất và chất lượng sản phẩm. Tuy nhiên, một điều dễ thấy là việc lựa chọn, tùy biến mô hình phù hợp cho các dự án đã khó, nhưng việc vận hành nó vào trong quá trình phát triển sản phẩm càng khó hơn. Đó chính là thách thức cho các nhà phát triển phần mềm.



    Hình 8: Rủi ro tồn tại cho đến gần cuối dự án.
    Lần sửa cuối bởi Nistelrooy; 07-12-2005 lúc 01:20 AM

  7. #7
    Quân Nhân Danh Dự
    Tham gia ngày
    Jan 2004
    Bài gửi
    1.404

    Mặc định

    SEP, ISO, CMM/CMMI

    Phần này sẽ không đi sâu vào tìm hiểu các mô hình phát triển phần mềm mà chỉ cung cấp một cái nhìn tổng quát về chúng, cũng như mối quan hệ giữa SEP với ISO và CMM/CMMI.

    Vấn đề được đặt ra là làm thế nào cải tiến qui trình để cải thiện chất lượng và năng suất? Câu trả lời chính là qui trình khung (Process Framework - PF). PF sẽ chỉ ra những yêu cầu mà một qui trình phải đáp ứng tùy theo mỗi mức độ. PF không chỉ ra bất kỳ một qui trình cụ thể nào mà chỉ đưa ra những yêu cầu ở mỗi mức độ trưởng thành khác nhau của qui trình phải đạt được. Đây chính là những hướng dẫn cho các hoạt động cải tiến để nâng mức độ trưởng thành từ thấp lên cao.

    Có nhiều PF, nhưng phổ biến nhất là ISO và CMM (Capability Maturity Model) được các tổ chức thế giới công nhận. ISO nhắm chung đến nhiều loại tổ chức cả sản xuất lẫn dịch vụ, trong khi CMM được dành riêng cho các tổ chức phát triển phần mềm. Đối với phần mềm, ISO chỉ ra mức độ chất lượng yêu cầu tối thiểu mà một SEP phải đạt (ISO certified) và việc cải tiến qui trình được thực hiện thông qua qui trình kiểm định, trong khi CMM bao gồm những thực tiễn tốt nhất (best practices) được tập hợp rút tỉa từ rất nhiều tổ chức phát triển phần mềm khác nhau và chúng được tổ chức thành 5 mức độ trưởng thành khác nhau (Level 1 - Initial, Level 2 - Repeatable, Level 3 - Defined, Level 4 - Managed, Level 5 - Optimizing).

    Ngày nay, phần mềm không đứng riêng một mình mà thường là một bộ phận trong hệ thống hoàn chỉnh. Do đó, CMMI (Capability Maturity Model Integration) ra đời hướng đến các qui trình cho việc xây dựng cả hệ thống, bao gồm cả việc tích hợp để xây dựng và bảo trì toàn bộ hệ thống.
    Lần sửa cuối bởi Nistelrooy; 07-12-2005 lúc 01:21 AM

  8. #8
    Quân Nhân Danh Dự
    Tham gia ngày
    Jan 2004
    Bài gửi
    1.404

    Mặc định

    Làm thế nào để resize mấy cái ảnh lại các bác nhỉ?
    Lần sửa cuối bởi Nistelrooy; 07-12-2005 lúc 01:34 AM

  9. #9
    Quân nhân danh dự Avatar của Mr.vulh_bk
    Tham gia ngày
    Dec 2003
    Bài gửi
    3.493

    Mặc định

    Quote Nguyên văn bởi Nistelrooy
    Làm thế nào để resize mấy cái ảnh lại các bác nhỉ?
    Read here :http://www.svbkol.org/forum/showthread.php?t=7684

  10. #10
    HUT's Student Avatar của langtucodon
    Tham gia ngày
    Sep 2005
    Bài gửi
    202

    Mặc định

    Bravo pác Nistelrooy
    Hãy vươn tay hướng tới mặt trời dù không là mặt trời thì bạn cũng là 1 vì sao sáng
    [trên bầu trời đầy sao2 ]

+ Trả lời chủ đề
Trang 1/2 12 CuốiCuối

Thông tin chủ đề

Users Browsing this Thread

Hiện có 1 người đọc bài này. (0 thành viên và 1 khách)

Chủ đề tương tự

  1. Liên quan đến hóa công
    Gửi bởi dunghdbk trong mục Viện Kỹ thuật Hóa học
    Trả lời: 7
    Bài cuối: 30-05-2012, 04:02 PM
  2. Trường ca CON ĐƯỜNG CÁI QUAN - Phạm Duy
    Gửi bởi con thuyền không bến trong mục V-Music
    Trả lời: 0
    Bài cuối: 02-07-2006, 11:39 AM
  3. Tầm quan trọng của môn toán cao cấp
    Gửi bởi mafd_47 trong mục GIẢNG ĐƯỜNG ĐẠI CƯƠNG
    Trả lời: 33
    Bài cuối: 06-12-2005, 05:38 PM
  4. Phụ nữ, quan tâm thế nào thì vừa đủ?
    Gửi bởi mr_vinhk44 trong mục Tình bạn - Tình yêu
    Trả lời: 8
    Bài cuối: 27-06-2005, 06:06 AM

Từ khóa (Tag) của chủ đề này

Quyền viết bài

  • Bạn không thể gửi chủ đề mới
  • Bạn không thể gửi trả lời
  • Bạn không thể gửi file đính kèm
  • Bạn không thể sửa bài viết của mình


About svBK.VN

    Bách Khoa Forum - Diễn đàn thảo luận chung của sinh viên ĐH Bách Khoa Hà Nội. Nơi giao lưu giữa sinh viên - cựu sinh viên - giảng viên của trường.

Follow us on

Twitter Facebook youtube