使用Delphi.NET开发UsingDelphiforMicrosoft.NETFramework.pptVIP

杀不死的人狼——我读《人月神话》 《人月神话》 人狼之杀不死 广义工程与狭义工程 《人月神话》这本书 《人月神话》的组织结构说明了什么？ 请注意下列关键词 项目 程序(编码)－复杂性 团队－方向、决策 沟通 需求 工具 管理－回顾、控制 文档化 《大道至简》的组织结构 这说明了什么问题？ 几十年来，我们的问题域与我们感受问题的过程有过丝毫的变化？ 我们在重复着错误 我们探索的脚步从未停止 工程问题并没有因为业界的喧嚣与鼓躁而发生任何实质性的变化 现象与本质 现象：街口的乞丐向我伸出手来 方法：我给了他十元钞票 结论：我给出了解决了他伸手(这个问题)的答案 《人月神话》中的现象与本质 14项本质问题(例举) 概念不完整＝定义不明确＝无法实施 私利性是本质问题 项目经理的基本职责是使每个人向着相同的方向前进 程序＝用户认识＋机器认识 有答案并不见得就正确 预言是一种假象 他做出了正确的判断 你主观地跟从了他对未来的设定 《人月神话》对本质设定的显性问题 目标的本质：是大型工程，是系统项目，而不是程序 工程的挑战 思与行－如何思想，与如何做事 人狼杀不死 vs 杀不死人狼 杀不死人狼 工程界几十年来讨论的问题总是 我们为什么杀不死人狼，或 用什么方法可以杀死人狼 不正确的命题 命题设错了，就成了问题了 人狼的定义 解的定义与约束 解的定义 提出对“软件活动的根本任务(抽象软件构成的复杂概念结构)”的普适性解决方法 问题 三点质疑 用确定抽象方法描述(复杂系统的)不同侧面 它是解决问题的方法上的一项描述，而非对问题本质的一项设定 这种解决问题方法的约定是否合理？ 结论 (*)学术的设定不是某个具体工程的必须 没有人狼从广义工程到狭义工程 本质与本质需求 本质不变 我们之于本质与盲人之于大象无异。在大多数时候，我们都只是“看”到本质的一个或几个侧面，而非本质本身 我们各自在本质的不同侧面，围绕自己所视见的那些“完全无误”，但“并不全面”的观点而争论 我们以为这是本质，但我得为他加上引号 广义工程与狭义工程 广义工程 面向“软件活动的根本任务” 程序实现的过程无助于求解根本任务 狭义工程的解 分歧并非坏事 能将事物一分为二，是由混沌未解走向清晰的必然过程。分歧并非坏事。 实践者的思想 具体的、狭义的工程实践活动 面向工程的本质需求 确定具体工程的具体目标 灵活和切实的实践观念 坚持：决策的前提与背景不变，决策不变 置疑：任何看起来完美的东西都一定有问题 开放：接受任何观点，知其所用 * 周爱民Aimingoo 没有银弹及其它 16～20 项目管理 13～15 项目-需求可变性 11 程序-工程 1 编码 8～10 工具 12 团队管理 3～7 内容 章 项目 2 基本定义与核心观点 实现 工程 团队建设及基本问题 两个仍未足够重视的问题 通过设计来获得系统的一致性 更好的文档 本质1：伸手的本质－饥饿 本质2：饥饿的本质－贫穷(或者懒惰) 本质3：贫穷的本质－国家、社会、阶级、制度 给出问题的答案，不见得触及问题的本质 本质 答案 现象 7% 31% 62% 统计 预言成真的本质 预言家看到了问题的本质 预言失败的本质 答案解决了问题，但远离本质 答案与问题及其本质背道而驰 个体的本质：是私利性的 目标系统不可改善：目标系统在工程之外？或在工程之内？ 思想的思想：？ 思想的方法：《人月神话》 做事的思想：《大道至简》 做事的方法：《移山之道》 做事没有思想也没有方法 Bug会从屏幕上跳出来 问题的本质是什么？ 能力问题？ 方法问题？ 你认为这是个问题，它就是个问题(温伯格) 针对于大型的、复杂的、面向根本任务的工程目标 用确定抽象方法描述(复杂系统的)不同侧面 不可丢弃的历史包袱 极端的复杂性 需求的持续变更 约束 独立的解决方案(社会性、商业性等等排除) 构建独立小型程序的数据不适用于编程系统产品 我们是否总是面临问题的全集？ 为什么需要独立解决方案？ 什么样的数据适用于系统产品？ 普适性解决方法——独立的解决方案 纯质银弹是唯一解吗？ 我们的目标是人狼，还是方案的独立性？ 构建独立小型程序的数据不适用于编程系统产品 应当承认复杂度的可分解性 如果承认人狼之存在，那么： 必然要承认“人狼杀不死”，因为Brooks所设的问题与检测方法是学术范畴的命题。 (*)具体工程的目标并不面向根本任务 所以， 问题的根本，并不在于“我们能否杀死人狼”，而在于“人狼原本就杀不死”。或， Brooks的要求的方法不是最终解的形态。 我们所能视见的“本质”具有不确定性。但工程的“本质需求”却是确定的： 实现(工程的目标) 狭义工程 面向“具体工程活动的需求” ：实现 求解“根本任务”(的探索活动)只是实现过程或其结果的附加价值 ……