软件经济学一 用经济学观点指导软件过程改进.docVIP

软件经济学一 用经济学观点指导软件过程改进 在21世纪的前十年中，软件工程方法发生了并继续发生深刻而又意义深远的变迁。软件的特征越来越被大多数人所看清，人们曾经认为，只要按照在建筑业或者制造业已经被证明是成功的管理方法，就可以使软件开发走向成功，但事实却让人气绥：进度滞后、项目失败、即使项目完成了用户还是不满意，结果很快导致商业机会的丧失，这些都严重困扰着软件工程界。为了改善这种状况，几乎所有的软件企业都在进行过程改进，但这种改进的目标是什么呢?有人说是正规的文档和流程，也有人说是有计划、秩序便于协调。但这些都不是根本目的，软件过程改进根本上是需要从经济学的观点来定义过程，追求的是高的投入回报比，这是一种崭新的价值观。 1，软件过程：现代对于传统的挑战 传统的软件过程所关注的是制订软件开发的规程，强调的是通过使用标准的、定义良好的、组织持续改进的过程。其质量控制的策略，是通过在各个关键位置上形成质量保证检查点，在该点上首先要对进度进行检查，并对提交物进行质量控制。其基本观念是：如果没有计划和规范，那项目一定是混乱和不一致的，尽管某些局部可能成功，但整体上可能永远也不会完成。传统是必须的，它是一种传承。 老式的软件过程所特有的低效率，使其在时间、预算和市场上失去机会等方面都代价高昂。所谓现代软件过程是最近十年来人们对软件开发困境进一步反思的结果，现代思维方式并不是完全反传统的，而是希望在传统之上进一步改进，使软件开发具有更好的经济性。良好的经济性就意味着能够更有效的管理有限的资源并获得最优结果。现代软件过程针对传统方法提出了一套新的价值观，这种价值观是反思了几十年来软件的特征所归纳的结果，由此演化出一套有价值的方法论。 2000年之后，人们重新审视软件工程方法，着眼点上已经不是重在建立内省的按部就班的规则和行为上，而是重在提升企业软件开发能力，并把这种能力升为一种确保项目健康和业务长期生存的手段，其过程定义更关注如何与客户交互，以及更好的交付产品或者服务。但是现实情况并不让人乐观，对大多数软件人来说，从经济学角度思考软件过程只是一种模模糊糊感觉，人们关注着编码和实现，关注着计划、进度的执行情况。关注着某个具体的项目而不是业务系统的价值。 很多行业仍然抱着那些过时的IT部门模型不放。比如，某些行业把IT部门仅仅看成一个提供内部服务的部门，只是被动的向业务部门提供他们认为能给他们带来方便的产品，而不是把软件看成公司整体业务价值链中不可或缺的一部分。目前把软件能力集成到业务价值链中的优势日益明显，我们需要改变公司管理与IT部门之间的那种关系。这种观念的创新改变，将会把软件开发能力提升为一种核心竞争力，而不仅仅是一项工程上的成绩。 从另一个方面来说，由于我们的教育使然，很多具有悠久历史的软件企业，仍然把上个世纪70年代建立起来的线性瀑布过程看成软件开发的正宗，他们按照这种方法，建立了一系列相互隔绝责任单一的部门(需求、设计、编码、测试)，而没有意识到这种条块隔绝的模型具有天生的高风险，在面对风险的时候往往显得束手无策。 为此，各种组织和专业联盟已经提出了很多不同的方法来解决软件项目中天生的难点，比如敏捷联盟、Scrum联盟。一些专业机构，包括项目管理协会(PMI)、软件工程研究所(SEI)、IBM的Rational公司等都针对软件的特征提出了解决方案。这些新的价值观和方法论，形成了新一轮现代对于传统的挑战。尽管这些团体的观点和目标不同，但他们的价值观都有一些共同的特点，包括更加重视人在过程中的作用，更加重视可运行的结果，更加重视与客户合作获取经济上的优势，更加重视软件天生的易变性性其解决办法。从方法论来说，他们都强调了迭代式增量开发的实践，这相对于旧的瀑布式实践而言，迭代式增量开发在经济上具有无可比拟的优点。 2，瀑布方式的问题 传统的瀑布式过程是一种顺序的、基于活动的思维定势，这些活动包括：需求收集、设计、编码、测试、集成一直到验收。通过这种一级一级进行的活动，来确保开发过程的有序。经典的瀑布开发过程，如下图所示。 这个过程要求在任何设计和实现工作之前，尽可能的推敲，把需求完全定义清楚，并把它稳定下来(冻结需求)，然后建立系统高层模型，包括系统和子系统的框架以及基于服务的层等。在底层设计阶段，可以精细的把业务需求转换为系统模型。然后在实现诸如编码、测试、系统集成以及部署等下游模型。瀑布式过程有8条经典法则： 在设计之前先要冻结需求。 在详细设计之前不要编码。 在集成之前要完成单元测试。 必须有详细的文档。 所有的交付文档都需要详细并且维护可追朔性。 质量评估必须是单独的团队(QA)。 高度精确的对所有的事情做计划。 审查所有的事情。 确实，这是一种非常好的工作方式，除非你是要做软件。至少，在现实中很少有用户承认需求已经被冻结了，也同意