《微软开发快速秘籍》读书笔记4-软件开发基础

1.  软件开发基础

1.1.     管理基础

1.1.1.  计划

1.          估算工作时程;

2.          决定多少人参与这个专案，需要什么样的技术能力，何时增加人员，是谁决定如何组织这个团队;

3.          选择使用何种生命周期模型

4.          危机管理

5.          对如何控制产品的功能设定和是否购买或自制产品的每一部分等议题，做策略性的决定

 

Rapid development	CMMI中的PP目录
估算工作时程	人力成本估计（Effort and Cost Estimation：）      专案时程（Project Schedule：mpp）
决定多少人参与这个专案，需要什么样的技术能力，何时增加人员，是谁决定如何组织这个团队	资源需求（Resource Requirement） 工作责任矩阵图（Task Responsibility Matrix）    组织架构图(Project Team Structure)       人力需求（Human Resource Requirement）  软硬件需求（Software/Hardware Requirement）  教育训练：(Training)
选择使用何种生命周期模型	项目流程（Project Process：类别，生命周期模式，流程调试）
危机管理	风险管理计划（Risk Management Plan）
对如何控制产品的功能设定和是否购买或自制产品的每一部分等议题，做策略性的决定	决策分析(Decision Analysis and Resolution)
	项目基本资料（Project Profile:客户名，专案名代号，类型，起讫日期）        项目目的及项目范围（Project Purposes and Project Scope） 项目目标（Project Objects：完成内容，管理目标，合约交付项目验收条件）    项目环境（Project Environment：开发/建制环境）
缺失 项目相关计划（Relative Project Plan）	专案监控（Project Monitoring and Control） 关键人员参予与沟通计划（Stakeholder Involvement and Communication Plan） 质量保证计划（Process and Product Quality Assurance Plan） 项目验证与确认计划（SVVP） 建构管理计划（Configuration Management Plan）        度量与分析计划（Measurement and Analysis Plan）    项目门坎管理(Project threshold management)        供货商管理计划（Supplier Management Plan） 包装、安装与交货计划 教育训练与技术移转计划    验收与结案计划(验收审查会议)
缺失 裁适准则(Tailoring Guideline)
缺失 组织重用和发展计划(Resuse & Plan)

1.1.2.  追踪

依照计划去追踪和确认各项事宜：时程进度，成本，品质目标。

典型的管理层级追踪控制：工作表，进度会议，进度报告，定期检视，预算报告，不时的巡视管理。

典型的技术层级追踪控制：技术审核，技术检视，依里程碑所做的品质审阅。

 

状况测量对于专案管理来说是必要和重要的成功因素。

在专案进行中很少知道情况进展如何是一种危险的事，应该对专案进展了如指掌。

追踪是软件管理的基础，是预知危机提前解决的保证，也是尽快发现延迟设法弥补的保证。

1.1.3.  量测

当你的老板说：我们可以在9个月内开发这个产品吗？

你可以说：我们组织开发这样的产品从来没有少于11个月，平均都是13个月。

这是量测得作用之一

有数据比只靠直觉来得好。

1.2.     技术基础

1.2.1.  需求管理

收集需求管理变更：纪录在文件，邮件，能执行的原型中，追踪与其相关的设计和编码，然后管理其他部分相关的改变。

需求分析方法学：结构分析，资料结构分析，物件导向分析

系统模型实作：古典图，资料流程图，实体关系图，资料字典，状态变化图。

通讯实作：合作系统开发(Joint Application Development,JAD),使用者皆免原型，一般会谈方法。

需求管理与不同生命周期模型之间的关系：渐进式原型，阶段性发行，螺旋型，瀑布型，编码与修改。

 

典型的专案在需求上会有25%的改变。

一开始就得到正确的需求资询所花的成本，会比直到建构或维护时才发现少50到200倍。

1.2.2.  设计

主要设计风格(物件设计，架构设计，资料结构设计)

基础设计概念（咨询隐藏，模组性，抽象化，封装，对称，层级结构，继承，基本演算法，基本资料架构）

对典型挑战的标准设计方法(例外处理，国际化/本地化，可移植性，字符串存储，输入/输出，记忆体管理，资料储存，浮点运算，资料库设计，效能，和再使用)

对你所正在进行的应用程式领域作特殊的设计考量（财物应用程式，科学应用程式，嵌入式系统，即使系统，安全危机软件，其他）

架构模式（系统组织化，层级，附属系统沟通风格，典型系统构架）

使用设计工具

设计提供架构，专案工作时程，专案追踪，和专案控制的基础。

1.2.3.  建构

编码实作（命名，格式，文件）

资料相关概念（变数范围，以致性，连接时间）

对使用特定资料形态的指导方针（）

与控制有关的概念

 

1.2.4.  软件配置管理

版本控制

1.3.     品质确认基础

l          品质确认1h会在专案后期省下3~10h

l          直到建构或维修阶段才处理需求错误的成本会比在需求阶段就处理的成本多50到200倍

l          一般而言，在前期(需求或设计阶段)没有侦查处的错误，会在后期（测试阶段）花10到100倍的成本去修改。越晚发现的错误会花越多的成本去修改。

1.3.1.  错误倾向模组

百分之80%的错误产生在20%的模组上。

错误倾向模组的每个功能点成本是正常模组的4倍。

如果模组的错误比率达到每一千行有十行错误，或过长，或结构不好，这时重头来重新设计模组和执行，错误倾向模组的确认和重新设计是必须要优先处理的。

1.3.2.  测试

个人测试：开发者检查自己的编码并确认运作正确(发现10%~15%的错误)

系统测试：专业测试者检查系统操作是否如预期。(发现20%~60%的错误)

其他错误不是最终使用者发现就是在技术检阅中发现。

当测试时发现产品的品质低到不足以上市的时，进度一定要延后直到改善。

1.3.3.  技术检阅

对需求，设计，测试个案，和所有专案其他非自然讯号作全盘性侦测错误的检阅。

                             排演(walkthroughs)

两人或两人以上的开发人员(not only PG)，以改善品质为目的而作检阅技术工作的会议

                     编码阅读

编码者把程式码交给两位或两位以上的检阅者，检阅者阅读并指出错误。

发现错误的效率是测试的两倍。

                     审查(inspections)

审查的效率比测试高20倍

仲裁者(moderator)，确定待审的工作产品

检阅者(reviewers)，在会议前检阅产品并详细列出检阅结果

作者(author)，对被审查项目进行说明，确认检阅者发现的错误

纪录(scribe)，纪录错误，

主席，制作审查报告，说明每项错误并指出如何改正。收集有关资料(错误，修改花费时间，审查花费时间)

1.3.4.  对技术检阅的意见

修改错误要趁他们还小，还容易控制的时候。

1.4.     跟随指示

油漆波音747飞机，一层油漆就重达400到800磅，风雨会以每小时600英里的速度打在油漆上。