Man-Computer Symbiosis
201250035 邓尤亮
2023.10.05
0. Source
Source
Man-Computer Symbiosis (mit.edu)
J.C.R. Licklider. Man-Computer Symbiosis. IRE Transactions on Human Factors in Electronics, Vol HFE-1(1): 4-11, 1960.
1.引言
Man-Computer Symbiosis: 是指人与计算机之间的合作共生, 是人机系统的一个子类. 其在未来科技发展中具有重要意义. 作者希望未来人脑与计算机能够紧密结合在一起, 并以该伙伴关系来进行思考与处理数据.
人机共生与 “机械延申的人”有着很大不同. 后者仅是人体的延申, 两者并非相互依存.
2.人机交互的主要目标
在 60 年代, 计算机主要用于解决预先指定的问题, 或根据预定程序处理数据. “问题是什么” 往往比答案更加重要. 因此, 人机共生旨在
- 找到解决方案中的问题
- 需要进行 “实时” 的计算 (当时传统计算机需要过长的计算时间, 而这有可能会导致效率低下)
3.为什么公式化和实时计算需要计算机参与
- 通过实验记录工作思考内容, 作者发现大部分时间都是机械性地活动, 比如记录, 画图, 计算, 而这些机械性操作由机器来执行会更加有效.
- 人类和计算机的比较:
- 人类灵活, 可以并行思考, 使用自然语言;
- 计算机快速准确, 预先编程, 程式化语言;
- 因此, 两者如果能够相结合并共生合作, 将会产生巨大的价值.
4.如果人机共生, 人机该怎么分工
- 在某些操作中，人类操作员和计算机的贡献会完全融合在一起，难以在分析中清晰地分开。
- 在其他操作中，人类和设备的贡献是可以分离的。人类负责设定目标、提供动机、制定假设、提出问题、考虑机制、程序和模型，以及填补问题解决方案或计算机程序中的空白。
- 机器的角色包括将假设转化为可测试的模型，测试这些模型，回答问题，模拟机制和模型，执行程序，转化数据，绘制图表，插值、外推和转化数据，以及将静态方程或逻辑语句转化为动态模型。它还可以作为统计推断、决策理论或博弈理论机器，对建议的行动方案进行基本评估，以及进行诊断、模式匹配和识别相关性。
5.人机共生的先决条件
5.1 人机两者思考速度的协调
大型计算机速度过快，不适合与一个人进行实时的协作思考。为了提高效率和节省成本，计算机必须在多个用户之间分配时间。因此需要开发时分系统. 作者预想未来将会出现 “思维中心” 通过网络给众多个人用户提供检索和计算能力.
5.2 内存硬件的要求
将大量技术文献存储在计算机内存中需要大量的存储空间和成本。不可能存储所有技术和科学论文，只能存储其中一部分，如定量部分和参考文献引用部分。
现在来看, 随着外部存储设备的进步, 存储巨量数据不再是问题.
5.3 数据结构的要求
人机共生要求信息可以通过名称和模式检索，而且检索速度要比串行搜索快得多。存储结构和模式识别是存储组织中的关键问题之一。
作者举例 “Trie Memory” 作为检索信息的数据结构.
5.4 语言问题
自然语言与机器语言差别很大
5.5 输入输出
与人机共生的要求相比，数据输入和输出设备方面的工程进展相对较少。为了实现真正的人机互动，需要开发更灵活、方便的输入输出设备，使人和计算机可以在同一显示屏上进行图形绘制、笔记和方程式编写等操作。
语音通信是否可行和可取，取决于识别的词汇量和与之一起工作的发音者和口音的多样性。对于实时互动，可能需要一个包括大约 2000 个词汇的词汇表，这是一个具有挑战性的问题。虽然现在还不能完成，但有一些组织愿意在五年内开发出这样的识别器。
AI 技术的发展, 让多模态的人机交互成为现实. 如今我们可以通过键盘输入文字, 手写图画, 语音, 视频等模态与计算机交互.
6.总结
作者在 60 年代计算机发展的初步时期, 探讨了人机共生这一前卫的概念, 畅想计算机与人类深度合作所带来的场景. 从现在的眼光来看, 作者所提到的挑战现在都已不再是问题, 人工智能的发展也让人机共生成为平常现实.
CMMI
- 刻画了软件团队/组织从不成熟到成熟的每个阶段的特征 (也就是 roadmap)
- 等级 2 和等级 3 关注的是当前状态
- 等级 4 和等级 5 是根据结果 (未来) 来进行管理
等级一：初始级
开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行
- 软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。
- 由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务，项目实施是否成功主要取决于实施人员。
等级二：已管理级
项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等。
- 软件组织对项目有一系列管理程序，避免了软件组织完成任务的随机性，保证了软件组织实施项目的成功率。
- 软件组织在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对项目相关的实施人员进行相应的培训，对整个流程进行监测与控制，并联合上级单位对项目与流程进行审查。
- 从 2 级升级到 3 级的原因：固化最佳实践，对小组而言是能够更快地学习其他的做法。
等级三：已定义级
公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司内分享。
- 软件组织能够根据自己的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。
- 软件组织不仅能够在同类项目上成功，也可以在其他项目上成功。
- 科学管理成为软件组织的一种文化，成为软件组织的财富。
等级四：定量管理级
构建预测模型，以统计过程控制的手段来管理过程
- 软件组织的项目管理实现了数字化。
- 通过数字化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
- 在这个级别我们希望能够看到一个预测模型。
等级五：优化级
继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题
- 软件组织能够充分利用信息资料，对软件项目在项目实施的过程中可能出现的次品予以预防。
- 能够主动地改善流程，运用新技术，实现流程的优化。
一些理解
- CMM/CMMI 不适用于软件开发的原因
- CMM/CMMI 并不是一种具体的软件过程或者软件开发方法
- CMM/CMMI 建立了一组有效地描述成熟软件组织特征的准则。
- CMMI 是过程改进模型而非软件过程或者软件过程模型：CMMI 指导软件过程改进，不指导开发。
- 按照 CMM/CMMI 模型的要求，一个软件组织应当定义使用本软件组织特点的软件过程，并且不断优化该过程，来更好地实现软件组织的商业目标。
- CMM/CMMI 并不能作为检验软件过程优劣的标准：过程改进对不同企业的含义不一样，成熟度等级无法脱离企业环境直接横向比较。
- CMM/CMMI 与其他软件过程或者软件开发方法的比较是没有任何意义的。
- CMM/CMMI 并不是一种具体的软件过程或者软件开发方法
- 一些误解：
- CMMI 模型需要适当裁剪以适应公司的实际情况：需要裁剪的是公司内部定义的组织级开发流程和开发规范。
- CMMI 模型太重了，不适合互联网时代的轻量级开发：这个说法的错误之处在于，不一定是 CMMI 重或者轻，而是，CMMI 根本就不是开发模型。
- CMMI 模型只适合大公司、大项目，不适合小项目：首先没人检验过；其次，项目的大小衡量本身也缺乏值得信赖的参考依据；最后，接受这种说法的人还是把 CMMI 当成是一种特殊的开发模型。
- CMMI 模型只适合需求不变或者很少变化的场合，不适合需求不确定，变化很多的场合：CMMI 不是开发模型，与需求变化与否无关，谈不上适应或者不适应。
- CMMI 不是过程优劣的标准，也不适合用作公司之间的能力比较，说法怎么样？对的，CMMI 本身是有评级。（美国国防部订单招标要求企业至少达到 CMMI 的 3 级。因为公司的能力需要绝对东西，也就是能力强，能力弱，而 CMMI 衡量的是相对的水平，CMMI 仅仅关注在本公司的目标下的等级
- 更多讨论：试论 CMM/CMMI 不适合在当前软件开发当中应用的原因
考试题
- 【2020-mid】请描述 CMMI 模型的 5 个等级的特征，并且解释为何 CMMI 模型不应该是敏捷方法的对立面：
- 五个等级的特征
- Initial 原始级别：开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行
- Managed 已管理级别：项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等
- Defined 已定义级别：公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司共享。
- Quantitatively Managed 定量管理级别：构建预测模型，已统计过程控制的手段来管理过程
- Optimizing 优化级：继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题。
- 原因解释：
- CMMI 是过程改进模型，刻画了软件组织从不成熟到成熟的路线图。
- 大部分敏捷方法都是开发方法
- 因此两者是完全不同性质的事物，将两者对立是不合适的。
- 五个等级的特征
