上海翻译公司完成安全系统中文翻译
-
目的：
首先我了解到我们现在比较关注的是，关于应对不同用户需求及需求爆炸和 需求变化问题遇到了一些困难（时间和人员投入以及质量带来的维护成本），所以我会就着本问题结合我的经历经验提出一些建议和看法，但是由于我不很了解我们morpho的系统，所以提出的问题也许不是特别有针对性，希望我的建议中好的东西能够改善我们现在的情况。在最后我想了解一些我们实际上遇到的问题，参照别的公司的模式来尝试分析问题。
-
建议：
基于我所了解的或者遇到过的问题，我认为也许在以下方面我们可以进一步加强。
-
需要增强辅助工具.
-
定义：能够提高工作效率（减少错误、降低重复性工作难度和时间）的非产品核心的工具。
-
事例：安装过程需要配置文件（这可能会因为安装人员不熟悉技术或者操作系统而增长了安装的时间并容易产生错误，还有培训新员工的成本也比较高。安装人员，需要对linux的了解、需要熟悉我们的系统、需要对照篇幅较长的说明）。
-
建议：对于重复性的复杂的工作，我们一次性投入资源进行辅助性工具的开发.
-
好处：
-
减少持续性投入成本。
-
缩短重复性工作的时间。
-
降低人工出错的可能。
-
降低对安装人员技术和水平的要求。
-
减少培训成本。
-
简化了复杂的工作，缩短帮助手册的篇幅。
-
缺点：
-
增加了非核心功能的投入（分析、开发、测试、文档）。
-
需要定期维护工具。（新需求、需求变化等）
-
分析和总结：
-
从上边的优缺点对比中，我们看出大部分重复性、操作复杂的工作，我们都可以用一次性的投入换来较大的收益。我们只要识别出这些工作并进行辅助工具的开发来解决这些问题。
-
关于工作模式。
-
环境：由于现今的商业化软件需求趋于复杂化，定制化，需求膨胀和需求快速变化成为了一个很大的问题。
-
分析：我对于这种现状提出了一个比较好的实现方式，这并不一定特别的适合我们现有的工作模式，但是我希望其中的一些优秀的实践方法可以作为我们的参考。
-
工作模式流程图：
-
解释：上边图例中，左侧是瀑布模型的简单图例，右边是基于XP极限编程的一种开发模式实践
-
需求分析：
-
首先理解用户需求，将其梳理成软件需求列表。
-
需求分类
-
关键需求（高风险、复杂）10%，影响项目成败，需要尽早处理，减低风险，合理评估项目计划的关键。
-
主要需求20%，项目的主体，不容易发生改变，完成将增加士气。
-
高增值需求 40%，低投入高产出（易用性等需求），尽量不在第一迭代处理，完成将增加用户满意度。
-
低增值需求20%，高投入低产出（用户可能不会使用的功能），尽量延迟开发，时间紧迫的情况下，有时到后期客户自己就会主动放弃这些需求。
-
错误需求：不应该做的需求和客户也没有描述清楚，或者他自己也没有想明白的需求。这部分如果是不应该做的需求就用延迟开发的办法处理，如果是不明确的需求要等到和用户明确了需求，再重新分类到其他类型中。(当然为了避免无必要的争执，我们一般是不会对用户说这是错误的需求的，我们可以告诉他这是低附加值的需求，到项目后期，随着他们对项目的了解，他们会明白的)。
-
做迭代计划，大约以1周到1个月甚至几个月为1迭代（这要视工程的规模决定）大概3-5个迭代是比较适宜的。
在第一个迭代安排，关键需求和主要需求，这会降低风险和稳定项目架构（极端的情况，有些高风险需求可能无法实现，比如说，需求是1台指定的服务器在1秒内需要处理完1000条数据，但是我们经过验证无法实现它），而这个需求对客户又是必须的，那么即使这个项目失败了，我们投入只是第一个迭代，我们的损失是相对小的。
中间的迭代我们应该根据需求的优先级进行分配，先完成高附加值的需求，而推延低附加值的需求，这点客户是可以接受的。随着项目的推进，客户也越来越明白他们自己想要的是什么，当他看到主要功能和高附加值功能都很好的运行时，我们把关注点集中在低附加值的需求上，这时客户往往会根据成本（主要指时间）和产出比，做出比较合理的取舍。
-
接下来我们做项目的初步架构，这次架构应尽可能考虑到可扩展性、易维护性、易测试性、安全等软件指标，然后在项目迭代过程中，不断反思和完善架构。
-
迭代（开发组）
-
首先是修改上一次迭代中测试组提出的问题。
-
然后进行关于本次迭代的细致需求分析。
-
然后进行软件设计。
-
当设计遇到不好处理的情况时，重新审视我们的架构，并在需求时，重构。
-
进行组件层的白盒单元测试（组件好比一台机器的零件），由于它是业务无关的，所以功能稳定，开发组能够更好的测试它保证质量(代码和测试代码的时间投入比例大约是1:1的)，这将覆盖代码路径测试和边界测试等白盒单元测试相关的情况。
-
定期进行代码审查和走查工作，这将保证代码质量在一定得级别以上，并可以提高初级员工的能力。
-
提交本迭代的代码给测试组。
-
迭代（测试组）
-
测试用例设计（主要关注在逻辑组件层），这是业务相关也容易变化的，测试人员要根据需求的变化不断的更新。这要覆盖正常流程异常流程，覆盖所有业务分支。
-
测试上一个迭代的产品。
-
回归测试。
-
提交测试报告（BUG列表）。
-
提交一个迭代的产品给客户（给他们信心和信任，并阶段性的给他们一个逐步深入了解真实需求的机会）
-
对下个迭代进行初步的分析，并用图形的方式（只是画图而不用代码）把我们的想法提前可客户进行交流，尽可能早的取得下一个迭代功能相关的真实需求。
-
总结本迭代遇到的问题，并考虑应对方法，在下一个迭代进行实践来验证他。
-
迭代结束，定期的庆祝一下给项目的成员信心，并稍微缓解下大家紧绷神经，让大家调整好状态，以应对下一个迭代。
-
当所有迭代都结束时，可能还有一些维护工作。其实在迭代过程中已经在进行DEBUG等维护工作，如果剩下的需求很多。（这将是一个新的项目，有新的合同和新的收入，我们不应该无偿的做太多额外的工作，除非我们认为值得）。
-
关于软件设计方面，在需求变化快速的今天，我们要适当的增加可扩展性和易维护性的投入。无论什么项目都有相对固定的部分、相对变化的部分，我们在容易变化的部分的设计投入将会降低我们因为变化产生的成本。下边我会举一个设计的例子用来说明这个问题。
-
需求：软件工作流
-
场景：流程经常变化、会增加新的工作节点
-
类图和构建图（只是为了说明问题的简化设计）
-
说明：
-
首先把实际的工作流节点从主流程中抽离出来，采用接口模式以库的形式动态加载，能够解决新增工作流的问题。
（IWorkflow , Scan , Code , Verify , Others…）
-
另外用工具可视化编辑工作流能力降低配置的风险（手工错误）和减少时间、降低配置难度。
（WorkflowConfigView ,WorkflowTemplate ,WorkflowBase…）
-
一些非功能性的内部需求（区别于用户需求）：
-
可扩展性，在易发生变化的部分，利用设计模式做一些可扩展的设计，这虽然会增加设计的难度，增加开发的时间，但是当你发现一个新的需求或者需求变更，因为我们的设计只用配置或者很少的很独立的代码就可以解决时，你将会觉得这个设计时超值的。
-
易维护性，在经常需要维护的部分增加设计。比如说：一个日志服务，能让我们方便的记录和查询想要的日志信息，这个组件就是很有意义的。再举个例子，有的 XML文件需要经常的修改（关于用户界面样式的定制配置文件），我们写一个工具去可视化的配置，能够提高这种效率。
-
易测试性，我们需要白盒测试的组件，不光需要容易看懂，而且需要容易测试，这方面的工作，有时会同时达到高内聚低耦合的高质量设计的效果。
-
安全性，安全性需求要尽早进行分析，当项目已经完成时，你再想提高他就难了。比如数据传输保密性、权限控制…
-
建议采取的其他实践：
-
结对编程测试，两个人互相写对方的白盒测试，互相代码审查。
-
市场人员，架构设计师，主要开发人员、测试经理和客户定期的交流讨论，可以拉近大家的距离并达到集思广益的效果。
-
定期代码走查，将提高整体团队的水平并让更多人熟悉别人完成的部分。
-
我的建议包括了，在需求变动频繁年代中，我所遇到或者听到的问题的解决建议，有些来自cogent，有些来自其他公司，可能这并不能很适当的应对我们现在遇到的问题。但很喜欢我们公司主动去了解分析并尝试解决问题的工作态度。有什么针对性的问题吗，或者以后以邮件或者其他形式交流，我希望morpho中国能为整个公司发挥更大的作用。上海翻译公司完成安全系统中文翻译
世联翻译-让世界自由沟通！专业的全球语言翻译供应商，上海翻译公司专业品牌。丝路沿线56种语言一站式翻译与技术解决方案，专业英语翻译、日语翻译等文档翻译、同传口译、视频翻译、出国外派服务，加速您的全球交付。
世联翻译公司在北京、上海、深圳等国际交往城市设有翻译基地，业务覆盖全国城市。每天有近百万字节的信息和贸易通过世联走向全球！积累了大量政商用户数据，翻译人才库数据，多语种语料库大数据。世联品牌和服务品质已得到政务防务和国际组织、跨国公司和大中型企业等近万用户的认可。 |
