谁在研究功能和可用性的衡量?

发布于 2024-09-18 22:05:40 字数 1179 浏览 2 评论 0原文

我正在寻求指导来帮助我的研究方向,以提供系统开发中的功能、可用性或优雅性的评估。

您能否提供有关功能、可用性或编码风格衡量工作的参考资料?谁(个人/组织)在该领域开展工作?我在哪里可以找到这样的参考资料。

我提出了一些关于系统构建的想法,与主流开发略有不同。出发点是对问题的充分描述。我正在开发一个演示/概念验证项目。

在开发我的概念验证项目时,我发现了意想不到的好处。到目前为止,我发现可以通过间接查看开发来收集有关系统完整性的有用信息。这种间接的观点是基于问题的描述,而不是软件解决方案。

由于这些发展,我也确信我的方法很可能为其他领域的系统开发提供指导,例如系统功能的指导;系统的可用性如何;或者解决方案有多优雅。

到目前为止,我的探索得出了以下建议,以及我对这些建议的回应:

  1. 文学编程是优雅的。 - 识字编程很可能很优雅,但这又将问题转移回来 - 如何评估程序的识字程度?
  2. 我正在寻找相当于美学衡量标准的系统开发,即不可言喻的——虽然我意识到这是不可能的,但我仍然相信在开发系统的过程中可以从可用的信息中提供指导。
  3. 我所寻求的只能在解决方案使用一段时间后才能评估,并且只能通过与同一问题的其他解决方案进行比较来评估。 - 情况很可能就是这样,而且可能确实是我的搜索失败的基石。然而,我仍然相信,开发中的措施可能会对软件的这些方面产生一些启发式的见解。
  4. 功能点分析是对功能的衡量——我认为 FPA 更多的是对生产力的衡量,而不是对功能的衡量。它不会告诉您系统中已合并了多少功能,而是与源自相同上下文的基线相比已包含了多少功能。随着环境的不断发展,这会降低该措施的实用性。
  5. 这些概念无法衡量,并且对于功能性、可用性或优雅的构成没有达成一致,并且不可能出于与论证类似的原因 - 我很顽固地相信我可以,至少部分地反驳这个建议为系统开发人员提供一些帮助。
  6. 我正在寻找的信息位于系统开发之外;在图形艺术领域;心理学;生物学;或其他 - 这看起来越来越有可能。
  7. 直接利用系统的对象作为其用户界面——这表明了一类旨在促进问题解决的系统的前景。
  8. 传统图形艺术(复杂数据的布局)的经验教训可以转移到系统开发中 - 这看起来是最有前途的路线,我正在尝试与领先的图形设计师建立联系。这可能只适用于信息系统,但看起来它的范围确实比这要广泛得多。
  9. 也有人认为我是一名“建筑宇航员”,与现实脱节——情况可能是这样,但如果是这样,那么我很可能是最后一个意识到这一点的人,这样的前景并不存在阻止我的搜索。

I am seeking pointers to assist the direction of my research into providing assessements of functionality, usability or elegance in system development.

Can you provide references to work being done on the measurement of functionality, usability, or coding style? Who (person/organisation) is doing work in this area? Where can I find such references.

I have developed some ideas about system construction, that are a little different to mainstream development. The starting point is a an adequate description of the problem. I am developing a demonstration/proof of concept project.

In developing my proof of concept project I have found an unexpected and unlooked for benefit. So far, I have found that useful information about the completeness of a system can be gathered by taking an indirect view of the development. This indirect view is based on the description of the problem, rather than the software solution.

I have also become convinced as a result of these developments that it may well be possible to provide guidance from my approach to system development in other areas such as guidance on how functional the system is; how usable the system is; or how elegant the solution is.

My explorations so far have led to the following suggestions, and my responses to them:

  1. Literate programming is elegant. - Literate programming may well be elegant, but this shifts the problem back - how do you assess how literate a program is?
  2. That I am looking for the system development equivalent of a measure of aesthetics ie the ineffable - while I appreciate that such is not possible, I still believe it possible to give guidelines from the infomation available during the course of developing a system.
  3. That what I am seeking can only be assessed after a solution has been in use for some time, and only by comparison with other solutions to the same problem. - This may well be the case, and may indeed the rock on which my search founders. However I still believe that it is possible that measures from the development may throw some heuristic insight on these aspects of software.
  4. Function point analysis is a measure of functionality - I see FPA as more a measure of productivity than functionality. It does not tell you how much functionality has been incorporated into the system, bur rather how much has been included compared to a baseline derived from the same context. As the context is continually evolving, this detracts from the measure's usefulness.
  5. That these concepts cannot be measured and there is no agreement on what constitutes functionality, usability, or elegance and there can't be for similar reasons to the argument - I am stubborn enough to believe I can, at least partially, refute this suggestion by providing some assistance to system developers.
  6. That the information I am looking for lies outside of system development; in the graphic arts arena; psychology; biology; or other - this is looking more and more likely.
  7. Utilising the objects of the system directly as its user interface - this shows promise for a class of systems designed to facilitate problem solving.
  8. The lessons from traditional graphic art (layout of complex data) can be transferred to system development - this is looking like the most promising route and I am trying to establish correspondance with a leading graphic designer. This may only be of use for informational systems but does look as if it is much more wide ranging than that.
  9. It has also been suggested that I am being an "architecture astronaut", out of touch with reality - this may be the case, but if it is so, then I am likely to be the last to realise it and such a prospect does not deter me from my search.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

草莓酥 2024-09-25 22:05:40

在您列出的三件事中,可用性是最可衡量的。搜索“测量代码可用性”将会产生很多点击,涉及从网站到并行编程的所有内容。

一些亮点:

软件工程的 ISO 标准;在这里您可以找到产品质量和软件开发生命周期的标准:
http://www.iso.org/iso/iso_catalogue/catalogue_tc /catalogue_tc_browse.htm?commid=45086

ISO 标准的 Cliff Notes 版本 :)
http://www.usabilitynet.org/tools/r_international.htm

软件人体工程学标准:
http://www.iso.org/iso/catalogue_detail.htm?csnumber=52712

从一篇关于并行程序可用性的写得很好的论文中,找到 此处

PPS 的几个特性决定了它的可用性。之中
这些是:
1) 学习曲线:专家或缺乏经验的并行程序员需要多长时间
能够高效地使用 PPS?请注意,某些 PPS 专门解决了这些需求
有的针对专家,有的则针对新手;很少有人同时适合两者。
2)编程错误:有些系统限制并行性的使用以防止错误(例如
企业)。其他系统,例如 NMP 和 PVM,允许用户做任何事情,交易
灵活性,以减少编程错误的可能性。通常发生错误的可能性是
与用户代码的行数直接相关。因此,需要更多的系统
用户代码可能更容易出错。
3)确定性性能:非确定性,常见于某些实现
算法和某些 PPS 中固有的,可以显着增加
应用程序调试。
4)与现有软件的兼容性:遗留软件不容忽视。理想情况下,
PPS 必须支持以最小的努力集成现有软件。
5) 与其他工具集成:PPS 应该附带或提供对以下工具的访问:
全套软件开发工具,包括调试、监控设施
和绩效评估。

一篇关于量化和测量功能的文章:
http://www.computer.org/portal/web/csdl /doi/10.1109/METRIC.1999.809732

链接到 CUE-4 宾夕法尼亚酒店可用性研究,其中 17 个独立团队对宾夕法尼亚酒店网站进行了可用性研究
http://www.dialogdesign.dk/CUE-4.htm

这篇 Wikipedia 文章 有很多与软件质量相关的文章的链接。文章本身讨论了软件质量的许多焦点,包括可理解性、简洁性、一致性、可维护性、可测试性、可用性、可靠性和效率等。

http://www.drdobbs.com/windows/184405654;​​jsessionid=SB2LUABORKQHBQE1GHOSKHWATMY32JVN
作者讨论了 Microsoft 用于设计和评估其 API 可用性的技术。

另一个建议:去一些比较知名的软件工程学院,在他们的计算机科学主页上查找有关该主题的已发表文章。

正如其他人所说,根据这些原理建立定量测量就像将果冻钉在树上......但我不同意它们不能或尚未在可量化分析中进行研究。

哈!
詹姆斯

Of the three things you list, usability is the most measurable. Doing a search for "measuring code usability" will yield many hits, for everything from websites to parallel programming.

Some highlights:

ISO standards on software engineering; Here you'll find the standards for product quality and the software development lifecycle:
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.htm?commid=45086

The Cliff Notes version of the ISO standards : )
http://www.usabilitynet.org/tools/r_international.htm

Standards for software ergonomics:
http://www.iso.org/iso/catalogue_detail.htm?csnumber=52712

From a well-written paper on parallel program usability, found here:

Several features of a PPS determine its usability. Among
these are:
1) Learning curve: How long does it take an expert or an inexperienced parallel programmer
to be able to use the PPS productively? Note that some PPSs specifically address the needs
of experts, while others are targeted at novices; few are suitable for both.
2) Programming errors: Some systems restrict the use of parallelism to prevent errors (e.g.
Enterprise). Other systems, such as NMP and PVM, allow the user to do anything, trading
flexibility for a higher chance of programming errors. Usually the potential for errors is
directly related to the number of lines of user code. Therefore, systems that require more
user code may be more susceptible to errors.
3) Deterministic performance: Non-determinism, common in the implementation of some
algorithms and inherent in some PPSs, can significantly increase the overhead in
application debugging.
4) Compatibility with existing software: Legacy software cannot be ignored. Ideally, the
PPS must support the integration of existing software with minimal effort.
5) Integration with other tools: A PPS should either come with, or provide access to, a
complete suite of software development tools including facilities for debugging, monitoring
and performance evaluation.

An article on quantifying and measuring functionality:
http://www.computer.org/portal/web/csdl/doi/10.1109/METRIC.1999.809732

Links to the CUE-4 Hotel Pennsylvania usability studies, where 17 independent teams performed usability of the website for Hotel Pennsylvania
http://www.dialogdesign.dk/CUE-4.htm

This Wikipedia article has a lot of links to software-quality-related articles. The article itself discusses a number of focal points for software quality, including Understandability, Conciseness, Consistency, Maintainability, Testability, Usability, Reliability, and Efficiency, among others.

http://www.drdobbs.com/windows/184405654;jsessionid=SB2LUABORKQHBQE1GHOSKHWATMY32JVN
The author discusses techniques that Microsoft uses to design and evaluate the usability of their APIs.

Another suggestion: Go to some of the more renowned colleges for software engineering and nose around on their Computer Science homepage for published articles on the subject.

As others have said, establishing quantitative measurements on these principles is like nailing jello to a tree... but I disagree that they can't or haven't been studied in quantifiable analyses.

HTH!
James

寄居人 2024-09-25 22:05:40

我认为,与另一个类似的实现相比,其中一些功能必须在产品使用相当长一段时间后进行测量。

考虑一个软件的多个 GUI 实现的示例。您可以测量用户使用一种特定实现完成某项任务所需的时间,以及使用不同 GUI 实现在(几乎)同一软件上完成相同任务(第 n 次)所需的时间。这将提供某种相对而言有用的度量。

沿着这条道路走下去可能会帮助您在获得(可发布?)结果方面阐明这些想法。从阅读您的原始描述来看,听起来您正在寻找绝对指标而不是相对指标。然而,通过快速浏览这个问题并尝试在工作休息五分钟的时间里提出一个有趣、有用的答案,相对指标是我能想到的最好的。

我希望这会有所帮助,

布莱恩·J·斯蒂纳尔

I think some of these features would have to be measured after the product has been in use for quite some time, as compared to another, similar implementation.

Consider the example of multiple GUI implementations for a piece of software. You could measure things like how long it took a user to accomplish a certain task using one specific implementation relative to accomplishing the same task (for the nth time) on the (almost) same piece of software using different GUI implementation. This would provide for some sort of a useful metric in relative terms.

Going along this path might help you clarify these ideas in terms of getting (publishable?) results. From reading your original description, it sounds like you are looking for absolute rather than relative metrics. However, from quickly looking over this question and trying to come up with an interesting, useful, reply during a five minute break from my work, the relative metric was the best I could come up with.

I hope this helps,

Brian J. Stinar

离线来电— 2024-09-25 22:05:40

所有这些概念都无法衡量。他们甚至无法客观地达成一致。

我敢说它们在物质世界中没有明确的解释。它们只存在于人类的头脑中。每个人都会根据他们的生活经历、知识、经验和对问题领域的态度、工程、艺术和人际能力的发展来感知和衡量这些。即使你可以强迫某些人“测量”它,这也将是非常主观的。

你如何定义美与爱、欢乐与悲伤?可用性和效率与这些有很大关系。

有些想法可以来自心理学研究。但只有一些想法。最好的情况是,您可以应用这些知识来尝试在用户的脑海中引起一些特定的反应。但它可能有效,也可能无效。

当您无法准确了解用户的响应模型时,您就无法规划具体的响应。因此,您无法测量程序的特定特征的程度。所以你一开始就无法定义比例。

All of those concepts cannot be measured. They can't even be objectively agreed upon.

I dare to say they have no clear interpretation in the physical world. They only exist in human mind. Every other person will perceive and measure those in accordance with their life experience, knowledge, experience and attitude to the problem field, development of engineering, artistic and interpersonal abilities. Evey if you can force some individuals to "measure" it, it will be highly subjective.

How do you define beauty and love, joy and sadness? Usability and efficiency will have much to do with those.

Some ideas can come from psychological studies. But only a few ideas. At best you can apply this knowledge to try to evoke some specific response in the users' minds. But it might work or it might not.

When you can't understand precisely the model of response of the users, you can't plan for specific response. Consequently, you can't measure the degree of a particular characteristic of your program. So you can't define the scale in the first place.

难如初 2024-09-25 22:05:40

我正在回答我自己的问题,以表明我在获得原始问题的答案方面已经取得了多大的进展。显然,任何与优雅相关的概念的度量都将具有以下特征:

  1. 它们可能是启发式的
  2. 它们可能必须基于开发过程的多次迭代
  3. 它们可能是相对的而不是绝对的
  4. 除了需要系统开发本身的信息之外,它们可能基于软件/系统开发以外的研究领域。可能的领域的例子有美学、心理学、神经语言学和神经美学;
  5. 如果我正在做的工作对软件开发人员有任何价值,那么它就不能基于复杂的数学或统计模型,而必须根据他们的工作以及其他开发人员的工作提供指导。
  6. 任何指南都可能基于以下问题的答案:
    • 对象、属性、数据类型的出现频率是多少?
    • 这个频率与其他项目相比如何?
    • 此衡量标准对于帮助开发人员评估其项目/查看改进空间是否有任何价值?

我仍在寻找有关该领域正在进行的工作的参考资料。

I am answering my own question to give an indication of how far I have got in obtaining an answer to my original question. It is apparent that any metrication of concepts related to elegance will share the following characteristics:

  1. they are likely to be heuristic
  2. they are likely to have to be based on multiple iterations of the development process
  3. they are likely to be relative rather than absolute
  4. they are likely to be based on areas of study other than software/system development, in addition to needing information from the system development itself. Examples of possible domains are aesthetics, psychology, neurolinguistics and neuroaesthetics;
  5. If the work I am doing is to be of any value to software developers, it must not be based on complex, mathematical or statistical models, but must offer guidelines based on their work, and work by other developers.
  6. Any guidelines are likely to be based on the answers to questions like:
    • What is the frequency of objects, attributes, data types?
    • How does this frequency compare with other projects?
    • Is this measure of any value in aiding the developer to evaluate his project/see room for improvement?

I am still seeking references to work being done in this arena.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文