涪陵区小城镇建设管理处网站,asp网站版权,行政部建设公司网站,百度竞价排名一年费用这里写目录标题 需求开发模型软件生命周期瀑布模型螺旋模型增量模型、迭代模型敏捷模型Scrum 测试模型V模型W模型#xff08;双V模型#xff09; 需求 用户需求#xff1a;没有经过合理的评估#xff0c;通常就是一句话 软件需求#xff1a;是开发人员和测试人员执行工作… 这里写目录标题 需求开发模型软件生命周期瀑布模型螺旋模型增量模型、迭代模型敏捷模型Scrum 测试模型V模型W模型双V模型 需求 用户需求没有经过合理的评估通常就是一句话 软件需求是开发人员和测试人员执行工作的依据
用户的需求不能直接作为开发和测试的依据。针对用户的需求产品经理需要进行需求分析(技术可行性、市场可行性、成本投入和收益占比等)后才可转变为软件需求。
开发模型
规范的流程是在时代的演变下逐渐成型并不是一开始就是规范的流程
软件生命周期
软件生命周期实际就是软件的开发模型认识具体的开发模型之前先了解软件的生命周期 需求的开始是软件生命的起点中间会经历需求的计划、设计程序开发程序测试等阶段直至软件不再进行维护便到了生命的重点 软件流程需求分析、计划、设计、编码、测试、运行维护开发:设计开发文档(用什么技术、用什么框架等等)测试:明确需求设计测试用例、测试计划(明确本次测试设计到的工具、设计到的测试类型…)运行维护软件上线之后在线上环境使用下可能会出现一些意向不到的情况 修复性维护:对项目中未发现的问题进行修复。 完善性维护:对功能进行完善。 预防性维护:居安思危为了避免产品在线上出现一些其他不可预料的问题进行一些防护的手段。 正常使用没有问题但是在极端的情况下会出现问题(性能问题) 软件的通用流程
阶段具体内容产出需求分析分析用户需求是否合理分别从市场需求、技术等方面进行分析。该阶段会输出需求等文档。计划对成立的需求执行需求执行计划多长时间内完成该需求每段时间具体完成哪些功能。该阶段会输出计划等文档。设计将需求细化成一个个任务团队成员各司其职领取任务并进行技术设计(如何进行架构设计设计哪些接口、采用什么技术)该阶段会输出技术等文档。编码开发人员参考需求文档、设计文档、交互图等等文件进行代码的编写。代码文件等文档。测试测试人员需要介入到软件的测试中来参考测试用例对软件进行测试测试用例、测试设计与计运行维护项目测试结束之后项目需要进行上线并对产品进行线上的维护。线上的维护主要分为三个方面。分别为修复性维护、完善性维护和预防性维护。
瀑布模型
瀑布模型在软件工程中占有重要地位是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次因此是线性顺序进行的软件开发模式。
优点/特点
强调开发的阶段性线性结构每个阶段只执行一次是其他模型的基础框架
缺点
测试后置 前面各阶段遗留的风险推迟到测试阶段才被发现导致项目大面积。返工失去了及早修复的机会必须留有足够的时间给测试活动否则导致测试不充分将缺陷直接暴露给用户(产品质量差) 周期太长产品很迟才能被看到和使用可能会导致需求/功能过时
瀑布模型的适用场景:需求固定的小项目
螺旋模型 螺旋模型中各个阶段都引入的风险分析原型 引入的目的是减少各阶段遗留的风险问题避免把问题留到后面的阶段 优点
强调严格的全过程风险管理强调各开发阶段的质量增加风险分析和原型
缺点
项目中可能存在的风险性与风险管理人员的技能水平有直接关系需求人员、资金、时间的增加和投入可能会导致项目的成本太高
适用场景:规模庞大、复杂度高、风险大的项目。
增量模型、迭代模型
增量模型将大需求拆分成小需求每个小需求独立开发上线 迭代模型基础板本-优化版本1-优化版本2-……增量模型将一个大的需求修改成多个小功能每个功能独立开发上线迭代模型会上线一个基础版本但是基础版本所有的功能都有只不过功能比较简陋后期再继续迭代优化上线
增量是逐块建造的概念迭代是反复求精的概念。
迭代模型和增量模型在现在已经不会单独去使用而是配合着去使用
适用场景:大型项目需求不明确
敏捷模型
克服在项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本和时间。
敏捷模型主要旨在帮助项目快速适应变更请求。因此敏捷模型的主要目的是促进项目的快速完成。敏捷性是通过使过程适应项目删除对特定项目可能不是必需的活动来实现的。此外避免任何浪费时间和精力的事情。在敏捷模型中需求被分解成许多可以增量开发的小部分。敏捷模型采用迭代开发。每个增量部分都是在迭代中开发的。每次迭代都旨在小而易于管理并且只能在几周内完成。一次为客户计划、开发和部署一个迭代。没有制定长期计划。
《敏捷宣言》
个体与交互重于过程和工具 强调高效的沟通 可用的软件重于完备的文档 强调轻文档文档不应该作为工作验收的标准 客户协作重于合同谈判 主动及时了解当下的需求 响应变化重于遵循计划 能够主动迎接变化 敏捷模型的四个特点:轻文档轻流程重自标重产出
Scrum
Scrum是敏捷模型中的一种又称为迭代式增量软件开发模型。在scrum模型中主要有三个角色和五个重要会议。三个角色不是指三个人而是三类角色
三个角色:scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
product owner负责整理userstory(用户故事)定义其商业价值对其进行排序制定发布计划对产品负责。 产品经理收集需求产出软件需求文档 scrum master负责召开各种会议协调项目为研发团队服务。研发团队则由不同技能的成员组成通过紧密协同完成每一次迭代的目标交付产品。 由很多角色组成:开发人员(前端、后端)、测试、交互、设计…… 迭代开发scrum将产品的开发分解为若干个小sprint(迭代)其周期从1周到4周不等但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的userstorv是固定的。每次迭代会产生一定的交付。
Scrum的流程
产品负责人负责整理user story形成product backlog。发布计划会议:product owner负责讲解user story对其进行估算和排序发布计划会议的产出就是制定出这一期迭代要完成的story列表sprint backlog。迭代计划会议:项目团队对每一个story进行任务分解分解的标准是完成该story的所有任务每个任务都有明确的负责人并完成工时的初估计。每日例会:每天scrum master召集站立会议团队成员回答昨天做了什么今天计划做什么有什么问题。演示会议:迭代结束之后召开演示会议相关人员都受邀参加团队负责向大家展示本次迭代取期间大家的反馈记录下来由po整理形成新的story。得的成果。回顾会议:项目团队对本期迭代进行总结发现不足制定改进计划下一次选代继续改进以达到持续改进的效果。 敏捷中的测试 轻文档和快速迭代
敏捷模型中强调轻文档所以测试人员不应使用传统的Excel编写测试用例的方法更多的是0使用思维导图、探索性测试(强调自由度设计和执行同时进行根据测试结果不断调整测试计划)、自动化测试等 轻文档测试用例、测试计划文档、测试报告…… 敏捷讲求合作在敏捷项目组中测试人员应多主动跟开发人员了解需求、讨论设计、一起研究bug出现的原因。
测试模型
V模型 V模型目的是改进软件开发的效率和效果。是瀑布模型的变种。 优点: 明确的标注了测试过程中存在的不同类型的测试并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系有效提升测试的质量和效率。V模型指出: 单元和集成测试应检测程序的执行是否满足软件设计的要求 系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标 验收测试确定软件的实现是否满足用户需要或合同的要求 缺点:仅仅把测试作为在编码之后的一个阶段未在需求阶段就介入测试。缺点同瀑布模型。 W模型双V模型 开发V模型并不是单单指编码阶段而是为产品开发流程而实施的各个阶段 特点:测试的对象不仅是程序需求、设计等同样要测试测试与开发是同步进行的 优点有利于尽早地全面的发现问题。例如需求分析完成后测试人员就应该参与到对需求的验证和确认活动中以尽早地找出缺陷所在。同时对需求的测试也有利于及时了解项目难度和测试风险及早制定应对措施显著减少总体测试时间加快项目进度。 缺点: 需求、设计、编码等活动被视为串行的;测试和开发活动也保持着一种线性的前后关系上一阶段完全结束才可正式开始下一个阶段工作。重流程无法支持敏捷开发模式。对于当前软件开发复杂多变的情况W模型并不能解除测试管理面临着困惑。
