销售点系统的发展.docx

销售点系统的发展：体验报告

摘要：这份报告包括了一些经验，这是期间的一个销售点终端（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中获取系统完成所有层/选定/下一个增量层。这意味着，设计和开发的业务组件，与其他系统集成他们，最后，把与客户端组件和用户界面的所有在一起。
     作为原型建成使用GUI Builder中的代码为原型的生成，而不是扔掉。即使在水平点的增量是完整的，它仍然可以修改用户界面采用了图形用户界面生成器。
的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每月开发”往往根本不理解。这个数字是否意味着高或低生产力？。
需求分析和探索原型
•原型有助于获得快速的要求。特别是在一种情况：客户的需要和需求尚不完全清楚 - 或者至少不明确的记录。
•使用探索原型，让最重要的要求清楚，但不'过样机系统。通常情况下，我们使用原型，以确保POS系统支持在核准的方式处理和个人屏幕都包含正确的信息。
•微变在用户界面 - 即使在后期阶段 - 可以轻松地处理与GUI Builder工具使用。当用户界面几乎完全建成一个GUI Builder和我们有能力在任何时间重新安排，我们也只能用稀少的原型来决定在哪里放置在屏幕上的一个字段。
•介绍后恢复的发展（一大）为客户和开发商的信任短时间内原型。该项目的气候变化，从紧张到轻松，经过第三次研讨会，气候非常乐观（可
太危险）。
•不要指望顾客探索自己的原型。做这做，有计划，并主持研讨会。除了研讨会上，我们做了一些尝试得到进一步的反馈意见，例如通过提供独立版本
原型。这里的反馈是非常微薄的，你可以控制，无论是原型，也不是其呈现方式分配。
•如果你弄清楚什么（系统的一部分）你是什么样的展示和发展的实际状况没有虚假的期望上来了。我们没有'为什么不是系统做好准备'影响，由于我们的原型设计方法。
•这是一个时间来建立一个GUI手工屏幕废弃物 - 至少是标准的。这些工具例如[5] - 这是相当成熟并允许往返和一个布局随时修改。即使系统已接近完成。我们不需要在任何时间接触生成的代码。
•建立一个原型是没有书面说明替代品，但它简化了显着创造一个规范。它缓解了一个规范，因为要作出一个合理的数额注明屏幕规格从原型拍摄的照片组成。顺便说一下，这个文件就变得尤为重要，当它来到到后期的变化。在这个时候，没有人有兴趣的原型了。
•原型并不妨碍后期的变化，但它最大限度地减少重大失误的风险。研讨会期间发现有一些细微的地方制度两个问题，必须改变错误的，新的要求。
系统测试，部署，预生产
•JUnit测试[2]帮助了很多，但在大量的用他们时，他们往往会变得相当复杂。组织沿测试场景和引用这在了JUnit -测试用例头方案帮助他们，使他们简洁。
•如果没有适当的负载和性能测试，它仍然不明对发达国家的数量结构系统执行情况。通常，系统将执行的数量结构，相当于以某种方式对开发团队的规模舒服。一个八人小组经常产生一个系统，它执行八（但没有以上）用户同时使用舒适。
•负载和性能测试，根本不是没有有效的工具支持。在一个数量结构，超出了开发团队的能力来手动生成的用户负载最少。
•不要让系统进入生产的情况下直接在试生产阶段（系统和系统集成测试）的完整的测试周期。如前所述，客户有其前期制作在当时的测试系统即将交付环境权的一些技术问题。为了避免进一步的延误，测试是在开发公司（4）环境。这是足够的功能测试，但显然没有足够的负载和性能测试等。
•在客户站点上可用的预生产环境的情况下是比重大的不便更多。不仅如此，没有从正确的负载和性能测试阻止，这也使得它非常困难和耗时
跟踪下来，甚至最简单的事情。一个没有预生产环境生产系统实际上是一个噩梦。
•非常谨慎，让您的客户访问您的测试和变更管理工具 - 事实上，不这样做。背后的想法似乎吸引力 - 共享相同的工具环境，以便让客户测试团队之间的快速沟通和发展。但是，通常是客户 - 当然 – 也有开发团队的其他要求。直到这些工具可以像客户端一个同样的变化，他们只会导致许多讨论使用时协作开发方面这样简单的事情。
•该系统的部署绝不能低估。安装和操作的支持是必要的，必须由开发团队提供系统是否应该毫不拖延地去生产 - 即使它是不明确的开发团队提供这种支持的责任。这是不够的，只提供软件（包括全面的文档）和第一时间的帮助。也有可以避免的麻烦和延误因客户和托管方责任不清。
综述
    总结并给予了同样的情况，探索原型将是一个需要做的事，再次以同样的方式已经完成。同样是在一个稳定的重点和明确的整合分配ofresources这项工作有效。问题的领域是测试该项目的后期阶段。测试过程中的问题引起或与客户的初期测试。这些问题有些是技术问题（预生产系统未准备好），某个进程相关（变更管理，建立了晚），有的因缺少技能（客户没有现在的方式和内容进行测试）。这个事情需要接受培训（更彻底地计划）。
      最有趣的事情之一 - 至少在笔者 - 仍然是发生什么事时，开发团队文化（主要是结构化的方法，缺乏
繁忙的活动等）是由该公司发展的文化不同，如何发展，然后从外面的人看见。在反思，一些模仿有点像'让团队出现之前，强调释放'似乎是比某些人试图说服某些活动大多是适得其反的，只是一个计划不周症状更成功的方法。
     该报告的许多经验在这里并不是新的，而是一个典型的消息确认 - 包括一个事实，即传统的信息往往是未知的或忽略。所以，我认为大多数的经验在这里所作的不针对特定的销售系统的一个分布点的发展。定性比较和项目，这些项目在规模，努力和时间上类似的评价将是非常有趣。