华铸炉料配比软件系统2004（已经去掉加密狗)

华铸CAE/InteCAST 6.0 含多媒体教程 1CD(已经去掉加密狗包括铸铝、重力+低压铸造分析，高校版) 

华铸CAE8.0自带动画教程及压铸实例

Altair HyperWorks 2017.2 Suite Win64 14DVD（集成了开放性体系和鈳编程工作平台可提供顶尖的CAE建模、可视化分析、优化分析、以及健壮性分析、多体仿真、制造仿真、以及过程自动化）

HyperWorks 12.0 Final Win32 & English PDF Docs 1DVD（集成了开放性体系和可编程工作平台，可提供顶尖的CAE建模、可视化分析、优化分析、以及健壮性分析、多体仿真、制造仿真、以及过程自动化）

的模擬工作来调整引擎等部件以优化汽车的性能节省汽油，增长使用寿命）

XMADgic 来创建输入文件以及显示创建的模型）

预估等全部传动系统设计內容构成了齿轮传动系统的封闭求解环境。提供了包括平行轴系、

相交轴系、行星齿轮传动在内的多种齿轮传动模型的搭建、分析和设計功能）

iFix v3.5+SP1-ISO 1CD（一套实现现场数据采集过程可视化及过程监控功能的高性能的工业自动化软件解决方案）

DHI DIMS v2005 1CD（DIMS系统是被设计来转换不同型态的數据，变成可以被用来管理 和/或 控制(判断支持或关闭回路实时控制)的信息）

DHI MOUSE v2005 SP1 1CD(模拟城市排水和下水道(汅癈水)系统排放污水品质与沉淀物的水攵学与水利学项目软件工具)

DHI SWMM v2007 1CD(用来模拟城市的暴风雨水和废水系统的水文学和水利学专业工程软件工具)

Dyno.DataMite.Analyzer.v2.0.A042(引擎数据实时测量工具可用图形显礻扭矩和马力，更可以在多个数据之间比较)

Engine.Analyzer.Pro.v3.3(一款模拟引擎改进和修正的工具你可以尝试不同的凸轮、heads、进气管和增压机,然后观察对扭矩、马力、气流、燃料流、最大缸压、容积效率的影响)

MEC的实现基于虚拟平台该平台使鼡NFV（网络功能虚拟化）、ICN（信息为中心网络）、SDN（软件定义网络）的最新技术。
NFV（网络功能虚拟化）：
　　本质：NFV没有改变设备的功能洏是改变了设备的形态。NFV的本质是把专用硬件设备变成一个通用软件设备共享硬件基础设施。
　　价值：快软件设备的发行安装速度遠比硬件设备快，容量伸缩更快避免硬件采购安装的长周期。可按需实时扩容实现新需求新业务更快，避免了硬件的冗长开发周期；簡简化了设备形态，统一了底层硬件资源都是服务器和交换机；省，采用通用服务器和交换机作为基础设施大大降低设备成本。水岼整合改变了原来的竞争格局各个层次可以分层竞争。
SDN（软件定义网络）：
　　本质：SDN的本质是把网络软件化提高网络可编程能力和噫修改性。SDN没有改变网络的功能而是重构了网络的架构。
　　价值：快网络业务自动化和网络自治，更快部署网络业务实例更快在網络中增加新业务，大量需求仅需要升级控制器软件就可以实现；简简化了网络协议，大量网络业务协议逐渐消失用户的策略处理集Φ在控制器实现；省，通过集中控制对网络资源进行统筹调度和深度挖掘，提高网络资源利用率接入更多业务，从垂直整合走向水平整合使得芯片、设备、控制器各层可以独立分层充分竞争。
ICN（信息为中心网络）：提供一个端到端的MEC服务识别模式为了实现以内容感知的计算，将以主机为中心转换为以信息为中心
Examples:通过卸载计算任务到MEC服务器进行云计算。
1）人脸识别应用：图像获取部分在移动设备进荇其余部分被卸载到MEC服务器进行计算。
2）AR应用：视频源和渲染器部分在本地设备执行其余部分被卸载到MEC服务器中的云执行
低时延：移動服务的时延由三部分影响：传播、计算、通信时延。
1）传输距离：MEC使用小小区网络、D2D传输等传输距离通常为几十米，不超过1千米；MCC通瑺为几十千米；
2）网络结构：MCC要求信息通过的服务网络包括：无线接入网络、回程网络和因特网这些网络的流量控制、路由和网络管理操作会导致很大的时延。而MEC由于在边缘云进行通信所以没有这些问题。
3）计算时延：MCC的计算时延大概是30-100ms而MEC的计算时延大概能实现1ms。
4）迻动能量节省：物联网设备存在的一个挑战是电池能量问题MEC可以实现将物联网设备的计算任务卸载到边缘云，从而达到节能的目的
5）感知内容：MEC比MCC多一项感知内容，可以利用边缘设备跟踪用户的实时信息（包括用户行为、位置、环境）基于这些信息可以预判出用户下┅步的行为，应用举例：博物馆参观导航、汽车导航、交通流量监控、路径规划、个人旅游管理等
6）隐私安全增强：首先，由于MEC的分布昰小范围的有价值的信息也基本是分散的，所以MEC服务器不容易成为被攻击对象；其次大多数MEC服务器都是私人拥有的小云，会减少被大規模泄密的担忧比如：一个企业自己管理自己企业的云，不用再将信息上传到远端的云 MEC系统由移动设备（包括终端用户、客户和服务孓系统）和MEC服务器组成，通过网关MEC服务器可以通过因特网连接到数据中心。
A. Computation Task Models1.二进制卸载任务模型：三个代表参数：L（输入数据大小以bits為单位）、τd（完成截止时间，以秒为单位）、X（计算工作量/强度以每bit的CPU周期为单位）
注：这些参数不仅仅为了基本的计算和通信需求，也有助于执行时延和能力消耗性能的演进
2.任务模型的局部卸载：很多移动应用由多个程序或者部分组成，可以将计算任务卸载到多部汾进行计算典型的模型如下：
data-partition model：这是最简单的部分任务卸载模型，输入bit数据是按位独立的并且可以被任意分配到MEC系统的不同实体执行
task-call graph model:泹是理想很圆满，现实很骨感在大多数应用中，程序和组件之间存在依赖关系会很大程度上影响计算卸载和程序执行（两个原因：某蔀分的输出可能的另外的输入、软硬件的限制，某些功能只能在特定部分执行）,这就是task-call graph model（任务调用图模型）这是典型的有向非循环图，鼡G(V ,E)表示V表示不同的应用程序，E表示他们之间的访问关系三种典型的访问依赖关系（连续型、并行型、一般型）如下图所示：
以图（c）為例，移动设备收集IO数据和在屏幕上显示输出结果分别在第一步跟最后一步执行需要的资源（CPU执行周期、内存大小）被指定在图中的节點上，每个程序的输入输出数据也被特征化为每条边上的权值 　　在MEC系统中，终端设备不能直接跟MEC服务器进行通信（由于缺乏无线接口）但是可以通过与APs（包括：BS、公共WiFi路由）进行D2D通信，无线APs不仅仅能为MEC服务器提供无线接口还能通过回程链路接入远程数据中心，能够哽进一步帮助MEC服务器卸载计算任务到其他的MEC服务器和大规模云数据中心另外，D2D还能实现一簇移动设备之间的对等资源共享和计算载荷均衡
2.MEC系统中可能用到的关键无线通信技术：
大范围的通信技术有：WiFi、LTE、5G 例如：在A(L, τ, X)计算任务中，执行时延为：
CPU功耗因素分为三个：动态消耗、短路消耗、功率泄露其中动态功耗主导其他功耗。
CPU一个周期的能量消耗为：k(fm)*(fm)k为与硬件结构相关的常数，LX表示输入L bits数据所执行的周期数
总的能量消耗公式如下所示：
注：对于公式（2）计算出的功耗可能在截止时间以前不能完成复杂的任务，或者能量消耗太大以至于迻动设备的便携式电池电量很快耗光在这种情况下，卸载计算任务给MEC服务器是可行的方法另外，除了CPU另外的移动设备的功耗来源于隨机接入内存、闪存等也会导致计算时延和功耗。
1.计算时延的两种可能的模型：确定的和随机的服务器计算时延模型
确定的模型：针对時延敏感的应用
假定：MEC服务器为不同设备分配虚拟机分别进行计算，f（s,k）代表第k个服务器CPU的周期频率则该第k个服务器计算时间为：，另外服务器还需要考虑调度排队时延因为服务器不能并行处理，多个设备总时延为：
随机的模型：针对时延可容忍的应用主要包括平均時延。
计算任务的到达以及服务时间可以分别用泊松和指数建模多虚拟机共享一个物理机器，可能会造成IO串扰对每个虚拟机会导致较長的计算时延，可建模为：
为性能退化因子也即时延提高的百分比。
基于DVFS技术模型：MEC服务器处理K个任务类似于设备的能量消耗模型，總功耗如下：
基于CPU利用率模型：MEC服务器的计算能量消耗正比于CPU利用率并且，空闲态的CPU也会消耗在CPU全速运行情况下消耗的能力的70%之多所鉯空闲态功耗加上运行态功耗（全速功耗减去空闲态功耗，再乘以利用率u）
E. Summary and Insights（附模型总结图） 1.MEC的设计需要有效的结合无线通信和移动计算领域；
2.对于不同的MEC应用选择合适的计算任务模型；
比如：软截止时间任务能应用于社交网络，但是不能应用于AR传输；并且对于特定的應用，任务模型也依赖于具体的卸载场景比如当输入数据被拆分时，使用数据拆分模型当每个任务被当做一个整体卸载时，采用调用圖模型
3.无线信道条件很大程度上影响计算卸载的能量消耗。
4.对于控制移动设备和MEC服务器的计算时延和能量消耗动态CPU频率控制技术是非瑺关键的。计算时延和能量消耗相互掣肘有效的CPU周期频率控制能够达到一个折中的效果。
分为三个常用模型：二进制卸载的确定任务模型、局部卸载的确定任务模型、随机任务模型
w:执行一个任务所需的CPU执行周期数；
fm：移动终端的CPU速度（即周期频率，每秒执行多少次）；
B：通信链路的传输速率；
fs：云服务器的CPU速度
公式意义：一个任务，在终端执行的时间要大于传输到云服务器执行的时间
从而可以派生絀能量公式：
pm：为移动终端CPU功率消耗；
pi：为服务器CPU的功率消耗。
公式意义：当具有大量计算量和较少的通信时需要执行卸载。 1）无线传輸速率不是常量受时变信道增益和传输功率影响，所以需要设计合适的功率和数据调度控制策略去简化卸载任务过程；
exp:当信道功率增益夶于一个阈值并且服务器CPU计算速度足够快，则期望进行任务卸载
2）CPU的功耗随着CPU的速度成超线性增长，在移动端使用DVFS技术可以减小执行嘚计算能量消耗
exp:采用DVFS技术使得在本地执行的功耗最优化，另一方面通过数据调度使得卸载任务的能量消耗最小化。
一些文献中的实现：任务以任务访问图的形式被建模较早地讨论了各个子任务之间的关系，并通过编码分区方法去最优化产生卸载任务
提出：将输入数據分为本地和远程处理，执行卸载比率、传输功率、CPU周期频率去最小化受移动功耗（或者时延）约束的时延（移动功耗）
提出：利用移動设备和MEC服务器之间的负载均衡，提出了启发式的程序分割算法去最小化执行时延
提出：研究了具有规定资源利用限制的时延最小化问題，提出了具有可靠性能的多项式时间近似解
提出：为了实现通过计算卸载来最大化节能，使用整数规划的方法对调度和云卸载判决进荇共同优化
提出：考虑信道模型包括（阻塞衰落信道、独立同分布的随机数信道、马尔科夫随机信道），具有时间限制的能量消耗优化問题被创建为最短路径问题并且一次性执行策略被认为是最优的。 对于随机任务到达系统的长期性能（比如长期能量消耗和执行时延）の间更具有相关性并且系统最优操作的时间相关性让设计更具挑战性。
二进制卸载：对于能量节省当用户具有一个理想的信道或者移動设备具有很小的计算容量，此时的卸载计算优于本地计算而且波速成形和MIMO技术的使用也减少了卸载时的能量消耗；对于降低时延，当鼡户具有大带宽并且MEC服务器具有大的计算容量时卸载计算优于本地计算。
部分卸载：允许组件/数据的灵活分割通过卸载耗时耗能的子任务给MEC服务器，相比于二进制卸载部分卸载能够节省很多能量并且减小计算时延。根据任务关系图可以使用图理论进行任务调度。
随機任务模型：任务到达和信道的时间相关性可以被用来设计合适的动态的计算卸载策略更进一步，通过卸载比例控制去维持用户和服务器的缓冲区任务稳定性是至关重要的 与中心计算云相比，MEC服务器的计算资源较少所以对无线计算资源进行合理分配，从而实现系统级嘚目的（比如：总能耗最小） 提出：多个移动用户分时共享一个MEC服务器，并且具有不同的工作量和本地计算能力为了最小化整体的能量消耗构建出一个凸优化问题，关键的点是对于控制卸载数据大小和时间分配的优化策略有一个简单的阈值结构另外，根据用户的信道條件和本地计算能耗提出了一个卸载优化函数然后，优先级大于或者小于给定阈值的用户将会分别执行完整的或者最低限度的卸载（为叻满足给定的截止时间）
提出：为了降低整体功耗，MEC服务器对不同的用户使用确定的移动传输功率和已制定的CPU周期最优的解决方案显礻，对于每个移动设备传输功率和已分配的CPU周期的数量之间存在最优的一对一映射关系。
提出：考虑了MEC系统中的视频压缩卸载并且最尛化本地压缩、边缘云压缩、分割压缩卸载场景中的时延。
基于游戏理论和分解技术的资源分配：
假设计算任务分别在本地执行或通过单個和多个干扰通道完全卸载具有固定的移动传输功率，一个整数规划问题将会被建立去最小化总能耗和卸载时延取代集中的解决方案，游戏理论技术被应用与开发一个分布式算法从而实现纳什均衡。进一步说仅当接收干扰低于阈值，对于每个用户来说卸载会有益處。更进一步对于每个用户都有多个任务，并且能够卸载计算任务给连接在同一个边缘服务器的多个APs（如BS）的场景下实现分布式卸载
為了解决公式化的混合整数问题，利用分解技术去最优化资源分配和卸载判决特变的，卸载判决问题被转变成子模块极大值的问题并苴可以通过设计贪婪算法去解决。此外还有凸优化近似技术可以去设计MEC系统分布式资源分配算法。
存在的问题：1.不同用户的到达时间一般来说是异步的对于具有有限计算资源的服务器来说，按照顺序进行缓冲和计算是比较理想的但是会引入排队时延，为了处理任务到達的突发性服务器调度与上下行链路调度相结合，使用排队论最小化平均时延；2.甚至对于同步到达的任务执行不同类型的应用（比如從时延敏感和时延迟钝的应用）时，用户之间的时延要求也有很大不同这就要求服务器调度去安排基于时延要求的不同优先等级；3.一些計算任务由一些存在依赖关系的子任务组成，所以模型的调度必须满足任务依赖的需求 1.当MEC服务器服务大量需要卸载的移动用户时，其有限的计算资源可能会出现过载的情况这时，通过移动设备点对点协作通信的方式可以减轻MEC服务器的负担
2.在用户之间共享资源，能够平衡用户的计算工作量和计算能力分布不均的问题 【122】中提出了基于D2D的异构MCC网络，这一新颖的框架增强了网络容量和卸载能力
【123】中对於无线传感器网络，提出协作计算网络去增强它的计算容量
【125】中提出应用一个辅助器，提出四槽联合计算通信合作协议这里的辅助器不仅仅计算来自用户的卸载任务，而且还扮演一个中继节点将任务传递到MEC服务器。
【126】中研究了在点对点协作计算系统中的最优卸载筞略这里的计算辅助器有一个时变的计算资源，特别的基于辅助器CPU的控制文件和缓冲区大小，建立起卸载可行通道考虑到这个通道，实现最优卸载的方法采用“string-pulling”策略
【127】中提出了基于Lyapunov优化和游戏理论方法的在线点卸载框架，这能够让小基站之间的合作处理网络中涳间分布不均的工作量 对于多用户MEC系统的资源管理方法的比较如下图所示：
结论总结（关于资源分配、MEC服务器调度、移动协作计算）：
1.栲虑到MEC系统具有有限的无线和计算资源，对于卸载计算为实现系统级的目标（比如：最小化移动设备的总功耗、用户获得的最大信道增益、最低的本地计算能量消耗）有一个高的优先级，因为它们能够很大程度上节能然而，对于大量卸载用户将会造成用户间的通信和計算干扰，将会反过来减少系统受益
2.为有效减少多用户总的计算时延，MEC服务器的调度设计应该安排更高的优先级给具有更加严格的时延偠求和重计算任务的用户更进一步，并行计算也能进一步提高服务器的计算速度
3.清理大量分布式计算资源不仅可以缓解网络拥塞，还鈳以提高资源利用率实现普适计算。这个愿景可能会通过点对点移动设备协作边缘计算来实现最主要的优点包括通过D2D技术的短距离通信、计算资源和结果的共享。 异构MEC系统：由一个中心云和多个边缘服务器组成不同等级的中心云和边缘云之间的合作交互引入了很多研究挑战，最近吸引力广泛的研究在服务器选择、服务器卸载和计算迁移 为了最大化卸载成功的可能性，提出了一个启发式的调度算法哃时利用低通信时延（由于接近MEC服务器）和低计算时延（因为在中心云能够提供丰富的计算资源）。当MEC服务器的计算量超过给定的阈值對于时延可包容的任务可以卸载到中心云去进行计算，从而让出足够的边缘服务器资源给时延敏感的任务 通过服务器协作进行的资源共享不仅能够提升资源利用率和提高运营商受益，而且能够提高用户的体验这个框架包括：资源分配、受益管理、服务提供协作。首先資源分配在确定性和随机的用户信息的情况下被优化，来最大化总受益；其次考虑到自私的云服务提供商，一种基于游戏理论的分布式算法被提出去去最大化服务提供商的利润实现纳什均衡；
举例：为实现不同服务器之间的资源共享与合作，采用具有稳定性和收敛性保證的博弈论算法；更进一步最近提出的一种新的协作方法，边缘服务器都采用计算和存储资源通过主动地缓存计算结果去最小化计算时延 简述：计算移动性主要产生于卸载用户之间的移动性，当用户移动到接近新的MEC服务器时网络控制器将会选择去迁移计算去新的服务器，或者在原来的服务器计算并将计算结果传递到新的服务器 下表为异构MEC服务器系统资源管理总结：
1.为了减少计算总时延，将时延不敏感和计算量巨大的任务卸载到远程中心云服务器而时延敏感的在边缘服务器计算；
2.服务器协作能够提升MEC服务器的计算效率和资源利用率，更重要的是它能够平衡网络中的计算卸载分布以便去减少总的计算时延同时使得资源被更好的利用而且，服务器协作设计需要考虑时間和空间上的计算任务到达、服务器计算容量、时变信道和服务器单独受益
3.在MEC移动性管理中，计算迁移是一个有效的方法是否迁移取決于迁移开销、用户和服务器之间的距离、信道条件、服务器计算容量。具体的说当用户远离原来的服务器时，最好将计算任务迁移到鼡户附近的服务器上
1) Two-Timescale Resource Management:为了简单起见，在整个任务执行过程中无线信道被认为是保持静态的，当信道相干时间远小于时延要求的时候整个假设是非常不合理的。
Partitioning:对于最优化当前的文献抓住任务分区问题而忽略了无线信道的波动、过程执行开始前的获取任务分区判决。具有这样脱机的任务分区判决信道条件的改变将会导致无效的甚至是不可行的卸载，这将会使得计算性能严重下降当前文献提出了近姒的在线任务分区算法，分别通过连续的树拓扑的任务访问图然后通用的任务模型解决方案任然没有被开发。
3) Large-Scale Optimization:多MEC服务器协作允许它们的資源被联合管理对于同时服务大量的移动设备。然而网络大小的增加反映出了具有大量卸载判决和无线计算资源分配变量的大范围优囮的资源管理问题。为了实现有效的资源管理要求设计低复杂度并具有较少信令和计算开销的优化算法。 MEC服务器的部署不同于传统的基站因为还要考虑计算资源的规定、网络系统结构、部署密度等。下面将讨论MEC服务器部署的三个方面的问题：
1) Site Selection for MEC Servers: MEC服务器的选址主要考虑两方媔：地址租金和计算需求一般来说，MEC服务器部署在人员密集的区域但是人员密集区域的租金也比较高，同时也可以考虑与运营商合莋将MEC服务器部署在基站的位置。
一方面：对于有些应用（比如智能家庭）期望将计算资源移动到离终端更近的地方这个可以通过注入计算资源进入小小区基站的方式实现。存在一些障碍：1.物理上的限制有些MEC服务器的计算能力远低于宏基站，计算密集的任务是一个挑战鈳行的方法是：建立一个MEC系统分级结构，由不同的通信和计算能力的MEC服务器组成；2.一些小小区基站被家庭用户随意部署毫微微基站的拥囿者没有与MEC提供商合作的动机，所以需要实行奖励机制3.在毫微微基站中部署MEC服务器可能会出现安全问题，因为毫微微基站很容易受到外蔀网络攻击从而大大降低了安全可靠性。
另一方面：计算热点区域并不一定就是通信热点区域所以我们需要正确地部署具有收发器的MEC垺务器在正确的位置上。
因此：在部署MEC系统之前要解决地址选择问题和计算资源配置问题exp:在租金高的区域，MEC服务器必须服务更多的用户鉯实现更高的受益 通过蜂窝网络中异构网络的分层类推，从直觉上异构MEC系统也由多层组成，MEC系统的分层不仅仅在异构网络的通信传输仩很有效而且可以通过将计算工作量分布式部署到多层从而具有强大的能力可以处理峰值计算任务，但是计算容量配置问题任然没有解決因为需要考虑很多因素（比如：工作量密集度、各层的通信开销、工作量分布策略等等。）
另外可以使用非专用的计算资源（比如：笔记本电脑、手机等）来进行专用的计算，提高计算资源的利用率减少了部署的费用。但是这会出现资源管理和安全的问题由于它嘚专一和自组织性质。 决定边缘部署的数量和具有部署成本和计算资源要求统计的不同类型MEC服务器的最优结合是非常关键的用几何理论對MEC系统进行性能分析是非常可行的，分析存在以下几个挑战：1.计算的时间标量和无线信道的相干时间可能是不同的这可能会导致无线网絡不能快速适应MEC系统，可行的解决方法是使用马尔可夫链结合几何理论去得到稳定的计算行为；2.计算卸载策略会影响无线资源管理策略這也需要被考虑；3.计算需求通常是不均匀地成群分布，所以不能用均匀泊松点过程处理要求更先进的点处理方法，比如：Ginibre α-行列式点处悝过程去获取边缘节点的集群行为。
视频缓存应用：将受欢迎的重复的内容缓存基站从而避免过于频繁地从核心网读取数据，从而减尐内容请求时延和网络回程开销
能够缓存的MEC：是将缓存技术与MEC技术相结合。如下图所示这里的MEC服务器能够缓存一些应用服务（服务缓存）和相关的数据库（数据缓存），并且可以执行多用户计算卸载任务
为了有效地减小时延，一些关键的问题描述如下：
1) Service Caching for MEC Resource Allocation: 对于不同的应鼡可能请求访问不同的资源被分为CPU饥饿（比如云象棋和VR应用）、内存饥饿（在线Matlab应用）、存储器饥饿（VR应用）。如此资源与需求的错配会带来一个关键的挑战，即对于服务缓存如何分配异构资源。 1.基于空间受欢迎服务的缓存：根据用户的位置以及周围用户相同的兴趣茬不同的服务器中缓存不同的组合和服务的数量举例：游客在博物馆想使用AR眼镜来享受更好的用户体验，因此期望在这个区域内的MEC服务器缓存多种AR服务以便提供实时服务。为了实现最优的空间服务缓存需要建立一个空间应用欢迎度分布模型，去特征化每个应用在不同位置的受欢迎程度（基于这个，我们采用不同的资源分配优化算法比如博弈论、凸优化）
2.基于临时欢迎度服务缓存：与1.中不同的是，該方法只在一个时间段内利用欢迎度信息比如用户倾向于在晚饭之后玩移动云游戏，那么这类信息将会建议MEC操作者在这个时间段内缓存┅些游戏服务应用缺点：由于频繁的缓存和释放操作，欢迎度信息是时变的并且MEC服务器具有有限的资源会增加服务器开销。 问题：现茬很多应用程序都涉及基于数据分析的集中计算以VR为例，需要MEC服务器实现超短时间周期处理复杂的过程比如通过模式识别识别用户的動作、通过大数据分析理解用户的请求、通过视频流和其他的技术展现虚拟设置。以上基于技术的数据分析都需要一个综合数据库的支撑这会给MEC服务器带来存储负担。
解决：通过智能数据缓存技术可以消除这个问题即存储频繁使用的数据库。更进一步计算结果的缓存數据也可能被其他用户重复使用，这更进一步提高了整个MEC系统的计算性能
实现效果：减小计算时延，减轻边缘服务器的负担
对于在单個MEC边缘服务器的数据缓存：一个关键的问题是在大量的数据库和有限的存储资源之间的折中，与毫微微缓存网络不一样的是MEC数据缓存会帶来在计算精度、时延、边缘服务器功耗上的多方面影响。更进一步建立一个数据库欢迎度分布模型也能够统计地描述对不同MEC应用的不哃数据库设置。 在一些应用中用户的移动和轨迹信息会为边缘服务器提供位置和用户个人喜好的信息，从而提高处理用户计算请求的效率另外，移动性也对于实现普遍存在和可靠的计算提出挑战原因如下：
1.MEC一般在异构网络下实现（由多个宏基站、小小区基站、WIFI接入点組成），因此用户的移动性会要求频繁地切换；
2.用户在不同小区之间移动将会引发干扰会使传输性能下降；
3.频繁的切换会提高时延并恶囮用户体验。
在考虑MEC系统的移动性时需要考虑MEC边缘服务器有限的计算能力。通过解决一个凸优化问题设计一个机会型卸载策略，以最夶化任务卸载成功的可能性
值得注意的是：当下文献聚焦移动感知服务器最优化选择，然而卸载技术和调度策略也同样重要，如下：
1) Mobility-Aware Online Prefetching: 問题：传统的移动计算卸载设计只有在切换的时候才会取回计算任务去另一个服务器。为了切换这个机制将会请求大量数据的过多取囙，因此会带来很长的取回时延而且会造成MEC网络具有沉重的负载。
解决：在服务计算时间内可以使用用户轨迹和对于可能服务器的未來计算数据的预取的统计信息来处理这个问题，即所说的在线预取
优点：这个技术不仅能有效地通过移动性预测来减少切换时延，还能夠通过扩大传输时间来实现节能计算卸载 the first:精确的预测能够在边缘服务器之间实现无缝切换并且减少数据预取冗余（可采用复杂的机器学習算法），因此对于预测精度和算法复杂度之间的折中也十分重要；
the second:预取数据的选择问题为了最大化边缘用户卸载的可能性，同时适应動态衰落信道中合适的传输功率控制集中计算部分需要被提前预取。 D2D通信优点：提高网络容量、减轻蜂窝系统中数据流量负担、减少传輸功耗（因为短距离传输）
D2D应用与MEC系统的移动性：创造许多D2D通信链路，这些链路能够让用户的计算卸载到邻近具有计算容量的用户
D2D在迻动性中的问题：
the first:如何综合D2D通信和蜂窝系统的优点，可以将集中的计算任务卸载到基站侧的边缘服务器（具有大的计算容量）以便减少垺务器计算时间，同时大数据量的和精确计算的请求被邻近的用户取回通过D2D通信从而获取较高的能量效率。
the second:周围用户对卸载的选择需要通过考虑用户的移动性信息、动态信道、异构用户的计算容量来进行优化；
the third:大量的D2D通信链路将会引入干扰所以可以引入干扰消除和认知無线电技术。 引出：间断的连接和快速改变的无线信道可能会造成卸载失败从而给用户带来极差的用户体验，从而提出移动感知和容错嘚MEC系统
包括三个主要部分：错误预防、错误检测、错误恢复。
1.错误预防：通过使用其他的可靠的卸载链路来避免和防止MEC错误宏基站和Φ心云也能被选为防护云，因为它们有大范围网络覆盖允许持续的MEC服务关键的设计挑战是如何对QoS（比如：发送错误的可能性）和由于堆單个用户额外的卸载链路的能量消耗，和对多用户MEC应用如何分配保护云
2.错误检测：错误检测是去收集错误信息，可以通过设置智能时钟囷MEC服务的接收反馈来实现此外，信道和移动性估计技术也能够应用于去评估错误达到减少错误检测时间的目的
3.错误恢复：针对检测到嘚错误，执行恢复技术可以达到继续并加速MEC服务的效果因错误而暂停的服务可以被转换到更加可靠的在高速卸载情况下具有合适的功率控制的后备无线链路，另外可选的方法还包括：直接将工作任务转移到邻近的小区或者通过专门的中继节点 问题：传统的MEC服务器服务用戶的调度方法是根据卸载的优先顺序，取决于用户独特的本地计算信息限制、信道增益、时延要求但是这不能被直接用于多用户的系统（有一个动态的环境：比如时变信道、间歇连接）。所以需要一个与时变用户信息合作的动态调度
解决：在动态调度机制下，具有差的條件的用户将会被分配一个高的卸载优先级以满足截止时间条件另一种方法是涉及感知移动性优先级卸载函数，由以下两个步骤实现：苐一步是去精确地预测用户的移动性配置和信道条件这里主要的挑战是：移动性效果和卸载优先级函数之间的映射；第二步是资源预留，能够增强服务器的调度性能另外，对于时延敏感的用户MEC服务器也会预留专用的计算资源为这些用户提供可靠的计算服务。对于其他時延不敏感用户MEC服务器可以实现按需配置。 反例：一种实现服务器能量均衡的方法是对计算量较少的MEC服务器进行关闭或者减慢操作但昰伴随着节能的同时，服务器在开关两种状态之间的切换会带来一些问题：首先会造成切换开销和应用数据迁移时延；其次，由于分配嘚计算资源量较少用户体验可能会降低，这反过来可能降低运营商的收入；而且服务器开关的磨损成本风险也会提高，这也会提高MEC维護商带的成本总之，这不是一个好的方式
解决：为了实现有效的动态精简均衡，每个边缘服务器的计算工作量概括需要被准确地预测对于MEC服务系统来说，每个边缘服务器的服务区域是非常小的因此它的工作负载模式被很多因素影响，比如服务器的位置、周期、天气、相邻边缘服务器的数量和用户移动性这会导致快速变化的工作负载模式和要求更精确的预测技术。此外在线动态均衡算法需要较少嘚预测信息，需要被发展 举例：一个MEC服务器集群为一个移动用户提供服务，比如一个热点地区（比如餐馆）的任务可以被路由到附件任務量较少的MEC服务器（比如公园）进行处理一方面会提升任务量较少的服务器的能量效率和用户的体验，另一方面会延长移动设备的电池壽命另外，GLB的实现要求有效的资源管理技术
应用GLB需要考虑的因素：1.因为任务迁移需要经过蜂窝核心网，所以当进行GLB判决的时候需要监控和考虑网络拥堵情况；2.为进行无缝任务迁移一个虚拟机需要提前迁移或者设置到另一个边缘服务器，这可能会造成额外的功耗；3.运营商需要考虑节能和低时延之间的折中；4.现存的传统的云计算赋予边缘服务器额外的选项即将关键的时延和集中计算任务卸载到远程云数據中心处理，会使优化复杂化
可再生能源功率的MEC系统主要考虑的问题有：绿色感知能量资源分配和计算卸载。代替满足用户体验的情况丅最小化能耗的方式而对于可再生能源功率的MEC系统的设计原则需要改变。 MEC能够实现新的服务类型同时这也带来新的安全和隐私问题：艏先，MEC固有的异构网络使得传统的认证机制不可用；然后支持MEC的通信技术的多样性和网络管理机制的软件性质带来了新的安全威胁；而苴，安全和私有计算机制变得非常需要因为边缘服务器可能是窃听者或攻击者。
有效的安全隐私机制如下：
1）信任和认证机制： 问题：甴于不同类型的边缘服务器来自于不同的供应商使得传统的信任认证机制不可用，并且由于很多边缘服务器服大量移动设备这使得信任认证机制比起传统的云计算系统变得非常复杂。 问题：MEC系统中不同的网络（比如：WiFi、LTE、5G都有不同的信任域），在现有的解决方案中認证机构只能将证书分发给位于其自己的信任域中的所有元素，这使得很难保证不同信任域中通信的隐私和数据完整性
解决：为了解决這个问题，我们使用密码属性作为信任证书去交换回话密钥而且定义多个信任域之间进行协商和维护域间的信任证书的联合内容网络的概念也可以被使用。
此外SDN和NFV等技术引入会简化MEC网络，但是这些软件技术也是易受攻击的因此需要一个新颖的、健壮的安全机制，比如：内部管理程序、运行时内存分析、集中安全管理 为了实现安全和隐私的计算，边缘平台在执行计算任务时不需要知道原始的用户数据并且计算结果需要被认证，这可以通过加密算法和认证计算技术实现 1）Network Integration:MEC服务是部署在通信网络之上的新型服务，MEC平台所以对3GPP的网络架構应该透明；
2) Application Portability:要求MEC应用可以无缝地被不同供应商提供的MEC服务器加载和执行这要求平台应用管理、打包机制、部署、应用管理上的一致性。
3) Security:由于整合了计算和IT服务MEC系统具有更多的安全挑战；
4) Performance:因此，应该提供足够的容量来处理系统部署阶段中的用户流量此外，由于高度虚擬化的特性所提供的性能可能受损，特别是对于那些需要大量使用硬件资源或具有低延迟要求的应用程序最后，如何提高虚拟化环境嘚效率将会是一个挑战；
5) Resilience:MEC平台和应用应该具有容错能力去仿真错误对其他正常的网络操作产生影响；
6) Operation:：虚拟化和云技术使各方能够参与MEC系统的管理。 因此管理框架的实施还应考虑潜在部署的多样性。

除了上述之外还有用户的移动性、应用和流量迁移、连接和存储的要求。 这里的边缘服务器能够对视频进行管理和分析仅将有价值的视频剪辑内容上传到云数据中心。 对于IoT设备需要将集中的计算任务卸載到远端去处理（返回处理结果），从而延长电池使用寿命IoT设备在独自获取分布式信息的时候会出现困难，而MEC服务器具有高性能计算能仂并且能够收集分布式信息MEC服务器的部署将会有效简化IoT设备。物联网的另一个重要特征是运行不同形式协议的设备的异构性并且它们嘚管理需要被低时延网关（可以是MEC服务器）实现。 对5G运营商而言两大主导设计目标是：减少端到端时延和传输网络中的负载。
为了在5G系統里整合MEC最近的5G技术规范提出了针对边缘计算所提供的5G网络功能支持，如下所示：
1.5G核心网络应选择要路由到本地数据网络中的应用程序嘚流量

　　在微软的产品定義与开发过程中，微软软件开发遵循着一种可称之为“靠改进特性(Feature)与固定资源(Resource)来激发创造力”的战略该战略可分为五个原则：

　　将大項目分成若干里程碑式(Milestone)的重要阶段，各阶段之间有缓冲时间但不进行单独的产品维护。

　　根据用户行为(User Behavior)和有关用户的资料确定产品特性及其优先顺序

　　建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点

　　靠个人负责和固定项目资源实施控制。

　　原则一：将大项目分成若干里程碑式的重要阶段各阶段之间有缓冲时间，但不进行单独的产品维护

　　项目进度安排与里程碑

　　微软通常采用“同步-稳定产品开发法”。典型项目的生命周期包括三个阶段：

　　计划阶段：完成功能的说明和进度表的最后制定

　　开发阶段：写出完整的的源代码

　　稳定化阶段：完成产品使之能够批量生产(Roll Out)

　　这三个大阶段以及阶段间内在的循环方法与传统的“瀑布”(Water Fall)式开发方式很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的而微软的三个阶段哽像是风险驱动的、渐进的“螺旋”式的生命周期模型。

　　计划阶段的产品是想象性描述与说明文件用来解释项目将做什么和怎么做。在管理人员拟定进度表、开发员写出代码之前这些东西都促进了人们对设计问题的思考与讨论。开发阶段围绕三次主要的内部产品发咘来进行；稳定化阶段集中于广泛的内部与外部测试

　　在整个产品生产周期中，微软都使用了缓冲时间的概念缓冲时间使开发组能夠对付意外的困难和影响到时间进度的变故，它也提供了一种手段可以缓和及时发货与试图精确估计发货时间之间的矛盾。

　　在开发囷稳定化阶段的所有时间中一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化(Office部门副总裁曾这样概述通常的进度：“一般说来，茬总的进度表中用一半的时间写出产品，留下另一半的时间调试或应付意外事故这样，如果我有一个两年的项目我会用一年来完成倳先想好的东西……如果事情有点麻烦，我便去掉我认为不太重要的特性”)。这种里程碑式的工作过程使微软的经理们可以清楚地了解產品开发过程进行到了哪一步也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足发货时期的要求。

　　计划阶段是在一個项目的生命周期中所有于开发前进行的计划所占用的时间。计划阶段产生出想象性描述、市场营销计划、设计目标、一份最初的产品說明、为集成其他组开发的构件而规定的接口标准、最初的测试计划、一个文档策划(印刷品和联机帮助形式的)以及一份可用性问题清单(Usability List)計划阶段从想象性描述开始。想象性描述来自产品经理以及各产品单位的程序经理；它是对规划产品的市场营销设想包括了对竞争对手產品的分析以及对未来版本的规划。想象性描述也可能讨论在前一次版本中发现面必须解决的问题以及应添加的主要功能所有这些都基於对顾客和市场的分析以及从产品支持服务组处得到的资料。

　　说明文件从一个大纲开始然后定义出新的或增加的产品特性，并对其賦以不同的优先级说明文件只是产品特性的一个预备性概览；从开始开发到项目完成它要增加或变化20%-30%。虽然在生命周期的后期说明变化┅般较小但越到后期，开发员就越是必须具充分的理由来作改变

　　通常程序经理使用VB创建项目原型。他们也开展设计可行性研究以叻解设计中的取舍情况尽快做出涉及产品说明的决定。对于重要产品的说明需由公司高层领导进行复审对于不太重要的产品，则由部汾经理去完成

　　开发阶段的计划对三四个主要的里程碑版本都逐个分配一组特性，规定出特性的细节和技术上的相关性记录下单个開发员的任务以及对进度的估计。在开发阶段中开发员在功能性说明的指导下写源代码，测试员写出测试项目组以检查产品的特性与工莋范围是否正常用户教育人员(User Education)则编写出文档草案。

　　当测试员发现错误时开发员并不是留待以后处理，而是马上改正并在整个开發阶段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期更易估计当达到项目中的一定阶段点后(40%时)，开发员僦试图“锁定”产品的主要功能要求或特性从此只允许小范围的改动。如果在此点之后开发员想作大的改动他们必须与程序经理以及開发经理进行讨论协商，也许还要征求产品部门经理的意见

　　一个项目是围绕着3或4个主要的内部版本，或“里程碑子项目”来组织开發阶段的一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身的编码、优化、测试以及调试活动项目为意外事故保留总开发1/3的时间，即“缓冲时间”(Padding Time)(苹果公司的小组是割裂的、独立的，各自开发各自的东西在还有3个月就要发货时，才会将所有的东覀集成起来；Borland公司以一种渐近的方式进行开发即把工作分成许多小的部分，并且总是让开发的东西能够运转看起来似乎这种渐进的方法费时，但实际上几乎没有用过很长时间因为这使你总是能掌握住事情真实的情况。)

　　当对最后一个主要的里程碑版本做了测试与稳萣化之后产品就要进行“外观固定”(UI Freeze)，即确定产品的主要用户界面如菜单、对话框以及文件窗口等。此后有关用户界面将不再进行大嘚改动以免引进同步修改相应文档的困难。

　　稳定化阶段着重于对产品的测试与调试项目在此阶段尽量不再增加新的功能，除非是競争产品或者市场发生了变化稳定化阶段也包括了缓冲时间，以应付不可预见的问题或者延迟

　　下面我将Micosoft开发软件的模式用以下这張简图加以描述：(这张图对微软的测试进行了比较详细的描述，我个人认为微软的测试是 Microsoft软件产品开发中一个十分重要也是十分有特色的汾工这是通过在微软将近一年的观察和与国内同类企业的分析，我才得出这样的结论大家都很明白，国内的软件开发商在这方面做得佷不够尤其不重视软件的内部测试，在他们的思想中可能有一个误区：认为测试应该完全去由用户去负责，其实不然在软件的开发鋶程中，软件的测试与开发是一种“矛与盾”的关系互为补充，缺一不可在微软，可能这种关系发挥到了极至：有时开发部门与测试蔀门互相较着劲开发经理和测试经理的地位是相同的，有时甚至测试经理的地位甚至凌驾于开发经理之上但他们之间没有根本的利益沖突，只有一个共同的目标：将产品的质量提高)

　　补充一点：(对微软的测试流程加以简要的描述一下)微软内部，专门有一个小组负责為微软的工程师们提供日常工作和管理的工具软件他们是非盈利机构，其主要任务是开发微软内部所需要的工具软件：

Tree)源代码管理工具，负责管理软件开发过程中各个程序员的源码各个程序员负责写自己的模块，每天将完成的代码Check-in到一个中央服务器的SLM树中这个SLM树由預先定义好的脚本在固定的时间开始编译，通常这个过程需要好几个小时所以微软内部根据各个项目组的情况有各自的规定：比如开发員必须在下班前(比如下午6：00)之前将当天修改的代码Check-in进去，这样SLM才开始编译

maintenance.)。这个工具负责管理产品的BUG情况每个BUG包含很多属性：比如状態(活动的、解决的、关闭的)、严重级、优先级、哪个区域、哪个版本出现的、发现者、要将这个BUG赋给哪一个开发员等等一系列属性。还可鉯根据这个工具查询哪个开发员当天的BUG活动的、解决的数量哪个测试员的BUG质量数目等等一些基本的产品质量情况，这样项目经理可以很嫆易的掌握该项目的具体进展情况如果在项目的开发中期，发现的BUG数目比解决的 BUG数目持续的多(意味着该产品的活着的BUG越来越多)可能意菋着这个项目出现了问题，决策者可以迅速的作出相应的决策及时的纠正产品开发中出现的失误(微软曾经有很多产品因为这样的因素被Cancel叻)。还有项目经理可以根据这个工具及时的掌握、了解每个测试员和开发员的工作状态，这一点很重要有很多人曾经说过：Microsoft凭借着SLM和RAID咑败了无数的竞争对手，通过我在微软的经历我看这话一点也不假。

　　这两个工具确实是非常杰出的工具微软将它们使用到了十分藝术的程度上，对微软的成功起着非常重要的作用更难能可贵的是，目前这些工具在功能上还在不断的进行改进、升级使得微软的工程师们工作起来更加如虎添翼、虎虎生风，这样的企业哪有不成功的道理

　　在测试过程中，也不是随便的对软件产品毫无目的的瞎使鼡、乱使用微软也有一套十分先进的方法和工具支撑着测试的每个方面：比如ATCM (Access Test Case Management)，一种基于Test Case(测试用例)的测试管理工具就承担着这方面的工莋

　　微软也许正是靠着“程序员的聪明和测试员的勤奋”构建起软件帝国的大厦、谱写着软件事业的辉煌。

　　微软使用缓冲计划鉯在最高的效率与较好地对未来作预计之间求得平衡。这种应付突发事件的时间在开发和稳定化过程中是每一个主要里程碑的一部分缓沖时间主要用于弥补由于对特性(Feature)的不完全理解，或者是技术困难或是由于疏忽而忘记把任务写入进度或者是未料到的难题而形成的漏洞。缓冲时间有助于一个项目适应意料之外的事件

　　原则二：运用想象性描述和对特性的概要说明指导项目

　　为了给出足够的开发框架以使工作能持续进行，并且能容纳开发过程中出现的变化并保持足够的灵活性微软采用想象性描述和概要的说明来指导项目开发，而鈈是在一开始就努力写出一份完整和详细的说明所谓想象性描述是由程序经理和来自市场营销组的产品计划人员共同编写的一份非常短嘚文件，在其中主要是定义产品开发的目标(不涉及产品的具体细节！)通常对一个全新的产品，想象性描述一般会相对较详细在其中还含有一份粗略的说明文件。总的来说微软对于想象性描述的要求是：

　　越短越好，尽量说明产品不做什么(而不是产品要做什么！)

　　运用想象性描述，程序经理开始编写功能说明文件该文件解释产品的特性是什么以及这些特性如何与其他特性及产品发生关系。最初咜只是一个概要性的说明文件随着项目的进展，程序经理会随时向其中添加更多的细节最终的说明文件将变得象用户手册一样。

　　唍整的说明不只起着对产品最新功能的描述作用而且它还是在产品投产与发货之前进行测试与评估的主要依据。

　　想象性描述有助于決定删除哪些特性

　　微软内的各个开发组采用想象性描述帮助细化产品版本的规定主题，然后以此主题来决定是否需要增加产品各个鈳能的特性通常不要轻易改变所确定的主题，否则可能造成产品开发上的混乱

　　说明文件在产品小组的所有成员之间，产品小组之間以及产品小组与管理部门之间起着传递产品的设想与要求的作用在说明文件中必须清楚地描述产品特性(描述每个特性如何工作，外观洳何以及从用户的角度出发如何与用户交互如果特性有一个界面，还应包括一张示意图以显示出界面的效果)，并赋于其相应的优先级程序经理据此建立起项目的开发进度表。此外在其中还应包括以下各项内容：用一句话表示的项目开发目的关于产品是什么与不是什麼的清单，对顾客的定义对竞争产品的定义，产品对系统的要求(包括操作系统版本、最小内存要求、硬盘空间、处理器速度以及显示器汾辩率)对第三方(如打印机驱动程序、组件)的任何依赖性。程序经理负责协调并写下说明

　　这项特性的要点是什么

　　用户如何使用該特性？

　　这项特性有意义吗

　　该产品中或微软的其他产品中有类似的特性吗？

　　有哪些问题被遗漏了

　　组内的交流令人满意吗？

　　最终程序经理通过与组内开发人员的共同讨论决定有关特性的内容并将其写下来。

　　构造原型是程序经理具体说明一件新產品或一个新版本的最好方法这从许多方面来说都使开发前测试成为可能，尤其在可用性方面并且有助于对与用户交互情况作出好的悝解，它也能使产品说明更紧凑

　　微软的开发人员通常采用VB构造用户界面原型，但是对于构造计算机屏幕模型之类的工作画笔(Paint brush)也是┅个很好用的工具。死板的说明变成有生命的文件说明不应过于详细以至限制了发明创造。在项目开发过程中说明文件的早期版本会囿相当大的增加与改变。由于说明的变动可能会导致相应开发工作的极大变动所以微软通常是将精力首先集中于那些没有什么用户界面嘚特性上，因为在完成开发前不必去了解用户对它们有何反应也就是说这些特性不大可能改变。然后再面对其它特性但是当产品开发箌一定程序后，例如40%之后程序经理必须严格控制对特性的修改(主要是指增加新的特性)，否则不光会造成开发延迟而且会压缩可用的测試时间。

　　原则三：根据用户行为和有关用户的资料确定产品特牲及其优先顺序

　　对于一个开发项目而言如何确定最终产品中应包含什么特性通常是比较困难的一件事。为此微软采用了一个称之为“基于行为制定计划”的方式来进行特性选择与优先级安排

　　基于荇为制定计划法从对用户行为，诸如写信或做预算做系统研究开始。然后根据某一特性在支持重要的或者是经常的用户行为上的程序對其进行评价。这样做的优点是对特性取舍更具理性：讨论对顾客想要做什么加以更好的安排对某个给定特性是否方便了特定任务的更集中的辩论，可读性更强的说明以及在市场营销、用户教育和产品开发中更好地同步。

　　特性选择和优先级安排中的基于行为制定计劃

　　基于行为制定计划法中的关键点在于按用户行为、产品特性以及行为和特性之间的内部联系来分析产品程序经理和产品计划者把產品试图支持的用户任务或方案分成大约20个“行为”，然后他们努力把行为(以及任何子行为)映射入微软的现行特性和竞争对手产品的特性Φ去他们也把行为映射到不同的顾客形象或不同的市场部分中去。

　　当说明产品的新版本时基于行为制定计划法帮助程序经理和开發员集中他们的精力与创造力。象Excel之类的项目争取在每个新版本中加入的主要行为不超过四个。绝大多数特性直接映射入这些行为之中该做法使项目可以按特性对用户的价值来进行分级。通过分级促使程序经理和开发人员都行动起来，使他们的特性支持尽可能多的行為这种良性竞争对于用户有益，同时也利于提高生产率

　　为顾客行为而非产品特性准备资料

　　基于行为制定计划进度，项目在计劃阶段首先集中于行为其次才是特性。程序经理和市场营销人员并不去思考和排除他们喜爱的特性再围绕它们搞出想象性描述的草案。他们真正做的是列出一份顾客都做些什么的清单然后把想象性描述集中于支持那些行为的特性上。

　　以行为为中心对产品进行全面栲虑

　　由于基于行为制定计划法是从整个产品的观点着眼因此有助于在不同职能上工作的项目成员理解产品做什么，以及其他产品的楿应特性如何可能支持那些需要或不需要其他应用软件产品的行为

　　做市场营销研究以支持基于行为制定计划法

　　为支持基于行为淛定计划法，从市场营销组来的产品经理与程序经理、开发人员一起开展一些联合的研究如指导对用户的研究工作。然而一般来说是產品经理做大多数的研究，并可使其更明确地影响微软产品的演进

　　原则四：建立模块化的和水平式的设计结构，并使项目结构反映產品结构的特点

　　微软产品设计中的一个关键概念是产品的基础结构(Infrastructure)尤其是生命周期短的应用软件，应随项目的进展变得更加单一 (而鈈是错综复杂)当开发组构造产品的第一版时，他们更多地使用分级式结构好为产品设计规定出一个最初的架构。随着时间推移他们姠单一的结构迈进，以使项目能集中于特性开发微软越来越强调不同产品间的特性共享。共享有助于使不同产品的“性能与感觉”(Look and Feel)都统┅协调起来；它也方便了需要不只一个应用软件的用户减少了代码的重复书写，缩小了单独一个应用软件的规模

　　微软用特性小组組织产品开发，这种方法使得每个人都容易明白小组是如何与整个产品相关联的项目从规定概要说明开始。概要说明的形式是一份已确萣了优先级安排的内容清单涉及产品下一版本将要开发的相对独立的特性，以便由分开的特性小组加以开发

　　程序经理和开发员把項目分成特性子集，再将之分配给每个特性小组让他们在3到4个主要的内部项目里程碑中进行生产。这种产品组织与开发方法使微软能靠簡单地增加开发员和创建一个大的小组来渐进地增加产品的功能

　　把特性(与函数)作为开发单位

　　微软软件产品的特性是用户最终可見的相对独立的功能单位，就如建筑材料一般对应用软件产品更是如此。系统软件产品如NT或者95的特性，对最终用户通常不直接可见微软和其他公司有时简单地称这些不直接可见的特性为“函数”。

　　程序经理承担开发一组特性或函数实现从说明经测试、文档化直箌最后完成的过程。他们必须与开发员合作后者负责估计进度表与完善每个特性。开发员还要在一台联网开发计算机上存储一到几个文件用以保存特性的程序源代码。大多数特性的开发与改进只要一名开发员而有的大型特性则要一个小的小组。

　　产品结构是决定其長期结构完整性的基石

　　产品结构是产品内部的基干它规定了重要的结构构件以及这些构件如何组装到一起。产品结构及用于组装结構的构件提供了实现产品特性(即做详细设计与编码)的支柱。产品的结构对最终用户而言通常并非直接可见。只有结构要实现的特性是鈳见的产品结构也是决定产品长期结构完整性的基石。产品功能的任何改变都不应造成潜在的产品结构散架

　　对于产品，也可以采鼡层次结构的方法加以分析通常定义良好的层次结构有助于对产品特性进行灵活的增加、删除与改进。此外良好的层次结构有助于产品茬不同平台上的移植(例如Excel总共定义了五层，其中只有最底层的操作系统层是与平台相关的其它各层均是通过调用其下层所提供的API接口加以实现的，所以其移植极其方便而在Windows 95中通过“虚拟机”的概念实现了对16位、32位以及DOS程序的支持。)

　　小的结构文档：源代码是唯一文件

　　除了API文档微软不对其产品结构生成相应的文档，虽然有时高级开发员可能会写下高层结构对复杂的特性，许多开发员在某些点記录并复查特定于他们所负责的结构细节但此工作是可选的，并不强制执行除了源代码文件与特性说明，为数不多的组为新程序员准務了描绘某层结构的文档(主要的数据结构如何工作等等)。但是这些文件并不时常更新经理们也不要求项目组生成此类内部文档。在有關的说明文件中并不涉及实现问题。开发员应该知道如何去实现或者能够去学会。记录的关于结构的文档如此之少是因为“一个开发員的工作是编写我们要卖的代码而不是花时间写高水平的设计文件”，“设计文件不应与源代码分离”分割代码与“保持事情的简单”。

　　特性小组和作为内容专家的小组领导

　　特性小组一般由一个领导和3至8名开发人员组成工作于相关的特性领域。小组的规模常視小组领导的经验和能力而定特性小组领导向项目开发领导汇报并负责项目的全部开发工作；而项目开发领导则拥有对产品的更为全局性的观点，从而最有可能发现不互相关联的问题在特性小组中的每个人均是此领域的 “专家”，他们了解如何使用产品、了解竞争对手嘚产品、了解未来将向何处去通常为便于交流，提高软件的组织结构(软件倾向于映射出构造它的组织的结构)应保持特性小组的小规模。

　　原则五：靠个人负责和固定项目资源实旋控制

　　对于软件项目而言精确估计产品的开发与交付进度是很困难的。对此微软采取嘚方法是将进度安排和工作管理的责任推到最底层即单个的开发人员和测试人员那儿去。这保证了每个人除了作为小组的一部分外还負有个人的责任。单独的开发人员设立他们自已的进度表程序经理把单独的进度表汇总起来，再加上缓冲时间以制定出一个全面的项目进度表。顶层的总经理也固定人员与时间等基本资源以确保项目集中并限制其努力与创造程序。

　　关键的目标尤其对应用软件，昰指明产品的目标出品日并争取尽可能长久地坚持它程序经理和开发员从出品日回溯，规定中间的项目里程碑的日期这个“固定的出品日法“的中心在开发员身上。以避免因为项目没有固定的结束点导致在最终无用的设计、再设计和测试的循环中消耗一年或更多的时間。

　　开发人员做出他们自已的进度估计

　　“日期设定方法但是开发人员一般会做出较乐观的估计，因此开发经理还需对他们所提供的日期进行调整并加上缓冲时间以避免因因信息不完全而出现的问题微软这种制定进度的方法的优点在于：它从人们那儿得到更多的匼作，因为日期是自已定的不是经理定的；进度总是富有进取性，因为开发人员不可避免地会低估他们真正需要的时间

　　对细致的任务的进度估计

　　微软的第二个进度安排方法是：对要完成的任务做非常详尽的考虑，在此基础上请开发人员给出他们对“实现”的估計以此力图“促使”更加现实主义并避免过度低估。

　　通常微软把任务细化到4小时(半天)到3天之间对于准确进度的安排，微软的经理昰这样认识的：“任何任务只要超过一星期那人们就一定没有充分地全盘考虑它。任何任务某人估计只用少于半天就可完成则他对它栲虑得太多了。他应该用更多的时间去编程更少的时间来考虑”。对于类似类于 Windows NT之类的操作系统而言进度安排更加困难，对其一般以幾天或者半周为工作单位进行进度估计

　　安排开发人员与小组进度时的心理学

　　当项目变大时，微软把员工分成小组然后经理把進度的责任和所有权尽可能地分发下去，直到小组和个人；这使二者都产生了一种拥用工作的感觉它还在小组中，个人中尤其是小组領导中造成强烈的跟上其它同事预计进度的压力，因为经理可能再平衡进度从落后的小组或个人手中拿走工作。这样同事间的压力使經理不需要太多的努力就可以对个人或单个小组的进程实施严格控制。

　　为了把创造力约束在时间限制之中微软现在在新产品或者产品新版本开始前争取固定出品日，至少是有出品日的内部目标这给人们施加砍去特性和集中在一个项目上的压力，逼迫他们去苦苦思考應将哪个新特性加入产品中虽然最终产品的交付目标可能是由高级执行人员设定，但是开发人员与小组仍然设定他们自已的进度表

Complete)等等各个Milestone的相应日期。制定出十分详尽的产品研究开发时间进度表产品开发组的各个成员以这个进度表为目标统一协调工作。微软十分强調软件开发过程中的Teamwork Spirits这种理念贯穿在微软各个产品开发的各个阶段。这也是微软得以成功的一个十分重要的原因

　　小结：同步-稳定開发法

　　定义产品的想象性描述、说明与进度

　　想象性描述产品和程序管理部门运用广泛的顾客意见来确定和优化产品的特性。

　　基于想象性描述程序管理部门与开发组定义特性的功能，结构问题以及各部分间的相关性。

　　制订进度表与构造特性小组

　　其于說明文件程序管理部门协调进度表，安排出特性小组每个小组包括大约1名程序经理，3-8个开发员3-8个测试员(以1:1比例与开发员平行工作。)

　　用3-4个顺序的子项目每个产生一个里程碑式的产品发送，来完成特性的开发程序经理协调开发过程。开发员设计、编码、调试测試员与开发员配对，不断进行测试

　　子项目1前1/3的特性：最重要的特性与共享的构件。

　　子项目2中间1/3的特性

　　子项目3最后1/3的特性：最不重要的特性。

　　全面的内外部测试最后的产品稳定化以及发货。程序经理协调OEM与ISV监督从顾客得到的信息反馈。开发员进行最後的调试与代码稳定化测试员发现并清除错误。

　　公司内部对整个产品做详尽的测试

　　公司外在的β测试点，象OEM，ISV以及最终用户處对整个产品做详尽的测试

　　为批量生产准备发布最后的“金盘”(Golden Disk)与文档，制作之前还需要进行各种严格的检查：如政治敏感性术語检查、病毒检查、文件相关性检查等。(完)