Đề tài: Agile Project Management cho ứng dụng di động

Chia sẻ: Cuong Vo | Ngày: | Loại File: DOCX | Số trang:20

Thêm vào BST

Báo xấu

159
lượt xem 15
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Đề tài: Agile Project Management cho ứng dụng di động dành cho các bạn sinh CNTT đang học bộ môn Phương pháp mô hình hóa với nội dung về : Phát triển ứng dụng di động bằng phương pháp Agile, Thực trạng phát triển ứng dụng di động, Một số phương pháp phát triển ứng dụng di động hướng Agile.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Đề tài: Agile Project Management cho ứng dụng di động

a) Giới thiệu về Aglie for Mobile b) Thực trạng phát triển ứng dụng di động Hiện nay, thị trường di động đang ngày càng được mở rộng nhanh chóng, đồng thời, các nền tảng di động cũng đang tiếp tục cải thiện hiệu suất, tính năng, phần mềm, khả năng tận dụng phần cứng máy … Các nền tảng di động mới cho phép tận dụng tối ưu hơn tài nguyên mạng, do đó, nó mở ra một h ướng phát triển chuyên sâu trong việc phân phối phần mềm, khả năng trao đổi dữ liệu giữa client và server. Phát triển các ứng dụng di động luôn tạo ra cơ hội để các tính năng độc đáo đến được với con người hơn và nó giúp nâng vai trò người dùng, theo đó, người dùng sẽ trở thành một phần không thể thiếu trong chu trình phát triển phần mềm di động. Môi trường phát triển và các công nghệ hỗ trợ phát triển phần mềm cũng khác rất nhiều so với cách cài đặt truyền thống trước đây. Một số đặc điểm dễ dàng nhận thấy ở những quy trình phát triển ứng dụng di động đó là: mức độ cạnh tranh cao, thời gian giao hàng ngắn, hoặc là công tác xác định các yêu cầu phần mềm và các bên liên quan. Ngoài ra, nhóm phát triển phải đối mặt với những thách thức từ môi trường đầy năng động bên ngoài với những thay đổi thường xuyên những nhu cầu từ phía khách hàng. Thêm vào đó, các yếu tố như phần cứng, phần mềm, hệ điều hành đặc biệt khác nhau cũng tạo ra những khó khăn nhất định trong việc phát triển những dự án ứng dụng trên di động. Nhìn chung, có hai hạn chế đó là nhu cầu phát triển và tài nguyên vốn có. Công tác phát triển một ứng dụng di động sẽ không thể hoàn tất nếu như có bất kì sự cố nhà mạng, đường truyển băng thông hẹp, lẫn cả về bảo hiểm, tính chất an ninh thông tin và hệ thống. Cùng với đó là những hạn chế vốn có của các
thiết bị động như màn hình hạn chế là giảm khả năng nhập liệu, dung lượng bộ nhớ giới hạn nên khả năng mở rộng kém, bộ vi xử lý và cả vấn đ ề thời lượng pin, những hạn chế này luôn tồn tại song hành cùng với các thiết bị di động, cũng như nền tảng phát triển. Do vậy, việc phát triển ứng dụng theo các hướng khác nhau là nhằm mục đích làm giảm những tác động vốn có lẫn những ảnh hưởng những tác động từ môi trường ngoài. Vì mức độ khác biệt giữa môi trường ngoài và nền tảng phát triển ứng dụng là rất lớn nên một câu hỏi được đặt ra là: Phát triển ứng dụng di động bằng phương pháp nào là phù hợp? Ta có thể xác định được mô hình phát triển phù hợp bằng cách xây dựng những yêu cầu, danh sách tác vụ và nhu c ầu người dùng. Việc xây dựng một bảng kế hoạch rõ ràng sẽ giúp giải quyết được vấn đề: phát triển trong môi trường đầy biến động, không chắc chắn, năng đ ộng cùng với mức độ cạnh tranh cao. Trong đó, các nhóm phát triển thường vừa và nhỏ, họ làm việc chung với nhau và sử dụng các công cụ hướng đối tượng để thiết kế. Những ứng dụng của chính họ thường nhỏ, mức độ an toàn thấp, đầy hạn chế. Những phiên bản ứng dụng được tung ra trong khoảng thời gian ngắn để đáp ứng những nhu cầu thị trường và quan trọng là phương pháp phát triển linh hoạt giúp việc phát triển ứng dụng di động trở nên dễ dàng hơn trong việc tận dụng những yếu tố sẵn có, mà trước giờ tưởng chừng là những thách thức, khó khăn, đó là: Quy mô nhỏ, mức độ khả thi, môi trường đầy linh hoạt, mở rộng nhóm phát triển theo từng giai đoạn và yếu tố vòng đời phát triển ngắn. c) Phát triển ứng dụng di động bằng phương pháp Agile Phương pháp Agile đại diện cho hướng tiếp cận liên quan đến việc phát triển phần mềm. Từ khi ra đời cho đến nay, phương pháp này ngày càng được mở rộng, phát triển trong suốt thập kỉ vừa qua. Phát kiến đầu tiên được đưa ra dựa trên những nguyên lý trong phương pháp sản xuất tin gọn (Lean Manufacturing)
và phương pháp sản xuất nhanh nhẹn (Agile Manufacturing) với cùng một điểm chung là chúng nhấn mạnh mức độ thích nghi với môi trường biến động của các doanh nghiệp. Hiện tại, trong đại gia đình Agile, có một số phương pháp nổi trội như là Scrum, XP, Lean, Crystal, FDD. Các phương pháp này mang trong mình những tính năng nổi trội, phù hợp với từng loại dự án nhưng, nhìn chung, chúng đều có chung một số tính năng nổi bật và được kế thừa t ừ bản tuyên ngôn Agile – “Agile Manifesto”: cá nhân và sự tương hổ quan trọng hơn quy trình và công cụ; phần mềm chạy được quan trọng hơn tài liệu tham khảo; hợp tác khách hàng quan trọng hơn hợp đồng; khả năng thích nghi quan trọng hơn việc tạo ra và thực hiện theo kế hoạch. Tại sao phát triển ứng dụng di động theo hướng Agle là hợp lý? Một trong những thách thức hàng đầu mà nhà phát triển phải đối mặt là phần cứng và cở sở hạ tầng cho các ứng dụng di động luôn không ngừng phát triển và kết quả là: tuổi thọ trung bình của một ứng dụng di động thường chỉ vào khoảng 12 tháng. Một yêu cầu đặt ra là nhóm phát triển ứng dụng phải tạo ra những giải pháp phần mềm để giải quyết những vấn đề phần mềm một cách nhanh chóng. Các nguyên tắc Agile đã giúp tạo nên một khuôn khổ để phát triển và phát hành các ứng dụng di động có tuổi thọ dài nhất trên thị trường. Những ứng dụng được phát hành lần đầu có thể không hoàn hảo, và điều này có thể chấp nhận được. Thế nhưng, việc áp dụng công tác cập nhật thường xuyên, mang lại những giá trị nhất định cho người dùng thì họ sẽ bắt đầu kì vọng vào những đôi mới trong những bản version sau, chẳng hạn như version 1.0 hay 2.0. Thêm vào đó, việc áp dụng phương pháp Agile sẽ giúp phản hồi nhanh chóng những thay đổi từ phía người dùng lẫn doanh nghiệp. Các ứng dụng di động được tải về, được sử dụng, và thậm chí bị người dùng hủy đi theo cách mà họ tương tác với phần mềm từ trước tới giờ. Do vậy, nếu nhà phát triển ứng dụng không có bất cứ hoạt động nào để níu chân người
dùng, khiến họ chú ý đến ứng dụng của mình thì ứng dụng đó coi như đã chết. chính vì thế, việc phát triển ứng dụng di động bằng Agile tỏ ra khá thuận tiện, nó giúp tạo liên kết mật thiết với người dùng trong suốt quá trình c ập nhật, phát hành phiên bản mới trong những lần sau. Sau đây là 7 giá trị có được khi áp dụng phương pháp Agile trong quá trình phát triển dự án: Thứ nhất, việc phát triển ứng dụng hướng Agile phù hợp với bản chất thích nghi và thử nghiệm của ứng dụng di động. Những ứng dụng di động trở nên thành công sau quá trình thử nghiệm và thích nghi lâu dài. Nó là cả một quá trình chọn lọc và khai thác những nhu cầu hàng ngày của con người, và cũng chính người dùng sẽ là người trực tiếp comment và xếp loại những ứng dụng đó trên Store. Thứ hai, phương pháp Agile làm tăng độ tin cậy và giúp ứng dụng luôn dẫn đầu top ứng dụng người dùng. Bằng phương pháp này, các ứng dụng di động sẽ được luân phiên kiểm tra rất nhiều lần nên chất lượng cũng gia tăng đáng kể. Vì hầu hết người dùng chẳng thể chấp nhận những lỗi và sự cố xảy ra trong các ứng dụng và họ sẽ gở bỏ ứng dụng ngay từ đầu. Với hàng trăm ứng dụng trên Store, quả thật người dùng không biết chọn cái nào vì họ có quá nhiều sự lựa chọn. Nếu như những sản phẩm phần mềm nào không đem lại mức độ tin cậy nhất định sẽ bị người dùng quên lãng ngay từ lân đầu. Thứ ba, các vòng lặp ngắn trong Agile sẽ giúp mở rộng cách thức, mô hình cập nhật phần mềm một cách tự nhiên. Thứ tư, phương pháp Agile cho phép phản hồi lại những thay đổi cả về công nghệ trong quá trình phát triển. Công nghệ di động, đặc biệt là những hệ điều hành di động, sẽ thay đổi, được cải tiến và nhận được rất nhiều đặc điểm cập nhật nhanh hơn những hệ điều hành không di động. Do vậy, phương pháp Agile cho phép những tổ chức phản hồi nhanh chóng với bất kì sự thay đổi nào
về công nghệ. Duy chỉ có duy nhất một điều đó là người dùng cảm thấy bực bội vì ứng dụng cập nhật quá thường xuyên. Thứ năm, phát triển hướng Agile cho phép nhận, phản hồi nhanh chóng những yêu cầu từ phía người dùng. Vì khi có bất khì sự phản hồi từ phía người dùng, ngay lập tức một mô hình cập nhật phần mềm được tạo ra với nhiều chặng chạy nước rút, những chặn phát triển theo một yêu cầu, hoặc một phần của yêu cầu khách hàng. Với cách này, nguồn dữ liệu lẫn việc thao tác dữ liệu cũng không bị gây hại gì nhiều so với những ứng dụng không phải là di đ ộng và không phát triển theo mô hình Agile. Do vậy, quá trình cập nhật vẫn s ẽ được đảm bảo hoạt động trơn tru trên nguồn dữ liệu cũ. Thứ sáu, việc phát triển theo hướng Agile cho phép quan tâm nhiều hơn đến với trải nghiệm người dùng. Vì các ứng dụng này chạy trên môi trường bị hạn chế bởi nhiều thứ nền kích thước ứng dụng cũng được quan tâm trong bản cập nhật sau. Nếu như nó mất gấp đôi thời gian tải về so với lần trước thì họ sẽ ngưng ngay lập tức và tìm ngay một ứng dụng tương tự để thay thế. Vì vậy, phương pháp Agile cho phép nhà phát triển có nhiều kinh nghiệm hơn trong quá trình phát triển các ứng dụng với nhiều tùy chọn hơn để đưa vào chu trình phát triển ứng dụng, sao cho tạp ra các giá trị về nhanh, mượt và đơn giản cho người dùng. Cuối cùng, phương pháp Agile cho phép loại bỏ bớt những tính năng cũ. Những ứng dụng độc lập giống như những game thì cần phải nhỏ gọn, thường thì nó không giao tiếp với bất kì máy chủ nền nào cả. Tuy có một số khác l ại cần đến việc truy cập máy chủ chẳng hạn như những ứng dụng thời tiết, ứng dụng hàng không hiển thị các trạng thái chuyến bay, các trang web dịch vụ du lịch … Nhà phát triển phải đảm bảo ứng dụng có những tính năng cơ bản và thừa ra những tính năng không liên quan nhằm tính tình trạng “ngợp” cho khách hàng. Một nhà thiết kế ứng dụng thông minh thì sẽ phải biết cách điều chỉnh
những tính năng trong ứng dụng, hoặc nếu thấy cần thiết thì họ phải quay về với những thiết kế căn bản ban đầu của ứng dụng. d) Một số phương pháp phát triển ứng dụng di động hướng Agile e) Mobile-D Mobile-D là nổ lực đầu tiên trong việc kết hợp các phương pháp thực hành Agile trong quá trình phát triển ứng dụng di động. Mobile-D được Abrahamsson giới thiệu vào năm 2004, trong quyển “Mobile-D: An Agile approach for mobile application development” như một phương pháp lấy cảm hứng từ Extreme Programming (XP), phương pháp Crystal và quy trình phát triển thống nhất (RUP) với yêu cầu nhóm phát triển có số lượng ít, phải làm việc cùng nhau trong những chu trình nhỏ. Mobile-D được cấu tạo từ 5 pha đ ược chuẩn bị một cách kĩ lưỡng bao gồm: Tìm hiểu, bắt đầu, sản xuất, củng cố va kiểm tra. Ở mỗi pha, điều cần phải thực hiện là phải xác định các bên liên quan thông qua hệ thống kiểm tra và phân phối. Các hoạt động thực tiễn được xác lập dựa trên các nguyên tắc phù hợp với phương phá thực hành Agile (ví dụ như test trước khi viết chương trình, lập trình cặp, v.v.). Nhìn chung, mobile-D là phương pháp có nhiều ảnh hưởng nhất trong việc phát triển ứng dụng di động. f) MASAM MASAM là từ viết tắt của Mobile Application Software development based on Agile Methodology tạm dịch là phương pháp phát triển ứng dụng di động dựa trên phương phá Agile được Jeong, Lee và Shin giới thiệu trong tài liệu nghiên cứu “Development process of mobile software development” năm 2008. Phương pháp này dựa trên XP, RUP và phương pháp thiết kế Metal-Model cho phần mềm và hệ thống. Giống như Mobile-D, MASAM cho phép một chu kì sống của một phần mềm được xây dựng dựa trên hướng tiếp cận Agile phù hợp với 4 giai đoạn đó là: chuẩn bị, xuất hiện, phát triển và thương mại hóa.
Việc xây dựng các sản phẩm thông qua cách thực hành công tác: Test trước khi viêt chương trình, lập trình cặp, tái cấu trúc, tích hợp liên tục và các công việc kiểm tra lặp. Việc bổ sung thêm pha thương mại hóa giúp mở rộng thêm phương pháp luận này ở mảng bán hàng. Thế nhưng, phương pháp này không bao gồm một công trình nghiên cứu cụ thể nào hết mà nó được tổng hợp dựa trên 3 bài báo khác nhau. g) Hybrid Methodology Design Process – Quy trình thiết kế phương pháp lai Quy trình thiết kế phương pháp lai được Rihimian và Ramsin giới thiệu trong tài liệu “Designing an agile methodology for mobile software development: a hybrid method engineering approach” năm 2008. Theo đó, họ thúc đẩy việc áp dụng các phương pháp Agile và các phương pháp rủi ro như một khuôn khổ thích hợp cho việc phát triển các ứng dụng di động. Nó dựa trên sự kết hợp giữa các phương pháp Agile, việc phát triển phần mềm thích nghi và phát triển sản phẩm mới. Xét về mặt cấu trúc thì phương pháp của họ được đ ề xuất là để tạo nên bộ khung phát triển chung cho vòng đời của phần mềm dựa trên các phương pháp thực hành và nguyên lý Agile. Kết quả là quy trình thiết kế phương pháp lai là công tác tổ chức kết cấu lặp đi lặp lại từ việc lên ý tường đến khi hoàn thiện sản phẩm. nó định nghĩa một kĩ thuật thiết kế lặp bao gồm thiết kế, mô hình, lồng ghép và đánh giá va sau đó là kiểm nghiệm thị trường và tiến hành thương mại hóa sản phẩm. Những nguyên tắc nhận đ ịnh thị thường sẽ tạo nên quá trình thương mại tích cực cho các sản phẩm được phân phối. Thế nhưng, các bài báo nghiên cứu và 9 bài trích dẫn khác của nó cũng không bao gồm bất kì công trình nghiên cứu hoặc những cuộc thử nghiệm nào để đảm bảo phương pháp này có thể dùng để phát triển các sản phẩm thực tế. h) Scrum Scharff và Verma đã hướng dẫn một cuộc nghiên cứu để kiểm tra mức ảnh hưởng của phương pháp Scrum trong việc phát triển các ứng dụng di động.
Scrum là một khuôn khổ vòng lặp và sự gia tăng giá trị chung trong việc hợp nhất các phương pháp thực hành Agile. Nó sử dụng các vòng lặp các khoảng thời gian cố định (thường từ 1 đến 4 tuần) và gọi chúng là những Sprint – chặng nước rút. Bắt đầu mỗi Sprint, vào thời kì xác lập kế hoạch, nhóm phải cam kết hoàn thành một lượng công việc nhất định được tạo từ những prodct backlog – công việc tồn đọng của sản phẩm, và viết các tài liệu có liên quan trong mỗi Sprint backlog – tác vụ tồn đọng mỗi chặng. Sau đó, nhóm Scrum sẽ quyết định làm việc bao nhiêu là đủ để họ có thể chạy được Sprint sau. Kết thúc mỗi Sprint thì một chức năng của sản phẩm sẽ được phân phối và các chức năng chưa hoàn thành khác sẽ được đưa vào vòng lặp kế tiếp. Để theo dõi dự án, một đồ thì đặc biệt được sử dụng là đồ thị burn-down, đồ thị này thể hiện mỗi qan hệ giữa những công việc còn đang chờ và thời gian còn lại của dự án. i) Scrum Lean Six Sigma Scrum Lean Six Sigma (SLeSS) là một hướng tiếp cận trong việc tích hợp Scurm và Lean Six Sigma trong phát triển các ứng dụng điện thoại di động. Triết lý này cho phép đạt được các mục đích có hiệu suất và chất lượng cao trong quá trình cải thiện các quy trình phát triển quyền điều khiển cơ bản. SLeSS được lọc ra từ phương pháp Scrum, với mục đích hợp nhất giữa những nổ lực và công tác phân phối của từng Sprint kèm theo việc phân tích liên tục và cải thiện mô hình đại diện bởi phương pháp Six Sigma bao gồm các pha: Định nghĩa, phương pháp, phân tích, cải tiến và điều khiển. Mỗi Sprint backlog được sử dụng không chỉ để thiết lập nên các thành phần ở phiên bản tiếp theo mà nó còn được kiểm tra một cách cẩn thận dựa trên quá trình cải tiến bằng thống kê. Việc sử dụng phương pháp SLeSS dự đoán một hướng tiếp cận mới tăng nhanh giá trị trong Agile mà ở đó Scrum được chuyển thể để cùng tồn tại cùng với phương pháp lập kế hoạch Lean Six Sigma.
j) Một số phương pháp khác. Không phải tất cả các phương pháp phát triển ứng dụng di động đều dựa trên phương pháp Agile. RaPiD7 là một phương pháp phát triển dựa trên những nguyên lý Agile thế nhưng lại tập trung vào tài liệu phần mềm nhiều hơn là việc phát triển các phần mềm thực tế. Ngoài ra, phương pháp phát triển mô hình xoắn ốc – Mobile Development Process Spiral, được đề xuất để tận dụng khả năng sử dụng hướng mô hình đẻ tích hợp các vấn đề cụ thể vào quy trình phát triển ứng dụng hiện có. Phương pháp này không dựa trên phương pháp Agile mặc dù nó cung cấp khả năng lặp và thực hành để chắc chắn rằng những yêu cầu được xác định và xác nhận. Cuối cùng khung phát triển ứng dụng di động – Mobile Application Development Framework, là một phương pháp hướng doanh nghiệp. Nó tập trung vào việc đánh giá sự phù hợp của các ứng dụng đi động để sinh ra các giá trị kinh doanh cho công ty. Nó quy định tài liệu, tạo điều kiện cho công nghệ và cung cấp các nguồn lực cần thiết đ ể thực hiện tốt các tiêu chuẩn được đề ra của tổ chức. k) Mobile-D Như đã trình bày sỏ lược ở trên thì Mobile-D là một phương pháp mới đ ược Abrahansson giới thiệu lần đầu vào năm 2004. Đây là phương pháp dựa trên các phương pháp thực hành Agile, nó được tổng hòa từ các phương pháp XP, Crystal và RUP. Các nguyên tắc thực hành trong Mobile-D bao gồm test trước trước khi lập trình, lập trình cặp, tích hợp liên tục, tái cấu trúc cũng như các công việc cải thiện quy trình phần mềm. 1. Tổng quan Phương pháp Mobile-D được dùng cho một nhóm 10 người, làm việc cùng nhau, cố gắng hoàn thiện sản phẩm trong vòng 10 tuần. Có 9 thành phần chính liên quan đến những phương pháp thực hành khác nhau xuyên suốt chu trình lặp, đó là:  Pha và truyền dẫn  Dây chuyền kỹ thuật  Test trước khi viết chương trình
 Tích hợp liên tục  Lập trình cặp  Kỹ thuật Metric  Cải tiến quy trình phần mềm  Khách hàng ngoài  Lấy người dùng làm trung tâm Ở thành phần dây chuyền kỹ thuật trong phương pháp là một điểm bổ sung mới vào các phương pháp thực hành Agile đã có sẵn. Nó giúp giữ lại những hiểu về những giải pháp kĩ thuật cao của một tổ chức, từ cả hai nguồn tài nguyên trong và ngoài để dùng vào lúc cần thiết. Phương pháp Mobile-D gồm 5 pha: tìm hiểu, bắt đầu, sản xuất, củng cố và kiểm tra hệ thống. Và ở mỗi pha đều có một số trạng thái, tác vụ và các cách thực hành khác nhau. Pha đầu tiên là tìm hiểu – Explore. Trong pha này, nhóm phát triển phải xây dựng nên một bản kế hoạch và các thành phần của dự án. Pha này hoàn tất nếu như cả 3 giai đoạn: thiết lập các bên liên quan – Stackholder Establishment, xác định phạm vi – Scope definition, thiết lập dự án – Project estalishment, hoàn tất. Các công việc liên quan đến pha này bao gồm việc thiết lập khách hàng, xây dựng kế hoạch dự án, thu thập yêu cầu và khỏi động tiến trình công việc, trong đó khách hàng sẽ là người tham gia hoạt đ ộng vào quá trình phát triển dự án.
Ở pha thứ hai, bắt đầu – Initialized, nhóm phát triển và tất cả các bên liên quan sẽ phải nắm rõ, hiểu rõ về sản phẩm sẽ làm và chuẩn bị các nguồn tài nguyên cẩn thiết cho các hoạt động sắp diễn ra như là phần cứng, kỹ thuật, các nguồn tài nguyên giao tiếp. Pha này được chia ra làm 3 giai đoạn nhỏ là: cài đặt dự án, khởi động kế hoạch và thử nghiệm. Pha sản xuất – Productionize, với nhiệm vụ chính là thực hiện các công việc, các nhiệm vụ. Đây là pha hoạt động xây dựng chính của cả quá trình phát triển dự án. Ở cuối pha này, hầu hết các công việc chính gần như hoàn tất. Pha này được chia ra làm các giai đoạn nhỏ khác nhau là: lên kế hoạch, xây dựng và phân phối sản phẩm. Lên kế hoạch hướng đến việc nâng cao quy trình, các yêu cầu phân tích, ưu tiên, lên kế hoạch các nội dung sẽ được lặp đi lặp lại và tạo ra các bài kiểm tra sẽ được chạy sau ngày phân phối sản phẩm. Ở giai đoạn xây dựng, bước thực hành Test trước khi viết chương trình – Test-Driven Development (TDD), được sử dụng để vận hành các chức năng như kế hoạch đã định trước cho vòng lặp hiện tại. Việc vận dụng phương pháp TDD cùng với tích hợp liên tục, các nhà phát triển tạo ra các phần kiểm tra căn bản, viết mã để pass qua các bài test đó, và tích hợp những mã mới vào version hiện tại. Cuối cùng, giai đoạn phân phối sản phẩm sẽ cho ra những sản phẩm hoạt động được trên trên hệ thống và có thể chấp nhận bất kì kiểm tra nào. Hai pha cuối cùng là củng cố và kiểm tra hệ thống – Stabilize and System Test & Fix, được dùng để hoàn thiện và kiểm tra sản phẩm một cách riêng r ẽ. Chúng bao gồm những trạng thái tương tự như pha Sản xuất – Productionize, cùng với một vài điều chỉnh để phù hợp cho việc xây dựng tài liệu hướng dẫn và kiểm tra hệ thống. Đến nay, phương pháp Mobile-D hoàn toàn được phép áp dụng vào các dự án phát triển phần mềm. Nó mang lại khá nhiều giá trị có lợi như tăng khả năng quan sát tiến độ, phát hiện sớm và sửa chữa các vấn đề nảy sinh, hạn chế đến mức thấp nhất những khuyết tật trong phân mềm. l) Phương pháp cải tiến Để có được tập hợp các cải tiến cho một phương pháp phát triển thì một trong những yếu tố tiên quyết đầu tiên là phải phân tích cho được những đ ặc điểm quan trọng trong phương pháp giúp dự án trước đạt được những thành công. Đồi với phương pháp phát triển ứng dụng, thì chìa khóa dẫn thành công những yếu tố như: linh động, phân tích, thẩm định thị trường, hỗ trợ cho dòng sản phẩm, những kĩ thuật nền, hỗ trợ tính tái sử dụng, bao gồm cả những yếu tố như thẩm định, nghiên cứu phát triển và những kiến trúc vật lý, kĩ thuật phần cứng nhất định. Và một vài yếu tố trên đã được tìm thấy trong phương pháp Mobie-D (linh động, những kiến trúc vật lý nền, thẩm định và nghiên cứu phát
triển) thế nhưng phương pháp cũng phải được cải tiến vì có khá nhiều thành phần khác không được tích hợp. Nếu có thể thì nên thêm vào một số thành phần như: khả năng nâng cao nhận thức thị trường, hỗ trợ dòng sản phẩm và tái sử dụng. Ở hai thành phần mới là hỗ trợ dòng sản phẩm và tái sử dụng sẽ giúp hạ chi phí xuống một cách đáng kể, nhưng không phải công ty, doanh nghiệp cũng có thể áp dụng được vì đ ối với một số công ty nhỏ có ít kinh nghiệm trong việc phát triển ứng dụng di động lại không thể thành lập được những thư viện các thành phần để vận tính tái sử dụng. Trong trường hợp người dùng cuối thì việc nhận dạng người dùng cuối không phải là việc đơn giản. Điều này được Abrahamsson chỉ ra trong tài liệu nghiên cứu của mình, khi tác giả tiến hành so sánh giữa những đặc điểm của Agile và với những yêu cầu của việc phát triển ứng dụng di động. Đôi khi việc xác định của người dùng không phải lúc nào cũng chính xác, họ có thể xác đ ịnh đ ược phương pháp Agile nhưng lại ngập ngừng khi nói đến Agile cho các ứng dụng di động. Về tổng thể, họ không có một ranh giới rõ ràng khi phân biệt hai hướng tiếp cận này. Để giải quyết vấn đề này thì một danh sách các đặc điểm chính trong phát triển ứng dụng di động được đưa ra mà có thể mở rộng được bao gồm sự cân bằng của khách hàng, người dùng cuối và đôi khi cần đ ến những yêu cầu từ nhà cung cấp nền tảng. Ba thành phần này hiếm khi hội t ụ chung trong cùng một dự ấn phát triển phần mềm. Danh sách sau đại diện cho mức độ ưu tiên thích nghi của các đặc điểm trong phương pháp phát triển ứng dụng di động thành công  Tính linh hoạt  Ý thức thị trường  Đặc điểm đầu tiên của kiến trúc vật lý  Cung câp phản hồi của người dùng cuối  Dòng sản phẩm phần mềm  Hỗ trợ tái sử dụng  Phát triển kiến trúc nền  Thẩm định và nghiên cứu phát triển Các yếu tố trên được rút ra từ thực tiễn quan sát các cuộc thử nghiệm sản phẩm trong các phòng thí nghiệm đặc biệt với người dùng cuối. Theo đó, ta mặc định việc thêm thành phần người dùng cuối vào quy trình phát triển sản phẩm sẽ tạo ra các giá trị dựa theo cái yêu cầu của họ và giúp phát hiện sớm những lỗ sau xuất hiện trong chương trình. Và trong quá trình phát triển dự án, ta cần đảm bảo những đóng góp của người dùng phải được xác định trước. Thêm vào đó, một khi xác lập được sự cân bằng của bộ ba gồm các yêu cầu của khách hàng, người dùng cuối và nhà cung cấp nền tảng là rất quan trọng trong trường hợp các yêu cầu phát triển trên không được tập hợp lại với nhau.
Khi nói về nền tảng di động thì yếu tố hiệu suất là điều cần được cân nhắc kĩ lưỡng khi phát triển các ứng dụng trên nền tảng đó. Vì vậy, việc hỗ trợ tiến trình TDD của phương pháp Mobile-D có ý nghĩa lớn, thế nhưng các trường hợp kiểm tra lại không được đưa vào để tận dụng các nguồn lực có sẵn, một phần là vì các công cụ hỗ trợ còn nghèo nàn. Do vậy, để cải thiện phương pháp Mobile-D thì công tác thực hành TDD phải thực sự thích nghi với việc kiểm tra nguồn tài nguyên sẵn có, đặc biệt là đối với các tr ường hợp tài nguyên giới hạn. m) Những cải tiến trong Mobile-D a) Mang người dùng cuối và vòng đời phần mềm Việc thành lập các bên liên quan trong việc phát triển di động và không dễ dàng chút nào, đặc biệt là việc xác định người dùng cuối. Đối với các s ản phần mềm thì người dùng rất khó để xác định vì có quá nhiều kênh phân phối khác nhau, những kênh này luôn không ngừng tranh giành khách hàng bằng mọi khác và dẫn đến kết quả là họ vi phạm nguyên tắc Agile là liên hệ mật thiết với khách hàng. Vai trò của người dùng cuối là khá quan trọng trong vòng đời phát triển phần mềm cho nên việc xác định sự cân bằng giữa họ và các bên liên quan khác lại càng quan trọng hơn. Để đảm bảo sự thành công của sản phẩm phần mềm, những yêu cầu của các bên liên quan phải được xác định một cách cẩn thận, ưu tiên và cân bằng. Trong vài trường hợp, sự cân bằng 3 bên phải đạt được giữa khác hàng, người dùng cuối và nhà cung cấp nền tảng hoặc những yêu cầu kiến trúc nền tảng mạng. Những yêu cầu mâu thuẫn có thể dẫn đến những nhiều sai lầm trong dự án. Những ảnh hưởng này được dự kiến là dùng trong các hệ thống gia đình, nhưng lại áp dụng cho bất kì hệ thống có mức độ sử dụng cao, chẳng hạn như các ứng dụng di động. Hệ thống thất bại có thể xảy ra nếu như các sản phẩm không mang lại lợi ích như mong muốn; khả năng sử dụng kém có thể xuất hiện là do người dùng cuối không hài lòng về việc thiết kế, và cuối cùng việc miền cưỡng chấp nhận và sử dụng hệ thống có thể là kết quả của việc tiếp cận không chính xác nhu cầu khách hàng hoặc xác định không chính xác kiểu người dùng. Để xác định những yêu cầu mâu thuẫn thì nhà phát triển có thể chuyển sang các lĩnh vực Yêu cầu kĩ thuật – Requirements engineering (RE), và các hoạt động liên quan. Các yêu cầu kĩ thuật đòi hỏi cần tập trung vào những yêu cầu cụ thể nào đó của các bên liên quan, tiến hành phân tích và xác định các yếu tố này. Có bốn hoạt động trọng tâm cần làm đó là: gợi mở, mô hình, xác thực và xác minh. Trong công việc đầu tiên, ta phải gợi ra các yêu cầu sử dụng các tài nguyên có sẵn ví dụ như người dùng, tài liệu và kế đến là mô hình của chúng. Một mô hình kết quả phải trải qua một quá trình xử lý như thường lệ, kế đến
kết quả phải được kiểm tra và xác thực. Phương pháp gợi mở các yêu cầu bao gồm nhiều cuộc phỏng vấn người dùng, các nhóm làm việc bằng phương pháp tập trung, hoặc thậm chí là nguồn kiến thức của các chuyên gia chỉ đ ể xác nhận những yêu cầu cho hệ thống. Người dùng cuối có thể tham gia vào hầu hết các hoạt động của bộ phận RE bao gồm: gợi mở yêu cầu, kiểm tra xác thực, bằng cách dùng các cuộc phỏng vấn, đánh giá ngang cấp và các kĩ thuật Walk-through. Ngoài ra, giữa các nhóm bên liên quan, người dùng và khách hàng vẫn có rất nhiều điểm khác nhau. Các nhóm được chia bằng chính động lực và các khu vực chuyên môn của họ; giữa khách hàng và người dùng cuối vẫn tồn tại rất nhiều mâu thuẫn, một bên muốn được lợi ích tối đa trong khi bên kia lại muốn hạn chế đến mức thấp nhất những sự gián đoạn có thể xảy ra trong quá trình phát triển dự án. Yêu cầu xác định các bên liên quan giờ đã trở nên phức tạp hơn nhiều. Việc phân tích bắt đầu bởi việc xác lập các bên liên quan cơ bản của hai loại đối tượng là “nhà cung ứng” và “khách hàng”. Các nhà cung ứng đóng góp các thông tin và tác vụ trong khi khách hàng là người kiểm tra các sản phẩm. Tiếp theo, các bên liên quan gọi là ”satellite” được lập ra, đây là một biến thể mới, các bên liên quan mới này sẽ hợp tác với các bên liên quan cơ bản bằng nhiều cách khác nhau (Hình 3.1). Có 4 nhóm cơ bản là: Người dùng, nhà phát triển, luật sư và nhóm người quyết định. Quá trình xác định các nhóm đ ược thực hiện thông qua một số bước để tìm ra toàn bộ mức độ ảnh hưởng của t ừng nhóm người. Nhóm người có liên quan đến cuộc thảo luận là người dùng, và nhóm này phải được chia thành nhiều vai trò khác nhau tùy vào chuyên môn, những mục tiêu dự kiến và vị trí trong tổ chức. Bước tiếp theo sau khi xác định người dùng cuối là đưa vai trò của họ vào quy trình sản xuất. Không chỉ vậy, nếu có thể, việc đưa người dùng vào cả hai công việc thiết kế và phát triển sẽ đảm bảo tính chác chắn thành công của sản phẩm. Đồng thời, các nhà phát triển cũng phải thực hiện các cuộc khảo sát khả năng sử dụng của phần mềm nhằm đảm bảo rằng phần mềm đủ để dùng được. Hơn thế nữa, người dùng cuối cũng sẽ góp phần làm tăng sự hài lòng của người dùng vào sản phẩm, nguyên nhân là do người dùng cuối biết rõ các tính năng dùng được và không dùng được của phần mềm. Nhờ vậy, chương trình sẽ trở nên có ích hơn.
n) Kiểm thử hiệu năng Khi đem ra so sánh với môi trường desktop thì các nền tảng di động luôn bị hạn chế về nguồn tài nguyên vậy lý nên khi đem ra sử dụng các nhà phát triển buộc phải cân nhắc khá kỹ lưỡng. Tuy nhiên, phương pháp Mobile-D được biết đến như một phương pháp không tính đến các yếu tố hiệu năng khi thiết kế hoặc khi viết mã. Để giải quyết vẫn đề đó, việc tích hợp các hoạt động kiểm thử hiệu năng vào chu kì sống của ứng dụng, đặc biệt là việc mở rộng phương pháp kiểm tra TDD tỏ ra khá triển vọng. Khởi điểm ban đầu là một kỹ thuật với tên gọi là kiểm trước hiệu năng - Test- first performent (TFP), được đề xuất để kết hợp với kỹ thuật TDD. Có vài điều đáng chú ý giữa kỹ thuật TDD cổ điển và TFP đó là, trong kỹ thuật TFP những kịch bản hiệu năng được tạo ra như các trường hợp kiểm tra, thay vì sử dụng các kết quả xác nhận như các trường hợp JUnit thông thường, các phép đo sẽ thực hiện trên các thành phần, yếu tố khác nhau của các trường hợp kiểm nghiệm khác nhau để từ đó xác định nên các giá trị thống kê hiệu năng. Đặc điểm khác của TFP là nhà thiết kế các trường hợp kiểm thử sẽ phải hiểu rõ những kì vọng từ phía người dùng bằng chuyên môn của mình, sau đó tóm
lại những trường hợp hợp nào là cần phải kiểm thử hiệu năng và những trường hợp nào không cần thiết. o) Thách thức và vấn đề nảy sinh Giống như bất kì phương pháp nào khác, thì Mobile-D vẫn có một số thách thứ và vấn đề nảy sinh trong quá trình sử dụng. Trong khi vận dụng phương pháp Mobile-D vào dự án cũng như những nghiên cứu các nguyên tác của phương pháp, chúng ta sẽ phải đối mặt và xác định một chuỗi các thách thử và vấn đề và gom chúng thành 4 nhóm chính: tổ chức thực thi, tài liệu, đội nhóm và các phương pháp làm việc chung. a) Tổ chức thực thi Đầu tiên phải kể đến đó là sự thiếu hụt các thí dụ điển hình. Có một trang web mô tả về Mobile-D và các pha của nó, thế nhưng lại không nói gì về cách xây dựng nên những story card và task card. Đây là một sự thiết h ụt nghiêm trọng vì nó là một trong những thành phần quan trọng nhất khi sử dụng Mobile-D. Một trong những nguyên nhân là vì đây là phương pháp mới, có thời gian tồn tại ngắn và sự thật nó không nổi tiếng như những phương khác như Scrum. Do vậy, chúng ta không thể tìm thấy những ví dụ cụ thể về việc sử dụng Mobile-D để có thể viết nên các story/ task card dựa trên những mô tả ở từng lĩnh vực vận dụng khác nhau và kết quả là việc so sánh tài liệu phần mềm của ta với những dự án tương tự là rất khó, nếu không muốn nói là không thể. Thứ hai, công tác tái lập cái vòng lặp cũng gặp nhiều khó khăn trong khi phương pháp Mobile-D yêu cầu phải tái lập các vòng lặp, đôi khi đây sẽ trở thành một vấn đề lớn, thực sự lớn với một nhóm phát triển nào đó. Chúng ta cũng khó để đoán trước liệu có bao nhiêu vòng lặp là đủ để hoàn tất một phần mềm di động. Có rất nhiều tình huống xảy ra khi chúng ta cho rằng công việc đó chỉ ngốn tối đa hai ngày làm việc thế nhưng vì một vấn đ ề nào đó mà công việc đó có thể bị trì hoãn lâu hơn dự kiến. Cũng có khi, kế hoạch đã được lên kế hoạch kĩ lưỡng thế nhưng nhóm lại không thể đến họp và làm việc được. Vì vậy, số lượng ngày làm việc trong giai đoạn working days tăng lên và thời gian của giai đoạn release days cũng vì thể mà bị trì hoãn. Thứ ba, tài liệu không chuẩn cũng gây ra nhiều khó khăn khác. Cũng bởi vì số lượng lớn các vòng lặp nên cũng sẽ có nhiều biểu mẫu – nghĩa là những story/task card, tăng lên trong thời gian dài nếu có bất kì sự thay đổi xảy ra dù là rất nhỏ. Điều này sẽ làm phát sinh rất nhiều tài liệu không chuẩn và sẽ rất khó để phân biệt đâu là tài liệu quan trọng, đâu là không quan trọng. Nó cũng sẽ rất khó khăn khi ta muốn tìm kiếm bất kì tài liệu nào đó. Vấn đề sẽ bộc lộ rõ hơn khi mỗi thành viên trong nhóm có riêng cho mình một
lượng lớn tài liệu riêng và khi hợp nhất tài liệu chung của cả đội thì thực sự, nó trở thành một vấn đề nhức nhối. Một thứ khác cũng gây không ít khó khăn cho nhóm Mobile-D đó là sự thiếu hụt các lược đồ chuẩn. Đó là những lược đồ UML để so sánh với những phương pháp Agile khác. Phương pháp Mobile-D chia các quá trình xử lý phức tạp thành các tác vụ nhỏ. Nếu như các lập trình viên trong nhóm sử dụng các lược đồ này để viết chương trinh thì thay cho những câu chuyện từ người dùng thì có vấn đề nảy sinh ngay lập tức. Nhưng thật may mắn là có một vài sự phòng ngừa có thể làm để tránh việc đó xảy ra. Đầu tiên là cần phải đảm bào rằng các nhóm phát triển phải hiểu rõ dự án và được đào tạo kĩ càng trước khi bắt ty vào công việc. Tiếp theo, thứ cần làm là viết chi tiết các nhu cầu thành những story/task card. Từ đó, các thành viên mới biết mình cần phải làm gì và làm như thế nào. Cuối cùng, điều cần làm là duy trì mối quan hệ bền vững với khách hàng vì họ có thể giúp nhóm phát triển hiều rõ hơn, cũng như giải thích rõ về các công việc, chức năng cần có trong phần mềm. p) Tài liệu Tài liệu và các vấn đề liên quan đến tài liệu là những thách thức mới đối với nhóm phảt triển với phương pháp Mobile-D. Khó khăn đầu tiên phải kể đến đó là việc sắp xếp tài liệu. Điều này là cần thiết để giúp cho tài liệu phần mềm đơn giản, dễ hiểu và dễ tìm kiếm hơn. Các lập trình viên thì cũng là con người, do vậy, họ vẫn sẽ mắc phải những sai lầm nhất đ ịnh nào đó. Nhưng nếu họ im lặng trước một vài sai phạm chủ yếu thì nó có thể khiến cho tài liệu giống như một mớ hỗn độn. Với mỗi sai phạm nào chính nào đó xảy ra thì sẽ có một tác vụ mới phát sinh tùy vào mục đích và việc sửa lỗi đó. Trong hầu hết các trường hợp, khi một tác vụ mới phát sinh thì các lập trình viên phải thêm nó vào trong tài liệu hoặc một bảng nào đó. Do vậy, tài liệu cần phải được xây dựng một cách khoa học, lô-gic đ ể không phát sinh thêm bất kì phiền phức nào khác. Một trong số những vấn đề mạng tính chất nhỏ hơn đó là việc đặt tên cho những ID của các story card và task card. Ý tưởng đầu tiên được đ ưa ra là ấn định một con số khác nhau trên mỗi story card. Ý tưởng này, nhìn thì có vẻ ổn nếu như không có hơn 10 tác vụ trong một ngày. ID của từng story card được dùng trong rất nhiều tài liệu giờ sẽ giống như một một danh sách khuyến điểm nếu như có ai đó ấn định sai giá trị ID. Do vậy, việc tra cứu trở nên khó khăn hơn rất nhiều đối với những tập tài liệu bị ảnh hưởng. Quá nhiều cảnh báo là vấn đề nảy sinh tiếp theo trong danh sách các vấn đề liên quan đến tài liệu. Một khi các cảnh báo được đưa ra thì buộc các thành viên trong nhóm phải viết ra những phần kiểm tra liên quan đến chức
năng đó và bắt đầu một vòng lặp mới để kiểm tra vấn đề nảy sinh đó. Nếu các mô tả không được viết cụ thể, chi tiết thì rất có thể những sự cố lỗi đó sẽ bị bỏ qua. q) Đội nhóm Teamwork là một yếu tố đóng góp lớn vào sự thành công của sự án. Mặc dù mỗi thành viên có sự chênh lệch về mức độ hiểu biết, kĩ năng và vịt trí trong toàn đội thì họ vẫn là một thành viên, không thể thiếu trong nhóm. Đồng thời, mỗi thành viên cần phải tin vào nhau thì mới tạo nên mối quan hệ gắn bó, mật thiết trong toàn đội. Mỗi thành viên cần năng động và tận tâm vì mục tiêu chung. Mỗi thành viên trong nhóm là một sự hỗ trợ đắc lực cho những thành viên khác. Mặc dù, họ học chung trường, chung bằng cấp, trình độ, thì mỗi người cần phải quan tâm vào phần được giao và lẫn người khác. Trong một nhóm Mobile-D, một nhóm nhỏ sẽ hoạt động hiệu quả hơn một nhóm có só lượng thành viên lớn. Khi nói đến một nhóm nhỏ, thường thì chúng ta sẽ nghĩ ngay đến việc liệu nhóm đó có làm tốt hay không trong khi khối lượng công việc khá lớn. Nhưng một nhóm nhỏ trong Mobile-D lại trở nên hoạt động hiệu quả và hài hòa hơn. Giao tiếp là một yếu tố riêng biệt trong phương pháp Mobile-D, tính chất này được dùng để trao đổi và tương tác với khách hàng. Để thành công thì không chỉ có nhà quản lý dự án mà ngay cả những thành viên trong nhóm phát triển phải thiết lập quan hệ với khách hàng vì họ sẽ cung cấp tất cả các thông tin cần thiết. Vậy vấn đề chính ở đây có thể đ ược đ ại diện bởi khách hàng. Thêm vào đó, trong tình huống khác thì khách hàng sẽ có thể là bất cứ người nào tải ứng dụng về. Do vậy, họ không thể nào trực tiếp giao tiếp và luôn sẵn sàng cung cấp thông tin cho nhà phát triển được nên nhóm phát triển phải chú ý phát triển cả về chiều ngang lẫn chiều dọc, để nó trở thành một thách thức quyết định đến khả năng thành công của dự án. Deadline là vấn đề thường gặp và nó cũng có khá nhiều ảnh hưởng đ ến tiếng độ công việc. Những người bị dealine trong dự án thường là những người gặp nhiều vấn đề còn tồn đọng chưa thể giải quyết ở cái giai đoạn như planning days, working days và release days. Deadline là yếu tố đại diện cho hầu hết các vấn đề nảy sinh, không chỉ riêng ở phương pháp này mà ở tất cả các phương pháp, quy trình phát triển. Deadline sẽ khiến cho tiến độ công việc chậm lại, là hoàn toàn bộ hệ thống nếu như nó không được giải quyết sớm. r) Phương pháp chung Không chỉ dành riêng cho mobile phương pháp Mobile-D được thiết kế để có thể áp dụng ở nhiều lĩnh vực khác nhau ví dụ như tài chính, Logistic và nhiều ứng dụng khác. Mobile-D là một phương pháp phức hợp nên mỗi
phần của phương pháp khi đem ra sử dụng yêu cầu cần phải tùy chình sao cho phù hợp. Phương pháp này yêu cầu khá rõ ràng về thời gian, số lượng thành viên trong nhóm, quy mô ứng dụng phải được lên kế hoạch trước. Tính chất rõ ràng cũng được đề cập đến trong việc xây dựng các ứng dụng di động. Nguyên nhân là do sự thiếu hụt các ví dụ điển hình, những tài liệu không chuẩn khiến cho việc vận dụng phương pháp này trở nên khó khăn. Như đã đề cập ở trên thì việc sử dụng những story card hoặc task card đôi khi khó khăn trong việc so sánh với cái dự án tương tự để xác định mức độ đúng sai, chính xác của dự án hiện tại. Vì phương pháp này không nổi tiếng cũng như không phổ biến rộng như các phương pháp Agile khác nên với một người nào đó mới bước vào đều cảm thấy khó để hiểu đ ược nó. Cho nên công việc tiên quyết cần phải làm đó là phải hiểu cho được các mục đích các pha, các trạng thái lẫn Story/Task card. Không chỉ riêng những nhà quản lý dự án mà những lập trình viên cũng phải hiểu được rằng với phương pháp Mobile-D thì chương chình không được viết dựa trên những sơ đồ hay bằng UML mà lập trình viên phải dựa trên những Story card hoặc Task card để xây dựng chương trình. Mặc dù, mới đầu nó không mấy thân thiện với người sử dụng. Yếu tố trật tự cũng quan trọng không kém. Mới khi bắt đầu dự án, hẳn mỗi người quản trị đều khá khó khăn để xác định số lượng vòng lặp cần thiết để hoàn tất dự án. Như đã đề cập ở trên thì việc sắp xếp thời gian không hợp lý sẽ ảnh hưởng đến khoảng thời gian áp chót của giai đoạn Release days trong khâu sản xuất – Productionize, đều này sẽ làm cho toàn bộ dự án phải bị đình trệ. Nguyên nhân dẫn đến điều này có nhiều nhưng chủ yếu là do người quản lý thiếu kinh nghiệm trong việc sử dụng mô hình Mobile-D một khi có sự cố xảy ra.
REFERENCES