测试：测试计划和策略，满足:正确性、功能性、性能、安全和系统测试
配置：文档和代码的存档及版本控制，提供文档规范,并传达到开发组中
质量：质量的分解,为:“需求质量”、“设计质量”、“实现质量”、“发布和维护质量”。设置质量控制点。控制点一般采用“评审”或“审查”为主。

文中对上述三个职责简单描述，写的比较整齐，但是缺乏细致度。不过，这样的话题也很难写的高质量，因为，他们每一个都可以具备较完整的体系，所以一句话两句话又怎么说的清呢。

从方法和态度2个角度入手。
……

我认为：
劳动密集型和知识密集型,只重人力单价，抛弃知识应有的价值，那么，蜕变是必然的，软件公司退化成为软件人力资源外包公司，软件人员蜕变成工人......软件团队销售的是领域经验，销售的是知识，这才够的上核心价值。

无论是以项目为主还是以软件产品为主要收益来源的软件公司，为了保证软件的延续销售，都需要对软件进行管理，即做到软件生命周期的管理，然后再去满足项目的需要

阅读《浅议工程项目的成本核算》之后
参与过而且也正在做着高速公路的机电项目，主要针对监控信息化这一块，对工程项目整体的管理还比较生疏，但是，读完这篇文章后，我觉得至少有一些启发和感触，记下来，以便日后的思考和作业实践。
思考一：项目成本核算
只要是做项目，都要存在成本的问题，看看我们是不是赚钱了，还是亏钱了。这篇文章中谈到的成本核算，我理解主要着力于成本核算的“对象”发生改变。不管有多少个团队或单位参加这个项目，还是只有一个单位负责，我们核算的对象是项目，也就是研究对象是项目本身，不用去考虑时间因素的影响，不用去考虑项目在单位之间的转移，从核算的角度看，简单清晰。

算下来，做项目管理已经有8年了，其实不管有没有角色的明确，我觉得自己都在做着这样的一些事情，比如：计划、跟踪、交流、文档等等，所以夸张的讲有这么多年头了。

现实项目的沟通往往一波三折
教科书里教的东西通常是很理论的，告诉我们沟通要有计划，要用这样那样的方法，要做沟通记录等等，这些可以说是“好东西”，是一种工作习惯，是实践的经验总结，但是仅仅知道这些后，在项目的沟通中我们也不一定很顺利，因为现实中问题很复杂，比如我们会碰到这样一些问题：
1、我们要了解需求，却找不到沟通的接口人；
2、谁是最终用户，谁是客户，是谁对工期提出要求，是谁约束着我们的工期；
3、谁更关注质量？
4、不同涉众方的关注点对项目的影响，如何去明确涉众方的最终目标
5、通过间接手段获得的需求对项目危害深重，尤其深重，深不可测！