、分析需求可行性没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选，这样的事也不干。可行性分析主要是针对某一需求决定是做还是不做。一般可行性主要考虑两个方面的因素:技术和人。技术方面主要是分析在给定的时间段内是否可实现所需的功能并满足产品的质量要求等相关指标。很多时候，用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想，将为项目的后续工作带来很大的风险。因此应尽量避免在需求分析中包含技术实施上有难度的功能。在曾经负责的一个项目中，用户要求新的管理系统应实现和管理系统的数据接口，以方便这些系统中的数据导人新的管理系统。许诺提供系统的数据接口，将为新系统的成功实施带来很大的风险。因为熟悉这些系统需要时间，开发与它们的接口也需要时间，而且等这些商业系统存在多个不同的版本。因此与外部系统接口的可行性定义为:不可行。对于复杂的项目，还应从经济方面和环境方面进行考虑。经济方面主要从投入、收益、短期、长远利益等方面进行分析。环境方面主要考虑市场环境和政策因素。需求变更对大型IT开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以，实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行
、应实地了解用户工作流程实地观察用户执行业务任务的过程。了解用户什么时候获得什么数据，并怎样使用这些数据，业务处理过程中需要处理哪些单据，需要和哪些角色的用户发生关联等。这都将有助于明确产品的功能需求。经验证明，与人们面谈关于他们如何完成任务时会有许多限制和不准确性，而这是任务观察可以直接解决的。特别是对于某些组织中普遍接受的规则和方法，用户认为你也应理所当然知道，而不曾提起时。在用户需求已经确认后，将用户需求进行条目化，把每一条需求形成需求开发任务，借助软件项目管理平台，将其直接推送给需求分析人员，而需求分析人员的分析结果可以通过该平台导出成为格式化的需求规格说明。一旦需求规格说明编写任务完成，管理平台直接推送需求评审任务给相关人员。后续的设计、编码、测试等任务都以类似的方式融入流程。
可以看出，50％ 并行化的程序在使用大于 10 个处理单元之后的速度提升收效甚微，而 95％ 并行化的程序在使用超过一千个处理单元之后仍然可以显著提升速度。
随着摩尔定律逐渐失效，单个处理器的速度增加缓慢，并行化是提高性能的关键。
图形编程是一个极好的例子，现代着色器可以并行渲染单个像素或片段。这也是现代显卡通常具有数千个处理核心（GPU 单元）的原因。
德墨忒尔定律
得墨忒耳定律又称最少知识原则，是一条与面向对象语言有关的软件设计原则。
该定律表明，软件的一个单元应该只与其直接合作者交谈。
比如对象 A 引用了对象 B，对象 B 引用了对象 C，则 A 可以直接调用 B 的方法，但不应直接调用 C 的方法。所以如果 C 有一个 dothing() 的方法，A 不应该直接调用，而是用 B.getC().doThis()。
遵循这一定律可以限制代码更改的范围，使其以后更容易维护、更安全。
坎宁汉姆定律
在网络上想得到正确答案的最好方法不是提问题，而是发布一个错误的答案。
除了以上的这些法则，该仓库还给出了很多的原则。
职场相关原则
死海效应原则：在任何一个组织中，工程师的技能、才华和效能往往与他们在公司的时间呈反比。
能力强的人更有可能离开，能力差的人反而会留下。
呆伯特原则：公司会倾向于系统地将工作能力差的员工提升到管理层，以使他们脱离工作流程。
（编辑：莆田站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
