Xem mẫu
- 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
nguon tai.lieu . vn
