Tóm tắt: Khám phá 10 mẹo nhỏ cần thiết để tạo các ứng dụng Phần mềm là dịch vụ
(SaaS) hoàn thành đúng hạn và tiết kiệm ngân sách, mang lại lợi nhuận đầu tư
dương và thích hợp hơn.
Phần mềm được cung cấp như một dịch vụ trực tuyến, chứ không phải là một
ứng dụng trên máy tính để bàn, tiếp tục ngày càng được công chúng yêu
thích hơn với tốc độ theo cấp số nhân. Tôi đã dành hết tâm trí cùng với
một số doanh nghiệp tập trung vào SaaS. Và trong thời gian đó, tôi đã sưu
tập 10 yếu tố then chốt cụ thể để phát triển phần mềm có thể xác định xem
một ứng dụng SaaS có trở nên thành công không và — trong
nhiều trường hợp — liệu nó có được phát hành không. Những
mẹo nhỏ này nhằm mục đích đưa ra một viễn cảnh sáng tỏ về phát triển dựa
trên SaaS.
1. Làm cho UXD trở thành tài sản có giá
trị nhất của bạn
Với sự ra đời của Internet, sự chú ý đến trải nghiệm người dùng đã biến
mất. Tuy nhiên, chắc đã có cú hích ngược lại rõ ràng và hiển nhiên về
hướng đặc điểm quan trọng này của phần mềm thành công trong những năm gần
đây. Sự trở lại này đã được đánh dấu khi thuật ngữ Web 2.0 lần đầu
tiên đã trở thành một từ thông dụng, cuối cùng chuyển thành một cái gì đó
có ý nghĩa hơn: các ứng dụng Internet phong phú (RIA). Tôi cố ý đặt thiết
kế trải nghiệm-người dùng (UXD) ở vị trí số 1 trong bài viết này bởi vì
trải nghiệm người dùng là một đặc điểm có thể nhận biết được, ngay lập tức
làm cho người dùng máy tính chọn một ứng dụng này hơn ứng dụng khác.
Hình 1 và Hình 2 thể hiện hai kỹ
thuật UXD thú vị. Hình 1 minh họa một khái niệm được biết đến là ở lại
trang này. Vì đây là một ứng dụng máy khách RIA nhẹ được xây dựng
bằng cách sử dụng Adobe® Flex, nên rõ ràng không có trang nào.
Tuy nhiên, kỹ thuật này vẫn còn hợp lệ. Kịch bản trường hợp sử dụng này là
một người dùng muốn thay đổi các thiết lập tài khoản cá nhân của mình.
Thay vì rời khỏi trạng thái (hoặc trang) hiện tại của ứng dụng, một
cửa sổ phủ ngoài được hiển thị cho phép người dùng thực hiện các thay đổi
cần thiết, sau đó đóng cửa sổ và quay trở lại nhiệm vụ sắp tới.
Hình 1. Ví dụ về kỹ thuật UXD được gọi là ở lại trang
Hình 2 hiển thị một khung nhìn gần gũi hơn của cửa sổ
đã đưa ra trong Hình 1, nhưng theo hai cách. Trường hợp sử dụng này cụ thể
hơn ở chỗ nó được giả định rằng người dùng muốn thay đổi các giá trị
Company Information (Thông tin công ty) một cách riêng biệt và,
do đó, cần lựa chọn thanh tiêu đề tương ứng. Cửa sổ 1 hiển thị trạng thái
cửa sổ khi được hiển thị lần đầu. Cửa sổ 2 cho thấy trạng thái cửa sổ sau
khi người dùng đã nhấn vào thanh Company Information. Kỹ thuật này
được gọi là trình đơn đàn ắc-coóc-đê-ông (accordion menu) do cách
các ngăn trượt lên và xuống giống như đàn ắc-coóc-đê-ông khi thanh tiêu đề
tương ứng của chúng được lựa chọn. Hoạt động này nâng cao kinh nghiệm
người dùng bởi vì nó làm cho người dùng dễ dàng xác định vị trí và cập
nhật nhanh chóng và dễ dàng một hoặc nhiều giá trị khi phải phân loại các
thiết lập.
2. Thích ứng với các yêu cầu thay
đổi
Nếu có một điều không thể tránh khỏi trong quá trình phát triển phần mềm,
thì đó là ứng dụng khách, khách hàng, hoặc chủ sở hữu sản phẩm sẽ thay đổi
các yêu cầu của dự án sau khi đã hoàn thành tất cả thiết kế, lập kế hoạch,
tạo biểu đồ, và tạo nguyên mẫu. Hầu hết các nhà quản lý dự án được đào tạo
theo các phương pháp luận truyền thống, và một phần của chương trình đào
tạo đó là đối phó với thay đổi; kết quả là một mức độ tăng dần nguy hiểm
về sự "thoái hóa" gần giống với sản phẩm đạt đến bản phát hành chính thức
đầu tiên của nó.
Việc phát triển phần mềm tiến triển nhanh đến mức thật không khó để tìm ra
phương pháp luận quản lý dự án lõi đang thay đổi nhiều lần trong suốt vòng
đời của quá trình phát triển ban đầu. Kết quả là, sẵn sàng thực hiện các
phương pháp luận phát triển mới hoặc các biến thể của phương pháp
luận hiện có với mọi dự án.
3. Chấp nhận các chuẩn mở
Các công ty dựa vào SaaS phải xem xét việc chấp nhận các chuẩn mở vì khả
năng tương thích với các thiết bị, các nền tảng, các dịch vụ, và các ứng
dụng Web khác thể hiện qua việc mã hóa ít hơn các quá trình lặp lại và
việc chấp nhận người tiêu dùng sản phẩm lớn hơn trong tương lai. Người
tiêu dùng đánh giá cao và bị hút về ứng dụng SaaS cho phép họ hoàn thành
nhiều nhiệm vụ. Ví dụ, Hình 3 cho thấy TweetDeck, một ứng dụng làm việc
trên nhiều nền tảng sử dụng các API mở của Twitter và Facebook trong một
giao diện. TweetDeck đang nhanh chóng trở thành một trong những ứng dụng
khách Twitter phổ biến nhất, chủ yếu là do những người dùng Twitter cũng
có thể xem các cập nhật trạng thái của các bạn bè Facebook của họ mà không
cần chuyển đổi các ứng dụng.
Hình 3. Ứng dụng TweetDeck phổ biến sử dụng các API mở của Twitter và Facebook
Có thể làm giảm đáng kể chi phí tài chính cho một doanh nghiệp bằng cách sử
dụng các công cụ dựa trên các chuẩn mở vì lệ phí cấp giấy phép được loại
bỏ, và chi phí tài nguyên giảm bớt bởi vì bạn có một điểm khởi đầu vượt xa
nơi bạn sẽ tới nếu bạn vẫn đang xây dựng từ đầu. Sau đó, bạn có thể phân
phối tài nguyên để thay đổi mã nguồn nhằm đáp ứng các nhu cầu và các thách
thức kinh doanh. Ví dụ, các tác giả của TweetDeck có thể tập trung vào
việc xây dựng các tính năng trải nghiệm người dùng trong các ứng dụng,
thay vì phải làm việc trên các API của Twitter và Facebook, vốn rất nặng
nề.
Hãy xem: Điều gì sẽ xảy ra nếu Twitter và Facebook tính tiền sử dụng các
API của họ? TweetDeck sẽ có thể phải thu phí sử dụng hàng tháng với người
dùng sao cho công ty có thể trả cho Twitter và Facebook phí để sử dụng các
API của họ. Hoặc người dùng sẽ phải trả cho Twitter và Facebook một khoản
phí hàng tháng chỉ để sử dụng ứng dụng TweetDeck. Ảnh hưởng mang lại sẽ
làm thiệt hại cho TweetDeck, Twitter, và Facebook, và TweetDeck có thể
không còn được coi là một ứng dụng SaaS thành công nữa.
4. Phác thảo cấu trúc chung trước khi
thiết kế
Một phác thảo cấu trúc chung (wireframe) đơn giản chỉ là một sự hình
dung dựa trên khái niệm về một trạng thái cụ thể của giao diện người dùng
của một chương trình phần mềm theo quan điểm chức năng, như hiển thị trong
Hình 4. Lưu ý rằng không có thiết kế ấn tượng nào. Mục đích là để tránh bị
phân tâm bởi các phần tử thiết kế sao cho có thể duy trì sự tập trung vào
chức năng nghiệp vụ. Một khi đã thiết lập các chức năng nghiệp vụ của ứng
dụng, nhóm thiết kế có thể có ở đó; nhưng phần mềm phải chỉ rõ chức năng
trước khi nó có thể trông đẹp mắt.
Hình 4. Phác thảo cấu trúc chung đưa ra hình dung dựa trên khái niệm về một giao diện người dùng
Khía cạnh này ràng buộc rất nhiều với UXD, yếu tố đầu tiên của SaaS thành
công. Sự khác biệt là để thành công với SaaS, UXD phải là một phần của
toàn bộ vòng đời phát triển phần mềm từ ý tưởng đến sản xuất. Khi nói đến
việc phác thảo cấu trúc chung, tôi luôn thấy hai sai lầm làm cho SaaS
không đạt được:
- Nhóm làm việc nhảy quá nhanh sang thiết kế, và làm cho chủ đề thiết kế của ứng dụng đột nhiên trở thành một phần của quá trình phác thảo cấu trúc chung, vì các bên liên quan muốn nhìn thấy một cái gì đó trông đẹp mắt thay vì chức năng.
- Các trạng thái chính của ứng dụng đang mất dần khỏi bộ sưu tập phác thảo cấu trúc chung (có nghĩa là, chỉ phác thảo cấu trúc chung các phần của ứng dụng).
Thật thú vị, điều thứ hai của hai lý do trên hầu như bất lợi với một dự án
SaaS. Điều hấp dẫn nhất về các phác thảo cấu trúc chung là bạn có thể dựa
vào chúng để trưng ra các khoảng trống về nhận thức các yêu cầu sản phẩm.
Người ta hiểu chúng để trưng rõ các thiếu sót thiết kế kiến trúc cốt lõi
trước khi bắt đầu quá trình phát triển. Với ý nghĩ đó, không khó để tưởng
tượng ra rằng việc đảm bảo cho quá trình phác thảo cấu trúc chung hoàn
thành có thể tiết kiệm cho doanh nghiệp rất nhiều về thời gian và tài
nguyên.
Một bộ phác thảo cấu trúc chung đã hoàn thành cũng có thể chứa hơn 100 tài
liệu. Mỗi phác thảo cấu trúc chung nên được kết hợp tối thiểu với một mô
tả có một hay hai trang để giúp các bên liên quan hiểu những gì họ đang
thấy khi xem lại các phác thảo cấu trúc chung. Hãy nhớ rằng các phác thảo
cấu trúc chung này sẽ cần phải được sửa lại trước khi các bên liên quan
ngừng nói về chúng. Tốt hơn nên nhận biết các sự khác biệt trong quá trình
phác thảo cấu trúc chung hơn sau khi đã mã hóa chức năng.
Lưu ý: Sau khi quá trình thiết kế diễn ra, bộ các tài liệu hoàn
chỉnh, lúc này định nghĩa các giao diện người dùng, thường được gọi là
sách ảnh.
5. Cung cấp SaaS với một cơ sở hạ tầng
đám mây
Lúc đầu, giả thiết rằng cơ sở hạ tầng mạng có thể tạo ra hoặc phá vỡ SaaS
có thể dường như là quá dễ dàng. Tuy nhiên, hầu hết các ứng dụng SaaS trên
Web đang chạy trên phần cứng không đủ được gắn với một cơ sở hạ tầng không
thể điều chỉnh được theo yêu cầu. Là các nhà phát triển, chúng tôi có
quyền truy cập vào các hệ thống đám mây tự điều chỉnh thường được gọi là
Cơ sở hạ tầng là dịch vụ (IaaS), nhưng việc chấp nhận công nghệ
cao hơn này là sự chậm hiểu đáng kinh ngạc.
Sự chậm hiểu này có thể được cho chủ yếu là do thiếu kiến thức về chủ đề
này. Ví dụ, Đám mây điện toán co giãn của của Amazon (Amazon EC2 -Amazon
Elastic Compute Cloud) có khả năng tạo ra các khoản tiết kiệm lớn cho các
doanh nghiệp đang chạy các ứng dụng SaaS, nhưng sự thiếu kiến thức chung
về cơ sở hạ tầng của Các dịch vụ Web của Amazon (AWS-Amazon Web Services)
làm cho nhiều doanh nghiệp quay về các hệ thống di sản bởi vì đó là những
gì họ biết. Tuy nhiên, sự gia tăng liên tục về băng thông có sẵn của các
ISP như là một sự đảm bảo rằng bất kỳ các ứng dụng SaaS thành công nào
cũng sẽ đòi hỏi hiệu năng mạng cao cấp hơn về việc mở rộng tài nguyên tự
động theo yêu cầu.
6. Tạo ra tài liệu thiết kế hoàn chỉnh
trước khi bắt đầu mã hóa
Phần mềm làm việc giống như cách các doanh nghiệp làm, và một đặc điểm
chính của các công ty SaaS thành công là tôn trọng đáng kể đối với giai
đoạn lập kế hoạch của quá trình phát triển. Tài liệu thiết kế chất lượng
cao dùng như một bản đồ đường đi cho những người chịu trách nhiệm về thực
hiện thiết kế và có khả năng tăng tốc độ mã hóa phần mềm lên đáng kể. Đó
là lý do tại sao các ứng dụng SaaS thành công thường là các dự án thực
hiện đúng hạn và không quá ngân sách.
Khi các ứng dụng SaaS thực hiện quá hạn và chi vượt ngân sách, đó là do sự
trao đổi thông tin về các nguyên lý thiết kế kiến trúc cho dự án rất kém.
Để duy trì tính nhất quán mã xuyên suốt một ứng dụng SaaS lớn, điều quan
trọng là thiết lập một bộ các mẫu thiết kế và các quy ước hoàn chỉnh và
trao đổi thông tin có hiệu quả trong toàn bộ nhóm phát triển. Một cách
tuyệt vời để trao đổi thông tin về các nguyên lý như vậy là nhờ sử dụng vỏ
não thị giác.
Sử dụng vỏ não thị
giác
Một số lượng đáng kinh ngạc về các nghiên cứu lâm sàng về tư duy và học tập
của con người được tiến hành trong vòng 100 năm qua cho thấy rằng con
người học nhanh hơn khi có nhiều hơn một trong năm giác quan được tham gia
vào quá trình học tập. Sự tham gia của thị giác ngoài thính giác làm cho
người học có khả năng nhớ vấn đề học gần đến bảy lần. Không có gì lạ,
trong trường hợp đó, các tín hiệu hình ảnh như các biểu đồ và các đồ thị
dòng công việc rất hiệu quả khi nó đi kèm với tài liệu phần mềm kỹ
thuật.
Như Hình 5 cho thấy, kiến trúc phần mềm và các biểu đồ kiến trúc cực nhỏ có
ích cho việc thiết lập và truyền thông một nền tảng với một ứng dụng khách
RIA và cung cấp cho các nhóm phát triển một phác thảo để làm theo khi
thiết lập mã. Các biểu đồ này cũng thiết lập một tập các hướng dẫn và các
kỳ vọng của một quan điểm cấu trúc.
Hình 5. Khung nhìn cao cấp, vẽ phóng về các mẫu thiết kế cấu trúc của một chương trình
Các biểu đồ dòng công việc cũng đặc biệt có ích để truyền đạt một quá trình
hoặc một loạt các sự kiện. Trong nhiều trường hợp, bạn có thể càng sáng
tạo thì các biểu đồ dòng công việc trở nên càng hiệu quả. Hình 6 thể hiện
cách thực hiện sáng tạo trong một biểu đồ dòng công việc được sử dụng để
đưa ra sự mô tả trực quan về Khung công tác Swiz với Flex (Swiz Framework
for Flex) nguồn mở thực hiện Phép nghịch đảo điều khiển (IoC - Inversion
of Control), phép nội quan đối tượng, và phép nội xạ phụ thuộc.
Hình 6. Biểu đồ dòng công việc của Khung công tác Swiz với Flex nguồn mở
Nếu bạn đã từng hỗ trợ, đã lưu trữ thông tin, hoặc nếu không thì đã được
tham gia vào việc tạo một bằng sáng chế phương pháp, thì biểu đồ trong
Hình 7 trông khá quen thuộc. Nó đặc biệt có ích để hiển thị một quá trình
hoặc phương pháp ở đó có nhiều khả năng. Một ví dụ hay về điều này là một
quá trình liên quan đến một số các hàm, một số trong đó bao gồm một hoặc
nhiều điều kiện, ví dụ như các câu lệnh
if - else (nếu-khác) và
switch (chuyển nhánh). Các biểu đồ mô tả chức
năng vô cùng tiện dụng để phác thảo các quy trình nghiệp vụ kỹ thuật cũng
như phần mềm. Ví dụ, kiểu biểu đồ này sẽ là tối ưu cho việc phác thảo quá
trình cam kết mã với kho lưu trữ kiểm soát mã nguồn tập trung của công
ty.Hình 7. Biểu đồ mô tả chức năng, được sử dụng để duyệt một quá trình hoặc phương pháp có điều kiện
7. Suy ngẫm về các bài thử nghiệm đơn
vị
Nói chung, những người có triển vọng thành công về SaaS luôn có các ứng
dụng khá lớn do nhiều người xây dựng. Khi nói đến các ứng dụng lớn và việc
thử nghiệm đơn vị, thì dữ liệu là nhất quán: Các dự án, thực hiện các bài
thử nghiệm đơn vị sau, sẽ thất bại thảm hại. Với cách giải quyết trước,
các nhà phát triển SaaS thành công viết các bài thử nghiệm đơn vị và thậm
chí chạy chúng trước khi họ viết mã. Ví dụ, nếu tôi được giao nhiệm vụ
viết một lớp có tên là
ServiceController, tôi
sẽ không bắt đầu bằng cách mã hóa lớp này. Thay vào đó, tôi sẽ viết lớp
chạy tất cả các trường hợp thử nghiệm đơn vị dựa vào các phương thức trong
lớp đó. Sau đó, thậm chí tôi tiến lên một bước nữa và chạy các trường hợp
thử nghiệm, mặc dù tôi biết chúng sẽ thất bại bởi vì tôi đã chưa thực sự
viết bất kỳ mã nào cho nó.
Mục đích của bài tập này là để loại trừ khả năng thực sự có lỗi trong các
bài thử nghiệm đơn vị của bạn để có thể làm cho chúng luôn được thông qua.
Dù là bất thường khi nó xảy ra, nhưng rất dễ dàng vô tình tạo ra lỗi này.
Với điều kiện là tất cả các bài thử nghiệm đơn vị đều thất bại, tôi biết
rằng mình đã sẵn sàng để bắt đầu viết mã thực tế. Khi tôi đã hoàn thành
viết lớp mới này, rồi tôi sẽ chạy lại bài thử nghiệm đơn vị. Miễn là tất
cả các trường hợp thử nghiệm đều vượt qua, tôi thêm lớp của bài thử nghiệm
đơn vị mới vào thư viện tự động hóa thử nghiệm đơn vị của tôi, chạy trên
mọi quá trình xây dựng. Nói cách khác, toàn bộ thư viện thử nghiệm đơn vị
mà tôi tạo cho một ứng dụng sẽ trở thành một phần của quá trình xây dựng
của tôi. Trong thực tế, ngay cả trước khi tôi bắt đầu xây dựng dự án, tất
cả các bài thử nghiệm đơn vị đều được chạy để đảm bảo rằng tính toàn vẹn
của mã ứng dụng đã không vô tình bị xâm phạm.
Trong thế giới lập trình, tôi chỉ thấy một vài nhà phát triển thường xuyên
áp dụng quá trình này. Tuy nhiên, họ là một trong số những cá nhân được
tôn trọng, có uy tín, và được trả lương cao trong ngành công nghiệp. Nếu
bạn đang tìm kiếm một con đường tăng lương hoặc thăng tiến nhanh chóng,
hãy suy ngẫm bài thử nghiệm đơn vị.
8. Giải quyết các việc lớn, chứ không
phải các việc bé
Khả năng thắt cổ chai hiệu năng với các ứng dụng SaaS lớn hơn nhiều so với
các ứng dụng khách "nặng" chạy từ máy tính để bàn. Ngay cả những lập trình
viên kỳ cựu cũng sẽ thừa nhận rằng khi nói đến các ứng dụng SaaS, đôi khi
rất khó dự đoán được các thắt cổ chai hiệu năng do có quá nhiều các thay
đổi có liên quan. Sự khác biệt giữa các ứng dụng SaaS thành công và các
ứng dụng SaaS thất bại là cách mà nhóm phát triển đáp ứng với số lần truy
cập hiệu năng bất lợi trong quá trình thử nghiệm và lược tả tải.
Nói chung, chỉ có hai kiểu tối ưu hóa hiệu năng: các kiểu thực hiện một tác
động đáng kể đến hiệu năng và các kiểu dường như không có bất kỳ kết quả
đáng chú ý nào. Hiếm khi có bất cứ điều gì ở giữa. Một ẩn dụ thường được
sử dụng trong lĩnh vực này là các việc lớn và các việc bé. Thường thường,
các nhà phát triển dành phần lớn thời gian được phân bổ để nâng cao hiệu
năng, giải quyết các việc bé còn hơn là giải quyết các vấn đề to lớn vượt
quá khả năng hoạt động của bộ vi xử lý hoặc bộ nhớ của máy tính trong khi
các ứng dụng đang chạy. Điều quan trọng cần loại bỏ ở đây là, với tư cách
là một lập trình viên, bạn không thể thấy việc lớn khi bạn quá bận rộn
nhìn vào các việc nhỏ.
Cách dễ nhất để tránh bị phân tâm bởi các việc nhỏ là lược tả các ứng dụng
của bạn. Việc lược tả là một phần quan trọng của dự án SaaS thành công bởi
vì nó mang lại cho bạn cơ hội để tối ưu hóa cách ứng dụng của bạn sử dụng
tài nguyên hệ thống, như thể hiện trong Hình 8. Khi bạn lược tả một ứng
dụng, bạn có thể thấy chính xác các đoạn ứng dụng nào đang chiếm nhiều tài
nguyên nhất và thực hiện các mẫu thiết kế cho hiệu năng tăng lên. Ví dụ,
bạn có thể thấy việc thực hiện phân nhóm đối tượng với các ủy quyền
(proxy) là cần thiết nếu bạn tìm thấy nhiều bản cài đặt lại đối tượng mà
không có việc thu gom rác thải cần thiết, do việc thu gom rác liên tục
chiếm dụng bộ nhớ nhiều hơn miễn là bạn phải rời khỏi ứng dụng đang
chạy.
Hình 8. Lược tả ứng dụng trong Eclipse
9. Tìm hiểu từ các dự án SaaS thành công
khác
Cách đơn giản nhất học được từ các dự án SaaS thành công khác là bắt đầu
bằng cách chọn một chương trình SaaS mà bạn đã sử dụng. Sau đó, tìm ra hai
hoặc ba đối thủ cạnh tranh về phần mềm mà bạn đã chọn và đưa chúng ra thử,
viết ra những điều cụ thể thu hút được sự chú ý của bạn và liên quan đến
lý do bạn thích hoặc không thích những ứng dụng tương ứng.
Thật hiếm có được một ứng dụng có thể thu hút sự chú ý của tôi về khả năng
dễ sử dụng và hiệu năng, vì thế khi nó xảy ra, tôi đảm bảo cần có thời
gian để tìm hiểu lý do vì sao tôi thường tìm hiểu điều gì từ nó. Một ứng
dụng quản lý nhiệm vụ đã thu hút sự chú ý của tôi gần đây, chủ yếu là do
tôi tìm thấy thể loại các ứng dụng này chứ không phải vì không hiểu rõ.
Tuy nhiên, mức độ dễ sử dụng có liên quan đến ứng dụng SaaS cụ thể này đã
rất ấn tượng.
Tôi đã dành khoảng hai giờ để chuyển hướng ứng dụng này, thử nghiệm các hạn
chế của nó và đánh giá khả năng tiếp cận của vô số tính năng của nó. Tôi
thích các ứng dụng có một số lượng các tính năng được dựng sẵn khác
thường, nhưng tôi hy vọng chúng vẫn còn khá nhẹ. Vì lý do này, tôi nhận
xét về thiết kế giao diện người dùng. Nếu giao diện này không được thiết
lập tốt, thì một ứng dụng có nhiều tính năng sẽ trở thành một tình huống
sử dụng đáng sợ, bởi vì không thể tìm thấy những thứ bạn đang chờ mất nửa
thời gian. Đánh giá của tôi về ứng dụng SaaS cụ thể này đưa tôi đến kết
luận rằng ứng dụng này có tổ chức giao diện người dùng độc nhất và không
theo quy tắc khi so sánh với các ứng dụng quản lý nhiệm vụ khác mà tôi đã
cài đặt, cho phép tôi thích làm việc với nó.
10. Xây dựng các nguyên mẫu có thể sử
dụng
Một nguyên mẫu có còn là một nguyên mẫu không nếu một mã tương tự được sử
dụng để xây dựng nó cũng được sử dụng để tạo ra sản phẩm cuối cùng?
Câu trả lời cho câu hỏi này là đúng như vậy. Trong việc phát triển phần
mềm, khách hàng thường muốn nhìn thấy bằng chứng về khái niệm trước khi
đầu tư vào việc phát triển thực tế. Một nguyên mẫu không có gì hơn một
bằng chứng về khái niệm. Các nhà phát triển SaaS thông minh tận dụng thời
gian mà họ được cung cấp để tạo các nguyên mẫu. Hãy xem xét có thể làm
xong bao nhiêu nguyên mẫu trong thời gian này:
- Thiết kế và bố trí nền tảng kiến trúc.
- Tạo lược đồ cơ sở dữ liệu SaaS bằng cách xây dựng một XML DTD tùy chỉnh, và sử dụng XML làm nguồn dữ liệu của nguyên mẫu. (Lược đồ có thể được nhập khẩu sau vào máy cơ sở dữ liệu và được chuyển đổi thành lược đồ thực tế trong một vài phút).
- Tạo gói cấu tạo của ứng dụng đủ kích thước, giao diện, cấu trúc lớp, thậm chí nếu các tệp không hơn gì nhiều so với khai báo tên lớp và giao diện thì thực hiện từ đầu.
Có một số lợi thế với cách tiếp cận này, nhưng có hai lợi thế là chìa khóa
giúp SaaS thành công: Bạn có một khởi đầu sớm vào đúng thời điểm để xây
dựng sản phẩm thực tế, và các mẫu thiết kế đối lập và các kiến trúc được
thiết kế kém sẽ luôn hiển thị các khuôn mặt xấu xí của chúng khi nguyên
mẫu được xây dựng trên đỉnh của chúng. Sau đó có thể thực hiện các thay
đổi cần thiết trước khi việc phát triển sản phẩm thực tế bắt
đầu.
Kết luận
Điều quan trọng là nhận ra rằng thế giới phát triển phần mềm tiến triển
nhanh đến mức các yếu tố chính cho sự phát triển SaaS thành công cuối cùng
sẽ thay đổi — có thể sớm còn hơn là muộn. Bí quyết là đẩy
nhanh tốc độ quá trình tiến hóa và vị trí của chính bạn để vượt qua khúc
rẽ ấy.
Tài nguyên
Học tập
- Để nghe các cuộc phỏng vấn và các cuộc
thảo luận thú vị dành cho các nhà phát triển phần mềm, hãy và developerWorks
podcasts.
- Theo sát với các sự kiện kỹ thuật và các
webcast của developerWorks.
- Theo dõi developerWorks trên
Twitter.
- Xem các hội nghị, triển lãm thương mại,
Webcast sắp tới và Các sự kiện khác trên thế giới
được các nhà phát triển nguồn mở của IBM quan tâm.
- Truy cập vào Vùng mã nguồn mở của
developerWorks với các thông tin hướng dẫn rộng lớn, các công cụ và các
bản cập nhật dự án để giúp bạn phát triển bằng các công nghệ mã nguồn mở
và sử dụng chúng với các sản phẩm của IBM.
- Xem và tìm hiểu về IBM và các công nghệ
mã nguồn mở và các chức năng sản phẩm với các trình diễn theo yêu cầu miễn
phí của developerWorks.
Lấy sản phẩm và công nghệ
-
iPlotz: Khám phá một cách tài tình để tạo
các mô hình và các phác thảo cấu trúc chung của bạn.
- Đổi mới dự án
phát triển nguồn mở tiếp theo của bạn bằng phần mềm dùng thử của IBM, có
sẵn để tải xuống hoặc trên đĩa DVD.
- Tải về các phiên bản đánh giá sản phẩm IBM hoặc khám phá các bản dùng thử trực tuyến trong Sandbox SOA của IBM và nhận được các công cụ phát triển ứng dụng thực hành của bạn và các sản phẩm phần mềm trung gian từ DB2®, Lotus®, Rational®, Tivoli®, và WebSphere®.
0 comments:
Post a Comment