轉自:http://www.leadge.com/djnews/news/20076783221.htm
下午下载了 MSDN Webcasts 关于 ASP.NET 项目实战系列课程的第一讲，了解了一下项目/产品的运作过程。
课程的主讲老师是MSDN的特约讲师邵志东先生。课程中间，邵志东老师介绍了软件开发流程、 程序员基本素质、关于质量控制和开发模板及项目组建设。
邵老师首先介绍了软件开发的流程，他把软件开发分为了两大类，即项目开发及产品开发。
项目开发是公司根据某一客户的需求单独为某一客户订制的软件；
产品开发是公司针对某一市场需求而开发的软件产品（比如WINDOWS、OFFICE等）。
这里把流程图用PS重新绘制了一下： 
程序员的基本技能包括了以下几个方面：
1、项目实践
• 软件工程理论
• 质量体系：ISO9001和CMM体系
• UML基本理论
• 测试理论和测试工具使用
• 加密理论和加密方法
• 源代码控制工具使用
• 说明书编写
• 程序的安装和部署
2、专业技能
3、程序员基本素质
• 团队精神和协作能力（• 木桶理论、• 学习性组织）
• 文档习惯（• 注释、• 开发过程文档：良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，而作为高级程序员和系统分析员，这个比例还要高很多。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。）
• 规范化，标准化的代码编写习惯（作为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。• 代码编写规范• 界面设计规范）这里邵老师强调了标准未必要固定，但在一个项目组中间要有统一的标准。
• 复用性，模块化思维能力（• 用户控件 • 组件技术）
• 测试习惯（• 单元测试 • 集成测试 • 系统测试 • 稳定性测试 • 软件研发作为一项工程而言，一个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。）
• 学习和总结的能力（• 学习：程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年内具有领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。• 总结：善于总结，也是学习能力的一种体现，每次完成一个研发任务，完成一段代码，都应当有目的的跟踪该程序的应用状况
和用户反馈，随时总结，找到自己的不足，这样逐步提高，一个程序员才可能成长起来。）
4、职业素质
• 交际能力
• 表达能力
• 职业素养
5、个人素质
• 信心和恒心
• 良好的个人品质
• 良好的个人习惯
• 关于质量控制和开发模板
• 项目组建设
高级程序员的基本素质：
1. 需求分析能力
对于程序员而言，理解需求就可以完成合格的代码，但是对于研发项目的组织和管理者，他们不但要理解客户需求，更多时候还要自行制定一些需求，为什么这么说呢？
2. 项目设计方法和流程处理能力
程序设计者必须能够掌握不少于两到三种的项目设计方法（比如自顶至下的设计方法，比如快速原型法等等），并能够根据项目需求和资源搭配来选择合适的设计方法进行项目的整体设计。设计方法上选择不当，就会耽误研发周期，浪费研发资源，甚至影响研发效果。
3. 复用设计和模块化分解能力
一个成熟的软件行业，在一些相关项目和系统中，不同的部件是可以随意换装的，比如微软的许多桌面软件，在很多操作模块（如打开文件，保存文件等等）都是复用的同一套功能模块，而这些接口又通过一些类库提供给了桌面应用程序开发者方便挂接，这就是复用化的模块设计明显的一个佐证。
4. 整体项目评估能力
作为系统设计人员，必须能够从全局出发，对项目又整体的清醒认识，比如公司的资源配置是否合理和到位，比如工程进度安排是否能最大化体现效率又不至于无法按期完成。评估项目整体和各个模块的工作量，评估项目所需的资源，评估项目可能遇到的困难，都需要大量的经验积累，换言之，这是一种不断总结的累计才能达到的境界
5. 团队组织管理能力
首先是工作的量化，没有量化就很难做到合适的绩效考核，而程序量化又不是简单的代码行数可以计算的，因此要求技术管理人员需要能真正评估一个模块的复杂性和工作量。
其次是对团队协作模式的调整，一般而言，程序开发的协作通常分为小组进行，小组有主程序员方式的，也有民主方式的，根据程序员之间的能力水平差距，以及根据项目研发的需求，选择合适的组队方式，并能将责权和成员的工作任务紧密结合，这样才能最大发挥组队的效率。
质量/过程标准部分的介绍
质量/过程标准是什么，有什么用？
• 开始并没有什么质量标准或者过程标准，但有些组织和企业呢，做的很成功，而有些则不成功。那么有人就去分析为什么，这些组织和企业成功了呢？他们有哪些的共同的特征吗？答案是有，于是这些特征被归纳出来（比如9000中的立项，开发策划，cmm中需求管理、配置管理等），并应用管理理论的成果，使之成为一种体系。
他能做到什么和不能做到什么？
• 当操作者有意识时，标准可以帮忙。假如你没做产品立项，或者作了，但没有市场分析报告，标准可以帮忙，因为SQA会来说，这违背了规程，我们必须先做产品立项，并且必须基于市场分析报告。
• 但大家没有意识时，比如产品立项时，假如与会人员多数认为没有市场，或者我们没有能力去做这个产品，但最终仍然立项通过，标准无能为力。
如何应用标准？
• 标准的目的？
– 可控制– 可追溯
• 开发模板
– 用户需求规格说明书 – 需求评审报告
– 系统设计书 – 系统开发进度计划
– 项目验收标准 – 用户手册项目组文档
接下来的课程中邵老师又介绍了下面的内容：
• 编码规范
• 项目组守则
• 工作计划总结
• Sourcesafe使用规范
• 公共几类和常用代码
Sourcesafe使用
一、版本管理的必要性
• 如果说70年代的软件危机导致了软件工程思想的诞生和理论体系的发展，那么80～90年代尤其是90年代软件产业的迅猛发展导致了另一种新思想的产生和实现，这就是软件的版本管理。
• 以往的那种被誉为具有良好编程风格的做法，诸如在对他人的源程序进行修改时注释修改原因，修改人和日期，如果是多个成员同时进行了修改，那么需要进行及时的人工的差异比较和综合以便形成一个统一的新版本。这种做法在当前的大型软件的开发中已经越来越没有空间了，可以说是一种以小作坊的形式来面对软件的社会化大生产，再也不可能行得通了
二、Visual SourceSafe 6.0(VSS 6.0)简介
• Microsoft的VSS 6.0解决了软件开发小组长期所面临的版本管理问题，它可能有效地帮助项目开发组的负责人对项目程序进行管理，将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。
• 开发组的成员不能对该数据库中的文件进行直接的修改，而是由该版本管理器将该项目的源程序或是子项目的源程序拷贝到各个成员自己的工作目录下进行调试和修改，然后将修改后的项目文件作Checkin提交给VSS，由它进行综合更新。
• VSS的客户端和服务端的安装
• VSS服务端和客户端的使用