在介绍GROUP BY 和 HAVING 子句前，我们必需先讲讲sql语言中一种特殊的函数：聚合函数，例如SUM, COUNT, MAX, AVG等。这些函数和其它函数的根本区别就是它们一般作用在多条记录上。 SELECT SUM(population) FROM bbc 这里的SUM作用在所有返回记录的population字段上，结果就是该查询只返回一个结果，即所有国家的总人口数。 通过使用... Read More
需求优先级主要是针对功能需求而言的，除却被依赖的需求应当优先实现之外，需求优先级主要反映了客户希望最终系统提供某功能需求的迫切程度。一般而言，需求优先级可以分为三级： 高优先级。必不可少的功能。只有在这些需求上达成一致意见，软件才可能被接受。这些功能的实现质量必须趋于完美； 中优先级。必要的功能。这些功能是系统所需要的，如果有必要可以延迟实现。虽然不提供这些功能系统也有可能被接受，但... Read More
在此强调一个观念：软件代表着创造它的团队。你想了解这个团队？看看他们的软件就知道了，反之亦然。我特别强调这个观念是因为这是软件开发管理的基础。在某一个时间点或是从某一段描述中，或是从这个团队的行为，常常无法准确判断这是个什么的团队，但软件不会说谎。软件会忠实地展现创造它的团队：一切优点和缺点，天赋和天谴，从潜伏期的小病到最极致的团队合作。若对这个团队有任何疑问？他们的软件作品就是答案。如... Read More
项目经理是软件开发团队的一份子，他的职责是： 领导大家定义出一个成功的产品。 引导大家对产品注入深切的期望和信念。 带领团队将理想实现，变成可预见的产品诞生。 项目经理并没有（或只有很少的）正式的权力或地位，至少刚开始时时如此，所以项目经理通常会为此感到非常地焦虑。笨蛋项目经理可能以为他的工作就是写出软件规格，让其他人去写程序、测试程序、撰写文件等等，最后完成项目经理心中... Read More
如果项目经理、产品经理、开发人员不断争论谁有权设计产品或是各执一词，这是一个愚蠢的开发团队，只会关心自己的权威；然而，真正的权威是来自于对现实状况的精确掌握。 团队的认同感和归属感，能消除个体的自利行为。 摘自--《微软团队：... Read More
确定对架构关键的需求 这不仅要求对功能需求（如用例）进行筛选，还要对非功能需求进行综合权衡，最终确定对软件架构起关键作用的需求子集。也就是说，必须致力于“缩小范围”，这样就掌握了主动权，可以充分利用有限的时间把架构分析和架构设计工作做“深”，而不是碌碌无为地在多得数不清的需求之间徘徊。 概念性架构设计 设计概念性架构的第一步是分析关键用例的用例规约，运用鲁棒图构造系统理想化的职责模型。接... Read More
透过问题领域的重重现象，捕捉其背后最为稳固的领域概念及这些概念之间的关系。 Read More
由于项目工作量不大、或者项目复杂度不高，所以工程师本身就可以独立完成。由于项目相对简单，在实施过程中，有一些项目管理活动（比如：项目例会、项目风险定期监控等）可以被简化或部分省略。但是，对项目范围、成本和时间等方面的管理却不能缺少，这依然是保证项目成功的必要步骤。所以在简单项目中，有经验的工程师可以身兼两职，即可以亲自实施项目中的技术内容（如设计、安装、测试等），又鉴当项目经理的角色。 ... Read More
团队协作模式下，沟通常常成为项目最大的瓶颈 --团队成员间的沟通成本与成员数目成几何指数比例关系 --沟通中的信息丢失、失真、曲解成为团队的最大敌人 团队协作开发的总体质量适用木桶原理，取决于最差者的开发（编码）质量 团队协作的进度优势体现在成员的并行工作上 --多人对同一工件同时操作所造成的冲突和混乱往往抵消了并行开发所能带来的好处 --将工... Read More
错误地理解最终用户的需要 面对变化中的需求无计可施 开发出一些无法整合为一体的软件模块 难以维护和扩展的软件系统 在后期才发现项目中所存在的严重缺陷 低下的软件质量 不能接受的软件性能 项目成员各自为政，搞不清楚谁在何时、何处、为了什么而变更了哪些内容 一套不可靠的构造和交付流程 Read More