Sự khác biệt giữa cách tiếp cận gia tăng và lặp lại để phát triển phần mềm là gì?


16

Cách tiếp cận Tăng dần là một phương pháp phát triển phần mềm trong đó mô hình được thiết kế, triển khai và thử nghiệm tăng dần (thêm một chút mỗi lần) cho đến khi sản phẩm kết thúc. Nó liên quan đến cả phát triển và bảo trì. Sản phẩm được định nghĩa là đã hoàn thành khi đáp ứng tất cả các yêu cầu của nó

Các thiết kế lặp là một phương pháp thiết kế dựa trên một quá trình tuần hoàn của tạo mẫu, thử nghiệm, phân tích, và tinh chỉnh một sản phẩm hoặc quy trình. Dựa trên kết quả kiểm tra lần lặp gần đây nhất của thiết kế, các thay đổi và tinh chỉnh được thực hiện. Quá trình này nhằm mục đích cuối cùng là cải thiện chất lượng và chức năng của một thiết kế. Trong thiết kế lặp, tương tác với hệ thống được thiết kế được sử dụng như một hình thức nghiên cứu để thông báo và phát triển dự án, như các phiên bản kế tiếp hoặc lặp lại của một thiết kế được thực hiện.

Dường như cả hai phương pháp là về việc tạo ra một phần của hệ thống, tinh chỉnh nó để vượt qua tất cả các trường hợp thử nghiệm, thêm một thành phần khác của hệ thống và tinh chỉnh lại, những điều này được lặp lại cho đến khi hệ thống kết thúc.

Sự khác biệt thực sự giữa hai cách thiết kế phần mềm này là gì

Làm thế nào có thể kết hợp hai phương pháp này để tạo thành phương pháp thiết kế lặp và tăng dần

Câu trả lời:


13

Các Incremental Cách tiếp cận sử dụng một số thiết lập của các bước và phát triển đi từ đầu đến cuối trong một con đường tuyến tính của sự tiến triển.

Phát triển gia tăng được thực hiện theo các bước từ thiết kế, thực hiện, thử nghiệm / xác minh, bảo trì. Chúng có thể được chia nhỏ thành các bước phụ nhưng hầu hết các mô hình gia tăng đều theo cùng một mẫu. Các Thác Mẫu là một cách tiếp cận phát triển gia tăng truyền thống.

Các cách tiếp cận lặp không có số tập các bước, chứ không phải phát triển được thực hiện trong chu kỳ.

Phát triển lặp lại ít quan tâm đến việc theo dõi tiến trình của các tính năng riêng lẻ. Thay vào đó, tập trung vào việc tạo ra một nguyên mẫu hoạt động trước tiên và thêm các tính năng trong các chu kỳ phát triển trong đó các bước Phát triển gia tăng được thực hiện cho mỗi chu kỳ. Mô hình hóa Agile là một cách tiếp cận lặp lại điển hình.


Mô hình gia tăng ban đầu được phát triển để theo mô hình dây chuyền lắp ráp truyền thống được sử dụng trong các nhà máy. Thật không may, thiết kế và phát triển phần mềm có ít điểm chung với sản xuất hàng hóa vật lý. Mã là bản thiết kế không phải là thành phẩm của sự phát triển. Các lựa chọn thiết kế tốt thường được 'khám phá' trong quá trình phát triển. Việc khóa các nhà phát triển vào một loạt các giả định mà không có bối cảnh phù hợp có thể dẫn đến các thiết kế kém trong trường hợp tốt nhất hoặc hoàn toàn làm hỏng sự phát triển trong điều tồi tệ nhất.

Phương pháp lặp hiện đang trở thành thông lệ vì nó phù hợp hơn với con đường tiến bộ tự nhiên trong phát triển phần mềm. Thay vì đầu tư nhiều thời gian / công sức để theo đuổi 'thiết kế hoàn hảo' dựa trên các giả định, phương pháp lặp là tất cả về việc tạo ra thứ gì đó 'đủ tốt' để bắt đầu và phát triển nó để phù hợp với nhu cầu của người dùng.

tl; dr - Nếu bạn đang viết một bài luận theo Mô hình gia tăng, bạn sẽ cố gắng viết nó một cách hoàn hảo từ đầu đến cuối một câu tại thời điểm đó. Nếu bạn đã viết nó theo Mô hình lặp, bạn sẽ đưa ra một bản phác thảo nhanh và làm việc để cải thiện nó thông qua một loạt các giai đoạn sửa đổi.


Cập nhật:

Tôi đã sửa đổi định nghĩa của mình cho 'Cách tiếp cận tăng dần' để phù hợp với một ví dụ thực tế hơn.

Nếu bạn đã từng phải đối phó với việc ký kết Hợp đồng tiếp cận gia tăng là cách hầu hết các hợp đồng được thực hiện (đặc biệt là cho quân đội). Mặc dù có nhiều biến thể tinh tế của 'Mô hình thác nước' điển hình nhất / tất cả chúng đều được áp dụng theo cùng một cách trong thực tế.

Các bước thực hiện như sau:

  • Giải thưởng hợp đồng
  • Đánh giá thiết kế sơ bộ
  • Đánh giá thiết kế quan trọng
  • Đặc điểm kỹ thuật đóng băng
  • Phát triển
  • Fielding / Tích hợp
  • xác minh
  • Kiểm tra độ tin cậy

PDR và ​​CDR là nơi thông số kỹ thuật được tạo và sửa đổi. Khi thông số kỹ thuật hoàn tất, nó sẽ được đóng băng để ngăn chặn creep scope. Tích hợp xảy ra nếu phần mềm được sử dụng để mở rộng một hệ thống có sẵn. Xác minh là để kiểm tra xem ứng dụng có khớp với thông số kỹ thuật không. Độ tin cậy là một thử nghiệm để chứng minh rằng ứng dụng sẽ đáng tin cậy trong thời gian dài, điều này có thể được chỉ định giống như SLA (Thỏa thuận cấp độ dịch vụ) trong đó hệ thống được yêu cầu duy trì một tỷ lệ thời gian hoạt động nhất định (99% thời gian hoạt động trong 3 tháng ).

Mô hình này hoạt động tuyệt vời cho các hệ thống đơn giản để chỉ định trên giấy nhưng khó sản xuất. Phần mềm rất khó chỉ định trên giấy đến bất kỳ mức độ chi tiết đáng kể nào (ví dụ UML). Hầu hết các 'loại hình kinh doanh' chịu trách nhiệm quản lý / ký kết hợp đồng đều không nhận ra rằng - khi nói đến phát triển phần mềm - bản thân mã thông số kỹ thuật. Thông số kỹ thuật giấy thường mất nhiều hoặc nhiều thời gian / công sức để viết như chính mã và chúng thường chứng minh là không đầy đủ / kém hơn trong thực tế.

Các cách tiếp cận tăng dần cố gắng lãng phí thời gian / tài nguyên bằng cách coi chính mã là đặc tả. Thay vì chạy thông số kỹ thuật giấy qua nhiều bước sửa đổi, bản thân mã phải trải qua nhiều chu kỳ sửa đổi.


+1 cho ví dụ hay, mặc dù mô tả Tăng dần có vẻ sai đối với tôi
Basilevs

@Basilevs Có tốt hơn không?
Evan Plaice

6
Thác không tăng. Phần đặc biệt đề cập đến việc xây dựng (thiết kế thông qua kiểm tra) từng phần mềm. Trong mô hình thác nước truyền thống, bạn thực hiện tất cả các thiết kế của mình, sau đó là tất cả việc thực hiện và sau đó là tất cả các thử nghiệm của bạn. Nó không tăng thêm chút nào. Có các biến thể của thác nước, chẳng hạn như nơi bạn sẽ xử lý các yêu cầu của mình về kỹ thuật trước, sau đó chia dự án thành các mức tăng trong đó mỗi mức tăng được thiết kế, thực hiện, thử nghiệm (và tích hợp và thử nghiệm với các mức tăng khác), nhưng điều này không truyền thống thác nước.
Thomas Owens

0

Như với bất kỳ tính từ nào, và hầu hết mọi thứ trong phát triển phần mềm ... đều phụ thuộc!

Nó phụ thuộc vào ngữ cảnh và cách sử dụng thuật ngữ này. Vì vậy, bạn đang hỏi về sự khác biệt giữa các cách tiếp cận gia tăng và lặp lại để phát triển phần mềm, nhưng trích dẫn của bạn nhìn vào thiết kế lặp, đó là một điều khác biệt (mặc dù tương tự).

Vì vậy, trả lời cụ thể như một cách tiếp cận để phát triển phần mềm ..

Câu hỏi được đặt không đúng chỗ. Nó không phải cái này hay cái kia. Bạn không thể so sánh chúng trực tiếp khi chúng đề cập đến các phần khác nhau của quy trình.

Phát triển phần mềm lặp là bản chất của nó tăng dần. Phát triển phần mềm tăng dần không cần phải lặp lại.

Một sự gia tăng là một động thái nhỏ, hy vọng về phía trước. Đó là một cách để đề cập đến từng bước của công việc được thực hiện.

Lặp lại là một chu kỳ của công việc.

Vì vậy, một phép lặp đề cập đến chu kỳ phát triển tổng thể được sử dụng. Một sự gia tăng đề cập đến từng bước riêng biệt của công việc. Lặp lại sẽ tạo ra một số gia, được tạo thành từ một hoặc nhiều số gia thực tế cho phần mềm (thường là nhiều hơn).

Tóm lại là...

Phát triển phần mềm lặp là một loại phương pháp cụ thể để phát triển phần mềm, hoạt động theo các bước lặp trái ngược với cách tiếp cận thác nước truyền thống. Scrum là một ví dụ tốt.

Phát triển phần mềm tăng dần là tổng quát hơn, và đề cập đến việc chuyển công việc về phía trước theo các bước, đó là một tính năng của hầu hết các phương pháp (có lẽ là tất cả?). Như đã nói, thuật ngữ này thường được sử dụng liên quan đến các cách tiếp cận hiện đại, nhanh nhẹn, có lẽ giải thích sự nhầm lẫn giữa hai thuật ngữ rất giống nhau.

Và cuối cùng, tất nhiên, nó phụ thuộc vào thuật ngữ này có nghĩa như thế nào khi được sử dụng, thường thay đổi đáng kể theo người nói, thời gian trong tháng, v.v!

Một câu hỏi thú vị hơn là, cách tiếp cận theo kinh nghiệm để phát triển phần mềm phù hợp với tất cả những điều này. Cái hay của cách tiếp cận lặp đi lặp lại là nó cho phép chủ nghĩa kinh nghiệm, đó là nơi phép màu xảy ra.

Hi vọng điêu nay co ich.

Bài viết này mô tả nó tốt, với các ví dụ.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.