销售点系统的发展

销售点系统的发展：体验报告摘要：这份报告包括了一些经验，这是期间的一个销售点终端（POS）的发展系统。有关项目的具体的事实是，它开始作为一种尝试开发可定制的标准软件，然后进行了重组，提供一个独特的项目解决方案。这份报告详细情况之前和之后重组，并讨论通过的经验不断的发展。这些经验主要涉及三方面，即：软件项目管理，原型设计和测试。简介本报告包括期间的一些经验一个销售终端（POS）系统的分布式点的发展。有经验的技术团体，但大多数这里介绍的经验是不按技术性质有关人员和流程。必须指出的是，本报告涉及的项目，不是一个IBM项目。不过，分析和编制已经完成在IBM在IT咨询与检测IBM集团瑞士。正如在抽象中提到，这份报告是关于一个项目进行了重组，该报告没有重点在重组本身，但是在路上，有人管理事后。为了更好地介绍经验他们被分为三组。•首先，发展过程中的经验（后重组的项目），估计和生产力。•其次，随着经验的要求分析，通过探索性原型。•第三，经验与系统测试，部署系统，有的试生产有关的活动。事前并促进理解，简要描述的POS系统及其嵌入会鉴于，由不同的综合纲要遵循项目情况和阶段。系统概述如上所述，该系统是一个有待开发的销售点系统。它的用途是协助的寿险销售过程。该系统是为企业的生命保险的一大银行表决。这家银行拟进入一个完整的产品组合的寿险市场。而不是建立一个新的销售机构，现有基础设施（分支机构）应使用。因此，POS系统应使财务人员和银行职员，提供和销售人寿保险银行客户。POS系统，实现了在后台关系数据库，如CORBA的中间件，并作为主要语言的Java实现中常见的多级体系结构都，在中间件业务组件和客户端组件在一个薄客户端窗体。前端是一个小程序在Web浏览器中运行。（见图1。）图。1：高层次的系统架构项目概况该公司，实现了POS系统，曾与终身保险管理系统的经验和合理数量也与POS系统的保险经纪。然而，对于非保险经纪（银行职员），在这技术（多层，CORBA技术，Java等）已成为现实之前，只有一个非常小的规模，而不是一个完整的产品系列POS系统。该项目涉及的四个政党：（1）客户公司（银行），（二）公司经营系统（一IT服务供应商），（三）公司应发展保险产品（一个金融服务咨询公司），（4）最后，公司应提供的管理制度，发展POS机（一种保险部门的软件公司）。项目里边反重组前该公司（4）有另一个客户-保险公司（集成电路）-谁订购了类似的系统，和另外两个客户，谁可能在这样的系统感兴趣。所以，当时的想法是开发一个系统定制POS机一次，这一制度适应每个客户的需求。项目开工前进行了一些基本的决定是整体技术架构。这些决定被证明是可靠和可扩展性。然而，每个单独的系统，更重要的是这些系统之间的电位差的要求是不能完全理解。这是清楚地认识到，一个可定制的系统的发展将采取比单个项目的解决方案开发更多的努力。令人惊讶的是，为发展不适应的时限。这意味着事实上，这是计划开发/生产一个全新的标准软件和定制在同一时间内，至少有两个客户在一个系统的发展将采取。为了应付这个问题的开发团队扩大到了35人的整体规模在两个地点派发。试图开发可定制的标准软件的POS比预期的更困难。有一个技术问题，由于缺乏早期阶段，直接导致团队沟通问题，是由于一些分散的发展。然而，最严重的问题涉及到一个不切实际的计划对一个时间表和目标，这些目标过于含糊不清，导致基础上的'我们没有时间去有效'的情况。的发展和进步变得越来越困难远远超出预期逗留。停止开发后9个月，就在当时的第一个客户（1）-在文件开头提到的银行-想进入试生产阶段。在这个时候，这个系统的最初版本应该已经开发和定制的第一个客户的需要，为了使第一次全面测试。现实中，这个系统仅部分已被开发。该系统或更高它准备的部分有三个主要问题：P-1型是什么已发展为两个原因不是客户想要的。（一）系统并没有真正适合客户的销售过程和（二）它是太复杂，由非保险人使用。然而，客户的希望和需要，并不完全清楚，但它肯定会不适合实际系统。该系统是接近什么其他客户-保险公司（集成电路）-通缉。此时的系统更类似于一个比一个POS系统保险管理制度。在反思，这不是太奇怪，因为：（一）有没有真正的需求分析，及（ii）客户的保险公司（集成电路）'是更接近开发人员，位于（三）保险管理系统是系统发展公司（4）具有大量的经验。P-2级的实际架构是有问题的，而不是真正与原来的想法兼容。由于时间限制，大大缩短了设计阶段，因此它并不清楚，所有的地方或在其上开发层以把哪些功能。因此，过多的业务逻辑进行编码为列和用户界面层。中间件是用来更像一个到数据库的连接器。特别是与外部系统分--导致大规模整合的问题，并解释这至少部分原因发展变得日益困难。的P-3系统的整体质量unsatisfactory.For例如：该系统是难以安装，其行为和外观不同的子系统之间不一致的，其他系统的连接意外终止等为主，这是因为没有对系统集成和控制，并没有专门的环境下，集成和测试，可以放在明确的活动。尽管有延迟，同时客户（1）和（集成电路）仍然希望他们的系统。在这一点，决定暂停计划开发一个可定制的标准软件和POS机分为（二）独立项目，独立开发团队的项目情况。每个项目应提供个别项目解决其客户。这是由每个项目的决定，这部分系统发展至今可以或应该被重用。在这份报告中，我们现在只集中在为客户系统（1）的发展-银行。重组后的项目重组后的团队，这次分配八个人给开发用于银行POS系统大小。这支团队开始的情况下，它不仅要应付前（错误的系统，有问题的架构，低质量）提到的三个主要问题，而且还与另外三个问题：没有人在团队中建立这样一个系统之前，P-4级的团队没有相当丰富的经验，P-5级，致力于开发客户，但现在还不清楚多久了客户的耐心会持续多久。P-6号文件的存在（事实上）关于3一直发展至今系统的各个部分。最初的开发者（事实上）不可用，因为他们正忙着和在另一个网站上。重组后的步骤在这一点，主要是因为这些问题的P-1和P-5，决定，并同意了一个发展进程探索原型[4]的基础情况。这种做法应保证在第二次获得该系统的权利，并能够尽快提出一个可能的东西给客户。会议还商定涉及尽可能接近客户，以验证结果不断进步，使透明。具体而言，下列活动确定了以'生存'的情况，并得到发展所做号：A-1中关于架构和代码的质量，决定哪些现有（失事）系统部件可重复使用，这部分有需要重建。走出六个部分两人重用（5,6），两个人重用，但完全重新设计的（2,4）和另外两个（1,3）-包括最重要的-被重建。凡错误的构成部分已建成，有必要重建它们。凡已建成的组件错误的，部分是重新设计的。A-2中建立一个集成，测试和发布环境，这是基本相似的生产环境和持续集成允许在开发过程中。两个人出了八个队（对一个全职员工为1.5当量）都致力于一体化和集成测试（后来也到包装，送货，安装支持）。A-3中决定是否及在一体制的逐渐发展是可能的。启动或恢复的组件，这是不符合的增量发展。只有一个组件-保险销售-被确定在增量发展。不过，这是最大的，最重要的。这是给了负责销售过程控制所有保险产品。其他组件被开发常规。A-4的做一些调查研究，找出了该系统可开发增量。确定垂直切割和数量递增。此外，准备的框架，允许增量发展。总体而言，有四个递增，直到完成鉴定。增量，说明该系统的开发，是保险产品的类别。为了开发一种结构化的方式递增，框架，以便延长（一）对新开发的产品，插件及（ii）一个典型的部件和控制纳入实部共处。A-5中选择第一个增量，建立一个探索性的用户界面原型，并确保配套业务组件的可行性。原型开始最困难的产品。完整的用户界面，建立使用GUI构建器。该样机的结果是一个插件的用户界面的增量研究。它可以插入到这将是该系统是为了进行验证一次。原型有一个小的控制逻辑，但没有业务逻辑。阿-6检讨与客户的要求得到明确的原型在一起。此外，目前的发展现状。从客户的承诺，继续这种方式。在这里举办了研讨会，每4周来验证与的CUS-Tomer的原型在一起。也证明了开发进度。在一个车间的当前状态和未来状态的车间系统计划结束时清楚传达。最后要求被记录和客户预期明确承诺了这些要求。此后，经审定的部分实现发射（或至少预定）。图。2：活动的继承A-7中获取系统完成所有层/选定/下一个增量层。这意味着，设计和开发的业务组件，与其他系统集成他们，最后，把与客户端组件和用户界面的所有在一起。作为原型建成使用GUIBuilder中的代码为原型的生成，而不是扔掉。即使在水平点的增量是完整的，它仍然可以修改用户界面采用了图形用户界面生成器。的A-8，直到垂直完整：同时为原型的下一个增量的用户界面。设立一个真正的原型和部分组成的系统的基准。然后继续进行活动的本周期/增量的A-6（见图。2）。按照计划，它需要四个增量，以获得完整的系统的所有10个保险产品。阿-9提供一个测试系统，让客户做安装-在他的环境和性能测试-，功能-，音量。测试系统必须至少有一个横向保险产品齐全。由于技术上的问题，对客户的预生产环境还没有准备好。其后，而不是在他的环境测试系统中的客户使用我们的测试环境，测试和发布系统。这使所有的功能，但仅限于有限的安装-，音量-，和性能测试。A-10的最后，完成开发工作，交付完整的POS系统。重组后的研究进展开发T输入法。重组后的系统的整体发展的需要14个月。9个月后完成，该系统由客户测试的。经过12个月的系统进入试生产阶段，经过14个月（和两次失败的尝试）终于去了生产力。系统的大小。已开发约19.0万行的Java代码（不计行语句）或2000年几乎完全类（不计的IDL定义，Perl脚本，和SQL语句）。从第一个开发再利用的约400班。配套的框架和（瘦客户机框架，持久化框架，JUnit中，图表库，CORBA技术，从JDK等）类库贡献将近6000级。然而，并非所有这些类都是交付系统的一部分。经验及教训在本节中的经验，这种方法将提交。请注意，这些都是一个项目的经验，因此不需要得到普遍有效的。发展过程，估计，生产率•持续集成是必要的，以确保在所有阶段一贯制。整合了较为严重的问题之一（P-3级）。因此，重组过程后强调持续集成和验证。我们综合频繁但与XP的类似技术[1]我们没有协调的一体化进程。•持续集成帮助也得到发展速度。每个人（尤其是开发者）可以看到，在作为一个整体，他们在部分系统的开发进度。这似乎激发了很多人。•集成商必须非常交际。例如，承诺在一个软件的一些必需品，为团队将有资格入住和集成（没有编译器错误，单元测试，版本等）。因此集成商执行这些规则。他们需要-并-拒绝的能力，而不用担心开发一个组件。•两个人（150名全职雇员）出了八个一体化，集成测试团队等是一个很好的规模和一定不会太多。一致的集成不会偶然发生，但支付了从长远来看了很多。尤其是当有一个（改变）接口相当数量到其他系统。•整合的活动是难以自圆其说的，因为他们往往出现非生产性-至少从一定角度。它需要坚持不懈的高度稳定证明了几乎两个开发任务只是为了等非生产性'的东西像集成，集成测试等•清除对部分或系统组件的开发任务，有助于确保质量（这是一个经典的[3]，但往往被忽略）。团队中的每个体质量欠佳知道会反弹回来。我不知道到何种程度，这将是集体代码所有权或类似的方法的情况。•具有生产效率高，交货准时的紧张活动结合的情况下可以给人的印象是有很多人在团队中。这是什么新的结构化方法趋于平衡工作量和避免高峰。但究竟这会成为一个问题，文化是一个忙碌前的最后期限是正常的活动和预期。而不是着眼于发展进程或一些数字的推理常常这样下去密切：“这里有一个车间前，甚至没有任何紧张的活动之前交付。因此，必须在团队人太多了。因此，团队的规模可以在不减少任何进一步的影响。“这些（致命）的结论有很多与管理能力，看看做当发展运行良好，什么时候不（亦见下文）。•（除团队内部使用）这是浪费时间的测量交流/关于系统的大小或生产力号码-如每个开发控制线和月-如果没有其他人的IT公司一样。因为他们无法直接比较中可以看出在其他项目，如报表“2000/LoC每月开发”往往根本不理解。这个