第一种方式：
APP采用原生开发方式展示所有页面。优点在于用户打开APP后，页面加载极快，因为所有展示页面在下载时就已存储在手机中。缺点是，一旦APP运行出现错误，技术团队无法通过后台直接修复，只能要求用户主动升级APP；而各应用商店审核周期不同，可能导致问题在线上长时间存在。

第二种方式：
非原生开发方式（H5展示方式），与原生方式不同，H5展示方式在用户下载APP后仅预装 登录、首页、个人中心等基础功能，其他页面如：服务页、记录查询等流程页面均在后台服务器加载。当用户进入服务页时，系统实时从服务器加载最新页面，确保信息及时更新。如果出现问题，技术团队可立即在后台修复，对用户来说几乎无感知。目前，主流APP均已采用这种成熟技术方式。

公司办公环境把windows更新给屏蔽了，导致远程桌面不能用。好像说因为加密连接时系统要去更新根证书，一直连不上。

解决办法：
1、先查看防火墙是否打开，是否去掉“仅允许运行使用网络级别身份验证的远程计算机…”
2、如果还是不行的话。便需要开启组策略中远程桌面链接安全层（在服务器端操作）：
（1）开始-运行-gpedit.msc，进入组策略编辑器。
（2）在左侧边栏中展开，计算机配置-管理模板-Windows组件-远程桌面服务-远程桌面会话主机-安全，修改以下两项。
* 第一，远程（RDP）连接要求使用指定的安全层，改为启用，安全层选择RDP。
* 第二，要求使用网络级别的身份验证对远程连接的用户进行身份验证，改为禁用。
（3）关闭组策略编辑器，重启即可。

1、edge浏览器打开一个默认页面
2、点击搜索栏
3、选择“管理搜索历史记录”
4、选中所有记录，点“清除”
5、登录microsoft账号

邮件链接跳转并自动登录的实现原理主要基于两种常见的技术：一是浏览器的自动登录，二是第三方平台的SDK回调。

在浏览器自动登录方面，用户在首次登录成功后，浏览器或服务器会在一定时间内保存用户的登录状态。即使用户关闭了浏览器或服务器重启，只要在这段时间内，用户重新打开浏览器或再次访问接口数据，都不需要重新登录。具体的实现方式可以使用Spring Security的配置来添加记住我功能，即只需要添加.rememberMe()即可实现自动登录。

对于第三方平台如QQ的自动登录，当用户点击第三方登录时，会跳转到第三方登录SDK内部；用户输入第三方登录用户名或密码后，有些第三方登录平台可以直接调用已经登录的账号完成第三方平台登录。登录完成后，第三方平台或SDK会回调我们的应用。具体的实战代码可参考Spring Security的配置示例。

系统分区：ESP分区，负责存放EFI引导文件
MSR分区：MSR保留分区
主分区：windows11系统主分区，系统就放在这里
恢复分区：RE恢复分区，负责存放系统恢复文件

案例分析：范围确认

A 公司刚刚和 M 签订了一份新的合同，合同的主要内容是处理公司以前为 M 开发的信息系统的升级工作。升级后的系统可以满足 M 公司新的业务流程和范围。

由于是一个现有系统的升级，项目经理老张特意请来了原系统的需求调研人员李工担任该项目的需求调研负责人。在李工的帮助下，很快地完成了需求开发的工作并进入设计与编码。

由于 M 公司的业务非常繁忙，其业务代表没有足够的时间投入到项目中，确认需求的工作一拖再拖。老张认为，双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。故老张并没有催促业务代表在需求说明书中签字。

进入编码阶段后，李工因故移民加拿大，需要离开项目组。老张考虑到系统需求已经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。

案例分析：可行性研究问题

在项目计划和选择的过程中，需要完成的首要工作是对项目进行估算。项目估算的范围涉及方方面面，例如项目或产品开发的范围、投入和回报、项目风险、作用和意义等。在传统信息系统工程方法中，是以可行性研究的方式来组织对项目的主要估算内容的。在企业实际的业务过程中，可行性研究通常作为一个重要的环节，被包含在整个项目立项，或项目选择和确认的过程中。

可行性研究的范围可能覆盖很广泛的技术、经济、执行、环境等各种需要评估的因素，但它并不是最后的精细计划(例如：项目的时间进度及人员安排)。通常在进行可行性研究的阶段，甚至项目的目标或产品的最终方向也是高度易变化的。但可行性研究的意义在于，虽然可行性研究不能指出项目最终的精细计划和方向，但可行性研究可以在项目定义阶段用较小的代价识别出错误构思的系统，从而规避未来更多的资源投入的损失(时间、资金、人力、机会)，或者因遭遇到无法逾越的技术障碍或环境障碍导致的不可避免的失败。

案例分享：项目计划编制

某市电子政务信息系统工程，总投资额约 500 万元，主要包括网络平台建设和业务办公应用系统开发，通过公开招标，确定工程的承建单位是 A 公司，按照《合同法》的要求与 A 公司签订了工程建设合同，并在合同中规定 A 公司可以将机房工程这样的非主体、非关键性子工程分包给具备相关资质的专业公司 B，B 公司将子工程转手给了 C 公司。

在随后的应用系统建设过程中，监理工程师发现 A 公司提交的需求规格说明书质量较差，要求 A 公司进行整改。此外，机房工程装修不符合要求，要求 A 公司进行整改。

项目经理小丁在接到监理工程师的通知后，对于第二个问题拒绝了监理工程师的要求，理由是机房工程由 B 公司承建，且 B 公司经过了建设方的认可，要求追究 B 公司的责任，而不是自己公司的责任。对于第一个问题，小丁把任务分派给程序员老张进行修改，此时，系统设计工作已经在进行中，程序员老张独自修改了已进入基线的程序，小丁默许了他的操作。老张在修改了需求规格说明书以后采用邮件通知了系统设计人员。

案例分析：创建工作分解结构

某信息系统项目较为复杂，有许多需要进行的工作，老刘是这个项目的经理，为了更好地制订项目计划，更有效地对项目实施过程进行管理与控制，老刘需要对项目开发过程可能涉及的工作进行分解。老刘的助手对开发过程进行了分解，认为可以划分为 5 大块：确定需要、设计、研发、测试和安装，如下表所示。

老刘认为，制订 WBS 是项目范围管理中的重要过程，一个详细的工作分解结构对项目的管理工作很有好处，但助手的工作分解结构并不完整。

案例分析：一筹莫展的项目经理

老王是一家 IT 公司软件开发部的项目经理，6 个月前他被公司派往新动力贸易集团有限公司（以下简称新动力）现场组织开发财务管理信息系统，并担任项目经理。老王已经领导开发过好几家公司的财务系统，并已形成较为成熟的财务管理软件产品，所以他认为此次去后应当只要适当地做一些二次开发，并根据用户需求作少量的新功能开发即可大功告成。

老王满怀信心地带着他的项目团队进驻新动力了，老王和项目团队在技术上已经历过多次考验，他们在 3 个月的时间就将系统开发完毕，项目很快进入了验收阶段。可是新动力分管财务的陈总认为，一个这么复杂的财务系统在短短的 3 个月的时间里就完成了，这在新动力的 IT 项目中还是首次，似乎不太可能。他拒绝在验收书上签字，并要求财务部的刘经理和业务人员认真审核集团公司及和各个子公司的财务管理上的业务需求，并严格测试相关系统的功能。

财务部的刘经理和相关人员经过认真审核和测试，发现系统开发基本准确，但实施起来比较困难，因为业务流程变更较大。这样一来，又过去了 1 个月，新动力的陈总认为系统还没有考虑集团公司领导对财务的需求，并针对实施较困难的现状，要求项目组从集团公司总部开始，一家一家子公司地逐步推动系统的使用。