软件服务工程课程总结

第一周

云计算

什么是云计算

云计算是一种模式，该模式允许用户通过无所不在的、便捷的、按需获得的网络，接入到一个可动态配置的共享计算资源池（其中包括网络设备、服务器、存储、应用以及业务），并且以最小的管理代价或业务交互复杂度即可实现这些可配置计算资源的快速发放与发布。

Saas软件即服务面临的挑战和它的适用性

挑战一：转换成本高。解决方案是提升服务质量，增强客户满意度。

挑战二：有限的灵活性。解决方案是提供应用程序交换平台，提供可定制化服务。

挑战三：安全性和隐私性。解决方案是尽可能谨慎并更加专业化。

SaaS的适用性：

1、企业软件应用

• 执行业务功能
• 组织内部和外部信息
• 在内部和外部用户之间共享数据
• 适用于Saas模型的最标准类型的软件
• 示例：Saleforce.com CRM应用 Siebel On-demand 程序

2、单用户软件应用

• 组织个人信息
• 在用户自己的本地计算机上运行
• 一次只服务于一个用户
• 不适用于Saas模型
  • 数据安全问题
  • 网络性能问题
• 示例：Microsoft办公套件

3、基础设施软件

• 作为大多数其他企业软件应用的基础
• 不适用于Saas模型
  • 需要在本地安装
  • 形成运行其他应用程序的基础
• 示例：Window XP、Oracle数据库

4、嵌入式软件

• 嵌入式系统软件组件
• 支持硬件设备的功能
• 不适用于Saas模型
  • 嵌入式软硬件结合在一起，密不可分。
• 示例：嵌入ATM机、手机、路由器、医疗设备等的软件

 

PaaS的概念

PaaS（平台即服务）是一个计算平台，它使得用户能够快速、方便地创建web应用，并且无需担心维护下层软件。其基本特征包括：在相同的集成开发环境中用来开发、测试、部署、托管和维护的应用;基于web的用户界面来创建工具，可用于创建、修改、测试和部署不同的UI场景；多租户架构，可使多个并发用户使用相同的开发应用；内置部署软件的可扩展性，包括负载均衡和故障转移；通过公共标准集成web服务和数据库；支持开发团队协作，包括一些PaaS解决方案以及项目规划、沟通工具等。

国内外著名PaaS提供者包括Google App Engine、Microsoft Azure、百度云等

IaaS的概念

IaaS(基础设施即服务)以服务模式提供计算、存储、网络等基础设施资源给用户。传统方式下企业需要去买物理服务器、存储等硬件来承载本地应用，让企业业务运行起来。通过IaaS，企业可将硬件外包给IaaS供应商，供应商会提供可支撑企业应用的服务器，存储和网络硬件及虚拟化软件，对上层业务提供虚拟机或其他基础设施资源。主流的IaaS供应商包括Amazon，Microsoft，VMWare，阿里、腾讯等

AMI（Amazon Machine Images）

AMI是一种使用亚马逊云计算服务时创建的机器镜像，机器镜像中包括操作系统、应用程序和配置设置。

通过AMI可以运行多个实例，这些实例是AMI的副本，每个实例类型提供不同的计算和内存设施。

Hadoop

Hadoop是一个由apache基金会所开发的分布式系统基础架构，用户可以在不了解分布式底层细节的情况下，开发分布式程序，Hadoop的使用和流行使人们可以充分利用集群的能力进行高速运算和存储。

Hadoop各组件：

HBase（分布式列存数据库）、Zookeeper（分布式协作服务）、Sqoop（数据同步工具）、Hive（数据仓库工具）、Pig（数据流系统）、Mahout（数据挖掘算法库）、Flume（日志收集工具）、Yarn（资源管理器）

DevOps介绍

DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。

SOA面向服务架构相关概念，微服务概念

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。

相对于单体架构和SOA，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

• 一组小的服务 

• 独立部署运行和扩展 

• 独立开发和演化 

• 独立团队和自治 

第二周

敏捷

敏捷是一组用于软件产品开发的实践、价值和原则。

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发。

 

为什么要用敏捷开发：敏捷使软件产品更好地响应客户需求，同时可以有效节省精力和资金。

传统的开发模型可能会增加客户的成本，原因如下：

1、新技术不断引进。

2、新玩家进入市场，

3、增加了新的要求

4、“小即美”

5、倾听顾客的需求，能降低被更小、更灵活的竞争对手击败的风险。

6、任何有助于降低维护成本的东西都有助于项目实现

 

敏捷开发和传统开发对比：

敏捷软件开发与传统开发方法相比具有很大的不同，其特点是适应性而不是预测性，强调沟通和反馈，开发团队不仅包括开发人员，还包括管理人员和客户。它鼓励团队成员的相互交流通过反馈机制尽早纠正软件中的错误，提高开发效率，同时为需求的调整提供更多机会，保证软件向正确的方向发展。

传统软件开发如瀑布模型强调预见性，严格遵循计划、分析、设计、编码、测试和维护等几个阶段。瀑布模型开发各阶段间具有严格的顺序性和依赖性，必须等到前一阶段的工作结束后才能开始下一阶段的工作，前一阶段的输出文档是后一阶段的输入文档，只有前一阶段的输出文档完全正确，后一阶段才能获得正确的结果。

 

敏捷开发的原则：

1、最优先考虑的是通过早期和连续交付有价值的软件来满足客户。

2、拥抱变化。敏捷过程利用变化来获得竞争优势。

3、频繁地交付工作，从几周到几个月，优先用更短的交付时间。

4、同一个项目的业务人员和开发人员必须在一起工作。

5、围绕有能力的个人建立项目。给他们需要的环境和支持，信任他们完成工作。

6、向开发团队传递信息最有效的方法是面对面的交谈。

7、工作软件是进度的主要度量。

8、敏捷过程促进可持续发展。赞助商、开发人员和用户应该能够无限期地保持恒定的步伐。

9、持续关注技术的卓越性和良好的设计可以提高敏捷性。

10、简洁是必不可少的。

11、组建团队实现最好的架构、需求和设计。

12、每隔一段时间，团队要思考如何变得更加有效，然后相应地进行调整。

 

敏捷方法：scrum

scrum是一种敏捷开发流程，在scrum流程中包含三大角色：

产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

流程管理员（Scrum Master）

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

如何进行scrum开发：

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

敏捷估算

计划扑克玩法

1.发牌 
2.拎出一个要估算的功能，PM解释要求 
3.开发人员根据功能给出自己的估算值，用牌上 的最接近的数字代替，出牌背面朝上（每次一张） 
4.大家同时翻转牌，差距过大的人给出自己的想法 
5.大家根据刚刚的发言再出牌和翻转，直到达成一致，该功能的估算结束 
6.重复2~5直至团队资源耗尽。
 

第三周

scrum

scrum中的迭代方式

1、迭代计划——为一次迭代创建一个计划

选择下一个要交付的内容（按优先级选择），定义和估计任务，协商交付产品的范围

2、迭代执行——实现计划中的项目

处理需求、设计、代码、集成/构建，并测试计划中需要的模块

3、交付迭代的结果——给出demo

步骤1-3将根据发布计划多次执行

每个周期是一个固定长度的时间盒：

总是按计划结束每次迭代，即使它不是完整的

（不要说——“我们可以在另外两天内完成这次迭代的所有工作”）。只需交付并运行下一次迭代计划会议。

团队学会了做出好的短期估计——因此，随着时间的推移，大多数迭代都会如期交付。

scrum角色

scrum小组

scrum板

待办事项

敏捷使用产品Backlog来管理需求，产品Backlog是一个需求的清单，按照需求的商业价值排序， 高优先级的需求在Backlog的最上层。产品Backlog是一个渐进明细的清单，它有4个主要特点，称之为DEEP：

• Detailed 合适的详细程度，高优先级需求更加明细，低优先级的需求粒度更大
• Emergent 涌现式的，需求是慢慢涌现出来的，渐进明细的
• Estimated 经过估算的
• Prioritized/ Ordered 根据商业价值排好顺序的

在产品Backlog中，需求的主要表现形式是用户故事。用户故事是从用户的角度对需求的简短描述。用户故事是将团队的焦点从描述、编写功能需求转移到讨论需求的最佳方式。

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

• 角色：谁要使用这个功能。
• 活动：需要完成什么样的功能。
• 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

作为一个<角色>, 我想要<活动>, 以便于<商业价值>。
比如：作为一个网站的普通会员，我期望在我下订单后，未发货之前可以取消订单，这样对我来说更灵活。

scrum管理工具

https://www.leangoo.com/kanban/board_list

第四周

软件系统架构演变