按照形式化的程度，可以把软件工程使用的方法划分成非形式化、半形式化和形式化3类。
所谓形式化方法，是描述系统性质的基于数学的技术。
用自然语言书写的系统规格说明书，可能存在矛盾、二义性、含糊性、不完整性及抽象层次混乱等问题。
数学最有用的一个性质是，它能够简洁准确地描述物理现象、对象或动作的结果，因此是理想的建模工具。数学特别适合于表示状态，也就是表示“做什么”。
应用形式化方法的准则
1.应该选用适当的表示方法。
2.应该形式化，但不要过分形式化。
3.应该估算成本。
4.应该有形式化方法顾问随时提供咨询。
5.不应该放弃传统的开发方法。
6.应该建立详尽的文档。
7.不应该放弃质量标准
8.不应该盲目依赖形式化方法：形式化方法并不能保证开发出的软件绝对正确，例如，无法用形式化方法证明从非形式化需求到形式化规格说明的转换是正确的，因此，必须有那个其他方法(例如，评审、测试)来验证软件正确性。
9.应该测试、测试再测试。
10.应该重用。
需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答”系统必须做什么?”这个问题。
虽然在可行性研究阶段已经粗略地了解了用户的需求，甚至还提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法，因此许多细节被忽略。然而在最终的系统中却不能遗漏任何一个微小的细节，也就是对目标系统提出完整、准确、清晰、具体的要求。
通常对软件系统有下述几方面的综合要求：
1.功能需求
2.性能需求
3.可靠性和可用性需求
4.出错处理需求
5.接口需求
6.约束
7.逆向需求
8.将来可能提出的要求
与用户沟通获取需求的方法
1.访谈
通过正式和非正式的访谈
2.面向数据流自顶向下求精
3.简易的应用规格说明技术
4.快速建立软件原型
需求分析过程应该建立3种模型，它们分别是数据模型、功能模型和行为模型。
验证软件需求
从4个方面进行验证
1.一致性
2.完整性
3.现实性
4.有效性
| 阶段 | 制品 | UML | |
|---|---|---|---|
| 起源 | 任务陈述或非正式的需求 | 否 | |
| 任务 | 否 | ||
| 责任 | 否 | ||
| 项目计划 | 否 | ||
| 工作本 | 否 | ||
| 术语表(全面更新) | 否 | ||
| 测试计划 | 否 | ||
| 需求 | 业务 | 参与者列表(带有描述) | 否 |
| 用例列表(带有描述) | 否 | ||
| 用例细节 | 否 | ||
| 活动图(可选) | 是 | ||
| 通信图(可选) | 是 | ||
| 系统 | 参与者列表(带有描述) | 否 | |
| 用例列表(带有描述) | 否 | ||
| 用例细节 | 否 | ||
| 用例图 | 是 | ||
| 用例调查 | 否 | ||
| 用户接口框架 | 否 | ||
| 分析 | 类图 | 是 | |
| 通信图 | 是 | ||
| 设计 | 系统 | 部署图 | 是 |
| 层图 | 否 | ||
| 子系统 | 类图 | 是 | |
| 顺序图 | 是 | ||
| 数据库模式 | 否 | ||
| 类规范 | 注释 | 否 | |
| 实现 | 源代码 | 否 | |
| 测试 | 测试报表 | 否 | |
| 部署 | 压缩打包的解决方案 | 否 | |
| 手册 | 否 | ||
| 培训材料 | 否 | ||
| 维护 | 错误报告 | 否 | |
| 递增计划 | 否 |
1.项目来源(与顾客一起进行)
a.了解顾客的需求，或者告诉他们需要什么
b.从顾客处获取需求文档，作为任务陈述或较长的文档；如果没有这些文档，就和顾客一起编写非正式的需求文档。
2.分配任务
a.确定开发任务(例如规划、管理、计时、开发、测试、系统管理)。
b.确定每个任务由谁负责。
3.编写业务手册：在纸上或者在线业务手册上包含所有的项目制品。
4.编写术语表
a.编写一个术语表，以记录项目术语的定义。
b.在整个开发过程中更新术语表。
5.制订项目计划
a.为螺旋式递增阶段进行初步的规划，并制订一个进度表。
b.在整个开发过程中，定期检查、调整项目计划。
6.制订测试计划：考虑不间断的测试、测试阶段、顾客评估、开发和维护。
7.业务需求(与顾客一起)：
a.制订业务参与者列表(及其描述)
b.制订业务用例列表(及其描述)
c.(可选)用活动图描述业务用例
d.(可选)用通信图描述业务用例
e.确定业务用例的细节
8.系统需求(与顾客一起)：
a.使用用户界面草图描述系统交互
b.制订系统参与者列表(及其描述)
c.制订系统用例列表(及其描述)
d.绘制系统用例图
e.制订系统用例调查表
f.确定系统用例的细节
g.给系统生成辅助需求
h.确定系统用例的优先级
9.分析：
a.绘制分析类图
b.制订属性列表(及其描述)
c.(可选)使用状态机给复杂的生命周期建模，在状态机图上记录结果
d.实现用例，使用通信图描述结果
e.制订操作列表(及其描述)
10.系统设计
a.选择技术
b.确定重用的可能性(库、模式和框架)
c.绘制层图
d.编写层交互策略
e.设计包结构，在包图上记录它
f.绘制部署图
g.制订安全策略
h.制订并发策略
11.子系统设计
a.定义业务服务
b.确定更多重用的可能性(库、模式和框架)
c.把分析类映射到业务层类上：类列表(及其描述)、类图、字段表(及其描述)。
d.生成数据库模式
e.为其他层设计类(例如服务器和协议、服务小程序、控制、持久)
f.实现业务服务，在顺序图上记录结果
g.制订消息列表(及其描述)
h.最后确定用户界面的设计
12.类的规范
a.为每个类生成非正式规范
b.在设计和源代码中记录非正式规范
13.实现
a.编写单元测试
b.编写实现代码
14.测试
a.让测试小组测试系统
b.修改错误
15.部署
a.生成手册和课件
b.在客户的系统上安装代码制品
c.培训客户
16.维护
a.修改错误
b.把顾客的反馈、改进意见和市场变化合并到新的递增版本中
许多问题不可能在预定的系统规模或时间期限之内解决。
可行性研究的目的不是解决问题，而是确定问题是否值得去解决。
技术可行性：使用现有的技术能实现这个系统吗？
经济可行性：这个系统的经济效益能超过它的开发成本吗？
操作可行性：系统的操作方式在这个用户组织内行得通吗？
1.复查系统规模和目标
清晰地描述对目标系统的一切限制和约束。
2.研究目前正在使用的系统
现有的系统是信息的重要来源，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。
3.导出新系统的高层逻辑模型
优秀的设计过程通常是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。
分析员能够使用数据流图，描绘数据在系统中流动和处理的情况，从而概括地表达出他对新系统的摄像。还应该有一个初步的数据字典，定义系统中使用的数据。
4.进一步定义问题
分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。
5.导出和评价供选择的解法
分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的(较抽象的)物理解法供比较和选择。导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。例如在数据流图上划分不同的自动化边界，从而导出不同物理方案的方法。
6.推荐行动方针
是否继续进行这项开发工程？分析员必须清楚地表明他对这个关键性决定的建议。
7.草拟开发计划
分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对各类开发人员(例如，系统分析员、程序员)和各种资源(计算机硬件、软件工具等)的需要情况，应该指明什么时候使用以及使用多长时间。
8.书写文档提交审查
应该把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。
阶段间具有顺序性和依赖性。
推迟实现的观点。先做设计，再做编程。
质量保证的观点。每个阶段都必须完成规定的文档，每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
优点：可强迫开发人员采用规范的方法；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点：“瀑布模型是由文档驱动的”。在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。
快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速建立一个能反映用户主要需求的原型系统。
优点：快速原型模型是不带反馈环的，开发基本上是线性顺序进行的。
把软件产品作为一系列的增量构建来设计、编码、集成和测试。它分批地逐步向用户提交产品。
优点：能在较短时间内向用户提交可完成部分工作的产品，逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
使用原型及其他方法来尽量降低风险。每个阶段之前都增加了风险分析过程的快速原型模型。每一步从风险角度分析上一步的工作结果，努力排除各种潜在的风险，通常用建造原型的方法来排除风险。如果风险不能排除，则停止开发工作或大幅度地削减项目规模。
体现了面向对象软件开发的过程迭代和无缝的特性。面向对象开发所有其他概念(例如功能、关系、事件等)都是围绕对象组成的，目的是保证分析工作中得到的信息不会丢失或改变。由于各阶段都使用统一的概念和表示符号，因此，整个开发过程都是吻合一致的。
Rational统一过程(Rational Unified Process, RUP)是由Rational软件公司推出的一种完整而且完美的软件过程。
最佳实践：迭代是开发；管理需求；使用基于构建的体系结构；可视化建模；验证软件质量；控制软件变更。
RUP软件开发生命周期：二维的生命周期模型。工作流，时间。
RUP中有9个核心工作流，其中前6个为核心过程工作流程，后3个为核心支持工作流程。
业务建模；需求；分析与设计；实现；测试；部署；配置与变更管理；项目管理；环境；
工作阶段
RUP把软件生命周期划分成4个连续的阶段
初始阶段：建立业务模型，定义最终产品视图，并且确定项目的范围。
精化阶段：设计并确定系统的体系结构，制订项目计划，确定资源需求。
构建阶段：开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能。
移交阶段：把开发出的产品提交给用户使用。
目的：为了使软件开发团队具有高效工作和快速响应变化的能力。
4个简单的价值观
个体和交互胜过过程和工具：首先致力于构建软件开发团队(包括成员和交互方式等)，然后再根据需要为团队配置项目环境(包括过程和工具)。
可以工作的软件胜过面面俱到的文档：开发人员应该把主要精力放在创建可工作的软件上面，仅当迫切需要并且具有重大意义时，才进行文档编制工作，而且所编制的内部文档应该尽量简明扼要、主体突出。
客户合作胜过合同谈判：能够满足客户不断变化的需求的切实可行的途径是，开发团队与客户密切切做。
响应变化胜过遵循计划：计划必须有足够的灵活性和可塑性，在形势发生变化时能迅速调整，以适应业务和技术等方面发生的变化。
极限编程是敏捷过程中最富盛名的一个，其名称中”极限“二字的含义是指把好的开发实践运用到极致。
极限编程有限的开发实践：
客户作为开发团队的成员。
使用用户素材：用户素材就是正在进行的关于需求的谈话内容的助记符。
短交付周期：每两周完成一次的迭代过程实现了用户的一些需求，获得他们的反馈意见。
验收测试：通过执行客户指定的验收测试来捕获用户素材的细节。
测试驱动开发：在编码之前首先设计好测试方案，然后再编程。
集体所有：小组每个成员都有更改代码的权利，每个成员都对全部代码的质量负责。
持续集成：一天之内多次集成系统，而且随着需求的变更，应该不断地进行回归测试。
可持续的开发速度：以能够长期维持的速度努力工作，避免工作时间太长，降低生产率。
开发的工作空间：全体参与者一起在一个开放的场所中工作。在这个场所中自由地交流和讨论。
及时调整计划：制订出计划之后，可以根据项目进展情况及时进行调整，没有一成不变的计划。
简单的设计：设计时不需要考虑未来的用户素材，不断变更系统设计，使之相对于正在实现的用户素材而言始终处于最优状态。
重构：在开发过程中不要过分依赖重构，不能轻视设计。
使用隐喻：可以将隐喻看做是整个系统联系在一起的全局视图，它描述系统如何运作，以及用何种方式把新功能加入到系统中。
基本准则：
项目计划应该兼顾未来的不确定因素。
用有效的风险管理来减少不确定因素的影响。
经常生成并快速地测试软件的过渡版本，从而提高产品的稳定性和可预测性。
采用快速循环、递进的开发过程。
用创造性的工作来平衡产品特性和产品成本。
项目进度表应该具有较高稳定性和权威性。
使用小型项目组并发地完成开发工作。
在项目早起把软件配置项基线化，项目后期则冻结产品。
使用原型验证概念，对项目进行早期论证。
把零缺陷作为追求的目标。
里程碑评审会的目的是改进工作，切忌相互指责。
1 下载
Fiddler:http://www.telerik.com/fiddler
.NET Framework 4:http://www.microsoft.com/zh-cn/download/confirmation.aspx?id=17718
2 简介
Fiddler是一个http协议调试代理工具，它能够记录并检查所有你的电脑和互联网之间的http通讯，设置断点，查看所有的“进出”Fiddler的数据（指cookie,html,js,css等文件，这些都可以让你胡乱修改的意思）。 Fiddler 要比其他的网络调试器要更加简单，因为它不仅仅暴露http通讯还提供了一个用户友好的格式。
3 模拟低速网络环境
Rules → Performances → Simulate Modem Speeds
有效的管理者能够使员工尽最大努力认真工作，了解员工如何受到激励以及为什么会被激励，并且选择最合适的激励方式来满足员工的需求。
动机指一种过程，它体现了个体为实现目标而付出努力的强度、方向和坚持性。
每个人都有五个层次的需求
管理者运用马斯洛的需求层次理论激励员工为实现自身需求而努力工作。但该理论也指出，一旦员工的某种需求得到实质性的满足，这种需求就不再具有激励作用。因此，需要了解目前处于哪个需求层次，然后重点满足这个层次以及该层次以上的需求。
马斯洛的理论在20世纪六七十年代得到普遍认可，但他的理论缺乏实证研究的支持。
但是，没有证据来证明哪一种理论更有效，也没有办法证明Y理论是激励员工的唯一途径。
黄仁轩在抨击一个项目团队重复犯错的时候说，“你们真的那么烂吗？”，“如果你们确实很烂，那就赶快站起来说你们很烂”。他的话用经典的X理论来解释，意思就是如果你们需要帮助，就赶快说出来。
内在因素与工作满意相关，而外在因素与工作不满意相关
| 激励因素 | 保健因素 |
|---|---|
| 成就 | 监督 |
| 认可 | 公司政策 |
| 工作本身 | 与主管的关系 |
| 责任 | 工作条件 |
| 进步 | 薪水 |
| 成长 | 与同伴的关系 |
| 个人生活 | |
| 与下属的关系 | |
| 地位 | |
| 稳定与保障 |
赫茨伯格提出了二维连续体的存在：“满意”的对立面是“没有满意”，“不满意”的对立面是“没有不满意”。因此，试图在工作中消除不满意因素的管理者只能给工作场所带来和平，未必能够激励员工。要想真正激励员工努力工作，必须注重激励因素，这些内在因素才是增加员工满意度的依据。
赫茨伯格的理论在20世纪60年代中期到80年代初一直有着广泛的影响，对该理论的批评主要是针对操作程序和方法论方面。
拥有高成就需求不一定就是好的管理者，因为高成就需求者专注于他们自己的成就，而优秀的管理者强调帮助他人完成目标。
最优秀的管理者往往拥有较高的权利需求和较低的归属需求。
目标设置理论认为，具体的工作目标会提高工作绩效，困难的目标一旦被员工接受，将会比容易的目标产生更高的工作绩效。
在你进行一项重大任务或者一次重要的班级项目汇报之前，老师是否鼓励过你“只要尽力而为就行”？这个模糊的说法“尽力而为”是什么意思？老师说过只有在班级项目汇报中得到93分，你这门功课才能得A，你的成绩是否会更高一些？目标设置理论的研究就是关注上述问题。
影响目标-绩效关系的因素
工作目标的具体化、挑战性和反馈信息对员工的工作绩效都有显著影响。
强化理论认为行为是其结果的函数。如果某种结果紧跟在某种行为之后立即出现，并且提高该行为未来重复的可能性，那么他就称为强化物。强化理论不考虑诸如目标、期望、需求等因素，而只关注个体采取某种行动后产生的结果。
例如，沃尔玛改进了小时工的奖金计划，提供出色客服的员工可以获得奖金奖励。奖金的分配取决商场业绩，而且每季度发放一次，从而使员工更频繁地获得奖励。公司的意图是，在员工完成工作目标是对他们进行奖励，以不断激励他们完成工作目标，从而强化他们的这些行为。
由于管理者想要激励员工努力工作，因为我们需要寻找各种方法来设计具有激励作用的工作。
工作特征模型，为管理者设计具有激励作用的工作提供了一种有效框架。确定了五种核心工作维度，他们的相互关系以及他们对员工生产率、动机和满意度的影响。
不公平感出现后，员工会试图采取行动来改变它。其结果可能是生产率下降或提高，产品质量下降或提高，更高的缺勤率，或者自愿离职。
管理者应该考虑把报酬分配的决策过程公开化，遵循一致、无偏见的程序，以及采取类似措施，以提高员工的程序公平感。通过增强程序公平感，即使员工对薪水、晋升或其他个人结果感到不满，他们也可能以积极的态度对待上司和组织。
期望理论认为，如果个体语气某种行为会带来某种特定的结构，而且该结果对自己具有吸引力，那么该个体往往会采取种种行为。
我必须付出多大努力才能达到某个特定的业绩水平，我确实能够达到这个水平吗？达到这个业绩水平之后我会得到什么奖励？这种奖励对我有多大吸引力，它是否有助于我实现自己的目标？在某个特定时间点上，你是否受到激励去付出努力，取决于你的目标是什么以及这个特定的绩效水平是不是实现你这些目标的必要条件。
管理者必须明白员工为什么认为某些特定的奖励有吸引力或者没有吸引力，我们希望以员工重视的东西来奖励他们。员工是否知道组织对他们的期望是什么以及组织会如何评估他们。期望理论关注人们的感知，真实情况是无关紧要的。个体对工作绩效、奖励和目标的感知（而不是客观情况本身）决定了他的动机（努力程度）。
目标设置理论：目标-努力链，表明了目标对行为的指导作用
期望理论：期望理论认为，如果个体认为努力与绩效之间，绩效与奖励之间，奖励与个人目标满足之间存在密切联系，他就会努力工作。每种联系之间又受到一些因素的影响
公平理论：个体的绩效水平不仅取决于自己的努力，而且取决于自己完成工作的能力水平，以及组织中有没有一个公正、客观的绩效评估系统
需求理论：当个体由于工作绩效而获得的奖励满足了与其个人目标相一致的主导需求，就会表现出与需求满足程度相对应的工作积极性。
需求理论：高成就需求者受到的激励不是来自组织对他的绩效评估或组织提供的奖励，对他来说，努力与个人目标之间直接相连。只要他们从事的工作能够提供责任感、信息反馈、中等程度的冒险。这些人并不关心努力-绩效，绩效-奖励以及奖励-目标的联系。
强化理论：通过组织提供的奖励对个人绩效的强化而来如果管理者设计的奖励系统在员工看来是致力于奖励出色的工作绩效，那么这种奖励会进一步强化和激励良好的绩效水平。个人经常会将自己的努力与得到的比例与其他相关人员进行比较，若觉得不公平，则会影响个体的努力程度。
工作设计理论：工作设计从两方面影响工作动机
1.个人绩效。工作本身的特征会激发个体的工作积极性。这些工作增强了努力-绩效之间的联系。
2.个人目标。增强员工对自己工作中的核心因素的控制。当工作可以提供自主性、信息反馈或类似特征时，将有助于满足该员工的个人目标，因为他们希望对自己的工作拥有更高的控制权
随着工作条件的恶化，员工的工作信心、乐观情绪以及工作敬业度也迅速下降。管理者被迫采取一些不涉及金钱或者费用相对低廉的激励措施。
召开员工会议来保持沟通渠道公开并谋求员工对工作事项的投入；设置一个共同目标，以使每个人都专注其中；创造一种社区感，以使员工能够感受到管理者关心他们和他们的工作；向员工提供继续学习和发展的机会。
当前大多数的动机理论是由美国人提出来的，而且主要是基于对美国人的研究。这些理论可能隐含着一个最明显的美国化特征：对个人主义和成就的显著强调。
对于年轻的员工来说，拥有独立性和体验不同经历的机会是非常重要的，但是，老员工可能会对高度结构化的工作机会更感兴趣。
在专业人员中，金钱和晋升通常处于次位。相反，工作的挑战性常常被排在较高的位置。
提供成为长期员工的机会。同时，临时员工和长期员工从事同样的工作，长期员工不但工资多而且享受福利待遇，那么临时工的绩效水平会受到影响。因此，让这些员工分开工作，或将他们之间的相互依赖程度降至最低，这样可能会帮助管理者减少潜在的问题。
如果负责管理某个全部由缺乏技能且工资最低的工人组成的工作群体。管理者可以利用员工认可计划，以及口头表扬。
通过公开财务报表的方式让员工参与工作决策。使员工更积极地做出有利于工作的决策，更好地理解自己的工作内容和工作方式对公司的意义，最终影响公司利润。
对员工的关注以及对出色的工作表现给予关注、赞扬和感谢。
40%的员工看不到绩效和薪酬的联系，公司没有清晰、明确地向员工传达绩效期望。绩效工资方案指的的根据对绩效的测量来支付员工工资的浮动薪酬方案。个体应当能够感觉到自己的绩效与所获得的奖励之间存在一种强有力的纽带，这样才能使激励效果最大化。
准备JMeter
安装插件
部署Master Slave
./jmeter.sh -n -t Ademo_cp.jmx -l jtl.jtl -j log.log -R B的IP
jmeter -n -t script.jmx -l jtl.jtl -R 127.0.0.1
slave启动命令：./jmeter-server -Djava.rmi.server.hostname=B的IP
master启动命令：
server:
jmeter-server
收集机器性能
Servers Performance Monitoring