PSM（PracticalSoftware and Systems Measurement） 过程的9条软件度量准则：5）使用结构化过程跟踪用于决策的度量。6）根据项目上下文信息解释说明度量的结果。7）在软件生命周期中将软件度量集成到项目管理中。9）使用度量过程作为目标沟通的基础。阅读全文>
发表于 @ 2007年09月30日 01:47:00|评论(loading...)|收藏
（注：下面的对话是有环境前提的，大致是部分开发已经提前完成，整体系统设计能力不足，多的不说，见谅）问题1、对目前的系统设计进行一次外部专家Review，尽早识别风险，让大家能够对当前的系统设计达到的质量状况有一个清楚的认识。……。me：我目前的想法：是否可以先关注代码质量和测试用例的质量，代码质量可以由系统组帮忙组织进行审核，用例可以请测试部对异常用例是否充分进行审核AAA：是个好问题。AAA：XXX要素表不是质量标准，属于质量标准之一。共识：先这样做，先对XXX要素如何标识水平考虑一下.阅读全文>
发表于 @ 2007年09月13日 02:28:00|评论(loading...)|收藏
前天因新员工问起“质量铁铁三角”的理解问题，便总结了一下，顺便试验一下Mind-Map工具。刚好，今天看见CSDN改版，新增了一个“软件研发”的栏目，并且直接说明了该栏目不讨论“方法论”，觉得这里面有些误区，应该是不孤立的讨论不同方法论中的具体技术才是，否则脱离了方法论，空谈过程和管理都是无益。希望有所借鉴。阅读全文>
发表于 @ 2006年05月17日 01:53:00|评论(loading...)|收藏
重读《软件构架实践》第一章，观其对“系统需求不能决定构架”的论证有感。写这篇文章主要是为了指明解决问题的一种途径——“扩大术语定义”，通过“过程”定义的扩大，来证明“过程决定质量”，其实随着软件工程的发展“过程”含义需要扩大已经被很多人意识到了，只是一直没有人明确的重新定义（或者是没有明确说出来），但已是在那么干而已。另外，需要指出的是，术语定义范围的扩大并非始终是正确的，例如文中提到的“需求”定义的扩大，很明显就是不可能解决问题的。但对于某些问题，这是一种常见的手段。之所以会写它，是因为当人们讨论问题时，一边使用一种定义，另一边则偷偷扩大了定义，会导致双方谈论问题时，出现“针尖对不上麦芒，打不到一块”的情况，徒惹不必要的争议，还各不愉快。阅读全文>
发表于 @ 2006年02月24日 20:49:00|评论(loading...)|收藏