Đề tài Phương pháp phát triển phần mềm linh hoạt

chu kỳ phát triển phần mềm tăng dần, và đạt mức tăng lớn nhất trong vòng mỗi 4 tháng, tốt nhất là trong vòng từ 1 đến 3 tháng. Điều cực kỳ quan trọng là sự hợp tác và giao tiếp giữa các thành viên trong nhóm. Phương pháp Crystal không giới hạn số lượng phương pháp thực thi, số lượng công cụ, số lượng các sản phẩm, và đặc biệt cho phép các thực thi của các phương thức khác nhiuw Scrum hay XP... Hơn nữa, cách tiếp cận này còn cho phép giảm bớt các sản phẩm trung gian và thể hiện cụ thể trong phạm vi một quy ước cho các dự án riêng lẻ và phát triển chúng như là các dự án mở. Hiện nay có 3 phương thức chính trong Crystal đó là: Crystal Clear, Crystal Orange, Crystal Orange Web. Tất cả các phương thức trong gia đình Crystal đều dựa trên những chuẩn hợp đồng đã ký, sản phẩm, chi phí, công cụ, và các quy tắc chuẩn để thực thi trong suốt quá trình sản xuất. Crystal Clear và Crystal Orange là hai trong số các thành viên của gia đình Crystal đã được xây dựng và sử dụng (Cockburn 1998, Cockburn 2002a). Crystal Orange (Cockburn 1998) cũng biểu diễn các hoạt động trong một quá trình. Crystal Clear được thiết kế cho những dự án rất nhỏ được phát triển bởi khoảng 6 thành viên. Tuy nhiên với cá phần mở rộng của nó có thể phù hợp với một dự án có từ 8-10 thành viên. Một đội sử dụng phương thức Crystal nên làm việc cùng nhau trong một phòng để tiện việc trao đổi, bàn bạc. Crystal Orange được thiết kế cho một dự án cỡ vừa, có từ 10 đến 40 thành viên và với thời gian thực hiện dự án là 1 đến 2 năm. Dĩ nhiên một dự án có 50 thành viên vẫn có thể sử dụng phương thức này nhưng với điều kiện phải thêm vào cho nó phương thức kiểm chứng. Một dự án sử dụng Crystal Orange có thể được chia nhỏ cho nhiều nhóm phát triển với cross-functional sử dụng chiến lược Holistic Deliversity. Tuy nhiên phương thức này không dành cho bản phát triển môi trường. Crystal Orange nhấn mạnh tầm quan trọng của time-to-market. Sự hoán đổi giữa phân phối rộng rãi và sự thay đổi nhanh trong yêu cầu và thiết kế kết quả trong một số giới hạn các phiên bản cho phép giảm bớt giá thành để bảo trì chúng nhưng vẫn giữ cho chức năng giao tiếp giữa các đội phát triển được hiệu quả. Policy standards: Đây là những thực thi cần được áp dụng trong suốt quá trình phát triển phần mềm. Cả Crystal Clear và Crystal Orange đều đưa ra các tiêu chuẩn chính sách sau: 1. Mở rộng các bản phân phối một cách đều đặn 2. Quy trình theo dõi những thành phần quan trọng được đưa vào các phiên bản, chú ý vào những quyết định hơn là viết tài liệu 3. Hướng sự chú ý của người dùng. 4. Nghiên cứu chức năng tự động hóa kiểm chứng 5. Coi như có 2 người sử dụng đang quan sát bạn làm việc 6. Hội thảo về sản phẩm và những điều chỉnh phương thức thực thi ở đầu vào ở giữa mỗi bước lặp Chỉ có sự khác biệt duy nhất trong chính sách của 2 phương thức này là. Crystal Clear cho rằng nên tăng phiên bản khoảng 2 đến 3 tháng một lần, trong khi Crystal Orange lại cho rằng nên mở rộng tối đa là 4 tháng. Những chính sách này đặc trưng của phương thức Crystal, tuy nhiên chúng có thể bị thay thế bằng những phương thức tương đương như XP và Scrum. Work products: Cockburn cho rằng các sản phẩm của Crystal Clear và Crystal Orange thường có những quy mô khác nhau. Tuy nhiên cũng có những sản phẩm tương tự nhau như: phiên bản liên tục, mô hình đối tượng thông thường, sổ tay người dùng, các trường hợp kiểm thử, mã di trú. Thêm vào đó Crystal Clear bao gồm những chú thích để mổ tả các đặc điểm, trái lại ở Crystal Orange lại đòi hỏi các tài liệu đặc tả yêu cầu. Local matters: Đó là những thủ tục của Crystal mới được ứng dụng, tuy nhiên nó hoàn toàn tách biệt với bản thân dự án, những thủ tục này có phạm vi khác nhau giữa hai phương thức Crystal Clear và Crystal Orange. Cả hai phương thức trên đều cho rằng mẫu cho một sản phẩm tốt là mã nguồn, kiểm tra truy hồi, và sử dụng giao diện chuẩn có thể cài đặt và bảo trì bởi chính đội phát triển. Tools: Công cụ mà Crystal Clear yêu cầu là công cụ biên dịch, công cụ tạo các phiên bản, công cụ cấu hình và quản lý và các trang in. Công cụ tối thiểu mà Crystal Orange yêu cầu là công cụ tạo các phiên bản, lập trình, kiểm thử, giao tiếp, theo dõi dự án, đồ họa và biện pháp trình diễn. Standards: Crystal Orange đề xuất việc lựa chọn những ký hiệu chuẩn, thiết kế thỏa thuận, định dạng chuẩn và chất lượng chuẩn (Cockburn 1998) sẽ được sử dụng trong dự án. Activities: Các hoạt động được thể hiện qua sơ đồ sau: 4. Feature Driven Development Feature Driven Development (FDD) là phương pháp tiếp cận linh hoạt dành cho phát triển hệ thống. FDD không bao phủ toàn bộ quy trình phát triển phần mềm mà nó tập trung vào giai đoạn thiết kế và xây dựng. Tuy nhiên nó được thiết kế để làm việc với những hoạt động khác của một dự án phát triển phần mềm và không yêu cầu bất cứ một mô hình quy trình riêng nào. Nó tập trung vào chất lượng sản phẩm xuyên suốt quy trình. FDD bao gồm 5 quy trình liên tục và cung cấp những phương thức, kỹ thuật và những hướng dẫn mà nhà đầu tư cần đến để chuyển giao hệ thống. Phần lặp của quy trình FDD hỗ trợ phát triển linh hoạt với sự thích nghi nhanh chóng với những thay đổi muộn trong yêu cầu của khách hàng. - Phát triển một mô hình toàn thể (Develop an Overall Model) Khi việc phát triển một mô hình toàn thể bắt đầu, các chuyên gia trong lĩnh vực này họ đã nhận thức được phạm vi, khung cảnh và yêu cầu của hệ thống để xây dựng. Các yêu cầu được tài liệu hóa như việc sử dụng các trường hợp hoặc các chức năng đặc biết sẽ có thể xuất hiện ở bước này. Tuy nhiên FDD không địa chỉ rõ ràng vấn đề lấy lại và quản lý các yêu cầu. Các chuyên gia cũng được gọi là “walkthrough” trong mỗi đội và là người kiến trúc sư chính có hiểu biết cao về hệ thống. Mô hình này có thể được chia nhỏ ra thành các nhóm và mỗi nhóm sẽ có các “walkthrough” phụ trách. Sau “walkthrough” các thành viên trong nhóm phát triển sẽ chia làm các nhóm nhỏ để trao đổi và thảo luận nhằm xây dựng một hệ thống tốt nhất. - Xây dựng một danh sách các tính năng (Build a Features List) Những chuyên gia, mô hình đối tượng, và những tài liệu về những yêu cầu đã có để tạo ra nền tảng tốt cho việc xây dựng một liệt kê các tính năng thông minh cho hệ thống đang được phát triển. Trong bản liệt kê, người phát triển hệ thống sẽ trình bày mỗi chức năng giá trị riêng biệt được xây dựng trong hệ thống. Chức năng sẽ được trình bày trong các nhóm bao gồm các chức năng trọng yếu đã được cài đặt. Thêm vào đó, các tính năng quan trọng này lại được chia ra cho các đặc điểm khác thiết lập. Sự biểu diễn lại này khác nhau đối với các phạm vi khác nhau. Liệt kê này sẽ được kiểm tra lịa bởi người dùng hoặc các nhà đầu tư cho một hệ thống hiệu quả và trọn vẹn. - Lập kế hoạch nhờ vào tính năng (Plan by Features): Bao gồm việc tạo ra các kế hoạch cao cấp hơn, mỗi đặc điểm sẽ được sắp xếp theo thứ tự quyền ưu tiên và phụ thuộc và được ấn định cho người đứng đầu nhóm lập trình. Ngoài ra, các lớp được đồng nhất trong một quy trình “mô hình phát triển toàn thể” sẽ được phân công cho các lập trình viên khác. - Thiết kế theo tính năng và xây dựng theo tính năng (Design by Feature and Build by Feature): - Một nhóm nhỏ các tính năng được lựa chọn từ tập hợp các tính năng. Những nhóm tính năng này được các đội phát triển. Quy trình thiết kế bằng tính năng và xây dựng bằng tính năng là những thủ tục có thể được lặp lại trong suốt quá trình những tính năng đã lựa chọn được sản xuất. Một bước lặp cần từ vài ngày cho tới tối đa 2 tuần để thực hiện. Sau khi thực hiện thành công một bước lặp, những tính năng đã hoàn thành được đưa vào trong chương trình chính trong khi vòng lặp thiết kế và xây dựng bắt đầu với một nhóm các tính năng mới từ tập các tính năng. 5. The Rational Unified Process Ration Unified Process (viết tắt làRUP) được phát triển bởi Philippe Kruchten, Ivar Jacobsen và những thành viên khác tại Ration Corporation để bổ sung cho UML (Unified Modelling Language). RUP là một phương thức tiếp cận những hệ thống hướng đối tượng, và được sử dụng để nắm bắt các yêu cầu mẫu và xây dựng nền tảng hệ thống. RUP nghiêng về hướng phát triển hướng đối tượng. Nó không bác bỏ hoàn toàn những phương thức khác, mặc dù UML đặc biệt thích hợp với phát triển OO Vòng đời của một dự án RUP được chia làm 4 giai đoạn : Khởi đầu (Inception), Dự thảo (Elaboration), Xây dựng (Construction) và Chuyển giao (Transition). Những giai đoạn lại được chia thành những vòng lặp nhỏ (interation). Khoảng thời gian của một vòng lặp có thể từ 2 tuần tới 6 tháng. - Giai đoạn Khởi đầu (Inception): Xem xét yêu cầu khách hàng và đưa ra các tiêu chí của dự án. Nhóm phát triển đưa ra những kiến trúc xây dựng khác nhau, bản kế hoạch và chi phí ước tính cho toàn bộ dự án. Ngoài ra những ước tính cho giai đoạn Dự thảo tiếp theo cũng được xây dựng. - Giai đoạn Dự thảo (Elaboration): Đây là giai đoạn xây dựng nền tảng kiến trúc phần mềm. Quy trình, cơ sở hạ tầng, và môi trường phát triển được mô tả chi tiết. Sau giai đoạn này, hầu hết các tình huống sử dụng và tất cả cả nhân tố ảnh hưởng được xác định và mô tả. Vào cuối giai đoạn, những phân tích được thực hiện để đánh giá khả năng xuất hiện rủi ro, sự ổn định của kiến trúc và chi phí xây dựng so với những gì bước đầu đã xác định. - Giai đoạn Xây dựng (Construction): tất cả những thành phần còn lại và tính năng của ứng dụng được phát triển, tích hợp vào sản phẩm và kiểm thử. Kết quả của giai đoạn xây dựng được tạo ra nhanh nhất có thể trong khi vẫn đảm bảo chất lượng sản phẩm. Một hoặc vài phiên bản được hoàn thành trong giai đoạn này trước khi chuyển sang giai đoạn Chuyển giao. - Giai đoạn chuyển giao (Transition Phase): là giai đoạn khi mà sản phẩm phần mềm đủ điều kiện để đưa tới cộng đồng người dùng. Dựa trên những phản hồi của người dùng, những phiên bản tiếp theo sẽ được vá lỗi hoặc gỡ bỏ đi những tính năng không cần thiết. Giai đoạn chuyển giao bao gồm kiểm thử beta, phân phối thí điểm, đào tạo người dùng, duy trì hệ thống, đưa sản phẩm ra thị trường, phân phối và thành lập đội kinh doanh. 6. Dynamic Systems Development Method (DSDM) Kể từ khi ra đời năm 1994, DSDM dần dần trở thành framework số 1 cho việc phát triển ứng dụng nhanh (RAD) ở UK. DSDM là frame work miễn phí và không bị ràng buộc bởi luật bản quyền dành cho sự phát triển RAD, được duy trì bởi DSDM Consortium. Những nhà phát triển duy trì rằng ngoài việc phục vụ như là một trong các phương pháp thông thường đã được chấp nhận DSDM cũng cung cấp một framework kiểm soát cho RAD, được bổ sung bởi sự hướng dẫn cách kiểm soát hiệu quả. Ý tưởng cơ bản đằng sau DSDM là thay vì cố định số lượng chức năng trong một sản phẩm và sau đó điểu chỉnh thời gian và chi phí để hoàn thành, nó sẽ cố định thời gian và chi phí hoàn thành và sau đó điều chỉn số lượng chức năng sao cho phù hợp. DSDM bao gồm 5 giai đoạn: feasibility study, business study, functional model iteration, design and build iteration và implementation. Hai giai đoạn đầu được thực hiện liên tiếp nhau và hoàn thành cùng thời điểm. 3 giai đoạn cuối, mỗi khi công việc phát triển hiện thời được hoàn thành, sẽ được lặp lại với quy mô lớn hơn. - Feasibility study là giai đoạn mà sự thích hợp của DSDM đối với dự án được đánh giá. Thông qua kiểu dự án và nhiều yếu tố khác quyết định được đưa ra, sử dụng DSDM hay là không. Thêm vào đó, giai đoạn này còn đề cập đến tính khả thi về kĩ thuật trong suốt dự án, những rủi ro trong đó và đưa ra bản báo cáo tính khả thi và bản phác thảo kế hoạch phát triển. - Business study là giai đoạn những đặc điểm cơ bản của nhiệm vụ cần thực hiện và công nghệ được phân tích. Phương pháp tiếp cận được đề nghị để tổ chức các hội thảo, nơi mà các chuyên gia của khách hàng tập trung đầy đủ để có thể xem xét, đánh giá tất cả các mặt có liên quan của hệ thống và có thể quyết định những gì được ưu tiên phát triển. Những quy trình nhiệm vụ chịu ảnh hưởng và những lớp người dùng được mô tả trong Business Area Definition. Việc xác định những lớp người dùng chịu ảnh hưởng đã thu hút được khách hàng. Sự mô tả ở mức cao hơn của những quy trình được trình bày trong Business Area Definition với dạng thích hợp như mô hình thực thể liên kết,… - Functional model iteration là giai đoạn lặp và gia tăng đầu tiên. Trong mỗi bước lặp, nội dung và phương pháp tiến cận được lên kế hoạch, đi qua bước lặp đó và kết quả được phân tích cho các bước lặp tiếp theo. Khi cả việc phân tích và viết mã hoàn thành, bản dùng thử được xây dựng và những kinh nghiệm thu được từ chúng được sử dụng để nâng cấp mô hình phân tích. Bản dùng thử không bị loại bỏ hoàn toàn mà dần dần đi theo hướng nâng cao chất lượng, như vậy chúng có thể được đưa vào trong hệ thống cuối cùng. Mô hình chức năng đươc tạo ra như là một đầu ra, gồm mã bản dùng thử và mô hình phân tích. Kiểm thử cũng là một phần cơ bản của giai đoạn này. - Design and build iteration là giai đoạn mà hệ thống được tập trung xây dựng. Đầu ra là một hệ thống đã được kiểm thử đáp ứng tối thiểu yêu cầu khách hàng. Thiết kế và tính năng bản dùng thử được đánh giá bởi người dùng và những phát triển sau này sẽ dựa trên những đánh giá đó. - Implementation là giai đoạn hệ thống được chuyển tử môi trường phát triển sang môi trường sản xuất thực tế. Công việc đào tạo, huấn luyện người dùng được tiến hành và hệ thống được vận hành bởi họ. Nếu như khi triển khai thu hút được số lượng lớn người dùng thì giai đoạn bổ sung cũng có thể được lặp lại. Bên cạnh hệ thống, đầu ra của giai đoạn bổ sung cũng gồm tài liệu hướng dẫn người dùng và bản báo cáo đánh giá dự án. Dựa trên kết quả đánh giá dự án, kế hoạch về những phát triển sau này được xây dựng. DSDM vạch rõ bốn khả năng có thể xảy ra. Nếu hệ thống đáp ứng được toàn bộ các yêu cầu thì việc phát triển thêm là không cần thiết. Nhưng nếu vẫn còn có những yêu cầu hệ thống chưa đáp ứng được thì quy trình phát triển có thể phải tiến hành lại từ bắt đầu tới kết thúc. Nếu như một vài chức năng bị bỏ qua thì quy trình phát triển có thể tiến hành lại từ functional model iteration. Cuối cùng, nếu một số vấn đề kĩ thuật không được tập trung do eo hẹp về thời gian, chúng có thể được hoàn thành khi tiến hành lại vòng lặp, bắt đầu từ giai đoạn thiết kế và xây dựng. 7. Phát triển phần mềm thích nghi Phát triển phần mềm tương thích (Adaptive Software Development-ASD) được phát triển bởi James A.Highsmith III. Hiện nay có khá nhiều các nguyên tắc của ASD khác với những tài liệu nghiên cứu của Highsmith trước kia về phương pháp phát triển lặp. Một trong những tiền thân được biết đến nhiều nhất của ASD là “RADical Software Development” (phát triển phần mềm căn bản), mô hình được phát triển bởi sự cộng tác của Highsmith và S. Bayer và được giới thiệu trong “Bayer and Highsmith” 1994. Trọng tâm chính của ASD là vào những vấn đề trong việc phát triển các hệ thống lớn và phức tạp. Phương pháp này đã kích thích mạnh mẽ việc phát triển lặp với việc chế thử liên tục. Về cơ bản ,ASD là “giữ cho cân bằng ở ranh giới của sự hỗn loạn”,do đó,mục đích của ASD là cung cấp một khuôn mẫu vói những hướng dẫn đầy đủ để tránh cho dự án lâm vào tình trạng hỗn loạn,khó kiểm soát mặc dù đôi khi nó cũng làm hạn chế những sáng tạo hay những đột phá. Một dự án ASD được thiết kế theo 3 chu kì,được biểu diễn bởi hình sau : Các bước này được đặt tên theo cách để nhấn mạnh vào vai trò của việc thay đổi trong tiến trình. Ở đây, “Speculation”xem xét , nghiên cứu) được dùng thay cho “Planning” (lên kế hoạch) bởi vì 1 kế hoạch thì nhìn chung là chỉ được nhìn nhận như là 1 cái gì đó không chắc chắn lắm,do đó mà những sự sai lệch sẽ dẫn đến thất bại. Tương tự như vậy, “Collaborate”(cộng tác) được sử dụng để nhấn mạnh vào tầm quan trọng của làm việc theo nhóm như là ý nghĩa của việc phát triển những hệ thống có sự thay đổi cao.”Learn”(học tập) lại nhấn mạnh vào sự cần thiết của kiến thức và sửa lỗi, và trong thực tế là những yêu cầu có thể thay đổi liên tục trong suốt quá trình phát triển. Hình sau đây sẽ miêu tả chi tiết hơn về chu kì phát triển thích nghi: Bước khởi tạo dự án định ra những nền tảng của dự án và được bắt đầu bằng cách định ra những nhiệm vụ của dự án.Những nhiệm vụ này cơ bản là lập ra một khung thô cho sản phẩm cuối,và tất cả các việc phát triển sẽ được chỉ đạo để các nhiệm vụ được hoàn thành.Một trong những cái quan trọng nhất trong việc định ra các nhiệm vụ cho dự án là phác thảo ra những thông tin nào cần thiết cho dự án.Các mặt quan trọng của nhiệm vụ được định ra theo 3 phần: tầm nhìn của dự án,dữ liệu dự án,1 sản phẩm đầu ra chi tiết. Ý nghĩa của những tài liệu này được được giải thích chi tiết trong Highsmith 2000. Bước khởi tạo dự án sửa lại bảng lịch trình kế hoạch tổng thể cũng như lich trình và các mục tiêu cho mỗi chu kì phát triển. Chu kì điển hình kéo dài từ 4 cho đến 8 tuần. ASD rõ ràng là hướng thành phần hơn là hướng nhiệm vụ. Trong thực hành,điều này có ý nghĩa là trọng tâm được đặt vào kết quả và chất lượng hơn là nhiệm vụ hay tiến trình được sử dụng trong quá trình tạo ra kết quả ấy. Tiền đề cho những chu kì phát triển xa hơn là kết quả của việc lặp đi lặp lại việc kiểm tra chất lượng mà trọng tâm là tập trung vào phát triển các chức năng của phần mềm trong suốt chu kì. Một yếu tố quan trọng nữa trong việc đưa ra các đánh giá,kiểm tra là sự có mặt của khách hàng ,ví dụ như là 1 nhóm các chuyên gia. Tuy nhiên từ khi các đánh giá,kiểm tra chất lượng trở nên hiếm dần (chúng chỉ được thực hiện vào cuối của mỗi chu kì) thì sự có mặt của khách hàng trong ASD cũng chỉ được làm trong các phiên phát triển ứng dụng kết nối (joint application development (JAD)). Một phiên JAD là vô cùng quan trọng cho công việc, đây là nơi mà khách hàng và nhà phát triển gặp nhau và thảo luận về những yêu cầu về các tính năng của sản phẩm, và để nâng cao việc truyền thông với nhau. ASD không đề xuất ra những lịch trình cho việc tổ chức các phiên JAD nhưng chúng thường được làm đặc biệt vào những bước đầu của dự án.Bước cuối cùng của dự án ASD là những câu hỏi \giải đáp cuối cùng và phát hành (Final Q/A and Release ). ASD không đưa ra cách thực hiện bước này thế nào nhưng nó nhấn mạnh vào tầm quan trọng của việc nắm được những gì đã học. Các hoạt động kế tiếp của dự án được xem như rất quan trọng trong các dự án có tốc độ nhanh và có nhiều thay đổi, nơi mà các quá trình phát triển linh hoạt diễn ra. Tóm lại, tính thích nghi của phát triển trong ASD được mô tả qua bảng sau: Đặc điểm Mô tả Hướng nhiệm vụ Các hoạt động trong mỗi chu kì phát triển phải phù hợp với nhiệm vụ tổng thể của dự án .Nhiệm vụ có thể được sửa đổi trong khi việc phát triển được tiến hành Dựa vào thành phần Các hoạt động phát triển không nên hướng tác vụ,nhưng cũng nên tập trung vào phát triển phần mềm làm việc như xây dựng hệ thống theo những phần nhỏ cùng lúc Lặp lại Một mô hình thác nước chỉ làm việc trong những môi trường đã được hiểu rõ và được định nghĩa chi tiết.Hầu hết các việc phát triển đều thay đổi thất thường vì thế thay vì làm đúng trong lần đầu ,các nỗ lực phát triển nên tập trung vào việc làm lại Time-Boxed Sự mập mờ trong những dự án phần mềm phức tạp có thể được giảm bớt bằng cách thay đổi thời hạn.Việc quản lí time-boxed dự án tập trung vào những người tham gia vào dự án để xử lí sớm những quyết định khó khăn không tránh khỏi trong dự án Thích ứng được với các thay đổi Thay đổi là thường xuyên trong phát triển phần mềm, việc có thể thích ứng với nó thì quan trọng hơn là kiểm soát nó.Để xây dựng một hệ thống thích ứng được với thay đổi,những nhà phát triển phải luôn đánh giá được sự thay đổi của các thành phần trong quá trình xây dựng chúng Hướng rủi ro Việc mở rộng phạm vi những yếu tố rủi ro cao nên được bắt đầu sơm nếu có thể 8. Phát triển phần mềm mã nguồn mở Sự kết hợp của những phát minh về he thing bảng thông báo và những thói quen cũ cũ của những người phát triển phần mềm để chia sẻ mã nguồn miễn phí với nhau đã thúc đẩy sự mở rộng của Internet trên phạm vi toàn cầu vào những năm 90. Tiến trình phát triển này đã khơi nguồn cho ý tưởng về 1 mô hình phát triển phần mềm mới – OSS - cách phát triển ứng dụng khá mới lạ. OSS cho rằng mã nguồn nên miễn phí và có thể sửa chữa hoặc bổ sung mà không cần trả tiền. Feller và Fitzgerald (2000) đã trình bày một số động lực và phương hướng cho phát triển OSS như sau: - Tính kĩ thuật; cần thiết phải có những mã mạnh, vòng đời phát triển nhanh hơn, đạt những tiêu chuẩn chất lượng cao hơn, đáng tin cậy và ổn định và hơn hết là tính mở. - Tính thương mại; sự hợp tác cần cho cả việc san sẻ lợi nhuận cũng như rủi ro. - Về chính trị, xã hội; thỏa mãn những sở thích cá nhân, mong muốn về công việc có ý nghĩ và hướng tới cộng đồng. Phần lớn mọi người đều biết rằng dự án phát triển OSS lấy trọng tâm là những công cụ phát triển hoặc những môi trường được các chuyên gia sử dụng để phát triển chúng thêm, vì vậy cùng lúc, họ đóng vai trò là người sử dụng và nhà phát triển. OSS không phải là một bản thing kê các thực nghiệm phát triển phần mềm đã được định nghĩa hay đã được ra đời mà nó được mô tả chính xác hơn trong thuật ngữ về những quyền hạn khác trong việc phân phối phần mềm. Sáng kiến về mã nguồn mở sẽ công nhận và cấp bản quyền cho những phần mềm đáp ứng các yêu cầu của OSS. Mặc dù có những khác biệt trong những mặt như tính thương mại, về cách tổ chức nhóm so với các phương pháp linh hoạt khác nhưng trong 1 số tình huống, các suy nghĩ và thực hiện lại có những điểm giống nhau, ví dụ như tiến trình phát triển OSS bắt đầu với những việc cho ra đời sớm và thường xuyên các bản thử nghiệm và nó thiếu rất nhiều các cơ chế truyền thống, cái mà được sử dụng cho hợp tác phát triển phần mềm với những kế hoạch, thiết kế cấp độ, lập lịch và những tiến trình đã định. Thông thường, một dự án OSS bao gồm các bước sau: - Tìm hiểu vấn đề - Tìm những người tình nguyện - Định ra cách giải quyết - Phát triển và kiểm thử mã nguồn - Thay đổi mã nguồn - Các tài liệu hướng dẫn mã nguồn - Tổ chức phát hành Mặc dù có thể mô tả phương pháp phát triển phần mềm OSS theo những bước trên nhưng sự quan tâm lại nằm ở chỗ quản lí những bước trên như thế nào, sau đây là một vài đặc điểm mô tả phương pháp phát triển OSS : - hệ thống được xây dựng bởi số lượng lớn những người tình nguyện - Công việc không được phân định rõ ràng mà mọi người tự chọn công việc mà mình thích - Có những thiết kế cấp độ hệ thống không rõ ràng - Không có kế hoạch, lịch trình - Hệ thống phát triển theo những bước tiến nhỏ - Chương trình được kiểm thử thường xuyên Theo Feller và Fitzgerald (2000), tiến trình phát triển OSS được tổ chức là một cách phát triển và những cố gắng gỡ lỗi trong phạm vi rộng 1 cách song song, nó bao gồm sự hợp tác và những cống hiến của những người phát triển.Tuy nhiên, cũng có những dấu hiệu chỉ ra rằng ý tưởng phát triển miễn phí này đang dần thay đổi vì tiến trình phát triển OSS không có bất kì một quy tắc hay thói quen được chuẩn hóa nào thế nhưng tiến trình này vẫn liên quan đến thói quen và những điều cấm kị đã được học hoặc rút ra từ thực nghiệm. III. So sánh các phương pháp phát triển phần mềm linh hoạt 1. Giới thiệu Việc so sánh khách quan các phương pháp với nhau thường rất khó, và những kết quả thu được thông thường đều dựa trên các kinh nghiệm chủ quan của những người đi trước hay là những hiểu biết trực giác của người làm (Song and Osterweil 1991). Có hai phương pháp thường dùng là phương pháp so sánh chính thống và phương pháp so sánh gần chính thống (Song and Osterweil 1992). Phương pháp so sánh gần chính thống cố gắng khắc phục những hạn chế chủ quan của kĩ thuật so sánh chính thống, theo Sol (1983), phương pháp so sánh không chính thống có thể tiếp cận theo 5 cách khác nhau : 1 Mô tả một phương pháp và đánh giá các phương pháp đối lập với phương pháp đó. 2 Rút ra những đặc điểm quan trọng từ một vài phương pháp hay qua việc so sánh mỗi phương pháp với nhau. 3 Xây dựng những giả thiết về các yêu cầu của phương pháp và đưa ra một khuôn mẫu từ những bằng chứng thực tế trong một vài phương pháp . 4 Định nghĩa một siêu ngôn ngữ như là một công cụ giao tiếp và như là một khung chuẩn chung để mô tả nhiều phương pháp khác. 5 Dùng phương pháp tiếp cận ngẫu nhiên và thử liên kết các đặc điểm của mỗi phương pháp thành 1 vấn đề cụ thể Ở đây chúng ta có sử dụng hai thuật ngữ là “những điểm chính “ (key points) và “những điểm đặc biệt” (Special features). Những điểm chính mô tả cụ thể những vấn đề hoặc những khía cạnh chính của phương pháp, còn những điểm đặc biệt thì d