软件开发中的人员与过程.ppt

第二章,软件开发中的人员与过程_3,上节回顾,软件工程师需养成的习惯： 编码习惯与规范、撰写文档能力 、源代码管理习惯 、主动沟通与反馈 、计划与总结的习惯 、测试习惯 软件开发生命周期介绍 需求分析、系统设计、编码实现介绍与难点分析,本节目标,软件开发生命周期： 系统测试、运行维护介绍与难点分析 软件生命周期模型 瀑布模型 原型模型 螺旋模型 渐增模型,测试,编程大师说：没有错误的程序世间难求。 测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。 成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。 通过测试能提高软件的质量，但是提高质量不能依赖测试。 测试只能证明缺陷存在，不能证明缺陷不存在。,测试方法,测试方法：黑盒测试、白盒测试： 白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档。 黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档。,测试阶段,测试阶段：单元测试、集成测试、系统测试、验收测试 单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。 集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。 系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。 验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。,测试分类与内容,测试流程,第一步：制定测试计划。该计划被批准后转向第二步； 第二步：设计测试用例。该用例被批准后转向第三步； 第三步：如果满足“启动准则”，那么执行测试； 第四步：撰写测试报告； 第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。,测试难点解析 1,尽早测试 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。避免测试自己的程序 尽可能避免测试自己编写的程序 ，程序开发小组也应尽可能避免测试本小组开发的程序。如果条件允许，最好建立独立的软件测试小组或测试机构。这点不能与程序的调试（debuging）相混淆。调试由程序员自己来做更有效。 程序员可以自己进行单元测试与集成测试，但是系统测试与验收测试由测试小组完成。,测试难点解析 2,测试用例中包括正确与错误的输入与输出 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。 合理的输入条件是指能验证程序正确的输入条件，不合理的输入条件是指异常的、临界的，可能引起问题异变的输入条件。 软件系统处理非法命令的能力必须在测试时受到检验。 用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。 测试中的群集现象 在测试中存在着80-20原则：80的缺陷聚集在20的模块中，在被测程序段中，若发现错误数目多，则残存错误数目也比较多。 这种错误群集性现象，已为许多程序的测试实践所证实。 根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。,测试难点解析 3,严格执行测试计划，排除测试的随意性 测试之前应仔细考虑测试的项目，对每一项测试做出周密的计划，包括被测程序的功能、输入和输出、测试内容、进度安排、资源要求等。 注意回归测试 测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。,测试难点解析 4,利用测试工具提高测试效率 测试工作在软件开发整个过程中占有极为重要的位置，而全人工测试是非常麻烦的，所以测试过程的自动化已成为测试发展的重要方向。 测试工具的选择对测试的规范化影响很大，目前已开发出了各种自动化软件测试工具，它们为软件测试提供了强有力的支持。 利用bug管理工具管理测试过程 Bug也有其生命周期，通过管理工具对bug进行追踪，用以管理bug提交、bug消除，不仅能降低同样错误的重复发生，提高开效率，而且有助于项目管理的难度。,阶段性成果,软件系统实现与测试计划 软件系统测试用例说明书 软件系统测试总结报告 经过测试的系统,运行维护 1,将软件部署到用户环境中运行系统的过程，在系统运行的漫长过程中，若是出现问题，需要对系统进行维护。 系统在运行期间，无论从系统的功能、硬件设备、软件程序和网络环境等，都可能出现使用户不满意的问题。因此，需要配备专门的维护人员，分析系统存在的问题，及时修正出现的错误，使系统保持正常的运行。,运行维护 2,系统运行前，需要进行培训工作、数据准备与文档移交。 培训工作包括对用户的培训包括管理信息系统知识的普及、新制度的学习、操作训练等。 开发新系统的过程中，就应该进行数据的准备工作，按照系统分析和系统设计、数据字典等为指导，根据手工管理的资料，组织和整理所需的原始数据。在数据准备过程中，遵循三个原则：真实性、准确性、完整性。 对在开发过程中形成的所有文档资料，如可行性研究报告、系统分析说明书、系统设计说明书、程序设计说明书、系统测试说明书、系统使用说明书等等，要由开发者移交给用户，这些文档资料十分重要，用户单位应该妥善保管，以便在系统运行过程中随时查询使用等。,运行维护 3,系统运行包括系统的日常操作和维护等，系统的好坏与系统分析设计、系统设计有很大的关系，也与系统运行有很大的关系。 任何一个系统都不是一开始就很好的，总是经过多次的开发、运行、再开发、再运行的循环不断上升的。开发的思想只有在运行中才能得到检验，而运行中发现的问题也是新的开发思想的源泉。 系统维护是指为了应付信息系统的环境和其他因素的各种变化，保证系统正常运行采取的一切活动，包括改善系统功能、解决系统运行期间发生问题两个方面。,运行维护难点解析 1,用户培训是关键 人都是有惯性的，用新系统取代旧系统，必然需要让系统的使用者放弃旧有的习惯来适应的新的系统。这需要对用户进行培训。 用户培训的目的是让用户认可新系统，并且能够平滑过渡到新系统下。 针对不同的培训对象，培训不同的内容，主要有以下几个方面的内容： 计算机应用基础知识（包括操作系统、汉字录入）； 网络与通讯知识（包括Internet和Intranet）； 系统所用主要软件工具（编程语言、工具、软件包、数据库等）的使用； 系统整体结构，系统概貌； 系统中蕴含的管理思想； 系统操作方式； 可能出现的故障以及故障的排除； 运行操作注意事项等。,运行维护难点解析 2,以行政制度配合系统运行 系统能否为用户创造价值，很大程度上取决于用户对系统的认可程度与使用程度。国内许多单位上ERP失败，并不是因为系统做的有问题，关键问题在“人”。即使用系统的人不认可系统的管理思想，因此系统形同虚设。 所以需要用户高层以行政制度配合系统的使用，使系统能够为用户真正的创造价值。,运行维护难点解析 3,维护从软硬件环境入手 若是正常运行的系统，某一天忽然不能正常运行，需要我们对其进行维护。维护时不要首先对程序代码进行调试。因为以前能够稳定运行的系统，忽然不能够正常运行，一般不是由于代码问题造成的。 维护的重点应该放在软硬件环境上。例如查看运行系统的软件环境有没有发生变化，查看是否由于其它软件与本系统软件冲突造成的，一一排除软件故障后，最后再调试程序代码。,运行维护阶段性成果,软件系统用户手册 系统帮助文档 正常运行的系统,软件生命周期模型,软件生命周期模型是建立确定软件生命周期内所有活动的次序的一种标准，给出了软件开发活动各阶段之间的关系。 常用模型有： 瀑布模型 原型模型 螺旋模型 渐增模型,瀑布模型 1,传统的开发模型是瀑布模型（waterfall model），由W. Royce于1970年首先提出。根据软件生命周期各个阶段的任务，自顶向下从抽象到具体顺序进行。 瀑布模型是线型顺序的，是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用，它提供了一种结构化的、自顶向下的软件开发方法，每阶段主要工作成果从一个阶段传递到下一个阶段，必须经过严格的评审或测试，以判定是否可以开始下一阶段工作，各阶段相互独立、不重叠。,瀑布模型 2,瀑布模型 3,瀑布模型的特点： 当有一个稳定的产品需求定义和很容易被理解的技术解决方案时，该模型可通过阶段评审以帮助项目组及早地发现问题及缺陷，而不至于将问题及缺陷带入下游，从而避免发生更大的错误，避免花更多的时间去纠正； 当要对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上，瀑布模型是一个恰当的选择； 当团队技能比较弱或者缺乏经验的时候，瀑布模型提供了清晰的开发模式，并方便管理； 当质量要求高于成本和进度要求时，它表现得尤为出色。,瀑布模型 4,瀑布模型的缺点： 瀑布模型是一种理想化的线性模型，不能适用需求的变化，无法克服变化引发的问题。如果上一步做错了，下一步也会跟着错，直到产品做完了才发现需求的遗漏和错误，只好从头到尾进行修改，这样逆流而上解决问题是非常困难的； 开发人员常常陷入“阻塞状态”，一部分组员不得不停下来等待别人把前头的任务完成； 该模型是在项目全部完成后一次性向客户交付产品，而不能分阶段的交付可运行产品，不能满足急着使用产品的用户，而会引起用户的不满。,原型模型 1,原型（prototype）模型的基本思想是：首先建立一个能反映用户主要需求的原型系统，让用户使用该系统，通过实践，了解未来系统的概貌，以便用户判断哪些功能符合他们的需要，哪些功能应该加强，哪些功能需要补充，哪些功能是多余的然后根据用户的意见快速修改系统，再让用户使用。 这样，对原型系统的反复试用和改进，最终建立起完全符合用户需要的新系统。,原型模型 2,历史上曾经形成实现原型模型的两种途径：抛弃原型法和演化原型法。 抛弃原型法是通过建立一个原型，使用户对系统有一个感性认识，以便更准确地确定需求，或者更严格地验证设计方案。使用完之后就把这种原型系统抛弃掉，然后再重新建立正式的目标系统。这种途径本质上仍属于瀑布模型，建立原型只不过是一种辅助性的步骤。 演化原型法是迭代的动态方法。在每次迭代过程中，都要再次分析和确定需求，再次进行设计，再次实现系统，以及再次进行测试和评价。因此，早期所犯的错误其后果并严重。这种途径的动态性质对开发者和用户都是一种挑战，它的成功在很大程度上取决于开发者和用户双方是否愿意在很长一段时间内对信息交流和修改系统采取开放的态度。,原型模型 2,基于演化原型法的软件开发模型 Boehm提出的螺旋模型： 分析，建原型，评价与修改； 设计，建原型，评价与修改； 程序设计，检原型，评价与修改。 Gilb提出的渐增模型： 完成一部分分析工作； 完成一部分设计工作； 完成一部分程序设计工作； 建原型并评价； 重复上述过程。,开发模型的选择 1,传统的瀑布模型适于以下几种特点的软件开发： 在开发时期内没有或很少有需求变化； 对应用领域很熟悉（例如，扩充已存在的系统）； 低风险项目（例如，对项目和开发环境很熟悉）； 除了在早期阶段，用户对开发工作参与很少； 要求使用面向过程的编程语言。,开发模型的选择 2,螺旋模型适于以下几种特点的软件