333333333333
CHƯƠNG 2
Hà Văn Thụy –cac phan ghi chũ xanh là phần chú thich them cho moi người hieu.
2.5. Iteration and Incrementation(sự lặp đi lập lại và tăng từng phần)
Như một hệ quả của vấn đề di chuyển mục tiêu và sự cần thiết để sửa chữa sai lầm không thể tránh khỏi trong khi một sản phẩm phần mềm được phát triển,mô hình sản xuất phần mềm thì tương tự như mô hình cây phát triển hoặc là mô hình thác nước.Một hệ quả của thực tế này là nó không có ý nghĩa nhiều để nói về (nói) "giai đoạn phân tích.".thay vào đó thì hoạt động của pha phân tích thì được trải ra toàn vòng dời.
Cân nhắc tới phiên bản tiếp theo của tạo tác.ví dụ như tài liệu kĩ thuật hoác các doạn code.Từ quan điểm này thì quá trình cơ bản là lặp đi lập lại.Vì vậy mà ta có thể đưa ra phiên bản đầu tiên của sản phẩm,và sau đó we sửa lại nó và đưa ra phiên bản tiếp theo.Ý dịnh của ch.ta là mỗi phiên bảm phải tiếp cận gần hơn mục tiêu hơn là phiên bản trước của chính nó và cuối cùng we đưa ra phiên bản hài lòng nhất.Lặp đi lặp lại là một khía cạnh bản chất của công nghệ phần mềm.và mô hình này đă được sử dụng trong khoảng hơn 30 năm.
Một khía cạnh thứ hai của phát triển phần mềm của thế giới thực là hạn chế của luật Miller.Năm 1956 một chuyên gia tâm ly hóc đã chỉ ra rằng,ở một thời điểm con người chỉ có thể tập trung chỉ vào chừng khoảng 7 khoanh(đơn vị thông tin).Tuy nhiêm một sản phẩm phần mềm diển hình thì thường nhiều hơn 7 khoanh.Một trong những cách thức mà con người vân dụng sự hạn chế này trong lượng thông tin mà chúng ta sử dụng tại một thời điểm là để sử dụng “làm mịn từng bước”.Đó là, chúng ta tập trung vào những khía cạnh quan trọng nhất và trì hoãn những khía cạnh khác cho đến sau này những khía cạnh này ít quan trọng hơn.
Trong thực tế, lặp đi lặp lại và sự tăng từng phần thêm được sử dụng kếthợp với nhau.Đó là,tạo tác được xây dựng từng phần (incrementation), và tăng lên từng phần đi qua nhiều phiên bản.Trong hình 2.2 chỉ ra rằng ,không có giai đoạn lấy yêu cầu là duy nhất.Thay vào đó, yêu cầu của khách hàng được chiết xuất và hai lần phân tích, mang lại các yêu cầu ban đầu (Yêu cầu1) và sửa đổi yêu cầu (yêu cầu4).
Những ý tưởng này là tổng quát trong hình 2.4, nó phản ánh các khái niệm cơ bản của mô hình ặp đi lặp lại và tăng tưng phần” Iteration and Incrementation”.Sơ đồ chỉ ra rằng sự phát triển của một sản phẩm phàn mềm thì được phát triển qua 4 sự tăng lên,Increment A, Increment B. Increment C, Increment D.
Hình 2.4 mô tả chỉ là một cách có thể một sản phẩm phần mềm có thể được chia ra trong sự gia tăng. Một sản phẩm phần mềm có thể được xây dựng chỉ trong 2 gia tăng, trong khi 1/3 có thể yêu cầu 14.
Chú giải cho moi người hiểu nhé:“sự gia tăng ở đây đc hiểu là một sản phẩm phần mềm thì có các phiên bản ,phiên bản sau bao giờ cũng tốt và hoàn thiện hơn các phiên bản trước đó.”
Hơn nữa,Sơ đò không có nghĩa là đại diện chính xác ”làm thế nào một sản phẩm phần mềm được phát triển”. Thay vào đó,nó cho thấy làm thế nào thay đổi trọng tâm từ lặp đi lặp lài đến lặp đi lặp lại.( from iteration to iteration.)
Chúng ta phải thừa nhận rằng các workflow khác nhau thì được thực thi trên toàn bộ vòng dời.Có 5 workflow cốt lõi là requirements workflow ,analysis workflow,design workflow,implementation workflow,and test workflow.tất cả năm được thực hiện trong vòng đời của một sản phẩm phầnmềm.Tuy nhiên, có thời điểm khi một workflow chiếm ưu thế hơn bốn workflow còn lại.
Ví dụ như ỏ gian đoạn bắt đàu của vòng đơi,thì đội phát triển phần mềm bắt đầu thiết lập việc lấy yêu cầu.Nói cách khác, lúc bắt đầu của mô hình “lặp đi lặp lại và gia tăng”
requirement workflow chiếm ưu thế.Những yêu cầu tạo tác (requirements artifacts) được mở rộng và sửa đổi trong thời gian còn lại của vòng đời.Khi chúng giảm bớt sự chiếm ưu thế của mình thì trong thời gian đó, bốn workfows (phân tích, thiết kế, thực hiện, và thử nghiệm) chiếm ưu thế.Nói cách khách là vào dầu mô hình vòng đời thì requirements workflow là workflow chính,nhưng nó sẽ giảm dần về sau và các workflow khác lên chiếm ưu thế.Ngược lại, implementation and test workflows chiếm thời gian của các thành viên trong nhóm phát triển phần mềm tại thời điểm kết thúc của vòng đời hơn là khoảng thời gian từ đầu.
Kế hoạch và tài liệu hướng dẫn hoạt động được thực hiện trong suốt vòng đời”lặp đi lặp lại và tăng từng phần”( Iteration and Incrementation).Hơn nữa ,v iệc kiểm tra là phần công việc chính trong mỗi lần lặp đi lặp lại Và sẽ kiểm tra một cách tỉ mỉ ở cuối mỗi lần lặp.Ngoài ra,một sản phẩm phần mềm khi nó đã được hoàn thành thì nó phải trải qua một lần kiểm tra kĩ lưỡng,và cũng trong khoảng thời gian đó thì ,việc kiểm thử ,sửa các lỗi trong pha cài dặt hầu như là hoạt đồng duy nhât trong dội phát triển ( thể hiên rõ trong sơ đò trên chủ yểu ở pha cài đăt và kiểm thử)
Hình 2.4 chỉ ra 4 sự tăng lên,Increment A nó được thể hiên băng côt ở bên trái.Ở thời điểm băt dầu của Increment này,các thành viên của đội lấy yêu cầu lấy các yêu cầu từ khách hàng.Một khi hầu hết các yêu cầu đã được xác dình thì phần đầu tiên của việc phân tích có thể dược bắt đầu.Tương tư vậy ,khi phần phân tích đã có dủ điểu kiện thì phần dầu của việc thiêt kế có thể băt đàu.Một vài đoạn code có thể được hoàn thành trong Increment đầu tiên này.có lẽ trong các hình thức của một nguyên mẫu để kiểm tra
tính khả thi một phần của các sản phẩm phần mềm được đề xuất.
Lê Tu Anh
Trang 44: Hình 2.5
Cuối cùng, như đã đề cập trước đó, lập kế hoạch, kiểm thử, và hướng dẫn sử dụng bắt đầu vào ngày đầu tiên và tiếp tục sau đó, cho đến khi sản phẩm phần mềm cuối cùng cũng được chuyển giao cho khách hàng.
Tương tự như vậy, sự tập trung chủ yếu trong quá trình Increment B là thực hiện yêu cầu và phân tích các workflow, và sau đó là thiết kế workflow. Nhấn mạnh trong Increment C đầu tiên là thiết kế workflow, và sau đó là triển khai workflow và test workflow. Cuối cùng, trong Increment D chủ yếu là triển khai workflow và test workflow.
Hình 1.4
Như hình 1.4, khoảng 1/5 trong tổng công sức(chi phí)(total effort) là được dành để thực hiện những yêu cầu và phân tích workflows, 1/5 tổng chi phí khác là việc thiết kế workflow và 3/5 còn lại là việc thực hiện workflow. Tổng các giá trị phần tô đậm trong hình 2.4 cũng đã nói lên điều này.
Đó là sự lặp đi lặp lại trong mỗi Increment trong hình 2.4. Hình 2.5 thể hiện chi tiết hơn Increment B trong hình 2.4, nó cho thấy 3 lần lặp đi lặp lại của các workflow. Theo hình 2.5, mỗi lần lặp lại đều lien quan đến tất cả 5 workflow nhưng trong mỗi lần thì tỉ lệ lại khác nhau.
1 lần nữa, nhấn mạnh rằng hình 2.5 không phải để cho thấy rằng mỗi Increment đều có chính xác 3 lần lặp lại. Số lần lặp lại thay đổi từ Increment này đến Increment khác. Mục đích của hình 2.5 là để cho thấy sự lặp lại trong mỗi Increment, và với cả 5 workflow cùng với cả kế hoạch và tài liệu được thưc hiện gần như tất cả trong quá trình lặp lại, mặc dù tỉ lệ là khác nhau trong mỗi thời điểm.
Như đã giải thích ở trên, hình 2.4 là sự thể hiện bên trong của Incremention(có thể dịch là phát triển thêm,từng tí 1) tới sự phát triển của mỗi sản phẩm phần mềm. Hình 2.5 thể hiện 1 cách rõ ràng, sự lặp đi lặp lại chính là nền tảng của Incrementation. Cụ thể, hình 2.5 mô tả 3 sự lặp lại lien tiếp các bước, đối lập với 1 Increment lớn.(là Increment B). Chi tiết hơn, Iteration B.1bao gồm requirements, analysis, design, implemention, và test workflows. Quá trình lặp lại sẽ tiếp tục cho đến khi sản phẩm(artifacts)(bản phác thảo) của mỗi workflow đạt yêu cầu.
Tiếp theo, 5 bản phác thảo trên lại được lặp lại ở B.2. Tương tự lần đầu tiên, những bản thảo yêu cầu cần được cải thiện, do đó gây ra các cải tiến của bản phân tích, cứ như vậy.tương tự với lần thứ 3.
Quá trình của sự lặp đi lặp lại và các Incrementation được bắt đầu từ Increment A và kết thúc ở D. Các sản phẩm hoàn thành sau đó được cài đặt trên máy của khách hàng.
Trang 46:
Phần 2.7: Risks and Other Aspects of Iteration and Incrementation(Rủi ro và các khía cạnh khác của sự lặp lại và phát triển thêm)
1 cách khác để nhìn vào Iteration và Incrementation như là 1 project bị chia nhỏ ra thành các mini project hay increment. Mỗi mini project extends các requiments, analysis, design, implementation, và testing artifacts. Cuối cùng, tập hợp các kết quả của artifacts tạo thành các sản phẩm phần mềm hoàn chỉnh.
Trong thực tế, mỗi mini project bao gồm nhiều hơn là chỉ cần extend các artifacts. Mini project là điều cần thiết để kiểm tra rằng mỗi artifact là chính xác(test workflow) và thực hiện những thay đổi cần thiết cho các artifacts có liên quan.Đó là quá trình của việc kiểm tra và sửa lỗi(checking and modifying), sau đó kiểm tra lại và lại sửa lỗi,cứ như vậy, rõ ràng là lặp đi lặp lại về bản chất. Nó sẽ tiếp tục cho đến khi các thành viên của nhóm phát triển đã được hài lòng với tất cả các artifacts của mini project hiện tại(or increment).Đến đây, họ sẽ cho tiến hành increment tiếp theo.
So sánh hình 2.3(waterfall model) với hình 2.5(sự lặp đi lặp lại với Increment B) cho thấy rằng mỗi iteration có thể coi như là 1waterfall model nhỏ nhưng đầy đủ. Trong mỗi iteration các thành viên của nhóm phát triển thông qua các pha yêu cầu cổ điển, phân tích, thiết kế, và triển khai. Trên quan điểm này, mô hình iterative-và-incremental của hình 2.4 và 2.5 có thể được xem như là series liên tiếp của các waterfall model.
Mô hình iterative-và-incremental có những thế mạnh:
1. Rất nhiều cơ hội(opportunities) được cung cấp để check các sản phẩm phần mềm là chính xác.Mỗi iteration kết hợp với test workflow, do đó mỗi iteration là 1 cơ hội khác để check tất cả artifacts được phát triển đến thời điểm này. Các lỗi sau đó được phát hiện và sửa, do đó chi phí cao hơn,như hình 1.6. Không giống như waterfall model cổ điển, mỗi iteration của mô hình iterative-và-incremental cung cấp hơn 1 cơ hội nữa để tìm lỗi và sửa chúng, do đó tiết kiệm chi phí hơn.
2. Sự vững chắc của kiến trúc cơ bản có thể được xác định khá sớm trong chu kì vòng đời. Kiến trúc của 1 sản phẩm phần mềm bao gồm thành phần khác nhau của artifacts và làm thế nào nó phù hợp. Một sự tương tự là kiến trúc của cathedral, mà có thể được mô tả như Romanesque, Gothic, Baroque, 1 số khả năng khác. Tương tự như vậy, kiến trúc của 1 sản phẩm phần mềm có thể được mô tả hướng đối tượng(Chap 7), đường ống và bộ lọc(pipes and filters)(các thành phần của UNIX or LINUX), hoặc client-server. Kiến trúc của 1 sản phẩm phần mềm được phát triển bằng cách sử dụng mô hình iterative-và-incremental phải có đặc tính là nó có thể mở rộng liên tục(và, nếu cần, dễ dàng thay đổi) để kết hợp các increment tiếp theo. Khả năng xử lý các phần mở rộng và thay đổi, mà không tan vỡ được gọi là robustness(bền vững).Robustness là 1 tính chất quan trọng trong quá trình phát triển của 1 sản phẩm phần mềm, nó quan trọng trong quá trình bảo trì postdelivery(ko dịch được). Vì vậy, nếu 1 sản phẩm phần mềm mà quá trình bảo trì postdeliverykéo dài hơn 12,15năm,hoặc lâu hơn thì kiến trúc cơ bản của nó sẽ bền vững. Khi 1 mô hình iterative-và-incremental được sử dụng, nó sẽ sớm trở nên rõ ràng (apparent) cho dù không có kiến trúc bền vững. Nếu, trong quá trình kết hợp 3 increment, rõ ràng là các phần mềm đã được phát triển cho đến nay đã được tổ chức lại (reorganized)(tái tạo) đáng kể và phần lớn các bộ phận được triển khai lại(reimplemented), thì rõ ràng kiến trúc không đủ bền vững. Các khách hàng quyết định nên từ bỏ hay bắt đầu lại từ đầu. 1 khả năng khác là thiết kế lại kiến trúc để được bển vững hơn, và sau đó tái sử dụng càng nhiều artifacts hiện tại càng tốt trước khi sang increment tiếp theo. 1 lý do khác khiến kiến trúc bền vững trở nên quan trọng là vì vấn đề di chuyển mục tiêu(moving-target)(yêu cầu thay đổi). Đó là tất cả lý do nhưng yêu cầu của khách hàng có thể thay đổi, sự phát triển trong tổ chức của khách hàng hoặc do khách hàng thay đổi ý kiến như mục đích mà phần mềm cần phải làm. Kiến trúc bền vững hơn, linh hoạt hơn là những điều thay đổi mà phần mềm sẽ làm. Nó không phải là có thể thiết kế 1 kiến trúc có thể đối phó với quá nhiều thay đổi mạnh mẽ. Nhưng nếu những thay đổi cần thiết là hợp lý,trong phạm vi cho phép, 1 kiến trúc bền vững nên có khả năng kết hợp với những thay đổi mà không cần phải tái cơ cấu mạnh mẽ.
Nguyen Gia Thuy
Các mô hình lặp lạivà gia tăng cho phép chúng tôi để giảm thiểu rủi ro ban đầu.Rủi roluôn luôn liên quan đến phát triển phần mềm và bảo trì.Trong một nghiên cứu nhỏ tại Winburg, ví dụ, thuật toán nhận dạng hình ảnh ban đầu là không đủ nhanh, có một rủi roluôn hiện diện một sản phẩm phần mềm sẽ không hoàn thànhđúng hạn.Phát triển một sản phẩm phần mềm từng bước cho phép chúng ta giảm thiểu rủi ro ban đầu trong vòng đời. Ví dụ, giả sử một mạng cục bộ (LAN) đang được phát triển và là mối quan tâm là phần cứng mạng hiện nay là không đủ cho các sản phẩm phần mềm mới.Sau đó, một hoặc hai lần lặp lại đầu tiên được hướng vào việc xâydựng những bộ phận của phần mềm có giao diện với các phần cứng mạng.Nếu nó trái ngược với lo ngại các nhà phát triển, mạng lưới cần khả năng, các nhà phát triển có thể tiến hành dự án, tự tin rằng nguy cơ này đã được giảm nhẹ.Mặt khác,nếu các mạng thực sự không thể đối phó với lưu lượngbổ sung mà các mạng LAN mới tạo ra, điều này được báo cáo cho khách hàng sớm trong vòng đời, khi chỉ có một tỷ lệ nhỏcủa ngân sách đã được chi.Các khách hàng bây giờ có thể quyết định liệu có nên hủy bỏdự án, mở rộng khả năng của mạng lưới hiện có, mua một mạng lưới mới và mạnh mẽhơn, hoặc một số hành động khác
Chúng ta luôn luôn có một phiên bản làm việc của phần mềm.Giả sử một sản phẩm phần mềm được phát triển bằng cách sử dụng mô hình vòng đời cổ điển của hình 2.1.Chỉ vào cuối của dự án là có một phiên bản làm việc của các sản phẩm phần mềm. Ngược lại, khicác mô hình vòng đời lặp lại và gia tăng được sử dụng, vào cuối mỗi lần lặp, có một phiên bản làm việc của một phần mục tiêu tổng thểcủa các sản phẩm phần mềm.Các khách hàng và người dựđịnhsử dụng có thể thử nghiệm với phiên bản đó và xác định những thay đổi cần thiết để đảm bảo rằng việc thực hiện đầy đủ sau nàyđáp ứng nhu cầu của họ. Những thay đổi này có thể được thực hiện để có bướctiếp theo, các khách hàng và người sử dụng sau đó có thể xác định nếu cần thiếtthay đổi hơn nữa. Sự thay đổi này là để cung cấp các phiênbản một phần của các sản phẩm phần mềm, không chỉ cho thử nghiệm mà còn cho việc giới thiệu các sản phẩm phần mềm mới trong tổ chức khách hàng được trơn tru. Thay đổi được hầu như luôn luôn nhận thức như là một mối đe dọa. Tất cả các quá thường xuyên, người dùng lo sợ rằng sự ra đời củamột sản phẩm phần mềm mới trong nơi làm việc sẽ dẫn đến họ mất việc làm của họ với một máy tính. Tuy nhiên, dần dần giới thiệu một sản phẩm phần mềm có thể có hai lợiích.Đầu tiên, nỗi lo sợ dễhiểu bởi máy tính sẽ giảm bớt.Thứ hai,nó thường dễ dàng hơn để tìm hiểu các chức năng của một sản phẩm phần mềm phức tạp nếu chức năng đó được giới thiệu từng bước trong một khoảng thời gian vài tháng,chứ không phải tất cả một lúc.
Có bằng chứng thực nghiệm rằng chu kì vòng đờilặp đi lặp lại và gia tăng hoạtđộng.Biểu đồ hình tròn trong hình 1.1 cho thấy kết quả của báo cáo từ Standish Group vềdự án
hoàn thành trong năm 2006 [Rubenstein, 2007]. Trong thực tế, báo cáo này (the so-called CHAOS Reportsee Just in Case You Wanted to Know Box 2.2) được sản xuất mỗi 2 năm. Hình 2.7 cho thấy các kết quả cho năm 1994 đến năm 2006. Tỷ lệ của sản phẩm thành công tăng lên đều đặn từ 16% năm 1994 lên 34% vào năm 2002, nhưng sau đógiảm xuống còn 29% vào năm 2004. Trong báo cáocả năm 2002 [Softwaremag.com, 2004] và 2004 [Hayes, 2004], một trong những yếu tố liên quan đến các dự án thành cônglà việc sử dụng của một quá trình lặp đi lặp lại. (Lý do đưa ra để giảm tỷ lệ phần trăm củadự án thành công trong năm 2004 bao gồm: các dự án lớn hơn so với năm 2002, sử dụngmô hình thác nước, thiếu sự tham gia của người sử dụng, và thiếu sự hỗ trợ của giám đốc điều hành cấp cao của Hayes, 2004].) , tỷ lệ phần trăm của dự án thành công tăng trở lạitrong nghiên cứu 2006 đến 35%. Chủ tịch của Nhóm Standish, Jim Johnson, do sự gia tăng đến ba yếu tố: quản lý dự án tốt hơn, cơ sở hạ tầng đang nổi lên Web, và (một lần nữa) lặp đi lặp lại phát triển [Rubenstein, 2007].
Liên
2.8 Quản lý sự lặp lại và sự gia tăng
Thoạt nhìn, các mô hình lặp đi lặp lại và gia tăng các hình 2.4 và 2.5 sẽ hoàn toàn lộn xộn. Thay vì sự tiến trình có trật tự yêu cầu thực hiện mô hình thác nước(Hình 2.3), nó xuất hiện cho thấy rằng các nhà phát triển làm bất cứ điều gì họ thích, có lẽ một số mã hóa vào buổi sáng, một giờ hoặc hai trong số thiết kế sau khi ăn trưa, và sau đó nửa giờ của quy định cụ thể trước khi về nhà. Đó ko phải là trường hợp. Ngược lại, các mô hình lặp lại và gia tăng là như regimented như mô hình thác nước, bởi vì như trước đây đã chỉ ra, phát triển một sản phẩm phần mềm bằng cách sử dụng các mô hình lặp lại và gia tăng ko có gì nhiều hơn hoặc ít hơn phát triển một loạt các sản phẩm phần mềm nhỏ hơn, tất cả bằng cách sử dụng các mô hình thác nước.
Chi tiết hơn, như thể hiện trong hình 2.3, phát triển một sản phẩm phần mềm bằng cách sử dụng mô hình thác nước có nghĩa là liên tục thực hiện yêu cầu, phân tích, thiết kế, và giai đoạn thực hiện( theo thứ tự) trên các sản phẩm phần mềm như một tổng thể. Nếu gặp một vấn đề, các thông tin phản hồi vòng hình 2.3(mũi tên nét dứt) theo sau; có nghĩa là sự lặp đi lặp lại(bảo trì) được thực hiện. Tuy nhiên, nếu cùng một sản phẩm phần mềm được phát triển bằng cách sử dụng các mô hình lặp lại và gia tăng, các sản phẩm phần mềm được xử lý như một tập hợp gia tăng. Đối với gia tăng lần lượt, các yêu cầu, phân tích, thiết kế và giai đoạn thực hiện(theo thứ tự) nhiều lần thực hiện trên đó, tăng cho đền khi rõ ràng là không thêm sự lặp đi lặp lại là cần thiết. Nói cách khác, các dự án như 1 tổng thể chia nhỏ thành một loạt các dự án thác nước nhỏ. Trong mỗi dự án nhỏ, lặp đi lặp lại là thực hiện khi cần thiết, như thế hiện trong hình 2.5. Vì vậy, lý do đoạn văn trước đó nói rằng các mô hình lặp lại và gia tăng như regimented là mô hình thác nước là bởi vì các mô hình lặp đi lặp lại và gia tăng là mô hình thác nước, áp đụng liên tiếp.
2.9 Các mô hình chu trình vòng đời
Bây giờ chúng ta hãy xem xét một số các mô hình vòng đời khác, bao gồm cả mô hình xoắn ốc và mô hình đồng bộ hóa và ổn định. Chúng tôi bắt đầu với mô hình Code và Fix nổi tiếng.
2.9.1 Mô hình vòng đời Code và Fix
Ko may rằng rất nhiều sản phẩm được phát triển bằng cách sử dụng những gì có thể được gọi là Mô hình vòng đời Code và Fix. Sản phẩm này thực hiện mà không có yêu cầu hoặc thông số kỹ thuật, hoặc bất kỳ cố gắng ở thiết kế. Thay vào đó, các nhà phát triển đơn giản là vứt mã lại với nhau và làm lại nhiều lần cần thiết để đáp ứng các khách hàng. Cách tiếp cận này đc thể hiện trong hình 2.8, hiển thị rõ ràng trường hợp ko có yêu cầu, chi tiết kỹ thuật và thiết kế.Mặc dù cách tiếp cận này có thể hoạt động tốt trên các bài tập lập trình ngắn 100 hoặc 200 dòng, mô hình Code và Fix là hoàn toàn ko đạt yêu cầu cho các sản phẩm của bất kỳ kích thước nào. Hình 1.6 cho thấy rằng chi phí của việc thay đổi một sản phẩm phần mềm là tương đối nhỏ nếu thay đổi được thực hiện trong quá trình yêu cầu, phân tích, giai đoạn thiết kế, nhưng phát triển ko thể chấp nhận được lớn nếu thay đổi được thực hiện sau khi sản phẩm đã được mã hóa, hoặc tồi tệ hơn, nếu nó đã có được
Hình 2.8 Mô hình vòng đời Code và Fix
Implement the first version: Phiên bản đầu tiên thực hiện
Modify until client is satisfied: Sửa đổi cho đến khi khách hàng hài lòng
Postdelivery maintenance: Postdelivery bảo trì
Retirement: gỡ bỏ
Development: phát triển
Maintenance: bảo trì
Cung cấp và cài đặt trên máy tính của khách hàng. Do đó, chi phí của Code và Fix thực sự là lớn hơn nhiều so với chi phí của một sản phẩm đúng quy định và thiết kế tỉ mỉ. Ngoài ra, bảo trì của một sản phẩm có thể cực kỳ khó khăn mà không có đặc điểm kỹ thuật hoặc các tài liệu thiết kế, và nguy cơ của một lỗi hồi quy xảy ra lớn hơn đáng kể. Thay vì cách tiếp cận Code và Fix , đó là điều cần thiết, trước khi bắt đầu phát triển một sản phẩm, một mô hình vòng đời thích hợp được lựa chọn.
Đáng tiếc, phần lớn các dự án sử dụng mô hình Code và Fix. Vấn đề đặc biệt nghiêm trọng trong các tổ chức thước đo tiên trình thuần túy là dòng mã, vì vậy, các thành viên của nhóm phát triển phần mềm bị áp lực tung ra nhiều dòng mã càng tốt, bắt đầu từ ngày thứ nhất của dự án. Mô hình Code và Fix là cách dễ nhất để phát triển phần mềm và cách tồi tệ nhất.
Một phiên bản đơn giản của mô hình thác nước đã được trình bày tại mục 2.2. Bây giờ chúng ta xem xét mô hình chi tiết hơn.
Hà
2.9.2 Mô hình vòng đời thác nước.
· Mô hình vòng đời thác nước lần đầu tiên đề ra bởi Royce[1970]
· Hình 2.9 cho thấy vòng phản hồi của bảo trì trong khi sản phẩm được phát tri
o Một điểm cần chú ý đối với mô hình thác nước (waterfall model) là một pha chỉ được hoàn thàh khi tài liệu cho pha đó đã hoàn thành, và sản phẩm tại pha đó được chấp nhận bởi nhóm bảo đảm chất lượng phần mềm ( software quality assurance-SQA).
o Nếu sản phẩm tại pha gần nhất phải thay đổi thì kéo theo sau đó là một vòng phản hồi, rằng pha gần nhất này được cho rằng hoàn thànhchỉ khi tài liệu cho phađã được điều chỉnh, và sự điều chỉnh phải được kiểm tra bởi SQA group.
o Bản thân một pha của waterfall model được kiểm tra, quá tình kiểm tra ko được thực hiện chỉ tại một pha riêng biệt sau khi sản phẩm được xây dựng, cũng ko được thực hiện kết thúc của mỗi một phase, mà theo section 1.7, thì kiểm tra (testing) phải được thực hiện liên tục xuyên suốt từ đầu đến cuối của tiến trình phần mềm. Và đặc biệt, trong suốt quá trình bảo trì, điều cần thiết cần phải đảm bảo phiên bản điều chỉnh của sản phẩm vẫn phải làm được những gì phiên bản trước đã làm được, thực hiện đúng và thêm những yêu cầu mới của khách hàng.
o Mô hình thác nước có nhiều sức mạnh, bao gồm 1 thứ tên là nó tên là enforced disciplined approach quy định các văn bản phải cung cấp tại mỗi pha và yêu cầu của toàn bộ sản phẩm tại mỗ pha được kiểm tra tỉ mỉ bởi SQA. Nhưng trong thực tế, thì mô hình thác nước có tài liệu kỹ thuật còn còn yếu (trong việc lấy yêu cầu đối với khách hàng)!! Có thể nhìn thấy qua 2 câu truyện hơi kỳ lạ:
§ 1. Joe và Jane quyết định xây nhà, họ tới gặp một kiến trúc sư, thay vì cho họ xem kế hoạch, bản phác thảo và có thể là một mô hình thì kiến trúc sư lại đưa họ 20 trang giấy tài liệu miêu tả căn nhà chuyên môn quá, trong khi đó Joe và Jane chưa học khóa học nào về kiến trúc, hầu như ko thể hiểu tài liệu đó, nhưng hó vẫn ký nó và nói “ Tiến lên, xây dựng ngôi nhà”
§ 2. Mark Marberry mua bộ com lê qua đặt hàng email, thay vì mail lại cho anh ta một bức tranh về các bộ com lê và những mẫu quần áo, thì công ty lại gửi cho anh ta miêu tả của những mảnh cắt tạo nên sản phẩm. Mark đã đặt hàng một cái bộ com le duy nhất dựa trên miêu tả ấy.
o Tất nhiên hầu như 2 cái câu truyện ko có thực, nhưng đây là mẫu điển hình cho cách phần mềm thường được xây dựng khi dùng mô hình thác nước. Tiến trình bắt đầu với những bản kĩ thuật chi tiết, chúng thường dài, chi tiết, và hầu như chán khi đọc. Khách hàng hầu như ko hề có kinh nghiệm để đọc chúng, bởi ngôn ngữ viết không phổ thông. Càng khó hơn khi nó lại được viết bởi ngôn ngữ kỹ thuật chi tiết như Z (tại section 12.9). tuy nhiên thì khách hàng vẫn kí vào tài liệu kỹ thuật đó, ko cần biết là hiểu hay ko. Khách hàng chấp nhận sản phẩm phần mềm miểu tả trong tài liệu kỹ thuật chi tiết rằng họ chỉ hiểu một vài phần.
o Trong lần đầu tiên khách hàng nhìn thấy sản phẩm hoạt động được chỉ sau khi toàn bộ sản phẩm đã được lập trình. Một ngạc nhiên nhỏ là nhà phát triển phần mềm vẫn luôn sống trong nỗi sợ của câu: “Tôi biết đó là những gì tôi yêu cầu, nhưng nó ko thực sự là những gì tôi muốn”? Điều gì sai? Đó là sự khác nhau đáng kể giữa cách mà khách hàng hiểu sản phẩm được miêu tả trong tài liệu kỹ thuật so với sản phẩm thật. Tài liệu kỹ thuật tồn tại chỉ trên giấy, Khách hàng ko thể hiểu thực sự rằng sản phẩm sẽ giống như thế nào, và tài liệu kỹ thuật có thể dẫn đến sản phẩm ko cập được điều mà khách hàng thực sự muốn.
o Ở truyện một kiến trúc sư, có thể giúp khách hàng hiểu rõ căn nhà sẽ được xây dựng bằng việc cung cấp cho họ mô hình, kế hoạch, và có thể dùng các công nghệ về đồ họa như sơ đồ dòng dữ liệu hay UML (ở chapter 17) để giao tiếp với khách hàng.
§ Có một vấn đề là đồ họa ko thể miểu tả sản phẩm kết thúc sẽ làm việc như thế nào. VD: sự khác nhau giữa flowchart (sơ đồ miêu tả sản phẩm) và sản phẩm được hoạt động bởi nó.
§ Trong quyển sách này, sẽ có 2 giải pháp đưa ra để giải quyết vấn đề trên, vừa có thể miểu tả sản phẩm theo cách để khách hàng có thể xác định được mục tiêu sản phẩm mà anh ấy hay cô ấy cần đó là:
· Giải pháp hướng đối tượng (chương 11, 13)
· Giải pháp truyền thống là rapid-prototyping model ngay sau đây.
Phương
2.9.3 Rapid-Prototyping Life-Cycle Model
Một rapid prototype (Nguyên mẫu) là một mô hình làm việc với chức năng tương đương với một tận hợp con của sản phẩm. Ví dụ, nếu sản phẩm đích là để xử lý các tài khoản phải trả, tài khoản phải thu và kho bãi, sau đó một rapid prototype có thể bao gồm một sản phẩm để thực hiện xử lý màn hình cho thu thập dữ liệu và in các báo cáo, nhưng không có file cập nhật và xử lý lỗi. Một rapid prototype cho một sản phẩm đích để xác định nồng độ của một enzyme trong một giải pháp có thể thực hiện tính toán và hiển thị những câu trả lời, nhưng mà không làm bất kỳ xác nhận hay kiểm tra tính hợp lý của dữ liệu vào.
Những gì là cần thiết, các nhà phát triển có thể xây dựng tài liệu về đặc điểm kỹ thuật với 1 số bảo đảm rằng sản phẩm đáp ứng được những nhu cầu thực sự của khách hàng.
Su khi sản xuất nguyên mẫu-nhanh chóng, quy trình phần mềm tiếp tục như thể hiện trong hình 2.10. Một sức mạnh chính của mô hình nguyên mẫu-nhanh chóng là sự phát triển của sản phẩm chủ yếu là tuyến tính, tiến hành từ nguyên mẫu-nhanh chóng đến sản phẩm giao nhận. Những vòng phản hồi từ mô hình thác nước (waterfall model) (hình 2.9) là ít có khả năng cần thiết trong mô hình nguyên mẫu-nhanh chóng. Một số lý do cho điều này, đầu tiên, những thành viên của nhóm phát triển sử dụng nguyên mẫu-nhanh chóng để xây dựng tài liệu đặc tả kỹ thuật. Bởi vì các nguyên mẫu-nhanh chóng làm việc đã được xác nhận thông qua sự tương tác với khách hàng, nó là hợp lý để hy vọng kết quả của tài liệu đặc tả kỹ thuật sẽ chính xác. Thứ hai, hãy xem thiết kế. Mặc dù nguyên mẫu-nhanh chóng (1 cách đúng đắn) được lắp ráp vội vàng, đội thiết kế có thể đạt được cái nhìn sâu sắc – điều tồi tệ là “làm thế nào để làm điều đó”. Một lần nữa, những vòng phản hồi của các mô hình thác nước (waterfall model) ít có khả năng cần thiết ở đây.
Thực hiện tiếp theo. Trong mô hình thác nước, thực hiện thiết kế đôi khi dẫn đến lỗi thiết kế với anh sáng. Trong mô hình nguyên mẫu-nhanh chóng, thực tế là một phiên bản sơ bộ của sản phẩm phần mềm đã được xây dựng có xu hướng giảm bớt sự cần thiết trong việc sửa thiết kế trong suốt hay sau khi thực hiện. Các mẫu thử nghiệm (prototype) đã đưa ra hiểu biết sâu sắc tới đội thiết kế, mặc dù nó có thể phản ánh duy nhất một phần chức năng của sản phẩm hoàn thiện đích.
Một khi sản phẩm đã được chấp nhận bởi khách hàng và được cài đặt, bảo trì tận nơi bắt đầu. Tùy thuộc vào nhiệm vụ bảo trì cụ thể phải được thực hiện, chy kì được nhập lại hoặc các yêu cầu pha phân tích, thiết kế hay pha thực hiện.
Một khía cạnh thiết yếu của nguyên mẫu-nhanh chóng là được thể hiện ở từ nhanh chóng. Các nhà phát triển cần nỗ lực để xây dựng nguyên mẫu-nhanh chóng nhanh nhất để tăng tốc độ quy trình phát triển phần mềm. Sau tất cả, việc sử dụng duy nhất của nguyên mẫu-nhanh chóng để xác định nhu cầu thực sự của khách hàng, khi điều này được xác định, nguyên mẫu-nhanh chóng thực hiện được loại bỏ nhưng những bài học kinh nghiệm được giữ lại và sử dụng trong những pha phát triển tiếp theo. Vì lý do này, cấu trúc nội bộ của nguyên mẫu-nhanh chóng là không liên quan. Điều quan trọng là nguyên mẫu-nhanh chóng được xây dựng rất nhanh và thay đổi cũng rất nhanh để phản ánh yêu cầu của khách hàng. Vì vậy, tốc độ là điều cốt yếu.
Mô hình nguyên mẫu-nhanh chóng được thảo luận chi tiết trong chương 11.
Bằng
2.9.4 Mô hình vòng đời mã nguồn mở
Hầu hết tất cả các dự án phần mềm mã nguồn mở thành công thông qua hai giai đoạn chính thức. Đầu tiên, một cá nhân duy nhất có một ý tưởng về một chương trình, chẳng hạn như hệ điều hành Linux, một trình duyệt Net như Firefox, hoặc một máy chủ web như Apache. Họ xây dựng một phiên bản ban đầu, sau đó phần phối miễn phí cho bất cứ ai muốn dùng; ngày nay, điều này được thực hiện thông qua Internet, các trang web như SourceForge.net và Freshmeat.net. Nếu ai đó tải về một bản sao của phiên bản ban đầu và nghĩ rằng chương trình cần được hoàn thiện, người đó sẽ bắt đầu sử dụng chương trình.
Nếu quan tâm đến chương trình thì nó sẽ bước vào giai đoạn hai. Người sử dụng trở thành đồng các nhà phát triển, khi đó họ sẽ cùng gửi các lỗi mà mình phát hiện và đưa ra đề nghị cách sửa chữa các lỗi đó. Một số người có thể đưa ra ý tưởng mở rộng chương trình và những người khác sẽ cùng thực hiện ý tưởng đó. Một mở rộng chức năng khác là chương trình được sử dụng trong hệ điều hành hoặc phần cứng khác. Một khía cạnh quan trọng là cá nhân thường làm việc trên một dự án mã nguồn mở trong thời gian rảnh rỗi của họ trên cơ sở tự nguyện, họ không được trả tiền để tham gia.
Bây giờ chúng ta xem xét chặt chẽ hơn ba hoạt động chính của giai đoạn thứ hai:
1. Báo cáo và sửa chữa các lỗi là bảo dưỡng sửa chữa.
2. Thêm chức năng bổ sung là hoàn bị phát triển.
3. Chuyển chương trình đến một môi trường mới là bảo trì tương thích.
Nói cách khác, giai đoạn không chính thức thứ hai của mô hình vòng đời mã nguồn mở chỉ bao gồm bảo trì, như hình 2.11. Trong thuật ngữ đồng các nhà phát triển trong giai đoạn thứ hai này nên thay bằng đồng bảo trì. Có một số sự khác biệt chính giữa mô hình vong đời phần mềm mã nguồn đóng và mã nguồn mở:
· Phần mềm mã nguồn đóng được duy trì và thử nghiệm bởi đội ngũ nhân viên của tổ chức sở hữu phần mềm. Người dùng đôi khi gửi báo cáo lỗi. Tuy nhiên, một hạn chế là gửi báo cáo thất bại, người dùng không thể truy nhập vào mã nguồn, vì vậy họ có thể k gửi được báo cáo lỗi ( báo cáo về mô tả mã nguồn k lỗi và cách sửa nó).
Ngược lại, phần mềm mã nguồn mở được duy trì bởi các tình nguyện viên không được trả lương. Người sử dụng được khuyến khích thông báo lỗi. Mặc dù mọi người có thể truy cập mã nguồn, nhưng chỉ số ít người có kĩ năng cần thiết về kiểm tra và báo cáo lỗi mới gửi báo cáo thành công. Nói chung là có một nhóm cốt lõi để bảo trì chuyên dụng - những người chịu trach nhiệm quản lí dự án mã nguồn mở. Một số thành viên của nhóm bên ngoài - người dùng không phải là thành viên của nhóm nong cốt - chọn báo cáo lỗi theo thời gian. Các thành viên của nhóm nòng cốt chịu trách nhiệm là các lỗi này được sửa chữa. Chi tiết hơn, khi một báo cáo lỗi được gửi, một thành viên của nhóm nòng cốt kiểm tra sửa chữa mã nguồn cho thích hợp. Khi báo cáo lỗi gửi thất bại, một thành viên của nhóm ngoài hoặc cá nhân sẽ xác định sửa chữa hoặc giao cho một tình nguyện viên khác. Một lần nữa, sức mạnh sửa chữa phần mềm giới hạn bởi các thành viên của nhóm nòng cốt.
· Phiên bản của phần mềm mã nguồn đóng thương phát hành khoảng 1 năm 1 lần. Mỗi phiên bản được kiểm tra bởi nhóm đảm bảo chất lượng phần mêm trước khi phát hành; bằng một loạt các trường hợp chạy thử nghiệm.
Ngược lại, một câu châm ngôn của phong trào mã nguồn mở là “ Phát hành sơm. Phát hành thường xuyên”. Đó là, nhóm nòng cootss phát hành một phiên bản mới của một sản phẩm mã nguồn mở ngay sau khi nó đã sẵn sàng, có thể là một tháng hoặc thậm chí chỉ một ngày sau khi phiên bản trước đó được phát hành. Phiên bản mới này được phát hành sau khi thử nghiệm tối thiểu, nó sẽ được thử nghiệm rộng rãi hơn bởi nhóm bên ngoài. Một phiên bản mới có thể được cài đặt bởi hàng trăm ngàn người sử dụng trong vòng một ngày. Tuy nhiên, trong quá trình sử dụng các phiên bản mới trên máy tính của họ, họ gặp phải lỗi, và báo cáo lỗi thông qua e-mail. Bằng cách này, các lỗi trong phiên bản mới được phát hiện và chỉnh sửa.
So sánh hình 2.8, 2.10, 2.11 chúng ta thấy rằng mô hình vòng đời của mã nguồn mở có tính năng giống với mô hình code-sửa lỗi và nhanh chóng tạo mô hình mẫu. Trong cả ba mô hình vòng đời, một phiên bản làm việc đầu tiên được sản xuất. Trong trường hợp mô hình nhanh chóng tạo mẫu, phiên bản ban đầu này được bỏ đi, và sản phẩm mục tiêu sau đó được quy định và được thiết kế trước khi được mã hóa. Trong cả hai mô hình code-sửa chữa và mã nguồn mở, các phiên bản đầu tiên được làm lại cho đến khi nó trở thành sản phẩm mục tiêu. Theo đó, trong một dự án mã nguồn mở, nói chung không có thông số kĩ thuật hoặc thiết kế.
Mặc dù thiếu các chi tiết kĩ thuật và thiết kế, vậy làm sao các dự án mả nguồn mở thành công như vây? Trong thế giới mã nguồn đóng, gồm các chuyên gia có chuyên môn cao. Nhưng thách thức mã nguồn mở đã thu hút một số chuyên gia phần mềm tốt nhất. Nói cách khác, một dự án mã nguồn mở thành công, mặc dù thiếu chi tiết kĩ thuật hoặc thiết kế, nhưng nếu các kĩ năng của các cá nhân làm việc về dự án là tuyệt vời thì dự án vẫn có thể hoạt động hiệu quả và thành công.
Tóm tắt:
Hầu hết các dự án mã nguồn mở thành công qua hai giai đoạn. Thứ nhất là một cá nhân có có ý tưởng chương trình ban đầu, đưa lên mạng để mọi người cùng sử dụng. Thứ hai, giai đoạn đồng phát triển, tức là mọi người cùng sử dụng phần mềm để phát hiện lỗi và phát triển phần mềm ( gồm 3 giai đoạn bảo trì sửa chữa, bảo trì phát triển, bảo trì tương thích)
Sự khác nhau giữa mô hình vòng đời mã nguồn mở - đóng
· Trong mã nguồn đóng, Người dùng không được truy nhập vào mã nguồn và chỉ có thể gửi báo cáo lỗi đến nhà cung cấp. Trong mã nguồn mở, người dùng có thể truy cập vào mã nguồn, gửi thông báo lỗi hoặc ý tưởng phát triển.
· Thời gian đưa ra phiên bản mới. Mã nguồn đóng thường là sau 1 năm và được kiểm nghiệm gắt gao. Mã nguồn mở là bất cứ khi nào, khi phiên bản sau được kiểm nghiệm tối thiểu.
Trong cả 3 mô hình vòng đời, một phiên bản đầu tiên được sản xuất. Trong trường hợp mô hình nhanh chóng tạo mẫu, phiên bản ban đầu này được bỏ đi, và sản phẩm mục tiêu sau đó được quy định và được thiết kế trước khi được mã hóa. Trong cả hai mô hình code-sửa chữa và mã nguồn mở, các phiên bản đầu tiên được làm lại cho đến khi nó trở thành sản phẩm mục tiêu.
Cácopen-source life-cycle bị hạn chế bởi chính ứng dụng của nó.Các open-source model đã thành công được sử dụng cho dự án phần mềm cơ sở hạ tầng nhất định, chẳng hạn như hệ điều hành (Linux, OpenBSD, Mach, Darwin), trình duyệt Web (Firefox, Netscape), trình biên dịch (gcc), các máy chủ Web (Apache), hoặc hệ thống quản lý cơ sở dữ liệu (MySQL). Mặt khác, rất khó để tưởng tượng phát triển mã nguồn mở của một sản phẩm phần mềm chỉ được sử dụng trong một tổ chức thương mại. Mấu chốt việc phát triển của phần mềm mã nguồn mở là sự phát triển của cả nhóm phát triển lẫn những người sử dụng. Do đó, life-cycle open-sourcesẽ không đc áp dụng trừ khi ng sử dụng có thể mang lại lợi ích cho nhà cung cấp.
Tại thời điểm viết bài, có khoảng 350.000 dự án nguồn mở tại SourceForge.net và FreshMeat.net. Khoảng một nửa số chúng thậm chí chưa bao giờ thu hút được một đội ngũ làm việc trên dự án. Trong số những người đã bắt đầu công việc, những người ko hoàn thành và ngưng phát triển chiếm đa số. Nhưng khi các mô hình nguồn mở đã làm việc, đôi khi vô cùng thành công. Các sản phẩm mã nguồn mở được liệt kêtrong dấu ngoặc đơn trong đoạn trước đó được sử dụng rộng rãi, hầu hết trong số họ được sử dụng trên mộtcơ sở thường xuyên bởi hàng triệu người sử dụng.Giải thích cho sự thành công của mô hình vòng đời mã nguồn mở được trình bày trongChương 4 trong bối cảnh các khía cạnh đội ngũ tổ chức phần mềm mã nguồn mởdự án.
2.9.5 Agile quá trình
Lập trình cực đoan [Beck, 2000] là một cách tiếp cận mới gây tranh cãi để phát triển phần mềm dựa trên mô hình lặp đi lặp lại và gia tăng. Bước đầu tiên là đội ngũ phát triển phần mềm xác định các tính năng khác nhau ,khách hàng sẽ đưa ra những tính năng họ thích. Đối với mỗi tính năng như vậy, nhóm nghiên cứu thông báo cho khách hàng thời gian và chi phí để thực hiện tính năng này. Bước đầu tiên này tương ứng với các yêu cầu và quy trình công việc phân tích của mô hình lặp đi lặp lại và gia tăng (hình 2.4).Khách hàng lựa chọn các tính năng được bao gồm trong mỗi kế xây dựng bằng cách sử dụng phân tích chi phí - lợi ích (Mục 5.2), có nghĩa là, trên cơ sở thời gian và chi phí dự toán được cung cấp bởi đội ngũ phát triển cũng như các lợi ích tiềm năng của tính năng kinh doanh của mình. Xây dựng đề xuất được chia thành các phần nhỏ hơn gọi là nhiệm vụ. Một lập trình viên đầu tiên rút ra các trường hợp thử nghiệm cho một công việc, điều này được gọi là định hướng phát triển thử nghiệm (TDD). Hai lập trình viên làm việc cùng nhau trên một máy tính (cặp lập trình) [Williams, Kessler, Cunningham, và Jeffries, 2000], thực hiện các nhiệm vụ và đảm bảo rằng tất cả các trường hợp thử nghiệm hoạt động chính xác. Hai lập trình viên thay thế gõ mỗi 15 hoặc 20 phút, các lập trình viên không được đánh máy cẩn thận kiểm tra các mã trong khi nó đang được nhập vào bởi đối tác của mình. Nhiệm vụ này sau đó được tích hợp vào phiên bản hiện tại của sản phẩm. Lý tưởng nhất, thực hiện và tích hợp một nhiệm vụ nên không có nhiều hơn một vài giờ. Nói chung, một số cặp sẽ thực hiện các nhiệm vụ song song, do đó, việc đối chiếu là cơ bản liên tục. Các thành viên trong nhóm thay đổi mã hóa các đối tác hàng ngày, nếu có thể, học hỏi từ các thành viên khác làm tăng mức độ kỹ năng của tất cả mọi người. TDD kiểm tra các trường hợp được sử dụng cho nhiệm vụ này được giữ lại và sử dụng trong tất cả các thử nghiệm hội nhập sâu hơn.
Một số nhược điểm để lập trình cặp đôi đã được quan sát trong thực tế [Drobka, Noftz, và Raghu, 2004]. Ví dụ, cặp lập trình đòi hỏi khối lượng lớn thời gian không bị gián đoạn, và các chuyên gia phần mềm có thể có khó culty trong fi nding 3 - 4 giờ các khối thời gian. Ngoài ra, cặp lập trình không luôn luôn làm việc tốt với các cá nhân nhút nhát hay độc đoán, hoặc với hai lập trình viên thiếu kinh nghiệm.
Một số nhược điểm để lập trình cặp đôi đã được quan sát trong thực tế [Drobka, Noftz, và Raghu, 2004]. Ví dụ, cặp lập trình đòi hỏi khối lượng lớn thời gian không bị gián đoạn, và các chuyên gia phần mềm có thể có khó khăn trong việc tìm kiếm 3 - 4 giờ các khối thời gian. Ngoài ra, các cặp lập trình sẽ xảy ra vấn đề khi thành có cá nhân nhút nhát , độc đoán hoặc hai lập trình viên thiếu kinh nghiệm
Một số tính năng của lập trình cực đoan (XP) là hơi khác nhau từ các phần mềm thường được phát triển:
· Các máy tính của nhóm XP được thiết lập ở trung tâm của một căn phòng lớn lót với buồng vệ sinh nhỏ.
· Một đại diện khách hàng làm việc với đội ngũ XP ở tất cả các lần.
· Không có cá nhân có thể làm việc thêm giờ trong hai tuần liên tiếp.
· Có chuyên môn không có. Thay vào đó, tất cả các thành viên của đội ngũ làm việc XP trên các yêu cầu, phân tích, thiết kế, mã, và thử nghiệm.
· Không có bước thiết kế tổng thể trước khi các bản xây dựng khác nhau được xây dựng.Thay vào đó, thiết kế được thay đổi trong khi sản phẩm đang được xây dựng. Thủ tục này được gọi là tái cấu trúc.Bất cứ khi nào một trường hợp thử nghiệm sẽ không chạy, các mã được tổ chức lại cho đến khi nhóm nghiên cứu được hài lòng rằng thiết kế đơn giản, đơn giản, và chạy tất cả các trường hợp kiểm tra thỏa đáng.
Hai từ viết tắt liên quan đến lập trình cực đoan là YAGNI (bạn sẽ không cần nó) và DTSTTCPW (làm điều đơn giản mà có thể có thể làm việc). Nói cách khác, một nguyên tắc lập trình cực đoan là để giảm thiểu số lượng các tính năng, không có cần thiết phải xây dựng một sản phẩm mà không nhiều hơn những gì khách hàng thực sự cần. Lập trình cực đoan là một trong một số mô hình mới được gọi chung là quá trình nhanh nhẹn. Mười bảy nhà phát triển phần mềm (sau này được đặt tên là Liên minh Agile) đã gặp tại một khu nghỉ mát trượt tuyết Utah trong hai ngày vào tháng 2 năm 2001 và sản xuất Tuyên Ngôn cho phát triển phần mềm Agile [Beck et al, 2001]. Nhiều người trong số những người tham gia trước đó đã là tác giả của phương pháp phát triển phần mềm của họ, bao gồm lập trình cực đoan [Beck, năm 2000, Crystal Cockburn, năm 2001, và Scrum [Schwaber năm 2001. Do đó, Liên minh Agile đã không quy định chu kỳ mô hình cụ thể c cuộc sống, mà là đặt ra một nhóm các nguyên tắc cơ bản đã được phổ biến phương pháp tiếp cận cá nhân của họ để phát triển phần mềm.
Agile quá trình được đặc trưng bởi sự nhấn mạnh đáng kể trên phân tích và thiết kế hơn trong hầu như tất cả các mô hình chu kỳ cuộc sống hiện đại khác. Thực hiện bắt đầu sớm hơn nhiều trong chu kỳ cuộc sống bởi vì phần mềm làm việc được coi là quan trọng hơn tài liệu chi tiết. Đáp ứng với những thay đổi trong các yêu cầu là một mục tiêu chính của quy trình nhanh nhẹn, và do đó là tầm quan trọng của hợp tác với khách hàng.
Một trong các nguyên tắc trong bản tuyên bố là phải gửi những sản phẩm phần mềm đang làm việc tốt, và lý tưởng là trong khoảng 2-3 tuần. một cách khác để đạt được mục đích là dung TimeBoxing cái mà đã được sử dụng nhiều năm và như là một kĩ năng để quản lý thời gian.
Các khoảng thời gian được dành cho mỗi nhiệm vụ và những thành viên trong nhóm có thể sử dụng thời gian đó để hoàn thành tốt công việc của mình. Trong phạm vi quá trình của Agile processes(qiai đoạn nhanh) thường thường thì được dành 3 tuần cho việc lặp lại(interation) . ở một khía cạnh khác thì nó sẽ làm cho khác hàng tin rằng một phiên bản mới nhiều chức năng hơn sẽ tới trong vong 3 tuần nữa. mặt khác thì người phát triển cũng biết rằng họ chỉ có 3 tuần để gửi đi 1 sản phầm đã được lặp lại mà không có bất kì sự phàn nàn nào của khác hàng. Khi mà khách hàng chọn sự Lặp lại thì có nghĩa là nó không có sự sửa đổi và phát triển.
Tuy nhiên nếu mà không thể hoàn thành nhiệm vụ bên trong Boxtime thì công việc có thể bị rút ngắn lại. hay có nghĩa là Agile Processes bị sử thời gian nhưng không sử những đặc trưng.
Những đặc trưng thường thấy khác của Agile Processes là có các buổi họp ngắn vào thời gian thường ngày. Tất cả các thành viên trong nhóm đều phải tham gia và đứng vào thành 1 vòng tròn hay hơn là ngồi vòng quanh 1 chiếc bàn. Và đảm bảo rằng cuộc họp đó chỉ diễn ra khoảng 15’. Mỗi thành viên đề phải trả lời 5 câu hỏi sau
· Bạn đã làm được gì kể từ buổi họp hôm qua?
· Tôi sẽ làm gì ngày hôm nay?
· Có vấn đề gì đã ngăn cản bạn đạt được mục đích?
· Chúng ta đã từng quên điều gì?
· Tôi đã học được gì và muốn chia sẻ với nhóm của minh?
Mục đích của cuộc hop đứng là nêu ra những vấn đề và giải pháp được đưa ra xuyên suốt buổi họp. cũng giống như TimeBoxing stand-up meeting cũng là một kĩ thuật quản lý rất tốt và được tận dụng trong quá trình Agile processes.
Alige processes là rất thành công với các dự án có quy mô nhỏ. Nhưng mà nó cũng chưa được thường xuyên sử dụng trong các dự án đủ lớn để quyết định rằng nó có phù hợp hay không. Thật may mắn là cho dù Aligle processes là tốt cho các dự án có quy mô nhỏ nhưng điều đó không có nghĩa là nó thể được sử dụng trong các dự án có quy mô trung bình và vừa, điều này sẽ được giải thích như sau.
Để đánh giá đúng(appreciate) vì sao nhiều sản phẩm phần mềm lại nghi ngờ về Aligle Processes trong phạm vi quá trình của các dự án phầm mềm chuyên nghiệp vừa và lớn.
Mọi người đều có thể gắn những mảnh gỗ lại dễ dàng thành ngôi nhà cho chó(doghouse) nhưng sẽ rât dại dột để xây một ngôi nhà có 3 phòng ngủ mà không có một bản thiết kế chi tiết. mở rổng ra nó còn cần các kĩ năng về hàn xì, đóng mái nhà….
Trên thực tế là một tòa nhà trọc trời có chiều cao bằng 1000 doghouse điều đó không có nghĩa là chúng ta xây dựng 1000 tòa nhà doghouse rùi trồng lên nhau. Vậy nên việc xây dựng các sản phẩm phần mềm quy mô lớn đòi hỏi rất nhiều kĩ năng phức tạp hơn là sản xuất các sản phẩm nhỏ.
Khóa để xác định rõ việc quyết định chọn Aligle Processes là tạo ra các bước đột phá chính trong CNPM là giá thành của công việc cài đặt và bảo trì. Có nghĩa là sử dụng Agile processes có kết quả trong việc giảm chi phí chó cài đặt và bảo trì. ở khía cạnh khác thì tái cấu trúc lại các thành phần bên trong của mỗi phần của Agile processes. Như đã giải thích ở trên thì sản phẩm không được thiết kế một cách toàn bộ mà thay vào đó là thiết kế sẽ được phát triển lên. Và code sẽ được tổ chức lại khi và chỉ khi thiết kế là không còn phù hợp dù bất kì lý do nào. Công việc thiết lập lại diễn ra trong suốt quá trình cài đặt và bảo trì. Nếu mà bản thiết kế của sản phẩm vượt qua được các bài kiểm tra và và có kết thúc mở và mềm dẻo thì quá trình bảo trì sẽ dễ dàng đạt được với chi phí thấp. tuy nhiên nếu mà thiết kế bị cấu trúc lại bất cứ khi nào có chức năng mới được thêm vào thì giá thành của quá trình cài đặt và bảo trì sẽ cao đến mức không thể chấp nhận được. như là hệ quả của việc tiếp cận cái mới chỉ có 1 vài dữ liệu của các cuộc thí nghiệm sẽ được phát triển Agile processes.
Tuy nhiên các cuộc thí nghiệm sẽ chỉ ra những đặc trưng quan trọng của Agile processes.
Tuyên bố phát triển nhanh phần mềm là đưa ra rằng Agile processes là cao cấp và có kỉ luật giống như Unified process. Những người hay nghi ngờ thì phản ứng rằng những đề suất ý tưởng của Agile processes là ít hơn các hacker. Tuy nhiên đó chỉ là mặt đất mà thôi. Có 2 sự liên kết với nhau nó có thể rất chặt chẽ và chứng minh bằng đặc trưng của Agile processes trong phạm vi khung làm việc của quá trình.
Cuối cùng thì Agile processes là sử dụng tiếp cận các dự án có quy mô nhỏ và khi mà yêu cầu của khách hàng là mập mờ. rộng ra các đặc trưng của Agile processes có thể tận dụng trong phạm vi của Life cycle model.
Quân
Ngoài ra, một số các tính năng củaquá trình nhanh nhẹn có thể được sử dụng hiệu quả trong bối cảnh của vòng đời mô hình khác.
2.9.6 Mô hình vòng đời đồng bộ hóa và ổn định (Synchronize-and-Stabilize Life-Cycle Model)
Microsoft, Inc là nhà sản xuất lớn nhất thế giới về phần mềm COTS. Phần lớn những gói đó được xây dựng bằng cách sử dụng một phiên bản của mô hình lặp đi lặp lại và gia tăng đã được gọi là đồng bộ hóa-và-ổn định vòng đời mô hình [Cusumano và Selby, năm 1997] .
Giai đoạn phân tích yêu cầu được thực hiện bằng cách phỏng vấn nhiều khách hàng tiềm năng cho gói và lọc ra một danh sách các tính năng ưu tiên cao nhất cho khách hàng. Một tài liệu đặc điểm kỹ thuật được soạn thảo ngay . Tiếp theo, tác phẩm được chia thành ba hay bốn xây dựng. Việc đầu tiên xây dựng bao gồm các tính năng quan trọng nhất, xây dựng thứ hai bao gồm quan trọng tiếp theo tính năng quan trọng nhất, và như vậy. Mỗi xây dựng được thực hiện bởi một số nhóm nhỏ làm việc song song. Vào cuối mỗi ngày, tất cả các đội đồng bộ hóa, có nghĩa là khi họ đặt hoàn thành một phần thành phần với nhau và kiểm tra và gỡ lỗi kết quả sản phẩm. Ổn định được thực hiện tại cuối mỗi bản xây dựng. Bất kỳ lỗi còn lại đã được phát hiện được cố định, và ngay lập tức họ đóng băng xây dựng, có nghĩa là không còn thay đổi nào sẽ được thực hiện với các thông số kỹ thuật.
Các bước đồng bộ hóa lặp đi lặp lại đảm bảo rằng các thành phần khác nhau luôn luôn làm việc cùng nhau. Một thuận lợi của việc thực hiện thường xuyên của các phần xây dựng sản phẩm là các nhà phát triển sớm có được cái nhìn sâu sắc vào hoạt động của sản phẩm và có thể sửa đổi các yêu cầu nếu cần thiết trong tiến trình của một xây dựng. Mô hình vòng đời có thể được sử dụng ngay cả khi các đặc điểm kĩ thuật cụ thể ban đầu không đầy đủ. Mô hình đồng bộ hóa và ổn định xem xét kĩ hơn nữa trong mục 4.5 , tại đây nhóm, tổ chức sẽ được thảo luận chi tiết .
Mô hình xoắn ốc được để lại xem xét ở mục sau vì nó kết hợp các khía cạnh của tất cả các mô hình khác được mô tả tại mục 2,9.
2.9.7 Mô hình vòng đời Xoắn ốc (Spiral Life-Cycle).
Như đã nêu trong mục 2.5, một yếu tố rủi ro luôn luôn tham gia vào sự phát triển của phần mềm. Ví dụ, nhân sự chủ chốt có thể từ chức trước khi sản phẩm có được đầy đủ tài liệu chi tiết. Các nhà sản xuất phần cứng sản phẩm nói khách quan có thể bị phá sản. Quá nhiều hay quá ít, có thể được đầu tư vào thử nghiệm và đảm bảo chất lượng . Sau khi chi tiêu hàng trăm ngàn đô la vào việc phát triển một sản phẩm phần mềm lớn đột phá công nghệ có thể làm cho toàn bộ sản phẩm vô giá trị. Một tổ chức có thể nghiên cứu và phát triển một hệ thống quản lý cơ sở dữ liệu, nhưng trước khi sản phẩm có thể được bán trên thị trường, gói có giá thấp hơn, chức năng tương đương được công bố bởi một đối thủ cạnh tranh. Các thành phần của một sản phẩm có thể không phù hợp với nhau khi hội nhập được thực hiện. Vì các lý do đó, các nhà phát triển phần mềm luôn cố gắng để giảm thiểu những rủi ro đến mức có thể.
Một cách để giảm thiểu một số loại rủi ro là xây dựng một nguyên mẫu. Như mô tả trong Mục 2.9.3, một cách tiếp cận để giảm nguy cơ rằng các sản phẩm giao nhận sẽ không đáp ứng các nhu cầu thực sự của khách hàng là xây dựng một nguyên mẫu nhanh chóng trong giai đoạn yêu cầu. Trong các giai đoạn tiếp theo, các phần khác của nguyên mẫu có thể thích hợp. Ví dụ, một điện thoại công ty có thể đưa ra một thuật toán mới, dường như có hiệu quả cao để định tuyến cuộc gọi thông qua một mạng lưới đường dài. Nếu sản phẩm được thực hiện nhưng không làm việc như mong đợi, công ty điện thoại sẽ lãng phí chi phí phát triển sản phẩm. Ngoài ra, làm phiền khách hàng và công việc kinh doanh của họ ở nơi khác. Kết quả này có thể tránh được bằng cách xây dựng một nguyên mẫu bằng chứng của khái niệm để xử lý chỉ định tuyến các cuộc gọi và thử nghiệm nó trên giả thuyết . Bằng cách này, hệ thống thực tế không được quấy rầy, và các chi phí thực hiện thuật toán chỉ định tuyến, các công ty điện thoại có thể xác định xem nó đáng giá để phát triển một bộ điều khiển toàn bộ mạng kết hợp các thuật toán mới.
Một nguyên mẫu bằng chứng của khái niệm không phải là một mẫu thử nghiệm nhanh chóng xây dựng để chắc chắn rằng yêu cầu đã được xác định chính xác, như mô tả trong mục 2.9.3. Thay vào đó, nó là nhiều hơn giống như một mẫu thử nghiệm kỹ thuật, có nghĩa là, một mô hình quy mô xây dựng để kiểm tra tính khả thi của việc xây dựng .Khi nhóm phát triển quan tâm đến việc một phần cụ thể của sản phẩm phần mềm đề xuất có thể được xây dựng không, lúc này một nguyên mẫu bằng chứng của khái niệm được xây dựng.
Ví dụ, các nhà phát triển có thể có quan tâm tới việc một tính toán cụ thể có thể được thực hiện một cách nhanh chóng đầy đủ hay không. Trong trường hợp đó, họ xây dựng một nguyên mẫu để kiểm tra thời gian tính toán đó. Hoặc họ có thể lo lắng rằng các font họ có ý định sử dụng cho tất cả các màn hình sẽ là quá nhỏ cho người dùng trung bình đọc mà không mỏi mắt. Trong trường hợp này, họ xây dựng một nguyên mẫu để hiển thị một số lượng màn hình khác nhau và xác định bằng thực nghiệm cho dù người dùng tìm thấy font chữ nhỏ và không dễ chịu .
Ý tưởng giảm thiểu rủi ro thông qua việc sử dụng các nguyên mẫu và các phương tiện khác là ý tưởng cơ bản của mô hình vòng đời xoắn ốc [Boehm, 1988]. Một cách đơn giản nhìn vào vòng đời này mô hình như mô hình thác nước với mỗi giai đoạn trước bằng cách phân tích rủi ro, như thể hiện trong hình 2.12. Trước khi bắt đầu mỗi giai đoạn, một nỗ lực được thực hiện để giảm nhẹ (kiểm soát) rủi ro. Nếu nó không thể giảm thiểu đáng kể tất cả các rủi ro , thì sau đó dự án ngay lập tức bị chấm dứt.
Cường
Nguyên mẫu có thể được sử dụng hiệu quả để cung cấp thông tin về các lớp rủi ro nhất định. Ví dụ, hạn chế thời gian nói chung có thể được thử nghiệm bằng cách xây dựng một nguyên mẫu và đo lường xem các mẫu thử nghiệm có thể đạt được hiệu suất cần thiết. Nếu các mẫu thử nghiệm là một đại diện chính xác chức năng của các tính năng của sản phẩm có liên quan, từ đó các phép đo được thực hiện trên nguyên mẫu cung cấp cho các nhà phát triển một ý tưởng tốt cũng như không hạn chế thời gian có thể đạt được.
Các khu vực khác của rủi ro ít tuân theo nguyên mẫu, ví dụ, nguy cơ nhân viên phần mềm cần thiết để xây dựng các sản phẩm không thể thuê được hoặc nhân sự chủ chốt có thể từ chức trước khi dự án hoàn thành. Một nguy cơ tiềm năng là một nhóm cụ thể có thể không có đủ thẩm quyền để phát triển một sản phẩm cụ thể trên quy mô lớn.Một nhà thầu thành công người là người xây dựng nhà ở có thể không có khả năng xây dựng một văn phòng cao tầng phức tạp. Trong cùng một cách, có sự khác biệt chủ yếu giữa phần mềm quy mô nhỏ và phần mềm quy mô lớn, và tạo ra mẫu ít đc sử dụng. Nguy cơ này không thể được giảm nhẹ bằng cách kiểm ra hiệu suất của đội ngũ trên một nguyên mẫu nhỏ hơn, trong đó đội ngũ đưa ra các vấn đề cụ thể để phần mềm quy mô lớn ko có thể phát sinh. Một lĩnh vực khác của rủi ro mà tạo mẫu không thể được sử dụng là đánh giá việc cung cấp đầy hứa hẹn của một nhà cung cấp phần cứng. Một chiến lược phát triển có thể áp dụng để xác định bằng cách nào đối xử tốt với khách hàng trước đây của nhà cung cấp, nhưng hiệu suất quá khứ không có nghĩa là một yếu tố dự báo hiệu suất của tương lai. Một điều khoản phạt trong hợp đồng giao hàng là một cách để đảm bảo rằng phần cứng cần thiết được giao đúng thời gian, nhưng làm gì nếu nhà cung cấp từ chối ký một thỏa thuận bao gồm điều khoản như vậy? Ngay cả với một khoản phạt, giao hàng chậm có thể xảy ra và cuối cùng dẫn đến hành động pháp lý có thể kéo dài trong nhiều năm. Trong khi đó, các nhà phát triển phần mềm có thể bị phá sản vì ko giao phần cứng đã hứa gây ra cho phần mềm hứa hẹn. Trong thời gian ngắn,trong khi tạo mẫu giúp giảm nguy cơ trong một số lĩnh vực, trong các lĩnh vực khác lại là một một phần câu trả lời tốt nhất, và vẫn còn những người khác không có câu trả lời cho tất cả.
Mô hình xoắn ốc sẽ được hiển thị trong hình 2.13. Các kích thước bố trí hình tròn đại diện cho chi phí tích lũy cho đến nay, và kích thước góc đại diện cho sự tiến bộ thông qua hình xoắn ốc. mỗi chu kỳ xoắn ốc tương ứng với một giai đoạn. Một giai đoạn bắt đầu (trong góc phần tư phía trên bên trái)bởi việc xác định mục tiêu của giai đoạn đó, lựa chọn thay thế để đạt được các mục tiêu và các ràng buộc đối với những lựa chọn đó. Kết quả củaquá trình này là một chiến lược để đạt được những mục tiêu đó. Tiếp theo, chiến lược đó được phân tích từ những quan điểm của rủi ro. Những nỗ lực được thực hiện để giảm thiểu mọi rủi ro tiềm năng, trong một số trường hợp bằng cách xây dựng một nguyên mẫu. Nếu rủi ro nhất định ko có thể giảm nhẹ, dự án có thể chấm dứt ngay lập tức. Ở một số trường hợp, tuy nhiên, một quyết định có thể được thực hiện để tiếp tục dự án nhưng trên một quy mô nhỏ hơn. Nếu tất cả các rủi ro được giảm nhẹ thành công, bước phát triển tiếp theo được bắt đầu (dưới cùng bên phải nhóm C). Góc phần tư của mô hình xoắn ốc tương ứng với mô hình thác nước cổ điển.Cuối cùng, kết quả của giai đoạn đó được đánh giá và giai đoạn tiếp theo được lên kế hoạch.
Mô hình xoắn ốc đã được sử dụng thành công để phát triển một loạt các sản phẩm.trong tập hợp 25 dự án, trong đó các mô hình xoắn ốc được sử dụng kết hợp với biện pháp khác để tăng năng suất, năng suất của mỗi dự án tăng ít nhất 50% so với mức sản xuất trước và tăng 100% trong hầu hết các dự án[Boehm, 1988].Để có thể quyết định xem mô hình xoắn ốc nên được sử dụng cho một dự án nhất định, điểm mạnh và điểm yếu của mô hình xoắn ốc được đánh giá.
Mô hình xoắn ốc có một số điểm mạnh. Nhấn mạnh vào việc lựa chọn thay thế và hạn chế hỗ trợ tái sử dụng các phần mềm hiện có (Mục 8.1) và kết hợp của chất lượng phần mềm như là mộtmục tiêu cụ thể.Ngoài ra, một vấn đề phổ biến trong phát triển phần mềm được xác định khi các sản phẩm của một giai đoạn cụ thể đã được thử nghiệm đầy đủ. Chi tiêu quá nhiều thời gian thử nghiệm là một sự lãng phí tiền bạc, và cung cấp các sản phẩm có thể bị trì hoãn quá mức. Ngược lại, nếu quá ít thử nghiệm được thực hiện, sau đó chuyển giao phần mềm có thể chứa đựng những lỗi còn sót lại, dẫn đến hậu quả khó chịu cho các nhà phát triển. Mô hình xoắn ốc trả lời câu hỏi này về những rủi ro sẽ phát sinh do không làm đủ thử nghiệm hoặc do thực hiện thử nghiệm quá nhiều. Có lẽ quan trọng nhất, bên trong cấu trúc của mô hình xoắn ốc, bảo trì giao hàng đơn giản chỉ là mộtvòng xoắn ốc;cơ bản không có sự phân biệt giữa bảo trì giao hàng và phát triển. Vì vậy,vấn đề bảo trì giao hàng đôi khi bi chê bai bởi các chuyên gia phần mền ko biết gì , vì bảo trì giao hang xử lý theo cùng một cách như phát triển.
Thanh
Có những hạn chế trong việc áp dụng mô hình xoắn ốc. Cụ thể, trong hình thái hiện tại của nó, mô hình được thiết kế dành riêng cho việc phát triển nội bộ của những phần mềm quy mô lớn. Xét một dự án nội bộ, có nghĩa là, một dự án mà người phát triển và người đặt hàng là thành viên thuộc cùng một tổ chức. Nếu việc phân tích rủi ro đi đến kết quả rằng dự án này nên được chấm dứt thì nhân viên phần mềm đơn giản sẽ được bố trí đến một dự án khác. Tuy nhiên, một khi hợp đồng đã được ký giữa tổ chức phát triển và người đặt hàng nội bộ, một sự cố gắng của cả 2 bên để chấm dứt mà có thể dẫn đến một vụ kiện vi phạm hợp đồng. Do đó, trong trường hợp của hợp đồng phần mềm, tất cả rủi ro phân tích được phải được thực hiện bởi cả người phát triển và người đặt hàng trước khi hợp đồng được ký kết, không giống như trong mô hình xoắn ốc.
Hạn chế thứ hai trong mô hình xoắn ốc liên quan đến quy mô của dự án. Cụ thể, Mô hình xoắn ốc chỉ có thể áp dụng với những dự án lớn. Điều đó có nghĩa rằng việc thực hiện phân tích rủi ro không có ý nghĩa nếu chi phí của việc thực hiện phân tích rủi ro tương đương với chi phí của cả dự án, hoặc nếu việc thực hiện phân tích rủi ro ảnh hưởng đáng kể đên lợi nhuận tiềm năng. Thay vào đó,để thực hiện người phát triển đầu tiên phải quyết định nguy cơ lớn như thế nào và sau đó là phân tích rủi ro (nếu có).
Một thế mạnh của mô hình xoắn ốc là điều khiển nguy cơ, nhưng chính điều này cũng có thể là một nhược điểm. Trừ khi người phát triển phần mềm có kinh nghiệm trong trong việc định vị rủi ro có thể xảy ra và phân tích rủi ro một cách chính xác; đó là một điều thực sự nguy hiểm, một nhóm có thể tin tưởng rằng tất cả sẽ tốt đẹp vào một thời gian nào đó trong dự án nhưng trên thực tế điều đó cũng đứng đầu những hiểm họa.Chỉ nếu những thành viên của đội phát triển là các nhà phân tích có thẩm quyền quyết định quản lý thì mới sử dụng mô hình xoắn ốc.
Tuy nhiên, nhìn tổng thể, điểm yếu lớn của mô hình xoắc ốc, cũng như mô hình thác nước và mô hình nhanh chóng tạo mẫu là giả định rằng phần mềm đó được phát triển ở nhiều pha rời rạc. Tuy nhiên, trên thực tế, phát triển phần mềm là lặp lại và gia tăng, như được phản xạ trong các mô hình cây tiến hóa (mục 2.2) hoặc mô hình lặp lại và gia tăng (mục 2.5).
2.10 So sánh các mô hình vòng đời
Có 9 loại mô hình vòng đời phần mềm khác nhau đã được nghiên cứu với sự quan tâm đặc biệt vào một số điểm mạnh, điểm yếu của chúng. Mô hình mã hóa và sửa chữa (code-and-fix model) (muc 2.9.1) nên được tránh. Mô hình thác nước (mục 2.9.3) là một mô hình được biết đến. Đã có hiểu biết về điểm mạnh của nó, và do đó là điểm yếu của nó (????) . Mô hình nhanh chóng tạo mẫu đã được phát triển như một trải nghiệm để cảm nhận cụ thể một điểm yếu của mô hình thác nước, cụ thể là, sản phẩm được giao không phải là những gì người đặt hàng thực sự cần. Tuy nhiên, vẫn không đủ bằng chứng chó thấy phương pháp này là tốt hơn mô hình thác nước ở những khía cạnh khác. Mô hình vòng đời mã nguồn mở đã thành công đáng kinh ngạc trong số ít các trường hợp khi sử dụng để xây dựng cơ sở hạ tầng phần mềm (mục 2.9.4). Quá trình Agile (mục 2.9.5) là một tập hợp các phương pháp tiếp cận mới cho đến nay gây tranh cãi xuất hiện để lam việc, những cho phần mềm quy mô nhỏ. Mô hình đồng bộ hóa và ổn định (mục 2.9.6) đã được sử dụng với thành công lớn của Microsoft, nhưng vẫn chưa có chứng cứ của sự thành công so sánh trong nền văn hoá khác của công ty. Tuy nhiên, thay thế khác là sử dụng mô hình xoắn ốc (mục 2.9.7), nhưng chỉ khi các nhà phát triển được huấn luyện đầy đủ trong phân tích rủi ro và giải quyết nguy cơ. Mô hình cây tiến hóa (mục 2.2) và mô hình lặp và gia tăng (mục 2.5) là cách gần nhất để sản xuất phần mềm trong thực tế. Một so sánh tổng thể xuất hiện trong hình 2.14.
Hình 2.14:
So sánh các mô hình vòng đời mô tả trong chương này, bao gồm cả phần trong đó được xác định
MÔ HÌNH VÒNG ĐỜI
ƯU ĐIỂM
NHƯỢC ĐIỂM
Mô hình cây tiến hóa
Chặt chẽ
Mô hình vòng đời lặp và gia tăng
Chặt chẽ
Nền tảng của quá trình hợp nhất
Mô hình vòng đời mã hóa và sửa chữa
Phạt tiền cho các chương trình ngắn mà không cần bảo trì
Hoàn toàn không đạt yêu cầu cho các chương trình không tầm thường
Mô hình vòng đời thác nước
Phương pháp xử lý tiếp cận
Tài liệu hướng dẫn
Sản phẩm cung cấp không thể đáp ứng nhu cầu của khách hàng
Mô hình nhanh chóng tạo mẫu
Đảm bảo các sản phẩm cũng cấp đáp ứng nhu cầu của khách hàng
Chưa vượt qua được tất cả các hoài nghi
Mô hình vòng đời mã nguồn mở
Đã làm việc tốt trong một số ít trường hợp
Hạn chế ứng dụng
Thường không làm việc
Quá trình Agile
Làm việc tốt khi yêu cầu của khách hàng mơ hồ, không rõ ràng
Dường như chỉ làm việc trên các dự án quy mô nhỏ
Mô hình vòng đời đồng bộ hóa và ổn định
Yêu cầu trong tường lai của người dùng được đáp ứng
Đảm bảo các thành phần có thể tích hợp thành công
Không được sử dụng rộng rãi hơn ở Microsoft
Mô hình vòng đời xoắn ốc
Điều khiển rủi ro
Có thể sử dụng cho các dự án quy mô lớn, các sản phẩm nội bộ
Người phát triển phải có trình độ về phân tích rủi ro và giải quyết rủi ro
Mỗi tổ chức phát triển phần mềm nên quyết định một mô hình vòng đời phần mềm thích hợp cho tổ chức đó và các nhà quản lý, nhân viên của mình cũng như quá trình phát triển phần mềm, Và nên thay đổi mô hình vòng đời phụ thuộc vào các tính năng của sản phầm cụ thể đang được phát triển. Một mô hình kết hợp các khía cạnh thích hợp của các mô hình vòng đời khác nhau, sử dụng các ưu điểm cũng như giảm thiểu khuyết điểm của chúng.
Bạn đang đọc truyện trên: Truyen2U.Com