搜索
某公司生产测试数据库系统案例分析ProductionDatabaseCaseAnalysis软件工程案例分析报告一、案例简介某企业是从事探测器生产的一家中小型外商独资企业，为节省人力成本和原材料成本，于06年开始，由外国总部开始将设计和生产制造中心向国内进行转移，先后在北京、宁波、香港等地建立分公司或分支办公室，并开始拓展大中国区和亚太区市场。由于所生产的产品需要有极高的技术工艺水平，所以在本地招募高级技术型人才以满足发展的需要。一切似乎都在意料中进行，但是在06年底产品转移出现严重问题，由于产品的环境适应性能较差，北京这个内陆城市的气候又比较干燥，冬天干冷，生产的环境一度无法保持原有的水平，成品率一落千丈，生产效率严重下滑，公司效益收到直接影响。一套完善、标准、可行性高、高效率、低成本的解决方案势在必行。在建设完善的物理环境以保证生产可以正常进行之外，公司领导层还提出了建立一套生产数据库系统的需要，以更进一步的保证生产效率，对于生产和测试流程进行良好的监控和管理，利用技术手段对于失败产品进行错误分析，以便于及时发现生产中出现的漏洞和隐患之后，可以提供最快最好的解决方案。由于该企业从事业务包括市场分析调研、自主研发、用户定制、生产制造、销售等一条完整的链式流程，所以产品都是基于某特定用户的特定需求来进行生产。这样的需求在市场上很难有现成的系统或软件产品可以完全胜任该企业生产发展的需要。所以领导层在经过多次讨论和协商后决定：自主开发这套生产数据库测试系统，由企业内部的IT人员和软件工程师协同合作，先后进行引导式需求分析、可行性分析、流程设计、概要和详细设计、测试和培训等，开发周期历时8个月。这套生产测试数据库系统（ProductionTestingDatabaseSystem）基于Linux系统平台，具有一定的可移植性和可扩展性。由于考虑到成本问题，开发平台基于PHP+Apache+MySQL的黄金组合，开发平台和系统平台符合GPL规范，系统架构成熟，具有一定的安全性、实用性和稳定性。系统内部的核心测试模块符合该企业现有的业务和测试流程，满足客户的需求，可即时生成报表以便管理层对任意时期或时段的生产和测试情况、良率等指标进行监控和统计，对库存和发货进行管理等。二、案例分析（一）系统目前运行状况该系统目前运行正常，硬件系统可以很好的满足系统的需要，负载均衡。网络通信流畅。整个系统平台按照设计的功能在正常的运行。数据库工作正常，用户可以正常的对数据进行增加、修改以及查询。备份方案完善。如果出现停机或拒绝服务等情况，本地管理员会及时查看并修复，如果无法解决，本地管理员有义务或责任把问题升级至公司总部，由远程工程师协助进行远程修复。综上所述，该系统目前运行良好，所以该案例为成功案例。（二）标准化的软件开发模型标准化的软件开发模型1.宏观角度该生产测试数据库系统在宏观角度采用瀑布模型作为软件开发模型。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。该系统在总体的开发和设计角度采用瀑布模型进行参考。起初在产品转移的阶段由于产品成品率下降严重，给公司的效益带来很大损失。为了更好的从质量角度监控所有产品的生产流程并有效执行，开始着手制定生产测试数据库系统的解决方案，并制定项目经理。在制定了自主开发的计划之后，所有的项目开发人员遇到了一个难题——需求分析。由于是自主研发一整套的软件系统，开发人员必须对整个系统的流程和业务流非常熟悉。但是在开发之前所有的开发人员并不具备这样的条件，也从来没有在这些方面被培训过。需求分析是一个软件项目的重中之重，有的比较复杂的项目，需求分析的时间可能占到总开发时间的60%以上。如果不了解用户确切的需求，便不能开发出一套实用性强且完整的系统。为了尽量贴合用户的需要，了解细节，在公司和相关领导的大力支持下，在项目开发时间允许的范围内，开发人员以分组的形式到各个所涉及的部门中去学习和实践，亲身了解各个产品的开发流程、测试步骤和生产的方法等，并对今后在软件开发的过程中可能涉及或考虑的问题进行详尽的记录。在学习和实践中，用户的需求自然而然的被描绘出来。这其实也是一种引导式的需求分析，在用户不能把需求很完整很明确的表达出来时，开发人员可以借助引导的方式来探知用户的真实想法，并最终把这些想法变成软件模型呈现出来。这在当今软件工程的需求分析阶段也是一个非常常用的方法。在进3个月的实践结束后，开发人员开始对在实践中遇到的问题，了解的情况等进行汇总和总结，并找到相关部门的负责人再次进行确认，收集意见和建议。在质量部门的监管下，着手发布正式的文档和文件。其中包括《某企业生产测试数据库系统开发项目——需求分析说明书》《某企业生产测试数据库系统开发项目——可行性分析报告》、。在质量部门同通过验收后，需求分析阶段结束。由于需求分析阶段全部人员的出色和到位的表现，使得这个项目开了一个好头。之后的系统概要设计和详细设计阶段就变得相对轻松。在质量部门的配合下，整个团队严格遵守系统开发的标准化流程，用ISO9000系列质量认证体系作为参考。按照ISO9126的定义，软件的质量通常可以从以下六个方面去衡量（定义）：1)功用性（Functionality），即软件是否满足了客户功能要求。2)可靠性（Reliability），即软件是否能够一直在一个稳定的状态上满足可用性。3)可用性（Usability），即衡量用户能够使用软件需要多大的努力。4)效率（Efficiency），即衡量软件正常运行需要耗费多少物理资源。5)可维护性（Maintainability），即衡量对已经完成的软件进行调整需要多大的努力。6)可移植性（Portability），即衡量软件是否能够方便地部署到不同的运行环境中。（此部分在此只是先提到，在后续的章节中会详尽介绍。）开发团队先后进行了硬件平台的搭建和网络设计、数据库设计、用户界面设计等详尽的设计工作。并在质量部门的协助下，完成并发布了正式的设计文档。其中包括《某企业生产测试数据库系统开发项目——概要设计报告》、《某企业生产测试数据库系统开发项目——系统详细设计报告》，并由网络管理员撰写《某企业生产测试数据库系统开发项目——搭建生产测试数据库系统的系统运行平台和网络环境指引》在质量部验收后，等。设计阶段结束。接下来的工作更为具体，所有的开发人员要从奔走转为安定，那就是——代码的编写和具体应用的实现。在编写之前，所有的开发人员务必熟读详细设计报告，充分了解其中的内容，统一开发工具的厂商和版本，统一开发方法和开发习惯（如注释的方法等等），以避免在日后的具体开发工作中产生不必要的兼容性问题，确保开发进度。在代码编写阶段，质量部严格按照ISO9000系列质量认证体系对系统开发进行评估和监管，并按照企业相关发布的对项目控制的文档对工作的开展进行有益的约束。设置周例会，对本周在工作中遇到的问题进行汇总、探讨和解决，使开发人员明确目前进度以及了解并协助规划下一周的工作开展方向和任务。每月由项目负责人（项目经理）提交书面开发进度报告并通过电子邮件的方式汇报给公司领导层。另外，在代码编写过程中，采用开发人员责任制，按功能模块划分，尽可能的少出现错误，完善自己的代码，并设立共享库，尽量提高代码的重用性，大大的节约了开发时间。代码编写阶段历史大约2个月。当系统基本成形，开发人员向项目经理提交了代码编写完成报告，由项目经理和质量部门一同向管理层汇报开发进度并开始制定测试计划。在征求了开发人员的意见之后，由项目经理提交书面的《某企业生产测试数据库系统开发项目——测试计划说明书》，在质量部验收之后，系统测试开始。由于开发人员有限，该套系统又是面向公司内部使用，所以采用了黑盒测试的方法。开发人员互换在代码编写阶段自己负责的模块，按照《某企业生产测试数据库系统开发项目——需求分析说明书》进行功能性检测，排除系统BUG。一旦发现错误，在找到原先的责任人确认之后，及时进行更改。建立《某企业生产测试数据库系统开发项目——排错列表》，用数字对已存在的BUG进行编号，如果日后再遇到此类问题，可以方便及时地进行查询。在开发团队内部测试之后，由网络管理员将系统安装上线，完成网络环境的配置，经生产中心领导的同意，挑选生产测试操作人员对系统进行公开测试，依然采用黑盒测试的方法着重功能性检测，并指派开发团队中的人员进行跟踪，一旦发现问题或者与实际需求不符时，立刻和开发团队沟通，能更改的尽量更改，尽量贴合用户需求。并将所有问题记录在《某企业生产测试数据库系统开发项目——排错列表》中，保证文档的实时更新。在测试临近尾声的时候，由项目经理提交《某企业生产测试数据库系统开发项目——测试报告》，由相关人员书写《某企业生产测试数据库系统开发项目——用户手册》并开始着手对用户进行培训。2.微观角度在软件系统开发完毕之后，最重要的工作莫过于对该系统的运维工作。由网络系统管理员定期检查服务器及网络使用情况，例如系统性能等参数。保证系统的硬件水平以满足用户的需求。由数据库管理员（DBA）定期对数据库进行备份和优化，保证系统稳定可靠的运行和数据安全。另外，开发团队成员则考虑如何进一步的优化系统，以提高系统的可用性和效率。在软件维护阶段，用户的需求还会根据生产流程的细微变化而膨胀。由于该企业的产品大多为定制类产品，生产的工艺和技术指标，以及客户的需求难免会有不同，所以如果有新产品的诞生，该生产测试数据库系统还需要为新的产品添加新的模块。所以在软件的维护阶段，从微观角度讲，在产品模块上开发人员采用了增量的软件开发模型。增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。为了在新的产品生产工艺公布之后能尽快地使系统支持这种产品的测试，也为了提高代码的重用性，节省更新时间和人力资源，开发团队采用产品类型模块化，即相同或相似的产品将有一部分源代码是相同的，这样可以很方便的在短时间内把模块移植以适应新产品的需要。这也就是我们常说的软件工程开发中的复用原则。在新模块上线之后，将更新某企业生产测试数据库系统开发项目系列文档及《用户使用手册》。软件工程从计