Phát triển người dùng cuối

Quy mô dân số dự kiến ​​cho các nơi làm việc của Mỹ vào năm 2012, dựa trên dữ liệu liên bang (lưu ý rằng các danh mục không loại trừ lẫn nhau)

Người dùng máy tính đã tăng nhanh cả về số lượng và sự đa dạng (Scaffidi và cộng sự 2005). Họ bao gồm các nhà quản lý, kế toán, kỹ sư, nhà sản xuất, giáo viên, nhà khoa học, nhân viên chăm sóc sức khỏe, người điều chỉnh bảo hiểm, nhân viên bán hàng và trợ lý hành chính. Nhiều người trong số những người này làm việc với các nhiệm vụ thay đổi nhanh chóng hàng năm, hàng tháng hoặc thậm chí hàng ngày. Do đó, nhu cầu phần mềm của họ rất đa dạng, phức tạp và thường xuyên thay đổi. Các nhà phát triển phần mềm chuyên nghiệp không thể đáp ứng trực tiếp tất cả các nhu cầu này vì kiến ​​thức miền hạn chế của họ và vì quy trình phát triển của họ quá chậm.

Phát triển người dùng cuối (EUD) giúp giải quyết vấn đề này. EUD là “một tập hợp các phương pháp, kỹ thuật và công cụ cho phép người dùng hệ thống phần mềm, những người đóng vai trò là nhà phát triển phần mềm không chuyên nghiệp, tại một thời điểm nào đó, tạo, sửa đổi hoặc mở rộng một tạo tác phần mềm ” (Lieberman và cộng sự 2006). Đặc biệt, EUD cho phép người dùng cuối thiết kế hoặc tùy chỉnh giao diện người dùngvà chức năng của phần mềm. Điều này có giá trị vì người dùng cuối hiểu rõ bối cảnh và nhu cầu của chính họ hơn bất kỳ ai khác và họ thường có nhận thức theo thời gian thực về sự thay đổi trong các miền tương ứng của họ. Thông qua EUD, người dùng cuối có thể điều chỉnh phần mềm để phù hợp hơn với yêu cầu của họ hơn là có thể nếu không có EUD. Hơn nữa, bởi vì người dùng cuối đông hơn các nhà phát triển phần mềm chuyên nghiệp theo hệ số 30 trên 1 (Hình 1), EUD “mở rộng quy mô” các hoạt động phát triển phần mềm bằng cách cho phép một nhóm lớn hơn nhiều người tham gia.

Tuy nhiên, EUD vốn dĩ khác với phát triển phần mềm truyền thống và việc cố gắng hỗ trợ EUD bằng cách bắt chước các cách tiếp cận truyền thống thường không đủ để tạo ra kết quả thành công. Người dùng cuối thường không được đào tạo về ngôn ngữ lập trình của chuyên gia, quy trình phát triển chính thức, hoặc ký hiệu mô hình hóa và sơ đồ hóa. Hơn nữa, người dùng cuối thường thiếu thời gian hoặc động lực để học những kỹ thuật truyền thống này, vì người dùng cuối thường viết mã để đạt được mục tiêu ngắn hạn hoặc trung hạn hơn là để tạo ra một tài sản phần mềm lâu bền sẽ tạo ra một dòng doanh thu liên tục. Do đó, hỗ trợ EUD đòi hỏi phải cung cấp các công cụ, cấu trúc xã hội phù hợpvà các quy trình phát triển có khả năng sử dụng cao, học hỏi nhanh chóng và dễ dàng tích hợp vào thực tiễn miền.

EUD trùng lặp với hai khái niệm tương tự, lập trình người dùng cuối và kỹ thuật phần mềm người dùng cuối. Lập trình người dùng cuối (EUP) cho phép người dùng cuối tạo các chương trình của riêng họ (Ko và cộng sự 2011). Tập hợp con của EUD này là nhóm trưởng thành nhất từ ​​quan điểm nghiên cứu và thực hành, vì vậy chúng tôi tập trung phần sau của bài viết này vào phần đó của EUD. Sự khác biệt giữa EUP và EUD là các phương pháp, kỹ thuật và công cụ của EUD trải dài trong toàn bộ vòng đời phát triển phần mềm, bao gồm cả việc sửa đổi và mở rộng phần mềm, không chỉ ở giai đoạn “tạo”.

Khái niệm liên quan khác trùng lặp với EUD là kỹ thuật phần mềm người dùng cuối (EUSE). EUSE là một tập hợp con tương đối mới của EUD bắt đầu cách đây khoảng một thập kỷ. Nó nhấn mạnh vào chất lượng của phần mềm mà người dùng cuối tạo, sửa đổi hoặc mở rộng; do đó nghiên cứu của nó tập trung vào các phương pháp, kỹ thuật và công cụ thúc đẩy chất lượng của phần mềm đó. Khu vực này đã phát sinh do có nhiều bằng chứng cho thấy các chương trình mà người dùng cuối tạo ra chứa đầy các lỗi đắt tiền (Panko 1998; Burnett 2010; Ko et al 2011). Do đó, chúng tôi tập trung vào tập hợp con EUSE của EUD trong phần sau của bài viết này.

Quy mô dân số dự kiến ​​cho các nơi làm việc của Mỹ vào năm 2012, dựa trên dữ liệu liên bang (lưu ý rằng các danh mục không loại trừ lẫn nhau)

Tác giả / Người giữ bản quyền: Được phép của Christopher Scaffidi. Điều khoản bản quyền và giấy phép: Không xác định (đang chờ điều tra). Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.1 : Quy mô dân số dự kiến ​​cho các nơi làm việc của Mỹ vào năm 2012, dựa trên dữ liệu liên bang (lưu ý rằng các danh mục không loại trừ lẫn nhau)

Tác giả / Chủ bản quyền: Được phép của Rikke Friis Dam và Mads Soegaard. Điều khoản bản quyền và giấy phép: CC-Att-ND (Creative Commons Attribution-NoDerivs 3.0 Unported)

Tác giả / Chủ bản quyền: Được phép của Rikke Friis Dam và Mads Soegaard. Điều khoản bản quyền và giấy phép: CC-Att-ND (Creative Commons Attribution-NoDerivs 3.0 Unported)

Phát triển người dùng cuối – Giá trị kinh doanh – Khả năng áp dụng trong ngành

Tác giả / Chủ bản quyền: Được phép của Rikke Friis Dam và Mads Soegaard. Điều khoản bản quyền và giấy phép: CC-Att-ND (Creative Commons Attribution-NoDerivs 3.0 Unported)

Phát triển người dùng cuối – Định hướng trong tương lai

10.1 Sự ra đời của EUD

Trước những năm 1980, hầu hết các máy tính diễn ra trên các máy tính lớn do các nhà phát triển chuyên nghiệp trong các bộ phận hệ thống thông tin điều khiển. Người dùng cuối có rất ít ảnh hưởng đến hình thức và chức năng của phần mềm chạy trên máy tính lớn, mà họ thường xem qua các cửa sổ đầu cuối đơn giản và được điều khiển bằng các lệnh đơn giản bằng văn bản (Hình 2). Các bộ phận hệ thống thông tin hiếm khi có đủ thời gian cho nhân viên để thiết kế và triển khai tất cả các cải tiến phần mềm mà người dùng yêu cầu (Brancheau và Wetherbe 1987).

EUD phát triển từ sự kết hợp của những đổi mới thể hiện trong những cỗ máy được gọi là “máy vi tính” (một thuật ngữ cuối cùng được thay thế bằng “máy tính cá nhân”). Đầu tiên, những chiếc máy này đủ rẻ để các tổ chức có thể đủ khả năng cung cấp cho mỗi người dùng một chiếc máy. Việc có máy riêng giúp người dùng có thể sửa đổi (“điều chỉnh”) cài đặt phần mềm của máy mà không ảnh hưởng đến môi trường máy tính của người dùng khác. Thứ hai, máy vi tính có đủ sức mạnh phần cứng để người dùng có thể biên dịch (hoặc thông dịch) mã mới bằng các ngôn ngữ như Basic. Điều này lại cung cấp cơ sở hạ tầng cho người dùng cuối để tạo các ứng dụng mới. Thứ ba, máy tính siêu nhỏ sớm bao gồm các tính năng mới sáng tạo như chuột và card đồ họa mạnh mẽ, giúp tăng khả năng sử dụngnhững tiến bộ như giao diện người dùng đồ họa (GUI) và thao tác trực tiếp; đến lượt nó, những tiến bộ này đã mở ra khả năng của các công cụ lập trình mới được thiết kế đặc biệt để đáp ứng nhu cầu của người dùng.

Tăng tốc sự nghiệp của bạn:
Nhận chứng chỉ khóa học được ngành công nhận

Ví dụ về chứng chỉ

  • Đóng in 6 hrs 42 mins 31 secs :

    Trở thành Nhà thiết kế UX từ Scratch

  • Đóng cửa in 4 days :

    Trải nghiệm người dùng: Hướng dẫn cho người mới bắt đầu

  • Đóng cửa in 6 days :

    Tương tác giữa người và máy tính – HCI

Bảng tính là môi trường lập trình EUD chính đầu tiên được tạo ra nhờ những đổi mới này (Bricklin và cộng sự 1979), bắt đầu với VisiCalc (Hình 3), sau đó tiếp tục với Lotus 1-2-3 và Excel. Mặc dù người dùng hệ thống bảng tính có thể không nghĩ mình đang “lập trình”, nhưng hệ thống bảng tính là môi trường lập trình vì công thức của chúng là chương trình chức năng bậc nhất (Jones và cộng sự 2003). Trong các chương trình như vậy, các công thức có thể tham chiếu đến các “biến” đầu vào (tên ô) và kết quả của các công thức là các giá trị đầu ra được tính toán. Sự sẵn có của phần mềm bảng tính là một yếu tố chính trong việc thúc đẩy nhu cầu sớm về máy vi tính (Ichbiah 1993). Các công nghệ mới hơn như web và điện toán di độngtừ đó đã mở ra các cơ hội ngày càng đa dạng và mạnh mẽ cho người dùng cuối để tạo và điều chỉnh phần mềm.

Giao diện đầu cuối trình bày một menu cố định, nơi người dùng nhập một số để chỉ ra lựa chọn menu

Tác giả / Chủ bản quyền: Được phép của e53 Điều khoản bản quyền và giấy phép: CC-Att-SA-2 (Creative Commons Attribution-ShareAlike 2.0 Unported).

Hình 10.2 : Giao diện đầu cuối trình bày một menu cố định, trong đó người dùng nhập một số để chỉ ra lựa chọn menu

Visicalc khoảng năm 1980

Tác giả / Người giữ bản quyền: Được phép của Dave Winer. Điều khoản bản quyền và giấy phép: CC-Att-SA-2 (Creative Commons Attribution-ShareAlike 2.0 Unported).

Hình 10.3 : Visicalc khoảng năm 1980

10.2 May đo

Chỉnh sửa là bất kỳ “hoạt động nào để sửa đổi một ứng dụng máy tính trong bối cảnh sử dụng của nóhoặc các phần tử giao diện người dùng đồ họa khác trong một ứng dụng. Các macro như vậy có thể mở rộng các ứng dụng với chức năng mới hoặc làm cho chức năng hiện có dễ sử dụng hơn (Hình 6). Các nhà nghiên cứu đã đề xuất một loạt các khuôn khổ dựa trên thành phần có thể được sử dụng để triển khai các ứng dụng dễ dàng điều chỉnh (Won và cộng sự 2006). Ví dụ, đối tượng “Lựa chọn” được tham chiếu trong Hình 6 thực sự là một thành phần đại diện cho vùng văn bản hiện được người dùng đánh dấu trong trình xử lý văn bản. Khung dựa trên thành phần giúp trình thông dịch có thể thao tác văn bản được đánh dấu theo hướng dẫn của macro. Các nhà nghiên cứu đã đề xuất một loạt các khuôn khổ dựa trên thành phần có thể được sử dụng để triển khai các ứng dụng dễ dàng điều chỉnh (Won và cộng sự 2006). Ví dụ, đối tượng “Lựa chọn” được tham chiếu trong Hình 6 thực sự là một thành phần đại diện cho vùng văn bản hiện được người dùng đánh dấu trong trình xử lý văn bản. Khung dựa trên thành phần giúp trình thông dịch có thể thao tác văn bản được đánh dấu theo hướng dẫn của macro. Các nhà nghiên cứu đã đề xuất một loạt các khuôn khổ dựa trên thành phần có thể được sử dụng để triển khai các ứng dụng dễ dàng điều chỉnh (Won và cộng sự 2006). Ví dụ, đối tượng “Lựa chọn” được tham chiếu trong Hình 6 thực sự là một thành phần đại diện cho vùng văn bản hiện được người dùng đánh dấu trong trình xử lý văn bản. Khung dựa trên thành phần giúp trình thông dịch có thể thao tác văn bản được đánh dấu theo hướng dẫn của macro.

Màn hình trong Microsoft Excel để điều chỉnh các tính năng nào nên được kích hoạt và hiển thị

Tác giả / Người giữ bản quyền: Được phép của Christopher Scaffidi. Điều khoản bản quyền và giấy phép: Không xác định (đang chờ điều tra). Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.4 : Màn hình trong Microsoft Excel để điều chỉnh các tính năng nào nên được kích hoạt và hiển thị

Màn hình trong Microsoft Word để điều chỉnh cách ứng dụng xử lý các nhấp chuột vào siêu liên kết, lệnh sao chép / dán và các loại đầu vào khác của người dùng

Tác giả / Người giữ bản quyền: Được phép của Christopher Scaffidi. Điều khoản bản quyền và giấy phép: Không xác định (đang chờ điều tra). Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.5 : Màn hình trong Microsoft Word để điều chỉnh cách ứng dụng xử lý các nhấp chuột vào siêu liên kết, lệnh sao chép / dán và các loại đầu vào khác của người dùng

Sử dụng trình soạn thảo mã để tạo ba macro thao tác văn bản Microsoft Word được liên kết (thông qua một màn hình riêng) với các phím tắt;  ví dụ: macro đầu tiên có một lệnh duy nhất

Tác giả / Người giữ bản quyền: Được phép của Christopher Scaffidi. Điều khoản bản quyền và giấy phép: Không xác định (đang chờ điều tra). Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.6 : Sử dụng trình soạn thảo mã để tạo ba macro thao tác văn bản trong Microsoft Word được liên kết (thông qua một màn hình riêng) với các phím tắt; ví dụ: macro đầu tiên có một lệnh duy nhất chỉ ra rằng ứng dụng nên chuyển đổi bất kỳ thứ gì có trên khay nhớ tạm thời của hệ thống thành một biểu diễn dạng văn bản và sau đó dán nó vào tài liệu.

10.3 Lập trình người dùng cuối (EUP)

Lập trình người dùng cuối (EUP) được định nghĩa là “lập trình để đạt được kết quả của một chương trình, thay vì chính chương trình” (Ko và cộng sự 2011). Trong EUP, mục tiêu của nhà phát triển là thực sự sử dụng chương trình; điều này trái ngược với lập trình chuyên nghiệp, trong đó mục đích là tạo ra một chương trình cho người khác sử dụng, thường để đổi lấy tiền bồi thường. Các chương trình được tạo thông qua EUP có thể là phần mở rộng của các ứng dụng hiện có (như trong Hình 6 ở trên), hoặc chúng có thể là các ứng dụng mới chạy riêng biệt với các ứng dụng hiện có. Người dùng cuối có thể thực hiện EUP thông qua một loạt các phong cách tương tác (Nardi 1993), như chúng ta sẽ thảo luận tiếp theo.

10.3.1 Lập trình sử dụng các thuộc tính trực quan

Trong các môi trường hỗ trợ phong cách tương tác lập trình trực quan, ít nhất một số ngữ nghĩa của chương trình được thể hiện thông qua bố cục trực quan của chương trình. Ví dụ, sự sắp xếp giống như lưới của các ô trong bảng tính mang một ngữ nghĩa nhất định; cụ thể, các ô được căn chỉnh theo chiều dọc hoặc chiều ngang với nhau là một phần của đối tượng tổng hợp được xác định chỉ dựa trên bố cục trực quan của các ô (ví dụ: phạm vi B: B tham chiếu đến tất cả cột thứ hai trong Microsoft Excel). Trong một ngôn ngữ hình ảnh, ngữ nghĩa có thể được mã hóa theo giả thuyết thành nhiều thuộc tính của một hình ảnh biểu diễn , chẳng hạn như vị trí, màu sắc, kích thước và giao điểm với các hình dạng khác. Như một ví dụ khác, Hình 7 cho thấy một ngôn ngữ trực quan trong đó mỗi lệnh là một khối màu có màu cho biết đó là loại lệnh gì và hình dạng của nó cho biết các khối khác có thể xuất hiện tiếp theo hoặc trước khối này. Hình 8 cho thấy một ví dụ thứ ba về ngôn ngữ hình ảnh. Cũng như nhiều ngôn ngữ trực quan, công cụ lập trình LabView cho phép người dùng kéo và thả các hình dạng này bằng GUI. Một cách phổ biến khác để tương tác thông qua ngôn ngữ hình ảnh là với một biểu mẫu (Hình 9). Trong một giao diện như vậy, người dùng không thể tự do kéo và thả các hình dạng mà phải thực hiện các lựa chọn từ các trường được xác định trước.

Giao diện trực quan để chỉnh sửa ba tập lệnh cho quả bóng trong hoạt ảnh trò chơi 'pong'.  Lập trình viên đặt các sprite ở bên phải;  nhấp vào một sprite sẽ hiển thị các tập lệnh của nó để chỉnh sửa trong t

Tác giả / Người giữ bản quyền: Không xác định (đang chờ điều tra). Điều khoản bản quyền và giấy phép: Không xác định (đang chờ điều tra). Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.7 : Giao diện trực quan để chỉnh sửa ba kịch bản cho quả bóng trong hoạt ảnh trò chơi ‘pong’. Lập trình viên đặt các sprite ở bên phải; nhấp vào một sprite sẽ hiển thị các tập lệnh của nó để chỉnh sửa ở trung tâm. Nguyên bản có thể được kéo và thả từ hộp công cụ ở bên trái. (Resnick và cộng sự 2009)

Ngôn ngữ lập trình LabVIEW để tạo mô phỏng mạch và các chương trình khác.  Mỗi hộp biểu thị một thành phần tính toán, trong khi các đường biểu thị luồng dữ liệu (tương tự như các dây mang tín hiệu)

Tác giả / Người giữ bản quyền: Được phép của Sam Shearman. Điều khoản bản quyền và giấy phép: CC-Att-SA-2 (Creative Commons Attribution-ShareAlike 2.0 Unported).

Hình 10.8 : Ngôn ngữ lập trình LabVIEW để tạo mô phỏng mạch và các chương trình khác. Mỗi hộp đại diện cho một thành phần tính toán, trong khi các đường biểu thị luồng dữ liệu (tương tự như các dây mang tín hiệu)

Giao diện người dùng trong Microsoft Word để tạo kiểu, là một tập hợp các hướng dẫn định dạng sẽ được áp dụng cho nhiều vùng được gắn nhãn trong tài liệu

Tác giả / Người giữ bản quyền: Được phép của Christopher Scaffidi. Điều khoản bản quyền và giấy phép: Không xác định (đang chờ điều tra). Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.9 : Giao diện người dùng trong Microsoft Word để tạo kiểu, là một tập hợp các hướng dẫn định dạng sẽ được áp dụng cho nhiều vùng được gắn nhãn trong tài liệu

10.3.2 Lập trình từng trình diễn (PBD)

Lập trình theo từng ví dụ (PBD), đôi khi được gọi là lập trình theo ví dụ, là một kỹ thuật lập trình theo đó người dùng thể hiện logic của chương trình mới, từ đó môi trường lập trình suy ra một chương trình đại diện cho logic đó. Một số hệ thống PBD có thể suy luận toàn bộ chương trình, trong khi những hệ thống khác suy luận những gì họ có thể và yêu cầu người dùng trợ giúp cho phần còn lại (Cypher 1993). Các công cụ dựa trên PBD có sẵn để tạo hoạt ảnh (Repenning và Perrone 2000; McDaniel và Myers 1999) và nhiều loại chương trình khác (Cypher 1993). Một vấn đề với PBD là trình bày chương trình cuối cùng ở dạng hữu ích cho người dùng (Cypher 1993; Yang và cộng sự 1997), để cho phép nhà phát triển người dùng cuối xem xét, kiểm tra, và gỡ lỗi chương trình. Do đó, PBD thường được sử dụng kết hợp với các ngôn ngữ hình ảnh hoặc văn bản.

Ví dụ: người dùng có thể tạo macro Microsoft Word (như những thứ được hiển thị trong Hình 6) thông qua PBD. Trước tiên, người dùng sẽ nhấp vào một nút hoặc mục menu cho biết rằng ứng dụng sẽ bắt đầu theo dõi các hành động của người dùng. Sau đó, người dùng sẽ sử dụng GUI để thể hiện hành vi mong muốn cho macro; ví dụ: người dùng có thể sử dụng một loạt các mục menu và cửa sổ hộp thoại để dán khay nhớ tạm của hệ thống dưới dạng văn bản. Người dùng sẽ nhấp vào nút “dừng ghi” để Microsoft Word ngừng theo dõi hành động của người dùng. Tại thời điểm đó, ứng dụng sẽ tạo một macro có chứa các hướng dẫn VBScript để lặp lại các hành động đã trình bày. Người dùng có thể đặt cho macro một phím tắt và tên, nếu muốn, để đơn giản hóa việc chạy hoặc chỉnh sửa nó sau này. Ngoài ra, người dùng có thể muốn chỉnh sửa macro ‘ s hướng dẫn để chúng thực hiện một tác vụ hơi khác so với tác vụ đã được trình diễn, đặc biệt nếu người dùng muốn macro hoàn thành một tác vụ không thể thực hiện được với GUI hiện có (thay vì chỉ khó sử dụng). Bằng cách này, người dùng có thể thêm chức năng hoàn toàn mới vào một ứng dụng, với PBD phục vụ để cung cấp điểm khởi đầu cho một cách tiếp cận lập trình khác.

10.3.3 Lập trình theo đặc điểm kỹ thuật

Lập trình theo đặc tả là một kiểu tương tác trong đó người dùng mô tả một chương trình mong muốn và sau đó một công cụ sẽ tạo ra chương trình cho người dùng. Như trong PBD, chương trình đã tạo sau đó có thể được đại diện để tạo điều kiện thuận lợi cho người dùng xem xét và tùy chỉnh. Ví dụ, Liu và Lieberman (2005) đã triển khai một hệ thống chấp nhận một đặc tả bằng ngôn ngữ tự nhiên và tạo ra một chương trình tương ứng được viết bằng Python. Một hạn chế chính của cách tiếp cận này, cũng như với các cách tiếp cận PBD dựa trên suy luận, là người dùng khó dự đoán chương trình nào sẽ được tạo từ bất kỳ đầu vào cụ thể nào. Một điều khác là, cũng như với PBD, việc đại diện có thể là một vấn đề khó khăn. Ví dụ: nếu tương tác đầu vào được thực hiện bằng tiếng Anh nhưng đầu ra là ngôn ngữ lập trình truyền thống như Python, thì người dùng cuối phải thông thạo cả hai ngôn ngữ. Một hạn chế khác là công cụ lập trình thường chỉ có thể xử lý chính xác một số đầu vào giới hạn. Điều này hạn chếtính hữu ích của công cụ và cũng khiến người dùng khó dự đoán liệu (và làm thế nào) một số đầu vào cụ thể sẽ được công cụ “hiểu” (ví dụ: liệu công cụ Liu và Lieberman được đề cập ở trên có tạo ra trò chơi hay không, và nếu có, thì những loại nào của trò chơi?) Để làm cho giới hạn của ngôn ngữ đầu vào của công cụ rõ ràng hơn với người dùng, một số hệ thống cung cấp giao diện trực quan dựa trên biểu mẫu (Hình 10) thay vì giao diện văn bản, do đó hạn chế các thông số kỹ thuật của người dùng chỉ những thông số thực sự có thể được xử lý bằng công cụ (Scaffidi và cộng sự 2009).

Đặc tả trực quan về số điện thoại trông như thế nào;  từ đặc điểm kỹ thuật này, công cụ tạo mã có thể kiểm tra xem một chuỗi cụ thể có khớp với thông số kỹ thuật hay không (Scaffidi 2009)

Tác giả / Người giữ bản quyền: Được phép của Christopher Scaffidi. Điều khoản bản quyền và giấy phép: Không xác định (đang chờ điều tra). Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.10 : Đặc tả trực quan về số điện thoại trông như thế nào; từ đặc điểm kỹ thuật này, công cụ tạo ra mã có thể kiểm tra xem một chuỗi cụ thể có khớp với thông số kỹ thuật hay không (Scaffidi 2009)

10.3.4 Lập trình với văn bản

Lập trình với văn bản là kỹ thuật tương tác truyền thống nhất để lập trình và trong một thời gian, một số người tin rằng phong cách lập trình này sẽ không phù hợp với EUP. Tuy nhiên, như các ví dụ trước đã chỉ ra, hầu hết các môi trường lập trình hỗ trợ các kiểu tương tác khác cũng bao gồm văn bản ở một mức độ nào đó. Một ví dụ khác, Hình 11 cho thấy ngôn ngữ văn bản mà công cụ CoScripter sử dụng để đại diện cho một macro web, là một tập lệnh chỉ đạo trình duyệt web điều hướng web và thao tác các trang web theo một cách cụ thể (Leshed et al 2008); một macro web như vậy thường được tạo thông qua PBD và sau đó được tùy chỉnh ở dạng văn bản nếu cần. Bất chấp sự gia tăng của các kiểu tương tác thay thế, văn bản vẫn được sử dụng rộng rãi vì tính ngắn gọn và hiệu quả để truyền đạt các khái niệm trừu tượng.

Sử dụng công cụ lập trình CoScripter để chỉnh sửa macro web yêu cầu trình duyệt tra cứu thông tin trên trang web của American Airlines.  Việc thực thi macro đã bị tạm dừng ở lệnh thứ hai

Tác giả / Chủ bản quyền: Scaffidi, Bogart, Burnett, Cypher, Myers và Shaw 2010. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.11 : Sử dụng công cụ lập trình CoScripter để chỉnh sửa macro web yêu cầu trình duyệt tra cứu thông tin trên trang web của American Airlines. Việc thực thi macro đã bị tạm dừng ở lệnh thứ hai (bên trái), lệnh này hướng dẫn CoScripter đánh dấu Số chuyến bay trên trang web (bên phải) và điền vào từ tệp cấu hình ‘Cơ sở dữ liệu cá nhân’ của người dùng (phía dưới bên trái). Scaffidi và cộng sự 2010.

10.4 Kỹ thuật phần mềm người dùng cuối (EUSE)

Kỹ thuật phần mềm người dùng cuối (EUSE) được định nghĩa là “lập trình người dùng cuối liên quan đến các hoạt động có hệ thống và kỷ luật nhằm giải quyết các vấn đề về chất lượng phần mềm” (Ko và cộng sự 2011). Chú ý đến chất lượng là điều quan trọng đối với EUP vì phần mềm được viết kém có thể gây mất dữ liệu, vi phạm bảo mật, tổn thất tài chính hoặc thậm chí tổn hại về thể chất, ngay cả khi phần mềm được tạo ra bởi các nhà phát triển người dùng cuối. Chất lượng phần mềm liên quan đến EUSE cũng giống như chất lượng phần mềm quan tâm đến các nhà phát triển chuyên nghiệp bán sản phẩm của họ. Những phẩm chất này bao gồm độ tin cậy, hiệu suất, khả năng bảo trì, khả năng tái sử dụng, quyền riêng tư và bảo mật. Một số phẩm chất, chẳng hạn như khả năng bảo trì và khả năng tái sử dụng, chỉ trở nên rõ ràng sau khi chương trình đã được viết và hoạt động một thời gian. Do đó, EUSE kết hợp mục tiêu của EUP,chất lượng của phần mềm đó trong toàn bộ vòng đời của nó . Vòng đời này bao gồm các yêu cầu, thiết kế, xác minh, gỡ lỗi và sử dụng lại mã (ngoài việc triển khai thực tế, đã được mô tả ở trên trong ngữ cảnh của các công cụ EUP).

10.4.1 Yêu cầu và thiết kế

Các yêu cầu mô tả những gì một chương trình nên làm và thiết kế đề cập đến việc xác định cách một chương trình nên thực hiện điều đó. Ví dụ, một yêu cầu có thể là một chương trình phải có khả năng sắp xếp một danh sách các địa chỉ gửi thư và thiết kế của nó có thể nêu chi tiết thuật toán sắp xếp sẽ được sử dụng.

Ví dụ về các yêu cầu (mục tiêu) trong EUD bao gồm cá nhân hóa cách ứng dụng hoặc máy tính hoạt động, tự động hóa các tác vụ tốn thời gian, thực hiện các phép tính khó thực hiện chính xác bằng tay hoặc truyền đạt thông tin (Ko và cộng sự 2011; Blackwell 2004; Blackwell 2006 ; Rosson và cộng sự 2002). Thực hiện đúng các yêu cầu này là một khía cạnh quan trọng theo quan điểm của EUSE, vì nó chú trọng đến chất lượng. Các nhà phát triển chuyên nghiệp phải điều tra, lập tài liệu và tinh chỉnh các yêu cầu trước khi họ bắt đầu thiết kế hoặc viết mã một ứng dụng. Ví dụ, họ có thể cố gắng xác định sự mâu thuẫn trong các yêu cầu bằng cách áp dụng một trong một số kỹ thuật cẩn thận (ví dụ: xem xét các bên liên quan hoặc mô hình chính thức). Ngược lại, người dùng cuối thường sống trong miền của họ hàng ngày và biết rất rõ về miền đó,

Tăng tốc sự nghiệp của bạn:
Nhận chứng chỉ khóa học được ngành công nhận

Ví dụ về chứng chỉ

  • Đóng in 6 hrs 42 mins 31 secs :

    Trở thành Nhà thiết kế UX từ Scratch

  • Đóng cửa in 4 days :

    Trải nghiệm người dùng: Hướng dẫn cho người mới bắt đầu

  • Đóng cửa in 6 days :

    Tương tác giữa người và máy tính – HCI

Tuy nhiên, đôi khi người dùng cuối không biết trước các yêu cầu và không mong muốn có một “thiết kế” theo ý mình; họ có thể mong đợi những vấn đề này được làm rõ khi việc thực hiện chương trình tiến triển (Costabile và cộng sự 2006; Fischer và Giaccardi 2006; Morch và Mehandjiev 2000; Segal 2007). (Các nhà phát triển chuyên nghiệp đôi khi cũng không biết trước các yêu cầu, nhưng họ dự kiến ​​sẽ thực hiện các bước để giải quyết tình huống đó, chẳng hạn như sử dụng một phương pháp lặp lại để điền vào các yêu cầu khi các nguyên mẫu phát triển, thay vì hoàn toàn bỏ qua khái niệm và tiếp tục. ) Trong trường hợp này, các nhà phát triển người dùng cuối có thể nhảy trực tiếp vào việc viết mã mà không cần dành thời gian để ghi lại các yêu cầu của họ hoặc tìm kiếm sự mâu thuẫn (Rosson và cộng sự 2010). Một tình huống liên quan là do sự kết hợp chặt chẽ của EUD với một miền, sự thay đổi bên ngoài trong lĩnh vực có thể gây ra sự thay đổi trong các yêu cầu; ví dụ: các thay đổi đối với các quy tắc kế toán có thể yêu cầu nhà phân tích tài chính tính toán các dữ liệu khác nhau, do đó có thể gây ra các sửa đổi đối với bảng tính hiện có. Do tính chất lặp đi lặp lại cao, việc sàng lọc các yêu cầu của EUD được ví như một hình thứclập trình nhanh (Lieberman và cộng sự 2006).

Do đó, các yêu cầu của lập trình viên người dùng cuối có xu hướng xuất hiện và đan xen chặt chẽ với thiết kế. Do đó, nhiều phương pháp thiết kế đã được nhắm mục tiêu đến các lập trình viên người dùng cuối nhằm hỗ trợ các phương pháp tiếp cận khám phá hoặc tiến hóa. DENIM là một ví dụ (bản phác thảohệ thống thiết kế trang web), cho phép người dùng để các phần của thiết kế ở trạng thái thô và mơ hồ cho đến khi phần đó được hiểu rõ hơn (Newman và cộng sự 2003). Quá trình thiết kế thăm dò cũng có thể được hỗ trợ bởi một nhà phê bình thiết kế, đây là một tính năng phần mềm có thể xem xét thiết kế của người dùng và đưa ra các đề xuất để cải thiện (Hình 12). Ví dụ, Janus là một công cụ với ngôn ngữ hình ảnh cho phép người dùng thiết kế sơ đồ mặt bằng cho ngôi nhà (Fischer và cộng sự 1990). Nó chứa một nhà phê bình thiết kế với một hệ thống chuyên gia có thể mở rộng có thể xác định các kết hợp không tối ưu của các đối tượng trong sơ đồ mặt bằng và đề xuất các bản sửa đổi để khắc phục các vấn đề thiết kế đó. Nó cũng hiển thị cơ sở lý luận cho mỗi gợi ý, để người dùng có thể suy luận về việc có nên áp dụng lời khuyên hay không và như thế nào.

Một cách tiếp cận khác dành cho các nhà phát triển người dùng cuối ít kinh nghiệm hơn để tìm kiếm đánh giá từ các đồng nghiệp có kinh nghiệm hơn. Bằng cách xác định danh sách ngắncác phương pháp hay nhất và cung cấp các công cụ thích hợp, các nhà nghiên cứu đã cố gắng làm cho đánh giá này hiệu quả nhất có thể để nó có thể được áp dụng mà không làm chậm vòng đời của EUD (Ronen và cộng sự 1989; Powell và Baker 2003; Rosson và cộng sự 2008). Cách tiếp cận như vậy dường như thành công nhất trong môi trường tổ chức, nơi các nhà phát triển người dùng cuối có các đồng nghiệp mà họ có thể kêu gọi (và nơi hệ thống phân cấp quản lý có thể được sử dụng, nếu thích hợp, để ủy thác và thực thi các đánh giá thiết kế). Một biến thể khác của ý tưởng này đã xuất hiện gần đây là thiết kế siêu mẫu, một phương pháp cộng tác theo nhóm, trong đó các nhà phát triển chuyên nghiệp xử lý một số nhiệm vụ thiết kế và các chuyên gia miền người dùng cuối xử lý các khía cạnh khác nhau (Fischer và Giaccardi 2006; Costabile et năm 2006).

Các nhà nghiên cứu cũng đã bắt đầu khám phá các phương pháp tiếp cận để điều chỉnh các kỹ thuật thiết kế kỹ thuật phần mềm hiện có cho phù hợp với bối cảnh EUD. Ví dụ, các mẫu thiết kế có thể phù hợp nhưng cần điều chỉnh để đáp ứng nhu cầu của các nhà phát triển người dùng cuối (Diaz và cộng sự 2008). Một cách tiếp cận tương đối mới khác là sự kết hợp của thiết kế / thông số kỹ thuật với khả năng xác minh, như với hệ thống Topes đã thảo luận trước đó (Scaffidi 2009).

Tổng quan về quy trình phê bình thiết kế, trong đó người dùng chỉ định thiết kế / giải pháp được đề xuất, mà tính năng phê bình thiết kế (bên phải) đánh giá dựa trên kiến ​​thức miền được mã hóa và mô hình của người dùng�

Tác giả / Chủ bản quyền: Fischer, Lemke, Mastaglio và Morch, 1990. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.12 : Tổng quan về quy trình phê bình thiết kế, trong đó người dùng chỉ định thiết kế / giải pháp được đề xuất, mà tính năng phê bình thiết kế (bên phải) đánh giá dựa trên kiến ​​thức miền được mã hóa và mô hình mục tiêu của người dùng (Fischer và cộng sự 1990)

10.4.2 Xác minh và xác nhận

Xác minh và / hoặc xác nhận (V&V) bao gồm các hoạt động cố gắng đảm bảo rằng một chương trình thực hiện những gì nó được cho là phải làm. Kiểm tra là cách tiếp cận phổ biến nhất đối với V&V (ngay cả đối với các nhà phát triển chuyên nghiệp). Một trong những hoạt động đầu tiên hỗ trợ V&V trong EUD là giúp người dùng đánh giá xem chương trình của họ có lỗi hay không bằng cách khuyến khích người dùng cuối kiểm tra một cách có chiến lược. Có lẽ thử nghiệm người dùng cuối phát triển nhấtphương pháp tiếp cận là “Những gì bạn thấy là những gì bạn kiểm tra” (WYSIWYT), hướng dẫn người dùng thực hiện quá trình kiểm tra bảng tính một cách có hệ thống (Fisher và cộng sự 2006). WYSIWYT sử dụng chiến lược “Bất ngờ-Giải thích-Phần thưởng” (Wilson và cộng sự 2003), trong đó những điều bất ngờ như đường viền màu thu hút sự chú ý của người dùng đến các khu vực của bảng tính cần thử nghiệm và các mẹo công cụ giải thích ý nghĩa của màu sắc và phần thưởng tiềm năng trong việc sử dụng các thiết bị thử nghiệm (Hình 13). Đằng sau hậu trường, WYSIWYT sử dụng tiêu chí chính thức về tính đầy đủ của thử nghiệm để suy luận về các yếu tố của công thức đã được kiểm tra cho đến nay.

Một cách tiếp cận khác để tìm lỗi trong chương trình là để công cụ lập trình tự động tìm lỗi trên cơ sở loại, kích thước hoặc đơn vị (Erwig và Burnett 2002; Abraham và Erwig 2007; Coblenz và cộng sự 2005; Chambers và Erwig 2009). Cách tiếp cận này có thể được coi là các loại khẳng định cụ thể. Ví dụ: một hệ thống liên kết các loại với các ô bảng tính (dựa trên vị trí của các nhãn ở đầu cột và ở cuối hàng bên trái) và chỉ định cách các loại này truyền qua bảng tính (Hình 14). Nếu hai ô có các loại khác nhau được kết hợp, thì loại của chúng sẽ được tổng quát hóa nếu có loại áp dụng (ví dụ: “3 quả táo + 3 quả cam = 6 quả”), nếu không, một thông báo lỗi sẽ hiển thị.

Phương pháp tiếp cận WYSIWYT, trong đó các dấu kiểm cho biết tính đúng đắn, dấu hỏi cho biết một ô cần thử nghiệm và các đường viền màu cho biết tính đúng đắn

Tác giả / Người giữ bản quyền: Burnett, Sheretof, Ren và Rothermel, 2002. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.13 : Phương pháp WYSIWYT, trong đó các dấu kiểm cho biết tính đúng đắn, dấu hỏi cho biết một ô cần thử nghiệm và các đường viền màu cho biết tính đúng đắn

Sử dụng tính năng UCheck để kiểm tra lỗi đơn vị trong bảng tính

Tác giả / Chủ bản quyền: Abraham và Erwig, 2007. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.14 : Sử dụng tính năng UCheck để kiểm tra lỗi đơn vị trong bảng tính

10.4.3 Gỡ lỗi

Sau khi lỗi lập trình được phát hiện, bước tiếp theo là loại bỏ nó bằng cách gỡ lỗi. Một số kỹ thuật gỡ lỗi được sử dụng bởi các nhà phát triển chuyên nghiệp đã được điều chỉnh để sử dụng trong các công cụ EUP. Ngoài việc chèn các câu lệnh “in” hiển thị giá trị của các biến khi chương trình thực thi, các nhà phát triển người dùng cuối có thể thực hiện từng bước một trong các hướng dẫn, để ý các thao tác sai (Leshed et al 2008). Các khẳng định đại diện cho một kỹ thuật truyền thống quan trọng khác đã được điều chỉnh để sử dụng trong EUP: người dùng có thể chèn một điều kiện vào mã và chương trình sẽ thu hút sự chú ý đến điểm đó nếu điều kiện được đánh giá là sai khi thực thi (Burnett et al 2003; Koesnandar et al. 2008; Scaffidi 2009).

Một số công cụ EUP cung cấp sự tích hợp chặt chẽ giữa kiểm tra và gỡ lỗi. Ví dụ: các xác nhận có thể được chèn một cách chủ động khi một chương trình được tạo, để thực hiện các kiểm tra tự động và bắt đầu gỡ lỗi nếu một xác nhận không thành công. Ví dụ: khi một macro web được tạo ban đầu, nó có thể hoạt động bình thường; tuy nhiên, khi thực thi sau đó, các đầu ra không hợp lệ có thể phát sinh do lỗi trong bản thân macro hoặc do những thay đổi trong cấu trúc và nội dung của trang web (đầu vào macro). Một xác nhận có thể bắt các lỗi phát sinh, tạm dừng thực thi và đưa chúng đến sự chú ý của người dùng để ngăn macro chạy không ổn định (Hình 15). Một số công cụ EUP khác hỗ trợ kỹ thuật kiểm tra, chẳng hạn như những công cụ đã đề cập ở trên, cũng tận dụng kết quả kiểm tra để tạo điều kiện gỡ lỗi. Ví dụ,

Tăng tốc sự nghiệp của bạn:
Nhận chứng chỉ khóa học được ngành công nhận

Ví dụ về chứng chỉ

  • Đóng in 6 hrs 42 mins 31 secs :

    Trở thành Nhà thiết kế UX từ Scratch

  • Đóng cửa in 4 days :

    Trải nghiệm người dùng: Hướng dẫn cho người mới bắt đầu

  • Đóng cửa in 6 days :

    Tương tác giữa người và máy tính – HCI

Một lớp công cụ gỡ lỗi mới dựa trên việc đặt câu hỏigần đây đã xuất hiện và đã được chứng minh là hiệu quả trong EUSE. Công cụ đầu tiên thực hiện cách tiếp cận này là Whyline, được tạo mẫu cho môi trường lập trình Alice cho phép người dùng lập trình hoạt ảnh (Ko và Myers 2004). Người dùng thực thi chương trình của họ và khi họ thấy một hành vi mà họ có thắc mắc, họ sẽ nhấn nút “Tại sao”. Thao tác này sẽ đưa ra một menu gồm các câu hỏi “tại sao” và “tại sao không”, được sắp xếp theo cấu trúc của các đối tượng 3D có thể nhìn thấy được thao tác bởi chương trình. Khi người dùng chọn một câu hỏi, hệ thống sẽ phân tích lịch sử thực thi của chương trình và tạo ra câu trả lời giải thích lỗi về các sự kiện đã xảy ra trong quá trình thực thi. Phương pháp Whyline cũng đã được áp dụng để gỡ lỗi các loại chương trình khác (ví dụ: Ko và Myers 2008; Kulesza và cộng sự 2009).

Cửa sổ bật lên yêu cầu người dùng cho biết liệu macro web Robofox nên được sửa đổi như thế nào do xác nhận bị vi phạm

Tác giả / Chủ bản quyền: Koesnandar, Elbaum, Rothermel, Hochstein, Scaffidi và Stolee. Điều khoản bản quyền và giấy phép: Mọi quyền được bảo lưu. Sao chép với sự cho phép. Xem phần “Ngoại lệ” trong điều khoản bản quyền bên dưới.

Hình 10.15 : Cửa sổ bật lên yêu cầu người dùng cho biết có nên sửa đổi macro web Robofox hay không do xác nhận bị vi phạm

10.4.4 Tái sử dụng

Sau khi mã được viết, việc sử dụng lại có thể tăng tốc độ tạo các chương trình sau này. Việc hỗ trợ tái sử dụng các chương trình dành cho người dùng cuối là một thách thức vì các nhà phát triển người dùng cuối hiếm khi có cơ hội hoặc được đào tạo cần thiết để thiết kế các chương trình có khả năng tái sử dụng cao. Một thách thức khác là các nhà phát triển người dùng cuối có thể mắc lỗi khi tạo chương trình hoặc các tệp khác để điều chỉnh ứng dụng và việc sử dụng lại chúng có thể gây ra lỗi trong toàn tổ chức (Mackay 1990). Do đó, mặc dù các hệ thống như kho lưu trữ hoặc máy chủ tệp có thể giúp nhà phát triển người dùng cuối dễ dàng đăng chương trình để người khác sử dụng lại, nhưng việc đánh giá khả năng tái sử dụng của các chương trình này có thể cực kỳ khó khăn và tốn thời gian đối với các nhà phát triển khác. Để giúp giảm bớt khó khăn khi sử dụng lại các chương trình, mô hình làm cho các chương trình người dùng cuối có thể tái sử dụng hiện đang được phát triển với hy vọng giúp người dùng tìm kiếm kho lưu trữ các chương trình có thể tái sử dụng liên quan đến sở thích cụ thể của người dùng (Scaffidi et al 2010). Bên ngoài kho lưu trữ, các công việc khác đã bắt đầu khám phá cách giúp người dùng trích xuất các phần có thể tái sử dụng (Oney và Myers 2009).

10.5 Tương lai và tác động của EUD

Khi người dùng tiếp tục phát triển về số lượng và sự đa dạng, EUD có thể sẽ ngày càng đóng vai trò trung tâm trong việc định hình phần mềm để đáp ứng nhu cầu rộng lớn, đa dạng và thay đổi nhanh chóng của thế giới. Đồng thời, cần có những nghiên cứu sâu hơn để giúp các nhà phát triển người dùng cuối tạo và điều chỉnh các loại chương trình mới theo những cách mới. Ví dụ, khi kỷ nguyên Web 2.0 mở ra, các nhà nghiên cứu đang nghiên cứu những cách mới giúp người dùng tự động hóa việc tổng hợp dữ liệu từ nhiều trang web thông qua các macro web và các bản mashup (Scaffidi và cộng sự 2008; Zang và cộng sự 2008). Một sự thay đổi đang diễn ra khác là vai trò ngày càng gia tăng nhanh chóng của các máy tính di động nhỏ, chẳng hạn như điện thoại thông minh; Công việc gần đây đã bắt đầu cho phép người dùng cuối tạo “ứng dụng” hoặc các chương trình khác cho các thiết bị này (Google App Inventor 2010).

Với việc liên tục mở rộng phạm vi và sức mạnh của lập trình người dùng cuối, sự quan tâm bổ sung đáng kể đến chất lượng sẽ ngày càng trở nên quan trọng. Đặc biệt, khi người dùng tiếp tục tương tác với số lượng lớn hơn những người ngang hàng ẩn danh (ví dụ: thông qua mạng xã hội hoặc “cửa hàng ứng dụng”), mã của họ có thể hiển thị nhiều hơn với những người khác và do đó dễ bị tấn công hơn. Hơn nữa, vì người dùng hiện có thể chia sẻ chương trình của họ với bất kỳ người nào trên web, nên nhiều người hơn có thể bị ảnh hưởng bởi lỗi trong mã của lập trình viên người dùng cuối. Do đó, cần nghiên cứu thêm để giúp các nhà phát triển người dùng cuối sản xuất phần mềm với sự đảm bảo mạnh mẽ hơn về bảo mật và quyền riêng tư, mà không ảnh hưởng đến tính chất nhẹ, lặp đi lặp lại của vòng đời EUD. Hơn nữa, khi lượng lớn dữ liệu trở nên có thể truy cập đượcthông qua web cho người dùng, họ có thể cần được hỗ trợ tốt hơn để thiết kế và triển khai các chương trình với khả năng mở rộng tăng lên. Các nhà nghiên cứu sẽ cần phát triển các phương pháp tiếp cận mới, vì các phương pháp tiếp cận được sử dụng bởi các nhà phát triển phần mềm chuyên nghiệp, chẳng hạn như phân tích tràn bộ đệm để bảo mật hoặc phân tích Big-O cho hiệu suất, có thể không liên quan hoặc quá phức tạp đối với nhu cầu của các lập trình viên người dùng cuối.

Nói rộng hơn, sự phát triển liên tục của EUD như một hiện tượng xã hội có ý nghĩa quan trọng đối với mối quan hệ giữa người dùng cuối và các nhà phát triển phần mềm chuyên nghiệp (Fischer và Giaccardi 2006, Costabile et al 2006). Sự nổi lên của EUD cho đến nay cho phép người dùng cuối đáp ứng các công việc phần mềm tồn đọng của các nhà phát triển chuyên nghiệp và thực tế là các nhà phát triển phần mềm chuyên nghiệp không có khả năng hiểu và lập kế hoạch cho mọi yêu cầu của người dùng khi phát triển phần mềm. Với những tiến bộ không ngừng trong EUSE, người dùng cuối sẽ không chỉ có thể tự mình tạo ra nhiều loại phần mềm mà còn có thể tự mình đánh giá và cải thiện chất lượng của phần mềm đó — để họ biết mình phải dựa vào mức độ nào và những việc cần làm để tăng chất lượng phần mềm nếu cần. Kết quả là, sự phù hợp giữa các phần mềm ‘

Start typing and press Enter to search

Shopping Cart