企业信息化与软件工程的迷思

企业信息化与软件工程迷思

      在IT信息化过程中，软件工程技术持续演化，各个行业都需要IT信息化，信息系统融入基于日常工作中。 在通常软件行业的公司内信息化往往比较健全，而非软件行业的公司做得就相差甚远。 非软件行业公司在这儿，主要指非以软件研发，电子商务互联网为首要赢利的公司与企业。 笔者曾经看到过某个国内上市公司，内部连一个门户Protal都没有。整个公司内部使有QQ做为工作沟通与文件分享工具。一些上千人的国企公司也是如此，大都缺乏信息安全意识，协作平台。又如一个非软件行业公司，自行组建研发团队做信息系统研发。而这种情况下，缺乏熟悉对某个领域专业知识，加之业务部们对业务不精通，研发出来的系统往往流程低效。有些业务流程有问题，居然也不做知道，甚至系统中一些业务逻辑错误操作的情况。这也是领导者一个意识的问题，回到根本就是没有深刻理解企业信息化本质，以及未能从全局来规划信息化，各处都是信息孤岛。反思一个非软件行业的公司需要CIO吗？领导信息化意识差，更别谈互联网思维。非软件行业公司信息化如何做得好呢？ 大型公司一般会实施ERP，SCM。可以看到是企业管理软件ERP演变之一 特定行业领域信息化，看上去可以是这样的零售连锁专卖信息化解决方案简介之一，餐饮连锁公司IT信息化解决方案一，某物流集团企业信息化案例介绍

      在信息系统研发过程中，这本身也是一个软件工程过程。按高层领导的想法想快速做一个系统，而他们认识里面往往只有开发这个过程。对于软件测试，部署，实施完成没有意识。总是在不断催促下开发一个信息系统。到最后，2个月系统开发完成。勉强投入使用，后面发现某个功能点又不能满足需求了。系统中BUG不断出现，没有办法，不断有工程师陷入到系统BUGS修复，维护过程中。后续又想继续做新项目时，发现人力资源完全耗在遗留项目维护中了。这样的领导往往不知道，修改程序比开发程序所花费的时间要大得多。接着出现的就是软件系统存在质量问题，测试过程薄弱，发布更新效率低的症状。想实施成熟的CMMI，但企业急功近利的情况下，完全不现实。最后演化为边做边改开发模式。开发工程师深受其苦，导致各类不标准，不规范的开发过程产生。项目在出现延期的迹象，但决策者不了解Brooks'Law：“往一个已经延误的项目里加人力资源，只能让那个项目更延误”.

如何提高软件系统质量呢？

     第一，需求阶段。从软件工程的源头开始，需求是否充分分析，在需求不清楚的情况下，做到敏捷需求开发。很大一部分取决于业务需求分析能力。在系统设计阶段，非软件行业的公司往往缺乏，对系统分析设计深入相对较少。系统没有经过设计就开始进入编码过程，最后没有系统设计任何文字留下来。从来没有说敏捷开发，就不需要系统设计，架构设计。对于大型信息系统，架构设计更是重要。在RUP（Rational Unified Process），统一软件开发过程，RUP最重要的它有三大特点：1）软件开发是一个迭代过程，2）软件开发是由Use Case驱动的，3）软件开发是以架构设计（Architectural Design）为中心的。在今天软件研发过程中，审视我们能否快速的迭代就能发现很多问题，再看是否有Use Case，Use Case是否设计合理，第三是否有系统架构设计，设计是否满足质量属性。

     第二，系统设计阶段，分析和设计（Analysis & Design）工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用例的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。与建筑学类似，如果软件系统没有一个好的架构是不可能成为成功的软件系统的。没有图纸的建筑地、没有设计的造桥工程都是不可以想象的混乱世界。建筑工程如是，软件工程中亦然！架构设计是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。之前写过一些，架构相关的文章，其中有数据库的互联网数据库架构设计思路，对于企业架构涉及有企业架构转型重构与治理，企业IT架构介绍。架构设计中软件架构风格介绍，企业级应用架构模式N-Tier多层架构，软件架构中质量特性。互联网行业的电子商务基础技术架构，互联网电商搜索架构演化之一。我们看到巨头公司的：

      文件的横向扩展。以Google的搜索技术为例，文件被分割为多个小块并分别拷贝到多个服务器中。这样搜索可并行地完成，并通过合并各个服务器所给出的结果得到最终的搜索结果。
      架构的横向扩展。以Amazon的做法为例，事务会被切分为多个服务，每个服务使用特定服务器实现。当事务存在瓶颈时，可在多个服务器上复制服务，并且每个服务由一个半自治的“双比萨”团队负责。

     第三，编码阶段，在敏捷开发过程，提及可以工作的软件胜过面面俱到文档。这就意味着我们对源代码质量要求比较高。源代码可读性，可维护性、可测试性尤其重要，还有性能。如何做到代码优雅，《The Art of Readable Code》一书已做详细描述。一个优秀的程序员效率超过10/100个普遍的程序员。有了优质的源代码，后续可能出现的BUGS就相对较少。所有一个大型软件产商，他们最重要一个过程就是Code Review. 其次开发人员，需要自行编写单元测试。在很多小公司这一块儿完全没有，很多人写几年程序员居然不知道单元测试，这也就是非软件行业的环境造就的问题。也是体现专业性。之前这篇文章也谈到软件开发的专业化 ，还有有提到 静态代码分析与代码质量安全 。

     第三，测试阶段。迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。从全面质量管理，测试能力成熟度TMM，到全面的软件测试。以及敏捷软件质量保证的方法与实践。 微软，GOOGLE等公司把软件测试推上更高台阶。诞生了SDET这样职位。SDET，属于开发和测试中间，属于白盒测试范畴，要求发现代码中的问题。SDET要求人员对质量的要求很高，并且喜欢拆东西，弄明白它是怎么工作的，而且喜欢改善它。一个SDET的最基本要求就是对质量的热情：一定要找到所有的瑕疵从而达到完美。其次，喜欢钻研、分析、并改善事物是成功的SDET的又一潜质。在今天移动互联网时间，需要移动应用App测试与质量管理一， 构建移动应用测试(一)，我们需要基本的IT持续集成之质量管理，到底自动化测试做什么，梳理流程软件测试流程参考一，同时演化DevOps的基本原则与介绍

     第四，部署发布阶段。工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。我们需要构建高效的研发与自动化运维。涉及运维，之前提及IT运维监控解决方案介绍，技术架构下的运维治理。也有移动端运维体系建设. Infrastructure As Code ，对着容器、容器编排技术进行编码，让“无人值守”、“智能运维”真正成为可能。持续集成（Continuous Integration）、持续交付（Continuous Delivery）、持续运维（Continuous Operation）是DevOps的具体环节和手段，它相当于把一条纯数字化链路上不同的参与者关联到一起 – 无论是开发工程师还是运维工程师

整体

     从整个研发生命周期中软件研发工程基础设施，移动开发一站式解决方案。我们如何解决技术债务管理计划。既然是个工程，我们还需要软件项目进度管理，一些企业在项目管理上的创新企业项目化管理介绍。说到最后不论是信息化建设，软件系统研发最关键3个要素是人，过程，技术。人是首位，人构成组织，需要学习型组织与企业，人需要管理企业绩效管理系统之平衡记分卡，这又与公司文化有关系，我们看人才公司环境与企业文化，企业文化、团队文化与知识共享，企业创新文化与等级观念的作用.

趋势

     越来越多的系统正在向云上迁移，云就是未来。相比于大多数预制的数据中心，云更便宜、更稳定、更安全并且更具扩展性。将已有的应用转化为基于云的应用是十分具有挑战性的。针对传统数据架构所设计的应用如果不做大量的代码重构工作，就无法在云中很好地运行。架构即代码解决方案：使用容器，实现了过程的标准化和自动化，容器影响开发者的开发方式、开发习惯，“强迫”他们去思考例如无状态的服务、业务逻辑粒度的控制、资源的弹性伸缩、应用代码的发布形态、系统里面每一个细节的可监控性等等。无服务器架构，以更低的价格提供了灵活的计算容量，软件定义网络，使用软件而非硬件实现了规模扩展。 Conversations as a Platform（CaaP）引导人工智能, Containers as a Service (CaaS) 引导持续交付。再到响应式编程宣言的出现，软件开发项目经历了一些重大的重构：构建自组织的团队模式，以增量和迭代的方式构建健壮的产品，从客户那获得快速反馈从而通知正在进行的工作。据Gartner称，2020年企业中无云战略将极为罕见。

     企业数据库是一个巨大的依赖性生成器。由于每个独立团队的工作必须要和其它共享同一数据库的团队协作，这导致每个团队都无法实现自治的部署。联邦架构是单一数据库的替代技术，它将数据分割为适合各个独立模块或服务需求的本地数据存储，数据的存取只能通过API方法。API正在替代中央共享数据库，并使物联网成为可能。使用API是软件工程的必备技术。API应作为有具体团队负责的产品看待，并通过聚焦于API用户来推进和开发新的功能。
     没有必要尽力去实现系统零故障，我们可以换一种思维。当前很多的系统都是脆弱的，虽然它们在刚上线时都是鲁棒的，但是随着时间的进展，它们变得越发地难以维护。当今系统需要的是反脆弱，并具有面对故障的能力。在发生故障时，系统应能限定损害的程度，并从故障中恢复。如何获取反脆弱系统取决于系统测试的方法，即如何通过注入故障产生给定的运行错误。为达到所期望的可用性和鲁棒性等级，系统需要隔离故障并从故障自动恢复。
     为具备持续集成的能力，需要一个部署流水线；为获得持续集成所承诺的优点，需要具有一个包括产品管理、测试和运营的跨功能团队。部署流水线依赖于自动的测试、迁移和部署过程。持续集成需要所有团队通过代码库做交流，实现针对主干分支的持续集成。团队应维持软件时常处于发布就绪的状态，如果事实并非如此，你必须停下来并做到上述要求。只要实现了持续的部署，一旦有用的软件增量或功能就绪，就可通过切换或转换实现软件的增量发布。
     持续交付提供了必要的端到端反馈。研究显示在半数情况下产品经理是错的，产品规格说明中会有三分之二的特性和功能是没有必要的。导致这些问题产生的原因在于做实验验证某个特性是否可以真正地解决手头问题之前，就试图达成具体开发特性的细节。为确保开发的解决方案能很好地适用于所需解决问题，需要通过实际的使用产生快速的反馈，这也正是精益开发和敏捷开发实践的真正价值所在。

     我们要让IT技术驱动业务，提升协作效率，降低运营成本，提高ROI。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

希望对您软件项目开发,运维管理，系统架构与研发管理体系, 信息安全, 企业信息化等有帮助。 其它您可能感兴趣的文章：
云计算参考架构几例
微服务与Docker介绍
互联网直播平台架构案例一
高可用架构案例一
某互联网公司广告平台技术架构
某大型电商云平台实践
云计算参考架构几例
移动应用App测试与质量管理一
全面的软件测试
著名ERP厂商的SSO单点登录解决方案介绍一
软件项目风险管理介绍
企业项目化管理介绍
智能企业与信息化之一
由企业家基本素质想到的
敏捷软件质量保证的方法与实践
构建高效的研发与自动化运维
IT运维监控解决方案介绍
IT持续集成之质量管理
人才公司环境与企业文化
企业绩效管理系统之平衡记分卡
企业文化、团队文化与知识共享
高效能的团队建设
餐饮连锁公司IT信息化解决方案一

如有想了解更多软件研发 , 系统 IT集成 , 企业信息化，项目管理，企业管理 等资讯，请关注我的微信订阅号：

 

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。