区块链基本知识及项目管理基础
为某个银行面试准备的，明天加油~
摘抄于《一本书读懂区块链》
区块链
1.定义
区块链采用了分布式数据储存、点对点网络、共识机制、加密算法等计算机技术的新型应用模式。
在所有节点均不可信的点对点网络中，通过共识算法和经济学常识建立信任机制，并最终实现数据储存一致性的网络系统。
公共账本 交易广播到其他所有节点
2.特点
不可篡改（所有节点共同记录，前后信息互相关联）
去中心化（没有中心节点）
3.组成
区块：本块哈希值、所有交易单、前后区块的哈希值
4.结构
区块链系统：数据层、网络层（分布式组网机制、数据传播机制和数据验证机制）、共识层、激励层（将激励体制集成到区块链技术体系中，鼓励节点参与区块链的安全验证工作）、合约层、应用层。
模型中的创新点：基于时间戳的链式区块结构、分布式节点的共识机制、基于公式算法的激励机制、灵活可编程的智能合约。
5.技术
分布式账本: 时间戳+唯一的密码签名
共识机制：在很短时间内完成对交易的验证和确认，对差不多时间内发生的事物的先后顺序达成共识。
工作量证明：节点通过计算随机哈希散列的数值解争夺记账权，新的比特币作为矿工奖励。
智能合约：以数字形式定义的承诺，包括合约方可以在上面执行这些承诺的协议。
智能合同，不能更改。
哈希算法：单向性，确定性
6.应用
数字货币：电子货币形式的替代货币/ 基于数字技术，依托网络传输、非物理形式存在的价值承载和转移的载体。
比特币
去中心化的加密数字货币
比特币地址-私钥
| 机制 | 实现 |
|---|---|
| 发行 | “挖矿“，即解决数学问题 |
| 交易 | 数字签名 争夺记账券后将记账结构向全网广播，其他矿工接受区块并验证。 |
7.缺点
交易平台的脆弱性、交易确认时间长、价格波动大、技术原理复杂、难以监管、不法活动的温床
8.未来发展
区块链+银行业
场景：供应链金融（以核心企业为依托，对上下游企业提供的综合性金融产品和服务）：需要多方合作
问题1：中小企业融资难
解决1：在区块链上发行、运行一种数字票据，对这种数字票据进行随意的拆分和转移
问题2：商业汇票、银行汇票使用场景受限，转让难度大
解决2：银行与核心企业打造联盟链，供供应链上所有成员企业使用，使得债券得到多方共识。
联盟链：每个节点权限都完全对等，各个节点有与之对应的实体机构组织
场景：跨境支付
问题：结算工具和支付系统实现资金转换
境内收单，外卡收单 每笔交易需要在本行和交易对手进行资金清算和对账->业务处理满，中间结算成本搞，支付效率低
解决：基于区块链，双方之间直接点对点进行支付
降低风险，提高效率，节省资源
不需要中心机构进行资金清算
写在回来后
等待3个半小时，面试5分钟，大概还是要凉。不过还真的挺想去的。
一些区块链问题以及其参考答案
https://blog.csdn.net/z695516174/article/details/102711834
问题4：你对区块链了解多少？原答：这是一种实际上为比特币设计的技术，后来因为监控和记录网络上所有金融交易而带来的多种好处而获得了大量的推广。这是一种值得信赖的方法，目前情况下有很多组织正在使用它。由于一切都是十分安全的，并且它是一种开源方式，所以从长远来看，它可以轻松获得大家的信任。
问题16：你所知道区块链的好处是什么？
它鼓励安全的在线交易，这是它最大的好处之一。基本上，作为一个密切关注所有交易记录的分布式分散账本，它不会让记录被任何人改变，这增强了安全性。除此之外，参与者和企业主可以始终确保最终的成本审计。区块链始终可以保证的一件事是每个区块或单元只能传输一次，这样可以消除双重支出问题。
项目管理
五大项目管理过程组：
启动：设定项目目标
规划：制定工作路线
执行：发生变更，根据结果重新规划和重定基准
监控：测量项目绩效
收尾：了解项目
软件项目的生命周期
高度预测性
在启动和规划阶段，强调需求和详细计划的规约。
高度适应性
基于短迭代开发，对需求逐步规约。
分析、架构、设计、构造、集成和测试
预测性生命周期：在项目声明周期的尽早时间，确定项目范围及交付此范围所需的时间和成本。
增量和迭代型生命周期：项目范围在项目早期就能确定，但时间和成本估计常常会随着项目团队对产品的深入了解而经常修改。
迭代是开发过程的要素，增量是产品的要素。
迭代型项目生命周期
重复一个或多个软件开发的迭代阶段，不同迭代包含的阶段数量不同。
增量型产品开发
每个增量都增加了扩充产品范围的功能。
适应性生命周期
小增量返工。适合难以早期精确定义顾客需求。提升总体质量和降低总成本。
剪裁：用项目管理过程组指导管理项目，考虑整体项目应遵循的方法。
项目信息：工作绩效数据、工作绩效信息、工作绩效报告
瀑布模型
将软件生命周期划分为计划、分析、设计、构建、测试和维护六个阶段。自上而下、相互衔接的固定次序，早期的错误可能要等到开发后期的测试阶段才能发现。
v-model改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时开始。v-model包含了三个等级，分别是生存期模型，分配模型，功能性工具需求模型，生存期模型回答了“What has to be done?”的问题，阐述了应当实施哪些活动，应当产生哪些结果，诸如此类。分配模型回答了“How is it be done”，决定了在实施活动的时候应该使用什么方法，功能性工具需求模型回答了“What is used to do it”，采用什么样的工具来实现这些活动。
项目管理-软件开发模式对比(瀑布、迭代、螺旋、敏捷)
传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。前期阶段设计的越完美，提交后的成本损失就越少。
迭代式开发，把主要功能先搭建起来为目的，以最短的时间、最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息逐步进行完善。
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作，强调适应性而非预见性。（适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。）
项目拖延的解决方法
正常情况下通过良好的项目时间表和关键里程碑，能够很好的跟踪项目的进展情况。而通过提供的临时可交付成果，项目经理可以预测出项目的最终交付是否低于预期。
解决方案1：咨询项目的关键利益相关者，商定合理延长时间
通过充分了解到项目中出现的问题，客户可能实际上感觉到项目中已经花费了更长的时间对问题进行了控制并提供了更好的结果。虽然项目可能在到期之后延迟交付，强大的沟通将会减少延迟交付的负面影响，降低客户对于到期交付的期望，达成良好的客户期望管理结果。
解决方案2：通过优化项目来减少项目范围或同意分阶段交付项目
需要重新对项目范围进行逐一检查，以便优化一些元素。如果在项目到期的时候，需要提供项目报告或项目成果，可以选择提供包含到目前为止形成的关键结果提供出来，然后在稍后的阶段提供更新的最终报告，或者选择性的不提供一些不重要的部分。
解决方案3：增加资源或延长工作时间(或花更多的钱)
通常适用于较大的项目，特别适合可交付成果明确的项目。但对于较小的项目，这种方法就可能不合适，
正反向代理
正向代理：顺着请求的方向进行的代理，即代理服务器他是由你配置为你服务，去请求目标服务器地址。
反向代理：代理服务器是为目标服务器服务的，虽然整体的请求返回路线都是一样的都是Client到Proxy到Server。
代理服务器(proxy serve)：提供代理服务的电脑系统或其他类型的网络终端，代替网络用户去获得网络信息。
使用代理服务器的好处：提高访问速度。
防火墙作用：通过代理服务器访问远程站点，可以在代理服务器上设限，过滤掉某些不安全的信息，同时正向代理上网者可以隐藏自己的ip，免收攻击；突破访问的限制；可以通过代理服务器，访问目标站点。
PMBOK十大知识领域是：整合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理、干系人管理。
1、整合管理：其作用犹如项链中的那根线；
2、范围管理：做且只做该做的事；
3、时间管理：让一切按既定的进度进行；
4、成本管理：算准钱和花好钱；
5、质量管理：目的是满足需求；
6、人力资源管理：让团队成员高效率地和你一起干；
7、沟通管理：在合适的时间让合适的人通过合适的方式把合适的信息传达给合适的人；
8、风险管理：“无事找事”，从而让项目“无险事”；
9、采购管理：当好甲方；
10、干系人管理：和项目干系人搞好关系并令其满意。
其中时间，质量和成本管理构成了三角形。这个三角形中间项目范围。
“项目管理三角形“。项目三角形中的成本，主要来自于所需资源的成本，自然也包括人力资源的成本。
管理性收尾。还应该把所有的经验教训总结一下。
负责质量控制。大公司一般有质量管理部门（QA），QA的成员基本上都是由非常有经验的PM转型过来
文档非常重要，文档的整理应该贯穿于项目管理的始终。文档的管理是对项目进行良好的跟踪和监控的一个手段，简单的讲就是根据你的项目计划进行你的文档管理。
一般档案分类主线是：立项、计划、执行、结束4大类；然后在每大类中，再根据任务或者团组分类管理，根据哪个需要根据你项目复杂程度和管理习惯，总之原则是方便你对整个项目进度的追踪。
他们是WBS、甘特图、基准（BASELINE）、项目干系人和关键路径
WBS
WORK BREAKDOWN STRUCTURE，工作分解结构
WBS的定义，PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。
WBS做好了，以后工作就有了参考物，知道在不同的阶段应该干什么，完成到什么进度。WBS的划分其实没有规则，主要考虑方便做各类的统计工作，为管理服务。
甘特图在WBS的基础上将WBS形象化老控制进度
项目变更会影响各要素比如时间，成本，质量等。应该统一由项目管理办公室来进行控制，如果你要变更基准，必须要进行严格的限制。PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
项目是在一段时间内 为完成某一独特的产品或 提供独特的服务 所进行努力的过程。受到时间、人力、资源、成本、质量上的限制。项目有几个特征：1.临时性 2.独特性 3.一次性
WBS的顶层按生命周期过程 或 活动细分 项目。工作和可交付成果在WBS的下一次以活动和任务的输出呈现。这种称为活动导向的WBS。首先确定最底层；首先确定最顶层；从中间向外部。
第一级通常与项目生命周期相同(如需求分析，设计，采购，施工……)
WBS的每一级都是其上一级的片断(Segment)，一个工作单元只与一个上层单元相关，上层单元的工作内容应该等于其所有直接下层工作单元的总和。
甘特图
1.以图形或表格的形式显示活动。
2.现在是一种通用的显示进度的方法。
3.构造时应包括实际日历天和持续时间
初始阶段风险大，结束阶段的损失大
1确定性。具有明显的可能性
2是风险。
3是未知性。
软件工程 三层架构
https://www.cnblogs.com/yanying521/p/10750061.html
UI(表现层): 主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。
BLL:(业务逻辑层): UI层和DAL层之间的桥梁。实现业务逻辑，具体包含：验证、计算、业务规则等等。
DAL:(数据访问层):与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。（当然这些操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户）
每一层都各负其责，那么该如何将三层联系起来呢？
1、单项引用（见下图）
2、实体层（Entity）：它不属于三层中的任何一层，但是它是必不可少的一层。Entity在三层架构中的作用：
1、实现面向对象思想中的"封装";
2、贯穿于三层，在三层之间传递数据;（注：确切的说实体层贯穿于三层之间，来连接三层）
3、每一层（UI—>BLL—>DAL）之间的数据传递（单向）是靠变量或实体作为参数来传递的，这样就构造了三层之间的联系，完成了功能的实现。
综上所述:三层及实体层之间的依赖关系:
使用三层架构的目的：解耦，三层之中每一层当不再适合程序时都可以没有负担的进行更换，不会影响其它层的正常工作。
最后说一句，真的想去~